JP2023011033A - Ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ及びＵｓｅｒ ｅｑｕｉｐｍｅｎｔのための方法 - Google Patents

Abstract

【課題】条件付きハンドオーバに適した無線端末の動作を提供する。【解決手段】ｇＮＢ－ＣＵ内でのＳｏｕｒｃｅ ｇＮＢ－ＤＵからＴａｒｇｅｔ ｇＮＢ－ＤＵへの条件つきハンドオーバにおいて、Ｕｓｅｒ ｅｑｕｉｐｍｅｎｔは、複数の条件付きハンドオーバ候補セルの１つであるターゲットセルへのアクセスが完了した場合に、当該ターゲットセルを除く複数の条件付きハンドオーバ候補ターゲットセルのリソースを自律的に解放する。【選択図】図１

Description

本開示は、無線通信システムに関し、特に無線端末のモビリティに関する。

非特許文献１及び２は、3GPP（登録商標）で議論されている条件付きハンドオーバ（conditional handover（CHO））について開示している。CHOのための幾つかの実装では、ソース無線アクセスネットワーク（radio access network（RAN））ノード（e.g., eNodeB（eNB））がハンドオーバ実行の条件（e.g., 閾値）を含むハンドオーバコマンドを無線端末（e.g., User Equipment（UE））に送信する。無線端末は、ハンドオーバコマンドの受信後もソースRANノードとのコネクションを維持し、ハンドオーバコマンドにより設定された条件（configured condition）が成立するとすぐにターゲットRANノードへのアクセスを開始する。すなわち、条件付きハンドオーバ（CHO）は、無線端末が、ハンドオーバコマンドの受信に応答してではなく、ハンドオーバコマンドにより設定された条件の成立に応答してターゲットセルへのアクセスを開始する点で、既存のハンドオーバと異なる。

CHOは、早いイベント・トリガリング（つまり、無線端末による測定報告をトリガーする閾値を下げること）によって、UEへのハンドオーバコマンドのデリバリーの信頼性（reliability）を高めることができる。これにより、CHOは、ハンドオーバ失敗率（handover failure rate）を低減できる。

なお、CHOでは、複数の候補ターゲットセルの設定が無線端末に送られてもよい。候補ターゲットセルは、潜在的（potential）ターゲットセルと呼ばれてもよい。例えば、無線端末は、複数の候補ターゲットセルの設定とCHO実行閾値とを含むハンドオーバコマンドをソースRANノード（e.g., eNB）から受信する。そして、無線端末は、設定された複数の候補ターゲットセルの測定を行い（又は開始し）、いずれかの候補ターゲットセルでの測定がCHO実行閾値を満たす場合に当該候補セルへのアクセス（e.g. ランダムアクセス）を開始する。

Intel Corporation, "Discussion of conditional handover", R2-1816691, 3GPP TSG RAN WG2 Meeting #104, Spokane, WA, USA, November 12-16, 2018 MediaTek Inc., "Conditional Handover Procedures", R2-1816959, 3GPP TSG RAN WG2 Meeting #104, Spokane, WA, USA, November 12-16, 2018

発明者等は、条件付きハンドオーバを含む条件付きモビリティをcloud RAN（C-RAN）配置（deployment）に適用することを検討し、様々な課題を見出した。C-RANでは、基地局（e.g., eNB、又はNR gNodeB（gNB））は、Central Unit（CU）と１又はそれ以上のDistributed Units（DUs）から構成される。C-RAN は、Centralized RANと呼ばれることもあるし、CU-DU split architectureと呼ばれることもある。

例えば、条件付きモビリティ（e.g., 条件付きハンドオーバ）がCU-DU split architectureに適用される場合に、条件付きモビリティの実行条件の成立（又は条件付きモビリティの開始）をCUがどのようにして知るのかが明確でない。

本明細書に開示される実施形態が達成しようとする目的の１つは、条件付きモビリティの実行条件の成立（又は条件付きモビリティの開始）を知ることをCentral Unit（CU）に可能にすることに寄与する装置、方法、及びプログラムを提供することである。なお、この目的は、本明細書に開示される複数の実施形態が達成しようとする複数の目的の１つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。

第１の態様では、基地局の分散ユニットは、少なくとも１つのメモリ及び前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサを含む。前記少なくとも１つのプロセッサは、前記分散ユニットによって提供される第１のセルから第２のセルへの無線端末の条件付きモビリティの開始を検出したことに応答して、第１のメッセージを前記基地局の中央ユニットに送るよう構成される。

第２の態様では、基地局の分散ユニットのための方法は、前記分散ユニットによって提供される第１のセルから第２のセルへの無線端末の条件付きモビリティの開始を検出したことに応答して、第１のメッセージを前記基地局の中央ユニットに送ることを含む。

第３の態様では、基地局の中央ユニットは、少なくとも１つのメモリ及び前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサを含む。前記少なくとも１つのプロセッサは、前記基地局の分散ユニットによって提供される第１のセルから第２のセルへの無線端末の条件付きモビリティを制御し、前記分散ユニットが前記条件付きモビリティの開始を検出したことに応答して送信する第１のメッセージを受信するよう構成される。

第４の態様では、基地局の中央ユニットのための方法は、前記基地局の分散ユニットによって提供される第１のセルから第２のセルへの無線端末の条件付きモビリティを制御すること、及び前記分散ユニットが前記条件付きモビリティの開始を検出したことに応答して送信する第１のメッセージを受信することを含む。

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

上述の態様によれば、条件付きモビリティの実行条件の成立（又は条件付きモビリティの開始）を知ることをCentral Unit（CU）に可能にすることに寄与する装置、方法、及びプログラムを提供できる。

第１の実施形態に係る無線通信ネットワークの構成例を示す図である。 第１の実施形態に係る無線通信ネットワークの構成例を示す図である。 第１の実施形態に係る分散ユニットによって行われる処理の一例を示すフローチャートである。 第１の実施形態に係るシグナリングの一例を示すシーケンス図である。 第２の実施形態に係る分散ユニットによって行われる処理の一例を示すフローチャートである。 第３の実施形態に係るシグナリングの一例を示すシーケンス図である。 第３の実施形態に係るシグナリングの一例を示すシーケンス図である。 第４の実施形態に係るシグナリングの一例を示すシーケンス図である。 第４の実施形態に係るシグナリングの一例を示すシーケンス図である。 第５の実施形態に係るシグナリングの一例を示すシーケンス図である。 第５の実施形態に係るシグナリングの一例を示すシーケンス図である。 第６の実施形態に係るシグナリングの一例を示すシーケンス図である。 第６の実施形態に係るシグナリングの一例を示すシーケンス図である。 第７の実施形態に係るシグナリングの一例を示すシーケンス図である。 第８の実施形態に係るシグナリングの一例を示すシーケンス図である。 第９の実施形態に係るDOWNLINK DATA DELIVERY STATUSフレームのフォーマットの一例を示す図である。 幾つかの実施形態に係る中央ノード（e.g., gNB-CU）の構成例を示すブロック図である。 幾つかの実施形態に係る分散ノード（e.g., gNB-DU）の構成例を示すブロック図である。 幾つかの実施形態に係る無線端末の構成例を示すブロック図である。

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

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

以下に示される複数の実施形態は、3GPP Long Term Evolution (LTE)システム及び第5世代移動通信システム（5G system）を主な対象として説明される。しかしながら、これらの実施形態は、無線端末のモビリティ（e.g., ハンドオーバ）をサポートする他の無線通信システムに適用されてもよい。なお、本明細書で使用される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とも呼ばれる。

＜第１の実施形態＞
図１は、本実施形態に係る無線通信ネットワークの構成例を示している。本実施形態に係る無線通信ネットワークは、Central Unit（CU）１、及び１又はそれ以上のDistributed Units（DUs）２を含む。CU１及び１又はそれ以上のDUs２は、無線アクセスネットワーク（Radio Access Network（RAN））に配置される。CU１及び１又はそれ以上のDUs２は、基地局（e.g., LTE eNB、又はgNB）として動作する。CU１及び各DU２の間はインタフェース１０１によって接続される。UE３は、少なくとも１つのエアインタフェース１０２を介して、少なくとも１つのDU２に接続される。

CU１及び１又はそれ以上のDUs２は、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であってもよい。

CU１は、gNBのRadio Resource Control（RRC）、Service Data Adaptation Protocol（SDAP）、及びPacket Data Convergence Protocol（PDCP）protocols（又はgNBのRRC及びPDCP protocols）をホストする論理ノードであってもよい。DU２は、gNBのRadio Link Control（RLC）、Medium Access Control（MAC）、及びPhysical（PHY）layersをホストする論理ノードであってもよい。CU１がgNB-CUでありDUs２がgNB-DUsであるなら、インタフェース１０１はF1インタフェースであってもよい。

図２に示されるように、CU１は、Control Plane （CP）Unit（e.g., gNB-CU-CP）１１及び１又はそれ以上のUser Plane（UP）Unit（e.g., gNB-CU-UP）１２を含んでもよい。この場合、CU-CP１１は、コントロールプレーン・インタフェース２０１（e.g., E1インタフェース）を介してCU-UP１２に接続される。さらに、CU-CP１１は、コントロールプレーン・インタフェース２０２（e.g., F1-Cインタフェース）を介して各DU２に接続される。CU-UP１２は、ユーザプレーン・インタフェース２０３（e.g., F1-Uインタフェース）を介して各DU２に接続される。

図３は、本実施形態のDU２によって行われる処理の一例を示している。ステップ３０１では、DU２は、当該DU２によって提供されるセル（第１のセル）から他のセル（第２のセル）へのUE３の条件付きモビリティの開始を検出する。ここで、条件付きモビリティは、条件付きハンドオーバであってもよい。条件付きハンドオーバは、intra-CU intra-DUハンドオーバであってもよいし、intra-CU inter-DUハンドオーバであってもよいし、inter-CUハンドオーバであってもよい。したがって、intra-CU intra-DUハンドオーバの場合、第２のセル（ターゲットセル）は、第１のセル（ソースセル）と同じDU２によって提供されてもよい。intra-CU inter-DUハンドオーバの場合、第２のセル（ターゲットセル）は、第１のセル（ソースセル）を提供するDU２とは異なるがこれと同じCU１に接続された他のDU２によって提供されてもよい。inter-CUハンドオーバの場合、第２のセル（ターゲットセル）は、他のRANノード（e.g., 第１のセル（ソースセル）を提供するDU２とは異なるCU１に接続された他のDU）により提供されてもよい。

条件付きハンドオーバと同様の動作は、他の様々なモビリティ・シナリオにも適用されることができる。上述のように、条件付きハンドオーバ（CHO）では、UE３が、ハンドオーバコマンド（又は指示）の受信に応答してではなく、設定された条件の成立に応答してターゲットセルへのアクセス（e.g. ランダムアクセス）を開始する。CHOの実行条件は、例えば、閾値及び対応するtime-to-trigger（TTT）を含む。これに代えて、CHOの実行条件は、ネットワークからの明示的な実行指示（e.g., 所定のシグナリング）の受信であってもよい。この場合、当該実行指示の受信に使用される設定（e.g., 無線パラメータ）のUE３による受信は、CHOの実行条件が当該実行指示の受信であることを、UE３に暗示的に示してもよい。言い換えると、UE３は当該設定（e.g., 無線パラメータ）を受信した場合、それに関連付けられたCHOの実行条件が当該実行指示（e.g., 所定のシグナリング）の受信であると判定（又は理解）してもよい。

これと同様に、様々な条件付きモビリティでは、UE３が、モビリティ・コマンド（e.g., RRC Recofiguration for mobility）の受信に応答してではなく、モビリティ・コマンドにより設定された条件（e.g., 閾値及びTTT）の成立に応答して他のセル（第２のセル、ターゲットセル）へのアクセスを開始する。条件付きハンドオーバ（CHO）と同様に、他の条件付きモビリティ（e.g., PSCell change）に対しても、ネットワークからの明示的な実行指示（e.g., 所定のシグナリング）の受信を当該条件付きモビリティの実行条件とすることもできる。さらに、上述のCHOに対する説明は、その他の条件付きモビリティにも適用されることができる。

このような条件付きモビリティは、例えば、Dual Connectivity（DC）でのマスターセルグループ（Master Cell Group（MCG））のプライマリセルの変更（Primary Cell (PCell) change）でもよいし、DCでのマスターノード間（inter-Master Node (MN)）ハンドオーバでもよい。さらに又はこれに代えて、条件付きモビリティは、DCでのセカンダリノード変更（Secondary Node (SN) change）でもよいし、DCでのセカンダリセルグループ（Secondary Cell Group（SCG））のプライマリセルの変更（つまりプライマリSCGセル変更（Primary SCG Cell (PSCell) change））でもよい。PSCellは、SCGのSpecial Cell（SpCell）である。UE３は、ハンドオーバ手順（又はReconfiguration with Sync手順）を行うときに、PSCellにランダムアクセスを行う。すなわち、条件付きモビリティは、様々なinter-MN mobility scenarios、intra-MN mobility senarios、 inter-SN mobility scenarios、及びintra-SN mobility scenariosを含む。

