JP7741333B2

JP7741333B2 - マルチリンク通信方法及び装置

Info

Publication number: JP7741333B2
Application number: JP2024543338A
Authority: JP
Inventors: リー，ユインボー; リー，イーチーン; ガン，ミーン; グオ，ユイチェン
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-01-23
Filing date: 2023-01-06
Publication date: 2025-09-17
Anticipated expiration: 2043-01-06
Also published as: US20240381476A1; AU2023209486A1; JP2025504493A; WO2023138414A1; AU2023209486B2; EP4456504A4; KR20240134984A; EP4456504A1; CA3249380A1; MX2024009061A

Description

［関連出願の相互参照］
この出願は、2022年1月23日に中国国家知的所有権局に出願された「MULTI-LINK COMMUNICATION METHOD AND APPARATUS」という名称の中国特許出願第202210076088.X号、及び2022年1月28日に中国国家知的所有権局に出願された「MULTI-LINK COMMUNICATION METHOD AND APPARATUS」という名称の中国特許出願第202210109328.1号の優先権を主張し、これらの双方の全内容が参照によりここに組み込まれる。

［技術分野］
この出願は、通信技術の分野に関し、特に、マルチリンク通信方法及び装置に関する。

次世代無線ローカルエリアネットワーク(wireless local area network, WLAN)標準は、スループットの継続的な改善に向けて発展及び進化している。WLANシステム標準は、電気電子技術者協会(institute of electrical and electronics engineers, IEEE)802.11標準グループにおいて主に研究されて議論されている。例えば、極高スループット(extremely high throughput, EHT)がターゲットとして使用される主要な技術は、マルチリンク(multi-link, ML)通信を含んでもよい。マルチリンク通信に基づいて、マルチリンクデバイスは、2.4GHz、5GHz及び6GHzの周波数帯域上で通信を実行して、マルチリンクデバイスの通信品質を確保するための最適な周波数帯域を選択してもよい。

マルチリンク通信シナリオでは、アクセスポイントマルチリンクデバイスは、複数のリンクを通じて、同じトラフィック識別子に対応するデータパケットをステーションマルチリンクデバイスに送信してもよい。さらに、ステーションマルチリンクデバイスが各リンク上でローカルスコアボードを維持するとき、異なるリンク上のステーションは、既存のブロック確認応答メカニズムにおいて、受信した集約媒体アクセス制御プロトコルデータユニット(aggregate media access control protocol data unit, A-MPDU)内の全てのMPDUの受信状態を正しくフィードバックできない可能性がある。

したがって、マルチリンク通信シナリオにおいて、異なるリンク上の受信デバイスが受信したA-MPDU内の全てのMPDUの受信状態を正しくフィードバックすることをどのように確保するかが、緊急に解決される必要がある。

この出願は、受信機が、受信機により受信されたA-MPDU内の全てのMPDUの受信状態を正しくフィードバックすることを効果的に確保するための、マルチリンク通信方法及び装置を提供する。

第1の態様によれば、この出願の実施形態は、マルチリンク通信方法を提供する。当該方法は以下を含む。受信機は、第1の集約媒体アクセス制御プロトコルデータユニットA-MPDUを受信する。受信機は、ローカルに記録されたスコアボードコンテキストを取得し、第1のA-MPDUが以下の条件のうちいずれか1つ以上を満たすとき、第1のA-MPDUのシーケンス番号SNに基づいてスコアボードコンテキストをリフレッシュする。第1の条件は、受信機と連携するSTAが、WinStart_R≦SN<WinStart_R+2¹¹であるSNを有するMPDUを受信することを含み、第2の条件は、WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUのいずれもSTAにより受信されないこと、又はWinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有する全てのMPDUが受信機と連携する他のSTAにより受信されることを含み、第3の条件は、第1のA-MPDUの前に受信された他のA-MPDU内の如何なるフレームもBAにより応答されていないものではないこと、第1のA-MPDUの前に受信されたいずれかのA-MPDU内のいずれかのMPDUがBAにより応答していること、又は第1のA-MPDUの前に受信されたいずれかのA-MPDUで搬送された全てのMPDUがBAにより応答していることを含む。

可能な実現方式では、第1のA-MPDUは、以下の第4の条件を更に満たす。第4の条件は、第1のA-MPDU内のSNを有する他のMPDUが第1の条件、第2の条件及び第3の条件をまだ満たしていないこと、受信機と連携するSTAにより受信されたSNを有するMPDUが、第1のA-MPDU内にあり且つ第1の条件、第2の条件及び第3の条件を満たす1番目のMPDUであること、又は受信機と連携するSTAのスコアボードコンテキストが第1のA-MPDU内のMPDUに基づいてリフレッシュされていないことを含む。

可能な実現方式では、受信機は、各リンクにおいて別々のスコアボードコンテキスト制御を有し、リンクは、受信機と送信機との間のリンクである。

可能な実現方式では、受信機と連携するSTAは、スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能である。

可能な実現方式では、第1のA-MPDU内のSNは、同じトラフィック識別子TIDに属する。

この出願のこの実施形態において提供される方法によれば、受信機は、ローカルスコアボード(local scoreboard)コンテキストを適切且つ効果的にリフレッシュできる。

第1の態様又は可能な実現方式のうちいずれか1つの具体的な説明については、第3のスコアボードコンテキスト制御動作～第10のスコアボードコンテキスト制御動作の以下の説明、以下の図４に示す方法等を参照することが理解され得る。詳細はここでは1つずつ再び説明しない。

第2の態様によれば、この出願の実施形態は、マルチリンク通信方法を提供する。当該方法は以下を含む。送信機は、第2のA-MPDUを送信する。A-MPDUは指示情報を含み、指示情報は、受信機のスコアボードコンテキストをリフレッシュするか否かを受信機に指示する。

可能な実現方式では、指示情報は、第2のA-MPDUを伝送するために使用されるリンクに対応するSTAがSTAのスコアボードコンテキストをリフレッシュするか否かを指示する。

可能な実現方式では、指示情報は、MPDUデリミタ又は高スループット制御フィールドで搬送される。

第2の態様又は可能な実現方式のうちいずれか1つの具体的な説明については、図５に示す方法及び以下の図６ａ～図６ｄに示す説明を参照することが理解され得る。詳細はここでは1つずつ再び説明しない。

第3の態様によれば、この出願の実施形態は、第1の態様又は第1の態様の可能な実現方式のいずれか1つによる方法を実行するように構成された通信装置を提供する。通信装置は、第1の態様又は第1の態様の可能な実現方式のいずれか1つによる方法を実行するユニットを含む。

例えば、通信装置は、送信機、送信機内のチップ等でもよい。

第4の態様によれば、この出願の実施形態は、第2の態様又は第2の態様の可能な実現方式のいずれか1つによる方法を実行するように構成された通信装置を提供する。通信装置は、第2の態様又は第2の態様の可能な実現方式のいずれか1つによる方法を実行するユニットを含む。

例えば、通信装置は、受信機、受信機内のチップ等でもよい。

第3の態様又は第4の態様において、通信装置は、トランシーバユニットと、処理ユニットとを含んでもよい。トランシーバユニット及び処理ユニットの具体的な説明については、以下に示す装置の実施形態を参照する。

第5の態様によれば、この出願の実施形態は、通信装置を提供する。通信装置は、第1の態様又は第1の態様の可能な実現方式のいずれか1つに示す方法を実行するように構成されたプロセッサを含む。代替として、プロセッサは、メモリに記憶されたプログラムを実行するように構成される。プログラムが実行されると、第1の態様又は第1の態様の可能な実現方式のうちいずれか1つに示す方法が実行される。

可能な実現方式では、メモリは通信装置の外部に位置する。

可能な実現方式では、メモリは通信装置の内部に位置する。

この出願のこの実施形態では、プロセッサ及びメモリは、1つのコンポーネントに更に統合されてもよく、言い換えると、プロセッサ及びメモリは、一緒に更に統合されてもよい。

可能な実現方式では、通信装置はトランシーバを更に含み、トランシーバは、信号を受信するか或いは信号を送信するように構成される。例えば、トランシーバは、A-MPDU等を受信するように更に構成されてもよい。

この出願のこの実施形態では、通信装置は、送信機、送信機内のチップ等でもよい。

第6の態様によれば、この出願の実施形態は、通信装置を提供する。通信装置は、第2の態様又は第2の態様の可能な実現方式のいずれか1つに示す方法を実行するように構成されたプロセッサを含む。代替として、プロセッサは、メモリに記憶されたプログラムを実行するように構成される。プログラムが実行されると、第2の態様又は第2の態様の可能な実現方式のうちいずれか1つに示す方法が実行される。

可能な実現方式では、通信装置はトランシーバを更に含み、トランシーバは、信号を受信するか或いは信号を送信するように構成される。例えば、トランシーバは、A-MPDUを送信するように構成されてもよい。

この出願のこの実施形態では、通信装置は、受信機、受信機内のチップ等でもよい。

第7の態様によれば、この出願の実施形態は、通信装置を提供する。通信装置は、論理回路とインタフェースとを含み、論理回路はインタフェースに結合される。インタフェースは、第1のA-MPDUを入力するように構成され、論理回路は、第1のA-MPDUに基づいてローカルスコアボードコンテキストをリフレッシュするように構成される。

任意選択で、インタフェースは、BAフレームを出力するように更に構成される。

任意選択で、通信装置はメモリを更に含む。メモリは、第3のスコアボードコンテキスト制御動作～第10のスコアボードコンテキスト制御動作のうちいずれか1つ以上を記憶するように構成される。

第8の態様によれば、この出願の実施形態は、通信装置を提供する。通信装置は、論理回路とインタフェースとを含み、論理回路はインタフェースに結合される。論理回路は、第1のA-MPDUを生成するように構成され、インタフェースは、第1のA-MPDUを出力するように構成される。

この出願のいくつかの他の実施形態では、インタフェースは、第2のA-MPDUを出力するように構成され、第2のA-MPDUは指示情報を含む。

第9の態様によれば、この出願の実施形態は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は、コンピュータプログラムを記憶するように構成される。コンピュータプログラムがコンピュータ上で実行すると、第1の態様又は第1の態様の可能な実現方式のいずれか1つに示す方法が実行されることが可能になる。

第10の態様によれば、この出願の実施形態は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は、コンピュータプログラムを記憶するように構成される。コンピュータプログラムがコンピュータ上で実行すると、第2の態様又は第2の態様の可能な実現方式のいずれか1つに示す方法が実行されることが可能になる。

第11の態様によれば、この出願の実施形態は、コンピュータプログラム製品を提供する。コンピュータプログラム製品は、コンピュータプログラム又はコンピュータコードを含む。コンピュータプログラム製品がコンピュータ上で実行されると、第1の態様又は第1の態様の可能な実現方式のいずれか1つに示す方法が実行されることが可能になる。

第12の態様によれば、この出願の実施形態は、コンピュータプログラム製品を提供する。コンピュータプログラム製品は、コンピュータプログラム又はコンピュータコードを含む。コンピュータプログラム製品がコンピュータ上で実行されると、第2の態様又は第2の態様の可能な実現方式のいずれか1つに示す方法が実行されることが可能になる。

第13の態様によれば、この出願の実施形態は、コンピュータプログラムを提供する。コンピュータプログラムがコンピュータ上で実行すると、第1の態様又は第1の態様の可能な実現方式のいずれか1つに示す方法が実行される。

第14の態様によれば、この出願の実施形態は、コンピュータプログラムを提供する。コンピュータプログラムがコンピュータ上で実行すると、第2の態様又は第2の態様の可能な実現方式のいずれか1つに示す方法が実行される。

第15の態様によれば、この出願の実施形態は、無線通信システムを提供する。無線通信システムは、送信機と受信機とを含む。送信機は、第1の態様又は第1の態様の可能な実現方式のいずれか1つに示す方法を実行するように構成される。受信機は、第2の態様又は第2の態様の可能な実現方式のいずれか1つに示す方法を実行するように構成される。

第1の態様～第15の態様におけるWinStart_R≦SN<WinStart_R+2¹¹は、WinSize_R=1024を例として使用することにより示されている。しかし、この出願におけるWinSize_Rは、代替として、64、128、256又は512でもよい。したがって、第1の態様～第15の態様におけるWinStart_R≦SN<WinStart_R+2¹¹は、代替として、WinStart_R≦SN<WinStart_R+2*WinSize_Rとして理解されてもよい。これはここでは1つずつ列挙されない。

この出願の実施形態によるマルチリンク通信シナリオの概略図である。この出願の実施形態によるマルチリンク通信シナリオの概略図である。この出願の実施形態によるマルチリンク通信シナリオの概略図である。この出願の実施形態によるマルチリンク通信方法の概略フローチャートである。この出願の実施形態によるスコアボードコンテキスト制御動作の概略図である。この出願の実施形態によるスコアボードコンテキスト制御動作の概略図である。この出願の実施形態によるスコアボードコンテキスト制御動作の概略図である。この出願の実施形態によるスコアボードコンテキスト制御動作の概略図である。この出願の実施形態によるスコアボードコンテキスト制御動作の概略図である。この出願の実施形態によるスコアボードコンテキスト制御動作の概略図である。この出願の実施形態によるマルチリンク通信方法の概略フローチャートである。この出願の実施形態による他のマルチリンク通信方法の概略フローチャートである。この出願の実施形態によるMPDUサブフレームの構造の概略図である。この出願の実施形態による集約制御フィールドのフォーマットの概略図である。この出願の実施形態による集約制御フィールドのフォーマットの概略図である。この出願の実施形態によるコマンド及び状態タイプ制御情報のフレーム構造の概略図である。この出願の実施形態による通信装置の構造の概略図である。この出願の実施形態による通信装置の構造の概略図である。この出願の実施形態による通信装置の構造の概略図である。この出願の実施形態によるスコアボードコンテキスト制御動作の概略図である。この出願の実施形態によるスコアボードコンテキスト制御動作の概略図である。

この出願の目的、技術的解決策及び利点をより明確にするために、以下に、添付の図面を参照してこの出願について詳細に更に説明する。

