Communication Control Method

Abstract

To provide a communication control method and a relay node that prevent a problem in which even IAB (Integrated Access and Backhaul) nodes that do not need to perform RRC (Radio Resource Control) re-establishment or the like perform RRC re-establishment or the like, by all IAB nodes in topology, forwarding Type 1 / 2 Indication.SOLUTION: In a cellular communication system, an IAB node 300-T detects occurrence of a radio link failure in a backhaul link #1 between the IAB node 300-T and its parent node 500 and sends a failure occurrence notification (Type 1, Type 2, or Type 1 / 2 Indication) to an IAB node 300-C. The IAB node 300-C determines whether or not to send the failure occurrence notification to a subordinate node of the IAB node 300-C based on a value set from the IAB node 300-T.SELECTED DRAWING: Figure 9

Description

[Technical field]

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

[0002] In the cellular communication system standardization project 3GPP (Third Generation Partnership Project) (registered trademark, hereinafter the same), the introduction of a new relay node called an IAB (Integrated Access and Backhaul) node is being considered (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 for use in a cellular communication system, the communication control method including: a relay node that detects occurrence of a fault in a backhaul link between the relay node and a parent node of the relay node transmitting a notification instructing execution of a conditional handover; and a communication device receiving the notification.

[0004] A communication control method according to a second aspect is a communication control method used in a cellular communication system. The communication control method includes a first relay node that detects occurrence of a failure in a backhaul link between a first relay node and a parent node of the first relay node, transmitting a failure occurrence notification indicating the occurrence of the failure to a second relay node, the failure occurrence notification including forwarding possibility information indicating whether or not to forward the failure occurrence notification. The communication control method also includes the second relay node forwarding the failure occurrence notification received from the first relay node or not forwarding the failure occurrence notification received from the second relay node according to the forwarding possibility information.

[0005] A communication control method according to a third aspect is a communication control method used in a cellular communication system. The communication control method includes a first relay node transmitting a first request for requesting a change of a route priority to a second relay node when transmitting a failure occurrence notification indicating that a failure has occurred in a backhaul link or a recovery failure notification indicating that recovery from the failure in the backhaul link has failed. The communication control method also includes the second relay node changing the priority of a first route from the second relay node via a third relay node to a fourth relay node and / or the priority of a second route from the second relay node to the fourth relay node via a fifth relay node in response to receiving the first request. The communication control method also includes the second relay node transmitting a packet according to the changed priority of the first route and / or the changed priority of the second route.

[0006] A communication control method according to a fourth aspect is a communication control method for use in a cellular communication system, the communication control method including: a second relay node receiving, from a first relay node, a failure occurrence notification indicating that a failure has occurred in a backhaul link; and the second relay node deactivating a main path setting and activating an alternative path setting for the main path in response to receiving the failure occurrence notification. [Brief description of the drawings]

[0007] [Figure 1] FIG. 1 is a diagram showing an example of the 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] FIG. 3 is a diagram showing an example configuration of a gNB (base station) according to one embodiment. [Figure 4] FIG. 4 is a diagram illustrating a configuration example of an IAB node (relay node) according to an embodiment. [Diagram 5]FIG. 5 is a diagram illustrating a configuration example of a UE (user equipment) according to an embodiment. [Figure 6] FIG. 6 is a diagram showing an example of a protocol stack related to an RRC connection and a NAS connection of an IAB-MT. [Figure 7] FIG. 7 is a diagram showing an example of a protocol stack related to the F1-U protocol. [Figure 8] FIG. 8 is a diagram showing an example of a protocol stack for the F1-C protocol. [Figure 9] FIG. 9 is a diagram showing an example of the configuration of the cellular communication system according to the first embodiment. [Figure 10] FIG. 10 is a diagram illustrating an operation example of the first embodiment. [Figure 11] FIG. 11 is a diagram showing an example of the configuration of a cellular communication system according to the third embodiment. [Figure 12] FIG. 12 is a diagram illustrating an operation example of the third embodiment. [Figure 13] FIG. 13 is a diagram showing an example of the configuration of a cellular communication system according to the fourth embodiment. [Figure 14] FIG. 14 is a diagram illustrating an operation example of the fourth embodiment. [Figure 15] FIG. 15 is a diagram illustrating an operation example of the fifth embodiment. [Figure 16] FIG. 16 is a diagram illustrating types of BH RLF notifications. [Figure 17] FIG. 17 is a diagram illustrating an extended BH RLF indication transmission option. [Figure 18] FIG. 18 illustrates an identified solution to avoid re-establishment on descendant nodes. [Figure 19] FIG. 19 illustrates a comparison of mechanisms for lossless delivery of UL data in the case of hop-by-hop RLCARQ. [Figure 20] FIG. 20 illustrates the "C) Introduction of UL Status Delivery" option. [Figure 21]FIG. 21 illustrates RAN2 signaling issues that may arise with IAB node movement between donors. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] A cellular communication system according to an embodiment will 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.

[0009] (Configuration of Cellular Communication System) A configuration example of a cellular communication system according to an embodiment will be described. The cellular communication system 1 according to an embodiment is a 3GPP 5G system. Specifically, the radio access method in the cellular communication system 1 is NR (New Radio), which is a 5G radio access method. However, LTE (Long Term Evolution) may be applied at least partially to the cellular communication system 1. Furthermore, the cellular communication system 1 may also be applied to future cellular communication systems such as 6G.

[0010] FIG. 1 is a diagram showing an example of the configuration of a cellular communication system 1 according to an embodiment.

[0011] As shown in Fig. 1, the cellular communication system 1 includes a 5G core network (5GC) 10, a user equipment (UE: User Equipment) 100, base station devices (hereinafter, sometimes referred to as "base stations") 200-1 and 200-2, and IAB nodes 300-1 and 300-2. The base station 200 may be referred to as a gNB.

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

[0013] In the following, the base stations 200-1 and 200-2 may be referred to as gNB 200 (or base station 200), and the IAB nodes 300-1 and 300-2 may be referred to as IAB node 300.

[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. In the following, a cell and a base station may be used without distinction.

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

[0018] 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).

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

[0020] 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 computer, a sensor or a device provided in a sensor, a vehicle or a device provided in a vehicle, or an aircraft or a device provided in an aircraft. 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.

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

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

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

