COMMUNICATION CONTROL METHOD, FIRST DONOR NETWORK NODE, AND CELLULAR COMMUNICATION SYSTEM

Abstract

To provide a communication control method in which a first relay node having a second relay node performs handover from a first donor base station to a second donor base station together with the second relay node.SOLUTION: In a cellular communication system, a communication control method includes a first relay node 300-P, which has a second relay node 300-C subordinate thereto, performing handover from a first donor base station 200-S to a second donor base station 200-T together with the second relay node 300-C, and, upon completing the handover to the second donor base station 200-T, the first relay node 300-P transmitting a notification indicating completion of the handover to the second relay node 300-C.SELECTED DRAWING: Figure 9

Description

[Technical Field]

[0001] The present invention relates to a communication control method for use in a cellular communication system. [Background technology]

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

[0003] A communication control method according to a first aspect is a communication control method for use in a cellular communication system, the communication control method including: a first relay node having a second relay node subordinate thereto, performing a handover from a first donor base station to a second donor base station together with the second relay node; and, upon completion of the handover to the second donor base station, transmitting a notification to the second relay node indicating completion of the handover.

[0004] A communication control method according to a second aspect is a communication control method for use in a cellular communication system, the communication control method including: a first relay node having a second relay node subordinate thereto, performing a handover from a first donor base station to a second donor base station together with the second relay node; and, when the first relay node completes the handover to the second donor base station, transmitting a first access message for the second donor base station received from the second relay node to the second donor base station. [Brief explanation of the drawings]

[0005] [Figure 1] FIG. 1 is a diagram showing an example of the configuration of a cellular communication system according to an embodiment. [Figure 2] FIG. 2 is a diagram showing the relationship between IAB nodes, parent nodes, and child nodes. [Figure 3] FIG. 3 is a diagram illustrating an example configuration of a gNB (base station) according to an embodiment. [Figure 4] FIG. 4 is a diagram illustrating an example of the configuration of an IAB node (relay node) according to an embodiment. [Figure 5] FIG. 5 is a diagram illustrating an example of the configuration of a UE (user equipment) according to an embodiment. [Figure 6] FIG. 6 is a diagram illustrating an example of a protocol stack related to an RRC connection and a NAS connection of an IAB-MT. [Figure 7] FIG. 7 is a diagram illustrating an example of a protocol stack for the F1-U protocol. [Figure 8] FIG. 8 is a diagram illustrating an example of a protocol stack for the F1-C protocol. [Figure 9] FIG. 9 illustrates an example of handover. [Figure 10] FIG. 10 is a diagram illustrating an example of operation of the first embodiment. [Figure 11] FIG. 11 is a diagram illustrating an example of operation of the second embodiment. [Figure 12] FIG. 12 is a diagram illustrating an example of operation of the third embodiment. [Figure 13] FIG. 13 is a diagram illustrating an example of operation of the fourth embodiment. [Figure 14] FIG. 14 is a diagram illustrating an example of the operation of the fifth embodiment. [Figure 15] FIG. 15 is a diagram illustrating types of BH RLF notifications. [Figure 16] FIG. 16 illustrates extended BH RLF indication transmission options. [Figure 17] FIG. 17 illustrates the identified solution to avoid re-establishment on descendant nodes. [Figure 18] FIG. 18 illustrates a comparison of mechanisms for lossless delivery of UL data in the case of hop-by-hop RLCARQ. [Figure 19] FIG. 19 illustrates the "C) Introduction of UL Status Distribution" option. [Figure 20] FIG. 20 illustrates RAN2 signaling issues that may arise with IAB node movement between donors. DETAILED DESCRIPTION OF THE INVENTION

[0006] 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.

