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

[Technical Field]

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

[0002] In the 3GPP (Third Generation Partnership Project), a standardization project for cellular communication systems, the introduction of a new relay node called an IAB (Integrated Access and Backhaul) node is being considered (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. [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] 3GPP TS 38.300 V17.3.0(2022-12) Summary of the Invention

[0004] A communication control method according to a first aspect is a communication control method for use in a cellular communication system, comprising: when a parent node broadcasts mobile relay node support information indicating that it supports a mobile relay node, broadcasting legacy relay node support information indicating that it permits access of the mobile relay node and supports a legacy relay node that is not mobile.

[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 mobile relay node can access a parent node that has broadcast 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 supports mobile relay nodes and legacy relay node support information indicating that the mobile relay node is permitted to access and that the mobile relay node supports non-mobile legacy relay nodes. [Brief explanation of the drawings]

[0006] [Figure 1] FIG. 1 is a diagram showing an example of the configuration of a cellular communication system according to an embodiment. [Figure 2] FIG. 2 is a diagram showing the relationship between IAB nodes, parent nodes, and child nodes. [Figure 3] FIG. 3 is a diagram illustrating an example configuration of a gNB (base station) according to an embodiment. [Figure 4] FIG. 4 is a diagram illustrating an example of the configuration of an IAB node (relay node) according to an embodiment. [Figure 5] FIG. 5 is a diagram illustrating an example of the configuration of a UE (user equipment) according to an embodiment. [Figure 6] FIG. 6 is a diagram illustrating an example of a protocol stack related to an RRC connection and a NAS connection of an IAB-MT. [Figure 7] FIG. 7 is a diagram illustrating an example of a protocol stack for the F1-U protocol. [Figure 8] FIG. 8 is a diagram illustrating an example of a protocol stack for the F1-C protocol. [Figure 9] FIG. 9 is a diagram showing whether or not access to an IAB node is restricted according to the first embodiment. [Figure 10] FIG. 10 is a flowchart illustrating a first operation example according to the first embodiment. [Figure 11]FIG. 11 is a flowchart illustrating a second operation example according to the first embodiment. [Figure 12] FIG. 12 is a flowchart illustrating a third operation example according to the first embodiment. [Figure 13] FIG. 13 is a flowchart illustrating a first operation example according to the second embodiment. [Figure 14] FIG. 14 is a flowchart illustrating a second operation example according to the second embodiment. [Figure 15] FIG. 15 is a diagram illustrating scenarios and sub-cases of UE cell reselection. [Figure 16] FIG. 16 is a diagram illustrating RACH-less handover in LTE. DETAILED DESCRIPTION OF THE INVENTION

[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 a cellular communication system) An example of the configuration of a cellular communication system according to an embodiment will be described. The cellular communication system 1 according to an embodiment is a 3GPP 5G system. Specifically, the radio access method in the cellular communication system 1 is NR (New Radio), which is a 5G radio access method. However, LTE (Long Term Evolution) may be applied at least partially to the cellular communication system 1. Furthermore, 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, an example in which base station 200 is an NR base station will be mainly described, but base station 200 may also be an LTE base station (i.e., an eNB).

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

[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. In the following, 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. Figure 1 illustrates two gNBs, gNB 200-1 and gNB 200-2, connected to the 5GC 10.

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

[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 functionality to support IAB. The backhaul can be multi-hop via multiple hops (i.e., multiple IAB nodes 300).

[0019] FIG. 1 illustrates 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 may be a mobile phone terminal and / or a tablet terminal, a laptop computer, a sensor or a device provided in a sensor, a vehicle or a device provided in a vehicle, or an aircraft or a device provided in an aircraft. The UE 100 is wirelessly connected to the IAB node 300 or the gNB 200 via an access link. FIG. 1 shows an example in which the UE 100 is wirelessly connected to the IAB node 300-2. The UE 100 indirectly communicates with the donor 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 an 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 DU of the parent IAB node or 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 a cell, similar to the gNB 200. The IAB-DU terminates the NR Uu radio interface to the UE 100 and lower IAB nodes. The IAB-DU supports the F1 protocol to the CU of the donor node 200-1. While FIG. 2 shows an example in which the child nodes of the IAB node 300 are IAB nodes 300-C1 to 300-C3, 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 centrally manages, for example, resources, 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] (Base station configuration) Next, a configuration of the gNB 200, which is a base station according to the embodiment, will be described. Fig. 3 is a diagram showing an example configuration of the gNB 200. As shown in Fig. 3, the gNB 200 has a radio communication unit 210, a network communication unit 220, and a control unit 230.

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

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

[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 described below.

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

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

[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 description will be given of a configuration of a UE 100 which is a user equipment according to the embodiment. Fig. 5 is a diagram showing an example of the configuration of the UE 100. As shown in Fig. 5, the UE 100 includes a radio communication unit 110 and a control unit 120.

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

[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 the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processing. The processor performs processing of each layer, which will be described later. Note that the control unit 120 may perform each processing in the UE 100 in each of the embodiments described below.

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

[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 between the MAC layer of the IAB-MT in IAB node 300-2 and the MAC layer of the IAB-DU in IAB node 300-1 via a transport channel. The MAC layer of the IAB-DU includes a scheduler, which determines the 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 is a diagram showing a protocol stack for the F1-U protocol. Figure 8 is a diagram showing 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 via a backhaul RLC channel (BH NR RLC channel). Configuring multiple backhaul RLC channels in each BH link enables traffic prioritization and Quality of Service (QoS) control. The association between BAP PDUs and backhaul RLC channels is performed by the BAP layer of each IAB node 300 and the BAP layer of the donor 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 referred to as the processing or operations of the "IAB." For example, the transmission of a BAP layer message from the IAB-DU of IAB 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 be simply referred to 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 along 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 may be 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 be a fixed IAB node.

[0054] A mobile IAB node can also connect to an intermediate IAB node. Also, a mobile IAB node can connect 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, a 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 the 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 the cell that broadcasts this "iab-Support" supports IAB and is considered as a candidate cell for cell (re)selection by the 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 the IAB node.

[0059] That is, a cell that broadcasts "iab-Support" indicates that it is capable of supporting the IAB node, and a cell that does not broadcast "iab-Support" indicates that it is not capable of supporting 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 considered a restricted cell.

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

[0061] (X1) A mobile IAB node may camp on a Rel-16 / Rel-17 IAB-enabled 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] A parent node cell can announce that it can support fixed, non-mobile IAB nodes (Rel-16 / Rel-17 IAB) by announcing "iab-Support." 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 announces "iab-Support." It can be said that "iab-Support" indicates that it can 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 mobile IAB nodes can be supported. In other words, if the parent node cell broadcasts "supporting mobile-IAB," the mobile IAB node can access the cell.

[0065] In this way, the parent node can announce "iab-Support" or "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 broadcasting methods, as shown in Figure 9. Note that, hereinafter, "iab-Support" may be referred to as "legacy IAB node support information." Also, "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. A 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 Figure 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] Also, as shown in "Case 4," if a parent node broadcasts both legacy IAB node support information and mobile IAB node support information, it indicates that the parent node can support both legacy IAB nodes and mobile IAB nodes, and therefore both legacy IAB nodes and mobile IAB nodes can 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. It can be assumed that the mobile IAB node cannot access the parent node because the parent node does not broadcast legacy IAB node support information. It can also be assumed that the mobile IAB node 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 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 the 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) that are mobile, 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 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 process 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, such as 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 the mobile IAB node support information, it also broadcasts the 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 the legacy IAB node support information (or the legacy relay node support information), it does not broadcast the mobile IAB node support information (or the mobile relay node support information). Therefore, the state of "Case 2" is prohibited. The parent node 200P broadcasts both the mobile IAB node support information and the 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) of the mobile IAB node support information, set the information element (IE) of the legacy IAB node support information." Specifically, when setting mobile IAB node support information, the IE configuration may be such that setting legacy IAB node support information is conditionally mandatory.

[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 the 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 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 notified 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 (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 (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 the 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 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 state of "Case 2," 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 based on the reception of the mobile IAB node support information. Under current specifications, the mobile IAB node 300M cannot access (or is considered barred from) cells that do not broadcast legacy IAB node support information. However, the mobile IAB node 300M cancels this specification and determines that it is able to access the parent node 200P. Note that the legacy IAB node determines that it is not allowed to access the parent node 200P (or considers it to be barred).

[0101] The third operation example according to the first embodiment is an operation example corresponding 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 connection to the network is permitted.

[0105] Specifically, first, a network device (e.g., AMF 11) transmits connection permission 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 permitted based on the connection permission 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 showing 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 it may also 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 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 connection to the network is permitted. The mobile IAB node 300M (IAM-MT) may perform an initial connection and receive the connection permission information from the AMF 11 in the registration procedure. At this time, the AMF 11 may perform an authentication process 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 on a cell to which connection is permitted. The information on the cell may be a cell identifier or a gNB identifier. The information may also be information on a cell to which connection is not permitted. The mobile IAB node 300M can determine whether connection is permitted for each cell on which it is currently camped based on the information.

[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 (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 (IAB-MT) 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 permission 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 connection to the network is permitted by the connection permission information, 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 if connection to the network is permitted ("Case 4"). That is, the mobile IAB node 300M determines that it is possible to access at least a parent node that broadcasts 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 accessible to 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 accessible to 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 accessible to 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 the second embodiment) Next, a second operation example according to the second embodiment will be described.

[0114] The second embodiment 2 The operation example 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). Secondly, 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 showing a second operation example according to the second embodiment. In the second operation example according to the second embodiment, the moving state will be explained using the speed state of the mobile IAB node 300M (for example, a slow moving state (or stationary), or a fast moving state, etc.) as an example.

[0118] 14, in step S50, the parent node 200P broadcasts the legacy IAB node support information without broadcasting the mobile IAB node support information. This results in the state of "Case 3." 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.

[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 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 slowly, 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 received signals, and determining that the moving speed is equal to or less than a speed threshold. The speed threshold may be preset (or broadcast) 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"). That is, 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 moving at high speed, it determines that it cannot access the 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 moving at high speed, it determines that it cannot access the parent node 200P that broadcasts legacy IAB node support information. 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 legacy IAB nodes, 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 received signals, 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 the second embodiment) In the second operation example according to the second embodiment, the speed state of the mobile IAB node 300M has been used 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 be used as the movement state. The movement range information is information indicating the movement range of the mobile IAB node 300M. The movement range information is 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), for example.

[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 in 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 larger 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 "slow-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: 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 by the gNB 200 for the mobile IAB node 300M. Therefore, the mobile IAB node 300M can determine that it is "narrow range movement" when the movement range information is equal to or less than the range threshold. 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, if the mobile IAB node 300M is moving in a narrow range, it can be determined that the parent node 200P can also support the mobile IAB node 300M. On the other hand, the mobile IAB node 300M can determine that it is "wide range movement" when the movement range information is a range wider than the range threshold. In this case, the mobile IAB node 300M determines that the parent node 200P that broadcasts legacy IAB node support information without broadcasting mobile IAB node support information is inaccessible to the mobile IAB node 300M. This is because, in the case of a mobile IAB node 300M that moves over a wide area, 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 has been 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 mobile IAB node support information and legacy IAB node support information have been received.

[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 embodiment and example, 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] Furthermore, the term "network node" primarily refers to a base station, but may also refer to a core network device or part of a base station (CU, DU, or RU). A network node may also be configured by a combination of at least part of a core network device and at least part of a base station.

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

[0136] In addition, circuits that execute 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 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), a CPU (Central Processing Unit), 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, a circuit, unit, or means is hardware that is programmed to perform or executes the described functions. The hardware may be any hardware disclosed in this specification or any hardware known to be programmed to perform or execute the described functions. If the hardware is a processor, which is considered to be a type of circuitry, the circuit, 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] (Appendix 1) (Appendix 1) A communication control method for use in a cellular communication system, comprising: When a parent node broadcasts mobile relay node support information indicating that it supports a mobile relay node that is movable, the parent node broadcasts legacy relay node support information indicating that it permits access to the mobile relay node and supports a legacy relay node that is not movable. Communication control method.

[0142] (Appendix 2) 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. 10. The communication control method according to claim 1.

[0143] (Appendix 3) A communication control method for use in a cellular communication system, comprising: and a step of determining whether or not a mobile relay node can access a parent node that has broadcast the mobile relay node support information and / or the legacy relay node support information, based on whether or not 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 access of the mobile relay node is permitted and that non-mobile legacy relay nodes are supported. Communication control method.

[0144] (Appendix 4) The method further comprises the step of the parent node broadcasting the mobile relay node support information without broadcasting the legacy relay node support information; the determining step includes a step of determining, when the mobile relay node has not received the legacy relay node support information, that the parent node is not accessible, regardless of whether the mobile relay node has received the mobile relay node support information. A communication control method according to any one of Supplementary Note 1 to Supplementary Note 3.

[0145] (Appendix 5) The method further comprises the step of the parent node broadcasting the mobile relay node support information without broadcasting the legacy relay node support information; the determining step includes a step of determining, when the mobile relay node has received the mobile relay node support information, that access to the parent node is possible regardless of whether the legacy relay node support information has been received. A communication control method according to any one of Supplementary Note 1 to Supplementary Note 4.

[0146] (Appendix 6) a network device transmitting connection authorization information to the mobile relay node indicating whether or not connection to a network that supports the legacy relay node and does not support the mobile relay node is permitted; the parent node broadcasting the legacy relay node support information without broadcasting the mobile relay node support information, The determining step includes a step of determining whether or not access to the parent node is possible according to the connection permission information when the mobile relay node receives the legacy relay node support information from the parent node without receiving the mobile relay node support information. A communication control method according to any one of Supplementary Note 1 to Supplementary Note 5.

[0147] (Appendix 7) the determining step includes a step of the mobile relay node determining that access to the parent node is permitted when the connection permission information indicates that connection to the network is permitted, and determining that access to the parent node is not permitted when the connection permission information indicates that connection to the network is not permitted. A communication control method according to any one of Supplementary Note 1 to Supplementary Note 6.

[0148] (Appendix 8) The method further comprises the step of the parent node broadcasting the legacy relay node support information without broadcasting the mobile relay node support information; the determining step includes a step of determining, by the mobile relay node, whether or not access to the parent node is permitted, depending on a movement state of the mobile relay node; A communication control method according to any one of Supplementary Note 1 to Supplementary Note 7.

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

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

[0151] (Second Appendix) 1. Introduction The WID for mobile IAB was revised in RAN#97e to state the following objectives: The detailed objectives of WI are as follows:

[0152] Define migration / topology adaptation procedures to enable mobility of IAB nodes, including inter-donor migration (full migration) of entire mobile IAB nodes [RAN3, RAN2]. Mobile IAB nodes can connect to stationary (intermediate) IAB nodes. Optimizations specific to the scenario where a mobile IAB node connects to a stationary (intermediate) IAB node or directly to an IAB donor DU are not prioritized. Mobility of dual-connected IAB nodes is down-prioritized. Enhanced mobility of IAB nodes and their UEs, including aspects related to group mobility. No optimization 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 IAB Node Mobility-specific enhancements.

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

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

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

[0157] 2. Discussion 2.1 UE Mobility Enhancement 2.1.1 Enhanced UE cell reselection function RAN2#119bis-e agreed to the following observations, findings, 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 a long period of time, it may consider the UE to be onboard the mobile IAB cell (i.e., the UE needs to know that this cell is such a cell). The time period requires further study.

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

[0159] RAN2 premise: Mobile IAB cell broadcast information To support mobility in idle / inactive mode for Rel-18 UE, a 1-bit mobile IAB cell type indication is introduced (further study is needed on when the UE needs to know it is onboard). How this is used may vary between implementations. RAN2 has not specified a fix 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 related 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 some sub-cases with expected UE behavior can be considered as follows: Scenario A: A mobile IAB node is moving together with a camping UE. Subcase A1: The UE (e.g., in a train) needs to stay at a mobile IAB node. Subcase A2: Surrounding UEs (e.g., outside a train) should not camp on mobile IAB nodes. Scenario B: A mobile IAB node is parked with a camping UE. Subcase B1: The UE (e.g., still on the train) should stay at the mobile IAB node. Subcase B2: The UE (eg, when getting off a train) needs to reselect a stationary cell (eg, a macrocell). Subcase B3: Surrounding UEs (e.g., when getting on a 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 sub-cases A1, B1, and B2, the UE is located near the mobile IAB node. In particular, sub-case A1 is the main case that WID clearly identifies as follows:

[0163] Enhanced mobility of IAB nodes and their UEs, including aspects related to group mobility. No optimization 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 IAB Node Mobility-specific enhancements.

[0164] In subcases A2, B3, and B4, these behaviors are the desired behaviors for surrounding UEs. WID clearly states that optimizations targeting surrounding UEs are not performed. For subcase B3, the UE enters subcase B1 or B2 after boarding the train, but the initial state of the UE remains the same as that of surrounding UEs. 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 (ie, 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 good enough, 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 its frequency as the highest priority).

[0170] We can also consider a train with multiple cars, each with a mobile IAB node. Even if the UE moves between cars, one of the mobile IAB node's cells will always be more stable than the external macro cell from the perspective of the UE inside the train. Furthermore, we assume that the mobile IAB node cells operate on the same frequency, which is a typical case. In this case, the existing intra-frequency cell reselection, i.e., the R criterion, works well.

[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 UEs moving with the moving 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 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. Therefore, the cell to which the UE reselects 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 (ie, 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, observation 4 for stopped). However, 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 mobile situation.

[0177] To summarize, in the 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., the assumption of "1-bit mobile IAB cell type indication" in RAN2 is unnecessary.

[0180] 2.1.1.3. Intra-Frequency Expansion In this deployment scenario, we assume that the mobile IAB nodes are deployed on the same frequency as the macrocell (i.e., the outer cell).

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

[0182] In subcase A1, a moving IAB cell may report a large positive Qoffset for the macrocell and a zero Qoffset for other moving 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 common for moving IAB cells 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 moving 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 drawback, similar to observation 5 above, is that the SIB changes frequently due to the mobility of IAB nodes.

[0187] Observation 8: A drawback of the current mechanism is that the 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 UE RAN2#119e reached the following agreement: R2 assumes that for onboard RRC connected UEs handed over with mobile IAB nodes, RACH-less procedures may be considered (also relying on the assumption of UL synchronization).

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

[0192] Regarding the TA value for UE RACH-less handover during 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 set an explicit TA value. On the other hand, if RACH-less handover is used for other scenarios, such as mobile IAB-MT handover, a generic approach like the LTE configuration is required.

[0193] Proposal 3: RAN2 should discuss whether the UE should implicitly apply the latest TA value or explicitly set the corresponding TA value for RACH-less handover of the UE.

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

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

[0196] Considering the RRCIE structure in NR, it can be assumed that the RACH-less configuration is included in the reconfigurationWithSync within the CellGroupConfig, since the RACH-less handover is indicated by the target IAB donor CU during the handover procedure.

[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 only supposed to serve the UE, which 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 requirements, RAN2#119e agreed to the following: Not advertising 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 part "(without further impact on the specification)" leaves open the question of whether it is sufficient to leave it to the implementation. Since WID clearly requires that mobile IAB nodes cannot access other mobile IAB nodes, it is considered necessary to clarify this premise in the specification to avoid confusion in mobile IAB implementations. Therefore, it is desirable for the Stage 2 specification to either incorporate the above agreement or clarify that "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 nodes: Mobile IAB nodes can camp on and connect to legacy Rel-16 / Rel-17 IAB capable cells. R2 assumes that the "supporting mobile-IAB" indication is provided by a Rel-18 mobile-IAB capable parent cell.

[0205] Based on the agreement, we will summarize the correspondence between indication availability and IAB node behavior. (Table 2) SIB instructions and IAB node behavior TIFF0007814565000002.tif63169

[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 to allow mobile IAB to evaluate 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 the 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 not to 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 instructions are not, the mobile IAB node can access its parent because RAN2 has agreed that the 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 its parent under certain conditions, while in case 4, it is considered that the mobile IAB node can always access its parent. For example, the mobile IAB node can access its parent only if no cell broadcasting the new instructions is found. As another example, whether the mobile IAB node is allowed to access a cell that does not broadcast the new instructions can be configured by, for example, the AMF or OAM through an authorization / verification process. Therefore, RAN2 needs to clarify under what conditions the mobile IAB node can access a parent cell that does not broadcast the new instructions.

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

Images