[0024] Adjacent nodes (i.e., lower nodes) on the NR Uu 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-300C3, but the child nodes of the IAB node 300 may include the UE 100. The direction toward the child nodes is called downstream.

[0025] (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 an example of the configuration of the gNB 200. As shown in Fig. 3, the gNB 200 has a wireless communication unit 210, a network communication unit 220, and a control unit 230.

[0026] 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 (down-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 (up-converts) a baseband signal (transmitted signal) output by the control unit 230 into a wireless signal and transmits the signal from the antenna.

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

[0028] 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. Furthermore, the control unit 230 may perform each processing in the gNB 200 in each of the embodiments shown below.

[0029] (Configuration of relay node) Next, the configuration of the IAB node 300, which is a relay node (or relay node device, hereinafter sometimes referred to as a "relay node") according to the embodiment, will be described. FIG. 4 is a diagram showing an example of the configuration of the IAB node 300. As shown in FIG. 4, the IAB node 300 has a wireless communication unit 310 and a control unit 320. The IAB node 300 may have multiple wireless communication units 310.

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

[0031] 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 (down-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 (up-converts) a baseband signal (transmitted signal) output by the control unit 320 into a wireless signal, and transmits the signal from the antenna.

[0032] 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 a program 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 a baseband signal. The CPU executes a program stored in the memory to perform various processing. The processor performs processing of each layer, which will be described later. The control unit 320 may also perform each processing in the IAB node 300 in each of the following embodiments.

[0033] (Configuration of user device) 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 includes a radio communication unit 110 and a control unit 120.

[0034] 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 (down-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 (up-converts) a baseband signal (transmitted signal) output by the control unit 120 into a wireless signal and transmits the signal from the antenna.

[0035] 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 a program 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 a baseband signal. The CPU executes a program stored in the memory to perform various processing. The processor performs processing of each layer, which will be described later. The control unit 130 may perform each processing in the UE 100 in each of the following embodiments.

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

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

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

[0039] The MAC layer performs data priority control, retransmission processing using hybrid ARQ (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.

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

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

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

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

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

[0045] 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 layer is transmitted through the BAP layer, enabling routing in multiple hops.

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

[0047] As shown in FIG. 8, the protocol stack of the F1-C protocol has an F1AP layer and an SCTP (Stream Control Transmission Protocol) layer instead of the GTP-U layer and UDP layer shown in FIG.

[0048] (First embodiment) First, a fault detection and recovery attempt in the first embodiment will be described.

[0049] (Failure detection and recovery attempts) FIG. 9 is a diagram showing an example of the configuration of a cellular communication system 1 according to the first embodiment.

[0050] The cellular communication system 1 shown in Fig. 9 includes a node 500, an IAB node 300-T, an IAB node 300-C, and a UE 100. The IAB node 300-C and the UE 100 may be communication devices.

[0051] Node 500 is a parent node of IAB node 300-T, and is a gNB 200 (or a donor node. Hereinafter, "gNB 200" may be referred to as a "donor node") or an IAB node 300 (parent IAB node). The IAB-MT of IAB node 300-T has established a backhaul link (BH link) #1 with node 500. The IAB-MT of IAB node 300-T is in an RRC connected state.

[0052] The IAB node 300-C is a child node (child IAB node) of the IAB node 300-T. The IAB-MT of the IAB node 300-C establishes a BH link #2 with the IAB node 300-T. The IAB-MT of the IAB node 300-C is in an RRC connected state. Alternatively, the IAB-MT of the IAB node 300-C may not establish a BH link #2 with the IAB node 300-T and may be in an RRC idle state.

[0053] The UE 100 has established an access link with the IAB node 300-T. The UE 100 is in an RRC connected state. Alternatively, the UE 100 may not have established an access link with the IAB node 300-T and may be in an RRC idle state.

[0054] In such a configuration, it is assumed that the IAB-MT of the IAB node 300-T detects a radio link failure (BH RLF (Radio Link Failure)) of the BH link #1. The IAB-MT of the IAB node 300-T detects the BH RLF, for example, as follows, and performs a recovery attempt to recover from the BH RLF.

[0055] First, if the IAB-MT of the IAB node 300-T detects an out-of-sync state N310 times in a row, it detects a radio problem and starts a timer T310. If the IAB-MT of the IAB node 300-T detects an in-sync state N311 times in a row after starting the timer T310, it stops the timer T310.

[0056] Secondly, when the timer T310 expires without being stopped, the IAB-MT of the IAB node 300-T detects the RLF and starts the timer T311 (i.e., starts the RRC re-establishment process) and performs a cell selection process to recover the BH link. The IAB-MT of the IAB node 300-T selects an appropriate cell by the cell selection process, and when the BH link is recovered for the selected cell, stops the timer T311. An appropriate cell is a cell that satisfies at least a minimum wireless quality standard.

[0057] Third, the IAB-MT of the IAB node 300-T transitions to the RRC idle state when the timer T311 expires without successful recovery of the BH link. In the following, failure to recover from a BH RLF after detecting the BH RLF (i.e., expiration of the timer T311) may be referred to as a BH link recovery failure.

[0058] Here, when the IAB-DU of the IAB node 300-T detects a BH RLF, it can notify a Type 1 Indication (RLF detected) to the IAB-MT of the IAB node 300-C and the UE 100. The Type 1 Indication is an example of a failure occurrence notification indicating that a BH RLF has been detected.

[0059] Furthermore, when the IAB-DU of the IAB node 300-T detects a recovery operation from a BH RLF, it can notify a Type 2 Indication (Trying to recover) to the IAB-MT of the IAB node 300-C and the UE 100. The Type 2 Indication is an example of a failure occurrence notification indicating that recovery from a BH RLF is being attempted.

[0060] Furthermore, when the IAB-DU of the IAB node 300-T does not distinguish between a Type 1 Indication and a Type 2 Indication, it can transmit a Type 1 / 2 Indication to the IAB-MT of the IAB node 300-C and the UE 100. The Type 1 / 2 Indication is also an example of a failure occurrence notification.

[0061] Furthermore, there are two types of notifications in the IAB node 300-T: Type 3 Indication (RLF recovered) and Type 4 Indication (Recovery failure). The Type 3 Indication is a recovery notification indicating that the IAB node 300-T has recovered from a BH RLF. The Type 4 Indication is an example of a recovery failure notification indicating that the IAB node 300-T has failed to recover from a BH RLF.

[0062] Each Indication may be transmitted in a BAP Control PDU or a MAC CE on the BH link, and may be transmitted in an SIB1 on the access link.

[0063] On the other hand, even if the IAB-MT of the IAB node 300-T detects a BH RLF of the BH link #1, the radio conditions of the BH link #2 and the radio conditions of the access link may be good, and therefore there is a concern that the IAB node 300-C and the UE 100 may remain in the cell of the IAB node 300-T that detected the BH RLF.

[0064] Therefore, in the first embodiment, the IAB node 300-T transmits a notification indicating an instruction to execute a conditional handover to at least one of the IAB node 300-C and the UE 100.

[0065] Specifically, first, a relay node that detects occurrence of a failure in a backhaul link between a relay node and a parent node of the relay node transmits a notification instructing execution of a conditional handover. Second, a communication device receives the notification. The communication device is, for example, the IAB node 300-C and the UE 100. As a result, for example, when the IAB node 300-T detects occurrence of a failure in the backhaul link, the IAB node 300-C or the UE 100 can execute a conditional handover to switch the connection to another IAB node.

[0066] Here, a conditional handover will be described.

[0067] (Conditional Handover) In the cellular communication system 1 shown in FIG. 9, it is assumed that the IAB-MT of the IAB node 300-C is in an RRC connected state, and a conditional handover is configured in the IAB-MT of the IAB node 300-C. The conditional handover is a handover that is executed when one or more handover execution conditions (or trigger conditions) are satisfied. The conditional handover configuration includes a candidate cell for the handover and a trigger condition for the handover. The conditional handover configuration may include a plurality of combinations of the candidate cell and the trigger condition. The conditional handover configuration further includes an RRC configuration corresponding to the candidate cell.

[0068] In a typical handover, the UE 100 reports the measurement values ​​of the radio conditions of the serving cell and / or the neighboring cell to the gNB 200, and the gNB 200 decides to perform a handover to the neighboring cell based on the report and transmits a handover command to the UE 100. For this reason, in a case where the radio conditions of the serving cell suddenly deteriorate, the typical handover may result in a communication interruption before the handover is executed. In contrast, the conditional handover can autonomously execute a handover to a candidate cell corresponding to a preset trigger condition when the trigger condition is satisfied. For this reason, problems such as communication interruption in a typical handover can be solved.

[0069] The trigger condition is, for example, at least one of an event called event A3 and an event called event A5. Event A3 is an event in which the radio condition of the neighboring cell is better than the radio condition of the serving cell by a predetermined amount (predetermined offset) or more. Event A5 is an event in which the radio condition of the serving cell is worse than a first threshold and the radio condition of the neighboring cell is better than a second threshold.

[0070] (Example of operation) Next, an operation example according to the first embodiment will be described.

[0071] Fig. 10 is a diagram showing an operation example according to the first embodiment. The operation example shown in Fig. 10 shows an operation example in the cellular communication system 1 in Fig. 9. Hereinafter, the IAB node 300-T shown in Fig. 9 may be referred to as the upper node 300-T, and the IAB node 300-C shown in Fig. 9 may be referred to as the lower node 300-C.

[0072] As shown in FIG. 10, in step S100, the cellular communication system 1 starts the process.

[0073] In step S101, the donor node performs a conditional handover (CHO) setting for the lower node 300-C and the UE 100. In the first embodiment, a trigger condition included in the setting of the conditional handover may include "receiving a notification indicating an instruction to execute a conditional handover".

[0074] The conditional handover may be configured by unicast signaling (eg, an RRC Reconfiguration message) from the CU of the donor node to the IAB-DU of the lower node 300-C and the UE 100.

[0075] In step S102, when the upper node 300-T detects the BH RLF, it transmits a notification indicating an instruction to execute a conditional handover to the lower node 300-C and the UE 100. The notification indicating an instruction to execute a conditional handover may be included in a message of the BAP layer, for example, a BAP Control PDU (Protocol Data Unit). Alternatively, the execution instruction may be included in a MAC CE (MAC Control Element). The IAB-MT of the lower node 300-C already connected to the IAB-DU of the upper node 300-T can receive a message of the BAP layer including the execution instruction from the IAB-DU of the upper node 300-T. On the other hand, the UE 100 does not have a BAP layer and cannot receive a message of the BAP layer. Therefore, the IAB-DU of the upper node 300-T transmits the execution instruction by including it in a system information block type 1 (SIB (System Information Block) 1). This allows not only the lower node 300-C but also the UE 100 to receive the execution instruction.

[0076] Incidentally, the notification in step S102 may be set by the donor node as to whether or not the notification is to be performed. This can be realized by the CU of the donor node making such a setting to the IAB-DU of the upper node 300-T by signaling. Alternatively, the upper node 300-T may perform step S102 only when the IAB node 300-C or the UE 100 exists under it. Such a setting may also be made by the CU of the donor node.

[0077] In step S103, when the lower node 300-C receives a notification indicating an instruction to execute a conditional handover, the lower node 300-C executes the conditional handover. Since one of the trigger conditions for a conditional handover, "receiving a notification indicating an instruction to execute a conditional handover", is satisfied, the lower node 300-C executes the handover.

[0078] Alternatively, when the lower node 300-C receives the notification, it may regard the received power from the serving cell (e.g., RSRP (Reference Signal Received Power)) as "zero" (=-∞ dBM) and trigger event A3 or event A5. Even if the trigger condition does not include "receiving a notification indicating an instruction to execute a conditional handover", the condition of event A3 or event A5 is satisfied by the process of regarding the received power from the serving cell as "zero" in response to receiving the notification, and the lower node 300-C can execute handover.

[0079] Alternatively, when the lower node 300-C receives the notification, it may apply a Time to Trigger (TTT) or wait for a certain period of time to execute the conditional handover. If the lower node 300-C receives a notification from the upper node 300-T during the period indicating cancellation of the instruction to execute the conditional handover, it cancels the trigger condition and does not execute the conditional handover. The TTT may be set by the CU of the donor node in step S101.

[0080] Then, in step 104, the cellular communication system 1 ends the series of processes.

[0081] Second embodiment In the first embodiment, an example has been described in which the lower node 300-C performs a handover upon receiving an instruction to execute a conditional handover. In the second embodiment, other examples of the trigger condition are included in addition to the event A3 or the event A5.

[0082] Such a trigger condition may be "reception of Type 1 Indication." For example, when the lower node 300-C or the UE 100 receives a Type 1 Indication from the upper node 300-T, the trigger condition for the conditional handover is satisfied, and the lower node 300-C or the UE 100 performs a handover. When the upper node 300-T detects a failure (BH RLF), the lower node 300-C or the UE 100 performs a handover to another IAB node 300.

[0083] Also, the trigger condition may be "reception of Type 2 Indication". For example, when the lower node 300-C or the UE 100 receives a Type 2 Indication from the upper node 300-T, the trigger condition for the conditional handover is satisfied, and the lower node 300-C or the UE 100 performs a handover. When the upper node 300-T detects that a recovery operation for a failure (BH RLF) is in progress, the lower node 300-C or the UE 100 performs a handover to another IAB node 300. Furthermore, the trigger condition may be "reception of Type 4 Indication." For example, when the lower node 300-C or the UE 100 receives a Type 4 Indication from the upper node 300-T, the trigger condition for the conditional handover is satisfied, and the lower node 300-C or the UE 100 performs a handover. When the upper node 300-T detects a failure in recovery from a failure (BH RLF), the lower node 300-C or the UE 100 performs a handover to another IAB node 300.

[0084] Such a setting may be performed, for example, in step 101 (FIG. 10) of the first embodiment. A conditional handover is set by the CU of the donor node in the IAB-DU of the lower node 300-C or the UE 100, with the reception of a Type 1, Type 2, or Type 4 Indication as a trigger condition.

[0085] Third embodiment It is argued that when an IAB node 300 receives a Type 1 / 2 Indication, the IAB node 300 should quickly recover the entire topology of the IAB node 300 by transmitting the received Type 1 / 2 Indication to its subordinate nodes.

[0086] However, there is a case where the lower nodes start RRC reestablishment or the like all at once by receiving the Type 1 / 2 Indication. In this case, there is a concern that all the IAB nodes 300 in the topology may switch connections with other IAB nodes due to the RRC reestablishment or the like. In this case, the topology of the IAB nodes 300 may collapse.

[0087] That is, when all IAB nodes 300 in the topology transfer Type 1 / 2 Indication, even IAB nodes that do not need to perform RRC re-establishment may perform RRC re-establishment. In addition, even if all IAB nodes 300 perform RRC re-establishment, the signaling does not reach the donor node due to connection disturbance, and such processing is considered to be unsuccessful. Furthermore, IAB is originally performed by a centralized process by the donor node, and there is a risk that it may fall into a state that cannot be controlled from the center.

[0088] Therefore, in the third embodiment, the Type1 / 2 Indication is configured to include forwarding availability information, or the Type1 / 2 Indication is configured to include forwarding hop count information.

[0089] Specifically, first, a first relay node that detects the occurrence of a failure in a backhaul link between a first relay node and a parent node of the first relay node transmits a failure occurrence notification indicating the occurrence of the failure to a second relay node, the failure occurrence notification including forwarding possibility information indicating whether or not to forward the failure occurrence notification.

[0090] Secondly, the second relay node forwards the failure occurrence notification received from the first relay node, or does not forward the failure occurrence notification received from the first relay node, in accordance with the forwarding availability information.

[0091] This allows, for example, the IAB node 300 to properly transfer Type 1 / 2 Indication, enabling rapid recovery of the topology while minimizing the impact on the entire topology.

[0092] Fig. 11 is a diagram showing a configuration example of a cellular communication system 1 in the third embodiment. As shown in Fig. 11, the IAB-MT of the IAB node (or upper node) 300-T detects a failure or the like of the BH link #1 between the node 500 by the method described in the first embodiment. The IAB-DU of the IAB node 300-T transmits a Type 1 Indication, a Type 2 Indication, or a Type 1 / 2 Indication including forwarding availability information and the like to the IAB-MT of the IAB node 300-C, which is a lower node. The lower node 300-C transfers or does not transfer the received Indication to the lower IAB node 300 according to the forwarding availability information and the like included in these Indications.

[0093] FIG. 12 is a diagram showing an operation example in the third embodiment.

[0094] As shown in FIG. 12, in step S110, the cellular communication system 1 starts the process.

[0095] In step S111, when the IAB-MT of the IAB node 300-T detects a BH RLF in its own BH link #1, the IAB-DU of the IAB node 300-T transmits a Type 1 Indication to the IAB-MT of the lower node 300-C. Also, in step S111, when the IAB-MT of the IAB node 300-T detects that a BH RLF recovery operation has started in the BH link #1, the IAB-DU of the IAB node 300-T transmits a Type 2 Indication to the IAB-MT of the lower node 300-C. Note that, if the IAB-DU of the IAB node 300-T does not distinguish between Type 1 Indication and Type 2 Indication, it transmits a Type 1 / 2 Indication to the IAB-MT of the lower node 300-C.

[0096] Here, the Type 1 Indication, Type 2 Indication, and Type 1 / 2 Indication include the following information:

[0097] That is, these Indications include type information (category information) of the Indication. In the case of a Type 1 Indication, the type information indicating that it is Type 1 is included. Note that there are also Type 3 Indication and Type 4 Indication types. Therefore, the type information may also include the types of these Indications.

[0098] Moreover, these Indications include forwarding availability information indicating whether or not to forward the Indication. For example, "0" indicates that forwarding is not possible, and "1" indicates that forwarding is possible (forwarding is performed). Alternatively, the Indication may include information indicating whether the Indication was transmitted in response to the BH RLF of the IAB node 300 itself. As the information, for example, "0" may indicate the BH RLF of the IAB node 300 itself, and "1" may indicate the BH RLF of the parent node of the IAB node 300 itself. In the example of FIG. 11, when the IAB node 300-T detects a BH RLC in its own BH link #1 and transmits a Type 1 Indication to the lower node 300-C, the IAB node 300-T forwards the Type 1 Indication with "0" included as the information, and the lower node 300-C forwards the Type 1 Indication with "1" included as the information. Alternatively, the Indication may include information as to whether or not the Indication was transmitted in response to an Indication from the upper node 300-T. In this case, when the lower node 300-C receives a Type 1 Indication from the upper node 300-T, the lower node 300-C transfers the Type 1 Indication, which includes information indicating that the Indication was transmitted in response to an Indication from the upper node 300-T, to further lower nodes.

[0099] Alternatively, these Indications may include forwarding hop information. For example, in FIG. 11, consider a case where the IAB node 300-T is the highest IAB node in a given topology. In this case, when the IAB-MT of the IAB node 300-T detects a BH RLF, it transmits a Type 1 Indication including "0" as forwarding hop count information. Then, every time forwarding is performed, the forwarding hop count is incremented. Each IAB node 300 includes the incremented forwarding hop count in a Type 1 Indication and forwards it to a lower node. The upper limit value of the forwarding hop count may be set by the CU of the donor node to the IAB-DU (or IAB-MT) of each IAB node 300 by signaling. The IAB-DU of each IAB node 300 compares the forwarding hop count information included in each received Indication with the upper limit value, and forwards or does not forward the received Indication depending on the comparison result. For example, when the forwarding hop count information is equal to the upper limit value, the IAB-DU of the IAB node 300 does not forward the received Indication, and when the forwarding hop count is smaller than the upper limit value, the IAB-DU forwards the received Indication.

[0100] 12, in step S112, the lower node 300-C determines, in accordance with the information included in the received Indication, whether or not to forward the received Indication to the further lower IAB node 300. Then, the lower node 300-C forwards or does not forward the received Indication in accordance with the determination.

[0101] For example, when the Indication contains information on whether or not it can be forwarded, the following applies: That is, when the IAB-DU of the lower node 300-C contains "0" as the information on whether or not it can be forwarded, it does not forward the received Indication. On the other hand, when the IAB-DU of the lower node 300-C contains "1" as the information on whether or not it can be forwarded, it forwards the received Indication to a further lower node.

[0102] For example, when the Indication includes information on the number of forwarding hops, the following applies. That is, the IAB-DU of the lower node 300-C compares the forwarding hop count information included in each received Indication with the upper limit value, and does not forward the received Indication if the forwarding hop count information is equal to the upper limit value. On the other hand, the IAB-DU of the lower node 300-C forwards the received Indication if the forwarding hop count is smaller than the upper limit value. Alternatively, the IAB-DU of the lower node 300-C may determine not to forward the received Indication if the forwarding hop count exceeds the upper limit value. If the forwarding hop count is equal to or smaller than the upper limit value, the IAB-DU of the lower node 300-C may forward the received Indication.

[0103] Then, in step S113, the cellular communication system 1 ends the series of processes. In the above-described third embodiment, an example has been described in which, when an Indication such as a Type 1 Indication is transferred, the transfer possibility information is included in the Indication. For example, instead of each Indication such as a Type 1 Indication, a notification indicating an instruction to execute a conditional handover as described in the first embodiment may be the transfer target. In this case, the IAB node 300-T may transmit the notification including the transfer possibility information or including the number of transfer hops information.

[0104] (Fourth embodiment) In 3GPP, route priority is being discussed in relation to IAB. Route priority refers to a priority set for each route when multiple routes (hereinafter sometimes referred to as "routes") are set for the same destination in IAB, for example.

[0105] FIG. 13 is a diagram showing an example of the cellular communication system 1 in the fourth embodiment. The IAB node 300-T is an upper node, and the IAB node 300-C is a lower node. The lower node 300-C further includes a plurality of IAB nodes 300-R1, 300-R2, ..., 300-D. In this case, the lower node 300-C has a route #1 from the IAB node 300-R1 to the IAB node 300-D. The lower node 300-C has a route #2 from the IAB node 300-R2 to the IAB node 300-D. For example, the route #1 is set to a priority of "1" (= the highest priority), and the route #2 is set to a priority of "2" (= a priority lower than the priority "1", but since there are only two routes, it is the lowest priority). Regarding the priority, for example, the highest priority may be assigned to the route with the smallest number of hops. It should be noted that such priorities can be set by the CU of the donor node through signaling to the IAB-DU of each IAB node 300.

[0106] In the fourth embodiment, when the lower node 300-C receives, for example, a Type 1 / 2 Indication from the upper node 300-T, it changes the route priority set for each route, and then, when it receives a Type 3 Indication, it returns the route priority to the state before the change.

[0107] Specifically, first, when a first relay node transmits a failure occurrence notification indicating that a failure has occurred in a backhaul link or a recovery failure notification indicating that recovery from the failure in the backhaul link has failed, the first relay node transmits a first request to a second relay node requesting a change in route priority.

[0108] Second, in response to receiving the first request, the second relay node changes the priority of a first route from the second relay node via the third relay node to the fourth relay node and / or the priority of a second route from the second relay node via the fifth relay node to the fourth relay node.

[0109] Third, the second relay node transmits the packet according to the priority of the changed first route and / or the priority of the changed second route.

[0110] FIG. 14 is a diagram showing an operation example in the fourth embodiment.

[0111] As shown in FIG. 14, in step S120, the cellular communication system 1 starts the process.

[0112] In step S121, the upper node 300-T detects an RLF in the BH link #1. Alternatively, the upper node 300-T may detect a recovery failure from the RLF in the BH link #1. Alternatively, the upper node 300-T may receive a Type 1 / 2 Indication transmitted from a higher-level IAB node 300. Alternatively, the upper node 300-T may receive a Type 4 Indication transmitted from a higher-level IAB node 300.

[0113] In step S122, the upper node 300-T transmits a notification indicating a change request for route priority to the lower node 300-C. For example, in step S121, when the upper node 300-T detects an RLF of the BH link #1, it transmits a Type 1 / 2 Indication to the lower node 300-C. In this case, the Type 1 / 2 Indication itself may indicate a change request for route priority. Or, the Type 1 / 2 Indication may include an indicator of whether or not to change the route priority. Also, for example, when the upper node 300-T detects a recovery failure for the RLF of the BH link #1, it transmits a Type 4 Indication to the lower node 300-C. This Type 4 Indication itself may indicate a change request for route priority. Or, the Type 4 Indication may include an indicator of whether or not to change the route priority. Also, for example, the upper node 300-T may transmit to the lower node 300-C a Type 1 / 2 Indication or a Type 4 Indication received from the higher IAB node 300. This Type 1 / 2 Indication or Type 4 Indication may itself indicate a request to change the route priority, or each Indication may include an indicator as to whether or not to change the route priority.

[0114] The notification indicating the request to change the route priority may be transmitted using a BAP Control PDU, SIB1, or MAC CE.

[0115] In step S123, the lower node 300-C changes the route priority. Examples of changing the route priority are as follows.

[0116] 1) The lower node 300-C may consider the priority of the route (route #1) that currently has the highest priority as the lowest priority. In this case, in the example of FIG. 13, route #1 has the lowest priority and route #2 has the highest priority.

[0117] 2) The lower node 300-C may also consider the priority of the route currently having the second priority as the highest priority. In this case, in the example of FIG. 13, the route #2 having the second priority becomes the highest priority.

[0118] 3) Furthermore, the lower node 300-C may lower the priority of the currently highest priority route by one or several points. In this case, in the example of FIG. 13, if the priority is to be lowered by two points, the lower node 300-C changes the priority of route #1 from "1" to "3." As a result, the priority of route #1 after the change becomes lower than the priority "2" of route #2, and route #2 takes precedence over route #1.

[0119] 4) Furthermore, the lower node 300-C may increase the priority of one or more routes other than the currently highest priority route. In this case, in the example of FIG. 13, if the priority is increased by two, the lower node 300-C changes the priority of route #2 from "2" to "0." As a result, route #2 becomes the highest priority, higher than the priority of route #1.

[0120] These changes in route priority may be temporary. Also, the lower node 300-C may change the priority of all routes by combining, for example, the above 1) to 4), rather than just changing the priority of some routes.

