Communication control method and mobile relay node

Abstract

A communication control method according to one aspect of the present invention is used in a cellular communication system. The communication control method includes a step for reporting, by a master node, movement-range support information supporting a movement range of a mobile relay node. Further, the communication control method includes a step for receiving the movement-range support information by the mobile relay node. Furthermore, the communication control method includes a step for determining, by the mobile relay node on the basis of the movement-range support information, whether the master node is accessible.

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.2.0 (2022-09)

[0004] A communication control method according to a first aspect is a communication control method used in a cellular communication system. The communication control method includes a step in which a parent node broadcasts movement range support information that supports a movement range of a mobile relay node. The communication control method also includes a step in which the mobile relay node receives the movement range support information. The communication control method further includes a step in which the mobile relay node determines whether or not access to the parent node is possible based on the movement range support information.

[0005] A communication control method according to a second aspect is a communication control method used in a cellular communication system, the communication control method comprising a step of a mobile relay node checking whether mobile relay node support information indicating that the mobile relay node is supported is broadcast from a serving cell and a neighboring cell, and a step of the mobile relay node accessing a selected cell when it is determined that the serving cell and all neighboring cells are not broadcasting the mobile relay node support information.

[0006] FIG. 1 is a diagram illustrating an example configuration of a cellular communication system according to one embodiment. FIG. 2 is a diagram illustrating the relationship between an IAB node, parent nodes, and child nodes. FIG. 3 is a diagram illustrating an example configuration of a gNB (base station) according to one embodiment. FIG. 4 is a diagram illustrating an example configuration of an IAB node (relay node) according to one embodiment. FIG. 5 is a diagram illustrating an example configuration of a UE (user equipment) according to one embodiment. FIG. 6 is a diagram illustrating an example protocol stack related to IAB-MT RRC connection and NAS connection. FIG. 7 is a diagram illustrating an example protocol stack related to the F1-U protocol. FIG. 8 is a diagram illustrating an example protocol stack related to the F1-C protocol. FIGS. 9(A) and 9(B) are diagrams illustrating an example of complete movement according to the first embodiment. FIGS. 10(A) and 10(B) are diagrams illustrating an example of complete movement according to the first embodiment. FIG. 11 is a diagram illustrating an example operation according to the first embodiment. FIG. 12 is a diagram illustrating an example operation according to the second embodiment. FIG. 13 is a diagram illustrating an example operation according to the third embodiment. Fig. 14 is a diagram showing an example of operation according to the fourth embodiment. Fig. 15 is a diagram showing an example of operation according to the fifth embodiment. Fig. 16 is a diagram showing scenarios and sub-cases of cell reselection of a UE. Fig. 17 is a diagram showing the configuration of RACH-less handover in LTE using applicable timing advance (TA) and uplink grant information in MobilityControlInfo.

[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] (Communication Control Method According to First Embodiment) In 3GPP, discussions are underway regarding mobile IAB node support information ("supporting mobile-IAB") that indicates support for a mobile IAB node 300M. The mobile IAB node support information is broadcast, for example, from a cell. When the mobile IAB node 300M receives the mobile IAB node support information, it can understand that the mobile IAB node 300M can access (camp or connect to) the cell. The mobile IAB node support information is, for example, 1-bit information.

[0065] On the other hand, the following methods are available for migrating the IAB node 300.

[0066] (1) Intra-CU movement (Rel-16: Intra-CU topology adaptation)

[0067] (2) Partial migration (Rel-17: Inter-CU topology adaptation / partial migration)

[0068] (3) Full Migration (Rel-18: Inter-CU Topology Adaptation / Full Migration) Depending on the range of movement of the mobile IAB node 300M, the donor node 200 (or parent node 300P) accessed by the mobile IAB node 300M may change.

[0069] For example, when the mobile IAB node 300M is limited to movement within the same CU, it can access a Rel-16 compatible donor node 200, and can also access a Rel-17 and Rel-18 compatible donor node 200. On the other hand, when the mobile IAB node 300M moves between different CUs, it must access a Rel-17 and a Rel-17 compatible donor node 200, and if it accesses a Rel-16 compatible donor node 200, it cannot move between CUs.

[0070] In this situation, assume that the donor node 200 broadcasts mobile IAB node support information. The mobile IAB node support information simply indicates that the donor node 200 that broadcasted the information can support access by the mobile IAB node 300M. The mobile IAB node 300M that receives the mobile IAB node support information does not know which release the donor node 200 that broadcasted the information corresponds to. In response to this, it is conceivable to address this by uniformly permitting the mobile IAB node 300M to access Rel-17 or Rel-18 compatible donor nodes 200, rather than Rel-16 compatible donor nodes 200. However, in this case, the mobile IAB node 300M will not be able to access Rel-16 compatible donor nodes 200. Therefore, the coverage area of ​​the donor node 200 may not be effectively utilized.

