Communication control method

Abstract

A communication control method according to an aspect of the present invention is used in a cellular communication system. The communication control method comprises receiving, by a relay node, a recovery attempt notice which is from a first parent node of the relay node and which indicates that the first parent node is trying to recover from a failure that has occurred in a backhaul link between the first parent node and a node that is a parent node of the first parent node. The communication control method further comprises transferring, by the relay node, a first packet received from the first parent node to a child node of the relay node in response to reception of the recovery attempt notice, and transferring, by the relay node, a second packet received from the child node to a second parent node which is a parent node of the relay node.

Description

Technical Field

[0001] The present disclosure relates to a communication control method executed by a relay node.

Background Art

[0002] In 3GPP (Third Generation Partnership Project), which is a standardization project for cellular communication systems, the introduction of a new relay node called an IAB (Integrated Access and Backhaul) node is being considered (see, for example, "3GPP TS 38.300 V16.4.0 (2020-12)"). One or more relay nodes are interposed in the communication between a base station and a user equipment and perform relaying for this communication.

Summary of the Invention

[0003] The communication control method according to the first aspect is a communication control method used in a cellular communication system. The communication control method includes the relay node receiving, from the first parent node, a recovery attempt notification indicating that the first parent node is attempting to recover from a failure that occurred in a backhaul link between the first parent node of the relay node and a node that is a further parent node of the first parent node. Further, the communication control method includes the relay node transferring, in response to receiving the recovery attempt notification, a first packet received from the first parent node to a child node of the relay node, and transferring a second packet received from the child node to a second parent node that is a parent node of the relay node.

[0004] The communication control method according to the second aspect is a communication control method used in a cellular communication system. The communication control method includes a relay node receiving, from the first parent node, a recovery attempt notification indicating that the first parent node is attempting to recover from a failure that occurred in a backhaul link between the relay node's parent node and the node that is the further parent node of the parent node. Further, the communication control method includes the relay node that has received the recovery attempt notification broadcasting system information that does not include an IAB support, which is an information element indicating that the cell of the relay node supports IAB and that the cell is a cell considered as a cell selection of an IAB node, when there is no alternative path to a donor node.

[0005] The communication control method according to the third aspect is a communication control method used in a cellular communication system. The communication control method includes a relay node receiving, from the parent node, a recovery attempt notification indicating that the parent node is attempting to recover from a failure that occurred in a backhaul link between the relay node's parent node and the node that is the further parent node of the parent node, and then not performing a predetermined transmission or receiving a setting to perform the predetermined transmission a predetermined number of times or less. Further, the communication control method includes the relay node, in response to receiving the recovery attempt notification, not performing the predetermined transmission or performing the predetermined transmission a predetermined number of times or less according to the setting. Here, the predetermined transmission is transmission of a scheduling request, a buffer status report, and / or a UL packet to the parent node.

[0006] The communication control method according to the fourth aspect is a communication control method used in a cellular communication system. The communication control method includes the relay node receiving, from the first parent node, a recovery attempt notification indicating that the first parent node is attempting to recover from a failure that occurred in a backhaul link between the first parent node of the relay node and a node that is a further parent node of the first parent node. Further, the communication control method includes the relay node transmitting, in response to receiving the recovery attempt notification, the fact that the recovery attempt notification has been received to a donor node via a second parent node that is a parent node of the relay node.

Brief Description of the Drawings

[0007]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

DETAILED DESCRIPTION OF THE INVENTION

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

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

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

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

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

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

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

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

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

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

[0018] The cellular communication system 1 supports IAB which enables wireless relaying of NR access using NR in the backhaul. The donor gNB (or donor node. Hereinafter, it may be referred to as the "donor node") 200-1 is a terminal node of the NR backhaul on the network side and is a donor base station equipped with an additional function for supporting IAB. The backhaul can be multi-hop via a plurality of hops (i.e., a plurality of IAB nodes 300).

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

[0020] UE100 is a mobile wireless communication device that performs wireless communication with a cell. UE100 can be any device as long as it can perform wireless communication with gNB200 or IAB node 300. For example, UE100 can be a mobile phone terminal, a tablet terminal, a notebook PC, a sensor or a device provided in a sensor, and / or a vehicle or a device provided in a vehicle. UE100 wirelessly connects to IAB node 300 or gNB200 via an access link. FIG. 1 shows an example where UE100 is wirelessly connected to IAB node 300-2. UE100 communicates indirectly with donor node 200-1 via IAB node 300-2 and IAB node 300-1.

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

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

[0023] An adjacent node (i.e., a higher-level node) on the NR Uu radio interface of IAB-MT is called a parent node. The parent node is the DU of the parent IAB node or donor node 200. The wireless link between IAB-MT and the parent node is called a backhaul link (BH link). FIG. 2 shows an example where the parent nodes of IAB node 300 are IAB nodes 300-P1 and 300-P2. Note that the direction towards the parent node is called upstream. From the perspective of UE100, the higher-level node of UE100 may correspond to the parent node.

[0024] An adjacent node (i.e., a lower node) on the NR access interface of the IAB-DU is called a child node. Similar to the gNB200, the IAB-DU manages cells. The IAB-DU terminates the NR Uu radio interface to the UE100 and the lower IAB nodes. The IAB-DU supports the F1 protocol to the CU of the donor node 200-1. In FIG. 2, an example is shown where the child nodes of the IAB node 300 are IAB nodes 300-C1 to 300-C3, but the UE100 may be included in the child nodes of the IAB node 300. Note that the direction towards the child node is called downstream.

[0025] Also, all IAB nodes 300 connected to the donor node 200 via one or more hops form a directed acyclic graph (DAG) topology (hereinafter sometimes referred to as the "topology") rooted at the donor node 200. In this topology, as shown in FIG. 2, adjacent nodes on the interface of the IAB-DU are child nodes, and adjacent nodes on the interface of the IAB-MT are parent nodes. The donor node 200 centrally performs, for example, resource, topology, and route management of the IAB topology. The donor node 200 is a gNB that provides network access to the UE100 via the network of the backhaul link and the access link.

[0026] (Configuration of the base station) Next, the configuration of the gNB200, which is a base station according to the embodiment, will be described. FIG. 3 is a diagram showing a configuration example of the gNB200. As shown in FIG. 3, the gNB200 includes a radio communication unit 210, a network communication unit 220, and a control unit 230.

[0027] The wireless communication unit 210 performs wireless communication with the UE 100 and wireless communication with the IAB node 300. The wireless communication unit 210 includes 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 (down-converts) the radio signal received by the antenna into a baseband signal (received signal), and outputs it 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 (up-converts) the baseband signal (transmitted signal) output by the control unit 230 into a radio signal, and transmits it from the antenna.

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

[0029] 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 for the processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals, etc. The CPU executes the programs stored in the memory to perform various processes. The processor performs the processing of each layer described later. Also, the control unit 230 may perform each process in the gNB 200 (or donor node 200) in each of the following embodiments.

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

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

[0032] The wireless communication unit 310 includes 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, converts (down-converts) the radio signal received by the antenna into a baseband signal (received signal), and outputs it 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, converts (up-converts) the baseband signal (transmitted signal) output by the control unit 320 into a radio signal, and transmits it from the antenna.

[0033] 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 for 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 the baseband signal, etc. The CPU executes the programs stored in the memory to perform various processes. The processor performs the processing of each layer described later. Also, in each of the following embodiments, the control unit 320 may perform each process in the IAB node 300. The control unit 320 may execute each function of the IAB-MT or IAB-DU in the IAB node 300.

[0034] (Configuration of the User Equipment) Next, the configuration of the UE100, which is a user equipment according to an embodiment, will be described. FIG. 5 is a diagram showing a configuration example of the UE100. As shown in FIG. 5, the UE100 includes a wireless communication unit 110 and a control unit 120.

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

[0036] The control unit 120 performs various controls in the UE100. The control unit 120 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs executed by the processor and information used for 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 the baseband signal, etc. The CPU executes the programs stored in the memory to perform various processes. The processor performs the processing of each layer described later. Also, the control unit 120 may perform each process in the UE100 in each of the following embodiments.

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

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

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

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

[0041] The RLC layer uses the functions of the MAC layer and the PHY layer to transmit data to the RLC layer on the receiving side. Between the RLC layer of the IAB-MT of the IAB node 300-2 and the RLC layer of the IAB-DU of the IAB node 300-1, data and control information are transmitted via a logical channel.

[0042] The PDCP layer performs header compression / expansion and encryption / decryption. Between the PDCP layer of the IAB-MT of the IAB node 300-2 and the PDCP layer of the donor node 200, data and control information are transmitted via radio bearers.

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

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

[0045] Figure 7 is a diagram showing a protocol stack related to the F1-U protocol. Figure 8 is a diagram showing a protocol stack related to the F1-C protocol. Here, an example is shown in which the donor node 200 is split into a CU and a DU.

[0046] As shown in Figure 7, each of the IAB-MT of the IAB node 300-2, the IAB-DU of the IAB node 300-1, the IAB-MT of the IAB node 300-1, and the DU of the donor node 200 has a BAP (Backhaul Adaptation Protocol) layer as the upper layer of the RLC layer. The BAP layer is a layer that performs routing processing and bearer mapping / demapping processing. In the backhaul, by transmitting the IP layer via the BAP layer, routing over multiple hops becomes possible.

[0047] In each backhaul link, the PDU (Protocol Data Unit) of the BAP layer is transmitted by the backhaul RLC channel (BH NR RLC channel). By configuring multiple backhaul RLC channels in each BH link, traffic prioritization and QoS (Quality of Service) control are possible. The association between the BAP PDU and the backhaul RLC channel is performed by the BAP layer of each IAB node 300 and the BAP layer of the donor node 200.