DCは、Multi-Radio Dual Connectivity (MR-DC)であってもよい。MR-DCは、Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (E-UTRA)-NR Dual Connectivit (EN-DC)、NR-E-UTRA DC（NE-DC）、NG-RAN EN-DC（NGEN-DC）、及びNR-NR DC（NR DC）を含む。

条件付きPCell change又は条件付きinter-MN handoverは、MN initiated SN changeを伴ってもよい。

条件付きPSCell changeは、Inter-gNB-DU Mobility using MCG SRBであってもよい。言い換えると、DU間でのPSCell changeのためのUEとCU（つまり、セカンダリノード（Secondary Node（SN））との間のRRCシグナリングは、マスターノード（Master Node（MN））によって提供されるMaster Cell Group（MCG）のシグナリング無線ベアラ（Signalling Radio Bearer（SRB））（e.g., SRB1）を介して行われてもよい。

条件付きPSCell changeは、Inter-gNB-DU Mobility using SCG SRBであってもよい。言い換えると、DU間でのPSCell changeのためのUEとCU（つまり、セカンダリノード（Secondary Node（SN））との間のRRCシグナリングは、Secondary Cell Group（SCG）のSRB（e.g., SRB3）を介して行われてもよい。

条件付きPSCell changeは、MN initiated SN change又はSN initiated SN changeであってもよい。言い換えると、SN間（e.g., 異なるSNのCU間）でのPSCell changeのためのUEとターゲットSN（e.g., ターゲットCU）との間のRRCシグナリングは、MCGのSRB（e.g., SRB1）を介して行われてもよい。

条件付きIntra-CU PSCell Changeは、条件つきSN Modificationと呼ぶこともできる。Intra-CU PSCell Changeは、同一のSN内でのSCGの設定変更の一例である。このような同一のSN内でのSCGの設定変更は、SN initiated SN Modification with (or without) MN involvement手順を使用する。

PSCell Change手順は、Reconfiguration with sync手順を伴う手順の一例である。このことから、条件付きPSCell Changeは、条件付きReconfiguration with sync（for PSCell change）と呼ぶこともできる。

幾つかの実装では、DU２は、条件付きモビリティの表示（indication）（e.g., measurement report）をUE３から受信したことによって条件付きモビリティの開始（又は実行）を検出してもよい。これに代えて、DU２は、条件付きモビリティの開始（又は実行）の条件の成立を自律的に判定し、これにより条件付きモビリティの開始（又は実行）を自律的に検出してもよい。

ステップ３０２では、DU２は、条件付きモビリティの開始の検出に応答して、当該DU２が関連付けられているCU１に所定のメッセージを送信する。したがって、当該所定のメッセージは、UE３による条件付きモビリティの開始（又は実行）に関連付けられる。当該所定のメッセージは、これに限定されないが例えば、条件付きモビリティの開始を明示してもよい。

図４は、本実施形態に係るシグナリングの一例を示している。ステップ４０１では、DU２は、CU１に、条件付きモビリティの開始に関連付けられた所定のメッセージ（e.g., F1APメッセージ）を送信する。

以上の説明から理解されるように、本実施形態では、DU２は、条件付きモビリティの開始の検出に応答して、当該DU２が関連付けられているCU１に所定のメッセージを送信する。これにより、CU１は、条件付きモビリティの開始を知ることができる。

幾つかの条件付きモビリティ・シナリオ（e.g., Intra-CU Inter-DU ハンドオーバ、及びIntra-CU Inter-DU PSCell Change）では、CU１は、条件付きモビリティの開始（又は実行）の直前までソースDU２を介してUE３のためのデータ伝送（ダウンリンク、又はアップリンク、又は両方）を継続できることが好ましいかもしれない。本実施形態で説明された動作によれば、CU１は、ソースDU２からの所定のメッセージの受信によって、条件付きモビリティの開始（又は実行）を知ることができる。したがって、例えば、CU１は、所定のメッセージを受信するまでソースDU２を介してUE３のためのデータ伝送（ダウンリンク、又はアップリンク、又は両方）を継続するよう動作してもよい。

なお、幾つかの実装では、上述の所定のメッセージは、DU２からCU１に送られる既存のメッセージ又はデータと共通であってもよい。例えば、所定のメッセージは、UE３に関するUEコンテキストの変更のためのシグナリング手順において送信されるメッセージ（e.g., F1APメッセージ）であってもよい。より具体的には、当該所定のメッセージは、UE Context Modification手順で送信されるUE CONTEXT MODIFICATION RESPONSEメッセージであってもよい。

所定のメッセージは、UE３へ送信されていないダウンリンクデータを示すためにCU１に送信されるメッセージ（又はフレーム、又はProtocol Data Unit（PDU））であってもよい。より具体的には、当該所定のメッセージは、DOWNLINK DATA DELIVERY STATUS（DDDS）フレームであってもよい。

これに代えて、幾つかの実装では、上述の所定のメッセージは、条件付きモビリティの開始を示すために新規に規定されたメッセージ又はデータ（e.g., F1APメッセージ）であってもよい。例えば、ソースDU２は、UE CONTEXT MODIFICATION RESPONSEメッセージをCU１に送り、さらにDDDSフレームをCU１に送り、その後に、条件付きモビリティの開始を示すために新規に規定されたメッセージ又はデータをさらにCU１に送信してもよい。ソースDU２は、新規メッセージ又はデータをCU１に送信するとき、再度DDDSフレームをCU１に送ってもよい。

＜第２の実施形態＞
本実施形態は、条件付きモビリティのために改良されたDUの動作を提供する。本実施形態に係る無線通信ネットワークの構成例は、図１及び図２に示された例と同様であってもよい。

図５は、本実施形態のDU２によって行われる処理の一例を示している。ステップ５０１では、DU２は、UE３の計画されている（planned）モビリティが条件付きモビリティであるかを判定する。DU２は、CU１から受信した制御メッセージが条件付きモビリティに関連付けられた情報要素を含むか否かに基づいて、UE３の計画されているモビリティが条件付きモビリティであるかを判定してもよい。これに代えて、DU２は、CU１から受信した制御メッセージに包含されている情報要素が条件付きモビリティ（又は条件付きモビリティがUE３に計画されていること）を示すか否かに基づいて、UE３の計画されているモビリティが条件付きモビリティであるかを判定してもよい。

当該制御メッセージ（又はこれに包含される情報要素）は、UE３の計画されているモビリティが条件付きモビリティであることを明示的に示してもよいし暗示的に示してもよい。当該情報要素は、例えば、条件付きモビリティの開始（又は実行）の条件を示す情報要素であってもよい。当該情報要素は、条件付きモビリティを示す何らかの表示（例えば、条件付きモビリティ情報要素（IE）又は条件付きモビリティ・フラグ（ビット））であってもよい。

幾つかの実装では、当該制御メッセージは、UE３に関するUEコンテキストの変更のためのシグナリング手順において送信されるメッセージ（e.g., F1APメッセージ）であってもよい。より具体的には、当該所定のメッセージは、UE Context Modification手順で送信されるUE CONTEXT MODIFICATION REQUESTメッセージであってもよい。

ステップ５０２では、DU２は、計画されているモビリティが条件付きモビリティである場合に、計画されているモビリティが条件付きモビリティでない場合（通常のモビリティ（e.g., ハンドオーバ）の場合）に比べて、所定のメッセージのCU１への送信を遅らせる。

幾つかの実装では、当該所定のメッセージは、UE３に関するUEコンテキストの変更のためのシグナリング手順において送信されるメッセージ（e.g., F1APメッセージ）であってもよい。より具体的には、当該所定のメッセージは、UE Context Modification手順で送信されるUE CONTEXT MODIFICATION RESPONSEメッセージであってもよい。通常の（つまり条件付きでない）UEモビリティでは、DU２は、CU１からのUE CONTEXT MODIFICATION REQUESTメッセージの受信に応答して、要求された修正（modifications）を実行し、更新（update）をUE CONTEXT MODIFICATION RESPONSEメッセージにおいて報告する。これとは対照的に、条件付きUEモビリティでは、DU２は、CU１からUE CONTEXT MODIFICATION REQUESTメッセージを受信し、要求された修正（modifications）を保留してもよい。そして、DU２は、条件付きモビリティの開始条件の成立に応答して、要求された修正を実行し、更新（update）をUE CONTEXT MODIFICATION RESPONSEメッセージにおいて報告してもよい。

これに代えて、幾つかの実装では、当該所定のメッセージは、UE３へ送信されていないダウンリンクデータを示すためにCU１に送信されるメッセージ（又はフレーム、又はProtocol Data Unit（PDU））であってもよい。より具体的には、当該所定のメッセージは、DOWNLINK DATA DELIVERY STATUS（DDDS）フレームであってもよい。DDDSフレームは、GTP-U（又はF1-U）PDUであってもよい。通常の（つまり条件付きでない）UEモビリティでは、DU２は、CU１からのUE CONTEXT MODIFICATION REQUESTメッセージ（UE３のためのデータ送信の停止を示すTransmission Stop Indicator 情報要素を含む）の受信に応答して、DDDSフレームをCU１に送信する。これとは対照的に、条件付きUEモビリティでは、DU２は、CU１からUE CONTEXT MODIFICATION REQUESTメッセージを受信した後も、UE３のためのデータ送信を継続してもよい。そして、DU２は、条件付きモビリティの開始条件の成立に応答して、UE３のためのデータ送信を停止し、DDDSフレームをCU１に送信してもよい。

DDDSフレームは、条件付きモビリティの開始（又は実行）を示す新たな情報（e.g., ビット）を包含してもよい。これに代えて、DU２は、通常の（つまり条件付きでない）UEモビリティで使用されるDDDSフレームを再利用しつつ、DU２からCU１に条件付きモビリティの開始（又は実行）を示すための新たに規定されるメッセージを送信してもよい。当該メッセージは、CONDITIONAL MOBILITY (又はHANDOVER, PSCell CHANGE, or RECONFIGURATION WITH SYNC) TRIGGERED (又はINITIATED, DETECTED, INDICATION, or INSTRUCTION)メッセージと呼ばれてもよい。このとき、DU２は、DDDSフレームを当該メッセージの後に送ってもよいし、当該メッセージの前に送ってもよい。

本実施形態では、DU２は、UE３の計画されているモビリティが条件付きモビリティである場合に、計画されているモビリティが条件付きモビリティでない場合に比べて、所定のメッセージのCU１への送信を遅らせる。具体的には、例えば、DU２は条件付きモビリティの開始条件が成立するまで（又は、成立したことを検出するまで）、当該所定のメッセージのCU１への送信を保留（又は延期）してもよい。したがって、当該所定のメッセージは、条件付きモビリティの開始（又は実行）をCU１に報告する用途を兼ねることができる。言い換えると、CU１は、当該所定のメッセージを受信することで、UE３が条件付きモビリティを開始（又は実行）したことを知ることができる。

＜第３の実施形態＞
本実施形態は、条件付きモビリティのためのシグナリングの具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図１及び図２に示された例と同様であってもよい。

図６は、intra-CU inter-DU条件付きハンドオーバ（CHO）手順の一例を示している。なお、図６の手順は、SCGのSRB（e.g., SRB3）を使用する条件付きPSCell changeのために使用されてもよい。言い換えると、図６の手順は、Inter-gNB-DU Mobility using SCG SRBのために使用されてもよい。

図６の手順よりも前に、CU１は、CHOのための報告設定（e.g., ReportConfig）を包含する測定設定（e.g., MeasConfig）を含むRRCメッセージ（e.g., RRCReconfigurationメッセージ）を生成し、これをソースDU２A経由でUE３へ送信してもよい。CHOのための測定設定は、CHO判定のために早いイベント・トリガリング（つまり、UE３による測定報告をトリガーする閾値を下げること）を可能にする。DU２Ａは、測定設定を含むRRCメッセージを受信するが、当該RRCメッセージに測定設定が含まれていることを認識しなくてもよい。言い換えると、DU２ＡはCU１から受信する測定設定を透過的に（transparently）UE３へ転送してもよい。他の実施形態を含む以降の説明でも、同様である。DU２Ａは、測定設定以外の他の情報を含むCU１からUE３へ送信されるRRCメッセージも同様に扱ってもよい。

ステップ６０１では、UE３は、測定報告（Measurement Report）をソースDU２Ａに送る。ステップ６０２では、ソースDU２Ａは、受信した測定報告を運ぶためにUPLINK RRC TRANSFERメッセージをCU１に送る。CU１は、当該測定報告に基づいて、ソースDU２ＡのセルからターゲットDU２ＢのセルへのUE３のCHOを決定する。DU２Ａは、測定報告を含むRRCメッセージを受信するが、当該RRCメッセージに測定報告が含まれていることを認識しなくてもよい。言い換えると、DU２ＡはUE３から受信する測定報告を透過的に（transparently）CU１へ転送してもよい。他の実施形態を含む以降の説明でも、同様である。DU２Ａは、測定報告以外の他の情報を含むUE３からCU１へ送信されるRRCメッセージについても同様に扱ってもよい。