この出願の明細書、特許請求の範囲及び添付の図面において、「第1」、「第2」等の用語は、単に異なるオブジェクトの間を区別することを意図しており、特定の順序を示すものではない。さらに、「含む」、「有する」という用語、及びこれらのいずれかの他の変形は、非排他的な包含をカバーすることが意図される。例えば、一連のステップ又はユニットを含むプロセス、方法、システム、製品又はデバイスは、列挙されたステップ又はユニットに限定されず、任意選択で、列挙されていないステップ又はユニットを更に含むか、或いは、任意選択で、プロセス、方法、製品又はデバイスに固有の他のステップ又はユニットを更に含む。

この明細書で言及される「実施形態」は、実施形態を参照して記載される特定の特性、構造又は特徴が、この出願の少なくとも1つの実施形態に含まれてもよいことを意味する。この明細書の様々な位置に現れる用語は、必ずしも同じ実施形態を意味するものではなく、他の実施形態から排他的な独立した実施形態又は任意選択の実施形態を意味するものでもない。当業者は、明示的及び暗黙的な方式で、この出願に記載される実施形態が他の実施形態と組み合わされてもよいことを理解し得る。

この出願において、「少なくとも1つ(の項目)」は1つ以上を意味し、「複数」は2つ以上を意味し、「少なくとも2つ(の項目)」は2つ以上(3つを含む)を意味する。「及び/又は」という用語は、関連するオブジェクトを記載するための関連付け関係を記述するために使用され、3つの関係が存在し得ることを表す。例えば、「A及び/又はB」は、以下の3つの場合、すなわち、Aのみが存在すること、Bのみが存在すること、及びAとBとの双方が存在することを表してもよく、A及びBは単数又は複数でもよい。「/」という文字は、一般的に、関連するオブジェクトの間の「又は」関係を示す。「以下の項目(もの)のうち少なくとも1つ」又はこの同様の表現は、これらの項目のいずれかの組み合わせを示す。例えば、a、b又はcのうち少なくとも1つ(のもの)は、a、b、c、「a及びb」、「a及びc」、「b及びc」又は「a、b、及びc」を表してもよい。

この出願において提供されるマルチリンク通信方法は、無線通信システムに適用されてもよい。無線通信システムは、WLAN、セルラネットワーク等を含んでもよい。当該方法は、無線通信システムにおける通信デバイス、通信デバイスにおける論理回路又はプロセッサ等により実現されてもよい。通信デバイスは、例えば、マルチリンクデバイス(multi-link device, MLD)又はマルチバンドデバイス(multi-band device)と呼ばれる、複数のリンク上での並列伝送をサポートする無線通信デバイスでもよい。例えば、無線ローカルエリアネットワークにおいて、通信デバイスは、IEEE802.11シリーズのプロトコルを使用することによる通信をサポートする。IEEE802.11シリーズのプロトコルは、802.11be、次世代802.11be、802.11ax、802.11a/b/g/n/ac等を含む。これは、ここでは1つずつ列挙されない。

以下に、まず、この出願におけるマルチリンクデバイスについて説明する。

マルチリンク通信の中心的な考えは、IEEE802.11標準をサポートするWLANデバイス、例えば、EHTデバイスが、複数の周波数帯域上で送信及び/又は受信を実行可能であり、その結果、より大きい帯域幅が伝送のために使用できるようにし、それにより、スループットを改善することである。例えば、複数の周波数帯域は、主に、2.4GHzのWi-Fi周波数帯域、5GHzのWi-Fi周波数帯域又は6GHzのWi-Fi周波数帯域を含むが、これらに限定されない。例えば、各周波数帯域上のアクセス及び/又は伝送は、1つのリンクと呼ばれ、したがって、複数の周波数帯域上のアクセス及び/又は伝送は、複数のリンクと呼ばれる。例えば、マルチリンク通信をサポートするデバイスは、マルチリンクデバイス(multi-link device, MLD)と呼ばれる。図１ａは、この出願の実施形態によるマルチリンク通信シナリオの概略図である。例えば、MLDデバイス上に複数のアクセスポイント(access point, AP)又はステーション(station, STA)が存在して、APマルチリンクデバイス(AP multi-link device, AP MLD)又は非APマルチリンクデバイス(non-AP multi-link device, non-AP MLD)を形成する。MDLの間の通信は、マルチリンク通信である。図１ａにおいて、リンク1及びリンク2はマルチリンクを形成する。

マルチリンクデバイスは、1つ以上の連携ステーションを含む。連携ステーション(affiliated station)は、論理ステーションであり、リンク、周波数帯域、チャネル等の上で動作してもよい。連携ステーションは、アクセスポイント(access point, AP)又は非アクセスポイントステーション(non-access point station, non-AP STA)でもよい。一般的に、連携ステーションがAPであるマルチリンクデバイスは、APマルチリンク、APマルチリンクデバイス又はAP MLDと呼ばれてもよい。連携ステーションがnon-AP STAであるマルチリンクデバイスは、マルチリンクSTA、マルチリンクSTAデバイス又はSTAマルチリンクデバイス(STA multi-link device)と呼ばれてもよい。代替として、連携ステーションがnon-AP STAであるマルチリンクデバイスは、マルチリンクnon-AP、マルチリンクnon-APデバイス、non-AP MLD等と呼ばれる。以下では、連携ステーションがAPであるマルチリンクデバイスはAP MLDと呼ばれ、連携ステーションがnon-AP STAであるマルチリンクデバイスはnon-AP MLDと呼ばれる。AP MLDには1つ以上の連携APが存在し、STA MLDには1つ以上の連携STAが存在する。

マルチリンクデバイスは、802.11シリーズのプロトコルに準拠した無線通信を実現してもよい。例えば、極高スループット(extremely high throughput, EHT)に準拠したマルチリンクデバイス、又は802.11beに準拠するか或いは802.11beと互換性のあるマルチリンクデバイスが、他のデバイスとの通信を実現する。

マルチリンクデバイス(non-AP MLD又はAP MLDでもよい)は、無線通信機能を有する通信装置である。通信装置は、デバイスでもよく、或いは、デバイスに設置されたチップ、処理システム等でもよい。チップ又は処理システムが設置されたデバイスは、チップ又は処理システムの制御下で、この出願の実施形態における方法及び機能を実現してもよい。例えば、この出願の実施形態におけるマルチリンクデバイスは、無線トランシーバ機能を有し、802.11シリーズのプロトコルをサポートしてもよく、APマルチリンクデバイス又はnon-APマルチリンクデバイスと通信してもよい。例えば、non-APマルチリンクデバイスは、ユーザがAPと通信することを可能にし、したがってWLANと通信することを可能にするいずれかのユーザ通信デバイスである。例えば、non-APマルチリンクデバイスは、ネットワークにアクセスできるユーザ機器、例えば、タブレットコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、ノートブックコンピュータ、ウルトラモバイルパーソナルコンピュータ(ultra-mobile personal computer, UMPC)、ハンドヘルドコンピュータ、ネットブック、携帯情報端末(personal digital assistant, PDA)又は携帯電話でもよく、或いは、モノのインターネットにおけるモノのインターネットノード、車両のインターネットにおける車載通信装置等でもよい。代替として、non-APマルチリンクデバイスは、上記の端末内のチップ及び処理システムでもよい。APマルチリンクデバイスは、サービスをnon-APマルチリンクデバイスに提供する装置でもよく、802.11シリーズのプロトコルをサポートしてもよい。例えば、APマルチリンクデバイスは、通信サーバ、ルータ、スイッチ又はネットワークブリッジのような通信エンティティでもよい。代替として、APマルチリンクデバイスは、様々な形式のマクロ基地局、マイクロ基地局、中継局等を含んでもよい。明らかに、APマルチリンクデバイスは、さらに、様々な形式のデバイス内のチップ及び処理システムでもよい。802.11プロトコルは、802.11beをサポートするか或いは802.11beと互換性があるプロトコルでもよい。

マルチリンクデバイス(non-AP MLD又はAP MLDでもよい)は、高レート及び低レイテンシ伝送をサポートしてもよいことが理解され得る。無線ローカルエリアネットワークの適用シナリオの継続的な発展に伴い、マルチリンクデバイスは、例えば、スマートシティにおけるセンサノード(例えば、スマート水道メータ、スマート電気メータ又はスマート空気検出ノード)、スマートホームにおけるスマートデバイス(例えば、スマートカメラ、プロジェクタ、ディスプレイスクリーン、テレビ、ステレオ、冷蔵庫又は洗濯機)、モノのインターネットにおけるノード、エンターテインメント端末(例えば、AR、VR又は他のウェアラブルデバイス)、スマートオフィスにおけるスマートデバイス(例えば、プリンタ又はプロジェクタ)、車両のインターネットにおける車両のインターネットデバイス、又は日常生活のシナリオにおけるインフラストラクチャ(例えば、自動販売機、セルフサービスナビゲーションコンソール、セルフチェックアウトデバイス又はセルフサービス食品機械)として機能する、より多くのシナリオに更に適用されてもよい。マルチリンクデバイスの具体的な形式は、この出願のこの実施形態では限定されない。これは、単にここでの説明のための例である。

上記のマルチリンクデバイスを参照して、図１ｂは、この出願の実施形態によるマルチリンク通信シナリオの概略図である。図１ｂに示すように、AP MLDは、AP1、AP2、…及びAPnを含み、non-AP MLDは、STA1、STA2、…及びAPnを含む。ここで、nは正の整数である。AP MLD及びnon-AP MLDは、リンク1、リンク2、…及びリンクnを通じて並列に通信してもよい。non-AP MLD内のSTA1は、AP MLD内のAP1とのアソシエーション関係を確立し、non-AP MLD内のSTA2は、AP MLD内のAP2とのアソシエーション関係を確立し、non-AP MLD内のSTAnは、AP MLD内のAPnとのアソシエーション関係を確立する、等である。したがって、non-AP MLD内の1つ以上のSTAとAP MLD内の1つ以上のAPとの間のアソシエーション関係が確立された後に、通信が実行されてもよい。

図１ｃは、この出願の実施形態によるマルチリンク通信シナリオの概略図である。図１ｃに示すように、少なくとも1つのAP及び少なくとも1つのSTAが含まれる。図１ｃは、2つのSTA、例えば、STA1及びSTA2と、1つのnon-AP MLDとを示す。例えば、non-AP MLDは、2つのリンクを通じてAPと通信してもよく、non-AP MLDは、図１ｃに示されていない2つの連携STAを含む。他の例では、STA2又はSTA3は、1つのリンクを通じてAPと通信してもよい。具体的には、図１ｃに示すシステムは、マルチリンク通信とシングルリンク通信との双方を含む。

この出願において提供される方法は、シングルユーザアップリンク/ダウンリンク伝送、マルチユーザアップリンク/ダウンリンク伝送、車両対全てのもの(vehicle-to-everything, V2X、Xはいずれかのものを表すことができる)及びデバイス対デバイス(device-to-device, D2D)に適用可能でもよいが、これらに限定されない。例えば、V2Xは、車両対車両(vehicle-to-vehicle, V2V)、車両対インフラストラクチャ(vehicle-to-infrastructure, V2I)、車両対歩行者(vehicle-to-pedestrian, V2P)、車両対ネットワーク(vehicle-to-network, V2N)等を含んでもよい。

この出願において以下に示す送信機は、ブロック確認応答(block acknowledgement, BA)メカニズムを使用することによりデータを送信するためのMLDとして理解され得る。送信機はまた、送信元MLD(originator MLD)とも呼ばれてもよく、データを受信するパーティは、受信機と呼ばれる。受信機はまた、受信側MLD(recipient MLD)とも呼ばれてもよい。例えば、送信機はnon-AP MLDでもよく、受信機はAP MLDでもよい。他の例では、送信機はAP MLDでもよく、受信機はnon-AP MLDでもよい。送信機と受信機との間には複数のリンクが存在してもよい。各リンクは、送信元MLDと連携するSTA(a STA affiliated with the originator MLD)と、受信側MLDと連携するSTA(a STA affiliated with the recipient MLD)との間の通信に使用される。

図２は、この出願の実施形態によるマルチリンク通信方法の概略フローチャートである。マルチリンク通信方法は、ブロック確認応答(block acknowledgement, BA)メカニズムに基づいて実現される。BAメカニズムは、複数の「確認応答(acknowledgement)」を1つのフレームに集約し、それにより、チャネル効率を改善してもよい。図２に示すように、当該方法は以下のステップを含む。

201:送信機は、ブロック確認応答追加(add BA, ADDBA)要求(request)フレームを受信機に送信する。対応して、受信機は、ADDBA要求フレームを受信する。

202:受信機は、ADDBA応答(response)フレームを送信機に送信する。対応して、送信機は、ADDBA応答フレームを受信する。

上記のステップ201及びステップ202を通じて、これは、BAプロトコルの正常な確立、BAメカニズムの正常な確立、又は送信機と受信機との間のBAセッションの正常な確立と呼ばれてもよい。

203:送信機は、集約媒体アクセス制御プロトコルデータユニット(aggregate MPDU, A-MPDU)を受信機に送信する。対応して、受信機はA-MPDUを受信する。

送信機と受信機との間で確立されたBAセッションに基づいて、送信機が複数の媒体アクセス制御(media access control, MAC)プロトコルデータユニット(MAC protocol data unit, MPDU)を受信機に送信する必要があるとき、送信機は、集約を通じて複数のMPDUを1つのA-MPDUに変換してもよいことが理解され得る。言い換えると、A-MPDUを受信した後に、受信機は、A-MPDUに対して集約解除制御(deaggregation control)を実行して、複数のMPDUを取得する。例えば、A-MPDU内の各MPDUはシーケンス番号(sequence number, SN)を有し、SNはA-MPDU内の各MPDUのシーケンスを示す。

例えば、1つのA-MPDUに含まれるMPDUの最大数は1024でもよい。例えば、スコアボードのウィンドウサイズは変更されてもよく、ADDBA要求フレームとADDBA応答フレームとの間の相互作用におけるネゴシエーションを通じて決定されてもよい。例えば、スコアボードのウィンドウサイズは、64、128、256、512、1024等でもよい。1つのA-MPDUにより集約されるデータは、スコアボードのウィンドウサイズを超えないが、スコアボードのウィンドウサイズよりも小さくてもよい。

204:送信機は、BA要求(BA request, BAR)フレームを受信機に送信する。対応して、受信機は、BARフレームを受信する。

