特許 7392722 マスターノード、セカンダリノード、及びこれらの方法

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

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

(11)【特許番号】

(24)【登録日】2023-11-28

(45)【発行日】2023-12-06

(54)【発明の名称】マスターノード、セカンダリノード、及びこれらの方法

(51)【国際特許分類】

   H04W 76/19 20180101AFI20231129BHJP

   H04W 76/34 20180101ALI20231129BHJP

   H04W 72/0457 20230101ALI20231129BHJP

   H04W 16/14 20090101ALI20231129BHJP

   H04W 76/15 20180101ALI20231129BHJP

【ＦＩ】

H04W76/19

H04W76/34

H04W72/0457 110

H04W16/14

H04W76/15

【請求項の数】 10

(21)【出願番号】P 2021536652

(86)(22)【出願日】2020-06-17

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

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

(87)【国際公開日】2021-02-04

【審査請求日】2022-01-05

(31)【優先権主張番号】P 2019139251

(32)【優先日】2019-07-29

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100103894

【弁理士】

【氏名又は名称】家入 健

(72)【発明者】

【氏名】二木 尚

(72)【発明者】

【氏名】林 貞福

【審査官】桑原 聡一

(56)【参考文献】

【文献】Huawei, HiSilicon，Discussion on MCG failure recovery via SRB3[online]，3GPP TSG RAN WG2 #106 R2-1907497，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_106/Docs/R2-1907497.zip>，2019年05月13日，第２節

【文献】Google Inc.，Correction to RRC transfer[online]，3GPP TSG RAN WG3 #103 R3-191154，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_103/Docs/R3-191154.zip>，2019年02月25日，第９．１．２．２０節

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

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

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

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

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１、４

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

【請求項1】

マスターノードとのデュアルコネクティビティにおけるセカンダリノードのための方法であって、
前記セカンダリノードに関連するサービングセルのグループであるSecondary Cell Group (SCG)を使用してユーザ端末と通信すること、
前記デュアルコネクティビティに関する前記セカンダリノード内の設定又はリソースの修正に関連し、且つ前記マスターノードに関連するサービングセルのグループであるMaster Cell Group (MCG)の無線リンク障害の回復に前記修正が関連することを示す第１のメッセージを前記マスターノードから受信すること、
前記MCGの無線リンク障害の回復に関連するRadio Resource Control (RRC) Reconfigurationメッセージを含むRRC Transferメッセージを前記マスターノードから受信すること、及び
前記RRC Reconfigurationメッセージを、前記セカンダリノードと前記ユーザ端末の間に直接的に設定されたシグナリング無線ベアラを介して前記ユーザ端末に送信すること、
を備える方法。

【請求項2】

前記RRC Transferメッセージは、前記RRC Reconfigurationメッセージが前記MCGの無線リンク障害の回復に関連することを前記セカンダリノードに示す情報を含む、請求項１に記載の方法。

【請求項3】

セカンダリノードとのデュアルコネクティビティにおけるマスターノードのための方法であって、
前記マスターノードに関連するサービングセルのグループであるMCGを使用してユーザ端末と通信すること、及び
前記デュアルコネクティビティに関する前記セカンダリノード内の設定又はリソースの修正に関連し、且つ前記MCGの無線リンク障害の回復に前記修正が関連することを示す第１のメッセージを前記セカンダリノードに送信すること、
を備える、
方法。

【請求項4】

前記MCGの無線リンク障害の回復に関連するRadio Resource Control (RRC) Reconfigurationメッセージを含むRRC Transferメッセージを前記セカンダリノードに送信することをさらに備え、
前記RRC Reconfigurationメッセージは、前記セカンダリノードと前記ユーザ端末の間に直接的に設定されたシグナリング無線ベアラを介して前記ユーザ端末に送信される、
請求項３に記載の方法。

【請求項5】

前記RRC Transferメッセージは、前記RRC Reconfigurationメッセージが前記MCGの無線リンク障害の回復に関連することを前記セカンダリノードに示す情報を含む、請求項４に記載の方法。

【請求項6】

マスターノードとのデュアルコネクティビティにおけるセカンダリノードであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと
を備え、
前記少なくとも１つのプロセッサは、
前記セカンダリノードに関連するサービングセルのグループであるSecondary Cell Group (SCG)を使用してユーザ端末と通信し、
前記デュアルコネクティビティに関する前記セカンダリノード内の設定又はリソースの修正に関連し、且つ前記マスターノードに関連するサービングセルのグループであるMaster Cell Group (MCG)の無線リンク障害の回復に前記修正が関連することを示す第１のメッセージを前記マスターノードから受信し、
前記MCGの無線リンク障害の回復に関連するRadio Resource Control (RRC) Reconfigurationメッセージを含むRRC Transferメッセージを前記マスターノードから受信し、
前記RRC Reconfigurationメッセージを、前記セカンダリノードと前記ユーザ端末の間に直接的に設定されたシグナリング無線ベアラを介して前記ユーザ端末に送信する、
よう構成される、セカンダリノード。

【請求項7】

前記RRC Transferメッセージは、前記RRC Reconfigurationメッセージが前記MCGの無線リンク障害の回復に関連することを前記セカンダリノードに示す情報を含む、請求項６に記載のセカンダリノード。

【請求項8】

セカンダリノードとのデュアルコネクティビティにおけるマスターノードであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと
を備え、
前記少なくとも１つのプロセッサは、
前記マスターノードに関連するサービングセルのグループであるMCGを使用してユーザ端末と通信し、
前記デュアルコネクティビティに関する前記セカンダリノード内の設定又はリソースの修正に関連し、且つ前記MCGの無線リンク障害の回復に前記修正が関連することを示す第１のメッセージを前記セカンダリノードに送信する、
よう構成される、
マスターノード。

【請求項9】

前記少なくとも１つのプロセッサは、前記MCGの無線リンク障害の回復に関連するRadio Resource Control (RRC) Reconfigurationメッセージを含むRRC Transferメッセージを前記セカンダリノードに送信するよう構成され、
前記RRC Reconfigurationメッセージは、前記セカンダリノードと前記ユーザ端末の間に直接的に設定されたシグナリング無線ベアラを介して前記ユーザ端末に送信される、
請求項８に記載のマスターノード。

【請求項10】

前記RRC Transferメッセージは、前記RRC Reconfigurationメッセージが前記MCGの無線リンク障害の回復に関連することを前記セカンダリノードに示す情報を含む、請求項９に記載のマスターノード。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、無線通信システムに関し、特にmulti-connectivity（e.g., Dual Connectivity）でのマスターセルグループ（Master Cell Group（MCG））の障害の回復に関する。

【背景技術】

【0002】

The 3rd Generation Partnership Project（3GPP）では、Multi-Radio Dual Connectivity（MR-DC）が行われているときのMCG障害の速やかな回復（fast recovery）が議論されている（例えば、非特許文献１－５を参照）。MCG障害は、例えば無線リンク切断（Radio Link Failure（RLF））である。Fast MCG Recoveryは、MR-DCが行われるときのMCG障害の回復のために、セカンダリノード（SN）により提供されるSecondary Cell Group（SCG）を介したマスターノード（MN）とUser Equipment（UE）の間のシグナリングの送信を利用する。これにより、Fast MCG Recoveryは、Radio Resource Control (RRC) connection re-establishmentではなく他の方法、例えばintra-MNハンドオーバ手順又はinter-MNハンドオーバ手順を利用してMCGリンク（又はMCG障害）の早い復旧（recovery）を可能にする。5G NRでは、Reconfiguration with syncと呼ばれる手順が規定され、これがハンドオーバ並びにMR-DCのPSCell（Primary SCG CellまたはPrimary Secondary Cell）change及びSN changeにおいて利用される。本明細書におけるintra-MNハンドオーバ及びinter-MNハンドオーバは、当該ハンドオーバ手順内でのMR-DCのSN解放を含んでもよい。本明細書におけるinter-MNハンドオーバは、MNとSNの間の役割変更（role changeを含んでもよい。当該役割変更では、ハンドオーバ前のMR-DCのSN（及びMN）がハンドオーバ手順においてMR-DCのMN（及びSN）に変更される。

【0003】

Fast MCG recoveryに必要なシグナリング（i.e., MN RRC messages）は、MNとUEの間で、Split Signaling Bearer1（SRB1）のSCG leg又はSRB3を介して転送される。Split SRB1は、RRC messagesのためのMNとUEの間のSRBであり、MCG内のRadio Link Control (RLC) bearer及びSCG内のRLC bearerを備える。Split SRB1は、MCG及びSCGを介した送信をサポートし、MNによって生成されたRRC Protocol Data Units (PDUs)の複製（duplication）を可能にする。ただし、Split SRB1で送信されるMN RRC messagesはMNのセキュリティ鍵で保護されるため、SNは、MN RRC messagesのコンテンツを知ることができず、MN RRC messagesを透過的に（transparently）UEへ送信する。Split SRB のMCG内及びSCG内のRLC bearersは、それぞれMCG leg（又はMCG部分）及びSCG leg（又はSCG部分）と呼ばれる。一方、SRB3は、SNとUEの間の直接的なSRBであり、SNがSN RRCメッセージをDC中のUEにSCGセルで送信するために使用されることができる。なお、Fast MCG recoveryは、Access Stratum（AS）レイヤのセキュリティが活性化され（activated）、SRB2と少なくとも１つのDRBが確立された後にだけトリガ（実行）されてもよい。

【先行技術文献】

【非特許文献】

【0004】

【文献】Ericsson: “Fast MCG recovery in MR-DC”, 3GPP TSG-RAN WG2#105 R2-1901414, February 2019

【文献】Ericsson: “Fast MCG recovery in (NG)EN-DC”, 3GPP TSG-RAN WG2#105 R2-1901416, February 2019

【文献】Qualcomm Incorporated: “Fast Recovery from MCG failure”, 3GPP TSG-RAN WG2#105 R2-1900113, February 2019

【文献】Huawei, HiSilicon: “MCG failure recovery via split SRB1”, 3GPP TSG-RAN WG2 #106 R2-1907493, May 2019

【文献】Huawei, HiSilicon: “Discussion on MCG failure recovery via SRB3”, 3GPP TSG-RAN WG2#106 R2-1907497, May 2019

【発明の概要】

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

【0005】

発明者等は、fast MCG recoveryについて検討し、様々な課題を見出した。例えば、MCG リンクを復旧するためのハンドオーバ手順では、SN内の設定又はリソースの修正（modification）又は解放（release）が必要とされるかもしれない。しかしながら、上述のように、fast MCG recoveryでは、MNとUEの間のシグナリング（MN RRC messages）がSNを介して転送される。したがって、SNは、MNとUEの間のMN RRC messageの転送を妨げないように、SN内の設定又はリソースの修正（modification）又は解放（release）を行うタイミングをコントロール（又は調整）する必要があるかもしれない。

【0006】

本明細書に開示される実施形態が達成しようとする目的の１つは、MCG障害（又はMCGリンク）の回復のためにMNからSNに送られるSN設定（又はリソース）の修正又は解放に関するメッセージを他のメッセージと区別することをSNに可能にする装置、方法、及びプログラムを提供することである。なお、この目的は、本明細書に開示される複数の実施形態が達成しようとする複数の目的の１つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。

【課題を解決するための手段】

【0007】

第１の態様では、マスターノードは、少なくとも１つのメモリ、及び前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサを含む。前記少なくとも１つのプロセッサは、前記マスターノードにより提供されるMaster Cell Group（MCG）及びセカンダリノードにより提供されるSecondary Cell Group（SCG）を使用することを無線端末に可能にするdual connectivityをサポートするよう構成される。前記少なくとも１つのプロセッサは、さらに、前記dual connectivityに関する前記セカンダリノード内の設定又はリソースの修正又は解放に関連する第１のメッセージを前記セカンダリノードに送るよう構成される。前記第１のメッセージは、前記修正又は前記解放が前記MCGの障害（failure）又は前記MCGの前記障害の回復に関連することを明示的又は暗示的に示す。

【0008】

第２の態様では、セカンダリノードは、少なくとも１つのメモリ、及び前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサを含む。前記少なくとも１つのプロセッサは、マスターノードにより提供されるMaster Cell Group（MCG）及び前記セカンダリノードにより提供されるSecondary Cell Group（SCG）を使用することを無線端末に可能にするdual connectivityをサポートするよう構成される。加えて、前記少なくとも１つのプロセッサは、前記dual connectivityに関する前記セカンダリノード内の設定又はリソースの修正又は解放に関連する第１のメッセージを前記マスターノードから受信するよう構成される。前記第１のメッセージは、前記修正又は前記解放が前記MCGの障害（failure）又は前記MCGの前記障害の回復に関連することを明示的又は暗示的に示す。さらに、前記少なくとも１つのプロセッサは、前記MCGの前記障害の回復に関連し且つ前記マスターノードから送られるRadio Resource Control（RRC）メッセージを、前記セカンダリノードと前記無線端末の間に直接的に設定されたシグナリング無線ベアラを介して、前記無線端末に送信するよう構成される。

【0009】

第３の態様では、マスターノードにより行われる方法は、（ａ）前記マスターノードにより提供されるMaster Cell Group（MCG）及びセカンダリノードにより提供されるSecondary Cell Group（SCG）を使用するdual connectivityを無線端末に可能にするために前記マスターノードを制御すること、及び（ｂ）前記dual connectivityに関する前記セカンダリノード内の設定又はリソースの修正又は解放に関連する第１のメッセージを前記セカンダリノードに送ること、を含む。前記第１のメッセージは、前記修正又は前記解放が前記MCGの障害（failure）又は前記MCGの前記障害の回復に関連することを明示的又は暗示的に示す。

【0010】

第４の態様では、セカンダリノードにより行われる方法は、（ａ）マスターノードにより提供されるMaster Cell Group（MCG）及び前記セカンダリノードにより提供されるSecondary Cell Group（SCG）を使用するdual connectivityを無線端末に可能にするために前記セカンダリノードを制御すること、（ｂ）前記dual connectivityに関する前記セカンダリノード内の設定又はリソースの修正又は解放に関連するする第１のメッセージを前記マスターノードから受信すること、及び（ｃ）前記MCGの障害（failure）の回復に関連し且つ前記マスターノードから受信するRadio Resource Control（RRC）メッセージを、前記セカンダリノードと前記無線端末の間に直接的に設定されたシグナリング無線ベアラを介して、前記無線端末に送信すること、を含む。前記第１のメッセージは、前記修正又は前記解放が前記MCGの前記障害又は前記MCGの前記障害の回復に関連することを明示的又は暗示的に示す。

【0011】

第５の態様では、プログラムは、コンピュータに読み込まれた場合に、上述の第３又は第４の態様に係る方法をコンピュータに行わせるための命令群（ソフトウェアコード）を含む。

【発明の効果】

【0012】

上述の態様によれば、MCG障害（又はMCGリンク）の回復のためにMNからSNに送られるSN設定（又はリソース）の修正又は解放に関するメッセージを他のメッセージと区別することをSNに可能にする装置、方法、及びプログラムを提供できる。

【図面の簡単な説明】

【0013】

【図1】実施形態に係る無線通信ネットワークの構成例を示す図である。

【図2】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図3】実施形態に係るMNの動作の一例を示すフローチャートである。

【図4】実施形態に係るSNの動作の一例を示すフローチャートである。

【図5】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図6】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図7】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図8】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図9】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図10】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図11】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図12】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図13】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図14】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図15】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図16】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図17】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図18】実施形態に係るRRC TRANSFERメッセージのフォーマットの一例を示す図である。

【図19】実施形態に係るCU及びDUの動作の一例を示すシーケンス図である。

【図20】実施形態に係るDL RRC MESSAGE TRANSFERメッセージのフォーマットの一例を示す図である。

【図21】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図22】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図23】実施形態に係るUEの動作の一例を示すシーケンス図である。

【図24】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図25】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図26】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図27】実施形態に係るRRC TRANSFERメッセージのフォーマットの一例を示す図である。

【図28】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図29】実施形態に係るMN MODIFICATION INDICATIONメッセージのフォーマットの一例を示す図である。

【図30】実施形態に係るCG-ConfigInfo情報要素のフォーマットの一例を示す図である。

【図31】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図32】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図33】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図34】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図35】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図36】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図37】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図38】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図39】実施形態に係るMN及びSNの動作の一例を示すシーケンス図である。

【図40】実施形態に係るMNの構成例を示すブロック図である。

【図41】実施形態に係るUEの構成例を示すブロック図である。

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

【0014】

以下では、具体的な実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。

【0015】

以下に説明される複数の実施形態は、独立に実施されることもできるし、適宜組み合わせて実施されることもできる。これら複数の実施形態は、互いに異なる新規な特徴を有している。したがって、これら複数の実施形態は、互いに異なる目的又は課題を解決することに寄与し、互いに異なる効果を奏することに寄与する。

【0016】

以下に示される複数の実施形態は、3GPP Long Term Evolution (LTE)システム及び第5世代移動通信システム（5G system）を主な対象として説明される。しかしながら、これらの実施形態は、3GPPのmulti-connectivity（e.g., Dual Connectivity）と類似の技術をサポートする他の無線通信システムに適用されてもよい。なお、本明細書で使用されるLTEとの用語は、特に断らない限り、5G Systemとのインターワーキングを可能とするためのLTE及びLTE-Advancedの改良・発展を含む。さらに、5G Systemは、NR (New Radio)に加えて、LTE eNodeB (eNB)が5Gコアネットワーク（5GC）と接続するネットワーク構成を含む。このときのLTE eNBは、ng-eNBとも呼ばれる。ng-eNBは、5GCと接続しているeNBということでeNB/5GCとも呼ばれる。一方、Evolved Packet Core（EPC）と接続するLTE eNBと共にDCを実現する5G gNBは、en-gNBとも呼ばれる。

【0017】

＜第１の実施形態＞
図１は、本実施形態に係る無線通信ネットワークの構成例を示している。本実施形態に係る無線通信ネットワークは、マスターノード（MN）１及びセカンダリノード（SN）２を含む。MN１及びSN２は、ノード間インタフェース１０３を介して互いに通信する。図示されていないが、少なくともMN１はコアネットワークに接続され、SN２もコアネットワークに接続されてもよい。UE３は、エアインタフェース１０１及び１０２を介してMN1及びSN２と通信し、マスターセルグループ（MCG）及びセカンダリセルグループ（SCG）のdual connectivity（DC）を行う。MCGは、MN１に関連付けられた（又は提供される）サービングセルのグループであり、SpCell（i.e., プライマリセル（Primary Cell（PCell））及び必要に応じて（optionally）１又はそれ以上のセカンダリセル（Secondary Cells（SCells））を含む。一方、SCGは、SN２に関連付けられた（又は提供される）サービングセルのグループであり、SCGのプライマリセル及び必要に応じて（optionally）１又はそれ以上のセカンダリセル（Secondary Cells（SCells））を含む。SCGのプリマリセルは、プライマリSCGセル（Primary SCG Cell （PSCell））又はプライマリ・セカンダリセル（Primary Secondary Cell（PSCell））である。PSCellは、SCGのSpecial Cell（SpCell）である。

【0018】

MN１及びSN２の各々は、Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network（EUTRAN）ノード又はNG-RAN（Next generation Radio Access Network）ノードであってもよい。EUTRANノードは、eNB又はen-gNBであってもよい。NG-RANノードは、gNB又はng-eNBであってもよい。MN１のRadio Access Technology（RAT）は、SN２のそれと異なっていてもよい。

【0019】

DCは、Multi-Radio Dual Connectivity (MR-DC)であってもよい。MR-DCは、E-UTRA-NR Dual Connectivity (EN-DC)、NR-E-UTRA DC（NE-DC）、NG-RAN EN-DC（NGEN-DC）、及びNR-NR DC（NR DC）を含む。EN-DCはEPCを利用し、一方NE-DC、NGEN-DC、及びNR DCは5GCを利用する。