[0007] (Configuration of a 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 applied at least partially to the cellular communication system 1. Furthermore, the cellular communication system 1 may also apply future cellular communication systems such as 6G.

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

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

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

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

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

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

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

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

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

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

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

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

[0020] 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.

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

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

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

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

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

[0026] The control unit 230 performs various controls in the gNB 200. The control unit 230 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs executed by the processor and information used in processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation / demodulation, encoding / decoding, etc. of baseband signals. The CPU executes programs stored in the memory to perform various processes. The processor performs processing of each layer, which will be described later. Furthermore, the control unit 230 may be configured to perform each process in the gNB 200 in each of the embodiments shown below.

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

[0028] 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.

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

[0030] The control unit 320 performs various controls in the IAB node 300. The control unit 320 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs executed by the processor and information used in processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processes. The processor performs processing of each layer, which will be described later. Furthermore, the control unit 320 may perform each process in the IAB node 300 in each of the embodiments shown below.

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

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

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

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

[0035] As shown in FIG. 6, the IAB-MT of IAB node 300-2 has a physical (PHY) layer, a medium access control (MAC) layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, a radio resource control (RRC) layer, and a non-access stratum (NAS) layer.

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

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

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

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

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

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

[0042] Figure 7 shows a protocol stack for the F1-U protocol. Figure 8 shows a protocol stack for the F1-C protocol. Here, an example is shown in which the donor gNB 200 is divided into a CU and a DU.

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

[0044] In each backhaul link, BAP layer PDUs (Protocol Data Units) are transmitted via a backhaul RLC channel (BH NR RLC channel). Configuring multiple backhaul RLC channels in each BH link enables traffic prioritization and Quality of Service (QoS) control. The association between BAP PDUs and backhaul RLC channels is performed by the BAP layer of each IAB node 300 and the BAP layer of the donor gNB 200.

[0045] As shown in FIG. 8, the protocol stack of the F1-C protocol has an F1AP layer and an SCTP (Stream Control Transmission Protocol) layer instead of the GTP-U layer and UDP layer shown in FIG.

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

[0047] (First embodiment) In the first embodiment, an example will be described in which an IAB node 300 performs a handover between donor gNBs 200. Here, handover refers to, for example, an operation in which an IAB-MT in an RRC connected state switches a connection to a cell. The first embodiment is an embodiment that realizes a handover of an IAB node 300 between donor gNBs 200. Such a handover may be called an inter-donor IAB node handover (or inter-donor IAB node migration).

[0048] FIG. 9 is a diagram showing an example of handover (or migration; hereinafter, sometimes referred to as "handover") performed in the first embodiment.

[0049] As shown in FIG. 9, under the control of a source donor gNB 200-S, the donor gNB 200-S and an IAB node 300-P are connected as a backhaul link. Also, under the control of an IAB node 300-P, the IAB node 300-P and an IAB node 300-C are connected as a backhaul link. Here, the IAB node 300-P may be called a "parent node" (or upper node), and the IAB node 300-C may be called a "child node" (or lower node). Note that the IAB node 300-C may be a UE 100.

[0050] In such a configuration, consider the case where the parent node, IAB node 300-P, performs a handover from a source donor gNB (hereinafter sometimes referred to as the "source donor") 200-S to a target donor gNB (hereinafter sometimes referred to as the "target donor") 200-T.

[0051] In this case, the child node IAB node 300-C also performs handover together with the parent node IAB node 300-P. By performing handover together, the topology between the IAB nodes 300-P and 300-C is maintained.

[0052] However, the IAB node 300-C may not know when the parent node, the IAB node 300-P, has completed the handover. This will be described in detail later. Therefore, the IAB node 300-C may attempt to access the target donor 200-T via the IAB node 300-P before the parent node, the IAB node 300-P, has completed the handover to the target donor 200-T. In this case, the IAB node 300-C's access to the target donor 200-T fails because the handover to the target donor 200-T in the IAB node 300-P has not yet completed.

[0053] Therefore, in the first embodiment, when the IAB node 300-P completes the handover from the source donor 200-S to the target donor 200-T, it notifies the IAB node 300-C, which is a child node.

[0054] Specifically, first, a first relay node having a second relay node subordinate thereto performs a handover from the first donor base station to the second donor base station together with the second relay node, and second, when the first relay node completes the handover to the second donor base station, it transmits a notification indicating that the handover has been completed to the second relay node.

[0055] This allows the IAB node 300-C to know that the handover of the parent node, the IAB node 300-P, has been completed, and even if the IAB node 300-C starts accessing the target donor 200-T, it can succeed.

[0056] FIG. 10 is a diagram illustrating an example of operation in the first embodiment.

[0057] 10, for example, "Source donor" is the source donor 200-S, and "Target donor" is the target donor 200-T. Also, in FIG. 10, for example, "Parent node" is the IAB node 300-P, and "Child node" is the IAB node 300-C. Hereinafter, the "Parent node" may be referred to as the upper node 300-P, and the "Child node" may be referred to as the lower node 300-C. Note that the lower node 300-C may be the UE 100 instead of the IAB node.

[0058] 10, before the process is started, the source donor 200-S and the upper node 300-P are in an RRC connected state, and the source donor 200-S and the lower node 300-C are also in an RRC connected state. In other embodiments described below, the same state is assumed before the process is started.

[0059] In step S110, the source donor 200-S sends a handover request (HO Request) message to the target donor 200-T.

[0060] In step S111, the target donor 200-T transmits a handover request acknowledgement (HO Request Ack) message, which is an acknowledgement to the handover request, to the source donor 200-S.

[0061] In step S112, the source donor 200-S transmits a handover command (HO Command) message to the lower node 300-C. The handover command message is, for example, a message instructing handover from the source donor 200-S to the target donor 200-T. The handover command message is a type of RRC Reconfiguration. The handover command message is transmitted to the lower node 300-C via the upper node 300-P.

[0062] Here, the handover command message may include an indicator instructing that access to the target donor 200-T be suspended. An example of such an indicator is "access suspend" as shown in FIG. 10. Instead of the indicator, setting information indicating that access to the target donor 200-T is suspended may be included. By receiving a handover command message including such an indicator or setting information, the lower node 300-C becomes able to suspend access to the target donor 200-T.

[0063] In step S113, the source donor 200-S transmits a handover command message to the upper node 300-P. Here, the handover command message may include a setting indicating whether or not to notify the lower node 300-C when the handover is completed. Such a setting may be made, for example, by the above-mentioned setting information or indicator.

[0064] In step S114, the upper node 300-P executes handover from the source donor 200-S to the target donor 200-T and starts access to the target donor 200-T. That is, the upper node 300-P transmits an RRC reconfiguration complete message to the target donor 200-T. The RRC reconfiguration complete message may be an access message or an access signal to the target donor 200-T.

[0065] If the upper node 300-P has successfully accessed the target donor 200-T, in step S115, the upper node 300-P notifies the lower node 300-C that the access has been successful. Such notification may be made by a BAP Control PDU and / or an SIB (System Information Block) 1. Alternatively, this notification may be a notification indicating that the upper node 300-P has completed handover to the target donor 200-T. Alternatively, this notification may be a notification indicating permission to start accessing the target donor 200-T.

[0066] If the upper node 300-P fails to access the target donor 200-T (i.e., HOF (Handover Failure)), it may transmit a notification indicating the access failure to the lower node 300-C. In this case, the lower node 300-C may receive this notification and discard the received handover command message (step S112). Furthermore, the upper node 300-P or the lower node 300-C may transmit a notification indicating the access failure to the source donor 200-S. The notification may include information (Cause) indicating that the access failure by the upper node 300-P is the cause. Upon receiving this notification, the source donor 200-S may recognize that the upper node 300-P's access to the target donor 200-T has failed, and may cancel the handover process of the upper node 300-P and / or the lower node 300-C. For example, the source donor 200-S may cancel the handover command. Alternatively, the source donor 200-S may send a notification of handover cancellation to the target donor 200-T.

[0067] In step S116, the lower node 300-C starts accessing the target donor 200-T. That is, the lower node 300-C transmits an RRC reconfiguration completion message to the target donor 200-T. This message is forwarded by the upper node 300-P and transmitted to the target donor 200-T.

[0068] For example, if the lower node 300-C does not receive a notification (step S115) from the upper node 300-P, it is not possible to know at what timing the handover of the upper node 300-P has been completed. Therefore, the lower node 300-C may transmit an RRC reconfiguration completion message before step S114 shown in Fig. 10 (or before the handover of the upper node 300-P is completed). In this case, the upper node 300-P has not yet completed the handover to the target donor 200-T, and therefore the RRC reconfiguration completion message transmitted from the lower node 300-C does not reach the target donor 200-T.

[0069] In the first embodiment, as described above, the lower node 300-C suspends access to the target donor 200-T in step S112, and can grasp the completion of handover by the upper node 300-P in step S115. Therefore, the lower node 300-C accesses the target donor 200-T after the upper node 300-P completes handover, and therefore becomes able to access the target donor 200-T.

[0070] (Second embodiment) In the first embodiment, an example of handover using a handover command message has been described. In the second embodiment, an example of a conditional handover is described. In the second embodiment, too, when the handover process of the upper node 300-P is completed, the lower node 300-C starts accessing the target donor 200-T.

[0071] Here, a description will be given of a conditional handover. A conditional handover is a handover that is executed when one or more handover execution conditions (or trigger conditions) are satisfied. The conditional handover configuration includes a configuration for a conditional handover candidate cell and a trigger condition. The conditional handover configuration may include a plurality of combinations of a configuration for a candidate cell and a trigger condition.

[0072] In a typical handover, UE100 reports measurements of the radio conditions of the serving cell and / or neighboring cells to gNB200, and based on this report, gNB200 decides to handover to the neighboring cell and transmits a handover command to UE100. Therefore, if the radio conditions of the serving cell suddenly deteriorate, a typical handover may result in communication being interrupted before the handover is executed. In contrast, a conditional handover can autonomously execute a handover to a candidate cell corresponding to a preset trigger condition when the trigger condition is met. This solves problems such as communication interruption that occur in a typical handover.

[0073] FIG. 11 is a diagram showing an example of operation in the second embodiment.

[0074] Steps S110 and S111 are the same as those in the first embodiment.

[0075] In step S120, the source donor 200-S configures the lower node 300-C for a conditional handover. In the example of FIG. 11, the source donor 200-S transmits an RRC Reconfiguration message including configuration information for the conditional handover to the lower node 300-C. The configuration information for the conditional handover includes a trigger condition of "when an upper node completes handover." That is, the lower node 300-C executes its own handover when the upper node 300-P completes handover as the trigger condition. Alternatively, the trigger condition may include "when a notification is received from an upper node." That is, the lower node 300-C executes its own handover when the upper node 300-P receives a notification from the upper node 300-P as the trigger condition. In addition, in executing the conditional handover based on the trigger condition, the lower node 300-C should select a cell managed by the upper node 300-P as a target. Alternatively, the subordinate node 300-C should select the same cell as the current serving cell, which allows access to the target donor 200-T while maintaining the relationship between the subordinate node 300-P and the subordinate node 300-C.

[0076] In step S113, the source donor 200-S transmits a handover command message to the upper node 300-P.

[0077] In step S114, the upper node 300-P executes the handover, sends an RRC reconfiguration complete message, and starts accessing the target donor 200-T.

[0078] In step S115, the upper node 300-P notifies the lower node 300-C. The example in Fig. 11 is the same notification as in the first embodiment. Such a notification may be a notification indicating that the handover has been completed, or a notification indicating permission to start accessing the target donor 200-T.

[0079] In step S116, the lower node 300-C starts accessing the target donor 200-T in accordance with the conditional handover setting (or trigger condition) received in step S120. The trigger condition in this case includes, for example, "when the upper node completes handover." The notification in step S115 satisfies the trigger condition "when the upper node completes handover." Therefore, the lower node 300-C transmits an RRC reconfiguration completion message to the target donor 200-T. The RRC reconfiguration completion message is forwarded by the upper node 300-P and transmitted to the target donor 200-T.

[0080] As described above, even when a conditional handover is performed, the lower node 300-C can recognize the completion of handover in the upper node 300-P by receiving a notification of handover completion, etc. from the upper node 300-P. This allows the lower node 300-C to access the target donor 200-T, for example, as in the first embodiment.

[0081] (Third embodiment) In the first and second embodiments, the lower node 300-C can know that the upper node 300-P has completed the handover by receiving a notification from the upper node 300-P indicating the completion of the handover (step S115 in FIG. 10 or FIG. 11).

[0082] However, there are cases where the lower node 300-C cannot receive such a notification. For example, there are the following cases. That is, when the lower node 300-C is a UE 100 that complies with 3GPP "Release 17," it can receive such a notification. However, when the UE 100 complies with "Release 15" or "Release 16," it cannot receive such a notification.

[0083] Therefore, in the third embodiment, even if the lower node 300-C cannot receive notification from the upper node 300-P, the lower node 300-C can access the target donor 200-T.

[0084] Specifically, first, a first relay node having a second relay node subordinate thereto performs a handover from the first donor base station to the second donor base station together with the second relay node. Second, when the first relay node completes the handover to the second donor base station, it transmits the access message to the second donor base station received from the second relay node to the second donor base station.

[0085] FIG. 12 is a diagram illustrating an example of operation in the third embodiment.

[0086] Steps S130 and S131 are the same as steps S110 and S111 in the first and second embodiments, respectively.

[0087] In step S132, the source donor 200-S transmits a handover command message to the subordinate node 300-C. The message is transmitted to the subordinate node 300-C via the superior node 300-P.

[0088] Here, in step S133, the source donor 200-S may transmit to the upper node 300-P a notification indicating that a handover command message has been transmitted to the lower node 300-C ("indication" in FIG. 12). The notification to the upper node 300-P may simply instruct the upper node 300-P to enter a transfer suspend mode. In this case, the upper node 300-P receives this notification and enters a transfer suspend mode ("Suspend mode"). The notification in step S133 may be transmitted before step S132. In this case, the notification to the upper node 300-P may indicate that a handover command message will soon be transmitted to the lower node 300-C, or may simply instruct the upper node 300-P to enter a transfer suspend mode.

[0089] In step S134, the source donor 200-S transmits a handover command message to the upper node 300-P. Note that, if the notification in step S133 has been received, this step S134 may be performed after entering the transfer hold mode. This handover message may include the notification in step S133. In this case, step S133 may be omitted.

[0090] In step S135, the upper node 300-P enters a transfer hold mode upon receiving the handover command from the source donor 200-S.

[0091] In the transfer hold mode, the upper node 300-P holds the transfer of the RRC message transmitted from the lower node 300-C (or stops the transmission of the RRC message transmitted from the lower node 300-C). Therefore, the upper node 300-P can hold the RRC reconfiguration complete message transmitted from the lower node 300-C.

[0092] There are two methods for suspending an RRC message, for example:

[0093] Method 1: Suspend (or stop transmission of) a specific BH RLC channel. However, this is on the condition that the source donor 200-S has configured the SRB (Signaling Radio Bearer) of the lower node 300-C to map to the BH RLC channel to be suspended. To perform such mapping, the source donor 200-S may transmit information about the specific BH RLC channel to be suspended to the upper node 300-P. The upper node 300-P can identify the RRC message by decoding the packet transmitted from the lower node 300-C and suspend the RRC message.

[0094] Method 2: Suspend all upstream packet transfers. In this case, the upper node 300-P suspends all upstream BH RLC channels. In other words, by suspending all SRBs and DRBs (Data Radio Bearers), the upper node 300-P can withhold the RRC reconfiguration completion message from the lower node 300-C.

[0095] In step S136, the upper node 300-P suspends the transfer of the RRC reconfiguration completion message transmitted from the lower node 300-C in the transfer suspension mode due to the suspension described above.

[0096] In step S137, the upper node 300-P executes the handover, transmits an RRC reconfiguration completion message, and starts accessing the target donor 200-T.

[0097] In step S138, the upper node 300-P transitions from the transfer hold mode to the normal mode ("Normal mode") due to the completion of the handover.

[0098] Since the upper node 300-P has transitioned to the normal mode, in step S139, the upper node 300-P transmits the RRC reconfiguration completion message that was suspended and was transmitted from the lower node 300-C to the target donor 200-T.

[0099] (Fourth embodiment) The fourth embodiment is an example in which a group handover is performed. Fig. 13 is a diagram showing an example of operation in the fourth embodiment. Fig. 13 shows the following configuration example.

[0100] That is, two subordinate nodes 300-C1 and 300-C2 each establish a BH link with one upper node 300-P, and are in an RRC connected state. A group handover is, for example, a handover from a source donor 200-S to a target donor 200-T for one upper node 300-P and multiple subordinate nodes 300-C1 and 300-C2. FIG. 13 shows an example in which two subordinate nodes 300-C1 and 300-C2 exist. The multiple subordinate nodes 300-C1 and 300-C2 may be called a subordinate node group.

[0101] In this configuration, also in the fourth embodiment, the upper node 300-P suspends the transfer of each RRC reconfiguration completion message transmitted from the multiple lower nodes 300-C1 and 300-C2. Then, when the handover to the target donor 200-T is completed, the upper node 300-P transmits the suspended RRC reconfiguration completion messages received from the lower nodes 300-C1 and 300-C2 to the target donor 200-T. This allows the lower nodes 300-C1 and 300-C2 to access the target donor 200-T, as in the first embodiment, even when a group handover is performed.

[0102] 13, in step S140, the source donor 200-S transmits a handover request message to the target donor 200-T. The handover request message may include a request to perform a group handover.

[0103] In step S141, the target donor 200-T sends a handover request acknowledgement message to the source donor 200-S.

[0104] In step S142-1, the source donor 200-S transmits a group handover command (group HO Command) message to the upper node 300-P.

[0105] In step S142-2, the upper node 300-P transfers the group handover command to the lower node 300-C2, and in step S142-3, the upper node 300-P transfers the group handover command to the lower node 300-C1.

[0106] The group handover command may include information indicating that a normal handover (handover for the IAB node 300-P) and a handover for the subordinate node group (subordinate nodes 300-C1 and 300-C2) are to be performed simultaneously. In this case, the upper node 300-P may forward the group handover command received from the source donor 200-S to the subordinate nodes 300-C1 and 300-C2 as is. Alternatively, the group handover command may include both the settings of the upper node 300-P and the settings of the subordinate nodes 300-C1 and 300-C2. In this case, the upper node 300-P may forward the group handover command to the subordinate nodes 300-C1 and 300-C2 by extracting the settings of the subordinate nodes 300-C1 and 300-C2 or without making any changes to the settings of the subordinate nodes 300-C1 and 300-C2.

[0107] 13, step S142-2 is followed by step S142-3, but the order may be reversed.Step S142-2 and step S142-3 may be performed simultaneously.

[0108] In step S143, the lower node 300-C2 transmits an RRC reconfiguration complete message to initiate access to the target donor 200-T.

[0109] Also, in step S144, the lower node 300-C1 transmits an RRC reconfiguration completion message to initiate access to the target donor 200-T.

[0110] The upper node 300-P suspends the transfer of the RRC reconfiguration completion messages received from the lower nodes 300-C1 and 300-C2 to the target donor 200-T and holds these messages until the upper node 300-P starts accessing the target donor 200-T (step S145). This transfer suspension may be performed in a "transfer suspension mode" as in the third embodiment.

[0111] In step S146, the upper node 300-P transmits an RRC reconfiguration completion message to the target donor 200-T, and starts accessing the target donor 200-T.

[0112] Then, in step S147, the upper node 300-P completes the handover to the target donor 200-T, and therefore transfers the RRC reconfiguration complete messages received from the lower nodes 300-C1 and 300-C2, the transfer of which has been suspended, to the target donor 200-T. In this case, the upper node 300-P may combine these RRC reconfiguration complete messages, the transfer of which has been suspended, into a single message and transmit it, or may transfer each RRC reconfiguration complete message. The combined message may be an RRC Group Reconfiguration Complete message. Alternatively, the upper node 300-P may transmit, as a single message, the RRC reconfiguration complete messages, the transfer of which has been suspended, in its own RRC reconfiguration complete message (step S146). In this case, the single message may also be an RRC Group Reconfiguration Complete message.

[0113] In the fourth embodiment described above, an example was described in which two IAB nodes 300-C1 and 300-C2 were used as lower level nodes, but three or more IAB nodes may exist as child nodes of the upper level node 300-P.

[0114] (Fifth embodiment) The fifth embodiment is an embodiment in which the upper node 300-P maintains the path to the source donor 200-S for a certain period of time even after the upper node 300-P has performed a handover to the target donor 200-T.

[0115] For example, even if the subordinate node 300-C has specific data or a message to transmit to the source donor 200-S, the handover may prevent the subordinate node 300-C from transmitting the data or message to the source donor 200-S.

[0116] Therefore, in the fifth embodiment, the upper node 300-P maintains the path to the source donor 200-S for a certain period of time even after handover. This allows, for example, the lower node 300-C to transmit specific data to the source donor 200-S even after handover.

[0117] FIG. 14 is a diagram showing an example of operation in the fifth embodiment.

[0118] In step S150, the source donor 200-S performs a setting for the upper node 300-P to maintain a path with the source donor 200-S even after handover. In the example of Fig. 14, the source donor 200-S performs the setting by transmitting an RRC reconfiguration message including the setting to the upper node 300-P. The setting includes at least any of the following information: 1) Routing settings to be maintained after handover 2) BH RLC Channel ID to be maintained after handover 3) Validity period of the path to be maintained after handover The RRC reconfiguration message in step S150 may be transmitted simultaneously with the subsequent handover command (step S154), or may be included in the handover command. The example in Fig. 14 shows an example in which the RRC reconfiguration message including the relevant settings is transmitted before the handover command.

