Communication control method, relay node and processor

Abstract

In a first aspect, a communication control method is a communication control method used in a cellular communication system and comprising the steps of: performing, by a relay node, a connection transition from a first donor base station to a second donor base station, the relay node comprising a user equipment under control of the relay node; continuing a radio resource control (RRC) connection between the user equipment and the first donor base station via the second donor base station after performing the connection transition; and transmitting, by the first donor base station, a handover command to the user equipment via the second donor base station by using the RRC connection, the handover command instructing the user equipment to perform a handover to the second donor base station.

Description

Technical Field

[0001] The present disclosure relates to a communication control method used in a cellular communication system. Background Art

[0002] In the Third Generation Partnership Project (3GPP), which is a standardization project for cellular communication systems, a new relay node called an integrated access and backhaul (IAB) node is defined (for example, see "3GPP TS 38.300 V16.2.0 (2020-07)"). One or more relay nodes participate in the communication between a base station and a user equipment and perform relaying of the communication. Summary of the Invention

[0003] In a first aspect, a communication control method is a communication control method used in a cellular communication system, and includes the following steps: a relay node selects a data relay destination from a plurality of relay destination nodes according to a routing configuration configured by a donor base station, where the relay node performs data relaying from a relay source node to the plurality of relay destination nodes; and the relay node performs local routing when a predetermined condition is satisfied, and the local routing selects a data relay destination without following the routing configuration. The predetermined condition includes the condition that a failure occurrence notification has been received from any one of the plurality of relay destination nodes.

[0004] In a second aspect, a communication control method is a communication control method used in a cellular communication system, and includes the following steps: a relay node performs a connection conversion from a first donor base station to a second donor base station, where the relay node includes a user equipment under the control of the relay node; after performing the connection conversion, continue a radio resource control (RRC) connection between the user equipment and the first donor base station via the second donor base station; and the first donor base station sends a handover command to the user equipment via the second donor base station by using the RRC connection, and the handover command instructs the user equipment to perform a handover to the second donor base station.

[0005] In a third aspect, a communication control method is a communication control method used in a cellular communication system, and includes the following steps: a relay node receives capability information related to the data relaying capability of a target relay node included in a plurality of relay destination nodes, where the relay node performs data relaying from a relay source node to the plurality of relay destination nodes; and the relay node controls data relaying based on the capability information.

[0006] In a fourth aspect, a communication control method is a communication control method used in a cellular communication system, and includes the following steps: a relay node selects a data relay destination from a plurality of relay destination nodes according to a routing configuration configured by a donor base station, where the relay node performs data relay from a relay source node to the plurality of relay destination nodes; and the relay node sends a routing configuration change request for changing the routing configuration to the donor base station.

[0007] In a fifth aspect, a communication control method is a communication control method used in a cellular communication system, and includes the following steps: a relay node selects a data relay destination from a plurality of relay destination nodes according to a routing configuration configured by a donor base station, where the relay node performs data relay from a relay source node to the plurality of relay destination nodes; the relay node performs local routing when a predetermined condition is satisfied, and the local routing selects a data relay destination without following the routing configuration; and historical information related to the local routing is sent to the donor base station. Description of the Drawings

[0008] Figure 1 is a diagram showing the configuration of a cellular communication system according to an embodiment.

[0009] Figure 2 is a diagram showing the relationship between an IAB node, a parent node, and a child node.

[0010] Figure 3 is a diagram showing the configuration of a base station (gNB) according to an embodiment.

[0011] Figure 4 is a diagram showing the configuration of a relay node (IAB node) according to an embodiment.

[0012] Figure 5 is a diagram showing the configuration of a user equipment (UE) according to an embodiment.

[0013] Figure 6 is a diagram showing a protocol stack related to the RRC connection and NAS connection of an IAB-MT.

[0014] Figure 7 is a diagram showing a protocol stack related to the F1-U protocol.

[0015] Figure 8 is a diagram showing a protocol stack related to the F1-C protocol.

[0016] Figure 9 is a diagram showing the operations according to the first embodiment.

[0017] Figure 10 is a diagram showing the protocol stack at the time of handover command transmission in the first embodiment.

[0018] Figure 11 is a diagram for showing the upstream relay operation according to the second embodiment.

[0019] Figure 12 is a diagram showing the upstream relay operation according to the second embodiment.

[0020] Figure 13 is a diagram for showing the downstream relay operation according to the second embodiment.

[0021] Figure 14 is a diagram showing the downstream relay operation according to the second embodiment.

[0022] Figure 15 is a diagram showing the operation according to Variant 1 of the second embodiment.

[0023] Figure 16 is a diagram showing the operation according to Variant 2 of the second embodiment.

[0024] Figure 17 is a diagram showing the types of BHR LF notifications.

[0025] Figure 18 is a diagram showing the determined solution for avoiding reconstruction to descendant nodes.

[0026] Figure 19 is a diagram showing a comparison of mechanisms for lossless transfer of UL data in the case of per-hop RLC ARQ.

[0027] Figure 20 is a diagram showing the option of introducing UL status transfer. Detailed Description

[0028] In an embodiment, a cellular communication system will be described with reference to the accompanying drawings. In the description of the drawings, the same or similar parts are denoted by the same or similar reference numerals.

[0029] Configuration of the Cellular Communication System

[0030] In an embodiment, the configuration of a cellular communication system will be described. Figure 1 is a diagram showing the configuration of a cellular communication system 1 according to an embodiment.

[0031] The cellular communication system 1 is a fifth-generation (5G) cellular communication system based on the 3GPP standard. Specifically, the radio access scheme in the cellular communication system 1 is New Radio (NR) as the radio access scheme of 5G. Note that Long-Term Evolution (LTE) can be at least partially applied to the cellular communication system 1.

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

[0033] Examples where each base station is an NR base station will be mainly described below. However, the base station can be an LTE base station (i.e., an eNB).

[0034] The 5GC 10 includes an access and mobility management function (AMF) 11 and a user plane function (UPF) 12. The AMF 11 is a device that performs various types of mobility control, etc. for the UE 100. The AMF 11 communicates with the UE 100 by using non-access stratum (NAS) signaling, thereby managing information on the area where the UE 100 is located. The UPF 12 is a device that performs transmission control of user data, etc.

[0035] Each gNB 200 is a fixed wireless communication node and manages one or more cells. The term "cell" is used to indicate the smallest unit of a wireless communication area. The term "cell" can be used to indicate a function or resource for performing wireless communication with the UE 100. One cell belongs to one carrier frequency.

[0036] Each gNB 200 is interconnected with the 5GC 10 via an interface called the NG interface. Figure 1 Two gNBs connected to the 5GC 10 are shown, namely gNB 200-1 and gNB 200-2.

[0037] Each gNB 200 is interconnected with another adjacent gNB 200 via an inter-base-station interface called the Xn interface. Figure 1 An example where gNB 200-1 is connected to gNB 200-2 is shown.

[0038] Each gNB 200 can 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 includes an F1-C protocol corresponding to the protocol for the control plane and an F1-U protocol corresponding to the protocol for the user plane.

[0039] The cellular communication system 1 supports IAB, which uses NR for backhaul to achieve wireless relay of NR access. The donor gNB 200-1 corresponds to the end node of the NR backhaul at the network side and includes a donor base station that supports additional functions of IAB. This backhaul can be implemented with multiple hops (i.e., multiple IAB nodes 300) to achieve multi-hop.

[0040] Figure 1The following example is shown: The IAB node 300-1 is wirelessly connected to the donor gNB 200-1, the IAB node 300-2 is wirelessly connected to the IAB node 300-1, and the F1 protocol is transmitted via two backhaul hops.

