🚄

3GPP Integrated Access and Backhaul(IAB)仕様解説

2023/01/13に公開

3gpp

iab

tech

Introduction

3GPPで規定されているIntegrated Access and Backhaul(IAB)の仕様解説です。

References

RAN Technical Specifications/Reports

3GPP TS 38.300 NR; NR and NG-RAN Overall description; Stage 2
3GPP TS 38.401 NG-RAN; Architecture description
3GPP TS 38.174 NR; Integrated Access and Backhaul (IAB) radio transmission and reception
3GPP TR 38.809 NR; Background for integrated access and backhaul radio transmission and reception
3GPP TR 38.874 NR; Study on integrated access and backhaul FS_NR_IAB(Rel-16)
3GPP TR 22.839 Study on vehicle-mounted relays; stage 1 (release 18)

SA2 Technical Specifications

3GPP TS 23.501 System architecture for the 5G System (5GS)
3GPP TS 25.502 Procedures for the 5G System (5GS)

Release-16 (as of Jan 2023)

Release-17 (as of Jan 2023)

Release-18 (as of Jan 2023)

[119] 3GPP, “IAB Enhancements for Rel 17,” 3rd Generation Partnership Project (3GPP), RP 192709, Dec. 2019, TSG-RAN WG3 meeting no. 86. [Online]. Available: https://www.3gpp.org/ftp/TSG_RAN/TSG_ RAN/TSGR_86/Docs/RP-192709.zip (visited on 09/13/2021)

[120] ——, “IAB topology update procedure,” 3rd Generation Partnership Project (3GPP), R3 212413, May 2021, TSG-RAN WG3 meeting no. 112-e. [Online]. Available: https : / / www. 3gpp . org / ftp / TSG _ RAN/WG3 _ Iu/ TSGR3 _ 112 - e/ Docs/ R3 - 212413 . zip (visited on 09/13/2021).

Research papers

Paving the Way Towards Mobile IAB: Problems, Solutions and Challenges

Background

IABは基地局のバックホールを無線で、かつ既存のUE-gNB間アクセスを最大限流用しつつ提供する仕組みのこと。実はLTEでもマイクロ波を使った無線バックホールは（独自実装だと思うけど）存在してる。3GPPでもLTEのころから検討はされてたけど制約が大きくあまり普及しなかった。

LTEのときの制約としては、
・シングルホップのみのサポート
・静的なアーキテクチャ（トポロジ変更とかできない）
・アクセスとバックホール間の静的な帯域分割
・利用できるスペクトルの制限（ミリ波が使えない）
などがあった。
5Gのこの制約を解消する柔軟性の高い仕組みとしてIABが標準化された。

つまり、5G IABでは、マルチホップ・アーキテクチャ、柔軟なトポロジー、動的なリソース共有、およびアクセスとバックホールの両方にミリ派を使用できるようになった。特にミリ波とMIMO指向性で高いデータレートを実現できるようになり、ようやくバックホールに使えるものとなった。

Definitions

TS 38.300

(3.2節の定義を著者の解釈で並び替え・ブループ化している)
IAB-donor: gNB that provides network access to UEs via a network of backhaul and access links.
IAB-node: RAN node that supports NR access links to UEs and NR backhaul links to parent nodes and child nodes. The IAB-node does not support backhauling via LTE.

IAB-MT: IAB-node function that terminates the Uu interface to the parent node using the procedures and behaviours specified for UEs unless stated otherwise. IAB-MT function used in 38-series of 3GPP Specifications corresponds to IAB-UE function defined in TS 23.501 [3].
IAB-DU: gNB-DU functionality supported by the IAB-node to terminate the NR access interface to UEs and next-hop IAB-nodes, and to terminate the F1 protocol to the gNB-CU functionality, as defined in TS 38.401 [4], on the IAB-donor.

Parent node: IAB-MT's next hop neighbour node; the parent node can be IAB-node or IAB-donor-DU
Child node: IAB-DU's and IAB-donor-DU's next hop neighbour node; the child node is also an IAB-node.

