Communication device and control method

Abstract

To provide a mechanism that enables the migration of a DU according to a communication status.SOLUTION: The present invention discloses a communication device that functions as a mobile IAB (Integrated Access and Backhaul) node. The communication device includes determination means that performs a determination process including whether or not to migrate a DU (Distributed Unit) functional unit based on a communication status, and first notification means that transmits notification information regarding the migration to an IAB donor CU (Central Unit) that is being connected when the determination means determines that the migration should be performed.SELECTED DRAWING: Figure 6

Description

[Technical field]

[0001] The present disclosure relates to a communication device, a control method, and a program. [Background technology]

[0002] The Third Generation Partnership Project (3GPP (registered trademark)) has formulated cellular communication standards. In the cellular communication standards in 3GPP (hereinafter also referred to as "3GPP standards"), standardization of Integrated Access and Backhaul (IAB), which integrates access lines and backhaul lines, is underway (see Patent Document 1).

[0003] In IAB, radio resources used for an access line between a base station and a user terminal (UE, User Equipment) are also used for a backhaul line. For example, millimeter wave band radio resources such as 28 GHz band may be used in IAB. By using IAB, a relay device (IAB node) can relay communication between a base station device (IAB donor) and a terminal device by a radio line. As a result, area coverage can be expanded at a lower cost than when a wired line such as optical fiber is used.

[0004] In addition, the IAB node is composed of an MT (Mobile Termination) that serves as a connection functional unit with a parent node, and a DU (Distributed Unit) that serves as a wireless connection functional unit with UE and lower nodes.

[0005] In addition, it has been proposed to transfer MT and DU of an IAB node independently between different donors (Patent Document 2). [Prior art documents] [Patent documents]

[0006] [Patent Document 1] Special Publication No. 2019-534625 [Patent Document 2] International Patent Publication No. 2021 / 098085 Brochure Summary of the Invention [Problem to be solved by the invention]

[0007] 3GPP is considering expanding the coverage area in urban areas by using on-board relay devices that function as IAB nodes mounted on vehicles (mobiles) such as buses, trains, and taxis. Hereinafter, such on-board relay devices will be called mobile IAB. Mobile IAB nodes are also called MBSR (Mobile base Station Relay).

[0008] When using mobile IAB, various problems are likely to arise that cannot be solved by the specifications of cellular communication standards formulated up to Release 17, which were based on the assumption that IAB nodes and fixed base stations would be installed in a fixed location.

[0009] For example, the conventional technology has a problem in that it does not have a mechanism that enables the migration of mobile IAB DUs according to communication conditions.

[0010] The present invention has been made in consideration of at least one of the above problems. One aspect of the present invention aims to provide a mechanism that enables DU migration according to communication conditions. Another aspect of the present invention aims to improve the convenience of cellular communication. [Means for solving the problem]

[0011] A communication device according to one aspect of the present invention is a communication device that functions as a mobile IAB (Integrated Access and Backhaul) node, A determination means for performing a determination process including whether or not to migrate a DU (Distributed Unit) function unit based on a communication state; and a first notification means for transmitting notification information regarding the transition to a connected IAB donor CU (Central Unit) when the determination means determines that the transition should be performed. Effect of the Invention

[0012] According to one aspect of the present invention, it is possible to provide a mechanism that enables DU migration according to communication conditions. [Brief description of the drawings]

[0013] [Figure 1] FIG. 1 illustrates an example of a communication system. [Figure 2A] FIG. 1 is a diagram showing the concept of the IAB protocol stack (part 1). [Figure 2B] FIG. 2 is a diagram showing the concept of the IAB protocol stack (part 2). [Diagram 3] FIG. 1 illustrates the format of a BAP Data Protocol Data Unit (PDU) or packet. [Figure 4] FIG. 2 is a diagram illustrating the hardware configuration of a mobile IAB node. [Figure 4A] FIG. 2 is a block diagram showing an example of the configuration of software functions of a mobile IAB node (first embodiment). [Diagram 5] FIG. 1 is a conceptual diagram illustrating an example of a mobile IAB node migrating between different IAB donors in an embodiment of the present invention. [Figure 6] FIG. 11 is a sequence diagram for explaining the flow of a DU transition process of a mobile IAB node (first embodiment). [Figure 7] A diagram showing an example of control by a mobile IAB node to determine DU transition depending on the network slice type (first embodiment). [Figure 8] FIG. 11 is a diagram showing an example of control by a mobile IAB node to determine DU transition in the first embodiment (first embodiment). [Figure 9] FIG. 1 is a flowchart showing the information collection process of an IAB donor (first embodiment). [Figure 10] FIG. 13 is a block diagram showing an example of the configuration of the software functions of an IAB donor (third embodiment). [Figure 11] FIG. 13 is a sequence diagram showing an example of control executed by an IAB donor (third embodiment). [Figure 12] FIG. 13 is a flowchart showing an example of control executed by an IAB donor (third embodiment). [Figure 13] FIG. 13 is a flowchart showing an example of control executed by an IAB donor (third embodiment). DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] Hereinafter, each embodiment will be described in detail with reference to the accompanying drawings. In the following description, the "number ***" in TS*** represents the number of the Technical Specification in the 3GPP standard.

[0015] <Background of this embodiment> 3GPP considers inter-IAB donor redundancy, where an IAB node, called a border IAB node, can access two different parent nodes connected to two different IAB donors. In this case, each IAB donor manages a different IAB topology (also called an IAB network). A border IAB node may belong to a single IAB topology, i.e., to a single IAB donor for configuration and management. Again, the border IAB node can route packets from a first IAB topology managed by a first IAB donor to a second IAB topology managed by a second IAB donor. The advantage of such inter-donor redundancy is that the first IAB donor can perform offloading by routing some of its packets through the second IAB topology. This can mitigate congestion issues and overcome Radio Link Failure (RLF) issues that may occur in the first IAB topology.

[0016] There are other situations in which an IAB node may become a border IAB node. For example, in case of a partial migration of an IAB node decided by an IAB donor, the MT of the IAB node is connected to a single parent IAB node belonging to another IAB topology controlled by another IAB donor. This situation may also occur for an IAB node that recovers via a parent IAB node belonging to another IAB topology due to a radio link failure. In such a case, the migrated IAB node and its potential descendant IAB nodes still belong to the initial IAB topology. Such a partial migration may be called MT migration. To be able to route traffic via the other IAB topology, a traffic migration needs to be performed after the MT migration. That is, a traffic migration needs to be performed in which the traffic related to the border IAB node and its descendant IAB nodes is routed via the other IAB topology up to the border IAB node (i.e., the migrated IAB node). For a fixed IAB node, only one MT migration is required. Indeed, the backhaul link (defined between two consecutive IAB nodes in the radio backhaul) may experience radio failures due to varying radio conditions. In this case, for a non-mobile IAB node, this is a temporary situation where the link may be restored after some time. Thus, for such a fixed IAB node, there is no need to perform multiple MT transitions for the same or different IAB topologies, avoiding the transmission and processing of multiple protocol messages. For the same reason, there is no need for a fixed node to transfer the control of the IAB node to a new IAB donor and transfer the DUs of the IAB node. Moreover, such a DU transition, which may be called a full transition, also includes the handover of the UEs served by the migrating mobile IAB node.

[0017] 3GPP is considering expanding the coverage area in urban areas by using a new type of vehicle-mounted relay device that functions as an IAB node mounted on vehicles (mobiles) such as buses, trains, and taxis. Hereinafter, such a vehicle-mounted device will be called mobile IAB. Note that mobile IAB or mobile IAB node is also called MBSR (Mobile base Station Relay).

[0018] When using mobile IAB, various problems are likely to arise that cannot be solved by the specifications of cellular communication standards formulated up to Release 17, which were based on the assumption that IAB nodes and fixed base stations would be installed in a fixed location.

[0019] For example, since the mobile IAB is intended to be installed in vehicles, etc., it may have lower processing power compared to conventional fixed IAB donors, due to the need to balance weight and power consumption costs. In addition, the mobile IAB performs backhaul communication with upper IAB nodes and IAB donors while moving around the area. Therefore, compared to communication conditions in which base stations are fixedly installed based on communication demand predictions and communication with UEs is provided, the mobile IAB has the characteristic that communication demand changes dynamically as the mobile IAB moves.

[0020] Urban environments are typically characterized by a high density of users along with the presence of a significant number of vehicles (e.g., public / private passenger transport, goods delivery, food trucks). Some of these vehicles (e.g., buses, trams, trains) may have predictable routes and be accessed by a large number of UEs. 3GPP believes that equipping such vehicles with Vehicle Mounted Base Stations acting as mobile relays can provide an opportunity to increase the network coverage and connectivity to UEs within the vehicle as well as to UEs in close proximity to the vehicle. These mobile IABs use 5G wireless backhaul (usually IAB) for connectivity to fixed donor devices. So, based on the fixed IAB foundation in Releases 16 and 17, 3GPP is now considering mobile IAB systems and architectures as part of the Release 18 framework to address scenarios focused on mobile IAB nodes mounted on vehicles. In such scenarios, the mobile IAB nodes are called Vehicle Mounted Relays and provide 5G coverage / capacity to on-board (in the vehicle) and / or surrounding UEs. For mobile IAB nodes, it is worthwhile to perform multiple MT or DU transitions. This is because the parent IAB node belonging to the initial IAB topology may not reconnect for a long time as the mobile IAB node moves, or may never reconnect if it moves away from the parent IAB node. Furthermore, for flexible IAB network management, it is useful to de-correlate MT and DU transitions. That is, the DU transition of an IAB node may occur independently before or after one or more MT transitions of this IAB node. Furthermore, the DU migration of an IAB node may be performed to an IAB donor different from the IAB donor associated with the MT of this IAB node.

[0021] The MT transition of the mobile IAB (mIAB) corresponds to a handover (HO: HandOver) of the MT function, and the IAB donor determines whether or not to perform the MT transition based on the radio wave strength of the nodes adjacent to the IAB donor.