[0048] Note that the CU of the donor node 200 is the gNB-CU function of the donor node 200 that terminates the F1 interface to the DU of the IAB node 300 and the donor node 200. Also, the DU of the donor node 200 is the gNB-DU function of the donor node 200 that hosts the IAB BAP sublayer and provides a wireless backhaul to the IAB node 300.

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

[0050] Note that in the following, the processing or operations performed in the IAB-DU and IAB-MT of IAB may sometimes be simply described as the processing or operations of "IAB". For example, the IAB-DU of the IAB node 300-1 transmitting a message of the BAP layer to the IAB-MT of the IAB node 300-2 is described as the IAB node 300-1 transmitting the message to the IAB node 300-2. Also, the processing or operations in the DU or CU of the donor node 200 may sometimes be simply described as the processing or operations of the "donor node".

[0051] Also, the upstream direction and the uplink (UL) direction may be used without distinction. Furthermore, the downstream direction and the downlink (DL) direction may be used without distinction.

[0052] (First Embodiment) Next, the first embodiment will be described with appropriate reference to the drawings.

[0053] (Regarding Routing) One of the functions of the BAP layer is the packet routing function to the next hop. In the network formed by a plurality of IAB nodes 300, each IAB node 300 transfers the received packet to the next hop, and finally sends the packet to the destination IAB node 300 (or donor node 200). Routing is, for example, controlling which IAB node 300 to transfer the received packet to.

[0054] Packet routing is performed, for example, as follows. That is, the IAB-CU of the donor node 200 provides routing settings to the IAB-DU of each IAB node 300. The provided routing settings include a routing ID and the BAP address of the next hop. The routing ID is composed of the (destination) BAP address and the BAP path ID. When each IAB node 300 receives a packet (BAP packet), it reads out the destination BAP address included in the header of the packet. Each IAB node 300 determines whether the destination BAP address matches its own BAP address. When the destination BAP address matches its own BAP address, each IAB node 300 determines that the data packet has reached the destination. On the other hand, when the destination BAP address does not match its own BAP address, each IAB node 300 transfers the packet to the IAB node 300 with the BAP address of the next hop according to the routing settings.

[0055] In this way, each IAB node 300 transfers the received BAP packet to the next hop according to the routing settings set by the donor node 200.

[0056] (BH RLF Indication) In a network composed of a plurality of IAB nodes 300, a backhaul link between the IAB nodes 300 may experience a failure. Such a failure is referred to as "BH RLF (Backhaul Radio Link Failure)".

[0057] FIG. 9 is a diagram showing an example of BH RLF according to the first embodiment. In FIG. 9, an example is shown in which a BH RLF has occurred in a BH link #1 between the IAB node 300-P1, which is the parent node of the IAB node 300-T, and the node 500, which is its further parent node. Note that the node 500 is the parent node of the parent node 300-P1 or the gNB 200 (or donor node 200).

[0058] Assume that the IAB-MT of the parent node 300-P1 has detected a BH RLF. The IAB-DU of the parent node 300-P1 transmits a failure occurrence notification to the downstream IAB node 300-T.

[0059] A failure occurrence notification indicating that a BH RLF has been detected is called a Type1 BH RLF Indication. The BH link RLF detected by a child node (the parent node 300-P1 in the example of FIG. 9) may be a Type1 BH RLF Indication.

[0060] In addition, a recovery trial notification indicating that a recovery from a backhaul link failure (BH RLF) is being attempted is called a Type2 BH RLF Indication. A notification indicating that a child node (in the example of FIG. 9, the parent node 300-P1) is attempting to recover from a BH RLF is a Type2 BH RLF Indication. When not distinguishing between Type1 BH RLF Indication and Type2 BH RLF Indication, it is called Type1 / 2 BH RLF Indication. In each embodiment, mainly examples of Type2 BH RLF Indication are described, but Type2 BH RLF Indication may be read as Type1 BH RLF Indication. As described above, Type1 BH RLF Indication is transmitted at the time of BH RLF detection, and Type2 BH RLF Indication is transmitted at the time of recovery attempt. However, in the IAB node 300, immediately after BH RLF detection, a recovery attempt process for BH RLF is performed. Therefore, Type1 BH RLF Indication and Type2 BH RLF Indication are substantially the same notification.

[0061] Furthermore, there is also a recovery notification indicating that the BH link has recovered from a BH RLF. Such a recovery notification is called a Type3 BH RLF Indication. Furthermore, there is also a failure notification indicating that the recovery of the BH link from RLF has failed. Such a failure notification is called a Type4 BH RLF Indication.

[0062] In the example shown in FIG. 9, an example is shown in which the parent node 300-P1 transmits a Type2 BH RLF Indication to its child node, the IAB node 300-T. The IAB node 300-T that has received the Type2 BH RLF Indication can perform various controls. Details will be described later.

[0063] Note that in the following, Type2 BH RLF Indication may sometimes be referred to as Type2 Indication.

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

[0065] In a multi-hop network where a plurality of IAB nodes 300 transfer packets one after another, data packets can be transferred to the destination IAB node 300 (or donor node 200) via an alternative path. When a line failure occurs, transferring data packets using an alternative path may sometimes be referred to as local rerouting. Local rerouting is performed by selecting an alternative path while ignoring the routing settings set by the donor node 200. Alternatively, local rerouting may be performed by selecting an alternative path from among the alternative path candidates set by the donor node 200.

[0066] In the example shown in FIG. 9, IAB node 300-T represents an example where local rerouting is performed to the parent node 300-P2 on the alternative path. Note that the two parent nodes 300-P1 and 300-P2 are connected to the same donor node 200.

[0067] (Communication Control Method According to the First Embodiment) In the 3GPP RAN2 meeting, it was agreed that Type2 Indication may be used to trigger local rerouting.

[0068] As described above, the routing setting by the donor node 200 includes the BAP address of the next hop. Therefore, the IAB node 300 transfers the packet to the next hop according to the routing setting. However, when local routing is applied, the IAB node 300 may transfer all packets to an alternative path. For example, in the example of FIG. 9, the IAB node 300-T may transfer the packets received from the parent node 300-P1 and the packets received from the child node 300-C to the parent node 300-P2 by local routing. Or, when there are multiple child nodes 300-C, the IAB node 300-T may transfer the packets received from the parent node 300-P1 to another child node 300-C on the alternative path.

[0069] On the other hand, the fact that the IAB node 300-T has received a BH RLF Indication such as a Type1 BH RLF Indication or a Type2 BH RLF Indication means that a radio link failure has occurred in the BH link #1 between the parent node 300-P1 and the node 500. In this case, it is quite possible that the BH link between the parent node 300-P1 and the IAB node 300-T is normal. The first embodiment assumes that the BH link between the parent node 300-P1 and the IAB node 300-T is normal.

[0070] Therefore, in the first embodiment, the IAB node 300-T that has received the Type2 Indication from the parent node 300-P1 does not perform local routing for all packets, but performs local routing for the upstream direction of the IAB node 300-T. The IAB node 300-T performs normal routing set by the donor node 200 for the downstream direction.

[0071] Specifically, first, a relay node (for example, IAB node 300-T) receives a recovery attempt notification (for example, Type2 Indication) from a first parent node (for example, parent node 300-P1) indicating that the first parent node is attempting to recover from a failure that occurred in a backhaul link between the first parent node and a node (for example, node 500) that is a further parent node of the first parent node. Second, in response to receiving the recovery attempt notification, the relay node transfers a first packet received from the first parent node to a child node of the relay node (for example, child node 300-C), and transfers a second packet received from the child node to a second parent node (for example, parent node 300-P2) that is a parent node of the relay node. Alternatively, the relay node may check the destination BAP address included in the header of the received packet, and determine that it is the upstream direction if the BAP address matches the BAP address of a preset donor node, and determine that it is the downstream direction if they do not match.

[0072] Thereby, the IAB node 300-T performs local routing for upstream packet transmission and performs routing setting by the donor node 200 for downstream packet transmission. Therefore, the IAB node 300-T can appropriately perform transfer without the transfer destination of all packets to be transferred changing.

[0073] FIG. 10 is a diagram showing an operation example according to the first embodiment. The operation example will be described by appropriately using the configuration example shown in FIG. 9.

[0074] As shown in FIG. 10, in step S10, the IAB node 300-T starts processing.

[0075] In step S11, the IAB node 300-T receives a Type2 Indication from the parent node 300-P1.

[0076] In step S12, the IAB node 300-T performs local routing for packet transfer in the upstream direction and executes the routing setting (hereinafter sometimes referred to as "normal routing") set by the donor node 200 for packet transfer in the downstream direction.

[0077] Packets in the upstream direction include the upstream packets buffered in the IAB node 300-T and the packets newly received from the child node 300-C after receiving the Type 2 Indication. Specifically, it includes the packets waiting to be transmitted in the upstream direction existing in the IAB-MT of the IAB node 300-T and the packets received from the child node 300-C at the IAB-DU of the IAB node 300-T after receiving the Type 2 Indication. The IAB-MT (or BAP entity) of the IAB node 300-T performs local routing for the upstream packets, selects an alternative path, and transfers the packets to the parent node 300-P2 on the alternative path (different from the parent node 300-P1).

[0078] Also, packets in the downstream direction include the downstream packets buffered in the IAB node 300-T and the packets received from the parent node 300-P1 after receiving the Type 2 Indication. Specifically, it includes the downstream packets waiting to be transmitted existing in the IAB-DU of the IAB node 300-T and the packets received from the parent node 300-P1 at the IAB-MT of the IAB node 300-T after receiving the Type 2 Indication. The IAB-DU (or BAP entity) of the IAB node 300-T performs normal routing for the downstream packets and transfers the packets according to the routing setting.

