JP2024506354A - マルチリンクを用いる無線通信方法及びこれを用いる無線通信端末 - Google Patents

マルチリンクを用いる無線通信方法及びこれを用いる無線通信端末 Download PDF

Info

Publication number
JP2024506354A
JP2024506354A JP2023548732A JP2023548732A JP2024506354A JP 2024506354 A JP2024506354 A JP 2024506354A JP 2023548732 A JP2023548732 A JP 2023548732A JP 2023548732 A JP2023548732 A JP 2023548732A JP 2024506354 A JP2024506354 A JP 2024506354A
Authority
JP
Japan
Prior art keywords
frame
txop
sta
ppdu
nav
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
Application number
JP2023548732A
Other languages
English (en)
Inventor
ゴンジュン・コ
ジュヒョン・ソン
サンヒュン・キム
ジンサム・カク
Original Assignee
ウィルス インスティテュート オブ スタンダーズ アンド テクノロジー インコーポレイティド
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 ウィルス インスティテュート オブ スタンダーズ アンド テクノロジー インコーポレイティド filed Critical ウィルス インスティテュート オブ スタンダーズ アンド テクノロジー インコーポレイティド
Publication of JP2024506354A publication Critical patent/JP2024506354A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W74/00Wireless channel access
    • H04W74/04Scheduled access
    • H04W74/06Scheduled access using polling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W74/00Wireless channel access
    • H04W74/08Non-scheduled access, e.g. ALOHA
    • H04W74/0833Random access procedures, e.g. with 4-step access
    • H04W74/0841Random access procedures, e.g. with 4-step access with collision treatment
    • H04W74/085Random access procedures, e.g. with 4-step access with collision treatment collision avoidance
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W74/00Wireless channel access
    • H04W74/002Transmission of channel access control information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14Multichannel or multilink protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/50Allocation or scheduling criteria for wireless resources
    • H04W72/535Allocation or scheduling criteria for wireless resources based on resource usage policies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W74/00Wireless channel access
    • H04W74/08Non-scheduled access, e.g. ALOHA
    • H04W74/0808Non-scheduled access, e.g. ALOHA using carrier sensing, e.g. carrier sense multiple access [CSMA]
    • H04W74/0816Non-scheduled access, e.g. ALOHA using carrier sensing, e.g. carrier sense multiple access [CSMA] with collision avoidance
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W74/00Wireless channel access
    • H04W74/08Non-scheduled access, e.g. ALOHA
    • H04W74/0866Non-scheduled access, e.g. ALOHA using a dedicated channel for access
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/15Setup of multiple wireless link connections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/02Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10Small scale networks; Flat hierarchical networks
    • H04W84/12WLAN [Wireless Local Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W74/00Wireless channel access
    • H04W74/002Transmission of channel access control information
    • H04W74/004Transmission of channel access control information in the uplink, i.e. towards network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W74/00Wireless channel access
    • H04W74/002Transmission of channel access control information
    • H04W74/006Transmission of channel access control information in the downlink, i.e. towards the terminal

Landscapes

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

Abstract

無線通信システムにおいてSTA(station:STA)がフレームを送信する方法が開示される。本発明に係るSTAは、AP(Access Point)から上りリンク送信を指示するトリガーフレーム(trigger frame)を受信し、トリガーフレームに基づいて前記共有されたTXOP内で前記AP及び/又は他のSTAにPPDU(Physical layer Protocol Data Unit)を送信する。この時、トリガーフレームは、前記APによって取得された送信機会(transmission opportunity:TXOP)の一部又は全部を前記STAに共有するために用いられる。また、PPDUは、前記PPDUの送信のためのTXOPを指示するデュレーション情報を含み、デュレーション情報は、前記共有されたTXOPに基づいて設定される。

Description

本発明は、マルチリンクを用いる無線通信方法及びこれを用いる無線通信端末に関し、特に、TXOPを設定してデータを送受信するための方法及び端末に関する。
最近、モバイル機器の普及が拡大されるにつれ、それらに速い無線インターネットサービスを提供し得る無線LAN(Wireless LAN)技術が脚光を浴びている。無線LAN技術は、近距離で無線通信技術に基づいてスマートフォン、スマートパッド、ラップトップPC、携帯型マルチメディアプレーヤー、インベデッド機器などのようなモバイル機器を家庭や企業、または特定サービス提供地域において、無線でインターネットに接続し得るようにする技術である。
IEEE(Istitute of Electronics Engineers) 802.11は、2.4GHのz周波数を利用した初期の無線LAN技術を支援して以来、多様な技術の標準を実用化または開発中である。まず、IEEE 802.11bは2.4GHzバンドの周波数を使用し、最高11Mbpsの通信速度を支援する。IEEE 802.11bの後に商用化されたIEEE 802.11aは2.4GHzバンドではなく5GHzバンドの周波数を使用することで、相当混雑した2.4GHzバンドの周波数に比べ干渉への影響を減らしており、OFDM技術を使用して通信速度を最大54Mbpsまで向上させている。しかし、IEEE 802.11aはIEEE 802.11bに比べ通信距離が短い短所がある。そして、IEEE 802.11gはIEEE 802.11bと同じく2.4GHzバンドの周波数を使用して最大54Mpbsの通信速度を具現し、下位互換性(backward compatibility)を満足していて相当な注目を浴びたが、通信距離においてもIEEE 802.11aより優位にある。
そして、無線LANで脆弱点として指摘されていた通信速度に関する限界を克服するために制定された技術規格として、IEEE 802.11nがある。IEEE 802.11nはネットワークの速度と信頼性を増加させ、無線ネットワークの運営距離を拡張することにその目的がある。詳しくは、IEEE 802.11nではデータ処理速度が最大540Mbps以上の高処理率(High Throughput、HT)を支援し、また、伝送エラーを最小化しデータの速度を最適化するために送信部と受信部の両端共に多重アンテナを使用するMIMO(Multiple Inputs and Multiple Outputs)技術を基盤としている。また、この規格はデータの信頼性を上げるために重複する写本を複数個伝送するコーディング方式を使用している。
無線LANの普及が活性化され、また、それを使用したアプリケーションが多様化するにつれ、IEEE 802.11nが支援するデータの処理速度より高い処理率(Very High Throughput、VHT)を支援するための新たな無線LANシステムに対する必要性が台頭している。そのうち、IEEE 802.11acは5GHz周波数で広い帯域幅(80MHz~160MHz)を支援する。IEEE 802.11ac標準は5GHz帯域でのみ定義されているが、従来の2.4GHz帯域の製品との下位互換性のために、初期11acチップセットは2.4GHz帯域での動作も支援すると考えられる。理論的に、この規格によると多重ステーションの無線LANの速度は最小1Gbps、最大単一リンク速度は最小500Mbpsまで可能になる。これはより広い無線周波数帯域幅(最大160MHz)、より多いMIMO空間的ストリーム(最大8個)、マルチユーザMIMO、そして、高い密度の変調(最大256QAM)など、802.11nで受け入れられた無線インタフェースの概念を拡張して行われる。また、従来の24GHz/5GHzに代わって60GHzバンドを利用してデータを伝送する方式として、IEEE 802.11adがある。IEEE 802.11adはビームフォーミング技術を利用して最大7Gbpsの速度を提供する伝送規格であって、大容量のデータや無圧縮HDビデオなど、高いビットレート動画のストリーミングに適合している。しかし、60GHz周波数バンドは障害物の通過が難しく、近距離空間でのデバイスの間でのみ利用可能な短所がある。
一方、802.11ac及び802.11ad以後の無線LAN標準として、APと端末が密集した高密度環境における高効率及び高性能の無線LAN通信技術を提供するためのIEEE 802.11ax(High Efficiency WLAN,HEW)標準が開発され、完了段階にある。802.11axベース無線LAN環境では、高密度のステーションとAP(Access Point)の存在下に屋内/屋外で高い周波数効率の通信が提供される必要があり、これを具現するための様々な技術が開発されている。
また、高画質ビデオ、実時間ゲームなどのような新しいマルチメディア応用を支援するために、最大送信速度を上げるための新しい無線LAN標準を開発し始めた。7世代無線LAN標準であるIEEE 802.11be(Extremely High Throughput,EHT)では、2.4/5/6GHzの帯域でより広い帯域幅と増加した空間ストリーム及び多重AP協調などによって最大で30Gbpsの送信率を支援することを目標に標準開発を進行している。IEEE 802.11beでは320MHzの帯域幅、多重リンク(Multi-link)動作、多重AP(Multi-Access Point、Multi-AP)動作、及び再伝送動作(Hybrid Automatic Repeat Request、HARQ)などの技術が提案されている。
多重リンク動作はその動作方式及び具現方法によって多様な形態に動作される。この際、従来のIEEE 802.11基盤の無線LAN通信動作では発生していなかった問題が発生する可能性があることで、多重リンク動作における詳細な動作方法に対する定義が必要である。
一方、発明の背景になる技術は発明の背景に対する理解を増進するために作成されたものであって、この技術が属する分野における通常の知識を有する者に既に知られている従来技術ではない内容を含む。
本発明は、多重リンク動作において、送信機会(transmission opportunity:TXOP)の設定を用いてデータを送受信する方法及び装置を提供することにその目的がある。
また、本発明は、AP(Access Point)によって設定されたTXOPをnon-AP STAに共有することにより、non-AP STAがデータを送受信する方法及び装置を提供することにその目的がある。
また、本発明は、共有されたTXOP内でnon-AP STAがデータを送受信するためにNAV(network allocation vector)を設定するための方法及び装置を提供することにその目的がある。
本明細書で遂げようとする技術的課題は、以上に言及している技術的課題に限定されず、言及していない別の技術的課題は、以下の記載から、本発明の属する技術の分野における通常の知識を有する者に明確に理解されるであろう。
無線通信システムのSTA(station:STA)は、送受信部;及び、前記送受信部を制御するプロセッサを含み、前記プロセッサは、AP(Access Point)から上りリンク送信を指示するトリガーフレーム(trigger frame)を受信し、前記トリガーフレームは、前記APによって取得された送信機会(transmission opportunity:TXOP)の一部又は全部を前記STAに共有するために用いられ、前記トリガーフレームに基づいて、前記共有されたTXOP内で前記AP及び/又は他のSTAにPPDU(Physical layer Protocol Data Unit)を送信し、前記PPDUは、前記PPDUの送信のためのTXOPを指示するデュレーション情報を含み、前記デュレーション情報は、前記共有されたTXOPに基づいて設定される。
また、本発明において、前記デュレーション情報によって指示されるデュレーションの終了時点は、前記共有されたTXOPの終了時点と同一である。
また、本発明において、前記デュレーション情報によって指示されるデュレーションは、前記共有されたTXOPの終了時点よりも以前に終了する。
また、本発明において、前記TXOP内で前記APによって送信されるフレームによってNAV(network allocation vector)が設定される場合に、前記PPDUは、前記共有されたTXOP内で前記設定されたNAVに関係なく送信される。
また、本発明において、さらに他のSTAによって前記トリガーフレームに基づいて、前記共有されたTXOP内でNAV及び前記NAVの終了時間を示すNAVタイムアウト周期(timeout period)が設定された場合に、前記共有されたTXOP内で前記NAVタイムアウト周期が満了しても、前記共有されたTXOP内で前記さらに他のSTAによって設定された前記NAVは、前記NAVタイムアウト周期の満了によって解除されない。
また、本発明において、前記トリガーフレームは、前記トリガーフレームによる前記TXOPの共有の有無を示すサブフィールドを含む。
また、本発明において、前記サブフィールドが前記TXOPの共有を示す場合に、前記サブフィールドの値は、前記共有されたTXOP内で前記他のSTAと送受信可能であるか否かを示す。
また、本発明において、前記トリガーフレームは、前記トリガーフレームのタイプを示すタイプフィールドを含み、前記TXOPの前記一部又は全部の共有は、前記タイプフィールドによる前記トリガーフレームの前記タイプによって設定される。
また、本発明は、AP(Access Point)から上りリンク送信を指示するトリガーフレーム(trigger frame)を受信する段階であって、前記トリガーフレームが、前記APによって取得された送信機会(transmission opportunity:TXOP)の一部又は全部を前記STAに共有するために用いられる、段階;及び、前記トリガーフレームに基づいて、前記共有されたTXOP内で前記AP及び/又は他のSTAにPPDU(Physical layer Protocol Data Unit)を送信する段階であって、前記PPDUが、前記PPDUの送信のためのTXOPを指示するデュレーション情報を含み、前記デュレーション情報が、前記共有されたTXOPに基づいて設定される、段階;を含む方法を提供する。
本発明の一実施例によれば、APによって設定されたTXOPをnon-AP STAに共有することにより、non-AP STAがデータを効率的に送受信できる効果がある。
また、本発明の一実施例によれば、共有されたTXOP内でnon-AP STAがデータを送受信するためのNAVを共有されたTXOPに基づいて設定したり、又は設定されたNAVを共有されたTXOPによって解釈したりすることにより、データを効率的に送信できる効果がある。
本発明から得られる効果は、以上で言及した効果に限定されず、言及していない別の効果は、以下の記載から、本発明の属する技術の分野における通常の知識を有する者に明確に理解されるであろう。
本発明の一実施例による無線LANシステムを示す図である。 本発明の他の実施例による無線LANシステムを示す図である。 本発明の一実施例によるステーションの構成を示す図である。 本発明の一実施例によるアクセスポイントの構成を示す図である。 STAがAPとリンクを設定する過程を概略的に示す図である。 無線LAN通信で使用されるCSMA(Carrier Sense Multiple Access)/CA(Collision Avoidance)方法を示す図である。 様々な標準世代別PPDU(PLCP Protocol Data Unit)フォーマットの一例を示す図である。 本発明の実施例に係る様々なEHT(Extremely High Throughput)PPDU(Physical Protocol Data Unit)フォーマット及びこれを指示するための方法の一例を示す図である。 本発明の一実施例に係る多重リンク(multi-link)装置を示す図である。 本発明の一実施例に係るTID-to-linkマッピング方法の一例を示す図である。 本発明の一実施例に係るmulti-link NAV設定動作の一例を示す図である。 本発明の一実施例に係るmulti-link NAV設定動作のさらに他の例を示す図である。 本発明の一実施例に係るBSS分類及びそれに基づく動作の一例を示す図である。 本発明の一実施例に係る無線LAN機能を示す図である。 本発明の一実施例に係る上りリンク(Uplink:UL)多重ユーザ(multi user:MU)動作を示す図である。 本発明の一実施例に係るトリガーフレーム(Trigger frame)フォーマットを示す図である。 本発明の一実施例に係るトリガーベースPPDUフォーマットを指示するための方法を示す図である。 本発明の一実施例に係るUL MU動作の一例を示す図である。 本発明の一実施例に係るTXOPを共有するための方法を示す図である。 本発明の一実施例に係るTXOPの共有及びNAV設定と関連した方法を示す図である。 本発明の一実施例に係るTXOPの共有及びCTSフレームの送信を示す図である。 本発明の一実施例に係るTXOPの共有のためのトリガーフレームの一例を示す図である。 本発明の一実施例に係るNAVタイムアウト(time out)を示す図である。 本発明の一実施例に係るTXOPの共有及びNAVタイムアウトを示す図である。 本発明のさらに他の実施例に係るTXOPの共有及びNAVタイムアウトを示す図である。 本発明のさらに他の実施例に係るTXOPの共有及びNAVタイムアウトを示す図である。 本発明の一実施例によってTXOP共有が適用される時に、STA及びAPがNAVを適用することを示す図である。 本発明の一実施例によってSTAがTXOPの共有を終了することを示す図である。 本発明の一実施例に係るSTAの動作の一例を示すフローチャートである。
本明細書で使用される用語は、本発明での機能を考慮してできる限り現在広く使用されている一般的用語を選択しているが、これは該当技術分野に携わる技術者の意図、慣例、または新たな技術の出現などによって異なり得る。また、特定の場合は出願人が任意に選定した用語もあり、このような場合は該当する発明の説明部分でその意味を記載する。よって、本明細書で使用される用語は単なる用語の名称ではなく、その用語が有する実質的な意味と本明細書全般にわたる内容に基づいて解釈すべきであることを明らかにする。
明細書全体にわたって、ある構成が他の構成と「連結」されているとすると、これは「直接連結」されている場合だけでなく、その中間に他の構成要素を間に挟んで「電気的に連結」されている場合も含む。また、ある構成要素が特定の構成要素を「含む」とすると、これは特に反対する記載がない限り、他の構成要素を除くのではなく他の構成要素を更に含み得ることを意味する。加えて、特定臨界値を基準に「以上」または「以下」という限定事項は、実施例によってそれぞれ「超過」または「未満」に適切に代替され得る。以下、本発明において、フィールドとサブフィールドは同じ意味で使われてよい。
図1は、本発明の一実施例による無線LANシステムを示す図である。
無線LANシステムは、一つまたはそれ以上のベーシックサービスセット(Basic Service Set、BSS)を含むが、BSSは同期化に成功し互いに通信し得る機器の集合を示す。一般に、BSSはインフラストラクチャBSS(infrastructure BSS)と独立BSS(Independent BSS、IBSS)に区分されるが、図1はこのうちインフラストラクチャBSSを示している。
図1に示すように、インフラストラクチャBSS BSS1,BSS2は、1つ又はそれ以上のステーションSTA1,STA2,STA3,STA4,STA5、分配サービス(Distribution Service)を提供するステーションであるアクセスポイントAP-1,AP-2、及び複数のアクセスポイントAP-1,AP-2を連結させる分配システム(Distribution System)DSを含む。
ステーション(Station、STA)は、IEEE 802.11標準の規定に従う媒体接続制御(Medium Access Control、MAC)と無線媒体に対する物理層(Physical Layer)インタフェースを含む任意のデバイスであって、広い意味では非アクセスポイントnon-APステーションのみならずアクセスポイントAPを全て含む。また、本明細書において、「端末」とはnon-APまたはAPを指すか、両者を全て指す用語として使用される。無線通信のためのステーションはプロセッサと通信部を含み、実施例によってユーザインタフェース部とディスプレーユニットなどを更に含む。プロセッサは無線ネットワークを介して伝送するフレームを生成するか、または前記無線ネットワークを介して受信されたフレームを処理し、その他にステーションを制御するための多様な処理を行う。そして、通信部は前記プロセッサと機能的に連結されており、ステーションのために無線ネットワークを介してフレームを送受信する。本発明において、端末はユーザ端末機(user equipment、UE)を含む用語として使用される。
アクセスポイント(Access Point、AP)は、自らに結合された(associated)ステーションのために無線媒体を経由して分配システムDSに対する接続を提供する個体である。インフラストラクチャBSSにおいて、非APステーション間の通信はAPを経由して行われることが原則であるが、ダイレクトリンクが設定されている場合は非APステーションの間でも直接通信が可能である。一方、本発明において、APはPCP(Personal BSS Coordination Point)を含む概念として使用されるが、広い意味では集中制御器、基地局(Base Station、BS)、ノードB、BTS(Base Transceiver System)、またはサイト制御器などの概念を全て含む。本発明において、APはベース無線通信端末とも称されるが、ベース無線通信端末は、広い意味ではAP、ベースステーション(base station)、eNB(eNodeB)、及びトランスミッションポイントTPを全て含む用語として使用される。それだけでなく、ベース無線通信端末は複数の無線通信端末との通信で通信媒介体(medium)資源を割り当て、スケジューリング(scheduling)を行う多様な形態の無線通信端末を含む。
複数のインフラストラクチャBSSは、分配システムDSを介して互いに連結される。この際、分配システムを介して連結された複数のBSSを拡張サービスセット(Extended Service Set、ESS)という。
図2は、本発明の他の実施例による無線LANシステムである独立BSSを示す図である。図2の実施例において、図1の実施例と同じであるか相応する部分は重複する説明を省略する。
図2に示したBSS3は独立BSSであってAPを含まないため、全てのステーション(STA6、STA7)がAPと接続されていない状態である。独立BSSは分配システムへの接続が許容されず、自己完備的ネットワーク(self-contained network)をなす。独立BSSにおいて、それぞれのステーション(STA6、STA7)はダイレクトに互いに連結される。
図3は、本発明の一実施例によるステーション100の構成を示すブロック図である。図示したように、本発明の実施例によるステーション100は、プロセッサ110、通信部120、ユーザインタフェース部140、ディスプレーユニット150、及びメモリ160を含む。
まず、通信部120は、無線LANパケットなどの無線信号を送受信し、ステーション100に組み込まれる又は外付けられて具備されてよい。実施例によれば、通信部120は、互いに異なる周波数バンドを用いる少なくとも1つの通信モジュールを含むことができる。例えば、前記通信部120は、2.4GHz、5GHz、6GHz及び60GHzなどの異なる周波数バンドの通信モジュールを含むことができる。一実施例によれば、ステーション100は、7.125GHz以上の周波数バンドを用いる通信モジュールと、7.125GHz以下の周波数バンドを用いる通信モジュールを備えることができる。それぞれの通信モジュールは、当該通信モジュールが支援する周波数バンドの無線LAN規格に基づいてAP又は外部ステーションと無線通信を行うことができる。通信部120は、ステーション100の性能及び要求事項に応じて1回に1つの通信モジュールのみを動作させるか、同時に複数の通信モジュールを共に動作させることができる。ステーション100が複数の通信モジュールを含む場合に、各通信モジュールはそれぞれ独立した形態で備えられてもよく、複数のモジュールが1つのチップとして統合して備えられてもよい。本発明の実施例において、通信部120は、RF(Radio Frequency)信号を処理するRF通信モジュールを表すことができる。
次に、ユーザインタフェース140は、ステーション100に備えられた多様な形態の入出力手段を含む。つまり、ユーザインタフェース部140は多様な入力手段を利用してユーザの入力を受信し、プロセッサ110は受信されたユーザ入力に基づいてステーション100を制御する。また、ユーザインタフェース部140は、多様な出力手段を利用してプロセッサ110の命令に基づく出力を行う。
次に、ディスプレーユニット150は、ディスプレー画面にイメージを出力する。前記ディスプレーユニット150は、プロセッサ110によって行われるコンテンツ、またはプロセッサ110の制御命令に基づくユーザインタフェースなどの多様なディスプレーオブジェクトを出力する。また、メモリ160は、ステーション100で使用される制御プログラム及びそれによる各種データを貯蔵する。このような制御プログラムには、ステーション100がAPまたは外部のステーションと接続を行うのに必要な接続プログラムが含まれる。
本発明のプロセッサ110は多様な命令またはプログラムを行い、ステーション100内部のデータをプロセッシングする。また、前記プロセッサ110は上述したステーション100の各ユニットを制御し、ユニット間のデータの送受信を制御する。本発明の実施例によると、プロセッサ110はメモリ160に貯蔵されたAPとの接続のためのプログラムを行い、APが伝送した通信設定メッセージを受信する。また、プロセッサ110は通信設定メッセージに含まれたステーション100の優先条件に関する情報を読み取り、ステーション100の優先条件に関する情報に基づいてAPに関する接続を要請する。本発明のプロセッサ110はステーション100のメインコントロールユニットを指してもよく、実施例によってステーション100の一部の構成、例えば、通信部120などを個別的に制御するためのコントロールユニットを指してもよい。つまり、プロセッサ110は通信部120から送受信される無線信号を変復調するモデム、または変復調部(modulator and/or demodulator)であってもよい。プロセッサ110は、本発明の実施例によるステーション100の無線信号送受信の各種動作を制御する。それに関する詳しい実施例は後述する。
図3に示したステーション100は本発明の一実施例によるブロック図であって、分離して示したブロックはデバイスのエレメントを論理的に区別して示したものである。よって、上述したデバイスのエレメントは、デバイスの設計に応じて一つのチップまたは複数のチップに取り付けられる。例えば、前記プロセッサ110及び通信部120は一つのチップに統合されて具現されてもよく、別途のチップで具現されてもよい。また、本発明の実施例において、前記ステーション100の一部の構成、例えば、ユーザインタフェース部140及びディスプレーユニット150などはステーション100に選択的に備えられてもよい。
図4は、本発明の一実施例によるAP200の構成を示すブロック図である。図示したように、本発明の実施例によるAP200は、プロセッサ210、通信部220、及びメモリ260を含む。図4において、AP200の構成のうち図3のステーション100の構成と同じであるか相応する部分については重複する説明を省略する。
図4を参照すると、本発明に係るAP 200は、少なくとも1つの周波数バンドにおいてBSSを運営するための通信部220を備える。図3の実施例において前述したように、前記AP 200の通信部220も、互いに異なる周波数バンドを用いる複数の通信モジュールを含むことができる。すなわち、本発明の実施例に係るAP 200は、異なる周波数バンド、例えば、2.4GHz、5GHz、6GHz及び60GHzのいずれかを用いる2つ以上の通信モジュールを共に備えることができる。好ましくは、AP 200は、7.125GHz以上の周波数バンドを用いる通信モジュールと、7.125GHz以下の周波数バンドを用いる通信モジュールを備えることができる。それぞれの通信モジュールは、当該通信モジュールが支援する周波数バンドの無線LAN規格に基づいてステーションと無線通信を行うことができる。前記通信部220は、AP 200の性能及び要求事項に応じて1回に1つの通信モジュールのみを動作させるか、同時に複数の通信モジュールを共に動作させることができる。本発明の実施例において、通信部220は、RF(Radio Frequency)信号を処理するRF通信モジュールを表すことができる。
次に、メモリ260は、AP200で使用される制御プログラム及びそれによる各種データを貯蔵する。このような制御プログラムには、ステーションの接続を管理する接続プログラムが含まれる。また、プロセッサ210はAP200の各ユニットを制御し、ユニット間のデータの送受信を制御する。本発明の実施例によると、プロセッサ210はメモリ260に貯蔵されたステーションとの接続のためのプログラムを行い、1つ以上のステーションに対する通信設定メッセージを伝送する。この際、通信設定メッセージには各ステーションの接続優先条件に関する情報が含まれる。また、プロセッサ210はステーションの接続要請に応じて接続設定を行う。一実施例によると、プロセッサ210は通信部220から送受信される無線信号を変復調するモデム、または変復調部である。プロセッサ210は、本発明の実施例によるAP200の無線信号送受信の各種動作を制御する。それに関する詳しい実施例は後述する。
図5は、STAがAPとリンクを設定する過程を概略的に示す図である。
図5を参照すると、STA100とAP200間のリンクは大きくスキャニング(scanning)、認証(authentication)、及び結合(association)の3つのステップを介して設定される。まず、スキャニングステップは、AP200が運営するBSSの接続情報をSTA100が獲得するステップである。スキャニングを行うための方法としては、AP200が周期的に伝送するビーコン(beacon)メッセージS101のみを活用して情報を取得するパッシブスキャニング(passive scanning)方法と、STA100がAPにプローブ要請(probe request)を伝送しS103、APからプローブ応答(probe response)を受信してS105、接続情報を取得するアクティブスキャニング(active scanning)方法がある。
スキャニングステップにおいて無線接続情報の受信に成功したSTA100は、認証要請(authentication request)を伝送しS107a、AP200から認証応答(authentication response)を受信してS107b、認証ステップを行う。認証ステップが行われた後、STA100は結合要請(association request)を伝送しS109a、AP200から結合応答(association response)を受信してS109b、結合ステップを行う。本明細書において、結合とは基本的に無線結合を意味するが、本発明はこれに限らず、広い意味での結合は無線結合及び有線結合を全て含む。
一方、追加に802.1X基盤の認証ステップS111、及びDHCPを介したIPアドレス獲得ステップS113が行われる。図5において、サーバ300はSTA100と802.1X基盤の認証を処理するサーバであって、AP200に物理的に結合されて存在するか、別途のサーバとして存在してもよい。
図6は、無線LAN通信で使用されるCSMA(Carrier Sense Multiple Access)/CA(Collision Avoidance)方法を示す図である。
無線LAN通信を行う端末は、データを伝送する前にキャリアセンシング(Carrier Sensing)を行ってチャネルが占有状態(busy)であるのか否かをチェックする。もし一定強度以上の無線信号が感知されれば該当チャネルが占有状態と判別され、前記端末は該当チャネルに対するアクセスを遅延する。このような過程をクリアチャネル評価(Clear Channel Assessment、CCA)といい、該当信号の感知有無を決定するレベルをCCA臨界値(CCA threshold)という。もし端末に受信されたCCA臨界値以上の無線信号が該当端末を受信者とすれば、端末は受信された無線信号を処理する。一方、該当チャネルから無線信号が感知されないかCCA臨界値より小さい強度の無線信号が感知されれば、前記チャネルは遊休状態(idle)と判別される。
チャネルが遊休状態と判別されれば、伝送するデータがある各端末は、各端末の状況によるIFS(Inter Frame Space)、例えば、AIFS(Arbitration IFS)、PIFS(PCF IFS)などの時間の後にバックオフ手順を行う。実施例によって、前記AIFSは従来のDIFS(DCF IFS)を代替する構成として使用される。各端末は、該当端末に決定された乱数(random number)だけのスロットタイムを前記チャネルの遊休状態の間隔(interval)の間に減少させながら待機し、スロットタイムを全て消尽した端末が該当チャネルに対するアクセスを試みる。このように、各端末がバックオフ手順を行う区間を競合ウィンドウ区間という。
もし特定端末が前記チャネルのアクセスに成功すれば、該当端末は前記チャネルを介してデータを伝送する。しかし、アクセスを試みた端末が他の端末と衝突すれば、衝突した端末はそれぞれ新しい乱数を割り当てられて更にバックオフ手順を行う。一実施例によると、各端末に新しく割り当てられる乱数は、該当端末が以前割り当てられた乱数の範囲(競合ウィンドウ、CW)の2倍の範囲(2*CW)内で決定される。一方、各端末は、次の競合ウィンドウ区間で更にバックオフ手順を行ってアクセスを試みるが、この際、各端末は以前の競合ウィンドウ区間に残ったスロットタイムからバックオフ手順を行う。このような方法で無線LAN通信を行う各端末は、特定チャネルに対する互いの衝突を回避することができる。
以下、本発明において、端末は、non-AP STA、AP STA、AP、STA、受信装置又は送信装置と呼ぶことができ、本発明がこれに限定されるものではない。また、本発明において、AP STAは、APと呼ぶことができる。
<様々なPPDUフォーマットの実施例>
図7には、様々な標準世代別PPDU(PLCP Protocol Data Unit)フォーマットの一例を示す。より具体的に、図7(a)は、802.11a/gに基づくレガシーPPDUフォーマットの一実施例、図7(b)は、802.11axに基づくHE PPDUフォーマットの一実施例を示し、図7(c)は、802.11beに基づくノン-レガシーPPDU(すなわち、EHT PPDU)フォーマットの一実施例を示す。また、図7(d)は、前記PPDUフォーマットで共通に用いられるL-SIG及びRL-SIGの細部フィールド構成を示す。
図7(a)を参照すると、レガシーPPDUのプリアンブルは、L-STF(Legacy Short Training field)、L-LTF(Legacy Long Training field)及びL-SIG(Legacy Signal field)を含む。本発明の実施例において、前記L-STF、L-LTF及びL-SIGは、レガシープリアンブルと呼ぶことができる。
図7(b)を参照すると、HE PPDUのプリアンブルは、前記レガシープリアンブルに、RL-SIG(Repeated Legacy Short Training field)、HE-SIG-A(High Efficiency Signal A field)、HE-SIG-B(High Efficiency Signal B field)、HE-STF(High Efficiency Short Training field)、HE-LTF(High Efficiency Long Training field)をさらに含む。本発明の実施例において、前記RL-SIG、HE-SIG-A、HE-SIG-B、HE-STF及びHE-LTFは、HEプリアンブルと呼ぶことができる。HEプリアンブルの具体的な構成は、HE PPDUフォーマットによって変形されてよい。例えば、HE-SIG-Bは、HE MU PPDUフォーマットのみにおいて用いられてよい。
図7(c)を参照すると、EHT PPDUのプリアンブルは、前記レガシープリアンブルに、RL-SIG(Repeated Legacy Short Training field)、U-SIG(Universal Signal field)、EHT-SIG-A(Extremely High Throughput Signal A field)、EHT-SIG-A(Extremely High Throughput Signal B field)、EHT-STF(Extremely High Throughput Short Training field)、EHT-LTF(Extremely High Throughput Long Training field)をさらに含む。本発明の実施例において、前記RL-SIG、EHT-SIG-A、EHT-SIG-B、EHT-STF及びEHT-LTFは、EHTプリアンブルと呼ぶことができる。ノン-レガシープリアンブルの具体的な構成は、EHT PPDUフォーマットによって変形されてよい。例えば、EHT-SIG-AとEHT-SIG-Bは、EHT PPDUフォーマットのうち一部のフォーマットのみにおいて用いられてよい。
PPDUのプリアンブルに含まれたL-SIGフィールドは、64 FFT OFDMが適用され、総64個のサブキャリアで構成される。このうち、ガードサブキャリア、DCサブキャリア及びパイロットサブキャリアを除く48個のサブキャリアが、L-SIGのデータ送信用に用いられる。L-SIGにはBPSK、Rate=1/2のMCS(Modulation and Coding Scheme)が適用されるので、総24ビットの情報を含むことができる。図7(d)には、L-SIGの24ビット情報構成を示す。
図7(d)を参照すると、L-SIG、は、L_RATEフィールドとL_LENGTHフィールドを含む。L_RATEフィールドは、4ビットで構成され、データ送信に用いられたMCSを示す。具体的に、L_RATEフィールドは、BPSK/QPSK/16-QAM/64-QAMなどの変調方式と1/2、2/3、3/4などの符号率を組み合わせた6/9/12/18/24/36/48/54Mbpsの送信速度のうち1つの値を示す。L_RATEフィールドとL_LENGTHフィールドの情報を組み合わせると当該PPDUの全長を示すことができる。ノン-レガシーPPDUフォーマットでは、L_RATEフィールドを最小速度である6Mbpsに設定する。
L_LENGTHフィールドの単位はバイトであり、総12ビットが割り当てられて最大4095までシグナルでき、L_RATEフィールドとの組合せで該当PPDUの長さを示すことができる。このとき、レガシー端末とノンレガシー端末はL_LENGTHフィールドを別個の方法で解釈することができる。
まず、レガシー端末又はノンレガシー端末がL_LENGTHフィールドを用いて該当PPDUの長さを解釈する方法は次の通りである。L_RATEフィールドの値が6Mbpsを指示するように設定された場合に、64FFTの1個のシンボルデュレーションである4usの間に3バイト(すなわち、24ビット)が送信されてよい。したがって、L_LENGTHフィールド値に、SVCフィールド及びTailフィールドに該当する3バイトを足し、これを1個のシンボルの送信量である3バイトで割ると、L-SIG以後の64FFT基準シンボル個数が取得される。取得されたシンボル個数に1個のシンボルデュレーションである4usをかけた後に、L-STF、L-LTF及びL-SIGの送信にかかる20usを足すと、該当PPDUの長さ、すなわち、受信時間(RXTIME)が得られる。これを数式で表現すれば、下記の式1の通りである。
このとき、
は、xより大きい又は等しい最小の自然数を表す。L_LENGTHフィールドの最大値は4095であるので、PPDUの長さは、最大5.484msまでに設定されてよい。当該PPDUを送信するノン-レガシー端末は、L_LENGTHフィールドを下記の式2のように設定しなければならない。
ここで、TXTIMEは、当該PPDUを構成する全体送信時間であり、下記の式3の通りである。このとき、TXは、Xの送信時間を表す。
以上の式を参照すると、PPDUの長さは、L_LENGTH/3の切上げ値に基づいて計算される。したがって、任意のk値に対してL_LENGTH={3k+1,3k+2,3(k+1)}の3つの異なる値が、同一のPPDU長を指示する。
図7(e)を参照すると、U-SIG(Universal SIG)フィールドは、EHT PPDU及び後続世代の無線LANのPPDUにおいて存続し、11beを含めてどの世代のPPDUであるかを区分する役割を担う。U-SIGは、64FFTベースのOFDMの2シンボルであり、総52ビットの情報を伝達することができる。このうち、CRC/テール9ビットを除く43ビットは、大きく、VI(Version Independent)フィールドとVD(Version Dependent)フィールドに区分される。
VIビットは、現在のビット構成を後にも維持し続け、後続世代のPPDUが定義されても、現在の11be端末が、当該PPDUのVIフィールドから当該PPDUに関する情報を得ることができる。そのために、VIフィールドは、PHYバージョン、UL/DL、BSSカラー、TXOP、リザーブド(Reserved)フィールドで構成される。PHYバージョンフィールドは3ビットであり、11be及び後続世代の無線LAN標準を順次にバージョンで区分する役割を担う。11beは000bの値を有する。UL/DLフィールドは、当該PPDUが上りリンク/下りリンクPPDUのいずれであるかを区分する。BSSカラーは、11axで定義されたBSS別識別子を意味し、6ビット以上の値を有する。TXOPは、MACヘッダーで伝達されていた送信機会デュレーション(Transmit Opportunity Duration)を意味するが、PHYヘッダーに追加することにより、MPDUをデコードすることなく、当該PPDUが含まれたTXOPの長さを類推でき、7ビット以上の値を有する。
VDフィールドは、11beバージョンのPPDUにのみ有用なシグナリング情報としてPPDUフォーマット、BWのように、如何なるPPDUフォーマットにも共通に用いられるフィールド、及びPPDUフォーマット別に異なるように定義されるフィールドで構成されてよい。PPDUフォーマットは、EHT SU(Single User)、EHT MU(Multiple User)、EHT TB(Trigger-based)、EHT ER(Extended Range)PPDUなどを区分する区分子である。BWフィールドは、大きく、20、40、80、160(80+80)、320(160+160)MHzの5個の基本PPDU BWオプション(20*2の冪乗の形態で表現可能なBWを基本BWと呼ぶことができる。)と、プリアンブルパンクチャリング(Preamble Puncturing)によって構成される様々な残りのPPDU BWをシグナルする。また、320MHzでシグナルされた後、一部の80MHzがパンクチャーされた形態でシグナルされてよい。また、パンクチャーされて変形されたチャネル形態は、BWフィールドで直接シグナルされてもよく、或いはBWフィールドとBWフィールド以後に現れるフィールド(例えば、EHT-SIGフィールド内のフィールド)を共に用いてシグナルされてもよい。仮に、BWフィールドを3ビットとする場合に、総8個のBWシグナリングが可能なので、パンクチャリングモードは最大で3個をシグナルできる。仮にBWフィールドを4ビットとする場合に総16個のBWシグナリングが可能なので、パンクチャリングモードは最大で11個をシグナルできる。
BWフィールド以後に位置するフィールドは、PPDUの形態及びフォーマットによって異なり、MU PPDUとSU PPDUは同一のPPDUフォーマットでシグナルされてよく、EHT-SIGフィールドの前に、MU PPDUとSU PPDUを区別するためのフィールドが位置してよく、そのための追加のシグナリングが行われてよい。SU PPDUとMU PPDUは両方ともEHT-SIGフィールドを含んでいるが、SU PPDUで不要な一部のフィールドが圧縮(compression)されてよい。この時、圧縮が適用されたフィールドの情報は省略されるか、あるいはMU PPDUに含まれる本来フィールドのサイズよりも縮小したサイズを有してよい。例えば、SU PPDUの場合、EHT-SIGの共通フィールドが省略又は代替されるか、ユーザ特定フィールドが代替されるか、或いは1個に縮小するなど、異なる構成を有してよい。
又は、SU PPDUは、圧縮されたか否かを示す圧縮フィールドをさらに含むことができ、圧縮フィールドの値によって一部のフィールド(例えば、RAフィールドなど)が省略されてよい。
SU PPDUのEHT-SIGフィールドの一部が圧縮された場合に、圧縮されたフィールドに含まれる情報は、圧縮されていないフィールド(例えば、共通フィールドなど)で一緒にシグナルされてよい。MU PPDUの場合、複数ユーザの同時受信のためのPPDUフォーマットであるので、U-SIGフィールド以後にEHT-SIGフィールドが必須に送信される必要があり、シグナルされる情報の量が可変的であってよい。すなわち、複数個のMU PPDUが複数個のSTAに送信されるので、それぞれのSTAは、MU PPDUが送信されるRUの位置、それぞれのRUが割り当てられたSTA、及び送信されたMU PPDUが自分に送信されたか否かを認識しなければならない。したがって、APは、EHT-SIGフィールドに上のような情報を含めて送信しなければならない。そのために、U-SIGフィールドではEHT-SIGフィールドを効率的に送信するための情報をシグナルし、これは、EHT-SIGフィールドのシンボル数及び/又は変調方法であるMCSであってよい。EHT-SIGフィールドは、各ユーザに割り当てられたRUのサイズ及び位置情報を含むことができる。
SU PPDUである場合、STAに複数個のRUが割り当てられてよく、複数個のRUは連続又は不連続してよい。STAに割り当てられたRUが連続しない場合、STAは、中間にパンクチャーされたRUを認識してこそ、SU PPDUを効率的に受信することができる。したがって、APは、SU PPDUに、STAに割り当てられたRUのうちパンクチャーされたRUの情報(例えば、RUのパンクチャリングパターンなど)を含めて送信できる。すなわち、SU PPDUの場合、パンクチャリングモードが適用されたか否か及びパンクチャリングパターンをビットマップ形式などで示す情報を含むパンクチャリングモードフィールドがEHT-SIGフィールドに含まれてよく、パンクチャリングモードフィールドは、帯域幅内で現れる不連続するチャネルの形態をシグナルできる。
シグナルされる不連続チャネルの形態は制限的であり、BWフィールドの値と組み合わせてSU PPDUのBW及び不連続チャネル情報を示す。例えば、SU PPDUの場合、単一端末にのみ送信されるPPDUであるので、STAは、PPDUに含まれたBWフィールドから、自分に割り当てられた帯域幅が認識でき、PPDUに含まれたU-SIGフィールド又はEHT-SIGフィールドのパンクチャリングモードフィールドから、割り当てられた帯域幅のうちパンクチャーされたリソースが認識できる。この場合、端末は、パンクチャーされたリソースユニットの特定チャネルを除く残りのリソースユニットでPPDUを受信できる。このとき、STAに割り当てられた複数個のRUは、互いに異なる周波数帯域又はトーンで構成されてよい。
制限された形態の不連続チャネル形態のみがシグナルされる理由は、SU PPDUのシグナリングオーバーヘッドを減らすためである。パンクチャリングは、20MHzサブチャネル別に行われてよいので、80、160、320MHzのように20MHzサブチャネルを複数個有するBWに対してパンクチャリングを行うと、320MHzの場合、プライマリーチャネルを除く残りの20MHzサブチャネル15個の使用有無をそれぞれ表現して、不連続チャネル(端部20MHzのみがパンクチーされた形態も不連続と見なす場合)形態をシグナルしなければならない。このように単一ユーザ送信の不連続チャネル形態をシグナルするために15ビットを用いることは、シグナリング部分の低い送信速度を考慮したとき、過大なシグナリングオーバーヘッドとなり得る。
本発明は、SU PPDUの不連続チャネル形態をシグナルする手法を提案し、提案した手法によって決定された不連続チャネル形態を示す。また、SU PPDUの320MHz BW構成において主(Primary)160MHzと副(Secondary)160MHzのパンクチャリング形態をそれぞれシグナルする手法を提案する。
また、本発明の一実施例では、PPDUフォーマットフィールドにシグナルされたPPDUフォーマットにしたがって、プリアンブルパンクチャリングBW値が指示するPPDUの構成を異ならせる手法を提案する。BWフィールドの長さが4ビットである場合を仮定し、EHT SU PPDU又はTB PPDUである場合には、U-SIG以後に1シンボルのEHT-SIG-Aをさらにシグナルするか、EHT-SIG-Aを全くシグナルしなくてよいので、これを考慮してU-SIGのBWフィールドのみを用いて最大で11個のパンクチャリングモードを全てシグナルする必要がある。しかしながら、EHT MU PPDUの場合、U-SIG以後にEHT-SIG-Bをさらにシグナルするので、最大で11個のパンクチャリングモードをSU PPDUと異なる方法でシグナルしてよい。EHT ER PPDUの場合、BWフィールドを1ビットに設定し、20MHz又は10MHzの帯域を用いるPPDUであるかをシグナルすることができる。
図7(f)には、U-SIGのPPDUフォーマットフィールドでEHT MU PPDUと指示された場合に、VDフィールドのフォーマット特異的(Format-specific)フィールドの構成を示す。MU PPDUの場合、複数ユーザの同時受信のためのシグナリングフィールドであるSIG-Bが必須であり、U-SIG後に別途のSIG-A無しでSIG-Bが送信されてよい。そのために、U-SIGではSIG-Bをデコードするための情報をシグナルしなければならない。このようなフィールドは、SIG-B MCS、SIG-B DCM、SIG-Bシンボルの数(Number of SIG-B Symbols)、SIG-B圧縮(SIG-B Compression)、EHT-LTFシンボルの数(Number of EHT-LTF Symbols)フィールドなどである。
図8は、本発明の実施例に係る様々なEHT(Extremely High Throughput)PPDU(Physical Protocol Data Unit)フォーマット及びこれを指示するための方法の一例を示す。
図8を参照すると、PPDUは、プリアンブルとデータ部分で構成されてよく、一つのタイプであるEHT PPDUのフォーマットは、プリアンブルに含まれているU-SIGフィールドによって区別されてよい。具体的に、U-SIGフィールドに含まれているPPDUフォーマットフィールドに基づき、PPDUのフォーマットがEHT PPDUであるか否かが指示されてよい。
図8の(a)は、単一STAのためのEHT SU PPDUフォーマットの一例を示す。EHT SU PPDUは、APと単一STA間の単一ユーザ(Single User:SU)送信のために用いられるPPDUであり、U-SIGフィールド以後に追加のシグナリングのためのEHT-SIG-Aフィールドが位置してよい。
図8の(b)は、トリガーフレームに基づいて送信されるEHT PPDUであるEHTトリガーベース(Trigger-based)PPDUフォーマットの一例を示す。EHTトリガーベースPPDUは、トリガーフレームに基づいて送信されるEHT PPDUであり、トリガーフレームに対する応答のために用いられる上りリンクPPDUである。EHT PPDUは、EHT SU PPDUとは違い、U-SIGフィールド以後にEHT-SIG-Aフィールドが位置しない。
図8の(c)は、多重ユーザのためのEHT PPDUであるEHT MU PPDUフォーマットの一例を示す。EHT MU PPDUは、1つ以上のSTAにPPDUを送信するために用いられるPPDUである。EHT MU PPDUフォーマットは、U-SIGフィールド以後にHE-SIG-Bフィールドが位置してよい。
図8の(d)は、拡張された範囲にあるSTAとの単一ユーザ送信のために用いられるEHT ER SU PPDUフォーマットの一例を示す。EHT ER SU PPDUは、図8の(a)で説明したEHT SU PPDUよりも広い範囲のSTAとの単一ユーザ送信のために用いられてよく、時間軸上でU-SIGフィールドが反復して位置してよい。
図8の(c)で説明したEHT MU PPDUは、APが複数個のSTAに下りリンク送信のために用いることができる。このとき、EHT MU PPDUは、複数個のSTAがAPから送信されたPPDUを同時に受信できるようにスケジューリング情報を含むことができる。EHT MU PPDUは、EHT-SIG-Bのユーザ特定(user specific)フィールドを通じて送信されるPPDUの受信者及び/又は送信者のAID情報を、STAに伝達することができる。したがって、EHT MU PPDUを受信した複数個の端末は、受信したPPDUのプリアンブルに含まれたユーザ特定フィールドのAID情報に基づいて空間再使用(spatial reuse)動作を行うことができる。
具体的に、HE MU PPDUに含まれたHE-SIG-Bフィールドのリソースユニット割り当て(resource unit allocation,RA)フィールドは、周波数軸の特定帯域幅(例えば、20MHzなど)におけるリソースユニットの構成(例えば、リソースユニットの分割形態)に関する情報を含むことができる。すなわち、RAフィールドは、STAがPPDUを受信するために、HE MU PPDUの送信のための帯域幅で分割されたリソースユニットの構成を指示できる。分割された各リソースユニットに割り当て(又は、指定)されたSTAの情報は、EHT-SIG-Bのユーザ特定フィールドに含まれてSTAに送信されてよい。すなわち、ユーザ特定フィールドは、分割された各リソースユニットに対応する1つ以上のユーザフィールドを含むことができる。
例えば、分割された複数個のリソースユニットのうち、データ送信のために用いられる少なくとも1つのリソースユニットに対応するユーザフィールドは、受信者又は送信者のAIDを含むことができ、データ送信に用いられない残りのリソースユニットに対応するユーザフィールドは、既に設定されたヌル(Null)STA IDを含むことができる。
図8に示す2個以上のPPDUを、同一のPPDUフォーマットを示す値で指示することができる。すなわち、2個以上のPPDUを同一の値によって同一のPPDUフォーマットと指示することができる。例えば、EHT SU PPDUとEHT MU PPDUは、U-SIG PPDUフォーマットサブフィールドを用いて同一の値で指示することができる。このとき、EHT SU PPDUとEHT MU PPDUは、PPDUを受信するSTAの個数によって区別されてよい。例えば、1個のSTAのみが受信するPPDUは、EHT SU PPDUと識別されてよく、2個以上のSTAが受信するようにSTAの数が設定された場合に、EHT MU PPDUと識別されてよい。言い換えると、同一のサブフィールド値を用いて、図8に示す2個以上のPPDUフォーマットを指示することができる。
また、図8に示すフィールドのうち一部のフィールド又はフィールドの一部の情報は省略されてよく、このように一部のフィールド又はフィールドの一部の情報が省略される場合を圧縮モード(compression mode)又は圧縮されたモード(compressed mode)と定義できる。
図9は、本発明の一実施例に係る多重リンク(multi-link)装置を示す図である。
図9を参照すると、一つ以上のSTAがアフィリエート(affiliate)されているデバイス(device)の概念が定義されてよい。さらに他の実施例として、本発明の一実施例によれば、1個超過(すなわち、2個以上の)のSTAがアフィリエートされているデバイスが定義されてよい。このとき、装置は論理的な(logical)概念であってよい。したがって、このような概念の1個以上又は1個超過のSTAがアフィリエートされているデバイスは、多重リンクデバイス(multi-link device:MLD)、多重バンド(multi-band)デバイス又は多重リンク論理的エンティティ(multi-link logical entity:MLLE)と呼ぶことができる。
又は、上の概念のデバイスは、多重リンクエンティティ(multi-link entity:MLE)と呼ぶことができる。また、MLDは、一つのMAC SAP(medium access control service access point)をLLC(logical link control)まで有してよく、MLDは一つのMACデータサービス(MAC data service)を有してよい。
MLDに含まれたSTAは、一つ以上のリンク(link)又はチャネル(channel)で動作することが可能である。すなわち、MLDに含まれたSTAは、互いに異なる複数のチャネルで動作することが可能である。例えば、MLDに含まれたSTAは、2.4GHz、5GHz、6GHzの互いに異なる周波数帯域のチャネルを用いて動作することが可能である。これにより、MLDはチャネル接続(channel access)における利得を得、全体ネットワークの性能を上げることができる。既存の無線LANは単一リンク(single link)で動作したが、MLD動作は、複数個のリンクを用いてより多いチャネル接続機会を得るか、チャネルの状況を考慮して複数個のリンクでSTAが効率的に動作することが可能である。
また、MLDにアフィリエートされたSTAがAPである場合に、APがアフィリエートされたMLDはAP MLDであってよい。しかし、MLDにアフィリエートされたSTAがnon-AP STAである場合に、non-APがアフィリエートされたMLDはnon-AP MLDであってよい。
また、AP MLD(Multi-link Device)は、一つ以上の無線アクセスポイント(AP)を含む機器であってよく、上位層に一つのインタフェースを介して連結された機器であってよい。すなわち、AP MLDは、一つのインタフェースを介してLLC(Logical Link Control)層に連結されてよい。AP MLDに含まれた複数のAPは、MAC層での一部の機能を共有してよい。AP MLD内の各APは個別のリンクで動作してよい。STA MLDは、一つ以上のnon-AP STAを含む機器であってよく、一つのインタフェースを介して上位層に連結された機器であってよい。
すなわち、STA MLDは、一つのインタフェースを介してLLC層に連結されてよい。STA MLDに含まれた複数のSTAは、MAC層での一部の機能を共有してよい。また、STA MLDは、non-AP MLDと呼ぶことができる。このとき、前記AP MLD及びSTA MLDは、複数の個別リンクを用いて通信する多重リンク動作を行うことができる。すなわち、AP MLDが複数のAPを含んでいる場合に、各APは別個のリンクを構成し、STA MLDに含まれたそれぞれの端末と複数のリンクを用いたフレーム送受信動作を行うことができる。このとき、各リンクは2.4GHz、5GHz、又は6GHzの帯域で動作でき、各リンクでは帯域幅拡張動作を行うことができる。例えば、AP MLDが2.4GHz帯域で一つのリンク、5GHz帯域で2つのリンクを設定した場合に、2.4GHz帯域では帯域幅拡張方式を用いて40MHzの帯域幅でフレーム送信を行うことができ、5GHz帯域を用いるそれぞれのリンクでは不連続の帯域幅を用いて最大で320MHzの帯域幅でフレーム送信を行うことができる。
一方、前記AP MLD或いはSTA MLDは、機器内部の干渉の問題から、MLD内の一つの端末が送信動作を行う間には他の端末が受信動作を行えないことがある。このようにMLD内の一つのAP或いは端末が送信動作を行う途中に前記MLD内の他のAP或いは端末が受信する動作をSTR(Simultaneous Transmit and Receive)という。前記AP MLDは全てのリンクに対してSTR動作が可能である。又は、前記AP MLDの一部のリンクでSTR動作が不可能である。AP MLDにはSTR動作可能な端末MLDが接続されることもあり、一部又は全体のリンクに対してSTR動作が不可能なMLDが接続されることもある。また、AP MLDに含まれたAPには、MLDに所属していない端末(例えば、IEEE 802.11a/b/g/n/ac/ax端末)がさらに接続されていることもある。
AP MLDとSTA MLDは、図5で説明したスキャニング及び接続過程において多重リンク利用動作のための交渉過程を行うことができる。例えば、図5で説明したスキャニング過程において、AP MLDに含まれたAPは、ビーコンフレームに、多重リンク動作が利用可能であることを指示する指示子、利用可能なリンク個数、利用可能な複数個のリンク情報を含めて送信できる。又は、STA MLDに属している端末は、プローブ要請フレームに、多重リンク動作が利用可能であることを指示する指示子を含めて送信でき、AP MLDに属しているAPは、プローブ応答フレームに、多重リンク動作が利用可能であることを指示する指示子を含めることができる。このとき、APは、多重リンク動作時に利用可能なリンク個数、リンク情報などをさらに含めて送信できる。
前記スキャニング過程でAP MLDの多重リンク動作をするか否か、及び利用リンク情報を確認したSTA MLDは、AP MLDと接続過程を行うことができる。このとき、前記AP MLDとSTA MLDは多重リンク動作のための交渉過程を始めることができる。このとき、前記多重リンク動作のための交渉過程は、AP MLDに属したAPとSTA MLDに属した端末間の接続過程で行われてよい。すなわち、STA MLDに属した任意の端末(例えば、STA1)がAP MLDに属した任意のAP(例えば、AP1)に接続要請フレームを送りながら、端末の多重リンク動作が利用可能であることを指示する指示子及び多重リンク動作を行うことを要請する要請指示子を送ることができる。前記端末から接続要請フレームを受信したAPは、多重リンク動作を要請する指示子を確認でき、APが多重リンク動作可能である場合に多重リンク動作に用いるリンク情報及び各リンクで用いられるパラメータなどを含めて多重リンク動作を許容する接続応答フレームを当該端末に送信できる。前記多重リンク動作のためのパラメータは、用いられる各リンクの帯域、帯域幅拡張方向、TBTT(Target Beacon Transmission Time)、STR動作の有無、のうち一つ以上を含んでよい。前記接続要請フレーム及び応答フレームが交換されて多重リンク動作の利用が確認されたAP MLD及びSTA MLDは、当該接続過程の後に、AP MLDに含まれた複数のAP及びSTA MLDに含まれた複数の端末を介して複数のリンクでフレーム送信動作を行うことができる。
図9を参照すると、複数のSTAを含むMLDが存在してよく、MLDに含まれている複数のSTAは複数のリンクで動作してよい。図9で、APであるAP1、AP2、AP3を含むMLDをAP MLDと呼ぶことができ、non-AP STAであるnon-AP STA1、non-AP STA2、non-AP STA3を含むMLDをnon-AP MLDと呼ぶことができる。MLDに含まれているSTAは、リンク1(Link1)、リンク2(Link2)、リンク3(Link3)、又はリンク1~3のうち一部のリンクで動作できる。
本発明の実施例によれば、多重リンク動作は多重リンク設定(multi-link setup)動作を含んでよい。多重リンク設定動作は、単一リンク動作で行われるアソシエーション(association)に対応する動作であってよい。多重リンクでフレームを交換するためには多重リンク設定が先行される必要がある。多重リンク設定動作は、多重リンク設定要素(multi-link setup element)を用いて行われてよい。ここで、多重リンク設定要素は、多重リンクに関連した能力情報(capability information)を含んでよく、能力情報は、MLDに含まれたSTAが一つのリンクでフレームを受信すると同時にMLDに含まれた他のSTAが他のリンクでフレームを送信できるかに関する情報を含んでよい。すなわち、能力情報は、MLDに含まれたリンクを通じてSTA(non-AP STA及び/又はAP(又は、AP STA)が互いに異なる送信方向に同時にフレームを送信/受信できるかに関する情報を含んでよい。また、能力情報は、利用可能なリンク又は動作チャネル(operating channel)に関する情報をさらに含んでよい。多重リンク設定は、ピアSTA(peer STA)間の交渉(negotiation)によって設定されてよく、一つのリンクを通じて多重リンク動作が設定されてよい。
本発明の一実施例によれば、TIDとMLDのリンク間にマッピング関係が存在してよい。例えば、TIDとリンクがマップされる場合に、TIDは、マップされたリンクで送信されてよい。TIDとリンク間のマッピングは、送信方向ベース(directional-based)でなされてよい。例えば、MLD1とMLD2間の両方向の各方向に対してマッピングがなされてよい。また、TIDとリンク間のマッピングは基本(default)設定が存在してよい。例えば、TIDとリンク間のマッピングは基本的に、あるリンクに全てのTIDがマップされたことであってよい。
図10は、本発明の一実施例に係るTID-to-linkマッピング方法の一例を示す図である。
図10を参照すると、図9で説明したようにTIDとリンク間のマッピング関係が存在してよい。また、本発明において、TIDとリンク間のマッピング関係をTID-to-linkマッピング、TIDツーリンクマッピング、TIDマッピング、リンクマッピングなどと呼ぶことができる。TIDはトラフィック識別子(traffic identifier)であってよい。また、TIDは、QoS(quality of service)を支援するためにトラフィック、データなどを分類するID(identifier)であってよい。
また、TIDは、MAC層よりも上位層で用いられたり、割り当てられたりするIDであってよい。TIDは、TC(traffic categories)、TS(traffic streams)を示すことが可能である。また、TIDは、16個の値が可能であり、例えば、0から15までの値で示されてよい。また、接続政策(access policy)又はチャネル接続、媒体接続(medium access)方法によって個別のTID値を用いることが可能である。例えば、EDCA(HCF(hybrid coordination function)連結ベースのチャネル接続、拡張型分散チャネル接続)を用いる場合に可能なTID値は0~7であってよい。また、EDCAを用いる場合に、TID値はUP(user priority)を示すものであってよく、前記UPはTC又はTSに関するものであってよい。また、UPは、MACよりも上位層に割り当てられる値であってよい。また、HCCA(HCF controlled channel access)又はSPCAを用いる場合に可能なTID値は8~15であってよい。また、HCCA又はSPCAを用いる場合にTIDはTSIDを示すものであってよい。また、HEMM又はSEMMを用いる場合に可能なTID値は8~15であってよい。また、HEMM又はSEMMを用いる場合にTIDはTSIDを示すものであってよい。
また、UPと接続カテゴリー(access category:AC)間のマッピング関係が存在してよい。ACは、EDCAにおいてQoSを提供するためのラベル(label)又はEDCAパラメータのセットを指示するラベルであってよい。EDCAパラメータ又はEDCAパラメータのセットは、チャネル連結に用いられるものであってよい。ACは、QoS STAで用いられてよい。
ACの値はAC_BK、AC_BE、AC_VI、AC_VOのうち一つに設定されてよい。AC_BK、AC_BE、AC_VI、AC_VOはそれぞれ、background、best effort、video、voiceを示すものであってよい。また、AC_BK、AC_BE、AC_VI、AC_VOを細分化することが可能である。例えば、AC_VIがAC_VI primaryとAC_VI alternateに細分化されてよい。また、AC_VOがAC_VO primaryとAC_VO alternateに細分化されてよい。また、UP値又はTID値はAC値とマップされてよい。例えば、UP値又はTID値1、2、0、3、4、5、6、7はそれぞれ、AC_BK、AC_BK、AC_BE、AC_BE、AC_VI、AC_VI、AC_VO、AC_VOとマップされてよい。又は、UP値又はTID値1、2、0、3、4、5、6、7はそれぞれ、AC_BK、AC_BK、AC_BE、AC_BE、AC_VI alternate、AC_VI primary、AC_VO primary、AC_VO alternateとマップされてよい。また、UP値又はTID値1、2、0、3、4、5、6、7は順に優先度(priority)が高いものであってよい。すなわち、1の方が低い優先度であり、7の方が高い優先度であってよい。したがって、AC_BK、AC_BE、AC_VI、AC_VOの順に優先度が高くなるものであってよい。また、AC_BK、AC_BE、AC_VI、AC_VOはそれぞれ、ACI(AC index)0、1、2、3に該当してよい。
したがって、TIDとAC間の関係が存在することが可能である。したがって、本発明のTID-to-linkマッピングは、ACとリンク間のマッピング関係であってもよい。また、本発明において、TIDがマップされたということは、ACがマップされたことであってもよく、その逆であってもよい。
本発明の一実施例によれば、multi-linkの各リンクにマップされたTIDが存在してよい。例えば、特定TID又は特定ACが複数のリンクのうちいずれのリンクで送信、受信が許容されるかに対するマッピングが存在してよい。また、このようなマッピングは、リンクの両方向の各方向に対して個別に定義されてよい。また、前述したように、TIDとリンク間のマッピングは、基本(default)設定が存在してよい。例えば、TIDとリンク間のマッピングは基本的に、あるリンクに全てのTIDがマップされてよい。また、一実施例によれば、特定時点に、あるTID又はあるACは少なくとも一つのリンクとはマップされていてよい。また、マネジメントフレーム(management frame)又は制御フレーム(control frame)は、全てのリンクで送信されてよい。
本発明において、リンクのいずれかの方向に対してマップされたTID又はACに該当するデータフレームが送信されてよい。また、リンクのいずれかの方向に対してマップされていないTID又はACに該当するデータフレームは送信されなくてよい。
一実施例によればTID-to-linkマッピングがacknowledgmentにも適用されてよい。例えば、block ack agreementがTID-to-linkマッピングに基づき得る。又は、TID-to-linkマッピングはblock ack agreementに基づき得る。例えば、TID-to-linkマップされたTIDに対してblock ack agreementが存在することが可能である。
TID-to-linkマッピングをすることによってQoSサービスを提供することが可能である。例えば、チャネル状態が良い或いはSTAが少ないリンクに、優先度の高いAC、TIDをマップすることによって、当該AC、TIDのデータを迅速に送信することが可能である。又は、TID-to-linkマッピングをすることにより、特定リンクのSTAが節電(power save)できるように(又は、doze状態に入るように)助けることができる。
図10を参照すると、AP1とAP2を含むAP MLDが存在してよい。また、STA1とSTA2を含むNon-AP MLDが存在してよい。また、前記AP MLDに複数のリンクであるLink1とLink2が存在してよい。AP1とSTA1はLink1でアソシエーションされ、AP2とSTA2はLink2でアソシエーションされてよい。
したがって、Link1は、AP1からSTA1へと送信するリンク及び/又はSTA1からAP1へと送信するリンクを含んでよく、Link2は、AP2からSTA2へと送信するリンク及び/又はSTA2からAP2へと送信するリンクを含んでよい。このとき、それぞれのリンクはTID及び/又はACがマップされていてよい。
例えば、Link1でAP1からSTA1に送信するリンク、Link1でSTA1からAP1に送信するリンクには全てのTID、全てのACがマップされていてよい。また、Link2でSTA2からAP2に送信するリンクには、AC_VO又はAC_VOに該当するTIDのみがマップされていてよい。また、マップされたTID及び/又はACのデータのみが当該リンクで送信されることが可能である。また、リンクにマップされていないTID又はACのデータは当該リンクで送信されることが不可能である。
図11は、本発明の一実施例に係るmulti-link NAV設定動作の一例を示す図である。
MLDが同時に送信又は受信する動作(STR;simultaneous transmit and receive;simultaneous transmission and reception)は制限的であってよく、これは、多重リンク(multi-link)で動作する複数のリンク間の周波数間隔と関連していてよい。
したがって、本発明の実施例によれば、リンク間の間隔がm MHzであるとき、同時に送信又は受信することが制限的であり、mよりも大きいnに対してリンク間の間隔がn MHzであるとき、同時に送信又は受信することが制限的でなくてよい。本実施例は、同時に送信又は受信することが制限的である問題を解決するためのものであってよく、重複説明は省略されてよい。また、本実施例をSTR不可なMLDに対して適用することが可能である。
本発明の一実施例によれば、多重リンクとして動作するリンク間に期間情報(duration information)が共有されてよい。一実施例として、前記期間情報は、プリアンブルのシグナリングフィールドで送信されるTXOP duration情報であってよい。前記シグナリングフィールドは、前述したU-SIGフィールドであってよい。又は、前記シグナリングフィールドは、前述したHE-SIG-Aフィールドであってよい。さらに他の実施例として、前記期間情報は、MAC headerが含むDuration/IDフィールドが指示する期間情報であってよい。さらに他の実施例として、前記期間情報は、L-SIGフィールドが含むLengthフィールド(L Length field)が指示する期間情報であってよい。一実施例によれば、U-SIGフィールド又はHE-SIG-A又はDuration/IDフィールドが指示する期間情報は、TXOP durationを指示する値であってよい。一実施例によれば、L-SIGフィールドが指示する期間情報は、前記L-SIGフィールドを含むPPDU(physical layer protocol data unit)の長さ又は前記L-SIGフィールドを含むPPDUの終わりを指示する値であってよい。
また、本発明の実施例によれば、リンク間に共有された期間情報に基づく期間に送信又はチャネル接続を行うことを制限することができる。送信又はチャネル接続を制限する方法は、NAVを設定することを含んでよい。又は、送信又はチャネル接続を再開するためにNAVをリセットすることができる。このとき、NAVはintra-BSS NAVであってよい。Intra-BSS NAVは、intra-BSSフレーム(又は、PPDU)によって設定されるNAVであってよい。すなわち、MLDに属したSTAは、前記MLDに属した他のSTAに向かうフレーム(又は、PPDU)に基づいてNAVを設定することができる。
本発明の一実施例によれば、inter-link NAVが存在してよい。Inter-link NAVは、多重リンクで動作する場合に、あるMLDに属した複数のリンクのSTAが用いるNAVであってよい。例えば、リンク1で受信した期間情報に基づいて設定したinter-link NAVに基づいてリンク2で送信をしなくてよい。また、inter-link NAVは、STR不可なMLDに対して存在又は利用することが可能である。例えば、inter-link NAVが設定された場合に、当該inter-link NAVを設定したMLDは、複数のリンク(又は、MLDが用いる全てのリンク)で送信又はチャネル接続をしなくてよい。
また、NAVの種類としてintra-BSS NAVの他にbasic NAVが存在してよい。Basic NAVは、inter-BSSフレーム(又は、PPDU)によって設定されるNAVであってよく、intra-BSSかinter-BSSかが判断されないフレーム(又は、PPDU)によってもbasic NAVが設定されてよい。
Inter-link NAVを別に用いる場合に、inter-link NAVを用いない場合に比べて、NAV設定がアップデートされる状況において長所を有し得る。例えば、他のリンクによって設定したNAVをリセットしても構わない状況が発生し得る。例えば、あるフレーム(又は、PPDU)に基づいてinter-link NAVを設定したが、前記フレーム(又は、PPDU)が同一MLDに向かうものでないと判断され、設定したinter-link NAVをリセットしても構わないことがある。仮に、リンク1とリンク2で動作するMLDが存在するとき、リンク1に対するNAVが、リンク1で受信したフレームに基づいて設定されていてよい。その後、リンク2のフレームに基づいてリンク1のNAVをアップデートしてよい。そして、リンク2によるNAVは維持する必要がなくなったとき、リンク1のNAVをリセットすれば、リンク1で受信したフレームに基づいて設定したNAV情報を失う不具合がある。仮にinter-link NAVを各リンクに対するNAVと共に用いれば、inter-link NAVをリセットしても各リンクに対するNAVが維持され、上記の不具合を解決することができる。
本発明の実施例においてNAVを設定することを取り上げたが、本発明の実施例は、これに限定されず、物理層にチャネル接続を中断するように指示するか、チャネル状態をbusyと指示することにも適用可能である。また、NAVをリセットすることに限定されず、物理層にチャネル接続を続けるように指示したり、チャネル状態をidleと指示したりすることにも適用可能である。このとき、物理層とMAC層間に授受するprimitiveが用いられてよい。又は、MLDの一つのSTAと他のSTA間に授受するprimitiveが用いられてよい。又は、MLDの一つのMAC層と他のMAC層間に授受するprimitiveが用いられてよい。
本発明の実施例によれば、MLDに属したSTAがPPDU受信を始めると、前記MLDに属した他のSTAはチャネル接続を止めなければならないことがある。前述したように、受信した期間情報に基づいてチャネル接続を止めてよいが、期間情報を含むフィールドの位置のため又はデコーディングなどにかかる時間のため、PPDUを受信し始めた時点から期間情報を得るまで時間が存在し得る。このため、この時間においてチャネルにアクセスして送信を始めると前述の問題につながり得る。このため、本発明の一実施例によれば、MLDのSTAは、前記MLDの他のSTAが受信を始めた時点からチャネル接続を中断することができる。また、前記MLDの他のSTAが受信を始めた後に受信したフレームが前記他のSTAに向かうものでないことを確認した場合にチャネル接続を再び始めることがてきる。
図12は、本発明の一実施例に係るmulti-link NAV設定動作のさらに他の例を示す図である。
図12は、図11で説明した実施例の具体的な方法に関する説明を具体化したものであり、重複説明は省略されてよい。
前述したように、MLDに属したあるSTAが受信するフレーム又はPPDUに基づいて、同一MLDに属した他のSTAがチャネル接続又は送信を中止又は再開することができる。本発明において、チャネル接続又は送信を中止することは、NAVを設定する(アップデートする)、チャネルをbusyと判断する、又はCCAを中止するなどの動作を含んでよい。また、チャネル接続又は送信を再開することは、NAVをリセットする、NAV設定を取消(cancel)する、チャネルをidleと判断する、又はCCAを行うなどの動作を含んでよい。以下では、このような動作を、チャネル接続を中止し再開することとして指示できる。また、以下、MLDにSTA1とSTA2が属しており、STA1とSTA2はそれぞれLink1とLink2で動作するとして説明できる。また、フレームとPPDUを相互互換的に指示できる。また、この時のNAVは、図11で説明したようにintra-BSS NAV又はinter-link NAVであってよい。
本発明の実施例によれば、STA1がフレーム受信し始めると、STA2はチャネル接続を中断してよい。また、STA1がL-SIGから期間情報(duration information)を取得したとき、STA2はチャネル接続を中断した状態を持続してよい。この時、STA2がチャネル接続を中断した状態を、STA1が受信したフレームの終わりまでと決定できる。また、STA1がL-SIGを確かにデコードできなかった場合(invalid L-SIGである場合)に、STA2はチャネル接続を再開できる。
また、STA1が受信するフレームのU-SIGからTXOP durationとBSS colorを受信することができる。仮に、受信したBSS colorがintra-BSSであることを示すか、BSS colorがSTA1に該当するBSS colorである場合に、チャネル接続を中断できる。一実施例として、この時にチャネル接続を中断する期間は、受信したフレームの終わりまでであってよい。この場合、受信したフレームが終わった後、より早くチャネル接続を開始できる長所がある。他の実施例として、この時にチャネル接続を中断する期間はTXOP durationであってよい。この場合、L-SIGに基づいて中断したチャネル接続の期間はアップデートされてよい。この場合、受信するフレームに続くシーケンス(sequence)をよりよく保護できる長所がある。
又は、STA1が受信するフレームのU-SIGからTXOP durationとBSS colorを受信したし、受信したBSS colorがintra-BSSでないことを示すか、BSS colorがSTA1に該当するBSS colorでない場合があり得る。又は、STA1がU-SIGを成功的にデコードできなかった場合があり得る。このような場合、STA2はチャネル接続を再開できる。
又は、STA1が受信するフレームのU-SIGから取得した情報が、当該フレームがSTA1が受信しないフレームであることを指示する場合に、STA2はチャネル接続を再開できる。例えば、U-SIGから取得したPHY identifierが、将来の標準に該当するID又は認識できないIDである場合に、STA2はチャネル接続を再開できる。
また、U-SIGを受信する場合を説明したが、同実施例を、HE PPDUを受信するとき、HE-SIG-Aを受信する場合にも適用できる。例えば、HE-SIG-AはTXOP durationとBSS colorを含んでよく、よって、前述したような動作を行うことができる。
また、STA1が受信するフレームのEHT-SIGからSTA-IDを受信していることがある。仮に、受信したSTA-IDがSTA1の受信するべき指示子であれば、例えば、STA-IDがSTA1を示す、STA-IDがSTA1の属したグループを示す、又はSTA-IDがbroadcastを示す場合に、STA2はチャネル接続を中断した状態を持続できる。
又は、STA1が受信するフレームのEHT-SIGからSTA-IDを受信していることがある。仮に、受信したSTA-IDがSTA1に該当しない指示子であれば、例えば、STA-IDがSTA1に該当する指示子を示さない、STA-IDがSTA1の属したグループを示さない、又はSTA-IDがbroadcastを示さない場合に、STA2はチャネル接続を再開できる。又は、STA1がEHT-SIGを成功的にデコードできなかった場合にもSTA2はチャネル接続を再開できる。
また、EHT-SIGを受信する場合を説明したが、同実施例を、HE PPDUを受信するとき、HE-SIG-Bを受信する場合にも適用できる。例えば、HE-SIG-BはSTA-IDを含んでよく、よって、前述したような動作を行うことができる。
また、STA1が受信するフレームのMAC headerを受信していることがある。仮に、受信したMAC headerが含むRA(receiver address)又はDA(destination address)がSTA1の受信するべき値を示す場合に、例えば、RA又はDAがSTA1を示す、STA1の属したグループを示す、又はSTA-IDがbroadcastを示す場合に、STA2はチャネル接続を中断した状態を持続できる。この時、中断するチャネルアクセスの期間は、受信したMAC headerが含む期間情報に基づき得る。より具体的には、中断するチャネルアクセスの期間は、受信したMAC headerが含むDuration/IDフィールドが指示する期間情報に基づき得る。
また、STA1が受信するフレームのMAC headerを受信していることがある。仮に、受信したMAC headerが含むRA又はDAが、STA1に該当しない指示子である場合に、例えば、RA又はDAがSTA1に該当する指示子を示さない、STA1の属したグループを示さない、又はbroadcastを示さない場合に、STA2はチャネル接続を再開できる。又は、STA1が全てのMAC headerを受信していないことがある。例えば、STA1がA-MPDUに含まれた全てのMPDUを受信失敗することがある。この場合、STA2はチャネル接続を再開できる。
図12で説明したチャネル接続中断と再開は、STA1でフレーム(又は、PPDU)を受信し始めて順次にデコードして行くにつれてデコードされる順に動作してよい。デコードされる順序は、PPDUフォーマット、フレームフォーマットなどに基づき得る。例えば、L-SIG、U-SIG、EHT-SIG、MAC headerの順にデコードできる(EHT PPDUの場合)。又は、L-SIG、HE-SIG-A、MAC headerの順にデコードできる(HE SU PPDU、HE TB PPDUの場合)。又は、L-SIG、HE-SIG-A、HE-SIG-B、MAC headerの順にデコードできる(HE MU PPDUの場合)。又は、L-SIG、MAC headerの順にデコードできる(11a/g PPDUの場合)。
本発明の実施例によれば、先に言及したSTA-IDは、PPDU又はRU(resource unit)の意図した受信者を指示する値であってよい。また、STA-IDは、EHT-SIGフィールド又はHE-SIG-Bフィールドなどに含まれてよい。また、STA-IDは、単一STAに該当する値を示すことが可能である。例えば、複数のSTAがMLDに含まれるとき、STA-IDは前記複数のSTAのうち一つのSTAに該当する値を示すことが可能である。また、STA-IDは、STAのAID又はMAC addressに基づく値であってよい。
図13は、本発明の一実施例に係るBSS分類及びそれに基づく動作の一例を示す図である。
本発明の一実施例によれば、STAは、受信したフレーム又は受信したPPDUに基づいてBSSを分類(classify)(又は、判断)することが可能である。BSSを分類することは、受信したフレーム又は受信したPPDUが、分類するSTAの属したBSSに該当するか否かを分類する動作を含んでよい。又は、BSSを分類することは、受信したフレーム又は受信したPPDUが、分類するSTAの属したBSSから送信されたか否かを分類する動作を意味できる。また、BSSを分類することは、受信したフレーム又は受信したPPDUが、分類するSTAの属していないBSSに該当するか否かを分類する動作を含んでよい。又は、BSSを分類することは、受信したフレーム又は受信したPPDUが、分類するSTAの属していないBSSから送信されたか否かを分類する動作を意味できる。また、BSSを分類することは、受信したフレーム又は受信したPPDUがどのBSSに属したかを分類する動作を含んでよい。又は、BSSを分類することは、受信したフレーム又は受信したPPDUがどのBSSから送信されたかを分類する動作を意味できる。本発明の一実施例によれば、分類するSTAの属したBSSをintra-BSSと呼ぶことができる。又は、分類するSTAの属したBSSを含むBSSをintra-BSSと呼ぶことができる。また、intra-BSSでないBSSをinter-BSSと呼ぶことができる。又は、intra-BSSでないBSSはinter-BSSであるか又は分類されないBSSであってよい。又は、inter-BSSは、分類されないBSSを含んでよい。また、分類するSTAが属していないBSSをinter-BSSと呼ぶことができる。
一実施例によれば、受信したフレーム又は受信したPPDUがintra-BSSに該当したり又はintra-BSSから送信されたと判断されたりした場合に、前記受信したフレーム又は前記受信したPPDUをそれぞれintra-BSSフレーム、intra-BSS PPDUということができる。また、受信したフレーム又は受信したPPDUがinter-BSSに該当したり又はinter-BSSから送信されたと判断されたりした場合に、前記受信したフレーム又は前記受信したPPDUをそれぞれinter-BSSフレーム、inter-BSS PPDUということができる。また、intra-BSSフレームを含むPPDUはintra-BSS PPDUであってよい。また、inter-BSSフレームを含むPPDUはinter-BSS PPDUであってよい。
本発明の一実施例によれば、一つ以上のBSS分類条件に基づいてBSSを分類できる。例えば、前記一つ以上のBSS分類条件のうち少なくとも一つの条件を満たすか否かによってBSSを分類できる。
前記BSS分類条件は、BSS colorに基づく条件を含んでよい。BSS colorは、BSSに対する識別子(identifier)であってよい。また、BSS colorは、PPDUのプリアンブル(preamble)、より具体的にはsignalingフィールド(例えば、HE-SIG-Aフィールド又はU-SIGフィールド又はVHT-SIG-Aフィールド)に含まれてよい。また、BSS colorは、送信者のMAC層からPHY層へ伝達されるTXVECTORに含まれてよい。また、BSS colorは、受信者のPHY層からMAC層に伝達されるRXVECTORに含まれてよい。TXVECTOR、RXVECTORに含まれるパラメータをそれぞれ、TXVECTORパラメータ、RXVECTORパラメータと呼ぶことができる。また、BSS colorは、TXVECTORパラメータ又はRXVECTORパラメータに含まれてよい。また、APが設定したBSS colorをSTAに知らせることができる。一実施例によれば、受信したPPDUに含まれたBSS colorに基づいてBSSを分類できる。仮に、STAの受信したPPDUに含まれたBSS colorが、STAに該当するBSSのBSS colorと異なる場合に、前記受信したPPDUをinter-BSS PPDUに分類できる。又は、仮に、STAの受信したPPDUに含まれたBSS colorが、STAに該当するBSSのBSS colorと異なり、その値が0でない場合に、前記受信したPPDUをinter-BSS PPDUに分類できる。また、仮に、STAの受信したPPDUに含まれたBSS colorが、STAに該当するBSSのBSS colorと同一である場合に、前記受信したPPDUをintra-BSS PPDUに分類できる。
前記BSS分類条件はMAC addressに基づく条件を含んでよい。MAC addressは、フレームのMAC headerに含まれてよい。また、MAC addressは、RA(receiver address)、TA(transmitter address)、BSSID、SA(source address)、DA(destination address)などを含んでよい。一実施例によれば、受信したフレームに含まれたMAC addressに基づいてBSSを分類できる。仮に、受信したフレームに含まれたMAC addressが、STAに該当するBSSのBSSIDと異なる場合に、前記受信したフレームをinter-BSSフレームに分類できる。より具体的には、仮に受信したフレームに含まれたMAC addressがいずれも、STAに該当するBSSのBSSIDと異なる場合に、前記受信したフレームをinter-BSSフレームに分類できる。また、仮に、受信したフレームに含まれたMAC addressが、STAに該当するBSSのBSSIDと同一である場合に、前記受信したフレームをintra-BSSフレームに分類できる。より具体的には、仮に、受信したフレームに含まれたMAC addressのうち少なくとも一つがSTAに該当するBSSのBSSIDと同一である場合に、前記受信したフレームをintra-BSSフレームに分類できる。
前記該当するBSSは、STAがアソシエーションされたBSSを含んでよい。また、前記該当するBSSは、STAがアソシエーションされたBSSと同じmultiple BSSID setに含まれたBSSを含んでよい。また、前記該当するBSSは、STAがアソシエーションされたBSSと同じco-hosted BSSID setに含まれたBSSを含んでよい。また、同じmultiple BSSID set又は同じco-hosted BSSID setに含まれた一つ以上のBSSは、一つのフレームを通じて前記一つ以上のBSSに関する情報が伝達されてよい。
前記BSS分類条件は、VHT PPDUに含まれたPartial AIDフィールド値に基づく条件を含んでよい。Partial AIDフィールドは、VHT PPDUのプリアンブルに含まれてよい。また、Partial AIDフィールドは、VHT PPDUに含まれたVHT-SIG-Aフィールドに含まれてよい。一実施例によれば、Partial AIDフィールドは、BSS colorの一部を示すことが可能である。例えば、partial BSS color機能を用いる場合に、Partial AIDフィールドは、BSS colorの一部を示すことが可能である。又は、AID割り当て規定(AID assignment rule)を用いる場合に、Partial AIDフィールドは、BSS colorの一部を示すことが可能である。AID割り当て規定は、BSS colorに基づくAIDを割り当てる方法であってよい。またVHT PPDUのVHT-SIG-Aフィールドに含まれたGroup IDフィールドが既に設定された値である場合(例えば、Group IDフィールドが63に設定された場合)に、Partial AIDフィールドは、BSS colorの一部を示すことが可能である。一実施例によれば、受信したPPDUのPartial AIDフィールドがBSS colorの一部を示す場合に、受信したPartial AIDフィールド値が受信したSTAに該当するBSS colorの一部と異なると、前記受信したPPDUをinter-BSS PPDUに分類できる。
また、受信したPPDUのPartial AIDフィールドがBSS colorの一部を示す場合に、受信したPartial AIDフィールド値が、受信したSTAに該当するBSS colorの一部と同一であれば、前記受信したPPDUをintra-BSS PPDUに分類できる。また、このとき、BSS colorの一部は、BSS colorの4LSBsであることが可能である。さらに他の実施例によれば、Partial AIDフィールドはBSSIDの一部を示すことが可能である。例えば、VHT PPDUのVHT-SIG-Aフィールドに含まれたGroup IDフィールドが既に設定された値である場合(例えば、Group IDフィールドが0に設定された場合)に、Partial AIDフィールドはBSSIDの一部を示すことが可能である。一実施例によれば、受信したPPDUのPartial AIDフィールドがBSSIDの一部を示す場合に、受信したPartial AIDフィールド値が、受信したSTAに該当するBSSIDの一部と異なると、前記受信したPPDUをinter-BSS PPDUに分類できる。また、受信したPPDUのPartial AIDフィールドがBSSIDの一部を示す場合に、受信したPartial AIDフィールド値が、受信したSTAに該当するBSSIDの一部と同一であれば、前記受信したPPDUをintra-BSS PPDUに分類できる。また、このとき、BSSIDの一部はBSSIDの9MSBsであることが可能である。また、Partial AIDフィールド値は、TXVECTORパラメータPARTIAL_AID又はRXVECTORパラメータPARTIAL_AIDに含まれてよい。また、Group IDフィールド値は、TXVECTORパラメータGROUP_ID又はRXVECTORパラメータGROUP_IDに含まれてよい。
前記BSS分類条件は、APが、既に設定された条件のPPDUを受信する条件を含んでよい。例えば、前記既に設定された条件のPPDUは、下りリンクPPDUを含んでよい。一実施例によれば、下りリンクPPDUは、VHT MU PPDUを含んでよい。また、下りリンクPPDUは、上りリンクか又は下りリンクかを指示するシグナリングが、既に設定された値に設定されたPPDUを含んでよい。上りリンクか又は下りリンクかを指示するシグナリングは、HE PPDUのsignalingフィールドに含まれてよい。又は、上りリンクか又は下りリンクかを指示するシグナリングはU-SIGに含まれてよい。U-SIGは、EHT PPDU又はEHT標準以後のPPDUのプリアンブルに含まれてよい。
また、intra-BSS PPDU又はinter-BSS PPDUに分類できない場合が存在し得る。例えば、前述したintra-BSS PPDUに分類する条件とinter-BSS PPDUに分類する条件をいずれも満たせない場合に、intra-BSS PPDU又はinter-BSS PPDUに分類できない。
また、BSSを分類するとき、複数の条件による分類結果が一致しないと、既に設定された条件によって最終結果を決定することが可能である。例えば、BSS colorに基づく条件による結果とMAC addressに基づく条件による結果とが一致しない場合に、MAC addressに基づく条件による結果が優先するか、又はMAC addressに基づく条件による結果を最終結果として決定できる。又は、intra-BSS PPDUに分類する条件とinter-BSS PPDUに分類する条件を両方とも満たす場合に、intra-BSS PPDUに分類できる。
本発明の一実施例によれば、STAは、分類したBSSに基づく動作を行うことができる。分類したBSSに基づく動作は、intra-PPDU節電(power save)動作を含んでよい。intra-PPDU節電動作は、受信したPPDUに基づく節電動作であってよい。既に設定された条件を満たす場合に、intra-PPDU節電動作を行うことが可能である。前記既に設定された条件は、受信したPPDUをintra-BSS PPDUに分類する条件を含んでよい。また、前記既に設定された条件は、受信したPPDUの意図した受信者(intended receiver)が前記PPDUを受信したSTAでない条件を含んでよい。例えば、PPDUに含まれたID又はaddressが前記PPDUを受信したSTAに該当しない場合に、前記PPDUの意図した受信者は、前記PPDUを受信したSTAでなくてよい。IDは、PPDUのプリアンブルに含まれてよい。例えば、IDは、PPDUのプリアンブルに含まれたSTA_IDであってよい。また、STA_IDは、HE MU PPDU又はEHT PPDUに含まれてよい。また、adderessは、前述したMAC addressであってよい。また、受信したPPDUに含まれた上りリンクか又は下りリンクかを指示するシグナリングが上りリンクを指示する場合に、前記PPDUの意図した受信者は、前記PPDUを受信したSTAでなくてよい。また、受信したPPDUの設定が、前記PPDUを受信したSTAが支援しないものに設定された場合に、前記PPDUの意図した受信者は、前記PPDUを受信したSTAでなくてよい。受信したPPDUの設定は、PPDUのMCS、空間ストリーム(spatial stream)個数、チャネル幅(channel width)などを含んでよい。また、受信したPPDUの設定を、前記PPDUを受信したSTAが支援しない場合に、PHY-RXEND.indication(UnsupportedRate)primitiveが受信されてよい。また、受信したPPDUが既に設定されたフォーマットである場合に、前記PPDUの意図した受信者は、前記PPDUを受信したSTAでなくてよい。前記既に設定されたフォーマットはTB PPDUを含んでよい。TB PPDUは、HE TB PPDU、EHT TB PPDUを含んでよい。また、TB PPDUは、トリガーするフレームによる応答として送信されるPPDUであってよい。トリガーするフレームは、トリガーフレームを含んでよい。トリガーするフレームは、トリガーする情報が含まれたフレームを含んでよい。トリガーする情報は、MAC header、例えば、A-controlフィールドに含まれてよい。また、トリガーする情報又はトリガーフレームに含まれた情報は、応答するPPDUの長さ、応答時に用いるRU、応答時に用いるPHY configuration、MAC configurationなどを含んでよい。intra-PPDU節電動作は、受信したPPDUの終わりまでdoze状態に入り得る動作であってよい。さらに他の実施例として、STAが受信したPPDU又はフレームの意図した受信者が前記STAでないと判断された場合に、PPDU又はフレームの受信又はデコーディングを中断できる。
分類したBSSに基づく動作は、NAVを設定(又は、アップデート)する動作を含んでよい。一実施例によれば、STAが一つ以上のNAVを運用することが可能である。また、STAがPPDU又はフレームを受信した場合に、受信したPPDU又は受信したフレームに基づいて分類したBSSに該当するNAVを設定することが可能である。例えばintra-BSS NAVは、intra-BSS PPDUに該当するNAVであってよい。また、basic NAVは、intra-BSS PPDUでないPPDUに該当するNAVであってよい。又は、basic NAVは、inter-BSS PPDUに該当するNAVであってよい。また、受信したPPDU又は受信したフレームに基づいてNAVを設定する時に、受信したPPDU又は受信したフレームに含まれたduration情報を用いることが可能である。前記duration情報は、TXOPを含んでよい。TXOPは、TXOPフィールドに含まれた値を意味できる。TXOPフィールドは、PPDUのプリアンブルに含まれてよい。例えば、TXOPフィールドは、HE PPDUのHE-SIG-Aフィールドに含まれてよい。又は、TXOPフィールドは、EHT PPDU又はEHT以後標準のPPDUのU-SIGフィールドに含まれてよい。また、前記duration情報は、MAC headerに含まれてよい。例えば、前記duration情報は、MAC headerに含まれたDuration/IDフィールドに含まれてよい。
分類したBSSに基づく動作は、空間再利用(spatial reuse)動作を含んでよい。また、分類したBSSに基づく動作は、チャネル接続動作を含んでよい。空間再利用動作はチャネル接続動作であってよい。STAがPPDU又はフレームを受信した時に、既に設定された条件を満たすと、空間再利用動作を行うことが可能である。既に設定された条件は、受信したPPDU又は受信したフレームがinter-BSSに該当する条件を含んでよい。また、既に設定された条件は、受信したPPDU又は受信したフレームの信号強度(signal strength)が閾値(threshold)よりも小さい条件を含んでよい。例えば、閾値は可変的であってよい。また、閾値は、OBSS PDベースの空間再利用(OBSS PD-based Spatial reuse)動作のための閾値であってよい。また、閾値は、CCA閾値以上の値であってよい。また、閾値は、送信しようとする電力(power)に基づく値であってよい。空間再利用動作は、PPDUを送信する動作を含んでよい。また、空間再利用動作は、PHYをリセットする動作を含んでよい。例えば、PHYをリセットする動作は、PHY-CCARESET.request primitiveを発行(issue)する動作であってよい。また、空間再利用動作は、受信したPPDU又は受信したフレームに基づいてNAVを設定しない動作を含んでよい。仮に、STAが空間再利用動作を行う場合に、受信したPPDU又は受信したフレームが送信又は受信される間に前記STAがPPDUを送信することが可能である。
図13を参照すると、BSS AとBSS Bが存在してよく、BSS AとBSS Bは互いに異なるBSSであってよい。また、BSS AとBSS Bは互いにinter-BSSに該当してよい。すなわち、BSS AにアソシエーションされたSTAがBSS Bで送信したPPDU又はフレームは、inter-BSS PPDU又はinter-BSSフレームに分類されてよい。また、BSS Aに属する(又は、BSS Aを運営するAPとアソシエーションされた)STA1、STA2が存在してよい。BSS Bに属する(又は、BSS Bを運営するAPとアソシエーションされた)STA3、STA4が存在してよい。図13を参照すると、STA1がPPDUを送信できる。また、STA1の送信したPPDUはBSSに対する情報を含んでよい。例えば、BSSに対する情報は、前述したBSSを分類するための情報であってよい。また、STA1の送信したPPDUは、Duration情報を含んでよい。
STA2は、STA1の送信したPPDUを受信し、このPPDUに対するBSSを分類できる。また、STA2とSTA1はBSS Aに属しているので、STA2の受信したPPDUはintra-BSS PPDUに分類されてよい。また、STA2の受信したPPDUはUL PPDUであるか、STAが意図した受信者でないPPDUであってよい。したがって、前述した実施例によってSTA2はintra-PPDU節電を行うことが可能である。図13を参照すると、STA2は、受信したPPDU終わりの時間までdoze状態に入り得る。また、STA2は、受信したPPDUに含まれたDuration情報に基づいてNAVを設定することができる。STA2は、受信したPPDUをintra-BSS PPDUに分類したので、intra-BSS NAVを設定することが可能である。
STA3は、STA1の送信したPPDUを受信し、このPPDUに対するBSSを分類できる。また、STA3とSTA1はそれぞれBSS B、BSS Aに属しているので、STA3の受信したPPDUはinter-BSS PPDUに分類されてよい。また、STA3は、受信したPPDUに含まれたDuration情報に基づいてNAVを設定できる。STA3は、受信したPPDUをinter-BSS PPDUに分類したので、basic NAVを設定することが可能である。
STA4は、STA1の送信したPPDUを受信し、このPPDUに対するBSSを分類できる。また、STA4とSTA1はそれぞれBSS B、BSS Aに属しているので、STA4の受信したPPDUはinter-BSS PPDUに分類されてよい。また、STA4の受信したPPDUの信号強度が閾値よりも小さくてよい。したがって、STA4の受信したPPDUがinter-BSS PPDUに分類されたし、STA4の受信したPPDUの信号強度が閾値よりも小さいので、STA4は空間再利用(spatial reuse)動作を行うことが可能である。したがって、STA4は、チャネル接続、バックオフ手順(backoff procedure)を行うことができ、送信を始めることができる。例えば、STA1の送信したPPDUが終わらない時点に、STA4が送信を始めることが可能である。
図14には、本発明の実施例に係るSTAの機能を示す。
本発明の実施例によれば、ある無線LAN標準に従うSTAは、以前の無線LAN標準の機能を含んでよい。これは、下位互換性のためのものである。例えば、特定の無線LAN標準を支援するSTAは、以前の世代の無線LAN標準機能を支援し、新しい機能もさらに支援できる。例えば、HT STAは、OFDM PHY STAの基本機能を支援できる。したがって、HT STAは、OFDM PHY STAに分類されてよい。また、HT STAは、OFDM PHY STAの機能の他、OFDM PHY STAが支援しない追加機能も支援できる。VHT STAは、HT STAの基本機能を支援する他、HT STAが支援しない機能も支援できる。VHT STAはHT STAに分類されてよい。また、HE STAは、VHT STAの基本機能を支援する他、VHT STAが支援しない機能も支援できる。HE STAはVHT STAに分類されてよい。また、EHT STAはHE STAでもあり得る。また、EHT STAは、HE STAの基本機能を支援する他、HE STAが支援しない機能も支援できる。また、EHT STAはHE STAに分類されてよい。また、EHT標準以降の無線LAN標準が新しく定義されてよい。本発明において、EHT標準以降の標準をNEXT標準と呼び、NEXT標準に従うSTAをNEXT STAと呼ぶ。NEXT STAは、EHT STAの基本機能を支援する他、EHT STAが支援しない機能も支援できる。NEXT STAはEHT STAに分類されてよい。
図14は、各無線LAN標準を支援するSTA間の関係を示すダイヤグラムである。図14を参照すると、EHT STAであれば、HE STAで、VHT STAで、HT STAで、OFDM PHY STAであってよい。また、NEXT STAであれば、EHT STAで、HE STAで、VHT STAで、HT STAで、OFDM PHY STAであってよい。
図15には、本発明の一実施例に係る上りリンク(Uplink:UL)多重ユーザ(multi user:MU)動作を示す。
本発明の一実施例において、アクセスポイントは、MU(multi-user)送信を誘発(solicit)するフレームを送信できる。このようなフレームをトリガリングフレームと呼ぶ。このとき、トリガリングフレームを受信した一つ以上のSTAは、トリガリングフレームに基づいて上り送信を行うことができる。具体的には、トリガリングフレームを受信した一つ以上のSTAは、フレームに対する応答フレームを送信できる。このとき、トリガリングフレームを含むPPDUと上り送信に用いられるPPDUとの間隔(inter-space)は、SIFSであってよい。具体的には、複数のSTAはトリガリングフレームを受信し、同時に(simultaneous)即刻の(immediate)応答を送信できる。即刻の応答は、先に受信したPPDUと応答を含むPPDUとの間の間隔がSIFSであることを示す。
トリガリングフレームは制御フレームの一種で、トリガー情報を含むトリガーフレームであってよい。また、トリガリングフレームは、トリガー情報をMACヘッダーに含むフレームであってよい。このとき、トリガー情報は、MACヘッダーのHT Controlフィールド、Controlサブフィールド、又はA-Controlサブフィールドに含まれるTRS(triggered response scheduling)であってよい。また、トリガー情報は、TB PPDUの送信を誘発する情報であってよい。
TB PPDUは、トリガリングフレームに対する応答フレームを含むPPDUフォーマットである。TB PPDUは、HE TB PPDU及びEHT TB PPDUを含んでよい。また、TB PPDUは、NEXT無線LAN標準で定義するNEXT TB PPDUを含んでよい。HE TB PPDUは、L-STF、L-LTF、L-SIG、RL-SIG、HE-SIG-A、HE-STF、HE-LTFを順に含むプリアンブルを含み、プリアンブルに続いてデータ、パケットエクステンション(packet extension,PE)を含んでよい。また、EHT TB PPDU、NEXT TB PPDUは、L-STF、L-LTF、L-SIG、RL-SIG、U-SIG、(EHT-/NEXT-)STF、(EHT-/NEXT-)LTFを順に含むプリアンブルを含み、プリアンブルに続いてデータ、パケットエクステンション(packet extension,PE)を含んでよい。
トリガリングフレームは、TB PPDU送信に必要な情報を含んでよい。MACフレームのTypeサブフィールド(B3B2)の値が01であり、サブタイプサブフィールド(B7 B6 B5 B4)の値が0010である場合に、MACフレームトリガーフレームであることを示し得る。
トリガーフレームに応答する複数のSTAが互いに異なるフォーマットのTB PPDUを送信する場合に、アクセスポイントにとってTB PPDUが受信し難いことがある。また、複数のSTAが送信するPPDUのプリアンブルが互いに異なる場合に、アクセスポイントにとってTB PPDUが受信し難いことがある。特に、互いに異なるフォーマットのTB PPDUが送信されるRUがオーバーラップする場合に、アクセスポイントにとってTB PPDUが受信し難いことがある。したがって、一つのトリガリングフレームに対する応答を送信する複数のSTAは、同一のフォーマットのTB PPDUを用いることができる。また、一つのトリガリングフレームに対する応答を送信する複数のSTAが送信するTB PPDUのプリアンブル情報は同一であってよい。
図14で説明しているように、HE STAは、HE TB PPDUを送信できる。また、EHT STAは、EHT TB PPDU又はHE TB PPDUを送信できる。また、NEXT STAは、NEXT TB PPDU、EHT TB PPDU又はHE TB PPDUを送信できる。
図15の実施例において、APがHE STA(HE STA)の送信とEHT STA(EHT STA)の送信をスケジュールするトリガーフレームを送信する。このとき、トリガーフレームがトリガーフレームに対する応答のために送信されるTB PPDUのフォーマットについて指示しない場合に、HE STA(HE STA)とEHT STA(EHT STA)又は互いに異なるEHT STA(EHT STA)は、互いに異なるフォーマットのTB PPDUを送信することがある。このため、TB PPDUの送信に失敗し、送信機会が浪費されることがある。説明の便宜のために、HE、EHT、及びNEXT標準で定義されたトリガーフレームをそれぞれ、HEトリガーフレーム、EHTトリガーフレーム、及びNEXTトリガーフレームと呼ぶ。また、HE、EHT、及びNEXT標準で定義されたTRSを、HE TRS、EHT TRS、及びNEXT TRSと呼ぶ。トリガーフレームのフォーマットについては図16を用いて説明する。
図16には、本発明の実施例に係るトリガーフレームのフォーマットと、トリガーフレームに含まれるサブフィールドを示す。
具体的には、図16(a)は、トリガーフレームのフォーマットを示し、図16(b)は、トリガーフレームのCommon Infoフィールドを示し、図16(c)は、トリガーフレームのUser Infoフィールドを示す。トリガーフレームのMACヘッダーは、Frame Controlフィールド、Durationフィールド、及びAddressフィールドを含む。このとき、Addressフィールドは、RAフィールド、TAフィールドを含む。また、トリガーフレームは、Common InfoフィールドとUser Info Listフィールドを含む。Common Infoフィールドは、トリガーフレームがトリガーする全てのステーションのための情報を含む。また、User Info Listフィールドは、User Infoフィールドを含んでよい。具体的な実施例において、特定タイプのトリガーフレームは、User Info Listフィールドを含まなくてよい。また、トリガーフレームは、PaddingフィールドとFCSフィールドを含んでよい。Paddingフィールドは、トリガーフレームを受信するSTAが応答を準備するのにかかる時間を確保するためにframe長さを増やす役割を担うことができ、選択的に存在してよい。
Common InfoフィールドはTrigger Typeサブフィールドを含んでよい。Trigger Typeサブフィールドは、トリガーフレームバリアント(variant)を識別(identify)する。トリガーフレームは、Trigger Typeサブフィールドの値でトリガーフレームのタイプを示すことができる。また、Trigger Typeサブフィールドによって、Trigger Dependent Common Infoサブフィールド、Trigger Dependent User Infoサブフィールドに含まれる情報、及びTrigger Dependent Common Infoサブフィールド、Trigger Dependent User Infoサブフィールドの長さが決定されてよい。例えば、Trigger TypeサブフィールドをCommon InfoフィールドのB0からB3までのビットが示すことができる。
また、Common InfoフィールドはUL Lengthサブフィールドを含んでよい。UL Lengthサブフィールドは、Trigger frameに応答するTB PPDUの長さに関する情報を含んでよい。又は、UL Lengthサブフィールドは、Trigger frameに応答するframeの長さに関する情報を含んでよい。また、UL Lengthサブフィールドは、Trigger frameに応答するTB PPDUのL-SIGのLengthサブフィールドに含まれる値を指示することができる。したがって、TB PPDUで応答するSTAは、受信したTrigger frameが含むUL Lengthサブフィールドの値に基づいてTB PPDUのL-SIGのLengthサブフィールドを設定できる。より具体的には、TB PPDUで応答するSTAは、受信したTrigger frameが含むUL Lengthサブフィールドの値でTB PPDUのL-SIGのLengthサブフィールドを設定できる。例えば、UL LengthサブフィールドをCommon Info fieldのB4からB15までのビットが示すことができる。
また、Common InfoフィールドはUL BWサブフィールドを含んでよい。UL BWサブフィールドは、トリガーフレームに応答するTB PPDUのシグナリングフィールド、例えば、HE-SIG-Aフィールド又はU-SIGフィールドに含まれる帯域幅(bandwidth,BW)値を指示することができる。また、UL BWサブフィールドは、Trigger frameに応答するTB PPDUの最大帯域幅を示すことができる。
また、Common Infoフィールドは、トリガーフレームに応答するTB PPDUのシグナリングフィールド、例えば、HE-SIG-Aフィールド又はU-SIGフィールドに含まれる情報などを含んでよい。
User Infoフィールドは、AID12サブフィールドを含んでよい。AID12サブフィールドは、AID12サブフィールドを含むUser Infoフィールドの意図した受信者又はUser Infoフィールドの機能を指示する役割を担うことができる。したがって、AID12サブフィールドは、AID12サブフィールドを含むトリガーフレームの意図した受信者又はトリガーフレームの機能を指示する役割を担うことができる。例えば、AID12サブフィールドの値が既に設定された値である場合に、User InfoフィールドはRA-RU(random access resource unit)を指示するものであることを示すことができる。より具体的には、AID12サブフィールドの値が0である場合に、User Infoフィールドは、連結された(associated)STAのためのRA-RUを指示できる。また、AID12サブフィールドの値が2045である場合に、User Infoフィールドは、連結されていない(unassociated)STAのためRA-RUを指示できる。また、AID12サブフィールドの値が指示するSTAID、例えば、AID(association ID)に該当するSTA AID12サブフィールドを含むUser Infoフィールド又はAID12サブフィールドを含むトリガーフレームが応答をトリガーすることを示すことができる。例えば、AID12サブフィールドは、AID又はAIDの12LSBsを示すことができる。AID12サブフィールドの値に該当するSTAは、トリガーフレームにTB PPDUで応答することができる。また、AID12サブフィールドの値は1から2007までの範囲(1と2007を含む。)であってよい。また、AID12サブフィールドが既に設定された値、例えば2046である場合に、該当するRUはいかなるSTAにも割り当てられていないことを指示できる。また、AID12サブフィールドが既に設定された値、例えば4095である場合に、トリガーフレームのパディングが始まることを指示できる。
また、AID12サブフィールドを含むUser Infoフィールドの情報は、AID12サブフィールドが指示するSTAに該当する情報であってよい。例えば、RU Allocationサブフィールドは、RUのサイズと位置を指示できる。このとき、AID12サブフィールドを含むUser InfoフィールドのRU Allocationサブフィールドの値は、前記AID12サブフィールドが指示するSTAに該当する情報であってよい。また、User Infoフィールドは、User Infoフィールドを含むトリガーフレームの応答に用いられるコーディング方法(UL FEC Coding Type)、モジュレーション方法(UL HE-MCS、UL DCM)、送信電力(UL Target RSSI)を指示できる。
前述したように、トリガーフレームに対する応答として同時に送信されるTB PPDUがいかなるPPDUのフォーマットで送信されるかによって問題になり得る。これに関連したトリガリングフレーム送信方法については図17を用いて説明する。
図17には、本発明の実施例によってトリガーフレームのAID12サブフィールドの値が指示する情報を示す。
本発明の実施例に係るEHT STAは、HE TB PPDU、EHT TB PPDUを選択的に送信できる。また、NEXT STAは、HE TB PPDU、EHT TB PPDU、NEXT TB PPDUを選択的に送信できる。これにより、一つのフレーム又は一つのPPDUで複数の無線LAN標準のSTAをスケジュールすることができる。これにより、送信媒体の使用効率を高めることができる。例えば、EHT標準を支援しないHE STAとEHT STAが一つのフレームでHE TB PPDUで応答するようにし得る。
また、TB PPDUフォーマットを選択するための情報が、トリガーフレーム又はTRS又はトリガーフレームを含むPPDU又はTRSを含むPPDUに含まれてよい。
本発明の実施例によれば、応答するTB PPDU formatに関する情報がMAC levelに存在し得る。本発明の実施例によれば、トリガーフレームは、HEトリガーフレーム、EHTトリガーフレーム及びNEXTトリガーフレームに区別されてよい。また、HEトリガーフレーム、EHTトリガーフレーム、NEXTトリガーフレームでトリガーされた応答は、それぞれ、HE TB PPDU、EHT TB PPDU、NEXT TB PPDUで応答できる。
また、HEトリガーフレーム、EHTトリガーフレーム、NEXTトリガーフレームを区別することは、トリガーフレームに応答するTB PPDUフォーマットをそれぞれ、HE TB PPDU、EHT TB PPDU、NEXT TB PPDUに区別するというのと同じ意味であってよい。すなわち、トリガーフレームのフォーマットによってそれに対するTB PPDUのフォーマットも変わってよく、次世代トリガーフレームは以前の世代TB PPDUの送信も共に指示できる。すなわち、EHTトリガーフレームは、HE TB PPDUとEHT TB PPDUの送信を同時に指示できる。しかし、HEトリガーフレームはEHT TB PPDUの送信を指示することはできない。
具体的な実施例において、トリガーフレームが含むMACヘッダーのFrame Controlフィールドによって、トリガーフレームがHEトリガーフレーム、EHTトリガーフレーム及びNEXTトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。例えば、トリガーフレームが含むMACヘッダーのFrame ControlフィールドのTypeサブフィールド、Subtypeサブフィールド又はControl Frame Extensionサブフィールドのうち少なくともいずれか一つによって、トリガーフレームがHEトリガーフレーム、EHTトリガーフレーム及びNEXTトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。例えば、トリガーフレームが含むMACヘッダーのFrame ControlフィールドのTypeサブフィールド、Subtypeサブフィールド又はControl Frame Extensionサブフィールドが第1値である場合に、トリガーフレームはHEトリガーフレームに分類されてよい。また、トリガーフレームが含むMACヘッダーのFrame ControlフィールドのTypeサブフィールド、Subtypeサブフィールド又はControl Frame Extensionサブフィールドが第2値である場合に、トリガーフレームはEHTトリガーフレームに分類されてよい。また、トリガーフレームが含むMACヘッダーのFrame ControlフィールドのTypeサブフィールド、Subtypeサブフィールド又はControl Frame Extensionサブフィールドが第3値である場合に、トリガーフレームはNEXTトリガーフレームに分類されてよい。MACヘッダーのFrame ControlフィールドのTypeサブフィールドの値が01であり、サブタイプサブフィールドの値が0010である場合に、トリガーフレームはHEトリガーフレームに分類されてよい。Typeサブフィールド、Subtypeサブフィールド及びControl Frame Extensionサブフィールドのそれぞれが2ビット、4ビット及び4ビットに限定される。このため、このような実施例は、限られたビットフィールドの値で将来に利用可能なタイプを制限するという短所がある。
さらに他の具体的な実施例において、トリガーフレームが含むCommon Infoフィールドによって、トリガーフレームがHEトリガーフレーム、EHTトリガーフレーム及びNEXTトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。例えば、トリガーフレームのCommon InfoフィールドのTrigger Typeサブフィールドの値が第1値である場合に、トリガーフレームはHEトリガーフレームに分類されてよい。トリガーフレームのCommon InfoフィールドのTrigger Typeサブフィールドの値が第2値である場合に、トリガーフレームはEHTトリガーフレームに分類されてよい。トリガーフレームのCommon InfoフィールドのTrigger Typeサブフィールドの値が第3値である場合に、トリガーフレームはNEXTトリガーフレームに分類されてよい。具体的には、トリガーフレームのCommon InfoフィールドのTrigger Typeサブフィールドの値が0~7である場合に、トリガーフレームはHEトリガーフレームに分類されてよい。また、トリガーフレームのCommon InfoフィールドのTrigger Typeサブフィールドの値が0~7でない場合、トリガーフレームはEHTトリガーフレーム又はNEXTトリガーフレームに分類されてよい。Trigger Typeサブフィールドのビット数が限定されているため、このような実施例は、限られたビットフィールドの値で将来に利用可能なトリガータイプを制限するという短所がある。
さらに他の具体的な実施例において、トリガーフレームが含むUL Lengthフィールドによって、トリガーフレームがHEトリガーフレーム、EHTトリガーフレーム及びNEXTトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。例えば、トリガーフレームのUL Lengthフィールドの値を3で割った余りの値が第1値である場合に、トリガーフレームはHEトリガーフレームに分類されてよい。トリガーフレームのUL Lengthフィールドの値を3で割った余りの値が第2値である場合に、トリガーフレームはEHTトリガーフレームに分類されてよい。トリガーフレームのUL Lengthフィールドの値を3で割った余りの値が第3値である場合に、トリガーフレームはNEXTトリガーフレームに分類されてよい。トリガーフレームのUL Lengthフィールドの値を3で割った余りの値が0でない場合に、トリガーフレームはHEトリガーフレームに分類されてよい。トリガーフレームのUL Lengthフィールドの値を3で割った余りの値が1である場合に、トリガーフレームはHEトリガーフレームに分類されてよい。トリガーフレームのUL Lengthフィールドの値を3で割った余りの値が0である場合に、トリガーフレームはEHTトリガーフレーム又はNEXTトリガーフレームに分類されてよい。また、トリガーフレームのUL Lengthフィールドの値の他にも、トリガーフレームのFormat Identifier、PHY Identifier及びTB PPDUフォーマットシグナリングのうち少なくとも一つによって、トリガーフレームがHEトリガーフレーム、EHTトリガーフレーム及びNEXTトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。
さらに他の具体的な実施例において、トリガーフレームが含むUser Infoフィールドによって、トリガーフレームがHEトリガーフレーム、EHTトリガーフレーム及びNEXTトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。具体的には、トリガーフレームのUser InfoフィールドのAID12サブフィールドの値によってトリガーフレームがHEトリガーフレーム、EHTトリガーフレーム及びNEXTトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。例えば、トリガーフレームのUser InfoフィールドのAID12サブフィールドの値があらかじめ指定された値であるかによって、トリガーフレームがHEトリガーフレーム、EHTトリガーフレーム及びNEXTトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。このとき、トリガーフレームのタイプを示すAID12サブフィールドを含むUser Infoフィールドは、User Infoフィールドリストにおいて最初のUser Infoフィールドであってよい。トリガーフレームのタイプを示すAID12サブフィールドを含むUser Infoフィールドは、STAのAIDを指示するAID12サブフィールドを含むUser Infoフィールドよりも前に位置してよい。これにより、トリガーフレームを受信するSTAがトリガーフレームのタイプを早期に判断することができる。さらに他の具体的な実施例において、トリガーフレームのタイプを示すAID12サブフィールドを含むUser Infoフィールドは、User InfoフィールドリストにおいてHE STAのためのUser Infoフィールドの後に位置してよい。これにより、レガシーSTA、すなわちHE STAがAID12サブフィールドの値の意味を判断できないことから発生する問題を防止することができる。また、トリガーフレームのタイプを示すAID12サブフィールドを含むUser Infoフィールドは、AID12サブフィールド以外のサブフィールドを含まなくてよい。当該User Infoフィールドはトリガーフレームタイプを指示するためのものであり、トリガーフレームタイプ以外の情報は必要としなくて済むことがあるためである。このような実施例において、User Infoフィールドの長さは、AID12サブフィールドの値によって変化する。図17に、このような実施例が適用されるとき、AID12サブフィールドの値が示す意味を示す。AID12サブフィールドの値が第1値である場合に、AID12サブフィールドは、AID12サブフィールドを含むトリガーフレームがEHT TB PPDUの送信をトリガーすることを示すことができる。第1値は2047であってよい。AID12サブフィールドの値が第2値である場合に、AID12サブフィールドは、AID12サブフィールドを含むトリガーフレームがNEXT TB PPDUの送信をトリガーすることを示すことができる。第2値は2048であってよい。
さらに他の具体的な実施例において、STAは、STAをトリガーするUser Infoフィールドの位置によって、トリガーフレームに対する応答として送信するTB PPDUのフォーマットを決定することができる。具体的には、STAは、STAをトリガーするUser Infoフィールドが、あらかじめ指定された値を有するAID12サブフィールドを含むUser Infoフィールドの後に位置するか否かに基づいて、トリガーフレームに対する応答として送信するTB PPDUのフォーマットを決定できる。このとき、STAは、STAをトリガーするUser Infoフィールドが、第1値を有するAID12サブフィールドを含むUser Infoフィールドの後に位置するか否かと第2値を有するAID12サブフィールドを含むUser Infoフィールドの後に位置するか否かに基づいて、トリガーフレームに対する応答として送信するTB PPDUのフォーマットを決定できる。図17の実施例において、STAをトリガーするUser Infoフィールドが、2047を有するAID12サブフィールドを含むUser Infoフィールドの後に位置するとき、STAは、トリガーフレームに対する応答としてEHT TB PPDUを送信できる。また、STAをトリガーするUser Infoフィールドが2048を有するAID12サブフィールドを含むUser Infoフィールドの後に位置するとき、STAは、トリガーフレームに対する応答としてNEXT TB PPDUを送信できる。また、STAをトリガーするUser Infoフィールドが、2047を有するAID12サブフィールドを含むUser Infoフィールドと2048を有するAID12サブフィールドを含むUser Infoフィールドの後に位置するとき、STAは、トリガーフレームに対する応答としてNEXT TB PPDUを送信できる。また、STAをトリガーするUser Infoフィールドが、2047を有するAID12サブフィールドを含むUser Infoフィールドと2048を有するAID12サブフィールドを含むUser Infoフィールドの前に位置するとき、STAは、トリガーフレームに対する応答としてHE TB PPDUを送信できる。
AID12サブフィールド以外のUser Infoフィールドのサブフィールドによって、トリガーフレームがHEトリガーフレーム、EHTトリガーフレーム及びNEXTトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。
トリガーフレームのPaddingフィールドによって、トリガーフレームがHEトリガーフレーム、EHTトリガーフレーム及びNEXTトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。例えば、トリガーフレームのPaddingフィールドが、あらかじめ指定された値を含むか否かによって、HEトリガーフレーム、EHTトリガーフレーム及びNEXTトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。
また、これらの実施例は結合して適用されてよい。例えば、上記のトリガーフレームがHEトリガーフレーム、EHTトリガーフレーム及びNEXTトリガーフレームのいずれかであるかを判断するのに影響を与える要素が結合して判断されてよい。
また、これらの実施例は、TRSフィールドに対する応答として送信されるTB PPDUのフォーマットを決定するために用いられてよい。
図18には、本発明の実施例に係るUL MU動作を示す。
前述したように、トリガーフレームは、MACフレームヘッダーにTRSを含んでよい。TRSは、前述したように、HT Controlフィールドに含まれてよい。具体的には、HT Controlフィールドは、A-Controlフィールドを含むとき、TRSを含んでよい。また、TRSはTRS Controlフィールドに含まれてよい。A-ControlフィールドにControl Listフィールドが連続して位置してよい。このとき、Control ListフィールドがTRSを含んでよい。
TRSを含むMACフレームの意図した受信者に該当するSTAは、TRSに基づいてPPDUを送信できる。このとき、TRSは、STAがTRSを含むMACフレームに対する応答として送信するPPDU又はフレームの長さに関する情報(UL Data Symbols)を含んでよい。TRSを含むMACフレームに対する応答送信の電力に関する情報(AP Tx Power、UL Target RSSI)、TRSを含むMACフレームに対する応答を送信する時に用いるRUの位置及びサイズ(RU Allocation)、TRSを含むMACフレームに対する応答送信のモジュレーション方法に関する情報(UL HE-MCS)を含んでよい。
TRSは、無線LAN標準別に定義されてよい。このとき、TRSを含むMACフレームを受信したSTAは、TRSのフォーマット、すなわち、どの無線LAN標準で定義されたTRSであるかによって、TRSに対する応答として送信されるTB PPDUのフォーマットを決定することができる。具体的には、STAがHE TRSを受信した場合に、STAは、TRSに対する応答としてHE TB PPDUを送信できる。また、STAがEHT TRSを受信した場合に、STAは、TRSに対する応答としてEHT TB PPDUを送信できる。また、STAがNEXT TRSを受信した場合に、STAは、TRSに対する応答としてNEXT TB PPDUを送信できる。このとき、STAは、A-ControlサブフィールドのControl IDサブフィールドに基づいて、どの無線LAN標準で定義されたTRSであるかが判断できる。TRSは、HE TRSと、HE TRSでないTRSとに区別されてよい。
TRSのフォーマットは、TRSが含まれるHT ControlフィールドがHEバリアント(variant)なのか、EHTバリアントなのか、NEXTバリアントなのかによって決定されてよい。TRSが含まれるHT ControlフィールドがEHTバリアント(variant)である場合に、TRSはEHT TRSであってよい。また、TRSが含まれるHT ControlフィールドがNEXTバリアント(variant)である場合に、TRSはNEXT TRSであってよい。また、TRSのフォーマットは、TRSが含まれるHT Controlフィールドのビットのうちあらかじめ指定されたビットがどの値であるかによって、HT ControlフィールドがHEバリアントなのか、EHTバリアントなのか、NEXTバリアントなのかが決定されてよい。例えば、HT Controlフィールドの1番目、2番目のビット(B0,B1)値が11である場合に、HT ControlフィールドはHEバリアントであってよい。また、HT Controlフィールドの1番目、2番目のビット(B0,B1)と追加のビット、例えば32番目のビット(B31)に基づいてHT ControlフィールドがHE variantなのか、EHT variantなのか、NEXT variantなのかが決定されてよい。
図18の実施例において、TRSがHE PPDUに含まれる場合に、HE PPDUを受信したSTAは、TRSに対する応答としてHE TB PPDUを送信する。TRSがEHT PPDUに含まれる場合に、EHT PPDUを受信したSTAは、TRSに対する応答としてEHT TB PPDUを送信する。TRSがNEXT PPDUに含まれる場合に、NEXT PPDUを受信したSTAは、TRSに対する応答としてNEXT TB PPDUを送信する。
また、TRSが含まれたPPDUフォーマットによって、TRSが含むサブフィールドが示す情報が変わってよい。TRSがHE PPDUに含まれる場合に、TRSが含むMCSに関するサブフィールド、例えばUL HE-MCSサブフィールドは、HE MCSテーブルに該当する値を指示できる。また、TRSがEHT PPDUに含まれる場合に、TRSが含むMCSに関するサブフィールド、例えばUL HE-MCSサブフィールドは、EHT MCSテーブルに該当する値を指示できる。また、TRSがNEXT PPDUに含まれる場合に、TRSが含むMCSに関するサブフィールド、例えばUL HE-MCSサブフィールドは、NEXT MCSテーブルに該当する値を指示できる。また、TRSが含まれるPPDUフォーマットによって、RU Allocationサブフィールドが示す情報が変わってよい。
図19は、本発明の一実施例に係るTXOPを共有するための方法を示す図である。
図19を参照すると、APによって設定されたTXOPの一部又は全部がnon-AP STAに共有され、non-AP STAは、共有されたTXOPを用いて他のnon-AP STA(第3STA)及び/又はAPにPPDU(PLCP Protocol Data Unit)を送信することができる。以下、本発明では、他のSTAにTXOPを共有することをTXOP共有(sharing)と称することができる。また、STAは、トリガーフレーム(trigger frame)を送信するAP又はAP-STAであるか、トリガーフレームを受信するnon-AP STAであってよい。また、STAは、TXOPを共有したり、又はTXOPが共有されてよい。
具体的には、STAは、TXOPを設定するためのフレームを送信した後、これに対する応答を受信することにより、TXOPを設定(又は、取得)することができる。STAはTXOPを設定した後に、設定されたTXOPを共有することによって、TXOP共有を果たすことができる。TXOPを設定するためのフレームに対する応答は、TXOPの長さに関する情報を含んでよく、TXOPの長さは0より大きくてよい。このとき、TXOPを設定するためのフレームに対する応答は、即刻の応答(immediate response)であってよく、TXOPを設定するためのフレーム(例えば、PPDU)の終わりから特定時間(例えば、SIFS)後に送信されてよい。
TXOPの長さは、STAが送信するフレームに含まれるデュレーション情報(duration information)に基づいて指示されてよい。例えば、デュレーション情報は、PPDUのMACヘッダーのデュレーション/IDフィールドに含まれてよく、TXOPの長さはデュレーション情報に基づくことができる。TXOPの長さはSTAによって送信されるフレームのPPDUに含まれたプリアンブルに含まれてよい。すなわち、デュレーション情報は、PPDUのシグナリングフィールド(signaling field)に含まれるTXOPフィールドに含まれてよく、シグナリングフィールドはHE-SIG-Aフィールド又はU-SIGフィールドであってよい。
TXOP共有は、設定されたTXOP内で共有されてよく、設定されたTXOPの間に一つ以上のTXOPが共有されてよい。すなわち、STAによって設定されたTXOP内で他のSTAに一つ以上のTXOPが共有されてよい。
TXOPが共有されたSTAは、共有されたTXOPの間にPPDUを、TXOPを共有したSTA又は他のSTAに送信でき、この時、送信されるPPDUは、TB PPDUでないPPDU(例えば、non-TB PPDU)であってよい。すなわち、TXOPが共有されたSTAは、共有されたTXOPの間にAPからトリガーフレームを受信しなくてもPPDUを送信することができる。言い換えると、TXOPが共有されたSTAは、共有されたTXOPの間にトリガーフレームによって別途のRUが個別的に割り当てられなくても、TXOPが共有される時に送信されたトリガーフレームによって、割り当てられたRUを用いて、共有されたTXOPが終了するまで追加のトリガーフレームを受信しなくてもPPDUを送信することができる。したがって、共有されたTXOPの間にSTAによって送信されるPPDUの例示として、non-HT PPDU、HE PPDU、VHT PPDU、HE SU PPDU又はEHT MU PPDUがあり得る。
TXOPの共有において、共有されたTXOPの間に、TXOPが共有されたSTAは、TXOPを共有したSTA又は第3STA(さらに他のSTA)にフレームを送信することができる。すなわち、APがTXOPを設定し、設定されたTXOPの一部又は全部をSTAに共有する場合に、TXOPが共有されたSTAは、TXOPを共有したAP又は第3STAにフレームを送信することができる。このとき、STAが第3STAに送信するフレームは、non-AP STA同士間で送信するフレームであることから、P2P(peer to peer)フレームであり得る。
このようなTXOPの共有は特定フレームによって設定されてよい。すなわち、特定フレームによって設定されたTXOPの一部又は全部が共有されるということが指示されてよく、STAは、当該フレームを受信し、共有されたTXOPを用いることができる。このとき、特定フレームは、TXOPを共有するSTAによって送信されてよい。例えば、APによって送信されるトリガーフレームによってTXOP共有が行われてよい。この場合、TXOP共有のためのトリガーフレームは、特定タイプのトリガーフレーム(例えば、MU-RTSフレーム、又はMU-RTSトリガーフレームなど)であってよく、図16で説明したトリガーフレームのトリガータイプサブフィールドの値によって識別されてよい。すなわち、トリガータイプサブフィールドの値が既に設定された値(例えば、「3」)に設定された場合に、トリガーフレームを受信したSTAは、TXOPが共有されることを認識でき、共有されたTXOPでPPDUを送信できる。
TXOPを共有するためのフレームであるMU-RTSフレームは、一つ以上のSTAからCTSフレームの送信を指示するフレームであってよい。例えば、MU-RTSフレームに対する即刻の応答としてCTSフレームが送信されてよく、CTSフレームはnon-HT PPDUであってよい。以下、本発明において、TXOPの共有のためのMU-RTSフレームは、modified MU-RTSフレーム又はMU-RTS TXSトリガーフレームと呼ぶことができる。ただし、これに限定されるものではなく、TXOPの共有のためのフレームは様々な呼称としてもよい。
TXOPの一部又は全部の共有は、1個のSTAにのみ設定されたり、1個以上のSTAに設定されたりしてよい。すなわち、フレームを用いたTXOPの共有では、TXOP共有のための一つ又はそれ以上のSTAがフレームによって指示されてよい。このとき、TXOPの共有は、前述したように、共有するSTAによって設定されたTXOP内で設定されてよい。すなわち、共有されるTXOPは、共有するSTAによって設定されたTXOPを超えることがない。
共有されるTXOPのデュレーションは、TXOPの共有のための特定フレーム(例えば、modified MU-RTSフレーム)を通じて指示されてよい。例えば、modified MU-RTSフレームは、UL長さサブフィールドを含んでよく、UL長さサブフィールドは、共有されるTXOPのデュレーションを含んでよい。このとき、UL長さサブフィールドは、図16で説明したUL長さサブフィールドであってよい。UL長さサブフィールドは、トリガーフレームがTB PPDUの送信を指示する場合に、指示されたTB PPDUの長さに関する情報(又は、TB PPDUの送信のための区間情報)を含んでよい。
送信されるMU-RTSフレームがTXOPの共有のためのMU-RTSフレーム(modified MU-RTSフレーム)であるか又はTXOPの共有のために用いられないMU-RTSフレームであるかは、フレームに含まれた特定フィールドによって指示されてよい。例えば、フレームに含まれた特定フィールドの値が既に設定された値である場合に、当該MU-RTSフレームは、TXOP共有のためのmodified MU-RTSフレームであってよい。このとき、特定フレームは、GI And HE-LTFタイプサブフィールドであってよい。例えば、トリガーフレームに含まれたタイプフィールドがMU-RTSフレームを指示する場合に、GI And HE-LTFタイプサブフィールドの値によって、MU-RTSフレームがTXOPの共有のためのトリガーフレームであるか否かが識別されてよい。すなわち、GI And HE-LTFタイプサブフィールドが既に設定された値に設定された場合に、当該トリガーフレームはTXOPの共有のためのトリガーフレーム(例えば、modified MU-RTSフレーム又はMU-RTS TXSトリガーフレーム)であってよい。
又は、受信されたフレームがTXOPの共有のためのMU-RTSフレーム(modified MU-RTSフレーム又はMU-RTS TXSトリガーフレーム)であるか否かは、MU-RTSフレームに特定フィールドが含まれるか否か及び/又は特定フィールドの個数に基づいて決定されてよい。このとき、特定フィールドは、図16で説明したユーザ情報フィールド(User Info field)又はユーザ情報リストフィールド(User Info List field)であってよい。具体的には、MU-RTSフレームに含まれたユーザ情報フィールドの個数に基づいて、受信されたMU-RTSフレームがTXOPの共有のためのフレームであるか否かが判断されてよい。例えば、MU-RTSフレームがユーザ情報フィールドを含まない場合(ユーザ情報フィールドの個数が「0」である場合)に、当該MU-RTSフレームはTXOP共有のためのフレームであってよい。このとき、MU-RTSフレームがTXOP共有のためのフレームでない場合に、当該MU-RTSフレームは、一つ以上のSTAに既存のCTSフレームの送信を指示するMU-RTSフレームであるか、既存のMU-RTSフレームは、802.11ax標準で定義したMU-RTSフレームであってよい。
既存のMU-RTSフレームに対する応答としてCTSフレームが送信された直後には、前記既存のMU-RTSフレームを送信したSTA(例えば、AP)がフレーム又はPPDUを送信できる。また、modified MU-RTSフレームに対する応答としてCTSフレームが送信された直後には、前記CTSフレームを送信したSTAがフレーム又はPPDUを送信できる。又は、modified MU-RTSフレームに対する応答としてTXOP共有を受けたSTAが、CTSフレームでないフレーム又はPPDUを送信できる。このとき、フレーム、PPDUはそれぞれ、前述の共有されたTXOPの間にTXOP共有を受けたSTAが送信するフレーム、共有されたTXOPの間にTXOP共有を受けたSTAが送信するフレームを含むPPDUであってよい。すなわち、フレーム又はPPDUは、APに向かうものであるか、P2Pフレームであってよい。
本発明において、MU-RTSフレームと表記されたものは、既存のMU-RTSフレームであってよい。すなわち、本発明においてMU-RTSフレームと表記されたものは、modified MU-RTSフレームでないMU-RTSフレームであってよい。
本発明の一実施例によれば、modified MU-RTSフレームに対する応答としてCTSフレームが送信されてよい。前記CTSフレームはTXOP共有を受けるSTAが送信するものであってよい。このような場合、TXOP共有を受けるSTAは、CTSフレームを送信した直後にフレームを送信することができる。TXOP共有を受けるSTAは、CTSフレームを含むPPDUを送信した直後にフレームを送信することができる。CTSフレームを送信した直後に送信する前記フレームは、前述の共有されたTXOPの間にTXOP共有を受けたSTAが送信するPPDUに含まれたものであってよい。又は、CTSフレームを送信した直後に送信する前記フレームは、前述したnon-TB PPDUに含まれて送信されるものであってよい。また、本発明において直後に送信するということは、CTSフレームを含むPPDUの終わりからSIFS又はPIFS時間以後に送信することを意味できる。CTSフレームは、TXOP共有を受けるSTAが、TXOP共有を受けたということを知らせる役割を担うことができる。
さらに他の実施例によれば、modified MU-RTSフレームに対する応答としてCTSフレームが送信されなくてよい。また、modified MU-RTSフレームの直後に、TXOP共有を受けるSTAはフレームを送信できる。又は、modified MU-RTSフレームを含むPPDU直後に、TXOP共有を受けるSTAはPPDUを送信できる。この時に送信する前記フレームは、前述の共有されたTXOPの間に、TXOP共有を受けたSTAが送信するPPDUに含まれたものであってよい。又は、この時に送信する前記フレームは、前述したnon-TB PPDUに含まれて送信されるものであってよい。また、本発明において、直後に送信するということは、modified MU-RTSフレームを含むPPDUの終わりからSIFS又はPIFS時間以後に送信することを意味してよい。
一実施例によれば、modified MU-RTSフレームは、TXOP共有を受けるSTAがCTSフレームを送信しなければならないか否かに対するシグナリングを含んでよい。一実施例によれば、TXOP共有を受けるSTAがAPに送るフレームを送信する場合に、CTSフレーム無しで共有されたTXOPを使用することが可能である。また、TXOP共有を受けるSTAがP2Pフレームを送信する場合に、CTSフレームを送信し、共有されたTXOPを使用することが可能である。また、TXOP共有を受けるSTAがP2Pフレームを送信する場合にも、modified MU-RTSフレームの直後に送信するCTSフレームのRAフィールドは、前記modified MU-RTSフレームを送信したSTAのMAC addressとして設定されることが可能である。これは、TXOP共有を受けるSTAがmodified MU-RTSフレームを受信した後、前記modified MU-RTSフレームを送信したSTAのaddressを含むフレームを送信しない場合に、TXOP共有をするSTAは、TXOP共有を受けるSTAがmodified MU-RTSフレームを成功的に受信したか否かが分かり難いためである。
図19を参照すると、STA1とSTA2が存在してよく、互いに結合(association)されていてよい。また、STA1はAPであってよい。STA2はnon-AP STAであってよい。STA1はMU-RTSフレームを送信することが可能である。前記MU-RTSフレームは既存のMU-RTSフレームであってよい。前記MU-RTSフレームは、TXOP durationに関するduration informationを含んでよい。前記MU-RTSフレームは一つ以上のSTAからCTSフレームを誘発(solicit)することができる。このとき、前記一つ以上のSTAはSTA2を含んでよい。STA2は、前記MU-RTSフレームに対する応答としてCTSフレームを送信できる。この場合、STA1はTXOP holderになり得る。TXOP holderは、TXOPを得たSTAであってよい。TXOP holderは、TXOPの間に、送信しようとするフレームを送信できる。また、この場合、STA2はTXOP responderになり得る。TXOP responderは、TXOP holderが送ったフレームに対する応答を送信したSTAであってよい。TXOP responderは、TXOPの間にTXOP holderが送信したフレームに対する応答(response)を送信することが可能である。又は、TXOP responderは、TXOPの間にTXOP holderが許容したフレームを送信することが可能である。図19の実施例において、MU-RTSフレーム、CTSフレームの交換(exchange)に基づいてTXOPが取得される例を説明したが、本発明は、これに限定されず、他のフレーム交換に基づいてTXOPが取得されることにも適用可能である。
図19において、STA1がTXOPを取得した後にTXOP共有を行うことが可能である。例えば、STA1は、TXOP共有を知らせるフレームであるmodified MU-RTSフレームを送信することができる。例えば、modified MU-RTSフレームをSTA2に送信できる。前記modified MU-RTSフレームのTA(transmitter address)は、STA1のMAC address又はSTA1のMAC addressに基づく値に設定されてよい。前記modified MU-RTSフレームのRA(receiver address)は、STA2のMAC address又はSTA2のMAC addressに基づく値に設定されてよい。また、前記modified MU-RTSフレームが含むUser Infoフィールドは、AID12サブフィールド値がSTA2を指示できる。すなわち、前記modified MU-RTSフレームが含むUser Infoフィールドは、AID12サブフィールド値がSTA2のAIDの12LSBsを指示できる。前記modified MU-RTSフレームは、共有されたTXOPのdurationに関する情報を含んでよい。
一実施例によれば、STA2は、modified MU-RTSフレームに対する応答としてCTSフレームを送信できる。また、STA2は、CTSフレームを送信した後にフレームを送信できる。STA2がCTSフレームを送信した後に送信するフレームは、CTSフレームでなくてよい。さらに他の実施例によれば、STA2は、modified MU-RTSフレームに対する応答としてCTSフレームを送信しなくてよい。この場合、STA2は、modified MU-RTSフレームが送信された後に、CTSフレームでないフレームを送信できる。また、STA2がmodified MU-RTSフレームを受信した後に送信するCTSフレームでないフレームは、一実施例によれば、STA1に送信するフレームであってよい。他の実施例によれば、STA2がmodified MU-RTSフレームを受信した後に送信するCTSフレームでないフレームは、STA3に送信するフレームであってよい。
例えば、APはnon-AP STA(又は、STA)にトリガーフレームを送信することにより、APのTXOPを設定することができる。この時、APはトリガーフレームを送信したnon-AP STAに、APによって設定されたTXOPの一部又は全部を共有しようとする場合に、トリガーフレームの特定フィールド(例えば、GI And HE-LTFタイプサブフィールド)を既に設定された値に設定して送信することができる。このとき、特定フィールドは、GI And HE-LTFタイプ/トリガーされたTXOP共有モードサブフィールド(triggered TXOP sharing mode subfield)と呼ぶことができる。具体的には、APがAPによって設定されたTXOPを共有しない場合に、GI And HE-LTFタイプ/トリガーされたTXOP共有モードサブフィールドは「0」に設定され、GI And HE-LTFタイプサブフィールドと解釈されてよい。しかし、APがAPによって設定されたTXOPを共有しない場合に、GI And HE-LTFタイプ/トリガーされたTXOP共有モードサブフィールドは「1」又は「2」の値に設定され、トリガーされたTXOP共有モードサブフィールドと解釈されてよい。仮に、GI And HE-LTFタイプ/トリガーされたTXOP共有モードサブフィールドの値が「1」又は「2」である場合に、当該トリガーフレームは、modified MU-RTSフレーム又はMU-RTS TXSトリガーフレームと呼ぶことができる。APがAPによって設定されたTXOPの一部又は全部を共有する場合に、TXOPの共有のためのトリガーフレームのGI And HE-LTFタイプ/トリガーされたTXOP共有モードサブフィールドは、TXOPの共有モードを示す。例えば、GI And HE-LTFタイプ/トリガーされたTXOP共有モードサブフィールドは、TXOPの共有がTXOPを設定したAPとの送受信においてのみ共有されるか、又はAPの他に第3STA(さらに他のSTA)との送受信においても共有されるかを示す。すなわち、GI And HE-LTFタイプ/トリガーされたTXOP共有モードサブフィールドの値が「1」である場合に、共有されたTXOPの間にSTAはAPにのみPPDUを送信できる。しかし、GI And HE-LTFタイプ/トリガーされたTXOP共有モードサブフィールドの値が「2」である場合に、共有されたTXOPの間にSTAはAPの他に別のSTAにもPPDUを送信することができる。すなわち、GI And HE-LTFタイプ/トリガーされたTXOP共有モードサブフィールドの値が「2」である場合に、共有されたTXOPの間にSTAはP2P通信も行うことができる。
下表1は、GI And HE-LTFタイプ/トリガーされたTXOP共有モードサブフィールドの値によるTXOP共有の有無及びモードの一例を示す。
図20は、本発明の一実施例に係るTXOPの共有及びNAV設定と関連した方法を示す図である。
図20の実施例は、図19で説明した動作を行い難い問題とそれに対する解決方法を説明する実施例であり得る。図19で説明した内容は省略されてよい。
本発明の一実施例によれば、STAは、受信したフレーム又は受信したPPDUが含むデュレーション情報に基づいてNAV(network allocation vector)を設定できる。NAVが設定されたか否かに基づいて、virtual CS(carrier sense)結果がidleであるか、busyであるかが決定されてよい。NAV値が0である場合に、virtual CS結果がidleであってよい。NAV値が0よりも大きい場合に、virtual CS結果がbusyであってよい。Physical CSは、CCA(clear channel assessment)であってよい。仮にvirtual CS又はphysical CSの少なくとも一つがbusyである場合に、CS結果はbusyであってよい。仮にvirtual CSとphysical CSの両方がidleである場合に、CS結果はidleであってよい。また、STAがNAVを多数含む場合が存在してよい。例えば、STAは、intra-BSS NAVとbasic NAVを含んでよい。Intra-BSS NAVは、intra-BSSフレーム又はintra-BSS PPDUによって設定されるNAVであってよい。Regular NAVは、inter-BSSフレーム又はinter-BSS PPDU又はintra-BSSなのかinter-BSSなのかが判断できないフレーム又はPPDUによって設定されるNAVであってよい。また、intra-BSS NAV、basic NAVのうち少なくとも一つが0よりも大きい値である場合に、virtual CSはbusyであってよい。又は、intra-BSS NAV、basic NAVのうち少なくとも一つが0よりも大きい値である場合に、NAVが0よりも大きい値であるといえる。intra-BSS NAV、basic NAVの両方が0である場合に、virtual CSはidleであってよい。又は、intra-BSS NAV、basic NAVの両方が0である場合に、NAVが0であるといえる。
あるSTAにとって、intra-BSSフレーム又はintra-BSS PPDUは、前記STAと同じBSSから送信されたと判断されるフレーム又はPPDUであってよい。あるSTAにとって、inter-BSSフレーム又はinter-BSS PPDUは、前記STAと異なるBSSから送信されたと判断されるフレーム又はPPDUであってよい。また、同じBSSから送信されたか、或いは異なるBSSから送信されたかに対する判断は、PPDUのプリアンブルが含むBSS colorフィールド、MAC headerが含むaddressフィールドなどに基づいて決定されてよい。例えば、BSS colorフィールド又はaddressフィールドが同じBSSに該当する値である場合に、intra-BSSフレーム又はintra-BSS PPDUと判断できる。また、BSS colorフィールド又はaddressフィールドが同じBSSに該当する値を含まない場合に、inter-BSSフレーム又はinter-BSS PPDUと判断できる。前記addressフィールドは、RAフィールド、TAフィールド、BSSIDフィールドなどを含んでよい。
一実施例によれば、STAは、受信したフレームのリソース割り当てフィールド(Resource Allocation(RA) field)が自分のMAC addressでない場合に、前記受信したフレームに基づいてNAVを設定できる。又は、STAは、受信したトリガーフレームに基づいてNAVを設定できる。より具体的には、STAは、受信したintra-BSSフレームであるトリガーフレームに基づいてNAVを設定できる。このとき、NAVはintra-BSS NAVであってよい。このとき、前記トリガーフレームが前記STAをトリガーするか否かに関係なくNAVを設定できる。又は、STAは、受信したフレーム又は受信したPPDUが前記STAから即刻の応答を指示しない場合にNAVを設定できる。
本発明の一実施例によれば、CSがbusyである場合に、STAはフレーム又はPPDUを送信できないことがある。
本発明の一実施例によれば、NAVが0より大きい値に設定されたSTAは、フレーム又はPPDUを送信できないことがある。より具体的には、NAVが0より大きい値に設定されたSTAは、既に設定された条件を満たさない場合に、フレーム又はPPDUを送信できないことがある。
一実施例によれば、STAは、受信したフレームが前記STAにアドレスされており、即刻の応答を要求する場合に、NAVに関係なく(又は、NAVを考慮しないで)送信することが可能である。より具体的には、前記受信したフレームはRTSフレームでなく、トリガーフレームでなくてよい。すなわち、STAは、NAVが0より大きい値に設定されても、受信したフレームが前記STAにアドレスされており、即刻の応答を要求する場合に、NAVに関係なく送信することが可能である。また、フレームがSTAにアドレスされた場合は、前記フレームのRAフィールドが前記STAのaddressとして設定された場合を含んでよい。又は、フレームがSTAにアドレスされた場合は、前記フレームが、前記STAに該当するidentifierを含む場合を含んでよい。前記identifierは、MAC address、AID(association ID)、MAC addressに基づくID、AIDに基づくIDなどを含んでよい。
さらに他の実施例によれば、STAは、受信したフレームがTXOP holderから送信された場合に、NAVに関係なくそれに対する応答を送信することが可能である。このとき、前記NAVは、前記TXOP holderが送ったフレーム又はPPDUによって設定されたNAVであってよい。又は、前記NAVは、intra-BSS NAVであってよい。また、前記受信したフレームは、RTSフレームであってよい。フレームがTXOP holderから送信されたことは、前記フレームが含むTAフィールドに基づいて判断することができる。STAは、TXOP holder addressを保存することができる。仮にSTAがTXOP holderの送信したRTSフレームを受信し、前記RTSフレームが前記STAにアドレスされた場合に、NAVを考慮しないでRTSフレームに応答できる。このとき、RTSフレームに対する応答としてCTSフレームを送信できる。
さらに他の実施例によれば、STAは、トリガーフレームを受信した場合に、NAVに関係なくそれに対する応答を送信することが可能である。このとき、前記NAVは、intra-BSS NAVに限定されてよい。したがって、STAは、同じBSSのSTA又は同じBSSのAPによってNAVが設定された場合に、トリガーフレームによって応答が指示されるとき、NAVに関係なくそれに対する応答を送信することが可能である。STAはトリガーフレームを受信した場合に、intra-BSS NAVは考慮し、basic NAVは考慮しないで、それに対する応答を送信するか否かを決定することが可能である。また、STAがトリガーフレームを受信したとき、CS結果に基づいて前記トリガーフレームに対する応答を送信するか否かを決定することが可能である。例えば、トリガーフレームは、前記トリガーフレームを受信したとき、応答を送信するか否かをCS結果に基づいて決定するか否かを指示するシグナリングを含んでよい。例えば、前記シグナリングは、図16に示したCS Requiredサブフィールドであってよい。仮にCS RequiredサブフィールドがCS結果に基づいて応答するか否かを決定することと指示する場合に、STAは、virtual CSとphysical CSがidleを示す場合にトリガーフレームに対して応答し、virtual CS又はphysical CSがbusyを示す場合にトリガーフレームに応答しなくてよい。このとき、virtual CSでintra-BSS NAVは考慮せず、basic NAVを考慮することが可能である。また、仮にCS RequiredサブフィールドがCS結果に基づかないで応答することを指示する場合に、STAは、CS結果確認無しでトリガーフレームに対して応答することが可能である。
図19の実施例において、modified MU-RTSフレームを受信したSTAはNAVが設定されたため、共有されたTXOPの間に、CTSフレームでないフレームを送信することが不可能なことがある。図20でこれについてさらに説明する。
図20と関連して図19で説明した内容は省略されてもよい。図20を参照すると、STA1とSTA2が存在してよく、互いに結合(association)されていてよい。また、STA1はAPであってよい。STA2はnon-AP STAであってよい。STA1は、MU-RTSフレームを送信できる。また、STA2は、前記MU-RTSフレームに応答してCTSフレームを送信できる。このとき、STA2がCTSフレームを送信したことは、STA2のphysical CS結果がidleであり、basic NAVが設定されていないからであってよい。又は、STA2がCTSフレームを送信したことは、STA2が、自分にアドレスされ、即刻の応答を要求するフレームを受信したからであってよい。このとき、MU-RTSフレームとCTSフレームの交換(exchange)の他に別のフレーム交換が起きる場合にも、STA2は、STA1から受信したフレームに基づいて、前記フレームがSTA2にアドレスされ、即刻の応答を要求しているため、応答するフレームを送信することが可能である。また、STA2は、MU-RTSフレーム又はSTA1が送信したMU-RTSフレームの他に別のフレームに基づいてNAVを設定していてもよい。このとき、NAVはintra-BSS NAVであってよい。
また、STA1はSTA2にTXOP共有(sharing)を行うことができる。すなわち、STA1は、modified MU-RTSフレームをSTA2に送信することができる。このとき、前述したように、STA2は、shared TXOPを用いて、1)CTSフレームを送信し、続いて他のフレームを送信したり、2)CTSフレーム送信無しで他のフレームを送信してよい。ところが、このとき、NAVが設定されているため、STA2はフレームを送信し難いことがある。例えば、STA2は、STA1がshared TXOPを割り当てる前に、TXOPを得るために送信したフレームによってNAVが設定されていることがあり得る。すなわち、STA2は、STA1がmodified MU-RTSフレームを送信する前に送信したフレームを受信し、NAVが設定されていることがあり得る。又は、STA2は、自分にアドレスされたmodified MU-RTSフレームを受信する前に、同じTXOPの間に他のSTAから送信されたフレームを受信し、NAVが設定されていることがあり得る。又は、STA2は、自分にアドレスされたmodified MU-RTSフレームに基づいてNAVが設定されていることがあり得る。すなわち、STA2は、shared TXOPを用いる際に、少なくともmodified MU-RTSフレームを受信するはずであるため、NAVが設定されていることがある。このため、STA2はshared TXOPを活用してフレームを送信し難いことがある。
したがって、本発明の一実施例によれば、TXOP共有を受けたSTAは、NAVに関係なくフレームを送信することができる。例えば、TXOP共有を受けたSTAは、共有されたTXOPの間にNAVに関係なくフレームを送信することができる。例えば、TXOPが共有されたSTAは、NAVが設定されていても(又は、NAVが0より大きい場合でも)フレームを送信できる。より具体的な実施例によれば、このとき、NAVは、intra-BSS NAVに限定されることが可能である。例えば、TXOPが共有されたSTAは、intra-BSS NAVに関係なくフレームを送信することが可能である。また、TXOPが共有されたSTAは、basic NAVが設定されている場合に、フレームを送信できないことがある。又は、TXOPが共有されたSTAは、結合されたAPが送ったフレーム又はPPDUによって設定されたNAVに関係なくフレームを送信することができる。例えば、TXOPが共有されたSTAのNAVが結合されたAPでないSTAが送ったフレームによって設定された場合に、共有されたTXOPの間にフレームを送信できないことがある。
すなわち、STAは、TXOPが共有された場合に、共有されたTXOP内に設定されたNAVに関係なくPPDUを送信することができる。具体的には、APがTXOPの共有のためにトリガーフレーム(modified MU-RTSフレーム又はMU-RTS TXSトリガーフレーム)を送信した場合に、共有されたTXOP内にAPによってNAVが設定されてよい。この場合、TXOPが共有されたSTAは、共有されたTXOP内で設定されたNAVであるがため、PPDUの送信が不可能になることがある。したがって、TXOPが共有されたSTAは、共有されたTXOP内にTXOPを共有したAPによって設定されたNAVを無視してPPDUを送信することができる。
本発明において、フレームと表示したものは、フレームを含むPPDUに代えて発明を適用することもできる。
また、このとき、TXOP共有されたSTAがNAVに関係なく送信するフレームは、前のPPDUからSIFS後に送信する場合であってよい。
さらに他の実施例によれば、TXOP共有されたSTAがフレームを送信するとき、前のPPDUからPIFS後にフレームを送信する場合には、NAVを考慮することが可能である。
図20を参照すると、STA2は、MU-RTSフレーム又はmodified MU-RTSフレームに基づいてNAVが設定されてよい。例えば、intra-BSS NAVが設定されてよい。又は、STA2は、intra-BSSフレームに基づいてNAVが設定されてよい。又は、STA2は、結合されたAPが送信したフレームに基づいてNAVが設定されてよい。本実施例において、NAVとは、上記のようなNAVを総称するものであってよい。STA1はSTA2にTXOP共有を行うことができる。STA2は、modified MU-RTSフレームによってTXOP共有を受けることができる。STA2は、shared TXOPでフレームを送信する時に、NAVに関係なくフレームを送信することが可能である。この時に送信するフレームは、一実施例によれば、受信したmodified MU-RTSフレームの直後に送信したCTSフレームの直後に送信するフレームであってよい。さらに他の実施例によれば、この時に送信するフレームは、受信したmodified MU-RTSフレームの直後に送信するフレームであってよい。また、一実施例によれば、STA2が送信するフレームは、modified MU-RTSフレームを送信したSTAに送るフレームであってよい。すなわち、送信するフレームのRAフィールドが、受信したmodified MU-RTSフレームのTAフィールドの値に設定されてよい。又は、送信するフレームのRAフィールドが、APのMAC addressに設定されてよい。他の実施例によれば、STA2が送信するフレームは、STA3に送信するフレームであってよい。また、フレームを直後に送信するということは、前記フレームを含むPPDUの送信開始時点が、前のPPDUの終わりからSIFS後である場合を意味できる。
図21は、本発明の一実施例に係るTXOPの共有及びCTSフレームの送信を示す図である。
図21の実施例は、図19及び図20で説明した問題を解決するための方法であってよい。したがって、前述した内容は説明を省略してもよい。
本発明の一実施例によれば、NAVを考慮して共有されたTXOPの間にフレームを送信し難い問題を解決するために、NAVに関係なく応答を送信できる条件が満たされるようにフレームシーケンスを続けていくことができる。
本発明の実施例によれば、TXOP共有を受けたSTAは、modified MU-RTSフレームに対する応答としてCTS-to-selfフレームを送信することができる。CTS-to-selfフレームは、RAフィールドが、前記CTS-to-selfフレームを送信するSTAのMAC addressに設定されたCTSフレームであってよい。このような場合、TXOP共有をするSTAは、modified MU-RTSフレームを送信した後に、TXOP共有を受けるSTAのMAC addressを含むフレームを受信すると、共有されたTXOP割り当てに成功したと判断できる。
図21を参照すると、STA2はSTA1からmodified MU-RTSフレームを受信することができる。また、STA2は、前記modified MU-RTSフレームの直後にCTS-to-selfフレームを送信することができる。すなわち、STA2は、CTSフレームのRAフィールドを前記STA2のMAC addressに設定してCTSフレームを送信することができる。このような場合、STA2の送ったCTS-to-selfフレームに対して、自分にアドレスされ、即刻の応答を要求するフレームであると見なすことができる。又は、STA2は、CTS-to-selfフレームを送信したことに対して、自分にアドレスされ、即刻の応答を要求するフレームを受信したと見なすことができる。したがって、STA2は、NAVが設定されていても、CTS-to-selfフレームの直後にフレームを送信することができる。
本発明の実施例によれば、RTSフレーム又はMU-RTSフレームに対する応答として送信するCTSフレームのRAフィールドは、前記RTSフレーム又は前記MU-RTSフレームのTAフィールド値又はTAフィールド値においてIndividual/Group bitを0に設定した値に設定できる。ところが、図21で説明したようなCTS-to-selfフレームを送信するために、追加のCTSフレームのRAフィールド設定方法が定義されてよい。例えば、modified MU-RTSフレームに対する応答として送信するCTSフレームのRAフィールドは、前記CTSフレームを送信するSTAのMAC addressに設定されることが可能である。
本発明の一実施例によれば、TXOP共有を受けたSTAは、共有されたTXOP内でリカバリー(recovery)を行うことが可能である。すなわち、TXOP共有を受けたSTAは、共有されたTXOP内で自分の送信したフレームが失敗した場合にリカバリーを行うことが可能である。例えば、TXOP共有を受けたSTAは、共有されたTXOP内で自分の送信したフレームが失敗した場合に、PIFS以後にフレームを送信することが可能である。本発明の実施例によれば、TXOP holderは、リカバリーを行うことが可能である。これに加え、TXOP holderがTXOP共有を行った場合に、TXOP共有を受けたSTAがリカバリーを行うことが可能である。すなわち、1)TXOP responderであるか、2)TXOP holderでもTXOP responderでもないSTAがTXOP共有を受けたSTAになる場合にリカバリーを行うことが可能である。また、TXOP共有を受けたSTAは、modified MU-RTSフレームを受信した以後に最初のCTSフレームでないフレームを送信した場合にも、前記CTSフレームでないフレームが失敗するとリカバリー動作を行うことが可能である。例えば、TXOP holderは、シーケンスの最初に送信したフレームが失敗した場合にリカバリー動作を行うことができず、このとき、TXOPが得られなかったといえる。しかし、TXOP共有を受けたSTAは、共有されたTXOPで送信した最初のCTSフレームでないフレームが失敗する場合にもリカバリー動作を行うことができる。
図21を参照すると、STA2は、図面に表示したULフレームを送信し、それが失敗した場合にリカバリー動作を行うことができる。すなわち、STA2は、ULフレームを送信し、図面に表示したDLフレームを受信していない場合にフレームを再び送信することができる。このとき、再び送信するフレームは、図面に表示した失敗したULフレームを含むPPDUの終わりからPIFS後に送信を始めることができる。また、リカバリー中にチャネルがidleであるか否かが確認できる。また、TXOP共有を受けたSTAが行うリカバリー動作では、virtual CSを考慮せず、physical CSのみを考慮できる。
図22は、本発明の一実施例に係るTXOPの共有のためのトリガーフレームの一例を示す図である。
図19で説明したように、modified MU-RTSフレームであるか否かは、ユーザ情報フィールドの個数に基づくことができる。ところが、802.11ax標準で定義したトリガーフレームは、以後の標準で機能が拡張されることを考慮しないで設計されたものであり得る。したがって、例えば、図16(b)に示した共通情報フィールド(Common Info field)は、拡張された機能を含むにはシグナリング空間が不足し得る。したがって、本発明の一実施例によれば、既に設定されたAID12サブフィールド値を含むユーザ情報フィールドは、図16(c)に示したのと異なるフォーマットを有してよい。また、既に設定されたAID12サブフィールド値を含むユーザ情報フィールドは、前記ユーザ情報フィールドを含むトリガーフレームの全ての受信者又は一つ以上の受信者に該当する情報を含んでよい。例えば、既に設定されたAID12サブフィールド値を含むユーザ情報フィールドは、PHY version ID、帯域幅extension、帯域幅、spatial reuse、U-SIG reserved bitsのうち少なくとも一つの情報を含んでよい。また、前記既に設定されたAID12サブフィールド値は、実際AIDとして割り当てられない値に基づくことができる。前記既に設定されたAID12サブフィールド値は、実際AIDとして割り当てられない値の12LSBsであってよい。例えば、前記既に設定されたAID12サブフィールド値は、2007であってよい。
また、先に言及した拡張された機能は、例えば、広くなった帯域幅を含んでよい。例えば、帯域幅が最大で160MHzから最大で320MHzに拡張されてよい。また、拡張された機能は、U-SIGフィールドを生成するための情報を含んでよい。
したがって、本発明の実施例によれば、modified MU-RTSフレーム又は共有されたTXOP内においても拡張された機能を使用するために、modified MU-RTSフレームは、先に言及した既に設定されたAID12サブフィールド値を含むユーザ情報フィールドを含んでよい。
本発明の実施例によれば、modified MU-RTSフレームは、ユーザ情報フィールドを一つも含まないか、先に言及した既に設定されたAID12サブフィールド値を含むユーザ情報フィールドのみをユーザ情報フィールドに含んでよい。すなわち、受信したトリガーフレームがユーザ情報フィールドを一つも含まないか、先に言及した既に設定されたAID12サブフィールド値を含むユーザ情報フィールドのみをユーザ情報フィールドに含む場合に、前記トリガーフレームをmodified MU-RTSフレームとして判断できる。又は、受信したMU-RTSフレームがユーザ情報フィールドを一つも含まないか、先に言及した既に設定されたAID12サブフィールド値を含むユーザ情報フィールドのみをユーザ情報フィールドに含む場合に、前記MU-RTSフレームをmodified MU-RTSフレームとして判断できる。このとき、TXOP共有を受けるSTAは、トリガーフレームのRAフィールドによって指示されてよい。
図22を参照すると、modified MU-RTSフレームは、タイプサブフィールドがMU-RTSに設定されてよい。また、modified MU-RTSフレームは、ユーザ情報フィールドが1個存在することが可能であり、このとき、前記ユーザ情報フィールドが含むAID12サブフィールドは、既に設定された値に設定されてよい。このとき、前記既に設定された値はAIDとして割り当てられない値であってよい。また、前記既に設定された値は、前記modified MU-RTSフレームのRAフィールド値をMAC addressとして有するSTAのAIDの12LSBsと異なる値であってよい。例えば、前記既に設定された値は、2007であってよい。又は、modified MU-RTSフレームは、ユーザ情報フィールドを一つも含まないことが可能である。すなわち、トリガーフレームを受信したSTAは、前記トリガーフレームのTypeがMU-RTSフレームとして設定された場合に、前記トリガーフレームがユーザ情報フィールドを一つも含まないか、又は既に設定された値のAID12サブフィールドを含むユーザ情報フィールドのみを含む場合に、前記トリガーフレームをmodified MU-RTSフレームとして判断できる。
図23は、本発明の一実施例に係るNAVタイムアウト(time out)を示す図である。
本発明の一実施例によれば、STAは、設定したNAVを解除(reset)することが可能である。例えば、RTSフレーム又はMU-RTSフレームに基づいてNAVを設定した場合に、NAVを解除することが可能である。より具体的には、RTSフレーム又はMU-RTSフレームに基づいてNAVを設定した場合に、既に設定された時間の間にPPDU受信を成功的に開始できなかった場合にNAVを解除することが可能である。このような動作をNAVタイムアウト又はNAVTimeoutと呼ぶことができる。既に設定された時間をNAVTimeout period又はNAVタイムアウト周期と呼ぶことができる。NAVTimeout periodは、RTSフレーム又はMU-RTSフレームに該当するPHY-RXEND.indication primitiveを受けた時に始まってよい。
本発明の実施例において、RTSフレーム又はMU-RTSフレームに基づいてNAVを設定した場合は、直近のNAVアップデートがRTSフレーム又はMU-RTSフレームに基づいてなされた場合を意味できる。仮にSTAがRTSフレーム又はMU-RTSフレームから受信したデュレーション情報が、前記STAの現在NAV値よりも大きい場合に、前記RTSフレーム又はMU-RTSフレームに基づいてNAVを設定又はアップデートすることができる。前記デュレーション情報は、MAC headerが含むDuration/IDフィールドに基づいて得るか、PPDUのプリアンブルに含まれたTXOPデュレーション又はTXOPフィールドに基づいて得ることができる。
また、本発明の実施例において、PPDU受信を成功的に始めた場合に、PHY-RXSTART.indication primitiveを受けることができる。又は、PPDU受信を成功的に始めた場合に、PHY-RXSTART.indication primitiveが発行されてよい。PHY-RXSTART.indication primitiveは、PHYからMACに伝達されるものであってよい。例えば、PHYがPPDUの有効な(valid)開始を受信した場合にPHY-RXSTART.indication primitiveが生成されてよい。また、PPDUの有効な開始を受信したことは、有効なPHY headerを受信した場合を意味できる。また、PHY-RXSTART.indication primitiveは、PPDUフォーマットを判断した後に生成されることが可能である。PHY-RXSTART.indication primitiveが生成された場合に、PPDUの長さ又はPPDUのプリアンブルが指示する長さの間に、PHYはphysical mediumをbusy statusとして維持することができる。仮にPHY-RXSTART.indication primitiveが生成されると、PPDUの中間に受信に失敗しても、PPDUの長さ又はPPDUのプリアンブルが指示する長さの間に、PHYはphysical mediumをbusy statusとして維持できる。また、PPDU受信を終了した場合にPHY-RXEND.indicationが生成されてよい。
本発明の実施例によれば、先に言及したNAVタイムアウト周期は、RTSフレーム又はMU-RTSフレームに対する応答時間に基づくものであってよい。すなわち、RTSフレーム又はMU-RTSフレームに対する応答がCTSフレームである場合に、NAVタイムアウト周期は、CTSフレーム時間に基づくものであってよい。前記CTSフレーム時間をCTS_Timeと示すことができる。又は、RTSフレーム又はMU-RTSフレームに対する応答時間をCTS_Timeと示すことができる。このとき、RTSフレーム又はMU-RTSフレームに対する応答時間は、前記応答を含むPPDUの長さを意味できる。
一実施例によれば、NAVタイムアウト周期は、次のうち少なくとも一つに基づくものであってよい。
1)CTS_Time
2)aSIFSTime
3)aRxPHYStartDelay
4)aSlotTime
一実施例によれば、CTS_Timeは、既に設定された比率(rate)に基づいて計算することが可能である。すなわち、CTS_Timeは、既に設定された比率に基づいて計算したCTSフレームの長さであってよい。又は、すなわち、CTS_Timeは、既に設定された比率に基づいて計算したCTSフレームを含むPPDUの長さであってよい。例えば、既に設定された比率は6Mbpsであってよい。例えば、CTS_Timeは、6Mbpsのデータ比率(data rate)に基づいて計算することが可能である。又は、既に設定されたrateは、NAVを設定するようにしたRTSフレーム又はMU-RTSフレームの比率であってよい。又は、既に設定されたrateは、NAVを設定するようにしたRTSフレーム又はMU-RTSフレームが指示する比率であってよい。
一実施例によれば、aSIFSTimeは、SIFS長さであってよい。例えば、aSIFSTimeは2.4GHz帯域で動作する場合に、10usであってよい。例えば、aSIFSTimeは、5GHz帯域又は6GHz帯域で動作する場合に、16usであってよい。
一実施例によれば、aRxPHYStartDelayは、PPDUの始めから受信者(receiver)がPHY-RXSTART.indication primitiveを生成するまでにかかる遅延(delay)であってよい。例えば、aRxPHYStartDelayは、PPDUの始めからPPDU formatを判断するまでにかかる時間であってよい。例えば、aRxPHYStartDelayは、PPDUフォーマットによって異なってよい。aRxPHYStartDelayは、non-HT PPDUに対して20usであってよい。また、aRxPHYStartDelayは、HT-mixed formatのHT PPDUに対して28usであってよい。また、aRxPHYStartDelayは、HT-greenfield formatのHT PPDUに対して24usであってよい。また、aRxPHYStartDelayは、VHT PPDUに対して(36+4*(the maximum possible value for N_VHT-LTF supported)+4)usであってよい。N_VHT-LTFは、VHT-LTFの個数であってよい。また、aRxPHYStartDelayは、HE SU PPDU又はHE TB PPDUに対して32usであってよい。また、aRxPHYStartDelayは、HE ER SU PPDUに対して40usであってよい。また、aRxPHYStartDelayは、HE MU PPDUに対して(32+4*N_HE-SIG-B)usであってよい。N_HE-SIG-Bは、HE-SIG-BフィールドのOFDMシンボル個数であってよい。また、aRxPHYStartDelayは、EHT MU PPDU又はEHT TB PPDUに対して32usであってよい。
一実施例によれば、NAV timeout periodは、((2*aSIFSTime)+(CTS_Time)+aRxPHYStartDelay+(2*aSlotTime))であってよい。
本発明の実施例によれば、RTSフレームは、CTSフレームを指示するフレームであってよい。又は、RTSフレームは、単一(single)STAからCTSフレームを指示するフレームであってよい。RTSフレームは、フレームControlフィールド、デュレーションフィールド、RAフィールド、TAフィールド、FCSフィールドを含んでよい。デュレーションフィールドは、前記デュレーションフィールドを受信するSTAがNAVを設定するための時間情報が含まれてよい。また、RAフィールドには、意図した即刻の応答者(intended immediate recipient)のアドレスが含まれてよい。例えば、STAが受信したRTSフレームが含むRAフィールドが前記STAのアドレスである場合に、前記RTSフレームに対してCTSフレームで応答することが可能である。また、フレームがRTSフレームであることは、前記フレームが含むフレームControlフィールドに基づいて判断されてよい。例えば、フレームがRTSフレームであることは、前記フレームが含むフレームControlフィールドに含まれたTypeサブフィールド、Subtypeサブフィールド基づいて判断されてよい。例えば、Typeサブフィールドが01(B3 B2)であり、Subtypeサブフィールドが1011(B7 B6 B5 B4)である場合に、前記Typeサブフィールド及び前記Subtypeサブフィールドを含むフレームがRTSフレームであることを指示できる。例えば、RTSフレームはControlフレームであってよい。
CTSフレームは、フレームControlフィールド、デュレーションフィールド、RAフィールド、FCSフィールドを含んでよい。デュレーションフィールドは、前記デュレーションフィールドを受信するSTAがNAVを設定するための時間情報が含まれてよい。例えば、Typeサブフィールドが01(B3 B2)であり、Subtypeサブフィールドが1100(B7 B6 B5 B4)である場合に、前記Typeサブフィールド及び前記Subtypeサブフィールドを含むフレームがCTSフレームであることを指示できる。例えば、CTSフレームはControlフレームであってよい。
図23の1番目のシーケンスを参照すると、STA1、STA2、STA3が存在してよい。また、STA1がRTSフレーム又はMU-RTSフレームをSTA2に送信できる。例えば、前記RTSフレーム又は前記MU-RTSフレームのRAフィールドがSTA2のアドレスに設定された場合に、前記RTSフレーム又は前記MU-RTSフレームはSTA2に送信されるものであってよい。又は、前記MU-RTSフレームが含むUser InfoフィールドがSTA2を指示する場合に、前記MU-RTSフレームはSTA2に送信されるものであってよい。仮にSTA2が前記RTSフレーム又は前記MU-RTSフレームを成功的に受信した場合に、CTSフレームで応答することが可能である。このとき、STA2がキャリアセンス(carrier sense,CA)結果に基づいて応答することができる。また、STA3が前記RTSフレーム又は前記MU-RTSフレームを受信する場合に、前記RTSフレーム又は前記MU-RTSフレームが含むデュレーション情報又は前記RTSフレーム又は前記MU-RTSフレームを含むPPDUが含むデュレーション情報に基づいて、STA3はNAVを設定できる。また、STA1がSTA2の送信したCTSフレームを成功的に受信した場合に、STA1はSTA2にフレームを送信できる。また、STA3はNAVを設定した後、STA2が送信したCTSフレーム又はSTA1がSTA2に送信したフレームを受信していてよい。このような場合、STA3は、NAVTimeout period内にPHY-RXSTART.indication primitiveを受けることができる。したがって、STA3が設定したNAVを解除できないことがある。
図23の2番目のシーケンスを参照すると、STA1、STA2、STA3が存在してよい。また、STA1がRTSフレーム又はMU-RTSフレームをSTA2に送信することができる。仮にSTA2が前記RTSフレーム又は前記MU-RTSフレームを成功的に受信できなかった場合に、CTSフレームで応答できないことがある。又は、STA2が前記RTSフレーム又は前記MU-RTSフレームを成功的に受信したが、キャリアセンス結果に基づいてCTSフレームで応答できないことがある。このような場合、STA1がSTA2に送るフレームシーケンスが続かないことがある。
また、STA3が前記RTSフレーム又は前記MU-RTSフレームを受信する場合に、前記RTSフレーム又は前記MU-RTSフレームが含むデュレーション情報又は前記RTSフレーム又は前記MU-RTSフレームを含むPPDUが含むデュレーション情報に基づいて、STA3はNAVを設定できる。また、STA3はNAVを設定した後に、STA2が送信したCTSフレーム又はSTA1がSTA2に送信したフレームを受信することができないことがある。このような場合、STA3は、NAVTimeout period内にPHY-RXSTART.indication primitiveを受信できない。したがって、STA3が設定したNAVを解除することができる。これにより、シーケンスが続かなかったにもかかわらず、STA3がNAVを維持することからチャネルに接続(access)できない問題を解決することができる。
図24は、本発明の一実施例に係るTXOPの共有及びNAVタイムアウトを示す図である。
図24を参照すると、前述したように、STA1がSTA2にTXOP共有を行うことが可能である。STA1は、TXOP共有をするSTAであり、STA2は、TXOP共有を受けるSTAであってよい。STA1はSTA2にシーケンスの1番目のフレームを送信することができる。図24を参照すると、STA1がSTA2に送信するシーケンスの1番目のフレームはMU-RTSフレームであってよい。また、前記MU-RTSフレームに対する応答であるCTSフレームが送信されてよい。
例えば、STA2を含むSTAからCTSフレームが送信されてよい。STA1はTXOPを得ることができる。また、STA3は、前記MU-RTSフレームと前記CTSフレームを成功的に受信できないことがある。STA1は、modified MU-RTSフレームをSTA2に送信できる。すなわち、STA1はSTA2にTXOP共有を行うことができる。また、STA3は、前記modified MU-RTSフレームを成功的に受信することができる。したがって、STA3は前記modified MU-RTSフレームに基づいてNAVを設定することができる。この場合、STA3は、MU-RTSフレームに基づいてNAVを設定したものであってよい。また、前述したTXOP共有シーケンスによれば、modified MU-RTSフレームに対してSTA2が、1)CTSフレームを送信し、CTSフレームを送信した直後にフレームを送信することができる。又は、modified MU-RTSフレームに対してSTA2が、2)CTSフレームを送信せず、フレームを送信することができる。また、STA3がSTA2からのフレーム又はPPDUを受信できないことがある。例えば、STA3がSTA2からhiddenである位置に存在し得る。例えば、STA2が送信する電力がSTA3に受信される程度に十分でないことがあり得る。このような場合、STA3は、NAVタイムアウト周期の間にPPDUを受信できないことがある。NAV timeout periodは、CTS_Timeに基づいて決定されるためであり得る。すなわち、STA2がCTSフレーム送信後にフレームを送信する場合に、STA3は、前記フレームが送信される間にNAVTimeout periodが終わるはずである。又は、STA2がCTSフレーム送信無しでフレームを送信する場合に、前記フレームはCTSフレームよりも長い可能性が高いため、STA3は、前記フレームが送信される間にNAVTimeout periodが終わるはずである。したがって、STA3はNAVを解除することが可能である。仮にSTA3がNAVを解除すると、STA3がチャネルに接続し、共有されたTXOPの間のシーケンスを妨害することがある。
図25は、本発明のさらに他の実施例に係るTXOPの共有及びNAVタイムアウトを示す図である。
図25を参照すると、APによってTXOPが共有された場合に、APによってTXOPが共有されたSTAでない他のSTA(第3STA)は、TXOPが共有されたSTAからCTSフレーム又は他のフレームが一定時間の間に送信されない場合にも、共有されたTXOPを解除しなくてよい。図25の実施例は、図23及び図24で説明した問題を解決するためのものであってよい。また、前述した内容は省略されてもよい。
具体的には、APから送信されたトリガーフレーム(例えば、MU-RTSフレーム)が、TXOPを共有するためのmodified MU-RTSフレーム又はMU-RTS TXSトリガーフレームであるか否かに基づいて、TXOPを解除するためのNAVタイムアウトが許容されたり或いは許容されなくてよい。すなわち、一般的に設定されたTXOPであるか又はAPによって設定されたTXOPの全部又は一部が共有されたTXOPであるかによって、TXOPが設定されたSTAでない他のSTAが設定されたTXOPを解除するためのNAVタイムアウトが許容されるか否かが決定されてよい。
例えば、設定されたTXOPの一部又は全部の共有のためのフレーム(modifited MU-RTSフレーム又はMU-RTS TXSトリガーフレーム)でないMU-RTSフレームに基づいてNAVが設定された場合に、NAVタイムアウトが許容されてよい。すなわち、STAがMU-RTSフレームに基づいてNAVを設定した場合に、前記MU-RTSフレームがmodified MU-RTSフレームでない場合に、NAVTimeout periodの間にPPDU受信を成功的に開始できなかった場合に、NAVを解除することが可能である。
しかし、設定されたTXOPの一部又は全部を共有するためのフレームであるmodified MU-RTSフレーム又はMU-RTS TXSトリガーフレームによってNAVが設定された場合に、NAVタイムアウトは許容されなくてよい。すなわち、STAがMU-RTSフレームに基づいてNAVを設定した場合に、当該MU-RTSフレームがTXOP共有のためのmodified MU-RTSフレーム又はMU-RTS TXSトリガーフレームであれば、STAはNAVTimeout periodの間にPPDU受信を成功的に開始できなくても、NAVを解除することが不可である。
すなわち、STAがNAVアップデートのために直近に受信したフレームが、TXOP共有のためのフレームであるmodified MU-RTSフレーム又はMU-RTS TXSトリガーフレームであれば、STAは、NAVTimeoutが満了した後、NAVをリセットしてはならない。
受信したMU-RTSフレームがmodified MU-RTSフレームであるか否かの決定は、前述した実施例に従うことができる。例えば、MU-RTSフレームが含むGI And HE-LTF Typeサブフィールドに基づいて、modified MU-RTSフレームであるか否かが決定されてよい。例えば、GI And HE-LTF Typeサブフィールド値が0である場合に、前記GI And HE-LTF Typeサブフィールドを含むMU-RTSフレームは、modified MU-RTSフレームでなくてよい。また、GI And HE-LTF Typeサブフィールド値が0でない場合に、前記GI And HE-LTF Typeサブフィールドを含むMU-RTSフレームは、modified MU-RTSフレームであってよい。例えば、GI And HE-LTF Typeサブフィールド値が1又は2である場合に、前記GI And HE-LTF Typeサブフィールドを含むMU-RTSフレームは、modified MU-RTSフレームであってよい。
本発明の実施例により、図24で説明した問題、すなわち、STAがmodified MU-RTSフレームに基づいてNAVを設定した後、NAV timeout動作を行うことによって共有されたTXOPのシーケンスを妨害する問題を防止することができる。
また、このような実施例を、802.11be標準以降の端末(EHT標準を含むその以後の標準の端末)が行い、802.11ax標準の端末(HE STA)は行うことができないことがある。HE STAがこれを行うことができなくても、上記の実施例により、説明した問題が発生する確率を減らすことができる。
図25を参照すると、STA1、STA2、STA3が存在してよい。また、STA1がSTA2にMU-RTSフレームを送信できる。例えば、STA1が、modified MU-RTSフレームでないMU-RTSフレームを送信できる。ところが、前記MU-RTSフレームの意図した受信者(intended receiver)であるSTA2が前記MU-RTSフレームに応答できないことがある。したがって、STA2がCTSフレームを送信できないことがある。また、STA3は、前記MU-RTSフレームに基づいてNAVを設定することができる。ところが、STA2がCTSフレームを送信できなかったため、STA3はNAVTimeout periodの間にPPDU受信を成功的に開始できていないことがある。この場合、NAV timeout動作に基づいて、STA3は、設定したNAVを解除することが可能である。これは、STA3がNAVを設定するようにしたフレームが、modified MU-RTSフレームでないMU-RTSフレームであるからである。
また、STA1がmodified MU-RTSフレームを送信することができる。図25では、modified MU-RTSフレームの前のフレームが省略されていてよい。前記modified MU-RTSフレームの意図した受信者であるSTA2が、前記modified MU-RTSフレームに応答できる。また、STA3は、前記modified MU-RTSフレームに基づいてNAVを設定できる。ところが、STA2が前記modified MU-RTSフレームに対して送信した応答をSTA3が受信できていないことがある。例えば、STA3にSTA2が送信した応答が十分に大きい電力で聞こえないからである。例えば、STA3とSTA2が遠く離れているからである。このような場合、STA3は、NAVTimeout periodの間にPPDU受信を成功的に開始できていないことがある。これは、STA2がmodified MU-RTSフレーム後に、CTSフレームを送信した後にフレームを送信したためであり得る。又は、これは、STA2がmodified MU-RTSフレーム後に、CTSフレームよりも長いフレームを送信したためであり得る。又は、これは、STA2がmodified MU-RTSフレーム後に、CTSフレームを含むPPDUよりも長いPPDUを送信したためであり得る。この場合、STA3は、NAV timeout動作に基づくNAVを解除する動作を行うことができないことがある。これは、STA3がNAVを設定するようにしたフレームが、modified MU-RTSフレームであるMU-RTSフレームであるためであり得る。
図26は、本発明のさらに他の実施例に係るTXOPの共有及びNAVタイムアウトを示す図である。
図26の実施例は、図23及び図24で説明した問題を解決するためのものであってよい。また、前述した内容は省略されてもよい。
本発明の一実施例によれば、MU-RTSフレームがmodified MU-RTSフレームであるか否かに基づいてNAV timeout periodが個別に決定されてよい。例えば、MU-RTSフレームがmodified MU-RTSフレームであるか否かに基づいてCTS_Timeが個別に決定されてよい。一実施例によれば、MU-RTSフレームがmodified MU-RTSフレームである場合に、NAV timeout periodは、MU-RTSフレームがmodified MU-RTSフレームでない場合のNAV timeout periodよりも長くてよい。本実施例において、MU-RTSフレームがmodified MU-RTSフレームである場合に、NAV timeout periodをextended NAVTimeout periodと呼ぶことができる。図23で説明したNAVTimeout periodとextended NAVTimeout periodは、同一時点に始まってよい。すなわち、MU-RTSフレームに該当するPHY-RXEND.indication primitiveを受けた時に始まってよい。図23で説明したNAVTimeout periodは、CTSフレーム時間に基づく時間であってよい。例えば、図23で説明したNAVTimeout periodは、CTSフレームを6Mbpsで送信するのにかかる時間に基づく時間であってよい。
本発明の実施例によれば、STAがmodified MU-RTSフレームに基づいてNAVを設定した場合に、extended NAVTimeout periodの間にPPDU受信を成功的に開始できなかった場合に、NAVを解除することが可能である。STAがmodified MU-RTSフレームに基づいてNAVを設定した場合に、図23で説明したNAVTimeout periodの間にPPDU受信を成功的に開始できなかった場合にもNAVを解除できないことがある。
また、STAがmodified MU-RTSフレームでないMU-RTSフレームに基づいてNAVを設定した場合に、図23で説明したNAVTimeout periodの間にPPDU受信を成功的に開始できなかった場合に、NAVを解除することが可能である。
本発明の実施例によれば、extended NAVTimeout periodは、modified MU-RTSフレームが含む長さ情報に基づいて決定されてよい。例えば、modified MU-RTSフレームが含む長さ情報に基づいてCTS_Timeが決定されてよい。又は、extended NAVTimeout periodは、modified MU-RTSフレームが含む長さ情報とmodified MU-RTSフレームに該当するrateに基づいて決定されてよい。例えば、modified MU-RTSフレームが含む長さ情報とmodified MU-RTSフレームに該当するrateに基づいてCTS_Timeが決定されてよい。例えば、modified MU-RTSフレームが含む長さ情報は、図16に示したUL Lengthサブフィールドに含まれてよい。さらに他の実施例において、modified MU-RTSフレームが含む長さ情報は、図16に示したUser Infoフィールドに含まれてよい。より具体的には、modified MU-RTSフレームが含む長さ情報は、図16に示したUser Infoフィールドのうち、TXOP共有を受けるSTAを指示するUser Infoフィールドに含まれてよい。
また、TXOP共有を受けたSTAは、modified MU-RTSフレームが含む長さ情報に基づいてPPDUを送信することができる。例えば、TXOP共有を受けたSTAは、modified MU-RTSフレームが含む長さ情報に基づいて、共有されたTXOPの最初のPPDUを送信できる。又は、TXOP共有を受けたSTAは、modified MU-RTSフレームが含む長さ情報に基づいて、共有されたTXOPのCTSフレームを含まない最初のPPDUを送信できる。共有されたTXOPのCTSフレームを含まない最初のPPDUは、CTSフレームを含むPPDU次の最初のPPDUであってよい。
図26を参照すると、STA1、STA2、STA3が存在してよい。また、STA1がSTA2にMU-RTSフレームを送信することができる。例えばSTA1がmodified MU-RTSフレームでないMU-RTSフレームを送信できる。ところが、前記MU-RTSフレームの意図した受信者であるSTA2が前記MU-RTSフレームに応答できないことがある。したがって、STA2がCTSフレームを送信できないことがある。また、STA3は、前記MU-RTSフレームに基づいてNAVを設定できる。ところが、STA2がCTSフレームを送信できなかったため、STA3はNAVTimeout periodの間にPPDU受信を成功的に開始できないことがある。この場合、NAV timeout動作に基づいて、STA3は、設定したNAVを解除することが可能である。これは、STA3がNAVを設定するようにしたフレームがmodified MU-RTSフレームでないMU-RTSフレームであるため、決定したNAVTimeout periodに基づく動作であってよい。すなわち、STA3がNAVを設定するようにしたフレームがmodified MU-RTSフレームでないMU-RTSフレームであるため、NAVTimeout periodを、CTSフレームを送信するのにかかる時間に基づいて決定することができる。
また、STA1がmodified MU-RTSフレームを送信することができる。図26は、modified MU-RTSフレームの前のフレームを省略したものであってよい。前記modified MU-RTSフレームの意図した受信者であるSTA2が、前記modified MU-RTSフレームに応答することができる。また、STA3は、前記modified MU-RTSフレームに基づいてNAVを設定することができる。ところが、STA2が前記modified MU-RTSフレームに対して送信した応答をSTA3が受信できないことがある。例えば、STA3にSTA2が送信した応答が十分に大きい電力で聞こえないためであり得る。例えば、STA3とSTA2が遠く離れているためであり得る。このような場合、STA3は、図23で説明したNAVTimeout periodの間にPPDU受信を成功的に開始できないことがある。しかし、このような場合、STA3は、extended NAVTimeout periodの間にPPDU受信を成功的に始めることができる。したがって、STA3は、NAV timeout動作を行わなくてよい。STA3が図23で説明したNAVTimeout periodが過ぎた時にNAV解除動作をせずに、extended NAVTimeout periodを待つことができたのは、STA3がNAVを設定するようにしたフレームがmodified MU-RTSフレームであるMU-RTSフレームであるためであり得る。
仮に前記modified MU-RTSフレームを受信したSTA2が応答できなかった場合に、STA1は、リカバリー(recovery)動作を行うことができる。したがって、STA3がNAV timeout動作をする前にPPDU受信を成功的に始めることができる。
又は、前記modified MU-RTSフレームを受信したSTA2が応答できなかった場合に、共有されたTXOPのシーケンスが絶えることがある。この場合、STA3は、NAV timeout動作を行い、実際フレーム交換が発生しない時に不要にNAVを設定していてチャネルに接続できない問題を解決することができる。
TXOP共有において、APによって設定されたTXOPの一部又は全部が共有されたスケジュールドSTAが、設定されたNAVによって送信を行い難い問題と解決方法について図20で説明した。さらに他の実施例に係る解決方法について図27を用いて説明する。以下、スケジュールドSTAとTXOPが共有されたSTAとは同じSTAであり、呼称は相互交換的に使われてよい。
図27は、本発明の一実施例によってTXOP共有が適用される時に、STA及びAPがNAVを適用することを示す図である。
TXOP共有において、スケジュールドSTAはNAVを設定しなくてよい。具体的には、TXOP共有において、スケジュールドSTAは、TXOP共有設定のためのMU-RTSフレームであるmodified MU-RTSフレーム又はMU-RTS TXSトリガーフレームに基づいてNAVを設定しなくてよい。TXOP共有設定のためのMU-RTSフレームを受信したSTAは、TXOP共有設定のためのMU-RTSフレームに基づいてNAVを設定しなくてよい。TXOP共有設定のためのMU-RTSフレームによってスケジュールされたSTAは、TXOP共有設定のためのMU-RTSフレームに基づいてNAVを設定しなくてよい。したがって、STAがトリガーフレームを受信し、トリガーフレームがSTAにTXOP共有をスケジュールする場合に、STAはトリガーフレームに基づいてNAVを設定しなくてよい。すなわち、トリガーフレームがTXOPを共有するためのトリガーフレームであるか否かによって、STAは、受信されたトリガーフレームに基づいてNAVを設定することができる。例えば、受信されたMU-RTSフレームがTXOPの共有のためのmodified MU-RTSフレーム又はMU-RTS TXSトリガーフレームである場合に、STAは、受信されたMU-RTSフレームに基づくNAVを設定しない。しかし、受信されたMU-RTSフレームがTXOPの共有のためのmodified MU-RTSフレーム又はMU-RTS TXSトリガーフレームでない場合に、STAは、受信されたMU-RTSフレームに基づくNAVを設定する。
また、TXOP共有において、スケジュールドSTAは、共有されたTXOP内で受信したフレームに基づいてNAVを設定しなくてよい。
この時、共有されたTXOP内とは、共有されたTXOPの期間(duration)が全て活用されない場合にも、共有されたTXOPが終了するまでのことを指すことができる。共有されたTXOPのスケジュールドSTAがPPDUを送信し、PPDUが即刻の応答を要請しないフレームのみを含む場合に、STAがPPDUを送信した時にTXOPが終了する。したがって、共有されたTXOP内は、TXOP共有が設定された時からTXOP共有のスケジュールドSTAが即刻の応答を要請しないフレームのみを含むPPDUを送信した時までであってよい。TXOP共有のスケジュールドSTAが、共有されたTXOPの終了をシグナルした場合に、共有されたTXOPが終了してよい。したがって、共有されたTXOP内は、TXOP共有が設定された時からTXOP共有のスケジュールドSTAが共有されたTXOPの終了をシグナルした時までであってよい。また、TXOP内は、TXOP共有が設定された時から共有されたTXOPデュレーションが経過した時までであってよい。又は、TXOP共有を受けたSTA(又は、TXOP共有をしたSTA)が共有されたTXOPが終了する旨のシグナリングを送受信した場合に、共有されたTXOPは終了してよい。この場合、共有されたTXOPとAPが共有のために用いたTXOP(最初APのフレームによって取得されたTXOP)のデュレーションは同一であるか、共有されたTXOPのデュレーションがTXOPのデュレーションよりも短い。したがって、共有されたTXOPが終了してもTXOPは終了しなくて済む。すなわち、共有されたTXOPのデュレーションとTXOPのデュレーションとが同一である場合に、共有されたTXOPが終了するとTXOPも共に終了するが、共有されたTXOPのデュレーションがTXOPのデュレーションよりも短い場合に、共有されたTXOPが終了してもTXOPは維持され得る。
さらに他の具体的な実施例において、共有されたTXOPが共有されたTXOP期間前に終了しても、共有されたTXOP期間内は、TXOP共有が設定された時から共有されたTXOPデュレーションが経過した時までであってよい。
前述したように、TXOP共有において、スケジュールドSTAは、NAVに関係なくフレームを送信することができる。すなわち、APによって設定されたTXOP内でNAVが設定された場合に(例えば、intra-BSS PPDUによって設定されたNAV)、スケジュールドSTAは、共有されたTXOP内では、設定されたNAVとは関係なくPPDUを送信することができる。言い換えると、TXOPが共有されたSTAは、TXOPを共有したSTAによって送信されるフレームによって設定されるNAVを、共有されたTXOP内では無視してフレームを送信することができる。このとき、共有されたTXOPは、MU-RTSフレームによって設定された区間よりも前に終了してよい。すなわち、共有されたTXOP内でMU-RTSによって設定された区間以前に、TXOPが共有されたSTAがTXOPの共有の中断を要請するためのシグナリングを送信することによってTXOPの共有を中断することができる。例えば、non-AP STAはAPからTXOPの全部又は一部が共有された場合に、送信する(又は、ペンドされた)PPDUがないと、共有されたTXOPを終了するために、TXOP共有を終了するためのシグナリングをAPに送信し、TXOPの共有を中断することができる。TXOP共有が中断される時点は、non-AP STAがTXOP共有の中断を要請するシグナリングを送信する時点又は当該シグナリングに対する応答フレームを受信する時点のいずれか一つであってよい。このとき、TXOPの共有のためのシグナリングは即刻の応答を要求しても要求しなくてもよい。また、この場合、non-AP STAは、MU-RTSフレームによって設定されるTXOPが共有される区間よりも早い時点にTXOP共有が中断されるため、TXOPの共有が終了する時点のみまで、設定されたNAVを無視できる。
この時、TXOP共有を設定したSTAも、NAVに関係なくフレームを送信することができる。図27の実施例において、第1STA(STA1)は第2STA(STA2)にTXOP共有設定のためのMU-RTSフレームを送信する。このとき、第1STA(STA1)はAPであってよい。第2STA(STA2)はTXOP共有設定のためのMU-RTSフレームを受信し、TXOP共有設定のためのMU-RTSフレームに対する応答としてCTSフレームを送信する。第2STA(STA2)は、共有されたTXOP内でフレーム交換を行う。第1STA(STA1)は、第2STA(STA2)が送信したり第2STA(STA2)に送信されるフレームに基づいてNAVを設定できる。例えば、共有されたTXOP内で第2STA(STA2)は第3STA(STA3)とフレーム交換を行うことができる。この時、第1STA(STA1)は、第3STA(STA3)が第2STA(STA2)に送信したフレームに基づいてNAVを設定できる。また、第1STA(STA1)は、第2STA(STA2)が第3STA(STA3)に送信したフレームに基づいてNAVを設定できる。このように第1STA(STA1)がNAVを設定した場合に、共有されたTXOPが割り当てられたTXOP内でフレームを送信し難いことがある。例えば、共有されたTXOPが終了した後に第1STA(STA1)がフレームを送信しようとするとき、共有されたTXOP内で設定されたNAVによってフレームを送信できないことがある。具体的には、共有されたTXOP内で送信されたPPDUが含むフレームが第1STA(STA1)から即刻の応答を誘発するフレームでない場合に、第1STA(STA1)は、設定されたNAVによってフレームを送信できないことがある。
TXOP共有を設定したSTAは、STAが取得したTXOP内でNAVに関係なくフレームを送信することができる。さらに他の具体的な実施例において、TXOP共有を設定したSTAは、共有されたTXOPが終了した時から取得したTXOP内でNAVに関係なくフレームを送信することができる。TXOP共有を設定したSTAは、TXOP共有を設定するためのMU-RTSフレームを送信したSTA又はTXOPホルダーであってよい。
この時、前述したように、共有されたTXOPは、MU-RTSフレームによって設定された区間以前に終了してよい。すなわち、共有されたTXOP内でMU-RTSによって設定された区間以前に、TXOPが共有されたSTAがTXOPの共有の中断を要請するためのシグナリングを送信することによってTXOPの共有を中断できる。例えば、non-AP STAは、APからTXOPの全部又は一部が共有された場合に、送信する(又は、ペンドされた)PPDUがないと、共有されたTXOPを終了するために、TXOP共有を終了するためのシグナリングをAPに送信してTXOPの共有を中断することができる。TXOP共有が中断される時点は、non-AP STAがTXOP共有の中断を要請するシグナリングを送信する時点又は当該シグナリングに対する応答フレームを受信する時点のいずれか一つであってよい。この時、TXOPの共有のためのシグナリングは、即刻の応答を要求しても要求しなくてもよい。また、この場合、MU-RTSフレームによって設定されるTXOPが共有される区間よりも早い時点にTXOP共有が中断されるため、TXOPの共有が終了する時点から、APは、non-AP STAによって送受信されたPPDUに基づいてAPによって設定されたNAVを無視できる。
前述した実施例において、TXOP共有を設定したSTAがNAVに関係なくフレームを送信することは、TXOP共有内でスケジュールドSTAが交換したフレームに基づいて設定されたNAVに関係なくフレームを送信することを表すことができる。TXOP共有を設定したSTAが、TXOP共有内でスケジュールドSTAが交換しなかったフレームに基づいて設定されたNAVに関係なくフレームを送信する場合に、他のSTAのフレーム交換を妨害することがあるためである。また、STAは、TXOP共有内でスケジュールドSTAが交換したフレームであるかを、フレームのMACヘッダーに基づいて判断できる。具体的には、STAは、TXOP共有内でスケジュールドSTAが交換したフレームであるかを、フレームのaddressフィールドに基づいて判断できる。addressフィールドは、RAフィールド、TAフィールド、及びBSSIDフィールドのうち少なくともいずれか一つを含んでよい。例えば、フレームのaddressフィールドのうち一つのフィールドがSTAのMACアドレスを指示する場合に、STAは、TXOP共有内でスケジュールドSTAが交換したフレームであると判断できる。また、STAは、TXOP共有内でスケジュールドSTAが交換したフレームであるかを、フレームを含むPPDUのプリアンブルに基づいて判断できる。また、STAは、TXOP共有内でスケジュールドSTAが交換したフレームであるかを、フレームを含むPPDUのプリアンブルが含むBSSカラー及びSTA IDのうち少なくともいずれか一つに基づいて判断できる。PPDUのプリアンブルがTXOP共有のスケジュールドSTAの属したBSSのBSSカラーを含み、PPDUのプリアンブルがTXOP共有のスケジュールドSTAに該当するSTA IDを含む場合に、STAは、PPDUが含むフレームをスケジュールドSTAが交換したフレームであると判断できる。このとき、STA IDは、STAのAIDに基づいて設定された値であってよい。
さらに他の具体的な実施例において、TXOP共有を設定したSTAがNAVに関係なく送信することは、フレームを送信する時にCS(carrier sensing)として物理的(physical)CS、例えばCCAのみを用いることができる。したがって、STAは仮想(virtual)CSを行わなくてよい。
本明細書において、NAVを設定することは、NAVをアップデートすることと相互交換的に使われてよい。また、本明細書において、NAVはIntra-BSS NAV又はベーシックNAVのうち少なくともいずれか一つを含んでよい。また、NAVの種類に対して特に言及がない場合、NAVはIntra-BSS NAVのことを指してよい。また、本明細書において、STAがいずれかのフレームに基づいてNAVを設定することは、フレームを含むPPDUに基づいてNAVを設定することを含んでよい。したがって、本明細書において、STAがいずれかのフレームに基づいてNAVを設定しないことは、フレームを含むPPDUに基づいてNAVを設定しないことを含んでよい。
TXOP共有を設定するためのMU-RTSフレームは、MACアドレス、例えば、RAフィールド又はUser Infoフィールドを用いてTXOPのスケジュールドSTAを指示できる。フレームやPPDUのデュレーション情報に基づいてNAVを設定することは、直近に設定したNAVがフレームやPPDUのデュレーション情報に基づいてNAVが設定されることを表すことができる。
さらに他の具体的な実施例において、共有されたTXOP内で送信されるフレームのDuration/IDフィールド又はフレームを含むPPDUのTXOPは、共有されたTXOPに基づいて設定されてよい。具体的には、共有されたTXOP内で送信されるフレームのDuration/IDフィールド又はフレームを含むPPDUのTXOPは、共有されたTXOPを超えて設定されることが許容されなくてよい。これにより、共有されたTXOPを設定したSTAが共有されたTXOPの終了後にもフレームを送信できない問題を防止することができる。
すなわち、APによって設定されたTXOPがトリガーフレームによってSTAに共有される場合に、共有されたTXOP内で送信されるフレーム(例えば、PPDU)に含まれるデュレーション情報(例えば、Duration/IDフィールド)は、共有されたTXOPに基づいて設定されてよい。具体的には、共有されたTXOP内で送信されるフレームのTXOPは、共有されたTXOPを超えて設定されることが許容されない。したがって、共有されたTXOP内でTXOPを設定したAP又はP2P通信のための第3STAに送信されるPPDUのTXOPは、共有されたTXOPと同一であるか、より以前に終了しなければならない。したがって、PPDUに含まれるデュレーション情報によって指示されるデュレーションの終了時点は、共有されたTXOPの終了時点と同一であるか、以前であってよい。言い換えると、APによって設定されたTXOPの一部又は全部が特定STAに共有された場合に、特定STAによって送信されるPPDUのTXOPは、共有されたTXOPを超えてはならず、以前に満了しなければならない。したがって、特定STAによってAP又はP2P通信のために第3STAに送信されるPPDUの長さ(又は、TXOP)の終了時点は、共有されたTXOPの終了時点の以後であってはならず、以前でなければならない。この場合、PPDUの長さ(又は、TXOP)の終了時点は、共有されたTXOPの終了時点と同一であるか、以前でなければならず、よって、PPDUに含まれるデュレーション情報によって指示される値は、共有されたTXOPに基づいて設定されてよい。
さらに他の具体的な実施例において、共有されたTXOPを設定したSTAは、TXOP共有のスケジュールドSTAが交換するフレームに基づいてNAVを設定しなくてよい。
共有されたTXOP内で共有されたTXOPを設定したSTAは、トリガーフレームを送信しなくてよい。共有されたTXOP内で共有されたTXOPを設定したSTAがトリガーフレームを送信する場合に、トリガーフレームによってトリガーされたフレームとスケジュールドSTAのフレーム交換とがオーバーラップすることがあるためである。また、共有されたTXOP内で共有されたTXOPを設定したSTAがスケジュールドSTAにトリガーフレームを送信する場合に、スケジュールドSTAは、トリガーフレームに対する応答を送信しなければならないことがある。したがって、これは、共有されたTXOPを設定した目的に符合しないことがある。このような実施例において、トリガーフレームは、TXOP共有を設定するためのMU-RTSフレームを含んでよい。このような実施例において、共有されたTXOPが終了した後、共有されたTXOPを設定したSTAはトリガーフレームを送信できる。
前述した実施例において、共有されたTXOPを設定したSTAが送信できないトリガーフレームは、TXOP共有のスケジュールドSTAのみへのトリガーフレーム以外の残りトリガーフレームであってよい。したがって、共有されたTXOPを設定したSTAは、共有されたTXOP内でTXOP共有のスケジュールドSTAのみにトリガーフレームを送信できる。例えば、共有されたTXOPを設定したSTAは、共有されたTXOPを延長するために、TXOP共有を設定するためのMU-RTSフレームを送信できる。この時、TXOP共有を設定するためのMU-RTSフレームを受信したSTAは、CTSフレームを送信しないでフレーム交換を始めることができる。具体的には、TXOP共有においてTXOP共有を設定したSTAとのフレーム交換のみが許容される場合に、TXOP共有を設定するためのMU-RTSフレームを受信したSTAは、CTSフレームを送信しないでフレーム交換を始めることができる。
本明細書において、共有されたTXOPの間に行われる動作は、TXOP共有のスケジュールドSTAによって共有されたTXOPが活用される動作であってよい。共有されたTXOPの間に行われる動作は、TXOP共有のスケジュールドSTAがTXOP共有を設定するためのMU-RTSフレームに対する応答としてフレームを送信すること、又はTXOP共有のスケジュールドSTAが共有されたTXOP内でフレームを送信することであってよい。このとき、TXOP共有を設定するためのMU-RTSフレームに対する応答フレームは、CTSフレームであってよい。
TXOP共有動作のためのシグナリングについて説明する。STAは、TXOP共有のスケジュールドSTAとして動作できるか否かをシグナルすることができる。この時、STAは、EHT Capabilitiesエレメントを用いて、TXOP共有のスケジュールドSTAとして動作できるかをシグナルすることができる。また、STAは、TXOP共有のスケジュールドSTAとして動作できるかを示すシグナリングを(再)連結要請フレーム又はプローブ要請フレームを用いて送信できる。TXOP共有を設定しようとするSTAは、TXOP共有のスケジュールドSTAとして動作できることをシグナルしたSTAにのみ、TXOP共有を設定するためのMU-RTSフレームを送信できる。また、TXOP共有を設定しようとするSTAは、TXOP共有のスケジュールドSTAとして動作できないことをシグナルしたSTAに、TXOP共有を設定するためのMU-RTSフレームを送信できなくてよい。
また、MU-RTSフレームは、MU-RTSフレームがTXOP共有を設定するためのMU-RTSフレームであるか否かを指示する情報を含んでよい。また、MU-RTSフレームがTXOP共有を設定するためのMU-RTSフレームである場合に、MU-RTSフレームは、TXOP共有のモードも指示することができる。TXOP共有のモードは、TXOP共有のスケジュールドSTAがどのSTAにフレームを送信できるかを指示できる。例えば、第1モードで、TXOP共有のスケジュールドSTAは、TXOP共有を設定したSTAにのみフレームを送信できる。また、第2モードで、TXOP共有のスケジュールドSTAは、TXOP共有を設定したSTAにフレームを送信したり又はP2Pフレームを送信できる。MU-RTSフレームがTXOP共有を設定するためのMU-RTSフレームであるか否かを指示する情報の値が1である場合に、第1モードを指示できる。また、MU-RTSフレームがTXOP共有を設定するためのMU-RTSフレームであるか否かを指示する情報の値が2である場合に、第2モードを指示できる。また、MU-RTSフレームがTXOP共有を設定するためのMU-RTSフレームであるか否かを指示する情報の値が0である場合に、MU-RTSフレームがTXOP共有を設定するためのMU-RTSフレームでないことを指示できる。
これらの実施例において、GI And HE-LTF Typeサブフィールドは、MU-RTSフレームがTXOP共有を設定するためのMU-RTSフレームであるか否かを指示できる。MU-RTSフレームがTXOP共有を設定するためのMU-RTSフレームである場合に、GI And HE-LTF Typeサブフィールドは、前述したように、TXOP共有のモードを指示できる。このとき、GI And HE-LTF Typeサブフィールドは、TXOP Sharing Modeサブフィールドと呼ぶことができる。TXOP Sharing Modeサブフィールドは、図16のCommon Infoフィールドの21番目のビット(B20)から22番目のビット(B21)のサブフィールドであってよい。
TXOP共有を終了する方法については図28を用いて説明する。
図28は、本発明の一実施例によってSTAがTXOPの共有を終了することを示す図である。
TXOP共有のスケジュールドSTAは、TXOP共有の終了をシグナルすることができる。TXOP共有を設定したSTAがTXOP共有の終了シグナリングを受信した場合に、TXOP共有を設定したSTAはTXOPホルダーになり得る。また、TXOP共有を設定したSTAがTXOP共有の終了シグナリングを受信した場合に、TXOP共有を設定したSTAはフレーム又はPPDUを送信できる。具体的には、TXOP共有を設定したSTAがTXOP共有の終了シグナリングを受信した場合に、共有されたTXOP内であっても、TXOP共有を設定したSTAはフレーム又はPPDUを送信できる。また、TXOP共有のスケジュールドSTAがTXOP共有の終了をシグナルした場合に、TXOP共有のスケジュールドSTAは、残っている共有されたTXOP内でいかなるフレームやPPDUも送信できなくてよい。
TXOP共有のスケジュールドSTAは、A-Controlサブフィールドを用いてTXOP共有の終了をシグナルすることができる。具体的には、A-ControlサブフィールドのSRS(single response scheduling)Controlサブフィールドは、TXOP共有の終了をシグナルすることができる。SRS Controlサブフィールドを受信したSTAは、SRS Controlサブフィールドを含むフレームに、TB PPDUでないPPDUで応答することができる。また、SRS Controlサブフィールドを含むフレームに対する応答PPDUの長さは、SRS Controlサブフィールドに基づいて決定されてよい。具体的には、SRS Controlサブフィールドを受信したSTAは、SRS Controlサブフィールドを含むフレームに対する応答PPDUの長さをSRS Controlサブフィールドが指示する長さに設定できる。
図28(a)は、SRS Controlサブフィールドのフォーマットを示す。前述したように、SRS Controlサブフィールドは、SRS Controlサブフィールドを含むMACフレームに対する応答であるPPDUの長さを指示するフィールドを含んでよい。このとき、フィールドは、PPDU Response Durationフィールドと呼ぶことができる。PPDU Response Durationフィールドは、4us単位で時間を指示できる。PPDU Response Durationフィールドが指示するPPDUの長さは、PPDU Response Durationフィールドの値×4usであってよい。また、PPDU Response Durationフィールドは、8ビットフィールドであってよい。
また、STAは、SRS Controlサブフィールドに対する能力(capability)をシグナルすることができる。具体的には、STAは、SRS Controlサブフィールドを受信できるか否かをシグナルすることができる。また、STAは、SRS Controlサブフィールドを含むフレームに応答できるか否かをシグナルすることができる。STAは、SRS Controlサブフィールドに対する動作を支援しないことをシグナルしたSTAにSRS Controlサブフィールドを送信できない。STAは、SRS Controlサブフィールドに対する動作を支援することをシグナルしたSTAにSRS Controlサブフィールドを送信できる。
また、SRS Controlフィールドは、TXOP共有の終了をシグナルするフィールドを含んでよい。TXOP共有の終了をシグナルするフィールドは、Shared TXOP Terminationフィールドと呼ぶことができる。Shared TXOP Terminationフィールドは、1ビットフィールドであってよい。Shared TXOP Terminationフィールドの値が1である場合に、Shared TXOP Terminationフィールドは、TXOP共有が終了することを示すことができる。Shared TXOP Terminationフィールドの値が0である場合に、Shared TXOP Terminationフィールドは、TXOP共有が終了しないことを示すことができる。STAがShared TXOP Terminationフィールドの値が1であるQoS Dataフレーム又はQoS Nullフレームを受信した場合に、STAは、TXOP共有が終了すると判断できる。
さらに他の具体的な実施例において、あらかじめ指定された設定を有するフレームがTXOP共有の終了をシグナルすることができる。このとき、あらかじめ指定された設定を有するフレームは、Qos Nullフレームであってよい。具体的には、あらかじめ指定された設定を有するフレームは、A-Controlサブフィールドを含まないQoS Nullフレームであってよい。また、あらかじめ指定された設定を有するフレームは、SRS Controlサブフィールドを含まないQoS Nullフレームであってよい。TXOP共有のスケジュールドSTAは、あらかじめ指定された設定を有するフレームを送信してTXOP共有の終了をシグナルすることができる。また、TXOP共有を設定したSTAがあらかじめ指定された設定を有するフレームを受信した場合に、TXOP共有を設定したSTAは、TXOP共有が終了すると判断できる。
TXOP共有のスケジュールドSTAがTXOP共有の終了シグナリングを送信したが、TXOP共有を設定したSTAはシグナリングを受信できないことがある。このとき、TXOP共有のスケジュールドSTAは、TXOP共有が終了したと判断し、フレームを送信しなくてよい。また、TXOP共有を設定したSTAは、TXOP共有が終了していないと判断し、フレームを送信しなくてよい。
具体的な実施例において、TXOP共有の終了をシグナルしたTXOP共有のスケジュールドSTAがシグナリングに対する応答を受信した場合に、TXOP共有のスケジュールドSTAは、TXOP共有が終了したと判断できる。この時、TXOP共有のスケジュールドSTAは、TXOP共有が終了したと判断し、フレームを送信しなくてよい。TXOP共有の終了シグナリングに対する応答は即刻の応答であってよい。また、TXOP共有の終了シグナリングに対する応答はACKであってよい。ただし、このような実施例は、TXOP共有の終了シグナリングのAck政策(Policy)が即刻の応答を要求するように設定された場合にのみ適用されてよい。具体的には、TXOP共有の終了シグナリングのAck政策(Policy)が即刻の応答を要求する場合に、TXOP共有の終了をシグナルしたTXOP共有のスケジュールドSTAがシグナリングに対する応答を受信すると、TXOP共有のスケジュールドSTAは、TXOP共有が終了したと判断できる。TXOP共有の終了シグナリングのAck政策(Policy)が即刻の応答を要求しない場合に、例えば、No ACK、TXOP共有の終了をシグナルしたTXOP共有のスケジュールドSTAがシグナリングに対する応答を受信しなくても、TXOP共有のスケジュールドSTAは、TXOP共有が終了したと判断できる。この時、TXOP共有のスケジュールドSTAは、TXOP共有の終了シグナリングを送信すると、TXOP共有が終了したと判断できる。また、TXOP共有の終了シグナリング送信に失敗した場合に、エラー回復(recovery)動作が行われてよい。具体的には、TXOP共有のスケジュールドSTAは、エラー回復(recovery)動作を行うことができる。また、TXOP共有を設定したSTAは、エラー回復(recovery)動作を行うことができる。
図28(b)において、第1STA(STA1)は第2STA(STA2)にTXOP共有設定のためのMU-RTSフレームを送信する。このとき、第1STA(STA1)はAPであってよい。第2STA(STA2)は、TXOP共有設定のためのMU-RTSフレームを受信し、TXOP共有設定のためのMU-RTSフレームに対する応答としてCTSフレームを送信する。共有されたTXOP内で第2STA(STA2)は第1STA(STA1)にTXOP共有の終了シグナリング(Frame to STA1 indicating termination)を送信する。第1STA(STA1)は、TXOP共有の終了シグナリング(Frame to STA1 indicating termination)受信に失敗する。この時、第1STA(STA1)は、TXOP共有が終了していないと判断する。前述したように、第1STA(STA1)又は第2STA(STA2)は、エラー回復動作を行うことができる。エラー回復動作後に、第2STA(STA2)は第1STA(STA1)にTXOP共有の終了シグナリング(Frame to STA1 indicating termination)を送信する。第1STA(STA1)は第2STA(STA2)にTXOP共有の終了シグナリング(Frame to STA1 indicating termination)に対する応答であるACK(Ack to STA2)を送信する。ACK(Ack to STA2)を受信した第2STA(STA2)は、TXOP共有が終了したと判断する。
TXOP共有が終了した後でも、TXOP共有を設定したSTAが応答を指示した場合に、TXOP共有のスケジュールドSTAはフレームを送信することができる。
前述したように、SRS Controlサブフィールドに対する動作を支援しないことをシグナルしたSTAにSRS Controlサブフィールドを送信できなくてよい。SRS ControlサブフィールドでTXOP共有の終了がシグナルされる場合に、SRS Controlサブフィールドに対する動作を支援しないことをシグナルしたSTAは、TXOP共有の終了シグナリングを受信できなくてよい。したがって、TXOP共有のスケジュールドSTAは、SRS Controlサブフィールドに対する動作を支援しないことをシグナルしたSTAにも、TXOP共有の終了をシグナルするSRS Controlサブフィールドを送信できる。TXOP共有の終了をシグナルするSRS Controlサブフィールドは、TXOP Terminationサブフィールドの値が1であるSRS Controlサブフィールドであってよい。TXOP共有のスケジュールドSTAは、SRS Controlサブフィールドに対する動作を支援しないことをシグナルしたSTAに、TXOP Terminationサブフィールドの値が0であるSRS Controlサブフィールドを送信できない。また、SRS Controlサブフィールドに対する動作を支援しないことをシグナルしたSTAに、SRS Controlサブフィールドを送信できない制限は、共有されたTXOP外でSRS Controlサブフィールドが送信された場合にのみ適用されてよい。
SRS ControlサブフィールドがTXOP共有の終了をシグナルする場合に、PPDU Response Durationサブフィールドは、リザーブドフィールドとして設定されてよい。リザーブドフィールドの全てのビットは0に設定されてよい。SRS ControlサブフィールドがTXOP共有の終了をシグナルしない場合に、PPDU Response Durationサブフィールドは、SRS Controlサブフィールドを含むフレームに対する応答であるフレームを含むPPDUの長さを指示できる。
SRS ControlサブフィールドがTXOP共有の終了をシグナルする場合に、SRS Controlサブフィールドを受信したSTAは、SRS Controlサブフィールドを含むフレームに対する応答を送信しなくてよい。さらに他の具体的な実施例において、SRS ControlサブフィールドがTXOP共有の終了をシグナルする場合に、SRS Controlサブフィールドを受信したSTAは、SRS Controlサブフィールドを含むフレームに対する応答を、SRS Controlフィールドがシグナルする情報に関係なく送信できる。この時、SRS Controlサブフィールドを受信したSTAは、SRS ControlサブフィールドがシグナルするSRS Controlサブフィールドを含むフレームに対する応答PPDUの長さに関係なく応答PPDUを送信できる。
共有されたTXOP内でSRS Controlサブフィールドを受信したSTAは、SRS Controlサブフィールドを含むフレームに対する応答を送信しなくてよい。さらに他の具体的な実施例において、共有されたTXOP内でSRS Controlサブフィールドを受信したSTAは、SRS Controlサブフィールドを含むフレームに対する応答を、SRS Controlフィールドがシグナルする情報に関係なく送信できる。この時、SRS Controlサブフィールドを受信したSTAは、SRS ControlサブフィールドがシグナルするSRS Controlサブフィールドを含むフレームに対する応答PPDUの長さに関係なく応答PPDUを送信できる。
又は、shared TXOP内でSRS Controlサブフィールドを受信するSTAは、前記SRS Controlサブフィールドが含むduration情報(PPDU Response Durationサブフィールド値)に基づいて応答しなくてよい。例えば、shared TXOP内でSRS Controlサブフィールドを受信するSTAは、前記SRS Controlサブフィールドが含むduration情報(PPDU Response Durationサブフィールド値)に関係なく応答することが可能である。
本発明の一実施例によれば、modified MU-RTSフレームは、TXOP内で最初のフレームでなくてよい。例えば、TXOP holderがTXOPを得るためにmodified MU-RTSフレームを送信せず、他のフレームを送信してもよい。これにより、あるSTAがmodified MU-RTSフレームに基づいてNAVを設定する前にNAVを設定することができる。すなわち、前記STAは、TXOPにおいて前記modified MU-RTSフレームよりも先に送信されたフレームに基づいてNAVを設定することができる。前述したNAV timeout動作は、NAV設定がRTSフレーム又はMU-RTSフレームに基づいてなされた場合に行うことが可能であるが、TXOPにおいてmodified MU-RTSフレームよりも先にフレーム送信を存在させることにより、RTSフレーム又はMU-RTSフレームに基づいてNAVが設定されることを少なく発生させることができる。また、modified MU-RTSフレームが含むデュレーション情報はTXOPを増やせずに済む。
図29は、本発明の一実施例に係るSTAの動作の一例を示すフローチャートである。
図29を参照すると、STAはAPからTXOPの一部又は全部が共有されてよく、これに基づいて共有されたTXOP内でPPDUを送信することができる。
具体的には、STAはAP(Access Point)から上りリンク送信を指示するトリガーフレーム(trigger frame)を受信することができる(S29010)。このとき、トリガーフレームは、前記APによって取得された送信機会(transmission opportunity:TXOP)の一部又は全部を前記STAに共有するために用いられてよく、TXOPの一部又は共有のために用いられる場合に、modified MU-RTSフレーム又はMU-RTS TXSトリガーフレームと呼ぶことができる。この時、STAは、受信されたフレームがTXOPの共有のためのフレームであるか否かを、前述したトリガーフレームのタイプフィールドから認識できる。
その後、STAは、トリガーフレームに基づいて、前記共有されたTXOP内で前記AP及び/又は他のSTAにPPDUを送信できる(S29020)。PPDUは、前記PPDUの送信のためのTXOPを指示するデュレーション情報を含み、前記デュレーション情報は、前記共有されたTXOPに基づいて設定されてよい。
デュレーション情報によって指示されるデュレーションの終了時点は、前記共有されたTXOPの終了時点と同一であるか、以前に終了してよい。
TXOP内で前記APによって送信されるフレームによってNAV(network allocation vector)が設定される場合に、前記PPDUは、前記共有されたTXOP内で前記設定されたNAVに関係なく送信される。
さらに他のSTAによって前記トリガーフレームに基づいて、前記共有されたTXOP内でNAV及び前記NAVの終了時間を示すNAVタイムアウト周期(timeout period)が設定された場合に、前記共有されたTXOP内で前記NAVタイムアウト周期が満了しても、前記共有されたTXOP内で前記さらに他のSTAによって設定された前記NAVは、前記NAVタイムアウト周期の満了によって解除されなくてよい。
トリガーフレームは、前記トリガーフレームによる前記TXOPの共有の有無を示すサブフィールドを含む。
前記サブフィールドが前記TXOPの共有を示す場合に、前記サブフィールドの値は、前記共有されたTXOP内で前記他のSTAと送受信できるか否かを示す。
前記トリガーフレームは、前記トリガーフレームのタイプを示すタイプフィールドを含み、前記TXOPの前記一部又は全部の共有は、前記タイプフィールドによる前記トリガーフレームの前記タイプによって設定される。
前述した本発明の説明は例示のためのものであり、本発明の属する技術の分野における通常の知識を有する者は、本発明の技術的思想や必須の特徴を変更することなく他の具体的な形態に容易に変形可能であるということが理解できよう。したがって、以上に述べた実施例はいかなる面においても例示的であり、限定的でないものと理解すべきである。例えば、単一型として説明されている各構成要素は、分散して実施されてもよく、同様に、分散していると説明されている構成要素も、結合した形態で実施されてよい。
本発明の範囲は、上述した詳細な説明よりは、後述する特許請求の範囲によって示され、特許請求の範囲の意味及び範囲そしてその均等概念から導出されるあらゆる変更又は変形された形態が本発明の範囲に含まれるものとして解釈されるべきである。
100 ステーション
110 プロセッサ
120 通信部
140 ユーザインタフェース部
150 ディスプレーユニット
160 メモリ
210 プロセッサ
220 通信部
260 メモリ
300 サーバ