[0041] The UE 100 is a mobile wireless communication device that performs wireless communication with a cell. The UE 100 can be any type of device as long as the UE 100 is a device that performs wireless communication with the gNB 200 or the IAB node 300. For example, the UE 100 is a mobile phone terminal, a tablet terminal, a laptop PC, a sensor, a device provided in the sensor, a vehicle, or a device provided in the vehicle. The UE 100 is wirelessly connected to the IAB node 300 or the gNB 200 via an access link. Figure 1 An example in which the UE 100 is wirelessly connected to the IAB node 300-2 is shown. The UE 100 communicates indirectly with the donor gNB 200-1 via the IAB node 300-2 and the IAB node 300-1.

[0042] Figure 2 is a diagram showing the relationship between the IAB node 300, the parent node, and the child node.

[0043] As Figure 2 shown, each IAB node 300 includes an IAB-DU corresponding to a base station functional unit and an IAB-Mobile Terminal (MT) corresponding to a user equipment functional unit.

[0044] An adjacent node (i.e., the upper node) on the NR Uu radio interface of the IAB-MT can be referred to as a "parent node". The parent node is the DU of the parent IAB node or the donor gNB 200. The radio link between the IAB-MT and each parent node is referred to as a backhaul link (BH link). Figure 2 An example in which the parent nodes of the IAB node 300 are the IAB nodes 300P1 and 300P2 is shown. Note that the direction towards the parent node is called upstream. From the perspective of the UE 100, the upper node of the UE 100 can correspond to the parent node.

[0045] An adjacent node (i.e., the lower node) on the NR access interface of the IAB-DU can be referred to as a "child node". The IAB-DU manages the cell in the same and / or similar manner as the gNB 200. The IAB-DU terminates the NR Uu radio interface connected to the UE 100 and the lower IAB node. The IAB-DU supports the F1 protocol for the CU of the donor gNB 200-1. Figure 2Shows an example where the child nodes of the IAB node 300 are IAB nodes 300C1 to 300C3; however, the UE 100 may be included in the child nodes of the IAB node 300. Note that the direction towards the child nodes is referred to as downstream.

[0046] Configuration of the base station

[0047] In an embodiment, the configuration of the gNB 200 as a base station will be described. Figure 3 Is a diagram showing the configuration of the gNB 200. As Figure 3 Shown, the gNB 200 includes a wireless communicator 210, a network communicator 220, and a controller 230.

[0048] The wireless communicator 210 performs wireless communication with the UE 100 and performs wireless communication with the IAB node 300. The wireless communicator 210 includes a receiver 211 and a transmitter 212. The receiver 211 performs various types of reception under the control of the controller 230. The receiver 211 includes an antenna, converts the radio signal received by the antenna into a baseband signal (received signal), and outputs the baseband signal to the controller 230. The transmitter 212 performs various types of transmission under the control of the controller 230. The transmitter 212 includes an antenna, converts the baseband signal (transmitted signal) output by the controller 230 into a radio signal, and transmits the radio signal from the antenna.

[0049] The network communicator 220 performs wired communication (or wireless communication) with the 5GC 10 and performs wired communication (or wireless communication) with another adjacent gNB 200. The network communicator 220 includes a receiver 221 and a transmitter 222. The receiver 221 performs various types of reception under the control of the controller 230. The receiver 221 receives a signal from the outside and outputs the received signal to the controller 230. The transmitter 222 performs various types of transmission under the control of the controller 230. The transmitter 222 transmits the transmission signal output by the controller 230 to the outside.

[0050] The controller 230 performs various types of control in the eNB 200. The controller 230 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs to be executed by the processor and information to be used for the processing performed by the processor. The processor may include a baseband processor and a central processing unit (CPU). The baseband processor performs modulation and demodulation, encoding and decoding, etc. of the baseband signal. The CPU executes the programs stored in the memory, thereby performing various types of processing. The processor performs the processing of the layers described below.

[0051] Configuration of the relay node

[0052] In an embodiment, the configuration of the IAB node 300 as a relay node will be described. Figure 4 FIG. is a diagram showing the configuration of the IAB node 300. As Figure 4 shown, the IAB node 300 includes a wireless communicator 310 and a controller 320. The IAB node 300 may include a plurality of wireless communicators 310.

[0053] The wireless communicator 310 performs wireless communication with the gNB 200 (BH link) and performs wireless communication with the UE 100 (access link). A wireless communicator 310 for BH link communication and a wireless communicator 310 for access link communication may be provided separately.

[0054] The wireless communicator 310 includes a receiver 311 and a transmitter 312. The receiver 311 performs various types of reception under the control of the controller 320. The receiver 311 includes an antenna, converts the radio signal received by the antenna into a baseband signal (received signal), and outputs the baseband signal to the controller 320. The transmitter 312 performs various types of transmission under the control of the controller 320. The transmitter 312 includes an antenna, converts the baseband signal (transmitted signal) output by the controller 320 into a radio signal, and transmits the radio signal from the antenna.

[0055] The controller 320 performs various types of control in the IAB node 300. The controller 320 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs to be executed by the processor and information to be used for the processing performed by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation and demodulation, encoding and decoding, etc. of the baseband signal. The CPU executes the programs stored in the memory, thereby performing various types of processing. The processor performs the processing of the layers described below.

[0056] Configuration of User Equipment

[0057] In an embodiment, the configuration of the UE 100 as a user equipment will be described. Figure 5 FIG. is a diagram showing the configuration of the UE 100. As Figure 5 shown, the UE 100 includes a wireless communicator 110 and a controller 120.

[0058] The wireless communicator 110 performs wireless communication in the access link. Specifically, it performs wireless communication with the gNB 200 and wireless communication with the IAB node 300. The wireless communicator 110 may perform wireless communication in the secondary link, that is, wireless communication with another UE 100. The wireless communicator 110 includes a receiver 111 and a transmitter 112. The receiver 111 performs various types of reception under the control of the controller 120. The receiver 111 includes an antenna, converts the radio signal received by the antenna into a baseband signal (received signal), and outputs the baseband signal to the controller 120. The transmitter 112 performs various types of transmission under the control of the controller 120. The transmitter 112 includes an antenna, converts the baseband signal (transmitted signal) output by the controller 120 into a radio signal, and transmits the radio signal from the antenna.

[0059] The controller 120 performs various types of control in the UE 100. The controller 120 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs to be executed by the processor and information to be used for the processing performed by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation and demodulation, encoding and decoding, etc. of the baseband signal. The CPU executes the programs stored in the memory, thereby performing various types of processing. The processor performs the processing of the layers described below.

[0060] Configuration of the protocol stack

[0061] In an embodiment, the configuration of the protocol stack will be described. Figure 6 It is a diagram showing the protocol stack related to the RRC connection and NAS connection of the IAB-MT.

[0062] As Figure 6 shown, the IAB-MT of the IAB node 300-2 includes a physical (PHY) layer, a media 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.

[0063] 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 via a physical channel between the PHY layer of the IAB-MT of the IAB node 300-2 and the PHY layer of the IAB-DU of the IAB node 300-1.

[0064] The MAC layer performs priority control of data, retransmission handling via Hybrid Automatic Repeat reQuest (HARQ), random access procedures, etc. Data and control information are transmitted via a transport channel between the MAC layer of the IAB-MT of IAB node 300-2 and the MAC layer of the IAB-DU of IAB node 300-1. The MAC layer of the IAB-DU includes a scheduler. The scheduler determines the transmission format (transport block size, modulation and coding scheme (MCS)) and resource blocks to be allocated in the uplink and downlink.