[0119] Steps S151 and S152 are the same as steps S110 and S111 in the first embodiment, respectively.

[0120] In step S153, the source donor 200-S transmits a handover command message to the subordinate node 300-C. Also, in step S154, the source donor 200-S transmits a handover command message to the superior node 300-P.

[0121] In step S155, the upper node 300-P executes handover processing, transmits an RRC reconfiguration completion message to the target donor 200-T, and starts accessing the target donor 200-T. At this time, the upper node 300-P leaves a path to the source donor 200-S based on the setting in step S150. Specifically, the upper node 300-P, based on the setting, 4) Maintain connection with the relevant cell 5) Maintain the corresponding BH RLC Channel 6) Maintain applicable routing settings In 4) to 6) above, "maintain" may be replaced with "not destroy."

[0122] In step S156, the lower node 300-C starts accessing the target donor 200-T. In this case, the lower node 300-C may make the access after the handover process by the upper node 300-P is completed based on the notification according to the first embodiment. Alternatively, the upper node 300-P may suspend the transfer of the RRC reconfiguration completion message received from the lower node 300-C until its own handover is completed, using the transfer hold mode according to the third embodiment, and may transfer the message after the handover is completed.

[0123] In step S157, the upper node 300-P receives a specific packet (in the example of FIG. 14, an RRC message for the source donor 200-S) transmitted from the lower node 300-C.

