特許 7523576 無線通信システムおよびユーザのための装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-07-18

(45)【発行日】2024-07-26

(54)【発明の名称】無線通信システムおよびユーザのための装置

(51)【国際特許分類】

   H04W 76/18 20180101AFI20240719BHJP

   H04W 24/04 20090101ALI20240719BHJP

   H04W 72/231 20230101ALI20240719BHJP

【ＦＩ】

H04W76/18

H04W24/04

H04W72/231

【請求項の数】 20

(21)【出願番号】P 2022564139

(86)(22)【出願日】2020-04-23

(65)【公表番号】

(43)【公表日】2023-05-31

(86)【国際出願番号】 CN2020086500

(87)【国際公開番号】W WO2021212437

(87)【国際公開日】2021-10-28

【審査請求日】2022-12-19

(73)【特許権者】

【識別番号】515076873

【氏名又は名称】ノキア テクノロジーズ オサケユイチア

(74)【代理人】

【識別番号】100094112

【弁理士】

【氏名又は名称】岡部 讓

(74)【代理人】

【識別番号】100106183

【弁理士】

【氏名又は名称】吉澤 弘司

(74)【代理人】

【識別番号】100114915

【弁理士】

【氏名又は名称】三村 治彦

(74)【代理人】

【識別番号】100125139

【弁理士】

【氏名又は名称】岡部 洋

(74)【代理人】

【識別番号】100209808

【弁理士】

【氏名又は名称】三宅 高志

(72)【発明者】

【氏名】ジ，リアンハイ

(72)【発明者】

【氏名】ラセルヴァ，ダニエラ

(72)【発明者】

【氏名】ウ，チュンリ

(72)【発明者】

【氏名】セビール，ブノワ

【審査官】鈴木 重幸

(56)【参考文献】

【文献】米国特許出願公開第２０２０／００５３８２６（ＵＳ，Ａ１）

【文献】ZTE Corporation, Sanechips, Intel Corporation, CATT，Updates to reestablishment procedure[online]，3GPP TSG RAN WG2 #109bis-e R2-2002970，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_109bis-e/Docs/R2-2002970.zip>，2020年04月09日

【文献】Ericsson，Correction on RLC retransmissions at RLC failure in CA duplication[online]，3GPP TSG RAN WG2 #103 R2-1811883，Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_103/Docs/R2-1811883.zip>，2018年08月09日

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｂ ７／２４－ ７／２６

Ｈ０４Ｗ ４／００－９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１，４

(57)【特許請求の範囲】

【請求項1】

無線通信システム（１０）用の装置（１００）であって、少なくとも１つのプロセッサ（１０２）と、
前記少なくとも１つのプロセッサ（１０２）によって実行されたときに、装置（１００）に、ユーザ機器が、前記ユーザ機器に関連する第１の論理チャネルのＲＬＣ障害にどのように対応すべきかを定義する無線リンク制御（ＲＬＣ）障害構成（ＲＬＣ－ＦＣＦＧ）で前記ユーザ機器（２００）を少なくとも構成させる命令を格納するメモリ（１０４）と
を備え、
前記ＲＬＣ障害構成（ＲＬＣ－ＦＣＦＧ）が、少なくとも１つの優先度しきい値（Ｐ１、Ｐ２）を含み、前記ユーザ機器（２００）は、少なくとも１つの前記優先度しきい値（Ｐ１、Ｐ２）と、（ａ）前記ユーザ機器に関連する論理チャネルの最低優先度、および（ｂ）前記第１の論理チャネルの優先度のうちの少なくとも１つに基づいて、前記ＲＬＣ障害をネットワークまたは前記ネットワークに送信するかどうかを決定する装置。

【請求項2】

前記ＲＬＣ障害構成（ＲＬＣ－ＦＣＦＧ）は、前記ユーザ機器（２００）が前記第１の論理チャネルの前記ＲＬＣ障害をネットワーク（１０）に通知すべきかどうかを定義する、請求項１に記載の装置（１００）。

【請求項3】

前記ＲＬＣ障害構成（ＲＬＣ－ＦＣＦＧ）は、前記ユーザ機器（２００）に関連する少なくとも第２の論理チャネルが正常に動作したときに、前記ユーザ機器（２００）が前記第１の論理チャネルの前記ＲＬＣ障害をネットワーク（１０）に通知すべきかどうかを定義する、請求項１または２に記載の装置（１００）。

【請求項4】

前記命令は、少なくとも１つの前記プロセッサ（１０２）によって実行されると、前記装置（１００）にさらに、ユーザ機器（２００）をＲＬＣ障害構成（ＲＬＣ－ＦＣＦＧ）で明示的に構成させる、請求項１～３のいずれか１項に記載の装置（１００）。

【請求項5】

前記ＲＬＣ障害構成（ＲＬＣ－ＦＣＦＧ）が第１のしきい値（Ｔ１）を含み、前記ユーザ機器（２００）は、第１のしきい値（Ｔ１）に基づいて、ＲＬＣ障害をネットワークまたは前記ネットワークに送信するかどうかを決定することができる、請求項１～４のいずれか１項に記載の装置（１００）。

【請求項6】

前記ＲＬＣ障害構成（ＲＬＣ－ＦＣＦＧ）が、前記第１の論理チャネルについての少なくとも１つのマッピング制限を無効にするかどうかを前記ユーザ機器（２００）に示す第１の制御情報（ＣＩ１）を含む、請求項１～５のいずれか１項に記載の装置（１００）。

【請求項7】

前記第１の制御情報（ＣＩ１）が、複数のマッピング制限のうちどれを無効にするかを示す、請求項６に記載の装置（１００）。

【請求項8】

少なくとも１つの前記プロセッサ（１０２）によって実行されると、前記命令は、前記装置（１００）にさらに、
（ａ）前記ユーザ機器は、前記第１の論理チャネルの前記ＲＬＣ障害の検出時に無線リンク障害を宣言すべきである、
（ｂ）前記ユーザ機器は、前記第１の論理チャネルの前記ＲＬＣ障害を前記ネットワークに送信すべきである、
（ｃ）前記ユーザ機器は、前記第１の論理チャネル以外の少なくとも１つの論理チャネルのＲＬＣ障害の検出時に無線リンク障害を宣言すべきである、および
（ｄ）前記ユーザ機器は、少なくとも１つの他の前記論理チャネルの前記ＲＬＣ障害を前記ネットワークに送信すべきである、
の内の少なくとも１つを示す第２の制御情報（ＣＩ２）で前記ユーザ機器を設定させる、請求項１～７のいずれか１項に記載の装置（１００）。

【請求項9】

前記命令は、少なくとも１つの前記プロセッサ（１０２）によって実行されると、前記装置（１００）に、さらに、少なくとも１つのユーザ機器固有の条件に基づいて、前記ＲＬＣ障害構成（ＲＬＣ－ＦＣＦＧ）の少なくとも一部を設定させる、請求項１～８のいずれか１項に記載の装置（１００）。

【請求項10】

前記命令は、少なくとも１つの前記プロセッサ（１０２）によって命令が実行されると、前記装置（１００）に、さらに、前記ＲＬＣ障害構成（ＲＬＣ－ＦＣＦＧ）の少なくとも一部をブロードキャストさせる、請求項１～９のいずれか１項に記載の装置（１００）。

【請求項11】

少なくとも１つのプロセッサ（２０２）と、命令（２０６）を格納するメモリ（２０４）とを含むユーザ機器（２００）であって、前記命令は、少なくとも１つの前記プロセッサ（２０２）によって実行されたときに、ユーザ機器（２００）に、前記ユーザ機器（２００）に関連付けられた第１の論理チャネルのＲＬＣ障害に対して前記ユーザ機器（２００）がどのように対処すべきかを定義する無線リンク制御（ＲＬＣ）障害構成（ＲＬＣ－ＦＣＦＧ）を少なくとも決定（３５０）させ、
前記ＲＬＣ障害構成（ＲＬＣ－ＦＣＦＧ）が、少なくとも１つの優先度しきい値（Ｐ１、Ｐ２）を含み、前記命令が、少なくとも１つの前記プロセッサ（２０２）によって実行されると、前記ユーザ機器（２００）に、さらに、少なくとも１つの前記優先度しきい値（Ｐ１、Ｐ２）と、
（ａ）前記ユーザ機器に関連する論理チャネルの最低優先度、および
（ｂ）前記第１の論理チャネルの優先度
のうちの少なくとも１つに基づいて、前記ＲＬＣ障害をネットワークまたは前記ネットワークに送信するかどうかを決定させる、ユーザ機器（２００）。

【請求項12】

前記命令は、少なくとも１つの前記プロセッサ（２０２）によって実行されると、前記ユーザ機器（２００）に、さらに、前記ＲＬＣ障害構成（ＲＬＣ－ＦＣＦＧ）に基づいて、前記ユーザ機器（２００）がネットワーク（１０）に前記第１の論理チャネルの前記ＲＬＣ障害を通知すべきかどうかを決定（３５２）させる、請求項１１に記載のユーザ機器（２００）。

【請求項13】

前記命令は、少なくとも１つの前記プロセッサ（２０２）によって実行されると、前記ユーザ機器（２００）に、さらに、前記ユーザ機器（２００）に関連する少なくとも第２の論理チャネルが正常に動作したときに、前記ユーザ機器（２００）がネットワーク（１０）に前記第１の論理チャネルの前記ＲＬＣ障害を通知すべきかどうかを、前記ＲＬＣ障害構成（ＲＬＣ－ＦＣＦＧ）に基づいて決定（３５２）させる、請求項１１または１２に記載のユーザ機器（２００）。

【請求項14】

前記命令は、少なくとも１つの前記プロセッサ（２０２）によって実行されると、前記ユーザ機器（２００）に、さらに、少なくとも１つの論理チャネルに対して許可されたセルの構成に基づいて、無線リンク制御（ＲＬＣ）障害構成（ＲＬＣ－ＦＣＦＧ）を決定（３６０）させる、請求項１１～１３のいずれか１項に記載のユーザ機器（２００）。

【請求項15】

前記ＲＬＣ障害構成（ＲＬＣ－ＦＣＦＧ）は、第１のしきい値（Ｔ１）を含み、前記命令は、少なくとも１つの前記プロセッサ（２０２）によって実行されると、前記ユーザ機器（２００）に、さらに、前記第１のしきい値（Ｔ１）に基づいて、前記ＲＬＣ障害をネットワークまたは前記ネットワークに送信するかどうかを決定（３６２）させる、請求項１１～１４のいずれか１項に記載のユーザ機器（２００）。

【請求項16】

前記ＲＬＣ障害構成（ＲＬＣ－ＦＣＦＧ）は、少なくとも１つのマッピング制限を無効にするかどうかを前記ユーザ機器（２００）に示す第１の制御情報（ＣＩ１）を含み、
前記命令は、少なくとも１つの前記プロセッサ（２０２）によって実行されると、前記ユーザ機器（２００）に、さらに、前記第１の制御情報（ＣＩ１）に基づいて、少なくとも１つの前記マッピング制限を無効（３６４）にさせる、請求項１１～１５のいずれか１項に記載のユーザ機器（２００）。

【請求項17】

前記命令は、少なくとも１つの前記プロセッサ（２０２）によって実行されると、前記ユーザ機器（２００）に、さらに、
論理チャネルについて所定の数のＲＬＣ再送に達した場合に、第１のセルによって提供される前記論理チャネルについて前記所定の数のＲＬＣ再送に達したかどうかを判定させ、
前記第１のセルによって提供される少なくとも１つのさらなる論理チャネルが所定の数のＲＬＣ再送に達していない場合に、前記論理チャネルについての前記ＲＬＣ障害を前記ネットワークに送信させる、請求項１１～１６のいずれか１項に記載のユーザ機器（２００）。

