COMMUNICATION CONTROL METHOD, FIRST RELAY DEVICE, PROCESSOR, PROGRAM, AND MOBILE COMMUNICATION SYSTEM

Abstract

To provide a communication control method used in a mobile communication system that can form at least one communication path using a plurality of relay devices between a user device and a donor device.SOLUTION: A communication control method includes: detecting, by a relay device (IAB node 300) included in a plurality of relay devices, a failure of a backhaul link between an upper device higher than the relay device and the relay device; in response to the detecting of the failure in the backhaul link, transmitting, by the relay device, a failure notification related to the failure of the backhaul link to a lower device lower than the relay device; and by the lower device, in response to receiving the failure notification from the relay device, stopping uplink transmission to the relay device.SELECTED DRAWING: Figure 6

Description

[Technical field]

[0001] The present disclosure relates to a communication control method used in a mobile communication system. [Background technology]

[0002] In the 3GPP (3rd Generation Partnership Project), a standardization project for mobile communication systems, a new relay device called an IAB (Integrated Access and Backhaul) node is being considered. One or more relay devices are interposed in communication between a base station and user equipment, and relay this communication.

[0003] Such a relay device has user equipment functions and base station functions, and uses the user equipment functions to perform wireless communication with an upper node (a base station or an upper relay device), and uses the base station functions to perform wireless communication with a lower node (a user equipment or a lower relay device).

[0004] A wireless section between a user equipment and a relay device or a base station may be referred to as an access link. A wireless section between a relay device and a base station or another relay device may be referred to as a backhaul link. 3GPP contribution "RP-170217" describes a method for dynamically switching communication paths by integrating and multiplexing data communication of an access link and data communication of a backhaul link in layer 2 and dynamically allocating wireless resources to the backhaul link. Summary of the Invention

[0005] A communication control method according to a first aspect is a method used in a mobile communication system capable of forming at least one communication path using a plurality of relay devices between a user device and a donor device. The communication control method includes a relay device included in the plurality of relay devices detecting a failure of a backhaul link between the relay device and an upper-level device that is a higher level of the relay device, a BAP layer of the relay device transmitting a failure notification regarding the failure of the backhaul link to a lower-level device that is a lower level of the relay device in response to the detection of the failure of the backhaul link, and a BAP layer of the lower-level device notifying an upper layer of the lower-level device of the receipt of the failure notification in response to the receipt of the failure notification from the relay device. [Brief description of the drawings]

[0006] [Figure 1] 1 is a diagram showing a configuration of a mobile communication system according to an embodiment; [Diagram 2] FIG. 2 is a diagram illustrating a configuration of a base station according to an embodiment. [Diagram 3] FIG. 2 is a diagram illustrating a configuration of a relay device according to an embodiment. [Figure 4] FIG. 2 is a diagram illustrating a configuration of a user device according to an embodiment. [Diagram 5] FIG. 2 is a diagram illustrating an example of a protocol stack configuration of a user plane according to an embodiment. [Figure 6] 5 is a diagram illustrating an operation of the relay device according to the first embodiment. FIG. [Figure 7] FIG. 2 is a diagram showing an example of the operation of the mobile communication system according to the first embodiment. [Figure 8] FIG. 13 is a diagram illustrating a configuration in a case where dual connectivity is applied in the first modification of the first embodiment. [Figure 9] FIG. 11 is a diagram illustrating an operation according to the second modification of the first embodiment. [Figure 10] FIG. 11 is a diagram illustrating an operation example 1 of the second embodiment. [Figure 11] FIG. 11 is a diagram illustrating an operation example 2 of the second embodiment. [Figure 12] FIG. 11 is a diagram illustrating an operation example 3 of the second embodiment. [Figure 13] FIG. 11 is an operational flow diagram of a relay device in an operational example 3 of the second embodiment. [Figure 14] FIG. 11 is a diagram illustrating an operation example 4 of the second embodiment. [Figure 15] FIG. 11 is a diagram illustrating a fifth operation example of the second embodiment. [Figure 16] FIG. [Figure 17] FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] A mobile 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.

[0008] [First embodiment]

[0009] (Configuration of a mobile communication system) First, a configuration of a mobile communication system according to an embodiment will be described. Fig. 1 is a diagram showing a configuration of a mobile communication system 1 according to an embodiment. The mobile communication system 1 is a fifth generation (5G) mobile communication system based on the 3GPP standard. Specifically, the radio access method in the mobile 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 mobile communication system 1.

[0010] As shown in Fig. 1, the mobile communication system 1 includes a 5G core network (5GC) 10, a user equipment (UE: User Equipment) 100, a base station (called a gNB) 200, and an IAB node 300. The IAB node 300 is an example of a relay device.

[0011] In one embodiment, an example in which the base station is an NR base station is mainly described, but the base station may also be an LTE base station (i.e., an eNB).

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

[0013] The gNB 200 is connected to the 5GC 10 via an interface called an NG interface. In FIG. 1, three gNBs 200-1 to 200-3 connected to the 5GC 10 are illustrated. The gNB 200 is a fixed wireless communication device that performs wireless communication with the UE 100. When the gNB 200 has a donor function, the gNB 200 may perform wireless communication with an IAB node wirelessly connected to the gNB 200.

[0014] The gNB 200 is connected to other adjacent gNBs 200 via an inter-base station interface called an Xn interface. FIG 1 shows an example in which a gNB 200-1 is connected to a gNB 200-2 and a gNB 200-3.

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

[0016] The UE 100 is a mobile wireless communication device that performs wireless communication with the gNB 200. The UE 100 may perform wireless communication with the IAB node 300. The UE 100 may be a device that performs wireless communication with the gNB 200 or the IAB node 300. For example, the UE 100 is a mobile phone terminal, a tablet terminal, a notebook PC, a sensor or a device provided in a sensor, or a vehicle or a device provided in a vehicle.

[0017] FIG. 1 shows an example in which UE 100-1 is wirelessly connected to gNB 200-1, UE 100-2 is wirelessly connected to IAB node 300-1, and UE 100-3 is wirelessly connected to IAB node 300-2. UE 100-1 directly communicates with gNB 200-1. UE 100-2 indirectly communicates with gNB 200-1 via IAB node 300-1. UE 100-3 indirectly communicates with gNB 200-1 via IAB node 300-1 and IAB node 300-2.

[0018] The IAB node 300 is a device (relay device) that is involved in communication between the eNB 200 and the UE 100 and relays this communication. In FIG. 1, an example is shown in which the IAB node 300-1 is wirelessly connected to the gNB 200-1, which is a donor device, and the IAB node 300-2 is wirelessly connected to the IAB node 300-1. Each IAB node 300 manages a cell. The cell ID of the cell managed by the IAB node 300 may be the same as or different from the cell ID of the cell of the donor gNB 200-1.

[0019] The IAB node 300 has a UE function (user equipment function) and a gNB function (base station function). Such a UE function may be referred to as an MT, and the gNB function may be referred to as a DU.

[0020] The IAB node 300 performs wireless communication with an upper device (gNB 200 or upper IAB node 300) using its own UE function (MT), and performs wireless communication with a lower device (UE 100 or lower IAB node 300) using its own gNB function (DU). The term "upper" refers to the donor device (gNB 200) side with respect to the IAB node 300, and the term "lower" refers to the UE 100 side with respect to the IAB node 300.

[0021] The UE functionality (MT) means at least some of the functions of the UE 100, and the IAB node 300 does not necessarily have all of the functions of the UE 100. The gNB functionality (DU) means at least some of the functions of the gNB 200, and the IAB node 300 does not necessarily have all of the functions of the gNB 200. For example, the gNB functionality (DU) does not necessarily have to include an RRC layer and a PDCP layer.

[0022] A wireless section between the UE 100 and the IAB node 300 or the gNB 200 may be referred to as an access link (or Uu). A wireless section between the IAB node 300 and the gNB 200 or another IAB node 300 may be referred to as a backhaul link (or Un). Such a backhaul link may be referred to as a fronthaul link.

[0023] It is possible to integrate and multiplex the data communication of the access link and the data communication of the backhaul link in layer 2, dynamically allocate radio resources to the data communication of the backhaul link, and dynamically switch the relay path. The access link and the backhaul link may use a millimeter wave band. The access link and the backhaul link may be multiplexed by time division and / or frequency division.

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

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

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

[0027] The control unit 230 performs various controls in the gNB 200. The control unit 230 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processing. The processor executes the processing described below.

[0028] (Configuration of relay device) Next, a configuration of an IAB node 300 which is a relay device according to an embodiment will be described. Fig. 3 is a diagram showing a configuration of the IAB node 300. As shown in Fig. 3, the IAB node 300 has a wireless communication unit 310 and a control unit 320. The IAB node 300 may have a plurality of wireless communication units 310.

[0029] The wireless communication unit 310 is used for wireless communication (backhaul link) with the gNB 200 and for wireless communication (access link) with the UE 100. The wireless communication unit 310 for backhaul link communication and the wireless communication unit 310 for access link communication may be provided separately.

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

[0031] 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 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 executes the processing described below.

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