[0071] As such, the mobile IAB node support information alone cannot cover all of the migrations of the mobile IAB node 300M, and as a result, the network side may not be able to provide appropriate access to the mobile IAB node 300M.

[0072] Therefore, the first embodiment aims to enable the mobile IAB node 300M to appropriately access other nodes.

[0073] Therefore, in the first embodiment, an example will be described in which the parent node 300P (or the donor node 200) announces support information that supports the movement range of the mobile IAB node 300M, and the mobile IAB node 300M determines whether or not to access the parent node 300P (or the donor node 200) based on the support information.

[0074] Specifically, first, a parent node (e.g., parent node 300P or donor node 200) broadcasts movement range support information that supports the movement range of a mobile relay node (e.g., mobile IAB node 300M). Second, the mobile relay node receives the movement range support information. Third, the mobile relay node determines whether or not access to the parent node is possible based on the movement range support information.

[0075] This allows, for example, the mobile IAB node 300M to access the parent node 300P according to the movement range of the mobile IAB node 300M, and therefore makes it possible to appropriately access the parent node 300P.

[0076] In the following description, the parent node 300P may be used as an example of the access destination of the mobile IAB node 300M. The access destination of the mobile IAB node 300M may be the donor node 200. Alternatively, the access destination of the mobile IAB node 300M may be another node.

[0077] In the following, "access" may be explained to include "camping." "Camping" refers to, for example, a state in which the IAB-MT of the mobile IAB node 300M in an RRC idle state or an RRC inactive state has completed a cell selection procedure or a cell reselection procedure and selected a cell for monitoring system information or paging information. In addition, "access" may be explained to include "connection." "Connected" refers to, for example, a state in which the IAB-MT of the mobile IAB node 300M is in an RRC connected state with a cell and is able to exchange RRC messages with the cell. "Access" may be at least one of "camping" and "connection."

[0078] (Example of Operation According to First Embodiment) Next, an example of operation according to the first embodiment will be described.

[0079] FIG. 11 is a diagram illustrating an example of operation according to the first embodiment.

[0080] As shown in Fig. 11 , in step S10, the parent node 300P broadcasts movement range support information. The movement range support information indicates, for example, a movement range that can be supported in the node (or cell) that broadcasts the information. The parent node 300P broadcasts the movement range support information by broadcast signaling (for example, a system information block (SIB)). The parent node 300P may also transmit the movement range support information to the UE 100 by dedicated signaling (for example, a specific RRC message). Information included in the movement range support information includes, for example, the following:

[0081] First, the movement range support information may include information representing a topology adaptation function that can be supported by the parent node 300P. Specifically, the information may be any one of "Rel-16: Intra-CU topology adaptation," "Rel-17: Inter-CU topology adaptation / partial migration," and "Rel-18: Inter-CU topology adaptation / full migration." Alternatively, the information may be any one of "Rel-16," "Rel-17," and "Rel-18." The information representing the topology adaptation function may represent, for example, a movement method of the mobile IAB node 300M. The movement method of the mobile IAB node 300M may be, for example, any of "intra-CU movement," "partial movement," and "complete movement."

[0082] Second, the movement range support information may include information regarding the movement range of the mobile IAB node 300M that can be supported by the parent node 300P. Specifically, the information may be any of "short distance," "medium distance," and "long distance." "Short distance" indicates, for example, that it corresponds to "movement within a CU." Furthermore, "medium distance" indicates, for example, that it corresponds to "partial movement" between different CUs. Furthermore, "long distance" indicates, for example, that it corresponds to "complete movement" between different CUs. The information may be divided into two or four or more divisions other than three divisions. For example, in the case of two divisions, the division may be "short distance" and "long distance," with "short distance" indicating "movement within a CU" and "long distance" indicating "partial movement" and "complete movement."

[0083] In step S11, the mobile IAB node 300M receives movement range support information broadcast from the parent node 300P and determines whether or not the parent node 300P is accessible based on the movement range support information. Specifically, the mobile IAB node 300M may compare its own movement range with the movement range support information, and if the parent node 300P corresponds to its own movement range, determine that the parent node 300P is accessible. On the other hand, if the parent node 300P does not correspond to its own movement range, the mobile IAB node 300M may determine that the parent node 300P is not accessible.

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

