Communication control method, relay node, mobile communication system, program and chipset

Abstract

The present invention provides a communication control method, a relay node, a mobile communication system, a program, and a chipset. [Solution] A communication control method used in a cellular communication system includes: a relay node 300-T, which is configured with a dual connection method for the first parent node 300-P1 and the second parent node 300-P2, detecting the occurrence of a radio link failure (RLF) in the backhaul link (BH link) #1 between the first parent node and the second parent node; and, if the relay node is unable to reroute the uplink, sending a notification regarding the detection of the failure to its child nodes.

Description

Technical Field

[0001] The present invention relates to a communication control method, a relay node, a mobile communication system, a program, and a chipset.

Background Art

[0002] In 3GPP (Third Generation Partnership Project), which is a standardization project for cellular communication systems, 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 interposed in the communication between the base station and the user equipment and perform relaying for this communication.

Summary of the Invention

[0003] A communication control method according to a first aspect is a communication control method used in a cellular communication system. The communication control method includes: a relay node in which a dual connection method is set for a first parent node and a second parent node detecting the occurrence of a failure in a backhaul link between the relay node and one of the parent nodes of the first parent node and the second parent node; and when the relay node is not capable of routing in the uplink, the relay node transmitting a notification regarding the detection of the failure to a child node of the relay node.

[0004] The second aspect of the communication control method is a communication control method used in a cellular communication system. The communication control method includes the step of a relay node setting up a dual connection scheme with a first parent node managing a master cell group as the master node and a second parent node managing a secondary cell group as the secondary node. The communication control method also includes the step of the relay node not sending a first notification indicating that it is attempting to recover from a first failure if a first failure occurs in the first backhaul link between the relay node and the first parent node. The first parent node is an LTE (Long Term Evolution) node providing E-UTRA (Evolved Universal Terrestrial Radio Access) service, and the second parent node is an NR (New Radio) node providing NR service.

[0005] The third aspect of the communication control method is a communication control method used in a cellular communication system. The communication control method includes a relay node detecting the occurrence of a failure in the backhaul link between the relay node and its parent node. The communication control method also includes the relay node sending a notification to its child nodes indicating that it is attempting to recover from the failure, and sending additional information related to the notification.

[0006] The fourth aspect of the communication control method is a communication control method used in a cellular communication system. The communication control method includes a relay node receiving a notification from its parent node indicating that a failure has occurred in the backhaul link. The communication control method also includes the relay node transmitting the notification to its child nodes in predetermined cases. [Brief explanation of the drawing]

[0007] [Figure 1] Figure 1 shows an example configuration of a cellular communication system according to one embodiment. [Figure 2]Figure 2 shows the relationship between IAB nodes, parent nodes, and child nodes. [Figure 3] Figure 3 shows an example configuration of a gNB (base station) according to one embodiment. [Figure 4] Figure 4 shows an example configuration of an IAB node (relay node) according to one embodiment. [Figure 5] Figure 5 shows an example configuration of a UE (User Equipment) according to one embodiment. [Figure 6] Figure 6 shows an example of a protocol stack for IAB-MT RRC and NAS connections. [Figure 7] Figure 7 shows an example of a protocol stack for the F1-U protocol. [Figure 8] Figure 8 shows an example of a protocol stack for the F1-C protocol. [Figure 9] Figure 9 shows an example configuration of a cellular communication system according to the first embodiment. [Figure 10(A)] Figure 10(A) is a diagram showing an example of the relationships of the IAB node 300 according to the first embodiment. [Figure 10(B)] Figure 10(B) is a diagram showing an example of the relationships of the IAB node 300 according to the first embodiment. [Figure 11] Figure 11 is a diagram illustrating an example of operation according to the first embodiment. [Figure 12(A)] Figure 12(A) is a diagram showing an example of EN-DC settings according to the second embodiment. [Figure 12(B)] Figure 12(B) is a diagram showing an example of EN-DC settings according to the second embodiment. [Figure 13] Figure 13 is a diagram illustrating an example of operation according to the second embodiment. [Figure 14] Figure 14 is a diagram illustrating an example of the relationships of the IAB node 300 according to the third embodiment. [Figure 15] Figure 15 is a diagram illustrating an example of operation according to the third embodiment. [Figure 16]Figure 16 is a diagram illustrating an example of the relationship between IAB nodes 300 according to the fourth embodiment. [Figure 17] Figure 17 is a diagram illustrating an example of operation according to the fourth embodiment. [Figure 18] Figure 18 is a diagram illustrating an example of operation according to the fifth embodiment. [Figure 19] Figure 19 shows the upstream packet forwarding related to the appendix. [Figure 20] Figure 20 is a diagram illustrating the operation of local rerouting related to the appendix. [Modes for carrying out the invention]

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

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

[0010] Figure 1 shows an example of the configuration of a cellular communication system 1 according to one embodiment.

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

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

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

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

[0015] Each gNB 200 is a fixed radio communication node that manages one or more cells. A cell is a term used to indicate the smallest unit of a radio communication area. A cell may be used as a term to indicate a function or resource for performing radio communication with the UE 100. One cell belongs to one carrier frequency. In the following, the cell and the base station may be used without distinction.

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

[0017] Each gNB200 may be divided into a Central Unit (CU) and a Distributed Unit (DU). The CU and DU are interconnected via an interface called the F1 interface. The F1 protocol is a communication protocol between the CU and DU, and consists of the F1-C protocol, which is the control plane protocol, and the F1-U protocol, which is the user plane protocol.

[0018] Cellular communication system 1 supports IAB, which enables wireless relay of NR access using NR for backhaul. Donor gNB200-1 (or donor node; hereinafter sometimes referred to as "donor node") is the network-side NR backhaul termination node and is a donor base station with additional functions to support IAB. Backhaul can be multi-hop, via multiple hops (i.e., multiple IAB nodes 300).

[0019] Figure 1 shows an example where IAB node 300-1 is wirelessly connected to donor node 200-1, and IAB node 300-2 is wirelessly connected to IAB node 300-1, with the F1 protocol being transmitted over two backhaul hops.

[0020] The UE100 is a mobile wireless communication device that communicates wirelessly with a cell. The UE100 can be any device that communicates wirelessly with the gNB200 or IAB node 300. For example, the UE100 may be a mobile phone terminal, tablet terminal, notebook PC, sensor or device installed on a sensor, vehicle or device installed on a vehicle, aircraft or device installed on an aircraft. The UE100 connects wirelessly to the IAB node 300 or gNB200 via an access link. Figure 1 shows an example of the UE100 connecting wirelessly to IAB node 300-2. The UE100 communicates indirectly with donor node 200-1 via IAB node 300-2 and IAB node 300-1.

[0021] Figure 2 shows an example of the relationship between IAB node 300, parent nodes, and child nodes.

[0022] As shown in Figure 2, each IAB node 300 has an IAB-DU, which corresponds to the base station function unit, and an IAB-MT (Mobile Termination), which corresponds to the user equipment function unit.

[0023] On the IAB-MT's NR Uu radio interface, adjacent nodes (i.e., higher-level nodes) are called parent nodes. A parent node is the DU of the parent IAB node or donor node 200. The radio link between the IAB-MT and the parent node is called a backhaul link (BH link). Figure 2 shows an example where the parent nodes of IAB node 300 are IAB nodes 300-P1 and 300-P2. The direction toward the parent node is called upstream. From the perspective of UE100, the higher-level node of UE100 may be a parent node.

[0024] Adjacent nodes (i.e., lower-level nodes) on the NR access interface of an IAB-DU are called child nodes. The IAB-DU manages cells, similar to the gNB200. The IAB-DU terminates the NR Uu radio interface to the UE100 and lower-level IAB nodes. The IAB-DU supports the F1 protocol to the CU of donor node 200-1. Figure 2 shows an example where the child nodes of IAB node 300 are IAB nodes 300-C1 to 300-C3, but the child nodes of IAB node 300 may also include the UE100. The direction toward child nodes is called downstream.

[0025] (Base station configuration) Next, the configuration of the gNB200, which is a base station according to the embodiment, will be described. Figure 3 is a diagram showing an example of the configuration of the gNB200. As shown in Figure 3, the gNB200 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 with the IAB node 300. The wireless communication unit 210 includes a receiving unit 211 and a transmitting unit 212. The receiving unit 211 performs various types of reception under the control of the control unit 230. The receiving unit 211 includes an antenna and converts the wireless signal received by the antenna into a baseband signal (received signal) (downconvert) and outputs it to the control unit 230. The transmitting unit 212 performs various types of transmission under the control of the control unit 230. The transmitting unit 212 includes an antenna and converts the baseband signal (transmitted signal) output by the control unit 230 into a wireless signal (upconvert) and transmits it from the antenna.