ステップ204は、送信機がBA要求フレームを送信する例を使用することにより示されていることが理解され得る。任意選択で、送信機は、送信されるA-MPDU内の確認応答ポリシー(ACK policy)を暗黙的BAR(implicit BAR)に更に設定してもよい。したがって、送信機は、BARフレームを別個に送信する必要がなくてもよい。

205:受信機は、BARフレームに基づいてBAフレームを送信機に送信し、BAフレームは、A-MPDU内のMPDUの受信状態を確認応答するために使用される。対応して、送信機はBAフレームを受信する。

一般的に、受信機は、ブロック確認応答レコード(BA record)を維持する必要がある。BAレコードは、シーケンス番号に基づいてインデックス付けされたビットマップと、ビットマップ内の最低シーケンス番号位置を示してもよい、12ビットの符号なし整数の開始シーケンス番号(WinStart_Rにより表されてもよい)と、現在の伝送ウィンドウ内の最高シーケンス番号(WinEnd_Rにより表されてもよい)と、最大ウィンドウサイズ(例えば、WinSize_Rにより表されてもよい)とを含む。説明を容易にするために、以下に、受信機のスコアボードが3つのパラメータ定義、すなわち、WinStart_R、WinSize_R及びWinEnd_Rを含む例を使用することにより、この出願の実施形態において提供される方法について説明する。WinStart_Rは、スコアボードの開始シーケンス番号を表し、WinSize_Rは、スコアボードのウィンドウサイズ(例えば、1024でもよい)を表し、WinEnd_Rは、スコアボードの終了シーケンス番号(スコアボードの現在の終了シーケンス番号)を表す。

例えば、A-MPDUに基づいて複数のMPDUを取得した後に、受信機は、各MPDUに対してスコアボードコンテキスト制御(scoreboard context control)動作を実行する。スコアが記録された後に、受信されたMPDUは、受信並べ替えバッファ(receive reordering buffer)に配信され、MPDUは、SNのシーケンスに基づいてソートされ、正しく受信されたMPDUは、上位レイヤに配信される。正常に受信されないMPDUが並べ替えプロセスにおいて出現した場合、MPDUに対応するSNはWinStart_Bとしてマーキングされ、シーケンスにおいて正常に受信され且つSNに対応するMPDUの前にある全てのMPDUは上位レイヤに配信される。SNの後のMPDUについて、受信機は、SNに対応するMPDUを受信した後にのみ、SNの後の正しく受信されたMPDU及びMPDUを上位レイヤに配信できる。

図３ｆは、この出願の実施形態によるスコアボードコンテキスト制御動作の概略図である。例えば、図３ｆに示すように、1つのA-MPDUを集約解除した後に、受信機は、SN:102、103、105及び100を有する4つのMPDUを取得する。この場合、受信機は、スコアボードコンテキストにおいて、SNに対応するビット位置に1を記録してもよく、ここで、「1」は、SNに対応するMPDUが正しく受信されたことを示し、ビットマップ(bitmap)はスコアリング結果に基づいて形成され、ビットマップは、A-MPDUの対応する確認応答としてBAフレームに配置される。図３ｆでは、WinStart_R=98であり、WinSize_R=12であり、WinEnd_R=109である。

BAレコードのシーケンス番号空間は4096個のSNを含んでもよく、スコアボードのウィンドウはシーケンス番号空間内で動かされてもよい。BAセッションが確立されると、スコアボードが初期化されてもよい。例えば、WinStart_Rは、ADDBA要求フレームにより提供される開始シーケンス番号(start sequence number, SSN)に設定されてもよい。MPDUが到着したとき、MPDUのSNがスコアボードにより表される空間内に入る場合、受信機は、スコアボードをインデックス付けするためにSNを使用し、MPDUの正しい受信を記録する。SNがスコアボードにより表される空間の外側にあるが、WinEnd_R～WinStart_R+2¹¹の範囲内(シーケンス番号空間の半分内)にある場合、受信機は、スコアボードのウィンドウの右端が新たなSNを含むまで、スコアボードのウィンドウを右に動かす(これは、受信機が、WinEnd_RをSNに等しくさせるようにWinEnd_Rを更新することとして理解され得る)。BARフレームが到着したとき、スコアボードのウィンドウは右に動かされ、その結果、WinStart_RはBARフレームにより提供されるSSNに等しくなり、スコアボードの記録された内容を有するBAフレームが返信される。

例えば、SNを有するMPDUを受信したとき、受信機は、MPDUがBAセッションの対応するスコアボードレコードを有するか否かを検査する。BAセッションは、送信機アドレス(transmitter address, TA)及びTIDにより識別される。スコアボードレコードが存在しない場合、受信機は、BAセッションのためのスコアボードを作成し、他のセッションのメモリを再利用してもよい。

この出願の実施形態において示されているマルチリンク通信シナリオでは、送信機と受信機との間の各リンクは、それぞれのスコアボードコンテキスト制御を維持し、MLD共通スコアボードが存在する点に留意すべきである。各リンク上のデバイス(例えば、MLD内の各STA、又はMLD内の各AP)は、リンク上のMPDUの受信状態をフィードバックするために、それぞれのスコアボードコンテキスト制御を使用する。共通スコアボードは、他のリンク上のスコアボードのパラメータ情報、例えば、各リンク上のスコアボードの開始シーケンス番号及び/又は終了シーケンス番号を記録するために、或いは、全てのリンクのスコアボードを統合する情報(例えば、WinStart_B)を記録するために使用されてもよい。

以下に、特定のスコアボードコンテキスト制御動作を参照して、この出願の実施形態において提供される方法について説明する。

例えば、SNは0～4095の範囲である。SNが4095であるとき、SNが1だけ増加した場合、4096の値は0になる。したがって、この出願において以下に示す例におけるSNの数値は、4096に対してモジュロ演算を実行することにより取得される。例えば、受信機は、モジュロ4096を使用することによりSNに対して演算を実行してもよく、SN空間のそれぞれは、モジュロ4096カウンタにより表されてもよい。

図３ａ～図３ｃに示す概略図では、送信機は、2つのリンク、例えば、第1のリンク及び第2のリンクを通じて受信機と通信してもよい。説明を容易にするために、以下では、受信機と連携し且つ第1のリンク上にあるSTAは、第1のSTAと呼ばれ、受信機と連携し且つ第2のリンク上にあるSTAは、第2のSTAと呼ばれる。言い換えると、第1のSTA及び第2のSTAは、同じMLDと連携する。

第1のタイプのスコアボードコンテキスト制御動作:
以下の条件、すなわち、
受信側MLDが各リンクにおいて別々のスコアボードコンテキスト制御を有し、
受信側MLDと連携する全てのSTAが、スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能であり、
受信側MLDと連携するSTAが、WinStart_R+2¹¹≦SN<WinStart_Rを満たし、WinStart_B+2¹¹≦SN<WinStart_Bを満たさないSNを有するMPDUを受信すること
が真である場合、
STAは、WinEnd_R<SN<WinStart_R+2¹¹を満たすSNを有するMPDUがSTAにより受信されたかのように、STAのスコアボードコンテキストを更新してもよい。

図３ａは、この出願の実施形態によるスコアボードコンテキスト制御動作の概略図である。例えば、同じTIDが4つのA-MPDUに対応し、各A-MPDUの集約長さは1024であり、言い換えると、各A-MPDUは1024個のMPDUを含み、各A-MPDUの確認応答ポリシーは即時ブロック確認応答である。第1のSTAは、0～1023のSNを有する1番目のA-MPDU(例えば、図３ａに示すA-MPDU1)を受信する。第2のSTAは、1024～2047のSNを有する2番目のA-MPDU(例えば、図３ａに示すA-MPDU2)と、2048～3071のSNを有する3番目のA-MPDU(例えば、図３ａに示すA-MPDU3)とを受信する。第1のSTAは、3072～4095のSNを有する4番目のA-MPDU(例えば、図３ａに示すA-MPDU4)を受信する。図３ｂに示すA-MPDUとSNとの間の関係の説明については、図３ａを参照することが理解され得る。詳細は、以下では1つずつ説明しない。

第1のSTAが1番目のA-MPDUのSNに基づいて第1のSTAのスコアボードコンテキストを更新した後に、第1のSTAのスコアボード(第1のリンクのスコアボードとも呼ばれてもよい)において、WinStart_R=0であり、WinEnd_R=1023である。第2のSTAが2番目のA-MPDUのSN及び3番目のA-MPDUのSNに基づいて第2のSTAのスコアボードコンテキストを更新した後に、第2のSTAのスコアボード(第2のリンクのスコアボードとも呼ばれてもよい)において、WinStart_R=2048であり、WinEnd_R=3071である。さらに、第1のSTAのスコアボード及び第2のSTAのスコアボードにおいて、WinStart_B=3072である。

第1のタイプのスコアボードコンテキスト制御動作に基づいて、第1のSTAにより受信された4番目のA-MPDUのSNが0+2048≦SN<0を満たし、SNが1024(4096に基づいて3072と2048との和に対してモジュロ演算を実行することにより取得される)≦SN<3072を満たさないとき、第1のSTAは、4番目のA-MPDUのSNに基づいて第1のSTAのスコアボードコンテキストを更新してもよい。4番目のA-MPDUのSNは3072～4095であるので、第1のSTAが4番目のA-MPDU内の全てのMPDUを正常に受信した場合、第1のSTAのスコアボードは、WinStart_R=3072及びWinEnd_R=4095に更新される。

しかし、第1のSTA及び第2のSTAにより受信されたA-MPDUが図３ｂに示されるものであるとき、第1のSTAが、第1のタイプのスコアボードコンテキスト制御動作に基づいて、0～1023のSNを有する5番目のA-MPDU(図３ｂに示すA-MPDU5)を受信したとき、第1のSTAは、5番目のA-MPDU内の全てのMPDUの受信状態を正しくフィードバックできない。

上記の問題を解決するために、この出願の実施形態は、第2のタイプのスコアボードコンテキスト制御動作を更に提供する。
以下の条件、すなわち、
受信側MLDが各リンクにおいて別々のスコアボードコンテキスト制御を有し、
受信側MLDと連携する全てのSTAが、スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能であり、
受信側MLDと連携するSTAが、WinStart_R≦SN<WinEnd_Rを満たすSNを有するMPDUを受信し、
受信側MLDと連携する他のSTAが、WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUを受信していること
が真である場合、
STAは、STAのスコアボードコンテキストをリフレッシュ(又はフラッシュ)及び更新してもよい。

上記に示す受信側MLDは、各リンクにおいて別々のスコアボードコンテキスト制御を有し、これはまた、受信側MLDと連携する各STAがそれぞれのスコアボードコンテキスト制御を維持することとして理解され得る。

この出願のこの実施形態では、STAがSTAのスコアボードコンテキストをリフレッシュすることは、STAがSTAのスコアボードコンテキストを初期化すること、STAのスコアボードコンテキストをゼロにすること、スコアボードコンテキストに既に記録されている内容をクリアすること、スコアボードコンテキストのキャッシュをクリアすること等を意味する点に留意すべきである。STAのスコアボードコンテキストを更新することは、STAがスコアボードコンテキスト内の既存の内容に基づいて更新を実行してもよいことを意味する。

図３ｂが例として使用される。第1のSTAにより受信された5番目のA-MPDUのSNは、0≦SN<1023を満たす。第2のSTAのスコアボードコンテキスト(すなわち、他のSTAのスコアボード)により受信されたMPDUのSNは、3072≦SN<4096を満たす。したがって、第1のSTAは、第1のSTAのスコアボードをリフレッシュし、第1のSTAのスコアボードコンテキストを更新してもよい。言い換えると、第1のSTAは、5番目のA-MPDUを受信する前にレコードをクリアして、5番目のA-MPDUのSNを使用することにより初期化されたスコアボードコンテキストを更新してもよい。したがって、第1のSTAが5番目のA-MPDU内の全てのMPDUを正常に受信した場合、第1のSTAのスコアボードは、WinStart_R=0及びWinEnd_R=1023にリフレッシュ及び更新される。

更に他のシナリオでは、第1のSTA及び第2のSTAにより受信されたA-MPDUが図３ｃに示されるものであるとき、第1のSTAが6番目のA-MPDU(図３ｃに示すA-MPDU6)を受信する前に、第1のSTAのスコアボードコンテキストにおいて、WinStart_R=0であり、WinEnd_R=1023である。受信機が6番目のA-MPDUを受信したとき、SNは1024～1500であるので、6番目のA-MPDUのSNは、上記の第1のタイプのスコアボードコンテキスト制御動作にも属さず、上記の第2のタイプのスコアボードコンテキスト制御動作にも属さない。したがって、第1のSTAは、第1のSTAのスコアボードコンテキストをどのように更新すべきかを知ることができない。これはまた、以下のように理解され得る。受信機が6番目のA-MPDUを受信したとき、第1のSTAにより受信されたMPDUのSNがWinEnd_R≦SN<WinStart_R+2¹¹の範囲内に入る場合は、上記の第2のタイプのスコアボードコンテキスト制御動作において考慮されない。第1のSTAのスコアボードのWinEnd_Rが1500の位置に直接動かされ、WinStart_Rが477(すなわち、1500-1023)にある場合、BAフレームがフィードバックされるとき、前のラウンドにおける477～1023の状態情報が誤ってフィードバックされる。

上記の問題を解決するために、この出願の実施形態は、第3のタイプのスコアボードコンテキスト制御動作を提供する。
以下の条件、すなわち、
受信側MLDが各リンクにおいて別々のスコアボードコンテキスト制御を有し、
受信側MLDと連携する全てのSTAが、スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能であり、
受信側MLDと連携するSTAが、WinStart_R≦SN<WinStart_R+2¹¹を満たすSNを有するMPDUを受信し、
受信側MLDと連携する他のSTAが、WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUを受信していること
が真である場合、
STAは、STAのスコアボードコンテキストをリフレッシュ及び更新してもよい(If the following conditions are true: a recipient MLD has a separate scoreboard context control in each link; the STA affiliated with the MLD is capable of using reordering buffer information to update its scoreboard context; a STA affiliated with the MLD receives a frame with SN that is WinStartR≦SN<WinStartR+211; the other STA affiliated with the MLD receives a frame with SN that is WinStartB-WinSizeR≦SN<WinStartB; the STA shall flush the scoreboard context and update the scoreboard context.)。