ステップ６０３では、CU１は、UEコンテキストを作成し且つ１又はそれ以上のベアラをセットアップするために、UE CONTEXT SETUP REQUESTメッセージをターゲットDU２Ｂに送る。UE CONTEXT SETUP REQUESTメッセージは、CHOのためのターゲットセルの無線リソースの設定（e.g., CellGroupConfig）をターゲットDU２Ｂに要求してもよい。CHO要求であることを示すために、UE CONTEXT SETUP REQUESTメッセージ内の“CU to DU RRC Information”情報要素に包含されている“Handover Preparation Information”情報要素が使用されてもよい。これに代えて、CHO要求であることを示すために、UE CONTEXT SETUP REQUESTメッセージ内に新たな情報要素が定義されてもよい。

ステップ６０４では、ターゲットDU２Ｂは、UE CONTEXT SETUP RESPONSEメッセージによりCU１に応答する。ターゲットDU２Ｂは、CHO要求の受信に応答して、CHOを受け入れ可能であるか否かを判定してもよい。ターゲットDU２Ｂは、CHOを受け入れ可能であるか否かを示す情報要素をUE CONTEXT SETUP RESPONSEメッセージ（ステップ６０４）に含めてもよい。

ステップ６０５では、CU１は、CU１によって生成されたRRCメッセージ（e.g., RRCReconfigurationメッセージ）を包含するRRC-Containerを含むUE CONTEXT MODIFICATION REQUESTメッセージをソースDU２Ａに送る。当該RRCメッセージは、CHOの開始（又は実行）条件（e.g., 閾値及びTTT）を含む。さらに、当該RRCメッセージは、UE３がCHOを離れる（exit）条件（e.g., offset）、及び有効（validity）タイマの値を含んでもよい。有効タイマの値は、候補ターゲットセルのリソースがいつまで有効であるかを示してもよい。あるいは、有効タイマの値は、候補ターゲットセルへのアクセスが許可される期間（時間）、又はCHOのための設定が有効な期間（時間）を示してもよい。

UE CONTEXT MODIFICATION REQUESTメッセージ（ステップ６０５）は、これがUE３へのCHOの指示（つまり、CHOによるハンドオーバに必要なRRC設定情報）を含むこと、又はこれがCHOを意図していることを明示的又は暗示的に示す情報要素（IE）を含んでもよい。DU２Ａは、受信したUE CONTEXT MODIFICATION REQUESTメッセージが当該IEを含むか否かを判定してもよい。例えば、DU２Ａが、CHOであると判定した場合、後続の動作を決定してもよい。

より具体的には、CU１は、CHOの開始条件を決定し、これをUE CONTEXT SETUP REQUESTメッセージ（ステップ６０３）に包含されるCU To DU RRC Information情報要素（e.g., この中のHandover Preparation Information）又は新規な情報要素に含めてもよい。そして、ターゲットDU２Ｂは、CHOの開始条件を包含するターゲットセルの無線リソースの設定（e.g., CellGroupConfig）を生成し、これをUE CONTEXT SETUP RESPONSEメッセージ（ステップ６０４）に含めてもよい。さらに、CU１は、受信した無線リソースの設定（e.g., CellGroupConfig）を包含するRRCReconfigurationメッセージを生成し、これをUE CONTEXT MODIFICATION REQUESTメッセージ（ステップ６０５）内のRRC-Containerに含めてもよい。

これに代えて、CU１は、CHOの開始条件を決定し、これをUE CONTEXT MODIFICATION REQUESTメッセージ（ステップ６０５）内の新規情報要素に含めてもよい。

さらにこれに代えて、ターゲットDU２ＢがCHOの開始条件を決定してもよい。この場合、ターゲットDU２Ｂは、CHO要求（ステップ６０３）に応答してCHOの開始条件を決定し、決定したCHOの開始条件をUE CONTEXT SETUP RESPONSEメッセージ（ステップ６０４）内のCellGroupConfig情報要素又は新規情報要素に含めてもよい。そして、CU１は、CHOの開始条件を含むCellGroupConfig情報要素又は新規情報要を包含するRRCReconfigurationメッセージを生成し、これをUE CONTEXT MODIFICATION REQUESTメッセージ（ステップ６０５）に含めてもよい。CU１は、CHOの指示を明示的に示す情報要素（IE）又はパラメータを、RRCReconfigurationメッセージに含めてもよい。

CHOの開始条件に加えて、UE３がCHOを離れる（exit）条件、及び有効（validity）タイマの値も、CHOの開始条件と同様に取り扱われてもよい。これに代えて、CHOの開始条件、CHOを離れる条件、及び有効タイマの値それぞれが、上述のいずれかの方法によって取り扱われてもよい。

ステップ６０６では、ソースDU２Ａは、受信したRRCReconfigurationメッセージをUE３にフォワードする。

UE３は、RRCReconfigurationメッセージ（ステップ６０６）を受信すると、これがCHOの指示であることを示す情報要素（IE）又はパラメータを含むか否か、又はこれがCHOの開始条件を含むか否かに応じて、CHOの指示であるか否かを判定する。UE３は、CHOの指示であると判定した場合、当該RRCReconfigurationメッセージの受信後もソースDU２Ａとのコネクションを維持する。UE３は、RRCReconfigurationメッセージにより設定されたCHOの実行条件が成立したことに応じて（ステップ６０７）、ターゲットDU２Ｂへのアクセス（i.e., ランダムアクセス手順）を開始する（ステップ６１０）。UE３は、CHO開始の表示（又は報告）をソースDU２Ａに送信してもよい（ステップ６０８）。

UE３によるCHO開始の表示は、Physical Uplink Control Channel（PUCCH）で送信されるアップリンク制御情報（Uplink Control Information（UCI））であってもよい。これに代えて、CHO開始の表示は、MAC Control Element（CE）であってもよい。ソースDU２Ａは、CHO開始の表示に用いられる無線リソースの設定を予め決定し、これをCU１を介してUE３に通知してもよい。例えば、ソースDU２Ａは、CHO開始の表示に用いられる無線リソースの設定をUE CONTEXT SETUP RESPONSEメッセージに包含される情報（e.g., CellGroupConfig）に含め、これをCU１へ送信してもよい。そして、CU１は、CHO開始の表示に用いられる無線リソースの設定を含むRRCReconfigurationメッセージを生成し、これをUE３へ送信してもよい。複数の候補ターゲットセルがある場合、CHO開始の表示は、選択された候補ターゲットセル（つまり、ハンドオーバがトリガされた候補ターゲットセル）を明示的又は暗示的に示す情報を含んでもよい。

ステップ６０９では、ソースDU２Ａは、UE CONTEXT MODIFICATION RESPONSEメッセージによりCU１に応答する。一例では、ソースDU２Ａは、CHO開始の表示（ステップ６０８）をUE３から受信したことに応答して、UE CONTEXT MODIFICATION RESPONSEメッセージ（ステップ６０９）を送信してもよい。この場合、UE CONTEXT MODIFICATION RESPONSEメッセージは、CHOの開始（又は実行）をCU１に報告する用途を兼ねることができる。他の例では、ソースDU２Ａは、CHO開始の表示（ステップ６０８）の受信と無関係に、UE CONTEXT MODIFICATION RESPONSEメッセージ（ステップ６０９）を送信してもよい。ソースDU２Ａは、CHO開始の表示（ステップ６０８）の受信よりも前に、UE CONTEXT MODIFICATION RESPONSEメッセージ（ステップ６０９）を送信してもよい。

図６には示されていないが、ランダムアクセス手順（ステップ６１０）に成功した後に、UE３は、RRCReconfigurationCompleteメッセージによってターゲットDU２Ｂを介してCU１に応答してもよい。ターゲットDU２Ｂは、UE３から受信したRRCReconfigurationCompleteメッセージを運ぶためにUPLINK RRC TRANSFERメッセージをCU１に送ってもよい。そして、CU１は、UE CONTEXT RELEASE COMMANDメッセージをソースDU２Ａに送信してもよい。このとき、UE CONTEXT RELEASE COMMANDメッセージに付される（又は含まれる）解放Cause値は、例えば、“Handover Condition Met”、“Action Desirable for Radio Reasons”、“Handover Complete”、又は“Normal Release”であってもよい。ソースDU２Ａは、UE３に関するUEコンテキストを解放し、UE CONTEXT RELEASE COMPLETEメッセージによってCU１に応答してもよい。

図７は、intra-CU inter-DU条件付きハンドオーバ（CHO）手順の他の例を示している。図７の手順は、SCGのSRB（e.g., SRB3）を使用する条件付きPSCell changeのために使用されてもよい。ステップ７０１～７０６の処理は、図６のステップ６０１～６０６のそれと同様である。ステップ７０７では、ソースDU２Ａは、UE CONTEXT MODIFICATION RESPONSEメッセージによりCU１に応答する。

ステップ７０８では、UE３は、RRCReconfigurationメッセージにより設定されたCHOの実行条件の成立を判定し、ターゲットDU２Ｂへのアクセス（i.e., ランダムアクセス手順）を開始する（ステップ７１１）。UE３は、CHO開始の表示（又は報告）をソースDU２Ａに送信してもよい（ステップ７０９）。UE３によるCHO開始の表示は、PUCCHで送信されるアップリンク制御情報（UCI）であってもよい。これに代えて、CHO開始の表示は、MAC CEであってもよい。

ステップ７１０では、ソースDU２Ａは、DDDSフレームをCU１に送信する。一例では、ソースDU２Ａは、CHO開始の表示（ステップ７０９）をUE３から受信したことに応答して、DDDSフレーム（ステップ７１０）を送信してもよい。この場合、DDDSフレームは、CHOの開始（又は実行）をCU１に報告する用途を兼ねることができる。これに代えて、ソースDU２Ａは、通常の（つまり条件付きでない）ハンドオーバで使用されるDDDSフレームを送信しつつ、CU１にCHO開始（又は実行）を示すための新たなメッセージをさらに送信してもよい（図示なし）。当該メッセージは、CONDITIONAL HANDOVER TRIGGERED (又はINITIATED, DETECTED, INDICATION, or INSTRUCTION)メッセージと呼ばれてもよい。他の例では、ソースDU２Ａは、CHO開始の表示（ステップ７０９）の受信と無関係に、DDDSフレーム（ステップ７１０）を送信してもよい。ソースDU２Ａは、CHO開始の表示（ステップ７０９）の受信よりも前に、DDDSフレーム（ステップ７１０）を送信してもよい。

図７には示されていないが、ランダムアクセス手順（ステップ７１１）に成功した後に、UE３は、RRCReconfigurationCompleteメッセージによってターゲットDU２Ｂを介してCU１に応答してもよい。ターゲットDU２Ｂは、UE３から受信したRRCReconfigurationCompleteメッセージを運ぶためにUPLINK RRC TRANSFERメッセージをCU１に送ってもよい。そして、CU１は、UE CONTEXT RELEASE COMMANDメッセージをソースDU２Ａに送信してもよい。このとき、UE CONTEXT RELEASE COMMANDメッセージに付される（又は含まれる）解放Cause値は、例えば、“Handover Condition Met”、“Action Desirable for Radio Reasons”、“Handover Complete”、又は“Normal Release”であってもよい。ソースDU２Ａは、UE３に関するUEコンテキストを解放し、UE CONTEXT RELEASE COMPLETEメッセージによってCU１に応答してもよい。

本実施形態で説明された幾つかの手順は、intra-CU inter-DU条件付きハンドオーバを可能にする。

＜第４の実施形態＞
本実施形態は、条件付きモビリティのためのシグナリングの具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図１及び図２に示された例と同様であってもよい。

図８は、intra-CU inter-DU条件付きハンドオーバ（CHO）手順の一例を示している。図８の手順は、SCGのSRB（e.g., SRB3）を使用する条件付きPSCell changeのために使用されてもよい。ステップ８０１～８０６の処理は、図６のステップ６０１～６０６のそれと同様である。

ステップ８０７では、ソースDU２Ａは、CHOの実行条件の成立を自律的に判定する。ステップ８０８では、ソースDU２Ａは、CHOの実行条件の成立に応答して、CHO開始コマンドをUE３に送る。CHO開始コマンドは、Physical Downlink Control Channel（PDCCH）で送信されるダウンリンク制御情報（Downlink Control Information（DCI））であってもよい。これに代えて、CHO開始コマンドは、MAC Control Element（CE）であってもよい。ソースDU２Ａは、CHO開始コマンドに用いられる無線リソースの設定を予め決定し、これをCU１を介してUE３に通知してもよい。例えば、ソースDU２Ａは、CHO開始コマンドに用いられる無線リソースの設定をUE CONTEXT SETUP RESPONSEメッセージに包含される情報（e.g., CellGroupConfig）に含め、これをCU１へ送信してもよい。そして、CU１は、CHO開始コマンドに用いられる無線リソースの設定を含むRRCReconfigurationメッセージを生成し、これをUE３へ送信してもよい。複数の候補ターゲットセルがある場合、CHO開始コマンドは、選択された候補ターゲットセル（つまり、ハンドオーバがトリガされた候補ターゲットセル）を明示的又は暗示的に示す情報を含んでもよい。

