JP4364210B2 - 無線通信装置 - Google Patents

無線通信装置 Download PDF

Info

Publication number
JP4364210B2
JP4364210B2 JP2006127110A JP2006127110A JP4364210B2 JP 4364210 B2 JP4364210 B2 JP 4364210B2 JP 2006127110 A JP2006127110 A JP 2006127110A JP 2006127110 A JP2006127110 A JP 2006127110A JP 4364210 B2 JP4364210 B2 JP 4364210B2
Authority
JP
Japan
Prior art keywords
frame
transmission
terminal
wireless communication
time
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2006127110A
Other languages
English (en)
Other versions
JP2006352844A5 (ja
JP2006352844A (ja
Inventor
徹 中島
朋子 足立
雅裕 高木
智哉 旦代
依子 宇都宮
寿久 鍋谷
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2006127110A priority Critical patent/JP4364210B2/ja
Publication of JP2006352844A publication Critical patent/JP2006352844A/ja
Publication of JP2006352844A5 publication Critical patent/JP2006352844A5/ja
Application granted granted Critical
Publication of JP4364210B2 publication Critical patent/JP4364210B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)

Description

本発明は、無線を介してデータの送受信を行う、例えば携帯電話や無線LAN等の無線通信機器を含む無線通信システムにおいて、劣悪な無線伝播環境でもロバストな無線通信方式を実現する方法に関する。
IEEE802.11標準規格に対して媒体アクセス制御(Medium Access Control: MAC)層のQoS (Quality of Service)に関する拡張した無線LAN規格IEEE802.11eでは、送信側通信装置(Initiator)がデータを送信することの出来る期間TXOP(transmission opportunity)期間を獲得する方法としてEDCA(enhanced distributed channel access)方式とHCCA(HCF controlled channel access)方式とがある(非特許文献1参照)。
更なる高速伝送を目指したIEEE802.11nでは、IEEE802.11eにおける送受信動作の際に各フレーム間に存在したオーバーヘッドを削減すべく、A−MPDU(Aggregated − MAC protocol data unit)、HTP(high−throughput PHY) Burstといった複数の方法が提案されている。
A−MPDUでは、複数のMAC(Medium Access Control)フレームそれぞれの先頭に各フレーム間を識別するフィールドをつけて一つのPHY(Physical Layer)フレームに結合したAggregationフレームを送信する(非特許文献2参照)。
HTP Burstでは、PHYフレーム同士を、従来のバースト伝送で使用していたSIFS(Short Interframe Space)期間よりも短縮したRIFS(Reduced Interframe Space)時間開けて送信する。HTP Burstでは、複数の受信側通信装置(Responder)それぞれへ異なる伝送レートや送信電力で送信動作を行う際には、各PHYフレームの間にRIFS間あける事によって、伝送レートや送信電力を変えて各PHYフレームを送信する事ができる(非特許文献2及び非特許文献3参照)。
また、IEEE802.11nでは、TXOP時間を獲得したInitiatorがTXOP時間の一部(TXOP分与時間)をResponderに与えて、Initiatorが獲得したTXOP時間中にピギーバック手法による双方向通信をする手法すなわちReverse Direction(RD)方式による伝送効率向上が提案されている。
IEEE802.11nにおいて、RD方式(InitiatorがEDCA方式あるいはHCCA方式で獲得したTXOP時間中にピギーバック手法でResponderとの双方向通信を行う方式)にA−MPDUを用るとすると、InitiatorがIAC(Initiator Aggregation Control)フレームを送信し、その送信後からSIFSだけ経過した後に、ResponderがRAC(Responder Aggregation Control)フレームを返信するIAC−RACフレーム交換が行われる。このようなIAC−RACフレーム交換を行うことを前提としてRD方式を採るならば、Initiatorは、獲得したTXOP時間のなかでの通信にRD方式を採用することを書き込んだIACフレームをResponder宛で送信する。IACフレームを受信してこのTXOP時間のなかでの通信にRD方式を採用することを通知されたResponderは、TXOP時間の一部を与えられた場合に自分が送信する事が出来るDataフレーム数と送信データレートを、RACフレームに書き込んで宛先をInitiatorにして送信する。Initiatorは、RACフレームに書かれたDataフレーム数と送信データレートから、Responderに対して分け与えるTXOP時間の一部としてRDG(Reverse Direction Grant) Durationを決める。Initiatorは、決定したRDG DurationをIACフレームに書き込み、送信するAggregationフレームの先頭にそれを付けて、RACフレーム受信完了後のSIFSだけ経った時点で送信する。
このとき、Dataフレームの送達確認方法(AckPolicy)がBlockAck方式であり、このBlockAck方式にはIEEE802.11eに規定されているImmediate BlockAck方式(送達確認要求フレーム(BlockAckRequestフレーム)を受信するとSIFS後に送達確認フレーム(BlockAckフレーム)を送信する方式)を使用している場合は、Initiatorから送信されるAggregationフレームの最後にBlockAckRequestフレームも結合される(ただし、IEEE802.11nで提案されているImplicit Block Ack方式ではBlockAckRequestを省略する)。
上記の場合、Responderは、InitiatorからのAggregationフレーム受信後にSIFSだけ経過した時点で、Block Ackフレームによる受信状況を送信しなければならない。RDであれば、SIFS後にBlock Ackフレームを返信する際に、ピギーバック手法を用いて、ResponderからのDataフレームをBlock AckフレームにAggregateしたAggregationフレームを送信する。このAggregationフレームの送信にかかる時間は、IACフレームに書かれたRDG Durationを越えなてはならない。ResponderがAggregationフレームを送信する際にさらにRDG Durationを要求する場合は、送信準備の出来ている(すなわち今回送信する予定の)データフレーム数と送信データレートをRACフレームに入れて、今回送信するAggregationフレームの先頭に付けて返信する(非特許文献2参照)。
IEEE 802.11e Draft 13.0、IEEE P802.11e/D13.0, January 2005. TGn Sync Proposal Technical Specification、IEEE 802.11−04/889r6, May 2005. WWiSE Proposal: High throughput extension to the 802.11 Standard, IEEE 802.11−05/0149r2, March 2005.
しかしながら、上記RD方式では、Dataフレーム群にBlockAckフレーム及びBlockAckRequestフレームを、結合して1つのPHYフレームとして送信するので、Dataフレーム群とBlockAckフレーム及びBlockAckRequestフレームとを同じ伝送レートで送信することになる。その為、無線伝播環境の悪化や衝突の発生などによる伝送エラーの確率がDataフレーム群とBlockAckフレーム及びBlockAckRequestフレームとでほぼ同じになってしまう。
一般に、高い伝送レートを用いると伝送エラーの確率が高まるので、BlockAckフレーム及びBlockAckRequestフレームの送達の確率を上げるためにはAggregationフレームの伝送レートを下げる必要がある。ただし、伝送レートを下げると、Aggregationフレームが長くなってしまい、スループットが低下してしまう。
逆にDataフレームを速く送受信するために伝送レートを上げるとBlockAckフレーム及びBlockAckRequestフレームの送達の確率が下がり、BlockAckフレームやBlockAckRequestフレームの受信に失敗したInitiatorあるいはResponderはAggregationフレームを再送することになる。これは、通信効率が極端な悪化、すなわちスループットの大幅な劣化要因となる。本発明は上記の問題を解決するためになされたものであり、BlockAckフレームやBlockAckRequestフレームなどの送達確認に使用するフレームの送信成功確率を向上させることを目的とする。
本発明の一観点に係る無線通信装置は、データ送信用の送信期間を獲得してデータ送信を行う際に、獲得した送信期間の一部を、該データ送信に係る受信側となる無線通信装置へデータ送信用として分け与えることのできる通信方式に従う無線通信装置において、受信したデータに対する送達確認フレームを含む第一の物理フレームおよび複数の送信データフレームがアグリゲートされた第二の物理フレームを生成する生成手段と、前記第一の物理フレームを第一の伝送レートで送信し、該第一の物理フレームの送信時点から一定期間が経過した後に第二の伝送レートで前記第二の物理フレームを送信する送信手段と、を具備する無線通信装置である。
本発明によれば、コントロールフレームの受信失敗によるResponderの再送依頼を抑えることと、Dataフレームの高速送信との両立が出来る。
(第1の実施の形態)
図1は、無線LAN通信規格のIEEE802.11nにて提案されている内容をサポートする無線通信装置101の一例に係るブロック図である。すなわち、IEEE802.11nにて提案されているMIMO(Multiple Input Multiple Output)方式の高速な伝送レートや、20MHz帯から40MHz帯に周波数帯域を拡張した伝送方式をサポートしているものとして以下説明する。
なお、ここで記述するIEEE802.11nにて提案されている内容には、IEEE802.11標準規格およびIEEE802.11a/b/g/eなど(amendmentやrecommended practiceなどとして位置づけられているものも含む)は全て含まれるものとする。
但し、IEEE802.11nは、あくまで本発明の一例であり、本発明が無線通信方式全般に適用出来ることは言うまでもない。
無線通信装置101は、送信データ管理部102、アクセス制御部103、フレーム生成・送信部104、受信処理部105を備える。
送信データ管理部102は、送信データをバッファする送信キュー106を備える。送信データ管理部102は送信キュー106内の送信データを管理する。
アクセス制御部103は、フレームの送受信処理や、再送処理などの、アクセス制御を行う。アクセス制御部103が扱うフレームには、送信キュー106にバッファされた送信データを含むデータ(Data)フレームが含まれる。また、送達確認フレーム(BlockAckフレームなど)や、IACフレーム、RACフレーム、RTSフレーム、CTSフレームなどのコントロールフレームや、マネジメントフレームも含まれる。アクセス制御部103は、送受信方法決定部107と送受信状態管理部108とキャリアセンス部109と備える。
送受信方法決定部107は、Aggregation方式やReverse Direction(RD)方式やRTS−CTSフレーム交換の有無などを含む送受信方法を決定する。
送受信状態管理部108は、前記データ送受信方式決定部107が決定した送受信方法に係る、送受信のタイミング管理や再送処理などのアクセス制御を行う。
キャリアセンス部109は、受信処理部105を監視し、受信したフレーム内のDurationフィールドに書かれたNAV(network allocation vector)の値が示す時間中はBusyとなるバーチャルキャリアセンス処理と、受信電力が所定の値よりも大きいときにBusyとなるキャリアセンス処理とを行う。
フレーム生成・送信処理部104は、コントロールフレームやDataフレームを生成する。またフレーム生成・送信処理部104はフレームのAggregationをして、送信処理を行う。
受信処理部105は、受信フレームの識別処理と送達確認のビットマップを作成するなどの受信処理を行う。
図2はRD方式で送受信する際にHTP Burst方式を使用して、BlockAckフレームと複数のDataフレームとを異なる伝送レートで送信する方法を説明するタイミングチャートである。また、図3は端末A201の動作に係るフローチャート、図4は端末B202の動作に係るフローチャートである。
以下説明する双方向通信では、Initiatorである端末A201からの送信データは全てResponderである端末B202宛てのデータであり、端末B202からの送信データも全て端末A201宛てのデータであるとして説明する。これら端末A201および端末B202は無線通信装置101の構成であるものとし、図1の対応する符号を用いる。
この双方向通信は図5のように、端末A201と端末B202が属している無線通信システムに端末A201及び端末B202以外にも、送信データの宛先とならない端末C203、端末D204、端末E205、端末F206も存在するものとする。
端末C203は、端末A201と端末B202との双方向通信が始まるときに、端末A201の送信波を受信できる範囲207および端末B202の送信波を受信できる範囲208の内にある。
端末D204は、端末A201と端末B202との双方向通信が始まるときに、端末A201の送信波を受信できる範囲207の内であって端末B202の送信波を受信できる範囲208の外にある。
端末E205は、端末A201と端末B202との双方向通信が始まるときに、端末A201の送信波を受信できる範囲207の外であって端末B202の送信波を受信できる範囲208の内にある。
端末F206は、端末A201と端末B202との双方向通信が始まるときには、端末A201および端末B202のの送信波を受信できず、端末A201と端末B202との双方向通信の開始後(すなわちRTS−CTS交換が完了した後)に端末A201およんび端末B202の送信波を受信できるようになるものとする。
Dataフレームの送達確認方法(AckPolicy)をIEEE802.11nで提案されているBlockAck方式のうちのImplicitBlockAck方式とする。BlockAck方式では、送信者が送信したフレームの送達確認として、受信者からBlockAckフレームを送信する。また、ImplicitBlockAck方式では、送信者がBlockAckフレームの送信要求をとしての送達確認要求フレーム(BlockAckRequestフレーム)を送信しない。
端末A201は、予めアソシエーションなどのマネジメントフレーム交換を端末B202と行い、端末B202がRD方式をサポートしていることと、端末B202が端末A201へ送信したいデータの量とを知っているものとする。
またこのマネジメントフレーム交換で、RD方式のネゴシエーションをするのであれば端末A201が最初に送信するAggregationフレーム304の次からはRIFS時間を挟んだ2つのPHYフレームを互いに送信してくることを、マネジメントフレームに書き込むことによって、端末A201と端末B202との両方が知る。その後、端末A201と端末B202との両方は、RD方式の通信における待ち受けの際にはRIFS時間を挟んだ2つのPHYフレームを待ち受けることにする。
ただし、RD方式で双方向通信を行うことがわかった時点で(すなわちマネジメントフレーム交換をするまでもなく)RIFS時間を挟んだ2つのPHYフレームを待ち受けることにするよう取り決めてあってもよい。
ただし、RD方式の通信における待ち受けの際にRIFS時間を挟んだ、3つあるいはそれ以上のPHYフレームを待ち受けることにするよう決めてもよい。
あるいは端末A201が基地局としての動作を行う場合は、端末A201から送信するBeaconフレームに、RD方式をするのであれば端末A201が最初のAggregationフレーム304の次からはRIFS時間を挟んだ2つのPHYフレームを送信することを書き込むことにしてもよい。
(1−1−1.端末AのRTSフレーム送信)
端末A201では双方向通信を開始するに先立って送信キュー106にデータが蓄積されると、送信データ管理部102は送受信状態管理部108に、蓄積された送信データの優先度と量と送信宛先とを渡す(図3のステップ1)。
送信状態管理部108は、受け取った送信データの優先度について、キャリアセンス部109に送信可能か否かを問い合わせる。キャリアセンス部109は受信電力が一定値以上である(Idle)か否(Busy)か監視している(キャリアセンス処理)。またキャリアセンス部109は送信帯域の予約がなされているか否かを監視する(バーチャルキャリアセンス処理)。送信状態管理部108は、キャリアセンス部109のキャリアセンスとバーチャルキャリアセンスとの結果が共にIdleで送信帯域の予約がなされていない期間が、AIFS+Backoff時間(Backoffは場合によっては行わない。以下も同様。)だけ継続している場合に、送信可能であると判断する。送信可能であると判断した送信状態管理部108は、送信データの優先度と量と送信宛先とを送受信方法決定部107へ渡す(図3のステップ2)。
送受信方法決定部107では、RTSフレーム301とCTSフレーム303の交換を行うこととRD方式で双方向通信を行うことと、TXOP時間のなかで帯域予約をする時間(NAV時間)の長さ(本実施の形態ではTXOP時間と等しい)と、端末B202に分け与えるTXOP時間の一部(TXOP 分与時間)の長さとを決定する(図3のステップ3)。
ここで、NAV時間やTXOP分与時間は例えば一定の値としてもよいし、いかなる計算方法によって算出されるものであってもよい。計算方法については本願発明の趣旨ではないため説明を省略する。
送受信状態管理部108では、送受信方法決定部107で決定した事に従って、フレーム生成・送信処理部104にRTSフレーム301のDurationフィールドに書き込むNAVの値を渡す(図3のステップ4)。RTSフレーム301に書き込むNAVの値は、RD方式で使用するTXOPLimitまでの時間として扱われる。
フレーム生成・送信処理部104は、受け取ったTXOP時間の長さをNAVの値としてDurationフィールドに書き込んだRTSフレーム301を生成し、第1の伝送レートで送信する(図3のステップ5)。
第1の伝送レートは例えば802.11a規格などの伝送レートもしくはベーシックレートである。あるいは802.11nにおける低いほうの伝送レートもしくはベーシックレートである。例えば、802.11nをサポートしていないが802.11aはサポートしている端末が端末A201あるいは端末B202 の送信波を受信できる位置にある場合は802.11aの伝送レートとする。逆に、端末A201あるいは端末B202 の送信波を受信できる位置に802.11nをサポートしている端末しかない場合は802.11nの低いほうの伝送レートもしくはベーシックレートとする。または802.11nをサポートしていない端末が存在するが802.11nをサポートしていない端末には既に帯域予約がなされている場合は、802.11nの低いほうの伝送レートもしくはベーシックレートとする。端末A201が送信した端末B202宛のRTSフレーム301は端末C203および端末D204にも受信される。端末C203および端末D204は、受信したRTSフレーム301の宛先が端末B202であることがわかると、その送信帯域を用いての通信をNAV時間だけ行わないようにする。その結果、端末A201にとっては送信帯域の予約ができたことになる。
RTSフレーム301の送信が済むと、受信処理部105はSIFS時間に加えて1slot分の時間だけ端末B202からのCTSフレーム303を待ち受ける。もしSIFS時間に1slot分の時間を加えた時間内にCTSフレーム303を受信開始できなかったら、RTSフレーム301を再送するためのBackoff処理を開始する(図3のステップ6)
(1−1−2.端末BのRTSフレーム受信とCTSフレーム送信)
端末B202の受信処理部105は、RTSフレーム301を受信し、それが完了してからSIFS時間後にCTSフレーム303を第1の伝送レートで送信する(図4のステップ101)。CTSフレーム303にはNAVの値として、RTSフレーム301に書かれたNAVの値からSIFS時間とCTSフレーム303の送信にかかる時間を差し引いた値が書き込まれている(各フレーム単体の長さは予めわかっており、送信レートも決めているので、送信にかかる時間もわかる)。これらRTSフレーム301とCTSフレーム303は、既存の規格であるIEEE802.11の通常のRTS−CTS交換と同様の為、この時点では端末B202は、端末A201がRD方式を使用する事を知らない。
CTSフレーム303の送信が済むと、受信処理部105はDataフレームを受信するまで待ち受ける(図4のステップ102)。
端末B202が送信した端末A201宛のCTSフレーム303は端末E205にも受信される。端末E205は、受信したCTSフレーム303の宛先が端末A201であることがわかると、その送信帯域を用いての通信を、CTSフレーム303に書き込まれたNAVの値だけ行わないようにする。その結果、端末A201にとっては送信帯域の予約ができたことになる。
(1−1−3.端末AのCTSフレーム受信とAggregationフレーム送信)
端末A201では、端末B202からのCTSフレーム303を受信処理部105が受信すると、CTSフレーム303を受信したことを表す値と、CTSフレーム303に書かれたNAVの値とを、送受信状態管理部108に渡す(図3のステップ7)。
送受信状態管理部108は、送信キュー106にバッファされた送信データを取り出し、送受信方法決定部107が決定したTXOP 分与時間と共に、フレーム生成・送信処理部104へ渡す(図3のステップ8)。
フレーム生成・送信処理部104では、送信データから、QoS Cf−Poll+DataフレームとしてData1−A305を、Dataフレームとして Data2−A306, Data3−A307, Data4−A308を、それぞれ作成する。またこれらのフレームを、Data1−A305を先頭として、Data1−A305, Data2−A306, Data3−A307, Data4−A308の順にそれぞれの先頭に各フレーム間を識別するフィールドをつけて結合したAggregationフレーム304を作成する(図3のステップ9)。
QoS Cf−Poll+DataフレームであるData1−A305のQoS ControlフィールドにはTXOP 分与時間が書き込まれる。本実施の形態ではこのTXOP分与時間は、RIFS時間と、後述するAggregatioin frame311の送信にかかる時間と、SIFS時間と、Aggregatioin frame311に対するBlockAckフレーム317の送信にかかる時間とを足し合わせた値である。Data1−A305, Data2−A306, Data3−A307, Data4−A308それぞれには、端末B202が送信したCTSフレーム303に書かれていたNAVの値から、SIFS時間と、Aggregationフレーム304の送信にかかる時間とを差し引いた値がNAVの値として書き込まれる。このNAVの値はすなわち、Aggregationフレーム304の送信完了からNAV時間の終わりの時刻までの長さを示す値となる。
フレーム生成・送信処理部104は、端末B202のCTSフレーム303を受信処理部105が受信完了してからSIFS時間後に、Aggregationフレーム304の送信を開始する(図3のステップ10)。この送信は、第1の伝送レートよりも高い第2の伝送レートで行われる。この第2の伝送レートは例えば802.11n規格の高いほうの伝送レート、例えばMIMOによる高いレートである。
Aggregationフレーム304の送信が済むと、受信処理部105はSIFS時間に加えて1slot分の時間だけ端末B202からのBlockAckフレーム310を待ち受ける。もしSIFS時間に1slot分の時間を加えた時間内にBlockAckフレーム310を受信できなかったら、Aggregationフレーム304を再送する(図3のステップ11)。
ここで、端末A201は自らがRD方式を使用することを知っているので、このあとの待ち受けにおいて、受信処理部105にRIFS時間を挟んだ2つのPHYフレームを待ち受けさせる。
(1−1−4.端末BのAggregationフレーム受信とHTP Burstフレーム送信)
Aggregationフレーム304を受信した端末B202の受信処理部105は、QoS Cf−Poll+Dataフレームを受信したことを表す値と、Data1−A305内に書かれたTXOP分与時間と、Data1−A305, Data2−A306, Data3−A307, Data4−A308それぞれに書かれたNAVの値とを、送受信状態管理部108に渡す。また、受信処理部105は、端末A201から送信されたData1−B312,Data2−B313, Data3−B314, Data4−B315の受信成否状況から、送達確認を相手に通知するBitmapを作成し、送受信状態管理部108に渡す。(図4のステップ103)。
端末B202は、TXOP分与時間を与えられたことを通知するPollフレームとしての機能も持ったQoS Cf−Poll+Dataフレームを受信した時点ではじめて、端末A201がRD方式を使用することを知る。RD方式を使用することを知った端末B202は、TXOP分与時間のなかで端末A201へ送信したい送信データをDataフレームにして送信する。
端末A201がRD方式を使用することを知った端末B202は、このあとの待ち受けにおいて、受信処理部105にRIFS時間を挟んだ2つのPHYフレームを待ち受けさせる。
送受信状態管理部108は、QoS Cf−Poll+Dataフレームを受信したことを表す値から、端末A201がRD方式で通信していると判断する。そして送受信状態管理部108は、送信キュー106にバッファされた送信データを取り出し、TXOP分与時間と、受信処理部105から受け取ったNAVの値と送達確認を相手に通知するBitmapと共に、フレーム生成・送信処理部104へ渡す(図4のステップ104)。送信キュー106から取り出す送信データの量については後述する。
フレーム生成・送信処理部104は送達確認を相手に通知するBitmapを用いて、端末A201から送信されたData1−A305, Data2−A306, Data3−A307, Data4−A308に対する送達確認(BlockAck)フレーム310を作成する。またフレーム生成・送信処理部104は、送信データからDataフレームとしてData1−B312, Data2−B313, Data3−B314, Data4−B315を作成する。Data1−B312, Data2−B313, Data3−B314, Data4−B315を結合してAggregationフレーム311を作成する。
ここでフレーム生成・送信処理部104は、受け取ったNAVの値からSIFS時間とBlockAckフレーム310の送信にかかる時間とを差し引いた値を、BlockAckフレーム310にNAVの値として書き込む。このNAVの値はすなわち、このBlockAckフレーム310の送信完了からNAV時間の終わりの時刻までの長さを示す値となる。
フレーム生成・送信処理部104は、 BlockAckフレーム310に書き込んだNAVの値からRIFS時間とAggregationフレーム311を送信にかかる時間とを差し引いた値を、Data1−B312, Data2−B313, Data3−B314, Data4−B315にNAVの値として書き込む。このNAVの値はすなわち、Aggregationフレーム311の送信完了からNAV時間の終わりの時刻までの長さを示す値となる。(図4のステップ105)。
以下、BlockAckフレームとAggregationフレームとの間にRIFS時間を挟んだものを、HTP Burst フレームと呼ぶ(詳しくは第10の実施の形態にて述べる)。送受信状態管理部108が送信キュー106から取り出してフレーム生成・送信処理部104に渡す送信データの量は、HTP Burstフレーム351のフレーム長が、Data1−A305に書き込まれていたTXOP 分与時間を超えない量とする。フレーム生成・送信処理部104は、端末A201から送信されたAggregationフレーム304を受信処理部105が受信完了してからSIFS時間後に、作成したHTP Burstフレーム351の送信を開始する。
HTP Burstフレーム351の送信について詳述する。まずBlockAckフレーム310の送信を開始する(図4のステップ106)。BlockAckフレーム310の送信の伝送レートを第1の伝送レートとする。
フレーム生成・送信処理部104は、BlockAckフレーム310の送信を完了した後にRIFS時間だけ、Aggregationフレーム311の送信を開始するのを待つ(図4のステップ107)。この間にフレーム生成・送信処理部104は、伝送レートを第1の伝送レートから第2の伝送レートに変更する。
フレーム生成・送信処理部104は、BlockAckフレーム310の送信を完了した後にRIFS時間だけ経つと、第2の伝送レートで、Aggregationフレーム311を送信する(図4のステップ108)。
Aggregationフレーム311の送信が済むと、受信処理部105は端末A201からのフレームを待ち受ける(図4のステップ109)。
(1−1−5.端末AのHTP Burstフレーム受信とHTP Burstフレーム送信)
HTP Burstフレームを受信したときに、端末B202へ送信したいデータが送信キュー106に蓄積されている場合の端末A201の動作について説明する。
HTP Burstフレーム351を受信した端末A201の受信処理部105は、Data1−B312, Data2−B313, Data3−B314, Data4−B315の受信成否状況から、送達確認を示す送達確認を相手に通知するBitmapを生成し、Data1−B312, Data2−B313, Data3−B314, Data4−B315それぞれに書かれたNAVの値と共に送受信状態管理部108に渡す。また受信処理部105は、BlockAckフレーム310に書き込まれた、受信したBitmapも送受信状態管理部108に渡す(図3のステップ12)。
送受信状態管理部108は、受信したBitmapにData1−A305,Data2−A306, Data3−A307, Data4−A308それぞれの不送達を示す値が書き込まれている場合はそのDataフレームを再送すべく、後述するAggregationフレーム318に入れる。また送受信状態管理部108は、送信キュー106にバッファされた送信データを取り出し、送受信方法決定部107から受け取ったTXOP 分与時間と受信処理部105から受け取ったNAVの値と送信Bitmapと共に、フレーム生成・送信処理部104へ渡す(図3のステップ13)。
フレーム生成・送信処理部104は受け取った送信Bitmapを用いて、端末B202から送信されたData1−B312, Data2−B313, Data3−B314, Data4−B315に対するBlockAckフレーム317を作成する。またフレーム生成・送信処理部104は、送信データからQoS Cf−Poll+DataフレームとしてのData5−A319と、DataフレームとしてのData5−A319, Data6−A320, Data7−A321, Data8−A322のAggregationフレーム318を作成する。ただし、再送するDataフレームがある場合は、ここで作成する新規のDataフレームの前に再送するDataフレームをつける。ただし再送するDataフレームの数が多い場合、新規のDataフレームの数を減らすか、新規のDataフレームをつけないようにする。ここでフレーム生成・送信処理部104は、受信処理部105から受け取ったNAVの値からSIFS時間とBlockAckフレーム317の送信にかかる時間とを差し引いた値を、BlockAckフレーム317にNAVの値として書き込む。このNAVの値はすなわち、このBlockAckフレーム317の送信完了からNAV時間の終わりの時刻までの長さを示す値となる。
フレーム生成・送信処理部104は、QoS Cf−Poll+DataフレームであるData1−A305にはTXOP 分与時間を書き込む。
フレーム生成・送信処理部104は、BlockAckフレーム317に書き込んだNAVの値からRIFS時間とAggregationフレーム318を送信にかかる時間とを差し引いた値を、Data5−A319, Data6−A320, Data7−A321, Data8−A322にNAVの値として書き込む。このNAVの値はすなわち、Aggregationフレーム318の送信完了からNAV時間の終わりの時刻までの長さを示す値となる(図3のステップ14)。フレーム生成・送信処理部104は、端末B202から送信されたHTP Burstフレーム351を受信処理部105が受信完了してからSIFS時間後に、作成したHTP Burstフレーム352の送信を開始する。
HTP Burstフレーム352の送信について詳述する。まずBlockAckフレーム317の送信を開始する(図3のステップ15)。BlockAckフレーム317の送信の伝送レートを第1の伝送レートとする。
フレーム生成・送信処理部104は、BlockAckフレーム317の送信を完了した後にRIFS時間だけ、Aggregationフレーム318の送信を開始するのを待つ(図3のステップ16)。この間にフレーム生成・送信処理部104は、伝送レートを第1の伝送レートから第2の伝送レートに変更する。
フレーム生成・送信処理部104は、BlockAckフレーム317の送信を完了した後にRIFS時間だけ経つと、第2の伝送レートで、Aggregationフレーム318を送信する(図3のステップ17)。
端末F206は端末A201が送信したRTSフレーム301や端末B202が送信したCTSフレーム303は、それらが送信されたときに受信できる状態でなかったので受信できなかったが、通信を受信できるようになったあとでいずれかのBlockAckフレームあるいはAggregationフレームを受信することで、その中に書き込まれたNAVの値を知り、そのNAVの値の時間だけはその送信帯域を用いての通信を行わないようにする。その結果、端末A201にとっては送信帯域の予約が端末F206に対してもできたことになる。
また端末F206が802.11nをサポートしておらずAggregationフレームの受信やMIMOによる高い伝送レートで送信されるフレームを受信できなくても、Dataフレームに先立って、端末F206も受信できる第1の伝送レートでBlockAckフレーム317が送信される為、端末F206はAggregation ftrame318として送られてくるDataフレームを受信する前にBlockAckフレーム317よってその宛先とNAVの値を知ることができる。端末F206はこの宛先とNAVの値を知ることで、その後に送られてくるDataフレームを受信できない場合であっても、帯域予約されていることおよびその長さを知ることができる。
HTP Burstフレーム352の送信が済むと、受信処理部105はSIFS時間に加えて1slot分の時間だけ端末A201からのBlockAckフレーム324を待ち受ける。もしSIFS時間に1slot分の時間を加えた時間内にBlockAckフレーム324を受信できなかったらHTP Burstフレーム352を再送する(図3のステップ18)。
(1−1−6.端末BのHTP Burstフレーム受信とHTP Burstフレーム送信)
RIFS時間を挟んだ2つのPHYフレーム、すなわちHTP Burstフレーム352を受信した端末B202の受信処理部105は、Data5−A319, Data6−A320, Data7−A321, Data8−A322の受信成否状況から、送達確認を示す、送達確認を相手に通知するBitmapを生成する。受信処理部105は、QoS Cf−Poll+Dataフレームを受信したことを表す値と、Data5−A319内に書かれたTXOP 分与時間と、Data5−A319, Data6−A320, Data7−A321, Data8−A322それぞれに書かれたNAVの値と、送達確認を相手に通知するBitmapと、BlockAckフレーム317に書き込まれ受信したBitmapとを、送受信状態管理部108に渡す(図4のステップ110)。
送受信状態管理部108は、受信したBitmapにData1−B312,Data2−B313, Data3−B314, Data4−B315それぞれの不送達を示す値が書き込まれている場合はそのDataフレームを再送すべく、後述するAggregationフレーム325に入れる。また送受信状態管理部108は、送信キュー106にバッファされた送信データを取り出し、受信処理部105から受け取ったNAVの値と、送達確認を相手に通知するBitmapと共に、フレーム生成・送信処理部104へ渡す(図4のステップ111)。送信キュー106から取り出す送信データの量については後述する。
フレーム生成・送信処理部104は送達確認を相手に通知するBitmapを用いて、端末A201から送信されたData5−A319, Data6−A320, Data7−A321, Data8−A322に対するBlockAckフレーム324を作成する。
またフレーム生成・送信処理部104は、送信データからDataフレームとしてData5−B326, Data6−B327, Data7−B328, Data8−B329を作成する。Data5−B326, Data6−B327, Data7−B328, Data8−B329を結合してAggregationフレーム325を作成する(図4のステップ112)。
ここでフレーム生成・送信処理部104は、受け取ったNAVの値からSIFS時間とBlockAckフレーム324の送信にかかる時間とを差し引いた値を、BlockAckフレーム324にNAVの値として書き込む。このNAVの値はすなわち、このBlockAckフレーム324の送信完了からNAV時間の終わりの時刻までの長さを示す値となる。
またフレーム生成・送信処理部104は、BlockAckフレーム324に書き込んだNAVの値からRIFS時間とAggregationフレーム325を送信にかかる時間とを差し引いた値を、Data5−B326, Data6−B327, Data7−B328, Data8−B329にNAVの値として書き込む。このNAVの値はすなわち、Aggregationフレーム325の送信完了からNAV時間の終わりの時刻までの長さを示す値となる。送受信状態管理部108が送信キュー106から取り出してフレーム生成・送信処理部104に渡す送信データの量は、BlockAckフレーム324とAggregationフレーム325との間にRIFS時間を挟んだHTP Burstフレームのフレーム長が、QoS Cf−Poll+DataフレームであるData5−A319に書き込まれていたTXOP 分与時間を超えない量とする。ただし、再送すべきDataフレームがある場合は、ここで作成するDataフレームの数をその分だけ減らす。つまり、送受信状態管理部108が送信キュー106から取り出してフレーム生成・送信処理部104に渡す送信データの量は、BlockAckフレーム324とRIFS時間とAggregationフレーム325とで形成するHTP Burstフレーム353のフレーム長がTXOP 分与時間を超えない量とする。
フレーム生成・送信処理部104は、端末A201から送信されたHTP Burstフレームを受信処理部105が受信完了してからSIFS時間後に、作成したHTP Burstフレーム353の送信を開始する。
HTP Burstフレーム353の送信について詳述する。まずBlockAckフレーム324の送信を開始する(図4のステップ113)。BlockAckフレーム324の送信の伝送レートを第1の伝送レートとする。
フレーム生成・送信処理部104は、BlockAckフレーム324の送信を完了した後にRIFS時間だけ、Aggregationフレーム325の送信を開始するのを待つ(図4のステップ114)。この間にフレーム生成・送信処理部104は、伝送レートを第1の伝送レートから第2の伝送レートに変更する。
フレーム生成・送信処理部104は、BlockAckフレーム324の送信を完了した後にRIFS時間だけ経つと、第2の伝送レートで、Aggregationフレーム325を送信する(図4のステップ115)。
HTP Burstフレーム353の送信が済むと、受信処理部105は端末A201からのフレームを待ち受ける(図4のステップ116)。
(1−1−7.端末AのHTP Burstフレーム受信とBlockAckフレーム送信)
HTP Burstフレーム353を受信したときに、端末B202へ送信したいデータが送信キュー106になく、再送するDataフレームもない場合、あるいTXOP時間の終了間際でこれ以上送信を継続できない場合のNAV時間の終了における端末A201の動作について説明する。
RIFS時間を挟んだ2つのPHYフレーム、すなわちHTP Burstフレーム353を受信した端末A201の受信処理部105は、Data5−B326, Data6−B327, Data7−B328, Data8−B329の受信成否状況から、送達確認を示すBitmapを生成し、Data5−B326, Data6−B327, Data7−B328, Data8−B329それぞれに書かれたNAVの値と共に送受信状態管理部108に渡す。また受信処理部105は、BlockAckフレーム324に書き込まれた、受信したBitmapも送受信状態管理部108に渡す(図3のステップ19)。
送受信状態管理部108は、受信したBitmapから、Data5−A319,Data6−A320, Data7−A321, Data8−A322それぞれの送達成否を確認する。また送受信状態管理部108は、受信処理部105から受け取ったNAVの値をフレーム生成・送信処理部104へ渡す(図3のステップ20)。
フレーム生成・送信処理部104は受け取ったBitmapを用いて、端末B202から送信されたData5−B326, Data6−B327, Data7−B328, Data8−B329に対するBlockAckフレーム331を作成する。
ここでフレーム生成・送信処理部104は、受信処理部105から受け取ったNAVの値からSIFS時間とBlockAckフレーム331の送信にかかる時間とを差し引いた値を、BlockAckフレーム331にNAVの値として書き込む。このNAVの値はすなわち、このBlockAckフレーム331の送信完了からNAV時間の終わりの時刻までの長さを示す値となる。(図3のステップ21)。
フレーム生成・送信処理部104は、端末A201から送信されたHTP Burstフレーム353を受信処理部105が受信完了してからSIFS時間後に、作成したBlockAckフレーム331の送信を開始する(図3のステップ22)。BlockAckフレーム331の送信の伝送レートは第1の伝送レートとする。
(1−1−8.TXOP時間の終了)
BlockAckフレーム331の送信終了時刻から、端末A201が送信したBlockAckフレーム331に書き込んだNAVの値だけ時間が経過すると帯域予約が解かれて端末A201と端末B202との双方向通信が終了する。この双方向通信が終了すると、端末A201と端末B202それぞれの受信処理部105は、RIFS時間を挟んだ2つのPHYフレームを待ち受けるのをやめ、通常の待ち受け状態になる。さらにこの双方向通信を行いたい場合は帯域予約が解かれてからAIFS+Backoff 時間だけ経過した後、1−1−1の手順から再度行う。あるいは他の端末と本実施の形態のような双方向通信もしくは通常の通信を行いたい場合は、帯域予約が解かれてからAIFS+Backoff 時間だけ経過した後、他の端末を端末B202として1−1−1の手順から再度行う。
以上のように、本実施の形態では、コントロールフレームを低い伝送レートで送信しDataフレームを高い伝送レートで送信する。
低い伝送レートで送信するとノイズ等による伝送エラーの発生を抑えられる。逆に、高い伝送レートで送信すれば高速な送信が可能となる。
本発明によれば、コントロールフレームの受信失敗によるResponderの再送依頼を抑えることと、Dataフレームの高速送信との両立が出来る。
なお、本実施の形態の端末A201および端末B202が、データを送信する周波数帯域として、従来のIEEE802.11a/b/gなどで利用されている20MHz帯域の周波数帯域ではなく、IEEE802.11nで提案されているような2つの20MHz帯域の周波数を束ねた40MHz帯域の周波数帯を使用する場合に、通常の送信データを40MHz帯域の周波数帯域で送信し、RTSフレーム301やCTSフレーム303やBlockAckフレーム305、310、317、324、331などのNAVの値が書き込まれたフレームを、アナログ部の周波数帯域を40MHz帯域としたまま、デジタル処理部のPHYレイヤーにて送信周波数帯域を20MHz帯域に切り替えて、20MHz帯域のフレームとして送信する事により、IEEE802.11a/b/gなどの20MHz帯域のみを使用する端末に対してNAVの値を通知する事ができる。
20MHz帯域のみを使用する端末が存在しないか、20MHz帯域のみを使用する端末に対して既にNAVが張られている場合など、コントロールフレームで20MHz帯域を使用する無線通信装置に対するNAVを通知する必要がない場合は、BlockAckフレームを40MHz帯域での低い伝送レートに下げる事により、BlockAckフレームが無線通信システム内の全ての端末へ到達する可能性を高くすることが出来る。 また、本実施の形態では端末A201からRTSフレーム301を送信して端末B202からCTSフレーム303を送信するRTS−CTSフレーム交換によってNAVの値を通知するものとして説明した。しかしNAVの値の通知方法はこれに限るものではない。いわゆるIAC−RACフレーム交換や、CTS−selfフレームを送信したSIFS時間だけ後にAggregationフレームを送信する方法などにおいても、本実施の形態のようなHTP Burstフレームを送信することが可能であることはいうまでもない。
または、HCCA方式による通信のように基地局からHCCA時間のNAVによる帯域予約がなされている場合は、RTS−CTSフレーム交換などを行わずにAggregationフレームの送信からRD方式を開始してもよい。
また、本実施の形態ではQoS Cf−Poll+DataフレームにTXOP 分与時間を書き込むとして説明したが、QoS Cf−Poll フレームとDataフレームとを分け、QoS Cf−Poll フレームのQoS ControlフィールドにTXOP 分与時間を書き込む構成としてもよい。
また、本実施の形態では端末A201と端末B202との双方向通信であるとして説明したが、端末A201や端末B202が基地局であっても端末局であっても何ら問題はない。ただし、端末A201が基地局である場合は、予約されていた送信帯域が解放された後にRTSフレームの送信をしようとする場合、解放から、AIFS+Backoff時間ででアクセスを開始するEDCA方式によるアクセスを行ってもよい。あるいは、PIFS時間だけ経過した後にRTSフレームやQoS Cf−PollフレームやDataフレームの送信を行うHCCA方式によるアクセスを行ってもよい。
(第1の実施の形態の変形例1)
第1の実施の形態では、端末A201がQoS Cf−Poll+DataフレームにTXOP 分与時間を書き込んでいた。すなわち、端末A201がTXOP 分与時間を端末B202に通知した。端末B202は与えられたTXOP分与時間を越えない量の送信データを送信していた。
しかし端末B202がTXOP分与時間に関係なく送りたいだけ送信データを送信するよう構成してもよい。
その場合、端末A201がQoS Cf−Poll+DataフレームにTXOP 分与時間を書き込む必要がない。図4のステップ105やステップ112において、送受信状態管理部108が送信キュー106から取り出してフレーム生成・送信処理部104に渡す送信データの量を任意にすればよい。
このようにしても、端末B202が送信するBlockAckフレームのあとRIFS時間を挟んで送られてくるAggregationフレームの長短が変わるだけなので、端末A201は問題なく受信することができる。以上のようにした結果、端末A201はTXOP分与時間を計算する必要がなくなる。
(第1の実施の形態の変形例2)
図6は、本変形例に係る無線通信装置2101の一例に係るブロック図である。図7は端末A1201の動作に係るフローチャート、図8は端末B1202の動作に係るフローチャートである。
第1の実施の形態では、端末A1201および端末B1202は共に、相手から受信したコントロールフレームあるいはDataフレームに書かれたNAVの値から、自らのフレームの送信とSIFS時間と相手が次に送信するBlockAckフレームの送信にかかる時間にかかる時間を差し引いた値を自らが送信するフレームに書き込むNAVの値とするものとして説明した。
本変形例は、タイマー110でカウントするNAV時間の終了までの残り時間から、自らのフレームの送信とSIFS時間と相手が次に送信するBlockAckフレームの送信にかかる時間にかかる時間を差し引いた値を自らが送信するフレームに書き込むNAVの値とする構成について説明する。
端末A1201および端末B1202は、次に説明する無線通信装置1101の構成であるものとする。
無線通信装置1101は、図1に示した無線通信装置101の構成に加えて、タイマー110を備える。タイマー110は送受信状態管理部 108に、ある時刻までの残り時間情報を提供する。
その他の構成は図1の無線通信装置101と同様である。
(1−3−1.端末AのRTSフレーム送信)
図7のステップ1001からステップ1004までは図3のステップ1からステップ4までと同様である。
フレーム生成・送信処理部104は、受け取ったTXOP時間の長さをNAVの値としてDurationフィールドに書き込んだRTSフレーム301を生成し、第1の伝送レートで送信する。RTSフレーム301の送信を開始するとき、タイマー110はNAVの値を初期値としてカウントダウンを開始する。(図7のステップ1005)。
この後に続くステップ1006は図3のステップ6と同様である。
(1−3−2.端末BのRTSフレーム受信とCTSフレーム送信)
端末B1202のタイマー110は、受信処理部105が受信したRTSフレーム301のNAVの値を初期値としてカウントダウンを開始する。
また受信処理部105は、RTSフレーム301の受信完了からSIFS時間後にCTSフレーム303を第1の伝送レートで送信する(図8のステップ1101)。またCTSフレーム303にはNAVの値として、タイマー110でカウントするNAV時間の終了までの残り時間から、SIFS時間とCTSフレーム303を送信にかかる時間を差し引いた値が書き込まれている。
この後に続くステップ1102は図4のステップ102と同様である。
(1−3−3.端末AのCTSフレーム受信とAggregationフレーム送信)
端末A1201では、端末B1202からのCTSフレーム303を受信処理部105が受信すると、CTSフレーム303を受信したことを表す値を送受信状態管理部108に渡す(図7のステップ1007)。
この後に続くステップ2008は図3のステップ8と同様である。
フレーム生成・送信処理部104では、送信データから、QoS Cf−Poll+DataフレームとしてData1−A305を、Dataフレームとして Data2−A306, Data3−A307, Data4−A308を、それぞれ作成する。またこれらのフレームを、Data1−A305を先頭として、Data1−A305, Data2−A306, Data3−A307, Data4−A308の順にそれぞれの先頭に各フレーム間を識別するフィールドをつけて結合したAggregationフレーム304を作成する(図7のステップ1009)。
QoS Cf−Poll+DataフレームであるData1−A305にはTXOP 分与時間が書き込まれる。Data1−A305, Data2−A306, Data3−A307, Data4−A308それぞれには、タイマー110でカウントするNAV時間の終了までの残り時間から、SIFS時間と、Aggregationフレーム304の送信にかかる時間とを差し引いた値がNAVの値として書き込まれる。
この後に続くステップ1010からステップ1011までは図3のステップ10からステップ11までと同様である。
(1−3−4.端末BのAggregationフレーム受信とHTP Burstフレーム送信)
Aggregationフレーム304を受信した端末B1202の受信処理部105は、QoS Cf−Poll+Dataフレームを受信したことを表す値と、Data1−A305内に書かれたTXOP 分与時間とを、送受信状態管理部108に渡す。また、受信処理部105は、端末A1201から送信されたData1−B312,Data2−B313, Data3−B314, Data4−B315の受信成否状況から、送達確認を相手に通知するためのBitmapを作成し、送受信状態管理部108に渡す。(図8のステップ1103)。
送受信状態管理部108は、QoS Cf−Poll+Dataフレームを受信したことを表す値から、端末A2201がRD方式で通信していると判断する。そして送受信状態管理部2108は、送信キュー106にバッファされた送信データを取り出し、TXOP 分与時間とBitmapと共に、フレーム生成・送信処理部104へ渡す(図8のステップ1104)。
フレーム生成・送信処理部104はBitmapを用いて、端末A1201から送信されたData1−A305, Data2−A306, Data3−A307, Data4−A308に対するBlockAckフレーム310を作成する。またフレーム生成・送信処理部104は、送信データからDataフレームとしてData1−B312, Data2−B313, Data3−B314, Data4−B315を作成する。Data1−B312, Data2−B313, Data3−B314, Data4−B315を結合してAggregationフレーム311を作成する。
ここでフレーム生成・送信処理部104は、タイマー110でカウントするNAV時間の終了までの残り時間から、SIFS時間とBlockAckフレーム310の送信にかかる時間とを差し引いた値を、BlockAckフレーム310にNAVの値として書き込む。このNAVの値はすなわち、このBlockAckフレーム310の送信完了からNAV時間の終わりの時刻までの長さを示す値となる。
さらにフレーム生成・送信処理部104は、BlockAckフレーム310に書き込んだNAVの値から、RIFS時間とAggregationフレーム311を送信にかかる時間とを差し引いた値を、Data1−B312, Data2−B313, Data3−B314, Data4−B315にNAVの値として書き込む(図8のステップ1105)。
この後に続くステップ1106からステップ1109までは図4のステップ106からステップ109までと同様である。
(1−3−5.端末AのHTP Burstフレーム受信とHTP Burstフレーム送信)
HTP Burstフレーム351を受信した端末A1201の受信処理部105は、Data1−B312, Data2−B313, Data3−B314, Data4−B315の受信成否状況から、送達確認を示すBitmapを生成して送受信状態管理部108に渡す。(図7のステップ1012)。
送受信状態管理部108は、送信キュー106にバッファされた送信データを取り出し、送受信方法決定部107から受け取ったTXOP 分与時間と受信処理部105から受け取ったBitmapと共に、フレーム生成・送信処理部104へ渡す(図7のステップ1013)。
フレーム生成・送信処理部104は受け取ったBitmapを用いて、端末B1202から送信されたData1−B312, Data2−B313, Data3−B314, Data4−B315に対するBlockAckフレーム317を作成する。またフレーム生成・送信処理部104は、送信データからQoS Cf−Poll+DataフレームとしてのData5−A319と、DataフレームとしてのData5−A319, Data6−A320, Data7−A321, Data8−A322のAggregationフレーム318を作成する。
ここでフレーム生成・送信処理部104は、タイマー110でカウントするNAV時間の終了までの残り時間から、SIFS時間とBlockAckフレーム317の送信にかかる時間とを差し引いた値を、BlockAckフレーム317にNAVの値として書き込む。フレーム生成・送信処理部104は、QoS Cf−Poll+DataフレームであるData1−A305にはTXOP 分与時間を書き込む。フレーム生成・送信処理部104は、BlockAckフレーム317に書き込んだNAVの値からRIFS時間とAggregationフレーム318を送信にかかる時間とを差し引いた値を、Data5−A319, Data6−A320, Data7−A321, Data8−A322にNAVの値として書き込む。(図7のステップ1014)。
この後に続くステップ1015からステップ1018までは図3のステップ15からステップ18までと同様である。
(1−3−6.端末BのHTP Burstフレーム受信とHTP Burstフレーム送信)
RIFS時間を挟んだ2つのPHYフレーム、すなわちHTP Burstフレーム352を受信した端末B2202の受信処理部105は、Data5−A319, Data6−A320, Data7−A321, Data8−A322の受信成否状況から、送達確認を示すBitmapを生成する。受信処理部105は、QoS Cf−Poll+Dataフレームを受信したことを表す値と、作成したBitmapとを、送受信状態管理部108に渡す(図8のステップ1110)。
送受信状態管理部108は送信キュー106にバッファされた送信データを取り出し、受信処理部105から受け取ったBitmapと共に、フレーム生成・送信処理部104へ渡す(図8のステップ1111)。
フレーム生成・送信処理部104はBitmapを用いて、端末A1201から送信されたData5−A319, Data6−A320, Data7−A321, Data8−A322に対するBlockAckフレーム324を作成する。またフレーム生成・送信処理部104は、送信データからDataフレームとしてData5−B326, Data6−B327, Data7−B328, Data8−B329を作成する。Data5−B326, Data6−B327, Data7−B328, Data8−B329を結合してAggregationフレーム325を作成する。
ここでフレーム生成・送信処理部104は、タイマー110でカウントするNAV時間の終了までの残り時間から、SIFS時間とBlockAckフレーム324の送信にかかる時間とを差し引いた値を、BlockAckフレーム324にNAVの値として書き込む。
またフレーム生成・送信処理部104は、BlockAckフレーム324に書き込んだNAVの値からRIFS時間とAggregationフレーム325を送信にかかる時間とを差し引いた値を、Data5−B326, Data6−B327, Data7−B328, Data8−B329にNAVの値として書き込む(図8のステップ1112)。
この後に続くステップ1113からステップ1116までは図4のステップ113からステップ116までと同様である。
(1−3−7.端末AのHTP Burstフレーム受信とBlockAckフレーム送信)
RIFS時間を挟んだ2つのPHYフレーム、すなわちHTP Burstフレーム353を受信した端末A2201の受信処理部105は、Data1−B312, Data2−B313, Data3−B314, Data4−B315の受信成否状況から、送達確認を示すBitmapを生成して送受信状態管理部108に渡す。(図7のステップ1019)。
送受信状態管理部108は、受信処理部105から受け取ったBitmapをフレーム生成・送信処理部104へ渡す(図7のステップ1019)。
フレーム生成・送信処理部104は受け取ったBitmapを用いて、端末B1202から送信されたData5−B326, Data6−B327, Data7−B328, Data8−B329に対するBlockAckフレーム331を作成する。
ここでフレーム生成・送信処理部104は、受信処理部105から受け取ったNAVの値からSIFS時間とBlockAckフレーム331の送信にかかる時間とを差し引いた値を、BlockAckフレーム331にNAVの値として書き込む。
タイマー110でカウントするNAV時間の終了までの残り時間から、SIFS時間とBlockAckフレーム331の送信にかかる時間とを差し引いた値を、BlockAckフレーム331にNAVの値として書き込む。(図7のステップ1020)。
この後に続くステップ1021からステップ22までは図3のステップ21からステップ22までと同様である。
(1−3−8.TXOP時間の終了)
端末B1202のタイマー110のカウントダウンが終了すると帯域予約が解かれて端末A1201と端末B1202との双方向通信が終了する。さらにこの双方向通信を行いたい場合は、帯域予約が解かれてからAIFS+Backoff 時間だけ経過した後、1−1の手順から再度行う。
以上のように、タイマー110でカウントするNAV時間の終了までの残り時間から、自らのフレームの送信にかかる時間を差し引いた値を自らが送信するフレームに書き込むNAVの値とする。その結果、相手から受信したコントロールフレームあるいはDataフレームにエラーがあったとしても確実にNAV時間の終了を認識することができる。
(第1の実施の形態の変形例3)
図9は、本変形例に係る無線通信装置3101の一例に係るブロック図である。図10は端末A2201の動作に係るフローチャート、図11は端末B2202の動作に係るフローチャートである。
第1の実施の形態では、端末A2201および端末B2202は共に、相手から受信したコントロールフレームあるいはDataフレームに書かれたNAVの値から、自らのフレームの送信にかかる時間とSIFS時間と相手が次に送信するBlockAckフレームの送信にかかる時間を差し引いた値を自らが送信するフレームに書き込むNAVの値とするものとして説明した。
本変形例は、RTC(リアルタイムクロック)111が供給する時刻からNAVの値を算出する構成について説明する。具体的には、RTC111から得られる時刻情報を用いてNAV時間の終了時刻を控えておき、それから自らのフレームの送信開始時刻と、そのフレームの送信にかかる時間とSIFS時間と相手が次に送信するBlockAckフレームの送信にかかる時間を差し引いた値を、自らが送信するフレームに書き込むNAVの値とする構成について説明する。
以下説明する双方向通信では、Initiatorである端末A2201からの送信データは全てResponderである端末B2202宛てのデータであり、端末B2202からの送信データも全て端末A2201宛てのデータであるとして説明する。
これら端末A2201および端末B2202は、次に説明する無線通信装置3101の構成であるものとする。
無線通信装置3101は、図1に示した無線通信装置101の構成に加えて、RTC111を備える。RTC111は送受信状態管理部108に時刻情報を提供する。
その他の構成は図1の無線通信装置101と同様である。
(1−4−1.端末AのRTSフレーム送信)
図10のステップ2001からステップ2006までは図3のステップ1からステップ3までと同様である。
(1−4−2.端末BのRTSフレーム受信とCTSフレーム送信)
端末B2202の送受信状態管理部108は、受信処理部105が受信したRTSフレーム301のNAVの値をNAV時間の終了時刻として記憶する。また受信処理部105は、RTSフレーム301の受信完了からSIFS時間後にCTSフレーム303を第1の伝送レートで送信する(図11のステップ2101)。またCTSフレーム303にはNAVの値として、NAV時間の終了時刻からCTSフレーム303の送信完了予定時刻を差し引いた値が書き込まれている。CTSフレーム303の送信完了予定時刻は、RTC111から得る時刻とCTSフレーム303の送信にかかる時間から算出する。
この後に続くステップ2102は図4のステップ102と同様である。
(1−4−3.端末AのCTSフレーム受信とAggregationフレーム送信)
端末A2201では、端末B2202からのCTSフレーム303を受信処理部105が受信すると、CTSフレーム303を受信したことを表す値を送受信状態管理部108に渡す(図10のステップ2007)。
この後に続くステップ2008は図3のステップ8と同様である。
フレーム生成・送信処理部104では、送信データから、QoS Cf−Poll+DataフレームとしてData1−A305を、Dataフレームとして Data2−A306, Data3−A307, Data4−A308を、それぞれ作成する。またこれらのフレームを、Data1−A305を先頭として、Data1−A305, Data2−A306, Data3−A307, Data4−A308の順にそれぞれの先頭に各フレーム間を識別するフィールドをつけて結合したAggregationフレーム304を作成する。(図10のステップ2009)。QoS Cf−Poll+DataフレームであるData1−A305にはTXOP 分与時間が書き込まれる。Data1−A305, Data2−A306, Data3−A307, Data4−A308それぞれには、NAV時間の終了時刻からAggregationフレーム304の送信開始時刻とAggregationフレーム304の送信にかかる時間とを差し引いた値がNAVの値として書き込まれる。Aggregationフレーム304の送信開始時刻は、CTSフレーム303の受信完了時刻からSIFS時間後と定めてある。そのため、RTC111から得られる時刻からAggregationフレーム304の送信開始時刻を算出することができる。
この後に続くステップ2010からステップ2011までは図3のステップ10からステップ11までと同様である。
(1−4−4.端末BのAggregationフレーム受信とHTP Burstフレーム送信)
Aggregationフレーム304を受信した端末B2202の受信処理部105は、QoS Cf−Poll+Dataフレームを受信したことを表す値と、Data1−A305内に書かれたTXOP 分与時間とを、送受信状態管理部108に渡す。また、受信処理部105は、端末A2201から送信されたData1−B312,Data2−B313, Data3−B314, Data4−B315の受信成否状況から、送達確認を示すBitmapを作成し、送受信状態管理部108に渡す。(図11のステップ2103)。
送受信状態管理部108は、QoS Cf−Poll+Dataフレームを受信したことを表す値から、端末A2201がRD方式で通信していると判断する。そして送受信状態管理部2108は、送信キュー106にバッファされた送信データを取り出し、TXOP 分与時間とBitmapと共に、フレーム生成・送信処理部104へ渡す(図11のステップ2104)。
フレーム生成・送信処理部104はBitmapを用いて、端末A2201から送信されたData1−A305, Data2−A306, Data3−A307, Data4−A308に対するBlockAckフレーム310を作成する。またフレーム生成・送信処理部104は、送信データからDataフレームとしてData1−B312, Data2−B313, Data3−B314, Data4−B315を作成する。Data1−B312, Data2−B313, Data3−B314, Data4−B315を結合してAggregationフレーム311を作成する。
ここでフレーム生成・送信処理部104は、NAV時間の終了時刻からBlockAckフレーム310の送信開始時刻とBlockAckフレーム310の送信にかかる時間を差し引いた値を、BlockAckフレーム310にNAVの値として書き込む。
BlockAckフレーム310の送信開始時刻は、Aggregationフレーム304の受信完了時刻からSIFS時間後と定めてある。そのため、RTC111から得られる時刻からBlockAckフレーム310の送信開始時刻を算出することができる。
さらにフレーム生成・送信処理部104は、NAV時間の終了時刻からAggregationフレーム311の送信開始時刻とAggregationフレーム311の送信にかかる時間を差し引いた値を、Data1−B312, Data2−B313, Data3−B314, Data4−B315にNAVの値として書き込む。
Aggregationフレーム311の送信開始時刻は、Aggregationフレーム304の受信完了時刻からSIFS時間後と定めてある。そのため、RTC111から得られる時刻かららAggregationフレーム311の送信開始時刻を算出することができる(図11のステップ2105)。
この後に続くステップ2106からステップ2109までは図4のステップ106からステップ109までと同様である。
(1−4−5.端末AのHTP Burstフレーム受信とHTP Burstフレーム送信)
HTP Burstフレームを受信した端末A2201の受信処理部105は、Data1−B312, Data2−B313, Data3−B314, Data4−B315の受信成否状況から、送達確認を示すBitmapを生成して送受信状態管理部108に渡す。(図10のステップ2012)。
送受信状態管理部108は、送信キュー106にバッファされた送信データを取り出し、送受信方法決定部107から受け取ったTXOP 分与時間と受信処理部105から受け取ったBitmapと共に、フレーム生成・送信処理部104へ渡す(図10のステップ2013)。
フレーム生成・送信処理部104は受け取ったBitmapを用いて、端末B2202から送信されたData1−B312, Data2−B313, Data3−B314, Data4−B315に対するBlockAckフレーム317を作成する。またフレーム生成・送信処理部104は、送信データからQoS Cf−Poll+DataフレームとしてのData5−A319と、DataフレームとしてのData5−A319, Data6−A320, Data7−A321, Data8−A322のAggregationフレーム318を作成する。
ここでフレーム生成・送信処理部104は、NAV時間の終了時刻からBlockAckフレーム317の送信開始時刻とBlockAckフレーム317の送信にかかる時間を差し引いた値を、BlockAckフレーム317にNAVの値として書き込む。フレーム生成・送信処理部104は、QoS Cf−Poll+DataフレームであるData1−A305にはTXOP 分与時間を書き込む。BlockAckフレーム317の送信開始時刻は、Aggregationフレーム311の受信完了時刻からSIFS時間後と定めてある。そのため、RTC111から得られる時刻からBlockAckフレーム317の送信開始時刻を算出することができる。
フレーム生成・送信処理部104は、NAV時間の終了時刻からAggregationフレーム318の送信開始時刻とAggregationフレーム318の送信にかかる時間を差し引いた値を、Data5−A319, Data6−A320, Data7−A321, Data8−A322にNAVの値として書き込む。Aggregationフレーム318の送信開始時刻は、Aggregationフレーム311の受信完了時刻からSIFS時間後と定めてある。そのため、RTC111から得られる時刻からAggregationフレーム318の送信開始時刻を算出することができる(図10のステップ2014)。
この後に続くステップ2015からステップ2018までは図3のステップ15からステップ18までと同様である。
(1−4−6.端末BのHTP Burstフレーム受信とHTP Burstフレーム送信)
HTP Burstフレームを受信した端末B2202の受信処理部105は、Data5−A319, Data6−A320, Data7−A321, Data8−A322の受信成否状況から、送達確認を示すBitmapを生成する。受信処理部105は、QoS Cf−Poll+Dataフレームを受信したことを表す値と、Data5−A319内に書かれたTXOP 分与時間と、作成したBitmapとを、送受信状態管理部108に渡す(図11のステップ2110)。
送受信状態管理部108は送信キュー106にバッファされた送信データを取り出し、受信処理部105から受け取ったBitmapと共に、フレーム生成・送信処理部104へ渡す(図11のステップ2111)。
フレーム生成・送信処理部104はBitmapを用いて、端末A2201から送信されたData5−A319, Data6−A320, Data7−A321, Data8−A322に対するBlockAckフレーム324を作成する。またフレーム生成・送信処理部104は、送信データからDataフレームとしてData5−B326, Data6−B327, Data7−B328, Data8−B329を作成する。Data5−B326, Data6−B327, Data7−B328, Data8−B329を結合してAggregationフレーム325を作成する。
ここでフレーム生成・送信処理部104は、NAV時間の終了時刻からBlockAckフレーム324の送信開始時刻とBlockAckフレーム324の送信にかかる時間を差し引いた値を、BlockAckフレーム324にNAVの値として書き込む。
BlockAckフレーム324の送信開始時刻は、Aggregationフレーム318の受信完了時刻からSIFS時間後と定めてある。そのため、RTC111から得られる時刻からBlockAckフレーム324の送信開始時刻を算出することができる
またフレーム生成・送信処理部104は、NAV時間の終了時刻からAggregationフレーム325の送信開始時刻とAggregationフレーム325の送信にかかる時間を差し引いた値を、Data5−B326, Data6−B327, Data7−B328, Data8−B329にNAVの値として書き込む。Aggregationフレーム325の送信開始時刻は、Aggregationフレーム318の受信完了時刻からSIFS時間後と定めてある。そのため、RTC111から得られる時刻からAggregationフレーム325の送信開始時刻を算出することができる(図11のステップ2112)。
この後に続くステップ2113からステップ2116までは図4のステップ113からステップ116までと同様である。
(1−4−7.端末AのHTP Burstフレーム受信とBlockAckフレーム送信)
HTP Burstフレームを受信した端末A2201の受信処理部105は、Data1−B312, Data2−B313, Data3−B314, Data4−B315の受信成否状況から、送達確認を示すBitmapを生成して送受信状態管理部108に渡す。(図10のステップ2019)。
送受信状態管理部108は、受信処理部105から受け取ったBitmapをフレーム生成・送信処理部104へ渡す(図10のステップ2020)。
フレーム生成・送信処理部104は受け取ったBitmapを用いて、端末B2202から送信されたData5−B326, Data6−B327, Data7−B328, Data8−B329に対するBlockAckフレーム331を作成する。ここでフレーム生成・送信処理部104は、NAV時間の終了時刻からBlockAckフレーム331の送信開始時刻とBlockAckフレーム331の送信にかかる時間を差し引いた値を、BlockAckフレーム331にNAVの値として書き込む。BlockAckフレーム331の送信開始時刻は、Aggregationフレーム325の受信完了時刻からSIFS時間後と定めてある。そのため、RTC111から得られる時刻からBlockAckフレーム331の送信開始時刻を算出することができる(図10のステップ2021)。
この後に続くステップ2021は図3のステップ22と同様である。
(1−4−8.TXOP時間の終了)
NAV時間の終了時刻になると帯域予約が解かれて端末A2201と端末B2202との双方向通信が終了する。さらにこの双方向通信を行いたい場合は、帯域予約が解かれてからAIFS+Backoff 時間だけ経過した後、1−1の手順から再度行う。
以上のように、RTC111から得られる時刻情報を用いてNAV時間の終了時刻を控えておき、それから自らのフレームの送信開始時刻とそのフレームの送信にかかる時間を差し引いた値を、自らが送信するフレームに書き込むNAVの値とする。その結果、相手から受信したコントロールフレームあるいはDataフレームにエラーがあったとしても確実にNAV時間の終了を認識することができる。
(第1の実施の形態の変形例4)
図12は第1の実施の形態に対して、AckPolicyを、DataフレームのAggregationフレームの後ろにBAR(BlockAckRequest)フレームを接続する、BlockAckRequestとした場合のタイミングチャートである。
本変形例では、第1の実施の形態におけるAggregationフレーム3304の送信の後にRIFS時間を挟んでBARフレーム3309を送信する。フレーム生成・送信処理部104は、この間にフレーム生成・送信処理部104は伝送レートを、Aggregationフレーム3304を送信したときの第2の伝送レートから、第1の伝送レートに変更する。フレーム生成・送信処理部104は、BARフレーム3309を第1の伝送レートで送信する。
Aggregationフレーム3315158,3325を第2の伝送レートで送信した後にも、それぞれRIFS時間だけ待ってからBARフレーム3316,3323,3330を第1の伝送レートで送信する。
なお、本変形例におけるHTP Burstフレームは、それぞれのPHYフレーム同士の間にRIFS時間を挟んだ3つのPHYフレームである。すなわち本変形例において端末A3201が送信するHTP Burstフレーム3352は、図2で示したHTP Burstフレーム352の後ろにRIFS時間を挟んでBARフレーム3323を持つものである。また、端末B3201が送信するHTP Burstフレーム3351は、図2で示したHTP Burstフレーム351の後ろにRIFS時間を挟んでBARフレーム3316を持つものである。
端末B3202は、アソシエーションやマネジメントフレーム交換などによって、RD方式をするのであれば端末A201が最初のAggregationフレーム3304の次からはRIFS時間を挟んだ3つのPHYフレームを送信してくることを知っているものとする。
あるいは端末A3201が基地局としての動作を行う場合は、端末A201から送信するBeaconフレームに、RD方式をするのであれば端末A201が最初のAggregationフレーム3304の次からはRIFS時間を挟んだ3つのPHYフレームを送信することを書き込むことにしてもよい。
この場合端末A3201の受信処理部105は、図3のステップ11のあとでそれぞれのPHYフレーム同士の間にRIFS時間を挟んだ3つのPHYフレームを待ち受けるようにする。また端末B3201の受信処理部105は、図4のステップ103のあとでそれぞれのPHYフレーム同士の間にRIFS時間を挟んだ3つのPHYフレームを待ち受けるようにする。上記のように、BARフレームも含むコントロールフレームを低い伝送レートで送信し、Dataフレームを高い伝送レートで送信する。低い伝送レートで送信するとノイズ等による伝送エラーの発生を抑えられる。逆に、高い伝送レートで送信すれば高速な送信が可能となる。したがって、BARフレームを含むコントロールフレームの受信失敗によるResponderの再送依頼を抑えることと、Dataフレームの高速送信との両立が出来る。
(第2の実施の形態)
図13は本実施の形態のタイミングチャートである。なお、端末A4201は図3に示す第1の実施の形態の端末A202の動作のフローチャート、端末B4202は図4に示す第1の実施の形態の端末B202の動作のフローチャートに従って動作するものとして説明する。
第1の実施の形態では、端末A201が送信するRTSフレーム301と端末B202が送信するCTSフレーム303とに、それぞれの送信完了から端末A201が開始したRD方式のTXOP期間が終了するまでの長さをNAVの値として書き込むものとして説明した。
本実施の形態は、送信者のRTSフレームに書き込むNAVの値を、送信者が送信する最初のAggregationフレームと、それに対して受信者が返信するBlockAckフレームの送信完了までの値とする。また、どちらかがBlockAckフレームを送信してこのBlockAckフレームのRIFS時間だけ後にDataフレームのAggregationフレームを送信して、このAggregationフレームに対するBlockAckフレームを受信する度にそのBlockAckフレームに書き込まれたNAVの値だけNAV時間4361から延長する構成について説明する。
(2−1−1.端末AのRTSフレーム送信)
図3のステップ1からステップ2までは同様である。
ステップ3にて決定するNAV時間4361の長さは、第1の実施の形態と違い、RTSフレーム4301の送信開始から、端末B4202から受信するBlockAckフレーム4310の受信完了までの時間である。
ステップ4からステップ6までは同様である。
(2−1−2.端末BのRTSフレーム受信とCTSフレーム送信)
図4のステップ4101からステップ4102までは同様である。
(2−1−3.端末AのCTSフレーム受信とAggregationフレーム送信)
図3のステップ7からステップ11までは同様である。
(2−1−4.端末BのAggregationフレーム受信とHTP Burstフレーム送信)
図4のステップ103からステップ104までは同様である。
ステップ105にて、フレーム生成・送信処理部104は、RIFS時間と、Aggregationフレーム4311の送信にかかる時間と、SIFS時間と、次に端末A4201が送信するBlockAckフレーム4317の送信にかかる時間と、を足し合わせた値を、BlockAckフレーム4310にNAVの値として書き込む。このNAVの値はすなわち、このBlockAckフレーム4310の送信完了から、次に端末A4201が送信するBlockAckフレーム4317の送信完了までの長さを示す値となる。
ステップ106からステップ109までは同様である。
端末C203はBlockAckフレーム4310を受信完了すると、BlockAckフレーム4310に書き込んだNAVの値が表す時間だけ、端末A4201と端末B4202とが双方向通信している帯域を用いての通信を行わないようにする。
以下、RTSフレーム4301のNAVの値で規定された帯域予約の終了時刻から、BlockAckフレーム4310に書き込んだNAVの値で規定された帯域予約の終了時刻までの長さを、NAV延長時間4362とする。
(2−1−5.端末AのHTP Burstフレーム受信とHTP Burstフレーム送信)
図3のステップ12からステップ13までは同様である。
ステップ14にてフレーム生成・送信処理部104は、RIFS時間と、Aggregationフレーム318の送信にかかる時間と、SIFS時間と、次に端末B4202が送信するBlockAckフレーム4324の送信にかかる時間と、を足し合わせた値を、BlockAckフレーム4317にNAVの値として書き込む。このNAVの値はすなわち、このBlockAckフレーム4317の送信完了から、次に端末B4202が送信するBlockAckフレーム4324の送信完了までの長さを示す値となる。
ステップ15からステップ18まで同様である。
ここで、端末C203はBlockAckフレーム4317を受信完了すると、BlockAckフレーム4317に書き込んだNAVの値が表す時間だけ、端末A4201と端末B4202とが双方向通信している帯域を用いての通信を行わないようにする。
以下、BlockAckフレーム4310のNAVの値で規定された帯域予約の終了時刻から、BlockAckフレーム4317に書き込んだNAVの値で規定された帯域予約の終了時刻までの長さを、NAV延長時間4363とする。
(2−1−6.端末BのHTP Burstフレーム受信とHTP Burstフレーム送信)
ステップ110からステップ111までは同様である。
ステップ112にて、フレーム生成・送信処理部104は、RIFS時間と、Aggregationフレーム325の送信にかかる時間と、SIFS時間と、次に端末A4331が送信するBlockAckフレーム4317の送信にかかる時間と、を足し合わせた値を、BlockAckフレーム4324にNAVの値として書き込む。このNAVの値はすなわち、このBlockAckフレーム4324の送信完了から、次に端末A4201が送信するBlockAckフレーム4331の送信完了までの長さを示す値となる。
ステップ113からステップ116までは同様である。
端末C203はBlockAckフレーム4324を受信完了すると、BlockAckフレーム4324に書き込んだNAVの値が表す時間だけ、端末A4201と端末B4202とが双方向通信している帯域を用いての通信を行わないようにする。
以下、BlockAckフレーム4317のNAVの値で規定された帯域予約の終了時刻から、BlockAckフレーム4324に書き込んだNAVの値で規定された帯域予約の終了時刻までの長さを、NAV延長時間4364とする。
(2−1−7.端末AのHTP Burstフレーム受信とBlockAckフレーム送信)
図3のステップ19からステップ20までは同様である。
ステップ21にてフレーム生成・送信処理部104は、NAVの値として0を書き込む。このNAVの値はすなわち、帯域予約を解除、すなわちNAV時間4361の終了を示す値となる。ステップ22は同様である。
以上のように、本実施の形態では、最初に設定したNAV時間からさらにNAV延長時間ずつ延長していくことができる。
なお、本実施の形態でNAVの値は予め定められたNAV時間の最大限度(TXOP Limit)を超えないようにすることが必要である。
端末A4021のみがTXOPLimitを超えないようにNAVの値を監視する場合は例えば以下のようにする。すなわち、端末A4021が送信するQoS Cf−Poll+DataフレームであるData1−A4319のQoS Controlフィールドに、RD方式で通信を行うことを示す値に代えて、TXOP分与限度時間を書き込む。端末B4202はTXOP分与限度時間を、DataフレームのAggregationフレームの送信にかかる時間と、SIFS時間と、BlockAckフレームの送信にかかる時間とを足し合わせた値の上限として、自らが送信するデータの量を決める。もし、BlockAckフレーム4317に書き込んだNAVの値とTXOP分与限度時間とを足し合わせた値が、BlockAckフレーム4317の送信完了からTXOP Limitまでの長さよりも長い場合は、TXOP分与限度時間を短くして、端末B4202が送信するHTP Burstフレーム4353の送信にかかる時間とSIFS時間とBlockAckフレーム4331の送信にかかる時間とを足し合わせた値がTXOP Limitまでの残り時間よりも短くなるように調整する。あるいは、BlockAckフレーム4317に書き込んだNAVの値とTXOP分与限度時間とを足し合わせた値が、BlockAckフレーム4317の送信完了からTXOP Limitまでの長さよりも場合にだけ端末A4021は、HTP Burstフレーム4352を送信するようにしてもよい。
また、端末B4022もTXOPLimitを超えないようにNAVの値を監視する場合は例えば以下のようにする。端末A4201と端末B4202はそれぞれ、自らが送信するHTP BurstフレームとSIFS時間とそのHTP Burst フレームに含まれるDataフレームに対するBlockAckフレームの送信にかかる時間とを足し合わせた値がTXOP Limitまでの残り時間よりも短くなるように、そのHTP BurstフレームのAggregationフレームのデータ量を減らす。
(第3の実施の形態)
図14は本実施の形態のタイミングチャートである。なお、端末A5201は図3に示す第1の実施の形態の端末A202の動作のフローチャート、端末B5202は図4に示す第1の実施の形態の端末B202の動作のフローチャートに従って動作するものとして説明する。
本実施の形態は、端末A5201のRTSフレーム5301に書き込むNAVの値を、端末B5202がHTP Burst フレーム5352を受信した後に返信するBlockAckフレーム5324の送信完了までの値とする構成について説明する。
(3−1−1.端末AのRTSフレーム送信)
ステップ1からステップ2までは同様である。
ステップ3にて決定するNAV時間5361の長さは、第1の実施の形態と違い、SIFS時間5つ分と、CTSフレーム5303の送信にかかる時間と、端末A5201が送信するAggregationフレーム5304の送信にかかる時間と、端末B5202が送信するHTP Burstフレーム5351の送信にかかる時間と、端末A5201が送信するHTP Burstフレーム5352の送信にかかる時間と、端末B5202が送信するBlockAckフレーム5324の送信にかかる時間と、を足し合わせた値を、RTSフレーム5301にNAVの値として書き込む。このNAVの値はすなわち、このRTSフレーム5301の送信完了から、端末B5202が送信する2つめのBlockAckフレーム5324の送信完了までの長さを示す値となる。
図3のステップ4からステップ6までは同様である。
(3−1−2.端末BのRTSフレーム受信とCTSフレーム送信)
ステップ101からステップ102までは同様である。
(3−1−3.端末AのCTSフレーム受信とAggregationフレーム送信)
ステップ7からステップ11までは同様である。
(3−1−4.端末BのAggregationフレーム受信とHTP Burstフレーム送信)
ステップ103からステップ109までは同様である。
(3−1−5.端末AのHTP Burstフレーム受信とHTP Burstフレーム送信)
ステップ12からステップ13までは同様である。
ステップ14にてフレーム生成・送信処理部104は、RIFS時間1つ分と、SIFS時間2つ分と、Aggregationフレーム318の送信にかかる時間と、HTP Burstフレーム5353の送信にかかる時間と、BlockAckフレーム5331の送信にかかる時間と、を足し合わせた値を、BlockAckフレーム5317にNAVの値として書き込む。このNAVの値はすなわち、このBlockAckフレーム5317の送信完了から、次に端末A5201自らが送信するBlockAckフレーム5331の送信完了までの長さを示す値となる。
ステップ15からステップ18まで同様である。
端末C203と端末D204はBlockAckフレーム5317を受信完了すると、BlockAckフレーム5317に書き込んだNAVの値が表す時間だけ、端末A5201と端末B5202とが双方向通信している帯域を用いての通信を行わないようにする。
以下、RTSフレーム4301のNAVの値で規定された帯域予約の終了時刻から、BlockAckフレーム5317に書き込んだNAVの値で規定された帯域予約の終了時刻までの長さを、NAV延長時間4362とする。
(3−1−6.端末BのHTP Burstフレーム受信とHTP Burstフレーム送信)
ステップ110からステップ111までは同様である。
ステップ112にてフレーム生成・送信処理部104は、RIFS時間と、Aggregationフレーム325の送信にかかる時間と、SIFS時間と、次に端末A5331が送信するBlockAckフレーム5324の送信にかかる時間と、を足し合わせた値を、BlockAckフレーム5324にNAVの値として書き込む。このNAVの値はすなわち、このBlockAckフレーム5324の送信完了から、次に端末A5201が送信するBlockAckフレーム5331の送信完了までの長さを示す値であり、かつBlockAckフレーム5317に書き込んだNAVの値で規定された帯域予約の終了時刻までの残り時間を示す値である。
ステップ113からステップ116までは同様である。
(3−1−7.端末AのHTP Burstフレーム受信とBlockAckフレーム送信)
ステップ19からステップ20までは同様である。
ステップ21にてフレーム生成・送信処理部104は、NAVの値として0を書き込む。ステップ22は同様である。
以上のように、RTS−CTS交換で開始したNAVが終了するまでに、端末A5201と端末B5202の両方から、NAVを延長したことを通知する。したがって、端末A5201の送信波しか受信できない端末や、端末B5202の送信波しか受信できない端末などに対しても確実に、NAVを延長したことを通知することができる。
(第4の実施の形態)
図15は本実施の形態のタイミングチャートである。
なお、基地局A6201は図3に示す第1の実施の形態の端末A201の動作のフローチャート、端末B5202は図4に示す第1の実施の形態の端末B202の動作のフローチャートに従って動作するものとして説明する。
本実施の形態は、この双方向通信は図16のように、端末A6201と端末B6202が属している無線通信システムに端末A6201及び端末B6202以外にも、送信データの宛先とならない端末C203、端末D204、端末E205も存在するものとする。
端末A6201の送信波は、端末A201と端末B202との双方向通信が始まるときに、端末C203、端末D204、端末E205は受信することができるものとする。すなわち、端末A6201の送信波を受信できない、端末A6201に対する隠れ端末はないものとする。
(4−1−1.端末AのRTSフレーム送信)
ステップ1からステップ2までは同様である。
ステップ3にて決定するNAV時間6361の長さは、第2の実施の形態と同様である。
ステップ4からステップ6までは同様である。
(4−1−2.端末BのRTSフレーム受信とCTSフレーム送信)
図4のステップ101からステップ102までは同様である。
(4−1−3.端末AのCTSフレーム受信とAggregationフレーム送信)
図3のステップ7からステップ11までは同様である。
(4−1−4.端末BのAggregationフレーム受信とHTP Burstフレーム送信)
図4のステップ103からステップ109までは同様である。
(4−1−5.端末AのHTP Burstフレーム受信とHTP Burstフレーム送信)
図3のステップ12からステップ13までは同様である。
ステップ14にてフレーム生成・送信処理部104は、RIFS時間と、2つのSIFS時間と、Aggregationフレーム6318の送信にかかる時間と、Data5−A6319に書き込むTXOP分与時間と、BlockAckフレーム6331の送信にかかる時間とを足し合わせたものをBlockAckフレーム6317にNAVの値として書き込む。このNAVの値はすなわち、このBlockAckフレーム6317の送信完了から、次に端末A6201自らが送信するBlockAckフレーム6331の送信完了までの長さを示す値となる。
図3のステップ15からステップ18までは同様である。
端末C203と端末D204はBlockAckフレーム6317を受信完了すると、BlockAckフレーム6317に書き込んだNAVの値が表す時間だけ、端末A6201と端末B6202とが双方向通信している帯域を用いての通信を行わないようにする。
以下、RTSフレーム4301のNAVの値で規定された帯域予約の終了時刻から、BlockAckフレーム6317に書き込んだNAVの値で規定された帯域予約の終了時刻までの長さを、NAV延長時間6362とする。
(4−1−6.端末BのHTP Burstフレーム受信とHTP Burstフレーム送信)
図4のステップ110からステップ116までは同様である。
(4−1−7.端末AのHTP Burstフレーム受信とBlockAckフレーム送信)
図3のステップ19からステップ22までは同様である。
以上のように、RTS−CTS交換で開始したNAVが終了するまでに、基地局A6201がNAVを延長するBlockAckフレーム6317を送信する。
端末C203、端末D204、端末E205の全てが基地局A6201の送信波を受信でき、基地局A6201がBlockAckフレーム6317を送信完了してNAV延長時間を全端末に通知するまで、その前に規定したNAV時間が継続するので、基地局A6201を含むシステムにおいてもNAV時間をを途切れさせることなく延長していくことができる。
なお、NAVを延長するときに基地局A6201は、NAV延長時間の終了時刻がTXOP Limitを超えないように調整する。
本実施の形態では基地局A6201を基地局と称した。しかし、隠れ端末がないことを前提とすれば、基地局A6201は端末であってもよい。
(第5の実施の形態)
図17は本実施の形態のタイミングチャート、図18は端末A7201の動作に係るフローチャート、図19は端末B7202の動作に係るフローチャートである。
端末A7201は図5の端末A201の位置に、端末B7202は図5の端末B202の位置に、それぞれあるものとして説明する。
本実施の形態では、第1の実施の形態について、端末A7201が与えたTXOP分与時間を端末B7202が使いきらない場合はその余った時間だけ繰り上げて双方向通信を行うよう変更を加えた構成について説明する。
(5−1−1.端末AのRTSフレーム送信)
図18のステップ7001からステップ7006までは図3のステップ1からステップ6までと同様である。
(5−1−2.端末BのRTSフレーム受信とCTSフレーム送信)
図19のステップ7101からステップ7102までは図4のステップ101からステップ102までと同様である。
(5−1−3.端末AのCTSフレーム受信とAggregationフレーム送信)
図18のステップ7007からステップ7011までは図3のステップ7からステップ11までと同様である。
(5−1−4.端末BのAggregationフレーム受信とHTP Burstフレーム送信)
図19のステップ7103からステップ7104までは図4のステップ103からステップ104までと同様である。
ステップ7105にて、フレーム生成・送信処理部104は、送信データからDataフレームとしてData1−B7312, Data2−B7313, Data3−B7314を作成する。
ここで注意すべきは、TXOP分与時間が、RIFS時間とSIFS時間とBlockAckフレームの送信にかかる時間に加えてDataフレームを4つ送信することができる値であるのに対して、端末B7202はData1−B7312と Data2−B7313と Data3−B7314といった3つのDataフレームしか作成しない点である。これは例えば、端末B7202が4つのDataフレームを作成するほどの量の端末A7201宛送信データを送信キュー106に有しない場合などである。
つづいてフレーム生成・送信処理部104はData1−B7312, Data2−B7313, Data3−B7314,を結合してAggregationフレーム7311を作成する。
ここでフレーム生成・送信処理部104は、RIFS時間と、3つのDataフレームからなるAggregationフレーム311の送信にかかる時間(すなわちDataフレームを3つ送るのにかかる時間)と、SIFS時間と、次に端末A7201が送信するBlockAckフレーム7317の送信にかかる時間と、を足し合わせた値を、BlockAckフレーム7310にNAVの値として書き込む。このNAVの値はすなわち、このBlockAckフレーム7310の送信完了から、次に端末A7201が送信するBlockAckフレーム7317の送信完了までの長さを示す値となる。
図19のステップ7106からステップ7109までは図4のステップ106からステップ109までと同様である。
ここで、端末C204はBlockAckフレーム7310を受信しても、BlockAckフレーム7310に書き込まれたNAVの値に拘わらず、RTS−CTSフレーム交換で規定したNAV時間7361の終了あるいは後述するCf−endフレーム7332を受信するまではその送信帯域を用いての通信を行わない。
(5−1−5.端末AのHTP Burstフレーム受信とHTP Burstフレーム送信)
図18のステップ7012からステップ7018は図3のステップ12からステップ18までと同様である。
ここで、端末B7202が送信したBlockAckフレーム7310に書き込まれたNAVの値が、ここではTXOP時間と等価であるNAV時間7361の終了時刻までの残り時間よりも短い場合、端末A7201は、Data1−A4305に書き込んだTXOP分与時間がその短い分だけ余ったことを知る。
(5−1−6.端末BのHTP Burstフレーム受信とHTP Burstフレーム送信)
図19のステップ7110からステップ7110までは図4のステップ110からステップ110までと同様である。
ステップ7111にて、送受信状態管理部108はBlockAckフレーム7317のBitmapから再送すべきDataフレームがあるか否かを判断して再送すべきDataフレームを用意した後に、送信キュー106から新たな送信データを取り出す処理を行う。ここで端末A7201宛の送信データが送信キュー106にないので、送受信状態管理部108はフレーム生成・送信処理部104に、送達確認を通知するBitmapを渡すと共に、端末A7201宛の送信データがないことを通知する。
ステップ7112にて、フレーム生成・送信処理部104はBitmapを用いて、端末A7201から送信されたData5−A7319, Data7−A7320, Data7−A7321, Data8−A7322に対するBlockAckフレーム7324を作成する。またフレーム生成・送信処理部104は、端末A7201宛の送信データがないこと通知されているので、端末A7201宛の送信データがないことを端末A7201に通知するためのQoS Nullフレーム7326を作成する。フレーム生成・送信処理部104は、RIFS時間と、QoS Nullフレーム7326の送信にかかる時間と、SIFS時間と、次に端末A7331が送信するBlockAckフレーム7317の送信にかかる時間と、を足し合わせた値を、BlockAckフレーム7324にNAVの値として書き込む。このNAVの値はすなわち、このBlockAckフレーム7324の送信完了から、次に端末A7201が送信するBlockAckフレーム7331の送信完了までの長さを示す値となる。
フレーム生成・送信処理部104は、 BlockAckフレーム7324に書き込んだNAVの値からRIFS時間とQoS Nullフレーム7326を送信にかかる時間とを差し引いた値を、QoS Nullフレーム7326にNAVの値として書き込む。このNAVの値はすなわち、QoS Nullフレーム7326の送信完了から次に端末A7201が送信するBlockAckフレーム7331の送信完了までの長さを示す値となる。
図19のステップ7113からステップ7116までは、図4のステップ113からステップ116までにおける送信AggregationフレームをQoS Nullフレームに読み替えるだけである。
(5−1−7.端末AのHTP Burstフレーム受信とBlockAckフレーム送信)
RIFS時間を挟んだ2つのPHYフレーム、すなわちHTP Burstフレーム7353を受信した端末A7201の受信処理部105は、QoS Nullフレーム7326を正常に受信するとAckフレーム7331の送信要求を送受信状態管理部108に渡す(図18のステップ7019)。
送受信状態管理部108は、Ackフレーム7331の送信要求をフレーム生成・送信処理部104へ渡す(図18のステップ7020)。
フレーム生成・送信処理部104は受け取った送信要求に従って、端末B7202から送信されたQoS Nullフレーム7326に対するAckフレーム7331を作成する。またフレーム生成・送信処理部104は、NAV時間を強制終了させるCf−endフレーム7332を作成する(図18のステップ7021)。
フレーム生成・送信処理部104は、端末B7202から送信されたHTP Burstフレーム7353を受信処理部105が受信完了してからSIFS時間後に、作成したHTP Burstフレーム7354の送信を開始する。
HTP Burstフレーム7354の送信について詳述する。まずAckフレーム7331の送信を開始する(図18のステップ22)。Ackフレーム7331の送信の伝送レートを第1の伝送レートとする。
フレーム生成・送信処理部104は、Ackフレーム7331の送信を完了した後にRIFS時間だけ経つと、、Ackフレーム7331の伝送レートと同じく第1の伝送レートで、Cf−endフレーム7332を送信する(図18のステップ23)。
端末C203はCf−endフレーム7332を受信することで、端末A7201の帯域予約が解除されてその帯域を用いてもよいことを知る。
さらにこの双方向通信もしくは他の端末との通信を行いたい場合は、AIFS+Backoff 時間だけ経過した後、1−1−1の手順から再度行う。
以上のように、本実施の形態では、端末A7201が与えたTXOP分与時間を端末B7202が使いきらない場合に、その余った時間だけ繰り上げて双方向通信を行うことができる。また、端末B7202に端末A7201宛の送信データがないことを通知することができる。
その結果、端末B7202が余らせた時間を送受信が行われない無駄時間にしてしまうことなく、双方向通信を早く終了することができる
なお、本実施の形態ではステップ116でQoS Nullフレーム7326を送信するものとして説明した。しかし、何れかのフレームで、端末B7202の送信キュー106に端末A7201宛送信データがないことを端末A7201に通知することができる場合、QoS Nullフレーム7326を他のフレームに置き換えることは可能である。これは例えば、BlockAckフレーム7324に書き込むNAVの値が0である場合に、端末B7202は端末A7201宛送信データを持たない、と端末A7201が見なすものと取り決めてくことで実現できる。
また、IEEE802.11a/b/g/eの規格にしか対応していない端末に対してもCf−endフレーム620の受信を保証するために、Ackフレーム7331とCf−endフレーム7332を、RIFS時間だけ挟んでHTP Burstフレームとして送信するのではなく、SIFS時間を挟んで送信する構成としてもよい。
また、Ackフレーム7331を送信せずに、端末B7202から送信されたHTP Burstフレーム7353を受信処理部105が受信完了してからSIFS時間後にCf−endフレーム7332を送信する構成としてもよい。この場合端末B7202は、Cf−endフレーム7332の受信を以って、HTP Burstフレームが送達し、双方向通信が終了するものとみなすものとする。この場合は、QoS Nullフレーム7326に対するAckフレーム7331は不要であり、HTP Burstフレーム7354の代わりにCf−endフレーム7332を単独で送信する。
また、本実施の形態では端末A7201がAckフレーム7331の送信を完了した後のRIFS時間中に伝送レートを第1の伝送レートから第2の伝送レートに変更するものとして説明したが、Cf−endフレーム7332を第1の伝送レートで送信するよう構成してもよい。
(第6の実施の形態)
図20は本実施の形態のタイミングチャート、図21は端末A8201の動作に係るフローチャートである。
なお、端末B8202は図19に示す第5の実施の形態の端末B8202の動作のフローチャートに従って動作するものとして説明する。
また、端末A8201は図5の端末A201の位置に、端末B8202は図5の端末B202の位置に、それぞれあるものとして説明する。
本実施の形態では、第2の実施の形態について、端末A8201が与えたTXOP分与時間を端末B8202が使いきらない場合はその余った時間だけ繰り上げて双方向通信を行うよう変更を加えた構成について説明する。
(6−1−1.端末AのRTSフレーム送信)
図21のステップ8001からステップ8002までは図18のステップ7001からステップ7002までと同様である。
ステップ8003にて決定するNAV時間8361の長さは、第2の実施の形態同様である。
図21のステップ8004からステップ8006までは図18のステップ7004からステップ7006までと同様である。
(6−1−2.端末BのRTSフレーム受信とCTSフレーム送信)
図19のステップ7101からステップ102までは同様である。
(6−1−3.端末AのCTSフレーム受信とAggregationフレーム送信)
図21のステップ8007からステップ8011までは図18のステップ7008からステップ7011までと同様である。
(6−1−4.端末BのAggregationフレーム受信とHTP Burstフレーム送信)
図19のステップ7103からステップ7104までは同様である。
ステップ7105にて、フレーム生成・送信処理部104は、送信データからDataフレームとしてData1−B8312, Data2−B8313, Data3−B8314を作成する。
ここで注意すべきは、TXOP分与時間が、RIFS時間とSIFS時間とBlockAckフレームの送信にかかる時間に加えてDataフレームを4つ送信することができる値であるのに対して、端末B8202はData1−B8312と Data2−B8313と Data3−B8314といった3つのDataフレームしか作成しない点である。これは例えば、端末B8202が4つのDataフレームを作成するほどの量の端末A8201宛送信データを送信キュー106に有しない場合などである。
つづいてフレーム生成・送信処理部104はData1−B8312, Data2−B8313, Data3−B8314,を結合してAggregationフレーム8311を作成する。
ここでフレーム生成・送信処理部104は、RIFS時間と、Aggregationフレーム8311の送信にかかる時間(すなわちDataフレームを3つ送るのにかかる時間)と、SIFS時間と、次に端末A8201が送信するBlockAckフレーム8317の送信にかかる時間と、を足し合わせた値を、BlockAckフレーム8310にNAVの値として書き込む。このNAVの値はすなわち、このBlockAckフレーム8310の送信完了から、次に端末A8201が送信するBlockAckフレーム8317の送信完了までの長さを示す値となる。
フレーム生成・送信処理部104は、 BlockAckフレーム8310に書き込んだNAVの値からRIFS時間とAggregationフレーム7311を送信にかかる時間とを差し引いた値を、Data1−B8312, Data2−B8313, Data3−B8314, Data4−B8315にNAVの値として書き込む。このNAVの値はすなわち、Aggregationフレーム7311の送信完了から次に端末A8201が送信するBlockAckフレーム8317の送信完了までの長さを示す値となる。
図19のステップ7106からステップ7109までは同様である。
ここで、端末C204はBlockAckフレーム8310を受信すると、BlockAckフレーム8310の受信完了からBlockAckフレーム8310に書き込まれたNAVの値で表される時間端末A8201と端末B8202とが双方向通信している帯域を用いての通信を行わない。すなわち、端末A8201の端末C204に対する帯域予約が延長される。
(6−1−5.端末AのHTP Burstフレーム受信とHTP Burstフレーム送信)
図21のステップ8012からステップ8018は図18のステップ7012からステップ7018までと同様である。
ここで、端末B8202が送信したBlockAckフレーム8310に書き込まれたNAVの値がData1−A8305に書き込んだTXOP分与時間の終了までの残り時間よりも短い場合、端末A8201は、BlockAckフレーム4305に書き込んだTXOP分与時間がその短い分だけ余ったことを知る。
(6−1−6.端末BのHTP Burstフレーム受信とHTP Burstフレーム送信)
図19のステップ7110からステップ7111までは同様である。
ステップ7112にて、フレーム生成・送信処理部104はBitmapを用いて、端末A8201から送信されたData5−A8319, Data8−A8320, Data8−A8321, Data8−A8322に対するAckフレーム8324を作成する。またフレーム生成・送信処理部104は、QoS Nullフレーム8326を作成する。
フレーム生成・送信処理部104は、RIFS時間と、QoS Nullフレーム8326の送信にかかる時間と、SIFS時間と、次に端末A8331が送信するAckフレーム8317の送信にかかる時間と、を足し合わせた値を、Ackフレーム8324にNAVの値として書き込む。このNAVの値はすなわち、このAckフレーム8324の送信完了から、次に端末A8201が送信するAckフレーム8331の送信完了までの長さを示す値となる。
フレーム生成・送信処理部104は、 Ackフレーム8324に書き込んだNAVの値からRIFS時間とQoS Nullフレーム8326を送信にかかる時間とを差し引いた値を、QoS Nullフレーム8326にNAVの値として書き込む。このNAVの値はすなわち、QoS Nullフレーム8326の送信完了から次に端末A8201が送信するAckフレーム8331の送信完了までの長さを示す値となる。
図19のステップ7113からステップ7115までは同様である。
また、ステップ7116についても送信するフレームをQoS Nullフレーム8326に読み替えるだけなので説明を省略する。
(6−1−7.端末AのHTP Burstフレーム受信とAckフレーム送信)
図21のステップ8019からステップ8020までは図18のステップ7019からステップ7020までと同様なので説明を省略する。
フレーム生成・送信処理部104は受け取ったBitmapを用いて、端末B8202から送信されたQoS Nullフレーム8326に対するAckフレーム8331を作成する。(図20のステップ8021)。
フレーム生成・送信処理部104は、端末B8202から送信されたHTP Burstフレーム8353を受信処理部105が受信完了してからSIFS時間後に、作成したAckフレーム8331を送信する(図20のステップ22)。
本実施の形態ではAckフレーム8331の送信完了の時点でNAV延長時間8364が終了するので、Cf−endフレーム8332は送信する必要がない。
さらにこの双方向通信を行いたい場合は、AIFS+Backoff 時間だけ経過した後、1−1−1の手順から再度行う。
以上のように、本実施の形態では、第2の実施の形態においても、端末A8201が与えたTXOP分与時間を端末B8202が使いきらない場合に、その余った時間だけ繰り上げて双方向通信を行うことができることを示した。
その結果、端末B8202が余らせた時間だけ双方向通信を早く終了することができる
(第7の実施の形態)
図22は本実施の形態のタイミングチャートである。
なお、基地局A9201は図18に示す第5の実施の形態の端末A7201の動作のフローチャート、端末B9202は図19に示す第5の実施の形態の端末B7202の動作のフローチャートに従って動作するものとして説明する。また、基地局A9201は図5の端末A201の位置に、端末B9202は図5の端末B202の位置に、それぞれあるものとして説明する。
本実施の形態では、第4の実施の形態について、基地局A9201が与えたTXOP分与時間を端末B9202が使いきらない場合はその余った時間だけ繰り上げて双方向通信を行うよう変更を加えた構成について説明する。
(7−1−1.端末AのRTSフレーム送信)
図18のステップ7001からステップ7002までは同様である。
ステップ3にて決定するNAV時間9361の長さは、第4の実施の形態と同様である。
ステップ7004からステップ7006までは同様である。
(7−1−2.端末BのRTSフレーム受信とCTSフレーム送信)
図19のステップ7101からステップ102までは同様である。
(7−1−3.端末AのCTSフレーム受信とAggregationフレーム送信)
図18のステップ7007からステップ7011までは同様である。
(7−1−4.端末BのAggregationフレーム受信とHTP Burstフレーム送信)
図19のステップ7103からステップ7109までは同様である。
(7−1−5.端末AのHTP Burstフレーム受信とHTP Burstフレーム送信)
図18のステップ7012からステップ7013は同様である。
ステップ14にてフレーム生成・送信処理部104は、RIFS時間と、2つのSIFS時間と、Aggregationフレーム9318の送信にかかる時間と、Data5−A9319に書き込むTXOP分与時間と、BlockAckフレーム9331の送信にかかる時間とを足し合わせたものをBlockAckフレーム9317にNAVの値として書き込み、帯域予約を延長する。
図18のステップ7015からステップ7018は同様である。
(7−1−6.端末BのHTP Burstフレーム受信とHTP Burstフレーム送信)
図19のステップ7110からからステップ7115までは同様である。
また、ステップ7116についても第5の実施の形態や第6の実施の形態と同様に、送信するフレームをQoS Nullフレーム9326に読み替えるだけなので説明を省略する。
(7−1−7.端末AのHTP Burstフレーム受信とAckフレーム送信)
図18のステップ7019からステップ7024までと同様である。
なお、本実施の形態ではAckフレーム9331の送信完了の時点で、BlockAckフレーム9317で規定したNAV延長時間9364が継続しているので、Cf−endフレーム8332を送信する必要がある。
以上のように、本実施の形態では、第4の実施の形態においても、基地局A9201が与えたTXOP分与時間を端末B9202が使いきらない場合に、その余った時間だけ繰り上げて双方向通信を行うことができることを示した。
その結果、端末B9202が余らせた時間だけ双方向通信を早く終了することができる。
(第8の実施の形態)
図17に示す第5の実施の形態のタイミングチャートを参照しながら以下説明する。ただし、BlockAckフレーム7317をCTS−Selfフレーム7317と読み替えるものとする。
端末A7201が、端末B7202が送信するHTP Burstフレームを正常に受信できないときには以下の4つうちいずれかの状態になる。本実施の形態では、第5の実施の形態について、それらの状態に陥ったとき毎に、リカバリについて説明する。
(1)QoS Cf−Poll+Dataフレームが結合されたAggregationフレームの送信完了からSIFS+1Slot時間経過しても、キャリアセンス部109がキャリアセンス処理において受信電力のBusyを検出しない場合
Aggregationフレームの送信完了からSIFS+1Slot時間経つまでに受信電力のBusyが検出されるか監視した後、QoS Cf−Poll+Dataフレームが結合されたAggregationフレームが再送される。もしくは、BlockAckフレームを送信することにしてもよい。これらはIEEE802.11eに規定された方法と同様である。
この場合はTXOP分与時間だけ経過した時点でCTS−Selfフレーム7317を送信する。ただし、RIFS時間を挟んだ2つのPHYフレームを待ち受けている端末B7202は、CTS−Selfフレーム7317が単独で送信されたのでは、受信することができない。
そこで、端末A7201がBlockAckフレーム7324を受信した後、端末B7202がBlockAckフレーム7310に書き込んだNAVの値が表す時間が経過してから、CTS−Selfフレーム7317を送信完了した後にRIFS時間だけ経過してからDataフレームを送信する。つまり、CTS−Selfフレーム7317を、DataフレームとのHTP Burst フレーム7352として送信する。
(2)BlockAckフレームの正常に受信してからRIFS時間後に、キャリアセンス部109がキャリアセンス処理において受信電力のBusyを検出しない場合
端末A7201が最初のAggregationフレーム7304を送信完了した後は、RIFS時間を挟んだ2つのPHYフレームを互いに送信しあうことがマネジメントフレーム交換などによって予めわかっている。
そのため、BlockAckフレーム7314すなわち1つめのPHYフレームの受信を完了してからRIFS時間後に端末A7201のキャリアセンス部109がキャリアセンス処理においてIdleである場合であっても、端末B7202は何らかのフレーム(ここではAggregationフレーム7311)を2つめのPHYフレームとして送信しているはずである。
ここで従来のようにカバリ方法に従えば、端末A7201が1つめのPHYフレームであるBlockAckフレーム7310を受信した後PIFS時間(SIFS+1Slot)が経過してから再送すべきフレームを送信することになる。
しかしそれでは、RIFS時間を挟んだ2つのPHYフレームを待ち受けている端末B7202は、端末A7201が再送したフレームを受信することができない。また、端末A7201が再送したフレームが、端末B7202が送信している何らかのフレームと衝突してしまう。
これを避けるには、端末A7201が端末B7202に与えたTXOP分与時間だけ送信を控える手法も考えられる。しかし本実施の形態ではこの場合はにおいて、端末A7201がBlockAckフレーム7324を受信した後、端末B7202がBlockAckフレーム7310に書き込んだNAVの値から、端末B7202が送信するAggregationフレームの長さと、SIFS時間と、BlockAckフレームの送信にかかる時間がわかる。そのおかげで、BlockAckフレーム7310に書き込んだNAVの値が表す時間が経過してから、CTS−Selfフレーム7317を送信する。その後にRIFS時間だけ経過してからDataフレームを送信する。つまり、CTS−Selfフレーム7317を、DataフレームとのHTP Burst フレーム7352として送信する。
(3)BlockAckフレームの正常に受信してからRIFS時間後に、キャリアセンス部109がキャリアセンス処理において受信電力のBusyを検出する場合
BlockAckフレーム7314すなわち1つめのPHYフレームの受信を完了してからRIFS時間後に端末A7201のキャリアセンス部109がキャリアセンス処理においてBusyである場合は、その後にBusyからIdleとなったときに、端末B7202が2つめのPHYフレームとして送信した何らかのフレーム(ここではAggregationフレーム7311)の送信が完了したものと考えられる。
そこでこの場合では、BlockAckフレーム7314すなわち1つめのPHYフレームの受信を完了してからRIFS時間後に端末A7201のキャリアセンス部109がBusyであった後に、IdleとなってからPIFS時間経過した時点でCTS−Selfフレーム7317を送信を開始し、完了した後にRIFS時間だけ経過してからDataフレームもしくはAggregationフレームを送信する。つまり、CTS−Selfフレーム7317を、DataフレームとのHTP Burst フレーム7352として送信する。
(4)QoS Cf−Poll+Dataフレームが結合されたAggregationフレームの送信完了からSIFS後に、キャリアセンス部109がキャリアセンス処理において受信電力のBusyを検出するが、受信したフレームが正常に読み取れない場合
この場合、これはHTP Burstフレーム7351に対応して、Aggregationフレーム7304の送信完了後にSIFS時間が経過してから、BlockAckフレーム7314の送信に対応する時間だけBusyとなり、RIFS時間だけIdleとなり、さらにまたBusyとなる。その次にIdleになる時点がHTP Burstフレーム7351の送信完了時点と対応すると考えられるので、その時点からPIFS時間経過してからCTS−Selfフレーム7317を送信を開始し、完了した後にRIFS時間だけ経過してからDataフレームを送信する。つまり、CTS−Selfフレーム7317を、DataフレームとのHTP Burst フレーム7352として送信する。
このようなリカバリを行うことによって、RD方式において、端末A7201が送信するリカバリ動作用フレームと、端末B7202が送信するHTP Burstフレームとの衝突を避けることができる。
また、端末A7201が与えたTXOP分与時間を端末B7202が使いきらない場合に、端末A7201がBlockAckフレーム7310を受信することができたならばその余った時間だけ繰り上げて双方向通信を行うことができる。
また、本実施の形態のようなリカバリを第5の実施の形態、第6の実施の形態、第7の実施の形態に対して組み合わせることによって、RTS−CTSフレーム交換やBlockAckフレームで張ったNAVが端末B7202のBlockAckフレーム7314で張るNAVと同時に終了する場合でも、NAVの終了時刻前もしくは直後にCTS−Selfフレーム7317を送信するので、NAVが終了してしまっていることがなく、端末A7201と端末B7202以外の端末との送信フレームの衝突を避けることができる。
(第9の実施の形態)
図14に示す第3の実施の形態のタイミングチャートを参照しながら以下説明する。ただし、BlockAckフレーム5317をCTS−Selfフレーム5317と読み替えるものとする。
本実施の形態では、第3の実施の形態について、第8の実施の形態で述べた(2)の場合それぞれに対するリカバリを説明する。
なお、(1)(3)(4)の場合は第8の実施の形態と同様である。
(2)BlockAckフレームの正常に受信してからRIFS時間後に、キャリアセンス部109がキャリアセンス処理において受信電力のBusyを検出しない場合
端末A5201が最初のAggregationフレーム304を送信完了した後は、RIFS時間を挟んだ2つのPHYフレームを互いに送信しあうことがマネジメントフレーム交換などによって予めわかっている。
そのため、BlockAckフレーム5314すなわち1つめのPHYフレームの受信を完了してからRIFS時間後に端末A5201のキャリアセンス部109がキャリアセンス処理において受信電力がIdleである場合であっても、端末B5202は何らかのフレーム(ここではAggregationフレーム5311)を2つめのPHYフレームとして送信しているはずである。
ここで従来のようなリカバリ方法に従えば、端末A5201が1つめのPHYフレームであるBlockAckフレーム5310を受信した後PIFS時間(SIFS+1Slot)が経過してから再送すべきフレームを送信することになる。
しかしそれでは、RIFS時間を挟んだ2つのPHYフレームを待ち受けている端末B5202は、端末A5201が再送したフレームを受信することができない。また、端末A5201が再送したフレームが、端末B5202が送信している何らかのフレームと衝突してしまう。
これを避けるため、この場合は、端末A5201がBlockAckフレーム5324を受信した後、端末A5201が端末B5202に与えたTXOP分与時間がが終了してから、CTS−Selfフレーム5317を送信完了した後にRIFS時間だけ経過してからDataフレームやAggregationフレームを送信する。つまり、CTS−Selfフレーム5317を、DataフレームとのHTP Burst フレーム5352として送信する。
このようなリカバリを行うことによって、RD方式において、端末A5201が送信するリカバリ動作用フレームと、端末B5202が送信するHTP Burstフレームとの衝突を避けることができる。
また、端末A5201が与えたTXOP分与時間を端末B5202が使いきらない場合に、端末A5201で受信電力のBusyを検出することができたならばその余った時間だけ繰り上げて双方向通信を行うことができる。
また、本実施の形態のようなリカバリを第5の実施の形態に対して組み合わせることによって、RTS−CTSフレーム交換やBlockAckフレームで張ったNAVが端末B5202のBlockAckフレーム5314で張るNAVと同時に終了する場合でも、CTS−Selfフレーム5317を送信する前にNAVが終了してしまっていることがなく、端末A5201と端末B5202以外の端末との送信フレームの衝突を避けることができる。
(第10の実施の形態)
本願の各実施の形態のHTP Burstフレームの構成と、HTP Burstフレーム受信時の受信動作に関して詳述する。
図23(a)及び図23(b)は、PHYフレームの構成を、図23(c)及び図23(d)はHTP Burstフレームの構成を示す。
本願の各実施の形態の各端末間で送受信されるフレームは、図23(a)に示すように、DataフレームやBlockAckフレームなどのMACレイヤからPHYレイヤに送信されるMACフレーム5の前に、データ送受信時にPHYレイヤの制御に必要な伝送レートや送信フレーム長などの情報を記載するPHYヘッダー3を付け、その前に、PHYレイヤでの受信時に時間同期を取る際に必要なプリアンブル1を付けたフレーム構成で送受信されている。
本願の各実施の形態では、図23(a)の構成のフレームと、図23(a)のフレームの後ろに、PHYヘッダー3とMACフレーム5とを交互に複数結合した図23(b)の構成フレーム(Aggregationフレーム20)を、PHYフレーム10と呼んでいる。また、MACレイヤでのAggregationを行う際は、PHYヘッダー3抜きでMACフレーム5がAggregationされたAggregationフレームとなる。
HTP Burstフレームは、図23(c)のようなフレーム構成となっており、図23(a)もしくは図23(b)で説明したPHYフレーム10を、プリアンブル1とPHYヘッダー3も付けたままで、間にRIFS間隔を開けたAggregation方式の一つであるHTP Burst方式として、バーストとして送信される。この、バースト送信のことを、本願の各実施の形態ではHTP Burstフレームと呼んでいる。もしくは、図23(d)のように、RIFSの後にプリアンブルを省略して結合する方法でもよい。
HTP Burstフレーム50では、PHYフレーム10の間にRIFS時間7が空いているが、RIFS時間7は、従来のIEEE802.11規格で最小時間間隔であったSIFS時間(IEEE802.11aで16μs)よりも大幅に短い期間(2μs)である為、PHYレイヤでの受信処理を軽減する為にRIFS時間7でデータが送信されるのか従来通りSIFS間隔以上でデータが送信されるかを、事前にPHYレイヤへ通知する必要がある。特に、図23(d)のようにプリアンブル1を省略した場合は、PHYレイヤが、2μs後にPHYヘッダーが来ることを認識していないと、時間同期を取ることが出来ない為に受信する事が出来ない。
本願の各実施の形態では、RD方式では、Initiator端末が最初に送信するAggregationフレーム以降の全てのAggregationフレームは、Aggregationフレームの先頭に1つのBlockAckフレームを付け、RIFS時間7を空けて1つのPHYフレーム10をAggregateした、2つのPHYフレーム10によるHTP Burst方式のAggregationフレームで通信が行われると言う事を、RD方式による双方向のデータ送受信を開始する前に、Initiator端末とResponder端末の間で、アソシエーションなどのマネジメントフレーム交換などをして取り決めているため、RD方式での送受信が始まると、MACレイヤではRIFS時間7で受信する必要があることが分かる為、PHYレイヤに対して、RIFS時間7で受信処理を行うか否かの指示が可能となる。
また、上記の取り決めが、2つのPHYフレーム10ではなく、3つ以上のPHYフレーム10を使用すると取り決められており、取り決められたPHYフレーム10の数も、最大値を取り決めただけの場合は、PHYヘッダー部分に、該PHYフレーム10を受信後、RIFSで送信されるかどうかを示すことにより、MACレイヤからの指示を行わなくても、RIFS時間7での連続した受信処理の準備を行うことが出来る。
また、本願の各実施の形態のBlockAckフレームやAckフレームやCf−endフレームのように、MACレイヤでRD方式の通信が終了し、2つのPHYフレームをRIFS間隔で送信する処理が行われないことがわかる場合は、当該フレームを受信後に、PHYレイヤにRIFS時間7で受信する必要が無いことを通知し、PHYレイヤの受信モードを通常の状態に戻すことが出来る。
したがって、RIFS間隔でバースト送信されるHTP Burst方式では、RIFS間隔でデータ受信を行う特殊な状況と、通常の受信方法を、MACレイヤから適宜制御することが出来る。また、PHYヘッダーを使用する事によって、PHYレイヤのみで制御可能となり、MACレイヤからの通知動作を省略することが出来る。
(第11の実施の形態)
第1の実施の形態では、RD方式のInitiator端末が一台のResponder端末と双方向のデータ送受信処理を行っていた。これに対して本実施の形態では、第1の実施の形態で記載したRTSフレームとCTSフレームでのNAVによる帯域予約を、全ての送信期間であるTXOP時間分行い、RD方式とHTP Burst方式を組合わせた送受信処理を行う際に、Responder端末が複数台存在しても、RD方式とHTP Burst方式を組合わせた送受信処理を行う方法に関して説明する。
本実施の形態は、Responder端末の台数が複数台となり、各データの送信先が異なる部分のみが第1の実施の形態と異なるので、第1の実施の形態と異なる部分を中心に記載する。
図24はRD方式とHTP Burst方式を組み合わせた送受信時に、Responder端末が複数台いる場合の送受信方法を説明する図である。
本実施の形態では、RD方式のInitiator端末である端末A1501から、RD方式で使用するTXOP時間をNAVの値として書き込んだRTSフレーム1504を、最初のResponder端末である端末B1502に対して送信する。RTSフレーム1504を受信した端末B1502は、RTSフレーム1504に記載されたNAVの値からSIFS時間とCTSフレーム1505の送信にかかる時間分差し引いた値を、CTSフレーム1505に記載して、端末A1501に対して返信する。次に端末A1501は、QoS Cf−Poll+Dataフレームを先頭に付けた、端末B1502宛ての送信データData1−A, Data2−A, Data3−A, Data4−AをAggregateしたAggregation frameを送信し、それに対して、端末B1502が、BlockAckフレーム1508を先頭に付けたHTP Burstフレーム1509を端末A1501に対して返信する。ここまでの送受信動作は、第1の実施の形態と同様のである。
HTP Burstフレーム1509を受信した端末A1501は、第1の実施の形態と異なり、HTP Burstフレーム1509に対するBlockAckフレームを送信する際に、端末C1503とのRD方式に切り替える。ここで、端末A1501は、HTP Burstフレーム1509内の端末B1502から端末A1501へ送信されたデータData1−B, Data2−B, Data3−B, Data4−Bに対するBlockAckフレームとして、BlockAckフレーム1510を作成する。次に、BlockAckフレーム1510のRIFS後に、端末A1501から端末C1503に対する送信データData5−A, Data6−A, Data7−A, Data8−AをAggregateしたHTP Burstフレーム1511を作成し、端末B1502と端末C1503宛てに送信する。本実施の形態では、HTP Burstフレーム1511内に、端末B1502宛てのBlockAckフレーム1510と、端末C1503宛ての送信データData5−A, Data6−A, Data7−A, Data8−Aの2つの端末宛てのフレームが結合される。また、端末C1503宛ての送信データData5−Aは、QoS Cf−Poll+Dataタイプのフレームとなっており、端末C1503に対して、TXOP時間の一部を分け与える動作を行っている。
HTP Burstフレーム1511を受信した端末B1502は、BlockAckフレーム1510から、自局が送信したデータの送達確認状況を確認する。また、HTP Burstフレーム1511を受信した端末C1503は、BlockAckフレーム1510のRIFS後のQoS Cf−Poll+Dataフレーム1512から、自局にTXOP時間が割当てられたことが分かる。次に、端末C1503は、HTP Burstフレーム1511内のデータData5−A, Data6−A, Data7−A, Data8−Aに対するBlockAckフレーム1513を作成し、端末A1501に対する送信データData1−C, Data2−C, Data3−C, Data4−CをBlockAckフレーム1513のRIFS後にAggregateした、HTP Burstフレーム1514を作成し、端末A1501に対して返信する。HTP Burstフレーム1514を受信した端末A1501は、HTP Burstフレーム1514内の端末A1501に対する送信データData1−C, Data2−C, Data3−C, Data4−Cに対するBlockAckフレーム1515を作成して、HTP Burstフレーム1514を受信したSIFS後に返信し、RD方式による端末B1502と端末C1503との送受信処理を終了する。
この時、HTP Burstフレーム内のBlockAckフレームのNAV設定方法及び送信レートは、第1の実施の形態と同様の方法を用いる。
上記、本実施の形態で説明した方法は、QoS Cf−Poll+DataフレームをAggregationしたAggregation frameを受信して、SIFS後にBlockAckフレームと各送信データを複数Aggregationしたフレームとの間にRIFS間隔空けたHTP Burstフレームを送信する方法自体は、他の実施の形態と同様である為、本実施の形態のRD方式による複数端末との送受信処理には、他の実施の形態の全ての送受信方法が適用でき、また、リカバリー動作も同様に動作する事ができる。
本実施の形態の送受信方法によって、RD方式による複数端末との双方向通信が可能となり、複数端末との双方向通信中に、BlockAckフレームの到達確率を送信データよりも向上させることができる。また、BlockAckフレームを送信データと異なるPHYフレームにて送信することにより、BlockAckフレームを用いて、帯域予約期間を延長する事ができる。など、他の実施の形態にて記載した効果と同様の効果を持った上で、複数端末と効率的に双方向通信を行う事ができる。
(第12の実施の形態)
本実施の形態では、複数の端末と双方向通信する際に、複数の端末に対して一度に送信期間を分け与えるマルチポールフレームを使用する以外は、第11の実施の形態と同様であるため、第11の実施の形態と異なる部分のみを記載する。
図25はMMP(Multiple receiver aggregate multi−poll)フレームにて複数端末に送信期間を付与し、自局からの送信データと複数端末からの送信データを双方向通信する方法を説明する図である。
本実施の形態の複数端末との双方向通信を開始する端末である端末A1601は、MMPフレーム1604を先頭に付け、RIFS後に端末B1602に対する送信データData1−A, Data2−A, Data3−A, Data4−Aを一つのPHYフレームにAggregateしたフレームを結合し、さらにRIFS後に端末C1603に対する送信データData5−A, Data6−A, Data7−A, Data8−Aを接続したHTP Burstフレーム1611を送信する。
MMPフレーム1604には、端末B1602に対して分け与える送信期間として、端末B1602に対するオフセット期間1607と端末B1602に与えるTXOP時間1608が記載されており、また、端末C1603に対して分け与える送信期間として、端末C1603に対するオフセット期間1609と端末C1603に与えるTXOP時間1610が記載される。また、MMPフレーム1604のは、MMPフレーム1604で開始する双方向通信期間1605の帯域予約を行うNAVの値が記載される。
MMPフレーム1604を先頭に結合したHTP Burstフレーム1611を受信した端末B1602は、MMPフレーム1604に書き込まれた端末B1602に対するオフセット期間1607を取り出し、端末B1602の送受信状態管理部108にてオフセット期間1607のタイマーをかける。次に、HTP Burstフレーム1611内の端末B1602宛ての送信データData1−A, Data2−A, Data3−A, Data4−Aを受信して、BlockAckフレーム1611を作成する。
端末B1602がHTP Burstフレーム1611を受信した後、送受信状態管理部108にてかけた端末B1602に対するオフセット期間1607のタイマーが切れると、端末B1602に与えるTXOP時間1608となる。この時、端末B1602は、BlockAckフレーム1611を作成し、BlockAckフレーム1611のRIFS後に、端末A1601に対する送信データData1−B, Data2−B, Data3−B, Data4−BをAggregateしたHTP Burstフレーム1612を作成して、端末A1601に対して送信し、HTP Burstフレーム1612を送信したSIFS後に端末A1601からのBlockAckフレーム1613を受信する。但し、HTP Burstフレーム1612は、端末B1602に与えるTXOP時間1608を超えないように、Aggregateするデータ数を調整する。図25に示すように、HTP Burstフレーム1612は、BlockAckフレーム1611と端末A1601に対する送信データData1−B, Data2−B, Data3−B, Data4−Bの間にRIFS期間あけている為、他の実施の形態と同様に、送信レートを変更する事が出来、またNAVを通知する事が出来る。
次に端末C1603では、HTP Burstフレーム1611を受信した際に、端末B1602と同様に、MMPフレーム1604に記載された端末C1603に対するオフセット期間1609を取り出し、端末C1603の送受信状態管理部108にてオフセット期間1607のタイマーをかける。その後、HTP Burstフレーム1611内の端末C1603宛ての送信データData5−A, Data6−A, Data7−A, Data8−Aを受信して、BlockAckフレームを作成する。端末C1603の送受信状態管理部108にてかけた、端末C1603に対するオフセット期間1609のタイマーが切れると、端末C1603に与えるTXOP時間1610となり、端末C1603は、BlockAckフレーム1614を作成し、BlockAckフレーム1614のRIFS語に、端末A1601に対する送信データData1−C, Data2−C, Data3−C, Data4−CをAggregateしたHTP Burstフレーム1615を作成して、端末A1601に対して送信し、HTP Burstフレーム1615を送信したSIFS後に端末A1601からのBlockAckフレーム1616を受信して、MMPフレーム1614で開始する双方向通信期間1605を終了する。
但し、端末C1603に与えるTXOP時間1610は、端末B1602に与えるTXOP時間1608終了後に開始する。
また、図25に示すように、端末B1602の送信キューに蓄積するデータ数が少なく、端末B1602が、端末B1602に与えるTXOP時間1608を全て使用出来なかった場合に、TXOP時間を分け与えた端末A1601は、他の実施の形態と同様に、BlockAckフレームを受信したRIFS後に一つのPHYフレームを受信したことによって、与えたTXOP時間の通信が完了したことを示すとすると、余ったTXOP時間を、端末A1601からの他端末宛てのデータ送信等に使用してもよい。但し、余ったTXOP時間を使用する場合は、端末C1603に与えるTXOP時間1610の開始時間までの期間とする。
以上、本実施の形態による通信方法を用いる事によって、複数の端末に対して一度に送信期間を分け与えるマルチポールフレームを使用する通信方法において、BlockAckフレームの到達確率を送信データよりも向上させることができる。また、BlockAckフレームを送信データと異なるPHYフレームにて送信することにより、BlockAckフレームを用いて、帯域予約期間を再度通知することが可能となる。また、BlockAckフレームの、TXOPを分け与えられた端末が使用する期間を記載する事によって、分け与えられたTXOPの内の使用しない期間を通知可能となり、TXOPを分け与えられた端末が使用しない期間を有効に活用する事が出来る。
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
第1の実施の形態に係る無線通信装置のブロック図。 第1の実施の形態に係るタイミングチャート。 第1の実施の形態の端末Aの動作に係るフローチャート。 第1の実施の形態の端末Bの動作に係るフローチャート。 第1の実施の形態の端末の位置関係を示す図。 第1の実施の形態の変形例2に係る無線通信装置のブロック図。 第1の実施の形態の変形例2に端末Aの動作に係るフローチャート。 第1の実施の形態の変形例2に端末Bの動作に係るフローチャート。 第1の実施の形態の変形例3に係る無線通信装置のブロック図。 第1の実施の形態の変形例3に端末Aの動作に係るフローチャート。 第1の実施の形態の変形例3に端末Bの動作に係るフローチャート。 第1の実施の形態の変形例4に係るタイミングチャート。 第2の実施の形態に係るタイミングチャート。 第3の実施の形態に係るタイミングチャート。 第4の実施の形態の端末Bの動作に係るフローチャート。 第4の実施の形態の端末の位置関係を示す図。 第5の実施の形態に係るタイミングチャート。 第5の実施の形態の端末Aの動作に係るフローチャート。 第5の実施の形態の端末Bの動作に係るフローチャート。 第6の実施の形態に係るタイミングチャート。 第6の実施の形態の端末Aの動作に係るフローチャート。 第7の実施の形態に係るタイミングチャート。 第10の実施の形態のフレーム構成を示す図。 第11の実施の形態に係るタイミングチャート。 第12の実施の形態に係るタイミングチャート。
符号の説明
101・・・無線通信装置、102・・・送信データ管理部、103・・・
アクセス制御部、104・・・フレーム生成・送信部、105・・・受信処理部、106・・・送信キュー、107・・・送受信方法決定部、108・・・送受信状態管理部、109・・・キャリアセンス部。

Claims (18)

  1. 他の無線通信装置から、前記他の無線通信装置が送信することができる期間の一部を与えられ、前記他の無線通信装置との双方向通信を行う無線通信装置において、
    前記他の無線通信装置から、複数のデータフレームを受信する受信手段と、
    前記他の無線通信装置から受信した前記複数のデータフレームについての送達確認フレームを含む第1物理フレームと、前記他の無線通信装置を宛先とする複数のデータフレームを含む第2物理フレームとを生成する生成手段と、
    前記他の無線通信装置から与えられた期間内に、前記第1物理フレームを第1の伝送レートで送信し、該第1物理フレームを送信してから一定期間が経過した後に第2の伝送レートで前記第2物理フレームを送信する送信手段とを備え、
    前記第1物理フレームには、帯域を予約するための第1の帯域予約期間が記載されていて、
    前記送信手段が前記第1物理フレームを送信することにより、前記第1物理フレームを送信する時点で設定されている帯域予約期間を延長することを特徴とする無線通信装置。
  2. 前記第1の伝送レートで送信された物理フレームは、該第1の伝送レートをサポートする第1無線通信装置と、前記第1の伝送レートおよび前記第2の伝送レートをサポートする第2無線通信装置とによって受信可能であり、
    前記第2の伝送レートで送信された物理フレームは、前記第2無線通信装置によって受信可能であることを特徴とする請求項1に記載の無線通信装置。
  3. 前記第1物理フレームを送信する時点で設定されている帯域予約期間とは、前記受信手段が前記他の無線通信装置からRTSフレームを受信し、前記送信手段が前記他の無線通信装置へCTSフレームを送信することによって帯域が予約された期間であることを特徴とする請求項1または2に記載の無線通信装置。
  4. 前記第1の帯域予約期間は、前記他の無線通信装置を宛先とする複数のデータフレームの送信、および前記他の無線通信装置を宛先とする複数のデータフレームについての送達確認状況を確認するのに必要な期間を含むことを特徴とする請求項1乃至3のいずれか1項に記載の無線通信装置。
  5. 前記受信手段は、前記他の無線通信装置から、前記他の無線通信装置を宛先とする複数のデータフレームについての送達確認フレームと、さらに複数のデータフレームとを受信し、
    前記受信手段で受信した送達確認フレームには、帯域を予約するための第2の帯域予約期間が記載されていて、
    前記受信手段で受信した送達確認フレームは、前記第1の伝送レートで送信されることを特徴とする請求項1乃至4のいずれか1項に記載の無線通信装置。
  6. 前記第1物理フレームは、Durationフィールドを有し、
    前記Durationフィールドには、前記第1の帯域予約期間が記載されていて、
    前記第1の帯域予約期間は、前記分与時間よりも短いことを特徴とする請求項1乃至5のいずれか1項に記載の無線通信装置。
  7. 前記送信手段は、前記第1物理フレームを送信した後にデータフレームを送信するのではなく、前記他の無線通信装置から与えられた期間内に、前記他の無線通信装置を宛先とするデータフレームが無いことを通知するためのフレームを送信することを特徴とする請求項1乃至6のいずれか1項に記載の無線通信装置。
  8. 他の無線通信装置から、前記他の無線通信装置が送信することができる期間の一部を与えられ、前記他の無線通信装置との双方向通信を行う無線通信方法において、
    前記他の無線通信装置から、複数のデータフレームを受信し、
    前記他の無線通信装置から受信した前記複数のデータフレームについての送達確認フレームを含む第1物理フレームと、前記他の無線通信装置を宛先とする複数のデータフレームを含む第2物理フレームとを生成し、
    前記他の無線通信装置から与えられた期間内に、前記第1物理フレームを第1の伝送レートで送信し、
    前記他の無線通信装置から与えられた期間内に、該第1物理フレームを送信してから一定期間が経過した後に第2の伝送レートで前記第2物理フレームを送信し、
    前記第1物理フレームには、帯域を予約するための第1の帯域予約期間が記載されていて、
    前記第1物理フレームを送信することにより、前記第1物理フレームを送信する時点で設定されている帯域予約期間を延長することを特徴とする無線通信方法。
  9. 送信可能期間の一部を他の無線通信装置に与える無線通信装置において、
    前記他の無線通信装置から、複数のデータフレームを受信する受信手段と、
    前記他の無線通信装置から受信した前記複数のデータフレームについての送達確認フレームを含む第1物理フレームと、前記他の無線通信装置を宛先とする複数のデータフレームを含む第2物理フレームとを生成する生成手段と、
    前記送信可能期間中に、前記第1物理フレームを第1の伝送レートで送信し、該第1物理フレームを送信してから一定期間が経過した後に第2の伝送レートで前記第2物理フレームを送信する送信手段とを備え、
    前記第1物理フレームには、帯域を予約するための第1の帯域予約期間が記載されていて、
    前記送信手段が前記第1物理フレームを送信することにより、前記第1物理フレームを送信する時点で設定されている帯域予約期間を延長することを特徴とする無線通信装置。
  10. 送信可能期間の一部を他の無線通信装置に与える無線通信方法において、
    前記他の無線通信装置から、複数のデータフレームを受信し、
    前記他の無線通信装置から受信した前記複数のデータフレームについての送達確認フレームを含む第1物理フレームと、前記他の無線通信装置を宛先とする複数のデータフレームを含む第2物理フレームとを生成し、
    前記送信可能期間内に、前記第1物理フレームを第1の伝送レートで送信し、
    前記送信可能期間内に、該第1物理フレームを送信してから一定期間が経過した後に第2の伝送レートで前記第2物理フレームを送信し、
    前記第1物理フレームには、帯域を予約するための第1の帯域予約期間が記載されていて、
    前記送信手段が前記第1物理フレームを送信することにより、前記第1物理フレームを送信する時点で設定されている帯域予約期間を延長することを特徴とする無線通信方法。
  11. 送信可能期間の一部である分与期間を他の無線通信装置に与える無線通信装置において、
    前記他の無線通信装置へ、複数のデータフレームを送信する送信手段と、
    前記複数のデータフレームについての送達確認フレームを含む第1物理フレームと、複数のデータフレームを含む第2物理フレームとを受信する受信手段とを備え、
    前記送信手段は、前記第2物理フレームに含まれる複数のデータフレームについての送達確認フレームを含む第3物理フレームを送信し、
    前記第3物理フレームには、帯域を予約するための第1の帯域予約期間が記載されていて、
    前記第1の帯域予約期間は、前記送信可能期間の範囲内で設定され、
    前記送信手段が前記第3物理フレームを送信することにより、前記第3物理フレームを送信する時点で設定されている帯域予約期間を延長するとともに、前記他の無線通信装置へ分与期間を前記第1の帯域予約期間付与することを特徴とする無線通信装置。
  12. 前記送信可能期間は、継続してフレームを送信することができる期間の上限値と等しいことを特徴とする請求項11に記載の無線通信装置。
  13. 送信可能期間の一部である分与期間を他の無線通信装置に与える無線通信方法において、
    前記他の無線通信装置へ、複数のデータフレームを送信し、
    前記複数のデータフレームについての送達確認フレームを含む第1物理フレームと、複数のデータフレームを含む第2物理フレームとを受信し、
    前記第2物理フレームに含まれる複数のデータフレームについての送達確認フレームを含む第3物理フレームを送信し、
    前記第3物理フレームには、帯域を予約するための第1の帯域予約期間が記載されていて、
    前記第1の帯域予約期間は、前記送信可能期間の範囲内で設定され、
    前記第3物理フレームを送信することにより、前記第3物理フレームを送信する時点で設定されている帯域予約期間を延長するとともに、前記他の無線通信装置へ分与期間を前記第1の帯域予約期間付与することを特徴とする無線通信方法。
  14. アンテナをさらに具備し、
    前記受信手段は、前記アンテナを用いて前記複数のデータフレームを受信し、
    前記送信手段は、前記アンテナを用いて前記第1物理フレーム及び前記第2物理フレームを送信することを特徴とする請求項1−7のいずれか1項に記載の無線通信装置。
  15. 前記他の無線通信装置に対してデータフレームを送信する前記双方向通信を行う場合、前記第1の帯域予約期間には、RIFSと、前記第2の物理フレームの送信に要する時間と、SIFSと、前記第2の物理フレームに含まれる複数のデータフレームについての送達確認フレームを受信するのに要する時間とを含む期間が設定されることを特徴とする請求項1に記載の無線通信装置。
  16. 前記第1の物理フレームによって帯域予約される期間が送信可能期間の最大値を超過する場合に、前記第2の物理フレームの長さを調整することを特徴とする請求項15に記載の無線通信装置。
  17. 前記他の無線通信装置に対してデータフレームを送信する前記双方向通信を行う場合、前記第1の帯域予約期間には、RIFSと、前記第2の物理フレームの送信に要する時間と、SIFSと、前記第2の物理フレームに含まれる複数のデータフレームについての送達確認フレームを受信するのに要する時間とを含む期間が設定されることを特徴とする請求項8に記載の無線通信方法。
  18. 前記第1の物理フレームによって帯域予約される期間が送信可能期間の最大値を超過する場合に、前記第2の物理フレームの長さを調整することを特徴とする請求項17に記載の無線通信方法。
JP2006127110A 2006-04-28 2006-04-28 無線通信装置 Active JP4364210B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2006127110A JP4364210B2 (ja) 2006-04-28 2006-04-28 無線通信装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006127110A JP4364210B2 (ja) 2006-04-28 2006-04-28 無線通信装置

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2005178584A Division JP4364165B2 (ja) 2005-06-17 2005-06-17 無線通信装置

Publications (3)

Publication Number Publication Date
JP2006352844A JP2006352844A (ja) 2006-12-28
JP2006352844A5 JP2006352844A5 (ja) 2009-05-14
JP4364210B2 true JP4364210B2 (ja) 2009-11-11

Family

ID=37648133

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006127110A Active JP4364210B2 (ja) 2006-04-28 2006-04-28 無線通信装置

Country Status (1)

Country Link
JP (1) JP4364210B2 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008306419A (ja) * 2007-06-07 2008-12-18 Sony Corp 送信装置及び方法、並びにプログラム
JP2009060213A (ja) * 2007-08-30 2009-03-19 Sony Corp 無線通信装置、無線通信システム、無線通信方法及びプログラム
JP4901681B2 (ja) 2007-10-05 2012-03-21 株式会社東芝 無線通信装置及び無線通信方法
KR101452504B1 (ko) 2008-06-18 2014-10-23 엘지전자 주식회사 Vht 무선랜 시스템에서의 채널 접속 방법 및 이를지원하는 스테이션
US8730878B2 (en) 2008-08-20 2014-05-20 Qualcomm Incorporated Power and resource efficient APPDU based approach with scheduled block ACKS for WLAN
US9451417B2 (en) * 2013-11-27 2016-09-20 Qualcomm Incorporated System and method for multicast communications in Wi-Fi networks
US20190182773A1 (en) * 2017-12-10 2019-06-13 Mediatek Inc. Data transmission mechanism of time-division duplex communication system supporting different radio communication standards

Also Published As

Publication number Publication date
JP2006352844A (ja) 2006-12-28

Similar Documents

Publication Publication Date Title
JP4364165B2 (ja) 無線通信装置
JP4364210B2 (ja) 無線通信装置
KR100935976B1 (ko) 무선랜 시스템에서 다중 목적지 데이터 전송 방법
JP4331088B2 (ja) 通信装置および通信方法
KR102212170B1 (ko) 무선 네트워크에서 업링크 다중 사용자 다중 입출력 통신의 승인, 오류 복구 및 백오프 동작
JP4575265B2 (ja) 無線通信装置
US20070153830A1 (en) Methods and apparatus to provide fairness for wireless local area networks that use extended physical layer protection mechanisms
WO2004064331A1 (ja) 無線通信システム、無線通信装置及び無線通信方法、並びにコンピュータ・プログラム
CN102123020B (zh) 提供服务质量保证的分布式协作多址接入方法及系统
US8599809B2 (en) Routing method for wireless mesh networks and wireless mesh network system using the same
CN102685920A (zh) 移动Ad Hoc网络中的双信道预约接入控制方法
Li et al. A new MAC scheme for very high-speed WLANs
WO2015133646A1 (ja) 通信制御装置、無線端末、メモリーカード、集積回路および無線通信方法
US8724469B2 (en) Method and device for sending packets on a wireless local area network
JP2008028430A (ja) 送信装置
JP2007166094A (ja) 無線通信装置および方法
JP3938752B2 (ja) パケット通信方法およびシステム
JP4163643B2 (ja) 無線通信システム、無線基地局、無線端末及び無線通信方法
JP2006319787A (ja) 多段無線中継方法
Lee DCF Throughput Analysis of IEEE 802.11 a/g/n-based Mobile LAN over Correlated Fading Channel
Lee et al. A safe multiple access-rates transmission (SMART) scheme for IEEE 802.11 wireless networks
Santos et al. Multicast Collision Free (MCF) Mechanism over IEEE 802.11 WLANs
Alonso Zárate et al. Cooperative arq: A medium access control (mac) layer perspective
Li et al. Fragmentation based D-MAC protocol in wireless ad hoc networks
Chen et al. Group-based relay for reliable multicast service in error prone IEEE 802.11 e WLANs

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080613

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090327

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090421

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090617

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090728

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090818

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120828

Year of fee payment: 3

R151 Written notification of patent or utility model registration

Ref document number: 4364210

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120828

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130828

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250