[0121] Returning to Fig. 14, in step S124, the lower node 300-C performs routing processing on the packet according to the changed route priority. For example, in the example of Fig. 13, the IAB-MT of the lower node 300-C transmits the packet addressed to the IAB node 300-D to the IAB node 300-R2 on the route #2, not to the IAB node 300-R1 on the route #1.

[0122] Returning to FIG. 14, in step S125, when the upper node 300-T detects the recovery of the BH link #1, it transmits a notification to the lower node 300-C indicating that the route priority is to be restored to the state before the change. The notification may be the Type 3 Indication itself. That is, the Type 3 Indication itself may be a notification indicating that the route priority is to be restored to the original state before the change. Alternatively, the Type 3 Indication may include an indicator indicating that the route priority is to be restored to the state before the change.

[0123] In addition, the upper node 300-T may detect the recovery of the backhaul link by receiving not only the BH link #1 but also a Type 3 Indication transmitted from the IAB node 300, which is higher than the upper node 300-T. In this case, the upper node 300-T also transmits a notification indicating that the route priority is to be restored to the state before the change. The lower node 300-C may perform a process of restoring the route priority to the state before the change based on the normal recovery of its own BH link. For example, the process of restoring the route priority to the state before the change is performed when RRC Reestablishment to another parent node is successful.

