JP7458839B2 - 通信装置、通信装置の制御方法、およびプログラム - Google Patents

通信装置、通信装置の制御方法、およびプログラム Download PDF

Info

Publication number
JP7458839B2
JP7458839B2 JP2020048026A JP2020048026A JP7458839B2 JP 7458839 B2 JP7458839 B2 JP 7458839B2 JP 2020048026 A JP2020048026 A JP 2020048026A JP 2020048026 A JP2020048026 A JP 2020048026A JP 7458839 B2 JP7458839 B2 JP 7458839B2
Authority
JP
Japan
Prior art keywords
harq
communication device
communication
data communication
type
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
JP2020048026A
Other languages
English (en)
Other versions
JP2021150777A5 (ja
JP2021150777A (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.)
Canon Inc
Original Assignee
Canon Inc
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 Canon Inc filed Critical Canon Inc
Priority to JP2020048026A priority Critical patent/JP7458839B2/ja
Priority to US17/181,121 priority patent/US11671206B2/en
Publication of JP2021150777A publication Critical patent/JP2021150777A/ja
Publication of JP2021150777A5 publication Critical patent/JP2021150777A5/ja
Application granted granted Critical
Publication of JP7458839B2 publication Critical patent/JP7458839B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1812Hybrid protocols; Hybrid automatic repeat request [HARQ]
    • H04L1/1819Hybrid protocols; Hybrid automatic repeat request [HARQ] with retransmission of additional or different redundancy
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1812Hybrid protocols; Hybrid automatic repeat request [HARQ]
    • H04L1/1816Hybrid protocols; Hybrid automatic repeat request [HARQ] with retransmission of the same, encoded, message
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1825Adaptation of specific ARQ protocol parameters according to transmission conditions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829Arrangements specially adapted for the receiver end
    • H04L1/1835Buffer management
    • H04L1/1845Combining techniques, e.g. code combining
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02Data link layer protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

本発明は、無線通信技術に関する。
近年、情報通信技術の発展とともにインターネット使用量が年々増加しており、需要の増加に応えるべく様々な通信技術の開発が進められている。中でも無線ローカルエリアネットワーク(WLAN)技術は、携帯端末によるパケットデータ、音声、ビデオなどのインターネット通信におけるスループット向上を実現しており、現在も様々な技術開発が盛んに行われている。
WLAN技術の発展において、無線通信技術の標準化機構であるIEEE(Institute of Electrical and Electronics Engineers)802による数多くの標準化作業が、重要な役割を果たしている。標準WLAN通信規格の一つとして、IEEE802.11シリーズの規格が知られており、IEEE802.11n/a/b/g/acまたはIEEE802.11axなどの規格がある。特許文献1によれば、IEEE802.11axではOFDMA(Orthogonal frequency-division multiple access)により最大9.6ギガビット毎秒(Gbps)という高いピークスループットに加え、混雑状況下での通信速度向上を実現している。
さらなるスループット向上のために、IEEE802.11axの後継規格として、IEEE802.11 EHT(extremely high throughput)と呼ばれるStudy Groupが発足した。EHTが目指すスループット向上を実現するうえで、アクセスポイント(AP)とステーション(STA)の間でHARQ(Hybrid Automatic Repeat reQuest(ハイブリッド自動再送要求))with soft combining技術を適用することが検討されている。
HARQは、ARQ(自動再送要求)と誤り訂正符号(FEC(前方誤り訂正))の技術を組み合わせた技術である。送信装置から送信された、冗長な誤り訂正符号が付加されたパケットを受信した受信装置は、当該パケットを正しく復号した場合、ACK(肯定応答/確認応答)パケットを送信装置に送信する。正しく復号できなかった場合はNACK(否定応答)を送信し、送信装置からの再送を待つ。送信装置は、受信装置にデータパケットを再送する場合、前回と同じデータを再度送信する。
HARQのタイプとしては主に、Chase Combining(チェース合成)(以下、CC)、Incremental Redundancy(インクリメンタルリダンタンシ)(以下、IR)がある。これらは再送時での挙動が異なる。CCでは、送信装置は、NACKの対象となるパケットと同一のパケットを再送する。受信装置は再送されたパケットを受信後、受信バッファに蓄積されているパケットと最大比合成(MRC:Maximal Ratio Combining)を行い、復号処理を行う。このCCタイプでは、電力干渉やSINR(信号対雑音干渉比)が向上する。一方で、チャネル状態が良好な場合に、符号語の冗長ビットをいつもすべて再送してしまう欠点がある。一方、IRでは、送信装置は再送時、その再送回数に応じて異なる符号化を行い、送信する。このIRでは、パケットを合成することにより符号化利得が向上し、CCよりも大きなパケット誤り低減効果を実現できる。一方で処理が複雑となり、送信装置と受信装置において、必要なメモリ数(バッファ容量)が大きくなりがちとなる。
特開2018-050133号公報
上記のように、EHTでは、HARQ with soft combining技術を適用することが検討されているが、通信装置がいずれのタイプを利用可能とするかを判断するための仕組みは定義されていなかった。
上記課題を鑑み、本発明は、通信装置が利用可能な再送方式を判断するための技術を提供することを目的とする。
上記目的を達成するため、本発明の一態様に係る通信装置は、以下の構成を有する。すなわち、他の通信装置との間で、IEEE802.11シリーズの規格に準拠するデータ通信であって、HARQ(ハイブリッド自動再送要求)を用いるデータ通信を行う通信手段と、少なくとも前記通信装置における前記HARQを用いたデータ通信に使用可能なメモリのバッファ空き容量と、閾値とに基づいて、複数の再送タイプの中から前記通信手段による前記他の通信装置とのデータ通信に用いる前記HARQの再送タイプを決定する決定手段と、を有し、記通信手段は、前記決定手段によって決定された再送タイプを用いて前記他の通信装置に対するデータ通信を行い、前記閾値は、前記通信装置と前記他の通信装置とが接続する周波数帯域の幅に少なくとも基づいて設定される
本発明によれば、通信装置が利用可能な再送方式を判断するための技術が提供される。
ネットワーク構成例を示す。 APおよびSTAのハードウェア構成例を示す。 APおよびSTAの機能構成例を示す。 STAがデータ送受信を行うまでのフローチャートである。 HARQの能力情報の例を示す。 HARQ typeが示す値と当該値の意味の対応付けの例を示す。 APがデータ送受信を行うまでのフローチャートである。 APがデータ送受信を行うまでの別のフローチャートである。 トリガーフレームの構成例を示す。
以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。
[実施形態1]
図1に、実施形態1におけるネットワークの構成例を示す。図1では、無線通信装置として、1つのアクセスポイント(AP102)と3つのステーション(STA103、STA104、STA105)を含んだネットワーク構成が示されている。図1に示すように、AP102が形成するネットワークは円101で示される。本実施形態では、STA103~105はAP102とフレームを送受信できるものとする。STA103~105およびAP102は、HARQ(ハイブリッド自動再送要求)のIRタイプ(HARQ-IR)とCCタイプ(HARQ-CC)両方にて通信が可能な無線通信装置であるものとする。なお、図1に示す構成は一例であり、例えばさらに広範な領域に多数の無線通信装置を含むネットワークに対して、また、様々な無線通信装置の位置関係に対して、以下の議論を適用可能である。
図2に、本実施形態におけるAPおよびSTAのハードウェア構成例を示す。APとSTAはそれぞれ、そのハードウェア構成の一例として、記憶部201、制御部202、機能部203、入力部204、出力部205、通信部206およびアンテナ207を有する。
記憶部201は、ROM、RAMの両方、または、いずれか一方により構成され、後述する各種動作を行うためのプログラムや、無線通信のための通信パラメータ等の各種情報を記憶する。なお、記憶部201として、ROM、RAM等のメモリの他に、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD-ROM、CD-R、磁気テープ、不揮発性のメモリカード、DVDなどの記憶媒体が用いられてもよい。
制御部202は、例えば、CPUやMPU等のプロセッサー、ASIC(特定用途向け集積回路)、DSP(デジタルシグナルプロセッサ)、FPGA(フィールドプログラマブルゲートアレイ)等の1つ以上により構成される。ここで、CPUはCentral Processing Unitの、MPUは、Micro Processing Unitの頭字語である。制御部202は、記憶部201に記憶されたプログラムを実行することによりAP(STA)全体を制御する。なお、制御部202は、記憶部201に記憶されたプログラムとOS(Operating System)との協働によりAP(STA)全体を制御するようにしてもよい。また、制御部202には、HARQの誤り訂正符号を生成、復号するための回路が含まれていても良い。また、制御部202は、機能部203を制御して、撮像や印刷、投影等の所定の処理を実行する。機能部203は、AP(STA)が所定の処理を実行するためのハードウェアである。例えば、AP(STA)がカメラである場合、機能部203は撮像部であり、撮像処理を行う。また、例えば、AP(STA)がプリンタである場合、機能部203は印刷部であり、印刷処理を行う。また、例えば、AP(STA)がプロジェクタである場合、機能部203は投影部であり、投影処理を行う。機能部203が処理するデータは、記憶部201に記憶されているデータであってもよいし、後述する通信部206を介して他の通信装置と通信したデータであってもよい。
入力部204は、ユーザからの各種操作の受付を行う。出力部205は、ユーザに対して各種出力を行う。ここで、出力部205による出力とは、画面上への表示や、スピーカーによる音声出力、振動出力等の少なくとも1つを含む。なお、タッチパネルのように入力部204と出力部205の両方を1つのモジュールで実現するようにしてもよい。
通信部206は、IEEE802.11シリーズの規格に準拠した無線通信の制御や、IP(Internet Protocol)通信の制御を行う。本実施形態では、通信部206は、少なくともIEEE802.11ax規格に準拠した処理を実行することができる。また、通信部206はアンテナ207を制御して、無線通信のための無線信号の送受信を行う。AP(STA)は通信部206を介して、画像データや文書データ、映像データ等のコンテンツを他の通信装置と通信する。
アンテナ207はそれぞれサブGHz帯、2.4GHz帯、5GHz帯、及び6GHz帯における無線信号のいずれかを受信可能なアンテナである。アンテナ207はMIMO(Multi-Input and Multi-Output)送受信を実現するために、物理的に一本以上のアンテナで構成されても良い。
図3は、本実施形態におけるAPおよびSTAの機能構成例を示す。APとSTAはそれぞれ、その機能構成の一例として、能力情報生成部301、MACフレーム生成部302、MACフレーム送受信部303、解析部304、IR可否判定部305、再送タイプ決定部306、およびデータ送受信部307を有する。
能力情報生成部301は、AP(STA)における能力(Capability)に関する情報(能力情報(Capability Information))を生成する。本実施形態では、能力情報生成部301は、HARQのサポートの有無(HARQによるデータ通信は可能か否か)、HARQをサポートするにはサポートするHARQのタイプといった情報を含む、HARQの能力情報(HARQ element)を生成する。
MAC(Media Access Control)フレーム生成部303は、必要に応じて能力情報生成部301により生成された能力情報を格納したMACフレームを生成する。当該MACフレームは、IEEE802.11シリーズの規格に準拠するMACフレームであり、例えば、Beaconフレーム、Probe Requestフレーム、Probe Responseフレーム、Association Requestフレーム、Association Responseフレーム、Reassociation Requestフレーム、Reassociation Responseフレーム、Actionフレームといったマネージメントフレーム、またトリガー(Trigger)フレームといったコントロールフレームである。
図5に、HARQの能力情報(HARQ element)フォーマットの例を示す。図5のHARQ element500は、自身がどの形式での通信を希望しているかを示すためのelementである。HARQ element500は、IEEE802.11シリーズの規格で規定される他のInfomation Element(情報要素)と同様、Elementを識別するElement IDフィールド501と、Elementのデータ長を示すLengthフィールド502と、Element固有の情報から構成される。HARQ element500は、前述のMACフレームに付加することのできる情報である。
HARQ supportフィールド503は、HARQをサポートするか否か(HARQを用いたデータ通信は可能か否か)を示す情報であり、例えば、HARQ supportフィールド503は、0の場合はHARQのサポート有りで、1の場合はHARQのサポート無しであることを示す。なお、HARQ supportフィールド503を使用せずに、MACフレーム内にHARQ element500が含まれるか否かに基づいて、フレームの受信側装置は、HARQのサポートの有無を判断してもよい。HARQ typeフィールド504は、HARQのサポートが有る場合に、サポートするHARQのタイプを示す情報である。HARQ typeフィールド504の値は、例えば図6に示すような値が対応付けられる。図6に、HARQ typeが示す値と当該値の意味の対応付けの例を示す。図6の対応付けは一例であり、他の手法による対応付けであってもよい。例えば、所定のタイプと当該所定のタイプに対応するビットを規定し、AP102がBeaconフレームにて当該所定のタイプをサポートしていることを示す場合には、そのタイプに応じたビットの値を1としてもよい。この場合、STA103~105はAP102がサポートするタイプに応じて、HARQのタイプを決定することが可能になる。もしくは、値が0の場合はHARQ-CCのみ、値が1の場合はHARQ-CCおよびHARQ-IRにサポートするものとして設定されてもよい。この場合、値が高いほど、AP102がより高度なタイプに対応しているものと考えることができ、サポートするHARQのタイプの種類やその組み合わせに対して、表示するビットサイズを少なく保つことが可能となる。また、複数のHARQのタイプをサポートする場合には、HARQ elementを複数付与することによって、サポートの表現をしてもよい。
図3の説明に戻り、MACフレーム送受信部303は、通信部206を介して、MACフレーム生成部302により生成されたMACフレームを送信し、相手機器からのMACフレームを受信する。解析部304は、MACフレーム送受信部303により受信されたMACフレームを解析し、所定の情報を抽出する。例えば解析部304は、受信されたMACフレームを解析し、相手機器(MACフレームの送信元の機器)のHARQのサポートの有無等を抽出する。解析部304は、当該解析の結果に基づいて、相手機器がHARQを用いたデータ通信を行うことができるか否か(相手機器との間でHARQを用いたデータ通信を行うか否か)を判定する。IR可否判定部305は、相手機器との間の接続帯域幅や自機器のバッファ空き容量等を確認することにより、HARQ-IRを用いたデータ通信を行うことができるか否かを判定する。再送タイプ決定部306は、相手機器との再送通信方式(以下、再送タイプ)、すなわち、HARQ-IR、HARQ-CC、またはARQ(自動再送要求)のいずれかを決定する。当該決定は、解析部304による解析の結果、IR可否判定部305による判定の結果、MACフレーム送受信部303により受信されるMACフレームの種別、のうちの少なくとも1つに基づいて、行われ得る。ARQは、IEEE802.11ax等、従来のIEEE802.11シリーズの規格でサポートされている再送タイプである。データ送受信部307は、再送タイプ決定部306により決定された再送タイプを用いて、データフレームの送受信を行う。
(処理の流れ)
本実施形態では、STAが、IEEE802.11シリーズの規格に準拠した通信に関する状態に基づいて、相手機器(AP)とのデータ通信において利用可能な再送タイプ(HARQ-IR、HARQ-CC、ARQ)を判断する。その上で、STAは、APとのデータ通信に使用する再送タイプを決定する。当該規格に準拠した通信に関する状態の一例は、STAにおけるHARQについての能力(性能)である。上述したように、HARQ-IRでは、パケットを合成することにより符号化利得が向上し、HARQ-CCよりも大きなパケット誤り低減効果を実現できる一方で、処理が複雑となり、必要なバッファ容量が大きくなり得る。本実施形態では、STA103とSTA104は、HARQ-IRを用いたデータ通信に必要なバッファ領域(バッファ空き容量)を確保できているが、STA105はそのようなバッファ領域を確保できていないものとする。
図4に、STA103~105により実行される、データ送受信を行うまでの処理のフローチャートを示す。STA103~105を総称する場合は、STAと表現する。図4に示すフローチャートは、STAの制御部202が記憶部201に記憶されている制御プログラムを実行し、情報の演算および加工並びに各ハードウェアの制御を実行することにより実現されうる。このフローチャートに示す処理は、STAがAP102と接続を開始(要求)するときに開始され得る。なお、STAがAP102との接続中に、例えばActionフレームを受信したことをトリガーとして開始されてもよい。
まず、STAの解析部304は、AP102とHARQを用いたデータ通信を行うか否かを判断する(S401)。解析部304は、例えば、MACフレーム送受信部303により受信された、AP102が定期的に送信するBeaconフレームや、送信されたProbe Requestフレームに対する返信であるProbe Responseフレームを解析する。具体的には、解析部304は、受信した前述のフレームに、HARQ element500(図5を参照)が含まれているか否か(AP102がHARQをサポートしているか否か)により、AP102とHARQを用いたデータ通信を行うか否かを判断してもよい。また、解析部304は、受信した前述のフレームにHARQ element500が含まれる場合に、HARQ supportフィールド503の値が1であるか否か(AP102がHARQをサポートしているか否か)により、AP102とHARQを用いたデータ通信を行うか否かを判断してもよい。解析部304は、AP102がHARQをサポートしていると判断した場合に、HARQを用いたデータ通信を行うと判断し、そうでない場合に、HARQを用いたデータ通信を行わないと判断する。
解析部304により、HARQを用いたデータ通信を行わないと判断された場合(S401でNo)、再送タイプ決定部306は、HARQを用いたデータ通信を行わず、ARQを用いたデータ通信を行うことを決定する(S402)。一方、解析部304は、AP102がHARQを用いたデータ通信を行うと判断した場合(S401でYes)、AP102がHARQ-IRを用いたデータ通信を行うことができるか否か、すなわち、HARQ-IRをサポートするか否かを判断する(S403)。具体的には、解析部304は、HARQ element500内のHARQ typeフィールド504の値(図6を参照)を確認する。解析部304により、AP102がHARQ-CCのみサポートしていると判断された場合(S403でNo)、MACフレーム送受信部303は希望再送タイプがHARQ-CCであることをAP102に通知する(S408)。具体的な処理例としては、まずMACフレーム生成部302は、例えば、AP102との接続時に希望する再送タイプとして、HARQ-CCを指定したAssociation Requestフレームを生成する。当該Association Requestフレームは、HARQ element500(図5)を有し、希望する再送タイプはHARQ supportフィールド503により指定され得る。そして、MACフレーム送受信部303は当該Association Requestフレームを送信する。
一方、解析部304により、AP102がHARQ-IRのみ、または、HARQ-CCとHARQ-IRをサポートしていると判断された場合(S403でYes)、処理はS404へ進む。S404では、IR可否判定部305は、HARQ-IRを用いた通信に使用可能なバッファ領域(バッファ空き容量)を確認する。具体的な処理例としては、IR可否判定部305は、STA自身が確保できるバッファ空き容量、もしくはメモリ空き容量を確認する。メモリ空き容量を確認するタイミングは、より最適なメモリ使用を行うために、AP102との接続の直前に行うことが望ましいが、これに限らない。例えば、IR可否判定部305は、STAの電源起動時にバッファ空き容量を確認し、HARQ-IRを用いたデータ通信を行うことができないと判断した場合、接続直前での確認を実施しなくてもよい。また、IR可否判定部305は、AP102との接続中に、より優先するべきアプリケーションが起動されている場合に、当該アプリケーション起動後に確保できるバッファ空き容量を確認してもよい。これにより、優先したアプリケーションへのメモリ確保が可能となる。IR可否判定部305は、ほかのアプリケーションの動作とは関係なく、定期的にSTA内部で確保できるバッファ容量を確認してもよい。HARQ-CCおよびHARQ-IRを用いたデータ通信のために必要なバッファ空き容量を定め、その閾値を超える、あるいは下回る変化があった時に、STAは、図4のフローチャートのS404の処理から開始してもよい。バッファ空き容量とは、製品に組み込まれるメモリサイズに加え、製品の接合部で増設されるメモリ容量も含めてよい。
HARQ-IRを用いたデータ通信に必要なバッファ空き容量は、AP102とSTA103~105が接続する周波数帯域(接続帯域)の幅によって変化しうる。例えば、80MHzで接続した場合と320MHzで接続した場合で必要なバッファ空き容量には、約4倍の差が生じる。また、通信中、メモリ上にデータを滞留させる時間(滞留時間)によっても必要なバッファ空き容量は異なる。規格に従って滞留時間を可変とした場合、滞留時間を1msとするか、5msとするかで5倍の差が生じうる。これらの情報は接続処理を行う際に、STAは、AP102から送信されるBeaconフレームやProbe Responseフレームによって知ることができる。IR可否判定部305は、データ通信するときの接続帯域の幅や滞留時間によって、HARQ-CCやHARQ-IRを用いたデータ通信に必要なバッファ空き容量の閾値を変更(設定)する。この上で、IR可否判定部305は、HARQ-IRを用いたデータ通信を行うことが可能か否か(HARQ-IRを利用可能か否か)を判断する(S405)。
バッファ空き容量が閾値に満たないなど、IR可否判定部305がHARQ-IRを用いたデータ通信を行うことができないと判断した場合(S405でNo)、MACフレーム送受信部303は希望再送タイプがHARQ-CCであることをAP102に通知する(S408)。S408の具体的な処理例は上述の通りである。バッファ空き容量が閾値以上であるなど、IR可否判定部305がHARQ-IRを用いたデータ通信を行うことができると判断した場合(S405でYes)、MACフレーム送受信部303は希望再送タイプがHARQ-IRであることをAP102に通知する(S406)。具体的な処理例としては、まずMACフレーム生成部302は、例えば、AP102との接続時に希望する再送タイプとして、HARQ-IRを指定したAssociation Requestフレームを生成する。当該Association Requestフレームは、HARQ element500(図5)を有し、希望する再送タイプはHARQ supportフィールド503により指定され得る。そして、MACフレーム送受信部303は当該Association Requestフレームを送信する。
MACフレーム送受信部303は、希望再送タイプがHARQ-IRであることをAP102に通知した(S406)後、当該通知に対する応答を待つ。応答が受信された場合に、解析部304は、当該応答が拒否応答か否かを判断する(S407)。具体的な処理例としては、S406にて、AP102との接続時に希望する再送タイプとして、HARQ-IRを指定したAssociation Requestフレームを送信した場合、MACフレーム送受信部303はAssociation Responseフレームの受信を待つ。MACフレーム送受信部303によりAssociation Responseフレームが受信された場合、解析部304は、当該フレームを解析し、HARQ-IRを用いたデータ通信を拒否することを示す情報が含まれているか否かを判断する。HARQ-IRを用いたデータ通信を拒否することを示す情報が含まれている場合に、解析部304は、応答が拒否応答であると判断し、それ以外の場合に、応答が拒否応答でないと判断する。拒否応答を受信(取得)していないと判断された場合(S407でNo)、再送タイプ決定部306は、HARQ-IRを用いたデータ通信を行うことを決定する(S410)。
解析部304により、拒否応答を受信(取得)したと判断された場合(S407でYes)、MACフレーム送受信部303は希望再送タイプがHARQ-CCであることをAP102に通知してもよい(S408)。MACフレーム送受信部303は、希望再送タイプがHARQ-CCであることをAP102に通知した(S408)後、当該通知に対する応答を待つ。応答が受信された場合に、解析部304は、当該応答が拒否応答か否かを判断する(S409)。具体的な処理例としては、S408にて、AP102との接続時に希望する再送タイプとして、HARQ-CCを指定したAssociation Requestフレームを送信した場合、MACフレーム送受信部303はAssociation Responseフレームの受信を待つ。MACフレーム送受信部303によりAssociation Responseフレームが受信された場合、解析部304は、当該フレームを解析し、HARQ-CCを用いたデータ通信を拒否することを示す情報が含まれているか否かを判断する。HARQ-CCを用いたデータ通信を拒否することを示す情報が含まれている場合に、解析部304は、応答が拒否応答であると判断し、それ以外の場合に、応答が拒否応答でないと判断する。拒否応答を受信(取得)していないと判断された場合(S409でNo)、再送タイプ決定部306は、HARQ-CCを用いたデータ通信を行うことを決定する(S411)。
解析部304により、拒否応答を受信(取得)したと判断された場合(S409でYes)、再送タイプ決定部306は、ARQを用いたデータ通信を行うことを決定する(S402)。なお、他の再送タイプを用いたデータ通信が可能である場合は、MACフレーム送受信部303は、希望再送タイプが当該他の再送タイプであることをAP102に通知してもよい。また、STAはタイマー(不図示)を設置し、MACフレーム送受信部303は、一定時間に応答(例えばAssociation Response)を受信しなかったことをもって、AP102により希望再送タイプが拒否されたと認識してもよい。この場合、MACフレーム送受信部303は、希望再送タイプがARQや別のHARQのタイプであることをAP102に通知してもよい。
その後、データ送受信部307は、再送タイプ決定部306により決定された再送タイプを用いて、データの送受信を行う(S412)。
なお、STAは、図4に示す処理をAP102との接続後に行う場合、例えばActionフレームを用いて希望再送タイプを通知してもよい(再送タイプ(接続タイプ)変更通知)。もしくは、データを一斉に送信する合図となるUL(アップリンク)やDL(ダウンリンク)のTriggerフレームをはじめとしたコントロールフレームを用いてもよい。
また、IR可否判定部305による、HARQ-IRを用いた通信を行うためのバッファ空き容量や、接続帯域(接続するときの周波数帯域)の確認は、S401の前に行われてもよい。またSTAは、この確認結果を、HARQを用いたデータ通信を行うかどうかの指標として用いてもよい。また、図4の処理では、IR可否判定部305が、接続帯域の幅および受信データの滞留時間をもとにHARQ-IRに必要なバッファ空き容量の閾値を設定し、その後、再送タイプ決定部306が当該閾値に基づいてHARQのタイプを決定した。閾値の設定とHARQのタイプの決定との処理順序は逆であってもよい。すなわち、再送タイプ決定部306が希望するHARQタイプをHARQ-IRと定め、その後、IR可否判定部305がHARQ-IRに必要なバッファ空き容量を計算し、現在のバッファ空き容量で通信できる周波数帯域幅から、STAが希望する周波数帯域幅を求めてもよい。これにより、相手機器が特定のHARQのタイプにのみ対応していたとしても、示されたタイプでのデータ通信が可能となる。
図4の例では、HARQのタイプを決定するために接続帯域の幅およびデータの滞留時間を用いたが、これは一例に過ぎず、メモリの使用に関する他の処理をS405に適用してもよい。例えば、Green fieldの使用の有無、A-MSDU(Aggregation MAC Service Data Unit)の使用の有無、A-MSDUやA-MPDU(Aggregation MAC Protocol Data Unit)の受信時の最大サイズ、MCS(Modulation and Coding Scheme)を含めた最大のデータレート、ビームフォーミング処理の有無、認証方式(PSK、SAE、EAP)や暗号化方式(TKIP、AES)を含めたセキュリティ方式、FTM(Fine Timing Measurement)処理の有無、Wi-Fi DirectやWi-Fi Aware処理の有無、LDPC(低密度パリティ検査符号)やBlock ACKの処理の有無、CSI(チャネル状態情報)情報の送受信の有無、Beacon ReportなどのSTA周辺の情報を送信するかどうか、などを元に、HARQのタイプを決定してもよい、もしくはHARQのタイプによって、上記の閾値を変更するものであってもよい。
このように、本実施形態によれば、STAは、自身のバッファ空き容量を確認し、AP102のサポートする機能(能力)の情報を取得することによって、データ通信に使用するHARQのタイプを決定することができる。また、AP102は、STAごとに、HARQ-CC、HARQ-IR、またはARQを用いたデータ通信を行うことを決めることができ、STAに適した通信方式を採用することができるようになる。
[実施形態2]
本実施形態では、APが、IEEE802.11シリーズの規格に準拠した通信に関する状態に基づいて、相手機器(STA)とのデータ通信において利用可能な再送タイプ(HARQ-IR、HARQ-CC、ARQ)を判断する。その上で、APは、STAとのデータ通信に使用する再送タイプを決定する。当該規格に準拠した通信に関する状態の一例は、APにおけるHARQについての能力(性能)である。以下、実施形態1と異なる点について説明する。本実施形態では、STA103、STA104は、HARQ-IRを用いたデータ通信に必要なバッファ領域(バッファ空き容量)を確保できているが、STA105はそのようなバッファ領域をできていないものとする。
図7に、AP102により実行される、データ送受信を行うまでの処理のフローチャートを示す。図7に示すフローチャートは、AP102の制御部202が記憶部201に記憶されている制御プログラムを実行し、情報の演算および加工並びに各ハードウェアの制御を実行することにより実現されうる。このフローチャートに示す処理は、STA103~STA105がAP102に接続を要求してきたときに開始され得る。
まず、IR可否判定部305は、APとしての動作開始時に希望する最大の周波数帯域(接続帯域)の幅、および、HARQ-IRを用いた通信に使用可能なバッファ領域(バッファ空き容量)を確認する(S701)。IR可否判定部305は、確認した容量の値から、希望する最大の接続帯域幅にてHARQ-IRを用いたデータ通信を行うことができるか否か(HARQ-IRを利用可能か否か)を判断する(S702)。なお、IR可否判定部305は、追加的または代替的に、AP102が現在接続しているSTAの数に基づいて、当該判断を行ってもよい。また、IR可否判定部305は、追加的または代替的に、トリガーフレームを用いた複数STAへの同時DL通信(ダウンリンク通信)またはUL通信(アップリンク通信)を行うかどうかに基づいて、当該判断を行ってもよい。また、IR可否判定部305は、AP102に現在搭載されているチップが持つ機能、通信する周波数帯域で送受信される周囲のフレーム数などの環境によって、当該判断を行ってもよい。
IR可否判定部305が、HARQ-IRのために必要な空きバッファ容量を確保できない等、HARQ-IRを用いたデータ通信を行うことができないと判断した場合(S702でNo)、MACフレーム送受信部303は、HARQ-CCを用いたデータ通信を行うことができることをSTAに通知する(S704)。S704の具体的な処理例としては、まずMACフレーム生成部302は、HARQのタイプとしてHARQ-CCを指定したBeaconフレームやProbe Responseフレームを生成する。当該BeaconフレームやProbe Responseフレームは、HARQ element500(図5)を有し、可能な再送タイプはHARQ supportフィールド503により指定され得る。そして、MACフレーム送受信部303は当該BeaconフレームやProbe Responseフレームを送信する。一方、IR可否判定部305が、HARQ-IRのために必要な空きバッファ容量を確保できる等、HARQ-IRを用いたデータ通信を行うことができると判断した場合(S702でYes)、MACフレーム送受信部303は、HARQ-IRを用いたデータ通信を行うことができることをSTAに通知する(S703)。S703の具体的な処理例としては、まずMACフレーム生成部302は、HARQのタイプとしてHARQ-IRを指定したBeaconフレームやProbe Responseフレームを生成する。当該BeaconフレームやProbe Responseフレームは、HARQ element500(図5)を有し、可能な再送タイプはHARQ supportフィールド503により指定され得る。そして、MACフレーム送受信部303は当該BeaconフレームやProbe Responseフレームを送信する。なお、IR可否判定部305がHARQ-IRを用いたデータ通信を行うことができないと判断した場合、MACフレーム生成部302は、送信するフレームにおいてHARQ element500を付与しなくてもよいし、HARQ supportフィールド503の値を0にしてもよい。
STAはAP102に対して接続を要求する場合、AuthenticationフレームをAP102に対して送信する。MACフレーム送受信部303が当該該Authenticationフレームを受信しない場合は(S705でNo)、処理はS701へ戻る。MACフレーム送受信部303は、当該Authenticationフレームを受信した場合(S705でYes)、Authenticationフレームを返信する(S706)。なお、S705とS706の処理(すなわちAuthenticationプロセス)についてはこれに限らない。処理形態によっては、S705とS706の処理は省略され得る。また、SAE(Simultaneous Authentication of Equals)で接続するときは、S705とS706におけるフレーム送受信の代わりに、SAE commitの送受信、SAE confirmの送受信を行ってもよい。
次に、MACフレーム送受信部303がSTAからAssociation Requestフレームを受信した場合(S707でYes)、処理はS708へ進む。S708において、解析部304は、受信したAssociation Requestフレームに、HARQ element500(図5を参照)が含まれているか否かを確認することにより、STAがHARQを用いた通信を希望しているか否かを判断する。S708では、解析部304は、当該受信したフレームにHARQ element500が含まれる場合に、HARQ supportフィールド503が1であるか否かに基づいて、STAがHARQを用いた通信を希望しているか否かを判断してもよい。解析部304により、STAがHARQを用いた通信を希望していないと判断された場合(S708でNo)、再送タイプ決定部306は、ARQを用いたデータ通信を行うことを決定する(S709)。その後、MACフレーム送受信部303は、Association Responseフレームを送信する(S717)。当該Association Responseフレームには、HARQ element500は含まれない、または、HARQ supportフィールド503の値が1であるHARQ element500が含まれ得る。
解析部304は、STAがHARQを用いた通信を希望していると判断した場合(S708でYes)、さらに、STAの希望がHARQ-IRかHARQ-CCかを判断する(S710)。解析部304は例えば、HARQ element500におけるHARQ typeフィールド504の値を確認することで当該判断を行うことができる。解析部304によりSTAがHARQ-IRを希望していると判断された場合(S710でYes)、IR可否判定部305は、AP102自身がHARQ-IRを用いたデータ通信を行うことができるか否かを判断する(S711)。S711の処理では、S701とS702の処理において用いた判断基準を再度用いてもよいし、S701とS702の処理における結果をそのまま用いてもよい。また、S701とS702の処理においてバッファ空き容量を確認した時点と、Association Requestフレームを受信した時点でのバッファ空き容量の変化量、を元にS711における判断が行われてもよい。
判断の結果、HARQ-IRを用いたデータ通信を行うことができないと判断された場合(S711でNo)、MACフレーム送受信部303は、HARQ-IRを用いたデータ通信を行うことができない(拒否する)ことをSTAに通知する(拒否通知を送信する)。このとき用いるフレームは、Association Responseフレームでもよいし、別のフレームでもよい。Association Responseフレームを用いる場合、MACフレーム生成部302は、HARQ-IRを用いたデータ通信を拒否することを示す情報を含め、MACフレーム送受信部303が当該フレームを拒否応答(拒否通知)として送信する。また、MACフレーム送受信部303は、Association Responseフレームを送信しないことで、HARQ-IRを用いたデータ通信を拒否することを通知してもよい。
一方、HARQ-IRを用いたデータ通信を行うことができると判断された場合(S711でYes)、再送タイプ決定部306は、HARQ-IRを用いたデータ通信を行うことを決定する(S712)。その後、MACフレーム送受信部303は、Association Responseフレームを送信する(S717)。当該Association Responseフレームには、HARQ supportフィールド503の値が0、HARQ typeフィールド504の値が1であるHARQ element500が含まれ得る。
解析部304によりSTAがHARQ-CCを希望していると判断された場合(S710でNo)、IR可否判定部305は、AP102自身がHARQ-CCを用いたデータ通信を行うことができるか否かを判断する(S714)。S714の処理では、S701とS702の処理において用いた判断基準を再度用いてもよいし、S701とS702の処理における結果をそのまま用いてもよい。また、S701とS702の処理においてバッファ空き容量を確認した時点と、Association Requestフレームを受信した時点でのバッファ空き容量の変化量、を元にS714における判断が行われてもよい。
判断の結果、HARQ-CCを用いたデータ通信を行うことができないと判断された場合(S714でNo)、MACフレーム送受信部303は、HARQ-CCを用いたデータ通信を行うことができない(拒否する)ことをSTAに通知する(拒否通知を送信する)。このとき用いるフレームは、Association Responseフレームでもよいし、別のフレームでもよい。Association Responseフレームを用いる場合、MACフレーム生成部302は、HARQ-CCを用いたデータ通信を拒否することを示す情報を含め、MACフレーム送受信部303が当該フレームを拒否応答(拒否通知)として送信する。また、MACフレーム送受信部303は、Association Responseフレームを送信しないことで、HARQ-CCを用いたデータ通信を拒否することを通知してもよい。
一方、HARQ-CCを用いたデータ通信を行うことができると判断された場合(S714でYes)、再送タイプ決定部306は、HARQ-CCを用いたデータ通信を行うことを決定する(S715)。その後、MACフレーム送受信部303は、Association Responseフレームを送信する(S717)。当該Association Responseフレームには、HARQ supportフィールド503の値が0、HARQ typeフィールド504の値が0であるHARQ element500が含まれ得る。
なお、AP102は、S713およびS716にて拒否通知を送信した後に、STAから再度接続が要求された場合は、S705から処理を開始してもよいし、S707から処理を開始してもよい。また、AP102は、Association Responseフレームを送信した後は、4way handshakeを実施してもよいし、実施しなくてもよい。
その後、データ送受信部307は、再送タイプ決定部306により決定された再送タイプを用いて、データの送受信を行う(S718)。
図8に、AP102により実行される、APがデータ送受信を行うまでの処理の別のフローチャートを示す。図8に示すフローチャートは、AP102の制御部202が記憶部201に記憶されている制御プログラムを実行し、情報の演算および加工並びに各ハードウェアの制御を実行することにより実現されうる。このフローチャートに示す処理は、AP102が接続中のSTAが1以上存在し、当該STAとデータを送受信しようとするときに開始され得る。また、STA103~STA105がAP102に接続を要求してきたときに開始されてもよい。
まず、AP102の制御部202は、AP102自身および接続中の1以上の各STAがHARQをサポートしているか(HARQに対応可能か)否かを確認する(S801)。すなわち、AP102は、接続中の各STAに対して、HARQを用いたデータ通信を行うか否かを決定する。具体的な処理例としては、制御部202は、AP102自身については、AP102に対して適用されている設定/構成を確認する。また、各STAについては、AP102は既に受信していたMACフレームにHARQ element500(図5)が含まれるか否か、含まれる場合には、HARQ supportフィールド503の値が1であるか否かを確認する。
AP102がHARQをサポートしていないと判断された場合(S801でNo)、再送タイプ決定部306は、HARQを用いたデータ通信を行わず、ARQを用いたデータ通信を行うことを決定する(S802)。接続中のSTAのうちHARQをサポートしていないSTAがあると判断された場合(S801でNo)、再送タイプ決定部306は、当該HARQのサポートが無いSTAに対して、ARQを用いたデータ通信を行うことを決定する(S802)。なお、接続中のSTAのうちHARQをサポートしていないSTAがあると判断された場合(S801でNo)、再送タイプ決定部306は、当該接続中の全てのSTAに対して、ARQを用いたデータ通信を行うことを決定してもよい(S802)。また、接続中のSTAの全てがHARQをサポートしている場合であっても、当該全てのSTAに対してHARQを用いたデータ通信ができない場合に、再送タイプ決定部306は、一部のSTAに対して、ARQを用いたデータ通信を行うことを決定してもよい。また、S801に替えて、AP102は、STAごとに個別でHARQのタイプを設定しているか否か、AP102がARQとHARQの切り替えができる能力を持っているか否かに基づいて、HARQを用いたデータ通信を行うか否かを決定してもよい。
AP102および接続中の各STAがHARQをサポートしていると判断された場合(S801でYes)、IR可否判定部305は、HARQを用いたデータ通信を行うAP102と各STAの各組において、接続帯域(周波数帯域)の幅、および、HARQ-IRを用いた通信に使用可能なバッファ領域(バッファ空き容量)を確認する(S803)。続いて、IR可否判定部305は、確認した容量の値から、当該接続帯域幅にてHARQ-IRを用いたデータ通信を行うことができるか否か(HARQ-IRが利用可能か否か)を判断する(S804)。IR可否判定部305が、HARQ-IRのために必要な空きバッファ容量を確保できない等、HARQ-IRを用いたデータ通信を行うことができないと判断した場合(S804でNo)、再送タイプ決定部306は、HARQ-CCを用いたデータ通信を行うことを決定する(S807)。一方、IR可否判定部305は、HARQ-IRを用いたデータ通信を行うことができると判断した場合(S804でYes)、さらにSTAがHARQ-IRをサポートしているか否かを判断する(S805)。当該判断は、MACフレーム送受信部303が、トリガーフレームなどのコントロールフレームにHARQ element500を含めて送受信することにより行われ得る。また、当該判断は、MACフレーム送受信部303が既に受信していたMACフレームの内容に基づいて行われてもよい。
STAがHARQ-IRをサポートしていないと判断された場合(S805でNo)、再送タイプ決定部306は、HARQ-CCを用いたデータ通信を行うことを決定する(S807)。STAがHARQ-IRをサポートしていると判断された場合(S805でYes)、再送タイプ決定部306は、HARQ-IRを用いたデータ通信を行うことを決定する(S806)。
S802、S806、S807の決定の後、処理はS808に進む。S808では、MACフレーム送受信部303は、決定した再送タイプをSTAに通知する。当該通知は、トリガーフレームを用いて行われ得る。また、当該通知は、ActionフレームやBlock Ack Requestフレームなどの他のコントロールフレームを用いて行われてもよい。決定した再送タイプの通知後、データ送受信部307は、再送タイプ決定部306により決定された再送タイプを用いて、データの送受信を行う(S809)。S808の通知においてトリガーフレームが使用され、当該トリガーフレームが同時データ通信を指示するものであった場合、STAは、指示されたDuration timeの間においてのみ、決定された再送タイプを用いてデータ通信を行ってもよい。
図9に、S808の通知に用いられ得るトリガーフレームの例を示す。なお、S808の通知は、図9に示す構成を有する他のフレームにより行われてもよい。図9のトリガーフレーム900において、Common Infoフィールド905にすべてのSTAに共通するパラメータが記述される。Trigger Typeフィールド909はトリガーフレームの種類を示す。UL Lengthフィールド910はデータフレームの最大の長さを示す。User Infoフィールド906に各STAにて定める情報を示す。AIDフィールド911は、どのSTAのストリームかを対応付けるためのフィールドである。これを見ることで、STAは自分への指示かどうかを判断することができる。RU Allocationフィールド912は、各STAに割り当てた通信帯域幅やどこの帯域を割り当てたかという場所情報が含まれる。HARQ typeフィールド913はHARQを用いたデータ通信を行うか、HARQを用いたデータ通信を行う場合はHARQのタイプを示す情報が含まれる。この値を見ることで、STAは自分がどの通信方式で通信すればよいかを判断することができるようになる。また、HARQ typeフィールド913を、User Infoフィールド906の内部に配置することで、STAごとでHARQのタイプ変更が可能となる。HARQ typeフィールド913は別のところに配置してもよい。例えば、Common Infoフィールド906の内部に配置すると、STAに一括してHARQ typeを通知することができる。
このように、本実施形態によれば、APは、自身のHARQについての能力に基づいて、STAとの通信における再送タイプを決定することができる。また、データの送受信に使用するHARQのタイプを、STAとAPとの間で交換することができる。
[その他の実施形態]
本発明は、上述の実施形態の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路(例えば、ASIC)によっても実現可能である。
発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。
101 ネットワーク 102 AP(アクセスポイント)、103~105 STA(ステーション)

Claims (10)

  1. 通信装置であって、
    他の通信装置との間で、IEEE802.11シリーズの規格に準拠するデータ通信であって、HARQ(ハイブリッド自動再送要求)を用いるデータ通信を行う通信手段と、
    少なくとも前記通信装置における前記HARQを用いたデータ通信に使用可能なメモリのバッファ空き容量と、閾値とに基づいて、複数の再送タイプの中から前記通信手段による前記他の通信装置とのデータ通信に用いる前記HARQの再送タイプを決定する決定手段と、
    有し、
    記通信手段は、前記決定手段によって決定された再送タイプを用いて前記他の通信装置に対するデータ通信を行い、
    前記閾値は、前記通信装置と前記他の通信装置とが接続する周波数帯域の幅に少なくとも基づいて設定されることを特徴とする通信装置。
  2. 前記決定手段は、前記バッファ空き容量が前記閾値以上である場合に、第1の再送タイプまたは第2の再送タイプを利用可能であると判断し、前記バッファ空き容量が前記閾値に満たない場合に、第2の再送タイプを利用可能であると判断し、利用可能であると判断した再送タイプの中から、前記他の通信装置とのデータ通信で用いる前記HARQの再送タイプを決定することを特徴とする請求項に記載の通信装置。
  3. 前記第1の再送タイプは、IR(Incremental Redundancy)タイプであり、前記第2の再送タイプは、CC(Chase Combining)タイプであることを特徴とする請求項に記載の通信装置。
  4. 前記閾値は、前記幅と、前記通信装置のメモリにおいてデータを滞留させる時間少なくとも基づいて設定されることを特徴とする請求項1から3のいずれか1項に記載の通信装置。
  5. 前記他の通信装置が利用できる前記HARQの再送タイプの情報を取得する取得手段をさらに有し
    前記決定手段は、前記他の通信装置が利用できる前記HARQの再送タイプにさらに基づき、前記HARQの再送タイプを決定する、ことを特徴とする請求項1に記載の通信装置。
  6. 前記取得手段は、マネージメントフレームの送受信により、前記他の通信装置が利用できる前記HARQの再送タイプの情報を取得することを特徴とする請求項に記載の通信装置。
  7. 記他の通信装置に対して、前記通信装置との前記データ通信のための周波数帯域の幅情報を通知する通知手段を更に有し、
    前記通知手段による前記通知の後、前記通信手段は、前記データ通信を行うことを特徴とする請求項またはに記載の通信装置。
  8. 複数の前記他の通信装置が前記通信装置に接続されている場合、
    前記決定手段は、前記他の通信装置のそれぞれに対して前記データ通信に用いる前記HARQの再送タイプを決定し、
    前記通知手段は、前記他の通信装置のそれぞれに対して、使用する再送タイプ、前記通信装置と前記データ通信のための周波数帯域の幅の情報を通知し、
    前記通知手段による前記通知の後、前記通信手段は、前記決定手段により決定された再送タイプを用いて、前記他の通信装置のそれぞれに対して前記データ通信を行うことを特徴とする請求項に記載の通信装置。
  9. 通信装置の制御方法であって、
    少なくとも前記通信装置におけるHARQ(ハイブリッド自動再送要求)を用いたデータ通信に使用可能なメモリのバッファ空き容量と、閾値とに基づいて、複数の再送タイプの中から他の通信装置とのデータ通信に用いる前記HARQの再送タイプを決定する決定工程と、
    EEE802.11シリーズの規格に準拠するデータ通信であって、前記決定工程において決定された再送タイプの前記HARQを用いて、前記他の通信装置とデータ通信を行う通信工程と、
    を有し、
    前記閾値は、前記通信装置と前記他の通信装置とが接続する周波数帯域の幅に少なくとも基づいて設定されることを特徴とする通信装置の制御方法。
  10. コンピュータを、請求項1からのいずれか1項に記載の通信装置として機能させるためのプログラム。
JP2020048026A 2020-03-18 2020-03-18 通信装置、通信装置の制御方法、およびプログラム Active JP7458839B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2020048026A JP7458839B2 (ja) 2020-03-18 2020-03-18 通信装置、通信装置の制御方法、およびプログラム
US17/181,121 US11671206B2 (en) 2020-03-18 2021-02-22 Communication apparatus for determination of hybrid automatic repeat request, method of controlling communication apparatus, and non-transitory computer-readable storage medium for same

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2020048026A JP7458839B2 (ja) 2020-03-18 2020-03-18 通信装置、通信装置の制御方法、およびプログラム

Publications (3)

Publication Number Publication Date
JP2021150777A JP2021150777A (ja) 2021-09-27
JP2021150777A5 JP2021150777A5 (ja) 2023-03-20
JP7458839B2 true JP7458839B2 (ja) 2024-04-01

Family

ID=77748520

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020048026A Active JP7458839B2 (ja) 2020-03-18 2020-03-18 通信装置、通信装置の制御方法、およびプログラム

Country Status (2)

Country Link
US (1) US11671206B2 (ja)
JP (1) JP7458839B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7308623B2 (ja) 2019-02-28 2023-07-14 キヤノン株式会社 情報処理装置並びにその制御方法、及び、プログラム
JP7339758B2 (ja) * 2019-04-11 2023-09-06 キヤノン株式会社 通信装置、通信方法、及び、プログラム

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005536159A (ja) 2002-08-13 2005-11-24 松下電器産業株式会社 複数harq処理のための処理設定の方法
JP2006246457A (ja) 2005-03-02 2006-09-14 Alcatel データを伝送するための適切なharq再伝送スキームを選択するための方法、およびそのような方法のための基地局およびプログラムモジュール
JP2011082869A (ja) 2009-10-08 2011-04-21 Ntt Docomo Inc 無線通信システム、無線送信装置及び無線受信装置
WO2019044535A1 (ja) 2017-08-31 2019-03-07 ソニー株式会社 通信装置および方法
US20200052832A1 (en) 2018-08-10 2020-02-13 Qualcomm Incorporated Hybrid automatic repeat request (harq) in a wireless local area network (wlan)

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6865233B1 (en) * 1999-02-19 2005-03-08 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for control signalling enabling flexible link adaptation in a radiocommunication system
WO2006013630A1 (ja) * 2004-08-05 2006-02-09 Mitsubishi Denki Kabushiki Kaisha 基地局、移動通信端末装置およびプライマリセル選択方法
KR101531503B1 (ko) * 2007-09-10 2015-06-26 엘지전자 주식회사 다중 harq를 이용한 신호 전송 방법
KR101387530B1 (ko) * 2007-12-28 2014-04-21 엘지전자 주식회사 자동 재전송 요구를 위한 자원할당방법
KR101634666B1 (ko) * 2008-04-18 2016-06-29 삼성전자주식회사 광대역 무선통신 시스템에서 동기식 복합 자동 재전송을 지원하기 위한 장치 및 방법
JP2011193434A (ja) * 2009-10-28 2011-09-29 Panasonic Corp パリティパケットを用いた通信方法、通信装置及び中継器
WO2013125767A1 (ko) * 2012-02-20 2013-08-29 엘지전자 주식회사 무선 접속 시스템에서 데이터 송수신 방법 및 이를 위한 장치
WO2016036196A1 (ko) * 2014-09-04 2016-03-10 엘지전자 주식회사 무선 통신 시스템에서 d2d통신 및 wan통신을 위한 버퍼 운영 방법 및 이를 위한 장치
CN111431662B (zh) * 2014-09-25 2023-09-19 索尼公司 无线通信装置和无线通信方法
WO2018012259A1 (ja) * 2016-07-15 2018-01-18 株式会社Nttドコモ ユーザ装置及び無線通信方法
JP2018050133A (ja) 2016-09-20 2018-03-29 キヤノン株式会社 通信装置、制御方法、及びプログラム
EP3837786B1 (en) * 2018-09-27 2022-11-23 Sony Group Corporation Infrastructure equipment, communications device and methods
US11469859B2 (en) * 2019-04-25 2022-10-11 Qualcomm Incorporated Hybrid automatic repeat request (HARQ) technique based on receiver processing capability
US20220231797A1 (en) * 2019-04-29 2022-07-21 Lg Electronics Inc. Nack frame for harq operation
US11349612B2 (en) * 2019-09-26 2022-05-31 Newracom, Inc. Hybrid automatic repeat request techniques in a wireless local area network

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005536159A (ja) 2002-08-13 2005-11-24 松下電器産業株式会社 複数harq処理のための処理設定の方法
JP2006246457A (ja) 2005-03-02 2006-09-14 Alcatel データを伝送するための適切なharq再伝送スキームを選択するための方法、およびそのような方法のための基地局およびプログラムモジュール
JP2011082869A (ja) 2009-10-08 2011-04-21 Ntt Docomo Inc 無線通信システム、無線送信装置及び無線受信装置
WO2019044535A1 (ja) 2017-08-31 2019-03-07 ソニー株式会社 通信装置および方法
US20200052832A1 (en) 2018-08-10 2020-02-13 Qualcomm Incorporated Hybrid automatic repeat request (harq) in a wireless local area network (wlan)

Also Published As

Publication number Publication date
US20210297189A1 (en) 2021-09-23
US11671206B2 (en) 2023-06-06
JP2021150777A (ja) 2021-09-27

Similar Documents

Publication Publication Date Title
JP5438115B2 (ja) キャリアアグリゲーションのためのrlc分割
WO2018059282A1 (en) System and method for d2d communication
US11251908B2 (en) Advanced coding on retransmission of data and control
JP5275410B2 (ja) ワイドバンド幅を使用したワイヤレスネットワークのレスポンスメカニズム
EP3603256B1 (en) Network node and method in a wireless communications network
JP2022512956A (ja) 高度なharq設計を用いてwlanを強化するための方法
WO2021027518A1 (zh) 处理数据的方法和通信装置
CN113169821A (zh) 用于多频带业务流的通信设备和通信方法
EP3123625B1 (en) Segmented transfers in mobile networks using coordinated multipoint
US20080270866A1 (en) Transmission with automatic repeat request process
CN104285400A (zh) 通信中的混合自动重传请求
WO2015141728A1 (ja) 通信制御方法及びユーザ端末
WO2020168635A1 (en) Method and apparatus for service continuity across lf and mmwave
US20230139754A1 (en) Coding method and apparatus
WO2020011264A1 (zh) 一种信道质量通知方法、接收方法和装置
JP7458839B2 (ja) 通信装置、通信装置の制御方法、およびプログラム
US20230179343A1 (en) Efficient uplink hybrid automatic repeat request feedback for point to multipoint transmissions
US11470623B2 (en) Electronic device, method for wireless communication system and storage medium
WO2015013965A1 (zh) 一种数据传输资源配置的方法和设备
KR20100113458A (ko) 무선 통신 시스템상에서 단말의 mac 계층에 의해 무선 자원을 구성하는 방법
WO2019139516A1 (en) Radio node and methods in a wireless communications network
KR20210138012A (ko) 통신 제어 장치 및 방법, 그리고 무선 통신 장치 및 방법
WO2020089221A1 (en) Wireless data transmission apparatus, wireless data reception apparatus and methods
WO2022149316A1 (ja) 基地局、通信装置及び通信方法
WO2023058264A1 (ja) 通信装置及び通信方法

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

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230310

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230310

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20231207

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20231211

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240205

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: 20240219

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240319

R151 Written notification of patent or utility model registration

Ref document number: 7458839

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151