[0022] However, when the mobile IAB node decides to transition to MT and the connection path between the IAB donor and the mobile IAB node's DU changes, the mobile IAB node has no way to notify the IAB donor to which the DU is connected of the communication status. Therefore, the mobile IAB node takes time to detect the deterioration of the communication status of the connected IAB donor CU, and there is a problem that it cannot switch the path to the appropriate IAB donor CU.

[0023] Each of the embodiments described below is capable of solving the above-mentioned problems, providing a mechanism that enables DU migration according to communication conditions, and also enabling the convenience of cellular communication to be improved.

[0024] <Explanation of Mobile IAB operation based on 3GPP specifications> First, FIG. 1 illustrates a mobile wireless communication system such as a 5G system that includes a wireless integrated access and backhaul network supporting a mobile IAB node of the communication system 100.

[0025] The communication system 100 includes a number of UEs 131, 132, 133, and 134, a core network 110, a primary base station 120, and two integrated access and backhaul (IAB) stations or IAB nodes 121 and 122. The communication system 100 also includes a mobile integrated access and backhaul station (mobile IAB node) 123 mounted on a vehicle 105 (e.g., a bus, a train, a taxi, a car, etc.).

[0026] A primary base station 120, also called IAB donor 120, is connected to the core network 110 via a wired link 101 (e.g., optical fiber or other wired means). In this embodiment, the IAB donor 120 is a 5G base station (gNB) with additional functionality to support IAB functionality, as defined in the 3GPP TS38.300 v 17.2.0 specification. To extend the network coverage of the IAB donor 120 and reach remote UEs 132, 133, and 131, IAB nodes 121 and 122 are installed by the operator. The IAB nodes 121 and 122 act as relay nodes between the IAB donor 120 and the UEs 132 and 133. Thereby, the IAB nodes 121 and 122 reduce reachability issues due to radio propagation and thus the presence of buildings 108 that impede direct connection and further communication between the UEs and the IAB donor 120. This is especially true when the communications between the IAB donor 120 and the UEs 132 and 133 are operating at mmWave frequencies, which are highly sensitive to shadowing phenomena. The IAB donor 120 also serves the UE 134 that is directly connected to it.

[0027] The mobile IAB node 123, also called mobile IAB node, is mounted on the vehicle 105 and provides network coverage and capacity expansion. The radio signal of the IAB donor 120 can reach not only on-board UEs such as remote UE 135, but also surrounding UEs in the vicinity of the IAB node 123, such as UE 136. Thus, the IAB donor 120 and the IAB nodes 121, 122 and 123 form a backhaul network, IAB network or IAB topology, which serves UEs 131-136. The terms IAB network and IAB topology are used interchangeably below. The IAB specifications are specified in several 3GPP standard documents, such as: 1) TS38.300 RAN Architecture (V 17.2.0) 2) TS38.321 MAC Protocol (V 17.2.0) 3) TS38.331 Radio Resource Control (RRC) Protocol (V 17.2.0) 4) TS38.340 Backhaul Adaptation Protocol Layer (V 17.2.0) 5) TS38.401 RAN Architecture (V 17.2.0) 6) TS38.423 Xn Application Protocol (V 17.2.0) 7) TS38.473 F1 Application Protocol (V 17.2.0) The IAB donor 120 and IAB nodes 121, 122, and 123 are connected to the UEs 131-136, respectively, and are therefore considered as the access IAB nodes of the UEs. The IAB donor 120 is a logical node that provides NR-based radio backhaul and is composed of a central unit (CU or gNB-CU functionality) and a donor distributed unit (DU or gNB-DU functionality) connected to the central unit. The IAB donor CU or donor CU (hereinafter also referred to as "IAB donor CU") hosts higher layer protocols such as PDCP and RRC protocols for controlling the operation of one or more DUs. PDCP is an abbreviation for Packet Data Coverage Protocol, and RRC is an abbreviation for Radio Resource Control. Each of the one or more IAB donor DUs includes lower layer protocols such as RLC (Radio Link Control), MAC (Medium Access Control), and physical layer protocols. The IAB donor CU and IAB donor DU may be located remotely from each other or may be in the same physical device. The gNB-DU functionality is defined in 3GPP TS 38.401. The gNB-DU is intended to terminate the NR access interface to the UE and the next-hop IAB node and to terminate the F1 protocol with the IAB donor gNB-CU function as shown in Figures 2A and 2B below. IAB nodes, which may serve multiple radio sectors, are wirelessly backhauled to the IAB donor 120 via one or more hops on one or more intermediate IAB nodes. They form a directed acyclic graph (DAG) topology rooted at the IAB donor 120.

[0028] Each IAB node is also composed of an IAB-DU and an IAB-MT. The gNB-DU function on an IAB node is also called an IAB-DU, and enables downstream (UE direction) connection to the next hop IAB or UE. The IAB-MT function includes, for example, physical layer, layer 2, RRC, and Non Access Strutum (NAS) functions for connecting to the gNB-DU of an upstream IAB node. The upstream IAB node includes an IAB donor 120. The IAB-MT function connects to the IAB donor gNB-CU and also connects to the core network 110 for initialization, registration, configuration, etc. In this DAG topology, the adjacent node on the interface of the IAB-DU is called a child node, and the adjacent node on the interface of the IAB-MT is called a parent node. The direction toward the child node is further called downstream, and the direction toward the parent node is called upstream. The IAB donor 120 (e.g., IAB donor CU) performs centralized management of resources, topology, and routes for the entire IAB topology. This includes, for example, configuring the IAB nodes according to the network topology to perform appropriate routing of data packets.

[0029] 2A and 2B show a schematic of the stack of several protocol layers involved in IAB operation. The F1 interface supports the exchange of signaling information (e.g., control traffic) between the endpoints and data transmission (e.g., user traffic transmission) to each endpoint. From a logical point of view, the F1 interface is a point-to-point interface between the endpoints.

[0030] In 5G, F1-C is the functional interface between IAB donor CU and IAB node DU and between IAB donor CU and IAB donor DU in the control plane (C-Plane). F1-U is the functional interface in the user plane (U-Plane) of the same unit. F1-C and F1-U are shown with reference number 212 in FIG. 2A. In this example, F1-U and F1-C are transmitted over two backhaul hops (from IAB donor to IAB node 1 and from IAB node 1 to IAB node 2).

[0031] In the U-Plane, box 210 of the IAB Donor CU and IAB Node DU refer to the GTP-U layer and box 211 to the UDP layer. GTP-U stands for GPRS Tunneling Protocol User Plane. GTP-U tunnels are used to transport encapsulated PDUs and signaling messages between a specific pair of GTP-U tunnel endpoints (see 3GPP TS29.281 for details). PDU stands for Protocol Data Unit. Box 210 of the IAB Donor CU and IAB Node DU are shown here. User Datagram Protocol (UDP) is a transport layer protocol that provides a best-effort datagram service and is suitable for use with the IP protocol.

[0032] In the C-Plane, box 210 shows the F1-AP (F1 Application Protocol) layer. Also, box 211 shows the SCTP (Stream Control Transmission Protocol) layer. The F1 Application Protocol (defined in 3GPP TS38.473 and TS38.401) provides signaling services between IAB donor CUs and IAB node DUs or UE related services. These services include initialization, configuration, etc., and the SCTP layer provides reliable sequence transfer of messages with congestion control.

[0033] F1-U and F1-C rely on the IP transport layer between IAB Donor CU and IAB Node DU as defined in 3GPP TS 38.401. Also, the transport between IAB Donor DU and IAB Donor CU is realized using IP transport layer over various media such as wire or optical fiber when IAB Donor CU is remote from IAB Donor DU or locally with virtual instantiation of IAB Donor CU and IAB Donor DU on the same physical machine. IAB specific transport between IAB Donor CU and IAB Donor DU is specified in 3GPP TS 38.401.

[0034] L1 and L2 in Figure 2A carry the transport and physical layers, respectively, appropriate for the medium in use. The IP layer can also be used for non-F1 traffic, such as operations, management and maintenance traffic. In wireless backhaul, the IP layer itself is carried over the Backhaul Adaptation Protocol (BAP) sublayer, allowing routing across multiple hops. The BAP sublayer is specified in TS 38.340.

[0035] The IP traffic of the IAB-DU is routed over the wireless backhaul via the BAP sublayer. In the downstream direction, upper layer packets are encapsulated by the BAP sublayer of the IAB donor DU, thus forming a BAP packet, packet data unit (PDU) or data packet. The BAP packets are routed by the BAP layers or entities of the intermediate IAB nodes (and the corresponding BAP entities of the IAB-DU and IAB-MT). The BAP packets are finally decapsulated by the BAP sublayer of the destination IAB node (which could be the access IAB node, if the upper layer packet in the BAP packet is for a UE).

[0036] In the upstream direction, upper layer packets are encapsulated by the BAP sublayer of the originating IAB node (or the access IAB node, if the upper layer packets are sent from the UE). This results in the formation of a BAP packet, data unit (PDU) or data packet. The BAP packet is routed by the BAP layers of the intermediate IAB nodes (and the corresponding BAP entities of the IAB-DU and IAB-MT). The BAP packet is finally decapsulated by the BAP sublayer of the IAB donor DU.

[0037] In the BAP sublayer, packets are routed based on the BAP Routing ID, which is carried in the BAP header of the BAP packet and is set by the BAP sublayer of the originating IAB donor DU or the originating IAB node.

[0038] Figure 2B from 3GPP TS38.300 v 17.2.0 shows the protocol stack for supporting RRC and NAS connection of IAB-MT. NAS protocol handles messages between the core network (CN) and UE or IAB node. For example, NAS protocol manages the establishment of communication sessions and maintains communication with moving IAB nodes or UE. 5G NAS is described in 3GPP TS24.501. 5G Core Access and Mobility Management Function (AMF) is a function in the core network that receives all connection and session related information from UEs connected to IAB nodes and similar information for IAB nodes. AMF is an abbreviation for Access and Mobility Management Function and is only responsible for handling connection and mobility management tasks. IAB-MT establishes signaling radio bearers SRBs (bearers that carry RRC and NAS messages) with IAB donor CU. These SRBs are transferred between IAB-MT and its parent node over NR-Uu interface.

