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; hereinafter the same), 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 are involved 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 according to a routing setting set by a donor base station; and the relay node performing local routing to select the data destination without following the routing setting when a predetermined condition is satisfied. The predetermined condition includes a condition that a failure occurrence notification is 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, comprising: a relay node having a user equipment subordinate thereto switches a connection from a first donor base station to a second donor base station; even after the connection switching, an RRC (Radio Resource Control) connection between the user equipment and the first donor base station is continued via the second donor base station; and the first donor base station uses 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, comprising: a relay node that relays data from a source node to a plurality of destination nodes receiving capacity information regarding the data relay capacity of a target relay node included in the plurality of destination nodes from the target relay node; and the relay node controlling the data relay based on the capacity information.

[0006] A 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, comprising: 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; when a predetermined condition is satisfied, the relay node performs local routing to select the data destination without following the routing setting; and transmitting historical information regarding the local routing to the donor base station. [Brief description of the drawings]

[0008] [Figure 1] 1 is a diagram showing a configuration of a cellular communication system according to an embodiment. [Diagram 2] FIG. 2 is a diagram showing the relationship between IAB nodes, parent nodes, and child nodes. [Diagram 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 an embodiment. [Diagram 5] FIG. 2 is a diagram showing a configuration of a UE (user equipment) according to an embodiment. [Figure 6] A diagram showing the protocol stacks for IAB-MT RRC connection and NAS connection. [Figure 7] FIG. 2 illustrates a protocol stack for the F1-U protocol. [Figure 8] FIG. 2 illustrates a protocol stack for the F1-C protocol. [Figure 9] FIG. 4 is a diagram showing 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. 11 is a diagram for explaining an upstream relay operation according to the second embodiment. [Figure 12] FIG. 11 is a diagram illustrating an upstream relay operation according to the second embodiment. [Figure 13] FIG. 11 is a diagram for explaining a downstream relay operation according to the second embodiment. [Figure 14] FIG. 11 is a diagram illustrating a downstream relay operation according to the second embodiment. [Figure 15] FIG. 11 is a diagram illustrating the operation of the first modified example of the second embodiment. [Figure 16] FIG. 13 is a diagram illustrating the operation of the second modification of the second embodiment. [Figure 17]FIG. 13 illustrates types of BH RLF notifications. [Figure 18] FIG. 1 illustrates an identified solution to avoid re-establishment on descendant nodes. [Figure 19] FIG. 1 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 UL status delivery deployment options. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0010] (Configuration of 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 wireless access method in the cellular communication system 1 is NR (New Radio), which is a 5G wireless access method. However, LTE (Long Term Evolution) may be applied at least partially to the cellular communication system 1.

[0012] As shown in Fig. 1, the cellular communication system 1 includes a 5G core network (5GC) 10, a user equipment (UE: User Equipment) 100, a base station (called 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 is 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 on 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.

[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 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 mutually connected to the 5GC 10 via an interface called an NG interface. In FIG. 1, two gNBs 200-1 and 200-2 connected to the 5GC 10 are illustrated.

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

[0018] Each gNB 200 may be divided into a central unit (CU) and a distributed unit (DU). The CU and the DU are connected to each other via an interface called an F1 interface. The F1 protocol is a communication protocol between the CU and the 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 a terminal node of the NR backhaul on the network side, and is a donor base station with additional functions to support IAB. The backhaul can be multi-hopped 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 is a mobile phone terminal, a tablet terminal, a laptop PC, a sensor or a device provided in a sensor, a vehicle or a device provided in a vehicle. The UE 100 wirelessly connects 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 cells, similar to the gNB 200. The IAB-DU terminates the NR Uu radio interface to the UE 100 and the lower IAB nodes. The IAB-DU supports the F1 protocol to the CU of the donor gNB 200-1. In FIG. 2, an example is shown in which the child nodes of the IAB node 300 are the IAB nodes 300C1 to 300C3, but the child nodes of the IAB node 300 may include the UE 100. The direction toward the child nodes is called downstream.

[0026] (Base station configuration) Next, a 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 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 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 receptions 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 transmissions 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 the 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 processing. The processor performs processing of each layer, which will be described later.

[0030] (Configuration of relay node) Next, a 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 a plurality of 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 receptions 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 signal to the control unit 320. The transmitting unit 312 performs various transmissions 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 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 the 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 processing. The processor performs processing of each layer, which will be described later.

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

[0035] The wireless communication unit 110 performs wireless communication in an access link, that is, wireless communication with the gNB 200 and wireless communication with the IAB node 300. The wireless communication unit 110 may also perform wireless communication in a side link, that is, wireless communication with another UE 100. The wireless 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 wireless 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 wireless 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 the 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 processing. The processor performs processing of each layer, which will be described later.

[0037] (Protocol stack configuration) Next, a configuration of a protocol stack according to an embodiment will be described below. Fig. 6 is a diagram showing a protocol stack related to an RRC connection and a NAS connection of an 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 the IAB node 300-2 and the PHY layer of the IAB-DU of the IAB node 300-1 via a physical channel.

[0040] The MAC layer performs data priority control, retransmission processing using Hybrid Automatic Repeat Request (HARQ), random access procedures, etc. Data and control information are transmitted 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 via a transport channel. The MAC layer of the IAB-DU includes a scheduler. The scheduler determines the transport format (transport block size, modulation and coding scheme (MCS)) and the assigned resource blocks for uplink and downlink.

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

[0042] The PDCP layer performs header compression / decompression and encryption / decryption. Data and control information are transmitted between the PDCP layer of the IAB-MT of the 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 the 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 located 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 split into a CU and a DU.

[0046] As shown in Fig. 7, 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 has a BAP (Backhaul Adaptation Protocol) layer as a layer above the RLC layer. The BAP layer is a layer that performs routing processing and bearer mapping / demapping processing. In the backhaul, the IP (Internet Protocol) layer is transmitted through the BAP layer, enabling routing in multiple hops.

[0047] In each backhaul link, the PDUs (Protocol Data Units) of the BAP layer are transmitted by a backhaul RLC channel (BH NR RLC channel). By configuring multiple backhaul RLC channels in each BH link, traffic prioritization and QoS (Quality of Service) control are possible. The association between the BAP PDUs and the 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 FIG. 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 Tunnelling Protocol for User Plane) layer and UDP (User Datagram Protocol) layer shown in FIG. 7.

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

[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 the IAB node 300 performs connection switching between donor gNBs 200, the operation of the UE 100 under the IAB node 300 becomes an issue. Specifically, when the 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 preferable to make changes to the operation of the UE 100.

[0052] The first embodiment is an example in which a connection switch (e.g., handover) of the IAB node 300 between donor gNBs 200 is realized only by changing the operation on the network side (IAB node side) transparently to the UE 100 side. 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 is continued via the target donor gNB 200T. Third, the source donor gNB 200S transmits a handover command to the UE 100 via the target donor gNB 200T, instructing a handover to the target donor gNB 200T, using the RRC connection.

[0054] That is, the RRC connection (and the PDCP connection) between the UE 100 and the source donor gNB 200 continues to be established via the target donor gNB 200, and the source donor gNB 200S uses this connection to transmit a handover command to the UE 100. This makes it possible to realize handover of the IAB node 300 between the donor gNBs 200 without making any operational changes to the UE 100.

[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 transfer process (i.e., data forwarding) of the data 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 FIG. 9, in step S101, the UE 100 is in a state in which an RRC connection with the source donor gNB 200S 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 has the cell of the IAB node 300 (IAB-DU) as its own 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 description will be given on the assumption 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 the PDCP layer of the UE 100 remain in a connected state with the source donor gNB 200. For this reason, the UE 100 cannot perform communication with the target donor gNB 200T in either the C-plane or the 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 an interface between base stations or may be set up via a 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 in 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 the source donor gNB200S continues via the tunnel between the source donor gNB200S and the target donor gNB200T and the target donor gNB200T.

[0072] In step S113, the source donor gNB200S transmits 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 gNB 200T transmits an RRC message (RRC Reconfiguration) including the handover command received in step S113 to the UE 100. Specifically, the target donor gNB 200T 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 a protocol stack when a handover command is transmitted. As shown in Fig. 10, a handover command (RRC Reconfiguration) is transmitted from the RRC layer of the source donor gNB200S to the RRC layer of the UE100 via the target donor gNB200T and the IAB node 300. Communication between the source donor gNB200S and the target donor gNB200T is performed by inter-base station communication. Fig. 9 shows an example of GTP, but is not limited to this. 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 the IAB node 300. The target donor gNB 200T receives the RRC message. Here, since UE 100 continues to be under the control of the IAB node 300, RACH-less handover in which the transmission of a random access preamble and the reception of a random access response are omitted may be performed. In this case, the RACH-less handover may be instructed to UE 100 in the handover command.

[0076] In step S116, the UE 100 establishes an RRC connection with the target donor gNB 200T as a result of the handover. 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 transfers the user data received in step S120 to the IAB node 300. The IAB node 300 receives the user data.

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

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

[0084] The second embodiment is an embodiment related to load balancing in the IAB topology. In the IAB node 300, the path in the IAB topology is basically determined semi-fixedly by the 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, it is considered that more dynamic load balancing is possible.

[0085] In the second embodiment, the IAB node 300 performs efficient data relay in consideration of 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 on 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 or not there are multiple next hop nodes of the target IAB node 300 included in the multiple relay destination nodes. If there are multiple next hop nodes of 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 a target IAB node 300, multiple paths can be used efficiently.

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

[0088] As described above, the IAB node 300 selects a data destination from among multiple destination nodes according to the routing setting (routing table) set by the donor gNB 200. When a predetermined condition is satisfied, the IAB node 300 may execute local routing to select a data destination without following the routing setting. Here, the predetermined condition may include a condition that a failure occurrence notification or a local routing request is received from any of the multiple 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 or a request occurs at the destination node, the IAB node 300 performs local routing itself, thereby enabling data to be relayed to an 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 for explaining an upstream relay operation according to the second embodiment. In the upstream relay operation, a source node of the IAB node 300 is a child node of the IAB node 300, and a destination node of the IAB node 300 is a parent node of the IAB node 300.

[0092] As shown in Fig. 11, an IAB topology including an IAB node 300, other IAB nodes 300a to 300g, and a donor gNB 200 is formed. 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, the IAB node 300a and / or the IAB node 300b, based on the routing setting set by the donor gNB 200 and information (BAP routing ID) included in the header of the uplink packet.

[0093] Each of the IAB nodes 300a to 300g transmits information indicating whether there are multiple next hop nodes of the own node to the child node as its own node's capacity information. In upstream relay operation, such capacity information is called "BH connection information." Specific examples of BH connection information will be described later. By transmitting such BH connection information from each IAB node 300 to the child node, the child node can grasp the potential capacity of its parent node, thereby 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 double connection is established by 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, 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 performing local routing, the IAB node 300 sets the transmission ratio for the IAB node 300a to "2 / 3" and sets 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 regarded 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 any of the following: A parameter (such as a threshold) that defines 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 recovery from the RLF of the BH of the parent node has failed.

[0100] -Condition that the uplink throughput to a parent node falls below a certain level: For example, this condition may be satisfied when a scheduling request (SR) transmitted by the 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 continues for a certain period of time or more). This condition may be satisfied when the uplink throughput of a parent node falls below a certain value (and this state continues for a certain period of time or more).

[0101] · A local routing request is received from the parent node: The local routing request may be transmitted from the parent node by a message of the BAP layer. 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 described later.

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

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

[0104] If the condition for starting local routing is not satisfied (step S202: No), the IAB node 300 continues routing based on the routing settings 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. The IAB node 300 may be allowed to execute local routing only when the execution of local routing is permitted by the donor gNB 200. 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 executed may be set for each bearer (RLC channel), or may be set collectively for all bearers. Along with such settings, it may be set which of the above conditions is to be applied and a threshold value to be used for determining 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. 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) transmitted by the donor gNB 200.

[0110] 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 a dual BH and the other parent node is a single BH, the IAB node 300 sets the transmission ratio for the one parent node to "2 / 3" and sets the transmission ratio for the other parent node to "1 / 3". Here, for example, when the transmission ratio is set to 0:1, it is considered that the destination has been switched (locally switched). The IAB node 300 may adjust or determine the transmission ratio based on information included in the BH connection information (for example, information on the capacity of each BH link). The IAB node 300 may adjust or determine the transmission ratio based on the past transmission throughput history for each parent node (or the uplink grant history to the child node (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 is satisfied. The termination condition may be the opposite of the above-mentioned start condition. For example, it is at least one of the following conditions: a BH recovery success notification is received from a parent node; throughput to a parent is recovered; a local routing stop request is received; and the buffer status of a child node (and grandchild node) is improved. The termination condition may include a condition that local routing permission is revoked (set to not permitted) from the donor gNB 200.

[0113] If the local routing termination condition is not satisfied (step S206: No), the IAB node 300 continues the local routing (step S205). On the other hand, if the local routing termination condition 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 the IAB node 300 is the parent node of the IAB node 300, and the destination node of the IAB node 300 is the child node of the IAB node 300. In downstream relay operation, the parent node and the child node in the above-mentioned upstream relay operation may be exchanged. Note that Fig. 13 shows an example in which each IAB node 300 is a dual BH, and four paths exist 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 the IAB-DU. Here, differences from the 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 start condition for local routing is satisfied. For example, the start condition is any one of the following. A parameter (threshold value, etc.) that determines the start condition may be set in the IAB node 300 by the donor gNB 200. The IAB node 300 may be able to execute local routing only when 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 value to be used for determining the condition may be set.

[0119] The condition occurs when 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 bad (and that 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 (eg, MCS) for the 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 judgment.

[0122] If the local routing start condition is not satisfied (step S302: No), the IAB node 300 continues routing based on the routing settings 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 an operation 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 the selected path. In addition, the IAB node 300 may change the header of the downlink 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.

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

[0128] If the local routing termination condition is not satisfied (step S306: No), the IAB node 300 continues the local routing (step S305). On the other hand, if the local routing termination condition 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 above-described second embodiment, there is a risk that the donor gNB 200 cannot grasp the contents of the local routing executed by the IAB node 300 (when it was executed and how many times it was executed). When local routing is executed, there is a possibility that there is a problem with the routing setting by the donor gNB 200, or a failure has occurred in the IAB topology. For this reason, it is preferable that the donor gNB 200 can grasp the contents of the local routing. This enables the donor gNB 200 to optimize the routing setting, for example.

[0131] In this modification, 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 setting set by the donor gNB 200. When a predetermined condition is satisfied, the IAB node 300 executes local routing that selects a data destination without following the routing setting (see the second embodiment). The IAB node 300 transmits history information related to this local routing (i.e., information indicating the contents 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 stores information (local routing information) related to the local routing executed in step S401. The IAB node 300 stores the local routing information every time it executes local routing.

[0135] The local routing information may include at least one of a timestamp indicating the time when the local routing was performed, location information (latitude, longitude, altitude) indicating the time when the local routing was performed, and information indicating the radio situation at the time when the local routing was performed. The local routing information may include routing IDs (path ID and destination) before and after the change due to the 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 IAB topology being connected. The local routing information may include information indicating the reason (or condition) for performing the local routing. The local routing information may include information indicating the period (start time, end time) during which the local routing was performed and / or the number of times the local routing was performed. 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 by, for example, 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 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 upon a request from the IAB node 300.

[0138] In this modification, 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 setting set by the donor gNB 200. The IAB node 300 transmits a routing change request to the donor gNB 200 to change the routing setting.

[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 desire for a 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 the 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 judgment 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 permits (sets) 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 (path) in the routing change request. The IAB node 300 may include the BSR value of its child node or its own BSR value with the BSR value added in the routing change request. Such transmission of the BSR value may be performed periodically by each IAB node 300 in the IAB topology to the donor gNB 200.

[0144] In the case of downstream routing change, the IAB node 300 may include its own available buffer size value and / or its child node's available buffer size value (Flow control feedback BAP Control PDU value) in the routing change request. Such transmission of available buffer size values ​​may be made periodically 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] In addition, 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 of this timer may be set for the IAB node 300 by the donor gNB 200.

[0147] (Other embodiments) The above-mentioned embodiment 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 together with the second embodiment, or can be implemented separately from the second embodiment.

[0148] In the above-mentioned embodiment and modified example, 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-mentioned embodiment and modified example may be applied to a relay node (Layer 3 relay node), a side link relay (a relay node using a side link used for direct communication between user devices), etc.

[0149] In the above 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 example. The program may be recorded in a computer-readable medium. The computer-readable medium can be used to install the program in a computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM. A chipset may be provided that is configured by 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] (Additional Note) (introduction) A revised work item on NR eIAB (Enhancements to Integrated Access AND Backhaul) was approved. Some of the objectives are to:

[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, multi-hop delays, and congestion mitigation across topologies.

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

[0155] (Discussion) (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 due to moving objects such as vehicles, seasonal changes (foliage), infrastructure changes (new buildings), etc. Such vulnerabilities apply even 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] Observation 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 normative work of Rel-16, 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, i.e., BH RLF indication (aka "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 "Extensions for Reducing Service Disruption Due to IAB Node Mobility and BH RLF Recovery" and "Enhancements for Topology Redundancy" clearly intend that the BH link is not stable, and mobility and BH RLF occur frequently in Rel-17 deployment scenarios. Therefore, according to the Rel-17 discussion, RAN2 should first have a common understanding of the assumptions for the BH link.

[0160] Proposal 1: RAN2 should assume that the quality of the backhaul link changes dynamically. Therefore, 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 the BH RLF indication in Rel-16, which causes the child IAB-MT to consider RLF on the BH link and initiate the RLF recovery procedure.

[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 thought that other types of indications would be useful, so it was discussed further in the email. Eight out of 13 companies preferred to introduce Type 2 "attempting recovery", while the other two thought it would be discussed in Rel-17. Therefore, it can be seen that the majority of companies think that Type 2 indications are ready to be introduced in Rel-17. How to send Type 2 indications, 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 is sent via BAP Control PDU, SIB1, or both is for further consideration.

[0166] In addition, 9 out of 13 companies agreed to discuss Type 3 "BH link recovery" in Rel-17 as well. In detail, it can be considered whether such an explicit indication is really necessary. For example, if Type 2 indication is sent via SIB1, the indication will not be broadcasted once the BH link is not under RLF (i.e., "recovered"). Thus, downstream IAB nodes and UEs will know whether the BH link has recovered or not 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 know the BH link recovery. However, in this case, UEs cannot know the fact because they do not have a BAP layer. 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", will be introduced.

[0168] If Proposal 2 and / or Proposal 3 can be agreed upon, the behavior of the IAB-MT upon receiving the indication under BH link recovery should be considered. It was proposed that the IAB-MT should reduce / stop SR upon receiving Type 2 and resume operation upon receiving Type 3 (i.e., no BH RLF in the parent IAB node). This is one of the desired IAB-MT behaviors when the parent node tries to recover 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 receiving an IAB-MT Type 2 indication and resume scheduling requests when the parent node no longer has BH RLF.

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

[0171] Regarding the IAB-DU sending the indication, if the BH link of the IAB node is under RLF, it is assumed to send a type 2 BH RLF indication. In the case of a single-connected BH, this is straightforward, since the indication is sent when RLF occurs on this BH link. However, in the case of a dual-connected BH, it becomes a bit more complicated. For example, when the IAB node detects RLF on the MCG, it initiates the MCG fault information procedure, but the SCG continues to function as the BH link, so it may not be necessary to send a type 2 indication at this point. If the MCG fault information procedure fails, such as due to T316 expiry, the IAB-MT will initiate RRC re-establishment, so a type 2 indication is sent at this point. Thus, a type 2 indication is sent when RRC re-establishment is initiated, not when the MCG / SCG fault information is triggered. In any case, since this is targeted at the behavior of the IAB-DU, it should be carefully considered whether / how to capture it in the specification. That is, it should be considered whether a note should be added or nothing should be captured in stage 2 and stage 3.

[0172] Proposal 6: RAN2 should agree that it may send a Type 2 BH RLF indication when the IAB-DU initiates an RRC re-establishment, but not when it initiates any 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. In this cell selection procedure, potential issues were pointed out in Rel-16, such as the possibility that the IAB-MT may select a descendant node. Therefore, it was 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". This meant that RAN2 agreed to "Option 4: Nothing is needed as RRC re-establishment will fail if there is no BH connection". Option 4 was acceptable in Rel-16 deployment scenarios even if more time is needed for BH RLF recovery since it has 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 view of 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 IAB-MT operation during BH RLF recovery, as stated by the rapporteur in the above email discussion, "this topic may be discussed again in Rel-17."

[0179] Proposal 8: RAN2 should agree that optimization of cell (re)selection 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, from the perspective of IAB nodes near the IAB donor, i.e., the top of the DAG topology, it is more reasonable to provide a whitelist 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 / neighboring IAB topologies, potentially increasing the size of the list, 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] It is therefore desirable for an IAB donor (or parent IAB node) to be able to choose between 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. BH RLF indication of type 2. Option 3 assumes providing topology-wide information not in the existing configuration. Option 5 assumes configuration by OAM, but as the rapporteur pointed out, this is doubtful.

[0188] Considering again the assumption of Rel-17 (i.e., proposal 1), i.e., parent IAB node or IAB donor should provide list to child IAB node when topology change occurs, the method of providing whitelist / blacklist should be dynamic. Therefore, option 5, i.e., OAM, should be excluded. Which method, i.e., option 1, 2, or 3, should be the baseline for enhancement needs 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 Delivery Extension) During the Rel-15 research phase, the issue of multi-hop RLC ARQ was discussed and captured in section 8.2.3 of the TR. In Rel-16, the protocol stack was defined for IAB with a non-separate RLC layer, i.e., end-to-end ARQ was eliminated 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, "Changes to PDCP protocols / procedures", was -15 Not adopted due to impact on UE.

[0193] The second solution, "re-routing of buffered PDCP PDUs at intermediate IAB nodes," was supported as an implementation choice at the BAP layer. Additionally, the BAP layer may "e.g., buffer data in the transmit portion of the BAP entity until the RLC-AM entity receives an acknowledgment, which is implementation dependent." 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 promised 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 in the UE would be initiated when necessary. However, it was not specified in Rel-16, since fixed IAB nodes were assumed, and UL packet drops due to topology changes were considered rare.

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

[0196] Proposal 11: RAN2 should agree to implement the solution specified in TR38.874, i.e. a mechanism to ensure lossless delivery under conditions of potentially frequent topology changes 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 a "confirmation" from the IAB donor needs to be specified in the BAP or RRC for end-to-end signaling forwarding over multi-hop L2 networks. Therefore, a relatively high standard effort would be required to specify this option.

[0199] Regarding C-2 above, if it works well for IAB topologies, it can actually be implemented for Rel-16 IAB nodes, since it ultimately depends on the IAB-DU implementation when sending RLC ACK to the UE (or downstream IAB nodes), even though it should be assumed that OAM configures all IAB nodes with this option. Furthermore, it is simpler than C-1, since it assumes hop-by-hop feedback and does not assume additional Control PDUs. Therefore, C-2 should be the Rel-17 extension baseline 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 expect dynamic topology changes that cause UL packet loss, so Rel-17 extensions will 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 does not guarantee lossless delivery during IAB node handover. Furthermore, minor changes such as RLC and / or BAP are expected in Stage 3, but may not specify the details since they are considered as internal operation of IAB nodes.

[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 parent IAB node (i.e. C-2). Whether / how to specify in stage 3 needs further study.

Claims

1. A communication control method, comprising: An IAB node having a user device thereunder performs a connection switch from a first donor base station to a second donor base station; continuing a control connection between the user equipment and the first donor base station via the second donor base station even after the connection switching is performed; the first donor base station transmitting control information destined for the user equipment to the user equipment via the second donor base station. Communications control method.

2. a first donor base station, A control unit that switches a connection between an IAB node having a user device under its control and the first donor base station to a second donor base station, and a transmission unit; The control unit continues a 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 transmission unit transmits control information 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, a control connection between the user equipment and the first donor base station is continued via the second donor base station; Transmitting control information addressed to the user equipment to the user equipment via the second donor base station. system.

Images