【請求項18】

前記命令は、少なくとも１つの前記プロセッサ（２０２）によって実行されると、前記ユーザ機器（２００）に、さらに、第１品質しきい値よりも良好な無線チャネル品質を持つ別のセルを再選択できるかどうかを決定させ、
前記第１品質しきい値よりも良好な無線チャネル品質を持つ別のセルを再選択できる場合は、前記他のセルとの無線リソース制御（ＲＲＣ）接続を再確立させ、
前記第１品質しきい値よりも良好な無線チャネル品質を持つ別のセルを再選択できない場合は、前記ＲＬＣ障害構成（ＲＬＣ－ＦＣＦＧ）に基づいて、ＲＬＣ障害レポートを現在のサービングセルに送信するかどうかを決定させる、請求項１１～１７のいずれか１項に記載のユーザ機器（２００）。

【請求項19】

ユーザ機器（２００）が前記ユーザ機器（２００）に関連する第１の論理チャネルのＲＬＣ障害にどのように対応すべきかを定義する無線リンク制御（ＲＬＣ）障害構成（ＲＬＣ－ＦＣＦＧ）を用いて前記ユーザ機器（２００）を設定（３００）することを含み、
前記ＲＬＣ障害構成（ＲＬＣ－ＦＣＦＧ）が、少なくとも１つの優先度しきい値（Ｐ１、Ｐ２）を含み、前記ユーザ機器（２００）は、少なくとも１つの前記優先度しきい値（Ｐ１、Ｐ２）と、（ａ）前記ユーザ機器に関連する論理チャネルの最低優先度、および（ｂ）前記第１の論理チャネルの優先度のうちの少なくとも１つに基づいて、前記ＲＬＣ障害をネットワークまたは前記ネットワークに送信するかどうかを決定する、無線通信システム（１０）用の装置（１００）を操作する方法。

【請求項20】

ユーザ機器（２００）が、前記ユーザ機器（２００）に関連する第１の論理チャネルのＲＬＣ障害にどのように対応すべきかを定義する無線リンク制御（ＲＬＣ）障害構成（ＲＬＣ－ＦＣＦＧ）を決定（３５０）することを含み、
前記ＲＬＣ障害構成（ＲＬＣ－ＦＣＦＧ）が、少なくとも１つの優先度しきい値（Ｐ１、Ｐ２）を含み、命令が、少なくとも１つのプロセッサ（２０２）によって実行されると、前記ユーザ機器（２００）に、さらに、少なくとも１つの前記優先度しきい値（Ｐ１、Ｐ２）と、
（ａ）前記ユーザ機器に関連する論理チャネルの最低優先度、および
（ｂ）前記第１の論理チャネルの優先度
のうちの少なくとも１つに基づいて、前記ＲＬＣ障害をネットワークまたは前記ネットワークに送信するかどうかを決定させる、ユーザ機器（２００）を操作する方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、無線通信システム用の装置に関する。この開示は、さらにユーザ機器（ＵＥ）に関するものである。本開示はさらに、無線通信システムのための装置の操作方法に関する。開示はさらに、ユーザ機器の操作方法に関連する。

【背景技術】

【0002】

無線通信システムは、例えば、２つ以上のエンティティ間の情報の無線交換に使用されることがある。

【発明の概要】

【発明が解決しようとする課題】

【0003】

開示の様々な実施形態に対して求められる保護の範囲は、独立したクレームによって規定されている。本明細書に記載されている、独立したクレームの範囲に該当しない例示的な実施形態及び特徴があれば、それは、開示の様々な例示的な実施形態を理解するのに有用な例として解釈される。

【0004】

いくつかの実施例は、少なくとも１つのプロセッサを含む無線通信システム用の装置と、少なくとも１つのプロセッサによって実行されたときに、装置が無線リンク制御（ＲＬＣ）ユーザ機器に関連付けられた第１論理チャネルのＲＬＣ障害にユーザ機器がどのように対応すべきかを定義する障害構成を少なくともユーザ機器に設定させる命令を格納するメモリに関連する。

【0005】

いくつかの実施例では、装置またはその機能は、それぞれ通信システムのネットワーク要素、例えば、基地局、より具体的にはｇＮｏｄｅＢ（ｇＮＢ）で提供されることがある。

【0006】

いくつかの実施例では、それぞれの実施例またはその機能に従った装置は、第３世代パートナーシッププロジェクト、３ＰＰ、４Ｇ Ｅ－ＵＴＲＡＮまたは５Ｇ ＮＲ（第５世代新無線）などの無線規格に基づくか、少なくとも部分的に準拠した無線通信システムのために、またはその中で使用することができる。いくつかの実施例では、５Ｇ ＮＲベースの通信システムの手順である無線リンク障害（ＲＬＦ）に対して、それぞれの実施例またはその機能に従った装置を使用することができる。

【0007】

例として、たとえば５Ｇ ＮＲなどで現在定義されているＵｕインターフェイスのＲＬＦに対する１つのトリガ条件は、ＲＬＣ確認応答モード（ＡＭ）を使用しているときに、ＲＬＣ再送信の最大数に達したことを無線リンク制御（ＲＬＣ）層から通知されたときに、次のように特徴付けられる。このトリガ条件に従って、ＲＬＣの最大再送信回数は、３ＧＰＰ ＴＳ３８．３３１（参照例：３ＧＰＰ ＴＳ３８．３３１Ｖ１５．８．０（２０１９－１２））に従って情報要素（ＩＥ）“ＲＬＣ－Ｃｏｎｆｉｇ”で設定されるパラメータ“ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ”を使用して設定され、ＡＭ ＲＬＣエンティティの送信側がＲＬＣパケットデータユニット（ＰＤＵ）の合計再送信回数を制限するために使用される。この場合、ＲＬＦが検出されると、ＵＥがＲＲＣ＿ＩＤＬＥ状態に遷移するか、Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ（ＲＲＣ）接続再確立手順を開始する可能性がある。

【0008】

５Ｇ ＮＲなどで現在定義されている最大再送信回数パラメータ（つまり、ＲＬＣ－Ｃｏｎｆｉｇで設定されたｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ）は、３ＧＰＰ ＴＳ３８．３３１で定義されているＲＬＣ ＡＭに適用され、値ｔ１は１回の再送信、値ｔ２は２回の再送信などに対応する。例示的な単一セルのシナリオで、ＲＬＣエンティティの再送信の最大回数に達すると、ＲＬＦが宣言され、前述のようにＵＥがＮＷとのＲＲＣ接続を再確立するようにトリガされる。具体的には、ＳＲＢ０を除くすべての無線ベアラ（ＲＢ）は、ＲＬＦが宣言された時点で中断される。これらの中断されたＲＢ（すなわち、ＳＲＢ２とＤＲＢ）は、ＲＲＣ接続再確立手順が正常に完了した後、第１のＲＲＣ再構成メッセージを受信すると最初に再開できる。したがって、ＤＲＢが再開されている間はユーザープレーンデータを送信できないため、実行中のアプリケーションに望ましくない中断が発生する。

【0009】

ＴＳ３８．３３１に従って、ＲＬＣ－ＣｏｎｆｉｇはＩＥ ＲＬＣ－ＢｅａｒｅｒＣｏｎｆｉｇ内に含まれる。これは、（ＰＤＣＰエンティティへのリンクに加えて）ＲＬＣエンティティと、アップリンクについてのＭＡＣの対応する論理チャネル（ＬＣＨ）を設定するために使用される。このように、個別のＲＬＣエンティティをＵＥについて（例えば、異なる論理チャネルについて）設定でき、これらは異なる方法で設定できる。たとえば、最大再送信回数に異なる値を設定できる。

【0010】

現在のＲＬＦの定義では、例えば５Ｇ ＮＲに対して現在定義されているように、１つの論理チャネル／ＲＬＣエンティティに対するＲＬＣ障害（例えば、ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄに到達した場合）は、ＲＬＦの宣言を意味し、次にすべてのＤＲＢを中断し、任意の他のＤＲＢ上のデータ伝送を中断する。

【0011】

例として、第１に、ＲＬＣ障害が発生した場合、無線の状態やプロトコルの問題が原因である可能性がある。無線の問題である場合、ＲＬＣの再送信であっても、無線損失からの回復を助けることができないことを意味する。通常、無線リンク監視（ＲＬＭ）手順は、ＲＬＣ障害が発生する前に無線の問題を検出できることが期待され、現在定義されている（例えば５Ｇ ＮＲについての）ＲＬＭ手順は、プライマリセル（ＰＣｅｌｌ）に制限されている。したがって、ＲＬＣ障害は、ＰＣｅｌｌだけの無線の問題ではなく、セカンダリセル（ＳＣｅｌｌ）の無線の問題またはプロトコルの障害（設定の問題を含む）が原因で発生する可能性がある。

【0012】

さらに、５Ｇ ＮＲでは、ＬＣＨで使用できる許可されたセル」の制限も導入された。これは、ＬＣＨのＲＬＣ障害がそのＬＣＨの許可されたセル（例えば、ライセンスされていないセル、高周波セルなど）のみの問題になる可能性があるが、信頼性が高くチャネル品質が優れた異なるセルを使用している場合は、他のＬＣＨに影響を与えないという点で、従来のＬＴＥとは異なる。

【0013】

これは、いくつかの実施例によると、あるＲＬＣエンティティのＲＬＣ障害は、別の論理チャネルを適切にサポートできないことを意味しない場合があることを意味する。これは、異なるＱｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ（ＱｏＳ）要件を持つ異なるサービスタイプがデバイス内に共存している場合に特に関連する側面である。
たとえば、超信頼性と低遅延の通信（ＵＲＬＬＣ）サービスに対して使用される論理チャネルからｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ値を達成することが、必ずしもより緩和されたＱｏＳ要件を持つ論理チャネル（大規模なマシンタイプ通信（ｍＭＴＣ）や拡張モバイルブロードバンド（ｅＭＢＢ）サービスをサポートするために使用される論理チャネルなど）の中断をトリガする必要はない。

【0014】

さらなる例として、第２に、ＲＬＣ障害によってトリガされる再確立は、（古いまたは新しいセルの）セル選択、選択されたセルへのランダムアクセス手順、および交換されるいくつかのＲＲＣメッセージを含むことがあるので、比較的遅い手順である可能性がある。プロトコル／設定の問題が原因でＲＬＣ障害が発生した場合、同じセル（例：影響を受けるＲＬＣエンティティの再設定）による回復試行が成功する可能性がある。
しかし、それは再設立による不必要な遅延の後にのみ開始される。

【0015】

いくつかの実施例では、影響を受けたＲＬＣエンティティ（つまり、ＲＬＣ障害を検出したＲＬＣエンティティ。）のより迅速な回復を目的とするＲＬＣ障害を処理する方法などの側面に対処すると同時に、影響を受けていないＲＬＣエンティティがサービスを継続できるようにする場合がある。

【0016】

いくつかの実施例によれば、既に述べたように、ユーザ機器は、例えばいくつかの実施例による装置を介した構成によって提供されるＲＬＣ障害構成を使用して、そのようなＲＬＣ障害にどのように対応するかを決定することができる。

【0017】

いくつかの実施例によれば、ＲＬＣ障害構成は、ユーザ機器がネットワークへの第１の論理チャネルのＲＬＣ障害を通知すべきかどうかを定義する。

【0018】