[0079] In step S13, the IAB node 300-T determines whether it has received a Type 3 BH RLF Indication (hereinafter sometimes referred to as "Type 3 Indication") from the parent node 300-P1. As described above, the Type 3 Indication is a recovery notification indicating that recovery has been performed from the BH PLF.

[0080] In step S13, if the IAB node 300-T does not receive the Type 3 Indication (NO in step S13), it proceeds to step S12 and performs the process of S12 until it receives the Type 3 Indication. Step Perform the process of S12.

[0081] On the other hand, in step S13, if the IAB node 300-T receives the Type 3 Indication (YES in step S13), it performs the process of step S14.

[0082] In step S14, the IAB node 300-T stops executing local rerouting for packet transfer in the upstream direction. In this case, since the IAB node 300-T has received the Type 3 Indication from the parent node 300-P1, it stops local rerouting. Due to the stop of local rerouting, the IAB node 300-T transfers packets in the upstream direction to the parent node 300-P1.

[0083] Then, in step S15, the IAB node 300-T ends a series of processes.

[0084] (Second Embodiment) Next, the second embodiment will be described.

[0085] In the RAN2 meeting of 3GPP, it was agreed that Type 2 Indication may be used to trigger the deactivation of IAB-Support included in SIB (System Information Block) 1.

[0086] IAB-Support is one of the information elements included in SIB1. IAB-Support is an information element (IAB-Support IE) indicating that the cell of a relay node (e.g., IAB node 300-T) supports IAB and the cell is considered as a cell for cell selection of the IAB node. The UE100 or the child node 300-C that receives SIB1 including IAB-Support (IAB-Support IE) can know that the IAB node 300-T that transmitted the SIB1 supports IAB.

[0087] However, similar to the first embodiment, for example, in FIG. 9, assume that the IAB node 300-T receives a Type 2 Indication from its parent node 300-P1. In this case, if there is an alternative path from the IAB node 300-T to the donor node 200, it is possible to access the donor node 200 using the alternative path. On the other hand, if there is no alternative path from the IAB node 300-T to the donor node 200, the IAB node 300-T cannot access the donor node 200, and the child node 300-C or the UE100 may not be able to receive service provision from the network via the IAB node 300-T.

[0088] Therefore, in the second embodiment, the IAB node 300-T that receives a Type 2 Indication from the parent node 300-P1 broadcasts system information that does not include the information element IAB-Support (IAB-Support IE) when it does not have an alternative path to the donor node. On the other hand, the IAB node 300-T broadcasts system information including IAB-Support when it has an alternative path to the donor node 200.

[0089] Specifically, a relay node (for example, IAB node 300-T) receives, from a first parent node, a recovery attempt notification (for example, Type2 Indication) indicating that the first parent node is attempting to recover from a failure that occurred in a backhaul link between the relay node's parent node (for example, parent node 300-P1) and a node that is a further parent node of the parent node (for example, node 500). Second, when there is no alternative path to a donor node, the relay node that has received the recovery attempt notification broadcasts system information that does not include IAB support, which is an information element indicating that the cell of the relay node supports IAB and that the cell is a cell considered for cell selection of the IAB node.

[0090] Thereby, the child node 300-C or the UE 100 can appropriately determine whether it is possible to receive the IAB service from the IAB node 300-T.

[0091] FIG. 11 is a diagram illustrating an operation example according to the second embodiment. The operation example will be described by appropriately using the configuration example shown in FIG. 9.

[0092] As shown in FIG. 11, in step S20, the IAB node 300-T starts processing.

[0093] In step S21, the IAB node 300-T receives a Type2 Indication from the parent node 300-P1.

[0094] In step S22, the IAB node 300-T determines whether there is an alternative path to the donor node 200. For example, in FIG. 9, assume a case where dual connectivity (DC (Dual Connectivity)) is set with the parent node 300-P1 as the master node (or master cell group) and the parent node 300-P2 as the secondary node (or secondary cell group). In such a case, the IAB node 300-T can determine that there is an alternative path to the parent node 300-P2 as an alternative path to the parent node 300-P1. On the other hand, in the IAB node 300-T, when such dual connectivity is not set and it is in a single connection with the parent node 300-P1, there is no alternative path. Therefore, the IAB node 300-T may determine that there is an alternative path to the donor node 200 if the parent node 300-P2 is set as the secondary node by the DC setting, and may determine that there is no alternative path to the donor node 200 if the DC is not set.

[0095] Note that the DC setting is performed, for example, when the CU of the donor node 200 uses an RRC reconfiguration (RRC Reconfiguration) message for the IAB-MT of the IAB node 300-T.

[0096] In step S22, when the IAB node 300-T determines that there is no alternative path to the donor node 200 (NO in step S22), it performs the process of step S23.

[0097] In step S23, the IAB node 300-T removes the IAB support (IAB-Support IE), which is an information element, from SIB1. Then, the IAB node 300-T broadcasts the SIB1 that does not include the IAB support.

[0098] In step S24, the IAB node 300-T determines whether it has received a Type3 Indication from the parent node 300-P1.

[0099] In step S24, when the IAB node 300-T determines that it has not received a Type 3 Indication from the parent node 300-P1 (NO in step S24), it repeats the process of step S23 until it receives a Type 3 Indication.

[0100] On the other hand, in step S24, when the IAB node 300-T determines that it has received a Type 3 Indication from the parent node 300-P1 (YES in step S24), it performs the process of step S25.

[0101] In step S25, the IAB node 300-T sets the IAB support (IAB-Support IE), which is an information element, in SIB1. Then, the IAB node 300-T broadcasts SIB1 including the IAB support.

[0102] Then, in step S26, the IAB node 300-T ends a series of processes.

[0103] On the other hand, in step S22, when the IAB node 300-T determines that there is an alternative path to the donor node 200 (YES in step S22), it proceeds to the process of step S25 and repeats the above-described process. In this case, since there is an alternative path, the IAB node 300-T broadcasts SIB1 including the IAB support.

[0104] (Third Embodiment) Next, the third embodiment will be described.

[0105] (SR and BSR) The SR (Scheduling Request) and BSR (Buffer Status Report) according to the third embodiment will be described.

[0106] FIG. 12(A) is a diagram illustrating an example of an SR and a BSR according to the third embodiment. As shown in FIG. 12(A), the IAB-MT of the IAB node 300-T has a function of transmitting the data amount of the transmission buffer of each logical channel to the IAB-DU of the parent node 300-P using a BSR. The IAB-DU of the parent node 300-P allocates radio resources (UL resources) of the uplink radio link based on the BSR. The IAB-MT of the IAB node 300-T transmits data to the parent node 300-P using the UL resources.

[0107] In the BSR, the IAB node 300-T allocates a logical channel group (LCG) to each logical channel. Then, the IAB node 300-T notifies the parent node 300-P of the transmission buffer amount for each LCG as a BSR. Note that the BSR may be a pre-emptive BSR. While the BSR notifies the buffer amount of the transmission waiting packets actually staying in the IAB node 300-T, the pre-emptive BSR notifies the packet amount expected to reach the IAB node 300-T (that is, not actually buffered as transmission waiting packets yet).

[0108] The IAB node 300-T transmits the BSR using a PUSCH (Physical Uplink Shared Channel). However, when the PUSCH is not allocated when the IAB node 300-T transmits the BSR, the IAB node 300-T transmits an SR using a PUCCH (Physical Uplink Control Channel). When the PUCCH for transmitting the SR is not allocated to the IAB node 300-T, the IAB node 300-T transmits the SR using a PRACH (Physical Random Access Channel). The parent node 300-P allocates UL resources to the IAB node 300-T based on the SR, and the IAB node 300-T transmits data using the UL resources.

[0109] In the third embodiment, it is assumed that the IAB node 300-T can transmit the BSR and / or SR using the PUSCH and PUCCH.

[0110] (Communication control method according to the third embodiment) At the 3GPP RAN2 meeting, it was agreed that Type 2 Indication may be used to trigger deactivation or reduction of SR and / or BSR.

[0111] Deactivation means not performing transmission. The above agreement means that Type 2 may be used to trigger non-transmission (or non-occurrence of transmission) of SR and / or BSR. Indication Reduction means transmitting at a predetermined number of transmissions less than the original number of transmissions. The above agreement means that Type 2 Indication may be used to trigger transmission of SR and / or BSR at a predetermined number of transmissions or less.

[0112] FIG. 12(B) is a diagram showing an example of Type 2 Indication according to the third embodiment. As shown in FIG. 12(B), assume that the IAB node 300-T receives a Type 2 Indication from the parent node 300-P. Then, assume that the IAB node 300-T transmits an SR or BSR to the parent node 300-P and receives radio resource allocation from the parent node 300-P. In such a case, even if the IAB node 300-T transfers a packet to the parent node 300-P, the parent node 300-P cannot transfer the packet to the node 500 because an RLF has occurred. Therefore, the packet transfer from the IAB node 300-T to the parent node 300-P may be wasted.

[0113] Therefore, when the IAB node 300-T that has received the Type 2 Indication does not transmit the SR and / or BSR, or sets the number of transmissions to be equal to or less than a predetermined number of transmissions, such packet transfer will stop or become less frequent than normal. Therefore, it is effective for the IAB node 300-T that has received the Type 2 Indication not to transmit the SR and / or BSR, or to set the number of transmissions to be equal to or less than a predetermined number of transmissions.

[0114] In the case of reduction, although the SR and / or BSR are transmitted less than the predetermined number of transmissions, the number of transmissions itself is small compared to the original number of transmissions, so interference with other cells can be prevented. Also, in the case of deactivation, since no transmission is performed, interference with other cells can be further prevented.