[0124] At this time, the upper node 300-P performs routing processing and forwarding processing based on the above 4) to 6) maintained in step S155. Then, in step S158, the upper node 300-P forwards the RRC message received from the lower node 300-C to the source donor 200-S using the path to the source donor 200-S. In this case, the upper node 300-P may forward a specific packet received from the source donor 200-S to the lower node 300-C using the path to the source donor 200-S.

[0125] The source donor 200-S or the target donor 200-T may transmit a discard instruction for the setting to leave the path to the upper node 300-P (steps S159 and S160). For example, the source donor 200-S or the target donor 200-T may transmit the discard instruction when all handover processes of the lower node 300-C are completed.

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

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

[0128] Although one embodiment has been described in detail above with reference to the drawings, the specific configuration is not limited to the above, and various design changes can be made without departing from the scope of the invention. Furthermore, it is also possible to combine all or part of each embodiment within a consistent range.

[0129] This application claims priority to U.S. Provisional Application No. 63 / 093381 (filed October 19, 2020), the entire contents of which are incorporated herein by reference.

[0130] (Addendum) (introduction) A revised work item on NR eIAB (Enhancements to Integrated Access and Backhaul) was approved. Some of the objectives are:

[0131] Topology Adaptation Extensions Specification of procedures for inter-donor IAB node mobility to enhance robustness and load balancing, including enhancements to reduce signaling load. -Specify extensions to reduce service interruptions due to IAB node movement and BH RLF recovery. · Specification of extensions to topology redundancy, including support for CP / UP separation. Topology, Routing, and Transport Enhancements Specification of extensions to improve fairness across topologies, multi-hop delays, and congestion mitigation.

