IAB node, IAB node chipset, communication control method, first donor base station, second donor base station, communication system and program

Abstract

This invention provides a communication control method that enables IAB (Integrated Access and Backhaul) node handover between donor base stations without requiring any operational changes to user equipment. [Solution] In a cellular communication system, when a relay node (IAB node) having a user device UE under its control switches the connection from a first donor base station (source donor eNB) to a second donor base station (target donor gNB), even after the connection switch, the control connection between the user device and the first donor base station is maintained via the second donor base station, and the first donor base station transmits control information to the user device via the second donor base station.

Description

Technical Field

[0001] The present disclosure relates to an IAB node used in a cellular communication system, a chipset of the IAB node, a communication control method, a first donor base station, a second donor base station, a communication system, and a program.

Background Art

[0002] In 3GPP (3rd Generation Partnership Project) (registered trademark; the same applies hereinafter), which is a standardization project for cellular communication systems, a new relay node called an IAB (Integrated Access and Backhaul) node is defined (see, for example, "3GPP TS 38.300 V16.2.0 (2020-07)"). One or more relay nodes intervene in the communication between the base station and the user equipment and perform relay for this communication.

Summary of the Invention

[0003] A communication control method according to a first aspect is a communication control method used in a cellular communication system. A relay node that performs data relay from a relay source node to a plurality of relay destination nodes selects a data relay destination from among the plurality of relay destination nodes according to a routing setting set from a donor base station, and when a predetermined condition is satisfied, the relay node executes local routing for selecting the data relay destination without following the routing setting. The predetermined condition includes the condition of receiving a failure occurrence notification from any one of the plurality of relay destination nodes.

[0004] A communication control method according to a second embodiment is a communication control method used in a cellular communication system, comprising: a relay node having user equipment under its control performing a connection switch from a first donor base station to a second donor base station; maintaining the RRC (Radio Resource Control) connection between the user equipment and the first donor base station via the second donor base station even after the connection switch; and the first donor base station using the RRC connection to transmit a handover command to the user equipment via the second donor base station instructing a handover to the second donor base station.

[0005] A third aspect of the communication control method is a communication control method used in a cellular communication system, comprising: a relay node that relays data from a source node to a plurality of destination nodes receiving capacity information relating to the data relay capacity of a target relay node included in the plurality of destination nodes from the target relay node; and the relay node controlling the data relay based on the capacity information.

[0006] A fourth aspect of the communication control method is a communication control method used in a cellular communication system, comprising: a relay node that relays data from a source node to a plurality of destination nodes selecting a data relay destination from among the plurality of destination nodes in accordance with routing settings set by a donor base station; and the relay node transmitting a routing change request to the donor base station to change the routing settings.

[0007] A fifth aspect of the communication control method is a communication control method used in a cellular communication system, comprising: a relay node that relays data from a source node to a plurality of destination nodes selecting a data relay destination from among the plurality of destination nodes in accordance with routing settings set by a donor base station; the relay node, when predetermined conditions are met, performing local routing to select the data relay destination without following the routing settings; and transmitting history information regarding the local routing to the donor base station. [Brief explanation of the drawing]

[0008] [Figure 1] This diagram shows the configuration of a cellular communication system according to an embodiment. [Figure 2] This diagram shows the relationship between IAB nodes, parent nodes, and child nodes. [Figure 3] This diagram shows the configuration of the gNB (base station) according to the embodiment. [Figure 4] This diagram shows the configuration of an IAB node (relay node) according to the embodiment. [Figure 5] This diagram shows the configuration of the UE (User Equipment) according to the embodiment. [Figure 6] This figure shows the protocol stack for IAB-MT RRC and NAS connections. [Figure 7] This is a diagram showing the protocol stack for the F1-U protocol. [Figure 8] This is a diagram showing the protocol stack for the F1-C protocol. [Figure 9] This diagram shows the operation according to the first embodiment. [Figure 10] This figure shows the protocol stack during handover command transmission according to the first embodiment. [Figure 11] This is a diagram illustrating the upstream relay operation according to the second embodiment. [Figure 12] This figure shows the upstream relay operation according to the second embodiment. [Figure 13] This is a diagram illustrating the downstream relay operation according to the second embodiment. [Figure 14] This figure shows the downstream relay operation according to the second embodiment. [Figure 15] This figure shows the operation of the modified example 1 of the second embodiment. [Figure 16] This figure shows the operation of the modified example 2 of the second embodiment. [Figure 17]This is a diagram showing the type of BH RLF notification. [Figure 18] This is a diagram showing a specific solution for avoiding re-establishment to descendant nodes. [Figure 19] This is a diagram showing a comparison of the mechanisms for lossless delivery of UL data in the case of hop-by-hop RLC ARQ. [Figure 20] This is a diagram showing options for the introduction of UL status delivery.

Mode for Carrying out the Invention

[0009] A cellular communication system according to an embodiment will be described while referring to the drawings. In the description of the drawings, the same or similar parts are denoted by the same or similar reference numerals.

[0010] (Configuration of the Cellular Communication System) First, the configuration of the cellular communication system according to the embodiment will be described. FIG. 1 is a diagram showing the configuration of a cellular communication system 1 according to the embodiment.

[0011] The cellular communication system 1 is a fifth-generation (5G) cellular communication system based on the 3GPP standard. Specifically, the radio access method in the cellular communication system 1 is NR (New Radio), which is a 5G radio access method. However, LTE (Long Term Evolution) may be at least partially applied to the cellular communication system 1.

[0012] As shown in FIG. 1, the cellular communication system 1 includes a 5G core network (5GC) 10, a user equipment (UE: User Equipment) 100, a base station (referred to as gNB) 200, and an IAB node 300. The IAB node 300 is an example of a relay node.

[0013] In the following, an example in which the base station is an NR base station will be mainly described, but the base station may be an LTE base station (i.e., eNB).

[0014] 5GC 10 has an AMF (Access and Mobility Management Function) 11 and a UPF (User Plane Function) 12. The AMF 11 is a device that performs various mobility controls and the like for the UE 100. The AMF 11 manages information on the area where the UE 100 is located by communicating with the UE 100 using NAS (Non-Access Stratum) signaling. The UPF 12 is a device that performs transfer control of user data and the like.

[0015] Each gNB 200 is a fixed radio communication node that manages one or more cells. A cell is a term used to indicate the smallest unit of a radio communication area. A cell may be a term used to indicate a function or resource for performing radio communication with the UE 100. One cell belongs to one carrier frequency.

[0016] Each gNB 200 is interconnected with the 5GC 10 via an interface called the NG interface. In FIG. 1, two gNBs 200-1 and 200-2 connected to the 5GC 10 are illustrated.

[0017] Each gNB 200 is interconnected with another gNB 200 in an adjacent relationship via a base station-to-base station interface called the Xn interface. In FIG. 1, an example in which the gNB 200-1 is connected to the gNB 200-2 is shown.

[0018] Each gNB 200 may be divided into a Central Unit (CU) and a Distributed Unit (DU). The CU and the DU are interconnected via an interface called the F1 interface. The F1 protocol is a communication protocol between the CU and the DU, and there are an F1-C protocol which is a protocol of the control plane and an F1-U protocol which is a protocol of the user plane.

[0019] Cellular communication system 1 supports IAB, which enables wireless relay of NR access using NR for backhaul. Donor gNB200-1 is the network-side NR backhaul termination node and is a donor base station with additional functions to support IAB. The backhaul can be multi-hop, via multiple hops (i.e., multiple IAB nodes 300).

[0020] Figure 1 shows an example where IAB node 300-1 is wirelessly connected to donor gNB200-1, and IAB node 300-2 is wirelessly connected to IAB node 300-1, with the F1 protocol being transmitted over two backhaul hops.