ステップ８０９では、ソースDU２Ａは、UE CONTEXT MODIFICATION RESPONSEメッセージによりCU１に応答する。一例では、ソースDU２Ａは、CHOの実行条件の成立に応答して、UE CONTEXT MODIFICATION RESPONSEメッセージ（ステップ８０９）を送信してもよい。この場合、UE CONTEXT MODIFICATION RESPONSEメッセージは、CHOの開始（又は実行）をCU１に報告する用途を兼ねることができる。他の例では、ソースDU２Ａは、CHOの実行条件の成立と無関係に、UE CONTEXT MODIFICATION RESPONSEメッセージ（ステップ８０９）を送信してもよい。ソースDU２Ａは、CHOの実行条件の成立よりも前に、UE CONTEXT MODIFICATION RESPONSEメッセージ（ステップ８０９）を送信してもよい。

ステップ８１０では、UE３は、CHO開始コマンドの受信に応答して、ターゲットDU２Ｂへのアクセス（i.e., ランダムアクセス手順）を開始する。

図８には示されていないが、ランダムアクセス手順（ステップ８１０）に成功した後に、UE３は、RRCReconfigurationCompleteメッセージによってターゲットDU２Ｂを介してCU１に応答してもよい。ターゲットDU２Ｂは、UE３から受信したRRCReconfigurationCompleteメッセージを運ぶためにUPLINK RRC TRANSFERメッセージをCU１に送ってもよい。そして、CU１は、UE CONTEXT RELEASE COMMANDメッセージをソースDU２Ａに送信してもよい。ソースDU２Ａは、UE３に関するUEコンテキストを解放し、UE CONTEXT RELEASE COMPLETEメッセージによってCU１に応答してもよい。

図９は、intra-CU inter-DU条件付きハンドオーバ（CHO）手順の他の例を示している。図９の手順は、SCGのSRB（e.g., SRB3）を使用する条件付きPSCell changeのために使用されてもよい。ステップ９０１～９０６の処理は、図８のステップ８０１～８０６のそれと同様である。ステップ９０７では、ソースDU２Ａは、UE CONTEXT MODIFICATION RESPONSEメッセージによりCU１に応答する。

ステップ９０８では、ソースDU２Ａは、CHOの実行条件の成立を自律的に判定する。ステップ９０９では、ソースDU２Ａは、CHOの実行条件の成立に応答して、CHO開始コマンドをUE３に送る。CHO開始コマンドは、PDCCHで送信されるDCIであってもよい。これに代えて、CHO開始コマンドは、MAC CEであってもよい。

ステップ９１０では、ソースDU２Ａは、DDDSフレームをCU１に送信する。一例では、ソースDU２Ａは、CHOの実行条件の成立に応答して、DDDSフレーム（ステップ９１０）を送信してもよい。この場合、DDDSフレームは、CHOの開始（又は実行）をCU１に報告する用途を兼ねることができる。これに代えて、ソースDU２Ａは、通常の（つまり条件付きでない）ハンドオーバで使用されるDDDSフレームを送信しつつ、CU１にCHO開始（又は実行）を示すための新たなメッセージを送信してもよい（図示なし）。当該メッセージは、CONDITIONAL HANDOVER TRIGGERED (又はINITIATED, DETECTED, INDICATION, or INSTRUCTION)メッセージと呼ばれてもよい。他の例では、ソースDU２Ａは、CHOの実行条件の成立と無関係に、DDDSフレーム（ステップ９１０）を送信してもよい。ソースDU２Ａは、CHOの実行条件の成立よりも前に、DDDSフレーム（ステップ９１０）を送信してもよい。

図９には示されていないが、ランダムアクセス手順（ステップ９１１）に成功した後に、UE３は、RRCReconfigurationCompleteメッセージによってターゲットDU２Ｂを介してCU１に応答してもよい。ターゲットDU２Ｂは、UE３から受信したRRCReconfigurationCompleteメッセージを運ぶためにUPLINK RRC TRANSFERメッセージをCU１に送ってもよい。そして、CU１は、UE CONTEXT RELEASE COMMANDメッセージをソースDU２Ａに送信してもよい。このとき、UE CONTEXT RELEASE COMMANDメッセージに付される（又は含まれる）解放Cause値は、例えば、“Handover Condition Met”、“Action Desirable for Radio Reasons”、“Handover Complete”、又は“Normal Release”であってもよい。ソースDU２Ａは、UE３に関するUEコンテキストを解放し、UE CONTEXT RELEASE COMPLETEメッセージによってCU１に応答してもよい。

本実施形態で説明された幾つかの手順は、intra-CU inter-DU条件付きハンドオーバを可能にする。

＜第５の実施形態＞
本実施形態は、条件付きモビリティのためのシグナリングの具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図１及び図２に示された例と同様であってもよい。

図１０は、intra-CU inter-DU 条件付きPSCell Change手順の一例を示している。既に述べたように、条件付きPSCell Changeは、条件付きReconfiguration with sync（for PSCell change）と呼ぶこともできる。図１０は、MR-DCでのPSCell ChangeにMN４（e.g., Master eNB（MeNB））が関与（involve）するケースを示している。図１０の例では、UE３のためのPSCellがソースDU２ＡのセルからターゲットDU２Ｂのセルに変更される。PSCell ChangeのためにSN（i.e., CU１）とUE３との間で送信されるRRCシグナリングは、MN４によって提供されるMCG内のSRBを使用する。

図１０の手順よりも前に、CU１は、条件付きPSCell Changeのための報告設定（e.g., ReportConfig）を包含する測定設定（e.g., MeasConfig）を含むRRCメッセージ（e.g., RRCReconfigurationメッセージ）を生成し、これをMN４により提供されるMCG SRB経由でUE３へ送信してもよい。条件付きPSCell Changeのための測定設定は、条件付きPSCell Change判定のために早いイベント・トリガリング（つまり、UE３による測定報告をトリガーする閾値を下げること）を可能にする。

ステップ１００１及び１００２では、UE３は、測定報告（Measurement Report）をMN４を介してCU１に送る。ステップ１００２では、MN４は、受信した測定報告を運ぶためにRRC TRANSFERメッセージをCU１に送る。CU１は、当該測定報告に基づいて、ソースDU２ＡのセルからターゲットDU２ＢのセルへのUE３の条件付きモビリティ（i.e., 条件付きPSCell change）を決定する。

ステップ１００３では、CU１は、UEコンテキストを作成し且つ１又はそれ以上のベアラをセットアップするために、UE CONTEXT SETUP REQUESTメッセージをターゲットDU２Ｂに送る。UE CONTEXT SETUP REQUESTメッセージは、PSCellの無線リソースの設定（e.g., CellGroupConfig）をターゲットDU２Ｂに要求してもよい。条件付きモビリティ（i.e., 条件付きPSCell change）の要求であることを明示的に又は暗示的に示すために、UE CONTEXT SETUP REQUESTメッセージ内の“CU to DU RRC Information”情報要素に包含されている“CG-ConfigInfo”情報要素が使用されてもよい。これに代えて、条件付きモビリティ要求であることを明示的に又は暗示的に示すために、UE CONTEXT SETUP REQUESTメッセージ内に新たな情報要素が定義（又は導入）されてもよい。

ステップ１００４では、ターゲットDU２Ｂは、UE CONTEXT SETUP RESPONSEメッセージによりCU１に応答する。ターゲットDU２Ｂは、条件付きモビリティ要求の受信に応答して、条件付きモビリティ（i.e., 条件付きPSCell change）を受け入れ可能であるか否かを判定してもよい。ターゲットDU２Ｂは、条件付きモビリティを受け入れ可能であるか否かを示す情報要素をUE CONTEXT SETUP RESPONSEメッセージ（ステップ１００４）に含めてもよい。

ステップ１００５では、CU１は、CU１によって生成されたSN RAT（e.g., NR）のRRCメッセージ（e.g., NR RRCReconfigurationメッセージ）を含むSN MODIFICATION REQUIREDメッセージをMN４に送る。当該RRCメッセージは、条件付きモビリティ（i.e., 条件付きPSCell change、又は条件付きReconfiguration with sync for PSCell change）の開始（又は実行）条件を含む。既に説明したように、条件付きビリティの開始（又は実行）条件は、例えば、閾値及びTTTであってもよい。これに代えて、条件付きビリティの開始（又は実行）条件は、ネットワークからの明示的な実行指示（e.g., 所定のシグナリング）の受信であってもよい。この場合、当該実行指示の受信に使用される設定（e.g., 無線パラメータ）のUE３による受信は、条件付きモビリティの開始（又は実行）条件が当該実行指示の受信であることを、UE３に暗示的に示してもよい。言い換えると、UE３は当該設定（e.g., 無線パラメータ）を受信した場合、それに関連付けられた条件付きモビリティの開始（又は実行）条件が当該実行指示（e.g., 所定のシグナリング）の受信であると判定（又は理解）してもよい。

さらに、当該RRCメッセージは、UE３が条件付きPSCell changeを離れる（exit）条件（e.g., offset）、及び有効（validity）タイマの値を含んでもよい。有効タイマの値は、候補ターゲットセル（つまり変更後のPSCellの候補となるセル）のリソースがいつまで有効であるかを示してもよい。あるいは、有効タイマの値は、候補ターゲットセルへのアクセスが許可される期間（時間）、又は条件付きモビリティのための設定が有効な期間（時間）を示してもよい。

より具体的には、CU１は、条件付きモビリティの開始条件を決定し、これをUE CONTEXT SETUP REQUESTメッセージ（ステップ１００３）に包含されるCG-ConfigInfo情報要素又は新規な情報要素に含めてもよい。そして、ターゲットDU２Ｂは、条件付きモビリティの開始条件を包含する無線リソースの設定（e.g., CellGroupConfig）を生成し、これをUE CONTEXT SETUP RESPONSEメッセージ（ステップ１００４）に含めてもよい。さらに、CU１は、受信した無線リソースの設定（e.g., CellGroupConfig）を包含するSN RATのRRCメッセージを生成し、これをSN MODIFICATION REQUIREDメッセージ（ステップ１００５）に含めてもよい。

これに代えて、CU１は、条件付きモビリティの開始条件を決定し、これをSN MODIFICATION REQUIREDメッセージ（ステップ１００５）内の新規情報要素に含めてもよい。

さらにこれに代えて、ターゲットDU２Ｂが条件付きモビリティの開始条件を決定してもよい。この場合、ターゲットDU２Ｂは、条件付きモビリティ要求（ステップ１００３）に応答して条件付きモビリティの開始条件を決定し、決定した開始条件をUE CONTEXT SETUP RESPONSEメッセージ（ステップ１００４）内のCellGroupConfig情報要素又は新規情報要素に含めてもよい。そして、CU１は、条件付きモビリティの開始条件を含むCellGroupConfig情報要素又は新規情報要を包含するSN RATのRRCメッセージを生成し、これをSN MODIFICATION REQUIREDメッセージ（ステップ１００５）に含めてもよい。

もしデータフォワーディング若しくはSNセキュリティキーの変更又は両方が適用される必要があるなら、MN４は、MN initiated SN Modification手順を行い、フォワーディングアドレス若しくは新たなSNセキュリティキー情報又は両方をSN Modification Requestメッセージを用いてCU１に適用してもよい。

ステップ１００６では、CU１は、UE CONTEXT MODIFICATION REQUESTメッセージをソースDU２Ａに送る。当該メッセージは、条件付きモビリティ（i.e., 条件付きPSCell change）の表示を含む。

ステップ１００７では、MN４は、MCG SRBを介したMN RAT（e.g., LTE）のRRC再設定手順（e.g., LTE RRC Connection Reconfigurtion手順）を行い、CU１から受信したSN RATのRRCメッセージをUE３にフォワードする。UE３は、CU１宛てのSN RATのRRC応答メッセージ（e.g., NR RRC Reconfiguration Completeメッセージ）を包含するMN RATのRRCメッセージ（e.g., LTE RRC Connection Reconfiguration Completeメッセージ）をMN４に送信する。

ステップ１００８では、MN４は、MN RATのRRC再設定手順の成功裏の完了に応じて、SN MODIFICATION CONFIRMメッセージによりCU１に応答する。当該SN MODIFICATION CONFIRMメッセージは、UE３から受信したSN RATのRRC応答メッセージ（e.g., NR RRC Reconfiguration Completeメッセージ）を包含する。

UE３は、SN RATのRRCメッセージ（ステップ１００７）の受信後もソースDU２Ａとのコネクションを維持する。UE３は、SN RATのRRCメッセージにより設定された条件付きモビリティ（i.e., 条件付きReconfiguration with sync）の実行条件が成立したことに応じて（ステップ１００９）、新たな設定を適用し、ターゲットDU２Ｂへのアクセス（i.e., ランダムアクセス手順）を開始する（ステップ１０１２）。UE３は、条件付きモビリティ開始の表示（又は報告）をソースDU２Ａに送信してもよい（ステップ１０１０）。UE３による条件付きモビリティ開始の表示は、PUCCHで送信されるアップリンク制御情報（UCI）であってもよい。これに代えて、条件付きモビリティ開始の表示は、MAC CEであってもよい。ソースDU２Ａは、CHO開始の表示に用いられる無線リソースの設定を予め決定し、これをCU１を介してUE３に通知してもよい。例えば、ソースDU２Ａは、条件付きモビリティ開始の表示に用いられる無線リソースの設定をUE CONTEXT SETUP RESPONSEメッセージに包含される情報（e.g., CellGroupConfig）に含め、これをCU１へ送信してもよい。そして、CU１は、条件付きモビリティ開始の表示に用いられる無線リソースの設定を含むRRCReconfigurationメッセージを生成し、これをUE３へ送信してもよい。複数の候補ターゲットセル（e.g., PSCell候補）がある場合、条件付きモビリティ開始の表示は、選択された候補ターゲットセル（e.g., PSCell changeがトリガされた候補ターゲットセル）を明示的又は暗示的に示す情報を含んでもよい。