【0020】

図２は、MN１及びSN２のシグナリングの一例を示している。ステップ２０１では、MN１は、DCに関するSN２内の設定又はリソース（resources）を修正又は解放に関連するメッセージをSN２に送る。すなわち、当該メッセージは、RANノード間インタフェース（i.e., Xnインタフェース又はX2インタフェース）の制御メッセージである。当該メッセージは、DCに関するSN２内の設定又はリソース（resources）を修正又は解放するよう前記SN２に要求するメッセージであってもよい。図２に示されているように、ステップ２０１のメッセージは、SN MODIFICATION REQUESTメッセージ又はSN RELEASE REQUESTメッセージであってもよい。SN MODIFICATION REQUESTメッセージは、DCに関するSN２内の設定又はリソース（resources）の修正を要求するためにMNからSNに送られる。一方、SN RELEASE REQUESTメッセージは、SN２内の設定又はリソース（resources）の解放を要求するためにMNからSNに送られる。これに代えて、ステップ２０１のメッセージは、新たなXnAP/X2APメッセージ（e.g., MN MODIFICATION NOTIFICATIONメッセージ）であってもよい。SN２内の設定は、例えば、SN２がUE３に対して設定及び送信し、SN２でも保持するSCGの設定情報（e.g., SCG configuration）又はベアラの設定情報（e.g., Radio bearer configuration）でもよい。SN２内のリソース（resources）は、例えば、UE３に関連付けられたMN１とSN２の間のシグナリング・コネクションのリソース、SN２がUE３に対して設定するSCGの無線リソース（e.g., radio resources）、又はUE３の端末情報（e.g., UEコンテキスト）でもよい。

【0021】

さらに、ステップ２０１のメッセージは、SN２の設定（又はリソース）の修正又は解放がMCG障害（e.g., MCG RLF）又はその回復に関連することを明示的又は暗示的に示す。言い換えると、ステップ２０１のメッセージは、SN２の設定（又はリソース）の修正又は解放がMCG障害に起因することを明示的又は暗示的に示す。例えば、当該メッセージは、MCG障害の表示を含んでもよい。当該表示は、例えば、MCG障害が発生したこと、MCG障害を検出したこと、又はMCG障害の種類（e.g., MCG failure type）を示してもよい。さらに又はこれに代えて、当該メッセージは、MCG障害（又はMCGリンク）の回復の表示を含んでもよい。当該表示は、例えば、MCG障害（又はMCGリンク）の回復を意図していること、目的としていること、又は試みることを示してもよい。さらに又はこれに代えて、当該メッセージは、SN（又はSCG、又はsplit SRB、又はSRB3）を介するMCG障害（又はMCGリンク）の回復の表示を含んでもよい。RLF はMCG障害の一例である。MCG障害は、例えば、ハンドオーバ失敗、MN（MCG）の再設定失敗（Reconfiguration with sync failure、又はReconfiguration failure）、又は完全性保護チェック失敗（Integrity protection check failure）でもよい。MCG障害の種類は、これらの他のMCG障害のいずれかを示してもよい。

【0022】

これにより、SN２は、ステップ２０１のメッセージにより要求される設定（又はリソース）の修正又は解放がMCG障害に起因することを知ることができる。言い換えると、SN２は、ステップ２０１のメッセージがMCG障害又はその回復（復旧）と関連付けられていることを知ることができる。したがって、SN２は、ステップ２０１のメッセージを、MCG recoveryと関係していない他のSN MODIFICATION及びSN RELEASE REQUESTメッセージから区別できる。言い換えると、SN２は、MCG障害（又はMCGリンク）の回復のためにMN１からSN２に送られるSN設定（又はリソース）の修正又は解放に関するメッセージを他のメッセージと区別できる。

【0023】

幾つかの実装では、MN１は、MCG障害情報（MCG failure information又はMCG failure indication）をUE３からSN２（i.e., split SRB、又はSRB3及びXn/X2）を介して受信したことに応答して、MCG回復手順を開始することを決定してもよい。MCG回復手順は、split SRB、又はSRB3及びXn/X2を介するMN RRCメッセージの転送を伴うintra-MNハンドオーバ又はinter-MNハンドオーバであってもよい。そして、MN１は、当該MCG回復手順の中で、ステップ２０１のメッセージをSN２に送ってもよい。さらに、当該MCG回復手順の中で、MN１は、MCG障害の回復に関連するMN RRCメッセージを、SCG（i.e., split SRB又はSRB3）を介してUE３に送信してもよい。言い換えると、SN２は、MCG障害の回復に関連し且つMN１から送られるMN RRCメッセージを、SCG（i.e., split SRB又はSRB3）を介してUE３に送信してもよい。

【0024】

これに代えて、MN１は、UE３からのMCG障害情報の受信に依存せずにMCG障害を（自律的に）検出したことに応答して、MCG回復手順の開始を決定し、ステップ２０１のメッセージをSN２に送ってもよい。さらに、当該MCG回復手順の中で、MN１は、MCG障害の回復に関連するMN RRCメッセージを、SCG（i.e., split SRB又はSRB3）を介してUE３に送信してもよい。MN１におけるMCG障害の検出は、これには限定されないが、従来のLTE又はNRの無線ネットワークにおける検出方法と同様でもよい。例えば、MCG障害は、上りリンク又は下りリンクのデータ送信の成否状況（e.g., RLC再送回数）、上りリンクの無線品質の状況（e.g., Sounding Reference Signal（SRS）の受信電力や受信品質）、又は下りリンクの無線品質の状況（e.g., CQI reportの値, Synchronization Signal/PBCH block（SSB）又はCSI-RSのRSRP、RSRQ又はSINRの値）のいずれかを基に判定されてもよい。

【0025】

さらにSN２は、ステップ２０２を行ってもよい。ステップ２０２では、SN２は、ステップ２０１のメッセージにより要求されるSN2内の設定（又はリソース）の修正又は解放がMCG障害又はその回復に関連するか否かを判定する。言い換えると、SN２は、ステップ２０１のメッセージがMCG障害復旧手順に関連付けられているか否かを判定する。さらに言い換えると、SN２は、ステップ２０１のメッセージがMCG障害に起因するか否かを判定する。当該メッセージがMCG障害に起因する（又はMCG障害復旧手順に関連付けられている）ことを判定したなら、SN２は、MN RRCメッセージのMN１からUE３へのSN２（i.e., split SRB又はSRB3）を介する送信に関連付けられた所定の条件が成立するまで、SN２内の設定（又はリソース）の修正又は解放を延期する。当該MN RRCメッセージは、MCG障害（又はMCGリンク）の回復のために送信される。当該MN RRCメッセージは、例えば、reconfigurationWithSync情報要素（information element（IE））又はmobilityControlInfo IEを包含するMN RRC (Connection) Reconfigurationメッセージであってもよい。

【0026】

SN２は、ステップ２０１のメッセージにより要求された複数の修正又は解放のうち一部のみを延期してもよい。具体的には、SN２は、MN１からUE３へのSN２（i.e., split SRB又はSRB3）を介するRRCメッセージの送信を妨げる可能性のある修正又は解放を延期してもよい。幾つかの実装では、SN２は、SN２とUE３の間の直接的な無線ベアラ（e.g., SRB3、DRB）に適用されるセキュリティ鍵の更新（修正）を延期してもよい。さらに又はこれに代えて、SN２は、Layer 2再設定（e.g., PDCP re-establishment、PDCP data recovery、RLC re-establishment、及びMAC resetのうち任意の１つ又は組み合わせ）を延期してもよい。幾つかの実装では、SN２は、UE３に関連付けられたMN１とSN２の間のシグナリング・コネクションのリソース（resources）の解放を延期してもよい。さらに又はこれに代えて、SN２は、UE３に割り当てられていた無線リソース（e.g., SCG configuration）の解放を延期してもよい。さらに又はこれに代えて、SN２は、UE３に関連付けられた端末情報（e.g., UEコンテキスト）の解放を延期してもよい。このような動作によれば、SN２は、MN１とUE３の間のSN２を介するMN RRC messageの転送を妨げないように、SN２内の設定又はリソースの修正又は解放を行うタイミングをコントロール（又は調整）できる。

【0027】

MN RRCメッセージのSN２を介する送信に関連付けられた所定の条件は例えば以下の例のうち少なくとも１つを含んでもよい。幾つかの実装では、当該所定の条件は、SN２がUE３へのMN RRCメッセージの送信を完了したことを含んでもよい。幾つかの実装では、当該所定の条件は、MN RRCメッセージの受信に応答してUE３により送信される応答をSN２が受信したことを含んでもよい。Split SRBを介してMN RRCが転送されるケースでは、UE３からの当該応答は、hybrid automatic repeat request（HARQ）Acknowledgement（ACK）及びRLC ARQ ACKのうち１つ又は両方であってもよい。一方、SRB3を介してMN RRCが転送されるケースでは、UE３からの当該応答は、UE３からのSN RRC (Connection) Reconfiguration Completeメッセージであってもよい。さらに、幾つかの実装では、当該所定の条件は、SN２がMN１（intra-MNハンドオーバの場合）又はターゲットMN（inter-MNハンドオーバの場合）からSN Reconfiguration Completeメッセージを受信したことを含んでもよい。

【0028】

図３は、MN１の動作の一例を示すフローチャートである。ステップ３０１では、MN１は、MCG障害の検出に応答してMCG障害回復手順を開始する。上述のように、MN１は、UE３からのMCG障害情報の受信に基づいてMCG障害を検出してもよいし、当該MCG障害情報の受信に依存せずに自律的にMCG障害を検出してもよい。

【0029】

ステップ３０２では、MN１は、MCG回復手順の中で、SN２内の設定（又はリソース）の修正又は解放がMCG障害又はその回復に関連することを明示的又は暗示的に示すSN MODIFICATION REQUEST又はSN RELEASE REQUESTメッセージをSN２に送る。上述のように、MN１は、SN MODIFICATION/RELEASE REQUESTメッセージとは異なる別のXnAP/X2APメッセージをSN２に送ってもよい。ステップ３０２のメッセージは、SN２を介するMN RRCメッセージの送信に関連付けられた所定の条件が成立するまで、SN２内の設定（又はリソース）の修正又は解放を延期することをSN２に引き起こす。

【0030】

図４は、SN２の動作の一例を示すフローチャートである。ステップ４０１では、SN２は、SN MODIFICATION REQUEST又はSN RELEASE REQUESTメッセージをMN１から受信する。ステップ４０２では、SN２は、ステップ４０１のメッセージにより要求されるSN２内の設定（又はリソース）の修正又は解放がMCG障害又はその回復に関連するか否かを、ステップ４０１のメッセージのメッセージに基づいて判定する。言い換えると、SN２は、ステップ４０１のメッセージがMCG障害復旧手順に関連付けられているか否かを判定する。さらに言い換えると、SN２は、ステップ４０１のメッセージがMCG障害に起因するか否かを判定する。当該メッセージがMCG障害又はその回復に関連する場合、SN２は、MN RRCメッセージのMN１からUE３へのSN２（i.e., split SRB又はSRB3）を介する送信に関連付けられた所定の条件が成立するまで、SN２内の設定（又はリソース）の修正又は解放を延期する（ステップ４０３）。

【0031】

＜第２の実施形態＞
本実施形態は、第１の実施形態で説明されたMN１及びSN２の動作の具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。本実施形態では、MN１とUE３との間にsplit SRB（e.g., split SRB1）が設定されているときのMCG障害の検出に応じて、MN１は、MCG障害の復旧のために、SN変更を伴わないintra-MNハンドオーバを行う。

【0032】

図５は、SN変更を伴わないintra-MNハンドオーバ手順内で行われるMN１及びSN２のシグナリングの一例を示している。ステップ５０１では、MN１は、SN MODIFICATION REQUESTメッセージをSN２に送る。当該SN MODIFICATION REQUESTメッセージは、SN２内のUE３に関連付けられた設定又はリソースの修正（又は更新）をSN２に要求する。例えば、当該メッセージは、SN２に終端されるベアラ（SN terminated bearer）に適用されるセキュリティ鍵（e.g., SgNB Security Key）の修正（又は更新）を要求するために、新たなセキュリティ鍵の情報を示してもよい。

【0033】

ステップ５０１のSN MODIFICATION REQUESTメッセージは、さらに、当該メッセージがMCG障害又はその回復に関連付けられていることをSN２に示すための表示を含む。当該表示は、例えば、MCG failure recovery notification、MCG link recovery notification、又はMCG failure notificationと呼ばれてもよい。当該表示は、当該メッセージに包含されるIE又はCause値であってもよい。これに代えて、Cause値は例えばMCG Radio Connection With UE Lost、又はMCG RLFでもよい。当該表示の受信に応答して、SN２は、SN２内の設定（又はリソース）の修正を延期する。

【0034】

ステップ５０２では、SN２は、UE３のためのSN（又はSCG）リソース修正のMN１からの要求を確認（confirm）するために、SN MODIFICATION REQUEST ACKNOWLEDGEメッセージをMN１に送る。当該メッセージは、SN２により生成されたCG-Configメッセージを含んでもよい。CG-Configメッセージは、ステップ５０１のSN MODIFICATION REQUESTメッセージに基づいてSN２により生成されたSCG無線設定（e.g., scg-CellGroupConfig及びscg-RB-Configのうち１つ又は両方）を含む。

【0035】

ステップ５０３では、MN１は、split SRB1のSCG legを介してUE３にMN RRCメッセージ（e.g., RRC Reconfiguration including reconfigurationWithSync）を送信する。具体的には、MN１は、当該MN RRCメッセージをカプセル化している（encapsulating）Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDU)を包含するRRC TRANSFERメッセージをSN２宛てに送る。SN２は、当該RRC TRANSFERメッセージを受信し、（MN RRCメッセージをカプセル化している）PDCP PDUをUE３にSplit SRB1のSCG legを介して送信する。なお、5Gの用語（5G terminology）では、当該PDCP PDUはControl Plane (CP)のRRC messageを包含するPDCP PDUであることからPDCP-C PDUとも呼ばれる。また、gNB Central Unit (CU) Control Plane (CP)がホストするPDCPのPDCP PDUも同様にPDCP-C PDUとも呼ばれる。

【0036】

UE３は、ステップ５０３においてMN RRCメッセージを受信すると、それに包含されるRRCの設定情報（e.g., securityConfig(HO)及びsk-Counterのうち１つ又は両方）に従い、SN変更を伴わないintra-MNハンドオーバを実行する。MN RRCメッセージは、SN変更を伴わないintra-MNハンドオーバのためのSN RRCメッセージ（又はSN RRC設定）を包含してもよい。この場合、UE３のMCG RRCエンティティは、当該SN RRCメッセージをUE３のSCG RRCエンティティへ渡す。UE３は、当該MN RRCメッセージ及びSN RRCメッセージに従ってSN変更を伴わないintra-MNハンドオーバを実行する。

【0037】

ステップ５０４では、SN２は、（MN RRCメッセージをカプセル化している）PDCP PDUをUE３に送信した後に、ステップ５０１のSN MODIFICATION REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソース（e.g., SN２内の設定又はリソース）の修正（更新）を実行する。SN２は、当該PDCP PDUをUE３に送信したことに応答して、SN（SCG）リソースを修正（更新）してもよい。すなわち、図５の例では、MN-initiated SN Modification Preparation手順がRRC Transfer手順（又はMN RRC reconfiguration手順）と相互作用（interact）する。言い換えると、MN-initiated SN Modification Preparation手順がRRC Transfer手順（又はMN RRC reconfiguration手順）と関連付けられる。幾つかの実装では、もしSN２がSN MODIFICATION REQUESTメッセージをMN１から受信した後に（e.g., 直後に（right after））RRC TRANSFERメッセージをさらに受信し、それがSplit SRBで送信されるSN RRCコンテナ（e.g., PDCP-C PDU）を包含している場合、SN２は、当該SN RRCコンテナのUE３への送信をSN Modification Preparation手順よりも優先して実行する。

【0038】

図６は、図５に示された手順の変形例を示している。ステップ６０１～６０３におけるMN１及びSN２の動作はステップ５０１～５０３のそれと同様である。ステップ６０４では、SN２は、HARQ-ACK（及びRLC ARQ-ACK）をUE３から受信する。当該HARQ-ACK（及びRLC ARQ-ACK）は、ステップ６０３のMN RRCメッセージのSCG leg（i.e., SCG RLC bearer）を介した受信に応答してUE３からSN２のMedium Access Control（MAC）サブレイヤ（及びRLCサブレイヤ）に送信される。

【0039】

ステップ６０５では、SN２は、UE３からのHARQ-ACK（及びRLC ARQ-ACK）を受信した後に、ステップ６０１のSN MODIFICATION REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソースの修正（更新）を実行する。SN２は、HARQ-ACK（及びRLC ARQ-ACK）をUE３から受信したことに応答して、SN（SCG）リソースを修正（更新）してもよい。すなわち、図６の例では、MN-initiated SN Modification Preparation手順がRRC Transfer手順（又はMN RRC reconfiguration手順）と相互作用（interact）する。言い換えると、MN-initiated SN Modification Preparation手順がRRC Transfer手順（又はMN RRC reconfiguration手順）と関連付けられる。幾つかの実装では、もしSN２がSN MODIFICATION REQUESTメッセージをMN１から受信した後に（e.g., 直後に（right after））RRC TRANSFERメッセージをさらに受信し、それがSplit SRBで送信されるSN RRCコンテナ（e.g., PDCP-C PDU）を包含している場合、SN２は、当該SN RRCコンテナのUE３への送信をSN Modification Preparation手順よりも優先して実行する。

【0040】

なお、通常のハンドオーバでは、UEは、reconfigurationWithSync IE（又はmobilityControlInfo IE）を包含するRRC (Connection) Reconfigurationメッセージの受信に対するHARQ-ACK（及びRLC ARQ-ACK）の送信を省略することが許容されている。しかしながら、図６に示されるようにUE３がSplit SRBのSCG legを介してreconfigurationWithSync IE（又はmobilityControlInfo IE）を受信したなら、UE３はHARQ-ACK（及びRLC ARQ-ACK）をSN２に必ず送信するように動作してもよい。なお、UE３は、UE３がMCG障害の検出をSCG及びSN２を介してMN１に報告していた場合にのみ、HARQ-ACK（及びRLC ARQ-ACK）をSN２に必ず送信するように動作してもよい。具体的には、例えば、UE３がMCG Failure Informationを送信していた場合に、UE３はこのように動作してもよい。これに代えて、UE３がMCG Failure Informationを送信してから所定の時間が経過していない場合に、UE３はこのように動作してもよい。これに代えて、UE３がMCG Failure Informationの送信を許可されていた場合に、UE３はこのように動作してもよい。これに代えて、UE３がMCG Failure Informationの送信のための設定情報をMNから受信していた場合に、UE３はこのように動作してもよい。

【0041】

図７は、図５に示された手順の他の変形例を示している。ステップ７０１～７０４は、図６のステップ６０１～６０４と同様である。ただし、ステップ７０４のHARQ-ACK（及びRLC ARQ-ACK）送信は省略されてもよい。ステップ７０５では、UE３は、ReconfigurationWithSync IEを包含するSpCellConfig IE（のservCellIndex）により指示された新たなPCellを介してMN１にRRC Reconfiguration Completeメッセージを送信する。ReconfigurationWithSync IEの代わりにMobilityControlInfo IEが使用される場合、新たなPCellは、当該IEが包含するtargetPhysCellIdにより指定されてもよい。ステップ７０６では、MN１は、SN RECONFIGURATION COMPLETEメッセージをSN２に送る。当該SN RECONFIGURATION COMPLETEメッセージは、ステップ７０２のSN MODIFICATION REQUEST ACKNOWLEDGEメッセージに包含されていたSCG無線設定（e.g., scg-CellGroupConfig及びscg-RB-Configのうち１つ又は両方）をUE３が成功裏に適用したことを示す。

