(57)【要約】  本開示は、送信ウィンドウサイズを有する送信ウィンドウに基づいて少なくとも１つのデータパケットを送信する送信機を有するユーザ機器（ＵＥ）に関する。前記ＵＥの受信機は、前記少なくとも１つの送信されたデータパケットに関する受信フィードバックを受信する。前記ＵＥの処理回路は、少なくとも前記受信された受信フィードバックに基づいて、少なくともさらなるデータパケットを送信するために使用される前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定する。【選択図】図１８
2022500885.tif 000002
【特許請求の範囲】
【請求項１】
動作中、送信ウィンドウサイズを有する送信ウィンドウに基づいて少なくとも１つのデータパケットを送信する送信機と、
動作中、前記少なくとも１つの送信されたデータパケットに関する受信フィードバックを受信する受信機と、
動作中、少なくとも前記受信された受信フィードバックに基づいて、少なくともさらなるデータパケットを送信するために使用される前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定する処理回路と、
を有するユーザ機器。
【請求項２】
前記送信機は、動作中、前記処理回路が前記送信ウィンドウサイズを変更すると決定した場合に、前記変更された送信ウィンドウサイズを有する前記送信ウィンドウに基づいて、さらなるデータパケットを送信する、
請求項１に記載のユーザ機器。
【請求項３】
前記少なくとも１つのデータパケットは、無線リンク経由で、前記ユーザ機器のサービング基地局である基地局に直接送信され、前記受信フィードバックは、前記基地局から受信される、
または、
前記少なくとも１つのデータパケットは、少なくとも２つのホップを有するデータトラフィックルートの第１の中間ノードに送信され、前記データトラフィックルートは、ソースノードとしての前記ユーザ機器と、宛先ノードとしての受信エンティティとをさらに有し、前記少なくとも１つのデータパケットは、前記ユーザ機器によって前記ユーザ機器の隣にある前記第１の中間ノードに送信され、前記第１の中間ノードによって前記宛先ノードに向けて転送される、
オプションとして、前記受信フィードバックは、前記第１の中間ノードから受信され、前記少なくとも１つのデータパケットが前記宛先ノードによって正しく受信されたか否かを示す、または、
オプションとして、前記受信フィードバックは、前記第１の中間ノードから受信され、前記少なくとも１つのデータパケットが前記第１の中間ノードによって正しく受信されたか否かを示す、
請求項１または２に記載のユーザ機器。
【請求項４】
前記処理回路は、前記送信ウィンドウサイズを変更するかどうかを決定する際に、
前記ユーザ機器によって以前送信された前記データパケットに対して決定された肯定的および／または否定的な応答確認に基づいて、前記送信ウィンドウサイズを大きくするかまたは小さくするかを決定する、
オプションとして、前記送信ウィンドウサイズは、最大送信ウィンドウサイズよりも大きくすることはできず、
オプションとして、前記送信ウィンドウサイズは、最小送信ウィンドウサイズよりも小さくすることはできない、
請求項１〜３の一項に記載のユーザ機器。
【請求項５】
前記処理回路は、前記送信ウィンドウサイズを大きくするかまたは小さくするかを決定する際に、
以下の場合に前記送信ウィンドウサイズを大きくすることを決定し、
−  多数の肯定応答が、前記ユーザ機器によって以前送信されたデータパケットに対する前記受信フィードバック内に受信され、前記多数の肯定応答は、連続したデータパケットに言及している、および／または
−  多数の肯定応答が、定義された期間内に受信されている、および／または、
−  送信されたデータパケットの数に対する肯定応答の割合が、しきい値を超えている、
以下の場合に前記送信ウィンドウサイズを小さくすることを決定する、
−  多数の否定応答が、前記ユーザ機器によって以前送信されたデータパケットに対する前記受信フィードバック内に受信され、前記多数の否定応答は、連続したデータパケットに言及している、および／または
−  多数の否定応答が、定義された期間内に受信されている、および／または、
−  送信されたデータパケットの数に対する否定応答の割合が、しきい値を超えている、
請求項４に記載のユーザ機器。
【請求項６】
前記送信ウィンドウは、どのデータパケットを送信するかを決定するために前記ユーザ機器によって使用され、
オプションとして、前記処理回路は、動作中、前記データパケットが前記送信ウィンドウの中のシーケンス番号に関連付けられている場合にはデータパケットを送信可能であると決定し、前記データパケットが前記送信ウィンドウの外のシーケンス番号に関連付けられている場合にはデータを送信不可であると決定する、
請求項１〜５の一項に記載のユーザ機器。
【請求項７】
前記受信機は、動作中、前記受信フィードバックに基づいて前記送信ウィンドウサイズを変更するメカニズムを開始するかどうかを前記ユーザ機器に設定するための設定メッセージを受信し、
オプションとして、前記設定メッセージは、前記ユーザ機器の前記サービング基地局から受信され、前記サービング基地局は、前記データトラフィックルートの前記宛先ノードである、
請求項３に記載のユーザ機器。
【請求項８】
前記受信フィードバックは、以前送信された少なくとも１つのデータパケットに対する肯定応答または否定応答を示す状態報告であり、
オプションとして、前記受信フィードバックは、自動再送要求（ＡＲＱ）（否定応答されたデータパケットの再送信に基づく送信誤り訂正を実施するために前記ユーザ機器と受信側との間で使用されるメカニズム）の一部として送信され、オプションとして、前記ＡＲＱメカニズムは、無線リンク制御（ＲＬＣ）レイヤの一部である、
請求項１〜７の一項に記載のユーザ機器。
【請求項９】
前記処理回路は、動作中、前記送信された少なくとも１つのデータパケットの各々に対して応答確認タイマを起動し、前記処理回路は、動作中、各データパケットに対する受信フィードバックを受信すると、前記応答確認タイマを停止し、
前記応答確認タイマが満了すると、前記処理回路は、動作中、各データパケットが受信側によって正しく受信されなかったと判定し、オプションとして、正しく受信されなかったと判定された各データパケットを再送信することを決定し、
オプションとして、各データパケットが正しく受信されなかったという判定は、前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定する際に、否定応答として使用される、
請求項１〜８の一項に記載のユーザ機器。
【請求項１０】
前記受信機は、動作中、前記ユーザ機器のサービング基地局から、前記応答確認タイマの値を設定するための情報を含む設定メッセージを受信し、
オプションとして、前記応答確認タイマの前記値は、ソースノードとしての前記ユーザ機器とデータトラフィックルートの宛先ノードとの間の前記データトラフィックルートのホップ数に比例し、
オプションとして、前記応答確認タイマの前記値は、前記ユーザ機器によって送信された前記少なくとも１つのデータパケットに関連付けられたサービス種別に依存する、
請求項９に記載のユーザ機器。
【請求項１１】
前記処理回路は、動作中、少なくとも１つのトリガ条件が、前記送信された少なくとも１つのデータパケットに対する前記受信フィードバックを送信させるために受信フィードバック要求の前記受信側への送信をトリガするかどうかを判定し、前記少なくとも１つのトリガ条件は、以下のうちの少なくとも１つを含み、
−  少なくともいくつかのデータパケットが前回の受信フィードバック要求の後に送信されていること、
−  少なくともいくつかのバイト数のデータが前回の受信フィードバック要求の後に送信されていること、
−  前回の受信フィードバック要求が送信された後の時間を示す受信フィードバック要求タイマの満了、
前記処理回路は、動作中、前記トリガ条件のうちの少なくとも１つが前記受信フィードバック要求の前記送信をトリガするかどうかを判定する際に、データパケットを送信するために前記ユーザ機器によって使用される前記送信ウィンドウサイズを考慮する、
請求項８〜１０の一項に記載のユーザ機器。
【請求項１２】
前記少なくとも１つのデータパケットは、少なくとも２つのホップを有するデータトラフィックルートの第１の中間ノードに送信され、前記データトラフィックルートは、ソースノードとしての前記ユーザ機器と、宛先ノードとしての受信エンティティとをさらに有し、
前記受信機は、動作中、以前送信されたデータパケットに対する前記受信フィードバックと共に輻輳情報を受信し、前記輻輳情報は、前記データトラフィックルートの前記第１の中間ノード、前記ソースノード、および前記宛先ノードのうちの少なくとも１つがデータ輻輳に遭っていることを示し、
前記処理回路は、動作中、一定期間データパケットの送信を減少させるよう前記送信機を制御し、
オプションとして、前記受信フィードバック内の前記輻輳情報は、１ビットであり、
オプションとして、前記輻輳情報は、応答確認の分布など、前記受信フィードバックのパターンから解釈される、
請求項１〜１１の一項に記載のユーザ機器。
【請求項１３】
ユーザ機器によって実行される以下のステップを有する方法であって、
送信ウィンドウサイズを有する送信ウィンドウに基づいて少なくとも１つのデータパケットを送信するステップと、
前記少なくとも１つの送信されたデータパケットに関する受信フィードバックを受信するステップと、
少なくとも前記受信された受信フィードバックに基づいて、少なくともさらなるデータパケットを送信するために使用される前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定するステップと、
を有する方法。
【請求項１４】
動作中、送信ウィンドウサイズを有する送信ウィンドウに基づいて少なくとも１つのデータパケットを送信する送信機と、
動作中、前記少なくとも１つの送信されたデータパケットに関する受信フィードバックを受信する受信機と、
動作中、少なくとも前記受信された受信フィードバックに基づいて、少なくともさらなるデータパケットを送信するために使用される前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定する処理回路と、
を有するサービング基地局。
【請求項１５】
前記サービング基地局は、ＩＡＢ（統合されたアクセス＆バックホール）ドナーであり、オプションとして、前記ＩＡＢドナーは、ユーザ機器が前記少なくとも１つのデータパケットの宛先ノードであり且つ少なくとも１つの中間ＩＡＢノードが存在するダウンリンクデータトラフィックルートにおけるソースノードである、
請求項１４に記載のサービング基地局。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、３ＧＰＰ通信システムなどの通信システムにおける方法、デバイス、および物品を対象とする。
【背景技術】
【０００２】
現在、第３世代パートナーシッププロジェクト（３ＧＰＰ）は、第５世代（５Ｇ）とも呼ばれる次世代セルラー技術の技術仕様に取り組んでいる。
【０００３】
１つの目的は、拡張モバイルブロードバンド（ｅＭＢＢ：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）（図５参照）として実装される受信フィードバックとを有する、そのＡＭデータ転送に対するＡＲＱ機能を提供する。
【０１２５】
ソリューションをＲＬＣ  ＡＭプロトコル機能に実装する場合、ＲＬＣ  ＡＭデータ転送は、固定サイズではなく、動的サイズ（ＡＭ＿ｗｉｎｄｏｗ＿ｓｉｚｅ）を有する送信ウィンドウを使用する。
【０１２６】
以下、１つの非常に具体的な例示的実装について説明する。最大ウィンドウサイズ（Ｍａｘ＿ＡＭ＿ｗｉｎｄｏｗ＿ｓｉｚｅ）および異なる初期ウィンドウサイズ（Ｉｎｉｔ＿ＡＭ＿ｗｉｎｄｏｗ＿ｓｉｚｅ）（例えば、非特許文献６の第９．２節を参照）：
Ｍａｘ＿ＡＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ：
この定数は、各ＡＭ  ＲＬＣエンティティの送信側と受信側の両方によって使用される。１２ビットＳＮが使用される場合、Ｍａｘ＿ＡＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ＝２０４８であり、１８ビットＳＮが使用される場合、Ｍａｘ＿ＡＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ＝１３１０７２である。
Ｉｎｉｔ＿ＡＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅ：
Ｉｎｉｔ＿ＡＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅは、Ｍａｘ＿ＡＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅの半分に等しい。
【０１２７】
2022500885.tif 000003
【０１２８】
2022500885.tif 000004
【０１２９】
受信側のＡＭデータ転送定義は、受信ウィンドウサイズとしてＭａｘ＿ＡＭ＿ｗｉｎｄｏｗ＿ｓｉｚｅを使用するように修正することができる。
【０１３０】
さらに、送信側から受信側への受信フィードバック要求の送信は、ＲＬＣレイヤに対して定義されたトリガされた条件のうちの１つに従ってトリガされたポーリングビットに基づいて実行することができる。上記したように、受信側からのＲＬＣ状態報告のポーリングは、ＰＤＵのポーリングビットを送信側から受信側に送信することを含むことができる。上記ソリューションのさらなるバリエーションによれば、受信側から状態報告をポーリングするためのトリガされた条件のいくつかは、適応された送信ウィンドウサイズに適応させることができる。これにより、送信ＡＲＱ側が以前送信されたＰＤＵの受信状態を合理的な時間で取得することができることを容易にすることができる。
【０１３１】
例えば、送信されたデータ量に基づくこれらのトリガは、送信ウィンドウサイズが送信可能なデータ量に強く影響することを考えると、適応された送信ウィンドウサイズに依存する。したがって、ユーザ機器は、これらのデータ量トリガ条件が満たされているかどうかを判定する際に、現在の送信ウィンドウサイズを考慮に入れることができる。
【０１３２】
例えば、ＵＥは、少なくとも多くのデータパケットまたはバイトが、最後のＲＬＣ状態報告がポーリングされた後に送信されたかどうかを判定し、それらのデータパケットの送信に使用された送信ウィンドウサイズに基づいて、データパケットおよびバイトの数を増減する。
【０１３３】
１つの特定の実施態様は、必要に応じてトリガ条件を拡大または縮小するためにスケーリングファクタを使用する。具体的には、スケーリングファクタは、例えば、最大送信ウィンドウサイズと使用される送信ウィンドウサイズとの間の関係を反映することができる。例えば、送信ウィンドウサイズの半分が使用された場合、ＲＬＣ状態報告をトリガする条件も半分にすることができ（例えば、データＰＤＵの半分および／またはバイトの半分）、また、その逆も同様である。
【０１３４】
同様に、ＲＬＣ状態報告をポーリングするさらなるトリガ条件は、最後のポーリングが送信された後の時間を制御するポーリング再送時間（Poll retransmit time）の満了である。このタイマを送信ウィンドウサイズに応じてスケーリングすることにより、送信ウィンドウサイズが小さい場合に、ポーリングをより頻繁に送信することができる。これは、ウィンドウストールの回避を容易にするという利点を有することができる、なぜなら、ＲＬＣ状態報告内の応答確認がより早く受信され、それに対応して送信ウィンドウをより早くスライドさせることができるからである。
【０１３５】
以上、トリガ条件の適応について、一般的に説明した。特定の実装において、それは、ＬＴＥフレームワークだけでなく既存および将来の５Ｇ  ＮＲフレームワークにも実装することができる。例えば、ソリューションは、５Ｇ  ＮＲに対して現在定義されているＲＬＣレイヤと組み合わせて実装することができる。
【０１３６】
例えば、新しいスケーリングファクタ定義を、既存の定義に追加することができる（非特許文献６の第７．４節を参照）：
ｄ）ｐｏｌｌＩＡＢＳｃａｌｅ
このパラメータは、パラメータｐｏｌｌＰＤＵおよびｐｏｌｌＢｙｔｅならびにｔ−ＰｏｌｌＲｅｔｒａｎｓｍｉｔを拡大または縮小するために、各ＡＭ  ＲＬＣエンティティの送信側によって使用される。
【０１３７】
それに対応して、トリガ条件の一部または全部を適応された送信ウィンドウサイズに適応させることによって、受信フィードバックのポーリング（要求）は、より適切になり、必要に応じて時間的に前後にシフトさせることができる。
【０１３８】
さらなる一連のバリエーションによれば、送信ノード（例えば、ＵＥ）は、以前送信されたデータパケットに対してタイマ（例えば、以下、応答確認タイマと呼ぶ）を制御することができる。例えば、ＵＥは、データパケットに対する肯定応答または否定応答を制御するために、送信されたデータパケットごとに１つのタイマを制御することができる。
【０１３９】
１つの例示的な実装において、送信ノード（例えば、ＵＥ）は、データパケットの送信時に１つの応答確認タイマを起動することができる。このタイマは、そのデータパケット（つまり、タイマを起動したデータパケット）の受信状態に関するフィードバックを受信すると、停止される。フィードバックは、例えば、ＲＬＣ状態報告内で受信された、肯定応答または否定応答とすることができる。
【０１４０】
データパケットに対してフィードバックが受信されない場合、対応する応答確認タイマは、やがて満了し、この場合、送信側は、各データパケットが受信側によって正しく受信されなかったと判定する。これに対応して、送信側は、そのデータパケットに対するＮＡＣＫを決定する。
【０１４１】
１つの例示的なバリエーションによれば、ＮＡＣＫは、受信側から受信された（例えば、ＲＬＣ状態報告内の）ＮＡＣＫと同様に送信側によって使用することができる。このような応答確認タイマから決定されたＮＡＣＫおよび受信側から受信されたＮＡＣＫは、送信ウィンドウサイズを変更するかどうかを決定するために、送信側によって使用することができる。特に、上記の条件のいくつかは、以前送信されたデータパケットに対して得られたＮＡＣＫの数に依存する。
【０１４２】
応答確認タイマおよびその時間値は、予め設定することができ、例えば、適切な構成メッセージを送信側（例えば、ＵＥ）に送信することによって、例えば、ネットワーク側によって設定することができる。１つの例において、応答確認タイマおよびその値は、ＲＲＣ再構成メッセージ、ＲＲＣセットアップメッセージ、またはＲＲＣ再確立メッセージの１つ以上を通じて設定することができる。
【０１４３】
他方、追加的または代替的に、応答確認タイマおよびその時間値は、ＳＩＭの一部として予め決定し、または３ＧＰＰ仕様の一部として定義することができる。
【０１４４】
ネットワーク側から設定されることによって容易になる１つの利点は、タイマの値を送信側（例えば、ＵＥ）と受信側（例えば、ＩＡＢドナー）との間のホップ数に適応させることができることである。特に、ルートが長いほど（例えば、ホップ数が多いほど）、応答確認タイマの値を長く設定することができ、逆に、ルートが短いほど（例えば、ホップ数が少ないほど）、応答確認タイマを短く設定することができる。
【０１４５】
１つのさらなる利点は、応答確認タイマの値を、データパケットに関連付けられるサービスタイプに適応させることができることである。サービスタイプは、例えば、ビデオ会議サービスやベストエフォートサービス（電子メール、ＦＴＰ）などであり、帯域幅およびレイテンシに関して一定の要件を課すことができる。例えば、サービスの優先順位が高いほど、より多くの帯域幅が必要になることを意味することができる。この場合、優先順位が高いほど、タイマの値を長く設定することができる。
【０１４６】
オプションとして、応答確認タイマが満了した際に送信側によって得られるＮＡＣＫを使用して、前記失われたデータパケットに対する送信側での再送信をトリガすることもできる。
【０１４７】
以上、新しい応答確認タイマメカニズムについて、一般的に説明した。特定の実装において、それは、ＬＴＥフレームワークだけでなく既存および将来の５Ｇ  ＮＲフレームワークにも実装することができる。例えば、ソリューションは、５Ｇ  ＮＲに対して現在定義されているＲＬＣレイヤと組み合わせて実装することができる。
【０１４８】
例えば、新しいタイマ定義を、既存の定義に追加することができる（非特許文献６の第７．３節を参照）：
ｄ）ｔ−ＩＡＢ＿ＮＡＣＫ
このタイマは、タイマ満了時にＮＡＣＫされているＰＤＵを決定するために、ＡＭ  ＲＬＣエンティティの送信側によって使用される。
【０１４９】
適応送信ウィンドウおよび応答確認タイマを使用する例示的なソリューションが、図２２に示されており、この図は、ＵＥ（送信側として）で実行されるプロセスのフロー図を示す。図１８のフロー図と比較すると、図２２は、送信ウィンドウサイズを増減する実装に言及している点、および、各データパケットに対して応答確認タイマを動作させ、それぞれの満了後にデータパケットに対する追加の否定応答を生成するのに使用される点で、より具体的である。その後、追加の否定応答は、送信ウィンドウサイズを大きくするか、小さくするか、または送信ウィンドウサイズを変更せずに維持するかの決定を行うのに使用することができる。
【０１５０】
図２２から明らかなように、ＵＳは、送信された各データパケットに対して応答確認タイマを起動することができ、タイマが停止されるか（例えば、ＡＣＫまたはＮＡＣＫなどの受信した受信フィードバックによって）または満了するかについてタイマを制御することができる。応答確認タイマが満了すると、ＵＥは、対応するデータパケット（タイマを起動した）を正常に送信することができなかったと判定し、そのデータパケットを否定応答（ＮＡＣＫ）すべきものと認める。
【０１５１】
このタイマ−ＮＡＣＫは、受信側から受信された受信フィードバックと共に使用して、送信ウィンドウを適応させることができる。この点に関して、送信ウィンドウサイズを適応させるかどうか、およびどのように適応させるかを決定するために、受信フィードバックに対して上記した条件のいずれかをチェックすることができる。その結果に応じて、送信ウィンドウサイズを大きくし、小さくし、または変更しない。いずれにせよ、ＵＥの手順は、送信ウィンドウ（大きくした、小さくした、または以前と同じサイズである）を使用してデータパケットの送信を続行する。
【０１５２】
以下、さらなるソリューションについて説明する。本発明者らによって認識された、ＨＢＨ  ＡＲＱ（例えば、ＩＡＢなどのマルチホップシナリオにおける）の１つの問題は、１つのホップにおけるＡＲＱ動作が別のホップにおけるＡＲＱ動作から分離されていることである。例えば、図８のＩＡＢノード２におけるダウンリンクでの輻輳を仮定した場合、ＤＵ側バッファは、ＵＥから多くのＮＡＣＫを受信するため、オーバーフローが始まるも、依然としてＩＡＢノード２のＭＴ側から受信ＰＤＵを受信する。ＩＡＢノード１はＩＡＢノード２のＭＴからＡＣＫのみを受信するため、ＩＡＢノード２とＩＡＢノード１との間のＡＲＱ動作は、正常に機能する。
【０１５３】
以下のソリューションは、ノードがデータパケットを送信しているか、データパケットを受信しているかに応じて、ホップの２つのノード（それぞれホップの送信ノードと受信ノード）の間で使用することができる。例えば、ダウンリンクの場合、ＵＥは、受信ノードであることができ、第１の中間ノードは、送信ノードであることができる。アップリンクの場合には、ＵＥは、送信ノードとなり、第１の中間ノードは、受信ノードとなる。このロジックは、他のホップ、例えば、２つの中間ノードを含むホップ、または、１つの中間ノードとＩＡＢノードを含むホップでも同様に適用可能である。以下の状況の議論および説明を容易にするために、輻輳がＵＥの後の第１の中間ノード（図８のＩ−ノード２）においてアップリンクで発生するという例示的なシナリオを仮定する。ＨＢＨ  ＡＲＱは、Ｉ−ノード２とＩ−ノード１の間で実行され、ＨＢＨ  ＡＲＱは、ＵＥとＩ−ノード２の間で実行される。このシナリオにおいて、Ｉ−ノード２は、輻輳情報をＵＥに提供する。
【０１５４】
しかし、ソリューションは、ＵＥとＩ−ノード２の間の第１のホップに関してそのようなアップリンクシナリオの文脈で説明されるが、当該ソリューションが、他のホップおよびダウンリンクシナリオにおいて同様に適用可能であることは、読者には明らかであろう。
【０１５５】
１つの例示的なソリューションは、仮定されたシナリオのＩ−ノード２のような中間ノードのＤＵ側およびＭＴ側のうちの内部シグナリングに基づく。上記のように、中間ノードの一方の側における輻輳の場合、中間ノードの他方の側は、入ってくるデータパケットの応答確認を続ける。したがって、輻輳が発生しているまたは発生するであろうことを他方の側に内部的に示すことによって、中間ノードの他方の側は、さらに入ってくる（例えば、ＵＥから）データパケットに対するＡＲＱフィードバックの送信を止めることができる。例えば、入ってくるデータパケットの応答確認の停止は、例えば、他の側によって内部的に示されるまたは予め設定された時間量に制限することができる。これに対応して、上流ノード（例えば、仮定されたシナリオのＵＥ、または、他のシナリオでは別の中間ノードもしくはＩＡＢドナー）は、さらなるデータパケットの送信を減らす、なぜなら、その上流ノードは、ホップの受信側からの肯定応答がなければその送信ウィンドウをスライドすることができないからである。これにより、このような暗黙的指示は、輻輳問題を解決または回避することができる。
【０１５６】
代替的または追加的ソリューションによれば、輻輳情報は、ホップの２つのノードの間で明示的に送信され、ホップバイホップＡＲＱを実行する場合、具体的に、輻輳が発生している中間ノード（例えば、中間ノード）から、データを送信するその上流ノード（例えば、仮定されたシナリオのＵＥ、または、他のシナリオでは別の中間ノードもしくはＩＡＢドナー）に送信される。
【０１５７】
この輻輳情報は、例えば、受信フィードバック（例えば、ＲＬＣ  ＡＲＱ情報）の一部として受信することができる。輻輳情報は、１ビットと短くあることができ、この場合、当該情報は、下流ノード（例えば、仮定されたシナリオのＩ−ノード２）の輻輳の有無を区別する。あるいは、輻輳情報は、数ビット長であることができ、この場合、当該情報は、輻輳についてより詳細な情報を提供することができる。例えば、輻輳情報は、次の下流ノードへの弱い無線リンクによる輻輳や、下流ノードによって提供される非常に限られたグラントによる輻輳など、輻輳のさまざまな理由を区別することができる。また、輻輳情報は、輻輳がどれくらい厳しいかを示すこともでき、これによって、輻輳情報を受信するノード（例えば、仮定されたシナリオのＵＥ）は、例えば、データ速度の低減量によって、適切に対応することができる。送信側（例えば、仮定されたシナリオのＵＥ）は、少なくとも一定の時間、ホップの受信側へのデータ送信の速度を低下させる。
【０１５８】
ソリューションのさらなるバリエーションにおいて、ホップの送信側（例えば、仮定されたシナリオのＵＥ）は、ホップの受信側から受信した受信フィードバック（例えば、ＡＣＫ；ＮＡＣＫ）に基づいて輻輳情報を分析する。例えば、肯定応答および／または否定応答の分布によって、送信側（例えば、ＵＥ）は、輻輳によるパケットロスと、無線干渉によるパケットロスとを区別することができる。例えば、送信されたデータパケットにある程度均一に分布している否定応答は、パケットロスが輻輳に起因することを示している可能性がある。一方、一連の連続したＮＡＣＫ（つまり、連続したシーケンス番号を指す）は、パケットロスが無線干渉に起因することを示している可能性がある。
【０１５９】
状況に応じて、ホップの送信側（例えば、ＵＥ）は、受信した輻輳情報に対して異なる対応をすることができる。例えば、パケットロスが主に下流ノードの輻輳に起因する場合、送信側（例えば、ＵＥ）は、送信ウィンドウサイズを縮小することができ、一方、パケットロスが主に無線干渉に起因する場合、送信側は、送信ウィンドウサイズを同じに保つことができる。
【０１６０】
さらなる例示的実装によれば、ＨＢＨ  ＡＲＱの場合、輻輳した中間ノードは、エンドノード（ＩＡＢドナー）によって与えられる情報を利用して、輻輳の影響を最小にするためにそのアグリゲーションポリシーを変更することができる。ＩＡＢドナーによって与えられた情報は、Ｆ１−ＡＰインタフェースを通して運ばれ、特定のサービスタイプのレイテンシがかなり増大したことを示す。その後、輻輳した中間ノードは、サービスタイプに基づいてデータベアラを集約することを決定することができ、特定のサービスタイプの集約されたベアラの送信にのみ焦点を当てる／優先順位を付ける。
【０１６１】
さらなる態様
【０１６２】
第１の態様によれば、ユーザ機器が提供され、当該ユーザ機器は、送信ウィンドウサイズを有する送信ウィンドウに基づいて少なくとも１つのデータパケットを送信する送信機を有する。前記ＵＥは、前記少なくとも１つの送信されたデータパケットに関する受信フィードバックを受信する受信機を有する。前記ＵＥは、少なくとも前記受信された受信フィードバックに基づいて、少なくともさらなるデータパケットを送信するために使用される前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定する処理回路を有する。
【０１６３】
第１の態様に加えて提供される第２の態様によれば、前記送信機は、前記処理回路が前記送信ウィンドウサイズを変更すると決定した場合に、前記変更された送信ウィンドウサイズを有する前記送信ウィンドウに基づいて、さらなるデータパケットを送信する。
【０１６４】
第１または第２の態様に加えて提供される第３の態様によれば、前記少なくとも１つのデータパケットは、無線リンク経由で、前記ユーザ機器のサービング基地局である基地局に直接送信され、前記受信フィードバックは、前記基地局から受信される。
【０１６５】
あるいは、前記少なくとも１つのデータパケットは、少なくとも２つのホップを有するデータトラフィックルートの第１の中間ノードに送信される。前記データトラフィックルートは、ソースノードとしての前記ユーザ機器と、宛先ノードとしての受信エンティティとをさらに有する。前記少なくとも１つのデータパケットは、前記ユーザ機器によって前記ユーザ機器の隣にある前記第１の中間ノードに送信され、前記第１の中間ノードによって前記宛先ノードに向けて転送される。１つのオプションの実装において、前記受信フィードバックは、前記第１の中間ノードから受信され、前記少なくとも１つのデータパケットが前記宛先ノードによって正しく受信されたか否かを示す、または、もう１つのオプションの実装において、前記受信フィードバックは、前記第１の中間ノードから受信され、前記少なくとも１つのデータパケットが前記第１の中間ノードによって正しく受信されたか否かを示す。
【０１６６】
第１〜第３の態様のいずれかに加えて提供される第４の態様によれば、前記処理回路は、前記送信ウィンドウサイズを変更するかどうかを決定する際に、前記ユーザ機器によって以前送信された前記データパケットに対して決定された肯定的および／または否定的な応答確認に基づいて、前記送信ウィンドウサイズを大きくするかまたは小さくするかを決定する。
【０１６７】
１つのオプションの実装において、前記送信ウィンドウサイズは、最大送信ウィンドウサイズよりも大きくすることはできず、また、１つのオプションの実装において、前記送信ウィンドウサイズは、最小送信ウィンドウサイズよりも小さくすることはできない。
【０１６８】
第４の態様に加えて提供される第５の態様によれば、前記処理回路は、前記送信ウィンドウサイズを大きくするかまたは小さくするかを決定する際に、
以下の場合に前記送信ウィンドウサイズを大きくすることを決定し、
−  多数の肯定応答が、前記ユーザ機器によって以前送信されたデータパケットに対する前記受信フィードバック内に受信され、前記多数の肯定応答は、連続したデータパケットに言及している、および／または
−  多数の肯定応答が、定義された期間内に受信されている、および／または、
−  送信されたデータパケットの数に対する肯定応答の割合が、しきい値を超えている、
以下の場合に前記送信ウィンドウサイズを小さくすることを決定する、
−  多数の否定応答が、前記ユーザ機器によって以前送信されたデータパケットに対する前記受信フィードバック内に受信され、前記多数の否定応答は、連続したデータパケットに言及している、および／または
−  多数の否定応答が、定義された期間内に受信されている、および／または、
−  送信されたデータパケットの数に対する否定応答の割合が、しきい値を超えている。
【０１６９】
第１〜第５の態様のいずれかに加えて提供される第６の態様によれば、前記送信ウィンドウは、どのデータパケットを送信するかを決定するために前記ユーザ機器によって使用される。オプションの実装において、前記処理回路は、前記データパケットが前記送信ウィンドウの中のシーケンス番号に関連付けられている場合にはデータパケットを送信可能であると決定し、前記データパケットが前記送信ウィンドウの外のシーケンス番号に関連付けられている場合にはデータを送信不可であると決定する。
【０１７０】
第１〜第６の態様のいずれかに加えて提供される第７の態様によれば、前記受信機は、前記受信フィードバックに基づいて前記送信ウィンドウサイズを変更するメカニズムを開始するかどうかを前記ユーザ機器に設定するための設定メッセージを受信する。オプションの実装において、前記設定メッセージは、前記ユーザ機器の前記サービング基地局から受信され、前記サービング基地局は、前記データトラフィックルートの前記宛先ノードである。
【０１７１】
第１〜第７の態様のいずれかに加えて提供される第８の態様によれば、前記受信フィードバックは、以前送信された少なくとも１つのデータパケットに対する肯定応答または否定応答を示す状態報告である。オプションの実装において、前記受信フィードバックは、自動再送要求（ＡＲＱ）（否定応答されたデータパケットの再送信に基づく送信誤り訂正を実施するために前記ユーザ機器と受信側との間で使用されるメカニズム）の一部として送信される。１つのオプションの実装において、前記ＡＲＱメカニズムは、無線リンク制御（ＲＬＣ）レイヤの一部である。
【０１７２】
第１〜第８の態様のいずれかに加えて提供される第９の態様によれば、前記処理回路は、前記送信された少なくとも１つのデータパケットの各々に対して応答確認タイマを起動する。前記処理回路は、各データパケットに対する受信フィードバックを受信すると、前記応答確認タイマを停止する。前記応答確認タイマが満了すると、前記処理回路は、各データパケットが受信側によって正しく受信されなかったと判定し、オプションとして、正しく受信されなかったと判定された各データパケットを再送信することを決定する。１つのオプションの実装において、各データパケットが正しく受信されなかったという判定は、前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定する際に、否定応答として使用される。
【０１７３】
第９の態様に加えて提供される第１０の態様によれば、前記受信機は、前記ユーザ機器のサービング基地局から、前記応答確認タイマの値を設定するための情報を含む設定メッセージを受信する。１つのオプションの実装において、前記応答確認タイマの前記値は、ソースノードとしての前記ユーザ機器とデータトラフィックルートの宛先ノードとの間の前記データトラフィックルートのホップ数に比例する。１つのオプションの実装において、前記応答確認タイマの前記値は、前記ユーザ機器によって送信された前記少なくとも１つのデータパケットに関連付けられたサービス種別に依存する。
【０１７４】
第１〜第１０の態様のいずれかに加えて提供される第１１の態様によれば、前記処理回路は、少なくとも１つのトリガ条件が、前記送信された少なくとも１つのデータパケットに対する前記受信フィードバックを送信させるために受信フィードバック要求の前記受信側への送信をトリガするかどうかを判定する。前記少なくとも１つのトリガ条件は、以下のうちの少なくとも１つを含む、
−  少なくともいくつかのデータパケットが前回の受信フィードバック要求の後に送信されていること、
−  少なくともいくつかのバイト数のデータが前回の受信フィードバック要求の後に送信されていること、
−  前回の受信フィードバック要求が送信された後の時間を示す受信フィードバック要求タイマの満了。
【０１７５】
前記処理回路は、前記トリガ条件のうちの少なくとも１つが前記受信フィードバック要求の前記送信をトリガするかどうかを判定する際に、データパケットを送信するために前記ユーザ機器によって使用される前記送信ウィンドウサイズを考慮する。
【０１７６】
第１〜第１１の態様のうちのいずれか１つに加えて第１２の態様によれば、前記少なくとも１つのデータパケットは、少なくとも２つのホップを有するデータトラフィックルートの第１の中間ノードに送信される。前記データトラフィックルートは、ソースノードとしての前記ユーザ機器と、宛先ノードとしての受信エンティティとをさらに有する。前記受信機は、以前送信されたデータパケットに対する前記受信フィードバックと共に輻輳情報を受信し、前記輻輳情報は、前記データトラフィックルートの前記第１の中間ノード、前記ソースノード、および前記宛先ノードのうちの少なくとも１つがデータ輻輳に遭っていることを示す。前記処理回路は、一定期間データパケットの送信を減少させるよう前記送信機を制御する。オプションの実装において、前記受信フィードバック内の前記輻輳情報は、１ビットである。前記輻輳情報は、応答確認の分布など、前記受信フィードバックのパターンから解釈される。
【０１７７】
第１３の態様によれば、前記ユーザ機器によって実行される以下のステップを有する方法が提供される。少なくとも１つのデータパケットが、送信ウィンドウサイズを有する送信ウィンドウに基づいて送信される。前記少なくとも１つの送信されたデータパケットに関する受信フィードバックが受信される。少なくとも前記受信された受信フィードバックに基づいて、少なくともさらなるデータパケットを送信するために使用される前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかが決定される。
【０１７８】
第１４の態様によれば、サービング基地局が提供される。前記サービング基地局の送信機は、送信ウィンドウサイズを有する送信ウィンドウに基づいて少なくとも１つのデータパケットを送信する。前記サービング基地局の受信機は、前記少なくとも１つの送信されたデータパケットに関する受信フィードバックを受信する。前記サービング基地局の処理回路は、少なくとも前記受信された受信フィードバックに基づいて、少なくともさらなるデータパケットを送信するために使用される前記送信ウィンドウの前記送信ウィンドウサイズを変更するかどうかを決定する。
【０１７９】
第１４の態様に加えて提供される第１５の態様によれば、前記サービング基地局は、ＩＡＢ（統合されたアクセス＆バックホール）ドナーであり、オプションとして、前記ＩＡＢドナーは、ユーザ機器が前記少なくとも１つのデータパケットの宛先ノードであり且つ少なくとも１つの中間ＩＡＢノードが存在するダウンリンクデータトラフィックルートにおけるソースノードである。
【０１８０】
本開示のハードウェアおよびソフトウェア実装
【０１８１】
本開示は、ソフトウェア、ハードウェア、またはハードウェアと連携したソフトウェアで実現することができる。上記各実施の形態の説明に用いた各機能ブロックは、部分的または全体的に、集積回路などのＬＳＩによって実現可能であり、また、各実施形態で説明した各処理は、部分的または全体的に、同じＬＳＩまたはＬＳＩの組み合わせによって制御されてもよい。ＬＳＩは、チップとして個別に形成されてもよいし、または、機能ブロックの一部または全部を含むように１つのチップが形成されてもよい。ＬＳＩは、データ入力とこれに接続されたデータ出力を含んでもよい。ここで、ＬＳＩは、集積度の違いにより、ＩＣ（integrated circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることがある。しかし、集積回路を実現する技術は、ＬＳＩに限られるものではなく、専用回路、汎用プロセッサ、または専用プロセッサを用いて実現されてもよい。また、ＬＳＩ製造後にプログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）、または、ＬＳＩ内部に配置された回路セルの接続および設定を再構成可能なリコンフィギャラブル・プロセッサを使用してもよい。本開示は、デジタル処理またはアナログ処理として実現することができる。半導体技術または他の派生技術の進歩の結果として将来の集積回路技術がＬＳＩに取って代わる場合には、その将来の集積回路技術を用いて機能ブロックを集積化することができる。バイオテクノロジーも適用可能である。
【０１８２】
また、さまざまな実施形態は、プロセッサによって実行されるソフトウェアモジュールによって実装することもでき、または、ハードウェアに直接実装することもできる。また、ソフトウェアモジュールとハードウェア実装の組み合わせも可能である。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体、例えば、ＲＡＭやＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに格納することができる。さらに、異なる実施形態の個々の特徴は、個別にまたは任意の組み合わせで、別の実施形態の主題となることができることに留意されたい。
【０１８３】
当業者であれば、具体的な実施形態に示される本開示に対して多数の変更および／または修正を行うことができることを理解するであろう。したがって、本実施形態は、すべての点で例示であり、限定ではないと考えられるべきである。
【図１】
2022500885.tif 000005
【図２】
2022500885.tif 000006
【図３】
2022500885.tif 000007
【図４】
2022500885.tif 000008
【図５】
2022500885.tif 000009
【図６】
2022500885.tif 000010
【図７】
2022500885.tif 000011
【図８】
2022500885.tif 000012
【図９】
2022500885.tif 000013
【図１０】
2022500885.tif 000014
【図１１】
2022500885.tif 000015
【図１２】
2022500885.tif 000016
【図１３】
2022500885.tif 000017
【図１４】
2022500885.tif 000018
【図１５】
2022500885.tif 000019
【図１６】
2022500885.tif 000020
【図１７】
2022500885.tif 000021
【図１８】
2022500885.tif 000022
【図１９】
2022500885.tif 000023
【図２０】
2022500885.tif 000024
【図２１】
2022500885.tif 000025
【図２２】
2022500885.tif 000026
【国際調査報告】
2022500885.tif 000027
2022500885.tif 000028
2022500885.tif 000029