Communication control method, user equipment, mobile communication system, program, and chipset

Abstract

A communication control method according to one aspect of the present invention is used in a cellular communication system. The communication control method comprises: a step for a distributed unit (DU) transmitting, to a central unit (CU), resource information relating to resources to be used by a user device during RACH-less handover; and a step for the central unit transmitting a handover command including the resource information to the user device.

Description

Communication Control Method

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

[0002] The Third Generation Partnership Project (3GPP), 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, Non-Patent Document 1). One or more relay nodes intervene in communication between a base station and a user device and relay this communication.

[0003] 3GPP TS 38.300 V17.1.0 (2022-06)

[0004] 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 comprising the steps of: a distributed unit (DU) transmitting, to a central unit (CU), resource information relating to resources to be used in a user equipment during a RACH-less handover; and the central unit transmitting, to the user equipment, a handover command including the resource information.

[0005] 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 comprising: a central unit (CU) transmitting, to a distributed unit (DU), validity period information indicating a validity period of resources used in a user equipment (UE) during a conditional RACH-less handover; and the distributed unit transmitting the validity period information to the central unit. The communication control method also comprises a step of the central unit transmitting, to the user equipment, a conditional reconfiguration including the validity period information.

[0006] FIG. 1 is a diagram showing an example of the configuration of a cellular communication system according to one embodiment. FIG. 2 is a diagram showing the relationship between an IAB node, parent nodes, and child nodes. FIG. 3 is a diagram showing an example of the configuration of a gNB (base station) according to one embodiment. FIG. 4 is a diagram showing an example of the configuration of an IAB node (relay node) according to one embodiment. FIG. 5 is a diagram showing an example of the configuration of a UE (user equipment) according to one embodiment. FIG. 6 is a diagram showing an example of a protocol stack related to an IAB-MT RRC connection and a NAS connection. FIG. 7 is a diagram showing an example of a protocol stack related to the F1-U protocol. FIG. 8 is a diagram showing an example of a protocol stack related to the F1-C protocol. FIGS. 9(A) and 9(B) are diagrams showing an example of complete mobility according to the first embodiment. FIGS. 10(A) and 10(B) are diagrams showing an example of complete mobility according to the first embodiment. FIG. 11 is a diagram showing an example of the relationship between a CU, a DU, and a UE according to the first embodiment. Figures 12(A) and 12(B) are diagrams showing an example of the relationship between a CU, a DU, and a UE according to the first embodiment. Figures 13(A) and 13(B) are diagrams showing an example of the relationship between a CU, a DU, and a UE according to the first embodiment. Figure 14 is a diagram showing an example of an operation according to the first embodiment. Figure 15 is a diagram showing an example of an operation according to the second embodiment. Figure 16 is a diagram showing a RACH-less handover using a TA (Timing Advance) value and / or an UL grant. Figure 17 is a diagram showing scenarios and subcases of UE cell reselection. Figure 18 is a diagram showing a scenario for PCI collision.

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

[0008] [First embodiment]

[0009] (Configuration of Cellular Communication System) An example configuration of a cellular communication system according to one embodiment will be described. The cellular communication system 1 according to one 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 in part to the cellular communication system 1. Furthermore, future cellular communication systems such as 6G may also be applied to the cellular communication system 1.

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

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

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

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

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

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

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