Claims (16)

  1. 無線通信システムのステーション(station:STA)であって、
    送受信部;及び
    前記送受信部を制御するプロセッサを含み、
    前記プロセッサは、
    AP(Access Point)から上りリンク送信を指示するトリガーフレーム(trigger frame)を受信し、
    前記トリガーフレームは、前記APによって取得された送信機会(transmission opportunity:TXOP)の一部又は全部を前記STAに共有するために用いられ、
    前記トリガーフレームに基づいて、前記共有されたTXOP内で前記AP及び/又は他のSTAにPPDU(Physical layer Protocol Data Unit)を送信し、
    前記PPDUは、前記PPDUの送信のためのTXOPを指示するデュレーション情報を含み、
    前記デュレーション情報は、前記共有されたTXOPに基づいて設定されるSTA。
  2. 前記デュレーション情報によって指示されるデュレーションの終了時点は、前記共有されたTXOPの終了時点と同一である、請求項1に記載のSTA。
  3. 前記デュレーション情報によって指示されるデュレーションは、前記共有されたTXOPの終了時点よりも以前に終了する、請求項1に記載のSTA。
  4. 前記TXOP内で前記APによって送信されるフレームによってNAV(network allocation vector)が設定される場合に、前記PPDUは、前記共有されたTXOP内で前記設定されたNAVに関係なく送信される、請求項1に記載のSTA。
  5. さらに他のSTAによって前記トリガーフレームに基づいて、前記共有されたTXOP内でNAV及び前記NAVの終了時間を示すNAVタイムアウト周期(timeout period)が設定された場合に、前記共有されたTXOP内で前記NAVタイムアウト周期が満了しても、前記共有されたTXOP内で前記さらに他のSTAによって設定された前記NAVは、前記NAVタイムアウト周期の満了によって解除されない、請求項1に記載のSTA。
  6. 前記トリガーフレームは、前記トリガーフレームによる前記TXOPの共有の有無を示すサブフィールドを含む、請求項1に記載のSTA。
  7. 前記サブフィールドが前記TXOPの共有を示す場合に、前記サブフィールドの値は、前記共有されたTXOP内で前記他のSTAと送受信可能であるか否かを示す、請求項6に記載のSTA。
  8. 前記トリガーフレームは、前記トリガーフレームのタイプを示すタイプフィールドを含み、
    前記TXOPの前記一部又は全部の共有は、前記タイプフィールドによる前記トリガーフレームの前記タイプによって設定される、請求項1に記載のSTA。
  9. 無線通信システムにおいてステーション(station:STA)がフレームを送信する方法であって、
    AP(Access Point)から上りリンク送信を指示するトリガーフレーム(trigger frame)を受信する段階であって、前記トリガーフレームは、前記APによって取得された送信機会(transmission opportunity:TXOP)の一部又は全部を前記STAに共有するために用いることができる、段階;及び、
    前記トリガーフレームに基づいて、前記共有されたTXOP内で前記AP及び/又は他のSTAにPPDU(Physical layer Protocol Data Unit)を送信する段階であって、前記PPDUは、前記PPDUの送信のためのTXOPを指示するデュレーション情報を含み、前記デュレーション情報は、前記共有されたTXOPに基づいて設定される、段階;を含む方法。
  10. 前記デュレーション情報によって指示されるデュレーションの終了時点は、前記共有されたTXOPの終了時点と同一である、請求項9に記載の方法。
  11. 前記デュレーション情報によって指示されるデュレーションは、前記共有されたTXOPの終了時点よりも以前に終了する、請求項9に記載の方法。
  12. 前記TXOP内で前記APによって送信されるフレームによってNAV(network allocation vector)が設定される場合に、前記PPDUは、前記共有されたTXOP内で前記設定されたNAVに関係なく送信される、請求項9に記載の方法。
  13. さらに他のSTAによって前記トリガーフレームに基づいて、前記共有されたTXOP内でNAV及び前記NAVの終了時間を示すNAVタイムアウト周期(timeout period)が設定された場合に、前記共有されたTXOP内で前記NAVタイムアウト周期が満了しても、前記共有されたTXOP内で前記さらに他のSTAによって設定された前記NAVは、前記NAVタイムアウト周期の満了によって解除されない、請求項9に記載の方法。
  14. 前記トリガーフレームは、前記トリガーフレームによる前記TXOPの共有の有無を示すサブフィールドを含む、請求項9に記載の方法。
  15. 前記サブフィールドが前記TXOPの共有を示す場合に、前記サブフィールドの値は、前記共有されたTXOP内で前記他のSTAと送受信可能であるか否かを示す、請求項14に記載の方法。
  16. 前記トリガーフレームは、前記トリガーフレームのタイプを示すタイプフィールドを含み、
    前記TXOPの前記一部又は全部の共有は、前記タイプフィールドによる前記トリガーフレームの前記タイプによって設定される、請求項9に記載の方法。