[0065] The RLC layer transmits data to the RLC layer at the receiving end by using the functions of the MAC layer and the PHY layer. Data and control information are transmitted via a logical channel 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.

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

[0067] The RRC layer controls logical channels, transport channels, and physical channels according to the establishment, reconstruction, and release of radio bearers. RRC signaling for various configurations 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 to the donor gNB 200, the IAB-MT is in the RRC connected state. When there is no RRC connection to the donor gNB 200, the IAB-MT is in the RRC idle state.

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

[0069] Figure 7 is a diagram showing a protocol stack related to the F1-U protocol. Figure 8 is a diagram showing a protocol stack related to the F1-C protocol. Here, an example is shown in which the donor gNB 200 is divided into a CU and a DU.

[0070] As Figure 7As shown, each of the IAB-MT of the IAB node 300-2, the IAB-DU of the IAB node 300-1, the IAB-MT of the IAB node 300-1, and the DU of the donor gNB 200 includes a backhaul adaptation protocol (BAP) layer as the upper layer of the RLC layer. The BAP layer is the layer that performs routing processing and bearer mapping and demapping processing. In the backhaul, the Internet Protocol (IP) layer is sent via the BAP layer to allow routing through multiple hops.

[0071] In each backhaul link, the protocol data unit (PDU) of the BAP layer is sent through the backhaul RLC channel (BH NR RLC channel). Configuring multiple backhaul RLC channels in each BH link can achieve traffic prioritization and Quality of Service (QoS) control. The association between the BAP PDU and the backhaul RLC channel is performed by the BAP layer of each IAB node 300 and the BAP layer of the donor gNB 200.

[0072] As Figure 8 shown, the protocol stack of the F1-C protocol includes an application protocol (F1AP) layer and a Stream Control Transmission Protocol (SCTP) layer, which respectively replace the GPRS Tunneling Protocol (GTP-U) layer and the User Datagram Protocol (UDP) layer for the user plane shown in Figure 7 .

[0073] First Embodiment

[0074] The operation of the cellular communication system 1 will be described assuming the configuration of the cellular communication system 1 as described above.

[0075] In the first embodiment, a scenario is assumed in which the IAB node 300 (specifically, the IAB-MT) performs a connection conversion between the donor gNBs 200. The IAB node 300 can be a mobile IAB node 300. Connection conversion refers to handover or RRC reconstruction. Handover refers to the operation of the IAB-MT in the RRC connected state to change cells. RRC reconstruction refers to the operation of the IAB-MT in the RRC connected state to reconnect to another cell in response to detecting a radio link failure. Hereinafter, an example in which the connection conversion is a handover will be described; however, the connection conversion can be RRC reconstruction.

[0076] In the scenario where the IAB node 300 performs a connection conversion between the donor gNBs 200, the operation of the UE 100 under the control of the IAB node 300 becomes a problem. Specifically, when the IAB node 300 performs a connection conversion between the donor gNBs 200, the UE 100 under the control of the IAB node 300 may require new operations. However, from the perspective of backward compatibility, it is not preferable to change the operation of the UE100.

[0077] The first embodiment is an example of implementing a connection conversion (e.g., handover) between donor gNBs 200 in the IAB node 300, where there are only operational changes on the network side (IAB node side), and it is transparent to the UE 100 side. Such a handover can be referred to as an inter-CU handover.

[0078] Specifically, in the first embodiment, first, the IAB node 300 including the UE 100 under the control of the IAB node 300 performs a handover from the source donor gNB 200S, which is the 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 when the handover is performed, 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 instructing the handover to the target donor gNB 200T to the UE 100 via the target donor gNB 200T.

[0079] In other words, the RRC connection (and PDCP connection) between the UE 100 and the source donor gNB 200 continues to be in an established state via the target donor gNB 200, and the source donor gNB 200S sends a handover command to the UE 100 using the RRC connection. Therefore, the handover between the donor gNBs 200 in the IAB node 300 can be achieved without making operational changes to the UE 100.

[0080] In the first embodiment, a data path can be established between the source donor gNB 200S and the target donor gNB 200T. From the handover in the IAB node 300 until the handover in the UE 100 is completed, the process of forwarding the data of the UE 100 (i.e., data forwarding) can be performed via the data path. Even when the handover in the IAB node 300 is performed first and then the handover in the UE 100 is performed, this can suppress the loss of the data of the UE 100.

[0081] Figure 9 is a diagram showing the operations according to the first embodiment.

[0082] As Figure 9 shown, in step S101, the UE 100 is in a state (RRC connection state) where the UE 100 has established an RRC connection with the source donor gNB 200S.

[0083] In step S102, the IAB node 300 (IAB-MT) is in a state where the IAB node 300 has established an RRC connection with the source donor gNB 200S (RRC connected state). There may be at least one intermediate IAB node 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). In other words, the UE 100 uses the cell of the IAB node 300 (IAB-DU) as the serving cell of the UE 100.

[0084] 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 description is provided based on the assumption that the IAB node 300 (IAB-MT) performs a handover.

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

[0086] At this time, the RRC layer and PDCP layer of the UE 100 are still connected to the source donor gNB 200. Therefore, the UE 100 cannot communicate with the target donor gNB 200T on either the C-plane or the U-plane.

[0087] Here, a tunnel (i.e., a path for data forwarding) is formed between the source donor gNB 200S and the target donor gNB 200T. This tunnel can be configured on the inter-base station interface or can be configured via the core network.

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

[0089] In step S106, the IAB node 300 sends the user data from the UE 100 to the target donor gNB 200T. The target donor gNB 200T receives the user data.

[0090] In step S107, the target donor gNB 200T forwards the user data received in step S106 to the source donor gNB 200S (data forwarding). The source donor gNB 200S receives the user data.

[0091] In step S108, the source donor gNB 200S forwards the user data received in step S107 to the UPF 12 in the core network.

[0092] In step S109, the source donor gNB 200S receives downlink user data from the UPF 12 of the core network.

[0093] In step S110, the source donor gNB 200S forwards the user data received in step S109 to the target donor gNB 200T (data forwarding). The target donor gNB 200T receives the user data.

[0094] 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.

[0095] In step S112, the IAB node 300 sends (relays) the user data received in step S111 to the UE 100.

[0096] In this way, the transmission and reception of user data between the UE 100 and the source donor gNB 200S continue via the tunnel between the source donor gNB 200S and the target donor gNB 200T and the target donor gNB 200T.

[0097] In step S113, the source donor gNB 200S sends a handover command (HO command) instructing the UE 100 to perform a handover to the target donor gNB 200T via the tunnel between the source donor gNB 200S and the target donor gNB 200S. The target donor gNB 200 receives the handover command.

[0098] In step S114, the target donor gNB 200T sends an RRC message (RRC reconfiguration) including the handover command received in step S113 to the UE 100. Specifically, the target donor gNB 200T sends the RRC message to the UE 100 via the IAB node 300. The UE 100 receives the RRC message.

[0099] Figure 10 is a diagram showing the protocol stack when transmitting the handover command. As Figure 10 shown, the handover command (RRC reconfiguration) is sent 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 the IAB node 300. The communication between the source donor gNB 200S and the target donor gNB 200T is performed through inter-base station communication. Figure 10 shows an example using GTP, but the embodiment is not limited thereto. For example, Xn-AP can be used, and in this case, the handover command is included (encapsulated) in the RRC container of the Xn-AP message to be sent.

[0100] Referring again to Figure 9 , in step S115, in response to the handover command, UE 100 sends an RRC message (RRC reconfiguration complete) indicating the completion of the handover to the target donor gNB 200T. Specifically, UE 100 sends this RRC message to the target donor gNB 200T via the IAB node 300. The target donor gNB 200T receives this RRC message. Here, UE 100 continues to be under the control of the IAB node 300, so it can perform a RACH-less handover, in which the transmission of the random access preamble and the reception of the random access response are omitted. In this case, in the handover command, the UE 100 can be instructed to perform a RACH-less handover.

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