[0033] The wireless communication unit 110 is used for wireless communication in the access link, i.e., wireless communication with the gNB 200 and wireless communication with the IAB node 300. The wireless communication unit 110 has a receiving unit 111 and a transmitting unit 112. The receiving unit 111 performs various receptions under the control of the control unit 120. The receiving unit 111 includes an antenna, and converts a wireless signal received by the antenna into a baseband signal (received signal) and outputs the signal to the control unit 120. The transmitting unit 112 performs various transmissions under the control of the control unit 120. The transmitting unit 112 includes an antenna, and converts a baseband signal (transmitted signal) output by the control unit 120 into a wireless signal and transmits the signal from the antenna.

[0034] 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 a baseband signal. The CPU executes programs stored in the memory to perform various processing. The processor executes the processing described below.

[0035] (An example of a protocol stack configuration) Next, an example of a protocol stack configuration in the mobile communication system 1 according to an embodiment will be described. Fig. 5 is a diagram showing an example of a protocol stack configuration of a user plane. Fig. 5 shows an example of a protocol stack configuration related to user data transmission between the UE 100-3 and the UPF 12 of the 5GC 10 shown in Fig. 1.

[0036] 5, the UPF 12 has a GPRS Tunneling Protocol for User Plane (GTP-U), a User Datagram Protocol (UDP), an Internet Protocol (IP), and Layer 1 / Layer 2 (L1 / L2). The gNB 200-1 (donor gNB) is provided with protocol stacks corresponding to these.

[0037] The gNB 200-1 also has a central unit (CU) and a distributed unit (DU). In the protocol stack of the wireless interface, the CU has layers above the packet data convergence protocol (PDCP), and the DU has layers below the radio link control (RLC), and the CU and the DU are connected via an interface called an F1 interface.

[0038] Specifically, the CU has a Service Data Adaptation Protocol (SDAP), a PDCP, an IP, and L1 / L2. The SDAP and PDCP of the CU communicate with the SDAP and PDCP of the UE 100 via the DU, the IAB node 300-1, and the IAB node 300-2.

[0039] In addition, the DU has an RLC, an adaptation layer (Adapt), a MAC (Medium Access Control), and a PHY (Physical layer) in the protocol stack of the radio interface. These protocol stacks are protocol stacks for gNBs. Note that the hierarchical relationship between the adaptation layer and the RLC (S-RLC) may be reversed. The adaptation layer may be called a backhaul adaptation protocol (BAP) layer.

[0040] The IAB node 300-1 is provided with a protocol stack ST1 for UEs corresponding to these. Furthermore, the IAB node 300-1 is provided with a protocol stack ST2 for gNBs. Both the protocol stack ST1 and the protocol stack ST2 are composed of layers (sublayers) below layer 2. That is, the IAB node 300-1 is a layer 2 relay device that relays user data using layers below layer 2. The IAB node 300-1 relays data without using layers above layer 3 (specifically, layers above PDCP). The IAB node 300-2 has a protocol stack configuration similar to that of the IAB node 300-1.

[0041] Here, the protocol stack configuration in the user plane has been described. However, in the control plane, the gNB 200-1, the IAB node 300-1, the IAB node 300-2, and the UE 100-3 each have a Radio Resource Control (RRC) corresponding to Layer 3.

[0042] An RRC connection is established between the RRC of the gNB 200-1 (donor gNB) and the RRC of the IAB node 300-1, and RRC messages are transmitted and received using this RRC connection. Also, an RRC connection is established between the RRC of the gNB 200-1 and the RRC of the IAB node 300-2, and RRC messages are transmitted and received using this RRC connection. Furthermore, an RRC connection is established between the RRC of the gNB 200-1 and the RRC of the UE 100-3, and RRC messages are transmitted and received using this RRC connection.

[0043] (Operation according to the first embodiment) Next, a description will be given of the operation according to the first embodiment. Fig. 6 is a diagram showing the operation of the IAB node 300 according to the first embodiment.

[0044] 6, the IAB node 300 is wirelessly connected to an upper device A via a backhaul link. The upper device A is an upper IAB node or a donor gNB (donor device).

[0045] The IAB node 300 is connected to lower-level devices B1 and B2, and the lower-level device B2 is connected to lower-level device B3. The lower-level device B4 is a device that is not subordinate to the IAB node 300. The lower-level devices B1 to B4 are lower IAB nodes or UEs. Hereinafter, the lower-level devices B1 to B4 will be simply referred to as lower-level device B when there is no particular need to distinguish them.

[0046] In the first embodiment, in an IAB node 300 that wirelessly relays communication between a higher-level device A and a lower-level device B, a user equipment function unit (MT) that wirelessly connects to the higher-level device A notifies a base station function unit (DU) that wirelessly connects to the lower-level device B of status information.

[0047] This state information indicates at least one of the RRC state of the user equipment function unit (MT) and the radio link state (hereinafter referred to as the backhaul link state) between the upper device A and the user equipment function unit (MT). This allows the base station function unit (DU) to control the service provision to the lower device B in consideration of the state of the backhaul link side.

[0048] Here, the RRC state of the user equipment function unit (MT) is one of connected, inactive, and idle.

[0049] The backhaul link status is based on at least one of the following indicators 1) to 6), or a combination of these indicators.

[0050] 1) RLF state such as detection of backhaul RLF (hereinafter referred to as BH RLF) and recovery from BH RLF

[0051] 2) Wireless quality such as RSRP (Reference Signal Received Power)

[0052] 3) Link status, such as the number of RLC (Radio Link Control) retransmissions and the number of RACH (Random Access Channel) retransmissions

[0053] 4) Congestion level such as RSSI (Received Signal Strength Indicator), CBR (Channel Busy Ratio), and LBT (Listen Before Talk) status

[0054] 5) Communication capacity such as the number of configured or activated secondary cells, the number of MIMO (Multiple Input Multiple Output) layers, the status of allocated radio resources (e.g., increase or decrease in configured grant in semi-static allocation, increase or decrease in dynamic grant in dynamic allocation), and throughput measurements

[0055] 6) Delay status such as measured uplink scheduling delay time and amount of data in the uplink buffer

[0056] The backhaul link condition may be a degree of goodness of the backhaul link condition based on the above indicators 1) to 6), for example, a condition such as better than a threshold or worse than a threshold.

[0057] The user equipment function unit (MT) may notify the base station function unit (DU) of state information when a change in the RRC state or a change in the backhaul link state is triggered. For example, the user equipment function unit (MT) notifies the base station function unit (DU) of state information when an event occurs in which the backhaul link state satisfies a threshold condition.

[0058] Alternatively, the user equipment function (MT) may periodically notify the base station function (DU) of the state information.

[0059] The base station function unit (DU) may stop providing a service to the lower device B based on the status information from the user equipment function unit (MT). Stopping the service provision to the lower device B means stopping the transmission of at least one downlink radio signal. The base station function unit (DU) may stop the transmission of a PSS (Primary Synchronization Signal), an SSS (Secondary Synchronization Signal), and an MIB (Master Information Block).

[0060] For example, when the user equipment function unit (MT) transitions to an RRC idle state or an RRC inactive state, the base station function unit (DU) may stop providing services to the lower-level device B. When the user equipment function unit (MT) transitions to an RRC connected state, the base station function unit (DU) may resume providing services to the lower-level device B.

[0061] When the backhaul link is degraded, for example, when a BH RLF is detected, the base station function unit (DU) may stop providing services to the lower-level device B. When the backhaul link is improved, the base station function unit (DU) may resume providing services to the lower-level device B.

[0062] Alternatively, the base station function unit (DU) may control radio resource allocation (scheduling) for the lower-level device B based on state information from the user equipment function unit (MT).

[0063] When the user equipment function unit (MT) transitions to the RRC idle state or the RRC inactive state, the base station function unit (DU) may stop resource allocation to the lower device B. Note that, when the user equipment function unit (MT) transitions to the RRC idle state or the RRC inactive state, if the base station function unit (DU) has assigned uplink resources to the lower device B, it may request the user equipment function unit (MT) to transition to the RRC connected state.

[0064] The base station function unit (DU) may resume resource allocation to the lower-level device B when the user equipment function unit (MT) transitions to the RRC connected state.

[0065] When the backhaul link is degraded, for example, when a BH RLF is detected, the base station function unit (DU) may stop resource allocation to the lower-level device B. When the backhaul link is improved, for example, when the BH RLF is recovered, the base station function unit (DU) may resume resource allocation to the lower-level device B.

[0066] Alternatively, the base station function unit (DU) may transmit a notification indicating degradation of the backhaul link, for example, a notification indicating the occurrence of a BH RLF (hereinafter referred to as an RLF notification or a BH RLF notification), to the lower device B based on state information from the user equipment function unit (MT). The BH RLF notification may include an identifier of the IAB node 300. An example in which the notification indicating degradation of the backhaul link is a BH RLF notification will be described below.

[0067] The base station function unit (DU) may transmit the BH RLF Notification by a control signal of a layer lower than the RRC layer. This is because the base station function unit (DU) does not have an RRC connection with the lower device B. The control signal of the layer lower than the RRC layer is a MAC CE (Control Element), an RLC Control PDU (Protocol Data Unit), or a PDCCH (Physical Downlink Control Channel), but an example using a MAC CE will be described below.