[0085] In the first embodiment, an example was described in which the mobile IAB node 300M that received the movement range support information compares its own movement range with the movement range support information. Here, the mobile IAB node 300M has a problem of how to set its own movement range. In the second embodiment, a method for setting the movement range of the mobile IAB node 300M will be described.

[0086] Specifically, a mobile relay node (for example, the mobile IAB node 300M) receives movement range information regarding the movement range of the mobile relay node from an operation management device (for example, the OAM server 400) or an access mobility management device (for example, the AMF 11). This allows, for example, the mobile IAB node 300M to grasp its own movement range.

[0087] (Operation Example According to Second Embodiment) Next, an operation example according to the second embodiment will be described. The operation example according to the second embodiment includes two operation examples: an operation example (first operation example) in which the mobile IAB node 300M receives settings from the OAM (Operations, Administration and Management) server 400, and an operation example (second operation example) in which the mobile IAB node 300M receives settings from the AMF 11.

[0088] (First Operation Example) First, an example in which the mobile IAB node 300M receives settings from the OAM server 400 will be described.

[0089] FIG. 12 is a diagram illustrating a first operation example according to the second embodiment.

[0090] 12, in step S20, the mobile IAB node 300M connects to the OAM server 400. The mobile IAB node 300M may connect to the OAM server 400 by transmitting a predetermined IP (Internet Protocol) message to the OAM server 400.

[0091] In step S21, the OAM server 400 sets a movement range for the mobile IAB node 300M. The OAM server 400 may set the movement range by transmitting movement range information regarding the movement range to the mobile IAB node 300M. The OAM server may transmit the movement range information to the mobile IAB node 300M using an IP message. Examples of movement range information include the following:

[0092] First, the movement range information may include a movement distance pattern. Specifically, the movement distance pattern may be one of "short distance," "medium distance," and "long distance." The classification of the movement distance pattern may correspond to the classification of the information on the movement range included in the movement range support information (one of "short distance," "medium distance," and "long distance"). The number of classifications of the movement distance pattern may be two, four, or more.

[0093] Second, the movement range information may include information on whether or not the node is a mobile IAB node. Specifically, the information may be "Mobile IAB-node" (being a mobile IAB node) or "Stationary IAB-node" (being a stationary (or intermediate) IAB node). "Mobile IAB-node" may indicate that it corresponds to a "medium distance" or "long distance" distance pattern. Furthermore, "Stationary IAB-node" may indicate that it corresponds to a "short distance" (or "medium distance") distance pattern.

[0094] Third, the mobility range information may include a release version. Specifically, the release version may be any one of "Rel-16," "Rel-17," and "Rel-18." "Rel-16" may indicate that the node is configured as a stationary (or intermediate) IAB node. Furthermore, "Rel-17" and "Rel-18" may indicate that the node is configured as a mobile IAB node.

[0095] In step S22, the mobile IAB node 300M receives the movement range setting from the OAM server 400, and determines its own movement range based on the movement range information.

[0096] (Second Operation Example) Next, a second operation example will be described.

[0097] FIG. 13 is a diagram illustrating a second operation example according to the second embodiment.

[0098] 13 , in step S30, the mobile IAB node 300M establishes a connection with the AMF 11. The IAM-MT of the mobile IAB node 300M may establish a connection with the AMF 11 by sending a registration request message to the AMF 11.

[0099] In step S31, the AMF 11 performs authentication processing for the mobile IAB node 300M. The AMF 11 may cause an authentication server function (AUSF) to perform authentication processing for the mobile IAB node 300M.

[0100] In step S32, the AMF 11 transmits the authentication result to the IAM-MT of the mobile IAB node 300M. The AMF 11 transmits the authentication result to the mobile IAB node 300M using a NAS message.

[0101] First, the authentication result may be expressed as whether or not the mobile IAB node 300M has been authenticated. Alternatively, the authentication result may be expressed as whether or not the mobile IAB node 300M has been authenticated in one of the travel distance patterns (e.g., a long distance has been authenticated).

[0102] Second, the AMF 11 may set the movement range of the mobile IAB node 300M based on the authentication result. The AMF 11 may set the movement range by sending a NAS message including movement range information to the IAB-MT of the mobile IAB node 300M. The movement range information may be the same as the movement range information set by the OAM server 400.

[0103] In step S33, the mobile IAB node 300M can determine the (permitted) movement range based on the authentication result, or based on the movement range information set by the AMF 11.

[0104] Third Embodiment Next, a third embodiment will be described.

[0105] In the second embodiment, an example was described in which a movement range was set for the mobile IAB node 300M. In the third embodiment, a description will be given of what kind of processing is performed when the mobile IAB node 300M, for which a movement range has been set, receives mobile IAB node support information from the parent node 300P.

