図面を参照しながら、実施形態に係る移動通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
[第1実施形態]
(移動通信システムの構成)
まず、一実施形態に係る移動通信システムの構成について説明する。図1は、一実施形態に係る移動通信システム1の構成を示す図である。移動通信システム1は、3GPP規格に基づく第5世代(5G)移動通信システムである。具体的には、移動通信システム1における無線アクセス方式は、5Gの無線アクセス方式であるNR(New Radio)である。但し、移動通信システム1には、LTE(Long Term Evolution)が少なくとも部分的に適用されてもよい。
図1に示すように、移動通信システム1は、5Gコアネットワーク(5GC)10と、ユーザ装置(UE:User Equipment)100と、基地局(gNBと呼ばれる)200と、IABノード300とを有する。IABノード300は、中継装置の一例である。
一実施形態において、基地局がNR基地局である一例について主として説明するが、基地局がLTE基地局(すなわち、eNB)であってもよい。
5GC10は、AMF(Access and Mobility Management Function)11及びUPF(User Plane Function)12を有する。AMF11は、UE100に対する各種モビリティ制御等を行う装置である。AMF11は、NAS(Non-Access Stratum)シグナリングを用いてUE100と通信することにより、UE100が在圏するエリアの情報を管理する。UPF12は、ユーザデータの転送制御等を行う装置である。
gNB200は、NGインターフェイスと呼ばれるインターフェイスを介して、5GC10に接続される。図1において、5GC10に接続された3つのgNB200-1~gNB200-3を例示している。gNB200は、UE100との無線通信を行う固定の無線通信装置である。gNB200がドナー機能を有する場合、gNB200は、自身に無線で接続するIABノードとの無線通信を行ってもよい。
gNB200は、Xnインターフェイスと呼ばれる基地局間インターフェイスを介して、隣接関係にある他のgNB200と接続される。図1において、gNB200-1がgNB200-2及びgNB200-3に接続される一例を示している。
各gNB200は、1又は複数のセルを管理する。セルは、無線通信エリアの最小単位を示す用語として用いられる。セルは、UE100との無線通信を行う機能又はリソースを示す用語として用いられることがある。1つのセルは1つのキャリア周波数に属する。
UE100は、gNB200との無線通信を行う移動可能な無線通信装置である。UE100は、IABノード300との無線通信を行ってもよい。UE100は、gNB200又はIABノード300との無線通信を行う装置であればよい。例えば、UE100は、携帯電話端末、タブレット端末、ノートPC、センサ若しくはセンサに設けられる装置、又は車両若しくは車両に設けられる装置である。
図1において、UE100-1がgNB200-1に無線で接続され、UE100-2がIABノード300-1に無線で接続され、UE100-3がIABノード300-2に無線で接続される一例を示している。UE100-1は、gNB200-1との通信を直接的に行う。UE100-2は、IABノード300-1を介してgNB200-1との通信を間接的に行う。UE100-3は、IABノード300-1及びIABノード300-2を介してgNB200-1との通信を間接的に行う。
IABノード300は、eNB200とUE100との間の通信に介在し、この通信に対する中継を行う装置(中継装置)である。図1において、IABノード300-1がドナー装置であるgNB200-1に無線で接続され、IABノード300-2がIABノード300-1に無線で接続される一例を示している。各IABノード300は、セルを管理する。IABノード300が管理するセルのセルIDは、ドナーgNB200-1のセルのセルIDと同じであってもよいし、異なっていてもよい。
IABノード300は、UE機能(ユーザ装置機能)及びgNB機能(基地局機能)を有する。このようなUE機能はMTと呼ばれることがあり、gNB機能はDUと呼ばれることがある。
IABノード300は、自身のUE機能(MT)により上位装置(gNB200又は上位のIABノード300)との無線通信を行うとともに、自身のgNB機能(DU)により下位装置(UE100又は下位のIABノード300)との無線通信を行う。上位とは、IABノード300を基準としてドナー装置(gNB200)側をいい、下位とは、IABノード300を基準としてUE100側をいう。
UE機能(MT)とは、UE100が有する機能のうち少なくとも一部の機能を意味し、必ずしもUE100の全ての機能をIABノード300が有していなくてもよい。gNB機能(DU)とは、gNB200の機能のうち少なくとも一部の機能を意味し、必ずしもgNB200の全ての機能をIABノード300が有していなくてもよい。例えば、gNB機能(DU)とは、RRCレイヤ及びPDCPレイヤ等を有していなくてもよい。
UE100と、IABノード300又はgNB200との間の無線区間は、アクセスリンク(或いは、Uu)と呼ばれることがある。IABノード300と、gNB200又は他のIABノード300との間の無線区間は、バックホールリンク(或いは、Un)と呼ばれることがある。かかるバックホールリンクは、フロントホールリンクと称されてもよい。
アクセスリンクのデータ通信及びバックホールリンクのデータ通信をレイヤ2において統合及び多重化し、バックホールリンクのデータ通信に動的に無線リソースを割り当て、中継の経路を動的に切り替えることが可能である。なお、アクセスリンク及びバックホールリンクには、ミリ波帯が用いられてもよい。また、アクセスリンク及びバックホールリンクは、時分割及び/又は周波数分割により多重化されてもよい。
(基地局の構成)
次に、一実施形態に係る基地局であるgNB200の構成について説明する。図2は、gNB200の構成を示す図である。図2に示すように、gNB200は、無線通信部210と、ネットワーク通信部220と、制御部230とを有する。
無線通信部210は、UE100との無線通信及びIABノード300との無線通信に用いられる。無線通信部210は、受信部211及び送信部212を有する。受信部211は、制御部230の制御下で各種の受信を行う。受信部211はアンテナを含み、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部230に出力する。送信部212は、制御部230の制御下で各種の送信を行う。送信部212はアンテナを含み、制御部230が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
ネットワーク通信部220は、5GC10との有線通信(又は無線通信)及び隣接する他のgNB200との有線通信(又は無線通信)に用いられる。ネットワーク通信部220は、受信部221及び送信部222を有する。受信部221は、制御部230の制御下で各種の受信を行う。受信部221は、外部から信号を受信して受信信号を制御部230に出力する。送信部222は、制御部230の制御下で各種の送信を行う。送信部222は、制御部230が出力する送信信号を外部に送信する。
制御部230は、gNB200における各種の制御を行う。制御部230は、少なくとも1つのメモリと、メモリと電気的に接続された少なくとも1つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサとCPUとを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
(中継装置の構成)
次に、一実施形態に係る中継装置であるIABノード300の構成について説明する。図3は、IABノード300の構成を示す図である。図3に示すように、IABノード300は、無線通信部310と、制御部320とを有する。IABノード300は、無線通信部310を複数有していてもよい。
無線通信部310は、gNB200との無線通信(バックホールリンク)及びUE100との無線通信(アクセスリンク)に用いられる。バックホールリンク通信用の無線通信部310とアクセスリンク通信用の無線通信部310とが別々に設けられていてもよい。
無線通信部310は、受信部311及び送信部312を有する。受信部311は、制御部320の制御下で各種の受信を行う。受信部311はアンテナを含み、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部320に出力する。送信部312は、制御部320の制御下で各種の送信を行う。送信部312はアンテナを含み、制御部320が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
制御部320は、IABノード300における各種の制御を行う。制御部320は、少なくとも1つのメモリと、メモリと電気的に接続された少なくとも1つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びCPUを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
(ユーザ装置の構成)
次に、一実施形態に係るユーザ装置であるUE100の構成について説明する。図4は、UE100の構成を示す図である。図4に示すように、UE100は、無線通信部110と、制御部120とを有する。
無線通信部110は、アクセスリンクにおける無線通信、すなわち、gNB200との無線通信及びIABノード300との無線通信に用いられる。無線通信部110は、受信部111及び送信部112を有する。受信部111は、制御部120の制御下で各種の受信を行う。受信部111はアンテナを含み、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部120に出力する。送信部112は、制御部120の制御下で各種の送信を行う。送信部112はアンテナを含み、制御部120が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
制御部120は、UE100における各種の制御を行う。制御部120は、少なくとも1つのメモリと、メモリと電気的に接続された少なくとも1つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びCPUを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
(プロトコルスタック構成の一例)
次に、一実施形態に係る移動通信システム1におけるプロトコルスタック構成の一例について説明する。図5は、ユーザプレーンのプロトコルスタック構成の一例を示す図である。図5において、図1に示したUE100-3と5GC10のUPF12との間のユーザデータ伝送に関するプロトコルスタック構成の一例を示している。
図5に示すように、UPF12は、GTP-U(GPRS Tunneling Protocol for User Plane)と、UDP(User Datagram Protocol)と、IP(Internet Protocol)と、レイヤ1/レイヤ2(L1/L2)とを有する。gNB200-1(ドナーgNB)には、これらに対応するプロトコルスタックが設けられる。
また、gNB200-1は、集約ユニット(CU:Central Unit)と分散ユニット(DU:Distributed Unit)とを有する。無線インターフェイスのプロトコルスタックのうちPDCP(Packet Data Convergence Protocol)以上の各レイヤをCUが有し、RLC(Radio Link Control)以下の各レイヤをDUが有し、F1インターフェイスと呼ばれるインターフェイスを介してCU及びDUが接続される。
具体的には、CUは、SDAP(Service Data Adaptation Protocol)と、PDCPと、IPと、L1/L2とを有する。CUのSDAP及びPDCPは、DUと、IABノード300-1と、IABノード300-2とを介して、UE100のSDAP及びPDCPとの通信を行う。
また、DUは、無線インターフェイスのプロトコルスタックのうち、RLCと、アダプテーションレイヤ(Adapt)と、MAC(Medium Access Control)と、PHY(Physical layer)とを有する。これらのプロトコルスタックは、gNB向けのプロトコルスタックである。なお、アダプテーションレイヤ及びRLC(S-RLC)は上下関係が逆であってもよい。アダプテーションレイヤは、バックホールアダプテーションプロトコル(BAP)レイヤと呼ばれてもよい。
IABノード300-1には、これらに対応するUE向けのプロトコルスタックST1が設けられる。さらに、IABノード300-1には、gNB向けのプロトコルスタックST2が設けられる。プロトコルスタックST1及びプロトコルスタックST2は、何れもレイヤ2以下の各レイヤ(各サブレイヤ)からなる。すなわち、IABノード300-1は、レイヤ2以下の各レイヤを用いてユーザデータの中継を行うレイヤ2中継装置である。IABノード300-1は、レイヤ3以上のレイヤ(具体的には、PDCP以上のレイヤ)を用いることなくデータ中継を行う。なお、IABノード300-2は、IABノード300-1と同様なプロトコルスタック構成を有する。
ここではユーザプレーンにおけるプロトコルスタック構成について説明した。しかしながら、制御プレーンにおいて、gNB200-1、IABノード300-1、IABノード300-2、及びUE100-3のそれぞれは、レイヤ3に相当するRRC(Radio Resource Control)を有する。
gNB200-1(ドナーgNB)のRRCとIABノード300-1のRRCとの間にRRC接続が確立され、このRRC接続を用いてRRCメッセージが送受信される。また、gNB200-1のRRCとIABノード300-2のRRCとの間にRRC接続が確立され、このRRC接続を用いてRRCメッセージが送受信される。さらに、gNB200-1のRRCとUE100-3のRRCとの間にRRC接続が確立され、このRRC接続を用いてRRCメッセージが送受信される。
(第1実施形態に係る動作)
次に、第1実施形態に係る動作について説明する。図6は、第1実施形態に係るIABノード300の動作を示す図である。
図6に示すように、IABノード300は、バックホールリンクを介して上位装置Aと無線で接続している。上位装置Aは、上位IABノード又はドナーgNB(ドナー装置)である。
IABノード300には下位装置B1及びB2が接続しており、下位装置B2には下位装置B3が接続している。下位装置B4は、IABノード300の配下にない装置である。下位装置B1乃至B4は、下位IABノード又はUEである。以下において、下位装置B1乃至B4を特に区別しないときは単に下位装置Bと呼ぶ。
第1実施形態では、上位装置Aと下位装置Bとの間の通信を無線で中継するIABノード300において、上位装置Aと無線で接続するユーザ装置機能部(MT)は、下位装置Bと無線で接続する基地局機能部(DU)に対して状態情報を通知する。
この状態情報は、ユーザ装置機能部(MT)のRRC状態、及び上位装置Aとユーザ装置機能部(MT)との間の無線リンク状態(以下、バックホールリンク状態と呼ぶ)のうち、少なくとも一方の状態を示す情報である。これにより、基地局機能部(DU)は、バックホールリンク側の状態を考慮して下位装置Bに対するサービス提供を制御できる。
ここで、ユーザ装置機能部(MT)のRRC状態は、コネクティッド、インアクティブ、及びアイドルのいずれかである。
バックホールリンク状態は、下記の1)乃至6)のうち少なくとも1つの指標、又はこれらの指標の組み合わせに基づく状態である。
1)バックホールのRLF(以下、BH RLFと呼ぶ)を検知した及びBH RLFから復帰したなどのRLF状態
2)RSRP(Reference Signal Received Power)などの無線品質
3)RLC(Radio Link Control)再送回数やRACH(Random Access Channel)再送回数などのリンク状態
4)RSSI(Received Signal Strength Indicator)、CBR(Channel Busy Ratio)、LBT(Listen Before Talk)状況などの混雑度
5)設定されている又は活性化されているセカンダリセル数、MIMO(Multiple Input Multiple Output)レイヤ数、割り当て無線リソース状況(例えば、準静的割り当てにおけるConfigured grantの増減、動的割り当てにおけるDynamic grantの増減)、スループット測定値などの通信容量
6)上りリンクスケジューリング遅延時間の測定値、上りリンクバッファ中のデータ量などの遅延状態。
バックホールリンク状態は、上記1)乃至6)の指標に基づくバックホールリンク状態の良好度合い、例えば、閾値よりも良好又は閾値よりも劣悪といった状態であってもよい。
ユーザ装置機能部(MT)は、RRC状態の変化又はバックホールリンク状態の変化をトリガとして、状態情報を基地局機能部(DU)に通知してもよい。例えば、ユーザ装置機能部(MT)は、バックホールリンク状態が閾値条件を満たしたというイベントが発生した際に、状態情報を基地局機能部(DU)に通知する。
或いは、ユーザ装置機能部(MT)は、状態情報を基地局機能部(DU)に周期的に通知してもよい。
基地局機能部(DU)は、ユーザ装置機能部(MT)からの状態情報に基づいて、下位装置Bに対するサービス提供を停止してもよい。下位装置Bに対するサービス提供を停止するとは、少なくとも1つの下りリンク無線信号の送信を停止することをいう。基地局機能部(DU)は、PSS(Primary Synchronization Signal)、SSS(Secondary Synchronization Signal)、MIB(Master Information Block)の送信を停止してもよい。
例えば、基地局機能部(DU)は、ユーザ装置機能部(MT)がRRCアイドル状態又はRRCインアクティブ状態に遷移した場合、下位装置Bに対するサービス提供を停止してもよい。基地局機能部(DU)は、ユーザ装置機能部(MT)がRRCコネクティッド状態に遷移した場合、下位装置Bに対するサービス提供を再開してもよい。
基地局機能部(DU)は、バックホールリンクが劣化している場合、例えば、BH RLFが検知された場合、下位装置Bに対するサービス提供を停止してもよい。基地局機能部(DU)は、バックホールリンクが良化した場合、下位装置Bに対するサービス提供を再開してもよい。
或いは、基地局機能部(DU)は、ユーザ装置機能部(MT)からの状態情報に基づいて、下位装置Bに対する無線リソース割り当て(スケジューリング)を制御してもよい。
基地局機能部(DU)は、ユーザ装置機能部(MT)がRRCアイドル状態又はRRCインアクティブ状態に遷移した場合、下位装置Bに対するリソース割当を中止してもよい。なお、基地局機能部(DU)は、ユーザ装置機能部(MT)がRRCアイドル状態又はRRCインアクティブ状態に遷移した際に、下位装置Bに上りリンクリソースを割り当てている場合、RRCコネクティッド状態に遷移するようにユーザ装置機能部(MT)に要求してもよい。
基地局機能部(DU)は、ユーザ装置機能部(MT)がRRCコネクティッド状態に遷移した場合、下位装置Bに対するリソース割当を再開してもよい。
基地局機能部(DU)は、バックホールリンクが劣化している場合、例えば、BH RLFが検知された場合、下位装置Bに対するリソース割当を中止してもよい。基地局機能部(DU)は、バックホールリンクが良化した場合、例えば、BH RLFから復旧した場合、下位装置Bに対するリソース割当を再開してもよい。
或いは、基地局機能部(DU)は、ユーザ装置機能部(MT)からの状態情報に基づいて、バックホールリンクの劣化を示す通知、例えば、BH RLFの発生を示す通知(以下、RLF Notification又はBH RLF Notificationと呼ぶ)を下位装置Bに送信してもよい。BH RLF Notificationは、IABノード300の識別子を含んでもよい。以下において、バックホールリンクの劣化を示す通知がBH RLF Notificationである一例について説明する。
基地局機能部(DU)は、RRCレイヤよりも下位のレイヤの制御信号によりBH RLF Notificationを送信してもよい。基地局機能部(DU)は下位装置BとのRRC接続を有していないためである。RRCレイヤよりも下位のレイヤの制御信号は、MAC CE(Control Element)、RLC Control PDU(Protocol Data Unit)、又はPDCCH(Physical Downlink Control Channel)であるが、以下においてはMAC CEを用いる一例について説明する。
基地局機能部(DU)は、BH RLF Notificationをユニキャストで下位装置Bに送信してもよい。或いは、基地局機能部(DU)は、BH RLF Notificationのシグナリング負荷を減らすために、BH RLF Notificationをブロードキャスト又はマルチキャストで送信してもよい。ブロードキャスト又はマルチキャストを用いる場合、下位装置B3及びB4は、接続中のセル(上位IABノード)からのBH RLF Notificationだけではなく、その他のセルのBH RLF Notificationもモニタすることで、IABノード300からのBH RLF Notificationを受信できる。
基地局機能部(DU)は、例えば、予め仕様で定められた固定のRNTI(Radio Network Temporary Identifier)を用いてBH RLF Notificationをブロードキャストで送信してもよい。基地局機能部(DU)は、下位装置のグループに割り当てた共通のRNTIを用いてBH RLF Notificationをマルチキャストで送信してもよい。
なお、ブロードキャスト/マルチキャストと、ユニキャストとを使い分けてもよい。この場合、基地局機能部(DU)は、BH RLF Notificationがブロードキャスト/マルチキャストで送信されるか、ユニキャストで送信されるかをSIBで通知(ブロードキャスト)してもよい。下位装置Bは、このSIBに基づいて、BH RLF Notificationの待ち受けモード、例えば、BH RLF Notificationのモニタに用いるRNTIを変更してもよい。
基地局機能部(DU)は、バックホールリンクの無線リンク状態が劣化している期間、例えば、BH RLFが発生している期間内において、BH RLF Notificationを周期的に送信してもよい。この場合、BH RLF Notificationが周期的に送信される期間内では、BH RLFが発生していることになる。或いは、基地局機能部(DU)は、BH RLFが発生した際にBH RLF Notificationを送信し、BH RLFから復旧した際に復旧を示す通知(BH Recovered)を送信してもよい。以下においては、BH RLF Notificationの周期的な送信により、BH RLFの発生及びBH RLFからの復旧を下位装置に示す一例について主として説明する。
下位装置Bは、IABノード300からBH RLF Notificationを受信する期間内では、BH RLFが発生していると判定する。BH RLF Notificationの送信周期は、ドナー装置からIABノード300のユーザ装置機能部(MT)を介して基地局機能部(DU)に設定されてもよい。
BH RLF Notificationがマルチキャストで送信される場合、BH RLF Notificationを受信した下位装置Bは、BH RLF Notificationの受信に応じて、IABノード300に対するACK/NACKフィードバックの送信を開始してもよい。IABノード300は、配下の全ての下位装置B1乃至B3からACKを受信した場合、BH RLF Notificationの周期的な送信を停止してもよい。
BH RLF Notificationを受信した下位装置B1乃至B3は、接続先又は通信経路をIABノード300から切り替えるための処理を行ってもよい。このような処理としては、例えば、接続再確立処理、条件付きハンドオーバのトリガ処理、通信経路切替処理、ハンドオーバ用の測定報告処理が挙げられる。なお、下位装置B1乃至B3は、このような切り替え処理を開始した後、切り替え処理を完了するまでの間において、IABノード300からのBH RLF Notificationを受信しなくなった場合(又はBH RLFの復旧を示す通知を受信した場合)、IABノード300のバックホールリンクが復旧したと判定し、切り替え処理を中止してもよい。
例えば、BH RLF Notificationを受信した下位装置B1乃至B3は、IABノード300のセル以外のセルを探索するセルサーチを行い、適切なセルに対して接続再確立(RRC Reestablishment)を行う。ここで、下位装置B1乃至B3とIABノード300との間でRLFが発生していなくても、このような接続再確立処理を早期に行う。
接続再確立処理は、時間的に分散して実行するように制御されていてもよい。例えば、下位装置B1乃至B3は、ランダム値やUE-IDを用いて接続再確立処理の実行開始時間を決定することにより、下位装置B1乃至B3の接続再確立処理の実行開始時間を分散させ、負荷の集中を防ぐことができる。なお、BH RLF Notificationがユニキャストで送信される場合、基地局機能部(DU)がBH RLF Notificationの送信タイミングを分散させることにより、下位装置B1乃至B3の接続再確立処理の実行開始時間を分散させてもよい。
BH RLF Notificationを受信した下位装置B1乃至B3は、自身がIABノード300と、IABノード300以外の上位装置とに接続してDC通信を行っている場合、IABノード300を経由する通信経路を他の上位装置に切り替えてもよいし、他の通信装置にBH RLF Notificationを送信してもよい。例えば、下位装置Bは、IABノード300をマスタノード(MN)として設定し、他の上位装置をバックアップ用のセカンダリノード(SN)として設定している場合、MNを経由する通信経路をSNに切り替える。
BH RLF Notificationを受信した下位装置B1乃至B3は、自身に条件付きハンドオーバが設定されている場合、条件が満たされたとみなして、ハンドオーバを行ってもよい。ハンドオーバ条件がサービングセルの無線品質劣化を示すイベントである場合、サービングセルの無線品質測定結果を低く修正する(例えば、-200dBmとみなす)ことにより、強制的にハンドオーバをトリガしてもよい。
BH RLF Notificationを受信した下位装置B1乃至B3は、測定報告の送信をトリガしてもよい。ここで、一般的な測定報告はRRCメッセージで送信されるが、基地局機能部(DU)はRRCレイヤを有していない。このため、IABノード300は、バックホールリンクのRLFから復旧するまでは下位装置Bからの測定報告を保持し、BH RLFから(一時的に)復旧した際にドナー装置に転送し、ドナー装置が下位装置Bをハンドオーバさせてもよい。
BH RLF Notificationを受信した下位装置B4は、接続先の候補としてIABノード300を除外するための処理を行ってもよい。例えば、BH RLF Notificationを受信した下位装置B4は、RRCアイドル状態又はRRCインアクティブ状態におけるセル再選択動作において、IABノード300のセルの優先度を下げる、もしくは再選択対象から除外する、もしくはIABノード300についての受信電力測定値を低く調整することにより、接続先の候補としてIABノード300が除外されるようにしてもよい。ここで、受信電力測定値を低く調整するために、実際の受信電力測定値に対してオフセット値を適用してもよい。当該オフセット値は予め決められた固定値であってもよい。もしくは当該オフセット値はネットワークから通知された値であってもよく、当該通知は下位装置B4が現在キャンプしているセルの報知情報(SIB)によって通知されてもよい。
下位装置B4は、接続先の候補としてIABノード300を除外するための処理を、RRCコネクティッド状態に遷移する際のRRC Setup Request処理又はRRC Resume Request処理を開始する前のタイミングで行ってもよい。
具体的には、下位装置B4は、RRC Setup Requestを送信する前に、送信先候補のセルがBH RLF Notificationを通知しているか否かの確認を行う。下位装置B4は、送信先候補のセルがBH RLF Notificationを通知していない場合はRRC Setup Requestを送信する。送信先候補のセルがBH RLF Notificationを通知している場合はRRC Setup Requestの送信を停止(もしくは中止)し、前記セル再選択動作を行うことにより、適切なRRC Setup Request送信先を選択する。
下位装置B4は、IABノード300からのBH RLF Notificationを受信しなくなった場合(又はBH RLFの復旧を示す通知を受信した場合)、IABノード300のバックホールリンクが復旧したと判定し、接続先の候補としてIABノード300を除外するための処理を中止してもよい。
図7は、第1実施形態に係る動作の一例を示す図である。図7において、IABノード(Parent IAB node)300とドナーgNB(IAB doner)200との間に他のIABノードが介在してもよい。
図7に示すように、ステップS101において、IABノード300のユーザ装置機能部(MT)は、無線問題(radio problem)を検知する。
ステップS102において、IABノード300のユーザ装置機能部(MT)は、BH RLFを検知する(RLF declaration)。
ステップS103において、IABノード300のユーザ装置機能部(MT)は、BH RLFの発生を示す状態情報をIABノード300の基地局機能部(DU)に通知する。
ステップS104において、IABノード300の基地局機能部(DU)は、ユーザ装置機能部(MT)からの通知に応じて、BH RLF Notificationの周期的な送信を開始する。
ステップS105において、BH RLF Notificationを受信した下位装置Bは、接続先又は通信経路をIABノード300から切り替えるための処理を開始する。このような処理としては、例えば、接続再確立処理(Early RRC Re-establishment)、条件付きハンドオーバのトリガ処理(Triggering Conditional HO)、通信経路切替処理(Switching to redundant route)が挙げられる。
ステップS106において、IABノード300のユーザ装置機能部(MT)は、例えばT310動作中に接続再確立を行うことができず、T310の満了に応じてRRCアイドル状態に遷移する(Go to IDLE)。
ステップS107において、IABノード300のユーザ装置機能部(MT)は、RRCアイドル状態への遷移を示す状態情報をIABノード300の基地局機能部(DU)に通知する。
ステップS108において、IABノード300の基地局機能部(DU)は、ユーザ装置機能部(MT)からの通知に応じて、下位装置Bへのサービス提供を停止する(Service stopped)。
ステップS109において、下位装置Bは、IABノード300からのサービス提供が停止されたことにより、RLFを検知する。
[第1実施形態の変更例1]
次に、第1実施形態の変更例1について説明する。
上述した第1実施形態において、図7のステップS104及びS105に示すように、BH RLFを検知したIABノード300がBH RLF Notificationを下位装置Bに送信し、下位装置Bが、BH RLF Notificationの受信に応じて、接続先又は通信経路をIABノード300から切り替えるための処理を開始する一例について説明した。
本変更例では、下位装置Bは、IABノード300からのBH RLF Notificationの受信に応じて、IABノード300に対する上りリンク送信を停止する。具体的には、IABノード300においてBH RLFが発生している場合、IABノード300と下位装置Bとの間の無線状態が正常であっても、下位装置Bの上りリンク信号はドナー装置200に到達しない。このため、下位装置BがIABノード300からのBH RLF Notificationの受信に応じて上りリンク送信を停止することにより、消費電力及び干渉の増大を抑制できる。
すなわち、本変更例に係る通信制御方法は、UE100とドナー装置200との間に複数のIABノード300を用いた少なくとも1つの通信経路を形成可能な移動通信システム1において用いる通信制御方法であって、
1)当該複数のIABノード300に含まれるIABノード300が、このIABノード300の上位の上位装置AとIABノード300との間のBH RLF(BH RLF)を検知することと、
2)BH RLFの検知に応じて、IABノード300が、BH RLFに関する障害通知(BH RLF Notification)をIABノード300の下位の下位装置Bに送信することと、
3)下位装置Bが、IABノード300からのBH RLF Notificationの受信に応じて、IABノード300に対する上りリンク送信を停止することと、を有する。
下位装置Bは、IABノード300に対する上りリンク送信を停止するとともに、接続先又は通信経路をIABノード300から切り替えるための処理を開始してもよい。或いは、下位装置Bは、IABノード300に対する上りリンク送信を停止した状態でBH RLFの復旧を待ち、一定時間待ってもBH RLFが復旧しない場合、接続先又は通信経路をIABノード300から切り替えるための処理を開始してもよい。
下位装置Bにおける上りリンク送信の停止とは、次のa)乃至e)のうち少なくとも1つを含む。
a)下位装置BからIABノード300に対するスケジューリング要求(SR:Scheduling Request)の送信を停止する:
スケジューリング要求とは、上りリンク無線リソースの割当を要求する信号をいう。IABノード300からBH RLF Notificationを受信した下位装置Bは、このIABノード300に対するスケジューリング送信の送信を停止(禁止)する。
b)下位装置BからIABノード300に対するPUSCH(Physical Uplink Shared Channel)送信を停止する:
IABノード300からBH RLF Notificationを受信した下位装置Bは、このIABノード300から上りリンク無線リソース(PUSCHリソース)が割り当てられた場合、すなわち、上りリンクグラントを受信した場合であっても、この割当を適用せずに、PUSCH送信を停止(禁止)する。すなわち、IABノード300からBH RLF Notificationを受信した下位装置Bは、上りリンクデータ及び上りリンクRRCシグナリングの送信を停止(禁止)する。
c)下位装置Bの無線ベアラをサスペンドする:
無線ベアラをサスペンドするとは、無線ベアラの設定を保持しつつ、無線ベアラの使用を停止(禁止)することをいう。IABノード300からBH RLF Notificationを受信した下位装置Bは、このIABノード300に対応する全ての無線ベアラをサスペンドしてもよいし、これらの無線ベアラのうちシグナリング無線ベアラの使用を継続しつつデータ無線ベアラをサスペンドしてもよい。
d)下位装置BからIABノード300に対するPUCCH送信を停止する:
これはa)で述べたMACレイヤによるSR送信の停止、及び、PHYレイヤによるCSI(Channel State Information)のフィードバックなどの停止を包含し得る。
e)下位装置BからIABノード300に対するPRACH送信を停止する、もしくはランダムアクセスプロシージャの開始を規制する(行わない)。
本変更例において、下位装置Bは、IABノード300がBH RLFから復旧したと判定し、この判定に応じて上りリンク送信を再開してもよい。
例えば、BH RLFから復旧したことを示す通知(RLF Recovered)をIABノード300が下位装置Bに送信する前提下において、下位装置Bは、このRLF Recoveredの受信に応じて、IABノード300がBH RLFから復旧したと判定し、上りリンク送信を再開する。
一方、BH RLFの継続中はBH RLF NotificationをIABノード300が下位装置Bに周期的に(連続的に)送信する前提下において、下位装置Bは、BH RLF Notificationの送信が停止したことに応じて、IABノード300がBH RLFから復旧したと判定し、上りリンク送信を再開する。ここで、下位装置Bは、BH RLF Notificationを受信していない場合に、BH RLF Notificationの送信が停止したと判断してもよい。例えば、BH RLF Notificationを所定のタイミングで受信しなかった場合に、当該判断を実施する。ここで所定のタイミングとは、前記周期的に送信される場合における送信周期であってもよい。
なお、BH RLF Notificationの送信停止とは、例えば、下位装置Bがスケジューリング要求の送信を希望した時点で既に停止していた場合や、スケジューリング要求の送信を希望した時点から次のBH RLF NotificationタイミングでBH RLF Notificationが停止していた場合が含まれる。
詳細については第2実施形態において説明するが、移動通信システム1において二重接続(DC:Dual Connectivity)が適用されてもよい。図8は、本変更例において二重接続が適用される場合の構成を示す図である。
図8に示す構成において、下位装置Bは、IABノード300Mをマスタノード(MN)とし、且つIABノード300Sをセカンダリノード(SN)とする二重接続の通信を行っている。MNが下位装置Bに割り当てる1つ又は複数のセルはマスタセルグループ(MCG)と呼ばれる。SNが下位装置Bに割り当てる1つ又は複数のセルはセカンダリセルグループ(SCG)と呼ばれる。
図8において、IABノード300Mの上位装置A1及びIABノード300Sの上位装置A2は、IABノード300又はgNB200である。下位装置Bは、IABノード300又はUE100である。
このような二重接続の状況下において、MNであるIABノード300Mは、上位装置A1とのBH RLFを検知すると、BH RLF Notificationを下位装置Bに送信する。下位装置Bは、MNであるIABノード300MからのBH RLF Notificationの受信に応じて、IABノード300Mに対する上りリンク送信を停止するとともに、SNであるIABノード300Sに対する上りリンク送信を停止する。言い換えると、下位装置Bは、MNがBH RLFを検知した場合、全ての上りリンク送信(MCG及びSCGへの上りリンク送信)を停止する。
一方、SNであるIABノード300Sは、上位装置A2とのBH RLFを検知すると、BH RLF Notificationを下位装置Bに送信する。下位装置Bは、SNであるIABノード300SからのBH RLF Notificationの受信に応じて、MNであるIABノード300Mに対する上りリンク送信を停止せずに、SNであるIABノード300Sに対する上りリンク送信を停止する。言い換えると、下位装置Bは、SNがBH RLFを検知した場合、SNに対する上りリンク送信(SCGへの上りリンク送信)のみを停止する。
[第1実施形態の変更例2]
次に、第1実施形態の変更例2について説明する。
上述した実施形態において、IABノード300が、BH RLF NotificationをMACレイヤにおいて送信する一例について説明した。本変更例においては、このようなBH RLF Notificationを受信した下位装置Bは、MACレイヤにおいて受信したBH RLF Notificationに関して上位レイヤに通知する。
すなわち、本変更例に係る通信制御方法は、UE100とドナー装置200との間に複数のIABノード300を用いた少なくとも1つの通信経路を形成可能な移動通信システム1において用いる通信制御方法であって、
1)当該複数のIABノード300に含まれるIABノード300が、このIABノード300の上位の上位装置AとIABノード300との間のBH RLFを検知することと、
2)BH RLFの検知に応じて、IABノード300のMACレイヤが、BH RLFに関する障害通知(BH RLF Notification)をIABノード300の下位の下位装置Bに送信することと、
3)下位装置BのMACレイヤが、IABノード300からの障害通知の受信に応じて、障害通知を受信した旨を下位装置Bの上位レイヤに通知することと、を有する。
図9は、本変更例に係る動作を示す図である。図9の(1)は、下位装置BがIABノード300である一例を示している。図9の(2)は、下位装置BがUE100である一例を示している。上位装置Aは、IABノード300であってもよいし、gNB200(ドナー装置)であってもよい。
図9の(1)に示すように、IABノード300は、MTと、BAPレイヤと、DUとを有する。BAPレイヤの少なくとも一部は、MTに含まれていてもよいし、DUに含まれていてもよい。IABノード300のDUは、MACレイヤを有する。また、DUは、図示を省略するPHYレイヤ及びRLCレイヤも有する。下位装置B(下位のIABノード)のMTは、MACレイヤと、RRCレイヤとを有する。また、DUは、図示を省略するPHYレイヤ及びRLCレイヤも有する。
図9の(2)に示すように、IABノード300は、図9の(1)と同様に構成されている。下位装置B(UE100)は、MACレイヤと、PDCPレイヤと、RRCレイヤとを有する。また、UE100は、図示を省略するPHYレイヤ及びRLCレイヤも有する。
図9に示すような構成において、IABノード300のMTがBH RLFを検知すると、IABノード300のDUのMACレイヤは、このBH RLFの検知に応じて、BH RLF Notificationを下位装置Bに送信する。BH RLF Notificationは、MAC CE(Control Element)に含まれていてもよい。下位装置BのMACレイヤは、BH RLF Notificationを受信すると、BH RLF Notificationを受信した旨を下位装置Bの上位レイヤに通知する。上位レイヤへの通知は、IABノード300においてBH RLFが検知されたことを示す通知であってもよいし、対応する通信経路(或いはIABノード300と下位装置Bとの間の無線リンク)が使用不能である旨の通知であってもよい。
下位装置BにおいてMACレイヤからの通知先となる上位レイヤは、RRCレイヤ、BAPレイヤ、及びPDCPレイヤのうち少なくとも1つを含む。上位レイヤは、第1実施形態で説明したような処理、すなわち、接続先又は通信経路をIABノード300から切り替えるための処理を行ってもよいし、第1実施形態の変更例1で説明したような処理、すなわち、上りリンク送信を停止してもよい。
下位装置Bにおいて、MACレイヤからの通知を受けたRRCレイヤは、例えば次の処理のうち少なくとも1つを実行する。
・上りリンク送信を停止する(第1実施形態の変更例1参照)。
・リダンダンシリンクの確立を試みる。例えば、下位装置Bが下位IABノードであり、下位IABノードが複数のMTを有する場合、RRCレイヤは、BH RLF Notificationを受信したMT以外のMTによりリンクを確立する。
・RRCレイヤは、別のセル(別の上位装置)へRRC再確立処理(RRC Reestablishment)を行う。
・下位装置Bが二重接続を有しており、下位装置BがSN(SCG)からBH RLF Notificationを受信した場合、RRCレイヤは、MN(MCG)へ通知(SCG Failure Indication)を送信する。
・下位装置Bが二重接続を有しており、下位装置BがMN(MCG)からBH RLF Notificationを受信した場合、RRCレイヤは、SN(SCG)へ通知(MCG Failure Indication)を送信する。
また、下位装置Bにおいて、MACレイヤからの通知を受けたBAPレイヤ又はPDCPレイヤは、下位装置Bが二重接続を有している場合、バッファしたアップストリームデータを別リンクへ転送(再ルーティング)する。例えば、下位装置BがSN(SCG)からBH RLF Notificationを受信した場合、BAPレイヤ又はPDCPレイヤは、MN(MCG)にアップストリームデータを転送する。一方、下位装置BがMN(MCG)からBH RLF Notificationを受信した場合、BAPレイヤ又はPDCPレイヤは、SN(SCG)にアップストリームデータを転送する。もしくは、BAPレイヤ又はPDCPレイヤは、BH RLFが発生しているルート(上位ノード)とリンクを確立しているRLCチャネル(すなわちRLCエンティティ)へのアップストリームデータの送信を停止する。
なお、本変更例において、BH RLF NotificationがMACレイヤにおいて送受信される一例について説明したが、BH RLF Notificationは、例えばRRCレイヤにおいて送受信されてもよい。このような前提下において、下位装置BのRRCレイヤは、BH RLF Notificationを受信すると、BH RLF Notificationを受信した旨を他のレイヤ(例えば、BAPレイヤ及び/又はMACレイヤ)に通知する。
或いは、BH RLF Notificationは、BAPレイヤにおいて送受信されてもよい。このような前提下において、下位装置BのBAPレイヤは、BH RLF Notificationを受信すると、BH RLF Notificationを受信した旨を他のレイヤ(例えば、RRCレイヤ及び/又はMACレイヤ)に通知する。
[第1実施形態の変更例3]
次に、第1実施形態の変更例3について説明する。
上述した第1実施形態において、図7のステップS104に示すように、IABノード300が、BH RLFが発生している期間内においてBH RLF Notificationを周期的に(連続的に)送信する一例について説明した。この送信周期は、移動通信システム1の仕様で規定された一定周期としてもよいが、本変更例では、この送信周期を可変とする。
すなわち、本変更例に係る通信制御方法は、UE100とドナー装置200との間に複数のIABノード300を用いた少なくとも1つの通信経路を形成可能な移動通信システム1において用いる通信制御方法であって、
1)当該複数のIABノード300に含まれるIABノード300が、このIABノード300の上位の上位装置AとIABノード300との間のBH RLFを検知することと、
2)BH RLFの検知に応じて、IABノード300が、BH RLFに関する障害通知(BH RLF Notification)をIABノード300の下位の下位装置Bに繰り返し送信することと、
3)IABノード300が、障害通知の繰り返し送信のタイミングに関するタイミング情報を下位装置Bに送信することと、を有する。
これにより、障害通知(BH RLF Notification)の送信周期を可変とすることができる。周期を短くすると、頻繁に送信することになるので、上位ノードがBH RLFから復旧した際に、下位ノードは当該復旧を迅速に知ることができ、UL送信再開などのリカバリ動作を素早く行うことができるメリットがある。一方で、送信/受信に要する消費電力が増えてしまったり、干渉が増えたりするデメリットがある。周期を長くした場合は、上記メリット/デメリットが逆転する。よって、障害通知(BH RLF Notification)の送信周期は、ネットワーク設計ポリシーに応じて最適値に調整され得る。
なお、繰り返し送信とは、周期的な送信であってもよいし、非周期的な送信であってもよい。BH RLF Notificationを周期的に送信する場合において、IABノード300が送信するタイミング情報は、BH RLF Notificationの送信周期を示す情報を含む。BH RLF Notificationを非周期的に送信する場合において、IABノード300が送信するタイミング情報は、BH RLF Notificationの送信タイミングに対応するサブフレーム番号を示す情報を含んでもよい。
IABノード300は、タイミング情報を含むSIBをブロードキャストにより送信してもよい。或いは、ドナー装置は、タイミング情報を含むRRCメッセージ(RRC Reconfigurationメッセージ)を、IABノード300を介して下位装置Bに送信してもよい。
或いは、IABノード300は、BH RLF Notificationと共にタイミング情報を下位装置Bに送信してもよい。具体的には、IABノード300は、タイミング情報を含むBH RLF Notificationを送信する。例えば、1つのBH RLF Notificationに含まれるタイミング情報は、次回のBH RLF Notificationの送信タイミングに対応するサブフレーム番号を示す情報を含んでもよい。なお、上述したように、BH RLF Notificationは、MACレイヤにおいて送受信されてもよい。
また、BH RLFを検知したIABノード300は、バックホールリンクの再確立を試行する期間において、BH RLF Notificationを下位装置Bに繰り返し送信してもよい。具体的には、BH RLFを検知したIABノード300は、バックホールリンクのRRC再確立に失敗しても、バックホールリンクのRRC再確立の試行を継続する期間内において、BH RLF Notificationの送信を継続する。そして、この期間内でRRC再確立に成功しない場合、IABノード300のDUは、BH RLF Notificationの送信を停止するとともに、下位装置Bに対するサービス提供を停止する(すなわち、PSS/SSS/MIB/SIB1を停止する)。また、IABノード300のMTは、RRCアイドル状態に遷移する。
[第2実施形態]
次に、第1実施形態及びその変更例に係る動作を前提として第2実施形態について説明する。但し、第1実施形態とは異なる点を主として説明し、第1実施形態と重複する説明を省略する。
第2実施形態は、二重接続(DC)を想定した実施形態であって、第1実施形態及びその変更例に係る動作と併用することが可能である。
(動作例1)
図10は、第2実施形態の動作例1を示す図である。
図10に示すように、IABノード300は、上位装置A1をMNとし、且つ上位装置A2をセカンダリノード(SN)とする二重接続の通信を行っている。IABノード300には、下位装置Bが無線で接続されている。下位装置Bは、下位IABノード又はUEである。
IABノード300は、MNである上位装置A1との間に通信経路のためのバックホールリンクを設定せずに、上位装置A1がIABノード300を制御するための制御用リンクを設定している。IABノード300は、SNである上位装置A2との間に通信経路のためのバックホールリンクを設定している。
二重接続を有するIABノード300がMNとのバックホールリンク及びSNとのバックホールリンクの両方を設定している場合、SNとのバックホールリンクにBH RLFが発生しても、MNとのバックホールリンクにBH RLFが維持される限りは、IABノード300が下位装置BにBH RLF Notificationを送信する必要は無いと考えられる。SNとのバックホールリンクにBH RLFが発生しても、MNとのバックホールリンクが維持される限りは、下位装置BがIABノード300に対する接続を維持してよいためである。
一方、二重接続を有するIABノード300がMNとのバックホールリンクを設定していない場合、IABノード300は、下位装置BのデータをMNと送受信できない。このため、SNとのバックホールリンクにBH RLFが発生した場合、下位装置BがIABノード300を介したデータ送受信が不可になってしまうため、IABノード300が下位装置BにBH RLF Notificationを送信するべきである。
すなわち、本動作例に係る通信制御方法は、UE100とドナー装置200との間に複数のIABノード300を用いた少なくとも1つの通信経路を形成可能な移動通信システム1において用いる通信制御方法であって、
1)複数のIABノード300に含まれるIABノード300が、IABノード300の上位の上位装置A2をSNとし、且つ、他の装置(上位装置A1)をMNとした二重接続の通信を行うことと、
2)IABノード300とMNとの間に通信経路のためのバックホールリンクを設定せずに、IABノード300とSNとの間にバックホールリンクを設定することと、
3)IABノード300が、IABノード300とSNとの間のBH RLFを検知することと、BH RLFの検知に応じて、IABノード300が、BH RLFに関する障害通知(BH RLF Notification)をIABノード300の下位の下位装置Bに送信することと、を有する。
具体的には、本動作例において、二重接続の通信を行うIABノード300は、MNとの間にバックホールリンクが設定されているか否かに応じて、障害通知を下位装置Bに送信するか否かを決定する。具体的には、IABノード300は、MNとの間にバックホールリンクが設定されていない場合、IABノード300とSNとの間のBH RLFの検知に応じて、障害通知を下位装置Bに送信すると決定する。一方、MNとの間にバックホールリンクが設定されている場合、IABノード300は、IABノード300とSNとの間のBH RLFを検知しても、障害通知を下位装置Bに送信しないと決定する。
本動作例において、LTE及びNRによる二重接続(DC)、すなわち、EN-DC(E-UTRA(Evolved Universal Terrestrial Radio Access)-NR Dual Connectivity)を想定してもよい。このような想定下において、MN(上位装置A1)はLTEの装置であって、SN(上位装置A2)はNRの装置である。例えば、MN(上位装置A1)は、LTE基地局であるeNBであって、SN(上位装置A2)は、NR基地局であるgNB(ドナー装置200)又は上位IABノードである。
本動作例において、NRのみによる二重接続(DC)、すなわち、NR-DC(NR Dual Connectivity)を想定してもよい。このような想定下において、MN(上位装置A1)はNRの装置であって、SN(上位装置A2)もNRの装置である。例えば、MN(上位装置A1)は、NR基地局であるgNB又は上位IABノードであって、SN(上位装置A2)は、NR基地局であるgNB又は上位IABノードである。
本動作例において、IABノード300は、バックホールリンクとして用いられるか否かを示す設定情報をドナー装置200から受信し、この設定情報に基づいてバックホールリンクを設定及び識別してもよい。設定情報は、CG(Cell Group)毎もしくはベアラ毎にバックホールリンクに用いられているか否かを示す情報であってもよい。
(動作例2)
図11は、第2実施形態の動作例2を示す図である。
図11に示すように、下位装置Bは、上位装置A1をMNとし、且つIABノード300をセカンダリノード(SN)とする二重接続の通信を行っている。下位装置Bは、下位IABノード又はUEである。このような前提下において、IABノード300は、IABノード300の上位装置A2とのBH RLFを検知した場合、BH RLF Notificationを下位装置Bに送信する。この場合、SNであるIABノード300においてBH RLFが発生したことをMN(上位装置A1)が把握できることが好ましい。なお、上位装置A1はIABノード又は基地局であって、上位装置A2はIABノード又は基地局(ドナー装置200)である。
すなわち、本動作例に係る通信制御方法は、UE100とドナー装置200との間に複数のIABノード300を用いた少なくとも1つの通信経路を形成可能な移動通信システム1において用いる通信制御方法であって、
1)IABノード300の下位の下位装置Bが、IABノード300をSNとし、且つ、他の装置(上位装置A1)をMNとした二重接続の通信を行うことと、
2)IABノード300が、IABノード300の上位の装置(上位装置A2)とIABノード300との間のBH RLFを検知すると、第1障害通知(BH RLF Notification)を下位装置Bに送信することと、
3)下位装置Bが、SNであるIABノード300からの第1障害通知の受信に応じて、SNにおけるBH RLFを示す第2障害通知(Failure Indication)をMNに送信することと、を有する。
なお、下位装置Bは、下位装置BとIABノード300との間のRLFを検知した場合、SCG Failure IndicationをMNに送信してもよい。一方、第2障害通知(Failure Indication)は、下位装置BとIABノード300との間でRLFが検知されていなくても、IABノード300と上位装置A2との間でBH RLFが発生した場合には、下位装置BからMNに送信されるものである。なお、第2障害通知(Failure Indication)は、SCG Failure Indicationメッセージ中の情報要素としてもよいし、SCG Failure Indicationメッセージとは異なるメッセージとしてもよい。
下位装置Bは、SCG障害の原因(Cause)を示す情報として、“BH RLF”を第2障害通知(Failure Indication)に含めてもよい。第2障害通知(Failure Indication)は、IABノード300又はそのセルを示す識別子を含んでもよい。
下位装置Bから第2障害通知(Failure Indication)を受信した上位装置A1(MN)は、SNであるIABノード300側のリンクを他の上位装置に繋ぎ変えるために、SN変更(Secondary Node Change)等の処理を行う。また、上位装置A1(MN)は、第2障害通知(Failure Indication)に基づいて、DC設定が切断した(failした)と判断し、SNであるIABノード300におけるUEコンテキストを解放する処理を実行してもよい。例えば、上位装置A1(MN)とIABノード300(SN)との間のインターフェイスを介して、UEコンテキスト解放メッセージを上位装置A1(MN)からIABノード300(SN)に送信する。
(動作例3)
図12は、第2実施形態の動作例3を示す図である。
図12に示すように、IABノード300は、MN300M及びSN300Sとの二重接続の通信を行っている。MN300M及びSN300Sのそれぞれは上位IABノードである。MN300Mは、自身の上位装置A1とのBH RLFを検知すると、BH RLF NotificationをIABノード300に送信する。SN300Sは、自身の上位装置A2とのBH RLFを検知すると、BH RLF NotificationをIABノード300に送信する。上位装置A1及びA2のそれぞれは上位IABノード又は基地局である。なお、IABノード300とMN300Mとの間のリンクであるMCGリンクにRLFが発生しておらず、且つIABノード300とSN300Sとの間のリンクであるSCGリンクにRLFが発生していないものとする。
このような前提下において、IABノード300は、MN300M及びSN300Sの両方からBH RLF Notificationを受信した場合に限り、下位装置Bに対してBH RLF Notificationを送信する。言い換えると、IABノード300は、MN300M及びSN300Sのうち一方のみからBH RLF Notificationを受信した場合には、下位装置Bに対してBH RLF Notificationを送信しない。
すなわち、本動作例に係る通信制御方法は、UE100とドナー装置200との間に複数のIABノード300を用いた少なくとも1つの通信経路を形成可能な移動通信システム1において用いる通信制御方法であって、
1)当該複数のIABノード300に含まれるIABノード300が、MN300M及びSN300Sとの二重接続の通信を行うことと、
2)MN300Mが、MN300Mの上位装置A1とMN300Mとの間のBH RLFを検知すると、第1障害通知(BH RLF Notification)をIABノード300に送信することと、
3)SN300Sが、SN300Sの上位装置A2とSN300Sとの間のBH RLFを検知すると、第2障害通知(BH RLF Notification)をIABノード300に送信することと、
4)IABノード300が、第1障害通知及び第2障害通知の両方を受信した場合、IABノード300の下位の下位装置Bに対して第3障害通知(BH RLF Notification)を送信することと、を有する。
ここで、IABノード300は、IABノード300とMN300Mとの間及びIABノード300とSN300Sとの間においてRLFが発生していなくても、第1障害通知及び第2障害通知の両方を受信した場合には、下位装置Bに対して第3障害通知(BH RLF Notification)を送信する。言い換えると、IABノード300は、自身の無線状態が良好であっても、MN300M及びSN300Sの両方でBH RLFが検知された場合には、下位装置Bに対して第3障害通知(BH RLF Notification)を送信する。
IABノード300は、第1障害通知及び第2障害通知の両方を受信した場合、IABノード300におけるBH RLFが発生したと見なしてもよい。IABノード300は、BH RLFが発生したと見なすことにより、結果的にBH RLF Notificationを下位装置Bへ送信することになる。また、IABノード300は、BH RLFが発生したと見なすことにより、別の上位装置に対するRRC再確立を実施するなどの動作を行ってもよい。
本動作例において、IABノード300は、第1障害通知及び第2障害通知の両方を受信し、且つ、IABノード300のバックホール通信が復旧しない状態が一定時間継続したと判定した場合、下位装置Bに対して第3障害通知を送信してもよい。すなわち、IABノード300は、第1障害通知及び第2障害通知の両方を受信して直ちに下位装置Bに第3障害通知を送信するのではなく、第1障害通知及び第2障害通知の両方を受信した後の一定時間内において自身のバックホール通信が復旧しないことを確認したうえで下位装置Bに対して第3障害通知を送信する。一方、IABノード300は、第1障害通知及び第2障害通知の両方を受信した後の一定時間内において自身のバックホール通信が復旧したと判定した場合、下位装置Bに対して第3障害通知を送信しない。
図13は、本動作例におけるIABノード300の動作フロー図である。ここでは、MN300M及びSN300Sのそれぞれが、BH RLFを検知している期間内においてBH RLF Notificationを周期的に(連続的に)送信するものとする。
図13に示すように、ステップS201において、IABノード300は、MN300M(MCG)及びSN300S(SCG)の両方、すなわち、全てのCGからBH RLF Notificationを受信したか否かを判定する。
全てのCGからBH RLF Notificationを受信した場合(ステップS201:Yes)、ステップS202において、IABノード300は、一定時間に対応するタイマを起動する。このタイマの値は、MN300M又は上位装置A1(例えばドナー装置)がIABノード300に設定してもよい。
ステップS203において、IABノード300は、MN300M(MCG)及びSN300S(SCG)の両方、すなわち、全てのCGからのBH RLF Notificationの受信が継続しているか否かを判定する。ステップS203において「No」である場合、処理がステップS201に戻る。
ステップS203において「Yes」である場合、ステップS204において、IABノード300は、ステップS202で起動したタイマが満了したか否かを判定する。ステップS204において「No」である場合、処理がステップS203に戻る。
ステップS204において「Yes」である場合、ステップS205において、IABノード300は、BH RLF Notificationを下位装置Bに送信する。或いは、ステップS204において「Yes」である場合、ステップS205において、IABノード300は、自身のBH RLFが発生したと見なしてもよい。
図13において、MN300M及びSN300Sのそれぞれが、BH RLFを検知している期間内においてBH RLF Notificationを周期的に(連続的に)送信することを想定している。しかしながら、第1実施形態において説明したように、MN300M及びSN300Sのそれぞれは、BH RLFから復旧した際に復旧を示す通知(BH Recovered)を送信してもよい。
このような通知(BH Recovered)を用いる前提下においては、IABノード300は、ステップS203において、少なくとも一方のCGからBH Recoveredを受信したか否かを判定してもよい。そして、IABノード300は、少なくとも一方のCGからBH Recoveredを受信した場合、ステップS201に処理を戻す。一方、IABノード300は、いずれのCGからもBH Recoveredを受信していない場合、ステップS204に処理を進める。
また、図13のステップS203において「No」と判定するケースとしては、IABノード300が、両方のCGからBH RLF Notificationを受信した後、別の上位装置に対するRRC再確立に成功したケースが含まれる。
(動作例4)
図14は、第2実施形態の動作例4を示す図である。
図14に示すように、下位装置Bは、MN300M及びSN300Sとの二重接続(NR-DC)の通信を行っている。下位装置Bは、IABノード又はUEである。MN300M及びSN300Sのそれぞれは、IABノードである。MN300Mと上位装置A1との間にはバックホールリンクが設定されており、SN300Sと上位装置A2との間にはバックホールリンクが設定されている。
本動作例においては、MN(MCG)及びSN(SCG)の両方がバックホールリンクに設定されている場合、MN(MCG)からのみBH RLF Notificationの送信が許可される。
すなわち、本動作例に係る通信制御方法は、UE100とドナー装置200との間に複数のIABノード300を用いた少なくとも1つの通信経路を形成可能な移動通信システム1において用いる通信制御方法であって、
1)当該複数のIABノード300に含まれるMN300M及びSN300Sとの二重接続の通信を下位装置Bが行うことと、
2)MN300Mが上位装置A1とMN300Mとの間のBH RLFを検知すると、MN300Mが第1障害通知(BH RLF Notification)を下位装置Bに送信することと、
3)SN300SがSN300Sの上位装置A2とSN300Sとの間のBH RLFを検知すると、MN300Mが第2障害通知(BH RLF Notification)を下位装置Bに送信することとを有する。
本動作例において、SN300SのBH RLFが発生した場合、SN300Sは、MN300MとSN300Sとの間のインターフェイスを用いて、SN300SのBH RLFに関する情報をSN300SからMN300Mに送信する。SN300Sの上位装置A2がSN300SのBH RLFを検知可能である場合、上位装置A2からドナー装置200を介してSN300SのBH RLFに関する情報をMN300Mに送信してもよい。
ここで、第1障害通知(BH RLF Notification)は、MN300MのBH RLFの発生を示す情報を含み、第2障害通知(BH RLF Notification)は、SN300SのBH RLFの発生を示す情報を含む。これにより、下位装置Bは、BH RLF Notificationの送信をMN300Mのみが行う場合であっても、BH RLF Notificationに含まれる情報に基づいてBH RLFがMN300M及びSN300Sのいずれで発生したかを把握できる。
本動作例において、SN300Sは、ドナー装置200(CU)からの通知又はMN300Mからの通知に基づいて、MN300Mがバックホールリンクを有するか否かを特定する。SN300Sは、MN300Mがバックホールリンクを有する場合、SN300Sから下位装置BへのBH RLF Notificationの送信を禁止する。一方、SN300Sは、MN300Mがバックホールリンクを有しない場合、SN300Sから下位装置BへのBH RLF Notificationの送信を可能とする。
(動作例5)
図15は、第2実施形態の動作例5を示す図である。
図15に示すように、下位装置Bは、MN300M及びSN300Sとの二重接続の通信を行っている。MN300M及びSN300Sのそれぞれは、IABノードである。MN300Mと上位装置A1との間にはバックホールリンクが設定されており、SN300Sと上位装置A2との間にはバックホールリンクが設定されている。本動作例においては、MN300MとSN300Sとの間にインターフェイスが存在しないものとする。
本動作例において、下位装置Bは、SN300SのBH RLFが発生している場合、SN300S宛てのメッセージをMN300Mから受信し、受信したメッセージをSN300Sに転送する。SN300S宛てのメッセージとは、例えば基地局間インターフェイス(Xnインターフェイス)用のメッセージ、又はCU・DU間インターフェイス(F1インターフェイス)用のメッセージであって、SN300Sを解放するための解放メッセージである。
すなわち、本動作例に係る通信制御方法は、UE100とドナー装置200との間に複数のIABノード300を用いた少なくとも1つの通信経路を形成可能な移動通信システム1において用いる通信制御方法であって、
1)当該複数のIABノード300に含まれるMN300M及びSN300Sとの二重接続の通信を下位装置Bが行うことと、
2)SN300Sが上位装置A2とSN300Sとの間のBH RLFを検知した後、下位装置Bが、SN300S宛てのメッセージをMN300Mから受信することと、
3)下位装置Bが、MN300Mから受信したメッセージをSN300Sに転送することと、を有する。
これにより、SN300SのBH RLFが検知され、MN300MとSN300Sとの間にインターフェイスが存在しない場合であっても、SN300Sは、MN300Mからのメッセージを受信できる。
本動作例は、次の手順を含む。
第1に、下位装置Bは、SN300SのBH RLFを示すBH RLF NotificationをSN300Sから受信する。下位装置Bは、SN300SのBH RLFを示すBH RLF NotificationをMN300Mから受信してもよい(動作例4参照)。下位装置Bは、SN300SのBH RLFを示すBH RLF NotificationをSN300Sから受信すると、Failure IndicationをMN300Mに送信してもよい(動作例2参照)。
第2に、MN300M又はドナー装置200は、ネットワークインターフェース(Xn/F1等)の中継を下位装置Bに指示する。MN300M又はドナー装置200は、下位装置Bのルーティングテーブル情報に例外ルーティングの設定を行ってもよい。この設定は、SN300S又はそのセルのID、及びSN300SのBAPレイヤのエンティティのIDのいずれかを含む。下位装置Bは、SN300Sに対して、下位装置Bを経由する例外ルーティングが設定されたことの通知、又は下位装置Bを経由する例外ルーティングの要求を行ってもよい。下位装置Bは、下位装置Bを経由する中継ルートが確立できたか否かをMN300M又はドナー装置200に通知(応答)してもよい。中継ルートが確立不可(NG)の通知の場合、その原因を示す情報として、SN300Sの拒否、下位装置Bの拒否などの情報を通知に含めてもよい。
第3に、MN300M又はドナー装置200は、中継ルートへネットワークインターフェースのメッセージ(例えば、Secondary Node Releaseメッセージ)を送信する。当該メッセージはカプセル化され、例えばRRCメッセージ又はBAP制御メッセージにより運ばれる。
第4に、下位装置Bは、カプセル化されたメッセージを、上述した例外ルーティング情報に従ってSN300Sへ転送する。
第5に、SN300Sは、カプセル化されたメッセージを受信し、受信したメッセージに準じる動作を行う。例えば、SN300Sは、Secondary Node Release受信時に、無線リソースの使用停止などの処理を行う。SN300Sは、Secondary Node Release Acknowledgeを、例外ルーティングを用いて、下位装置B経由でMN300M又はドナー装置200に対して返してもよい。
[その他の実施形態]
上述した各実施形態及びその変更例において、移動通信システム1が5G移動通信システムである一例について主として説明した。しかしながら、移動通信システム1における基地局はLTE基地局であるeNBであってもよい。また、移動通信システム1におけるコアネットワークはEPC(Evolved Packet Core)であってもよい。さらに、gNBがEPCに接続することもでき、eNBが5GCに接続することもでき、gNBとeNBとが基地局間インターフェイス(Xnインターフェイス、X2インターフェイス)を介して接続されてもよい。
上述した各実施形態及びその変更例に係る各処理をコンピュータに実行させるプログラムが提供されてもよい。また、プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、CD-ROMやDVD-ROM等の記録媒体であってもよい。UE100、gNB200、又はIABノード300が行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップセットが提供されてもよい。
なお、各図において示されるフローは、適宜組み合わされても良い。
[付記]
(導入)
バックホールリンクの無線リンク障害(BH RLF)について、RAN2は次の合意に達した。
・R2は、少なくともダウンストリームノードへのBHリンクRLFにおけるRLF通知があると想定する。
・BHリンクの障害における回復時に、(合意されている場合)代替ルート及び/又はデュアルコネクティビティを利用され得る。
・現在のUE RLFの検出及び回復はベースラインとして再利用される。
・例えば、リンクが回復したとき、または回復が進行中のとき、他のインディケーションが必要かどうかは更なる検討が必要である。
合意に加えて、RAN2は、ダウンストリームノード向けのRLF通知及びアップストリームノード向けのRLF通知を含むRLF通知の詳細を議論した。
この付記では、BH RLFハンドリングの残りの問題、特にダウンストリームノードへのRLF通知に焦点を当てて議論する。
なお、この付記では、「親」ノードが「子」ノードにRLF通知を送信するという関係を想定する。
(議論)
(RLF通知およびその他のインディケーション)
Rel-15 UEは、引き続きIABノードとの接続を許可されるが、合意された「RLF通知」はRel-16機能であることに注意すべきである。Rel-15 UEでもサービスの停止を最小限に抑えるためには、バックホールリンクを回復することに失敗した場合、IABノードはSSB(PSS、SSS、及びPBCH)の送信を停止すべきである。なぜならば、IABノードがバックホールリンクなしではサービスを継続できないことは明らかであり、またRel-15 UEに対して意図的に無線問題を生み出すからである。
所見1:合意された「RLF通知」はRel-15 UEでは機能できない。
提案1:RAN2は、バックホールリンクを回復することに失敗した場合、IABノードがSSBの送信を停止することに合意すべきである。
また、提案1は、バックホールリンクが回復することに失敗するまで、IABノードはサービスを提供し続けてもよいことを暗示する。次に、「例えば、リンクが回復したとき、または回復が進行中のとき、他のインディケーションが必要かどうかは更なる検討が必要である」ように、バックホールリンク状態についてダウンストリームのMT/UEに通知する価値があるかどうかを更に検討する必要がある。ただし、BH RLF中にRLF通知が繰り返し送信される場合は、「その他のインディケーション」を指定する必要はない。言い換えれば、RLF通知が送信されない場合、BH RLFは発生していない、又はすでに回復されており、そうでない場合は、バックホールリンクの回復が進行中である。したがって、論点は、BH RLF中にRLF通知を繰り返し送信するかどうかである。
提案2:RAN2は、RLF通知がBH RLF中に繰り返し送信されることに合意すべきである。
(RRCコネクティッド)
BH RLFが親IABノードで発生している間、アップリンクデータが子IABノード/UEからIABドナーに到達できないことは明らかである。アップリンク送信が続く場合、子IABノード/UEでの電力消費、親IABノードでのバッファのオーバーフローのリスク、及びネットワークでの干渉などの不要な問題を発生させる可能性がある。したがって、子ノード/UEは、少なくとも新しいデータ送信においてSR送信を控えるべきである。
提案3:RAN2は、RLF通知を受信時に、MT/UEがアップリンク信号、つまりデータ送信用のSRを停止することに合意すべきである。
親IABノードがそのバックホールリンクでRLFを受けるとRLF通知が送信されるが、そのアクセスリンクはまだ良好である可能性がある。言い換えると、RLFは、親IABノードと子IABノードとの間のリンクでは発生していない。RAN2は「現在のUE RLF検出及び回復はベースラインとして再利用される」ことに合意しているため、子ノード/UEはRLFを宣言せず、この場合はRLF通知をトリガしない。
追加ルールとしてRLF通知の受信が既存のRLFをトリガする場合、さらにそれはダウンストリームノードへのRLF通知の送信をトリガし、それはIABトポロジ間ですぐに伝搬される。これは、全てのIABノードに同時にRRC再確立を開始させ、IABトポロジを壊す可能性がある。したがって、RLF通知の受信はRRC再確立をトリガしない。
提案4:RAN2は、MT/UEがRLF通知の受信時にRRC再確立の開始を含むRLFを宣言せず、RLF通知の送信もトリガしないことに合意すべきである。
(RRCアイドル)
別の態様は、RRCアイドルでのMT/UEのふるまいである。提案3が同意できる場合、アイドルモードのMT/UEがBH RLFを受ける親IABノードへのRRCセットアップ要求を開始することを控えることは、非常に簡単である。これにより、一種のアクセス制限と見なすことができる。たとえRRCセットアップ要求メッセージが送信された場合でも、BH RLFのためにIABドナー(つまり、ピアRRCエンティティを有するCU)に転送できず、手順は結局失敗する。
提案5:RAN2は、RRCアイドルであるMT/UEが、RLF通知を送信している親IABノードへのRRCセットアップ要求を開始することを控えるべきであることに合意すべきである。
論点は、セル再選択プロセスがBH RLFをどのようにハンドリングするか、つまり、BH RLFを送信する親IABノードが再選択の候補セルであるかどうかである。BH RLFが短時間で回復され得る場合、そのような最適化は必要ない。そうではない場合、MT/UEが結局BHリンクなしにセルでRRC接続を確立できないため、悪いユーザーエクスペリエンスを引き起こす可能性がある。
提案6:RAN2は、RRCアイドルのMT/UEが、RLF通知を送信する親IABノードを再選択できるかどうかについて議論すべきである。
(デュアルコネクティビティの場合の検討)
デュアルコネクティビティは複雑なシナリオの1つですが、RAN2は「BHリンクの障害における回復時に、(合意されている場合)代替ルート及び/又はデュアルコネクティビティを利用され得る」ことに合意した。これは、親がデュアルコネクティビティを有するケース(つまり、図17のケース1)、及び子がデュアルコネクティビティを有するケース(つまり、図17のケース2)の2つのケースに分類できる。
(ケース1(親がDCで設定される)
ケース1では、RLF通知はMCG RLF又はSCG RLFのいずれかによってトリガされてもよい。EN-DC(つまり、CプレーンがLTE Uu上にある)の場合、RN2が「EN-DCを使用するIABノードの場合、BAPおよびバックホールRLCチャネルの観点から、これは単一リンクの展開(NRリンクによるBAPルートのみ)である」ことに合意したように、バックホールリンクにMCGを使用することは想定されていない。したがって、RLFがSCGリンクでのみ発生する場合でも、IABトポロジの観点からは、BH RLFと見なすべきである。これは、RLF通知がSCG RLFで親IABノードによって送信されるべきであることも意味する。
所見2:EN-DCで設定されたIABノードの場合、SCG RLFはRLF通知をトリガすべきである。
一方、NR-DCの場合、バックホールリンクはSCGのみ、又はSCG及びMCGの両方に設定されてもよい。言うまでもなく、前者のケース(SCGのみのBH)はEN-DCのケースと同様である。後者の場合(MCG及びSCGの両方でBH)、SCG RLFがRLF通知をトリガしないことは明らかですが、MCG RLFが常にRLF通知をトリガするかどうかは疑わしい。
現在の仕様では、UEは、MCG RLFでSCGへのUL送信を停止(RRC再確立で「SRB0を除く全てのRBをサスペンド」)する。これにより、BH RLFと見なすことができる。一方、MCG RLFが発生してもSCGリンクの品質は良好であり、堅牢なバックホールのために使用され続ける可能性がある。したがって、UL送信の停止に関する現在の原則は、MCGリンクに障害が発生した場合にSCGリンクを使用すべきかどうかに応じて、再検討される必要がある可能性がある。例えば、DCCA WIで議論されている高速MCGリンク回復メカニズムである。
所見3:NR-DCで設定されSCGにのみBHがあるIABノードの場合、SCG RLFはRLF通知をトリガする(所見2と同様)。
提案7:RAN2は、バックホールリンクがSCGのみで構成されている場合(つまり、EN-DC及びSCGのみバックホールを備えたNR-DC)、SCG RLFがRLF通知をトリガすることに合意すべきである。
提案8:RAN2は、MCG RLFが常にRLF通知をトリガすることに合意すべきである。
所見4:MCG RLFのときにSCGリンクが使用されている場合、UL送信の停止に関する現在の原則を再検討する必要がある可能性がある。DCCA WIにおけるMCGリンクの高速復旧について議論することが期待される。
(ケース2(子がDCで設定される))
ケース2では、子IABノードの観点からのデュアルコネクティビティにより、2つの親IABノードがバックホールリンクのために利用できる。したがって、論点は、どの親IABノードがそのBH RLFでRLF通知を送信するかである。1つのアプローチは、BH RLFがMCG(つまり、MN)又はSCG(つまり、SN)に関連付けられたバックホールリンクで発生するかどうかに関係なく、MCGが常にRLF通知を送信することである。MCGは子IABノードとのCプレーン接続を有するため、これは理にかなっているであろう。但し、これは、SCG(SN)がそのBH RLFをMCG(MN)に通知しなければならないことを意味する。BH RLF下において、ノード間接続が必ずしも利用できるとは限らない(図17参照)。
したがって、MCGでのRLF通知及びSCGでのRLF通知は分離されている方が簡単である。つまり、MCGはそのBH RLFでのみRLF通知を送信し、SCGはそのBH RLFでのみRLF通知を送信する。デュアルコネクティビティ下で各CGに2つの個別のMACが設定されているため、RLF通知にMAC CEが使用されている場合、これは容易である。
提案9:RAN2は、RLF通知がMAC CEを介してMCG又はSCGのいずれかによって送信される可能性があることに合意すべきである。
一方、子IABノードは、SCGからRLF通知を受信すると、提案3が受け入れられる場合、SCGへのUL送信を停止する。これは実際には一種のSCG障害と見なされる可能性があり、子IABノードはMCGがトポロジの適合(例えば、セカンダリノードの変更)を行うことを期待する場合がある。ただし、IABトポロジによっては、SCGのBHリンクに障害が発生した場合、MCGはSCGのBHリンクが(少なくとも一時的に)切断されていることを認識しない可能性があり、適切なアクションをとることはできない可能性がある。したがって、子ノードが、例えば、障害情報又はSCG障害情報を介して、SCGからRLF通知を受信した場合に、MCGに通知できるかどうかを検討すべきである。
提案10:RAN2は、SCGからRLF通知を受信した場合に、MT/UEがMCGに通知することを許可されるかどうかについて議論すべきである。
本願は、米国仮出願第62/884268号(2019年8月8日出願)の優先権を主張し、その内容の全てが本願明細書に組み込まれている。