[0115] On the other hand, in the case of deactivation, even when the BH RLF is resolved, the parent node 300-P transmits the Type 3 Indication to the IAB node 300-T and performs scheduling after receiving the SR and / or BSR from the IAB node 300-T. Therefore, a delay may occur compared to the case where the parent node 300-P performs scheduling immediately after the BH RLF is resolved. On the other hand, in the case of reduction, when the parent node 300-P receives the SR and / or BSR immediately after the BH RLF is resolved, the delay is less than in the case of deactivation.

[0116] In the third embodiment, when the IAB node 300-T receives the Type 2 Indication, the IAB node 300-T receives a setting as to whether to deactivate or reduce the transmission of the SR, BSR, and / or UL packets. Then, when the IAB node 300-T receives the Type 2 Indication, it deactivates or reduces the transmission of the SR, BSR, and / or UL packets according to the setting.

[0117] Specifically, first, when a relay node (for example, IAB node 300-T) receives a recovery attempt notification from a parent node indicating that the parent node (for example, parent node 300-P) is attempting to recover from a failure that occurred in a backhaul link between the parent node of the relay node and a node (for example, node 500) that is the further parent node of the parent node, it does not perform a predetermined transmission or receives a setting to perform the predetermined transmission a predetermined number of times or less. Second, in response to receiving the recovery attempt notification, the relay node, according to the setting, does not perform a predetermined transmission to the parent node or performs the predetermined transmission a predetermined number of times or less. The predetermined transmission is the transmission of SR, BSR, and / or UL packets. Hereinafter, the transmission of SR, BSR, and / or UL packets may be referred to as "predetermined transmission".

[0118] As a result, the IAB node 300-T stops transmitting packets to the parent node 300-P that is in the process of attempting to recover from the failure or transmits packets a predetermined number of times or less, so that unnecessary packet transmission can be suppressed. In addition, since the IAB node 300-T stops performing the predetermined transmission or performs the predetermined transmission a predetermined number of times or less, it can prevent interference with other cells as compared with normal transmission. Furthermore, when the reduction setting is performed, the IAB node 300-T has less delay than when the deactivation setting is performed.

[0119] FIG. 13 is a diagram showing an operation example according to the third embodiment.

[0120] As shown in FIG. 13, in step S30, the IAB node 300-T starts processing.

[0121] In step S31, the IAB node 300-T receives a setting as to whether a predetermined transmission should be deactivated or reduced when receiving a Type 2 Indication. First, this setting may be performed by the donor node 200. In this case, the IAB-CU of the donor node 200 performs this setting for the IAB-MT of the IAB node 300-T using an RRC message such as an RRC reconfiguration message. Second, this setting may be performed by the parent node 300-P. In this case, the IAB-DU of the parent node 300-P performs this setting for the IAB-MT of the IAB node 300-T using a MAC CE or a BAP Control PDU or the like.

[0122] In step S32, the IAB node 300-T receives a Type 2 Indication from the parent node 300-P.

[0123] In step S33, the IAB node 300-T deactivates or reduces a predetermined transmission according to the setting in step S31. In the case of deactivation, the IAB node 300-T may hold the triggered predetermined transmission in a pending state in the buffer. Or, in the case of deactivation, the IAB node 300-T may not trigger an SR, a BSR, and / or a UL packet.

[0124] In step S34, the IAB node 300-T determines whether it has received a Type 3 Indication from the parent node 300-P.

[0125] If, in step S34, the IAB node 300-T determines that it has not received a Type 3 Indication (NO in step S34), it proceeds to step S33 and repeats the process of step S33 until it receives a Type 3 Indication.

[0126] On the one hand, in step S34, if the IAB node 300-T determines that it has received a Type 3 Indication (YES in step S34), it proceeds to step S35.

[0127] In step S35, the IAB node 300-T performs a (re-)activation of a predetermined transmission or a normal transmission. A normal transmission means performing a predetermined transmission without reducing the number of transmissions. In the case of (re-)activation, the IAB node 300-T may read out and transmit the SR, BSR, and / or UL packets held in the buffer as a pending state from the buffer. That is, the IAB node 300-T transfers the triggered SR, BSR, and / or UL packets to the lower layer upon receiving the Type 3 Indication. Alternatively, in the case of (re-)activation, the IAB node 300-T may set the SR, BSR, and / or UL packets to a state where they can be triggered.

[0128] Then, in step S36, the IAB node 300-T ends the series of processes.

[0129] (Modification Example 1 of the Third Embodiment) In the third embodiment, an example was described in which when the IAB node 300-T receives a Type 2 Indication, a reduction is performed such that the number of transmissions of a predetermined transmission is less than or equal to a predetermined number of transmissions. In contrast, in modification example 1, an example of realizing the reduction by using a prohibit timer is presented.

[0130] Specifically, first, the relay node (for example, the IAB node 300-T) receives a setting of a prohibit timer value. Second, when the relay node receives a recovery attempt notification and performs a predetermined transmission with a number of transmissions less than or equal to a predetermined number of transmissions, it does not perform the predetermined transmission until the prohibit timer value expires, and when the prohibit timer value expires, it performs the predetermined transmission. Thereby, the relay node can perform a predetermined transmission with a number of transmissions less than or equal to a predetermined number of transmissions after receiving the recovery attempt notification.

[0131] FIG. 14 is a diagram showing an operation example according to Modification Example 1 of the third embodiment.

[0132] As shown in FIG. 14, in step S30, the IAB node 300-T starts processing.

[0133] In step S31, for the IAB node 300-T, a prohibited timer value for reducing a predetermined transmission when receiving a Type 2 Indication is set. First, the prohibited timer value may be set by the donor node 200. In this case, the donor node 200 may perform the setting by transmitting an RRC message such as an RRC reconfiguration message to the IAB node 300-T. Second, the prohibited timer value may be set by the parent node 300-P. In this case, the parent node 300-P may perform the setting by transmitting a MAC CE or a BAP Control PDU or the like to the IAB node 300-T.

[0134] In step S32, the IAB node 300-T receives a Type 2 Indication.

[0135] In step S33, the IAB node 300-T starts the prohibited timer.

[0136] In step S34, while the prohibited timer is running, the IAB node 300-T does not trigger SR, BSR, and / or UL packets. Or, the IAB node 300-T pends the transmission of SR, BSR, and / or UL packets. In this case, the IAB node 300-T may hold the pended SR, BSR, and / or UL packets in a buffer.

[0137] In step S35, the IAB node 300-T determines whether the prohibited timer has expired. Whether the prohibited timer has expired is determined by whether the prohibited timer has reached the prohibited timer value.

[0138] In step S35, if the IAB node 300-T determines that the prohibition timer has not expired (NO in step S35), it proceeds to step S34 and repeats the process of step S34 until it expires.

[0139] On the other hand, in step S35, if the IAB node 300-T determines that the prohibition timer has expired (YES in step S35), it performs the process of step S36.

[0140] In step S36, the IAB node 300-T permits the triggering of SR, BSR, and / or UL packets. In this case, the IAB node 300-T is permitted to perform a predetermined transmission and performs the predetermined transmission (at a predetermined timing). The IAB node 300-T may transmit the pending SR, BSR, and / or UL packets (at a predetermined timing).

[0141] In step S37, the IAB node 300-T restarts the prohibition timer. The IAB node 300-T may restart the prohibition timer at the timing when the prohibition timer expires, or may restart the prohibition timer when a predetermined transmission is performed.

[0142] In step S38, the IAB node 300-T determines whether it has received a Type3 Indication from the parent node 300-P. In step S38, if the IAB node 300-T determines that it has not received a Type3 Indication (NO in step S38), it transfers the process to step S34 and repeats the above-described process.

[0143] On the other hand, in step S38, if the IAB node 300-T determines that it has received a Type3 Indication (YES in step S38), it performs the process of step S39.

[0144] In step S39, the IAB node 300-T stops the prohibition timer.

[0145] Then, in step S40, the IAB node 300-T ends a series of processes.

[0146] In Modification 1, when the IAB node 300-T receives a Type 2 Indication, it starts a prohibition timer. While the prohibition timer is running, it does not perform SR, BSR, and / or UL packet transmissions. When the prohibition timer expires, it performs a predetermined transmission. Thereby, after receiving the Type 2 Indication, the IAB node 300-T can reduce the number of transmissions of a predetermined transmission and achieve a reduction for the predetermined transmission.

[0147] (Modification 2 of the Third Embodiment) In Modification 1 of the Third Embodiment, an example of using a prohibition timer to achieve a reduction for a predetermined transmission after receiving a Type 2 Indication was described. In contrast, in Modification 2 of the Third Embodiment, an example of using a counter to achieve a reduction for a predetermined transmission after receiving a Type 2 Indication is given.

[0148] Specifically, first, a relay node (for example, the IAB node 300-T) receives a setting of a counter value. Second, when the relay node receives a recovery attempt notification and performs a predetermined transmission with a number of transmissions less than or equal to a predetermined number, it does not perform the predetermined transmission until the transmission opportunity for the predetermined transmission reaches a counter threshold value, and when the transmission opportunity reaches the counter threshold value, it performs the predetermined transmission. Thereby, after receiving the recovery attempt notification, the relay node can perform a predetermined transmission with a number of transmissions less than or equal to a predetermined number.

[0149] FIG. 15 is a diagram showing an operation example according to Modification 2 of the Third Embodiment.

[0150] As shown in FIG. 15, in step S50, the IAB node 300-T starts processing.

[0151] In step S51, when the IAB node 300-T receives a Type 2 Indication, a counter threshold for reducing a predetermined transmission is set. First, the counter threshold may be set by the donor node 200. In this case, the donor node 200 may use an RRC message such as an RRC reconfiguration message to set the IAB node 300-T. Second, the counter threshold may be set by the parent node 300-P. In this case, the parent node 300-P may use a MAC CE or a BAP Control PDU, etc. to set the IAB node 300-T.