JP2023548732A 2021-02-10 2022-02-10 マルチリンクを用いる無線通信方法及びこれを用いる無線通信端末 Pending JP2024506354A (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
KR10-2021-0019409 2021-02-10
KR20210019409 2021-02-10
KR20210022885 2021-02-19
KR10-2021-0022885 2021-02-19
KR10-2021-0052041 2021-04-22
KR20210052041 2021-04-22
PCT/KR2022/002057 WO2022173251A1 (ko) 2021-02-10 2022-02-10 멀티 링크를 사용하는 무선 통신 방법 및 이를 사용하는 무선 통신 단말

Publications (1)

Publication Number Publication Date
JP2024506354A true JP2024506354A (ja) 2024-02-13

Family

ID=82838499

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2023548732A Pending JP2024506354A (ja) 2021-02-10 2022-02-10 マルチリンクを用いる無線通信方法及びこれを用いる無線通信端末

Country Status (4)

Country Link
US (1) US20240049304A1 (ja)
JP (1) JP2024506354A (ja)
KR (1) KR20230129510A (ja)
WO (1) WO2022173251A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220353910A1 (en) * 2021-05-03 2022-11-03 Mediatek Singapore Pte. Ltd. EDCA Schemes For Triggered TXOP Sharing Operations
EP4380290A1 (en) * 2022-11-29 2024-06-05 Comcast Cable Communications, LLC Triggered transmission opportunity sharing

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9295074B2 (en) * 2013-09-10 2016-03-22 Samsung Electronics Co., Ltd. Acknowledgement, error recovery and backoff operation of uplink multi-user multiple-input-multiple-output communication in wireless networks
EP3229434B1 (en) * 2014-12-05 2019-09-04 LG Electronics Inc. Data transmission method in wireless communication system and device therefor
WO2016200182A1 (ko) * 2015-06-10 2016-12-15 엘지전자 주식회사 무선랜 시스템에서 nav를 관리하는 방법 및 이를 위한 장치
KR102435189B1 (ko) * 2016-04-02 2022-08-23 주식회사 윌러스표준기술연구소 중첩된 베이직 서비스 세트의 공간적 재사용 동작을 위한 무선 통신 방법 및 무선 통신 단말

Also Published As

Publication number Publication date
US20240049304A1 (en) 2024-02-08
KR20230129510A (ko) 2023-09-08
WO2022173251A1 (ko) 2022-08-18

Similar Documents

Publication Publication Date Title
JP2023545087A (ja) 無線通信システムにおいてフレームを送受信するための方法及び無線通信端末
JP7461082B2 (ja) マルチリンクを用いる無線通信方法及びこれを用いる無線通信端末
US20230284303A1 (en) Method and wireless communication terminal for transmitting/receiving data in wireless communication system
JP2024505101A (ja) マルチリンクを用いる無線通信方法及びこれを用いる無線通信端末
JP7554502B2 (ja) マルチリンクを用いる無線通信方法及びこれを用いる無線通信端末
EP4280775A1 (en) Wireless communication method using limited twt and wireless communication terminal using same
JP7544402B2 (ja) 無線通信システムにおいてデータを送受信するための方法及び無線通信端末
JP2024510319A (ja) 複数のリンクで動作するマルチリンク装置及びマルチリンク装置の動作方法
US12101814B2 (en) Wireless communication method using shared TXOP, and wireless communication terminal using same
US20240049304A1 (en) Wireless communication method using multi-link, and wireless communication terminal using same
JP2024532781A (ja) マルチリンクを用いる無線通信方法及びこれを用いる無線通信端末
JP7555644B2 (ja) 無線通信システムにおいてデータを送受信するための方法及び無線通信端末
KR20230048064A (ko) 멀티 링크를 사용하는 무선 통신 방법 및 이를 사용하는 무선 통신 단말
US20240008083A1 (en) Wireless communication method using multilink, and wireless communication terminal using same
JP2024524957A (ja) マルチリンクを用いる無線通信方法及びこれを用いる無線通信端末
KR20230171987A (ko) 공유 txop를 이용하는 무선 통신 장치 및 무선 통신장치의 동작 방법
CN116803128A (zh) 使用多链路的无线通信方法和使用该方法的无线通信终端
EP4412297A1 (en) Wireless communication method using multi-links, and wireless communication terminal using same
CN116830754A (zh) 使用多链路的无线通信方法和使用该方法的无线通信终端
CN117546590A (zh) 使用共享txop的无线通信方法及使用其的无线通信终端
CN116746106A (zh) 在无线通信系统中发送和接收数据的方法和终端
JP2024521227A (ja) マルチリンクを用いる無線通信方法及びこれを用いる無線通信端末
CN117356156A (zh) 使用共享txop的无线通信设备和无线通信设备的操作方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230810

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20240617

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240917