[0124] In step S126, the lower node 300-C performs a process of returning the route priority to the original state before the change. For example, the IAB-DU (or IAB-MT) of the lower node 300-C may change the route priority set in step S123 to the priority set by the donor node. Alternatively, the IAB-DU of the lower node 300-C may request the CU of the donor node to return the route priority to the state before the change. In this case, the CU of the donor node may reset the route priority to the state before the change by retransmitting the routing configuration transmitted before the route priority change to the IAB-DU of the lower node 300-C.

[0125] In step S127, the lower node 300-C performs routing processing of the packet according to the route priority before the change of the route priority. For example, in the example of Fig. 13, the lower node 300-C changes the destination of the packet addressed to the IAB node 300-D from the IAB node 300-R2 on the route #2 to the IAB node 300-R1 on the route #1.

[0126] Returning to FIG. 14, in step S128, the cellular communication system 1 ends the series of processes.

[0127] In the fourth embodiment, an example of Type1 / 2 Indication has been described, but Type1 Indication or Type2 Indication may be used instead of Type1 / 2 Indication.

[0128] Fifth embodiment In the fifth embodiment, when the IAB node (or lower node) 300-C receives a Type 1 / 2 Indication from the upper node 300-T, it deactivates the setting of the main path and activates the setting of an alternative path for the main path.