[0068] The base station function unit (DU) may transmit the BH RLF Notification to the lower device B by unicast. Alternatively, the base station function unit (DU) may transmit the BH RLF Notification by broadcast or multicast in order to reduce the signaling load of the BH RLF Notification. When broadcast or multicast is used, the lower devices B3 and B4 can receive the BH RLF Notification from the IAB node 300 by monitoring not only the BH RLF Notification from the connected cell (upper IAB node) but also the BH RLF Notification from other cells.

[0069] The base station function unit (DU) may transmit the BH RLF Notification by broadcast using a fixed RNTI (Radio Network Temporary Identifier) ​​defined in advance in a specification. The base station function unit (DU) may transmit the BH RLF Notification by multicast using a common RNTI assigned to a group of lower level devices.

[0070] Note that broadcast / multicast and unicast may be used separately. In this case, the base station function unit (DU) may notify (broadcast) in an SIB whether the BH RLF Notification is to be transmitted by broadcast / multicast or unicast. Based on this SIB, the lower device B may change the waiting mode for the BH RLF Notification, for example, the RNTI used to monitor the BH RLF Notification.

[0071] The base station function unit (DU) may periodically transmit a BH RLF Notification during a period in which the radio link state of the backhaul link is degraded, for example, during a period in which a BH RLF occurs. In this case, a BH RLF occurs during a period in which the BH RLF Notification is periodically transmitted. Alternatively, the base station function unit (DU) may transmit a BH RLF Notification when a BH RLF occurs, and transmit a notification (BH Recovered) indicating recovery when recovered from the BH RLF. In the following, an example in which the occurrence of a BH RLF and recovery from the BH RLF are indicated to a lower-level device by periodically transmitting a BH RLF Notification will be mainly described.

[0072] The lower device B determines that a BH RLF occurs during a period in which the BH RLF Notification is received from the IAB node 300. The transmission cycle of the BH RLF Notification may be set in the base station function unit (DU) from the donor device via the user equipment function unit (MT) of the IAB node 300.

[0073] When the BH RLF Notification is transmitted by multicast, the lower-level device B that has received the BH RLF Notification may start transmitting ACK / NACK feedback to the IAB node 300 in response to receiving the BH RLF Notification. When the IAB node 300 has received ACKs from all of the subordinate lower-level devices B1 to B3, the IAB node 300 may stop the periodic transmission of the BH RLF Notification.

[0074] The lower-level devices B1 to B3 that have received the BH RLF Notification may perform processing to switch the connection destination or communication path from the IAB node 300. Examples of such processing include a connection re-establishment processing, a conditional handover trigger processing, a communication path switching processing, and a measurement report processing for handover. Note that, if the lower-level devices B1 to B3 no longer receive a BH RLF Notification from the IAB node 300 (or receive a notification indicating recovery of the BH RLF) during the period from starting such a switching processing to completing the switching processing, they may determine that the backhaul link of the IAB node 300 has been restored and may stop the switching processing.

[0075] For example, the lower-level devices B1 to B3 that have received the BH RLF Notification perform a cell search to search for cells other than the cell of the IAB node 300, and perform connection re-establishment (RRC Reestablishment) for an appropriate cell. Here, even if an RLF does not occur between the lower-level devices B1 to B3 and the IAB node 300, such a connection re-establishment process is performed early.

[0076] The connection re-establishment process may be controlled so as to be executed in a time-distributed manner. For example, the lower-level devices B1 to B3 may determine the execution start time of the connection re-establishment process by using a random value or a UE-ID, thereby distributing the execution start times of the connection re-establishment process of the lower-level devices B1 to B3 and preventing concentration of the load. Note that, when the BH RLF Notification is transmitted by unicast, the base station function unit (DU) may distribute the transmission timing of the BH RLF Notification, thereby distributing the execution start times of the connection re-establishment process of the lower-level devices B1 to B3.

[0077] When the lower-level devices B1 to B3 that have received the BH RLF Notification are connected to the IAB node 300 and a higher-level device other than the IAB node 300 and are performing DC communication, they may switch the communication path via the IAB node 300 to the other higher-level device, or may transmit the BH RLF Notification to the other communication device. For example, when the lower-level device B sets the IAB node 300 as a master node (MN) and sets the other higher-level device as a secondary node (SN) for backup, it switches the communication path via the MN to the SN.

[0078] When the lower level devices B1 to B3 receive the BH RLF Notification, if a conditional handover is set for them, they may consider the condition to be satisfied and perform a handover. If the handover condition is an event indicating deterioration of the wireless quality of the serving cell, they may forcibly trigger a handover by lowering the wireless quality measurement result of the serving cell (e.g., by considering it to be −200 dBm).

[0079] The lower-level devices B1 to B3 that receive the BH RLF Notification may trigger the transmission of a measurement report. Here, a general measurement report is transmitted by an RRC message, but the base station function unit (DU) does not have an RRC layer. Therefore, the IAB node 300 may hold the measurement report from the lower-level device B until the backhaul link recovers from the RLF, and transfer it to the donor device when the backhaul link recovers (temporarily) from the BH RLF, and the donor device may hand over the lower-level device B.

[0080] The lower-level device B4 that has received the BH RLF Notification may perform a process for excluding the IAB node 300 as a candidate for connection. For example, the lower-level device B4 that has received the BH RLF Notification may lower the priority of the cell of the IAB node 300, or exclude it from the reselection target, or adjust the reception power measurement value of the IAB node 300 to a lower value in a cell reselection operation in an RRC idle state or an RRC inactive state, so that the IAB node 300 is excluded as a candidate for connection. Here, in order to adjust the reception power measurement value to a lower value, an offset value may be applied to the actual reception power measurement value. The offset value may be a predetermined fixed value. Alternatively, the offset value may be a value notified from the network, and the notification may be notified by broadcast information (SIB) of the cell on which the lower-level device B4 is currently camped.

[0081] The lower level device B4 may perform the process of excluding the IAB node 300 as a connection destination candidate at a timing before starting the RRC Setup Request process or the RRC Resume Request process when transitioning to the RRC connected state.

[0082] Specifically, before transmitting an RRC Setup Request, the lower level device B4 checks whether the destination candidate cell has notified BH RLF Notification. If the destination candidate cell has not notified BH RLF Notification, the lower level device B4 transmits an RRC Setup Request. If the destination candidate cell has notified BH RLF Notification, the lower level device B4 stops (or cancels) the transmission of the RRC Setup Request and performs the cell reselection operation to select an appropriate destination for the RRC Setup Request.

[0083] If the lower-level device B4 no longer receives a BH RLF Notification from the IAB node 300 (or receives a notification indicating recovery of the BH RLF), it may determine that the backhaul link of the IAB node 300 has been restored and may discontinue the process of excluding the IAB node 300 as a candidate for connection.

[0084] Fig. 7 is a diagram showing an example of the operation according to the first embodiment. In Fig. 7, another IAB node may be interposed between the IAB node (Parent IAB node) 300 and the donor gNB (IAB donor) 200.

[0085] As shown in FIG. 7, in step S101, the user equipment function (MT) of the IAB node 300 detects a radio problem.

[0086] In step S102, the user equipment function unit (MT) of the IAB node 300 detects the BH RLF (RLF declaration).

[0087] In step S103, the user equipment function unit (MT) of the IAB node 300 notifies the base station function unit (DU) of the IAB node 300 of state information indicating the occurrence of a BH RLF.

[0088] In step S104, the base station function unit (DU) of the IAB node 300 starts periodic transmission of a BH RLF Notification in response to a notification from the user equipment function unit (MT).

[0089] In step S105, the lower device B that has received the BH RLF Notification starts a process for switching the connection destination or communication path from the IAB node 300. Examples of such a process include a connection re-establishment process (Early RRC Re-establishment), a triggering process for a conditional handover (Triggering Conditional HO), and a communication path switching process (Switching to redundant route).

[0090] In step S106, the user equipment function (MT) of the IAB node 300 cannot re-establish a connection during, for example, T310 operation, and transitions to an RRC idle state (Go to IDLE) upon expiration of T310.

[0091] In step S107, the user equipment function unit (MT) of the IAB node 300 notifies the base station function unit (DU) of the IAB node 300 of state information indicating a transition to the RRC idle state.

[0092] In step S108, the base station function unit (DU) of the IAB node 300 stops providing the service to the lower-level device B in response to the notification from the user equipment function unit (MT).

[0093] In step S109, the lower device B detects the RLF because the service provided by the IAB node 300 has been stopped.

[0094] [Modification 1 of the first embodiment] Next, a first modification of the first embodiment will be described.

[0095] In the above-described first embodiment, an example has been described in which, as shown in steps S104 and S105 of FIG. 7, the IAB node 300 that detects a BH RLF transmits a BH RLF Notification to the lower device B, and the lower device B starts processing to switch the connection destination or communication path from the IAB node 300 in response to receiving the BH RLF Notification.

[0096] In this modification, the lower device B stops uplink transmission to the IAB node 300 in response to receiving the BH RLF Notification from the IAB node 300. Specifically, when a BH RLF occurs in the IAB node 300, even if the wireless state between the IAB node 300 and the lower device B is normal, the uplink signal of the lower device B does not reach the donor device 200. Therefore, by the lower device B stopping the uplink transmission in response to receiving the BH RLF Notification from the IAB node 300, it is possible to suppress an increase in power consumption and interference.