[0021] The UE100 is a mobile wireless communication device that communicates wirelessly with a cell. The UE100 can be any device that communicates wirelessly with the gNB200 or IAB node 300. For example, the UE100 can be a mobile phone terminal, tablet terminal, notebook PC, sensor or device installed on a sensor, vehicle or device installed on a vehicle. The UE100 connects wirelessly to the IAB node 300 or gNB200 via an access link. Figure 1 shows an example of the UE100 connecting wirelessly to IAB node 300-2. The UE100 communicates indirectly with the donor gNB200-1 via IAB node 300-2 and IAB node 300-1.

[0022] Figure 2 shows the relationship between IAB node 300, parent nodes, and child nodes.

[0023] As shown in Figure 2, each IAB node 300 has an IAB-DU, which corresponds to the base station function unit, and an IAB-MT (Mobile Termination), which corresponds to the user equipment function unit.

[0024] On the IAB-MT's NR Uu radio interface, adjacent nodes (i.e., higher-level nodes) are called parent nodes. A parent node is either a parent IAB node or the DU of a donor gNB200. The radio link between the IAB-MT and the parent node is called a backhaul link (BH link). Figure 2 shows an example where the parent nodes of IAB node 300 are IAB nodes 300P1 and 300P2. The direction toward the parent node is called upstream. From the perspective of UE100, the higher-level node of UE100 may be a parent node.

[0025] Adjacent nodes (i.e., lower-level nodes) on the NR access interface of an IAB-DU are called child nodes. The IAB-DU manages cells, similar to the gNB200. The IAB-DU terminates the NR Uu radio interface to the UE100 and lower-level IAB nodes. The IAB-DU supports the F1 protocol to the CU of the donor gNB200-1. Figure 2 shows an example where the child nodes of IAB node 300 are IAB nodes 300C1 to 300C3, but the child nodes of IAB node 300 may also include the UE100. The direction toward child nodes is called downstream.

[0026] (Base station configuration) Next, the configuration of the base station gNB200 according to the embodiment will be described. Figure 3 is a diagram showing the configuration of gNB200. As shown in Figure 3, gNB200 has a wireless communication unit 210, a network communication unit 220, and a control unit 230.

[0027] The wireless communication unit 210 performs wireless communication with the UE 100 and the IAB node 300. The wireless communication unit 210 includes a receiving unit 211 and a transmitting unit 212. The receiving unit 211 performs various types of reception under the control of the control unit 230. The receiving unit 211 includes an antenna and converts the wireless signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 230. The transmitting unit 212 performs various types of transmission under the control of the control unit 230. The transmitting unit 212 includes an antenna and converts the baseband signal (transmitted signal) output by the control unit 230 into a wireless signal and transmits it from the antenna.

[0028] The network communication unit 220 performs wired (or wireless) communication with 5GC10 and with other adjacent gNB200s. The network communication unit 220 has a receiving unit 221 and a transmitting unit 222. The receiving unit 221 performs various types of reception under the control of the control unit 230. The receiving unit 221 receives signals from the outside and outputs the received signals to the control unit 230. The transmitting unit 222 performs various types of transmission under the control of the control unit 230. The transmitting unit 222 transmits the transmission signals output by the control unit 230 to the outside.

[0029] The control unit 230 performs various controls in the gNB200. The control unit 230 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs executed by the processor and information used for processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in memory and performs various processing. The processor performs processing for each layer described later.

[0030] (Configuration of relay nodes) Next, the configuration of the IAB node 300, which is a relay node according to the embodiment, will be described. Figure 4 is a diagram showing the configuration of the IAB node 300. As shown in Figure 4, the IAB node 300 has a wireless communication unit 310 and a control unit 320. The IAB node 300 may have multiple wireless communication units 310.

[0031] The wireless communication unit 310 performs wireless communication with the gNB200 (BH link) and wireless communication with the UE100 (access link). The wireless communication unit 310 for BH link communication and the wireless communication unit 310 for access link communication may be provided separately.

[0032] The wireless communication unit 310 includes a receiving unit 311 and a transmitting unit 312. The receiving unit 311 performs various types of reception under the control of the control unit 320. The receiving unit 311 includes an antenna and converts the wireless signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 320. The transmitting unit 312 performs various types of transmission under the control of the control unit 320. The transmitting unit 312 includes an antenna and converts the baseband signal (transmitted signal) output by the control unit 320 into a wireless signal and transmits it from the antenna.

[0033] The control unit 320 performs various controls on the IAB node 300. The control unit 320 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs executed by the processor and information used for processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in memory and performs various processing. The processor performs processing for each layer described later.

[0034] (User device configuration) Next, the configuration of the user device UE100 according to the embodiment will be described. Figure 5 is a diagram showing the configuration of UE100. As shown in Figure 5, UE100 has a wireless communication unit 110 and a control unit 120.

[0035] The wireless communication unit 110 performs wireless communication on the access link, i.e., wireless communication with the gNB200 and wireless communication with the IAB node 300. The wireless communication unit 110 may also perform wireless communication on the side link, i.e., wireless communication with other UE100s. The wireless communication unit 110 has a receiving unit 111 and a transmitting unit 112. The receiving unit 111 performs various types of reception under the control of the control unit 120. The receiving unit 111 includes an antenna and converts the wireless signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 120. The transmitting unit 112 performs various types of transmission under the control of the control unit 120. The transmitting unit 112 includes an antenna and converts the baseband signal (transmitted signal) output by the control unit 120 into a wireless signal and transmits it from the antenna.

[0036] The control unit 120 performs various controls on the UE 100. The control unit 120 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs executed by the processor and information used for processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in memory and performs various processing. The processor performs processing for each layer described later.

[0037] (Protocol stack configuration) Next, the configuration of the protocol stack according to the embodiment will be described. Figure 6 is a diagram showing the protocol stack for IAB-MT RRC connection and NAS connection.

[0038] As shown in Figure 6, the IAB-MT of IAB node 300-2 has a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, a PDCP (Packet Data Convergence Protocol) layer, an RRC (Radio Resource Control) layer, and a NAS (Non-Access Stratum) layer.

[0039] The PHY layer performs encoding and decoding, modulation and demodulation, antenna mapping and demapping, and resource mapping and demapping. Data and control information are transmitted between the PHY layer of IAB-MT at IAB node 300-2 and the PHY layer of IAB-DU at IAB node 300-1 via a physical channel.

[0040] The MAC layer performs data priority control, retransmission processing using Hybrid ARQ (Automatic Repeat Request) (HARQ), and random access procedures. Data and control information are transmitted between the MAC layer of IAB-MT on IAB node 300-2 and the MAC layer of IAB-DU on IAB node 300-1 via the transport channel. The MAC layer of IAB-DU includes a scheduler. The scheduler determines the transport format (transport block size, modulation and coding scheme (MCS)) and allocated resource blocks for the up and down links.

[0041] The RLC layer uses the functions of the MAC layer and PHY layer to transmit data to the receiving RLC layer. Data and control information are transmitted between the RLC layer of IAB-MT on IAB node 300-2 and the RLC layer of IAB-DU on IAB node 300-1 via a logical channel.

[0042] The PDCP layer performs header compression / decompression, and encryption / decryption. Data and control information are transmitted between the PDCP layer of IAB-MT on IAB node 300-2 and the PDCP layer of donor gNB200 via a wireless bearer.

[0043] The RRC layer controls the logical channel, transport channel, and physical channel in response to the establishment, re-establishment, and release of the radio bearer. RRC signaling for various settings is transmitted between the RRC layer of the IAB-MT on IAB node 300-2 and the RRC layer of the donor gNB200. When an RRC connection is established with the donor gNB200, the IAB-MT is in the RRC connected state. When there is no RRC connection with the donor gNB200, the IAB-MT is in the RRC idle state.

[0044] The NAS layer, located above the RRC layer, handles session management and mobility management, among other things. NAS signaling is transmitted between the NAS layer of IAB-MT on IAB node 300-2 and AMF11.

[0045] Figure 7 shows the protocol stack for the F1-U protocol. Figure 8 shows the protocol stack for the F1-C protocol. Here, an example is shown where the donor gNB200 is divided into CU and DU.