[0102] In step S117, UE 100 sends uplink user data to the IAB node 300. The IAB node 300 receives the user data.

[0103] In step S118, the IAB node 300 sends the user data received in step S117 to the target donor gNB 200T. The target donor gNB 200T receives the user data.

[0104] In step S119, the target donor gNB 200T forwards the user data received in step S118 to the UPF 12 of the core network.

[0105] In step S120, the target donor gNB 200T receives downlink user data from the UPF 12 of the core network.

[0106] 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.

[0107] In step S122, the IAB node 300 sends (relays) the user data received in step S121 to UE 100.

[0108] Second Embodiment

[0109] The second embodiment will be described with a main focus on the differences from the above embodiment.

[0110] The second embodiment is an embodiment related to load balancing in the IAB topology. In the IAB node 300, the paths in the IAB topology are basically determined in a semi-fixed manner based on the routing table (BAP routing ID and path ID), and the CU of the donor gNB 200 uniformly manages the routing table. However, the efficient use of multiple paths can achieve more dynamic load balancing.

[0111] In the second embodiment, the IAB node 300 performs efficient data relaying in consideration of the data relaying capabilities of each of the multiple relay destination nodes (multiple paths). Specifically, in the second embodiment, the IAB node 300 that performs data relaying from the relay source node to the multiple relay destination nodes receives the capability information related to the data relaying capabilities of the target IAB node 300 included in the multiple relay destination nodes. Then, the IAB node 300 controls the data relaying based on the received capability information.

[0112] The capability information may include information indicating whether there are multiple nodes in the next hop of the target IAB node 300 included in the multiple relay destination nodes. When there are multiple nodes in the next hop of the target IAB node 300, it can be considered that the target IAB node 300 has a relatively large data relaying capability. Therefore, preferentially relaying data to such a target IAB node 300 enables the efficient use of multiple paths.

[0113] The IAB node 300 may receive the capability information related to each of the multiple relay destination nodes, and control the data transmission ratio of each of the multiple relay destination nodes based on the received capability information. For example, the IAB node 300 relays more data to the relay destination node with a relatively large data relaying capability, and relays less data to other relay destination nodes with a relatively small data relaying capability.

[0114] As described above, the IAB node 300 selects the data relay destination from the multiple relay destination nodes according to the routing configuration (routing table) configured by the donor gNB 200. When a predetermined condition is satisfied, the IAB node 300 may perform local routing to select the data relay destination without following the routing configuration. Here, the predetermined condition may include the following conditions: a failure occurrence notification or a local routing request has been received from any one of the multiple relay destination nodes.

[0115] As described above, basically, the IAB node 300 performs routing according to the configuration from the donor gNB 200S, and in the case of a failure in the relay destination node or a request from the relay destination node, the IAB node 300 itself performs local routing. In this way, the IAB node 300 can relay data to an appropriate relay destination node according to the situation.

[0116] (1) Upstream relay operation

[0117] In the second embodiment, the upstream relay operation will be described.

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

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

[0120] Each IAB node among the IAB nodes 300a to 300g sends information indicating whether there are multiple nodes in the next hop of each IAB node among the IAB nodes 300a to 300g as the capability information of each IAB node among the IAB nodes 300a to 300g. In the upstream relay operation, this kind of capability information is called "BH connection information". Specific examples of the BH connection information will be described below. By the IAB node 300 sending this kind of BH connection information to its child node, the child node can identify the potential capabilities of its parent node, and thus can perform efficient data relay when performing local routing.

[0121] The BH whose node includes one next-hop node is called "single BH", and the BH whose node includes two next-hop nodes is called "dual BH". In Figure 11In the example, each of the IAB nodes 300b, 300c, 300e, 300f, and 300g is a single BH. In contrast, each of the IAB nodes 300a and 300d is a dual BH, and the dual BH can be considered to have a greater data relay capability than the single BH. Note that for the dual BH, a duplex connection can be established in a dual connection manner.

[0122] For example, the IAB node 300 determines a transmission ratio based on the BH connection information of the parent nodes (IAB nodes 300a and 300b). Since 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 3. Therefore, when the IAB node 300 performs local routing, the IAB node 300 configures the transmission ratio of the IAB node 300a as "2 / 3" and configures the transmission ratio of the IAB node 300b as the remaining "1 / 3". Note that the transmission ratio of a certain parent node can be configured to zero. In this case, the determination of the transmission ratio can be considered as path selection (path conversion).

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

[0124] As Figure 12 shown, in step S201, the IAB node 300 performs routing based on the routing configuration configured from the donor gNB 200.

[0125] In step S202, the IAB node 300 determines whether the start condition for local routing has been satisfied. For example, the start condition is one of the following. Parameters (thresholds, etc.) for defining the start condition can be configured from the donor gNB 200 to the IAB node 300.

[0126] - Condition: A BH failure occurrence notification has been received from the parent node:

[0127] For example, a BH failure occurrence notification in the parent node is sent from the parent node to the IAB node 300 on the BH RLF indication which is a message of the BAP layer. The BH failure occurrence notification can be a notification indicating that a radio link failure (RLF) has occurred in the BH of the parent node, can be a notification indicating that the parent node is in the middle of the process of recovering from the RLF of the BH, or can be a notification indicating that the recovery from the RLF of the BH of the parent node has failed.

[0128] - Condition: The uplink throughput to a certain parent node has dropped to or below a certain value:

[0129] For example, a case where a scheduling request (SR) sent from the IAB node 300 to a certain parent node has been ignored a certain number of times or more (e.g., no uplink grant is returned) may fall under this condition. A case where the uplink throughput of the parent node is compared and a certain difference (deviation) has occurred between the uplink throughputs in a past certain time period or a greater difference has occurred (and the state has lasted for a certain time period or longer) may fall under this condition. A case where the uplink throughput of a certain parent node has dropped to or below a certain value (and the state has lasted for a certain time period or longer) may fall under this condition.

[0130] - Condition: A local routing request has been received from the parent node:

[0131] The local routing request can be sent from the parent node on a message of the BAP layer. The local routing request can be sent from the donor gNB 200 on an F1 message or an RRC message via the parent node. The IAB node 300 can send a response to the local routing request from the parent node, or can notify the parent node of the transmission ratio described below.

[0132] The local routing request can include an identifier of a target bearer (or RLC channel or logical channel) to encounter local routing. The IAB node 300 performs local routing on the target bearer (or RLC channel or logical channel), and does not perform local routing on non-target bearers (or RLC channels or logical channels) (i.e., performs routing on non-target bearers according to the routing table).

[0133] - Condition: The uplink buffer amount of the IAB node 300 or its child nodes has reached or exceeded a certain value (and the state has lasted for a certain time period or longer):

[0134] For example, the IAB node 300 can identify the uplink buffer amount of the child node based on a buffer status report (BSR) received from the child node. The BSR can consider the uplink buffer amount of the child node's child nodes (i.e., grandchild nodes). A case where the uplink buffer amount indicated by the BSR has reached or exceeded a certain value (and the state has lasted for a certain time period or longer) may fall under this condition.

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

[0136] In contrast, if the start condition for local routing is satisfied (step S202: Yes), the IAB node 300 starts operations related to local routing. Note that the IAB node 300 can perform local routing only when the donor gNB 200 permits the execution of local routing. This permission is carried out by using messages of the BAP layer (BAP control PDU), system information (SIB1), RRC reconfiguration, etc. Whether local routing can be performed can be configured for each bearer (RLC channel), or it can be configured commonly for all bearers. Along with such configuration, which condition among the above conditions is to be applied and the threshold for determining that condition can be configured.

