Communication control method, relay node, cellular 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 has a step for reporting: mobile relay node support information indicating that a parent node supports a mobile relay node which is capable of moving; and legacy relay node support information indicating that the parent node supports both the mobile relay node and a legacy relay node which is not capable of moving.

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.3.0 (2022-12)

[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: when a parent node broadcasts mobile relay node support information indicating that it supports movable mobile relay nodes, broadcasting legacy relay node support information indicating that it permits access of the mobile relay nodes and supports non-movable legacy relay nodes.

[0005] A communication control method according to a second aspect is a communication control method for use in a cellular communication system, comprising: a step of determining whether a parent node that broadcasts the mobile relay node support information and / or legacy relay node support information is accessible, based on whether a mobile relay node has received mobile relay node support information indicating that the mobile relay node supports mobile relay nodes and legacy relay node support information indicating that the mobile relay node is permitted to access and that the parent node supports non-mobile legacy relay nodes.

[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 IAB-MT RRC connection and 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. FIG. 9 is a diagram showing whether or not access to an IAB node according to the first embodiment is restricted. FIG. 10 is a flowchart showing a first operation example according to the first embodiment. FIG. 11 is a flowchart showing a second operation example according to the first embodiment. FIG. 12 is a flowchart showing a third operation example according to the first embodiment. FIG. 13 is a flowchart showing a first operation example according to the second embodiment. Fig. 14 is a flowchart illustrating a second operation example according to the second embodiment. Fig. 15 is a diagram illustrating a scenario and subcases of cell reselection of a UE. Fig. 16 is a diagram illustrating RACH-less handover in LTE.

[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] (Communication Control Method According to First Embodiment) Next, a communication control method according to the first embodiment will be described.

[0058] 3GPP specifies "iab-Support" (3GPP TS 38.331 V17.3.0 (2022-12)) as an information element (IE) that can be broadcast in SIB1. "iab-Support" indicates that a cell that broadcasts this "iab-Support" supports IAB and is considered as a candidate cell for cell (re)selection by an IAB node. On the other hand, if this IE is not included in SIB1, it indicates that the cell that broadcasts this SIB1 does not support IAB and / or is a barred cell for an IAB node.

[0059] That is, a cell that broadcasts "iab-Support" is a cell that can support the IAB node, and a cell that does not broadcast "iab-Support" is a cell that cannot support the IAB node. Therefore, the IAB node 300 can access a cell that broadcasts "iab-Support," but cannot access a cell that does not broadcast "iab-Support," as it is a restricted cell.

[0060] On the other hand, the 3GPP has agreed on the following points.

[0061] (X1) A mobile IAB node may camp on a Rel-16 / Rel-17 IAB-capable cell. The mobile IAB node may connect to the cell.

[0062] (X2) The "supporting mobile-IAB" indication shall be provided by a Rel-18 mobile IAB capable parent cell.

[0063] In a parent node cell, by broadcasting "iab-Support," it is possible to broadcast that it can support fixed, non-mobile IAB nodes (Rel-16 / Rel-17 IAB). Here, agreement (X1) allows mobile IAB nodes to access (camp or connect to) fixed IAB nodes. In other words, agreement (X1) allows mobile IAB nodes to access a parent node that broadcasts "iab-Support." It can be said that "iab-Support" indicates that it is possible to support not only fixed, non-mobile IAB nodes, but also access by mobile IAB nodes.

[0064] On the other hand, the agreement (X2) indicates "supporting mobile-IAB." "Supporting mobile-IAB" indicates, for example, that a mobile IAB node can be supported. In other words, when a parent node cell broadcasts "supporting mobile-IAB," a mobile IAB node can access the cell.

[0065] In this way, the parent node can advertise "iab-Support" and can also advertise "supporting mobile-IAB."

[0066] Based on the above-mentioned agreement, the presence or absence of access restrictions is summarized in a table shown in Fig. 9. Fig. 9 is a diagram showing the presence or absence of access restrictions for IAB nodes according to the first embodiment.

[0067] Considering that a parent node cell can broadcast two types of support information ("iab-Support" and "supporting mobile-IAB"), there are four cases of how to broadcast, as shown in FIG. 9. In the following, "iab-Support" may be referred to as "legacy IAB node support information." Furthermore, "supporting mobile-IAB" may be referred to as "mobile IAB node support information."

[0068] Also, in FIG. 9 , "Legacy IAB-node" represents a non-mobile (fixed) IAB node. Hereinafter, a non-mobile IAB node may be referred to as a "legacy IAB node." A legacy IAB node may be an IAB node capable of Rel-16. The legacy IAB node may be an IAB node capable of Rel-17. In FIG. 9 , "Mobile IAB-node" represents a "mobile IAB node." A mobile IAB node may be a mobile IAB node capable of Rel-18.

[0069] As shown in FIG. 9, "Case 1" and "Case 4" are clear.

[0070] That is, as shown in "Case 1," if a parent node does not broadcast either legacy IAB node support information or mobile IAB node support information, it indicates that the parent node does not support either legacy IAB nodes or mobile IAB nodes, and therefore neither legacy IAB nodes nor mobile IAB nodes can access the parent node.

[0071] Furthermore, as shown in "Case 4," if a parent node broadcasts both legacy IAB node support information and mobile IAB node support information, this indicates that the parent node can support both legacy IAB nodes and mobile IAB nodes, allowing both legacy IAB nodes and mobile IAB nodes to access the parent node.

[0072] On the other hand, in "Case 3," if the parent node broadcasts legacy IAB node support information, the mobile IAB node 300M can access the parent node, as described in the above agreement (X1). That is, the legacy IAB node support information may indicate, for example, that in addition to supporting legacy IAB nodes, it also indicates that the mobile IAB node is permitted to access (camp or connect to) the cell.

[0073] In addition, in "Case 2," the parent node does not broadcast legacy IAB node support information, so the legacy IAB node is prohibited from accessing the parent node.

[0074] However, in "Case 2," it is unclear whether the mobile IAB node can access the parent node. The mobile IAB node may consider that it cannot access the parent node because the parent node does not broadcast legacy IAB node support information. Alternatively, the mobile IAB node may consider that it can access the parent node because the parent node broadcasts mobile IAB node support information. Therefore, the mobile IAB node may not be able to properly process the cell.

[0075] Therefore, the first embodiment aims to allow the mobile IAB node to perform appropriate processing for the cell. In the first embodiment, "Case 2" will be described.

[0076] In the following, "access" may be explained to include "camping." "Camping" refers to, for example, a state in which the IAB-MT of a mobile IAB node 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. "Access" may also be explained to include "connection." "Connected" refers to, for example, a state in which the IAB-MT of a mobile IAB node 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."

[0077] In the following, the terms "parent node" and "cell of parent node" may be used interchangeably. For example, the terms "parent node" announcing legacy IAB node support information and "cell of parent node" announcing legacy IAB node support information may be used interchangeably (without distinction).

[0078] (1.1) First Operation Example According to First Embodiment A first operation example according to the first embodiment will be described.

[0079] The first operation example according to the first embodiment is processing on the parent node side, that is, an example in which the parent node prohibits the occurrence of "Case 2."

[0080] Specifically, the parent node broadcasts mobile relay node support information (e.g., mobile IAB node support information) indicating that it supports mobile relay nodes (e.g., mobile IAB nodes), and legacy relay node support information (e.g., legacy IAB node support information) indicating that it both allows access for mobile relay nodes and supports non-mobile legacy relay nodes (e.g., legacy IAB nodes).

[0081] In this way, the parent node broadcasts both the legacy IAB node support information and the mobile IAB node support information, eliminating the situation in "Case 2." This allows the mobile IAB node to properly access the parent node and properly perform processing on the parent node's cell.

[0082] The parent node may be a gNB 200. The parent node may be a fixed, non-moving IAB node 300. The parent node may be any non-moving node, and may be a macro cell, a large cell, a small cell, or an indoor cell.

[0083] FIG. 10 is a flowchart illustrating a first operation example according to the first embodiment.

[0084] As shown in FIG. 10 , in step S10, when the parent node 200P broadcasts mobile IAB node support information, it also broadcasts legacy IAB node support information. That is, the parent node 200P does not broadcast the mobile IAB node support information in order to broadcast the legacy IAB node support information, but rather broadcasts the legacy IAB node support information as a condition for broadcasting the mobile IAB node support information. Alternatively, if the parent node 200P does not broadcast legacy IAB node support information (or legacy relay node support information), it does not broadcast mobile IAB node support information (or mobile relay node support information). Therefore, the state of "Case 2" is prohibited. The parent node 200P broadcasts both mobile IAB node support information and legacy IAB node support information. The configuration of the information element (IE) in the SIB may be expressed as "to set the information element (IE) for mobile IAB node support information, the information element (IE) for legacy IAB node support information must be set." Specifically, the IE configuration may be such that setting the legacy IAB node support information is a conditional mandatory when setting the mobile IAB node support information.

[0085] The mobile IAB node 300M (its IAB-MT) receives two pieces of support information from the parent node 200P. Therefore, the mobile IAB node 300M receives the two pieces of support information and becomes able to access the cell ("Case 4").

[0086] (1.2) Second Operation Example According to First Embodiment Next, a second operation example according to the first embodiment will be described.

[0087] The second operation example according to the first embodiment is processing on the mobile IAB node 300M side in "Case 2."

[0088] Specifically, first, a parent node (e.g., parent node 200P) broadcasts mobile relay node support information (e.g., mobile IAB node support information) without broadcasting legacy relay node support information (e.g., legacy IAB node support information). Second, if a mobile relay node (e.g., mobile IAB node 300M) does not receive legacy relay node support information, it determines that access to the parent node is not possible, regardless of whether the mobile relay node support information is received.

[0089] In this way, if the mobile IAB node 300M does not receive the legacy IAB node support information, it determines that it cannot access the parent node that broadcast the legacy IAB node support information, regardless of whether it has received the mobile IAB node support information. Therefore, the mobile IAB node 300M can appropriately process the parent node even in the state of "Case 2."

[0090] FIG. 11 is a flowchart illustrating a second operation example according to the first embodiment.

[0091] 11, in step S20, parent node 200P broadcasts mobile IAB node support information without broadcasting legacy IAB node support information. Mobile IAB node 300M (its IAB-MT) receives mobile IAB node support information from parent node 200P without receiving legacy IAB node support information.

[0092] In step S21, if the mobile IAB node 300M (its IAB-MT) does not receive the legacy IAB node support information, it determines that it cannot access the parent node 200P, regardless of whether it has received the mobile IAB node support information. In this case, the mobile IAB node 300M may determine that the cell of the parent node 200P is barred.

[0093] The second operation example according to the first embodiment corresponds to "Prohibited" in "Case 2" in FIG.

[0094] (1.3) Third Operation Example According to First Embodiment Next, a third operation example according to the first embodiment will be described.

[0095] The third operation example according to the first embodiment is also processing on the mobile IAB node 300M side in "Case 2."

[0096] Specifically, first, a parent node (e.g., parent node 200P) broadcasts mobile relay node support information (e.g., mobile IAB node support information) without broadcasting legacy relay node support information (e.g., legacy IAB node support information). Second, when a mobile relay node (e.g., mobile IAB node 300M) receives mobile relay node support information, it determines that access to the parent node is possible, regardless of whether the legacy relay node support information has been received.

[0097] As described above, in the third operation example according to the first embodiment, when the mobile IAB node 300M receives mobile IAB node support information from the parent node 200P, it determines that it can access the cell of the parent node 200P that broadcast the mobile IAB node support information, regardless of whether it has received legacy IAB node support information. Therefore, even in the "Case 2" state, the mobile IAB node 300M can appropriately process the cell. This is effective, for example, when the parent node 200P is a base station installed for the mobile IAB node 300M. The base station can operate as a base station dedicated to the mobile IAB node 300M.

[0098] FIG. 12 is a flowchart illustrating a third operation example according to the first embodiment.

[0099] 12, in step S30, parent node 200P broadcasts mobile IAB node support information without broadcasting legacy IAB node support information. Mobile IAB node 300M receives the mobile IAB node support information from parent node 200P without receiving the legacy IAB node support information.

[0100] In step S31, the mobile IAB node 300M has received the mobile IAB node support information, and therefore determines that it is able to access the parent node 200P, regardless of whether it has received the legacy IAB node support information. The mobile IAB node 300M may ignore the absence of legacy IAB node support information and determine that it is able to access the parent node 200P in accordance with the reception of the mobile IAB node support information. Under current specifications, the mobile IAB node 300M cannot access (or considers as barred) cells that do not broadcast legacy IAB node support information. However, the mobile IAB node 300M has canceled this specification and determined that it is able to access the parent node 200P. Note that a legacy IAB node determines that it is unable to access (or considers as barred) the parent node 200P.

[0101] The third operation example according to the first embodiment corresponds to "Allowed" in "Case 2" in FIG.

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

[0103] In the first embodiment, "Case 2" in Fig. 9 has been described. In the second embodiment, "Case 3" in Fig. 9 will be described. In particular, in the second embodiment, the conditions under which the mobile IAB node 300M accesses the parent node in "Case 3" will be described.

[0104] (First operation example according to the second embodiment) The first operation example according to the second embodiment is an operation example in which, in "Case 3", the mobile IAB node 300M accesses the parent node 200P, on the condition that it is permitted to connect to the network.

[0105] Specifically, first, a network device (e.g., AMF 11) transmits connection authorization information to a mobile relay node indicating whether or not to permit connection to a network that supports legacy relay nodes (e.g., legacy IAB nodes) but does not support mobile relay nodes (e.g., mobile IAB node 300M). Second, a parent node (e.g., parent node 200P) broadcasts legacy relay node support information without broadcasting mobile relay node support information. Third, when a mobile relay node receives legacy relay node support information without receiving mobile relay node support information from a parent node, the mobile relay node determines whether or not access to the parent node is possible based on the connection authorization information.

[0106] In this way, when the mobile IAB node 300M receives legacy IAB node support information without receiving mobile IAB node support information from the parent node 200P (i.e., "Case 3"), the mobile IAB node 300M determines whether to allow access to the parent node 200P based on the connection permission information. Therefore, in the state of "Case 3," the conditions for accessing the parent node 200P become clear, and the mobile IAB node 300M can perform appropriate processing on the cell.

[0107] 13 is a flowchart illustrating a first operation example according to the second embodiment. In the following, the AMF 11 will be described as an example of a network device, but the network device may be another network device such as an operation management device (or an OAM (Operations, Administration and Management) server).

[0108] As shown in FIG. 13 , in step S40, the mobile IAB node 300M receives connection permission information from the AMF 11. The connection permission information is, for example, information indicating whether or not connection to a network that supports legacy IAB nodes but does not support the mobile IAB node 300M is permitted. The mobile IAB node 300M that has received the connection permission information can determine whether or not connection to the network is permitted. The mobile IAB node 300M (its IAM-MT) may perform an initial connection and receive connection permission information from the AMF 11 in the registration procedure. At this time, the AMF 11 may perform authentication processing for the mobile IAB node 300M, and the connection permission information may be included in the authentication information transmitted from the AMF 11 to the mobile IAB node 300M. The connection permission information may include information about a cell to which connection is permitted. The information about the cell may be a cell identifier or a gNB identifier. The information may also be information about a cell to which connection is not permitted. Using this information, the mobile IAB node 300M can determine whether or not it is possible to connect to each cell in which it is currently camped.

[0109] In step S41, the parent node 200P broadcasts the legacy IAB node support information without broadcasting the mobile IAB node support information. The mobile IAB node 300M (its IAB-MT) receives the legacy IAB node support information from the parent node 200P without receiving the mobile IAB node support information.

[0110] In step S42, the mobile IAB node 300M (the IAB-MT thereof) determines whether or not access to the parent node 200P is permitted based on the connection permission information. Specifically, the following operations are performed.

[0111] First, if the connection authorization information indicates that connection to the network is permitted, the mobile IAB node 300M determines that it is possible to access the parent node 200P that broadcasts legacy IAB node support information without broadcasting mobile IAB node support information. That is, in "Case 3," if the connection authorization information indicates that connection to the network is permitted, the mobile IAB node 300M determines that it is possible to access the parent node 200P. For example, if the mobile IAB node 300M cannot find a cell that broadcasts mobile IAB node support information, it can determine that it is possible to access a cell that broadcasts legacy IAB node support information, provided that connection to the network is permitted. Note that the mobile IAB node 300M may also determine that it is possible to access other parent nodes that broadcast mobile IAB node support information and legacy IAB node support information, provided that connection to the network is permitted ("Case 4"). That is, the mobile IAB node 300M determines that it can access at least the parent node that broadcasts the legacy IAB node support information.

[0112] Second, if the connection permission information does not permit connection to the network, the mobile IAB node 300M determines that it is not able to access the parent node 200P. That is, in "Case 3," if the connection permission information does not permit connection to the network, the mobile IAB node 300M determines that it is not able to access the parent node 200P, even if the parent node 200P broadcasts legacy IAB node support information. In this case, the mobile IAB node 300M determines that it is able to access another parent node that broadcasts mobile IAB node support information ("Case 2"). The mobile IAB node 300M may determine that a parent node that does not broadcast mobile IAB node support information is barred.

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

[0114] The third operation example according to the second embodiment is an operation example in which the mobile IAB node 300M accesses the parent node 200P in accordance with the movement state of the mobile IAB node 300M in "Case 3."

[0115] Specifically, a parent node (e.g., parent node 200P) broadcasts legacy relay node support information (e.g., legacy IAB node support information) without broadcasting mobile relay node support information (e.g., mobile IAB node support information). Second, a mobile relay node (e.g., mobile IAB node 300M) determines whether or not to allow access to the parent node depending on the movement state of the mobile relay node.

[0116] As a result, for example, a mobile IAB node 300M can determine whether or not to access a parent node 200P that broadcasts legacy IAB node support information without broadcasting mobile IAB node support information, based on its own movement state, thereby clarifying the conditions for accessing the parent node 200P and enabling appropriate processing for the cell.

[0117] 14 is a flowchart illustrating a second operation example according to the second embodiment. In the second operation example according to the second embodiment, the speed state of the mobile IAB node 300M (for example, a low-speed moving state (or stationary), a high-speed moving state, etc.) will be described as an example of the moving state.

[0118] 14, in step S50, parent node 200P broadcasts legacy IAB node support information without broadcasting mobile IAB node support information. This results in the state of "Case 3." Mobile IAB node 300M (its IAB-MT) receives legacy IAB node support information from parent node 200P without receiving mobile IAB node support information.

[0119] In step S51, the mobile IAB node 300M determines whether or not it is possible to access the parent node 200P, depending on its own movement state. Specifically, the process is as follows.

[0120] First, when the mobile IAB node 300M is in a slow-moving state (or a stationary state), it determines that it can access a parent node 200P that broadcasts legacy IAB node support information without broadcasting mobile IAB node support information. In "Case 3," when the mobile IAB node 300M is moving at a slow speed, if the parent node 200P can support a legacy IAB node instead of the mobile IAB node 300M, it can determine that it can accept the mobile IAB node 300M. The slow-moving state (or stationary state) may be determined by the mobile IAB node 300M measuring its own moving speed based on its own sensor (such as a speed sensor) or GNSS reception signals, and determining that the moving speed is equal to or less than a speed threshold. The speed threshold may be set (or broadcast) in advance by the gNB 200. The speed threshold may also be set by the AMF 11. Note that when the mobile IAB node 300M is in a slow-moving state (or a stationary state), it may determine that it can access other parent nodes that broadcast mobile IAB node support information and legacy IAB node support information ("Case 4"). In other words, when the mobile IAB node 300M is in a slow-moving state (or a stationary state), it determines that it can access at least parent nodes that broadcast legacy IAB node support information.

[0121] Second, when the mobile IAB node 300M is in a high-speed moving state, it determines that it cannot access a parent node 200P that broadcasts legacy IAB node support information without broadcasting mobile IAB node support information. That is, in "Case 3," when the mobile IAB node 300M is in a high-speed moving state, even if the parent node 200P broadcasts legacy IAB node support information, the mobile IAB node 300M determines that it cannot access the parent node 200P. This is because, in "Case 3," when the mobile IAB node 300M is moving at high speed, it can be determined that a parent node 200P that can support a legacy IAB node, but not the mobile IAB node 300M, cannot accept the mobile IAB node 300M. The high-speed moving state may be determined by the mobile IAB node 300M measuring its own moving speed based on its own sensor (e.g., a speed sensor) or GNSS reception signals, etc., and determining that the moving speed is faster than a speed threshold. When the mobile IAB node 300M is moving at high speed, it determines that it can access other parent nodes that broadcast mobile IAB node support information ("Case 2"). When the mobile IAB node 300M is moving at high speed, it may determine that parent nodes that do not broadcast mobile IAB node support information are barred.

[0122] (Third Operation Example According to Second Embodiment) In the second operation example according to the second embodiment, the speed state of the mobile IAB node 300M has been described as an example of the movement state, but the movement state is not limited to this. Movement range information of the mobile IAB node 300M may also be used as the movement state. The movement range information is information that indicates the movement range of the mobile IAB node 300M. The movement range information is, for example, information that is set in advance in the mobile IAB node 300M from a network device such as an operation management device (or an OAM server).

[0123] That is, the third operation example according to the second embodiment is an example in which, in "Case 3", the mobile IAB node 300M determines whether or not access to the parent node 200P is permitted based on the movement range information.

[0124] Specifically, first, the operation management device sets movement range information indicating a movement range to a mobile relay node (e.g., mobile IAB node 300M). Second, if the movement range of the mobile relay node is equal to or smaller than a range threshold, the mobile relay node determines that access to a parent node (e.g., parent node 200P) is possible, and if the movement range of the mobile relay node is greater than the range threshold, determines that access to the parent node is not possible.

[0125] In this way, in the third operation example of the second embodiment, the mobile IAB node 300M can determine whether or not access to the parent node 200P is possible based on the movement range information, so the conditions for whether or not access is possible become clear and processing for the cell can be performed appropriately.

[0126] 14 is used for the third operation example according to the second embodiment, as with the second operation example according to the second embodiment. In this case, by replacing "low-speed moving state (or stationary state)" with "narrow-range movement" and "high-speed moving state" with "wide-range movement," the third operation example according to the second embodiment can be implemented in the same way as the second operation example according to the second embodiment.

[0127] Note that "narrow range" refers to, for example, a range within one or more cells managed by the same donor node (CU). When the mobile IAB node 300M moves within the cell, this is "narrow range movement." On the other hand, "wide range" refers to, for example, a range that does not have the above restrictions and includes cells managed by other donor nodes (CUs). When the mobile IAB node 300M moves within a range that includes the cell, this is "wide range movement."

[0128] Specifically, for example, the following applies. That is, in the mobile IAB node 300M, movement range information is set by the operation management device. Also, a range threshold is set (or broadcast) in advance for the mobile IAB node 300M by the gNB 200. Therefore, in the mobile IAB node 300M, when the movement range information is equal to or less than the range threshold, it can be determined that the node is moving in a "narrow range." In this case, the mobile IAB node 300M determines that it can access the parent node 200P that broadcasts legacy IAB node support information without broadcasting mobile IAB node support information. This is because, in the case of a mobile IAB node 300M with narrow range movement, it can be determined that the parent node 200P can also support the mobile IAB node 300M. On the other hand, in the case of a mobile IAB node 300M, when the movement range information is a range wider than the range threshold, it can be determined that the node is moving in a "wide range." In this case, the mobile IAB node 300M determines that it cannot access the parent node 200P that broadcasts legacy IAB node support information without broadcasting mobile IAB node support information. This is because, in the case of a mobile IAB node 300M with wide-range movement, it can be determined that a parent node 200P that can support legacy IAB nodes but not the mobile IAB node 300M cannot accept the mobile IAB node 300M.

[0129] [Other Embodiments] In the first and second embodiments, an example was described in which the mobile IAB node 300M determines whether or not to allow access to the parent node 200P based on whether or not it has received mobile IAB node support information and legacy IAB node support information.

[0130] That is, based on whether or not a mobile relay node (e.g., mobile IAB node 300M) has received mobile relay node support information (e.g., mobile IAB node support information) indicating that it supports mobile relay nodes, and legacy relay node support information (e.g., legacy IAB node support information) indicating that it supports both mobile relay nodes and non-mobile legacy relay nodes (e.g., legacy IAB nodes), it determines whether or not it is possible to access the parent node (e.g., parent node 200P) that notified the mobile relay node support information and / or legacy relay node support information.

[0131] This allows, for example, the mobile IAB node 300M to determine whether or not it can access the parent node based on whether or not it has received mobile IAB node support information and legacy IAB node support information, thereby enabling it to perform appropriate processing on the parent node's cell.

[0132] The above-described operational flows are not limited to being implemented independently, but can also 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.

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

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

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

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

[0137] The functions performed by the UE 100 or the gNB 200 (network node) may be implemented in circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), CPUs (Central Processing Units), conventional circuits, and / or combinations thereof, programmed to perform the described functions. A processor includes transistors and other circuits and is considered to be circuitry or processing circuitry. A processor may also be a programmed processor that executes a program stored in memory. In this specification, circuitry, unit, or means refers to hardware that is programmed to perform the described functions or hardware that executes them. The hardware may be any hardware disclosed herein or any hardware known to be programmed or capable of performing the described functions. If the hardware is a processor, the circuitry, means, or unit is a combination of hardware and software used to configure the hardware and / or processor.

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

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

[0140] This application claims priority to U.S. Provisional Application No. 63 / 444,309 (filed February 9, 2023), the entire contents of which are incorporated herein by reference.

[0141] (Supplementary Note 1) (Supplementary Note 1) A communication control method used in a cellular communication system, comprising: when a parent node broadcasts mobile relay node support information indicating that it supports a mobile relay node, the parent node permits access of the mobile relay node and broadcasts legacy relay node support information indicating that it supports a legacy relay node that is not mobile.

[0142] (Supplementary Note 2) The communication control method according to Supplementary Note 1, wherein the step of reporting includes a step of not reporting the mobile relay node support information if the parent node does not report the legacy relay node support information.

[0143] (Supplementary Note 3) A communication control method used in a cellular communication system, comprising: a step of determining whether a mobile relay node can access a parent node that notified the mobile relay node support information and / or the legacy relay node support information, based on whether the mobile relay node has received mobile relay node support information indicating that the mobile relay node is supported and legacy relay node support information indicating that the mobile relay node is permitted to access and that non-mobile legacy relay nodes are supported.

[0144] (Supplementary Note 4) A communication control method as described in any one of Supplementary Notes 1 to 3, further comprising a step in which the parent node broadcasts the mobile relay node support information without broadcasting the legacy relay node support information, and the determining step includes a step in which, if the mobile relay node does not receive the legacy relay node support information, the mobile relay node determines that access to the parent node is not possible, regardless of whether the mobile relay node support information has been received.

[0145] (Supplementary Note 5) A communication control method as described in any one of Supplementary Notes 1 to 4, further comprising a step in which the parent node broadcasts the mobile relay node support information without broadcasting the legacy relay node support information, and the determining step includes a step in which, when the mobile relay node receives the mobile relay node support information, the mobile relay node determines that access to the parent node is possible regardless of whether the legacy relay node support information has been received.

[0146] (Supplementary Note 6) A communication control method according to any one of Supplementary Notes 1 to 5, further comprising: a step in which a network device transmits to the mobile relay node connection permission information indicating whether or not connection to a network that supports the legacy relay node but does not support the mobile relay node is permitted; and a step in which the parent node broadcasts the legacy relay node support information without broadcasting the mobile relay node support information, wherein the determining step includes a step in which, when the mobile relay node receives the legacy relay node support information from the parent node without receiving the mobile relay node support information, the mobile relay node determines whether access to the parent node is possible according to the connection permission information.

[0147] (Supplementary Note 7) The communication control method according to any one of Supplementary Notes 1 to 6, wherein the determining step includes a step in which the mobile relay node determines that access to the parent node is possible if the connection permission information indicates that connection to the network is permitted, and determines that access to the parent node is not possible if the connection permission information indicates that connection to the network is not permitted.

[0148] (Supplementary Note 8) A communication control method according to any one of Supplementary Notes 1 to 7, further comprising a step in which the parent node notifies the legacy relay node support information without notifying the mobile relay node support information, and the determining step includes a step in which the mobile relay node determines whether or not access to the parent node is possible depending on the mobility state of the mobile relay node.

[0149] (Supplementary Note 9) The communication control method according to any one of Supplementary Notes 1 to 8, wherein the determining step includes a step in which the mobile relay node determines that access to the parent node is possible if the moving speed of the mobile relay node is equal to or less than a speed threshold, and determines that access to the parent node is not possible if the moving speed of the mobile relay node is faster than the speed threshold.

[0150] (Supplementary Note 10) A communication control method according to any one of Supplementary Notes 1 to 9, further comprising a step in which an operation management device sets movement range information indicating a movement range to the mobile relay node, and the determining step includes a step in which the mobile relay node determines that access to the parent node is possible if the movement range of the mobile relay node is equal to or less than a range threshold, and determines that access to the parent node is not possible if the movement range of the mobile relay node is wider than the range threshold.

[0151] (Second Supplement) 1. Introduction The WID for mobile IAB was revised in RAN#97e, and the following purpose was stated: The detailed purpose of WI is as follows:

[0152] Defines migration / topology adaptation procedures to enable IAB node mobility, including inter-donor migration (full migration) of entire mobile IAB nodes [RAN3, RAN2]. Mobile IAB nodes can be attached to stationary (intermediate) IAB nodes. Optimizations specific to scenarios 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 down-prioritized. Enhances mobility of IAB nodes and their UEs, including aspects related to group mobility. There are no optimizations for targeting surrounding UEs [RAN3, RAN2].

[0153] Note: Solutions should avoid touching on topics already discussed in Rel-17 or topics excluded from Rel-17, with the exception of enhancements specific to IAB node mobility.

[0154] Mitigation of interference due to IAB node mobility, including avoidance of potential reference and control signal collisions (PCI, RACH, etc.) [RAN3, RAN2].

[0155] The following principles should be respected: Mobile IAB nodes should be able to serve legacy UEs. Solutions that provide optimization for mobile IAB may involve enhancements to Rel-18 UEs.

[0156] This appendix discusses the details of the mobility enhancements for the mobile IAB.

[0157] 2. Discussion 2.1 UE Mobility Enhancements 2.1.1 UE Cell Reselection Enhancements RAN2#119bis-e agreed to the following confirmations, observations, and assumptions: RAN2 confirms that mobile IAB needs to work with legacy UEs. RAN2 confirms that if a UE camps on / connects to a mobile IAB cell for an extended period of time, the UE may consider itself onboard the mobile IAB cell (i.e., the UE needs to know that this cell is such a cell). The time period requires further consideration.

[0158] RAN2 makes the following assumptions about UEs operating in mobile IAB cells. Assumption 1: From the viewpoint of the network of a mobile IAB cell, the configuration principles of legacy parameters (including cell (re)selection, cell reservation, and access restriction) are the same as for legacy IAB cells. Assumption 2: There is no impact on the operation of legacy UEs in terms of specifications. Assumption 3: Information about a mobile IAB cell newly broadcast by R18 (if agreed) does not prohibit / control access for legacy UEs. Assumption 4: UEs that do not support enhancement (including legacy UEs and non-enhancement R18 UEs) ignore information about a mobile IAB cell newly broadcast by R18 (if agreed).

[0159] RAN2 Assumptions: Mobile IAB Cell Broadcast Information To support idle / inactive mode mobility for Rel-18 UEs, a one-bit mobile IAB cell type indication is introduced (the cases where a UE needs to know it is onboard require further study). How this is used may vary depending on the implementation. RAN2 has not specified any modifications to prevent surrounding UEs from accessing mobile IAB nodes from a mobile IAB WI perspective, but it is believed that SA2 may be working on an applicable Rel-18 solution (pending SA2).

[0160] RAN2#120 further agreed to the following assumptions: Regarding the assumed mobile IAB cell type indication, RAN2 assumes that it may be specified if any associated UE behavior is specified.

[0161] Based on the agreement, UE cell reselection is analyzed in terms of mobility scenarios, expected UE behavior, and deployment scenarios.

[0162] 2.1.1.1 Mobility Scenarios and Expected UE Behavior Two main scenarios and several sub-cases with expected UE behavior can be considered as follows: Scenario A: The mobile IAB node is moving with a camping UE. Sub-case A1: The UE (e.g., on a train) needs to stay on the mobile IAB node. Sub-case A2: Surrounding UEs (e.g., off the train) should not camp on the mobile IAB node. Scenario B: The mobile IAB node is stationary with a camping 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., when getting off the train) needs to reselect a stationary cell (e.g., a macrocell). Sub-case B3: Surrounding UEs (e.g., when getting on the train) need to reselect a mobile IAB node. Subcase B4: Surrounding UEs (e.g., still at the station) should stay in the fixed cell. In subcases A1, B1, and B2, UEs are located near the mobile IAB node. In particular, subcase A1 is the main case that WID clearly identifies as follows:

[0163] Enhancements to the mobility of IAB nodes and their UEs, including aspects related to group mobility. There are no optimizations for targeting surrounding UEs [RAN3, RAN2]. Note: Solutions should avoid touching on topics already discussed in Rel-17 or topics excluded from Rel-17, with the exception of enhancements specific to IAB node mobility.

[0164] In subcases A2, B3, and B4, these behaviors are the behaviors desired for surrounding UEs. WID clearly states that optimization targeting surrounding UEs is not performed. For subcase B3, the UE becomes subcase B1 or B2 after getting on a train, but the initial state of the UE remains that of a surrounding UE. Therefore, these subcases are not covered by Rel-18.

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

[0166] Therefore, only subcases A1, B1 and B2 will be considered below.

[0167] Observation 1: Although optimization targeting surrounding UEs is outside the scope of WI, configurations similar to Observations 2 and 4 are applicable.

[0168] 2.1.1.2. Inter-Frequency Deployment In this deployment scenario, it is assumed that the mobile IAB nodes are deployed on frequencies other than those for the macrocell (i.e., outer cells).

[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 advertises its frequency preference as "7" or advertises its cell as an HSDN cell (i.e., the UE considers that frequency as the highest priority).

[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] Observation 2: It may be common for a moving IAB cell to broadcast a serving frequency priority of "7" or an HSDN cell indication to prevent cell reselection by a UE moving with the IAB cell.

[0172] 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 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 priority. That is, the mobile IAB node may, for example, broadcast a serving frequency priority in the same way as the fixed macrocell layer, or stop broadcasting the HSDN cell indication.

[0173] Observation 3: When the UE and the mobile IAB node go down, the UE cannot determine whether to reselect to the mobile IAB node unless it knows the user's intention, so which cell the UE reselects to depends on the radio conditions.

[0174] Observation 4: It may be typical for a stationary mobile IAB cell to return the frequency priority or HSDN cell indication that was in use at the time of movement (i.e., similar to observation 2).

[0175] However, considering the above findings, a drawback of the current mechanism is that the SIB of a mobile IAB node needs to be changed depending on its mobility state (observation 2 for moving and observation 4 for stationary), but this may not be a critical issue to solve.

[0176] Observation 5: A drawback of the current mechanism is that the mobile IAB cell needs to change its SIB depending on the mobility situation.

[0177] To summarize, in case of inter-frequency deployment, the existing cell reselection mechanism, i.e., based on radio conditions and frequency priorities, still works well, so no enhancements are needed for the UE to perform cell reselection.

[0178] HSDN is useful for subcase A1.

[0179] Proposal 1: When mobile IAB nodes and macro cells are deployed on different frequencies, RAN2 should agree that no enhancements are required for UE cell reselection, i.e., RAN2's assumption of "1-bit mobile IAB cell type indication" is unnecessary.

[0180] 2.1.1.3. Intra-Frequency Deployment In this deployment scenario, it is assumed that the mobile IAB node is deployed on the same frequency as the macrocell (i.e., it is an outer cell).

[0181] For intra-frequency (and inter-frequency with equal priority) cell reselection, the UE must follow a ranking mechanism (i.e., R-criterion), and the value range of q-OffsetCell in SIB3 is -24 dB to +24 dB (Table 1).

[0182] In subcase A1, a moving IAB cell may report a large positive Qoffset to the macrocell and zero Qoffset to other IAB cells. In this configuration, a UE moving with an IAB cell will prefer the moving IAB cell over the macrocell.

[0183] Observation 6: It may be a common configuration for a moving IAB cell to report the macrocell's Qoffset as a large positive value.

[0184] For subcases B1 and B2, as explained in Remark 3 above, depending on radio conditions, the mobile IAB cell should return the Qoffset value used during the move.

[0185] Observation 7: It may be a common configuration for a moving IAB cell to revert to the Qoffset value it was using while moving (i.e., similar to observation 6).

[0186] One of the drawbacks is that, similar to observation 5 above, SIBs are frequently changed due to the mobility of IAB nodes.

[0187] Observation 8: A drawback of the current mechanism is that a mobile IAB cell needs to change its SIB depending on its mobility state.

[0188] To summarize, for intra-frequency deployments, the existing cell reselection mechanism, i.e. cell reselection based on radio condition prioritization, still works well, so no enhancements are needed for the UE to perform cell reselection.

[0189] Proposal 2: When the mobile IAB node and the macro cell are installed on the same frequency, RAN2 should agree that no functional enhancement is required for UE cell reselection, i.e., the "1-bit mobile IAB cell type indication" is not required, as assumed by RAN2.

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

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

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

[0193] Proposal 3: 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.

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

[0195] Proposal 4: RAN2 should agree in RACH-less handover of UE that UL grant information is configured by the target IAB donor CU.

[0196] Considering the RRCIE 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.

[0197] Proposal 5: RAN2 should agree that RACH-less handover is configured with a handover command, i.e., reconfiguration with synchronization.

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

[0199] Proposal 6: RAN2 should discuss whether RACH-less handover can also be configured as a conditional handover, i.e., conditional reconfiguration.

[0200] 2.2 IAB-MT Mobility Enhancements 2.2.1 Access Restrictions 2.2.1.1 Stationary IAB Node Access In WID, a mobile IAB node is required to serve only UEs. This means that a mobile IAB node should not serve other IAB nodes as child nodes. A mobile IAB node has no descendant IAB nodes and serves only UEs.

[0201] 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 (without further spec impact).

[0202] However, it does not appear that this agreement was reached after sufficient discussion. In particular, the question remains as to whether it is sufficient to leave the "(without further impact on the specification)" part to implementation discretion. Since WID clearly requires that mobile IAB nodes 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 incorporate the above agreement or clarify that "mobile IAB nodes cannot access other mobile IAB nodes in this release."

[0203] Proposal 7: RAN2 should agree to incorporate into the Stage 2 specification that in this release, when an IAB node acts as a mobile IAB node, the IAB support IE (information element) is not set in the SIB.

[0204] 2.2.1.2 Mobile IAB Node Access RAN2#120 has reached the following agreement for mobile IAB nodes to access their parent node: A mobile IAB node can camp on and connect to a legacy Rel-16 / Rel-17 IAB-capable cell. R2 assumes that a "supporting mobile-IAB" indication is provided by a Rel-18 mobile IAB-capable parent cell.

[0205] Based on the agreement, the correspondence between the indication availability and the behavior of the IAB node is summarized in Table 2. SIB indication and IAB node behavior

[0206] For cases 1 and 4, the behavior of the mobile IAB node is clear, as shown in Table 2.

[0207] Proposal 8: RAN2 should agree that mobile IABs are prohibited from accessing parents that do not advertise both the legacy IAB support IE and the new "supporting mobile-IAB" IE.

[0208] Proposal 9: RAN2 should agree that the mobile IAB evaluates parents that advertise both the legacy IAB support IE and the new "supporting mobile-IAB" IE.

[0209] Regarding Case 2, if a new indication is provided without a legacy IAB support IE, it is unclear whether the mobile IAB node can access the parent node. Furthermore, it should be discussed whether it is a valid case for the parent node to broadcast only the new indication without the legacy IE. It is considered a typical case that the parent node accepts access from both legacy and mobile IAB nodes. However, it is also possible that the parent node is set up only for the mobile IAB node. Therefore, it may be good to maintain flexibility in the configuration.

[0210] Proposal 10: RAN2 should discuss whether it is a valid configuration for the legacy IAB support IE to not be provided while the new "supporting mobile-IAB" IE is broadcast (i.e., the case in Table 2).

[0211] In case 3, i.e., when the legacy IAB support IE is provided but the new indication is not, the mobile IAB node can access the parent because RAN2 has agreed that "a mobile IAB node can camp on and connect to a legacy Rel-16 / Rel-17 IAB-capable cell." However, the expected behavior of the IAB node is the same as in case 4. In case 3, the mobile IAB node can access the parent under certain conditions, while in case 4, access is considered to be always possible. For example, the mobile IAB node can access only if no cell broadcasting the new indication is found. As another example, whether a mobile IAB node is allowed to access a cell that does not broadcast the new indication can be configured by, for example, the AMF or OAM in an authorization / verification process. Therefore, RAN2 needs to clarify under what conditions a mobile IAB node can access a parent cell that does not broadcast the new indication.

[0212] Proposal 11: RAN2 should discuss under what conditions a mobile IAB node is allowed to access a parent node that broadcasts the legacy IAB support IE (case 3 in Table 2) but does not provide the new "supporting mobile-IAB" IE. For example, access to the parent node is allowed only if no cell broadcasting the new indication is found.

Claims

1. A communication control method for use in a cellular communication system, comprising: When a non-mobile legacy relay node receives legacy relay node support information from a cell indicating that the legacy relay node is supported without receiving mobile relay node support information from the cell indicating that the legacy relay node is supported, the non-mobile legacy relay node is allowed to access the cell, and when the non-mobile legacy relay node does not receive the mobile relay node support information from the cell and does not receive the legacy relay node support information from the cell, access to the cell is restricted; When the mobile relay node receives the mobile relay node support information from a cell without receiving the legacy relay node support information from the cell, the mobile relay node is able to access the cell, and when the mobile relay node does not receive the mobile relay node support information from the cell without receiving the legacy relay node support information from the cell, access to the cell is restricted. Communication control method.

2. The mobile relay node support information is applied to the mobile relay node. The communication control method according to claim 1.

3. A non-mobile relay node in a cellular communication system, comprising: The cell can be accessed when legacy relay node support information indicating that a non-movable relay node is supported is received from the cell without receiving mobile relay node support information indicating that the mobile relay node is supported from the cell, and access to the cell is restricted when the mobile relay node support information is not received from the cell without receiving the legacy relay node support information from the cell. Relay node.

4. A mobile relay node in a cellular communication system, comprising: When mobile relay node support information indicating support for a mobile relay node is received from a cell without receiving legacy relay node support information indicating support for a non-mobile relay node from the cell, access to the cell is permitted, and when the mobile relay node support information is not received from the cell without receiving the legacy relay node support information from the cell, access to the cell is restricted. Relay node.

5. A cellular communication system having a non-mobile relay node according to claim 3 and a mobile relay node according to claim 4.

6. A program in a cellular communication system, comprising: a process in which, when a legacy relay node that is not mobile receives legacy relay node support information from a cell indicating that the legacy relay node supports a mobile mobile relay node without receiving mobile relay node support information from the cell, the cell is accessible, and when the legacy relay node support information is not received from the cell without receiving the mobile relay node support information from the cell, the access to the cell is restricted; and causing the mobile relay node to execute a process of allowing access to the cell when the mobile relay node receives the mobile relay node support information from the cell without receiving the legacy relay node support information from the cell, and restricting access to the cell when the mobile relay node does not receive the mobile relay node support information from the cell without receiving the legacy relay node support information from the cell. program.

7. A chipset in a cellular communication system, comprising: When a non-mobile legacy relay node receives legacy relay node support information from a cell indicating that the legacy relay node is supported without receiving mobile relay node support information from the cell indicating that the legacy relay node is supported, the non-mobile legacy relay node is allowed to access the cell, and when the non-mobile legacy relay node does not receive the mobile relay node support information from the cell and does not receive the legacy relay node support information from the cell, access to the cell is restricted; When the mobile relay node receives the mobile relay node support information from a cell without receiving the legacy relay node support information from the cell, the mobile relay node is able to access the cell, and when the mobile relay node does not receive the mobile relay node support information from the cell without receiving the legacy relay node support information from the cell, access to the cell is restricted. Chipset.