(57)【特許請求の範囲】
【請求項１】
データユニット（ＤＵ）を送信するための無線リンク制御（ＲＬＣ）通信パスを監視する方法であって、前記方法は、
前記ＲＬＣ通信パスで送信された１つ以上の未確認のＤＵに対するタイマーに基づいて、前記ＲＬＣ通信パスの低下を決定する工程を含む、またはトリガーし、
前記タイマーは、前記ＲＬＣ通信パスで送信された前記未確認のＤＵの中で最も古いＤＵに対する確認応答を受信すると、再起動され、前記タイマーを再起動することは、前記送信され未確認のＤＵの中で２番目に古いＤＵを送信してから経過した時間に従って前記タイマーを起動することを含む、方法。
【請求項２】
請求項１に記載の方法であって、前記タイマーは、前記ＲＬＣ通信パスでの前記１つ以上の未確認のＤＵの最も早い送信、または前記ＲＬＣ通信パスで送信された前記未確認のＤＵの中で最も古いＤＵの送信、からの経過時間を示す、方法。
【請求項３】
請求項１または２に記載の方法であって、前記タイマーは、前記ＲＬＣ通信パスで送信された前記未確認のＤＵの中で最も古いＤＵが未確認である限り、維持される、方法。
【請求項４】
請求項１から３のいずれか１項に記載の方法であって、前記低下は、前記タイマーの少なくとも１つの期間が経過すると決定される、方法。
【請求項５】
請求項１から４のいずれか１項に記載の方法であって、前記１つ以上のＤＵの送信を回復するための測定は、前記タイマーの少なくとも１つの期間が経過するとトリガーされる、方法。
【請求項６】
請求項１から５のいずれか１項に記載の方法であって、前記低下を決定することは、通信プロトコルスタックの上位レイヤまたは下位レイヤに前記低下を示すことを含む、方法。
【請求項７】
請求項１から６のいずれか１項に記載の方法であって、前記低下を決定することは、前記タイマーの第１の期間が経過すると、無線リンク障害（ＲＬＦ）を決定する、または示すことを含む、方法。
【請求項８】
請求項１から７のいずれか１項に記載の方法であって、前記低下を決定することは、前記タイマーの少なくとも１つの第２の期間が経過すると、
前記ＲＬＣ通信パスにおけるＤＵの送信を削減または中断すること、 
スケジューリング要求またはスケジューリング割り当ての送信のレートを削減または当該送信を中断すること、
バッファステータスレポートの送信のレートを削減または当該送信を中断すること、 
前記ＲＬＣ通信パスにより使用される物理チャネルに対するチャネル品質インジケータを削減すること、および、
前記ＲＬＣ通信パスから別のＲＬＣ通信パスへ切り替えること、
の少なくともいずれかを含む、方法。
【請求項９】
データユニット（ＤＵ）を受信するための無線リンク制御（ＲＬＣ）通信パスを監視する方法であって、前記方法は、
前記ＲＬＣ通信パスで受信される１つ以上の未処理のＤＵに対するタイマーに基づいて、前記ＲＬＣ通信パスの低下を決定する工程を含む、またはトリガーし、
受信される各ＤＵは、シーケンス番号ＳＮを含むかまたは関連付けられ、前記１つ以上の未処理のＤＵのＳＮは、前記ＲＬＣ通信パスで受信された少なくとも１つのＤＵのＳＮよりも小さく、
前記タイマーは、前記ＲＬＣ通信パスで受信される前記未処理のＤＵの中で最も古いＤＵを受信すると、再起動され、前記タイマーを再起動することは、前記未処理のＤＵの中で２番目に古いＤＵに気づいてから経過した時間に従って前記タイマーを起動することを含む、方法。
【請求項１０】
請求項９に記載の方法であって、前記タイマーは、ＳＮが前記ＲＬＣ通信パスで順番に受信されたＤＵとのギャップを有する少なくとも１つのＤＵを受信すると起動される、方法。
【請求項１１】
請求項１から１０のいずれか１項に記載の方法であって、前記低下を決定することは、前記タイマーの少なくとも３分の１期間が経過すると、
スケジューリング許可の送信のレートを削減または当該送信を中断すること、
前記ＲＬＣ通信パスにより使用される物理チャネルに対するチャネル品質インジケータを削減すること、および、
前記ＲＬＣ通信パスから別のＲＬＣ信パスへ切り替えること、
の少なくともいずれかを含む、方法。
【請求項１２】
請求項１から１１のいずれか１項に記載の工程を実行するためのプログラムコード部分を含む、コンピュータプログラム。
【請求項１３】
データユニット（ＤＵ）を送信するための無線リンク制御（ＲＬＣ）通信パスを監視するためのデバイスであって、前記デバイスは、
前記ＲＬＣ通信パスで送信された１つ以上の未確認のＤＵに対するタイマーに基づいて、前記ＲＬＣ通信パスの低下を決定する工程を実行するように構成され、
前記タイマーは、前記ＲＬＣ通信パスで送信された前記未確認のＤＵの中で最も古いＤＵに対する確認応答を受信すると、再起動され、前記タイマーを再起動することは、前記送信され未確認のＤＵの中で２番目に古いＤＵを送信してから経過した時間に従って前記タイマーを起動することを含む、デバイス。
【請求項１４】
請求項１３に記載のデバイスであって、請求項１から８と請求項１１のいずれか１項に記載の工程を実行するように構成される、デバイス。
【請求項１５】
データユニット（ＤＵ）を受信するための無線リンク制御（ＲＬＣ）通信パスを監視するためのデバイスであって、前記デバイスは、
前記ＲＬＣ通信パスで受信される１つ以上の未処理のＤＵに対するタイマーに基づいて、前記ＲＬＣ通信パスの低下を決定する工程を実行するように構成され、
受信される各ＤＵは、シーケンス番号ＳＮを含むかまたは関連付けられ、前記１つ以上の未処理のＤＵのＳＮは、前記ＲＬＣ通信パスで受信された少なくとも１つのＤＵのＳＮよりも小さく、
前記タイマーは、前記ＲＬＣ通信パスで受信される前記未処理のＤＵの中で最も古いＤＵを受信すると、再起動され、前記タイマーを再起動することは、前記未処理のＤＵの中で２番目に古いＤＵに気づいてから経過した時間に従って前記タイマーを起動することを含む、デバイス。 
【請求項１６】
請求項１５に記載のデバイスであって、請求項９から１１のいずれか１項に記載の工程を実行するように構成される、デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は一般に、無線通信を監視するための技術に関する。より具体的には、無線リンク制御通信パスを監視するための方法とデバイスが提供される。
【背景技術】
【０００２】
無線通信は、例えば、第３世代パートナーシッププロジェクト（３ＧＰＰ）で規定されたロングタームエヴォリューション（ＬＴＥ）によると、無線リンク制御（ＲＬＣ）確認応答（アクノレッジ）モード（ＡＭ）プロトコルを使用して、自動再送要求（ＡＲＱ）の手段によりパケットデータユニット（ＰＤＵ）を確実に配信する。送信側は、各ＲＬＣ ＰＤＵに関連付けられたＲＬＣシーケンス番号（ＳＮ）を使用してＲＬＣ ＰＤＵを送信し、ＲＬＣ ＰＤＵが正常に受信されたことを確認するためのステータスレポートを受信側にポーリングする。送信側のＡＭ ＲＬＣエンティティは、確認応答モードデータ（ＡＭＤ）ＰＤＵまたはＡＭＤＰＤＵの一部に対するピアＡＭ ＲＬＣ受信エンティティによる受信失敗の通知として、ステータスレポートで明示的な否定応答（ＮＡＣＫ）を受信でき、例えば、ＮＡＣＫが報告されたＲＬＣ  ＳＮを持つＰＤＵの再送をトリガーする。例えば、送信側が受信側からのステータスレポートを待機してタイムアウトし、受信側をポーリングする必要があるが、ポーリングリクエストを送信するための新しいデータがない場合など、再送に対して暗黙的なトリガーもある。
【０００３】
ＡＭＤ ＰＤＵまたはその一部が再送される場合、ＬＴＥのＲＬＣプロトコルでは、送信側が各ＳＮに関連付けて１つのReTx_count状態変数を維持する必要がある。ReTx_count状態変数は、対応するＲＬＣ ＳＮを持つＲＬＣ ＰＤＵが再送されるたびにインクリメントされる。任意のＲＬＣ ＳＮに対するReTx_countが、正常な受信の確認応答（ＡＣＫ）を受信せずに再送のmaxReTx_Threshold数に達すると、無線リンク障害（ＲＬＦ）宣言が上位レイヤに示される。
【０００４】
３ＧＰＰによるNew Radio（ＮＲ）では、ＲＬＣレイヤはＬＴＥと同様に機能する。違いの１つは、ＮＲでは、ＲＬＣレイヤではなく媒体アクセス制御（ＭＡＣ）レイヤが上位レイヤデータを連結することである。より具体的には、ＮＲのＭＡＣレイヤは、同じ論理チャネルからの複数のサービスデータユニット（ＭＡＣ ＳＤＵ）を多重化する。したがって、ＮＲ ＲＬＣからのＡＭＣ ＰＤＵには、完全なＲＬＣ ＳＤＵ（パケットデータ収束プロトコルデータユニットまたはＰＤＣＰ ＰＤＵ等）が１つだけ含まれているか、ＲＬＣ ＳＤＵの１つのセグメント（ＰＤＣＰ ＰＤＵのセグメント等）が含まれている。ＮＲのReTx_countの詳細は、３ＧＰＰでまだ決定されていない。
【０００５】
ＲＬＣ ＳＮごとにReTx_countを追跡する既存のＲＬＣ ＡＭの問題の１つは、何らかの無線リンクの問題がある可能性があることを検出するメカニズムを提供するだけで、メタデータの量と関連する処理コストに関して大きなメモリ負荷を課すことである。特にＲＮでは、連結がＲＬＣレイヤから削除され、ＬＴＥと比較してはるかに高いデータレートであるため、ＲＬＣ ＳＮサイズは、ＬＴＥの１０ビットのＲＬＣ ＳＮサイズと比較して、例えば１８ビットに増やす必要がある。このような大きなＲＬＣ ＳＮスペースを使用して、送信されたＲＬＣ ＳＮごとにReTx_countを維持し、ＳＮレートをはるかに高くすると、メモリ要件にかなりの負担がかかり、処理の負荷とメモリアクセス数が増加する。
【０００６】
ReTx_countの目的は、データユニット（ＤＵ）の再送回数を追跡し、再送を継続するためにそれを限度（maxReTx_Threshold）と比較することである。限度を超えると、通知（ＲＬＦ）が上位レイヤに示される。
【０００７】
ただし、このメカニズムは、再送に必要な時間の制御を意味するものではない。エンドツーエンドサービスの観点から、送信側が特定の期間内にＳＮの全てのセグメントのＡＣＫを受信しなかった場合、結果は、ＤＵの配信または受信の確認に失敗する原因となる詳細に関係なく同じである。通常、エンドツーエンドサービスへの結果は、上位レイヤのパケットまたはメッセージを配信できない期間に基づいており、ＲＬＣプロトコルの低レベルの詳細に依存しない。
【０００８】
最初のＭＡＣハイブリッドＡＲＱ（ＨＡＲＱ）失敗からＲＬＦが示されるまでの実際の時間は、大きく異なる場合がある。ＲＬＦ指示のための時間は、t-PollRetransmitやmaxReTx_ThresholdなどのＲＬＣパラメーターの設定だけに依存しない。また、ＲＬＣが制御できない他の状況も影響を与える可能性がある。システムにおける負荷と、間欠受信（ＤＲＸ）といったユーザ装置（ＵＥ）におけるその他の設定は、再送が行われるときに影響し得る。また、エンドツーエンドのサービスの観点からは、送信の問題の原因は重要ではなく、重要なのは、上位レイヤのパケットまたはメッセージを配信できない時間だけである。
【０００９】
再送の最大数に基づいたＲＬＦ検出の従来のメカニズムも非効率的である。それは、ＲＬＦをトリガーするためには多くのスケジューリングの試行が必要だからである。ＬＴＥでは、アップリンク方向のＵＥの一般的な構成では、maxReTx_Thresholdを３２に設定する。これは、無線インターフェイスによって正常に配信されない少なくとも３２回のスケジューリング試行が必要であることを意味する。さらに悪いことに、異なる再送の試行に対して異なるＰＤＵがスケジュールされている場合、さらに多くの試行が必要になる場合がある。これは、無線状態が、ＲＬＦが他の手段によって検出されないようなものである場合、無線アクセスネットワークがＵＥに関して無線状態が非常に悪いことを知っていても、ＵＥに多くのスケジューリング要求を許可する必要があるため、ＲＬＦをトリガーするためにかなりの無駄なリソースが必要になることを意味する。ＬＴＥでは、無線アクセスネットワークは通常、非常に悪い無線状態にある場合でもＵＥのスケジュールを継続し、必要に応じて最大数のＲＬＣ再送に対してＲＬＦをトリガーすることが重要であるため、スケジューリング要求が失敗する可能性がある。
【発明の概要】
【００１０】
したがって、メモリリソースおよび／または処理負荷の点で効率的な無線リンク制御技術が必要である。代替的または追加的に、無線の問題が検出されるまでの時間を制御できる技術が必要である。代替的または追加的に、無線リソースの無駄なスケジューリングを回避する技術が必要である。
【００１１】
一態様に関して、データユニット（ＤＵ）を送信するための無線リンク制御（ＲＬＣ）通信パスを監視する方法が提供される。方法は、ＲＬＣ通信パスで送信された１つ以上の未確認のＤＵに対するタイマーに基づいて、ＲＬＣ通信パスの低下（下落／減衰／落ち込み）を決定する工程を含む。
【００１２】
ここで、確認応答（ＡＣＫ）は、特に否定的なＡＣＫまたはＮＡＣＫなどによって他に述べられていない場合、肯定的なＡＣＫを指し得る。「未確認（認識されていない）」とは、ＡＣＫの不在または未処理のＡＣＫの状態を含み得る。ＡＣＫは、明示的（例：フィードバック内）または暗黙的であり得る。ＤＵは、対応するＤＵへの応答（データ応答またはシグナリング応答等）によって暗黙的に確認され得る。
【００１３】
この技術は、ＲＬＣ通信パスの低下、例えばベアラ障害または無線リンク障害（ＲＬＦ）状態またはその前兆を決定（判定）するために、例えばＲＬＣ  ＡＲＱメカニズムによって追跡する必要があるメモリの量（例えば、メタデータまたは状態変数に対して）を削減することができる。当該決定は、（例えば、ＲＬＣレイヤ以外またはＲＬＣレイヤ内のプロトコルスタックのレイヤに）当該低下を示すことによって、および／またはタイマーに基づいてＲＬＣ通信パスの使用（例えば、スケジューリング）を制御することによって実装され得る。例えば、タイマーに基づいて、無線リンク障害が管理される。
【００１４】
この技術では、タイマーに基づいて再送の期間を制御することができる。この技術は、低下の経時に基づく決定（例えば、指示および／または反作用）のために実装され得る。この技術は、送信ウィンドウのストール（停止状態、こう着状態）の発生を防止または削減し得る。
【００１５】
この技術は5G New Radio（ＮＲ）のＲＬＣプロトコルで実装され得るが、この技術は5G NRに限定されない。むしろ、この技術はあらゆる無線技術、例えば３ＧＰＰに準拠したＬＴＥまたはＩＥＥＥ８０２．１１に準拠したＷｉ−Ｆｉに適用することができる。
【００１６】
タイマーに基づいて、この技術は、ＲＬＣ通信パスの低下、例えば送信の問題を検出することができる。当該低下は、（ａ）いくつかのＤＵの正しい転送の失敗、または例えば劣悪な無線状態により受信機によるＤＵの受信の失敗、（ｂ）例えば劣悪な無線状態によるステータスレポートの受信の失敗、（ｃ）高負荷といった他の理由によるＤＵまたはステータスレポートの長時間のスケジュールの失敗、のうちの少なくとも１つにより発生し得る。
【００１７】
この技術は、適時にかつ効率的に、例えば、低下の詳細な原因とは無関係に決定できる。ReTx_countといった再送カウンタは、ＲＬＦがトリガーされるまでの時間が大きく異なる場合があるため、上記のケース（ａ）における再送の期間を制御するには十分ではない。ステータスレポートを要求するためのポーリングが同じＳＮを使用して送信局によって送信される場合、ケース（ｂ）は処理され得る（これは、送信する新しいデータがない場合、新しいデータ、３ＧＰＰに従って状態変数（VT(S)）により示されるＳＮでポーリングを送信する従来のシステムの場合ではない）。ケース（ｃ）は、従来のシステムではまったく処理されない。この技術は、上記のケースのいずれかにおける低下を決定するために実装することができる。
【００１８】
方法は、送信局、例えば、無線アクセスネットワーク（ＲＡＮ）のノード、またはＲＡＮと通信するＵＥによって実行され得る。方法は、ＲＬＣ通信パスの送信側で実行され得る。
【００１９】
方法は、送信ウィンドウ（例えばＲＬＣ送信ウィンドウ）の下端について第１の状態変数（例えば３ＧＰＰによるVT(A)）を監視する工程を含む、またはトリガーすることを含み得る。タイマーは、最も古い未確認のＤＵが送信されてから経過した時間、第１の状態変数が更新されてから経過した時間、および／または送信ウィンドウが進められてから経過した時間を監視し得る。
【００２０】
タイマーに基づいて低下を決定することは、タイマーが閾値を超えたときに減少（無線リンクの問題など）を示すこと、ＲＬＦへの適切なアクション、ＤＵを第１のＲＬＣ通信パスから第２のＲＬＣ通信パスに転送すること、によって実装および／またはトリガーされ得る。代替的または追加的に、タイマーに基づいて低下を決定することは、制御メッセージをＲＬＣ通信ピアエンティティに送信することによって実装および／またはトリガーされ得る。
【００２１】
未確認のＤＵは、（例えば、対応するＤＵの送信側で）確認応答が受信されていないＤＵを含み得る。ＲＬＣ通信パスで送信されたＤＵは、送信されたＤＵと簡単に呼ばれ得る。ＲＬＣ通信パスで送信された未確認のＤＵは、送信され未確認のＤＵと呼ばれ得る。ＲＬＣ通信パスで送信された未確認のＤＵは、未確認のＤＵまたは空中（送信中）にある（in flight）ＤＵと呼ばれ得る。
【００２２】
方法は、確認応答モードにおいてＲＬＣ通信パスで１つ以上のＤＵを送信する工程と、１つ以上のＤＵを送信すると、タイマーを開始する工程のうちの少なくとも１つを更に含む、またはトリガーし得る。タイマーは、ＲＬＣ通信パスで以前に送信された全てのＤＵが確認された場合に、１つ以上のＤＵを送信すると起動され得る。
【００２３】
ここでは、タイマーを起動する（initiate）ことは、タイマーを開始する（start）こととも呼ばれ得る。タイマーは、タイマー（例えば、タイマーによって示される時間または期間）をゼロに設定することで起動し得る。
【００２４】
タイマーは、１つ以上のより古いＤＵが未確認の場合、維持され得る。タイマーは、１つ以上の送信されたＤＵの少なくとも１つが未確認である限り、維持され得る。
【００２５】
タイマーを維持することは、タイマーを実行することとも呼ばれ得る。タイマーを維持することは、タイマーの初期時間（または開始時間）に対応するタイムスタンプを保存することにより実装され得る。タイマーによって示される時間または期間は、現在の時間と保存されているタイムスタンプとの差によって評価され得る。代替的または追加的に、タイマーを維持することは、タイマーによって示される時間または期間を定期的にインクリメントすることによって実装され得る。
【００２６】
タイマーは、ＲＬＣ通信パスで送信された１つ以上の未確認のＤＵに対する確認応答を受信すると、停止および／または再起動され得る（停止と再起動の少なくとも一方が行われ得る）。ＤＵは、ＲＬＣ通信パスにおいてバーストで送信され得る。前のバーストで送信された全てのＤＵが確認された後、後続のバーストが送信され得る。
【００２７】
ここでは、タイマーを再起動する（reinitiate）ことは、タイマーを再開する（restart）こととも呼ばれ得る。タイマーは、タイマー（例えば、タイマーによって示される時間または期間）をゼロに設定することで再起動され得る。
【００２８】
タイマーは、ＲＬＣ通信パスでの１つ以上の未確認のＤＵの最も早い送信、または、ＲＬＣ通信パスで送信された未確認のＤＵの中で最も古いＤＵの送信、からの経過時間を示し得る。最も古いＤＵの送信は、例えば最も古いＤＵの再送を含まない、最も古いＤＵの最初の（第１の）送信に関連し得る。
【００２９】
ＲＬＣ通信パスで送信された未確認のＤＵの中で「最も古い」ＤＵは、ＲＬＣ通信パスで送信された未確認のＤＵの中で最も早い送信におけるＤＵであり得る。
【００３０】
送信されたＤＵのそれぞれは、シーケンス番号（ＳＮ）を含む、および／または、関連付けられ得る。送信された各ＤＵは、異なるＳＮまたは一意のＳＮを含む、または、関連付けられ得る。ＳＮは、ＤＵのヘッダーまたはＤＵに付加されたヘッダに含まれ得る。ＤＵは、ＳＮに従って順番に送信され得る。
【００３１】
ＲＬＣ通信パスで送信された未確認のＤＵの中で最も古いＤＵは、ＲＬＣ通信パスで送信された未確認のＤＵの中で最小のＳＮを含む、または、関連付けられ得る。ＲＬＣ通信パスで送信された未確認のＤＵの中で最も古のＤＵのＳＮは、ＲＬＣ通信パスで送信された未確認のＤＵの最小のＳＮであり得る。
【００３２】
方法は更に、ＲＬＣ通信パスでの未確認のＤＵの最も早い送信のＳＮ、またはＲＬＣ通信パスで送信された未確認のＤＵの中の最も古いＤＵのＳＮを示す第１の状態変数を維持することを含むまたはトリガーすることを含み得る。第１の状態変数は、VT_AまたはVT(A)と称され得る。第１の状態変数は、技術仕様ＴＳ  ３６．３２２（例えば３ＧＰＰ文書  ＴＳ  ３６．３２２  Ｖ１３．２．０，５．１．３節と７．１節）に従って実装され得る。
【００３３】
タイマーは、第１の状態変数が変更されない限り維持され得る。代替的にまたは追加的に、タイマーは、送信ウィンドウが変更されない限り維持され得る。
【００３４】
第１の状態変数を維持することは、第１の状態変数によって示されるＳＮを含むまたは当該ＳＮに関連付けられるＤＵに対する確認応答を受信すると、第１の状態変数を進めることを含み得る。第１の状態変数を進めることは、第１の状態変数をインクリメントすることを含み得る。例えば、第１の状態変数は、ＲＬＣ通信パスで送信された未確認のＤＵの中で２番目に古いＤＵにシフトされ得る。
【００３５】
代替的にまたは追加的に、送信ウィンドウは維持され得る。送信ウィンドウは、送信され未確認のＤＵのＳＮを含み得る。送信ウィンドウは更に、送信されるＤＵ、例えば送信バッファに格納されたＤＵのＳＮを含み得る。送信ウィンドウに含まれるＳＮは、第１の状態変数以上である場合がある。すなわち、第１の状態変数は、送信ウィンドウの下端を示し得る。送信ウィンドウは、第１の状態変数によって示されたＳＮを含むまたはそれに関連付けられたＤＵに対する確認応答を受信すると、進められ得る。送信ウィンドウの上端は、第１の状態変数に送信ウィンドウの（例えば、事前定義された）サイズを加えたものに等しくてもよい。
【００３６】
タイマーは、第１の状態変数によって示されるＳＮを含むまたは当該ＳＮに関連付けられたＤＵに対する確認応答を受信するか、第１の状態変数を進めると、停止および／または再起動され得る（停止と再起動の少なくとも一方が行われ得る）。代替的にまたは追加的に、タイマーは、送信ウィンドウを進めると、停止および／または再起動され得る。
【００３７】
方法は更に、次に送信されるＤＵのＳＮを示す第２の状態変数を維持する工程を含む、またはトリガーし得る。第２の状態変数は、VT_SまたはVT(S)と称され得る。第２の状態変数は、技術仕様ＴＳ  ３６．３２２（例えば３ＧＰＰ文書  ＴＳ  ３６．３２２  Ｖ１３．２．０，５．１．３節と７．１節）に従って実装され得る。
【００３８】
第２の状態変数を維持することは、次のＤＵを送信すると第２の状態変数を進めることを含み得る。第２の状態変数を進めることは、第２の状態変数をインクリメントすることを含み得る。例えば、第２の状態変数は、送信される２番目に次のＤＵにシフトされ得る。
【００３９】
代替的にまたは追加的に、フィードバックウィンドウは維持され得る。フィードバックウィンドウは、ステータス（状態）ウィンドウとも称され得る。フィードバックウィンドウは、送信され未確認のＤＵのＳＮを含み得る。フィードバックウィンドウに含まれるＳＮは、第１の状態変数以上である場合がある。すなわち、第１の状態変数は、フィードバックウィンドウの下端を示し得る。代替的にまたは追加的に、フィードバックウィンドウに含まれるＳＮは、第２の状態変数より小さい場合がある。すなわち、第２の状態変数より１少ない値は、フィードバックウィンドウの上端を示し得る。
【００４０】
タイマーは、フィードバックウィンドウが変更されない限り維持され得る。代替的にまたは追加的に、タイマーは、フィードバックウィンドウを進めると、停止および／または再開され得る（停止と再起動の少なくとも一方が行われ得る）。
【００４１】
ＲＬＣ通信パスは、無線ベアラに一意的に関連付けられ得る。無線ベアラは、順序通りの通信に対して設定され得る。
【００４２】
タイマーは、ＲＬＣ通信パスで送信された未確認のＤＵの中で最も古いＤＵが未確認である限り、維持され得る。タイマーは、ＲＬＣ通信パスで送信された未確認のＤＵの中の最も古いＤＵに対する確認応答を受信すると、停止および／または再起動され得る（停止と再起動の少なくとも一方が行われ得る）。タイマーを再起動することは、タイマー（例えば、タイマーによって示される時間または期間）をゼロに設定することを含み得る。
【００４３】
タイマーは、送信ウィンドウおよび／またはフィードバックウィンドウの経過時間を測定し得る。タイマーは、対応するＤＵの送信時に起動（初期化）された場合にのみ、最も古い未確認のＤＵの経過時間を測定し得る。ＡＣＫに応答してタイマーがゼロにリセットされると、タイマーは最も古い未確認のＤＵの経過時間よりも短い期間を測定し得る。
【００４４】
代替的に、タイマーを再起動することは、送信され未確認のＤＵの中の２番目に古いＤＵを送信してから経過した時間に従ってタイマーを起動することを含み得る。タイマーは、ＤＵの経過時間を測定し得る。
【００４５】
タイマーは、１つ以上の未確認のＤＵが送信されてからの経過時間を示すために再起動または設定され得る。タイマーは、ＲＬＣ通信パスで送信された未確認のＤＵの中で最も古いＤＵの経過時間を示し得る。
【００４６】
タイマーは、否定応答（ＮＡＣＫ）を受信した場合、維持され得る。受信側、例えば受信ピアＲＬＣエンティティからのステータスレポートは、ＮＡＣＫを示している場合がある。
【００４７】
少なくとも１つの送信されたＤＵに対する確認応答（すなわち、肯定応答またはＡＣＫ）および／または否定応答（ＮＡＣＫ）は、ステータスレポートにおいて受信され得る。ステータスレポートは、同じＲＬＣ通信パスで受信され得る。ステータスレポートは、ＲＬＣ通信パスでＤＵを送信する同じＲＬＣエンティティによって受信され得る。
【００４８】
ステータスレポートに対するポーリング要求は、ＲＬＣ通信パスで送信された未確認のＤＵの中で最も古いＤＵを使用して送信され得る。タイマーは、例えばタイマーが停止されているか、まだ維持されていない場合に、ステータスレポートに対するポーリング要求を送信すると起動し得る。
【００４９】
低下は、タイマーの少なくとも１つの期間が経過すると、決定され得る。タイマーの異なる期間は、同じタイマーをチェックするか、タイマーの異なるインスタンスをチェックすることにより実装され得る。
【００５０】
異なるタイプまたはレベルの低下は、タイマーの異なる期間が経過すると、決定され得る。例えば、期間が長くなるほど、ＲＬＣ通信パスに対して決定された低下はより深刻となり得る。
【００５１】
１つ以上のＤＵの送信を回復（復元）するための測定（措置／手段）は、タイマーの少なくとも１つの期間が経過するとトリガーされ得る。タイマーの異なる期間が経過すると、異なる測定またはイベントがトリガーされ得る。例えば、期間が長くなるほど、決定によってトリガーされる測定値は強くなる。
【００５２】
低下を決定すること、および／または、測定またはイベントをトリガーすることは、通信プロトコルスタックの上位レイヤまたは下位レイヤに当該低下を示すこと（知らせること）または報告することによって実装するか、または含めることができる。上位レイヤは、タイマーを制御または実装するレイヤの１つ以上のサブレイヤ、例えばＲＬＣレイヤのサブレイヤを含み得る。上位レイヤには、無線リソース制御（ＲＲＣ）レイヤ、パケットデータ収束プロトコル（ＰＤＣＰ）レイヤ、ＲＬＣレイヤ、またはＲＬＣレイヤの上位サブレイヤが含まれ得る。下位レイヤには、媒体アクセス制御（ＭＡＣ）レイヤが含まれ得る。
【００５３】
ＤＵは、ＲＬＣ ＰＤＵおよび／またはＰＤＣＰ ＳＤＵを含むか、それらによって実装され得る。
【００５４】
低下を決定することには、タイマーの第１の時間が経過すると、ＲＬＦを決定するまたは示す（知らせる）ことが含まれ得る。第１の期間の長さにより、ステータスレポートをポーリングするためのいくつかの試行が可能になり得る（例えば、ポーリング要求を数回送信することによって）。代替的または追加的に、第１の期間は、例えばステータスレポートでＮＡＣＫを受信することによって、および／または、例えば受信したＮＡＣＫに応じていくつかの再送を行うことにより、いくつかの自動再送要求（ＡＲＱ）を可能にし得る。
【００５５】
代替的または追加的に、タイマーの少なくとも１つの第２の期間が経過すると、低下が決定され得る。タイマーの１つ以上の第２の期間のそれぞれは、測定またはイベントをトリガーし得る。異なる第２の期間が終了すると、異なるイベントがトリガーされ得る。イベントに対する以下の例のサブセットがトリガーされ得る。
【００５６】
イベントに対する第１の例は、ＲＬＣ通信パスでのＤＵの送信の削減または中断（一時停止）であり得る。イベントに対する第２の例は、スケジューリング要求またはスケジューリング割り当ての送信のレートの削減または当該送信の中断であり得る。イベントに対する第３の例は、バッファステータスレポートの送信のレートの削減または当該送信の中断であり得る。イベントに対する第４の例は、ＲＬＣ通信パスにより使用される物理チャネルに対するチャネル品質インジケータの削減であり得る。イベントに対する第５の例は、第２の状態変数に等しくなるように第１の状態変数を進めることであり得る。イベントに対する第６の例は、ＲＬＣ通信パスで送信された確認済みのＤＵに続く次の未確認のＤＵのＳＮへ、第１の状態変数を進めることであり得る。
【００５７】
イベントに対する第７の例は、ＲＬＣ通信パスから別のＲＬＣ通信パスへの切り替えであり得る。ＲＬＣ通信パスおよび他のＲＬＣ通信パスは、デュアルコネクティビティのために、それぞれ第１および第２のＲＬＣレッグであり得る。切り替えは、１つ以上のＤＵが送信された第１のＲＬＣレッグとは異なる第２のＲＬＣレッグを介して、１つ以上の未確認のＤＵを再送することを含み得る。
【００５８】
第１の期間および第２の期間時間のうちの少なくとも一方は、品質の要件に依存し得る。品質の要件は、１つ以上のＤＵに関連付けられ得る。代替的または追加的に、品質の要件は、ＤＵを送信または受信するための無線アクセスノード、またはＤＵを送信または受信するＵＥに関連付けられ得る。代替的または追加的に、品質の要件は、ＲＬＣ通信パスまたは１つ以上のＤＵのベアラに関連付けられ得る。代替的または追加的に、品質の要件は、１つ以上のＤＵのペイロードを提供するアプリケーションまたはサービスに関連付けられ得る。
【００５９】
品質の要件は、１つ以上のＤＵの基礎となるアプリケーションまたはサービスによって定義され得る。代替的または追加的に、品質の要件は、例えば、ＱｏＳクラス識別子（ＱＣＩ）に従って、サービス品質（ＱｏＳ）要件を含み得る。
【００６０】
低下の決定は、ＲＬＣ通信ピア、例えば受信局または受信局のＲＬＣエンティティへの当該低下のシグナリングを含むか、または当該シグナリングによって実装され得る。１つ以上のＤＵの受信機は、ＲＬＣ通信ピアを有し得る。ＲＬＣ通信ピアは、ＲＬＣエンティティにより実装され得る。シグナリングはまた、報告とも称され得る。第１の状態変数を進めること、第２の状態変数を進めること、およびＲＬＣ通信パスを切り替えることのうちの少なくとも１つは、ＲＬＣ通信ピアにシグナリングされ得る。
【００６１】
方法は、ＲＡＮの無線アクセスノードにより実行され得る。あるいは、または組み合わせて、方法は、ＲＡＮに接続された、または接続可能な、無線端末によって実行され得る。
【００６２】
方法は、送信局によって、または送信局の手段によって実行され得る。送信局は、無線通信に対して構成された任意のデバイスであり得る。例えば、無線ネットワークの局はデータを送信し得る。ＤＵは、無線通信で、例えば、無線ネットワークの１つ以上の受信局に送信され得る。
【００６３】
別の態様に関して、ＤＵを受信するためのＲＬＣ通信パスを監視する方法が提供される。この方法は、ＲＬＣ通信パスで受信される（受信されるべき）１つ以上の未処理のＤＵのタイマーに基づいて、ＲＬＣ通信パスの低下を決定する工程を含む。
【００６４】
受信される各ＤＵは、ＳＮを含む、および／または、ＳＮに関連付けられ得る。１つ以上の未処理のＤＵのＳＮは、ＲＬＣ通信パスで受信された少なくとも１つのＤＵのＳＮよりも小さい場合がある。
【００６５】
タイマーは、ＳＮがＲＬＣ通信パスで順番に受信されたＤＵとのギャップを有する少なくとも１つのＤＵを受信すると起動し得る。
【００６６】
方法は、ＲＬＣ通信パスで順番に（連続して）受信されたＤＵの最も高いＳＮに続くＳＮを示す第３の状態変数を維持する工程を更に含む、または、トリガーし得る。第３の状態変数は、受信ウィンドウ、例えば、ＲＬＣ受信ウィンドウの受信状態変数であり得る。第３の状態変数は、VT_RまたはVT(R)と称され得る。第３の状態変数は、技術仕様ＴＳ  ３６．３２２（例えば３ＧＰＰ文書  ＴＳ  ３６．３２２  Ｖ１３．２．０，５．１．３節と７．１節）に従って実装され得る。
【００６７】
方法は、ＲＬＣ通信パスで受信されたＤＵの最も高いＳＮに続くＳＮを示す第４の状態変数を維持する工程を更に含む。または。トリガーし得る。第４の状態変数は、VT_HまたはVT(H)と称され得る。第４の状態変数は、技術仕様ＴＳ  ３６．３２２（例えば３ＧＰＰ文書  ＴＳ  ３６．３２２  Ｖ１３．２．０，５．１．３節と７．１節）に従って実装され得る。
【００６８】
１つ以上の未処理のＤＵのＳＮは、第３の状態変数以上である場合がある。１つ以上の未処理のＤＵのＳＮは、第４の状態変数未満（第４の状態変数より小さい）の場合がある。
【００６９】
タイマーは、第４の状態変数が第３の状態変数よりも大きい限り維持され得る。タイマーは、第４の状態変数が第３の状態変数と等しい場合、停止され得る。
【００７０】
タイマーは、第３の状態変数が第４の状態変数よりも小さいＳＮに進むと、再起動され得る。
【００７１】
低下を決定することは、タイマーの少なくとも３分の１の時間が経過したときに（経過すると）イベントを実行またはトリガーすることを含み得る。以下のイベントの例のサブコンビネーションが、トリガーまたは実行され得る。イベントの第１の例は、スケジューリング許可の送信のレートを削減するか、当該送信を中断することであり得る。イベントの第２の例は、ＲＬＣ通信パスにより使用される物理チャネルに対するチャネル品質インジケータを削減することであり得る。イベントの第３の例は、第４の状態変数に等しくなるように第３の状態変数を進めることであり得る。イベントの第５の例は、ＲＬＣ通信パスで受信されたＤＵに続く次の未処理のＤＵのＳＮに第３の状態変数を進めることであり得る。イベントの第６の例は、ＲＬＣ通信パスから別のＲＬＣ通信パスへの切り替えであり得る。ＲＬＣ通信パスは、デュアルコネクティビティで他のＲＬＣ通信パスとペアにすることができる。
【００７２】
代替的または追加的に、ＲＬＣ通信ピアからのシグナリングの受信に応答して、上記のイベントのいずれかがトリガーまたは実行され得る。第３の状態変数を進めること、および／または、ＲＬＣ通信パスを切り替えることは、ＲＬＣ通信ピアによってシグナリングされ得る。
【００７３】
方法は、ＲＬＣ通信パスの受信側、例えば、ＲＡＮ内のノードまたはＲＡＮと通信しているＵＥによって実行され得る。
【００７４】
この技術は、ＲＬＣ通信パスの低下、例えばベアラ障害またはＲＬＦ状態またはその前兆を決定（判定）するために、例えばＲＬＣ  ＡＲＱメカニズムによって追跡する必要があるメモリの量（例えば、メタデータまたは状態変数に対して）を削減することができる。当該決定は、（例えば、ＲＬＣレイヤ以外またはＲＬＣレイヤ内のプロトコルスタックのレイヤに）低下を示すことによって、および／またはタイマーに基づいてＲＬＣ通信パスの使用（例えば、スケジューリング）を制御することによって実装され得る。例えば、タイマーに基づいて、無線リンク障害が管理され得る。
【００７５】
方法は、受信ウィンドウの下端に対して第３の状態変数を監視する工程を含む、または、トリガーし得る。タイマーは、最も古いＳＮギャップが検出されてからの時間を監視し得る。
【００７６】
イベントには、タイマーが閾値を超えたときに、第３の状態変数を次に古いＳＮギャップに移動させることを含み得る。オプションで、同じまたは別のイベントは、例えば送信局で、ＲＬＣ通信ピアに制御メッセージを送信することを含む。
【００７７】
方法は、受信局によって、または受信局の手段によって実行され得る。受信局は、無線通信に対して構成された任意のデバイスであり得る。例えば、無線ネットワークの１つ以上の局が１つ以上のＤＵを受信し得る。受信局は、１つの方法の態様の文脈において上記で定義された任意の局によって具体化されてもよい。ＤＵは、例えば、無線ネットワークの送信局から、無線通信で受信され得る。
【００７８】
方法は、一方法の態様の文脈で開示される任意の特徴および／または利点をさらに達成することができ、かつ／または一方法の態様の工程のいずれかに対応する１つ以上の工程を含むことができる。
【００７９】
送信局および受信局のいずれも、例えばピアツーピア通信（例えばサイドリンク上）および／または無線アクセスネットワークへのアクセス（例えばアップリンクおよび／または ダウンリンク）に対して構成された無線デバイスまたは端末として具体化され得る。局は、ユーザ装置（ＵＥ、例えば３ＧＰＰ  ＵＥ）、モバイルまたはポータブルステーション（ＳＴＡ、例えばＷｉ−Ｆｉ  ＳＴＡ）、マシンタイプ通信用デバイス（ＭＴＣ）、またはそれらの組み合わせであり得る。ＵＥとモバイルステーションの例には、携帯電話とタブレットコンピューターが含まれる。ポータブルステーションの例には、ラップトップコンピューターやテレビが含まれる。ＭＴＣデバイスの例には、例えば、製造、自動車通信、およびホームオートメーションにおけるロボット、センサーおよび／またはアクチュエータが含まれる。ＭＴＣデバイスは、家庭用電化製品および家電製品に実装され得る。組み合わせの例には、自動運転車、ドア相互通信システム、現金自動預け払い機が含まれる。
【００８０】
代替的または追加的に、送信局および受信局のいずれかは、無線ネットワークの制御局または無線ネットワークの無線ネットワークノード、例えば無線アクセスノードとして具体化され得る。制御局または無線アクセスノードの例には、基地局（例えば、３Ｇ基地局またはＮｏｄｅＢ、４Ｇ基地局またはｅＮｏｄｅＢ、または５Ｇ基地局またはｇＮｏｄｅＢ）、アクセスポイント（例えば、Ｗｉ−Ｆｉアクセスポイント）およびネットワークコントローラ（例えば、Bluetooth、ZigBeeまたはZ-Waveによる）が含まれる。
【００８１】
無線ネットワークには、少なくとも１つの被制御局（例えば、ＵＥ、移動局または携帯局および／またはＭＴＣデバイス）および／または少なくとも１つの制御局（例えば、基地局、アクセスポイントおよび／またはネットワークコントローラ）が含まれ得る。少なくとも１つの制御局は、例えば、グローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ）、ユニバーサルモバイルテレコミュニケーションズシステム（ＵＭＴＳ）、ロングタームエヴォリューション（ＬＴＥ）またはNew Radio（ＮＲ）に従って、無線アクセスネットワーク（ＲＡＮ）を定義してもよく、またはその一部であってもよい。
【００８２】
任意の方法の態様は、無線通信のプロトコルスタックの。物理レイヤ（ＰＨＹ）、媒体アクセス制御（ＭＡＣ）レイヤ、無線リンク制御（ＲＬＣ）レイヤ、および／または無線リソース制御（ＲＲＣ）レイヤで実装され得る。
【００８３】
別の態様に関して、コンピュータプログラム製品が提供される。コンピュータプログラム製品は、コンピュータプログラム製品が１つ以上のコンピューティングデバイスによって実行されるときに、本明細書で開示される方法の態様の工程のいずれか１つを実行するためのプログラムコード部分を含む。コンピュータプログラム製品は、コンピュータ可読記録媒体に格納されてもよい。コンピュータプログラム製品は、データネットワーク、例えば無線ネットワークおよび／またはインターネットおよび／または送信局を介してダウンロードするために提供することもできる。代替的または追加的に、方法は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）および／または特定用途向け集積回路（ＡＳＩＣ）にエンコードされてもよく、またはハードウェア記述言語によるダウンロードのために機能が提供されてもよい。
【００８４】
デバイスの一態様に関して、ＤＵを送信するためのＲＬＣ通信パスを監視するためのデバイスが提供される。デバイスは、１つの方法の態様を実行するように構成される。代替的または追加的に、デバイスは、ＲＬＣ通信パスで送信される１つ以上の未確認のＤＵのタイマーに基づいてＲＬＣ通信パスの低下を決定するように構成された決定ユニットを備えてもよい。
【００８５】
別のデバイスの態様に関して、ＤＵを受信するためのＲＬＣ通信パスを監視するためのデバイスが提供される。デバイスは、他の方法の態様を実行するように構成される。代替的または追加的に、デバイスは、ＲＬＣ通信パスで受信される１つ以上の未処理のＤＵのタイマーに基づいてＲＬＣ通信パスの低下を決定するように構成された決定ユニットを備えてもよい。
【００８６】
デバイスの更なる態様に関して、ＤＵを送信するためのＲＬＣ通信パスを監視するためのデバイスが提供される。デバイスは少なくとも１つのプロセッサとメモリを備える。当該メモリは、当該少なくとも１つのプロセッサによって実行可能な命令を備え（含み）、それにより、デバイスは、ＲＬＣ通信パスで送信された１つ以上の未確認のＤＵのタイマーに基づいてＲＬＣ通信パスの低下を決定するように動作する。
【００８７】
デバイスの更なる態様に関して、ＤＵを受信するためのＲＬＣ通信パスを監視するためのデバイスが提供される。デバイスは少なくとも１つのプロセッサとメモリを備える。当該メモリは、当該少なくとも１つのプロセッサによって実行可能な命令を備え（含み）、それにより、デバイスは、ＲＬＣ通信パスで受信される１つ以上の未処理のＤＵのタイマーに基づいてＲＬＣ通信パスの低下を決定するように動作する。
【００８８】
更なる態様に関して、ＤＵを送信するためのＲＬＣ通信パスを監視するためのデバイスが提供される。デバイスは、１つの方法の態様を実行するための１つ以上のモジュールを備えてもよい。代替的または追加的に、デバイスは、ＲＬＣ通信パスで送信された１つ以上の未確認のＤＵのタイマーに基づいてＲＬＣ通信パスの低下を決定するための決定モジュールを備える。
【００８９】
更なる態様に関して、ＤＵを受信するためのＲＬＣ通信パスを監視するためのデバイスが提供される。デバイスは、別の方法の態様を実行するための１つ以上のモジュールを備えてもよい。代替的または追加的に、デバイスは、ＲＬＣ通信パスで受信される１つ以上の未処理のＤＵのタイマーに基づいて、ＲＬＣ通信パスの低下を決定するモジュールを備える。
【００９０】
デバイスおよび／または局は、方法の態様の文脈で開示される任意の特徴をさらに含み得る。特に、ユニットおよびモジュールのいずれか、または更なるユニットまたはモジュールは、方法の態様のいずれかの工程の１つ以上を実行または開始するように構成されてもよい。
【図面の簡単な説明】
【００９１】
技術の実施形態の更なる詳細は、添付の図面を参照して説明される。
【図１】図１は、データユニットを送信するための無線リンク制御通信パスを監視するための装置の概略ブロック図を示す。
【図２】図２は、データユニットを受信するための無線リンク制御通信パスを監視するための装置の概略ブロック図を示す。
【図３】図３は、図１の装置によって実装可能な、データユニットを送信するための無線リンク制御通信パスを監視する方法のフローチャートを示す。
【図４】図４は、図２の装置によって実装可能な、データユニットを受信するための無線リンク制御通信パスを監視する方法のフローチャートを示す。
【図５】図５は、送信ウィンドウの例示的な表現を概略的に示す図である。
【図６】図６は、送信ウィンドウの例示的な表現を概略的に示す図である。
【図７】図７は、ストールした送信ウィンドウを概略的に示す図である。
【図８】図８は、ポーリングリクエストを送信するために使用されるデータユニットを概略的に示す図である。
【図９】図９は、ポーリングリクエストを送信するために使用されるデータユニットを概略的に示す図である。
【図１０】図１０は、図１の装置において実装可能な、送信側におけるタイマーの動作を概略的に示す図である。
【図１１】図１１は、図２の装置において実装可能な、受信側におけるタイマーの動作を概略的に示す図である。
【図１２】図１２は、送信局で展開可能または仮想化可能な図１の装置の実施形態の概略ブロック図を示す。
【図１３】図１３は、送信局で展開可能または仮想化可能な図１の装置の実施形態の概略ブロック図を示す。
【図１４】図１４は、送信局で展開可能または仮想化可能な図２の装置の実施形態の概略ブロック図を示す。
【図１５】図１５は、送信局で展開可能または仮想化可能な図２の装置の実施形態の概略ブロック図を示す。
【発明を実施するための形態】
【００９２】
以下の説明では、限定ではなく説明の目的で、本明細書で開示される技術の完全な理解を提供するために、特定のネットワーク環境などの特定の詳細が示される。これらの特定の詳細から逸脱する他の実施形態でこの技法を実施できることは、当業者には明らかであろう。更に、以下の実施形態は主に5G New Radio（ＮＲ）の実装について説明しているが、ここで説明する技術は、３ＧＰＰ  ＬＴＥまたはその後継、ＩＥＥＥ８０２．１１の規格ファミリによる無線ローカルエリアネットワーク（ＷＬＡＮ）、Bluetooth Special Interest Group（ＳＩＧ）によるBluetooth、特にBluetooth低エネルギーおよびBluetoothブロードキャストおよび／またはＩＥＥＥ８０２．１５．４に基づくZigBee、を含む他の無線ネットワークでも実装できることは明らかである。
【００９３】
更に、本明細書で説明する機能、工程（ステップ）、ユニット、およびモジュールは、プログラムされたマイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタルシグナルプロセッサ（ＤＳＰ）または汎用コンピュータ（例えばアドバンストＲＩＳＣマシン（ＡＲＭ）を含む）と連携して機能するソフトウェアを使用して実装できることを当業者は理解するであろう。また、以下の実施形態は主に方法およびデバイスに関連して説明されるが、本発明は、コンピュータプログラム製品ならびに少なくとも１つのコンピュータプロセッサおよびメモリに接続されたメモリを含むシステムにおいても実施できることも理解されよう。メモリは、機能および工程を実行するか、または本明細書で開示されるユニットおよびモジュールを実装することができる１つ以上のプログラムでエンコードされる。
【００９４】
図１は、データユニット（ＤＵ）を送信するための無線リンク制御（ＲＬＣ）通信パスを監視するデバイスのブロック図を概略的に示しており、このデバイス（装置）は一般に参照符号１００で示されている。デバイス１００は、ＲＬＣ通信パスで送信された１つ以上の未確認のＤＵのタイマーに基づいてＲＬＣ通信パスの低下を決定する決定ジュール１０４を備える。
【００９５】
デバイス１００は、無線ネットワークおよび／または無線ネットワークの一部に接続され得る。デバイス１００は、無線ネットワークの送信局、送信局を制御するために無線ネットワークに接続されたノード、またはそれらの組み合わせにより、またはそれらで具体化されてもよい。例えば、デバイス１００は、１つ以上の送信ＲＬＣエンティティを含むＲＬＣ送信機であり得る。
【００９６】
オプションで、デバイス１００は、ＲＬＣ通信パスで送信された未確認のＤＵのタイマーを維持する未確認データモジュール１０２を更に備える。タイマーはモジュール１０４によって使用される。代替的または追加的に、デバイス１００は、モジュール１０４によって決定された低下に応じてＲＬＣ通信パスの使用を制御する制御モジュール１０６を備える。
【００９７】
図２は、ＤＵを受信するためのＲＬＣ通信パスを監視するためのデバイスのブロック図を概略的に示しており、このデバイス（装置）は一般に参照符号２００で示されている。デバイス２００は、ＲＬＣ通信パスで受信される（受信されるべき）１つ以上の未処理のＤＵのタイマーに基づいて、ＲＬＣ通信パスの低下を決定する決定モジュール２０４を備える。
【００９８】
オプションで、デバイス２００は、ＲＬＣ通信パスで受信される未処理のＤＵのタイマーを維持する未処理データモジュール２０２を更に備える。タイマーはモジュール１０４によって使用される。代替的または追加的に、デバイス２００は、モジュール２０４によって決定された低下に応じてＲＬＣ通信パスの使用を制御する制御モジュール２０６を備える。
【００９９】
デバイス２００は、無線ネットワークおよび／または無線ネットワークの一部に接続され得る。デバイス２００は、無線ネットワークの受信局、受信局を制御する無線ネットワークに接続されたノード、またはそれらの組み合わせにより、またはそれらで具体化されてもよい。例えば、デバイス２００は、１つ以上の受信ＲＬＣエンティティを含むＲＬＣ受信機であり得る。
【０１００】
デバイス１００およびデバイス２００のモジュールのいずれかは、対応する機能を提供するように構成されたユニットによって実装され得る。
【０１０１】
送信局および受信局のそれぞれは、基地局（例えば、ネットワークコントローラまたはＷｉ−Ｆｉアクセスポイント）、または、無線ネットワーク（例えば、より具体的には、無線ネットワーク内で無線アクセスを提供する無線アクセスネットワーク）の無線アクセスノード（例えば、３Ｇ ＮｏｄｅＢ、４Ｇ ｅＮｏｄｅＢまたは５Ｇ ｇＮｏｄｅＢ）を含み得る。代替的または追加的に、送信局および受信局のそれぞれは、無線ネットワークに接続可能な（たとえば、より具体的には、無線ネットワーク内の無線アクセスを提供する無線アクセスネットワークに接続可能な）モバイルまたはポータブルステーションまたは無線デバイスを含み得る。無線デバイスは、ユーザ装置（ＵＥ）またはマシンタイプ通信（ＭＴＣ）のデバイス（道路車両等）であり得る。代替的または追加的に、送信局および受信局のそれぞれは、無線アクセスを提供するように、および／または、例えばアドホック無線ネットワーク内または３ＧＰＰサイドリンクを介して互いに無線接続するように構成され得る。
【０１０２】
図３は、ＤＵを送信するためのＲＬＣ通信パスを監視する方法３００のフローチャートを示す。方法３００は、ＲＬＣ通信パスで送信された１つ以上の未確認のＤＵに対するタイマーに基づいて、ＲＬＣ通信パスの低下を決定する工程３０４を含む。
【０１０３】
方法は、ＲＬＣ通信パスで送信された未確認のＤＵに対するタイマーを維持するステップ３０２、および／または、ステップ３０４において決定された低下に従ってＲＬＣ通信パスの使用を制御するステップ３０６を更に含み得る。
【０１０４】
方法３００は、デバイス１００によって、例えば無線ネットワークの送信局で、または送信局を使用して、実行され得る。例えば、モジュール１０２、１０４、および１０６は、それぞれステップ３０２、３０４、および３０６を実行し得る。
【０１０５】
図４は、ＤＵを受信するためのＲＬＣ通信パスを監視する方法４００のフローチャートを示す。方法４００は、ＲＬＣ通信パスで受信される１つ以上の未処理のＤＵに対するタイマーに基づいて、ＲＬＣ通信パスの低下を決定するステップ４０４を含む。
【０１０６】
方法は、ＲＬＣ通信パスで受信される未処理のＤＵに対するタイマーを維持するステップ４０２、および／または、ステップ４０４において決定された低下に従ってＲＬＣ通信パスの使用を制御するステップ４０６を更に含み得る。
【０１０７】
方法４００は、デバイス２００によって、例えば受信局で、または受信局を使用して、実行され得る。例えば、モジュール２０２、２０４、および２０６は、それぞれステップ４０２、４０４、および４０６を実行し得る。
【０１０８】
この技術は、標準化された状態変数（例えば、デバイス１００によって維持されるVT_SおよびVT_A、および／または、デバイス２００によって維持されるVT_RおよびVT_H）を使用する５Ｇ  ＮＲ実装に対してより詳細に説明される。
【０１０９】
タイマーに基づいて、方法３００および４００のそれぞれは、ステップ３０４および４０４においてそれぞれ上位レイヤへの無線リンク障害（ＲＬＦ）を決定（例えば、宣言および／または指示）するタイミングを制御する。（メモリおよび／または処理リソースに関して）複雑性の低い効果的なアプローチが提示され、ここで、デバイス１００としてのＲＬＣ送信機は、デバイス１００が未確認の送信データを持っている（すなわち、VT_S != VT_A、ここで!=は「等しくない」またはこの場合は「より大きい」を意味する）が、Ｔ１で示されるタイマー（ＲＬＦタイマーとも呼ばれる）の第１の期間が満了する（切れる）前に送信ウィンドウが進まない場合、ＲＬＦを宣言する。好ましくは、第１の期間、すなわちＴ１タイマー値は、無線ベアラで運ばれる上位レイヤサービスに耐えられるものに基づいており、ステータスフィードバックをポーリングし、１つ以上のＡＲＱ（および基礎となるＨＡＲＱ）再送を実行するためのいくつかの試行を可能にするのに十分な大きさである。簡潔にするために、第１の期間と、第１の期間の満了時の対応するトリガーを「タイマーＴ１」と称する。
【０１１０】
代替として、またはタイマーＴ１に加えて、方法３００は、第２の期間、すなわち第２のタイマー値Ｔ２を実装する。第２の期間は第１の期間より短い。簡潔にするために、第２の期間と、第２の期間の満了時の対応するトリガーを「タイマーＴ２」と称する。タイマーＴ２はタイマーＴ１として動作する。特に、開始時間は同じである。タイマーＴ２は、第２のタイマーとして、またはタイマーＴ１に使用される同じタイマーの第２のトリガーとして実装され得る。
【０１１１】
Ｔ２タイマーの目的は、ＲＬＦをトリガーすることではない。タイマーＴ２は、無線の問題を示すために使用される。その後、タイマーＴ２が満了した場合に、悪い無線状態を処理するために異なるアクションが実行され得る。
【０１１２】
一実施形態では、例えば、デュアルコネクティビティ構成の場合、タイマーＴ２は、現在使用されている第１のＲＬＣレッグにおける１つ以上の未確認のＤＵ（すなわち、ＲＬＣ確認応答が受信されていないＤＵ）の、１つ以上の未確認のＤＵの送信に対する別の代替のＲＬＣレッグへの転送をトリガーするために使用される。第１および第２のＲＬＣレッグは、ＲＬＣ通信パスの送信側で、それぞれ第１および第２のＲＬＣエンティティによって固定および制御されてもよい。第１および第２のＲＬＣエンティティは、送信局に位置し得る。あるいは、第１のＲＬＣエンティティのみが送信局のＲＬＣレイヤで実装され得る。送信局のＲＬＣレイヤは、別の送信局のＲＬＣレイヤに実装された第２のＲＬＣエンティティを制御する。
【０１１３】
第２のレッグが再送（または更なるＤＵ送信）を継続できるという確認が第２のＲＬＣエンティティから受信されると、第１のＲＬＣエンティティは、第１のＲＬＣレッグでの１つ以上の未確認のＤＵの再送を停止または一時停止する。１つ以上の未確認のＤＵが第２のＲＬＣレッグを介して正常に転送されたという確認が第２のＲＬＣエンティティから受信されると、第１のＲＬＣエンティティは、それらのＤＵをその送信ウィンドウから破棄し得る。
【０１１４】
別の実施形態では、例えば、単一のコネクティビティ構成について、または一実施形態に加えて、タイマーＴ２（または更なる第２の期間）は、一時停止をトリガーするか、ＵＥまたはＲＡＮが実行することができるＤＵ再送の数および／または新しいＤＵの送信の数の一時停止または一時的な削減（例えば、最小化）をトリガーする。
【０１１５】
タイマーＴ２の満了の結果として、デバイス１００がＲＬＣ受信機によってまだ正常に受信されていないＤＵを破棄する場合、これにより、従来のＲＬＣ受信機は、欠落したＳＮを待つことでスタックする可能性がある。受信ウィンドウを進めることができないこのようなデッドロックを回避するために、ＲＬＣ受信機としてのデバイス２００は、そのタイマー（明確にするためにタイマーＴ３と呼ばれる）を維持する。タイマーＴ３に基づいて、デバイス２００は、それ以上待機する必要がない場合を決定する。タイマーＴ３は、状態変数ＶＲ＿Ｒによって示される受信ウィンドウの下端に対応するＤＵが最初に欠落として検出されてから経過した時間または期間を測定するために使用される。タイマーＴ３が満了すると、受信機は受信ウィンドウを進め、次の欠落したＳＮに移動させ得る。
【０１１６】
このために、デバイス２００は、受信ウィンドウに少なくとも１つのホール（穴）またはギャップ（間隔）がある場合に、欠落したＤＵを検出し、最も古い連続した欠落ＤＵ（すなわち、欠落したＤＵの最小のＳＮのシーケンス）がタイマーＴ３により指定された期間に受信されていない場合に、デバイス２００は、受信ウィンドウの下端を、欠落したＤＵの次のＳＮシーケンスの開始（すなわち、最小ＳＮ）に進めるか、そのようなホールまたはギャップがない場合、受信ウィンドウの下端を最新の受信ＳＮに続くＳＮに設定する。
【０１１７】
タイマーＴ３（またはデバイス２００によって維持される更なるタイマーＴ３）に対する代替または追加の使用法は、Ｔ３が満了した場合にデバイス２００にＲＬＦをトリガーさせることである。したがって、デバイス２００はまた、デバイス１００がＤＵの送信に失敗した場合、例えば、受信機によりトリガーされるＲＬＦが送信機によりトリガーされるＲＬＦよりも効率的である場合、無線の問題に対してＲＬＦをトリガーすることができる。例えば、ＵＥがトリガーするＲＬＦの方がデータトラフィックの中断が短くなることが多いため、通常はＵＥがＲＡＮではなくＲＬＦをトリガーする方が適切である。
【０１１８】
図５は、ＲＬＣ送信機としてデバイス１００で維持されるＲＬＣ送信機変数を概略的に示す。ＳＮ長が16ビットのＬＴＥ  ＲＬＣデータ転送に関連する状態変数は、0〜65535の値を取ることができる。ＮＲの実装では、ＲＬＣレイヤは18ビットＳＮを使用し得る。ＳＮ長が18ビットの状態変数は、0〜262143の値を取ることができる。一般に、状態変数は0〜2[SNのフィールド長]を取る。
【０１１９】
ＲＬＣ送信機としてのデバイス１００では、状態変数VT_SおよびVT_Aが維持される。VT_Sは、次の新しく生成されたＰＤＵに割り当てられるＳＮの値を保持する、３ＧＰＰ  ＴＳ  ３６．３２２の送信状態変数に従って、またはそれに類似して、定義され得る。最初は0に設定され、デバイス１００の送信ＲＬＣエンティティがSN = VT_SのＰＤＵを送信するたびにインクリメントされる。
【０１２０】
VT_Aは、３ＧＰＰ  ＴＳ  ３６．３２２の確認応答状態変数であり、肯定応答（簡単に言うとＡＣＫ）が順番に受信される次のＰＤＵのＳＮの値を保持する。そのため、VT_Aは送信ウィンドウの下端として機能する。最初は0に設定され、デバイス１００の送信ＲＬＣエンティティがSN = VT_AのＰＤＵのＡＣＫを受信するたびに更新される。送信ウィンドウの上端は、VT_A + AM_Window_Sizeに従ってVT_Aに基づいて計算される。
【０１２１】
状態変数VT_Aは、デバイス１００、例えばＡＭ ＲＬＣエンティティの送信側でのいわゆるmodulus（モジュラス）（係数・率）ベースでもある。このmodulusベースは、関係するすべての値から減算され、絶対比較が実行される。一例として、ＳＮ長が18ビットの場合、 
VTA ≦ SN ＜ VTS
が、
[VTS - VTA] modulo 262144 ≦ [SN - VTA] modulo 262144 ＜ 
[VTS - VTA] modulo 262144
として評価される。
【０１２２】
また、ＲＬＣ受信器としてのデバイス２００は、いくつかの状態変数を維持する。特に、ここで興味深いVR_HとVR_Sの２つのＲＬＣ状態変数がある。
【０１２３】
VR_Hは３ＧＰＰ  ＴＳ  ３６．３２２の受信状態変数で、受信したＲＬＣデータＰＤＵの中で最高のＳＮを持つＲＬＣデータＰＤＵのＳＮに続くＳＮの値を保持する。最初は０に設定され、ＲＬＣエンティティがSN = VR_HのＰＤＵを受信するたびにインクリメントされる。
【０１２４】
VR_Rは、３ＧＰＰ  ＴＳ  ３６．３２２の受信状態変数で、最後に順番どおりに完全に受信されたＡＭＤ  ＰＤＵに続くＳＮの値を保持する。そのため、VR_Rはデバイス２００において受信ウィンドウの下端として機能する。Sそれは、最初は0に設定される。受信ウィンドウの上端は、VR_R + AM_Window_Sizeに従ってVR_Rに基づいて計算される。VR_Rは、デバイス２００、例えばＡＭ ＲＬＣエンティティの受信側でのmodulusベースである。
【０１２５】
図５と図６は、それぞれ基準信号５０２および５０４でのＲＬＣ送信機の通常動作におけるVT_AおよびVT_Sの例を概略的に示している。図５は、線形表現５００および円形表現５５０を使用する送信ウィンドウを概略的に示している。送信ウィンドウの上端は、参照符号５０６で示されている。
【０１２６】
図５の例では、連続データだけでなく、ＲＬＣ送信機が送信する多くのデータもある。例えば、ＩＰパケット／秒または物理レイヤビット／秒のピークレートに到達しようとしている。輻輳を引き起こす根本的なボトルネックは存在しない。デバイス１００がデバイス２００から受信の確認応答を含むステータスレポートを受信すると、送信ウィンドウ５５０は連続的に前進する。図５は、送信ウィンドウの２つの位置を示している。最初の時点で、送信ウィンドウは、18ビットＳＮ空間の104448以降のシーケンスにある。次に、後の２番目の時点で、送信ウィンドウは18ビットＳＮ空間の152576以降にある。
【０１２７】
図６は、図５と同じ送信ウィンドウの同じ位置を模式的に示しているが、モジュラスベースVT_Aで計算されている。
【０１２８】
図７は、VT_Aによって示されるＳＮに対するＡＣＫが欠落し続けている間に、送信ウィンドウ５５０のストールの開始の例を概略的に示している。その理由は、SN VT_Aを持つＤＵがデバイス２００のピアＲＬＣ受信機によって正常に受信されることを妨げる物理的状況であり得る。また、ステータスレポートの送信をスケジュールするために同じ状況または他のリソースが欠落している可能性があり、これにより、受信したVT_AのＳＮを持つＤＵをクリアするデバイス１００でのステータスレポートの受信が妨げられる。VT_Sがウィンドウの上端に達すると、ウィンドウがストールする（図７における131071において）。結果として、VT_Aは更新されない。すなわち、送信ウィンドウは進行せず、ストールし始める。
【０１２９】
この技術は、従来のＬＴＥに定義されたメカニズムまたは従来のＬＴＥに類似したメカニズムと組み合わせたり、補完したりできる。例えば、VT_Aが欠落している間、再送カウンタReTx_countが使用される。ＤＵが初めて再送されると見なされる場合、ReTx_countはＤＵに関連付けられ、ゼロに設定される。それ以外の場合、ＤＵまたはその一部がすでに再送を保留している場合、ReTx_countはインクリメントされる。ReTx_count = maxReTx_Thresholdの場合、ベアラ障害の指標が上位レイヤに配信される。
【０１３０】
更に、例えば、従来のＬＴＥにおけるように、デバイス２００からのステータスレポートをポーリングするためのポーリング要求が送信され、バイトの閾値量（例えば、pollByte）またはＤＵ（例えば、pollPDU）のいずれかに達すると、または、新しいデータを送信できない場合（ウィンドウのストールにより等）、タイマーt-PollRetransmitが開始される。タイマーt-PollRetransmitが満了すると、ポーリング要求が送信され、タイマーt-PollRetransmitが再び開始される。送信する新しいデータがまだない場合（ウィンドウのストールにより等）、SN = VT_S - 1のＤＵ、または肯定に確認されていないＤＵが再送と見なされる。
【０１３１】
図８および図９は、状態変数VT_SおよびVT_AがどのＤＵが再送のために考慮されるべきかを決定するためにどのように使用されるかを概略的に示している。図８の例では、バッファが空になり、送信する新しいデータはない。図９の例では、送信されるデータの量が多いため、VT_Sはウィンドウがストールする上端５０６までかなり進んでいる。
【０１３２】
図８と図９のそれぞれに示されるように、ＳＮがVT_Sより小さく、VT_A以上である送信されたＤＵの中で、非常に多くのＤＵが空中（すなわち、未確認）であり得る。図８および図９では、未確認のＤＵのＳＮ白丸で示されている。VT_S未満であり、VT_A以上である他のＳＮについて、デバイス１００は、（例えば、ポーリング要求に応答して）承認された受信のステータスレポートを受信している。
【０１３３】
ＳＮごとに維持されるReTx_count８００は、図８および図９の参照符号８００で示されている。ReTx_count ８００がインクリメントされると、maxReTx_Thresholdに達するまで、失敗したポーリングごとにt-PollRetransmitタイマーの期間が合計される。
【０１３４】
デバイス１００のＮＲ ＲＬＣ実装は、順不同でＤＵを配信することを許可され得るが、少なくともＮＲ ＰＤＣＰレイヤの再配列バッファは、それに応じて寸法決定される必要があるだろう。ＭＴＵ（最大送信ユニット）サイズが1500バイトの131070データユニット（SNスペースの半分）には、各無線ベアラに対して200MB必要であり、各ＵＥはそのような複数のベアラのサポートを必要とする。
【０１３５】
その結果、従来のＬＴＥでは、ReTx_countに必要なメタデータと関連する処理はVT_S - VT_Aに対応する。したがって、メモリと処理装置は、欠落しており再送信が必要な131070ＤＵユニットの最悪の場合の順序に合わせて寸法設定する必要がある。
【０１３６】
方法３００および４００によるタイマーにより、ＲＬＣ送信機としてのデバイス１００およびＲＬＣ受信機としてのデバイス２００は、それぞれ、VT_AおよびVT_Rが失われた後の経過時間に基づいて、無線の問題を自律的に検出できる。
【０１３７】
図１０は、送信ウィンドウ５５０に応じてデバイス１００でVT_Aの進行を監視するために方法３００に従って使用されるタイマーＴの動作を示す。確認応答されていないＤＵがある場合とない場合の受信ウィンドウの状態は、それぞれ参照符号１０１０と１０２０で概略的に示されている。
【０１３８】
したがって、ＮＲ  ＲＬＣ（またはＡＲＱが実行される場合のＮＲ  ＰＤＣＰ）では、ＤＵが再送を考慮され、送信ウィンドウ（VT_A）の下端５０２が前方に移動すると、タイマーＴはゼロに設定される。タイマーＴが閾値期間、たとえば、第１の期間（maxwaitB4RLFとも称される）としてのＴ１、または第２の期間（maxwaitB4forwardとも称される）としてのＴ２を超える場合、ベアラ障害の指標が、ステップ３０４に従って、上位レイヤに配信される。
【０１３９】
したがって、タイマーＴは、SN VT_Aを有する未確認のＤＵの経過時間、またはSN VT_Aで始まる送信ウィンドウの経過時間を測定する。
【０１４０】
方法３００によれば、タイマーＴはいくつかのスキームに従って動作し得る。以下のスキームのリストは網羅的なものではなく、例のサブコンビネーションは方法３００によって実装されてもよい。
【０１４１】
第１の例では、VT_Sが更新され１つ以上の未確認のＤＵが送信されたときに（つまり、VT_S != VT_A）、タイマーＴがまだ実行されていない場合に開始される。第２の例では、タイマーＴが既に実行されている場合、VT_Aが新しい値を取得せずに更新されると（つまり、VT_Aは変更されない）、タイマーＴは実行されたままになる一方で、未確認の送信データが発生する（VT_S != VT_A）。第３の例では、タイマーＴは、まだ実行されていない場合、タイマーt-PollRetransmitが開始するときに、すなわち、ＤＵに対するポーリングビットが最初に設定されたときにのみ（同じＳＮの後続のポーリングではない）、開始する。第４の例では、全ての送信データが確認された場合（すなわち、VT_AがVT_Sに等しい場合）、タイマーＴは停止する。
【０１４２】
一実施形態として、Ｔ１として示されるタイマーは、タイマーＴについて説明したように動作する。タイマーＴ１が満了する（すなわち、Ｔ１がmaxwaitB4RLFに等しいかそれを超える）場合、タイマーＴ１は、ステップ３０４で現在の無線ベアラに対して宣言されるＲＬＦをトリガーする。
【０１４３】
一実施形態の拡張として、または別の実施形態において、Ｔ２として示されるタイマーは、タイマーＴについて説明したように動作する。タイマーＴ２が満了する（すなわち、Ｔ２がmaxwaitB4forwardに等しい）場合、タイマーＴ２はデバイス１００内のローカルインジケーションまたは送信局の別のレイヤをトリガーし、別のＲＬＣインスタンスを介して、１つ以上の未確認のＤＵ（すなわち、正常に転送されなかったＤＵ）を転送しようとする。これは、タイマーＴ２が満了した現在のＲＬＣインスタンスでのスケジューリングを一時停止、最小化、または少なくとも更に減少させ得ることを示し得る。
【０１４４】
代替的または追加的に、タイマーＴ２の満了は、送信レートを停止または最小化するためにＲＬＣ送信機としてのデバイス１００をトリガーする。代替的または追加的に、タイマーＴ２の満了は、ＵＥがスケジューリング要求（ＳＲ）を送信しているレートを減少させるために、ＲＬＣ送信機としてのデバイス１００を具体化するＵＥをトリガーする。代替的または追加的に、タイマーＴ２の満了は、ＵＥがバッファステータスレポート（ＢＳＲ）を送信しているレートを減少させるために、ＲＬＣ送信機としてのデバイス１００を具体化するＵＥをトリガーする。代替的または追加的に、タイマーＴ２の満了は、送信ウィンドウの下端VT_Aを進め、VT_Sに設定するために、ＲＬＣ送信機としてデバイス１００をトリガーする。代替的または追加的に、タイマーＴ２の満了は、送信ウィンドウの下端VT_Aを、 確認済みＤＵ（すなわち、成功したＲＬＣ  ＡＣＫを受信したＤＵ）に続く次の送信し未確認のＤＵ（すなわち、成功したＲＬＣ  ＡＣＫが受信されていないＤＵ）に進め、タイマーＴ２を再開させるために、ＲＬＣ送信機としてデバイス１００をトリガーする。
【０１４５】
従来のＲＬＦ検出は、例えばカウンタのみに基づいており、受信側、例えばＵＥにとっても不利である。無線の問題により、ＲＡＮによりＵＥに送信されたＲＬＣ  ＰＤＵが正常に確認されない場合、これは、しばらくしてＲＡＮがＲＬＦを示し、その結果、ＵＥを解放しようとすることを意味する。いくつかの追加の期間の後、ＲＡＮは無線の問題によりＵＥを解放する必要があることを上位レイヤに示す。これは、ＵＥがこの時間内に自律的に無線の問題を検出せず、ＲＡＮにアクセスしようとした場合、ＵＥは、ＲＡＮのコアネットワークから、例えば、ＬＴＥ実装のモビリティ管理エンティティ（ＭＭＥ）によって、解放されることを意味する。
【０１４６】
対照的に、受信局（例えば、ＵＥ）で実装されるデバイス２００は、低下（例えば、ＲＬＦまたはその任意の前兆）を自律的に検出する。これにより、ＵＥはセル（例えば、デバイス１００の現在のセルまたは別のセル）で無線リソース制御（ＲＲＣ）再確立を実行できる。これは、成功した場合に、悪い無線状態によるトラフィックの中断が最小化されることを意味する。なぜなら、この場合、ＵＥはコアネットワークの構成要素によって解放されていないからである。
【０１４７】
ＲＬＣ受信機としてデバイス２００によって実行される方法４００は、ステップ４０４に従って受信ウィンドウで検出されたギャップに起因する無線の問題を自律的に検出する。
【０１４８】
前の実施形態で提案されたように、ＲＬＣ送信機としてのデバイス１００が、ＲＬＣ  ＰＤＵを破棄し、ＲＬＣ受信機に通知せずに送信ウィンドウを進めると、従来のＲＬＣ受信機は欠落したＳＮを待ってスタックし得る。受信ウィンドウを進めることができないこのようなデッドロックを回避するために、方法４００は、タイマーに基づいて受信側で低下を検出する。
【０１４９】
デバイス２００の一実施形態では、ＲＬＣ受信機は、タイマーＴ３によって示されるタイマーを維持する。タイマーＴ３は、実行されていない場合、受信ウィンドウで未処理のＤＵの新しいホールまたはギャップが検出されたときに開始される。VR_Hより小さい１つ以上の完全に受信されていないＳＮがある場合（およびその場合のみ）、ホールまたはギャップが存在する。タイマーＴ３は、VR_Rが更新され、VR_Hの下にホールまたはギャップがなくなると停止する。タイマーＴ３が満了すると（切れると）、受信ウィンドウの下端（すなわちVR_R）がVR_Hに進むか、次のホールまたはギャップの開始に進む。そのような次のホールが存在する場合、タイマーＴ３が再開される。ホールがもはや存在しない場合、受信ウィンドウの下端VR_RはVR_Hに設定される。
【０１５０】
方法４００に従ってタイマーＴ３を動作させる例が図１１に概略的に示されており、タイマーＴ３によって受信側での最大待ち時間を制御する。時間は、受信ウィンドウ１１００の円形表現の半径方向外側に進む。第３の状態変数VT_R、第４の状態変数VT_H、および受信ウィンドウの上端は、それぞれ参照符号１１０２、１１０４および１１０６で示されている。受信すべき未処理のＤＵのホール（またはギャップ）の有無による受信ウィンドウの状態は、それぞれ参照符号１１１０および１１２０で概略的に示されている。
【０１５１】
一実施形態に加えて、または別の実施形態では、デバイス２００のタイマーＴ３が満了すると、ＵＥは、VR_Rの新しい値に関連付けられたＳＮについてポーリングされたかのように、新しいＲＬＣステータスレポートを送信する。したがって、VR_Rまで受信された全てのＤＵは、デバイス１００で確認済みと見なされる。代替として、ＵＥは、タイマーＴ３の満了時にＲＬＣステータスレポートの送信をトリガーしない。
【０１５２】
デバイス２００が受信ウィンドウの下端VT_Rを自律的に進める場合、送信ウィンドウの（以前の）下端にＳＮを持つＤＵ（VT_A等）は、デバイス１００によって後で再送される場合、受信ウィンドウの（進んだ）下端の下に現れ、それゆえ、ＲＬＣ受信機として機能するデバイス２００によって継続的に破棄され得る。この問題を軽減するために、一実施形態では、デバイス２００は、これが発生した場合、ＲＬＣステータスレポートをトリガーし、VR_Rに設定されたＳＮでポーリングされたようにＲＬＣステータスレポートを送信する。
【０１５３】
デバイス２００の任意の実施形態に加えて、または更なる実施形態では、タイマーＴ３が満了し、ＲＬＣ受信機としてのデバイス２００がＲＡＮによって具体化される場合、タイマーＴ３の満了は、受信側での劣悪な無線の指標をトリガーする。代替的または追加的に、ＲＡＮで実装されるデバイス２００は、ステップ４０４の決定に応じて、アップリンクにおける現在のスケジューリングのレートを停止または減少させ得る。
【０１５４】
更なる実施形態として、またはデバイス２００の上記の実施形態のいずれかに加えて、タイマーＴ３の満了は、ＲＬＣ受信機でＲＬＦをトリガーする。
【０１５５】
方法４００の任意の実装は、ＲＬＣ送信機としてのデバイス１００が、ＲＬＣ受信ウィンドウの上で受信される新しいＤＵを送信することを可能にし得る。デバイス１００のタイマーＴ２が満了したとき、ＲＬＣ送信機としてのデバイス１００がその送信ウィンドウを一方的に進めると、ＲＬＣ ＳＮ同期はリスクとなる可能性がある。VT_Sで次に送信されたＤＵ（およびその後のＤＵ）は、受信ウィンドウの上端を超えて現れる場合があり、したがって、従来のＲＬＣ受信機によって破棄され得る。
【０１５６】
ＲＬＣ受信機としてデバイス２００によって実行される方法４００は、このイベントを検出し、タイマーＴ２の満了時に送信ウィンドウを進めるＲＬＣ送信機としてデバイス１００との同期を維持し得る。したがって、デバイス２００の上記の実施形態のいずれも、デバイス２００が以下のＳＮを有するＤＵを受信するとき、VR_RおよびVR_Hの両方をSN + 1に更にリセットし得る。
SN ＞ VR_R + AM_Window_Size、および、
SN ＜ VR_R + AM_Window_Size + deltaSize
ここで、deltaSizeは、AM_Window_Sizeの実質的な部分（例：ごく一部）である値、例えば４分の１（１／４）である。
【０１５７】
代替的または追加的に、方法３００および４００の任意の実装は、例えば制御ＰＤＵメッセージなどのシグナリングの手段によって、ＲＬＣ送信機としてのデバイス１００とＲＬＣ受信機としてのデバイス２００とを同期させ得る。
【０１５８】
異なるレッグで負荷と無線条件が変化するため、データは２つのパスで送信され、一方のレッグで送信されたデータはもう一方のレッグで送信されたデータと比べて大幅に遅延するため、デュアルコネクティビティは特別な問題を引き起こす。これは、受信ＰＤＣＰエンティティ（例えば、デバイス２００またはデバイス２００の受信局において）がＰＤＣＰ  ＳＤＵを順番に上位レイヤに配信できず、ウィンドウのストールにつながる場合に特に問題になる。
【０１５９】
ただし、デュアルコネクティビティでは、１つ以上のＤＵの安全な配信を保証するために、少なくとも１つのレッグの無線状態が十分に良好であると想定できる。例として、デュアルコネクティビティのシナリオでは、一方のレッグがより低いＬＴＥレガシーキャリア周波数を使用し、もう一方が１０倍の大きさの５Ｇキャリア周波数を使用している場合がある。このようなシナリオでは、５Ｇレッグでの無線状態が厳しいシャドウフェージング特性を示し、その結果、カバレッジが短時間で良好から基本的に存在しない状態（高速フェージング）になる可能性があると想定できる。そのようなシナリオでは、ＰＤＣＰプロトコルを終了するノードに対して有利であり、レッグフロー制御が、５Ｇノードにすでに送信され、ＬＴＥノードに存在する１つ以上のＤＵを再送するために存在する。これにより、ＵＥの受信エンティティでのＰＤＣＰレベルでの配信が、５Ｇノードでスタックしたデータのためにストールしないことが保証される。このようなシナリオでは、送信PDCPエンティティは、５ＧレッグにスタックしたデータがＬＴＥレッグを介してＵＥによって正常に送信および受信されたという確認応答を受信し、５Ｇレッグでの再送によるデータを冗長にする。その結果、送信エンティティとしてのデバイス１００は、冗長な１つ以上のＤＵの破棄、および、５Ｇノード内のＲＬＣの同期を開始する。これは、専用の制御メッセージを使用して実現することができる。この制御メッセージは、ＭＡＣ、ＲＬＣ、またはＰＤＣＰプロトコルのいずれかを介して送信することができ、１つの可能な実施形態は、例えば以下で詳述するように、ＲＬＣ制御ＰＤＵを利用することである。
【０１６０】
例として、ＲＬＣレベルでは、これは制御ＰＤＵタイプ（ＣＰＴ）フィールドの予約値を使用するか、ＰＤＣＰヘッダの予約ビットを使用することで実現できる。次に、この現在予約値を使用して、スループットの低いまたはスループットのないレッグにおける１つ以上のＤＵを破棄するように、受信エンティティとしてのデバイス２００に指示できる。指示は、スループットの問題があるレッグで送信するか、より適切には、無線状態が良好な他のレッグで送信でき、他のレッグの１つ以上のＤＵを破棄してＲＬＣ同期するように指示する。
【０１６１】
制御ＰＤＵは、より明示的であり、全てのデータを破棄する命令を送信する代わりに、ＰＤＣＰにおける受信リオーダリングエンティティが良好なレッグを介して要求した特定のＰＤＣＰ  ＰＤＵの指示を含め、それにより、送信ＰＤＣＰエンティティが順番に 不良レッグにおけるＲＬＣエンティティが破棄するＰＤＣＰ  ＰＤＵを指示することができる。
【０１６２】
３ＧＰＰ  ＴＳ３６．３２２におけるＣＰＴフィールドには多くの予約ビット（001〜111）があり、そのいずれかをピアＲＬＣエンティティに示す目的で使用できる。代替的または追加的に、３ＧＰＰ  ＴＳ  ３６．３２３  ＰＤＣＰヘッダの予約ビットのいずれかを使用することもできる。次に、制御ＰＤＵを使用して、特定のＲＬＣ  ＳＮまでの全てのＲＬＣ  ＳＤＵデータを破棄し、ポーリングビットを介して明示的に受信エンティティに指示するか、別の予約ヘッダビットを利用して別の制御ＰＤＵを介して暗示的に受信ＲＬＣエンティティに確認応答を送信するよう指示する。
【０１６３】
これにより、良好なレッグで実行されたシグナリング調整に基づいて、レッグにおけるＲＬＣエンティティが送信問題を経験し、冗長データを破棄し、ＲＬＣエンティティを同期化して、無線条件が許容されるとすぐにＤＵ送信が再開されるようにする。
【０１６４】
タイマーを使用する（またはタイマーのみを使用する）のではなく、明示的なシグナリングを使用する利点は、シグナリングがより積極的な処理を可能にし、タイマーの期限が切れるのを待たずに片方のレッグのスループットの問題に直ちに対処できることである。例として、デュアルコネクティビティシナリオでデータのフローを制御するノードは、無線条件または両方のレッグの輻輳などの他の変化についての知識を持っている場合もある。したがって、シグナリングにより、タイマーが切れるのを待たずに、必要に応じて良好なレグでデータの再送を開始し、他のデータを破棄および同期できるため、そもそも発生する問題を未然に防ぐことができる。
【０１６５】
したがって、任意の実施形態の更に別の関連する変形形態として、ＲＬＣ受信機としてのデバイス２００は、上述の制御ＰＤＵまたは同様の機能を備えたメッセージを使用して、Ｔ３満了時にアクションの詳細についてピアＲＬＣ送信機としてデバイス１００にクエリする、または通知することができる。当該アクションの詳細は、ＳＮおよび／またはそのウィンドウの同期を維持するためのデバイス１００および２００のペアに関連する。このような制御ＰＤＵまたはメッセージは、元の（第１の）および／または代替の（第２の）ＲＬＣレッグで送信され得る。
【０１６６】
上述の方法のいずれかは、デバイス１００が送信機としてＵＥによって具体化され、デバイス２００が受信エンティティとしてＲＡＮノードによって具体化されるという点で相互的であってもよい。
【０１６７】
デュアルコネクティビティの実施形態の更に別の変形では、方法３００は、ＵＥのアップリンクレッグ送信を制御するために実装される。デバイス１００を具体化するＲＡＮノード（ＰＤＣＰレイヤおよび／またはフロー制御が終了される、またはアンカーされる）は、ＵＥに確認応答を送信し、送信を一時停止し、データを同期し、他方のレッグにおけるデータ破棄するように指示する更に別の予約ビットを使用して、別のＲＬＣ制御メッセージを送信する。
【０１６８】
上記の実施形態のいずれにおいても、制御ＰＤＵは一度だけ、またはより適切に、制御メッセージを送信するノードとしてのデバイス１００は、同期の成功を保証するために、確認応答制御ＰＤＵを受信するまでそうし続けることができる。
【０１６９】
更に、デバイス１００の任意の実施形態において、ステータスレポートをポーリングするために使用されるＤＵは、より効率的に選択され得る。送信機としてのデバイス１００は、再送のためにＤＵを考慮するとき、SN VT_Aを有するＤＵを選択する。これは、上記から明らかなように、VT_Aを備えたＤＵがウィンドウを同期する支配的な役割を果たすという事実だけでなく、VT_Aが空中である最も古いＤＵであるため転送する最も緊急のＤＵであるという事実による利点である。
【０１７０】
ＮＲ実装では、閾値のバイト（pollByteなど）またはＤＵ（pollPDUなど）のいずれかに到達したとき、または新しいデータを送信できない（すなわち、ＬＴＥ実装と同様または同等の場合）ときに、ポーリング要求が送信され、タイマーt-PollRetransmitが開始される。しかし、タイマーt-PollRetransmitが満了し、デバイス１００のタイマーＴが実行中で、送信する新しいデータがまだない場合（例えば、ウィンドウのストールによる）、SN = VT_AのＤＵまたは未確認のＤＵ（すなわち、肯定的に確認されていない）は再送が考慮される。ポーリング要求が送信され、タイマーt-PollRetransmitが再び開始される。
【０１７１】
図１２は、デバイス１００の実施形態の概略ブロック図を示す。デバイス１００は、方法３００を実行するための１つ以上のプロセッサ１２０４と、プロセッサ１２０４に結合されたメモリ１２０６とを備える。例えば、メモリ１２０６は、モジュール１０２、１０４、および１０６のうちの少なくとも１つを実装する命令でエンコード（符号化）されてもよい。
【０１７２】
１つ以上のプロセッサ１２０４は、マイクロプロセッサ、コントローラ、マイクロコントローラ、中央処理ユニット、デジタル信号プロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、または他の適切なコンピューティングデバイス、リソース、またはハードウェアの組み合わせ、マイクロコード、および／またはメモリ１２０６といったデバイス１００の他の構成要素と組み合わせて送信局の機能を提供するように動作可能な符号化ロジックの１つまたは複数の組み合わせであり得る。例えば、１つ以上のプロセッサ１２０４は、メモリ９０６に格納された命令を実行してもよい。そのような機能は、本明細書で開示される利点のいずれかを含む、本明細書で説明される様々な特徴および工程（ステップ）を提供することを含み得る。「アクションを実行するように動作しているデバイス」という表現は、アクションを実行するように構成されているデバイス１００を示し得る。
【０１７３】
図１２に概略的に示されるように、デバイス１００は、送信局１２００によって具現化され得る。送信局１２００は、１つ以上の受信局との無線通信のためにデバイス１００に結合された無線インターフェース１２０２を備える。
【０１７４】
変形例では、例えば、図１３に概略的に示されるように、デバイス１００の機能は無線ネットワークのノードにより提供される。すなわち、ノードは方法３００を実行する。デバイス１００の機能は、例えばインターフェース１２０２または専用の有線または無線インターフェースを介して、ノードにより送信局１２００に提供される。
【０１７５】
図１４は、デバイス２００の実施形態の概略ブロック図を示す。デバイス２００は、方法４００を実行するための１つ以上のプロセッサ１４０４と、プロセッサ１４０４に結合されたメモリ１４０６とを備える。例えば、メモリ１４０６は、モジュール２０２、２０４、および２０６のうちの少なくとも１つを実装する命令でエンコードされてもよい。
【０１７６】
１つ以上のプロセッサ１４０４は、マイクロプロセッサ、コントローラ、マイクロコントローラ、中央処理ユニット、デジタル信号プロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、または他の適切なコンピューティングデバイス、リソース、またはハードウェアの組み合わせ、マイクロコード、および／またはメモリ１４０５といったデバイス２００の他の構成要素と組み合わせて送信局の機能を提供するように動作可能な符号化ロジックの１つまたは複数の組み合わせであり得る。例えば、１つ以上のプロセッサ１４０４は、メモリ１４０６に格納された命令を実行してもよい。  そのような機能は、本明細書で開示される利点のいずれかを含む、本明細書で説明される様々な特徴および工程（ステップ）を提供することを含み得る。「アクションを実行するように動作しているデバイス」という表現は、アクションを実行するように構成されているデバイス２００を示し得る。
【０１７７】
図１４に概略的に示されるように、デバイス２００は、受信局１４００によって具体化され得る。受信局１４００は、送信局との無線通信のためにデバイス２００に結合された無線インターフェース１４０２を備える。
【０１７８】
変形例では、例えば、図１５に概略的に示されるように、デバイス２００の機能は無線ネットワークのノードにより提供される。すなわち、ノードは方法４００を実行する。デバイス２００の機能は、例えばインターフェース１４０２または専用の有線または無線インターフェースを介して、ノードにより受信局１４００に提供される。
【０１７９】
上記の説明から明らかになったように、この技術の実施形態は、例えば、再送される可能性のある各データユニットのReTx_countの長くてコストのかかる追跡を維持する代わりに、無線ベアラごとに1つまたは少数のタイマーのみを維持することにより、メモリ効率が高い。その結果、実施形態の少なくともいくつかは、ＲＬＣ送信機がＲＬＣ無線ベアラごとに追跡するのに必要なメタデータがはるかに少なく、および／または、実装および維持がより簡単である。
【０１８０】
更に、更なる実施形態の同じものでは、より高いレイヤから見られるように、より低いレイヤで、より予測可能なタイミングの動作が達成される。あるいは、または更に、無線品質が非常に悪い場合にＲＬＦをトリガーするために必要なスケジューリングリソースがはるかに少なくなる。
【０１８１】
いくつかの有利な効果は、レート、したがってシーケンス番号スペースが大きくなるにつれて必要になる。これは、レガシーＬＴＥによりサポートされるものと比較して5G New Radioに対して予想される。
【０１８２】
更に、ＲＬＦを検出およびトリガーするために、この技術を任意のＲＬＣ受信器で実装することができる。例えばＵＥがＲＬＦ受信機の場合、受信機トリガーされたＲＬＦはより効率的である。なぜならば、ＵＥがＲＬＦを検出した場合、再確立手順をトリガーして新しいセルに接続できるためであり、 それは、ネットワークは、ＲＬＦを上位ネットワークレイヤに示す必要がある場合に、通常より効率的であり得る。
【０１８３】
更なる実施形態の同じものでは、無線ベアラに関連する無線問題についての指示の２つのレベル（またはそれ以上のレベル）を達成することができる。第１のレベルは、無線ベアラでの送信を一時的に停止または最小化するために使用され得るが、ＲＬＦをまだ宣言していない。第２のレベルは、ＲＬＦを宣言するために使用され得る。無線の問題を示すための中間の第１のレベルは、たとえば、データ送信を別の第２のＲＬＣレッグに切り替えるデュアルコネクティビティシナリオで役立ち、第２のレッグで正常に送信された場合、第１のレッグにおけるデータをクリアする。
【０１８４】
特に、２つの異なるＲＬＣレッグにデータユニットを分配するＰＤＣＰレイヤによってデュアルコネクティビティが実装される5G New Radioシステムの展開では、この技術により、再送に使用される時間に強い制限を設定し、ＤＵを別のＲＬＣレッグを介して転送する。従来のＬＴＥでは、ReTx_countがＲＬＦをトリガーするための再送の固定最大回数に到達しない限り、データユニットは破棄されないが、ＮＲの場合、デュアルコネクティビティははるかに一般的であるため、この技術により、ＲＬＣレッグの１つにおける一時的な悪い無線状態が原因で発生した頻繁なＲＬＦトリガーを回避することができる。
【０１８５】
中間の第１のレベルは、単一のコネクティビティのシナリオ、例えば、非常に悪い無線状態があるときにデータトラフィックを最小化する場合にも役立ち得る。
【０１８６】
本発明の多くの利点は、前述の説明から完全に理解され、本発明の範囲から逸脱することなく、本発明の範囲から逸脱することなく、および／またはその利点のすべてを犠牲にすることなく、ユニットおよびデバイスの形態、構造、および配置に様々な変更を加えることができることは明らかであろう。本発明は多くの方法で変更することができるため、本発明は添付の特許請求の範囲によってのみ制限されるべきであることが認識されるであろう。
【図１】
0006883372.tif 000002
【図２】
0006883372.tif 000003
【図３】
0006883372.tif 000004
【図４】
0006883372.tif 000005
【図５】
0006883372.tif 000006
【図６】
0006883372.tif 000007
【図７】
0006883372.tif 000008
【図８】
0006883372.tif 000009
【図９】
0006883372.tif 000010
【図１０】
0006883372.tif 000011
【図１１】
0006883372.tif 000012
【図１２】
0006883372.tif 000013
【図１３】
0006883372.tif 000014
【図１４】
0006883372.tif 000015
【図１５】
0006883372.tif 000016