[0039] FIG. 3 shows the format 300 of a BAP Data Protocol Data Unit (PDU) or packet. It is specified in chapter 6.2 of 3GPP TS 38.340 Release 17.2.0. The payload section 307 is a normal IP packet, with the header 30 including fields 301 to 306. Field 301, named the D / C field, is a Boolean value indicating whether the corresponding BAP packet is a BAP data packet or a BAP control packet. Fields 301 to 304 are 1-bit reserved fields, preferably set to 0 (ignored by the receiver). Fields 305 and 306 collectively indicate the BAP routing ID of the BAP packet. The BAP address field 305 (also called the DESTINATION field) is in the leftmost 10 bits, and the BAP path ID field 306 (also called the PATH field) is in the rightmost 10 bits. Field 305 carries the BAP address (on the BAP sublayer) of the destination IAB node or IAB donor DU of the BAP packet. For routing purposes, each IAB node and IAB donor DU in the IAB network is configured with a unique BAP address assigned by the IAB donor CU of the IAB network. Field 306 contains a path ID that identifies the routing path that the BAP packet must follow to this destination in the IAB topology. For routing purposes, the routing path including the path ID is configured by the IAB donor CU of the IAB network at the IAB nodes of the IAB network.

[0040] The BAP header is added to the packet when it arrives at the BAP layer from the higher layers and is removed by the BAP layer when it reaches the destination node. The selection of the BAP routing ID for a packet is configured by the IAB donor CU. For example, the BAP packet is generated by the IAB donor DU for downstream transmission, or by the originator (access IAB node if the higher layer packet is sent from the UE) for upstream transmission. The BAP header with the BAP routing ID is built by the node according to a configuration table defined in 3GPP TS38.340. This table is called the Downlink Traffic to Routing ID Mapping Configuration table of the IAB donor DU, or the Uplink Traffic to Routing ID Mapping Configuration table of the originating IAB node. In the relaying IAB node, the BAP header field is already specified in the BAP packet to be forwarded.

[0041] To transfer messages over the 5G NG wireless medium, three further sublayers (RLC, MAC and PHY) are implemented in each IAB node below the BAP sublayer. The RLC sublayer is responsible for packet segmentation or reassembly. It is also responsible for requesting retransmission of missing packets. The RLC layer is further described in TS 38.322. The MAC protocol sublayer is responsible for selecting the transmission format available for user data and for mapping logical channels to transport channels. The MAC also handles part of the Hybrid Automated Repetition request scheme. The MAC layer is detailed in TS 38.321. On the transmit side, the MAC encapsulates the data packets issued by the RLC and adds a header that carries the information required for the MAC function. On the receive side, the MAC decapsulates the data packets issued by the PHY layer, removes its header and passes the remaining data to the RLC. The PHY layer provides the electrical interface to the transmission medium by converting the stream of information into a physical modulated signal and modulating the carrier frequency at the emitter side. At the receiving end, the PHY layer converts the physical modulated signal into a stream of information. The PHY layer is described in TS38.201, TS38.211, TS38.212, TS38.213, and TS38.214.

[0042] To pass messages to the user or control plane, two sublayers are used in the UE and IAB donor CU: the PDCP sublayer and the Service Data Adaptation Protocol (SDAP) sublayer for U-Plane communication or the RRC sublayer for C-Plane communication.

[0043] The PDCP sublayer is described in 3GPP TS 38.323. The PDCP sublayer handles IP header compression / decompression, encryption / decryption, and data packet integrity if necessary. Packets are forced to be numbered on the sender side and reordered on the receiver side.

[0044] The SDAP sublayer 220 in the U-Plane is described in TS 38.324 and handles Quality of Service. On the UE side, the SDAP sublayer 220 exchanges payload data with user applications (voice, video, etc.). On the IAB donor CU side, the SDAP sublayer exchanges data with the core network 110 (internet traffic, cloud, etc.).

[0045] The C-Plane RRC sublayer 230 is described in TS38.331 and handles the configuration of protocol entities in the user plane protocol stack. In particular, it is responsible for broadcasting the information required for the UE to communicate with the cells. It also handles the sending of paging messages, connection management (bearer configuration, etc.) and mobility functions (measurement configuration and reporting).

[0046] The interface between nodes (both CP and UP) using PDCP, RLC, MAC and PHY layers is referred to as NR-Uu, which is primarily used for interfacing with UE. The interface between nodes (both CP and UP) using BAP, RLC, MAC and PHY layers is referred to as Backhaul RLC Channel, which is primarily used for interfacing with IAB nodes.

[0047] NR-Uu is the interface between the UE and the Radio Access Network (IAB node).

[0048] <Hardware configuration> The hardware configuration 401 of the IAB node 123 will be described with reference to Fig. 4. Fig. 4 is a block diagram for explaining an example of the hardware configuration 401 of the IAB node 123.

[0049] The hardware configuration 401 of the IAB node 123 includes a control unit 402, a storage unit 403, a wireless communication unit 404, an antenna control unit 405, an antenna 406, and an operation unit 407. It is assumed that the antenna 406 is a phased array antenna, but is not limited to this.

[0050] The storage unit 403 is composed of one or more memories such as a ROM (Read Only Memory) and a RAM (Random Access Memory). The storage unit 403 stores computer programs for performing various operations described later, communication parameters for wireless communication, management information of UEs connected to the IAB node, etc. The storage unit 403 also functions as a temporary storage area (work area) for data that the IAB node transfers to each UE via the IAB donor or CN.

[0051] Note that, in addition to memories such as ROM and RAM, storage media such as a hard disk and a non-volatile memory may be used as the storage unit 403. Also, the storage unit 403 may be composed of a plurality of memories.

[0052] The control unit 402 is configured with one or more processors such as a CPU or an MPU, and controls the entire IAB node 123 by executing a computer program deployed in a RAM that is the storage unit 403. The control unit 402 may control the entire IAB node 123 in cooperation with the computer program stored in the storage unit 403 and an OS (Operating System).

[0053] The processes performed by the control unit 402, which will be described in the flowcharts below, are also realized by executing a computer program deployed in the RAM, which is the storage unit 403. The processes described in the flowcharts below can also be realized using a hardware circuit such as an ASIC (Application Specific Integrated Circuit) or an FPGA. The processes described in the flowcharts below can also be realized by having the hardware circuit cooperate with a processor such as a CPU or an MPU.

[0054] The wireless communication unit 404 is a module that cooperates with the control unit 402, the antenna control unit 405, and the antenna 406 to transmit and receive cellular communications such as LTE (Long Term Evolution) and 5G NR that comply with the 3GPP standard. Note that, in the present embodiment, the communication unit 404 supports wireless communications that comply with LTE and 5G NR, but is not limited thereto. For example, the wireless communication unit 404 may support wireless communications that comply with 6G and Beyond 5G, which are successor standards to 5G NR. In addition, the wireless communication unit 404 has a measurement function that measures communication conditions with each UE and each base station.

[0055] The antenna control unit 405 controls the directivity of the antenna 406, and uses techniques such as beamforming and MIMO to transmit radio signals generated by the wireless communication unit 404 to the UE, and receives radio signals transmitted from the UE and passes them on to the wireless communication unit 404.

[0056] The operation unit 407 includes a touch panel capable of detecting a user's touch operation and a display panel for displaying various screens. The operation unit 407 functions as a display unit for displaying information and a reception unit for receiving user instructions. The control unit 402 cooperates with the operation unit 407 to display a setting screen for performing various settings of the IAB node. In addition, the user can input a desired operation instruction to the IAB node 123 by performing a touch operation on the operation unit 407 using an object such as a finger. The display unit may be an external display device separate from the hardware configuration 401 of the IAB node 123, and the reception unit may be an input device such as a keyboard or a mouse.

[0057] The hardware configurations of the IAB donor 120 and the IAB nodes 121 and 122 are similar to that of the IAB node 123, and therefore will not be described. As described in FIG. 2A, the IAB donor 120 is composed of an IAB donor DU and an IAB donor CU. The IAB donor DU and the IAB donor CU may be realized by separate hardware. In this case, the IAB donor DU and the IAB donor CU, which are separate hardware, may be communicatively connected via a network such as optical fiber. In this case, the connection method between the DU and the CU is not limited to this.

[0058] FIG. 4A is a block diagram illustrating an example configuration of software functionality 450 of a mobile IAB node (see mobile IAB node 570 in FIG. 5).

[0059] Software function 450 of the mobile IAB node includes a signal transmitting unit 451, a signal receiving unit 452, a data storage unit 453, a connection control unit 454, and a transition determination processing unit 455. Software function 450 also includes a transition request unit 456, a communication status collecting unit 457, a load information request unit 458, and a transition destination information notifying unit 459. The functions of each block shown in Fig. 4A can be realized by control unit 402 executing a control program stored in storage unit 403 in the hardware configuration shown in Fig. 4.

[0060] The signal transmission unit 451 and the signal reception unit 452 control the wireless communication unit 404 to transmit and receive wireless signals between the IAB donor or other IAB nodes and the UE. The signal transmission unit 451 and the signal reception unit 452 transmit and receive wireless signals that comply with a 3GPP standard such as the LTE standard or the 5G standard.

[0061] In this embodiment, the signal receiving unit 452 receives a handover request for the MT function unit from the connected IAB donor CU in a situation where the mobile IAB node is connected to the IAB donor CU.

[0062] The data storage unit 453 stores various programs and various data (various information) in the storage unit 403 to hold them.

[0063] The connection control unit 454 performs processing related to the connection of the IAB network, such as transmitting and receiving Radio Resource Control (RRC) messages with the IAB donor CU.