Downstream: Direction toward child node or UE in IAB-topology.
Upstream: Direction toward parent node in IAB-topology.

IAB topology: The unison of all IAB-nodes and IAB-donor-DUs that are interconnected via BH links and terminate F1 and/or RRC at the same IAB-donor-CU.

Inter-donor partial migration: Migration of an IAB-MT to a parent node underneath a different IAB-donor-CU while the collocated IAB-DU and its descendant IAB-node(s), if any, are terminated at the initial IAB-donor-CU. The procedure renders the said IAB-node as a boundary IAB-node.
Multi-hop backhauling: Using a chain of NR backhaul links between an IAB-node and an IAB-donor.
NR backhaul link: NR link used for backhauling between an IAB-node and an IAB-donor, and between IAB-nodes in case of a multi-hop backhauling.

TS 38.401

(3.2節の定義を著者の解釈で並び替え・ブループ化している)
Boundary IAB-node: an IAB-node with one RRC interface terminating at a different IAB-donor-CU than the F1 interface. This definition applies to partial migration, inter-donor redundancy and inter-donor RLF recovery.

IAB-donor-CU: the gNB-CU of an IAB-donor, terminating the F1 interface towards IAB-nodes and IAB-donor-DU.
IAB-donor-DU: the gNB-DU of an IAB-donor, hosting the IAB BAP sublayer (as defined in TS 38.340 [22]), providing wireless backhaul to IAB-nodes.

F1-terminating IAB-donor of boundary IAB-node: Refers to the IAB-donor that terminates F1 for the boundary IAB-node.
Non-F1-terminating IAB-donor of boundary IAB-node: Refers to the IAB-donor that has an RRC connection with the boundary node but does not terminate F1 with this boundary node.

Architecture

IAB（Integrated Access and Backhaul）は、NG-RANにおける無線中継(wireless relaying)を可能にする機能です。IAB-nodeと呼ばれるリレーノードは、NR経由のアクセスとバックホールの両方をサポートすることができます。ネットワーク側のNRバックホール終端ノードはIAB-donorと呼ばれます。gNBに相当しますが、IABをサポートするための追加機能を持ちます。
バックホールは、単一ホップまたは複数ホップを経由して行われることがあります。
!

a) SA mode with NGC
b) EN-DC

IAB-nodeは、TS 38.401で定義されたgNB-DU機能をサポートして、UEおよびnext-hop IAB-node へのNRアクセスを終端し、IAB-donorのgNB-CU機能へF1プロトコルを終端させる。IABノード上のgNB-DU機能は、IAB-DUとも呼ばれます。
IABノードは、gNB-DU機能に加えて、IAB-MTと呼ばれるUE機能のサブセットもサポートます。つまり、IAB-MTには物理層、層2、RRCおよびNAS機能が含まれており、他のIABノードまたはIABドナーのgNB-DUに接続し、5GCに接続することができます。

以上のように、IABでは既存のRAN機能やIFを再利用して設計されてる。

下図にようにIABドナーとIABノードでIABトポロジーを形成する。
このIABトポロジーにおいて、IAB-DUまたはIAB-donor-DUの近傍ノードをChild node、IAB-MTの近傍ノードをParent nodeと呼ぶ。また、Child nodeに向かう方向をdownstream、Parent nodeに向かう方向をupstreamという。IAB-donorは、そのIABトポロジーのリソース、トポロジー、ルート管理を一元的に実行する。

IABにはインバンドとアウトバンドの2つのモードがある。
in-band：BH(バックホール)とAL(アクセスリンク)同じ周波数を使う。自己干渉を避けるため半二重(Half Duplex)で動作する。
out-band：BHとALで異なる周波数を使う。干渉を回避できる。TDDにおいてBHとALのDL/ULの領域の最適化を行う。

Protocols

CUはIABドナーのみに配置されるのは、スケジューリングや再送信など低レイヤで遅延要求の高い処理を物理的に近い箇所で実行するため。プロトコルスタックでは、BAP(Backhaul Adaptation Protocol)の導入が特徴的。

