JP2009049461A - 無線通信装置 - Google Patents
無線通信装置 Download PDFInfo
- Publication number
- JP2009049461A JP2009049461A JP2007210886A JP2007210886A JP2009049461A JP 2009049461 A JP2009049461 A JP 2009049461A JP 2007210886 A JP2007210886 A JP 2007210886A JP 2007210886 A JP2007210886 A JP 2007210886A JP 2009049461 A JP2009049461 A JP 2009049461A
- Authority
- JP
- Japan
- Prior art keywords
- block ack
- frame
- communication
- terminal
- bitmap field
- 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.)
- Pending
Links
- 238000004891 communication Methods 0.000 title claims abstract description 113
- 230000005540 biological transmission Effects 0.000 claims abstract description 29
- 230000004044 response Effects 0.000 claims description 17
- 238000012790 confirmation Methods 0.000 claims description 15
- OVGWMUWIRHGGJP-WVDJAODQSA-N (z)-7-[(1s,3r,4r,5s)-3-[(e,3r)-3-hydroxyoct-1-enyl]-6-thiabicyclo[3.1.1]heptan-4-yl]hept-5-enoic acid Chemical compound OC(=O)CCC\C=C/C[C@@H]1[C@@H](/C=C/[C@H](O)CCCCC)C[C@@H]2S[C@H]1C2 OVGWMUWIRHGGJP-WVDJAODQSA-N 0.000 description 35
- 101100161473 Arabidopsis thaliana ABCB25 gene Proteins 0.000 description 35
- 101000988961 Escherichia coli Heat-stable enterotoxin A2 Proteins 0.000 description 35
- 101100096893 Mus musculus Sult2a1 gene Proteins 0.000 description 35
- 101150081243 STA1 gene Proteins 0.000 description 35
- 238000000034 method Methods 0.000 description 24
- 101000752249 Homo sapiens Rho guanine nucleotide exchange factor 3 Proteins 0.000 description 13
- 102100021689 Rho guanine nucleotide exchange factor 3 Human genes 0.000 description 13
- 230000006870 function Effects 0.000 description 9
- 230000008569 process Effects 0.000 description 7
- 238000012545 processing Methods 0.000 description 7
- 238000010586 diagram Methods 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 5
- 230000008859 change Effects 0.000 description 2
- VJTAZCKMHINUKO-UHFFFAOYSA-M chloro(2-methoxyethyl)mercury Chemical compound [Cl-].COCC[Hg+] VJTAZCKMHINUKO-UHFFFAOYSA-M 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 241001417495 Serranidae Species 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
- H04L12/1868—Measures taken after transmission, e.g. acknowledgments
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1886—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
Abstract
【課題】無線LAN 通信環境下でMC/BC 通信による複数のフレーム送信に対して一つのフレームで送達確認応答(Block Ack) を行うことが可能な無線通信装置を提供する。
【解決手段】無線LAN 通信の規格IEEE802.11およびIEEE802.11e に準拠し、親局から特定多数の端末へ一斉送信するマルチキャスト通信および不特定多数の端末に一斉送信するブロードキャスト通信を行う機能を具備した無線通信システムに用いられる無線通信装置であって、親局からマルチキャストあるいはブロードキャストのデータフレームを送信する時に、送信内容に対する肯定確認応答としてACK フレームの返信の有無を識別する値をMAC ヘッダへ付与する機能を具備し、さらに、端末は、マルチキャスト通信あるいはブロードキャスト通信における複数のフレーム送信に対する肯定確認応答としてのBlock ACK フレームを要求された場合にBlock ACK フレームを一斉に通知する機能を具備する。
【選択図】 図5
【解決手段】無線LAN 通信の規格IEEE802.11およびIEEE802.11e に準拠し、親局から特定多数の端末へ一斉送信するマルチキャスト通信および不特定多数の端末に一斉送信するブロードキャスト通信を行う機能を具備した無線通信システムに用いられる無線通信装置であって、親局からマルチキャストあるいはブロードキャストのデータフレームを送信する時に、送信内容に対する肯定確認応答としてACK フレームの返信の有無を識別する値をMAC ヘッダへ付与する機能を具備し、さらに、端末は、マルチキャスト通信あるいはブロードキャスト通信における複数のフレーム送信に対する肯定確認応答としてのBlock ACK フレームを要求された場合にBlock ACK フレームを一斉に通知する機能を具備する。
【選択図】 図5
Description
本発明は、無線通信装置に係り、特に無線LAN 通信の規格IEEE802.11およびIEEE802.11e に準拠した無線LAN システムにおけるMAC 層プロトコルのフレームフォーマットおよびプロトコルシーケンスに関する。
無線LAN 通信においては、IEEE802.11(非特許文献1,2参照)で規定されたフレームフォーマットおよび通信制御用プロトコルにしたがって通信する。この無線LAN 通信の規格におけるMAC レイヤでのデータ通信方式として、3種類の方法が定義されている。すなわち、ある特定の一台の端末に対して送信を実施するユニキャスト(Uni Cast;UC)方式、全ての端末に対してデータ送信を実施するブロードキャスト(Broad Cast;BC)方式、1 台以上の特定の端末に対してデータ送信を実施するマルチキャスト(Multi Cast;MC)方式である。このうち、UC方式はデータ送信に対して送達確認(ACK) を実施する仕組みが導入されているが、後者のBC/MC 方式にはデータ送信に対するACK の仕組み、および、複数のフレームに対する確認応答(Block Acknowledgement;Block ACK;BA)の仕組みが導入されていない。
図16は、従来から利用されているUC利用時のACK 返信方法を示す。データフレームを受け取ると、無線LAN におけるデータ送信間隔の最小単位(short interframe space;SIFS) 後にACK を返信する規格になっている。ここで、IEEE802.11a ではSIFSは16μs 、IEEE802.11b ではSIFSは10μs と規定されている。このように、UCに対しては規格が定められているが、MC/BC に対しては規格が定められておらず、ACK を返信する必要もない。
しかし、送信データの内容によってはACK の返信が重要となる場面がある。例えば株価情報の配布など全員に同時に確実に株価を知らせなければ不平等が生じる場合、MC/BC 通信とその確認応答であるACK は必須である。
そこで、図17に示すように、MC/BC で送信されたデータフレームに対する確認応答として、UC通信で利用されるACK 返信方式をそのまま利用することを考えると、次のような問題が生じる。図17を見て分かるように、全ての端末(STA) においてACK の送信タイミングが同一であるので、複数のSTA から送信されてくるフレームが衝突し、情報が壊れてしまい、受信者は誰から送信されたフレームか識別できない。つまり、UCで利用されるACK 返信方式を工夫なしにMC/BC で利用することはできない。
上記したように、IEEE802.11およびIEEE802.11e で規定されている制御および管理フレームを使用したプロトコルシーケンスによるBC/MC のフレーム送信方法では、相手端末側でフレームを受信したことを送信端末側で認識する仕組みが存在せず、フレームによるACK 送信を行うことができない。そのため、下記のような問題が発生する。
(a)フレームロスが発生し、相手端末側でフレームを受信できなかったとしても、送信端末側ではそれを認識することができず、フレームの再送処理を行うことができない。
(b)仮に、UC通信のフレームにおける送達確認の仕組みを単純にBC/MC 通信のフレームの送達確認に適用すると、無線区間で送達確認フレームの衝突が発生し、送達確認フレームを相手端末へ正常に送信することができない。
なお、IEEE802.11e (非特許文献3参照)には、複数のフレームに対する確認応答(BA)フレームのフォーマットが定義されている。
インターネット<URL: http://grouper.ieee.org/groups/802/11> IEEE Std 802.11,1999 Edition IEEE Std 802.11e-2005
インターネット<URL: http://grouper.ieee.org/groups/802/11> IEEE Std 802.11,1999 Edition IEEE Std 802.11e-2005
現状では、無線LAN 通信環境下において、MC/BC 通信を利用して送信されたデータフレームに対してACK を如何に上手く返信するかが課題である。前記したように複数のSTA から送信されてくるフレームの衝突を回避するために、各STA の返信するタイミングが重ならないように、通信開始前にACK を返信する順序を決定してしまう方法が考えられる。この際、MC/BC 通信に対するACK の返信が必要なMC/BC データフレームを作成しておく。そして、MC/BC グループに参加する端末数が固定あるいは可変の場合に、MC/BC 通信に対するACK の返信のタイミングを送信元で事前に調節することにより、複数のSTA から送信されてくるフレームの衝突を回避し、受信者は誰から送信されたフレームか識別することが考えられる。また、ACK の返信を必要とするMC/BC データフレームを解釈できる端末を生成したり、ACK を返信するまでの待機時間を変更することが考えられる。
しかし、上記のように考えられる方法は、データが送られてくる度にACK を返信することで通信速度が低下するので、通信手順に関してさらに工夫を凝らすことが望ましい。
本発明は前記したように無線LAN 通信規格においてMC/BC 通信に対するACK およびBAの返信方法は定められていない現状に鑑みてなされたもので、無線LAN 通信環境下でのMC/BC 通信による複数のフレーム送信に対して一つのフレームで送達確認応答(Block Ack) を行うことが可能な無線通信装置を提供することを目的とする。
本発明は、無線LAN 通信の規格IEEE802.11およびIEEE802.11e に準拠し、親局から特定多数の端末へ一斉送信するマルチキャスト通信および不特定多数の端末に一斉送信するブロードキャスト通信を行う機能を具備した無線通信システムに用いられる無線通信装置であって、前記端末は、マルチキャスト通信あるいはブロードキャスト通信における複数のフレーム送信に対する肯定確認応答としてのBlock ACK フレームを要求された場合にBlock ACK フレームをマルチキャスト通信あるいはブロードキャスト通信により一斉に通知する機能を具備することを特徴とする。
本発明の無線通信装置によれば、無線LAN 通信環境下でMC/BC 通信においてある程度のデータを受信した後に一括して送達確認Block ACK を返信することができる。
以下、図面を参照して本発明の実施形態を説明する。この説明に際して、全図にわたり共通する部分には共通する参照符号を付す。
<第1の実施形態>
図1は、本発明の第1の実施形態に係る無線通信装置を用いた無線LAN 通信システムの一例を示す。図1に示す無線LAN 通信システムは、1つのBSS(Basic Service Set)内に親局であるAP(Access Point)100と、端末(子局)である1台以上のSTA (Station) 101,102,…が存在する場合を示している。APは、無線LAN 通信規格IEEE802.11およびIEEE802.11e に準拠し、特定多数の端末へ一斉送信するMC通信と、不特定多数の端末に一斉送信するBC通信を行う機能を具備している。STA は、無線LAN 通信規格IEEE802.11およびIEEE802.11e に準拠し、APおよび特定多数の端末へ一斉送信するMC通信と、APおよび不特定多数の端末に一斉送信するBC通信を行う機能を具備している。
図1は、本発明の第1の実施形態に係る無線通信装置を用いた無線LAN 通信システムの一例を示す。図1に示す無線LAN 通信システムは、1つのBSS(Basic Service Set)内に親局であるAP(Access Point)100と、端末(子局)である1台以上のSTA (Station) 101,102,…が存在する場合を示している。APは、無線LAN 通信規格IEEE802.11およびIEEE802.11e に準拠し、特定多数の端末へ一斉送信するMC通信と、不特定多数の端末に一斉送信するBC通信を行う機能を具備している。STA は、無線LAN 通信規格IEEE802.11およびIEEE802.11e に準拠し、APおよび特定多数の端末へ一斉送信するMC通信と、APおよび不特定多数の端末に一斉送信するBC通信を行う機能を具備している。
図2は、図1中のAP/STAのハードウェアを示すブロック図である。図2において、200は無線LAN ベースバンドチップ、201はCPU(Central Processing Unit)、202はMAC (Medium Access Controller)層ブロック、203はPHY (Physical layer)層ブロック、204はMEMC (Memory Controller)、205はPCIC (Peripheral Components Interconnect Controller)、206はSRAM (Static Random Access Memory)、207はSDRAM (Synchronous Dynamic Random Access Memory)、208はPCIC (Peripheral Components Interconnect Controller)、209はHOST PC (Host Personal Computer)、210は無線部(RF部) 、211はRFチップ、212はアンテナ部である。
ここで、図2に示したAP/STAにおける基本的な動作を説明しておく。HOST PC209から送信されるデータは、ホスト側PCIC208および無線LAN ベースバンドチップ200内のPCIC205を介してメモリ(SRAM206やSDRAM 207)に格納される。このSRAM206、SDRAM 207へのアクセスは、MEMC204を介して行われる。メモリ上に格納されたデータは、CPU 201によって処理され、その後、MAC 層ブロック202およびPHY 層ブロック203を通って無線部210へ出力され、RFチップ211からアンテナ部212へデータが渡り、最終的に無線LAN のフレームとして送信されることになる。また、データ受信は、前記データ送信とは逆のフローで処理される。
なお、本実施形態に記載されている内容の処理は、ソフトウェアおよびハードウェアのどちらで実施することも可能である。ハードウェアで実施する場合にはMAC 層ブロック202で処理され、ソフトウェアで実施する場合には、CPU 201が処理することになる。
図3は、図1に示す無線LAN 通信システムにおいて説明を簡易化するために、1つのBSS 内に1 台のAPと3台のSTA(STA1,STA2,STA3) が存在し、APがMC/BC 通信を利用してデータフレームを送信し、それを3台のSTA1,STA2,STA3で受信し、各STA1,STA2,STA3が指定された順序でACK フレームを返信する様子を示す。
図4は、図3において、APからMC/BC 通信によって各STA へデータフレームを送信し、各STA はAPおよび他のSTA へBlock ACK フレームを一斉に返信する様子を示す。
図5は、図3において、各STA がBC/BC 通信におけるデータフレームを受信した時に、各STA は受信内容に対する肯定確認応答としてBlock ACK フレームを定められた間隔と順序を遵守して返信する様子を示す。本例では、Block ACK フレームの返信はSTA1,STA2,STA3の順に行っている例を示している。
図6は、IEEE802.11e で定義されているBlock ACK フレームのフォーマットを示す。
図7は、図3において、STA1から送られてきたBlock ACK を受信したSTA2で、送られてきたBlock ACK フレームのBlock ACK BitmapフィールドとSTA2がこれから返信しようとするBlock ACK フレームのBlock ACK Bitmapフィールドを比較し、両者が一致する様子を示す。
図8は、図3において、STA1から送られてきたBlock ACK を受信したSTA2でBlock ACK Bitmapフィールドの比較結果が一致した場合にMAC アドレスを設定する際、Reserved領域に1を格納するとともに、Block ACK Bitmapフィールドを128 Byteから6 Byteに縮小する様子を示す。
図9は、図3において、STA1から送られてきたBlock ACK を受信したSTA2で、送られてきたBlock ACK フレームのBlock ACK BitmapフィールドとSTA2がこれから返信しようとするBlock ACK フレームのBlock ACK Bitmapフィールドを比較し、両者が一致しない様子を示す。
図10は、図3において、STA1から送られてきたBlock ACK を受信したSTA2でBlock ACK Bitmapフィールドの比較結果が一致しなかった場合にMAC アドレスを設定する際、BA ControlフィールドのReserved領域に0を格納するとともに、Block ACK Bitmapフィールドには従来通り受信したフレームを識別する値を格納する様子を示す。
図11は、図4において、STA1から送られてきたBlock ACK を受信したSTA2が、MC通信によってAP,STA1,STA3へBlock ACK フレームを返信する様子を示す。
図3において、APは、以下に述べる機能を具備する。
(a)MC/BC 通信におけるデータフレームを送信する時に、送信内容に対する肯定確認応答としてBlock ACK フレームの返信の時間と順序を指定する値をMAC ヘッダへ付与する。
(b)STA からBlock ACK フレームを受け取った時、まず、フレーム中のBA ControlフィールドにおけるReserved領域をチェックする。この領域が1であれば,Block ACK BitmapフィールドにMAC アドレスが格納されていると自覚し、かつ、そのMAC アドレスはこれまで自身が受信し記録してきたBlock ACK フレームのいずれかの送信元MAC アドレスと一致することを知る。その後、AP自身に保持されているBlock ACK フレームの送信元MAC アドレスと一致するフレームを検索し、それを発見したら、当該フレームのBlock ACK Bitmapフィールドを調査し、前記STA がAPから送られたどのデータフレームを受信できたかを知る。
これに対して、前記STA から送られてきたBlock ACK フレームを受け取り、フレーム中のBA ControlフィールドにおけるReserved領域をチェックした結果が0であった場合は、Block ACK Bitmapフィールドには従来通り前記STA が受信することのできたフレームの情報そのものが格納されていることを知る。
このような機能によれば、APは、どの端末がどのデータを受信できたか、逆に、どのデータを受信できなかったかを知ることが可能になる。
一方、図3において、各STA は、以下に述べる機能を具備する。
(a)送られてきたデータフレームを受信した時、APからMC/BC 通信で送信されたデータフレームであるか否かを判断する。
(b)上記判断の結果、APからMC/BC 通信で送信されたデータフレームであることを認識し、受信内容に対する肯定確認応答としてBlock ACK の返信が必要であることを知ると、その旨を表す所定の値(例えば10,1101 )を図2中のCPUのファームウェアに記録する。そして、図4および図5に示すようにMC通信を利用して、Block ACK フレーム(フォーマットは規格化されている)を定められた間隔と順序を遵守してMC通信(あるいはBC通信)によってAPおよび他のSTA へ返信する。
(c)前記判断の結果、他のSTA から送信されたBlock ACK フレームを受信した場合は、このBlock ACK フレームのBlock ACK Bitmapフィールドの値とこれからSTA 自身が返信しようとする自己の端末のBlock ACK フレームのBlock ACK Bitmapフィールドの値とを比較する。
(d)上記比較の結果、図7に示すように完全に一致した場合には、図8に示すようにSTA 自身が返信しようとしたBlock ACK フレーム中のBlock ACK BitmapフィールドにSTA1のMAC アドレス00:00:39:00:18:01 を格納し、STA1が返信したBlock ACK フレームのBlock ACK Bitmapフィールドと内容が一致する旨を記録する。そして、図8に示すようにBlock ACK Bitmapフィールドを元来の128 Byteから6 Byteに縮小する。
この時、STA 自身が返信するBlock ACK フレームのBlock ACK Bitmapフィールドには、本来の意味である「自己の端末がこれまでに受信したフレームを示す」という意味がない。ここでは、どの端末が返信したBlock ACK Bitmapフィールドと一致するかを示している。このようにBlock ACK Bitmapフィールドの意味が変化したことをBlock ACK フレームの受信者に通知する必要があるので、図8に示すようにBA ControlフィールドのReserved領域に1を設定する。
(e)前記比較の結果、図9に示すように一致しなかった場合には、図10に示すようにSTA 自身が返信しようとしたBlock ACK フレーム中のBlock ACK Bitmapフィールドに従来通り受信したフレームを識別する値を格納するとともに、BA ControlフィールドのReserved領域に0を格納する。
(f)以上の処理が完了したら、図11に示すようにMC通信(あるいはBC通信)によって、Immediate BA形式あるいはDelayed BA形式でBlock ACK フレーム(受信不可であったデータの欠落通知情報を含む)をAPおよび他のSTA へ送信する。
次に、第1の実施形態における動作例について図面を参照しながら説明する。いま、1台のAPから3台のSTA1,STA2,STA3に対してMCフレームを送信する場合を考える。この場合、1台のAPと3台のSTA1,STA2,STA3との間では、既に、通信確立用の制御プロトコルが動作し、通信できる環境(IEEE802.11 で規定されている通信可能な状態(State 3) にあるものとする。
図12は、第1の実施形態におけるAP側の動作例を示すフローチャートである。まず、APは、実施しようとするMC/BC 通信に対してBlock ACK を求めるか否かを判断する(ステップS1)。Block ACK を求めると判断した場合(Yes)には、Block ACK を求めることを示す識別子として、MAC ヘッダのフレーム制御部のタイプ(type)フィールド、サブタイプ(subtype) フィールドに所定の値を格納する(ステップS2)。その後、STA の新規加入を許すか否かを判断する(ステップS3)。STA の新規加入を許さないと判断した場合(No)には、Block ACK の返信順をMAC ヘッダに格納する(ステップS4)。これに対して、ステップS3で、新規加入を許すと判断した場合(Yes)には、APに現在接続されているSTA の数とBlock ACK の返信順をMAC ヘッダに格納する(ステップS5)。
上記ステップS4またはS5の後、MC/BC 通信を用いてデータを送信する(ステップS6)。なお、ステップS1でBlock ACK を求めないと判断した場合(No)にも、ステップS6に移る。
次に、Block ACK を要求するためのBlock ACK Request フレームを各STA へ送信する(ステップS7)。次に、Block ACK Request に対するBlock ACK フレームを受信する(ステップS8)。
次に、STA から送られてきたMAC ヘッダのBA Controlフィールドに含まれるReserved領域に格納されている値が1(または、第2の実施形態で後述する2)であるかを判断する(ステップS9)。前記Reserved領域に1(または2)が格納されていると判断した場合(Yes)には、Block ACK フレームが縮小されていると認識する(ステップS10)。この場合には、Block ACK フレームに含まれるBlock ACK Bitmapフィールドには、別の端末のアドレスが格納されているので、そのアドレスに基づいて、どの端末が送信したBlock ACK フレームのBlock ACK Bitmapフィールドと内容が同一であったかを知る(ステップS11)。
そして、次のデータを送信する(ステップS12)。この際、ステップS5へ移る。なお、ステップS9でReserved領域に1(または2)が格納されていなかったと判断した場合(No)にも、ステップS12に移る。
図13は、第1の実施形態におけるSTA 側の動作例を示すフローチャートである。STA1は、送信されてきたデータフレームを受信した時、APからMC/BC 通信で送信されたデータフレームであるか否かを判断する(ステップS1)。MC/BC 通信で送信されたデータフレームであると判断した場合(Yes)には、MAC ヘッダのtypeフィールドに10、subtype フィールドに1101が格納されているか判断する(ステップS2)。上記の値が格納されていると判断した場合(Yes)には、受信データのMAC ヘッダに格納されている自身のアドレス位置から、自身が何μs後にBlock ACK を返信するか算出する(ステップS3)。その後、別のSTA が送信したBlock ACK を受信済みか否かを判断する(ステップS4)。
上記ステップS4で受信済みであると判断した場合(Yes)には、自身がこれから返信しようとしているBlock ACK と別のSTA から送られてきたBlock ACK とを比較し、両者に違いがあるか判断する(ステップS5)。両者に違いがあると判断した場合(Yes)には、予定時間がきたらBlock ACK フレームを送信する(ステップS6)。
一方、ステップS4で別のSTA が送信したBlock ACK を受信済みでないと判断した場合(No)には、ステップS6に移る。また、ステップS5で両者に違いがないと判断した場合(No)には、Block ACK フレームのBlock ACK Bitmapフィールドに別のSTA のMAC アドレスを格納することでBlock ACK フレームを短縮し、Block ACK フレームを送信する(ステップS7)。
上記ステップS6またはステップS7の後、処理を終了する。なお、ステップS1においてMC/BC 通信で送信されたデータフレームでないと判断した場合(No)にも処理を終了する。また、ステップS2で所定の値が格納されていないと判断した場合(No)にも処理を終了する。
なお、上記した動作例の説明において、MC/BC で送信されてきたデータフレームに対して各端末が確認応答として返信するBlock ACK フレームの意味するところは、各端末とも同じである。各端末は、どの端末から送られてきたどのフレームに対するBlock ACK であるかをフレームに記載し、Block ACK をMC通信を利用して返信する機能を有する。本例の説明では、STA1が返信したBlock ACK の内容をMC通信を利用してAP、STA2、STA3に通知する。この際、各端末がそれぞれAPへ返信するのではなく,いずれか1つの端末が代表となって返信することにより、無線帯域の有効活用を図るとともに、APから次のフレームが投げられるまでの時間を短縮している。
上記した第1の実施形態によれば、APはMC/BC 通信の開始と終了を参加者に知らせ、各STA はMC/BC 通信の確認応答としてBlock ACK をAPへ返信する方式を実施することが可能となる。これにより、MC/BC 通信におけるデータ送信のスループットを向上させ、無線帯域の有効活用を図ることができる。
また、各STA は、他のSTA から返信されてきたBlock ACK フレームのBlock ACK Bitmapフィールドとこれから自信が返信しようとするBlock ACK フレームのBlock ACK Bitmapフィールドの値とを比較し、全てが一致した場合にMAC アドレスを設定する際、Block ACK Bitmapフィールドを縮小することができる。
すなわち、Block ACK フレームは、元来は152Byte の大きさであったが、本実施形態によれば、前記比較結果が一致した場合には30Byteに縮小することができる。よって、54Mbpsの通信速度を持った無線LAN 環境下において、38.5×n(n=1,2,3,…) の間隔でAPより送信されていたデータフレームを、20×n(n=1,2,3,…) の間隔で送信することができる。具体例を挙げると、MC通信に8台のSTA が参加していた場合、従来方式では38.5×8=308 μsの間隔でAPより送信されていたデータフレームを本実施形態の方式では約半分の20×8=160 μsで送信できる。
これに対して、各STA は、Block ACK Bitmapフィールドの比較結果が一致しなかった場合にMAC アドレスを設定する際、従来通りBlock ACK フレーム中のBlock ACK Bitmapフィールドに自身がこれまでAPより受信したフレームに関する情報を格納するとともに、BA ControlフィールドのReserved領域に0を格納する。以上の処理が完了したら、STA は、Block ACK フレームをAPおよび他のSTA へ送信する。
すなわち、ある端末が受信したBlock ACK フレーム中のBlock ACK Bitmapフィールドが、自身が返信しようとするフレームのBlock ACK Bitmapフィールドと不一致であった場合にも、MC通信を利用してBlock ACK を返信する。これにより、次にBlock ACK を返信しようとする他の端末に対して、そのBitmapフィールドはどの端末のBitmapフィールドと一致するのか、選択肢に幅を与えることができる。
<第2の実施形態>
第2の実施形態は、第1の実施形態と比べて、次の点が異なる。すなわち、各端末は、他の端末が送信したBlock ACK フレームに含まれるBlock ACK Bitmapフィールドの値と自己の端末が送信しようとするBlock ACK フレームに含まれるBlock ACK Bitmapフィールドの値とを比較した結果、一部または全てが一致した場合、他の端末が送信したBlock ACK Bitmapフィールドと共通している分量を数値としてBlock ACK フレームのBlock ACK Bitmapフィールドに設定するとともに、BA ControlフィールドのReserved領域に2を設定する機能を具備する。
第2の実施形態は、第1の実施形態と比べて、次の点が異なる。すなわち、各端末は、他の端末が送信したBlock ACK フレームに含まれるBlock ACK Bitmapフィールドの値と自己の端末が送信しようとするBlock ACK フレームに含まれるBlock ACK Bitmapフィールドの値とを比較した結果、一部または全てが一致した場合、他の端末が送信したBlock ACK Bitmapフィールドと共通している分量を数値としてBlock ACK フレームのBlock ACK Bitmapフィールドに設定するとともに、BA ControlフィールドのReserved領域に2を設定する機能を具備する。
図14は、STA1から送られてきたBlock ACK を受信したSTA2において、STA1から送られてきたBlock ACK フレームのBlock ACK BitmapフィールドとSTA2がこれから返信しようとするBlock ACK フレームのBlock ACK Bitmapフィールドを比較し、両者の一部(例えば先頭から5バイト)が一致した様子を示す。
図15は、STA2においてBlock ACK Bitmapフィールドの比較結果が一部一致した場合にMAC アドレスを設定する際、BA ControlフィールドのReserved領域に2を格納するとともに、Block ACK Bitmapフィールドには共通量(例えば5)と不一致部以降の受信したフレームを識別する値を格納する様子を示す。
STA1は、APからMC/BC 通信で送信されてきた送られてきたデータフレームを受信した時、Block ACK の返信が必要であることを知り、その旨を図2中のCPUのファームウェアに記録する。そして、STA1は、MC通信を利用してBlock ACK フレームをAP,STA2,STA3へ返信する。
STA2は、STA1から送信されたBlock ACK を受信した時、STA1から送られてきたBlock ACK フレームのBlock ACK BitmapフィールドとSTA2がこれから返信しようとするBlock ACK フレームのBlock ACK Bitmapフィールドを比較する。
比較の結果、図14に示すように両者の一部または全てが一致したならば、その旨をMAC アドレス中に記載する。具体的には、前記Block ACK Bitmapフィールドに格納されている値が先頭から何バイトが一致しているかを示す値を、図15に示すようにSTA2が返信しようとしたBlock ACK フレーム中のBlock ACK Bitmapフィールドの先頭1バイト分の箇所に設定する。これにより、本例では、Block ACK Bitmapフィールドを元来の128 Byteから122Byte に縮小するので、Block ACK フレームは、元来は152Byte の大きさであったが、本実施形態によれば148Byte に縮小する。
なお、上記動作において、STA2が返信するBlock ACK フレームのBlock ACK Bitmapフィールドは、本来の意味である「自己の端末がこれまでに受信したフレームを示す」という意味がない。ここでは、どの端末が返信したBlock ACK Bitmapフィールドと一致するかを示している。この意味的変化をBlock ACKフレームの受信者に通知する必要があるので、図15に示すようにBA ControlフィールドのReserved領域に2を設定し、Block ACK Bitmapフィールドの意味が変化したことを通知する。以上の処理が完了したら、STA2はMC通信を利用してBlock ACK フレームをAP,STA1,STA3へ送信する。
上記した第2の実施形態によれば、各STA1,STA2,STA3はBlock ACK Bitmapフィールドの比較結果が一致した場合にMAC アドレスを設定する際、Block ACK Bitmapフィールドに格納されている値が先頭から何バイトが一致しているかを示す値を先頭1バイト分の箇所に設定するので、Block ACK フレームは、元来は152Byte の大きさであったが、最高で25Byteにまで縮小することができる。
AP…親局、STA(STA1,STA2,STA3) …端末。
Claims (6)
- 無線LAN 通信の規格IEEE802.11およびIEEE802.11e に準拠し、親局から特定多数の端末へ一斉送信するマルチキャスト通信および不特定多数の端末に一斉送信するブロードキャスト通信を行う機能を具備した無線通信システムに用いられる無線通信装置であって、
前記端末は、マルチキャスト通信あるいはブロードキャスト通信における複数のフレーム送信に対する肯定確認応答としてのBlock ACK フレームを要求された場合にBlock ACKフレームをマルチキャスト通信あるいはブロードキャスト通信により一斉に通知する機能を具備することを特徴とする無線通信装置。 - 前記端末は、他の端末から送信された前記Block ACK フレームに含まれるBlock ACK Bitmapフィールドと自己の端末が送信しようとするBlock ACK フレームに含まれるBlock ACK Bitmapフィールドとを比較し、比較結果の一致/不一致に応じて異なる内容のBlock ACK フレームを返信する機能を具備することを特徴とする請求項1記載の無線通信装置。
- 前記端末は、他の端末から送信された前記Block ACK フレームに含まれるBlock ACK Bitmapフィールドと自己の端末が送信しようとするBlock ACK フレームに含まれるBlock ACK Bitmapフィールドとが一致した場合には、自己の端末が送信するBlock ACK フレームの当該フィールドを縮小し、一致した送信元の端末を識別する値を前記縮小したBlock ACK Bitmapフィールドに格納する機能を具備することを特徴とする請求項1記載の無線通信装置。
- 前記端末は、自己の端末がしようと送信するBlock ACK フレームのBlock ACK Bitmapフィールドに格納されている値が端末識別子であるか、または受信フレームの識別子であるかを識別する値を前記Block ACK フレームのBA ControlフィールドにおけるReserved領域に設定する機能を具備することを特徴とする請求項1記載の無線通信装置。
- 前記端末は、他の端末が送信した前記Block ACK フレームに含まれるBlock ACK Bitmapフィールドと自己の端末が送信しようとするBlock ACK フレームに含まれるBlock ACK Bitmapフィールドの一部または全てが一致した場合には、他の端末が送信した前記Block ACK Bitmapフィールドと共通している分量を示す数値をBlock ACK フレームのBlock ACK Bitmapフィールドに設定する機能を具備することを特徴とする請求項1記載の無線通信装置。
- 前記親局は、前記マルチキャスト通信あるいはブロードキャスト通信によりデータフレームを送信する時に、送信内容に対する肯定確認応答としてACK フレームの返信の有無を識別する値をMAC ヘッダへ付与する機能を具備することを特徴とする請求項1記載の無線通信装置。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007210886A JP2009049461A (ja) | 2007-08-13 | 2007-08-13 | 無線通信装置 |
US12/190,951 US8116249B2 (en) | 2007-08-13 | 2008-08-13 | Wireless communication system and wireless communication device |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007210886A JP2009049461A (ja) | 2007-08-13 | 2007-08-13 | 無線通信装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2009049461A true JP2009049461A (ja) | 2009-03-05 |
Family
ID=40362870
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2007210886A Pending JP2009049461A (ja) | 2007-08-13 | 2007-08-13 | 無線通信装置 |
Country Status (2)
Country | Link |
---|---|
US (1) | US8116249B2 (ja) |
JP (1) | JP2009049461A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2024029372A1 (ja) * | 2022-08-04 | 2024-02-08 | ソニーセミコンダクタソリューションズ株式会社 | 情報端末、通信方法、および通信装置 |
Families Citing this family (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100046367A1 (en) * | 2008-08-20 | 2010-02-25 | Qualcomm Incorporated | Power and resource efficient appdu based approach with scheduled data transmission times for wlan |
CN102187626B (zh) * | 2009-07-22 | 2014-06-04 | 松下电器产业株式会社 | 通信方法 |
US9173191B2 (en) * | 2009-12-20 | 2015-10-27 | Intel Corporation | Device, system and method of simultaneously communicating with a group of wireless communication devices |
KR101758909B1 (ko) * | 2010-02-18 | 2017-07-18 | 엘지전자 주식회사 | 무선 랜에서 수신 확인 전송 방법 및 장치 |
US8774088B2 (en) * | 2010-04-01 | 2014-07-08 | Intel Corporation | Legacy operations in a MU MIMO wireless network |
US9131395B2 (en) * | 2010-09-08 | 2015-09-08 | Broadcom Corporation | Acknowledgment and/or receiver recovery mechanisms for scheduled responses within multiple user, multiple access, and/or MIMO wireless communications |
KR101794250B1 (ko) * | 2011-03-08 | 2017-11-07 | 삼성전자주식회사 | 통신 장치, 통신 시스템 및 통신 방법 |
CN103178943A (zh) * | 2011-12-23 | 2013-06-26 | 华为技术有限公司 | 用于链路自适应的方法、装置和系统 |
US8924807B2 (en) * | 2011-12-28 | 2014-12-30 | Qualcomm Incorporated | Method and apparatus for acknowledgement using a group identifier |
US20130170430A1 (en) * | 2011-12-28 | 2013-07-04 | Qualcomm Incorporated | Method and apparatus for acknowledgement including a group identifier |
US20130336182A1 (en) * | 2012-06-13 | 2013-12-19 | Qualcomm Incorporated | Systems and methods for identifying enhanced frames for wireless communication |
US9451417B2 (en) | 2013-11-27 | 2016-09-20 | Qualcomm Incorporated | System and method for multicast communications in Wi-Fi networks |
WO2016006365A1 (ja) | 2014-07-11 | 2016-01-14 | ソニー株式会社 | 情報処理装置、通信システムおよび情報処理方法 |
JP6405042B2 (ja) * | 2014-10-27 | 2018-10-17 | エルジー エレクトロニクス インコーポレイティド | 無線lanシステムにおける多重ユーザブロック確認応答フレームの送受信方法及びそのための装置 |
WO2016204574A1 (ko) * | 2015-06-17 | 2016-12-22 | 주식회사 윌러스표준기술연구소 | 복수의 무선 통신 단말로부터 데이터를 수신하는 무선 통신 방법 및 무선 통신 단말 |
EP3399681A4 (en) * | 2016-01-19 | 2018-12-26 | Huawei Technologies Co., Ltd. | Feedback method and device for uplink channel |
CN107994976B (zh) | 2016-10-26 | 2021-06-22 | 华为技术有限公司 | 一种快速应答回复方法及装置 |
JP7444253B2 (ja) * | 2020-06-09 | 2024-03-06 | 日本電気株式会社 | 通信制御システム及び通信制御方法 |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4130648B2 (ja) * | 2004-10-19 | 2008-08-06 | 株式会社東芝 | 通信装置および通信方法 |
JP2008524898A (ja) * | 2004-12-15 | 2008-07-10 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | 電力制御を備えたマルチキャスト通信システム |
US20060268886A1 (en) * | 2005-05-04 | 2006-11-30 | Interdigital Technology Corporation | Wireless communication method and system for enhancing the capability of WLAN control frames |
TW201434302A (zh) * | 2006-02-14 | 2014-09-01 | Interdigital Tech Corp | Wlan服物中提供可靠多播服務方法及系統 |
US7804800B2 (en) * | 2006-03-31 | 2010-09-28 | Intel Corporation | Efficient training schemes for MIMO based wireless networks |
US20070258466A1 (en) * | 2006-04-24 | 2007-11-08 | Nokia Corporation | Reliable multicast/broadcast in a wireless network |
EP2119110B1 (en) * | 2007-03-12 | 2018-10-03 | Nokia Technologies Oy | Establishment of reliable multicast/broadcast in a wireless network |
-
2007
- 2007-08-13 JP JP2007210886A patent/JP2009049461A/ja active Pending
-
2008
- 2008-08-13 US US12/190,951 patent/US8116249B2/en not_active Expired - Fee Related
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2024029372A1 (ja) * | 2022-08-04 | 2024-02-08 | ソニーセミコンダクタソリューションズ株式会社 | 情報端末、通信方法、および通信装置 |
Also Published As
Publication number | Publication date |
---|---|
US8116249B2 (en) | 2012-02-14 |
US20090046618A1 (en) | 2009-02-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2009049461A (ja) | 無線通信装置 | |
JP5317235B2 (ja) | 無線ローカル・エリア・ネットワークにおいてマルチキャスト・データの確認応答および再伝送を行う方法および装置 | |
JP5637988B2 (ja) | 無線ローカル・エリア・ネットワークにおいてマルチキャスト・データの確認応答の要求および伝送を行う装置 | |
US9420631B2 (en) | WLAN peer-to-peer group owner negotiation | |
US9935785B2 (en) | System and method for full-duplex media access control using Request-to-Send signaling | |
JP2009049704A (ja) | 無線通信装置 | |
US10154384B2 (en) | Systems and methods for back channel communication | |
EP2858326B1 (en) | Service information discovery method and device | |
JP2009027645A (ja) | 無線通信装置 | |
US20160374114A1 (en) | Method and apparatus for indicating channel resource | |
US9769850B2 (en) | Method, device and system for transmitting data | |
WO2015133648A1 (ja) | 通信制御装置、無線端末、メモリーカード、集積回路および無線通信方法 | |
US9210551B2 (en) | Wireless communication method and wireless communication system requiring acknowledgement frame from receiving side | |
WO2012092848A1 (zh) | 数据发送、接收方法及装置和网络系统 | |
CN108347788B (zh) | 基于Slotted-FAMA协议利用传播时延的数据并发传输方法 | |
US11330084B2 (en) | Signaling of wireless station capabilities | |
US20170034684A1 (en) | Connection control method by communication terminal | |
WO2019127372A1 (zh) | 一种波束选取方法、终端设备及计算机存储介质 | |
TWI400898B (zh) | 通道狀態判斷方法及相關無線區域網路系統與直接連線設定建立方法 | |
JP6436144B2 (ja) | 無線通信方法、無線通信システム、及びプログラム | |
CN107635288B (zh) | 无线通信系统及相关的无线通信方法及无线装置 | |
US20160301620A1 (en) | Setting parameters pertaining to service period for reduced latency in wireless communication | |
JP2007013824A (ja) | 無線マルチキャスト通信方法 | |
WO2014186985A1 (zh) | 通信设备和无线通信方法 | |
CN107204824B (zh) | 一种用于低速信道的数据传输方法及系统 |