[0027] The network communication unit 220 performs wired (or wireless) communication with 5GC10 and with other adjacent gNB200s. The network communication unit 220 has a receiving unit 221 and a transmitting unit 222. The receiving unit 221 performs various types of reception under the control of the control unit 230. The receiving unit 221 receives signals from the outside and outputs the received signals to the control unit 230. The transmitting unit 222 performs various types of transmission under the control of the control unit 230. The transmitting unit 222 transmits the transmission signals output by the control unit 230 to the outside.

[0028] The control unit 230 performs various controls in the gNB200. 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 for processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation, demodulation, encoding, decoding, etc., of the baseband signal. The CPU executes programs stored in the memory and performs various processing. The processor performs processing of each layer, which will be described later. In addition, the control unit 230 may perform each processing or operation in the gNB200 in each embodiment.

[0029] (Configuration of relay nodes) Next, the configuration of the IAB node 300, which is a relay node (or relay node device; hereinafter sometimes referred to as "relay node") according to the embodiment, will be described. Figure 4 is a diagram showing an example of the configuration of the IAB node 300. As shown in Figure 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 with the gNB200 (BH link) and wireless communication with the UE100 (access link). 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 includes a receiving unit 311 and a transmitting unit 312. The receiving unit 311 performs various types of reception under the control of the control unit 320. The receiving unit 311 includes an antenna and converts the wireless signal received by the antenna into a baseband signal (received signal) (downconvert) and outputs it to the control unit 320. The transmitting unit 312 performs various types of transmission under the control of the control unit 320. The transmitting unit 312 includes an antenna and converts the baseband signal (transmitted signal) output by the control unit 320 into a wireless signal (upconvert) and transmits it from the antenna.

[0032] The control unit 320 performs various controls on the IAB node 300. The control unit 320 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs executed by the processor and information used for processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in the memory and performs various processes. The processor performs processing for each layer described later. In addition, the control unit 320 may perform various processes or operations on the IAB node 300 in each embodiment.

[0033] (User device configuration) Next, the configuration of the user device UE100 according to the embodiment will be described. Figure 5 is a diagram showing an example of the configuration of UE100. As shown in Figure 5, UE100 has a wireless communication unit 110 and a control unit 120.

[0034] The wireless communication unit 110 performs wireless communication on the access link, i.e., wireless communication with the gNB200 and wireless communication with the IAB node 300. The wireless communication unit 110 may also perform wireless communication on the side link, i.e., wireless communication with other UE100s. The wireless communication unit 110 has a receiving unit 111 and a transmitting unit 112. The receiving unit 111 performs various types of reception under the control of the control unit 120. The receiving unit 111 includes an antenna and converts the wireless signal received by the antenna into a baseband signal (received signal) (downconvert) and outputs it to the control unit 120. The transmitting unit 112 performs various types of transmission under the control of the control unit 120. The transmitting unit 112 includes an antenna and converts the baseband signal (transmitted signal) output by the control unit 120 into a wireless signal (upconvert) and transmits it 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 programs executed by the processor and information used for processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in the memory and performs various processes. The processor performs processing for each layer described later. In addition, the control unit 130 may perform each process in the UE 100 in each of the embodiments shown below.

[0036] (Protocol stack configuration) Next, the configuration of the protocol stack according to the embodiment will be described. Figure 6 shows an example of a protocol stack for IAB-MT RRC connection and NAS connection.

[0037] As shown in Figure 6, the IAB-MT of IAB node 300-2 has a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, a PDCP (Packet Data Convergence Protocol) layer, an RRC (Radio Resource Control) layer, and a NAS (Non-Access Stratum) layer.

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

[0039] 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 IAB-MT on IAB node 300-2 and the MAC layer of IAB-DU on IAB node 300-1 via the transport channel. The MAC layer of IAB-DU includes a scheduler. The scheduler determines the transport format (transport block size, modulation and coding scheme (MCS)) and allocated resource blocks for the up and down links.

[0040] The RLC layer uses the functions of the MAC layer and PHY layer to transmit data to the receiving RLC layer. Data and control information are transmitted between the RLC layer of IAB-MT on IAB node 300-2 and the RLC layer of IAB-DU on 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 IAB-MT on IAB node 300-2 and the PDCP layer on donor node 200 via a wireless bearer.

[0042] The RRC layer controls the logical channel, transport channel, and physical channel in response to the establishment, re-establishment, and release of the radio bearer. RRC signaling for various settings is transmitted between the RRC layer of the IAB-MT on IAB node 300-2 and the RRC layer of donor node 200. If there is an RRC connection with donor node 200, the IAB-MT is in the RRC connected state. If there is no RRC connection with donor node 200, the IAB-MT is in the RRC idle state.

[0043] The NAS layer, located above the RRC layer, handles session management and mobility management, among other things. NAS signaling is transmitted between the NAS layer of IAB-MT on IAB node 300-2 and AMF11.

[0044] Figure 7 shows the protocol stack for the F1-U protocol. Figure 8 shows the protocol stack for the F1-C protocol. Here, an example is shown where donor node 200 is divided into CU and DU.

[0045] As shown in Figure 7, each of the IAB-MT on IAB node 300-2, the IAB-DU on IAB node 300-1, the IAB-MT on IAB node 300-1, and the DU on donor node 200 has a BAP (Backhaul Adaptation Protocol) layer as a layer above the RLC layer. The BAP layer is the layer that performs routing and bearer mapping / demapping. In backhaul, routing across multiple hops is possible because the IP layer is transmitted through the BAP layer.

[0046] In each backhaul link, the BAP layer's PDUs (Protocol Data Units) are transmitted via backhaul RLC channels (BH NR RLC channels). By configuring multiple backhaul RLC channels in each BH link, traffic prioritization and QoS control are possible. The mapping between BAP PDUs and backhaul RLC channels is performed by the BAP layer of each IAB node 300 and the BAP layer of the donor node 200.

[0047] As shown in Figure 8, the protocol stack of the F1-C protocol has an F1AP layer and an SCTP layer instead of the GTP-U layer and UDP layer shown in Figure 7.

[0048] In the following, the processes or operations performed by the IAB-DU and IAB-MT of the IAB may be described simply as "IAB processes or operations." For example, the transmission of a BAP layer message from the IAB-DU of IAB node 300-1 to the IAB-MT of IAB node 300-2 will be described as IAB node 300-1 transmitting the message to IAB node 300-2. Similarly, the processes or operations of the DU or CU of donor node 200 may be described simply as "donor node processes or operations."

[0049] Furthermore, the upstream direction and the uplink (UL) direction may not be distinguished. Additionally, the downstream direction and the downlink (DL) direction may not be distinguished.

[0050] [First Embodiment] Next, the first embodiment will be described.

[0051] First, we will describe the Type2 BH RLF Indication and local rerouting in the first embodiment.

[0052] (Type 2 BH RLF Indication) Figure 9 shows an example configuration of the cellular communication system 1 according to the first embodiment.

[0053] The cellular communication system 1 shown in Figure 9 includes node 500, parent node 300-P1 and parent node 300-P2, and IAB node 300-T.

[0054] Node 500 is the parent node of IAB node 300-P1 and is either donor node 200 or IAB node 300 (parent IAB node). The IAB-MT of IAB node 300-P1 has established backhaul link (BH link) #1 with node 500.

[0055] IAB node 300-T is a child node (or child IAB node) of IAB node 300-P1. IAB-MT of IAB node 300-T has established BH link #2 with IAB node 300-P1.

[0056] Furthermore, IAB-MT on IAB node 300-T has also established BH link #3 with IAB node 300-P2. IAB node 300-P2 is the parent node of IAB node 300-T.

[0057] In this configuration, we assume that the IAB-MT of IAB node 300-P1 detects a radio link failure (BH RLF (Radio Link Failure)) on BH link #1. The IAB-MT of IAB node 300-P1 detects the BH RLF, for example, as follows, and attempts to recover from the BH RLF.

[0058] Firstly, the IAB-MT on IAB node 300-P1 starts timer T310 if it detects an out-of-sync state for N310 consecutive times. After starting timer T310, the IAB-MT on IAB node 300-P1 stops timer T310 if it detects an in-sync state for N311 consecutive times. If timer T310 expires without being stopped, the IAB-MT on IAB node 300-P1 detects an RLF (Radio Link Failure) on BH link #1.

[0059] Secondly, the IAB-MT on IAB node 300-P1 detects the RLF and starts timer T311 (i.e., starts the RRC re-establishment process) to perform cell selection to restore the BH link. The IAB-MT on IAB node 300-P1 selects an appropriate cell through the cell selection process, and if the BH link is restored to the selected cell, it stops timer T311. An appropriate cell is one that meets at least the minimum radio quality standards.