[0017] Each gNB 200 may be divided into a central unit (CU) and a distributed unit (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 the F1-C protocol, which is a control plane protocol, and the F1-U protocol, which is a user plane protocol.

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

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

[0020] The UE 100 is a mobile wireless communication device that performs wireless communication with a cell. The UE 100 may be any device that performs wireless communication with the gNB 200 or the IAB node 300. For example, the UE 100 is a mobile phone terminal and / or a tablet terminal, a laptop PC, 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 node 200-1 via the IAB node 300-2 and the IAB node 300-1.

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

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

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

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

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

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

[0027] The wireless communication unit 210 performs wireless communication with the UE 100 and wireless communication with the IAB node 300. The wireless communication unit 210 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.

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

[0029] The control unit 230 performs various controls in the gNB 200. The control unit 230 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs executed by the processor and information used in processing by the processor. The processor may include a baseband processor and a CPU. 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. Note that the control unit 230 may perform each process or operation in the gNB 200 in each of the embodiments shown below.

[0030] (Configuration of Relay Node) Next, a configuration of an IAB node 300, which is a relay node (or relay node device; hereinafter, may be referred to as a "relay node") according to an 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.

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

[0032] The wireless communication unit 310 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 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 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 wireless signal, and transmits the signal from the antenna.

[0033] The control unit 320 performs various controls in the IAB node 300. The control unit 320 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs executed by the processor and information used 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. Note that the control unit 320 may perform each process or operation in the IAB node 300 in each of the embodiments described below.

[0034] (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 an example configuration of the UE 100. As shown in Fig. 5, the UE 100 includes a radio communication unit 110 and a control unit 120.

[0035] The wireless communication unit 110 performs wireless communication in an access link, i.e., 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, i.e., wireless communication with other UEs 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.

[0036] 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 processing by the processor. The processor may include a baseband processor and a CPU. 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. Note that the control unit 120 may be configured to perform each process in the UE 100 in each of the embodiments described below.

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

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

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

[0040] The MAC layer performs data priority control, retransmission processing using Hybrid Automatic Repeat reQuest (HARQ), random access procedures, etc. Data and control information are transmitted via transport channels 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. The MAC layer of the IAB-DU includes a scheduler. The scheduler determines the uplink and downlink transport format (transport block size, modulation and coding scheme (MCS)) and the allocated resource blocks.

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

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

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

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

[0045] 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 node 200 is divided into a CU and a DU.

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

[0047] In each backhaul link, 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 BAP PDUs and backhaul RLC channels is performed by the BAP layer of each IAB node 300 and the BAP layer of the donor node 200.

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

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

[0050] Also, the upstream direction and the uplink (UL) direction may be used interchangeably, and the downstream direction and the downlink (DL) direction may be used interchangeably.

[0051] (Mobile IAB Node) Currently, 3GPP has begun discussions toward the introduction of mobile IAB nodes. A mobile IAB node is, for example, an IAB node that is moving. A mobile IAB node may be an IAB node that is capable of moving. Alternatively, a mobile IAB node may be an IAB node that is currently stationary but is certain to move in the future (or is expected to move in the future).

[0052] The mobile IAB node enables, for example, a UE 100 under the mobile IAB node to receive services from the mobile IAB node while moving in accordance with the movement of the mobile IAB node. For example, a case is envisioned in which a user (or UE 100) on a vehicle receives services via a mobile IAB node installed on the vehicle.

[0053] On the other hand, in contrast to mobile IAB nodes, there are also IAB nodes that do not move. Such IAB nodes are sometimes referred to as intermediate IAB nodes. An intermediate IAB node is, for example, an IAB node that does not move. Alternatively, the intermediate IAB node may be a stationary IAB node. Alternatively, the intermediate IAB node may be an IAB node that remains stationary (or does not move) and remains installed at its installation location. Alternatively, the intermediate IAB node may be a stationary IAB node that does not move. The intermediate IAB node may also be a fixed IAB node.

[0054] A mobile IAB node can also be connected to an intermediate IAB node. Also, a mobile IAB node can be connected to a donor node 200. A mobile IAB node can also change its connection destination due to movement (migration or handover). The connection source may be an intermediate IAB node. The connection source may be the donor node 200. Also, the connection destination may be an intermediate IAB node. The connection destination may be the donor node 200.

[0055] In the following, the terms "migration" of a mobile IAB node and "handover" of a mobile IAB node may be used interchangeably.

[0056] In the following description, the mobile IAB node may be referred to as a "mobile IAB node." The mobile IAB node may also be referred to as a "migrating IAB node." In either case, the mobile IAB node may be referred to as a mobile IAB node.

[0057] (Full Migration of a Mobile IAB Node) A mobile IAB node may move between donor nodes (IAB-donors) 200 .

[0058] 9(A) to 10(B) are diagrams showing an example of a procedure when the mobile IAB node 300M moves from the source donor node 200-S to the target donor node 200-T. The mobile IAB node 300M has a UE 100 under its control. The example of FIG. 9(A) shows an example in which the UE 100 is present in a cell range formed by IAB-DU#1 of the mobile IAB node 300M. The UE 100 can move together with the mobile IAB node 300M.

[0059] 9A shows an example of an initial condition. The IAB-DU#1 of the mobile IAB node 300M has established an F1 connection with the CU of the source donor node 200-S. The IAB-MT of the mobile IAB node 300M has established an RRC connection with the CU of the source donor node 200-S.

[0060] 9(B) shows an example in which the mobile IAB node 300M moves to the target donor node 200-T, resulting in a partial migration state with respect to the target donor node 200-T. As shown in FIG. 9(B), in partial migration, the IAB-DU #1 (and the UE 100) of the mobile IAB node 300M is terminated in the CU of the source donor node 200-S, while the IAB-MT of the mobile IAB node 300M has moved to the CU of the target donor node 200-T. The IAB-MT of the mobile IAB node 300M has established an RRC connection with the CU of the target donor node 200-T. In addition, the IAB-DU of the mobile IAB node 300M has established an F1 connection with the source donor node 200-S. Partial mobility refers to a state in which, for example, the connection of the UE 100 under the mobile IAB node 300M remains with the source donor node 200-S via the IAB-DU#1 of the mobile IAB node 300M.

[0061] 10A shows an example in which the mobile IAB node 300M subsequently enters a state of phase 1 of full migration with respect to the target donor node 200-T. In phase 1 of full migration, the UE 100 remains connected to the source donor node 200-S via IAB-DU#1, but a new IAB-DU#2 has established an F1 connection with the CU of the target donor node 200-T. Here, IAB-DU#1 and IAB-DU#2 may be logical IAB-DUs. One physical IAB-DU may include two logical IAB-DUs (IAB-DU#1 and IAB-DU#2).

[0062] 10(B) shows an example in which the mobile IAB node 300M subsequently enters a state of complete movement phase 2 with respect to the target donor node 200-T. In the complete movement phase 2, the connection of the mobile IAB node 300M (and the UE 100) has moved from the CU of the source donor node 200-S to the CU of the target donor node 200-T. Complete movement refers to, for example, a state in which the connection of the UE 100 has moved to the target donor node 200-T via IAB-DU #2 of the mobile IAB node 300M.

[0063] Note that movement between CUs using two DUs (IAB-DU #1 and IAB-DU #2) by the mobile IAB node 300M may be referred to as a “dual DU approach.” For example, the dual DU approach is performed when the UE 100 moves from one CU and DU to another CU and DU.

[0064] (RACH-less handover) 3GPP specifies RACH-less handover (RACH-less HO) (for example, 3GPP TS 36.300 V17.1.0 (2022-06)). RACH-less handover is a handover that skips the random access procedure. In RACH-less handover in the LTE system, for example, the following process is performed.

[0065] That is, the UE 100 receives an RRC connection reconfiguration (RRCConnectionReconfiguration) message from the source cell. The RRC connection reconfiguration message includes an information element (MobilityControlInfo) including parameters (such as a TA (Timing Advance) value and / or an UL grant) used when the UE 100 performs a RACH-less handover. The UE 100 uses the parameters included in the RRC connection reconfiguration message to transmit an RRC connection reconfiguration complete (RRCConnectionReconfigurationComplete) message to the target cell without performing a random access (RACH) procedure. As a result, a RACH-less handover is performed, and the UE 100 can establish uplink synchronization with the target cell.

[0066] In the RACH-less handover, the random access procedure is skipped, and therefore the delay in the execution time of the handover can be improved compared to when the random access procedure is executed in the UE 100.

[0067] (Communication Control Method According to the First Embodiment) There are cases where the UE 100 under the mobile IAB node 300M may perform a RACH-less handover. For example, in the case of a full migration of the mobile IAB node 300M, the UE 100 changes its connection destination from IAB-DU #1 (or the cell formed by IAB-DU #1; i.e., the source cell) of the mobile IAB node 300M to IAB-DU #2 (or the cell formed by IAB-DU #2; i.e., the target cell) (see FIGS. 10A and 10B). Therefore, the UE 100 performs a handover from IAB-DU #1 to IAB-DU #2. However, IAB-DU #1 and IAB-DU #2 are logical DUs and may be the same DU physically. That is, when two DUs (or two cells) are provided using the same antenna system, the physical distance between the UE 100 and the antenna system is the same, and therefore the TA value can also be considered to be the same. Therefore, when the UE 100 performs a handover from IAB-DU#1 to IAB-DU#2, it is possible to avoid connection interruptions and perform communication appropriately by performing a RACH-less handover rather than performing a random access procedure for IAB-DU#2.

[0068] On the other hand, in the 5G system, the UE 100 can complete the RACH-less handover by transmitting an RRC reconfiguration complete (RRCReconfigurationComplete) message. In the 5G system, the RRC connection reconfiguration complete (RRCConnectionReconfigurationComplete) message in the LTE system is replaced with an RRC reconfiguration complete message.

[0069] Generally, uplink resource information (i.e., UL grant) is configured by the DU using downlink control information (DCI). On the other hand, a RACH-less handover is configured by the CU since it is configured using an RRC reconfiguration message. That is, the UL grant is configured by the DU, and the RACH-less handover is configured by the CU. Without information about the UL grant, the CU may not be able to properly configure the RACH-less handover for the UE 100. In this case, the UE 100 cannot transmit an RRC reconfiguration complete message and cannot properly perform the RACH-less handover.

[0070] Therefore, the first embodiment aims to enable the UE 100 to appropriately execute the RACH-less handover.

[0071] Therefore, in the first embodiment, first, the distributed unit (DU) transmits resource information regarding resources used in the user equipment (e.g., UE 100) during the RACH-less handover to the central unit (CU). Second, the central unit transmits a handover command including the resource information to the user equipment.

[0072] In this way, resource information used in UE 100 during RACH-less handover is transmitted from DU to CU, and therefore, CU can appropriately set RACH-less handover for UE 100 using the resource information. Therefore, UE 100 can appropriately execute RACH-less handover.

[0073] (Relationship between CU, DU, and UE 100) Here, an example of the relationship between the CU, DU, and UE 100 when a RACH-less handover is performed will be described. Note that the CU may be a central device, and the DU may be a distributed device.

[0074] Fig. 11 is a diagram illustrating an example of the relationship between a CU, a DU, and a UE 100 according to the first embodiment. Generally, as shown in Fig. 11, when the UE 100 moves from a source-side DU (or a source cell formed by the source-side DU) to a target-side DU (or a target cell formed by the target-side DU), the UE 100 executes a handover (RACH-less handover in the first embodiment) to the target-side DU at the movement destination.

[0075] The relationship between CU, DU and UE100 can be classified into, for example, the following two types.

[0076] First, there is a case where the CU is included in the donor node 200 and the DU is included in the mobile IAB node 300M. That is, this is a case where the CU is the CU (IAB-donor-CU) of the donor node 200, and the DU is the IAB-DU of the mobile IAB node 300M. FIGS. 12(A) and 12(B) show examples of relationships in such cases. FIG. 12(A) shows an example of inter-donor migration, and FIG. 12(B) shows an example of intra-donor migration. Note that the mobile IAB node 300M may also be a fixed IAB node.

[0077] Secondly, there is a case where the CU and DU are included in the gNB200. That is, when the CU is a CU of the gNB200 and the DU is a DU of the gNB200. Figures 13(A) and 13(B) show relationship examples in such cases. Figure 13(A) shows an example of inter-gNB handover (Inter-gNB HO), and Figure 13(B) shows an example of intra-gNB handover (Intra-gNB HO). Note that the source cell and target cell may be provided from the same DU. Such handover is called intra-DU (Intra-DU HO).

[0078] Note that the IAB-MT of the mobile IAB node 300M has a UE function in the mobile IAB node. Therefore, the mobile IAB node 300M itself may perform a RACH-less handover to the donor node 200. In this case, in Figures 13(A) and 13(B), the UE 100 can be read as the mobile IAB node 300M, and the gNB 200 can be read as the donor node 200.

[0079] The operation examples shown below may be mainly explained using the example of inter-donor transfer shown in FIG. 12A (or complete transfer shown in FIGS. 9A to 10B).

[0080] (Operation Example According to First Embodiment) FIG. 14 is a diagram illustrating an operation example according to the first embodiment.

[0081] 14, in step S10, the CU decides to set up a RACH-less handover for the UE 100. For example, the CU of the target donor node 200-T decides to set up a RACH-less handover for the UE 100 under the mobile IAB node 300M because the mobile IAB node 300M is moving. Alternatively, the CU of the source donor node 200-S may notify the CU of the target donor node 200-T, using an Xn message, that a RACH-less handover can be set up for the UE 100 under the mobile IAB node 300M because the mobile IAB node 300M is moving.

[0082] In step S11, the CU may request the DU (the DU providing the target cell) to reserve resources (or UL resources) for the RACH-less handover. The CU may make the request by transmitting a resource reservation request message requesting resource reservation for the RACH-less handover. For example, when the CU of the target donor node 200-T has established an F1 connection with the target-side DU (IAB-DU #2 of the mobile IAB node 300M in the example of FIG. 10(A)), the CU transmits the resource reservation request message as an F1 message to the target-side DU. The resource reservation request message may be a message requesting allocation of an UL grant for the RACH-less handover. Alternatively, the resource reservation request message may request provision of resource information (or UL grant information) for the RACH-less handover allocated by the DU. Alternatively, the resource reservation request message may request establishment of a UE context (UE Context Setup) and may include an identifier indicating that the handover is a RACH-less handover. Alternatively, the resource reservation request message may include a setting value desired by the CU (or a setting value to be included in an RRC reconfiguration message).

[0083] In step S12, the DU transmits UL grant information for RACH-less handover to the CU. The UL grant information represents, for example, resource information related to resources used in the UE 100 during RACH-less handover. The DU may transmit the UL grant information by transmitting a resource information message including the UL grant information for RACH-less handover to the CU. For example, when the target-side DU (IAB-DU #2 of the mobile IAB node 300M in the example of FIG. 10A) has established an F1 connection with the CU of the target donor node 200-T, the DU transmits a resource information message including the UL grant information as an F1 message to the CU of the target donor node 200-T. The UL grant information included in the resource information message may be UL resource configuration information. This information may be PUSCH (Physical Uplink Shared Channel) resource configuration information.

[0084] In step S13, the CU includes UL grant information for RACH-less handover in a handover command. The handover command may be an RRC Reconfiguration message including an information element (e.g., reconfiguration with synchronization (reconfigurationWithSync)) used for the UE 100 to establish synchronization with the target cell during handover. The UL grant information for RACH-less handover may be included in the reconfiguration with synchronization. For example, the CU of the target donor node 200-T includes the UL grant information in the handover command.

[0085] In step S14, the CU transmits a handover command to the UE 100. For example, the CU of the target donor node 200-T transmits an Xn message including a handover command to the CU of the source donor node 200-S, and the CU of the source donor node 200-S transmits the handover command to the UE 100. In this case, the CU of the source donor node 200-S extracts the handover command from the Xn message and transmits an F1 message including the handover command to the source side DU of the mobile IAB node 300M (IAB-DU #1 of the mobile IAB node 300M in the example of FIG. 10(A)). Then, the source side DU (source cell) extracts the handover command from the F1 message and transmits the handover command to the UE 100.

[0086] In step S15, UE 100 extracts UL grant information and the like from the handover command, and transmits an RRC reconfiguration complete (RRCReconfigurationComplete) message to the target side DU (target cell) using resources indicated by the UL grant information without performing a random access procedure. As a result, UE 100 performs a RACH-less handover. UE 100 executes a RACH-less handover using resources allocated by the target side DU.

[0087] (Another Example 1 According to the First Embodiment) The above-described operation example according to the first embodiment has been mainly described as an example in which the mobile IAB node 300M performs inter-donor migration, but is not limited to this. The above-described operation example is also applicable to a case in which the mobile IAB node 300M performs intra-donor migration ( FIG. 12(B) ). In this case, the CU of the donor node 200 may make a resource reservation request to the IAB-DU of the mobile IAB node 300M (step S11). Furthermore, the IAB-DU of the mobile IAB node 300M transmits an UL grant for RACH-less handover to the CU of the donor node 200 (step S12). Then, the CU of the donor node 200 transmits a handover command including the UL grant to the UE 100 (step S14).

[0088] The above-described operation example can also be applied to inter-gNB handover (FIG. 13(A)). In this case, in FIG. 14, the source side DU can be read as the DU of the source side gNB 200-1, and the target side DU can be read as the DU of the target side gNB 200-2.

[0089] Furthermore, the above-described operation example can also be applied to intra-gNB handover (FIG. 13(B)). In this case, in FIG. 14, the source side DU can be read as the source side DU of gNB200, and the target side DU can be read as the target side DU of gNB200.

[0090] Furthermore, the above-described operation example is also applicable to the case where the mobile IAB node 300M itself performs a RACH-less handover to the donor node 200.

[0091] First, when the mobile IAB node 300M performs inter-donor migration, in Fig. 14, the source-side DU should be read as the DU of the source donor node 200-S, the target-side DU should be read as the DU of the target donor node 200-T, and further, the UE 100 should be read as the mobile IAB node 300M. In this case, in Fig. 14, the CU of the target donor node 200-T sends a handover command by an Xn message to the CU of the source donor node 200-S, and the CU of the source donor node 200-S sends the handover command to the mobile IAB node 300M.

[0092] Secondly, when the mobile IAB node 300M performs intra-donor migration, in Fig. 14, the source-side DU should be read as the source-side DU of the donor node 200, the target-side DU should be read as the target-side DU of the donor node 200, and further, the UE 100 should be read as the mobile IAB node 300M. The operation example shown in Fig. 14 may also be applied to intra-DU handover (intra-DU HO).

[0093] (Another Example 2 According to the First Embodiment) In the first embodiment, an example of a RACH-less handover has been described, but the present invention is not limited to this. For example, the first embodiment can also be applied to a case where a conditional handover (CHO) is performed as a RACH-less handover. In this case, the CU may request the target-side DU to reserve resources for the conditional RACH-less handover (step S11). The request may be made by a resource reservation request message, as in the first embodiment. Furthermore, the target-side DU transmits UL grant information indicating resources for the conditional RACH-less handover to the CU (step S12). The UL grant information may be included in a resource information message. Furthermore, the CU may include the UL grant information in conditional reconfiguration and transmit an RRC reconfiguration message including conditional reconfiguration to the UE 100 (step S14).

[0094] Second Embodiment Next, a second embodiment will be described, focusing mainly on the differences from the first embodiment.

[0095] In the second embodiment, an example will be described in which a conditional handover is performed by a RACH-less handover. Hereinafter, a conditional handover performed by a RACH-less handover may be referred to as a conditional RACH-less handover (Conditional RACH-less HO).

[0096] (Conditional Handover) Here, conditional handover (CHO) will be described. In a typical handover, the UE 100 reports the measurement values ​​of the radio conditions of the serving cell and / or neighboring cells to the gNB 200, and the gNB 200 determines a handover to the neighboring cell based on this report and transmits a handover instruction to the UE 100. For this reason, in a case where the radio conditions of the serving cell suddenly deteriorate, a typical handover may result in communication being interrupted before the handover is executed.

[0097] In contrast, in the conditional handover, when a preset trigger condition is satisfied, the UE 100 can autonomously execute handover to a candidate cell corresponding to the trigger condition. Therefore, problems such as communication interruption in general handover can be solved.

[0098] Conditional handover is configured by conditional reconfiguration. The conditional reconfiguration is one of the information elements (IEs) included in an RRC reconfiguration message. The conditional reconfiguration is configured, for example, by transmitting an RRC reconfiguration message from the CU of the donor node 200 to the IAB-MT of the IAB node 300 (or the UE 100). The conditional reconfiguration includes candidate cells and execution conditions used in the conditional handover. The execution conditions include one or more trigger conditions. When the trigger conditions are satisfied, the IAB-MT of the IAB node 300 (or the UE 100) starts executing a handover to the candidate cell.

[0099] (Communication control method according to the second embodiment) As described above, for example, when the UE 100 performs a conditional handover, the UE 100 does not start accessing the target cell until the trigger condition is satisfied. That is, the UE 100 does not immediately start accessing the target cell after the conditional reconfiguration is set. In addition, in the conditional handover, access to a plurality of target cells can also be set. However, there are cases where the trigger condition is not satisfied for a certain target cell, and the UE 100 does not access the cell.

[0100] Even in the case of a conditional RACH-less handover, when the trigger condition is satisfied, resources (UL resources) for executing the RACH-less handover are required. Specifically, resources (or radio resources) for transmitting an RRC reconfiguration complete message to the target cell are required.

[0101] As described above, in the conditional handover, the UE 100 does not immediately access the target cell, so a source for transmitting the RRC reconfiguration complete message is reserved for a certain period of time.

[0102] However, maintaining the resource for a certain period of time or longer may not be desirable from the viewpoint of resource efficiency, since there may be cases where it is better to use the resource for other communications rather than maintaining the resource for a certain period of time or longer.

[0103] Therefore, the second embodiment aims to ensure effective use of radio resources while securing resources for conditional RACH-less handover.

[0104] Therefore, in the second embodiment, first, the central unit (CU) transmits validity period information indicating the validity period of resources used in the user equipment (e.g., UE 100) during the conditional RACH-less handover to the distributed unit (DU), and the distributed unit transmits the validity period information to the central unit. Second, the central unit transmits a conditional reconfiguration including the validity period information to the user equipment.

[0105] In this way, the UE 100 is notified of the validity period of the resources used in the conditional RACH-less handover, and therefore, when the validity period expires, the resources are released and can be used for other communications. Thus, in the cellular communication system 1, it is possible to secure resources for the conditional RACH-less handover while making effective use of the resources.

[0106] The central device is a CU and the distributed device is a DU, as in the first embodiment. An example of the relationship between the CU, the DU, and the UE 100 is also the same as in the first embodiment.

[0107] (Example of Operation According to Second Embodiment) Next, an example of operation according to the second embodiment will be described.

[0108] Fig. 15 is a diagram illustrating an example of operation according to the second embodiment. The example of operation shown in Fig. 15 will be mainly described using the example of inter-donor transfer shown in Fig. 12(A) (or complete transfer shown in Figs. 9(A) to 10(B)).

[0109] 15, in step S20, the CU decides to set up a conditional RACH-less handover for the UE 100. For example, the CU of the target donor node 200-T decides to set up a conditional RACH-less handover for the UE 100 under the control of the mobile IAB node 300M.

[0110] In step S21, the CU may request the DU to reserve resources (or UL resources) for a conditional RACH-less handover. As in the first embodiment, the request may be made by a resource reservation request message. For example, when the CU of the target donor node 200-T has established an F1 connection with the target-side DU (IAB-DU #2 of the mobile IAB node 300M in the example of FIG. 10(A)), the CU transmits a resource reservation request message as an F1 message to the target-side DU. The resource reservation request message may include validity period information indicating the validity period of the resources for a conditional RACH-less handover. The validity period may be represented by a timer value. The validity period may be determined by the CU.

[0111] In step S22, the DU may transmit to the CU resource information indicating resources for conditional RACH-less handover, along with validity period information indicating the validity period of the resources. As in the first embodiment, the transmission may be performed using a resource information message. In this case, the resource information message includes the resource information and the validity period information. The validity period may be determined by the DU and transmitted to the CU. That is, the validity period may be determined by the CU (step S21). The validity period may also be determined by the DU (step S22). For example, the target-side DU (IAB-DU #2 of the mobile IAB node 300M in the example of FIG. 10(A)) transmits a resource information message including the validity period information as an F1 message to the CU of the target donor node 200-T.

[0112] In step S23, the CU includes the validity period information in the conditional reconfiguration. The validity period may be associated with each conditional reconfiguration (or each entry in the configuration list). The validity period may be commonly applied to all conditional reconfigurations. For example, the CU of the target donor node 200-T includes the validity period information in the conditional reconfiguration.

[0113] In step S24, the CU transmits a conditional reconfiguration including the validity period information to the UE 100. The conditional reconfiguration may be transmitted by being included in an RRC reconfiguration message. For example, the CU of the target donor node 200-T transmits an RRC reconfiguration message including the conditional reconfiguration to the CU of the source donor node 200-S using an Xn message, and the CU of the source donor node 200-S transmits the RRC reconfiguration message to the UE 100. In this case, the CU of the source donor node 200-S extracts the RRC reconfiguration message from the Xn message and transmits an F1 message including the RRC reconfiguration message to the source side DU of the mobile IAB node 300M (IAB-DU #1 of the mobile IAB node 300M in the example of FIG. 10(A)). Then, the source side DU extracts the RRC reconfiguration message from the F1 message and transmits the RRC reconfiguration message to UE100.

[0114] In step S24, the UE 100 receives the conditional reconfiguration. If validity period information is included in the conditional reconfiguration, the UE 100 starts counting by a timer. The UE 100 may start counting by the timer when receiving the conditional reconfiguration.

[0115] In step S25, the UE 100 determines whether or not the count value of the timer reaches the valid period (that is, whether or not the timer has expired).

[0116] When the timer expires (Yes in step S25), UE 100 discards the conditional reconfiguration in step S26. That is, UE 100 discards the conditional reconfiguration because the validity period of the resources for the conditional RACH-less handover has elapsed. Then, UE 100 ends the series of processes in step S27.

[0117] On the other hand, when the trigger condition is satisfied (Yes in step S28) before the timer expires (No in step S25), UE 100 transmits an RRC reconfiguration complete message to the target DU in step S29. That is, when the trigger condition indicated in the conditional reconfiguration is satisfied before the validity period elapses, UE 100 executes a conditional RACH-less handover by transmitting an RRC reconfiguration complete message to the target DU. On the other hand, when the trigger condition is not satisfied (No in step S28) before the timer expires (No in step S25), UE 100 proceeds to step S25 and repeats the above-described processing (steps S25 to S28).

[0118] (Another Example 1 According to the First Embodiment) The operation example according to the first embodiment has been mainly described as an example in which the mobile IAB node 300M performs inter-donor migration, but is not limited to this. The above-described operation example can also be applied to a case in which the mobile IAB node 300M performs intra-donor migration (FIG. 12(B)). In this case, the operation can be implemented by replacing the target-side DU and source-side DU in the same way as in the first embodiment.

[0119] In addition, the operation example according to the first embodiment can also be applied to inter-gNB handover (FIG. 13(A)). Furthermore, the above-described operation example can also be applied to intra-gNB handover (FIG. 13(B)). Furthermore, the above-described operation example can also be applied when performing a RACH-less handover to the donor node 200 of the mobile IAB node 300M itself. In either case, the CU, target side DU, source side DU, and / or UE can be implemented by replacing them in the same way as in the first embodiment.

[0120] (Another Example 2 According to the Second Embodiment) The validity period described in the second embodiment may use a value determined in advance in the specifications (or a value determined by hard coding). In this case, the validity period is not transmitted from the CU to the UE 100. When a conditional RACH-less handover is configured (step S24), the UE 100 starts counting a timer and determines whether the timer has expired based on whether the count value has reached a predetermined value.

[0121] (Another Example 3 According to Second Embodiment) In the second embodiment, an example in which a RACH-less handover is performed in a conditional handover has been described, but the present invention is not limited to this. For example, the present invention is also applicable to a case in which a RACH-less handover is performed in another conditional cell change procedure. Examples of other conditional cell change procedures include a conditional PS cell change (CPC) or a conditional PS cell addition (CPA).

[0122] The conditional PS cell change is a procedure in which, for example, when an execution condition is satisfied, the UE 100 changes the PS cell that is a primary cell of a secondary cell group. The conditional PS cell change is configured by a CPC configuration. The CPC configuration includes the execution condition, information on candidate PS cells, and the like. The CU may configure the UE 100 with a RACH-less handover in the conditional PS cell change by including validity period information in the CPC configuration and transmitting it to the UE 100 (step S24). When the timer expires, the UE 100 discards the CPC configuration, and, if the execution condition is satisfied before the timer expires, performs the PS cell change by a RACH-less handover.

[0123] Furthermore, the conditional PS cell addition is a procedure for adding a PS cell in the UE 100 when, for example, a PS cell addition condition is satisfied. The conditional PS cell addition is configured by a CPA configuration. The CPA configuration includes an execution condition, information on candidate PS cells, and the like. The CU may configure the UE 100 with a RACH-less handover in the conditional PS cell addition by including validity period information in the CPA configuration and transmitting it to the UE 100 (step S23). When a timer expires, the UE 100 discards the CPA configuration, and when the execution condition is satisfied before the timer expires, the UE 100 executes the PS cell addition by a RACH-less handover.

[0124] (Another Example 4 According to the Second Embodiment) In the second embodiment, an example in which validity period information is set in the UE 100 has been described, but this is not limiting. The validity period may be used by the CU. The validity period may be notified by an Xn message from the CU of the target donor node 200-T to the CU of the source donor node 200-S. For example, the CU of the source donor node 200-S starts a timer in which the validity period is set when the conditional RACH-less handover is configured for the UE 100 (or when the configuration is received from the CU of the target donor node 200-T). The CU of the source donor node 200-S may remove the RACH-less handover configuration from the UE 100 when the timer expires (for example, when the count value of the timer reaches the validity period).

[0125] [Other Embodiments] The above-described operational flows are not limited to being implemented independently, but can be implemented by combining two or more operational flows. For example, some steps of one operational flow may be added to another operational flow, or some steps of one operational flow may be replaced with some steps of another operational flow. In each flow, it is not necessary to execute all steps, and only some steps may be executed.

[0126] In the above-described embodiments and examples, an example in which the base station is an NR base station (gNB) has been described, but the base station may be an LTE base station (eNB) or a 6G base station. The base station may also be a relay node such as an IAB (Integrated Access and Backhaul) node. The base station may also be a DU of the IAB node. The UE 100 may also be an MT (Mobile Termination) of the IAB node.

[0127] Also, the term "network node" primarily refers to a base station, but may also refer to a device in the core network or part of a base station (CU, DU, or RU).

[0128] A program that causes a computer to execute each process performed by the UE 100 or the gNB 200 may be provided. The program may be recorded on a computer-readable medium. Using a computer-readable medium, it is possible to install the program on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not particularly limited, but may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.

[0129] In addition, circuits that perform each process performed by UE100 or gNB200 may be integrated, and at least a portion of UE100 or gNB200 may be configured as a semiconductor integrated circuit (chip set, SoC: System on a chip).

[0130] As used in this disclosure, the terms "based on" and "depending on / in response to" do not mean "based only on" or "depending only on," unless expressly stated otherwise. The term "based on" means both "based only on" and "based at least in part on." Similarly, the term "depending on" means both "depending only on" and "depending at least in part on." The terms "include," "comprise," and variations thereof do not mean including only the listed items, but may mean including only the listed items or may include additional items in addition to the listed items. Additionally, the term "or," as used in this disclosure, is not intended to mean an exclusive or. Furthermore, any reference to elements using designations such as "first," "second," etc., as used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used herein as a convenient method of distinguishing between two or more elements. Thus, a reference to a first and a second element does not imply that only two elements may be employed therein or that the first element must precede the second element in some way. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles shall include the plural unless the context clearly indicates otherwise.

[0131] 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 within the scope of the gist. Furthermore, the embodiments, operation examples, and processes can be appropriately combined within the scope of not being inconsistent.

[0132] This application claims priority to U.S. Provisional Application No. 63 / 410,710 (filed September 28, 2022), the entire contents of which are incorporated herein by reference.

[0133] (Supplementary Note 1) (Supplementary Note 1) A communication control method used in a cellular communication system, comprising: a step in which a distributed unit (DU) transmits, to a central unit (CU), resource information relating to resources used in a user equipment during a RACH-less handover; and a step in which the central unit transmits, to the user equipment, a handover command including the resource information.

[0134] (Supplementary Note 2) The communication control method according to Supplementary Note 1, further comprising a step in which the central device transmits a resource reservation request message to the distributed device requesting reservation of the resource, and the step of transmitting the resource information includes a step in which the distributed device transmits a resource information message including the resource information to the central device in response to receiving the resource reservation request message.

[0135] (Supplementary Note 3) The communication control method according to Supplementary Note 1 or Supplementary Note 2, wherein the central device is included in a donor node, and the distributed device is included in a mobile relay node.

[0136] (Supplementary Note 4) The communication control method according to any one of Supplementary Note 1 to Supplementary Note 3, wherein the central device and the distributed devices are included in a network node (or a network device).

[0137] (Supplementary Note 5) The communication control method according to any one of Supplementary Note 1 to Supplementary Note 4, wherein the RACH-less handover is a conditional RACH-less handover.

[0138] (Supplementary Note 6) A communication control method used in a cellular communication system, comprising: a central unit (CU) transmitting validity period information indicating a validity period of resources used in a user equipment during a conditional RACH-less handover to a distributed unit (DU), and the distributed unit transmitting the validity period information to the central unit; and a step by the central unit transmitting a conditional reconfiguration including the validity period information to the user equipment.

[0139] (Supplementary Note 7) The communication control method according to Supplementary Note 6, further comprising the step of: the user equipment discarding the conditional reconfiguration when the validity period has elapsed; and performing a RACH-less handover when a trigger condition indicated in the conditional reconfiguration is satisfied before the validity period has elapsed.

[0140] (Appendix 2) Introduction The WID for mobile IAB was revised in RAN#97e with the following objectives: The detailed objectives of the WI are as follows: - Define mobility / topology adaptation procedures to enable IAB node mobility, including inter-donor mobility (full mobility) of the entire mobile IAB node. - A mobile IAB node can be attached to a fixed (intermediate) IAB node. Optimizations specific to the scenario where a mobile IAB node connects to a stationary (intermediate) IAB node or directly to an IAB donor DU are not prioritized. - Mobility of dual-attached IAB nodes is deprioritized. - Enhance the mobility of IAB nodes and their UEs, including aspects related to group mobility. There are no optimizations for targeting surrounding UEs. Note: Solutions should avoid touching on topics already discussed or excluded from Rel-17, with the exception of enhancements specific to IAB node mobility. - Mitigation of interference due to IAB node mobility, including avoidance of potential reference and control signal collisions (PCI, RACH, etc.). The following principles should be respected: - Mobile IAB nodes should be able to serve legacy UEs. - Solutions providing optimization for mobile IAB may involve enhancements to Rel-18 UE.

[0141] One of the key challenges in Rel-18 is how to efficiently perform handovers of multiple descendant UEs while moving between mobile IAB nodes. This appendix provides details of the mobility enhancements for mobile IAB.

[0142] Discussion RACH-less Handover for Rel-18 UE RAN2#119e has reached the following agreement: R2 assumes that for onboard RRC CONNECTED UEs handed over with mobile IAB nodes, a RACH-less procedure may be considered (also dependent on the assumption of UL synchronization).

[0143] In LTE, RACH-less handover is configured using the applicable Timing Advance (TA) and Uplink Grant (UL) information in MobilityControlInfo as follows:

[0144] Regarding the TA value for a UE in a RACH-less handover during an IAB node transition, since the source and target cells are provided via the same "physical" DU (but dual "logical" DU), the UE is assumed to apply the latest TA value to access the target cell. In other words, the "physical" distance from the UE must be the same. Therefore, there is no need for the UE to configure an explicit TA value. On the other hand, if RACH-less handover is used in other scenarios, such as a mobile IAB-MT handover, a generic approach like the LTE configuration is required.

[0145] Proposal 1: RAN2 should discuss whether for RACH-less handover of the UE, the UE should implicitly apply the latest TA value or explicitly configure the corresponding TA value.

[0146] Since the UE needs to transmit RRCReconfigurationComplete within the UL resources provided by the target cell, UL grant information needs to be configured in the UE.

[0147] Proposal 2: RAN2 should agree for RACH-less handover of UE that UL grant information is set by the target IAB donor CU.

[0148] Considering the RRC IE structure of NR, since RACH-less handover is indicated by the target IAB donor CU during the handover procedure, it can be assumed that the RACH-less setting is included in reconfigurationWithSync in CellGroupConfig.

[0149] Proposal 3: RAN2 should agree that RACH-less handover is configured with a handover command (reconfiguration with synchronization).

[0150] One question is whether RACH-less handover can also be applied to conditional handover. RAN2#119e agreed that it would be useful to support conditional RACH-less handover since "R2 assumes that CHO or delayed RRC configuration can be the baseline for group mobility."

[0151] Proposal 4: RAN2 should discuss whether RACH-less handover can also be configured as a conditional handover (conditional reconfiguration).

[0152] Legacy UE Handover Procedure RAN2#119e reached the following agreement: R2 assumes that CHO or delayed RRC config can be the baseline for group mobility (its applicability to IABMT mobility needs further study).

[0153] WID makes it clear that legacy UEs should be served by mobile IAB nodes. The following principles should be respected: - Mobile IAB nodes should be able to serve legacy UEs. - Solutions providing optimization for mobile IAB may involve enhancements to Rel-18 UE functionality.

[0154] Conditional Handover (CHO) was introduced in Rel-16, so Rel-15 UEs do not support the conditional reconfiguration function. Therefore, CHO cannot be used as a baseline for group mobility during mobile IAB node transition. Using the traditional handover command as a baseline, CHO should provide some enhancements for efficient group mobility for UEs in Rel-16 and beyond.

[0155] Observation 1: Although conditional handover was introduced in Rel-16, mobile IAB nodes should also support Rel-15 UEs. Therefore, traditional handover commands are the only way to control the mobility of Rel-15 UEs.

[0156] Regarding the legacy handover command, RAN2 agreed on "delayed RRC config" as one of the candidates. However, it is unclear whether this "delayedRRCconfig" is intended to be the same as the deferred / conditional delivery of RRC reconfiguration messages specified in Rel-17, i.e., Solution 1. If it is deferred / conditional delivery, it will work for legacy UEs, including Rel-15 UEs. If it is not, it may not work depending on the intended solution(s). Therefore, RAN2 needs to clarify what is intended by "delayed RRC config".

[0157] Proposal 5: RAN2 should clarify whether the deferred / conditional delivery of RRC messages specified in Rel-17 is the same as the "delayed RRC config" agreed upon in the previous meeting.

[0158] RAN2#119e supported the following points: P3: Regarding the "dual-DU-way" with full migration, RAN2 can discuss whether a legacy UE should consider the two logical cells / DUs as separate physical cells or as the same physical cell, and in either case what procedures the legacy UE needs to perform.

[0159] Handover to the same PCI may be possible from a signaling point of view, but it is unclear whether the UE risks making any errors.

[0160] Furthermore, if CHO is used for Rel-16 UE, i.e., there is only A3 / A5 based trigger, if these PCIs are the same, the UE may perceive the RSRP from the source cell and the RSRP from the target cell as the same, and therefore the condition cannot be met.

[0161] Also, if the PCI needs to be changed during the transition of the mobile IAB node, i.e., to avoid PCI collisions, the PCI of the target cell needs to be different from the PCI of the source cell.

[0162] That is, even if the source and target cells are "physically" served by the same IAB node, the PCIs are different.

[0163] Proposal 6: RAN2 should assume that the two logical cells / DUs have different PCIs.

[0164] Cell Reselection for Rel-18 UE RAN2#119e supported the following points: P1: RAN2 discusses scenarios to enhance cell (re)selection with mobile IAB nodes, for example, based on the mobile IAB node's broadcast parameters.

[0165] Two main scenarios and several subcases are considered: Scenario A: The mobile IAB node is moving with a camped UE. Subcase A1: The UE (e.g., a train) needs to stay on the mobile IAB node. Subcase A2: Surrounding UEs (e.g., outside the train) should not camp on the mobile IAB node. Scenario B: The mobile IAB node is stationary with the camped UE. Subcase B1: The UE (e.g., still on the train) stays on the mobile IAB node. Subcase B2: The UE (e.g., getting off the train) needs to reselect a fixed cell (e.g., a macrocell). Subcase B3: The surrounding UE (e.g., getting on the train) needs to reselect a mobile IAB node. Subcase B4: The surrounding UE (e.g., still at the station) should stay on the fixed cell.

[0166] Subcases A2, B3, and B4 are desirable behaviors for surrounding UEs. However, WID clearly states that there is no optimization targeting surrounding UEs. For subcase B3, the UE becomes subcase B1 or B2 after getting on the train, but the initial state of the UE remains that of a surrounding UE. Therefore, these subcases are not of interest.

[0167] Enhances mobility of IAB-nodes and their UEs, including aspects related to group mobility. No optimization for targeting surrounding UEs.

[0168] Observation 2: Optimization targeted at surrounding UEs is outside the scope of WI.

[0169] In subcase A1, the UE moves with the mobile IAB node, so the RSRP and RSRQ from the mobile IAB node are always stable and sufficiently good, for example, when the mobile IAB node broadcasts its frequency priority as "7" or broadcasts its cell as an HSDN cell.

[0170] It can also be considered that a train has multiple cars, and a mobile IAB node is deployed in each car. Even if the UE moves between cars, one of the cells of the mobile IAB node is always more stable from the perspective of the UE in the train than the external macro cell. Furthermore, as a typical case, it is assumed that the mobile IAB node cells operate on the same frequency. In this case, the existing intra-frequency cell reselection, i.e., the R criterion, works properly.

[0171] So cell reselection based on existing radio conditions works well and does not need to be augmented with, for example, some broadcast information.

[0172] Observation 3: A UE moving with an IAB node can camp on the IAB node based on existing radio condition-based cell reselection and appropriate frequency priority.

[0173] In subcases B1 and B2, there is no way for the AS to know whether the user will stay on the train or leave the train. In this case, even if the mobile IAB node broadcasts some information, the UE cannot decide which cell (mobile IAB node or fixed macrocell) to ultimately reselect to. Therefore, which cell the UE should reselect to ultimately depends on the radio conditions and frequency priorities.

[0174] Observation 4: If the UE and the mobile IAB node go down, the UE cannot determine whether to reselect the mobile IAB node unless the UE knows the user's intention.

[0175] In summary, the existing cell reselection mechanism, i.e., cell reselection mechanism based on radio conditions and frequency priority, still works well, so no enhancements are needed for the UE to perform cell reselection.

[0176] HSDN is useful for subcase A1 because it can be supported by mobile IAB nodes without any specification changes.

[0177] Proposal 7: RAN2 should agree that no enhancements are required for UEs to perform cell reselection to and from mobile IAB nodes.

[0178] Mobile IAB Node Indication RAN2#119e supported the following points: P2: It can be discussed whether a mobile IAB-MT needs to send a mobile IAB indication (Capability or Mobility) to an IAB donor CU.

[0179] In RAN3#117e, the following agreements have been made: Donor CUs should understand that IAB nodes are "mobile".

[0180] In Rel-16 IAB, IAB Node Indication is sent via Msg5, which is intended for use by a provider to select an AMF that supports IAB. Therefore, whether a provider needs to select an AMF that supports mobile IAB is a matter of deciding whether to send mobile IAB Node Indication via Msg5, and this is up to RAN3.

[0181] It has been pointed out that the donor CU can obtain real-time mobility status through existing measurement reports such as Immediate MDT. Such mobility status information is considered useful for predictive mobility control. The presenter clarified that the mobile IAB node indication is necessary for the provider to configure the mobile IAB node with the appropriate measurement settings.

[0182] Therefore, at least from the AS's perspective, a mobile IAB node indication should be sent by the IAB-MT, but whether such an indication needs to be sent in Msg5 or Capability signaling is unclear and up to RAN3.

[0183] Proposal 8: RAN2 should agree that the mobile IAB node indication is sent in an RRC message. It is up to RAN3 whether the RRC message is Msg5 or Capability signaling.

[0184] Access Restrictions for Mobile IAB Nodes In WID, mobile IAB nodes are assumed to serve only UEs. - A mobile IAB node has no descendant IAB nodes and serves only UEs.

[0185] To ensure this requirement, RAN2#119e has agreed that: - Not broadcasting the IAB support indication is sufficient to prevent other IAB nodes from accessing the mobile IAB (with no further impact on the specification).

[0186] Regarding the part "(without further impact on the specification)," it is questionable whether it is really sufficient to leave it to the implementation. Since WID clearly requires that a mobile IAB node cannot access other mobile IAB nodes, it is necessary to clarify this premise in the specification to avoid confusion in mobile IAB implementations. Therefore, it is desirable for the Stage-2 specification to either incorporate the above agreement or clarify that "a mobile IAB node cannot access other mobile IAB nodes in this release."

[0187] Proposal 9: RAN2 should agree to include in the Stage-2 specification that in this release, when an IAB node acts as a mobile IAB node, it shall not set the IAB support IE in the SIB.

[0188] Introduction The WID for mobile IAB was revised in RAN#97e with the following objectives: Detailed objectives of the WI are as follows: - Define mobility / topology adaptation procedures to enable IAB node mobility, including inter-donor mobility (full mobility) of the entire mobile IAB node. - Mobile IAB nodes can be attached to fixed (intermediate) IAB nodes. Optimizations specific to scenarios where a mobile IAB node connects to a stationary (intermediate) IAB node or directly connects to an IAB donor-DU are not prioritized. - Mobility of dual-attached IAB nodes is deprioritized. - Enhance mobility for IAB nodes and their UEs, including aspects related to group mobility. There are no optimizations for targeting surrounding UEs. Note: Solutions should avoid touching on topics already discussed or excluded from Rel-17, with the exception of enhancements specific to IAB node mobility. - Mitigation of interference due to IAB node mobility, including avoidance of potential reference and control signal collisions (PCI, RACH, etc.). The following principles should be respected: - Mobile IAB nodes should be able to serve legacy UEs. - Solutions providing optimization for mobile IAB may involve enhancements to Rel-18 UE.

[0189] One of the objectives is to mitigate interference due to IAB node mobility. This appendix discusses potential issues regarding PCI collisions and RACH configuration collisions.

[0190] Discussion Dynamic PCI change mechanism RAN2#119e supported the following points: P4: RAN2 may discuss whether there are any PCI partitioning issues that need / can be addressed (for use in application scenarios) if found within the R2 scope. From the R2 perspective, the need and feasibility of a dynamic PCI change mechanism may be discussed. Also, discuss whether enhancements to current UE / MT reporting are useful / necessary to improve PCI collision detection.

[0191] Two scenarios of PCI collisions are considered: Scenario 1: The PCI of a mobile IAB node collides with an adjacent cell; Scenario 2: The PCIs of two mobile IAB nodes that move to the same target donor collide with each other.

[0192] In Scenario 1, existing PCI partitioning may work if the PCI space for fixed cells (e.g., macrocells) and the PCI space for mobile IAB-nodes are separated. However, there may be cases where a small PCI space becomes a problem, such as in areas with many small cells where there is a shortage of PCI.

[0193] In scenario 2, if PCI partitioning is used, the PCI space of mobile IAB nodes may need to be further segregated or a global PCI (i.e., not reusable in the PLMN) may need to be assigned to each IAB node. Given the limited number of PCIs, PCI partitioning is not a practical solution.

[0194] In particular, scenario 2 requires a dynamic PCI change mechanism.

[0195] Proposal 1: RAN2 should agree that a dynamic PCI change mechanism is necessary, especially in the case of PCI collision between two mobile IAB nodes.

[0196] There are three possible approaches to PCI collision avoidance: IAB-MT measurement, UE reporting, and network coordination.

[0197] In IAB-MT measurements, if a mobile IAB node detects the same PCI from a neighboring cell, it is assumed that the mobile IAB node will change its own PCI. However, by the time the IAB-MT detects the same PCI, a PCI collision has already occurred.

[0198] In UE reporting, if a UE detects and reports the same PCI from different cells, the donor is expected to request the mobile IAB node to change the PCI. However, it is questionable whether the UE can determine whether different cells are using the same PCI. Similarly, a PCI collision may already exist when the UE detects the same PCI.

[0199] In network coordination, during the migration of a mobile IAB node, the source donor may inquire of the target donor whether the PCI used by the migrating mobile IAB node is acceptable. Furthermore, the target donor may ask neighboring gNBs the same question, for example, whether another mobile IAB node in the vicinity of the target donor is using the same PCI, to avoid future PCI collisions. This approach can prevent PCI collisions in advance. Therefore, RAN2 should consider dynamic PCI changes to occur only during the migration of a mobile IAB node, and there is no enhancement from RAN2's perspective. It is up to RAN3 how RAN3 avoids and changes PCI collisions during the migration of a mobile IAB node.

[0200] Proposal 2: RAN2 should assume that dynamic PCI changes only occur during IAB node transition procedures and that PCI conflicts are resolved by network coordination. It is up to RAN3, not RAN2, how to avoid PCI conflicts.

[0201] RACH Configuration Collision RAN2#119e supported the following points: P5: RAN2 can discuss whether there is a problem of RACH configuration collision between the mobile IAB and the fixed network from RAN2's point of view and / or whether RAN2 should ask RAN1 to consider RAN1 related aspects.

[0202] If two adjacent cells use the same PRACH configuration, an increased PRACH collision rate may be an issue. Additionally, incorrect RARs may also be a risk, such as when a UE transmits a PRACH to cell A, but it is also received by cell B, causing the UE to receive an RAR from cell B. If RAN2 identifies these potential issues, it should request RAN1 for further analysis.

[0203] Observation 1: RAN1 is a suitable group to analyze the collision problem of RACH configuration.

Claims

**Claim 1** A communication control method, comprising: a user equipment receiving information for setting a resource for performing a RACH (Random Access Channel) less handover from a cell of a source DU (Distribution Unit) of a mobile IAB (Integrated Access and Backhaul) node to a cell of a target DU; the user equipment transmitting an RRC message to the cell of the target DU by using the resource information without performing a random access procedure; wherein the source DU is F1-connected to a CU of a source donor node, and the target DU is F1-connected to a CU of a target donor node A communication control method. **Claim 2** The information for setting the resource is included in an RRC reconfiguration message, wherein the user equipment transmitting the RRC message includes the user equipment transmitting an RRC reconfiguration complete message. The communication control method according to claim 1. **Claim 3** Further comprising: a CU of the target donor node transmitting a UE context setup request message to a target DU of the mobile IAB node; the CU of the target donor node receiving an F1 message for the UE context setup request message from the target DU; the CU of the target donor node transmitting the resource information included in the F1 message to the user equipment. The communication control method according to claim 1. **Claim 4** A user equipment, comprising: a receiving unit configured to receive information for setting a resource for performing a RACH less handover from a cell of a source DU of a mobile IAB node to a cell of a target DU; a transmitting unit configured to transmit an RRC message to the cell of the target DU by using the resource information without performing a random access procedure; wherein the source DU is F1-connected to a CU of a source donor node, and the target DU is F1-connected to a CU of a target donor node User equipment.

5. A mobile communication system having a user equipment and a mobile IAB (Integrated Access and Backhaul) node, wherein the user equipment receives information for setting resources for performing a RACH (Random Access Channel) less handover from a cell of a source DU (Distribution Unit) of the mobile IAB node to a cell of a target DU, the user equipment transmits an RRC message to the cell of the target DU using the resource information without performing a random access procedure, the source DU is F1-connected to a CU of the source donor node, and the target DU is F1-connected to a CU of the target donor node Mobile communication system.

6. In a user equipment, a process of receiving information for setting resources for performing a RACH (Random Access Channel) less handover from a cell of a source DU (Distribution Unit) of a mobile IAB (Integrated Access and Backhaul) node to a cell of a target DU, a process of transmitting an RRC message to the cell of the target DU using the resource information without performing a random access procedure, the source DU is F1-connected to a CU of the source donor node, and the target DU is F1-connected to a CU of the target donor node Program.

7. A chipset of a user equipment, executing a process of receiving information for setting resources for performing a RACH (Random Access Channel) less handover from a cell of a source DU (Distribution Unit) of a mobile IAB (Integrated Access and Backhaul) node to a cell of a target DU, executing a process of transmitting an RRC message to the cell of the target DU using the resource information without performing a random access procedure, the source DU is F1-connected to a CU of the source donor node, and the target DU is F1-connected to a CU of the target donor node Chipset.