[0129] Specifically, first, the second relay node receives a failure occurrence notification from the first relay node, which indicates that a failure has occurred in the backhaul link. Second, in response to receiving the failure occurrence notification, the second relay node deactivates the setting of the main path and activates the setting of an alternative path for the main path.

[0130] For example, in FIG. 13, the path of route #1 is the main path, and the path of route #2 is the alternative path. Such a setting is possible when the CU of the donor node provides the IAB-DU of the IAB node 300-C with a routing configuration. The routing configuration includes, for example, the BAP address of each IAB node 300 on the main path, and the BAP address of each IAB node 300 on the alternative path. The former can be information related to the setting of the main path, and the latter can be information related to the setting of the alternative path.

[0131] FIG. 15 is a diagram illustrating an operation example of the fifth embodiment.

[0132] As shown in FIG. 15, the IAB node 300-C starts the process in step S130.

[0133] In step S131, when the IAB node 300-C receives a Type 1 / 2 Indication from the upper node 300-T, it deactivates the main path setting and activates the alternative path setting. For example, the IAB-DU of the IAB node 300-C stops reading information related to the main path setting stored in the memory and starts reading information related to the alternative path setting stored in the memory.

[0134] In step S132, the IAB node 300-C routes the packet to the activated path. For example, the IAB-DU of the IAB node 300-C transmits the packet received from the upper node 300-T to the IAB-MT of the IAB node 300-R2 based on the information on the setting of the alternative path.