いくつかの実施形態によれば、ＲＬＣ障害構成は、ユーザ機器に関連する少なくとも第２の論理チャネルが正常に動作した場合、すなわちＲＬＣ障害が発生しなかった場合に、ユーザ機器が第１の論理チャネルのＲＬＣ障害をネットワークに通知すべきかどうかを定義する。いくつかの実施形態によれば、これは、例えば、ＲＬＦを宣言して再確立を開始するのではなく、少なくともそれに関連する第２のＬＣＨおよび／またはＲＢに対して、通常の、すなわち中断されない動作を維持することを可能にする。

【0019】

例として、ユーザ機器に関連付けられた第２の論理チャネルは、例えば第２の論理チャネルがＲＬＣ再送の所定回数（例：第１のしきい値または最大ＲＬＣ再送信回数）に達していない場合に、正常に動作する。

【0020】

いくつかの実施例によると、ＵＥは複数のＬＣＨおよび／またはＲＬＣエンティティで構成される場合がある。

【0021】

いくつかの実施例によると、ＵＥはＬＣＨごとに個別のＲＬＣ障害構成で設定することができ、これにより異なるＲＬＣ障害構成を持つ異なるＬＣＨを提供することができる。

【0022】

いくつかの実施形態によれば、命令は、少なくとも１つのプロセッサによって実行されると、装置にさらに、ＲＬＣ障害構成でユーザ機器を明示的に設定させる。

【0023】

いくつかの実施例によると、ユーザ機器はＲＬＣ障害構成で暗黙的に設定されることもある。

【0024】

たとえば、マルチセルキャリア集約（ＣＡ）／デュアル接続（ＤＣ）シナリオに基づく可能性のあるいくつかの実施形態によると、ＬＣＨのＲＬＣ障害が再確立ではなくＲＬＣ障害レポートをトリガするべきかどうかをＬＣＨごとに設定することは、たとえば、ＬＣＨの許可されたセル設定に基づいて暗黙的に行われる可能性がある。

【0025】

いくつかの実施例によると、暗黙的な設定は許可されたセル設定の一部であり、ＵＥごとに有効／無効にすることができる。たとえば、障害下のＬＣＨに対して許可されている設定済みセル、つまり第１のＬＣＨは、障害がおきていると見なされ、したがって、中断／非アクティブ化される可能性がある。少なくとも別のセルが失敗しておらず、少なくとも別のＬＣＨにマップされている限り、これらの条件下では、いくつかの実施形態に従って、ＲＬＣ障害レポートが（ＲＲＣ）再確立なしでトリガされる可能性がある。いくつかの実施形態によれば、そうでない場合、例えば、他のセルも障害が発生しており、障害が発生していない他のＬＣＨがセルにマップされていない場合、ＲＲＣの再確立が開始される。

【0026】

いくつかの実施形態では、許可されたセルは、無線エラーが発生しやすい可能性があるため、無許可セルおよび／または高周波セル（例えば、３ＧＰＰ３８．１０１－１で定義されている周波数範囲ＦＲ２を使用する場合、参照：３ＧＰＰ ＴＳ３８．１０１－１Ｖ１６．２．０（２０１９－１２）、表５．１－１等）である。これにより、信頼性が高くチャネル品質が高い異なるセルを使用している場合に、これらのセルの問題が他のＬＣＨに影響を与えないようにする。

【0027】

いくつかの実施例では、ＲＬＣ障害構成は第１のしきい値を含み、ユーザ機器は第１のしきい値に基づいて、ＲＬＣ障害を同じまたは別のネットワークに送信するかどうかを決定することができる。

【0028】

いくつかの実施例では、第１のしきい値はＲＬＣ再送信の所定回数である。

【0029】

例えば、シングルセルのシナリオやマルチセルのＣＡ／ＤＣシナリオに基づくいくつかの実施形態によれば、第１のしきい値は、３ＧＰＰ ＴＳ３８．３３１（例えば、３ＧＰＰ ＴＳ３８．３３１ Ｖ１５．８．０（２０１９－１２）を参照）に従って情報要素（ＩＥ）“ＲＬＣ－Ｃｏｎｆｉｇ”で設定される既存のしきい値パラメータ“ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ”を考慮した新しい（追加の）しきい値と見なすことができる。

【0030】

いくつかの実施形態によれば、第１の（すなわち、新しい）しきい値は、例えば、“ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ＿ＲＬＣＲｅｐｏｒｔ”として示され、以下の（ａ）および／または（ｂ）を決定するようにＵＥに設定される場合がある。
（ａ）例えば、現在のＲＬＣ ＡＭ再送信回数が第１のしきい値に達した場合に、第１のＬＣＨのＲＬＣ障害を報告するときである（および／または、報告するかどうか）
（ｂ）（例えば、現在のＲＬＣ ＡＭの再送信回数が、ＲＬＦ検出用に定義された既存のしきい値パラメータ“ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ”に達した場合に）ＲＬＦを宣言するときである（および／または、宣言するかどうか）

【0031】

いくつかの実施形態によれば、第１のしきい値“ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ＿ＲＬＣＲｅｐｏｒｔ”の値は、例えば最初にレポートをトリガするために、既存の“ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ”よりも低く設定することができる。
いくつかの実施例によると、これにより、ＲＬＦを宣言してすべてのＤＲＢを中断する前に、例えば、影響を受けた（第１の）ＬＣＨに対するプロトコルパラメータを再設定したり、許可されたセルや他のＬＣＰ制限を変更したりすることによって、最初にＲＬＣ障害の問題を回復／解決する試みが可能になる。

【0032】

いくつかの実施形態によれば、ＲＬＣ障害構成は、少なくとも１つのマッピング制限を無効にするかどうかをユーザ機器に示す第１の制御情報を含む。

【0033】

例えば、シングルセルのシナリオまたはマルチセルのＣＡ／ＤＣシナリオに基づくことが可能ないくつかの実施例によると、（例えば、ＲＬＦ検出(例:既存の“ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ”)のために定義された最大数や、より低い設定された数、例えば、上で説明したいくつかの実施形態による第１のしきい値に対応する）ＲＬＣエンティティ／ＬＣＨに対して所定の回数のＲＬＣ ＡＭ再送信に達したことを検出すると、ＬＣＨにＬＣＰ(論理チャネルの優先順位付け)マッピング制限（例：ａｌｌｏｗｅｄＣＧ＿ｌｉｓｔ、ａｌｌｏｗｅｄＰｒｉｏｒｉｔｙＬｅｖｅｌｓ、ａｌｌｏｗｅｄＳｅｒｖｉｎｇＣｅｌｌｓによる（例：３ＧＰＰ ＴＳ ３８．３００ Ｖ １５．８．０（２０１９－１２）、例：ｃｈａｐｔｅｒ１６．１．２））が設定されている場合、ＵＥは、（例えば、ＲＬＦをトリガする代わりに）これらのマッピング制限の少なくとも１つを無効にすることができ、これは、できるだけ早く送信されるデータを取得するために有益である可能性があり、いくつかの実施形態に従った「回復動作（ｒｅｃｏｖｅｒｙ ｂｅｈａｖｉｏｒ）」のいくつかのアクションとして例示的に参照される可能性がある。

【0034】

いくつかの実施形態によれば、これらのマッピング制限のうち少なくとも１つの無効化は、自動的に、すなわち、ＵＥによって受信される明示的な指示なしに実行され得る。

【0035】

いくつかの実施例によると、この「回復動作」を有効にするかどうかは、ネットワーク構成に依存する場合がある。（例えば、上記で説明したいくつかの実施形態による可能な第１のしきい値に加えて）設定は、（例えば、情報要素（ＩＥ）“ＲｅｓｔｒｉｃｔｉｏｎｓＤｉｓａｂｌｅＬｉｓｔ”を介して）無効にするＬＣＰマッピング制限を示す場合がある。例えば、いくつかの実施形態によれば、“ａｌｌｏｗｅｄＳｅｒｖｉｎｇＣｅｌｌｓ”に従って制限を無効にした後、ＵＥは、影響を受けた（例：第１の）ＬＣＨに対して以前に制限されたセルに適用されるＵＬ許可を、そのＬＣＨからのデータで満たすことができる。いくつかの実施例によれば、同様に、その許可に対応する送信にそのＬＣＨのデータが存在することは、ＵＥが（ＬＣＰマッピング）制限を無効にしたことをネットワークに対して暗黙的に示す可能性があり、同様に、上記で説明したいくつかの実施例に従って、ＵＥがＲＬＣ障害を経験したか、またはＵＥが第１のしきい値に達したことを示す。

【0036】

いくつかの実施形態によれば、第１の制御情報は、複数のマッピング制限のうちどれを無効にするかを示す。

【0037】

いくつかの実施形態によれば、ＲＬＣ障害構成は、少なくとも１つの優先度しきい値を含み、ユーザ機器は、少なくとも１つの優先度しきい値に基づいて、ＲＬＣ障害をあるネットワークまたは前記ネットワークに送信するかどうかを決定することができる。

【0038】

いくつかの実施例によると、ユーザ機器は、少なくとも１つの優先度しきい値に基づいて、ａ）ユーザ機器に関連付けられた論理チャネルの最低優先度、ｂ）第１の論理チャネルの優先度のうちの少なくとも１つに基づいて、ＲＬＣ障害をあるネットワークまたは前記ネットワークに送信するかどうかを決定する場合がある。

【0039】

いくつかの実施形態によれば、第１の優先度しきい値と第２の優先度しきい値を提供することができる。

【0040】

例えば、シングルセルのシナリオやマルチセルのＣＡ／ＤＣシナリオに基づいたいくつかの実施形態によれば、既存の論理チャネルの最低優先度が第１の設定しきい値Ｐ１より低く、ＲＬＣ障害を検出するＬＣＨの優先度が第２のしきい値Ｐ２より高い場合、ＵＥはＲＬＣ障害レポートをＮＷに送信することができる。
いくつかの実施形態によると、ＲＬＣ障害を検出するＬＣＨと比較して、特定の（すなわち、消失しない）ＱｏＳの違いおよび／または設定の違いを持つ別のＬＣＨが設定されている場合、影響を受ける（すなわち、ＲＬＣ障害を検出する）ＬＣＨからのＲＬＣ障害は、他のＬＣＨの障害を意味する必要はなく、したがって、他のＬＣＨに影響を与えるべきではない。あるいは、いくつかの実施形態によると、設定されたしきい値よりも優先度が高いまたは低いＬＣＨに障害が発生した場合にＬＣＨまたは優先度しきい値ごとに設定され、ＲＬＣ障害レポートがトリガされる。

【0041】

いくつかの実施形態によれば、命令は、少なくとも１つのプロセッサによって実行されると、さらに、装置に、例えばＬＣＨ／ＲＬＣエンティティのようなユーザ機器を、以下の（ａ）～（ｄ）の内の少なくとも１つを示す第２の制御情報、例えばフラグを設定させる。
（ａ）ユーザ機器は、第１の論理チャネルのＲＬＣ障害の検出時に無線リンク障害を宣言すべきである、
（ｂ）ユーザ機器は、例えばＲＬＣ障害レポートの形式で、第１の論理チャネルのＲＬＣ障害をネットワークに送信すべきである、
（ｃ）ユーザ機器は、第１の論理チャネル以外の少なくとも１つの論理チャネルのＲＬＣ障害の検出時に無線リンク障害を宣言すべきである、
（ｄ）ユーザ機器は、第１の論理チャネル以外の少なくとも１つの論理チャネルのＲＬＣ障害の検出時にＲＬＣ障害レポートを送信すべきである。

【0042】

いくつかの実施形態によれば、第２の制御情報、例えばフラグは、ＬＣＨ／ＲＬＣエンティティおよび／または設定されたＬＣＨ／ＲＬＣエンティティのセットのＱｏＳ要件を考慮して設定することができる。