[0137] In step S203, the IAB node 300 receives the BH connection information of each parent node. Note that step S203 can be executed before step S202.

[0138] The BH connection information of the parent node may include information indicating whether the parent node is a single BH or a dual BH (or triple BH). The BH connection information of the parent node may include a numerical value indicating the number of BHs of the parent node. The BH connection information may also include information related to the capabilities of each BH link. For example, the information related to the capabilities of each BH link may be information indicating at least one item selected from the group consisting of the bandwidth of each BH link, the number of component carriers, and the frequency band, or it may be information indicating the average throughput (or maximum throughput, or guaranteed bit rate (GBR)) of each BH link.

[0139] The BH connection information can be sent 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) sent by the parent node. When the parent node is a dual BH (or triple BH), the parent node can send the BH connection information, and when the parent node is a single BH, the parent node may not send the BH connection information. The IAB node 300 differentiates between single BH and dual BH based on the presence or absence of the transmission of the BH connection information.

[0140] Alternatively, the BH connection information can be sent from the donor gNB 200 to the IAB node 300. The BH connection information may be an information element included in an RRC message (e.g., RRC reconfiguration) or an F1 message (e.g., DL information transfer) sent by the donor gNB 200.

[0141] In step S204, the IAB node 300 determines the uplink packet transmission ratio based on the BH connection information received in step S203. As in the above example, when one parent node is dual BH and the other parent node is single BH, the IAB node 300 configures the transmission ratio of the one parent node as "2 / 3", and configures the transmission ratio of the other parent node as "1 / 3". Here, for example, when the transmission ratio is configured as 0:1, it is considered that the transmission destination has been switched (local switching has been performed). The IAB node 300 can adjust or determine the transmission ratio based on the information included in the BH connection information (e.g., information related to the capabilities of each BH link). The IAB node 300 can adjust or determine the transmission ratio based on the throughput history of previous transmissions to each parent node (or the history of uplink grants to child nodes (i.e., received throughput)).

[0142] In step S205, the IAB node 300 performs local routing of the uplink packets based on the transmission ratio determined (and adjusted) in step S204. The IAB node 300 can change the header of the uplink packets encountering local routing. For example, in the BAP header, the routing ID can be changed, and an identifier indicating that local routing has been performed can be provided.

[0143] In step S206, the IAB node 300 determines whether the end condition for local routing has been met. The end condition can be a condition opposite to the above start condition. For example, the end condition is at least one condition selected from the group consisting of: a BH recovery success notification has been received from the parent node, the throughput to a certain parent node has been restored, a local routing stop request has been received, and the buffer status of the child nodes (and grandchild nodes) has been improved. The end condition can include the following condition: the local routing permission has been cancelled by the donor gNB 200 (configured as "not permitted").

[0144] When the end condition for local routing is not met (step S206: No), the IAB node 300 continues local routing (step S205). In contrast, when the end condition for local routing is met (step S206: Yes), the IAB node 300 performs routing based on the routing configuration configured by the donor gNB 200 (step S201).

[0145] (2) Downstream relay operation

[0146] In the second embodiment, the downstream relay operation will be described.

[0147] Figure 13This is a diagram for illustrating the downstream relay operation according to the second embodiment. In the downstream relay operation, the relay source node of the IAB node 300 is the parent node of the IAB node 300, and the relay 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 the child node in the above upstream relay operation are replaced with each other. Note that Figure 13 An example is shown 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).

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

[0149] As Figure 14 shown, in step S301, the IAB node 300 performs routing based on the routing configuration configured from the donor gNB 200.

[0150] In step S302, the IAB node 300 determines whether the start condition for local routing has been satisfied. For example, the start condition is one of the following. Parameters (thresholds, etc.) for defining the start condition can be configured from the donor gNB 200 to the IAB node 300. The IAB node 300 can perform local routing only when the donor gNB 200 permits (configures) local routing. This permission can be performed by using an F1 message (F1AP), an RRC message, or a BAP message. This permission can be configured for each bearer (RLC channel), or can be configured commonly for all bearers. This permission can be an instruction. Which condition among the following conditions and the threshold for determining this condition can be configured to be applied.

[0151] - Condition: The throughput of a certain path has dropped to or below a certain value (and this state has continued for a certain period or longer):

[0152] - Condition: The radio state of a certain child node has deteriorated (and this state has continued for a certain period or longer):

[0153] For example, the IAB node 300 can determine the radio state based on the measurement report from the child node and / or the scheduling result (MCS, etc.) for the child node.

[0154] - Condition: The available buffer size of a certain child node is lower than a certain value (and this state has continued for a certain period or longer):

[0155] For example, the IAB-DU of the IAB node 300 sends a flow control polling BAP control PDU to the 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 (amount of available buffer) indicated by the flow control feedback BAP control PDU and performs a determination.

[0156] When the start condition for local routing is not satisfied (step S302: No), the IAB node 300 continues routing based on the routing configuration configured from the donor gNB 200 (step S301).

[0157] In contrast, when the start condition for local routing is satisfied (step S302: Yes), the IAB node 300 starts operations related to local routing. The IAB node 300 can select different paths with the same destination from the routing configuration and send the downlink packet to the IAB node corresponding to the path. The IAB node 300 can change the header of the downlink packet encountering local routing. For example, in the BAP header, the routing ID can be changed, and an identifier indicating that local routing has been performed can be provided.

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

[0159] In step S304, the IAB node 300 selects a downstream path and / or determines the transmission ratio of the child node. Specifically, the IAB node 300 selects other paths with the same destination from the stored routing configuration. The IAB node 300 can select multiple paths, and in this case, the IAB node 300 can determine the transmission ratio in the same and / or similar manner as the upstream relay operation described above. The combination of alternative paths from the donor gNB 200 to the IAB node 300 can be pre-configured.

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

[0161] In step S306, the IAB node 300 determines whether the end condition for local routing has been satisfied. The end condition can be a condition opposite to the above start condition. For example, the end condition is at least one condition selected from the group consisting of: the throughput of a certain path has recovered to or exceeded a certain value, the radio state of the child node has recovered to or exceeded a certain value, and the available buffer size of the child node has recovered to or exceeded a certain value. The end condition can include the following condition: the local routing permission has been cancelled by the donor gNB 200 (configured as "not permitted").

[0162] When the local routing end condition is not satisfied (step S306: No), the IAB node 300 continues local routing (step S305). In contrast, when the end condition of local routing is satisfied (step S306: Yes), the IAB node 300 performs routing based on the routing configuration configured from the donor gNB 200 (step S301).

[0163] Variant 1 of the second embodiment

[0164] Variant 1 of the second embodiment will be described mainly focusing on the differences from the above embodiment.

[0165] In the above second embodiment, the donor gNB 200 may not be able to recognize the details of the local routing performed by the IAB node 300 (when the local routing has been performed and how many times the local routing has been performed). When performing local routing, the routing configuration configured by the donor gNB 200 may be defective, or a failure may have occurred in the IAB topology. Therefore, the donor gNB 200 preferably can recognize the details of the local routing. Thus, for example, the donor gNB 200 can optimize the routing configuration.

[0166] In this variant example, the IAB node 300 that performs data relaying from a relay source node to a plurality of relay destination nodes selects a data relay destination from the plurality of relay destination nodes according to the routing configuration configured from the donor gNB 200. When a predetermined condition is satisfied, the IAB node 300 performs local routing for selecting a data relay destination without following the routing configuration (see the second embodiment). The IAB node 300 sends historical information related to the local routing (that is, information indicating the details of the local routing) to the donor gNB 200.