[0135] In step S133, when the IAB node 300-C receives a Type 3 Indication from the upper node 300-T, the IAB node 300-C activates the main path setting and deactivates the alternative path setting. For example, the IAB-DU of the IAB node 300-C starts reading information related to the main path setting stored in the memory and stops reading information related to the alternative path setting stored in the memory.

[0136] In step S134, the IAB node 300-C routes the packet to the activated path. For example, the IAB-DU of the IAB node 300-C transmits the packet received from the upper node 300-T to the IAB-MT of the IAB node 300-R1 based on information about the setting of the main path.

[0137] Then, in step S135, the IAB node 300-C ends the series of processes.

[0138] In the fifth embodiment, an example of Type1 / 2 Indication has been described, but Type1 Indication or Type2 Indication may be used instead of Type1 / 2 Indication.

[0139] (Other embodiments) A program may be provided that causes a computer to execute each process performed by the UE 100 or the gNB 200. The program may be recorded in a computer-readable medium. Using the computer-readable medium, it is possible to install the program in the 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.

[0140] In addition, circuits that execute each process performed by UE100 or gNB200 may be integrated, and at least a part of UE100 or gNB200 may be configured as a semiconductor integrated circuit (chip set, SoC (System on a chip)).

[0141] Although one embodiment has been described in detail above with reference to the drawings, the specific configuration is not limited to the above, and various design changes and the like are possible without departing from the scope of the invention. In addition, it is also possible to combine all or part of each embodiment as long as there is no contradiction.

