Communication control method, relay node, cellular communication system, program, and chip set

Abstract

To provide a communication control method, relay node, communication system, program, and chipset for controlling the transmission of a notification regarding the detection of a failure to a child node when the relay node detects the occurrence of the failure in a backhaul link.SOLUTION: A communication control method is used in a cellular communication system. The communication control method includes: detecting, by a relay node, an occurrence of a failure in a backhaul link (BH RLF (Radio Link Failure)) between the relay node and one of parent nodes of a first parent node and a second parent node, the relay node being configured with dual connectivity for the first parent node and the second parent node; and transmitting, by the relay node, a notification relating to detection of the failure to a child node of the relay node, when the relay node is not capable of uplink rerouting.SELECTED DRAWING: Figure 9

Description

[Technical field]

[0001] The present invention relates to a communication control method, a relay node, a cellular communication system, a program, and a chip set for use in a cellular communication system. [Background technology]

[0002] In the cellular communication system standardization project 3GPP (Third Generation Partnership Project) (registered trademark, hereinafter the same), the introduction of a new relay node called an IAB (Integrated Access and Backhaul) node is being considered (see, for example, "3GPP TS 38.300 V16.2.0 (2020-07)"). One or more relay nodes are involved in communication between a base station and a user device, and relay this communication. Summary of the Invention

[0003] A communication control method according to a first aspect is a communication control method for use in a cellular communication system, the communication control method including: a relay node in which a dual connectivity scheme is set for a first parent node and a second parent node; detecting an occurrence of a failure in a backhaul link between the first parent node and one of the parent nodes of the second parent node; and, if uplink rerouting is not possible, the relay node transmitting a notification regarding the detection of the failure to a child node of the relay node.

[0004] A communication control method according to a second aspect is a communication control method used in a cellular communication system. The communication control method includes a step of configuring a relay node with a dual connectivity scheme, with a first parent node managing a master cell group as a master node and a second parent node managing a secondary cell group as a secondary node. The communication control method includes the relay node not transmitting a first notification indicating that recovery from the first failure is being attempted, when a first failure occurs in a first backhaul link between the relay node and the first parent node. The first parent node is a Long Term Evolution (LTE) node providing an Evolved Universal Terrestrial Radio Access (E-UTRA) service, and the second parent node is an NR node providing a New Radio (NR) service.

[0005] A communication control method according to a third aspect is a communication control method for use in a cellular communication system. The communication control method includes a relay node detecting an occurrence of a failure in a backhaul link between the relay node and a parent node of the relay node. The communication control method includes the relay node transmitting, to a child node of the relay node, a notification indicating that the relay node is attempting to recover from the failure, and transmitting additional information related to the notification.

[0006] A communication control method according to a fourth aspect is a communication control method for use in a cellular communication system. The communication control method includes a relay node receiving a notification indicating that a failure has occurred in a backhaul link from a parent node of the relay node. The communication control method includes the relay node transmitting the notification to a child node of the relay node in a predetermined case. [Brief description of the drawings]

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

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

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

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

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

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

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

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

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

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

[0017] Each gNB 200 may be divided into a central unit (CU) and a distributed unit (DU). The CU and the DU are connected to each other via an interface called an F1 interface. The F1 protocol is a communication protocol between the CU and the DU, and includes an F1-C protocol, which is a control plane protocol, and an F1-U protocol, which is a user plane protocol.

[0018] The cellular communication system 1 supports IAB, which enables wireless relay of NR access using NR for backhaul. The donor gNB 200-1 (or donor node, hereinafter sometimes referred to as "donor node") is a terminal node of the NR backhaul on the network side, and is a donor base station with additional functions that support IAB. The backhaul can be multi-hopped via multiple hops (i.e., multiple IAB nodes 300).

[0019] FIG. 1 illustrates an example in which IAB node 300-1 wirelessly connects to donor node 200-1, IAB node 300-2 wirelessly connects to IAB node 300-1, and the F1 protocol is transmitted over two backhaul hops.

[0020] The UE 100 is a mobile wireless communication device that performs wireless communication with a cell. The UE 100 may be any device that performs wireless communication with the gNB 200 or the IAB node 300. For example, the UE 100 is a mobile phone terminal, a tablet terminal, a laptop computer, a sensor or a device provided in a sensor, a vehicle or a device provided in a vehicle, or an aircraft or a device provided in an aircraft. The UE 100 wirelessly connects to the IAB node 300 or the gNB 200 via an access link. FIG. 1 shows an example in which the UE 100 is wirelessly connected to the IAB node 300-2. The UE 100 indirectly communicates with the donor node 200-1 via the IAB node 300-2 and the IAB node 300-1.

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

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

[0023] An adjacent node (i.e., an upper node) on the NR Uu radio interface of the IAB-MT is called a parent node. The parent node is a DU of the parent IAB node or the donor node 200. The radio link between the IAB-MT and the parent node is called a backhaul link (BH link). FIG. 2 shows an example in which the parent nodes of the IAB node 300 are IAB nodes 300-P1 and 300-P2. The direction toward the parent node is called upstream. From the perspective of the UE 100, the upper node of the UE 100 may correspond to the parent node.

[0024] Adjacent nodes (i.e., lower nodes) on the NR access interface of the IAB-DU are called child nodes. The IAB-DU manages cells, similar to the gNB 200. The IAB-DU terminates the NR Uu radio interface to the UE 100 and the lower IAB nodes. The IAB-DU supports the F1 protocol to the CU of the donor node 200-1. In FIG. 2, an example is shown in which the child nodes of the IAB node 300 are the IAB nodes 300-C1 to 300-C3, but the child nodes of the IAB node 300 may include the UE 100. The direction toward the child nodes is called downstream.

[0025] (Base station configuration) Next, a configuration of the gNB 200 which is a base station according to the embodiment will be described. Fig. 3 is a diagram showing an example of the configuration of the gNB 200. As shown in Fig. 3, the gNB 200 has a wireless communication unit 210, a network communication unit 220, and a control unit 230.

[0026] The wireless communication unit 210 performs wireless communication with the UE 100 and wireless communication with the IAB node 300. The wireless communication unit 210 has a receiving unit 211 and a transmitting unit 212. The receiving unit 211 performs various receptions under the control of the control unit 230. The receiving unit 211 includes an antenna, and converts (down-converts) a wireless signal received by the antenna into a baseband signal (received signal) and outputs the signal to the control unit 230. The transmitting unit 212 performs various transmissions under the control of the control unit 230. The transmitting unit 212 includes an antenna, and converts (up-converts) a baseband signal (transmitted signal) output by the control unit 230 into a wireless signal and transmits the signal from the antenna.

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