上記の第3のタイプのスコアボードコンテキスト制御動作に基づいて、例えば、図３ｃが例として使用され、第1のSTAが6番目のA-MPDUを受信しない前に、第1のSTAのスコアボードコンテキストにおいて、WinStart_R=0であり、WinEnd_R=1023である。第1のSTAが6番目のA-MPDUを受信したとき、6番目のA-MPDUのSNは0≦SN<0+2¹¹を満たすので、他のSTA(図３ｃに示す第2のSTA)により既に受信されているA-MPDUのSNはWinStart_B-WinSize_R≦SN<WinStart_B(WinStart_B=1024)を満たす。したがって、第1のSTAは、第1のSTAのスコアボードコンテキストをリフレッシュし、スコアボードコンテキストを更新してもよい。更新されたスコアボードコンテキストでは、WinStart_R=477であり、WinEnd_R=1500である。

上記の第1のタイプのスコアボードコンテキスト制御動作及び第2のタイプのスコアボードコンテキスト制御動作と組み合わせて、受信側MLDと連携するSTAは、MPDUが取得される毎にスコアボードコンテキストをリフレッシュしてもよい。この方式は、ローカルスコアボードを不適切にフラッシュするという問題を有する。

STAがA-MPDUを受信すると仮定する。A-MPDUは、第1のMPDUと第2のMPDUとを含み、ローカルスコアボードコンテキストは、第1のMPDUのSNに基づいて1回フラッシュされてもよい。ローカルスコアボードコンテキストが第2のMPDUに基づいてフラッシュされるとき、第1のMPDUのSNに関係する、フィードバックされないBAフレームのスコアボードコンテキストがフラッシュされる。STAが第1のMPDUのSN1に基づいてローカルスコアボードコンテキストをフラッシュした後に、STAはBAフレームをフィードバックしない。この場合、ローカルスコアボードコンテキストが第2のMPDUに基づいて次にフラッシュされる場合、STAはBAフレームを正しくフィードバックできない。

上記の問題を解決するために、この出願の実施形態は、第4のタイプのスコアボードコンテキスト制御動作を提供する。
以下の条件、すなわち、
受信側MLDが各リンクにおいて別々のスコアボードコンテキスト制御を有し、
受信側MLDと連携する全てのSTAが、スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能であり、
受信側MLDと連携するSTAが、WinStart_R≦SN<WinEnd_Rを満たすSNを有するMPDUを受信し、
受信側MLDと連携する他のSTAが、WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUを受信しており、
現在受信されているA-MPDU内のSNを有する他のMPDUがまだ全ての上記の条件を満たしていないか(no other frame with an SN in current A-MPDU that already fulfills all above conditions)、全ての上記の条件を満たしているものが、STAにより受信された、A-MPDU内のSNを有する1番目のMPDUであるか(it is the first frame with an SN in current A-MPDU that fulfills all above conditions)、或いは、STAのスコアボードが現在受信されているA-MPDU内のMPDUに基づいてリフレッシュされていないこと(the scoreboard is not flushed based on a frame in current A-MPDU)
が真である場合、
STAは、STAのスコアボードコンテキストをリフレッシュ及び更新してもよい(If the following conditions are true: a recipient MLD has a separate scoreboard context control in each link, the STA affiliated with the MLD is capable of using reordering buffer information to update its scoreboard context; a STA affiliated with the MLD receives a frame with SN that is WinStart_R≦SN<WinEnd_R; the other STA affiliated with the MLD receives a frame with SN that is WinStart_B-WinSize_R≦SN<WinStart_B; no other frame with an SN in current A-MPDU that already fulfills all above conditions; the STA shall flush the scoreboard context and update the scoreboard context.)。

言い換えると、第4のタイプのスコアボードコンテキスト制御動作では、受信機がA-MPDUを取得し、A-MPDUに含まれる複数のMPDUが全てSTAに送信され、複数のMPDUのSNが全てWinStart_R≦SN<WinEnd_Rを満たすとき、STAは、最後の条件以外の全ての条件を満たすA-MPDU内の1番目のMPDUに基づいて、STAのスコアボードコンテキストをリフレッシュしてもよい。STAは、最後の条件以外の全ての条件を満たすA-MPDU内の1番目ではないMPDUのSNに基づいてSTAのスコアボードコンテキストをリフレッシュできないとも言われてもよい。

図３ｄに示す概略図が例として使用される。第1のSTAが、500～1023のSNを有する2つのA-MPDUと、0～499のSNを有する2つのA-MPDUとを受信した後に、2つのA-MPDUの双方が上記の第2のタイプのスコアボードコンテキスト制御動作を満たすので、第1のSTAは、別々に2回フラッシュを実行する。例えば、0～499のSNを有するA-MPDUが受信された後にローカルスコアボードコンテキストがフラッシュされるとき、500～1023のSNを有する、返信されていないBAフレームのBAレコードもフラッシュされる。図３ｄに示す1番目の確認応答ポリシー(ACK policy)は、第1のSTAがBAフレームを一時的にフィードバックする必要がないことを示し、図３ｄに示す2番目の確認応答ポリシー(暗黙的BARとも呼ばれてもよい)は、第1のSTAがBAフレームをフィードバックする必要があることを示すことが理解され得る。

上記の問題を解決するために、この出願の実施形態は、第5のタイプのスコアボードコンテキスト制御動作を更に提供する。
以下の条件、すなわち、
受信側MLDが各リンクにおいて別々のスコアボードコンテキスト制御を有し、
受信側MLDと連携する全てのSTAが、スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能であり、
受信側MLDと連携するSTAが、WinStart_R≦SN<WinEnd_Rを満たすSNを有するMPDUを受信し、
受信側MLDと連携する他のSTAが、WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUを受信しており、
現在受信されているA-MPDUの前に受信された他のA-MPDU内の如何なるMPDUもBAにより応答されていないものではないか、現在受信されているA-MPDUの前に受信されたいずれかのA-MPDU内の如何なるMPDUもBAにより応答されていないものではないか(no any frame that is carried in any A-MPDU that received before current A-MPDU is not responded by a BA)、或いは、現在受信されているA-MPDUの前に受信されたいずれかのA-MPDUで搬送された全てのMPDUがBAにより応答されていること(all frames that are carried in the A-MPDUs that received before current A-MPDU has been responded by BAs)
が真である場合、
STAは、STAのスコアボードコンテキストをリフレッシュ及び更新してもよい(If the following conditions are true: a recipient MLD has a separate scoreboard context control in each link, the STA affiliated with the MLD is capable of using reordering buffer information to update its scoreboard context. A STA affiliated with the MLD receives a frame with SN that is WinStart_R≦SN<WinEnd_R; the other STA affiliated with the MLD receives a frame with SN that is WinStart_B-WinSize_R≦SN<WinStart_B; no any frame that is carried in any A-MPDU that received before current A-MPDU is not responded by a BA; the STA shall flush the scoreboard context and update the scoreboard context.)。

言い換えると、第5のタイプのスコアボードコンテキスト制御動作では、STAが2つのA-MPDUを連続して受信するとき、且つ、1番目のA-MPDU内のMPDUのSNがWinStart_R≦SN<WinEnd_Rを満たすとき、STAは、STAのスコアボードコンテキストをリフレッシュしてもよい。STAが1番目のA-MPDUのBAフレームをフィードバックしないとき、2番目のA-MPDU内のMPDUのSNが上記の条件を満たす場合であっても、STAは、STAのスコアボードコンテキストをリフレッシュしないが、STAのスコアボードコンテキストを更新してもよい。

図３ｅに示す概略図が例として使用される。第1のSTAが200～299のSNを有するA-MPDUを受信した後に、A-MPDUは、上記の第2のタイプのスコアボードコンテキスト制御動作を満たし、第1のSTA内のスコアボードコンテキストがリフレッシュされる。しかし、図３ｅに示すシナリオでは、1番目のA-MPDUと、3番目のA-MPDUと、4番目のA-MPDUとの間のSN関係に従って、第1のSTAは、フラッシュを実行する必要はない。

上記の問題を解決するために、この出願の実施形態は、第6のタイプのスコアボードコンテキスト制御動作を提供する。
以下の条件、すなわち、
受信側MLDが各リンクにおいて別々のスコアボードコンテキスト制御を有し、
受信側MLDと連携する全てのSTAが、スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能であり、
受信側MLDと連携するSTAが、WinStart_R≦SN<WinEnd_Rを満たすSNを有するMPDUを受信し、
WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUがSTAにより受信されない(受信されていない)か(none of a frame with SN that is WinStart_B-WinSize_R≦SN<WinStart_B is (was) received by the STA)、或いは、WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有する全てのMPDUが受信側MLDと連携する他のSTAにより受信されること(受信されていること)(all frames with SN that are WinStart_B-WinSize_R≦SN<WinStart_B are (were) received by the other STA(s))、ここで、WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUは、現在の並べ替えバッファのWinStart_Bを示し、SNがWinStart_B-WinSize_R≦SN<WinStart_Bを満たす範囲は考慮されないが、MPDUは、並べ替えバッファ内の前のラウンド又はそれより前に受信されたMPDUである点に留意すべきである、
が真である場合、
STAは、STAのスコアボードコンテキストをリフレッシュ及び更新してもよい(If the following conditions are true: a recipient MLD has a separate scoreboard context control in each link, the STA affiliated with the MLD is capable of using reordering buffer information to update its scoreboard context; a STA affiliated with the MLD receives a frame with SN that is WinStart_R≦SN<WinEnd_R; none of a frame with SN that is WinStart_B-WinSize_R≦SN<WinStart_B is (was) received by the STA; the STA shall flush the scoreboard context and update the scoreboard context.)。

言い換えると、第6のタイプのスコアボードコンテキスト制御動作では、STAがWinStart_R≦SN<WinEnd_Rを満たすSNを有するMPDUを受信し、WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUがSTAにより受信されないとき、STAは、STAのスコアボードコンテキストをリフレッシュしてもよい。

図３ｅが例として使用される。第1のSTAが2番目のA-MPDU及び3番目のA-MPDUを受信しない前に、第1のSTAのスコアボードコンテキストにおいて、WinStart_R=199-1023+4096=3272であり、WinEnd_R=199であり、WinStart_B=200である。第1のSTAが3番目のA-MPDUを受信したとき、3番目のA-MPDUのSNは300～399であり、上記の条件は満たされないので、第1のSTAのスコアボードコンテキストは更新されない。4番目のA-MPDUについても同様である。これは、1つずつ列挙されない。

上記の第3のタイプのスコアボードコンテキスト制御動作～第6のタイプのスコアボードコンテキスト制御動作は、別々に実現されてもよく、或いは、互いに組み合わされてもよいことが理解され得る。例えば、第3のタイプのスコアボードコンテキスト制御動作と第4のタイプのスコアボードコンテキスト制御動作とが組み合わされて、例えば、第7のタイプのスコアボードコンテキスト制御動作を取得してもよい。
以下の条件、すなわち、
受信側MLDが各リンクにおいて別々のスコアボードコンテキスト制御を有し、
受信側MLDと連携する全てのSTAが、スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能であり、
受信側MLDと連携するSTAが、WinStart_R≦SN<WinStart_R+2¹¹を満たすSNを有するMPDUを受信し、
受信側MLDと連携する他のSTAが、WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUを受信しており、
現在受信されているA-MPDU内のSNを有する他のMPDUがまだ全ての上記の条件を満たしていないか、全ての上記の条件を満たしているものが、STAにより受信された、A-MPDU内のSNを有する1番目のMPDUであるか、或いは、STAのスコアボードコンテキストが現在受信されているA-MPDU内のMPDUに基づいてリフレッシュされていないこと
が真である場合、
STAは、STAのスコアボードコンテキストをリフレッシュ及び更新してもよい。

このように、第7のタイプのスコアボードコンテキスト制御動作は、上記の図３ｃに示す問題と、上記に示す各MPDUについてスコアボードコンテキストをリフレッシュするという問題との双方を解決できる。

例えば、第3のタイプのスコアボードコンテキスト制御動作と第5のタイプのスコアボードコンテキスト制御動作とが組み合わされて、例えば、第8のタイプのスコアボードコンテキスト制御動作を取得してもよい。
以下の条件、すなわち、
受信側MLDが各リンクにおいて別々のスコアボードコンテキスト制御を有し、
受信側MLDと連携する全てのSTAが、スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能であり、
受信側MLDと連携するSTAが、WinStart_R≦SN<WinStart_R+2¹¹を満たすSNを有するMPDUを受信し、
受信側MLDと連携する他のSTAが、WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUを受信しており、
現在受信されているA-MPDUの前に受信された他のA-MPDU内の如何なるMPDUもBAにより応答されていないものではないか、現在受信されているA-MPDUの前に受信されたいずれかのA-MPDU内の如何なるMPDUもBAにより応答されていないものではないか、或いは、現在受信されているA-MPDUの前に受信されたいずれかのA-MPDUで搬送された全てのMPDUがBAにより応答されていること
が真である場合、
STAは、STAのスコアボードコンテキストをリフレッシュ及び更新してもよい。

このように、第8のタイプのスコアボードコンテキスト制御動作は、上記の図３ｃ及び図３ｄに示す問題を解決できる。

この出願のこの実施形態に示す第4のタイプのスコアボードコンテキスト制御動作及び第5のタイプのスコアボードコンテキスト制御動作も組み合わされてもよいことが理解され得る。詳細は、ここでは1つずつ再び説明しない。

例えば、第3のタイプのスコアボードコンテキスト制御動作と第4のタイプのスコアボードコンテキスト制御動作と第5のタイプのスコアボードコンテキスト制御動作とが組み合わされて、例えば、第9のタイプのスコアボードコンテキスト制御動作を取得してもよい。
以下の条件、すなわち、
受信側MLDが各リンクにおいて別々のスコアボードコンテキスト制御を有し、
受信側MLDと連携する全てのSTAが、スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能であり、
受信側MLDと連携するSTAが、WinStart_R≦SN<WinStart_R+2¹¹を満たすSNを有するMPDUを受信し、
受信側MLDと連携する他のSTAが、WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUを受信し、
現在受信されているA-MPDU内のSNを有する他のMPDUがまだ全ての上記の条件を満たしていないか、全ての上記の条件を満たしているものが、STAにより受信された、現在受信されているA-MPDU内のSNを有する1番目のMPDUであるか、或いは、STAのスコアボードコンテキストが現在受信されているA-MPDU内のMPDUに基づいてリフレッシュされておらず、
現在受信されているA-MPDUの前に受信された他のA-MPDU内の如何なるMPDUもBAにより応答されていないものではないか、現在受信されているA-MPDUの前に受信されたいずれかのA-MPDU内の如何なるMPDUもBAにより応答されていないものではないか、或いは、現在受信されているA-MPDUの前に受信されたいずれかのA-MPDUで搬送された全てのMPDUがBAにより応答されていること
が真である場合、
STAは、STAのスコアボードコンテキストをリフレッシュ及び更新してもよい。