[0097] That is, the communication control method according to this modification is a communication control method used in a mobile communication system 1 capable of forming at least one communication path using a plurality of IAB nodes 300 between the UE 100 and the donor device 200, 1) An IAB node 300 included in the plurality of IAB nodes 300 detects a BH RLF (BH RLF) between the IAB node 300 and a host device A above the IAB node 300; 2) In response to the detection of the BH RLF, the IAB node 300 transmits a fault notification (BH RLF Notification) regarding the BH RLF to a lower-level device B of the IAB node 300; 3) The lower device B stops uplink transmission to the IAB node 300 in response to receiving the BH RLF Notification from the IAB node 300.

[0098] The lower device B may stop uplink transmission to the IAB node 300 and start processing to switch the connection destination or communication path from the IAB node 300. Alternatively, the lower device B may wait for recovery of the BH RLF while stopping uplink transmission to the IAB node 300, and start processing to switch the connection destination or communication path from the IAB node 300 if the BH RLF is not recovered even after waiting for a certain period of time.

[0099] The stop of uplink transmission in the lower device B includes at least one of the following a) to e).

[0100] a) Stop sending a scheduling request (SR) from the lower device B to the IAB node 300: The scheduling request is a signal requesting allocation of uplink radio resources. Upon receiving the BH RLF Notification from the IAB node 300, the lower-level device B stops (prohibits) the transmission of the scheduling transmission to the IAB node 300.

[0101] b) Stop PUSCH (Physical Uplink Shared Channel) transmission from lower device B to IAB node 300: When the lower level device B receives the BH RLF Notification from the IAB node 300, even if an uplink radio resource (PUSCH resource) is allocated from the IAB node 300, that is, even if an uplink grant is received, the lower level device B does not apply the allocation and stops (prohibits) PUSCH transmission. That is, when the lower level device B receives the BH RLF Notification from the IAB node 300, the lower level device B stops (prohibits) transmission of uplink data and uplink RRC signaling.

[0102] c) Suspend the radio bearer of subordinate device B: Suspending a radio bearer means stopping (prohibiting) the use of the radio bearer while maintaining the settings of the radio bearer. Having received a BH RLF Notification from the IAB node 300, the lower-level device B may suspend all radio bearers corresponding to the IAB node 300, or may suspend the data radio bearer among these radio bearers while continuing to use the signaling radio bearer.

[0103] d) Stop PUCCH transmission from lower device B to IAB node 300: This may include stopping SR transmission by the MAC layer as mentioned in a) and stopping CSI (Channel State Information) feedback by the PHY layer, etc.

[0104] e) Stop PRACH transmission from lower device B to IAB node 300, or restrict (do not) initiation of a random access procedure.

[0105] In this modification, the lower device B may determine that the IAB node 300 has recovered from the BH RLF, and resume uplink transmission in response to this determination.

[0106] For example, assuming that the IAB node 300 transmits a notification (RLF Recovered) indicating that it has recovered from the BH RLF to the lower-level device B, the lower-level device B determines that the IAB node 300 has recovered from the BH RLF in response to receiving this RLF Recovered, and resumes uplink transmission.

[0107] On the other hand, under the premise that the IAB node 300 periodically (continuously) transmits a BH RLF notification to the lower device B while the BH RLF continues, the lower device B determines that the IAB node 300 has recovered from the BH RLF in response to the stop of the transmission of the BH RLF notification, and resumes uplink transmission. Here, the lower device B may determine that the transmission of the BH RLF notification has stopped when the BH RLF notification has not been received. For example, the lower device B performs this determination when the BH RLF notification has not been received at a predetermined timing. Here, the predetermined timing may be the transmission cycle in the case where the notification is transmitted periodically.

[0108] In addition, the stop of transmission of the BH RLF Notification includes, for example, a case where the transmission has already been stopped at the time when the lower device B wishes to transmit a scheduling request, and a case where the BH RLF Notification has been stopped at the next BH RLF Notification timing from the time when the lower device B wishes to transmit a scheduling request.

[0109] Although details will be described in a second embodiment, dual connectivity (DC) may be applied to the mobile communication system 1. Fig. 8 is a diagram showing a configuration in the case where dual connectivity is applied in this modification.

[0110] In the configuration shown in Fig. 8, the lower device B performs dual connectivity communication with the IAB node 300M as the master node (MN) and the IAB node 300S as the secondary node (SN). One or more cells that the MN assigns to the lower device B are called a master cell group (MCG). One or more cells that the SN assigns to the lower device B are called a secondary cell group (SCG).

[0111] 8, an upper device A1 of the IAB node 300M and an upper device A2 of the IAB node 300S are the IAB node 300 or the gNB 200. A lower device B is the IAB node 300 or the UE 100.

[0112] In such a dual connectivity situation, when the IAB node 300M, which is an MN, detects a BH RLF with the upper device A1, it transmits a BH RLF Notification to the lower device B. In response to receiving the BH RLF Notification from the IAB node 300M, which is an MN, the lower device B stops uplink transmission to the IAB node 300M and stops uplink transmission to the IAB node 300S, which is an SN. In other words, when the MN detects a BH RLF, the lower device B stops all uplink transmissions (uplink transmissions to the MCG and SCG).

[0113] On the other hand, when the IAB node 300S, which is an SN, detects a BH RLF with the upper device A2, it transmits a BH RLF Notification to the lower device B. In response to receiving the BH RLF Notification from the IAB node 300S, which is an SN, the lower device B stops uplink transmission to the IAB node 300S, which is an SN, without stopping uplink transmission to the IAB node 300M, which is an MN. In other words, when the SN detects a BH RLF, the lower device B stops only uplink transmission to the SN (uplink transmission to the SCG).

[0114] [Modification 2 of the First Embodiment] Next, a second modification of the first embodiment will be described.

[0115] In the above-described embodiment, an example has been described in which the IAB node 300 transmits the BH RLF Notification in the MAC layer. In this modification, the lower layer device B that receives such a BH RLF Notification notifies a higher layer of the BH RLF Notification received in the MAC layer.

[0116] That is, the communication control method according to this modification is a communication control method used in a mobile communication system 1 capable of forming at least one communication path using a plurality of IAB nodes 300 between the UE 100 and the donor device 200, 1) An IAB node 300 included in the plurality of IAB nodes 300 detects a BH RLF between the IAB node 300 and a host device A that is a higher level of the IAB node 300; 2) In response to the detection of the BH RLF, the MAC layer of the IAB node 300 transmits a fault notification (BH RLF Notification) regarding the BH RLF to a lower-level device B of the IAB node 300; 3) The MAC layer of the lower device B notifies the upper layer of the lower device B of the receipt of the failure notification in response to receiving the failure notification from the IAB node 300.

[0117] Fig. 9 is a diagram showing the operation according to this modified example. Fig. 9(1) shows an example in which the lower device B is an IAB node 300. Fig. 9(2) shows an example in which the lower device B is a UE 100. The upper device A may be the IAB node 300 or a gNB 200 (donor device).

[0118] As shown in (1) of FIG. 9, the IAB node 300 has an MT, a BAP layer, and a DU. At least a part of the BAP layer may be included in the MT or may be included in the DU. The DU of the IAB node 300 has a MAC layer. The DU also has a PHY layer and an RLC layer, which are not shown. The MT of the lower device B (lower IAB node) has a MAC layer and an RRC layer. The DU also has a PHY layer and an RLC layer, which are not shown.

[0119] As shown in (2) of Fig. 9, the IAB node 300 has the same configuration as that shown in (1) of Fig. 9. The lower device B (UE 100) has a MAC layer, a PDCP layer, and an RRC layer. The UE 100 also has a PHY layer and an RLC layer, which are not shown.

[0120] In the configuration shown in Fig. 9, when the MT of the IAB node 300 detects a BH RLF, the MAC layer of the DU of the IAB node 300 transmits a BH RLF Notification to the lower device B in response to the detection of the BH RLF. The BH RLF Notification may be included in a MAC CE (Control Element). When the MAC layer of the lower device B receives the BH RLF Notification, it notifies the upper layer of the lower device B that it has received the BH RLF Notification. The notification to the upper layer may be a notification indicating that a BH RLF has been detected in the IAB node 300, or a notification that the corresponding communication path (or the wireless link between the IAB node 300 and the lower device B) is unavailable.

[0121] The upper layer to which the MAC layer notifies the lower device B includes at least one of the RRC layer, the BAP layer, and the PDCP layer. The upper layer may perform the process described in the first embodiment, that is, the process for switching the connection destination or the communication path from the IAB node 300, or may perform the process described in the first modification of the first embodiment, that is, the process for stopping the uplink transmission.

[0122] In the lower device B, the RRC layer that receives the notification from the MAC layer executes, for example, at least one of the following processes.

[0123] Uplink transmission is stopped (see Modification 1 of the first embodiment).

[0124] Attempt to establish a redundancy link. For example, if the lower-level device B is a lower-level IAB node and the lower-level IAB node has multiple MTs, the RRC layer establishes a link with an MT other than the MT that received the BH RLF Notification.

[0125] The RRC layer performs RRC reestablishment to another cell (another upper device).

[0126] · If the lower device B has dual connectivity and receives a BH RLF Notification from the SN (SCG), the RRC layer sends a notification (SCG Failure Indication) to the MN (MCG).

[0127] · If the lower device B has dual connectivity and receives a BH RLF Notification from the MN (MCG), the RRC layer sends a notification (MCG Failure Indication) to the SN (SCG).

