Communication control method

Abstract

The communication control method according to the first embodiment is used in a cellular communication system. In the communication control method, a relay node that has detected a failure in a backhaul between the relay node and a parent node of the relay node transmits a notification for ordering a conditional handover, and a communication device receives the notification.

Description

Technical Field

[0001] This invention relates to a communication control method used in a cellular communication system. Background Technology

[0002] In the 3rd Generation Partnership Project (3GPP), a standardization project for cellular communication systems, the introduction of new relay nodes known as Integrated Access and Backhaul (IAB) nodes is being studied (see, for example, "3GPP TS 38.300V16.2.0 (2020-07)"). One or more relay nodes participate in communication between the base station and user equipment and perform the relaying of communication. Summary of the Invention

[0003] The communication control method according to the first aspect is a communication control method used in a cellular communication system. The communication control method includes: a relay node sending a notification instructing a conditional handover to be performed, the relay node having detected a failure in the backhaul link between the relay node and its parent node; and a communication device receiving the notification.

[0004] The communication control method according to the second aspect is a communication control method used in a cellular communication system. This communication control method includes: a first relay node, having detected a failure in the backhaul link between a first relay node and its parent node, including forwarding availability information indicating whether to forward the failure notification in a failure occurrence notification, and then sending the failure occurrence notification to a second relay node. The communication control method further 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 first relay node, based on the forwarding availability information.

[0005] The communication control method according to the third aspect is a communication control method used in a cellular communication system. The communication control method includes: a first relay node sending a first request to a second relay node when sending a failure occurrence notification indicating a failure in the backhaul link or a failure recovery notification indicating recovery from a failure in the backhaul link. The communication control method includes: in response to receiving the first request, 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 via a fifth relay node to the fourth relay node. The communication control method further includes: the second relay node sending packets according to the changed priority of the first route and / or the changed priority of the second route.

[0006] The communication control method according to the fourth aspect is a communication control method used in a cellular communication system. This communication control method includes: a second relay node receiving a failure occurrence notification from a first relay node indicating the occurrence of a failure in the backhaul link; and in response to receiving the failure occurrence notification, the second relay node deactivating the configuration of the primary path and activating the configuration of an alternative path to the primary path. Attached Figure Description

[0007] Figure 1 This is a diagram illustrating a configuration example of a cellular communication system according to an embodiment.

[0008] Figure 2 This is a diagram illustrating the relationships between IAB nodes, parent nodes, and child nodes.

[0009] Figure 3 This is a diagram illustrating a configuration example of a base station (gNB) according to an embodiment.

[0010] Figure 4 This is a diagram illustrating a configuration example of a relay node (IAB node) according to an embodiment.

[0011] Figure 5 This is a diagram illustrating a configuration example of a user equipment (UE) according to an embodiment.

[0012] Figure 6 This is a diagram illustrating an example of the protocol stack associated with IAB-MT's RRC and NAS connections.

[0013] Figure 7 This is a diagram showing an example of the protocol stack associated with the F1-U protocol.

[0014] Figure 8 This is a diagram showing an example of the protocol stack associated with the F1-C protocol.

[0015] Figure 9 This is a diagram illustrating a configuration example of a cellular communication system according to a first embodiment.

[0016] Figure 10 This is a diagram illustrating an operational example according to the first embodiment.

[0017] Figure 11 This is a diagram illustrating a configuration example of a cellular communication system according to a third embodiment.

[0018] Figure 12 This is a diagram illustrating an operational example according to the third embodiment.

[0019] Figure 13 This is a diagram illustrating a configuration example of a cellular communication system according to a fourth embodiment.

[0020] Figure 14 This is a diagram illustrating an operational example according to the fourth embodiment.

[0021] Figure 15 This is a diagram illustrating an operational example according to the fifth embodiment.

[0022] Figure 16 This is a diagram illustrating the types of BH RLF notifications.

[0023] Figure 17 Transmission options for the enhanced BH RLF indication are shown.

[0024] Figure 18 The diagram illustrates the determined solution for avoiding reconstruction to descendant nodes.

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

[0026] Figure 20 This is a diagram illustrating the option of introducing UL status transmission.

[0027] Figure 21 This study illustrates potential issues with RAN2 signaling during migration between donor IAB nodes. Detailed Implementation

[0028] A cellular communication system according to an embodiment will be described with reference to the accompanying drawings. In the description of the drawings, the same or similar reference numerals denote the same or similar parts.

[0029] Configuration of cellular communication system

[0030] A configuration example of a cellular communication system according to an embodiment will be described. Cellular communication system 1 according to the embodiment is a 3GPP 5G system. Specifically, the radio access scheme in cellular communication system 1 is New Radio (NR) as a radio access scheme for 5G. Note that Long Term Evolution (LTE) can be applied at least partially to cellular communication system 1. Future cellular communication systems such as 6G can be applied as cellular communication system 1.

[0031] Figure 1 This is a diagram illustrating a configuration example of a cellular communication system according to an embodiment.

[0032] like Figure 1 As shown, the cellular communication system 1 includes a 5G core network (5GC) 10, a user equipment (UE) 100, base station devices (hereinafter referred to as "base stations") 200-1 and 200-2, and IAB nodes 300-1 and 300-2. Each base station 200 may be referred to as a gNB.

[0033] The following description focuses on an example where each of the base stations 200 is an NR base station; however, base station 200 can be an LTE base station (i.e., an eNB).

[0034] Note that in the following description, base stations 200-1 and 200-2 may be referred to as gNB 200 (or base station 200), and IAB nodes 300-1 and 300-2 may be referred to as IAB node 300.

[0035] 5GC 10 includes Access and Mobility Management Function (AMF) 11 and User Plane Function (UPF) 12. AMF 11 is a means for performing various types of mobility control for UE 100. AMF 11 communicates with UE 100 using Non-Access Stratum (NAS) signaling to manage information about the area where UE 100 exists. UPF 12 is a means for performing transmission control of user data.

[0036] Each gNB 200 is a fixed wireless communication node and manages one or more cells. The term "cell" is used to indicate the smallest unit of a wireless communication area. The term "cell" may also be used to indicate the functions or resources used to perform wireless communication with the UE 100. A cell belongs to one carrier frequency. In the following text, cell and base station may be used interchangeably.

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

[0038] Each gNB 200 can be divided into a Central Unit (CU) and a Distributed Unit (DU). The CU and DU are interconnected via an interface known as the F1 interface. The F1 protocol is the communication protocol between the CU and DU and includes the F1-C protocol corresponding to the protocol used for the control plane and the F1-U protocol corresponding to the protocol used for the user plane.

[0039] Cellular communication system 1 supports IAB, which uses NR for backhaul to enable NR access via wireless relay. Donor gNB200-1 is a donor base station corresponding to the endpoint of the NR backhaul at the network end and includes additional functionality supporting IAB. This backhaul can be multi-hop via multiple hops (i.e., multiple IAB nodes 300).

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

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

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

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

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

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

[0046] Base station configuration

[0047] In this embodiment, the configuration of gNB 200 as a base station will be described. Figure 3 This is a diagram showing a configuration example of the gNB 200. (See diagram below.) Figure 3 As shown, gNB 200 includes a wireless communication device 210, a network communication device 220, and a controller 230.

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

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

[0050] Controller 230 performs various types of control for gNB 200. Controller 230 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs to be executed by the processor and information for the processing performed by the processor. The processor may include a baseband processor and a central processing unit (CPU). The baseband processor performs modulation and demodulation, encoding and decoding of baseband signals, etc. The CPU executes programs stored in the memory, thereby performing various types of processing. The processor performs layer-level processing as described below. Controller 230 can perform each processing operation in gNB 200 in each embodiment described below.