このように、第9のタイプのスコアボードコンテキスト制御動作は、上記の図３ｃ及び図３ｄに示す問題を効果的に解決できる。

例えば、第3のタイプのスコアボードコンテキスト制御動作と第4のタイプのスコアボードコンテキスト制御動作と第5のタイプのスコアボードコンテキスト制御動作と第6のタイプのスコアボードコンテキスト制御動作とが組み合わされて、例えば、第10のタイプのスコアボードコンテキスト制御動作を取得してもよい。
以下の条件、すなわち、
受信側MLDが各リンクにおいて別々のスコアボードコンテキスト制御を有し、
受信側MLDと連携する全てのSTAが、スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能であり、
受信側MLDと連携するSTAが、WinStart_R≦SN<WinStart_R+2¹¹を満たすSNを有するMPDUを受信し、
WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUがSTAにより受信されないか、或いは、WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUが受信側MLDと連携する他のSTAにより受信され、
現在受信されているA-MPDUの前に受信された他のA-MPDU内の如何なるMPDUもBAにより応答されていないものではないか、現在受信されているA-MPDUの前に受信されたいずれかのA-MPDU内の如何なるMPDUもBAにより応答されていないものではないか、或いは、現在受信されているA-MPDUの前に受信されたいずれかのA-MPDUで搬送された全てのMPDUがBAにより応答されており、
ここで、STAにより上記の条件を実行するシーケンスは限定されないことが理解され得る、
現在受信されているA-MPDU内のSNを有する他のMPDUがまだ全ての上記の条件を満たしていないか、全ての上記の条件を満たしているものが、STAにより受信された、A-MPDU内のSNを有する1番目のMPDUであるか、或いは、STAのスコアボードコンテキストが現在受信されているA-MPDU内のMPDUに基づいてリフレッシュされていないこと
が真である場合、
STAは、STAのスコアボードコンテキストをリフレッシュ及び更新してもよい。

このように、第10のタイプのスコアボードコンテキスト制御動作は、上記の図３ｃ～図３ｅに示す問題を効果的に解決できる。

例えば、上記の第10のタイプのスコアボードコンテキスト制御動作は、以下のように更に理解され得る。
以下の条件、すなわち、
受信側MLDが各リンクにおいて別々のスコアボードコンテキスト制御を有し、
MLDと連携するSTAが、そのスコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能であり、
MLDと連携するSTAが、WinStart_R≦SN<WinStart_R+2¹¹であるSNを有するフレームを受信し、
WinStart_B-WinSize_R≦SN<WinStart_BであるSNを有するフレームのいずれもSTAにより受信されず(受信されておらず)、
現在のA-MPDUの前に受信された他のA-MPDUで搬送された如何なるフレームもBAにより応答されていないものではなく、
上記の全ての条件を既に満たしている現在のA-MPDU内のSNを有する他のフレームがないこと
が真である場合、
STAは、スコアボードコンテキストをフラッシュし、スコアボードコンテキストを更新するものとする
(if the following conditions are true:
a recipient MLD has a separate scoreboard context control in each link;
the STA affiliated with the MLD is capable of using reordering buffer information to update its scoreboard context;
a STA affiliated with the MLD receives a frame with SN that is WinStart_R≦SN<WinStart_R+2¹¹;
none of a frame with SN that is WinStart_B-WinSize_R≦SN<WinStart_B is (was) received by the STA;
no any frame that is carried in another A-MPDU that received before current A-MPDU is not responded by a BA; and
no other frame with an SN in current A-MPDU that already fulfills all above conditions,
the STA shall flush the scoreboard context and update the scoreboard context.)。

図３ａ～図３ｅは、1つのA-MPDUが複数のMPDUを含み、各SNが1つのMPDUに対応してもよい例を使用することにより全て示されていることが理解され得る。この出願では、上記に示すA-MPDUのSNは、SNが同じTIDに属する例を使用することにより全て示されていることが理解され得る。

上記の第3～第10のタイプのスコアボードコンテキスト制御動作を参照して、この出願の実施形態は、マルチリンク通信方法を提供する。当該方法における送信機及び受信機の説明については、上記の説明を参照する。詳細は、ここでは1つずつ再び説明しない。図４に示すように、マルチリンク通信方法は、以下のステップを含む。

401:送信機は、第1のA-MPDUを受信機に送信し、受信機は、第1のA-MPDUを受信する。

任意選択で、送信機と受信機との間に1つのリンクが存在してもよい。

任意選択で、送信機と受信機との間に少なくとも2つのリンクが存在してもよい。

任意選択で、第1のA-MPDUは1つのMPDUを含んでもよい。任意選択で、第1のA-MPDUは、少なくとも2つのMPDUを含んでもよい。

A-MPDUはPPDUで搬送されることが理解され得る。一般的に、受信ステーションについて、1つのPPDUは、1つのA-MPDUのみを搬送する。したがって、この出願のこの実施形態におけるA-MPDUは、PPDUとして更に理解され得る。これは、この出願のこの実施形態では限定されない。

402:受信機は、ローカルに記録されたスコアボードコンテキストを取得し、第1のA-MPDUが以下の条件のうちいずれか1つ以上を満たすとき、第1のA-MPDUのSNに基づいてスコアボードコンテキストをリフレッシュする。

この出願のこの実施形態におけるローカルに記録されたスコアボードコンテキストは、初期化されたスコアボードコンテキスト、第1のA-MPDUが受信される前に受信機により受信されているA-MPDUに基づいて受信機により更新されたスコアボードコンテキスト、第1のA-MPDUが受信される前に受信機により受信されているA-MPDUに基づいて受信機によりリフレッシュされたスコアボードコンテキスト等でもよいことが理解され得る。これは、ここでは1つずつ列挙されない。

第1のA-MPDUが満たす条件は、以下を含む。
第1の条件:受信機と連携するSTAが、WinStart_R≦SN<WinStart_R+2¹¹を満たすSNを有するMPDUを受信すること
第2の条件:WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUのいずれもSTAにより受信されないこと、又はWinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有する全てのMPDUが受信機と連携する他のSTAにより受信されること
第3の条件:現在受信されているA-MPDUの前に受信された他のA-MPDU内の如何なるMPDUもBAにより応答されていないものではないこと、第1のA-MPDUの前に受信されたいずれかのA-MPDU内の如何なるMPDUもBAにより応答されていないものではないこと、又は第1のA-MPDUの前に受信されたいずれかのA-MPDUで搬送された全てのMPDUがBAにより応答していること
第4の条件:第1のA-MPDU内のSNを有する他のMPDUが上記の条件(上記の第1の条件～第3の条件)をまだ満たしていないこと、受信機と連携するSTAにより受信されたSNを有するMPDUが、第1のA-MPDU内にあり且つ上記の条件を満たす1番目のMPDUであること、又は受信機と連携するSTAのスコアボードコンテキストが第1のA-MPDU内のMPDUに基づいてリフレッシュされていないこと

STAにより第1の条件～第3の条件を実行するシーケンスは、この出願のこの実施形態では限定されないことが理解され得る。

任意選択で、第1のA-MPDUが上記の第1の条件～第4の条件のいずれか1つを満たすとき、第1のA-MPDUにより満たされる他の条件については、上記の第3のタイプのスコアボードコンテキスト制御動作～第6のタイプのスコアボードコンテキスト制御動作の関連する説明を参照する。

任意選択で、第1のA-MPDUが上記の第1の条件～第4の条件のいずれか2つを満たすとき、第1のA-MPDUにより満たされる他の条件については、上記の第6のタイプのスコアボードコンテキスト制御動作～第9のタイプのコンテキスト制御動作の関連する説明を参照する。

任意選択で、第1のA-MPDUが上記の第1の条件～第4の条件を満たすとき、第1のA-MPDUにより満たされる他の条件については、上記の第10のタイプのスコアボードコンテキスト制御動作の関連する説明を参照する。

第1のA-MPDUにより満たされる条件については、第3のタイプのスコアボードコンテキスト制御動作～第10のタイプのコンテキスト制御動作の上記の説明を参照することが理解され得る。詳細は、ここでは1つずつ再び説明しない。

403:受信機は、BAフレームを送信機に送信し、BAフレームは、第1のA-MPDU内のMPDUの受信状態を確認応答するために使用される。

この出願のこの実施形態に示されていないADDBA要求フレーム、ADDBA応答フレーム及びBARフレームの説明については、上記に示す図２を参照することが理解され得る。詳細は、ここでは1つずつ再び説明しない。

図４に示すマルチリンク通信方法では、受信機は、第3のタイプのスコアボードコンテキスト制御動作～第10のタイプのスコアボードコンテキスト制御動作に基づいて、ローカルスコアボードコンテキストをリフレッシュ又は更新してもよい。この出願の実施形態は、マルチリンク通信方法を更に提供する。当該方法では、送信機は、指示情報を使用することにより、受信機がローカルスコアボードコンテキストをリフレッシュするか否かを示してもよく、それにより、受信機の複雑さを効果的に低減する。

図５は、この出願の実施形態による他のマルチリンク通信方法の概略フローチャートである。当該方法における送信機及び受信機の説明については、上記の説明を参照する。詳細は、ここでは1つずつ再び説明しない。図５に示すように、マルチリンク通信方法は、以下のステップを含む。

501:送信機は、第2のA-MPDUを受信機に送信し、第2のA-MPDUは指示情報を含み、指示情報は、受信機のスコアボードコンテキストをリフレッシュするか否かを受信機に指示する。対応して、受信機は、第2のA-MPDUを受信する。

図４に示す方法では、受信機におけるSTAは、スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能であることが理解され得る。図５に示す方法では、受信機におけるSTAは、並べ替えバッファ情報を使用することによりスコアボードコンテキストを更新することが可能でもよく、或いは、並べ替えバッファ情報を使用することによりスコアボードコンテキストを更新することが可能でなくてもよい。

例えば、指示情報が0に設定されるとき、これは、受信機がローカルスコアボードコンテキストをリフレッシュする必要がないことを示してもよい。他の例では、指示情報が1に設定されるとき、これは、受信機がローカルスコアボードコンテキストをリフレッシュする必要があることを示すか、或いは、受信機がローカルスコアボードコンテキストをリフレッシュすることが可能であることを暗黙的に示してもよい。一般的に、第2のA-MPDUはリンクを通じて伝送され、リンク上でA-MPDUを受信するSTAは一意である。したがって、第2のA-MPDUを伝送するために使用されるリンクに対応するSTAは、指示情報に基づいて、ローカルスコアボードコンテキストをリフレッシュすべきか否かを決定してもよい。

図６ａは、この出願の実施形態によるMPDUサブフレームの構造の概略図である。図６ａに示すように、指示情報は、MPDUデリミタ(delimiter)内の予約済み(reserved)フィールドで搬送されてもよく、或いは、高スループット(high throughput, HT)制御(HT control)フィールドで搬送されてもよい。

HT制御フィールドは、いくつかの制御情報を搬送するために、MPDU(例えば、サービス品質(quality of service, QoS)データ(data)フレーム、サービス品質ヌル(QoS null)フレーム及び管理フレーム)で搬送されてもよい。HT制御フィールドの長さは4バイトである。3つのタイプのHT制御フィールドが存在し、これらはB0ビット及びB1ビットにより区別される。表1に示すように、B0=0であるとき、対応するHT制御フィールドは、高スループット(high throughput, HT)タイプのHT制御フィールドである。B0=1でありB1=0であるとき、対応するHT制御フィールドは、超高スループット(very high throughput, VHT)タイプのHT制御フィールドである。B0=1でありB1=1であるとき、対応するHT制御フィールドは、高効率(high efficiency, HE)タイプのHT制御フィールドである。

HEタイプのHT制御フィールド内のB2～B31は、集約制御(A-control)サブフィールド(subfield)と呼ばれる。図６ｂは、この出願の実施形態による集約制御フィールドのフォーマットの概略図である。集約制御フィールドは、制御リスト(control list)とパディング(padding)部分とを含む。制御リストのビット長は可変であり、制御リストは1つ以上の制御サブフィールド(control subfield)を含んでもよい。パディング部分は、0個以上のビットを含む。図６ｃは、この出願の実施形態による集約制御フィールド内の制御サブフィールドのフォーマットの概略図である。1つの制御サブフィールドは、4ビットの制御識別子(control ID)と制御情報(control information)とを含む。制御識別子は、制御情報を識別するために使用される。制御識別子及び対応する制御情報の長さは、表2に示されている。

MPDUデリミタに含まれるフレーム終了(end of frame, EOF)フィールド、反転(reversed)フィールド、MPDU長(length)フィールド、巡回冗長検査(cyclic redundancy check, CRC)フィールド及びデリミタシグネチャ(delimiter signature)フィールドのような、図６ａに示す他のフィールド、並びにMPDUに含まれるフレーム制御(frame control)フィールド、持続時間/識別子(duration/ID)フィールド、アドレス1(address 1)フィールド～アドレス4(address 4)フィールド、シーケンス制御(sequence control)フィールド、QoS制御(QoS control)フィールド、HT制御(HT control)フィールド、パディング(padding)フィールド等の説明については、関連する標準又はプロトコルを参照することが理解され得る。詳細は、ここでは1つずつ再び説明しない。

上記の説明に基づいて、この出願のこの実施形態は、指示情報を搬送できる2つのHEタイプのHT制御フィールドを提供する。