[0028] The control unit 230 performs various controls in the gNB 200. The control unit 230 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processing. The processor performs processing of each layer, which will be described later. In addition, the control unit 230 may perform each processing or each operation in the gNB 200 in each embodiment.

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

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

[0031] The wireless communication unit 310 has a receiving unit 311 and a transmitting unit 312. The receiving unit 311 performs various receptions under the control of the control unit 320. The receiving unit 311 includes an antenna, and converts (down-converts) a wireless signal received by the antenna into a baseband signal (received signal), and outputs the signal to the control unit 320. The transmitting unit 312 performs various transmissions under the control of the control unit 320. The transmitting unit 312 includes an antenna, and converts (up-converts) a baseband signal (transmitted signal) output by the control unit 320 into a wireless signal, and transmits the signal from the antenna.

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

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

[0034] The wireless communication unit 110 performs wireless communication in an access link, that is, wireless communication with the gNB 200 and wireless communication with the IAB node 300. The wireless communication unit 110 may also perform wireless communication in a side link, that is, wireless communication with another UE 100. The wireless communication unit 110 has a receiving unit 111 and a transmitting unit 112. The receiving unit 111 performs various receptions under the control of the control unit 120. The receiving unit 111 includes an antenna, and converts (down-converts) a wireless signal received by the antenna into a baseband signal (received signal) and outputs the signal to the control unit 120. The transmitting unit 112 performs various transmissions under the control of the control unit 120. The transmitting unit 112 includes an antenna, and converts (up-converts) a baseband signal (transmitted signal) output by the control unit 120 into a wireless signal and transmits the signal from the antenna.

[0035] The control unit 120 performs various controls in the UE 100. The control unit 120 includes at least one memory and at least one processor electrically connected to the memory. The memory stores a program executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of a baseband signal. The CPU executes a program stored in the memory to perform various processing. The processor performs processing of each layer, which will be described later. The control unit 130 may perform each processing in the UE 100 in each of the following embodiments.

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

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

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

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

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

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

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

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

[0044] Fig. 7 is a diagram showing a protocol stack for the F1-U protocol. Fig. 8 is a diagram showing a protocol stack for the F1-C protocol. Here, an example is shown in which the donor node 200 is divided into a CU and a DU.

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

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

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

[0049] Also, the upstream direction and the uplink (UL) direction may be used interchangeably, and the downstream direction and the downlink (DL) direction may be used interchangeably.

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

[0051] First, the Type 2 BH RLF Indication and local rerouting in the first embodiment will be described.

[0052] (Type2 BH RLF Indication) FIG. 9 is a diagram showing an example of the configuration of a cellular communication system 1 according to the first embodiment.

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

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

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

[0056] The IAB-MT of the IAB node 300-T also establishes a BH link #3 with the IAB node 300-P2, which is the parent node of the IAB node 300-T.

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

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

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

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

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

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

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

[0064] Note that Type 1 Indication may be read as Type 2 Indication. Type 1 Indication is transmitted when a BH RLF is detected, and Type 2 Indication is transmitted when a recovery attempt is made. However, IAB-MT of IAB node 300-P1 immediately performs a BH RLF recovery attempt process after detecting a BH RLF. Therefore, the two Indications can be considered to be substantially the same Indication.

[0065] There is also a recovery indication indicating that the BH link has recovered from a BH RLF. Such a recovery indication is called a Type 3 BH RLF Indication (hereinafter, may be referred to as a "Type 3 Indication"). There is also a failure indication indicating that the BH link has failed to recover from an RLF. Such a failure indication is called a Type 4 BH RLF Indication (hereinafter, may be referred to as a "Type 4 Indication").

[0066] FIG. 9 illustrates an example in which IAB node 300-P1 transmits a Type 2 Indication to IAB node 300-T, which is a child node of IAB node 300-P1.

[0067] (Local Rerouting) As described above, in a network made up of a plurality of IAB nodes 300, a BH RLF may occur in a backhaul link between the IAB nodes 300.

[0068] In a multi-hop network in which a packet is forwarded in succession by a plurality of IAB nodes 300, a data packet can be forwarded to a destination IAB node 300 (or a donor node 200) via an alternative path. Forwarding a data packet using an alternative path may be referred to as local rerouting. Local rerouting is performed by ignoring the routing settings set by the donor node 200 and selecting an alternative path. Alternatively, local rerouting may be performed by selecting an alternative path from alternative path candidates set by the donor node 200.

[0069] In the example shown in FIG. 9, the IAB node 300-T represents an example in which local rerouting is performed to a parent node 300-P2 on an alternative path.

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

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

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

[0073] In this case, the IAB node 300 itself has an alternative path (or a forwarding path) to another parent node. Therefore, the IAB node 300 can forward the data packet received from the child node 300-C using the alternative path. Therefore, even if the IAB node 300 detects an RLF by itself, there are cases where it is not necessary to transmit a Type 2 Indication to the child node 300-C of the IAB node 300.

[0074] On the other hand, the child node 300-C that has received the Type 2 Indication may perform processing such as local rerouting in response to receiving the Type 2 Indication from the IAB node 300. However, the child node 300-C performs processing such as local rerouting even though an alternative path has been secured by the IAB node 300. Therefore, there is a possibility that redundant processing will be performed in the child node 300-C.

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

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

[0077] As a result, even if IAB node 300 detects an RLF, there are cases in which it does not transmit a Type 2 Indication to child node 300-C, making it possible to suppress redundant processing in child node 300-C.

[0078] (Operation example of the first embodiment) Next, a description will be given of an operation example according to the first embodiment. Fig. 11 is a diagram illustrating an operation example according to the first embodiment.

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

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

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

[0082] First, whether local rerouting is possible may be determined based on whether DC is set in the IAB-MT of the IAB node 300. This is because, as described above, if DC is set in the IAB node 300, a path different from the path where RLF occurs can be used as an alternative path. Whether DC is set in the IAB node 300 may be determined based on whether setting information is received from a parent node that is a master node. The IAB-MT of the IAB node 300 may determine that local rerouting is possible when DC is set, and may determine that local rerouting is not possible when DC is not set. Also, whether local rerouting is possible may be determined based on whether the secondary cell group is activated in the IAB-MT of the IAB node 300. The IAB-MT of the IAB node 300 may determine that local rerouting is possible when the secondary cell group is activated, and may determine that local rerouting is not possible when the secondary cell group is deactivated.

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