ステップ１０１１では、ソースDU２Ａは、UE CONTEXT MODIFICATION RESPONSEメッセージによりCU１に応答する。一例では、ソースDU２Ａは、条件付きモビリティ開始の表示（ステップ１０１０）をUE３から受信したことに応答して、UE CONTEXT MODIFICATION RESPONSEメッセージ（ステップ１０１１）を送信してもよい。この場合、UE CONTEXT MODIFICATION RESPONSEメッセージは、条件付きモビリティの開始（又は実行）をCU１に報告する用途を兼ねることができる。他の例では、ソースDU２Ａは、条件付きモビリティ開始の表示（ステップ１０１０）の受信と無関係に、UE CONTEXT MODIFICATION RESPONSEメッセージ（ステップ１０１１）を送信してもよい。ソースDU２Ａは、条件付きモビリティ開始の表示（ステップ１０１０）の受信よりも前に、UE CONTEXT MODIFICATION RESPONSEメッセージ（ステップ１０１１）を送信してもよい。

図１０には示されていないが、CU１は、UE CONTEXT MODIFICATION RESPONSEメッセージ（ステップ１０１１）の受信後に、UE CONTEXT RELEASE COMMANDメッセージをソースDU２Ａに送信してもよい。又は、CU１は、図示されていないDDDSフレームをソースDU２Ａから受信した後に、UE CONTEXT RELEASE COMMANDメッセージをソースDU２Ａに送信してもよい。このとき、UE CONTEXT RELEASE COMMANDメッセージに付される（又は含まれる）解放Cause値は、例えば、“Handover Condition Met”、“Action Desirable for Radio Reasons”、“Handover Complete”、又は“Normal Release”であってもよい。ソースDU２Ａは、UE３に関するUEコンテキストを解放し、UE CONTEXT RELEASE COMPLETEメッセージによってCU１に応答してもよい。

図１１は、intra-CU inter-DU 条件付きPSCell Change手順の他の例を示している。ステップ１１０１～１１０６の処理は、図１０のステップ１００１～１００６のそれと同様である。ステップ１１０７では、ソースDU２Ａは、UE CONTEXT MODIFICATION RESPONSEメッセージによりCU１に応答する。

ステップ１１０８及び１１０９の処理は、図１０のステップ１００７及び１００８の処理と同様である。すなわち、ステップ１１０８では、MN４は、MCG SRBを介したMN RAT（e.g., LTE）のRRC再設定手順（e.g., LTE RRC Connection Reconfigurtion手順）を行い、CU１から受信したSN RAT（e.g., NR）のRRCメッセージ（e.g., NR RRC Reconfigurationメッセージ）をUE３にフォワードする。UE３は、CU１宛てのSN RATのRRC応答メッセージ（e.g., NR RRC Reconfiguration Completeメッセージ）を包含するMN RATのRRC応答メッセージ（e.g., LTE RRC Connection Reconfiguration Completeメッセージ）をMN４に送信する。ステップ１１０９では、MN４は、MN RATのRRC再設定手順の成功裏の完了に応じて、SN MODIFICATION CONFIRMメッセージによりCU１に応答する。当該SN MODIFICATION CONFIRMメッセージは、UE３から受信したSN RATのRRC応答メッセージ（e.g., NR RRC Reconfiguration Completeメッセージ）を包含する。

ステップ１１１０では、UE３は、SN RATのRRCメッセージにより設定された条件付きモビリティ（i.e., 条件付きReconfiguration with sync）の実行条件の成立を判定し、新たな設定を適用し、ターゲットDU２Ｂへのアクセス（i.e., ランダムアクセス手順）を開始する（ステップ１１１３）。UE３は、条件付きモビリティ開始の表示をソースDU２Ａに送信してもよい（ステップ１１１１０）。

ステップ１１１２では、ソースDU２Ａは、DDDSフレームをCU１に送信する。一例では、ソースDU２Ａは、条件付きモビリティ開始の表示（ステップ１１１１）をUE３から受信したことに応答して、DDDSフレーム（ステップ１１１２）を送信してもよい。この場合、DDDSフレームは、条件付きモビリティの開始（又は実行）をCU１に報告する用途を兼ねることができる。これに代えて、ソースDU２Ａは、通常の（つまり条件付きでない）モビリティで使用されるDDDSフレームを送信しつつ、CU１に条件付きモビリティの開始（又は実行）を示すための新たなメッセージを送信してもよい（図示なし）。当該メッセージは、CONDITIONAL MOBILITY TRIGGERED (又はINITIATED, DETECTED, INDICATION, or INSTRUCTION)メッセージと呼ばれてもよい。他の例では、ソースDU２Ａは、条件付きモビリティ開始の表示（ステップ１１１１）の受信と無関係に、DDDSフレーム（ステップ１１１２）を送信してもよい。ソースDU２Ａは、条件付きモビリティ開始の表示（ステップ１１１１）の受信よりも前に、DDDSフレーム（ステップ１１１２）を送信してもよい。

図１１には示されていないが、CU１は、DDDSフレーム（ステップ１１１２）の受信後に、UE CONTEXT RELEASE COMMANDメッセージをソースDU２Ａに送信してもよい。このとき、UE CONTEXT RELEASE COMMANDメッセージに付される（又は含まれる）解放Cause値は、例えば、“Handover Condition Met”、“Action Desirable for Radio Reasons”、“Handover Complete”、又は“Normal Release”であってもよい。ソースDU２Ａは、UE３に関するUEコンテキストを解放し、UE CONTEXT RELEASE COMPLETEメッセージによってCU１に応答してもよい。

本実施形態で説明された幾つかの手順は、intra-CU inter-DU条件付きPSCell Changeを可能にする。

＜第６の実施形態＞
本実施形態は、条件付きモビリティのためのシグナリングの具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図１及び図２に示された例と同様であってもよい。

図１２は、intra-CU inter-DU条件付きPSCell Change手順の一例を示している。ステップ１２０１～１２０８の処理は、図１０のステップ１００１～１００８のそれと同様である。ただし、ステップ１２０６のUE CONTEXT MODIFICATION REQUESTメッセージは、条件付きモビリティ（i.e., 条件付きPSCell change、又は条件付きReconfiguration with sync）の条件を示す。

ステップ１２０９では、ソースDU２Ａは、条件付きモビリティ（i.e., 条件付きPSCell change、又は条件付きReconfiguration with sync）の実行条件の成立を自律的に判定する。ステップ１２１０では、ソースDU２Ａは、条件付きモビリティの実行条件の成立に応答して、条件付きモビリティ開始コマンドをUE３に送る。条件付きモビリティ開始コマンドは、PDCCHで送信されるダウンリンク制御情報（DCI）であってもよい。これに代えて、条件付きモビリティ開始コマンドは、MAC CEであってもよい。ソースDU２Ａは、条件付きモビリティ開始コマンドに用いられる無線リソースの設定を予め決定し、これをCU１を介してUE３に通知してもよい。例えば、ソースDU２Ａは、条件付きモビリティ開始コマンドに用いられる無線リソースの設定をUE CONTEXT SETUP RESPONSEメッセージに包含される情報（e.g., CellGroupConfig）に含め、これをCU１へ送信してもよい。そして、CU１は、条件付きモビリティ開始コマンドに用いられる無線リソースの設定を含むRRCReconfigurationメッセージを生成し、これをUE３へ送信してもよい。複数の候補ターゲットセル（e.g., PSCell候補）がある場合、条件付きモビリティ開始コマンドは、選択された候補ターゲットセル（e.g., PSCell changeがトリガされた候補ターゲットセル）を明示的又は暗示的に示す情報を含んでもよい。

ステップ１２１１では、ソースDU２Ａは、UE CONTEXT MODIFICATION RESPONSEメッセージによりCU１に応答する。一例では、ソースDU２Ａは、条件付きモビリティの実行条件の成立に応答して、UE CONTEXT MODIFICATION RESPONSEメッセージ（ステップ１２１１）を送信してもよい。この場合、UE CONTEXT MODIFICATION RESPONSEメッセージは、条件付きモビリティの開始（又は実行）をCU１に報告する用途を兼ねることができる。他の例では、ソースDU２Ａは、条件付きモビリティの実行条件の成立と無関係に、UE CONTEXT MODIFICATION RESPONSEメッセージ（ステップ１２１１）を送信してもよい。ソースDU２Ａは、条件付きモビリティの実行条件の成立よりも前に、UE CONTEXT MODIFICATION RESPONSEメッセージ（ステップ１２１１）を送信してもよい。

ステップ１２１２では、UE３は、条件付きモビリティ開始コマンドの受信に応答して、ターゲットDU２Ｂへのアクセス（i.e., ランダムアクセス手順）を開始する。

図１２には示されていないが、CU１は、UE CONTEXT MODIFICATION RESPONSEメッセージ（ステップ１２１１）の受信後に、UE CONTEXT RELEASE COMMANDメッセージをソースDU２Ａに送信してもよい。又は、CU１は、図示されていないDDDSフレームをソースDU２Ａから受信した後に、UE CONTEXT RELEASE COMMANDメッセージをソースDU２Ａに送信してもよい。このとき、UE CONTEXT RELEASE COMMANDメッセージに付される（又は含まれる）解放Cause値は、例えば、“Handover Condition Met”、“Action Desirable for Radio Reasons”、“Handover Complete”、又は“Normal Release”であってもよい。ソースDU２Ａは、UE３に関するUEコンテキストを解放し、UE CONTEXT RELEASE COMPLETEメッセージによってCU１に応答してもよい。

図１３は、intra-CU inter-DU 条件付きPSCell Change手順の他の例を示している。ステップ１３０１～１３０６の処理は、図１２のステップ１２０１～１２０６のそれと同様である。ステップ１３０７では、ソースDU２Ａは、UE CONTEXT MODIFICATION RESPONSEメッセージによりCU１に応答する。

ステップ１３０８及び１３０９の処理は、図１２のステップ１２０７及び１２０８の処理と同様である。すなわち、ステップ１３０８では、MN４は、MCG SRBを介したMN RAT（e.g., LTE）のRRC再設定手順（e.g., LTE RRC Connection Reconfigurtion手順）を行い、CU１から受信したSN RAT（e.g., NR）のRRCメッセージ（e.g., NR RRC Reconfigurationメッセージ）をUE３にフォワードする。UE３は、CU１宛てのSN RATのRRC応答メッセージ（e.g., NR RRC Reconfiguration Completeメッセージ）を包含するMN RATのRRC RRC応答メッセージ（e.g., LTE Connection Reconfiguration Completeメッセージ）をMN４に送信する。ステップ１３０９では、MN４は、MN RATのRRC再設定手順の成功裏の完了に応じて、SN MODIFICATION CONFIRMメッセージによりCU１に応答する。当該SN MODIFICATION CONFIRMメッセージは、UE３から受信したSN RATのRRC応答メッセージ（e.g., NR RRC Reconfiguration Completeメッセージ）を包含する。

ステップ１３１０では、ソースDU２Ａは、条件付きモビリティ（i.e., 条件付きPSCell change、又は条件付きReconfiguration with sync）の実行条件の成立を自律的に判定する。ステップ１３１１では、ソースDU２Ａは、条件付きモビリティの実行条件の成立に応答して、条件付きモビリティ開始コマンドをUE３に送る。条件付きモビリティ開始コマンドは、PDCCHで送信されるDCIであってもよい。これに代えて、条件付きモビリティ開始コマンドは、MAC CEであってもよい。

ステップ１３１２では、ソースDU２Ａは、DDDSフレームをCU１に送信する。一例では、ソースDU２Ａは、条件付きモビリティの実行条件の成立に応答して、DDDSフレーム（ステップ１３１２）を送信してもよい。この場合、DDDSフレームは、条件付きモビリティの開始（又は実行）をCU１に報告する用途を兼ねることができる。これに代えて、ソースDU２Ａは、通常の（つまり条件付きでない）モビリティで使用されるDDDSフレームを送信しつつ、CU１に条件付きモビリティの開始（又は実行）を示すための新たなメッセージを送信してもよい（図示なし）。当該メッセージは、CONDITIONAL MOBILITY TRIGGERED (又はINITIATED, DETECTED, INDICATION, or INSTRUCTION)メッセージと呼ばれてもよい。他の例では、ソースDU２Ａは、条件付きモビリティの実行条件の成立と無関係に、DDDSフレーム（ステップ１３１２）を送信してもよい。ソースDU２Ａは、条件付きモビリティの実行条件の成立よりも前に、DDDSフレーム（ステップ１３１２）を送信してもよい。