F1-U/F1-CはTS 38.407で規定される。F1はTS 33.501にあるようにセキュリティ保護される。

無線バックホールでは、IPレイヤーはBAP（Backhaul Adaptation Protocol）サブレイヤーを介して転送され、複数のホップでのルーティングを可能にする。IPレイヤは、TS 38.401で定義されているOAMトラフィックなど、非F1トラフィックにも使用できる。

各IABノードは、IABネットワーク内で一意に識別するためのBAPアドレスを所有する。BAPパケットヘッダにはBAPルーティングID（IABドナーが設定）が設定される。BAPルーティングID = BAPアドレス + BAPパスID。
BAPパスIDにより、パケットがノードに到達するまでに辿るべきルーティングパスを定義できる

プロトコルレベルでの他の特徴は、RLCでhop by hop ARQがあげられる。end to end ARQではホップ数の増大による遅延増大がボトルネックになるし、パケロス発生時による再送信も負担になる。

各BHリンクでは、BAP PDUはBH RLCチャネルによって運ばれる。トラフィックの優先順位付けとQoSを可能にするために、各BHリンクに複数のBH RLCチャネルを設定することができる。BAP PDUのBH-RLCチャネル・マッピングは、各IABノードおよびIABドナーDU上のBAPエンティティによって実行される。

IAB-MTはさらに、IAB-donor-CUとSRB（RRCおよびNASを搭載）を確立する。DRBの確立はオプション。SRBとDRBは、IAB-MTとその親ノードとの間でUuアクセスチャネルを介して伝送される。

User-plane Aspects

Backhaul transport

IPトラフィックはBAPサブレイヤーで転送される。BAPサブレイヤーはTS 38.340で規定される。

downstream: IAB donor DUのBAPサブレイヤーでカプセル化、宛先IABノードでカプセル化解除
upstream: IAB nodeのBAPサブレイヤーでカプセル化、IAB donor DUでカプセル化解除

各IABノードは、IABネットワーク内で一意に識別するためのBAPアドレスを所有する。BAPパケットヘッダにはBAPルーティングID（IABドナーが設定）が設定される。

BAPルーティングID = BAPアドレス + BAPパスID

BAPパスIDにより、パケットがノードに到達するまでに辿るべきルーティングパスを定義できる。

IABノードはBAPアドレスを検査する。パケットが宛先に到達していない場合、egress link(ネクストホップ、次のIABノード)を決定する。
IAB-nodeはさらに、指定されたegress linkのegress BH RLC Channelを決定する。BHでのtraffic specific prioritizationとQoS enforcementが可能になる。

Flow and Congestion Control

upstreamとdownstreamの両方にFlow and Congestion Controlが適用できる。

upstream: MAC UL scheduling
downstream: NR User plane protocol (TS 38.425)とIABサブレイヤー

Uplink Scheduling Latency

UL scheduling遅延を減らすためにPre-emptive BSRが導入された。
下図のb) c)のように中間のIAB-nodeではDataを受け取る前（実際にデータをバッファする前に）に予想されるデータ量をPre-emptive BSRでParent Nodeに送ることができる。

Signalling procedures

IAB-node Integration (TS 38.401 8.12.1)

Phase 1: 図ではIAB-node 2がnewノード。先ずはUEと同じ要領で5GCへの登録、セッション確立までを行う。オプションでOAM用のセッションも確立する。親ノード選択のときはSIB1のindicationをみる。IAB-MTはRRC接続のときRRCSetupCompleteに自身のcapabilityを入れて、IABドナーはIABをサポートするAMFを選択するのに使う。
Phase 2-1:BH RLC Channelの確立。少なくとも1つ確立して、追加で確立するかもしれない（OAM用など）。BAP Addressの設定もする。
Phase 2-2:Routing Update。BAPサブレイヤーがIAB-node 2とIABドナー-DU間のルーティングをできるように更新される。CUからF1AP手順を開始する。
Phase 3: IAB-DUがOAMからセットアップされる。