【0042】

ステップ７０７では、SN２は、MN１からのSN RECONFIGURATION COMPLETEメッセージの受信後に、ステップ７０１のSN MODIFICATION REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソースの修正（更新）を実行する。SN２は、SN RECONFIGURATION COMPLETEメッセージの受信に応答して、SN（SCG）リソースを修正（更新）してもよい。すなわち、図７の例では、MN-initiated SN Modification Preparation手順がSN Reconfiguration Complete手順と相互作用（interact）する。言い換えると、MN-initiated SN Modification Preparation手順がSN Reconfiguration Complete手順と関連付けられる。

【0043】

幾つかの実装では、もしMN１がRRC reconfiguration手順の成功に関する報告を必要としている端末情報（e.g., UEコンテキスト）の修正（i.e. SN MODIFICATION REQUEST）をSN２が受け入れる（admit）なら、SN２はMN１にSN MODIFICATION REQUEST ACKNOWLEDGEメッセージを送信するとき、タイマ（e.g., T_DCoverall, TXn_DCoverall）をスタートしてもよい。そして、SN２は、SN RECONFIGURATION COMPLETEメッセージを受信すると、当該タイマを停止してもよい。さらに、もしSN２がSN MODIFICATION REQUESTメッセージをMN１から受信した後に（e.g., 直後に（right after））RRC TRANSFERメッセージをさらに受信し、それがSplit SRBで送信されるSN RRCコンテナ（e.g., PDCP-C PDU）を包含している場合、SN２は、当該SN RRCコンテナのUE３への送信をSN Modification Preparation手順よりも優先する。すなわち、SN２は、少なくともSN RECONFIGURATION COMPLETEメッセージを受信するまでは当該端末情報の修正（i.e. SN（SCG）リソースを修正（更新））を行わない。

【0044】

図８は、図５に示された手順の他の変形例を示している。既に説明したように、SN MODIFICATION REQUEST/ACKNOWLEDGEメッセージに代えて、新たなXnAP/X2APメッセージ（messages）が使用されてもよい。図８の例では、MN１がSN２にMN MODIFICATION NOTIFICATIONメッセージを送る（ステップ８０１）。MN MODIFICATION NOTIFICATIONメッセージは、MCGの修正（又は変更又は再設定）に関連付けられたSCGの修正（又は再設定）が必要とされることをSN２に示す。SN MODIFICATION REQUESTメッセージと同様に、MN MODIFICATION NOTIFICATIONメッセージは、SN２内のUE３のための設定又はリソースの修正（又は更新）をSN２に要求する。MN MODIFICATION NOTIFICATIONメッセージは、当該メッセージがMCG障害又はその回復に関連付けられていることをSN２に示すための表示を含んでもよい。これに代えて、MN MODIFICATION NOTIFICATIONメッセージの送信それ自体が、MCG障害又はその回復に関連付けられてもよい（つまり、MCG障害又はその回復を意味してもよい）。言い換えると、MN MODIFICATION NOTIFICATIONメッセージはMCG障害の回復のために送信され、SN２は当該メッセージを受信することで（受信に応答して）、MN１がMCG障害の回復を行おうとしていることを認識してもよい。

【0045】

ステップ８０２では、SN２は、UE３のためのSN（SCG）リソース修正のMN１からの要求を確認（confirm）するために、MN MODIFICATION NOTIFICATION RESPONSEメッセージをMN１に送る。当該メッセージは、SN MODIFICATION REQUEST ACKNOWLEDGEメッセージと同様に、SN２により生成されたCG-Configメッセージを含んでもよい。

【0046】

ステップ８０３では、ステップ５０３と同様に、MN１は、split SRB1のSCG legを介してUE３にMN RRCメッセージ（e.g., RRC Reconfiguration including reconfigurationWithSync）を送信する。ただし、ステップ８０３では、RRC TRANSFERメッセージの代わりに、新たなXnAP/X2APメッセージ（例えば、MN MODIFICATION REQUESTメッセージ）が使用される。MN MODIFICATION REQUESTメッセージは、MCG修正に関連付けられたMN RRCメッセージのUE３への転送が必要とされることをSN２に示す。

【0047】

ステップ８０４では、SN２は、HARQ-ACK（及びRLC ARQ-ACK）をUE３から受信する。ステップ８０４のHARQ-ACK（及びRLC ARQ-ACK）送信は省略されてもよい。

【0048】

ステップ８０５では、SN２は、（MN RRCメッセージをカプセル化している）PDCP PDUをUE３に送信した後に、ステップ８０１のMN MODIFICATION NOTIFICATIONメッセージにより要求されていたUE３のためのSN（SCG）リソースの修正（更新）を実行する。SN２は、PDCP PDUをUE３に送信したことに応答して、SN（SCG）リソースを修正（更新）してもよい。これに代えて、UE３からのHARQ-ACK（及びRLC ARQ-ACK）を受信した後に、UE３のためのSN（SCG）リソースを修正（更新）してもよい。SN２は、HARQ-ACK（及びRLC ARQ-ACK）をUE３から受信したことに応答して、SN（SCG）リソースを修正（更新）してもよい。

【0049】

図７の手順と同様に、図８では、SN２は、MN１からのSN RECONFIGURATION COMPLETEメッセージの受信後に、ステップ８０１のMN MODIFICATION NOTIFICATIONメッセージにより要求されていたUE３のためのSN（SCG）リソースを修正（更新）してもよい。

【0050】

ステップ８０１のMN MODIFICATION NOTIFICATIONメッセージ、ステップ８０２のMN MODIFICATION NOTIFICATION RESPONSEメッセージ、及びステップ８０３のMN MODIFICATION REQUESTメッセージが１つの（一連の）手順として規定されてもよい。当該手順では、これらの動作が一連の動作として（つまり関連付けて）実行されてもよい。当該手順は、例えば、MN MODIFICATION preparation手順又はMN RECOVERY preparation手順と呼ばれてもよい。

【0051】

図９は、図５～図７に示された手順の具体例を示している。図９のステップ９０４～９０６は、図５のステップ５０１～５０３、図６のステップ６０１～６０３、及び図７のステップ７０１～７０３に相当する。図９のステップ９０７は、図６のステップ６０４及び図７のステップ７０４に相当する。図９のステップ９０９及び９１０は、図７のステップ７０５及び７０６に相当する。

【0052】

図９のステップ９０１では、UE３はMCG障害（e.g., MCG RLF）を検出する。ステップ９０２では、UE３は、Split SRB1のSCG legを介してMN１にMCG障害情報を送信する。SN２からMN１へのMCG障害情報の転送のためにRRC TRANSFERメッセージが使用されてもよい。ステップ９０３では、MN１は、MCG障害情報の受信に応じて、MCG障害復旧手順を決定する。このMCG障害復旧手順は、SN変更を伴わないintra-MNハンドオーバ手順（すなわち、ステップ９０４～９１１）を含む。

【0053】

図１０は、図８に示された手順の具体例を示している。図１０のステップ１００４～１００７は、図８のステップ８０１～８０４に相当する。図１０のステップ１００１～１００３は図９のステップ９０１～９０３と同様である。図１０のステップ１００８～１０１１は、図９のステップ９０８～９１１と同様である。

【0054】

＜第３の実施形態＞
本実施形態は、第１の実施形態で説明されたMN１及びSN２の動作の具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。本実施形態では、MN１とUE３との間にsplit SRB（e.g., split SRB1）が設定されているときのMCG障害の検出に応じて、MN１は、MCG障害の復旧のために、SN変更を伴わないinter-MNハンドオーバを行う。

【0055】

図１１は、SN変更を伴わないinter-MNハンドオーバ手順内で行われるMN１及びSN２のシグナリングの一例を示している。ステップ１１０１では、MN１は、SN RELEASE REQUESTメッセージをSN２に送る。MN１は、SN２内のUEコンテキストが維持される（kept）ことをSN２に示すために、 “True”にセットされたUE Context Kept Indicator IEを当該SN RELEASE REQUESTメッセージに含める。

【0056】

ステップ１１０１のSN RELEASE REQUESTメッセージは、さらに、当該メッセージがMCG障害又はその回復に関連付けられていることをSN２に示すための追加の表示を含む。当該追加の表示は、例えば、MCG failure recovery notification、MCG link recovery notification、又はMCG failure notificationと呼ばれてもよい。当該表示は、当該メッセージに包含されるIE又はCause値であってもよい。当該追加の表示の受信に応答して、SN２は、SN２内の設定（又はリソース）の解放を延期する。具体的には、SN２は、UE３に関連付けられたMN１とSN２の間のシグナリング・コネクションのリソース（resources）の解放を延期してもよい。さらに又はこれに代えて、SN２は、UE３に割り当てられていた無線リソースの解放を延期してもよい。

【0057】

ステップ１１０２では、SN２は、UE３のためのSN（SCG）リソース解放のMN１からの要求を確認（confirm）するために、SN RELEASE REQUEST ACKNOWLEDGEメッセージをMN１に送る。

【0058】

ステップ１１０３では、MN１は、split SRB1のSCG legを介してUE３にMN RRCメッセージ（e.g., RRC Reconfiguration including reconfigurationWithSync）を送信する。ステップ１１０３は、図５のステップ５０３と同様である。

【0059】

ステップ１１０４では、SN２は、（MN RRCメッセージをカプセル化している）PDCP PDUをUE３に送信した後に、ステップ５０１のSN RELEASE REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソースの解放を実行する。SN２は、PDCP PDUをUE３に送信したことに応答して、SN（SCG）リソースを解放してもよい。すなわち、図１１の例では、MN-initiated SN Release手順がRRC Transfer手順（又はMN RRC reconfiguration手順）と相互作用（interact）する。言い換えると、MN-initiated SN Release手順がRRC Transfer手順（又はMN RRC reconfiguration手順）と関連付けられる。幾つかの実装では、もしSN２がSN RELEASE REQUESTメッセージをMN１から受信した後に（e.g., 直後に（right after））RRC TRANSFERメッセージをさらに受信し、それがSplit SRBで送信されるSN RRCコンテナ（e.g., PDCP-C PDU）を包含している場合、SN２は、当該SN RRCコンテナのUE３への送信をSN Release手順よりも優先して実行する。

【0060】

図１２は、図１１に示された手順の変形例を示している。ステップ１２０１～１２０３におけるMN１及びSN２の動作はステップ１１０１～１１０３のそれと同様である。ステップ１２０４では、SN２は、HARQ-ACK（及びRLC ARQ-ACK）をUE３から受信する。当該HARQ-ACK（及びRLC ARQ-ACK）は、ステップ１２０３のMR RRCメッセージのSCG leg（i.e., SCG RLC bearer）を介した受信に応答してUE３からSN２のMACサブレイヤ（及びRLCサブレイヤ）に送信される。

【0061】

ステップ１２０５では、SN２は、UE３からのHARQ-ACK（及びRLC ARQ-ACK）を受信した後に、ステップ１２０１のSN RELEASE REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソースの解放を実行する。SN２は、HARQ-ACK（及びRLC ARQ-ACK）をUE３から受信したことに応答して、SN（SCG）リソースを解放してもよい。すなわち、図１２の例では、MN-initiated SN Release手順がRRC Transfer手順（又はMN RRC reconfiguration手順）と相互作用（interact）する。言い換えると、MN-initiated SN Release手順がRRC Transfer手順（又はMN RRC reconfiguration手順）と関連付けられる。幾つかの実装では、もしSN２がSN RELEASE REQUESTメッセージをMN１から受信した後に（e.g., 直後に（right after））RRC TRANSFERメッセージをさらに受信し、それがSplit SRBで送信されるSN RRCコンテナ（e.g., PDCP-C PDU）を包含している場合、SN２は、当該SN RRCコンテナのUE３への送信をSN Release手順よりも優先して実行する。

【0062】

なお、通常のハンドオーバでは、UEは、reconfigurationWithSync IE（又はmobilityControlInfo IE）を包含するRRC (Connection) Reconfigurationメッセージの受信に対するHARQ-ACK（及びRLC ARQ-ACK）の送信を省略することが許容されている。しかしながら、図１２に示されるようにUE３がSplit SRBのSCG legを介してreconfigurationWithSync IE（又はmobilityControlInfo IE）を受信したなら、UE３はHARQ-ACK（及びRLC ARQ-ACK）をSN２に必ず送信するように動作してもよい。なお、UE３は、UE３がMCG障害の検出をSCG及びSN２を介してMN１に報告していた場合にのみ、HARQ-ACK（及びRLC ARQ-ACK）をSN２に必ず送信するように動作してもよい。具体的には、例えば、UE３がMCG Failure Informationを送信していた場合に、UE３はこのように動作してもよい。これに代えて、UE３がMCG Failure Informationを送信してから所定の時間が経過していない場合に、UE３はこのように動作してもよい。これに代えて、UE３がMCG Failure Informationの送信を許可されていた場合に、UE３はこのように動作してもよい。これに代えて、UE３がMCG Failure Informationの送信のための設定情報をMNから受信していた場合に、UE３はこのように動作してもよい。

【0063】

図１３は、図１１に示された手順の他の変形例を示している。ステップ１３０１～１３０４は、図１２のステップ１２０１～１２０４と同様である。ただし、ステップ１３０４のHARQ-ACK（及びRLC ARQ-ACK）送信は省略されてもよい。ステップ１３０５では、UE３は、ReconfigurationWithSync IEを包含するSpCellConfig IE（のservCellIndex）により指示された新たなPCellを介してターゲットMN４にRRC Reconfiguration Completeメッセージを送信する。ReconfigurationWithSync IEの代わりにMobilityControlInfo IEが使用される場合、新たなPCellは、当該IEが包含するtargetPhysCellIdにより指定されてもよい。ステップ１３０６では、ターゲットMN４は、SN RECONFIGURATION COMPLETEメッセージ（又はMN RECONFIGURATION COMPLETEメッセージ）をSN２に送る。

【0064】

ステップ１３０７では、SN２は、ターゲットMN４からのSN RECONFIGURATION COMPLETEメッセージの受信後に、ステップ１３０１のSN RELEASE REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソースの解放を実行する。SN２は、SN RECONFIGURATION COMPLETEメッセージの受信に応答して、SN（SCG）リソースを解放してもよい。すなわち、図１３の例では、MN-initiated SN Release手順がSN Reconfiguration Complete手順と相互作用（interact）する。言い換えると、MN-initiated SN Release手順がSN Reconfiguration Complete手順と関連付けられる。ステップ１３０６の代わりに、ターゲットMN４はソースMN１にMN RECONFIGURATION COMPLETEメッセージを送信し、ソースMN１がSN２にSN RECONFIGURATION COMPLETEメッセージを送信してもよい。

【0065】

図１１の手順は、さらに変形されてもよい。SN RELEASE REQUEST/ACKNOWLEDGEメッセージに代えて、新たなXnAP/X2APメッセージ（messages）が使用されてもよい。例えば、図８の手順と類似して、MN MODIFICATION NOTIFICATION/RESPONSEメッセージが使用されてもよい。さらに又はこれに代えて、RRC TRANSFERメッセージの代わりに新たなXnAP/X2APメッセージ（例えば、図８のMN MODIFICATION REQUESTメッセージ）が使用されてもよい。図８に関して説明したように、MN MODIFICATION NOTIFICATIONメッセージ、MN MODIFICATION RESPONSEメッセージ、及びMN MODIFICATION REQUESTメッセージがまとめて１つの（一連の）手順として規定されてもよい。

【0066】

図１４は、図１１～図１３に示された手順の具体例を示している。図１４のステップ１４０６～１４０８は、図１１のステップ１１０１～１１０３、図１２のステップ１２０１～１２０３、及び図１３のステップ１３０１～１３０３に相当する。図１４のステップ１４０９及び１４１０は、図１３のステップ１３０５及び１３０６に相当する。図１４で、SN２は、ターゲットMN４からSN RECONFIGURATION COMPLETEメッセージ（又はMN RECONFIGURATION COMPLETEメッセージ）を受信すると（ステップ１４１０）、ステップ１４０６のSN RELEASE REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソースの解放を、UE３の端末情報（e.g., UEコンテキスト）を除いて、実行してもよい。例えば、SN２は、ソースMN１とのMR-DCのためにUE３に関連付けられた無線リソース（e.g., source SCG lower layer configuration（e.g., CellGroupConfig））を解放してもよい。

【0067】

図１４のステップ１４０１では、UE３は、Split SRB1のSCG legを介してMN１にMCG障害情報を送信する。MN１は、MCG障害情報の受信に応じて、MCG障害復旧手順を決定する。このMCG障害復旧手順は、SN変更を伴わないinter-MNハンドオーバ手順（すなわち、ステップ１４０２～１４１３）を含む。SN変更を伴わないinter-MNハンドオーバ手順は、パススイッチのためのコアネットワーク（Core Network(CN)）５とのシグナリング（ステップ１４１１）を含む。SN２は、ソースMN１からUE CONTEXT RELEASEメッセージを受信すると（ステップ１４１３）、ソースMN１とのMR-DCのために保持していたUE３の端末関連リソース（e.g., UEコンテキストに関連するソースMN1とのC-planeリソース）を解放する。

【0068】

＜第４の実施形態＞
本実施形態は、第１の実施形態で説明されたMN１及びSN２の動作の具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。本実施形態では、MN１とUE３との間にsplit SRB（e.g., split SRB1）が設定されているときのMCG障害の検出に応じて、MN１は、MCG障害の復旧のために、SN解放を伴うMN to gNB change手順を行う。

【0069】

図１５は、SN解放を伴うMN to gNB change手順の具体例を示している。図１５のステップ１５０１では、UE３は、Split SRB1のSCG legを介してMN１にMCG障害情報を送信する。MN１は、MCG障害情報の受信に応じて、MCG障害復旧手順を決定する。このMCG障害復旧手順は、SN解放を伴うMN to gNB change手順（すなわち、ステップ１５０２～１５１３）を含む。

【0070】

ステップ１５０４では、MN１（i.e., ソースMN）は、SN RELEASE REQUESTメッセージをSN２に送る。ステップ１５０４のSN RELEASE REQUESTメッセージは、さらに、当該メッセージがMCG障害又はその回復に関連付けられていることをSN２に示すための表示を含む。当該表示は、例えば、MCG failure recovery notification、MCG link recovery notification、又はMCG failure notificationと呼ばれてもよい。当該表示は、当該メッセージに包含されるIE又はCause値であってもよい。当該表示の受信に応答して、SN２は、SN２内の設定（又はリソース）の解放を延期する。具体的には、SN２は、UE３に関連付けられたMN１とSN２の間のシグナリング・コネクションのリソース（resources）の解放を延期してもよい。さらに、SN２は、UE３に関連付けられた端末情報（e.g., UEコンテキスト）の解放を延期してもよい。さらに、SN２は、UE３に関連付けられた無線リソース（e.g., SCG configuration）の解放を延期してもよい。

【0071】

ステップ１５０５では、SN２は、UE３のためのSN（SCG）リソース解放のMN１からの要求を確認（confirm）するために、SN RELEASE REQUEST ACKNOWLEDGEメッセージをMN１に送る。

【0072】

ステップ１５０６では、MN１は、split SRB1のSCG legを介してUE３にMN RRCメッセージ（e.g., RRC Reconfiguration including reconfigurationWithSync）を送信する。ステップ１５０６は、図５のステップ５０３及び図１１のステップ１１０３などと同様である。

【0073】

幾つかの実装では、SN２は、（MN RRCメッセージをカプセル化している）PDCP PDUをUE３に送信（ステップ１５０６）したことに応答して、ステップ１５０４のSN RELEASE REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソースを解放してもよい。これに代えて、SN２は、HARQ-ACK（及びRLC ARQ-ACK）をUE３から受信（ステップ１５０７）したことに応答して、SN（SCG）リソースを解放してもよい。これに代えて、SN２は、ターゲットgNB６からのSN RECONFIGURATION COMPLETEメッセージ（又はMN RECONFIGURATION COMPLETEメッセージ）の受信（ステップ１５０９）に応答して、SN（SCG）リソースを解放してもよい。例えばSN２は、ステップ１５０４のSN RELEASE REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソースの解放を、UE３の端末情報（e.g., UEコンテキスト）を除いて、実行してもよい。