[0128] In addition, in the lower device B, the BAP layer or PDCP layer that has received the notification from the MAC layer transfers (reroutes) the buffered upstream data to another link if the lower device B has dual connectivity. For example, when the lower device B receives a BH RLF Notification from the SN (SCG), the BAP layer or PDCP layer transfers the upstream data to the MN (MCG). On the other hand, when the lower device B receives a BH RLF Notification from the MN (MCG), the BAP layer or PDCP layer transfers the upstream data to the SN (SCG). Alternatively, the BAP layer or PDCP layer stops transmitting upstream data to an RLC channel (i.e., an RLC entity) that has established a link with the route (upper node) where the BH RLF occurs.

[0129] In this modification, an example in which the BH RLF Notification is transmitted and received in the MAC layer has been described, but the BH RLF Notification may be transmitted and received in, for example, the RRC layer. Under such a premise, upon receiving the BH RLF Notification, the RRC layer of the lower device B notifies other layers (for example, the BAP layer and / or the MAC layer) that the BH RLF Notification has been received.

[0130] Alternatively, the BH RLF Notification may be transmitted and received in the BAP layer. Under such a premise, when the BAP layer of the lower device B receives the BH RLF Notification, the BAP layer notifies other layers (for example, the RRC layer and / or the MAC layer) that the BH RLF Notification has been received.

[0131] [Third Modification of the First Embodiment] Next, a third modification of the first embodiment will be described.

[0132] In the above-mentioned first embodiment, an example has been described in which the IAB node 300 periodically (continuously) transmits the BH RLF Notification during a period in which a BH RLF occurs, as shown in step S104 in Fig. 7. This transmission period may be a fixed period defined in the specifications of the mobile communication system 1, but in this modification, this transmission period is variable.

[0133] That is, the communication control method according to this modification is a communication control method used in a mobile communication system 1 capable of forming at least one communication path using a plurality of IAB nodes 300 between the UE 100 and the donor device 200, 1) An IAB node 300 included in the plurality of IAB nodes 300 detects a BH RLF between the IAB node 300 and a host device A that is a higher level of the IAB node 300; 2) In response to detection of the BH RLF, the IAB node 300 repeatedly transmits a fault notification (BH RLF Notification) regarding the BH RLF to a lower-level device B below the IAB node 300; and 3) The IAB node 300 transmits, to the lower device B, timing information regarding the timing of repeatedly transmitting the fault notification.

[0134] This makes it possible to vary the transmission cycle of fault notifications (BH RLF Notification). If the cycle is shortened, transmissions will be more frequent, so that when an upper node recovers from a BH RLF, the lower node can quickly learn of the recovery and can quickly perform recovery operations such as resuming UL transmission. On the other hand, this has the disadvantage of increasing power consumption required for transmission / reception and increasing interference. If the cycle is lengthened, the above advantages and disadvantages are reversed. Therefore, the transmission cycle of fault notifications (BH RLF Notification) can be adjusted to an optimal value according to the network design policy.

[0135] Here, the repeated transmission may be a periodic transmission or a non-periodic transmission. When the BH RLF Notification is transmitted periodically, the timing information transmitted by the IAB node 300 includes information indicating the transmission period of the BH RLF Notification. When the BH RLF Notification is transmitted non-periodically, the timing information transmitted by the IAB node 300 may include information indicating a subframe number corresponding to the transmission timing of the BH RLF Notification.

[0136] The IAB node 300 may transmit the SIB including the timing information by broadcast. Alternatively, the donor device may transmit an RRC message (RRC Reconfiguration message) including the timing information to the subordinate device B via the IAB node 300.

[0137] Alternatively, the IAB node 300 may transmit timing information together with the BH RLF Notification to the lower device B. Specifically, the IAB node 300 transmits a BH RLF Notification including timing information. For example, the timing information included in one BH RLF Notification may include information indicating a subframe number corresponding to the transmission timing of the next BH RLF Notification. As described above, the BH RLF Notification may be transmitted and received in the MAC layer.

[0138] Furthermore, the IAB node 300 that detects the BH RLF may repeatedly transmit a BH RLF Notification to the lower device B during a period during which the re-establishment of the backhaul link is attempted. Specifically, even if the IAB node 300 that detects the BH RLF fails to re-establish the RRC of the backhaul link, the IAB node 300 continues to transmit the BH RLF Notification during a period during which the attempt to re-establish the RRC of the backhaul link is continued. If the RRC re-establishment is not successful within this period, the DU of the IAB node 300 stops transmitting the BH RLF Notification and stops providing services to the lower device B (i.e., stops the PSS / SSS / MIB / SIB1). Furthermore, the MT of the IAB node 300 transitions to an RRC idle state.

[0139] [Second embodiment] Next, a second embodiment will be described based on the operations of the first embodiment and its modified example. However, the differences from the first embodiment will be mainly described, and the description overlapping with the first embodiment will be omitted.

[0140] The second embodiment is an embodiment assuming dual connectivity (DC), and can be used in combination with the operations according to the first embodiment and its modified examples.

[0141] (Example 1) FIG. 10 is a diagram illustrating an operation example 1 of the second embodiment.

[0142] 10, the IAB node 300 performs dual-connection communication with the host device A1 as the MN and the host device A2 as the secondary node (SN). The IAB node 300 is wirelessly connected to the subordinate device B. The subordinate device B is a subordinate IAB node or a UE.

[0143] The IAB node 300 does not establish a backhaul link for a communication path between the host device A1, which is an MN, and the IAB node 300 establishes a control link for the host device A1 to control the IAB node 300. The IAB node 300 establishes a backhaul link for a communication path between the host device A2, which is an SN.

[0144] When an IAB node 300 having a dual connection has established both a backhaul link with an MN and a backhaul link with an SN, even if a BH RLF occurs in the backhaul link with an SN, as long as the BH RLF is maintained in the backhaul link with the MN, it is considered that the IAB node 300 does not need to transmit a BH RLF Notification to the lower device B. This is because, even if a BH RLF occurs in the backhaul link with an SN, as long as the backhaul link with the MN is maintained, the lower device B may maintain a connection to the IAB node 300.

[0145] On the other hand, if the IAB node 300 having dual connectivity does not set up a backhaul link with the MN, the IAB node 300 cannot transmit or receive data of the subordinate device B to or from the MN. For this reason, if a BH RLF occurs in the backhaul link with the SN, the subordinate device B cannot transmit or receive data via the IAB node 300, so the IAB node 300 should transmit a BH RLF Notification to the subordinate device B.

[0146] That is, the communication control method according to this operation example is a communication control method used in a mobile communication system 1 capable of forming at least one communication path using a plurality of IAB nodes 300 between the UE 100 and the donor device 200, 1) An IAB node 300 included in a plurality of IAB nodes 300 performs dual connectivity communication with a host device A2 above the IAB node 300 as an SN and another device (host device A1) as an MN; 2) Setting a backhaul link between the IAB node 300 and the SN without setting a backhaul link for a communication path between the IAB node 300 and the MN; and 3) The IAB node 300 detects a BH RLF between the IAB node 300 and an SN, and in response to the detection of the BH RLF, the IAB node 300 transmits a fault notification (BH RLF Notification) regarding the BH RLF to a subordinate device B subordinate to the IAB node 300.

[0147] Specifically, in this operation example, the IAB node 300 performing dual connectivity communication determines whether to transmit a fault notification to the lower device B depending on whether a backhaul link is established between the IAB node 300 and the MN. Specifically, when a backhaul link is not established between the IAB node 300 and the MN, the IAB node 300 determines to transmit a fault notification to the lower device B in response to detection of a BH RLF between the IAB node 300 and the SN. On the other hand, when a backhaul link is established between the IAB node 300 and the MN, the IAB node 300 determines not to transmit a fault notification to the lower device B even if it detects a BH RLF between the IAB node 300 and the SN.

[0148] In this operation example, dual connectivity (DC) by LTE and NR, i.e., EN-DC (E-UTRA (Evolved Universal Terrestrial Radio Access)-NR Dual Connectivity), may be assumed. Under such assumption, the MN (host device A1) is an LTE device, and the SN (host device A2) is an NR device. For example, the MN (host device A1) is an eNB that is an LTE base station, and the SN (host device A2) is a gNB (donor device 200) that is an NR base station or a host IAB node.

[0149] In this operation example, dual connectivity (DC) using only NR, i.e., NR-DC (NR Dual Connectivity), may be assumed. Under such assumption, the MN (host device A1) is an NR device, and the SN (host device A2) is also an NR device. For example, the MN (host device A1) is a gNB or a host IAB node that is an NR base station, and the SN (host device A2) is a gNB or a host IAB node that is an NR base station.

[0150] In this operation example, the IAB node 300 may receive setting information indicating whether or not it is used as a backhaul link from the donor device 200, and may set and identify the backhaul link based on the setting information. The setting information may be information indicating whether or not it is used as a backhaul link for each CG (Cell Group) or for each bearer.

[0151] (Example 2) FIG. 11 is a diagram illustrating an operation example 2 of the second embodiment.