[0084] (1) Whether or not an alternative route exists may be determined as follows. That is, the IAB-MT of the IAB node 300 may determine whether or not another route (another routing ID) having the same destination BAP address (Destination) as the destination BAP address (Destination) of the route (routing ID) to be locally rerouted exists. That is, the IAB node 300 determines whether or not an alternative path exists based on the presence or absence of a route that is different from the route to be locally rerouted and has the same destination. Alternatively, the IAB node 300 may determine whether or not an alternative route exists based on whether or not an alternative route (another routing ID) is set by the donor node 200 for the route (routing ID) to be locally rerouted. The routing ID is composed of a destination BAP address (Destination) and a path identifier (Path ID).

[0085] (2) On the other hand, whether an alternative route can be selected may be determined as follows. That is, the IAB-MT of the IAB node 300 may determine whether an egress link (outflow link) linked to a candidate for an alternative route whose existence was confirmed in (1) is available or not. In this case, if the egress link (outflow link) linked to the candidate is available, the IAB-MT of the IAB node 300 determines that the candidate route can be selected as an alternative route. On the other hand, if the egress link is not available, the IAB-MT of the IAB node 300 determines that the candidate route cannot be selected as an alternative route.

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

[0087] When the IAB node 300 determines that local rerouting is possible (YES in step S12), it does not transmit a Type 2 Indication in step S13. This is because, if local rerouting is possible in the IAB node 300, the IAB node 300 can forward a data packet forwarded from a child node of the IAB node 300 to an alternative path without transmitting a Type 2 Indication to the child node of the IAB node 300. In this case, the IAB-DU of the IAB node 300 may delete the generated Type 2 Indication from the memory. Also, the IAB-DU of the IAB node 300 may cancel the transmission of the generated Type 2 Indication.

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

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

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

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

[0092] (About EN-DC) In the EN-DC, the UE 100 is connected to one eNB (evolved Node B) functioning as a master node and one en-gNB functioning as a secondary node. The eNB is an LTE base station providing an E-UTRA service. The en-gNB is an NR base station providing an NR service.

[0093] For example, when an EN-DC is configured in the IAB node 300, the master node can be the first parent node (eNB) of the IAB node 300, and the secondary node can be the second parent node (en-gNB) of the IAB node 300.

[0094] 12(A) and 12(B) are diagrams showing an example of EN-DC setting according to the second embodiment. Fig. 12(A) and Fig. 12(B) show an example in which an EN-DC is set in the IAB node 300, with the master node being the IAB node 300-P1 and the secondary node being the IAB node 300-P2.

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

[0096] In the EN-DC, the MCG performs control-related processing. On the other hand, the SCG performs data-related processing. Therefore, as shown in FIG. 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 rarely affects the data path or routing.

[0097] On the other hand, as shown in FIG. 12(B), if an RLF occurs in the backhaul between the IAB node 300 and the secondary node (IAB node 300-P2) that manages the SCG, the SCG performs data processing, which 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 has been agreed that an IAB node 300 that has dual parent nodes (via DC) may trigger local rerouting to one parent node when it receives a Type 2 Indication from the other parent node.

[0099] However, as described above, when EN-DC is set, the impact on data relay varies greatly depending on which backhaul the RLF occurs in. Therefore, even with regard to transmission of Type 2 Indication, there may be cases where the IAB node 300 does not need to transmit Type 2 Indication even if an RLF occurs.

[0100] That is, even if an RLF occurs on the MCG side, the IAB node 300 can forward the data packet forwarded from the child node using the alternative path because an alternative path is secured on the SCG side. In such a case, even if the IAB node 300 transmits 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 in the IAB node 300. Such processing by the child node may be redundant, as in the first embodiment.

[0101] Therefore, in the second embodiment, the IAB node 300 in which the EN-DC is set does not transmit a Type 2 Indication even if an RLF occurs in a backhaul between the IAB node 300 and a first parent node that manages an MCG. On the other hand, when an RLF occurs in a backhaul between the IAB node 300 and a second parent node that manages an SCG, the IAB node 300 transmits a Type 2 Indication to a child node of the IAB node 300.

[0102] Specifically, first, a relay node (e.g., IAB node 300) is configured with a dual connectivity scheme, with a first parent node (e.g., IAB node 300-P1) managing a master cell group as the master node and a second parent node (e.g., IAB node 300-P2) managing a secondary cell group as the secondary node. Second, when a first failure occurs in a first backhaul link between the relay node and the first parent node, the relay node does not transmit a first notification (e.g., Type 2 Indication) indicating that recovery from the first failure is being attempted. Here, the first parent node is an LTE node (or an LTE base station) providing an E-UTRA service, and the second parent node is an NR node (or an NR base station) providing an NR service.

[0103] As a result, similarly to the first embodiment, the IAB node 300 may not transmit a Type 2 Indication to the child node, making it possible to suppress redundant processing for the child node.

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

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

[0106] In step S21, an EN-DC is configured in the IAB node 300. For example, the IAB node 300 receives an RRC connection reconfiguration message including setting information related to the EN-DC from the IAB node 300-P1, which is the master node, and thereby the EN-DC is configured.

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

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

[0109] When the IAB node 300 determines that an RLF has occurred in the MCG ("MCG" in step S23), it does not transmit a Type 2 Indication in step S24. This is because even if an RLF has occurred in the MCG, if a path to the IAB node 300-P2, which is a secondary node, is secured, the data packet received from the child node can be forwarded to that path. In this case, the IAB node 300 may delete the generated Type 2 Indication from the memory. Also, the IAB node 300 may cancel the transmission of the generated Type 2 Indication.

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

[0111] On the other hand, if an RLF occurs in an SCG ("SCG" in step S23), the IAB node 300 transmits a Type 2 Indication to a child node of the IAB node 300 in step S26. Since a path for forwarding a data packet is not secured in the IAB node 300, the IAB-DU of the IAB node 300 can transmit a Type 2 Indication to the child node, thereby causing the child node to perform local rerouting.

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

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