[0064] The transition determination processing unit 455 performs transition determination processing of the DU function unit based on the communication status. The DU function unit is controlled and set by the IAB donor using the F1-AP message defined in 3GPP TS38.473. The communication status may be, for example, the communication status related to the own station. In this embodiment, the communication status is determined based on various information (described later) collected and acquired by the communication status collecting unit 457 and the load information requesting unit 458 described later. In addition, in a modified example, the communication status may be determined based on information (described later) obtained through either one of the communication status collecting unit 457 and the load information requesting unit 458 described later. The transition determination processing of the DU function unit by the transition determination processing unit 455 includes a determination processing of whether or not to transition the DU function unit. The transition determination processing of the DU function unit by the transition determination processing unit 455 may include a process of determining a transition destination of the DU function unit in addition to a process of determining whether or not to transition the DU function unit.

[0065] The determination process by the transition determination processing unit 455 may be triggered by the reception of a handover request (a handover request of the MT function unit from the connected IAB donor CU) by the signal receiving unit 452. Further details of the determination process by the transition determination processing unit 455 will be described later.

[0066] The transition request unit 456 makes a transition request for the DU function unit when the transition determination processing unit 455 determines that the DU function unit is to be transitioned under a specific situation. The specific situation corresponds to a situation in which the IAB donor to which the MT function unit is connected is different from the IAB donor to which the DU function unit is connected. That is, it corresponds to a situation in which the IAB donor to which the RRC connection is established is different from the IAB donor to which the F1 interface is established. The transition request unit 456 may transmit a transition request for the DU function unit (an example of notification information) to the IAB donor CU to which the DU function unit is connected (F1 termination donor CU 604 in FIG. 6 described later). At this time, the transition request for the DU function unit may include information indicating the transition destination of the DU function unit. In another embodiment, the notification destination of the transition request may include other IAB donor CUs (for example, donor CU 605 in FIG. 6 described later) in addition to the IAB donor CU to which the DU function unit is connected (F1 termination donor CU 604 in FIG. 6 described later). Further details of the transition request are provided below.

[0067] The communication status collecting unit 457 collects communication status information including at least one of a delay time related to communication with a connected IAB donor CU and a network slice type requested by a UE accessing the own device. The delay time may be a value calculated based on a Ping value or an MT transition number. The network slice type is a type such as low latency (URLLC), high speed and large capacity (eMBB), and multiple simultaneous connections (MIoT). URLLC is an abbreviation for Ultra-Reliable and Low Latency Communications, and MIoT is an abbreviation for Massive Internet of Things. Also, eMBB is an abbreviation for enhanced Mobile BroadBand. Further details of the communication status information will be described later.

[0068] The load information request unit 458 requests the load information of the connected IAB donor CU from the connected IAB donor CU. The load information may include free buffer capacity, the number of connected UEs, etc. In addition to the load information of the connected IAB donor CU, the load information request unit 458 may request load information of other IAB donor CUs adjacent to the connected IAB donor CU.

[0069] The load information request may be performed using an RRC message. In this case, the RRC Reconfiguration and RRC Setup message formats defined in section 6.2.2 of TS38.331 may be used. In this case, a "donor CU load information request" field is added to a reserved field "nonCriticalExtension" in the format. Further details of the load information will be described later.

[0070] When performing migration of the DU function unit in response to the migration request described above, the migration destination information notification unit 459 notifies the connected (FI connected) IAB donor CU of the identifier of the migration destination IAB donor CU. Such notification may be realized by using an F1-AP message. In this case, for example, the F1 message gNB-DU CONFIGURATION UPDATE specified in TS38.473 V 17.2.0 section 9.2.1.7 may be used. This allows the connected IAB donor CU to obtain the identifier of the migration destination IAB donor CU. Further details of the identifier of the migration destination IAB donor CU will be described later.

[0071] <Example of operation premised on the first embodiment> FIG. 5 illustrates an example of an IAB communication system (or IAB network system) 500 in which the present embodiment can be implemented. In an example implementation, the wireless links (BH wireless links) between the IAB nodes and between the IAB nodes and the IAB donor DUs operate in the millimeter wave frequency band (above 30 GHz), which is highly sensitive to wireless channel disturbances. The IAB network is also called an IAB topology or topology, so the terms IAB network and IAB topology are used interchangeably in the present embodiment. The IAB communication system 500 is composed of three IAB topologies 5001, 5002, 5003. Each of the IAB topologies 5001, 5002, 5003 is composed of multiple IAB nodes and an IAB donor CU for controlling or managing the multiple IAB nodes. As the multiple IAB nodes, for example, a set of IAB nodes can include multiple IAB nodes or at least one IAB node. The set of IAB nodes can include one or more IAB nodes, such as an originating IAB node that generates a BAP packet and an intermediate IAB node. Each IAB node communicates with at least one other IAB node via a wireless backhaul (BH) link. Although FIG. 5 shows three IAB topologies 5001, 5002, and 5003, the present embodiment is not limited to three IAB topologies. That is, the IAB communication system may be implemented in two or more IAB topologies, each of which includes a set of IAB nodes and an IAB donor CU as described above. As described above, each IAB node includes an MT function and a DU function. The MT function is controlled and configured by the IAB donor using RRC messages defined in 3GPP TS38.331. For example, the IAB node 510 includes an MT 511 and a DU unit 512.

[0072] The IAB topology 5001 includes an IAB donor CU 501 (denoted as Donor CU1 in FIG. 5) and an associated IAB donor DU 504 (denoted as Donor DU1 in FIG. 5). The IAB topology 5001 also includes multiple IAB nodes 510 and 520.

[0073] The IAB topology 5002 includes an IAB donor CU 502 (denoted as Donor CU2 in FIG. 5) and its associated IAB donor DU. The IAB topology 5002 also includes an IAB donor DU 505 (denoted as Donor DU21 in FIG. 5) and an IAB donor DU 506 (denoted as Donor DU22 in FIG. 5). The IAB topology 5002 also includes multiple IAB nodes 530, 540, 550, and an IAB node 570. All the IAB nodes can be access nodes serving UEs, such as a UE 580 served by a mobile IAB node 570. The IAB topology 5002 is transparent to a UE 580 that connects to the donor CU 502 via a DU function 572 of the mobile IAB node 570. Although only one UE 580 is shown in FIG. 5, multiple UEs are connected to the network nodes of the IAB communication system 500.

[0074] The IAB topology 5003 includes an IAB donor CU 503 (denoted as Donor CU3 in FIG. 5), its associated IAB donor DU 507 (denoted as Donor DU3 in FIG. 5), and an IAB node 560.

[0075] The wired backhaul IP network interconnects the IAB donor CUs 501 to 503 and the IAB donor DUs 504 to 507 via a wired backhaul 508. For example, the wired backhaul 508 is configured with an optical fiber cable.

[0076] IAB donor CU 501, IAB donor DU 504, and IAB nodes 510 and 520 are part of the IAB topology 5001, and are configured and managed or controlled by IAB donor CU 501.

[0077] The IAB donor CU 502 , the IAB donor DUs 505 and 506 , and the IAB nodes 530 , 540 , 550 are part of the same IAB network or IAB topology 5002 , which is configured and managed or controlled by the IAB donor CU 502 .

[0078] The IAB donor CU 503 , the IAB donor DU 507 , and the IAB node 560 are part of the same IAB topology 5003 , which is configured and managed or controlled by the IAB donor CU 503 .

[0079] Each IAB node DU and IAB donor DU supports wireless communication in a coverage area called a cell. That is, each IAB node DU and IAB donor DU is associated with a cell. Wireless communication devices located in a cell may be UEs or other IAB nodes. Wireless communication devices in a cell may establish a communication link with a node serving the cell to communicate with other devices (e.g., other UEs, IAB nodes, servers providing access to the Internet, etc.) via the node. The node serving the cell may be, for example, an IAB node DU or an IAB donor DU.

[0080] Assume that the mobile IAB node 570 initially has a single parent IAB node 520, and the IAB node 570 belongs to an IAB topology 5001 controlled by an IAB donor CU 501. In this case, the IAB donor CU 501 operates as an F1 terminating donor CU (also called an F1 terminating IAB donor CU or an F1 donor CU). When the mobile IAB node 570 moves, in consideration of the proximity to the IAB topology 5002, the mobile IAB node 570 may be able to establish a wireless BH link with the IAB node 530. For example, when the mobile IAB node 570 is in a position shown by the dotted line in FIG. 5, the mobile IAB node 570 may be able to establish a wireless BH link with the IAB node 530. Such a BH link is possible for a stationary IAB node, and for a mobile IAB node such as the IAB node 570, it is highly likely to move, for example, in the direction of the IAB topology 5003 (as indicated by the arrows 590, 591 in FIG. 5).

[0081] Next, the F1 donor CU 501 decides to migrate the MT function unit 571 of the IAB node 570 toward the IAB topology controlled by the IAB donor CU 502, which has become the non-F1 terminating donor CU of the IAB node 570. That is, the MT function unit 571 of the IAB node 570 is migrated toward the parent IAB node 530. At this time, the IAB donor CU 502 is a non-F1 terminating donor CU, and is also called a non-F1 terminating IAB donor CU or a non-F1 donor CU. For this purpose, the F1 donor CU 501 initiates an IAB donor CU inter-topology adaptation procedure. The IAB donor CU inter-topology adaptation procedure is described in TS38.401 V 17.2.0 section 8.17.3.1 or section 8.17.3.2 (when the IAB node 570 has a descendant IAB node). As a result, the IAB node 570 still belongs to the IAB topology 5001 and continues to establish an F1 connection with the donor CU 501, but the RRC connection switches from the donor CU 501 to the donor CU 502. The IAB donor CU 501 may then request migration of backhaul traffic (e.g., user traffic, control traffic) related to the IAB node 570 to the IAB topology 5002. This request is made via the IAB donor DU 505. In this case, the IAB donor CU 501 triggers the IAB transport transition management procedure as specified in TS38.423 V 17.2.0 section 8.5.2. In an IAB communication system, all traffic communicated on the backhaul link uses the F1 interface (F1-C or F1-U) between the IAB donor CU and the IAB node DU. Thus, the offloaded or migrated traffic or backhaul traffic is F1 traffic, which may include control traffic and user traffic.

