IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 日本電気株式会社の特許一覧

特許7396444User equipment及びUser equipmentのための方法
<>
  • 特許-User  equipment及びUser  equipmentのための方法 図1
  • 特許-User  equipment及びUser  equipmentのための方法 図2
  • 特許-User  equipment及びUser  equipmentのための方法 図3
  • 特許-User  equipment及びUser  equipmentのための方法 図4
  • 特許-User  equipment及びUser  equipmentのための方法 図5
  • 特許-User  equipment及びUser  equipmentのための方法 図6
  • 特許-User  equipment及びUser  equipmentのための方法 図7
  • 特許-User  equipment及びUser  equipmentのための方法 図8
  • 特許-User  equipment及びUser  equipmentのための方法 図9
  • 特許-User  equipment及びUser  equipmentのための方法 図10
  • 特許-User  equipment及びUser  equipmentのための方法 図11
  • 特許-User  equipment及びUser  equipmentのための方法 図12
  • 特許-User  equipment及びUser  equipmentのための方法 図13
  • 特許-User  equipment及びUser  equipmentのための方法 図14
  • 特許-User  equipment及びUser  equipmentのための方法 図15
  • 特許-User  equipment及びUser  equipmentのための方法 図16
  • 特許-User  equipment及びUser  equipmentのための方法 図17
  • 特許-User  equipment及びUser  equipmentのための方法 図18
  • 特許-User  equipment及びUser  equipmentのための方法 図19
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-12-04
(45)【発行日】2023-12-12
(54)【発明の名称】User equipment及びUser equipmentのための方法
(51)【国際特許分類】
   H04W 36/24 20090101AFI20231205BHJP