[0167] Figure 15 is a diagram showing the operation according to Variant 1 of the second embodiment.

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

[0169] In step S402, the IAB node 300 stores information related to the local routing performed in step S401 (local routing information). Each time the IAB node 300 performs local routing, the IAB node 300 stores the local routing information.

[0170] The local routing information may include at least one selected from the group consisting of: a timestamp indicating the execution time of the local routing, location information (latitude, longitude, and altitude) indicating the execution location of the local routing, and information indicating the radio state during the execution of the local routing. The local routing information may include the routing ID (path ID and destination) before and after being changed due to the local routing. The local routing information may include the topology ID of the IAB topology being connected (which may be the donor gNB ID or gNB-CU ID). The local routing information may include information indicating the reason (or condition) for executing the local routing. The local routing information may include information indicating the time period (start time, end time) during which the local routing has been executed and / or the number of times the local routing has been executed. 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 at each occasion and then stored in the RRC layer.

[0171] In step S403, the IAB node 300 sends the local routing information stored in step S402 to the donor gNB 200. For example, the local routing information is sent from the IAB node 300 on an RRC message. In response to a request from the donor gNB 200, the local routing information may be sent as a response message. For example, the local routing information may be sent as a UE information response to a UE information request.

[0172] Variant 2 of the second embodiment

[0173] Variant 2 of the second embodiment will be described with a main focus on the differences from the above embodiments. This variant is an example where the donor gNB 200 changes the routing configuration of the IAB node 300 in response to a request from the IAB node 300.

[0174] In this variant example, the IAB node 300 that performs data relaying from a relay source node to a plurality of relay destination nodes selects a data relay destination from the plurality of relay destination nodes according to the routing configuration configured by the donor gNB 200. The IAB node 300 sends a routing configuration change request for changing the routing configuration to the donor gNB 200.

[0175] Figure 16 is a diagram showing the operation according to Variant 2 of the second embodiment.

[0176] As Figure 16As shown, in step S501, the IAB node 300 sends a routing configuration change request to the donor gNB 200. This routing configuration change request can be a notification of the desired routing change. This routing configuration change request can be an RRC message or an F1 message (F1AP). The routing configuration change request can be defined separately for the case of upstream routing change and the case of downstream routing change. This routing configuration change request can only be sent when the donor gNB 200 permits the sending.

[0177] The IAB node 300 can send the routing configuration change request by triggering, and this trigger is to meet the same conditions as the start conditions of the local routing described in the second embodiment above. Which condition and determination threshold can be configured from the donor gNB 200 to the IAB node 300. The IAB node 300 can send the routing configuration change request only when the donor gNB 200 permits (configures) the sending.

[0178] This routing configuration change request can include at least one selected from the group consisting of: information indicating the reason (or condition) for the need of routing configuration change, the routing ID (path ID and destination) of the configuration change target, and the RLC channel ID of the configuration change target (which can be a bearer ID or an LCID).

[0179] In the case of upstream routing change, the IAB node 300 can include the BSR value of the IAB node 300 in the routing configuration change request. When the IAB node 300 is dual BH (dual connection), the BSR value can be included in the routing configuration change request for each parent node (for each path). The IAB node 300 can include the BSR value of the child node of the IAB node 300, or the BSR value of the IAB node 300 that takes into account the BSR value of the child node of the IAB node 300 in the routing configuration change request. Each IAB node 300 in the IAB topology can periodically perform the transmission of such BSR values to the donor gNB 200.

[0180] In the case of downstream routing change, the IAB node 300 can include the available buffer size value of the IAB node 300 and / or the available buffer size value of the child node of the IAB node 300 (flow control feedback BAP control PDU value) in the routing configuration change request. Each IAB node 300 in the IAB topology can periodically perform the transmission of such available buffer size values to the donor gNB 200.

[0181] In step S502, the donor gNB 200 changes the routing configuration of the IAB node 300 in response to the routing configuration 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 needed.

[0182] Note that the IAB node 300 may start a timer when the IAB node 300 sends a routing configuration change request, and may be inhibited from sending the next routing configuration change request until the timer expires. The timer value of the timer can be configured from the donor gNB 200 to the IAB node 300.

[0183] Other embodiments

[0184] The above embodiments and variations can be implemented by combining different embodiments and variations with each other. Variations 1 and 2 of the second embodiment can be implemented together with the second embodiment, or can be implemented separately from the second embodiment.

[0185] The above embodiments and variations are provided by taking the relay transmission performed by the IAB as an example for description, but are not limited thereto. The above embodiments and variations can be applied to other relay transmission systems. For example, the operations according to the above embodiments and variations can be applied to relay nodes (layer 3 relay nodes), secondary link relay nodes (relay nodes using a secondary link, and the secondary link is used for direct communication between user equipments), etc.

[0186] In the above embodiments, an example in which the cellular communication system 1 is a 5G cellular communication system is mainly described. However, the base station in the cellular communication system 1 may be an eNB as an LTE base station. The core network in the cellular communication system 1 may be an evolved packet core (EPC). 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 or X2 interface).

[0187] A program can be provided that causes a computer to execute each processing operation according to the above embodiments and variations. The program can be recorded on a computer-readable medium. Using the computer-readable medium enables the program to 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 for example, may be a recording medium such as a CD-ROM or a DVD-ROM. A chipset including a memory and a processor can be provided. The memory stores a program for executing each processing operation performed by the UE 100, the gNB 200, or the IAB node 300, and the processor executes the program stored in the memory.

[0188] This application claims priority to U.S. Provisional Application No. 63 / 061887, filed on August 6, 2020, the entire content of which is incorporated herein by reference.

[0189] Supplementary Notes

[0190] Introduction

[0191] The amendment work item related to New Radio Enhanced Integrated Access and Backhaul (NR eIAB) was approved. Some of its objectives are as follows.

[0192] Enhancement of Topology Adaptation

[0193] - Specification of procedures for migration between donor IAB nodes for enhanced robustness and load balancing, including enhanced functions for reducing signaling load.

[0194] - Specification of enhancements for reducing service interruptions due to IAB node migration and BH RLF recovery.

[0195] - Specification of enhancements for topology redundancy, including support for CP / UP separation.

[0196] Enhancement of Topology, Routing, and Transmission

[0197] - Specification of enhancements for improving topology scope fairness, multi-hop latency, and congestion mitigation.

[0198] In the supplementary notes, the first issue regarding the enhancement of topology adaptation for eIAB in Release 17 to be considered will be discussed from the following aspects: assumptions about backhaul link quality, enhancements to BH RLF indication, BH RLF recovery and cell (re)selection, and enhancements to lossless transfer.

[0199] Discussion

[0200] Assumptions about Backhaul Link Quality

[0201] In the study phase of Release 15, as a requirement background, the TR stated as follows: "Radio backhaul links are vulnerable to obstacles caused by moving objects (e.g., vehicles), seasonal changes (leaves), changes in infrastructure (new buildings), etc. This vulnerability also applies to physically stationary IAB nodes." Therefore, as already reflected in the TR, various problems caused by multi-hop / radio backhaul and potential solutions to these problems were studied.

[0202] Finding 1: In the study of Release 15, various problems caused by unstable backhaul links and potential solutions to these problems were identified, which were fully reflected in TR 38.874.

[0203] In the specification work of Release 16, it is assumed that the IAB node is stationary, i.e., a "stationary IAB node". Therefore, even in the case of a backhaul link via millimeter wave and / or a local IAB node that can be deployed using an unmanaged method, the backhaul (BH) is stable enough in a properly designed deployment. Therefore, only a recovery process combined with the basic function of BH RLF is defined. This basic function is an existing function, such as BH RLF indication (also known as type 4, i.e., "recovery failure"), RRC reconstruction, MCG / SCG failure indication, and / or conditional handover.