[0106] Specifically, first, a mobile relay node (e.g., mobile IAB node 300M) determines whether a parent node (e.g., parent node 300P) has broadcast mobile relay node support information indicating that the mobile relay node is supported. Second, the mobile relay node determines whether it can access the parent node based on whether the mobile relay node support information has been broadcast and the movement range information.

[0107] In this way, the mobile IAB node 300M determines whether or not it is possible to access the parent node 300P by using not only the mobile relay node support information but also the movement range set for itself. Therefore, compared to determining whether or not it is possible to access the parent node 300P by using only the mobile relay node support information, the mobile IAB node 300M can appropriately access the parent node 300P.

[0108] (Example of Operation According to Third Embodiment) Next, an example of operation according to the third embodiment will be described.

[0109] Fig. 14 is a diagram illustrating an example of operation according to the third embodiment. Note that, before the example of operation illustrated in Fig. 14 is started, it is assumed that a movement range is set for the mobile IAB node 300M (second embodiment).

[0110] As shown in FIG. 14, in step S40, the parent node 300P broadcasts or does not broadcast the mobile IAB node support information.

[0111] In step S41, the mobile IAB node 300M determines whether the parent node 300P is broadcasting mobile IAB node support information. The mobile IAB node 300M then determines whether or not the parent node 300P can be accessed based on whether or not the mobile IAB node support information has been broadcast (or whether or not the information has been received) and the movement range set for the mobile IAB node 300M. The mobile IAB node 300M makes this determination, for example, as follows:

[0112] First, when the parent node 300P has not notified mobile IAB node support information, if the mobile IAB node 300M is set with a movement range of "short distance" (or stationary (intermediate) IAB node), the mobile IAB node 300M determines that it can access the parent node 300P.

[0113] Second, when the parent node 300P does not broadcast mobile IAB node support information, if the mobile IAB node 300M is set as its movement range to "long distance" (or mobile IAB node), the mobile IAB node 300M determines that access to the parent node 300P is not possible.

[0114] Third, if the parent node 300P broadcasts mobile IAB node support information, the mobile IAB node 300M determines that it is possible to access the parent node 300P, regardless of whether the distance is "short" or "long."

[0115] As described above, in the third embodiment, even if the parent node 300P does not broadcast mobile IAB node support information, the mobile IAB node 300M set to "short distance" (or stationary (intermediate) IAB node) is able to access the parent node (for example, the Rel-16-compliant donor node 200). Therefore, in the third embodiment, compared to when the mobile IAB node 300M is uniformly allowed to access the Rel-18-compliant donor node 200, access to the Rel-16-compliant donor node is also permitted, which makes it possible to distribute the load across the entire network or expand the coverage range.

[0116] Fourth Embodiment Next, a fourth embodiment will be described.

[0117] Assume that the mobile IAB node 300M is located in a network (or topology) under the control of a Rel-16-compliant donor node 200 and cannot find a cell that broadcasts mobile IAB node support information. In this case, the mobile IAB node 300M may determine that no cell supports the mobile IAB node, and may be unable to access the network.

[0118] Therefore, in the fourth embodiment, an example will be described in which even if the mobile IAB node 300M cannot find a cell that broadcasts mobile IAB node support information, access to the cell is permitted.

[0119] Specifically, first, the mobile relay node determines whether the serving cell and neighboring cells broadcast mobile relay node support information indicating that the mobile relay node is supported, and second, if the mobile relay node detects that the serving cell and neighboring cells do not broadcast mobile relay node support information, the mobile relay node accesses the selected cell.

[0120] This allows the mobile IAB node 300M to properly access a cell even if it is unable to find a cell that broadcasts mobile IAB node support information.

[0121] (Example of Operation According to Fourth Embodiment) Next, an example of operation according to the fourth embodiment will be described.

[0122] FIG. 15 illustrates an example of operation according to the fourth embodiment.

[0123] As shown in FIG. 15, in step S50, the mobile IAB node 300M starts processing.

[0124] In step S51, the IAB-MT of the mobile IAB node 300M monitors the serving cell and all neighboring cells to check whether mobile IAB node support information has been broadcast.

[0125] In step S52, the IAB-MT of the mobile IAB node 300M confirms that the mobile IAB node support information is not being broadcast in all cells.

[0126] In step S53, the mobile IAB node 300M considers that access to the predetermined cell is permitted. It may be pre-configured that access to the predetermined cell is permitted when the donor node 200, the AMF 11, or the OAM server 400 has not broadcast mobile IAB node support information to the mobile IAB node 300M in all cells. For example, the CU, the AMF 11, or the OAM server 400 of the donor node 200 may perform this configuration by sending an RRC message, a NAS message, or an IP message containing information indicating this configuration to the IAB-MT of the mobile IAB node 300M. The predetermined cell may be the cell with the best radio quality.

