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

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 chipset used in a cellular communication system. [Background technology]

[0002] The Third Generation Partnership Project (3GPP) (registered trademark; the same applies hereinafter), a standardization project for cellular communication systems, is considering the introduction of a new relay node called an Integrated Access and Backhaul (IAB) node (see, for example, "3GPP TS 38.300 V16.2.0 (2020-07)"). One or more relay nodes intervene 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 configured with a dual connectivity scheme for a first parent node and a second parent node detecting an occurrence of a failure in a backhaul link between the relay node and one of the parent nodes of the first parent node and the second parent node; and, if uplink rerouting is not possible, the relay node transmitting a notification of 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 the master node and a second parent node managing a secondary cell group as the secondary node. The communication control method also includes, when a first failure occurs in a first backhaul link between the relay node and the first parent node, not transmitting a first notification indicating that recovery from the first failure is being attempted. 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, by the relay node, the occurrence of a failure in a backhaul link between the relay node and a parent node of the relay node. The communication control method also includes the relay node transmitting, to a child node of the relay node, a notification indicating that recovery from the failure is being attempted, 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 from a parent node of the relay node indicating that a failure has occurred in a backhaul link. The communication control method also includes the relay node transmitting the notification to a child node of the relay node in a predetermined case. [Brief explanation 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. [Figure 2]FIG. 2 is a diagram showing the relationship between IAB nodes, parent nodes, and child nodes. [Figure 3] FIG. 3 is a diagram illustrating an example configuration of a gNB (base station) according to an embodiment. [Figure 4] FIG. 4 is a diagram illustrating an example of the configuration of an IAB node (relay node) according to an embodiment. [Figure 5] FIG. 5 is a diagram illustrating an example of the configuration of a UE (user equipment) according to an embodiment. [Figure 6] FIG. 6 is a diagram illustrating 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 illustrating an example of a protocol stack for the F1-U protocol. [Figure 8] FIG. 8 is a diagram illustrating 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 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 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 illustrating upstream packet forwarding according to the appendix. [Figure 20] FIG. 20 is a diagram illustrating the operation of local rerouting according to the appendix. DETAILED DESCRIPTION OF THE INVENTION

[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 a cellular communication system) An example of the configuration 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, future cellular communication systems such as 6G may also be applied to the cellular communication system 1.

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

[0011] 1, the cellular communication system 1 includes a 5G core network (5GC) 10, user equipment (UE) 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 about 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, etc.

[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 also 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, there may be cases where a cell and a base station are used interchangeably.

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

[0017] Each gNB 200 may be divided into a central unit (CU) and distributed units (DU). The CU and DU are connected to each other via an interface called an F1 interface. The F1 protocol is a communication protocol between the CU and 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 the "donor node") is the terminal node of the NR backhaul on the network side and is a donor base station with additional functionality to support IAB. The backhaul can be multi-hop via multiple hops (i.e., multiple IAB nodes 300).

[0019] FIG. 1 illustrates an example in which IAB node 300-1 wirelessly connects with donor node 200-1, IAB node 300-2 wirelessly connects with 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 may be 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 is wirelessly connected 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 the 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 a cell, similar to the gNB 200. The IAB-DU terminates the NR Uu radio interface to the UE 100 and lower IAB nodes. The IAB-DU supports the F1 protocol to the CU of the donor node 200-1. While FIG. 2 shows an example in which the child nodes of the IAB node 300 are IAB nodes 300-C1 to 300-C3, the child nodes of the IAB node 300 may also include the UE 100. The direction toward the child nodes is called downstream.

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

[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 types of reception 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 types of transmission 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 types of reception 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 types of transmission 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 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 processes. The processor performs processing of each layer, which will be described later. Furthermore, in each embodiment, the control unit 230 may perform each process or operation in the gNB 200.

[0029] (Relay node configuration) 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 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 types of reception under the control of the control unit 320. The receiving unit 311 includes an antenna, and converts (down-converts) a radio 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 types of transmission 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 radio 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 programs executed by the processor and information used in 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 processes. The processor performs processing of each layer, which will be described later. In each embodiment, the control unit 320 may also perform each process or operation in the IAB node 300.

[0033] (Configuration of user device) Next, a description will be given of a configuration of a UE 100 which is a user equipment according to the embodiment. 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 radio communication unit 110 performs radio communication in the access link, i.e., radio communication with the gNB 200 and radio communication with the IAB node 300. The radio communication unit 110 may also perform radio communication in the side link, i.e., radio communication with another UE 100. The radio 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 radio 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 radio 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 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. Furthermore, the control unit 130 may perform each processing in the UE 100 in each of the embodiments shown below.

[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 IAB node 300-2 and the PHY layer of the IAB-DU of 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 in IAB node 300-2 and the MAC layer of the IAB-DU in IAB node 300-1 via a transport channel. The MAC layer of the IAB-DU includes a scheduler, which determines the transport format (transport block size, modulation and coding scheme (MCS)) and allocated resource blocks for the uplink and downlink.

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

[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 in response 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 positioned above the RRC layer, performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of the IAB-MT of the IAB node 300-2 and the AMF 11.

[0044] Figure 7 is a diagram showing a protocol stack for the F1-U protocol. Figure 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 Figure 7, the IAB-MT of IAB node 300-2, the IAB-DU of IAB node 300-1, the IAB-MT of IAB node 300-1, and the DU of donor node 200 each have a BAP (Backhaul Adaptation Protocol) 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 via the BAP layer, enabling routing over multiple hops.

[0046] In each backhaul link, PDUs (Protocol Data Units) of the BAP layer are transmitted via a backhaul RLC channel (BH NR RLC channel). Configuring multiple backhaul RLC channels in each BH link enables traffic prioritization and QoS control. 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 operations performed by the IAB-DU and IAB-MT of the IAB may be simply referred to as the processing or operations of the "IAB." For example, the transmission of a BAP layer message from the IAB-DU of IAB node 300-1 to the IAB-MT of IAB node 300-2 will be described as the IAB node 300-1 sending the message to IAB node 300-2. In addition, the processing or operations of the DU or CU of the donor node 200 may be simply referred to as the processing or operations 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, 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 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 this 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] Second, the IAB-MT of the IAB node 300-P1 detects the RLF and starts timer T311 (i.e., starts the RRC re-establishment process) and performs a cell selection process to restore the BH link. The IAB-MT of the IAB node 300-P1 selects a suitable cell through the cell selection process, and stops timer T311 when the BH link is restored for the selected cell. A suitable cell is a cell that meets 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. Hereinafter, the failure to recover from the BH RLF after detecting the BH RLF (i.e., the expiration of the timer T311) may be referred to as a BH link recovery failure.

[0061] Here, when the IAB-DU of IAB node 300-P1 detects a BH RLF, it can notify the IAB-MT of 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 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 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 interpreted 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, the 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 essentially the same indication.

[0065] Furthermore, there is a recovery notification indicating that the BH link has recovered from a BH RLF. Such a recovery notification is called a Type 3 BH RLF Indication (hereinafter, sometimes referred to as a "Type 3 Indication"). Furthermore, there is a failure notification indicating that the BH link has failed to recover from an RLF. Such a failure notification is called a Type 4 BH RLF Indication (hereinafter, sometimes referred to as a "Type 4 Indication").

[0066] FIG. 9 shows an example in which IAB node 300-P1 transmits 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 configured with a plurality of IAB nodes 300, a BH RLF may occur in the backhaul link between the IAB nodes 300.

[0068] In a multi-hop network in which a packet is forwarded successively by multiple 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 is sometimes referred to as local rerouting. Local rerouting is performed by selecting an alternative path, ignoring the routing configuration set by the donor node 200. 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 performs local rerouting to the parent node 300-P2 on the alternative path.

[0070] (Communication control method according to the first embodiment) In 3GPP, it has been agreed that 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, or where the IAB node 300 may delete the generated Type 2 Indication from its memory even if it detects an RLF.

[0072] 10(A) is a diagram showing an example of a relationship between 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 the BH link with the parent node 500. It is also assumed that the IAB node 300 has set dual connectivity (DC) 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 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. This may result in redundant processing being 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 data packets to an alternative path, it does not send a notification (e.g., Type 2 Indication) to its child node (e.g., child node 300-C) indicating that it is attempting to recover from the failure. On the other hand, if the relay node is not capable of local rerouting, it sends the notification to its child node.

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

[0078] (Operation example of the first embodiment) Next, a description will be given of an example of operation according to the first embodiment. Fig. 11 is a diagram showing an example of operation 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 itself 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 RLF detection. Second, the IAB node 300 may detect an RLF when it receives a Type 4 Indication from its parent node. FIG. 10(B) is a diagram showing an example of a relationship between IAB nodes 300 according to the first embodiment. As shown in FIG. 10(B), the IAB node 300 may detect an RLF when it receives a Type 4 Indication from its parent node 300-P.

[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 configured in the IAB-MT of the IAB node 300. This is because, as described above, if DC is configured in the IAB node 300, a path different from the path where RLF occurred can be used as an alternative path. Whether DC is configured in the IAB node 300 may be determined based on whether configuration information is received from a parent node, which is a master node. The IAB-MT of the IAB node 300 may determine that local rerouting is possible if DC is configured, and may determine that local rerouting is not possible if DC is not configured. Furthermore, whether local rerouting is possible may be determined based on whether a 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 if the secondary cell group is activated, and may determine that local rerouting is not possible if the secondary cell group is deactivated.

[0083] Second, whether local rerouting is possible may be determined based on (1) whether an alternative route (or alternative path) exists and (2) whether 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 there is 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 local rerouted. That is, the IAB node 300 determines whether or not there is an alternative path depending on whether or not there is a route that is different from the route to be local rerouted and has the same destination. Alternatively, the IAB node 300 may determine whether or not there is an alternative route depending on whether or not the donor node 200 has set an alternative route (another routing ID) for the route (routing ID) to be local 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 the egress link (outgoing link) associated with the alternative route candidate confirmed in (1) is available. In this case, if the egress link (outgoing link) associated with 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] Whether local rerouting is possible may be determined based on whether all traffic is local reroutable. For example, if some traffic is not local reroutable, the IAB-MT of IAB node 300 may determine that local rerouting is not possible.

[0087] If 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 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 memory. Alternatively, 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), then 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 that provides E-UTRA services. The en-gNB is an NR base station that provides NR services.

[0093] For example, when an EN-DC is set 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. Figures 12(A) and 12(B) show an example in which an EN-DC is set in the IAB node 300, with the IAB node 300-P1 as the master node and the IAB node 300-P2 as the secondary node.

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

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

[0097] On the other hand, as shown in Figure 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 with 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 configured, 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 has been 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 has been 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 the backhaul between the IAB node 300 and the first parent node that manages the MCG. On the other hand, if an RLF occurs in the backhaul between the IAB node 300 and the second parent node that manages the SCG, the IAB node 300 transmits a Type 2 Indication to its child node.

[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) that manages a master cell group as the master node and a second parent node (e.g., IAB node 300-P2) that manages 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 it is attempting to recover from the first failure. Here, the first parent node is an LTE node (or an LTE base station) that provides an E-UTRA service, and the second parent node is an NR node (or an NR base station) that provides an NR service.

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

[0104] (Example of operation 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 RRCConnectionReconfiguration message including configuration information related to the EN-DC from the IAB node 300-P1, which is the master node, thereby configuring the EN-DC.

[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 master node IAB node 300-P1. The IAB-MT of the IAB node 300 may also detect an RLF in the BH link between the IAB node 300 and the secondary node IAB node 300-P2. 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 determines whether the RLF occurred in the MCG or the SCG. For example, if 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 determines that the RLF occurred in the MCG. Also, for example, if 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 determines that the RLF occurred in the SCG.

[0109] If 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, as long as a path to the secondary node IAB node 300-P2 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 memory. Alternatively, 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 data packets is not secured in the IAB node 300, the IAB-DU of the IAB node 300 can cause the child node to perform local rerouting by transmitting a Type 2 Indication to the child node.

[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 IAB node 300 transmits a Type 2 Indication to child node 300-C, child node 300-C may perform various controls in the future based on the receipt of the Type 2 Indication. For example, one example of such control is that IAB node 300-C, which has two parent nodes, may perform local rerouting when it receives 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 the 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) to its child node (e.g., IAB node 300-C) indicating that it is attempting to recover from the failure, along with 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, there may be cases where the terms "transmitting additional information together with Type 2 Indication" and "transmitting Type 2 Indication with additional information included therein" are used interchangeably.

[0119] Fig. 14 is a diagram showing an example of a relationship between IAB nodes 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, it is described that 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 the 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 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 IAB node 300 itself 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 whether the MCG or SCG is an RLF, or the additional information is information indicating whether the MCG or SCG is available.

[0128] A4: The additional information is information indicating a routing ID that can be used (or cannot be used).

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

[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, when a child node 300-C receives additional information indicating that local rerouting is possible together with a Type 2 Indication from an IAB node 300, the child node 300-C can transmit a data packet to the IAB node 300. This is because, even if an RLF occurs, the child node 300-C can forward the data packet to the destination node using an alternative path of the IAB node 300. On the other hand, when the child node 300-C receives additional information indicating that local rerouting is not possible together with a Type 2 Indication, the child node 300-C may perform local rerouting 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 (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] When the child node 300-C receives additional information indicating that local rerouting should be performed, it performs local rerouting in accordance with the additional information. On the other hand, when the child node 300-C receives additional information indicating that local rerouting should not be performed, it does not perform local rerouting in accordance with 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 an 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 whether a failure has occurred in a first backhaul link between a first parent node (e.g., parent node 300-P1) that manages an MCG and a relay node (e.g., IAB node 300) or a second backhaul link between a second parent node (e.g., parent node 300-P2) that manages an SCG and a relay node. Alternatively, the additional information may be information indicating which of the first backhaul link and the second backhaul link is usable.

[0138] Upon receiving the additional information indicating whether the MCG or SCG is RLF, the child node 300-C may determine that the route to the cell group where the RLF is occurring is unavailable and perform local rerouting of traffic to that route. Alternatively, upon receiving the additional information indicating whether the MCG or SCG is available, the child node 300-C 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 that a cell group in which no RLF occurs is an available 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 from the additional information. Then, the child node 300-C can confirm the routing ID corresponding to the cell group in which RLF has occurred from the notification from the donor node 200. Then, the child node 300-C can target data packets including the routing ID for local rerouting.

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

[0143] The IAB node 300 may have a DC setting configured therein and 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 a path other than the path where the RLF occurred is unusable, the IAB node 300 may transmit the unusable routing ID to the child node 300-C as additional information.

[0145] The child node 300-C, which 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, when the child node 300-C receives additional information indicating an unavailable routing ID along with the Type 2 Indication, it 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 at 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] Regarding (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 path ID 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, child node 300-C to grasp the quality status of alternative path candidates at IAB node (parent node) 300. Then, child node 300-C can perform local rerouting by itself depending on the quality status. This allows, for example, child node 300-C to avoid forwarding to alternative path candidates, making it possible to 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 RLF occurs. The quality may also be the difference (or ratio) between the throughput, congestion, or delay of the available link before the RLF occurs and the throughput, congestion, or delay after the RLF occurs.

[0153] Upon receiving the additional information indicating the quality of the available link, the child node 300-C may perform local rerouting or forward the data packet to the IAB node 300 according to the additional information. For example, the child node 300-C may perform local rerouting of some traffic according to 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 (A1) indicating that local rerouting is possible and information (A4) indicating a usable routing ID 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) or the like, 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 IAB nodes 300 according to the fourth embodiment.

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

[0160] By propagating Type 2 Indication, an alternative path is secured through local rerouting processing, etc., which is said to enable faster service restoration across the entire topology.

[0161] However, there may be a problem as to whether Type 2 Indication should always be propagated, whether Type 2 Indication should be propagated only one hop, or whether 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 and 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 but not 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, IAB node 300 propagates Type 2 Indication, which allows child node 300-C to perform local rerouting on its own, 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 is possible for all routes" in step S42), the process proceeds to step S43.

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

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

[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 forwarded 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 the routing ID for which local rerouting is possible as additional information to the child node 300-C, as in 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, the Type 2 Indication is propagated when the IAB node 300 does not support local rerouting.

[0178] In the fourth embodiment, the relationship between the parent node 300-P that detected the RLF and the IAB node 300 was described, but it can also be applied to the relationship between the IAB node 300 and the child node 300-C, for example. It can also be applied to the relationship between the child node 300-C and its child node (grandchild node). In other words, the propagation of Type 2 Indication described in the fourth embodiment can be applied 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 was transmitted by the parent node 300-P upon detecting an RLF (not propagated) or whether the Type 2 Indication was 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, along with information instructing the relay node to propagate 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 an RLF in its own BH link, the IAB node 300 performs a first process. Step S51 is an example in which, for example, the IAB node 300 shown in FIG. 14 transmits a Type 2 Indication to the child node 300-C.

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

[0187] B1: No additional information is added.

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

[0189] B3: Information instructing the child node to perform 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. Furthermore, B2 enables the IAB node 300 to notify the child node 300-C that the Type 2 Indication was transmitted as a result of RLF detection on its own BH link. This also enables the IAB node 300 to notify the child node 300-C that it is the first IAB node to receive the Type 2 Indication. Furthermore, B1 enables the IAB node 300 to leave subsequent processing to the child node 300-C without issuing any particular instructions 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, for example, the operation when the IAB node 300 that has received a Type 2 Indication from the parent node 300-P in FIG. 16 transmits the Type 2 Indication to the child node 300-C.

[0192] The second process is 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: Provide information to the child node instructing it not to propagate Type 2 Indication.

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

[0197] After performing the second process, the IAB node 300 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 on a computer-readable medium. Using the computer-readable medium, the program can be installed on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory 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 (chipset, 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 expressly stated otherwise. 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 "at least in part on." Furthermore, "obtain" may mean obtaining information from stored information, obtaining information from information received from another node, or obtaining information by generating the information. The terms "include," "comprise," and variations thereof do not mean including only the listed items, but may also mean including only the listed items or including additional items in addition to the listed items. Furthermore, as used in this disclosure, the term "or" is not intended to mean an exclusive or. Furthermore, any reference to elements using designations such as "first," "second," etc., as used in this disclosure does not 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 first and second elements 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 shall 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 can be made without departing from the spirit of the invention. Furthermore, it is also possible to combine all or part of each embodiment within a consistent range.

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

[0206] (Addendum) (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 the available buffer size. Further details are required. The current 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 RLF. Both the single-connection and dual-connection cases require further study.

[0214] The trigger for sending a Type 3 RLF Indication is a 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 Indication are transmitted via a 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 needed to determine the details of local rerouting and whether the behavior upon Type 2 Indication can be configured.

[0218] This appendix provides details on Type2 / 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 a Type 2 Indication is RLF detection, and further study is needed for both single connectivity and dual connectivity cases. In the case of a single connectivity with a parent node, agreement is quite easy. On the other hand, in the case of dual connectivity with two parent nodes, how the 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 must support Type2 / 3 RLF Indication (the impact of the specified operating 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 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 that receives 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 that IAB node. This is consistent with the agreement that "if an IAB node with two parent nodes receives a Type 2 BH RLF Indication from one parent node (via DC), the IAB node may trigger local rerouting 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 has dual connectivity, it may perform local rerouting as a Rel-16 behavior.

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

[0229] FIG. 19 is a diagram showing two cases of upstream packet forwarding from the perspective of a child node.

[0230] Therefore, it is questionable whether the IAB node in question 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 in question can continue with local rerouting.

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

[0232] Another scenario for EN-DC is also worth considering. In EN-DC, the MCG link (i.e., MeNB) is used only for control plane signaling, and data is always forwarded via the SCG link (i.e., SgNB). In this case, the IAB node needs to send a Type 2 Indication to the child node, since the SCG RLF directly affects the packet forwarding of the child node. 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, the parent node (the IAB node in question) cannot perform local rerouting via the MCG (LTE link), so the parent node must notify 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: the child node can forward upstream packets to the IAB node. However, what the child node does based on receiving the Type 2 Indication is different, 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, if an IAB node can perform local rerouting after a BH RLF declaration, it should not send Type 2 BH RLF Indication (i.e., Option 1) or send it with additional information such as "alternate path is available" (i.e., Option 2).

[0239] Donor controllability for Type 2 indication The most promising use case for Type 2 Indication is for a child node to perform local rerouting, as agreed upon in RAN2. In RAN2#114-e, the combined use of Type 2 and Type 4 was discussed. With Type 4 Indication, the child node declares a BH RLF, which ultimately results in local rerouting, similar to Rel-16. Some companies pointed out that local rerouting upon receiving Type 2 can be configured by the donor. This makes sense because 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 Type 2 BH RLF Indication.

[0241] Additionally, it is necessary for the donor to be able to configure the IAB node whether to send Type 2 Indication when a BH RLF is detected. For example, 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 should agree that the donor configures the IAB node whether to send Type 2 BH RLF Indication upon detecting BH RLF.

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

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

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

[0246] Option A is simple and corresponds to the behavior of the child node when option 1 above is selected. However, it may cause an overload of the parent node because the parent node loses either an MCG or SCG link due to the BH RLF.

[0247] Option B is enabled by option 2 above, and can distribute the load across the child nodes' 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 in question sends a Type 2 BH RLF Indication with some information (i.e., option 2 in Proposal 4), the child node may have a choice if a "partial" local rerouting is performed for better load balancing (i.e., option B).

[0249] If option B is preferred, 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 notifies the child node of the parent node's MCG RLF, the donor pre-configures the IAB node with a list routing ID for partial local rerouting.

[0252] Option B1 is a distributed method by each IAB node, and option B2 is a centralized method by the donor. Option B1 may be able to follow dynamic fluctuations in 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 slightly more desirable.

[0253] Proposal 4: RAN2 should 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 shows a pair of diagrams illustrating 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 normal recovery after a BH RLF. Further study is needed for both single-connection and dual-connection cases." It appears to be a common understanding that a Type 3 indication reverses the child node's behavior initiated by receiving a Type 2 indication. Therefore, a Type 3 indication is valid only if the child node receives a Type 2 indication. Such conditions for a Type 3 indication, such as those in Proposal 1 above, are applicable to both single-connection and dual-connection cases, since only a Type 2 indication depends on these cases.

[0256] Proposal 5: RAN2 should agree that, in addition to the agreed behavior of successful recovery of the BH RLF, Type 3 BH RLF indication should be sent only if Type 2 BH RLF indication is sent, for both single and dual connectivity cases.

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

[0258] Specifically, various proposals have been made by various companies. One option is for an IAB node to forward a Type 2 Indication if it receives one and there is no alternative path. This is largely consistent with the behavior of the IAB node in Option 1 of Proposal 1. In other words, it can also be interpreted as an IAB node not performing local rerouting, including partial local rerouting in Proposal 4. Another option is to limit the propagation of a Type 2 Indication to one hop, which is expected for stable topology management. Naturally, it depends on the method of transmitting a Type 2 Indication in the case of dual connectivity (i.e., Proposal 1; whether "partial" local rerouting at child nodes is considered, i.e., Proposal 4). Therefore, further study is required for the details.

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

[0260] Disabling or reducing SR and BSR by 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 about how to handle this agreement. Since this is considered an IAB-MT operation, it seems necessary to clearly specify it. Regarding deactivation or reduction, "deactivation" may be easier from a specification perspective. 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 backhaul 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. Furthermore, if "reduction" is supported, it is unclear how to handle SR and / or BSR reduction. Reusing the prohibition timer concept is conceivable, but further consideration is needed at this time.

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

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

[0263] Local Rerouting Alternative path setting by donor 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). Furthermore, 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 send a BAP data PDU, the BAP entity does the following:

[0265] Otherwise, if there is an entry in the BH routing configuration where the BAP address matches the destination field, the BAP path ID is the same as the path field, and the outgoing link corresponding to the next-hop BAP address is available, - Select the outgoing link corresponding 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 outgoing 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 same destination field. - Select the outgoing link that corresponds to the next hop BAP address of the entry selected above.

[0266] On the other hand, regarding local rerouting in Rel-17, RAN2#114-e agreed that "we assume that the IAB donor configures (alternate) outflow links that can be used for local rerouting (at least the same destination and the same routing ID require further study)." Considering the agreement in RAN2#112-e that "RAN2 should discuss local rerouting, including its advantages over centralized route determination and how it can address topology-wide goals," the IAB donor should have more control over local rerouting in terms of alternative path configuration compared to the Rel-16 mechanism. For example, the IAB donor may want the IAB node to select another route as an alternative path during local rerouting because it knows which route is congested based on the number of UE bearers aggregated on the BH RLC channel. In this case, the IAB donor can explicitly configure a specific alternative path in the IAB node, and the IAB node 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. 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, IAB nodes performing local rerouting may rewrite the BAP header, whether for intra-topology local rerouting or agreed-upon inter-topology routing, i.e., option 4. This allows locally rerouted packets to be directed along the entire topology, rather than just one outgoing link.

[0269] Proposal 10: If Proposal 9 is agreed, RAN2 must also agree that BAP header rewriting applies to intra-topology local rerouting, 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 and topology-wide objectives, an IAB donor should be aware of local rerouting and be able to start / stop it at an IAB node. For example, if an IAB donor realizes that it cannot achieve its topology-wide objectives, it can instruct an IAB node to start / stop local rerouting, i.e., load balancing between routes. How to handle topology-wide objectives through local rerouting is entirely up to the IAB donor implementation, but an IAB donor may require information and control over the local decisions of an 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 method is set for a first node that is an LTE (Long Term Evolution) node that manages a master cell group (MCG) and provides an E-UTRA (Evolved Universal Terrestrial Radio Access) service and a second node that is an NR (New Radio) node that provides an NR (New Radio) service detects the occurrence of a failure in a link between the first node and one of the second node; the relay node transmitting a notification regarding the detection of the failure to a child node of the relay node; The relay node transmits a notification regarding detection of a failure when a failure occurs between the relay node and the second node on which a backhaul link is formed, and does not transmit a notification regarding detection of the failure when a failure occurs in a link between the relay node and the first node. Communication control method.

2. If an RRC re-establishment procedure has been initiated, a notification regarding the detection of the failure is sent to the 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 detecting a radio 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 child node does not support local rerouting.

7. The communication control method according to claim 6.

8. The predetermined condition is when the relay node transmits, together with the notification regarding the detection of the failure, information instructing the execution of propagation of the notification.

7. The communication control method according to claim 6.

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

10. 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 usable; Information indicating a usable routing ID, or information indicating an unusable routing ID, or It is information that indicates the quality of the available links. The communication control method according to claim 9.

11. a relay node, A control unit that manages a master cell group (MCG) and configures a dual connectivity method for a first node that is a Long Term Evolution (LTE) node that provides an Evolved Universal Terrestrial Radio Access (E-UTRA) service and a second node that is a New Radio (NR) node that provides an NR (New Radio) service, and detects the occurrence of a failure in a link between the first node and one of the second node; a transmitter that transmits a notification regarding the detection of the failure to a child node, The transmitter transmits a notification regarding the detection of a failure when a failure occurs between the relay node and the first node and the second node over which a backhaul link is formed, and does not transmit a notification regarding the detection of a failure when a failure occurs in a link between the relay node and the first node. Relay node.

12. a relay node, the relay node comprising: A dual connectivity method is configured for a first node that is a Long Term Evolution (LTE) node that manages a master cell group (MCG) and provides an Evolved Universal Terrestrial Radio Access (E-UTRA) service, and a second node that is a New Radio (NR) node that provides an NR (New Radio) service, and a process of detecting the occurrence of a failure in a link between the first node and one of the second node; transmitting a notification regarding the detection of the failure to a child node; When a failure occurs between the relay node and the second node over which a backhaul link is formed, a notification regarding the detection of the failure is transmitted, and when a failure occurs in a link between the relay node and the first node, a notification regarding the detection of the failure is not transmitted. Communication system.

13. At the relay node, A dual connectivity method is configured for a first node that is a Long Term Evolution (LTE) node that manages a master cell group (MCG) and provides an Evolved Universal Terrestrial Radio Access (E-UTRA) service, and a second node that is a New Radio (NR) node that provides an NR (New Radio) service, and a process of detecting the occurrence of a failure in a link between the first node and one of the second node; and transmitting a notification regarding the detection of the failure to a child node; The transmission of the notification regarding the detection of the failure is performed when a failure occurs between the relay node and the second node through which a backhaul link is formed, and when a failure occurs in a link between the relay node and the first node, the notification regarding the detection of the failure is not transmitted. program.

14. A chipset for controlling a relay node, A dual connectivity method is configured for a first node that is a Long Term Evolution (LTE) node that manages a master cell group (MCG) and provides an Evolved Universal Terrestrial Radio Access (E-UTRA) service, and a second node that is a New Radio (NR) node that provides an NR (New Radio) service, and a process of detecting the occurrence of a failure in a link between the first node and one of the second node; transmitting a notification regarding the detection of the failure to a child node; The transmission of the notification regarding the detection of the failure is performed when a failure occurs between the relay node and the second node through which a backhaul link is formed, and when a failure occurs in a link between the relay node and the first node, the notification regarding the detection of the failure is not transmitted. Chipset.

Images