第1の方法は、CASタイプ制御情報内の予約済み(reversed)ビットを使用することにより指示情報を実現することである。CASタイプの制御情報のフレーム構造は図６ｄに示されている。図６ｄに示すように、CASタイプ制御情報は、アクセスカテゴリ(access category, AC)制約(AC constraint)フィールド、逆方向直接許可(reverse direct grant, RDG)フィールド、パラメータ化空間再利用伝送(parameterized spatial reuse transmission, PSRT)PPDUフィールド、及び予約済み(reserved)フィールドを含んでもよい。図６ｄにおける他のフィールドの関連する説明については、関連する標準又はプロトコルを参照することが理解され得る。詳細は、ここでは1つずつ再び説明しない。

第2の方法は、現在予約されている制御識別子(control ID)を使用することにより、(図６ｃに示すような)新たな制御タイプを確立し、新たな制御タイプの制御情報を使用することにより、新たな制御タイプを示すことである。例えば、指示情報のビット長は1ビットでもよい。

502:受信機は、指示情報に基づいてスコアボードコンテキストをリフレッシュする。

受信機は、代替として、指示情報に基づいてスコアボードコンテキストをリフレッシュしなくてもよいことが理解され得る。例えば、受信機は、スコアボードコンテキストを更新してもよい。

503:受信機は、BAフレームを送信機に送信し、送信機は、BAフレームを受信する。

この出願のこの実施形態において提供される方法によれば、送信機は、指示情報をA-MPDUに追加して、スコアボードコンテキストをリフレッシュするように受信機に指示する。これは、受信機の複雑さを効果的に低減し、受信機によりスコアボードコンテキストをリフレッシュする効率を改善できる。

この出願の実施形態は、マルチリンク通信方法を更に提供する。この実現方式では、受信機におけるSTAは、並べ替えバッファ情報を使用することによりスコアボードコンテキストを更新することが可能でもよく、或いは、並べ替えバッファ情報を使用することによりスコアボードコンテキストを更新することが可能でなくてもよい。

この出願のこの実施形態では、送信機は、伝送されるデータフレーム(すなわち、A-MPDU)内に第1のフィールドを含め、第1のフィールドは、現在のSNの伝送のラウンドを示す。第1のフィールドは、SNラウンドサブフィールド(Round of SN subfield)と呼ばれてもよく、当該フィールドの初期値は0に設定される。データフレームのSNが最大SN値(4095)を超えた後に当該SNが再び0に戻されたとき、SNラウンドサブフィールドの値は1だけ増加する。例えば、SNラウンドサブフィールドが5ビットを含むと仮定すると、SNラウンドサブフィールドの値は0～31でもよい。例えば、SNラウンドサブフィールドの値が31に設定された場合、値が1だけ増加した場合に値は0に戻される。

したがって、データフレームを受信した後に、受信機は、以下の条件、すなわち、
ローカルスコアボードコンテキストがデータフレームのSNに基づいて更新された場合、更新されたローカルスコアボードコンテキストが、更新の前の範囲を少なくとも部分的にカバーし、
SNラウンドサブフィールドの値が、最後に受信されたデータフレームで搬送されるSNラウンドサブフィールドの値と異なること
が満たされる場合、ローカルスコアボードコンテキストを更新する前にローカルスコアボードコンテキストをリフレッシュしてもよい。

例えば、SNラウンドサブフィールドは、図５に示すHEタイプの新たに作成されたHT制御タイプに含まれてもよい(図６ｃに示すように、表2に示す第1の列における未使用IDを使用することにより、新たな制御タイプが新たに作成される)。SNラウンドサブフィールドのビット長は、この出願のこの実施形態では限定されず、例えば、5ビットでもよい。例えば、SNラウンドサブフィールドは、新たに作成されたA-controlタイプを使用することにより搬送されてもよく、或いは、CAS制御タイプの予約済みビットで搬送されてもよい。例えば、図５に示す指示情報のベアラ位置を参照する。

SNラウンドサブフィールドの長さが制限される場合(例えば、5ビット)、値が32回増加した後に元の値が復元されてもよいことが理解され得る。この場合、受信機は、SNラウンドサブフィールドの値が変化するか否かを決定できなくてもよい。しかし、SNラウンドサブフィールドの長さが十分に長い場合、この状況の発生の確率は非常に低く、これは低確率のイベントとして無視されてもよい。

この出願の実施形態は、以下に説明するように、或るタイプのスコアボードコンテキスト制御動作を更に提供する。
受信側MLDと連携するSTAが、STAのスコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能でなく、受信側MLDが各リンクにおいて別々のスコアボードコンテキスト制御を有する場合、STAは、部分状態動作(BAメカニズムの部分状態(partial state)動作を意味する)を実現し、以下の定義された期間、すなわち、
BA及び確認応答されたA-MPDUが1つの伝送機会(transmission opportunity, TXOP)内にある場合のBAを送信した後、且つ、同じリンク上でイニシエータMLDから受信され且つ同じTIDと連携する次のQoSデータフレームのスコアボードコンテキストを処理する前、
BAが現在のTXOPの終わりに送信されない場合、次のQoSデータフレームが新たなTXOPにおいて同じリンク上でイニシエータMLDから受信された後、且つ、スコアボードコンテキストが更新される前
において一時レコードを破棄する必要がある(If a STA affiliated with a recipient MLD in a link is not capable of using reordering buffer information to update its scoreboard context and the recipient MLD has a separate scoreboard context control in each link, the STA shall implement the partial-state operation and should discard the temporary record in the following defined time periods:
After sending a BA where the BA and the acknowledged A-MPDU(s) are in one TXOP and before processing the scoreboard context of the next received the QoS Data frame of the TID from the initiator MLD in the link if BA is transmitted; and
immediate before processing the scoreboard context of the next received the QoS Data frame of the TID from the initiator MLD in the link in a new TXOP if BA is not transmitted at the end of the current TXOP (すなわち、after receiving the next QoS Data frame of the TID from the initiator MLD in the link in a new TXOP and before processing the scoreboard context, if BA is not transmitted at the end of the current TXOP))。

上記の実施形態において、一実施形態において詳細に記載されていない実現方式については、他の実施形態を参照することが理解され得る。

上記のように、スコアボードのウィンドウサイズは、64、128、256、512、1024等でもよい。したがって、上記の第3のタイプのスコアボードコンテキスト制御動作～第10のタイプのスコアボードコンテキスト制御動作に関与する2¹¹は、例としてWinSize_R=1024を使用することにより全て示されている。

スコアボードのウィンドウサイズが1024でないとき、上記の第3のタイプのスコアボードコンテキスト制御動作～第10のタイプのスコアボードコンテキスト制御動作のうち少なくとも1つに関与する2¹¹は、それに従って変化してもよい。

例えば、第3のタイプのスコアボードコンテキスト制御動作が例として使用される。実際には、WinStart_R≦SN<WinStart_R+Q*WinSize_Rの範囲内のフレームが受信されるとき、フレームのスコアボードがフラッシュされる必要がある。例えば、Qは2に等しいか、或いは、Qは3に等しくてもよい。説明を容易にするために、以下では、この出願において提供される方法を説明するための例としてQ=2を使用する。

Q=2であるとき、WinStart_R+2*WinSize_R≦SN<WinStart_R+2₁₁であるときに、第1のSTAはWinStart_R及びWinEnd_Rを更新し、スコアボード(新[WinStart_R,WinEnd_R])範囲と更新前のスコアボード範囲(旧[WinStart_R,WinEnd_R])とは重複しないので、古いデータフレームを受信するレコードはスコアボードに残されない。言い換えると、古いデータのレコードは、BAを使用することにより送信ステーションにフィードバックされない。

臨界点が考慮される場合、WinStart_R≦SN<WinStart_R+2¹¹はまた、WinStart_R≦SN<WinStart_R+2¹¹-1として理解されてもよいことが理解され得る。以下のWinStart_R≦SN<WinStart_R+2*WinSize_Rはまた、WinStart_R≦SN<WinStart_R+2*WinSize_R-1又はWinStart_R≦SN<WinEnd_R+WinSize_Rとしても理解されてもよい。言い換えると、値の丸め、式の簡潔さ等が考慮される場合、この出願においてSNが満たす範囲は、特定の範囲(例えば、-2～+2の範囲)に基づいて調整されてもよい。これは、ここでは1つずつ列挙されない。

説明を容易にするために、以下に、説明のための例として、WinStart_R≦SN<WinStart_R+2*WinSize_R-1を使用する。

Q=2が例として使用され、第3のタイプのスコアボードコンテキスト制御動作は、以下のように更に理解され得る。
以下の条件、すなわち、
受信側MLDが各リンクにおいて別々のスコアボードコンテキスト制御を有し、
受信側MLDと連携する全てのSTAが、スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能であり、
受信側MLDと連携するSTAが、WinStart_R≦SN<WinStart_R+2*WinSize_R-1を満たすSNを有するMPDUを受信し、
受信側MLDと連携する他のSTAが、WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUを受信していること
が真である場合、
STAは、STAのスコアボードコンテキストをリフレッシュ及び更新してもよい(If the following conditions are true: a recipient MLD has a separate scoreboard context control in each link; the STA affiliated with the MLD is capable of using reordering buffer information to update its scoreboard context; a STA affiliated with the MLD receives a frame with SN that is WinStart_R≦SN< WinEnd_R+WinSize_R; the other STA affiliated with the MLD receives a frame with SN that is WinStart_B-WinSize_R≦SN<WinStart_B; the STA shall flush the scoreboard context and update the scoreboard context.)。

第3のタイプのコンテキスト制御動作について、図１０ａは、WinSize_R=256が例として使用される手順である。第1のSTAが6番目のA-MPDU(例えば、図１０ａに示すA-MPDU6)を受信しない前に、第1のSTAのスコアボードコンテキストにおいて、WinStart_R=0であり、WinEnd_R=255である。受信機が6番目のA-MPDUを受信したとき、SNは256～400であるので、6番目のA-MPDUのSNは、上記の第1のタイプのスコアボードコンテキスト制御動作にも属さず、上記の第2のタイプのスコアボードコンテキスト制御動作にも属さない。したがって、第1のSTAは、第1のSTAのスコアボードコンテキストをどのように更新すべきかを知ることができない。これはまた、以下のように理解され得る。受信機が6番目のA-MPDUを受信したとき、第1のSTAにより受信されたMPDUのSNがWinEnd_R≦SN<WinStart_R+2*WinSize_R-1の範囲内に入る場合は、上記の第2のタイプのスコアボードコンテキスト制御動作において考慮されない。第1のSTAのスコアボードのWinEnd_Rが400の位置に直接動かされ、WinStart_Rが145(すなわち、400-255)にある場合、BAフレームがフィードバックされるとき、前のラウンドにおける145～255の状態情報が誤ってフィードバックされる。

しかし、図１０ｂでは、第1のSTAが6番目のA-MPDU(例えば、図１０ｂに示すA-MPDU6)を受信しない前に、第1のSTAのスコアボードコンテキストにおいて、WinStart_R=0であり、WinEnd_R=255である。受信機が6番目のA-MPDUを受信したとき、SNは512～767であるので、6番目のA-MPDUのSNは、上記の第1のタイプのスコアボードコンテキスト制御動作にも属さず、上記の第2のタイプのスコアボードコンテキスト制御動作にも属さない。したがって、第1のSTAは、第1のSTAのスコアボードコンテキストをどのように更新すべきかを知ることができない。これはまた、以下のように理解され得る。6番目のA-MPDUを受信したとき、受信機は、第1のSTAのスコアボードのWinEnd_Rを767の位置に直接動かし、WinStart_Rが512にある。BAフレームがフィードバックされるとき、前のラウンドにおける0～255の範囲内のいずれかのフレームの状態情報は、誤ってフィードバックされない。したがって、スコアボードは、6番目のA-MPDUについてフラッシュされる必要はない。図１０ｂに示す例では、省略記号は、示されていない他のA-MPDUを省略することが理解され得る。

Q=2が例として使用され、第7のタイプのスコアボードコンテキスト制御動作は、以下のように更に理解され得る。
以下の条件、すなわち、
受信側MLDが各リンクにおいて別々のスコアボードコンテキスト制御を有し、
受信側MLDと連携する全てのSTAが、スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能であり、
受信側MLDと連携するSTAが、WinStart_R≦SN<WinStart_R+2*WinSize_R-1を満たすSNを有するMPDUを受信し、
受信側MLDと連携する他のSTAが、WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUを受信しており、
現在受信されているA-MPDU内のSNを有する他のMPDUがまだ全ての上記の条件を満たしていないか、全ての上記の条件を満たしているものが、STAにより受信された、A-MPDU内のSNを有する1番目のMPDUであるか、或いは、STAのスコアボードコンテキストが現在受信されているA-MPDU内のMPDUに基づいてリフレッシュされていないこと
が真である場合、
STAは、STAのスコアボードコンテキストをリフレッシュ及び更新してもよい。

Q=2が例として使用され、第8のタイプのスコアボードコンテキスト制御動作は、以下のように更に理解され得る。
以下の条件、すなわち、
受信側MLDが各リンクにおいて別々のスコアボードコンテキスト制御を有し、
受信側MLDと連携する全てのSTAが、スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能であり、
受信側MLDと連携するSTAが、WinStart_R≦SN<WinStart_R+2*WinSize_R-1を満たすSNを有するMPDUを受信し、
受信側MLDと連携する他のSTAが、WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUを受信しており、
現在受信されているA-MPDUの前に受信された他のA-MPDU内の如何なるMPDUもBAにより応答されていないものではないか、現在受信されているA-MPDUの前に受信されたいずれかのA-MPDU内の如何なるMPDUもBAにより応答されていないものではないか、或いは、現在受信されているA-MPDUの前に受信されたいずれかのA-MPDUで搬送された全てのMPDUがBAにより応答されていること
が真である場合、
STAは、STAのスコアボードコンテキストをリフレッシュ及び更新してもよい。