[0060] Thirdly, if the IAB-MT of IAB node 300-P1 fails to recover BH link #1 and timer T311 expires, it transitions to the RRC idle state. In the following, the failure to recover from BH RLF after detecting BH RLF (i.e., timer T311 expiring) may be referred to as a BH link recovery failure.

[0061] Here, when the IAB-DU on IAB node 300-P1 detects a BH RLF, it can notify the IAB-MT on IAB node 300-T of a Type 1 BH RLF Indication (hereinafter sometimes referred to as "Type 1 Indication"). A Type 1 Indication is an example of a fault notification indicating that a BH RLF has been detected.

[0062] Furthermore, when the IAB-DU on IAB node 300-P1 detects a recovery operation from a BH RLF, it can notify the IAB-MT on IAB node 300-T of a Type 2 BH RLF Indication (hereinafter sometimes referred to as "Type 2 Indication"). A Type 2 Indication is an example of a failure notification indicating that an attempt is being made to recover from a BH RLF.

[0063] Furthermore, when IAB-DU on IAB node 300-P1 does not distinguish between Type 1 Indication and Type 2 Indication, it can send a Type 1 / 2 BH RLF Indication (hereinafter sometimes referred to as "Type 1 / 2 Indication") to IAB-MT on IAB node 300-T. A Type 1 / 2 Indication is also an example of a fault notification.

[0064] Note that Type1 Indication may be interpreted as Type2 Indication. Type1 Indication is sent when BH RLF is detected, and Type2 Indication is sent when recovery is attempted. However, the IAB-MT on IAB node 300-P1 immediately performs the BH RLF recovery attempt process after BH RLF detection. Therefore, the two Indications can be considered essentially the same Indication.

[0065] Furthermore, there are also recovery notifications indicating that the BH link has recovered from the BH RLF. These recovery notifications are called Type 3 BH RLF Indications (hereinafter sometimes referred to as "Type 3 Indications"). In addition, there are also failure notifications indicating that the BH link failed to recover from the RLF. These failure notifications are called Type 4 BH RLF Indications (hereinafter sometimes referred to as "Type 4 Indications").

[0066] Figure 9 shows an example where IAB node 300-P1 sends a Type 2 Indication to IAB node 300-T, which is a child node of IAB node 300-P1.

[0067] (Local rerouting) As mentioned above, in a network consisting of multiple IAB nodes 300, BH RLF may occur in the backhaul links between the IAB nodes 300.

[0068] In a multi-hop network where packets are forwarded sequentially by multiple IAB nodes 300, data packets can be forwarded to the destination IAB node 300 (or donor node 200) via an alternative path. This forwarding of data packets using an alternative path is sometimes referred to as local rerouting. Local rerouting is performed by selecting an alternative path, ignoring the routing settings configured by the donor node 200. Alternatively, local rerouting may be performed by selecting an alternative path from a list of alternative path candidates configured by the donor node 200.

[0069] In the example shown in Figure 9, IAB node 300-T is performing local rerouting to parent node 300-P2 on an alternative path.

[0070] (Communication control method according to the first embodiment) Within 3GPP, it has been agreed that Type 2 Indications are generated when BH RLF (hereinafter sometimes referred to as "RLF") is detected.

[0071] However, even if IAB node 300 detects an RLF, it may not need to send a Type 2 Indication. Alternatively, even if IAB node 300 detects an RLF, it may need to delete the generated Type 2 Indication from memory.

[0072] Figure 10(A) is a diagram showing an example of the relationships of the IAB node 300 according to the first embodiment. As shown in Figure 10(A), it is assumed that the IAB node 300 detected an RLF on the BH link with the parent node 500. It is also assumed that the IAB node 300 has a dual connectivity (DC) configuration set up between the parent node 500 and other parent nodes other than the parent node 500.

[0073] In this case, IAB node 300 itself has an alternative path (or forwarding path) to the other parent node. Therefore, IAB node 300 can forward the data packets received from child node 300-C using the alternative path. Consequently, even if IAB node 300 detects an RLF itself, it may not need to send a Type 2 Indication to its child node 300-C.

[0074] On the other hand, child node 300-C, upon receiving a Type2 Indication from IAB node 300, may perform actions such as local rerouting in response to receiving the Type2 Indication from IAB node 300. However, child node 300-C will perform actions such as local rerouting even though an alternative path has been secured by IAB node 300. Therefore, redundant processing may occur on child node 300-C.

[0075] Therefore, in the first embodiment, if local rerouting is possible at the IAB node 300, even if an RLF is detected, a Type 2 Indication is not sent.

[0076] Specifically, firstly, the relay node (e.g., IAB node 300) detects a failure in the backhaul link. Secondly, if the relay node is capable of local rerouting to forward data packets to an alternative path, it does not send a notification (e.g., Type 2 Indication) to its child node (e.g., child node 300-C) indicating that it is attempting to recover from the failure. On the other hand, if the relay node is not capable of local rerouting, it sends the notification to the child node.

[0077] As a result, even if IAB node 300 detects an RLF, it may not send a Type 2 Indication to child node 300-C, thus suppressing redundant processing in child node 300-C.

[0078] (Example of operation of the first embodiment) Next, an example of operation according to the first embodiment will be described. Figure 11 is a diagram showing an example of operation according to the first embodiment.

[0079] As shown in Figure 11, in step S10, the IAB node 300 starts processing.

[0080] In step S11, the IAB node 300 detects the BH RLF. Firstly, as shown in Figure 10(A), the IAB node 300 may detect the RLF on the BH link with its parent node 500 itself. In this case, the RLF detection method described in (Type 2 BH RLF Indication) may be used. Secondly, the IAB node 300 may detect the RLF when it receives a Type 4 Indication from the parent node. Figure 10(B) is a diagram showing an example of the relationship of the IAB node 300 according to the first embodiment. As shown in Figure 10(B), the IAB node 300 may detect the RLF when it receives a Type 4 Indication from the parent node 300-P.

[0081] Returning to Figure 11, in step S12, the IAB node 300 determines whether local rerouting is possible.

[0082] Firstly, whether or not local rerouting is possible may be determined by whether or not a DC is configured in the IAB-MT of IAB node 300. As mentioned above, if a DC is configured in IAB node 300, a different path from the path where the RLF occurred can be used as an alternative path. Whether or not a DC is configured in IAB node 300 may be determined by whether or not configuration information has been received from the parent node, which is the master node. The IAB-MT of IAB node 300 may determine that local rerouting is possible if a DC is configured, and that local rerouting is not possible if a DC is not configured. Alternatively, whether or not local rerouting is possible may be determined by whether or not the secondary cell group has been activated in the IAB-MT of IAB node 300. The IAB-MT of IAB node 300 may determine that local rerouting is possible if the secondary cell group is activated, and that local rerouting is not possible if the secondary cell group is deactivated.

[0083] Secondly, whether or not local rerouting is possible may be determined by (1) whether an alternative route (or alternative path) exists and (2) whether or not the alternative route is selectable. In other words, if an alternative route exists and the alternative route is selectable, the IAB-MT of IAB node 300 will determine that local rerouting is possible. On the other hand, if an alternative route does not exist, or if an alternative route exists but the alternative route is not selectable, the IAB-MT of IAB node 300 will determine that local rerouting is not possible.

[0084] (1) Whether or not an alternative route exists may be determined as follows: The IAB-MT of IAB node 300 may determine whether or not there is another route (another routing ID) that has the same destination BAP address (Destination) as the route (routing ID) targeted for local rerouting. In other words, IAB node 300 determines whether or not an alternative path exists by checking whether or not there is a route that is different from the route targeted for local rerouting but has the same destination. Alternatively, IAB node 300 may determine whether or not an alternative route exists by checking whether or not an alternative route (another routing ID) has been set up by donor node 200 for the route (routing ID) targeted for local rerouting. Note that the routing ID consists of the destination BAP address (Destination) and the path identifier (Path ID).

[0085] (2) Alternatively, whether or not an alternative route is selectable may be determined as follows: The IAB-MT of IAB node 300 may determine whether or not an alternative route candidate is available based on whether or not the egress link associated with the candidate is available. In this case, if the egress link associated with the candidate is available, the IAB-MT of IAB node 300 will determine that the candidate route is selectable as an alternative route. On the other hand, if the egress link is not available, the IAB-MT of IAB node 300 will determine that the candidate route is not selectable as an alternative route.

[0086] Alternatively, whether or not local rerouting is possible can be determined by whether or not all traffic is locally reroutable. For example, if some traffic is not locally reroutable, the IAB-MT on IAB node 300 may determine that local rerouting is not possible.