[0082] While the mobile IAB node 570 is still moving in the direction indicated by the arrow 590, the MT functionality 571 of the IAB node 570 is transitioned by the non-F1 donor CU 502 towards the parent IAB node 550. In this case, the backhaul link 5050 between the IAB node 550 and the IAB node 570 is used. For this purpose, the non-F1 donor CU 502 applies the intra-CU topology adaptation procedure described in TS38.401 V 17.2.0 section 8.2.3.1 (or section 8.17.3.2). As a result, a successive MT transition of the IAB node 570 with a new single parent IAB node 550 (or another MT transition to another IAB node) occurs. Nevertheless, the IAB node 570 continues its F1 connection with the IAB donor CU 501 and its RRC connection with the IAB donor CU 502.

[0083] After being notified to route F1 traffic related to the IAB node 570 using the IAB donor DU 506 instead of the IAB donor DU 505, the IAB donor CU 501 may act as follows: the IAB donor CU 501 may request the IAB node 570 to transition the traffic related to the IAB node 570 to the IAB topology 5002. In this case, the IAB donor CU 501 triggers the IAB transport transition management procedure specified in TS 38.423 V 17.2.0 section 8.5.2. The IAB node 570 may then move further in the direction towards the IAB topology 5003 controlled by the AB donor CU 503. In this case, the IAB node 570 may reach a position where the backhaul link 5060 with the IAB node 560 may be of better quality than the backhaul link 5050 with the IAB node 550. Once in this position, the IAB donor CU 502 can apply the inter-CU topology adaptation procedure described in TS 38.401 V 17.2.0 section 8.17.3.1 or 8.17.3.2. After this successive MT transition, the DU function 572 of the IAB node 570 still belongs to the IAB topology 5001 and has an F1 connection with the IAB donor CU 501. On the other hand, the RRC connection is now with the IAB donor CU 503, so that the IAB donor CU 503 becomes a non-F1 terminating donor CU. However, the IAB donor CU 501 is informed of the new non-F1 donor CU 503 for the IAB node 570 and the new IAB donor DU 507. This is to redirect the offloaded traffic via the IAB donor DU 507 instead of the IAB donor DU 506. The offloaded traffic can be, for example, F1 traffic, control, and user traffic.

[0084] In all the above MT transition cases, the UE 580 remains connected to the IAB donor CU 501 via the DU function 572 of the mobile IAB node 570. If the IAB node 570 has some child IAB nodes, such child IAB nodes still belong to the IAB topology 5001. In this case, they are fully controlled (via F1 and RRC connections) by the IAB donor CU 501. Therefore, at any state of transition of the MT function 571 of the IAB node 570, the F1 donor CU 501 can decide to perform transition of the DU function 572 of the IAB node 570. This decision can be performed regardless of whether the MT function 571 of the IAB node 570 has transitioned to the IAB topology 5002 or the IAB topology 5003.

[0085] The reason for performing DU migration is to reduce the processing load on the F1 donor CU 501. Or, the IAB node 570 is geographically far away from the F1 donor CU 501 and approaches an area where there is no Xn connection (connection through the Xn interface) between the F1 donor CU 501 and the target donor CU. After deciding to perform DU migration of the IAB node 570, the F1 donor CU 501 also needs to determine a donor CU (called a target F1 donor CU) to perform DU migration.

[0086] In this case, since there is a non-F1 terminating donor CU, the non-F1 terminating donor CU becomes the target F1 donor CU. Alternatively, there may be a case where the DU migration is not to the current non-F1 terminating donor CU (i.e., the default selection) but to another target F1 donor CU. For example, assume that the IAB node 570 is mobile and its trajectory is predictable (e.g., in the case of a bus or train). In this case, the F1 donor CU 501 may recognize a suitable target F1 donor CU that controls the cell where the IAB node 570 will soon connect to the network. Specifically, the non-F1 terminating donor CU of the IAB node 570 is the donor CU 502, but the IAB node 570 may pass through the IAB topology 5002 controlled by the donor CU 502 quickly and not remain. For this reason, the F1 donor CU may decide that the DU migration of the IAB node 570 should be directly directed to the donor CU 503. Not performing DU transition to donor CU 502 and performing DU transition to donor CU 503 instead avoids intermediate DU transition protocol messages in IAB node 570. During DU transition, handover of the UE served by IAB node 570 must also be performed at the same time. Therefore, not performing DU transition to donor CU 502 also avoids intermediate handover of the UE to donor UE 502 before the new DU transition and handover of the UE to donor CU 503.

[0087] <First embodiment: DU transition decision of mobile IAB node> FIG. 6 shows an example sequence of some message flows according to the present embodiment when performing successive MT migration of an IAB node toward a target IAB topology, including the establishment of a control data path. The successive migration of an MT may include migration of an MT between different parent IAB nodes managed by different IAB donor CUs different from the IAB donor CU serving the DU of the IAB node. Note that in FIG. 6 (and subsequent similar figures), an IAB node may be denoted as "mIAB".

[0088] Figure 6 shows an IAB node 601, which may be a mobile IAB node such as IAB node 570 of Figure 5. The IAB node 601 includes an MT function 603 (hereinafter referred to as mIAB-MT 603) and a DU function 602 (hereinafter referred to as mIAB-DU 602).

[0089] In FIG. 6, the source non-F1 terminated donor CU 605 terminates the RRC connection to the IAB node 601 via the mIAB-MT 603, and the F1 terminated donor CU 604 terminates the F1 connection to the IAB node 601 via the mIAB-DU 602. This sequence procedure shows that the target non-F1 donor CU 606 becomes the new non-F1 terminated donor CU of the IAB node 601. As an example, the correspondence with the IAB communication system in FIG. 5 is as follows. The F1 terminated donor CU 604 of the IAB node is the donor CU 501. The MT function unit 571 of the IAB node 570 has migrated to the IAB topology 5002 managed by the donor CU 502, so the source non-F1 terminated donor CU 605 becomes the donor CU 502. When the IAB node moves towards the IAB topology 5003, the IAB node 560 is identified as the target IAB node to which the MT of the mobile IAB node 570 can be migrated. Therefore, the target non-F1 terminated donor CU606 becomes donor CU503.

[0090] In the sequence 600, the control path (F1-C) and the user path (F1-U) are assumed to use one or more backhaul paths through an IAB topology controlled by a source non-F1 donor CU 605. In this case, the control path (F1-C) and the user path (F1-U) are initially set by the F1 donor CU 604 to connect to an IAB node 601. The assumed IAB topology is also controlled by the source non-F1 donor CU 605 via a donor DU not shown in FIG. 6. For example, referring to FIG. 5, one such backhaul path may include the donor CU 506 and the IAB nodes 540 and 550.

[0091] The first part of the sequence describes the procedure 20010 of transitioning the mIAB-MT 603 from the source non-F1 donor CU 605 to the target non-F1 donor CU 606 and setting up a new path for the RRC protocol messages.

[0092] Assume that the non-F1 donor CU 605, having received the measurement report S611 from the IAB node 601, starts a continuous MT migration of the IAB node 601 to another IAB topology. In the example shown in Fig. 5, this corresponds to the case where the MT function unit 571 of the mobile IAB node 570 is migrated from the parent IAB node 550 of the IAB topology 5002 to a new parent IAB node 560 of a different IAB topology 5003.

[0093] The measurement report S611 is received by the non-F1 donor CU 605 via the UL RRC MESSAGE TRANSFER (specified in TS38.423) of the F1 message. This F1 message is sent from the parent IAB node of the IAB node 601 (e.g. parent IAB node 550 in FIG. 5). The RRC message embeds the measurement report sent from the mIAB-MT 603 to the DU part of the parent IAB node. The measurement report is the result of measurements on signals received from one or more target cells, such as signal synchronization blocks (SSBs, Synchronization Signal Blocks) transmitted in the serving and target cells. The measurements are performed periodically by the mIAB-MT 603. The target cells can be serving cells or neighbor cells of the source cell (current serving cell). The measurement report is generated / sent when the IAB-MT 603 detects at least one SSB that meets a predefined criterion (e.g. received power above a predefined threshold). In this case, radio link quality information of different cells in the vicinity of the IAB node 601 can be provided. The identity of each cell is included in the measurement report, allowing the non-F1 donor CU 605 to identify the target donor CU associated with the cell. The identity of the donor CU can be deduced from the physical cell identity broadcasted in each cell and the new radio cell global identity managed by this donor CU and also broadcasted in each cell. In this case, the physical cell identity is the PCI (Physical Cell Identity) and the radio cell global identity is the NCGI (New Radio Cell Global Identity). The NCGI is broadcasted in a System Information Block (SIB) message. The PCI or NCGI may be reported by the IAB node 601 in the measurement report 611.

[0094] Based on the received measurement report, the non-F1 donor CU 605 may detect that the IAB node 601 receives a radio signal at a target cell of the target parent IAB node with better quality than the source serving cell. Assume that the source parent IAB node is a target parent IAB node (e.g., IAB node 560 in FIG. 5) that belongs to another IAB topology. In this case, the source non-F1 donor CU 605 may decide to apply an inter-CU topology adaptation procedure to the IAB node 601. The target parent IAB node of the target IAB topology includes a new donor DU to route packets. The target parent IAB node may be an IAB node or an IAB donor DU.

[0095] The transition of the mIAB-MT 603 is triggered by a handover request acknowledgement (S612) as described in TS38.423 V 17.2.0 section 8.2.1. The source non-F1 donor CU 605 sends a HANDOVER REQUEST message to the target non-F1 donor CU 606 containing the necessary information related to the mIAB-MT 603 so that the handover can be performed (S612). For example, the message contains the identification of the target cell to which the IAB node 601 switches, and thus identifies the target parent IAB node that controls the target cell. After requesting the target parent IAB node to perform a UE context setup for the IAB node 601, the target non-F1 donor CU 606 performs admission control. Then, the target non-F1 donor CU 606 provides the new RRC configuration information to the source non-F1 donor CU 605 with a HANDOVER REQUEST ACKNOWLEDGE message.