[0204] Finding 2: In Release 16 IAB, only stationary IAB nodes with a sufficiently stable backhaul link are assumed.

[0205] In the enhancement of Release 17, one expected use case is a "mobile IAB node", which can be part of "migration between donor IAB nodes" (even if not explicitly described in the WID). The secondary objectives in the WID (e.g., "reduce service interruption due to IAB node migration and BH RLF recovery" and "enhancement of topological redundancy") clearly imply that the BH link is unstable, and migrations and BH RLF occur frequently in the Release 17 deployment scenario. Therefore, according to the discussion in Release 17, first of all, RAN2 should reach a consensus on the assumptions of the BH link.

[0206] Recommendation 1: RAN2 should assume that the quality of the backhaul link changes dynamically. Therefore, backhaul RLF is not as rare as in Release 17 eIAB.

[0207] Enhancement of BH RLF indication

[0208] In the email discussion of Release 16, four types of BH RLF notifications as shown Figure 17 were discussed.

[0209] Finally, only "recovery failure" as type 4 is defined as the BH RLF indication in Release 16. Thereby, the sub-IAB-MT considers the RLF on the BH link and initiates the RLF recovery process.

[0210] Finding 3: In Release 16, only "recovery failure" as type 4 is defined as the BH RLF indication.

[0211] On the other hand, many companies still consider other types of indications useful, so this was further discussed via email. Eight out of the thirteen companies are willing to introduce "attempt to recover" as type 2, and two other companies are considering discussing this in version 17. Therefore, it can be assumed that a large number of companies think they are ready to introduce type 2 indications into version 17. The method for sending type 2 indications needs further study. Examples of this method include using BAP control PDU, SIB1, or both. Note that type 1 and type 2 have exactly the same meaning.

[0212] Recommendation 2: RAN2 should agree to the fact that "attempt to recover" has been introduced as the BH RLF indication of type 2. Whether to use BAP control PDU, SIB1, or both to perform the transmission needs further study.

[0213] Nine out of the thirteen companies also agreed to discuss "BH link recovered" as type 3 in version 17. Specifically, it can be studied whether such an explicit indication is really needed. For example, when the type 2 indication is sent via SIB1 and the BH link is not in RLF (i.e., "recovered"), the indication is no longer broadcast. Therefore, downstream IAB nodes and UEs should identify whether the BH link has been recovered based on the absence of the type 2 indication on SIB1. Of course, when the type 3 indication is sent via BAP control PDU, the advantage is that downstream IAB nodes can know in a timely manner that the BH link has been recovered. Note that in this case, the UE does not include the BAP layer and thus cannot know this fact. Therefore, RAN2 should discuss whether the type 3 indication is necessary.

[0214] Recommendation 3: If Recommendation 3 can be agreed upon, RAN2 should discuss whether to introduce an explicit BH RLF indication, i.e., "BH link recovered" as type 3, when BH RLF no longer exists.

[0215] If Recommendation 2 and / or Recommendation 3 can be agreed upon, the operations during the BH link recovery of the IAB-MT that has received the indication should be studied. The recommendations are as follows: When the IAB-MT receives type 2, the IAB-MT reduces / stops SR, and when the IAB-MT receives type 3 (i.e., BH RLF no longer exists in the parent IAB node), the IAB-MT resumes operations. This operation is an expected operation of the IAB-MT when the parent node is attempting to recover the BH link. It is assumed that other operations of the IAB-MT (such as suspending the operations of all RBs) are also possible.

[0216] Recommendation 4: RAN2 should agree that when BH RLF no longer exists in the parent node, the IAB-MT that has received the type 2 indication and then reduces / stops the scheduling request resumes the scheduling request.

[0217] Recommendation 5: RAN2 should discuss whether there are operations of other IAB-MTs when the parent node is attempting to recover the BH link.

[0218] When the BH link of an IAB node is in RLF, it is assumed that the IAB-DU sending the indication sends a type 2 BH RLF indication. The indication is sent when RLF occurs in the BH link, so the case of single-connected BH is simple. However, the case of duplex-connected BH is slightly more complex. For example, when an IAB node detects RLF in MCG, the IAB node initiates the MCG failure information procedure; however, the SCG continues to act as the BH link, so at this time, it may not be necessary to send a type 2 indication. When the MCG failure information procedure fails due to the timeout of T316, etc., the IAB-MT initiates RRC reconstruction, so at this time, a type 2 indication is sent. Therefore, the type 2 indication is sent when RRC reconstruction is initiated, rather than when the MCG / SCG failure information is triggered. In either case, since this involves the operation of the IAB-DU, it should be carefully studied whether to reflect this in the specification / how to reflect it. That is, it should be studied whether to add a note in stage 2 or stage 3 or whether nothing needs to be reflected.

[0219] Recommendation 6: RAN2 should agree on the fact that the type 2 BH RLF indication can be sent when the IAB-DU initiates RRC reconstruction, rather than when the IAB-DU initiates any RLF recovery procedure.

[0220] Recommendation 7: RAN2 should discuss whether to reflect the operation of the IAB-DU (i.e., Recommendation 6) in the specification / how to reflect this operation.

[0221] Enhancements to BH RLF Recovery and Cell (Re)selection

[0222] During the RRC reconstruction process, the IAB-MT first performs a cell selection process to find a suitable cell. In the cell selection process, potential problems were pointed out in Release 16, such as the problem that the IAB-MT may select its descendant node. Therefore, this was discussed in the email discussion.

[0223] As Figure 18 shown, together with the reporter's views, five possible solutions were discussed and summarized.

[0224] The conclusion is "no further action on this topic in Release 16". This means that RAN2 agrees with "Option 4: Nothing is required because if there is no BH connection, the RRC reconstruction will fail". Option 4 requires waiting for the failure (T301 expiration) and finally entering the idle state. Therefore, even when further time is required for BH RLF recovery, Option 4 is acceptable in the Release 16 deployment scenario.

[0225] Finding 4: In Release 16, when an IAB node attempts to initiate an RRC reconstruction request to a descendant node, the IAB node needs to wait for the attempt to fail and finally enter the idle state.

[0226] In Release 17, from the perspective of Recommendation 1, cell (re)selection and RRC reconstruction may occur frequently. Therefore, from the perspective of the stability of the IAB topology and service continuity, sub-optimal operations (i.e., operations according to Finding 4) will lead to significant performance degradation. Therefore, in order to optimize the operation of the IAB-MT during BH RLF recovery, as the reporter mentioned in the above email discussion, "this topic can be discussed again in Release 17".

[0227] Recommendation 8: RAN2 should agree to study the optimization of cell (re)selection to avoid reconstruction to an inappropriate node (e.g., a descendant node).

[0228] It can be assumed that: in addition to Option 4 above, a common concept in the identified solutions is that for the purpose of cell selection, the IAB-MT provides some type of whitelist or blacklist. For example, assume that in Release 17, due to "migration between donor IAB nodes", topology changes may occur frequently. Depending on the topology and the location of the IAB nodes, both the whitelist and the blacklist have their advantages and disadvantages.

[0229] For example, from the perspective of an IAB node close to the IAB donor (i.e., the top node in the DAG topology), since the number of candidate nodes is small and in some cases there is only one IAB donor DU, it is more reasonable to provide a whitelist.