図１３には示されていないが、CU１は、DDDSフレーム（ステップ１３１２）の受信後に、UE CONTEXT RELEASE COMMANDメッセージをソースDU２Ａに送信してもよい。このとき、UE CONTEXT RELEASE COMMANDメッセージに付される（又は含まれる）解放Cause値は、例えば、“Handover Condition Met”、“Action Desirable for Radio Reasons”、“Handover Complete”、又は“Normal Release”であってもよい。ソースDU２Ａは、UE３に関するUEコンテキストを解放し、UE CONTEXT RELEASE COMPLETEメッセージによってCU１に応答してもよい。

本実施形態で説明された幾つかの手順は、intra-CU inter-DU条件付きPSCell Changeを可能にする。

＜第７の実施形態＞
本実施形態は、条件付きモビリティのためのシグナリングの具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図１及び図２に示された例と同様であってもよい。

UE３は、ソースDU２Ａ（又はCU１）から条件付きモビリティ開始コマンドを受信したことに応答して、条件付きモビリティ（e.g., CHO）を開始してもよい。言い換えると、条件付きモビリティのためにUE３に設定されるモビリティ開始条件は、ネットワーク（e.g., ソースDU２Ａ）からの明示的なシグナリング（e.g., 条件付きモビリティ開始コマンド）の受信であってもよい。

条件付きモビリティ開始コマンドは、モビリティ開始条件をUE３に設定するためにネットワークからUE３に送られるメッセージ（e.g., RRCメッセージ）のレイヤ（RRCレイヤ）よりも下位レイヤ（e.g., MACレイヤ、physicalレイヤ）の信号であってもよい。より具体的には、条件付きモビリティ開始コマンドは、PDCCHで送信されるDCI（i.e., physical layer signalling）であってもよいし、MAC CE（i.e., MAC layer signalling）であってもよい。一般的に、物理レイヤ及びMACレイヤのシグナリングは、RRCレイヤのシグナリングよりも頻繁に送信されることができる。言い換えると、物理レイヤ及びMACレイヤのシグナリングの送信機会（transmission opportunities）の間隔は、RRCレイヤのシグナリングのそれよりも短い。したがって、RRCレイヤよりも下位のレイヤのシグナリングを用いることは、UE３への条件付きモビリティ開始コマンドの速やかな送信に寄与できる。

さらに、条件付きモビリティ開始コマンドの送信のためにRRCレイヤよりも下位のレイヤ（e.g., MACレイヤ、physicalレイヤ）のシグナリングを用いることは、Inter-gNB-DU Mobility using MCG SRBを含むSN Modification with MN involvementにおいて特に有効である。SN Modification with MN involvementでは、条件付きモビリティ（e.g., 条件付きPSCell change）のためのRRCシグナリングがMCG SRBを介して送信される。したがって、セカンダリノード（SN）（i.e., ソースDU２Ａ及びCU１）からUE３へのRRCシグナリングの送信は、マスターノード（MN）を経由することに起因する遅延が生じる。これとは対照的に、SN（i.e., ソースDU２Ａ及びCU１）からUE３へのMACレイヤ又はphysicalレイヤのシグナリングは、SN（i.e., ソースDU２Ａ及びCU１）によって提供されるセルの物理チャネルを介してUE３に直接的に送信できる。したがって、SN（i.e., ソースDU２Ａ及びCU１）は、RRCレイヤよりも下位のレイヤ（e.g., MACレイヤ、physicalレイヤ）のシグナリングを用いて条件付きモビリティ開始コマンドを送信することによって、当該コマンドをUE３に送る際の遅延を低減できる。

なお、この説明から理解されるように、本実施形態で説明されたシグナリング手順は、CU-DU splitが適用されない場合にも有効である。例えば、SN Modification with MN involvementのケースにおいて、SNは、RRCレイヤよりも下位のレイヤ（e.g., MACレイヤ、physicalレイヤ）のシグナリングを用いて条件付きモビリティ開始コマンドを送信してもよい。これにより、条件付きモビリティ開始コマンドは、MCG SRBを経由せずに、SN によって提供されるセルの物理チャネルを介してUE３に直接的に送られることができる。このことは、条件付きモビリティ開始コマンドをUE３に送る際の遅延の低減に寄与できる。

図１４は、本実施形態に係るシグナリングの一例を示している。ステップ１４０１では、ソースDU２Ａ（又はCU１）は、条件付きモビリティ開始コマンドのための設定を含むRRCメッセージ（e.g., RRCReconfigurationメッセージ）を送信する。図示されていないが、ソースDU２Ａが条件付きモビリティ開始コマンドのための設定を決定し、これをCU１へ例えばDU To CU RRC Information情報要素で送信してもよい。そして、CU１が当該設定を含むRRCメッセージを生成し、ソースDU２Ａを介してUE３へ送信してもよい。さらに、CU１及びDU２ＡがDCのSN（e.g., SgNB）である場合、当該RRCメッセージは、MN（e.g., MeNB）を介して（つまりMCGセルのSRBを介して）UE３に送られてもよい。

条件付きモビリティ開始コマンドのための設定は、条件付きモビリティ開始コマンドの識別情報を示してもよい。さらに又はこれに代えて、当該設定は、条件付きモビリティ開始コマンドの送信のためのリソースを示してもよい。より具体的には、当該設定は、条件付きモビリティ開始コマンドのインデックスを示してもよいし、条件付きモビリティ開始コマンドの送信のための時間／周波数／コード・リソースを示してもよい。当該設定は、UE３に固有のPDCCH parameters（e.g., Downlink Control Information (DCI)）を設定するために使用されるPDCCH-Configであってもよい。

ステップ１４０２では、ソースDU２Ａ（又はCU１）は、条件付きモビリティ（e.g., CHO）の実行条件の成立を判定する。ステップ１４０３では、ソースDU２Ａは、条件付きモビリティの実行条件の成立に応答して、条件付きモビリティ開始コマンド（e.g., CHO開始コマンド）をUE３に送る。条件付きモビリティ開始コマンドの送信は、ステップ１４０１においてUE３に事前に提供された設定に従う。

図１４の手順は、CU-DUスプリットを適用されていないソースノード（e.g., ソースgNB、又はソースeNB）によって、CHOのために行われてもよい。図１４の手順は、CU-DUスプリットを適用されていないSNによって、MR-DCでの条件付きPSCell changeのために行われてもよい。

＜第８の実施形態＞
本実施形態は、条件付きモビリティのためのシグナリングの具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図１及び図２に示された例と同様であってもよい。本実施形態では、複数の候補ターゲットセルは、複数のDU２によって提供されてもよい。

図１５は、intra-CU inter-DU 条件付きモビリティ（e.g., CHO）に関するシグナリングの一例を示す図である。ステップ１５０１では、CU１は、候補ターゲットセルのリソースの解放の要求を１又は複数のターゲットDU２Ｂに送る。Inter-DUハンドオーバのケースでは、当該要求は、条件付きハンドオーバのために予約されている１又は複数の候補ターゲットセルのリソースを解放するよう各ターゲットDU２Ｂに要求する。CU１は、UE３が移動するターゲットセルとは異なる候補ターゲットセルを管理するターゲットDU２Ｂに当該要求を送信すればよい。一方、Inter-DU PSCell Changeのケースでは、当該要求は、条件付きPSCell Change（又は条件付きReconfiguration with sync）のために予約されている１又は複数の候補ターゲットPSCellのリソースを解放するよう各ターゲットDU２Ｂに要求する。CU１は、UE３が移動するターゲットPSCellとは異なる候補ターゲットPSCellを管理するターゲットDU２Ｂに当該要求を送信すればよい。

リソース解放要求のためにステップ１５０１で送信されるメッセージは、例えばUE CONTEXT RELEASE COMMANDメッセージであってもよい。このとき、UE CONTEXT RELEASE COMMANDメッセージに付される（又は含まれる）解放Cause値は、例えば、“Handover Condition Met”、“Action Desirable for Radio Reasons”、“Handover Complete”、 “Normal Release”、又は“Candidate Target Cell Found”であってもよい。

例えば、CU１は、UE３が条件付きモビリティを完了したことを検出した場合に、ステップ１５０１の要求を送信してもよい。CU１は、UE３の条件付きモビリティの成功を示すメッセージ（e.g., RRCReconfigurationCompleteメッセージを運ぶUPLINK RRC TRANSFERメッセージ）をいずれかのターゲットDU２Ｂから受信したことによって、条件付きモビリティの完了を検出してもよい。CU１及びDU２ＡがDCのSNである場合、CU１は、UE３の条件付きモビリティの成功を示すメッセージ（e.g., RRCReconfigurationCompleteメッセージ）をMN（e.g., MeNB）を介してUE３から受信したことによって、条件付きモビリティの完了を検出してもよい。

これに代えて、CU１は、UE３が条件付きモビリティを実行（又は開始）したこと検出した場合に、ステップ１５０１の要求を送信してもよい。CU１は、条件付きモビリティの開始の表示（indication）（e.g., measurement report）をUE３又はいずれかのターゲットDU２Ｂから受信したことによって、モビリティ実行（又は開始）を検出してもよい。

このような動作によれば、例えば、ターゲットDU２Ｂは、有効（validity）タイマの満了を待つことなく、条件付きモビリティのために予約されていたリソースをCU１からの要求に応答して解放できる。

一方、UE３は、いずれかの候補ターゲットセルへの条件付きモビリティを完了した場合に、自律的に他の候補ターゲットセルのリソース（つまり、無線リソース設定）を解放してもよい。これに代えて、UE３は、条件付きモビリティを完了した後にネットワーク（e.g., CU１、又はターゲットDU２Ｂ）から解放要求を受信したことに応答して、他の候補ターゲットセルのリソースを解放してもよい。

＜第９の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図１及び図２に示された例と同様であってもよい。本実施形態は、UE３へ送信されていないダウンリンクデータを示すためにソースDU２ＡからCU１へ送られる制御メッセージの改良を提供する。当該制御メッセージは、これに限られないが例えば、LTE及びNRで使用されるDOWNLINK DATA DELIVERY STATUS（DDDS）フレームであってもよい。

第１～第３の実施形態で説明されたように、DDDSフレームは、UE３へ送信されていないダウンリンクデータを示すことに加えて、条件付きモビリティ（e.g., CHO）の開始（又は実行）をCU１に報告する用途のために使用されてもよい。DDDSフレームは、条件付きモビリティの開始（又は実行）を明示的に表示してもよい。例えば、DDDSフレームは、条件付きモビリティの開始（又は実行）を示すための１又はそれ以上のビットを含んでもよい。

図１６は、CHOの開始（又は実行）を明示的に表示するために改良されたDDDSフレームのフォーマットの一例を示している。図１６の例では、DDDSフレームは、Conditional Handover Metビット１６０１を含む。ビット１６０１は、CHOの実行（又は開始）条件が満たされた（met、又はsatisfied）か否かを示す。ビット１６０１は、CHOに代えて又は加えて、他の条件付きモビリティを示すために使用されてもよい。

ビット１６０１の値は、条件付きモビリティの実行（又は開始）条件が満たされた場合に１とされ、そうでない場合に０とされてもよい。この場合、ビット１６０１の値が１であるとき、当該ビットはConditional Handover indicationを示す。Conditional Handover indicationは、条件付きモビリティの実行（又は開始）条件が満たされた場合にシグナルされる。例えば、Conditional Handover indicationを受信した場合、NR PDCP entityをホストするノード（e.g., CU１）は、対応するノード（e.g., DU２）とUE３の間でアップリンク又はダウンリンクデータがこれ以上送信されないと考えられることを認識してもよい。

本実施形態に係る制御メッセージ（e.g., DDDSフレーム）は、例えば、UE３へ送信されていないダウンリンクデータを示すことに加えて、条件付きモビリティ（e.g., CHO）の開始（又は実行）をDU３に報告することをDU２に可能にする。

続いて以下では、上述の複数の実施形態に係るCU１、DU２、及びUE３の構成例について説明する。図１７は、上述の実施形態に係るCU１の構成例を示すブロック図である。なお、CU-CP１１及びCU-UP１２の構成も図１７に示されたそれと同様であってもよい。図１７を参照すると、CU１は、ネットワークインターフェース１７０１、プロセッサ１７０２、及びメモリ１７０３を含む。ネットワークインターフェース１７０１は、ネットワークノード（e.g., DU２並びにコアネットワーク内の制御プーレーン（CP）ノード及びユーザプレーン（UP）ノード）と通信するために使用される。ネットワークインターフェース１７０１は、複数のインタフェースを含んでもよい。ネットワークインターフェース１７０１は、例えば、CU-DU間通信のための光ファイバーインタフェース及びIEEE 802.3 seriesに準拠したネットワークインターフェースを含んでもよい。

プロセッサ１７０２は、無線通信のためのデジタルベースバンド信号処理（データプレーン処理）とコントロールプレーン処理を行う。プロセッサ１７０２は、複数のプロセッサを含んでもよい。例えば、プロセッサ１７０２は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., Digital Signal Processor（DSP））とコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., Central Processing Unit（CPU）又はMicro Processing Unit（MPU））を含んでもよい。

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

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

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