[0046] As shown in Figure 7, each of the IAB-MT on IAB node 300-2, the IAB-DU on IAB node 300-1, the IAB-MT on IAB node 300-1, and the DU on donor gNB200 each have a BAP (Backhaul Adaptation Protocol) layer as a layer above the RLC layer. The BAP layer is the layer that performs routing and bearer mapping / demapping. In backhaul, the IP (Internet Protocol) layer is transmitted through the BAP layer, enabling routing across multiple hops.

[0047] In each backhaul link, BAP layer PDUs (Protocol Data Units) are transmitted via backhaul RLC channels (BH NR RLC channels). By configuring multiple backhaul RLC channels in each BH link, traffic prioritization and QoS (Quality of Service) control are possible. The mapping between BAP PDUs and backhaul RLC channels is performed by the BAP layer of each IAB node 300 and the BAP layer of the donor gNB200.

[0048] As shown in Figure 8, the F1-C protocol stack has an F1AP (Application Protocol) layer and an SCTP (Stream Control Transmission Protocol) layer instead of the GTP-U (GPRS Tunnelling Protocol for User Plane) layer and UDP (User Datagram Protocol) layer shown in Figure 7.

[0049] (First Embodiment) Next, assuming the configuration of the cellular communication system 1 described above, the operation of the cellular communication system 1 will be explained.

[0050] In the first embodiment, we assume a scenario in which an IAB node 300 (specifically, an IAB-MT) performs a connection switch between donor gNB200s. The IAB node 300 may be a mobile IAB node 300. Connection switch refers to either a handover or RRC re-establishment. Handover refers to the operation in which an IAB-MT in an RRC connected state switches cells. RRC re-establishment refers to the operation in which an IAB-MT in an RRC connected state reconnects to another cell in response to the detection of a radio link failure. Below, we will describe an example in which the connection switch is a handover, but the connection switch may also be an RRC re-establishment.

[0051] In a scenario where IAB node 300 performs a connection switch between donor gNB200s, the operation of UE100 under this IAB node 300 becomes an issue. Specifically, when IAB node 300 performs a connection switch between donor gNB200s, new operation may be required of UE100 under this IAB node 300. However, from a backward compatibility standpoint, it is undesirable to change the operation of UE100.

[0052] The first embodiment is an example in which the connection switching of IAB nodes 300 between donor gNB200s (e.g., handover) is achieved transparently to the UE100 side, simply by changing the operation on the network side (IAB node side). Such a handover may also be called an interCU handover.

[0053] Specifically, in the first embodiment, firstly, the IAB node 300 having UE100 under its control performs a handover from the first donor base station, source donor gNB200S, to a second donor base station, target donor gNB200T, which is different from the first donor base station. Secondly, even after the handover, the RRC connection between UE100 and source donor gNB200S is maintained via target donor gNB200T. Thirdly, source donor gNB200S uses the RRC connection to send a handover command to UE100 via target donor gNB200T, instructing a handover to target donor gNB200T.

[0054] In other words, the RRC connection (and PDCP connection) between UE100 and source donor gNB200 remains established via target donor gNB200, and source donor gNB200S uses this connection to send a handover command to UE100. This enables the handover of IAB node 300 between donor gNB200s without requiring any operational changes to UE100.

[0055] In the first embodiment, a data path may be established between the source donor gNB200S and the target donor gNB200T. From the handover of the IAB node 300 to the completion of the handover of the UE100, data transfer processing (i.e., data forwarding) of the UE100 may be performed through this data path. This prevents data loss in the UE100 even if the handover of the IAB node 300 is performed first and then the handover of the UE100.

[0056] Figure 9 shows the operation according to the first embodiment.

[0057] As shown in Figure 9, in step S101, UE100 is in a state where it has established an RRC connection with the source donor gNB200S (RRC connected state).

[0058] In step S102, IAB node 300 (IAB-MT) is in a state where it has established an RRC connection with source donor gNB200S (RRC connected state). At least one intermediate IAB node may be interposed between IAB node 300 and source donor gNB200S. UE100 is under the control of IAB node 300 (IAB-DU). That is, UE100 uses the cell of IAB node 300 (IAB-DU) as its serving cell.

[0059] In step S103, IAB node 300 (IAB-MT) performs either RRC reestablishment or handover from source donor gNB200S to target donor gNB200T. Here, we will proceed assuming that IAB node 300 (IAB-MT) performs a handover.

[0060] In step S104, IAB node 300 (IAB-MT) establishes an RRC connection with the target donor gNB200T as a result of the handover.

[0061] At this point, the RRC and PDCP layers of the UE100 still maintain a connection with the source donor gNB200S. Therefore, the UE100 cannot communicate with the target donor gNB200T using either the C-plane or the U-plane.

[0062] Here, a tunnel (i.e., a data forwarding path) is formed between the source donor gNB200S and the target donor gNB200T. This tunnel may be established over the inter-base station interface or via the core network.

[0063] In step S105, UE100 sends uplink user data to IAB node 300. IAB node 300 receives the user data.

[0064] In step S106, the IAB node 300 sends user data from UE100 to the target donor gNB200T. The target donor gNB200T receives the user data.

[0065] In step S107, the target donor gNB200T forwards the user data received in step S106 to the source donor gNB200S (data forwarding). The source donor gNB200S receives the user data.

[0066] In step S108, the source donor gNB200S forwards the user data received in step S107 to UPF12 of the core network.

[0067] In step S109, the source donor gNB200S receives downlink user data from the core network's UPF12.

[0068] In step S110, the source donor gNB200S forwards the user data received in step S109 to the target donor gNB200T (data forwarding). The target donor gNB200T receives the user data.

[0069] In step S111, the target donor gNB200T transfers the user data received in step S110 to the IAB node 300. The IAB node 300 receives the user data.

[0070] In step S112, the IAB node 300 transmits (relays) the user data received in step S111 to the UE100.

[0071] Thus, the transmission and reception of user data between UE100 and source donor gNB200S continues via the tunnel between source donor gNB200S and target donor gNB200T, and through the target donor gNB200T.

[0072] In step S113, source donor gNB200S transmits a handover command (HO Command) to target donor gNB200T via the tunnel between source donor gNB200S and target donor gNB200T, instructing UE100 to hand over to target donor gNB200T. Target donor gNB200 receives the handover command.

[0073] In step S114, the target donor gNB200T sends an RRC message (RRC Reconfiguration) containing the handover command received in step S113 to the UE100. Specifically, the target donor gNB200T sends the RRC message to the UE100 via the IAB node 300. The UE100 receives the RRC message.

[0074] Figure 10 shows the protocol stack during handover command transmission. As shown in Figure 10, a handover command (RRC Reconfiguration) is transmitted from the RRC layer of the source donor gNB200S to the RRC layer of UE100 via the target donor gNB200T and IAB node 300. Communication between the source donor gNB200S and the target donor gNB200T is performed via inter-base station communication. Figure 9 shows an example of GTP, but is not limited to this. For example, Xn-AP may also be used, in which case the handover command is transmitted enclosed (encapsulated) within the RRC container of the Xn-AP message.

[0075] Returning to Figure 9, in step S115, UE100 sends an RRC message (RRC Reconfiguration Complete) to the target donor gNB200T in response to the handover command, indicating that the handover is complete. Specifically, UE100 sends the RRC message to the target donor gNB200T via IAB node 300. The target donor gNB200T receives the RRC message. Here, since UE100 remains under the control of IAB node 300, it may perform a RACH-less handover, omitting the transmission of the random access preamble and the reception of the random access response. In this case, RACH-less handover may be instructed to UE100 in the handover command.

[0076] In step S116, UE100 establishes an RRC connection with the target donor gNB200T as a result of the handover. From this point onward, the user data of UE100 switches to communication with the target donor gNB200T.