[0096] Next, the source non-F1 donor CU 605 can relay RRC configuration information to the mIAB-MT 603 via an RRC reconfiguration message (S613). Specifically, the RRC configuration information is first embedded in the UE CONTEXT MODIFICATION REQUEST of the F1 message specified in TS38.473 and sent by the non-F1 donor CU 605 to the parent IAB node of the IAB node 601. Next, this parent IAB node sends an RRC reconfiguration message to the mIAB-MT 603 (S613). The RRC reconfiguration message contains address information such as the identification address (i.e., IP address) of the target donor DU for packet routing.

[0097] <Migration Decision Process of IAB Node DU Function Unit> Here, a method for determining whether to migrate the source IAB donor CU of the DU function unit 602 is described, triggered by the fact that the proposed mobile IAB node 601 requests a handover of the MT function unit 603.

[0098] The mobile IAB node 601 that has received the migration (handover) request S613 from the source non-F1 donor CU 605 operates as follows. That is, the mobile IAB node 601 calculates the delay time based on, for example, the Ping value or the number of MT migrations (hop count) with respect to the F1 donor CU 604 that has established an F1 interface with the DU function unit 602 (S614). Next, the mobile IAB node 601 requests the F1 donor CU 604 and the non-F1 donor CU 605 to provide the load information of the donor CUs (S615). Here, the flowchart of the information collection process of the donor CU that has received the request is shown in FIG. 9. S901 indicates that the same mobile IAB node 601 as in S615 has received a request for load information.

[0099] The non-F1 donor CU 605 that receives a load information request from the mobile IAB node 601 measures / collects its own free buffer capacity, the number of connected UEs, and the like (S902). The non-F1 donor CU 605 also requests adjacent donor CUs to provide the same load information as that of the non-F1 donor CU (S616, S903). In response to this request, the adjacent donor CU may provide the load information to the non-F1 donor CU 605 if possible (S617). If the non-F1 donor CU 605 receives load information from an adjacent donor CU (S903), the non-F1 donor CU 605 transmits its own load information and the received load information of the adjacent donor to the requesting mobile IAB node 601 (S618, S905). If no load information is received from an adjacent donor CU, the non-F1 donor CU 605 provides only its own load information to the mobile IAB node 601 (S906). Here, the operation of the non-F1 donor CU 605 that has received a request to provide load information has been described, but the F1 donor CU 604 that has received a request to provide load information may be the same. In addition, here, the mobile IAB node 601 is essentially requesting the donor CU (target non-F1 donor CU 606) adjacent to the non-F1 donor CU 605 to provide load information via the non-F1 donor CU 605 (S616). However, the mobile IAB node 601 may directly request the donor CU (target non-F1 donor CU 606) adjacent to the non-F1 donor CU 605 to provide load information.

[0100] Thereafter, the mobile IAB node 601 judges whether or not to migrate the originating IAB donor CU, which is the parent node of the DU function unit 602, according to a flowchart described later (S619). If it is judged that the originating IAB donor CU should be migrated, it notifies the connected IAB donor CU (in this example, the F1 donor CU 604 in an F1 connection) of a DU migration request (migration request) (S620). Also, in S619, a parent node to which the mIAB-DU 602 will migrate may be selected, and in this case, the destination IAB donor CU (in this example, the target non-F1 donor CU 606) may be notified in S620.

[0101] Fig. 7 shows a flowchart in which the mobile IAB node 601 determines whether to migrate the connecting IAB donor CU that is the parent node of the DU function unit 602. Fig. 7 shows a case in which a network slice is requested from a UE accessing the mobile IAB node 601. Fig. 8 shows a case in which there is no network slice request from the UE, but since the control method is the same as Fig. 7 except for the determination of the network slice type, the description of Fig. 8 is omitted.

[0102] First, the mobile IAB node 601 calculates the delay time from the F1 donor CU 604 that has established an F1 interface with the DU function unit 602 to grasp the communication status of the own station based on the Ping value or the number of MT transitions (S701). Next, it receives the load information of the donor CU that was requested from the non-F1 donor CU 605 (S702). In S703, it is determined whether the network slice type requested from the UE is low latency. If it is low latency, it is determined whether the delay time measured by the mobile IAB node 601 exceeds a threshold (for example, 10 ms or less) (S704). If the delay time exceeds the threshold, it is determined to transition the DU function unit 602 from the connected F1 donor CU 604 (S705). This is because hopping through multiple IAB donors, such as successive MT transitions, is considered to be one of the factors that increase the delay. At this time, the mobile IAB node 601 may determine that the mIAB-DU 602 is to be migrated to the target non-F1 donor CU 606 to which the mIAB-MT 603 is scheduled to be migrated. If the delay time does not exceed the threshold in S704, it is determined that the mIAB-DU 602 is not to be migrated (S711). If the network slice type requested by the UE is not low delay in S703, it is determined whether it is high speed and large capacity (S707). If it is high speed and large capacity, it is confirmed whether the buffer free capacity of the target non-F1 donor CU 606 is equal to or greater than a threshold (for example, 100 MB) (S708). Then, if the buffer free capacity is equal to or greater than the threshold, it is determined that the mIAB-DU 602 is to be migrated from the connected F1 donor CU 604 (S705). At this time, it may be determined that the mIAB-DU 602 is to be migrated to a target non-F1 donor CU 606 with a buffer with room to spare. On the other hand, if the free buffer capacity of the target non-F1 donor CU 606 is not equal to or greater than the threshold in S708, it is determined that the mIAB-DU 602 will not be migrated (S711).

[0103] If the network slice type requested by the UE in S707 is not high speed and large capacity, it is determined whether the network slice type is simultaneous multiple connections (S709). If it is not simultaneous multiple connections in S709, it is determined to migrate mIAB-DU602 from the currently connected F1 donor CU604 (S705). If it is simultaneous multiple connections, it is confirmed whether the number of connected UEs is less than a threshold (for example, 1000 UE) (S710). Then, if the number of connected UEs is less than the threshold, it is determined to migrate mIAB-DU602 from the currently connected F1 donor CU604 (S705). At this time, the mobile IAB node 601 may determine to migrate mIAB-DU602 to a target non-F1 donor CU606 with a smaller number of connected UEs. On the other hand, if the number of connected UEs is not less than the threshold in S710, it is determined not to migrate mIAB-DU602 (S711).

[0104] In addition, the sequence of the transition procedure when miAB-DU 602 transitions to target non-F1 donor CU 606 may be as follows: IAB node 601 performs a random access procedure to a target parent IAB node (e.g., IAB node 560 in FIG. 5). Then, IAB node 601 sends an RRC reconfiguration complete message (S621) to target non-F1 donor CU 606 (S621). The RRC reconfiguration complete message is sent via an F1 message UL RRC MESSAGE TRANSFER embedding RRC Reconfiguration Complete to the target parent IAB node.

[0105] The procedure S640 ends via an Xn message UE CONTEXT RELEASE (S622) specified in TS38.423 sent from the target non-F1 donor CU 606 to the source non-F1 donor CU 605. However, the identifiers of the F1 donor CU 604 and the IAB node 601 are retained by the source non-F1 donor CU 605. Also, the F1 path of the IAB node 601 remains available through the IAB topology controlled by the source non-F1 donor CU 605.

[0106] Steps S640 and S650 relate to procedures for updating the F1 paths (F1-C and F1-U) between the IAB node 601 and the F1 donor CU 604 via the target donor DU in the IAB topology controlled by the target non-F1 donor CU 606. The outline of the operation of step S650 is that the source non-F1 donor CU 605 changes the path setting of the F1 user plane transport to the target non-F1 donor CU 606. This process is a series of path switching procedures triggered by the mIAB-MT handover request / confirmation of S612.

[0107] The target non-F1 donor CU 606 sets up a BH RLC channel and a BAP layer routing entry on the target path between the target parent IAB node and the target IAB donor DU of the IAB node 601. In the example shown in Fig. 5, the target parent IAB node corresponds to the IAB node 560 and the target IAB donor DU corresponds to the IAB donor DU 507. The target non-F1 donor CU 606 can establish additional BH RLC channel and BAP configuration for the transitioning IAB-MT via an RRC message (S623).

[0108] Next, the DU unit (mIAB-DU 602) of the IAB node 601 transmits a DU configuration message (S624) to the F1 donor CU 604. This message may be the F1 message gNB-DU CONFIGURATION UPDATE as described above. This message includes the identifier of the target non-F1 donor CU 606 and the identifiers of the target donor DUs of the F1-C and F1-U traffic. This allows the F1 donor CU 604 to obtain the identifier of the target non-F1 donor CU 606. That is, the PCI or NCGI of the target cell managed by the target non-F1 donor CU 606 is reported from the IAB node 601 to the F1 donor CU 604. The address of the target donor DU, such as the IP address, is recognized by the IAB node 601 after receiving the message (S613). The destination address of the message (S624) is the F1 donor CU 604. When the target donor DU receives this IP packet in the IAB topology controlled by the target non-FI donor CU 606, it can route the IP packet over a wired backhaul to the F1 donor CU 604. Upon receiving the identifier of the target donor DU, the F1 donor CU 604 can update its configuration to deliver the F1 packet to the IAB node 601 via the target donor DU in the IAB topology 5003. For example, the F1 donor CU 604 can update the routing path associated with the IAB node based on the received information. The path in the F1 control data (F1-C) is then updated.

[0109] Here, as an alternative option to informing the F1 donor CU 604 about the identifier of the target non-F1 donor CU 606 in S620, the following method may be used: the source non-F1 donor CU 605 may execute a procedure represented by Configuration Update (message in S628) and Configuration Update Response (message S in S630). In this case, similar information may be provided. The message (S628) sent by the source non-F1 donor CU 605 may include the identifier of the target non-F1 donor CU 606, and the message (S630) may be an acknowledgement from the F1 donor CU 604. The identifier of the donor CU is specified in TS38.423 V 17.2.0 section 9.2.2.3 with the information element Global NG-RAN Node ID.

