JP2022068653A - 通信装置、通信装置の制御方法、およびプログラム - Google Patents
通信装置、通信装置の制御方法、およびプログラム Download PDFInfo
- Publication number
- JP2022068653A JP2022068653A JP2020177444A JP2020177444A JP2022068653A JP 2022068653 A JP2022068653 A JP 2022068653A JP 2020177444 A JP2020177444 A JP 2020177444A JP 2020177444 A JP2020177444 A JP 2020177444A JP 2022068653 A JP2022068653 A JP 2022068653A
- Authority
- JP
- Japan
- Prior art keywords
- frame
- information
- sequence number
- data
- data frames
- 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 88
- 238000000034 method Methods 0.000 title claims abstract description 63
- 230000005540 biological transmission Effects 0.000 claims description 20
- 238000012545 processing Methods 0.000 description 25
- 230000004044 response Effects 0.000 description 11
- 230000006870 function Effects 0.000 description 5
- 238000012790 confirmation Methods 0.000 description 4
- 230000015654 memory Effects 0.000 description 4
- 238000003384 imaging method Methods 0.000 description 3
- 238000007796 conventional method Methods 0.000 description 2
- 230000003111 delayed effect Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000010276 construction Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1642—Formats specially adapted for sequence numbers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1614—Details of the supervisory signal using bitmaps
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1685—Details of the supervisory signal the supervisory signal being transmitted in response to a specific request, e.g. to a polling signal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L5/00—Arrangements affording multiple use of the transmission path
- H04L5/003—Arrangements for allocating sub-channels of the transmission path
- H04L5/0053—Allocation of signaling, i.e. of overhead other than pilot signals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/04—Error control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/10—Small scale networks; Flat hierarchical networks
- H04W84/12—WLAN [Wireless Local Area Networks]
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Description
本発明は、無線通信技術に関する。
IEEE(Institute of Electrical and Electronics Engineers、米国電気電子技術者協会)が策定している無線LAN(Local Area Network)通信規格として、IEEE802.11シリーズが知られている。IEEE802.11シリーズ規格としては、IEEE802.11a/b/g/n/ac/ax規格などの規格がある(特許文献1)。
IEEE802.11ax規格では、複数の無線パケットの受信について、一つのフレームで確認応答(Acknowledgement(ACK))を送信できるBlockAckフレームの拡張仕様が開示されている。IEEE802.11ax規格では、BlockAckフレーム中のBlockAck Bitmapで表現できるMPDU(MAC(Media Access Control) Protocol Data Unit)の数を、IEEE802.11acまでの64から256に拡張する仕様が開示されている。一度に確認応答が行えるMPDU数が増えることで、スループットの向上を実現している。
IEEEでは、さらなるスループットの向上や周波数利用効率の改善のため、IEEE802.11シリーズの新たな規格として、IEEE802.11be規格の策定が検討されている。IEEE802.11be規格では、一度に確認応答が行えるMPDU数をさらに512や1024へ拡張することが提案されている。この方式では、スループットの向上や周波数利用効率の改善が実現され得るが、一方で、当該拡張により、確認応答のデータ量が大きくなり、従来方式に比べ帯域を消費しまうという課題がある。
本発明は上記課題に鑑みてなされたものであり、少ないデータ量で確認応答を実現するための技術を提供することを目的とする。
上記目的を達成するため、本発明の一態様に係る無線通信装置は、以下の構成を有する。すなわち、IEEE802.11規格シリーズに準拠する通信装置であって、通信相手装置から、それぞれにシーケンス番号が付された複数のデータフレームを受信する受信手段と、前記受信手段により受信された前記複数のデータフレームに対する確認応答(Ack)フレームを生成する生成手段と、前記生成手段により生成された前記Ackフレームを前記通信相手装置に送信する送信手段と、を有し、前記生成手段は、前記Ackフレームに、前記受信された複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した1つ以上のデータフレーム群を特定する特定情報を含める。
本発明によれば、少ないデータ量で確認応答を実現するための技術が提供される。
以下、添付図面を参照して実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。
(ネットワークの構成)
図1に、本実施形態によるネットワークの構成例を示す。図1は、通信装置として、1つのAP(アクセスポイント)(AP102)と1つのSTA(ステーション/端末装置)(STA103)を含んだ構成を示している。なお、本実施形態の説明は、APとSTAどちらにも適用可能であり、どちらかに限定されない。図1に示すように、AP102が形成するネットワークは円101で示される。
図1に、本実施形態によるネットワークの構成例を示す。図1は、通信装置として、1つのAP(アクセスポイント)(AP102)と1つのSTA(ステーション/端末装置)(STA103)を含んだ構成を示している。なお、本実施形態の説明は、APとSTAどちらにも適用可能であり、どちらかに限定されない。図1に示すように、AP102が形成するネットワークは円101で示される。
本実施形態では、STA103は、AP102と無線リンク104を介してフレームを送受信できるものとする。無線リンク104は2.4GHz、5GHz、6GHz帯の周波数バンドのチャネルを使用することができるが、使用する周波数バンドはこれに限定されるものではなく、60GHz帯のように別の周波数バンドを使用しても良い。また、無線リンク104は一つのリンクに限定されない。STAとAPのMulti-Link通信のCapability情報に応じて、2.4GHz帯と5GHz帯のチャネルを組み合わせて使用しても良いし、6GHz帯の中から複数のチャネルを選択して組み合わせて使用しても良い。
なお、図1に示すネットワーク構成は一例であり、例えばさらに広範な領域に多数の通信装置を含むネットワークに対して、また、様々な通信装置の位置関係に対して、以下の議論を適用可能である。
(通信装置の構成)
次に、本実施形態による通信装置(AP、STA)の構成について説明する。図2に、本実施形態に係るAPのハードウェア構成例を示す。APは、そのハードウェア構成の一例として、記憶部201、制御部202、機能部203、入力部204、出力部205、通信部206及びアンテナ207を有する。なお、STAもAPと同様のハードウェア構成を有し、以下の説明をSTAに適用可能である。
次に、本実施形態による通信装置(AP、STA)の構成について説明する。図2に、本実施形態に係るAPのハードウェア構成例を示す。APは、そのハードウェア構成の一例として、記憶部201、制御部202、機能部203、入力部204、出力部205、通信部206及びアンテナ207を有する。なお、STAもAPと同様のハードウェア構成を有し、以下の説明をSTAに適用可能である。
記憶部201は、ROM(Read Only Memory)、RAM(Random Access Memory)の両方、または、いずれか一方により構成され、後述する各種動作を行うためのプログラムや、無線通信のための通信パラメータ等の各種情報を記憶する。なお、記憶部201として、ROM、RAM等のメモリの他に、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD-ROM、CD-R、磁気テープ、不揮発性のメモリカード、DVDなどの記憶媒体が用いられてもよい。
制御部202は、例えば、CPU(Central Processing Unit)やMPU(Micro Processing Unit)等のプロセッサ、ASIC(特定用途向け集積回路)、DSP(デジタルシグナルプロセッサ)、FPGA(Field Programmable Gate Array)等により構成される。制御部202は、記憶部201に記憶されたプログラムを実行することによりAP全体を制御する。なお、制御部202は、記憶部201に記憶されたプログラムとOS(Operating System)との協働によりAP全体を制御するようにしてもよい。
制御部202は、機能部203を制御して、撮像や印刷、投影等の所定の処理を実行する。機能部203は、APが所定の処理を実行するためのハードウェアである。例えば、APがカメラである場合、機能部203は撮像部であり、撮像処理を行う。また、例えば、APがプリンタである場合、機能部203は印刷部であり、印刷処理を行う。また、例えば、APがプロジェクタである場合、機能部203は投影部であり、投影処理を行う。機能部203が処理するデータは、記憶部201に記憶されているデータであってもよいし、後述する通信部206を介して他の通信装置と通信したデータであってもよい。
入力部204は、ユーザからの各種操作の受付を行う。出力部205は、ユーザに対して各種出力を行う。ここで、出力部205による出力とは、画面上への表示や、スピーカーによる音声出力、振動出力等の少なくとも1つを含む。なお、タッチパネルのように入力部204と出力部205の両方を1つのモジュールで実現するようにしてもよい。
通信部206は、IEEE802.11規格シリーズに準拠した無線通信の制御や、IP通信の制御を行う。本実施形態では、通信部206は、少なくともIEEE802.11ax規格に準拠した処理を実行することができる。また、通信部206はアンテナ207を制御して、無線通信のための無線信号の送受信を行う。APは通信部206を介して、画像データや文書データ、映像データ等のコンテンツを他の通信装置と通信する。
無線アンテナ207は、それぞれサブGHz帯、2.4GHz帯、5GHz帯、及び6GHz帯のいずれかが受信可能なアンテナである。無線アンテナ207はMIMO(Multi-Input Multi-Output)送受信を実現するために、物理的に一本以上のアンテナで構成されても良い。
図3に、本実施形態に係るAPの機能構成例を示す。APは、その機能構成の一例として、フレーム解析部301、フレーム生成部302、接続管理部303、フレーム送受信部304を有する。なお、STAもAPと同様の機能構成を有し、以下の説明をSTAに適用可能である。
フレーム解析部301は、通信相手装置(対向の通信装置)から受信したフレームを解析する。フレーム生成部302は、通信相手装置へ送信するフレームを生成する。接続管理部303は、通信相手装置との間の接続を管理する。例えば、接続管理部303は、各通信相手装置に対して、接続中のBlockAck(BA)の取り決め・合意(BlockAck Agreement)や、データのシーケンス番号(Sequence Number)の管理を行う。BlockAck AgreementやSequence Numberは、接続内のTID(Traffic Identifier(トラフィック(データ)の種別を表す識別子))ごとに管理される。フレーム送受信部304は、通信相手装置との間で、通信部206とアンテナ207(図2)を介してフレームを送受信する。
(APとSTA間の通信シーケンス)
図4に、AP102とSTA103間におけるデータ通信のための通信シーケンス図を示す。本シーケンスの処理は、AP102およびSTA103のそれぞれの電源が投入されたことに応じて開始されうる。あるいは、本シーケンスの処理は、AP102およびSTA103の少なくとも一方が、ユーザまたはアプリケーションから無線通信の開始を指示されたことに応じて開始されてもよい。
図4に、AP102とSTA103間におけるデータ通信のための通信シーケンス図を示す。本シーケンスの処理は、AP102およびSTA103のそれぞれの電源が投入されたことに応じて開始されうる。あるいは、本シーケンスの処理は、AP102およびSTA103の少なくとも一方が、ユーザまたはアプリケーションから無線通信の開始を指示されたことに応じて開始されてもよい。
初めに、F401にて、AP102とSTA103は、IEEE802.11規格に従接続処理を行うことにより、無線接続を確立する。本実施形態は、通信の暗号化なしの場合および暗号化ありの場合のいずれにも適用可能である。また、暗号化ありの場合の暗号化方式(セキュリティ方式)が、WEP(Wired Equivalent Privacy)、WPA(Wi-Fi Protected Access)1、WPA2、WPA3、WPS(Wi-Fi Protected Setup)や、他の方式であっても、本実施形態を適用可能である。
本例では、AP102からSTA103へデータ送信をする例を示す。F401にて接続確立後、F402においてAP102は、ADDBA RequestフレームをSTA103へ送信し、F403でその確認応答としてACKフレームを受信する。次にSTA103は、F404にてADDBA ResponseフレームをAP102へ送信し、F405でその確認応答としてACKフレームを受信する。本ADDBA RequestとADDBA Responseのやりとり(F402~F405の処理)が完了すると、AP102とSTA103の間で、AP102⇒STA103へのデータ送信に関して、BlockAck Agreementが構築される。
ここで、BlockAck Agreementについて説明する。ADDBA RequestフレームとADDBA Responseフレームには、BlockAckPolicyパラメータが含まれ、当該フレームを受信した通信装置は、当該パラメータに合意する場合にACKフレームを送信する。BlockAckPolicyパラメータは、Immediate(Immediate BlockAck)またはDelay(Delayed BlockAck)に設定される。図4の例はImmediate設定の場合であり、AP102はBlockAck Requestフレームを送信し、STA103は当該フレームを受信したことを受けて、BlockAckフレームを返信する。一方、BlockAckPolicyがDelayed設定の場合(不図示)、STA103は(F408のBlockAckフレームの返信の代わりに)ACKフレームを返信する。そしてSTA103は、その後に取得したTXOP(Transmission Opportunity)期間でBlockAckフレームを送信することになる。
また、ADDBA Requestフレームには、1つのBAセッションにおいて送信するデータの開始番号に関する情報(Starting Sequence Control)の各種パラメータ(Starting Sequence Number(開始シーケンス番号)等)が含まれる。Starting Sequence Numberの初期値は、ADDBA Request/Responseのやりとりによって決定されうる。その後のStarting Sequence Numberの更新はIEEE802.11規格規定の方法に従いうる。
また、ADDBA Request/Responseフレームには、自装置がサポートするBA Type(BlockAckのタイプを示すBA Typeフィールド)が含まれ得る。当該フレームを受信した通信装置は、通信相手装置のサポートするBA Typeを記録・管理する。
本実施形態では、AP102とSTA103それぞれの接続管理部303が、BlockAck Agreement構築時に、TIDに対する上記の各種パラメータや情報を記憶部201に記録し、管理する。
BlockAck Agreementが構築された後、AP102は、通信相手装置(対向の通信装置)であるSTA103からのACKフレームの受信前に、複数のデータフレームを送信することが可能になる。例えば、AP102は、F406(データ送信処理)において複数のMPDU(データフレーム)を送信し、STA103は複数のMPDUの確認応答としてF408においてBlock Ackフレームを送信する。上記のように、図4の例は、BlockAckPolicyパラメータにImmediateが設定されている場合である。AP102がBlockAck Requestフレームを送信(F407)した後に、STA103はBlockAckフレームを返信(F408)する。
図4の例では、AP102はF407でBlockAckRequestフレームをSTA103へ送信している。これに代えて、AP102は、F406のMPDU群の内の少なくとも一つのMPDU内のQoS Controlフィールドに含まれるAck PolicyサブフィールドをImplicit BlockAck Requestに設定してもよい。これにより、AP102は、BlockAckRequestフレーム(F407)を送信せずに、STA103へBlockAckフレームを要求することができる。
(BlockAckフレームの構成)
続いて、STA103が送信するBlockAckフレーム(図4ではF408に対応)のデータ量を低減するためのBlockAckフレームの構成について説明する。なお、図4ではAP102⇒STA103へのデータ送信の例を示したが、以下の説明は、STA103⇒AP102へのデータ送信にも同様に適用可能である。
続いて、STA103が送信するBlockAckフレーム(図4ではF408に対応)のデータ量を低減するためのBlockAckフレームの構成について説明する。なお、図4ではAP102⇒STA103へのデータ送信の例を示したが、以下の説明は、STA103⇒AP102へのデータ送信にも同様に適用可能である。
図5(a)~(c)に、802.11axにおけるBlockAckフレームの構成を示す。図5(a)~(c)共通の説明として、Octests、Bitsはそれぞれのフィールドのサイズを示す。variableと示されているフィールドは可変長であることを意味する。また、参照符号の付いていないフィールドの説明は割愛する。
図5(a)にBlockAckフレーム全体の構成を示す。BlockAckフレームは、MAC headerフィールド501、BA Controlフィールド502、BA Informationフィールド503とFCSフィールドから構成される。
図5(b)にBA Controlフィールド502の構成を示す。BA Controlフィールド502は、BA Ack Policyサブフィールド、BA Typeサブフィールド504、Reservedサブフィールド505、TID_INFOサブフィールドから構成される。BA Informationフィールド503は、BA Typeサブフィールド504に設定される情報に応じてそのフォーマットが規定される。IEEE802.11ax規格においては、BA Type0、4~5、7~9、12~15がReserved領域に指定されている。本実施形態では、このReserved領域の内の少なくとも一つを使用して、新たなBA Typeを規定する。
図5(c)に、新たなBA Typeで規定するBA Informationフィールド503の構成を示す。BA Informationフィールド503は、BA Subtypeサブフィールド507、ACK Infoサブフィールド506から構成される。BA Subtypeサブフィールド507は、Bitsに記載の通り0が設定されてもよい。この場合、BA Subtypeに相当する情報をBA Typeサブフィールド504内のReserved領域、もしくはReservedサブフィールド505のReserved領域を用いて表現しても良い。なお、ここで提示したBA Subtype、ACK Infoの名称は一例であり、これに限定されない。
(ACK Infoサブフィールドの構成)
本実施形態における、図5(c)におけるACK Infoサブフィールド506のいくつかの構成例について、図6と図7を用いて説明する。なお、以下に記載する各部の名称、サイズ、格納する順番については一例であり、同様な機能を果たすものであればこれに限定されない。
本実施形態における、図5(c)におけるACK Infoサブフィールド506のいくつかの構成例について、図6と図7を用いて説明する。なお、以下に記載する各部の名称、サイズ、格納する順番については一例であり、同様な機能を果たすものであればこれに限定されない。
≪受信したMPDUを示すACK Infoサブフィールドの構成(構成例1~3)≫
図6(a)~(c)に、ACK Infoサブフィールド506の構成例1~3を示す。構成例1~3は、STA103が受信したMPDUに関する情報を送信する場合の構成例である。構成例1~3共通の構成として、ACK Infoサブフィールド506は、ACK Info全体のメタ情報を含むACK Infoヘッダ部(ACK Infoヘッダ部601、607、814に対応)と、受信したフレーム群(データフレーム群)を特定する特定情報(フレーム群602、603、609、610、615、616に対応)を含むACK Infoデータ部で構成される。なお、ここで示したACK Infoヘッダ、ACK Infoデータという名称は一例であり、これに限定されない。
図6(a)~(c)に、ACK Infoサブフィールド506の構成例1~3を示す。構成例1~3は、STA103が受信したMPDUに関する情報を送信する場合の構成例である。構成例1~3共通の構成として、ACK Infoサブフィールド506は、ACK Info全体のメタ情報を含むACK Infoヘッダ部(ACK Infoヘッダ部601、607、814に対応)と、受信したフレーム群(データフレーム群)を特定する特定情報(フレーム群602、603、609、610、615、616に対応)を含むACK Infoデータ部で構成される。なお、ここで示したACK Infoヘッダ、ACK Infoデータという名称は一例であり、これに限定されない。
STA103は、AP102から受信したデータをシーケンス番号が連番である一連のデータの塊ごと(一連のデータフレームごとに)に、フレーム群として区別する。つまり、受信したデータのシーケンス番号に抜けが発生した場合、そこでフレーム群としては区切られることになる。STA103は、受信したすべてのフレーム群についての情報をACK Infoサブフィールド506に含めた確認応答(BlockAck)を送信する。従来のBlockAck Bitmap方式では、一つのMPDUに一つのビットを割り当てていたが、これをフレーム群という塊で扱うことで、全体のデータ量を低減し、BlockAckフレームの送信に消費する帯域を低減することができる。なお、ACK Infoデータ部には0個以上のフレーム群情報が含まれ、受信できたフレーム群の数に応じてその数は変動する。ACK Infoヘッダ部に含まれるデータ長はACK Infoヘッダ部のデータ長分を含んでもよいし、含まなくてもよい。
<構成例1>
図6(a)に、ACK Infoサブフィールド506の構成例1を示す。構成例1におけるACK Infoヘッダ部601は、ACK Infoデータ部に含まれるデータ長(後続の全てのフレーム群を指定する情報のデータ長)を示す情報を含む。当該情報は、データフレーム群の終了を示す情報でありうる。データ長を示す方法として、後続のACK Info部のデータ長をビット単位、バイト単位、フレーム群数(本例においては1フレーム群あたり24ビットの構成)単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。
図6(a)に、ACK Infoサブフィールド506の構成例1を示す。構成例1におけるACK Infoヘッダ部601は、ACK Infoデータ部に含まれるデータ長(後続の全てのフレーム群を指定する情報のデータ長)を示す情報を含む。当該情報は、データフレーム群の終了を示す情報でありうる。データ長を示す方法として、後続のACK Info部のデータ長をビット単位、バイト単位、フレーム群数(本例においては1フレーム群あたり24ビットの構成)単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。
IEEE802.11においてSequence Number(シーケンス番号)は12ビットで表現され、0~4095の値で表現される。構成例1では、フレーム群602、603の表現方法として、各フレーム群における開始シーケンス番号(Start SN)604と終了シーケンス番号(End SN)605を用いる。開始シーケンス番号604と終了シーケンス番号605はそれぞれ12ビットで表現可能である。開始シーケンス番号604は、各受信フレーム群の先頭に相当するMPDUのシーケンス番号を示す。終了シーケンス番号605は、各受信フレーム群の終了に相当するMPDUのシーケンス番号を示す。
<構成例2>
図6(b)に、ACK Infoサブフィールド506の構成例2を示す。構成例2におけるACK Infoヘッダ部607は、構成例1と同様に、ACK Infoデータ部に含まれるデータ長を示す情報を含む。データ長を示す方法として、後続のACK Info部のデータ長をビット単位、バイト単位、フレーム群数(本例においては1フレーム群あたり12+Count Size部608で示すビット数の構成)単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。構成例2では、ACK Infoヘッダ部607は、さらにCount Size部608を含む。Count Size部608は、フレーム群609、610のCount部(Count部612に対応)のサイズを示す。
図6(b)に、ACK Infoサブフィールド506の構成例2を示す。構成例2におけるACK Infoヘッダ部607は、構成例1と同様に、ACK Infoデータ部に含まれるデータ長を示す情報を含む。データ長を示す方法として、後続のACK Info部のデータ長をビット単位、バイト単位、フレーム群数(本例においては1フレーム群あたり12+Count Size部608で示すビット数の構成)単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。構成例2では、ACK Infoヘッダ部607は、さらにCount Size部608を含む。Count Size部608は、フレーム群609、610のCount部(Count部612に対応)のサイズを示す。
構成例2では、フレーム群609、610の表現方法として、各フレーム群における開始シーケンス番号(Start SN)611とCount部612を用いる。開始シーケンス番号611は、構成例1と同様に、各受信フレーム群の先頭に相当するMPDUのシーケンス番号を示す。Count部612は、開始シーケンス番号611から開始し、何個分の連続するシーケンス番号を持つMPDUを受信したかの個数を示す情報を保持する。Count Size部608で指定するCount部のサイズが小さいと、フレーム群として表現できる最大MPDU数が小さくなるが、ひとつのフレーム群を表現するために必要なデータ長を小さくすることができる。一方、Count Size部608で指定するCount部のサイズが大きいと、フレーム群として表現できる最大MPDU数が大きくなるが、ひとつのフレーム群を表現するために必要なデータ長が大きくなってしまう。どのCount Sizeを使用するかは本例においては限定しない。開始シーケンス番号は、12ビットで表現可能である。
本構成例では、一つのフレーム群内で表現できるMPDU数の上限がCount Size部608によって規定されるため、連続するシーケンス番号を持つMPDUであっても別のフレーム群として表現される場合がある。
<構成例3>
図6(c)に、ACK Infoサブフィールド506の構成例3を示す。構成例3におけるACK Infoヘッダ部614は、構成例1と同様に、ACK Infoデータ部に含まれるデータ長を示す情報を含む。データ長を示す方法として、後続のACK Info部のデータ長をビット単位、バイト単位、フレーム群数(本例においては1フレーム群あたり16+各フレームのCount Size部で示すビット数の構成)単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。構成例3では、フレーム群615、616の表現方法として、各フレーム群における開始シーケンス番号(Start SN)617とCount Size部618とCount部619を用いる。構成例2でACK Infoヘッダ部607に格納したCount Size部608を、Count Size部618としてそれぞれのフレーム群内に格納する。これにより、ヘッダ部でCount Sizeを固定せずに、各フレーム群で適切なCount Sizeを設定することが可能になる。フレーム群で表現したいフレーム数が多い場合はCount Sizeを大きく設定し、少ない場合は小さく設定することで、適切なCount Sizeが設定できる。
図6(c)に、ACK Infoサブフィールド506の構成例3を示す。構成例3におけるACK Infoヘッダ部614は、構成例1と同様に、ACK Infoデータ部に含まれるデータ長を示す情報を含む。データ長を示す方法として、後続のACK Info部のデータ長をビット単位、バイト単位、フレーム群数(本例においては1フレーム群あたり16+各フレームのCount Size部で示すビット数の構成)単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。構成例3では、フレーム群615、616の表現方法として、各フレーム群における開始シーケンス番号(Start SN)617とCount Size部618とCount部619を用いる。構成例2でACK Infoヘッダ部607に格納したCount Size部608を、Count Size部618としてそれぞれのフレーム群内に格納する。これにより、ヘッダ部でCount Sizeを固定せずに、各フレーム群で適切なCount Sizeを設定することが可能になる。フレーム群で表現したいフレーム数が多い場合はCount Sizeを大きく設定し、少ない場合は小さく設定することで、適切なCount Sizeが設定できる。
≪受信できなかったMPDUを示すACK Infoサブフィールドの構成(構成例4~6)≫
図7(a)~(c)に、ACK Infoサブフィールド506の構成例4~6を示す。構成例4~6は、STA103が受信できなかったMPDUに関する情報を送信する場合の構成例である。構成例4~6共通の構成として、ACK Infoサブフィールド506は、ACK Info全体のメタ情報を含むACK Infoヘッダ部(ACK Infoヘッダ部721、724、727に対応)と、受信できなかったフレーム群(データフレーム群)を特定する特定情報(フレーム群702、703、709、710、715、716に対応)を含むACK Infoデータ部で構成される。なお、ここで示したACK Infoヘッダ、ACK Infoデータという名称は一例であり、これに限定されない。
図7(a)~(c)に、ACK Infoサブフィールド506の構成例4~6を示す。構成例4~6は、STA103が受信できなかったMPDUに関する情報を送信する場合の構成例である。構成例4~6共通の構成として、ACK Infoサブフィールド506は、ACK Info全体のメタ情報を含むACK Infoヘッダ部(ACK Infoヘッダ部721、724、727に対応)と、受信できなかったフレーム群(データフレーム群)を特定する特定情報(フレーム群702、703、709、710、715、716に対応)を含むACK Infoデータ部で構成される。なお、ここで示したACK Infoヘッダ、ACK Infoデータという名称は一例であり、これに限定されない。
STA103は、AP102から受信できなかったデータをシーケンス番号が連番である一連のデータの塊ごとに、フレーム群として区別する。つまり、受信できなかったデータのシーケンス番号に抜けが発生した場合、そこでフレーム群としては区切られることになる。STA103は、受信できなかったすべてのフレーム群についての情報をACK Infoサブフィールド506に含めた確認応答(BlockAck)を送信する。従来のBlockAck Bitmap方式では、一つのMPDUに一つのビットを割り当てていたが、これをフレーム群という塊で扱うことで全体のデータ量を低減し、BlockAckフレームの送信に消費する帯域を低減することができる。なお、ACK Infoデータ部には0個以上のフレーム群情報が含まれ、受信できなかったフレーム群の数に応じて変動する。
構成例4~6が構成例1~3と異なる点は、ACK Infoヘッダ部に新しく受信できたデータフレームのうち最初と最後のフレームを識別する情報(本例では1以上のフレーム群の開始シーケンス番号と終了シーケンス番号を示す情報)を含むことである。これは、構成例4~6においては、ACK Infoデータ部に受信できなかったMPDUに関する情報を含むため、それのみではどこからどこまでのシーケンス番号を受信できたか、特定することができないためである。ACK Infoサブフィールド506全体として表現するフレーム群の開始シーケンス番号と終了シーケンス番号を示す情報と、受信できなかったMPDUのシーケンス番号を組み合わせることで、受信できたMPDUのシーケンス番号を特定することができる。ACK Infoヘッダ部に含まれるデータ長はACK Infoヘッダ部のデータ長分を含んでもよいし、含まなくてもよい。
<構成例4>
図7(a)に、ACK Infoサブフィールド506の構成例4を示す。構成例4におけるACK Infoヘッダ部721は、ACK Infoデータ部に含まれるデータ長(後続の全てのフレーム群を指定する情報のデータ長)を示す情報701を含む。当該情報は、データフレーム群の終了を示す情報でありうる。データ長を示す方法として、後続のACK Info部のデータ長をビット単位、バイト単位、フレーム群数(本例においては1フレーム群あたり24ビットの構成)単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。
図7(a)に、ACK Infoサブフィールド506の構成例4を示す。構成例4におけるACK Infoヘッダ部721は、ACK Infoデータ部に含まれるデータ長(後続の全てのフレーム群を指定する情報のデータ長)を示す情報701を含む。当該情報は、データフレーム群の終了を示す情報でありうる。データ長を示す方法として、後続のACK Info部のデータ長をビット単位、バイト単位、フレーム群数(本例においては1フレーム群あたり24ビットの構成)単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。
IEEE802.11においてSequence Number(シーケンス番号)は12ビットで表現され、0~4095の値で表現される。構成例4では、フレーム群702、703の表現方法として、各フレーム群における開始シーケンス番号(Start SN)704と終了シーケンス番号(End SN)705を用いる。開始シーケンス番号704と終了シーケンス番号705はそれぞれ12ビットで表現可能である。開始シーケンス番号704は、各受信できなかったフレーム群の先頭に相当するMPDUのシーケンス番号を示す。終了シーケンス番号705は、受信できなかったフレーム群の終了に相当するMPDUのシーケンス番号を示す。構成例4ではACK Infoヘッダ部721内に受信できたフレーム群の開始シーケンス番号722と終了シーケンス番号723を含む。
<構成例5>
図7(b)に、ACK Infoサブフィールド506の構成例5を示す。構成例5におけるACK Infoヘッダ部607は、構成例4と同様に、ACK Infoデータ部に含まれるデータ長を示す情報を含む。データ長を示す方法として、後続のACK Info部のデータ長をビット単位、バイト単位、フレーム群数(本例においては1フレーム群あたり12+Count Size部708で示すビット数の構成)単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。構成例5では、ACK Infoヘッダ部724は、さらにCount Size部708を含む。Count Size部708は、フレーム群709、710のCount部(Count部712に対応)のサイズ、さらにACK Infoヘッダ部724に含まれるCount部726のサイズも示す。
図7(b)に、ACK Infoサブフィールド506の構成例5を示す。構成例5におけるACK Infoヘッダ部607は、構成例4と同様に、ACK Infoデータ部に含まれるデータ長を示す情報を含む。データ長を示す方法として、後続のACK Info部のデータ長をビット単位、バイト単位、フレーム群数(本例においては1フレーム群あたり12+Count Size部708で示すビット数の構成)単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。構成例5では、ACK Infoヘッダ部724は、さらにCount Size部708を含む。Count Size部708は、フレーム群709、710のCount部(Count部712に対応)のサイズ、さらにACK Infoヘッダ部724に含まれるCount部726のサイズも示す。
構成例5では、フレーム群709、710の表現方法として、各フレーム群における開始シーケンス番号(Start SN)711とCount部712を用いる。開始シーケンス番号711は、構成例4と同様に、受信できなかったフレーム群の先頭に相当するMPDUのシーケンス番号を示す。Count部712は、開始シーケンス番号711から開始し、何個分の連続するシーケンス番号を持つMPDUを受信できなかったかの個数を示す情報を保持する。Count Size部708で指定するCount部のサイズが小さいと、フレーム群として表現できる最大MPDU数が小さくなるが、ひとつのフレーム群を表現するために必要なデータ長を小さくすることができる。一方、Count Size部708で指定するCount部のサイズが大きいと、フレーム群として表現できる最大MPDU数が大きくなるが、ひとつのフレーム群を表現するために必要なデータ長が大きくなってしまう。どのCount Sizeを使用するかは本例においては限定しない。開始シーケンス番号は12ビットで表現可能である。
本構成例では、一つのフレーム群内で表現できるMPDU数の上限がCount Size部708によって規定されるため、連続するシーケンス番号を持つMPDUであっても別のフレーム群として表現される場合がある。
また、本構成例では、ACK Infoヘッダ部724は、受信できたフレーム群の開始シーケンス番号725とそこから終了シーケンス番号までの総数(個数)を意味するCount部726を含む。ACK Infoヘッダ部724内のCount部726のサイズはCount Size部708で規定せず、12ビットに固定する、もしくはCount部726の情報を示すCount Size部を別途ACK Infoヘッダ部に保持しても良い。
<構成例6>
図7(c)に、ACK Infoサブフィールド506の構成例6を示す。構成例6におけるACK Infoヘッダ部727は、構成例4と同様に、ACK Infoデータ部に含まれるデータ長を示す情報を含む。データ長を示す方法として、後続のACK Info部のデータ長をビット単位、バイト単位、フレーム群数(本例においては1フレーム群あたり16+各フレームのCount Size部で示すビット数の構成)単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。構成例6では、フレーム群715、716の表現方法として、各フレーム群における開始シーケンス番号(Start SN)717とCount Size部718とCount部719を用いる。構成例5でACK Infoヘッダ部607に格納したCount Size部708をそれぞれのフレーム群内に格納する。これにより、ヘッダ部でCount Sizeを固定せずに、各フレーム群で適切なCount Sizeを設定することが可能になる。フレーム群で表現したいフレーム数が多い場合はCount Sizeを大きく設定し、少ない場合は小さく設定することで、適切なCount Sizeが設定できる。
図7(c)に、ACK Infoサブフィールド506の構成例6を示す。構成例6におけるACK Infoヘッダ部727は、構成例4と同様に、ACK Infoデータ部に含まれるデータ長を示す情報を含む。データ長を示す方法として、後続のACK Info部のデータ長をビット単位、バイト単位、フレーム群数(本例においては1フレーム群あたり16+各フレームのCount Size部で示すビット数の構成)単位で格納することができる。なお、データ長を示すことができればこの方法に限定されない。構成例6では、フレーム群715、716の表現方法として、各フレーム群における開始シーケンス番号(Start SN)717とCount Size部718とCount部719を用いる。構成例5でACK Infoヘッダ部607に格納したCount Size部708をそれぞれのフレーム群内に格納する。これにより、ヘッダ部でCount Sizeを固定せずに、各フレーム群で適切なCount Sizeを設定することが可能になる。フレーム群で表現したいフレーム数が多い場合はCount Sizeを大きく設定し、少ない場合は小さく設定することで、適切なCount Sizeが設定できる。
また、本構成例では、ACK Infoヘッダ部727は、受信できたフレーム群の開始シーケンス番号728とそこから終了シーケンス番号までの総数を意味するCount部730、Count部730のサイズ情報を示すCountSize部729を含む。
構成例4に関し、受信したフレームが1つであった場合、ACK Infoヘッダ部721における開始シーケンス番号722と終了シーケンス番号723に、同じシーケンス番号が設定されてもよい。また、構成例4に関し、1つもフレームを正常に受信できなかった場合、1つのフレーム群(すなわち、フレーム群702のみ)がACK Infoサブフィールド506に含まれるように構成されてもよい。ここで、開始シーケンス番号704には、すでに受信していた、送信側が送信するデータの開始番号に関する情報に基づく値(Starting Sequence Controlで示される値等)が設定されてもよい。構成例5、6についても同様である。
(ACK Infoサブフィールドの構成の通知方法)
BlockAckフレームの送信側は、構成例1~6のいずれかでACK Infoサブフィールド506を構成するかを該フレームにおいて特定(指定)し、受信側に通知することができる。例えば、構成例1~6のいずれを用いるかを、BA Typeサブフィールド504、Reservedサブフィールド505、BA Subtypeサブフィールド507の少なくともいずれかを用いて、特定することができる。
BlockAckフレームの送信側は、構成例1~6のいずれかでACK Infoサブフィールド506を構成するかを該フレームにおいて特定(指定)し、受信側に通知することができる。例えば、構成例1~6のいずれを用いるかを、BA Typeサブフィールド504、Reservedサブフィールド505、BA Subtypeサブフィールド507の少なくともいずれかを用いて、特定することができる。
例えば、BA Typeサブフィールド504のReservedを意味するBA Type0を、構成例1~6のいずれかを用いることを意味するBA Typeと規定しても良い。さらに、構成例1~6の中のいずれを使うかを、BA Typeサブフィールド504の他のReserved領域、Reservedサブフィールド505、BA Subtypeサブフィールド507の内の少なくとも3ビットを使用することで特定しても良い。具体的には、BA Subtypeサブフィールド507を使用する場合、BA Subtypeサブフィールド507に0000というビットを指定した場合は構成例1を使用し、0001というビットを指定した場合は構成例2を使用するといったように定義してもよい。
また、既存のBA Typeサブフィールド504と所定の(サブ)フィールドとを組み合わせて、構成例1~6のいずれかを用いることを特定してもよい。例えば、BA Typeサブフィールド504をMulti-TIDやMulti-STAに設定する場合を想定する。BA Typeサブフィールド504をMulti-TIDに設定する場合、Reservedサブフィールド505の領域を使って構成例1~6のいずれかを用いることを特定してもよい。
なお、通信相手装置が、本実施形態による新たなBA Type(すなわち構成例1~6のACK Infoサブフィールド506の構成)をサポートしているかどうか(当該新たなBA Typeに対する能力情報を有するか)は、規格上対応必須と定めてもよい。あるいは、図4の例の場合、AP102とSTA103間でのADDBA Request/Responseフレームのやりとりを介して(BlockAck Agreement構築時に)、能力情報を交換してもよい。あるいは、他のマネージメントフレームのやり取りを介して、能力をネゴシエートしても良い。
(データフレーム受信側の処理)
次に図8を用いて、本実施形態によるデータフレーム受信側の処理について説明する。図8は、データフレーム受信側の装置により実行される処理のフローチャートである。ここでは、図4のようにデータフレーム受信側の装置がSTA103である場合を例に説明するが、本説明は、AP102が動作主体である場合にも同様に適用可能である。当該処理は、STA103が通信相手装置(図4の例ではAP102)と無線接続を確立し、ADDBA Request/Responseフレームのやりとりを終えた後に開始されうる。
次に図8を用いて、本実施形態によるデータフレーム受信側の処理について説明する。図8は、データフレーム受信側の装置により実行される処理のフローチャートである。ここでは、図4のようにデータフレーム受信側の装置がSTA103である場合を例に説明するが、本説明は、AP102が動作主体である場合にも同様に適用可能である。当該処理は、STA103が通信相手装置(図4の例ではAP102)と無線接続を確立し、ADDBA Request/Responseフレームのやりとりを終えた後に開始されうる。
なお、上述のように、STA103とAP102それぞれの接続管理部303は、BlockAck Agreement構築時(図4のF402~F405)に、BAセッションにおけるStarting Sequence Number等の各種パラメータを記憶部201に記録し、管理しているものとする。さらに、STA103とAP102それぞれの接続管理部303は、通信相手装置のサポートするBA Type(本実施形態による新たなBA Typeも含みうる)の情報を記憶部201に記録し、管理しているものとする。
STA103のフレーム送受信部304が、通信相手装置からの無線フレームを受信すると、フレーム解析部301は、受信したフレームの解析処理を開始する。なお、自身宛にフレームでない場合や、フレームが壊れている(例えばFCS値が不正)場合は、AP102は、この処理を開始せずにフレームを破棄してもよい。
フレームの解析処理として、初めにフレーム解析部301は、受信したフレームがデータフレームかの判定を行う(S801)。これは、例えば、IEEE802.11規格で規定されるMACフレームフォーマット内のMACヘッダに含まれるFrame Control Field中のTypeフィールドが“10”であるかどうかを確認することにより、判定可能である。“10”の場合はデータフレーム、それ以外の場合はデータフレームでないと判定できる。
受信したフレームがデータフレームであると判定した場合(S801でYes)、接続管理部303は、データフレームのシーケンス番号の確認処理を実行する(S802)。S802の処理の詳細は、図9を用いて後述する。S802の処理の後、フレーム解析部301は、受信したフレームがBlockAckフレームを要求するデータフレームかを判定する(S803)。これは、例えば、データフレームが含むMPDUの内、少なくとも1つ以上のMPDU内のQoS Controlフィールドに含まれるAck PolicyサブフィールドがImplicit BlockAck Request(“00”)に設定されているかどうかを確認することにより、判定可能である。“00”に設定されている場合、フレーム解析部301は、受信したフレームはBlockAckフレームを要求するデータフレームと判定し(S803でYes)、処理はS804へ進む。“00”に設定されてない場合、フレーム解析部301は、受信したフレームはBlockAckフレームを要求するデータフレームでないと判定し、フレーム受信処理を終了する。S804では、AP102はBlockAck(BA)フレーム生成・送信処理を行う。S804の処理の詳細は、図10を用いて後述する。
S801で、受信したフレームがデータフレームでないと判定した場合(S801でNo)、フレーム解析部301は、受信したフレームがBAR(BlockAck Request)フレームかどうかを判定する(S805)。例えば、データフレームにおける、前述のTypeフィールドが“01”であり、かつ、MACヘッダ内のFrame Control Field中のSubtypeフィールドが“1000”である場合に、BARフレームと特定できる。フレーム解析部301は、受信したフレームがBARフレームと判定した場合は(S805でYes)、処理はS804へ進み、STA103は、BAフレーム生成・送信処理を実行する。BARフレームには、データの開始番号に関する情報が含まれ得る。S805で受信したフレームがBARフレームでないと判定した場合は(S805でNo)、STA103は、IEEE802.11規格準拠の各種フレームに対応する処理を実行し(S806)、処理を終了する。S806の処理については、本実施形態との関連が低いため、説明を割愛する。
次に、図9を用いてS802のデータフレームのシーケンス番号の確認処理について説明する。図9はデータフレームのシーケンス番号確認処理のフローチャートである。なお、データフレーム(MPDU)のシーケンス番号は、IEEE802.11規格で規定されるMACフレームフォーマット内のMACヘッダに含まれるSequence Controlフィールド内のSequence Numberによって示され、0~4095の範囲の値を持つ。接続管理部303は、無線接続が確立した段階(図4の例ではF401)で、当該接続に関する受信シーケンス番号(受信済みのデータフレームのシーケンス番号)の管理を開始する。管理の開始時点では、すべてのシーケンス番号0~4095が未受信シーケンス番号(受信済みとして記録されていないデータフレームのシーケンス番号)として、記憶部201に記録される。
STA103の接続管理部303は、データフレーム(MPDU)のシーケンス番号が未受信シーケンス番号かを確認する(S901)。すなわち、接続管理部303は、受信したデータフレームシーケンス番号の情報を、記憶部201に記録されている受信シーケンス番号と照合し、受信したデータフレームのシーケンス番号が未受信シーケンス番号かどうかを判定する。
受信したデータフレームのシーケンス番号が未受信シーケンス番号である場合(S901でYes)、接続管理部303は、当該シーケンス番号を受信シーケンス番号として新たに記憶部201に記録し、終了する。一方、受信したデータフレームのシーケンス番号が受信シーケンス番号である場合(S901でNo)、受信したデータフレームは既に受信済みであり、重複フレームとみなして、当該データフレームを破棄し(S903)、終了する。
次に、図10を用いてS804のBlockAck(BA)フレーム生成・送信処理について説明する。図10は、BAフレーム生成・送信処理のフローチャートである。なお、上述したように、STA103とAP102それぞれの接続管理部303は、通信相手装置のサポートするBA Type(本実施形態による新たなBA Typeも含みうる)や、BAセッションにおけるStarting Sequence Number等の情報を記憶部201に記録し、管理しているものとする。また、フレームの生成に関し、図5を参照する。
STA103の接続管理部303は、接続のサポートする(自装置とAP102のサポートする)BA Typeを確認する(S1001)。ここで確認したBA Typeのサポート状況に応じて、フレーム生成部302は、S1004、S1005で生成するBlockAckフレームの内容を決定することができる。次に、STA103の接続管理部303は、BAセッションにおけるStarting Sequence Numberを確認する。前述したように、Starting Sequence NumberはBlockAck Agreement構築時に初期値が決定され、IEEE802.11規格規定の方法に従ってその後更新されうる。続いて、接続管理部303は、受信シーケンス番号(受信済みとして記録されたシーケンス番号)の確認を行う(S1003)。
フレーム生成部302は、S1001~S1003で確認された情報を用いて、Block Ackフレームの生成を行う。まず、フレーム生成部302は、BA Informationフィールド503におけるACK Infoサブフィールド506の構成を決定する(S1004)。ここで、フレーム生成部302は、S1001で確認されたサポートBA Typeに基づいて、ACK Infoサブフィールド506の構成を決定することができる。確認されたサポートBA Typeが、上記の構成例1~6のいずれかの構成をサポートすることを示す場合、フレーム生成部302は、ACK Infoサブフィールド506の構成として当該構成例1~6のいずれかを使用することを決定することができる。なお、上記の構成例1~6のいずれかの構成を使用することは、予めSTA103に固定的に設定されていてもよいし、入力部204を介したユーザによる入力操作により、設定(決定)されてもよい。また、フレーム生成部302は、S1003で確認されたシーケンス番号の受信状況に応じて。最も小さなデータサイズでACK Infoサブフィールド506を構成するように構成例1~6のいずれかを使用することを決定してもよい。
次に、フレーム生成部302は、S1004で決定したACK Infoサブフィールド506の構成に従って、また、当該構成を特定(指定)するように、BA Controlフィールド502とBA Informationフィールド503を生成する(S1005)。前述したように、ACK Infoサブフィールド506に構成例1~6のいずれかを使用することを、BA Controlフィールド502/BA Informationフィールド503における各種サブフィールドで指定することができる。
続いてフレーム生成部302は、図5(a)記載のMAC headerフィールド501、FSCフィールドを生成しMACフレームとして完成させ、PHY部も生成してBlockAckフレームを完成させる(S1006)。最後に、フレーム送受信部304は、フレーム生成部302により生成されたBlockAckフレームを通信相手装置(AP102)へ送信する。
送信したフレームの確認応答や、確認応答を一定時間受信しなかった際の再送処理は、IEEE802.11規格の規定に従って実行される。STA103は。BlockAckフレームを正しく送信し、AP102から確認応答を受信した場合、受信済みの記録をリセットする、例えば、STA103の接続管理部303は、管理している受信シーケンス番号のうち、当該BlockAckフレームで通知が完了したシーケンス番号については、受信済みの記録をリセットする。これにより、シーケンス番号が一周した際にシーケンス番号の管理が可能となる。
なお、図8~図10に示す処理のフローは本実施形態を実現する一例であり、同じ機能を果たすものであれば各処理の順番は限定されない。また、この処理フローに記載されていない処理についてはIEEE802.11規格規定の処理に従う。
このように、本実施形態によれば、従来の方式に比べて、少ないデータ量で確認応答を実現することが可能となる。
本発明は、上述の実施形態の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路(例えば、ASIC)によっても実現可能である。
発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。
101 ネットワーク、102 AP(アクセスポイント)、103 STA(ステーション)
Claims (16)
- IEEE802.11規格シリーズに準拠する通信装置であって、
通信相手装置から、それぞれにシーケンス番号が付された複数のデータフレームを受信する受信手段と、
前記受信手段により受信された前記複数のデータフレームに対する確認応答(Ack)フレームを生成する生成手段と、
前記生成手段により生成された前記Ackフレームを前記通信相手装置に送信する送信手段と、を有し、
前記生成手段は、前記Ackフレームに、前記受信された複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した1つ以上のデータフレーム群を特定する特定情報を含めることを特徴とする通信装置。 - 前記生成手段は、前記特定情報として、各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と終了シーケンス番号の情報とを前記Ackフレームに含めることを特徴とする請求項1に記載の通信装置。
- 前記生成手段は、前記特定情報として、各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報とを前記Ackフレームに含めることを特徴とする請求項1に記載の通信装置。
- 前記生成手段は、前記特定情報として、各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報と、前記個数の情報のサイズを示す情報とを前記Ackフレームに含めることを特徴とする請求項1に記載の通信装置。
- 前記生成手段は、前記1つ以上のデータフレーム群の終了を示す情報を、前記Ackフレームに含めることを特徴とする請求項1から3のいずれか1項に記載の通信装置。
- 前記1つ以上のデータフレーム群の終了を示す情報は、ビット単位、バイト単位、前記データフレーム群の数のいずれかで示されることを特徴とする請求項5に記載の通信装置。
- IEEE802.11規格シリーズに準拠する通信装置であって、
通信相手装置から、それぞれにシーケンス番号が付された複数のデータフレームを受信する受信手段と、
前記受信手段により受信された前記複数のデータフレームに対する確認応答(Ack)フレームを生成する生成手段と、
前記生成手段により生成された前記Ackフレームを前記通信相手装置に送信する送信手段と、を有し、
前記生成手段は、前記Ackフレームに、前記受信された複数のデータフレームの情報と、前記受信手段により受信されなかった1つ以上のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した1つ以上のデータフレーム群を特定する特定情報とを含めることを特徴とする通信装置。 - 前記生成手段は、前記Ackフレームに、前記受信された複数のデータフレームの情報として、前記受信された複数のデータフレームの開始シーケンス番号と終了シーケンス番号の情報を含め、前記特定情報として、各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と終了シーケンス番号の情報とを含めることを特徴とする請求項7に記載の通信装置。
- 前記生成手段は、前記Ackフレームに、前記受信された複数のデータフレームの情報として、前記受信された複数のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記複数のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報を含め、前記特定情報として、各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報とを含めることを特徴とする請求項7に記載の通信装置。
- 前記生成手段は、前記Ackフレームに、前記受信された複数のデータフレームの情報として、前記受信された複数のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記複数のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報を含め、前記特定情報として、各データフレーム群における一連のデータフレームの開始シーケンス番号の情報と、当該開始シーケンス番号から開始して前記一連のデータフレームの終了シーケンス番号まで連続するシーケンス番号の個数の情報と、前記個数の情報のサイズを示す情報を含めることを特徴とする請求項7に記載の通信装置。
- 前記生成手段は、前記1つ以上のデータフレーム群の終了を示す情報を、前記Ackフレームに含めることを特徴とする請求項7から10のいずれか1項に記載の通信装置。
- 前記1つ以上のデータフレーム群の終了を示す情報は、ビット単位、バイト単位、前記データフレーム群の数のいずれかで示されることを特徴とする請求項11に記載の通信装置。
- 前記Ackフレームは、生成手段により生成された前記Ackフレームの構成を示す情報を含むことを特徴とする請求項1から12のいずれか1項に記載の通信装置。
- IEEE802.11規格シリーズに準拠する通信装置の制御方法であって、
通信相手装置から、それぞれにシーケンス番号が付された複数のデータフレームを受信する受信工程と、
前記受信工程において受信された前記複数のデータフレームに対する確認応答(Ack)フレームを生成する生成工程と、
前記生成工程において生成された前記Ackフレームを前記通信相手装置に送信する送信工程と、を有し、
前記生成工程では、前記Ackフレームに、前記受信された複数のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した1つ以上のデータフレーム群を特定する特定情報を含めることを特徴とする制御方法。 - IEEE802.11規格シリーズに準拠する通信装置の制御方法であって、
通信相手装置から、それぞれにシーケンス番号が付された複数のデータフレームを受信する受信工程と、
前記受信工程において受信された前記複数のデータフレームに対する確認応答(Ack)フレームを生成する生成工程と、
前記生成工程において生成された前記Ackフレームを前記通信相手装置に送信する送信工程と、を有し、
前記生成工程では、前記Ackフレームに、前記受信された複数のデータフレームの情報と、前記受信工程において受信されなかった1つ以上のデータフレームのうちシーケンス番号が連番である一連のデータフレームごとに区別した1つ以上のデータフレーム群を特定する特定情報とを含めることを特徴とする制御方法。 - コンピュータを、請求項1から13のいずれか1項に記載の通信装置として機能させるためのプログラム。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2020177444A JP2022068653A (ja) | 2020-10-22 | 2020-10-22 | 通信装置、通信装置の制御方法、およびプログラム |
PCT/JP2021/035311 WO2022085370A1 (ja) | 2020-10-22 | 2021-09-27 | 通信装置、通信装置の制御方法、およびプログラム |
US18/301,086 US20230254089A1 (en) | 2020-10-22 | 2023-04-14 | Communication apparatus, control method of communication apparatus, and non-transitory computer-readable storage medium |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2020177444A JP2022068653A (ja) | 2020-10-22 | 2020-10-22 | 通信装置、通信装置の制御方法、およびプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2022068653A true JP2022068653A (ja) | 2022-05-10 |
Family
ID=81291246
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2020177444A Pending JP2022068653A (ja) | 2020-10-22 | 2020-10-22 | 通信装置、通信装置の制御方法、およびプログラム |
Country Status (3)
Country | Link |
---|---|
US (1) | US20230254089A1 (ja) |
JP (1) | JP2022068653A (ja) |
WO (1) | WO2022085370A1 (ja) |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
ES2604854T3 (es) * | 2012-07-16 | 2017-03-09 | Qualcomm Incorporated | Aparatos y procedimientos para la compresión de confirmación de bloques |
WO2017094331A1 (ja) * | 2015-11-30 | 2017-06-08 | ソニー株式会社 | 情報処理装置、通信システム、情報処理方法およびプログラム |
-
2020
- 2020-10-22 JP JP2020177444A patent/JP2022068653A/ja active Pending
-
2021
- 2021-09-27 WO PCT/JP2021/035311 patent/WO2022085370A1/ja active Application Filing
-
2023
- 2023-04-14 US US18/301,086 patent/US20230254089A1/en active Pending
Also Published As
Publication number | Publication date |
---|---|
US20230254089A1 (en) | 2023-08-10 |
WO2022085370A1 (ja) | 2022-04-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9106639B2 (en) | WiMAX R6 management protocol | |
US9161379B2 (en) | Method and apparatus for transmitting data in DLS wireless network | |
TWI425791B (zh) | 在無線網狀網路中及匯聚媒體存取控制服務資料單位格式下之資料傳輸方法 | |
JP2008509622A (ja) | Ackフレーム伝送方法及び装置 | |
JP6806411B2 (ja) | コネクションレス伝送における同期維持のためのシステムおよび方法 | |
CN109246708B (zh) | 一种信息传输方法和装置 | |
WO2019062621A1 (zh) | 一种进行重复传输的方法和设备 | |
JP2022549953A (ja) | データパケット送信方法および装置 | |
US8670387B2 (en) | WiMAX R6 control architecture | |
JP2021150777A (ja) | 通信装置、通信装置の制御方法、およびプログラム | |
JP5609728B2 (ja) | 通信端末およびデータ転送方法 | |
WO2022085370A1 (ja) | 通信装置、通信装置の制御方法、およびプログラム | |
US20220217549A1 (en) | Communication Method, Apparatus, and System | |
WO2022123967A1 (ja) | 通信装置、通信装置の制御方法、およびプログラム | |
JP7405154B2 (ja) | 基地局、通信方法及び通信プログラム | |
WO2022030117A1 (ja) | 通信装置、制御方法、およびプログラム | |
JP6770943B2 (ja) | 基地局装置及びプログラム | |
EP4354951A1 (en) | Data transmission method, apparatus and system | |
WO2024162249A1 (ja) | 通信装置、その制御方法、及び、プログラム | |
US9144056B2 (en) | Broadcast teardown apparatus and method | |
CN115706995A (zh) | 通信方法及装置、计算机可读存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20210103 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20210113 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20231012 |