【0074】

＜第５の実施形態＞
本実施形態は、第１の実施形態で説明されたMN１及びSN２の動作の具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。本実施形態では、MN１とUE３との間にsplit SRB（e.g., split SRB1）が設定されているときのMCG障害の検出に応じて、MN１は、MCG障害の復旧のために、SN to gNB change（role change）手順を行う。

【0075】

図１６は、SN to gNB change手順の具体例を示している。図１６のステップ１６０１では、UE３は、Split SRB1のSCG legを介してMN１にMCG障害情報を送信する。MN１は、MCG障害情報の受信に応じて、MCG障害復旧手順を決定する。このMCG障害復旧手順は、SN to gNB change手順（すなわち、ステップ１６０２～１６１０）を含む。

【0076】

ステップ１６０２では、MN１（i.e., ソースMN）は、HANDOVER REQUESTメッセージをSN２に送る。ステップ１６０２のHANDOVER REQUESTメッセージは、ハンドオーバ後にSN２がMNとして（又はStandalone（SA）で）UE３を管理することを期待することを明示的又は暗示的に示す情報を含んでもよい。例えば、MN１は当該メッセージにUE Context Reference at the SgNB IEを含めることでそれを示してもよい。一方、当該情報（e.g., UE Context Reference at the SgNB IE）を受信すると、SN２は、MN１とMR-DCを行っているUE３に対してハンドオーバを実行して（ターゲット）MNとして（又はSAで）UE３を受け入れることを期待（又は要求）されていると理解（又は認識）してもよい。

【0077】

ステップ１６０３では、SN２は、UE３のハンドオーバを受け入れることを示すために、HANDOVER REQUEST ACKNOWLEDGEメッセージをMN１に送る。SN２は、当該メッセージにUE Context Kept Indicator IEを含め（i.e., Trueにセットし）、これによりSN２がMNとして（又はSAで）UE３を管理することをMN１に示してもよい。

【0078】

ステップ１６０４では、MN１（i.e., ソースMN）は、SN RELEASE REQUESTメッセージをSN２に送る。ステップ１６０４のSN RELEASE REQUESTメッセージは、UE Context Kept Indicator IEを含んでもよい。さらに、SN RELEASE REQUESTメッセージは、当該メッセージがMCG障害又はその回復に関連付けられていることをSN２に示すための表示を含む。当該表示は、例えば、MCG failure recovery notification、MCG link recovery notification、又はMCG failure notificationと呼ばれてもよい。当該表示は、当該メッセージに包含されるIE又はCause値であってもよい。当該表示の受信に応答して、SN２は、SN２内の設定（又はリソース）の解放を延期する。具体的には、SN２は、UE３に関連付けられたMN１とSN２の間のシグナリング・コネクションのリソース（resources）の解放を延期してもよい。さらに、SN２は、UE３に関連付けられた端末情報（e.g., UEコンテキスト）の解放を延期してもよい。さらに、SN２は、ソースMN１とのMR-DCのためにUE３に関連付けられた無線リソース（e.g., SCG lower layer configuration）の解放を延期してもよい。

【0079】

ステップ１６０５では、SN２は、UE３のためのSN（SCG）リソース解放のMN１からの要求を確認（confirm）するために、SN RELEASE REQUEST ACKNOWLEDGEメッセージをMN１に送る。

【0080】

ステップ１６０６では、MN１は、split SRB1のSCG legを介してUE３にMN RRCメッセージ（e.g., RRC Reconfiguration including reconfigurationWithSync）を送信する。ステップ１６０６は、図５のステップ５０３及び図１１のステップ１１０３などと同様である。つまり、SN２はハンドオーバのターゲットRANノード（MN又はSA gNB）であるが、少なくとも当該MN RRCメッセージの送信まではソースSNとして動作する。

【0081】

幾つかの実装では、SN２は、（MN RRCメッセージをカプセル化している）PDCP PDUをUE３に送信（ステップ１６０６）したことに応答して、ステップ１６０４のSN RELEASE REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソースを解放してもよい。これに代えて、SN２は、HARQ-ACK（及びRLC ARQ-ACK）をUE３から受信（ステップ１６０７）したことに応答して、ソースMN１とのMR-DCのためのSN（SCG）リソースを解放してもよい。

【0082】

＜第６の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。本実施形態は、MN RRCメッセージを転送するためにMN１からSN２に送られるRRC TRANSFERメッセージの改良を提供する。

【0083】

図１７は、本実施形態に係るMN１及びSN２の動作の一例を示している。ステップ１７０１では、MN１は、SN２にRRC TRANSFERメッセージを送る。MN１は、RRC TRANSFERメッセージに包含されるMN RRCメッセージに関する情報（e.g., Delivery Requirement IE、又はDelivery Priority IE）を当該RRC TRANSFERメッセージに含めてもよい。当該Delivery Requirement IEは、MN RRCメッセージがUE３に必ず配信される（delivered）べきであるか否かを示す。当該Delivery Priority IEは、MN RRCメッセージが他のメッセージ又は情報よりも優先してUE３に配信される（delivered）べきであるか否かを示す。

【0084】

図１８は、Delivery Requirement IEを包含するRRC TRANSFERメッセージのフォーマットの具体例を示している。図１８の例では、Delivery Requirement IEの値が“essential”にセットされている場合、これは（MN RRCメッセージをカプセル化している）PDCP PDUがUE３に必ず配信されるべきであることを意味する。

【0085】

なお、SN２は、Central Unit（CU）（e.g., gNB-CU）、及び１又はそれ以上のDistributed Units（DUs）（e.g., gNB-DUs）を含んでもよい。さらに、CUは、Control Plane (CP) Unit（e.g., gNB-CU-CP）及び１又はそれ以上のUser Plane (UP) Unit（e.g., gNB-CU-UP）を含んでもよい。この場合、図１９に示されるように、CU（又はCU-CP）１９０１は、UE３にRRCメッセージを転送するためにDU１９０２に送られるメッセージ（F1AP：DL RRC MESSAGE TRANSFERメッセージ）に、Delivery Requirement IEを含めてもよい（ステップ１９１１）。

【0086】

図２０は、Delivery Requirement IEを包含するDL RRC MESSAGE TRANSFERメッセージのフォーマットの具体例を示している。図２０の例では、Delivery Requirement IEの値が“essential”にセットされている場合、これは（RRCメッセージをカプセル化している）PDCP PDUがUE３に必ず配信されるべきであることを意味する。

【0087】

図２１は、MCG復旧手順の一例を示している。図２１の例では、MN１とUE３との間にsplit SRB（e.g., split SRB1）が設定されているときのMCG障害の検出に応じて、MN１は、MCG障害の復旧のために、SN変更を伴わないinter-MNハンドオーバを行う。

【0088】

図２１の手順は、図１４のそれと類似する。ただし、図２１の手順では、RRC Transfer手順（ステップ２１０６）がSN Release手順（ステップ２１０７及び２１０８）よりも前に行われる。ステップ２１０６では、MN１は、split SRB1のSCG legを介してUE３にMN RRCメッセージ（e.g., RRC Reconfiguration including reconfigurationWithSync）を送信する。具体的には、MN１は、当該MN RRCメッセージをカプセル化しているPDCP PDUを包含するRRC TRANSFERメッセージをSN２宛てに送る。当該RRC TRANSFERメッセージは、PDCP PDUのUE３への配信が必ず行われるべきであることを示す。当該RRC TRANSFERメッセージは、“essential”にセットされたDelivery Requirement IEを含んでもよい。一方、ステップ２１０７では、MN１は、MCG障害又はその回復との関連付けを示す表示をSN RELEASE REQUESTメッセージに含めなくてもよい。

【0089】

図２１の手順によれば、SN２は、“essential”にセットされたDelivery Requirement IE を包含するRRC TRANSFERメッセージ（ステップ２１０６）を受信していたなら、SN RELEASE REQUESTメッセージ（ステップ２１０７）により要求されるUE３のためのリソースの解放を、UE３への（MN RRCメッセージをカプセル化している）PDCP PDUの配信が完了するまで保留（延期）できる。なお、Delivery Requirement IEに代えてDelivery Priority IEが使用され、当該IEの値が“high”にセットされた場合にSN２は上述と同様に動作してもよい。

【0090】

図２１の手順は、次のように変形されてもよい。例えば、SN Release手順（図２１のステップ２１０７及び２１０８相当）がRRC Transfer手順（図２１のステップ２１０６相当）の前に行われてもよい。このとき、SN RELEASE REQUESTメッセージはMCG障害又はその回復に関連付けられていることを示す表示を含まなくてもよい。SN２は、SN RELEASE REQUESTメッセージを受信した後にDelivery Requirement IE を包含するRRC TRANSFERメッセージを受信し且つ当該IEの値が“essential”にセットされている場合、SN２内の設定（又はリソース）の解放を延期する。これにより、SN２は、SN RELEASE REQUESTメッセージにより要求されるUE３のためのリソースの解放を、UE３への（MN RRCメッセージをカプセル化している）PDCP PDUの配信が完了するまで保留（延期）できる。

【0091】

＜第７の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。本実施形態は、MN１からSN２に送られるノード間メッセージ（i.e., XnAP/X2APメッセージ）の改良を提供する。

【0092】

既に説明したように、UE３のためのSN２内の設定（又はリソース）の修正又は変更をSN２に要求するXnAP/X2APメッセージは、MCG障害に関連する表示を含んでもよい。当該表示は、MCG障害の表示であってもよいし、MCG障害（若しくはMCGリンク）の回復の表示であってもよい。当該表示は、例えば、MCG failure recovery notification、MCG link recovery notification、又はMCG failure notificationと呼ばれてもよい。当該表示は、当該XnAP/X2APメッセージに包含されるIE又はCause値であってもよい。当該XnAP/X2APメッセージは、例えば、SN MODIFICATION REQUESTメッセージ、又はSN RELEASE REQUESTメッセージである。

【0093】

さらに又はこれに代えて、本実施形態では、その他のXnAP/X2APメッセージ（例えばRRC TRANSFERメッセージ又はHANDOVER REQUESTメッセージ）が、MCG障害に関連する表示を含んでもよい。当該表示は、MCG障害の表示であってもよいし、MCG障害（又はMCGリンク）の回復の表示であってもよい。

【0094】

図２２の例では、MN１は、SN２に送られるXnAP/X2APメッセージ（例えばRRC TRANSFERメッセージ）に、MCG障害の表示（e.g., MCG Failure Notification）を含める（ステップ２２０１）。これにより、SN２は、受信したXnAP/X2APメッセージがMCG障害又はその回復に関連する（又はMCG障害に起因する）ことを知ることができる。言い換えると、SN２は、受信したXnAP/X2APメッセージがMCG障害又はその復旧と関連付けられていることを知ることができる。

【0095】

＜第８の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。本実施形態は、UE３からSN２へのMCG障害の通知を可能とするための改良を提供する。

【0096】

Split SRB1を用いるfast MCG recoveryでは、UE３は、MCG障害を示すMN RRCメッセージ（e.g., MCG Failure Informationメッセージ）をSplit SRB1のSCG legを介してMN１に送信する。このとき、SN２のRLCサブレイヤは、MCG Failure Informationメッセージをカプセル化しているPDCP PDUをUE３のSCG RLCサブレイヤから受信し、これをMN１のPDCPサブレイヤに送信する。したがって、SN２のRRCレイヤは、MCG 障害の発生を知ることができない。

【0097】

この問題に対処するために、本実施形態のUE３は以下のように動作する。UE３は、split SRB1のSCG legを介してMCG障害情報をMN１に送信する。さらに、UE３は、SN２とUE３との間の直接的な制御シグナリングを介して、MCG障害の通知をSN２に送信する。この直接的な制御シグナリングは、MAC Control Element (CE) 又はSRB3であってもよい。

【0098】

図２３は、UE３の動作の一例を示している。ステップ２３０１では、UE３のMCG RRC ３１は、MCG障害（e.g., MCG RLF）を検出する。ステップ２３１１～２３１３では、MCG障害の検出に応答して、UE３は、split SRB1のSCG legを介してMCG障害情報をMN１に送信する。ステップ２３１１では、UE３のMCG RRC３１は、MN RRC: MCG Failure Informationメッセージを生成し、これをMCG PDCP３２に渡す。ステップ２３１２では、MCG PDCP３２は、MCG Failure Informationメッセージをカプセル化しているPDCP PDU（PDCP-C PDU）を生成し、UE３のSCG RLC３４、UE３のSCG MAC３５、SN２のSN MAC２３、及びSN２のSN RLC２２を介して、これをMN１のMN PDCP１２に送る。ステップ２３１３では、MN１のMN RRC１１は、MCG Failure InformationメッセージをMN PDCP１２から受信する。

【0099】

これに加えて、ステップ２３５１～２３５４では、MCG障害の検出に応答して、UE３は、MCG障害の通知をSN２に送る。ステップ２３５１では、UE３のMCG RRC３１は、SN２宛てのMCG障害通知を生成し、これをUE３のSCG RRC３３に渡す。ステップ２３５２では、SCG RRC３３は、MCG障害通知をUE３のSCG MAC３５に渡す。ステップ２３５３では、SCG MAC３５は、MCG障害通知を示すMAC CEを生成し、これをSN２のSN MAC２３に送る。当該MAC CEは、ステップ２３１２のPDCP-C PDUと同一のMAC PDUに含まれてもよいし、PDCP-C PDUとは異なるMAC PDUsに含まれてもよい。ステップ２３５４では、当該MAC CEの受信に応答して、SN２のSN MAC２３は、MCG障害通知をSN２のSN RRC２１に渡す。これにより、MCG障害情報をsplit SRBのSCG legを介してMN１に送信する場合であっても、UE３はSN２にもMCG障害を知らせることができる。つまり、SN２はMCG障害を知ることができる。

【0100】

なお図２３では、図示の都合上、UE３からSN２への直接的な制御シグナリグの手順（ステップ２３５１～２３５４）がSplit SRBのSCG legを介したMCG障害情報の送信手順（ステップ２３１１～２３１３）より前に行われるように描かれている。しかしながら、これら２つの手順の実行順序は特に限定されない。各手順内でのステップが図２３の通りであればよく、これら２つの手順は互いに独立に実行されることができる。例えば、ステップ２３５１～２３５４は、ステップ２３１１～２３１３の後に行われてもよいし、ステップ２３１１～２３１３と並行して行われてもよい。

【0101】

＜第９の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。本実施形態のMN１は、UE３にsplit SRB（e.g., SRB1）を設定するとき、アップリンクのプライマリ・パス（primary path）がMCGである（e.g., primaryPathのCellGroupがMCGにセットされる）ことを通知する。さらにMN１は、split SRBのアップリンクのプライマリ・パスをMCGからSCGに切り替える許可を予めUE３に明示的に又は暗示的に送信する。UE３は、split SRBが設定され且つ当該許可を受信しているときのMCG障害（e.g., MCG RLF）の検出に応答して、MCG障害情報をsplit SRBのSCG legを介してMN１に送信する。該MCG障害情報のUE３からMN１への送信は、例えば、図９のステップ９０２に相当する。また、該MCG障害情報の送信の後に、図５～８等に記載のMCG障害の回復に関する手順が行われてもよい。一方当該許可を受信していない場合、UE３は、RRC再接続処理（RRC (connection) re-establishment手順）を行ってもよい。これにより、MN１は、MCG障害が発生したときのUE３の動作（つまり、MCG障害情報の送信又はRRC再接続）を制御できる。当該許可は、さらに、MCG障害の種類を指定してもよい。つまり、MN１は、UE３が複数のMCG障害の種類のうち特定の１又はそれ以上の種類を検出した場合にsplit SRBのアップリンクのプライマリ・パスをMCGからSCGに切り替えることをUE３に許可してもよい。UE３は、検出したMCG障害の種類に応じて、MCG障害情報をsplit SRBのSCG legを介してMN１に送信するようにしてもよい。

【0102】

アップリンクのプライマリ・パスのMCGからSCGへの切り替えは、アップリンクのプライマリ・パスの設定（i.e., RRC configuration）をUE３が（自律的に）MCG用のものからSCG用の別のものに切り替えることを意味してもよい。これに代えて、アップリンクのプライマリ・パスのMCGからSCGへの切り替えは、UE３がMCGのアップリンク（i.e., MCG leg）の代わりにSCGのアップリンク（i.e. SCG leg）を使うことを意味してもよい。つまり、UE３は、アップリンクのプライマリ・パスの設定を変えずに、追加的にSCGのアップリンクを使用してもよい。

【0103】

＜第１０の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。本実施形態のMN１は、split SRBを設定する（又は既に設定している）UE３に対して、当該UE３がMCG障害（e.g., MCG RLF）を検出した場合にRRC再接続処理（RRC (connection) re-establishment手順）又はMCG回復処理（MCG (link) recovery手順）のどちらを行うべきかを示す指示（又はRRC設定情報）を、予め送信する。ここで、MCG回復処理は、UE３がMCG障害情報（e.g., MCG Failure Information）をsplit SRBでSN２を介してMN１に送信することを含む。これにより、MN１は、MCG障害が発生したときのUE３の動作（つまり、MCG障害情報の送信又はRRC再接続）を制御できる。

【0104】

MN１は、UE３に実行させる処理（手順）を明示的に示す情報を送信してもよい。例えば、MN１は、MCG障害（e.g., MCG RLF）の復旧のための方法を示すRRC情報（e.g., MCG-FailureRecovery IE）をUE３に送信するときに、どちらの処理（i.e., RRC再接続処理（e.g., rr-Reestablishment）又はsplit SRBのSCG legを介したMCG障害情報の送信（e.g., fast-MCG-recovery、又はMCG-failure-indication））が行われるべきかをUE３に通知してもよい。UE３は、MCG障害情報を送信するように通知されている場合、MCG障害の検出に応答して、MCG障害情報をsplit SRBのSCG legを介してMN１に送信する。該MCG障害情報のUE３からMN１への送信は、例えば、図９のステップ９０２に相当する。また、該MCG障害情報の送信の後に、図５～８等に記載のMCG障害の回復に関する手順が行われてもよい。一方、UE３はRRC再接続処理を実行するように通知されている場合、RRC (connection) re-establishment手順を行う。

【0105】

＜第１１の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。本実施形態のUE３は、MCG障害（e.g., MCG RLF）の検出に応答して、アップリンクのプライマリ・パス（primary path）をMCGからSCGへ切り替え、MCG障害情報（e.g. MCG Failure Information）をsplit SRB（e.g., SRB1）のSCG legを介してMN１に送信する。このとき、UE３は以下のように動作してもよい。UE３は、アップリンクのプライマリ・パスがMCGからSCGへ切り替えられることに応答して、SCGでアップリンク送信バッファ状況の報告（Buffer Status Report（BSR））をトリガしてもよい。例えば、UE３のMCG RRCエンティティは、MCG障害を検出すると、MCG PDCPエンティティへアップリンクのプライマリ・パスをMCGからSCGへ切り替える指示を送る。MCG MACエンティティは、MCG障害情報をSCGで送信するために当該MCG障害情報（及びその他の未送信データ）のバッファ量（データ量）をSCG PDCPエンティティ及びSCG RLCエンティティから取得する。そして、MCG MACエンティティは、MCG PHYを介してSCGでSN２へ当該送信バッファ情報の報告（BSR）を送信する。

【0106】

