COMMUNICATION CONTROL METHOD, FIRST DONOR BASE STATION, AND SYSTEM

Abstract

To provide a communication control method that achieves the handover of an IAB (Integrated Access and Backhaul) node between donor base stations without making any operational changes to user equipment.SOLUTION: In a cellular communication system, when a relay node (IAB (Integrated Access and Backhaul) node) having user equipment UE under its control switches a connection from a first donor base station (source donor eNB) to a second donor base station (target donor gNB), even after the connection switching, the control connection between the user equipment and the first donor base station continues via the second donor base station, and the first donor base station transmits control information to the user equipment via the second donor base station.SELECTED DRAWING: Figure 9

Description

[Technical Field]

[0001] The present disclosure relates to a communication control method for use in a cellular communication system. [Background technology]

[0002] 3GPP (3rd Generation Partnership Project) (registered trademark; the same applies hereinafter), a standardization project for cellular communication systems, specifies a new relay node called an IAB (Integrated Access and Backhaul) node (see, for example, "3GPP TS 38.300 V16.2.0 (2020-07)"). One or more relay nodes intervene in communication between a base station and a user device and relay 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, comprising the steps of: a relay node that relays data from a source node to a plurality of destination nodes selecting a data destination from among the plurality of destination nodes in accordance with a routing configuration set by a donor base station; and the relay node performing local routing to select the data destination without following the routing configuration when a predetermined condition is satisfied. The predetermined condition includes a condition that a failure occurrence notification has been received from any of the plurality of destination nodes.

[0004] A communication control method according to a second aspect is a communication control method used in a cellular communication system, and includes the steps of: a relay node having a user equipment subordinate thereto switching a connection from a first donor base station to a second donor base station; continuing an 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 switching; 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 communication control method according to a third aspect is a communication control method used in a cellular communication system, and includes a relay node that relays data from a source node to multiple destination nodes receiving capacity information regarding the data relay capacity of a target relay node included in the multiple destination nodes from the target relay node, and the relay node controlling the data relay based on the capacity information.

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

[0007] A communication control method according to a fifth aspect is a communication control method used in a cellular communication system, and includes a relay node that relays data from a source node to multiple destination nodes selecting a data destination from among the multiple destination nodes in accordance with a routing setting set by a donor base station, and when a predetermined condition is met, the relay node performing local routing that selects the data destination without following the routing setting, and transmitting historical information regarding the local routing to the donor base station. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is a diagram illustrating a configuration of a cellular communication system according to an embodiment. [Figure 2] FIG. 1 is a diagram illustrating the relationship between IAB nodes, parent nodes, and child nodes. [Figure 3] A diagram showing the configuration of a gNB (base station) according to an embodiment. [Figure 4] FIG. 2 is a diagram illustrating a configuration of an IAB node (relay node) according to the embodiment. [Figure 5] 1 is a diagram illustrating a configuration of a UE (user equipment) according to an embodiment. [Figure 6] A diagram showing the protocol stacks for RRC connection and NAS connection of IAB-MT. [Figure 7] FIG. 1 illustrates a protocol stack for the F1-U protocol. [Figure 8] FIG. 1 illustrates a protocol stack for the F1-C protocol. [Figure 9] FIG. 4 is a diagram illustrating an operation according to the first embodiment. [Figure 10] FIG. 2 is a diagram showing a protocol stack when a handover command is transmitted according to the first embodiment. [Figure 11] FIG. 10 is a diagram for explaining an upstream relay operation according to the second embodiment. [Figure 12] FIG. 10 is a diagram illustrating an upstream relay operation according to the second embodiment. [Figure 13] FIG. 10 is a diagram for explaining a downstream relay operation according to the second embodiment. [Figure 14] FIG. 10 is a diagram illustrating a downstream relay operation according to the second embodiment. [Figure 15] FIG. 10 is a diagram illustrating the operation of the first modification of the second embodiment. [Figure 16] FIG. 10 is a diagram illustrating the operation of the second modification of the second embodiment. [Figure 17]FIG. 10 illustrates types of BH RLF notifications. [Figure 18] FIG. 10 illustrates an identified solution to avoid re-establishment on descendant nodes. [Figure 19] FIG. 10 shows a comparison of mechanisms for lossless delivery of UL data in the case of hop-by-hop RLC ARQ. [Figure 20] FIG. 1 illustrates deployment options for UL status distribution. DETAILED DESCRIPTION OF THE INVENTION

[0009] A cellular communication system according to an embodiment will be described with reference to the drawings, in which the same or similar parts are designated by the same or similar reference numerals.

[0010] (Configuration of a cellular communication system) First, the configuration of a cellular communication system according to an embodiment will be described. Fig. 1 is a diagram showing the configuration of a cellular communication system 1 according to an 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 applied at least partially to the cellular communication system 1.