[0127] Then, the mobile IAB node 300M begins accessing the cell selected as the predetermined cell.

[0128] In step S54, the mobile IAB node 300M ends the series of processes.

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

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

[0131] The term "network node" primarily refers to a base station, but may also refer to a core network device or a part of a base station (CU, DU, or RU). A network node may also be configured by a combination of at least a part of a core network device and at least a part of a base station.

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

[0133] 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).

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

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

[0136] This application claims priority to U.S. Provisional Application No. 63 / 421,705 (filed November 2, 2022), the entire contents of which are incorporated herein by reference.

[0137] (Supplementary Note 1) (Supplementary Note 1) A communication control method used in a cellular communication system, comprising: a step in which a parent node broadcasts movement range support information that supports the movement range of a mobile relay node; a step in which the mobile relay node receives the movement range support information; and a step in which the mobile relay node determines whether or not access to the parent node is possible based on the movement range support information.

[0138] (Supplementary Note 2) The communication control method according to Supplementary Note 1, wherein the movement range support information indicates either a movement method of the mobile relay node that can be supported by the parent node, or a movement range of the mobile relay node that can be supported by the parent node.

[0139] (Supplementary Note 3) The communication control method according to Supplementary Note 1 or Supplementary Note 2, wherein the movement method of the mobile relay node is any one of intra-CU movement, partial movement, and complete movement.

[0140] (Supplementary Note 4) The communication control method according to any one of Supplementary Note 1 to Supplementary Note 3, further comprising a step in which the mobile relay node receives movement range information relating to a movement range of the mobile relay node from an operation management device (OAM) or an access mobility management device (AMF).

[0141] (Supplementary Note 5) A communication control method as described in any of Supplementary Notes 1 to 4, further comprising a step in which the mobile relay node determines whether the parent node has broadcast mobile relay node support information indicating that the mobile relay node is supported, and the step of determining whether access to the parent node is possible includes a step in which the mobile relay node makes a determination based on whether the mobile relay node support information has been broadcast and the movement range information.

[0142] (Supplementary Note 6) A communication control method used in a cellular communication system, comprising: a step of a mobile relay node checking whether mobile relay node support information indicating that the mobile relay node is supported is broadcast from a serving cell and a neighboring cell; and a step of the mobile relay node accessing a selected cell when the mobile relay node checks that the serving cell and all of the neighboring cells have not broadcast the mobile relay node support information.