[0077] In step S117, UE100 sends uplink user data to IAB node 300. IAB node 300 receives the user data.

[0078] In step S118, the IAB node 300 transmits the user data received in step S117 to the target donor gNB200T. The target donor gNB200T receives the user data.

[0079] In step S119, the target donor gNB200T forwards the user data received in step S118 to UPF12 of the core network.

[0080] In step S120, the target donor gNB200T receives downlink user data from the core network's UPF12.

[0081] In step S121, the target donor gNB200T transfers the user data received in step S120 to the IAB node 300. The IAB node 300 receives the user data.

[0082] In step S122, the IAB node 300 transmits (relays) the user data received in step S121 to the UE100.

[0083] (Second Embodiment) Next, the differences between the second embodiment and the embodiment described above will be explained.

[0084] The second embodiment relates to load balancing within an IAB topology. The paths within the IAB topology are semi-fixed, determined by a routing table (BAP routing ID and path ID) for the IAB node 300, and the CU of the donor gNB200 centrally manages the routing table. However, it is believed that more dynamic load balancing would be possible if multiple paths could be used efficiently.

[0085] In the second embodiment, the IAB node 300 performs efficient data relay by considering the data relay capacity of each of the multiple destination nodes (multiple paths). Specifically, in the second embodiment, the IAB node 300 that relays data from the source node to multiple destination nodes receives capacity information regarding the data relay capacity of the target IAB node 300 included in the multiple destination nodes. The IAB node 300 then controls data relay based on the received capacity information.

[0086] Capacity information may include information indicating whether there are multiple nodes at the next hop of the target IAB node 300, which is included in multiple relay destination nodes. If there are multiple nodes at the next hop of the target IAB node 300, the target IAB node 300 can be considered to have a large data relay capacity. Therefore, by prioritizing data relay to such a target IAB node 300, multiple paths can be used efficiently.

[0087] The IAB node 300 may receive capacity information for each of the multiple destination nodes and control the data transmission ratio to the multiple destination nodes based on the received capacity information. For example, the IAB node 300 may relay more data to destination nodes with large data relay capacity and less data to other destination nodes with small data relay capacity.

[0088] As described above, the IAB node 300 selects a data relay destination from among multiple relay nodes according to the routing settings (routing table) configured by the donor gNB200. The IAB node 300 may perform local routing, selecting a data relay destination without following the routing settings, if certain conditions are met. Here, the predetermined conditions may include the condition that a failure notification or local routing request has been received from one of the multiple relay nodes.

[0089] In this way, the IAB node 300 basically performs routing according to the settings from the donor gNB200S, and in the event of a failure at a relay node or a request arises, the IAB node 300 itself performs local routing, enabling it to relay data to the appropriate relay node depending on the situation.

[0090] (1) Upstream relay operation The upstream relay operation according to the second embodiment will be described below.

[0091] Figure 11 is a diagram illustrating the upstream relay operation according to the second embodiment. In the upstream relay operation, the source node of IAB node 300 is a child node of IAB node 300, and the destination node of IAB node 300 is the parent node of IAB node 300.

[0092] As shown in Figure 11, an IAB topology is formed that includes IAB node 300, other IAB nodes 300a to 300g, and donor gNB200. IAB node 300 receives uplink packets (UL packets) from child nodes (which may be UE100). Based on the routing settings configured by donor gNB200 and the information contained in the header of the uplink packet (BAP routing ID), IAB node 300 forwards the received uplink packets to the parent nodes, IAB node 300a and / or IAB node 300b.

[0093] Each IAB node 300a through 300g sends information to its child nodes indicating whether there are multiple nodes at the next hop, as capacity information for its node. In upstream relay operation, this capacity information is called "BH connection information." Specific examples of BH connection information will be described later. By each IAB node 300 sending this BH connection information to its child nodes, the child nodes can understand the potential capacity of their parent nodes, enabling efficient data relay during local routing.

[0094] A back hub (BH) where the next hop node to the local node is one node is called a "single BH," and a BH where the next hop node to the local node is two nodes is called a "dual BH." In the example in Figure 11, IAB nodes 300b, 300c, 300e, 300f, and 300g are all single BHs. On the other hand, IAB nodes 300a and 300d are both dual BHs and can be considered to have a larger data relay capacity than single BHs. Note that a dual BH may also be a state where dual connectivity has been established to create duplicate connections.

[0095] For example, IAB node 300 determines the transmit ratio based on the BH connection information of its parent nodes (IAB nodes 300a and 300b). Since IAB node 300a is a dual BH and IAB node 300b is a single BH, the total number of BH links for the parent nodes is 3. Therefore, when performing local routing, IAB node 300 sets the transmit ratio for IAB node 300a to "2 / 3" and the transmit ratio for IAB node 300b to the remaining "1 / 3". Alternatively, the transmit ratio for a parent node may be set to zero. In this case, the determination of the transmit ratio can be considered as path selection (path switching).

[0096] Figure 12 shows the upstream relay operation according to the second embodiment. This operation is performed by the IAB node 300, and at least a portion of it may be performed by the BAP layer and / or IAB-MT.

[0097] As shown in Figure 12, in step S201, the IAB node 300 performs routing based on the routing settings configured by the donor gNB200.

[0098] In step S202, the IAB node 300 determines whether the conditions for initiating local routing have been met. For example, the initiation conditions are one of the following. The parameters (thresholds, etc.) that define the initiation conditions may be set from the donor gNB200 to the IAB node 300.

[0099] • The condition that a BH failure notification has been received from the parent node: For example, a BH failure notification from the parent node is sent from the parent node to the IAB node 300 via a BH RLF Indication message in the BAP layer. The BH failure notification may indicate that an RLF (Radio Link Failure) has occurred in the parent node's BH, that the parent node is in the process of recovering from the RLF of the BH, or that the recovery from the RLF of the parent node's BH has failed.

[0100] • The condition that the uplink throughput to a certain parent node falls below a certain level: For example, this condition may be met if a scheduling request (SR) sent by IAB node 300 to a parent node is ignored a certain number of times or more (for example, no uplink grant is received). This condition may also be met if, when comparing the uplink throughput of parent nodes, a difference (bias) of a certain amount or more occurs in the uplink throughput over a certain period of time (and this condition continues for a certain period of time or longer). This condition may also be met if the uplink throughput of a parent node falls below a certain value (and this condition continues for a certain period of time or longer).

[0101] • The condition that a local routing request has been received from the parent node: A local routing request may be sent from the parent node via a BAP layer message. Alternatively, a local routing request may be sent from the donor gNB200 via the parent node via an F1 message or an RRC message. The IAB node 300 may send a response to the local routing request from the parent node, or it may notify the parent node of the transmission ratio described below.

[0102] The local routing request may include an identifier for the bearer (or RLC channel, or logical channel) to which local routing is to be performed. IAB node 300 performs local routing for the target bearer (or RLC channel, or logical channel) and does not perform local routing for the other bearers (or RLC channels, or logical channels) (i.e., it performs routing according to the routing table).

[0103] The condition is that the uplink buffer size of IAB node 300 or its child nodes exceeds a certain level (and this condition persists for a certain period of time or longer): For example, IAB node 300 can determine the uplink buffer amount of a child node based on the Buffer Status Report (BSR) received from the child node. The BSR may also take into account the uplink buffer amount of the child node's further child nodes (i.e., grandchild nodes). This condition may be met when the uplink buffer amount indicated by the BSR exceeds a certain level (and that state continues for a certain period of time or longer).

[0104] If the conditions for initiating local routing are not met (step S202: No), IAB node 300 continues routing based on the routing configuration set by donor gNB200 (step S201).

[0105] On the other hand, if the conditions for initiating local routing are met (step S202: Yes), IAB node 300 will begin operations related to local routing. IAB node 300 may only be able to perform local routing if it has been authorized by donor gNB200. This authorization is granted via BAP layer messages (BAP Control PDU), system information (SIB1), or RRC Reconfiguration, etc. Whether or not local routing can be performed may be set for each bearer (RLC channel) or for all bearers at once. Along with such settings, it may be possible to specify which of the above conditions to apply and the threshold used to determine those conditions.