[0152] In step S52, the IAB node 300-T receives a Type 2 Indication from the parent node 300-P.

[0153] In step S53, the IAB node 300-T sets the counter value of the counter to "0".

[0154] In step S54, when an SR, BSR, and / or UL packet transmission opportunity occurs, the IAB node 300-T increments the counter value. That is, even when an SR, BSR, and / or UL packet transmission opportunity arrives, the IAB node 300-T does not perform a transmission and increments the counter value. Or Even when an SR, BSR, and / or UL packet transmission opportunity arrives, the IAB node 300-T does not perform a transmission and increments the counter value.

[0155] Note that the SR transmission opportunity is a predetermined timing of the PUCCH. The BSR transmission opportunity is a predetermined timing of the PUSCH. The UL packet transmission opportunity is also a predetermined timing of the PUSCH.

[0156] In step S55, the IAB node 300-T determines whether the counter value has reached the counter threshold. In step S55, when the IAB node 300-T determines that the counter value has not reached the counter threshold (NO in step S55), the process of step S54 is repeated until the counter value reaches the counter threshold.

[0157] On the other hand, in step S55, when the IAB node 300-T determines that the counter value has reached the counter threshold (YES in step S55), it performs the process of step S56.

[0158] In step S56, the IAB node 300-T performs a predetermined transmission at a transmission opportunity for the predetermined transmission.

[0159] In step S57, the IAB node 300-T sets the counter value to "0". For example, the IAB node 300-T may set the counter value to "0" when the counter value reaches the counter threshold, or may set the counter value to "0" when performing the predetermined transmission.

[0160] In step S58, the IAB node 300-T determines whether it has received a Type 3 Indication from the parent node 300-P. In step S58, when the IAB node 300-T determines that it has not received a Type 3 Indication from the parent node 300-P (NO in step S58), it transfers the process to step S54 and repeats the above-described process.

[0161] On the other hand, in step S58, when the IAB node 300-T determines that it has received a Type 3 Indication from the parent node 300-P (YES in step S58), it performs the process of step S59.

[0162] In step S59, the IAB node 300-T stops the counting operation of the counter.

[0163] Then, in step S60, the IAB node 300-T ends the series of processes. In Modification 2, when the IAB node 300-T receives a Type 2 Indication, it counts with the counter without performing a transmission at the transmission opportunity of the SR, BSR, and / or UL packet, and when the count Ta value reaches the count TaWhen the threshold is reached, transmission is performed at the transmission opportunity of a predetermined transmission. As a result, after receiving the Type 2 Indication, the IAB node 300-T can reduce the number of transmissions of the predetermined transmission and achieve a reduction for the predetermined transmission.

[0164] (Modification Example 3 of the Third Embodiment) In the third embodiment, when receiving the Type 2 Indication, the reduction in which the number of transmissions of the SR and / or BSR is set to be equal to or less than a predetermined number of transmissions has been described. In contrast, in Modification Example 3 of the third embodiment, this is an example in which the parent node 300-P that has transmitted the Type 2 Indication does not transmit a UL grant (UL grant) to the child node (IAB node 300-T) when receiving the SR and / or BSR due to reduction from the child node.

[0165] Specifically, first, when a relay node (for example, the IAB node 300-T) receives a recovery attempt notification from a parent node (for example, the parent node 300-P), it does not perform a predetermined transmission or receives a setting to perform the predetermined transmission equal to or less than a predetermined number of transmissions. Second, in response to receiving the recovery attempt notification, the relay node performs the predetermined transmission equal to or less than the predetermined number of transmissions according to the setting. Third, in response to the parent node receiving the scheduling request and / or the buffer status report equal to or less than a predetermined number of transmissions, the parent node does not transmit a UL grant to the relay node.

[0166] As a result, the relay node no longer transfers packets to the parent node that is attempting to recover from the BH RLF, and can perform appropriate transmission.

[0167] FIG. 16 is a diagram showing an operation example according to the third modification example of the third embodiment.

[0168] As shown in FIG. 16, in step S70, the IAB node 300-T starts processing.

[0169] In step S71, when the IAB node 300-T receives a Type 2 Indication, a reduction is set for the transmission of the SR and / or BSR. The setting itself may be performed by the donor node 200 or the parent node 300-P, similar to the third embodiment.

[0170] In step S72, the IAB node 300-T receives a Type 2 Indication from the parent node 300-P.

[0171] In step S73, the IAB node 300-T reduces the transmission of the SR and / or BSR according to the setting.

[0172] In step S74, even if the parent node 300-P receives the SR and / or BSR, it does not transmit a UL grant to the child node (IAB node 300-T) that has transmitted the SR and / or BSR.

[0173] In step S75, the parent node 300-P determines whether the BH RLF recovery has been successful. For example, the parent node 300-P may perform cell selection processing on the node on the BH link where the BH RLF has occurred, and determine based on whether a cell that satisfies the minimum radio quality for the node is found. If the parent node 300-P determines that the BH RLF recovery has not been successful (NO in step S75), it repeats the process of step S74 until successful.

[0174] On the other hand, if the parent node 300-P determines that the BH RLF recovery has been successful (YES in step S75), it performs the process of step S76.

[0175] In step S76, when the parent node 300-P receives the SR and / or BSR, it transmits a UL grant to the child node (IAB node 300-T). Note that the parent node 300-P may transmit a Type 3 Indication to the child node and then transmit a UL grant.

[0176] And in step S77, the parent node 300-P ends a series of processes.

[0177] (Other variations) In variation 3 of the third embodiment, an example was described in which after the parent node 300-P transmits a Type2 Indication to the child node (IAB node 300-T), the parent node 300-P does not transmit a UL grant to the child node even if it receives an SR and / or BSR from the child node. For example, the parent node 300-P may perform control not to transmit a UL grant to the child node (IAB node 300-T) even if it receives an SR and / or BSR from the child node after detecting BH RLF or during the recovery process, regardless of the BH RLF Indication.

[0178] (Fourth embodiment) Next, the fourth embodiment will be described.

[0179] In the fourth embodiment, an example is where the IAB node 300-T that has received a Type2 Indication transmits a notification indicating that it has received a Type2 Indication from the parent node 300-P1 to the donor node 200 via the parent node 300-P2.

[0180] FIG. 17 is a diagram showing a configuration example of an IAB network according to the fourth embodiment.

[0181] As described above, the donor node 200 centrally manages the resources, topology, route management, etc. of the IAB topology in the IAB network. For example, as shown in FIG. 17, assume that an RLF occurs on the BH link #1 between the parent node 300-P1 and its parent node, the node 500, and the parent node 300-P1 is attempting to recover from the BH RLF. In such a case, if the donor node 200 can grasp that the IAB node is in such a situation, it becomes possible to centrally manage the entire IAB node 300 under its control.

[0182] However, when the IAB node 300-T receives a Type 2 Indication from the parent node 300-P1 and notifies the parent node 300-P1 of the reception, since RLF has occurred on the BH link #1, the notification cannot reach the donor node 200.

[0183] On the other hand, for example, assume that in the IAB node 300-T, two paths, namely the parent node 300-P1 and the parent node 300-P2, are ensured by DC setting. In this case, the IAB node 300-T can send the notification to the donor node 200 via the parent node 300-P2.

[0184] That is, in the fourth embodiment, first, the relay node (for example, the IAB node 300-T) receives a recovery attempt notification from the first parent node indicating that the first parent node (for example, the parent node 300-P1) of the relay node is attempting to recover from a failure that occurred in the backhaul link between the first parent node and the node (for example, the node 500) that is the further parent node of the first parent node. Second, in response to receiving the recovery attempt notification, the relay node sends a message indicating that the relay node has received the recovery attempt notification from the first parent node to the donor node via the second parent node that is the parent node of the relay node. Thereby, it becomes possible for the relay node to send a message indicating that the relay node has received the recovery attempt notification from the first parent node to the donor node via the second parent node. Therefore, it becomes possible to contribute to centralized management by the donor node.

[0185] FIG. 18 is a diagram showing an operation example according to the fourth embodiment. In the operation example shown in FIG. 18, it is assumed that dual connectivity (DC) is set in the IAB node 300-T. For example, the CU of the donor node 200 sets the parent node 300-P1 as the MCG (Master Cell Group) and the parent node 300-P2 as the SCG (Secondary Cell Group) for the IAB-MT of the IAB node 300-T using an RRC message (for example, an RRC reconfiguration message).

[0186] As shown in FIG. 18, in step S90, the IAB node 300-T starts the process.

[0187] In step S91, the IAB node 300-T receives a Type 2 Indication from the parent node 300-P1. At this time, similar to the first embodiment, the IAB node 300-T may determine to perform local rerouting for a parent node 300-P2 different from the parent node 300-P1 (with respect to packet transfer in the upstream direction).

[0188] In step S92, the IAB node 300-T sends a notification indicating that it has received a Type 2 Indication from the parent node 300-P1 to the donor node 200 via another parent node 300-P2. The notification may indicate that, instead of (or in addition to) receiving the Type 2 Indication from the parent node 300-P1, it has determined to perform local rerouting (with respect to packet transfer in the upstream direction). The following may be included in the notification.

[0189] A1) Routing ID (or path ID) before local rerouting: For example, the routing ID is the routing ID set by the donor node 200 for the IAB node 300-T before the IAB node 300-T determines to perform local rerouting.