[0087] If IAB node 300 determines that local rerouting is possible (YES in step S12), it does not send a Type2 Indication in step S13. This is because, if local rerouting is possible at IAB node 300, it can forward data packets transferred from its child nodes to an alternative path without sending a Type2 Indication to the child nodes. In this case, IAB-DU of IAB node 300 may delete the generated Type2 Indication from memory. Alternatively, IAB-DU of IAB node 300 may cancel the transmission of the generated Type2 Indication.

[0088] In step S14, the IAB node 300 completes the series of processes.

[0089] On the other hand, if IAB node 300 determines that local rerouting is not possible (NO in step S12), it sends a Type2 Indication to its child node 300-C in step S15. By sending a Type2 Indication to child node 300-C, IAB-DU of IAB node 300 can also cause child node 300-C to perform local rerouting.

[0090] Then, in step S14, the IAB node 300 terminates the series of processes.

[0091] [Second Embodiment] One type of DC is EN-DC (E-UTRA (Evolved Universal Terrestrial Radio Access)-NR Dual Connectivity). Here, we will explain EN-DC.

[0092] (Regarding EN-DC) In EN-DC, the UE100 is connected to one eNB (evolved Node B) that functions as a master node and one en-gNB that functions as a secondary node. The eNB is an LTE base station that provides E-UTRA services. The en-gNB is an NR base station that provides NR services.

[0093] For example, if EN-DC is configured on IAB node 300, the master node may become the first parent node (eNB) of IAB node 300, and the secondary node may become the second parent node (en-gNB) of IAB node 300.

[0094] Figures 12(A) and 12(B) are diagrams illustrating an example of EN-DC configuration according to the second embodiment. Figures 12(A) and 12(B) show an example where EN-DC is configured on IAB node 300, with IAB node 300-P1 as the master node and IAB node 300-P2 as the secondary node.

[0095] The master node (IAB node 300-P1) manages the master cell group (MCG). The MCG is a cell group of serving cells associated with the master node (IAB node 300-P1). On the other hand, the secondary node (IAB node 300-P2) manages the secondary cell group (SCG). The SCG is a cell group of serving cells associated with the secondary node (IAB node 300-P2).

[0096] In EN-DC, the MCG handles control-related processing, while the SCG handles data-related processing. Therefore, as shown in Figure 12(A), even if an RLF occurs in the backhaul between the IAB node 300 and the master node (IAB node 300-P1) that manages the MCG, it has little impact on the data path or routing.

[0097] On the other hand, as shown in Figure 12(B), if an RLF occurs in the backhaul between IAB node 300 and the secondary node (IAB node 300-P2) that manages the SCG, the SCG processes data, so this directly leads to the loss of the data path and the inability to route.

[0098] (Communication control method according to the second embodiment) In 3GPP, it was agreed that an IAB node 300 with dual parent nodes (via a DC) may trigger local rerouting to the other parent node if it receives a Type 2 Indication from one parent node.

[0099] However, as mentioned above, when EN-DC is set, the impact on data relay varies greatly depending on which backhaul the RLF occurred in. Therefore, even with regard to the transmission of Type 2 Indications, IAB node 300 may not need to transmit a Type 2 Indication just because an RLF has occurred.

[0100] In other words, for the IAB node 300, even if an RLF occurs on the MCG side, an alternative path is secured on the SCG side, making it possible to forward data packets transferred from the child node using the alternative path. In such cases, even if the IAB node 300 sends a Type 2 Indication to the child node, the child node may perform processing such as local rerouting, even though an alternative path is secured on the IAB node 300. Such processing by the child node may be redundant, similar to the first embodiment.

[0101] Therefore, in the second embodiment, the IAB node 300, which is configured with EN-DC, does not send a Type 2 Indication even if an RLF occurs in the backhaul with the first parent node that manages the MCG. On the other hand, if an RLF occurs in the backhaul with the second parent node that manages the SCG, the IAB node 300 sends a Type 2 Indication to its child nodes.

[0102] Specifically, firstly, a relay node (e.g., IAB node 300) configures a dual connection scheme with a first parent node (e.g., IAB node 300-P1) managing the master cell group as the master node, and a second parent node (e.g., IAB node 300-P2) managing the secondary cell group as the secondary node. Secondly, if a first failure occurs in the first backhaul link between the relay node and the first parent node, the relay node does not send a first notification (e.g., Type 2 Indication) indicating that it is attempting to recover from the first failure. Here, the first parent node is an LTE node (or LTE base station) providing E-UTRA services, and the second parent node is an NR node (or NR base station) providing NR services.

[0103] As a result, similar to the first embodiment, the IAB node 300 may not send a Type 2 Indication to the child node, thereby suppressing redundant processing for the child node.

[0104] (Example of operation according to the second embodiment) Figure 13 is a diagram illustrating an example of operation according to the second embodiment.

[0105] As shown in Figure 13, in step S20, the IAB node 300 starts processing.

[0106] In step S21, the EN-DC is configured on the IAB node 300. For example, the EN-DC is configured on the IAB node 300 when it receives an RRCConnectionReconfiguration message containing configuration information about the EN-DC from the master node, IAB node 300-P1.

[0107] In step S22, IAB node 300 detects a BH RLF. The IAB-MT of IAB node 300 may also detect an RLF in the BH link between IAB node 300 and the master node IAB node 300-P1. Alternatively, the IAB-MT of IAB node 300 may also detect an RLF in the BH link between IAB node 300 and the secondary node IAB node 300-P2. The detection of the RLF itself may be the same as in step S11 of the first embodiment.

[0108] In step S23, IAB node 300 determines whether the RLF occurred at MCG or SCG. For example, if IAB-MT of IAB node 300 detects an RLF in the BH link between IAB node 300 and IAB node 300-P1, it determines that the RLF occurred at MCG. Alternatively, if IAB-MT of IAB node 300 detects an RLF in the BH link between IAB node 300 and IAB node 300-P2, it determines that the RLF occurred at SCG.

[0109] If IAB node 300 determines that an RLF occurred at MCG (indicated as "MCG" in step S23), it does not send a Type 2 Indication in step S24. This is because even if an RLF occurs at MCG, if a path to the secondary node IAB node 300-P2 is secured, data packets received from child nodes can be forwarded to that path. In this case, IAB node 300 may delete the generated Type 2 Indication from memory. Alternatively, IAB node 300 may cancel the transmission of the generated Type 2 Indication.

[0110] Then, in step S25, the IAB node 300 terminates the series of processes.

[0111] On the other hand, if an RLF occurs at SCG (in step S23, "SCG"), IAB node 300 sends a Type 2 Indication to its child nodes in step S26. Since IAB node 300 does not have a path secured for forwarding data packets, the IAB-DU of IAB node 300 sends a Type 2 Indication to its child nodes, which allows the child nodes to perform local rerouting.

[0112] Then, in step S25, the IAB node 300 terminates the series of processes.

[0113] [Third Embodiment] Next, a third embodiment will be described.

[0114] When IAB node 300 sends a Type 2 Indication to child node 300-C, child node 300-C may perform various controls upon receiving the Type 2 Indication. For example, IAB node 300-C, which has two parent nodes, may perform local rerouting upon receiving a Type 2 Indication; this is one example of such control.

[0115] Therefore, in the third embodiment, the IAB node 300 sends additional information along with the Type2 Indication to its child node 300-C. Alternatively, the IAB node 300 includes the additional information in the Type2 Indication and sends it to the child node 300-C.

[0116] Specifically, firstly, a relay node (e.g., IAB node 300) detects a failure in the backhaul link between the relay node and its parent node (e.g., IAB node 300-P). Secondly, the relay node sends a notification (e.g., Type 2 Indication) to its child node (e.g., IAB node 300-C) indicating that it is attempting to recover from the failure, and also sends additional information related to the notification.

[0117] This allows, for example, child node 300-C, which receives additional information along with a Type2 Indication, to perform various controls related to the Type2 Indication according to the additional information.

[0118] In the following, the terms "sending additional information along with a Type2 Indication" and "sending a Type2 Indication with additional information included in it" may not be used interchangeably.

[0119] Figure 14 is a diagram showing an example of the relationships of the IAB node 300 according to the third embodiment. In the first and second embodiments, it was explained that the IAB node 300 may not send a Type 2 Indication. In the third embodiment, as shown in Figure 14, the IAB node 300 is described as sending a Type 2 Indication to the child node 300-C of the IAB node 300 when an RLF occurs on the BH link between the IAB node 300 and the parent node 300-P.

[0120] (Example of operation according to the third embodiment) Figure 15 is a diagram illustrating an example of operation according to the third embodiment.

[0121] As shown in Figure 15, in step S30, the IAB node 300 starts processing.