SN２は、BSRの受信に応答してUE３にアップリンク（UL）グラントを送信してもよい。当該ULグラントは、アップリンクリソースをUE３に割り当てる。ULグラントの受信に応答して、UE３は、MCG障害情報をMN１に送るために、MCG障害情報を包含するMN RRCメッセージをsplit SRB1のSCG legで送信してもよい。UE３からMN１へのMCG障害情報の送信は、例えば、図９のステップ９０２に相当する。また、該MCG障害情報のMN１への送信が行われた後に、図５～８等に記載のMCG障害の回復に関する手順が行われてもよい。

【0107】

さらに又はこれに代えて、MCG障害（e.g., MCG RLF）の検出に応答して、UE３は、MN１により終端され且つアップリンクのプライマリ・パスがMCGに設定されている１又はそれ以上のsplit DRBs（MN terminated bearers）のプライマリ・パスをSCGに切り替えてもよい。さらに又はこれに代えて、MCG障害（e.g., MCG RLF）の検出に応答して、UE３は、SN２により終端され且つアップリンクのプライマリ・パスがMCGに設定されている１又はそれ以上のsplit DRBs（SN terminated bearers）のプライマリ・パスをSCGに切り替えてもよい。UE３は、このようなsplit DRBに対する制御を、上述のsplit SRBに対する制御と同様に行ってもよい。具体的には、UE３は、split SRBのアップリンクのプライマリ・パスをMCGからSCGに切り替えるように指示されている（又はそれを許可されている）場合、split DRBに対してもアップリンクのプライマリ・パスをMCGからSCGに切り替えるように指示されている（又はそれを許可されている）と考えてもよい。これに代えて、MN１は予めUE３に、split DRBsのプライマリ・パスの切り替えがUE３に許可されるか否かを明示的または暗示的に通知してもよい。MN１はプライマリ・パスの切り替えがUE３に許可されるか否かをDRB毎に（DRB単位で）UE３に通知してもよい。

【0108】

＜第１２の実施形態＞
本実施形態は、第１の実施形態で説明されたMN１及びSN２の動作の具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。本実施形態では、SN２とUE３との間にダイレクトSRB（i.e., SRB3）が設定されている。このとき、MN１は、MCG障害の検出に応じて、MCG障害の復旧のために、SN変更を伴わないintra-MNハンドオーバを行う。

【0109】

図２４は、SN変更を伴わないintra-MNハンドオーバ手順内で行われるMN１及びSN２のシグナリングの一例を示している。ステップ２４０１では、MN１は、SN MODIFICATION REQUESTメッセージをSN２に送る。当該SN MODIFICATION REQUESTメッセージは、SN２内のUE３に関連付けられた設定又はリソースの修正（又は更新）をSN２に要求する。例えば、当該メッセージは、SN２に終端されるベアラ（SN terminated bearer）に適用されるセキュリティ鍵（e.g., SgNB Security Key）の修正（又は更新）を要求するために、新たなセキュリティ鍵の情報を示してもよい。

【0110】

ステップ２４０１のSN MODIFICATION REQUESTメッセージは、さらに、当該メッセージがMCG障害又はその回復に関連付けられていることをSN２に示すための表示を含む。当該表示は、例えば、MCG failure recovery notification、MCG link recovery notification、又はMCG failure notificationと呼ばれてもよい。当該表示は、当該メッセージに包含されるIE又はCause値であってもよい。これに代えて、Cause値は例えばMCG Radio Connection With UE Lost、又はMCG RLFでもよい。当該表示の受信に応答して、SN２は、SN２内の設定（又はリソース）の修正を延期する。

【0111】

ステップ２４０２では、SN２は、UE３のためのSN（又はSCG）リソース修正のMN１からの要求を確認（confirm）するために、SN MODIFICATION REQUEST ACKNOWLEDGEメッセージをMN１に送る。当該メッセージは、SN２により生成されたCG-Configメッセージを含んでもよい。CG-Configメッセージは、ステップ５０１のSN MODIFICATION REQUESTメッセージに基づいてSN２により生成されたSCG無線設定（e.g., scg-CellGroupConfig及びscg-RB-Configのうち１つ又は両方）を含む。

【0112】

ステップ２４０３及び２４０４では、MN１は、SRB3を介してUE３にMN RRCメッセージ（e.g., RRC Reconfiguration including reconfigurationWithSync）を送信する。具体的には、ステップ２４０３では、MN１は、当該MN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間（inter-RAN Node）メッセージ）を包含するRRC TRANSFERメッセージをSN２宛てに送る。ステップ２４０４では、SN２は、MN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間メッセージの少なくとも一部）を包含するSN RRC Reconfigurationメッセージを生成し、これをSRB3を介してUE３に送信する。このとき、SN２は、SN２のベアラのためのセキュリティ鍵（e.g., S-KgNB）によってSN RRC Reconfigurationメッセージを暗号化する。

【0113】

UE３のSCG RRCエンティティは、SN RRC Reconfigurationメッセージを復号してMN RRCメッセージを取り出し、それをUE３のMCG RRCエンティティへ渡す。UE３は、当該MN RRCメッセージを受信すると、それに包含されるRRCの設定情報（e.g., securityConfig(HO) 及びsk-Counterのうち１つ又は両方）に従い、SN変更を伴わないintra-MNハンドオーバを実行する。MN RRCメッセージは、SN変更を伴わないintra-MNハンドオーバのためのSN RRCメッセージ（又はSN RRC設定）を包含してもよい。この場合、UE３のMCG RRCエンティティは、当該SN RRCメッセージをUE３のSCG RRCエンティティへ渡す。UE３は、当該MN RRCメッセージ及びSN RRCメッセージに従ってSN変更を伴わないintra-MNハンドオーバを実行する。

【0114】

ステップ２４０５では、SN２は、MN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間メッセージの少なくとも一部）を包含するSN RRC ReconfigurationメッセージをUE３に送信した後に、ステップ２４０１のSN MODIFICATION REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソース（e.g., SN２内の設定又はリソース）の修正（更新）を実行する。SN２は、当該SN RRC ReconfigurationメッセージをUE３に送信したことに応答して、SN（SCG）リソースを修正（更新）してもよい。すなわち、図２４の例では、MN-initiated SN Modification Preparation手順がRRC Transfer手順（又はSN RRC reconfiguration手順）と相互作用（interact）する。言い換えると、MN-initiated SN Modification Preparation手順がRRC Transfer手順（又はSN RRC reconfiguration手順）と関連付けられる。幾つかの実装では、もしSN２がSN MODIFICATION REQUESTメッセージをMN１から受信した後に（e.g., 直後に（right after））RRC TRANSFERメッセージをさらに受信し、それがSRB3で送信されるMN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間（inter-RAN Node）メッセージ）を包含している場合、SN２は、当該MN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間メッセージの少なくとも一部）のUE３への送信をSN Modification Preparation手順よりも優先して実行する。

【0115】

図２５は、図２４に示された手順の変化例を示している。ステップ２５０１～２５０４におけるMN１及びSN２の動作はステップ２４０１～２４０４のそれと同様である。ステップ２５０５では、SN２は、SN RRC Reconfiguration CompleteメッセージをUE３から受信する。

【0116】

ステップ２５０６では、SN２は、UE３からのSN RRC Reconfiguration Completeメッセージを受信した後に、ステップ２５０１のSN MODIFICATION REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソースの修正（更新）を実行する。SN２は、SN RRC Reconfiguration CompleteメッセージをUE３から受信したことに応答して、SN（SCG）リソースを修正（更新）してもよい。すなわち、図２５の例では、MN-initiated SN Modification Preparation手順がRRC Transfer手順（又はSN RRC reconfiguration手順）と相互作用（interact）する。言い換えると、MN-initiated SN Modification Preparation手順がRRC Transfer手順（又はSN RRC reconfiguration手順）と関連付けられる。幾つかの実装では、もしSN２がSN MODIFICATION REQUESTメッセージをMN１から受信した後に（e.g., 直後に（right after））RRC TRANSFERメッセージをさらに受信し、それがSRB3で送信されるMN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間（inter-RAN Node）メッセージ）を包含している場合、SN２は、当該MN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間メッセージの少なくとも一部）のUE３への送信をSN Modification Preparation手順よりも優先して実行する。

【0117】

図２６は、図２４に示された手順の他の変化例を示している。ステップ２６０１～２６０５は、図２５のステップ２５０１～２５０５と同様である。

【0118】

ステップ２６０６では、UE３は、ReconfigurationWithSync IEを包含するSpCellConfig IE（のservCellIndex）により指示された新たなPCellを介してMN１にRRC Reconfiguration Completeメッセージを送信する。ReconfigurationWithSync IEの代わりにMobilityControlInfo IEが使用される場合、新たなPCellは、当該IEが包含するtargetPhysCellIdにより指定されてもよい。ステップ２６０７では、MN１は、SN RECONFIGURATION COMPLETEメッセージをSN２に送る。当該SN RECONFIGURATION COMPLETEメッセージは、ステップ２６０２のSN MODIFICATION REQUEST ACKNOWLEDGEメッセージに包含されていたSCG無線設定（e.g., scg-CellGroupConfig及びscg-RB-Configのうち１つ又は両方）をUE３が成功裏に適用したことを示す。

【0119】

ステップ２６０８では、SN２は、MN１からのSN RECONFIGURATION COMPLETEメッセージの受信後に、ステップ２６０１のSN MODIFICATION REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソースの修正（更新）を実行する。SN２は、SN RECONFIGURATION COMPLETEメッセージの受信に応答して、SN（SCG）リソースを修正（更新）してもよい。すなわち、図２６の例では、MN-initiated SN Modification Preparation手順がSN Reconfiguration Complete手順と相互作用（interact）する。言い換えると、MN-initiated SN Modification Preparation手順がSN Reconfiguration Complete手順と関連付けられる。

【0120】

幾つかの実装では、もしMN１がRRC reconfiguration手順の成功に関する報告を必要としている端末情報（e.g., UEコンテキスト）の修正（i.e. SN MODIFICATION REQUEST）をSN２が受け入れる（admit）なら、SN２はMN１にSN MODIFICATION REQUEST ACKNOWLEDGEメッセージを送信するとき、タイマ（e.g., T_DCoverall, TXn_DCoverall）をスタートしてもよい。そして、SN２は、SN RECONFIGURATION COMPLETEメッセージを受信すると、当該タイマを停止してもよい。さらに、もしSN２がSN MODIFICATION REQUESTメッセージをMN１から受信した後に（e.g., 直後に（right after））RRC TRANSFERメッセージをさらに受信し、それがSRB3で送信されるMN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間（inter-RAN Node）メッセージ）を包含している場合、SN２は、当該MN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間メッセージの少なくとも一部）のUE３への送信をSN Modification Preparation手順よりも優先する。すなわち、SN２は、少なくともSN RECONFIGURATION COMPLETEメッセージを受信するまでは当該端末情報の修正（i.e. SN（SCG）リソースを修正（更新））を行わない。

【0121】

図２７は、MN RRCメッセージをSRB3を介して送信するために改良されたRRC TRANSFERメッセージのフォーマットの具体例を示している。図２７のRRC TRANSFERメッセージは、MN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間メッセージ）を包含するRRC Container IEを含むことができる。当該RRC Container IEは、新たに規定されるRRC TRANSFERメッセージ内のIE（e.g., MN SRB IE）のサブIEであってもよい。幾つかの実装では、SN２は、MN SRB IE内のRRC Container IEを受信したなら、当該RRC Container IEに包含されているMN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間メッセージの少なくとも一部）をUE３に必ず送信する。SN２は、MN１から受信したRRC TRANSFERメッセージにMN SRB IEが包含されている場合（それを検出したことに応答して）、当該MN SRB IEに包含されるRRCメッセージをSRB3で送信するよう動作してもよい。

【0122】

図１８の例と類似して、図２７に示されたMN SRB IEは、Delivery Requirement IEを含んでもよい。当該Delivery Requirement IEは、MN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間メッセージの少なくとも一部）がUE３に必ず配信される（delivered）べきであるか否かを示す。されに又はこれに代えて、当該Delivery Priority IEは、MN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間メッセージの少なくとも一部）が他のメッセージ又は情報よりも優先してUE３に配信される（delivered）べきであるか否かを示す。例えば、Delivery Requirement IEの値が“essential”にセットされている場合、これはMN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間メッセージの少なくとも一部）がUE３に必ず配信されるべきであることを意味する。

【0123】

なお、SRB3を介したMN RRCメッセージの送信のために、RRC TRANSFERメッセージとは異なる新たなXnAP/X2APメッセージが定義されてもよい。図２８は、図２４に示された手順の他の変化例を示している。ステップ２８０１及び２８０２は、図２４のステップ２４０１及び２４０２と同様である。

【0124】

図２８の例では、MN１は、MN RRCメッセージをSRB3を介してUE３に送信するために、MN MODIFICATION INDICATIONメッセージをSN２に送る（ステップ２８０３）。SN２は、要求されたMN RRCメッセージを包含するSN RRCメッセージ（e.g., RRC Reconfiguration）をUE３に送信し（ステップ２８０４）、UE３からのSN RRC Reconfiguration Completeメッセージを受信（ステップ２８０５）する。SN２は、MN MODIFICATION INDICATIONメッセージに対する返信メッセージ（e.g., MN RECONFIGURATION COMPLETEメッセージ、又はMN MODIFICATION COMPLETEメッセージ）をMN１に送信してもよい（ステップ２８０６）。例えば、SN２は、UE３からのSN RRC Reconfiguration Completeメッセージの受信に応答して、MN RECONFIGURATION COMPLETEメッセージをMN１に送信してもよい。

【0125】

ステップ２８０７では、SN２は、UE３からSN RRC Reconfiguration Completeメッセージを受信した後に、ステップ２８０１のSN MODIFICATION REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソースの修正（更新）を実行する。SN２は、MN RECONFIGURATION COMPLETEメッセージをMN１に送信した後に、SN（SCG）リソースを修正（更新）してもよい。

【0126】

図２９は、MN MODIFICATION INDICATIONメッセージのフォーマットの具体例を示している。図２９の例では、MN MODIFICATION INDICATIONメッセージは、M-NG-RAN node to S-NG-RAN node Container IEを含む。当該IEは、CG-ConfigInfo messageを含む。当該CG-ConfigInfo messageは、MN RRCメッセージ（e.g., RRC (Connection) Reconfigurationメッセージ）を示す。図３０に示されたCG-ConfigInfo messageは、sourceConfigMCGフィールド３００１を含むことができる、sourceConfigMCGフィールド３００１は、MN RRCメッセージ（e.g., RRC (Connection) Reconfigurationメッセージ）を包含する。MN１とSN２が異なる無線アクセス技術（RAT）を用いる場合（e.g., EN-DC）、sourceConfigMCGフィールド３００１は、source RATのRRCメッセージ（i.e., MN RRCメッセージ）を透過的に（transparent）に包含してもよい。言い換えると、SN２は、sourceConfigMCGフィールド３００１内の情報を解析又は認識せずに、これをUE３に転送してもよい。一方、MN１とSN２が同じRAT又は同種のPDCP（e.g., NR PDCP）を用いる場合（e.g., NR-DC, NGEN-DC）、sourceConfigMCGフィールド３００１は、source RATのRRCメッセージを明示的に包含してもよい。

【0127】

図３１は、図２８に示された手順の変化例を示している。図３１の例では、SN MODIFICATION REQUEST/ACKNOWLEDGEメッセージに代えて、MN MODIFICATION NOTIFICATION/RESPONSEメッセージ（ステップ３１０１及び３１０２）が使用される。図３１の例では、MN１がSN２にMN MODIFICATION NOTIFICATIONメッセージを送る（ステップ３１０１）。MN MODIFICATION NOTIFICATIONメッセージは、MCGの修正（又は変更又は再設定）に関連付けられたSCGの修正（又は再設定）が必要とされることをSN２に示す。SN MODIFICATION REQUESTメッセージと同様に、MN MODIFICATION NOTIFICATIONメッセージは、SN２内のUE３のための設定又はリソースの修正（又は更新）をSN２に要求する。MN MODIFICATION NOTIFICATIONメッセージは、当該メッセージがMCG障害又はその回復に関連付けられていることをSN２に示すための表示を含んでもよい。これに代えて、MN MODIFICATION NOTIFICATIONメッセージの送信それ自体が、MCG障害又はその回復に関連付けられてもよい（つまり、MCG障害又はその回復を意味してもよい）。言い換えると、MN MODIFICATION NOTIFICATIONメッセージはMCG障害の回復のために送信され、SN２は当該メッセージを受信することで（受信に応答して）、MN１がMCG障害の回復を行おうとしていることを認識してもよい。

【0128】

ステップ３１０２では、SN２は、UE３のためのSN（SCG）リソース修正のMN１からの要求を確認（confirm）するために、MN MODIFICATION NOTIFICATION RESPONSEメッセージをMN１に送る。当該メッセージは、SN MODIFICATION REQUEST ACKNOWLEDGEメッセージと同様に、SN２により生成されたCG-Configメッセージを含んでもよい。

【0129】

ステップ３１０３では、MN１は、MN RRCメッセージ（e.g., RRC Reconfiguration including reconfigurationWithSync）をSRB3を介してUE３に送信するために、MN MODIFICATION INDICATIONメッセージをSN２に送る。

【0130】

ステップ３１０４～３１０５は、図２８のステップ２８０４～２８０５と同様である。SN２は、UE３からSN RRC Reconfiguration Completeメッセージを受信すると、MN MODIFICATION COMPLETEメッセージをMN１に送信してもよい（ステップ３１０６）。MN MODIFICATION COMPLETEメッセージは、MN RECONFIGURATION COMPLETEメッセージと呼ばれてもよい。ステップ３１０７では、図２８のステップ２８０７と同様に、SN２は、ステップ３１０１のMN MODIFICATION NOTIFICATIONメッセージにより要求されていたUE３のためのSN（SCG）リソースの修正（更新）を実行する。

【0131】

ステップ３１０１のMN MODIFICATION NOTIFICATIONメッセージ、ステップ３１０２のMN MODIFICATION NOTIFICATION RESPONSEメッセージ、及びステップ３１０３のMN MODIFICATION REQUESTメッセージ（及びステップ３１０６のMN MODIFICATION COMPLETEメッセージ）が１つの（一連の）手順として規定されてもよい。当該手順では、これらの動作が一連の動作として（つまり関連付けて）実行されてもよい。当該手順は、例えば、MN MODIFICATION preparation手順又はMN RECOVERY preparation手順と呼ばれてもよい。

【0132】

図３２は、図２４～図２６に示された手順の具体例を示している。図３２のステップ３２０５～３２０８は、図２４のステップ２４０１～２４０４、図２５のステップ２５０１～２５０４、及び図２６のステップ２６０１～２６０４に相当する。図３２のステップ３２０９は、図２５のステップ２５０５及び図２６のステップ２６０５に相当する。図３２のステップ３２１２及び３２１３は、図２６のステップ２６０６及び２６０７に相当する。

【0133】

図３２のステップ３２０１では、UE３はMCG障害（e.g., MCG RLF）を検出する。ステップ３２０２では、UE３は、SRB3を介してSN２にMCG障害情報を送信する。ステップ３２０３では、SN２は、MCG障害情報をMN２に転送する。SN２からMN１へのMCG障害情報の転送のためにRRC TRANSFERメッセージが使用されてもよい。ステップ３２０４では、MN１は、MCG障害情報の受信に応じて、MCG障害復旧手順を決定する。このMCG障害復旧手順は、SN変更を伴わないintra-MNハンドオーバ手順（すなわち、ステップ３２０５～３２１４）を含む。。

【0134】

なお、図３２の例では、RRC TRANSFERメッセージ（ステップ３２０７）は、MN MODIFICATION INDICATIONメッセージ（ステップ２８０３）又はMN MODIFICATION REQUESTメッセージ（ステップ３１０３）に置き換えられてもよい。この場合、SN２は、MN RECONFIGURATION COMPLETEメッセージ（又はMN MODIFICATION COMPLETEメッセージ）をMN１に送信してもよい（ステップ３２１０）。

