(57)【要約】【課題】非対称アクセスを用いた場合にも上位層の確認応答フレームもしくは制御フレームを効率的に送信し、システム全体のスループットを向上すること。【解決手段】実施形態によれば、無線通信装置間において第１間隔によるフレーム送信と該第１間隔より長い第２間隔によるフレーム送信とを行う非対称通信に用いられる無線通信装置が提供される。該装置は、送達確認応答の送信を要求するフラグが設定されたフレームを受信する受信部と、前記フレームの受信に応じて、前記第１間隔を前記第２間隔より長い第３間隔に変更する間隔制御部と、変更された前記第３間隔によるフレーム送信を行う送信部と、を具備する。【選択図】図１
2014127956.tif 000002
【特許請求の範囲】
【請求項１】
無線通信装置間において第１間隔によるフレーム送信と該第１間隔より長い第２間隔によるフレーム送信とを行う非対称通信に用いられる無線通信装置であって、
送達確認応答の送信を要求するフラグが設定されたフレームを受信する受信部と、
前記フレームの受信に応じて、前記第１間隔を前記第２間隔より長い第３間隔に変更する間隔制御部と、
変更された前記第３間隔によるフレーム送信を行う送信部と、
を具備する無線通信装置。
【請求項２】
前記間隔制御部は、前記第３間隔によるフレーム送信を行なったのち、少なくとも１つのフレームを正常に受信するまで当該第３間隔を維持する請求項１記載の装置。
【請求項３】
前記間隔制御部は、前記フレームを受信し、かつ少なくとも１回の前記第１間隔によるフレーム送信が行なわれた後に、前記第１間隔を前記第３間隔に変更する請求項１記載の装置。
【請求項４】
前記送信部は、前記第２間隔によるフレーム送信を行っている際に、当該第２間隔が開始してからの経過時間を示すタイマーがタイムアウトする以前に当該タイマーがキャンセルされたこと又は当該タイマーがキャンセルされた回数を示す情報に応じて、前記送達確認応答の送信を要求するフラグが設定されたフレームを送信するか否かを判定する請求項１記載の装置。
【請求項５】
前記間隔制御部は、送達確認応答の受信を期待することを示す情報を上位層から受信し、かつ、前記フレームを受信した場合に、前記第１間隔を前記第３間隔に変更する請求項１記載の装置。
【請求項６】
送信要求がなされた複数のフレームを記憶する送信バッファをさらに具備し、
前記送信部は、前記第２間隔によるフレーム送信を行っている際に、前記複数のフレームの少なくとも１つにおいて前記送達確認応答の送信を要求するフラグが設定されているならば、前記複数のフレームのすべてに当該フラグを設定して送信する請求項１記載の装置。
【請求項７】
前記第１間隔と前記第２間隔の設定を無線通信装置間で交換することを要求するフラグを含めて前記複数のフレームを送信する請求項６記載の装置。
【請求項８】
無線通信装置間において第１間隔によるフレーム送信と該第１間隔より長い第２間隔によるフレーム送信とを行う非対称通信に用いられる無線通信装置であって、
送達確認応答の送信を要求するフラグが設定されたフレームを受信し、前記フレームの受信に応じて、前記第１間隔を前記第２間隔より長い第３間隔に変更し、前記第３間隔によるフレーム送信を行うように構成されたプロセッサと、
前記プロセッサに接続されたメモリと、
を具備する無線通信装置。
【請求項９】
無線通信装置間において第１間隔によるフレーム送信と該第１間隔より長い第２間隔によるフレーム送信とを行う非対称通信に用いられる無線通信装置であって、
アンテナと、
送達確認応答の送信を要求するフラグが設定されたフレームを前記アンテナを介して受信する受信部と、
前記フレームの受信に応じて、前記第１間隔を前記第２間隔より長い第３間隔に変更する間隔制御部と、
変更された前記第３間隔によるフレーム送信を前記アンテナを介して行う送信部と、
を具備する無線通信装置。
【請求項１０】
無線通信装置間において第１間隔によるフレーム送信と該第１間隔より長い第２間隔によるフレーム送信とを行う非対称通信に用いられる無線通信方法であって、
送達確認応答の送信を要求するフラグが設定されたフレームを受信するステップと、
前記フレームの受信に応じて、前記第１間隔を前記第２間隔より長い第３間隔に変更するステップと、
変更された前記第３間隔によるフレーム送信を行うステップと、
を含む無線通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、無線通信装置に関する。
【背景技術】
【０００２】
無線LANではCSMA/CA方式のアクセス制御が用いられており、各無線通信装置は無線チャネルを使用する前に無線チャネルの占有状態を測定及び検出する。各無線通信装置が送信を行う前にランダムにバックオフを設定することで、無線通信装置間で帯域を公平に利用することが可能である。数10cm程度の近距離通信を仮定すると、無線帯域にはその通信範囲に入る無線通信装置のみが影響する。したがって、近距離通信では、ランダムバックオフ制御よりも効率的なアクセス制御の方法が期待される。
【０００３】
上記の近距離通信を仮定した場合、1対1無線通信での送受信が想定される。接続確立までの制御信号送信時にはランダムバックオフを行い、接続確立後にはバックオフ無しに一定間隔(例えばIEEE802.11の無線LANにおけるSIFS、DIFS等)で送受信を行う。
【０００４】
接続要求送信を行う無線通信装置(以下「Initiator」または「イニシエータ」と表記する)と、接続要求受信の無線通信装置(以下「Responder」または「レスポンダ」と表記する)のそれぞれに与える一定期間を変更することにより、イニシエータとレスポンダの衝突を回避すると共にイニシエータに優先権を与える方法が提案されている。ここで、イニシエータにはInitiator IFS(IIFS)を与え、レスポンダにはResponder IFS(RIFS)を与え、IIFS<RIFSに設定する。この方法では、イニシエータにレスポンダと比較して短い信号送信間隔を与えることでイニシエータには優先的に信号を送信する機会が与えられる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−３１８６３１号公報
【非特許文献】
【０００６】
【非特許文献１】Standard ECMA-398 Close Proximity Electronic Induction Wireless Communications 1st Edition
【発明の概要】
【発明が解決しようとする課題】
【０００７】
非対称アクセスを用いた場合にもTCP/IPやDTCP(Digital Transmission Content Protection)など上位で必要な場合にレスポンダからのパケットを効率的に送信し、システム全体のスループットを向上できることが望まれている。
【課題を解決するための手段】
【０００８】
実施形態によれば、無線通信装置間において第１間隔によるフレーム送信と該第１間隔より長い第２間隔によるフレーム送信とを行う非対称通信に用いられる無線通信装置が提供される。該装置は、送達確認応答の送信を要求するフラグが設定されたフレームを受信する受信部と、前記フレームの受信に応じて、前記第１間隔を前記第２間隔より長い第３間隔に変更する間隔制御部と、変更された前記第３間隔によるフレーム送信を行う送信部と、を具備する。
【図面の簡単な説明】
【０００９】
【図１】実施形態に係る無線システムの概略図
【図２】1対1無線通信における非対称アクセスの例を示す図
【図３】一定期間にわたりフレーム送信を停止する例を示す図
【図４】第１の実施形態に係る通信制御のシーケンス図
【図５】第１の実施形態に係る無線通信装置の構成図
【図６】干渉挿入時の例を示す図
【図７】第２の実施形態に係る通信制御のシーケンス図
【図８】第４の実施形態に係る通信制御のシーケンス図
【図９】第５の実施形態に係る通信制御のシーケンス図
【図１０】第６の実施形態に係る通信制御のシーケンス図
【図１１】第１０の実施形態に係る無線通信装置の構成図
【図１２】第１６の実施形態に係る無線通信装置の構成図
【発明を実施するための形態】
【００１０】
以下、実施の形態について、図面を参照して説明する。
【００１１】
（第１の実施形態）  
第１の実施形態では、レスポンダまたはRIFS設定中の無線通信装置が、CNLuser（Connection Layer user Layer: 接続ユーザ層）からCNL（Connection Layer: 接続層）へのフレーム送信要求信号(CNL_DATA.request)にTCPACK送信要求(AppTxreq)を挿入することについて説明し、AppTxreqを含んだACKフレームを受信したイニシエータまたはIIFS設定中の無線通信装置は、次の信号送信までの信号送信間隔をLIFSに設定することについて説明する。
【００１２】
図１を参照して実施形態に係る無線システムの概要を説明する。図１の無線システムは、第1〜3無線通信装置1〜3を備える。この無線システムでは無線通信装置間の距離を数10cm程度と仮定している。このような近距離通信の場合、無線通信装置1台に接続する無線通信装置は高々数台となる。図１の例では、無線システムが備える無線通信装置の台数を3台としているが、これに限られず2〜5台程度であってもよい。図１の例では、第1無線通信装置1と第2無線通信装置2とが無線通信を行っている。また第1無線通信装置1と第3無線通信装置3が無線通信を行っている。以下の説明では、第1無線通信装置1と第2無線通信装置2との間の無線通信に着目して説明するが、第1,3無線通信装置1,3との間の無線通信、第2,3無線通信装置2,3との間の無線通信も同様である。
【００１３】
1つの無線通信装置がアクセスポイントとしてブロードキャスト信号(例えばビーコン信号)を送信する。ランダムバックオフ制御を行う方法よりも接続を簡易化しかつ効率化するために、当該無線システムは、次のように通信を行う。
【００１４】
信号送信を行う時には、接続要求信号(Connect Request)といった接続を開始するための無線通信装置間の制御信号を、例えばランダムバックオフ制御を用いて送受信する。接続確立後には、イニシエータにレスポンダと比較して短い信号送信間隔を与える。これにより、ランダムバックオフ制御無しとしても、イニシエータとレスポンダの衝突を回避し、イニシエータに優先的に信号送信の機会を与えることができる。 
図２に、1対1無線通信における非対称アクセスのアクセス例を示す。それぞれの無線通信装置には異なる信号送信間隔が設定される。同図はイニシエータの信号送信間隔をIFSとし、レスポンダの信号送信間隔をRIFSとし、IIFS<RIFSである場合を示す。この場合、イニシエータにデータフレームがある場合には、短い信号送信間隔でフレーム送信が行える。しかし一方で、レスポンダにデータフレームがある場合でも、RIFSタイマーカウント中にIIFSタイマーがタイムアウトし、イニシエータが送信を開始するため、レスポンダはフレームを送信できない問題が生じる。特に上位層においてレスポンダから確認応答フレームや制御フレームを要求するプロトコルを行っている場合には、それらのフレームの送信が遅れ、システム全体のスループット低下を招く。
【００１５】
次に、確認応答フレーム送信要求を相手の無線通信装置に通知する場合を考える。通知を受けた無線通信装置は、一定期間にわたりフレーム送信を停止する。図３に、Δtで示される一定期間にわたりフレーム送信を停止する場合を示す。
【００１６】
レスポンダは、CNLにTCP DATA用とTCP ACK用のバッファを有する。送信フレームのIP層およびTCP層のヘッダ情報を解析し、その解析結果によっていずれかのバッファを選択し、フレームを挿入する。TCP ACK用バッファに送信フレームが存在する時には、その後に送信する応答フレーム(図ではACK frame)に要求フラグを挿入する。この要求フラグが挿入された応答フレームを受信したイニシエータは、Δtで示される一定期間にわたり送信を停止する。レスポンダは、RIFSタイマー後に、確認応答フレームをフレームボディに含んだデータフレーム(図ではData frame)を送信する。この仕組みでは、図３に示す例のような干渉または雑音の影響がある場合において、確認応答フレームを送信したいレスポンダが優先的な送信の機会を逃してしまうこと、即ち、確認応答フレームをΔt内に送信できないという問題が生じうる。
【００１７】
図４に、第１の実施形態に係る通信制御のシーケンスを示す。同図に示すイニシエータおよびレスポンダはいずれも物理層（PHY）、CNL、CNLuser、アプリケーション層（Application）で構成される。PHYとしてはOSI参照モデル2層、4層を想定する。CNLはネットワークを介してデータフレームと応答フレームの送受信を行うものであり、OSI参照モデル5層を想定する。CNLuserは、アプリケーション層とCNLとの間の制御を行う。なお、CNLuserとアプリケーション層との間に他に層がある、もしくはCNLuserの一部にアプリケーション層があるとしても、本実施形態には影響しない。
【００１８】
図４は、ECMA-398規格に基づき、TCP/IPプロトコルのデータ送受信を行う例に相当する。本実施形態に基づく処理を行うために、ECMA-398の応答フレーム構成において、フレームヘッダのリザーブ（予備）ビット内の1ビットをAppTxReqビットとして使用する。以降、この通知ビットを「AppTxflag」と表記する。  
同図に示すように、アプリケーション層からのデータ(TCP Data)に対し、CNLuserからCNLに送信要求(CNL_DATA.request)を出力する。CNLでは、送信要求の入力を受けてIIFSタイマーを起動し、もしくはそれ以前のフレーム送受信終了時点からIIFSタイマーを起動しておき、IIFSタイマーのタイムアウト時にPHYからデータ送信を開始するようにCNLからPHYへデータ(DATA)フレームの出力と送信指示を行う。PHYはCNLにより制御されたタイミングでデータフレーム送信を開始する。
【００１９】
一方、レスポンダでは、CNLにおいて受信データの復号処理及び誤り検出を行い、正常受信時にはCNLからCNLuserにCNL_DATA.indicationを出力する。CNLuserはアプリケーション層にCNL_DATA.indicationによって通知された受信フレームボディ部分(TCP Data)を出力する。次に、レスポンダのアプリケーション層からCNLuserにTCPフレームヘッダをACKflag=1としたフレーム(TCP ACK)を出力する。CNLuserにおいて、ACKflag=1の場合には、CNL_DATA.requestにAppTxreqを挿入してCNLに出力する。
【００２０】
CNLは、自無線通信装置がレスポンダであって且つRIFS設定中の場合には、応答フレームヘッダのAppTxflagを1に設定してPHYへフレーム送信を指示する。なお、自無線通信装置がイニシエータであるが優先権を一時的にレスポンダに移譲してRIFS設定中であって、且つCNL_DATA.requestにAppTxreqがある場合においても、応答フレーム(ACK)のヘッダにおいてAppTxflagを1に設定してPHYへフレーム送信を指示する。応答フレームはIIFS、RIFSより短いSIFSで送信する(ECMA-398参照)。
【００２１】
応答フレームを受信したイニシエータは、応答フレームヘッダのAppTxflagを確認し、AppTxflagが1の場合には、次フレームの送信開始間隔をIIFSからLong Interframe Space(LIFS)に変更（すなわち長く）する。ただし、イニシエータでのフレーム受信処理の結果、イニシエータにおいて送信したフレームに再送の必要がある場合には、IIFSにおいて再送処理し、かつ以降の再送が必要ないと判断した後にIIFSからLIFSに変更する。
【００２２】
なお、LIFSの値としては、その間にRIFS設定の無線通信装置がRIFSタイムアウト後に送信したフレームを受信できる必要があるため、少なくともRIFSタイマー、チャネルビジー検出期間(slot)、送受切替えに必要な期間(TxRxSw timer)を考慮し、“RIFS timer+slot+TxRxSw timer”以上の長さに設定する。
【００２３】
また、ECMA-398の仕様では、CNL_DATA.requestの内容は、CSDU Profile ID(PID), Payload length及びData Payloadのみであるため、上記のAppTxreqの通知方法としては、以下の2通りが考えられる。１つは、現仕様ではPIDが0,1の設定のみであるところ、2を新設し、AppTxreqの場合には2に設定する方法である。もう1つは、CNL_DATA.requestの要素として上記3要素の他にAppTxreqを追加する方法である。この場合、TCPACK要求時には、AppTxreq=1に設定する。
【００２４】
図４の説明では、TCP/IPプロトコルのデータ送受信を行う例で説明したが、映像伝送への適用を考え、上位層にDTCPもしくはDTCP/IPプロトコルを用いた場合にも、図４と同様の処理の流れで本実施形態が行われる。例えば、DTCP/IPではContent Key Confirmationという仕組みがあり、一定時間毎にレスポンダ側からイニシエータ側に、今の鍵の確認要求を出す必要がある。そのため、この鍵の確認要求時に、レスポンダ側アプリケーション層からCNL user層に制御フレームが送信要求として出され、それに対し、CNL user層からAppTxreqフラグを立てたCNL_DATA.requestを送信することで対処する。レスポンダはAppTxflagを立てて応答フレームを送信する。
【００２５】
次に、図５に本実施形態の無線通信装置の構成例を示す。イニシエータとレスポンダは、送信する信号の種類とタイミングが異なるが、ハードウェア構成は同じであっても実現できるため、図５を参照してイニシエータとレスポンダの両方について説明する。図５の無線通信装置は、アンテナ10、無線部20、PHY30、CNL40、CNLuser50及びアプリケーション60で構成される。PHY30は、変調部31と復調部32を含む。CNL40は、CNL送信部41、CNL受信部42、送信バッファ43、受信バッファ44、CNLアクセス制御部45及びフレーム間隔制御部46を含む。CNLuser 50は、送信部51及び受信部52を含む。
【００２６】
先ず、信号送信時の無線通信装置の動作を説明する。アプリケーション60から出力されたパケットは、必要に応じてCNLuser50によりパディングビット（Padding bit）が付加されたのち、CNL_DATA.requestによってCNL40の送信バッファ43に格納される。送信バッファ43は、CNL送信部41からの指示に応じて、バッファ内のデータをその格納順にCNL送信部41に出力する。CNL送信部41は、CNLヘッダ付加等の処理を行ってフレームを生成する。生成されたフレームは変調部31に出力される。変調部31は、フレームに符号化処理、変調処理、物理ヘッダの追加処理等を行って物理フレームを生成する。無線部20は、物理フレームに対してD/A変換処理、アップコンバート等の処理を行って送信信号を生成し、アンテナ10を介して送信する。なお、図５では、CNLヘッダ付加等の処理を行い、フレームを生成するブロックをCNL送信部と称しているが、図５のCNL送信部41、変調部31及び無線部20の送信機能を有する部分をまとめて送信部又は送信手段と称してもよい。
【００２７】
次に、信号受信時の無線通信装置の動作を説明する。アンテナ10を介して受信された受信信号は、無線部20においてダウンコンバート、A/D変換等の処理を施されて物理フレームに変換される。復調部32は、物理フレームに対して復調処理や物理ヘッダの解析等の処理を行ってフレームを生成する。CNL受信部42は、フレームのCNLヘッダの解析等の処理を行う。CNL受信部42は、受信信号が当該無線通信装置の通信相手から送信された信号であって、かつ受信に誤りが無い場合には、CNL_DATA.indicationによってデータをCNLuser50に出力する。なお、図５では、CNLヘッダ解析等の処理を行い、データを生成するブロックをCNL受信部と称しているが、図５の受信部42、復調部32及び無線部20の受信機能を有する部分をまとめて受信部又は受信手段と称してもよい。
【００２８】
自無線通信装置がイニシエータであるかレスポンダであるのかの情報、またはイニシエータとレスポンダの間で優先権を移譲する場合にあっては自無線通信装置がIIFS設定中であるかRIFS設定中であるかの情報は、CNLアクセス制御部45またはフレーム間隔制御部46に保持される。
【００２９】
本実施形態に係る無線通信装置では、CNLuser50に入力するフレームが上位層要求の確認応答フレームもしくは制御フレームの場合、送信部51からCNL40の送信バッファ43に出力するCNL_DATA.requestにAppTxreq情報を挿入する。
【００３０】
CNL40は、送信処理開始時に送信バッファのAppTxreqおよび自無線通信装置のフレーム送信開始間隔の設定を確認する。レスポンダであって、AppTxreq=ON（例えば1）であり、RIFS設定中の場合には、応答フレームヘッダのAppTxflagをON（例えば1）に設定する。また、イニシエータであるがRIFS設定中の場合にも、応答フレームヘッダのAppTxflagをON（例えば1）に設定する。
【００３１】
一方、CNL受信部42において、受信フレームの解析を行った結果、AppTxflagがONの応答フレームを受信したことが判明した時には、フレーム間隔制御部46にその由を通知する。フレーム間隔制御部46は、次フレームの送信開始間隔をIIFSからLIFSに変更し、少なくとも1フレームを正常受信するまでLIFS設定を保持する。1フレームを正常受信後には上記設定をLIFSからIIFSに戻す。図６に本実施形態の仕組みを用いた場合の干渉挿入時の例を示す。同図のように、RIFSタイマーを起動し、送信を試みている途中で雑音または干渉が入った場合、この雑音または干渉の影響が無くなったタイミングから、再度イニシエータはLIFSタイマーを設定し、レスポンダはRIFSタイマーを設定する。その結果、RIFSタイマーのタイムアウト時にレスポンダが送信を行うことが可能となる。
【００３２】
このように、第１の実施形態に係る無線通信装置は、TCP/IPの確認応答フレームを送信したいタイミングでイニシエータがタイマー設定をIIFSからLIFSにすることで、レスポンダがRIFSにおいてフレーム送信を行うことが可能となり、TCP/IPのスループットを向上することができる。また、RIFS<LIFSの関係は、RIFS設定の無線通信装置が所望のTCPの確認応答フレームの送受信ができるまで保持されるため、要求送信後に干渉や雑音が入っても、それらの影響が無くなった後にRIFS設定の無線通信装置が確認応答フレームを送信することができる。
【００３３】
（第２の実施形態）  
第１の実施形態では、イニシエータもしくはIIFS設定中の無線通信装置は、AppTxflag=ONの応答フレーム受信時に、直後のデータフレームの送信開始間隔をIIFSからLIFSに変更する例を示した。一方、IIFS,RIFS,LIFSといったタイマーは無線チャネル上のフレーム送受信終了タイミングを起点に起動する必要があるため、上記の処理を行うためには、イニシエータもしくはIIFS設定中の端末は、フレーム受信終了時にSIFS,IIFS,LIFSタイマーを起動し、受信フレーム解析結果により不必要タイマーをタイマーキャンセルする必要がある。
【００３４】
LIFSについては、IIFSからLIFSに変更する頻度によるが、毎回この処理を行うのは煩雑となる可能性がある。そこで第２の実施形態では、図４においてイニシエータがAppTxflag=1の場合には、直後のデータフレームについては、現在設定中のIIFSタイマーに従いIIFS後にフレーム送信を行い、それに対する応答フレームの無線チャネルでの受信終了時にLIFSタイマーを設定する。
【００３５】
図７に、本実施形態に係る通信制御のシーケンスを示す。基本的に第1の実施形態と同一の処理であるが、AppTxflag=ONの応答フレーム受信時のタイマー設定が第１の実施形態と異なる。なお、第１の実施形態での説明を簡単にするため、図４のシーケンスでは、CNLがACKフレーム受信終了後にLIFSタイマーのみ設定するように示したが、実際には上記に示した通り、フレーム復号処理遅延によりACKフレームの無線チャネルでの受信終了タイミングでAppTxflagの有無が判断できないので、少なくともIIFS及びLIFSタイマーの設定が必要となる。一方、図７のシーケンスでは、最初のAppTxflag=ONの応答フレーム受信時にはIIFSタイマーの設定のみを行い、それに従い図６のようにイニシエータに送信データが存在すればフレーム送信を行う。ここでは、レスポンダは2つ目のフレーム受信時にもAppTxflag=ONの応答フレームを送信する例を示したが、1つ目のフレーム受信時に通知してあるため、ここではAppTxflagは必須ではない。イニシエータはIIFSにおいてフレーム送信後にフレーム間隔制御部46によってフレーム送信開始間隔をIIFSからLIFSに変更する。
【００３６】
このように、第２の実施形態に係る無線通信装置は、レスポンダまたはRIFS設定中の無線通信装置において、TCPACK送信要求が発生してから送信成功するまでの時間は第１の実施形態よりも多少長くなる可能性があるが、イニシエータでのタイマー設定及び制御を簡易化することが可能となる。なお、第１及び第２の実施形態では、レスポンダから要求があった場合に、イニシエータのタイマー値をIIFSからLIFSにする方法として説明したが、それとは別に、イニシエータとレスポンダにおいて信号送信間隔(IIFS,RIFS)の設定を交換する優先権移譲も考えられる。本実施形態においてレスポンダから要求があった場合に、IIFS,RIFS設定を交換するような処理を行ってもよい。ただし、TCPACKの送信のみやDTCPプロトコルでの制御フレーム送信であれば、小さいフレームサイズのフレーム送信で済むので、そのフレームの送受信が正常に終了するまでLIFS設定にすることが有効である。
【００３７】
（第３の実施形態）  
第１及び第２の実施形態では、CNLにおいて自無線通信装置がレスポンダであって且つRIFS設定中、もしくはイニシエータであるが優先権を一時的にレスポンダに移譲しRIFS設定中、かつCNL_DATA.requestにAppTxreqがある場合には、必ず応答フレームヘッダのAppTxflagをONと設定する例を示した。
【００３８】
一方、CNLの送信バッファにAppTxreqAを含んだCNL_DATA.requestが格納された時点でCNL送信部41がRIFSタイマー起動し、送信処理の開始時点でRIFSタイマーがキャンセルされることなくRIFS後にフレーム送信が可能である場合には、必ずしもイニシエータにAppTxreqを通知しなくてもよい。
【００３９】
そこで、本実施形態では、レスポンダにおいて、AppTxreqを含んだCNL_DATA.requestがCNLに入力された直後にRIFSタイマーを起動する。また、イニシエータからのフレーム受信によりRIFSタイマーがキャンセルされたか否か、もしくはキャンセルされた回数をCNLアクセス制御部45またはフレーム間隔制御部46において保持する。この情報をもとにイニシエータにAppTxreqを通知するか否かを判断する。例えば、キャンセルの有無のみで判断する場合、RIFS設定中であって、CNL_DATA.requestにAppTxreqがあり、かつRIFSタイマーキャンセル有りの場合に限り、AppTxflagを立てる。
【００４０】
このように、第３の実施形態に係る無線通信装置は、レスポンダにおいてRIFSでTCPACKのフレーム送信が可能か否かを判断し、できない場合にのみAppTxreqを通知することで、イニシエータの処理を簡易化することが可能となる。
【００４１】
（第４の実施形態）  
第１〜第３の実施形態では、レスポンダからのAppTxreqで要求されるままに、イニシエータはLIFSに変更して、レスポンダ優先の送信を行っていた。一方、本実施形態では、イニシエータのCNL40において、レスポンダからの要求のみでなく、自無線通信装置のCNLuserからの情報も用いてLIFSに設定を変更するかを判断するように構成される。  
図８に本実施形態に係る通信制御のシーケンスを示す。レスポンダの処理は、第１〜第３の実施形態と同一の処理であるため、ここでは説明を省略する。図８を参照して本実施形態に係るイニシエータの処理を説明する。まず、CNLuserではCNLに対し出力するCNL_DATA.request信号にAppTxreq期待情報を挿入するかを判断する。AppTxreq期待情報は、レスポンダのアプリケーションからの応答フレームの受信を期待することを表す。
【００４２】
TCP/IPの送受信を行っている場合には、常にAppTxreq期待情報=ONにしても良い。あるいは、TCP/IPの場合であってかつ、TCP/IP通信開始時のコネクション処理でのウィンドウサイズのやりとりからTCPACK受信タイミングが推測できる場合には、TCPACK受信のタイミングに近いタイミングでAppTxreq期待情報=ONにしても良い。一方、DTCPやDTCP/IPを行っている場合には、ある一定間隔毎にレスポンダから応答フレームを受信するため、その一定間隔を目安にAppTxReq期待情報=ONにしても良い。
【００４３】
また、AppTxReq期待情報のCNL_DATA.requestへの入れ方としては、第１の実施形態で説明したようにPIDの現仕様の設定を変えるか、AppTxreqを追加する形で対応する。本実施形態で示すイニシエータでの挿入時にも、第１の実施形態と同様にPID=2, AppTxreq=1を用いるか、例えばPID=3に設定するか、AppTxreq=2に設定することが考えられる。後者の場合には、自無線通信装置がIIFS設定中かの確認を行うことなく、処理することが可能となる。
【００４４】
CNLではCNLuserからのCNL_DATA.requestにAppTxreq期待情報が挿入されているか否かを判断し、CNLアクセス制御部45もしくはフレーム間隔制御部46において該情報を保持する。レスポンダから受信した応答フレームのCNLヘッダに含まれるAppTxflag=ONの時点で、イニシエータは上記TCPACK期待情報の有無を判断する。AppTxreq期待情報が有る場合には、IIFS設定からLIFS設定に変更を行う。AppTxreq期待情報が無い場合にはIIFS設定を継続して、フレーム送受信を続ける。
【００４５】
このように、第４の実施形態に係る無線通信装置は、イニシエータのCNLにおいてCNLuserからの情報と、レスポンダからの情報の両者を用いて判断することにより、レスポンダから要求されるままにフレーム送信を許すことによる、自無線通信装置の効率低下を防ぐことが可能となる。
【００４６】
（第５の実施形態）  
第１〜第４の実施形態では、レスポンダのCNLの送信バッファ43に挿入されるCNL_DATA.requestはAppTxreqのみである事を前提としていた。一方、アプリケーションによっては双方向のデータ送受信を想定するものもあり、その場合には、レスポンダのCNL_DATA.requestにAppTxreqではない、いわゆるDATAの要求が来る可能性がある。そこで、本実施形態では、レスポンダにおいてAppTxreqのCNL_DATA.requestとAppTxreqではないCNL_DATA.requestとが混在した場合の処理について説明する。
【００４７】
複数のCNL_DATA.requestに伴う送信要求及び送信データが送信バッファに入力された場合の対応として、１つは、次に処理すべき1つのCNL_DATA.requestがAppTxreqか否かで判断する方法である。この場合の処理は第1〜第４の実施形態と同じであるため、ここでは説明を省略する。他の方法では、送信バッファに入力された複数のCNL_DATA.requestに伴う送信要求の全てについて、AppTxreqの有無を判断する。AppTxreqのCNL_DATA.requestと、AppTxreqではないCNL_DATA.requestとが混在していた場合には、CNLにおいて次に処理するデータフレームが、AppTxreqではないCNL_DATA.requestであっても、応答フレームのCNLヘッダに含まれるAppTxflagをONにしてフレーム送信を行う。  
図９に本実施形態に係る通信制御のシーケンスを示す。図９の例では、レスポンダのCNLの送信バッファ43にTCP DATAのCNL_DATA.requestが入り、その後にTCP ACKのCNL_DATA.requestが入る場合を示す。ここで、第１〜第４の実施形態及び上記で説明したように、次に処理すべきCNL_DATA.requestのみで判断すると、DATAであるので、応答フレーム送信時にAppTxflagを立てない。この場合、DATAはイニシエータからのIIFSでのバースト送信が終了するまで送信ができず、これが次に送信バッファに積まれているAppTxflagのフレーム送信にも影響することは明らかである。
【００４８】
一方、送信バッファに積まれている全てのCNL_DATA.requestで判断する場合、レスポンダは送信バッファに溜まる全てのデータフレームのAppTxreqを送信のたびに確認し、送信バッファに溜まる全てのデータフレームからAppTxreqの送信が無くなるまで、応答フレームのCNL header AppTxflagをONにしてフレーム送信を行う。
【００４９】
このように第５の実施形態に係る無線通信装置は、レスポンダにおいてAppTxreqのCNL_DATA.requestとAppTxreqではないCNL_DATA.requestとが混在した場合に、送信バッファに積まれた全要求についてAppTxreqの判断を行うことで、結果的にTCP ACKの送信タイミングを早くすることができる。
【００５０】
（第６の実施形態）  
第５の実施形態では、レスポンダにおいてAppTxreqのCNL_DATA.requestとAppTxreqではないCNL_DATA.requestが混在した場合に、AppTxflagを入れることで、TCP ACKを送信しやすくする例を示した。一方、レスポンダにおいてAppTxreq以外の送信要求が送信バッファに溜まっている場合には、イニシエータとレスポンダにおいて信号送信間隔(IIFS,RIFS)の設定を交換する優先権移譲を適応したほうが、より効率を向上できる可能性がある。本実施形態では、レスポンダからAppTxflagと共に、AppTxreqではないCNL_DATA.requestがある場合には、切替え要求flagも立てて応答信号を送信するしくみについて説明する。
【００５１】
図１０に本実施形態に係る通信制御のシーケンスを示す。図１０の例では、レスポンダのCNL送信バッファにAppTxreqの送信要求と、それ以外の送信要求が複数溜まっている場合を示す。この場合、レスポンダでは、応答フレームヘッダのAppTxflagと共に、切替え要求flagも立てて送信する。一方、AppTxflag及び切替え要求flagが入った応答フレームを受信したイニシエータは、自分の送信バッファ43の状況も考慮したうえで、IIFS/RIFS切替えを行うかを判断する。IIFS/RIFS切替えを行い、レスポンダに一時的にIIFSでの送信期間を与えると判断した場合には、送信終了通知をデータフレームに挿入して送信する。レスポンダでは、AppTxflag及び切替え要求flagを含んだ応答フレームを送信し、それに対する送信終了通知を受信した場合に、それらの情報をフレーム間隔制御部において管理する。上記の場合にはRIFS設定からIIFS設定に変更し、次のフレーム送信はIIFSタイマーに基づいて行う。
【００５２】
図１０の例では、AppTxflag及び切替え要求flagを含んだ応答フレームを受信したタイミングでイニシエータの送信バッファには送信要求が1つ入っているが、ここではIIFS/RIFS切替えを行うと判断した。その他のイニシエータでの判断例としては、例えば送信バッファに送信要求がある場合には、IIFS/RIFS切替えはせずにLIFSにしてTCPACK送信機会を与え、送信要求が無い場合にIIFS/RIFS切替えを行う方法が考えられる。IIFS/RIFS切替えするかは、送信バッファの送信要求の占有率で決める方法も考えられる。後者の場合、例えば送信バッファの送信要求占有率が半分以下の場合にはIIFS/RIFS切替えを行い、送信要求占有率が75%を超えたらIIFS設定に再度切替え、その後はLIFSによって対処するなどが考えられる。
【００５３】
（第７の実施形態）  
本実施形態では、図５の無線通信装置1の構成において、アンテナ10が無線通信装置に含まれる構成を示す。このように、アンテナ10を無線通信装置1に含める構成とすることにより、アンテナまで含めた１つの装置として無線通信装置を構成することが可能となるため、実装面積を少なく抑えることが可能となる。また、図６でも示しているが、アンテナ10を送信処理と受信処理で共用している。このように、１つのアンテナを送信処理および受信処理で共用することにより、無線通信装置を小型化することが可能となる。
【００５４】
（第８の実施形態）  
本実施形態では、図５の無線通信装置1の構成に加えて、バス、プロセッサ部、外部インターフェースを備える構成を示す。プロセッサ部ではファームウエアが動作する。また、これらのプロセッサ部、バス、外部インターフェースはアプリケーション60に存在しても、アプリケーション60とは独立して存在してもよい。このように、ファームウエアを無線通信装置に含める構成とすることにより、ファームウエアの書き換えによって無線通信装置の機能の変更を容易に行うことが可能となる。
【００５５】
（第９の実施形態）  
本実施形態では、図５の無線通信装置1の構成に加えて、クロック生成部を備える構成を示す。クロック生成部は図５の無線部20、PHY30及びCNL40を纏めて無線送受信部70とした場合、無線送受信部70に接続されているとともに、出力端子より外部に出力されている。このように、無線通信装置内部で生成されたクロックを外部に出力し、外部に出力されたクロックによってホスト側を動作させることにより、ホスト側と無線通信装置側を同期させて動作させることが可能となる。
【００５６】
（第１０の実施形態）  
図１１は本実施形態に係る無線通信装置１00を概略的に示している。この無線通信装置100は、図５の無線通信装置１の構成に加えて、電源部101、電源制御部102、無線電力給電部103が追加され、それぞれが無線送受信部60に接続されている。このような第１０の実施形態の構成によれば、電源を制御した低消費電力化動作が可能となる。
【００５７】
（第１１の実施形態）  
本実施形態は、図１１の無線通信装置100の構成に加えて、NFC(Near Field Communications)送受信部を備える。NFC送受信部は、電源制御部102及びMAC処理部40と接続し、アプリケーション60内部に存在しても、独立して存在してもよい。このように、NFC送受信部を無線通信装置に備える構成とすることにより、容易に認証処理を行うことが可能となるとともに、NFC送受信部をトリガとして電源制御を行うことによって、待受け時の低消費電力化を図ることが可能となる。
【００５８】
（第１２の実施形態）  
本実施形態では、図１１の無線通信装置100の構成に加えて、SIMカードを備える構成を示す。SIMカードは、MAC処理部40と接続し、アプリケーション60内部に存在しても、独立して存在してもよい。このように、SIMカードを無線通信装置に備える構成とすることにより、容易に認証処理を行うことが可能となる。
【００５９】
（第１３の実施形態）  
本実施形態では、第８の実施形態に加えて、動画像圧縮／伸長部を備える構成を示す。動画像圧縮／伸長部は、バスと接続する。このように、動画像圧縮／伸長部を無線通信装置に備える構成とすることにより、圧縮した動画像の伝送と受信した圧縮動画像の伸長を容易に行うことが可能となる。
【００６０】
（第１４の実施形態）  
本実施形態では、図５の無線通信装置1の構成に加えて、LED部を備える構成を示す。このように、LEDを無線通信装置に備える構成とすることにより、無線通信装置の動作状態をユーザに容易に通知することが可能となる。
【００６１】
（第１５の実施形態）  
本実施形態では、図５の無線通信装置1の構成に加えて、バイブレータ部を備える構成を示す。このように、バイブレータを無線通信装置に備える構成とすることにより、無線通信装置の動作状態をユーザに容易に通知することが可能となる。
【００６２】
（第１６の実施形態）  
本実施形態では、図５の無線通信装置1の構成に加えて、無線LAN部および無線切替部を備える構成を示す。図１２に本実施形態に係る無線通信装置160を概略的に示している。この無線通信装置160は、図５の無線通信装置1の構成に加えて、無線LAN部161、無線切替部162を追加し、無線切替部160は無線送受信部60、CNLuser50及び無線LAN部161に接続されている。このように、無線LANを無線通信装置に備える構成とすることにより、状況に応じて無線LANによる通信と無線送受信部による通信を切替えることが可能となる。
【００６３】
ミリ波帯では複数チャネルの使用が可能であるが、無線システムにおいて、どのチャネルでも他システムとの干渉が大きく、所望の送受信ができない場合には、無線LANによる通信に切り替え可能であることが望ましい。ここで、切り替える無線LANは、当該無線システムのものとは異なる周波数帯域を用いるIEEE 802.11a,b,g等であっても良いし、当該無線システムと同一の周波数帯域を用いる802.11adであっても良い。また、無線LAN部に独自の送受信アンテナを備える構成としても良いし、当該無線システムと同一の周波数帯域を用いる無線LANの場合にはアンテナを共有してもよい。
【００６４】
（第１７の実施形態）  
本実施形態では、第１６の実施形態に係る構成に加えて、スイッチ(SW)を備える構成を示す。スイッチは無線送受信部60、無線LAN部161、無線切替部162にそれぞれ接続する。このように、スイッチを無線通信装置に備える構成とすることにより、アンテナを共用しながら状況に応じて無線LANによる通信と無線送受信部による通信を切替えることが可能となる。
【００６５】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００６６】
1…無線通信装置、10…アンテナ、20…無線部、30…PHY、31…変調部、32…復調部、40…CNL、41…CNL送信部、42…受信部、43…送信バッファ、44…受信バッファ、45…アクセス制御部、46…フレーム間隔制御部、50…CNLuser、51…送信部、52…受信部、60…アプリケーション、60…無線送受信部、70…無線送受信部、100…無線通信装置、101…電源部、102…電源制御部、103…無線電力給電部、160…無線通信装置、160…無線切替部、161…無線LAN部、162…無線切替部
【図１】
2014127956.tif 000003
【図２】
2014127956.tif 000004
【図３】
2014127956.tif 000005
【図４】
2014127956.tif 000006
【図５】
2014127956.tif 000007
【図６】
2014127956.tif 000008
【図７】
2014127956.tif 000009
【図８】
2014127956.tif 000010
【図９】
2014127956.tif 000011
【図１０】
2014127956.tif 000012
【図１１】
2014127956.tif 000013
【図１２】
2014127956.tif 000014