[0122] In step S31, the IAB node 300 detects the RLF in the BH link between the IAB node 300 and the parent node 300-P. The detection method may be the same as in the first embodiment (step S11 in Figure 11).

[0123] In step S32, the IAB node 300 sends a Type 2 Indication along with additional information to the child node 300-C.

[0124] The additional information may also be information related to the Type 2 Indication. For example, the following five types of additional information are available:

[0125] A1: The additional information indicates whether or not the node itself (IAB node 300) is capable of local rerouting.

[0126] A2: The additional information indicates whether or not child node 300-C should perform local rerouting.

[0127] A3: The additional information is information indicating whether MCG or SCG is the RLF, or information indicating whether MCG or SCG is usable.

[0128] A4: Additional information is information indicating available (or unavailable) routing IDs.

[0129] A5: Additional information indicates the quality of available links.

[0130] The following explains A1 through A5 in order.

[0131] (Regarding A1) The additional information may also include information indicating whether or not the IAB node 300 is capable of local rerouting.

[0132] For example, in the example in Figure 14, if child node 300-C receives additional information from IAB node 300, along with a Type 2 Indication, indicating that local rerouting is possible, it can send a data packet to IAB node 300. This is because even if an RLF occurs, child node 300-C can use IAB node 300's alternative path to forward the data packet to the destination node. On the other hand, if child node 300-C receives additional information along with a Type 2 Indication indicating that IAB node 300 is not capable of local rerouting, it may perform local rerouting itself.

[0133] (Regarding A2) The additional information may also indicate whether or not child node 300-C should perform local rerouting.

[0134] For example, since IAB node 300 (the parent node for child node 300-C) cannot perform local rerouting on its own, the additional information may instruct child node 300-C to perform local rerouting. Alternatively, since IAB node 300 is capable of performing local rerouting on its own, the additional information may instruct child node 300-C not to perform local rerouting.

[0135] Child node 300-C, upon receiving additional information indicating that local rerouting should be performed, will perform local rerouting according to the additional information. On the other hand, child node 300-C, upon receiving additional information indicating that local rerouting should not be performed, will not perform local rerouting according to the additional information, even upon receiving a Type 2 Indication. In this case, child node 300-C may send the data packet to IAB node 300.

[0136] (Regarding A3) The additional information may be information indicating whether MCG or SCG is the RLF, or information indicating whether MCG or SCG is usable.

[0137] Specifically, additional information may include details indicating which of the following backhaul links is experiencing a failure: the first backhaul link between the first parent node managing the MCG (e.g., parent node 300-P1) and the relay node (e.g., IAB node 300), and the second backhaul link between the second parent node managing the SCG (e.g., parent node 300-P2) and the relay node. Alternatively, additional information may include details indicating which of the first and second backhaul links is available.

[0138] Child node 300-C, upon receiving additional information indicating whether MCG or SCG is experiencing RLF, may determine that the route to the cell group where the RLF is occurring is unavailable and perform local rerouting for traffic to that route. Alternatively, child node 300-C, upon receiving additional information indicating whether MCG or SCG is available, may select the route to the available cell group as an alternative route.

[0139] Furthermore, IAB node 300 may determine whether an RLF has occurred in either MCG or SCG by determining whether the RLF occurred on the BH link between it and parent node 300-P1 managing MCG, or on the BH link between it and parent node 300-P2 managing SCG.

[0140] In this case, the IAB node 300 may determine that cell groups in which no RLF has occurred are usable cell groups.

[0141] Furthermore, the correspondence between routes to each cell group (MCG or SCG) and routing IDs may be notified in advance by the donor node 200. That is, child node 300-C can identify the cell group where the RLF occurred based on the additional information. Child node 300-C can then identify the routing ID corresponding to the cell group where the RLF occurred based on the notification from donor node 200. Child node 300-C can then target data packets containing that routing ID for local rerouting.

[0142] (Regarding A4) The additional information may include information indicating available (or unavailable) routing IDs.

[0143] IAB node 300 may, for example, have DC configuration set up on its own and possess routable paths, or it may have routable paths pre-configured by donor node 200.

[0144] If IAB node 300 detects an RLF, and there are routable paths other than the path where the RLF occurred, it may send the routing ID of such path to child node 300-C as additional information indicating an available routing ID. On the other hand, if paths other than the path where the RLF occurred are unavailable, IAB node 300 may send the unavailable routing ID to child node 300-C as additional information.

[0145] Child node 300-C, having received additional information indicating an available routing ID along with a Type 2 Indication, may forward the data packet containing that routing ID to IAB node (parent node) 300. This is because IAB node 300 has an alternative path that allows for local rerouting even if an RLF occurs, and can therefore use that alternative path to send the data packet.

[0146] On the other hand, child node 300-C, which receives additional information indicating an unusable routing ID along with the Type 2 Indication, performs local rerouting for data packets containing that routing ID. In this case, even if child node 300-C forwards the data packet to IAB node (parent node) 300, IAB node 300 will perform local rerouting itself because there are no available paths. Thus, the additional information indicating the unusable routing ID can be interpreted as the routing ID that child node 300-C should perform local rerouting for.

[0147] Regarding (A4), instead of a usable or unusable routing ID, a usable or unusable destination BAP address (Destination) may be used as additional information. Alternatively, instead of a usable or unusable routing ID, a usable path ID or an unusable path ID may be used as additional information. Since a routing ID consists of a destination BAP address (Destination) and a path ID, it is possible to use a destination address or path ID as additional information instead of a routing ID.

[0148] (Regarding A5) Additional information may include information indicating the quality of available links.

[0149] For example, let's assume that IAB node 300 performs local rerouting from SCG to MCG. In this case, congestion may occur on the BH link to the MCG after routing. Transferring data packets to a congested BH link will result in delays.

[0150] Therefore, if an RLF occurs on the BH link to the SCG, IAB node 300 sends additional information indicating the quality of the MCG, along with a Type 2 Indication, to child node 300-C.

[0151] This allows, for example, child node 300-C to understand the quality status of alternative path candidates on IAB node (parent node) 300. Child node 300-C can then perform local rerouting on its own according to that quality status. This allows child node 300-C to, for example, avoid forwarding to alternative path candidates, thereby preventing delays caused by congestion.

[0152] Quality may be the throughput, congestion, or latency of available links. Quality may be the throughput, congestion, or latency of available links after an RLF occurs. Alternatively, quality may be the difference (or ratio) between the throughput, congestion, or latency of available links before an RLF occurs and the throughput, congestion, or latency after an RLF occurs.

[0153] Furthermore, child node 300-C, upon receiving additional information indicating the quality of available links, may perform local rerouting or forward data packets to IAB node 300 according to the additional information. For example, child node 300-C may locally reroute some traffic according to its quality and forward data packets to parent nodes other than IAB node 300.

[0154] Returning to Figure 15, in step S33, the IAB node 300 completes the series of processes.

[0155] (Modified version of the third embodiment) Next, a modification of the third embodiment will be described. For example, the following is a modification of the third embodiment: The IAB node 300 can transmit additional information by combining all or part of A1 to A5. For example, the IAB node 300 may transmit information indicating a usable routing ID (A4) along with a Type2 Indication, along with information indicating that local rerouting is possible (A1).

[0156] 3GPP has agreed that Type 2 Indications and Type 3 Indications should be transmitted in BAP Control PDUs. Therefore, additional information may also be transmitted in BAP Control PDUs. In this case, a single BAP Control PDU may contain both the Type 2 Indication and the additional information. Alternatively, the Type 2 Indication and the additional information may be contained in separate BAP Control PDUs. Alternatively, the additional information may be transmitted not by a BAP Control PDU, but by a MAC CE (Control Element), etc.

[0157] [Fourth Embodiment] Next, a fourth embodiment will be described.

[0158] Figure 16 is a diagram illustrating an example of the relationship between IAB nodes 300 according to the fourth embodiment.

[0159] In 3GPP, the propagation of Type 2 Indications is being discussed. Type 2 Indication propagation refers to the process where IAB node 300, having received a Type 2 Indication from its parent node 300-P, transmits (or forwards) the Type 2 Indication to its child node 300-C.

[0160] It is believed that the propagation of Type 2 Indications, along with local rerouting processes, ensures that alternative paths are secured, allowing for faster service recovery across the entire topology.

[0161] However, there are times when the question arises as to whether the propagation of Type 2 Indication should always occur, whether it should only occur for one hop, or whether it is acceptable not to propagate Type 2 Indication at all.

[0162] Therefore, in the fourth embodiment, when the IAB node 300 receives a Type 2 Indication, if local rerouting is not possible, it will propagate the Type 2 Indication.