[0132] This appendix discusses considerations for topology adaptation extensions to Rel-17 eIAB in terms of backhaul link quality assumptions, BH RLF indication extensions, BH RLF recovery and cell (re)selection, and lossless delivery extensions.

[0133] (Discussion) (Assuming backhaul link quality) During the Rel-15 research phase, the TR stated as one of the requirements backgrounds that "wireless backhaul links are vulnerable to blockages caused by moving objects such as vehicles, seasonal changes (leaves), infrastructure changes (new buildings), etc. Such vulnerabilities also apply to IAB nodes that are physically stationary." Therefore, various challenges arising from multi-hop / wireless backhaul and potential solutions to these were studied, as captured in the TR.

[0134] Finding 1: The Rel-15 study identified various challenges posed by unstable backhaul links and potential solutions, which were well captured in TR38.874.

[0135] In the Rel-16 normative work, IAB nodes were assumed to be stationary, i.e., "fixed IAB nodes." Therefore, the backhaul (BH) was sufficiently stable in a well-designed deployment, even for backhaul links over mmWave and / or local area IAB nodes that may be deployed in an unmanaged manner. Therefore, only the basic functionality of the BH RLF was specified: BH RLF indication (also known as "recovery failure" type 4) and recovery procedures combined with existing functionality such as RRC re-establishment, MCG / SCG failure indication, and / or conditional handover.

[0136] Observation 2: Rel-16 IAB assumed only fixed IAB nodes with sufficiently stable backhaul links.

