図面を参照しながら、一実施形態に係る移動通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
[第1実施形態]
(移動通信システムの構成)
本実施形態に係る移動通信システムの構成について説明する。図1は、本実施形態に係る移動通信システム1の構成を示す図である。移動通信システム1は、3GPP規格に基づく第5世代(5G)移動通信システムである。具体的には、移動通信システム1における無線アクセス方式は、5Gの無線アクセス方式であるNR(New Radio)である。但し、移動通信システム1には、LTE(Long Term Evolution)が少なくとも部分的に適用されてもよい。
図1に示すように、移動通信システム1は、5Gコアネットワーク(5GC)10と、ユーザ機器(UE)100と、基地局(gNBと称される)200と、IABノード300とを備える。本実施形態において、基地局がNR基地局である一例について主として説明するが、基地局がLTE基地局(すなわち、eNB)であってもよい。
5GC10は、AMF(Access and Mobility Management Function)11及びUPF(User Plane Function)12を備える。AMF11は、UE100に対する各種モビリティ制御等を行う装置である。AMF11は、NAS(Non-Access Stratum)シグナリングを用いてUE100と通信することにより、UE100が在圏するエリアの情報を管理する。UPF12は、ユーザデータの転送制御等を行う装置である。
gNB200は、NGインターフェイスと称されるインターフェイスを介して、5GC10に接続される。図1において、5GC10に接続された3つのgNB200-1~gNB200-3を例示している。gNB200は、UE100との無線通信を行う固定の無線通信装置である。gNB200がドナー機能を有する場合、gNB200は、自身に無線で接続するIABノードとの無線通信を行ってもよい。
gNB200は、Xnインターフェイスと称される基地局間インターフェイスを介して、隣接関係にある他のgNB200と接続される。図1において、gNB200-1がgNB200-2及びgNB200-2に接続される一例を示している。
各gNB200は、1又は複数のセルを管理する。セルは、無線通信エリアの最小単位を示す用語として用いられる。セルは、UE100との無線通信を行う機能又はリソースを示す用語として用いられることがある。1つのセルは1つのキャリア周波数に属する。
UE100は、gNB200との無線通信を行う移動可能な無線通信装置である。UE100は、IABノード300との無線通信を行ってもよい。UE100は、gNB200又はIABノード300との無線通信を行う装置であればどのような装置であってもよい。例えば、UE100は、携帯電話端末、タブレット端末、ノートPC、センサ若しくはセンサに設けられる装置、又は車両若しくは車両に設けられる装置である。
図1において、UE100-1がgNB200-1に無線で接続され、UE100-2がIABノード300-1に無線で接続され、UE100-3がIABノード300-2に無線で接続される一例を示している。UE100-1は、gNB200-1との通信を直接的に行う。UE100-2は、IABノード300-1を介してgNB200-1との通信を間接的に行う。UE100-3は、IABノード300-1及びIABノード300-2を介してgNB200-1との通信を間接的に行う。
IABノード300は、eNB200とUE100との間の通信に介在し、この通信に対する中継を行う装置(中継装置)である。図1において、IABノード300-1がドナーであるgNB200-1に無線で接続され、IABノード300-2がIABノード300-1に無線で接続される一例を示している。各IABノード300は、セルを管理する。IABノード300が管理するセルのセルIDは、ドナーgNB200-1のセルのセルIDと同じであってもよいし、異なっていてもよい。
IABノード300は、UE機能(ユーザ機器機能)及びgNB機能(基地局機能)を有する。IABノード300は、UE機能を用いて上位ノード(gNB200又は上位のIABノード300)との無線通信を行うとともに、gNB機能を用いて下位ノード(UE100又は下位のIABノード300)との無線通信を行う。なお、UE機能とは、UE100が有する機能のうち少なくとも一部の機能を意味し、必ずしもUE100の全ての機能をIABノード300が有していなくてもよい。gNB機能とは、gNB200の機能のうち少なくとも一部の機能を意味し、必ずしもgNB200の全ての機能をIABノード300が有していなくてもよい。
UE100と、IABノード300又はgNB200との間の無線区間は、アクセスリンク(或いは、Uu)と称されることがある。IABノード300と、gNB200又は他のIABノード300との間の無線区間は、バックホールリンク(或いは、Un)と称されることがある。かかるバックホールリンクは、フロントホールリンクと称されてもよい。
アクセスリンクのデータ通信及びバックホールリンクのデータ通信をレイヤ2において統合及び多重化し、バックホールリンクのデータ通信に動的に無線リソースを割り当て、中継の経路を動的に切り替えることが可能である。なお、アクセスリンク及びバックホールリンクには、ミリ波帯が用いられてもよい。また、アクセスリンク及びバックホールリンクは、時分割及び/又は周波数分割により多重化されてもよい。
(gNBの構成)
本実施形態に係るgNB200の構成について説明する。図2は、gNB200の構成を示す図である。図2に示すように、gNB200は、無線通信部210と、ネットワーク通信部220と、制御部230とを備える。
無線通信部210は、UE100との無線通信及びIABノード300との無線通信に用いられる。無線通信部210は、受信部211及び送信部212を備える。受信部211は、制御部230の制御下で各種の受信を行う。受信部211はアンテナを含み、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部230に出力する。送信部212は、制御部230の制御下で各種の送信を行う。送信部212はアンテナを含み、制御部230が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
ネットワーク通信部220は、5GC10との有線通信(又は無線通信)及び隣接する他のgNB200との有線通信(又は無線通信)に用いられる。ネットワーク通信部220は、受信部221及び送信部222を備える。受信部221は、制御部230の制御下で各種の受信を行う。受信部221は、外部から信号を受信して受信信号を制御部230に出力する。送信部222は、制御部230の制御下で各種の送信を行う。送信部222は、制御部230が出力する送信信号を外部に送信する。
制御部230は、gNB200における各種の制御を行う。制御部230は、少なくとも1つのプロセッサ及び少なくとも1つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサとCPU(Central Processing Unit)とを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
(IABノードの構成)
本実施形態に係るIABノード300の構成について説明する。図3は、IABノード300の構成を示す図である。図3に示すように、IABノード300は、無線通信部310と、制御部320とを備える。
無線通信部310は、gNB200との無線通信(バックホールリンク)及びUE100との無線通信(アクセスリンク)に用いられる。無線通信部310は、受信部311及び送信部312を備える。受信部311は、制御部320の制御下で各種の受信を行う。受信部311はアンテナを含み、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部320に出力する。送信部312は、制御部320の制御下で各種の送信を行う。送信部312はアンテナを含み、制御部320が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
制御部320は、IABノード300における各種の制御を行う。制御部320は、少なくとも1つのプロセッサ及び少なくとも1つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びCPUを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
(UEの構成)
本実施形態に係るUE100の構成について説明する。図4は、UE100の構成を示す図である。図4に示すように、UE100は、無線通信部110と、制御部120とを備える。
無線通信部110は、アクセスリンクにおける無線通信、すなわち、gNB200との無線通信及びIABノード300との無線通信に用いられる。無線通信部110は、受信部111及び送信部112を備える。受信部111は、制御部120の制御下で各種の受信を行う。受信部111はアンテナを含み、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部120に出力する。送信部112は、制御部120の制御下で各種の送信を行う。送信部112はアンテナを含み、制御部120が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
制御部120は、UE100における各種の制御を行う。制御部120は、少なくとも1つのプロセッサ及び少なくとも1つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びCPUを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
(プロトコルスタック構成の一例)
本実施形態に係る移動通信システム1におけるプロトコルスタック構成の一例について説明する。図5は、ユーザプレーンのプロトコルスタック構成の一例を示す図である。ここでは、図1に示したUE100-3と5GC10のUPF12との間のユーザデータ伝送に関するプロトコルスタック構成の一例について説明する。
図5に示すように、UPF12は、GTP-U(GPRS Tunneling Protocol for User Plane)と、UDP(User Datagram Protocol)と、IP(Internet Protocol)と、レイヤ1/レイヤ2(L1/L2)とを備える。gNB200-1(ドナーgNB)には、これらに対応するプロトコルスタックが設けられる。
また、gNB200-1は、集約ユニット(CU:Central Unit)と分散ユニット(DU:Distributed Unit)とを備える。無線インターフェイスのプロトコルスタックのうちPDCP(Packet Data Convergence Protocol)以上の各レイヤをCUが有し、RLC(Radio Link Control)以下の各レイヤをDUが有し、F1インターフェイスと称されるインターフェイスを介してCU及びDUが接続される。
具体的には、CUは、SDAP(Service Data Adaptation Protocol)と、PDCPと、IPと、L1/L2とを備える。CUのSDAP及びPDCPは、DUと、IABノード300-1と、IABノード300-2とを介して、UE100のSDAP及びPDCPとの通信を行う。
また、DUは、無線インターフェイスのプロトコルスタックのうち、RLCと、アダプテーションレイヤ(Adapt)と、MAC(Medium Access Control)と、PHY(Physical layer)とを有する。これらのプロトコルスタックは、gNB向けのプロトコルスタックである。なお、アダプテーションレイヤ及びRLC(S-RLC)は上下関係が逆であってもよい。
IABノード300-1には、これらに対応するUE向けのプロトコルスタックST1が設けられる。さらに、IABノード300-1には、gNB向けのプロトコルスタックST2が設けられる。プロトコルスタックST1及びプロトコルスタックST2は、何れもレイヤ2以下の各レイヤ(各サブレイヤ)からなる。すなわち、IABノード300-1は、レイヤ2以下の各レイヤを用いてユーザデータの中継を行うレイヤ2中継装置である。IABノード300-1は、レイヤ3以上のレイヤ(具体的には、PDCP以上のレイヤ)を用いることなくデータ中継を行う。なお、IABノード300-2は、IABノード300-1と同様なプロトコルスタック構成を有する。
ここではユーザプレーンにおけるプロトコルスタック構成について説明した。しかしながら、制御プレーンにおいて、gNB200-1、IABノード300-1、IABノード300-2、及びUE100-3のそれぞれは、レイヤ3に相当するRRC(Radio Resource Control)を備える。
gNB200-1(ドナーgNB)のRRCとIABノード300-1のRRCとの間にRRC接続が確立され、このRRC接続を用いてRRCメッセージが送受信される。また、gNB200-1のRRCとIABノード300-2のRRCとの間にRRC接続が確立され、このRRC接続を用いてRRCメッセージが送受信される。さらに、gNB200-1のRRCとUE100-3のRRCとの間にRRC接続が確立され、このRRC接続を用いてRRCメッセージが送受信される。
(移動通信システムにおける動作)
本実施形態に係る移動通信システム1における動作について説明する。具体的には、IABノード300-1がgNB200-1(ドナーgNB)に無線で接続する場合の動作について説明する。
かかる場合、最初に、IABノード300-1は、UE機能を用いてgNB200-1とのアクセスリンク接続(第1の無線接続)を確立する。言い換えると、IABノード300-1は、UE100として振る舞ってgNB200-1とのアクセスリンク接続を確立する。アクセスリンク接続の確立は、RRC接続の確立を含む。
次に、gNB200-1は、アクセスリンク接続を維持しつつ、IABノード300-1のgNB機能のためのバックホールリンク接続(第2の無線接続)をIABノード300-1とgNB200-1との間に確立させるメッセージをIABノード300-1に送信する。本実施形態において、かかるメッセージは、RRC接続を用いて送受信されるRRC再設定(RRC Reconfiguration)メッセージである。
その結果、バックホールリンク接続がIABノード300-1とgNB200-1との間に確立されるため、IABノード300-1とgNB200-1との間でバックホールリンクの通信を適切に開始可能とすることができる。
バックホールリンク接続を確立させるRRC再設定メッセージは、バックホールリンク接続を構成するベアラ(又はL2リンク)の設定情報、及びIABノード300-1が送信するべきセルID(具体的には、セルIDに関連付けられた参照信号及び同期信号の送信設定)を含んでもよい。以下において、かかるRRC再設定メッセージをIABノード設定メッセージと称する。
IABノード設定メッセージは、デフォルトベアラ(又はデフォルトリンク)の設定情報を含んでもよい。デフォルトベアラ(又はデフォルトリンク)は、例えば、SIB(System Information Block)の中継やUEからのMsg3中継などを行うためのベアラ(又はリンク)である。
IABノード設定メッセージは、ドナーgNB200-1側のスタックの設定情報と、オプションでIABノード300-2(又はUE100)側のスタックの設定情報とを含んでもよい。IABノード300-2(又はUE100)側のスタックの設定情報は、暗示的にドナーgNB200-1のSIBで報知されている設定群を再利用してもよいし、オペレータ(OAM)から(事前に)設定されてもよい。
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設定が含まれてもよい。
また、IABノード設定メッセージにおける設定内容には、アダプテーションレイヤの設定(下位側又は上位側の論理チャネルのマッピング(ルーティング)設定、優先度設定等)が含まれてもよい。
さらに、IABノード設定メッセージにおける設定内容には、必要に応じて、IABノード300-1の(仮想的な)IPアドレス(すなわち、L3アドレス)を含めてもよい。これは、例えばF1インターフェイスをL2リンク上に確立するために、F1のプロトコルスタックがSCTP over IPを想定しているためである。
なお、IABノード設定メッセージにおける設定内容は、NRプロトコルの設定情報に限らず、LTEプロトコル(RLC、MAC、PHY)の設定情報であってもよい。
本実施形態において、IABノード300-1は、バックホールリンク接続を確立するよりも前に、IABノードの機能(すなわち、レイヤ2中継機能)を有すること又はバックホールリンク接続の確立を要求することを示すインディケーションをgNB200-1に送信してもよい。これにより、gNB200-1は、バックホールリンク接続を確立するためのプロシージャを適切に開始できる。以下において、かかるインディケーションをIABインディケーションと称する。IABインディケーションは、IABノード300-1におけるUE機能向けリンクプロトコルスタックをLTEで準備するのか、NRで準備するのか、もしくはその両方か、という意図又は能力を示す情報を含んでもよい。
なお、IABノード300-1は、gNB200-1とのアクセスリンク接続の確立後にIABインディケーションを送信してもよいし、gNB200-1とのアクセスリンク接続を確立するプロシージャ中にIABインディケーションを送信してもよい。
また、IABインディケーションをgNBに送信可能とする条件として、このgNBから、ドナー機能を有することを示すドナー機能識別子を含むSIBを受信しているという条件があってもよい。かかる場合、IABノード300-1は、gNB200-1からSIBによりドナー機能識別子を受信している場合に限り、gNB200-1に対してIABインディケーションを送信する。
本実施形態において、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がハンドオーバに係る処理を行ってもよい。
本実施形態において、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であると判断する。
そして、自身(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とのバックホールリンク接続を確立できる。
本実施形態において、gNB200-1は、バックホールリンク接続の確立後、IABノード300-1に関するコンテキスト情報を他のgNBに送信してもよい。このコンテキスト情報は、無線側のASレイヤの接続設定(RRC再設定の内容)、ネットワーク側のPDUセッションリソース設定(AMF又はRAN(Radio Access Network)のUE ID、セッションID、QoS(Quality of Service)/スライス設定等)、その他関連情報(IABノードの挙動や通信などの履歴情報、及び/又はプリファレンス情報などを含む。
具体的には、gNB200-1は、IABノード300-1を他のgNBにハンドオーバさせるという判断を行っていなくても、IABノード300-1に関するコンテキスト情報を予め他のgNBに送信する。これにより、gNB200-1とIABノード300-1との間の無線状態が悪化し、IABノード300-1が他のgNBとの無線接続を再確立する場合に、予め共有したコンテキスト情報を用いて速やかな再確立を行うことができる。
ここで、gNB200-1は、IABノード300-1とIABノード300-1のドナーgNBの候補とを対応付けるテーブルを保持していることが好ましい。gNB200-1は、テーブル中の候補である他のgNBに対してコンテキスト情報を送信する。これにより、gNB200-1は、コンテキスト情報を適切な他のgNBと共有できる。
(1)通常動作シーケンスの一例
図6は、本実施形態に係る移動通信システム1における通常動作シーケンスの一例を示す図である。
図6に示すように、ステップS101において、IABノード300-1は、例えばgNB200-1に対してランダムアクセスプロシージャを行うことにより、gNB200-1とのアクセスリンク接続(RRC接続)を確立する。IABノード300-1は、ランダムアクセスプロシージャ中にgNB200-1に送信するメッセージ(例えば、Msg3)にIABインディケーションを含めてもよい。また、gNB200-1は、ステップS101において、IABノード300-1に関するコンテキスト情報を取得する。
ステップ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との接続を再確立しなければならない場合などにおいて、アタッチ処理を省略する。
ステップS103において、IABノード300-1は、IABインディケーションをgNB200-1に送信する。IABノード300-1は、次のイベントのうち1又は複数が満たされたことをトリガとしてIABインディケーションを送信してもよい。
・Msg5(RRC Complete)を送信する際。
・gNBとの接続が確立した際(Msg5以降でもよい。例えば最初のRRC再設定が行われた際)。
・AMFからIAB設定情報(上記参照)を入手した際(既にIAB設定情報を持っている場合も含む)。
・単純にIABノードとして動作したくなった際(上位レイヤからIABノードとして動作する指示を受信したことを含む)。
・下位のIABノード300-2又はUE100-3からIABノードとなるように要求された場合(その旨の要求を示す信号を下位のIABノード300-2又はUE100-3から受信した場合)。
・下位のIABノード300-2又はUE100-3が既に接続している場合。
IABノード300-1は、例えばgNB200-1に送信するRRCメッセージにIABインディケーションを含める。かかるRRCメッセージは、UEとしての能力を示す「UE Capability Information」メッセージであってもよい。但し、ステップS101においてIABインディケーションを送信している場合、ステップS103は省略可能である。
或いは、IABインディケーションは、AMF11からPDUセッションリソースの変更という形でgNB200-1に通知されてもよい。なお、AMFは、IAB管理用(専用)のAMFであってもよい。
本通常動作シーケンスにおいては、gNB200-1がドナー能力を有すると仮定して説明を進める。gNB200-1は、IABインディケーションに基づいて、バックホールリンク接続をIABノード300-1に確立させる必要があると判断する。
ステップS104において、gNB200-1は、無線測定を設定する測定設定をIABノード300-1に送信する。IABノード300-1は、測定設定に基づいて無線測定を行う。例えば、IABノード300-1は、現在のサービングセルであるgNB200-1のセルと、隣接セルであるgNB200-2のセルとに対して受信電力(セル固有参照信号の受信電力)の測定を行う。
ステップS105において、IABノード300-1は、無線測定の結果を含む測定報告をgNB200-1に送信する。gNB200-1は、測定報告に基づいて、自身(gNB200-1)が適切なドナーgNBであるか又は他のgNBが適切なドナーgNBであるかを判断する。ここでは、gNB200-1が、自身(gNB200-1)が適切なドナーgNBであると判断したと仮定して説明を進める。なお、ステップS104及びステップS105の処理は必須ではなく、省略してもよい。
ステップ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側(のアクセスリンク用)のプロトコルスタックを準備して、同期信号やセル固有参照信号の送信を開始する処理(もしくは、開始する準備をする処理)を含んでもよい。
ステップS107において、IABノード300-1は、バックホールリンク接続の確立を含むIABノード設定が完了したことを示す完了通知メッセージをgNB200-1に送信する。ステップS107以降は、IABノード300-1はgNB200-1に対してUEとして振る舞うのではなく、IABノードとして振る舞う。
ステップ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の候補として設定される。なお、図7のテーブルは、gNBとの対応付けの例を示したが、セルIDとの対応付けであってもよい。セルIDは、物理レイヤセルIDでもよく、グローバルセルIDでもよい。なお、gNB200-1は、IABノード300-1から受信した測定報告に基づいて、IABノード300-1に地理的に近いgNB200-1をドナー候補として決定してもよい。gNB200-1は、当該決定したドナー候補に基づいて、IABノード300-1と当該IABノード300-1のドナーgNBの候補とを対応付けるテーブルを作成又は既存のテーブルを更新してもよい。
ステップS109において、gNB200-1は、IABノード300-1とのバックホールリンク接続を確立したことを示す通知を5GC10に送信する。もしくは、gNB200-1は、IABノード用のPDUセッションの確立要求を5GC10に送信してもよい。なお、上述したように、PDUセッションの確立要求は、ステップS109よりも先に又はステップS109においてAMF11からgNB200-1に送信されてもよい。
(2)例外動作シーケンスの一例
図8は、本実施形態に係る移動通信システム1における例外動作シーケンスの一例を示す図である。例外動作シーケンスにおいて、gNB200-1は、IABノード300-1をgNB200-2にハンドオーバさせる。
図8に示すように、ステップS201において、IABノード300-1は、例えばgNB200-1に対してランダムアクセスプロシージャを行うことにより、gNB200-1とのアクセスリンク接続(RRC接続)を確立する。IABノード300-1は、ランダムアクセスプロシージャ中にgNB200-1に送信するメッセージ(例えば、Msg3)にIABインディケーションを含めてもよい。また、gNB200-1は、ステップS201において、IABノード300-1に関するコンテキスト情報を取得する。
ステップS202において、IABノード300-1は、gNB200-1を介して、5GC10(具体的には、AMF11)に対するアタッチプロシージャを行う。
ステップS203において、IABノード300-1は、IABインディケーションをgNB200-1に送信する。IABノード300-1は、例えばgNB200-1に送信するRRCメッセージにIABインディケーションを含める。かかるRRCメッセージは、UEの能力を示す「UE Capability Information」メッセージであってもよい。但し、ステップS201においてIABインディケーションを送信している場合、ステップS203は省略可能である。
ステップS204において、gNB200-1は、自身がドナー能力を有するか否かを判断する。gNB200-1がドナー能力を有しない場合(ステップS204:NO)、gNB200-1は、処理をステップS208に進める。
gNB200-1がドナー能力を有する場合(ステップS204:YES)、ステップS205において、gNB200-1は、無線測定を設定する測定設定をIABノード300-1に送信する。IABノード300-1は、測定設定に基づいて無線測定を行う。例えば、IABノード300-1は、現在のサービングセルであるgNB200-1のセルと、隣接セルであるgNB200-2のセルとに対して受信電力(セル固有参照信号の受信電力)の測定を行う。
ステップS206において、IABノード300-1は、無線測定の結果を含む測定報告をgNB200-1に送信する。
ステップS207において、gNB200-1は、測定報告に基づいて、自身(gNB200-1)が適切なドナーgNBであるか又は他のgNBが適切なドナーgNBであるかを判断する。自身(gNB200-1)が適切なドナーgNBであると判断した場合(ステップS207:YES)、gNB200-1は、上述した通常動作シーケンス(図6参照)のステップS106に処理を進める。
一方、他のgNBが適切なドナーgNBであると判断した場合(ステップS207:NO)、gNB200-1は、ステップS208に処理を進める。
ステップ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に対してハンドオーバ要求メッセージを転送することができる。
gNB200-2は、ハンドオーバ要求メッセージに含まれるIABインディケーションも考慮して、IABノード300-1のハンドオーバを受け入れるか否かを判断する。gNB200-2は、自身がドナー能力を有しない場合には、ハンドオーバ要求を拒否してもよい。ここではgNB200-2がIABノード300-1のハンドオーバを受け入れると判断したと仮定して説明を進める。
ステップS209において、gNB200-2は、ハンドオーバ肯定応答メッセージをXnインターフェイス上でgNB200-1に送信する。
ステップS210において、gNB200-1は、gNB200-2からのハンドオーバ肯定応答メッセージに基づいて、ハンドオーバ指示メッセージ(RRC再設定メッセージ)をIABノード300-1に送信する。ハンドオーバ指示メッセージは、ハンドオーバ先のgNB200-2(のセル)を指定する情報を含む。
ステップS211において、IABノード300-1は、gNB200からのハンドオーバ指示メッセージに基づいて、gNB200-2へのハンドオーバを行う。
(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)通常動作シーケンス」と重複する説明を省略する。
図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に関するコンテキスト情報を取得する。
ステップ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との接続を再確立しなければならない場合などにおいて、アタッチ処理を省略する。
ステップS303において、IABノード300-2は、IABノード300-1を介してIABインディケーションをgNB200-1に送信する。IABノード300-2は、上述した「(1)通常動作シーケンス」のステップS103において説明したトリガと同様なトリガに応じてIABインディケーションを送信してもよい。
IABノード300-2は、例えばgNB200-1に送信するRRCメッセージにIABインディケーションを含める。かかるRRCメッセージは、UEとしての能力を示す「UE Capability Information」メッセージであってもよい。但し、ステップS301においてIABインディケーションを送信している場合、ステップS303は省略可能である。
或いは、IABインディケーションは、AMF11からPDUセッションリソースの変更という形でgNB200-1に通知されてもよい。なお、AMFは、IAB管理用(専用)のAMFであってもよい。
本動作シーケンスにおいては、gNB200-1がドナー能力を有すると仮定している。そのため、gNB200-1は、IABインディケーションに基づいて、バックホールリンク接続をIABノード300-1とIABノード300-2との間に確立させる必要があると判断する。
ステップS304において、gNB200-1は、無線測定を設定する測定設定をIABノード300-2に送信する。IABノード300-2は、測定設定に基づいて無線測定を行う。
ステップS305において、IABノード300-2は、無線測定の結果を含む測定報告を、IABノード300-1を介してgNB200-1に送信する。gNB200-1は、測定報告に基づいて、自身(gNB200-1)が適切なドナーgNBであるか又は他のgNBが適切なドナーgNBであるかを判断する。ここでは、gNB200-1が、自身(gNB200-1)が適切なドナーgNBであると判断したと仮定して説明を進める。なお、ステップS304及びステップS305の処理は必須ではなく、省略してもよい。
ステップS306において、gNB200-1は、IABノード設定メッセージ(RRC再設定メッセージ)をIABノード300-2に送信する。IABノード300-2は、IABノード設定メッセージに基づいて、バックホールリンク接続をIABノード300-1と確立する処理を行う。かかる確立処理は、IABノード設定メッセージ中の設定情報に基づいて、バックホールリンク用のプロトコルスタック(アダプテーション/RLC/MAC/PHYエンティティ)を生成したり、パラメータ設定したりする処理を含む。かかる確立処理は、UE側(のアクセスリンク用)のプロトコルスタックを準備して、同期信号やセル固有参照信号の送信を開始する処理(もしくは、開始する準備をする処理)を含んでもよい。
ステップS307において、gNB200-1は、RRC再設定メッセージをIABノード300-1に送信する。かかるRRC再設定メッセージは、IABノード300-2の追加に伴ってIABノード300-1における設定を変更するためのメッセージである。かかるRRC再設定メッセージは、例えば、IABノード300-2の論理チャネルとIABノード300-1のバックホールリンクの論理チャネルとの対応付けを示すマッピング情報を含む。なお、ステップS307は、ステップS306の前であってもよいし、ステップS306と同時であってもよい。
ステップS308において、IABノード300-2は、IABノード300-1とのバックホールリンク接続の確立を含むIABノード設定が完了したことを示す完了通知メッセージをgNB200-1に送信する。ステップS308以降は、IABノード300-2はgNB200-1に対してUEとして振る舞うのではなく、IABノードとして振る舞う。
ステップS309において、IABノード300-1は、IABノード300-2とのバックホールリンク接続の確立に伴う設定変更が完了したことを示す完了通知メッセージをgNB200-1に送信する。なお、ステップS309は、ステップS308の前であってもよいし、ステップS308と同時であってもよい。
ステップS310において、gNB200-1は、ステップS301において取得したIABノード300-2のコンテキスト情報を、Xnインターフェイス上でgNB200-2に転送する。
ステップS311において、gNB200-1は、IABノード300-2のバックホールリンク接続を確立したことを示す通知を5GC10に送信する。もしくは、gNB200-1は、IABノード300-2用のPDUセッションの確立要求を5GC10に送信してもよい。なお、上述したように、PDUセッションの確立要求は、ステップS311よりも先に又はステップS311においてAMF11からgNB200-1に送信されてもよい。
[第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インディケーションを送信してもよい。
或いは、各gNB200は、自身がドナー能力を有することをSIBにより通知することに加えて、又は自身がドナー能力を有することをSIBにより通知することに代えて、自身がIABノード300を取り扱う能力を有することをSIBにより通知してもよい。例えば、各gNB200は、自身がIABノード300を他のgNB(ドナーgNB)にハンドオーバする機能を有することをSIBにより通知してもよい。
上述した第1実施形態において、IABノード300がランダムアクセスプロシージャ中にgNB200に送信するメッセージ(例えば、Msg3)にIABインディケーションを含める一例について説明した。ここで、Msg3は、例えばRRC Setup Requestメッセージである。また、IABノード300は、Msg3中のフィールド(情報要素)であるEstablishment CauseにIABインディケーションを含めてもよい。
或いは、IABノード300は、ランダムアクセスプロシージャ中にgNB200に送信するランダムアクセスプリアンブル(Msg1)を利用して、IABインディケーションを通知してもよい。例えば、IABインディケーション用のPRACH(Physical Random Access Channel)リソースがSIBにより通知される場合、IABノード300は、通知されたIABインディケーション用のPRACHリソースの中から選択したPRACHリソースを用いてランダムアクセスプリアンブルを送信することにより、IABインディケーションを通知してもよい。ここで、PRACHリソースとは、時間・周波数リソースであってもよいし、信号系列(プリアンブル系列)であってもよい。
或いは、IABノード300は、ランダムアクセスプロシージャ以外のタイミングでIABインディケーションを通知してもよい。例えば、IABノード300は、UE Assistance Informationメッセージ等のRRCメッセージにIABインディケーションを含めてもよい。
上述した第1実施形態において、gNB200が、無線測定を設定する測定設定をIABノード300又はUE100に送信し、無線測定の結果を含む測定報告を受信する。これにより、自身(gNB200)が適切なドナーgNBであるか又は他のgNBが適切なドナーgNBであるかを当該測定報告に基づいて判断する一例について説明した。しかしながら、gNB200は、このような初期接続時に測定結果を利用する場合に限らず、ネットワークトポロジの変更やデータ転送経路の変更に測定報告を利用してもよい。
[第2実施形態]
第2実施形態について、上述した第1実施形態との相違点を主として説明する。第2実施形態は、AM(Acknowledged Mode)のRLCレイヤにおける自動再送制御(ARQ:AutomaticRepeat reQuest)に着目した実施形態である。
UE100とgNB(ドナーgNB)200との間の通信にIABノード300が介在する場合、ARQを「end-to-end」で行う方法とARQを「hop-by-hop」で行う方法とがある。なお、本実施形態において上りリンクにおけるデータ転送について主として説明する。但し、上りリンクにおけるデータ転送に限定されるものではなく、下りリンクにおけるデータ転送であってもよい。
図10は、「end-to-end」の一例を示す図である。
図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の受信に応じて、保持している上りリンクデータを再送する。
一方、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の受信に成功するごとに返してもよい。
なお、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」の一種である。
このように、UE100とgNB200との間の通信にIABノード300が介在する場合であっても、ARQを「end-to-end」で行うことにより、データ転送経路上において消失したデータが再送により受信側に伝達されることを保証できる。
一方で、ARQを、「end-to-end」ではなく、「hop-by-hop」で行う場合、データ転送経路上でデータが消失すると、消失したデータを再送できないことがある。
図11は、「hop-by-hop」の一例を示す図である。
図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処理における再送対象から外す(破棄してもよい)。
次に、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レイヤにおける再送が行われない虞がある。
このような「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ノードであってもよい。
送信側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の通信装置に送信しない。
このように、IABノード300において、受信側RLCエンティティ22Rは、送信側RLCエンティティ22Tが上りリンクデータの送信成功を確認するまで、当該上りリンクデータに対応するAckを第1の通信装置に送信しない。これにより、第1の通信装置は、受信側RLCエンティティ22Rから当該上りリンクデータに対応するAckを受信するまで、当該上りリンクデータを保持するため、上述したような「hop-by-hop」における問題を解決できる。
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)等)ごとにマッピング情報を管理してもよい。
アダプテーションエンティティ23は、第1の肯定応答(Ack)に関する情報を送信側RLCエンティティ22Tから取得し、該取得された情報を受信側RLCエンティティ22Rに提供する。受信側RLCエンティティ22Rは、アダプテーションエンティティ23から提供される情報に基づいて、送信側RLCエンティティ22Tが第1の肯定応答(Ack)を受信したことを確認する。
例えば、送信側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エンティティ経由で送達情報の受け渡しを行ってもよい。
本実施形態において、受信側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に対して送信されてもよい。
例えば、受信側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に要求しないようにする。
図12は、本実施形態に係る動作例を示すシーケンス図である。
ここでは、図1に示すUE100-3とgNB200-1との間で上りリンクのデータ転送を行う場合を想定する。本動作例において、第2の通信装置は、IABノード300-2とgNB200-1(ドナーgNB)との間の通信に介在するIABノード300-1である。
図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を受信する。
ステップ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を送信してもよい。
ステップS13において、IABノード300-2の受信側RLCエンティティ22Rは、IABノード300-2のアダプテーションエンティティ23を介してIABノード300-2の送信側RLCエンティティ22TにRLC SDUを提供する。
ステップ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を受信する。
ステップS15において、IABノード300-1の受信側RLCエンティティ22Rは、RLC PDUの受信に応じてタイマを起動することにより、IABノード300-1の送信側RLCエンティティ22TがAckを受信するまでの待ち時間を計時する。
ステップS16において、IABノード300-1の受信側RLCエンティティ22Rは、IABノード300-1のアダプテーションエンティティ23を介してIABノード300-1の送信側RLCエンティティ22TにRLC SDUを提供する。
ステップ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に提供する。
ステップ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を受信する。
ステップS19において、IABノード300-1の送信側RLCエンティティ22Tは、受信したSTATUS PDU又はそれに基づく送達情報を、IABノード300-1のアダプテーションエンティティ23を介してIABノード300-1の受信側RLCエンティティ22Rに提供する。
ステップS20において、IABノード300-1の受信側RLCエンティティ22Rは、送達情報に基づいて、ステップS14で受信したRLC PDUに対応するAckをIABノード300-1の送信側RLCエンティティ22Tが受信したことを確認する。
ステップ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を受信する。
ステップS22において、IABノード300-2の送信側RLCエンティティ22Tは、受信したSTATUS PDUに基づく送達情報を、IABノード300-2のアダプテーションエンティティ23を介してIABノード300-2の受信側RLCエンティティ22Rに提供する。
ステップS23において、IABノード300-2の受信側RLCエンティティ22Rは、送達情報に基づいて、ステップS11で受信したRLC PDUに対応するAckをIABノード300-2の送信側RLCエンティティ22Tが受信したことを確認する。
ステップ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に通知する。
また、上述の実施形態では、gNB200-1や各IABノードがRLC PDUを正常に受信し、Ackを含むSTATUS PDUを送信する事例を主に説明したが、RLC PDUを正常に受信しなかった場合を以下に説明する。
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に提供する。
また、IABノード300-1(300-2)の送信側RLCエンティティ22Tは、RLC PDUの再送ができない場合、Nackを含むSTATUS PDUを所定回数受信した場合又はタイマが満了した場合、Nackを含むSTATUS PDUをIABノード300-2又はUE100-3に送信してもよい。
なお、IABノード300-1(300-2)は、Nackを含むSTATUS PDUをIABノード300-2又はUE100-3に送信することに併せて、タイマを停止してもよい。図13は、本実施形態に係る他の動作例を示すシーケンス図である。ここでは、図12の動作例との相違点について説明する。
図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.)とに分けられている。
図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を受信する。
ステップS32において、IABノード300-2の受信側RLCエンティティ22Rは、RLC PDUの受信に応じてタイマを起動することにより、IABノード300-2の送信側RLCエンティティ(RLC ARQ)22TbがAckを受信するまでの待ち時間を計時する。
ステップS33において、IABノード300-2の受信側RLCエンティティ22Rは、送信側RLCエンティティ(RLC ARQ)22TbにステップS32において受信した当該RLC PDUに対応するRLC SDUを中継(relay)する。
ステップ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に提供する。
ステップ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を受信する。
ステップS36において、IABノード300-2の送信側RLCエンティティ(RLC ARQ)22Tbは、受信したSTATUS PDU又はそれに基づく送達情報を、IABノード300-2の受信側RLCエンティティ22Rに提供する。
ステップS37において、IABノード300-2の受信側RLCエンティティ22Rは、送達情報に基づいて、ステップS31で受信したRLC PDUに対応するAckをIABノード300-2の送信側RLCエンティティ(RLC ARQ)22Tbが受信したことを確認する。
ステップ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に通知する。
なお、図13の動作例において、gNB200-1は、例えばルーティングテーブルを参照し、UE100-3に対してアクセスリンクを提供しているIABノード300-2を特定し、IABノード300-2に対して、通常のACK/NACK(STATUS PDU)とは別のACK/NACKを送信してもよい。ここで、別のACK/NACKとは、複数の(バックホール)ベアラのACK/NACKをまとめて1つのメッセージで送信するものであってもよい。その場合、gNB200-1は、ベアラ(又はRLCチャネル)を特定するためのIDとACK/NACK情報とを紐づけて(リスト化して)送信してもよい。gNB200-1は、このような別のACK/NACKを、IABノード300-2からの要求に応じて送信してもよい。
このように、本実施形態によれば、ARQを「hop-by-hop」で行う場合において、データ転送経路上でデータが消失しても、PDCPレイヤにおける再送を行うことが可能である。現状のPDCP動作と整合が取れているため、現状のPDCP動作に変更を加える必要がない。具体的には、UE100の動作変更を最小限にすることで、後方互換性を保つことができる。さらに、各IABノード300が中継先のACK受信状況を加味するだけでよいため、複雑性及び処理の増加を防ぐことができる。
[第2実施形態の変更例1]
第2実施形態の変更例1について、上述した第2実施形態との相違点を主として説明する。本変更例は、上述した第2実施形態と併用して実施してもよいし、上述した第2実施形態とは別に実施してもよい。
本変更例において上りリンクにおけるデータ転送について主として説明する。但し、上りリンクにおけるデータ転送に限定されるものではなく、下りリンクにおけるデータ転送であってもよい。
本変更例に係るIABノード300は、第1の通信装置から第2の通信装置へデータを中継する場合に、当該データを保持する。第1の通信装置は、UE100であってもよいし、UE100と当該IABノード300との間に介在する他のIABノードであってもよい。第2の通信装置は、gNB200であってもよいし、gNB200と当該IABノード300との間に介在する他のIABノードであってもよい。IABノード300は、第2の通信装置との無線リンクにおける無線状態の悪化又はデータ転送経路の切り替えに応じて、保持しているデータを第3の通信装置に送信する。
図14は、本変更例に係る構成例を示す図である。
図14に示すように、IABノード300-2は、第1の通信装置からデータを受信する受信側RLCエンティティ22Rと、第2の通信装置と対応付けられた第1の送信側RLCエンティティ22T1と、第3の通信装置と対応付けられた第2の送信側RLCエンティティ22T2とを有する。図14の例において、第1の通信装置はUE100-3であり、第2の通信装置はIABノード300-1であり、第3の通信装置はIABノード300-4である。
IABノード300-2は、受信側RLCエンティティ22Rが受信したデータを第1の送信側RLCエンティティ22T1に提供するとともに当該データを保持(バッファリング)するアダプテーションエンティティ23を有する。アダプテーションエンティティ23は、RLCエンティティ22よりも上位のレイヤに位置付けられている。
IABノード300-2のアダプテーションエンティティ23は、当該IABノード300-2と第2の通信装置(IABノード300-1)との間の無線状態の悪化、又は第2の通信装置(IABノード300-1)から第3の通信装置(IABノード300-4)へのデータ転送経路の切り替えに応じて、保持しているデータを第2の送信側RLCエンティティ22T2に提供する。ここで、無線状態の悪化とは、第2の通信装置との間で無線リンク障害が発生したこと、第2の通信装置からの無線信号が途絶したこと、又は第2の通信装置からの無線信号の受信レベルが閾値を下回ったことであってもよい。また、データ転送経路の切り替えとは、ハンドオーバによるネットワークトポロジの変更であってもよい。
例えば、アダプテーションエンティティ23は、1つの送信側RLCエンティティ22T1に受け渡し済みのPDCP PDU(RLC SDU)をバッファリングし、この送信側RLCエンティティ22T1に紐づいた無線リンクに障害が発生した場合に、当該バッファリングしているPDCP PDUを別の無線リンクに紐づいた送信側RLCエンティティ22T2に受け渡す。これにより、無線リンク障害が発生した場合でもデータが消失することを防止できる。
具体的には、IABノード300-2のアダプテーションエンティティ23は、受信側RLCエンティティ22RからRLC SDUを取得し、当該RLC SDU(PDCP PDU)のコピーを作成し、一方のRLC SDU(PDCP PDU)を自身のバッファに保存した後、他方のRLC SDU(PDCP PDU)を第1の送信側RLCエンティティ22T1に受け渡す。そして、IABノード300-2のアダプテーションエンティティ23は、無線リンク異常が発生した場合に、当該保存してあるRLC SDU(PDCP PDU)をバッファから取り出し、無線リンク異常が発生していない第2の送信側RLCエンティティ22T2に受け渡す。ここで、無線リンク異常は、IABノード300-2のRRCから通知されてもよいし、gNB(ドナーgNB)200のRRCから通知されてもよい。若しくは、IABノード300-2の受信側RLCエンティティ22RからRLC SDUからそのコピーを第2の送信側RLCエンティティ22T2に受け渡してもよい。また、切替先の送信側RLCエンティティは、IABノード300-2のRRCから指定されてもよいし、gNB(ドナーgNB)200のRRCから指定されてもよい。
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を利用した再送対象から除外してもよい。
また、IABノード300-2のアダプテーションエンティティ23は、第2の送信側RLCエンティティ22T2が、STATUS PDU(Ack/Nack)又は送達確認情報(Ack/Nack)を他のIABノード300-4の受信側RLCエンティティ22Rから受信し、それらの情報を第2の送信側RLCエンティティ22T2から取得したことに応じて、当該RLC SDU(PDCP PDU)を破棄又はPDCP Data Recoveryを利用した再送対象から除外してもよい。
なお、図12~14において、各装置(UE、IABノード、gNB)のPHYエンティティを省略しているが、実際、各装置は、それぞれPHYエンティティを有し、各PHYエンティティを介して互いに通信していてもよい。
[第2実施形態の変更例2]
第2実施形態の変更例2について、上述した第2実施形態及びその変更例1との相違点を主として説明する。本変更例は、上述した第2実施形態及びその変更例1と併用して実施してもよいし、上述した第2実施形態及びその変更例1とは別に実施してもよい。
図15は、第2実施形態の変更例2の想定シナリオを示す図である。
図15に示すように、ドナーgNB(IAB donor)200-1とUE100-3との間に、IABノード300-1(IAB node#1)及びIABノード300-2(IAB node#2)が介在している。IABノード300-1(IAB node#1)及びIABノード300-2(IAB node#2)のそれぞれは、UE100からドナーgNB200-1へ送信される上りリンクデータ(UL data)を中継する。
ドナーgNB200-1は、上りリンクデータの送達状況を示す送達情報(UL delivery status)を、IABノード300-1を介して、UE100が接続するIABノード300-2に送信する。IABノード300-2は、送達確認に基づいて、上りリンクデータをドナーgNB200-1が正しく受信したことを確認すると、上りリンクデータに対応するACK(RLC ACK)をUE100に送信する。
ここで、IABノード300-2は、IABノード300-1に対して上りリンクデータを送信する送信側RLCエンティティを有しており、この送信側RLCエンティティは順序制御及び重複制御を行うためにウィンドウ制御を行っている。
IABノード300-2の送信側RLCエンティティは、新規のRLC PDUの送信の度にシーケンス番号(SN)を付与し、SNを含むRLC PDUをIABノード300-1の受信側RLCエンティティに送信する。IABノード300-2の送信側RLCエンティティは、送信済みのRLC PDUをバッファに蓄積しており、受信側からのStatus report(ACK)により送達を確認した後に破棄する。
ここで、IABノード300-2の送信側RLCエンティティは、RLC送信ウィンドウを管理する。IABノード300-2の送信側RLCエンティティは、ACKが確認されていないRLC PDUを再送しつつ、順次RLC送信ウィンドウをスライドさせる。
IABノード300-2の送信側RLCエンティティは、ACKを確認できず、RLC送信ウィンドウを更新できない場合、新規のPDUを送信することができなくなり、スループットが低下する。このような現象は、Tx Window Stallingと呼ばれることがある。Tx Window Stallingを回避するためには、受信側からのStatus reportを適切な頻度で受信側からフィードバックする必要がある。
本変更例では、ドナーgNB200-1からIABノード300-2へ送達情報(UL delivery status)を送信するために、この送達情報のやり取りを上位エンティティが行うこととする。上位エンティティとは、RLCエンティティよりも上位のレイヤのエンティティをいう。例えば、上位のレイヤは、アダプテーションレイヤ(Adapt)であってもよいし、F1インターフェイスのためのエンティティであるF1-APであってもよい。IABノード300-2とドナーgNB200-1とが直接的なやり取りを行うためには、マルチホップのルーティング機能が必要であるところ、RLCは対面(一対)でのやり取りしかできないため、上位レイヤを利用することとしている。
ここで、IABノード300-2の上位レイヤが送達情報(UL delivery status)をやり取りし、且つ、IABノード300-2の送信側RLCエンティティがRLC送信ウィンドウを管理する場合、IABノード300-2において上位レイヤと送信側RLCエンティティとの間の適切な協調が必要である。
図16は、本変更例に係る動作を示す図である。図16に示すプロトコルスタックの構成は、図12に示すプロトコルスタックの構成と同様である。なお、図16において上位レイヤがアダプテーションレイヤ(アダプテーションエンティティ)である一例を示しているが、上位レイヤはF1-AP(F1-APエンティティ)であってもよい。
図16に示すように、ステップS51において、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を介してRLC PDUを受信する。
IABノード300-2の受信側RLCエンティティ22Rは、IABノード300-2のアダプテーションエンティティ23を介して、IABノード300-2の送信側RLCエンティティ22TにRLC SDUを提供する。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を受信する。
IABノード300-1は、IABノード300-2が行う動作と同様の動作を行い、RLC PDUをドナーgNB200-1に送信する。
ドナーgNB200-1は、MACエンティティ31、RLCエンティティ32、アダプテーションエンティティ33、及びPDCPエンティティの順に上りリンクデータを処理する。
ステップS52において、IABノード300-2の送信側RLCエンティティ22Tは、自身のRLC送信ウィンドウのstallingが発生しないように、アダプテーションエンティティ23に対して上りリンクデータデータの送達確認要求を行う。
具体的には、送信側RLCエンティティ22Tは、ACKが確認できていない最も古いシーケンス番号が、RLC送信ウィンドウに対応するシーケンス番号の範囲(下限値)に達する前に、アダプテーションエンティティ23に対して上りリンクデータデータの送達確認要求を行う。送信側RLCエンティティ22Tは、送達確認の対象となるシーケンス番号を送達確認要求に含めてもよい。このシーケンス番号は、送信側RLCエンティティ22Tが付与するRLCシーケンス番号であってもよいし、アダプテーションエンティティ23が付与するシーケンス番号(パケット識別番号)であってもよい。
ステップS53において、IABノード300-2のアダプテーションエンティティ23は、送信側RLCエンティティ22Tからの要求(ステップS52)に応じて、ドナーgNB200のアダプテーションエンティティ33に対して、上りリンクデータに対応する送達情報(UL status delivery)の送信を要求する送信要求(UL status request)を送信する。
IABノード300-2のアダプテーションエンティティ23は、送信要求(UL status request)に、送達確認の対象となるシーケンス番号を送達確認要求に含めてもよい。このシーケンス番号は、送信側RLCエンティティ22Tが付与するRLCシーケンス番号であってもよいし、アダプテーションエンティティ23が付与するシーケンス番号(パケット識別番号)であってもよい。
ステップS54において、ドナーgNB200-1のアダプテーションエンティティ33は、送信要求(UL status request)の受信に応じて、送達情報(UL status delivery)をIABノード300-2のアダプテーションエンティティ23に送信する。
ステップS55において、IABノード300-2のアダプテーションエンティティ23は、送達情報(UL status delivery)の受信に応じて、送信側RLCエンティティ22Tに対して上りリンクデータの送達確認応答を行う。当該応答には、送達確認したパケットのRLC SN、もしくはアダプテーションエンティティ23のSN(パケット識別番号)を含めてもよい。
IABノード300-2の送信側RLCエンティティ22Tは、アダプテーションエンティティ23からの応答に応じて、RLC送信ウィンドウをスライドさせる。
なお、UE100側へACKを伝達する方法としては、上述した第2実施形態と同様な方法を利用してもよい。
本変更例によれば、IABノード300-2の上位レイヤ(アダプテーションエンティティ23)が送達情報(UL status delivery)をドナーgNB200-1から受信し、この送達情報に関する情報をアダプテーションエンティティ23から送信側RLCエンティティ22Tに通知することにより、送信側RLCエンティティ22TにおけるTx Window Stallingの発生を抑制できる。
図16に示す動作例では、ドナーgNB200-1の送達情報(UL status delivery)をIABノード300-2が受信し、RLC送信ウィンドウをスライドさせる例を示したが、これに限らない。前記送達情報(UL status delivery)は、IABノード300-1のアダプテーションエンティティ23のルーティング機能を介して伝送される為、IABノード300-1においても解読が可能である。前記IABノード300-2の動作と同様に、IABノード300-1においてもRLC送信ウィンドウをスライドさせることが可能である。つまり、IABノード300-1のアダプテーションエンティティ23は、前記送達情報(UL status delivery)の送信先が自分自身でない場合においても情報を解読し、自身(IABノード300-1)のRLCエンティティ22Tに対して送達確認情報を提供する。これにより、RLCエンティティ22TはRLC送信ウィンドウをスライドすることが可能である。このような方法により、IABノード毎に別々の送達確認要求及び送達情報をやり取りする必要がなくなり、ネットワーク上のシグナリング負荷を低減することが可能である。
[第2実施形態の変更例3]
第2実施形態の変更例3について、上述した第2実施形態及びその変更例1、2との相違点を主として説明する。本変更例は、上述した第2実施形態及びその変更例1、2と併用して実施してもよいし、上述した第2実施形態及びその変更例1、2とは別に実施してもよい。
図17は、第2実施形態の変更例3の想定シナリオを示す図である。なお、第2実施形態の変更例3の想定シナリオは、上述した第2実施形態の図11及び図12と同様である。
図17に示すように、ドナーgNB(IAB donor)200-1とUE100-3との間に、IABノード300-1(IAB node#1)及びIABノード300-2(IAB node#2)が介在している。IABノード300-1(IAB node#1)及びIABノード300-2(IAB node#2)のそれぞれは、UE100からドナーgNB200-1へ送信される上りリンクデータ(UL data)を中継する。
ドナーgNB200-1がRLC ACKをIABノード300-1に送信し、IABノード300-1がRLC ACKをIABノード300-2に送信し、IABノード300-2がRLC ACKをUE100に送信する。このように、RLC ACKが上位から下位へ向けて順次伝送される場合、RLC ACKの遅延が大きくなる。その結果、下位装置(UE100及びIABノード300-2)の送信側RLCエンティティにおいてTx Window Stallingが発生する可能性がある。
そこで、本変更例では、このような遅延を考慮して、ドナーgNB200-1がRLC送信ウィンドウに関する設定を行う。
図18は、第2実施形態の変更例3に係る動作を示す図である。
図18に示すように、ステップS401において、ドナーgNB200は、UE100とドナーgNB200との間に介在するIABノード300の数を示すホップ数に基づいて、RLCウィンドウに関する設定パラメータを決定する。ここで、ドナーgNB200は、自身の配下の各IABノード300を管理しており、ホップ数を把握している。
RLCウィンドウに関する設定パラメータは、例えば、送信側RLCエンティティが管理するRLC送信ウィンドウの長さ、受信側RLCエンティティから送信側RLCエンティティへのRLC Status Report(STATUS PDU)の送信を禁止する時間を定めるタイマ(t-StatusProhibit)、送信側RLCエンティティから受信側RLCエンティティへRLC Status Report(STATUS PDU)の送信を要求するトリガとするデータ量又はPDU数の閾値(pollPDU、pollByte)のうち、少なくとも1つを含む。
ドナーgNB200は、ホップ数が多いほど、RLC送信ウィンドウを大きくするように決定してもよい。ドナーgNB200は、ホップ数が多いほど、t-StatusProhibitの値を小さくするように決定してもよい。ドナーgNB200は、ホップ数が多いほど、データ量又はPDU数の閾値を小さくするように決定してもよい。
ステップS402において、ドナーgNB200は、ステップS401で決定された設定パラメータをUE100及びIABノード300の少なくとも一方に設定する。具体的には、ドナーgNB200は、ステップS401で決定された設定パラメータを含む設定メッセージをUE100及びIABノード300の少なくとも一方に送信する。
本変更例によれば、ドナーgNB200は、ホップ数を考慮してRLCウィンドウに関する設定パラメータを決定することにより、送信側RLCエンティティにおけるTx Window Stallingの回避を抑制できる。
[第2実施形態の変更例4]
第2実施形態の変更例4について、上述した第2実施形態及びその変更例1乃至3との相違点を主として説明する。本変更例は、上述した第2実施形態及びその変更例1乃至3と併用して実施してもよいし、上述した第2実施形態及びその変更例1乃至3とは別に実施してもよい。
第2実施形態の変更例4の想定シナリオは、第2実施形態の変更例3と同様である(図17参照)。
本変更例は、IABノード300の送信側RLCエンティティが、ACK/NACKを示すRLC Status Report(STATUS PDU)の送信を要求するポーリングを上位装置に対して送信する動作に関する。なお、上位装置は、ドナーgNB200、又はドナーgNB200とIABノード300との間に介在する他のIABノードである。
図19は、第2実施形態の変更例4に係る動作を示す図である。ここでは、図17に示すIABノード300-2を例に挙げて説明する。
図19に示すように、ステップS501において、IABノード300-2は、自身の下位装置であるUE100のRLC送信ウィンドウの状態を推定する。例えば、IABノード300-2は、UE100のRLC送信ウィンドウ設定、UE100からのバッファ状態報告(BSR)、UE100に割り当てた上りリンクリソースの情報(UL grant)などに基づいて、UE100のRLC送信ウィンドウの状態を推定する。ここで、IABノード300-2は、自身の下位装置であるUE100のRLC設定をIABドナー(ドナーgNB200-1)から受信していてもよい。
特に、IABノード300-2は、UE100においてTx Window Stallingが発生したか否かを推定する。IABノード300-2は、UE100においてTx Window Stallingが発生する将来のタイミングを予測してもよい。
ステップS502において、IABノード300-2は、ステップS501で推定したRLC送信ウィンドウの状態に基づいて、ポーリングをIABノード300-1に送信する。例えば、IABノード300-2は、UE100においてTx Window Stallingが発生した又はTx Window Stallingが近いうちに発生すると推定した場合、ポーリングをIABノード300-1に送信する。
これにより、IABノード300-2は、IABノード300-1からRLC ACK/NACKを適切なタイミングで取得できるため、UE100からポーリングを受けた際に即座にRLC ACK/NACKをUE100に送信できる。
[第3実施形態]
第3実施形態について、上述した第1実施形態及び第2実施形態との相違点を主として説明する。本実施形態は、上述した第1実施形態及び第2実施形態と併用して実施してもよいし、上述した第1実施形態及び第2実施形態とは別に実施してもよい。
IABノード300の直下の下位装置は、IABノード300との無線リンク障害(RLF)を検知した場合、他のセルを再選択し、再選択したセルに対して接続の再確立を試みる。しかしながら、RLFは、基本的には下りリンクの受信状態に基づいて検知されるため、IABノード300は、下位装置がRLFを検知したことを把握できない可能性がある。
図20は、第3実施形態に係るIABノード300の動作を示す図である。
図20に示すように、ステップS601において、IABノード300は、自身の直下の下位装置から定期的に送信される上りリンク信号を受信する。下位装置とは、UE100、又はUE100とIABノード300との間に介在する他のIABノードをいう。上りリンク信号とは、定期的に送信可能な信号であればどのようなものであってもよいが、例えば、MAC CE(例えば、バッファ状態報告)、RRCメッセージ(例えば、測定報告メッセージ)、上りリンク参照信号を利用できる。
ステップS602において、IABノード300は、下位装置からの上りリンク信号の受信に応じて、タイマを開始させる。このタイマに設定されるタイマ値は、ドナーgNB200-1から設定された値であってもよい。タイマ値は、下位装置が上りリンク信号を送信する周期よりも長い時間であってもよい。
タイマを開始させた後、IABノード300は、下位装置から上りリンク信号を受信した場合(ステップS603:YES)、ステップS604において、タイマを停止させる。この場合、処理がステップS602に戻り、タイマを再開させる。
一方、下位装置から上りリンク信号を受信することなく(ステップS603:NO)、タイマが満了した場合(ステップS605:YES)、ステップS606において、IABノード300は、下位装置がRLFを検知したと判断する。IABノード300は、自身の下位装置がRLFを検知したと判断した場合、自身の上位装置に対して、この下位装置に対応する無線ベアラ(バックホールリンク)の解放を要求してもよい。
第3実施形態によれば、下位装置においてRLFが検知されたことをIABノード300が把握できる。
[第4実施形態]
第4実施形態について、上述した第1実施形態乃至第3実施形態との相違点を主として説明する。本実施形態は、上述した第1実施形態乃至第3実施形態と併用して実施してもよいし、上述した第1実施形態乃至第3実施形態とは別に実施してもよい。
図21は、第4実施形態に係る動作を示す図である。図21において、「DU」は基地局機能に相当し、「MT」はユーザ装置機能に相当する。
図21に示すように、UE100-3は、ステップS701乃至S705の手順により上りリンクデータ(PDU)をIABノード300-2に送信する。具体的には、UE100-3は、スケジューリング要求(SR)をIABノード300-2に送信し(ステップS701)、BSR送信用の上りリンク無線リソースの割り当てを受け(ステップS702)、BSRを送信し(ステップS703)、上りリンクデータ送信用の上りリンク無線リソースの割り当てを受け(ステップS704)、上りリンクデータをIABノード300-2に送信する(ステップS705)。
同様にして、IABノード300-2は、ステップS706乃至S710の手順により上りリンクデータ(PDU)をIABノード300-1に送信する。
また、IABノード300-1は、ステップS711乃至S715の手順により上りリンクデータ(PDU)をドナーgNB200-1に送信する。
本シーケンスにおいて、各IABノード300は、上りリンク無線リソースの割り当てを要求する第1スケジューリング要求を下位装置から受信する。そして、各IABノード300は、上りリンクデータ(PDU)を下位装置から受信するよりも前において、第2スケジューリング要求を上位装置に送信する。
一般的に、スケジューリング要求は、送信するべき上りリンクデータを有する場合にトリガされるが、本実施形態では、送信するべき上りリンクデータを未だ有していない段階でスケジューリング要求をトリガしている。これにより、円滑な上りリンク無線リソースの割り当てを実現できる。
例えば、ステップS706において、IABノード300-2は、UE100-3からBSRを受信(ステップS703)した際に、スケジューリング要求をIABノード300-1に送信する。
IABノード300-2は、UE100-3からスケジューリング要求を受信(ステップS701)した後、UE100-3からBSRを受信(ステップS703)する前に、スケジューリング要求をIABノード300-1に送信してもよい。
IABノード300-2は、UE100-3からスケジューリング要求を受信(ステップS701)した後、UE100-3に上りリンク無線リソースを割り当てた際(ステップS702)に、スケジューリング要求をIABノード300-1に送信(トリガ)してもよい。
IABノード300-2は、UE100-3からスケジューリング要求を受信した際(ステップS701)に、スケジューリング要求をIABノード300-1に送信(トリガ)してもよい。
本実施形態において、各IABノード300は、当該IABノード300が上りリンク送信に利用可能なデータの量を少なくとも示す第1のバッファ状態報告を上位装置に送信する。ここで、上位装置とは、ドナーgNB200の配下の他のIABノード(上位IABノード)又はドナーgNB200である。上位装置は、第1のバッファ状態報告に基づいて、上りリンク送信用の無線リソースをIABノード300に割り当てる。
IABノード300は、上りリンク送信待ちのデータを一時的に記憶する上りリンクバッファを有する。例えば、IABノード300のMACレイヤは、当該上りリンクバッファ内のデータ量を示す情報を含む第1のバッファ状態を上位装置のMACレイヤに通知する。上位装置のMACレイヤはスケジューラを有しており、第1のバッファ状態に基づいて上りリンク無線リソースをIABノード300に割り当て、制御チャネルを介して割当リソースをIABノード300に通知する。
ここで、IABノード300は、複数のUE分の上りリンクデータをバッファリングするため、UE100に比べて大容量の上りリンクバッファを有すると考えられる。よって、IABノード向けのバッファ状態報告は、UE向けのバッファ状態報告とは異なるフォーマットを有していてもよい。また、IABノード向けのバッファ状態報告が表現可能なデータ量(最大データ量)は、UE向けのバッファ状態報告が表現可能なデータ量(最大データ量)よりも大きくてもよい。
IABノード向けのバッファ状態報告は、IABノード300の配下のUE100の数に関する情報を含んでもよい。IABノード300は、自身の配下のUE100の数をUEコンテキストやC-RNTI等に基づいて判断してもよいし、自身の配下のUE100の数をドナーgNB200から通知されてもよい。IABノード300は、自身の配下のUE100のうち、自身の上りリンクバッファ内にデータがあるUE100の数をバッファ状態報告に含めてもよい。言い換えると、IABノード300は、自身がいくつのUE分の上りリンクデータを持っているかをバッファ状態報告により上位装置に通知してもよい。或いは、IABノード300は、自身の配下のUE100のうち、RRCコネクティッド状態にあるUE100の数をバッファ状態報告に含めてもよい。
IABノード向けのバッファ状態報告は、IABノード300の上りリンクバッファ内に実際に存在するデータの量だけではなく、下位装置からのバッファ状態報告(すなわち、潜在的な上りリンクデータ量)が加味されてもよい。これにより、上位装置は、潜在的な上りリンクデータ量を考慮して、上りリンク無線リソースを予めIABノード300に割り当てておくことができるため、マルチホップに起因する上りリンクの伝送遅延を抑制できる。
IABノード300は、下位装置から、下位装置が上りリンク送信に利用可能なデータの量を示す第2のバッファ状態報告を受信する。IABノード300は、第2のバッファ状態報告に基づいて、自身が上りリンク送信に利用可能なデータの量と下位装置が上りリンク送信に利用可能なデータの量とに基づく第1のバッファ状態報告を上位装置に送信する。例えば、IABノード300は、自身が上りリンク送信に利用可能なデータの量と下位装置が上りリンク送信に利用可能なデータの量との合計値を第1のバッファ状態報告に含めてもよい。或いは、IABノード300は、自身が上りリンク送信に利用可能なデータの量を示す第1のBSR値と、下位装置が上りリンク送信に利用可能なデータの量を示す第2のBSR値とを別々に第1のバッファ状態報告に含めてもよい。
なお、IABノード300が上りリンク送信に利用可能なデータ量とは、自身の送信バッファ(MTのバッファ)のデータ量、自身の受信バッファ(DU)のデータ量、アダプテーションエンティティのバッファ量を含んでもよい。
[その他の実施形態]
上述した実施形態において、移動通信システム1が5G移動通信システムである一例について主として説明した。しかしながら、移動通信システム1における基地局はeNBであってもよい。また、移動通信システム1におけるコアネットワークはEPC(Evolved Packet Core)であってもよい。さらに、gNBがEPCに接続することもでき、eNBが5GCに接続することもでき、gNBとeNBとが基地局間インターフェイス(Xnインターフェイス、X2インターフェイス)を介して接続されることもできる。
なお、上述した実施形態に係る各処理をコンピュータに実行させるプログラムが提供されてもよい。また、プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、CD-ROMやDVD-ROM等の記録媒体であってもよい。UE100及びeNB200が行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップセットが提供されてもよい。
なお、各図において示されるフローは、適宜組み合わされても良い。
[付記1]
1. 序論
RAN2 AH1807は、end-to-endの信頼性、即ち、「end-to-end」及び「hop-by-hop」のRLC ARQメカニズムを比較することを広く議論し、TRに追加のテキストを取り込むことに合意した。
「end-to-end」及び「hop-by-hop」のARQに対する所見
hop-by-hopのRLC ARQの場合におけるend-to-endの信頼性の課題は、例えば、以下のメカニズムを特定することによって対処することができる。
-PDCPプロトコル/プロシージャの変更。この解決策は、Rel-15 UEには適用できないであろう、それはRel-15 UEの性能が損なわれる可能性があることを意味する。
-経路更新(FFS IABノード間で交換される必要のある情報)に応じて中間IABノードにバッファされたPDCP PDUの再ルーティング。
-ULステータス配信(ドナーgNBからIABノードに)を導入することにより、IABノードは、ドナーgNBでの受信の確認までUEへのRLC ACKの送信を遅らせることができる。
この付記において、hop-by-hopのRLC ARQメカニズムの更なる考察が議論される。
2. 議論
合意されたTPは、end-to-endの信頼性、即ち、「トポロジ変更中のULデータの損失のない配信」に関して、「hop-by-hop」のRLC ARQメカニズムにおける課題を特定し、それはまた3つの可能なアプローチを取り入れる。参考として、アプローチを以下に引用する。
第1のアプローチ:「PDCPプロトコル/プロシージャの変更。この解決策は、Rel-15 UEには適用できないであろう、それはRel-15 UEの性能が損なわれる可能性があることを意味する。」
第2のアプローチ:「経路更新に応じて中間IABノードにバッファされたPDCP PDUの再ルーティング。(FFS IABノード間で交換される必要のある情報)」
第3のアプローチ:「ULステータス配信(ドナーgNBからIABノードに)を導入することにより、IABノードは、ドナーgNBでの受信の確認までUEへのRLC ACKの送信を遅らせることができる。」
2.1. 信頼性のあるhop-by-hopのARQのための第1のアプローチ
第1のアプローチは、例えば、既に送信されたPDCP PDUを一定期間維持しながらDCPデータ回復を行うために、いくつかの「PDCPプロトコル/プロシージャの変更」を必要とする。しかしながら、それはTRで取り込まれているように、Rel-15 UEの性能を損なう。さらに、Rel-16 PDCPプロトコルを実装するUEを有する必要がある可能性がある、これは、TRに取り込まれている以下の要件を満たすことができないことを意味する。
IAB設計は、IABノードに接続する以下のUEを少なくともサポートする。
-Rel.15 NR UE
-IABがLTEアクセスのバックホールをサポートしている場合、レガシLTE UE
この意味では、それはend-to-endの信頼性を保証するための解決策候補にはなり得ない。
提案1:RAN2は、「Rel-15 UEの性能が損なわれる可能性がある」ことに加えて、「PDCPの変更」がRel?15 UEのための解決策ではないことに同意すべきである。
2.2. 信頼性のあるhop-by-hopのARQのための第2のアプローチ
第2のアプローチは、「経路更新に応じて中間IABノードにバッファされたPDCP PDUの再ルーティング」のための新しい機能を導入することになり、それはRLC又はアダプテーションレイヤのいずれかの中に実装されると仮定され得る。経路更新は、例えば、以下のような複数のシナリオを意味する可能性がある。
-親への接続は失敗し、異なる親への別の接続として回復する(即ち、RRC再確立)。又は、
-親への接続は、異なる親に変更されるように再設定される(即ち、ハンドオーバ)。又は、
-異なる親への2つの接続のうちの1次接続が他方に切り替えられる(即ち、例えばデュアルコネクティビティによる冗長ルーティング)。
上記のいくつかの場合において(例えば、ハンドオーバ時に)、RLCエンティティは再確立される必要があるかもしれず、更に全てのRLC SDUは破棄される。そのため、Rel-15 RLCの動作が変更されない限り、PDCP PDUをバッファリング/再ルーティングすることはできない。一方、「RLCより上の」タイプのアダプテーションレイヤは、RLC再確立中にPDCP PDUをバッファリングするのに適し、そしてアクティブMACリンクに関連する(他の)RLCエンティティにそれらを再ルーティングするのに適すると考えられる。
提案2:RAN2は、PDCP PDUをバッファリング/再ルーティングする機能が、中間IABノードにおいて「RLCより上」に位置するアダプテーションレイヤによって処理されることに同意すべきである。
これらの場合を考慮すると、「情報が交換される必要がある」ことは、それはRRCの再設定を含むことになるので、例えば、アーキテクチャグループ2に対して既に取り入れられた「IABノード間」に加えて、例えば、アーキテクチャグループ1のために、IABドナー及びIABノードの間にあると考えられる。加えて、経路更新のために、例えば、RLFのために、経路更新のためにIABノード間で情報を交換することは既に不可能であるかもしれない。従って、TRはIABノード内の情報交換のエンティティを制限すべきではないと考えられる。
提案3:RAN2は、「PDCP PDUの再ルーティング」を契機とした情報交換のために「又はIABドナーとIABノード間の」というテキストを追加することに同意すべきである。
第2のアプローチの利点は、たとえRLCチャネルのうちの1つが例えばRLFのために失敗したとしても、IABネットワークがそれ自体でパケット損失を回復することであろう。一方、結局のところ、それはend-to-endの信頼性のための完璧な解決策ではないかもしれない。例えば、適切なIABドナー/ノードが周囲にないために、再ルーティングのための中間IABノードが他の接続を得ることができず、最終的にPDCP PDUを失う場合、データの損失のない配信は保証されない。
提案4:RAN2は、「PDCP PDUの再ルーティング」が最終的に損失のない配信を保証するのではなく、別の経路が見つかる限り中間RLCチャネルのパケット損失を改善/回復することに同意すべきである。
2.3. 信頼性のあるhop-by-hopのARQのための第3のアプローチ
第3のアプローチ、即ち、「ULステータス配信(ドナーgNBからIABノードに)を導入すること」は興味深いが、これまでの寄書では何らかの関連される/可能な解決策が明らかにされているかどうか明白ではない。従って、研究段階でも、もう少し詳しく議論する価値がある。
現時点で「ULステータス配信」が何であるかは明確にされていないが、これの目的は、例えば、UEのPDCPレイヤにおけるPDCP PDUをバッファリングし、PDCPデータを回復することを可能にするために、「IABノードが、ドナーgNBでの受信の確認まで、RLC ACKのUEへの送信を遅らせることができる」ことを許可することである。そのため、IABノードのRLCレイヤに導入される可能性がある新しいメカニズムによるRel-15 PDCPへの影響は何ら予期されない。
提案5:RAN2は、第3のアプローチの影響がIABネットワーク内で(即ち、IABドナー及びIABノードにおいて)制限されるかどうかを議論するべきである。
提案3に同意する場合、エッジのIABノードの観点から、IABドナーへのステータスUL配信を確認するために以下のような2つの選択肢がある。
-選択肢1:UL配信ステータス報告は、IABドナーからエッジのIABノードに直接送られることにより、RLC ACKは、それ自身の受信ステータス及びUL配信ステータス報告の両方を考慮に入れる。
-選択肢2:STATUS PDU(即ち、ACK)は、今日のようにピアPLCエンティティの間で送られることにより、RLC ACKは、それ自身だけでなく親ノードのRLCエンティティにおいて成功した受信を考慮に入れる。
選択肢1は、TRで取り入れられた文の直接的な解釈であるが、各エッジのIABノードに各UL配信ステータス報告を送ることに関して、いくらかの複雑さが所見される。新しい報告は通常のRLC PDU(即ち、STATUS PDU)とは異なるので、バックホールリンクを介した追加のシグナリングオーバヘッドをもたらす可能性がある。
選択肢2は、RLC ACKのバケツリレーゲームのような単純な代替であることにより、IABノードは、親ノードから関連付けられたRLC ACKを受信した後、既存のRLC ACKを送るだけである。利点は、追加のシグナリングを必要とせず、スケーラビリティを提供することである(即ち、ホップ数に制限がない)。欠点は、UEがIABノードからSTATUS PDUを受信するためにより長い時間待つ可能性があることだが、選択肢1よりも悪くない。
まだ研究段階にあるので、両方の選択肢が有益であると認識される場合、両方の選択肢はTRに取り込まれるべきである。
提案6:RAN2は、「ULステータス配信」の詳細をTRに取り込むことに同意すべきである。特に、IABノードはIABドナーからのUL配信ステータス報告(選択肢1)及びその親ノードからのRLC ACK(選択肢2)を考慮する。
[付記2]
1.序論
統合されたアクセスとバックホールに関する新しいワークアイテムが承認された。このWIの目的の1つは、ロスレス配信でマルチホップRLC ARQメカニズムを指定することである。
L2無線トランスポートの拡張の仕様:
・hop-by-hopのARQにおけるロスレス配信を可能にするメカニズムの仕様。
この付記では、hop-by-hopのARQの規範的なワークのための最初の考慮事項について議論する。
2.議論
調査段階では、マルチホップRLC ARQが広く議論され、最終的にTRは、「RAN2は、hop-by-hop及びend-to-endのRLC ARQを研究した。Rel-16では、hop-by-hopのARQのみをサポートすることが推奨される。」と結論付けた。hop-by-hopのRLC ARQに関して、ULデータのロスレス配信の問題が特定され、候補の解決策とこれらの所見がTRでキャプチャされた。hop-by-hopのRLC ARQにおけるend-to-endの信頼性の問題は、例えば、次のメカニズムを指定することで対処できる。
-PDCPプロトコル/手順の変更。このメカニズムは、Rel-15 UEのパフォーマンスが低下する可能性があるため、Rel-15のUEには適用されないだろう
-PDCPデータ回復/PDCP再確立がRRCによってトリガされるか、PDCPステータスレポートが受信される場合、UEは、RLCによって配信の成功が確認されたかどうかに関係なく、ULデータを再送信する
-RLCによる配信成功の確認に関係なくUEがULデータ再送信を実行するかどうかを示すために、RRCメッセージ又はPDCPステータスレポートに新しいフィールドを含め得る
-経路更新に応じて、中間IABノードでバッファされたPDCP PDUの再ルーティング
-ULデータは、IABノードが親ノードからIABドナーに正常に配信されたULデータに関する情報、又はRLC肯定ACKのいずれかを受信するまで、IABノードでバッファされる
-転送パスが(再)設定されると、バッファされたデータは、新しいパスの最新の変更がされていないノードであるIABノード、又はバックホールリンク障害が発生したIABノードによって再送信される
-ULステータス配信の導入(ドナーgNBからIABノードへ)
-1つの方法は、UEのアクセスIABノードが、IABドナーからデータ受信の確認を受信するまで、UEへのRLC肯定ACKの送信を遅らせることである。別の方法は、IABノードが、親ノードからRLC肯定ACKを受信するまで、子ノード又はUEへのRLC肯定ACKの送信を遅らせることである。
-RRCによってPDCPデータ回復/PDCP再確立がトリガされる場合、UEは現在の仕様のようにULデータを再送信する
明らかに、「ULステータス配信の導入」の3番目の候補は、研究段階で議論されたメトリックスに利点がある。したがって、Rel-16の規範的なワークでは、3番目の解決策を優先する必要がある。他の解決策も検討することができ、除外することは意図されていない。
提案1:RAN2は、hop-by-hopのRLC ARQにおけるULのロスレス配信で特定された「ULステータス配信の導入」に基づく解決策を最初に検討すべきである。
提案1が受け入れられる場合、「ULステータス配信」が何であるかを明確にすべきである。TRは、次の2つの可能性をキャプチャする。
「1つの方法は、IABノードからのデータ受信の確認を受信するまで、UEのアクセスIABノードがRLC肯定ACKのUEへの送信を遅らせることである。」(選択肢1)
・「別の方法は、IABノードが、親ノードからRLC肯定ACKを受信するまで、子ノード又はUEへのRLC肯定ACKの送信を遅らせることである。」(選択肢2)
所見1:「ULステータス配信」の2つの選択肢が研究段階で特定された。
選択肢1では、IABノードはIABドナーから直接ULステータス配信を受信する。RLC STATUS PDUがピアRLCエンティティ間で転送されることを考慮すると、マルチホップ機能により、ULステータス配信が中間RLCエンティティを超えて(つまり、中間IABノードで)必要になることが課題となるだろう。中間IABノードのRLCエンティティをバイパスするには、(アクセス)IABノードとIABドナー間の直接メッセージ(つまり、ULステータス配信)は、RLCレイヤの上に配置され、無線バックホール全体のルーティングを提供するアダプテーションレイヤに(或いは、他の可能性として、F1-APに)実装する必要がある。アダプテーションレイヤ/F1-APとRLCレイヤとの間のレイヤ間相互作用(例えば、RLC層からのポーリング要求、RLCデータPDUのシーケンス番号のマッピングを伴うアダプテーションレイヤからの配信指示など)が必要になる可能性がある。
所見2:直接の「ULステータス配信」(選択肢1)は、アダプテーションレイヤ又はF1-APに実装されてもよく、いくつかのレイヤ間の相互作用が必要である。
選択肢2では、IABノードは、親ノードから対応するRLC ACKを受信するまで、子ノードにRLC ACKを送信するのを遅らせる。そのため、ULステータス配信はRLCレイヤで既存のSTATUS PDUを再利用でき、メッセージは「暗示的」と見なされます。ただし、エッジデバイス(例えば、UE及び(アクセス)IABノードでRLC ACKの遅延が長くなると、ウィンドウの長さが長くなったり、t-StatusProhibitタイマが短くなったり、注意深い操作が行われたりしない限り、RLCウィンドウが停止するため、レイテンシ/スループットが低下する可能性がある。
所見3:暗示的な「ULステータス配信」(選択肢2)は、既存のRLC STATUS PDUを再利用できますが、頻繁なRLCウィンドウ停止を回避するために、慎重に実装する必要がある。
「ULステータス配信」の2つの選択肢には長所と短所がありますが、選択肢2の方が簡単であるため、標準化の労力は少なくなる。
提案2:RAN2は、既存のRLC STATUS PDUを再利用する暗示的な「ULステータス配信」、すなわち、「IABノードは、その親ノードからRLC肯定ACKを受信するまで、その子ノード又はUEへのRLC肯定ACKの送信を遅らせる」(上記選択肢2)を採用(又は優先)することに同意すべきである。
選択肢間の共通の側面は、RLCがUE及び/又は子ノードへのRLC ACKのための追加条件、つまりSTATUS PDUでACK_SNを設定する方法を持つ必要があることだろう。IABノードのRLCエンティティは、実際にUE/子ノードから関連データPDUを正常に受信したが、IABドナー/親ノードからの「ULステータス配信」の受信を待つ必要があるためである。単純な解決策は、RLCエンティティが「ULステータス配信」を受信するまで、関連するデータPDUがまだ受信されていないと見なすことである。
提案3:RAN2は、選択肢(つまり、直接的又は暗示的)に関係なく、STATUS PDUを構築する場合、「ULステータス配信」が受信されるまで、関連するULデータPDUがまだ受信されていないとRLCエンティティが見なすことに同意すべきである。
[付記3]
1.序論
統合されたアクセスとバックホールに関する新しいワークアイテムが承認された。WIDは、目的の1つとしてバックホール無線リンク障害(BH RLF)処理を指定することを定める。
以下を含むアーキテクチャ1aに続くIABノードの仕様
・[…]
・低遅延スケジューリング、BH RLF処理、及びマルチホップトポロジ全体のリソース調整をサポートするためのシグナリングのホップバイホップ伝搬。
・[…]
L2トランスポート及びリソース管理のシグナリングの仕様
・[…]
・BH RLF処理の仕様(例:ダウンストリームBH RLF通知)
この付記では、研究項目からの結果に加えてBH RLF処理の最初の考慮が議論される。
2.議論
TRは、セクション9.7.14及び9.7.15において、マルチホップの無線バックホールのBH RLFに起因する問題を特定する。セクション間の共通の問題は、子IABノード/UEが親IABノードにおけるBH RLFを認識していないことである。結果として、ユーザの観点から、サービスの回復が遅れることを含むサービスが大幅に中断される。これにより、BH RLFは、FR2やマルチホッピングなどの高周波数の無線バックホールにおいて頻繁に発生する可能性がある。
このような悪いユーザーエクスペリエンスを回避するために、TRは次のように潜在的な解決策も特定する。
9.7.14アーキテクチャ1aにおけるBH RLFのダウンストリーム通知
「選択肢1:IABノードDUはサービスを中止する。その結果、子ノードもBH RLFを決定し、上記の手順に従って回復する。」
「選択肢2:IABノードDUは、アップストリームRLFについて子IABノードに明示的に警告する。この警告を受信した子IABノードは、警告をさらに下流に転送し得る。このような警告を受信した各IABノードは、上記のBH-RLF回復を開始する。」
「選択肢3:全てのIABノードは、BH品質などに関する情報を子又は親のIABノードと定期的に共有し得る。このようにして、明示的な動作を実行しなくても、ダウンストリーム又はアップストリームRLFを検知し得る。」
9.7.15効率的なバックホールリンク障害の復旧
「バックホール障害のために親ノードとして機能できないノードのリストを含む、バックホール障害に関する情報は、ダウンストリームIABノードに提供され得る。」(選択肢4)
「事前(つまり、RLFの発生前)における代替バックホールリンクとルートの準備」(選択肢5)
2.1.IABノードがサービスを中止する(選択肢1)
選択肢1は、BH RLF情報が子IABノード及びUEに暗示的に伝搬されるため、セクション9.7.14と9.7.15との間の共通の問題のための一般的な解決策と見なし得る。BH RLFが子IABノードだけでなく、(BH RLFに直面する親IABノードに接続される)UEにも影響することを考慮すると、選択肢1は既存のRLFと回復メカニズムに依存することが予想されるため、選択肢1がRel-15 UEでサポートされることは重要な側面である。一方、他の選択肢にはRel-16の機能が必要であろう。Rel-15 UEの場合でもサービスの中断を最小限に抑えるには、BH RLFの問題のためのベースラインの解決策として選択肢1を指定すべきである。
提案1:RAN2は、選択肢1、つまりIABノードがBH RLFでサービスを停止すること、及び選択肢1はRel-15 UEにも有効であるため、ベースラインの解決策であることに同意すべきである。
選択肢1の説明によれば、解決策は「子ノードもBH RLFを判定する」ことを容易にすべきである。技術的には、子IABノードのMT及びUEは、「サービス」が中断された場合にRLFを宣言すべきである。簡単な解決策は、BH RLF下にある親IABノードが、PSS、SSS、MIB、及びSIB1の送信を停止することである。これにより、子IABノード及びUEの無線問題を意図的に作成する。
提案2:RAN2は、「サービス」を中止することを決定した場合に、IABノードがPSS、SSS、MIB、及びSIB1の送信を停止することに同意すべきである。
提案2に同意できる場合は、いつ信号が停止するかを厳密に定義すべきである。BH RLFにあることはTRから大まかに理解できるが、BH RLFが何であるか、及び「サービス」がいつ停止するかは不明確である。明らかに、BH RLFは、IABノードのMTとIABドナーのDU(例えば、親IABノードのDU)の間のRLFと見なし得る。UEとgNB間の既存のRLFを使用した場合とまったく同じように理解し得る。したがって、BH RLFは、無線バックホールリンクにおけるRLFとしてモデル化される。
提案3:RAN2は、BH RLFに既存のRLFメカニズムの再利用に同意すべきである。
提案3に同意できる場合、現在のUEの動作はRLFを宣言した後でも、つまりRRC再確立を開始するためにRRC接続を維持するため、RLFでサービスを実際に停止する必要があるかどうかは疑問である。UEがRRC接続を正常に再確立すると、最小の中断時間でサービスが回復する。そのため、IABノードは、MTがRRC IDLEに入った場合、つまりRRC再確立が失敗した場合にのみ、「サービス」を停止すべきであることが分かる。
提案4:RAN2は、MTがRLFを宣言した場合ではなく、MTがRRC IDLEに入った場合、IABノードのDUが「サービス」を停止することに同意すべきである。
上記のように、選択肢1は、Rel-15のUEを含むあらゆる種類のケースとデバイスをカバーするための基盤であり、サービスの迅速な回復などの点で最良の解決策を意味するものではない。そのため、他の選択肢は選択肢1に加えて有益であり、このWIで指定される他の多くの機能がある。
所見1:選択肢1の上にある他の選択肢は、サービス品質をさらに向上させるという点で依然として有益である。
2.2.IABノードはダウンストリームノードに通知する(選択肢2、選択肢4)
子IABノードが回復手順を迅速及び/又は効率的に開始することを容易にするため、親IABノードがそのBH RLFに関連する情報を子IABノードに通知することは役立つ。TRは、「アップストリームRLFについて子IABノードに明示的に警告する」(選択肢2)のような可能な情報要素、又は「親ノードとして機能できないノードのリストを含むバックホール障害に関する」(選択肢4)情報をキャプチャする。
ただし、親IABノードでBH RLFが発生した場合に、子IABノードにそのような情報を提供する方法は不明確である。研究項目は、「RAN-3は将来の規範的段階にアーキテクチャ1aを推奨する」と結論付けた。これは、IABノードがDUとMTで構成され、IABドナーが(DUと)CUで構成されることを意味する。CUはDUとCUとの間のRRCを担当し、BH RLFはMTのRRCで検出される。そのため、考慮すべき2つの異なるRRCがある。親IABノードのMT上におけるRRCは、BH RLFを検出し、IABドナーの異なるRRCは子IABノードに送信されるRRCメッセージを生成する。
物理的な無線リンクがBH RLFで切断されることを考慮すると、ダウンストリームノードへの情報はRRCメッセージで伝達でない。つまり、CUによって生成されたRRCメッセージはBH RLFのためにDUに到達できない。(選択肢2の)「警告」は、MAC CEなどで送信してもよいが、RRCメッセージを使用しなければ、(選択肢4の)「ノードのリスト」は大きすぎ、フレキシブルすぎる。そのため、選択肢2及び/又は選択肢4が導入された場合、RAN2は最初にどのシグナリングが使用されるかを検討すべきである。
所見2:CUへの物理的な無線リンクが切断されているため、IABノードのDUはRRCメッセージを使用しなくてもよい。
この情報はRel-16の機能として提供されることは明らかである。つまり、IABノード間でのみサポートされ得る。つまり、Rel-15のUEではサポートされない。
所見3:選択肢2及び選択肢4は、Rel-16のIABノードの復旧手順でのみ機能する。
2.3.全てのIABノードは定期的に情報を共有する(選択肢3)
選択肢3では、IABノードは共有される情報に基づいてBH RLFを検知できる。TRでキャプチャされる情報は、例えば、「BH品質」である。これは、F1の既存のGNB-DUステータス表示である場合とDU間の新しいシグナリングである場合があってもよい。
所見4:選択肢3はRAN2の範囲外である可能性がある。
2.4.代替リンクの事前準備(選択肢5)
選択肢5は、例えば、マルチコネクティビティ(MN/SNロール変更あり)、条件付きハンドオーバ、又は通常のトポロジ適応又はモビリティ拡張に関連するその他の技術を利用することを目的とする場合がある。TRで「他のRel-16のWIの一部として定義された追加の機能/拡張機能を活用してもよい」と述べられているように、選択肢5は、このWI又は他のWIの他のトピックで議論される結果を再利用してもよい。
所見5:選択肢5は、このWI又は他のWIでの他のトピックで議論される解決策を再利用してもよい。
[付記4]
1.序論
統合されたアクセス及びバックホールの新しいワークアイテムはRAN#82で承認され、マルチホップ無線バックホールの低レイテンシスケジューリングは特定されると見なされる。
アーキテクチャ1aに続くIABノードの仕様
・[…]
・マルチホップトポロジ全体での低レイテンシスケジューリング、BH RLF処理、及びリソース調整をサポートするためのシグナリングのhop-by-hop伝搬。
この寄書では、低レイテンシスケジューリングの解決策について議論する。
2.議論
この研究項目は、TR 38.87のセクション8.6でキャプチャされた図22に示すようなマルチホップバックホールのシーケンス手順によるULスケジューリングのレイテンシの問題を特定した。
TRはまた、「このような遅延を緩和する1つのアプローチは、到着が予想されるデータに基づいてIABノードでアップリンクリソース要求を開始することで構成される。これにより、IABノードは、子IABノード又はそれがサービスを提供するUEから実際のデータを受信する前に、アップリンクリソースを取得できるようになる。」、及び「SR/BSR及びULスケジューリングの内容及びトリガの詳細は、WI段階に残される。」という考えられるメカニズムを特定する。
詳細に飛ぶ前に、前提条件に応じて解決策が多少異なるため、拡張が動的割り当てに必要か、設定されたグラントに必要か、又はその両方に必要かを明確にすべきである。上記のTRの論述は、動的リソース割り当ての使用を意図している可能性がありますが、レイテンシの問題は、設定されるグラントには問題でない場合がありますが、場合によってはスペクトル効率において問題がある場合がある。したがって、RAN2は、動的リソース割り当てのためにSR、BSR、及び/又はULスケジューリングを拡張すべきである。
提案1:RAN2は、マルチホップ無線バックホールでの動的なリソース割り当てのためにSR、BSR、及び/又はULスケジューリングを拡張すべきである。
現在の仕様では、次のように通常のBSR送信用のリソースがない場合にSRがトリガされる。
MACエンティティ
1>バッファステータスレポート手順で、少なくとも1つのBSRがトリガされ、キャンセルされていないと判断された場合
[…]
2>通常のBSRがトリガされ、logicalChannelSR-DelayTimerが実行されていない場合
3>新しい送信に利用可能なUL-SCHリソースがない場合、又は
3>MACエンティティが設定されるアップリンクグラントで設定し、logicalChannelSR-Maskがfalseに設定される論理チャネルに対して通常のBSRがトリガされた場合、又は
3>新しい伝送に使用可能なUL-SCHリソースが、BSRをトリガした論理チャネルに設定されたLCPマッピングの制限(5.4.3.1を参照)を満たさない場合、
4>スケジューリング要求をトリガする
したがって、重要な問題の1つは、通常のBSRのトリガを高速化する方法である。通常のBSRは、次のように、データが送信可能になるとトリガされる。
MACエンティティは、TS38.322及び38.323のデータ量計算手順に従って、論理チャネルで使用可能なULデータの量を決定する。
次のいずれかのイベントが発生した場合、BSRがトリガされる。
-LCGに属する論理チャネルのULデータは、MACエンティティで利用可能になる。
-このULデータは、任意のLCGに属する利用可能なULデータを含む論理チャネルの優先度よりも高い優先度を持つ論理チャネルに属する。又は、
-LCGに属する論理チャネルには、利用可能なULデータが含まれていない。
この場合、BSRは「通常BSR」と呼ばれる。
「アーリー通常BSRトリガ」を有効にするには、送信可能なデータに追加のルールを設定することが簡単である。現在、このようなデータ量の計算手順はRLC及びPDCPレイヤでのみ行われているが、バックホールリンクのMTのMACエンティティは、DUに表示されるULデータ量を何らかの形で考慮すべきである。
提案2:RAN2は、MTのMACエンティティが、同じIABノードのDUで見えるULデータ量を考慮する必要があることに同意すべきである。
提案2に同意できる場合、DUに見えるデータ量のどれがデータ利用可能な送信とみなされるかを検討すべきである。以下の選択肢が考慮される。
選択肢1:DUプロトコルスタックのMAC、RLC、PDCP(及び場合によってはアダプテーションレイヤ)におけるバッファの実際のデータ量。
選択肢2:選択肢1に加えて、子ノード/UEに既にグラントされているデータ量(図23)。
選択肢3:選択肢2に加えて、子ノード/UEでの送信に利用可能なデータ、つまり子ノード/UEからのBSRのバッファサイズ(図21)。
レイテンシ削減の観点から、選択肢3は、IABノードのDUが子ノード/UEからULデータを受信したときにそのIABノードのMTがバックホールリンクのリソースをグラントしたことが予想されるため、最適な解決策である。一方、MTでのULグラントの受信とDUでのULデータの受信とが十分に同期されていない限り、リソースの浪費が発生する可能性がある。つまり、オーバースケジューリングが発生する可能性がある。選択肢1はリスクが低いが利益も低くなる。選択肢2は、他の選択肢間のバランスの取れた解決策と見なされる。
提案3:RAN2は、送信に利用可能な追加データがUEへのULグラント又はUEからのBSRに関連するデータ量であるかどうかを議論すべきである。
本願は、米国仮出願第62/805435号(2019年2月14日出願)の優先権を主張し、その内容の全てが本願明細書に組み込まれている。