JP7446247B2 - データの送信に関与するユーザ機器および基地局 - Google Patents

データの送信に関与するユーザ機器および基地局 Download PDF

Info

Publication number
JP7446247B2
JP7446247B2 JP2020571631A JP2020571631A JP7446247B2 JP 7446247 B2 JP7446247 B2 JP 7446247B2 JP 2020571631 A JP2020571631 A JP 2020571631A JP 2020571631 A JP2020571631 A JP 2020571631A JP 7446247 B2 JP7446247 B2 JP 7446247B2
Authority
JP
Japan
Prior art keywords
received
window size
data packet
user equipment
transmitted
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2020571631A
Other languages
English (en)
Other versions
JP2022500885A (ja
Inventor
ミン－フン タオ
リキン シャー
秀俊 鈴木
アンキット バムリ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
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 Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Publication of JP2022500885A publication Critical patent/JP2022500885A/ja
Application granted granted Critical
Publication of JP7446247B2 publication Critical patent/JP7446247B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/187—Details of sliding window management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1685—Details of the supervisory signal the supervisory signal being transmitted in response to a specific request, e.g. to a polling signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/188—Time-out mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092—Error control systems characterised by the topology of the transmission link
    • H04L2001/0097—Relays

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Description

本開示は、３ＧＰＰ通信システムなどの通信システムにおける方法、デバイス、および物品を対象とする。
現在、第３世代パートナーシッププロジェクト（３ＧＰＰ）は、第５世代（５Ｇ）とも呼ばれる次世代セルラー技術の技術仕様に取り組んでいる。
１つの目的は、拡張モバイルブロードバンド（ｅＭＢＢ：enhanced mobile broadband）、超高信頼低遅延通信（ＵＲＬＬＣ：ultra-reliable low-latency communications）、大量マシン型通信（ｍＭＴＣ：massive machine type communications）を少なくとも含む、すべての使用シナリオ、要求事項、および展開シナリオに対処する単一の技術的枠組みを提供することである（例えば、参照することにより本明細書に組み込まれる非特許文献１の第６節を参照）。例えば、ｅＭＢＢ展開シナリオは、室内ホットスポット、密集した都市、地方、都市マクロ、および高速を含むことができる。ＵＲＬＬＣ展開シナリオは、産業制御システム、モバイルヘルスケア（リモート監視／診断／処置）、車両のリアルタイム制御、スマートグリッドのための広域監視／制御システムを含むことができる。ｍＭＴＣは、スマートウェアラブルやセンサネットワークなど、非タイムクリティカルなデータ転送を伴う多数の装置を有するシナリオを含むことができる。ｅＭＢＢとＵＲＬＬＣのサービスは、両方とも非常に広い帯域幅を要求する点で類似しているが、ＵＲＬＬＣサービスが超低遅延を必要とする点で相違している。
第２の目的は、前方互換性を達成することである。ロングタームエボリューション（ＬＴＥ、ＬＴＥ－Ａ）セルラーシステムに対する後方互換性は必要なく、これによって、全く新しいシステム設計および／または新規の特徴の導入が容易になる。
物理レイヤの信号波形は、ＯＦＤＭに基づくことになるであろうが、非直交波形および多元接続のサポートの可能性もある。例えば、ＤＦＴ－Ｓ－ＯＦＤＭ、および／またはＤＦＴ－Ｓ－ＯＦＤＭのバリエーション、および／またはフィルタリング／ウィンドウイングのような、ＯＦＤＭの上の追加機能がさらに検討されている。ＬＴＥでは、ＣＰベースＯＦＤＭおよびＤＦＴ－Ｓ－ＯＦＤＭが、ダウンリンク送信用およびアップリンク送信用の波形としてそれぞれ使用される。ＮＲにおける設計目標の１つは、ダウンリンク、アップリンク、およびサイドリンクに対してできる限り共通の波形を求めることである。
ＴＲ ３８．９１３ ｖｅｒｓｉｏｎ １５．０．０ ＴＲ ３８．８０４ ｖ１４．０．０ ３ＧＰＰ ＴＳ ３８．３００ ｖ１５．２．０ ３ＧＰＰ ＴＲ ３８．８０１ ｖ１４．０．０ ３ＧＰＰ ＴＳ ３８．２１１ ｖ１５．２．０ ３ＧＰＰ ＴＳ ３８．３２２ ｖｅｒｓｉｏｎ １５．２．０ ＴＲ ３８．８７４ ｖｅｒｓｉｏｎ ０．４．０
非限定的かつ例示的な実施形態は、データを送信するための改善された手順の提供を容易にする。
１つの一般的な第１の例において、本明細書に開示された技術は、以下に係る受信機、送信機、および処理回路を有するユーザ機器を特徴とする。送信機は、送信ウィンドウサイズを有する送信ウィンドウに基づいて少なくとも１つのデータパケットを送信する。受信機は、前記少なくとも１つの送信されたデータパケットに関する受信フィードバックを受信する。処理回路は、少なくとも前記受信された受信フィードバックに基づいて、少なくともさらなるデータパケットを送信するために使用される前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定する。
１つの一般的な第１の例において、本明細書に開示された技術は、ユーザ機器によって実行される以下のステップを有する方法を特徴とする。ステップは、
送信ウィンドウサイズを有する送信ウィンドウに基づいて少なくとも１つのデータパケットを送信するステップと、
前記少なくとも１つの送信されたデータパケットに関する受信フィードバックを受信するステップと、
少なくとも前記受信された受信フィードバックに基づいて、少なくともさらなるデータパケットを送信するために使用される前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定するステップと、
を含む。
１つの一般的な第１の例において、本明細書に開示された技術は、以下に係る送信機だけでなく受信機および処理回路を有するサービング基地局を特徴とする。送信機は、送信ウィンドウサイズを有する送信ウィンドウに基づいて少なくとも１つのデータパケットを送信する。受信機は、前記少なくとも１つの送信されたデータパケットに関する受信フィードバックを受信する。処理回路は、少なくとも前記受信された受信フィードバックに基づいて、少なくともさらなるデータパケットを送信するために使用される前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定する。
一般的または具体的な実施形態は、システム、方法、集積回路、コンピュータプログラム、記憶媒体、またはこれらの任意の選択的な組合せとして実現できることに留意されたい。
開示された実施形態のさらなる利益および利点は、本明細書および図面から明らかになるであろう。これらの利益および／または利点は、いくつかの実施形態ならびに明細書および図面に記載された特徴によって個々に得ることができるが、これらは、そのような利益および／または利点の１つ以上を得るためにすべてが提供される必要はない。
以下、例示的な実施形態について添付の図面を参照してより詳細に説明する。
３ＧＰＰ ＮＲシステムの例示的なアーキテクチャを示す図 ＬＴＥ ｅＮＢ、ｇＮＢ、およびＵＥに対する例示的なユーザプレーンおよび制御プレーンのアーキテクチャを示す図 ＡＭ ＲＬＣエンティティを簡略化した例示的なモデルを示す図 ＲＬＣレイヤでのＡＭデータ転送を示す図 １２ビットのシーケンス番号を使用する場合の例示的なＲＬＣステータス報告を示す図 ＩＡＢドナー、中間ＩＡＢノード、およびＵＥを含む、統合されたアクセスバックホールに関する図 ＩＡＢシナリオのアーキテクチャオプション１ａを示す図 アーキテクチャグループ１の例示的なユーザプレーンプロトコルアーキテクチャを示す図 アーキテクチャグループ１の例示的なユーザプレーンプロトコルアーキテクチャを示す図 フロー制御前の、アップリンクおよびダウンリンクにおける簡略化された輻輳シナリオを示す図 フロー制御後の、アップリンクおよびダウンリンクにおける簡略化された輻輳シナリオを示す図 フロー制御前の、アップリンクおよびダウンリンクにおける簡略化された別の輻輳シナリオを示す図 フロー制御後の、アップリンクおよびダウンリンクにおける簡略化された別の輻輳シナリオを示す図 フロー制御前の、アップリンクおよびダウンリンクにおける簡略化されたさらに別の輻輳シナリオを示す図 フロー制御後の、アップリンクおよびダウンリンクにおける簡略化されたさらに別の輻輳シナリオを示す図 ＵＥおよびｇＮＢの例示的な簡略化した構造を示す図 例示的なアップリンクデータトラフィックルートシナリオを示す図 一実施形態の例示的な実施に係る、送信側（ここでは例示的にＵＥ）の動作のフロー図 一実施形態の例示的な実施に係るＵＥの構造を示す図 送信側（ここでは例示的にＵＥ）と受信側（ここでは例示的にＩＡＢドナー）との間のデータパケット交換を示す図、 例示的なダウンリンクデータトラフィックルートシナリオを示す図 一実施形態の他の例示的な実施に係る、送信側（ここでは例示的にＵＥ）の動作のフロー図
５Ｇ ＮＲシステムアーキテクチャおよびプロトコルスタック
背景技術のセクションで示したように、３ＧＰＰは、最大１００ＧＨｚの周波数範囲で動作する新しい無線アクセス技術（ＮＲ）の開発を含む、単に５Ｇと呼ばれる第５世代セルラー技術の次回リリースに取り組んでいる。３ＧＰＰは、緊急の市場ニーズとより長期的な要求事項の両方を適時に満たすＮＲシステムをうまく標準化するために必要な技術コンポーネントを特定し開発しなければならない。これを達成するために、無線インタフェースおよび無線ネットワークアーキテクチャの進化が、研究項目「Ｎｅｗ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｔｅｃｈｎｏｌｏｇｙ」において検討されている。結果および合意は、テクニカルレポートである非特許文献２に集められており、参照することにより完全に本明細書に組み込まれている。
とりわけ、総合システムアーキテクチャは、ＮＧ－無線アクセスユーザプレーン（ＳＤＡＰ／ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）および制御プレーン（ＲＲＣ）のＵＥへのプロトコル終端を提供する、ｇＮＢを含むＮＧ－ＲＡＮ（Next Generation - Radio Access Network）を想定する。ｇＮＢは、Ｘｎインタフェースによって互いに相互接続される。また、ｇＮＢは、次世代（ＮＧ：Next Generation）インタフェースによってＮＧＣ（Next Generation Core）に、より具体的には、ＮＧ－ＣインタフェースによってＡＭＦ（Access and Mobility Management Function）（例えば、ＡＭＦを実行する特定のコアエンティティ）に、また、ＮＧ－ＵインタフェースによってＵＰＦ（User Plane Function）（例えば、ＵＰＦを実行する特定のコアエンティティ）に接続される。ＮＧ－ＲＡＮアーキテクチャは、図１に示されている（例えば、参照することにより本明細書に組み込まれた非特許文献３の第４節を参照）。
さまざまな展開シナリオをサポートすることができる（例えば、参照することにより本明細書に組み込まれた非特許文献４を参照）。例えば、そこには非一元展開シナリオ（例えば、非特許文献４の第５．２節を参照。一元展開は第５．４節に示されている）が示されており、５Ｇ ＮＲをサポートする基地局を展開することができる。図２は、例示的な非一元配備シナリオ（例えば、前記非特許文献４の図５．２．－１を参照）を示し、その上、ＬＴＥ ｅＮＢ、およびｇＮＢとＬＴＥ ｅＮＢの両方に接続されるユーザ機器（ＵＥ）をさらに示している。ＮＲ ５Ｇのための新しいｅＮＢは、例示的に、ｇＮＢと呼ばれることがある。ｅＬＴＥ ｅＮＢは、ＥＰＣ（Evolved Packet Core）およびＮＧＣ（Next Generation Core）への接続性をサポートするｅＮＢの進化である。
ＮＲのユーザプレーンプロトコルスタック（例えば、参照することにより本明細書に組み込まれた非特許文献３の第４．４．１節を参照）は、ＰＤＣＰ（パケットデータコンバージェンスプロトコル：Packet Data Convergence Protocol）、ＲＬＣ（無線リンク制御：Radio Link Control）、およびＭＡＣ（メディアアクセス制御：Medium Access Control）のサブレイヤを有し、これらはネットワーク側のｇＮＢで終端される。さらに、新しいアクセス層（ＡＳ：access stratum）サブレイヤ（ＳＤＡＰ、サービスデータアダプテーションプロトコル：Service Data Adaptation Protocol）がＰＤＣＰの上に導入される（例えば、参照することにより本明細書に組み込まれた非特許文献３の第６．５サブ項を参照されたい）。ＮＲの制御プレーンプロトコルスタックの詳細については、例えば、非特許文献３の第４．４．２節を参照されたい。レイヤ２機能の概要は、非特許文献３の第６サブ項で与えられる。ＰＤＣＰ、ＲＬＣ、およびＭＡＣのサブレイヤの機能は、非特許文献３の第６．４節、第６．３節、および第６．２節にそれぞれ列挙されている。ＲＲＣレイヤの機能は、非特許文献３の第７サブ項に列挙されている。非特許文献３の上記節は、参照することにより本明細書に組み込まれている。
５Ｇシステムに対して例示的に想定される新しいＮＲレイヤは、ＬＴＥ（－Ａ）通信システムにおいて現在使用されているユーザプレーンレイヤ構造に基づくことができる。
ＮＲの使用事例／展開シナリオは、拡張モバイルブロードバンド（ｅＭＢＢ）、超高信頼低遅延通信（ＵＲＬＬＣ）、大量マシン型通信（ｍＭＴＣ）を含むことができ、これらは、データ速度、レイテンシ、およびカバレッジの面で多様な要件を有する。例えば、ｅＭＢＢは、ピークデータ速度（ダウンリンクでは２０Ｇｂｐｓ、アップリンクでは１０Ｇｂｐｓ）と、ＩＭＴ－Ａｄｖａｎｃｅｄによって提供されるデータ速度の３倍ほどのユーザ経験データ速度とをサポートすることが期待される。一方、ＵＲＬＬＣの場合には、超低遅延（ユーザプレーン遅延に対してＵＬとＤＬでそれぞれ０．５ｍｓ）および高信頼性（１ｍｓ以内に１～１０－５）に関してより厳格な要件が求められる。最後に、ｍＭＴＣは、好ましくは、高接続密度（都市環境では１，０００，０００デバイス／ｋｍ２）、過酷な環境での大きなカバレッジ、および低価格デバイスのための極めて長寿命のバッテリ（１５年）を必要とする可能性がある。
したがって、１つの使用事例に適したＯＦＤＭニューメロロジー（例えば、サブキャリア間隔、ＯＦＤＭシンボル持続時間、サイクリックプレフィックス（ＣＰ）持続時間、スケジューリング間隔あたりのシンボル数）は、他の使用事例ではうまく機能しない場合がある。例えば、低遅延サービスは、好ましくは、ｍＭＴＣサービスよりも短いシンボル持続時間（および、したがって、より大きなサブキャリア間隔）、および／または、ｍＭＴＣサービスよりも少ないスケジューリング間隔あたりのシンボル（別名、ＴＴＩ）を必要とする場合がある。また、チャネル遅延スプレッドが大きい展開シナリオは、好ましくは、遅延スプレッドが短いシナリオよりも長いＣＰ持続時間を必要とする場合がある。したがって、サブキャリア間隔は、同じＣＰオーバーヘッドを保持するように最適化されるべきである。ＮＲは、サブキャリア間隔の２つ以上の値をサポートすることができる。これに対応して、現時点で１５ｋＨｚ、３０ｋＨｚ、６０ｋＨｚのサブキャリア間隔が検討されている。シンボル継続時間Ｔｕとサブキャリア間隔（∀ｆ）は、式（∀ｆ＝１／Ｔｕ）を通して直接関係している。ＬＴＥシステムと同様に、「リソースエレメント」という用語を使用して、最小のリソース単位が１つのＯＦＤＭ／ＳＣ－ＦＤＭＡシンボルの長さに対して１つのサブキャリアで構成されることを示すことができる。
ニューメロロジーおよびサブキャリアの各々に対する新しい無線システム５Ｇ‐ＮＲでは、サブキャリアおよびＯＦＤＭシンボルのリソースグリッドが、アップリンクとダウンリンクに対してそれぞれ定義される。リソースグリッドの各エレメントは、リソースエレメントと呼ばれ、周波数領域の周波数インデックスおよび時間領域のシンボル位置に基づいて特定される。参照することにより本明細書に組み込まれた非特許文献５から明らかなように、いくつかの定義が既に達成されている。
ＲＬＣレイヤのＡＲＱ（自動再送要求：Automatic Repeat reQuest）
ＲＬＣレイヤは、さまざまな機能を託されているＡＭ ＲＬＣエンティティ（Acknowledge Mode RLC entity）を有する（例えば、ＲＬＣ、無線リンク制御、プロトコル仕様、参照することにより本明細書に組み込まれた非特許文献６を参照）。
ｇＮＢで設定されたＲＬＣエンティティに対しては、ＵＥで設定されたピアＲＬＣエンティティがあり、その逆も同様である。特に、ＡＭ ＲＬＣエンティティは、送信側と受信側を有する。ＡＭ ＲＬＣエンティティの送信側は、上位レイヤからＲＬＣ ＳＤＵを受け取り、そのピアＡＭ ＲＬＣエンティティに下位レイヤを介してＲＬＣ ＰＤＵを送信する。ＡＭ ＲＬＣエンティティの受信側は、ＲＬＣ ＳＤＵを上位レイヤに送り、そのピアＡＭ ＲＬＣエンティティから下位レイヤを介してＲＬＣ ＰＤＵを受信する。
図３は、ＡＭ ＲＬＣエンティティを簡略化した例示的なモデルを示す（例えば、非特許文献６の第４．２．１．３節を参照）。この図から明らかなように、ＲＬＣ ＰＤＵは、論理チャネルＤＬ／ＵＬ ＤＣＣＨ（Dedicated Control CHannel）またはＤＬ／ＵＬ ＤＴＣＨ（Dedicated Traffic CHannel）を通じて送受信される。
ＲＬＣレイヤのＡＭデータ転送は、送信ウィンドウの使用を伴う（例えば、参照することにより本明細書に組み込まれた、非特許文献６の第５．２．３節、送信および受信動作を含む「ＡＭデータ転送」を参照）。特に、ＡＭ ＲＬＣエンティティの送信側は、シーケンス番号（ＳＮ：Sequence Number）が送信ウィンドウの中にあるか外にあるかに応じてＲＬＣ ＰＤＵの送信を制御（制限）するための送信ウィンドウを維持する。例えば、送信ウィンドウの外にある（ＳＮを有する）ＲＬＣ ＰＤＵは送信されないのに対し、送信ウィンドウの中にある（ＳＮを有する）ＲＬＣ ＰＤＵは送信することができる。送信ウィンドウのサイズは、固定可能な（例えば、ＡＭ＿ｗｉｎｄｏｗ＿ｓｉｚｅという名前の）パラメータによって与えられ、２０４８（例えば、１２ビットのシーケンス番号を使用する場合）または１３１０７２（例えば、１８ビットのＳＮを使用する場合）に設定可能である（例えば、参照することにより本明細書に組み込まれた、非特許文献６の第７．２節「定数」を参照）。
ＲＬＣレイヤにおけるＡＭデータ転送は、図４に簡略化された例示的な形で示されている。説明を目的として、送信ウィンドウのサイズは１０ＰＤＵであると仮定する。したがって、送信ウィンドウは、以前送信されたデータパケットに対する肯定応答を受信することなく、送信可能なＰＤＵ（この文脈において例示的にデータパケットと呼ぶこともできる）の量を、１０個のＰＤＵに制限する。送信ウィンドウは、スライディングウィンドウであってもよく、これは、送信ウィンドウの下端でＰＤＵの肯定応答を受信すると前方に移動する。その結果、下端は、最後順次に完全に受信されたＲＬＣ ＰＤＵに続くＳＮを有するＰＤＵに対応する。選択した例では、ＳＮが１１～２０のＰＤＵが、送信ウィンドウに配置され、受信側に送信可能である。さらに、ＳＮが１１、１３、２０のＰＤＵのみが受信側で正常に受信されると仮定する（ＳＮが１２、１４～１９の残りのＰＤＵは、例えば、無線リンクで失われたため、正常に復号できなかったものとする）。
後でより詳細に説明するように、ＡＭ ＲＬＣレイヤは、ＡＲＱと呼ばれる誤り訂正メカニズムを含む。これは、送信側に受信フィードバック（例えば、ＡＣＫおよび／またはＮＡＣＫ）を提供することを可能にするとともに、送信側が否定応答されたＰＤＵに対して再送信を実行することを可能にする。
図４において、送信ウィンドウは、ＳＮ＝１１でＡＣＫが受信されたため、１つのＰＤＵだけスライドされる。ＳＮ＝１１は、その時点での送信ウィンドウの下端である。その結果、ＳＮ＝２１のＰＤＵは、今や送信ウィンドウ（ＳＮ＝１２～ＳＮ＝２１）の中に入り、例えば、ＳＮ＝１２、１４－１９のＰＤＵの再送信と共に、受信側に送信することができる。
誤り訂正機能は、ＡＲＱ（Automatic Repeat reQuest）を使用してＲＬＣレイヤによって実現される。特に、ＲＬＣエンティティの送信側は、データの再送信をサポートし、一方、ＲＬＣエンティティの受信側は、下位レイヤにおけるデータの喪失の検出と、そのピアＲＬＣエンティティへの再送信の要求とをサポートする（例えば、参照することにより本明細書に組み込まれた、非特許文献６の第５．３節「ＡＲＱ手順」を参照）。ＡＲＱ機能は、ＲＬＣレイヤの受信側によって送信側に送信されるＳＴＡＴＵＳメッセージ（例えば、状態報告とも呼ばれる）に基づく。ＳＴＡＴＵＳメッセージは、ＲＬＣ ＰＤＵに対する肯定的および／または否定的な応答確認（受信失敗および受信成功の通知）を含むことができる。ＳＴＡＴＵＳメッセージは、ＲＬＣ ＰＤＵの失敗したおよび／または成功した受信のフィードバックを提供することができ、送信側が、どのＲＬＣ ＰＤＵが受信ＲＬＣ側に正常に送信されたかおよびどれがそうでなかったかを少なくとも特定することを可能にする。
ステータス報告の一例は、否定応答されたＲＬＣ ＰＤＵのシーケンス番号（ＮＡＣＫ＿ＳＮ）および肯定応答に対する１つのシーケンス番号（ＡＣＫ＿ＳＮ）を含み、ＡＣＫ＿ＳＮは、次の受信されなかったＲＬＣ ＳＤＵ（結果のステータス報告（累積応答確認）では欠落として示されない）のシーケンス番号に設定される。ＲＬＣエンティティの送信側は、ＳＮ＝ＡＣＫ＿ＳＮのＲＬＣ ＳＤＵまでの（しかしＳＮ＝ＡＣＫ＿ＳＮのＲＬＣ ＳＤＵは含まない）すべてのＲＬＣ ＳＤＵが、ＮＡＣＫ＿ＳＮのステータス報告に示されたＲＬＣ ＳＤＵを除いて、そのピアＲＬＣエンティティによって受信されたものとステータス報告を解釈する。このようなステータス報告の一例が、１２ビットのシーケンス番号が通信のために使用されるという仮定に基づいて、図５に示されている（例えば、参照することにより本明細書に組み込まれた非特許文献６の第５．３．４、６．２．３．１０～６．２．３．１７節を参照）。
送信ＲＬＣエンティティは、送信されたＲＬＣ ＰＤＵの受信フィードバック（成功または不成功などの受信状態）を取得するためのＲＬＣ ＳＴＡＴＵＳメッセージの送信をトリガするために、そのピアＲＬＣエンティティをポーリングすることができる。ＲＬＣステータスのポーリングは、例えば以下のうちの１つ以上など、さまざまな条件によってトリガすることができる。
－ 最後のポーリング後にすでに送信されたＰＤＵの数、
－ 最後のポーリング後にすでに送信されたバイト数、
－ 送信バッファ内の最後のＰＤＵの送信、
－ 最後のポーリング後の時間を示す、ポーリング再送タイマの満了
－ ＡＲＱウィンドウストールの発生。
ＲＬＣステータスメッセージは、それに応じてＡＭＤ ＰＤＵの対応するフィールドを設定し（例えば、「１」の値に設定された１ビットのＰフィールド。「０」の値に設定されたＰフィールドは、ステータスレポートが要求されないことを意味する）、そのＡＭＤ ＰＤＵを受信側に送信することによってポーリングされる（要求される）。
これに応じて、ＲＬＣエンティティの受信側は、そのようなポーリング要求を受信すると、そのピアＲＬＣエンティティ（送信側）にＳＴＡＴＵＳレポートを送信する。このＳｔａｔｕｓレポートは、ポーリングビットが設定された受信したＡＭＤ ＰＤＵ以下のシーケンス番号を持つＰＤＵの受信状態を含む。
ＩＡＢ－５Ｇにおける統合されたアクセスおよびバックホール
ミリ波ベースのセルラーアクセスは、空間的再利用を高め、より高い帯域幅を達成するものであるが、新しい５Ｇ ＮＲの不可欠な部分である。しかし、ミリ波帯で送信される信号は、大きなパスロスを被るため、ミリ波ベースのセルラーアクセスは、主に、スモールセルネットワークに対して実現可能である。多くのスモールセルに有線バックホールを提供することは、展開のコストおよび複雑さを増大させる可能性がある。他方、無線バックホールは、ネットワーク事業者が、追加のファイバ展開コストを招くことなく、スモールセル基地局を柔軟に展開することを容易にし、さらに、ネットワークの展開（rollout）の初期段階における増分展開を容易にする。特に、ファイバは、基地局のサブセット（アンカーノード）に展開することができ、残りの基地局のアクセストラフィックは、アンカーノードに無線でバックホールすることができる。
統合されたアクセスおよびバックホール（ＩＡＢ）は、ワイヤレスバックホールを実施する技術であり、ここで、アクセスおよびバックホール通信は、同じ規格の無線技術（例えば、５Ｇ ＮＲ）を使用し、これにより、高密度セルネットワークの柔軟な展開のための重要な基準である、異なる製造業者からの異なる基地局間の相互運用性が可能となる。ＩＡＢは、帯域内および帯域外の両方の中継を通して展開することができ、屋内および屋外の両方のネットワークで使用することができる。
ＩＡＢは、スタンドアロン（ＳＡ）および非スタンドアロン（ＮＳＡ）の展開をサポートすることができ、ＩＡＢのノードは、ＳＡまたはＮＳＡのモードで動作することができる。マルチホップバックホールは、シングルホップよりも大きな範囲拡張を提供し、その限定された範囲により６ＧＨｚ以上の周波数に対して特に有益である。展開におけるホップの最大数は、周波数やセル密度、伝播環境、トラフィック負荷など、多くの要因に依存することが予想される。
図６は、１つのＩＡＢドナーおよび多数のＩＡＢノード、ならびに異なるノードに接続することができるために２つ以上のホップを有するデータトラフィックルートを確立するＵＥを含む、統合されたアクセスバックホールに関する例示的な参考図を示す。例えば、ＩＡＢドナーは、基地局（サービング基地局、ｇＮＢ）に類似した一連の機能を有する単一の論理ノードと見なすことができる。
異なるレイヤ２（Ｌ２）とレイヤ３（Ｌ３）の中継アーキテクチャが可能であり、これらは、例えば、マルチホップ転送を達成するために必要なインタフェースおよび／または追加機能で必要とされる修正に関して異なる。これらのアーキテクチャは、２つのアーキテクチャグループに分けることができる。アーキテクチャグループ１は、ＩＡＢドナーで分かれている集約ノード（ＣＵ：Central Unit）／分散ノード（ＤＵ：Distributed Unit）を活用し、アーキテクチャグループ２では、中間ノード間のホップバイホップ転送が上位レイヤのユーザプレーンプロトコル（例えば、ＧＴＰ－Ｕ、ＵＤＰ、またはＩＰネステッドトンネリング）を使用する。
なお、中間ノードの存在は、ＵＥに対して透過的であってもよい、つまり、ＵＥは、ＵＥとＩＡＢドナ（サービング基地局）の間に中間ノードがあることを知らないことに留意されたい。
第１のアーキテクチャグループのアーキテクチャ１ａは、Ｆ１－Ｕのバックホールのために、アダプテーションレイヤまたはアダプテーションレイヤと組み合わせたＧＴＰ－Ｕを使用する。図７は、アーキテクチャオプション１ａを例示的に示す（例えば、参照することにより本明細書に組み込まれた非特許文献７の第６．３．１．１節を参照）。アーキテクチャグループ１については、アダプテーションレイヤの配置や、アダプテーションレイヤによってサポートされる機能、マルチホップＲＬＣのサポート、スケジューラに対する影響、ＱｏＳなど、いくつかのユーザプレーンの側面を考慮することができる。１つのユーザプレーンプロトコルアーキテクチャを選択するためには、これらのさまざまな側面の間でトレードオフが発生する可能性が高い。図８および図９は、アーキテクチャグループ１の例示的なユーザプレーンプロトコルアーキテクチャを示す（例えば、参照することにより本明細書に組み込まれた非特許文献７の第８．２．１節を参照）。これらの図から明らかなように、レイヤ２－中継は、アダプテーションレイヤを使用して（アダプテーションレイヤと組み合わせたＧＴＰ－Ｕを使用する代わりに）実行されることが例示的に仮定されている。アダプテーションレイヤは、例示的に、ＲＬＣレイヤの上またはＭＡＣレイヤの上に配置される。また、ＲＬＣレイヤは、ＲＬＣ ＡＲＱ機能と他の機能（ＲＬＣ分割など）の間で分割されないことが例示的に仮定されている。しかし、このユーザプレーンプロトコルアーキテクチャは、本願で均等に検討されることができる多くの異なるオプションの中の単なる１つにすぎない。
アダプテーションレイヤ（図中の例示的な「Adapt」）は、さまざまな機能をサポートすることができる（例えば、参照することにより本明細書に組み込まれた非特許文献７の第８．２．２節「アダプテーションレイヤ」を参照）。上記のアーキテクチャオプション１ａにおいて、それらの機能は、以下のうちの１つ以上を含むことができる。
－ ＰＤＵに対するＵＥベアラの識別
－ 無線バックホールトポロジ全体にわたるルーティング
－ スケジューラによる無線バックホールリンク上のＤＬおよびＵＬでのＱｏＳ実施
－ ＵＥユーザプレーンＰＤＵのバックホールＲＬＣチャネルへのマッピング
ＩＡＢは、アクセスのためにすでに５Ｇ ＮＲで定義されている既存の機能およびインタフェースの再利用に努めており、マルチホップ転送などの追加機能に加えて、これらの機能およびインタフェースの変更または強化も特定し定義することになっている。
本発明者らによって認識されるように、改善されたＲＬＣ ＡＲＱデザインは、統合されたアクセスおよびバックホールシナリオのために定義することができる。一般に、ＡＲＱは、エンドツーエンド（Ｅ２Ｅ：End-to-End））ソリューションとホップバイホップ（ＨＢＨ：Hop-by-Hop）ソリューションに分けることができるが、他のより複雑なソリューションにも分けることができる。Ｅ２ＥまたはＨＢＨ ＡＲＱを使用するかどうかは、実装されるプロトコルアーキテクチャにも依存する。上記のＲＬＣアダプテーションレイヤ（図８参照）を使用するプロトコルアーキテクチャは、ホップバイホップＡＲＱのみをサポートすることができるのに対し、上記のＭＡＣアダプテーションレイヤ（図９参照）を使用するプロトコルアーキテクチャは、ホップバイホップおよびエンドツーエンドＡＲＱの両方をサポートすることができる。両方のアダプテーションレイヤ配置（上記ＭＡＣ、上記ＲＬＣ）については、ＲＬＣ ＡＲＱを送信側（ＴＸ側）で前処理することができる。アダプテーションレイヤの配置については、他の観察を行うことができる（例えば、参照することにより本明細書に組み込まれた非特許文献７の第８．２．２節を参照）。
ここでは、エンドツーエンドＡＲＱは、ＲＬＣ ＡＲＱが、ＵＥおよびＩＡＢドナーノードなど、データトラフィックルートの２つのエンドノードの間で実行される点で、理解されるべきである。中間ノードをトラバースする、データトラフィックルート全体に対して１つのＡＲＱ処理のみが存在する。なお、ＭＡＣレイヤにおけるＨＡＲＱ（ハイブリッドＡＲＱ）は、依然としてホッピング毎に使用することができることに留意されたい。ＲＬＣ ＡＲＱは、データトラフィックルートの２つのエンドノード（例えば、ＵＥとＩＡＢドナー）の間で実行されるため、中間ノードは、ただ、ＲＬＣ ＰＤＵおよびＡＣＫ／ＮＡＣＫを（他の方向に）宛先に向けて中継するだけである。中継ホップのいずれか１つで失われたパケットの場合、その失われたパケット（受信側によって送信側にＮＡＣＫされる）は、すべての中継ホップ上で再送されなければならず、これは、ＰＤＵが以前ＰＤＵを正常に送信したホップ上で不必要に再送されることになるため、非効率的であると考えることができる。
さらに、ＰＤＵの再送信がエンドツーエンドＡＲＱに対してうまく機能するためには、受信フィードバック（例えば、ＡＣＫ／ＮＡＣＫ）も、受信機から送信機に戻る途中ですべての中継ホップをうまくトラバースする必要がある。ＡＣＫ／ＮＡＣＫは、ＲＬＣ ＰＤＵを肯定的にも否定的にも応答確認するために、状態報告メッセージ（ＲＬＣ ＡＲＱ ＳＴＡＴＵＳ ＰＤＵに関する上記説明を参照）を使用して送信することができる。その結果、そのような状態報告メッセージが中継ホップのいずれか１つで失われた場合、これにより、すべての中継ホップにわたってすでに正常に送信されたＰＤＵの再送が不必要にトリガされる可能性がある。
一方、ホップバイホップＡＲＱにおいて、ＡＲＱ機能は、直接的に互いに隣り合った２つのノード（例えば、図８参照）、つまり、1ホップのエンティティの間でそれぞれ実行される。したがって、ＮＡＣＫされたＰＤＵは、否定応答が決定されたホップ上でのみ再送信されることができ、これは、Ｅ２Ｅ ＡＲＱオプションと比較してより効率的である（とりわけ、無線アクセスと無線バックホールリンクの間で同じ周波数帯域幅を共有する帯域内（in-band）システムの場合）。しかし、ＨＢＨ－ＡＲＱは、実際には、フルＲＬＣレイヤ（より正確には、少なくともそれのＲＬＣ ＡＲＱ部分）がＩＡＢドナーのみならず中間ノードをも含むすべてのＩＡＢノードに展開される結果となる。したがって、中間ノードは、追加のＡＲＱステートマシンによってより複雑で高価になる可能性がある。これは、ファイバが最終的に利用可能である場合、ＩＡＢ中間ノードのＩＡＢドナーへのアップグレードが容易になるという利点によって相殺される可能性がある。
また、Ｅ２Ｅ ＡＲＱおよびＨＢＨ ＡＲＱは、Ｅ２Ｅ ＡＲＱにおけるマルチホップ中継のより長いラウンドトリップタイム（ＲＴＴ）に適応したり、または、Ｅ２Ｅ ＡＲＱ使用時の複数ホップ全体にわたる失われたＲＬＣステータス報告に対する影響を軽減するためのＲＬＣプロトコルにおける追加の機能に適応したりするために、ＲＬＣレイヤでのシーケンス番号空間を拡張する必要性など、３ＧＰＰ仕様に対するそれらの影響に関しても異なる。
マルチホップデータトラフィックルートにおけるフロー制御
上記のマルチホップＩＡＢバックホールシナリオでは（しかし、ＬＴＥ－Ａ中継展開など、ＩＡＢと直接的には関係のない、他の使用事例においても）、１つ以上の中間ノードでデータ輻輳が発生する可能性がある。データ輻輳は、ノードの受信（incoming）データ速度が送信（outgoing）データ速度よりも高いシナリオを指すものとして広く理解することができる。その結果、そのノード内のバッファが増加し、最終的にバッファオーバーフローおよびパケットドロップにつながる。フロー制御メカニズムは、データ輻輳を解決または軽減することができる。以下に説明するように、１つの解決策は、受信するデータトラフィックを減らすために、上流のノードに付与するリソースを少なくすることである（例えば、中間ノードが、ＵＥに付与するアップリンク無線リソースを減らす）。
例えば、アップリンクで、中間ＩＡＢノードは、他の上流ＩＡＢノードのｇＮＢとして機能し、ＵＬグラント、つまり、つまり、ＩＡＢノードに向かうアップリンクデータ速度を制御する現在の送信／スケジューリングメカニズムを調整することによって、上流ＩＡＢノード（またはＵＥ）からのアップリンクデータ量を制御することができる。これは、アップリンクにおける輻輳を軽減するための１つのメカニズムである。
ダウンリンクでは、下流ＩＡＢノードまたはＵＥへのリンクの容量は、上流ＩＡＢノードへのバックホールリンクの容量よりも小さい場合がある。上流ＩＡＢノードのＤＵ（Distribution Unit）側は、その下流ＩＡＢノードのダウンリンクバッファ状態を知らない場合があり、その結果、この中間ダウンストリームＩＡＢノードにおいてダウンリンクデータ輻輳およびパケット廃棄が生じる場合がある。ホップバイホップＡＲＱの場合、廃棄されたＰＤＵは、再送信されず、下流ＵＥのＰＤＣＰエンティティは、上位レイヤに順にＰＤＵを送る前に、ｔ－並び替え（t-reordering）タイマを待つ。この遅延は、上位レイヤに対して悪影響を及ぼす可能性があり、例えば、ＴＣＰスロースタートを引き起こす可能性がある。エンドツーエンドＡＲＱの場合、廃棄されたＰＤＵは、以前すでに正常に送信されたリンクのアップストリームで再送信される。これは、バックホールリンク容量を不必要に消費する。
追加でアップリンクおよびダウンリンクのデータ輻輳を回避し処理するフロー制御メカニズムを定義することができる。
図１０～図１５は、アップリンクおよびダウンリンクにおける、フロー制御の前（上側）およびフロー制御の後（下側）のさまざまな例示的な輻輳シナリオを、簡略化された例示的な形で示している。
図１０および図１１のアップリンクの例から明らかなように、輻輳およびパケットドロップは、例示的に２つの中間ノード１と２の間の弱いリンク（破線の矢印で示す）に起因して、中間ノード２で発生すると仮定されている。特に、中間ノード１（例えば、図８および図９に示す、Ｉ－ノード２の移動端末（ＭＴ：Mobile Terminal）側）に接続された中間ノード２の側のアップリンク送信バッファは、バッファオーバーフローとなり、パケット廃棄をもたらすことがある。フロー制御の結果、上流ノードＵＥ１は、弱いリンクで利用可能な送信容量に適合するようにデータ送信の速度を低下させるため、輻輳の問題は、中間ノード２で解決される（点線の矢印で示す）。
図１２および図１３のアップリンクの例は、ＩＡＢドナーとの弱い無線リンクに起因する中間ノード１でのアップリンクデータトラフィックのパケット輻輳を例示的に仮定している。フロー制御による、中間ノード２およびＵＥ１でのアップリンクデータ送信の適応は、点線の矢印を用いて示されている。
図１４および図１５のダウンリンクの例から明らかなように、輻輳およびパケットドロップは、例示的にＵＥ１への最後のホップの弱いリンクに起因して、中間ノード２で発生すると仮定されている。特に、ＵＥ（例えば、図８および図９に示すＤＵ側）に接続された中間ノード２の側は、ダウンリンク送信バッファオーバーフローとなることがある。Ｉ－ノード１は、Ｉ－ノード２のバッファ状態を知らず、Ｉ－ノード２は、この状態を制御することができないため、輻輳問題を解決するフロー制御メカニズムとしてグラントを適応させることは、この例示的なシナリオでは不可能である。いずれにしても、他の２つのシナリオについて上記したように、フロー制御は、理想的には、輻輳の課題を解決するために上流ノード（中間ノード１およびソースノード、例えば、ＩＡＢドナー）の一部または全部がデータ送信を低減する（点線の矢印で示す）という結果を有することができる。その結果、中間ノード２に到着するデータが少なくなり、中間ノード２は今やＵＥ１への最後のリンクで十分なデータを送信することができるようになったと仮定すると、輻輳問題は解決され、この理由でデータがドロップされる必要はない。
上記のフロー制御は、輻輳問題を解決することを達成するが、本発明者らは、前記関連においていくつかの問題を認識した。例えば、フロー制御は、かなり遅れて、つまり、輻輳および／またはパケットロスがすでに発生した時に、実行されることがある。輻輳およびパケットドロップが発生する前のフロー制御はない。また、フロー制御は、ホップ毎のフロー制御であり、これにより、輻輳問題が輻輳したノードからソースノードにゆっくりと伝播する可能性がある。例えば、まず１つの中間ノード（例えば、図１３のＩ－ノード１）が次の中間ノード（例えば、図１３のＩ－ノード２）へのアップリンク機会のグラントを少なくした場合、そのノード（つまり、Ｉ－ノード１）において輻輳を緩和することができる。しかし、この結果、Ｉ－ノード２が輻輳する可能性がある。これを順次繰り返すことにより、輻輳は、輻輳したノードからソースノードにゆっくりと伝播する。その結果、ソースノードからのデータの低減に時間がかかる。また、ダウンリンクにおけるフロー制御メカニズムの必要性がある。
本発明者らは、ダウンリンクおよびアップリンクにおける上記輻輳問題を回避または軽減することを容易にする効率的なフロー制御手順を定義する必要性を認識した。
以下では、この必要性を満たすＵＥ、基地局、および手順について、５Ｇ移動通信システムのために想定される新しい無線アクセス技術について説明する。さまざまな実装およびバリエーションについても説明する。以下の開示は、上記の議論および知見によって容易にされたものであり、例えば、少なくともその一部に基づくことができる。
しかし、一般的に、本明細書では、本開示の基礎をなす原理を明確かつ理解可能な方法で説明することができるように多くの仮定がなされていることに留意されたい。しかし、これらの仮定は、本開示の範囲を限定すべきではない例示目的のために本明細書に記載された単なる例として理解されるべきである。当業者であれば、以下の開示の原理および特許請求の範囲に記載された原理が、さまざまなシナリオに、本明細書に明示的に記載されていない方法で適用可能であることを認識するであろう。
さらに、以下で使用する、手順やエンティティ、レイヤなどの用語のいくつかは、ＬＴＥ／ＬＴＥ－Ａシステムに、または、現在の３ＧＰＰ ５Ｇ標準化で使用される用語に密接に関連しているが、次の３ＧＰＰ ５Ｇ通信システムのための新しい無線アクセス技術の文脈で使用される具体的な用語は、まだ完全には決定されていない。したがって、用語は、実施形態の機能に影響を及ぼすことなく、将来変更可能である。したがって、当業者は、実施形態およびその保護範囲が、最新のまたは最終合意された用語を欠くために本明細書で例示的に使用される特定の用語に限定されるべきではなく、本開示の機能および原理の基礎をなす機能および概念に関してより広く理解されるべきであることを認識する。
例えば、移動局または移動ノードまたはユーザ端末またはユーザ機器（ＵＥ）は、通信ネットワーク内の物理エンティティ（物理ノード）である。１つのノードは、いくつかの機能エンティティを有することができる。機能エンティティは、所定の一連の機能を、同じもしくは別のノードまたはネットワークの他の機能エンティティに実装および／または提供するソフトウェアまたはハードウェアモジュールを指す。ノードは、当該ノードを通信可能にする通信設備または媒体に当該ノードを接続する１つ以上のインタフェースを有することができる。同様に、ネットワークエンティティは、当該ネットワークエンティティを他の機能エンティティまたは対応するノードと通信可能にする通信設備または媒体に機能エンティティを接続する論理インタフェースを有することができる。
ここで、「基地局」または「無線基地局」という用語は、通信ネットワーク内の物理エンティティを指す。移動局と同様に、基地局は、いくつかの機能エンティティを有することができる。機能エンティティは、所定の一連の機能を、同じもしくは別のノードまたはネットワークの他の機能エンティティに実装および／または提供するソフトウェアまたはハードウェアモジュールを指す。物理エンティティは、１つ以上のスケジューリングおよび設定を含む、通信デバイスに関するいくつかの制御タスクを実行する。なお、基地局機能および通信デバイス機能は、単一のデバイス内に統合されてもよい。例えば、移動端末は、他の端末に対する基地局の機能も実装することができる。ＬＴＥで使用される用語は、ｅＮＢ（またはｅＮｏｄｅＢ）であり、５Ｇ ＮＲで現在使用されている用語は、ｇＮＢである。
特許請求の範囲および明細書で使用される「受信フィードバック」という表現は、送信側によって以前受信側に送信されたデータパケットの成功したまたは成功しなかった受信についての受信側からの任意の適切なフィードバックを意味するように広く解釈されるべきである。例示的な実装形態は、５Ｇ ＮＲに対する上記ＲＬＣ状態報告などの既存のメカニズムに基づくことができるが、それのバリエーションであってもよく、または完全に異なるものであってもよい。受信フィードバックを例示的にどのように実施するかに関するさらなる情報は、さまざまな実施形態を説明する際に提供される。
特許請求の範囲および明細書で使用される「送信ウィンドウ」という用語は、データパケット（例えば、ＲＬＣ ＰＤＵ）の送信に使用されるメカニズムとして広く解釈されるべきである。一例において、送信ウィンドウは、送信可能なデータパケットの数を制限する、なぜなら、送信ウィンドウサイズが、送信可能なデータパケットの数を決定するからである。また、送信ウィンドウは、例示的に、データパケットが正常に送信されたときに送信ウィンドウをスライドさせる（つまり、移動させる）スライディングウィンドウとして実装することができる。１つの例示的な実装は、５Ｇ ＮＲについて上記したＲＬＣ ＡＭウィンドウのような既存のメカニズムに基づくことができる。しかし、他の実装も同様に使用することができる。送信ウィンドウを実施する例示的な方法に関するさらなる情報は、さまざまな実施形態を説明する際に提供される。
図１６は、ユーザ機器（通信デバイスとも呼ばれる）およびスケジューリングデバイス（ここでは、例示的に、基地局、例えば、ｅＬＴＥ ｅＮＢ（あるいはｎｇ－ｅＮＢと呼ばれる）または５Ｇ ＮＲのｇＮＢに位置すると仮定される）の一般的な簡略化した例示的なブロック図を示す。ＵＥおよびｅＮＢ／ｇＮＢは、それぞれ送受信機を使用して、（無線）物理チャネルで互いに通信している。
通信デバイスは、送受信機および処理回路を有することができる。次に、送受信機は、受信機および送信機を有し、および／または、受信機および送信機として機能することができる。処理回路は、１つ以上のプロセッサまたは任意のＬＳＩなどの１つ以上のハードウェアであってもよい。送受信機と処理回路の間には、入出力点（またはノード）があり、これを通じて、処理回路は、動作中、送受信機を制御することができる、つまり、受信機および／または送信機を制御し、ならびに受信／送信データを交換することができる。送受信機は、送信機および受信機として、１つ以上のアンテナ、増幅器、ＲＦ（無線周波数）変調器／復調器などを含むＲＦフロントを含むことができる。処理回路は、自身が提供するユーザデータや制御データを送信しおよび／または自身がさらに処理するユーザデータや制御データを受信するように送受信機を制御することなどの制御タスクを実装することができる。また、処理回路は、判定や決定、計算、測定などの他の処理を実行する役割を果たすことができる。送信機は、送信処理およびこれに関連する他の処理を実行する役割を果たすことができる。受信機は、受信処理およびこれに関連する他の処理（例えば、チャネルの監視など）を実行する役割を果たすことができる。
したがって、この場合、さまざまな実施形態およびそのバリエーションの以下の開示から明らかになるように、本プロセッサは、送信ウィンドウサイズを決定するステップ、例えば、必要に応じて送信ウィンドウサイズを増減するステップを少なくとも部分的に実行するように例示的に構成することができる。また、処理回路は、タイマを動作させるステップ、例えば、タイマを起動し、モニタし、停止し、およびその満了を判定するステップを少なくとも部分的に実行することができる。処理回路によって少なくとも部分的に実行することができる別のタスクは、ＡＣＫやＮＡＣＫなどのフィードバック信号を評価して、データパケットが受信側で正常に受信されたかどうかを判定することである。
送信機は、データパケットを送信するステップを少なくとも部分的に実行することができるように構成することができる。
次に、受信機は、以前送信されたデータパケットに関する受信側からの受信フィードバックを受信するステップを少なくとも部分的に実行することができるように構成することができる。
以下で提供されるソリューションは、主に、新しい５Ｇ ＮＲ標準化（スタンドアロンおよび非スタンドアロン）、特にＩＡＢ拡張に適用されるが、ＬＴＥの中継などの他のシステムにも適用することができる。また、以下において、ソリューションは、主に、一方のエンドノードとしてのＵＥ、他方のエンドノードとしてのＩＡＢドナー、およびその間にある１つ以上のＩＡＢ中間ノードを含むマルチホップデータトラフィックルートを有するＩＡＢシナリオの文脈で提示される。しかし、これは、主に、ソリューションの説明を容易にするためである。したがって、以下に説明するソリューションは、単にＩＡＢシナリオにおいてのみ使用される必要はなく、ＬＴＥ中継のようなマルチホップデータトラフィックルートを有する他のシナリオにおいても使用することができる。
さらに、主な使用シナリオではないものの、以下のソリューションは、例えば、ＵＥが基地局（例えば、ｇＮＢ）に直接接続されているワンホップシナリオにも適用することができる。以下に例示的に仮定される簡略化したＩＡＢシナリオは、図１７に示され、２つのデータトラフィックルートを有する。一方は、ＵＥ１ － 中間ノード２（Ｉ－ノード２） － 中間ノード１（Ｉ－ノード１） － エンドノード（例えば、ＩＡＢドナー）であり、他方は、ＵＥ２ － 中間ノード３（Ｉ－ノード３） － 中間ノード１（Ｉ－ノード１） － エンドノード（例えば、ＩＡＢドナー）である。さらに、アップリンク送信シナリオが例示的に仮定され、それに従って、データは、ＵＥによってエンドノードに向けて送信され、それによって、それぞれの無線アクセスおよびバックホールリンクをトラバースする。
しかし、上記のソリューションは、サイドをそれぞれ交代して、例えば、ＵＥがデータ送信側ではなくデータ受信側である、ダウンリンクデータトラフィックルートにも適用することができる。これに対応して、エンドツーエンドＡＲＱソリューションでは、ＵＥが、したがって、受信ＲＬＣ ＡＲＱエンティティであり、ＩＡＢドナーが、送信ＲＬＣ ＡＲＱエンティティである。
さらに、本ソリューションは、以下で説明するように、エンドツーエンドＡＲＱアーキテクチャおよびホップバイホップＡＲＱアーキテクチャに適用することができる。
１つの例示的なソリューションについて、ＵＥ側（例えば、図１７のＵＥ１および／またはＵＥ２）で実行される処理シーケンスを示す図１８を参照して、説明する。なお、ここでは、ＵＥをデータトラフィックルートの送信側とする。したがって、同じ動作を、ＵＥではない送信側、例えば、サービング基地局、ＩＡＢドナーに対して使用することができる。この場合、ＵＥは、受信側となる。
例えば、実装されるＡＲＱアーキテクチャオプション（Ｅ２ＥまたはＨＢＨ ＡＲＱ）に応じて、受信フィードバックは、データトラフィックルートの中間ノード（ＨＢＨの場合）またはエンドノード（Ｅ２Ｅの場合）によって送信することができる。まず、このソリューションは、Ｅ２ＥおよびＨＢＨ ＡＲＱオプションの両方に適用可能であるが、主にＥ２Ｅ ＡＲＱオプションに関して説明する。
要するに、以下のソリューションは、以前送信されたデータパケットに対して決定された受信フィードバックに基づいて、送信ウィンドウサイズをデータトラフィックルートのデータトラフィック条件に適応させることを可能にする動的送信ウィンドウサイズメカニズムを導入する。
図１８から明らかなように、例示的で簡略化したＵＥ手順は、ユーザ機器がＩＡＢ無線バックホールによってエンドノードに向かってデータパケットを送信することから始まる。この送信は、送信ウィンドウに基づいてＵＥによって実行される。その後、ＵＥは、これら以前送信したデータパケットに関する受信フィードバックを、例えば、肯定応答および／または否定応答の形で受信する。
この例のシナリオにおいてＥ２Ｅ ＡＲＱソリューションを仮定すると、受信フィードバックをデータトラフィックルートのソースノード（つまり、ＵＥ）に送信するのは、データトラフィックルートの宛先ノード（つまり、ＩＡＢドナー）である。データパケットは、中間ＩＡＢノード（Ｉ－ノード１～３）によってＩＡＢドナーまで転送された。このＩＡＢドナーが、このようなデータパケットに対する受信フィードバックを決定し送信するエンティティである。
ＵＥは、受信フィードバックを受信した後、この受信フィードバックを使用して、送信ウィンドウ（データパケットの送信に使用されている）のサイズを変更する必要があるかどうか、例えば、送信ウィンドウのサイズが依然としてデータトラフィックルートに適切であるかどうかを決定することができる。
ＵＥは、送信ウィンドウのサイズを変更することを決定し、調整後のサイズの送信ウィンドウに基づいてデータパケットを送信することに進むことができる。一方、ＵＥは、送信ウィンドウのサイズを変更せずに維持することを決定し、変更なしのサイズの送信ウィンドウに基づいてデータパケットを送信することに進むことができる。
このソリューションにおいて、受信フィードバックは、送信側によって分析されると、下流における可能性のあるもしくは差し迫った輻輳についてのインジケータとして、または、より広く、下流で利用可能なデータスループットについてのインジケータとして使用することができる。例えば、ＵＥは、フィードバック（例えば、肯定的または否定的ＡＣＫ）のレイテンシから、キューの遅延およびスループットの制限を決定することができる。言い換えると、ＵＥは、送信ウィンドウサイズを適合させることが有利な状況（例えば、輻輳状況、低データスループット状況など）を識別するために、以前送信したデータパケット（例えば、受信側から受信した）の受信状態を分析する。
例えば、下流ノード（中間ノードＩ－ノード１など）の輻輳または差し迫った輻輳は、例えば、中間ノードと次の下流ノードとの間の弱いリンク（例えば、図１７において、Ｉ－ノード１とエンドノード（ＩＡＢドナー）の間の無線バックホールリンク）によって引き起こされる多くの否定応答されたデータパケットによって特徴付けることができる。データパケットは、中間ノードＩ－ノード１でドロップされ、これによって、このようなデータパケットに対して受信側（例えば、ＩＡＢドナー）から送信側（つまり、ＵＥ）に否定応答が送信されることがある。輻輳を回避または解決することを容易にするために、ＵＥは、それに基づいて、フロー制御メカニズムの一部として送信ウィンドウサイズを適合させることを決定することができる。
一方、多くの肯定応答されたデータパケットは、強いデータトラフィックルート（強いとは、例えば、良好な無線リンクを意味する）を示唆し、おそらくより多くのデータパケットの送信を可能にする。
ＵＥの動作は、データ送信を、マルチホップデータトラフィックルートの無線バックホールおよびアクセスリンク上の変化する条件に柔軟に適応させることができる。例えば、ＵＥは、データパケットの送信速度が低下するように送信ウィンドウサイズを小さくすることができる。これにより、データトラフィックを、無線リンク（弱いと仮定する）の（輻輳した）中間ノードの送信能力の低下に適応させることができる。したがって、中間ノードは、最初に輻輳状態になっていなくてもよく、または、すでに輻輳している場合、中間ノードが輻輳を低減または解決することを容易にしてもよい。
一方、データスループットを増加させるために、ＵＥは、送信ウィンドウサイズを大きくすることができる。例えば、これは、輻輳が解消された（例えば、干渉が少ないために、もはや弱いリンクがない）後に以前のデータスループットを回復するように、ＵＥが、小さくした送信ウィンドウサイズで（例えば、送信ウィンドウを小さくし、したがって、以前のデータスループットを減少させた後に）動作している場合に有利であり得る。例えば、多くの否定応答を受信する代わりに、ＵＥは、フロー制御後に、多くの肯定応答を受信し、したがって、送信ウィンドウサイズの縮小はもはや必要ではない（例えば、輻輳は解決された）と結論付けることができる。しかし、データスループットを増加させるために送信ウィンドウサイズを大きくすることは、例えば、データトラフィックルート上のデータスループットをさらに増加させることが可能である場合にも（例えば、滑らかな（fluent）データトラフィックルートの場合）、送信ウィンドウサイズを事前に小さくしておくことなく、有利であり得る。
全体的に、データスループットは、送信ウィンドウサイズを小さくする（例えば、弱い無線リンク、輻輳）（オプションとして、最小値よりもさらに下げることはない）ことによって低減することができ、また、データスループットは、送信ウィンドウサイズを大きくする（例えば、良好な無線リンク、輻輳なし）（オプションとして、最大値よりもさらに上げることはない）ことによって増大することができる。
送信ウィンドウサイズの縮小および増大は、異なるステップおよびステップサイズに沿って、例えば、毎回５ＰＤＵずつ増大／減少するように、段階的に実行することができる。上記のように、送信ウィンドウサイズのこのような段階的な適応は、最大（例えば、５０００、しかし任意の他の適切な数も同様に可能である）および最小（例えば、１ＰＤＵ、しかし任意の他の適切な数も同様に可能である）の送信ウィンドウサイズによって制限することができる。
少なくとも受信フィードバックに基づいて、送信ウィンドウサイズを増大または減少させる必要性（例えば、輻輳および／または調整されるデータパケットスループット）を識別する方法について、さまざまな基準および条件を定義することができる。さらなる例示的なバリエーションでは、他のシナリオをデータ輻輳から区別することを容易にするために、受信フィードバックに加えて、他の情報を前記決定のために使用することができる。例えば、以前送信されたデータパケットに対する受信フィードバックは、受信側から受信されるだけでなく、後でより詳細に説明するように、例えばタイマに基づいて、ＵＥによって自律的に決定されてもよい。別の例として、ＵＥは、例えば下流ノードからのチャネル品質報告、輻輳報告に関する他の情報を（例えば、アダプテーションレイヤを介して）取得することもでき、ＵＥは、このような情報を使用して前記決定を実行することができる。
１つのバリエーションにおいて、１つの条件は、ＵＥによって以前送信されたデータパケットに対して決定された連続的な肯定応答または否定応答の数に基づいている（例えば、応答確認が連続的なデータパケットを指すという意味で連続的である、つまり、連続的なシーケンス番号を有する）。例えば、チェックする条件は、連続的な否定応答の数が所定のしきい値よりも大きいかどうかであり、大きい場合、ＵＥは、送信ウィンドウサイズを小さくすることができる。逆に、大きくない場合、ＵＥは、送信ウィンドウサイズを小さくせず、送信ウィンドウサイズを変更せずに維持することができ、その送信ウィンドウを使用してデータパケットの送信を継続することができる。
これに対応して、ＵＥは、さらに、肯定応答に対して同様のチェックを実行して、連続的な肯定応答の数が所定のしきい値（連続的な否定応答との比較に使用されるしきい値と同じまたは異なる）よりも大きいかどうかを決定することができ、大きい場合、ＵＥは、送信ウィンドウサイズを大きくすることができる。逆に、大きくない場合、ＵＥは、送信ウィンドウサイズを大きくせず、送信ウィンドウサイズを変更せずに維持することができ、その送信ウィンドウを使用してデータパケットの送信を継続することができる。
ＵＥによってチェックされるさらなる代替的または追加的条件は、所定の時間内に決定された肯定応答および／または否定応答の数を参照することができる。具体的には、ＵＥは、一定の時間内に受信した肯定応答および否定応答をモニタする（この場合、これらの応答確認は、連続的なデータパケットを指しても指さなくてもよい）。前の条件についてちょうど説明した内容と同様に、このようにしてモニタされた肯定応答の数は、送信ウィンドウサイズを大きくするかどうかを決定するためにしきい値と比較することができ、逆もまた同様であり、このようにしてモニタされた否定応答の数は、送信ウィンドウサイズを小さくするかどうかを決定するために、ＵＥによって同じまたは別のしきい値と比較することができる。例えば、ＵＥは、ｘ秒の時間（例えば、ｘは３秒以上）の間に、ｙ個を超える肯定／否定応答（例えば、ｙは、送信されたパケットの数およびモニタ期間ｘの長さにも依存する）が受信されるかどうかを絶えずモニタする。
ＵＥによってチェックされるさらなる代替的または追加的条件は、送信されたデータパケットの総数と比較して肯定および／または否定応答の関係を決定することであり得る。例えば、ＵＥは、データパケットの総数を追跡し、これらの送信されたデータパケットに関して決定された肯定および／または否定応答をモニタする。例えば、関係（例えば、ＮＡＣＫ／データパケットおよびＡＣＫ／データパケットなど、パーセンテージとして表される）を、ＵＥによって決定し、それぞれのしきい値と比較することができる。パーセンテージがしきい値を超える場合、ＵＥは、送信ウィンドウサイズをそれぞれ小さくし（ＮＡＣＫのパーセンテージがＮＡＣＫのしきい値を超える場合）または大きくする（ＡＣＫパーセンテージがＡＣＫしきい値を超える場合）ことを決定する。
上記の条件は、単に例として理解されるべきである。当業者は、これらの条件のバリエーションまたは全く異なる条件を同様に定義することができる。
また、上記の説明では、送信ウィンドウのサイズを変更するかどうかを決定するのに使用される条件について別々に説明した。しかし、ソリューションの他のバリエーションは、送信ウィンドウサイズが変更されなければならないことをＵＥが決定するために、それらの条件の１つ以上が満たされなければならないということに頼ることができる。これは、輻輳または差し迫った輻輳などの状況を識別する信頼性を高めることができる。
送信ウィンドウサイズを変更するかどうかを決定するステップを実行するためのこれらの条件および／または対応するパラメータ（例えば、しきい値）は、例えばネットワーク側によって構成されて（例えば、ＩＡＢドナー。例えば、ＲＲＣレイヤの一部など上位レイヤ構成メッセージを使用して）、ＵＥに予め定められていてもよく、または、ＵＥにハードコードされてもよい（例えば、ＳＩＭカードを介して、もしくは３ＧＰＰ仕様に沿ってプログラムされて）。
上記のソリューションは、以前送信されたデータパケットに対して決定された受信フィードバックに基づいて適切に決定されたように送信ウィンドウサイズを段階的に増減させるものとして説明した。しかし、送信ウィンドウサイズを段階的に増減させることに付け加えて、以前送信されたデータパケットに対して得られた受信フィードバックに基づいてＵＥによって選択可能な少なくとも２つの異なる送信ウィンドウサイズを使用してソリューションを実現することも同様に可能である。
１つの例示的な実装によれば、ＵＥが受信フィードバックに応じて切り替える２つの送信ウィンドウサイズのみを定義することができる。例えば、最初の送信ウィンドウサイズは、データパケット送信を開始するためにＵＥによって使用されることができる。小さくした送信ウィンドウサイズ（例えば、最初の送信ウィンドウサイズの半分）は、送信ウィンドウサイズを小さくすることを決定した後に（例えば、あまりにも多くの否定応答が受信される場合）、さらなるデータパケット送信のために端末によって使用されることができる。次に、ＵＥは、やがて、送信ウィンドウサイズを再び大きくして最初に使用されたものにすることを決定することができ、以下同様である。
逆に、最初の送信ウィンドウサイズは、ＵＥが低い方のデータスループットで開始するように、小さい方の値とすることができ、低い方のデータスループットは、送信ウィンドウサイズを大きくする条件が発生したとの決定時に送信ウィンドウサイズを大きくすることによって高くすることができる。
しかし、上記では送信ウィンドウの２つの異なるサイズのみについて説明したが、他の例示的な実装は、ＵＥが選択できる３つ以上の適切な送信ウィンドウサイズを使用することができる。より多くの送信ウィンドウサイズを有することは、オプションとして、決定された受信フィードバックに基づいて送信ウィンドウサイズをどれだけ増減させるかを決定するために２つ以上のしきい値を実装することから利益を得ることもできる。これにより、より正確で、より細かい、なおかつ迅速なフロー制御メカニズムの実装が容易になる可能性がある。
図１９は、上記のソリューションに係る簡略化された例示的なＵＥ構造を示す。図１９に示すＵＥのさまざまな構成要素は、例えば、制御およびユーザデータならびに他の信号をやり取りするために、例えば、対応する入出力ノード（図示せず）を用いて、互いに相互接続することができる。説明目的で示されてはいないが、ＵＥは、さらなる構成要素を含むことができる。
同図から明らかなように、ＵＥは、送信ウィンドウに基づいて（例えば、送信ウィンドウサイズを更新する前後に）データパケットを送信するデータパケット送信機を含む。ＵＥは、さらに、少なくとも１つの送信されたデータパケットに関する受信フィードバックを受信する受信フィードバック受信機を含む。また、ＵＥは、受信フィードバック受信機によって受信された受信フィードバックに基づいて送信ウィンドウサイズを決定する回路（図１９の送信ウィンドウサイズ決定回路）を含む。
図２０は、上記の例示的なソリューションのうちの１つに係る１つの例示的なデータパケット交換を示す。例示的に、送信側およびソースノードとしてのＵＥは、ＩＡＢドナー（宛先ノードおよび受信側として）に向けてデータパケットを送信する際に、サイズが１０ＰＤＵの送信ウィンドウを使用すると仮定する。パケットは、中間ノードＩ－ノード２とＩ－ノード１によって転送される。また、例示的に、中間ノードＩ－ノード１は、輻輳（おそらくＩＡＢドナーへの弱い無線リンクによる）が発生し、その結果、受信するデータパケットの一部（例えば、パケット１１、１２、２０）のみが送信されるとも仮定する。データパケット１１、１２、２０は、実際に、ＩＡＢドナーで正常に受信されると仮定し、さらに、ＳＮ＝２０のデータパケットは、ＲＬＣステータスポーリング要求も含むと仮定する。このポーリング要求によって受信側で対応するフィードバックがトリガされると仮定すると、ＩＡＢドナーは、送信側（ＵＥ）に受信フィードバックを送信する。この受信フィードバックは、シーケンス番号１１、１２、２０（図のＡＣＫを参照）のデータパケットが正常に受信されたのに対し、シーケンス番号１３～１９のデータパケットは否定応答されたことを示す（図のＮＡＣＫを参照）。
ＵＥは、ＮＡＣＫの数から、輻輳がデータトラフィックルート内で発生していると決定し、送信ウィンドウサイズを半分に減らすことができる（例えば、この場合は５に減らす）。さらに、送信ウィンドウをスライドして、下端をＳＮ＝１３（つまり、１２＋１）、上端をＳＮ＝１７にする。これに対応して、シーケンス番号１３～１７のデータパケットをＵＥ側から送信し、一方、データトラフィックルートは、１３～１７をＩＡＢドナーに送信することができると仮定する。再び、対応する受信フィードバックは、受信側でトリガされ（例えば、パケット１７のポーリングビット）、ＵＥにシーケンス番号１３、１４、１７のデータパケットの肯定応答およびシーケンス番号１５、１６のデータパケットの否定応答を通知すると仮定する。
このようにして、データスループットは、最後の中間ノード（輻輳を伴う）の利用可能なスループット能力に適応される。
さまざまなソリューションについて上記したように、送信ウィンドウサイズは、動的であり、以前送信されたデータに対して送信側によって得られた受信フィードバックに基づいて適応させることができる。（ＡＲＭ ＲＬＣエンティティの）送信側は、送信ウィンドウサイズを適応させる一方で、受信側は、同様に自身の受信ウィンドウサイズを変更する必要はない。受信側は、以前と同じ受信ウィンドウサイズ、例えば、受信側が初期化されたサイズを維持することができる。例えば、受信ウィンドウは、可能な最大サイズで初期化され、たとえ送信側（例えば、ＵＥ）がその送信ウィンドウサイズを小さくしても変更されない。このようなソリューションでは、送信側が送信ウィンドウサイズを小さくしたことさえ気付かない。
他の例示的な実装において、送信ウィンドウサイズと受信ウィンドウサイズは、同期させることができ、この場合、送信ウィンドウサイズと受信ウィンドウサイズは、同じ程度に且つ（ほとんど）同時に増減少される。送信ウィンドウおよび受信ウィンドウのサイズを同期させることによって、受信側がＰＤＵを不正確に保持および／または廃棄する（その結果、異なるウィンドウスライディング動作をもたらす可能性がある）ことを防止することができる。
１つの例示的な実装において、受信側は、送信側と同じ決定、つまり、受信フィードバックに基づいて送信ウィンドウサイズを大きくするか、小さくするか、または維持する（つまり、変更しない）かの決定を行うことができる。この場合、送信側および受信側は、決定の同じ基礎（つまり、受信フィードバック）を有利に有することができる。
送信ウィンドウサイズと受信ウィンドウサイズを同期させるさらなるソリューションは、明示的なシグナリングを使用することである。例えば、新しい送信ウィンドウサイズに関する情報が、例えば、データパケットの一部として、受信側に送信される（例えば、状態報告ポーリングビットと同じまたは類似の方法で）。この情報により、受信側（例えば、アップリンクシナリオのＩＡＢドナー）は、同じ方法で受信ウィンドウの大きさを適応させることができる。
さらに、受信側は、応答確認タイマがすぐに満了することを知っている場合、受信フィードバックの送信を優先する（例えば、ユーザデータなどの他の送信よりも受信フィードバックを優先する）ようにさらに変更することができる。例えば、受信側は、応答確認タイマがすでに満了していることを知っている場合、受信フィードバックの送信の優先順位を下げるようにさらに変更することができる。送信されたデータパケットは、例えば、それがいつ送信側から送信されたかのようなタイムスタンプを含むことができ、その結果、受信側は、送信側の対応する応答確認タイマがいつ満了するかを予測することができる。
上記説明では、適応送信ウィンドウを使用するソリューションは、主に、送信側、例えば、図１７で仮定したアップリンクシナリオにおけるＵＥの観点から説明されている。
図２１は、図１７と同様に、ダウンリンクデータトラフィックルートの例示的なＩＡＢシナリオを示す。図２１のこの例示的なシナリオにおいて、ＵＥは、データパケットを受信するエンティティである。Ｅ２Ｅ ＡＲＱが実装され、それに従って、ＵＥが受信ＲＬＣ ＡＲＱエンティティを有し、ＩＡＢドナーが送信ＲＬＣ ＡＲＱエンティティを有することが、さらに例示的に仮定されている。ＵＥは、受信フィードバックを送信側（例えば、このシナリオではＩＡＢドナー）に報告する。一方、その後、送信側は、以前送信したデータパケットに対する受信フィードバックに基づいて、送信ウィンドウサイズの適応を実行する。ＵＥ（アップリンクシナリオにおける送信側として）およびＩＡＢドナー（アップリンクシナリオにおける受信側として）によって実行されるために説明されるさまざまなソリューションは、ＩＡＢドナー（ダウンリンクシナリオにおける送信側として）およびＵＥ（ダウンリンクシナリオにおける受信側として）の動作に同様に適用可能である。
手短にかつ概要として、ＩＡＢドナーは、送信ウィンドウに基づいてデータパケットをＵＥに送信し、ＵＥは、受信したデータパケットに対して受信フィードバックをＩＡＢドナーに返信する（データパケットが正常に復号できたかどうかに応じて肯定応答または否定応答となる）。この受信フィードバック（おそらくさらなる情報を伴う）に基づいて、ＩＡＢドナーは、例えば、送信ウィンドウサイズを大きくするか、小さくするか、または変更せずに維持するかのいずれかによって、その送信ウィンドウサイズを変更するかどうかを決定する。ＩＡＢドナーは、サイズが大きくなった、小さくなった、または以前と同じに維持されたいずれかの送信ウィンドウに基づいて、ダウンリンクでデータパケットの送信を継続する。
以下で説明するように、上記した図１８に係るソリューションは、主に、Ｅ２Ｅ ＡＲＱアーキテクチャの一部として説明されたが、ＡＲＱがすべてのホップで実行されるＨＢＨ ＡＲＱアーキテクチャにも適用することができる。したがって、このソリューションは、ＵＥと次の中間ノードの間や、２つの中間ノードの間、中間ノードとＩＡＢドナーの間など、データトラフィックルートの任意の２つのノードの間で実装することができる。これらは、ＵＥや中間ノード、ＩＡＢドナーなど、適用可能なノードそれぞれにおいて実装することができる。
より具体的には、ＵＥの後のデータトラフィックルートの最初の中間ノード（例えば、図１７において、ＵＥ１に対するＩ－ノード２、ＵＥ２に対するＩ－ノード３）は、以前送信されたデータパケットを受信し、ＨＢＨ ＡＲＱをサポートしている場合には、そのデータパケットの受信に関するフィードバックをＵＥ１に返信する。エンドツーエンドソリューションに関して非常に詳細に上述したように、ＵＥは、したがって、受信した受信フィードバックに基づいて送信ウィンドウサイズを適応させることができる。繰り返しを避けるため、読者は、上記の点に関して、Ｅ２Ｅのためのソリューションを説明した上記セクションを参照されたい。
上記したソリューションは、２つのエンドノードがＵＥとサービング基地局としてのｇＮＢであるワンホップシナリオにも適用可能である。このようなワンホップシナリオの場合、１つのホップしかないため、Ｅ２Ｅ ＡＲＱとＨＢＨ ＡＲＱとのソリューションを区別することは不要である。あるいは、言い換えれば、１つのホップ上のＡＲＱは、基本的に、同時にＥ２ＥとＨＢＨの両方である。これに対応して、データパケットの意図された受信者は、ＵＥのサービング基地局（例えば、ｇＮＢ）であり、受信フィードバックは、サービング基地局（例えば、ｇＮＢ）によってＵＥに送信される。
ソリューションの他のバリエーションにおいて、適応送信ウィンドウサイズに基づく上述の改善されたフロー制御メカニズムは、具体的な機会またはシナリオに対して選択的にアクティブにすることができる。上記のように、ソリューションは、マルチホップシナリオ（ＩＡＢなど）またはシングルホップシナリオにも適用することができるが、輻輳問題は、通常、マルチホップソリューションで発生する。したがって、ネットワーク側は、ＵＥがマルチホップシナリオにある場合にのみ、このようなフロー制御メカニズムをアクティブにすることを決定することができる。
１つのソリューションによれば、ネットワーク側は、このような改善されたフロー制御メカニズムを使用するかどうかを決定することができ、したがって、この点に関してユーザ機器を構成する。例えば、サービング基地局（例えば、ＩＡＢドナー）は、ＲＲＣシグナリングを使用して、例えば、ＲＲＣ再構成（RRC Reconfiguration）メッセージ、またはＲＲＣセットアップ（RRC setup）およびＲＲＣ再確立（RRC Reestablishment）メッセージなどの機能をアクティブにすることができる。
なお、実際の実装に応じて、データがマルチホップシナリオで送信されるかどうかは、ＵＥに対して透過的であってもよい、つまり、ＵＥは、いかなる中間ノードも認識しておらず、自身はサービング基地局（ＩＡＢドナー）に直接接続されていると仮定することに留意されたい。これに対応して、このようなシナリオにおいて、ＵＥは、単純に特定の使用シナリオを認識していないため、上記機能を自律的にアクティブにしなくてもよい。
以上、適応送信ウィンドウサイズを使用する改善されたフロー制御メカニズムについて、一般的に説明した。特定の実装において、これらのメカニズムおよびソリューションは、ＬＴＥフレームワークだけでなく既存および将来の５Ｇ ＮＲフレームワークにも実装することができる。例えば、ソリューションは、５Ｇ ＮＲに対して現在定義されているＲＬＣレイヤと組み合わせて実装することができる。上記のように、ＲＬＣレイヤは、実行される再送と、ＲＬＣ状態報告（Status Report）（図５参照）として実装される受信フィードバックとを有する、そのＡＭデータ転送に対するＡＲＱ機能を提供する。
ソリューションをＲＬＣ ＡＭプロトコル機能に実装する場合、ＲＬＣ ＡＭデータ転送は、固定サイズではなく、動的サイズ（ＡＭ＿ｗｉｎｄｏｗ＿ｓｉｚｅ）を有する送信ウィンドウを使用する。
以下、１つの非常に具体的な例示的実装について説明する。最大ウィンドウサイズ（Ｍａｘ＿ＡＭ＿ｗｉｎｄｏｗ＿ｓｉｚｅ）および異なる初期ウィンドウサイズ（Ｉｎｉｔ＿ＡＭ＿ｗｉｎｄｏｗ＿ｓｉｚｅ）（例えば、非特許文献６の第９．２節を参照）：
Ｍａｘ＿ＡＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ：
この定数は、各ＡＭ ＲＬＣエンティティの送信側と受信側の両方によって使用される。１２ビットＳＮが使用される場合、Ｍａｘ＿ＡＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ＝２０４８であり、１８ビットＳＮが使用される場合、Ｍａｘ＿ＡＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ＝１３１０７２である。
Ｉｎｉｔ＿ＡＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ：
Ｉｎｉｔ＿ＡＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅは、Ｍａｘ＿ＡＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅの半分に等しい。
受信側のＡＭデータ転送定義は、受信ウィンドウサイズとしてＭａｘ＿ＡＭ＿ｗｉｎｄｏｗ＿ｓｉｚｅを使用するように修正することができる。
さらに、送信側から受信側への受信フィードバック要求の送信は、ＲＬＣレイヤに対して定義されたトリガされた条件のうちの１つに従ってトリガされたポーリングビットに基づいて実行することができる。上記したように、受信側からのＲＬＣ状態報告のポーリングは、ＰＤＵのポーリングビットを送信側から受信側に送信することを含むことができる。上記ソリューションのさらなるバリエーションによれば、受信側から状態報告をポーリングするためのトリガされた条件のいくつかは、適応された送信ウィンドウサイズに適応させることができる。これにより、送信ＡＲＱ側が以前送信されたＰＤＵの受信状態を合理的な時間で取得することができることを容易にすることができる。
例えば、送信されたデータ量に基づくこれらのトリガは、送信ウィンドウサイズが送信可能なデータ量に強く影響することを考えると、適応された送信ウィンドウサイズに依存する。したがって、ユーザ機器は、これらのデータ量トリガ条件が満たされているかどうかを判定する際に、現在の送信ウィンドウサイズを考慮に入れることができる。
例えば、ＵＥは、少なくとも多くのデータパケットまたはバイトが、最後のＲＬＣ状態報告がポーリングされた後に送信されたかどうかを判定し、それらのデータパケットの送信に使用された送信ウィンドウサイズに基づいて、データパケットおよびバイトの数を増減する。
１つの特定の実施態様は、必要に応じてトリガ条件を拡大または縮小するためにスケーリングファクタを使用する。具体的には、スケーリングファクタは、例えば、最大送信ウィンドウサイズと使用される送信ウィンドウサイズとの間の関係を反映することができる。例えば、送信ウィンドウサイズの半分が使用された場合、ＲＬＣ状態報告をトリガする条件も半分にすることができ（例えば、データＰＤＵの半分および／またはバイトの半分）、また、その逆も同様である。
同様に、ＲＬＣ状態報告をポーリングするさらなるトリガ条件は、最後のポーリングが送信された後の時間を制御するポーリング再送時間（Poll retransmit time）の満了である。このタイマを送信ウィンドウサイズに応じてスケーリングすることにより、送信ウィンドウサイズが小さい場合に、ポーリングをより頻繁に送信することができる。これは、ウィンドウストールの回避を容易にするという利点を有することができる、なぜなら、ＲＬＣ状態報告内の応答確認がより早く受信され、それに対応して送信ウィンドウをより早くスライドさせることができるからである。
以上、トリガ条件の適応について、一般的に説明した。特定の実装において、それは、ＬＴＥフレームワークだけでなく既存および将来の５Ｇ ＮＲフレームワークにも実装することができる。例えば、ソリューションは、５Ｇ ＮＲに対して現在定義されているＲＬＣレイヤと組み合わせて実装することができる。
例えば、新しいスケーリングファクタ定義を、既存の定義に追加することができる（非特許文献６の第７．４節を参照）：
ｄ）ｐｏｌｌＩＡＢＳｃａｌｅ
このパラメータは、パラメータｐｏｌｌＰＤＵおよびｐｏｌｌＢｙｔｅならびにｔ－ＰｏｌｌＲｅｔｒａｎｓｍｉｔを拡大または縮小するために、各ＡＭ ＲＬＣエンティティの送信側によって使用される。
それに対応して、トリガ条件の一部または全部を適応された送信ウィンドウサイズに適応させることによって、受信フィードバックのポーリング（要求）は、より適切になり、必要に応じて時間的に前後にシフトさせることができる。
さらなる一連のバリエーションによれば、送信ノード（例えば、ＵＥ）は、以前送信されたデータパケットに対してタイマ（例えば、以下、応答確認タイマと呼ぶ）を制御することができる。例えば、ＵＥは、データパケットに対する肯定応答または否定応答を制御するために、送信されたデータパケットごとに１つのタイマを制御することができる。
１つの例示的な実装において、送信ノード（例えば、ＵＥ）は、データパケットの送信時に１つの応答確認タイマを起動することができる。このタイマは、そのデータパケット（つまり、タイマを起動したデータパケット）の受信状態に関するフィードバックを受信すると、停止される。フィードバックは、例えば、ＲＬＣ状態報告内で受信された、肯定応答または否定応答とすることができる。
データパケットに対してフィードバックが受信されない場合、対応する応答確認タイマは、やがて満了し、この場合、送信側は、各データパケットが受信側によって正しく受信されなかったと判定する。これに対応して、送信側は、そのデータパケットに対するＮＡＣＫを決定する。
１つの例示的なバリエーションによれば、ＮＡＣＫは、受信側から受信された（例えば、ＲＬＣ状態報告内の）ＮＡＣＫと同様に送信側によって使用することができる。このような応答確認タイマから決定されたＮＡＣＫおよび受信側から受信されたＮＡＣＫは、送信ウィンドウサイズを変更するかどうかを決定するために、送信側によって使用することができる。特に、上記の条件のいくつかは、以前送信されたデータパケットに対して得られたＮＡＣＫの数に依存する。
応答確認タイマおよびその時間値は、予め設定することができ、例えば、適切な構成メッセージを送信側（例えば、ＵＥ）に送信することによって、例えば、ネットワーク側によって設定することができる。１つの例において、応答確認タイマおよびその値は、ＲＲＣ再構成メッセージ、ＲＲＣセットアップメッセージ、またはＲＲＣ再確立メッセージの１つ以上を通じて設定することができる。
他方、追加的または代替的に、応答確認タイマおよびその時間値は、ＳＩＭの一部として予め決定し、または３ＧＰＰ仕様の一部として定義することができる。
ネットワーク側から設定されることによって容易になる１つの利点は、タイマの値を送信側（例えば、ＵＥ）と受信側（例えば、ＩＡＢドナー）との間のホップ数に適応させることができることである。特に、ルートが長いほど（例えば、ホップ数が多いほど）、応答確認タイマの値を長く設定することができ、逆に、ルートが短いほど（例えば、ホップ数が少ないほど）、応答確認タイマを短く設定することができる。
１つのさらなる利点は、応答確認タイマの値を、データパケットに関連付けられるサービスタイプに適応させることができることである。サービスタイプは、例えば、ビデオ会議サービスやベストエフォートサービス（電子メール、ＦＴＰ）などであり、帯域幅およびレイテンシに関して一定の要件を課すことができる。例えば、サービスの優先順位が高いほど、より多くの帯域幅が必要になることを意味することができる。この場合、優先順位が高いほど、タイマの値を長く設定することができる。
オプションとして、応答確認タイマが満了した際に送信側によって得られるＮＡＣＫを使用して、前記失われたデータパケットに対する送信側での再送信をトリガすることもできる。
以上、新しい応答確認タイマメカニズムについて、一般的に説明した。特定の実装において、それは、ＬＴＥフレームワークだけでなく既存および将来の５Ｇ ＮＲフレームワークにも実装することができる。例えば、ソリューションは、５Ｇ ＮＲに対して現在定義されているＲＬＣレイヤと組み合わせて実装することができる。
例えば、新しいタイマ定義を、既存の定義に追加することができる（非特許文献６の第７．３節を参照）：
ｄ）ｔ－ＩＡＢ＿ＮＡＣＫ
このタイマは、タイマ満了時にＮＡＣＫされているＰＤＵを決定するために、ＡＭ ＲＬＣエンティティの送信側によって使用される。
適応送信ウィンドウおよび応答確認タイマを使用する例示的なソリューションが、図２２に示されており、この図は、ＵＥ（送信側として）で実行されるプロセスのフロー図を示す。図１８のフロー図と比較すると、図２２は、送信ウィンドウサイズを増減する実装に言及している点、および、各データパケットに対して応答確認タイマを動作させ、それぞれの満了後にデータパケットに対する追加の否定応答を生成するのに使用される点で、より具体的である。その後、追加の否定応答は、送信ウィンドウサイズを大きくするか、小さくするか、または送信ウィンドウサイズを変更せずに維持するかの決定を行うのに使用することができる。
図２２から明らかなように、ＵＳは、送信された各データパケットに対して応答確認タイマを起動することができ、タイマが停止されるか（例えば、ＡＣＫまたはＮＡＣＫなどの受信した受信フィードバックによって）または満了するかについてタイマを制御することができる。応答確認タイマが満了すると、ＵＥは、対応するデータパケット（タイマを起動した）を正常に送信することができなかったと判定し、そのデータパケットを否定応答（ＮＡＣＫ）すべきものと認める。
このタイマ－ＮＡＣＫは、受信側から受信された受信フィードバックと共に使用して、送信ウィンドウを適応させることができる。この点に関して、送信ウィンドウサイズを適応させるかどうか、およびどのように適応させるかを決定するために、受信フィードバックに対して上記した条件のいずれかをチェックすることができる。その結果に応じて、送信ウィンドウサイズを大きくし、小さくし、または変更しない。いずれにせよ、ＵＥの手順は、送信ウィンドウ（大きくした、小さくした、または以前と同じサイズである）を使用してデータパケットの送信を続行する。
以下、さらなるソリューションについて説明する。本発明者らによって認識された、ＨＢＨ ＡＲＱ（例えば、ＩＡＢなどのマルチホップシナリオにおける）の１つの問題は、１つのホップにおけるＡＲＱ動作が別のホップにおけるＡＲＱ動作から分離されていることである。例えば、図８のＩＡＢノード２におけるダウンリンクでの輻輳を仮定した場合、ＤＵ側バッファは、ＵＥから多くのＮＡＣＫを受信するため、オーバーフローが始まるも、依然としてＩＡＢノード２のＭＴ側から受信ＰＤＵを受信する。ＩＡＢノード１はＩＡＢノード２のＭＴからＡＣＫのみを受信するため、ＩＡＢノード２とＩＡＢノード１との間のＡＲＱ動作は、正常に機能する。
以下のソリューションは、ノードがデータパケットを送信しているか、データパケットを受信しているかに応じて、ホップの２つのノード（それぞれホップの送信ノードと受信ノード）の間で使用することができる。例えば、ダウンリンクの場合、ＵＥは、受信ノードであることができ、第１の中間ノードは、送信ノードであることができる。アップリンクの場合には、ＵＥは、送信ノードとなり、第１の中間ノードは、受信ノードとなる。このロジックは、他のホップ、例えば、２つの中間ノードを含むホップ、または、１つの中間ノードとＩＡＢノードを含むホップでも同様に適用可能である。以下の状況の議論および説明を容易にするために、輻輳がＵＥの後の第１の中間ノード（図８のＩ－ノード２）においてアップリンクで発生するという例示的なシナリオを仮定する。ＨＢＨ ＡＲＱは、Ｉ－ノード２とＩ－ノード１の間で実行され、ＨＢＨ ＡＲＱは、ＵＥとＩ－ノード２の間で実行される。このシナリオにおいて、Ｉ－ノード２は、輻輳情報をＵＥに提供する。
しかし、ソリューションは、ＵＥとＩ－ノード２の間の第１のホップに関してそのようなアップリンクシナリオの文脈で説明されるが、当該ソリューションが、他のホップおよびダウンリンクシナリオにおいて同様に適用可能であることは、読者には明らかであろう。
１つの例示的なソリューションは、仮定されたシナリオのＩ－ノード２のような中間ノードのＤＵ側およびＭＴ側のうちの内部シグナリングに基づく。上記のように、中間ノードの一方の側における輻輳の場合、中間ノードの他方の側は、入ってくるデータパケットの応答確認を続ける。したがって、輻輳が発生しているまたは発生するであろうことを他方の側に内部的に示すことによって、中間ノードの他方の側は、さらに入ってくる（例えば、ＵＥから）データパケットに対するＡＲＱフィードバックの送信を止めることができる。例えば、入ってくるデータパケットの応答確認の停止は、例えば、他の側によって内部的に示されるまたは予め設定された時間量に制限することができる。これに対応して、上流ノード（例えば、仮定されたシナリオのＵＥ、または、他のシナリオでは別の中間ノードもしくはＩＡＢドナー）は、さらなるデータパケットの送信を減らす、なぜなら、その上流ノードは、ホップの受信側からの肯定応答がなければその送信ウィンドウをスライドすることができないからである。これにより、このような暗黙的指示は、輻輳問題を解決または回避することができる。
代替的または追加的ソリューションによれば、輻輳情報は、ホップの２つのノードの間で明示的に送信され、ホップバイホップＡＲＱを実行する場合、具体的に、輻輳が発生している中間ノード（例えば、中間ノード）から、データを送信するその上流ノード（例えば、仮定されたシナリオのＵＥ、または、他のシナリオでは別の中間ノードもしくはＩＡＢドナー）に送信される。
この輻輳情報は、例えば、受信フィードバック（例えば、ＲＬＣ ＡＲＱ情報）の一部として受信することができる。輻輳情報は、１ビットと短くあることができ、この場合、当該情報は、下流ノード（例えば、仮定されたシナリオのＩ－ノード２）の輻輳の有無を区別する。あるいは、輻輳情報は、数ビット長であることができ、この場合、当該情報は、輻輳についてより詳細な情報を提供することができる。例えば、輻輳情報は、次の下流ノードへの弱い無線リンクによる輻輳や、下流ノードによって提供される非常に限られたグラントによる輻輳など、輻輳のさまざまな理由を区別することができる。また、輻輳情報は、輻輳がどれくらい厳しいかを示すこともでき、これによって、輻輳情報を受信するノード（例えば、仮定されたシナリオのＵＥ）は、例えば、データ速度の低減量によって、適切に対応することができる。送信側（例えば、仮定されたシナリオのＵＥ）は、少なくとも一定の時間、ホップの受信側へのデータ送信の速度を低下させる。
ソリューションのさらなるバリエーションにおいて、ホップの送信側（例えば、仮定されたシナリオのＵＥ）は、ホップの受信側から受信した受信フィードバック（例えば、ＡＣＫ；ＮＡＣＫ）に基づいて輻輳情報を分析する。例えば、肯定応答および／または否定応答の分布によって、送信側（例えば、ＵＥ）は、輻輳によるパケットロスと、無線干渉によるパケットロスとを区別することができる。例えば、送信されたデータパケットにある程度均一に分布している否定応答は、パケットロスが輻輳に起因することを示している可能性がある。一方、一連の連続したＮＡＣＫ（つまり、連続したシーケンス番号を指す）は、パケットロスが無線干渉に起因することを示している可能性がある。
状況に応じて、ホップの送信側（例えば、ＵＥ）は、受信した輻輳情報に対して異なる対応をすることができる。例えば、パケットロスが主に下流ノードの輻輳に起因する場合、送信側（例えば、ＵＥ）は、送信ウィンドウサイズを縮小することができ、一方、パケットロスが主に無線干渉に起因する場合、送信側は、送信ウィンドウサイズを同じに保つことができる。
さらなる例示的実装によれば、ＨＢＨ ＡＲＱの場合、輻輳した中間ノードは、エンドノード（ＩＡＢドナー）によって与えられる情報を利用して、輻輳の影響を最小にするためにそのアグリゲーションポリシーを変更することができる。ＩＡＢドナーによって与えられた情報は、Ｆ１－ＡＰインタフェースを通して運ばれ、特定のサービスタイプのレイテンシがかなり増大したことを示す。その後、輻輳した中間ノードは、サービスタイプに基づいてデータベアラを集約することを決定することができ、特定のサービスタイプの集約されたベアラの送信にのみ焦点を当てる／優先順位を付ける。
さらなる態様
第１の態様によれば、ユーザ機器が提供され、当該ユーザ機器は、送信ウィンドウサイズを有する送信ウィンドウに基づいて少なくとも１つのデータパケットを送信する送信機を有する。前記ＵＥは、前記少なくとも１つの送信されたデータパケットに関する受信フィードバックを受信する受信機を有する。前記ＵＥは、少なくとも前記受信された受信フィードバックに基づいて、少なくともさらなるデータパケットを送信するために使用される前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定する処理回路を有する。
第１の態様に加えて提供される第２の態様によれば、前記送信機は、前記処理回路が前記送信ウィンドウサイズを変更すると決定した場合に、前記変更された送信ウィンドウサイズを有する前記送信ウィンドウに基づいて、さらなるデータパケットを送信する。
第１または第２の態様に加えて提供される第３の態様によれば、前記少なくとも１つのデータパケットは、無線リンク経由で、前記ユーザ機器のサービング基地局である基地局に直接送信され、前記受信フィードバックは、前記基地局から受信される。
あるいは、前記少なくとも１つのデータパケットは、少なくとも２つのホップを有するデータトラフィックルートの第１の中間ノードに送信される。前記データトラフィックルートは、ソースノードとしての前記ユーザ機器と、宛先ノードとしての受信エンティティとをさらに有する。前記少なくとも１つのデータパケットは、前記ユーザ機器によって前記ユーザ機器の隣にある前記第１の中間ノードに送信され、前記第１の中間ノードによって前記宛先ノードに向けて転送される。１つのオプションの実装において、前記受信フィードバックは、前記第１の中間ノードから受信され、前記少なくとも１つのデータパケットが前記宛先ノードによって正しく受信されたか否かを示す、または、もう１つのオプションの実装において、前記受信フィードバックは、前記第１の中間ノードから受信され、前記少なくとも１つのデータパケットが前記第１の中間ノードによって正しく受信されたか否かを示す。
第１～第３の態様のいずれかに加えて提供される第４の態様によれば、前記処理回路は、前記送信ウィンドウサイズを変更するかどうかを決定する際に、前記ユーザ機器によって以前送信された前記データパケットに対して決定された肯定的および／または否定的な応答確認に基づいて、前記送信ウィンドウサイズを大きくするかまたは小さくするかを決定する。
１つのオプションの実装において、前記送信ウィンドウサイズは、最大送信ウィンドウサイズよりも大きくすることはできず、また、１つのオプションの実装において、前記送信ウィンドウサイズは、最小送信ウィンドウサイズよりも小さくすることはできない。
第４の態様に加えて提供される第５の態様によれば、前記処理回路は、前記送信ウィンドウサイズを大きくするかまたは小さくするかを決定する際に、
以下の場合に前記送信ウィンドウサイズを大きくすることを決定し、
－ 多数の肯定応答が、前記ユーザ機器によって以前送信されたデータパケットに対する前記受信フィードバック内に受信され、前記多数の肯定応答は、連続したデータパケットに言及している、および／または
－ 多数の肯定応答が、定義された期間内に受信されている、および／または、
－ 送信されたデータパケットの数に対する肯定応答の割合が、しきい値を超えている、
以下の場合に前記送信ウィンドウサイズを小さくすることを決定する、
－ 多数の否定応答が、前記ユーザ機器によって以前送信されたデータパケットに対する前記受信フィードバック内に受信され、前記多数の否定応答は、連続したデータパケットに言及している、および／または
－ 多数の否定応答が、定義された期間内に受信されている、および／または、
－ 送信されたデータパケットの数に対する否定応答の割合が、しきい値を超えている。
第１～第５の態様のいずれかに加えて提供される第６の態様によれば、前記送信ウィンドウは、どのデータパケットを送信するかを決定するために前記ユーザ機器によって使用される。オプションの実装において、前記処理回路は、前記データパケットが前記送信ウィンドウの中のシーケンス番号に関連付けられている場合にはデータパケットを送信可能であると決定し、前記データパケットが前記送信ウィンドウの外のシーケンス番号に関連付けられている場合にはデータを送信不可であると決定する。
第１～第６の態様のいずれかに加えて提供される第７の態様によれば、前記受信機は、前記受信フィードバックに基づいて前記送信ウィンドウサイズを変更するメカニズムを開始するかどうかを前記ユーザ機器に設定するための設定メッセージを受信する。オプションの実装において、前記設定メッセージは、前記ユーザ機器の前記サービング基地局から受信され、前記サービング基地局は、前記データトラフィックルートの前記宛先ノードである。
第１～第７の態様のいずれかに加えて提供される第８の態様によれば、前記受信フィードバックは、以前送信された少なくとも１つのデータパケットに対する肯定応答または否定応答を示す状態報告である。オプションの実装において、前記受信フィードバックは、自動再送要求（ＡＲＱ）（否定応答されたデータパケットの再送信に基づく送信誤り訂正を実施するために前記ユーザ機器と受信側との間で使用されるメカニズム）の一部として送信される。１つのオプションの実装において、前記ＡＲＱメカニズムは、無線リンク制御（ＲＬＣ）レイヤの一部である。
第１～第８の態様のいずれかに加えて提供される第９の態様によれば、前記処理回路は、前記送信された少なくとも１つのデータパケットの各々に対して応答確認タイマを起動する。前記処理回路は、各データパケットに対する受信フィードバックを受信すると、前記応答確認タイマを停止する。前記応答確認タイマが満了すると、前記処理回路は、各データパケットが受信側によって正しく受信されなかったと判定し、オプションとして、正しく受信されなかったと判定された各データパケットを再送信することを決定する。１つのオプションの実装において、各データパケットが正しく受信されなかったという判定は、前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定する際に、否定応答として使用される。
第９の態様に加えて提供される第１０の態様によれば、前記受信機は、前記ユーザ機器のサービング基地局から、前記応答確認タイマの値を設定するための情報を含む設定メッセージを受信する。１つのオプションの実装において、前記応答確認タイマの前記値は、ソースノードとしての前記ユーザ機器とデータトラフィックルートの宛先ノードとの間の前記データトラフィックルートのホップ数に比例する。１つのオプションの実装において、前記応答確認タイマの前記値は、前記ユーザ機器によって送信された前記少なくとも１つのデータパケットに関連付けられたサービス種別に依存する。
第１～第１０の態様のいずれかに加えて提供される第１１の態様によれば、前記処理回路は、少なくとも１つのトリガ条件が、前記送信された少なくとも１つのデータパケットに対する前記受信フィードバックを送信させるために受信フィードバック要求の前記受信側への送信をトリガするかどうかを判定する。前記少なくとも１つのトリガ条件は、以下のうちの少なくとも１つを含む、
－ 少なくともいくつかのデータパケットが前回の受信フィードバック要求の後に送信されていること、
－ 少なくともいくつかのバイト数のデータが前回の受信フィードバック要求の後に送信されていること、
－ 前回の受信フィードバック要求が送信された後の時間を示す受信フィードバック要求タイマの満了。
前記処理回路は、前記トリガ条件のうちの少なくとも１つが前記受信フィードバック要求の前記送信をトリガするかどうかを判定する際に、データパケットを送信するために前記ユーザ機器によって使用される前記送信ウィンドウサイズを考慮する。
第１～第１１の態様のうちのいずれか１つに加えて第１２の態様によれば、前記少なくとも１つのデータパケットは、少なくとも２つのホップを有するデータトラフィックルートの第１の中間ノードに送信される。前記データトラフィックルートは、ソースノードとしての前記ユーザ機器と、宛先ノードとしての受信エンティティとをさらに有する。前記受信機は、以前送信されたデータパケットに対する前記受信フィードバックと共に輻輳情報を受信し、前記輻輳情報は、前記データトラフィックルートの前記第１の中間ノード、前記ソースノード、および前記宛先ノードのうちの少なくとも１つがデータ輻輳に遭っていることを示す。前記処理回路は、一定期間データパケットの送信を減少させるよう前記送信機を制御する。オプションの実装において、前記受信フィードバック内の前記輻輳情報は、１ビットである。前記輻輳情報は、応答確認の分布など、前記受信フィードバックのパターンから解釈される。
第１３の態様によれば、前記ユーザ機器によって実行される以下のステップを有する方法が提供される。少なくとも１つのデータパケットが、送信ウィンドウサイズを有する送信ウィンドウに基づいて送信される。前記少なくとも１つの送信されたデータパケットに関する受信フィードバックが受信される。少なくとも前記受信された受信フィードバックに基づいて、少なくともさらなるデータパケットを送信するために使用される前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかが決定される。
第１４の態様によれば、サービング基地局が提供される。前記サービング基地局の送信機は、送信ウィンドウサイズを有する送信ウィンドウに基づいて少なくとも１つのデータパケットを送信する。前記サービング基地局の受信機は、前記少なくとも１つの送信されたデータパケットに関する受信フィードバックを受信する。前記サービング基地局の処理回路は、少なくとも前記受信された受信フィードバックに基づいて、少なくともさらなるデータパケットを送信するために使用される前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定する。
第１４の態様に加えて提供される第１５の態様によれば、前記サービング基地局は、ＩＡＢ（統合されたアクセス＆バックホール）ドナーであり、オプションとして、前記ＩＡＢドナーは、ユーザ機器が前記少なくとも１つのデータパケットの宛先ノードであり且つ少なくとも１つの中間ＩＡＢノードが存在するダウンリンクデータトラフィックルートにおけるソースノードである。
本開示のハードウェアおよびソフトウェア実装
本開示は、ソフトウェア、ハードウェア、またはハードウェアと連携したソフトウェアで実現することができる。上記各実施の形態の説明に用いた各機能ブロックは、部分的または全体的に、集積回路などのＬＳＩによって実現可能であり、また、各実施形態で説明した各処理は、部分的または全体的に、同じＬＳＩまたはＬＳＩの組み合わせによって制御されてもよい。ＬＳＩは、チップとして個別に形成されてもよいし、または、機能ブロックの一部または全部を含むように１つのチップが形成されてもよい。ＬＳＩは、データ入力とこれに接続されたデータ出力を含んでもよい。ここで、ＬＳＩは、集積度の違いにより、ＩＣ（integrated circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることがある。しかし、集積回路を実現する技術は、ＬＳＩに限られるものではなく、専用回路、汎用プロセッサ、または専用プロセッサを用いて実現されてもよい。また、ＬＳＩ製造後にプログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）、または、ＬＳＩ内部に配置された回路セルの接続および設定を再構成可能なリコンフィギャラブル・プロセッサを使用してもよい。本開示は、デジタル処理またはアナログ処理として実現することができる。半導体技術または他の派生技術の進歩の結果として将来の集積回路技術がＬＳＩに取って代わる場合には、その将来の集積回路技術を用いて機能ブロックを集積化することができる。バイオテクノロジーも適用可能である。
また、さまざまな実施形態は、プロセッサによって実行されるソフトウェアモジュールによって実装することもでき、または、ハードウェアに直接実装することもできる。また、ソフトウェアモジュールとハードウェア実装の組み合わせも可能である。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体、例えば、ＲＡＭやＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ－ＲＯＭ、ＤＶＤなどに格納することができる。さらに、異なる実施形態の個々の特徴は、個別にまたは任意の組み合わせで、別の実施形態の主題となることができることに留意されたい。
当業者であれば、具体的な実施形態に示される本開示に対して多数の変更および／または修正を行うことができることを理解するであろう。したがって、本実施形態は、すべての点で例示であり、限定ではないと考えられるべきである。

Claims (18)

  1. 動作中、送信ウィンドウサイズを有する送信ウィンドウに基づいて少なくとも１つのデータパケットをサービング基地局に送信する送信機と、
    動作中、前記サービング基地局から、前記少なくとも１つの送信されたデータパケットに関する受信フィードバックを肯定応答および／または否定応答として受信する受信機と、
    動作中、少なくとも前記受信された受信フィードバックに基づいて、少なくともさらなるデータパケットを送信するために使用される前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定する処理回路と、
    を有し、
    前記少なくとも１つの送信されたデータパケットに対して受信される前記否定応答の数が、しきい値を超えている場合に、前記送信ウィンドウサイズを小さくすることを決定する、
    ユーザ機器。
  2. 前記送信機は、動作中、前記処理回路が前記送信ウィンドウサイズを変更すると決定した場合に、前記変更された送信ウィンドウサイズを有する前記送信ウィンドウに基づいて、さらなるデータパケットを送信する、
    請求項１に記載のユーザ機器。
  3. 前記少なくとも１つのデータパケットは、無線リンク経由で、前記ユーザ機器の前記サービング基地局である基地局に直接送信され、前記受信フィードバックは、前記基地局から受信される、
    または、
    前記少なくとも１つのデータパケットは、少なくとも２つのホップを有するデータトラフィックルートの第１の中間ノードに送信され、前記データトラフィックルートは、ソースノードとしての前記ユーザ機器と、宛先ノードとしての受信エンティティとをさらに有し、前記少なくとも１つのデータパケットは、前記ユーザ機器によって前記ユーザ機器の隣にある前記第１の中間ノードに送信され、前記第１の中間ノードによって前記宛先ノードに向けて転送される、
    前記受信フィードバックは、前記第１の中間ノードから受信され、前記少なくとも１つのデータパケットが前記宛先ノードによって正しく受信されたか否かを示す、または、
    前記受信フィードバックは、前記第１の中間ノードから受信され、前記少なくとも１つのデータパケットが前記第１の中間ノードによって正しく受信されたか否かを示す、
    請求項１または２に記載のユーザ機器。
  4. 前記処理回路は、前記送信ウィンドウサイズを変更するかどうかを決定する際に、
    前記ユーザ機器によって以前送信された前記データパケットに対して決定された肯定的および／または否定的な応答確認に基づいて、前記送信ウィンドウサイズを大きくするかまたは小さくするかを決定する、
    前記送信ウィンドウサイズは、最大送信ウィンドウサイズよりも大きくすることはできず、
    前記送信ウィンドウサイズは、最小送信ウィンドウサイズよりも小さくすることはできない、
    請求項１～３の一項に記載のユーザ機器。
  5. 前記処理回路は、前記送信ウィンドウサイズを大きくするかまたは小さくするかを決定する際に、
    以下の場合に前記送信ウィンドウサイズを大きくすることを決定し、
    － 前記ユーザ機器によって以前送信されたデータパケットに対する前記受信フィードバック内に受信される肯定応答の数が、しきい値を超え、前記肯定応答の数は、連続したデータパケットに言及している、および／または
    － 定義された期間内に受信される肯定応答の数が、しきい値を超えている、および／または、
    － 送信されたデータパケットの数に対する肯定応答の割合が、しきい値を超えている、
    以下の場合に前記送信ウィンドウサイズを小さくすることを決定する、
    － 前記ユーザ機器によって以前送信されたデータパケットに対する前記受信フィードバック内に受信される否定応答の数が、しきい値を超え、前記否定応答の数は、連続したデータパケットに言及している、および／または
    － 定義された期間内に受信される否定応答の数が、しきい値を超えている、および／または、
    － 送信されたデータパケットの数に対する否定応答の割合が、しきい値を超えている、
    請求項４に記載のユーザ機器。
  6. 前記送信ウィンドウは、どのデータパケットを送信するかを決定するために前記ユーザ機器によって使用され、
    前記処理回路は、動作中、前記データパケットが前記送信ウィンドウの中のシーケンス番号に関連付けられている場合にはデータパケットを送信可能であると決定し、前記データパケットが前記送信ウィンドウの外のシーケンス番号に関連付けられている場合にはデータを送信不可であると決定する、
    請求項１～５の一項に記載のユーザ機器。
  7. 前記受信機は、動作中、前記受信フィードバックに基づいて前記送信ウィンドウサイズを変更するメカニズムを開始するかどうかを前記ユーザ機器に設定するための設定メッセージを受信し、
    前記設定メッセージは、前記ユーザ機器の前記サービング基地局から受信され、前記サービング基地局は、前記データトラフィックルートの前記宛先ノードである、
    請求項３に記載のユーザ機器。
  8. 前記受信フィードバックは、以前送信された少なくとも１つのデータパケットに対する肯定応答または否定応答を示す状態報告であり、
    前記受信フィードバックは、自動再送要求（ＡＲＱ）（否定応答されたデータパケットの再送信に基づく送信誤り訂正を実施するために前記ユーザ機器と受信側との間で使用されるメカニズム）の一部として送信され、前記ＡＲＱメカニズムは、無線リンク制御（ＲＬＣ）レイヤの一部である、
    請求項１～７の一項に記載のユーザ機器。
  9. 前記処理回路は、動作中、前記送信された少なくとも１つのデータパケットの各々に対して応答確認タイマを起動し、前記処理回路は、動作中、各データパケットに対する受信フィードバックを受信すると、前記応答確認タイマを停止し、
    前記応答確認タイマが満了すると、前記処理回路は、動作中、各データパケットが受信側によって正しく受信されなかったと判定し、正しく受信されなかったと判定された各データパケットを再送信することを決定し、
    各データパケットが正しく受信されなかったという判定は、前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定する際に、否定応答として使用される、
    請求項１～８の一項に記載のユーザ機器。
  10. 前記受信機は、動作中、前記ユーザ機器のサービング基地局から、前記応答確認タイマの値を設定するための情報を含む設定メッセージを受信し、
    前記応答確認タイマの前記値は、ソースノードとしての前記ユーザ機器とデータトラフィックルートの宛先ノードとの間の前記データトラフィックルートのホップ数に比例し、
    前記応答確認タイマの前記値は、前記ユーザ機器によって送信された前記少なくとも１つのデータパケットに関連付けられたサービス種別に依存する、
    請求項９に記載のユーザ機器。
  11. 前記処理回路は、動作中、少なくとも１つのトリガ条件が、前記送信された少なくとも１つのデータパケットに対する前記受信フィードバックを送信させるために受信フィードバック要求の前記受信側への送信をトリガし、前記少なくとも１つのトリガ条件は、以下のうちの少なくとも１つを含み、
    － 少なくともいくつかのデータパケットが前回の受信フィードバック要求の後に送信されていること、
    － 少なくともいくつかのバイト数のデータが前回の受信フィードバック要求の後に送信されていること、
    － 前回の受信フィードバック要求が送信された後の時間を示す受信フィードバック要求タイマの満了、
    前記処理回路は、動作中、前記トリガ条件のうちの少なくとも１つが前記受信フィードバック要求の前記送信をトリガするかどうかを判定する際に、データパケットを送信するために前記ユーザ機器によって使用される前記送信ウィンドウサイズを考慮する、
    請求項８～１０の一項に記載のユーザ機器。
  12. 前記少なくとも１つのデータパケットは、少なくとも２つのホップを有するデータトラフィックルートの第１の中間ノードに送信され、前記データトラフィックルートは、ソースノードとしての前記ユーザ機器と、宛先ノードとしての受信エンティティとをさらに有し、
    前記受信機は、動作中、以前送信されたデータパケットに対する前記受信フィードバックと共に輻輳情報を受信し、前記輻輳情報は、前記データトラフィックルートの前記第１の中間ノード、前記ソースノード、および前記宛先ノードのうちの少なくとも１つがデータ輻輳に遭っていることを示し、
    前記処理回路は、動作中、一定期間データパケットの送信を減少させるよう前記送信機を制御し、
    前記受信フィードバック内の前記輻輳情報は、１ビットであり、
    前記輻輳情報は、応答確認の分布が示す前記受信フィードバックのパターンから解釈される、
    請求項１～１１の一項に記載のユーザ機器。
  13. ユーザ機器によって実行される以下のステップを有する方法であって、
    送信ウィンドウサイズを有する送信ウィンドウに基づいて少なくとも１つのデータパケットを送信するステップと、
    前記少なくとも１つの送信されたデータパケットに関する受信フィードバックを肯定応答および／または否定応答として受信するステップと、
    少なくとも前記受信された受信フィードバックに基づいて、少なくともさらなるデータパケットを送信するために使用される前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定するステップと、
    を有し、
    前記少なくとも１つの送信されたデータパケットに対して受信される前記否定応答の数が、しきい値を超えている場合に、前記送信ウィンドウサイズを小さくすることを決定する、
    方法。
  14. 動作中、送信ウィンドウサイズを有する送信ウィンドウに基づいて少なくとも１つのデータパケットをユーザ機器に送信する送信機と、
    動作中、前記ユーザ機器から、前記少なくとも１つの送信されたデータパケットに関する受信フィードバックを肯定応答および／または否定応答として受信する受信機と、
    動作中、少なくとも前記受信された受信フィードバックに基づいて、少なくともさらなるデータパケットを送信するために使用される前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定する処理回路と、
    を有し、
    前記少なくとも１つの送信されたデータパケットに対して受信される前記否定応答の数が、しきい値を超えている場合に、前記送信ウィンドウサイズを小さくすることを決定する、
    サービング基地局。
  15. 前記サービング基地局は、ＩＡＢ（統合されたアクセス＆バックホール）ドナーであり、前記ＩＡＢドナーは、前記ユーザ機器が前記少なくとも１つのデータパケットの宛先ノードであり且つ少なくとも１つの中間ＩＡＢノードが存在するダウンリンクデータトラフィックルートにおけるソースノードである、
    請求項１４に記載のサービング基地局。
  16. サービング基地局によって実行される以下のステップを有する方法であって、
    送信ウィンドウサイズを有する送信ウィンドウに基づいて少なくとも１つのデータパケットを送信するステップと、
    前記少なくとも１つの送信されたデータパケットに関する受信フィードバックを肯定応答および／または否定応答として受信するステップと、
    少なくとも前記受信された受信フィードバックに基づいて、少なくともさらなるデータパケットを送信するために使用される前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定するステップと、
    を有し、
    前記少なくとも１つの送信されたデータパケットに対して受信される前記否定応答の数が、しきい値を超えている場合に、前記送信ウィンドウサイズを小さくすることを決定する、
    方法。
  17. ユーザ機器の処理を制御する集積回路であって、前記処理は、
    送信ウィンドウサイズを有する送信ウィンドウに基づいて少なくとも１つのデータパケットを送信する処理と、
    前記少なくとも１つの送信されたデータパケットに関する受信フィードバックを肯定応答および／または否定応答として受信する処理と、
    少なくとも前記受信された受信フィードバックに基づいて、少なくともさらなるデータパケットを送信するために使用される前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定する処理と、
    を有し、
    前記少なくとも１つの送信されたデータパケットに対して受信される前記否定応答の数が、しきい値を超えている場合に、前記送信ウィンドウサイズを小さくすることを決定する、
    集積回路。
  18. サービング基地局の処理を制御する集積回路であって、前記処理は、
    送信ウィンドウサイズを有する送信ウィンドウに基づいて少なくとも１つのデータパケットを送信する処理と、
    前記少なくとも１つの送信されたデータパケットに関する受信フィードバックを肯定応答および／または否定応答として受信する処理と、
    少なくとも前記受信された受信フィードバックに基づいて、少なくともさらなるデータパケットを送信するために使用される前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定する処理と、
    を有し、
    前記少なくとも１つの送信されたデータパケットに対して受信される前記否定応答の数が、しきい値を超えている場合に、前記送信ウィンドウサイズを小さくすることを決定する、
    集積回路。
JP2020571631A 2018-09-25 2019-09-09 データの送信に関与するユーザ機器および基地局 Active JP7446247B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP18196683.9A EP3629505A1 (en) 2018-09-25 2018-09-25 User equipment and base station involved in transmission of data
EP18196683.9 2018-09-25
PCT/EP2019/073973 WO2020064310A1 (en) 2018-09-25 2019-09-09 User equipment and base station involved in transmission of data

Publications (2)

Publication Number Publication Date
JP2022500885A JP2022500885A (ja) 2022-01-04
JP7446247B2 true JP7446247B2 (ja) 2024-03-08

Family

ID=63685604

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020571631A Active JP7446247B2 (ja) 2018-09-25 2019-09-09 データの送信に関与するユーザ機器および基地局

Country Status (5)

Country Link
US (1) US11973604B2 (ja)
EP (2) EP3629505A1 (ja)
JP (1) JP7446247B2 (ja)
CN (1) CN112313894B (ja)
WO (1) WO2020064310A1 (ja)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020048510A1 (en) * 2018-09-07 2020-03-12 Intel Corporation Apparatus and method for congestion handling in radio access network
GB2581121B (en) * 2018-10-31 2021-06-02 Tcl Communication Ltd Bearer mapping in a wireless communications network
WO2020097883A1 (zh) * 2018-11-15 2020-05-22 北京小米移动软件有限公司 传输消息的方法及装置
WO2020129228A1 (ja) * 2018-12-20 2020-06-25 株式会社Ｎｔｔドコモ 無線ノード、及び、無線通信方法
CN111490857A (zh) * 2019-01-25 2020-08-04 夏普株式会社 适配实体和rlc实体的无线通信方法及通信设备
CN113162862A (zh) * 2020-01-23 2021-07-23 华为技术有限公司 拥塞控制方法及装置
US11856450B2 (en) * 2020-02-27 2023-12-26 Qualcomm Incorporated Range extension for radio link control status reporting
US11438269B2 (en) * 2020-05-20 2022-09-06 Verizon Patent And Licensing Inc. Systems and methods for congestion control in an integrated access and backhaul network
WO2022030517A1 (ja) * 2020-08-05 2022-02-10 京セラ株式会社 通信制御方法
EP4096174B1 (en) * 2021-05-26 2023-05-10 OY Gamecluster Ltd Delivery of transport layer packets

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004222271A (ja) 2002-12-27 2004-08-05 Ntt Docomo Inc 伝送制御方法、通信装置、通信システム及びプログラム
US20110090793A1 (en) 2007-10-17 2011-04-21 Rudiger Halfmann Method and Device for Data Communication and Communication System Comprising Such Device
JP2011188429A (ja) 2010-03-11 2011-09-22 Kyocera Corp 無線通信装置

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6519223B1 (en) * 1999-04-06 2003-02-11 Telefonaktiebolaget L M Ericsson (Publ) System and method for implementing a semi reliable retransmission protocol
US6778509B1 (en) * 1999-11-19 2004-08-17 Hughes Electronics Corporation MAC layer protocol for a satellite based packet switched services
DE60236138D1 (de) * 2002-01-03 2010-06-10 Innovative Sonic Ltd Fenster-basierende Blockadevermeidung für ein drahtloses Hochgeschwindigkeits-Kommunikationssystem
US7505412B2 (en) * 2002-12-27 2009-03-17 Ntt Docomo, Inc. Transmission control method and system
SE0301048D0 (sv) * 2003-04-07 2003-04-07 Ericsson Telefon Ab L M RLC window reconfiguration
CN1257621C (zh) * 2003-05-30 2006-05-24 中兴通讯股份有限公司 无线链路控制层中发送窗口调整的方法
JP4417733B2 (ja) * 2004-01-15 2010-02-17 ソニー・エリクソン・モバイルコミュニケーションズ株式会社 伝送方法及び装置
ATE505883T1 (de) * 2007-11-01 2011-04-15 Ericsson Telefon Ab L M Begrenzung der rlc-fenstergrösse in einer hsdpa- flusssteuerung
US8363550B1 (en) * 2010-06-15 2013-01-29 Google Inc. Adaptive data unit transmission and acknowledgment
CN102611537B (zh) * 2011-01-25 2015-09-09 华为技术有限公司 一种数据包的重传方法及装置
US9681326B2 (en) * 2012-09-28 2017-06-13 Intel Corporation Hybrid automatic repeat request (HARQ) mapping for carrier aggregation (CA)
KR101669777B1 (ko) * 2012-10-26 2016-10-26 인텔 코포레이션 사용자 플레인 혼잡의 리포트
US9271164B2 (en) * 2013-08-05 2016-02-23 Acer Incorporated Method of increasing data throughput of a wireless network system by dynamically adjusting MTU/fragmentation size according to current transmission status
CN107534896B (zh) * 2015-05-14 2021-09-14 有线电视实验室公司 对话前监听系统中的混合自动重传请求(harq)
CN106330412B (zh) * 2015-06-25 2019-05-21 辰芯科技有限公司 利用harq ack/nack的rlc pdu发送方法及装置
US10554566B2 (en) * 2015-09-14 2020-02-04 Lenovo Innovations Limited (Hong Kong) Contention window size adjustment in a wireless communication system
WO2017050363A1 (en) * 2015-09-23 2017-03-30 Sony Mobile Communications Inc Contention window adjustment in unlicensed cellular radio network
US10708000B2 (en) * 2015-10-20 2020-07-07 Apple Inc. Contention window size adaptation
US10624125B2 (en) * 2016-10-26 2020-04-14 Qualcomm Incorporated Techniques for semi-autonomously scheduling an uplink transmission in a shared radio frequency spectrum band
EP3533253B1 (en) * 2016-10-26 2021-08-18 Telefonaktiebolaget LM Ericsson (PUBL) 5g congestion control
CN108023758B (zh) * 2016-11-04 2020-06-02 华为技术有限公司 一种混合接入网络中处理报文的方法及网络设备
CN108282257A (zh) * 2017-01-06 2018-07-13 株式会社Ntt都科摩 用户终端、在其处的反馈方法、基站和在其处的方法
KR102397625B1 (ko) * 2017-02-13 2022-05-12 텔레폰악티에볼라겟엘엠에릭슨(펍) 무선 통신을 감시하기 위한 기술
US10686691B2 (en) * 2017-07-12 2020-06-16 The Board Of Trustees Of The University Of Alabama Intelligent high-speed unmanned vehicle communications via bio-inspired multi-beam pipe transmission
JP7018499B2 (ja) * 2017-08-11 2022-02-10 テレフオンアクチーボラゲット エルエム エリクソン（パブル） 自律アップリンク送信および再送信のための方法
CN115334689A (zh) * 2017-09-25 2022-11-11 华为技术有限公司 上行信道侦听的方法和装置
US10490059B2 (en) * 2017-12-15 2019-11-26 Comcast Cable Communications, Llc Priority-based wireless collision avoidance and interfering device response
CN111630932B (zh) * 2018-02-12 2023-09-15 Lg电子株式会社 在无线通信系统中调整竞争窗口大小的方法和使用该方法的通信装置
US10476808B1 (en) * 2018-03-07 2019-11-12 Sprint Spectrum L.P. Dynamic configuration of maximum transmission unit of UE, based on receipt of oversized packet(s) at network entity
US12057945B2 (en) * 2018-04-19 2024-08-06 Qualcomm Incorporated Repetition-based transmissions for uplink ultra-reliable low latency communication
CN112534910A (zh) * 2018-08-17 2021-03-19 Oppo广东移动通信有限公司 Harq信息的传输方法、网络设备和终端设备

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004222271A (ja) 2002-12-27 2004-08-05 Ntt Docomo Inc 伝送制御方法、通信装置、通信システム及びプログラム
US20110090793A1 (en) 2007-10-17 2011-04-21 Rudiger Halfmann Method and Device for Data Communication and Communication System Comprising Such Device
JP2011188429A (ja) 2010-03-11 2011-09-22 Kyocera Corp 無線通信装置

Also Published As

Publication number Publication date
US11973604B2 (en) 2024-04-30
EP3629505A1 (en) 2020-04-01
WO2020064310A1 (en) 2020-04-02
CN112313894B (zh) 2024-10-22
CN112313894A (zh) 2021-02-02
JP2022500885A (ja) 2022-01-04
US20210075547A1 (en) 2021-03-11
EP3857759A1 (en) 2021-08-04
EP3857759B1 (en) 2023-11-01

Similar Documents

Publication Publication Date Title
JP7446247B2 (ja) データの送信に関与するユーザ機器および基地局
TWI786269B (zh) 用於無線通訊的背壓訊號傳遞
JP6631961B2 (ja) スモールセル配備時の効率的な破棄メカニズム
RU2640397C2 (ru) Способ для сообщения неисправности повторной передачи управления радиолинии и устройство для этого
CN112075097A (zh) 在中继节点中处理数据的方法及其装置
EP3206321B1 (en) Improved uplink harq operation for prose-enabled ues participating in sidelink discovery operation
JP5671122B2 (ja) 無線通信システムの状態情報送信方法及び受信装置
JP5667285B2 (ja) リンク・セグメントについてのターゲット・パケット遅延を決定するための、また調整するための方法、装置およびノード
CN110574487A (zh) 分组数据汇聚协议(pdcp)实体处的分组重复
CN106489243B (zh) 远程通信设备和方法
US20170012745A1 (en) Method and apparatus for triggering acknowledgement status report in wireless communications system
JP2015233282A (ja) ｅＮＢ間キャリアアグリゲーション
WO2009035300A2 (en) Method of performing polling procedure in a wireless communication system
CN107534890B (zh) 适应性tti调整的方法以及用户设备
CN114650551A (zh) 降低多分支传输中分组延迟的方法和装置
WO2018058380A1 (zh) 一种数据传输方法、网络设备及终端设备
Nardini et al. Performance evaluation of TCP-based traffic over direct communications in LTE-Advanced
CN108650258B (zh) 窄带物联网无线链路协议子层am实体数据传输自适应方法
CN119278600A (zh) 发送控制协议确认整形
CN115209468A (zh) Iab网络中的用户装备第2层缓冲区操作
US20250080278A1 (en) Duplicate acknowledgment message reduction procedures
CN119096589A (zh) 通信方法和通信设备
BR112016001410B1 (pt) Estação base mestre configurada para encaminhar pacotes de dados destinados a uma estação móvel, estação de base secundária configurada para encaminhar pacotes de dados recebidos de uma estação base mestre e destinados a uma estação móvel para a estação móvel, método implementado em uma estação base mestre para encaminhar pacotes de dados destinados a uma estação móvel, e método implementado em uma estação base secundária para encaminhar pacotes de dados recebidos de uma estação base mestre e destinados a uma estação móvel para uma estação móvel

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220819

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20230718

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230815

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20231113

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240130

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240227

R150 Certificate of patent or registration of utility model

Ref document number: 7446247

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150