[0012] 1, the cellular communication system 1 includes a 5G core network (5GC) 10, user equipment (UE) 100, a base station (referred to as a 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 also be an LTE base station (i.e., an eNB).

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

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

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

[0017] Each gNB 200 is connected to other adjacent gNBs 200 via an inter-base station interface called an Xn interface. Figure 1 shows an example in which gNB 200-1 is connected to gNB 200-2.

[0018] Each gNB 200 may be divided into a central unit (CU) and distributed units (DU). The CU and DU are connected to each other via an interface called an F1 interface. The F1 protocol is a communication protocol between the CU and DU, and includes an F1-C protocol, which is a control plane protocol, and an F1-U protocol, which is a user plane protocol.

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

[0020] FIG. 1 illustrates an example in which IAB node 300-1 wirelessly connects to donor gNB 200-1, IAB node 300-2 wirelessly connects to IAB node 300-1, and the F1 protocol is transmitted over two backhaul hops.

[0021] The UE 100 is a mobile wireless communication device that performs wireless communication with a cell. The UE 100 may be any device that performs wireless communication with the gNB 200 or the IAB node 300. For example, the UE 100 may be a mobile phone terminal, a tablet terminal, a laptop computer, a sensor or a device provided in a sensor, or a vehicle or a device provided in a vehicle. The UE 100 is wirelessly connected to the IAB node 300 or the gNB 200 via an access link. FIG. 1 shows an example in which the UE 100 is wirelessly connected to the IAB node 300-2. The UE 100 indirectly communicates with the donor gNB 200-1 via the IAB node 300-2 and the IAB node 300-1.

[0022] FIG. 2 is a diagram showing the relationship between the IAB node 300, parent nodes, and child nodes.

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

[0024] An adjacent node (i.e., an upper node) on the NR Uu radio interface of the IAB-MT is called a parent node. The parent node is a parent IAB node or a DU of the donor gNB 200. The radio link between the IAB-MT and the parent node is called a backhaul link (BH link). FIG. 2 shows an example in which the parent nodes of the IAB node 300 are IAB nodes 300P1 and 300P2. The direction toward the parent node is called upstream. From the perspective of the UE 100, the upper node of the UE 100 may correspond to the parent node.

[0025] Adjacent nodes (i.e., lower nodes) on the NR access interface of the IAB-DU are called child nodes. The IAB-DU manages a cell, similar to the gNB 200. The IAB-DU terminates the NR Uu radio interface to the UE 100 and lower IAB nodes. The IAB-DU supports the F1 protocol to the CU of the donor gNB 200-1. While FIG. 2 shows an example in which the child nodes of the IAB node 300 are IAB nodes 300C1 to 300C3, the child nodes of the IAB node 300 may also include the UE 100. The direction toward the child nodes is called downstream.

[0026] (Base station configuration) Next, the configuration of the gNB 200, which is a base station according to the embodiment, will be described. Fig. 3 is a diagram showing the configuration of the gNB 200. As shown in Fig. 3, the gNB 200 has a radio 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 wireless communication with the IAB node 300. The wireless communication unit 210 has a receiving unit 211 and a transmitting unit 212. The receiving unit 211 performs various receptions under the control of the control unit 230. The receiving unit 211 includes an antenna, and converts a wireless signal received by the antenna into a baseband signal (received signal), and outputs the baseband signal to the control unit 230. The transmitting unit 212 performs various transmissions under the control of the control unit 230. The transmitting unit 212 includes an antenna, and converts a baseband signal (transmitted signal) output by the control unit 230 into a wireless signal, and transmits the wireless signal from the antenna.

[0028] The network communication unit 220 performs wired communication (or wireless communication) with the 5GC10 and wired communication (or wireless communication) with other adjacent gNBs 200. 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 a signal from the outside and outputs the received signal 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 signal output by the control unit 230 to the outside.

[0029] The control unit 230 performs various controls in the gNB 200. 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 in processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processes. The processor performs processing of each layer, which will be described later.

[0030] (Relay node configuration) Next, the configuration of the IAB node 300, which is a relay node according to the embodiment, will be described. Fig. 4 is a diagram showing the configuration of the IAB node 300. As shown in Fig. 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 (BH link) with the gNB 200 and wireless communication (access link) with the UE 100. 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 has 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 a wireless signal received by the antenna into a baseband signal (received signal), and outputs the baseband signal 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 a baseband signal (transmitted signal) output by the control unit 320 into a wireless signal, and transmits the wireless signal from the antenna.

[0033] The control unit 320 performs various controls in 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 in processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processes. The processor performs processing of each layer, which will be described later.

[0034] (Configuration of user device) Next, a description will be given of a configuration of a UE 100 which is a user equipment according to the embodiment. Fig. 5 is a diagram showing the configuration of the UE 100. As shown in Fig. 5, the UE 100 includes a radio communication unit 110 and a control unit 120.

[0035] The radio communication unit 110 performs radio communication in the access link, i.e., radio communication with the gNB 200 and radio communication with the IAB node 300. The radio communication unit 110 may also perform radio communication in the side link, i.e., radio communication with another UE 100. The radio communication unit 110 has a receiving unit 111 and a transmitting unit 112. The receiving unit 111 performs various receptions under the control of the control unit 120. The receiving unit 111 includes an antenna, and converts a radio signal received by the antenna into a baseband signal (received signal), and outputs the signal to the control unit 120. The transmitting unit 112 performs various transmissions under the control of the control unit 120. The transmitting unit 112 includes an antenna, and converts a baseband signal (transmitted signal) output by the control unit 120 into a radio signal, and transmits the signal from the antenna.

[0036] The control unit 120 performs various controls in 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 in processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processes. The processor performs processing of each layer, which will be described later.

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

[0038] As shown in FIG. 6, the IAB-MT of IAB node 300-2 has a physical (PHY) layer, a medium access control (MAC) layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, a radio resource control (RRC) layer, and a non-access stratum (NAS) layer.

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

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

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

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

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

[0044] The NAS layer, which is positioned above the RRC layer, performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of the IAB-MT of the IAB node 300-2 and the AMF 11.

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

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

[0047] In each backhaul link, BAP layer PDUs (Protocol Data Units) are transmitted via a backhaul RLC channel (BH NR RLC channel). Configuring multiple backhaul RLC channels in each BH link enables traffic prioritization and Quality of Service (QoS) control. The association 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 gNB 200.

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

[0049] (First embodiment) Next, the operation of the cellular communication system 1 will be described, assuming that the cellular communication system 1 has the above-described configuration.

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

[0051] In a scenario in which an IAB node 300 performs connection switching between donor gNBs 200, the operation of a UE 100 under the IAB node 300 becomes an issue. Specifically, when an IAB node 300 performs connection switching between donor gNBs 200, new operations may be required for the UE 100 under the IAB node 300. However, from the viewpoint of backward compatibility, it is not desirable to make changes to the operation of the UE 100.

[0052] The first embodiment is an example in which connection switching (e.g., handover) of the IAB node 300 between donor gNBs 200 is realized simply by changing the operation on the network side (IAB node side), transparently to the UE 100. Such a handover may be called an inter-CU handover.

[0053] Specifically, in the first embodiment, first, the IAB node 300 having the UE 100 under its control performs a handover from the source donor gNB 200S, which is a first donor base station, to the target donor gNB 200T, which is a second donor base station different from the first donor base station. Second, even after the handover, the RRC connection between the UE 100 and the source donor gNB 200S continues via the target donor gNB 200T. Third, the source donor gNB 200S uses the RRC connection to send a handover command to the UE 100 via the target donor gNB 200T, instructing the handover to the target donor gNB 200T.

[0054] That is, 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 allows handover of IAB node 300 between donor gNB200 to be realized without making any operational changes to UE100.

[0055] In the first embodiment, a data path may be established between the source donor gNB 200S and the target donor gNB 200T. From the handover of the IAB node 300 to the completion of the handover of the UE 100, a data transfer process (i.e., data forwarding) of the UE 100 may be performed via this data path. This makes it possible to prevent loss of data of the UE 100 even if the handover of the IAB node 300 is performed first and then the handover of the UE 100 is performed.

[0056] FIG. 9 is a diagram showing the operation according to the first embodiment.

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

[0058] In step S102, the IAB node 300 (IAB-MT) is in a state in which an RRC connection with the source donor gNB 200S is established (RRC connected state). At least one intermediate IAB node may be interposed between the IAB node 300 and the source donor gNB 200S. The UE 100 is under the control of the IAB node 300 (IAB-DU). That is, the UE 100 uses the cell of the IAB node 300 (IAB-DU) as its serving cell.

[0059] In step S103, the IAB node 300 (IAB-MT) performs RRC reestablishment or handover from the source donor gNB 200S to the target donor gNB 200T. Here, the explanation will proceed assuming that the IAB node 300 (IAB-MT) performs handover.

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

[0061] At this point, the RRC layer and PDCP layer of the UE 100 remain connected to the source donor gNB 200. Therefore, the UE 100 cannot communicate with the target donor gNB 200T in either the C-plane or U-plane.

[0062] Here, a tunnel (i.e., a data forwarding path) is formed between the source donor gNB 200S and the target donor gNB 200T. This tunnel may be set up on the base station-to-base station interface or via the core network.

[0063] In step S105, the UE 100 transmits uplink user data to the IAB node 300. The IAB node 300 receives the user data.

[0064] In step S106, the IAB node 300 transmits the user data from the UE 100 to the target donor gNB 200T. The target donor gNB 200T 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 the UPF12 of the core network.

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

[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 gNB 200T forwards 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 UE 100.

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

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

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

[0074] Fig. 10 is a diagram showing the protocol stack when transmitting a handover command. As shown in Fig. 10, a handover command (RRC Reconfiguration) is transmitted from the RRC layer of the source donor gNB 200S to the RRC layer of the UE 100 via the target donor gNB 200T and IAB node 300. Communication between the source donor gNB 200S and the target donor gNB 200T is performed via inter-base station communication. Fig. 9 shows an example of GTP, but this is not limiting. For example, Xn-AP may be used, in which case the handover command is transmitted enclosed (encapsulated) in the RRC container of the Xn-AP message.

[0075] Returning to FIG. 9 , in step S115, UE 100 transmits an RRC message (RRC Reconfiguration Complete) indicating handover completion to the target donor gNB 200T in response to the handover command. Specifically, UE 100 transmits the RRC message to the target donor gNB 200T via IAB node 300. The target donor gNB 200T receives the RRC message. Here, since UE 100 continues to be under the control of IAB node 300, it may perform a RACH-less handover in which the transmission of a random access preamble and the reception of a random access response are omitted. In this case, the handover command may instruct UE 100 to perform a RACH-less handover.

[0076] In step S116, as a result of the handover, the UE 100 establishes an RRC connection with the target donor gNB 200T. From this point on, the user data of the UE 100 is switched to communication with the target donor gNB 200T.

[0077] In step S117, the UE 100 transmits uplink user data to the IAB node 300. The 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 gNB 200T. The target donor gNB 200T receives the user data.

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

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

[0081] In step S121, the target donor gNB 200T forwards 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 UE 100.

[0083] (Second embodiment) Next, a second embodiment will be described, focusing mainly on the differences from the above-described embodiment.

[0084] The second embodiment is an embodiment related to load balancing within the IAB topology. In the IAB node 300, paths within the IAB topology are basically determined semi-statically using a routing table (BAP routing ID and path ID), and the CU of the donor gNB 200 collectively manages the routing table. However, if multiple paths can be used efficiently, more dynamic load balancing is considered possible.

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

[0086] The capacity information may include information indicating whether there are multiple next-hop nodes for the target IAB node 300 included in the multiple destination nodes. If there are multiple next-hop nodes for the target IAB node 300, the target IAB node 300 can be considered to have a large data relay capacity. Therefore, by relaying data preferentially to such target IAB node 300, multiple paths can be used efficiently.

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

[0088] As described above, the IAB node 300 selects a data relay destination from among multiple relay destination nodes according to the routing configuration (routing table) set by the donor gNB 200. If a predetermined condition is met, the IAB node 300 may perform local routing to select a data relay destination without following the routing configuration. Here, the predetermined condition may include a condition that a failure occurrence notification or a local routing request is received from one of the multiple relay destination nodes.

[0089] In this way, the IAB node 300 basically performs routing according to the settings from the donor gNB200S, and when a failure occurs at the destination node or a request is made, the IAB node 300 itself performs local routing, allowing data to be relayed to the appropriate destination node depending on the situation.

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

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

[0092] 11, an IAB topology is formed including an IAB node 300, other IAB nodes 300a to 300g, and a donor gNB 200. The IAB node 300 receives an uplink packet (UL packet) from a child node (which may be a UE 100). The IAB node 300 relays the received uplink packet to the parent node, IAB node 300a and / or IAB node 300b, based on the routing configuration set by the donor gNB 200 and information (BAP routing ID) included in the header of the uplink packet.

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

[0094] A BH with one next hop node of the own node is called a "single BH," and a BH with two next hop nodes of the own node is called a "dual BH." In the example of FIG. 11, each of IAB nodes 300b, 300c, 300e, 300f, and 300g is a single BH. On the other hand, each of IAB nodes 300a and 300d is a dual BH, and can be considered to have a larger data relay capacity than a single BH. Note that a dual BH may be in a state where a dual connection is established through dual connectivity.

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

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

[0097] As shown in FIG. 12, in step S201, the IAB node 300 performs routing based on the routing settings set by the donor gNB 200.

[0098] In step S202, the IAB node 300 determines whether a start condition for local routing is satisfied. For example, the start condition is one of the following: A parameter (such as a threshold) defining the start condition may be set in the IAB node 300 by the donor gNB 200.

[0099] -Condition that a BH failure notification is received from the parent node: For example, a notification of the occurrence of a BH failure in a parent node is transmitted from the parent node to the IAB node 300 by a BH RLF Indication, which is a message of the BAP layer. The notification of the occurrence of a BH failure may be a notification indicating that an RLF (Radio Link Failure) has occurred in the BH of the parent node, a notification indicating that the parent node is in the process of recovering from the RLF of the BH, or a notification indicating that the recovery from the RLF of the BH of the parent node has failed.

[0100] -Condition that the uplink throughput to a parent node drops below a certain level: For example, this condition may be satisfied when a scheduling request (SR) sent by an IAB node 300 to a parent node is ignored a certain number of times (for example, no uplink grant is received). This condition may be satisfied when the uplink throughputs of parent nodes are compared and a difference (bias) of a certain amount or more has occurred in the uplink throughputs over a certain period of time in the past (and this state has continued for a certain period of time or longer). This condition may be satisfied when the uplink throughput of a parent node falls below a certain value (and this state has continued for a certain period of time or longer).

[0101] ·Condition that a local routing request is received from the parent node: The local routing request may be transmitted from the parent node by a BAP layer message. The local routing request may be transmitted from the donor gNB 200 via the parent node by an F1 message or an RRC message. The IAB node 300 may transmit a response to the local routing request from the parent node, or may notify the parent node of a transmission ratio, which will be described later.

[0102] The local routing request may include an identifier of a bearer (or RLC channel, or logical channel) to be local-routed. The IAB node 300 performs local routing for the target bearer (or RLC channel, or logical channel), and does not perform local routing for the non-target bearer (or RLC channel, or logical channel) (i.e., performs routing according to a routing table).

[0103] The condition that the uplink buffer capacity of the IAB node 300 or its child node has reached a certain level (and this state has continued for a certain period of time): For example, the IAB node 300 can grasp the uplink buffer capacity of a child node based on a buffer status report (BSR) received from the child node. The BSR may also take into account the uplink buffer capacity of a child node (i.e., a grandchild node) of the child node. This condition may be met when the uplink buffer capacity indicated by the BSR exceeds a certain level (and this state continues for a certain period of time).

[0104] If the local routing start condition is not satisfied (step S202: No), the IAB node 300 continues routing based on the routing configuration set by the donor gNB 200 (step S201).

[0105] On the other hand, if the local routing start condition is satisfied (step S202: Yes), the IAB node 300 starts operations related to local routing. Note that the IAB node 300 may be allowed to perform local routing only when the donor gNB 200 permits the execution of local routing. This permission is given by a BAP layer message (BAP Control PDU), system information (SIB1), RRC Reconfiguration, or the like. Whether or not local routing can be performed may be set for each bearer (RLC channel) or may be set for all bearers collectively. Along with such settings, it may also be possible to set which of the above conditions is to be applied and a threshold value used to determine the condition.

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

[0107] The BH connection information of a parent node may include information indicating whether the parent node is a single BH or dual BH (or triple BH). The BH connection information of a parent node may include a numerical value indicating the number of BHs of 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 be, for example, information indicating at least one of the bandwidth, the number of component carriers, and the frequency band of each BH link, or information indicating the average throughput (or the maximum throughput, GBR (Guaranteed Bit Rate), etc.) of each BH link.

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

[0109] Alternatively, the BH connection information may be transmitted from the donor gNB 200 to the IAB node 300. It may be an information element included in an RRC message (e.g., RRC Reconfiguration) or an F1 message (e.g., DL Information Transfer) transmitted by the donor gNB 200.

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

[0111] In step S205, the IAB node 300 performs local routing of the uplink packet based on the transmission ratio determined (and adjusted) in step S204. The IAB node 300 may change the header of the uplink packet that has been locally routed. 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.

[0112] In step S206, the IAB node 300 determines whether a termination condition for local routing has been satisfied. The termination condition may be the opposite of the above-mentioned start condition. For example, the termination condition may be at least one of the following: a BH recovery success notification has been received from a parent node; throughput to a parent has been restored; a local routing stop request has been received; and the buffer status of a child node (and grandchild node) has improved. The termination condition may also include a condition in which local routing permission has been revoked (set to not permitted) by the donor gNB 200.

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

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

[0115] Fig. 13 is a diagram for explaining downstream relay operation according to the second embodiment. In downstream relay operation, the source node of an 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 downstream relay operation, the parent node and child node in the upstream relay operation described above can be swapped. Note that Fig. 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 (Destination).

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

[0117] As shown in FIG. 14, in step S301, the IAB node 300 performs routing based on the routing settings set by the donor gNB 200.

[0118] In step S302, the IAB node 300 determines whether a local routing start condition is satisfied. For example, the start condition is one of the following: A parameter (threshold, etc.) defining the start condition may be set in the IAB node 300 by the donor gNB 200. The IAB node 300 may be able to perform local routing only if local routing is permitted (set) by the donor gNB 200. The permission may be given by an F1 message (F1AP), an RRC message, or a BAP message. The permission may be set for each bearer (RLC channel) or may be set collectively for all bearers. The permission may be an instruction. In addition, which of the following conditions is to be applied and a threshold used to determine the condition may be set.

[0119] - A condition in which the throughput of a path drops below a certain level (and this state continues for a certain period of time).

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

[0121] The condition that the available buffer size of a child node falls below a certain level (and this state continues for a certain period of time): For example, the IAB-DU of the IAB node 300 transmits a Flow Control Polling BAP Control PDU to a child node and receives a Flow Control Feedback BAP Control PDU from the child node. Then, the IAB node 300 (IAB-DU) identifies the available buffer size (free buffer amount) indicated by the Flow Control Feedback BAP Control PDU and makes a determination.

[0122] If the local routing start condition is not satisfied (step S302: No), the IAB node 300 continues routing based on the routing configuration set by the donor gNB 200 (step S301).

[0123] On the other hand, if the local routing start condition is satisfied (step S302: Yes), the IAB node 300 starts operations related to local routing. The IAB node 300 may select a different path with the same destination from the routing configuration and transmit a downlink packet to the IAB node corresponding to that path. The IAB node 300 may also change 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 selects a downstream path and / or determines a transmission ratio to a child node. Specifically, the IAB node 300 selects another path having the same destination from the stored routing configuration. The IAB node 300 may select multiple paths, and in this case, may determine the transmission ratio in the same manner as the upstream relay operation described above. A combination of selectable paths from the donor gNB 200 to the IAB node 300 may be set in advance.

[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 a termination condition for local routing has been satisfied. The termination condition may be the opposite of the above-described start condition. For example, the termination condition may be at least one of the following: the throughput of a certain path has recovered to a certain level or above; the radio condition of a child node has recovered to a certain level or above; or the available buffer size of a child node has recovered to a certain level or above. The termination condition may include a condition in which permission for local routing has been revoked (set to unpermitted) by the donor gNB 200.

[0128] If the termination condition for local routing is not satisfied (step S306: No), the IAB node 300 continues local routing (step S305). On the other hand, if the termination condition for local routing is satisfied (step S306: Yes), the IAB node 300 performs routing based on the routing setting set by the donor gNB 200 (step S301).

[0129] (Modification 1 of the second embodiment) Next, a first modification of the second embodiment will be described, focusing mainly on the differences from the above-described embodiment.

[0130] In the second embodiment described above, there is a risk that the donor gNB 200 may not be able to grasp the contents of the local routing performed by the IAB node 300 (when it was performed and how many times it was performed). If local routing is performed, there is a possibility that there is a problem with the routing configuration by the donor gNB 200, or that a failure has occurred in the IAB topology. For this reason, it is preferable that the donor gNB 200 be able to grasp the contents of the local routing. This allows the donor gNB 200 to, for example, optimize the routing configuration.

[0131] In this modified example, the IAB node 300, which relays data from a source node to multiple destination nodes, selects a data destination from among multiple destination nodes according to a routing configuration set by the donor gNB 200. When a predetermined condition is met, the IAB node 300 performs local routing to select a data destination without following the routing configuration (see the second embodiment). The IAB node 300 transmits history information about this local routing (i.e., information indicating the content of the local routing) to the donor gNB 200.

[0132] FIG. 15 is a diagram illustrating the operation of the first modification of the second embodiment.

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

[0134] In step S402, the IAB node 300 saves information (local routing information) related to the local routing executed in step S401. The IAB node 300 saves the local routing information every time it performs local routing.

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

[0136] In step S403, the IAB node 300 transmits the local routing information stored in step S402 to the donor gNB 200. The local routing information is transmitted from the IAB node 300, for example, by an RRC message. The local routing information may be transmitted as a response message in response to a request from the donor gNB 200. For example, the local routing information may be transmitted as a UE Information Response in response to a UE Information Request.

[0137] (Modification 2 of the second embodiment) Next, a second modification of the second embodiment will be described, focusing on differences from the above-described embodiment. This modification is an example in which the donor gNB 200 changes the routing setting of the IAB node 300 in response to a request from the IAB node 300.

[0138] In this modified example, the IAB node 300, which relays data from a source node to multiple destination nodes, selects a destination node from among the multiple destination nodes in accordance with the routing settings set by the donor gNB 200. The IAB node 300 transmits a routing change request to the donor gNB 200 to change the routing settings.

[0139] FIG. 16 is a diagram illustrating the operation of the second modification of the second embodiment.

[0140] As shown in FIG. 16, in step S501, the IAB node 300 transmits a routing change request to the donor gNB 200. The routing change request may be a notification of a desired routing change. The routing change request may be an RRC message or an F1 (F1AP) message. The routing change request may be defined separately for an upstream routing change and a downstream routing change. The routing change request may be transmitted only when transmission is permitted by the donor gNB 200.

[0141] The IAB node 300 may transmit a routing change request when the same conditions as the local routing start conditions described in the second embodiment are satisfied as a trigger. The conditions and determination thresholds to be used may be set in the IAB node 300 by the donor gNB 200. The IAB node 300 may transmit a routing change request only when the donor gNB 200 has permitted (set) transmission of the routing change request.

[0142] The routing change request may include at least one of information indicating the reason (or condition) for which a routing setting change is necessary, the routing ID (path ID, destination) of the setting change target, and the RLC Channel ID (bearer ID, which may also be LCID) of the setting change target.

[0143] In the case of an upstream routing change, the IAB node 300 may include its own BSR value in the routing change request. In addition, in the case of dual BH (dual connectivity), the IAB node 300 may include a BSR value for each parent node (each path) in the routing change request. The IAB node 300 may also include the BSR value of its child node or its own BSR value that takes that into account in the routing change request. Such transmission of BSR values ​​may be periodically performed by each IAB node 300 in the IAB topology to the donor gNB 200.

[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 value of its child node (Flow control feedback BAP Control PDU value) in the routing change request. Such transmission of available buffer size values ​​may be periodically performed by each IAB node 300 in the IAB topology to the donor gNB 200.

[0145] In step S502, the donor gNB 200 changes the routing setting of the IAB node 300 in response to the routing change request received in step S501. The IAB node 300 may perform a handover of the IAB node 300 (i.e., an IAB topology change) as necessary.

[0146] The IAB node 300 may start a timer when transmitting a routing change request, and may be prohibited from transmitting the next routing change request until the timer expires. The timer value may be set for the IAB node 300 by the donor gNB 200.

[0147] (Other embodiments) The above-described embodiments and modifications can be implemented by combining different embodiments and modifications with each other. In addition, modifications 1 and 2 of the second embodiment can be used in combination with the second embodiment, or can be implemented separately from the second embodiment.

[0148] In the above-described embodiment and modified examples, relay transmission by IAB has been described as an example, but the present invention is not limited to this and may be applied to other relay transmission systems. For example, the operations according to the above-described embodiment and modified examples may be applied to a relay node (Layer 3 relay node), a sidelink relay (a relay node using a sidelink used for direct communication between user equipments), etc.

[0149] In the above-described embodiment, an example in which the cellular communication system 1 is a 5G cellular communication system has been mainly described. However, the base station in the cellular communication system 1 may be an eNB, which is an LTE base station. Also, the core network in the cellular communication system 1 may be an EPC (Evolved Packet Core). Furthermore, the gNB may be connected to the EPC, the eNB may be connected to the 5GC, and the gNB and the 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 process according to the above-described embodiment and modified examples. The program may also be recorded on a computer-readable medium. Using the computer-readable medium, the program can be installed on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM. A chipset may also be provided that is configured from a memory that stores a program for executing each process performed by the UE 100, the gNB 200, or the IAB node 300, and a processor that executes the program stored in the memory.

[0151] This application claims priority to U.S. Provisional Application No. 63 / 061887 (filed August 6, 2020), the entire contents of which are incorporated herein by reference.

[0152] (Addendum) (introduction) A revised work item on NR eIAB (Enhancements to Integrated Access and Backhaul) was approved. Some of the objectives are:

[0153] Topology Adaptation Extensions Specification of procedures for inter-donor IAB node mobility to enhance robustness and load balancing, including enhancements to reduce signaling load. -Specify extensions to reduce service interruptions due to IAB node movement and BH RLF recovery. · Specification of extensions to topology redundancy, including support for CP / UP separation. Topology, Routing, and Transport Enhancements Specification of extensions to improve fairness across topologies, multi-hop delays, and congestion mitigation.

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

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

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

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

[0158] Observation 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 Node," which may be part of "Inter-Donor IAB Node Mobility" even though it is not explicitly mentioned in the WID. Furthermore, sub-objectives in the WID, such as "Enhancements for IAB Node Mobility and BH RLF Recovery to Reduce Service Disruptions" and "Topology Redundancy Enhancements," clearly intend for the BH link to be unstable, and mobility and BH RLF frequently occur 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 changes dynamically, so that backhaul RLF is not a rare case as in Rel-17 eIAB.

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

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

[0163] Finding 3: In Rel-16, only Type 4 “failure to recover” was defined as a BH RLF indication.

[0164] On the other hand, many companies still believed that other types of indications would be useful, so this was further discussed via email. Eight out of 13 companies preferred to introduce Type 2 "attempting recovery," while the other two companies thought it would be discussed in Rel-17. Therefore, it can be assumed that the majority of companies believe they are ready to introduce Type 2 indication in Rel-17. How to send Type 2 indication, such as by using BAP Control PDU, SIB1, or both, requires further consideration. Note that Type 1 and Type 2 have exactly the same meaning.

[0165] Proposal 2: RAN2 should agree that BH RLF indication type 2 "attempting recovery" is introduced. Whether it should be sent via BAP Control PDU, SIB1, or both is for further consideration.

[0166] Furthermore, nine of the 13 companies agreed to discuss Type 3 "BH link recovery" in Rel-17 as well. Specifically, whether such an explicit indication is truly necessary can be considered. For example, if Type 2 indication is sent via SIB1, the indication will not be broadcast once the BH link is no longer under RLF (i.e., "recovered"). Therefore, downstream IAB nodes and UEs will recognize whether the BH link has recovered based on the absence of Type 2 indication in SIB1. Of course, if Type 3 indication is sent via BAP Control PDU, it has the advantage that downstream IAB nodes can quickly learn of the BH link recovery. However, in this case, the UE does not have the BAP layer and cannot know the fact. Therefore, RAN2 should discuss whether Type 3 indication is necessary.

[0167] Proposal 3: If Proposal 3 can be agreed upon, RAN2 should discuss whether an explicit BH RLF indication when the BH RLF disappears, i.e., Type 3 "BH Link Recovery", should be introduced.

[0168] If Proposal 2 and / or Proposal 3 can be agreed upon, the behavior of the IAB-MT when it receives an indication and the BH link is restored should be considered. It is proposed that the IAB-MT should reduce / stop SR when it receives Type 2 and resume operation when it receives Type 3 (i.e., the BH RLF disappears at the parent IAB node). This is one of the desired IAB-MT behaviors when the parent node attempts to restore the BH link. It is assumed that other IAB-MT behaviors, such as suspending all RBs, are also 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 the parent node no longer has a BH RLF.

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

[0171] Regarding the IAB-DU that transmits the indication, if the BH link of the IAB node is under RLF, it is assumed that it will transmit a Type 2 BH RLF indication. This is straightforward for a single-connection BH because the indication is transmitted when an RLF occurs on this BH link. However, it becomes a bit more complicated for a dual-connection BH. For example, if an IAB node detects RLF on the MCG, it initiates the MCG fault information procedure. However, since the SCG continues to function as the BH link, it may not be necessary to transmit a Type 2 indication at this point. If the MCG fault information procedure fails, such as due to the expiration of T316, the IAB-MT initiates RRC re-establishment, so a Type 2 indication is transmitted at this point. Therefore, a Type 2 indication is transmitted when RRC re-establishment is initiated, not when the MCG / SCG fault information is triggered. In any case, since this is intended for IAB-DU operation, careful consideration should be given to whether and how to capture this in the specification. That is, consideration should be given to whether notes should be added or not at all in Stages 2 and 3.

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

[0173] Proposal 7: RAN2 should discuss whether / how to capture IAB-DU behavior (i.e., Proposal 6) in its specifications.

[0174] (BH RLF Recovery and Cell (Re)Selection Enhancements) In the RRC re-establishment procedure, the IAB-MT first performs a cell selection procedure to find a suitable cell. Potential issues with this cell selection procedure, such as the possibility that the IAB-MT may select a descendant node, were identified in Rel-16. Therefore, these were discussed in the email discussion.

[0175] Five possible solutions were discussed and summarized along with the rapporteur's views, as shown in Figure 18.

[0176] The conclusion was "No further action will be taken on this topic in Rel-16", which meant that RAN2 agreed to "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 required more time for BH RLF recovery, since it would have to wait for failure (T301 expiry) and eventually move to idle.

[0177] Observation 4: In Rel-16, if an IAB node attempts an RRC re-establishment request to a descendant node, the IAB node must wait for the failure and eventually move to idle.

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

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

[0180] Among the solutions identified, except for option 4 above, a common concept can be seen to be that for cell selection purposes, the IAB-MT is provided with either a whitelist or blacklist type. Considering that topology changes may occur frequently in Rel-17, for example due to "inter-donor IAB node movements," whitelists and blacklists have advantages and disadvantages depending on the topology and the location of the IAB nodes.

[0181] For example, it is more reasonable to provide a whitelist for IAB nodes near the IAB donor, i.e., from the perspective of the top of the DAG topology, since the number of candidate nodes is small, possibly only IAB donor DUs.

[0182] However, in another example, where an IAB node is far away from the IAB donor, i.e., from the perspective of the bottom of the DAG topology, the whitelist may need to include a huge number of candidate nodes. Instead, the blacklist may include, for example, only downstream IAB nodes of the IAB node of concern, and possibly only a few child IAB nodes, thus providing the advantage of less overhead in this case.

[0183] One concern with whitelists is that due to the nature of Rel-17's "Inter-Donor IAB Node Movement," they may need to include candidate IAB nodes that belong to different / adjacent IAB topologies, potentially increasing the list size, whereas blacklists do not need to care about downstream IAB nodes, since they obviously belong to the same IAB topology.

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

[0185] Therefore, it is desirable for an IAB donor (or parent IAB node) to be able to select either a whitelist or a blacklist when providing information to a child IAB node for cell selection purposes. It may be beneficial to reuse this information for cell reselection purposes.

[0186] Proposal 9: RAN2 should agree that whitelists or blacklists (i.e., selection structures) are provided to the IAB-MT for cell selection purposes to avoid re-establishment on descendant nodes. Whether these lists can also be used for cell reselection procedures requires further study.

[0187] If proposal 9 can be agreed upon, further consideration should be given to how the information, i.e. whitelist or blacklist, is provided. Option 1 assumes CHO configuration and may require some extensions. Option 2 assumes additional indications, e.g., Type 2 BH RLF indication. Option 3 assumes providing topology-wide information not present in the existing configuration. Option 5 assumes configuration by OAM, but as the rapporteur pointed out, this is questionable.

[0188] Considering again the assumption of Rel-17 (i.e., Proposal 1), that parent IAB nodes or IAB donors should provide lists to child IAB nodes when topology changes occur, the method of providing whitelists / blacklists should be dynamic. Therefore, option 5, i.e., OAM, should be ruled out. Which method, i.e., option 1, 2, or 3, should be the baseline for enhancements requires further consideration.

[0189] Proposal 10: RAN2 should agree that the whitelist / blacklist will be dynamically provided by the parent IAB node or IAB donor whenever the topology changes. Details need further study.

[0190] (Lossless streaming extension) 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 IAB with a non-separated RLC layer, i.e., end-to-end ARQ was eliminated in Rel-16 in favor of hop-by-hop ARQ.

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

[0192] In Rel-16, the first solution, "PDCP protocol / procedure changes", was -15 Not adopted due to impact on UE.

[0193] The second solution, "rerouting buffered PDCP PDUs at intermediate IAB nodes," was supported as an implementation choice at the BAP layer. Additionally, the BAP layer may "implementation-dependently perform, for example, data buffering in the transmitting part of the BAP entity until the RLC-AM entity receives an acknowledgment." These BAP implementations were considered to avoid packet loss in "most" cases of Rel-16 deployment scenarios, i.e., when using fixed IAB nodes, but were not perfect, e.g., as shown in Figure 19.

[0194] The third solution, "introduction of UL status delivery," was a promising solution to ensure lossless delivery of UL data, taking into account the evaluation results cited in Figure 19. The idea was to delay the RLC ARQ to the UE, so that PDCP data recovery at the UE would be initiated when necessary. However, since fixed IAB nodes were assumed, it was considered rare for UL packets to be dropped due to topology changes, so this was not specified in Rel-16.

[0195] Considering the assumptions of Rel-17, i.e., from the perspective of Proposal 1, the third solution should be further explored because UL packet loss during topology changes, which occur frequently in Rel-17, is no longer rare. Therefore, in addition to the results captured in TR, RAN2 should discuss enhancement mechanisms to ensure lossless delivery within L2 multi-hop networks.

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

[0197] Regarding the details of the third solution, i.e., "Introduction of UL Status Distribution", two options, C-1 and C-2, were discussed in the email discussion, 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 transport over a multi-hop L2 network. Therefore, specifying this option would require a relatively high standardization effort.

[0199] Regarding C-2 above, if it works well in an IAB topology, it should be assumed that OAM configures all IAB nodes using this option, but sending an RLC ACK to the UE (or downstream IAB node) ultimately relies on the IAB-DU implementation, so it can actually be implemented 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 an extended baseline for Rel-17 for lossless delivery of UL packets.

[0200] Observation 6: Solution C-2 for "Introduction of UL Status Distribution" could be an extended baseline for Rel-17, which could also be implemented for Rel-16.

[0201] However, Rel-17 should anticipate dynamic topology changes that cause UL packet loss, so Rel-17 extensions will likely support C-2 as a standard supported feature. At least the Stage 2 specifications 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 these are considered internal operations of IAB nodes and may not be specified in detail.

[0202] Proposal 12: RAN2 should agree to specify an RLC ARQ mechanism for lossless delivery of UL packets in Stage 2, which delays sending ACK to child nodes / UEs before receiving ACK from the parent IAB node (i.e., C-2). Whether / how to specify this in Stage 3 requires further study.

Claims

1. A communication control method, comprising: an IAB node having a user device thereunder switches a connection from a first donor base station to a second donor base station; Even if the connection switching is performed, a Radio Resource Control (RRC) connection between the user equipment and the first donor base station is continued via the second donor base station; the first donor base station transmitting an RRC message addressed to the user equipment to the user equipment via the second donor base station. Communication control method.

2. a first donor base station, a control unit that switches a connection between an IAB node having a user device thereunder and the first donor base station to a second donor base station; and a transmission unit; The control unit continues an RRC (Radio Resource Control) connection between the user equipment and the first donor base station via the second donor base station even when the connection is switched, The transmitter transmits an RRC message addressed to the user equipment to the user equipment via the second donor base station. First donor base station.

3. 1. A system comprising a first donor base station, The first donor base station: Switching a connection between an IAB node having a user device thereunder and the first donor base station to a second donor base station; Even if the connection is switched, an RRC (Radio Resource Control) connection between the user equipment and the first donor base station is continued via the second donor base station; Transmitting an RRC message addressed to the user equipment to the user equipment via the second donor base station. system.

Images