[0051] Relay node configuration

[0052] The configuration of IAB node 300, which serves as a relay node (or relay node device, which may be referred to as "relay node" below) according to an embodiment, will be described. Figure 4 This is a diagram illustrating a configuration example for an IAB node 300. (For example...) Figure 4As shown, IAB node 300 includes a wireless communication device 310 and a controller 320. IAB node 300 may include multiple wireless communication devices 310.

[0053] Wireless communication device 310 performs wireless communication (BH link) with gNB 200 and wireless communication (access link) with UE 100. Wireless communication device 310 for BH link communication and wireless communication device 310 for access link communication can be provided separately.

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

[0055] Controller 320 performs various types of control within IAB node 300. Controller 320 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs to be executed by the processor and information for the processing performed by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation and demodulation, encoding and decoding of baseband signals, etc. The CPU executes programs stored in the memory, thereby performing various types of processing. The processor performs layer-level processing as described below. Controller 320 can perform each processing operation in IAB node 300 in each embodiment described below.

[0056] User equipment configuration

[0057] In this embodiment, the configuration of UE 100 as a user equipment will be described. Figure 5 This is a diagram showing the configuration of UE 100. (As shown...) Figure 5 As shown, UE 100 includes a wireless communication device 110 and a controller 120.

[0058] Wireless communicator 110 performs wireless communication in the access link, specifically wireless communication with gNB 200 and wireless communication with IAB node 300. Wireless communicator 110 can also perform wireless communication in a secondary link, i.e., wireless communication with another UE 100. Wireless communicator 110 includes receiver 111 and transmitter 112. Receiver 111 performs various types of reception under the control of controller 120. Receiver 111 includes an antenna, converts (down-converts) the radio signal received by the antenna into a baseband signal (received signal), and outputs the baseband signal to controller 120. Transmitter 112 performs various types of transmission under the control of controller 120. Transmitter 112 includes an antenna, converts (up-converts) the baseband signal (transmitted signal) output by controller 120 into a radio signal, and transmits the radio signal from the antenna.

[0059] Controller 120 performs various types of control in UE 100. Controller 120 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs to be executed by the processor and information for processing performed by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation and demodulation, encoding and decoding of baseband signals, etc. The CPU executes programs stored in the memory, thereby performing various types of processing. The processor performs layer-level processing as described below. Controller 130 can perform each processing operation in UE 100 in each embodiment described below.

[0060] Protocol stack configuration

[0061] In this embodiment, the configuration of the protocol stack will be described. Figure 6 This is a diagram illustrating an example of the protocol stack associated with IAB-MT's RRC and NAS connections.

[0062] like Figure 6 As shown, the IAB-MT of IAB node 300-2 includes the Physical (PHY) layer, Media Access Control (MAC) layer, Radio Link Control (RLC) layer, Packet Data Convergence Protocol (PDCP) layer, Radio Resource Control (RRC) layer, and Non-Access Stratum (NAS) layer.

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

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

[0065] The RLC layer transmits data to the receiving RLC layer using the functions of the MAC and PHY layers. Data and control information are transmitted between the RLC layer of IAB-MT in IAB node 300-2 and the RLC layer of IAB-DU in IAB node 300-1 via a logical channel.

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

[0067] The RRC layer controls logical, transport, and physical channels based on the establishment, reconstruction, and release of radio bearers. RRC signaling for various configurations is transmitted between the RRC layer of the IAB-MT at IAB node 300-2 and the RRC layer of the donor gNB 200. When an RRC connection to the donor gNB 200 is present, the IAB-MT is in an RRC connected state. When no RRC connection to the donor gNB 200 is present, the IAB-MT is in an RRC idle state.

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

[0069] Figure 7 This is a diagram showing the protocol stack associated with the F1-U protocol. Figure 8 This is a diagram illustrating the protocol stack associated with the F1-C protocol. Here, an example is shown where the donor gNB 200 is divided into CU and DU.

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

[0071] In each backhaul link, Protocol Data Units (PDUs) of the BAP layer are transmitted via the backhaul RLC channel (BH NR RLC channel). Configuring multiple backhaul RLC channels in each BH link enables service prioritization and QoS control. The association between BAPPDUs 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.

[0072] like Figure 8 As shown, the F1-C protocol stack includes the F1AP layer and the Flow Control Transport Protocol (SCTP) layer, rather than... Figure 7 The GTP-U layer and UDP layer are shown.

[0073] First Embodiment

[0074] First, the failure detection and recovery attempts in the first embodiment will be described.

[0075] (Failure detection and recovery attempts)

[0076] Figure 9 This is a diagram illustrating a configuration example of a cellular communication system 1 according to a first embodiment.

[0077] Figure 9 The cellular communication system 1 shown includes node 500, IAB node 300-T, IAB node 300-C, and UE 100. IAB node 300-C and UE 100 can be communication devices.

[0078] Node 500 is the parent node of IAB node 300-T, and is either gNB 200 (or donor node, "gNB 200" may be referred to as "donor node" hereinafter) or IAB node 300 (parent IAB node). IAB-MT of IAB node 300-T has established a backhaul link (BH link) #1 with node 500. IAB-MT of IAB node 300-T is in RRC connection status.

[0079] IAB node 300-C is a child node (child IAB node) of IAB node 300-T. IAB-MT of IAB node 300-C has established BH link #2 with IAB node 300-T. IAB-MT of IAB node 300-C is in RRC connected state. Alternatively, IAB-MT of IAB node 300-C may not have established BH link #2 with IAB node 300-T and may be in RRC idle state.

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

[0081] In this configuration, assume that the IAB-MT of IAB node 300-T detects a radio link failure (BH RLF) in BH link #1. The IAB-MT of IAB node 300-T detects the BH RLF for example, and performs a recovery attempt to recover from the BH RLF.

[0082] First, when an asynchronous state is detected N310 times consecutively, the IAB-MT of IAB node 300-T detects a radio problem and starts timer T310. When a synchronized state is detected N311 times consecutively after the start of timer T310, the IAB-MT of IAB node 300-T stops timer T310.

[0083] Secondly, when timer T310 expires without being stopped, the IAB-MT of IAB node 300-T detects an RLF and starts timer T311 (i.e., begins RRC reconstruction processing), and performs cell selection processing to restore the BH link. When a suitable cell is selected through the cell selection process and the BH link is restored for the selected cell, the IAB-MT of IAB node 300-T stops timer T311. A suitable cell is defined as a cell that at least meets the minimum radio quality standards.

[0084] Third, when timer T311 expires and BH link recovery fails, the IAB-MT of IAB node 300-T transitions to the RRC idle state. Failure to recover from BH RLF after detecting BH RLF (i.e., the expiration of timer T311) can be referred to as BH link recovery failure hereinafter.

[0085] Here, when a BH RLF is detected, the IAB-DU of IAB node 300-T can notify the IAB-MT of IAB node 300-C and UE 100 of a Type 1 indication (RLF detected). A Type 1 indication is an example of a failure notification indicating that a BH RLF has been detected.

[0086] When a recovery operation from the BH RLF is detected, the IAB-DU of IAB node 300-T can notify the IAB-MT of IAB node 300-C and UE 100 of a Type 2 indication (attempt to recover). A Type 2 indication is an example of a notification indicating a failure to recover from the BH RLF.

[0087] When there is no distinction between Type 1 and Type 2 indications, the IAB-DU of IAB Node 300-T can send Type 1 / 2 indications to the IAB-MT of IAB Node 300-C and UE 100. Type 1 / 2 indications are also an example of failure occurrence notifications.