[0106] In step S203, the IAB node 300 receives BH connection information from each parent node. Note that step S203 may be performed before step S202.

[0107] The parent node's BH connection information may include information indicating whether the parent node is a single BH, a dual BH, or a triple BH. The parent node's BH connection information may also include a numerical value indicating the number of BHs in the parent node. The BH connection information may further include information regarding the capacity of each BH link. The information regarding the capacity of each BH link may, for example, indicate at least one of the bandwidth, number of component carriers, and frequency band of each BH link, or it may indicate the average throughput (or maximum throughput, GBR (Guaranteed Bit Rate), etc.) of each BH link.

[0108] BH connection information may be sent from the parent node to the IAB node 300. For example, BH connection information may be an information element included in the BAP Control PDU or system information (e.g., SIB1) sent by the parent node. The parent node may send BH connection information if it is a dual BH (or triple BH), and not send BH connection information if it is a single BH. The IAB node 300 determines whether it is a single BH or a dual BH based on whether or not BH connection information is sent.

[0109] Alternatively, BH connection information may be sent from donor gNB200 to IAB node 300. This information may also be included as an element in an RRC message (e.g., RRC Reconfiguration) or F1 message (e.g., DL Information Transfer) sent by donor gNB200.

[0110] In step S204, the IAB node 300 determines the packet transmission ratio for the uplink based on the BH connection information received in step S203. As in the example above, if one parent node is a dual BH and the other parent node is a single BH, the IAB node 300 sets the transmission ratio to one parent node to "2 / 3" and the transmission ratio to the other parent node to "1 / 3". Here, for example, if the transmission ratio is set to 0:1, it is considered that the destination has been switched (locally switched). The IAB node 300 may adjust or determine the transmission ratio based on the information contained in the BH connection information (for example, information on the capacity of each BH link). The IAB node 300 may also adjust or determine the transmission ratio based on the past transmission throughput history for each parent node (or the uplink grant history to child nodes (i.e., receive throughput)).

[0111] In step S205, the IAB node 300 performs local routing of uplink packets based on the transmission ratio determined (and adjusted) in step S204. The IAB node 300 may modify the header of the uplink packets that have been locally routed. For example, it may modify the routing ID in the BAP header, or add an identifier indicating that local routing has been performed.

[0112] In step S206, the IAB node 300 determines whether the termination conditions for local routing have been met. The termination conditions can be the inverse of the initiation conditions described above. For example, at least one of the following conditions may be received: a notification of successful recovery of the BH from the parent node; throughput to a certain parent has been restored; a request to stop local routing has been received; and the buffer state of the child node (and grandchild node) has improved. The termination conditions may also include the condition that local routing permission has been revoked (set to denial) by the donor gNB200.

[0113] If the local routing termination condition is not met (step S206: No), IAB node 300 continues local routing (step S205). On the other hand, if the local routing termination condition is met (step S206: Yes), IAB node 300 performs routing based on the routing configuration set by donor gNB200 (step S201).

[0114] (2) Downstream relay operation The downstream relay operation according to the second embodiment will be described.

[0115] Figure 13 is a diagram illustrating the downstream relay operation according to the second embodiment. In the downstream relay operation, the source node of the IAB node 300 is the parent node of the IAB node 300, and the destination node of the IAB node 300 is the child node of the IAB node 300. In the downstream relay operation, the parent node and child node from the upstream relay operation described above are swapped. Note that Figure 13 shows an example in which each IAB node 300 is a dual BH and there are four paths between the IAB node 300 and the destination node.

[0116] Figure 14 shows the downstream relay operation according to the second embodiment. This operation is performed by the IAB node 300, and at least a portion of it may be performed by the BAP layer and / or IAB-DU. Here, we will mainly explain the differences from the upstream relay operation.

[0117] As shown in Figure 14, in step S301, the IAB node 300 performs routing based on the routing settings configured by the donor gNB200.

[0118] In step S302, the IAB node 300 determines whether the conditions for initiating local routing have been met. For example, the initiation conditions may be one of the following. Parameters (thresholds, etc.) that define the initiation conditions may be set from the donor gNB200 to the IAB node 300. The IAB node 300 may only be able to perform local routing if local routing is permitted (configured) from the donor gNB200. This permission may be given by an F1 message (F1AP), an RRC message, or a BAP message. This permission may be set for each bearer (RLC channel) or for all bearers at once. This permission may also be an instruction. In addition, it may be set which of the following conditions to apply and the threshold used to determine that condition.

[0119] This condition occurs when the throughput of a particular path falls below a certain level (and this condition persists for a certain period of time or longer).

[0120] The condition is that the wireless status of a child node deteriorates (and this condition persists for a certain period of time or longer): For example, the IAB node 300 may determine the wireless status from measurement reports from child nodes and / or scheduling results (such as MCS) for child nodes.

[0121] The condition is that the available buffer size of a child node falls below a certain level (and this condition persists for a certain period of time or longer): For example, the IAB-DU of IAB node 300 sends a Flow control polling BAP Control PDU to its child nodes and receives a Flow control feedback BAP Control PDU from the child nodes. Then, IAB node 300 (IAB-DU) identifies and determines the available buffer size (amount of free buffer) indicated by the Flow control feedback BAP Control PDU.

[0122] If the conditions for initiating local routing are not met (step S302: No), IAB node 300 continues routing based on the routing configuration set by donor gNB200 (step S301).

[0123] On the other hand, if the conditions for initiating local routing are met (step S302: Yes), IAB node 300 begins operations related to local routing. IAB node 300 may select a different path with the same destination from the routing configuration and send the downlink packet to the IAB node corresponding to that path. IAB node 300 may also modify the header of the downlink packet that has undergone local routing. For example, the routing ID may be changed in the BAP header, or an identifier indicating that local routing has been performed may be added.

[0124] In step S303, the IAB node 300 may receive available buffer size information from each child node.

[0125] In step S304, the IAB node 300 determines the selection of a downstream path and / or the transmission ratio to the child node. Specifically, the IAB node 300 selects other paths with the same destination from the stored routing configurations. The IAB node 300 may select multiple paths, in which case the transmission ratio may be determined in the same manner as the upstream relay operation described above. A set of selectable path combinations may be preconfigured from the donor gNB200 to the IAB node 300.

[0126] In step S305, the IAB node 300 performs local routing according to the result of step S304.

[0127] In step S306, the IAB node 300 determines whether the termination conditions for local routing have been met. The termination conditions can be the inverse of the initiation conditions described above. For example, at least one of the following conditions may be met: the throughput of a certain path has recovered to a certain level or higher; the wireless status of the child node has recovered to a certain level or higher; or the available buffer size of the child node has recovered to a certain level or higher. The termination conditions may also include the condition that local routing permission has been revoked (set to denial) by the donor gNB200.

[0128] If the local routing termination conditions are not met (step S306: No), IAB node 300 continues local routing (step S305). On the other hand, if the local routing termination conditions are met (step S306: Yes), IAB node 300 performs routing based on the routing configuration set by donor gNB200 (step S301).

[0129] (Example of modification of the second embodiment 1) Next, we will mainly explain the differences between the first modified example of the second embodiment and the embodiment described above.

[0130] In the second embodiment described above, the donor gNB200 may not be able to ascertain the details of the local routing performed by the IAB node 300 (when and how many times it was performed). When local routing is performed, it may indicate a problem with the routing configuration by the donor gNB200 or a failure within the IAB topology. For this reason, it is preferable that the donor gNB200 be able to ascertain the details of the local routing. This would allow the donor gNB200 to optimize the routing configuration, for example.