[0137] In the Rel-17 extension, one of the intended use cases is "Mobile IAB Node," which may be part of "Inter-Donor IAB Node Mobility" even though it is not explicitly mentioned in the WID. Furthermore, sub-objectives in the WID, such as "Extended Features for Reducing Service Interruptions through IAB Node Mobility and Backhaul RLF Recovery" and "Topology Redundancy Enhancements," clearly intend for backhaul link instability, for example, due to mmWave interference, and mobility and backhaul RLF are frequent occurrences in Rel-17 deployment scenarios. Therefore, according to the Rel-17 discussion, RAN2 should first have a common understanding of backhaul link assumptions.

[0138] Proposal 1: RAN2 should assume that the quality of the backhaul link changes dynamically. Therefore, backhaul RLF is not a rare case in Rel-17 eIAB.

[0139] (Extended BH RLF indication) (Additional Indications (Type 2 and Type 3)) In the Rel-16 email discussion, four types of BH RLF notifications were discussed, as shown in Figure 15.

[0140] Finally, only Type 4 "Recovery Failure" is specified as the BH RLF indication in Rel-16, which allows a child IAB-MT to recognize the RLF on the BH link and initiate the RLF recovery procedure.

[0141] Finding 3: In Rel-16, only Type 4 “failure to recover” was defined as a BH RLF indication.

[0142] On the other hand, many companies still believe that other types of indications would be useful, so this was further discussed via email. Eight out of 13 companies preferred to introduce Type 2 "Attempting Recovery," while the other two companies thought it would be discussed in Rel-17. Therefore, it can be concluded that the majority of companies are ready to introduce Type 2 indication in Rel-17. Even if Type 2 indication can be introduced, further consideration is needed on how to send it, such as by using BAP Control PDU, SIB1, or both. Note that Type 1 and Type 2 have the same meaning.

[0143] Proposal 2: RAN2 should agree that BH RLF indication type 2 "attempting recovery" is introduced. Whether it should be sent via BAP Control PDU, SIB1, or both is for further consideration.

[0144] Furthermore, 9 out of 13 companies agreed to discuss Type 3 "BH link recovery" in Rel-17 as well. If Type 2 indication is introduced as in Proposal 2, it will be very easy for the IAB-MT / UE to be notified when the parent BH link has been successfully restored.

[0145] However, it should be considered whether such an explicit indication is really necessary. For example, if the Type 2 indication is sent via SIB1, the indication will not be broadcast once the BH link is no longer under RLF (i.e., "recovered"), as shown in Option 2 of Figure 16. Therefore, the downstream IAB node and the UE will know whether the BH link has recovered based on the absence of the Type 2 indication in SIB1. Of course, if the Type 3 indication is sent via the BAP Control PDU, it has the advantage that the downstream IAB node can quickly learn of the BH link recovery. However, it has the disadvantage that the UE does not know of the recovery because it does not have the BAP layer. Therefore, the RAN2 should consider whether the Type 3 indication is really necessary.

[0146] Proposal 3: If Proposal 2 is agreed upon, RAN2 should consider whether an explicit BH RLF indication should be introduced when the BH RLF disappears, i.e., Type 3 "BH Link Recovery."

[0147] If Proposal 2 and / or Proposal 3 are agreed upon, the behavior of the IAB-MT upon receiving an indication should be considered while the BH link is being restored. It is proposed that the IAB-MT should reduce / suspend SR upon receiving a Type 2 indication and resume operation upon receiving a Type 3 indication (i.e., the BH RLF disappears at the parent IAB node). This is one of the desired IAB-MT behaviors when the parent node is attempting to restore the BH link. It is assumed that other IAB-MT behaviors, such as suspending all RBs, are also possible.

[0148] Proposal 4: RAN2 should agree to reduce / stop scheduling requests after IAB-MT receives a Type 2 indication and resume scheduling requests when the parent node no longer has a BH RLF.

[0149] Another possible behavior is related to local rerouting, which has been proposed in many papers. Local rerouting is expected to be used for congestion relief, load balancing, etc., but may also be used for service continuity in the case of an upstream BH RLF, such as a parent node. For example, an IAB node may perform local rerouting upon receiving a Type 2 indication, but in a Rel-16-like routing configuration, it may revert to normal routing once the IAB node is notified of successful recovery from the upstream BH RLF, such as by receiving a Type 3 indication.

[0150] There are new IAB-MT actions related to Rel-17 functionality that may be performed upon receipt of a Type 2 indication. Therefore, in addition to Proposal 4, RAN2 should consider other IAB-MT actions when a parent node is recovering from a BH RLF.

[0151] Proposal 5: RAN2 should discuss if there are other IAB-MT operations, such as local rerouting, while the parent node is trying to restore the BH link.

[0152] Regarding the IAB-DU that transmits the indication, if the BH link of the IAB node is under RLF, it is assumed that it will transmit a Type 2 BH RLF indication. This is straightforward for a single-connection BH because the indication is sent when an RLF occurs on this BH link. However, the dual-connection BH case is more complicated. For example, if an IAB node detects RLF on the MCG, it initiates the MCG fault information procedure, but the SCG continues to function as the BH link, so there is no need to transmit a Type 2 indication at this point. If the MCG fault information procedure fails, such as due to the expiration of T316, the IAB-MT initiates RRC re-establishment, so a Type 2 indication is sent at this point. Therefore, a Type 2 indication is sent when RRC re-establishment is initiated, not when the MCG / SCG fault information is triggered. In any case, since this is targeted at the behavior of the IAB-DU, careful consideration should be given to whether and how to capture this in the specification. That is, consideration should be given to whether notes should be added in Stages 2 and 3, or whether no capture is necessary.

[0153] Proposal 6: RAN2 should agree that it may send a Type 2 BH RLF indication when IAB-DU initiates RRC re-establishment, rather than when it initiates any of the RLF recovery procedures.

[0154] Proposal 7: RAN2 should discuss whether / how to capture IAB-DU behavior (i.e., Proposal 6) in its specifications.

[0155] (CHO Extension with Indication (Type 4)) Conditional Handover (CHO) was introduced in Rel-16, and our understanding is that CHO can be used out of the box for Rel-16 IAB. Many companies have proposed extending CHO or using it to move inter-donor IAB nodes.