【0043】

いくつかの実施形態によれば、命令は、少なくとも１つのプロセッサによって実行されると、さらに、少なくとも１つのユーザ機器固有の条件に基づいて、装置にＲＬＣ障害構成の少なくとも一部を設定させる。

【0044】

いくつかの実施例によれば、第１のしきい値の値、および／または、無線リンク障害を宣言しおよび／またはＲＬＦ障害レポートを送信する条件は、ＵＥ固有の条件、例えば、ＵＥ内の既存のサービスや、オプションでＱｏＳ要件を考慮して設定され得る。例えば、いくつかの実施例では、ｅＭＢＢサービスとＵＲＬＬＣサービスの両方が共存している場合、ＵＲＬＬＣサービスからのみのＲＬＣ障害はＲＬＦを宣言しない。

【0045】

いくつかの実施形態によれば、１つのしきい値、または第１および第２のしきい値が設定される場合があり、例えば既存の論理チャネルに対する５Ｇ ＮＲによって現在定義されている最大再送信回数パラメータ（つまり、ＲＬＣ－Ｃｏｎｆｉｇで設定された“ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ”）の最大値が第１の設定しきい値よりも高く、ＲＬＣ障害を検出するＬＣＨの“ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ”の値が第２の設定しきい値よりも低い場合、ＵＥはＲＬＣ障害レポートをＮＷに送信することがある。このオプションでは、ＵＥは宣言するＬＣＨ（ＲＬＦを宣言するＬＣＨ）と他のＬＣＨとの間で、ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄに関して大きな違いを保証できる。したがって、影響ＲＬＣエンティティのＲＬＣ障害が別のＬＣＨの動作に影響を与えることはない。

【0046】

いくつかの実施形態によれば、命令は、少なくとも１つのプロセッサによって実行されると、装置にＲＬＣ障害構成の少なくとも一部、例えば、第１のしきい値、第２のしきい値の少なくとも１つをブロードキャストさせる。

【0047】

いくつかの実施形態によれば、装置またはネットワークは、ＲＬＣ障害構成の少なくとも一部、例えば、システム情報ブロック（ＳＩＢ）内の第１のしきい値、第２のしきい値の少なくとも１つをブロードキャストすることができる。

【0048】

さらなる実施例は、少なくとも１つのプロセッサと、少なくとも１つのプロセッサによって実行されたときに、ユーザ機器に、ユーザ機器に関連付けられた第１論理チャネルのＲＬＣ障害にどのように対処すべきかを定義する無線リンク制御（ＲＬＣ）障害構成を少なくとも決定させる命令を格納するメモリとを含むユーザ機器に関する。

【0049】

いくつかの実施形態によれば、ＲＬＣ障害構成の決定は、装置、例えば、実施形態による装置、および／またはｇＮＢからのＲＬＣ障害構成の受信（例えば、明示的な構成を持つ実施形態の場合）、他のデータおよび／または構成からのＲＬＣ障害構成の決定（例えば、暗黙的な構成を持つ実施形態の場合）の少なくとも１つを含むことができる。

【0050】

いくつかの実施例によれば、ユーザ機器におけるＲＬＣ障害構成の少なくとも一部は、例えば３ＧＰＰ技術仕様のように標準でも規定されている場合があり、および／またはＵＥ実装によって準備されている場合がある。いくつかの実施形態によれば、この命令は、少なくとも１つのプロセッサによって実行されると、ユーザ機器にさらに、例えばユーザ機器に関連する少なくとも第２の論理チャネルが正常に動作する場合など、ユーザ機器がネットワークへの第１の論理チャネルのＲＬＣ障害を通知すべきかどうかを、ＲＬＣ障害構成に基づいて判断させる。

【0051】

いくつかの実施形態によれば、命令は、少なくとも１つのプロセッサによって実行されると、さらに、少なくとも１つの論理チャネルに対して許可されたセルの構成に基づいて、ユーザ機器に無線リンク制御（ＲＬＣ）障害構成を決定させる。

【0052】

いくつかの実施形態によれば、ＲＬＣ障害構成は第１のしきい値で構成され、命令が少なくとも１つのプロセッサによって実行されると、ユーザ機器はさらに第１のしきい値に基づいて、ＲＬＣ障害をあるネットワークまたは前記ネットワークに送信するかどうかを決定する。

【0053】

いくつかの実施例では、第１のしきい値はＲＬＣ再送信の所定回数である。

【0054】

いくつかの実施形態によれば、ＲＬＣ障害構成は、少なくとも１つのマッピング制限を無効にするかどうかをユーザ機器に示す第１の制御情報を含み、その命令は、少なくとも１つのプロセッサによって実行されると、さらに、ユーザ機器に第１の制御情報に基づいて少なくとも１つのマッピング制限を無効にさせる。

【0055】

いくつかの実施形態によれば、ＲＬＣ障害構成は、少なくとも１つの優先度しきい値を含み、命令は、少なくとも１つのプロセッサによって実行されると、ユーザ機器にさらに、少なくとも１つの優先度しきい値、およびオプションで、ａ）ユーザ機器に関連付けられた論理チャネルの最低優先度、ｂ）第１の論理チャネルの優先度のうちの少なくとも１つに基づいて、ＲＬＣ障害をあるネットワークまたは前記ネットワークに送信するかどうかを決定させる。

【0056】

いくつかの実施形態によれば、この命令は、少なくとも１つのプロセッサによって実行されると、ユーザ機器にさらに、第１のセルによって提供される論理チャネルについて所定の数のＲＬＣ再送信に達したかどうかを判断させ、論理チャネルについて所定の数のＲＬＣ再送信に達した場合には、第１のセルによって提供される少なくとも１つのさらなる論理チャネルが所定の数のＲＬＣ再送信に達しなかった場合に、論理チャネルについてＲＬＣ障害をネットワークに送信させる。

【0057】

いくつかの実施形態によれば、ＲＬＣ再送信の所定の回数は、設定された第１のしきい値または最大ＲＬＣ再送信回数とすることができる。

【0058】

いくつかの実施形態によれば、この命令は、少なくとも１つのプロセッサによって実行されると、ユーザ機器にさらに、第１の品質しきい値よりも優れた無線チャネル品質を持つ別のセルを再選択できるかどうかを判断させ、第１品質しきい値よりも優れた無線チャネル品質を持つ別のセルを再選択できる場合は、他のセルとの無線リソース制御（ＲＲＣ）接続をＲＬＣ障害構成に基づいて再確立し、第１の品質しきい値よりも優れた無線チャネル品質を持つ別のセルを再選択できない場合は、ＲＬＣ障害構成に基づいて現在のサービングセルにＲＬＣ障害レポートを送信するかどうかを判断させる。

【0059】

いくつかの実施例によれば、ＵＥの上位層は、例えば装置やネットワークによって、ＲＬＣエンティティからＲＬＣ障害の報告を受けたときに異なる動作をするように設定されるかもしれない。いくつかの実施例によれば、上位層はＲＬＣ障害によって影響を受けたサービスを分析するかもしれない（つまり、ＲＬＣ障害を検出した論理チャネルで送信されるデータを持つサービス）。

【0060】

いくつかの実施例によると、ＵＥの上位層は、例えば第１のＬＣＨのＲＬＣ障害のために、特定のサービス／アプリケーションがこれ以上サポートできないかどうかをチェックする場合がある。いくつかの実施例によると、サービスが厳格なＱｏＳ要件を有する場合、ＬＣＨがＲＬＣ障害を検出できないため、サービスを停止する必要があると考えられる。この場合、いくつかの実施例によると、このサービスが複数のＬＣＨを使用し、これらのＬＣＨの一部がこのサービスによってのみ使用される場合、ＲＬＣ障害メッセージには、影響を受けるサービスによってのみ使用されるＬＣＨ／ＲＢを中断するための情報／推奨事項も含まれる場合がある。これにより、影響を受けるサービスのみを提供するＬＣＨが中断される可能性がある。いくつかの実施形態によれば、中断後、ＬＣＨは再開および／または再構成されるまで、次の伝送では使用されない。

【0061】

いくつかの実施形態によれば、影響を受けるサービスがパフォーマンスの低下に耐えるように自身を調整できる場合、ＵＥはＲＬＣ障害レポートに対応する表示を含めることなどにより、ＲＬＣ障害レポートでこれを示すことができる。いくつかの実施形態によると、この表示は、影響を受けたＬＣＨ／ＤＲＢを再設定するか、または中断するかを決定する柔軟性をＮＷに提供する可能性がある。いくつかの実施例によると、やはり、影響を受けたサービスのみを提供するＬＣＨの表示をＲＬＣ障害レポートに含めることができるため、ＮＷはより良い知識で決定を下すことができる。

【0062】

いくつかの実施例は、ユーザ機器に関連付けられた第１の論理チャネルのＲＬＣ障害にユーザ機器がどのように対応すべきかを定義する無線リンク制御（ＲＬＣ）障害構成を用いてユーザ機器を設定するステップを含む、無線通信システムのための装置を操作する方法に関する。

【0063】

いくつかの実施例は、ユーザ機器に関連する第１の論理チャネルのＲＬＣ障害にユーザ機器がどのように対応すべきかを定義する無線リンク制御（ＲＬＣ）障害構成を決定するステップを含む、ユーザ機器を操作する方法に関する。

【0064】

いくつかの詳細および実施例は、いくつかの実施例によると、ＵＥとネットワークの間の無線インターフェイス、例えばｇＮＢを使用するが、基本的な原則は、例えばＰＣ５－ＲＲＣ接続の下で、２つのユーザデバイス、例えばＵＥ間のサイドリンク通信に使用される可能性のあるサイドリンク（ＳＬ）ＲＬＣエンティティのＲＬＣ障害を処理するために、他の通信および／または無線インターフェイスにも適用される場合がある。

【0065】

例えば、いくつかの実施例によれば、２つのＳＬ ＵＥ間のＳＬ ＬＣＨの伝送は、複数のＳＬキャリアまたは２つのリソースプールを介して行われる可能性があり、したがって、いくつかの実施例に従ったマルチセルシナリオのための提案された解決策は、複数のＳＬキャリアまたは複数のＳＬリソースプールを介したＳＬ伝送を考慮することによって適用され得る。

【0066】

他の実施例では、単一セルシナリオについて示されたいくつかの実施例のアプローチは、単一のＳＬキャリアまたは単一のＳＬリソースプールを介して２つのＳＬ ＵＥ間でＳＬ ＬＣＨを送信するために適用され得る。いくつかの実施例に従って提案された方式をＳＬ通信に適用することは、例えばＰＣ５－ＲＬＣ宣言を回避し、ＳＬ ＲＬＣ障害が１つのＳＬ ＲＬＣエンティティ／ＬＣＨに影響を与えているにもかかわらず、他のＳＬ ＲＬＣエンティティ／ＬＣＨに対してサービスを継続できるようにするなど、ＵＥとネットワーク間の通信についていくつかの実施例を参照して説明したのと同様の利点を持ち得る。

【0067】

なお、サイドリンク通信の場合、ＳＬの伝送モードおよび／またはＵＥのＲＲＣ状態に応じて、ＵＥのＳＬ ＲＢ／ＲＬＣエンティティ／ＬＣＨの（再）設定は、ＳＬ ＵＥ自身でなされる場合とネットワークでなされる場合がある。

【0068】

ここで、いくつかの例示的な実施形態について、以下に示す添付図面を参照して説明する。

【図面の簡単な説明】

【0069】

【図1】いくつかの実施形態による装置を模式的に描く簡略化されたブロック図である。