ネットワークインターフェース１８０３は、ネットワークノード（e.g., CU１、CU-CP１１、CU-UP１２）と通信するために使用される。ネットワークインターフェース１８０３は、複数のインタフェースを含んでもよい。ネットワークインターフェース１８０３は、例えば、CU-DU間通信のための光ファイバーインタフェース及びIEEE 802.3 seriesに準拠したネットワークインターフェースのうち少なくとも１つを含んでもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

図１７～図１９を用いて説明したように、上述の実施形態に係るCU１、DU２、及び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）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

＜その他の実施形態＞
上述の実施形態で説明されたCU１とDU２の間のシグナリングは、CU-CP１１とDU２の間、又はCU-UP１２とDU２の間で行われてもよい。

上述の実施形態は、各々独立に実施されてもよいし、実施形態全体又はその一部が適宜組み合わせて実施されてもよい。これらの実施形態は、互いに独立に実施されることができ、互いに異なる目的又は課題を解決することに寄与し、互いに異なる効果を奏することに寄与する。

上述の実施形態で条件付き（Conditional）モビリティとして説明された機能は、事前条件設定（pre-conditioned）モビリティ、事前準備（prepared）モビリティ、又は遅延型（delayed）モビリティなどと呼ばれてもよい。さらに具体的には、条件付きハンドオーバ（Conditional handover: CHO）として説明された機能は、事前条件設定ハンドオーバ（pre-conditioned HO）、事前準備ハンドオーバ（prepared HO）、又は遅延型ハンドオーバ（delayed HO）などと呼ばれてもよい。同様に、上述の実施形態で条件付き（Conditional）PSCell changeとして説明された機能は、事前条件設定（pre-conditioned）PSCell change、事前準備（prepared）PSCell change、又は遅延型（delayed）PSCell changeなどと呼ばれてもよい。

上述の実施形態で説明された条件付きハンドオーバ（又はReconfiguration with sync）は、これらに限定されないが例えば、inter-gNBハンドオーバ、intra-gNB (inter-gNB-DU) ハンドオーバ、gNB及びeNB/5GC (ng-eNB) の間のハンドオーバ、inter-eNB/5GCハンドオーバ、又はintra-eNB/5GC (inter-eNB/5GC-DU)ハンドオーバであってもよい。さらに、上述の実施形態で説明された条件付きハンドオーバは、条件付きintra-DU（e.g., intra-gNB-DU又はintra-eNB-DU）ハンドオーバであってもよい。条件付きintra-DUハンドオーバでは、複数の候補ターゲットセルの少なくとも１つが、ソースセルと同じgNB-DU（又はeNB-DU）のセルである。この場合、ターゲットRANノードのCU（e.g., gNB-CU）とDU（e.g., gNB-DU）の間のUE CONTEXT SETUP REQUEST及びUE CONTEXT RESPONSEメッセージは、それぞれUE CONTEXT MODIFICATION REQUEST及びUE CONTEXT MODIFICATION RESPONSEメッセージであってもよい。

上述した条件付きハンドオーバのためのハンドオーバ実行の条件（e.g., 閾値（イベント）及び対応するtime-to-trigger (TTT)）は、すでに3GPPにより規定されている測定報告（Measurement report）をトリガするイベント（e.g. Event A1, A2, A3, A4, A5, A6, B1, B2, C1, C2, W1, W2, W3, V1, V2, H1, or H2）毎に新たなイベントとして追加（定義）されてもよい。

さらに又はこれに代えて、上述した条件付きハンドオーバのためのハンドオーバ実行の条件は、すでに3GPPにより規定されている測定報告をトリガする各イベントに含まれる複数のパラメータの少なくとも１つと置き換えられるパラメータを含んでもよい。

さらに又はこれに代えて、上述した条件付きハンドオーバのためのハンドオーバ実行の条件は、すでに3GPPにより規定されている測定報告をトリガする各イベントに含まれる複数のパラメータの少なくとも１つに対するオフセット値を含んでもよい。

すでに3GPPで規定されている測定報告（Measurement report）をトリガするイベント（e.g. Event A1, A2, A3, A4, A5, A6, B1, B2, C1, C2, W1, W2, W3, V1, V2, H1, and H2）に含まれるパラメータは、これには限られないが例えば、以下のうち少なくとも１つを含んでもよい：
Ms：オフセット値を考慮しないサービングセルの測定結果、オフセット値を考慮しない送信リソースプールのチャネル混雑比（channel busy ratio）の測定結果、又はUE３がAerial UEの場合のオフセット値を考慮しないAerial UEの高度、
Hys：このイベントのためのヒステリシス値、
Thresh (1又は2)：このイベントのための閾値、
Mn：オフセット値を考慮しない隣接セルの測定結果、
Ofn：隣接セルの周波数のための周波数固有のオフセット値、
Ocn：隣接セルにのためのセル固有のオフセット値、
Mp：オフセット値を考慮しないPrimary Cell又はPrimary SCG Cellの測定結果
Ofp：Primary Cell又はPrimary SCG Cellの周波数のための周波数固有のオフセット値、
Ocp：Primary Cell又はPrimary SCG Cellのためのセル固有のオフセット値
Off：このイベントのためのオフセットパラメータ、
Mcr：オフセット値を考慮しないCSI-RS（Channel State Information-Reference Signal）リソースの測定結果、
Ocr：CSI-RSのためのCSI-RS固有のオフセット値、
Mref：参照CSI-RSリソースの測定結果、及び
Oref：参照CSI-RSリソースのためのCSI-RS固有のオフセット値。

本明細書における無線端末（User Equipment（UE））は、無線インターフェースを介して、ネットワークに接続されるエンティティである。本明細書の無線端末（UE）は、専用の通信装置に限定されるものではなく、本明細書中に記載された無線端末（UE）の通信機能を有する次のような任意の機器であってもよい。

「（3GPPで使われる単語としての）ユーザー端末（User Equipment（UE））」、「移動局（mobile station）」、「移動端末（mobile terminal）」、「モバイルデバイス（mobile device）」、及び「無線端末（wireless device）」との用語は、一般的に互いに同義であることが意図されている。UEは、ターミナル、携帯電話、スマートフォン、タブレット、セルラIoT端末、IoTデバイス、などのスタンドアローン移動局であってもよい。「UE」及び「無線端末」との用語は、長期間にわたって静止している装置も包含する。

UEは、例えば、生産設備・製造設備および／またはエネルギー関連機械（一例として、ボイラー、機関、タービン、ソーラーパネル、風力発電機、水力発電機、火力発電機、原子力発電機、蓄電池、原子力システム、原子力関連機器、重電機器、真空ポンプなどを含むポンプ、圧縮機、ファン、送風機、油圧機器、空気圧機器、金属加工機械、マニピュレータ、ロボット、ロボット応用システム、搬送装置、昇降装置、貨物取扱装置、繊維機械、縫製機械、印刷機、印刷関連機械、紙工機械、化学機械、鉱山機械、鉱山関連機械、建設機械、建設関連機械、農業用機械および／または器具、林業用機械および／または器具、漁業用機械および／または器具、安全および／または環境保全器具、トラクター、動力伝動装置、および／または上記で述べた任意の機器又は機械のアプリケーションシステムなど）であってもよい。

UEは、例えば、輸送用装置（一例として、車両、自動車、二輪自動車、自転車、列車、バス、リヤカー、人力車、船舶（ship and other watercraft）、飛行機、ロケット、人工衛星、ドローン、気球など）であってもよい。

UEは、例えば、情報通信用装置（一例として、電子計算機及び関連装置、通信装置及び関連装置、電子部品など）であってもよい。

UEは、例えば、商業およびサービス用機器、自動販売機、自動サービス機、事務用機械及び装置、民生用電気・電子機械器具（一例として音声機器、スピーカー、ラジオ、映像機器、テレビなど）であってもよい。

UEは、例えば、電子応用システムまたは電子応用装置（一例として、X線装置、粒子加速装置、放射性物質応用装置、音波応用装置、電磁応用装置、電力応用装置など）であってもよい。

UEは、例えば、電球、照明、計量機、分析機器、試験機及び計測機械（一例として、煙報知器、対人警報センサ、動きセンサ、無線タグなど）、時計（watchまたはclock）、理化学機械、光学機械、医療用機器および／または医療用システム、武器、利器工匠具、または手道具であってもよい。

UEは、例えば、無線通信機能を備えたパーソナルデジタルアシスタントまたは装置（一例として、無線カードや無線モジュールなどを取り付けられる、もしくは挿入するよう構成された電子装置（例えば、パーソナルコンピュータや電子計測器など））であってもよい。

UEは、例えば、有線や無線通信技術を使用した「あらゆるモノのインターネット（IoT：Internet of Things）」において、以下のアプリケーション、サービス、ソリューションを提供する装置またはその一部であってもよい。IoTデバイス（もしくはモノ）は、デバイスが互いに、および他の通信デバイスとの間で、データ収集およびデータ交換することを可能にする適切な電子機器、ソフトウェア、センサー、ネットワーク接続、などを備える。IoTデバイスは、内部メモリの格納されたソフトウェア指令に従う自動化された機器であってもよい。IoTデバイスは、人間による監督または対応を必要とすることなく動作してもよい。IoTデバイスは、長期間にわたって備え付けられている装置および／または、長期間に渡って非活性状態（inactive）状態のままであってもよい。IoTデバイスは、据え置き型な装置の一部として実装され得る。IoTデバイスは、非据え置き型の装置（例えば車両など）に埋め込まれ得る、または監視される／追跡される動物や人に取り付けられ得る。IoT技術は、人間の入力による制御またはメモリに格納されるソフトウェア命令に関係なくデータを送受信する通信ネットワークに接続されることができる任意の通信デバイス上に実装されることができる。IoTデバイスは、機械型通信（Machine Type Communication、MTC）デバイス、またはマシンツーマシン（Machine to Machine、M2M）通信デバイス、Narrow Band-IoT (NB-IoT) UEと呼ばれることもある。

UEは、１つまたは複数のIoTまたはMTCアプリケーションをサポートしてもよい。

MTCアプリケーションのいくつかの例は、3GPP TS22.368 V13.2.0(2017-01-13) Annex B（その内容は参照により本明細書に組み込まれる）に示されたリストに列挙されている。このリストは、網羅的ではなく、一例としてのMTCアプリケーションを示すものである。このリストでは、MTCアプリケーションのサービス範囲 (Service Area)は、セキュリティ (Security)、追跡及びトレース (Tracking & Tracing)、支払い (Payment)、健康 (Health)、リモートメンテナンス／制御 (Remote Maintenance/Control)、計量 (Metering)、及び民生機器 (Consumer Devices)を含む。

セキュリティに関するMTCアプリケーションの例は、監視システム (Surveillance systems)、固定電話のバックアップ (Backup for landline)、物理アクセスの制御（例えば建物へのアクセス） (Control of physical access (e.g. to buildings))、及び車／運転手のセキュリティ (Car/driver security)を含む。

追跡及びトレースに関するMTCアプリケーションの例は、フリート管理 (Fleet Management)、注文管理 (Order Management)、テレマティクス保険：走行に応じた課金 (Pay as you drive (PAYD))、資産追跡 (Asset Tracking)、ナビゲーション (Navigation)、交通情報 (Traffic information)、道路料金徴収 (Road tolling)、及び道路通行最適化／誘導 (Road traffic optimisation/steering)を含む。

支払いに関するMTCアプリケーションの例は、販売時点情報管理 (Point of sales (POS))、自動販売機 (Vending machines)、及び遊戯機 (Gaming machines)を含む。

健康に関するMTCアプリケーションの例は、生命徴候の監視 (Monitoring vital signs)、高齢者又は障害者支援 (Supporting the aged or handicapped)、ウェブアクセス遠隔医療 (Web Access Telemedicine points)、及びリモート診断 (Remote diagnostics)を含む。

リモートメンテナンス／制御に関するMTCアプリケーションの例は、センサー (Sensors)、明かり (Lighting)、ポンプ (Pumps)、バルブ (Valves)、エレベータ制御 (Elevator control)、自動販売機制御 (Vending machine control)、及び車両診断 (Vehicle diagnostics)を含む。

計量に関するMTCアプリケーションの例は、パワー (Power)、ガス (Gas)
水 (Water)、暖房 (Heating)、グリッド制御 (Grid control)、及び産業用メータリング (Industrial metering)を含む。

民生機器に関するMTCアプリケーションの例は、デジタルフォトフレーム、デジタルカメラ、及び電子ブック (ebook)を含む。