[0163] Specifically, firstly, a relay node (e.g., IAB node 300) receives a notification (e.g., Type 2 Indication) from its parent node (parent node 300-P) indicating that a failure has occurred on the backhaul link. Secondly, the relay node sends the notification to its child node (e.g., child node 300-C) in predetermined cases. Here, predetermined cases are when the relay node can locally reroute some routes but not others, or when the relay node does not support local rerouting.

[0164] This allows IAB node 300 to propagate a Type 2 Indication when local rerouting is not possible, enabling child node 300-C to perform local rerouting on its own and quickly restore service.

[0165] (Example of operation of the fourth embodiment) Figure 17 is a diagram illustrating an example of operation according to the fourth embodiment.

[0166] As shown in Figure 17, in step S40, the IAB node 300 starts processing.

[0167] In step S41, IAB node 300 receives a Type 2 Indication from parent node 300-P.

[0168] In step S42, the IAB node 300 determines whether local rerouting is possible.

[0169] First, IAB node 300 determines whether local rerouting is possible for all routes except the one where the RLF occurred (first determination). That is, IAB node 300 checks the routing IDs of all routes except the one where the RLF occurred. Then, IAB node 300 determines whether local rerouting is possible for all routes except the one where the RLF occurred. If IAB node 300 determines that local rerouting is possible for all routes (in step S42, "local rerouting is possible for all routes"), the process proceeds to step S43.

[0170] Secondly, during the first determination, IAB node 300 may determine that some routes are locally reroutable, but the remaining routes are not. In this case (where step S42 indicates "local rerouting is possible for some routes"), the process proceeds to step S45.

[0171] Thirdly, IAB node 300 may determine during the first determination that it does not support local rerouting. In this case ("local rerouting is impossible" in step S42), the process proceeds to step S46. IAB node 300 may also determine that local rerouting is impossible for all routes except the route where the RLF occurred, and proceed to step S46.

[0172] In step S43, IAB node 300 does not send a Type 2 Indication to child node 300-C. That is, IAB node 300 does not propagate the Type 2 Indication. This is because an alternative path is available at IAB node 300, and the data packets received from child node 300 can be forwarded using this alternative path.

[0173] Then, in step S44, the IAB node 300 terminates the series of processes.

[0174] Furthermore, in step S45, the IAB node 300 transmits a Type2 Indication. That is, the IAB node 300 propagates the Type2 Indication. Child node 300-C may perform local rerouting in response to receiving the Type2 Indication.

[0175] In step S45, since local rerouting is possible for some routes, the IAB node 300 may, as in the third embodiment, send the routing IDs of locally reroutable routes to the child node 300-C as additional information.

[0176] Furthermore, in step S46, IAB node 300 transmits a Type 2 Indication to child node 300-C. In other words, IAB node 300 propagates the Type 2 Indication. Then, the process proceeds to step S44.

[0177] Thus, in the fourth embodiment, Type 2 Indication propagation occurs at the IAB node 300 when local rerouting is possible for some routes but not for the remaining routes. Furthermore, Type 2 Indication propagation occurs at the IAB node 300 when local rerouting is not supported.

[0178] In the fourth embodiment, the relationship between the parent node 300-P that detected the RLF and the IAB node 300 was described, but it is also applicable to the relationship between the IAB node 300 and the child node 300-C, for example. Furthermore, it is also applicable to the relationship between the child node 300-C and its child nodes (grandchild nodes). In other words, the propagation of Type 2 Indication described in the fourth embodiment is applicable to each IAB node 300 that constitutes the topology.

[0179] [Fifth Embodiment] Next, a fifth embodiment will be described.

[0180] The fifth embodiment is also an embodiment relating to the propagation of Type 2 Indications. For example, suppose an IAB node 300 receives a Type 2 Indication from its parent node 300-P. In this case, the IAB node 300 cannot determine whether the Type 2 Indication was sent by the parent node 300-P because it detected an RLF (and is not propagating) or whether it was sent from the parent node 300-P's further parent node (and is propagating).

[0181] Therefore, in the fifth embodiment, when the IAB node 300 receives a Type2 Indication, if the propagation of the received Type2 Indication is instructed, it transmits the Type2 Indication to the child node 300-C.

[0182] Specifically, if a relay node (for example, IAB node 300) receives a notification from a parent node (for example, parent node 300-P) indicating that a failure has occurred in the backhaul link, along with information instructing it to propagate the notification, it will send the notification to a child node (for example, child node 300-C).

[0183] (Example of operation according to the fifth embodiment) Figure 18 is a diagram illustrating an example of operation according to the fifth embodiment.

[0184] As shown in Figure 18, in step S50, the IAB node 300 starts processing.

[0185] In step S51, if the IAB node 300 sends a Type 2 Indication due to an RLF on its BH link, it performs the first processing. Step S51 is an example of when the IAB node 300 shown in Figure 14 sends a Type 2 Indication to the child node 300-C.

[0186] The first process is one of the following:

[0187] B1: No additional information is provided.

[0188] B2: Provide information indicating that it is caused by your own BH RLF.

[0189] B3: Provides child nodes with information instructing them to perform propagation.

[0190] For example, B3 allows IAB node 300 to instruct child node 300-C to propagate the Type 2 Indication. Also, B2 allows IAB node 300 to notify child node 300-C that the Type 2 Indication was transmitted by RLF detection on its own BH link. This also allows IAB node 300 to notify child node 300-C that child node 300-C is the first IAB node to receive the Type 2 Indication. Furthermore, B1 allows IAB node 300 to delegate subsequent processing to child node 300-C without giving any specific instructions.

[0191] In step S52, if IAB node 300 receives a Type2 Indication from parent node 300-P, it performs a second process. Step S52 is the operation when, for example, in Figure 16, IAB node 300, having received a Type2 Indication from parent node 300-P, sends the Type2 Indication to child node 300-C.

[0192] The second process is one of the following:

[0193] C1: No additional information is provided.

[0194] C2: Adds information indicating that it is caused by the parent node's BH RLF.

[0195] C3: Provides information to child nodes instructing them not to propagate Type 2 Indications.

[0196] For example, C3 allows IAB node 300 to send a Type 2 Indication to child node 300-C, but to instruct it not to propagate the Type 2 Indication to further child nodes (grandchild nodes for IAB node 300). Also, C2 allows IAB node 300 to notify child node 300-C that it will send a Type 2 Indication due to an RLF detected by its parent node 300-P. Furthermore, C1 allows IAB node 300 to delegate subsequent processing to child node 300-C without giving any specific instructions.

[0197] When IAB node 300 performs the second process, it sends a Type 2 Indication to child node 300-C.

[0198] Furthermore, the IAB node 300 may perform the processing in steps S51 and S52 only if one-hop propagation is configured. One-hop propagation may be configured, for example, by the donor node 200 or by OAM (Operations, Administration, and Maintenance).

[0199] In step S53, child node 300-C may or may not send a Type2 Indication to the grandchild node according to the additional information. That is, child node 300-C may or may not propagate the Type2 Indication to the grandchild node according to the additional information.

[0200] Then, in step S54, the child node 300-C terminates the series of processes.

[0201] [Other embodiments] A program may be provided that causes a computer to perform each of the processes that UE100 or gNB200 performs. The program may be recorded on a computer-readable medium. Using a computer-readable medium, it is possible to install the program on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, but may be a recording medium such as a CD-ROM or DVD-ROM.

[0202] Alternatively, the circuits that perform each process carried out by the UE100 or gNB200 may be integrated, and at least a portion of the UE100 or gNB200 may be configured as a semiconductor integrated circuit (chipset, SoC).

[0203] The terms "based on" and "depending on" used in this disclosure do not mean "based solely on" or "depending solely on" unless otherwise specified. The term "based on" means both "based solely on" and "at least partially on." Similarly, the term "depending on" means both "at least partially on" and "at least partially on." Also, "obtain / acquire" may mean obtaining information from stored information, obtaining information from information received from other nodes, or obtaining information by generating it. The terms "include," "comprise," and their variations do not mean to include only the listed items, but may include only the listed items, or may include additional items in addition to the listed items. Also, the term "or" used in this disclosure is not intended to mean exclusive OR. Furthermore, any reference to elements using designations such as "first," "second," etc., used in this disclosure does not limit the quantity or order of those elements in general. These designations may be used herein as a convenient way to distinguish between two or more elements. Therefore, references to the first and second elements do not imply that only two elements may be employed therein, or that the first element must precede the second element in any way. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles shall be plural unless it is clearly indicated otherwise by the context.

[0204] Although one embodiment has been described in detail above with reference to the drawings, the specific configuration is not limited to that described above, and various design changes can be made without departing from the gist of the work. Furthermore, it is possible to combine all or part of each embodiment without contradiction.