[0088] In addition, the notification types in IAB node 300-T include Type 3 indication (RLF recovery) and Type 4 indication (recovery failure). Type 3 indication is a recovery notification indicating that IAB node 300-T has recovered from the BH RLF. Type 4 indication is an example of a recovery failure notification indicating that IAB node 300-T has failed to recover from the BH RLF.

[0089] In the BH link, each indication can be transmitted within the BAP control PDU or MAC CE. In the access link, each indication can be transmitted within the SIB1.

[0090] On the other hand, even if the IAB-MT of IAB node 300-T detects a BH RLF in BH link #1, the radio status of BH link #2 and the radio status of the access link may still be good. Therefore, IAB node 300-C and UE 100 can still be in the cell of IAB node 300-T that has already detected the BH RLF.

[0091] Therefore, in the first embodiment, IAB node 300-T sends a notification instructing to perform a conditional switch to at least one of IAB node 300-C or UE 100.

[0092] Specifically, firstly, when a failure is detected in the backhaul link between a relay node and its parent node, the relay node sends a notification instructing a conditional handover. Secondly, a communication device receives this notification. The communication device could be, for example, IAB node 300-C and UE 100. Therefore, for example, when IAB node 300-C detects a failure in the backhaul link, either IAB node 300-C or UE 100 can perform a conditional handover to switch the connection to another IAB node.

[0093] Switch the description conditions.

[0094] Condition switching

[0095] exist Figure 9 In the illustrated cellular communication system 1, it is assumed that the IAB-MT of IAB node 300-C is in an RRC connected state, and that conditional handover is configured for the IAB-MT of IAB node 300-C. Conditional handover is a handover performed when one or more handover execution conditions (or triggering conditions) are met. The configuration of conditional handover includes candidate cells for handover and handover triggering conditions. The configuration of conditional handover can include various combinations of candidate cells and triggering conditions. The configuration of conditional handover also includes the RRC configuration corresponding to the candidate cells.

[0096] In a typical handover, UE 100 reports measurements of the radio state of the serving cell and / or neighboring cells to gNB 200. Based on this report, gNB 200 determines the handover to a neighboring cell and sends a handover command to UE 100. Therefore, in a typical handover, when the radio state of the serving cell deteriorates rapidly, a communication failure may occur before the handover is executed. Conversely, in conditional handover, a handover to a candidate cell corresponding to the pre-configured trigger conditions can be executed autonomously when these conditions are met. This resolves typical handover problems such as communication interruptions.

[0097] As a triggering condition, for example, at least one of an event referred to as event A3 or an event referred to as event A5 is specified. Event A3 is the event that the radio state of a neighboring cell is better than the radio state of the serving cell by a predetermined amount (predetermined offset) or more. Event A5 is the event that the radio state of the serving cell is worse than a first threshold, and the radio state of the neighboring cell is better than a second threshold.

[0098] Operation Example

[0099] In the first embodiment, an operational example will be described.

[0100] Figure 10 This is a diagram illustrating an operational example according to the first embodiment. Figure 10 The operation example shown illustrates Figure 9 An operational example of cellular communication system 1. In the following text, Figure 9 The IAB node 300-T shown can be referred to as the upper node 300-T, and the IAB node 300-C can be referred to as the lower node 300-C.

[0101] like Figure 10 As shown, in step S100, the cellular communication system 1 begins processing.

[0102] In step S101, the donor node configures conditional handover (CHO) for the downstream node 300-C and UE 100. In the first embodiment, the triggering condition included in the conditional handover configuration may include "receiving a notification instructing to perform conditional handover".

[0103] Note that conditional handover configuration can be performed via unicast signaling from the donor node's CU to the downstream node 300-C's IAB-DU and UE 100 (e.g., RRC reconfiguration messages, etc.).

[0104] In step S102, upon detecting a BH RLF, the upper node 300-T sends a notification instructing the lower node 300-C and UE 100 to perform a condition switching. This notification may be included in a BAP layer message (e.g., a BAP Control Protocol Data Unit (PDU)). Alternatively, the execution instruction may be included in a MAC Control Element (MAC CE). The lower node 300-C's IAB-MT, connected to the upper node 300-T's IAB-DU, can receive the BAP layer message including the execution instruction from the upper node 300-T's IAB-DU. On the other hand, UE 100 does not include a BAP layer and therefore cannot receive BAP layer messages. Therefore, the upper node 300-T's IAB-DU transmits the execution instruction within a System Information Block Type 1 (System Information Block (SIB1)). Thus, not only the lower node 300-C but also UE 100 can receive the execution instruction.

[0105] Note that the donor node can configure whether to execute the notification in step S102. This can be achieved by signaling the donor node's CU to perform this configuration for the upper node 300-T's IAB-DU. Alternatively, the upper node 300-T executes step S102 only if an IAB node 300-C or UE 100 exists under the upper node 300-T. This configuration can also be performed by the donor node's CU.

[0106] In step S103, in response to receiving a notification instructing the execution of a condition switch, the next node 300-C performs a condition switch. This satisfies one of the triggering conditions for the condition switch, namely "receiving a notification instructing the execution of a condition switch," and therefore the next node 300-C performs the switch.

[0107] Alternatively, upon receiving this notification, the downstream node 300-C may treat the received power from the serving cell (e.g., the reference signal received power (RSRP)) as "zero" (=-∞dBM) and may invoke event A3 or event A5. Even if "receiving a notification indicating the execution of conditional handover" is not included as a triggering condition, the process of treating the received power from the serving cell as "zero" in response to receiving this notification will cause the conditions of event A3 or event A5 to be met, thereby allowing the downstream node 300-C to perform the handover.

[0108] Alternatively, upon receiving a notification, the downstream node 300-C may apply a trigger timeout (TTT) or wait for a certain period of time to perform a condition switch. Subsequently, in response to receiving a notification from the upstream node 300-T within that period instructing to cancel the condition switch, the downstream node 300-C cancels the trigger condition and does not perform the condition switch. Note that in step S101, the TTT can be configured by the donor node's CU.

[0109] In step S104, the cellular communication system 1 completes a series of processing operations.

[0110] Second Embodiment

[0111] In the example described in the first embodiment, the lower node 300-C performs a switch in response to receiving an instruction to switch the execution condition. The second embodiment also includes examples other than event A3 or event A5 as triggering conditions.

[0112] Such triggering conditions may include "receiving a Type 1 indication". For example, in response to receiving a Type 1 indication from the upper node 300-T that meets the triggering conditions for a handover, the lower node 300-C or UE 100 performs a handover. When the upper node 300-T detects a failure (BH RLF), the lower node 300-C or UE 100 will perform a handover to another IAB node 300.

[0113] Triggering conditions may include "receiving a Type 2 indication". For example, in response to receiving a Type 2 indication from the upper node 300-T that meets the triggering conditions for a handover, the lower node 300-C or UE 100 performs a handover. When it is detected that the upper node 300-T is performing a recovery operation from a failure (BH RLF), the lower node 300-C or UE 100 performs a handover to another IAB node 300.

[0114] In addition, the triggering condition may include "receiving a Type 4 indication". For example, in response to receiving a Type 4 indication from the upper node 300-T that meets the triggering condition for handover, the lower node 300-C or UE 100 performs a handover. When the upper node 300-T detects a failure during recovery from a failure (BH RLF), the lower node 300-C or UE 100 will perform a handover to another IAB node 300.