[0152] As shown in FIG. 11, the lower device B performs dual connectivity communication with the upper device A1 as the MN and the IAB node 300 as the secondary node (SN). The lower device B is a lower IAB node or a UE. Under such a premise, when the IAB node 300 detects a BH RLF with the upper device A2 of the IAB node 300, it transmits a BH RLF Notification to the lower device B. In this case, it is preferable that the MN (upper device A1) can grasp that a BH RLF has occurred in the IAB node 300, which is an SN. The upper device A1 is an IAB node or a base station, and the upper device A2 is an IAB node or a base station (donor device 200).

[0153] That is, the communication control method according to this operation example is a communication control method used in a mobile communication system 1 capable of forming at least one communication path using a plurality of IAB nodes 300 between the UE 100 and the donor device 200, 1) A lower-level device B below the IAB node 300 performs dual-connection communication with the IAB node 300 as the SN and another device (higher-level device A1) as the MN; 2) When the IAB node 300 detects a BH RLF between the IAB node 300 and a higher-level device (higher-level device A2) of the IAB node 300, the IAB node 300 transmits a first fault notification (BH RLF Notification) to the lower-level device B; 3) The lower device B transmits a second failure indication indicating the BH RLF in the SN to the MN in response to receiving the first failure indication from the IAB node 300 which is the SN.

[0154] In addition, when the lower device B detects an RLF between the lower device B and the IAB node 300, it may transmit an SCG Failure Indication to the MN. On the other hand, the second failure notification (Failure Indication) is transmitted from the lower device B to the MN when a BH RLF occurs between the IAB node 300 and the upper device A2 even if an RLF is not detected between the lower device B and the IAB node 300. In addition, the second failure notification (Failure Indication) may be an information element in the SCG Failure Indication message, or may be a message different from the SCG Failure Indication message.

[0155] The lower device B may include "BH RLF" in the second failure indication as information indicating the cause of the SCG failure. The second failure indication may include an identifier indicating the IAB node 300 or its cell.

[0156] The upper device A1 (MN) that receives the second failure notification (Failure Indication) from the lower device B performs processing such as SN change (Secondary Node Change) to reconnect the link on the side of the IAB node 300, which is an SN, to another upper device. In addition, the upper device A1 (MN) may determine that the DC setting has been disconnected (failed) based on the second failure notification (Failure Indication) and execute processing to release the UE context in the IAB node 300, which is an SN. For example, the upper device A1 (MN) transmits a UE context release message to the IAB node 300 (SN) via an interface between the upper device A1 (MN) and the IAB node 300 (SN).

[0157] (Example 3) FIG. 12 is a diagram illustrating an operation example 3 of the second embodiment.

[0158] As shown in Fig. 12, the IAB node 300 communicates with the MN 300M and the SN 300S through dual connections. Each of the MN 300M and the SN 300S is an upper IAB node. When the MN 300M detects a BH RLF with its upper device A1, it transmits a BH RLF Notification to the IAB node 300. When the SN 300S detects a BH RLF with its upper device A2, it transmits a BH RLF Notification to the IAB node 300. Each of the upper devices A1 and A2 is an upper IAB node or a base station. It is assumed that no RLF occurs in the MCG link, which is the link between the IAB node 300 and the MN 300M, and no RLF occurs in the SCG link, which is the link between the IAB node 300 and the SN 300S.

[0159] Under such a premise, only when the IAB node 300 receives a BH RLF Notification from both the MN 300M and the SN 300S, the IAB node 300 transmits a BH RLF Notification to the lower device B. In other words, when the IAB node 300 receives a BH RLF Notification from only one of the MN 300M and the SN 300S, the IAB node 300 does not transmit a BH RLF Notification to the lower device B.

[0160] That is, the communication control method according to this operation example is a communication control method used in a mobile communication system 1 capable of forming at least one communication path using a plurality of IAB nodes 300 between the UE 100 and the donor device 200, 1) An IAB node 300 included in the plurality of IAB nodes 300 performs dual-connection communication with an MN 300M and an SN 300S; 2) When the MN 300M detects a BH RLF between the upper device A1 of the MN 300M and the MN 300M, the MN 300M transmits a first fault notification (BH RLF Notification) to the IAB node 300; 3) when the SN300S detects a BH RLF between the upper device A2 of the SN300S and the SN300S, transmitting a second fault notification (BH RLF Notification) to the IAB node 300; 4) When the IAB node 300 receives both the first fault notification and the second fault notification, the IAB node 300 transmits a third fault notification (BH RLF Notification) to a lower-level device B below the IAB node 300.

[0161] Here, even if no RLF has occurred between the IAB node 300 and the MN 300M and between the IAB node 300 and the SN 300S, when the IAB node 300 receives both the first and second fault notifications, it transmits a third fault notification (BH RLF Notification) to the lower device B. In other words, even if the IAB node 300's own wireless condition is good, when a BH RLF is detected in both the MN 300M and the SN 300S, the IAB node 300 transmits a third fault notification (BH RLF Notification) to the lower device B.

[0162] When the IAB node 300 receives both the first fault notification and the second fault notification, the IAB node 300 may determine that a BH RLF has occurred in the IAB node 300. By determining that a BH RLF has occurred, the IAB node 300 will end up transmitting a BH RLF Notification to the lower device B. Furthermore, by determining that a BH RLF has occurred, the IAB node 300 may perform an operation such as re-establishing an RRC with another upper device.

[0163] In this operation example, when the IAB node 300 receives both the first fault notification and the second fault notification and determines that the state in which the backhaul communication of the IAB node 300 has not been restored continues for a certain period of time, the IAB node 300 may transmit a third fault notification to the lower device B. That is, the IAB node 300 does not transmit the third fault notification to the lower device B immediately after receiving both the first fault notification and the second fault notification, but transmits the third fault notification to the lower device B after confirming that its own backhaul communication has not been restored within a certain period of time after receiving both the first fault notification and the second fault notification. On the other hand, when the IAB node 300 determines that its own backhaul communication has been restored within a certain period of time after receiving both the first fault notification and the second fault notification, it does not transmit the third fault notification to the lower device B.

[0164] 13 is an operation flow diagram of the IAB node 300 in this operation example. Here, it is assumed that each of the MN 300M and the SN 300S periodically (continuously) transmits a BH RLF Notification during a period during which the BH RLF is detected.

[0165] As shown in FIG. 13, in step S201, the IAB node 300 determines whether or not it has received a BH RLF Notification from both the MN 300M (MCG) and the SN 300S (SCG), that is, from all CGs.

[0166] When the BH RLF Notification is received from all CGs (step S201: Yes), the IAB node 300 starts a timer corresponding to a certain period of time in step S202. The value of this timer may be set in the IAB node 300 by the MN 300M or the higher-level device A1 (for example, a donor device).

[0167] In step S203, the IAB node 300 judges whether or not the reception of the BH RLF Notification from both the MN 300M (MCG) and the SN 300S (SCG), i.e., from all CGs, continues. If the result is "No" in step S203, the process returns to step S201.

[0168] If the answer is "Yes" in step S203, then in step S204, the IAB node 300 determines whether the timer started in step S202 has expired. If the answer is "No" in step S204, then the process returns to step S203.

[0169] If the result is "Yes" in step S204, then in step S205, the IAB node 300 transmits a BH RLF Notification to the lower device B. Alternatively, if the result is "Yes" in step S204, then in step S205, the IAB node 300 may consider that its own BH RLF has occurred.

[0170] 13, it is assumed that each of the MN 300M and the SN 300S periodically (continuously) transmits a BH RLF Notification during a period in which the BH RLF is detected. However, as described in the first embodiment, each of the MN 300M and the SN 300S may transmit a notification indicating recovery (BH Recovered) when recovered from the BH RLF.

[0171] Under the assumption that such a notification (BH Recovered) is used, the IAB node 300 may determine whether or not BH Recovered has been received from at least one of the CGs in step S203. If the IAB node 300 has received BH Recovered from at least one of the CGs, the process returns to step S201. On the other hand, if the IAB node 300 has not received BH Recovered from any of the CGs, the process proceeds to step S204.

[0172] Also, cases in which the determination in step S203 in FIG. 13 is "No" include a case in which the IAB node 300 successfully re-establishes RRC with another upper device after receiving BH RLF Notification from both CGs.

[0173] (Example 4) FIG. 14 is a diagram illustrating an operation example 4 of the second embodiment.

[0174] As shown in Fig. 14, the lower device B is performing dual connection (NR-DC) communication with the MN300M and the SN300S. The lower device B is an IAB node or a UE. Each of the MN300M and the SN300S is an IAB node. A backhaul link is established between the MN300M and the upper device A1, and a backhaul link is established between the SN300S and the upper device A2.

[0175] In this operation example, when both the MN (MCG) and the SN (SCG) are configured as backhaul links, only the MN (MCG) is permitted to transmit a BH RLF Notification.

[0176] That is, the communication control method according to this operation example is a communication control method used in a mobile communication system 1 capable of forming at least one communication path using a plurality of IAB nodes 300 between the UE 100 and the donor device 200, 1) A lower device B performs dual-connection communication with the MN 300M and the SN 300S included in the plurality of IAB nodes 300; 2) When the MN 300M detects a BH RLF between the upper device A1 and the MN 300M, the MN 300M transmits a first fault notification (BH RLF Notification) to the lower device B; 3) When the SN 300S detects a BH RLF between the upper device A2 of the SN 300S and the SN 300S, the MN 300M transmits a second fault notification (BH RLF Notification) to the lower device B.