【図2】いくつかの実施形態によるユーザ機器を模式的に描く簡略化されたブロック図である。

【図3】いくつかの実施形態による通信システムを模式的に描く簡略化されたブロック図である。

【図4】いくつかの実施例に従った方法の簡略化されたフローチャートである。

【図5】いくつかの実施例に従ったＲＬＣ障害構成の簡略化されたブロック図である。

【図6】いくつかの実施例に従った方法の簡略化されたフローチャートである。

【図7】いくつかの実施例に従った方法の簡略化されたフローチャートである。

【図8】いくつかの実施例に従った方法の簡略化されたフローチャートである。

【図9】いくつかの実施例に従った方法の簡略化されたフローチャートである。

【図10】いくつかの実施例に従った方法の簡略化されたフローチャートである。

【発明を実施するための形態】

【0070】

いくつかの実施例は、無線通信システム用の装置に関するものである。図１は、いくつかの実施例による装置１００の簡略化されたブロック図を模式的に示し、図４は、いくつかの実施例による装置の操作方法の簡略化されたフローチャートを模式的に示している。装置１００（図１）は、少なくとも１つのプロセッサ１０２と、少なくとも１つのプロセッサ１０２によって実行されたときに、装置１００に、無線リンク制御（ＲＬＣ）障害構成ＲＬＣ－ＦＣＦＧを備えたユーザ機器を少なくとも構成３００（図４を参照）させる命令１０６を格納するメモリ１０４から構成される。無線リンク制御（ＲＬＣ）障害構成ＲＬＣ－ＦＣＦＧはユーザ機器に関連付けられた第１の論理チャネルのＲＬＣ障害にユーザ機器がどのように対応すべきかを定義する。

【0071】

いくつかの実施例によれば、ユーザ機器におけるＲＬＣ障害構成の一部は、例えば３ＧＰＰ技術仕様などにおける規格で規定され、および／またはＵＥ実装によって準備される。

【0072】

いくつかの実施例では、ＲＬＣ障害構成ＲＬＣ－ＦＣＦＧでユーザ機器を構成３００した後、装置１００は、図４のステップ３０２を参照して、ユーザ機器から、たとえば、少なくとも１つのＲＬＣ障害レポートＲＬＣ－ＦＲの形で、ＲＬＣ障害をうけとる。

【0073】

いくつかの実施形態では、装置１００（図１）は、例えばユーザ機器（ＵＥ）２００（例えば図２参照）および／または更なる装置（図には示されていない）のような他のコンポーネントと無線周波数（ＲＦ）信号を交換、すなわち送信および／または受信するためのトランシーバ１０８を含むことができる。

【0074】

図３は、いくつかの実施例による通信システム１０の簡略化されたブロック図を示す。通信システム１０は、例えば装置１００を構成することができる。通信システム１０はさらに少なくとも１つのユーザ機器ＵＥ２００を含むことができる。「２００’」はオプションの追加ＵＥを示す。

【0075】

いくつかの実施例では、装置１００またはその機能は、それぞれ通信システム１０のネットワーク要素、例えば、基地局１１０、例えば、ｇＮｏｄｅＢ（ｇＮＢ）１１０で提供されてもよい。

【0076】

いくつかの実施例では、それぞれの実施例またはその機能に従った装置１００は、第３世代パートナーシッププロジェクト、３ＧＰＰ、４Ｇ Ｅ－ＵＴＲＡＮまたは５Ｇ ＮＲ（第５世代新無線）などの無線規格に基づくか、少なくとも部分的に準拠した無線通信システム１０のために、またはその中で使用することができる。いくつかの実施例では、実施例またはその機能に応じた装置１００は、それぞれ、無線リンク障害（ＲＬＦ）、５Ｇ ＮＲベースの通信システム１０の手順に使用することができる。

【0077】

いくつかの実施例では、図２を参照すると、ＵＥ２００は、少なくとも１つのプロセッサ２０２と、例えばコンピュータプログラムコード２０６の形で命令を格納するメモリ２０４を含むことができる。

【0078】

オプションとして、さらなる例示的な実施形態によれば、ＵＥ２００は、無線周波数（ＲＦ）信号を、例えば装置１００またはｇＮＢ１１０（図３）、および／またはさらなるデバイス（図示せず）などの、他のコンポーネントと交換、すなわち送信および／または受信するステップを含む。

【0079】

例として、たとえば５Ｇ ＮＲに対して現在定義されているＵｕインターフェイスのＲＬＦに対する１つのトリガ条件は、ＲＬＣ確認応答モード（ＡＭ）を使用しているときに、ＲＬＣ再送信の最大数に達したことを無線リンク制御（ＲＬＣ）層から示されたときに特徴付けられる。このトリガ条件に従って、ＲＬＣの最大再送信回数は、３ＧＰＰ ＴＳ３８．３３１（例えば、３ＧＰＰ ＴＳ３８．３３１Ｖ１５．８．０（２０１９－１２）を参照）に従って情報要素（ＩＥ）“ＲＬＣ－Ｃｏｎｆｉｇ”で設定されるパラメータ“ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ”を使用して設定され、ＡＭ ＲＬＣエンティティの送信側がＲＬＣパケットデータユニット（ＰＤＵ）の合計再送信回数を制限するために使用される。

【0080】

５Ｇ ＮＲなどで現在定義されている最大再送信回数パラメータ（つまり、ＲＬＣ－Ｃｏｎｆｉｇで設定されたｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ）は、３ＧＰＰ ＴＳ３８．３３１で定義されているＲＬＣ ＡＭに適用される。ここで、値ｔ１は１回の再送信、値ｔ２は２回の再送信などに対応する。例示的な単一セルのシナリオにおいて、ＲＬＣエンティティの再送信の最大回数に達すると、前述のようにＵＥの、ＮＷとのＲＲＣ接続の再確立をトリガするＲＬＦが宣言される。具体的には、ＳＲＢ０を除くすべての無線ベアラ（ＲＢ）は、ＲＬＦが宣言された時点で中断される。これらの中断されたＲＢ（すなわち、ＳＲＢ２とＤＲＢ）は、ＲＲＣ接続再確立手順が正常に完了した後、第１のＲＲＣ再構成メッセージを受信すると最初に再開できる。したがって、ＤＲＢが再開されている間はユーザープレーンデータを送信できないため、実行中のアプリケーションに望ましくない中断が発生する。

【0081】

ＴＳ３８．３３１に従って、ＲＬＣ－ＣｏｎｆｉｇはＩＥ ＲＬＣ－ＢｅａｒｅｒＣｏｎｆｉｇ内に含まれる。ＲＬＣ－ＢｅａｒｅｒＣｏｎｆｉｇは、ＲＬＣエンティティと、（ＰＤＣＰエンティティへのリンク以外にも）アップリンクについてのＭＡＣにおける対応する論理チャネル（ＬＣＨ）を設定するために使用される。このように、ＵＥ２００（例えば、異なる論理チャネル）に対して異なるＲＬＣエンティティを設定でき、異なるＲＬＣエンティティは異なる設定、たとえば最大再送信回数に異なる値を設定することが可能である。

【0082】

ＲＬＦの現在の定義では、例えば５Ｇ ＮＲに対して現在定義されているように、１つの論理チャネル／ＲＬＣエンティティに対するＲＬＣ障害（例：ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄに到達した場合）は、ＲＬＦの宣言を意味し、次にすべてのＤＲＢの中断を意味し、これは他のＤＲＢ上のデータ伝送を中断する。

【0083】

例として、まず、ＲＬＣ障害が発生した場合、無線の状態および／またはプロトコルの問題が原因である可能性がある。無線障害が発生した場合は、ＲＬＣの再送信であっても、無線損失からの回復を助けることができないことを意味する。通常、無線リンク監視（ＲＬＭ）手順は、ＲＬＣ障害が発生する前に無線の問題を検出できることが期待できるが、（例えば、５Ｇ ＮＲに対して）現在定義されているＲＬＭ手順は、プライマリセル（ＰＣｅｌｌ）に制限されている。したがって、ＲＬＣ障害は、ＰＣｅｌｌだけの無線の問題ではなく、セカンダリセル（ＳＣｅｌｌ）の無線の問題またはプロトコルの障害（設定の問題を含む）が原因で発生する可能性がある。

【0084】

さらに、５Ｇ ＮＲでは「許可されたセル」の制限も導入され、ＬＣＨが使用できるのは、ＬＣＨのＲＬＣ障害がそのＬＣＨで許可されたセル（例えば、ライセンスされていないセル、高周波セルなどである）だけの問題になる可能性があるという点で、従来のＬＴＥとは異なる。信頼性が高く、チャネル品質が優れた異なるセルを使用している場合、ＬＣＨは他のＬＣＨに影響を与えないようにする必要がある。

【0085】

これは、いくつかの実施例によると、あるＲＬＣエンティティのＲＬＣ障害は、別の論理チャネルを適切にサポートできないことを意味しない場合があることを意味する。これは、異なるＱｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ（ＱｏＳ）要件を持つ異なるサービスタイプがデバイス内に共存している場合に特に関連する側面である。たとえば、超信頼性と低遅延の通信（ＵＲＬＬＣ）サービスに使用される論理チャネルからｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ値を達成することは、必ずしもより緩和されたＱｏＳ要件を持つ論理チャネル（大規模なマシンタイプ通信（ｍＭＴＣ）や拡張モバイルブロードバンド（ｅＭＢＢ）サービスをサポートするために使用される論理チャネルなど）の中断をトリガする必要はない。

【0086】

さらなる例として、第２に、ＲＬＣ障害によってトリガされる再確立は、（古いまたは新しいセルの）セル選択、選択されたセルへのランダムアクセス手順、および交換されるいくつかのＲＲＣメッセージを含むことがあるため、比較的遅い手順である可能性がある。プロトコル／設定の問題が原因でＲＬＣ障害が発生した場合、同じセル（例：影響を受けるＲＬＣエンティティの再設定）による回復試行が成功する可能性がある。しかし、それは再設立による不必要な遅延の後にのみ開始される。

【0087】

これを考慮して、いくつかの実施形態は、影響を受けたＲＬＣエンティティ（つまり、ＲＬＣ障害を検出したＲＬＣエンティティ）のより迅速な回復を目的とするＲＬＣ障害を処理する方法などの側面に対処すると同時に、影響を受けていないＲＬＣエンティティがサービスを継続できるようにする場合がある。

【0088】

いくつかの実施例によると、前述したように、ユーザ機器２００（図３）は、いくつかの実施例に従って、例えば装置１００を介した構成によって提供されるＲＬＣ障害構成ＲＬＣ＿ＦＣＦＧ（図４）を使用して、このようなＲＬＣ障害への対応方法を決定することができる。

【0089】

いくつかの実施例によれば、ＲＬＣ障害構成ＲＬＣ＿ＦＣＦＧは、ユーザ機器２００が第１の論理チャネルのＲＬＣ障害をネットワーク、例えば装置１００またはｇＮＢ１１０に通知すべきかどうかを定義する。

【0090】

いくつかの実施例によれば、ＲＬＣ障害構成は、ユーザ機器２００に関連付けられた少なくとも第２の論理チャネルが正常に動作したとき、すなわちＲＬＣ障害が発生しなかったときに、ユーザ機器２００が第１の論理チャネルのＲＬＣ障害をネットワークに通知すべきかどうかを定義する。いくつかの実施形態によれば、これは、例えば、ＲＬＦを宣言して再確立を開始するのではなく、少なくとも第２のＬＣＨおよび／またはそれに関連付けられたＲＢに対して、通常の、すなわち中断されない動作を維持することを可能にする。