[0142] This application claims priority to U.S. Provisional Application No. 63 / 094428 (filed October 21, 2020), the entire contents of which are incorporated herein by reference.

[0143] (Additional Note) ·introduction A revised work item on NR eIAB (Enhancements to Integrated Access AND Backhaul) was approved. Some of the objectives are to:

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

[0145] This appendix discusses 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.

[0146] 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 potential solutions to this were studied, as captured in the TR.

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

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

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

[0150] 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 becomes unstable, for example due to mmWave interference, and mobility and BH RLF are frequent occurrences in Rel-17 deployment scenarios. Therefore, according to the Rel-17 discussion, RAN2 should first have a common understanding of the BH link assumptions.

[0151] Proposal 1: RAN2 should assume that the quality of the backhaul link changes dynamically. Therefore, backhaul RLF is not a rare case in Rel-17 eIAB.

[0152] (Extended BH RLF indication) (Additional Indications (Type 2 and Type 3)) In the Rel-16 email discussion, four types of BH RLF notifications were discussed, as shown in Figure 16.

[0153] Finally, only type 4 "recovery failure" is specified as the BH RLF indication in Rel-16, which allows a child IAB-MT to recognize the RLF on the BH link and initiate the RLF recovery procedure.

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

[0155] On the other hand, many companies still believe that other types of indications would be useful, so it was discussed further in the email. 8 out of 13 companies preferred to introduce Type 2 "attempting recovery", while the other 2 thought it would be discussed in Rel-17. Therefore, it can be concluded that the majority of companies are ready to introduce Type 2 indication in Rel-17. Even if Type 2 indication can be introduced, the way to send it, such as by using BAP Control PDU, SIB1, or both, needs further consideration. Note that Type 1 and Type 2 have the same meaning.

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

[0157] Additionally, 9 out of 13 companies agreed to discuss Type 3 “BH link recovery” in Rel-17 as well. If Type 2 indication is introduced as in Proposal 2, it is very easy for the IAB-MT / UE to be notified when the parent BH link is successfully restored.

[0158] However, it should be considered whether such an explicit indication is really necessary. For example, if the type 2 indication is sent via SIB1, as shown in option 2 of Figure 17, 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 the 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, it has the disadvantage that the UE does not know the recovery because it does not have the BAP layer. Therefore, RAN2 should consider whether the type 3 indication is really necessary.

[0159] Proposal 3: If Proposal 2 is acceptable, RAN2 should consider whether an explicit BH RLF indication when the BH RLF is lost, i.e., Type 3 “BH Link Recovery”, should be introduced.

[0160] If Proposal 2 and / or Proposal 3 can be agreed upon, the behavior of the IAB-MT upon receiving an indication should be considered while the BH link is being restored. It was proposed that the IAB-MT should reduce / stop SR upon receiving an indication of type 2 and resume operation upon receiving an indication of type 3 (i.e., no more BH RLFs at the parent IAB node). This is one of the desired IAB-MT behaviors when the parent node is attempting to restore the BH link. It is assumed that other IAB-MT behaviors, such as suspending all RBs, are also possible.

[0161] 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 a BH RLF.

[0162] Another possible behavior is related to local rerouting, which has been proposed in many papers. Local rerouting is expected to be used for congestion mitigation, load balancing, etc., but may also be used for service continuity even in the case of an upstream BH RLF, such as a parent node. For example, an IAB node may perform local rerouting upon receiving a Type 2 indication, but in a Rel-16-like routing setup, it may revert to normal routing once the IAB node is notified of successful recovery from the upstream BH RLF, such as by receiving a Type 3 indication.

[0163] There are new IAB-MT actions related to Rel-17 functionality that may be performed upon receipt of a Type 2 indication. Therefore, in addition to Proposal 4, RAN2 should consider other IAB-MT actions when a parent node is recovering from a BH RLF.

[0164] Proposal 5: RAN2 should discuss if there are other IAB-MT operations while the parent node is trying to recover the BH link, such as local rerouting.

[0165] 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. The case of a single-connected BH is straightforward, since the indication is sent when an RLF occurs on this BH link. However, the case of a dual-connected BH is more complicated. For example, if the IAB node detects an RLF on the MCG, it will initiate the MCG fault information procedure, but the SCG will continue to function as the BH link, and therefore there is no need 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, and therefore a type 2 indication is sent at this point. Thus, a type 2 indication is sent when the 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 at stage 2 and stage 3.

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

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

[0168] (CHO Extension with Indication (Type 4)) Conditional Handover (CHO) was introduced in Rel-16 and, to our understanding, CHO can be used out of the box for Rel-16 IAB. Many companies have proposed its use for extending CHO or moving inter-donor IAB nodes.

[0169] In Rel-16, CHO is performed when the corresponding CHO event (A3 / A5) is satisfied or when the selected cell is a CHO candidate as a result of RRC re-establishment cell selection. These trigger conditions can be satisfied when an IAB node experiences a BH RLF on a BH link. On the other hand, they cannot be satisfied under an IAB specific RLF, such as an RLF due to reception of a BH RLF indication (type 4), because the radio condition of the BH link owned by the IAB node is good. In this case, one of the desired behaviors is for an IAB node to perform CHO when it receives a BH RLF indication.