[0115] This configuration can be implemented, for example, in step S101 of the first embodiment ( Figure 10 The donor node's CU is configured for the downstream node 300-C or UE 100's IAB-DU to receive a type 1, type 2, or type 4 indication as a trigger conditional switch.

[0116] Third Embodiment

[0117] The following viewpoint exists: When IAB node 300 receives a Type 1 / 2 indication, IAB node 300 should quickly restore the entire topology of IAB node 300 by sending the received Type 1 / 2 indication to its downstream nodes.

[0118] However, in response to receiving a Type 1 / 2 instruction, the next node may simultaneously initiate an RRC rebuild or similar process. In this case, all IAB nodes 300 in the topology may switch connections to other IAB nodes via an RRC rebuild or similar process. Therefore, the topology of IAB nodes 300 may crash.

[0119] In other words, when all IAB nodes 300 forward type 1 / 2 indications in the topology, even IAB nodes that do not need to perform RRC reconstruction or similar procedures can still perform RRC reconstruction or similar procedures. First, even if all IAB nodes 300 perform RRC reconstruction or similar procedures, signaling may fail to reach the donor node due to interference in the connection. Therefore, this processing may be unsuccessful. Furthermore, since IAB was initially performed through centralized processing by the donor node, this processing could lead to a centralized uncontrollable state.

[0120] Therefore, in the third embodiment, the Type 1 / 2 indication includes forwarding availability information. Alternatively, the Type 1 / 2 indication includes forwarding hop count information.

[0121] Specifically, firstly, when a failure is detected in the backhaul link between the first relay node and its parent node, the first relay node includes forwarding availability information indicating whether to forward the failure notification in the failure occurrence notification, and sends the failure occurrence notification to the second relay node.

[0122] Secondly, the second relay node forwards or does not forward the failure notification received from the first relay node based on the forwarding availability information.

[0123] Therefore, for example, IAB node 300 appropriately forwards type 1 / 2 indications, thereby allowing the topology to be quickly restored and minimizing the impact on the overall topology.

[0124] Figure 11 This is a diagram illustrating a configuration example of the cellular communication system 1 in the third embodiment. (See diagram for reference.) Figure 11 As shown, the IAB-MT of IAB node (or upstream node) 300-T detects a failure in BH link #1 or a similar link with node 500 using the method described in the first embodiment. The IAB-DU of IAB node 300-T sends a Type 1 indication, Type 2 indication, or Type 1 / 2 indication, including forwarding availability information or similar information, to the IAB-MT of IAB node 300-C, which is the downstream node. Based on the forwarding availability information or similar information included in the received indication, the downstream node 300-C may forward or not forward the indication to a further downstream IAB node 300.

[0125] Figure 12 This is a diagram illustrating an operational example according to the third embodiment.

[0126] like Figure 12 As shown, in step S1 10, the cellular communication system 1 begins processing.

[0127] In step S111, when the IAB-MT of IAB node 300-T detects a BH RLF in BH link #1 of IAB node 300-T, the IAB-DU of IAB node 300-T sends a Type 1 indication to the IAB-MT of the lower node 300-C. In step S111, when the IAB-MT of IAB node 300-T detects that a BH RLF recovery operation has started in BH link #1, the IAB-DU of IAB node 300-T sends a Type 2 indication to the IAB-MT of the lower node 300-C. Note that when the Type 1 indication and the Type 2 indication are not distinguished, the IAB-DU of IAB node 300-T sends a Type 1 / 2 indication to the IAB-MT of the lower node 300-C.

[0128] Here, Type 1 indication, Type 2 indication, and Type 1 / 2 indication include the following information.

[0129] That is, the indication includes indication type information (classification information). Type 1 indication includes classification information for indication type 1. Note that the indication types also include type 3 and type 4 indications. Therefore, the classification information can also include the types of these indications.

[0130] These indications include forwarding availability information indicating whether to forward the indication. For example, "0" indicates forwarding is disabled, and "1" indicates forwarding is enabled (forwarding is performed). Alternatively, the indication may include information indicating whether the indication is sent in response to a BH RLF in IAB node 300. For example, "0" could indicate a BH RLF in IAB node 300, and "1" could indicate a BH RLF in the parent node of IAB node 300. Figure 11 In the example, when IAB node 300-T detects BH RLC in BH link #1 of IAB node 300-T and sends a Type 1 indication to downstream node 300-C, IAB node 300-T includes a "0" in the Type 1 indication as information and then forwards the Type 1 indication, and downstream node 300-C includes a "1" in the Type 1 indication as information and then forwards the Type 1 indication. Alternatively, the indication may include information indicating whether the indication was sent in response to an indication from upstream node 300-T. In this case, upon receiving the Type 1 indication from upstream node 300-T, downstream node 300-C forwards the Type 1 indication, including information indicating whether the indication was sent in response to an indication from upstream node 300-T, to further downstream nodes.

[0131] Alternatively, these instructions may include forwarding jump information. For example, in Figure 11 In this scenario, assume IAB node 300-T is the highest-ranking IAB node in the predetermined topology. In this case, when the IAB-MT of IAB node 300-T detects a BH RLF, it sends a Type 1 indication including "0" as forwarding hop count information. The forwarding hop count increments with each forwarding operation. Each IAB node 300 includes the incrementing forwarding hop count in its Type 1 indication and then forwards the Type 1 indication to the next downstream node. The upper limit for the forwarding hop count can be configured by the donor node's CU via signaling for each IAB-DU (or IAB-MT) of IAB node 300. Each IAB-DU of IAB node 300 compares the forwarding hop count information included in each received indication with this upper limit and forwards or does not forward the received indication based on the comparison result. For example, if the forwarding hop count information is the same as the upper limit, the IAB-DU of IAB node 300 does not forward the received indication; if the forwarding hop count is less than the upper limit, the IAB-DU forwards the received indication.

[0132] Return to reference Figure 12 In step S112, the next node 300-C determines whether to forward the received instruction to the next IAB node 300 based on the information included in the received instruction. The next node 300-C then forwards or does not forward the received instruction based on this determination.

[0133] For example, when the indication includes forwarding availability information, the following operation is performed. That is, when the indication includes "0" as forwarding availability information, the IAB-DU of the downstream node 300-C does not forward the received indication. On the other hand, when the indication includes "1" as forwarding availability information, the IAB-DU of the downstream node 300-C forwards the received indication to the further downstream node.

[0134] For example, when the indication includes information about the number of forwarding hops, the following processing is performed. In other words, the IAB-DU of the lower node 300-C compares the forwarding hop count information included in each received indication with an upper limit value. If the forwarding hop count information is the same as the upper limit value, the IAB-DU does not forward the received indication. On the other hand, if the number of forwarding hops is less than the upper limit value, the IAB-DU of the lower node 300-C forwards the received indication. Alternatively, when the number of forwarding hops exceeds the upper limit value, the IAB-DU of the lower node 300-C may determine not to forward the received indication. When the number of forwarding hops is equal to or less than the upper limit value, the IAB-DU of the lower node 300-C may forward the received indication.

[0135] In step S113, the cellular communication system 1 terminates a series of processing operations.

[0136] In the example described in the third embodiment above, when an indication such as a Type 1 indication is forwarded, the indication includes forwarding availability information. For example, instead of forwarding every indication such as a Type 1 indication, a notification of condition switching could be forwarded, as described in the first embodiment. In this case, the IAB node 300-T could send a notification that includes forwarding availability information or forwarding hop count information.

[0137] Fourth embodiment

[0138] 3GPP has been discussing route prioritization in IAB. Route prioritization, for example, in IAB, is the priority configured for each of multiple routes (which may be referred to as "routes" below) configured for the same destination.

[0139] Figure 13This is a diagram illustrating an example of a cellular communication system 1 according to a fourth embodiment. IAB node 300-T is the upper node, and IAB node 300-C is the lower node. Further lower nodes of lower node 300-C include multiple IAB nodes 300-R1, 300-R2, ..., and 300-D. In this case, below lower node 300-C, there exists a route #1 from IAB node 300-R1 to IAB node 300-D. Below lower node 300-C, there exists a route #2 from IAB node 300-R2 to IAB node 300-D. For example, priority "1" (= highest priority) is configured for route #1, and priority "2" (= lower than priority "1", and since there are only two routes, priority "2" is the lowest priority) is configured for route #2. Regarding priorities, for example, the highest priority can be assigned to the route with the fewest hops. Note that this priority can be configured by the donor node's CU to the IAB-DU of each IAB node 300 via signaling.

[0140] 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 configured for each route, and then when it receives a type 3 indication, the lower node 300-C changes the route priority back to the state before the change.

[0141] Specifically, firstly, when sending a failure occurrence notification indicating that a failure has occurred in the backhaul link or a recovery failure notification indicating that a failure has occurred in the backhaul link, the first relay node sends a first request to the second relay node to change the routing priority.

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

[0143] Third, the second relay node sends packets based on the priority of the change of the first route and / or the priority of the change of the second route.

[0144] Figure 14 This is a diagram illustrating an operational example according to the fourth embodiment.

[0145] like Figure 14 As shown, in step S120, the cellular communication system 1 begins processing.

[0146] In step S121, the upper node 300-T detects an RLF in BH link #1. Alternatively, the upper node 300-T may also detect a failure to recover from an RLF in BH link #1. Alternatively, the upper node 300-T may receive a Type 1 / 2 indication sent from a further upper IAB node 300. Alternatively, the upper node 300-T may receive a Type 4 indication sent from a further upper IAB node 300.

[0147] In step S122, the upper node 300-T sends a notification to the lower node 300-C indicating a request to change the routing priority. For example, in step S121, upon detecting an RLF in BH link #1, the upper node 300-T sends a type 1 / 2 indication to the lower node 300-C. In this case, the type 1 / 2 indication itself can indicate a request to change the routing priority. Alternatively, the type 1 / 2 indication can include an indicator indicating whether the routing priority has been changed. For example, when the upper node 300-T detects a failure to recover from an RLF in BH link #1, the upper node 300-T sends a type 4 indication to the lower node 300-C. The type 4 indication itself can indicate a request to change the routing priority. Alternatively, the type 4 indication can include an indicator indicating whether the routing priority has been changed. For example, the upper node 300-T can send either a type 1 / 2 indication or a type 4 indication received from a further upper IAB node 300 to the lower node 300-C. Type 1 / 2 or Type 4 indicators can themselves indicate a request to change the route priority, or each indicator can include an indicator indicating whether the route priority has been changed.

[0148] Note that BAP control PDUs, SIBIs, MAC CEs, etc., can be used to send notifications indicating requests to change routing priorities.

[0149] In step S123, the downstream node 300-C changes its route priority. An example of changing the route priority is as follows.

[0150] 1) Node 300-C can treat the route with the highest current priority (route #1) as the lowest priority. In this case, Figure 13 In the example, route #1 has the lowest priority, and route #2 has the highest priority.

[0151] 2) Node 300-C can treat the route with the current second priority as the highest priority. In this case, Figure 13 In the example, route #2, which has the second priority, becomes the highest priority.