Q=2が例として使用され、第9のタイプのスコアボードコンテキスト制御動作は、以下のように更に理解され得る。
以下の条件、すなわち、
受信側MLDが各リンクにおいて別々のスコアボードコンテキスト制御を有し、
受信側MLDと連携する全てのSTAが、スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能であり、
受信側MLDと連携するSTAが、WinStart_R≦SN<WinStart_R+2*WinSize_R-1を満たすSNを有するMPDUを受信し、
受信側MLDと連携する他のSTAが、WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUを受信しており、
現在受信されているA-MPDU内のSNを有する他のMPDUがまだ全ての上記の条件を満たしていないか、全ての上記の条件を満たしているものが、STAにより受信された、現在受信されているA-MPDU内のSNを有する1番目のMPDUであるか、或いは、STAのスコアボードコンテキストが現在受信されているA-MPDU内のMPDUに基づいてリフレッシュされておらず、
現在受信されているA-MPDUの前に受信された他のA-MPDU内の如何なるMPDUもBAにより応答されていないものではないか、現在受信されているA-MPDUの前に受信されたいずれかのA-MPDU内の如何なるMPDUもBAにより応答されていないものではないか、或いは、現在受信されているA-MPDUの前に受信されたいずれかのA-MPDUで搬送された全てのMPDUがBAにより応答されていること
が真である場合、
STAは、STAのスコアボードコンテキストをリフレッシュ及び更新してもよい。

Q=2が例として使用され、第10のタイプのスコアボードコンテキスト制御動作は、以下のように更に理解され得る。
以下の条件、すなわち、
受信側MLDが各リンクにおいて別々のスコアボードコンテキスト制御を有し、
受信側MLDと連携する全てのSTAが、スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能であり、
受信側MLDと連携するSTAが、WinStart_R≦SN<WinStart_R+2*WinSize_R-1を満たすSNを有するMPDUを受信し、
WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUがSTAにより受信されたMPDUにないか、或いは、WinStart_B-WinSize_R≦SN<WinStart_Bを満たすSNを有するMPDUが受信側MLDと連携する他のSTAにより受信され、
現在受信されているA-MPDUの前に受信された他のA-MPDU内の如何なるMPDUもBAにより応答されていないものではないか、現在受信されているA-MPDUの前に受信されたいずれかのA-MPDU内の如何なるMPDUもBAにより応答されていないものではないか、或いは、現在受信されているA-MPDUの前に受信されたいずれかのA-MPDUで搬送された全てのMPDUがBAにより応答されており、
ここで、STAにより上記の条件を実行するシーケンスは限定されないことが理解され得る、
現在受信されているA-MPDU内のSNを有する他のMPDUがまだ全ての上記の条件を満たしていないか、全ての上記の条件を満たしているものが、STAにより受信された、A-MPDU内のSNを有する1番目のMPDUであるか、或いは、STAのスコアボードコンテキストが現在受信されているA-MPDU内のMPDUに基づいてリフレッシュされていないこと
が真である場合、
STAは、STAのスコアボードコンテキストをリフレッシュ及び更新してもよい。

スコアボードコンテキスト制御動作の上記の説明は単なる例であり、この出願の上記の説明における2¹¹とスコアボードのウィンドウとの間の関係は、ここでは再び1つずつ詳細に説明しないことが理解され得る。例えば、SNが満たす条件がスコアボードのウィンドウサイズと組み合わされる場合、上記に示す全ての2¹¹は、2*WinSize_Rと置き換えられてもよい。

上記の第3のタイプのスコアボードコンテキスト制御動作及び第6のタイプのスコアボードコンテキスト制御動作と組み合わせて、この出願は、第11のタイプのスコアボードコンテキスト制御動作を更に提供する。
以下の条件、すなわち、
受信側MLDが各リンクにおいて別々のスコアボードコンテキスト制御を有し、
受信側MLDと連携する全てのSTAが、スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能であり、
受信側MLDと連携するSTAが、WinStart_R≦SN<WinStart_R+2*WinSize_R-1を満たすSNを有するMPDUを受信し、
STAにより受信されたMPDU内のSNを有する如何なるMPDUもWinStart_B-WinSize_R≦SN<WinStart_Bを満たさないか、或いは、受信側MLDと連携する他のSTAにより受信されたSNを有するMPDUがWinStart_B-WinSize_R≦SN<WinStart_Bを満たすこと
が真である場合、
STAは、STAのスコアボードコンテキストをリフレッシュ及び更新してもよい。

以下に、この出願の実施形態において提供される通信装置について説明する。

この出願では、通信装置は、上記の方法の実施形態に基づいて機能モジュールに分割されてもよい。例えば、機能モジュールは、対応する機能に基づく分割を通じて取得されてもよく、或いは、2つ以上の機能が1つの処理モジュールに統合されてもよい。統合されたモジュールは、ハードウェアの形式で実現されてもよく、或いは、ソフトウェア機能モジュールの形式で実現されてもよい。この出願において、モジュール分割は、例として使用され、単に論理的な機能分割である点に留意すべきである。実際の実現方式では、他の分割方式が使用されてもよい。以下に、図７～図９を参照して、この出願の実施形態における通信装置について詳細に説明する。

図７は、この出願の実施形態による通信装置の構造の概略図である。図７に示すように、通信装置は、処理ユニット701と、トランシーバユニット702とを含む。

この出願のいくつかの実施形態では、通信装置は、上記の送信機でもよい。言い換えると、図７に示す通信装置は、上記の方法の実施形態における送信機により実行されるステップ、機能等を実行するように構成されてもよい。

例えば、トランシーバユニット702は、ADDBA要求フレームを送信し、ADDBA応答フレームを受信するように構成される。

他の例では、トランシーバユニット702は、第1のA-MPDUを送信するように更に構成される。

他の例では、トランシーバユニット702は、BARフレームを送信し、BAフレームを受信するように更に構成される。

他の例では、トランシーバユニット702は、第2のA-MPDUを送信するように更に構成される。

この出願のこの実施形態におけるトランシーバユニット及び処理ユニットの具体的な説明は、単なる例であることが理解され得る。トランシーバユニット及び処理ユニットにより実行される具体的な機能又はステップについては、上記の方法の実施形態を参照する(例えば、図４及び図５が含まれる)。詳細はここでは再び説明しない。

図７が再利用される。この出願のいくつかの他の実施形態では、通信装置は、上記の受信機でもよい。言い換えると、図７に示す通信装置は、上記の方法の実施形態において受信機により実行されるステップ、機能等を実行するように構成されてもよい。

例えば、トランシーバユニット702は、ADDBA要求フレームを受信し、ADDBA応答フレームを送信するように構成される。

他の例では、トランシーバユニット702は、第1のA-MPDUを受信するように更に構成される。

他の例では、処理ユニット701は、ローカルに記録されたスコアボードコンテキストを取得し、第1のA-MPDUが、この出願の実施形態に示す第3のタイプのスコアボードコンテキスト制御動作～第10のタイプのスコアボードコンテキスト制御動作のうち少なくとも1つを満たすとき、第1のA-MPDUのSNに基づいてスコアボードコンテキストをリフレッシュするように構成される。

他の例では、トランシーバユニット702は、BARフレームを受信し、BAフレームを送信するように更に構成される。

他の例では、トランシーバユニット702は、第2のA-MPDUを受信するように更に構成される。処理ユニット701は、第2のA-MPDU内の指示情報に基づいて、スコアボードコンテキストをリフレッシュするように更に構成される。

第3のタイプのスコアボードコンテキスト制御動作～第10のタイプのスコアボードコンテキスト制御動作の具体的な説明については、上記の方法の実施形態を参照することが理解され得る。詳細はここでは1つずつ再び説明しない。

上記に、この出願の実施形態における送信機及び受信機を説明している。以下に、送信機及び受信機の可能な製品形式について説明する。図７における送信機の機能を有するいずれかの形式の製品、又は図７の受信機の機能を有するいずれかの形式の製品が、この出願の実施形態の保護範囲内に入ることが理解されるべきである。以下の説明は単なる例であり、この出願の実施形態における送信機及び受信機の製品形式はこれに限定されないことが更に理解されるべきである。

図７に示す通信装置において、処理ユニット701は、1つ以上のプロセッサでもよい。トランシーバユニット702はトランシーバでもよく、或いは、トランシーバユニット702は送信ユニット及び受信ユニットでもよい。送信ユニットは送信機でもよく、受信ユニットは受信機でもよい。送信ユニット及び受信ユニットは、1つのコンポーネント、例えば、トランシーバに統合される。この出願のこの実施形態では、プロセッサ及びトランシーバは結合されてもよく、プロセッサとトランシーバとの間の接続方式は、この出願のこの実施形態では限定されない。

図８に示すように、通信装置80は、1つ以上のプロセッサ820と、トランシーバ810とを含む。

例えば、通信装置が、送信機により実行されるステップ、方法又は機能を実行するように構成されるとき、例えば、トランシーバ810は、ADDBA要求フレームを送信し、ADDBA応答フレームを受信するように構成される。他の例では、トランシーバ810は、第1のA-MPDUを送信するように更に構成される。他の例では、トランシーバ810は、BARフレームを送信し、BAフレームを受信するように更に構成される。他の例では、トランシーバ810は、第2のA-MPDUを送信するように更に構成される。

例えば、通信装置が、受信機により実行されるステップ、方法又は機能を実行するように構成されるとき、例えば、トランシーバ810は、ADDBA要求フレームを受信し、ADDBA応答フレームを送信するように構成される。他の例では、トランシーバ810は、第1のA-MPDUを受信するように更に構成される。他の例では、プロセッサ820は、ローカルに記録されたスコアボードコンテキストを取得し、第1のA-MPDUが、この出願の実施形態に示す第3のタイプのスコアボードコンテキスト制御動作～第10のタイプのスコアボードコンテキスト制御動作のうち少なくとも1つを満たすとき、第1のA-MPDUのSNに基づいてスコアボードコンテキストをリフレッシュするように構成される。他の例では、トランシーバ810は、BARフレームを受信し、BAフレームを送信するように更に構成される。他の例では、トランシーバ810は、第2のA-MPDUを受信するように更に構成される。プロセッサ820は、第2のA-MPDU内の指示情報に基づいて、スコアボードコンテキストをリフレッシュするように更に構成される。

プロセッサ及びトランシーバの具体的な説明については、図７に示す処理ユニット及びトランシーバユニットの説明を参照することが理解され得る。詳細はここでは再び説明しない。

図８に示す通信装置の各実現方式では、トランシーバは、受信機と送信機とを含んでもよい。受信機は、受信する機能(又は動作)を実行するように構成され、送信機は、送信する機能(又は動作)を実行するように構成される。トランシーバは、伝送媒体を使用することにより他のデバイス/装置と通信するように構成される。

任意選択で、通信装置80は、プログラム命令及び/又はデータを記憶するように構成された1つ以上のメモリ830を更に含んでもよい。メモリ830は、プロセッサ820に結合される。この出願の実施形態における結合は、電気的形式、機械的形式又は他の形式の装置、ユニット又はモジュールの間の間接結合又は通信接続でもよく、装置、ユニット又はモジュールの間の情報交換のために使用される。プロセッサ820は、メモリ830と協働してもよい。プロセッサ820は、メモリ830に記憶されたプログラム命令を実行してもよい。任意選択で、1つ以上のメモリのうち少なくとも1つは、プロセッサに含まれてもよい。

トランシーバ810と、プロセッサ820と、メモリ830との間の具体的な接続媒体は、この出願のこの実施形態では限定されない。この出願のこの実施形態では、メモリ830、プロセッサ820及びトランシーバ810は、図８においてバス840を通じて互いに接続されている。バスは、図８において太線を使用することにより表される。他のコンポーネントの間の接続方式は、単に説明のための例であり、これに限定されない。バスは、アドレスバス、データバス、制御バス等に分類されてもよい。表現を容易にするために、図８において表現のために1本の太線のみが使用されるが、これは、1つのバスのみ又は1つのタイプのバスのみが存在することを意味しない。

この出願の実施形態では、プロセッサは、汎用プロセッサ、デジタルシグナルプロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ若しくは他のプログラム可能論理デバイス、ディスクリートゲート若しくはトランジスタ論理デバイス、又はディスクリートハードウェアコンポーネントでもよく、この出願の実施形態において開示される方法、ステップ及び論理ブロック図を実現又は実行してもよい。汎用プロセッサは、マイクロプロセッサ又はいずれかの従来のプロセッサ等でもよい。この出願の実施形態において開示される方法のステップは、ハードウェアプロセッサにより直接実行されてもよく、或いは、プロセッサ内のハードウェアモジュールとソフトウェアモジュールとの組み合わせを使用することにより実行されてもよい。

この出願のこの実施形態では、メモリは、不揮発性メモリ、例えば、ハードディスクドライブ(hard disk drive, HDD)又はソリッドステートドライブ(solid-state drive, SSD)、ランダムアクセスメモリ(random access memory, RAM)、消去可能プログラム可能読み取り専用メモリ(erasable programmable ROM, EPROM)、読み取り専用メモリ(read-only memory, ROM)又はコンパクトディスク読み取り専用メモリ(compact disc read-only memory, CD-ROM)を含んでもよいが、これらに限定されない。メモリは、命令又はデータ構造の形式でプログラムコードを搬送又は記憶でき且つコンピュータ(例えば、この出願に示す通信装置)により読み取られること及び/又は書き込まれることができるいずれかの他の媒体であるが、これに限定されない。この出願のこの実施形態におけるメモリは、代替として、記憶機能を実現でき、プログラム命令及び/又はデータを記憶するように構成された回路又はいずれかの他の装置でもよい。

プロセッサ820は、主に、通信プロトコル及び通信データを処理し、全体の通信装置を制御し、ソフトウェアプログラムを実行し、ソフトウェアプログラムのデータを処理するように構成される。メモリ830は、主に、ソフトウェアプログラム及びデータを記憶するように構成される。トランシーバ810は、制御回路及びアンテナを含んでもよい。制御回路は、主に、ベースバンド信号と無線周波数信号との間の変換を実行し、無線周波数信号を処理するように構成される。アンテナは、主に、電磁波の形式で無線周波数信号を送信及び受信するように構成される。入力/出力装置、例えば、タッチスクリーン、ディスプレイ、キーボード等は、主に、ユーザにより入力されたデータを受け取り、ユーザにデータを出力するように構成される。