【FI】
H04W36/24
【請求項の数】 6
(21)【出願番号】P 2022188930
(22)【出願日】2022-11-28
(62)【分割の表示】P 2021156753の分割
【原出願日】2019-10-31
(65)【公開番号】P2023011033
(43)【公開日】2023-01-20
【審査請求日】2022-11-28
(31)【優先権主張番号】P 2019003562
(32)【優先日】2019-01-11
(33)【優先権主張国・地域又は機関】JP
(73)【特許権者】
【識別番号】000004237
【氏名又は名称】日本電気株式会社
(74)【代理人】
【識別番号】100103894
【弁理士】
【氏名又は名称】家入 健
(72)【発明者】
【氏名】二木 尚
(72)【発明者】
【氏名】林 貞福
【審査官】石田 信行
(56)【参考文献】
【文献】Nokia, Nokia Shanghai Bell,RRC Container exchange in UE Context Management [online],3GPP TSG RAN WG3 #98 R3-174367,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_98/Docs/R3-174367.zip>,2017年12月01日
【文献】Samsung, KT,Mobility procedures with high layer split [online],3GPP TSG RAN WG3 #98 R3-174611,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_98/Docs/R3-174611.zip>,2017年12月01日
【文献】CATT,Discussion on UE Context Management [online],3GPP TSG RAN WG3 #96 R3-171458,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_96/Docs/R3-171458.zip>,2017年05月19日
【文献】CATT,L2 Behaviors in NR Handover or Reconfiguration [online],3GPP TSG RAN WG2 #97 R2-1700984,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_97/Docs/R2-1700984.zip>,2017年02月17日
(58)【調査した分野】(Int.Cl.,DB名)
H04W 4/00 - 99/00
H04B 7/24 - 7/26
3GPP TSG RAN WG1-4
SA WG1-4
CT WG1,4
(57)【特許請求の範囲】
【請求項1】
User equipment(UE)のための方法であって、
gNB-CU内でのSource gNB-DUからTarget gNB-DUへの条件つきハンドオーバにおいて、複数の条件付きハンドオーバ候補セルの1つであるターゲットセルへのアクセスが完了した場合に、前記ターゲットセルを除く前記複数の条件付きハンドオーバ候補ターゲットセルのリソースを自律的に解放する工程を有する、方法。
【請求項2】
前記Source gNB-DUから、前記複数の条件付きハンドオーバの実行条件に関する情報を含む、RRCReconfigurationメッセージを受信する工程を備える、請求項1に記載の方法。
【請求項3】
前記複数の条件付きハンドオーバの実行条件が成立した場合に、前記Target gNB-DUとの間でランダムアクセス手順を実行する工程を備える、請求項2に記載の方法。
【請求項4】
User equipment(UE)であって、
gNB-CU内でのSource gNB-DUからTarget gNB-DUへの条件つきハンドオーバにおいて、複数の条件付きハンドオーバ候補セルの1つであるターゲットセルへのアクセスが完了した場合に、前記ターゲットセルを除く前記複数の条件付きハンドオーバ候補ターゲットセルのリソースを自律的に解放する手段を有する、UE。
【請求項5】
前記Source gNB-DUから、前記複数の条件付きハンドオーバの実行条件に関する情報を含む、RRCReconfigurationメッセージを受信する手段を有する、請求項4に記載のUE。
【請求項6】
前記複数の条件付きハンドオーバの実行条件が成立した場合に、前記Target gNB-DUとの間でランダムアクセス手順を実行する手段を有する、請求項5に記載のUE。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、無線通信システムに関し、特に無線端末のモビリティに関する。
【背景技術】
【0002】
非特許文献1及び2は、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)は、無線端末が、ハンドオーバコマンドの受信に応答してではなく、ハンドオーバコマンドにより設定された条件の成立に応答してターゲットセルへのアクセスを開始する点で、既存のハンドオーバと異なる。
【0003】
CHOは、早いイベント・トリガリング(つまり、無線端末による測定報告をトリガーする閾値を下げること)によって、UEへのハンドオーバコマンドのデリバリーの信頼性(reliability)を高めることができる。これにより、CHOは、ハンドオーバ失敗率(handover failure rate)を低減できる。
【0004】
なお、CHOでは、複数の候補ターゲットセルの設定が無線端末に送られてもよい。候補ターゲットセルは、潜在的(potential)ターゲットセルと呼ばれてもよい。例えば、無線端末は、複数の候補ターゲットセルの設定とCHO実行閾値とを含むハンドオーバコマンドをソースRANノード(e.g., eNB)から受信する。そして、無線端末は、設定された複数の候補ターゲットセルの測定を行い(又は開始し)、いずれかの候補ターゲットセルでの測定がCHO実行閾値を満たす場合に当該候補セルへのアクセス(e.g. ランダムアクセス)を開始する。
【先行技術文献】
【非特許文献】
【0005】
【文献】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
【発明の概要】
【発明が解決しようとする課題】
【0006】
発明者等は、条件付きハンドオーバを含む条件付きモビリティをcloud RAN(C-RAN)配置(deployment)に適用することを検討し、様々な課題を見出した。C-RANでは、基地局(e.g., eNB、又はNR gNodeB(gNB))は、Central Unit(CU)と1又はそれ以上のDistributed Units(DUs)から構成される。C-RAN は、Centralized RANと呼ばれることもあるし、CU-DU split architectureと呼ばれることもある。
【0007】
例えば、条件付きモビリティ(e.g., 条件付きハンドオーバ)がCU-DU split architectureに適用される場合に、条件付きモビリティの実行条件の成立(又は条件付きモビリティの開始)をCUがどのようにして知るのかが明確でない。
【0008】
本明細書に開示される実施形態が達成しようとする目的の1つは、条件付きモビリティの実行条件の成立(又は条件付きモビリティの開始)を知ることをCentral Unit(CU)に可能にすることに寄与する装置、方法、及びプログラムを提供することである。なお、この目的は、本明細書に開示される複数の実施形態が達成しようとする複数の目的の1つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。
【課題を解決するための手段】
【0009】
第1の態様では、基地局の分散ユニットは、少なくとも1つのメモリ及び前記少なくとも1つのメモリに結合された少なくとも1つのプロセッサを含む。前記少なくとも1つのプロセッサは、前記分散ユニットによって提供される第1のセルから第2のセルへの無線端末の条件付きモビリティの開始を検出したことに応答して、第1のメッセージを前記基地局の中央ユニットに送るよう構成される。
【0010】
第2の態様では、基地局の分散ユニットのための方法は、前記分散ユニットによって提供される第1のセルから第2のセルへの無線端末の条件付きモビリティの開始を検出したことに応答して、第1のメッセージを前記基地局の中央ユニットに送ることを含む。
【0011】
第3の態様では、基地局の中央ユニットは、少なくとも1つのメモリ及び前記少なくとも1つのメモリに結合された少なくとも1つのプロセッサを含む。前記少なくとも1つのプロセッサは、前記基地局の分散ユニットによって提供される第1のセルから第2のセルへの無線端末の条件付きモビリティを制御し、前記分散ユニットが前記条件付きモビリティの開始を検出したことに応答して送信する第1のメッセージを受信するよう構成される。
【0012】
第4の態様では、基地局の中央ユニットのための方法は、前記基地局の分散ユニットによって提供される第1のセルから第2のセルへの無線端末の条件付きモビリティを制御すること、及び前記分散ユニットが前記条件付きモビリティの開始を検出したことに応答して送信する第1のメッセージを受信することを含む。
【0013】
第5の態様では、プログラムは、コンピュータに読み込まれた場合に、上述の第2又は第4の態様に係る方法をコンピュータに行わせるための命令群(ソフトウェアコード)を含む。
【発明の効果】
【0014】
上述の態様によれば、条件付きモビリティの実行条件の成立(又は条件付きモビリティの開始)を知ることをCentral Unit(CU)に可能にすることに寄与する装置、方法、及びプログラムを提供できる。
【図面の簡単な説明】
【0015】
図1】第1の実施形態に係る無線通信ネットワークの構成例を示す図である。
図2】第1の実施形態に係る無線通信ネットワークの構成例を示す図である。
図3】第1の実施形態に係る分散ユニットによって行われる処理の一例を示すフローチャートである。
図4】第1の実施形態に係るシグナリングの一例を示すシーケンス図である。
図5】第2の実施形態に係る分散ユニットによって行われる処理の一例を示すフローチャートである。
図6】第3の実施形態に係るシグナリングの一例を示すシーケンス図である。
図7】第3の実施形態に係るシグナリングの一例を示すシーケンス図である。
図8】第4の実施形態に係るシグナリングの一例を示すシーケンス図である。
図9】第4の実施形態に係るシグナリングの一例を示すシーケンス図である。
図10】第5の実施形態に係るシグナリングの一例を示すシーケンス図である。
図11】第5の実施形態に係るシグナリングの一例を示すシーケンス図である。
図12】第6の実施形態に係るシグナリングの一例を示すシーケンス図である。
図13】第6の実施形態に係るシグナリングの一例を示すシーケンス図である。
図14】第7の実施形態に係るシグナリングの一例を示すシーケンス図である。
図15】第8の実施形態に係るシグナリングの一例を示すシーケンス図である。
図16】第9の実施形態に係るDOWNLINK DATA DELIVERY STATUSフレームのフォーマットの一例を示す図である。
図17】幾つかの実施形態に係る中央ノード(e.g., gNB-CU)の構成例を示すブロック図である。
図18】幾つかの実施形態に係る分散ノード(e.g., gNB-DU)の構成例を示すブロック図である。
図19】幾つかの実施形態に係る無線端末の構成例を示すブロック図である。
【発明を実施するための形態】
【0016】
以下では、具体的な実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。
【0017】
以下に説明される複数の実施形態は、独立に実施されることもできるし、適宜組み合わせて実施されることもできる。これら複数の実施形態は、互いに異なる新規な特徴を有している。したがって、これら複数の実施形態は、互いに異なる目的又は課題を解決することに寄与し、互いに異なる効果を奏することに寄与する。
【0018】
以下に示される複数の実施形態は、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とも呼ばれる。
【0019】
<第1の実施形態>
図1は、本実施形態に係る無線通信ネットワークの構成例を示している。本実施形態に係る無線通信ネットワークは、Central Unit(CU)1、及び1又はそれ以上のDistributed Units(DUs)2を含む。CU1及び1又はそれ以上のDUs2は、無線アクセスネットワーク(Radio Access Network(RAN))に配置される。CU1及び1又はそれ以上のDUs2は、基地局(e.g., LTE eNB、又はgNB)として動作する。CU1及び各DU2の間はインタフェース101によって接続される。UE3は、少なくとも1つのエアインタフェース102を介して、少なくとも1つのDU2に接続される。
【0020】
CU1及び1又はそれ以上のDUs2は、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であってもよい。
【0021】
CU1は、gNBのRadio Resource Control(RRC)、Service Data Adaptation Protocol(SDAP)、及びPacket Data Convergence Protocol(PDCP)protocols(又はgNBのRRC及びPDCP protocols)をホストする論理ノードであってもよい。DU2は、gNBのRadio Link Control(RLC)、Medium Access Control(MAC)、及びPhysical(PHY)layersをホストする論理ノードであってもよい。CU1がgNB-CUでありDUs2がgNB-DUsであるなら、インタフェース101はF1インタフェースであってもよい。
【0022】
図2に示されるように、CU1は、Control Plane (CP)Unit(e.g., gNB-CU-CP)11及び1又はそれ以上のUser Plane(UP)Unit(e.g., gNB-CU-UP)12を含んでもよい。この場合、CU-CP11は、コントロールプレーン・インタフェース201(e.g., E1インタフェース)を介してCU-UP12に接続される。さらに、CU-CP11は、コントロールプレーン・インタフェース202(e.g., F1-Cインタフェース)を介して各DU2に接続される。CU-UP12は、ユーザプレーン・インタフェース203(e.g., F1-Uインタフェース)を介して各DU2に接続される。
【0023】
図3は、本実施形態のDU2によって行われる処理の一例を示している。ステップ301では、DU2は、当該DU2によって提供されるセル(第1のセル)から他のセル(第2のセル)へのUE3の条件付きモビリティの開始を検出する。ここで、条件付きモビリティは、条件付きハンドオーバであってもよい。条件付きハンドオーバは、intra-CU intra-DUハンドオーバであってもよいし、intra-CU inter-DUハンドオーバであってもよいし、inter-CUハンドオーバであってもよい。したがって、intra-CU intra-DUハンドオーバの場合、第2のセル(ターゲットセル)は、第1のセル(ソースセル)と同じDU2によって提供されてもよい。intra-CU inter-DUハンドオーバの場合、第2のセル(ターゲットセル)は、第1のセル(ソースセル)を提供するDU2とは異なるがこれと同じCU1に接続された他のDU2によって提供されてもよい。inter-CUハンドオーバの場合、第2のセル(ターゲットセル)は、他のRANノード(e.g., 第1のセル(ソースセル)を提供するDU2とは異なるCU1に接続された他のDU)により提供されてもよい。
【0024】
条件付きハンドオーバと同様の動作は、他の様々なモビリティ・シナリオにも適用されることができる。上述のように、条件付きハンドオーバ(CHO)では、UE3が、ハンドオーバコマンド(又は指示)の受信に応答してではなく、設定された条件の成立に応答してターゲットセルへのアクセス(e.g. ランダムアクセス)を開始する。CHOの実行条件は、例えば、閾値及び対応するtime-to-trigger(TTT)を含む。これに代えて、CHOの実行条件は、ネットワークからの明示的な実行指示(e.g., 所定のシグナリング)の受信であってもよい。この場合、当該実行指示の受信に使用される設定(e.g., 無線パラメータ)のUE3による受信は、CHOの実行条件が当該実行指示の受信であることを、UE3に暗示的に示してもよい。言い換えると、UE3は当該設定(e.g., 無線パラメータ)を受信した場合、それに関連付けられたCHOの実行条件が当該実行指示(e.g., 所定のシグナリング)の受信であると判定(又は理解)してもよい。
【0025】
これと同様に、様々な条件付きモビリティでは、UE3が、モビリティ・コマンド(e.g., RRC Recofiguration for mobility)の受信に応答してではなく、モビリティ・コマンドにより設定された条件(e.g., 閾値及びTTT)の成立に応答して他のセル(第2のセル、ターゲットセル)へのアクセスを開始する。条件付きハンドオーバ(CHO)と同様に、他の条件付きモビリティ(e.g., PSCell change)に対しても、ネットワークからの明示的な実行指示(e.g., 所定のシグナリング)の受信を当該条件付きモビリティの実行条件とすることもできる。さらに、上述のCHOに対する説明は、その他の条件付きモビリティにも適用されることができる。
【0026】
このような条件付きモビリティは、例えば、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)である。UE3は、ハンドオーバ手順(又はReconfiguration with Sync手順)を行うときに、PSCellにランダムアクセスを行う。すなわち、条件付きモビリティは、様々なinter-MN mobility scenarios、intra-MN mobility senarios、 inter-SN mobility scenarios、及びintra-SN mobility scenariosを含む。
【0027】
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)を含む。
【0028】
条件付きPCell change又は条件付きinter-MN handoverは、MN initiated SN changeを伴ってもよい。
【0029】
条件付き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)を介して行われてもよい。
【0030】
条件付き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)を介して行われてもよい。
【0031】
条件付き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)を介して行われてもよい。
【0032】
条件付きIntra-CU PSCell Changeは、条件つきSN Modificationと呼ぶこともできる。Intra-CU PSCell Changeは、同一のSN内でのSCGの設定変更の一例である。このような同一のSN内でのSCGの設定変更は、SN initiated SN Modification with (or without) MN involvement手順を使用する。
【0033】
PSCell Change手順は、Reconfiguration with sync手順を伴う手順の一例である。このことから、条件付きPSCell Changeは、条件付きReconfiguration with sync(for PSCell change)と呼ぶこともできる。
【0034】
幾つかの実装では、DU2は、条件付きモビリティの表示(indication)(e.g., measurement report)をUE3から受信したことによって条件付きモビリティの開始(又は実行)を検出してもよい。これに代えて、DU2は、条件付きモビリティの開始(又は実行)の条件の成立を自律的に判定し、これにより条件付きモビリティの開始(又は実行)を自律的に検出してもよい。
【0035】
ステップ302では、DU2は、条件付きモビリティの開始の検出に応答して、当該DU2が関連付けられているCU1に所定のメッセージを送信する。したがって、当該所定のメッセージは、UE3による条件付きモビリティの開始(又は実行)に関連付けられる。当該所定のメッセージは、これに限定されないが例えば、条件付きモビリティの開始を明示してもよい。
【0036】
図4は、本実施形態に係るシグナリングの一例を示している。ステップ401では、DU2は、CU1に、条件付きモビリティの開始に関連付けられた所定のメッセージ(e.g., F1APメッセージ)を送信する。
【0037】
以上の説明から理解されるように、本実施形態では、DU2は、条件付きモビリティの開始の検出に応答して、当該DU2が関連付けられているCU1に所定のメッセージを送信する。これにより、CU1は、条件付きモビリティの開始を知ることができる。
【0038】
幾つかの条件付きモビリティ・シナリオ(e.g., Intra-CU Inter-DU ハンドオーバ、及びIntra-CU Inter-DU PSCell Change)では、CU1は、条件付きモビリティの開始(又は実行)の直前までソースDU2を介してUE3のためのデータ伝送(ダウンリンク、又はアップリンク、又は両方)を継続できることが好ましいかもしれない。本実施形態で説明された動作によれば、CU1は、ソースDU2からの所定のメッセージの受信によって、条件付きモビリティの開始(又は実行)を知ることができる。したがって、例えば、CU1は、所定のメッセージを受信するまでソースDU2を介してUE3のためのデータ伝送(ダウンリンク、又はアップリンク、又は両方)を継続するよう動作してもよい。
【0039】
なお、幾つかの実装では、上述の所定のメッセージは、DU2からCU1に送られる既存のメッセージ又はデータと共通であってもよい。例えば、所定のメッセージは、UE3に関するUEコンテキストの変更のためのシグナリング手順において送信されるメッセージ(e.g., F1APメッセージ)であってもよい。より具体的には、当該所定のメッセージは、UE Context Modification手順で送信されるUE CONTEXT MODIFICATION RESPONSEメッセージであってもよい。
【0040】
所定のメッセージは、UE3へ送信されていないダウンリンクデータを示すためにCU1に送信されるメッセージ(又はフレーム、又はProtocol Data Unit(PDU))であってもよい。より具体的には、当該所定のメッセージは、DOWNLINK DATA DELIVERY STATUS(DDDS)フレームであってもよい。
【0041】
これに代えて、幾つかの実装では、上述の所定のメッセージは、条件付きモビリティの開始を示すために新規に規定されたメッセージ又はデータ(e.g., F1APメッセージ)であってもよい。例えば、ソースDU2は、UE CONTEXT MODIFICATION RESPONSEメッセージをCU1に送り、さらにDDDSフレームをCU1に送り、その後に、条件付きモビリティの開始を示すために新規に規定されたメッセージ又はデータをさらにCU1に送信してもよい。ソースDU2は、新規メッセージ又はデータをCU1に送信するとき、再度DDDSフレームをCU1に送ってもよい。
【0042】
<第2の実施形態>
本実施形態は、条件付きモビリティのために改良されたDUの動作を提供する。本実施形態に係る無線通信ネットワークの構成例は、図1及び図2に示された例と同様であってもよい。
【0043】
図5は、本実施形態のDU2によって行われる処理の一例を示している。ステップ501では、DU2は、UE3の計画されている(planned)モビリティが条件付きモビリティであるかを判定する。DU2は、CU1から受信した制御メッセージが条件付きモビリティに関連付けられた情報要素を含むか否かに基づいて、UE3の計画されているモビリティが条件付きモビリティであるかを判定してもよい。これに代えて、DU2は、CU1から受信した制御メッセージに包含されている情報要素が条件付きモビリティ(又は条件付きモビリティがUE3に計画されていること)を示すか否かに基づいて、UE3の計画されているモビリティが条件付きモビリティであるかを判定してもよい。
【0044】
当該制御メッセージ(又はこれに包含される情報要素)は、UE3の計画されているモビリティが条件付きモビリティであることを明示的に示してもよいし暗示的に示してもよい。当該情報要素は、例えば、条件付きモビリティの開始(又は実行)の条件を示す情報要素であってもよい。当該情報要素は、条件付きモビリティを示す何らかの表示(例えば、条件付きモビリティ情報要素(IE)又は条件付きモビリティ・フラグ(ビット))であってもよい。
【0045】
幾つかの実装では、当該制御メッセージは、UE3に関するUEコンテキストの変更のためのシグナリング手順において送信されるメッセージ(e.g., F1APメッセージ)であってもよい。より具体的には、当該所定のメッセージは、UE Context Modification手順で送信されるUE CONTEXT MODIFICATION REQUESTメッセージであってもよい。
【0046】
ステップ502では、DU2は、計画されているモビリティが条件付きモビリティである場合に、計画されているモビリティが条件付きモビリティでない場合(通常のモビリティ(e.g., ハンドオーバ)の場合)に比べて、所定のメッセージのCU1への送信を遅らせる。
【0047】
幾つかの実装では、当該所定のメッセージは、UE3に関するUEコンテキストの変更のためのシグナリング手順において送信されるメッセージ(e.g., F1APメッセージ)であってもよい。より具体的には、当該所定のメッセージは、UE Context Modification手順で送信されるUE CONTEXT MODIFICATION RESPONSEメッセージであってもよい。通常の(つまり条件付きでない)UEモビリティでは、DU2は、CU1からのUE CONTEXT MODIFICATION REQUESTメッセージの受信に応答して、要求された修正(modifications)を実行し、更新(update)をUE CONTEXT MODIFICATION RESPONSEメッセージにおいて報告する。これとは対照的に、条件付きUEモビリティでは、DU2は、CU1からUE CONTEXT MODIFICATION REQUESTメッセージを受信し、要求された修正(modifications)を保留してもよい。そして、DU2は、条件付きモビリティの開始条件の成立に応答して、要求された修正を実行し、更新(update)をUE CONTEXT MODIFICATION RESPONSEメッセージにおいて報告してもよい。
【0048】
これに代えて、幾つかの実装では、当該所定のメッセージは、UE3へ送信されていないダウンリンクデータを示すためにCU1に送信されるメッセージ(又はフレーム、又はProtocol Data Unit(PDU))であってもよい。より具体的には、当該所定のメッセージは、DOWNLINK DATA DELIVERY STATUS(DDDS)フレームであってもよい。DDDSフレームは、GTP-U(又はF1-U)PDUであってもよい。通常の(つまり条件付きでない)UEモビリティでは、DU2は、CU1からのUE CONTEXT MODIFICATION REQUESTメッセージ(UE3のためのデータ送信の停止を示すTransmission Stop Indicator 情報要素を含む)の受信に応答して、DDDSフレームをCU1に送信する。これとは対照的に、条件付きUEモビリティでは、DU2は、CU1からUE CONTEXT MODIFICATION REQUESTメッセージを受信した後も、UE3のためのデータ送信を継続してもよい。そして、DU2は、条件付きモビリティの開始条件の成立に応答して、UE3のためのデータ送信を停止し、DDDSフレームをCU1に送信してもよい。
【0049】
DDDSフレームは、条件付きモビリティの開始(又は実行)を示す新たな情報(e.g., ビット)を包含してもよい。これに代えて、DU2は、通常の(つまり条件付きでない)UEモビリティで使用されるDDDSフレームを再利用しつつ、DU2からCU1に条件付きモビリティの開始(又は実行)を示すための新たに規定されるメッセージを送信してもよい。当該メッセージは、CONDITIONAL MOBILITY (又はHANDOVER, PSCell CHANGE, or RECONFIGURATION WITH SYNC) TRIGGERED (又はINITIATED, DETECTED, INDICATION, or INSTRUCTION)メッセージと呼ばれてもよい。このとき、DU2は、DDDSフレームを当該メッセージの後に送ってもよいし、当該メッセージの前に送ってもよい。
【0050】
本実施形態では、DU2は、UE3の計画されているモビリティが条件付きモビリティである場合に、計画されているモビリティが条件付きモビリティでない場合に比べて、所定のメッセージのCU1への送信を遅らせる。具体的には、例えば、DU2は条件付きモビリティの開始条件が成立するまで(又は、成立したことを検出するまで)、当該所定のメッセージのCU1への送信を保留(又は延期)してもよい。したがって、当該所定のメッセージは、条件付きモビリティの開始(又は実行)をCU1に報告する用途を兼ねることができる。言い換えると、CU1は、当該所定のメッセージを受信することで、UE3が条件付きモビリティを開始(又は実行)したことを知ることができる。
【0051】
<第3の実施形態>
本実施形態は、条件付きモビリティのためのシグナリングの具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図1及び図2に示された例と同様であってもよい。
【0052】
図6は、intra-CU inter-DU条件付きハンドオーバ(CHO)手順の一例を示している。なお、図6の手順は、SCGのSRB(e.g., SRB3)を使用する条件付きPSCell changeのために使用されてもよい。言い換えると、図6の手順は、Inter-gNB-DU Mobility using SCG SRBのために使用されてもよい。
【0053】
図6の手順よりも前に、CU1は、CHOのための報告設定(e.g., ReportConfig)を包含する測定設定(e.g., MeasConfig)を含むRRCメッセージ(e.g., RRCReconfigurationメッセージ)を生成し、これをソースDU2A経由でUE3へ送信してもよい。CHOのための測定設定は、CHO判定のために早いイベント・トリガリング(つまり、UE3による測定報告をトリガーする閾値を下げること)を可能にする。DU2Aは、測定設定を含むRRCメッセージを受信するが、当該RRCメッセージに測定設定が含まれていることを認識しなくてもよい。言い換えると、DU2AはCU1から受信する測定設定を透過的に(transparently)UE3へ転送してもよい。他の実施形態を含む以降の説明でも、同様である。DU2Aは、測定設定以外の他の情報を含むCU1からUE3へ送信されるRRCメッセージも同様に扱ってもよい。
【0054】
ステップ601では、UE3は、測定報告(Measurement Report)をソースDU2Aに送る。ステップ602では、ソースDU2Aは、受信した測定報告を運ぶためにUPLINK RRC TRANSFERメッセージをCU1に送る。CU1は、当該測定報告に基づいて、ソースDU2AのセルからターゲットDU2BのセルへのUE3のCHOを決定する。DU2Aは、測定報告を含むRRCメッセージを受信するが、当該RRCメッセージに測定報告が含まれていることを認識しなくてもよい。言い換えると、DU2AはUE3から受信する測定報告を透過的に(transparently)CU1へ転送してもよい。他の実施形態を含む以降の説明でも、同様である。DU2Aは、測定報告以外の他の情報を含むUE3からCU1へ送信されるRRCメッセージについても同様に扱ってもよい。
【0055】
ステップ603では、CU1は、UEコンテキストを作成し且つ1又はそれ以上のベアラをセットアップするために、UE CONTEXT SETUP REQUESTメッセージをターゲットDU2Bに送る。UE CONTEXT SETUP REQUESTメッセージは、CHOのためのターゲットセルの無線リソースの設定(e.g., CellGroupConfig)をターゲットDU2Bに要求してもよい。CHO要求であることを示すために、UE CONTEXT SETUP REQUESTメッセージ内の“CU to DU RRC Information”情報要素に包含されている“Handover Preparation Information”情報要素が使用されてもよい。これに代えて、CHO要求であることを示すために、UE CONTEXT SETUP REQUESTメッセージ内に新たな情報要素が定義されてもよい。
【0056】
ステップ604では、ターゲットDU2Bは、UE CONTEXT SETUP RESPONSEメッセージによりCU1に応答する。ターゲットDU2Bは、CHO要求の受信に応答して、CHOを受け入れ可能であるか否かを判定してもよい。ターゲットDU2Bは、CHOを受け入れ可能であるか否かを示す情報要素をUE CONTEXT SETUP RESPONSEメッセージ(ステップ604)に含めてもよい。
【0057】
ステップ605では、CU1は、CU1によって生成されたRRCメッセージ(e.g., RRCReconfigurationメッセージ)を包含するRRC-Containerを含むUE CONTEXT MODIFICATION REQUESTメッセージをソースDU2Aに送る。当該RRCメッセージは、CHOの開始(又は実行)条件(e.g., 閾値及びTTT)を含む。さらに、当該RRCメッセージは、UE3がCHOを離れる(exit)条件(e.g., offset)、及び有効(validity)タイマの値を含んでもよい。有効タイマの値は、候補ターゲットセルのリソースがいつまで有効であるかを示してもよい。あるいは、有効タイマの値は、候補ターゲットセルへのアクセスが許可される期間(時間)、又はCHOのための設定が有効な期間(時間)を示してもよい。
【0058】
UE CONTEXT MODIFICATION REQUESTメッセージ(ステップ605)は、これがUE3へのCHOの指示(つまり、CHOによるハンドオーバに必要なRRC設定情報)を含むこと、又はこれがCHOを意図していることを明示的又は暗示的に示す情報要素(IE)を含んでもよい。DU2Aは、受信したUE CONTEXT MODIFICATION REQUESTメッセージが当該IEを含むか否かを判定してもよい。例えば、DU2Aが、CHOであると判定した場合、後続の動作を決定してもよい。
【0059】
より具体的には、CU1は、CHOの開始条件を決定し、これをUE CONTEXT SETUP REQUESTメッセージ(ステップ603)に包含されるCU To DU RRC Information情報要素(e.g., この中のHandover Preparation Information)又は新規な情報要素に含めてもよい。そして、ターゲットDU2Bは、CHOの開始条件を包含するターゲットセルの無線リソースの設定(e.g., CellGroupConfig)を生成し、これをUE CONTEXT SETUP RESPONSEメッセージ(ステップ604)に含めてもよい。さらに、CU1は、受信した無線リソースの設定(e.g., CellGroupConfig)を包含するRRCReconfigurationメッセージを生成し、これをUE CONTEXT MODIFICATION REQUESTメッセージ(ステップ605)内のRRC-Containerに含めてもよい。
【0060】
これに代えて、CU1は、CHOの開始条件を決定し、これをUE CONTEXT MODIFICATION REQUESTメッセージ(ステップ605)内の新規情報要素に含めてもよい。
【0061】
さらにこれに代えて、ターゲットDU2BがCHOの開始条件を決定してもよい。この場合、ターゲットDU2Bは、CHO要求(ステップ603)に応答してCHOの開始条件を決定し、決定したCHOの開始条件をUE CONTEXT SETUP RESPONSEメッセージ(ステップ604)内のCellGroupConfig情報要素又は新規情報要素に含めてもよい。そして、CU1は、CHOの開始条件を含むCellGroupConfig情報要素又は新規情報要を包含するRRCReconfigurationメッセージを生成し、これをUE CONTEXT MODIFICATION REQUESTメッセージ(ステップ605)に含めてもよい。CU1は、CHOの指示を明示的に示す情報要素(IE)又はパラメータを、RRCReconfigurationメッセージに含めてもよい。
【0062】
CHOの開始条件に加えて、UE3がCHOを離れる(exit)条件、及び有効(validity)タイマの値も、CHOの開始条件と同様に取り扱われてもよい。これに代えて、CHOの開始条件、CHOを離れる条件、及び有効タイマの値それぞれが、上述のいずれかの方法によって取り扱われてもよい。
【0063】
ステップ606では、ソースDU2Aは、受信したRRCReconfigurationメッセージをUE3にフォワードする。
【0064】
UE3は、RRCReconfigurationメッセージ(ステップ606)を受信すると、これがCHOの指示であることを示す情報要素(IE)又はパラメータを含むか否か、又はこれがCHOの開始条件を含むか否かに応じて、CHOの指示であるか否かを判定する。UE3は、CHOの指示であると判定した場合、当該RRCReconfigurationメッセージの受信後もソースDU2Aとのコネクションを維持する。UE3は、RRCReconfigurationメッセージにより設定されたCHOの実行条件が成立したことに応じて(ステップ607)、ターゲットDU2Bへのアクセス(i.e., ランダムアクセス手順)を開始する(ステップ610)。UE3は、CHO開始の表示(又は報告)をソースDU2Aに送信してもよい(ステップ608)。
【0065】
UE3によるCHO開始の表示は、Physical Uplink Control Channel(PUCCH)で送信されるアップリンク制御情報(Uplink Control Information(UCI))であってもよい。これに代えて、CHO開始の表示は、MAC Control Element(CE)であってもよい。ソースDU2Aは、CHO開始の表示に用いられる無線リソースの設定を予め決定し、これをCU1を介してUE3に通知してもよい。例えば、ソースDU2Aは、CHO開始の表示に用いられる無線リソースの設定をUE CONTEXT SETUP RESPONSEメッセージに包含される情報(e.g., CellGroupConfig)に含め、これをCU1へ送信してもよい。そして、CU1は、CHO開始の表示に用いられる無線リソースの設定を含むRRCReconfigurationメッセージを生成し、これをUE3へ送信してもよい。複数の候補ターゲットセルがある場合、CHO開始の表示は、選択された候補ターゲットセル(つまり、ハンドオーバがトリガされた候補ターゲットセル)を明示的又は暗示的に示す情報を含んでもよい。
【0066】
ステップ609では、ソースDU2Aは、UE CONTEXT MODIFICATION RESPONSEメッセージによりCU1に応答する。一例では、ソースDU2Aは、CHO開始の表示(ステップ608)をUE3から受信したことに応答して、UE CONTEXT MODIFICATION RESPONSEメッセージ(ステップ609)を送信してもよい。この場合、UE CONTEXT MODIFICATION RESPONSEメッセージは、CHOの開始(又は実行)をCU1に報告する用途を兼ねることができる。他の例では、ソースDU2Aは、CHO開始の表示(ステップ608)の受信と無関係に、UE CONTEXT MODIFICATION RESPONSEメッセージ(ステップ609)を送信してもよい。ソースDU2Aは、CHO開始の表示(ステップ608)の受信よりも前に、UE CONTEXT MODIFICATION RESPONSEメッセージ(ステップ609)を送信してもよい。
【0067】
図6には示されていないが、ランダムアクセス手順(ステップ610)に成功した後に、UE3は、RRCReconfigurationCompleteメッセージによってターゲットDU2Bを介してCU1に応答してもよい。ターゲットDU2Bは、UE3から受信したRRCReconfigurationCompleteメッセージを運ぶためにUPLINK RRC TRANSFERメッセージをCU1に送ってもよい。そして、CU1は、UE CONTEXT RELEASE COMMANDメッセージをソースDU2Aに送信してもよい。このとき、UE CONTEXT RELEASE COMMANDメッセージに付される(又は含まれる)解放Cause値は、例えば、“Handover Condition Met”、“Action Desirable for Radio Reasons”、“Handover Complete”、又は“Normal Release”であってもよい。ソースDU2Aは、UE3に関するUEコンテキストを解放し、UE CONTEXT RELEASE COMPLETEメッセージによってCU1に応答してもよい。
【0068】
図7は、intra-CU inter-DU条件付きハンドオーバ(CHO)手順の他の例を示している。図7の手順は、SCGのSRB(e.g., SRB3)を使用する条件付きPSCell changeのために使用されてもよい。ステップ701~706の処理は、図6のステップ601~606のそれと同様である。ステップ707では、ソースDU2Aは、UE CONTEXT MODIFICATION RESPONSEメッセージによりCU1に応答する。
【0069】
ステップ708では、UE3は、RRCReconfigurationメッセージにより設定されたCHOの実行条件の成立を判定し、ターゲットDU2Bへのアクセス(i.e., ランダムアクセス手順)を開始する(ステップ711)。UE3は、CHO開始の表示(又は報告)をソースDU2Aに送信してもよい(ステップ709)。UE3によるCHO開始の表示は、PUCCHで送信されるアップリンク制御情報(UCI)であってもよい。これに代えて、CHO開始の表示は、MAC CEであってもよい。
【0070】
ステップ710では、ソースDU2Aは、DDDSフレームをCU1に送信する。一例では、ソースDU2Aは、CHO開始の表示(ステップ709)をUE3から受信したことに応答して、DDDSフレーム(ステップ710)を送信してもよい。この場合、DDDSフレームは、CHOの開始(又は実行)をCU1に報告する用途を兼ねることができる。これに代えて、ソースDU2Aは、通常の(つまり条件付きでない)ハンドオーバで使用されるDDDSフレームを送信しつつ、CU1にCHO開始(又は実行)を示すための新たなメッセージをさらに送信してもよい(図示なし)。当該メッセージは、CONDITIONAL HANDOVER TRIGGERED (又はINITIATED, DETECTED, INDICATION, or INSTRUCTION)メッセージと呼ばれてもよい。他の例では、ソースDU2Aは、CHO開始の表示(ステップ709)の受信と無関係に、DDDSフレーム(ステップ710)を送信してもよい。ソースDU2Aは、CHO開始の表示(ステップ709)の受信よりも前に、DDDSフレーム(ステップ710)を送信してもよい。
【0071】
図7には示されていないが、ランダムアクセス手順(ステップ711)に成功した後に、UE3は、RRCReconfigurationCompleteメッセージによってターゲットDU2Bを介してCU1に応答してもよい。ターゲットDU2Bは、UE3から受信したRRCReconfigurationCompleteメッセージを運ぶためにUPLINK RRC TRANSFERメッセージをCU1に送ってもよい。そして、CU1は、UE CONTEXT RELEASE COMMANDメッセージをソースDU2Aに送信してもよい。このとき、UE CONTEXT RELEASE COMMANDメッセージに付される(又は含まれる)解放Cause値は、例えば、“Handover Condition Met”、“Action Desirable for Radio Reasons”、“Handover Complete”、又は“Normal Release”であってもよい。ソースDU2Aは、UE3に関するUEコンテキストを解放し、UE CONTEXT RELEASE COMPLETEメッセージによってCU1に応答してもよい。
【0072】
本実施形態で説明された幾つかの手順は、intra-CU inter-DU条件付きハンドオーバを可能にする。
【0073】
<第4の実施形態>
本実施形態は、条件付きモビリティのためのシグナリングの具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図1及び図2に示された例と同様であってもよい。
【0074】
図8は、intra-CU inter-DU条件付きハンドオーバ(CHO)手順の一例を示している。図8の手順は、SCGのSRB(e.g., SRB3)を使用する条件付きPSCell changeのために使用されてもよい。ステップ801~806の処理は、図6のステップ601~606のそれと同様である。
【0075】
ステップ807では、ソースDU2Aは、CHOの実行条件の成立を自律的に判定する。ステップ808では、ソースDU2Aは、CHOの実行条件の成立に応答して、CHO開始コマンドをUE3に送る。CHO開始コマンドは、Physical Downlink Control Channel(PDCCH)で送信されるダウンリンク制御情報(Downlink Control Information(DCI))であってもよい。これに代えて、CHO開始コマンドは、MAC Control Element(CE)であってもよい。ソースDU2Aは、CHO開始コマンドに用いられる無線リソースの設定を予め決定し、これをCU1を介してUE3に通知してもよい。例えば、ソースDU2Aは、CHO開始コマンドに用いられる無線リソースの設定をUE CONTEXT SETUP RESPONSEメッセージに包含される情報(e.g., CellGroupConfig)に含め、これをCU1へ送信してもよい。そして、CU1は、CHO開始コマンドに用いられる無線リソースの設定を含むRRCReconfigurationメッセージを生成し、これをUE3へ送信してもよい。複数の候補ターゲットセルがある場合、CHO開始コマンドは、選択された候補ターゲットセル(つまり、ハンドオーバがトリガされた候補ターゲットセル)を明示的又は暗示的に示す情報を含んでもよい。
【0076】
ステップ809では、ソースDU2Aは、UE CONTEXT MODIFICATION RESPONSEメッセージによりCU1に応答する。一例では、ソースDU2Aは、CHOの実行条件の成立に応答して、UE CONTEXT MODIFICATION RESPONSEメッセージ(ステップ809)を送信してもよい。この場合、UE CONTEXT MODIFICATION RESPONSEメッセージは、CHOの開始(又は実行)をCU1に報告する用途を兼ねることができる。他の例では、ソースDU2Aは、CHOの実行条件の成立と無関係に、UE CONTEXT MODIFICATION RESPONSEメッセージ(ステップ809)を送信してもよい。ソースDU2Aは、CHOの実行条件の成立よりも前に、UE CONTEXT MODIFICATION RESPONSEメッセージ(ステップ809)を送信してもよい。
【0077】
ステップ810では、UE3は、CHO開始コマンドの受信に応答して、ターゲットDU2Bへのアクセス(i.e., ランダムアクセス手順)を開始する。
【0078】
図8には示されていないが、ランダムアクセス手順(ステップ810)に成功した後に、UE3は、RRCReconfigurationCompleteメッセージによってターゲットDU2Bを介してCU1に応答してもよい。ターゲットDU2Bは、UE3から受信したRRCReconfigurationCompleteメッセージを運ぶためにUPLINK RRC TRANSFERメッセージをCU1に送ってもよい。そして、CU1は、UE CONTEXT RELEASE COMMANDメッセージをソースDU2Aに送信してもよい。ソースDU2Aは、UE3に関するUEコンテキストを解放し、UE CONTEXT RELEASE COMPLETEメッセージによってCU1に応答してもよい。
【0079】
図9は、intra-CU inter-DU条件付きハンドオーバ(CHO)手順の他の例を示している。図9の手順は、SCGのSRB(e.g., SRB3)を使用する条件付きPSCell changeのために使用されてもよい。ステップ901~906の処理は、図8のステップ801~806のそれと同様である。ステップ907では、ソースDU2Aは、UE CONTEXT MODIFICATION RESPONSEメッセージによりCU1に応答する。
【0080】
ステップ908では、ソースDU2Aは、CHOの実行条件の成立を自律的に判定する。ステップ909では、ソースDU2Aは、CHOの実行条件の成立に応答して、CHO開始コマンドをUE3に送る。CHO開始コマンドは、PDCCHで送信されるDCIであってもよい。これに代えて、CHO開始コマンドは、MAC CEであってもよい。
【0081】
ステップ910では、ソースDU2Aは、DDDSフレームをCU1に送信する。一例では、ソースDU2Aは、CHOの実行条件の成立に応答して、DDDSフレーム(ステップ910)を送信してもよい。この場合、DDDSフレームは、CHOの開始(又は実行)をCU1に報告する用途を兼ねることができる。これに代えて、ソースDU2Aは、通常の(つまり条件付きでない)ハンドオーバで使用されるDDDSフレームを送信しつつ、CU1にCHO開始(又は実行)を示すための新たなメッセージを送信してもよい(図示なし)。当該メッセージは、CONDITIONAL HANDOVER TRIGGERED (又はINITIATED, DETECTED, INDICATION, or INSTRUCTION)メッセージと呼ばれてもよい。他の例では、ソースDU2Aは、CHOの実行条件の成立と無関係に、DDDSフレーム(ステップ910)を送信してもよい。ソースDU2Aは、CHOの実行条件の成立よりも前に、DDDSフレーム(ステップ910)を送信してもよい。
【0082】
図9には示されていないが、ランダムアクセス手順(ステップ911)に成功した後に、UE3は、RRCReconfigurationCompleteメッセージによってターゲットDU2Bを介してCU1に応答してもよい。ターゲットDU2Bは、UE3から受信したRRCReconfigurationCompleteメッセージを運ぶためにUPLINK RRC TRANSFERメッセージをCU1に送ってもよい。そして、CU1は、UE CONTEXT RELEASE COMMANDメッセージをソースDU2Aに送信してもよい。このとき、UE CONTEXT RELEASE COMMANDメッセージに付される(又は含まれる)解放Cause値は、例えば、“Handover Condition Met”、“Action Desirable for Radio Reasons”、“Handover Complete”、又は“Normal Release”であってもよい。ソースDU2Aは、UE3に関するUEコンテキストを解放し、UE CONTEXT RELEASE COMPLETEメッセージによってCU1に応答してもよい。
【0083】
本実施形態で説明された幾つかの手順は、intra-CU inter-DU条件付きハンドオーバを可能にする。
【0084】
<第5の実施形態>
本実施形態は、条件付きモビリティのためのシグナリングの具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図1及び図2に示された例と同様であってもよい。
【0085】
図10は、intra-CU inter-DU 条件付きPSCell Change手順の一例を示している。既に述べたように、条件付きPSCell Changeは、条件付きReconfiguration with sync(for PSCell change)と呼ぶこともできる。図10は、MR-DCでのPSCell ChangeにMN4(e.g., Master eNB(MeNB))が関与(involve)するケースを示している。図10の例では、UE3のためのPSCellがソースDU2AのセルからターゲットDU2Bのセルに変更される。PSCell ChangeのためにSN(i.e., CU1)とUE3との間で送信されるRRCシグナリングは、MN4によって提供されるMCG内のSRBを使用する。
【0086】
図10の手順よりも前に、CU1は、条件付きPSCell Changeのための報告設定(e.g., ReportConfig)を包含する測定設定(e.g., MeasConfig)を含むRRCメッセージ(e.g., RRCReconfigurationメッセージ)を生成し、これをMN4により提供されるMCG SRB経由でUE3へ送信してもよい。条件付きPSCell Changeのための測定設定は、条件付きPSCell Change判定のために早いイベント・トリガリング(つまり、UE3による測定報告をトリガーする閾値を下げること)を可能にする。
【0087】
ステップ1001及び1002では、UE3は、測定報告(Measurement Report)をMN4を介してCU1に送る。ステップ1002では、MN4は、受信した測定報告を運ぶためにRRC TRANSFERメッセージをCU1に送る。CU1は、当該測定報告に基づいて、ソースDU2AのセルからターゲットDU2BのセルへのUE3の条件付きモビリティ(i.e., 条件付きPSCell change)を決定する。
【0088】
ステップ1003では、CU1は、UEコンテキストを作成し且つ1又はそれ以上のベアラをセットアップするために、UE CONTEXT SETUP REQUESTメッセージをターゲットDU2Bに送る。UE CONTEXT SETUP REQUESTメッセージは、PSCellの無線リソースの設定(e.g., CellGroupConfig)をターゲットDU2Bに要求してもよい。条件付きモビリティ(i.e., 条件付きPSCell change)の要求であることを明示的に又は暗示的に示すために、UE CONTEXT SETUP REQUESTメッセージ内の“CU to DU RRC Information”情報要素に包含されている“CG-ConfigInfo”情報要素が使用されてもよい。これに代えて、条件付きモビリティ要求であることを明示的に又は暗示的に示すために、UE CONTEXT SETUP REQUESTメッセージ内に新たな情報要素が定義(又は導入)されてもよい。
【0089】
ステップ1004では、ターゲットDU2Bは、UE CONTEXT SETUP RESPONSEメッセージによりCU1に応答する。ターゲットDU2Bは、条件付きモビリティ要求の受信に応答して、条件付きモビリティ(i.e., 条件付きPSCell change)を受け入れ可能であるか否かを判定してもよい。ターゲットDU2Bは、条件付きモビリティを受け入れ可能であるか否かを示す情報要素をUE CONTEXT SETUP RESPONSEメッセージ(ステップ1004)に含めてもよい。
【0090】
ステップ1005では、CU1は、CU1によって生成されたSN RAT(e.g., NR)のRRCメッセージ(e.g., NR RRCReconfigurationメッセージ)を含むSN MODIFICATION REQUIREDメッセージをMN4に送る。当該RRCメッセージは、条件付きモビリティ(i.e., 条件付きPSCell change、又は条件付きReconfiguration with sync for PSCell change)の開始(又は実行)条件を含む。既に説明したように、条件付きビリティの開始(又は実行)条件は、例えば、閾値及びTTTであってもよい。これに代えて、条件付きビリティの開始(又は実行)条件は、ネットワークからの明示的な実行指示(e.g., 所定のシグナリング)の受信であってもよい。この場合、当該実行指示の受信に使用される設定(e.g., 無線パラメータ)のUE3による受信は、条件付きモビリティの開始(又は実行)条件が当該実行指示の受信であることを、UE3に暗示的に示してもよい。言い換えると、UE3は当該設定(e.g., 無線パラメータ)を受信した場合、それに関連付けられた条件付きモビリティの開始(又は実行)条件が当該実行指示(e.g., 所定のシグナリング)の受信であると判定(又は理解)してもよい。
【0091】
さらに、当該RRCメッセージは、UE3が条件付きPSCell changeを離れる(exit)条件(e.g., offset)、及び有効(validity)タイマの値を含んでもよい。有効タイマの値は、候補ターゲットセル(つまり変更後のPSCellの候補となるセル)のリソースがいつまで有効であるかを示してもよい。あるいは、有効タイマの値は、候補ターゲットセルへのアクセスが許可される期間(時間)、又は条件付きモビリティのための設定が有効な期間(時間)を示してもよい。
【0092】
より具体的には、CU1は、条件付きモビリティの開始条件を決定し、これをUE CONTEXT SETUP REQUESTメッセージ(ステップ1003)に包含されるCG-ConfigInfo情報要素又は新規な情報要素に含めてもよい。そして、ターゲットDU2Bは、条件付きモビリティの開始条件を包含する無線リソースの設定(e.g., CellGroupConfig)を生成し、これをUE CONTEXT SETUP RESPONSEメッセージ(ステップ1004)に含めてもよい。さらに、CU1は、受信した無線リソースの設定(e.g., CellGroupConfig)を包含するSN RATのRRCメッセージを生成し、これをSN MODIFICATION REQUIREDメッセージ(ステップ1005)に含めてもよい。
【0093】
これに代えて、CU1は、条件付きモビリティの開始条件を決定し、これをSN MODIFICATION REQUIREDメッセージ(ステップ1005)内の新規情報要素に含めてもよい。
【0094】
さらにこれに代えて、ターゲットDU2Bが条件付きモビリティの開始条件を決定してもよい。この場合、ターゲットDU2Bは、条件付きモビリティ要求(ステップ1003)に応答して条件付きモビリティの開始条件を決定し、決定した開始条件をUE CONTEXT SETUP RESPONSEメッセージ(ステップ1004)内のCellGroupConfig情報要素又は新規情報要素に含めてもよい。そして、CU1は、条件付きモビリティの開始条件を含むCellGroupConfig情報要素又は新規情報要を包含するSN RATのRRCメッセージを生成し、これをSN MODIFICATION REQUIREDメッセージ(ステップ1005)に含めてもよい。
【0095】
もしデータフォワーディング若しくはSNセキュリティキーの変更又は両方が適用される必要があるなら、MN4は、MN initiated SN Modification手順を行い、フォワーディングアドレス若しくは新たなSNセキュリティキー情報又は両方をSN Modification Requestメッセージを用いてCU1に適用してもよい。
【0096】
ステップ1006では、CU1は、UE CONTEXT MODIFICATION REQUESTメッセージをソースDU2Aに送る。当該メッセージは、条件付きモビリティ(i.e., 条件付きPSCell change)の表示を含む。
【0097】
ステップ1007では、MN4は、MCG SRBを介したMN RAT(e.g., LTE)のRRC再設定手順(e.g., LTE RRC Connection Reconfigurtion手順)を行い、CU1から受信したSN RATのRRCメッセージをUE3にフォワードする。UE3は、CU1宛てのSN RATのRRC応答メッセージ(e.g., NR RRC Reconfiguration Completeメッセージ)を包含するMN RATのRRCメッセージ(e.g., LTE RRC Connection Reconfiguration Completeメッセージ)をMN4に送信する。
【0098】
ステップ1008では、MN4は、MN RATのRRC再設定手順の成功裏の完了に応じて、SN MODIFICATION CONFIRMメッセージによりCU1に応答する。当該SN MODIFICATION CONFIRMメッセージは、UE3から受信したSN RATのRRC応答メッセージ(e.g., NR RRC Reconfiguration Completeメッセージ)を包含する。
【0099】
UE3は、SN RATのRRCメッセージ(ステップ1007)の受信後もソースDU2Aとのコネクションを維持する。UE3は、SN RATのRRCメッセージにより設定された条件付きモビリティ(i.e., 条件付きReconfiguration with sync)の実行条件が成立したことに応じて(ステップ1009)、新たな設定を適用し、ターゲットDU2Bへのアクセス(i.e., ランダムアクセス手順)を開始する(ステップ1012)。UE3は、条件付きモビリティ開始の表示(又は報告)をソースDU2Aに送信してもよい(ステップ1010)。UE3による条件付きモビリティ開始の表示は、PUCCHで送信されるアップリンク制御情報(UCI)であってもよい。これに代えて、条件付きモビリティ開始の表示は、MAC CEであってもよい。ソースDU2Aは、CHO開始の表示に用いられる無線リソースの設定を予め決定し、これをCU1を介してUE3に通知してもよい。例えば、ソースDU2Aは、条件付きモビリティ開始の表示に用いられる無線リソースの設定をUE CONTEXT SETUP RESPONSEメッセージに包含される情報(e.g., CellGroupConfig)に含め、これをCU1へ送信してもよい。そして、CU1は、条件付きモビリティ開始の表示に用いられる無線リソースの設定を含むRRCReconfigurationメッセージを生成し、これをUE3へ送信してもよい。複数の候補ターゲットセル(e.g., PSCell候補)がある場合、条件付きモビリティ開始の表示は、選択された候補ターゲットセル(e.g., PSCell changeがトリガされた候補ターゲットセル)を明示的又は暗示的に示す情報を含んでもよい。
【0100】
ステップ1011では、ソースDU2Aは、UE CONTEXT MODIFICATION RESPONSEメッセージによりCU1に応答する。一例では、ソースDU2Aは、条件付きモビリティ開始の表示(ステップ1010)をUE3から受信したことに応答して、UE CONTEXT MODIFICATION RESPONSEメッセージ(ステップ1011)を送信してもよい。この場合、UE CONTEXT MODIFICATION RESPONSEメッセージは、条件付きモビリティの開始(又は実行)をCU1に報告する用途を兼ねることができる。他の例では、ソースDU2Aは、条件付きモビリティ開始の表示(ステップ1010)の受信と無関係に、UE CONTEXT MODIFICATION RESPONSEメッセージ(ステップ1011)を送信してもよい。ソースDU2Aは、条件付きモビリティ開始の表示(ステップ1010)の受信よりも前に、UE CONTEXT MODIFICATION RESPONSEメッセージ(ステップ1011)を送信してもよい。
【0101】
図10には示されていないが、CU1は、UE CONTEXT MODIFICATION RESPONSEメッセージ(ステップ1011)の受信後に、UE CONTEXT RELEASE COMMANDメッセージをソースDU2Aに送信してもよい。又は、CU1は、図示されていないDDDSフレームをソースDU2Aから受信した後に、UE CONTEXT RELEASE COMMANDメッセージをソースDU2Aに送信してもよい。このとき、UE CONTEXT RELEASE COMMANDメッセージに付される(又は含まれる)解放Cause値は、例えば、“Handover Condition Met”、“Action Desirable for Radio Reasons”、“Handover Complete”、又は“Normal Release”であってもよい。ソースDU2Aは、UE3に関するUEコンテキストを解放し、UE CONTEXT RELEASE COMPLETEメッセージによってCU1に応答してもよい。
【0102】
図11は、intra-CU inter-DU 条件付きPSCell Change手順の他の例を示している。ステップ1101~1106の処理は、図10のステップ1001~1006のそれと同様である。ステップ1107では、ソースDU2Aは、UE CONTEXT MODIFICATION RESPONSEメッセージによりCU1に応答する。
【0103】
ステップ1108及び1109の処理は、図10のステップ1007及び1008の処理と同様である。すなわち、ステップ1108では、MN4は、MCG SRBを介したMN RAT(e.g., LTE)のRRC再設定手順(e.g., LTE RRC Connection Reconfigurtion手順)を行い、CU1から受信したSN RAT(e.g., NR)のRRCメッセージ(e.g., NR RRC Reconfigurationメッセージ)をUE3にフォワードする。UE3は、CU1宛てのSN RATのRRC応答メッセージ(e.g., NR RRC Reconfiguration Completeメッセージ)を包含するMN RATのRRC応答メッセージ(e.g., LTE RRC Connection Reconfiguration Completeメッセージ)をMN4に送信する。ステップ1109では、MN4は、MN RATのRRC再設定手順の成功裏の完了に応じて、SN MODIFICATION CONFIRMメッセージによりCU1に応答する。当該SN MODIFICATION CONFIRMメッセージは、UE3から受信したSN RATのRRC応答メッセージ(e.g., NR RRC Reconfiguration Completeメッセージ)を包含する。
【0104】
ステップ1110では、UE3は、SN RATのRRCメッセージにより設定された条件付きモビリティ(i.e., 条件付きReconfiguration with sync)の実行条件の成立を判定し、新たな設定を適用し、ターゲットDU2Bへのアクセス(i.e., ランダムアクセス手順)を開始する(ステップ1113)。UE3は、条件付きモビリティ開始の表示をソースDU2Aに送信してもよい(ステップ11110)。
【0105】
ステップ1112では、ソースDU2Aは、DDDSフレームをCU1に送信する。一例では、ソースDU2Aは、条件付きモビリティ開始の表示(ステップ1111)をUE3から受信したことに応答して、DDDSフレーム(ステップ1112)を送信してもよい。この場合、DDDSフレームは、条件付きモビリティの開始(又は実行)をCU1に報告する用途を兼ねることができる。これに代えて、ソースDU2Aは、通常の(つまり条件付きでない)モビリティで使用されるDDDSフレームを送信しつつ、CU1に条件付きモビリティの開始(又は実行)を示すための新たなメッセージを送信してもよい(図示なし)。当該メッセージは、CONDITIONAL MOBILITY TRIGGERED (又はINITIATED, DETECTED, INDICATION, or INSTRUCTION)メッセージと呼ばれてもよい。他の例では、ソースDU2Aは、条件付きモビリティ開始の表示(ステップ1111)の受信と無関係に、DDDSフレーム(ステップ1112)を送信してもよい。ソースDU2Aは、条件付きモビリティ開始の表示(ステップ1111)の受信よりも前に、DDDSフレーム(ステップ1112)を送信してもよい。
【0106】
図11には示されていないが、CU1は、DDDSフレーム(ステップ1112)の受信後に、UE CONTEXT RELEASE COMMANDメッセージをソースDU2Aに送信してもよい。このとき、UE CONTEXT RELEASE COMMANDメッセージに付される(又は含まれる)解放Cause値は、例えば、“Handover Condition Met”、“Action Desirable for Radio Reasons”、“Handover Complete”、又は“Normal Release”であってもよい。ソースDU2Aは、UE3に関するUEコンテキストを解放し、UE CONTEXT RELEASE COMPLETEメッセージによってCU1に応答してもよい。
【0107】
本実施形態で説明された幾つかの手順は、intra-CU inter-DU条件付きPSCell Changeを可能にする。
【0108】
<第6の実施形態>
本実施形態は、条件付きモビリティのためのシグナリングの具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図1及び図2に示された例と同様であってもよい。
【0109】
図12は、intra-CU inter-DU条件付きPSCell Change手順の一例を示している。ステップ1201~1208の処理は、図10のステップ1001~1008のそれと同様である。ただし、ステップ1206のUE CONTEXT MODIFICATION REQUESTメッセージは、条件付きモビリティ(i.e., 条件付きPSCell change、又は条件付きReconfiguration with sync)の条件を示す。
【0110】
ステップ1209では、ソースDU2Aは、条件付きモビリティ(i.e., 条件付きPSCell change、又は条件付きReconfiguration with sync)の実行条件の成立を自律的に判定する。ステップ1210では、ソースDU2Aは、条件付きモビリティの実行条件の成立に応答して、条件付きモビリティ開始コマンドをUE3に送る。条件付きモビリティ開始コマンドは、PDCCHで送信されるダウンリンク制御情報(DCI)であってもよい。これに代えて、条件付きモビリティ開始コマンドは、MAC CEであってもよい。ソースDU2Aは、条件付きモビリティ開始コマンドに用いられる無線リソースの設定を予め決定し、これをCU1を介してUE3に通知してもよい。例えば、ソースDU2Aは、条件付きモビリティ開始コマンドに用いられる無線リソースの設定をUE CONTEXT SETUP RESPONSEメッセージに包含される情報(e.g., CellGroupConfig)に含め、これをCU1へ送信してもよい。そして、CU1は、条件付きモビリティ開始コマンドに用いられる無線リソースの設定を含むRRCReconfigurationメッセージを生成し、これをUE3へ送信してもよい。複数の候補ターゲットセル(e.g., PSCell候補)がある場合、条件付きモビリティ開始コマンドは、選択された候補ターゲットセル(e.g., PSCell changeがトリガされた候補ターゲットセル)を明示的又は暗示的に示す情報を含んでもよい。
【0111】
ステップ1211では、ソースDU2Aは、UE CONTEXT MODIFICATION RESPONSEメッセージによりCU1に応答する。一例では、ソースDU2Aは、条件付きモビリティの実行条件の成立に応答して、UE CONTEXT MODIFICATION RESPONSEメッセージ(ステップ1211)を送信してもよい。この場合、UE CONTEXT MODIFICATION RESPONSEメッセージは、条件付きモビリティの開始(又は実行)をCU1に報告する用途を兼ねることができる。他の例では、ソースDU2Aは、条件付きモビリティの実行条件の成立と無関係に、UE CONTEXT MODIFICATION RESPONSEメッセージ(ステップ1211)を送信してもよい。ソースDU2Aは、条件付きモビリティの実行条件の成立よりも前に、UE CONTEXT MODIFICATION RESPONSEメッセージ(ステップ1211)を送信してもよい。
【0112】
ステップ1212では、UE3は、条件付きモビリティ開始コマンドの受信に応答して、ターゲットDU2Bへのアクセス(i.e., ランダムアクセス手順)を開始する。
【0113】
図12には示されていないが、CU1は、UE CONTEXT MODIFICATION RESPONSEメッセージ(ステップ1211)の受信後に、UE CONTEXT RELEASE COMMANDメッセージをソースDU2Aに送信してもよい。又は、CU1は、図示されていないDDDSフレームをソースDU2Aから受信した後に、UE CONTEXT RELEASE COMMANDメッセージをソースDU2Aに送信してもよい。このとき、UE CONTEXT RELEASE COMMANDメッセージに付される(又は含まれる)解放Cause値は、例えば、“Handover Condition Met”、“Action Desirable for Radio Reasons”、“Handover Complete”、又は“Normal Release”であってもよい。ソースDU2Aは、UE3に関するUEコンテキストを解放し、UE CONTEXT RELEASE COMPLETEメッセージによってCU1に応答してもよい。
【0114】
図13は、intra-CU inter-DU 条件付きPSCell Change手順の他の例を示している。ステップ1301~1306の処理は、図12のステップ1201~1206のそれと同様である。ステップ1307では、ソースDU2Aは、UE CONTEXT MODIFICATION RESPONSEメッセージによりCU1に応答する。
【0115】
ステップ1308及び1309の処理は、図12のステップ1207及び1208の処理と同様である。すなわち、ステップ1308では、MN4は、MCG SRBを介したMN RAT(e.g., LTE)のRRC再設定手順(e.g., LTE RRC Connection Reconfigurtion手順)を行い、CU1から受信したSN RAT(e.g., NR)のRRCメッセージ(e.g., NR RRC Reconfigurationメッセージ)をUE3にフォワードする。UE3は、CU1宛てのSN RATのRRC応答メッセージ(e.g., NR RRC Reconfiguration Completeメッセージ)を包含するMN RATのRRC RRC応答メッセージ(e.g., LTE Connection Reconfiguration Completeメッセージ)をMN4に送信する。ステップ1309では、MN4は、MN RATのRRC再設定手順の成功裏の完了に応じて、SN MODIFICATION CONFIRMメッセージによりCU1に応答する。当該SN MODIFICATION CONFIRMメッセージは、UE3から受信したSN RATのRRC応答メッセージ(e.g., NR RRC Reconfiguration Completeメッセージ)を包含する。
【0116】
ステップ1310では、ソースDU2Aは、条件付きモビリティ(i.e., 条件付きPSCell change、又は条件付きReconfiguration with sync)の実行条件の成立を自律的に判定する。ステップ1311では、ソースDU2Aは、条件付きモビリティの実行条件の成立に応答して、条件付きモビリティ開始コマンドをUE3に送る。条件付きモビリティ開始コマンドは、PDCCHで送信されるDCIであってもよい。これに代えて、条件付きモビリティ開始コマンドは、MAC CEであってもよい。
【0117】
ステップ1312では、ソースDU2Aは、DDDSフレームをCU1に送信する。一例では、ソースDU2Aは、条件付きモビリティの実行条件の成立に応答して、DDDSフレーム(ステップ1312)を送信してもよい。この場合、DDDSフレームは、条件付きモビリティの開始(又は実行)をCU1に報告する用途を兼ねることができる。これに代えて、ソースDU2Aは、通常の(つまり条件付きでない)モビリティで使用されるDDDSフレームを送信しつつ、CU1に条件付きモビリティの開始(又は実行)を示すための新たなメッセージを送信してもよい(図示なし)。当該メッセージは、CONDITIONAL MOBILITY TRIGGERED (又はINITIATED, DETECTED, INDICATION, or INSTRUCTION)メッセージと呼ばれてもよい。他の例では、ソースDU2Aは、条件付きモビリティの実行条件の成立と無関係に、DDDSフレーム(ステップ1312)を送信してもよい。ソースDU2Aは、条件付きモビリティの実行条件の成立よりも前に、DDDSフレーム(ステップ1312)を送信してもよい。
【0118】
図13には示されていないが、CU1は、DDDSフレーム(ステップ1312)の受信後に、UE CONTEXT RELEASE COMMANDメッセージをソースDU2Aに送信してもよい。このとき、UE CONTEXT RELEASE COMMANDメッセージに付される(又は含まれる)解放Cause値は、例えば、“Handover Condition Met”、“Action Desirable for Radio Reasons”、“Handover Complete”、又は“Normal Release”であってもよい。ソースDU2Aは、UE3に関するUEコンテキストを解放し、UE CONTEXT RELEASE COMPLETEメッセージによってCU1に応答してもよい。
【0119】
本実施形態で説明された幾つかの手順は、intra-CU inter-DU条件付きPSCell Changeを可能にする。
【0120】
<第7の実施形態>
本実施形態は、条件付きモビリティのためのシグナリングの具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図1及び図2に示された例と同様であってもよい。
【0121】
UE3は、ソースDU2A(又はCU1)から条件付きモビリティ開始コマンドを受信したことに応答して、条件付きモビリティ(e.g., CHO)を開始してもよい。言い換えると、条件付きモビリティのためにUE3に設定されるモビリティ開始条件は、ネットワーク(e.g., ソースDU2A)からの明示的なシグナリング(e.g., 条件付きモビリティ開始コマンド)の受信であってもよい。
【0122】
条件付きモビリティ開始コマンドは、モビリティ開始条件をUE3に設定するためにネットワークからUE3に送られるメッセージ(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レイヤよりも下位のレイヤのシグナリングを用いることは、UE3への条件付きモビリティ開始コマンドの速やかな送信に寄与できる。
【0123】
さらに、条件付きモビリティ開始コマンドの送信のために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., ソースDU2A及びCU1)からUE3へのRRCシグナリングの送信は、マスターノード(MN)を経由することに起因する遅延が生じる。これとは対照的に、SN(i.e., ソースDU2A及びCU1)からUE3へのMACレイヤ又はphysicalレイヤのシグナリングは、SN(i.e., ソースDU2A及びCU1)によって提供されるセルの物理チャネルを介してUE3に直接的に送信できる。したがって、SN(i.e., ソースDU2A及びCU1)は、RRCレイヤよりも下位のレイヤ(e.g., MACレイヤ、physicalレイヤ)のシグナリングを用いて条件付きモビリティ開始コマンドを送信することによって、当該コマンドをUE3に送る際の遅延を低減できる。
【0124】
なお、この説明から理解されるように、本実施形態で説明されたシグナリング手順は、CU-DU splitが適用されない場合にも有効である。例えば、SN Modification with MN involvementのケースにおいて、SNは、RRCレイヤよりも下位のレイヤ(e.g., MACレイヤ、physicalレイヤ)のシグナリングを用いて条件付きモビリティ開始コマンドを送信してもよい。これにより、条件付きモビリティ開始コマンドは、MCG SRBを経由せずに、SN によって提供されるセルの物理チャネルを介してUE3に直接的に送られることができる。このことは、条件付きモビリティ開始コマンドをUE3に送る際の遅延の低減に寄与できる。
【0125】
図14は、本実施形態に係るシグナリングの一例を示している。ステップ1401では、ソースDU2A(又はCU1)は、条件付きモビリティ開始コマンドのための設定を含むRRCメッセージ(e.g., RRCReconfigurationメッセージ)を送信する。図示されていないが、ソースDU2Aが条件付きモビリティ開始コマンドのための設定を決定し、これをCU1へ例えばDU To CU RRC Information情報要素で送信してもよい。そして、CU1が当該設定を含むRRCメッセージを生成し、ソースDU2Aを介してUE3へ送信してもよい。さらに、CU1及びDU2AがDCのSN(e.g., SgNB)である場合、当該RRCメッセージは、MN(e.g., MeNB)を介して(つまりMCGセルのSRBを介して)UE3に送られてもよい。
【0126】
条件付きモビリティ開始コマンドのための設定は、条件付きモビリティ開始コマンドの識別情報を示してもよい。さらに又はこれに代えて、当該設定は、条件付きモビリティ開始コマンドの送信のためのリソースを示してもよい。より具体的には、当該設定は、条件付きモビリティ開始コマンドのインデックスを示してもよいし、条件付きモビリティ開始コマンドの送信のための時間/周波数/コード・リソースを示してもよい。当該設定は、UE3に固有のPDCCH parameters(e.g., Downlink Control Information (DCI))を設定するために使用されるPDCCH-Configであってもよい。
【0127】
ステップ1402では、ソースDU2A(又はCU1)は、条件付きモビリティ(e.g., CHO)の実行条件の成立を判定する。ステップ1403では、ソースDU2Aは、条件付きモビリティの実行条件の成立に応答して、条件付きモビリティ開始コマンド(e.g., CHO開始コマンド)をUE3に送る。条件付きモビリティ開始コマンドの送信は、ステップ1401においてUE3に事前に提供された設定に従う。
【0128】
図14の手順は、CU-DUスプリットを適用されていないソースノード(e.g., ソースgNB、又はソースeNB)によって、CHOのために行われてもよい。図14の手順は、CU-DUスプリットを適用されていないSNによって、MR-DCでの条件付きPSCell changeのために行われてもよい。
【0129】
<第8の実施形態>
本実施形態は、条件付きモビリティのためのシグナリングの具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図1及び図2に示された例と同様であってもよい。本実施形態では、複数の候補ターゲットセルは、複数のDU2によって提供されてもよい。
【0130】
図15は、intra-CU inter-DU 条件付きモビリティ(e.g., CHO)に関するシグナリングの一例を示す図である。ステップ1501では、CU1は、候補ターゲットセルのリソースの解放の要求を1又は複数のターゲットDU2Bに送る。Inter-DUハンドオーバのケースでは、当該要求は、条件付きハンドオーバのために予約されている1又は複数の候補ターゲットセルのリソースを解放するよう各ターゲットDU2Bに要求する。CU1は、UE3が移動するターゲットセルとは異なる候補ターゲットセルを管理するターゲットDU2Bに当該要求を送信すればよい。一方、Inter-DU PSCell Changeのケースでは、当該要求は、条件付きPSCell Change(又は条件付きReconfiguration with sync)のために予約されている1又は複数の候補ターゲットPSCellのリソースを解放するよう各ターゲットDU2Bに要求する。CU1は、UE3が移動するターゲットPSCellとは異なる候補ターゲットPSCellを管理するターゲットDU2Bに当該要求を送信すればよい。
【0131】
リソース解放要求のためにステップ1501で送信されるメッセージは、例えば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”であってもよい。
【0132】
例えば、CU1は、UE3が条件付きモビリティを完了したことを検出した場合に、ステップ1501の要求を送信してもよい。CU1は、UE3の条件付きモビリティの成功を示すメッセージ(e.g., RRCReconfigurationCompleteメッセージを運ぶUPLINK RRC TRANSFERメッセージ)をいずれかのターゲットDU2Bから受信したことによって、条件付きモビリティの完了を検出してもよい。CU1及びDU2AがDCのSNである場合、CU1は、UE3の条件付きモビリティの成功を示すメッセージ(e.g., RRCReconfigurationCompleteメッセージ)をMN(e.g., MeNB)を介してUE3から受信したことによって、条件付きモビリティの完了を検出してもよい。
【0133】
これに代えて、CU1は、UE3が条件付きモビリティを実行(又は開始)したこと検出した場合に、ステップ1501の要求を送信してもよい。CU1は、条件付きモビリティの開始の表示(indication)(e.g., measurement report)をUE3又はいずれかのターゲットDU2Bから受信したことによって、モビリティ実行(又は開始)を検出してもよい。
【0134】
このような動作によれば、例えば、ターゲットDU2Bは、有効(validity)タイマの満了を待つことなく、条件付きモビリティのために予約されていたリソースをCU1からの要求に応答して解放できる。
【0135】
一方、UE3は、いずれかの候補ターゲットセルへの条件付きモビリティを完了した場合に、自律的に他の候補ターゲットセルのリソース(つまり、無線リソース設定)を解放してもよい。これに代えて、UE3は、条件付きモビリティを完了した後にネットワーク(e.g., CU1、又はターゲットDU2B)から解放要求を受信したことに応答して、他の候補ターゲットセルのリソースを解放してもよい。
【0136】
<第9の実施形態>
本実施形態に係る無線通信ネットワークの構成例は、図1及び図2に示された例と同様であってもよい。本実施形態は、UE3へ送信されていないダウンリンクデータを示すためにソースDU2AからCU1へ送られる制御メッセージの改良を提供する。当該制御メッセージは、これに限られないが例えば、LTE及びNRで使用されるDOWNLINK DATA DELIVERY STATUS(DDDS)フレームであってもよい。
【0137】
第1~第3の実施形態で説明されたように、DDDSフレームは、UE3へ送信されていないダウンリンクデータを示すことに加えて、条件付きモビリティ(e.g., CHO)の開始(又は実行)をCU1に報告する用途のために使用されてもよい。DDDSフレームは、条件付きモビリティの開始(又は実行)を明示的に表示してもよい。例えば、DDDSフレームは、条件付きモビリティの開始(又は実行)を示すための1又はそれ以上のビットを含んでもよい。
【0138】
図16は、CHOの開始(又は実行)を明示的に表示するために改良されたDDDSフレームのフォーマットの一例を示している。図16の例では、DDDSフレームは、Conditional Handover Metビット1601を含む。ビット1601は、CHOの実行(又は開始)条件が満たされた(met、又はsatisfied)か否かを示す。ビット1601は、CHOに代えて又は加えて、他の条件付きモビリティを示すために使用されてもよい。
【0139】
ビット1601の値は、条件付きモビリティの実行(又は開始)条件が満たされた場合に1とされ、そうでない場合に0とされてもよい。この場合、ビット1601の値が1であるとき、当該ビットはConditional Handover indicationを示す。Conditional Handover indicationは、条件付きモビリティの実行(又は開始)条件が満たされた場合にシグナルされる。例えば、Conditional Handover indicationを受信した場合、NR PDCP entityをホストするノード(e.g., CU1)は、対応するノード(e.g., DU2)とUE3の間でアップリンク又はダウンリンクデータがこれ以上送信されないと考えられることを認識してもよい。
【0140】
本実施形態に係る制御メッセージ(e.g., DDDSフレーム)は、例えば、UE3へ送信されていないダウンリンクデータを示すことに加えて、条件付きモビリティ(e.g., CHO)の開始(又は実行)をDU3に報告することをDU2に可能にする。
【0141】
続いて以下では、上述の複数の実施形態に係るCU1、DU2、及びUE3の構成例について説明する。図17は、上述の実施形態に係るCU1の構成例を示すブロック図である。なお、CU-CP11及びCU-UP12の構成も図17に示されたそれと同様であってもよい。図17を参照すると、CU1は、ネットワークインターフェース1701、プロセッサ1702、及びメモリ1703を含む。ネットワークインターフェース1701は、ネットワークノード(e.g., DU2並びにコアネットワーク内の制御プーレーン(CP)ノード及びユーザプレーン(UP)ノード)と通信するために使用される。ネットワークインターフェース1701は、複数のインタフェースを含んでもよい。ネットワークインターフェース1701は、例えば、CU-DU間通信のための光ファイバーインタフェース及びIEEE 802.3 seriesに準拠したネットワークインターフェースを含んでもよい。
【0142】
プロセッサ1702は、無線通信のためのデジタルベースバンド信号処理(データプレーン処理)とコントロールプレーン処理を行う。プロセッサ1702は、複数のプロセッサを含んでもよい。例えば、プロセッサ1702は、デジタルベースバンド信号処理を行うモデム・プロセッサ(e.g., Digital Signal Processor(DSP))とコントロールプレーン処理を行うプロトコルスタック・プロセッサ(e.g., Central Processing Unit(CPU)又はMicro Processing Unit(MPU))を含んでもよい。
【0143】
メモリ1703は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。揮発性メモリは、例えば、Static Random Access Memory(SRAM)若しくはDynamic RAM(DRAM)又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory(MROM)、Electrically Erasable Programmable ROM(EEPROM)、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。メモリ1703は、プロセッサ1702から離れて配置されたストレージを含んでもよい。この場合、プロセッサ1702は、ネットワークインターフェース1701又は図示されていないI/Oインタフェースを介してメモリ1703にアクセスしてもよい。
【0144】
メモリ1703は、上述の複数の実施形態で説明されたCU1による処理を行うための命令群およびデータを含む1又はそれ以上のソフトウェアモジュール(コンピュータプログラム)1704を格納してもよい。いくつかの実装において、プロセッサ1702は、当該1又はそれ以上のソフトウェアモジュール1704をメモリ1703から読み出して実行することで、上述の実施形態で説明されたCU1の処理を行うよう構成されてもよい。
【0145】
図18は、上述の実施形態に係るDU2の構成例を示すブロック図である。図18を参照すると、DU2は、Radio Frequencyトランシーバ1801、ネットワークインターフェース1803、プロセッサ1804、及びメモリ1805を含む。RFトランシーバ1801は、UEsと通信するためにアナログRF信号処理を行う。RFトランシーバ1801は、複数のトランシーバを含んでもよい。RFトランシーバ1801は、アンテナアレイ1802及びプロセッサ1804と結合される。RFトランシーバ1801は、変調シンボルデータをプロセッサ1804から受信し、送信RF信号を生成し、送信RF信号をアンテナアレイ1802に供給する。また、RFトランシーバ1801は、アンテナアレイ1802によって受信された受信RF信号に基づいてベースバンド受信信号を生成し、これをプロセッサ1804に供給する。RFトランシーバ1801は、ビームフォーミングのためのアナログビームフォーマ回路を含んでもよい。アナログビームフォーマ回路は、例えば複数の移相器及び複数の電力増幅器を含む。
【0146】
ネットワークインターフェース1803は、ネットワークノード(e.g., CU1、CU-CP11、CU-UP12)と通信するために使用される。ネットワークインターフェース1803は、複数のインタフェースを含んでもよい。ネットワークインターフェース1803は、例えば、CU-DU間通信のための光ファイバーインタフェース及びIEEE 802.3 seriesに準拠したネットワークインターフェースのうち少なくとも1つを含んでもよい。
【0147】
プロセッサ1804は、無線通信のためのデジタルベースバンド信号処理(データプレーン処理)とコントロールプレーン処理を行う。プロセッサ1804は、複数のプロセッサを含んでもよい。例えば、プロセッサ1804は、デジタルベースバンド信号処理を行うモデム・プロセッサ(e.g., DSP)とコントロールプレーン処理を行うプロトコルスタック・プロセッサ(e.g., CPU又はMPU)を含んでもよい。プロセッサ1804は、ビームフォーミングのためのデジタルビームフォーマ・モジュールを含んでもよい。デジタルビームフォーマ・モジュールは、Multiple Input Multiple Output(MIMO)エンコーダ及びプリコーダを含んでもよい。
【0148】
メモリ1805は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。揮発性メモリは、例えば、SRAM若しくはDRAM又はこれらの組み合わせである。不揮発性メモリは、MROM、EEPROM、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。メモリ1805は、プロセッサ1804から離れて配置されたストレージを含んでもよい。この場合、プロセッサ1804は、ネットワークインターフェース1803又は図示されていないI/Oインタフェースを介してメモリ1805にアクセスしてもよい。
【0149】
メモリ1805は、上述の複数の実施形態で説明されたDU2による処理を行うための命令群およびデータを含む1又はそれ以上のソフトウェアモジュール(コンピュータプログラム)1806を格納してもよい。いくつかの実装において、プロセッサ1804は、当該1又はそれ以上のソフトウェアモジュール1806をメモリ1805から読み出して実行することで、上述の実施形態で説明されたDU2の処理を行うよう構成されてもよい。
【0150】
図19は、上述の実施形態に係るUE3の構成例を示すブロック図である。Radio Frequency(RF)トランシーバ1901は、RANノード(e.g., DU2)と通信するためにアナログRF信号処理を行う。RFトランシーバ1901は、複数のトランシーバを含んでもよい。RFトランシーバ1901により行われるアナログRF信号処理は、周波数アップコンバージョン、周波数ダウンコンバージョン、及び増幅を含む。RFトランシーバ1901は、アンテナアレイ1902及びベースバンドプロセッサ1903と結合される。RFトランシーバ1901は、変調シンボルデータ(又はOFDMシンボルデータ)をベースバンドプロセッサ1903から受信し、送信RF信号を生成し、送信RF信号をアンテナアレイ1902に供給する。また、RFトランシーバ1901は、アンテナアレイ1902によって受信された受信RF信号に基づいてベースバンド受信信号を生成し、これをベースバンドプロセッサ1903に供給する。RFトランシーバ1901は、ビームフォーミングのためのアナログビームフォーマ回路を含んでもよい。アナログビームフォーマ回路は、例えば複数の移相器及び複数の電力増幅器を含む。
【0151】
ベースバンドプロセッサ1903は、無線通信のためのデジタルベースバンド信号処理(データプレーン処理)とコントロールプレーン処理を行う。デジタルベースバンド信号処理は、(a) データ圧縮/復元、(b) データのセグメンテーション/コンカテネーション、(c) 伝送フォーマット(伝送フレーム)の生成/分解、(d) 伝送路符号化/復号化、(e) 変調(シンボルマッピング)/復調、及び(f) Inverse Fast Fourier Transform(IFFT)によるOFDMシンボルデータ(ベースバンドOFDM信号)の生成などを含む。一方、コントロールプレーン処理は、レイヤ1(e.g., 送信電力制御)、レイヤ2(e.g., 無線リソース管理、及びhybrid automatic repeat request(HARQ)処理)、及びレイヤ3(e.g., アタッチ、モビリティ、及び通話管理に関するシグナリング)の通信管理を含む。
【0152】
例えば、ベースバンドプロセッサ1903によるデジタルベースバンド信号処理は、Service Data Adaptation Protocol(SDAP)レイヤ、Packet Data Convergence Protocol(PDCP)レイヤ、Radio Link Control(RLC)レイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。また、ベースバンドプロセッサ1903によるコントロールプレーン処理は、Non-Access Stratum(NAS)プロトコル、RRCプロトコル、及びMAC CEの処理を含んでもよい。
【0153】
ベースバンドプロセッサ1903は、ビームフォーミングのためのMIMOエンコーディング及びプリコーディングを行ってもよい。
【0154】
ベースバンドプロセッサ1903は、デジタルベースバンド信号処理を行うモデム・プロセッサ(e.g., DSP)とコントロールプレーン処理を行うプロトコルスタック・プロセッサ(e.g., CPU又はMPU)を含んでもよい。この場合、コントロールプレーン処理を行うプロトコルスタック・プロセッサは、後述するアプリケーションプロセッサ1904と共通化されてもよい。
【0155】
アプリケーションプロセッサ1904は、CPU、MPU、マイクロプロセッサ、又はプロセッサコアとも呼ばれる。アプリケーションプロセッサ1904は、複数のプロセッサ(複数のプロセッサコア)を含んでもよい。アプリケーションプロセッサ1904は、メモリ1906又は図示されていないメモリから読み出されたシステムソフトウェアプログラム(Operating System(OS))及び様々なアプリケーションプログラム(例えば、通話アプリケーション、WEBブラウザ、メーラ、カメラ操作アプリケーション、音楽再生アプリケーション)を実行することによって、UE3の各種機能を実現する。
【0156】
幾つかの実装において、図19に破線(1905)で示されているように、ベースバンドプロセッサ1903及びアプリケーションプロセッサ1904は、1つのチップ上に集積されてもよい。言い換えると、ベースバンドプロセッサ1903及びアプリケーションプロセッサ1904は、1つのSystem on Chip(SoC)デバイス1905として実装されてもよい。SoCデバイスは、システムLarge Scale Integration(LSI)またはチップセットと呼ばれることもある。
【0157】
メモリ1906は、揮発性メモリ若しくは不揮発性メモリ又はこれらの組合せである。メモリ1906は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、SRAM若しくはDRAM又はこれらの組み合わせである。不揮発性メモリは、MROM、EEPROM、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。例えば、メモリ1906は、ベースバンドプロセッサ1903、アプリケーションプロセッサ1904、及びSoC1905からアクセス可能な外部メモリデバイスを含んでもよい。メモリ1906は、ベースバンドプロセッサ1903内、アプリケーションプロセッサ1904内、又はSoC1905内に集積された内蔵メモリデバイスを含んでもよい。さらに、メモリ1906は、Universal Integrated Circuit Card(UICC)内のメモリを含んでもよい。
【0158】
メモリ1906は、上述の複数の実施形態で説明されたUE3による処理を行うための命令群およびデータを含む1又はそれ以上のソフトウェアモジュール(コンピュータプログラム)1907を格納してもよい。幾つかの実装において、ベースバンドプロセッサ1903又はアプリケーションプロセッサ1904は、当該ソフトウェアモジュール1907をメモリ1906から読み出して実行することで、上述の実施形態で図面を用いて説明されたUE3の処理を行うよう構成されてもよい。
【0159】
なお、上述の実施形態で説明されたUE3によって行われるコントロールプレーン処理及び動作は、RFトランシーバ1901及びアンテナアレイ1902を除く他の要素、すなわちベースバンドプロセッサ1903及びアプリケーションプロセッサ1904の少なくとも一方とソフトウェアモジュール1907を格納したメモリ1906とによって実現されることができる。
【0160】
図17図19を用いて説明したように、上述の実施形態に係るCU1、DU2、及びUE3が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む1又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体(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)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【0161】
<その他の実施形態>
上述の実施形態で説明されたCU1とDU2の間のシグナリングは、CU-CP11とDU2の間、又はCU-UP12とDU2の間で行われてもよい。
【0162】
上述の実施形態は、各々独立に実施されてもよいし、実施形態全体又はその一部が適宜組み合わせて実施されてもよい。これらの実施形態は、互いに独立に実施されることができ、互いに異なる目的又は課題を解決することに寄与し、互いに異なる効果を奏することに寄与する。
【0163】
上述の実施形態で条件付き(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などと呼ばれてもよい。
【0164】
上述の実施形態で説明された条件付きハンドオーバ(又は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ハンドオーバでは、複数の候補ターゲットセルの少なくとも1つが、ソースセルと同じ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メッセージであってもよい。
【0165】
上述した条件付きハンドオーバのためのハンドオーバ実行の条件(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)毎に新たなイベントとして追加(定義)されてもよい。
【0166】
さらに又はこれに代えて、上述した条件付きハンドオーバのためのハンドオーバ実行の条件は、すでに3GPPにより規定されている測定報告をトリガする各イベントに含まれる複数のパラメータの少なくとも1つと置き換えられるパラメータを含んでもよい。
【0167】
さらに又はこれに代えて、上述した条件付きハンドオーバのためのハンドオーバ実行の条件は、すでに3GPPにより規定されている測定報告をトリガする各イベントに含まれる複数のパラメータの少なくとも1つに対するオフセット値を含んでもよい。
【0168】
すでに3GPPで規定されている測定報告(Measurement report)をトリガするイベント(e.g. Event A1, A2, A3, A4, A5, A6, B1, B2, C1, C2, W1, W2, W3, V1, V2, H1, and H2)に含まれるパラメータは、これには限られないが例えば、以下のうち少なくとも1つを含んでもよい:
Ms:オフセット値を考慮しないサービングセルの測定結果、オフセット値を考慮しない送信リソースプールのチャネル混雑比(channel busy ratio)の測定結果、又はUE3が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固有のオフセット値。
【0169】
本明細書における無線端末(User Equipment(UE))は、無線インターフェースを介して、ネットワークに接続されるエンティティである。本明細書の無線端末(UE)は、専用の通信装置に限定されるものではなく、本明細書中に記載された無線端末(UE)の通信機能を有する次のような任意の機器であってもよい。
【0170】
「(3GPPで使われる単語としての)ユーザー端末(User Equipment(UE))」、「移動局(mobile station)」、「移動端末(mobile terminal)」、「モバイルデバイス(mobile device)」、及び「無線端末(wireless device)」との用語は、一般的に互いに同義であることが意図されている。UEは、ターミナル、携帯電話、スマートフォン、タブレット、セルラIoT端末、IoTデバイス、などのスタンドアローン移動局であってもよい。「UE」及び「無線端末」との用語は、長期間にわたって静止している装置も包含する。
【0171】
UEは、例えば、生産設備・製造設備および/またはエネルギー関連機械(一例として、ボイラー、機関、タービン、ソーラーパネル、風力発電機、水力発電機、火力発電機、原子力発電機、蓄電池、原子力システム、原子力関連機器、重電機器、真空ポンプなどを含むポンプ、圧縮機、ファン、送風機、油圧機器、空気圧機器、金属加工機械、マニピュレータ、ロボット、ロボット応用システム、搬送装置、昇降装置、貨物取扱装置、繊維機械、縫製機械、印刷機、印刷関連機械、紙工機械、化学機械、鉱山機械、鉱山関連機械、建設機械、建設関連機械、農業用機械および/または器具、林業用機械および/または器具、漁業用機械および/または器具、安全および/または環境保全器具、トラクター、動力伝動装置、および/または上記で述べた任意の機器又は機械のアプリケーションシステムなど)であってもよい。
【0172】
UEは、例えば、輸送用装置(一例として、車両、自動車、二輪自動車、自転車、列車、バス、リヤカー、人力車、船舶(ship and other watercraft)、飛行機、ロケット、人工衛星、ドローン、気球など)であってもよい。
【0173】
UEは、例えば、情報通信用装置(一例として、電子計算機及び関連装置、通信装置及び関連装置、電子部品など)であってもよい。
【0174】
UEは、例えば、商業およびサービス用機器、自動販売機、自動サービス機、事務用機械及び装置、民生用電気・電子機械器具(一例として音声機器、スピーカー、ラジオ、映像機器、テレビなど)であってもよい。
【0175】
UEは、例えば、電子応用システムまたは電子応用装置(一例として、X線装置、粒子加速装置、放射性物質応用装置、音波応用装置、電磁応用装置、電力応用装置など)であってもよい。
【0176】
UEは、例えば、電球、照明、計量機、分析機器、試験機及び計測機械(一例として、煙報知器、対人警報センサ、動きセンサ、無線タグなど)、時計(watchまたはclock)、理化学機械、光学機械、医療用機器および/または医療用システム、武器、利器工匠具、または手道具であってもよい。
【0177】
UEは、例えば、無線通信機能を備えたパーソナルデジタルアシスタントまたは装置(一例として、無線カードや無線モジュールなどを取り付けられる、もしくは挿入するよう構成された電子装置(例えば、パーソナルコンピュータや電子計測器など))であってもよい。
【0178】
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と呼ばれることもある。
【0179】
UEは、1つまたは複数のIoTまたはMTCアプリケーションをサポートしてもよい。
【0180】
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)を含む。
【0181】
セキュリティに関するMTCアプリケーションの例は、監視システム (Surveillance systems)、固定電話のバックアップ (Backup for landline)、物理アクセスの制御(例えば建物へのアクセス) (Control of physical access (e.g. to buildings))、及び車/運転手のセキュリティ (Car/driver security)を含む。
【0182】
追跡及びトレースに関するMTCアプリケーションの例は、フリート管理 (Fleet Management)、注文管理 (Order Management)、テレマティクス保険:走行に応じた課金 (Pay as you drive (PAYD))、資産追跡 (Asset Tracking)、ナビゲーション (Navigation)、交通情報 (Traffic information)、道路料金徴収 (Road tolling)、及び道路通行最適化/誘導 (Road traffic optimisation/steering)を含む。
【0183】
支払いに関するMTCアプリケーションの例は、販売時点情報管理 (Point of sales (POS))、自動販売機 (Vending machines)、及び遊戯機 (Gaming machines)を含む。
【0184】
健康に関するMTCアプリケーションの例は、生命徴候の監視 (Monitoring vital signs)、高齢者又は障害者支援 (Supporting the aged or handicapped)、ウェブアクセス遠隔医療 (Web Access Telemedicine points)、及びリモート診断 (Remote diagnostics)を含む。
【0185】
リモートメンテナンス/制御に関するMTCアプリケーションの例は、センサー (Sensors)、明かり (Lighting)、ポンプ (Pumps)、バルブ (Valves)、エレベータ制御 (Elevator control)、自動販売機制御 (Vending machine control)、及び車両診断 (Vehicle diagnostics)を含む。
【0186】
計量に関するMTCアプリケーションの例は、パワー (Power)、ガス (Gas)
水 (Water)、暖房 (Heating)、グリッド制御 (Grid control)、及び産業用メータリング (Industrial metering)を含む。
【0187】
民生機器に関するMTCアプリケーションの例は、デジタルフォトフレーム、デジタルカメラ、及び電子ブック (ebook)を含む。
【0188】
アプリケーション、サービス、及びソリューションは、一例として、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)サービス/システムなどであってもよい。
【0189】
上述したUEのカテゴリは、本明細書に記載された技術思想及び実施形態の応用例に過ぎない。本明細書のUEは、これらの例に限定されるものではなく、当業者は種々の変更をこれに行うことができる。
【0190】
さらに、上述した実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。
【0191】
例えば、上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
【0192】
(付記1)
基地局の分散ユニットであって、
少なくとも1つのメモリと、
前記少なくとも1つのメモリに結合された少なくとも1つのプロセッサと、
を備え、
前記少なくとも1つのプロセッサは、前記分散ユニットによって提供される第1のセルから第2のセルへの無線端末の条件付きモビリティの開始を検出したことに応答して、第1のメッセージを前記基地局の中央ユニットに送るよう構成される、
分散ユニット。
【0193】
(付記2)
前記少なくとも1つのプロセッサは、
前記無線端末の計画されているモビリティが前記条件付きモビリティであるかを判定するよう構成され、
前記計画されているモビリティが前記条件付きモビリティである場合に、前記計画されているモビリティが前記条件付きモビリティでない場合に比べて前記第1のメッセージの前記中央ユニットへの送信を遅らせるよう構成される、
付記1に記載の分散ユニット。
【0194】
(付記3)
前記第1のメッセージは、前記無線端末に関するコンテキストの変更のためのシグナリング手順において送信される、
付記1又は2に記載の分散ユニット。
【0195】
(付記4)
前記シグナリング手順は、UE Context Modification 手順であり、
前記第1のメッセージは、UE CONTEXT MODIFICATION RESPONSEメッセージである、
付記3に記載の分散ユニット。
【0196】
(付記5)
前記第1のメッセージは、前記無線端末へ送信されていないダウンリンクデータを示すために前記中央ユニットに送信される、
付記1又は2に記載の分散ユニット。
【0197】
(付記6)
前記第1のメッセージは、DOWNLINK DATA DELIVERY STATUSフレームである、
付記5に記載の分散ユニット。
【0198】
(付記7)
前記少なくとも1つのプロセッサは、前記条件付きモビリティの開始条件の成立に応じて前記無線端末から送信される報告を受信したことによって、前記条件付きモビリティの開始を検出するよう構成される、
付記1~6のいずれか1項に記載の分散ユニット。
【0199】
(付記8)
前記少なくとも1つのプロセッサは、前記条件付きモビリティの開始条件の成立を自律的に判定したことによって、前記条件付きモビリティの開始を検出するよう構成される、
付記1~6のいずれか1項に記載の分散ユニット。
【0200】
(付記9)
前記少なくとも1つのプロセッサは、前記条件付きモビリティの前記開始条件の成立に応答して、前記無線端末に条件付きモビリティ開始コマンドを送信するよう構成される、
付記8に記載の分散ユニット。
【0201】
(付記10)
前記少なくとも1つのプロセッサは、前記条件付きモビリティ開始コマンドのための設定を、前記条件付きモビリティ開始コマンドの送信よりも前に、前記中央ユニットへ送信するよう構成される、
付記9に記載の分散ユニット。
【0202】
(付記11)
前記第2のセルは、前記分散ユニット、前記分散ユニットとは異なる前記基地局の他の分散ユニット、又は前記基地局とは異なる他の基地局によって提供される、
付記1~10のいずれか1項に記載の分散ユニット。
【0203】
(付記12)
基地局の分散ユニットのための方法であって、
前記分散ユニットによって提供される第1のセルから第2のセルへの無線端末の条件付きモビリティの開始を検出したことに応答して、第1のメッセージを前記基地局の中央ユニットに送ることを備える、
方法。
【0204】
(付記13)
前記無線端末の計画されているモビリティが前記条件付きモビリティであるかを判定すること、及び
前記計画されているモビリティが前記条件付きモビリティである場合に、前記計画されているモビリティが前記条件付きモビリティでない場合に比べて前記第1のメッセージの前記中央ユニットへの送信を遅らせること、
をさらに備える、
付記12に記載の方法。
【0205】
(付記14)
前記第1のメッセージは、前記無線端末に関するコンテキストの変更のためのシグナリング手順において送信される、
付記12又は13に記載の方法。
【0206】
(付記15)
前記シグナリング手順は、UE Context Modification 手順であり、
前記第1のメッセージは、UE CONTEXT MODIFICATION RESPONSEメッセージである、
付記14に記載の方法。
【0207】
(付記16)
前記第1のメッセージは、前記無線端末へ送信されていないダウンリンクデータを示すために前記中央ユニットに送信される、
付記12又は13に記載の方法。
【0208】
(付記17)
前記第1のメッセージは、DOWNLINK DATA DELIVERY STATUSフレームである、
付記16に記載の方法。
【0209】
(付記18)
前記条件付きモビリティの開始条件の成立に応じて前記無線端末から送信される報告を受信したことによって、前記条件付きモビリティの開始を検出すことをさらに備える、
付記12~17のいずれか1項に記載の方法。
【0210】
(付記19)
前記条件付きモビリティの開始条件の成立を自律的に判定したことによって、前記条件付きモビリティの開始を検出することをさらに備える、
付記12~17のいずれか1項に記載の方法。
【0211】
(付記20)
基地局の分散ユニットのための方法をコンピュータに行わせるためのプログラムであって、
前記方法は、前記分散ユニットによって提供される第1のセルから第2のセルへの無線端末の条件付きモビリティの開始を検出したことに応答して、第1のメッセージを前記基地局の中央ユニットに送ることを備える、
プログラム。
【0212】
(付記21)
基地局の中央ユニットであって、
少なくとも1つのメモリと、
前記少なくとも1つのメモリに結合された少なくとも1つのプロセッサと、
を備え、
前記少なくとも1つのプロセッサは、
前記基地局の分散ユニットによって提供される第1のセルから第2のセルへの無線端末の条件付きモビリティを制御し、
前記分散ユニットが前記条件付きモビリティの開始を検出したことに応答して送信する第1のメッセージを受信するよう構成される、
中央ユニット。
【0213】
(付記22)
前記少なくとも1つのプロセッサは、前記無線端末に計画されているモビリティが前記条件付きモビリティであることを明示的に又は暗示的に示す情報を前記分散ユニットに送信するよう構成される、
付記21に記載の中央ユニット。
(付記23)
前記少なくとも1つのプロセッサは、前記第1のメッセージの受信に応答して、前記無線端末による条件付きモビリティが開始されたことを知るよう構成される、
付記21又は22に記載の中央ユニット。
【0214】
(付記24)
基地局の中央ユニットのための方法であって、
前記基地局の分散ユニットによって提供される第1のセルから第2のセルへの無線端末の条件付きモビリティを制御すること、及び
前記分散ユニットが前記条件付きモビリティの開始を検出したことに応答して送信する第1のメッセージを受信すること、
を備える、方法。
【0215】
(付記25)
基地局の中央ユニットのための方法をコンピュータに行わせるためのプログラムであって、
前記方法は、
前記基地局の分散ユニットによって提供される第1のセルから第2のセルへの無線端末の条件付きモビリティを制御すること、及び
前記分散ユニットが前記条件付きモビリティの開始を検出したことに応答して送信する第1のメッセージを受信すること、
を備える、プログラム。
【0216】
(付記26)
無線アクセスネットワークノードであって、
少なくとも1つのメモリと、
前記少なくとも1つのメモリに結合された少なくとも1つのプロセッサと、
を備え、
前記少なくとも1つのプロセッサは、前記無線アクセスネットワークノードによって提供される第1のセルから第2のセルへの無線端末の条件付きモビリティの開始条件の成立に応答して、前記無線端末に条件付きモビリティ開始コマンドを送信するよう構成され、
前記少なくとも1つのプロセッサは、前記条件付きモビリティ開始コマンドのための設定を、前記条件付きモビリティ開始コマンドの送信よりも前に、前記無線端末に送信するよう構成される、
無線アクセスネットワークノード。
【0217】
(付記27)
前記少なくとも1つのプロセッサは、デュアルコネクティビティのマスターノードを介して、前記設定を前記無線端末に送信するよう構成され、
前記少なくとも1つのプロセッサは、前記無線アクセスネットワークノードにより提供されるセルを介して、前記条件付きモビリティ開始コマンドを前記無線端末に直接的に送信するよう構成される、
付記26に記載の無線アクセスネットワークノード。
【0218】
(付記28)
前記設定は、Radio Resource Control(RRC)メッセージを介して前記無線端末に送信され、
前記条件付きモビリティ開始コマンドは、RRCレイヤよりも下位レイヤのシグナリングを用いて前記無線端末に送信される、
付記26又は27のいずれか1項に記載の無線アクセスネットワークノード。
【0219】
(付記29)
前記条件付きモビリティ開始コマンドは、Medium Access Control(MAC)のシグナリングを用いて前記無線端末に送信される、
付記28に記載の無線アクセスネットワークノード。
【0220】
(付記30)
前記条件付きモビリティ開始コマンドは、MAC Control Element(CE)である、
付記28又は29に記載の無線アクセスネットワークノード。
【0221】
(付記31)
前記条件付きモビリティ開始コマンドは、物理レイヤのシグナリングを用いて前記無線端末に送信される、
付記28に記載の無線アクセスネットワークノード。
【0222】
(付記32)
前記条件付きモビリティ開始コマンドは、Physical Downlink Control Channel(PDCCH)で送信されるダウンリンク制御情報(Downlink Control Information(DCI))である、
付記28又は31に記載の無線アクセスネットワークノード。
【0223】
(付記33)
前記設定は、前記条件付きモビリティ開始コマンドの識別情報、及び前記条件付きモビリティ開始コマンドの送信のためのリソースのうち少なくとも1つを示す、
付記26~32のいずれか1項に記載の無線アクセスネットワークノード。
【0224】
(付記34)
前記無線アクセスネットワークノードは、中央ユニット及び少なくとも1つの分散ユニットを含む、
付記26~33のいずれか1項に記載の無線アクセスネットワークノード。
【0225】
(付記35)
無線アクセスネットワークノードのための方法であって、
前記無線アクセスネットワークノードによって提供される第1のセルから第2のセルへの無線端末の条件付きモビリティの開始条件の成立に応答して、前記無線端末に条件付きモビリティ開始コマンドを送信すること、及び
前記条件付きモビリティ開始コマンドのための設定を、前記条件付きモビリティ開始コマンドの送信よりも前に、前記無線端末に送信すること、
を備える方法。
【0226】
(付記36)
無線アクセスネットワークノードのための方法をコンピュータに行わせるためのプログラムであって、
前記方法は、
前記無線アクセスネットワークノードによって提供される第1のセルから第2のセルへの無線端末の条件付きモビリティの開始条件の成立に応答して、前記無線端末に条件付きモビリティ開始コマンドを送信すること、及び
前記条件付きモビリティ開始コマンドのための設定を、前記条件付きモビリティ開始コマンドの送信よりも前に、前記無線端末に送信すること、
を備える、
プログラム。
【0227】
この出願は、2019年1月11日に出願された日本出願特願2019-003562を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【0228】
1 中央ユニット(Central Unit(CU))
2 分散ユニット(Distributed Unit(DU))
3 UE
4 マスターノード(Master Node(MN))
11 CU-CP
12 CU-UP
1702 プロセッサ
1703 メモリ
1704 モジュール(modules)
1804 プロセッサ
1805 メモリ
1806 モジュール(modules)
1903 ベースバンドプロセッサ
1904 アプリケーションプロセッサ
1906 メモリ
1907 モジュール(modules)
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19