[0152] 3) Furthermore, the downstream node 300-C can lower the priority of the route with the current highest priority by one or several levels. In this case, Figure 13 In the example, when the priority is reduced by two levels, the downstream node 300-C changes the priority of route #1 from "1" to "3". Therefore, the priority of route #1 after the change is lower than the priority of route #2 "2", and route #2 takes precedence over route #1.

[0153] 4) In addition, the downstream node 300-C can raise the priority of a route by one or more levels, except for the current highest priority. In this case, Figure 13 In the example, when the priority is increased by two levels, the lower node 300-C changes the priority of route #2 from "2" to "0". Therefore, route #2 has the highest priority and thus has a higher priority than route #1.

[0154] Note that these changes to route priorities can be temporary. For example, by combining any of the items in 1) through 4) above, the next node 300-C can not only change the priority of some routes, but also change the priority of all routes.

[0155] Return to reference Figure 14 In step S124, the downstream node 300-C performs routing processing on the packets according to the changed routing priority. For example, in Figure 13 In the example, the IAB-MT of the lower node 300-C sends a packet addressed to IAB node 300-D to IAB node 300-R2 on route #2 instead of IAB node 300-R1 on route #1.

[0156] Return to reference Figure 14 In step S125, upon detecting that BH link #1 has recovered, the upstream node 300-T sends a notification to the downstream node 300-C indicating that the route priority will be changed back to its pre-change state. This notification can be a Type 3 indication itself. That is, the Type 3 indication itself can be a notification indicating that the route priority has been changed back to its original state before the change. Alternatively, the Type 3 indication can include an indicator indicating that the route priority has been changed back to its pre-change state.

[0157] In addition to BH link #1, the upstream node 300-T can detect the recovery of the backhaul link by receiving a Type 3 indication sent from the upstream IAB node 300. Furthermore, in this case, the upstream node 300-T sends a notification indicating that the route priority has been reverted to its pre-change state. The downstream node 300-C can, based on the successful recovery of its BH link, perform the process of reverting the route priority to its pre-change state. For example, when another parent node's RRC is successfully rebuilt or a similar situation occurs, the downstream node 300-C performs the process of reverting the route priority to its pre-change state.

[0158] In step S126, the downstream node 300-C performs processing to revert the route priority back to its original state before the change. For example, the IAB-DU (or IAB-MT) of the downstream node 300-C can change the route priority configured in step S123 to the priority configured by the donor node. Alternatively, the IAB-DU of the downstream node 300-C can request the CU of the donor node to revert the route priority back to its state before the change. In this case, the CU of the donor node can resend the route configuration sent before the route priority change to the IAB-DU of the downstream node 300-C, thereby causing a reconfiguration of the route priority before the change.

[0159] In step S127, the downstream node 300-C performs packet routing processing by changing the previous route priority according to the route priority. For example, in Figure 13 In the example, the downstream node 300-C changes the transmission destination of the packet addressed to IAB node 300-D from IAB node 300-R2 on route #2 to IAB node 300-R1 on route #1.

[0160] Return to reference Figure 14 In step S128, the cellular communication system 1 ends a series of processing operations.

[0161] Note that although an example of a type 1 / 2 indicator has been described in the fourth embodiment, a type 1 / 2 indicator can be replaced by a type 1 indicator or a type 2 indicator.

[0162] Fifth embodiment

[0163] In the fifth embodiment, when a type 1 / 2 indication is received from the upper node 300-T, the IAB node (or lower node) 300-C deactivates the configuration of the main path and activates the configuration of the alternative paths of the main path.

[0164] Specifically, first, the second relay node receives a failure notification from the first relay node indicating that a failure has occurred in the backhaul link. Second, in response to receiving the failure notification, the second relay node deactivates the configuration of the primary path and activates the configuration of the alternative path to the primary path.

[0165] For example, in Figure 13 In this configuration, route #1 is the primary path, and route #2 is the alternative path. This configuration is enabled by providing route configuration to the IAB-DU of IAB node 300-C via the donor node's CU. The route configuration includes, for example, the BAP address of each IAB node 300 on the primary path and the BAP address of each IAB node 300 on the alternative path. The former may be information related to the configuration of the primary path, while the latter may be information related to the configuration of the alternative path.