【0091】

例として、ユーザ機器に関連付けられた第２の論理チャネルは、例えば第２の論理チャネルがＲＬＣ再送の所定回数（例：第１のしきい値または最大ＲＬＣ再送信回数）に達していない場合に、正常に動作する。

【0092】

いくつかの実施例によれば、ＵＥ２００は複数のＬＣＨおよび／またはＲＬＣエンティティで構成することができる。

【0093】

いくつかの実施例によると、ＵＥ２００は、ＵＥごとまたはＬＣＨごとに個別のＲＬＣ障害構成ＲＬＣ＿ＦＣＦＧを使用して設定することができる。ＬＣＨごとのＲＬＣ障害構成ＲＬＣ＿ＦＣＦＧの場合、異なるＲＬＣ障害構成の異なるＬＣＨを提供できる。

【0094】

いくつかの実施例によると、命令１０６（図１）は、少なくとも１つのプロセッサ１０２によって実行されると、さらに装置１００にユーザ機器２００をＲＬＣ障害構成ＲＬＣ＿ＦＣＦＧで明示的に構成させる。いくつかの実施例によれば、ＲＬＣ障害構成ＲＬＣ＿ＦＣＦＧは、例えばＵＥ２００のＲＬＣエンティティの構成のような、装置１００からＵＥ２００に送信される更なる情報と共に、明示的にＵＥ２００に提供され得る。

【0095】

いくつかの実施例によれば、ユーザ機器２００は、ＲＬＣ障害構成ＲＬＣ－ＦＣＦＧで暗黙的に構成することもできる。

【0096】

たとえば、マルチセルキャリア集約（ＣＡ）／デュアル接続（ＤＣ）シナリオに基づく可能性のあるいくつかの実施形態によると、ＬＣＨのＲＬＣ障害が再確立ではなくＲＬＣ障害レポートをトリガするかどうかをＬＣＨごとに設定することは、たとえば、ＬＣＨの許可されたセル設定に基づいて暗黙的に行われる可能性がある。

【0097】

いくつかの実施形態によれば、暗黙の設定は許容されるセル設定の一部であり、ＵＥ２００，２００’ごとに有効／無効にすることができる（図３）。たとえば、失敗したＬＣＨに対して許可されている設定済みセル、つまり第１のＬＣＨは、失敗したと見なすことができるため、少なくとも別のセルが失敗しておらず、少なくとも別のＬＣＨにマップされている限り、中断／非アクティブ化される可能性がある。これらの条件下では、いくつかの実施形態に従って、ＲＬＣ障害レポートが（ＲＲＣ）再確立なしでトリガされる可能性がある。いくつかの実施形態によれば、そうでない場合、例えば、他のセルも故障していたり、故障していない他のＬＣＨがセルにマップされていない場合、ＲＲＣの再確立が開始される。

【0098】

いくつかの実施形態では、許可されたセルは、無線エラーが発生しやすい可能性があるため、無許可セルおよび／または高周波セル（例えば、例えば３ＧＰＰ３８．１０１－１で定義されている周波数範囲ＦＲ を使用する場合、例えば３ＧＰＰ ＴＳ３８．１０１－１Ｖ１６．２．０（２０１９－１２）、表５．１－１）である。これにより、信頼性が高くチャネル品質が高い異なるセルを使用している場合に、これらのセルの問題が他のＬＣＨに影響を与えないようにする。

【0099】

いくつかの実施形態では、図５を参照すると、ＲＬＣ障害構成ＲＬＣ＿ＦＣＦＧは第１のしきい値Ｔ１で構成されており、ユーザ機器２００は第１のしきい値に基づいて、ＲＬＣ障害をネットワーク、例えばｇＮＢ１１０に送信するかどうかを決定することができる。

【0100】

いくつかの実施例では、第１のしきい値Ｔ１は所定の数のＲＬＣ再送信であってもよい。

【0101】

例えば、シングルセルのシナリオやマルチセルのＣＡ／ＤＣシナリオに基づいているかもしれないいくつかの実施形態によれば、第１のしきい値Ｔ１は、３ＧＰＰ ＴＳ３８．３３１（ｃｆ．例：３ＧＰＰ ＴＳ３８．３３１Ｖ１５．８．０（２０１９－１２））に従って、情報要素（ＩＥ）“ＲＬＣ－Ｃｏｎｆｉｇ”で設定される既存のしきい値パラメータ“ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ”を考慮した新しい（追加の）しきい値と見なすことができる。

【0102】

いくつかの実施形態によれば、第１の（すなわち、新しい）しきい値Ｔ１は、例えば、“ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ＿ＲＬＣＲｅｐｏｒｔ”と示され、例えば、現在のＲＬＣ ＡＭ再送信数が第１のしきい値に達した場合など、第１のＬＣＨのＲＬＣ障害を報告する（および／または）かどうか、および／またはＲＬＦ（例えば、現在のＲＬＣ ＡＭの再送信回数が、ＲＬＦ検出用に定義された既存のしきい値パラメータ“ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ”に達した場合）を宣言する（または、宣言するかどうかを決定する）ために、ＵＥ２００に設定されることがある。

【0103】

いくつかの実施形態によれば、第１のしきい値Ｔ１“ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ＿ＲＬＣＲｅｐｏｒｔ”の値は、例えば最初にレポートをトリガするために、既存の“ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ”よりも低く設定することができる。いくつかの実施例によると、これにより、ＲＬＦを宣言してすべてのＤＲＢを中断する前に、影響を受けた（第１の）ＬＣＨのプロトコルパラメータを再設定したり、許可されたセルやその他のＬＣＰ制限を変更したりすることによって、最初にＲＬＣ障害の問題を回復／解決する試みが可能になる。

【0104】

いくつかの実施形態によれば、ＲＬＣ障害構成ＲＬＣ－ＦＣＦＧ（図５）は、少なくとも１つのマッピング制限を無効にするかどうかをユーザ機器２００に示す第１の制御情報ＣＩ１を含む。

【0105】

例えば、シングルセルのシナリオやマルチセルのＣＡ／ＤＣシナリオに基づいているかもしれないいくつかの実施例によると、ＲＬＣエンティティ／ＬＣＨ（例えば、ＲＬＦ検出のために定義された最大数（例：既存の“ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ”）や、より低い設定された数、例えば、上記で説明したいくつかの実施形態による第１のしきい値に対応する）に対して所定の数のＲＬＣ ＡＭ再送信に達したことを検出した時点で、ＬＣＨがＬＣＰ（論理チャネル優先順位付け）マッピング制限（例：ａｌｌｏｗｅｄＣＧ＿ｌｉｓｔ、ａｌｌｏｗｅｄＰｒｉｏｒｉｔｙＬｅｖｅｌｓ、ａｌｌｏｗｅｄＳｅｒｖｉｎｇＣｅｌｌｓによる（例：３ＧＰＰ ＴＳ３８．３００Ｖ１５．８．０（２０１９－１２）、例：ｃｈａｐｔｅｒ１６．１．２））で設定されている場合、ＵＥ２００（図３）はそれらのマッピング制限（例えば、ＲＬＦをトリガーする代わりに）の少なくとも１つを無効にするかもしれず、これはできるだけ早く送信されるデータを取得するために有益であるかもしれず、いくつかの実施例によると「回復動作」のいくつかのアクションと例示的に呼ばれるかもしれない。

【0106】

いくつかの実施形態によれば、これらのマッピング制限のうち少なくとも１つの無効化は自動的に、すなわちＵＥ２００が明示的な指示を受信することなく実行される。

【0107】

いくつかの実施例によると、この「回復動作」を有効にするかどうかは、ネットワーク構成に依存する場合がある。設定（例えば、上記で説明したいくつかの実施例による第１のしきい値Ｔ１の可能性に加えて）は、無効にするＬＣＰマッピング制限（例えば、情報要素（ＩＥ）“ＲｅｓｔｒｉｃｔｉｏｎｓＤｉｓａｂｌｅＬｉｓｔ”を介して）を示す場合がある。例えば、いくつかの実施形態によれば、“ａｌｌｏｗｅｄＳｅｒｖｉｎｇＣｅｌｌｓ”に従って制限を無効にした後、ＵＥ２００は、影響を受けた（例：第１の）ＬＣＨに対して以前に制限されたセルに適用されるＵＬ許可を、そのＬＣＨからのデータで満たすことができる。いくつかの実施例によれば、同様に、その許可に対応する送信にそのＬＣＨのデータが存在することは、ＵＥ２００が（ＬＣＰマッピング）制限を無効にしたことをネットワークに対して暗黙的に示す可能性があり、さらに、上で説明したいくつかの実施例に従って、ＵＥ２００でＲＬＣ障害が発生したか、またはＵＥが第１のしきい値に達したことを示す可能性がある。

【0108】

いくつかの実施形態では、第１の制御情報ＣＩ１は、複数のマッピング制限のうちどれを無効にするかを示す。

【0109】

いくつかの実施形態によれば、ＲＬＣ障害構成ＲＬＣ－ＦＣＦＧ（図５）は、少なくとも１つの優先度しきい値Ｐ１、Ｐ２を含み、ここでユーザ機器２００は、少なくとも１つの優先度しきい値Ｐ１、Ｐ２に基づいて、ＲＬＣ障害をネットワークに送信するかどうかを決定することができる。

【0110】

いくつかの実施形態によれば、ユーザ機器２００は、少なくとも１つの優先度しきい値Ｐ１、Ｐ２と、（ａ）ユーザ機器２００に関連する論理チャネルの最低優先度、および（ｂ）第１の論理チャネルの優先度、のうちの少なくとも１つに基づいて、ＲＬＣ障害をネットワークに送信するかどうかを決定することができる。

【0111】

いくつかの実施例によれば、第１の優先度しきい値Ｐ１および第２の優先度しきい値Ｐ２は、例えばネットワークまたは事前設定によって提供される。

【0112】

例えば、シングルセルのシナリオやマルチセルのＣＡ／ＤＣシナリオに基づくいくつかの実施例によると、既存のすべての論理チャネルの最低優先度が第１の設定しきい値Ｐ１より低く、ＬＣＨがＲＬＣ障害を検出する優先度が第２のしきい値Ｐ２より高い場合、ＵＥ２００はＲＬＣ障害レポートＲＬＣ－ＦＲ（図４）をＮＷ１０または装置１００に送信する場合がある。いくつかの実施形態によると、ＲＬＣ障害を検出するＬＣＨと比較して、特定の（すなわち、消失しない）ＱｏＳの違いおよび／または設定の違いを持つ別のＬＣＨが設定されている場合、影響を受けるＬＣＨ（すなわち、ＲＬＣ障害を検出するＬＣＨ）からのＲＬＣ障害は、他のＬＣＨの障害を意味する必要はなく、したがって、他のＬＣＨに影響を与えるべきではない。あるいは、いくつかの実施形態によると、ＬＣＨまたは優先度しきい値ごとに設定され、設定されたしきい値よりも優先度が高いまたは低いＬＣＨに障害が発生した場合、ＲＬＣ障害レポートＲＬＣ－ＦＲがトリガされる。

【0113】