【0135】

＜第１３の実施形態＞
本実施形態は、第１の実施形態で説明されたMN１及びSN２の動作の具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。本実施形態では、SN２とUE３との間にダイレクトSRB（i.e., SRB3）が設定されているときのMCG障害の検出に応じて、MN１は、MCG障害の復旧のために、SN変更を伴わないinter-MNハンドオーバを行う。

【0136】

図３３は、SN変更を伴わないinter-MNハンドオーバ手順内で行われるMN１及びSN２のシグナリングの一例を示している。ステップ３３０１及び３３０２は図１１のステップ１１０１及び１１０２と同様である。具体的には、ステップ３１０１では、MN１は、SN RELEASE REQUESTメッセージをSN２に送る。MN１は、SN２内のUEコンテキストが維持される（kept）ことをSN２に示すために、 “True”にセットされたUE Context Kept Indicator IEを当該SN RELEASE REQUESTメッセージに含める。

【0137】

ステップ３３０１のSN RELEASE REQUESTメッセージは、さらに、当該メッセージがMCG障害又はその回復に関連付けられていることをSN２に示すための追加の表示を含む。当該追加の表示は、例えば、MCG failure recovery notification、MCG link recovery notification、又はMCG failure notificationと呼ばれてもよい。当該表示は、当該メッセージに包含されるIE又はCause値であってもよい。当該追加の表示の受信に応答して、SN２は、SN２内の設定（又はリソース）の解放を延期する。具体的には、SN２は、UE３に関連付けられたMN１とSN２の間のシグナリング・コネクションのリソース（resources）の解放を延期してもよい。さらに又はこれに代えて、SN２は、UE３に割り当てられていた無線リソースの解放を延期してもよい。

【0138】

ステップ３３０２では、SN２は、UE３のためのSN（SCG）リソース解放のMN１からの要求を確認（confirm）するために、SN RELEASE REQUEST ACKNOWLEDGEメッセージをMN１に送る。

【0139】

ステップ３３０３及び３３０４では、MN１は、SRB3を介してUE３にMN RRCメッセージ（e.g., RRC Reconfiguration including reconfigurationWithSync）を送信する。ステップ３３０３及び３３０４は、図２４のステップ２４０３及び２４０４と同様である。

【0140】

ステップ３３０５では、SN２は、MN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間メッセージの少なくとも一部）をUE３に送信した後に、ステップ３３０１のSN RELEASE REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソースの解放を実行する。SN２は、MN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間メッセージの少なくとも一部）をUE３に送信したことに応答して、SN（SCG）リソースを解放してもよい。すなわち、図３３の例では、MN-initiated SN Release手順がRRC Transfer手順（又はSN RRC reconfiguration手順）と相互作用（interact）する。言い換えると、MN-initiated SN Release手順がRRC Transfer手順（又はSN RRC reconfiguration手順）と関連付けられる。幾つかの実装では、もしSN２がSN RELEASE REQUESTメッセージをMN１から受信した後に（e.g., 直後に（right after））RRC TRANSFERメッセージをさらに受信し、それがSRB3で送信されるMN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間（inter-RAN Node）メッセージ）を包含している場合、SN２は、当該MN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間メッセージの少なくとも一部）のUE３への送信をSN Release手順よりも優先して実行する。

【0141】

図３４は、図３３に示された手順の変形例を示している。ステップ３４０１～３４０４におけるMN１及びSN２の動作はステップ３３０１～３３０４のそれと同様である。ステップ３４０５では、SN２は、SN RRC Reconfiguration CompleteメッセージをUE３から受信する。

【0142】

ステップ３４０６では、SN２は、UE３からのSN RRC Reconfiguration Completeメッセージを受信した後に、ステップ３５０１のSN RELEASE REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソースの解放を実行する。SN２は、SN RRC Reconfiguration CompleteメッセージをUE３から受信したことに応答して、SN（SCG）リソースを解放してもよい。すなわち、図３４の例では、MN-initiated SN Release手順がRRC Transfer手順（又はSN RRC reconfiguration手順）と相互作用（interact）する。言い換えると、MN-initiated SN Release手順がRRC Transfer手順（又はSN RRC reconfiguration手順）と関連付けられる。幾つかの実装では、もしSN２がSN RELEASE REQUESTメッセージをMN１から受信した後に（e.g., 直後に（right after））RRC TRANSFERメッセージをさらに受信し、それがSRB3で送信されるMN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間（inter-RAN Node）メッセージ）を包含している場合、SN２は、当該MN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間メッセージの少なくとも一部）のUE３への送信をSN Release手順よりも優先して実行する。

【0143】

図３５は、図３３に示された手順の変形例を示している。ステップ３５０１～３５０５は、図３４のステップ３４０１～３４０５と同様である。ステップ３５０６では、UE３は、ReconfigurationWithSync IEを包含するSpCellConfig IE（のservCellIndex）により指示された新たなPCellを介してターゲットMN４にRRC Reconfiguration Completeメッセージを送信する。ステップ３５０７では、ターゲットMN４は、SN RECONFIGURATION COMPLETEメッセージをSN２に送る。

【0144】

ステップ３５０８では、SN２は、ターゲットMN４からのSN RECONFIGURATION COMPLETEメッセージの受信後に、ステップ３５０１のSN RELEASE REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソースの解放を実行する。SN２は、SN RECONFIGURATION COMPLETEメッセージの受信に応答して、SN（SCG）リソースを解放してもよい。すなわち、図３５の例では、MN-initiated SN Release手順がSN Reconfiguration Complete手順と相互作用（interact）する。言い換えると、MN-initiated SN Release手順がSN Reconfiguration Complete手順と関連付けられる。

【0145】

図３３の手順は、さらに変形されてもよい。SN RELEASE REQUEST/ACKNOWLEDGEメッセージに代えて、新たなXnAP/X2APメッセージ（messages）が使用されてもよい。例えば、図３１の手順と類似して、MN MODIFICATION NOTIFICATION/RESPONSEメッセージが使用されてもよい。さらに又はこれに代えて、RRC TRANSFERメッセージの代わりに新たなXnAP/X2APメッセージ（例えば、図３１のMN MODIFICATION REQUESTメッセージ）が使用されてもよい。図３１に関して説明したように、MN MODIFICATION NOTIFICATIONメッセージ、MN MODIFICATION RESPONSEメッセージ、及びMN MODIFICATION REQUESTメッセージがまとめて１つの（一連の）手順として規定されてもよい。

【0146】

図３６は、図３３～図３５に示された手順の具体例を示している。図３６のステップ３６０７～３６１０は、図３３のステップ３３０１～３３０４、図３４のステップ３４０１～３４０４、及び図３５のステップ３５０１～３５０４に相当する。図３６のステップ３６１１は、図３４のステップ３４０５及び図３５のステップ３５０５に相当する。図３６のステップ３６１２及び３６１３は、図３５のステップ３５０６及び３５０７に相当する。図３６で、SN２は、ターゲットMN４からSN RECONFIGURATION COMPLETEメッセージを受信すると（ステップ３６１３）、ステップ３６０７のSN RELEASE REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソースの解放を、UE３の端末情報（e.g., UEコンテキスト）を除いて、実行してもよい。例えば、SN２は、ソースMN１とのMR-DCのためにUE３に関連付けられた無線リソース（e.g., source SCG lower layer configuration（e.g., CellGroupConfig））を解放してもよい。

【0147】

図３６のステップ３６０１では、UE３は、SRB3を介してSN２にMCG障害情報を送信する。ステップ３６０２では、SN２は、MCG障害情報をMN１に転送する。MN１は、MCG障害情報の受信に応じて、MCG障害復旧手順を決定する。このMCG障害復旧手順は、SN変更を伴わないinter-MNハンドオーバ手順（すなわち、ステップ３６０３～３６１６）を含む。SN変更を伴わないinter-MNハンドオーバ手順は、パススイッチのためのコアネットワーク（Core Network(CN)）５とのシグナリング（ステップ３６１４）を含む。SN２は、ソースMN１からUE CONTEXT RELEASEメッセージを受信すると（ステップ３６１６）、ソースMN１とのMR-DCのために保持していたUE３の端末関連リソース（e.g., UEコンテキストに関連するソースMN1とのC-planeリソース）を解放する。

【0148】

＜第１４の実施形態＞
本実施形態は、第１の実施形態で説明されたMN１及びSN２の動作の具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。本実施形態では、SN２とUE３との間にダイレクトSRB（i.e., SRB3）が設定されているときのMCG障害の検出に応じて、MN１は、MCG障害の復旧のために、SN解放を伴うMN to gNB change手順を行う。

【0149】

図３７は、SN解放を伴うMN to gNB change手順の具体例を示している。図３７のステップ３７０１では、UE３は、SRB3を介してSN２にMCG障害情報を送信する。ステップ３７０２では、SN２は、MCG障害情報をMN１に転送する。MN１は、MCG障害情報の受信に応じて、MCG障害復旧手順を決定する。このMCG障害復旧手順は、SN解放を伴うMN to gNB change手順（すなわち、ステップ３７０３～３７１４）を含む。

【0150】

ステップ３７０５では、MN１（i.e., ソースMN）は、SN RELEASE REQUESTメッセージをSN２に送る。ステップ３７０５のSN RELEASE REQUESTメッセージは、さらに、当該メッセージがMCG障害又はその回復に関連付けられていることをSN２に示すための表示を含む。当該表示は、例えば、MCG failure recovery notification、MCG link recovery notification、又はMCG failure notificationと呼ばれてもよい。当該表示は、当該メッセージに包含されるIE又はCause値であってもよい。当該表示の受信に応答して、SN２は、SN２内の設定（又はリソース）の解放を延期する。具体的には、SN２は、UE３に関連付けられたMN１とSN２の間のシグナリング・コネクションのリソース（resources）の解放を延期してもよい。さらに、SN２は、UE３に関連付けられた端末情報（e.g., UEコンテキスト）の解放を延期してもよい。さらに、SN２は、UE３に関連付けられた無線リソース（e.g., SCG configuration）の解放を延期してもよい。

【0151】

ステップ３７０６では、SN２は、UE３のためのSN（SCG）リソース解放のMN１からの要求を確認（confirm）するために、SN RELEASE REQUEST ACKNOWLEDGEメッセージをMN１に送る。

【0152】

ステップ３７０７及び３７０８では、MN１は、SRB3を介してUE３にMN RRCメッセージ（e.g., RRC Reconfiguration including reconfigurationWithSync）を送信する。ステップ３７０７及び３７０８は、図２４のステップ２４０３及び２０４及び図３３のステップ３３０３及び３３０４などと同様である。

【0153】

幾つかの実装では、SN２は、MN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間メッセージの少なくとも一部）をUE３に送信（ステップ３７０８）したことに応答して、ステップ３７０５のSN RELEASE REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソースを解放してもよい。これに代えて、SN２は、SN RRC Reconfiguration CompleteメッセージをUE３から受信（ステップ３７０９）したことに応答して、SN（SCG）リソースを解放してもよい。これに代えて、SN２は、ターゲットgNB６からのSN RECONFIGURATION COMPLETEメッセージの受信（ステップ３７１１）に応答して、SN（SCG）リソースを解放してもよい。例えばSN２は、ステップ３７０５のSN RELEASE REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソースの解放を、UE３の端末情報（e.g., UEコンテキスト）を除いて、実行してもよい。

【0154】

＜第１５の実施形態＞
本実施形態は、第１の実施形態で説明されたMN１及びSN２の動作の具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。本実施形態では、SN２とUE３との間にダイレクトSRB（i.e., SRB3）が設定されているときのMCG障害の検出に応じて、MN１は、MCG障害の復旧のために、SN to gNB change（role change）手順を行う。

【0155】

図３８は、SN to gNB change手順の具体例を示している。図３８のステップ３８０１では、UE３は、SRB3を介してSN２にMCG障害情報を送信する。ステップ３８０２では、SN２は、MCG障害情報をMN１に転送する。MN１は、MCG障害情報の受信に応じて、MCG障害復旧手順を決定する。このMCG障害復旧手順は、SN to gNB change手順（すなわち、ステップ３８０３～３８１２）を含む。

【0156】

ステップ３８０３では、MN１（i.e., ソースMN）は、HANDOVER REQUESTメッセージをSN２に送る。ステップ３８０３のHANDOVER REQUESTメッセージは、ハンドオーバ後にSN２がMNとして（又はStandalone（SA）で）UE３を管理することを期待することを明示的又は暗示的に示す情報を含んでもよい。例えば、MN１は当該メッセージにUE Context Reference at the SgNB IEを含めることでそれを示してもよい。一方、当該情報（e.g., UE Context Reference at the SgNB IE）を受信すると、SN２は、MN１とMR-DCを行っているUE３に対してハンドオーバを実行して（ターゲット）MNとして（又はSAで）UE３を受け入れることを期待（又は要求）されていると理解（又は認識）してもよい。

【0157】

ステップ３８０４では、SN２は、UE３のハンドオーバを受け入れることを示すために、HANDOVER REQUEST ACKNOWLEDGEメッセージをMN１に送る。SN２は、当該メッセージにUE Context Kept Indicator IEを含め（i.e., Trueにセットし）、これによりSN２がMNとして（又はSAで）UE３を管理することをMN１に示してもよい。

【0158】

ステップ３８０５では、MN１（i.e., ソースMN）は、SN RELEASE REQUESTメッセージをSN２に送る。ステップ３８０５のSN RELEASE REQUESTメッセージは、UE Context Kept Indicator IEを含んでもよい。さらに、SN RELEASE REQUESTメッセージは、当該メッセージがMCG障害又はその回復に関連付けられていることをSN２に示すための表示を含む。当該表示は、例えば、MCG failure recovery notification、MCG link recovery notification、又はMCG failure notificationと呼ばれてもよい。当該表示は、当該メッセージに包含されるIE又はCause値であってもよい。当該表示の受信に応答して、SN２は、SN２内の設定（又はリソース）の解放を延期する。具体的には、SN２は、UE３に関連付けられたMN１とSN２の間のシグナリング・コネクションのリソース（resources）の解放を延期してもよい。さらに、SN２は、UE３に関連付けられた端末情報（e.g., UEコンテキスト）の解放を延期してもよい。さらに、SN２は、ソースMN１とのMR-DCのためにUE３に関連付けられた無線リソース（e.g., SCG lower layer configuration）の解放を延期してもよい。

【0159】

ステップ３８０６では、SN２は、UE３のためのSN（SCG）リソース解放のMN１からの要求を確認（confirm）するために、SN RELEASE REQUEST ACKNOWLEDGEメッセージをMN１に送る。

【0160】

ステップ３８０７及び３８０８では、MN１は、SRB3を介してUE３にMN RRCメッセージ（e.g., RRC Reconfiguration including reconfigurationWithSync）を送信する。ステップ３８０７及び３８０８は、図２４のステップ２４０３及び２４０４並びに図３４のステップ３４０３及び３４０４などと同様である。つまり、SN２はハンドオーバのターゲットRANノード（MN又はSA gNB）であるが、少なくとも当該MN RRCメッセージの送信まではソースSNとして動作する。

【0161】

幾つかの実装では、SN２は、MN RRCメッセージ（又はこれを包含するMN１とSN２の間のRANノード間メッセージの少なくとも一部）をUE３に送信（ステップ３８０８）したことに応答して、ステップ３８０５のSN RELEASE REQUESTメッセージにより要求されていたUE３のためのSN（SCG）リソースを解放してもよい。これに代えて、SN２は、HARQ-ACK（及びRLC ARQ-ACK）をUE３から受信（ステップ３８０９）したこと、又はRRC Reconfiguration CompleteメッセージをUE３から受信（ステップ３８１０）したことに応答して、ソースMN１とのMR-DCのためのSN（SCG）リソースを解放してもよい。

【0162】

＜第１６の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。本実施形態は、MN RRCメッセージを転送するためにMN１からSN２に送られるRRC TRANSFERメッセージの改良を提供する。

【0163】

図３９は、MCG復旧手順の一例を示している。図３９の例では、SN２とUE３との間にダイレクトSRB（i.e., SRB3）が設定されているときのMCG障害の検出に応じて、MN１は、MCG障害の復旧のために、SN変更を伴わないinter-MNハンドオーバを行う

【0164】

図３９の手順は、図３６のそれと類似する。ただし、図３９の手順では、MN１からUE３へのSRB3を介するMN RRCメッセージの送信（ステップ３９０７～３９１０）がSN Release手順（ステップ３９１１及び３９１２）よりも前に行われる。ステップ３９０７～３９１０は、図２８のステップ２８０３～２８０６と同様である。ステップ３９０７のMN MODIFICATION INDICATIONメッセージを受信すると、SN２は、MN RRCメッセージのUE３への配信が必ず行われるべきであることを認識する。一方、ステップ３９１１では、MN１は、MCG障害又はその回復との関連付けを示す表示をSN RELEASE REQUESTメッセージに含めなくてもよい。

【0165】

ステップ３９０７のMN MODIFICATION INDICATIONメッセージに代えて、RRC TRANSFERメッセージが用いられてよい。この場合、当該RRC TRANSFERメッセージは、PDCP PDUのUE３への配信が必ず行われるべきであることを示す。当該RRC TRANSFERメッセージは、“essential”にセットされたDelivery Requirement IEを含んでもよい。

【0166】

＜第１７の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。本実施形態のMN１は、SRB3を介してRRCメッセージをSN２に送信できるよう設定されているUE３がMCG障害（e.g., MCG RLF）を検出した場合に、UE３がRRC再接続処理（RRC (connection) re-establishment手順）又はMCG回復処理（MCG (link) recovery手順）のどちらを行うべきかを示す指示（又はRRC設定情報）を、予めUE３に送信する。ここで、MCG回復処理は、UE３がMCG障害情報（e.g., MCG Failure Information）をSRB3でSN２に送信することを含む。さらに、MCG回復処理は、MCG障害情報を受信したSN２が、当該MCG障害情報又はそれから導出される制御情報をMN１に送信することを含んでもよい。これにより、MN１は、MCG障害が発生したときのUE３の動作（つまり、MCG障害情報の送信又はRRC再接続）を制御できる。

【0167】

MN１は、UE３に実行させる処理（手順）を明示的に示す情報を送信してもよい。MN１は、SN２がSRB3のRRC設定（e.g., RadioBearerConfig IE）をUE３に送信するときに（又は送信した後に）、MN RRCメッセージ（e.g., RRC (Connection) Reconfiguration）で当該処理（手順）をUE３に通知してもよい。例えば、MN１はMCG障害（e.g., MCG RLF）の復旧のための方法を示すRRC情報（e.g., MCG-FailureRecovery IE）をUE３に送信するときに、どちらの処理（i.e., RRC再接続処理（e.g., rr-Reestablishment）又はSRB3でのSN２へのMCG障害情報の送信（e.g., fast-MCG-recovery、又はMCG-failure-indication））が行われるべきかをUE３に通知してもよい。UE３は、MCG障害情報を送信するように通知されている場合、MCG障害の検出に応答して、MCG障害情報をSRB3でSN２に送信する。SN２は、受信したMCG障害情報又はそれから導出される制御情報をMN１へ送信してもよい。該MCG障害情報のUE３からSN２及びMN１への送信は、例えば、図３２のステップ３２０２及び３２０３に相当する。また、該MCG障害情報の送信の後に、図２４～２６等に記載のMCG障害の回復に関する手順が行われてもよい。一方、UE３はRRC再接続処理を実行するように通知されている場合、RRC (connection) re-establishment手順を行う。当該通知は、さらに、MCG障害の種類を指定してもよい。つまり、MN１は、UE３が複数のMCG障害の種類のうち特定の１又はそれ以上の種類を検出した場合にMCG障害情報をSRB3でSN２に送信することをUE３に許可してもよい。UE３は、検出したMCG障害の種類に応じて、MCG障害情報をSRB3でSN２に送信するか、RRC再接続処理を実行するかを判定してもよい。