[0166] Figure 15 This is a diagram illustrating an operational example according to the fifth embodiment.

[0167] like Figure 15 As shown, in step S130, IAB node 300-C begins processing.

[0168] In step S131, upon receiving a Type 1 / 2 indication from the upper node 300-T, IAB node 300-C deactivates the primary path configuration and activates the alternative path configuration. For example, the IAB-DU of IAB node 300-C stops reading the information related to the primary path configuration stored in memory and begins reading the information related to the alternative path configuration stored in memory.

[0169] In step S132, IAB node 300-C routes packets to the activated path. For example, based on information related to the configuration of alternative paths, IAB node 300-C's 1AB-DU sends packets received from the parent node 300-T to IAB node 300-R2's IAB-MT.

[0170] In step S133, upon receiving a Type 3 instruction from the parent node 300-T, IAB node 300-C activates the configuration of the primary path and deactivates the configuration of the alternative paths. For example, the IAB-DU of IAB node 300-C begins reading information related to the configuration of the primary path stored in memory and stops reading information related to the configuration of the alternative paths stored in memory.

[0171] In step S134, IAB node 300-C routes packets to the activated path. For example, based on information related to the configuration of the primary path, IAB node 300-C's IAB-DU sends packets received from the parent node 300-T to IAB node 300-R1's IAB-MT.

[0172] Then, in step S135, IAB node 300-C completes a series of processing operations.

[0173] Note that although an example of a type 1 / 2 indicator has been described in the fifth embodiment, a type 1 / 2 indicator may be replaced by a type 1 indicator or a type 2 indicator.

[0174] Other embodiments

[0175] A program may be provided that enables the computer to perform each process executed by the UE 100 or gNB 200. This program may be recorded on a computer-readable medium. The computer-readable medium allows the program to be installed on the computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. Non-transitory recording media are not particularly limited and may, for example, be a recording medium such as a CD-ROM or DVD-ROM.

[0176] The circuitry for performing the processing operations to be performed by the UE 100 or gNB 200 can be integrated, and at least a portion of the UE 100 or gNB 200 can be configured as a semiconductor integrated circuit (chipset or SoC (system-on-chip)).

[0177] Although embodiments have been described in detail with reference to the accompanying drawings, the specific configurations are not limited to those described above, and various design changes can be made without departing from the spirit of the work. All or some embodiments can be combined, as long as the combination remains consistent.

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

[0179] Additional notes

[0180] introduction

[0181] Revisions related to NR Enhanced Integrated Access and Backhaul (NR eIAB) have been approved. Some of their objectives are as follows.

[0182] Enhanced topology adaptation

[0183] - Specifications for the migration process between donor IAB nodes to enhance robustness and load balancing, including enhancements to reduce signaling load.

[0184] - Enhanced specifications to reduce service disruptions caused by IAB node migration and BH RLF recovery.

[0185] - Enhanced specifications for topological redundancy, including support for CP / UP separation.

[0186] Enhancements to topology, routing, and transport.

[0187] - Enhanced specifications for improving topology-wide fairness, multi-hop latency, and congestion mitigation.

[0188] In the supplementary notes, the topology adaptation enhancements to be considered for version 17 of eIAB will be discussed from the following perspectives: assumptions about backhaul link quality, enhancements to BH RLF indication, BH RLF recovery and cell (re)selection, and enhancements to lossless delivery.

[0189] discuss

[0190] Assumptions about backhaul link quality

[0191] During the research phase of version 15, as background to the requirements, the TR stated: "Radio backhaul links are easily affected by obstacles such as moving objects (e.g., vehicles), seasonal changes (leaf), and changes in infrastructure (new buildings). This vulnerability also applies to physically stationary IAB nodes." Therefore, as already reflected in the TR, various problems caused by multi-hop / radio backhaul and potential solutions to these problems were investigated.

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

[0193] In the version 16 specification work, it is assumed that the IAB node is stationary, i.e., a "stationary IAB node". Therefore, even with backhaul links via millimeter waves and / or local IAB nodes that can be deployed using unmanaged methods, the backhaul (BH) is sufficiently stable in a properly designed deployment. Therefore, only the recovery process in conjunction with the basic functionality of the BH RLF is defined. This basic functionality includes existing features such as BH RLF indication (also referred to as Type 4, i.e., "recovery failure") and RRC rebuild, MCG / SCG failure indication, and / or conditional switching.

[0194] Finding 2: In version 16 of the IAB, only quiescent IAB nodes with sufficiently stable backhaul links are assumed.

[0195] In the enhancements of Release 17, one anticipated use case is "moving IAB nodes," which could be part of "migration between donor IAB nodes" (even if not explicitly described in the WID). Furthermore, secondary objectives in the WID (e.g., enhancements to reduce service disruptions due to IAB node migration and BH RLF recovery) and "enhancements to topology redundancy") clearly imply that BH links become unstable, for example, due to millimeter wave interference, and that migrations and BH RLFs occur frequently in the Release 17 deployment scenario. Therefore, based on the discussion of Release 17, RAN2 should first reach a consensus on the assumptions regarding BH links.

[0196] Recommendation 1: RAN2 should assume that the quality of the backhaul link changes dynamically. Therefore, backhaul RLF is not uncommon in version 17eIAB.

[0197] Enhancement of BH RLF indication

[0198] Additional instructions (Type 2 and Type 3)

[0199] In the email discussion of version 16, the following were discussed: Figure 16 The four types of BH RLF notifications are shown.

[0200] Ultimately, in version 16, only the "Recovery Failure" corresponding to type 4 is defined as a BH RLF indication. This allows the sub-IAB-MT to identify RLFs on the BH link to initiate an RLF recovery process.

[0201] Finding 3: In version 16, only the "Recovery Failure" corresponding to type 4 is defined as a BH RLF indicator.

[0202] On the other hand, many companies still find other types of instructions beneficial, and this was discussed further via email. Eight of the thirteen companies were willing to introduce a "attempted recovery" corresponding to Type 2, and the other two believed this would be discussed in Release 17. Therefore, in summary, most companies are ready to introduce Type 2 instructions into Release 17. Even where Type 2 instructions can be introduced, the methods for sending them require further investigation; these methods could include using BAP control PDUs, SIB1, or both. Note that Type 1 and Type 2 have the same meaning.

[0203] Recommendation 2: RAN2 should agree that an "attempt to recover" mechanism corresponding to Type 2 of the BH RLF indication has been introduced. Further investigation is needed regarding whether to use BAP control PDU, SIB1, or both to perform the transport.

[0204] Nine of the thirteen companies also agreed to discuss “BH link restored” corresponding to Type 3 in version 17. Notification to the IAB-MT / UE is straightforward when a Type 2 indication is introduced as in Recommendation 2 and the parent BH link is successfully restored.

[0205] However, it should be investigated whether such explicit indication is truly necessary. For example, for a Type 2 indication sent via SIB1, if the BH link is not in RLF (i.e., "recovered"), the indication should no longer be broadcast, such as... Figure 17Option 2 is shown in the table. Therefore, downstream IAB nodes and UEs identify whether the BH link has been restored based on the absence of a Type 2 indication in SIB1. Of course, the advantage of sending a Type 3 indication via the BAP control PDU is that downstream IAB nodes can know in a timely manner that the BH link has been restored. However, the UE does not include the BAP layer and is therefore disadvantageously unable to recognize the restoration. Therefore, RAN2 should investigate whether a Type 3 indication is truly necessary.