[0143] (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 is attached to a stationary (intermediate) IAB node or directly attached to an IAB-Donor-DU are not prioritized. - Mobility of dual-attached IAB nodes is deprioritized. - Enhance the mobility of IAB nodes and their served UEs, including aspects related to group mobility. There are no optimizations related to targeting of nearby UEs. Note: Solutions should avoid touching on topics already discussed in Rel-17 or excluded from Rel-17, except for 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 capabilities.

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

[0145] Discussion UE Mobility Enhancements UE Handover Procedures RAN2#119bis-e has reached the following agreement regarding UE handover procedures: RAN2 focuses on the scenario where, during full mobility, the UE perceives two logical DU cells as different physical cells (e.g. with different PCIs if on the same carrier) and the two logical DU cells use separate physical resources (i.e. different carriers or orthogonal time and frequency resources of the same carrier, as supported in legacy L1). From the QC tdoc, the following options O1 O2 O3 are considered: 1) Message deferral by logical source IAB-DU 2) Conditional execution by UE based on broadcast indications, e.g., SIB indication of service time or DCI indication of MT mobility (including new triggered CHO) 3) Legacy CHO (with implementation-specific behavior, e.g., using source cell power down and target cell power up to trigger the actual HO) RAN2 assumes that O1 and O3 above work, and further consideration is required if O2 above (e.g., new trigger) is required.

[0146] O1 with deferred delivery is considered the baseline because it works with Rel-15 UEs. O3 with the current conditional handover (CHO) works with Rel-16 UEs. Therefore, further consideration is needed to determine whether to enhance CHO for Rel-18, such as by building on O3.

[0147] Since there are already viable solutions such as O1 and O3, it is questionable whether enhancements are really necessary. On the other hand, it is expected that at some point in the future, Rel-18 UEs will dominate the network. In this case, if there are disadvantages to the existing solutions, it would be useful to provide some enhancements for Rel-18 and later UEs. If a new solution is discussed, one of the key points is to ensure that UE handovers do not cause signaling storms, as pointed out in RAN2#119bis-e.

[0148] Proposal 1: RAN2 should discuss whether there are problems with the existing solutions for UE handover, namely deferred delivery (O1) and CHO (O3).

[0149] In the case of O1, the RRC reconfiguration with synchronization is held by the mobile IAB node and delivered to the UE when the mobile IAB-MT completes its movement to the target donor. The timing of sending the RRC reconfiguration message can be managed by the mobile IAB node, so the timing of receiving the RRC reconfiguration complete message can be controlled. This depends on the time that the two cells (i.e., provided by dual DU) are maintained, but during this period, some DL load may occur in the source cell and some UL load may occur in the target cell.

[0150] In the case of O3, the RRC reconfiguration, including the conditional reconfiguration, is transmitted in advance by the IAB donor through the mobile IAB node. This allows for the UE handover command to be prepared in advance and the DL load can be distributed in time within the source cell. On the other hand, CHO is performed when an existing event (i.e., A3 / A5) is met. Because O3 depends on the radio conditions of the source / target cells (i.e., transmit power control), it may cause a UL signaling storm in the target cell, i.e., the completion of PRACH and RRC reconfiguration, especially when the source and target cells are served from a physically quasi-common antenna.

[0151] From the above observations, O1 may need to maintain the source and target cells for a long time to reduce the DL / UL load, while O3 may cause UL signaling storms at the target cell. In other words, maintaining two cells (provided by Dual DU) for a minimum period can avoid signaling storms.

[0152] Proposal 2: If CHO is enhanced for Rel-18 UEs, RAN2 should agree on a solution that avoids signaling storms in the DL (source cell) and UL (target cell) even when the source and target cells are held for a minimum period during the movement of a mobile IAB node.

[0153] Enhancement of UE Cell Reselection Functionality RAN2#119bis-e has agreed to the following confirmations, observations, and assumptions: RAN2 has confirmed that mobile IAB is required to work with legacy UEs. RAN2 has confirmed that if a UE camps on / connects to a mobile IAB cell for a long period of time, the UE may consider itself onboard to the mobile IAB cell (i.e., the UE needs to know that this cell is such a cell). The time period requires further consideration. RAN2 makes the following assumptions regarding UEs operating in mobile IAB cells: Assumption 1: From the perspective of the mobile IAB cell's network, the configuration principles of legacy parameters (including cell (re)selection, cell reservation, and access restriction) remain unchanged compared to legacy IAB cells. Assumption 2: There is no impact on the operation of legacy UEs. Assumption 3: The newly broadcast mobile IAB cell information (if agreed) in R18 does not prohibit / control access for legacy UEs. Assumption 4: Non-enhanced UEs (including legacy UEs and non-enhanced R18 UEs) will simply ignore the newly broadcast mobile IAB cell information by R18 (if agreed). RAN2 Assumption: Mobile IAB Cell Broadcast Information To assist mobility in idle / inactive mode for Rel-18 UEs, a 1-bit mobile IAB cell type indication is introduced (further study is needed on when a UE needs to know it is onboard). How this is used needs further study (may vary depending on implementation). RAN2 has not specified any modifications to prevent surrounding UEs from accessing mobile IAB nodes from a mobile IAB WI perspective, but believes SA2 may be working on an applicable Rel-18 solution.

[0154] Two main scenarios and several sub-cases with expected UE behavior can be considered: Scenario A: The mobile IAB node is moving with a camped UE. Sub-case A1: The UE (e.g., on a train) should stay on the mobile IAB node. Sub-case 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 a camped UE. Sub-case B1: The UE (e.g., still on the train) should stay on the mobile IAB node. Sub-case B2: The UE (e.g., getting off the train) reselects a stationary cell (e.g., a macrocell). Sub-case B3: Surrounding UEs (e.g., getting on the train) need to reselect a mobile IAB node. Sub-case B4: Surrounding UEs (e.g., still at station) should stay on their fixed cells.

[0155] In subcase A1, the UE moves with the mobile IAB node. Therefore, the RSRP and RSRQ from the mobile IAB node are always stable and sufficiently good. This does not trigger a cell reselection procedure. To be precise, if the frequency priority of the mobile IAB node is higher than the external cell, the UE may not perform intra-frequency or inter-frequency measurements. For example, the mobile IAB node broadcasts its frequency priority as "7" or broadcasts its cell as an HSDN cell.

[0156] In addition, a train may have multiple cars, and a mobile IAB node may be deployed in each car. Even if the UE moves between cars, one of the mobile IAB node cells is always more stable than the external macro cell from the perspective of the UE in the train. Also, 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.

[0157] Observation 1: It is considered a typical configuration for a moving mobile IAB cell to broadcast a serving frequency priority of "7" or an HSDN cell indication to prevent UEs moving with the mobile IAB cell from undergoing cell reselection.

[0158] In subcases B1 and B2, there is no way for the AS to know whether the user will stay on the train or get off. In this case, even if the mobile IAB node broadcasts some information, the UE cannot determine which cell (mobile IAB node or fixed macrocell) to ultimately reselect to. Therefore, which cell the UE reselects to ultimately depends on the radio conditions and frequency priority. Therefore, the mobile IAB node needs to restore the serving frequency priority set as Observation 1. That is, the mobile IAB node can either broadcast the serving frequency priority in the same way as the fixed macrocell layer, or stop broadcasting the HSDN cell indication.

[0159] Observation 2: If the UE and the mobile IAB node go down, the UE cannot determine whether to reselect the mobile IAB node unless it knows the user's intention, which means it depends on the radio conditions.

[0160] Observation 3: It is typical for a stationary mobile IAB cell to revert to the frequency priority or HSDN cell indication it used when moving (i.e., similar to Observation 1).

[0161] However, given the above observations, a drawback of the current mechanism is that the SIB of a mobile IAB node needs to be changed according to its mobility state, which may not be a critical issue to solve.

[0162] Observation 4: A drawback of the current mechanism is that a mobile IAB cell needs to change its SIB depending on its mobility state, i.e., between observations 1 and 3.

[0163] For subcase A2, the UE can stay in a stationary macrocell for the same reason as in Observation 1, i.e., the UE will not perform intra-frequency measurements if the RSRP / RSRQ from the macrocell is sufficient, and will not perform inter-frequency measurements if the macrocell frequency priority is higher than the mobile IAB node's priority, or if the mobile IAB node broadcasts an HSDN cell indication (when the UE is not in a high mobility state).

[0164] For subcases B3 and B4, for the same reasons as observation 2, cell reselection should depend on radio conditions, and the typical configuration of a mobile IAB node in stationary state as in observation 3 is also applicable.

[0165] However, subcases A2, B3, and B4 are desirable behaviors for surrounding UEs. WID specifies that optimizations are not performed to target surrounding UEs. For subcase B3, after the UE boards a train, it becomes subcase B1 or B2, but the UE's initial state remains that of a surrounding UE. Therefore, these subcases are not covered by Rel-18.

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

[0167] Observation 5: Although the optimization of targeting of surrounding UEs is outside the scope of WI, the same configurations as Observations 1 and 3 may be applicable.

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

[0169] HSDN is valid for subcase A1.

[0170] Proposal 3: RAN2 should agree that no enhancement is needed for UEs to perform cell reselection with mobile IAB nodes, i.e., revert the assumption made in the previous meeting regarding "1-bit mobile IAB cell type indication".

[0171] RACH-less Handover for Rel-18 UEs 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).