[0205] This application claims priority to U.S. Provisional Application No. 63 / 228249 (filed August 2, 2021), the entirety of which is incorporated into the specification of this application.

[0206] (Note) (introduction) In RAN2#114e, eIAB (Enhancements to Integrated Access and Backhaul for NR) reached the following agreements for strengthening topology adaptation:

[0207] One of the priority trends for RAN2 is to support inter-topology routing by rewriting the BAP header based on the BAP routing ID, as in option 4.

[0208] Assume the IAB donor configures an (alternative) outflow link that can be used for local rerouting (at least for the same destination and same routing ID, further consideration is needed).

[0209] Local rerouting based on flow control feedback is permitted based on a specific value of the available buffer size. Further investigation is needed for more details. The current hbh fc is for DL ​​traffic.

[0210] NR DLInformationTransfer and ULInformationTransfer messages can be extended to forward F1-C related packets in CP / UP isolation.

[0211] A new IE called DedicatedInfoF1c can be defined to forward F1-C related packets in NR RRC messages.

[0212] F1-C via RRC and F1-C via BAP should not be supported simultaneously on the same parent link.

[0213] The trigger for generating a Type 2 Indication is RLF detection. Further investigation is needed for both single-connection and dual-connection cases.

[0214] The trigger for transmitting a Type 3 RLF Indication is a normal recovery after a BH RLF. Further investigation is needed for both single-connection and dual-connection cases.

[0215] Type 2 and Type 3 BH RLF Indications are transmitted via the BAP Control PDU.

[0216] Even upon receiving a Type 2 Indication, the IAB node will not initiate RRC re-establishment.

[0217] If an IAB node with two parent nodes via a DC receives a Type 2 BH RLF instruction from one parent node, the IAB node can trigger local rerouting to the other parent node. Further investigation is needed regarding the details of local rerouting and whether the behavior during Type 2 indications can be configured.

[0218] This addendum provides details on Type 2 / 3 BH RLF Indication and local rerouting.

[0219] (Discussion) Type 2 / 3 BH RLF Indication Type 2 Indication in the case of a dual connection scheme RAN2 agreed that "the trigger for generating a Type 2 Indication is RLF detection, and further consideration is needed for both single-connection and dual-connection cases." The agreement is quite straightforward for single-connection with a parent node. However, how the Type 2 Indication is transmitted in the case of dual-connection with two parent nodes should be further discussed.

[0220] In RAN2#113-e, the use cases for Type2 Indication from the perspective of child nodes were agreed upon as follows:

[0221] RAN2 will support Type 2 / 3 RLF Indication (further investigation is needed regarding the impact of the specified operational TS and other details).

[0222] Type 2 RLF Indication may be used to trigger local rerouting.

[0223] Type 2 RLF Indication may be used to trigger the invalidation of IABs supported by SIBs.

[0224] Type 2 Indication may be used to trigger the deactivation or reduction of SR and / or BSR transmissions.

[0225] In the context described above, it can be assumed that a child node receiving a Type 2 Indication will not forward the upstream packet to the IAB node that sent the Type 2 Indication due to a BH RLF at that IAB node. This is consistent with the agreement that "if an IAB node with two parent nodes receives a Type 2 BH RLF Indication from one parent node (via the DC), the IAB node may trigger local rerouting to the other parent node."

[0226] Finding 1: Child nodes may not be expected to forward upstream packets to the IAB node that sent the Type 2 BH RLF Indication.

[0227] If the IAB node in question has a dual connection configuration, Rel-16 may perform local rerouting, so Observation 1 is not always correct.

[0228] Note: Data buffering on the sender side of a BAP entity (e.g., until the RLC-AM entity receives an acknowledgment) depends on the implementation. In the case of BH RLF, the sender of the BAP entity can reroute BAP data PDUs that were not acknowledged at lower layers before the BH RLF to an alternative path.

[0229] Figure 19 shows two cases of upstream packet forwarding from the perspective of a child node.

[0230] Therefore, the question remains whether the IAB node should send a Type 2 Indication if an alternative path exists after the MCG's BH RLF. Note that the IAB node can continue local rerouting during the MCG failure information procedure.

[0231] Finding 2: A child node can forward upstream packets if the parent node (the IAB node in question) is capable of performing local rerouting, i.e., due to a dual connection scheme.

[0232] Another scenario for EN-DC is also worth considering. In EN-DC, the MCG link (i.e., MeNB) is used solely for control plane signaling, and data is always transmitted via the SCG link (i.e., SgNB). In this case, the IAB node needs to send a Type 2 Indication to the child node because it directly affects packet forwarding for the SCG RLF child node. On the other hand, the MCG RLF (LTE link) does not seem to need to trigger a Type 2 Indication because the SCG link is available during the subsequent RRC connection re-establishment procedure.

[0233] Observation 3: In EN-DC, the parent node (the IAB node in question) cannot perform local rerouting via MCG (LTE link), so the parent node needs to notify child nodes of SCG RLF (i.e., NR link) using Type 2 BH RLF Indication.

[0234] Based on the above, in a dual-connected IAB node, if RLF is detected in either the MCG or SCG, the following options are possible.

[0235] - Option 1: The IAB node does not send a Type 2 Indication if there is an alternative path for local rerouting.

[0236] - Option 2: The IAB node sends a Type 2 Indication along with information that there is an alternative path.

[0237] Both options have the same intended outcome: the child node can forward upstream packets to the IAB node. However, they differ depending on what the child node does based on receiving the Type 2 Indication, with option 2 being expected to provide options for better overall topology management, such as the "partial" local rerouting described later. Therefore, RAN2 needs to discuss which option is preferable from the child node's perspective.

[0238] Proposal 1: RAN2 needs to discuss whether to send a Type 2 BH RLF Indication if the IAB node can perform local rerouting after the BH RLF declaration (i.e., option 1), or to send it with additional information such as "alternative path available" (i.e., option 2).

[0239] Controllability of donors adapted to Type 2 The most promising use case for Type 2 Indication is for child nodes to perform local rerouting, as agreed upon in RAN2. RAN2#114-e discussed the combined use of Type 2 and Type 4, as Type 4 Indication allows child nodes to declare BH RLFs, ultimately resulting in local rerouting similar to Rel-16. Some companies pointed out that local rerouting upon Type 2 reception could be configurable by the donor, which makes sense as the donor manages the overall topology objectives and has a grasp of the overall topology's performance.

[0240] Proposal 2: RAN2 needs to agree on whether to perform local rerouting when it receives a Type 2 BH RLF Indication, or whether the donor needs to configure the IAB node.

[0241] Furthermore, donors should be able to configure whether to send a Type 2 Indication when a BH RLF is detected on their IAB node. For example, if the IAB node implements Rel-17 and its child nodes only support Rel-16, i.e., a "mixed" configuration, the donor can turn this off.

[0242] Proposal 3: RAN2 needs to agree that the donor configures the IAB node to send a Type 2 BH RLF Indication when a BH RLF is detected.

[0243] Partial local rerouting using Type 2 Indication If the parent node (the IAB node in question) detects a BH RLF but is still able to perform local rerouting, the child node with dual connectivity actually has two options for action, as shown in Figure 19.

[0244] - Option A: All upstream traffic remains on this parent node, and no local rerouting occurs on the child nodes.

[0245] - Option B: "Partial" local rerouting, which reroutes a portion of the upstream traffic to a different parent node.

[0246] Option A is simple, just the same behavior as when option 1 is selected. However, BH RLF can cause the parent node to lose either the MCG or SCG link, potentially leading to an overload on the parent node.

[0247] Option B is enabled by option 2 above, allowing the load to be distributed across the two parent nodes of the child node. Therefore, option B is expected to improve the overall performance of the topology.

[0248] Finding 4: If the dual-connected IAB node sends a Type 2 BH RLF Indication along with some information (i.e., Option 2 of Proposal 4), the child node may have an option if "partial" local rerouting is performed for better load balancing (i.e., Option B).

[0249] If option B is preferred, there are two more options for how the child node can perform partial local rerouting.

[0250] -Option B1: The child node locally decides which traffic to route to another parent node based on additional information from the Type 2 Indication, such as the congestion status of the parent node (the IAB node in question).

[0251] - Option B2: The donor configures the child node which traffic to route to a different parent. For example, when a Type2 Indication notifies the child node of the parent node's MCG RLF, the donor pre-configures the IAB node with a list routing ID for partial local rerouting.

[0252] Option B1 is a distributed approach using each IAB node, while option B2 is an aggregated approach using donors. Option B1 may be able to track dynamic changes in the load along the route, while option B2 may be a semi-static optimization. Considering that the overall topology objective is managed by the donors, option B2 seems slightly preferable.