[0114] When the IAB node 300 transmits a Type 2 Indication to the child node 300-C, the child node 300-C may perform various controls in the future upon receipt of the Type 2 Indication. For example, one example of such controls is that the IAB node 300-C having two parent nodes may perform local rerouting upon receiving a Type 2 Indication.

[0115] Therefore, in the third embodiment, the IAB node 300 transmits the additional information together with the Type 2 Indication to the child node 300-C of the IAB node. Alternatively, the IAB node 300 includes the additional information in the Type 2 Indication and transmits it to the child node 300-C.

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

[0117] This allows, for example, the child node 300-C that receives the additional information together with the Type 2 Indication to perform various controls related to the Type 2 Indication in accordance with the additional information.

[0118] In the following description, there may be no distinction between transmitting additional information together with a Type 2 Indication and transmitting a Type 2 Indication including additional information.

[0119] Fig. 14 is a diagram showing an example of a relationship of an IAB node 300 according to the third embodiment. In the first and second embodiments, it has been described that the IAB node 300 may not transmit a Type 2 Indication. In the third embodiment, as shown in Fig. 14, the IAB node 300 transmits a Type 2 Indication to a child node 300-C of the IAB node 300 when an RLF occurs in a BH link between the IAB node 300 and a parent node 300-P.

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

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

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

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

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

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

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

[0127] A3: The additional information is information indicating which of the MCG and the SCG is the RLF, or the additional information is information indicating which of the MCG and the SCG is available.

[0128] A4: The additional information is information indicating a usable (or unusable) routing ID.

[0129] A5: The additional information is information that indicates the quality of the available links.

[0130] Below, A1 to A5 will be explained in order.

[0131] (About A1) The additional information may be information indicating whether the IAB node 300 itself is capable of local rerouting.

[0132] 14, the child node 300-C that receives additional information indicating that local rerouting is possible together with the Type 2 Indication from the IAB node 300 can transmit a data packet to the IAB node 300. This is because the child node 300-C can forward the data packet to the destination node using an alternative path of the IAB node 300 even if an RLF occurs. On the other hand, when the child node 300-C receives additional information indicating that the IAB node 300 is not capable of local rerouting together with the Type 2 Indication, it may perform local rerouting by itself.

[0133] (About A2) The additional information may be information indicating whether or not the child node 300-C should perform local rerouting.

[0134] For example, since the IAB node 300 (the parent node for the child node 300-C) cannot perform local rerouting by itself, the additional information may instruct the child node 300-C to perform local rerouting. Also, since the IAB node 300 can perform local rerouting by itself, the additional information may instruct the child node 300-C not to perform local rerouting.

[0135] The child node 300-C that has received additional information indicating that local rerouting should be performed performs local rerouting according to the additional information. On the other hand, the child node 300-C that has received additional information indicating that local rerouting should not be performed does not perform local rerouting according to the additional information even if it receives a Type 2 Indication. In this case, the child node 300-C may transmit the data packet to the IAB node 300.

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

[0137] Specifically, the additional information may be information indicating which of a first backhaul link between a first parent node (e.g., parent node 300-P1) that manages the MCG and a relay node (e.g., IAB node 300) and a second backhaul link between a second parent node (e.g., parent node 300-P2) that manages the SCG and a relay node has a failure. Alternatively, the additional information may be information indicating which of the first backhaul link and the second backhaul link is available.

[0138] The child node 300-C that has received the additional information indicating whether the MCG or the SCG is RLF may determine that the route to the cell group in which the RLF occurs is unavailable and may perform local rerouting of traffic to that route. Alternatively, the child node 300-C that has received the additional information indicating whether the MCG or the SCG is available may select the route to the available cell group as an alternative route.

[0139] In addition, the IAB node 300 may determine whether an RLF has occurred in either the MCG or the SCG based on whether the RLF has occurred in the BH link with the parent node 300-P1 that manages the MCG, or the BH link with the parent node 300-P2 that manages the SCG.

[0140] In this case, the IAB node 300 may determine a cell group in which no RLF occurs as a usable cell group.

[0141] The correspondence between the route to each cell group (MCG or SCG) and the routing ID may be notified in advance by the donor node 200. That is, the child node 300-C can confirm the cell group in which RLF has occurred by the additional information. Then, the child node 300-C can confirm the routing ID corresponding to the cell group in which RLF has occurred by the notification from the donor node 200. Then, the child node 300-C can target the data packet including the routing ID for local rerouting.

[0142] (About A4) The additional information may be information indicating an available (or unavailable) routing ID.

[0143] The IAB node 300 may have a DC setting configured therein and may have a routable path, or may have a routable path configured in advance by the donor node 200.

[0144] When the IAB node 300 detects an RLF and has a routable path other than the path where the RLF occurred, the IAB node 300 may transmit the routing ID of the path to the child node 300-C as additional information indicating a usable routing ID. On the other hand, when the IAB node 300 cannot use a path other than the path where the RLF occurred, the IAB node 300 may transmit the path to the child node 300-C as additional information indicating an unusable routing ID.

[0145] The child node 300-C that has received additional information indicating a usable routing ID together with the Type 2 Indication may forward the data packet including the routing ID to the IAB node (parent node) 300. This is because the IAB node 300 has an alternative path that can be locally rerouted even if an RLF occurs, and therefore can transmit the data packet using the alternative path.

[0146] On the other hand, the child node 300-C that has received additional information indicating an unavailable routing ID together with the Type 2 Indication performs local rerouting on the data packet including the routing ID. In this case, even if the child node 300-C forwards the data packet to the IAB node (parent node) 300, there is no available path in the IAB node 300, so the child node 300-C performs local rerouting by itself. In this way, the additional information indicating the unavailable routing ID may be interpreted as a routing ID for which the child node 300-C should perform local rerouting.

[0147] In addition, in (A4), instead of the usable or unusable routing ID, the usable or unusable destination BAP address (Destination) may be used as the additional information. Alternatively, instead of the usable or unusable routing ID, the usable or unusable path ID may be used as the additional information. Since the routing ID is composed of the destination BAP address (Destination) and the path ID, it is possible to use the destination address or the path ID as the target of the additional information instead of the routing ID.

[0148] (About A5) The additional information may be information indicating the quality of the available links.

[0149] For example, assume that the IAB node 300 performs local rerouting from the SCG to the MCG. In this case, congestion may occur in the BH link to the MCG after routing. Even if a data packet is forwarded to the BH link where congestion occurs, a delay occurs.