[0206] Recommendation 3: When Recommendation 2 can be agreed upon, RAN2 should study whether to introduce an explicit BH RLF indication (i.e., corresponding to Type 3 "BH link restored"), which is provided when the BH RLF no longer exists.

[0207] When Recommendation 2 and / or Recommendation 3 can be agreed upon, the operation of the IAB-MT during BH link recovery, after the IAB-MT has received an instruction, should be investigated. The recommendation is as follows: When the IAB-MT receives a Type 2 instruction, the IAB-MT reduces / stops the SR, and when the IAB-MT receives a Type 3 instruction (i.e., the BH RLF no longer exists in the parent IAB node), the IAB-MT resumes the operation. This operation is a desirable action for the IAB-MT while the parent node is attempting to recover the BH link. It is assumed that other operations by the IAB-MT (e.g., suspending all RBs) are also possible.

[0208] Recommendation 4: RAN2 should agree that when the BH RLF no longer exists in the parent node, the IAB-MT resume scheduling request has received a type 2 indication and then reduced / stopped the scheduling request.

[0209] Another possible operation involves local rerouting, which has been mentioned in numerous papers. Local rerouting is intended for congestion mitigation, load balancing, etc., but it can also be used for service continuity, even in cases where an upstream BH RLF exists in the parent node. For example, an IAB node can perform local rerouting upon receiving a Type 2 indication, but in routing configurations such as version 16, the IAB node reverts to normal routing upon being notified of a successful recovery from an upstream BH RLF by receiving a Type 3 indication, etc.

[0210] The new IAB-MT operation associated with the version 17 feature is available, and this operation can be performed upon receiving a type 2 instruction. Therefore, in addition to Recommendation 4, RAN2 should also investigate other IAB-MT operations that can be performed when the parent node is attempting to recover from the BH RLF.

[0211] Recommendation 5: RAN2 should discuss when other IAB-MT operations (such as local rerouting) are available while the parent node is attempting to restore the BH link.

[0212] When the BH link of an IAB node is in an RLF (Recurrent Leak) state, it is assumed that the 1AB-DU sending the indication sends a Type 2 BH RLF indication. The indication is sent when an RLF occurs in the BH link, thus the case of a single-connection BH is simple. However, the case of a BH with a full-duplex connection is more complex. For example, when an RLF is detected in the MCG, the IAB node initiates an MCG failure information procedure, but the SCG continues to be used as the BH link; therefore, a Type 2 indication is not needed at this time. When the MCG failure information procedure fails due to reasons such as a T316 timeout, the IAB-MT initiates an RRC (Recurrent Recovery Call) reconstruction; therefore, a Type 2 indication is sent at this time. Thus, the Type 2 indication is sent when initiating an RRC reconstruction, not when triggering an MCG / SCG failure information. In either case, since this involves the operation of the IAB-DU, it should be carefully examined whether / how this should be reflected in the specification. That is, it should be studied whether to add a comment in phase 2 or phase 3, or whether nothing needs to be reflected.

[0213] Recommendation 6: RAN2 should agree that Type 2 BH RLF instructions can be sent when IAB-DU initiates an RRC reconstruction, rather than when IAB-DU initiates any RLF recovery procedure.

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

[0215] Enhancement using the indicated CHO (Type 4)

[0216] Conditional Switching Requests (CHOs) were introduced in version 16, and to our knowledge, CHOs can be used as is in version 16 IAB. Many companies have suggested enhancing CHOs or using them for migration between donor IAB nodes.