[0110] In one example, the message (S628) may be an IAB TRANSPORT MIGRATION MODIFICATION REQUEST message, and the message (S630) may be an IAB TRANSPORT MIGRATION MODIFICATION RESPONSE message, both of which are messages used in the IAB Transport Migration Modification procedure specified in TS38.423 V 17.2.0 (Xn protocol) chapters 9.1.4.4 and 9.1.4.5. Using this procedure, the source non-F1 donor CU 605 can notify the F1 donor CU 604 to release the traffic offloaded through the IAB topology controlled by the source non-F1 donor CU 605.

[0111] In another example, the message at S628 may be an NG-RAN NODE CONFIGURATION UPDATE message. Also, the message at S630 may be an NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE. Both are specified in TS38.423 V 17.2.0 (Xn protocol) Chapters 9.1.3.4 and 9.1.3.5, and are messages used in the NG-RAN node configuration update procedure. This message has the following characteristics to enable the F1 donor CU 604 to identify the transitioning IAB node 601 associated with the received message. That is, the message indicates that the IAB node has transitioned from the IAB topology managed by the source non-donor CU 605 to the target IAB topology managed by the target non-F1 donor CU 606 (new non-F1 donor CU). Also, the message uses one or more new paths for the routing data of the transitioning IAB node through the topology of the target non-F1 donor CU 606. The messages sent to the F1 donor CU 605 include the identifiers of the transitioning IAB nodes associated with each of the non-F1 donor CU controlled IAB topologies. For example, in these procedures (NG-RAN Node Configuration Update, IAB Transport Transition Change), the identifier of the IAB node 601 is present in all messages with information elements: F1-Terminating IAB-donor UE XnAP ID and non-F1-Terminating IAB-donor UE XnAP ID. Both are defined upon the first MT transition of the IAB node 601 to the first non-F1 donor CU controlled IAB topology (F1 donor CU 604 and source non-F1 donor CU 605). Upon the subsequent MT transition of the IAB node 601 to the second non-F1 donor CU controlled IAB topology (target IAB topology), the target non-F1 donor CU 606 assigns the identifiers to the IAB node 601. This is shared with the source non-F1 donor CU 605 in a HANDOVER REQUEST ACKNOWLEDGE message containing the target NG-RAN node UE XnAP ID information element.

[0112] According to the present embodiment described above, when the mobile IAB node decides to perform MT migration and the communication conditions deteriorate due to a change in the connection path between the IAB donor and the DU of the mobile IAB node, a DU migration request can be notified. As a result, the path switching to the appropriate IAB donor CU is possible.

[0113] <Second embodiment> In the first embodiment, the mobile IAB node 601 determines whether to transition the IAB donor CU from which the DU function unit 602 is connected, using as a trigger a request for handover of the MT function unit 603. In contrast, in the present embodiment, regardless of the handover request of the MT function unit 603, the transition of the DU function unit 602 is determined using speed information of the mobile IAB node 601 as a trigger.

[0114] For example, in the sequence of Fig. 6, if there is no operation up to the handover request of the MT function unit 603 in S613, the DU function unit 602 may be determined to transition using the speed information of the mobile IAB node 601 as a trigger as follows. That is, the mobile IAB node 601 may constantly measure its own moving speed, and when the moving speed drops below a certain value (for example, 10 km / h), the MT function unit 603 of the mobile IAB node 601 determines that the parent node will not be switched for a certain period of time. Then, it determines that the DU function unit 602 will transition from the connected non-F1 donor CU 605. The subsequent sequence is the same as S614 in Fig. 6. Note that the conditions other than the trigger may be the same as those in the first embodiment, and the description in the sequence and the flow chart will be omitted.

[0115] <Third embodiment> In the first embodiment, the mobile IAB node 601 determines whether the source IAB donor CU of the DU function unit 602 should be migrated when the mobile IAB node 601 receives a request for handover of the MT function unit 603 as a trigger. In contrast, the source IAB donor CU 1105 of the MT 1103 of the mobile IAB node 1101 may determine whether migration is necessary when the MT function unit 1103 of the mobile IAB node 1101 determines whether migration is necessary. That is, in this embodiment, the source IAB donor CU 1105 determines whether migration of the DU function unit 1102 of the mobile IAB node is necessary and notifies the mobile IAB node 1101.

[0116] FIG. 10 is a block diagram showing an example of the configuration of a software function 1050 of an IAB donor that executes the communication control function according to this embodiment.

[0117] The software function 1050 of the IAB donor includes a signal transmitting unit 1051, a signal receiving unit 1052, a data storage unit 1053, a connection control unit 1054, a transition determination processing unit 1055, a transition notifying unit 1056, a communication status acquiring unit 1057, and a load information acquiring unit 1058. The functions of each block shown in Fig. 10 can be realized by the control unit 402 executing a control program stored in the storage unit 403 in the hardware configuration shown in Fig. 4.

[0118] The signal transmitting unit 1051 and the signal receiving unit 1052 transmit and receive wireless signals that comply with the 3GPP standard, such as the LTE standard or the 5G standard.

[0119] The data storage unit 1053 stores various programs and various data (various information) in the storage unit 403 to hold them.

[0120] The connection control unit 1054 controls an antenna for wireless communication performed by the wireless communication unit 404. In this embodiment, the connection control unit 1054 judges whether or not handover to the MT function unit of the mobile IAB node is necessary, and decides on handover to the MT function unit as necessary. When the connection control unit 1054 decides on handover to the MT function unit, it makes a transition request (handover request) for the MT function unit.

[0121] The transition determination processing unit 1055 performs a determination process including whether or not to transition the DU function unit of the mobile IAB node based on the communication status. The determination process itself may be the same as the determination process of the transition determination processing unit 455 according to the above-mentioned first embodiment. In this embodiment, the transition determination processing unit 1055 may perform the determination process in response to the decision of handover by the connection control unit 1054.

[0122] The transition notification unit 1056 transmits notification information regarding transition to the mobile IAB node when the transition determination processing unit 1055 determines that the DU function unit of the mobile IAB node is to be transitioned. The message format for transmitting the notification information may be the RRC Reconfiguration or RRC Setup message format defined in Chapter 6.2.2 of TS38.331. For example, fields called "mIAB-DU transition request" and "mIAB-DU transition destination donor CU" may be added to the reserved area "nonCriticalExtension" in the message format.

[0123] The communication status acquisition unit 1057 acquires communication status information related to a connected mobile IAB node. The communication status information itself may be the same as the communication status information collected by the communication status collection unit 457 according to the first embodiment described above. In this embodiment, the communication status acquisition unit 1057 acquires the communication status information based on a notification from the mobile IAB node. In this case, a reserved field "nonCritialExtension" of the Measurement Report message format defined in Chapter 6.2.2 of TS38.331 may be used. For example, fields called "Mobile IAB Node Communication Information" and "Network Slice Type of UE Request" may be added to the reserved field. In this case, the communication status information (delay time, etc.) may be included in the communication information field of the mobile IAB node.

[0124] The load information acquisition unit 1058 acquires load information of the own station. The load information may include the free buffer capacity, the number of connected UEs, etc., as in the first embodiment described above. In addition to the load information of the own station, the load information acquisition unit 1058 may acquire load information of other IAB donor CUs adjacent to the currently connected IAB donor CU.

[0125] A specific sequence will be described in Figure 11. However, they are common in terms of the transition decision of the DU function unit 1102 of the mobile IAB node, and the only difference is that the subject of the transition decision is the mobile IAB node 1101 and the IAB donor CU 1105. Therefore, only the differences from Figure 6 will be described here, and the same sequence will not be described.

[0126] After deciding to hand over the mobile IAB node MT 1103, the source non-F1 donor CU 1105 also adds a parameter requesting communication status information of the mobile IAB node to the RRC Reconfiguration message and transmits it (S1113). The mobile IAB node 1101 that receives the mIAB-MT 1103 transition request (handover request) from the source non-F1 donor CU 1105 performs the following. That is, it calculates the delay time for the F1 donor CU 1104 and the IAB donor CU 1105 that have established an F1 interface with the DU function unit 1102 based on the Ping value or the number of MT transitions (S1114). Next, the mobile IAB node 1101 transmits the measured delay time of its own station to the non-F1 donor CU 1105 as communication status information (S1116).

[0127] After sending the message in S1113, the non-F1 donor CU 1105 collects its own load information and the load information of the neighboring donor CUs (S1115). After receiving S1116, the IAB donor CU 1105 determines whether to transition from mIAB to MT according to the flowchart described later (S1117). In S1118, the mobile IAB node is notified of the result of the determination on the DU transition.

[0128] Here, the mIAB-DU transfer determination process by the donor CU in FIG. 12 will be described.

[0129] First, the non-F1 donor CU 1105 from which mIAB-MT is to be migrated requests load information (such as free buffer capacity and the number of connected UEs) from adjacent donor CUs, and receives the load information from the adjacent donor CU (S1200). Next, the free buffer capacity of the own station and the number of connected UEs are measured to collect load information (S1201). The mobile IAB node 1101 receives the measured delay time and the network slice type requested by the accessing UE (S1202). In S1203, it is determined whether the network slice type requested by the UE is low latency (URLLC), and if it is low latency, it is determined whether the delay time measured by the mIAB node 1101 exceeds a threshold (for example, 10 ms or less) (S1204). If the delay time exceeds the threshold, hopping multiple IAB donors such as continuous MT migration is considered to be one of the factors that increases the delay, so it is determined to migrate the mIAB-DU 1102 from the connected non-F1 donor CU 1105 (S1205). At this time, it may be determined to migrate to the target non-F1 donor CU 1206 to which the mIAB-MT 1103 is scheduled to migrate. If the delay time does not exceed the threshold in S1204, the DU does not migrate (S1210). If the network slice type requested by the UE is not low delay (URLLC) in S1203, it is determined whether it is high speed and large capacity (eMBB) (S1206). If it is high speed and large capacity, it is confirmed in S1207 whether the buffer free capacity of the target non-F1 donor CU 1106 is equal to or greater than a threshold (for example, 100 MB) (S1207). Then, if the buffer free capacity is equal to or greater than the threshold, it is determined to migrate the mIAB-DU 1102 from the connected non-F1 donor CU 1105 (S1205). Or, it is determined to migrate to the target non-F1 donor CU 1106 with a buffer with room. If the network slice type requested by the UE in S1206 is not high speed and large capacity, it is determined whether it is a simultaneous multiple connection (MIoT) (S1208). If it is a simultaneous multiple connection, it is confirmed whether the number of connected UEs is below a threshold (for example, 1000 UEs) (S1209), and if it is below the threshold, it is determined to shift the DU function unit 1102 from the currently connected non-F1 donor CU 1105 (S1205). Alternatively, it is determined to shift to a target non-F1 donor CU 1106 with a smaller number of connected UEs.