[0190] A2) Routing ID (or Path ID) after local routing: For example, after the IAB node 300-T determines to perform local routing, the routing ID is the routing ID set by the IAB node 300-T. The routing ID includes the BAP address and / or path ID of the parent node 300-P2 or the donor node. The IAB node 300-T generates the routing ID whose destination BAP address is the parent node 300-T itself and includes this in the notification. Alternatively, the donor node 200 may set an alternative path (or alternative routing ID) for the IAB node 300-T, and the IAB node 300-T may select the routing ID shown in A2) from the set alternative paths.

[0191] A3) Cell ID (or gNB ID, or BAP address) of the parent node 300-P1 that sent the Type2 Indication: For example, when the IAB node 300-T receives a packet containing the Type2 Indication, since the cell ID is included in the source of the packet, it is obtained and included in the notification.

[0192] A4) Cell ID (or gNB ID, or BAP address) of the parent node 300-P2 that is the local routing destination: For example, when setting up DC, the IAB node 300-T obtains the cell ID of the parent node 300-P2 including SCG through an RRC message or the like and uses this.

[0193] A5) Reason information (Cause) indicating "local routing due to receiving Type2 Indication" All or part of the above A1) to A5) may be included in the notification. The IAB-MT of the IAB node 300-T may send the RRC message including the notification to the CU of the donor node 200 via the parent node 300-P2 to send the notification.

[0194] In step S93, the donor node 200 performs routing of the packet destined for the IAB node 300-T. For example, the donor node 200 causes a packet destined for the IAB node 300-T or a downstream packet passing through the IAB node 300-T to be transmitted via an alternative path passing through the parent node 300-P2.

[0195] Then, in step S94, the IAB node 300-T ends a series of processes.

[0196] Note that the IAB node 300-T may send a notification indicating that it has received the Type 3 Indication from the parent node 300-P1 to the donor node 200 in response to the reception of the Type 3 Indication from the parent node 300-P1. Alternatively, a notification indicating that local routing has been stopped may be sent. In this case, the IAB node 300-T may send the notification to the donor node 200 via the parent node 300-P1, or may send it to the donor node via the parent node 300-P2.

[0197] (Other Embodiments) A program for causing a computer to execute each process performed by the UE 100, the gNB 200, or the IAB node 300 may be provided. The program may be recorded on a computer-readable medium. By using a computer-readable medium, it is possible to install the program on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.

[0198] Also, circuits for executing each process performed by the UE 100, the gNB 200, or the IAB node 300 may be integrated, and at least a part of the UE 100, the gNB 200, or the IAB node 300 may be configured as a semiconductor integrated circuit (chipset, SoC (System-on-a-chip)).

[0199] The above has described one embodiment in detail with reference to the drawings. However, the specific configuration is not limited to the above, and various design changes and the like can be made without departing from the gist. Also, within a non - conflicting range, it is possible to combine all or part of each embodiment.

[0200] This application claims the priority of U.S. Provisional Application No. 63 / 167,227 (filed on March 29, 2021), and all of its content is incorporated into the specification of this application.

[0201] (Appendix) (Introduction) The revised work item regarding the integrated access of NR and the expansion of the backhaul (eIAB) was approved at RAN#88e. Some of the objectives are as follows.

[0202] Enhanced topology adaptation: · Specification of the procedure for migrating donor - to - donor IAB nodes to enhance robustness and load distribution, including enhanced functions to reduce signaling load. · Specification of extended functions to reduce service interruption due to the migration of IAB nodes and the recovery of BH RLF. · Specification of enhancing topology redundancy, including support for CP / UP separation. Enhanced topology, routing, and transport functions: · Specification of extended functions to improve fairness across the topology, multi - hop delay, and congestion mitigation.

[0203] · In RAN2, discuss conditional handover, and start discussing conditional handover within the donor up to the migration of IAB nodes between donors advanced in RAN3. · RAN2 confirms the intention that the conditional handover of Rel - 16 is used by / can be used by IAB - MT (further examination is required to determine if changes are necessary). ·RAN2 assumes that the Rel-16 specification is the baseline for setting the default route, IP address, and the target path of the donor-internal conditional handover. ·RAN2 supports Type2 / 3 RLF Indication (further study is required for details). ·Local routing can be triggered using Type2 RLF Indication. ·Type2 RLF Indication can be used to trigger the deactivation of IAB supported in the SIB. ·Type2 RLF Indication can be used to trigger the deactivation or reduction of SR and / or BSR transmission. ·Local routing can be triggered by indicating per-hop flow control. Further study is required for details such as trigger information, trigger conditions, and the role of CU settings. ·RAN2 considers that the local routing of the DU between donors is within the scope.

[0204] This appendix describes various topics of the topology adaptation enhancement of Rel-17's eIAB. Specifically, it is the enhancement of the BH RLF Indication function, the enhancement of the conditional handover function, the enhancement of the local routing function, and several other function enhancements.

[0205] (Discussion) Enhancement of the BH RLF Indication function In the Rel-16 email discussion, four types of BH RLF notifications were discussed as shown in Figure 19.

[0206] Finally, only the Type 4 "recovery failure" was defined as the Rel-16 BH RLF Indication. As a result, the child IAB-MT can recognize the RLF on the BH link of the parent node and start the RLF recovery procedure.

[0207] Observation 1: Only the "recovery failure" of Type 4 is defined as the BH RLF Indication in Rel-16.

[0208] Regarding the enhancement of Rel-17 functions, RAN2 agreed to introduce the "attempting recovery" of Type 2 and the "BH link recovery" of Type 3.

[0209] · RAN2 that supports Type 2 / 3 RLF Indication (details require further consideration). · Using the Type 2 RLF Indication, local routing can be triggered. · The Type 2 RLF Indication can be used to trigger the deactivation of IAB supported in SIB. · The Type 2 RLF Indication can be used to trigger the deactivation or reduction of SR and / or BSR transmission.

[0210] Although one of the things that need to be discussed is whether / how to define the operation, RAN2 already agrees on three possible use cases for the new BH RLF Indication.

[0211] Regarding the trigger of local routing, since BH RLF occurs in UL from the perspective of the IAB node that receives the Type 2 BH RLF Indication, it can be regarded as triggering upstream local routing, that is, switching of the UL path. In other words, since the IAB node that receives the Type 2 BH RLF Indication can maintain a good BH link with the downstream node, downstream local routing is independent of the Type 2 BH RLF Indication. Therefore, it can be regarded as the operation of the IAB-MT that needs to be clearly defined.

[0212] Proposal 1: RAN2 should agree to specify that when the IAB-MT receives a Type 2 BH RLF Indication from the parent node, it triggers local routing in the upstream path.

[0213] Proposal 2: RAN2 should agree to specify that when the IAB-MT receives a Type 3 BH RLF Indication from the parent node, it stops local routing in the upstream path, i.e., returns to the configured "normal" routing.

[0214] Regarding the deactivation of the IAB-Support IE in SIB1, it can be regarded as the operation of the IAB-DU until it is widely implemented in Rel-16. Therefore, it may be sufficient to only specify it in Stage 2. Regarding the details of the operation, it is assumed that the IAB-DU may not remove the IAB-Support IE from SIB1 if there is still an alternative path to the donor. This needs to be clarified when the operation is specified.

[0215] Proposal 3: RAN2 should consider whether to remove the IAB-Support IE from SIB1 when the IAB-DU receives a Type 2 BH RLF Indication and there is no alternative path to the IAB donor, only in Stage 2.

[0216] According to the above RAN2 agreement, regardless of Proposal 3, if the IAB-Support IE does not exist in SIB1, the IAB-MT does not initiate the establishment of a connection to the parent node. One question is whether the UE is permitted to access the cell (parent node) even when the parent node is under BH RLF. This has an adverse impact on the user because the RRC setup request cannot reach the CU, i.e., the donor. To avoid this, for example, any of the following is considered: the cell prohibits access by the UE, stops the SSB, or broadcasts a Type 2 BH RLF Indication via SIB1. Similar to Proposal 3, if there is an alternative path to the donor for the IAB node, there is no need to remove the IAB support IE from SIB1.

[0217] Proposal 4: RAN2 needs to consider whether to prohibit the access of the UE in addition to the IAB-MT access when the IAB-DU receives a Type 2 BH RLF Indication and there is no alternative path to the IAB donor.

[0218] Regarding the deactivation or reduction of SR and / or BSR transmission, since it may be regarded as the operation of IAB-MT, it is necessary to clearly define it. Regarding deactivation or reduction, "deactivation" may be simpler from the perspective of the specification. However, since SR and / or BSR can only be transmitted after receiving Type 3, there may be a scheduling delay. On the other hand, with "reduction", scheduling may be resumed immediately after the BH link is restored. However, unnecessary interference will occur. Therefore, RAN2 needs to discuss whether to support "deactivation", "reduction", or both of SR and / or BSR. If both are supported, it needs to be configurable by the IAB donor. Furthermore, when "reduction" is supported, the method of reducing SR and / or BSR is unclear. There is also a possibility of reusing the concept of the prohibition timer, but further consideration is required at present.

[0219] Proposal 5: RAN2 should agree to specify that when the IAB-MT receives a Type 2 BH RLF Indication from the parent node, it deactivates or reduces SR and / or BSR transmission.

[0220] Proposal 6: RAN2 should agree to specify that when the IAB-MT receives a Type 3 BH RLF Indication from the parent node, it can resume the normal procedure of SR and / or BSR transmission.

[0221] Proposal 7: RAN2 needs to consider whether to support "deactivation", "reduction", or both (i.e., configurable) of SR and / or BSR when a Type 2 BH RLF Indication is received from the parent node.

