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

[0003] A communication control method according to a first aspect is a communication control method for use in a cellular communication system, the communication control method including: a 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 notification to the second relay node indicating that the handover has been completed.

[0004] A communication control method according to a second aspect is a communication control method used in a cellular communication system, the communication control method 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 transmitting a first access message for the second donor base station received from the second relay node to the second donor base station when the first relay node completes the handover to the second donor base station. [Brief description 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. [Diagram 2] FIG. 2 is a diagram showing the relationship between IAB nodes, parent nodes, and child nodes. [Diagram 3] FIG. 3 is a diagram showing an example configuration of a gNB (base station) according to one embodiment. [Figure 4] FIG. 4 is a diagram illustrating a configuration example of an IAB node (relay node) according to an embodiment. [Diagram 5] FIG. 5 is a diagram illustrating a configuration example of a UE (user equipment) according to an embodiment. [Figure 6] FIG. 6 is a diagram showing an example of a protocol stack related to an RRC connection and a NAS connection of an IAB-MT. [Figure 7] FIG. 7 is a diagram showing an example of a protocol stack related to the F1-U protocol. [Figure 8] FIG. 8 is a diagram showing an example of a protocol stack for the F1-C protocol. [Figure 9] FIG. 9 illustrates an example of a handover. [Figure 10] FIG. 10 is a diagram illustrating an operation example of the first embodiment. [Figure 11] FIG. 11 is a diagram illustrating an operation example of the second embodiment. [Figure 12] FIG. 12 is a diagram illustrating an operation example of the third embodiment. [Figure 13] FIG. 13 is a diagram illustrating an operation example of the fourth embodiment. [Figure 14] FIG. 14 is a diagram illustrating an operation example of the fifth embodiment. [Figure 15] FIG. 15 is a diagram illustrating types of BH RLF notifications. [Figure 16] FIG. 16 is a diagram illustrating the transmission options of the extended BH RLF indication. [Figure 17] FIG. 17 illustrates an 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 Delivery" option. [Figure 20] FIG. 20 illustrates RAN2 signaling issues that may arise with IAB node movement between donors. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[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 on the area in which the UE 100 is located by communicating with the UE 100 using Non-Access Stratum (NAS) signaling. The UPF 12 is a device that performs transfer control of user data.

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

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

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

[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 a terminal node of the NR backhaul on the network side, and is a donor base station with additional functions to support IAB. The backhaul can be multi-hopped 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 is a mobile phone terminal, a tablet terminal, a laptop computer, a sensor or a device provided in a sensor, a vehicle or a device provided in a vehicle, or an aircraft or a device provided in an aircraft. The UE 100 wirelessly connects to the IAB node 300 or the gNB 200 via an access link. FIG. 1 shows an example in which the UE 100 is wirelessly connected to the IAB node 300-2. The UE 100 indirectly communicates with the donor 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 cells, similar to the gNB 200. The IAB-DU terminates the NR Uu radio interface to the UE 100 and the lower IAB nodes. The IAB-DU supports the F1 protocol to the CU of the donor gNB 200-1. In FIG. 2, an example is shown in which the child nodes of the IAB node 300 are the IAB nodes 300C1-300C3, but the child nodes of the IAB node 300 may 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 of the configuration of the gNB 200. As shown in Fig. 3, the gNB 200 has a wireless communication unit 210, a network communication unit 220, and a control unit 230.

[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 receptions under the control of the control unit 230. The receiving unit 211 includes an antenna, and converts (down-converts) a wireless signal received by the antenna into a baseband signal (received signal) and outputs the signal to the control unit 230. The transmitting unit 212 performs various transmissions under the control of the control unit 230. The transmitting unit 212 includes an antenna, and converts (up-converts) a baseband signal (transmitted signal) output by the control unit 230 into a wireless signal and transmits the signal from the antenna.

[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 receptions under the control of the control unit 230. The receiving unit 221 receives a signal from the outside and outputs the received signal to the control unit 230. The transmitting unit 222 performs various transmissions under the control of the control unit 230. The transmitting unit 222 transmits the transmission signal output by the control unit 230 to the outside.

[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 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 a baseband signal. 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 230 may perform each processing in the gNB 200 in each of the embodiments shown below.

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

[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 receptions under the control of the control unit 320. The receiving unit 311 includes an antenna, and converts (down-converts) a wireless signal received by the antenna into a baseband signal (received signal), and outputs the signal to the control unit 320. The transmitting unit 312 performs various transmissions under the control of the control unit 320. The transmitting unit 312 includes an antenna, and converts (up-converts) a baseband signal (transmitted signal) output by the control unit 320 into a wireless signal, and transmits the signal from the antenna.

[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 a program executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of a baseband signal. The CPU executes a program stored in the memory to perform various processing. The processor performs processing of each layer, which will be described later. The control unit 320 may also perform each processing in the IAB node 300 in each of the embodiments shown below.

[0031] (Configuration of user device) Next, a configuration of the UE 100 which is a user device according to the embodiment will be described. Fig. 5 is a diagram showing 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 wireless communication unit 110 performs wireless communication in an access link, that is, wireless communication with the gNB 200 and wireless communication with the IAB node 300. The wireless communication unit 110 may also perform wireless communication in a side link, that is, wireless communication with another UE 100. The wireless communication unit 110 has a receiving unit 111 and a transmitting unit 112. The receiving unit 111 performs various receptions under the control of the control unit 120. The receiving unit 111 includes an antenna, and converts (down-converts) a wireless signal received by the antenna into a baseband signal (received signal) and outputs the signal to the control unit 120. The transmitting unit 112 performs various transmissions under the control of the control unit 120. The transmitting unit 112 includes an antenna, and converts (up-converts) a baseband signal (transmitted signal) output by the control unit 120 into a wireless signal and transmits the signal from the antenna.

[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 a program executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of a baseband signal. The CPU executes a program stored in the memory to perform various processing. The processor performs processing of each layer, which will be described later. The control unit 130 may also 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 the IAB node 300-2 and the PHY layer of the IAB-DU of the 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 of IAB node 300-2 and the MAC layer of the IAB-DU of IAB node 300-1 via a transport channel. The MAC layer of the IAB-DU includes a scheduler. The scheduler determines the transport format (transport block size, modulation and coding scheme (MCS)) and the assigned resource blocks for uplink and downlink.

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

[0039] The PDCP layer performs header compression / decompression and encryption / decryption. Data and control information are transmitted between the PDCP layer of the IAB-MT of the IAB node 300-2 and the PDCP layer of the donor 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 the 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 located above the RRC layer, performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of the IAB-MT of the IAB node 300-2 and the AMF 11.

[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 split into a CU and a DU.

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

[0044] In each backhaul link, the PDUs (Protocol Data Units) of the BAP layer are transmitted by a backhaul RLC channel (BH NR RLC channel). By configuring multiple backhaul RLC channels in each BH link, traffic prioritization and QoS (Quality of Service) control are possible. The association between the BAP PDUs and the 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 operation performed by the IAB-DU and IAB-MT of the IAB may be simply described as the processing or operation of the "IAB." For example, the transmission of a BAP layer message by the IAB-DU of IAB300-1 to the IAB-MT of IAB300-2 will be described as the IAB300-1 transmitting the message to IAB300-2. In addition, the processing or operation of the DU or CU of the IAB donor 200 may be simply described as the processing or operation of the "IAB donor."

[0047] (First embodiment) In the first embodiment, an example will be described in which the IAB node 300 performs 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 handover of the IAB node 300 between donor gNBs 200. Such handover may be called 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 the 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 a higher-level node), and the IAB node 300-C may be called a "Child Node" (or a lower-level node). 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, may be referred to as the "source donor") 200-S to a target donor gNB (hereinafter, may be 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 at what timing the parent node IAB node 300-P has completed handover. Details will be described 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 IAB node 300-P has completed 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 been 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 the completion of the handover to the second relay node.

[0055] This allows the IAB node 300-C to grasp the completion of the handover of the parent node, the IAB node 300-P, and allows the IAB node 300-C to succeed even if it starts to access the target donor 200-T.

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

[0057] In addition, in FIG. 10, for example, "Source donor" is the source donor 200-S, and "Target donor" is the target donor 200-T. In addition, in FIG. 10, for example, "Parent node" is the IAB node 300-P, and "Child node" is the IAB node 300-C. In the following, "Parent node" may be referred to as the upper node 300-P, and "Child node" may be referred to as the lower node 300-C. In addition, 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 the 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 acknowledgment (HO Request Ack) message, which is an acknowledgment 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 a 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 to suspend access to the target donor 200-T. 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 performed, 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 accessing 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] When 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 a 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] In addition, when the upper node 300-P fails to access the target donor 200-T (i.e., HOF (Handover Failure)), the upper node 300-P may transmit a notification indicating the failure of the access to the lower node 300-C. In this case, the lower node 300-C may discard the received handover command message (step S112) upon receiving this notification. In addition, the upper node 300-P or the lower node 300-C may transmit a notification indicating the failure of the access to the source donor 200-S. The notification may include information (Cause) indicating that the cause is the access failure of the upper node 300-P. By the notification, the source donor 200-S may recognize that the access of the upper node 300-P 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 toward 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 cannot know at what timing the handover of the upper node 300-P is 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 handover to the target donor 200-T has not been completed in the upper node 300-P, so 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 the handover by the upper node 300-P in step S115. Therefore, the lower node 300-C accesses the target donor 200-T after the handover of the upper node 300-P is completed, and therefore the lower node 300-C can access the target donor 200-T.

[0070] Second embodiment In the first embodiment, an example of handover by a handover command message is described. In the second embodiment, a conditional handover is performed. In the second embodiment, 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 conditional handover will be described. A conditional handover is a handover that is executed when one or more handover execution conditions (or trigger conditions) are satisfied. The conditional handover setting includes a setting for a conditional handover candidate cell and a trigger condition. The conditional handover setting may include a plurality of combinations of the setting for the candidate cell and the trigger condition.

[0072] In a typical handover, the UE 100 reports the measurement values ​​of the radio conditions of the serving cell and / or the neighboring cell to the gNB 200, and the gNB 200 decides to perform a handover to the neighboring cell based on the report and transmits a handover command to the UE 100. For this reason, in a case where the radio conditions of the serving cell suddenly deteriorate, the typical handover may result in a communication interruption before the handover is executed. In contrast, the conditional handover can autonomously execute a handover to a candidate cell corresponding to a preset trigger condition when the trigger condition is satisfied. For this reason, problems such as communication interruption in a typical handover can be solved.

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

[0074] Steps S110 and S111 are similar to those in the first embodiment.

[0075] In step S120, the source donor 200-S sets the conditional handover for the lower node 300-C. In the example of FIG. 11, the source donor 200-S transmits an RRC Reconfiguration message including the setting information of the conditional handover to the lower node 300-C. The setting information of the conditional handover includes a trigger condition of "when the upper node completes the handover". That is, the lower node 300-C executes its own handover when the upper node 300-P completes the handover as the trigger condition. Alternatively, the trigger condition may include "when a notification from the upper node is received". That is, the lower node 300-C executes its own handover when the notification from the upper node 300-P is received 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 enables access to the target donor 200-T while maintaining the relationship between the superior 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 completion message, and initiates access to 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 is 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 according to 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 grasp 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 completion of the handover, etc. (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 the UE 100 that supports "Release 17" of 3GPP, it can receive such a notification. However, when the UE 100 supports "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 a 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 under its control performs 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 an 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 showing an operation example 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 lower node 300-C. The message is transmitted to the lower node 300-C via the upper 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 hold mode. In this case, the upper node 300-P receives this notification and enters a transfer hold 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 is about to be transmitted to the lower node 300-C or may simply instruct the upper node 300-P to enter a transfer hold mode.

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

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

[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 completion message transmitted from the lower node 300-C.

[0092] There are, for example, the following two methods for suspending an RRC message.

[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 on 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. That is, the upper node 300-P can hold the RRC reconfiguration completion message from the lower node 300-C by suspending all SRBs and DRBs (Data Radio Bearers).

[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 initiates access to the target donor 200-T.

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

[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 operation example in the fourth embodiment. In Fig. 13, the following configuration example is shown.

[0100] That is, two lower 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 lower nodes 300-C1 and 300-C2. FIG. 13 shows an example in which two lower nodes 300-C1 and 300-C2 exist. The multiple lower nodes 300-C1 and 300-C2 may be called a lower node group.

[0101] In such a configuration, even 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 that a group handover be performed.

[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 lower node group (lower nodes 300-C1 and 300-C2) are to be performed simultaneously. In this case, the upper node 300-P may transfer the group handover command received from the source donor 200-S to the lower 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 lower nodes 300-C1 and 300-C2. In this case, the upper node 300-P may transfer the group handover command to the lower nodes 300-C1 and 300-C2 by extracting the settings of the lower nodes 300-C1 and 300-C2 or without modifying the settings of the lower nodes 300-C1 and 300-C2.

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

[0108] In step S143, the lower node 300-C2 transmits an RRC reconfiguration completion 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 by 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, since the upper node 300-P has completed the handover to the target donor 200-T, it transfers the RRC reconfiguration completion 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 transmit these RRC reconfiguration completion messages, the transfer of which has been suspended, together as one message, or may transfer each RRC reconfiguration completion message. The message combined into one may be an RRC Group Reconfiguration Complete message. Alternatively, the upper node 300-P may transmit, as one message, its own RRC reconfiguration completion message (step S146) including these RRC reconfiguration completion messages, the transfer of which has been suspended. The one message in this case may also be an RRC group reconfiguration complete message.

[0113] In the above-described fourth embodiment, an example has been described in which two IAB nodes 300-C1 and 300-C2 are 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 handover to the target donor 200-T.

[0115] For example, even if the lower node 300-C has certain data or messages to transmit to the source donor 200-S, the lower node 300-C may not be able to transmit the data or messages to the source donor 200-S due to the handover.

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

[0117] FIG. 14 is a diagram showing an operation example 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 an RRC reconfiguration message including the setting is transmitted before the handover command.

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

[0120] In step S153, the source donor 200-S transmits a handover command message to the lower node 300-C, and in step S154, the source donor 200-S transmits a handover command message to the upper 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 a connection with the relevant cell 5) Maintain the relevant BH RLC Channel 6) Maintain applicable routing settings In 4) to 6) above, "retain" 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 perform 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 in 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 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 in a computer-readable medium. Using the computer-readable medium, it is possible to install the program in the computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.

[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 (chip set, 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 and the like are possible without departing from the scope of the invention. In addition, it is also possible to combine all or part of each embodiment as long as there is no contradiction.

[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] (Additional Note) (introduction) A revised work item on NR eIAB (Enhancements to Integrated Access AND Backhaul) was approved. Some of the objectives are to:

[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, multi-hop delays, and congestion mitigation across topologies.

[0132] This appendix discusses considerations for Rel-17 eIAB topology adaptation extensions 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 due to moving objects such as vehicles, seasonal changes (foliage), infrastructure changes (new buildings), etc. Such vulnerabilities apply even to IAB nodes that are physically stationary." Therefore, various challenges arising from multi-hop / wireless backhaul and potential solutions to this were studied, as captured in the TR.

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

[0135] In the normative work of Rel-16, 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, i.e., BH RLF indication (aka "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 "Extensions for Reducing Service Disruption Due to IAB Node Mobility and BH RLF Recovery" and "Enhancements for Topology Redundancy" clearly intend that the BH link becomes unstable, for example due to mmWave interference, and mobility and BH RLF are frequent occurrences in Rel-17 deployment scenarios. Therefore, according to the Rel-17 discussion, RAN2 should first have a common understanding of the BH 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 it was discussed further in the email. 8 out of 13 companies preferred to introduce Type 2 "attempting recovery", while the other 2 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, the way to send it, such as by using BAP Control PDU, SIB1, or both, needs further consideration. 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 is sent via BAP Control PDU, SIB1, or both is for further consideration.

[0144] Additionally, 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 is very easy for the IAB-MT / UE to be notified when the parent BH link is 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, as shown in option 2 of Figure 16, the indication will not be broadcasted once the BH link is not under RLF (i.e., "recovered"). Thus, downstream IAB nodes and UEs will know whether the BH link has recovered or not based on the absence of type 2 indication in SIB1. Of course, if the type 3 indication is sent via BAP Control PDU, it has the advantage that downstream IAB nodes can quickly know the BH link recovery. However, it has the disadvantage that the UE does not know the recovery because it does not have the BAP layer. Therefore, RAN2 should consider whether the type 3 indication is really necessary.

[0146] Proposal 3: If Proposal 2 is acceptable, RAN2 should consider whether an explicit BH RLF indication when the BH RLF is lost, i.e., Type 3 “BH Link Recovery”, should be introduced.

[0147] If Proposal 2 and / or Proposal 3 can be agreed upon, the behavior of the IAB-MT upon receiving an indication should be considered while the BH link is being restored. It was proposed that the IAB-MT should reduce / stop SR upon receiving an indication of type 2 and resume operation upon receiving an indication of type 3 (i.e., no more BH RLFs 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 receiving an IAB-MT 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 mitigation, load balancing, etc., but may also be used for service continuity even 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 setup, 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 while the parent node is trying to recover the BH link, such as local rerouting.

[0152] Regarding the IAB-DU sending the indication, if the BH link of the IAB node is under RLF, it is assumed to send a type 2 BH RLF indication. The case of a single-connected BH is straightforward, since the indication is sent when an RLF occurs on this BH link. However, the case of a dual-connected BH is more complicated. For example, if the IAB node detects an RLF on the MCG, it will initiate the MCG fault information procedure, but the SCG will continue to function as the BH link, and therefore there is no need to send a type 2 indication at this point. If the MCG fault information procedure fails, such as due to T316 expiry, the IAB-MT will initiate RRC re-establishment, and therefore a type 2 indication is sent at this point. Thus, a type 2 indication is sent when the 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, it should be carefully considered whether / how to capture it in the specification. That is, it should be considered whether a note should be added or nothing should be captured at stage 2 and stage 3.

[0153] Proposal 6: RAN2 should agree that it may send a Type 2 BH RLF indication when the IAB-DU initiates an RRC re-establishment, but not 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, to our understanding, CHO can be used out of the box for Rel-16 IAB. Many companies have proposed its use for extending CHO or moving 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 a BH link. On the other hand, they cannot be satisfied under an IAB specific RLF, such as an RLF due to 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 of the desired behaviors is for an 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 the topology adaptation of 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 if introduced, we could further explore whether CHO would be executed upon receipt of a Type 2 indication.

[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 required as to 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. In this cell selection procedure, potential issues were pointed out in Rel-16, such as the possibility that the IAB-MT may select a descendant node. Therefore, it was 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". This meant that RAN2 agreed to "Option 4: Nothing is needed as RRC re-establishment will fail if there is no BH connection". Option 4 was acceptable in Rel-16 deployment scenarios even if more time is needed for BH RLF recovery since it has 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 view 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 IAB-MT operation during BH RLF recovery, as the rapporteur in the above email discussion states, "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, from the perspective of IAB nodes near the IAB donor, i.e., the top of the DAG topology, it is more reasonable to provide a whitelist since the number of candidate nodes is small, possibly only IAB donor DUs.

[0167] However, in another example, where an IAB node is 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 to reduce overhead, for example by including only downstream IAB nodes of the IAB node of concern, and possibly even only a small number of child IAB nodes.

[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 / neighboring IAB topologies, potentially increasing the size of the list, whereas blacklists have no such concern, 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] It may therefore 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 white or black lists (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) is provided. Option 1 assumes CHO configuration and may require some extensions. Option 2 assumes additional indications, e.g. BH RLF indication of type 2. Option 3 assumes providing topology-wide information not in the existing configuration. Option 5 assumes configuration by OAM, but as the rapporteur pointed out, this is doubtful.

[0173] Considering again the assumption of Rel-17 (i.e., proposal 1), i.e., parent IAB node or IAB donor should provide list to child IAB node when topology change occurs, whitelist / blacklist needs to be provided dynamically. Therefore, option 5, i.e., OAM, should be ruled out. Which method, i.e., option 1, 2, or 3, should be the baseline for enhancement needs 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 Delivery Extension) During the Rel-15 research phase, the issue of multi-hop RLC ARQ was discussed and captured in section 8.2.3 of the TR. In Rel-16, the protocol stack was defined for IAB with a non-separate RLC layer, i.e., end-to-end ARQ was eliminated 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, "changes in PDCP protocols / procedures", was not adopted because it would affect Rel-15 UEs.

[0178] The second solution, "re-routing of buffered PDCP PDUs at intermediate IAB nodes", was supported as an implementation choice at the BAP layer. Additionally, the BAP layer may "e.g. buffer data at the transmitting part of the BAP entity until the RLC-AM entity receives an acknowledgment, which is implementation dependent". 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 in the UE would be initiated when necessary. However, it was not specified in Rel-16, since fixed IAB nodes were assumed, and it was considered rare for UL packets to be dropped due to topology changes.

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

[0181] Proposal 12: RAN2 should agree to implement the solution specified in TR38.874, i.e. a mechanism to ensure lossless delivery under conditions of potentially frequent topology changes 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 a "confirmation" from the IAB donor needs to be specified in the BAP or RRC for end-to-end signaling forwarding over multi-hop L2 networks. Therefore, a relatively high standard effort would be required to specify this option.

[0184] Regarding C-2 above, even though it should be assumed that OAM configures all IAB nodes with this option if it works well for IAB topology, it can be actually implemented for Rel-16 IAB nodes as well since it ultimately depends on the IAB-DU implementation when sending RLC ACK to the UE (or downstream IAB node). Moreover, it is simpler than C-1 since it assumes hop-by-hop feedback and does not assume additional Control PDUs. Therefore, C-2 should be the Rel-17 extended baseline 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 expect dynamic topology changes that cause UL packet loss, so Rel-17 extensions will 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 does not guarantee lossless delivery during IAB node handover. Furthermore, minor changes such as RLC and / or BAP are expected in Stage 3, but may not specify the details since they are considered as internal operation of IAB nodes.

[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 parent IAB node (i.e. C-2). Whether / how to specify in stage 3 needs further study.

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

[0189] Rel-17 aims to specify inter-donor IAB node movement, which will provide robust operation and apply to mobile IAB nodes. Unlike Rel-16, Rel-17 inter-donor IAB node movement is performed in the in-service phase, so that an inter-donor IAB node movement of one IAB node will impact the entire topology and cause service interruption. In other words, Rel-17 inter-donor IAB node movement requires consideration of how all IAB nodes in the IAB topology move to other IAB donors, specifically, how RRC reconfiguration with synchronization (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 can 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 traversed. 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 could be for the child node to first be released and then reintegrated using Rel-16 procedures, although given the significant service interruption this may not be viable as a 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 needs to 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 executes a process for removing 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 subordinate device is completed; A communication control method comprising the steps of:

2. a first donor network node, a transmitter for transmitting a message to a relay node having a subordinate device thereunder for switching from the first donor network node to a second donor network node; a control unit that executes a process for removing 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