アプリケーション、サービス、及びソリューションは、一例として、MVNO（Mobile Virtual Network Operator：仮想移動体通信事業者）サービス/システム、防災無線サービス/システム、構内無線電話（PBX（Private Branch eXchange：構内交換機））サービス/システム、PHS/デジタルコードレス電話サービス/システム、Point of sales（POS）システム、広告発信サービス/システム、マルチキャスト（Multimedia Broadcast and Multicast Service（MBMS））サービス/システム、V2X（Vehicle to Everything：車車間通信および路車間・歩車間通信）サービス/システム、列車内移動無線サービス/システム、位置情報関連サービス/システム、災害/緊急時無線通信サービス/システム、IoT（Internet of Things：モノのインターネット）サービス/システム、コミュニティーサービス/システム、映像配信サービス/システム、Femtoセル応用サービス/システム、VoLTE（Voice over LTE）サービス/システム、無線タグ・サービス/システム、課金サービス/システム、ラジオオンデマンドサービス/システム、ローミングサービス/システム、ユーザー行動監視サービス/システム、通信キャリア/通信NW選択サービス/システム、機能制限サービス/システム、PoC（Proof of Concept）サービス/システム、端末向け個人情報管理サービス/システム、端末向け表示・映像サービス/システム、端末向け非通信サービス/システム、アドホックNW/DTN（Delay Tolerant Networking）サービス/システムなどであってもよい。

上述したUEのカテゴリは、本明細書に記載された技術思想及び実施形態の応用例に過ぎない。本明細書のUEは、これらの例に限定されるものではなく、当業者は種々の変更をこれに行うことができる。

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

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

（付記１）
基地局の分散ユニットであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、前記分散ユニットによって提供される第１のセルから第２のセルへの無線端末の条件付きモビリティの開始を検出したことに応答して、第１のメッセージを前記基地局の中央ユニットに送るよう構成される、
分散ユニット。

（付記２）
前記少なくとも１つのプロセッサは、
前記無線端末の計画されているモビリティが前記条件付きモビリティであるかを判定するよう構成され、
前記計画されているモビリティが前記条件付きモビリティである場合に、前記計画されているモビリティが前記条件付きモビリティでない場合に比べて前記第１のメッセージの前記中央ユニットへの送信を遅らせるよう構成される、
付記１に記載の分散ユニット。

（付記３）
前記第１のメッセージは、前記無線端末に関するコンテキストの変更のためのシグナリング手順において送信される、
付記１又は２に記載の分散ユニット。

（付記４）
前記シグナリング手順は、UE Context Modification 手順であり、
前記第１のメッセージは、UE CONTEXT MODIFICATION RESPONSEメッセージである、
付記３に記載の分散ユニット。

（付記５）
前記第１のメッセージは、前記無線端末へ送信されていないダウンリンクデータを示すために前記中央ユニットに送信される、
付記１又は２に記載の分散ユニット。

（付記６）
前記第１のメッセージは、DOWNLINK DATA DELIVERY STATUSフレームである、
付記５に記載の分散ユニット。

（付記７）
前記少なくとも１つのプロセッサは、前記条件付きモビリティの開始条件の成立に応じて前記無線端末から送信される報告を受信したことによって、前記条件付きモビリティの開始を検出するよう構成される、
付記１～６のいずれか１項に記載の分散ユニット。

（付記８）
前記少なくとも１つのプロセッサは、前記条件付きモビリティの開始条件の成立を自律的に判定したことによって、前記条件付きモビリティの開始を検出するよう構成される、
付記１～６のいずれか１項に記載の分散ユニット。

（付記９）
前記少なくとも１つのプロセッサは、前記条件付きモビリティの前記開始条件の成立に応答して、前記無線端末に条件付きモビリティ開始コマンドを送信するよう構成される、
付記８に記載の分散ユニット。

（付記１０）
前記少なくとも１つのプロセッサは、前記条件付きモビリティ開始コマンドのための設定を、前記条件付きモビリティ開始コマンドの送信よりも前に、前記中央ユニットへ送信するよう構成される、
付記９に記載の分散ユニット。

（付記１１）
前記第２のセルは、前記分散ユニット、前記分散ユニットとは異なる前記基地局の他の分散ユニット、又は前記基地局とは異なる他の基地局によって提供される、
付記１～１０のいずれか１項に記載の分散ユニット。

（付記１２）
基地局の分散ユニットのための方法であって、
前記分散ユニットによって提供される第１のセルから第２のセルへの無線端末の条件付きモビリティの開始を検出したことに応答して、第１のメッセージを前記基地局の中央ユニットに送ることを備える、
方法。

（付記１３）
前記無線端末の計画されているモビリティが前記条件付きモビリティであるかを判定すること、及び
前記計画されているモビリティが前記条件付きモビリティである場合に、前記計画されているモビリティが前記条件付きモビリティでない場合に比べて前記第１のメッセージの前記中央ユニットへの送信を遅らせること、
をさらに備える、
付記１２に記載の方法。

（付記１４）
前記第１のメッセージは、前記無線端末に関するコンテキストの変更のためのシグナリング手順において送信される、
付記１２又は１３に記載の方法。

（付記１５）
前記シグナリング手順は、UE Context Modification 手順であり、
前記第１のメッセージは、UE CONTEXT MODIFICATION RESPONSEメッセージである、
付記１４に記載の方法。

（付記１６）
前記第１のメッセージは、前記無線端末へ送信されていないダウンリンクデータを示すために前記中央ユニットに送信される、
付記１２又は１３に記載の方法。

（付記１７）
前記第１のメッセージは、DOWNLINK DATA DELIVERY STATUSフレームである、
付記１６に記載の方法。

（付記１８）
前記条件付きモビリティの開始条件の成立に応じて前記無線端末から送信される報告を受信したことによって、前記条件付きモビリティの開始を検出すことをさらに備える、
付記１２～１７のいずれか１項に記載の方法。

（付記１９）
前記条件付きモビリティの開始条件の成立を自律的に判定したことによって、前記条件付きモビリティの開始を検出することをさらに備える、
付記１２～１７のいずれか１項に記載の方法。

（付記２０）
基地局の分散ユニットのための方法をコンピュータに行わせるためのプログラムであって、
前記方法は、前記分散ユニットによって提供される第１のセルから第２のセルへの無線端末の条件付きモビリティの開始を検出したことに応答して、第１のメッセージを前記基地局の中央ユニットに送ることを備える、
プログラム。

（付記２１）
基地局の中央ユニットであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、
前記基地局の分散ユニットによって提供される第１のセルから第２のセルへの無線端末の条件付きモビリティを制御し、
前記分散ユニットが前記条件付きモビリティの開始を検出したことに応答して送信する第１のメッセージを受信するよう構成される、
中央ユニット。

（付記２２）
前記少なくとも１つのプロセッサは、前記無線端末に計画されているモビリティが前記条件付きモビリティであることを明示的に又は暗示的に示す情報を前記分散ユニットに送信するよう構成される、
付記２１に記載の中央ユニット。
（付記２３）
前記少なくとも１つのプロセッサは、前記第１のメッセージの受信に応答して、前記無線端末による条件付きモビリティが開始されたことを知るよう構成される、
付記２１又は２２に記載の中央ユニット。

（付記２４）
基地局の中央ユニットのための方法であって、
前記基地局の分散ユニットによって提供される第１のセルから第２のセルへの無線端末の条件付きモビリティを制御すること、及び
前記分散ユニットが前記条件付きモビリティの開始を検出したことに応答して送信する第１のメッセージを受信すること、
を備える、方法。

（付記２５）
基地局の中央ユニットのための方法をコンピュータに行わせるためのプログラムであって、
前記方法は、
前記基地局の分散ユニットによって提供される第１のセルから第２のセルへの無線端末の条件付きモビリティを制御すること、及び
前記分散ユニットが前記条件付きモビリティの開始を検出したことに応答して送信する第１のメッセージを受信すること、
を備える、プログラム。

（付記２６）
無線アクセスネットワークノードであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、前記無線アクセスネットワークノードによって提供される第１のセルから第２のセルへの無線端末の条件付きモビリティの開始条件の成立に応答して、前記無線端末に条件付きモビリティ開始コマンドを送信するよう構成され、
前記少なくとも１つのプロセッサは、前記条件付きモビリティ開始コマンドのための設定を、前記条件付きモビリティ開始コマンドの送信よりも前に、前記無線端末に送信するよう構成される、
無線アクセスネットワークノード。

（付記２７）
前記少なくとも１つのプロセッサは、デュアルコネクティビティのマスターノードを介して、前記設定を前記無線端末に送信するよう構成され、
前記少なくとも１つのプロセッサは、前記無線アクセスネットワークノードにより提供されるセルを介して、前記条件付きモビリティ開始コマンドを前記無線端末に直接的に送信するよう構成される、
付記２６に記載の無線アクセスネットワークノード。

（付記２８）
前記設定は、Radio Resource Control（RRC）メッセージを介して前記無線端末に送信され、
前記条件付きモビリティ開始コマンドは、RRCレイヤよりも下位レイヤのシグナリングを用いて前記無線端末に送信される、
付記２６又は２７のいずれか１項に記載の無線アクセスネットワークノード。

（付記２９）
前記条件付きモビリティ開始コマンドは、Medium Access Control（MAC）のシグナリングを用いて前記無線端末に送信される、
付記２８に記載の無線アクセスネットワークノード。

（付記３０）
前記条件付きモビリティ開始コマンドは、MAC Control Element（CE）である、
付記２８又は２９に記載の無線アクセスネットワークノード。

（付記３１）
前記条件付きモビリティ開始コマンドは、物理レイヤのシグナリングを用いて前記無線端末に送信される、
付記２８に記載の無線アクセスネットワークノード。

（付記３２）
前記条件付きモビリティ開始コマンドは、Physical Downlink Control Channel（PDCCH）で送信されるダウンリンク制御情報（Downlink Control Information（DCI））である、
付記２８又は３１に記載の無線アクセスネットワークノード。

（付記３３）
前記設定は、前記条件付きモビリティ開始コマンドの識別情報、及び前記条件付きモビリティ開始コマンドの送信のためのリソースのうち少なくとも１つを示す、
付記２６～３２のいずれか１項に記載の無線アクセスネットワークノード。

（付記３４）
前記無線アクセスネットワークノードは、中央ユニット及び少なくとも１つの分散ユニットを含む、
付記２６～３３のいずれか１項に記載の無線アクセスネットワークノード。

（付記３５）
無線アクセスネットワークノードのための方法であって、
前記無線アクセスネットワークノードによって提供される第１のセルから第２のセルへの無線端末の条件付きモビリティの開始条件の成立に応答して、前記無線端末に条件付きモビリティ開始コマンドを送信すること、及び
前記条件付きモビリティ開始コマンドのための設定を、前記条件付きモビリティ開始コマンドの送信よりも前に、前記無線端末に送信すること、
を備える方法。

（付記３６）
無線アクセスネットワークノードのための方法をコンピュータに行わせるためのプログラムであって、
前記方法は、
前記無線アクセスネットワークノードによって提供される第１のセルから第２のセルへの無線端末の条件付きモビリティの開始条件の成立に応答して、前記無線端末に条件付きモビリティ開始コマンドを送信すること、及び
前記条件付きモビリティ開始コマンドのための設定を、前記条件付きモビリティ開始コマンドの送信よりも前に、前記無線端末に送信すること、
を備える、
プログラム。

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

１ 中央ユニット（Central Unit（CU））
２ 分散ユニット（Distributed Unit（DU））
３ UE
４ マスターノード（Master Node（MN））
１１ CU-CP
１２ CU-UP
１７０２ プロセッサ
１７０３ メモリ
１７０４ モジュール（modules）
１８０４ プロセッサ
１８０５ メモリ
１８０６ モジュール（modules）
１９０３ ベースバンドプロセッサ
１９０４ アプリケーションプロセッサ
１９０６ メモリ
１９０７ モジュール（modules）

Claims (6)

1. User equipment（UE）のための方法であって、
   gNB-CU内でのSource gNB-DUからTarget gNB-DUへの条件つきハンドオーバにおいて、複数の条件付きハンドオーバ候補セルの１つであるターゲットセルへのアクセスが完了した場合に、前記ターゲットセルを除く前記複数の条件付きハンドオーバ候補ターゲットセルのリソースを自律的に解放する工程を有する、方法。
2. 前記Source gNB-DUから、前記複数の条件付きハンドオーバの実行条件に関する情報を含む、RRCReconfigurationメッセージを受信する工程を備える、請求項１に記載の方法。
3. 前記複数の条件付きハンドオーバの実行条件が成立した場合に、前記Target gNB-DUとの間でランダムアクセス手順を実行する工程を備える、請求項２に記載の方法。
4. User equipment（UE）であって、
   gNB-CU内でのSource gNB-DUからTarget gNB-DUへの条件つきハンドオーバにおいて、複数の条件付きハンドオーバ候補セルの１つであるターゲットセルへのアクセスが完了した場合に、前記ターゲットセルを除く前記複数の条件付きハンドオーバ候補ターゲットセルのリソースを自律的に解放する手段を有する、ＵＥ。
5. 前記Source gNB-DUから、前記複数の条件付きハンドオーバの実行条件に関する情報を含む、RRCReconfigurationメッセージを受信する手段を有する、請求項４に記載のＵＥ。
6. 前記複数の条件付きハンドオーバの実行条件が成立した場合に、前記Target gNB-DUとの間でランダムアクセス手順を実行する手段を有する、請求項５に記載のＵＥ。

Images