JP2020509632A - 無線通信を監視するための技術 - Google Patents

無線通信を監視するための技術 Download PDF

Info

Publication number
JP2020509632A
JP2020509632A JP2019538673A JP2019538673A JP2020509632A JP 2020509632 A JP2020509632 A JP 2020509632A JP 2019538673 A JP2019538673 A JP 2019538673A JP 2019538673 A JP2019538673 A JP 2019538673A JP 2020509632 A JP2020509632 A JP 2020509632A
Authority
JP
Japan
Prior art keywords
communication path
rlc
timer
dus
state variable
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2019538673A
Other languages
English (en)
Other versions
JP6883372B2 (ja
Inventor
ガンナー ベルグクイスト，
ガンナー ベルグクイスト，
サミール シャー，
サミール シャー，
ミカエル ウィットバーグ，
ミカエル ウィットバーグ，
アンダース ジョンソン，
アンダース ジョンソン，
Original Assignee
テレフオンアクチーボラゲット エルエム エリクソン（パブル）
テレフオンアクチーボラゲット エルエム エリクソン（パブル）
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by テレフオンアクチーボラゲット エルエム エリクソン（パブル）, テレフオンアクチーボラゲット エルエム エリクソン（パブル） filed Critical テレフオンアクチーボラゲット エルエム エリクソン（パブル）
Publication of JP2020509632A publication Critical patent/JP2020509632A/ja
Application granted granted Critical
Publication of JP6883372B2 publication Critical patent/JP6883372B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1685—Details of the supervisory signal the supervisory signal being transmitted in response to a specific request, e.g. to a polling signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1628—List acknowledgements, i.e. the acknowledgement message consisting of a list of identifiers, e.g. of sequence numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1671—Details of the supervisory signal the supervisory signal being transmitted together with control information
    • H04L1/1678—Details of the supervisory signal the supervisory signal being transmitted together with control information where the control information is for timing, e.g. time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1848—Time-out mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/188—Time-out mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053—Allocation of signaling, i.e. of overhead other than pilot signals
    • H04L5/0055—Physical resource allocation for ACK/NACK
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0278—Traffic management, e.g. flow control or congestion control using buffer status reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/04—Error control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0002—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0015—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy
    • H04L1/0017—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy where the mode-switching is based on Quality of Service requirement

Landscapes

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

Abstract

データユニットを送信／受信するための無線リンク制御（ＲＬＣ）通信パスを監視するための方法およびデバイスが開示される。方法／デバイスは、ＲＬＣ通信パスで送信される／受信される１つ以上の未確認の／未処理のＤＵに対するタイマーに基づいて、ＲＬＣ通信パスの低下を決定することを含む、または決定することをトリガーする。【選択図】図３

Description

本開示は一般に、無線通信を監視するための技術に関する。より具体的には、無線リンク制御通信パスを監視するための方法とデバイスが提供される。
無線通信は、例えば、第３世代パートナーシッププロジェクト（３ＧＰＰ）で規定されたロングタームエヴォリューション（ＬＴＥ）によると、無線リンク制御（ＲＬＣ）確認応答（アクノレッジ）モード（ＡＭ）プロトコルを使用して、自動再送要求（ＡＲＱ）の手段によりパケットデータユニット（ＰＤＵ）を確実に配信する。送信側は、各ＲＬＣ ＰＤＵに関連付けられたＲＬＣシーケンス番号（ＳＮ）を使用してＲＬＣ ＰＤＵを送信し、ＲＬＣ ＰＤＵが正常に受信されたことを確認するためのステータスレポートを受信側にポーリングする。送信側のＡＭ ＲＬＣエンティティは、確認応答モードデータ（ＡＭＤ）ＰＤＵまたはＡＭＤＰＤＵの一部に対するピアＡＭ ＲＬＣ受信エンティティによる受信失敗の通知として、ステータスレポートで明示的な否定応答（ＮＡＣＫ）を受信でき、例えば、ＮＡＣＫが報告されたＲＬＣ ＳＮを持つＰＤＵの再送をトリガーする。例えば、送信側が受信側からのステータスレポートを待機してタイムアウトし、受信側をポーリングする必要があるが、ポーリングリクエストを送信するための新しいデータがない場合など、再送に対して暗黙的なトリガーもある。
ＡＭＤ ＰＤＵまたはその一部が再送される場合、ＬＴＥのＲＬＣプロトコルでは、送信側が各ＳＮに関連付けて１つの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がＲＬＦをトリガーするための再送の固定最大回数に到達しない限り、データユニットは破棄されないが、ＮＲの場合、デュアルコネクティビティははるかに一般的であるため、この技術により、ＲＬＣレッグの１つにおける一時的な悪い無線状態が原因で発生した頻繁なＲＬＦトリガーを回避することができる。
中間の第１のレベルは、単一のコネクティビティのシナリオ、例えば、非常に悪い無線状態があるときにデータトラフィックを最小化する場合にも役立ち得る。
本発明の多くの利点は、前述の説明から完全に理解され、本発明の範囲から逸脱することなく、本発明の範囲から逸脱することなく、および／またはその利点のすべてを犠牲にすることなく、ユニットおよびデバイスの形態、構造、および配置に様々な変更を加えることができることは明らかであろう。本発明は多くの方法で変更することができるため、本発明は添付の特許請求の範囲によってのみ制限されるべきであることが認識されるであろう。

Claims (58)

  1. データユニット（ＤＵ）を送信するための無線リンク制御（ＲＬＣ）通信パスを監視する方法（３００）であって、前記方法は、
    前記ＲＬＣ通信パスで送信された１つ以上の未確認のＤＵに対するタイマーに基づいて、前記ＲＬＣ通信パスの低下を決定する工程（３０４）を含む、またはトリガーする、方法。
  2. 請求項１に記載の方法であって、更に、
    確認応答モードにおいて前記ＲＬＣ通信パスで前記１つ以上のＤＵを送信する工程と、
    前記１つ以上のＤＵを送信すると前記タイマーを起動する工程、の少なくとも一方を含むまたはトリガーする、方法。
  3. 請求項２に記載の方法であって、前記ＲＬＣ通信パスで以前に送信された全てのＤＵが確認された場合に、前記１つ以上のＤＵを送信すると前記タイマーが起動される、方法。
  4. 請求項１から３のいずれか１項に記載の方法であって、前記タイマーは、前記１つ以上の送信されたＤＵの少なくとも１つが未確認である限り、維持される、方法。
  5. 請求項１から４のいずれか１項に記載の方法であって、前記タイマーは、前記ＲＬＣ通信パスで送信された前記１つ以上の未確認のＤＵに対する確認応答を受信すると、停止および／または再起動される、方法。
  6. 請求項１から５のいずれか１項に記載の方法であって、前記タイマーは、前記ＲＬＣ通信パスでの前記１つ以上の未確認のＤＵの最も早い送信、または前記ＲＬＣ通信パスで送信された前記未確認のＤＵの中で最も古いＤＵの送信、からの経過時間を示す、方法。
  7. 請求項６に記載の方法であって、前記ＲＬＣ通信パスで送信された前記未確認のＤＵの中の最も古いＤＵは、前記ＲＬＣ通信パスで送信された前記未確認のＤＵの中の最も早い送信におけるＤＵである、方法。
  8. 請求項１から７のいずれか１項に記載の方法であって、前記送信されたＤＵのそれぞれは、シーケンス番号（ＳＮ）が含まれる、または、関連付けられる、方法。
  9. 請求項８および請求項６または７に記載の方法であって、前記ＲＬＣ通信パスで送信された前記未確認のＤＵの中で最も古いＤＵは、前記ＲＬＣ通信パスで送信された前記未確認のＤＵの中で最小のＳＮを含む、または、関連付けられる、方法。
  10. 請求項８または９に記載の方法であって、更に、
    前記ＲＬＣ通信パスでの前記未確認のＤＵの最も早い送信のＳＮ、または前記ＲＬＣ通信パスで送信された前記未確認のＤＵの中の最も古いＤＵのＳＮを示す第１の状態変数（５０２）を維持する工程を含む、またはトリガーする、方法。
  11. 請求項１０に記載の方法であって、前記タイマーは、前記第１の状態変数（５０２）が変更されない限り、維持される、方法。
  12. 請求項１０または１１に記載の方法であって、前記第１の状態変数（５０２）を維持することは、前記第１の状態変数（５０２）によって示される前記ＳＮを含むまたは当該ＳＮに関連付けられるＤＵに対する確認応答を受信すると、前記第１の状態変数（５０２）を進めることを含む、方法。
  13. 請求項１０から１２のいずれか１項に記載の方法であって、前記タイマーは、前記第１の状態変数（５０２）によって示されるＳＮを含むまたは当該ＳＮに関連付けられたＤＵに対する確認応答を受信するか、前記第１の状態変数（５０２）を進めると、停止および／または再起動される、方法。
  14. 請求項８から１３のいずれか１項に記載の方法であって、
    次に送信される前記ＤＵの前記ＳＮを示す第２の状態変数（５０４）を維持する工程を含む、またはトリガーする、方法。
  15. 請求項１４に記載の方法であって、更に、前記第２の状態変数（５０４）を維持することは、前記次のＤＵを送信すると前記第２の状態変数（５０４）を進めることを含む、方法。
  16. 請求項１から１５のいずれか１項に記載の方法であって、前記タイマーは、前記ＲＬＣ通信パスで送信された前記未確認のＤＵの中で最も古いＤＵが未確認である限り、維持される、方法。
  17. 請求項１から１６のいずれか１項に記載の方法であって、前記タイマーは、前記ＲＬＣ通信パスで送信された前記未確認のＤＵの中で最も古いＤＵに対する確認応答を受信すると、停止および／または再起動される、方法。
  18. 請求項５、１３、および１７のいずれか１項に記載の方法であって、前記タイマーを再起動することは、前記タイマーをゼロに設定することを含む、方法。
  19. 請求項５、１３、および１７のいずれか１項に記載の方法であって、前記タイマーを再起動することは、前記送信され未確認のＤＵの中で２番目に古いＤＵを送信してから経過した時間に従って前記タイマーを起動することを含む、方法。
  20. 請求項１から１９のいずれか１項に記載の方法であって、前記送信されたＤＵの少なくとも１つに対する確認応答または否定応答がステータスレポートにおいて受信される、方法。
  21. 請求項２０に記載の方法であって、前記タイマーが停止されているか、まだ維持されていない場合、前記タイマーは、前記ステータスレポートに対するポーリング要求を送信すると起動される、方法。
  22. 請求項２１に記載の方法であって、前記ポーリング要求は、前記ＲＬＣ通信パスで送信された前記未確認のＤＵの中の最も古いＤＵを使用して送信される、方法。
  23. 請求項１から２２のいずれか１項に記載の方法であって、前記低下は、前記タイマーの少なくとも１つの期間が経過すると決定される、方法。
  24. 請求項１から２３のいずれか１項に記載の方法であって、前記１つ以上のＤＵの送信を回復するための測定は、前記タイマーの少なくとも１つの期間が経過するとトリガーされる、方法。
  25. 請求項１から２４のいずれか１項に記載の方法であって、前記低下を決定すること、および／または、前記測定をトリガーすることは、通信プロトコルスタックの上位レイヤまたは下位レイヤに前記低下を示すことを含む、方法。
  26. 請求項１から２５のいずれか１項に記載の方法であって、前記低下を決定することは、前記タイマーの第１の期間が経過すると、無線リンク障害（ＲＬＦ）を決定する、または示すことを含む、方法。
  27. 請求項１から２６のいずれか１項に記載の方法であって、前記低下を決定することは、前記タイマーの少なくとも１つの第２の期間が経過すると、
    前記ＲＬＣ通信パスにおけるＤＵの送信を削減または中断すること、
    スケジューリング要求またはスケジューリング割り当ての送信のレートを削減または当該送信を中断すること、
    バッファステータスレポートの送信のレートを削減または当該送信を中断すること、
    前記ＲＬＣ通信パスにより使用される物理チャネルに対するチャネル品質インジケータを削減すること、
    前記第２の状態変数（５０４）に等しくなるように前記第１の状態変数（５０２）を進めること、
    前記ＲＬＣ通信パスで送信された確認済みのＤＵに続く次の未確認のＤＵのＳＮへ、第１の状態変数（５０２）を進めること、および、
    前記ＲＬＣ通信パスから別のＲＬＣ信パスへ切り替えること、
    の少なくともいずれかを含む、方法。
  28. 請求項２６または２７に記載の方法であって、前記第１の期間と前記第２の期間の少なくとも一方は、品質の要件に依存する、方法。
  29. 請求項２８に記載の方法であって、前記品質の要件は、
    １つ以上のＤＵ、
    ＤＵを送信または受信するための無線アクセスノード、
    前記ＲＬＣ通信パスまたは前記１つ以上のＤＵのベアラ、
    前記１つ以上のＤＵのペイロードを提供するアプリケーションまたはサービス、
    のうちの少なくとも１つに関連付けられ得る、方法。
  30. 請求項１２、１３、１５、または２６に記載の方法であって、前記第１の状態変数（５０２）を進めること、前記第２の状態変数（５０４）を進めること、および前記ＲＬＣ通信パスを切り替えることのうちの少なくとも１つは、ＲＬＣ通信ピアにシグナリングされる、方法。
  31. 請求項１から３０のいずれか１項に記載の方法であって、無線アクセスネットワーク（ＲＡＮ）の無線アクセスノードによって実行される、方法。
  32. 請求項１から３０のいずれか１項に記載の方法であって、ＲＡＮに接続された、または接続可能な、無線端末によって実行される、方法。
  33. データユニット（ＤＵ）を受信するための無線リンク制御（ＲＬＣ）通信パスを監視する方法（４００）であって、前記方法は、
    前記ＲＬＣ通信パスで受信される１つ以上の未処理のＤＵに対するタイマーに基づいて、前記ＲＬＣ通信パスの低下を決定する工程（４０４）を含む、またはトリガーする方法。
  34. 請求項３３に記載の方法であって、受信される各ＤＵは、シーケンス番号ＳＮを含むかまたは関連付けられ、前記１つ以上の未処理のＤＵのＳＮは、前記ＲＬＣ通信パスで受信された少なくとも１つのＤＵのＳＮよりも小さい、方法。
  35. 請求項３４に記載の方法であって、前記タイマーは、ＳＮが前記ＲＬＣ通信パスで順番に受信されたＤＵとのギャップを有する少なくとも１つのＤＵを受信すると起動される、方法。
  36. 請求項３４または３５に記載の方法であって、更に、
    前記ＲＬＣ通信パスで順番に受信されたＤＵの最も高いＳＮに続くＳＮを示す第３の状態変数（１１０２）を維持する工程を含む、またはトリガーする方法。
  37. 請求項３４から３６のいずれか１項に記載の方法であって、更に、
    前記ＲＬＣ通信パスで受信されたＤＵの最も高いＳＮに続くＳＮを示す第４の状態変数（１１０４）を維持する工程を含む、またはトリガーする方法。
  38. 請求項３６または３７に記載の方法であって、前記１つ以上の未処理のＤＵのＳＮは、第３の状態変数（１１０２）以上であり、第４の状態変数（１１０４）未満である、方法。
  39. 請求項３６または３７に記載の方法であって、前記第４の状態変数（１１０４）が前記第３の状態変数（１１０２）よりも大きい限り、前記タイマーが維持される、方法。
  40. 少なくとも請求項３６または３７に記載の方法であって、前記第４の状態変数（１１０４）が前記第３の状態変数（１１０２）に等しい場合、前記タイマーが停止される、方法。
  41. 請求項３６または３７に記載の方法であって、前記第３の状態変数（１１０２）が前記第４の状態変数（１１０４）よりも小さいＳＮに進む場合、前記タイマーが再起動される、方法。
  42. 請求項１から４１のいずれか１項に記載の方法であって、前記低下を決定することは、前記タイマーの少なくとも３分の１期間が経過すると、
    スケジューリング許可の送信のレートを削減または当該送信を中断すること、
    前記ＲＬＣ通信パスにより使用される物理チャネルに対するチャネル品質インジケータを削減すること、
    前記第４の状態変数（１１０４）に等しくなるように前記第３の状態変数（１１０２）を進めること、
    前記ＲＬＣ通信パスで受信されたＤＵに続く次の未処理のＤＵのＳＮに第３の状態変数（１１０２）を進めること、および、
    前記ＲＬＣ通信パスから別のＲＬＣ信パスへ切り替えること、
    の少なくともいずれかを含む、方法。
  43. 請求項４２に記載の方法であって、第３の状態変数（１１０２）を進めること、および／または、前記ＲＬＣ通信パスを切り替えることは、ＲＬＣ通信ピアによってシグナリングされる、方法。
  44. 請求項３３から４３に記載の方法であって、請求項２から３２のいずれか１項のいずれかに記載の工程またはその対応する受信工程を更に含む、またはトリガーする方法。
  45. コンピュータプログラム製品であって、前記コンピュータプログラム製品が１つ以上のコンピューティングデバイス（１２０４；１４０４）によって実行されるときに、請求項１から４４のいずれか１項に記載の工程を実行するためのプログラムコード部分を含む、コンピュータプログラム製品。
  46. 請求項４５に記載のコンピュータプログラム製品であって、コンピュータ可読記録媒体（１２０６；１４０６）に格納される、コンピュータプログラム製品。
  47. データユニット（ＤＵ）を送信するための無線リンク制御（ＲＬＣ）通信パスを監視するためのデバイス（１００）であって、前記デバイス（１００）は、
    前記ＲＬＣ通信パスで送信された１つ以上の未確認のＤＵに対するタイマーに基づいて、前記ＲＬＣ通信パスの低下を決定する工程を実行するように構成される、デバイス。
  48. 請求項４７に記載のデバイスであって、請求項２から３２のいずれか１項に記載の工程を実行するように構成される、デバイス。
  49. データユニット（ＤＵ）を受信するための無線リンク制御（ＲＬＣ）通信パスを監視するためのデバイス（２００）であって、前記デバイス（２００）は、
    前記ＲＬＣ通信パスで受信される１つ以上の未処理のＤＵに対するタイマーに基づいて、前記ＲＬＣ通信パスの低下を決定する工程を実行するように構成される、デバイス。
  50. 請求項４９に記載のデバイスであって、請求項３４から４４のいずれか１項に記載の工程を実行するように構成される、デバイス。
  51. データユニット（ＤＵ）を送信するために無線リンク制御（ＲＬＣ）通信パスを監視するためのデバイス（１００）であって、前記デバイス（１００）は、少なくとも１つのプロセッサ（１２０４）とメモリ（１２０６）を含み、前記メモリ（１２０６）は前記少なくとも１つのプロセッサ（１２０４）によって実行可能な命令を備え、それにより、デバイス（１００）は、
    前記ＲＬＣ通信パスで送信された１つ以上の未確認のＤＵに対するタイマーに基づいて、前記ＲＬＣ通信パスの低下を決定するように動作する、デバイス。
  52. 請求項５１に記載のデバイスであって、更に請求項２から３２のいずれか１項に記載の工程を実行するように動作する、デバイス。
  53. データユニット（ＤＵ）を受信するために無線リンク制御（ＲＬＣ）通信パスを監視するための装置（２００）であって、前記装置（２００）は、少なくとも１つのプロセッサ（１４０４）とメモリ（１４０６）を含み、前記メモリ（１２０６）は前記少なくとも１つのプロセッサ（１４０４）によって実行可能な命令を備え、それにより、デバイス（２００）は、
    ＲＬＣ通信パスで受信される１つ以上の未処理のＤＵに対するタイマーに基づいて、ＲＬＣ通信パスの低下を決定するように動作する、デバイス。
  54. 請求項５３に記載のデバイスであって、更に請求項３４から４４のいずれか１項に記載の工程を実行するように動作する、デバイス。
  55. データユニット（ＤＵ）を送信するための無線リンク制御（ＲＬＣ）通信パスを監視するためのデバイス（１００）であって、
    前記ＲＬＣ通信パスで送信された１つ以上の未確認のＤＵに対するタイマーに基づいて、前記ＲＬＣ通信パスの低下を決定するための決定モジュール（１０４）を備える、デバイス。
  56. 請求項５５に記載のデバイスであって、更に、請求項２から３２のいずれか１つの工程を実行するための１つ以上のモジュールを更に備える、デバイス。
  57. データユニット（ＤＵ）を受信するための無線リンク制御（ＲＬＣ）通信パスを監視するためのデバイス（２００）であって、前記デバイス（２００）は、
    ＲＬＣ通信パスで受信される１つ以上の未処理のＤＵに対するタイマーに基づいてＲＬＣ通信パスの低下を決定するための決定モジュール（２０４）を備える、デバイス。
  58. 請求項５７に記載のデバイス（２００）であって、請求項３４から４４のいずれか１項の工程を実行するための１つ以上のモジュールを有する、デバイス。
JP2019538673A 2017-02-13 2017-11-16 無線通信を監視するための技術 Active JP6883372B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201762458177P 2017-02-13 2017-02-13
US62/458,177 2017-02-13
PCT/EP2017/079459 WO2018145787A1 (en) 2017-02-13 2017-11-16 Technique for monitoring a radio communication

Publications (2)

Publication Number Publication Date
JP2020509632A true JP2020509632A (ja) 2020-03-26
JP6883372B2 JP6883372B2 (ja) 2021-06-09

Family

ID=60382219

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019538673A Active JP6883372B2 (ja) 2017-02-13 2017-11-16 無線通信を監視するための技術

Country Status (7)

Country Link
US (2) US10531321B2 (ja)
EP (1) EP3580873B8 (ja)
JP (1) JP6883372B2 (ja)
KR (2) KR102397625B1 (ja)
CN (1) CN110268657B (ja)
MX (1) MX2019009533A (ja)
WO (1) WO2018145787A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022081073A1 (en) * 2020-10-16 2022-04-21 Telefonaktiebolaget Lm Ericsson (Publ) Packet transmission and reception in a wireless communication network

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108809542B (zh) * 2017-05-05 2021-04-20 华为技术有限公司 一种数据传输的处理方法和装置
CN109905206A (zh) * 2017-12-07 2019-06-18 夏普株式会社 无线通信方法和设备
EP3629505A1 (en) * 2018-09-25 2020-04-01 Panasonic Intellectual Property Corporation of America User equipment and base station involved in transmission of data
CN110944352B (zh) 2018-09-25 2022-11-01 维沃移动通信有限公司 一种旁链路的链路失败检测方法及终端
CN111526599B (zh) 2019-02-01 2022-05-31 华为技术有限公司 一种无线资源控制rrc消息发送方法及装置
US20220150730A1 (en) * 2019-02-12 2022-05-12 Idac Holdings, Inc. Method for sidelink radio link monitoring and determining radio link failure
CN111800886B (zh) * 2019-07-12 2022-04-08 维沃移动通信有限公司 一种随机接入过程回退方法、设备及***
US20240023160A1 (en) * 2019-11-07 2024-01-18 Telefonaktiebolaget Lm Ericsson (Publ) Methods, Apparatus and Machine-Readable Media Relating to Reporting Failure in a Wireless Network
CN115606314A (zh) * 2021-05-10 2023-01-13 苹果公司（Us） 在使用高频谱的情况下处理协议栈中的高数据速率

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070268861A1 (en) * 2006-05-16 2007-11-22 Diachina John W Bi-Directional RLC Non-Persistent Mode for Low Delay Services
JP2014131361A (ja) * 2007-10-01 2014-07-10 Interdigital Patent Holdings Inc Ｐｄｃｐ破棄の方法および装置

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6519223B1 (en) * 1999-04-06 2003-02-11 Telefonaktiebolaget L M Ericsson (Publ) System and method for implementing a semi reliable retransmission protocol
SE0301048D0 (sv) * 2003-04-07 2003-04-07 Ericsson Telefon Ab L M RLC window reconfiguration
CN102412936A (zh) * 2006-10-23 2012-04-11 交互数字技术公司 无线发射/接收单元、方法和无线网络设备
US8208394B2 (en) * 2007-10-30 2012-06-26 Qualcomm Incorporated Service data unit discard timers
PT3113403T (pt) * 2007-11-02 2022-02-07 Ericsson Telefon Ab L M Métodos e aparelho para processar mensagens de controlo de erro num sistema de comunicação sem fios
CN101478380B (zh) * 2008-01-03 2013-02-27 中兴通讯股份有限公司 一种自动重传请求窗口管理方法
EP2086142A3 (en) * 2008-02-04 2012-10-10 LG Electronics Inc. Wireless communication method for transmitting a sequence of data units between a wireless device and a network
KR101606205B1 (ko) * 2008-08-21 2016-03-25 엘지전자 주식회사 무선통신 시스템에서 상태 보고 유발 방법 및 수신기
US8295159B2 (en) * 2009-01-14 2012-10-23 Qualcomm Incorporated Timer poll retransmission expiry in a wireless communication system
CN101989899B (zh) * 2009-07-31 2013-12-18 中兴通讯股份有限公司 一种无线链路控制层触发状态报告的方法及接收侧装置
CA2813161C (en) 2010-09-30 2019-05-14 Kossan Sdn Bhd Elastomer rubber which does not use sulfur and vulcanization accelerator and elastomer rubber product
US9461776B2 (en) * 2012-01-27 2016-10-04 Blackberry Limited Selecting a data unit for retransmission
CN103701572A (zh) * 2012-09-27 2014-04-02 普天信息技术研究院有限公司 一种指示信道质量的方法和装置
US9432251B2 (en) * 2013-03-08 2016-08-30 Qualcomm Incorporated Enhanced acknowledgement and retransmission mechanism
US9942846B2 (en) * 2013-12-05 2018-04-10 Qualcomm Incorporated Delaying radio link control retransmissions
US9854478B2 (en) * 2014-01-17 2017-12-26 Qualcomm Incorporated Techniques for switching bearers between radio access technologies (RATS)
CN105379342B (zh) * 2014-02-28 2019-11-29 华为技术有限公司 一种数据重传的方法和装置
WO2018166042A1 (zh) * 2017-03-14 2018-09-20 北京小米移动软件有限公司 数据单元传输方法及装置
US10750562B2 (en) * 2018-02-02 2020-08-18 Ofinno, Llc Connection failure report considering bandwidth

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070268861A1 (en) * 2006-05-16 2007-11-22 Diachina John W Bi-Directional RLC Non-Persistent Mode for Low Delay Services
CN101444033A (zh) * 2006-05-16 2009-05-27 艾利森电话股份有限公司 用于低延迟业务的双向rlc非持久模式
JP2009538011A (ja) * 2006-05-16 2009-10-29 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 低遅延サービスのための双方向ｒｌｃ非永続モード
JP2014131361A (ja) * 2007-10-01 2014-07-10 Interdigital Patent Holdings Inc Ｐｄｃｐ破棄の方法および装置

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022081073A1 (en) * 2020-10-16 2022-04-21 Telefonaktiebolaget Lm Ericsson (Publ) Packet transmission and reception in a wireless communication network

Also Published As

Publication number Publication date
KR20210052581A (ko) 2021-05-10
CN110268657B (zh) 2022-05-27
CN110268657A (zh) 2019-09-20
US20200128416A1 (en) 2020-04-23
US10531321B2 (en) 2020-01-07
EP3580873A1 (en) 2019-12-18
KR20190104399A (ko) 2019-09-09
US11039328B2 (en) 2021-06-15
US20180310192A1 (en) 2018-10-25
EP3580873B1 (en) 2021-10-20
WO2018145787A1 (en) 2018-08-16
MX2019009533A (es) 2019-09-16
EP3580873B8 (en) 2021-12-01
KR102397625B1 (ko) 2022-05-12
JP6883372B2 (ja) 2021-06-09

Similar Documents

Publication Publication Date Title
JP6883372B2 (ja) 無線通信を監視するための技術
EP3011705B1 (en) Polling and reporting mechanism
JP5357295B2 (ja) 無線通信システムにおけるエラー制御メッセージを処理するための方法及び装置
JP5351329B2 (ja) 無線通信システムにおいて１対多サービスを受信する方法及び端末
KR101306724B1 (ko) 이동통신 시스템에서의 제어 정보 전송 방법 및 이를구현하는 전송 장치
US9461776B2 (en) Selecting a data unit for retransmission
US20120163304A1 (en) Data transmission method and data re-transmission method
CN106068018B (zh) 在从中断场景重新开始期间进行吞吐量恢复的方法和设备
EP3111579B1 (en) Method and apparatus for triggering acknowledgement status report in wireless communications system
KR20090083867A (ko) Ｒｌｃ 무한 재전송 오류를 검출하고 처리하는 방법
EP3335463A1 (en) Predictive adaptive queue management
US20090181703A1 (en) Method and Apparatus for Triggering Status Report in a Wireless Communications System
RU2392752C2 (ru) Способ передачи данных и способ повторной передачи данных
WO2009082848A1 (fr) Procédé de réinitialisation d'entité de commande de liaison radio
EP2818003B1 (en) Method and base station for controlling wireless communication of data
WO2019193734A1 (ja) 通信装置

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190830

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190830

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20200813

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200821

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20201109

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210409

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210506

R150 Certificate of patent or registration of utility model

Ref document number: 6883372

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250