通信装置が電源オンになった後に、プロセッサ820は、メモリ830内のソフトウェアプログラムを読み取り、ソフトウェアプログラムの命令を解釈して実行し、ソフトウェアプログラムのデータを処理してもよい。データが無線で送信される必要があるとき、送信対象のデータに対してベースバンド処理を実行した後に、プロセッサ820は、ベースバンド信号を無線周波数回路に出力する。ベースバンド信号に対して無線周波数処理を実行した後に、無線周波数回路は、アンテナを通じて電磁波の形式で無線周波数信号を送信する。データが通信装置に送信されるとき、無線周波数回路は、アンテナを通じて無線周波数信号を受信し、無線周波数信号をベースバンド信号に変換し、ベースバンド信号をプロセッサ820に出力する。プロセッサ820は、ベースバンド信号をデータに変換し、データを処理する。

他の実現方式では、無線周波数回路及びアンテナは、ベースバンド処理を実行するプロセッサとは独立して配置されてもよい。例えば、分散シナリオでは、無線周波数回路及びアンテナは、通信装置とは独立して遠隔に配置されてもよい。

この出願のこの実施形態に示す通信装置は、図８におけるコンポーネントよりも多くのコンポーネント等を更に有してもよいことが理解され得る。これは、この出願のこの実施形態では限定されない。プロセッサ及びトランシーバにより実行される上記の方法は、単なる例である。プロセッサ及びトランシーバにより実行される具体的なステップについては、上記の方法を参照する。

他の可能な実現方式では、図７に示す通信装置において、処理ユニット701は1つ以上の論理回路でもよく、トランシーバユニット702は、入力/出力インタフェースでもよく、或いは、通信インタフェース、インタフェース回路、インタフェース等と呼ばれてよい。代替として、トランシーバユニット702は、送信ユニット及び受信ユニットでもよい。送信ユニットは出力インタフェースでもよく、受信ユニットは入力インタフェースでもよい。送信ユニット及び受信ユニットは、1つのユニット、例えば、入力/出力インタフェースに統合される。図９に示すように、図９に示す通信装置は、論理回路901と、インタフェース902とを含む。具体的には、処理ユニット701は、論理回路901を使用することにより実現されてもよく、トランシーバユニット702は、インタフェース902を使用することにより実現されてもよい。論理回路901は、チップ、処理回路、集積回路、システムオンチップ(system on chip, SoC)チップ等でもよい。インタフェース902は、通信インタフェース、入力/出力インタフェース、ピン等でもよい。例えば、図９は、上記の通信装置がチップとして使用される例である。チップは、論理回路901とインタフェース902とを含む。

この出願のこの実施形態では、論理回路及びインタフェースは、互いに更に結合されてもよい。論理回路及びインタフェースの具体的な接続方式は、この出願のこの実施形態では限定されない。

例えば、通信装置が、送信機により実行される方法、機能又はステップを実行するように構成されるとき、例えば、インタフェース902は、ADDBA要求フレームを送信し、ADDBA応答フレームを受信するように構成される。他の例では、インタフェース902は、第1のA-MPDUを送信するように更に構成される。他の例では、インタフェース902は、BARフレームを送信し、BAフレームを受信するように更に構成される。他の例では、インタフェース902は、第2のA-MPDUを送信するように更に構成される。

例えば、通信装置が、受信機により実行される方法、機能又はステップを実行するように構成されるとき、例えば、インタフェース902は、ADDBA要求フレームを受信し、ADDBA応答フレームを送信するように構成される。他の例では、インタフェース902は、第1のA-MPDUを受信するように更に構成される。他の例では、論理回路901は、ローカルに記録されたスコアボードコンテキストを取得し、第1のA-MPDUがこの出願の実施形態に示す第3のタイプのスコアボードコンテキスト制御動作～第10のタイプのスコアボードコンテキスト制御動作のうち少なくとも1つを満たすとき、第1のA-MPDUのSNに基づいてスコアボードコンテキストをリフレッシュするように構成される。他の例では、インタフェース902は、BARフレームを受信し、BAフレームを送信するように更に構成される。他の例では、インタフェース902は、第2のA-MPDUを受信するように更に構成される。論理回路901は、第2のA-MPDU内の指示情報に基づいてスコアボードコンテキストをリフレッシュするように更に構成される。

この出願の実施形態に示す通信装置は、ハードウェアの形式でこの出願の実施形態において提供される方法を実現してもよく、或いは、ソフトウェアの形式でこの出願の実施形態において提供される方法を実現してもよいことが理解され得る。これは、この出願の実施形態では限定されない。

図９に示される実施形態の具体的な実現方式については、上記の実施形態を参照する。詳細はここでは再び説明しない。

この出願の実施形態は、無線通信システムを更に提供する。無線通信システムは、送信機と受信機とを含む。送信機及び受信機は、(図４、図５等に示すような)上記の実施形態のいずれか1つにおける方法を実行するように構成されてもよい。

さらに、この出願は、コンピュータプログラムを更に提供する。コンピュータプログラムは、この出願において提供される方法において送信機により実行される動作及び/又は処理を実現するために使用される。

この出願は、コンピュータプログラムを更に提供する。コンピュータプログラムは、この出願において提供される方法において受信機により実行される動作及び/又は処理を実現するために使用される。

この出願は、コンピュータ可読記憶媒体を更に提供する。コンピュータ可読記憶媒体は、コンピュータコードを記憶する。コンピュータコードがコンピュータ上で実行されると、コンピュータは、この出願において提供される方法において送信機により実行される動作及び/又は処理を実行することが可能になる。

この出願は、コンピュータ可読記憶媒体を更に提供する。コンピュータ可読記憶媒体は、コンピュータコードを記憶する。コンピュータコードがコンピュータ上で実行されると、コンピュータは、この出願において提供される方法において受信機により実行される動作及び/又は処理を実行することが可能になる。

この出願は、コンピュータプログラム製品を更に提供する。コンピュータプログラム製品は、コンピュータコード又はコンピュータプログラムを含む。コンピュータコード又はコンピュータプログラムがコンピュータ上で実行すると、この出願において提供される方法において送信機により実行される動作及び/又は処理が実行されることが可能になる。

この出願は、コンピュータプログラム製品を更に提供する。コンピュータプログラム製品は、コンピュータコード又はコンピュータプログラムを含む。コンピュータコード又はコンピュータプログラムがコンピュータ上で実行すると、この出願において提供される方法において受信機により実行される動作及び/又は処理が実行されることが可能になる。

この出願において提供されるいくつかの実施形態では、開示されるシステム、装置及び方法は、他の方式で実現されてもよいことが理解されるべきである。例えば、記載の装置の実施形態は、単なる例である。例えば、ユニットへの分割は、単に論理的な機能分割であり、実際の実現方式では他の分割でもよい。例えば、複数のユニット又はコンポーネントは組み合わされてもよく或いは他のシステムに統合されてもよく、或いは、いくつかの特徴が無視されてもよく或いは実行されなくてもよい。さらに、表示又は議論される相互結合又は直接結合又は通信接続は、いくつかのインタフェースを通じて実現されてもよい。装置又はユニットの間の間接結合又は通信接続は、電気的、機械的又は他の形式で実現されてもよい。

別個の部分として記載されたユニットは、物理的に別個でもよく或いは別個でなくてもよく、ユニットとして表示された部分は、物理的なユニットでもよく物理的なユニットでなくてもよく、1つの場所に位置してもよく、或いは、複数のネットワークユニットに分散されてもよい。ユニットの一部又は全部は、この出願の実施形態において提供される解決策の技術的効果を実現するための実際の要件に基づいて選択されてもよい。

さらに、この出願の実施形態における機能ユニットは、1つの処理ユニットに統合されてもよく、或いは、ユニットのそれぞれが物理的に単独で存在してもよく、或いは、2つ以上のユニットが1つのユニットに統合されてもよい。統合されたユニットは、ハードウェアの形式で実現されてもよく、或いは、ソフトウェア機能ユニットの形式で実現されてもよい。

統合されたユニットがソフトウェア機能ユニットの形式で実現され、独立した製品として販売又は使用されるとき、統合されたユニットはコンピュータ可読記憶媒体に記憶されてもよい。このような理解に基づいて、この出願の実施形態の技術的解決策は本質的に、或いは、従来技術に寄与する部分、又は技術的解決策の全部若しくは一部は、ソフトウェア製品の形式で実現されてもよい。コンピュータソフトウェア製品は、可読記憶媒体に記憶され、コンピュータデバイス(パーソナルコンピュータ、サーバ又はネットワークデバイスでもよい)に、この出願の実施形態において記載される方法のステップの全部又は一部を実行するように命令するためのいくつかの命令を含む。上記の可読記憶媒体は、USBフラッシュドライブ、リムーバブルハードディスク、読み取り専用メモリ(read-only memory, ROM)、ランダムアクセスメモリ(random access memory, RAM)、磁気ディスク又は光ディスクのような、プログラムコードを記憶できるいずれかの媒体を含む。

上記の説明は、単にこの出願の特定の実現方式であり、この出願の保護範囲を限定することを意図するものではない。この出願において開示される技術的範囲内で当業者により容易に考え出される如何なる変形又は置換も、この出願の保護範囲内に入るものとする。したがって、この出願の保護範囲は、特許請求の範囲の保護範囲に従うものとする。

Claims

マルチリンク通信方法であって、
受信機により、第1の集約媒体アクセス制御プロトコルデータユニット(A-MPDU)を受信するステップと、
前記受信機により、ローカルに記録されたスコアボードコンテキストを取得し、前記第1のA-MPDUが以下の条件のうちいずれか1つ以上を満たすとき、前記第1のA-MPDUのシーケンス番号(SN)に基づいて前記スコアボードコンテキストをリフレッシュするステップと
を含み、
第1の条件は、前記受信機と連携するSTAが、WinStart_R≦SN<WinStart_R+2¹¹を満たすSNを有するMPDUを受信することを含み、
第3の条件は、前記第1のA-MPDUの前に受信されたいずれかのA-MPDU内のいずれかのMPDUがBAにより応答していること、又は前記第1のA-MPDUの前に受信されたいずれかのA-MPDUで搬送された全てのMPDUがブロック確認応答(BA)により応答していることを含む、方法。
前記第1のA-MPDUは、以下の第2の条件又は第4の条件を更に満たし、
前記第2の条件は、WinStart _B -WinSize _R ≦SN<WinStart _B を満たすSNを有するMPDUのいずれもSTAにより受信されないこと、又はWinStart _B -WinSize _R ≦SN<WinStart _B を満たすSNを有する全てのMPDUが前記受信機と連携する他のSTAにより受信されることを含み、
前記第4の条件は、前記第1のA-MPDU内のSNを有する他のMPDUが前記第1の条件、前記第2の条件及び前記第3の条件をまだ満たしていないこと、前記受信機と連携するSTAにより受信されたSNを有するMPDUが、前記第1のA-MPDU内にあり且つ前記第1の条件、前記第2の条件及び前記第3の条件を満たす1番目のMPDUであること、又は前記受信機と連携するSTAのスコアボードコンテキストが前記第1のA-MPDU内のMPDUに基づいてリフレッシュされていないことを含む、請求項１に記載の方法。
前記受信機は、各リンクにおいて別々のスコアボードコンテキスト制御を有し、前記リンクは、前記受信機と送信機との間のリンクである、請求項１に記載の方法。
前記受信機と連携する前記STAは、前記スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能である、請求項１に記載の方法。
前記第1のA-MPDU内のSNは、同じトラフィック識別子(TID)に属する、請求項１に記載の方法。
通信装置であって、
第1の集約媒体アクセス制御プロトコルデータユニット(A-MPDU)を受信するように構成されたトランシーバユニットと、
ローカルに記録されたスコアボードコンテキストを取得し、前記第1のA-MPDUが以下の条件のうちいずれか1つ以上を満たすとき、前記第1のA-MPDUのシーケンス番号(SN)に基づいて前記スコアボードコンテキストをリフレッシュするように構成された処理ユニットと
を含み、
第1の条件は、当該通信装置と連携するSTAが、WinStart_R≦SN<WinStart_R+2¹¹を満たすSNを有するMPDUを受信することを含み、
第3の条件は、前記第1のA-MPDUの前に受信されたいずれかのA-MPDU内のいずれかのMPDUがBAにより応答されていること、又は前記第1のA-MPDUの前に受信されたいずれかのA-MPDUで搬送された全てのMPDUがブロック確認応答(BA)により応答していることを含む、装置。
前記第1のA-MPDUは、以下の第2の条件又は第4の条件を更に満たし、
前記第2の条件は、WinStart _B -WinSize _R ≦SN<WinStart _B を満たすSNを有するMPDUのいずれもSTAにより受信されないこと、又はWinStart _B -WinSize _R ≦SN<WinStart _B を満たすSNを有する全てのMPDUが当該通信装置と連携する他のSTAにより受信されることを含み、
前記第4の条件は、前記第1のA-MPDU内のSNを有する他のMPDUが前記第1の条件、前記第2の条件及び前記第3の条件をまだ満たしていないこと、当該通信装置と連携するSTAにより受信されたSNを有するMPDUが、前記第1のA-MPDU内にあり且つ前記第1の条件、前記第2の条件及び前記第3の条件を満たす1番目のMPDUであること、又は当該通信装置と連携するSTAのスコアボードコンテキストが前記第1のA-MPDU内のMPDUに基づいてリフレッシュされていないことを含む、請求項６に記載の装置。
当該通信装置は、各リンクにおいて別々のスコアボードコンテキスト制御を有し、前記リンクは、当該通信装置と送信機との間のリンクである、請求項６に記載の装置。
当該通信装置と連携する前記STAは、前記スコアボードコンテキストを更新するために並べ替えバッファ情報を使用することが可能である、請求項６に記載の装置。
前記第1のA-MPDU内のSNは、同じトラフィック識別子(TID)に属する、請求項６に記載の装置。
プロセッサとメモリとを含む通信装置であって、
前記メモリは、命令を記憶するように構成され、
前記プロセッサは、前記命令を実行して、請求項１に記載の方法が実行されることを可能にするように構成される、通信装置。
論理回路とインタフェースとを含む通信装置であって、
前記論理回路は前記インタフェースに結合され、
前記インタフェースは、コード命令を入力及び/又は出力するように構成され、前記論理回路は、前記コード命令を実行して、請求項１に記載の方法が実行されることを可能にするように構成される、通信装置。
コンピュータ可読記憶媒体であって、
前記コンピュータ可読記憶媒体は、コンピュータプログラムを記憶するように構成され、前記コンピュータプログラムが実行されると、請求項１に記載の方法が実行される、コンピュータ可読記憶媒体。