Communication control method, IAB node, cellular communication system, chipset and program

Abstract

The present invention provides a communication control method, an IAB node, a cellular communication system, a chipset, and a program for broadcasting a system information block that does not contain information supporting other relay nodes when a relay node is operating as a mobile relay node in a cellular communication system. [Solution] The communication control method includes the step of a mobile relay node moving from a source donor node to a target donor node receiving a predetermined message from the source donor node and sending an F1 setup request message to the target donor node requesting the establishment of an F1 connection. The predetermined message is a message representing either a request to establish a new F1 connection to the target donor node or an instruction to move to the target donor node.

Description

Technical Field

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

Background Art

[0002] In 3GPP (Third Generation Partnership Project), which is a standardization project for cellular communication systems, the introduction of a new relay node called an IAB (Integrated Access and Backhaul) node has been under consideration (see, for example, Non-Patent Document 1). One or more relay nodes intervene in communication between a base station and a user equipment and perform relay for this communication.

[0003] Furthermore, in NR developed by 3GPP, the aggregation node constituting a gNB is defined as a CU (Central Unit), and the distributed node is defined as a DU (Distributed Unit). Layers above the PDCP layer are disposed in the CU, and layers below the RLC layer are disposed in the DU, and the interface between the CU and the DU is specified as F1.

Prior Art Documents

Non-Patent Documents

[0004]

Non-Patent Document 1

Summary of the Invention

[0005] The first aspect of the communication control method is a communication control method used in a cellular communication system. The communication control method includes the step of a mobile relay node moving from a source donor node to a target donor node receiving a predetermined message from the source donor node and sending an F1 setup request message to the target donor node requesting the establishment of an F1 connection. Here, the predetermined message is a message representing either a request to establish a new F1 connection to the target donor node or an instruction to move to the target donor node.

[0006] The second aspect of the communication control method is a communication control method used in a cellular communication system. The communication control method includes a step of broadcasting a system information block that does not contain information indicating that a relay node is supporting other relay nodes when the relay node is operating as a mobile relay node. [Brief explanation of the drawing]

[0007] [Figure 1] Figure 1 shows an example configuration of a cellular communication system according to one embodiment. [Figure 2] Figure 2 shows the relationship between IAB nodes, parent nodes, and child nodes. [Figure 3] Figure 3 shows an example configuration of a gNB (base station) according to one embodiment. [Figure 4] Figure 4 shows an example configuration of an IAB node (relay node) according to one embodiment. [Figure 5] Figure 5 shows an example configuration of a UE (User Equipment) according to one embodiment. [Figure 6] Figure 6 shows an example of a protocol stack for IAB-MT RRC and NAS connections. [Figure 7] Figure 7 shows an example of a protocol stack for the F1-U protocol. [Figure 8] Figure 8 shows an example of a protocol stack for the F1-C protocol. [Figure 9] Figures 9(A) and 9(B) are diagrams illustrating examples of movement of a mobile IAB node according to the first embodiment. [Figure 10] Figure 10 is a diagram illustrating an example of operation according to the first embodiment. [Figure 11] Figure 11 is a diagram illustrating an example of operation according to the second embodiment. [Figure 12] Figure 12 shows an example of a traditional handover (top) and an example of a group reset (bottom). [Figure 13] Figure 13 shows Solution 1 for reducing service interruptions. [Figure 14] Figure 14 shows Solution 2 for reducing service interruptions. [Modes for carrying out the invention]

[0008] A cellular communication system according to an embodiment will be described with reference to the drawings. In the drawings, identical or similar parts are denoted by the same or similar reference numerals.

[0009] [First Embodiment]

