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

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

▶ 京セラ株式会社の特許一覧

特開2024-60005通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム
<>
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図1
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図2
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図3
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図4
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図5
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図6
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図7
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図8
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図9
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図10
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図11
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図12
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図13
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図14
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図15
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図16
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図17
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図18
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図19
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図20
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図21
  • 特開-通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム 図22
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024060005
(43)【公開日】2024-05-01
(54)【発明の名称】通信制御方法、移動IABノード、プログラム、チップセット及びセルラ通信システム
(51)【国際特許分類】
   H04W 16/26 20090101AFI20240423BHJP
   H04W 36/08 20090101ALI20240423BHJP
   H04W 84/00 20090101ALI20240423BHJP
【FI】
H04W16/26
H04W36/08
H04W84/00 110
【審査請求】有
【請求項の数】5
【出願形態】OL
(21)【出願番号】P 2024034918
(22)【出願日】2024-03-07
(62)【分割の表示】P 2023533138の分割
【原出願日】2022-07-05
(31)【優先権主張番号】P 2021114499
(32)【優先日】2021-07-09
(33)【優先権主張国・地域又は機関】JP
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.3GPP
(71)【出願人】
【識別番号】000006633
【氏名又は名称】京セラ株式会社
(74)【代理人】
【識別番号】110001106
【氏名又は名称】弁理士法人キュリーズ
(72)【発明者】
【氏名】藤代 真人
(57)【要約】      (修正有)
【課題】セルラ通信システムで用いる通信制御方法を提供する。
【解決手段】移動通信システムにおいて、中継ノード(IABノード)を配下に有する第1通信ノード(ソースドナーノード)は、第2通信ノード(ターゲットドナーノード)に対して、中継ノードにおいて使用可能なセルIDを問い合わせる。第2通信ノードは、問い合わせに応じて、中継ノードにおいて使用可能なセルIDのうち、第2通信ノードで使用可能なセルIDと衝突しないセルIDを決定し、決定したセルIDを第1通信ノードへ送信する。第1通信ノードは、決定したセルIDを中継ノードへ送信する。中継ノードは、決定したセルIDを用いて移動処理を実行する。
【選択図】図11
【特許請求の範囲】
【請求項1】
セルラ通信システムで用いる通信制御方法であって、
移動可能な移動IABノードが、前記移動IABノードにおいて使用可能な第1セルIDがOAMにより設定されることと、
ドナーノードが、第2セルIDを含むF1メッセージを、前記移動IABノードへ送信することと、を有し、
前記第2セルIDは、前記ドナーノードで使用可能なセルIDのうち前記第1セルIDと衝突しないセルIDである
通信制御方法。
【請求項2】
セルラ通信システムにおいて移動可能な移動IABノードであって、
前記移動IABノードにおいて使用可能な第1セルIDがOAMにより設定される制御部と、
第2セルIDを含むF1メッセージをドナーノードから受信する受信部と、を有し、
前記第2セルIDは、前記ドナーノードで使用可能なセルIDのうち前記第1セルIDと衝突しないセルIDである
移動IABノード。
【請求項3】
セルラ通信システムにおいて移動可能な移動IABノードに、
前記移動IABノードにおいて使用可能な第1セルIDがOAMにより設定される処理と、
第2セルIDを含むF1メッセージをドナーノードから受信する処理と、
を実行させ、
前記第2セルIDは、前記ドナーノードで使用可能なセルIDのうち前記第1セルIDと衝突しないセルIDである
プログラム。
【請求項4】
セルラ通信システムにおいて移動可能な移動IABノードのチップセットであって、
前記移動IABノードにおいて使用可能な第1セルIDがOAMにより設定されることと、
第2セルIDを含むF1メッセージをドナーノードから受信することと、
を実行し、
前記第2セルIDは、前記ドナーノードで使用可能なセルIDのうち前記第1セルIDと衝突しないセルIDである
チップセット。
【請求項5】
請求項2に記載の移動IABノードを有するセルラ通信システム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、セルラ通信システムに用いる通信制御方法に関する。
【背景技術】
【0002】
セルラ通信システムの標準化プロジェクトである3GPP(Third Generation Partnership Project)(登録商標。以下同じ)において、IAB(Integrated Access and Backhaul)ノードと呼ばれる新たな中継ノードの導入が検討されている(例えば、「3GPP TS 38.300 V16.5.0(2021-03)」参照)。1又は複数の中継ノードが、基地局とユーザ装置との間の通信に介在し、この通信に対する中継を行う。
【発明の概要】
【0003】
第1の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードを配下に有する第1通信ノードが、第2通信ノードに対して、前記中継ノードにおいて使用可能なセルID(Identity)を問い合わせることを含む。また、前記通信制御方法は、第2通信ノードが、問い合わせに応じて、中継ノードにおいて使用可能なセルIDのうち、第2通信ノードで使用可能なセルIDと衝突しないセルIDを決定し、決定したセルIDを第1通信ノードへ送信することを含む。更に、前記通信制御方法は、第1通信ノードが、決定したセルIDを中継ノードへ送信することを含む。更に、前記通信制御方法は、中継ノードが、決定したセルIDを用いて移動処理を実行することを含む。
【0004】
第2の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードが、現在使用するセルが使用できなくなることを検知することを含む。また、前記通信制御方法は、中継ノードが、使用できなくなるセルのセルIDを、中継ノードの子ノード及び/又はユーザ装置へ送信することを含む。
【0005】
第3の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、ソースドナーノードが、時間をトリガ条件に含む条件付きハンドオーバ(Time-triggered CHO(Conditional Handover))をターゲットドナーノードへ要求する要求メッセージを送信することを含む。前記通信制御方法は、ターゲットドナーノードが、要求メッセージを受信したことに応じて、要求を受け入れる受け入れメッセージをソースドナーノードへ送信することを含む。前記通信制御方法は、ソースドナーノードは、受け入れメッセージを受信したことに応じて、時間余裕で条件付きハンドオーバを実行するよう中継ノードを設定することを含む。
【0006】
第4の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードが、現在使用するセルIDを示す第1セルIDと、変更後のセルIDを示す第2セルIDとを報知することを含む。また、前記通信制御方法は、中継ノードが、第1セルIDのセルにアクセスする中継ノードの子ノード及び/又は第1セルIDのセルにアクセスするユーザ装置を、第2セルIDのセルへハンドオーバさせることを含む。更に、前記通信制御方法は、中継ノードが、子ノード及び/又はユーザ装置をハンドオーバさせた後、第1セルIDの報知を停止することを含む。
【0007】
第5の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、第1通信ノードが、第1通信ノードに隣接する隣接ノードから受信した隣接セルのPRACH(Physical Random Access Channel)設定に基づいて、当該隣接セルのPRACH設定と衝突しないPRACH設定を決定することを有する。また、前記通信制御方法は、第1通信ノードが、決定したPRACH設定を中継ノードへ送信することを含む。
【図面の簡単な説明】
【0008】
図1図1は、一実施形態に係るセルラ通信システムの構成例を表す図である。
図2図2は、一実施形態に係るIABノードと親ノード(Parent nodes)と子ノード(Child nodes)との関係を表す図である。
図3図3は、一実施形態に係るgNB(ドナーノード)の構成例を表す図である。
図4図4は、一実施形態に係るIABノード(中継ノード)の構成例を表す図である。
図5図5は、一実施形態に係るUE(ユーザ装置)の構成例を表す図である。
図6図6は、一実施形態に係るIAB-MTのRRC(Radio Resource Control)接続及びNAS(Non-Access Stratum)接続に関するプロトコルスタックの例を表す図である。
図7図7は、一実施形態に係るF1-Uプロトコルに関するプロトコルスタックの例を表す図である。
図8図8は、一実施形態に係るF1-Cプロトコルに関するプロトコルスタックの例を表す図である。
図9図9(A)と図9(B)は、第1実施形態に係るセルID(のリスト)の送信例を表す図である。
図10図10は、第1実施形態に係る具体例を表す図である。
図11図11は、第1実施形態に係る動作例を表す図である。
図12図12は、第1実施形態の第1変形例に係る動作例を表す図である。
図13図13は、第1実施形態の第2変形例に係る動作例を表す図である。
図14図14は、第1実施形態の第3変形例に係る動作例を表す図である。
図15図15(A)と図15(B)は、第1実施形態の第3変形例に係るF1コンテナの例を表す図である。
図16図16は、第2実施形態に係る動作例を表す図である。
図17図17は、第3実施形態に係る動作例を表す図である。
図18図18は、第4実施形態に係る動作例を表す図である。
図19図19は、第5実施形態に係るPRACH(Physical Random Access Channel)リソースの衝突例を表す図である。
図20図20は、第5実施形態に係る動作例を表す図である。
図21図21は、第5実施形態の第1変形例に係る動作例を表す図である。
図22図22は、第5実施形態の変形例2に係る動作例を表す図である。
【発明を実施するための形態】
【0009】
図面を参照しながら、実施形態に係るセルラ通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
【0010】
(セルラ通信システムの構成)
まず、一実施形態に係るセルラ通信システムの構成例について説明する。一実施形態に係るセルラ通信システムは3GPPの5Gシステムである。具体的には、セルラ通信システムにおける無線アクセス方式は、5Gの無線アクセス方式であるNR(New Radio)である。但し、セルラ通信システムには、LTE(Long Term Evolution)が少なくとも部分的に適用されてもよい。また、セルラ通信システムは、6Gなど、将来のセルラ通信システムも適用されてよい。
【0011】
図1は、一実施形態に係るセルラ通信システム1の構成例を表す図である。
【0012】
図1に示すように、セルラ通信システム1は、5Gコアネットワーク(5GC)10と、ユーザ装置(UE:User Equipment)100、基地局装置(以下、「基地局」と称する場合がある。)200-1,200-2、及びIABノード300-1,300-2を有する。基地局200は、gNB(next generation Node B)と呼ばれる場合がある。
【0013】
以下において、基地局200がNR基地局である一例について主として説明するが、基地局200がLTE基地局(すなわち、eNB(evolved Node B))であってもよい。
【0014】
なお、以下において、基地局200-1,200-2をgNB200(又は基地局200)、IABノード300-1,300-2をIABノード300とそれぞれ称する場合がある。
【0015】
5GC10は、AMF(Access and Mobility Management Function)11及びUPF(User Plane Function)12を有する。AMF11は、UE100に対する各種モビリティ制御等を行う装置である。AMF11は、NAS(Non-Access Stratum)シグナリングを用いてUE100と通信することにより、UE100が在圏するエリアの情報を管理する。UPF12は、ユーザデータの転送制御等を行う装置である。
【0016】
各gNB200は、固定の無線通信ノードであって、1又は複数のセルを管理する。セルは、無線通信エリアの最小単位を示す用語として用いられる。セルは、UE100との無線通信を行う機能又はリソースを示す用語として用いられることがある。また、セルは、gNB200など、基地局と区別しないで用いられる場合がある。1つのセルは1つのキャリア周波数に属する。
【0017】
各gNB200は、NGインターフェイスと呼ばれるインターフェイスを介して5GC10と相互に接続される。図1において、5GC10に接続された2つのgNB200-1及びgNB200-2を例示している。
【0018】
各gNB200は、集約ユニット(CU:Central Unit)と分散ユニット(DU:Distributed Unit)とに分割されてもよい。CU及びDUは、F1インターフェイスと呼ばれるインターフェイスを介して相互に接続される。F1プロトコルは、CUとDUとの間の通信プロトコルであって、制御プレーンのプロトコルであるF1-CプロトコルとユーザプレーンのプロトコルであるF1-Uプロトコルとがある。
【0019】
セルラ通信システム1は、バックホールにNR(New Radio)を用いてNRアクセスの無線中継を可能とするIABをサポートする。ドナーgNB(又はドナーノード。以下、「ドナーノード」と称する場合がある。)200-1は、ネットワーク側のNRバックホールの終端ノードであり、IABをサポートする追加機能を備えたドナー基地局である。バックホールは、複数のホップ(すなわち、複数のIABノード300)を介するマルチホップが可能である。
【0020】
図1において、IABノード300-1がドナーノード200-1と無線で接続し、IABノード300-2がIABノード300-1と無線で接続し、F1プロトコルが2つのバックホールリンクで伝送される一例を示している。
【0021】
UE100は、セルとの無線通信を行う移動可能な無線通信装置である。UE100は、gNB200又はIABノード300との無線通信を行う装置であればどのような装置であってもよい。例えば、UE100は、携帯電話端末又はタブレット端末、ノートPC、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置、無人航空機若しくは無人航空機に設けられる装置である。UE100は、アクセスリンクを介してIABノード300又はgNB200に無線で接続する。図1は、UE100がIABノード300-2と無線で接続される一例を示している。UE100は、IABノード300-2及びIABノード300-1を介してドナーノード200-1と間接的に通信する。図1では、IABノード300-2及びIABノード300-1が、中継ノードの役割を果たしている例を表している。
【0022】
図2は、IABノード300と、親ノード(Parent nodes)及び子ノード(Child nodes)との関係を表す図である。
【0023】
図2に示すように、各IABノード300は、基地局機能部に相当するIAB-DUとユーザ装置機能部に相当するIAB-MT(Mobile Termination)とを有する。
【0024】
IAB-MTのNR Uu無線インターフェイス上の隣接ノード(すなわち、上位ノード)は、親ノードと呼ばれる。親ノードは、親IABノード又はドナーノード200のDUである。IAB-MTと親ノードとの間の無線リンクは、バックホールリンク(BHリンク)と呼ばれる。図2において、IABノード300の親ノードがIABノード300-P1及び300-P2である一例を示している。なお、親ノードへ向かう方向は、アップストリーム(upstream)と呼ばれる。UE100から見て、UE100の上位ノードは親ノードに該当し得る。
【0025】
IAB-DUのNRアクセスインターフェイス上の隣接ノード(すなわち、下位ノード)は、子ノードと呼ばれる。IAB-DUは、gNB200と同様に、セルを管理する。IAB-DUは、UE100及び下位のIABノードへのNR Uu無線インターフェイスを終端する。IAB-DUは、ドナーノード200-1のCUへのF1プロトコルをサポートする。図2において、IABノード300の子ノードがIABノード300-C1~300-C3である一例を示しているが、IABノード300の子ノードにUE100が含まれてもよい。なお、子ノードへ向かう方向は、ダウンストリーム(downstream)と呼ばれる。
【0026】
また、1つ又は複数のホップを介して、ドナーノード200に接続されている全てのIABノード300は、ドナーノード200をルートとする有向非巡回グラフ(DAG:Directed Acyclic Graph)トポロジ(以下、「トポロジ」と称する場合がある。)を形成する。このトポロジにおいて、図2に示すように、IAB-DUのインターフェイス上の隣り合うノードが子ノード、IAB-MTのインターフェイス上の隣り合うノードが親ノードとなる。ドナーノード200は、例えば、IABトポロジのリソース、トポロジ、ルート管理などを集中的に行う。ドナーノード200は、バックホールリンクとアクセスリンクのネットワークを介して、UE100に対して、ネットワークアクセスを提供するgNBである。
【0027】
(基地局の構成)
次に、実施形態に係る基地局であるgNB200の構成について説明する。図3は、gNB200の構成例を表す図である。図3に示すように、gNB200は、無線通信部210と、ネットワーク通信部220と、制御部230とを有する。
【0028】
無線通信部210は、UE100との無線通信及びIABノード300との無線通信を行う。無線通信部210は、受信部211及び送信部212を有する。受信部211は、制御部230の制御下で各種の受信を行う。受信部211はアンテナを含み、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換(ダウンコンバート)して制御部230に出力する。送信部212は、制御部230の制御下で各種の送信を行う。送信部212はアンテナを含み、制御部230が出力するベースバンド信号(送信信号)を無線信号に変換(アップコンバート)してアンテナから送信する。
【0029】
ネットワーク通信部220は、5GC10との有線通信(又は無線通信)及び隣接する他のgNB200との有線通信(又は無線通信)を行う。ネットワーク通信部220は、受信部221及び送信部222を有する。受信部221は、制御部230の制御下で各種の受信を行う。受信部221は、外部から信号を受信して受信信号を制御部230に出力する。送信部222は、制御部230の制御下で各種の送信を行う。送信部222は、制御部230が出力する送信信号を外部に送信する。
【0030】
制御部230は、gNB200における各種の制御を行う。制御部230は、少なくとも1つのメモリと、メモリと電気的に接続された少なくとも1つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサとCPU(Central Processing Unit)とを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部230は、以下に示す各実施形態において、gNB200(又はドナーノード200)おける各種処理を行ってもよい。
【0031】
(中継ノードの構成)
次に、実施形態に係る中継ノード(又は中継ノード装置。以下、「中継ノード」と称する場合がある。)であるIABノード300の構成について説明する。図4は、IABノード300の構成例を表す図である。図4に示すように、IABノード300は、無線通信部310と、制御部320とを有する。IABノード300は、無線通信部310を複数有していてもよい。
【0032】
無線通信部310は、gNB200との無線通信(BHリンク)及びUE100との無線通信(アクセスリンク)を行う。BHリンク通信用の無線通信部310とアクセスリンク通信用の無線通信部310とが別々に設けられていてもよい。
【0033】
無線通信部310は、受信部311及び送信部312を有する。受信部311は、制御部320の制御下で各種の受信を行う。受信部311はアンテナを含み、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換(ダウンコンバート)して制御部320に出力する。送信部312は、制御部320の制御下で各種の送信を行う。送信部312はアンテナを含み、制御部320が出力するベースバンド信号(送信信号)を無線信号に変換(アップコンバート)してアンテナから送信する。
【0034】
制御部320は、IABノード300における各種の制御を行う。制御部320は、少なくとも1つのメモリと、メモリと電気的に接続された少なくとも1つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びCPUを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部320は、以下に示す各実施形態において、IABノード300における各種処理を行ってもよい。
【0035】
(ユーザ装置の構成)
次に、実施形態に係るユーザ装置であるUE100の構成について説明する。図5は、UE100の構成例を表す図である。図5に示すように、UE100は、無線通信部110と、制御部120とを有する。
【0036】
無線通信部110は、アクセスリンクにおける無線通信、すなわち、gNB200との無線通信及びIABノード300との無線通信を行う。また、無線通信部110は、サイドリンクにおける無線通信、すなわち、他のUE100との無線通信を行ってもよい。無線通信部110は、受信部111及び送信部112を有する。受信部111は、制御部120の制御下で各種の受信を行う。受信部111はアンテナを含み、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換(ダウンコンバート)して制御部120に出力する。送信部112は、制御部120の制御下で各種の送信を行う。送信部112はアンテナを含み、制御部120が出力するベースバンド信号(送信信号)を無線信号に変換(アップコンバート)してアンテナから送信する。
【0037】
制御部120は、UE100における各種の制御を行う。制御部120は、少なくとも1つのメモリと、メモリと電気的に接続された少なくとも1つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びCPUを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部120は、以下に示す各実施形態において、UE100における各処理を行ってもよい。
【0038】
(プロトコルスタックの構成)
次に、実施形態に係るプロトコルスタックの構成について説明する。図6は、IAB-MTのRRC接続及びNAS接続に関するプロトコルスタックの例を表す図である。
【0039】
図6に示すように、IABノード300-2のIAB-MTは、物理(PHY)レイヤと、MAC(Medium Access Control)レイヤと、RLC(Radio Link Control)レイヤと、PDCP(Packet Data Convergence Protocol)レイヤと、RRC(Radio Resource Control)レイヤと、NAS(Non-Access Stratum)レイヤとを有する。
【0040】
PHYレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。IABノード300-2のIAB-MTのPHYレイヤとIABノード300-1のIAB-DUのPHYレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。
【0041】
MACレイヤは、データの優先制御、ハイブリッドARQ(HARQ:Hybrid Automatic Repeat reQuest)による再送処理、及びランダムアクセスプロシージャ等を行う。IABノード300-2のIAB-MTのMACレイヤとIABノード300-1のIAB-DUのMACレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。IAB-DUのMACレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット(トランスポートブロックサイズ、変調・符号化方式(MCS:Modulation and Coding Scheme))及び割当リソースブロックを決定する。
【0042】
RLCレイヤは、MACレイヤ及びPHYレイヤの機能を利用してデータを受信側のRLCレイヤに伝送する。IABノード300-2のIAB-MTのRLCレイヤとIABノード300-1のIAB-DUのRLCレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
【0043】
PDCPレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。IABノード300-2のIAB-MTのPDCPレイヤとドナーノード200のCUのPDCPレイヤとの間では、無線ベアラを介してデータ及び制御情報が伝送される。
【0044】
RRCレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。IABノード300-2のIAB-MTのRRCレイヤとドナーノード200のCUのRRCレイヤとの間では、各種設定のためのRRCシグナリングが伝送される。ドナーノード200とのRRC接続がある場合、IAB-MTはRRCコネクティッド状態である。ドナーノード200とのRRC接続がない場合、IAB-MTはRRCアイドル状態である。
【0045】
RRCレイヤの上位に位置するNASレイヤは、セッション管理及びモビリティ管理等を行う。IABノード300-2のIAB-MTのNASレイヤとAMF11のNASレイヤとの間では、NASシグナリングが伝送される。
【0046】
図7は、F1-Uプロトコルに関するプロトコルスタックを表す図である。図8は、F1-Cプロトコルに関するプロトコルスタックを表す図である。ここでは、ドナーノード200がCU及びDUに分割されている一例を示す。
【0047】
図7に示すように、IABノード300-2のIAB-MT、IABノード300-1のIAB-DU、IABノード300-1のIAB-MT、及びドナーノード200のDUの各々は、RLCレイヤの上位レイヤとしてBAP(Backhaul Adaptation Protocol)レイヤを有する。BAPレイヤは、ルーティング処理及びベアラマッピング・デマッピング処理を行うレイヤである。バックホールでは、IPレイヤがBAPレイヤを介して伝送されることにより、複数のホップでのルーティングが可能になる。
【0048】
各バックホールリンクにおいて、BAPレイヤのPDU(Protocol Data Unit)は、バックホールRLCチャネル(BH NR RLCチャネル)によって伝送される。各BHリンクで複数のバックホールRLCチャネルを構成することにより、トラフィックの優先順位付け及びQoS(Quality of Service)制御が可能である。BAP PDUとバックホールRLCチャネルとの対応付けは、各IABノード300のBAPレイヤ及びドナーノード200のBAPレイヤによって実行される。
【0049】
なお、ドナーノード200のCUは、IABノード300とドナーノード200のDUへのF1インターフェイスを終端する、ドナーノード200のgNB-CU機能である。また、ドナーノード200のDUは、IAB BAPサブレイヤをホストし、IABノード300へワイヤレスバックホールを提供する、ドナーノード200のgNB-DU機能である。
【0050】
図8に示すように、F1-Cプロトコルのプロトコルスタックは、図7に示すGTP-Uレイヤ及びUDPレイヤに代えて、F1APレイヤ及びSCTPレイヤを有する。
【0051】
なお、以下においては、IABのIAB-DUとIAB-MTで行われる処理又は動作について、単に「IAB」の処理又は動作として説明する場合がある。例えば、IABノード300-1のIAB-DUが、IABノード300-2のIAB-MTへBAPレイヤのメッセージを送信することを、IABノード300-1がIABノード300-2へ、当該メッセージを送信するものとして説明する。また、ドナーノード200のDU又はCUの処理又は動作についても、単に「ドナーノード」の処理又は動作として説明する場合がある。
【0052】
また、アップストリーム方向とアップリンク(UL)方向とを区別しないで用いる場合がある。更に、ダウンストリーム方向とダウンリンク(DL)方向とを区別しないで用いる場合がある。
【0053】
[第1実施形態]
次に第1実施形態について説明する。
【0054】
(PCI Collisionについて)
セルを識別するID(Identity)として、NCGI(NR Cell Global ID)がある。NCGIは、NRセルをグローバルに識別するために用いられる。NCGIは、セルが属するPLMN(Public Land Mobile Network) IDと、セルのNCI(NR Cell Identity)とから構成される。NCGIは、事業者識別番号であるPLMN IDを含み、かつ、NCIも含むため、NCGIを用いることで、全世界で一意に、セルを識別することが可能である。そのため、NCGIの衝突(Collision)は発生しない。
【0055】
NCIについても、gNB IDとセルIDとにより構成され、PLMN内でgNBセルを一意に識別することが可能である。そのため、NCIの衝突も基本的には発生しない。
【0056】
他方、PCI(Physical Cell ID)は、5Gでは、1008個、用意されているが、PLMN内で一意に識別することが可能な態様とはなっていない。
【0057】
現在、3GPPでは、IABノード300が移動するMobile IABについて検討されている。IABノード300の移動は、当該IABノード300を管理するドナーノード200内において行われる場合もあれば、ドナーノード200とは異なるドナーノードへ移動する場合もある。
【0058】
このようなIABノード300の移動によって、同一のPCIを有する異なるIABノードと近接する場合がある。このような近接により、異なるIABノード配下の各々のセルが同一のPCIを用いて処理する場合がある。
【0059】
従って、IABノード300の移動により、PCI Collisionが発生する場合がある。PCI Collisionにより、以下のような不具合が発生する場合がある。
【0060】
すなわち、UE100は、セルサーチにおいて最適ではないセルを選択する場合がある。UE100は、セルサーチの際に、PSS(Primary Synchronization Signal)とSSS(Secondary Synchronization Signal)とを用いてPCIを計算する。PCI Collisionにより、UE100は、実際は異なるセルを同一セルのPCIとして計算する。そのため、UE100は、最適ではないセルを選択する場合がある。また、UE100は、PSSとSSSの受信自体に時間がかかる場合もある。
【0061】
更に、UE100は、PCI Collisionにより、ハンドオーバに失敗する場合がある。すなわち、ソース基地局200は、Measurement Reportに含まれるPCIに基づいて、ハンドオーバ処理を行うと、正しいターゲットセルではない別のセルへUE100をハンドオーバさせてしまう場合がある。
【0062】
第1実施形態では、IABノード300の移動によるPCI Collisionの発生を抑制することを目的としている。
【0063】
(セルIDとPCIについて)
PCIとセルIDとは異なる概念である。PCIは、上述したように、5Gでは、予め用意された1008個のいずれかに該当するIDである。他方、セルIDは、PLMNのサブセットに関連づけられ、SIB1(System Information Block type 1)により報知されるIDである。
【0064】
ただし、以下では、特に断らない限り、PCIとセルIDとを区別しないで用いる場合がある。また、PCIとセルIDとをまとめて、セルIDと称する場合もある。これらの点は、第1実施形態だけではなく、第2実施形態以降も同様である。なお、PCIとセルIDとを区別する場合は、セルIDを、Cell IDと称する場合がある。
【0065】
(セルIDの通知について)
セルIDは、gNB-DUに対しては、OAM(Operations, Administration, and Maintenance)により設定される。
【0066】
他方、gNB-DUは、gNB-CUへ、セルID(のリスト)を送信することが可能である。図9(A)は、第1実施形態に係るセルID(のリスト)の送信例を表す図である。図9(A)は、F1 Setup Requestメッセージを用いて、セルID(のリスト)を送信する例を表している。なお、F1 Setupは、gNB-DUとgNB-CUとにおいて、F1インターフェイス上で正確に相互運用するために、必要なアプリケーションデータを交換する場合に用いられる。F1 Setup Requestメッセージは、そのようなF1 Setupを要求するためのメッセージである。
【0067】
図9(A)に示すように、ステップS1において、gNB-DUは、当該セルのセルID(のリスト)を含むF1 Setup Requestメッセージを、gNB-CUへ送信する。ステップS2において、gNB-CUは、アクティブ化するセルID(のリスト)を含むF1 Setup Responseメッセージを、gNB-DUへ送信する。
【0068】
図9(B)は、第1実施形態に係るセルID(のリスト)の送信例を表す図である。図9(B)では、gNB-DU Configuration Updateメッセージを用いて、セルID(のリスト)を送信する例を表す図である。なお、gNB-DU Configuration Updateは、gNB-DUとgNB-CUとの間において、F1インターフェイス上で正確に相互運用するために、必要なアプリケーションデータを更新する場合に用いられる。gNB-DU Configuration Updateメッセージは、そのような更新を行うために用いられるメッセージである。
【0069】
図9(B)に示すように、ステップS3において、gNB-DUは、追加、変更、及び/又は削除するセルのセルID(のリスト)を含むgNB-DU Configuration Updateメッセージを、gNB-CUへ送信する。ステップS4において、gNB-CUは、アクティブ化、及び非アクティブ化するセルのセルID(のリスト)を含むgNB-DUConfiguration Update Acknowledgeメッセージを、gNB-DUへ送信する。
【0070】
このように、セルIDの決定権は、OAM又はgNB-DUにある。gNB-CUは、主に、gNB-DUからの要求に対して、アクティブ化するか否かを制御している。
【0071】
(第1実施形態の動作例)
第1実施形態は、セルラ通信システム1で用いる通信制御方法を含む。通信制御方法は、中継ノード(例えば、IABノード300)を配下に有する第1通信ノード(例えば、ソースドナーノード200-1)が、第2通信ノード(例えば、ターゲットドナーノード200-2)に対して、中継ノードにおいて使用可能なセルID(Identity)を問い合わせる。次に、第2通信ノードが、問い合わせに応じて、中継ノードにおいて使用可能なセルIDのうち、第2通信ノードで使用可能なセルIDと衝突しないセルIDを決定し、決定したセルIDを第1通信ノードへ送信する。次に、第1通信ノードが、決定したセルIDを中継ノードへ送信する。そして、中継ノードが、決定したセルIDを用いて移動処理を実行する。
【0072】
具体的には、以下のようになる。すなわち、最初に、ソースドナーノード200-1は、IABノード300において使用可能なセルIDを含むHandover Requestメッセージをターゲットドナーノード200-2へ送信する。次に、ターゲットドナーノード200-2が、IABノード300において使用可能なセルIDのうち、ターゲットドナーノード200-2において使用可能なセルIDと衝突しないセルIDを決定する。次に、ターゲットドナーノード200-2は、当該セルIDを含むHandover Request Acknowledgeメッセージをソースドナーノード200-1へ送信する。ソースドナーノード200-1は、当該セルIDを含むRRC Reconfiguration(HO Command)メッセージをIABノード300へ送信する。そして、IABノード300は、当該セルIDを用いて、ターゲットドナーノード200-2への移動処理(具体的には接続処理)を実行する。
【0073】
図10は、第1実施形態に係る具体例を表す図である。図10は、IABノード300が、ソースドナーノード200-1からターゲットドナーノード200-2へ移動する例を表している。
【0074】
図10に示すように、ソースドナーノード200-1は、IABノード300において使用可能なセルID(PCI#2とPCI#3)を、ターゲットドナーノード200-2へ送信する。ターゲットドナーノード200-2は、IABノード300が使用可能なセルIDのうち、自ノード200-2で使用可能なセルID(PCI#2)と衝突しないセルID(PCI#3)を決定する。ターゲットドナーノード200-2は、ソースドナーノード200-1を介して、IABノード300へ、決定したセルID(PCI#3)を通知する。
【0075】
このように、第1実施形態では、IABノード300は、IABノード300において使用可能なセルIDのうち、ターゲットドナーノード200-2において使用可能なセルIDと衝突しないセルIDを、ターゲットドナーノード200-2から受信する。そのため、当該セルIDを用いて移動処理を行うことで、PCI Collisionを抑制することができる。
【0076】
図11は、第1実施形態に係る動作例を表す図である。
【0077】
ただし、図11に示す動作が行われる前に、OAMによって、自局が使用可能なセルIDがIABノード300に設定されているものとする。
【0078】
セルIDは、セルIDのリストであってもよい。当該リストには、複数のセルIDが含まれる。当該リストには、アクティブなセルのセルIDと非アクティブなセルのセルIDとが含まれてもよい。もしくは、当該リストには、アクティブなセルのセルIDと非アクティブなセルのセルIDのいずれか一方のセルIDが含まれてもよい。
【0079】
また、セルIDは、使用可能なセルIDの範囲によって示されてもよい。例えば、使用可能なセルIDの範囲として、「PCI#1からPCI#3」などがある。
【0080】
このように、セルIDには、セルIDのリスト及び/又はセルIDの範囲が含まれてもよい。
【0081】
また、図11に示す動作が行われる前に、IABノード300は、自局が使用可能なセルIDをソースドナーノード200-1へ通知しているものとする。IABノード300のIAB-DUは、自局が使用可能なセルIDを含むF1 Setup Requestメッセージをソースドナーノード200-1のCUへ送信してもよい。また、IABノード300のIAB-DUは、自局が使用可能なセルIDを含むgNB-DU Configuration Updateメッセージをソースドナーノード200-1のCUへ送信してもよい。
【0082】
なお、図11に示す例は、Xnハンドオーバを想定している。
【0083】
図11に示すように、ステップS10において、ソースドナーノード200-1は、配下のIABノード300を、migration(又はハンドオーバ。以下では、「ハンドオーバ」と称する場合がある。)させることを決定する。ハンドオーバは、ソースドナーノード200-1からターゲットドナーノード200-2へのハンドオーバである。
【0084】
ステップS11において、ソースドナーノード200-1は、IABノード300が使用可能なセルIDを含むHandover Requestメッセージを、ターゲットドナーノード200-2へ送信する。当該使用可能なセルIDは、セルIDのリストでもよい。当該使用可能なセルIDには、それぞれのセルIDがアクティブ化されているか非アクティブ化されているかの情報が含まれていてもよい。もしくは、当該使用可能なセルIDは、使用禁止のセルIDとして通知されてもよい。この送信が、IABノード300で使用可能なセルIDをターゲットドナーノード200-2へ問い合わせることに対応する。なお、Handover Requestメッセージは、Xnメッセージの一例である。
【0085】
ステップS12において、ターゲットドナーノード200-2は、Handover Requestメッセージを受信したことに応じて、IABノード300が使用可能なセルIDのうち、ターゲットドナーノード200-2で使用可能なセルIDと衝突しないセルIDを決定する。
【0086】
ステップS13において、ターゲットドナーノード200-2は、決定したセルIDを含むHandover Request Acknowledgeメッセージを、ソースドナーノード200-1へ送信する。当該決定したセルIDは、セルIDのリストでもよい。当該決定したセルIDには、それぞれのセルIDをアクティブ化するのか非アクティブ化するのかの情報が含まれていてもよい。もしくは、当該決定したセルIDは、使用禁止のセルIDとして通知されてもよい。Handover Request Acknowledgeメッセージは、Handover Requestメッセージに対する応答メッセージであって、Xnメッセージの一例である。当該決定したセルIDは、ターゲットドナーノード200-2が生成したRRCメッセージ(例えばRRC Reconfiguration)に含まれてもよい。当該決定したセルIDは、当該メッセージはカプセル化されて(すなわち当該Xnメッセージのコンテナに格納されて)、送信されてもよい。
【0087】
ステップS14において、ソースドナーノード200-1は、Handover Request Acknowledgeメッセージを受信したことに応じて、決定したセルIDを含むRRC Reconfiguration(HO Command)メッセージを、IABノード300へ送信する。RRC Reconfiguration(HO Command)メッセージは、RRCメッセージの一例である。
【0088】
ステップS15において、IABノード300は、RRC Reconfiguration(HO Command)メッセージを受信したことに応じて、決定したセルIDをアクティブ化する。IABノード300は、セルIDのアクティブ化と連動して、ターゲットドナーノード200-2に対してアクセスを開始する。なお、ステップS15において、IABノード300は、アクティブ化したセルID以外のセルIDを非アクティブ化してもよい。
【0089】
図11に示す例は、IABノード300がハンドオーバにより、ドナーノード200-1,200-2間で移動する場合について説明した。例えば、IABノード300の親ノード300-P1,300-P2間でIABノード300がハンドオーバする場合でもよい。IABノード300の上位ノード間でIABノード300がハンドオーバする場合でもよい。また、gNB-CU間でIABノード300がハンドオーバする場合でもよい。いずれの場合も、各メッセージが、親ノード300-P1,300-P2間、上位ノード間、gNB-CU間、IABノード300と親ノード間、IABノード300と上位ノード間、IABノード300のDUとgNB-CU間で交換されてもよい。
【0090】
以降、第1実施形態における第1の別の実施形態を説明するが、当該実施形態についても、このようなドナーノード200-1,200-2間のハンドオーバ以外の例が用いられてもよい。
【0091】
(第1実施形態の第1変形例)
次に、第1実施形態の第1変形例について説明する。第1実施形態では、ソースドナーノード200-1がターゲットドナーノード200-2に、IABノード300において使用可能なセルIDの問い合わせる例について説明した。第1実施形態の第1変形例は、ソースドナーノード200-1がAMF11へ問い合わせる例である。
【0092】
具体的には、以下のようになる。すなわち、最初に、ソースドナーノード200-1が、IABノード300において使用可能なセルIDを含む第1メッセージをAMF11へ送信する。次に、AMF11が、IABノード300において使用可能なセルIDのうち、AMF11配下で使用可能なセルIDと衝突しないセルIDを決定する。そして、AMF11は、決定したセルIDを含む第2メッセージをソースドナーノード200-1へ送信する。ソースドナーノード200-1は、決定したセルIDを含むHandover CommandメッセージをIABノード300へ送信し、IABノード300は、決定したセルIDを用いてターゲットドナーノード200-2への移動処理(具体的には接続処理)を実行する。
【0093】
第1変形例も、IABノード300は、自局で使用可能なセルIDのうち、AMF11配下で使用可能なセルIDと衝突しないセルIDをAMF11から受信する。そのため、IABノード300は、AMF11配下のターゲットドナーノード200-2へ移動する場合であっても、PCI Collisionを抑制することができる。
【0094】
図12は、第1実施形態の第1変形例に係る動作例を表す図である。図12に示す動作例における事前設定も、第1実施形態の動作例(図11)と同様である。
【0095】
図12に示すように、ステップS20において、ソースドナーノード200-1は、IABノード300をソースドナーノード200-1からターゲットドナーノード200-2へハンドオーバさせることを決定する。
【0096】
ステップS21において、ソースドナーノード200-1は、IABノード300において使用可能なセルIDを含む第1メッセージを、AMF11へ送信する。当該使用可能なセルIDは、セルIDのリストでもよい。当該使用可能なセルIDには、それぞれのセルIDがアクティブ化されているか非アクティブ化されているかの情報が含まれていてもよい。もしくは、当該使用可能なセルIDは、使用禁止のセルIDとして通知されてもよい。第1メッセージは、NGメッセージの一例であって、新規メッセージである。第1メッセージは、IAB migration inquiryメッセージと称する場合がある。IAB migration inquiryメッセージの送信が、IABノード300で使用可能なセルIDのAMF11への問い合わせに該当する。
【0097】
ステップS22において、AMF11は、IAB migration inquiryメッセージの受信に応じて、IABノード300において使用可能なセルIDのうち、AMF11配下で使用可能なセルIDと衝突しないセルIDを決定する。
【0098】
ステップS23において、AMF11は、決定したセルIDを含む第2メッセージをソースドナーノード200-1へ送信する。第2メッセージも、NGメッセージの一例であって、新規メッセージである。第2メッセージは、IAB migration inquiry Responseメッセージと称する場合がある。
【0099】
ステップS25において、ソースドナーノード200-1は、IAB migration inquiry Responseメッセージの受信に応じて、ターゲットドナーノード200-2との間で、Xnハンドオーバ準備手順を実行する。Xnハンドオーバ準備手順は、Handover Requestメッセージの送受信と、Handover Request Acknowledgeメッセージの送受信を含む。
【0100】
ステップS26において、ソースドナーノード200-1は、AMF11で決定したセルIDを含むRRC Reconfiguration(HO Command)メッセージを、IABノード300へ送信する。
【0101】
ステップS27において、IABノード300は、RRC Reconfiguration(HO Command)メッセージの受信に応じて、決定したセルIDをアクティブ化する。IABノード300は、アクティブ化したセルIDを用いて、ターゲットドナーノード200-2に対してアクセスを開始する。
【0102】
(第1実施形態の第2変形例)
次に、第1実施形態の第2変形例について説明する。第1実施形態と、第1実施形態の第1変形例では、Xnハンドオーバの例について説明した。第1実施形態の第2変形例は、NGハンドオーバを適用した場合の例である。Xnハンドオーバでは、ハンドオーバ手順が、主に、ドナーノード200-1,200-2間で行われた。NGハンドオーバでは、AMF11などの5GC10に含まれる装置もハンドオーバ手順に含まれる。
【0103】
具体的には、第1通信ノードがソースドナーノード200-1であり、第2通信ノードがAMF11の例である。また、中継ノードがIABノード300の例である。最初に、ソースドナーノード200-1は、IABノード300において使用可能なセルIDを含むHandover RequiredメッセージをAMF11へ送信する。次に、AMF11は、IABノード300において使用可能なセルIDのうち、AMF11配下で使用可能なセルIDと衝突しないセルIDを決定する。AMF11は、決定したセルIDを含む第1Handover Commandメッセージをソースドナーノード200-1へ送信する。そして、ソースドナーノード200-1が、決定したセルIDを含む第2Handover CommandメッセージをIABノード300へ送信し、IABノード300が、決定したセルIDを用いてターゲットドナーノード200-2への接続処理を実行する。
【0104】
第2変形例においても、IABノード300は、自局で使用可能なセルIDのうち、AMF11配下で使用可能なセルIDと衝突しないセルIDをAMF11から受信する。そのため、IABノード300は、AMF11配下のターゲットドナーノード200-2へ移動する場合であっても、PCI Collisionを抑制することができる。
【0105】
なお、第2変形例では、AMF11に代えて、5GC10に含まれる他の装置(例えば、UPF12)であってもよい。
【0106】
図13は、第1実施形態の第2変形例に係る動作例を表す図である。図13に示す動作例における事前設定も、第1実施形態の動作例(図11)と同様である。
【0107】
ステップS30において、ソースドナーノード200-1は、IABノード300をソースドナーノード200-1からターゲットドナーノード200-2へハンドオーバさせることを決定する。
【0108】
ステップS31において、ソースドナーノード200-1は、IABノード300において使用可能なセルIDを含むHandover RequiredメッセージをAMF11へ送信する。Handover Requiredメッセージは、NGプロトコルのメッセージである。当該使用可能なセルIDは、セルIDのリストでもよい。当該使用可能なセルIDには、それぞれのセルIDがアクティブ化されているか非アクティブ化されているかの情報が含まれていてもよい。もしくは、当該使用可能なセルIDは、使用禁止のセルIDとして通知されてもよい。
【0109】
ステップS32において、AMF11は、Handover Requiredメッセージの受信に応じて、IABノード300において使用可能なセルIDのうち、AMF11配下で使用可能なセルIDと衝突しないセルIDを決定する。
【0110】
ステップS33において、AMF11は、決定したセルIDを含むHandover Commandメッセージを、ソースドナーノード200-1へ送信する。Handover Commandメッセージも、NGプロトコルのメッセージである。なお、AMF11は、ターゲットドナーノード200-2との間でもハンドオーバに関連するメッセージの交換を行うが、図13では省略されている。
【0111】
ステップS34において、ソースドナーノード200-1は、Handover Commandメッセージの受信に応じて、決定したセルIDを含むRRC Reconfiguration(HO Command)メッセージをIABノード300へ送信する。
【0112】
ステップS35において、IABノード300は、AMF11で決定したセルIDをアクティブ化し、アクティブ化したセルIDを用いて、移動処理を行う。具体的には、IABノード300は、当該セルIDを用いてターゲットドナーノード200-2への接続処理を実行する。
【0113】
(第1実施形態の第3変形例)
次に、第1実施形態の第3変形例を説明する。第1実施形態の第3変形例では、IABノード300のドナーノード200-2に対するF1 Setupを、ドナーノード200-1を介して行う例である。そして、第1実施形態の第3変形例では、このようなF1 Setupがハンドオーバ手順内で行われる例を表している。
【0114】
具体的には、第1通信ノードはソースドナーノード200-1であり、第2通信ノードはターゲットドナーノード200-2の例を表している。また、中継ノードはIABノード300の例を表している。最初に、ソースドナーノード200-1は、IABノード300に対してF1 Setup Requestメッセージの送信を指示する。次に、IABノード300は、F1 Setup Requestメッセージをカプセル化した第3メッセージをソースドナーノード200-1へ送信する。F1 Setup Requestメッセージには、IABノード300で使用可能なセルIDが含まれる。次に、ソースドナーノード200-1は、F1 Setup Requestメッセージをカプセル化したHandover Requestメッセージをターゲットドナーノード200-2へ送信する。次に、ターゲットドナーノード200-2は、Handover RequestメッセージからIABノード300において使用可能なセルIDを取り出し、当該セルIDのうち、ターゲットドナーノード200-2において使用可能なセルIDと衝突しないセルIDを決定する。そして、ターゲットドナーノード200-2は、決定したセルIDを含むF1 Setup Responseメッセージをカプセル化したHandover Request Acknowledgeメッセージをソースドナーノード200-1へ送信する。次に、ソースドナーノード200-1は、決定したセルIDを含むF1 Setup Responseメッセージをカプセル化したHandover CommandメッセージをIABノード300へ送信する。そして、IABノード300は、F1 Setup Responseメッセージに含まれるセルIDを用いて、ターゲットドナーノード200-2へ移動処理を実行する。
【0115】
このように、第3変形例においても、IABノード300は、自局で使用可能なセルIDのうち、ターゲットドナーノード200-2において使用可能なセルIDと衝突しないセルIDを、ターゲットドナーノード200-2から受信する。そのため、IABノード300は、ターゲットドナーノード200-2へハンドオーバする場合であっても、PCI Collisionを抑制することができる。
【0116】
図14は、第1実施形態の第3変形例に係る動作例を表す図である。事前設定などは、第1実施形態と同様である。図14に示す例では、Xnハンドオーバの例を表している。
【0117】
図14に示すように、ソースドナーノード200-1は、配下のIABノード300をソースドナーノード200-1からターゲットドナーノード200-2へハンドオーバさせることを決定する。
【0118】
ステップS41において、ソースドナーノード200-1は、F1 Setup Requestメッセージの送信を、IABノード300へ指示する。具体的には、ソースドナーノード200-1のCUは、F1 Setup Requiredメッセージを、IABノード300のIAB-MTへ送信する。F1 Setup Requiredメッセージは、F1 Setup Requestメッセージの送信を指示することを示す新規のRRCメッセージである。
【0119】
なお、F1 Setup Requiredメッセージは、F1APプロトコルのメッセージであってもよい。この場合、ソースドナーノード200-1のCUは、当該メッセージを、IABノード300のIAB-DUへ送信する。
【0120】
ステップS42において、IABノード300のIAB-MTは、F1 Setup Requiredメッセージの受信に応じて、F1 Setup Responseメッセージを、ソースドナーノード200-1のCUへ送信する。F1 Setup Responseメッセージは、F1 Setup Requiredメッセージに対する応答メッセージであって、新規なRRCメッセージである。この場合、IABノード300のIAB-MTは、当該メッセージに含まれるF1APコンテナに、F1 Setup Requestメッセージをカプセル化して、当該メッセージを送信する。図15(A)は、当該メッセージに含まれるF1APコンテナの例を表している。F1 Setup Requestメッセージには、IABノード300において使用可能なセルIDが含まれる。なお、F1 Setup Responseメッセージは、F1APプロトコルメッセージでもよい。
【0121】
図14に戻り、なお、F1 Setup RequiredメッセージがRRCのメッセージの場合、IABノード300のIAB-MTは、IABノード300のIAB-DUに対して取得指示を通知し、IAB-DUからF1 Setup Requestメッセージを取得するようにしてもよい。
【0122】
ステップS43において、ソースドナーノード200-1は、F1 Setup Responseメッセージの受信に応じて、Handover Requestメッセージをターゲットドナーノード200-2へ送信する。この際、ソースドナーノード200-1は、F1 Setup ResponseメッセージのF1APコンテナから、カプセル化されたF1 Setup Requestメッセージを取り出し、Handover RequestメッセージのF1APコンテナに挿入する。図15(B)は、Handover Requestメッセージ(Xnメッセージ)に含まれるF1APコンテナの例を表している。
【0123】
図14に戻り、ステップS44において、ターゲットドナーノード200-2は、Handover RequestメッセージのF1APコンテナから、F1 Setup Requestメッセージを取り出し、自局に対するF1 Setupを行う。また、ターゲットドナーノード200-2は、F1 Setup RequestメッセージからIABノード300で使用可能なセルIDを取り出し、当該セルIDのうち、ターゲットドナーノード200-2において使用可能なセルIDと衝突しないセルIDを決定する。
【0124】
ステップS45において、ターゲットドナーノード200-2は、Handover Request Acknowledgeメッセージをソースドナーノード200-1へ送信する。この際、ターゲットドナーノード200-2は、Handover Request Acknowledgeメッセージ(Xnメッセージ)に含まれるF1コンテナに、決定したセルIDを含むF1 Setup Responseメッセージをカプセル化して送信する。当該使用可能なセルIDは、セルIDのリストでもよい。当該使用可能なセルIDには、それぞれのセルIDがアクティブ化されているか非アクティブ化されているかの情報が含まれていてもよい。もしくは、当該使用可能なセルIDは、使用禁止のセルIDとして通知されてもよい。
【0125】
ステップS46において、ソースドナーノード200-1は、Handover Request Acknowledgeメッセージの受信に応じて、Handover Request AcknowledgeメッセージのF1コンテナから、F1 Setup Responseメッセージを取り出す。そして、ソースドナーノード200-1は、取り出したF1 Setup Responseメッセージを、RRC Reconfiguration(HO Command)メッセージのF1コンテナに、カプセル化する。ソースドナーノード200-1のCUは、カプセル化したF1 Setup Responseメッセージを含むRRC Reconfiguration(HO Command)メッセージを、IABノード300のIAB-MTへ送信する。
【0126】
ステップS47において、IABノード300は、RRC Reconfiguration(HO Command)メッセージからF1 Setup Responseメッセージを取り出し、更に、F1 Setup Responseメッセージから、ターゲットドナーノード200-2で決定したセルIDを取り出す。そして、IABノード300は、取り出したセルIDをアクティブ化する。IABノード300は、セルIDのアクティブ化と連動して、ターゲットドナーノード200-2に対して移動処理(具体的には、接続処理)を実行する。
【0127】
[第2実施形態]
次に、第2実施形態について説明する。
【0128】
第1実施形態で説明したように、IABノード300のmigrationにより、IABノード300において使用するセルIDが変更される場合がある。当該IABノード300を親ノードに持つ子ノード300-C及び/又はUE100は、親ノード(IABノード300)における変更後のセルIDを知ることはできない。一方、子ノード300-C及び/又はUE100は、変更後のセルIDを使用する場合、当該セルIDに対してセル再選択処理、又はRRC Connection Reestablishment(RRC接続再設定)処理を行う。しかし、IABノード300の全ての子ノード300-C及び/又はUE100が、一斉に、RRC接続再設定処理を開始すると、RACHのプリアンブル衝突が発生したり、リソース全体が逼迫したりする場合がある。このため、UE100に提供中のサービスが瞬断する場合がある。
【0129】
そこで、第2実施形態は、子ノード300-C及び/又はUE100に対して、親ノードのセルID変更に伴う処理を抑制することを目的としている。
【0130】
そのため、第2実施形態では、中継ノード(例えば、IABノード300-P)は、現在使用するセルが使用できなくなることを検知する。そして、中継ノードは、使用できなくなるセルのセルIDを、中継ノードの子ノード(例えば、子ノード300-C)及び/又はユーザ装置(例えば、UE100)へ送信する。
【0131】
これにより、例えば、子ノード300-C及び/又はUE100は、使用できなくなるセルのセルIDを受信しても、少なくとも、セル再選択処理、RRC接続再設定処理、及びRLF(Radio Link Failure)処理を行わないようにすることで、セルID変更に伴う処理を抑制させることができる。
【0132】
図16は、第2実施形態に係る動作例を表す図である。図16は、ドナーノード200の配下にIABノード300-Pが存在する例を表している。また、図16は、IABノード300-Pの子ノードとしてIABノード300-Cが存在する、及び/又は、IABノード300-Pとアクセスリンクで接続されたUE100が存在する例を表している。
【0133】
ステップS50において、IABノード300-Pは、ドナーノード200から、変更後のセルIDを含むRRC Reconfiguration(HO Command)メッセージを受信してもよい。ステップS50は、第1実施形態のステップS14(図11)、第1実施形態の第1変形例のステップS26(図12)、第1実施形態の第2変形例のステップS34(図13)、又は第1実施形態の第3変形例のステップS46(図14)等であってもよい。変更後のセルIDに代えて、使用可能なセルID、使用不可能なセルID、アクティブ化するセルID、又は非アクティブ化するセルIDであってもよい。ドナーノード200に代えて、IABノード300-Pの親ノード又は上位ノードであってもよい。
【0134】
ステップS51において、IABノード300-Pは、現在使用中のセルが使用できなくなることを検知する。IABノード300-Pは、現在使用中のセルが非アクティブ化される(又は使用不可能となる)ことをドナーノード200から通知(例えば、ステップS50)を受けて、現在使用中のセルが使用できなくなることを検知してもよい。又は、IABノード300-Pは、ステップS50により、変更後のセルIDの通知を受けて、現在使用中のセルが使用できなくなることを検知してもよい。なお、IABノード300-Pは、現在使用中のセルが継続して使用できる場合は、当該セルのセルIDを使用し続けることになる。以降の処理は、現在使用中のセルが使用できなくなった場合を想定している。
【0135】
ステップS52において、IABノード300-Pは、継続して使用することができなくなるセルのセルIDを、子ノード300-C及び/又はUE100へ送信する。
【0136】
この場合、IABノード300-Pは、当該セルIDを含むSIB1を報知することで当該送信が行われてもよい。また、IABノード300-Pは、当該セルIDを含むRRCメッセージ又はF1APメッセージなどを送信することで当該送信が行われてもよい。
【0137】
通知する内容も、継続して使用することができなくなるセルのセルIDに代えて、当該セルが使用できなくなることを表す情報、当該セルのセルIDが変更されることを表す情報、又はタイミング情報が含まれてもよい。当該セルのセルIDが変更されることを表す情報には、変更後のセルIDが含まれてもよい。変更後のセルIDそのものが、当該セルのセルIDが変更されることを表す情報そのものであってもよい。また、タイミング情報は、非アクティブになるタイミングを表す情報、又はセルIDが変更になるタイミングを表す情報であってもよい。タイミング自体は、SFN(System Frame Number)及び/又は時間(1秒等)で表されてもよい。
【0138】
ステップS53において、子ノード300-C及び/又はUE100は、当該セルIDを受信したことに応じて、現在使用中のセルのセルIDが変更されても、所定処理を行わないようにする。所定処理は、少なくとも、RLF検知、セル再選択処理、及びRRC接続再設定処理のいずれかひとつ以上を含む。子ノード300-C及び/又はUE100が、所定処理を行わないことで、セルID変更に伴う処理を抑制できる。この場合、子ノード300-C及び/又はUE100は、ソフトハンドオーバーとして、セルIDの変更を認識し、当該セルに対する設定処理などをそのまま継続して使用してもよい。
【0139】
なお、ステップS53において、子ノード300-C及び/又はUE100は、セルID変更後、RRC接続再設定処理を行ってもよい。ただし、セルID変更に伴う処理を抑制するため、子ノード300-C及び/又はUE100は、新セルIDに対して、RACH-lessハンドオーバを行ってもよい。
【0140】
また、ステップS53は、子ノード300-C及び/又はUE100が、IABノード300-Pに対して、RRCコネクティッド状態であることを前提とした動作を説明した。例えば、子ノード300-C及び/又はUE100は、アイドル状態の場合又はインアクティブ状態の場合、新セルIDに対するセル再選択処理を行うことになる。そのため、図16に示す動作例は、子ノード300-C及び/又はUE100が、アイドル状態の場合又はインアクティブ状態であることを前提としてもよい。
【0141】
[第3実施形態]
次に、第3実施形態について説明する。
【0142】
第2実施形態では、IABノード300-Pにおいて現在使用中のセルのセルIDが使用できなくなることを、子ノード300-C及び/又はUE100へ通知する例について説明した。この場合、子ノード300-C及び/又はUE100は、そのような通知を受けて、すぐに、ハンドオーバ処理を行うと、自局においてセルIDの変更を完了する前に、ハンドオーバ処理を開始してしまう場合もある。とくに、第1実施形態で説明したHO Commandを受信したIABノード300は、時間的余裕もなく、セルIDを変更する前に、ハンドオーバ処理を行う場合もある。
【0143】
そこで、第3実施形態では、時間をトリガ条件に含む条件付きハンドオーバを用いて、IABノード300がハンドオーバする例について説明する。このような条件付きハンドオーバを、Time-triggered CHO(Conditional Handover)と称する場合がある。
【0144】
具体的には、ソースドナーノード200-1は、時間をトリガ条件に含む条件付きハンドオーバをターゲットドナーノード200-2へ要求する要求メッセージを送信する。次に、ターゲットドナーノード200-2は、要求メッセージを受信したことに応じて、要求を受け入れる受け入れメッセージをソースドナーノード200-1へ送信する。そして、ソースドナーノード200-1は、受け入れメッセージを受信したことに応じて、時間をトリガ条件に含む条件付きハンドオーバを実行するよう中継ノード(例えば、IABノード300)を設定する。
【0145】
これにより、例えば、IABノード300は、ソースドナーノード200-1から、セルID変更の通知(図16のステップS52)を受けても、当該時間経過後に、ハンドオーバ処理を実行することができる。そのため、IABノード300は、例えば、セルIDを変更した後で、ハンドオーバ処理を実行でき、ハンドオーバ処理を適切に行うことが可能となる。
【0146】
ここで、条件付きハンドオーバについて説明する。
【0147】
(条件付きハンドオーバ)
条件付きハンドオーバは、1つ以上のハンドオーバ実行条件(又はトリガ条件)が満たされたときに実行されるハンドオーバである。条件付きハンドオーバの設定は、ハンドオーバの候補セル及びハンドオーバのトリガ条件を含む。条件付きハンドオーバの設定は、候補セル及びトリガ条件の複数の組み合わせを複数含んでもよい。
【0148】
トリガ条件は、例えば、イベントA3と呼ばれるイベント及びイベントA5と呼ばれるイベントのうち少なくとも一方が指定される。イベントA3は、隣接セルの無線状態がサービングセルの無線状態よりも所定量(所定オフセット)以上に良好であるというイベントである。イベントA5は、サービングセルの無線状態が第1閾値よりも劣化し、且つ、隣接セルの無線状態が第2閾値よりも良好であるというイベントである。
【0149】
第3実施形態では、上述したように、条件付きハンドオーバのトリガ条件に、時間(又は時間余裕。以下では、「時間余裕」と称する場合がある。)を含めるようにしている。
【0150】
(第3実施形態の動作例)
図17は、第3実施形態に係る動作例を表す図である。図17は、IABノード300が、ソースドナーノード200-1からターゲットドナーノード200-2へハンドオーバする場合の例を表している。
【0151】
図17に示すように、ステップS60において、IABノード300は、時間余裕の必要量をソースドナーノード200-1へ通知してもよい。例えば、IABノード300は、RRCメッセージ又はF1APメッセージなどに、時間余裕の必要量を含めて送信してもよい。
【0152】
時間余裕の必要量とは、例えば、IABノード300が、時間をトリガ条件に含む条件付きハンドオーバを実行する際に要求する時間のことである。時間余裕の必要量は、SFN及び/又は時間単位(1秒など)で表されてよい。
【0153】
ステップS61において、ソースドナーノード200-1は、IABノード300をソースドナーノード200-1からターゲットドナーノード200-2へハンドオーバさせることを決定する。
【0154】
ステップS62において、ソースドナーノード200-1は、時間をトリガ条件に含む条件付きハンドオーバを要求する。ソースドナーノード200-1は、Handover Requestメッセージを利用して、当該要求を送信してもよい。Handover Requestメッセージが、当該条件付きハンドオーバをターゲットドナーノード200-2へ要求する要求メッセージであってもよい。ソースドナーノード200-1は、時間余裕の必要量を、当該要求とともに送信してもよい。IABノード300の時間余裕の必要量は、予めソースドナーノード200-1が保持してもよい。IABノード300の時間余裕の必要量は、ステップS60のようにIABノード300から受信してもよい。
【0155】
ステップS63において、ターゲットドナーノード200-2は、当該条件付きハンドオーバの要求を受信したことに応じて、当該条件付きハンドオーバの受け入れを決定する。ターゲットドナーノード200-2は、当該要求に時間余裕の必要量が含まれている場合は、当該必要量に対して、時間余裕の量を決定してもよい。なお、当該要求に時間余裕の必要量が含まれていない場合は、ソースドナーノード200-1において、時間余裕の必要量に対して、時間余裕の量を決定してもよい。
【0156】
なお、時間余裕の量は、例えば、時間余裕の必要量に対して、当該条件付きハンドオーバにおいて実際に用いられる時間のことである。時間余裕の量も、例えば、SFNで表されても良いし、時間単位で表されてもよい。
【0157】
ステップS64において、ターゲットドナーノード200-2は、当該条件付きハンドオーバの受け入れをソースドナーノード200-1へ送信する。ターゲットドナーノード200-2は、当該条件付きハンドオーバの受け入れを、Handover Request Acknowledgeメッセージを利用して送信してもよい。当該Handover Request Acknowledgeメッセージが、当該要求を受け入れる受け入れメッセージであってもよい。なお、ターゲットドナーノード200-2は、時間余裕の量を決定した場合は、決定した時間余裕の量を、当該Handover Request Acknowledgeメッセージに含めて送信する。また、当該Handover Request Acknowledgeメッセージには、RRC Reconfiguration設定が含まれる。
【0158】
ステップS65において、ソースドナーノード200-1は、当該条件付きハンドオーバの受け入れを受信したことに応じて、IABノード300に対して、当該条件付きハンドオーバを設定する。例えば、ソースドナーノード200-1は、RRC ReconfigurationメッセージをIABノード300へ送信することで設定が行われる。RRC Reconfigurationメッセージには、ソースドナーノード200-1又はターゲットドナーノード200-2で決定した時間余裕の量が含まれる。また、RRC Reconfigurationメッセージには、ステップS64で受信したRRC Reconfiguration設定が含まれる。
【0159】
IABノード300では、当該条件付きハンドオーバに用いられるトリガ条件として、時間余裕の量が設定される。ここで、時間余裕の量は、2つの意味がある。
【0160】
第1に、IABノード300は、所定時間から、当該時間余裕の量が経過した後、条件付きハンドオーバのトリガ条件(例えば、イベントA3等)を評価する場合である。この場合、時間余裕の量が、トリガ条件の監視を開始する前の時間余裕を表している。例えば、IABノード300は、所定時間から1秒(時間余裕の量)経過後、条件付きハンドオーバの他のトリガ条件(例えば、イベントA3)の監視を開始し、当該他のトリガ条件を満たすと、ターゲットドナーノード200-2へのアクセスを開始する。
【0161】
第2に、当該時間余裕の量が経過した後に、ハンドオーバが実行される場合である。この場合、時間余裕の量がトリガ条件となっている。例えば、IABノード300は、所定時間から1秒(時間余裕の量)経過後、ターゲットドナーノード200-2へのアクセスを開始する。
【0162】
なお、IABノード300は、当該時間をトリガ条件に含む条件付きハンドオーバが設定された際、当該時間経過中(例えば対応するタイマの動作中)は、他の条件(例えば無線状況の変化)に従った条件付きハンドオーバの評価を停止してもよい。これにより、時間余裕の間に、意図せず別のセルへアクセスする(別の条件付きハンドオーバを実行する)ことを防止することができる。
【0163】
なお、所定時間は、IABノード300が、RRC Reconfigurationメッセージ(ステップS65)を受信した時間でもよい。所定時間は、ドナーノード200-1,200-2から設定された時間でもよい。
【0164】
ステップS66において、IABノード300は、当該条件付きハンドオーバを実行する。
【0165】
[第4実施形態]
次に、第4実施形態について説明する。
【0166】
第4実施形態は、IABノード300が、子ノード300-C及び/又はUE100へ、現在使用しているセルのセルIDと、新たなセルIDとを報知する例である。
【0167】
具体的には、中継ノード(例えば、IABノード300)は、現在使用するセルIDを示す第1セルIDと、変更後のセルIDを示す第2セルIDとを報知する。次に、中継ノードは、第1セルIDのセルにアクセスする中継ノードの子ノード(例えば、子ノード300-C)及び/又はユーザ装置(例えば、UE100)を、第2セルIDのセルへハンドオーバさせる。そして、中継ノードは、子ノード及び/又はユーザ装置をハンドオーバさせた後、第1セルIDの報知を停止する。
【0168】
これにより、子ノード300-C及び/又はUE100は、現在使用しているセルIDと、変更後の新セルIDとを把握して、その後、適切にハンドオーバ処理を行うことが可能となる。
【0169】
図18は、第4実施形態に係る動作例を表す図である。
【0170】
図18に示すように、ステップS70において、IABノード300-Pは、migrationする際に、ドナーノード200から、変更後のセルIDを受信してもよい。変更後のセルIDに代えて、使用可能なセルID、使用不可能なセルID、アクティブ化するセルID、又は非アクティブ化するセルIDであってもよい。ステップS70は、第1実施形態のステップS14(図11)、第1実施形態の第1変形例のステップS26(図12)、第1実施形態の第2変形例のステップS34(図13)、又は第1実施形態の第3変形例のステップS46(図14)などであってもよい。
【0171】
ステップS71において、IABノード300-Pは、現在使用しているセルのセルIDと並行して、新たなセルのセルIDを報知する。新たなセルのセルIDとは、例えば、IABノード300-Pのハンドオーバにより、新たにアクセスするセルのセルIDのことである。新たなセルのセルIDは、現在IABノード300-Pが使用するセルIDとは異なる変更後のセルIDでもよい。
【0172】
ステップS72において、IABノード300-Pは、PSSとSSSとを報知することで、現在使用しているPCIと、新たなPCIとを報知してもよい。
【0173】
ステップS73において、IABノード300-Pは、SIB1を用いて、現在使用しているCell IDと、新たなCell IDとを報知してもよい。
【0174】
ステップS74において、IABノード300-Pは、現在使用しているセルから新たなセルへ、子ノード300-C及び/又はUE100をハンドオーバさせる。この際、IABノード300-Pは、RACH-lessハンドオーバを設定するようにしてもよい。又は、IABノード300-Pは、第2実施形態で説明したソフトハンドオーバ(図16のステップS53)を設定するようにしてもよい。
【0175】
ステップS75において、IABノード300-Pは、配下の全ての子ノード300-C及び/又はUE100を新セルへハンドオーバさせた後、現在使用しているセルのセルIDの報知を停止する。例えば、IABノード300-Pは、配下の全ての子ノード300-C及び/又はUE100からハンドオーバ完了メッセージを受信すると、現在使用しているセルのセルIDの報知を停止する。
【0176】
[第5実施形態]
次に、第5実施形態について説明する。
【0177】
第1実施形態では、IABノード300がmigrationすることで、PCI Collisionが発生する場合について説明した。第5実施形態では、IABノード300がmigrationすることで、PRACH(Physical Random Access Channel)のリソースが衝突する場合の例について説明する。
【0178】
図19は、第5実施形態に係るPRACHリソースの衝突例を表す図である。図19は、IABノード300が、ソースドナーノード200-1からターゲットドナーノード200-2へハンドオーバする場合の例を表している。
【0179】
IABノード300がハンドオーバする前は、ドナーノード200-1と近接した位置に位置する。IABノード300-2のPRACHリソースR2と、IABノード300-1のPRACHリソースR1とは、衝突しないリソース配置となっている。このため、ドナーノード200-1とIABノード300との間に位置するUE100は、ドナーノード200-1に対してランダムアクセス手順を実行して、ドナーノード200-1と接続することができる。また、当該UE100は、IABノード300に対してランダムアクセス手順を実行して、IABノード300に接続することも可能となる。
【0180】
他方、IABノード300がハンドオーバすると、IABノード300は、ドナーノード200-2に近接した位置に移動する。IABノード300のPRACHリソースR2と、ドナーノード200-2のPRACHリソースR3とは、そのリソース範囲が重複する。このため、UE100は、PRACHリソースR2を用いて、RACHプリアンブル(message1)を送信しても、IABノード300は、干渉によって、RACHプリアンブルを受信することができない場合がある。仮に、IABノード300とドナーノード200-2が、ともに、UE100から送信されたRACHプリアンブルを受信した場合、IABノード300及びドナーノード200-2は、双方ともRACHレスポンス(message2)をUE100へ送信する。UE100は、RACHレスポンスを双方から受信するため不定状態になる。そのため、UE100は、IABノード300へのランダムアクセス手順を失敗し、IABノード300へ接続できなくなる。
【0181】
これに対して、第5実施形態では、最初に、第1通信ノード(例えば、ソースドナーノード200-1)が、第1通信ノードに隣接する隣接ノードから受信した隣接ノードのPRACH設定に基づいて、当該隣接ノードのPRACH設定と衝突しないPRACH設定を決定する。次に、第1通信ノードが、決定したPRACH設定を中継ノード(例えば、IABノード300)へ送信する。そして、ソースドナーノード200-1は、ターゲットドナーノード200-2との間でハンドオーバ処理を実行し、中継ノードは、決定したPRACH設定を、ターゲットドナーノード200-2に対して適用する。
【0182】
例えば、図19の例では、ソースドナーノード200-1は、隣接ノードのPRACH設定として、ターゲットドナーノード200-2のPRACH設定(例えば、PRACHリソースR3)を受信する。ソースドナーノード200-1は、自局のPRACH設定(例えば、PRACHリソースR1)と、ターゲットドナーノード200-2のPRACH設定(例えば、PRACHリソースR3)とで重複しないPRACH設定(例えば、PRACHリソースR4)を決定する。そして、ソースドナーノード200-1は、当該PRACH設定を、IABノード300へ送信する。
【0183】
IABノード300は、ターゲットドナーノード200-2に対して、当該PRACH設定を適用しても、PRACHリソースはいずれとも重複しないため、ターゲットドナーノード200-2へ適切にアクセスすることができる。従って、ソースドナーノード200-1は、PRACHリソースの重複を抑制するように当該リソースを制御することができる。
【0184】
なお、図19の例において、ソースドナーノード200-1が当該PRACH設定を決定する例を説明したが、ターゲットドナーノード200-2が当該PRACH設定を決定してもよい。後者は、第5実施形態の第1変形例で説明する。
【0185】
(PRACH設定の通知)
ここで、PRACH設定(PRACH Configuration)の通知の例について説明する。PRACH設定は、セルにおけるPRACHリソースを示している。PRACH設定は、具体的には、リソースの開始周波数、サブキャリアスペーシング(SCS)、周波数ドメイン長などが含まれる。
【0186】
gNB-DUは、F1 Setup Responseメッセージに、各セルのPRACH設定を含めて、gNB-CUへ送信することができる。また、gNB-DUは、gNB-DU Configuration Updateメッセージに、各セルのPRACH設定を含めて、gNB-CUへ送信することができる。
【0187】
更に、gNB-CUは、RACH Optimizationのために、他のgNBのCUへ、PRACH設定を通知することも可能である。これにより、ソースドナーノード200-1は、ターゲットドナーノード200-2のPRACH設定を、ターゲットドナーノード200-2から受信できる。また、ターゲットドナーノード200-2も、ソースドナーノード200-1のPRACH設定を、ソースドナーノード200-1から受信できる。
【0188】
(第5実施形態の動作例)
次に、第5実施形態の動作例を説明する。図20は、第5実施形態に係る動作例を表す図である。ただし、図20に示す動作例が行われる前に、ソースドナーノード200-1は、隣接ドナーノードのPRACH設定として、ターゲットドナーノード200-2のPRACH設定を受信しているものとする。
【0189】
なお、以下の動作例では、ドナーノード200-1,200-2間でIABノード300がハンドオーバする例について説明する。ただし、第1実施形態と同様に、それ以外の例が適用されてもよい。すなわち、親ノード300-P1,300-P2間でIABノード300がハンドオーバする場合でもよい。上位ノード間でIABノード300がハンドオーバする場合でもよい。また、gNB-CU間でIABノード300がハンドオーバする場合でもよい。いずれの場合も、各メッセージが、親ノード300-P1,300-P2間、上位ノード間、gNB-CU間、IABノード300と親ノード間、IABノード300と上位ノード間、IABノード300のDUとgNB-CU間で交換されてもよい。
【0190】
図20に示すように、ステップS80において、ソースドナーノード200-1は、IABノード300がソースドナーノード200-1からターゲットドナーノード200-2へハンドオーバすることを決定する。
【0191】
ステップS81において、ソースドナーノード200-1は、隣接ドナーノードのPRACH設定に基づいて、IABノード300のPRACH設定を決定する。具体的には、ソースドナーノード200-1は、ターゲットドナーノード200-2のPRACH設定と、自ソースドナーノード200-1のPRACH設定とが衝突しないPRACH設定を決定する。
【0192】
ステップS82において、ソースドナーノード200-1は、決定したPRACH設定をIABノード300へ送信する。ソースドナーノード200-1は、当該PRACH設定を含むRRCメッセージ及び/又は当該PRACH設定を含むF1APメッセージを送信してもよい。この場合、ソースドナーノード200-1は、当該PRACH設定をハンドオーバ後に適用する旨の識別子を当該メッセージに含めて送信してもよい。IABノード300では、決定したPRACH設定を受信しても、ターゲットドナーノード200-2へのハンドオーバが完了するまで、当該PRACH設定の適用を保留してもよい。もしくは、IABノード300では、PRACH設定を受信すると即座に当該PRACH設定を適用してもよい。
【0193】
ステップS83において、ソースドナーノード200-1は、ターゲットドナーノード200-2との間で、Handover Preparation手順を実行する。
【0194】
ステップS84において、ソースドナーノード200-1は、Handover Preparation手順を終了すると、RRC Reconfiguration(HO Command)メッセージをIABノード300へ送信する。
【0195】
ステップS85において、IABノード300は、RRC Reconfiguration(HO Command)メッセージの受信に応じて、ステップS82で受信したPRACH設定を適用する。IABノード300は、例えば、当該メッセージ受信時、ターゲットドナーノード200-2へのアクセス開始時、又は、当該アクセス完了時に、当該PRACH設定を適用してもよい。
【0196】
(第5実施形態の第1変形例)
次に、第5実施形態の第1変形例について説明する。
【0197】
第5実施形態では、ソースドナーノード200-1が、リソース衝突が発生しないPRACH設定を決定する例を説明した。第5実施形態の第1変形例は、ターゲットドナーノード200-2が、リソース衝突が発生しないPRACH設定を決定する例である。
【0198】
具体的には、第1通信ノード(例えば、ターゲットドナーノード200-2)が、第1通信ノードに隣接する隣接ノードから受信した隣接セルのPRACH(Physical Random Access Channel)設定に基づいて、当該隣接セルのPRACH設定と衝突しないPRACH設定を決定する。そして、第1通信ノードが、決定したPRACH設定を中継ノード(例えば、IABノード300)へ送信する。
【0199】
第5実施形態の第1変形例も、第5実施形態と同様に、IABノード300は、当該PRACH設定を適用して、ターゲットドナーノード200-2にアクセスしても、PRACH設定が重複しないため、適切にアクセスすることができる。従って、第5実施形態の第1変形例も、ターゲットドナーノード200-2は、PRACHリソースの重複を抑制するように当該リソースを制御することができる。
【0200】
図21は、第5実施形態の第1変形例に係る動作例を表す図である。ただし、図21に示す動作例が行われる前に、ターゲットドナーノード200-2は、隣接ドナーノードのPRACH設定として、ソースドナーノード200-1のPRACH設定を受信しているものとする。
【0201】
図21に示すように、ステップS90において、ソースドナーノード200-1は、IABノード300がハンドオーバを行うことを決定する。
【0202】
ステップS91において、ソースドナーノード200-1は、ターゲットドナーノード200-2へ、Handover Requestメッセージを送信する。この場合、ソースドナーノード200-1は、IABノード300のPRACH設定をHandover Requestメッセージに含めて送信してもよい。ターゲットドナーノード200-2が、隣接ドナーノードのPRACH設定として、ソースドナーノード200-1のPRACH設定を事前に受信していない場合も考えられるからである。
【0203】
ステップS92において、ターゲットドナーノード200-2は、隣接セルのPRACH設定に基づいて、IABノード300のPRACH設定を決定する。具体的には、ターゲットドナーノード200-2は、ソースドナーノード200-1のPRACH設定と、自ターゲットドナーノード200-2のPRACH設定とが衝突しないPRACH設定を決定する。
【0204】
ステップS93において、ターゲットドナーノード200-2は、決定したPRACH設定を含むHandover Request Acknowledgeメッセージをソースドナーノード200-1へ送信する。
【0205】
ステップS94において、ソースドナーノード200-1は、Handover Request Acknowledgeメッセージを受信したことに応じて、決定したPRACH設定を含む、RRC Reconfiguration(HO Command)メッセージを、IABノード300へ送信する。
【0206】
ステップS95において、IABノード300は、ターゲットドナーノード200-2で決定したPRACH設定を適用する。IABノード300は、第5実施形態と同様に、RRC Reconfiguration(HO Command)メッセージ受信時、ターゲットドナーノード200-2へのアクセス開始時、又は、当該アクセス完了時に、当該PRACH設定を適用してもよい。
【0207】
(第5実施形態の第2変形例)
次に、第5実施形態の第2変形例を説明する。
【0208】
第5実施形態と、第5実施形態の第1変形例では、IABノード300がハンドオーバする際の例について説明した。第5実施形態の第2変形例では、ハンドオーバではなく、IABノード300の電源オン後の例について説明する。
【0209】
具体的には、最初に、中継ノード(例えば、IABノード300)が、電源をオンにする。次に、中継ノードは、F1 Setup Requestメッセージをドナーノード(例えば、ドナーノード200)へ送信する。次に、ドナーノードは、隣接ドナーノードのPRACH設定と、F1 Setup Requestに含まれる中継ノードのPRACH設定とに基づいて、隣接セルのPRACH設定と衝突しないPRACH設定を決定する。そして、ドナーノードは、決定したPRACH設定を含むF1 Setup Responseメッセージを中継ノードへ送信する。
【0210】
IABノード300は、ドナーノード200において隣接ドナーノードと衝突しないPRACH設定を、ドナーノード200から受信するため、当該PRACH設定を用いて、ドナーノード200にランダムアクセス手順を適切に行うことが可能となる。従って、第5実施形態の第2変形例も、ターゲットドナーノード200-2は、PRACHリソースの重複を抑制するように当該リソースを制御することができる。
【0211】
図22は、第5実施形態の第2変形例に係る動作例を表す図である。ただし、図22に示す動作例も、事前設定として、ドナーノード200は、隣接ドナーノードのPRACH設定を受信しているものとする。
【0212】
図22に示すように、ステップS100において、IABノード300は、電源をオンにする。電源オンに代えて、IABノード300は、RRC Reconfiguration(HO Command)を受信して、ドナーノード200とRRC接続を確立してもよい。
【0213】
ステップS101において、IABノード300は、F1 Setup Requestメッセージをドナーノード200へ送信する。当該メッセージには、IABノード300のPRACH設定が含まれる。Mobile IABの場合、当該メッセージには、PRACH設定を必ず含めるようにしてもよい。
【0214】
ステップS102において、ドナーノード200は、隣接ドナーノードのPRACH設定に基づいて、IABノード300のPRACH設定を確認する。具体的には、ドナーノード200は、IABノード300のPRACH設定が、隣接ドナーノードのPRACH設定と衝突するか否かを確認する。ドナーノード200は、衝突しなければ、以降の処理を行うことなく終了する。以下では、衝突するものとして説明する。
【0215】
ステップS103において、ドナーノード200は、隣接ドナーノードのPRACH設定と衝突しないPRACH設定を決定する。具体的には、ドナーノード200は、自ドナーノード200と、隣接ドナーノードのPRACH設定とが衝突しないPRACH設定を決定する。
【0216】
この場合、ドナーノード200は、当該PRACH設定を決定することに代えて、F1 Setup Failureメッセージを、IABノード300へ送信してもよい。この場合、ドナーノード200は、IABノード300のPRACH設定がNGであること、又は当該PRACH設定が衝突すること、を表す理由(Cause)を、F1 Setup Failureメッセージに含めて送信してもよい。IABノード300は、F1 Setup Failureメッセージを受信した場合、他のPRACH設定を再考するようにしてもよい。IABノード300は、他のPRACH設定をドナーノード200へ送信し、ステップS101以降を繰り返すようにしてもよい。
【0217】
ステップS104において、ドナーノード200は、決定したPRACH設定を含むF1 Setup ResponseメッセージをIABノード300へ送信する。
【0218】
ステップS105において、IABノード300は、ドナーノード200で決定したPRACH設定を適用する。IABノード300は、ドナーノード200へのアクセス開始時、又は、当該アクセス完了時に、当該PRACH設定を適用してもよい。
【0219】
図12に示す動作例において、F1 Setup Requestメッセージ(ステップS101)及びF1 Setup Responseメッセージ(ステップS104)の例を説明した。
【0220】
F1 Setup Requestメッセージに代えてgNB-DU Configuration Updateメッセージ、F1 Setup Responseメッセージに代えてgNB-DU Configuration Update Acknowledgeメッセージであってもよい。この場合、IABノード300のPRACH設定がgNB-DU Configuration Updateメッセージに含まれ、決定したPRACH設定がgNB-DU Configuration Update Acknowledgeメッセージに含まれる。
【0221】
また、F1 Setup Requestメッセージに代えてgNB-CU Configuration Updateメッセージ、F1 Setup Responseメッセージに代えてgNB-DU Configuration Update Acknowledgeメッセージであってもよい。この場合、IABノード300のPRACH設定がgNB-CU Configuration Updateメッセージに含まれ、決定したPRACH設定がgNB-DU Configuration Update Acknowledgeメッセージに含まれる。
【0222】
[その他の実施形態]
UE100、gNB200、又はIABノード300が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、CD-ROM又はDVD-ROM等の記録媒体であってもよい。
【0223】
また、UE100、gNB200、又はIABノード300が行う各処理を実行する回路を集積化し、UE100、gNB200、又はIABノード300の少なくとも一部を半導体集積回路(チップセット、SoC:System on a chip)として構成してもよい。
【0224】
本開示で使用されている「に基づいて(based on)」、「に応じて(depending on)」という記載は、別段に明記されていない限り、「のみに基づいて」、「のみに応じて」を意味しない。「に基づいて」という記載は、「のみに基づいて」及び「に少なくとも部分的に基づいて」の両方を意味する。同様に、「に応じて」という記載は、「のみに応じて」及び「に少なくとも部分的に応じて」の両方を意味する。また、「取得する(obtain/acquire)」は、記憶されている情報の中から情報を取得することを意味してもよく、他のノードから受信した情報の中から情報を取得することを意味してもよく、又は、情報を生成することにより当該情報を取得することを意味してもよい。「含む(include)」、「備える(comprise)」、及びそれらの変形の用語は、列挙する項目のみを含むことを意味せず、列挙する項目のみを含んでもよいし、列挙する項目に加えてさらなる項目を含んでもよいことを意味する。また、本開示において使用されている用語「又は(or)」は、排他的論理和ではないことが意図される。さらに、本開示で使用されている「第1」、「第2」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定するものではない。これらの呼称は、2つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第1及び第2の要素への参照は、2つの要素のみがそこで採用され得ること、又は何らかの形で第1の要素が第2の要素に先行しなければならないことを意味しない。本開示において、例えば、英語でのa,an,及びtheのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。
【0225】
以上、図面を参照して一実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。また、矛盾しない範囲で、各実施形態の全部又は一部を組み合わせることも可能である。
【0226】
本願は、日本国特許出願第2021-114499号(2021年7月9日出願)の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
【符号の説明】
【0227】
1 :移動通信システム
10 :5GC
11 :AMF
100 :UE
110 :無線通信部
120 :制御部
200(200-1,200-2):gNB(ドナーノード)
210 :無線通信部
220 :ネットワーク通信部
230 :制御部
300 :IABノード
310 :無線通信部
320 :制御部
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22