[0217] In version 16, a CHO is executed when the corresponding CHO event (A3 / A5) is met, or when the selected cell is a CHO candidate as a result of cell selection for RRC reconstruction. These triggering conditions can be met when the IAB node experiences a BH RLF on a BH link. On the other hand, since the BH link owned by the IAB node is in good radio condition, the triggering conditions cannot be met under IAB-specific RLFs (e.g., RLFs caused by receiving a BH RLF indication (Type 4). In this case, a desirable operation is to execute the CHO when the IAB node receives a BH RLF indication.

[0218] Therefore, to improve topology adaptation in version 17eIAB, it is worthwhile to investigate additional triggering conditions for CHOs. At least the existing BH RLF indication (i.e., type 4) is considered a promising candidate as a new trigger, but if introduced, it is worth further investigation into whether to execute a CHO upon receiving a type 2 indication.

[0219] Recommendation 8: RAN2 needs to investigate whether any additional triggering conditions should be defined for CHO, i.e., at least the case where an IAB node receives a BH RLF indication (Type 4) should be investigated. If introduced, further investigation is needed to determine whether it applies to Type 2.

[0220] Enhanced BH RLF recovery and cell (reselection)

[0221] During RRC reconstruction, the IAB-MT first performs a cell selection process to find a suitable cell. Version 16 identified potential issues during this process, such as the possibility that the IAB-MT might select a descendant node. This was therefore discussed in an email discussion.

[0222] like Figure 18 As shown, along with the presenter's perspective, five possible solutions are discussed and summarized.

[0223] The conclusion is "No further action will be taken on this topic in version 16." This means that RAN2 agrees with "Option 4: Nothing is needed because RRC reconstruction will fail if the BH connection does not exist." Option 4 requires waiting for failure (T301 expiration) and eventually entering an idle state, so it is acceptable in the version 16 deployment scenario even if BH RLF recovery takes further time.

[0224] Discovery 4: In version 16, when an IAB node attempts to initiate an RRC rebuild request to a descendant node, the IAB node needs to wait for the attempt to fail and eventually enters an idle state.

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

[0226] Recommendation 9: RAN2 should agree to study the optimization of cell (re)selection to avoid rebuilding to unsuitable nodes (e.g., descendant nodes).

[0227] It can be assumed that, in addition to option 4 above, a common concept in the determined solutions is that IAB-MT provides some type of whitelist or blacklist for cell selection purposes. For example, assuming that topology changes may occur frequently in version 17 due to "donor IAB node migration," whitelists and blacklists each have their advantages and disadvantages depending on the topology and the location of the IAB nodes.

[0228] For example, from the perspective of the IAB node closest to the IAB donor (i.e., the topmost node in the DAG topology), it is more reasonable to provide a whitelist because there are fewer candidate nodes and in some cases only one IAB donor DU.

[0229] However, in another example, viewed from the perspective of an IAB node far from the IAB donor (i.e., the bottommost node in the DAG topology), it might be necessary to include a large number of candidate nodes in a whitelist. Conversely, a blacklist might be more appropriate, for example, because it only includes downstream IAB nodes of the IAB node to be monitored, and in some cases only a small number of child IAB nodes, thus reducing overhead.

[0230] One concern with the whitelist is that, due to the nature of "donor IAB node migration" in version 17, the list may need to include candidate IAB nodes belonging to different / adjacent IAB topologies, thus potentially increasing its size. On the other hand, downstream IAB nodes naturally belong to the same IAB topology, so the blacklist does not address this issue.

[0231] Finding 5: Depending on the topology and location of the IAB nodes, both whitelists and blacklists have their advantages and disadvantages.

[0232] Therefore, when providing information to child IAB nodes for cell selection purposes, it may be expected that the IAB donor (or parent IAB node) can choose to use a whitelist or a blacklist. Note that it should also be investigated whether reusing this information for cell reselection purposes would be beneficial.

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

[0234] If recommendation 10 can be agreed upon, further research should be conducted into methods for providing this information (i.e., whitelisting or blacklisting). Option 1 assumes a CHO configuration and may require some enhancements. Option 2 assumes additional instructions, such as a Type 2 BHRLF instruction. Option 3 assumes providing information on the overall topology that is not present in the existing configuration. Option 5 assumes an OAM-based configuration; however, as the reporter noted, this is problematic.

[0235] Reconsidering the assumptions of Version 17 (i.e., Recommendation 1), namely that the parent IAB node or IAB donor needs to provide a list to the child IAB node in response to topology changes, and that the whitelist / blacklist needs to be provided dynamically, Option 5 (i.e., OAM) should be ruled out. Which approach (i.e., which of Options 1, 2, and 3) will be used as the baseline for enhancement requires further investigation.

[0236] Recommendation 11: RAN2 should agree that the parent IAB node or IAB donor should dynamically provide whitelists / blacklists each time the topology changes. Further details require investigation.

[0237] Enhancement of lossless transfer

[0238] During the research phase of version 15, the issue of multi-hop RLC ARQ was discussed and illustrated in section 8.2.3 of the TR. In version 16, a protocol stack was defined for the IAB, including the unsplit RLC layer. In other words, in version 16, end-to-end ARQ was excluded, and hop-by-hop ARQ was adopted.

[0239] Regarding hop-by-hop ARQ, issues related to end-to-end reliability (i.e., lossless transmission using UL packets) were identified. Figure 19 As shown, three solutions were identified and evaluated.

[0240] In version 16, the "Modification of PDCP Protocol / Procedure" as the first option was not adopted because it would affect the UE of version 15.

[0241] The second solution, "rerouting PDCP PDUs buffered on intermediate IAB nodes," is supported as an implementation choice in the BAP layer. The BAP layer can implement the second solution based on the assumption that "data buffering occurs in the transport portion of the BAP entity until the RLC-AM entity receives an acknowledgment response, depending on the implementation." These BAP implementations are considered to avoid packet loss in "most" cases of version 16 deployment scenarios (i.e., using fixed IAB nodes). However, these implementations do not, for example... Figure 19 It's not as perfect as it seems.

[0242] The "introduction of UL status transfer" corresponding to the third solution is a promising solution for ensuring the lossless transfer of UL data, which takes into account... Figure 19 The evaluation results mentioned above. The idea is to delay until the UE's RLC ARQ, thereby initiating PDCP data recovery at the UE if necessary. However, this is not defined in version 16 because it was assumed that UL packets would be rarely dropped due to topology changes, based on the assumption of a stationary IAB node.

[0243] Given the assumptions of version 17, namely that from the perspective of recommendation 1, UL packet loss during topology changes (which occurs frequently in version 17) is no longer uncommon, further research into a third solution is needed. Therefore, in addition to the results embodied in TR, RAN2 should also discuss enhancement mechanisms for guaranteeing lossless delivery in L2 multi-hop networks.

[0244] Recommendation 12: RAN2 should agree to introduce the solution identified in TR 38.874, namely a mechanism based on some form of "UL state transfer" to ensure lossless transfer in situations where topology changes may occur frequently.

[0245] Details of the third solution (i.e., "introducing UL status transfer") were discussed via email, including two options (i.e., C-1 and C-2), such as... Figure 20 As shown.

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

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

[0248] Finding 6: C-2 as a solution for “introducing UL status transfer” can be an enhanced baseline for version 17, and this can also be implemented in version 16.

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

[0250] Recommendation 13: RAN2 should agree to define an RLC ARQ mechanism for lossless delivery of UL packets in Phase 2. This RLC ARQ mechanism delays the transmission of the ACK to the child node / UE before it is received from the parent IAB node (i.e., C-2). Whether and how to define the RLC ARQ mechanism in Phase 3 requires further investigation.

[0251] Migration between donor IAB nodes

[0252] The IAB node integration process was introduced in version 16 and used for the initial integration of IAB nodes. In other words, the IAB node integration process is still in the service suspension phase.

[0253] Version 17 is designed to specify donor IAB node migration, providing robust operation and applicable to moving IAB nodes. Unlike Version 16, donor IAB node migration in Version 17 is performed during the working phase; therefore, a donor IAB node migration for one IAB node will affect the entire topology and cause service interruption. In other words, for Version 17 donor IAB node migration, it is necessary to study how each IAB node in the IAB topology migrates to another IAB donor, specifically how to provide RRC synchronization reconfiguration (i.e., switchover commands) to the affected IAB nodes.

[0254] like Figure 21 As shown, assuming that the child node (IAB node #2) is connected to the source IAB donor via the parent node (IAB node #1), a set of signaling problems may occur.

[0255] Scenario 1: When the parent node is migrated first, the RRC signaling path between the child node and the source donor is released. Therefore, how the child node can be migrated is unknown.

[0256] Scenario 2: When migrating child nodes first, an RRC signaling path from the parent node to the target donor has not yet been established. Therefore, how the child node accesses the target donor (i.e., how to complete the RRC reconfiguration and send it to the target donor) is unknown.

[0257] For case 1, we investigate some enhancements to reuse CHOs using child nodes, i.e., when the parent node is migrated, the child node executes the CHO.

[0258] In case 2, the child node is considered to be waiting to send an RRC reconfiguration to the target donor, for example, until the parent node is migrated.

[0259] In either case, an option might be to first release the child nodes and then perform a re-integration using the version 16 process. However, given the potential for severe service disruption, this is unlikely to be the solution in version 17.

[0260] While RAN3 has been discussing the general process of migration between donor IAB nodes, RAN2 needs to investigate the impact of RAN2 on how to reconfigure multiple IAB nodes in a multi-hop network.

[0261] Recommendation 14: RAN2 needs to investigate how to reconfigure multi-hop IAB nodes for migration between donor IAB nodes.

Claims

1. A communication control method used in a cellular communication system, the communication control method comprising: The second relay node receives configuration information, which includes a first path configuration for configuring the first path and a second path configuration for configuring the second path. The second relay node executes the routing to the first path based on the configuration of the first path; The second relay node receives a failure occurrence notification from the first relay node indicating that a failure has occurred in the backhaul link; In response to receiving the failure notification, the second relay node determines that the first path is unusable and performs routing to the second path based on the second path configuration; The second relay node receives a recovery notification from the first relay node indicating recovery from the failure; as well as After routing to the second path, in response to receiving the recovery notification, the second relay node determines that the first path can be reused and proceeds with routing to the first path.

2. A second relay node, comprising: A receiver is configured to receive configuration information, the configuration information including a first path configuration for configuring a first path and a second path configuration for configuring a second path; as well as The controller is configured to execute routing to the first path based on the first path configuration, wherein, The receiver is configured to receive a failure occurrence notification from the first relay node indicating that a failure has occurred in the backhaul link. The controller is configured to, in response to receiving the failure notification, consider the first path unusable and perform routing to the second path based on the second path configuration. The receiver is configured to receive from the first relay node a recovery notification indicating recovery from the failure, and The controller is configured to, after routing to the second path, in response to receiving the recovery notification, consider the first path to be usable again and proceed with routing to the first path.

3. A processor for controlling a second relay node, the processor being configured to perform the following processes: Receive configuration information, the configuration information including a first path configuration for configuring a first path and a second path configuration for configuring a second path; The routing to the first path is executed based on the configuration of the first path; Receive a failure notification from the first relay node indicating that a failure has occurred in the backhaul link; In response to receiving the failure notification, it is determined that the first path is unusable, and routing to the second path is performed based on the second path configuration; Receive a recovery notification from the first relay node indicating recovery from the failure; as well as After routing to the second path, in response to receiving the recovery notification, it is determined that the first path can be reused, and routing to the first path is then performed.

Images