[0177] In this operation example, when a BH RLF occurs in the SN300S, the SN300S transmits information about the BH RLF of the SN300S to the MN300M using an interface between the MN300M and the SN300S. When the host device A2 of the SN300S is capable of detecting the BH RLF of the SN300S, the host device A2 may transmit information about the BH RLF of the SN300S to the MN300M via the donor device 200.

[0178] Here, the first fault notification (BH RLF Notification) includes information indicating the occurrence of a BH RLF in the MN 300M, and the second fault notification (BH RLF Notification) includes information indicating the occurrence of a BH RLF in the SN 300S. This allows the lower device B to know whether the BH RLF occurred in the MN 300M or the SN 300S, based on the information included in the BH RLF Notification, even if only the MN 300M transmits the BH RLF Notification.

[0179] In this operation example, the SN300S identifies whether the MN300M has a backhaul link based on a notification from the donor device 200 (CU) or a notification from the MN300M. If the MN300M has a backhaul link, the SN300S prohibits the transmission of a BH RLF Notification from the SN300S to the lower device B. On the other hand, if the MN300M does not have a backhaul link, the SN300S enables the transmission of a BH RLF Notification from the SN300S to the lower device B.

[0180] (Example 5) FIG. 15 is a diagram illustrating a fifth operation example of the second embodiment.

[0181] As shown in Fig. 15, the lower device B is performing dual connection communication with the MN300M and the SN300S. Each of the MN300M and the SN300S is an IAB node. A backhaul link is set between the MN300M and the upper device A1, and a backhaul link is set between the SN300S and the upper device A2. In this operation example, it is assumed that no interface exists between the MN300M and the SN300S.

[0182] In this operation example, when a BH RLF of the SN300S occurs, the lower device B receives a message addressed to the SN300S from the MN300M and transfers the received message to the SN300S. The message addressed to the SN300S is, for example, a message for the base station interface (Xn interface) or a message for the CU-DU interface (F1 interface), and is a release message for releasing the SN300S.

[0183] That is, the communication control method according to this operation example is a communication control method used in a mobile communication system 1 capable of forming at least one communication path using a plurality of IAB nodes 300 between the UE 100 and the donor device 200, 1) A lower device B performs dual-connection communication with the MN 300M and the SN 300S included in the plurality of IAB nodes 300; 2) After the SN300S detects the BH RLF between the upper device A2 and the SN300S, the lower device B receives a message addressed to the SN300S from the MN300M; and 3) The lower device B transfers the message received from the MN 300M to the SN 300S.

[0184] This allows the BH RLF of the SN300S to be detected, and the SN300S to receive a message from the MN300M even if there is no interface between the MN300M and the SN300S.

[0185] This operation example includes the following steps.

[0186] First, the lower device B receives a BH RLF Notification indicating the BH RLF of the SN300S from the SN300S. The lower device B may receive a BH RLF Notification indicating the BH RLF of the SN300S from the MN300M (see Operation Example 4). When the lower device B receives a BH RLF Notification indicating the BH RLF of the SN300S from the SN300S, it may transmit a Failure Indication to the MN300M (see Operation Example 2).

[0187] Secondly, the MN 300M or the donor device 200 instructs the lower device B to relay the network interface (Xn / F1, etc.). The MN 300M or the donor device 200 may set an exception routing in the routing table information of the lower device B. This setting includes either the ID of the SN 300S or its cell, or the ID of an entity of the BAP layer of the SN 300S. The lower device B may notify the SN 300S that an exception routing via the lower device B has been set, or may request an exception routing via the lower device B. The lower device B may notify (respond) to the MN 300M or the donor device 200 whether or not a relay route via the lower device B has been established. In the case of a notification that a relay route cannot be established (NG), information indicating the cause, such as a refusal of the SN 300S or a refusal of the lower device B, may be included in the notification.

[0188] Third, the MN 300M or the donor device 200 transmits a message (for example, a Secondary Node Release message) of the network interface to the relay route. The message is encapsulated and carried by, for example, an RRC message or a BAP control message.

[0189] Fourth, the subordinate device B forwards the encapsulated message to the SN 300S according to the exception routing information described above.

[0190] Fifth, the SN300S receives the encapsulated message and performs an operation according to the received message. For example, the SN300S performs a process such as suspending the use of wireless resources when it receives the Secondary Node Release. The SN300S may return a Secondary Node Release Acknowledge to the MN300M or the donor device 200 via the lower device B by using exception routing.

[0191] [Other embodiments] In the above-described embodiments and modifications thereof, an example in which the mobile communication system 1 is a 5G mobile communication system has been mainly described. However, the base station in the mobile communication system 1 may be an eNB, which is an LTE base station. Also, the core network in the mobile communication system 1 may be an EPC (Evolved Packet Core). Furthermore, the gNB may be connected to the EPC, the eNB may be connected to the 5GC, and the gNB and the eNB may be connected via an inter-base station interface (Xn interface, X2 interface).

[0192] A program may be provided that causes a computer to execute each process according to each of the above-described embodiments and their modified examples. The program may be recorded in a computer-readable medium. Using the computer-readable medium, it is possible to install the program in the computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM. A chipset may be provided that is configured by a memory that stores a program for executing each process performed by the UE 100, the gNB 200, or the IAB node 300, and a processor that executes the program stored in the memory.

[0193] The flows shown in the respective figures may be combined as appropriate.

[0194] [Note] (introduction) For backhaul link radio link failure (BH RLF), RAN2 reached the following agreement:

[0195] · R2 assumes that there is an RLF notification at least in the BH link RLF to downstream nodes.

[0196] Upon recovery from a BH link failure, alternative routes and / or dual connectivity may be used (if agreed).

[0197] · The current UE RLF detection and recovery is reused as the baseline.

[0198] Further study is needed as to whether other indications are necessary, for example when the link is restored or when restoration is in progress.

[0199] In addition to the agreement, RAN2 discussed the details of RLF notification, including RLF notification for downstream nodes and RLF notification for upstream nodes.

[0200] In this appendix, we discuss the remaining issues of BH RLF handling, focusing in particular on RLF notification to downstream nodes.

[0201] Note that this appendix assumes a relationship in which a "parent" node sends RLF notifications to its "child" nodes.

[0202] (Discussion) (RLF notifications and other indications) It should be noted that Rel-15 UEs are still allowed to connect to IAB nodes, but the agreed "RLF notification" is a Rel-16 feature. To minimize service outages even for Rel-15 UEs, IAB nodes should stop transmitting SSBs (PSS, SSS, and PBCH) if they fail to restore the backhaul link, because it is obvious that IAB nodes cannot continue service without the backhaul link and they are intentionally creating radio problems for Rel-15 UEs.

[0203] Observation 1: The agreed upon "RLF notification" cannot work for Rel-15 UE.

[0204] Proposal 1: RAN2 should agree that IAB nodes will stop transmitting SSB if they fail to recover the backhaul link.

[0205] Proposal 1 also implies that an IAB node may continue to provide service until the backhaul link fails to recover. Then, it needs to be further considered whether it is worth notifying downstream MT / UE about the backhaul link status, as "whether other indications are needed, e.g., when the link recovers or when recovery is in progress, further consideration is needed." However, if RLF notification is repeatedly sent during BH RLF, there is no need to specify "other indications." In other words, if no RLF notification is sent, the BH RLF has not occurred or has already been recovered, otherwise the backhaul link recovery is in progress. So, the issue is whether to repeatedly send RLF notification during BH RLF.

[0206] Proposal 2: RAN2 should agree that the RLF notification is sent repeatedly during the BH RLF.

[0207] (RRC Connected) It is clear that while a BH RLF occurs at the parent IAB node, uplink data cannot reach the IAB donor from the child IAB node / UE. If the uplink transmission continues, it may cause unnecessary problems such as power consumption at the child IAB node / UE, risk of buffer overflow at the parent IAB node, and interference in the network. Therefore, the child node / UE should refrain from SR transmission at least for new data transmissions.

[0208] Proposal 3: RAN2 should agree that upon receiving the RLF notification, the MT / UE will stop uplink signaling, i.e., SR for data transmission.

[0209] An RLF notification is sent when a parent IAB node experiences an RLF on its backhaul link, but its access link may still be fine. In other words, RLF is not occurring on the link between the parent IAB node and the child IAB node. Since RAN2 has agreed that "current UE RLF detection and recovery will be reused as baseline", the child node / UE will not declare RLF and will not trigger an RLF notification in this case.

[0210] An additional rule is that if the receipt of an RLF notification triggers an existing RLF, it also triggers the sending of an RLF notification to downstream nodes, which is immediately propagated across the IAB topology. This could cause all IAB nodes to initiate RRC re-establishment simultaneously, potentially breaking the IAB topology. Therefore, the receipt of an RLF notification does not trigger RRC re-establishment.

[0211] Proposal 4: RAN2 should agree that the MT / UE shall not declare RLF, including initiating RRC re-establishment, upon receiving an RLF notification, nor shall it trigger the sending of an RLF notification.

[0212] (RRC Idol) Another aspect is the MT / UE behavior in RRC idle. If proposal 3 is agreeable, it is quite simple for an MT / UE in idle mode to refrain from initiating an RRC setup request to a parent IAB node receiving a BH RLF. This can be seen as a kind of access restriction. Even if an RRC setup request message is sent, it cannot be forwarded to the IAB donor (i.e. the CU with the peer RRC entity) due to the BH RLF and the procedure will eventually fail.