【0168】

MN１は、SN２から受信するSCGの設定情報（e.g., CG-Config message）に含まれるベアラ情報（e.g., scg-RB-Config）を基に、SRB3が確立されるか否かを判定してもよい。これに代えて、SN２は、SRB3が確立されているか否かを示す情報を、XnAP/X2AP messageのIEを用いて、MN１に明示的に通知してもよい。

【0169】

SN２は、どちらの処理（i.e., RRC再接続処理（e.g., rr-Reestablishment）又はSRB3でのSN２へのMCG障害情報の送信（e.g., fast-MCG-recovery、又はMCG-failure-indication））をUE３に実行させるかを決定し、これをMN１に通知してもよい。これに代えて、SN２は、SRB3を使用してMCG障害情報を送信することをUE３に許可するか否かを決定し、結果（許可又は不許可）をMN１に通知してもよい。MN１は、SN２からの当該通知に従い、又は当該通知を基に、UE３に実行させる処理（手順）を示す情報を送信してもよい。

【0170】

＜第１８の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。本実施形態のSN２は、SRB3を介してRRCメッセージをSN２に送信できるよう設定されているUE３がMCG障害（e.g., MCG RLF）を検出した場合に、UE３がRRC再接続処理（RRC (connection) re-establishment手順）又はMCG回復処理（MCG (link) recovery手順）のどちらを行うべきかを示す指示（又はRRC設定情報）を、予めUE３に送信する。ここで、MCG回復処理は、UE３がMCG障害情報（e.g., MCG Failure Information）をSRB3でSN２に送信することを含む。さらに、MCG回復処理は、MCG障害情報を受信したSN２が、当該MCG障害情報又はそれから導出される制御情報をMN１に送信することを含んでもよい。これにより、SN２は、MCG障害が発生したときのUE３の動作（つまり、MCG障害情報の送信又はRRC再接続）を制御できる。

【0171】

幾つかの実装では、SN２は、UE３に実行させる処理（手順）を明示的に示す情報（e.g., rr-Reestablishment、fast-MCG-recovery、又はMCG-failure-indication）を包含するSN RRCメッセージ（e.g., RRC (Connection) Reconfiguration）を、SRB3で、又はMN１を介して、UE３に送信してもよい。MN１を介する送信の場合、当該SN RRCメッセージは、MN１からUE３に送られるMN RRCメッセージに包含される。

【0172】

これに代えて、SN２は、SRB3のRRC設定（e.g., RadioBearerConfig IE）をUE３に送信するときに（又は送信した後に）、SRB3でMCG障害情報を送信することがUE３に許可されるか否か（又はUE３に許可されること）を示す情報をUE３に送信してもよい。例えば、SN２は、当該情報を、UE３に送られるSN RRCメッセージ（e.g., RRC (Connection) Reconfiguration）のベアラ設定情報（e.g., RadioBearerConfig）又はSCG設定情報（e.g., CellGroupConfig）に含めてもよい。当該SN RRCメッセージは、SRB3で送信されてもよいし、MN１を介して送信されてもよい。これに代えて、SN２は当該情報をRANノード間（inter-RAN Node）メッセージ（e.g., CG-Config）でMN１に送信してもよく、MN１は、当該情報を、UE３に送られるMN RRCメッセージ内のSCGの設定情報（e.g., scg-RB-Config、又はnr-RadioBearerConfig）に含めてもよい。当該許可は、さらに、MCG障害の種類を指定してもよい。つまり、SN２は、UE３が複数のMCG障害の種類のうち特定の１又はそれ以上の種類を検出した場合にMCG障害情報をSRB3でSN２に送信することをUE３に許可してもよい。UE３は、検出したMCG障害の種類に応じて、MCG障害情報をSRB3でSN２に送信するか、RRC再接続処理を実行するかを判定してもよい。

【0173】

幾つかの実装では、SN２は、SRB3のRRC設定（e.g., RadioBearerConfig IE）をUE３に送信し（つまり、SRB3を確立するようUE３に指示し）、このことがSRB3でMCG障害情報を送信することがUE３に許可されることをUE３に暗示的に示してもよい。UE３は、SRB3を確立するためのRRC設定を受信した場合、SRB3を確立した後にMCG障害を検出したときにはSRB3でMCG障害情報をSN２に送信するように指示されている（又は許可されている）と考えてもよい。

【0174】

MCG障害情報を送信することをUE３が指示、設定、又は許可されている場合、UE３は、MCG障害の検出に応答して、MCG障害情報をSRB3でSN２に送信する。このとき、SN２は、受信したMCG障害情報又はそれから導出される制御情報をMN１へ送信してもよい。該MCG障害情報のUE３からSN２及びMN１への送信は、例えば、図３２のステップ３２０２及び３２０３に相当する。また、該MCG障害情報の送信の後に、図２４～２６等に記載のMCG障害の回復に関する手順が行われてもよい。一方、RRC再接続処理を実行するようにUE３が指示又は設定されている場合、又はSRB3でMCG障害情報を送信することをUE３が許可されていない場合、UE３はRRC (connection) re-establishment手順を行う。

【0175】

SN２は、UE３がRRC再接続処理又はMCG回復処理のどちらを行うべきかを示す情報を、XnAP/X2AP messageに含まれるIEで明示的にMN１へ送信してもよい。これに代えて、MN１は、SN２から受信するSCGの設定情報（e.g., CG-Config message）を基に、どちらの処理（i.e., RRC再接続処理又はMCG回復処理）がUE３により行われるかを判定してもよい。MN１は、SN２から受信するSCGの設定情報（e.g., CG-Config message）に含まれるベアラ情報（e.g., scg-RB-Config）を基に、SRB３が確立されるか否かを判定してもよい。これに代えて、SN２は、SRB3が確立されているか否かを示す情報を、XnAP/X2AP messageのIEを用いて、MN１に明示的に通知してもよい。

【0176】

続いて以下では、上述の複数の実施形態に係るMN１、SN２及びUE３の構成例について説明する。図４０は、上述の実施形態に係るMN１の構成例を示すブロック図である。SN２の構成も、図４０に示された構成と同様であってもよい。図４０を参照すると、MN１は、Radio Frequencyトランシーバ４００１、ネットワークインターフェース４００３、プロセッサ４００４、及びメモリ４００５を含む。RFトランシーバ４００１は、UE３を含むUEsと通信するためにアナログRF信号処理を行う。RFトランシーバ４００１は、複数のトランシーバを含んでもよい。RFトランシーバ４００１は、アンテナアレイ４００２及びプロセッサ４００４と結合される。RFトランシーバ４００１は、変調シンボルデータをプロセッサ４００４から受信し、送信RF信号を生成し、送信RF信号をアンテナアレイ４００２に供給する。また、RFトランシーバ４００１は、アンテナアレイ４００２によって受信された受信RF信号に基づいてベースバンド受信信号を生成し、これをプロセッサ４００４に供給する。RFトランシーバ４００１は、ビームフォーミングのためのアナログビームフォーマ回路を含んでもよい。アナログビームフォーマ回路は、例えば複数の移相器及び複数の電力増幅器を含む。

【0177】

ネットワークインターフェース４００３は、ネットワークノード（e.g., MN１、並びにコアネットワークの制御ノード及び転送ノード）と通信するために使用される。ネットワークインターフェース４００３は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード（NIC）を含んでもよい。

【0178】

プロセッサ４００４は、無線通信のためのデジタルベースバンド信号処理（データプレーン処理）とコントロールプレーン処理を行う。プロセッサ４００４は、複数のプロセッサを含んでもよい。例えば、プロセッサ４００４は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., Digital Signal Processor（DSP））とコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., Central Processing Unit（CPU）又はMicro Processing Unit（MPU））を含んでもよい。プロセッサ４００４は、ビームフォーミングのためのデジタルビームフォーマ・モジュールを含んでもよい。デジタルビームフォーマ・モジュールは、Multiple Input Multiple Output（MIMO）エンコーダ及びプリコーダを含んでもよい。

【0179】

メモリ４００５は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。揮発性メモリは、例えば、Static Random Access Memory（SRAM）若しくはDynamic RAM（DRAM）又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory（MROM）、Electrically Erasable Programmable ROM（EEPROM）、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。メモリ４００５は、プロセッサ４００４から離れて配置されたストレージを含んでもよい。この場合、プロセッサ４００４は、ネットワークインターフェース４００３又は図示されていないI/Oインタフェースを介してメモリ４００５にアクセスしてもよい。

【0180】

メモリ４００５は、上述の複数の実施形態で説明されたMN１による処理を行うための命令群およびデータを含む１又はそれ以上のソフトウェアモジュール（コンピュータプログラム）４００６を格納してもよい。いくつかの実装において、プロセッサ４００４は、当該ソフトウェアモジュール４００６をメモリ４００５から読み出して実行することで、上述の実施形態で説明されたMN１の処理を行うよう構成されてもよい。

【0181】

なお、MN１がCU（e.g., eNB-CU又はgNB-CU）である場合、MN１は、RFトランシーバ４００１（及びアンテナアレイ４００２）を含まなくてもよい。

【0182】

図４１は、UE３の構成例を示すブロック図である。Radio Frequency（RF）トランシーバ４１０１は、MN１及びSN２と通信するためにアナログRF信号処理を行う。RFトランシーバ４１０１は、複数のトランシーバを含んでもよい。RFトランシーバ４１０１により行われるアナログRF信号処理は、周波数アップコンバージョン、周波数ダウンコンバージョン、及び増幅を含む。RFトランシーバ４１０１は、アンテナアレイ４１０２及びベースバンドプロセッサ４１０３と結合される。RFトランシーバ４１０１は、変調シンボルデータ（又はOFDMシンボルデータ）をベースバンドプロセッサ４１０３から受信し、送信RF信号を生成し、送信RF信号をアンテナアレイ４１０２に供給する。また、RFトランシーバ４１０１は、アンテナアレイ４１０２によって受信された受信ＲＦ信号に基づいてベースバンド受信信号を生成し、これをベースバンドプロセッサ４１０３に供給する。RFトランシーバ４１０１は、ビームフォーミングのためのアナログビームフォーマ回路を含んでもよい。アナログビームフォーマ回路は、例えば複数の移相器及び複数の電力増幅器を含む。

【0183】

ベースバンドプロセッサ４１０３は、無線通信のためのデジタルベースバンド信号処理（データプレーン処理）とコントロールプレーン処理を行う。デジタルベースバンド信号処理は、(a) データ圧縮／復元、(b) データのセグメンテーション／コンカテネーション、(c) 伝送フォーマット（伝送フレーム）の生成／分解、(d) 伝送路符号化／復号化、(e) 変調（シンボルマッピング）／復調、及び(f) Inverse Fast Fourier Transform（IFFT）によるOFDMシンボルデータ（ベースバンドOFDM信号）の生成などを含む。一方、コントロールプレーン処理は、レイヤ１（e.g., 送信電力制御）、レイヤ２（e.g., 無線リソース管理、及びhybrid automatic repeat request（HARQ）処理）、及びレイヤ３（e.g., アタッチ、モビリティ、及び通話管理に関するシグナリング）の通信管理を含む。

【0184】

例えば、ベースバンドプロセッサ４１０３によるデジタルベースバンド信号処理は、Service Data Adaptation Protocol（SDAP）レイヤ、Packet Data Convergence Protocol（PDCP）レイヤ、Radio Link Control（RLC）レイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。また、ベースバンドプロセッサ４１０３によるコントロールプレーン処理は、Non-Access Stratum（NAS）プロトコル、RRCプロトコル、及びMAC CEの処理を含んでもよい。

【0185】

ベースバンドプロセッサ４１０３は、ビームフォーミングのためのMIMOエンコーディング及びプリコーディングを行ってもよい。

【0186】

ベースバンドプロセッサ４１０３は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., DSP）とコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., CPU又はMPU）を含んでもよい。この場合、コントロールプレーン処理を行うプロトコルスタック・プロセッサは、後述するアプリケーションプロセッサ４１０４と共通化されてもよい。

【0187】

アプリケーションプロセッサ４１０４は、CPU、MPU、マイクロプロセッサ、又はプロセッサコアとも呼ばれる。アプリケーションプロセッサ４１０４は、複数のプロセッサ（複数のプロセッサコア）を含んでもよい。アプリケーションプロセッサ４１０４は、メモリ４１０６又は図示されていないメモリから読み出されたシステムソフトウェアプログラム（Operating System（OS））及び様々なアプリケーションプログラム（例えば、通話アプリケーション、WEBブラウザ、メーラ、カメラ操作アプリケーション、音楽再生アプリケーション）を実行することによって、UE３の各種機能を実現する。

【0188】

幾つかの実装において、図４１に破線（４１０５）で示されているように、ベースバンドプロセッサ４１０３及びアプリケーションプロセッサ４１０４は、１つのチップ上に集積されてもよい。言い換えると、ベースバンドプロセッサ４１０３及びアプリケーションプロセッサ４１０４は、１つのSystem on Chip（SoC）デバイス４１０５として実装されてもよい。SoCデバイスは、システムLarge Scale Integration（LSI）またはチップセットと呼ばれることもある。

【0189】

メモリ４１０６は、揮発性メモリ若しくは不揮発性メモリ又はこれらの組合せである。メモリ４１０６は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、SRAM若しくはDRAM又はこれらの組み合わせである。不揮発性メモリは、MROM、EEPROM、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。例えば、メモリ４１０６は、ベースバンドプロセッサ４１０３、アプリケーションプロセッサ４１０４、及びSoC４１０５からアクセス可能な外部メモリデバイスを含んでもよい。メモリ４１０６は、ベースバンドプロセッサ４１０３内、アプリケーションプロセッサ４１０４内、又はSoC４１０５内に集積された内蔵メモリデバイスを含んでもよい。さらに、メモリ４１０６は、Universal Integrated Circuit Card（UICC）内のメモリを含んでもよい。

【0190】

メモリ４１０６は、上述の複数の実施形態で説明されたUE３による処理を行うための命令群およびデータを含む１又はそれ以上のソフトウェアモジュール（コンピュータプログラム）４１０７を格納してもよい。幾つかの実装において、ベースバンドプロセッサ４１０３又はアプリケーションプロセッサ４１０４は、当該ソフトウェアモジュール４１０７をメモリ４１０６から読み出して実行することで、上述の実施形態で図面を用いて説明されたUE３の処理を行うよう構成されてもよい。

【0191】

なお、上述の実施形態で説明されたUE３によって行われるコントロールプレーン処理及び動作は、RFトランシーバ４１０１及びアンテナアレイ４１０２を除く他の要素、すなわちベースバンドプロセッサ４１０３及びアプリケーションプロセッサ４１０４の少なくとも一方とソフトウェアモジュール４１０７を格納したメモリ４１０６とによって実現されることができる。

【0192】

図４０及び図４１を用いて説明したように、上述の実施形態に係るMN１、SN２、及びUE３が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、Compact Disc Read Only Memory（CD-ROM）、CD-R、CD-R/W、半導体メモリ（例えば、マスクROM、Programmable ROM（PROM）、Erasable PROM（EPROM）、フラッシュROM、Random Access Memory（RAM））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

【0193】

＜その他の実施形態＞
上述の実施形態では、Split SRB1の代わりにSplit SRB2が使用されてもよい。

【0194】

上述の実施形態は、SN２がUE３から受信するMCG障害情報（e.g., MCG Failure Information）をMN１に送信するために、RRC TRANSFERメッセージを使用する例を提供した（例えば、ステップ９０２及びステップ３２０３）。これに代えて、SN２は、SN MODIFICATION REQUIREDメッセージを使用してMCG障害情報を送信してもよい。SN２は、UE３から受信するRRCメッセージがMCG障害情報を含んでいることを認識した場合、SN MODIFICATION REQUIREDメッセージを使用してもよい。例えば、SN２は、SRB3でUE３からMCG障害情報を受信した場合、SN MODIFICATION REQUIREDメッセージにMCG障害情報（e.g. MCG Failure Information）を包含し、当該メッセージをMN１へ送信してもよい。あるいは、SN２は、SCG signaling（e.g., MAC CE）でUE３からMCG障害通知を受信した場合、SN MODIFICATION REQUIREDメッセージにMCG障害情報を含むSplit SRBのコンテンツ（e.g., PDCP-C PDU）を包含し、当該メッセージをMN１へ送信してもよい。MN１は、SN２から当該SN MODIFICATION REQUIREDメッセージを受信すると、上述の実施形態におけるMCG障害の回復のための手順を実行（開始）してもよい。

【0195】

上述の実施形態では、SN２は、MCG障害回復の処理を実行するために、SN２内の設定又はリソースの修正又は解放の実行を所定タイミングまで待つ（延期する）。所定タイミングは、SN２が送信するSplit SRB（e.g., PDCP-C PDU）に対するUE３からの送達確認（e.g., HARQ ACK, RLC ARQ ACK）の受信であってもよいし、又はSRB3に対するUE３からの送達確認の受信であってもよい。さらに又はこれに代えて、SN２はSN２内の設定又はリソースの修正又は解放の実行を所定期間だけ待つ（延期する）ようにしてもよい。所定期間は、タイマとして設定されてもよい。当該タイマの値は、MN１からXnAP/X2APメッセージ（e.g., SN MODIFICATION REQUESTメッセージ又はSN RELEASE REQUESTメッセージ）でSN２に通知されてもよいし、予め仕様で規定されてもよい。例えば、SN２は所定期間が満了するまでに、所定タイミング（つまり、その事象（イベント））が検出されなかった場合には、所定期間の満了後にSN２内の設定又はリソースの修正又は解放を実行してもよい。

【0196】

上述の実施形態では、基本的にSN２（SCG）を介したMCG障害の回復（fast MCG recovery）が成功する場合が想定されている。しかしながら、それが失敗する場合も起こりうる。一例では、UE３は、MCG障害情報（e.g. MCG failure information）をSCGで送信した後、SCG障害（e.g., SCG failure）を検出することが起こりうる。このとき、UE３はPCellの再確立のためのRRC再接続処理を実行してもよい。他の例では、SN２は、MCG障害に起因してSCGの修正（又は再設定）が必要とされることを示すXnAP/X2APメッセージ（又は情報）をMN１から受信し、且つMN１からのMN RRCメッセージをUE３へ送信した後に、SCG障害を検出することが起こり得る。既に説明したように、当該XnAP/X2APメッセージ（又は情報）は、MCG障害の表示又はMCG障害の回復の表示を含んでもよい。あるいは、当該XnAP/X2APメッセージ（又は情報）は、MCGの修正（又は変更又は再設定）に関連付けられたSCGの修正（又は再設定）が必要とされることを示してもよい。このとき、SN２は、SCG障害の検出又はMN RRCメッセージの送信の失敗をMN１へXnAP/X2APメッセージで通知してもよい。当該XnAP/X2APメッセージは、例えばRRC TRANSFER FAILUREメッセージ、SN MODIFICATION FAILUREメッセージ、又はMCG MODIFICATION FAILUREメッセージでもよい。

【0197】

上述の実施形態で説明されたMN１、SN２、及びUE３に関する動作及び手順は、SCGで発生した障害（SCG障害）の回復のために利用されてもよい。従来のMR-DCでは、UEはSCG障害（e.g., SCG failure）を検出するとMCGのSRB（e.g., SRB1）でMNへSCG障害情報（SCG Failure Information）を送信する。MNは、当該SCG障害情報を基にSNを解放するか、別のRANノード（e.g., gNB）へSNを変更するか、同じSN内の別のセルへPSCellを変更するかを決定する。このような動作に代えて、MN１、SN２、及びUE３は例えば以下のように動作してもよい。

【0198】