[0131] In this modification example, the IAB node 300, which relays data from the source node to multiple destination nodes, selects a data relay destination from among the multiple destination nodes according to the routing settings configured by the donor gNB200. If certain conditions are met, the IAB node 300 performs local routing, selecting a data relay destination without following the routing settings (see the second embodiment). The IAB node 300 sends historical information regarding this local routing (i.e., information indicating the content of the local routing) to the donor gNB200.

[0132] Figure 15 shows the operation of the modified example 1 of the second embodiment.

[0133] As shown in Figure 15, in step S401, the IAB node 300 performs local routing.

[0134] In step S402, the IAB node 300 saves the information (local routing information) related to the local routing performed in step S401. The IAB node 300 saves the local routing information each time local routing is performed.

[0135] Local routing information may include at least one of the following: a timestamp indicating the time the local routing was performed, location information (latitude, longitude, altitude) indicating the time the local routing was performed, and information indicating the radio conditions at the time the local routing was performed. Local routing information may also include routing IDs (path ID and destination) before and after the change made by local routing. Local routing information may also include the topology ID of the connected IAB topology (donor gNB ID, or gNB-CU ID). Local routing information may also include information indicating the reason (or conditions) for performing local routing. Local routing information may also include information indicating the period during which local routing was performed (start time, end time) and / or the number of times local routing was performed. Local routing information may be stored at the BAP layer, or it may be reported from the BAP layer to the RRC layer each time and stored at the RRC layer.

[0136] In step S403, the IAB node 300 sends the local routing information saved in step S402 to the donor gNB200. The local routing information is sent from the IAB node 300, for example, by an RRC message. This local routing information may also be sent as a response message in response to a request from the donor gNB200. For example, this local routing information may be sent as a UE Information Response to a UE Information Request.

[0137] (Example of modification of the second embodiment 2) Next, we will mainly describe the differences between the above-described embodiment and the modified example 2 of the second embodiment. This modified example is an embodiment in which the donor gNB200 changes the routing settings of the IAB node 300 at the request of the IAB node 300.

[0138] In this example of a change, the IAB node 300, which relays data from the source node to multiple destination nodes, selects a data relay destination from among the multiple destination nodes according to the routing settings configured by the donor gNB200. The IAB node 300 sends a routing change request to the donor gNB200 to change the routing settings.

[0139] Figure 16 shows the operation of the modified example 2 of the second embodiment.

[0140] As shown in Figure 16, in step S501, the IAB node 300 sends a routing change request to the donor gNB200. The routing change request may also be a notification that a routing change is desired. The routing change request may be an RRC message or an F1 (F1AP) message. Routing change requests may be defined separately for upstream routing changes and downstream routing changes. The routing change request may only be sent if the donor gNB200 is permitted to send it.

[0141] IAB node 300 may send a routing change request triggered by the fulfillment of the same conditions as those for initiating local routing as described in the second embodiment above. The conditions and thresholds to be used may be configured by donor gNB200 to IAB node 300. IAB node 300 may only send a routing change request if donor gNB200 has permitted (configured) to send routing change requests.

[0142] A routing change request may include at least one of the following: information indicating the reason (or conditions) for the routing configuration change, the routing ID (path ID, destination) to be changed, and the RLC Channel ID (bearer ID, LCID may also be used) to be changed.

[0143] In the case of upstream routing changes, IAB node 300 may include its own BSR value in the routing change request. Alternatively, in the case of dual BH (dual connectivity), IAB node 300 may include the BSR value for each parent node (per path) in the routing change request. IAB node 300 may also include the BSR value of its child nodes, or its own BSR value with the child nodes added to it, in the routing change request. Such transmission of BSR values ​​may be performed periodically by each IAB node 300 in the IAB topology to the donor gNB200.

[0144] In the case of a downstream routing change, the IAB node 300 may include its own available buffer size value and / or the available buffer size values ​​of its child nodes (Flow control feedback BAP Control PDU value) in the routing change request. Such transmission of available buffer size values ​​may be performed periodically by each IAB node 300 in the IAB topology to the donor gNB200.

[0145] In step S502, donor gNB200 modifies the routing configuration of IAB node 300 in response to the routing change request received in step S501. IAB node 300 may perform a handover (i.e., IAB topology change) as necessary.

[0146] Furthermore, the IAB node 300 may start a timer when it sends a routing change request, and may be prohibited from sending the next routing change request until this timer expires. The timer value for this timer may be set by the donor gNB200 for the IAB node 300.

[0147] (Other embodiments) The embodiments and modifications described above can be implemented by combining separate embodiments and modifications. Furthermore, modifications 1 and 2 of the second embodiment may be used in conjunction with the second embodiment or implemented separately from the second embodiment.

[0148] In the embodiments and modifications described above, relay transmission by IAB was used as an example, but the system is not limited to this and may be applied to other relay transmission systems. For example, the operation according to the embodiments and modifications described above may be applied to relay nodes (Layer 3 relay nodes), sidelink relays (relay nodes using sidelinks for direct communication between user devices), etc.

[0149] In the embodiments described above, an example in which the cellular communication system 1 is a 5G cellular communication system was mainly explained. However, the base station in the cellular communication system 1 may be an eNB that is an LTE base station. Also, the core network in the cellular communication system 1 may be an EPC (Evolved Packet Core). Furthermore, a gNB may be connected to an EPC, an eNB may be connected to a 5GC, and the gNB and eNB may be connected via an inter-base station interface (Xn interface, X2 interface).

[0150] A program may be provided that causes a computer to execute each of the processes described in the above-described embodiments and modifications. The program may also be recorded on a computer-readable medium. Using a computer-readable medium, it is possible to install the program on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, but may be a recording medium such as a CD-ROM or DVD-ROM. A chipset may be provided that consists of a memory for storing programs for executing each of the processes performed by the UE100, gNB200, or IAB node 300, and a processor for executing the programs stored in the memory.

[0151] This application claims priority to U.S. Provisional Application No. 63 / 061887 (filed August 6, 2020), the entirety of which is incorporated into the specification of this application.

[0152] (Note) (introduction) A revised work item related to NR eIAB (Enhancements to Integrated Access AND Backhaul) has been approved. Some of its objectives are as follows:

[0153] Extension of topology adaptation • Specifications for procedures for inter-donor IAB node migration to enhance robustness and load balancing, including functional enhancements to reduce signaling load. • Specifications for enhanced features to reduce service interruptions through IAB node migration and BH RLF recovery. • Specifications for extensions to topology redundancy, including support for CP / UP separation. Topology, routing, and transport feature enhancements • Specifications for extensions to improve overall topology fairness, multi-hop latency, and congestion mitigation.

[0154] This addendum discusses the initial considerations for Rel-17 eIAB topology-adaptive extensions in terms of backhaul link quality assumptions, BH RLF indication extensions, BH RLF recovery and cell (re)selection, and lossless delivery extensions.

[0155] (Discussion) (Assumptions for backhaul link quality) During the Rel-15 research phase, TR stated that one of the requirements' backgrounds was that "wireless backhaul links are vulnerable to blockages caused by moving objects such as vehicles, seasonal changes (leaves), and infrastructure changes (new buildings). Such vulnerabilities also apply to physically stationary IAB nodes." Therefore, as captured in TR, various challenges arising from multi-hop / wireless backhaul and their potential solutions were studied.

[0156] Finding 1: The Rel-15 study identified various challenges caused by unstable backhaul links and their potential solutions, which were well captured in TR38.874.

[0157] In the normative work of Rel-16, IAB nodes were assumed to be stationary, i.e., "fixed IAB nodes." Therefore, backhaul (BH) was considered sufficiently stable with a well-designed deployment, even in the case of local area IAB nodes that could be deployed via millimeter-wave backhaul links and / or in uncontrolled manner. Thus, only the basic functions of BH RLF, i.e., recovery procedures combined with existing functions such as BH RLF indication (also known as "recovery failure" type 4) and RRC re-establishment, MCG / SCG failure indication, and / or conditional handover, were specified.

[0158] Finding 2: Rel-16 IAB assumed only fixed IAB nodes with sufficiently stable backhaul links.

