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

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

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

<>
  • 特許-中継装置 図1
  • 特許-中継装置 図2
  • 特許-中継装置 図3
  • 特許-中継装置 図4
  • 特許-中継装置 図5
  • 特許-中継装置 図6
  • 特許-中継装置 図7
  • 特許-中継装置 図8
  • 特許-中継装置 図9
  • 特許-中継装置 図10
  • 特許-中継装置 図11
  • 特許-中継装置 図12
  • 特許-中継装置 図13
  • 特許-中継装置 図14
  • 特許-中継装置 図15
  • 特許-中継装置 図16
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-12-05
(45)【発行日】2022-12-13
(54)【発明の名称】中継装置
(51)【国際特許分類】
   H04L 1/16 20060101AFI20221206BHJP
   H04W 16/26 20090101ALI20221206BHJP
   H04W 28/04 20090101ALI20221206BHJP
【FI】
H04L1/16
H04W16/26
H04W28/04 110
【請求項の数】 4
(21)【出願番号】P 2020535848
(86)(22)【出願日】2019-08-07
(86)【国際出願番号】 JP2019031188
(87)【国際公開番号】W WO2020032129
(87)【国際公開日】2020-02-13
【審査請求日】2021-02-02
(31)【優先権主張番号】62/715,959
(32)【優先日】2018-08-08
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】000006633
【氏名又は名称】京セラ株式会社
(74)【代理人】
【識別番号】110001106
【氏名又は名称】弁理士法人キュリーズ
(72)【発明者】
【氏名】藤代 真人
(72)【発明者】
【氏名】チャン ヘンリー
【審査官】谷岡 佳彦
(56)【参考文献】
【文献】特開2009-219099(JP,A)
【文献】国際公開第2017/196249(WO,A1)
【文献】中国特許出願公開第101986592(CN,A)
【文献】Huawei, HiSilicon,Further comparison between hop-by-hop ARQ and E2E ARQ[online],3GPP TSG RAN WG2 adhoc_2018_07_NR R2-1810678,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_AHs/2018_07_NR/Docs/R2-1810678.zip>,2018年07月
【文献】Nokia, Nokia Shanghai Bell,Text Proposal on end to end reliability in IAB[online],3GPP TSG RAN WG2 adhoc_2018_07_NR R2-1810811,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_AHs/2018_07_NR/Docs/R2-1810811.zip>,2018年07月
【文献】Ericsson,Layer 2 Functions for Multi-hop IAB System[online],3GPP TSG RAN WG2 #102 R2-1806814,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_102/Docs/R2-1806814.zip>,2018年05月
(58)【調査した分野】(Int.Cl.,DB名)
H04L 1/16
H04W 16/26
H04W 28/04
(57)【特許請求の範囲】
【請求項1】
移動通信システムに用いられる中継装置であって、
第1の通信装置からデータを受信する受信側RLCエンティティと、
前記受信側RLCエンティティが受信した前記データを第2の通信装置に送信する送信側RLCエンティティと、を備え、
前記送信側RLCエンティティは、前記送信されたデータを前記第2の通信装置が受信成功したことを示す第1の肯定応答を前記第2の通信装置から受信し、
前記受信側RLCエンティティは、前記送信側RLCエンティティが前記第1の肯定応答を受信するまで待った後、前記データを前記受信側RLCエンティティが受信成功したことを示す第2の肯定応答を前記第1の通信装置に送信し、
前記受信側RLCエンティティ及び前記送信側RLCエンティティよりも上位のレイヤに位置付けられる上位エンティティをさらに備え、
前記上位エンティティは、前記第1の肯定応答に関する情報を前記送信側RLCエンティティから取得し、該取得された情報を前記受信側RLCエンティティに提供し、
前記受信側RLCエンティティは、前記上位エンティティから提供される情報に基づいて、前記送信側RLCエンティティが前記第1の肯定応答を受信したことを確認する
継装置。
【請求項2】
前記受信側RLCエンティティは、前記第1の通信装置からの前記データを受信してから、前記送信側RLCエンティティが前記第1の肯定応答を受信するまでの待ち時間を計時し、
前記受信側RLCエンティティは、前記待ち時間が一定時間を超える場合に、前記受信側RLCエンティティが前記データを受信失敗したことを示す否定応答を前記第1の通信装置に送信する
請求項1に記載の中継装置。
【請求項3】
前記第2の通信装置は、当該中継装置とドナー基地局との間の通信に介在する他の中継装置であり、
前記送信側RLCエンティティは、前記受信側RLCエンティティにより受信された前記データを、前記他の中継装置に設けられるRLCエンティティに送信し、
前記送信側RLCエンティティは、前記他の中継装置に設けられる前記RLCエンティティから前記第1の肯定応答を受信する
請求項1又は2に記載の中継装置。
【請求項4】
前記送信側RLCエンティティは、
前記送信されたデータを前記第2の通信装置が受信失敗したことを示す第1の否定応答を前記第2の通信装置から受信したことに応じて、前記データを再送し、
前記再送した後に前記第1の肯定応答を前記第2の通信装置から受信した場合であっても、前記上位エンティティに前記第1の肯定応答に関する情報を提供する、
請求項1乃至3のいずれか1項に記載の中継装置。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、移動通信システムに用いられる中継装置に関する。
【背景技術】
【0002】
移動通信システムの標準化プロジェクトである3GPP(3rd Generation Partnership Project)において、IAB(Integrated Access and Backhaul)ノードと称される新たな中継装置が検討されている。1又は複数の中継装置が基地局とユーザ機器との間の通信に介在し、この通信に対する中継を行う。かかる中継装置は、ユーザ機器機能及び基地局機能を有しており、ユーザ機器機能を用いて上位ノード(基地局又は上位の中継装置)との無線通信を行うとともに、基地局機能を用いて下位ノード(ユーザ機器又は下位の中継装置)との無線通信を行う。
【0003】
ユーザ機器と、中継装置又は基地局との間の無線区間は、アクセスリンクと称されることがある。中継装置と、基地局又は他の中継装置との間の無線区間は、バックホールリンクと称されることがある。3GPP寄書「RP-170217」には、アクセスリンクのデータ通信及びバックホールリンクのデータ通信をレイヤ2において統合及び多重化し、バックホールリンクに動的に無線リソースを割り当てることにより、データ転送経路を動的に切り替える方法が記載されている。
【発明の概要】
【0004】
一実施形態に係る中継装置は、移動通信システムに用いられる。前記中継装置は、第1の通信装置からデータを受信する受信側RLCエンティティと、前記受信側RLCエンティティが受信した前記データを第2の通信装置に送信する送信側RLCエンティティとを備える。前記送信側RLCエンティティは、前記送信されたデータを前記第2の通信装置が受信成功したことを示す第1の肯定応答を前記第2の通信装置から受信する。前記受信側RLCエンティティは、前記送信側RLCエンティティが前記第1の肯定応答を受信するまで待った後、前記データを前記受信側RLCエンティティが受信成功したことを示す第2の肯定応答を前記第1の通信装置に送信する。
【0005】
一実施形態に係る中継装置は、移動通信システムに用いられる。前記中継装置は、第1の通信装置からデータを受信する受信側RLCエンティティと、第2の通信装置と対応付けられた第1の送信側RLCエンティティと、第3の通信装置と対応付けられた第2の送信側RLCエンティティと、前記受信側RLCエンティティが受信した前記データを前記第1の送信側RLCエンティティに提供するとともに前記データを保持する上位エンティティとを備える。前記上位エンティティは、当該中継装置と前記第2の通信装置との間の無線状態の悪化、又は前記第2の通信装置から前記第3の通信装置へのデータ転送経路の切り替えに応じて、前記保持しているデータを前記第2の送信側RLCエンティティに提供する。
【図面の簡単な説明】
【0006】
図1】実施形態に係る移動通信システムの構成を示す図である。
図2】実施形態に係る基地局(gNB)の構成を示す図である。
図3】実施形態に係る中継装置(IABノード)の構成を示す図である。
図4】実施形態に係るユーザ機器(UE)の構成を示す図である。
図5】実施形態に係る移動通信システムにおけるユーザプレーンのプロトコルスタック構成の一例を示す図である。
図6】第1実施形態に係る通常動作シーケンスの一例を示す図である。
図7】第1実施形態に係るコンテキスト転送先を決定するためのテーブルの一例を示す図である。
図8】第1実施形態に係る例外動作シーケンスの一例を示す図である。
図9】第1実施形態に係るマルチホップ接続シーケンスの一例を示す図である。
図10】第2実施形態に係る「end-to-end」の一例を示す図である。
図11】第2実施形態に係る「hop-by-hop」の一例を示す図である。
図12】第2実施形態に係る動作例を示すシーケンス図である。
図13】第2実施形態に係る他の動作例を示すシーケンス図である。
図14】第2実施形態の変更例を示す図である。
図15】UEへのRLC ACKの送信を遅らせる選択肢1を示す図である。
図16】UEへのRLC ACKの送信を遅らせる選択肢2を示す図である。
【発明を実施するための形態】
【0007】
図面を参照しながら、一実施形態に係る移動通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
【0008】
[第1実施形態]
(移動通信システムの構成)
本実施形態に係る移動通信システムの構成について説明する。図1は、本実施形態に係る移動通信システム1の構成を示す図である。移動通信システム1は、3GPP規格に基づく第5世代(5G)移動通信システムである。具体的には、移動通信システム1における無線アクセス方式は、5Gの無線アクセス方式であるNR(New Radio)である。但し、移動通信システム1には、LTE(Long Term Evolution)が少なくとも部分的に適用されてもよい。
【0009】
図1に示すように、移動通信システム1は、5Gコアネットワーク(5GC)10と、ユーザ機器(UE)100と、基地局(gNBと称される)200と、IABノード300とを備える。本実施形態において、基地局がNR基地局である一例について主として説明するが、基地局がLTE基地局(すなわち、eNB)であってもよい。
【0010】
5GC10は、AMF(Access and Mobility Management Function)11及びUPF(User Plane Function)12を備える。AMF11は、UE100に対する各種モビリティ制御等を行う装置である。AMF11は、NAS(Non-Access Stratum)シグナリングを用いてUE100と通信することにより、UE100が在圏するエリアの情報を管理する。UPF12は、ユーザデータの転送制御等を行う装置である。
【0011】
gNB200は、NGインターフェイスと称されるインターフェイスを介して、5GC10に接続される。図1において、5GC10に接続された3つのgNB200-1~gNB200-3を例示している。gNB200は、UE100との無線通信を行う固定の無線通信装置である。gNB200がドナー機能を有する場合、gNB200は、自身に無線で接続するIABノードとの無線通信を行ってもよい。
【0012】
gNB200は、Xnインターフェイスと称される基地局間インターフェイスを介して、隣接関係にある他のgNB200と接続される。図1において、gNB200-1がgNB200-2及びgNB200-2に接続される一例を示している。
【0013】
各gNB200は、1又は複数のセルを管理する。セルは、無線通信エリアの最小単位を示す用語として用いられる。セルは、UE100との無線通信を行う機能又はリソースを示す用語として用いられることがある。1つのセルは1つのキャリア周波数に属する。
【0014】
UE100は、gNB200との無線通信を行う移動可能な無線通信装置である。UE100は、IABノード300との無線通信を行ってもよい。UE100は、gNB200又はIABノード300との無線通信を行う装置であればどのような装置であっても構わないが、例えば、UE100は、携帯電話端末やタブレット端末、ノートPC、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置である。
【0015】
図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との通信を間接的に行う。
【0016】
IABノード300は、eNB200とUE100との間の通信に介在し、この通信に対する中継を行う装置(中継装置)である。図1において、IABノード300-1がドナーであるgNB200-1に無線で接続され、IABノード300-2がIABノード300-1に無線で接続される一例を示している。各IABノード300は、セルを管理する。IABノード300が管理するセルのセルIDは、ドナーgNB200-1のセルのセルIDと同じであってもよいし、異なっていてもよい。
【0017】
IABノード300は、UE機能(ユーザ機器機能)及びgNB機能(基地局機能)を有する。IABノード300は、UE機能を用いて上位ノード(gNB200又は上位のIABノード300)との無線通信を行うとともに、gNB機能を用いて下位ノード(UE100又は下位のIABノード300)との無線通信を行う。なお、UE機能とは、UE100が有する機能のうち少なくとも一部の機能を意味し、必ずしもUE100の全ての機能をIABノード300が有していなくてもよい。gNB機能とは、gNB200の機能のうち少なくとも一部の機能を意味し、必ずしもgNB200の全ての機能をIABノード300が有していなくてもよい。
【0018】
UE100と、IABノード300又はgNB200との間の無線区間は、アクセスリンク(或いは、Uu)と称されることがある。IABノード300と、gNB200又は他のIABノード300との間の無線区間は、バックホールリンク(或いは、Un)と称されることがある。かかるバックホールリンクは、フロントホールリンクと称されてもよい。
【0019】
アクセスリンクのデータ通信及びバックホールリンクのデータ通信をレイヤ2において統合及び多重化し、バックホールリンクのデータ通信に動的に無線リソースを割り当て、中継の経路を動的に切り替えることが可能である。なお、アクセスリンク及びバックホールリンクには、ミリ波帯が用いられてもよい。また、アクセスリンク及びバックホールリンクは、時分割及び/又は周波数分割により多重化されてもよい。
【0020】
(gNBの構成)
本実施形態に係るgNB200の構成について説明する。図2は、gNB200の構成を示す図である。図2に示すように、gNB200は、無線通信部210と、ネットワーク通信部220と、制御部230とを備える。
【0021】
無線通信部210は、UE100との無線通信及びIABノード300との無線通信に用いられる。無線通信部210は、受信部211及び送信部212を備える。受信部211は、制御部230の制御下で各種の受信を行う。受信部211はアンテナを含み、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部230に出力する。送信部212は、制御部230の制御下で各種の送信を行う。送信部212はアンテナを含み、制御部230が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
【0022】
ネットワーク通信部220は、5GC10との有線通信(又は無線通信)及び隣接する他のgNB200との有線通信(又は無線通信)に用いられる。ネットワーク通信部220は、受信部221及び送信部222を備える。受信部221は、制御部230の制御下で各種の受信を行う。受信部221は、外部から信号を受信して受信信号を制御部230に出力する。送信部222は、制御部230の制御下で各種の送信を行う。送信部222は、制御部230が出力する送信信号を外部に送信する。
【0023】
制御部230は、gNB200における各種の制御を行う。制御部230は、少なくとも1つのプロセッサ及び少なくとも1つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサとCPU(Central Processing Unit)とを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
【0024】
(IABノードの構成)
本実施形態に係るIABノード300の構成について説明する。図3は、IABノード300の構成を示す図である。図3に示すように、IABノード300は、無線通信部310と、制御部320とを備える。
【0025】
無線通信部310は、gNB200との無線通信(バックホールリンク)及びUE100との無線通信(アクセスリンク)に用いられる。無線通信部310は、受信部311及び送信部312を備える。受信部311は、制御部320の制御下で各種の受信を行う。受信部311はアンテナを含み、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部320に出力する。送信部312は、制御部320の制御下で各種の送信を行う。送信部312はアンテナを含み、制御部320が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
【0026】
制御部320は、IABノード300における各種の制御を行う。制御部320は、少なくとも1つのプロセッサ及び少なくとも1つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びCPUを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
【0027】
(UEの構成)
本実施形態に係るUE100の構成について説明する。図4は、UE100の構成を示す図である。図4に示すように、UE100は、無線通信部110と、制御部120とを備える。
【0028】
無線通信部110は、アクセスリンクにおける無線通信、すなわち、gNB200との無線通信及びIABノード300との無線通信に用いられる。無線通信部110は、受信部111及び送信部112を備える。受信部111は、制御部120の制御下で各種の受信を行う。受信部111はアンテナを含み、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部120に出力する。送信部112は、制御部120の制御下で各種の送信を行う。送信部112はアンテナを含み、制御部120が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
【0029】
制御部120は、UE100における各種の制御を行う。制御部120は、少なくとも1つのプロセッサ及び少なくとも1つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びCPUを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
【0030】
(プロトコルスタック構成の一例)
本実施形態に係る移動通信システム1におけるプロトコルスタック構成の一例について説明する。図5は、ユーザプレーンのプロトコルスタック構成の一例を示す図である。ここでは、図1に示したUE100-3と5GC10のUPF12との間のユーザデータ伝送に関するプロトコルスタック構成の一例について説明する。
【0031】
図5に示すように、UPF12は、GTP-U(GPRS Tunneling Protocol for User Plane)と、UDP(User Datagram Protocol)と、IP(Internet Protocol)と、レイヤ1/レイヤ2(L1/L2)とを備える。gNB200-1(ドナーgNB)には、これらに対応するプロトコルスタックが設けられる。
【0032】
また、gNB200-1は、集約ユニット(CU:Central Unit)と分散ユニット(DU:Distributed Unit)とを備える。無線インターフェイスのプロトコルスタックのうちPDCP(Packet Data Convergence Protocol)以上の各レイヤをCUが有し、RLC(Radio Link Control)以下の各レイヤをDUが有し、F1インターフェイスと称されるインターフェイスを介してCU及びDUが接続される。
【0033】
具体的には、CUは、SDAP(Service Data Adaptation Protocol)と、PDCPと、IPと、L1/L2とを備える。CUのSDAP及びPDCPは、DUと、IABノード300-1と、IABノード300-2とを介して、UE100のSDAP及びPDCPとの通信を行う。
【0034】
また、DUは、無線インターフェイスのプロトコルスタックのうち、RLCと、アダプテーションレイヤ(Adapt)と、MAC(Medium Access Control)と、PHY(Physical layer)とを有する。これらのプロトコルスタックは、gNB向けのプロトコルスタックである。なお、アダプテーションレイヤ及びRLC(S-RLC)は上下関係が逆であってもよい。
【0035】
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と同様なプロトコルスタック構成を有する。
【0036】
ここではユーザプレーンにおけるプロトコルスタック構成について説明した。しかしながら、制御プレーンにおいて、gNB200-1、IABノード300-1、IABノード300-2、及びUE100-3のそれぞれは、レイヤ3に相当するRRC(Radio Resource Control)を備える。
【0037】
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メッセージが送受信される。
【0038】
(移動通信システムにおける動作)
本実施形態に係る移動通信システム1における動作について説明する。具体的には、IABノード300-1がgNB200-1(ドナーgNB)に無線で接続する場合の動作について説明する。
【0039】
かかる場合、最初に、IABノード300-1は、UE機能を用いてgNB200-1とのアクセスリンク接続(第1の無線接続)を確立する。言い換えると、IABノード300-1は、UE100として振る舞ってgNB200-1とのアクセスリンク接続を確立する。アクセスリンク接続の確立は、RRC接続の確立を含む。
【0040】
次に、gNB200-1は、アクセスリンク接続を維持しつつ、IABノード300-1のgNB機能のためのバックホールリンク接続(第2の無線接続)をIABノード300-1とgNB200-1との間に確立させるメッセージをIABノード300-1に送信する。本実施形態において、かかるメッセージは、RRC接続を用いて送受信されるRRC再設定(RRC Reconfiguration)メッセージである。
【0041】
その結果、バックホールリンク接続がIABノード300-1とgNB200-1との間に確立されるため、IABノード300-1とgNB200-1との間でバックホールリンクの通信を適切に開始可能とすることができる。
【0042】
バックホールリンク接続を確立させるRRC再設定メッセージは、バックホールリンク接続を構成するベアラ(又はL2リンク)の設定情報、及びIABノード300-1が送信するべきセルID(具体的には、セルIDに関連付けられた参照信号及び同期信号の送信設定)を含んでもよい。以下において、かかるRRC再設定メッセージをIABノード設定メッセージと称する。
【0043】
IABノード設定メッセージは、デフォルトベアラ(又はデフォルトリンク)の設定情報を含んでもよい。デフォルトベアラ(又はデフォルトリンク)は、例えば、SIB(System Information Block)の中継やUEからのMsg3中継などを行うためのベアラ(又はリンク)である。
【0044】
IABノード設定メッセージは、ドナーgNB200-1側のスタックの設定情報と、オプションでIABノード300-2(又はUE100)側のスタックの設定情報とを含んでもよい。IABノード300-2(又はUE100)側のスタックの設定情報は、暗示的にドナーgNB200-1のSIBで報知されている設定群を再利用してもよいし、オペレータ(OAM)から(事前に)設定されてもよい。
【0045】
IABノード設定メッセージにおける設定内容としては、基本的にRRC再設定メッセージに含まれる設定全てが対象になり得るが、RLC設定(AM:Acknowledged Mode/UM:Unacknowledged Mode/TM:Transparent Mode等の動作モード、LCP(Logical Channel Prioritization)パラメータ等)、MAC設定(BSR:Buffer Status Report/TAG:Timing Advance Group/PHR:Power Headroomパラメータ、DRX:Discontinues Reception設定等)、PHY設定が含まれてもよい。
【0046】
また、IABノード設定メッセージにおける設定内容には、アダプテーションレイヤの設定(下位側又は上位側の論理チャネルのマッピング(ルーティング)設定、優先度設定等)が含まれてもよい。
【0047】
さらに、IABノード設定メッセージにおける設定内容には、必要に応じて、IABノード300-1の(仮想的な)IPアドレス(すなわち、L3アドレス)を含めてもよい。これは、例えばF1インターフェイスをL2リンク上に確立するために、F1のプロトコルスタックがSCTP over IPを想定しているためである。
【0048】
なお、IABノード設定メッセージにおける設定内容は、NRプロトコルの設定情報に限らず、LTEプロトコル(RLC、MAC、PHY)の設定情報であってもよい。
【0049】
本実施形態において、IABノード300-1は、バックホールリンク接続を確立するよりも前に、IABノードの機能(すなわち、レイヤ2中継機能)を有すること又はバックホールリンク接続の確立を要求することを示すインディケーションをgNB200-1に送信してもよい。これにより、gNB200-1は、バックホールリンク接続を確立するためのプロシージャを適切に開始できる。以下において、かかるインディケーションをIABインディケーションと称する。IABインディケーションは、IABノード300-1におけるUE機能向けリンクプロトコルスタックをLTEで準備するのか、NRで準備するのか、もしくはその両方か、という意図又は能力を示す情報を含んでもよい。
【0050】
なお、IABノード300-1は、gNB200-1とのアクセスリンク接続の確立後にIABインディケーションを送信してもよいし、gNB200-1とのアクセスリンク接続を確立するプロシージャ中にIABインディケーションを送信してもよい。
【0051】
また、IABインディケーションをgNBに送信可能とする条件として、このgNBから、ドナー機能を有することを示すドナー機能識別子を含むSIBを受信しているという条件があってもよい。かかる場合、IABノード300-1は、gNB200-1からSIBによりドナー機能識別子を受信している場合に限り、gNB200-1に対してIABインディケーションを送信する。
【0052】
本実施形態において、IABノード300-1とのバックホールリンク接続を確立するドナー機能をgNB200-1が有する場合、gNB200-1は、IABノード300-1からIABインディケーションを受信した後、IABノード設定メッセージをIABノード300-1に送信する。一方、ドナー機能をgNB200-1が有しない場合、gNB200-1は、IABノード300-1からIABインディケーションを受信した後、IABノード設定メッセージをIABノード300-1に送信することに代えて、IABノード300-1のハンドオーバを要求するハンドオーバ要求を他のgNBに送信してもよい。ここで、gNB200-1は、ドナー機能を有する他のgNBの情報を予め記憶していることが好ましい。gNB200-1は、ドナー機能を有する他のgNBの情報をIABノード300-1から取得してもよい。IABノード300-1は、5GC10(コアネットワーク)から情報を入手、もしくは隣接セルのSIB(ドナー機能識別子)を確認することにより、ドナー機能を有する他のgNB(隣接セル)の情報を取得し、取得した情報をgNB200-1に通知する。gNB200-1は、記憶している情報又はIABノード300-1から取得した情報に基づいて、ドナー機能を有する他のgNBに対してハンドオーバ要求を送信する。これにより、IABノード300-1を他のgNBにハンドオーバさせた後に、IABノード300-1が当該他のgNBとのバックホールリンク接続を確立できる。或いは、ドナー機能をgNB200-1が有しない場合、IABノード300-1は、5GC10に対して、ドナー機能を有するセル(gNB)へハンドオーバさせることを要求し、5GC10がハンドオーバに係る処理を行ってもよい。
【0053】
本実施形態において、gNB200-1は、IABノード300-1からIABインディケーションを受信したことに応じて、無線測定を設定する測定設定をIABノード300-1に送信してもよい。IABノード300-1は、gNB200-1から測定設定を受信した後、無線測定の結果を含む測定報告をgNB200-1に送信する。gNB200-1は、IABノード300-1からの測定報告に基づいて、自身(gNB200-1)が適切なドナーgNBであるか又は他のgNBが適切なドナーgNBであるかを判断する。例えば、gNB200-1は、測定報告に基づいて、自身(gNB200-1)に対する測定結果よりも他のgNBに対する測定結果が良好であり、かつ、これらの測定報告の差が閾値よりも大きい場合に、他のgNBが適切なドナーgNBであると判断する。そうでなければ、gNB200-1は、自身が適切なドナーgNBであると判断する。
【0054】
そして、自身(gNB200-1)が適切なドナーgNB200-1であると判断した場合、gNB200-1は、IABノード設定メッセージをIABノード300-1に送信する。一方、他のgNBが適切なドナーgNBであると判断した場合、gNB200-1は、IABノード設定メッセージをIABノード300-1に送信することに代えて、IABノード300-1のハンドオーバを要求するハンドオーバ要求を当該他のgNBに送信する。これにより、IABノード300-1をより無線状態の良好な他のgNBにハンドオーバさせて、IABノード300-1が当該他のgNBとのバックホールリンク接続を確立できる。
【0055】
本実施形態において、gNB200-1は、バックホールリンク接続の確立後、IABノード300-1に関するコンテキスト情報を他のgNBに送信してもよい。このコンテキスト情報は、無線側のASレイヤの接続設定(RRC再設定の内容)、ネットワーク側のPDUセッションリソース設定(AMF又はRAN(Radio Access Network)のUE ID、セッションID、QoS(Quality of Service)/スライス設定等)、その他関連情報(IABノードの挙動や通信などの履歴情報、プリファレンス情報などを含む。
【0056】
具体的には、gNB200-1は、IABノード300-1を他のgNBにハンドオーバさせるという判断を行っていなくても、IABノード300-1に関するコンテキスト情報を予め他のgNBに送信する。これにより、gNB200-1とIABノード300-1との間の無線状態が悪化し、IABノード300-1が他のgNBとの無線接続を再確立する場合に、予め共有したコンテキスト情報を用いて速やかな再確立を行うことができる。
【0057】
ここで、gNB200-1は、IABノード300-1とIABノード300-1のドナーgNBの候補とを対応付けるテーブルを保持していることが好ましい。gNB200-1は、テーブル中の候補である他のgNBに対してコンテキスト情報を送信する。これにより、gNB200-1は、コンテキスト情報を適切な他のgNBと共有できる。
【0058】
(1)通常動作シーケンスの一例
図6は、本実施形態に係る移動通信システム1における通常動作シーケンスの一例を示す図である。
【0059】
図6に示すように、ステップS101において、IABノード300-1は、例えばgNB200-1に対してランダムアクセスプロシージャを行うことにより、gNB200-1とのアクセスリンク接続(RRC接続)を確立する。IABノード300-1は、ランダムアクセスプロシージャ中にgNB200-1に送信するメッセージ(例えば、Msg3)にIABインディケーションを含めてもよい。また、gNB200-1は、ステップS101において、IABノード300-1に関するコンテキスト情報を取得する。
【0060】
ステップS102において、IABノード300-1は、gNB200-1を介して、5GC10(具体的には、AMF11)に対するアタッチプロシージャを行う。ここで、IABノード300-1は、IABインディケーションのような通知(つまり、IABノードとして動作したいことを示す通知)をAMF11に通知してもよい。これにより、IABノード300-1は、AMF11から、ドナーgNB(セル)の候補リストや下位ノードの有無などのルーティング情報、その他管理情報などを入手してもよい。もしくは、AMF11からドナーgNBの各候補に対して、IABノード300-1のアタッチがあった旨や、IABノード300-1のルーティング情報などのコンテキスト情報を通知してもよい。なお、IABノード300-1が既にアタッチしている場合は、ステップS102におけるアタッチ処理を省略可能である。具体的には、IABノード300-1は、ステップS101において、RRC再確立(Reestablishment)などのように、何らかのエラー発生によってドナーgNBとの接続を再確立しなければならない場合などにおいて、アタッチ処理を省略する。
【0061】
ステップS103において、IABノード300-1は、IABインディケーションをgNB200-1に送信する。IABノード300-1は、次のイベントのうち1又は複数が満たされたことをトリガとしてIABインディケーションを送信してもよい。
【0062】
・Msg5(RRC Complete)を送信する際。
【0063】
・gNBとの接続が確立した際(Msg5以降でもよい。例えば最初のRRC再設定が行われた際)。
【0064】
・AMFからIAB設定情報(上記参照)を入手した際(既にIAB設定情報を持っている場合も含む)。
【0065】
・単純にIABノードとして動作したくなった際(上位レイヤからIABノードとして動作する指示を受信したことを含む)。
【0066】
・下位のIABノード300-2又はUE100-3からIABノードとなるように要求された場合(その旨の要求を示す信号を下位のIABノード300-2又はUE100-3から受信した場合)。
【0067】
・下位のIABノード300-2又はUE100-3が既に接続している場合。
【0068】
IABノード300-1は、例えばgNB200-1に送信するRRCメッセージにIABインディケーションを含める。かかるRRCメッセージは、UEとしての能力を示す「UE Capability Information」メッセージであってもよい。但し、ステップS101においてIABインディケーションを送信している場合、ステップS103は省略可能である。
【0069】
或いは、IABインディケーションは、AMF11からPDUセッションリソースの変更という形でgNB200-1に通知されてもよい。なお、AMFは、IAB管理用(専用)のAMFであってもよい。
【0070】
本通常動作シーケンスにおいては、gNB200-1がドナー能力を有すると仮定して説明を進める。gNB200-1は、IABインディケーションに基づいて、バックホールリンク接続をIABノード300-1に確立させる必要があると判断する。
【0071】
ステップS104において、gNB200-1は、無線測定を設定する測定設定をIABノード300-1に送信する。IABノード300-1は、測定設定に基づいて無線測定を行う。例えば、IABノード300-1は、現在のサービングセルであるgNB200-1のセルと、隣接セルであるgNB200-2のセルとに対して受信電力(セル固有参照信号の受信電力)の測定を行う。
【0072】
ステップS105において、IABノード300-1は、無線測定の結果を含む測定報告をgNB200-1に送信する。gNB200-1は、測定報告に基づいて、自身(gNB200-1)が適切なドナーgNBであるか又は他のgNBが適切なドナーgNBであるかを判断する。ここでは、gNB200-1が、自身(gNB200-1)が適切なドナーgNBであると判断したと仮定して説明を進める。なお、ステップS104及びステップS105の処理は必須ではなく、省略してもよい。
【0073】
ステップS106において、gNB200-1は、IABノード設定メッセージ(RRC再設定メッセージ)をIABノード300-1に送信する。IABノード設定メッセージは、gNB200-1のセル(すなわち、IABノード300-1の現在のサービングセル)をハンドオーバ先として指定するハンドオーバ指示を含んでもよい。IABノード300-1は、IABノード設定メッセージに基づいて、バックホールリンク接続をgNB200-1と確立する処理を行う。かかる確立処理は、IABノード設定メッセージ中の設定情報に基づいて、バックホールリンク用のプロトコルスタック(アダプテーション/RLC/MAC/PHYエンティティ)を生成したり、パラメータ設定したりする処理を含む。かかる確立処理は、UE側(のアクセスリンク用)のプロトコルスタックを準備して、同期信号やセル固有参照信号の送信を開始する処理(もしくは、開始する準備をする処理)を含んでもよい。
【0074】
ステップS107において、IABノード300-1は、バックホールリンク接続の確立を含むIABノード設定が完了したことを示す完了通知メッセージをgNB200-1に送信する。ステップS107以降は、IABノード300-1はgNB200-1に対してUEとして振る舞うのではなく、IABノードとして振る舞う。
【0075】
ステップS108において、gNB200-1は、ステップS101において取得したコンテキスト情報を、Xnインターフェイス上でgNB200-2に転送する。gNB200-1は、IABノード300-1とIABノード300-1のドナーgNBの候補とを対応付けるテーブルを保持しており、このテーブルを参照してコンテキスト転送先を決定する。このようにして、gNB200-1が、他のgNBに対してコンテキストを事前に転送しておけば、IABノード300-1と接続しているgNBとの無線接続状態が悪化した場合に、直ぐに、当該他のgNBとの再接続を確立することができる。図7は、コンテキスト転送先を決定するためのテーブルの一例を示す図である。かかるテーブルは、例えばオペレータにより各gNBに対して予め設定される。図7に示すように、テーブルにおいて、IABノードごとに、そのドナーgNBの候補が対応けられている。具体的には、IABノードに関する識別子ごとに、そのドナーgNBの候補の識別子が対応けられている。例えば、IABノードに地理的に近いgNBがそのIABノードのドナーgNBの候補として設定される。なお、gNBとの対応付けの例を示したが、セルIDとの対応付けであってもよい。セルIDは、物理レイヤセルIDでもよく、グローバルセルIDでもよい。なお、gNB200-1は、IABノード300-1から受信した測定報告に基づいて、IABノード300-1に地理的に近いgNB200-1をドナー候補として決定してもよい。gNB200-1は、当該決定したドナー候補に基づいて、IABノード300-1と当該IABノード300-1のドナーgNBの候補とを対応付けるテーブルを作成又は既存のテーブルを更新してもよい。
【0076】
ステップS109において、gNB200-1は、IABノード300-1とのバックホールリンク接続を確立したことを示す通知を5GC10に送信する。もしくは、gNB200-1は、IABノード用のPDUセッションの確立要求を5GC10に送信してもよい。なお、上述したように、PDUセッションの確立要求は、ステップS109よりも先に又はステップS109においてAMF11からgNB200-1に送信されてもよい。
【0077】
(2)例外動作シーケンスの一例
図8は、本実施形態に係る移動通信システム1における例外動作シーケンスの一例を示す図である。例外動作シーケンスにおいて、gNB200-1は、IABノード300-1をgNB200-2にハンドオーバさせる。
【0078】
図8に示すように、ステップS201において、IABノード300-1は、例えばgNB200-1に対してランダムアクセスプロシージャを行うことにより、gNB200-1とのアクセスリンク接続(RRC接続)を確立する。IABノード300-1は、ランダムアクセスプロシージャ中にgNB200-1に送信するメッセージ(例えば、Msg3)にIABインディケーションを含めてもよい。また、gNB200-1は、ステップS201において、IABノード300-1に関するコンテキスト情報を取得する。
【0079】
ステップS202において、IABノード300-1は、gNB200-1を介して、5GC10(具体的には、AMF11)に対するアタッチプロシージャを行う。
【0080】
ステップS203において、IABノード300-1は、IABインディケーションをgNB200-1に送信する。IABノード300-1は、例えばgNB200-1に送信するRRCメッセージにIABインディケーションを含める。かかるRRCメッセージは、UEの能力を示す「UE Capability Information」メッセージであってもよい。但し、ステップS201においてIABインディケーションを送信している場合、ステップS203は省略可能である。
【0081】
ステップS204において、gNB200-1は、自身がドナー能力を有するか否かを判断する。gNB200-1がドナー能力を有しない場合(ステップS204:NO)、gNB200-1は、処理をステップS208に進める。
【0082】
gNB200-1がドナー能力を有する場合(ステップS204:YES)、ステップS205において、gNB200-1は、無線測定を設定する測定設定をIABノード300-1に送信する。IABノード300-1は、測定設定に基づいて無線測定を行う。例えば、IABノード300-1は、現在のサービングセルであるgNB200-1のセルと、隣接セルであるgNB200-2のセルとに対して受信電力(セル固有参照信号の受信電力)の測定を行う。
【0083】
ステップS206において、IABノード300-1は、無線測定の結果を含む測定報告をgNB200-1に送信する。
【0084】
ステップS207において、gNB200-1は、測定報告に基づいて、自身(gNB200-1)が適切なドナーgNBであるか又は他のgNBが適切なドナーgNBであるかを判断する。自身(gNB200-1)が適切なドナーgNBであると判断した場合(ステップS207:YES)、gNB200-1は、上述した通常動作シーケンス(図6参照)のステップS106に処理を進める。
【0085】
一方、他のgNBが適切なドナーgNBであると判断した場合(ステップS207:NO)、gNB200-1は、ステップS208に処理を進める。
【0086】
ステップS208において、gNB200-1は、IABノード300-1から受信したIABインディケーションを含むハンドオーバ要求メッセージをXnインターフェイス上でgNB200-2に転送する。gNB200-1は、ステップS201において取得したコンテキスト情報をハンドオーバ要求メッセージに含めてもよい。または、gNB200-1は、ハンドオーバ要求メッセージに、IABインディケーションを含める代わりに、IABノード300-1がgNBに対してドナーgNBとして機能することを要求する旨を示す情報を含めて送信してもよい。なお、ステップS208において、gNB200-1は、gNB200-2がドナー能力を有すると判断した上で、ハンドオーバ要求メッセージをXnインターフェイス上でgNB200-2に転送してもよい。具体的には、例えば、gNB200-1は、図7に示すテーブルにおいて、IABノード300-1にドナー候補としてgNB200-2が対応付けられていると判断した場合に、ハンドオーバ要求メッセージをgNB200-2に対して転送してもよい。この場合、gNB200-2がハンドオーバ要求を拒否する可能性が低減されるため、IABノード300-1のハンドオーバをより早急に実行することができる。または、互いに隣接する複数のgNB200間でXnインターフェイスを介して、自身のドナー能力に関する情報を事前に共有してもよい。これによって、gNB200-1は、ドナー能力を有する隣接のgNB200を特定することができ、当該特定した隣接のgNB200に対してハンドオーバ要求メッセージを転送することができる。
【0087】
gNB200-2は、ハンドオーバ要求メッセージに含まれるIABインディケーションも考慮して、IABノード300-1のハンドオーバを受け入れるか否かを判断する。gNB200-2は、自身がドナー能力を有しない場合には、ハンドオーバ要求を拒否してもよい。ここではgNB200-2がIABノード300-1のハンドオーバを受け入れると判断したと仮定して説明を進める。
【0088】
ステップS209において、gNB200-2は、ハンドオーバ肯定応答メッセージをXnインターフェイス上でgNB200-1に送信する。
【0089】
ステップS210において、gNB200-1は、gNB200-2からのハンドオーバ肯定応答メッセージに基づいて、ハンドオーバ指示メッセージ(RRC再設定メッセージ)をIABノード300-1に送信する。ハンドオーバ指示メッセージは、ハンドオーバ先のgNB200-2(のセル)を指定する情報を含む。
【0090】
ステップS211において、IABノード300-1は、gNB200からのハンドオーバ指示メッセージに基づいて、gNB200-2へのハンドオーバを行う。
【0091】
(3)マルチホップ接続シーケンスの一例
図9は、本実施形態に係る移動通信システム1におけるマルチホップ接続シーケンスの一例を示す図である。マルチホップ接続シーケンスは、IABノード300-1とgNB200-1との間にバックホールリンク接続が接続された後において、IABノード300-1にIABノード300-2又はUE100-2が接続する場合のシーケンスである。ここではIABノード300-1にIABノード300-2が接続する場合について主として説明するが、IABノード300-2をUE100-2と適宜読み替えてもよい。また、上述した「(1)通常動作シーケンス」と重複する説明を省略する。
【0092】
図9に示すように、ステップS301において、IABノード300-2は、IABノード300-1を介してgNB200-1に対してランダムアクセスプロシージャを行うことにより、gNB200-1とのアクセスリンク接続(RRC接続)を確立する。IABノード300-2は、ランダムアクセスプロシージャ中にgNB200-1に送信するメッセージ(例えば、Msg3)にIABインディケーションを含めてもよい。また、gNB200-1は、ステップS301において、IABノード300-2に関するコンテキスト情報を取得する。
【0093】
ステップS302において、IABノード300-2は、IABノード300-2及びgNB200-1を介して、5GC10(具体的には、AMF11)に対するアタッチプロシージャを行う。ここで、IABノード300-2は、IABインディケーションのような通知(つまり、IABノードとして動作したいことを示す通知)をAMF11に通知してもよい。これにより、IABノード300-2は、AMF11から、ドナーgNB(セル)の候補リストや下位ノードの有無などのルーティング情報、その他管理情報などを入手してもよい。もしくは、AMF11からドナーgNBの各候補に対して、IABノード300-2のアタッチがあった旨や、IABノード300-2のルーティング情報などのコンテキスト情報を通知してもよい。なお、IABノード300-2が既にアタッチしている場合は、ステップS302におけるアタッチ処理を省略可能である。具体的には、IABノード300-2は、RRC再確立(Reestablishment)などのように、何らかのエラー発生によってドナーgNBとの接続を再確立しなければならない場合などにおいて、アタッチ処理を省略する。
【0094】
ステップS303において、IABノード300-2は、IABノード300-1を介してIABインディケーションをgNB200-1に送信する。IABノード300-2は、上述した「(1)通常動作シーケンス」のステップS103において説明したトリガと同様なトリガに応じてIABインディケーションを送信してもよい。
【0095】
IABノード300-2は、例えばgNB200-1に送信するRRCメッセージにIABインディケーションを含める。かかるRRCメッセージは、UEとしての能力を示す「UE Capability Information」メッセージであってもよい。但し、ステップS301においてIABインディケーションを送信している場合、ステップS303は省略可能である。
【0096】
或いは、IABインディケーションは、AMF11からPDUセッションリソースの変更という形でgNB200-1に通知されてもよい。なお、AMFは、IAB管理用(専用)のAMFであってもよい。
【0097】
本動作シーケンスにおいては、gNB200-1がドナー能力を有すると仮定しているため、gNB200-1は、IABインディケーションに基づいて、バックホールリンク接続をIABノード300-1とIABノード300-2との間に確立させる必要があると判断する。
【0098】
ステップS304において、gNB200-1は、無線測定を設定する測定設定をIABノード300-2に送信する。IABノード300-2は、測定設定に基づいて無線測定を行う。
【0099】
ステップS305において、IABノード300-2は、無線測定の結果を含む測定報告を、IABノード300-1を介してgNB200-1に送信する。gNB200-1は、測定報告に基づいて、自身(gNB200-1)が適切なドナーgNBであるか又は他のgNBが適切なドナーgNBであるかを判断する。ここでは、gNB200-1が、自身(gNB200-1)が適切なドナーgNBであると判断したと仮定して説明を進める。なお、ステップS304及びステップS305の処理は必須ではなく、省略してもよい。
【0100】
ステップS306において、gNB200-1は、IABノード設定メッセージ(RRC再設定メッセージ)をIABノード300-2に送信する。IABノード300-2は、IABノード設定メッセージに基づいて、バックホールリンク接続をIABノード300-1と確立する処理を行う。かかる確立処理は、IABノード設定メッセージ中の設定情報に基づいて、バックホールリンク用のプロトコルスタック(アダプテーション/RLC/MAC/PHYエンティティ)を生成したり、パラメータ設定したりする処理を含む。かかる確立処理は、UE側(のアクセスリンク用)のプロトコルスタックを準備して、同期信号やセル固有参照信号の送信を開始する処理(もしくは、開始する準備をする処理)を含んでもよい。
【0101】
ステップS307において、gNB200-1は、RRC再設定メッセージをIABノード300-1に送信する。かかるRRC再設定メッセージは、IABノード300-2の追加に伴ってIABノード300-1における設定を変更するためのメッセージである。かかるRRC再設定メッセージは、例えば、IABノード300-2の論理チャネルとIABノード300-1のバックホールリンクの論理チャネルとの対応付けを示すマッピング情報を含む。なお、ステップS307は、ステップS306の前であってもよいし、ステップS306と同時であってもよい。
【0102】
ステップS308において、IABノード300-2は、IABノード300-1とのバックホールリンク接続の確立を含むIABノード設定が完了したことを示す完了通知メッセージをgNB200-1に送信する。ステップS308以降は、IABノード300-2はgNB200-1に対してUEとして振る舞うのではなく、IABノードとして振る舞う。
【0103】
ステップS309において、IABノード300-1は、IABノード300-2とのバックホールリンク接続の確立に伴う設定変更が完了したことを示す完了通知メッセージをgNB200-1に送信する。なお、ステップS309は、ステップS308の前であってもよいし、ステップS308と同時であってもよい。
【0104】
ステップS310において、gNB200-1は、ステップS301において取得したIABノード300-2のコンテキスト情報を、Xnインターフェイス上でgNB200-2に転送する。
【0105】
ステップS311において、gNB200-1は、IABノード300-2のバックホールリンク接続を確立したことを示す通知を5GC10に送信する。もしくは、gNB200-1は、IABノード300-2用のPDUセッションの確立要求を5GC10に送信してもよい。なお、上述したように、PDUセッションの確立要求は、ステップS311よりも先に又はステップS311においてAMF11からgNB200-1に送信されてもよい。
【0106】
[第1実施形態の変更例]
上述した第1実施形態において、IABノード300-1がgNB200-1に無線で接続した後に、gNB200-1がドナー能力を有しないことに応じてIABノード300-1をハンドオーバさせる一例について説明した。しかしながら、各gNB200は、自身がドナー能力を有するか否かに関する情報をIABノード300-1に提供してもよい。これにより、IABノード300-1は、ドナー能力を有するgNB200を選択したうえで接続することが可能になる。例えば、ドナー能力を有するgNB200は、ドナー能力を有することを示す情報をシステム情報ブロック(SIB)に含めてブロードキャストする。IABノード300-1は、かかるSIBに基づいて、接続先とするgNB200を選択する。IABノード300-1は、ドナー能力を有するgNB200であって、且つ、このgNB200からの受信電力が閾値以上である場合に、このgNB200を接続先として選択してもよい。または、gNB200がドナー能力を有しない場合には、IABノード300-1は、gNB200から送信されたSIBを受信したことに応じて、他のgNB200を再選択してもよい。その後、他のgNB200から送信されたSIBにより当該他のgNB200がドナー能力を有することが示される場合には、IABノード300-1は、当該他のgNB200を接続先として、ランダムアクセスプロシージャを行うと共にIABインディケーションを送信してもよい。
【0107】
或いは、各gNB200は、自身がドナー能力を有することをSIBにより通知することに加えて、又は自身がドナー能力を有することをSIBにより通知することに代えて、自身がIABノード300を取り扱う能力を有することをSIBにより通知してもよい。例えば、各gNB200は、自身がIABノード300を他のgNB(ドナーgNB)にハンドオーバする機能を有することをSIBにより通知してもよい。
【0108】
上述した第1実施形態において、IABノード300がランダムアクセスプロシージャ中にgNB200に送信するメッセージ(例えば、Msg3)にIABインディケーションを含める一例について説明した。ここで、Msg3は、例えばRRC Setup Requestメッセージである。また、IABノード300は、Msg3中のフィールド(情報要素)であるEstablishment CauseにIABインディケーションを含めてもよい。
【0109】
或いは、IABノード300は、ランダムアクセスプロシージャ中にgNB200に送信するランダムアクセスプリアンブル(Msg1)を利用して、IABインディケーションを通知してもよい。例えば、IABインディケーション用のPRACH(Physical Random Access Channel)リソースがSIBにより通知される場合、IABノード300は、通知されたIABインディケーション用のPRACHリソースの中から選択したPRACHリソースを用いてランダムアクセスプリアンブルを送信することにより、IABインディケーションを通知してもよい。ここで、PRACHリソースとは、時間・周波数リソースであってもよいし、信号系列(プリアンブル系列)であってもよい。
【0110】
或いは、IABノード300は、ランダムアクセスプロシージャ以外のタイミングでIABインディケーションを通知してもよい。例えば、UE Assistance Informationメッセージ等のRRCメッセージにIABインディケーションを含めてもよい。
【0111】
上述した第1実施形態において、gNB200が、無線測定を設定する測定設定をIABノード300又はUE100に送信し、無線測定の結果を含む測定報告を受信することにより、自身(gNB200)が適切なドナーgNBであるか又は他のgNBが適切なドナーgNBであるかを当該測定報告に基づいて判断する一例について説明した。しかしながら、このような初期接続時に測定結果を利用する場合に限らず、ネットワークトポロジの変更やデータ転送経路の変更に測定報告を利用してもよい。
【0112】
[第2実施形態]
第2実施形態について、上述した第1実施形態との相違点を主として説明する。第2実施形態は、AM(Acknowledged Mode)のRLCレイヤにおける自動再送制御(ARQ:AutomaticRepeat reQuest)に着目した実施形態である。
【0113】
UE100とgNB(ドナーgNB)200との間の通信にIABノード300が介在する場合、ARQを「end-to-end」で行う方法とARQを「hop-by-hop」で行う方法とがある。なお、本実施形態において上りリンクにおけるデータ転送について主として説明する。但し、上りリンクにおけるデータ転送に限定されるものではなく、下りリンクにおけるデータ転送であってもよい。
【0114】
図10は、「end-to-end」の一例を示す図である。
【0115】
図10に示すように、ARQを「end-to-end」で行う場合、UE100の送信側RLCエンティティ12は、IABノード300を介して上りリンクデータをgNB200の受信側RLCエンティティ32に送信するとともに、当該上りリンクデータを保持する。この上りリンクデータが伝送中に消失すると、当該上りリンクデータを受信失敗したことを示すNack(negative acknowledgement)をgNB200の受信側RLCエンティティ32がIABノード300を介してUE100の送信側RLCエンティティ12に送信する。UE100の送信側RLCエンティティ12は、Nackの受信に応じて、保持している上りリンクデータを再送する。
【0116】
一方、gNB200の受信側RLCエンティティ32が上りリンクデータの受信に成功すると、当該上りリンクデータを受信成功したことを示すAck(positive acknowledgement)をgNB200の受信側RLCエンティティ32がIABノード300を介してUE100の送信側RLCエンティティ12に送信する。但し、gNB200の受信側RLCエンティティ32は、UE100の送信側RLCエンティティ12からの要求(Status PDU)に応じてAckを送信してもよい。具体的には、Ackは、複数PDU分をまとめて送ることができるようになっているため、受信成功したら直ぐにAckを返す訳ではない。UE100の送信側RLCエンティティ12は、Ackの受信に応じて、保持している上りリンクデータを破棄するとともに、UE100のPDCPエンティティ13にデータ送信成功を通知する。なお、Ackは、1つのPDUの受信に成功するごとに返してもよい。
【0117】
なお、RLCエンティティが送信するデータは「RLC data PDU(Protocol Data Unit)」と称され、特にAMのRLCエンティティが送信するデータは「AMD(AM Data) PDU」と称される。また、AMD PDUの送信側は「transmitting AM RLC entity」と称され、AMD PDUの受信側は「receiving AM RLC entity」と称される。Ack及びNackは、「STATUS PDU」と称されるPDUに含まれる。「STATUS PDU」は、「RLC control PDU」の一種である。
【0118】
このように、UE100とgNB200との間の通信にIABノード300が介在する場合であっても、ARQを「end-to-end」で行うことにより、データ転送経路上において消失したデータが再送により受信側に伝達されることを保証できる。
【0119】
一方で、ARQを、「end-to-end」ではなく、「hop-by-hop」で行う場合、データ転送経路上でデータが消失すると、消失したデータを再送できないことがある。
【0120】
図11は、「hop-by-hop」の一例を示す図である。
【0121】
図11に示すように、UE100とIABノード300との間のARQ#1と、IABノード300とgNB200との間のARQ#2とが個別に行われる。先ず、UE100の送信側RLCエンティティ12がIABノード300の受信側RLCエンティティ22Rに上りリンクデータを送信し、且つ、IABノード300の受信側RLCエンティティ22RがUE100の送信側RLCエンティティ12にAckを送信すると、UE100の送信側RLCエンティティ12は当該上りリンクデータについて送信成功と判断する。UE100のPDCPエンティティ13は、送信側RLCエンティティ12が送信成功と判断した上りリンクデータについては、PDCP Data Recovery処理における再送対象から外す(破棄してもよい)。
【0122】
次に、IABノード300の送信側RLCエンティティ22TがgNB200の受信側RLCエンティティ32に当該上りリンクデータを送信する際に当該上りリンクデータが消失すると、gNB200の受信側RLCエンティティ32はNackをIABノード300の送信側RLCエンティティ22Tに送信し、IABノード300の送信側RLCエンティティ22Tは当該上りリンクデータを再送する。IABノード300とgNB200との間のARQ#2においてデータを回復できない場合、gNB200のPDCPエンティティ34は、PDCPレイヤの再送の仕組みであるPDCP Data Recoveryを利用して、UE100のPDCPエンティティ13に再送を要求する。しかしながら、UE100のPDCPエンティティ13は、IABノード300へのデータ送信成功と判断しているため、PDCPレイヤにおける再送が行われない虞がある。
【0123】
このような「hop-by-hop」における問題を解決するために、本実施形態に係るIABノード300は次のような動作を行う。図11に示すように、IABノード300は、第1の通信装置から上りリンクデータを受信する受信側RLCエンティティ22Rと、受信側RLCエンティティ22Rが受信した上りリンクデータを第2の通信装置に送信する送信側RLCエンティティ22Tとを有する。図11の例において第1の通信装置がUE100であるが、第1の通信装置は、UE100と当該IABノード300との間に介在する他のIABノードであってもよい。また、図11の例において第2の通信装置がgNB200であるが、第2の通信装置は、gNB200と当該IABノード300との間に介在する他のIABノードであってもよい。
【0124】
送信側RLCエンティティ22Tは、送信された上りリンクデータを第2の通信装置が受信成功したことを示す第1の肯定応答(Ack)を第2の通信装置から受信する。受信側RLCエンティティ22Rは、送信側RLCエンティティ22Tが第1の肯定応答(Ack)を受信したことに応じて、当該上りリンクデータを受信側RLCエンティティ22Rが受信成功したことを示す第2の肯定応答(Ack)を第1の通信装置に送信する。すなわち、受信側RLCエンティティ22Rは、送信側RLCエンティティ22Tが第1の肯定応答(Ack)を受信するまでは、第2の肯定応答(Ack)を第1の通信装置に送信しない。
【0125】
このように、IABノード300において、受信側RLCエンティティ22Rは、送信側RLCエンティティ22Tが上りリンクデータの送信成功を確認するまで、当該上りリンクデータに対応するAckを第1の通信装置に送信しない。これにより、第1の通信装置は、受信側RLCエンティティ22Rから当該上りリンクデータに対応するAckを受信するまで、当該上りリンクデータを保持するため、上述したような「hop-by-hop」における問題を解決できる。
【0126】
IABノード300は、受信側RLCエンティティ22R及び送信側RLCエンティティ22Tよりも上位のレイヤに位置付けられるアダプテーションレイヤ(Adapt.)のエンティティ23を有してもよい。以下において、アダプテーションレイヤのエンティティを「アダプテーションエンティティ」と称する。アダプテーションエンティティ23は、複数の受信側RLCエンティティ22Rと複数の送信側RLCエンティティ22Tとが存在する場合に、受信側RLCエンティティ22Rと送信側RLCエンティティ22Tとの対応付けを示すマッピング情報を管理する。アダプテーションエンティティ23は、論理チャネル(LCH)ごとにマッピング情報を管理してもよいし、UE100の識別子(例えば、C-RNTI(Cell-Radio Network Temporary Identifier)等)ごとにマッピング情報を管理してもよい。
【0127】
アダプテーションエンティティ23は、第1の肯定応答(Ack)に関する情報を送信側RLCエンティティ22Tから取得し、該取得された情報を受信側RLCエンティティ22Rに提供する。受信側RLCエンティティ22Rは、アダプテーションエンティティ23から提供される情報に基づいて、送信側RLCエンティティ22Tが第1の肯定応答(Ack)を受信したことを確認する。
【0128】
例えば、送信側RLCエンティティ22Tは、第2の通信装置の受信側RLCエンティティ32からの送達情報としてSTATUS PDU(Ack/Nack)をアダプテーションエンティティ23に通知する。或いは、送信側RLCエンティティ22Tは、当該STATUS PDUに基づくAck/Nack情報を送達情報としてアダプテーションエンティティ23に通知してもよい。Ack/Nack情報は、送達に成功したシーケンス番号(SN)を含んでもよいし、送達に失敗したシーケンス番号(SN)を含んでもよい。アダプテーションエンティティ23は、送信側RLCエンティティ22Tからの送達情報を、対応する受信側RLCエンティティ22Rに転送する。受信側RLCエンティティ22Rは、アダプテーションエンティティ23から転送された送達情報を取得し、RLC PDU(AMD PDU)の送信成功が確認できた場合に、当該RLC PDU(AMD PDU)についてAckを送信可能な状態になったと判断する。 本実施形態では、IABノード300が、独立したアダプテーションエンティティ23を有する一例を想定しているが、IABノード300が、独立したアダプテーションエンティティ23を有していなくてもよい。アダプテーションエンティティ23の機能は、他のレイヤ(例えば、RLC、MAC)のエンティティに統合されてもよい。このような場合、受信側RLCエンティティ22Rと送信側RLCエンティティ22Tとの間で直接的に送達情報の受け渡しを行ってもよいし、RRCエンティティ経由で送達情報の受け渡しを行ってもよい。
【0129】
本実施形態において、受信側RLCエンティティ22Rは、第1の通信装置からの上りリンクデータを受信してから、送信側RLCエンティティ22Tが第1の肯定応答(Ack)を受信するまで(又は受信側RLCエンティティ22Rが、送信側RLCエンティティ22Tから送達情報を取得するまで若しくはRLC PDU(AMD PDU)についてAckを送信可能な状態になったと判断するまで)の待ち時間を計時してもよい。受信側RLCエンティティ22Rは、当該待ち時間が一定時間を超える場合に、受信側RLCエンティティ22Rが上りリンクデータの受信に失敗したことを示す否定応答(Nack)を第1の通信装置に送信してもよい。かかる否定応答(Nack)に応じて第1の通信装置から再送された上りリンクデータを受信側RLCエンティティ22Rが受信した場合、送信側RLCエンティティ22Tは、受信された上りリンクデータによって第2の通信装置に対する再送を試みてもよい。或いは、受信側RLCエンティティ22Rは、当該待ち時間が一定時間を超える場合に、PDCP Data RecoveryをトリガすることをUE100のPDCPエンティティ13に要求するためのメッセージを送信してもよい。かかるメッセージは、受信側RLCエンティティ22Rから上位レイヤ(例えば、アダプテーションエンティティ23又はRRCエンティティ)に通知され、当該上位レイヤからUE100に対して送信されてもよい。
【0130】
例えば、受信側RLCエンティティ22Rは、第1の通信装置から上りリンクデータ(RLC PDU)を受信した時に、タイマを起動する。タイマには一定時間が設定され、この一定時間が経過(すなわち、タイマが満了)すると、受信側RLCエンティティ22Rは、否定応答(Nack)を第1の通信装置に送信する。受信側RLCエンティティ22Rは、タイマが動作中(すなわち、タイマが満了する前)に、送信側RLCエンティティ22Tが第1の肯定応答(Ack)を第2の通信装置から受信すると(又は受信側RLCエンティティ22Rが、送信側RLCエンティティ22Tから送達情報を取得する若しくはRLC PDU(AMD PDU)についてAckを送信可能な状態になったと判断すると)、タイマを停止させる。なお、タイマに設定される一定時間は、gNB200から例えばRRCシグナリングにより指定されてもよいし、予めIABノード300に記憶されたものでもよい。また、タイマに設定される一定時間は、他のIABノード300から転送されたものであってもよい。受信側RLCエンティティ22Rは、gNB200からの設定に応じて、タイマ満了時の動作を変更してもよい。例えば、受信側RLCエンティティ22Rは、タイマ満了時に第2の肯定応答(Ack)を第1の通信装置に送信するよう設定されてもよい。 本実施形態において、UE100(第1の通信装置)の送信側RLCエンティティ12は、Ackの待ち時間が長くなっても送信失敗と判断しないように、Ackの最大待ち時間(又はSTATUS PDUの最大待ち時間)を規定するタイマを通常よりも長く設定することが好ましい。例えば、gNB200は、RRCシグナリングにより、通常よりも長いタイマ値をUE100(第1の通信装置)の送信側RLCエンティティ12に設定してもよい。UE100の送信側RLCエンティティ12は、当該タイマが動作中は、STATUS PDUの送信をIABノード300の受信側RLCエンティティ22Rに要求しないようにする。
【0131】
図12は、本実施形態に係る動作例を示すシーケンス図である。
【0132】
ここでは、図1に示すUE100-3とgNB200-1との間で上りリンクのデータ転送を行う場合を想定する。本動作例において、第2の通信装置は、IABノード300-2とgNB200-1(ドナーgNB)との間の通信に介在するIABノード300-1である。
【0133】
図12に示すように、ステップS11において、UE100-3の送信側RLCエンティティ12は、PDCPエンティティ13からのPDCP PDUをRLC SDU(Service Data Unit)として受け取り、RLC SDUからRLC PDUを生成し、生成したRLC PDUを、MACエンティティ11を介してIABノード300-2に送信する。IABノード300-2の受信側RLCエンティティ22Rは、MACエンティティ21Rを介してRLC PDUを受信する。
【0134】
ステップS12において、IABノード300-2の受信側RLCエンティティ22Rは、RLC PDUの受信に応じてタイマを起動することにより、IABノード300-2の送信側RLCエンティティ22TがAckを受信するまでの待ち時間を計時する。なお、タイマは、RLC PDUごとに設けられてもよいし、複数のRLC PDUからなるグループごとに設けられてもよい。つまり、タイマが複数のRLC PDUからなるグループごとに設けられている場合、IABノード300-2の受信側RLCエンティティ22Rは、当該複数のRLC PDUを受信した場合に、タイマを起動してもよい。その場合、IABノード300-2の受信側RLCエンティティ22Rは、後述するステップS21において、当該複数のRLC PDUに対応するAckを送信側RLCエンティティ22Tが受信した場合に応じて、後述するステップS24において、UE100-3に対してAckを送信してもよい。
【0135】
ステップS13において、IABノード300-2の受信側RLCエンティティ22Rは、IABノード300-2のアダプテーションエンティティ23を介してIABノード300-2の送信側RLCエンティティ22TにRLC SDUを提供する。
【0136】
ステップS14において、IABノード300-2の送信側RLCエンティティ22Tは、アダプテーションエンティティ23から受け取ったRLC SDUからRLC PDUを生成し、生成したRLC PDUを、MACエンティティ21を介してIABノード300-1に送信する。IABノード300-1の受信側RLCエンティティ22Rは、MACエンティティ21Rを介してRLC PDUを受信する。
【0137】
ステップS15において、IABノード300-1の受信側RLCエンティティ22Rは、RLC PDUの受信に応じてタイマを起動することにより、IABノード300-1の送信側RLCエンティティ22TがAckを受信するまでの待ち時間を計時する。
【0138】
ステップS16において、IABノード300-1の受信側RLCエンティティ22Rは、IABノード300-1のアダプテーションエンティティ23を介してIABノード300-1の送信側RLCエンティティ22TにRLC SDUを提供する。
【0139】
ステップS17において、IABノード300-1の送信側RLCエンティティ22Tは、アダプテーションエンティティ23から受け取ったRLC SDUからRLC PDUを生成し、生成したRLC PDUを、MACエンティティ21を介してgNB200-1に送信する。gNB200-1の受信側RLCエンティティ32は、MACエンティティ31を介してRLC PDUを受信する。gNB200-1の受信側RLCエンティティ32は、受信したRLC PDUに対応するRLC SDUを、アダプテーションエンティティ33を介してPDCPエンティティ34に提供する。
【0140】
ステップS18において、gNB200-1の受信側RLCエンティティ32は、ステップS17で受信したRLC PDUに対応するAckを含むSTATUS PDUを、MACエンティティ31を介してIABノード300-1に送信する。このSTATUS PDUには、他のRLC PDUに対応するAck/Nackも含まれていてもよい。IABノード300-1の送信側RLCエンティティ22Tは、MACエンティティ21Tを介してSTATUS PDUを受信する。
【0141】
ステップS19において、IABノード300-1の送信側RLCエンティティ22Tは、受信したSTATUS PDU又はそれに基づく送達情報を、IABノード300-1のアダプテーションエンティティ23を介してIABノード300-1の受信側RLCエンティティ22Rに提供する。
【0142】
ステップS20において、IABノード300-1の受信側RLCエンティティ22Rは、送達情報に基づいて、ステップS14で受信したRLC PDUに対応するAckをIABノード300-1の送信側RLCエンティティ22Tが受信したことを確認する。
【0143】
ステップS21において、IABノード300-1の受信側RLCエンティティ22Rは、ステップS14で受信したRLC PDUに対応するAckを含むSTATUS PDUを、MACエンティティ21Rを介してIABノード300-2に送信する。IABノード300-2の送信側RLCエンティティ22Tは、MACエンティティ21Tを介してSTATUS PDUを受信する。
【0144】
ステップS22において、IABノード300-2の送信側RLCエンティティ22Tは、受信したSTATUS PDUに基づく送達情報を、IABノード300-2のアダプテーションエンティティ23を介してIABノード300-2の受信側RLCエンティティ22Rに提供する。
【0145】
ステップS23において、IABノード300-2の受信側RLCエンティティ22Rは、送達情報に基づいて、ステップS11で受信したRLC PDUに対応するAckをIABノード300-2の送信側RLCエンティティ22Tが受信したことを確認する。
【0146】
ステップS24において、IABノード300-2の受信側RLCエンティティ22Rは、ステップS11で受信したRLC PDUに対応するAckを含むSTATUS PDUを、MACエンティティ21Rを介してUE100-3に送信する。UE100-3の送信側RLCエンティティ12は、MACエンティティ11を介してSTATUS PDUを受信し、ステップS11で送信したRLC PDUの送信成功を確認し、その旨をPDCPエンティティ13に通知する。
【0147】
また、上述の実施形態では、gNB200-1や各IABノードがRLC PDUを正常に受信し、Ackを含むSTATUS PDUを送信する事例を主に説明したが、RLC PDUを正常に受信しなかった場合を以下に説明する。
【0148】
gNB200-1又は各IABノード300-1の受信側RLCエンティティは、Nackを含むSTATUS PDUを各IABノード300-1(300-2)の送信側RLCエンティティに送信する。その場合、各IABノード300-1(300-2)の送信側RLCエンティティ22Tは、当該STATUS PDUを受信したことに応じて、RLC PDUを再送する。その後、各IABノード300-1(300-2)の送信側RLCエンティティ22Tは、Ackを含むSTATUS PDUを受信した場合、上述の実施形態と同様に、受信したSTATUS PDUに基づく送達情報を、各IABノード300-1(300-2)のアダプテーションエンティティ23を介してIABノード300-1(300-2)の受信側RLCエンティティ22Rに提供する。
【0149】
また、IABノード300-1(300-2)の送信側RLCエンティティ22Tは、RLC PDUの再送ができない場合、Nackを含むSTATUS PDUを所定回数受信した場合又はタイマが満了した場合、Nackを含むSTATUS PDUをIABノード300-2又はUE100-3に送信してもよい。
【0150】
なお、IABノード300-1(300-2)は、Nackを含むSTATUS PDUをIABノード300-2又はUE100-3に送信することに併せて、タイマを停止してもよい。
【0151】
図13は、本実施形態に係る他の動作例を示すシーケンス図である。ここでは、図12の動作例との相違点について説明する。
【0152】
図13に示すように、本動作例において、アダプテーションエンティティ23はRLCエンティティ22よりも下位のレイヤに位置付けられている。かかる構成において、アダプテーションエンティティ23は、例えば、QoS制御を行ったり、UE100からのUL受信とIABノードからのUL受信とを区別してひも付けを行ったり、MACへの指示を行ったりする。また、IABノード300-1及び300-2、並びにgNB200-1において、RLCエンティティ22がARQ機能(RLC ARQ)とデータ分割・結合機能(RLC Seg.)とに分けられている。
【0153】
図13に示すように、ステップS31において、UE100-3の送信側RLCエンティティ12は、PDCPエンティティ13からのPDCP PDUをRLC SDUとして受け取り、RLC SDUからRLC PDUを生成し、生成したRLC PDUを、MACエンティティ11を介してIABノード300-2に送信する。IABノード300-2の受信側RLCエンティティ22Rは、MACエンティティ21R及びアダプテーションエンティティ23Rを介してRLC PDUを受信する。
【0154】
ステップS32において、IABノード300-2の受信側RLCエンティティ22Rは、RLC PDUの受信に応じてタイマを起動することにより、IABノード300-2の送信側RLCエンティティ(RLC ARQ)22TbがAckを受信するまでの待ち時間を計時する。
【0155】
ステップS33において、IABノード300-2の受信側RLCエンティティ22Rは、送信側RLCエンティティ(RLC ARQ)22TbにステップS32において受信した当該RLC PDUに対応するRLC SDUを中継(relay)する。
【0156】
ステップS34において、IABノード300-2の送信側RLCエンティティ(RLC ARQ)22Tbは、受信側RLCエンティティ22Rから受け取ったRLC SDUを、送信側RLCエンティティ(RLC Seg.)22Ta、アダプテーションエンティティ23T、及びMACエンティティ21Tを介してIABノード300-1に送信する。ここで、送信側RLCエンティティ(RLC Seg.)22Taは、RLC SDUに対してシーケンス番号の付与及び分割(セグメンテーション)を行う。IABノード300-1の受信側RLCエンティティ(RLC Seg.)22Raは、MACエンティティ21R及びアダプテーションエンティティ23Rを介してRLC PDUを受信し、RLC PDUを送信側RLCエンティティ(RLC Seg.)22Taに中継する。IABノード300-1の送信側RLCエンティティ(RLC Seg.)22Taは、中継されたRLC SDU(PDCP PDU)を分割して、アダプテーションエンティティ23T及びMACエンティティ21Tを介してgNB200-1に送信する。なお、ARQの視点では、IABノード300-1は透過的である。gNB200-1の受信側RLCエンティティ(RLC ARQ)32bは、MACエンティティ31、アダプテーションエンティティ33、及び受信側RLCエンティティ(RLC Seg.)32aを介してRLC PDUを受信する。gNB200-1の受信側RLCエンティティ(RLC ARQ)32bは、受信したRLC PDUに対応するRLC SDUをPDCPエンティティ34に提供する。
【0157】
ステップS35において、gNB200-1の受信側RLCエンティティ(RLC ARQ)32bは、ステップS34で受信したRLC PDUに対応するAckを含むSTATUS PDUを、受信側RLCエンティティ(RLC Seg.)32a、アダプテーションエンティティ33、及びMACエンティティ31を介してIABノード300-1に送信する。このSTATUS PDUには、他のRLC PDUに対応するNackも含まれていてもよい。STATUS PDUはIABノード300-1を介してIABノード300-2に伝達される。IABノード300-2の送信側RLCエンティティ(RLC ARQ)22Tbは、MACエンティティ21T、アダプテーションエンティティ23T、及び送信側RLCエンティティ(RLC Seg.)22Taを介してSTATUS PDUを受信する。
【0158】
ステップS36において、IABノード300-2の送信側RLCエンティティ(RLC ARQ)22Tbは、受信したSTATUS PDU又はそれに基づく送達情報を、IABノード300-2の受信側RLCエンティティ22Rに提供する。
【0159】
ステップS37において、IABノード300-2の受信側RLCエンティティ22Rは、送達情報に基づいて、ステップS31で受信したRLC PDUに対応するAckをIABノード300-2の送信側RLCエンティティ(RLC ARQ)22Tbが受信したことを確認する。
【0160】
ステップS38において、IABノード300-2の受信側RLCエンティティ22Rは、ステップS31で受信したRLC PDUに対応するAckを含むSTATUS PDUを、アダプテーションエンティティ23R及びMACエンティティ21Rを介してUE100-3に送信する。UE100-3の送信側RLCエンティティ12は、MACエンティティ11を介してSTATUS PDUを受信し、ステップS31で送信したRLC PDUの送信成功を確認し、その旨をPDCPエンティティ13に通知する。
【0161】
なお、図13の動作例において、gNB200-1は、例えばルーティングテーブルを参照し、UE100-3に対してアクセスリンクを提供しているIABノード300-2を特定し、IABノード300-2に対して、通常のACK/NACK(STATUS PDU)とは別のACK/NACKを送信してもよい。ここで、別のACK/NACKとは、複数の(バックホール)ベアラのACK/NACKをまとめて1つのメッセージで送信するものであってもよい。その場合、ベアラ(又はRLCチャネル)を特定するためのIDとACK/NACK情報とを紐づけて(リスト化して)送信してもよい。gNB200-1は、このような別のACK/NACKを、IABノード300-2からの要求に応じて送信してもよい。
【0162】
このように、本実施形態によれば、ARQを「hop-by-hop」で行う場合において、データ転送経路上でデータが消失しても、PDCPレイヤにおける再送を行うことが可能である。現状のPDCP動作と整合が取れているため、現状のPDCP動作に変更を加える必要がない。具体的には、UE100の動作変更を最小限にすることで、後方互換性を保つことができる。さらに、各IABノード300が中継先のACK受信状況を加味するだけでよいため、複雑性及び処理の増加を防ぐことができる。
【0163】
[第2実施形態の変更例]
第2実施形態の変更例について、上述した第2実施形態との相違点を主として説明する。本変更例は、上述した第2実施形態と併用して実施してもよいし、上述した第2実施形態とは別に実施してもよい。
【0164】
本変更例において上りリンクにおけるデータ転送について主として説明する。但し、上りリンクにおけるデータ転送に限定されるものではなく、下りリンクにおけるデータ転送であってもよい。
【0165】
本変更例に係るIABノード300は、第1の通信装置から第2の通信装置へデータを中継する場合に、当該データを保持する。第1の通信装置は、UE100であってもよいし、UE100と当該IABノード300との間に介在する他のIABノードであってもよい。第2の通信装置は、gNB200であってもよいし、gNB200と当該IABノード300との間に介在する他のIABノードであってもよい。IABノード300は、第2の通信装置との無線リンクにおける無線状態の悪化又はデータ転送経路の切り替えに応じて、保持しているデータを第3の通信装置に送信する。
【0166】
図14は、本変更例に係る構成例を示す図である。
【0167】
図14に示すように、IABノード300-2は、第1の通信装置からデータを受信する受信側RLCエンティティ22Rと、第2の通信装置と対応付けられた第1の送信側RLCエンティティ22Tと、第3の通信装置と対応付けられた第2の送信側RLCエンティティ22Tとを有する。図14の例において、第1の通信装置はUE100-3であり、第2の通信装置はIABノード300-1であり、第3の通信装置はIABノード300-4である。
【0168】
IABノード300-2は、受信側RLCエンティティ22Rが受信したデータを第1の送信側RLCエンティティ22Tに提供するとともに当該データを保持(バッファリング)するアダプテーションエンティティ23を有する。アダプテーションエンティティ23は、RLCエンティティ22よりも上位のレイヤに位置付けられている。
【0169】
IABノード300-2のアダプテーションエンティティ23は、当該IABノード300-2と第2の通信装置(IABノード300-1)との間の無線状態の悪化、又は第2の通信装置(IABノード300-1)から第3の通信装置(IABノード300-4)へのデータ転送経路の切り替えに応じて、保持しているデータを第2の送信側RLCエンティティ22Tに提供する。ここで、無線状態の悪化とは、第2の通信装置との間で無線リンク障害が発生したこと、第2の通信装置からの無線信号が途絶したこと、又は第2の通信装置からの無線信号の受信レベルが閾値を下回ったことであってもよい。また、データ転送経路の切り替えとは、ハンドオーバによるネットワークトポロジの変更であってもよい。
【0170】
例えば、アダプテーションエンティティ23は、1つの送信側RLCエンティティ22Tに受け渡し済みのPDCP PDU(RLC SDU)をバッファリングし、この送信側RLCエンティティ22Tに紐づいた無線リンクに障害が発生した場合に、当該バッファリングしているPDCP PDUを別の無線リンクに紐づいた送信側RLCエンティティ22Tに受け渡す。これにより、無線リンク障害が発生した場合でもデータが消失することを防止できる。
【0171】
具体的には、IABノード300-2のアダプテーションエンティティ23は、受信側RLCエンティティ22RからRLC SDUを取得し、当該RLC SDU(PDCP PDU)のコピーを作成し、一方のRLC SDU(PDCP PDU)を自身のバッファに保存した後、他方のRLC SDU(PDCP PDU)を第1の送信側RLCエンティティ22Tに受け渡す。そして、IABノード300-2のアダプテーションエンティティ23は、無線リンク異常が発生した場合に、当該保存してあるRLC SDU(PDCP PDU)をバッファから取り出し、無線リンク異常が発生していない第2の送信側RLCエンティティ22Tに受け渡す。ここで、無線リンク異常は、IABノード300-2のRRCから通知されてもよいし、gNB(ドナーgNB)200のRRCから通知されてもよい。若しくは、IABノード300-2の受信側RLCエンティティ22RからRLC SDUからそのコピーを第2の送信側RLCエンティティ22Tに受け渡してもよい。また、切替先の送信側RLCエンティティは、IABノード300-2のRRCから指定されてもよいし、gNB(ドナーgNB)200のRRCから指定されてもよい。
【0172】
IABノード300-2のアダプテーションエンティティ23は、RLC SDU(PDCP PDU)を保存する際にタイマを起動し、タイマが満了した際に当該RLC SDU(PDCP PDU)を破棄する。或いは、IABノード300-2のアダプテーションエンティティ23は、gNB(ドナーgNB)200のアダプテーションエンティティ又は他のIABノードのアダプテーションエンティティから送達確認情報(Ack/Nack)を取得し、保持しているRLC SDU(PDCP PDU)の送信が成功したと判断した場合に当該RLC SDU(PDCP PDU)を破棄してもよい。また、IABノード300-2のアダプテーションエンティティ23は、当該RLC SDU(PDCP PDU)を破棄する際に、当該タイマを停止してもよい。また、IABノード300-2のアダプテーションエンティティ23は、当該RLC SDU(PDCP PDU)を破棄する代わりに、PDCP Data Recoveryを利用した再送対象から除外してもよい。
【0173】
また、IABノード300-2のアダプテーションエンティティ23は、第2の送信側RLCエンティティ22Tが、STATUS PDU(Ack/Nack)又は送達確認情報(Ack/Nack)を他のIABノード300-4の受信側RLCエンティティ22Rから受信し、それらの情報を第2の送信側RLCエンティティ22Tから取得したことに応じて、当該RLC SDU(PDCP PDU)を破棄又はPDCP Data Recoveryを利用した再送対象から除外してもよい。
【0174】
なお、図12~14において、各装置(UE、IABノード、gNB)のPHYエンティティを省略しているが、実際、各装置は、それぞれPHYエンティティを有し、各PHYエンティティを介して互いに通信していてもよい。
【0175】
[その他の実施形態]
上述した実施形態において、移動通信システム1が5G移動通信システムである一例について主として説明した。しかしながら、移動通信システム1における基地局はeNBであってもよい。また、移動通信システム1におけるコアネットワークはEPC(Evolved Packet Core)であってもよい。さらに、gNBがEPCに接続することもでき、eNBが5GCに接続することもでき、gNBとeNBとが基地局間インターフェイス(Xnインターフェイス、X2インターフェイス)を介して接続されることもできる。
【0176】
なお、上述した実施形態に係る各処理をコンピュータに実行させるプログラムが提供されてもよい。また、プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、CD-ROMやDVD-ROM等の記録媒体であってもよい。UE100及びeNB200が行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップセットが提供されてもよい。
【0177】
なお、各図において示されるフローは、適宜組み合わされても良い。
【0178】
本願は、米国仮出願第62/715959号(2018年8月8日出願)の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
【0179】
[付記]
1. 序論
RAN2 AH1807は、end-to-endの信頼性、即ち、「end-to-end」及び「hop-by-hop」のRLC ARQメカニズムを比較することを広く議論し、TRに追加のテキストを取り込むことに合意した。
【0180】
「end-to-end」及び「hop-by-hop」のARQに対する所見
【0181】
【表1】
【0182】
(例:IABノード間の無線リンク障害)
現在の仕様では、IABトポロジの変更を追加の機能強化なしで実行した場合(下記の例)に、データの損失のない配信を保証できない。
【0183】
end-to-endのRLCフィードバックにより、データの損失のない配信が保証される。
【0184】
hop-by-hopのRLC ARQの場合におけるend-to-endの信頼性の課題は、例えば、以下のメカニズムを特定することによって対処することができる。
【0185】
-PDCPプロトコル/プロシージャの変更。この解決策は、Rel-15 UEには適用できないであろう、それはRel-15 UEの性能が損なわれる可能性があることを意味する。
【0186】
-経路更新(FFS IABノード間で交換される必要のある情報)に応じて中間IABノードにバッファされたPDCP PDUの再ルーティング。
【0187】
-ULステータス配信(ドナーgNBからIABノードに)を導入することにより、IABノードは、ドナーgNBでの受信の確認までUEへのRLC ACKの送信を遅らせることができる。
【0188】
この付記において、hop-by-hopのRLC ARQメカニズムの更なる考察が議論される。
【0189】
2. 議論
合意されたTPは、end-to-endの信頼性、即ち、「トポロジ変更中のULデータの損失のない配信」に関して、「hop-by-hop」のRLC ARQメカニズムにおける課題を特定し、それはまた3つの可能なアプローチを取り入れる。参考として、アプローチを以下に引用する。
【0190】
第1のアプローチ:「PDCPプロトコル/プロシージャの変更。この解決策は、Rel-15 UEには適用できないであろう、それはRel-15 UEの性能が損なわれる可能性があることを意味する。」
【0191】
第2のアプローチ:「経路更新に応じて中間IABノードにバッファされたPDCP PDUの再ルーティング(FFS IABノード間で交換される必要のある情報)。」
【0192】
第3のアプローチ:「ULステータス配信(ドナーgNBからIABノードに)を導入することにより、IABノードは、ドナーgNBでの受信の確認までUEへのRLC ACKの送信を遅らせることができる。」
【0193】
2.1. 信頼性のあるhop-by-hopのARQのための第1のアプローチ
第1のアプローチは、例えば、既に送信されたPDCP PDUを一定期間維持しながらDCPデータ回復を行うために、いくつかの「PDCPプロトコル/プロシージャの変更」を必要とする。しかしながら、それはTRで取り込まれているように、Rel-15 UEの性能を損なう。さらに、Rel-16 PDCPプロトコルを実装するUEを有する必要がある可能性がある、これは、TRに取り込まれている以下の要件を満たすことができないことを意味する。
【0194】
IAB設計は、IABノードに接続する以下のUEを少なくともサポートする。
【0195】
-Rel.15 NR UE
-IABがLTEアクセスのバックホールをサポートしている場合、レガシLTE UE
【0196】
この意味では、それはend-to-endの信頼性を保証するための解決策候補にはなり得ない。
【0197】
提案1:RAN2は、「Rel-15 UEの性能が損なわれる可能性がある」ことに加えて、「PDCPの変更」がRel?15 UEのための解決策ではないことに同意すべきである。
【0198】
2.2. 信頼性のあるhop-by-hopのARQのための第2のアプローチ
第2のアプローチは、「経路更新に応じて中間IABノードにバッファされたPDCP PDUの再ルーティング」のための新しい機能を導入することになり、それはRLCまたはアダプテーションレイヤのいずれかの中に実装されると仮定され得る。経路更新は、例えば、以下のような複数のシナリオを意味する可能性がある。
【0199】
-親への接続は失敗し、異なる親への別の接続として回復する(即ち、RRC再確立)。または、
-親への接続は、異なる親に変更されるように再設定される(即ち、ハンドオーバ)。または、
-異なる親への2つの接続のうちの1次接続が他方に切り替えられる(即ち、例えばデュアルコネクティビティによる冗長ルーティング)。
【0200】
上記のいくつかの場合において(例えば、ハンドオーバ時に)、RLCエンティティは再確立される必要があるかもしれず、更に全てのRLC SDUは破棄される。そのため、Rel-15 RLCの動作が変更されない限り、PDCP PDUをバッファリング/再ルーティングすることはできない。一方、「RLCより上の」タイプのアダプテーションレイヤは、RLC再確立中にPDCP PDUをバッファリングするのに適し、そしてアクティブMACリンクに関連する(他の)RLCエンティティにそれらを再ルーティングするのに適すると考えられる。
【0201】
提案2:RAN2は、PDCP PDUをバッファリング/再ルーティングする機能が、中間IABノードにおいて「RLCより上」に位置するアダプテーションレイヤによって処理されることに同意すべきである。
【0202】
これらの場合を考慮すると、「情報が交換される必要がある」ことは、それはRRCの再設定を含むことになるので、例えば、アーキテクチャグループ2に対して既に取り入れられた「IABノード間」に加えて、例えば、アーキテクチャグループ1のために、IABドナー及びIABノードの間にあると考えられる。加えて、経路更新のために、例えば、RLFのために、経路更新のためにIABノード間で情報を交換することは既に不可能であるかもしれない。従って、TRはIABノード内の情報交換のエンティティを制限すべきではないと考えられる。
【0203】
提案3:RAN2は、「PDCP PDUの再ルーティング」を契機とした情報交換のために「またはIABドナーとIABノード間の」というテキストを追加することに同意すべきである。
【0204】
第2のアプローチの利点は、たとえRLCチャネルのうちの1つが例えばRLFのために失敗したとしても、IABネットワークがそれ自体でパケット損失を回復することであろう。一方、結局のところ、それはend-to-endの信頼性のための完璧な解決策ではないかもしれない。例えば、適切なIABドナー/ノードが周囲にないために、再ルーティングのための中間IABノードが他の接続を得ることができず、最終的にPDCP PDUを失う場合、データの損失のない配信は保証されない。
【0205】
提案4:RAN2は、「PDCP PDUの再ルーティング」が最終的に損失のない配信を保証するのではなく、別の経路が見つかる限り中間RLCチャネルのパケット損失を改善/回復することに同意すべきである。
【0206】
2.3. 信頼性のあるhop-by-hopのARQのための第3のアプローチ
第3のアプローチ、即ち、「ULステータス配信(ドナーgNBからIABノードに)を導入すること」は興味深いが、これまでの寄書では何らかの関連される/可能な解決策が明らかにされているかどうか明白ではない。従って、研究段階でも、もう少し詳しく議論する価値がある。
【0207】
現時点で「ULステータス配信」が何であるかは明確にされていませんが、これの目的は、例えば、UEのPDCPレイヤにおけるPDCP PDUをバッファリングし、PDCPデータを回復することを可能にするために、「IABノードが、ドナーgNBでの受信の確認まで、RLC ACKのUEへの送信を遅らせることができる」ことを許可することである。そのため、IABノードのRLCレイヤに導入される可能性がある新しいメカニズムによるRel-15 PDCPへの影響は何ら予期されない。
【0208】
提案5:RAN2は、第3のアプローチの影響がIABネットワーク内で(即ち、IABドナーおよびIABノードにおいて)制限されるかどうかを議論するべきである。
【0209】
提案3に同意する場合、エッジのIABノードの観点から、IABドナーへのステータスUL配信を確認するために以下のような2つの選択肢がある。
【0210】
-選択肢1:UL配信ステータス報告は、IABドナーからエッジのIABノードに直接送られることにより、RLC ACKは、それ自身の受信ステータス及びUL配信ステータス報告の両方を考慮に入れる。
【0211】
-選択肢2:STATUS PDU(即ち、ACK)は、今日のようにピアPLCエンティティの間で送られることにより、RLC ACKは、それ自身だけでなく親ノードのRLCエンティティにおいて成功した受信を考慮に入れる。
【0212】
選択肢1は、TRで取り入れられた文の直接的な解釈であるが、各エッジのIABノードに各UL配信ステータス報告を送ることに関して、いくらかの複雑さが所見される。新しい報告は通常のRLC PDU(即ち、STATUS PDU)とは異なるので、バックホールリンクを介した追加のシグナリングオーバヘッドをもたらす可能性がある。
【0213】
選択肢2は、RLC ACKのバケツリレーゲームのような単純な代替であることにより、IABノードは、親ノードから関連付けられたRLC ACKを受信した後、既存のRLC ACKを送るだけである。利点は、追加のシグナリングを必要とせず、スケーラビリティを提供することである(即ち、ホップ数に制限がない)。欠点は、UEがIABノードからSTATUS PDUを受信するためにより長い時間待つ可能性があることだが、選択肢1よりも悪くない。
【0214】
まだ研究段階にあるので、両方の選択肢が有益であると認識される場合、両方の選択肢はTRに取り込まれるべきである。
【0215】
提案6:RAN2は、「ULステータス配信」の詳細をTRに取り込むことに同意すべきである。特に、IABノードはIABドナーからのUL配信ステータス報告(選択肢1)及びその親ノードからのRLC ACK(選択肢2)を考慮する。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16