いくつかの実施形態によれば、命令１０６（図１）は、少なくとも１つのプロセッサ１０２によって実行されると、装置１００にさらに、例えばＬＣＨ／ＲＬＣエンティティのようなユーザ機器２００を、以下の（ａ）～（ｄ）うちの少なくとも１つを示す第２の制御情報ＣＩ２（図５）、例えばフラグ、で構成３００させる。
（ａ）ユーザ機器２００は、第１の論理チャネルのＲＬＣ障害を検出したときに無線リンク障害を宣言すべきである、
（ｂ）ユーザ機器２００は、例えばＲＬＣ障害レポートＲＬＣ－ＦＲの形で、第１の論理チャネルのＲＬＣ障害をネットワークに送信すべきである、
（ｃ）ユーザ機器２００は、第１の論理チャネル以外の少なくとも１つの論理チャネルのＲＬＣ障害を検出したときに無線リンク障害（ＲＬＦ）を宣言すべきである、
（ｄ）ユーザ機器２００は、第１の論理チャネル以外の少なくとも１つの論理チャネルのＲＬＣ障害を検出したときにＲＬＣ障害レポートを送信すべきである。

【0114】

いくつかの実施形態によれば、第２の制御情報ＣＩ２、例えばフラグは、ＬＣＨ／ＲＬＣエンティティおよび／または構成されたＬＣＨ／ＲＬＣエンティティのセットのＱｏＳ要件を考慮して設定することができる。

【0115】

いくつかの実施形態によれば、命令１０６は、少なくとも１つのプロセッサ１０２によって実行されると、装置１００に、さらに、少なくとも１つのユーザ機器固有の条件に基づいて、ＲＬＣ障害構成ＲＬＣ－ＦＣＦＧの少なくとも一部を設定させる。

【0116】

いくつかの実施例によれば、第１のしきい値Ｔ１の値、および／または無線リンク障害を宣言するおよび／またはＲＬＦ障害レポートを送信する条件は、ＵＥ固有の条件、たとえばＵＥ２００内の既存のサービス、およびオプションでそのＱｏＳ要件を考慮して設定することができる。例えば、いくつかの実施例では、ｅＭＢＢサービスとＵＲＬＬＣサービスの両方が共存している場合、ＵＲＬＬＣサービスからのＲＬＣ障害だけではＲＬＦを宣言できないことがある。

【0117】

いくつかの実施例によれば、１つのしきい値、または第１および第２のしきい値が設定されている場合があり、例えば既存の論理チャネルに対する５Ｇ ＮＲによって現在定義されている最大再送信回数パラメータ（つまり、ＲＬＣ－Ｃｏｎｆｉｇで設定された“ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ”）の最大値が第１の設定しきい値よりも高く、ＲＬＣ障害を検出するＬＣＨの“ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ”の値が第２の設定しきい値よりも低い場合、ＵＥ２００はＲＬＣ障害レポートをＮＷに送信することがある。このオプションでは、ＵＥ２００は宣言するＬＣＨ（ＲＬＦを宣言するＬＣＨ）と他のＬＣＨとの間でｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄに関して大きな違いを保証できる。したがって、影響を受けるＲＬＣエンティティのＲＬＣ障害が別のＬＣＨの動作に影響を与えることはない。

【0118】

いくつかの実施形態によれば、命令１０６は、少なくとも１つのプロセッサ１０２によって実行されると、装置１００にＲＬＣ障害構成ＲＬＣ－ＦＣＦＧ（図３）の少なくとも一部、例えば第１のしきい値、第２のしきい値の少なくとも１つをブロードキャストさせる。

【0119】

いくつかの実施形態によれば、装置１００またはネットワークは、ＲＬＣ障害構成の少なくとも１部、例えば、システム情報ブロック（ＳＩＢ）内の第１のしきい値、第２のしきい値の少なくとも１つをブロードキャストすることができる。

【0120】

さらなる実施例は、プロセッサ２０２と命令２０６を格納するメモリ２０４を含むＵＥ２００（図２）と関連し、ここで、命令２０６は少なくとも１つのプロセッサ２０２によって実行されたときに、ユーザ機器２００に、図６のフローチャートを参照して、少なくとも無線リンク制御（ＲＬＣ）障害構成ＲＬＣ－ＦＣＦＧを決定させる。無線リンク制御（ＲＬＣ）障害構成ＲＬＣ－ＦＣＦＧは、ーザ機器２００に関連する第１の論理チャネルのＲＬＣ障害にユーザ機器２００がどのように対応すべきかを定義している。

【0121】

いくつかの実施例によれば、ＲＬＣ障害構成ＲＬＦ－ＦＣＦＧを決定すること３５０は、装置、例えば実施例に関連する装置１００からＲＬＣ障害構成ＲＬＣ－ＦＣＦＧを受け取る（例えば、明示的な構成を持つ実施形態の場合）こと、および／または他のデータおよび／または構成（例えば、暗黙的な構成を持つ実施形態の場合）からＲＬＣ障害構成ＲＬＣ－ＦＣＦＧを決定するｇＮＢ１１０の少なくとも１つを含むことができる。

【0122】

いくつかの実施例によれば、ユーザ機器におけるＲＬＣ障害構成の少なくとも一部は、例えば３ＧＰＰ技術仕様のように規格において規定されている場合があり、および／またはＵＥ実装によって準備されている場合がある。

【0123】

いくつかの実施例によれば、命令２０６は、少なくとも１つのプロセッサ２０２によって実行されると、ユーザ機器２００にさらに、ＲＬＣ障害構成ＲＬＣ－ＦＣＦＧに基づいて、ユーザ機器２００がネットワークへの第１の論理チャネルのＲＬＣ障害を通知すべきかどうか（例えば、ユーザ機器２００に関連する少なくとも第２の論理チャネルが正常に動作している場合）を判断（３５２）させる。

【0124】

いくつかの実施形態によれば、命令２０６は、少なくとも１つのプロセッサ２０２によって実行されると、さらにユーザ機器２００に、少なくとも１つの論理チャネルに対して許可されたセルの構成に基づいて、ＲＬＣ障害構成ＲＬＣ－ＦＣＦＧを決定（３６０）させる（図７）。

【0125】

いくつかの実施形態によれば、ＲＬＣ障害構成は、第１のしきい値Ｔ１を含み、命令２０６は、少なくとも１つのプロセッサ２０２によって実行されると、さらにユーザ機器２００に、第１のしきい値Ｔ１に基づいて、ＲＬＣ障害をネットワークに送信するかどうかを決定（３６２）させる（図７）。

【0126】

いくつかの実施形態によれば、ＲＬＣ障害構成は、少なくとも１つのマッピング制限を無効にするかどうかをユーザ機器２００に示す第１の制御情報ＣＩ１を含み、ここで、命令２０６は、少なくとも１つのプロセッサ２０２によって実行されると、さらに、ユーザ機器２００に、第１の制御情報に基づいて、少なくとも１つのマッピング制限を無効にさせる（３６４）（図７）。

【0127】

いくつかの実施形態によれば、ＲＬＣ障害構成ＲＬＣ－ＦＣＦＧは、少なくとも１つの優先度しきい値Ｐ１、Ｐ２を含み、ここで、命令２０６は、少なくとも１つのプロセッサ２０２によって実行されると、さらに、少なくとも１つの優先度しきい値に基づいて、そして任意で、
（ａ）ユーザ機器に関連する論理チャネルの最低優先度、
（ｂ）第１の論理チャネルの優先度、
のうちの少なくとも１つに基づいて、ユーザ機器２００に、ＲＬＣ障害をネットワークに送信するかどうかを決定させる。

【0128】

いくつかの実施形態によれば、命令２０６は、少なくとも１つのプロセッサ２０２によって実行されると、さらにユーザ機器２００に、第１のセルによって提供される論理チャネルについて所定の数のＲＬＣ再送信に達したかどうかを判断させ、論理チャネルについて所定の数のＲＬＣ再送信に達した場合には、第１のセルによって提供されるさらに少なくとも１つの論理チャネルが所定の数のＲＬＣ再送信に達していない場合に、論理チャネルについてＲＬＣ障害をネットワークに送信させる。

【0129】

いくつかの実施形態によれば、命令２０６は、少なくとも１つのプロセッサ２０２によって実行されると、ユーザ機器２００にさらに、第１品質しきい値よりも良好な無線チャネル品質を持つ別のセルを再選択できるかどうかを決定し、第１品質しきい値よりも良好な無線チャネル品質を持つ別のセルを再選択できる場合は、ＲＬＣ障害構成に基づいて他のセルとの無線リソース制御（ＲＲＣ）接続を再確立し、第１品質しきい値よりも良好な無線チャネル品質を持つ別のセルを再選択できない場合は、ＲＬＣ障害構成に基づいて現在のサービングセルにＲＬＣ障害レポートを送信するかどうかを決定させる。

【0130】

いくつかの実施例によれば、ＵＥの上位層は、例えば装置１００および／またはネットワークまたはｇＮＢ１１０によって、ＲＬＣエンティティからのＲＬＣ障害の報告を受けたときに異なる動作をするように設定されている場合がある。いくつかの実施例によれば、上位層はＲＬＣ障害によって影響を受けたサービスを分析する場合がある（つまり、ＲＬＣ障害を検出した論理チャネルで送信されるデータを持つサービス）。

【0131】

いくつかの実施例によると、ＵＥ２００の上位層は、例えば第１のＬＣＨのＲＬＣ障害のために、特定のサービス／アプリケーションがこれ以上サポートできないかどうかをチェックする場合がある。いくつかの実施例によると、サービスが厳格なＱｏＳ要件を持つ場合、ＬＣＨがＲＬＣ障害を検出できないため、サービスを停止する必要があると考えられる。この場合、いくつかの実施例によると、このサービスが複数のＬＣＨを使用し、これらのＬＣＨの一部がこのサービスによってのみ使用される場合、ＲＬＣ障害メッセージには、影響を受けるサービスによってのみ使用されるＬＣＨ／ＲＢを中断するための情報／推奨事項も含まれる場合がある。これにより、影響を受けるサービスのみを提供するＬＣＨが中断される可能性がある。いくつかの実施形態によれば、中断後、ＬＣＨは再開および／または再構成されるまで、続く伝送では使用されない。

【0132】

いくつかの実施例によれば、影響を受けたサービスがパフォーマンスの低下に耐えるように自身を調整できる場合、ＵＥ２００は、ＲＬＣ障害レポートＲＬＣ－ＦＲに対応する表示を含めるなどして、ＲＬＣ障害レポートＲＬＣ－ＦＲ（図３）でこれを示すことができる。いくつかの実施形態によると、この表示は、影響を受けたＬＣＨ／ＤＲＢを再設定するか、または中断するかを決定する柔軟性をＮＷに提供する可能性がある。いくつかの実施例によると、やはり、影響を受けたサービスのみを提供するＬＣＨの表示をＲＬＣ障害レポートに含めることができるため、ＮＷはより良い知識で決定を下すことができる。

【0133】

図８は、いくつかの実施例による方法の単純化されたフローチャートを概略的に示している。ステップ４００では、ＵＥ２００（図３）に複数のＬＣＨ／ＲＬＣエンティティを設定し、ＲＬＣ障害構成ＲＬＣ－ＦＣＦＧ、たとえばＬＣＨごとのＲＬＣ障害構成ＲＬＣ－ＦＣＦＧを設定できる。ステップ４０１で、ＵＥ２００はＬＣＨ（つまり、ステップ４００で設定された複数のＬＣＨの内の１つ）に対してＲＬＣ障害が検出されたかどうかを判断する。検出されていない場合は、ステップ４０１に戻る。ＬＣＨ、すなわち第１のＬＣＨに対してＲＬＣ障害が検出された場合、方法はステップ４０２に進み、ＲＬＣ障害の影響を受けたＲＬＣエンティティがＵＥのＲＲＣ層に指示を送信する。ステップ４０３では、ＲＬＣ障害構成ＲＬＣ－ＦＣＦＧに基づいて、ＲＬＣ障害レポートをトリガするかどうかがＵＥ２００によって決定される。ステップ４０３でＲＬＣ障害レポートをトリガすることが決定された場合、方法はステップ４０４に進み、ＵＥ２００はＲＬＣ障害レポートＲＬＣ－ＦＲ（図４）をネットワーク（例えば、装置１００および／またはｇＮＢ１１０）に送信し、および／または、いくつかの実施形態によると、設定されている場合は、マッピング制限の少なくとも１つを無効にする。たとえば、影響を受けるＬＣＨに対して許可されているセル制限を無効にする。