[0159] In the Rel-17 extension, one of the intended use cases is "mobile IAB nodes," which may be part of "inter-donor IAB node migration," even if not explicitly stated in the WID. Furthermore, sub-objectives in the WID such as "extensions for reducing service disruption through IAB node migration and BH RLF recovery" and "extensions for topology redundancy" clearly assume that BH links are unstable, and migration and BH RLF occur frequently in Rel-17 deployment scenarios. Therefore, according to the Rel-17 discussion, RAN2 should first have a common understanding of the BH link assumptions.

[0160] Proposal 1: RAN2 should assume that the quality of the backhaul link will change dynamically. Therefore, backhaul RLFs are not rare cases like Rel-17 eIAB.

[0161] (BH RLF indication extension) In the Rel-16 email discussion, four types of BH RLF notifications, as shown in Figure 17, were discussed.

[0162] Finally, only Type 4 "Recovery Failure" is defined as a BH RLF indication in Rel-16, which causes the child IAB-MT to consider the RLF on the BH link and initiate the RLF recovery procedure.

[0163] Finding 3: In Rel-16, only type 4 "recovery impairment" was defined as a BH RLF indication.

[0164] On the other hand, many companies still believed other types of indications would be beneficial, so this was further discussed via email. Eight out of thirteen companies preferred to implement a Type 2 "Attempting Recovery" indication, while the other two believed it would be discussed in Rel-17. Therefore, it can be concluded that the majority of companies are ready to implement Type 2 indications in Rel-17. Further consideration is needed regarding how to send Type 2 indications, such as by using BAP Control PDUs, SIB1s, or both. Note that Type 1 and Type 2 have exactly the same meaning.

[0165] Proposal 2: RAN2 should agree that a Type 2 "Attempting Recovery" BH RLF indication should be implemented. Further consideration is needed as to whether it should be transmitted via the BAP Control PDU, SIB1, or both.

[0166] Furthermore, nine out of thirteen companies agreed to discuss Type 3 "BH link recovery" in Rel-17. In detail, it may be considered whether such explicit indications are truly necessary. For example, if a Type 2 indication is transmitted via SIB1, the indication will not be broadcast if the BH link is not under the RLF (i.e., "recovered"). Thus, downstream IAB nodes and UEs will know whether the BH link has recovered based on the absence of a Type 2 indication in SIB1. Of course, if a Type 3 indication is transmitted via the BAP Control PDU, there is the advantage that downstream IAB nodes can quickly know of BH link recovery. However, in this case, the UE will not know the fact because it does not have a BAP layer. Therefore, RAN2 should discuss whether a Type 3 indication is necessary.

[0167] Proposal 3: If Proposal 3 can be agreed upon, RAN2 should discuss whether an explicit BH RLF indication should be introduced when a BH RLF is lost, i.e., a Type 3 "BH link recovery".

[0168] If Proposal 2 and / or Proposal 3 can be agreed upon, the behavior of the IAB-MT upon receiving the indication under BH link recovery should be considered. It has been proposed that the IAB-MT reduce / stop SRs upon receiving Type 2 and resume operation upon receiving Type 3 (i.e., no BH RLFs at the parent IAB node). This is one of the desirable behaviors for the IAB-MT when the parent node attempts to recover the BH link. Other IAB-MT behaviors, such as suspending all RBs, are also assumed to be possible.

[0169] Proposal 4: RAN2 should agree to reduce / stop scheduling requests after IAB-MT receives a Type 2 indication, and resume scheduling requests when there are no more BH RLFs on the parent node.

[0170] Proposal 5: RAN2 should be discussed if there are other IAB-MT operations while the parent node is attempting to restore the BH link.

[0171] Regarding IAB-DUs that send indications, if an IAB node's BH link is under an RLF, it is expected that a Type 2 BH RLF indication will be sent. This is straightforward for single-connection BHs, as the indication is sent when an RLF occurs on this BH link. However, it becomes slightly more complex for dual-connection BHs. For example, if an IAB node detects an RLF in the MCG, it initiates the MCG failure information procedure, but since the SCG continues to function as a BH link, it may not be necessary to send a Type 2 indication at this point. If the MCG failure information procedure fails, such as due to the expiration of T316, the IAB-MT initiates RRC re-establishment, and a Type 2 indication is sent at this point. Therefore, the Type 2 indication is sent when RRC re-establishment is initiated, not when MCG / SCG failure information is triggered. In any case, since this concerns the behavior of IAB-DUs, careful consideration should be given to whether and how to capture this in the specification. That is, consideration should be given to adding notes for stages 2 and 3, or whether nothing needs to be captured.

[0172] Proposal 6: RAN2 should agree that it may send a Type 2 BH RLF indication when the IAB-DU initiates RRC re-establishment, rather than when the IAB-DU initiates any of the RLF recovery procedures.

[0173] Proposal 7: The specification should discuss whether and how RAN2 should capture the behavior of IAB-DU (i.e., Proposal 6).

[0174] (BH RLF recovery and cell (re)selection expansion) In the RRC re-establishment procedure, the IAB-MT first performs a cell selection procedure to find a suitable cell. Potential issues in this cell selection procedure, such as the possibility of the IAB-MT selecting descendant nodes, were pointed out in Rel-16. Therefore, it was discussed in an email discussion.

[0175] As shown in Figure 18, five possible solutions are discussed and summarized along with Rapporter's perspective.

[0176] The conclusion was, "No further action will be taken on this topic in Rel-16." This meant that RAN2 agreed on "Option 4: If there is no BH connection, RRC re-establishment will fail, so nothing is needed." Option 4 was acceptable in the Rel-16 deployment scenario, even though it would require more time for BH RLF recovery, as it would have to wait for failure (T301 expiration) and eventually move to idle.

[0177] Observation 4: In Rel-16, if an IAB node attempts to re-establish RRC with a descendant node, the IAB node must wait for that to fail and eventually move to idle mode.

[0178] In Rel-17, cell (re)selection and RRC re-establishment may occur frequently from the perspective of Proposal 1. Therefore, suboptimal operation, i.e., operation according to Finding 4, would cause a significant performance degradation in terms of IAB topology stability and service continuity. Accordingly, in order to optimize the operation of the IAB-MT during BH RLF recovery, as the rapporter stated in the above email discussion, "this topic may be discussed again in Rel-17."

[0179] Proposal 8: RAN2 should agree that cell (re)selection optimization should be considered to avoid re-establishment to inappropriate nodes (e.g., descendant nodes).

[0180] Apart from option 4 above, among the identified solutions, a common concept can be considered to be that, for the purpose of cell selection, IAB-MT should be provided in either a whitelist or blacklist form. For example, given that topology changes can occur frequently in Rel-17 due to "movement of interdonor IAB nodes," both whitelists and blacklists have advantages and disadvantages depending on the topology and the location of the IAB nodes.

[0181] For example, from the perspective of IAB nodes near IAB donors, i.e., the top level of the DAG topology, the number of candidate nodes is small, and in some cases, it may only be IAB donor DUs, so providing a whitelist is more rational.

[0182] However, in another example, where an IAB node is far from the IAB donor, i.e., from the lowest level of the DAG topology, it may be necessary to include a huge number of candidate nodes in the whitelist. Instead, a blacklist has the advantage of less overhead in this case, as it would include, for example, only downstream IAB nodes of the IAB node of concern, and possibly only a few child IAB nodes.

[0183] One concern with whitelisting is that, due to the nature of Rel-17's "movement of interdonor IAB nodes," it may be necessary to include candidate IAB nodes belonging to different / adjacent IAB topologies, which could increase the size of the list. On the other hand, downstream IAB nodes, needless to say, belong to the same IAB topology, so blacklisting does not have to worry about that.

[0184] Observation 5: Whitelists and blacklists have advantages and disadvantages depending on the topology and location of the IAB nodes.