[0150] Therefore, when an RLF occurs in the BH link to the SCG, the IAB node 300 transmits additional information indicating the quality of the MCG together with a Type 2 Indication to the child node 300-C.

[0151] This allows, for example, the child node 300-C to grasp the quality status of the alternative path candidate in the IAB node (parent node) 300. Then, the child node 300-C can perform local rerouting by itself according to the quality status. This allows, for example, the child node 300-C to refrain from forwarding to the alternative path candidate, and can prevent delays caused by congestion in advance.

[0152] The quality may be the throughput, congestion, or delay of the available link. The quality may be the throughput, congestion, or delay of the available link after the occurrence of RLF. The quality may also be the difference (or ratio) between the throughput, congestion, or delay of the available link before the occurrence of RLF and the throughput, congestion, or delay after the occurrence of RLF.

[0153] In addition, the child node 300-C that has received the additional information indicating the quality of the available link may perform local rerouting or forward the data packet to the IAB node 300 depending on the additional information. For example, the child node 300-C may perform local rerouting of some traffic depending on the quality and forward the data packet to a parent node other than the IAB node 300.

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

[0155] (Modification of the third embodiment) Next, a modified example of the third embodiment will be described. As a modified example of the third embodiment, for example, there is the following. That is, 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 (A4) indicating a usable routing ID together with information (A1) indicating that local rerouting is possible, together with the Type 2 Indication.

[0156] In 3GPP, it has been agreed that Type 2 Indication and Type 3 Indication are transmitted in a BAP Control PDU. Therefore, additional information may also be transmitted in a BAP Control PDU. In this case, Type 2 Indication and additional information may be included in one BAP Control PDU. Alternatively, Type 2 Indication and additional information may each be included in separate BAP Control PDUs. Alternatively, additional information may be transmitted by a MAC CE (Control Element) instead of a BAP Control PDU.

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

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

[0159] In 3GPP, the propagation of a Type 2 Indication is being discussed. The propagation of a Type 2 Indication means that an IAB node 300 that has received a Type 2 Indication from a parent node 300-P transmits (or transfers) the Type 2 Indication to a child node 300-C of the IAB node 300.

[0160] It is said that by propagating a Type 2 Indication, an alternative path can be secured through local rerouting processing, etc., making it possible to more quickly restore services across the entire topology.

[0161] However, there may be a problem as to whether the Type 2 Indication should always be propagated, whether the Type 2 Indication should be propagated only for one hop, or whether the Type 2 Indication should not be propagated at all.

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

[0163] Specifically, first, a relay node (e.g., IAB node 300) receives a notification (e.g., Type 2 Indication) from the parent node (parent node 300-P) of the relay node indicating that a failure has occurred in the backhaul link. Second, the relay node transmits the notification to a child node (e.g., child node 300-C) of the relay node in a predetermined case. Here, the predetermined case is when the relay node is capable of local rerouting for some routes and not capable of local rerouting for other routes. Alternatively, the predetermined case is when the relay node does not support local rerouting.

[0164] As a result, when local rerouting is not possible, the IAB node 300 propagates a Type 2 Indication, which enables the child node 300-C to perform local rerouting by itself, thereby enabling service to be restored quickly.

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

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

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

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

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

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

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

[0172] In step S43, the IAB node 300 does not transmit the Type 2 Indication to the child node 300-C. That is, the IAB node 300 does not propagate the Type 2 Indication. This is because an alternative path can be secured in the IAB node 300, and the data packet received from the child node 300 can be transferred using the alternative path.

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

[0174] In step S45, the IAB node 300 transmits a Type 2 Indication. That is, the IAB node 300 propagates the Type 2 Indication. In response to receiving the Type 2 Indication, the child node 300-C may perform local rerouting.

[0175] In step S45, since local rerouting is possible for some routes, the IAB node 300 may transmit a routing ID for which local rerouting is possible as additional information to the child node 300-C, similarly to the third embodiment.

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

[0177] In this way, in the fourth embodiment, the Type 2 Indication is propagated when local rerouting is possible for some routes but not for the remaining routes in the IAB node 300. Also, when the IAB node 300 does not support local rerouting, the Type 2 Indication is propagated.

[0178] In the fourth embodiment, the relationship between the parent node 300-P that detects the RLF and the IAB node 300 has been 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 node (grandchild node). That is, 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 related to the propagation of a Type 2 Indication. For example, assume that the IAB node 300 receives a Type 2 Indication from its parent node 300-P. In this case, the IAB node 300 cannot confirm whether the Type 2 Indication is a Type 2 Indication transmitted by the parent node 300-P upon detection of an RLF (not propagated) or a Type 2 Indication transmitted from the parent node of the parent node 300-P (propagated).

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

[0182] Specifically, when a relay node (e.g., IAB node 300) receives a notification from a parent node (e.g., parent node 300-P) indicating that a failure has occurred in the backhaul link, together with information instructing the execution of propagation of the notification, the relay node transmits the notification to a child node (e.g., child node 300-C).

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

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

[0185] In step S51, when the IAB node 300 transmits a Type 2 Indication in association with the RLF in its own BH link, the IAB node 300 performs a first process. Step S51 is an example of a case in which the IAB node 300 shown in FIG. 14 transmits a Type 2 Indication to the child node 300-C.

[0186] The first process is any one of the following processes.

[0187] B1: No additional information is added.

[0188] B2: Provide information indicating that the incident is due to your own BH RLF.

[0189] B3: Information instructing the child node to execute propagation is provided.

[0190] For example, B3 enables the IAB node 300 to instruct the child node 300-C to propagate a Type 2 Indication. Also, B2 enables the IAB node 300 to notify the child node 300-C that the Type 2 Indication is a Type 2 Indication transmitted as a result of RLF detection in its own BH link. This enables the IAB node 300 to notify the child node 300-C that the child node 300-C is the IAB node that first received the Type 2 Indication. Furthermore, B1 enables the IAB node 300 to leave subsequent processing to the child node 300-C without giving any particular instruction to the child node 300-C.

[0191] In step S52, when the IAB node 300 receives a Type 2 Indication from the parent node 300-P, the IAB node 300 performs the second process. Step S52 is an operation in which, for example, in FIG. 16, the IAB node 300 that has received a Type 2 Indication from the parent node 300-P transmits the Type 2 Indication to the child node 300-C.

[0192] The second process is any one of the following processes.

[0193] C1: No additional information is added.