[0156] In Rel-16, CHO is performed when the corresponding CHO event (A3 / A5) is satisfied or when the selected cell is a CHO candidate as a result of RRC re-establishment cell selection. These trigger conditions can be satisfied when an IAB node experiences a BH RLF on the BH link. On the other hand, they cannot be satisfied under an IAB-specific RLF, such as the RLF due to the reception of a BH RLF indication (Type 4), because the radio condition of the BH link owned by the IAB node is good. In this case, one desired behavior is for the IAB node to perform CHO when it receives a BH RLF indication.

[0157] Therefore, it is worth exploring additional trigger conditions for CHO to improve topology adaptation in Rel-17 eIAB. We believe that at least the existing BH RLF indication (i.e., Type 4) is a promising candidate for a new trigger, but further consideration could be given to whether CHO will be executed upon receipt of a Type 2 indication, if introduced.

[0158] Proposal 8: RAN2 should consider whether an additional trigger condition for CHO is defined, i.e., at least when an IAB node receives a BH RLF indication (Type 4). If introduced, further study is needed to determine whether it can be applied to Type 2.

[0159] (BH RLF Recovery and Cell (Re)Selection Enhancements) In the RRC re-establishment procedure, the IAB-MT first performs a cell selection procedure to find a suitable cell. Potential issues with this cell selection procedure, such as the possibility that the IAB-MT may select a descendant node, were identified in Rel-16. Therefore, these were discussed in the email discussion.

[0160] Five possible solutions were discussed and summarized, along with the rapporteur's views, as shown in Figure 17.

[0161] The conclusion was "No further action will be taken on this topic in Rel-16", which meant that RAN2 agreed to "Option 4: If there is no BH connection, RRC re-establishment will fail, so nothing is needed". Option 4 was acceptable in the Rel-16 deployment scenario, even though it required more time for BH RLF recovery, since it would have to wait for failure (T301 expiry) and eventually move to idle.

[0162] Observation 4: In Rel-16, if an IAB node attempts an RRC re-establishment request to a descendant node, the IAB node must wait for the failure and eventually move to idle.

[0163] In Rel-17, cell (re)selection and RRC re-establishment may occur more frequently in light of Proposal 1. Therefore, suboptimal operation, i.e., operation according to Finding 4, would cause significant performance degradation in terms of IAB topology stability and service continuity. Therefore, to optimize the operation of IAB-MT during BH RLF recovery, as the rapporteur in the above email discussion stated, "this topic may be discussed again in Rel-17."

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

[0165] Among the solutions identified, except for option 4 above, a common concept can be seen to be that for cell selection purposes, the IAB-MT is provided with either a whitelist or blacklist type. Considering that topology changes may occur frequently in Rel-17, for example due to "inter-donor IAB node movements," whitelists and blacklists have advantages and disadvantages depending on the topology and the location of the IAB nodes.

[0166] For example, it is more reasonable to provide a whitelist for IAB nodes near the IAB donor, i.e., from the perspective of the top of the DAG topology, since the number of candidate nodes is small, possibly only IAB donor DUs.

[0167] However, in another example, for IAB nodes far away from the IAB donor, i.e., from the perspective of the bottom of the DAG topology, the whitelist may need to include a huge number of candidate nodes. Instead, a blacklist may be more appropriate, for example, to include only downstream IAB nodes of the IAB node of concern, and possibly only a small number of child IAB nodes, thereby reducing overhead.

[0168] One concern with whitelists is that due to the nature of Rel-17's "Inter-Donor IAB Node Movement," they may need to include candidate IAB nodes that belong to different / adjacent IAB topologies, potentially increasing the list size, whereas blacklists do not have such concerns, since downstream IAB nodes obviously belong to the same IAB topology.

[0169] Observation 5: Whitelists and blacklists have advantages and disadvantages depending on the topology and location of the IAB nodes.

[0170] Therefore, it may be desirable for an IAB donor (or parent IAB node) to be able to choose whether to use a whitelist or a blacklist when providing information to a child IAB node for cell selection purposes. It should also be considered whether it would be beneficial to reuse that information for cell reselection purposes.

[0171] Proposal 10: RAN2 should agree that whitelists or blacklists (i.e., selection structures) are provided to the IAB-MT for cell selection purposes to avoid re-establishment on descendant nodes. Whether these lists can also be used for cell reselection procedures requires further study.

[0172] If proposal 10 can be agreed upon, further consideration should be given to how the information (i.e., whitelists or blacklists) will be provided. Option 1 assumes CHO configuration and may require some extensions. Option 2 assumes additional indications, such as a Type 2 BH RLF indication. Option 3 assumes providing topology-wide information not present in the existing configuration. Option 5 assumes configuration by OAM, but as the rapporteur pointed out, this is questionable.

[0173] Considering again the assumption of Rel-17 (i.e., Proposal 1), that parent IAB nodes or IAB donors should provide lists to child IAB nodes when topology changes occur, whitelists / blacklists need to be dynamically provided. Therefore, option 5, i.e., OAM, should be ruled out. Which method, i.e., option 1, 2, or 3, should be the baseline for enhancements requires further consideration.

[0174] Proposal 11: RAN2 should agree that the whitelist / blacklist will be dynamically provided by the parent IAB node or IAB donor whenever the topology changes. Details need further study.

[0175] (Lossless streaming extension) During the Rel-15 research phase, the challenges 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 a non-separated RLC layer, i.e., end-to-end ARQ was eliminated in Rel-16 in favor of hop-by-hop ARQ.

[0176] For hop-by-hop ARQ, challenges were identified in end-to-end reliability, i.e., lossless delivery of UL packets. Three solutions were identified and evaluated, as shown in Figure 18.

[0177] In Rel-16, the first solution, "changing the PDCP protocol / procedures," was not adopted because it would affect Rel-15 UEs.