[0185] Therefore, when providing information to child IAB nodes for the purpose of cell selection, it is desirable that the IAB donor (or parent IAB node) be able to choose either a whitelist or a blacklist. Furthermore, it is considered beneficial to reuse this information for the purpose of cell re-selection.

[0186] Proposal 9: RAN2 should agree to provide IAB-MT with a whitelist or blacklist (i.e., a selection structure) for cell selection purposes to avoid re-establishment to descendant nodes. Further consideration is needed as to whether these lists can also be used in cell re-selection procedures.

[0187] If we can agree to Proposal 9, we should further consider how to provide the information, i.e., the whitelist or blacklist. Option 1 assumes a CHO configuration and may require some extensions. Option 2 assumes additional indications, such as a Type 2 BH RLF indication. Option 3 assumes providing topology-wide information that is not present in existing configurations. Option 5 assumes configuration by OAM, but as Rapporter pointed out, this is questionable.

[0188] Reconsidering the assumptions of Rel-17 (i.e., Proposal 1), namely that when a topology change occurs, the parent IAB node or IAB donor should provide a list to the child IAB nodes, the method for providing the whitelist / blacklist should be dynamic. Therefore, option 5, i.e., OAM, should be excluded. Further consideration is needed to determine which method, i.e., option 1, 2, or 3, should be the baseline for the extension.

[0189] Proposal 10: RAN2 should agree that whenever the topology changes, the whitelist / blacklist should be dynamically provided by the parent IAB node or IAB donor. Further consideration is needed for details.

[0190] (Expansion of lossless streaming) During the Rel-15 research phase, the challenges of multi-hop RLC ARQ were discussed and captured in section 8.2.3 of the TR. In Rel-16, the protocol stack was defined for IABs with unisolated RLC layers. In other words, in Rel-16, end-to-end ARQ was excluded and hop-by-hop ARQ was adopted.

[0191] Regarding hop-by-hop ARQ, challenges were identified in end-to-end reliability, i.e., lossless delivery in UL packets. As shown in Figure 19, three solutions were identified and evaluated.

[0192] In Rel-16, the first solution is "modification of the PDCP protocol / procedure". -15 It was not adopted because it would affect UE.

[0193] The second solution, "rerouting buffered PDCP PDUs at the intermediate IAB node," was supported as an implementation choice at the BAP layer. Furthermore, the BAP layer may perform, "for example, data buffering in the transmit portion of the BAP entity until the RLC-AM entity receives an acknowledgment, which is implementation-dependent." While these BAP implementations were considered to avoid packet loss in "most" cases of Rel-16 deployment scenarios, i.e., when using fixed IAB nodes, they were not complete, as shown in Figure 19, for example.

[0194] The third solution, "Introduction of UL Status Delivery," was a promised solution to ensure lossless delivery of UL data, considering the evaluation results cited in Figure 19. The idea was to delay the RLC ARQ to the UE so that it would be initiated when PDCP data recovery was needed at the UE. However, this was not specified in Rel-16 because fixed IAB nodes were assumed, and it was considered rare for UL packets to be dropped due to topology changes.

[0195] Given the assumptions of Rel-17, i.e., from the perspective of Proposal 1, since the loss of UL packets during the frequent topology changes in Rel-17 is no longer uncommon, a third solution should be further considered. Accordingly, RAN2 should discuss an extension mechanism to ensure lossless delivery within the L2 multihop network, in addition to the results captured by the TR.

[0196] Proposal 11: RAN2 should agree to implement the solution identified in TR38.874, namely, a mechanism to guarantee lossless delivery under conditions where topology changes may occur frequently based on some form of "UL status delivery".

[0197] The third solution, namely "Implementing UL Status Delivery," was discussed in detail in an email discussion, with two options, C-1 and C-2, as shown in Figure 20.

[0198] Regarding C-1 above, it is assumed that "confirmation" from the IAB donor needs to be specified in the BAP or RRC for end-to-end signaling forwarding over a multi-hop L2 network. Therefore, specifying this option will likely require a relatively high level of standardization efforts.

[0199] Regarding C-2 above, if it works well with the IAB topology, it should be assumed that OAM will configure all IAB nodes using this option, and if RLC ACKs are sent to the UE (or downstream IAB nodes), it ultimately depends on the IAB-DU implementation, so it is indeed implementable even for Rel-16 IAB nodes. Furthermore, it is simpler than C-1 because it assumes hop-by-hop feedback and does not assume additional Control PDUs. Therefore, C-2 should be the extended baseline for Rel-17 for lossless delivery of UL packets.

[0200] Finding 6: C-2, the solution for "Introduction of UL status delivery," could serve as an extended baseline for Rel-17, and this could also be implemented for Rel-16.

[0201] However, since Rel-17 should anticipate dynamic topology changes that cause UL packet loss, extensions to Rel-17 will likely support C-2 as a standard feature. At least the Stage 2 specification should describe the overall mechanism based on C-2. Otherwise, the 3GPP standard will not guarantee lossless delivery during IAB node handover. Furthermore, minor changes such as RLC and / or BAP are expected in Stage 3, but since these are considered internal operations of the IAB node, details may not be specified.

[0202] Proposal 12: RAN2 should agree to define an RLC ARQ mechanism for lossless delivery of UL packets in Stage 2. This would delay the transmission of the ACK to the child node / UE until it receives an ACK from the parent IAB node (i.e., C-2). Further consideration is needed as to whether and how this should be defined in Stage 3.

Claims

1. An IAB (Integrated Access and Backhaul) node that has user devices under its control, It includes a control unit that switches the connection from the first donor base station to the second donor base station, The control unit, The aforementioned connection switching establishes an RRC (Radio Resource Control) connection with the second donor base station, Even after the aforementioned connection switching is performed, the RRC connection between the user device and the first donor base station will continue via the second donor base station. IAB node.

2. A chipset for an IAB (Integrated Access and Backhaul) node that has user devices under its control, Switching the connection from the first donor base station to the second donor base station, The aforementioned connection switching establishes an RRC (Radio Resource Control) connection with the second donor base station, Even after the aforementioned connection switching is performed, the RRC connection between the user device and the first donor base station will be continued via the second donor base station. Chipset.

3. A communication control method, An IAB (Integrated Access and Backhaul) node with user equipment under its control performs a connection switch from the first donor base station to the second donor base station, The IAB node establishes an RRC (Radio Resource Control) connection with the second donor base station through the connection switching, The IAB node ensures that even after the connection switching is performed, the RRC connection between the user device and the first donor base station is maintained via the second donor base station. Communication control method.

4. The first donor base station, It includes a control unit that switches the connection to an IAB (Integrated Access and Backhaul) node with user equipment under its control to a second donor base station. The control unit, Even if an RRC (Radio Resource Control) connection is established between the IAB node and the second donor base station, the RRC connection with the user device will continue via the second donor base station. First donor base station.

5. It is the second donor base station, The system includes a control unit that switches the connection between an IAB (Integrated Access and Backhaul) node having user equipment under its control and a first donor base station to the second donor base station, The control unit, Even if an RRC (Radio Resource Control) connection is established with the IAB node, the RRC connection between the user device and the first donor base station will be maintained via the second donor base station. Second donor base station.

6. A communication system comprising an IAB (Integrated Access and Backhaul) node having user equipment under its control, a first donor base station, and a second donor base station, The IAB node performs a connection switch from the first donor base station to the second donor base station. The IAB node establishes an RRC (Radio Resource Control) connection with the second donor base station through the connection switching, Even if the IAB node performs the connection switching, it will continue the RRC connection between the user device and the first donor base station via the second donor base station. Communication system.

7. An IAB (Integrated Access and Backhaul) node that has user devices under its control, The process of switching the connection from the first donor base station to the second donor base station, The process of establishing an RRC (Radio Resource Control) connection with the second donor base station as a result of the connection switching, Even after the aforementioned connection switching is performed, the process of continuing the RRC connection between the user device and the first donor base station via the second donor base station is executed. program.

Images