[0213] Proposal 5: RAN2 should agree that an MT / UE that is RRC idle should refrain from initiating an RRC setup request to a parent IAB node that is sending an RLF notification.

[0214] The issue is how the cell reselection process handles the BH RLF, i.e., whether the parent IAB node sending the BH RLF is a candidate cell for reselection. If the BH RLF can be recovered in a short time, such optimization is not necessary. If not, it may cause a bad user experience since the MT / UE cannot establish an RRC connection in a cell without a BH link after all.

[0215] Proposal 6: RAN2 should discuss whether an RRC idle MT / UE can reselect a parent IAB node to send an RLF notification.

[0216] (Consideration for dual connectivity) Dual connectivity is one of the more complex scenarios, but RAN2 agreed that "upon recovery in the event of a BH link failure, alternate routes and / or dual connectivity may be utilized (if agreed upon)." This can be categorized into two cases: parent has dual connectivity (i.e., case 1 in Figure 17) and child has dual connectivity (i.e., case 2 in Figure 17).

[0217] (Case 1 (Parent is set in DC) In case 1, the RLF notification may be triggered by either the MCG RLF or the SCG RLF. In case of EN-DC (i.e., C-plane is on LTE Uu), it is not supposed to use MCG for the backhaul link as RN2 agreed that "For IAB nodes using EN-DC, from the point of view of BAP and backhaul RLC channel, this is a single-link deployment (only BAP routed by NR link)". Therefore, even if RLF occurs only on SCG link, from the point of view of IAB topology, it should be considered as BH RLF. This also means that RLF notification should be sent by parent IAB node on SCG RLF.

[0218] Observation 2: For IAB nodes configured in the EN-DC, the SCG RLF should trigger an RLF notification.

[0219] On the other hand, in the case of NR-DC, the backhaul link may be configured only in the SCG or in both the SCG and the MCG. Needless to say, the former case (BH in only the SCG) is similar to the EN-DC case. In the latter case (BH in both the MCG and the SCG), it is clear that the SCG RLF does not trigger an RLF notification, but it is doubtful whether the MCG RLF always triggers an RLF notification.

[0220] In the current specification, the UE stops UL transmission to the SCG at the MCG RLF ("suspend all RBs except SRB0" at RRC re-establishment). This can be considered as a BH RLF. On the other hand, the quality of the SCG link may be good even if an MCG RLF occurs and it may continue to be used for robust backhaul. Therefore, the current principle of stopping UL transmission may need to be reconsidered depending on whether the SCG link should be used when the MCG link fails. For example, the fast MCG link recovery mechanism discussed in the DCCA WI.

[0221] Observation 3: For an IAB node configured with NR-DC and with BH only in SCG, the SCG RLF triggers an RLF notification (similar to observation 2).

[0222] Proposal 7: RAN2 should agree that the SCG RLF triggers an RLF notification when the backhaul link is configured with only SCG (i.e., NR-DC with EN-DC and SCG-only backhaul).

[0223] Proposal 8: RAN2 should agree that the MCG RLF always triggers an RLF notification.

[0224] Observation 4: It may be necessary to reconsider the current principle of UL transmission cessation when SCG links are used during MCG RLF. It is expected to discuss fast recovery of MCG links in DCCA WIs.

[0225] (Case 2 (child is set in DC)) In case 2, due to dual connectivity from the perspective of the child IAB node, two parent IAB nodes are available for backhaul links. Thus, the issue is which parent IAB node sends the RLF notification in its BH RLF. One approach is for the MCG (i.e., MN) or SCG (i.e., SN) to always send the RLF notification, regardless of whether the BH RLF occurs in the backhaul link associated with the MCG (i.e., MN) or SCG (i.e., SN). This would make sense since the MCG has C-plane connectivity with the child IAB node. However, this means that the SCG (SN) must notify the MCG (MN) of its BH RLF. Under the BH RLF, inter-node connectivity is not necessarily available (see Figure 17).

[0226] Therefore, it is easier if the RLF notification at MCG and the RLF notification at SCG are separated, i.e. MCG sends RLF notification only on its BH RLF and SCG sends RLF notification only on its BH RLF. This is easy if MAC CE is used for RLF notification, since under dual connectivity there are two separate MACs configured for each CG.

[0227] Proposal 9: RAN2 should agree that the RLF notification may be sent by either the MCG or the SCG via the MAC CE.

[0228] On the other hand, when a child IAB node receives an RLF notification from an SCG, it stops UL transmission to the SCG if proposal 3 is accepted. This may actually be considered as a kind of SCG failure, and the child IAB node may expect the MCG to adapt the topology (e.g., change secondary nodes). However, depending on the IAB topology, if the BH link of the SCG fails, the MCG may not know that the BH link of the SCG is disconnected (at least temporarily) and may not be able to take appropriate action. Therefore, it should be considered whether the child node can notify the MCG when it receives an RLF notification from the SCG, e.g., via failure information or SCG failure information.

[0229] Proposal 10: RAN2 should discuss whether MT / UE is allowed to notify MCG when receiving RLF notification from SCG.

[0230] This application claims priority to U.S. Provisional Application No. 62 / 884,268, filed August 8, 2019, the entire contents of which are incorporated herein by reference.

Claims

1. A communication control method for use in a mobile communication system capable of forming at least one communication path using a plurality of relay devices between a user device and a donor device, comprising: a first relay device included in the plurality of relay devices performs dual-connection communication with a master node and a secondary node; receiving, by the first relay device, a first fault notification from the secondary node indicating an occurrence of a fault in a backhaul link; In response to receiving the first fault notification, the first relay device notifies the master node that a fault has occurred in the secondary node, and switches from a first communication path via the secondary node to a second communication path via the master node; receiving, by the first relay device, from the secondary node before the switching is completed, a recovery notification indicating that the node has recovered from the failure; the first relay device cancels switching from the first communication path to the second communication path in response to receiving the recovery notification. Communications control method.

2. The switching comprises: in response to receiving the first fault notification, stopping uplink transmission to the secondary node; switching from the first communication path to the second communication path when the secondary node does not recover from the failure until a certain time has elapsed since the uplink transmission was stopped. The communication control method according to claim 1 .

3. Stopping the uplink transmission includes suspending a data radio bearer corresponding to the secondary node while continuing to use a signaling radio bearer corresponding to the secondary node; The suspending step includes stopping use of the data radio bearer while maintaining the configuration of the data radio bearer. The communication control method according to claim 2.

4. A first relay device included in a plurality of relay devices in a mobile communication system capable of forming at least one communication path between a user device and a donor device, the first relay device comprising: A control unit that performs dual-connection communication with a master node and a secondary node; a receiving unit configured to receive a first fault notification from the secondary node, the first fault notification indicating an occurrence of a fault in a backhaul link; the control unit, in response to receiving the first fault notification, notifies the master node that a fault has occurred in the secondary node, and switches from a first communication path via the secondary node to a second communication path via the master node; the receiving unit receives, before the switching is completed, from the secondary node, a recovery notification indicating that the secondary node has recovered from the failure; The control unit cancels switching from the first communication path to the second communication path in response to receiving the recovery notification. First relay device.

5. A processor for controlling a first relay device included in a plurality of relay devices in a mobile communication system capable of forming at least one communication path between a user device and a donor device using the plurality of relay devices, the processor comprising: A process of performing dual connection communication with a master node and a secondary node; receiving a first fault notification from the secondary node indicating an occurrence of a fault in a backhaul link; In response to receiving the first failure notification, a process of notifying the master node that a failure has occurred in the secondary node and switching from a first communication path via the secondary node to a second communication path via the master node; receiving, before the switching is completed, from the secondary node a recovery notification indicating that the secondary node has recovered from the failure; In response to receiving the recovery notification, a process of canceling the switching from the first communication path to the second communication path is executed. Processor.

6. In a mobile communication system capable of forming at least one communication path using a plurality of relay devices between a user device and a donor device, a first relay device included in the plurality of relay devices is provided, A process of performing dual connection communication with a master node and a secondary node; receiving a first fault notification from the secondary node indicating an occurrence of a fault in a backhaul link; In response to receiving the first failure notification, a process of notifying the master node that a failure has occurred in the secondary node and switching from a first communication path via the secondary node to a second communication path via the master node; receiving, before the switching is completed, from the secondary node a recovery notification indicating that the secondary node has recovered from the failure; and in response to receiving the recovery notification, canceling the switching from the first communication path to the second communication path. program.

7. A mobile communication system capable of forming at least one communication path using a plurality of relay devices between a user device and a donor device, a first relay device included in the plurality of relay devices; The first relay device is Dual connection communication with the master node and secondary node is performed. receiving a first fault notification from the secondary node indicating an occurrence of a fault in a backhaul link; In response to receiving the first failure notification, notify the master node that a failure has occurred in the secondary node, and switch from a first communication path via the secondary node to a second communication path via the master node; receiving a recovery notification from the secondary node before the switch is completed, the recovery notification indicating that the secondary node has recovered from the failure; canceling the switching from the first communication path to the second communication path in response to receiving the recovery notification. Mobile communication system.

Images