[0178] The second solution, "rerouting of buffered PDCP PDUs at intermediate IAB nodes," was supported as an implementation choice at the BAP layer. Additionally, the BAP layer may "implementation-dependently perform, for example, data buffering in the transmitting part of the BAP entity until the RLC-AM entity receives an acknowledgment." These BAP implementations were considered to avoid packet loss in "most" cases of Rel-16 deployment scenarios, i.e., when using fixed IAB nodes, but were not perfect, e.g., as shown in Figure 18.

[0179] The third solution, "introduction of UL status delivery," was a promising solution to ensure lossless delivery of UL data, taking into account the evaluation results cited in Figure 18. The idea was to delay the RLC ARQ to the UE so that PDCP data recovery at the UE would be initiated when necessary. However, since fixed IAB nodes were assumed, it was considered rare for UL packets to be dropped due to topology changes, so this was not specified in Rel-16.

[0180] Considering the assumptions of Rel-17, i.e., from the perspective of Proposal 1, the third solution should be further explored because UL packet loss during topology changes, which occur frequently in Rel-17, is no longer rare. Therefore, in addition to the results captured in TR, RAN2 should discuss enhancement mechanisms to ensure lossless delivery within L2 multi-hop networks.

[0181] Proposal 12: RAN2 should agree to the solution specified in TR38.874, i.e., to implement a mechanism to ensure lossless delivery under conditions where topology changes may occur frequently based on some form of "UL status delivery."

[0182] Regarding the details of the third solution, i.e., “Introduction of UL Status Distribution”, two options, C-1 and C-2, were discussed in the email discussion, as shown in Figure 19.

[0183] Regarding C-1 above, it is assumed that "confirmation" from the IAB donor needs to be specified in the BAP or RRC for end-to-end signaling transport over a multi-hop L2 network. Therefore, specifying this option would require a relatively high standardization effort.

[0184] Regarding C-2 above, if it works well in an IAB topology, it should be assumed that OAM configures all IAB nodes using this option, but sending an RLC ACK to the UE (or downstream IAB node) ultimately relies on the IAB-DU implementation, so it can actually be implemented for Rel-16 IAB nodes. Furthermore, it is simpler than C-1 because it assumes hop-by-hop feedback and does not assume additional Control PDUs. Therefore, C-2 should be an extended baseline for Rel-17 for lossless delivery of UL packets.

[0185] Observation 6: Solution C-2 for "Introduction of UL Status Distribution" could be an extended baseline for Rel-17, which could also be implemented for Rel-16.

[0186] However, Rel-17 should anticipate dynamic topology changes that cause UL packet loss, so Rel-17 extensions will likely support C-2 as a standard supported feature. At least the Stage 2 specifications should describe the overall mechanism based on C-2. Otherwise, the 3GPP standard will not guarantee lossless delivery during IAB node handover. Furthermore, minor changes such as RLC and / or BAP are expected in Stage 3, but these are considered internal operations of IAB nodes and may not be specified in detail.

[0187] Proposal 13: RAN2 should agree to specify an RLC ARQ mechanism for lossless delivery of UL packets in Stage 2, which delays sending ACK to child nodes / UEs before receiving ACK from the parent IAB node (i.e., C-2). Whether / how to specify this in Stage 3 requires further study.

[0188] (IAB node transfer between donors) The IAB node integration procedure was introduced in Rel-16 and will be used for the initial integration of IAB nodes, i.e., while they are still in the out-of-service phase.

[0189] Rel-17 aims to specify inter-donor IAB node mobility, which will provide robust operation and apply to mobile IAB nodes. Unlike Rel-16, Rel-17 inter-donor IAB node mobility is performed during the in-service phase, so the movement of one IAB node from one IAB node to another will impact the entire topology and cause service interruptions. In other words, Rel-17 inter-donor IAB node mobility requires consideration of how all IAB nodes in the IAB topology move to other IAB donors, specifically how synchronized RRC reconfiguration (i.e., handover commands) is provided to these affected IAB nodes.

[0190] Assuming that a child node (IAB node #2) is connected to a source IAB donor via a parent node (IAB node #1), as shown in FIG. 20, a set of signaling issues can be considered.

[0191] Case 1: If the parent is moved first, the RRC signaling path between the child and the source donor is released, so it is unclear how the child node can be moved. Case 2: When a child is moved first, the RRC signaling path to the target donor via the parent node has not yet been established, so it is unclear how the child node will reach the target donor (i.e., how to complete the RRC reconfiguration and send it to the target donor).

[0192] For case 1, we consider reusing CHO with some extensions of the child nodes, i.e., CHO is executed on the child nodes when the parent node is moved. In case 2, by the time of, say, the parent node, the child is considered to be waiting to send an RRC reconfiguration to the target donor.

[0193] In either case, one option may be for the child node to first release and then reintegrate using Rel-16 procedures, although given the significant service disruption, this may not be a viable solution in Rel-17.

[0194] While the overall procedure for inter-donor IAB node mobility is considered in RAN3, RAN2 needs to consider its impact on how multiple IAB nodes are reconfigured in a multi-hop network.

[0195] Proposal 14: RAN2 should consider how to reconfigure multi-hop IAB nodes due to IAB node movement between donors.

Claims

1. A communication control method for use in a cellular communication system, comprising: a first donor network node transmitting a message to a relay node having a subordinate device thereunder to cause the relay node to switch from the first donor network node to a second donor network node; the first donor network node performs a process to remove a path between the relay node and the first donor network node after the connection to the second donor network node in the relay node is completed and the switching from the first donor network node to the second donor network node in the lower device is completed; A communication control method comprising:

2. a first donor network node, a transmitter that transmits a message to a relay node having subordinate devices to switch from the first donor network node to a second donor network node; a control unit that executes a process to remove a path between the relay node and the first donor network node after the connection to the second donor network node in the relay node is completed and switching from the first donor network node to the second donor network node in the lower device is completed. A first donor network node.

3. 1. A cellular communication system, comprising: a relay node having subordinate devices; a first donor network node; The first donor network node: sending a message to the relay node to cause the relay node to switch from the first donor network node to a second donor network node; After the connection to the second donor network node in the relay node is completed and the switching from the first donor network node to the second donor network node in the lower device is completed, a process is performed to remove the path between the relay node and the first donor network node. Cellular communication systems.

Images