IAB-node Migration (Toporogy Adaptation)(TS 38.401 8.17.3)

トポロジーアダプテーション。IABノードが別の親ノードへ移行する手順。TS 38.401で規定される。UEハンドオーバーに似ている。IABノードはMeasurement Reportを親ノードを経由してIABドナーに通知する。
2つのシナリオがある。

IABドナーが同じ　→　Intra-CU topology adaptation
IABドナーが変わる　→　Inter-CU topology adaptation

参考文献のPaving the Way Towards Mobile IAB: Problems, Solutions and Challengesより抜粋。

以下は、Inter-CU topology adaptationのシーケンス。
Phase 1: IAB-MT migration

Phase 2: F1 transport migration

Topological Redundancy(TS 38.401 8.17.2)

冗長化のためにデュアル接続する。NR-DC(TS 37.340 10.2節)を使うことが前提、つまりSA modeが前提。(EN-DCではない)

Backhaul RLF Recovery(TS 38.401 8.17.4)

IABノードでRLF(Radio Link Failure)になった場合、他の親ノードで回復を試みることができる。XnインタフェースでUEコンテキストの転送を行う。

5GC Support for IAB

IABが5GCに接続するときのリファレンスアーキテクチャ。IAB-MTはIAB-UEと表記されている。

5GS Enhancement (TS 23.501 5.35.2)

Registration手順(TS 23.502 4.2.2.2)ではIAB-nodeの能力がAMFに通知される。N2 INITIAL UE MESSAGEに含める。(TS 38.413)
IAB-indicationはRRC接続時にIAB-donor-CUに提供される。IAB-donor-CUはindicationにもとづきIABをサポートするAMFを選択する。
IABの認可のためにUE Subscription dataを拡張する。Registration手順のときにそれを確認する。
IAB-nodeはCM-CONNECTED stateを維持する。
RLFのときは既存の手順で回復する。

Mobile IAB

Release-18でMobile IABについて検討されている。
WID: RP-222671

車両搭載側のMobile IABノードのシナリオにフォーカスする。

In-band and out-of-band backhauling.
The mobile IAB-node should have no descendent IAB-nodes, i.e., it serves only UEs.
Solutions should support UE HO and UE DC.

目的は以下、

Define Procedures for migration/topology adaptation to enable IAB-node mobility, including inter-donor migration of the entire mobile IAB-node (full migration) [RAN3, RAN2]
- The mobile IAB-node can connect to a stationary (intermediate) IAB-node. Optimizations specific to the scenarios, where the mobile IAB-node connects to a stationary (intermediate) IAB-node, or where it directly connects to an IAB-donor-DU are de-prioritized.
- The mobility of dual-connected IAB-nodes is down-prioritized.
Enhancements for mobility of an IAB-node together with its served UEs, including aspects related to group mobility. No optimizations for the targeting of surrounding UEs. [RAN3, RAN2]
Note: Solutions should avoid touching upon topics where Rel-17 discussions already occurred and where the topic was excluded from Rel-17, except for enhancements that are specific to IAB-node mobility.
Mitigation of interference due to IAB-node mobility, including the avoidance of potential reference and control signal collisions (e.g. PCI, RACH). [RAN3, RAN2]

Challenges

Paving the Way Towards Mobile IAB: Problems, Solutions and Challengesで取り上げられていた個人的に興味のある課題。

Mobile IABではU-Planeがマルチホップで、C-Planeをワンホップにするというアイディアもある。(RP-192709)
Inter-CU topology adaptationでは、IABノードの配下の子ノードやUEの全てがターゲットCUにHOしないといけない。(R3-212413)UEコンテキストの転送の負荷が大きい。Xn,F1,UuでのSignaling Streamが課題になる。2つの論理DUをサポートのアイディアもあり。
Group HandoverとRACHレスもあり。Group Signallingで複数UEのHO messageを連結圧縮することも考えられている。(R3-206332)