[0172] In LTE, RACH-less handover is configured as shown in Figure 17 using the applicable Timing Advance (TA) and uplink grant information in MobilityControlInfo.

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

[0174] Proposal 4: 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.

[0175] Since the UE needs to transmit RRC Reconfiguration Complete within the UL resources provided by the target cell, it is necessary to configure UL grant information in the UE.

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

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

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

[0179] 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."

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

[0181] IAB-MT Mobility Enhancements Indication of Mobile IAB Node to IAB Donor CU In RAN3#117e, the following agreements have been made: The Donor CU should know that the IAB node is "mobile".

[0182] RAN2#119bis-e agreed on the following baselines: UE capability signaling is the baseline to inform the CU that the MT is of "mobile IAB" type. Further study is needed on early mobile IAB indication, e.g., in Msg5. Regarding mobility state / mode indication, R2 sees that legacy reports of mobility state (e.g., mobilityState-r16) could be reused, as well as current location reports from the UE. Further study is needed on whether any of these need to be enhanced or supplemented, e.g., for potential purposes of predictive mobility.

[0183] 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 the mobile IAB node indication via Msg5, and this is up to RAN3.

[0184] In email discussions, several companies pointed out that donor CUs 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 presenters clarified that mobile IAB node indication is necessary for providers to configure appropriate measurement settings in the mobile IAB node. However, since it is not a major issue once the donor CU configures the mobile IAB node after receiving UE capability signaling, early indication is not justified.

[0185] Therefore, it is up to RAN3 whether an early movement IAB indication is required.

[0186] Observation 6: For example, depending on whether the donor CU needs to select an AMF that supports mobile IAB, it is up to RAN3 whether early mobile IAB indication in Msg5 is required.

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

[0188] To ensure the requirement, RAN2#119e 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).