[0170] Therefore, it is worth exploring additional trigger conditions for CHO to improve the topology adaptation of Rel-17 eIAB. We believe that at least the existing BH RLF indication (i.e., Type 4) is a promising candidate for a new trigger, but if introduced, we could further explore whether CHO would be executed upon receipt of a Type 2 indication.

[0171] Proposal 8: RAN2 should consider whether an additional trigger condition for CHO is defined, i.e., at least when an IAB node receives a BH RLF indication (Type 4). If introduced, further study is required as to whether it can be applied to Type 2.

[0172] (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.

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

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

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

[0176] In Rel-17, cell (re)selection and RRC re-establishment may occur more 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 the rapporteur in the above email discussion states, "this topic may be discussed again in Rel-17."

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

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

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

[0180] 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, a blacklist may be more appropriate to reduce overhead, for example by including only downstream IAB nodes of the IAB node of concern, and possibly even only a small number of child IAB nodes.

[0181] 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 have no such concern, since downstream IAB nodes obviously belong to the same IAB topology.

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

[0183] It may therefore be desirable for an IAB donor (or parent IAB node) to be able to choose whether to use a whitelist or a blacklist when providing information to a child IAB node for cell selection purposes. It should also be considered whether it would be beneficial to reuse that information for cell reselection purposes.

[0184] Proposal 10: RAN2 should agree that white or black lists (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.

[0185] If proposal 10 can be agreed upon, further consideration should be given to how the information (i.e. whitelists or blacklists) 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.

[0186] 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, whitelist / blacklist needs to be provided dynamically. Therefore, option 5, i.e., OAM, should be ruled out. Which method, i.e., option 1, 2, or 3, should be the baseline for enhancement needs further consideration.

[0187] Proposal 11: 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.

[0188] (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.

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

[0190] In Rel-16, the first solution, "changes in PDCP protocols / procedures", was not adopted because it would affect Rel-15 UEs.

[0191] 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 at the transmitting part 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.

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

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

[0194] Proposal 12: 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".

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

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

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

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

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

[0200] Proposal 13: 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.

[0201] (IAB node transfer between donors) The IAB node integration procedure has been introduced in Rel-16, which will be used for the initial integration of IAB nodes, i.e., they are still in the out-of-service phase.

[0202] Rel-17 aims to specify inter-donor IAB node movement, which will provide robust operation and apply to mobile IAB nodes. Unlike Rel-16, Rel-17 inter-donor IAB node movement is performed in the in-service phase, so that an inter-donor IAB node movement of one IAB node will impact the entire topology and cause service interruption. In other words, Rel-17 inter-donor IAB node movement requires consideration of how all IAB nodes in the IAB topology move to other IAB donors, specifically, how RRC reconfiguration with synchronization (i.e., handover commands) is provided to these affected IAB nodes.

[0203] Assuming that a child node (IAB node #2) is connected to a source IAB donor via a parent node (IAB node #1) as shown in FIG. 21, a set of signaling issues can be considered.

[0204] Case 1: If the parent is moved first, the RRC signaling path between the child and the source donor is released, so it is unclear how the child node can be moved. Case 2: When a child is moved first, the RRC signaling path to the target donor via the parent node has not yet been established, so it is unclear how the child node can reach the target donor (i.e., how to complete the RRC reconfiguration and send it to the target donor).

[0205] For case 1, we consider reusing CHO with some extensions of the child nodes, i.e., CHO is executed on the child node when the parent node is traversed. In case 2, by the time of, say, the parent node, the child is considered to be waiting to send an RRC reconfiguration to the target donor.

[0206] In either case, one option could be for the child node to first be released and then reintegrated using Rel-16 procedures, although given the significant service interruption this may not be viable as a solution in Rel-17.

[0207] While the overall procedure for inter-donor IAB node mobility is considered in RAN3, RAN2 needs to consider its impact on how multiple IAB nodes are reconfigured in a multi-hop network.

[0208] Proposal 14: RAN2 needs to consider how to reconfigure multi-hop IAB nodes due to inter-donor IAB node movement.

Claims

1. A communication control method for use in a cellular communication system, comprising: A first relay node that detects an occurrence of a failure in a backhaul link between a first relay node and a parent node of the first relay node transmits a failure occurrence notification to a second relay node; determining whether or not to transmit the failure occurrence notification to a lower node of the second relay node based on a value set by a network node; A communication control method comprising the steps of:

2. the fault occurrence notification includes a forwarding hop count that is incremented each time the fault occurrence notification is forwarded; the value set by the network node is an upper limit of the number of forwarding hops, The determining includes determining, when the number of forwarding hops is smaller than the upper limit, to forward the failure occurrence notification received from the first relay node to the lower node. The communication control method according to claim 1 .

3. the fault occurrence notification includes forwarding availability information indicating whether or not the fault occurrence notification is to be forwarded; The determining step includes determining whether or not to forward the fault occurrence notification to the lower node, in accordance with the forwarding availability information, by the second relay node. The communication control method according to claim 2.

4. When the second relay node determines not to transmit the failure occurrence notification to a lower node of the second relay node, the second relay node controls not to transmit the failure occurrence notification to the lower node of the second relay node. The communication control method according to claim 1 .

5. A receiving unit that receives a failure occurrence notification from the first relay node that detects the occurrence of a failure in a backhaul link between a first relay node and a parent node of the first relay node; a control unit that determines whether or not to transmit the fault occurrence notification to a lower node based on a value set by a network node. Relay node.

6. 1. A chipset for a relay node, comprising: receiving a failure occurrence notification from a first relay node that detects an occurrence of a failure in a backhaul link between a first relay node and a parent node of the first relay node; and determining whether or not to transmit the fault occurrence notification to a lower node based on a value set by the network node. Chipset.

7. At the relay node, receiving a failure occurrence notification from a first relay node that detects an occurrence of a failure in a backhaul link between a first relay node and a parent node of the first relay node; and determining whether or not to transmit the fault occurrence notification to a lower node based on a value set by the network node. program.

8. 1. A cellular communication system comprising: The first relay node detects an occurrence of a failure in a backhaul link between a first relay node and a parent node of the first relay node, and transmits a failure occurrence notification to a second relay node; the second relay node determines whether or not to transmit the failure occurrence notification to a lower node of the second relay node based on a value set by a network node; Cellular communication systems.

Images