[0194] C2: Add information indicating that the BH RLF of the parent node is the cause.

[0195] C3: Information instructing the child node not to propagate Type 2 Indication is provided.

[0196] For example, C3 enables the IAB node 300 to instruct the child node 300-C not to transmit the Type 2 Indication to further child nodes (grandchild nodes for the IAB node 300) but not to propagate the Type 2 Indication to the child nodes. C2 enables the IAB node 300 to notify the child node 300-C that it will transmit a Type 2 Indication due to an RLF detected by its parent node 300-P. C1 enables the IAB node 300 to leave subsequent processing to the child node 300-C without issuing any particular instruction to the child node 300-C.

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

[0198] The IAB node 300 may execute the process of step S51 and the process of step S52 when one hop propagation is set. The one hop propagation may be set by the donor node 200 or by OAM (Operations, Administration, and Maintenance), for example.

[0199] In step S53, the child node 300-C transmits or does not transmit a Type 2 Indication to the grandchild node in accordance with the additional information. That is, the child node 300-C propagates or does not propagate a Type 2 Indication to the grandchild node in accordance with the additional information.

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

[0201] [Other embodiments] A program may be provided that causes a computer to execute each process performed by the UE 100 or the gNB 200. The program may be recorded in a computer-readable medium. Using the computer-readable medium, it is possible to install the program in the computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.

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

[0203] As used in this disclosure, the terms "based on" and "depending on" do not mean "based only on" or "depending only on," unless otherwise specified. The term "based on" means both "based only on" and "based at least in part on." Similarly, the term "depending on" means both "based only on" and "based at least in part on." Additionally, "obtain / acquire" may mean obtaining information from stored information, from information received from other nodes, or by generating information. The terms "include," "comprise," and variations thereof do not mean including only the items listed, but may include only the items listed, or may include additional items in addition to the items listed. Additionally, the term "or" as used in this disclosure is not intended to be an exclusive or. Additionally, any reference to elements using designations such as "first," "second," etc., as used in this disclosure is not intended to generally limit the quantity or order of those elements. These designations may be used herein as a convenient method of distinguishing between two or more elements. Thus, reference to a first and a second element does not imply that only two elements may be employed therein or that the first element must precede the second element in some manner. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles are intended to include the plural unless the context clearly indicates otherwise.

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

[0205] This application claims priority to U.S. Provisional Application No. 63 / 228,249 (filed August 2, 2021), the entire contents of which are incorporated herein by reference.

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

[0207] A preference for RAN2 is to support inter-topology routing by rewriting the BAP header based on option 4, the BAP Routing ID.

[0208] Assume that the IAB donor configures (alternative) outgoing links that can be used for local rerouting (at least for the same destination, same routing ID; further study is needed).

[0209] Local rerouting based on flow control feedback is allowed based on a specific value of available buffer size. Details require further study. Currently hbh fc is for DL ​​traffic.

[0210] The NR DLInformationTransfer and ULInformationTransfer messages can be extended to transport F1-C related packets with CP / UP separation.

[0211] A new IE called DedicatedInfoF1c can be defined to transport 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 the detection of an RLF. Both the single-connection and dual-connection cases require further study.

[0214] The trigger for sending a Type 3 RLF Indication is successful recovery after a BH RLF. Both the single-connection and dual-connection cases require further study.

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

[0216] Even if the IAB node receives a Type 2 Indication, it does not initiate RRC re-establishment.

[0217] When an IAB node with two parent nodes via DC receives a Type 2 BH RLF indication from one of the parent nodes, the IAB node can trigger local rerouting to the other parent node. Further study is required on the details of local rerouting and whether the operation at the time of Type 2 Indication can be configured.

[0218] This appendix explains the details of Type 2 / 3 BH RLF Indication and local rerouting.

[0219] (Discussion) Type2 / 3 BH RLF Indication Type 2 Indication in case of dual connection method RAN2 agreed that "the trigger for generating Type 2 Indication is RLF detection, and both the single connectivity and dual connectivity cases require further study." In the case of a single connectivity with a parent node, the agreement is quite easy. On the other hand, in the case of dual connectivity with two parent nodes, how Type 2 Indication is transmitted should be further discussed.

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

[0221] RAN2 supports Type2 / 3 RLF Indication (the impact of the specified operation TS and details require further study).

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

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

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

[0225] In the above context, it can be considered as expected behavior that a child node receiving a Type 2 Indication will not forward upstream packets to the IAB node that sent the Type 2 Indication due to a BH RLF at the 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 (through DC), the IAB node may trigger a local reroute to the other parent node."

[0226] Observation 1: A child node may not be expected to forward upstream packets to an IAB node that sent a Type 2 BH RLF Indication.

[0227] Observation 1 is not always true because if the IAB node in question has dual connectivity, it may perform local rerouting as a Rel-16 operation.

[0228] NOTE: Data buffering at the transmit side of the BAP entity (e.g., until the RLC-AM entity receives an acknowledgment) is up to the implementation. In the case of a BH RLF, the transmit part of the BAP entity may reroute to an alternative path BAP data PDUs that were not acknowledged by lower layers before the BH RLF.

[0229] FIG. 19 illustrates 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 there is an alternative path even after the BH RLF of the MCG. Note that during the MCG Failure Information procedure, the IAB node can continue with local rerouting.

[0231] Observation 2: A child node can forward an upstream packet if its parent node (the IAB node in question) can perform local rerouting, i.e., for dual connectivity scheme.

[0232] Another scenario for EN-DC is also worth considering: in EN-DC, the MCG link (i.e. MeNB) is only used for control plane signaling, and data is always forwarded via the SCG link (i.e. SgNB). In this case, the IAB node in question needs to send a Type 2 Indication to its child nodes, since the SCG RLF has a direct impact on the child nodes' packet forwarding. On the other hand, the MCG RLF (LTE link) does not seem to need to trigger a Type 2 Indication, since the SCG link is available for the subsequent RRC connection re-establishment procedure.

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

[0234] Therefore, in a dual-connected IAB node, if an RLF is detected in either the MCG or SCG, the following options are available:

[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 with information that an alternative path exists.

[0237] Both options have the same intended outcome, i.e. the child node can forward upstream packets to the IAB node. However, what the child node does based on receiving the Type 2 Indication depends on the outcome, and option 2 is expected to provide options for better topology-wide management, such as "partial" local rerouting, as described below. Therefore, RAN2 needs to discuss which option is preferable from the child node's perspective.

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

[0239] Donor controllability for Type 2 adaptation The most promising use case for Type 2 Indication is for a child node to perform local rerouting, as agreed in RAN2. In RAN2#114-e, the use of Type 2 and Type 4 together was discussed, because in Type 4 Indication, the child node declares a BH RLF, and local rerouting ultimately occurs, similar to Rel-16. Some companies pointed out that local rerouting on receipt of Type 2 can be configured by the donor. This makes sense, since the donor controls the intent of the entire topology and knows the latest performance of the entire topology.

[0240] Proposal 2: RAN2 needs to agree with the donor to configure the IAB node whether to perform local rerouting upon receiving a Type 2 BH RLF Indication.

[0241] Additionally, it is necessary for a donor to be able to configure an IAB node whether to send Type 2 Indications when a BH RLF is detected, e.g., if the IAB node implements Rel-17 and its child nodes only support Rel-16, i.e., a "mixed" deployment, the donor can turn this off.

[0242] Proposal 3: RAN2 needs to agree that the donor configures the IAB node whether to send Type 2 BH RLF Indication upon detection of BH RLF.

[0243] Partial local rerouting with Type 2 Indication When a parent node (the IAB node in question) detects a BH RLF but is still able to perform local rerouting, the dual-connected child node 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 is done on the child node.

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

[0246] Option A is simple and is just the behavior of the child node if option 1 above is chosen. However, it may cause an overload of the parent node because the BH RLF causes the parent node to lose either an MCG or SCG link.

[0247] Option B is enabled by option 2 above and allows for load balancing of a child node across its two parent nodes. Therefore, option B is expected to work to improve the performance of the entire topology.

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

[0249] If option B is desired, there are two further 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 in 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 another parent. For example, when a Type 2 Indication informs 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 method by each IAB node, and option B2 is an aggregated method by the donor. Option B1 may be able to follow the dynamic fluctuation of the load on the route, and option B2 may be a semi-static optimization. Considering that the purpose of the entire topology is managed by the donor, option B2 seems to be slightly more desirable.

[0253] Proposal 4: RAN2 needs to discuss whether to perform “partial” local rerouting at the child node (i.e., option B) if the dual-connected parent node experiences a BH RLF.

[0254] FIG. 20 illustrates a pair of diagrams showing the behavior of a child node without local rerouting and with partial local rerouting.

[0255] Indication for Type 3 single and dual connection cases RAN2 agreed that "the trigger for sending a Type 3 RLF indication is a normal recovery after a BH RLF. Both the single-connectivity and dual-connectivity cases require further study." It appears to be a common understanding that a Type 3 indication restores the child node's operation that was initiated by the receipt of a Type 2 indication. Therefore, a Type 3 indication is only valid if the child node receives a Type 2 indication. Such conditions for a Type 3 indication can be commonly applied to both single-connectivity and dual-connectivity, since only a Type 2 indication depends on these cases, as in Proposal 1 above.

[0256] Proposal 5: RAN2 should agree, common to single-connection and dual-connection cases, that a Type 3 BH RLF indication shall be sent only if a Type 2 BH RLF indication has been sent, in addition to the agreed behavior of successful BH RLF recovery.

[0257] Propagation of Type 2 Indication The propagation of Type 2 Indications is intended to provide better topology management, including load balancing and reduced service interruptions.

[0258] Specifically, various proposals have been made by each company. One option is that when an IAB node receives a Type 2 Indication and there is no alternative path, it forwards the Type 2 Indication. This is mainly 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 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, it depends on the method of sending Type 2 Indication in the case of dual connectivity (i.e. Proposal 1, whether to consider "partial" local rerouting at child nodes, i.e. Proposal 4). Therefore, further study is required for details.

[0259] Proposal 6: RAN2 should agree that the propagation of Type 2 Indication to descendant nodes is supported. Further consideration is required for detailed conditions, such as forwarding only when IAB nodes do not perform local rerouting.

[0260] Disabling or reducing SR and BSR due to Type 2 Indication RAN2 agreed that "Type 2 Indication can be used as a trigger for disabling or reducing SR and / or BSR transmissions", but there was no discussion on how to handle this agreement. Since it is considered an IAB-MT operation, it seems necessary to clearly specify it. Regarding deactivation or reduction, "deactivation" may be easier from the perspective of the specification. However, this means that SR and / or BSR can only be transmitted after receiving Type 3 Indication, which may cause scheduling delays. On the other hand, "reduction" may allow scheduling to resume immediately after the BH link is restored, although it may cause unnecessary interference. Therefore, RAN2 needs to discuss whether to support "deactivation", "reduction", or both of SR and / or BSR. If both are supported, it should be configurable by the IAB donor. Also, if "reduction" is supported, it is unclear how to handle the reduction of SR and / or BSR. It is possible to reuse the concept of a prohibition timer, but at this point, further consideration is required.

[0261] Proposal 7: RAN2 should agree to specify that the IAB-MT disables or reduces SR and / or BSR transmissions upon receiving a Type 2 BH RLF Indication.

[0262] Proposal 8: RAN2 needs to discuss whether it will support (i.e., configurable) the “deactivation” and / or “reduction” of SR and / or BSR upon receiving a Type 2 BH RLF Indication.

[0263] Local Rerouting Alternative path setting by donors In Rel-16, local rerouting is permitted only when a BH RLF occurs, and covers both the BH RLF of the BH link and the parent node's BH link (i.e., when Type 4 Indication is received). In addition, the IAB-MT is free to decide which path to use as an alternative path during local rerouting from multiple routes with the same destination set by the IAB donor.

[0264] To transmit a BAP data PDU, the BAP entity does the following:

[0265] Otherwise, if there is an entry in the BH routing configuration whose BAP address matches the destination field, whose BAP path ID is the same as the path field, and whose outflow link corresponding to the next-hop BAP address is available, - Select the outgoing link that corresponds to the entry's next hop BAP address. NOTE 1: If the link is in the BHRLF, the outgoing link is not considered available. NOTE 2: For each combination of BAP address and BAP path ID, there must be at most one entry in the BH routing configuration. There may be multiple entries for the same BAP address in the BH routing configuration. - Otherwise, if there is at least one entry in the BH routing configuration whose BAP address matches the destination field and whose outflow link corresponding to the next-hop BAP address is available, - Select an entry from the BH routing configuration where the outgoing link corresponding to the next hop BAP address is available, with the BAP address in the destination field. - Select the outgoing link that corresponds to the next hop BAP address of the entry selected above.

[0266] On the other hand, for local rerouting in Rel-17, it has been agreed in RAN2#114-e that "we assume that IAB donors configure (alternative) outflow links that can be used for local rerouting (at least the same destination, same routing ID is further study required)". Considering the agreement in RAN2#112-e that "RAN2 should discuss local rerouting, including its advantages over central routing decision and how it can address the topology-wide goal", IAB-donors should have more control over local rerouting in terms of alternative path configuration compared to Rel-16 mechanism. For example, IAB donors may want IAB nodes to select other routes as alternative paths during local rerouting because they know which routes are congested due to the number of UE bearers aggregated to BH RLC channels, etc. In this case, IAB donors can explicitly configure specific alternative paths in IAB nodes, and IAB nodes must follow that configuration during local rerouting. In this case, a specific alternative route (for local rerouting) is associated with a normal route (for normal routing) in the BH routing configuration. It is important to note that the Rel-16 mechanism is applicable even if the IAB donor does not configure a specific alternative path for the IAB node.

[0267] Proposal 9: RAN2 should agree that IAB donors can configure specific alternative paths relative to each regular route to IAB nodes for local rerouting.

[0268] If proposal 9 is agreed upon, an IAB node performing local rerouting may rewrite the BAP header for intra-topology local rerouting as well as for agreed inter-topology routing, i.e. option 4. This allows a locally rerouted packet to be given a route along the entire topology, not just a single outgoing link.

[0269] Proposal 10: If Proposal 9 is agreed, RAN2 must also agree that BAP header rewriting applies to intra-topology local rerouting as well, similar to inter-topology routing option 4.

[0270] Local rerouting command by donor Another aspect of IAB donor controllability is that for the coexistence of local rerouting with topology-wide objectives, it should be considered that the IAB donor should be aware of local rerouting and be able to start / stop it at the IAB node. For example, if the IAB donor notices that the topology-wide objectives cannot be met, the IAB donor can instruct the IAB node to start / stop local rerouting, i.e. load balancing between routes. How to handle topology-wide objectives with local rerouting is entirely up to the IAB donor implementation, but the IAB donor may require information and controllability of local decisions of the IAB node.

[0271] Proposal 11: RAN2 should consider whether IAB nodes should notify IAB donors when local rerouting starts / stops. Proposal 12: RAN2 needs to discuss whether IAB donors can instruct IAB nodes to start / stop local rerouting for load balancing between routes.

Claims

1. A communication control method, comprising: A relay node in which a dual connectivity scheme is set for a first node and a second node detects an occurrence of a failure in a backhaul link between the relay node and one of the first node and the second node; The relay node transmits a notification regarding the detection of the failure to a child node of the relay node; The notification regarding the detection of the fault is transmitted when an EN-DC is set in the relay node and a fault occurs between the relay node and the second node to which the backhaul link is formed. Communications control method.

2. If an RRC re-establishment procedure has been started, a notification regarding the detection of the failure is sent to a child node of the relay node. The communication control method according to claim 1 .

3. The occurrence of the failure in the backhaul link is due to expiration of a timer that is started after detection of a wireless failure. The communication control method according to claim 1 .

4. The notification indicates that the relay node is attempting to recover from the failure. The communication control method according to claim 1 .

5. and performing local rerouting of upstream traffic when the child node receives the notification from the relay node. The communication control method according to claim 1 .

6. The method further includes transmitting the notification to a child node of the child node when the child node receives the notification from the relay node and a predetermined condition is satisfied. The communication control method according to claim 1 .

7. The predetermined condition is: If the child node is capable of local rerouting for some paths and not for other paths, or The communication control method according to claim 6, wherein the child node does not support local rerouting.

8. the predetermined condition is a case where the relay node transmits, together with a notification regarding the detection of the fault, information instructing the execution of propagation of the notification; The communication control method according to claim 6.

9. When the first node is a Long Term Evolution (LTE) node providing an Evolved Universal Terrestrial Radio Access (E-UTRA) service and the second node is a New Radio (NR) node providing an NR service, if a failure occurs in the backhaul link between the relay node and the first node, the relay node does not transmit a notification regarding detection of the failure. The communication control method according to claim 1 .

10. transmitting a notification regarding the detection of the fault and transmitting additional information related to the notification. The communication control method according to claim 1 .

11. The additional information is Information indicating whether the relay node is locally reroutable; Information indicating whether the child node should perform local rerouting; Information indicating which of a first backhaul link between the first node managing a master cell group and the relay node and a second backhaul link between the second node managing a secondary cell group and the relay node has a failure, or information indicating which of the first backhaul link and the second backhaul link is available; Information indicating a usable routing ID, or information indicating an unusable routing ID, or Information about the quality of available links, The communication control method according to claim 10.

12. A relay node, A dual connectivity method is set for a first node and a second node, and a control unit detects occurrence of a failure in a backhaul link between the first node and one of the second node; a transmission unit that transmits a notification regarding the detection of the fault to a child node, The transmission unit transmits a notification regarding detection of the failure when a failure occurs between the second node to which the EN-DC is set and the backhaul link is formed. Relay node.

13. A relay node, the relay node comprising: A dual connectivity method is set for a first node and a second node, and a process of detecting an occurrence of a failure in a backhaul link between one of the first node and the second node is performed; transmitting a notification regarding the detection of the fault to a child node; The notification regarding the detection of the failure is transmitted when a failure occurs between the second node to which the EN-DC is configured and the backhaul link is formed. Communication systems.

14. At the relay node, A dual connectivity method is set for a first node and a second node, and a process of detecting an occurrence of a failure in a backhaul link between one of the first node and the second node is performed; a process of transmitting a notification regarding the detection of the fault to a child node; The notification regarding the detection of the fault is transmitted when a fault occurs between the second node to which an EN-DC is configured and the backhaul link is formed. program.

15. A chipset for controlling a relay node, A dual connectivity method is set for a first node and a second node, and a process of detecting an occurrence of a failure in a backhaul link between one of the first node and the second node is performed; transmitting a notification regarding the detection of the fault to a child node; The notification regarding the detection of the fault is transmitted when a fault occurs between the second node to which an EN-DC is configured and the backhaul link is formed. Chipset.

Images