[0189] However, the agreement was reached without sufficient discussion. In particular, the part "(without further impact on the specification)" leaves open the question of whether it is appropriate to leave it up to the implementation. Since WID explicitly requires that mobile IAB nodes cannot access other mobile IAB nodes, it is considered necessary to clarify this assumption 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 "mobile IAB nodes cannot access other mobile IAB nodes in this release."

[0190] Proposal 8: 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.

[0191] Another limitation was discussed in RAN2#119bis-e and left for further consideration as follows: The case for introducing fixed network broadcasting an indication that "Mobile IAB supported" (intended for Mobile IAB MT) needs further consideration.

[0192] Several companies have noted that "whether or not an indication from the network to a mobile IAB node is required may depend on whether the mobile IAB node can camp on / attach to a regular IAB-capable cell." Assuming there are legacy IAB donors in the network, there are three releases of IAB, each supporting different mobility mechanisms: intra-CU topology adaptation in Rel-16, inter-CU topology adaptation with partial mobility in Rel-17, and inter-CU mobility with full mobility in Rel-18.

[0193] That is, technically, a mobile IAB node can connect with a Rel-16 donor if it only moves close to the donor (i.e., within cells belonging to the same donor CU). On the other hand, if the mobile IAB node moves farther away, it will need to connect with a Rel-17 or Rel-18 donor (i.e., between cells belonging to different donor CUs). In other words, a formerly mobile IAB node can be considered a stationary IAB node from a functional standpoint.

[0194] Observation 7: A mobile IAB node can connect with a Rel-16 donor if it only moves nearby, but if it moves farther away, it must connect with a Rel-17 or Rel-18 donor.

[0195] In this sense, some "supports mobile IAB" information broadcast from the parent node is necessary, but it is questionable whether a mobile IAB node can determine which cells it can connect to based on just this one-bit indication. For example, this indication is associated with the area in which the mobile IAB node can move. However, it may also mean that the mobile IAB node needs to know the area in which it moves (or whether it is considered a stationary IAB node, for example, depending on OAM configuration). In addition, it is worth considering whether there are other cases in which a mobile IAB node is allowed to connect to a parent node that does not broadcast the indication. For example, this may be the case when the mobile IAB node cannot find a parent node that broadcasts the indication. Therefore, RAN2 should discuss in detail what this indication means.

[0196] Proposal 9: RAN2 should agree to introduce some kind of "mobile IAB supported" indication. Further study is needed as to whether it is just a one-bit indication or whether there are conditions under which a mobile IAB node is allowed to access a parent node that does not broadcast the indication.

Claims

1. A communication control method used in a cellular communication system, comprising: a parent node notifying movement range support information for supporting the movement range of a mobile relay node; the mobile relay node receiving the movement range support information; the mobile relay node determining whether access to the parent node is possible based on the movement range support information. A communication control method.

2. The movement range support information represents either a movement method of the mobile relay node that can be supported by the parent node or a movement range of the mobile relay node that can be supported by the parent node. The communication control method according to Claim 1.

3. The movement method of the mobile relay node is any one of in-CU movement, partial movement, and full movement. The communication control method according to Claim 2.

4. The communication control method according to Claim 1, further comprising: the mobile relay node receiving movement range information regarding the movement range of the mobile relay node from an operation and administration management device (OAM) or an access and mobility management function (AMF). The communication control method according to Claim 1.

5. The communication control method according to Claim 4, further comprising: the mobile relay node determining whether the parent node has notified mobile relay node support information indicating that the mobile relay node is supported; and determining whether access to the parent node is possible includes the mobile relay node determining based on the presence or absence of notification of the mobile relay node support information and the movement range information. The communication control method according to Claim 4. [[ID=X]]

6. A communication control method used in a cellular communication system, comprising: a mobile relay node checking whether mobile relay node support information indicating that the mobile relay node is supported is notified from a serving cell and adjacent cells; and when the mobile relay node confirms that all of the serving cell and the adjacent cells have not notified the mobile relay node support information, accessing a selected cell. A communication control method.

7. A mobile relay node used in a cellular communication system, comprising: a receiving unit that receives, from a parent node, movement range support information for supporting the movement range of the mobile relay node notified by the parent node; and a control unit that determines whether access to the parent node is possible based on the movement range support information. A mobile relay node.

8. A mobile relay node used in a cellular communication system, comprising a control unit configured to check whether mobile relay node support information indicating support for the mobile relay node is notified from a serving cell and adjacent cells, wherein when the control unit confirms that all of the serving cell and the adjacent cells do not notify the mobile relay node support information, the control unit accesses a selected cell. Mobile relay node.