[0222] Similar to the Type 4 BH RLF Indication in Rel-16, it is considered easy for the Type 2 and Type 3 BH RLF Indications to be transmitted via the BAP control PDU. However, in relation to Proposal 3 above, since there is no BAP layer in the UE, the UE cannot receive the BAP control PDU. Therefore, these BH RLF Indications may be broadcast via SIB1, and SIB1 may be encoded by the DU. Therefore, RAN2 needs to consider whether these are transmitted via the BAP control PDU or SIB1.

[0223] Proposal 8: RAN2 needs to discuss whether the Type 2 and Type 3 BH RLF Indications are transmitted via the BAP control PDU or SIB1.

[0224] (Enhanced Functionality of Conditional Handover) Conditional handover was introduced in Rel-16 to improve the robustness of mobility. In our understanding, conditional handover can be used for the defined Rel-16 IAB. RAN2#113-e reached the following agreement. Therefore, in addition to the Rel-16 conditional handover, it is worth considering the enhanced functionality of the conditional handover for eIAB. · In RAN2, discuss conditional handover and start discussions on conditional handover within the donor up to the migration of IAB nodes between donors as advanced in RAN3. · RAN2 confirms the intention that the Rel-16 conditional handover can be used for IAB-MT Do (Whether changes are needed requires further consideration). · RAN2 assumes that the Rel-16 specification is the baseline for setting the default route, IP address, and target path for conditional handover within the donor.

[0225] In the conditional handover of Rel-16, it is executed when the corresponding conditional handover event (A3 / A5) is satisfied, or when the selected cell is a candidate for conditional handover as a result of cell selection for RRC re-establishment. The following principles apply to conditional handover: · The configuration of conditional handover includes the configuration of candidate cells for conditional handover generated by the candidate gNB and the execution conditions generated by the source gNB. · The execution conditions are set with one or two trigger conditions (conditional handover events A3 / A5). Only a single RS Type is supported, and up to two different trigger quantities (RSRP and RSRQ, RSRP and SINR, etc.) can be set simultaneously to evaluate the execution conditions for conditional handover of a single candidate cell. After RLF is declared, the UE performs the following: · Remain in the RRC connected state. In the case of conditional handover, in the case of RLF of the source cell: · Select a suitable cell. If the selected cell is a candidate for conditional handover and the UE is configured such that the network attempts a conditional handover after RLF, the UE attempts to execute the conditional handover once. Otherwise, re-establishment is performed. · If a suitable cell is not found within a certain time after RLF is declared, enter the RRC idle state.

[0226] The conditional handover events A3 / A5 can be satisfied when the IAB node experiences BH RLF on the BH link. On the other hand, since the radio state of the BH link of the IAB node itself is good, these trigger conditions cannot be satisfied by RLF specific to the IAB, that is, RLF due to reception of BH RLF Indication (Type4). In this case, one of the desired operations is for the IAB node to execute a conditional handover when it receives a BH RLF Indication.

[0227] Observation 2: In the conditional handover of Rel-16, since the BH link between the IAB-MT and the parent node still remains and the recovery of the BH RLF of the parent node is in progress, even if it fails, it is not automatically triggered / executed by the conditional handover event A3 / A5 in the IAB-MT.

[0228] Therefore, in order to improve the topology adaptation of Rel-17 eIAB, it is valuable to explain the additional trigger conditions for conditional handover. At least the existing BH RLF Indication (i.e., Type4) is considered a promising candidate for the new trigger, but if introduced, it can be further debated whether conditional handover also needs to be executed when receiving Type2 Indication.

[0229] Proposal 9: RAN2 needs to discuss whether additional trigger conditions for conditional handover are defined, that is, at least when the IAB node receives the BH RLF Indication (Type4). Regarding If introduced, further consideration is needed on whether it can be applied to Type2.

[0230] If Proposal 9 is acceptable, although it does not depend on the conditional handover event A3 / A5, it is a kind of forced trigger by the BH RLF Indication, so all candidates for conditional handover (i.e., candidate cells) may be able to trigger conditional handover simultaneously.

[0231] According to the current specification, "when multiple NR cells are triggered by the execution of conditional reset, which one to select depends on the UE implementation. The UE selects one of the cells triggered for execution considering the beam and beam quality." This is mainly targeted at the UE.

[0232] Observation 3: In the conditional handover of Rel-16, when multiple candidate cells trigger the execution of conditional handover, which cell to select depends on the UE implementation.

[0233] Regarding the IAB-MT, since the overall topology goal can be effectively processed by the IAB donor described in RAN2#112-e, it is not always the best approach for the IAB-MT to select one of the triggered cells through an implementation according to local radio quality, etc. Therefore, RAN2 needs to consider how the execution of conditional handover of IAB donor control using additional trigger conditions functions as described in Proposal 9. For example, the IAB donor can set the priority information associated with the conditional handover candidates in the conditional handover setting. The IAB-MT needs to select the cell with the highest priority from all the triggered conditional handover candidates that meet a specific radio quality (such as the S criterion).

[0234] Proposal 10: When receiving a BH RLF Indication, RAN2 needs to consider whether the execution of conditional handover of IAB donor control is necessary as an additional extension function when all candidate cells trigger a conditional handover.

[0235] (Enhancement of Local Routing Function) In Rel-16, local routing is only permitted when a BH RLF occurs. Note: For example, data buffering in the transmission part of the BAP entity depends on the implementation until the RLC-AM entity receives an acknowledgement response. In the case of BH RLF, the transmission part of the BAP entity can reroute the BAP data PDU that has not been confirmed by the lower layer before the BH RLF to an alternative path.

[0236] In RAN2#113-e, the following agreement related to the enhancement of the local routing function was reached. · Local routing can be triggered using a Type2 RLF Indication. · Local routing can be triggered by indicating per-hop flow control. Further consideration is needed for details such as trigger information, trigger conditions, and the role of CU configuration. · RAN2 considers that donor - to - donor DU local routing is within the scope.

[0237] However, the details of local routing are still unclear, at least from the perspective of configuration. As agreed in RAN2#112 - e, for other cases in Rel - 17 (i.e., not limited to BH RLF), "RAN2 will discuss local routing regarding how it can address the overall topology goals, including the advantages for central route determination." Therefore, the Rel - 16 issues need to be considered from an objective perspective of the overall topology. Needless to say, the IAB donor, having complete knowledge and full control of the IAB topology, is the entity that processes the overall topology objectives.

[0238] Finding 4: The IAB donor is the most appropriate entity to ensure the overall topology objectives.

[0239] In Rel - 16 local routing, as long as the destinations are the same, which path is selected as an alternative path depends on the implementation of the IAB node. This means that local routing is based on local decisions and cannot be controlled from the perspective of the IAB donor. This may not be consistent with the overall topology objectives, especially when many local decisions occur and accumulate in the IAB topology.

[0240] Finding 5: In Rel - 16 local routing, which path is selected as an alternative path depends on the implementation of the IAB - MT.

[0241] Therefore, when local routing is extended beyond the case of BHR LF, the controllability of the IAB donor should become more important. It is easy for the IAB donor to set up an alternative path. Thereby, the IAB node needs to select an alternative path when performing local routing. Further consideration is needed for the modeling of the alternative path. For example, whether the alternative paths have the same routing ID or not.

[0242] Proposal 11: RAN2 needs to consider whether the IAB donor can configure the IAB node using an alternative path in addition to the Rel-16 routing configuration.

[0243] As another aspect of the controllability of the IAB donor, the IAB donor should consider being able to recognize local routing and start / stop local routing at the IAB node for the coexistence of local routing and the overall topology. For example, the IAB donor can consider whether the overall topology goal has been achieved based on which IAB nodes are currently performing local routing. If the IAB donor notices that the overall topology goal cannot be achieved, the IAB donor may instruct the IAB node to start / stop local routing, or the IAB donor may change the routing configuration of the entire IAB topology.

[0244] How to handle the overall topology goal with local routing depends on the implementation of the IAB donor, but the IAB donor may need the local decision information and controllability of the IAB node.

[0245] Proposal 12: RAN2 needs to consider whether the IAB node should notify the IAB donor when starting / stopping local routing.

[0246] Proposal 13: RAN2 needs to discuss whether the IAB donor can instruct the IAB node to start / stop local routing.

[0247] (Other function enhancements) (Enhancement of BH RLF recovery and cell (re)selection) In the RRC reestablishment procedure, the IAB-MT first executes the cell selection procedure to find a suitable cell. Potential issues were pointed out in Rel-16 in this cell selection procedure, such as the possibility that the IAB-MT may select a descendant node. Therefore, it was discussed in the email discussion.

[0248] As shown in Figure 20, five possible solutions were discussed and summarized along with the reporter's views.

[0249] The conclusion was that "no further action will be taken on this topic in Rel-16". This means that RAN2 agreed that "in Option 4: when there is no BH connection, RRC reestablishment fails, so nothing is needed". Option 4 was acceptable in the Rel-16 deployment scenario even if more time was required for BH RLF recovery because it was necessary to wait for the failure (expiration of T301) and finally move to the idle state.

[0250] Finding 6: In Rel-16, when an IAB node attempts an RRC reestablishment request for a descendant node, the IAB node has to wait for its failure and finally move to the idle state.

[0251] In Rel-17, from the perspective of Finding 6, cell (re)selection and RRC reestablishment may occur frequently. Therefore, sub-optimal operation, i.e., operation following Finding 4, will cause a significant performance degradation from the perspectives of the stability of the IAB topology and service continuity. Therefore, in order to optimize the operation of the IAB-MT during BH RLF recovery, as the reporter in the above email discussion stated, "this topic may be discussed again in Rel-17".

[0252] Proposal 14: RAN2 should agree that optimization of cell (re)selection is considered to avoid re-establishment to inappropriate nodes (e.g., descendant nodes).