[0230] However, in another example from the perspective of an IAB node that is far from the IAB donor (i.e., the bottom node in the DAG topology), a large number of candidate nodes may need to be included in the whitelist. On the contrary, for example, the blacklist only includes the downstream IAB nodes of the IAB nodes to be concerned about and in some cases only includes a small number of sub-IAB nodes, so in this case, it has the advantage of low overhead.

[0231] One issue worthy of attention regarding the whitelist is that due to the nature of "Donor IAB Node Migration between Versions" in Version 17, it may be necessary to include candidate IAB nodes belonging to different / adjacent IAB topologies, which may lead to an increase in the size of the list. On the other hand, needless to say, downstream IAB nodes belong to the same IAB topology, so the blacklist does not need to consider this issue.

[0232] Finding 5: Depending on the topology and location of the IAB node, both the whitelist and the blacklist have their advantages and disadvantages.

[0233] Therefore, when providing information to a child IAB node for cell selection purposes, it is desirable for the IAB donor (or parent IAB node) to be able to select the whitelist or the blacklist. Note that this information may be useful if it is reused for cell reselection purposes.

[0234] Recommendation 9: For cell selection purposes, RAN2 should agree to provide the whitelist or the blacklist (i.e., selection structure) to the IAB-MT to avoid reconstruction to descendant nodes. Whether these lists can also be used in the cell reselection process requires further study.

[0235] If Recommendation 9 can be agreed upon, the method of providing this information (i.e., the whitelist or the blacklist) should be further studied. Option 1 assumes CHO configuration and may require some enhancements. Option 2 assumes additional indication, examples of which include type 2 BHRLF indication. Option 3 assumes providing information on the overall topology that does not exist in the existing configuration. Option 5 assumes OAM-based configuration; however, as pointed out by the rapporteur, this is problematic.

[0236] Considering again the assumption in Version 17 (i.e., Recommendation 1), that is, the fact that when a topology change occurs, the parent IAB node or the IAB donor should provide the list to the child IAB node, the method of providing the whitelist / blacklist should be a dynamic method. Therefore, Option 5 (i.e., OAM) should be excluded. Which method (i.e., which of Options 1, 2, and 3) will be used as the baseline for enhancement requires further study.

[0237] Recommendation 10: RAN2 should agree to the fact that every time a topology change occurs, the parent IAB node or the IAB donor dynamically provides the whitelist / blacklist. The details need further study.

[0238] Enhancement of lossless transfer

[0239] During the study phase of Version 15, the issue of multi-hop RLC ARQ was discussed and reflected in Section 8.2.3 of the TR. In Version 16, a protocol stack was defined for IAB including the unsplit RLC layer. In other words, in Version 16, end-to-end ARQ was excluded and hop-by-hop ARQ was adopted.

[0240] Regarding per-hop ARQ, issues in terms of end-to-end reliability (i.e., lossless transmission of UL packets) were identified. As Figure 19 shown, three solutions were identified and evaluated.

[0241] In Release 16, the first solution, "modification of the PDCP protocol / procedure", was not adopted because it would affect Release 15 UEs.

[0242] The second solution, "rerouting PDCP PDUs buffered at intermediate IAB nodes", is supported as an implementation option in the BAP layer. The BAP layer can implement the second solution based on the assumption that, for example, data buffering in the transmission part of the BAP entity until the RLC-AM entity receives an acknowledgment response depends on the implementation. These BAP implementations were considered to avoid packet loss in "most" cases in the Release 16 deployment scenario (i.e., when using stationary IAB nodes); however, it is not as perfect as, for example, Figure 19 that.

[0243] The third solution, "introducing UL status transfer", is a promising solution for ensuring lossless transmission of UL data, taking into account the Figure 19 evaluation results mentioned in. The idea is to defer RLC ARQ to the UE, thereby initiating PDCP data recovery at the UE when necessary. However, this is not defined in Release 16 because, assuming stationary IAB nodes, it has been assumed that UL packets will rarely be discarded due to topology changes.

[0244] Considering the assumptions of Release 17, i.e., from the perspective of Proposal 1, UL packet loss during topology changes (which occurs frequently in Release 17) is no longer rare, so the third solution needs to be further studied. Therefore, in addition to the results reflected in the TR, RAN2 should also discuss enhanced mechanisms for ensuring lossless transmission in L2 multi-hop networks.

[0245] Proposal 11: RAN2 should agree to introduce the solution identified in TR 38.874, i.e., a mechanism for ensuring lossless transmission based on some form of "UL status transfer" in cases where topology changes may occur frequently.

[0246] In the email discussion as Figure 20 shown, the details of the third solution (i.e., "introducing UL status transfer") were discussed among two options (i.e., C-1 and C-2).

[0247] Regarding the above C-1, it is assumed that a "confirmation" from the IAB donor needs to be defined in the BAP or RRC for end-to-end signaling forwarding via the multi-hop L2 network. Therefore, to define this option, a relatively high standard of work will be required.

[0248] Regarding the above C-2, when C-2 is fully functional in the IAB topology and RLC ACKs are to be sent to the UE (or downstream IAB nodes), even if it is assumed that OAM uses this option to configure all IAB nodes, it ultimately depends on the IAB-DU implementation. Thus, C-2 can actually be implemented for Release 16 IAB nodes as well. Since hop-by-hop feedback is assumed and no additional control PDUs are assumed, C-2 is easier to implement than C-1. Therefore, C-2 should be the enhanced baseline for lossless transfer of UL packets in Release 17.

[0249] Finding 6: C-2 as a solution for "introducing UL state transfer" can be the enhanced baseline for Release 17 and can also be implemented in Release 16.

[0250] Note that since Release 17 should assume dynamic topology changes that cause UL packet loss, the enhancements in Release 17 will support C-2 as a standard supported feature. At least in the Phase 2 specification, the overall mechanism based on C-2 should be described. Otherwise, in the 3GPP standard, lossless transfer is not guaranteed during the handover of IAB nodes. In Phase 3, although minor changes are assumed (e.g., minor changes in RLC and / or BAP), these minor changes are considered internal operations of the IAB nodes, so their details may not need to be defined.

[0251] Recommendation 12: RAN2 should agree to the definition of the RLC ARQ mechanism for achieving lossless transfer of UL packets in Phase 2. This RLC ARQ mechanism delays the transmission of the ACK to the child node / UE (i.e., C-2) until the ACK is received from the parent IAB node. Whether / how to define the RLC ARQ mechanism in Phase 3 requires further study.

Claims

1. A communication control method, comprising: Performing, by an IAB node, a connection conversion from a first donor base station to a second donor base station, wherein the IAB node includes a user equipment under the control of the IAB node; After performing the connection conversion, continuing a data connection between the user equipment and the first donor base station via the second donor base station; And Sending, by the first donor base station via the second donor base station, user data destined for the user equipment to the user equipment.

2. The communication control method according to claim 1, comprising: After performing the connection conversion, continuing an RRC connection between the user equipment and the first donor base station via the second donor base station; And Sending, by the first donor base station via the second donor base station, an RRC message destined for the user equipment to the user equipment.

3. A first donor base station, comprising: A controller that converts a connection between an IAB node and the first donor base station to a second donor base station, wherein the IAB node includes a user equipment under the control of the IAB node; And A transmitter, After converting the connection, the controller continues a data connection between the user equipment and the first donor base station via the second donor base station, The transmitter sends user data destined for the user equipment to the user equipment via the second donor base station.

4. A system including a first donor base station, wherein, The first donor base station: Converts a connection between an IAB node and the first donor base station to a second donor base station, wherein the IAB node includes a user equipment under the control of the IAB node, After converting the connection, continues a data connection between the user equipment and the first donor base station via the second donor base station, and Sends user data destined for the user equipment to the user equipment via the second donor base station.

Images