SN２は、SN２とUE３の間の直接的なSRB（i.e. SRB3）を確立し、当該SRB3によって送信されるSN RRCメッセージを、MN１（MCG）を介してUE３へ送信するためのSplit SRB（e.g., SN Split SRB）を確立してもよい。SN Split SRB は、SN RRC messagesのためのSN２とUE３の間のSRBであり、MCG内のRLC bearer（i.e., MCG leg）及びSCG内のRLC bearer（i.e., SCG leg）を備える。SN Split SRB は、MCG及びSCGを介した送信をサポートし、SNによって生成されたRRC Protocol Data Units (PDUs)の複製（duplication）を可能にする。言い換えると、SN Split SRB は、RRC情報を包含するPDCP PDUの複製を可能にする。

【0199】

UE３は、SCG障害を検出するとSCG障害情報（e.g., SCG RLF）をSN Split SRBのMCG leg（i.e. SN RRCメッセージ）でMN１を介してSN２へ送信してもよい。SN２は、当該SCG障害情報をもとに、SN自身の解放、別のRANノードへのSNの変更、又はSN自身の別のセルへPSCellの変更を決定してもよい。そして、SN２は、例えばSN MODIFICATION REQUIREDメッセージ又はSN RELEASE REQUIREDメッセージをMN１へ送信し、SN Modification手順又はSN Release手順を開始（トリガ）してもよい。当該メッセージは、SCG障害の表示又はSCG障害の回復の表示を含んでもよい。MN１は、当該表示を包含するメッセージをSN２から受信すると、当該メッセージに関する処理を優先してもよい。例えば、MN１は、UE３に関するMN（MCG）内の設定又はリソースの修正又は解放を中断又は延期して、当該メッセージに関する処理を優先して実行してもよい。

【0200】

幾つかの実装では、SN２は、UE３にSN split SRBを設定するとき、アップリンクのプライマリ・パス（primary path）がSCGである（e.g., primaryPathのCellGroupがSCGにセットされる）ことを通知してもよい。さらにSN２は、SN split SRBのアップリンクのプライマリ・パスをSCGからMCGに切り替える許可を予めUE３に明示的に又は暗示的に送信してもよい。UE３は、SN split SRBが設定され且つ当該許可を受信しているときのSCG障害（e.g., SCG RLF）の検出に応答して、SCG障害情報をSN split SRBのMCG legを介してSN２に送信してもよい。一方当該許可を受信していない場合、UE３は、MCGでSCG障害情報をMN１に送信してもよい。これにより、SN２は、SCG障害が発生したときのUE３の動作（つまり、MN又はSNへのSCG障害情報の送信）を制御できる。

【0201】

幾つかの実装では、SN２は、SN split SRBを設定する（又は既に設定している）UE３に対して、当該UE３がSCG障害（e.g., SCG RLF）を検出した場合にMCGでのSCG障害情報の送信又はSCG回復処理（SCG (link) recovery手順）のどちらを行うべきかを示す指示（又はRRC設定情報）を、予め送信してもよい。ここで、SCG回復処理は、UE３がSCG障害情報（e.g., SCG Failure Information）をSN split SRBでMN１を介してSN２に送信することを含む。これにより、SN２は、SCG障害が発生したときのUE３の動作（つまり、MN又はSNへのSCG障害情報の送信又はRRC再接続）を制御できる。

【0202】

SN２は、UE３に実行させる処理（手順）を明示的に示す情報を送信してもよい。例えば、SN２は、SCG障害（e.g., SCG RLF）の復旧のための方法を示すRRC情報（e.g., SCG-FailureRecovery IE）をUE３に送信するときに、どちらの処理（i.e., MNへのSCG障害情報の送信又はSN split SRBのMCG legを介したSCG障害情報の送信（e.g., fast-SCG-recovery、又はSCG-failure-indication））が行われるべきかをUE３に通知してもよい。UE３は、SN split SRBでSCG障害情報を送信するように通知されている場合、SCG障害の検出に応答して、SCG障害情報をSN split SRBのMCG legを介してSN２に送信する。一方、UE３はMNへSCG障害情報を送信するように通知されている場合、MN RRCでSCG障害情報の送信を行う。

【0203】

上述の実施形態では、MN１は、修正又は解放すべきSN２内の設定（又はリソース）を明示的にSN２に通知し、SN２がそれに従ってもよい。例えば、MN１は、SN２で使用される新しいセキュリティ鍵（e.g. S-KgNB）をSN２に通知するために、XnAP/X2APメッセージのIEを用いてもよい。あるいは、MN１は、SN２が従うべき設定（e.g., configRestrictInfo）をSN２に通知するために、XnAP/X2APメッセージに包含されるRRCコンテナ（e.g., CG-ConfigInfo message）を用いてもよい。

【0204】

これに代えて、上述の実施形態では、MN１がMN１内の設定（又はリソース）の修正又は解放の内容をSN２に示し、SN２がこれに基づいてSN２内の設定（又はリソース）の修正又は解放が必要であるか否かを判定してもよい。SN２は、SN２内の設定（又はリソース）を必要に応じて修正又は解放してもよい。例えば、MN１は、MN１内の設定（又はリソース）の修正又は解放の内容をSN２に示すためにXnAP/X2APメッセージのIEを用いてもよい。あるいは、MN１は、MN１が修正又は解放したMN１内の設定（e.g., measConfigMN）をSN２に通知するために、XnAP/X2APメッセージに包含されるRRCコンテナ（e.g., CG-ConfigInfo message）を用いてもよい。

【0205】

上述した実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。当該技術思想は、上述した実施形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。

【0206】

例えば、上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。

【0207】

（付記１）
マスターノードであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、
前記マスターノードにより提供されるMaster Cell Group（MCG）及びセカンダリノードにより提供されるSecondary Cell Group（SCG）を使用することを無線端末に可能にするdual connectivityをサポートし、
前記dual connectivityに関する前記セカンダリノード内の設定又はリソースの修正又は解放に関連する第１のメッセージを前記セカンダリノードに送るよう構成され、
前記第１のメッセージは、前記修正又は前記解放が前記MCGの障害（failure）又は前記MCGの前記障害の回復に関連することを明示的又は暗示的に示す、
マスターノード。

【0208】

（付記２）
前記少なくとも１つのプロセッサは、前記MCGの前記障害の回復のためのRadio Resource Control（RRC）メッセージを、前記セカンダリノードを介して前記無線端末に送信するよう構成される、
付記１に記載のマスターノード。

【0209】

（付記３）
前記RRCメッセージは、前記セカンダリノードと前記無線端末の間に直接的に設定されたシグナリング無線ベアラを介して、前記無線端末に送信される、
付記２に記載のマスターノード。

【0210】

（付記４）
前記第１のメッセージは、前記セカンダリノードを介する前記RRCメッセージの送信に関連付けられた所定の条件が成立するまで、前記設定又は前記リソースの修正又は解放を延期することを前記セカンダリノードに引き起こす、
付記２又は３に記載のマスターノード。

【0211】

（付記５）
前記所定の条件は、前記セカンダリノードが前記無線端末への前記RRCメッセージの送信を完了したことを含む、
付記４に記載のマスターノード。

【0212】

（付記６）
前記所定の条件は、前記RRCメッセージの受信に応答して前記無線端末により送信される応答を前記セカンダリノードが受信したことを含む、
付記４に記載のマスターノード。

【0213】

（付記７）
前記少なくとも１つのプロセッサは、前記RRCメッセージを前記無線端末に配信するために前記RRCメッセージを運ぶ第２のメッセージを前記セカンダリノードに送るよう構成され、
前記第２のメッセージは、前記RRCメッセージの配信が前記MCGの前記障害又は前記障害の回復に関連することを明示的又は暗示的に示す、
付記２～６のいずれか１項に記載のマスターノード。

【0214】

（付記８）
前記少なくとも１つのプロセッサは、前記RRCメッセージを前記無線端末に配信するために前記RRCメッセージを運ぶ第２のメッセージを前記セカンダリノードに送るよう構成され、
前記第２のメッセージは、前記RRCメッセージの配信が必ず行われるべきであることを前記セカンダリノードに示す、
付記２～６のいずれか１項に記載のマスターノード。

【0215】

（付記９）
前記第１のメッセージは、前記設定又は前記リソースの修正を要求し、
前記設定又は前記リソースは、前記セカンダリノードと前記無線端末の間の直接的な無線ベアラに適用されるセキュリティ鍵を含む、
付記１～８のいずれか１項に記載のマスターノード。

【0216】

（付記１０）
前記第１のメッセージは、前記設定又は前記リソースの解放を要求し、
前記設定又は前記リソースは、前記無線端末に関連付けられた前記マスターノードと前記セカンダリノードの間のシグナリング・コネクションのリソースを含む、
付記１～８のいずれか１項に記載のマスターノード。

【0217】

（付記１１）
前記少なくとも１つのプロセッサは、前記無線端末が前記MCGの前記障害を検出した場合に前記無線端末がRRCコネクションの再確立手順又はMCG回復手順のどちらを行うべきかを、前記無線端末に指示するよう構成され、
前記MCG回復手順は、前記MCGの前記障害の情報を前記無線端末から前記マスターノードに、前記セカンダリノードと前記無線端末の間に直接的に設定されたシグナリング無線ベアラを介して送信することを含む、
付記１～１０のいずれか１項に記載のマスターノード。

【0218】

（付記１２）
セカンダリノードであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、
マスターノードにより提供されるMaster Cell Group（MCG）及び前記セカンダリノードにより提供されるSecondary Cell Group（SCG）を使用することを無線端末に可能にするdual connectivityをサポートし、
前記dual connectivityに関する前記セカンダリノード内の設定又はリソースの修正又は解放に関連する第１のメッセージを前記マスターノードから受信し、
前記MCGの障害（failure）の回復に関連し且つ前記マスターノードから送られるRadio Resource Control（RRC）メッセージを、前記セカンダリノードと前記無線端末の間に直接的に設定されたシグナリング無線ベアラを介して、前記無線端末に送信するよう構成され、
前記第１のメッセージは、前記修正又は前記解放が前記MCGの前記障害又は前記MCGの前記障害の回復に関連することを明示的又は暗示的に示す、
セカンダリノード。

【0219】

（付記１３）
前記少なくとも１つのプロセッサは、前記第１のメッセージの受信に応答して、前記RRCメッセージの前記無線端末への送信に関連付けられた所定の条件が成立するまで、前記設定又は前記リソースの修正又は解放を延期するよう構成される、
付記１２に記載のセカンダリノード。

【0220】

（付記１４）
前記所定の条件は、前記セカンダリノードが前記無線端末への前記RRCメッセージの送信を完了したことを含む、
付記１３に記載のセカンダリノード。

【0221】

（付記１５）
前記所定の条件は、前記RRCメッセージの受信に応答して前記無線端末により送信される応答を前記セカンダリノードが受信したことを含む、
付記１３に記載のセカンダリノード。

【0222】

（付記１６）
前記少なくとも１つのプロセッサは、前記RRCメッセージを運ぶ第２のメッセージを前記マスターノードから受信し、前記RRCメッセージを前記無線端末に前記SCGを介して送信するよう構成される、
付記１２～１５のいずれか１項に記載のセカンダリノード。

【0223】

（付記１７）
前記第２のメッセージは、前記RRCメッセージの配信が前記MCGの前記障害又は前記障害の回復に関連することを明示的又は暗示的に示す、
付記１６に記載のセカンダリノード。

【0224】

（付記１８）
前記第２のメッセージは、前記RRCメッセージの配信が必ず行われるべきであることを前記セカンダリノードに示す、
付記１６又は１７に記載のセカンダリノード。

【0225】

（付記１９）
前記第１のメッセージは、前記設定又は前記リソースの修正を要求し、
前記設定又は前記リソースは、前記セカンダリノードと前記無線端末の間の直接的な無線ベアラに適用されるセキュリティ鍵を含む、
付記１２～１８のいずれか１項に記載のセカンダリノード。

【0226】

（付記２０）
前記第１のメッセージは、前記設定又は前記リソースの解放を要求し、
前記設定又は前記リソースは、前記無線端末に関連付けられた前記マスターノードと前記セカンダリノードの間のシグナリング・コネクションのリソースを含む、
付記１２～１８のいずれか１項に記載のセカンダリノード。

【0227】

（付記２１）
前記少なくとも１つのプロセッサは、前記無線端末が前記MCGの前記障害を検出した場合に前記無線端末がRRCコネクションの再確立手順又はMCG回復手順のどちらを行うべきかを、前記無線端末に指示するよう構成され、
前記MCG回復手順は、前記MCGの前記障害の情報を前記無線端末から前記マスターノードに、前記セカンダリノードと前記無線端末の間に直接的に設定されたシグナリング無線ベアラを介して送信することを含む、
付記１２～２０のいずれか１項に記載のセカンダリノード。

【0228】

（付記２２）
マスターノードにより行われる方法であって、
前記マスターノードにより提供されるMaster Cell Group（MCG）及びセカンダリノードにより提供されるSecondary Cell Group（SCG）を使用するdual connectivityを無線端末に可能にするために前記マスターノードを制御すること、及び
前記dual connectivityに関する前記セカンダリノード内の設定又はリソースの修正又は解放に関連する第１のメッセージを前記セカンダリノードに送ること、
を備え、
前記第１のメッセージは、前記修正又は前記解放が前記MCGの障害（failure）又は前記MCGの前記障害の回復に関連することを明示的又は暗示的に示す、
方法。

【0229】

（付記２３）
セカンダリノードにより行われる方法であって、
マスターノードにより提供されるMaster Cell Group（MCG）及び前記セカンダリノードにより提供されるSecondary Cell Group（SCG）を使用するdual connectivityを無線端末に可能にするために前記セカンダリノードを制御すること、
前記dual connectivityに関する前記セカンダリノード内の設定又はリソースの修正又は解放に関連する第１のメッセージを前記マスターノードから受信すること、及び
前記MCGの障害（failure）の回復に関連し且つ前記マスターノードから送られるRadio Resource Control（RRC）メッセージを、前記セカンダリノードと前記無線端末の間に直接的に設定されたシグナリング無線ベアラを介して、前記無線端末に送信すること、
を備え、
前記第１のメッセージは、前記修正又は前記解放が前記MCGの前記障害又は前記MCGの前記障害の回復に関連することを明示的又は暗示的に示す、
方法。

【0230】

（付記２４）
マスターノードのための方法をコンピュータに行わせるためのプログラムであって、
前記方法は、
前記マスターノードにより提供されるMaster Cell Group（MCG）及びセカンダリノードにより提供されるSecondary Cell Group（SCG）を使用するdual connectivityを無線端末に可能にするために前記マスターノードを制御すること、及び
前記dual connectivityに関する前記セカンダリノード内の設定又はリソースの修正又は解放に関連するする第１のメッセージを前記セカンダリノードに送るよう前記マスターノードを制御すること、
を備え、
前記第１のメッセージは、前記修正又は前記解放が前記MCGの障害（failure）又は前記MCGの前記障害の回復に関連することを明示的又は暗示的に示す、
プログラム。

【0231】

（付記２５）
セカンダリノードのための方法をコンピュータに行わせるためのプログラムであって、
前記方法は、
マスターノードにより提供されるMaster Cell Group（MCG）及び前記セカンダリノードにより提供されるSecondary Cell Group（SCG）を使用するdual connectivityを無線端末に可能にするために前記セカンダリノードを制御すること、
前記dual connectivityに関する前記セカンダリノード内の設定又はリソースの修正又は解放に関連する第１のメッセージを前記マスターノードから受信するよう前記セカンダリノードを制御すること、及び
前記MCGの障害（failure）の回復に関連し且つ前記マスターノードから送られるRadio Resource Control（RRC）メッセージを、前記セカンダリノードと前記無線端末の間に直接的に設定されたシグナリング無線ベアラを介して、前記無線端末に送信するよう前記セカンダリノードを制御すること、
を備え、
前記第１のメッセージは、前記修正又は前記解放が前記MCGの前記障害又は前記MCGの前記障害の回復に関連することを明示的又は暗示的に示す、
プログラム。

【0232】

（付記Ｂ１）
無線端末であって、
少なくとも１つの無線トランシーバと、
前記少なくとも１つの無線トランシーバに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、
マスターノードにより提供されるMaster Cell Group（MCG）及びセカンダリノードにより提供されるSecondary Cell Group（SCG）を使用するdual connectivityをサポートし、
前記マスターノードと前記無線端末の間に設定され且つ前記MCG及び前記SCGの両方を介した送信をサポートするスプリット・シグナリング無線ベアラのアップリンク・プライマリ・パスを前記MCGから前記SCGに切り替える許可を、前記マスターノードから受信するよう構成され、
前記スプリット・シグナリング無線ベアラから設定され且つ前記許可を受信しているときの前記MCGの障害（failure）の検出に応答して、前記MCGの障害の情報を、前記スプリット・シグナリング無線ベアラのSCG部分を介して前記マスターノードに送信するよう構成される、
無線端末。

【0233】

（付記Ｂ２）
前記少なくとも１つのプロセッサは、前記スプリット・シグナリング無線ベアラから設定され且つ前記許可を受信していないときの前記MCGの障害（failure）の検出に応答して、Radio Resource Control（RRC）コネクションの再確立手順を行うよう構成される、
付記Ｂ１に記載の無線端末。

【0234】

（付記Ｂ３）
マスターノードであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、
前記マスターノードにより提供されるMaster Cell Group（MCG）及びセカンダリノードにより提供されるSecondary Cell Group（SCG）を使用することを無線端末に可能にするdual connectivityをサポートし、
前記マスターノードと前記無線端末の間に設定され且つ前記MCG及び前記SCGの両方を介した送信をサポートするスプリット・シグナリング無線ベアラのアップリンク・プライマリ・パスを前記MCGから前記SCGに切り替える許可を、前記無線端末に送信するよう構成される、
マスターノード。

【0235】

（付記Ｃ１）
マスターノードであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、
前記マスターノードにより提供されるMaster Cell Group（MCG）及びセカンダリノードにより提供されるSecondary Cell Group（SCG）を使用することを無線端末に可能にするdual connectivityをサポートし、
前記無線端末が前記セカンダリノードを介してRRCメッセージを前記マスターノードに送信できるよう設定されているときに前記無線端末が前記MCGの障害（failure）を検出した場合に前記無線端末がRadio Resource Control（RRC）コネクションの再確立手順又はMCG回復手順のどちらを行うべきかを、前記無線端末に指示するよう構成され、
前記MCG回復手順は、前記MCGの障害の情報を前記無線端末から前記マスターノードに前記セカンダリノードを介して送信することを含む、
マスターノード。

【0236】

（付記Ｃ２）
無線端末であって、
少なくとも１つの無線トランシーバと、
前記少なくとも１つの無線トランシーバに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、
マスターノードにより提供されるMaster Cell Group（MCG）及びセカンダリノードにより提供されるSecondary Cell Group（SCG）を使用するdual connectivityをサポートし、
前記無線端末が前記セカンダリノードを介してRRCメッセージを前記マスターノードに送信できるよう設定されているときに前記無線端末が前記MCGの障害（failure）を検出した場合に前記無線端末がRadio Resource Control（RRC）コネクションの再確立手順又はMCG回復手順のどちらを行うべきかを示す指示を、前記マスターノードから受信するよう構成され、
前記MCG回復手順は、前記MCGの障害の情報を前記無線端末から前記マスターノードに前記セカンダリノードを介して送信することを含む、
無線端末。

【0237】

この出願は、２０１９年７月２９日に出願された日本出願特願２０１９－１３９２５１を基礎とする優先権を主張し、その開示の全てをここに取り込む。

【符号の説明】

【0238】

１ マスターノード（Master Node（MN））
２ セカンダリノード（Secondary Node（SN））
３ User Equipment（UE）
４ ターゲットMN
５ コアネットワーク
６ ターゲットgNB
４００４ プロセッサ
４００５ メモリ
４００６ モジュール（modules）
４１０３ ベースバンドプロセッサ
４１０４ アプリケーションプロセッサ
４１０６ メモリ
４１０７ モジュール（modules）

【図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】