[0010] (Configuration of a 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 wireless access method in the cellular communication system 1 is NR (New Radio), which is a 5G wireless access method. However, LTE (Long Term Evolution) may be applied to the cellular communication system 1 at least partially. Furthermore, future cellular communication systems such as 6G may also be applied to the cellular communication system 1.

[0011] Figure 1 shows an example of the configuration of a cellular communication system 1 according to one embodiment.

[0012] As shown in FIG. 1, a cellular communication system 1 includes a 5G core network (5GC) 10, a user equipment (UE: User Equipment) 100, base station apparatuses (hereinafter sometimes referred to as "base stations") 200-1, 200-2, and IAB nodes 300-1, 300-2. The base station 200 is sometimes referred to as a gNB.

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

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

[0015] The 5GC 10 includes an AMF (Access and Mobility Management Function) 11 and a UPF (User Plane Function) 12. The AMF 11 is an apparatus that performs various types of mobility control and the like for the UE 100. The AMF 11 manages information on an area where the UE 100 is located by communicating with the UE 100 using NAS (Non-Access Stratum) signaling. The UPF 12 is an apparatus that performs transfer control and the like for user data.

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

[0017] Each gNB 200 is mutually connected to the 5GC 10 via an interface called an NG interface. FIG. 1 exemplifies two gNBs 200-1 and 200-2 connected to the 5GC 10.

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

[0019] The cellular communication system 1 supports Integrated Access and Backhaul (IAB) that enables wireless relay for NR access using NR for the backhaul. A donor gNB 200-1 (or donor node, which may hereinafter be referred to as a "donor node") is a termination node of the NR backhaul on the network side, and is a donor base station provided with an additional function for supporting IAB. The backhaul is capable of multi-hop transmission via a plurality of hops (i.e., a plurality of IAB nodes 300).

[0020] Fig. 1 shows an example in which an IAB node 300-1 is wirelessly connected to a donor node 200-1, an IAB node 300-2 is wirelessly connected to the IAB node 300-1, and the F1 protocol is transmitted over two backhaul hops.

[0021] A UE 100 is a movable wireless communication device that performs wireless communication with a cell. The UE 100 may be any device as long as it performs wireless communication with a gNB 200 or an IAB node 300. For example, the UE 100 is a mobile phone terminal and / or a tablet terminal, a notebook personal 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 an IAB node 300 or a gNB 200 via an access link. Fig. 1 shows an example where the UE 100 is wirelessly connected to an IAB node 300-2. The UE 100 communicates indirectly with the donor node 200-1 via the IAB node 300-2 and the IAB node 300-1.

[0022] Figure 2 shows an example of the relationship between IAB node 300, parent nodes, and child nodes.

[0023] As shown in Figure 2, each IAB node 300 has an IAB-DU, which corresponds to the base station function unit, and an IAB-MT (Mobile Termination), which corresponds to the user equipment function unit.

[0024] On the IAB-MT's NR Uu radio interface, adjacent nodes (i.e., higher-level nodes) are called parent nodes. A parent node is the DU of the parent IAB node or donor node 200. The radio link between the IAB-MT and the parent node is called a backhaul link (BH link). Figure 2 shows an example where the parent nodes of IAB node 300 are IAB nodes 300-P1 and 300-P2. The direction toward the parent node is called upstream. From the perspective of UE100, the higher-level node of UE100 may be a parent node.

[0025] Adjacent nodes (i.e., lower-level nodes) on the NR access interface of an IAB-DU are called child nodes. The IAB-DU manages cells, similar to the gNB200. The IAB-DU terminates the NR Uu radio interface to the UE100 and lower-level IAB nodes. The IAB-DU supports the F1 protocol to the CU of donor node 200-1. Figure 2 shows an example where the child nodes of IAB node 300 are IAB nodes 300-C1 to 300-C3, but the child nodes of IAB node 300 may also include the UE100. The direction toward child nodes is called downstream.

[0026] 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 Figure 2, adjacent nodes on the IAB-DU interface become child nodes, and adjacent nodes on the IAB-MT interface become parent nodes. The donor node 200 centrally manages, for example, the resources, topology, and route management of the IAB topology. The donor node 200 is a gNB that provides network access to the UE100 via the backhaul link and access link network.

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

[0028] The wireless communication unit 210 performs wireless communication with the UE 100 and with the IAB node 300. The wireless communication unit 210 includes 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 the wireless signal received by the antenna into a baseband signal (received signal) (downconvert) and outputs it 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 the baseband signal (transmitted signal) output by the control unit 230 into a wireless signal (upconvert) and transmits it from the antenna.

[0029] The network communication unit 220 performs wired (or wireless) communication with 5GC10 and with other adjacent gNB200s. 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 signals from the outside and outputs the received signals 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 signals output by the control unit 230 to the outside.

[0030] The control unit 230 performs various controls in the gNB200. 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 for processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation, demodulation, encoding, decoding, etc., of the baseband signal. The CPU executes programs stored in the memory and performs various processing. The processor performs processing for each layer described later. In each of the embodiments shown below, the control unit 230 may perform each processing or operation in the gNB200.

[0031] (Configuration of relay nodes) Next, the configuration of the IAB node 300, which is a relay node (or relay node device; hereinafter sometimes referred to as "relay node") according to the embodiment, will be described. Figure 4 is a diagram showing an example of the configuration of the IAB node 300. As shown in Figure 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.

[0032] The wireless communication unit 310 performs wireless communication with the gNB200 (BH link) and wireless communication with the UE100 (access link). The wireless communication unit 310 for BH link communication and the wireless communication unit 310 for access link communication may be provided separately.

[0033] The wireless communication unit 310 includes 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 the wireless signal received by the antenna into a baseband signal (received signal) (downconvert) and outputs it 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 the baseband signal (transmitted signal) output by the control unit 320 into a wireless signal (upconvert) and transmits it from the antenna.

[0034] 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 for processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in the memory and performs various processes. The processor performs processing for each layer described later. In each of the embodiments shown below, the control unit 320 may perform each process or operation in the IAB node 300.

[0035] (User device configuration) Next, the configuration of the user device UE100 according to the embodiment will be described. Figure 5 is a diagram showing an example of the configuration of UE100. As shown in Figure 5, UE100 has a wireless communication unit 110 and a control unit 120.

[0036] The wireless communication unit 110 performs wireless communication on the access link, i.e., wireless communication with the gNB200 and wireless communication with the IAB node 300. The wireless communication unit 110 may also perform wireless communication on the side link, i.e., wireless communication with other UE100s. The wireless communication unit 110 has a receiving unit 111 and a transmitting unit 112. The receiving unit 111 performs various types of reception under the control of the control unit 120. The receiving unit 111 includes an antenna and converts the wireless signal received by the antenna into a baseband signal (received signal) (downconvert) and outputs it to the control unit 120. The transmitting unit 112 performs various types of transmission under the control of the control unit 120. The transmitting unit 112 includes an antenna and converts the baseband signal (transmitted signal) output by the control unit 120 into a wireless signal (upconvert) and transmits it from the antenna.

[0037] 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 for processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation, demodulation, encoding, and decoding of baseband signals. The CPU executes programs stored in the memory and performs various processes. The processor performs processing for each layer described later. The control unit 120 may perform each process in the UE 100 in each of the embodiments shown below.

[0038] (Protocol stack configuration) Next, the configuration of the protocol stack according to the embodiment will be described. Figure 6 shows an example of a protocol stack for IAB-MT RRC connection and NAS connection.

[0039] As shown in Figure 6, the IAB-MT of IAB node 300-2 has a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, a PDCP (Packet Data Convergence Protocol) layer, an RRC (Radio Resource Control) layer, and a NAS (Non-Access Stratum) layer.

[0040] The PHY layer performs encoding and decoding, modulation and demodulation, antenna mapping and demapping, and resource mapping and demapping. Data and control information are transmitted between the PHY layer of IAB-MT at IAB node 300-2 and the PHY layer of IAB-DU at IAB node 300-1 via a physical channel.

[0041] The MAC layer performs data priority control, retransmission processing using Hybrid Automatic Repeat request (HARQ), and random access procedures. Data and control information are transmitted between the MAC layer of IAB-MT on IAB node 300-2 and the MAC layer of IAB-DU on IAB node 300-1 via a transport channel. The MAC layer of IAB-DU includes a scheduler. The scheduler determines the transport format (transport block size, modulation and coding scheme (MCS)) and allocated resource blocks for the up and down links.

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

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

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

[0045] The NAS layer, located above the RRC layer, handles session management and mobility management, among other things. NAS signaling is transmitted between the NAS layer of IAB-MT on IAB node 300-2 and AMF11.

[0046] Figure 7 shows the protocol stack for the F1-U protocol. Figure 8 shows the protocol stack for the F1-C protocol. Here, an example is shown where donor node 200 is divided into CU and DU.

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

[0048] In each backhaul link, the BAP layer's PDUs (Protocol Data Units) are transmitted via backhaul RLC channels (BH NR RLC channels). By configuring multiple backhaul RLC channels in each BH link, traffic prioritization and QoS (Quality of Service) control are possible. The mapping 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.

[0049] As shown in Figure 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 Figure 7.

[0050] In the following, the processes or operations performed by the IAB-DU and IAB-MT of the IAB may be described simply as "IAB processes or operations." 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 IAB node 300-1 transmitting the message to IAB node 300-2. Similarly, the processes or operations of the DU or CU of donor node 200 may be described simply as "donor node processes or operations."

[0051] Furthermore, the upstream direction and the uplink (UL) direction may not be distinguished. Additionally, the downstream direction and the downlink (DL) direction may not be distinguished.

[0052] (Mobile IAB node) Currently, 3GPP is considering the introduction of mobile IAB nodes. A mobile IAB node is, for example, an IAB node that is in motion. A mobile IAB node may be a mobile IAB node, or an IAB node that has the capability to move, or an IAB node that is currently stationary but is certain to move in the future (or is expected to move in the future).

[0053] A mobile IAB node allows, for example, a UE100 under the mobile IAB node to move along with the mobile IAB node while receiving services from it. For example, a user (or UE100) riding in a vehicle could receive services via a mobile IAB node installed in the vehicle.

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

[0055] A mobile IAB node can also connect to an intermediate IAB node. Furthermore, a mobile IAB node can connect to donor node 200. A mobile IAB node can also change its connection destination through migration or handover. The source of the connection may be an intermediate IAB node. The source of the connection may also be donor node 200. Furthermore, the destination may be an intermediate IAB node. The destination of the connection may also be donor node 200.

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

[0057] Furthermore, in the following, a moving IAB node may also be referred to as a "mobile IAB node." The same moving IAB node may also be referred to as a "migrating IAB node." In either case, it may be written as a moving IAB node.

[0058] (Partial and total movement) A migrating IAB node may move between 200 donor nodes (IAB-donors).

[0059] Figures 9(A) and 9(B) illustrate an example of the movement of a mobile IAB node 300M according to the first embodiment. Figures 9(A) and 9(B) illustrate an example in which the mobile IAB node 300M moves from a source donor node 200-S to a target donor node 200-T.

[0060] Of these, Figure 9(A) shows an example of partial migration, and Figure 9(B) shows an example of full migration.

[0061] As shown in Figure 9(A), in a partial move, the IAB-DU#1 (and UE100) of the moving IAB node 300M is terminated at CU#1 (200-CU#1) of the source donor node 200-S, while the IAB-MT of the moving IAB node 300M moves to CU#2 (200-CU#2) of the target donor node 200-T. A partial move refers to a state where, for example, the connection of UE100 under the moving IAB node 300M remains with the source donor node 200-S via the IAB-DU#1 of the moving IAB node 300M.

[0062] On the other hand, as shown in Figure 9(B), in a full migration, the connection of the migrating IAB node 300M (and UE100) has moved from CU#1 (200-CU#1) of the source donor node 200-S to CU#2 (200-CU#2) of the target donor node 200-T. A full migration refers to a state where, for example, the connection of UE100 has moved to the target donor node 200-T via IAB-DU#2 of the migrating IAB node 300M.

[0063] In order to achieve the overall migration, it is necessary that IAB-DU#2 be logically established at the migrating IAB node 300M, and that an F1 connection be established between IAB-DU#2 and CU#2 (200-CU#2) of the target donor node 200-T. This is because UE100 can exchange various messages with the target donor node 200-T via IAB-DU#2.

[0064] Furthermore, in order for an F1 connection to be established between IAB-DU#2 and CU#2 (200-CU#2) of target donor node 200-T, an F1 setup request (F1 SETUP REQUEST) must be sent from the mobile IAB node 300M to CU#2 (200-CU#2) of target donor node 200-T.

[0065] However, the mobile IAB node 300M does not know when to send the F1 setup request. If the F1 setup request is not sent at the appropriate time, the F1 connection with the target donor node 200-T may not be established, and the entire migration may not be able to be performed. As a result, the UE100 under mobile IAB node 300M may not be able to connect to the network properly.

[0066] Therefore, the objective of the first embodiment is to enable the UE100 to connect to the network properly.

[0067] In the first embodiment, a source donor node (e.g., source donor node 200-S) sends a request to establish a new F1 connection to a target donor node (e.g., target donor node 200-T) to a mobile relay node (e.g., mobile IAB node) that is moving from the source donor node to the target donor node (e.g., target donor node 200-T).

[0068] This means that, for example, when the mobile IAB node 300M receives a new establishment request from the source donor node 200-S, it only needs to send an F1 setup request message, and can send that message at the appropriate time. Therefore, the mobile IAB node 300M can establish an F1 connection via IAB-DU#2 at the appropriate time and perform the overall move. As a result, UE100 can connect to the network via IAB-DU#2, and thus can connect to the network at the appropriate time.

[0069] (Example of operation according to the first embodiment) Figure 10 is a diagram illustrating an example of operation according to the first embodiment.

[0070] Figure 10 shows an example where the moving IAB node 300M moves from the source donor node 200-S to the target donor node 200-T, performing a complete migration. The source donor node 200-S may consist of CU#1 (200-CU#1) and DU#1 (200-DU#1) of the source donor node 200-S shown in Figure 9(B). Similarly, the target donor node 200-T may consist of CU#2 (200-CU#2) and DU#2 (200-DU#2) of the target donor node 200-T shown in Figure 9(B).

[0071] As shown in Figure 10, in step S10, the source donor node 200-S decides on the migration of the moving IAB node 300M. The CU of the source donor node 200-S may decide on the migration in response to receiving a measurement report from the IAB-MT of the moving IAB node 300M via the DU of the source donor node 200-S.

[0072] In step S11, the source donor node 200-S sends a HANDOVER REQUEST message to the target donor node 200-T for the migrating IAB node 300M. The source donor node 200-S may include in the message an execution request requesting that the migrating IAB node 300M perform a full migration. Alternatively, the source donor node 200-S may include in the message information indicating whether or not a full migration by the migrating IAB node 300M will be performed. Alternatively, the source donor node 200-S may include in the message an execution request requesting that the migrating IAB node 300M perform a partial migration. Alternatively, the source donor node 200-S may include in the message information indicating whether or not a partial migration by the migrating IAB node 300M will be performed. For example, the CU on source donor node 200-S sends the handover request message, which is an Xn message, to the CU on target donor node 200-T.

[0073] In step S12, the target donor node 200-T decides to accept the handover based on the handover request message. The target donor node 200-T also decides to proceed with the overall move. For example, the CU of the target donor node 200-T decides to accept the handover and proceed with the overall move in response to receiving the handover request message.

[0074] In step S13, the target donor node 200-T sends a HANDOVER REQUEST ACKNOWLEDGE message to the source donor node 200-S. For example, if the CU of the target donor node 200-T decides to accept the handover (step S12), it sends this message, which is an Xn message, to the CU of the source donor node 200-S.

[0075] The handover request approval message includes an RRC Reconfiguration message for the moving IAB node 300M. This RRC Reconfiguration message may include information requesting the establishment of a new F1 connection, or it may include information indicating that a full migration is being performed. This RRC Reconfiguration message functions, for example, as a handover command instructing a handover to the moving IAB node 300M.

[0076] In step S14, the source donor node 200-S may send a request to establish a new F1 connection to the moving IAB node 300M. For example, the CU of the source donor node 200-S generates an F1 message containing a request to establish a new F1 connection in response to receiving a handover request approval message (step S13), and sends the generated F1 message to the IAB-DU of the moving IAB node 300M. The CU of the source donor node 200-S may send the F1 message before the moving IAB node 300M's move decision (step S10). The CU of the source donor node 200-S may also send the F1 message immediately after the move decision. Note that the request to establish a new connection may be included in the RRC Reconfiguration message in step S13 and step S15 described below. In this case, step S14 may be omitted.

[0077] In step S15, the source donor node 200-S sends the RRC reconfiguration message included in the handover request approval message (step S13) to the mobile IAB node 300M. For example, the following process takes place: The CU of the source donor node 200-S extracts the RRC reconfiguration message from the handover request approval message received in step S13 and sends an F1 message containing the RRC reconfiguration message to the DU of the source donor node 200-S. The DU of the source donor node 200-S then extracts the RRC reconfiguration message from the F1 message and sends the RRC reconfiguration message to the IAB-MT of the mobile IAB node 300M. The RRC reconfiguration message may be a request to establish a new F1 connection to the target donor node 200-T. Alternatively, the RRC reconfiguration message may contain information representing a request to establish a new F1 connection to the target donor node 200-T. When the AS layer receives a request to establish a new F1 connection, it may notify the higher layer (F1AP layer) of the request.

[0078] In step S16, the mobile IAB node 300M recognizes that it needs to establish a new F1 connection to the target donor node 200-T, having received either an F1 message (step S14) or an RRC reconfiguration message (step S15) that includes a request to establish a new F1 connection.

[0079] Then, the mobile IAB node 300M sends an F1 setup request message to the target donor node 200-T requesting the establishment of the F1 connection. In other words, the mobile IAB node 300M sends the F1 setup request message in response to receiving a request to establish a new F1 connection (step S14 or step S15). For example, the IAB-DU of the mobile IAB node 300M sends the F1 setup request message to the CU of the target donor node 200-T. The mobile IAB node 300M may also send the F1 setup request message via the source donor node 200-S.

[0080] In step S17, the moving IAB node 300M establishes a new F1 connection with the target donor node 200-T. As a result, the moving IAB node 300M has "IAB-DU#2" as shown in Figure 9(B). Then, the moving IAB node 300M establishes an F1 connection with the CU of the target donor node 200-T via "IAB-DU#2", and the entire migration can be executed.

[0081] Once the overall migration is complete, the relocated IAB node 300M performs the process of terminating the F1 connection to the source donor node 200-S. This F1 connection is, for example, the F1 connection from "IAB-DU#1" to CU#1 (200-CU#1) of the source donor node 200-S, as shown in Figure 9(B). The overall migration may also be considered complete when the handover of all UE100s under the relocated IAB node 300M is complete.

[0082] In step S18, the source donor node 200-S may terminate the F1 connection by sending a request to terminate the F1 connection to the mobile IAB node 300M. For example, the CU of the source donor node 200-S sends an F1 message containing the request to terminate the F1 connection to the IAB-DU of the mobile IAB node 300M.

[0083] In step S19, the target donor node 200-T may send a request to discard the F1 connection. In this case, an F1 message containing the request to discard the F1 connection may also be sent. For example, the CU of the target donor node 200-T sends an F1 message containing the request to discard the F1 connection to the IAB-DU of the moving IAB node 300M. The CU of the target donor node 200-T may send an F1 message containing information indicating the completion of the overall move instead of the request to discard the F1 connection.

[0084] In step S20, the moving IAB node 300M determines that the entire move is complete when all UE contexts are gone (or all UE contexts are released) in the F1 connection (F1 entity) connected to the source donor node 200-S. The moving IAB node 300M then sends an F1 REMOVAL REQUEST message to the source donor node 200-S requesting the termination of the F1 connection.

[0085] The mobile IAB node 300M may send an F1 termination request message in response to receiving either an F1 connection termination request from the source donor node 200-S (step S18) or an F1 connection termination request from the target donor node 200-T (step S19).

[0086] Thus, when the mobile IAB node 300M receives a request from either the source donor node 200-S or the target donor node 200-T to drop the F1 connection to the source donor node 200-S, it sends an F1 drop request message. Therefore, the mobile IAB node 300M can send the F1 drop request message to the source donor node 200-S at the appropriate time.

[0087] [Second Embodiment] Next, a second embodiment will be described.

[0088] 3GPP proposes that mobile IAB node 300M should not be connected to IAB node 300 as a child or grandchild node, but only to UE100. This is because if IAB node 300 is connected to mobile IAB node 300M as a child or grandchild node, it is anticipated that control will become complicated not only for the IAB node itself, but also for the UEs under that IAB node.

[0089] The problem here is how to connect only the UE100 to the mobile IAB node 300M.

[0090] The objective of the second embodiment is to enable the UE100 to properly connect to the network by allowing only the UE100 to connect to the mobile IAB node 300M.

[0091] Therefore, in the second embodiment, when the IAB node 300 is operating as a mobile IAB node 300M, the IAB node 300 does not set the IAB support information (iab-Support IE), which is an information element indicating that it supports IAB nodes, in SIB1. That is, the IAB node 300 broadcasts an SIB1 that does not include the IAB support information.

[0092] Specifically, when a relay node (e.g., IAB node 300) is operating as a mobile relay node (e.g., mobile IAB node 300M), it broadcasts a system information block (e.g., SIB1) that does not include information indicating support for other relay nodes (e.g., IAB support information).

[0093] As a result, the IAB-MT of the IAB node 300 that received the SIB1 recognizes that the IAB node (or cell that reported the SIB1) does not support IAB nodes. Therefore, the IAB-MT of the IAB node 300 that received the SIB1 does not perform connection processing (for example, a cell selection procedure or a cell re-selection procedure) to the IAB node that reported the SIB1.

[0094] Furthermore, even if the SIB1 does not contain IAB support information, the UE100 that receives the SIB1 will not be restricted from connecting to its own IAB node 300 because IAB support information is an information element for the IAB node 300.

[0095] Therefore, IAB node 300, operating as mobile IAB node 300M, will not have any other IAB nodes as child or grandchild nodes, and will only have UE100. Thus, UE100 under mobile IAB node 300M can properly connect to the network.

[0096] (Example of operation according to the second embodiment) Next, an example of operation according to the second embodiment will be described.

[0097] Figure 11 is a diagram illustrating an example of operation according to the second embodiment.

[0098] As shown in Figure 11, in step S30, IAB node 300-1 determines that it is operating as mobile IAB node 300M. IAB node 300-1 determines that it is operating as mobile IAB node 300M, for example, as follows.

[0099] Firstly, IAB node 300-1 may determine that it is operating as a mobile IAB node 300M by the fact that it is moving. IAB node 300-1 may also determine that it is moving based on the detection result of the acceleration sensor or the GNSS (Global Navigation Satellite System) received signal from the GNSS (Global Navigation Satellite System) receiver.

[0100] Secondly, IAB node 300-1 may determine that it is operating as mobile IAB node 300M if it has been authorized by the core network (CN) to operate as mobile IAB node 300M. IAB node 300-1 may also determine that such authorization has been granted by receiving a message from AMF11 or the like that contains information indicating such authorization.

[0101] Thirdly, IAB node 300-1 may determine that it is operating as a mobile IAB node 300M if it has been permitted by donor node 200 to operate as a mobile IAB node 300M. IAB node 300-1 may determine that such permission has been granted by receiving a message from donor node 200 that contains information indicating such permission. Alternatively, IAB node 300-1 may implicitly determine that it is permitted to operate as a mobile IAB node 300M if the settings specific to mobile IAB node 300M have been set by donor node 200.

[0102] Furthermore, if IAB node 300 is permitted to operate as mobile IAB node 300M in the higher layer, it may output this permission to the AS layer.

[0103] In step S31, if IAB node 300-1 is operating as mobile IAB node 300M, it does not transmit IAB support information. That is, IAB node 300-1 broadcasts an SIB1 that does not contain IAB support information. IAB node 300-1 may broadcast a system information block (e.g., SIB1) that includes information indicating that it is mobile IAB node 300M. Alternatively, IAB node 300-1 may broadcast a system information block (e.g., SIB1) that includes information indicating that it is not intermediate IAB node 300S.

[0104] When another IAB node 300-2 receives SIB1, it excludes the cell of IAB node 300-1 that announced SIB1 (step S31) from the candidate cells for the cell selection procedure or cell re-selection procedure. As a result, the other IAB node 300-2 will not establish a connection to IAB node 300-1 that announced SIB1.

[0105] The terms "based on" and "depending on" used in this disclosure do not mean "based solely on" or "depending solely on" unless otherwise specified. "Based on" means both "based solely on" and "at least partially on." Similarly, "depending on" means both "at least partially on" and "at least partially on." Furthermore, the terms "include" and "comprise" do not mean to include only the listed items, but may include only the listed items or may include additional items in addition to the listed items. Also, the term "or" used in this disclosure is not intended to mean exclusive OR. Moreover, any reference to elements using designations such as "first," "second," etc., used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used herein as a convenient way to distinguish between two or more elements. Therefore, references to the first and second elements do not imply that only two elements may be adopted therein, or that the first element must precede the second element in any way. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles shall be plural unless it is clearly indicated by the context that they are not.

[0106] Although the embodiments have been described in detail above with reference to the drawings, the specific configuration is not limited to those described above, and various design changes can be made without departing from the gist of the invention.

[0107] This application claims priority to U.S. Provisional Application No. 63 / 395944 (filed August 8, 2022), the entirety of which is incorporated into the specification of this application.

[0108] (First Appendix)

[0109] (Note 1) A communication control method used in a cellular communication system, The source donor node sends a request to a mobile relay node moving from the source donor node to the target donor node to establish a new F1 connection to the target donor node. Communication control method.

[0110] (Note 2) The mobile relay node, upon receiving the new establishment request, further comprises the step of sending an F1 setup request message to the target donor node requesting the establishment of the F1 connection. The communication control method described in Appendix 1.

[0111] (Note 3) The source donor node further includes the step of sending an execution request to the target donor node requesting the execution of a full migration by the mobile relay node, The aforementioned overall movement is a state in which the connection of the transfer relay node has moved from the CU of the source donor node to the CU of the target donor node. The communication control method described in Appendix 1 or Appendix 2.

[0112] (Note 4) The further step includes the source donor node or the target donor node sending a request to the mobile relay node to terminate the F1 connection to the source donor node. A communication control method as described in any of Appendix 1 to Appendix 3.

[0113] (Note 5) The mobile relay node, upon receiving the discard request, further comprises the step of sending an F1 discard request message to the source donor node requesting the discard of the F1 connection to the source donor node. A communication control method as described in any of Appendix 1 to Appendix 4.

[0114] (Note 6) A communication control method used in a cellular communication system, The relay node, when operating as a mobile relay node, has the step of broadcasting a system information block that does not contain information indicating that it supports other relay nodes. Communication control method.

[0115] (Note 7) The notification step includes the step of notifying the relay node of the system information block which includes information indicating that the relay node is the mobile relay node. The communication control method described in Appendix 6.

[0116] (Second Addendum) 1. Introduction RAN#94e approved a new work item related to mobile IABs. Its WID was revised in RAN#96 as follows:

[0117] The detailed objectives for this work item are as follows: Define migration / topology adaptation procedures to enable the mobility of IAB nodes. This includes the inter-donor migration (complete migration) of entire moving IAB nodes. • Enhance the mobility of IAB nodes and the UEs they serve. This includes aspects related to group mobility. There are no optimizations targeting surrounding UEs. Note: The solution should avoid touching on topics that have already been discussed in Rel-17, or topics that have been excluded from Rel-17, except for enhancements specific to IAB node mobility. • IAB node mobility is necessary to mitigate interference, such as avoiding collisions between reference signals and control signals (PCI, RACH, etc.). Note: At the start of the work, RAN3 and RAN2 should discuss the potential complexities between the scenario in which the mobile IAB node connects to a stationary (intermediate) IAB node and the scenario in which the mobile IAB node connects directly to an IAB donor.

[0118] The following principles should be respected. - The relocated IAB node needs to be able to provide services to legacy UEs. - Solutions that provide optimization for mobile IABs may require extensions to Rel-18UE, but only if such extensions are backward compatible.

[0119] One of the main challenges of Rel-18 is how to efficiently perform the handover of multiple descendant UEs during the migration of a mobile IAB node. This note provides an initial discussion on enhancing the mobility of mobile IABs from the perspective of UE handover.

[0120] 2. Discussion 2.1 Group Reset Group UE mobility is expected to be one of the possible enhancements for mobile IABs because when a mobile IAB node moves to a new IAB donor, many UEs need to be handed over simultaneously.

[0121] Under the current specification, handover is indicated by dedicated signaling, namely RRC reconfiguration and synchronization. This means that multiple individual messages are sent to each UE simultaneously. Therefore, group reconfiguration is being considered as a candidate to reduce signaling overhead and delay. This is expected to allow reconfiguration of multiple UEs with a single message.

[0122] The group reconfiguration has already been discussed in Rel-17MBS as a "common RRC structure," and the following summary was provided.

[0123] Summary of Common RRC Structures conclusion The majority opinion, 16 to 5, was that standardizing RRC settings is impossible. From the reporter's perspective, there appear to be no technical limitations preventing this, but there seems to be strong opposition to doing so. The general understanding is that adopting a common RRC structure would increase the overhead of the Uu signal, but would benefit the F1 / E1 signals. However, considering the companies' perspective, it has been proposed to maintain the current RRC signal structure.

[0124] Proposal 2: Maintain the current CRRRC structure and do not promote a common RRC structure (i.e., there will be no impact on RRCCR).

[0125] The key point is that each UE needs to receive individual RRC resets, and in addition, group RRC resets. Therefore, there was a common view that MBS offered little benefit (rather a disadvantage) to the Uu signal, but the F1 / E1 signal might offer some benefit. As a result, RAN2 decided to maintain its current structure, meaning it will only perform individual RRC resets.

[0126] In the case of P2, if RAN2 is agreed upon, RRC assumes that it will continue to use a dedicated UE configuration.

[0127] Similar concerns apply to mobile IABs. That is, different UEs have different configurations, and a single group reconfiguration cannot handle the different configurations of different UEs. While F1 signal reduction is also more useful for mobile IABs than for MBSs, access link signal reduction remains more important because backhaul links are generally assumed to be over FR2.

[0128] The WID clearly states that "solutions should be avoided, except for improvements specifically for IAB node mobility, so as to avoid touching on areas where Rel-17 discussions have already taken place and those topics have been excluded from Rel-17," therefore, RAN2 does not need to reopen group reconfiguration (or common RRC structure) in Rel-18 mobile IABs, at least from RAN2's perspective.

[0129] Proposal 1: RAN2 should agree to continue using only individual RRC reconfiguration for UE handovers associated with the relocation of IAB nodes, as is currently the case.

[0130] 2.2 Handover for Legacy UE As indicated in the WID (Work Item Description), "The relocated IAB node needs to support the legacy UE." Therefore, RAN2 should consider a handover method for the legacy UE.

[0131] RAN3 had two solutions to reduce service interruptions during the migration of IAB nodes between donors in Rel-17. Solution 1 is shown in Figure 12 below.

[0132] Solution 1 involves the IAB-DU withholding the RRC reconfiguration message to the child node upon completion of the handover. RAN2 concluded that both solutions require further discussion, but determined that Solution 1 has less overall impact than Solution 2.

[0133] Of course, it is also possible to perform a UE handover without Solution 1. However, as with the IAB node issue in Rel-17, since the handover of descendant UEs is involved, if Solution 1 is not applied, the UEs will experience service interruptions during the migration of the IAB node in transit. Therefore, RAN2 must assume that Solution 1 for intra-donor migration will be reused to reduce service interruptions for legacy UEs during the migration of inter-donor moving IAB nodes.

[0134] Proposal 2: RAN2 should assume that Solution 1, which reduces service interruptions during the migration of IAB nodes within donors for Rel-17, can be reused for handover of legacy UEs.

[0135] 2.3 Conditional Reset If individual RRC reconfigurations are sent to the UE simultaneously, the large number of RRC messages and their corresponding responses could increase the load on radio resources. Conditional reconfiguration is considered useful for load balancing, i.e., time-domain distribution. This allows IAB donors to avoid sending many messages simultaneously by pre-configuring IAB nodes in transit. A similar solution exists in Solution 2 for reducing service disruptions in Rel-17.

[0136] Finding 1: Conditional rescheduling may help IAB donors distribute RRC rescheduling messages over the time domain.

[0137] Depending on how the relocating IAB-DU handles cells, and partly due to RAN3's decisions, it's possible that the relocating IAB-DU may need to change its cell ID after the migration of the relocating IAB node. For example, this change might be necessary to avoid PCI collisions in the target topology. In this case, the UE also needs to move from the old cell (the cell that disappears) to the new cell (the cell that becomes available), but both cells are managed by the same relocating IAB-DU. For such "cell shifts," conditional reconfiguration is considered more effective than traditional HO commands.

[0138] Finding 2: If the serving cell ID changes due to the migration of a moving IAB node, conditional reconfiguration may function efficiently.

[0139] Considering the examples above (but not limited to these), improvements to conditional resetting may be worth discussing in RAN2. For example, one could consider whether existing trigger conditions can be reused for moving IABs.

[0140] Proposal 3: RAN2 should consider whether conditional reconfiguration to UE can be enhanced to improve the mobility of mobile IAB nodes.

[0141] 2.4 RACHless Handover Under the current specifications, when a UE receives an HO command, it must first initiate a random access procedure. However, if the target cell is the same as the source cell, i.e., if the same IAB-DU handles both cells, only the cell ID may differ. In this case, since the timing advance is also the same for both cells, a PRACH transmission is unnecessary. RAN2 should consider whether to specify RACH-less handover to improve the mobility of mobile IABs. It should be noted that RACH-less handover applies only to Rel-18UEs.

[0142] Proposal 4: RAN2 should consider whether RACH-less handover for Rel-18UE is useful due to the relocation of IAB nodes.

[0143] 2.5 Lossless Handover During the planning stage, the issue of packet loss due to hop-by-hop ARQ was discussed. This problem was observed "when IAB topology changes were performed after a hop-by-hop hole link failure, or when inter-CU handovers occurred." In Rel-16 / 17, this was not pursued as it was considered a rare case under the assumption of deployments using static IAB nodes.

[0144] In Rel-18 mobile IABs, such packet loss is still considered a rare case if the mobile IAB node is always the access IAB node. The justification section of the WID states the assumption that "the mobile IAB node has no descendant IAB nodes, i.e., it only serves UEs." Therefore, this assumption should be verified by RAN2.

[0145] Proposal 5: RAN2 should ensure that mobile IAB nodes are always access IAB nodes, and therefore ensure that packet loss due to hop-by-hop ARQ is a rare case in Rel-18 mobile IABs.

[0146] Regarding general packet loss, even with legacy handovers, the UE's PDCP sublayer can handle data recovery as it does now. Therefore, no improvements are planned for lossless handovers of the UE due to the relocation of IAB nodes.

[0147] Proposal 6: RAN2 should agree that existing UE PDCP data recovery can be used in lossless handovers due to the relocation of IAB nodes, meaning no improvements are necessary.

[0148] 2.6 Other Aspects WID states that the mobile IAB node will only support UEs.

[0149] • A mobile IAB node should not have child nodes, meaning it should only support UEs.

[0150] To ensure this restriction is met, existing IAB support IEs can be reused. That is, by preventing the mobile IAB node from configuring this IE in SIB1, access from other IAB nodes is prevented, while allowing access from the UE. The question is how such restrictions are documented in the specification. A clear description in the Stage-2 specification would help avoid confusion in mobile IAB implementations.

[0151] Proposal 7: It should be agreed that if RAN2 is functioning as a mobile IAB node in this release, the Stage-2 specification should include a clause stating that the IAB node should not configure IAB support IE in the SIB.

Claims

1. A communication control method used in a cellular communication system, If an IAB node is operating as a physically mobile IAB node, it broadcasts a system information block that does not contain information indicating support for other IAB nodes. The system information block includes information indicating that the IAB node is the mobile IAB node. Communication control method.

2. An IAB node in a cellular communication system, When the IAB node is operating as a physically movable mobile IAB node, it has a transmitter that broadcasts a system information block that does not contain information indicating support for other IAB nodes. The system information block includes information indicating that the IAB node is the mobile IAB node. IAB node.

3. Having the IAB node described in claim 2 Cellular communication system.

4. For IAB nodes, If the IAB node is operating as a physically movable mobile IAB node, it will perform a process that broadcasts a system information block that does not contain information indicating that it supports other IAB nodes. The system information block includes information indicating that the IAB node is the mobile IAB node. program.

5. It is an IAB node chipset, If the IAB node is operating as a physically movable mobile IAB node, it performs a process of broadcasting a system information block that does not contain information indicating that it supports other IAB nodes. The system information block includes information indicating that the IAB node is the mobile IAB node. Chipset.

Images