[0130] Note that Figure 12 shows the case where a network slice request is made from a UE connected to the mobile IAB node 1101, and Figure 13 shows the case where there is no UE request, but since the operation is the same except for determining the network slice type, the explanation of Figure 13 is omitted.

[0131] (Other embodiments) The present invention can also be realized by a process in which a program for realizing one or more functions of each of the above-mentioned embodiments is supplied to a system or device via a network or a storage medium, and one or more processors in a computer of the system or device read and execute the program. Also, the present invention can be realized by a circuit (e.g., ASIC or FPGA) for realizing one or more functions.

[0132] Although each embodiment has been described above in detail, the present invention is not limited to the specific embodiment, and various modifications and changes are possible within the scope of the claims. In addition, it is also possible to combine all or a plurality of the components of the above-described embodiments.

[0133] In addition, the following supplementary notes are disclosed regarding the above embodiment.

[0134] (Appendix 1) A communication device that functions as a mobile IAB (Integrated Access and Backhaul) node, A determination means for performing a determination process including whether or not to migrate a DU (Distributed Unit) function unit based on a communication state; and a first notification means for transmitting notification information regarding the transition to a connected IAB donor CU (Central Unit) when the determination means determines to perform the transition. (Appendix 2) The receiving means further includes a receiving unit for receiving a handover request of an MT (Mobile Termination) function unit from the connected IAB donor CU, The communication device according to claim 1, wherein the determining means performs the determining process when the receiving means receives the handover request. (Appendix 3) 3. The communication device according to claim 1, wherein the determining means performs the determining process when the moving speed of the own station falls below a threshold. (Appendix 4) Further comprising a collection means for collecting communication status information including at least one of a delay time related to communication with the connected IAB donor CU and a network slice type requested by a UE (User Equipment) accessing the device; The communication device according to any one of claims 1 to 3, wherein the determination means determines the communication status based on the communication status information collected by the collection means. (Appendix 5) The load information processing device further includes a request means for requesting at least one of load information of the connected IAB donor CU and load information of another IAB donor CU adjacent to the connected IAB donor CU, The communication device according to any one of claims 1 to 4, characterized in that the determination means determines the communication status based on the load information acquired via a request by the request means. (Appendix 6) The communication device according to claim 5, wherein the request means uses an RRC message. (Appendix 7) The communication device according to any one of appendixes 1 to 6, wherein the determination process includes determining a migration destination IAB donor CU when it is determined to perform the migration. (Appendix 8) 8. The communication device according to claim 1, wherein the notification information includes a request for the transition. (Appendix 9) A communication device described in any one of appendices 1 to 8, characterized in that it further has a second notification means for notifying the connected IAB donor CU of an identifier of the IAB donor CU to be migrated to using an F1-AP message. (Appendix 10) A communication device that functions as an IAB donor CU, A determination means for performing a determination process including whether or not to transition the DU function unit of the mobile IAB node based on a communication status; a notification means for transmitting notification information regarding the transition to the mobile IAB node when the determination means determines to perform the transition. (Appendix 11) A decision means for deciding a handover to an MT function unit of the mobile IAB node, The communication device according to claim 10, wherein the judgment means performs the judgment process in response to a decision to perform the handover made by the decision means. (Appendix 12) A first acquisition means for acquiring communication status information from the mobile IAB node, the communication status information including at least one of a delay time related to communication with an IAB donor CU currently connected to the mobile IAB node and a network slice type requested by a UE currently accessing the mobile IAB node, 12. The communication device according to claim 10, wherein the determining means determines the communication status based on the communication status information acquired by the first acquiring means. (Appendix 13) The communication device according to any one of appendices 10 to 12, further comprising a second acquisition means for acquiring at least one of load information of the local station and load information of other IAB donor CUs adjacent to the local station. (Appendix 14) The communication device according to claim 13, wherein the determining means determines the communication status based on the load information acquired by the second acquiring means. (Appendix 15) The communication device according to any one of appendixes 10 to 14, wherein the determination process includes determining a destination IAB donor CU when it is determined that the transition is to be performed. (Appendix 16) 16. The communication device according to any one of claims 10 to 15, wherein the notification information includes a request for the transition. (Appendix 17) The communication device according to any one of Supplementary Notes 10 to 16, wherein the notification means uses an RRC message. [Explanation of symbols]

[0135] 100 Communication Systems 101 Wired Link 105 vehicles 108 Building 110 Core Network 120 IAB donors 121 IAB nodes 122 IAB nodes 123 IAB Nodes 402 Control section 403 Storage section 404 Communications Department 404 Wireless Communication Department 405 Antenna control section 406 Antenna 407 Operation section 451 Signal Transmitter 452 Signal receiving unit (an example of a receiving means) 453 Data Storage Unit 454 Connection control section 455 Transition judgment processing unit (an example of a judgment means) 456 Transition request unit (an example of a first notification means) 457 Communication status collection unit (an example of collection means) 458 Load information request unit (an example of a request means) 459 Destination information notification unit (an example of a second notification means) 1051 Signal transmitter 1052 Signal receiving unit 1053 Data storage unit 1054 Connection control unit (an example of a determination means) 1055 Transition determination processing unit (an example of a determination means) 1056 Transition notification unit (an example of a notification means) 1057 Communication status acquisition unit (an example of a first acquisition means) 1058 load information acquisition unit (an example of a second acquisition means)

Claims

1. A communication device that functions as a mobile IAB (Integrated Access and Backhaul) node, A determination means that performs a determination process, including whether or not to perform a transition of the DU (Distributed Unit) function based on the communication status, A communication device characterized by having a first notification means that transmits notification information regarding the transition to a connected IAB donor CU (Central Unit) when the determination means determines that the transition should be performed.

2. The system further includes receiving means for receiving a handover request from the Mobile Termination (MT) function unit from the connected IAB donor CU, The communication device according to claim 1, characterized in that the determination means performs the determination process triggered by the reception means receiving the handover request.

3. The communication device according to claim 1, characterized in that the determination means performs the determination process when the station's moving speed falls below a threshold.

4. The system further includes a means for collecting communication status information, which includes at least one of the following: the delay time related to communication with the connected IAB donor CU and the network slice type requested by the UE (User Equipment) accessing the device. The communication device according to claim 1, wherein the determination means determines the communication status based on the communication status information collected by the collection means.

5. The system further includes a request means for requesting load information from the connected IAB donor CU, which includes at least one of the load information of the connected IAB donor CU and the load information of other IAB donor CUs adjacent to the connected IAB donor CU. The communication device according to claim 1, characterized in that the determination means determines the communication status based on the load information obtained through the request by the request means.

6. The communication device according to claim 5, characterized in that the request means uses RRC messages.

7. The communication device according to claim 1, characterized in that the decision process includes determining the destination IAB donor CU when it is determined that the transition should be performed.

8. The communication device according to claim 1, characterized in that the notification information includes the request for the transition.

9. The communication device according to claim 1, further comprising a second notification means for notifying the connected IAB donor CU of the identifier of the destination IAB donor CU using an F1-AP message.

10. A communication device that functions as an IAB donor CU, A determination means that performs a determination process, including whether or not to perform a migration of the DU function unit of the mobile IAB node, based on the communication status, A communication device characterized by having a notification means that transmits notification information regarding the migration to the mobile IAB node when the determination means determines that the migration should be performed.

11. The system further includes a determination means for determining the handover of the mobile IAB node to the MT function unit, The communication device according to claim 10, characterized in that the determination means performs the determination process triggered by the determination of the handover by the decision means.

12. The system further includes a first acquisition means for acquiring communication status information from the mobile IAB node, which includes at least one of the following: the delay time related to communication with the connected IAB donor CU at the mobile IAB node and the network slice type requested by the UE accessing the mobile IAB node. The communication device according to claim 10, characterized in that the determination means determines the communication status based on the communication status information obtained by the first acquisition means.

13. The communication device according to claim 10, further comprising a second acquisition means for acquiring at least one of the load information of its own station and the load information of other IAB donor CUs adjacent to its own station.

14. The communication device according to claim 13, characterized in that the determination means determines the communication status based on the load information obtained by the second acquisition means.

15. The communication device according to claim 10, characterized in that the decision process includes determining the destination IAB donor CU when it is determined that the transition should be performed.

16. The communication device according to claim 10, characterized in that the notification information includes the request for the transition.

17. The communication device according to claim 10, characterized in that the notification means uses RRC messages.

18. A method for controlling a communication device that functions as a mobile IAB node, A decision process that performs a decision process, including whether or not to perform a transition of the DU function unit, based on the communication status, If the determination step determines that the transition should be performed, the communication device transmits notification information regarding the transition to the IAB donor CU to which it is connected. A control method characterized by having the following features.

19. A method for controlling a communication device that functions as an IAB donor CU, A decision step that performs a decision process, including whether or not to migrate the DU function unit of the mobile IAB node based on the communication status, If the determination step determines that the migration should be performed, the step of sending notification information regarding the migration to the mobile IAB node, A control method characterized by having the following features.

Images