[0253] Among the solutions identified excluding the above Option 4, a common concept can be considered that for the purpose of cell selection, the IAB-MT is provided in either a whitelist or a blacklist. For example, considering that topology changes may occur frequently in Rel-17 due to "mobility of inter-domain IAB nodes", the whitelist and blacklist have advantages and disadvantages depending on the topology and the location of the IAB node.

[0254] For example, for an IAB node near the IAB donor, that is, from the perspective of the top of the DAG topology, since the number of candidate nodes is small and in some cases there is only the IAB donor DU, it is more reasonable to provide a whitelist.

[0255] However, in another example which is the perspective from the bottom of the DAG topology for an IAB node far from the IAB donor, it may be necessary to include a huge number of candidate nodes in the whitelist. Instead, the blacklist has the advantage of less overhead as it includes, for example, only the downstream IAB nodes of the IAB node in question and in some cases only a few child IAB nodes.

[0256] One concern of the whitelist is that due to the nature of "mobility of inter-domain IAB nodes" in Rel-17, it may be necessary to include candidate IAB nodes belonging to different / adjacent IAB topologies, which may increase the size of the list. On the other hand, since it goes without saying that the downstream IAB nodes belong to the same IAB topology, the blacklist does not need to worry about this.

[0257] Finding 7: The whitelist and blacklist have advantages and disadvantages depending on the topology and location of the IAB node.

[0258] Therefore, when providing information to a child IAB node for cell selection purposes, it is desirable that the IAB donor (or parent IAB node) can select either a whitelist or a blacklist. Note that this information can be beneficially reused for cell reselection purposes.

[0259] Proposal 15: RAN2 should agree that a whitelist or a blacklist (i.e., a selection structure) is provided to the IAB-MT for cell selection purposes to avoid re-establishment to descendant nodes. Whether these lists can also be used in the cell reselection procedure requires further consideration.

[0260] If agreement can be reached on Proposal 15, the method of providing information, i.e., the whitelist or the blacklist, should be further considered. Option 1 assumes CHO configuration and some extensions may be required. Option 2 assumes additional Indication, such as Type 2 BH RLF Indication. Option 3 assumes providing information about the entire topology that is not in the existing configuration. Option 5 assumes OAM configuration, but as pointed out by the reporter, this is doubtful.

[0261] Considering again the Rel-17 assumption that when a topology change occurs, the parent IAB node or the IAB donor should provide the list to the child IAB node, the method of providing the whitelist / blacklist should be a dynamic method. Therefore, Option 5, i.e., OAM, should be excluded. Which method, i.e., which of Options 1, 2, or 3, should be the baseline for the extension requires further consideration.

[0262] Proposal 16: RAN2 should agree that the whitelist / blacklist is dynamically provided by the parent IAB node or the IAB donor whenever the topology changes. Details require further consideration.

[0263] (Expansion of Lossless Delivery) In the research stage of Rel-15, the issues of multi-hop RLC ARQ were discussed and captured in section 8.2.3 of the TR. In Rel-16, the protocol stack was defined for IAB with an RLC layer that is not separated. That is, in Rel-16, end-to-end ARQ was excluded and hop-by-hop ARQ was adopted.

[0264] Regarding hop-by-hop ARQ, issues in end-to-end reliability, i.e., lossless delivery in UL packets, were identified. As shown in Figure 21, three solutions were identified and evaluated.

[0265] In Rel-16, the first solution, "modification of the PDCP protocol / procedure", was not adopted because it would affect Rel-15 UEs.

[0266] The second solution, "rerouting of PDCP PDUs buffered at intermediate IAB nodes", was supported as an implementation option in the BAP layer. Furthermore, the BAP layer may perform "for example, data buffering in the transmission part of the BAP entity until the RLC-AM entity receives an acknowledgement, which is implementation-dependent". These BAP implementations were considered to avoid packet loss in "most" cases of the Rel-16 deployment scenario, i.e., when using fixed IAB nodes, but were not complete as shown in Figure 20, for example.

[0267] The third solution, "introduction of UL status delivery", was an agreed solution to ensure lossless delivery of UL data considering the evaluation results cited in Figure 20. The idea was to delay RLC ARQ to the UE and start it when PDCP data recovery at the UE is required. However, since fixed IAB nodes were assumed and it was considered rare for UL packets to be dropped due to topology changes, it was not specified in Rel-16.

[0268] Considering the assumptions of Rel-17, since UL packets will no longer be lost during topology changes that frequently occur in Rel-17, a third solution should be further considered. Therefore, in addition to the results captured in the TR, RAN2 should discuss an extended mechanism for ensuring lossless delivery within the L2 multi-hop network.

[0269] Proposal 17: RAN2 should agree to introduce a mechanism for ensuring lossless delivery under conditions where topology changes may frequently occur based on the solutions specified in TR38.874, i.e., some form of "UL status delivery".

[0270] Regarding the details of the third solution, i.e., "introduction of UL status delivery", as shown in Figure 22, two options, C-1 and C-2, were discussed in the email discussion.

[0271] Regarding C-1 above, it is assumed that it is necessary to define "confirmation" from the IAB donor in BAP or RRC for end-to-end signaling transfer via the multi-hop L2 network. Therefore, relatively high standard efforts will be required to define this option.

[0272] Regarding C-2 above, even if it is necessary to assume that OAM uses this option to configure all IAB nodes when it functions well in the IAB topology, when transmitting RLC ACK to the UE (or downstream IAB node), it ultimately depends on the IAB-DU implementation, so it is actually implementable for Rel-16 IAB nodes as well. Furthermore, assuming hop-by-hop feedback and no additional Control PDUs, it is simpler than C-1. Therefore, C-2 should be the Rel-17 extended baseline for lossless delivery of UL packets.

[0273] Solution C-2, which is the solution for "Introduction of UL Status Delivery", may become the Rel-17 extended baseline, and this is also implementable for Rel-16.

[0274] However, since Rel-17 should assume dynamic topology changes that cause UL packet loss, the Rel-17 extension will support C-2 as a standard support function. At least in the stage 2 specification, the overall mechanism based on C-2 should be described. Otherwise, in the 3GPP standard, lossless delivery is not guaranteed during the handover of IAB nodes. Furthermore, in stage 3, minor changes such as RLC and / or BAP are expected, but since they are regarded as the internal operation of IAB nodes, the details may not be specified.

[0275] Proposal 18: RAN2 should agree to specify the RLC ARQ mechanism for lossless delivery of UL packets in stage 2. This delays the transmission of ACK to the child node / UE before receiving ACK from the parent IAB node (i.e., C-2). Whether / how to specify it in stage 3 requires further consideration.

Claims

1. A communication control method used in a cellular communication system, when a relay node receives a recovery attempt notification from the parent node indicating that the parent node is attempting to recover from a failure that occurred in a backhaul link between the relay node's parent node and the node that is the further parent node of the parent node, the relay node either does not perform a predetermined transmission or receives a setting to perform the predetermined transmission a predetermined number of times or less; the relay node, in response to receiving the recovery attempt notification, performs the predetermined transmission either not at all or a predetermined number of times or less according to the setting; and the predetermined transmission is the transmission of a scheduling request, a buffer status report, and / or a UL (Uplink) packet to the parent node, Communication control method.

2. Further, it includes the relay node receiving a recovery notification from the parent node indicating that the relay node has recovered from the failure; performing the predetermined transmission includes the relay node performing the predetermined transmission without reducing the number of transmissions in response to receiving the recovery notification. The communication control method according to Claim 1.

3. Receiving the setting includes the relay node receiving a setting of a prohibited timer value; performing the predetermined transmission includes the relay node not performing the predetermined transmission until the prohibited timer value expires, and when the prohibited timer value expires, performing the predetermined transmission, thereby performing the predetermined transmission a predetermined number of times or less. The communication control method according to Claim 1.

4. Receiving the setting includes the relay node receiving a setting of a counter value; performing the predetermined transmission includes the relay node not performing the predetermined transmission until the transmission opportunity of the predetermined transmission reaches the counter value, and when the transmission opportunity reaches the counter value, performing the predetermined transmission, thereby performing the predetermined transmission a predetermined number of times or less. The communication control method according to Claim 1.

5. Further, it includes the parent node not transmitting a UL grant to the relay node in response to receiving the scheduling request and / or the buffer status report from the relay node a predetermined number of times or less. The communication control method according to Claim 1.

6. Further, it includes a donor node or the parent node performing the setting. The communication control method according to claim 1.

7. A relay node, a receiving unit that receives, from the parent node, a recovery attempt notification indicating that the parent node of the relay node is attempting to recover from a failure that occurred in a backhaul link between the parent node of the relay node and a node that is a further parent node of the parent node; a control unit that, when receiving the recovery attempt notification, receives a setting to not perform a predetermined transmission or to perform the predetermined transmission a predetermined number of times or less; a transmission unit that, in response to receiving the recovery attempt notification, does not perform the predetermined transmission or performs the predetermined transmission a predetermined number of times or less according to the setting, and the predetermined transmission is transmission of a scheduling request, a buffer status report, and / or a UL (Uplink) packet to the parent node, a relay node.

8. A processor that controls a relay node, a process of receiving, from the parent node, a recovery attempt notification indicating that the parent node of the relay node is attempting to recover from a failure that occurred in a backhaul link between the parent node of the relay node and a node that is a further parent node of the parent node; a process of receiving a setting to not perform a predetermined transmission or to perform the predetermined transmission a predetermined number of times or less when receiving the recovery attempt notification; a process of not performing the predetermined transmission or performing the predetermined transmission a predetermined number of times or less according to the setting in response to receiving the recovery attempt notification, and the predetermined transmission is transmission of a scheduling request, a buffer status report, and / or a UL (Uplink) packet to the parent node, a processor.

Images