【0134】

ステップ４０３でＲＬＣ障害レポートをトリガしないと判断された場合、メソッドはステップ４０５に進み、ＲＬＦ宣言がトリガされたかどうかが判断される。ＲＬＦ宣言がトリガされた場合、方法はステップ４０６に進み、ＵＥ２００はＲＲＣ再確立手順を開始する。ＲＬＦ宣言がトリガされていない場合、メソッドはステップ４０１に進む。いくつかの実施形態では、有利には、ＲＲＣ再確立手順（図８のステップ４０６参照）は避けてもよい。代わりに、ステップ４０４を実行してもよい。

【0135】

図９は、いくつかの実施例による方法の単純化されたフローチャートを概略的に示している。なお、わかりやすくするためにユーザープレーンの伝送は記載していない。参照符号４１０は、ＵＥ２００の１つ以上のＲＬＣエンティティに対する設定ＲＬＣ－Ｃｏｎｆｉｇをシンボル化している。いくつかの実施例によれば、構成４１０は、例えば第１のしきい値Ｔ１（図５参照）および／または、例えばＵＬ－ＡＭ－ＲＬＣについての上述の“ＲｅｓｔｒｉｃｔｉｏｎｓＤｉｓａｂｌｅＬｉｓｔ”ＩＥを含むいくつかの実施例に従うＲＬＣ障害構成ＲＬＣ－ＦＣＦＧ（図３も参照）を含むこともできる。参照符号４１１は、例えば、ａｌｌｏｗｅｄＣＧ＿ｌｉｓｔ、ａｌｌｏｗｅｄＰｒｉｏｒｉｔｙＬｅｖｅｌｓ、ａｌｌｏｗｅｄＳｅｒｖｉｎｇＣｅｌｌｓ（例えば、３ＧＰＰ ＴＳ３８．３００Ｖ１５．８．０（２０１９－１２）、例えば第１６．１．２章参照）に従ってＬＣＰマッピング制限を特徴付けるＬＣＰ制限設定をシンボル化する。ブロック４１２は、ＵＥ２００によって実行される無線リンク監視（ＲＬＭ）のステップを示し、ブロック４１３は、ＲＬＣ障害レポートの設定されたトリガの検出を示し、いくつかの実施形態によると、以前に設定されたようにＬＣＰ制限を無効にする（参照記号４１１を参照）。矢印４１４は、ＲＬＣ障害情報のｇＮＢ１１０への送信を示し、ブロック４１５は、例えば、ＲＬＣ障害情報に基づき、ＲＬＣ障害情報の受信時などに実行されるネットワークアクションを特徴付ける。いくつかの実施例によれば、ネットワークアクション４１５は再構成を含むことができる。したがって、矢印４１６は、例えば（新しい）ＲＬＣ構成を含むＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎのような、ＵＥ２００への再設定メッセージを表すことができる。ブロック４１７は、ＵＥがＲＬＣ障害の影響を受けたＬＣＨを再構成することを示しており、いくつかの実施形態によると、以前に無効にされた（ブロック４１３参照）ＬＣＰ制限を有効にすることも含む場合がある。または、４１６で受信した再構成メッセージに基づいて、ＵＥがブロック４１７でＬＣＰ制限を有効にすることもできる。

【0136】

図１０は、いくつかの実施例による方法の単純化されたフローチャートを概略的に示している。なお、図９と同様に、わかりやすくするためにユーザープレーンの伝送は示していない。図９の矢印４１０と同様に、図１０の参照符号４２０は、ＵＥ２００の１つ以上のＲＬＣエンティティの構成ＲＬＣ－Ｃｏｎｆｉｇをシンボル化している。いくつかの実施例によれば、構成４２０は、第１のしきい値Ｔ１（図５を参照）および／または例えばＵＬ－ＡＭ－ＲＬＣについての上で説明した“ＲｅｓｔｒｉｃｔｉｏｎｓＤｉｓａｂｌｅＬｉｓｔ”ＩＥを例えば含むいくつかの実施例に従うＲＬＣ障害構成ＲＬＣ－ＦＣＦＧ（図３も参照）を含むこともできる。参照符号４２１はＬＣＰ制限構成をシンボル化しており、例えば前述のように、ａｌｌｏｗｅｄＣＧ＿ｌｉｓｔ、ａｌｌｏｗｅｄＰｒｉｏｒｉｔｙＬｅｖｅｌｓ、ａｌｌｏｗｅｄＳｅｒｖｉｎｇＣｅｌｌｓに従うＬＣＰマッピング制限を特徴付ける。図９のブロック４１２、４１３と同様に、図１０のブロック４２２、４２３は、ＵＥ２００（ブロック４２２）によって実行される無線リンク監視（ＲＬＭ）のステップと、ＲＬＣ障害レポート用に設定されたトリガの検出を示し、いくつかの実施形態によれば、以前に構成されたようにＬＣＰ制限を無効にする（参照符号４２１（ブロック４２３）を参照）。

【0137】

いくつかの実施例によれば、ＵＥ２００がＬＣＰ制限を無効にしたことをネットワークがアップリンク受信から検出すると、ＲＬＣ障害情報がネットワークに暗黙的に示されることもある。

【0138】

いくつかの実施形態によれば、例えば、レガシーネットワークアクションのように、以下のネットワークアクションの１つ以上が実行されることがあり、これはＲＬＣ障害表示（例えば図９の矢印４１４参照）を受信することによってトリガされる。いくつかの実施例によると、ネットワークアクションは、ＲＬＣ障害の影響を受けたＬＣＨ／ＲＢのサービスの回復を試みるために行われる場合がある。－ＮＷは、ＵＥ２００の他のサービスを継続しながら、影響を受けるＤＲＢを中断することを決定する場合がある。
－ ＮＷは、影響を受けるＬＣＨエンティティを中断し、影響を受けるＤＲＢ／ＬＣＨのトラフィックを、影響を受けないＬＣＨエンティティにマッピングすることによって、影響を受けるＲＢ／ＬＣＨのサービスを継続することを決定する場合がある。
－ ＮＷは、影響を受けるサービスを継続的に提供できるように、影響を受けるＤＲＢ／ＬＣＨを再設定する場合がある。
－ ＮＷは、ＲＬＣ障害を宣言するＤＲＢ／ＬＣＨと同様またはより厳密なＱｏＳ要件を持つ他のＤＲＢ／ＬＣＨを事前に再設定できる。いくつかの実施例によれば、例えばパラメータ“ｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ”を増加させることによる積極的な再構成は、将来他のＲＢに影響を与えるＲＬＣ障害を潜在的に回避することにより、検討されているＤＲＢ／ＬＣＨのより良いサービス継続性を達成するのに役立つ。
－ ＮＷは、例えば、代替的に、サービングセルまたはサービングバンド幅の変更をトリガするように決定することもできる。たとえば、ＮＷが同じまたは異なるＲＬＣエンティティから複数のＲＬＣ障害レポートを受信した場合、ＮＷはサービングセルの非アクティブ化、サービングビームの再設定、ＢＷＰ（帯域幅部分）のスイッチングまたはハンドオーバーなどをトリガすることを決定できる。

【0139】

いくつかの実施形態によれば、ＲＬＣ障害の影響を受けるＲＢ／ＬＣＨは、複製で設定されない（「非複製シナリオ」）。

【0140】

いくつかの実施形態によれば、セルで動作するＬＣＨ／ＲＢの障害は、セル全体の動作を中断するのではなく、影響を受けたＬＣＨのみを中断することにつながる可能性がある。

【0141】

いくつかの実施形態によれば、ＲＬＣ障害が１つのＲＢに影響を及ぼしているにもかかわらず、１つ以上のサービスを他のＲＢに対して継続することができ、その間、ネットワークは、影響を受けたＲＢのＲＬＣ障害に関連する問題を、例えば可能な限り迅速に治療し、その結果、回復時間を短縮することができる。いくつかの実施形態によれば、回復が試みられている間、影響を受けた（失敗した）ＲＬＣ／ＬＣＨは、元々そのセルが許可されていなかった（すなわち、いくつかの実施例に従ったＲＬＣ障害時のＬＣＰマッピング制限の無効化）としても、中断されていない任意のセルを使用してサービスすることができる。

【0142】

つまり、ほとんどのシナリオでは、ＲＬＣ障害レポートはＲＬＦレポートと同時に、またはＲＬＦレポートよりも早くネットワークで受信される必要があるため、一部の実施形態では、従来のアプローチ（例：ＲＬＦおよびＲＲＣの再確立のトリガ）と比較して、ＲＢに影響を与えるＲＬＣ障害の解決に追加の遅延を導入しない。

【0143】

いくつかの詳細および実施例は、いくつかの実施例に従うＵＥとネットワークの間の無線インターフェイス、例えばｇＮＢを使用するが、基本的な原則は、例えばＰＣ５－ＲＲＣ接続の下で、２つのユーザデバイス、例えばＵＥ間のサイドリンク通信に使用される可能性のあるサイドリンク（ＳＬ）ＲＬＣエンティティのＲＬＣ障害を処理するために、他の通信および／または無線インターフェイスにも適用される場合がある。

【0144】

例えば、いくつかの実施例によれば、２つのＳＬ ＵＥ間のＳＬ ＬＣＨの送信は、複数のＳＬキャリアまたは２つのリソースプールを介して行われる可能性があり、したがって、いくつかの実施例に従ったマルチセルシナリオのための提案された解決策は、複数のＳＬキャリアまたは複数のＳＬリソースプールを介したＳＬ送信を考慮することによって適用することができる。

【0145】

他の実施例では、単一セルシナリオに対して示されたいくつかの実施例のアプローチを、単一のＳＬキャリアまたは単一のＳＬリソースプールを介して２つのＳＬ ＵＥ間でＳＬ ＬＣＨを送信するために適用することができる。いくつかの実施例に従って提案された方式をＳＬ通信に適用することは、例えばＰＣ５－ＲＬＣ宣言を回避し、ＳＬ ＲＬＣ障害が１つのＳＬ ＲＬＣエンティティ／ＬＣＨに影響を与えているにもかかわらず、他のＳＬ ＲＬＣエンティティ／ＬＣＨに対してサービスを継続できるようにするなど、ＵＥとネットワーク間の通信についていくつかの実施例を参照して説明したのと同様の利点を持つことができる。

【0146】

なお、サイドリンク通信の場合、ＳＬの伝送モードやＵＥのＲＲＣ状態に応じて、ＵＥのＳＬ ＲＢ／ＲＬＣエンティティ／ＬＣＨの（再）設定をＳＬ ＵＥ自身で行う場合とネットワークで行う場合がある。

【0147】

添付図面の例を参照して上記のいくつかの実施形態を説明したが、実施形態はそれに限定されるものではなく、添付の請求項の範囲内でいくつかの方法で修正することができることは明らかである。したがって、すべての単語と表現は広く解釈されるべきであり、それらは実施形態を制限するものではなく、例示することを意図している。技術の進歩に伴い、実施形態に従った概念が様々な方法で実装できることは、当業者には明らかであろう。さらに、記載された実施形態は、様々な方法で他の実施形態と組み合わせることができるが、そうする必要はないことは、当業者には明らかである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】