[0253] Proposal 4: RAN2 needs to consider whether to perform "partial" local rerouting on child nodes (i.e., option B) if a dual-connected parent node experiences a BH RLF.

[0254] Figure 20 illustrates a pair of behavioral diagrams for a child node without local rerouting and a child node with partial local rerouting.

[0255] Indication for Type 3 single and dual connection cases RAN2 agreed that "the trigger for sending a Type3 RLF Indication is a normal recovery after a BH RLF. Further consideration is needed for both single-connected and double-connected cases." It seems to be a common understanding that the Type3 Indication returns the operation of a child node initiated by the reception of a Type2 Indication. Therefore, the Type3 Indication is only valid if the child node has received a Type2 Indication. Such conditions for a Type3 Indication can be applied to both single-connected and double-connected cases, for example, as in Proposal 1 above, since only the Type2 Indication depends on these cases.

[0256] Proposal 5: In addition to the agreed-upon behavior of successfully recovering a BH RLF, RAN2 should agree that a Type 3 BH RLF Indication will only be sent if a Type 2 BH RLF Indication is sent, and this should be common to both single-connection and dual-connection cases.

[0257] Propagation of Type 2 Indications The propagation of Type 2 indications aims to provide better topology management, such as load balancing and reduced service interruptions.

[0258] Specifically, various proposals have been made by different companies. One option is for the IAB node to forward the Type 2 Indication if it receives it and there is no alternative path. This is largely consistent with the behavior of the IAB node in Option 1 of Proposal 1. In other words, it can also be interpreted that the IAB node does not perform local rerouting, including the partial local rerouting in Proposal 4. Another option is to limit the propagation of Type 2 Indication to one hop, which is expected for stable topology management. Naturally, this depends on how the Type 2 Indication is sent in the case of a dual-connection scheme (i.e., Proposal 1, or whether to consider "partial" local rerouting at child nodes, i.e., Proposal 4). Therefore, further consideration is needed for more details.

[0259] Proposal 6: RAN2 should agree to support the propagation of Type 2 Indications to descendant nodes. Further consideration is needed regarding the specific conditions, such as forwarding only if the IAB node does not perform local rerouting.

[0260] Disabling or reducing SR and BSR using Type 2 Indication RAN2 agreed that "Type 2 Indications can be used as triggers for disabling or reducing SR and / or BSR transmissions," but it has not discussed how to handle this agreement. Since this is likely to be the behavior of IAB-MT, it seems necessary to specify it clearly. Regarding disabling or reducing, "disabling" may be simpler from a specification standpoint. However, this would mean that SRs and BSRs can only be transmitted after receiving a Type 3 Indication, potentially causing scheduling delays. On the other hand, "reducing" might allow scheduling to resume immediately after the BH link is restored, although this could introduce unnecessary interference. Therefore, RAN2 needs to discuss whether to support "disabling," "reducing," or both of these for SRs and / or BSRs. If both are supported, it should be configurable by the IAB donor. Also, if "reducing" is supported, it is unclear how the reduction of SRs and / or BSRs should be handled. Reusing the concept of a prohibit timer is a possibility, but further consideration is needed at this time.

[0261] Proposal 7: RAN2 should agree to stipulate that if a Type 2 BH RLF Indication is received, the IAB-MT will disable or reduce SR and / or BSR transmissions.

[0262] Proposal 8: We need to discuss whether RAN2 supports (i.e., configurable) "deactivation," "reduction," or both of the SR and BSR when it receives a Type 2 BH RLF Indication.

[0263] Local rerouting Alternative path setting by the donor In Rel-16, local rerouting is permitted only when a BH RLF occurs, and it covers BH RLFs on both the BH link in question and the parent node's BH link (i.e., when a Type 4 Indication is received). Also, when multiple routes with the same destination configured by the IAB donor are used, the IAB-MT is left to decide which path to use as the alternative path during local rerouting.

[0264] To send BAP data PDUs, the BAP entity does the following:

[0265] Otherwise, if the BAP address matches the destination field, the BAP path ID is the same as the path field, and there is an entry in the BH routing configuration where the outgoing link corresponding to the next-hop BAP address is available, - Select the leak link corresponding to the next-hop BAP address of the entry. Note 1: If the link is located in BHRLF, the leaked link is not considered usable. Note 2: For each combination of BAP address and BAP path ID, there should be at most one entry in the BH routing configuration. Multiple entries for the same BAP address may exist in the BH routing configuration. - Otherwise, if the BAP address matches the destination field and there is at least one entry in the available BH routing configuration for the outgoing link corresponding to the next-hop BAP address, - From the BH routing configuration, select an entry where the outgoing link corresponding to the next-hop BAP address is available, with the BAP address being the same as the destination field. - Select the leak link corresponding to the next-hop BAP address of the entry selected above.

[0266] On the one hand, regarding the local routing in Rel-17, an agreement has been reached in RAN2#114-e that "assuming that the IAB donor can set an (alternative) outgoing link for local routing (at least the same destination, and the same routing ID requires further consideration)". Considering the agreement in RAN2#112-e that "RAN2 will discuss local routing, including the advantages for centralized routing decision-making and how to address the overall topology goals", from the perspective of alternative path configuration, the IAB-donor needs to have more control over local routing compared to the Rel-16 mechanism. For example, since the IAB donor knows which route will be congested based on factors such as the number of UE bearers aggregated on the BH RLC channel, there may be cases where it wants to let the IAB node select another route as an alternative path during local routing. In this case, the IAB donor can explicitly set a specific alternative path for the IAB node, and the IAB node must follow this setting during local routing. In this case, in the BH routing configuration, a specific alternative path (= for local routing) will be associated with the normal path (= for normal routing). It should be noted that the Rel-16 mechanism is still applicable even if the IAB donor does not set a specific alternative path for the IAB node.

[0267] Proposal 9: RAN2 needs to reach an agreement that the IAB donor can set a specific alternative path related to each normal route for the IAB node for local routing.

[0268] If agreeing to Proposal 9, the IAB node performing local routing may rewrite the BAP header, i.e., Option 4, even for local routing within the topology, similar to the agreed inter-topology routing. This enables showing not only one outgoing link but also the path across the entire topology for the locally routed packets.

[0269] Proposal 10: If Proposal 9 is agreed, RAN2 should also agree that the rewriting of the BAP header is also applicable to in-topology local rerouting, similar to inter-topology routing option 4.

[0270] Local rerouting command by the donor As another aspect of the controllability of the IAB donor, for the coexistence of local rerouting and the overall topology objectives, it should be considered that the IAB donor recognizes local rerouting and can start / stop it at the IAB node. For example, if the IAB donor notices that it cannot achieve the overall topology objectives, the IAB donor can instruct the IAB node to start / stop local rerouting, i.e., load distribution between paths. How to handle the overall topology objectives by local rerouting is entirely up to the implementation of the IAB donor, but the IAB donor may need the information and controllability of the local decisions of the IAB node.

[0271] Proposal 11: RAN2 needs to consider whether the IAB node should notify the IAB donor when starting / stopping local rerouting. Proposal 12: RAN2 needs to discuss whether the IAB donor can instruct the IAB node to start / stop local rerouting for load distribution between paths.

Claims

1. A communication control method, A relay node connected to a parent node and a child node receives a notification from the parent node indicating the occurrence of a failure in the backhaul link, The relay node transmits the notification to the child node when it determines that there are no remaining backhaul links unaffected by the failure indicated by the notification. Communication control method.

2. It is a relay node, A receiving unit connected to a parent node and a child node, which receives notifications from the parent node indicating the occurrence of a failure in the backhaul link, The system includes a transmitting unit that, when it determines that there are no remaining backhaul links unaffected by the failure indicated by the notification, transmits the notification to the child node. Relay node.

3. The system comprises a relay node, a parent node connected to the relay node, and a child node connected to the relay node. The relay node, The process of receiving a notification from the parent node indicating the occurrence of a failure in the backhaul link, If it is determined that there are no remaining backhaul links unaffected by the failure indicated by the notification, the process of sending the notification to the child node is executed. Mobile communication system.

4. The relay node connected to the parent node and child nodes, The process of receiving a notification from the parent node indicating the occurrence of a failure in the backhaul link, If it is determined that there are no remaining backhaul links unaffected by the failure indicated by the notification, the process of sending the notification to the child node is executed. program.

5. A chipset that controls relay nodes, The relay node is connected to a parent node and a child node, and the parent node receives a notification indicating a failure in the backhaul link. If it is determined that there are no remaining backhaul links unaffected by the failure indicated by the notification, the process of sending the notification to the child node is executed. Chipset.

Images