Control device, control method, and program

Abstract

To appropriately select a communication path in relay transmission.SOLUTION: A control device monitors, in a first communication path managed by the control device, a communication path from the control device to a relay device included in the first communication path, and acquires first status information on the communication path, when the relay device is included in a second communication path managed by another control device, acquires, from the another control device, second status information on the communication path from the another control device to the relay device, in the second communication path, and controls communication of the relay device based on the first status information and the second status information.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present invention relates to a technology for recognizing the state of a communication path in relay transmission. [Background technology]

[0002] The Third Generation Partnership Project (3GPP) is currently working on standardizing Integrated Access and Backhaul (IAB), which integrates access lines and backhaul lines (see Patent Document 1). In IAB, the radio resources used for the access line between a base station and a user equipment (UE) are also used for the backhaul line. For example, in IAB, radio resources in the millimeter wave band, such as the 28 GHz band, may be used. By using IAB, a relay device (IAB node) can relay communication between a base station device (IAB donor) and a terminal device via a radio line, which enables area coverage to be expanded at a lower cost than when using a wired line such as optical fiber.

[0003] However, millimeter-wave radio waves can be severely attenuated by weather conditions. Furthermore, due to the directivity of radio waves, communication may be disrupted due to obstacles along the radio wave propagation path. Therefore, when millimeter-wave radio waves are used in a wireless link established between an IAB donor and an IAB node or between two IAB nodes, a radio link failure (RLF) may occur, temporarily disrupting communication over the wireless link. To address this issue, the IAB framework provides topology redundancy, allowing an IAB node to establish links with multiple parent nodes, for example, for backhaul communication. Here, a "parent node" refers to a node (IAB donor or IAB node) directly connected to a communication path that is closer to the core network (upstream). Of the IAB nodes directly connected to a communication path, a node (downstream) that is farther from the core network may be called a "child node."

[0004] 3GPP is also studying an IAB node called a border IAB node (or boundary node). A border IAB node is an IAB node that connects to two or more parent nodes that are connected to different IAB donors. A border IAB node is controlled by a single IAB donor. The IAB donor manages a network formed by IAB nodes that are directly connected to the IAB donor or connected via other IAB nodes. The network managed by this IAB donor is hereinafter referred to as an IAB network. Other IAB nodes connected downstream from the border IAB node connect to the IAB network managed by the IAB donor that controls the border IAB node. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Special Publication No. 2018-525874 Summary of the Invention [Problem to be solved by the invention]

[0006] In communications between terminals connected to a border IAB node or its downstream IAB nodes, the terminals can use IAB networks managed by two or more IAB donors in parallel to the border IAB node. This allows for efficient communications, for example, if an RLF occurs in an IAB network managed by an IAB donor that controls the border IAB node, by using other IAB networks where no RLF has occurred.

[0007] However, while an IAB donor can recognize the status of communication paths within the IAB network that it manages, it cannot recognize the status of communication paths within IAB networks managed by other IAB donors.

[0008] The present invention provides a technique that enables efficient recognition of the status of multiple communication paths in relay transmission. [Means for solving the problem]

[0009] A control device according to one aspect of the present invention includes a monitoring means for monitoring a communication path from the control device to a relay device included in a first communication path managed by the control device, and acquiring first status information regarding the communication path; an acquisition means for acquiring, when the relay device is included in a second communication path managed by another control device, second status information regarding a communication path from the other control device to the relay device among the second communication paths, from the other control device; and a control means for controlling communication of the relay device based on the first status information and the second status information. The monitoring means transmits a message to confirm status information to a device included in a communication path from the control device to the relay device on the first communication path, and receives a response to the message, thereby acquiring the first status information. do. [Effects of the Invention]

[0010] According to the present invention, it is possible to efficiently recognize the states of multiple communication paths in relay transmission. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 is a diagram illustrating an example of the configuration of a wireless communication system. [Figure 2] FIG. 2 is a block diagram illustrating an example of the hardware configuration of an IAB donor. [Figure 3] FIG. 2 is a block diagram illustrating an example of the functional configuration of an IAB donor. [Figure 4] FIG. 10 is a diagram illustrating an example of the flow of a setting process related to a boundary IAB node. [Figure 5] FIG. 10 is a diagram illustrating an example of a processing flow when notifying status information of a communication path. [Figure 6] FIG. 10 is a diagram illustrating an example of the configuration of status information of a communication path. [Figure 7] FIG. 10 is a diagram illustrating an example of a processing flow when selecting a communication path. DETAILED DESCRIPTION OF THE INVENTION

[0012] Hereinafter, embodiments will be described in detail with reference to the accompanying drawings. Note that the following embodiments do not limit the scope of the invention claimed. Although multiple features are described in the embodiments, not all of these multiple features are necessarily essential to the invention, and multiple features may be combined arbitrarily. Furthermore, in the accompanying drawings, the same reference numerals are used to designate the same or similar components, and redundant explanations will be omitted.

[0013] (Configuration of wireless communication system) FIG. 1 shows an example of the configuration of a wireless communication system according to this embodiment. The wireless communication system of FIG. 1 includes a relay transmission network conforming to the Integrated Access and Backhaul (IAB) standard of the Third Generation Partnership Project (3GPP). In an IAB relay transmission network, wireless communication is performed by integrating access lines and backhaul lines. Hereinafter, this IAB relay transmission network will be referred to as an IAB network. The IAB network includes IAB donors (e.g., IAB donor 102 and IAB donor 103) and IAB nodes (e.g., IAB nodes 104-107 and IAB nodes 110-111). Through relay transmission via these IAB donors and IAB nodes, communication services are provided to a terminal (e.g., terminal 109) residing in an area (e.g., area 108) provided by any of the nodes (IAB donors or IAB nodes). Note that the configuration of FIG. 1 is merely an example, and more IAB donors, IAB nodes, and terminals may naturally exist.

[0014] The IAB donor establishes a connection by treating the IAB node as a terminal, and then performs configuration based on the Backhaul Adaptation Protocol (BAP). Once this configuration is complete, the IAB node begins to function as a relay device. An IAB donor can accommodate multiple IAB nodes. In the example of FIG. 1, the IAB donor 102 accommodates IAB nodes 104 to 107, and the IAB donor 103 accommodates IAB nodes 110 to 111. Multiple IAB nodes can be directly connected, for example, with the IAB node 111 connected downstream of the IAB node 110. Alternatively, multiple IAB nodes can be connected in parallel to a common IAB node (or IAB donor), for example, with the IAB nodes 105 and 106 connected downstream of the IAB node 104. The IAB donor is configured to be connectable to a core network (CN 101) using, for example, a wired line. The IAB donor and the core network can be connected, for example, by an Internet Protocol (IP) network. In the following, communication from the core network based on the IAB to each IAB node is referred to as backhaul communication to distinguish it from communication via an access line between an IAB donor or an IAB node and a terminal.

[0015] In backhaul communication, a downlink signal (a link from the network to the terminal) is transferred from an IAB donor to an IAB node. When multiple IAB nodes are connected in series, the signal is relayed from the parent node to the child node in turn. Also, in backhaul communication, when multiple IAB nodes are connected in series, an uplink signal (a link from the terminal to the network) is relayed from the child node to the parent node in turn, and is then transferred to the IAB donor. As mentioned above, a "parent node" refers to an IAB donor or IAB node on the upstream side (approaching the core network) of a communication path, and a "child node" refers to an IAB node on the downstream side (away from the core network) of a communication path. For example, from the perspective of IAB node 104, IAB donor 102 is the parent node, and IAB nodes 105 and 106 are child nodes. Also, from the perspective of IAB node 106, IAB node 104 is the parent node, and IAB node 107 is the child node. From the perspective of IAB node 107, IAB node 106 is the parent node, but there are no child nodes. Hereinafter, one or more IAB nodes included in a communication path from an IAB donor to an IAB node that has no child nodes may be referred to as IAB nodes subordinate to that IAB donor. In the example of FIG. 1, IAB nodes 104 to 107 are subordinate to IAB donor 102, and IAB nodes 110 to 111 are subordinate to IAB donor 103. IAB donors can provide connections to core networks for their subordinate IAB nodes via backhaul communication.

[0016] Note that an IAB donor can communicate with other IAB donors without going through a core network. In this case, an Xn interface defined in TS38.420, a 3GPP standard, is established between the IAB donors that communicate without going through a core network. In this embodiment, an Xn interface is established between IAB donors 102 and 103, and it is assumed that communication can be performed between these IAB donors without going through a core network.

[0017] Each IAB node (and IAB donor) can form a cell and establish an access line with a terminal to provide communication services to the terminal. The example of FIG. 1 shows a state in which an IAB node 107 forms an area 108 and can provide communication services to a terminal 109 staying within the area 108. Note that the "terminal" is, for example, User Equipment (UE). A terminal staying in an area provided by an IAB node can connect to the IAB donor and the core network via backhaul communication.

[0018] As described above, each IAB donor configures an IAB network using one or more subordinate IAB nodes and is configured to provide communication services to terminals. The radio access technology (RAT) used by the IAB may be, for example, fifth-generation (5G) New Radio (NR), and the IAB donor and IAB node may be referred to as a gNodeB (gNB). However, this is merely an example, and a next-generation RAT after 5G may be used, or another RAT such as Long Term Evolution (LTE) may be used, and the IAB donor and IAB node may be treated as a node with a name corresponding to that RAT. Furthermore, the discussion of this embodiment may be applied to any wireless communication system in which a relay transmission path is formed, other than a cellular communication system, and to a communication device belonging to that wireless communication system.

[0019] (Device configuration) Next, a description will be given of an example of the configuration of an IAB donor (IAB donor 102 and IAB donor 103). In the following, when there is no need to distinguish between IAB donor 102 and IAB donor 103, they will simply be referred to as "IAB donors."

[0020] 2 shows an example of the hardware configuration of an IAB donor. The IAB donor includes, for example, a control unit 201, a memory unit 202, a wired communication unit 203, a wireless communication unit 204, an antenna control unit 205, and an antenna 206. Note that this configuration is only an example, and the IAB donor may have a configuration completely different from that shown in FIG. 2, or may include additional elements in the example configuration of FIG. 2, or may delete elements included in the example configuration of FIG. 2.

[0021] The control unit 201 includes one or more processors, such as a CPU or an MPU. The CPU stands for Central Processing Unit, and the MPU stands for Micro Processing Unit. In one example, the control unit 201 may include multiple processors, such as a multi-core processor. The control unit 201 controls the entire device by executing a control program stored in the storage unit 202. The control unit 201 may include, for example, a field programmable gate array (FPGA), a digital signal processor (DSP), or an application-specific integrated circuit (ASIC). The storage unit 202 includes one or more memories or storage devices, such as a ROM or RAM. The ROM stands for Read Only Memory, and the RAM stands for Random Access Memory. The storage unit 202 stores, for example, the control program executed by the control unit 201 and information related to wireless communication, such as cell information and information about connected terminals. The storage unit 202 also stores various information related to the IAB, such as routing information and address information of the IAB network. Note that various operations described below can be realized by, for example, the control unit 201 executing a control program stored in the storage unit 202.

[0022] The wired communication unit 203 includes a communication circuit and an interface for performing wired communication with the CN 101 and other IAB donors. The wireless communication unit 204 includes a communication circuit and the like for performing wireless communication in compliance with cellular communication standards such as 3GPP LTE and 5G. Note that the wireless communication unit 204 may also include a communication circuit operable in compliance with communication standards other than cellular communication standards, such as a wireless local area network (LAN). The antenna control unit 205 controls the antenna 206 for wireless communication performed by the wireless communication unit 204. The antenna 206 is an antenna having characteristics capable of receiving signals in a frequency band used in wireless communication performed by the wireless communication unit 204 and outputting signals in that frequency band.

[0023] 3 is a diagram showing an example of the functional configuration of an IAB donor. The IAB donor's functional configuration includes, for example, a wired transceiver 301, a wireless transceiver 302, a connection controller 303, a broadcast information generator 304, and a time information unit 305. The IAB donor may further include a backhaul PDU generator 306, a backhaul PDU receiver 307, an IAB network manager 308, a communication path monitor 309, and a status collector 310.

[0024] The wired transceiver 301 transmits and receives various signals, such as frames and information, between the CN 101 and other IAB donors via the wired communication unit 203 in FIG. 2. The wireless transceiver 302 transmits and receives various signals to and from communication devices, such as IAB nodes connected under it and terminals connected to those IAB nodes, via the wireless communication unit 204 in FIG. 2. The connection control unit 303 controls connections with other communication devices through communication via the wireless transceiver 302. The connection control unit 303 performs processing related to connection and disconnection with other communication devices, for example, by transmitting and receiving Radio Resource Control (RRC) messages via the wireless transceiver 302. The broadcast information generation unit 304 generates broadcast information, such as system information related to cells provided by the IAB donor itself. The IAB donor periodically transmits broadcast information via the wireless transceiver 302 without specifying a destination. Note that broadcast information transmitted by subordinate IAB nodes may also be generated by the broadcast information generation unit 304. The broadcast information transmitted by a subordinate IAB node may be generated by that subordinate IAB node. By receiving the broadcast information, other communication devices (terminals or communication devices capable of functioning as IAB nodes) can recognize the presence of an IAB donor or IAB node in the vicinity and can perform connection processing to the IAB donor or IAB node. The time information unit 305 acquires time information via the network and performs timer processing to measure time until a predetermined time.

[0025] The backhaul PDU generator 306 generates a Protocol Data Unit (PDU) based on the Backhaul Adaptation Protocol (BAP) exchanged between communication devices in backhaul communication. Data transfer and notification of control messages in backhaul communication are performed using this PDU. The PDU is transmitted to and received from other communication devices via the wireless transceiver 302. The PDU includes a BAP header and a payload that stores the data and control messages to be transferred. The BAP address of the PDU destination is specified in the BAP header. The IAB donor that manages the IAB network uniquely assigns a BAP address to each IAB node that constitutes the IAB network. In other words, the destination BAP address specifies which IAB node the PDU should be transferred to. The backhaul PDU receiver 307 analyzes the PD received from the subordinate IAB node via the wireless transceiver 302.

[0026] The IAB network management unit 308 manages the IAB network that includes subordinate IAB nodes. The IAB network management unit 308 assigns a BAP address to each subordinate IAB node and sets up a communication path (routing) from an IAB donor to a destination IAB node. The IAB network management unit 308 also changes the shape (topology) of the communication path, which is determined by which parent node an IAB node is connected to, and performs connection determination and operation settings for boundary IAB nodes, as described below.

[0027] The communication path monitoring unit 309 monitors a communication path to a specific IAB node in the IAB network managed by the IAB donor itself via the wireless transceiver unit 302. For example, the communication path monitoring unit 309 transmits a confirmation message to each IAB node constituting the communication path monitored by the IAB donor to confirm the free space of the communication buffer, thereby grasping the free space of the communication buffer of each IAB node. Here, when an IAB node notifies the IAB donor of the free space of its communication buffer, a flow control feedback message defined in the BAP may be used. Note that, if there is an IAB node from which a response to the confirmation message is not received, the communication path monitoring unit 309 may determine that a radio link failure (RLF) has occurred in the communication path including that IAB node.

[0028] The status collection unit 310 receives notification of status information of a communication path acquired by another IAB donor from the other IAB donor via the wired transceiver 301. That is, the status collection unit 310 receives status information about a communication path under the management of the other IAB donor from the other IAB donor. The status collection unit 310 may send a request message requesting status information about the communication path to the other IAB donor, and receive status information about the communication path under the management of the other IAB donor in response to the request message. When an IAB donor receives a request message from another IAB donor, it notifies the IAB donor that sent the request message of the status information about the communication path obtained by the communication path monitoring unit 309.

[0029] The IAB donor consists of two units: a Central Unit (CU) and a Distributed Unit (DU). An IAB node consists of a Mobile Termination (MT), which connects to the parent node as a terminal, and a DU. While both the IAB donor and IAB node include a DU, the term "DU" below refers to the IAB donor's DU. The CU controls the DU and supports higher-layer protocols in wireless communication. For example, the CU supports the Packet Data Convergence Protocol (PDCP) and Service Data Adaptation Protocol (SDCP) used for communication with terminals. The CU may also support the User Datagram Protocol (UDP), Stream Control Transmission Protocol (SCTP), and IP used for communication with the CN 101 and other IAB donors. The CU also assigns BAP addresses to DUs within the IAB donor. The DU supports lower-layer protocols in wireless communication, such as the Radio Link Control (RLC) layer, physical layer, and Medium Access Control (MAC) layer. The CU and DU may be located in separate devices, in which case the devices may be connected by a wired IP network.

[0030] (Processing flow) An example of the processing flow when IAB node 106 operates as a boundary IAB node in the wireless communication system of Fig. 1 will be described using Fig. 4. It is assumed that IAB donor 102 performs backhaul communication with IAB node 104 and IAB node 106, and IAB donor 103 performs backhaul communication with IAB node 110. It is also assumed that IAB donor 102 can directly communicate with IAB donor 103, for example, by establishing an Xn interface.

[0031] First, the IAB node 106 receives broadcast information from the IAB node 110 and detects that it is also connectable to the IAB node 110 (S401). Then, the IAB node 106 notifies the IAB donor 102 that it has detected the IAB node 110, for example, by using identification information (gNB ID) of the base station device (IAB node) included in the received broadcast information. That is, the IAB node 106 notifies the IAB donor 102 of the existence of a connectable IAB node. The IAB donor 102 determines whether the IAB node 106 can operate as a boundary IAB node by connecting to the notified IAB node 110 (S402). For the IAB node 106 to effectively operate as a boundary IAB node, it is important that the IAB donor managing the IAB node 110 and the IAB donor 102 can communicate directly. For this reason, the IAB donor 102 inquires of all or some of the IAB donors with which it can directly communicate (for example, with which an Xn interface has been established) whether the IAB nodes under its control include the IAB node 110. In this embodiment, the IAB donor 102 can directly communicate with the IAB donor 103, and therefore makes an inquiry to the IAB donor 103.

[0032] In response to the inquiry, the IAB donor 103 checks whether the IAB node 110 is included in the IAB network managed by the IAB donor 103 (S403). Then, the IAB donor 103 notifies the IAB donor 102 that the IAB node 110 is included in the IAB network using a response message. If the IAB donor 103 does not include the IAB node 110 in the IAB network managed by the IAB donor 103, the IAB donor 102 may transmit a response indicating that the IAB node 110 does not exist under the control of the IAB donor 102, or may not transmit a response at all. Upon receiving the response from the IAB donor 103, the IAB donor 102 can recognize that the IAB node 110 exists under the control of the IAB donor 103 with which direct communication is possible. Based on this recognition, the IAB donor 102 can identify that the IAB node 106 can operate as a border IAB node. In this embodiment, the IAB donor 102 determines that the IAB node 106 operates as a border IAB node, and transmits a connection instruction message to the IAB node 106 instructing it to connect to the IAB node 110 (S404).

[0033] Upon receiving the connection instruction message, the IAB node 106 executes connection processing with the IAB node 110 (S405). The IAB node 106 establishes downlink synchronization by, for example, receiving a downlink synchronization signal from the IAB node 110, and then establishes uplink synchronization by executing a random access process (RACH process). Thereafter, the IAB node 106 transmits and receives RRC messages to and from the IAB node 110, and establishes a connection in the RRC layer. After establishing a connection with the IAB node 110, the IAB node 106 is assigned a BAP address by the IAB donor 103 that controls the IAB node 110 (S406). The IAB node 106 is also assigned a BAP address by the IAB donor 102. Therefore, the IAB node 106 has a corresponding BAP address in each of the two or more IAB networks in which it participates. In the following, the IAB network in which the IAB node 106 originally participated (the IAB network managed by the IAB donor 102) may be referred to as the primary network. Also, the IAB network in which the IAB node 106 will additionally participate (the IAB network managed by the IAB donor 103) may be referred to as the secondary network. The primary network may be the IAB network managed by the IAB donor that controls the IAB node 106. In other words, if the IAB node 106 is controlled by the IAB donor 103 that manages the IAB network in which the IAB node 106 will additionally participate, the IAB network managed by the IAB donor 103 may be treated as the primary network.

[0034] When the IAB node 106 establishes a connection with the IAB node 110 and receives a BAP address assignment from the IAB donor 103, it transmits a connection completion notification to the IAB donor 102 indicating that the connection process with the IAB donor 103 has been completed (S407). The connection completion notification includes, for example, the BAP address assigned to the IAB node 106 by the IAB donor 103. Upon receiving the connection completion notification, the IAB donor 102 configures the IAB node 106 as a boundary IAB node (S408). When the boundary IAB node receives a packet addressed to a BAP address assigned by an IAB donor that manages a secondary network, it rewrites the packet's destination BAP address to the BAP address of the primary network and then forwards the packet to a lower node. In the configuration of the boundary IAB node, settings for this forwarding are made. In this embodiment, when the IAB node 106 receives a packet addressed to the BAP address assigned to the IAB node 106 by the IAB donor 103, the IAB node 106 performs a setting to rewrite the destination BAP address to the BAP address of the IAB node 107 and forward the packet. After this setting is completed, the IAB node 106 starts operating as a boundary node.

[0035] The IAB node 107 connected downstream of the IAB node 106 may also be assigned a BAP address in the sub-network. In this case, if the destination of a signal is the BAP address of the main network or sub-network of the IAB node 106, the IAB node 106 may process the signal within the IAB node 106. On the other hand, if the destination of a signal is the BAP address of the main network or sub-network of the IAB node 107, the IAB node 106 may forward the signal to the IAB node 107. In other words, if the BAP address of the sub-network is also assigned to the IAB node 107, the IAB node 106 may not need to rewrite the destination BAP address. If the BAP address of the IAB node 107 in the sub-network is specified as the destination BAP address, the IAB node 106 may rewrite the destination BAP address to the BAP address of the IAB node 107 in the main network. Note that, regardless of whether the destination is IAB node 106 or IAB node 107, the BAP address of IAB node 106 may be set as the destination in the secondary network. In one example, information indicating whether the destination is IAB node 106 or IAB node 107 may be included in the signal. For example, a signal including the BAP address of IAB node 106 or IAB node 107 in the primary network may be included in the payload, and a signal may be generated in which the BAP address of IAB node 106 in the secondary network is specified as the destination. In this case, upon receiving this signal, IAB node 106 may extract only the payload portion and treat the signal stored in the payload portion as a signal that arrived in the primary network.

[0036] When transmitting data to IAB node 107, if the IAB donor 102 communicates only using the IAB network managed by the IAB donor 102 itself, the IAB donor 102 generates a signal addressed to the BAP address of the IAB node 107. The IAB donor 102 then transmits the signal to the IAB node 104. The transmitted signal is forwarded to the IAB node 107 via the IAB node 104 and the IAB node 106. On the other hand, when the IAB donor 102 is to transmit data to the IAB node 107 via the IAB network managed by the IAB donor 103, the IAB donor 102 generates a signal addressed to the BAP address of the IAB node 106 assigned by the IAB donor 103. The IAB donor 102 then transmits the signal to the IAB donor 103. More specifically, the IAB donor 102 transmits the generated signal to the DU of the IAB donor 103. The transmitted signal is forwarded to the IAB node 106 via the IAB donor 103 and the IAB node 110. When the IAB node 106 receives the signal, it rewrites the destination BAP address to the BAP address of the IAB node 107, and the signal is finally forwarded to the IAB node 107. In this way, the IAB node 106 operates as a boundary node, making it possible to select a communication path from the IAB donor 102 to the IAB node 106 or another IAB node connected downstream thereof.

[0037] Returning to FIG. 4, the IAB donor 102 transmits a notification request for communication path status information to the IAB donor 103 via the status collection unit 310 (S409). The IAB donor 102 also monitors the communication path from its own device to the IAB node 106 (boundary IAB node) via the communication path monitoring unit 309, and collects status information about the communication path. Similar to the IAB donor 102, the IAB donor 103 also monitors the communication path from its own device to the IAB node 106 (boundary IAB node) via the communication path monitoring unit 309, and collects status information about the communication path. Note that while this embodiment illustrates an example in which each IAB donor monitors the communication path to the boundary IAB node, the IAB donor may also monitor other communication paths, such as a communication path including an IAB node connected downstream from the boundary IAB node. Then, when the IAB donor 103 receives a notification request for communication path status information, it notifies the IAB donor 102 that requested the information of the status information of the communication path from its own device to the IAB node 106 (S410). In this way, the IAB donor 102 that manages the primary network can obtain information indicating the environment of the communication path to the boundary IAB node in the secondary network. Then, for example, the IAB donor 102 can decide to use the second communication path when the communication environment of the second communication path from the IAB donor 103 to the IAB node 106 is better than the communication environment of the first communication path from its own device to the IAB node 106. This enables efficient communication when a boundary IAB node is present.

[0038] Next, an example of the flow of a process in which the IAB donor 103 notifies status information of a communication path will be described with reference to Fig. 5. This process corresponds to the process executed in S410 of Fig. 4, for example.

[0039] First, the IAB donor 103 determines whether a notification request for communication path status information has been newly received (S501). If the IAB donor 103 has newly received a notification request (YES in S501), the process proceeds to S504. On the other hand, if the IAB donor 103 has not newly received a notification request (NO in S501), the IAB donor 103 subsequently determines whether a notification request has been received in the past (S502). If the IAB donor 103 has not received a notification request in the past (NO in S502), the process simply ends. If the IAB donor 103 has received a notification request in the past (YES in S502), the IAB donor 103 measures time using the time information unit 305, for example, until the time elapsed since the previous notification request was received or the last information notification reaches a predetermined time (S503). The predetermined time may be, for example, a time preset in the IAB donor 103 or a time designated by another IAB donor (e.g., IAB donor 102). The predetermined time may be set for each boundary IAB node. When the elapsed time reaches the predetermined time, the IAB donor 103 proceeds to S504. As will be described later, the processes from S504 onward involve notifying the status information of the communication path. As a result, the IAB donor 103 notifies the IAB donor 102 of the information when it receives a request to notify the status information of the communication path (YES in S501), and thereafter at predetermined intervals (YES in S502, S503).

[0040] IAB donor 103 may notify IAB donor 102 of status information even if it has not received a request for notification of communication path status information. For example, IAB donor 103 may be configured to notify status information at a predetermined time. IAB donor 103 may be configured to repeatedly notify status information at a predetermined interval, regardless of the initial trigger for notifying status information.

[0041] In S504, the IAB donor 103 checks the free buffer capacity of each IAB node constituting the communication path from its own device to the IAB node 106 using the communication path monitoring unit 309. For example, the IAB donor 103 can check the free buffer capacity of each IAB node by requesting the IAB node 110 to report the free buffer capacity and receiving the report. For example, in response to receiving a request message from the IAB donor 103, the IAB node 110 transmits a message reporting the free communication buffer capacity. The message reporting the free communication buffer capacity can be, for example, a flow control feedback message defined in the BAP. The IAB donor 103 waits for responses including reports from all IAB nodes whose free communication buffer capacity is being checked, for example, for a predetermined period of time (S505).

[0042] If the IAB donor 103 does not receive a response from one or more IAB nodes (NO in S505), it may determine that an RLF has occurred on the link leading to the IAB node. This is because an RLF indicates that the request message did not reach the IAB node or that the response did not reach the IAB donor 103. If the IAB donor 103 determines that an RLF has occurred, it adds information indicating the occurrence of an RLF to the status information of the communication path (S506) and proceeds to S507. If the IAB donor 103 receives responses from all IAB nodes (YES in S505), it skips S506 and proceeds to S507. In S507, the IAB donor 103 adds available buffer capacity information to the status information of the communication path based on the flow control feedback messages notified from each IAB node. Then, the IAB donor 103 transmits the status information of the communication path to the IAB donor that sent the notification request (S508), and ends the process. After transmitting the status information of the communication path, the IAB donor 103 may return the process to S501.

[0043] In the above processing example, the IAB donor 103 periodically notifies the IAB donor that has requested the notification of the status information of the communication path. However, this is not limiting. For example, the IAB donor 103 may be configured to notify only when it checks the free buffer capacity of an IAB node included in the communication path from the donor itself to the boundary IAB node and finds that the free buffer capacity is below a specified value. In other words, a predetermined event may be defined, and notification may be performed only when the predetermined event occurs. This can reduce the amount of information exchanged between IAB donors. Alternatively, the IAB donor 103 may simply determine whether an RLF has occurred on the communication path to the boundary IAB node and notify the IAB donor that has requested the notification of the result of the determination.

[0044] An example of the structure of a message used to transmit status information of a communication path is shown in Fig. 6. In one example, the status information of the communication path is included in a message transmitted and received over the Xn interface. That is, the status information of the communication path may be transmitted by a message based on the Xn application protocol (XnAP) defined in 3GPP TS38.423. However, this is not limiting, and the status information of the communication path may be notified by a message used in a commonly used protocol such as a UDP / IP packet.

[0045] A message for transmitting communication path status information includes, for example, fields of message type 601, target IAB node ID 602, link status information 603, free buffer capacity information 604, and option 605. Note that the target IAB node ID 602, link status information 603, free buffer capacity information 604, and option 605 are prepared for each target IAB node for which the free communication buffer capacity is to be notified. In other words, if there are multiple target IAB nodes, the target IAB node ID 602, link status information 603, free buffer capacity information 604, and option 605 may be repeated as many times as the number of target IAB nodes.

[0046] The message type 601 is a field that can be included only once in a message and indicates what information this message is used to transmit. The message type 601 is, for example, a 4-octet (32-bit) field. In this embodiment, this field stores a value indicating status information of a communication path. The target IAB node ID 602 ​​is, for example, a 4-octet field and stores an IAB node identifier to indicate which IAB node the following link status information 603, buffer free space information 604, and options 605 relate to. The link status information 603 is, for example, a 1-octet field and stores a value indicating the link status between the IAB donor sending this message and the IAB node indicated by the target IAB node ID 602. The link status information 603 may store, for example, information that can identify whether the IAB donor that sent this message is able to communicate with the target IAB node (whether RLF occurs in any wireless link to the IAB node). The IAB donor may also identify the reliability of the link based on, for example, the frequency of past RLF occurrences, and store information indicating the reliability of the link in the link status information 603. The buffer free capacity information 604 is, for example, a three-octet field, and stores a value indicating the capacity of the communication buffer currently available in the IAB node indicated by the target IAB node ID 602 ​​in a predetermined unit (for example, kilobytes).

[0047] Option 605 is a field that can be used to store other information. For example, the IAB donor may measure the time it takes for a packet transmitted from its own device to reach the target IAB node and notify information indicating the time obtained by the measurement using option 605. The IAB donor may also store information indicating the radio wave strength of the radio waves transmitted from the parent node, measured at the target IAB node, in option 605. Note that the target IAB node may be configured to measure, for example, the above-mentioned time and radio wave strength and notify the IAB donor of the measurement results.

[0048] In the above example, both link status information 603 and free buffer capacity information 604 are included in the message, but only one of these may be included. Also, option 605 may be omitted if not required. Also, the order of the multiple information fields in the above example may be changed. Also, the sizes of the above-mentioned fields are merely examples. In other words, any format of message capable of notifying similar information may be used. Also, some fields may be omitted as necessary.

[0049] Next, an example of the process by which the IAB donor 102 selects a communication path will be described with reference to Fig. 7. The IAB donor 102 selects a communication path through the process of Fig. 7, and generates and transmits a signal (PDU) in which a destination BAP address is set so that the selected communication path can be used. For example, when the IAB donor 102 determines to transmit a signal via a secondary network, it transmits the generated signal to the IAB donor 103. When the IAB donor 102 determines to transmit a signal via a primary network, it can transmit the generated signal to a subordinate IAB node 104.

[0050] The IAB donor 102 determines whether the destination of data to be transmitted is an IAB node connected downstream from the boundary IAB node, such as a boundary IAB node or its child node (S701). In one example, the IAB donor 102 may perform the determination of S701 by setting the IAB node to which the terminal that is the final destination of the data is connected as the destination of signal forwarding by the BAP. However, this is not limited thereto. For example, when the IAB donor 102 controls a subordinate IAB node, the IAB donor 102 may perform the determination of S701 by setting the IAB node as the destination of a message for control. Note that the IAB donor 102 may determine whether the IAB node that is the source of uplink data is an IAB node connected downstream from the boundary IAB node, such as a boundary IAB node or its child node.

[0051] If the IAB node of the data destination is not a boundary IAB node or a downstream IAB node (NO in S701), the IAB donor 102 determines to communicate using only the communication path managed by the donor (S702). In other words, if the IAB node of the data destination is not a boundary IAB node or a downstream IAB node, there is no sub-network available for the destination IAB node, so the communication path within one configured IAB network will be used.

[0052] On the other hand, if the IAB donor 102 determines that the data destination IAB node is a boundary IAB node or an IAB node downstream thereof (YES in S701), it determines whether to use the primary network or the secondary network. To do so, the IAB donor 102 first collects communication path status information from the subordinate IAB nodes using the communication path monitoring unit 309 (S703). In the example of FIG. 1, the IAB donor 102 collects communication path status information by having the communication path monitoring unit 309 cause the IAB nodes 104 and 106 to report the communication path status information. In addition, the IAB donor 102 collects communication path status information from other IAB donors managing other IAB networks (secondary networks) in which the boundary IAB node participates using the status collecting unit 310 (S704). In the example of FIG. 1 , the IAB donor 102 collects status information of the communication paths of the nodes 110 and 106 subordinate to the IAB donor 103 via the IAB donor 103 by sending a request message to the IAB donor 103. The IAB donor 102 may collect information at other times, such as before it is determined in S701 that the data destination is a border IAB node. The IAB donor 102 may also collect information periodically. The IAB donor 102 may also use information obtained the previous time the process of FIG. 7 was executed. The IAB donor 102 may also store time information when the information was acquired, and collect information at the times of S703 and S704 if a predetermined period of time has elapsed since the information was acquired.

[0053] After collecting the communication path status information, the IAB donor 102 determines whether or not a communication path where RLF is occurring exists based on the information (S705). If a communication path where RLF is occurring exists (YES in S705), the IAB donor 102 does not select the communication path where RLF is occurring, but instead uses another communication path, and proceeds to S707 (S706). In one example, the IAB donor 102 may prevent the communication path where RLF is occurring from being an option in subsequent selection processing by registering the communication path where RLF is occurring on a blacklist or by excluding it from candidate communication paths to be used. On the other hand, if a communication path where RLF is occurring does not exist (NO in S705), the IAB donor 102 determines that all communication paths are available, and proceeds to S707 without performing any additional processing.

[0054] In S707, the IAB donor 102 selects a communication path to use for transmitting data. For example, the IAB donor 102 may select a communication path with a larger free buffer capacity based on the status information of each communication path collected in S703 and S704. For example, the IAB donor 102 may select a communication path based on the minimum free buffer capacity of the IAB nodes included in each communication path, with higher values ​​being selected preferentially. The IAB donor 102 may also select one communication path from among communication paths that can satisfy the communication capacity required for data communication. The IAB donor 102 may also, for example, determine the use of multiple communication paths. In this case, when multiple communication paths are used in parallel, the IAB donor 102 may select a combination of communication paths that can satisfy the required communication capacity. In the example of FIG. 1, the IAB donor 102 selects a communication path based, for example, on the size of the free buffer capacity of the IAB node 104 and the IAB node 110. The IAB donor 102 then communicates using the selected communication path.

[0055] As described above, by collecting communication path status information from other IAB donors, an IAB donor can select a communication path not only from the communication paths it manages but also from the communication paths managed by other IAB donors, thereby enabling communication that makes effective use of border IAB nodes.

[0056] In the above embodiment, a case where a communication path to be used is selected from two communication paths has been described. However, the same discussion can be applied to a case where a communication path by another IAB donor exists. In the above embodiment, an example where a communication path is selected based on whether an RLF has occurred and the free space in the communication buffer has been described. However, for example, the value stored in the field of option 605 may be used as a criterion for selecting a communication path. For example, as described above, if the field of option 605 stores information on the time required for a signal to reach the target IAB node from the IAB donor (i.e., signal propagation), the communication path to be used may be selected based on the time information. In one example, if the free space in the communication buffer exceeds a predetermined value in all communication paths, the IAB donor may preferentially select a communication path that takes a packet from the IAB donor to reach the border IAB node the shortest. In addition, when a communication path is selected based on the time required for signal propagation, the propagation time of the secondary network may be calculated by adding the propagation time from the IAB donor in the primary network to the IAB donor in the secondary network. Furthermore, for example, if the field of option 605 includes wireless quality, such as the radio wave reception strength of a signal from a parent node at the target IAB node, the communication path to be used may be selected based on that information. For example, a communication path with the highest minimum wireless quality among the communication paths between the IAB donor and the border IAB node may be selected. Furthermore, for example, if the free capacity of the communication buffer in the primary network and the free capacity of the communication buffer in the secondary network both exceed a predetermined value, a communication path may be selected based on wireless quality. Furthermore, for example, scores may be assigned to each communication path, such that the larger the free capacity of the communication buffer, the higher the score, and the shorter the packet arrival time, the higher the score, and communication paths with higher scores may be preferentially selected. Furthermore, if the free capacity of the communication buffer in the primary network exceeds a predetermined value and RLF does not occur, a communication path in the primary network may be used.

[0057] In the above embodiment, an example has been described in which an IAB donor controlled by a border IAB node selects a communication path to be used, but this is not limiting. For example, which of the IAB donors that manage the communication paths to which the border IAB nodes belong selects a communication path to be used may be determined based on, for example, the capability information of the IAB donor.

[0058] Although the above-described embodiment describes a method for collecting status information of communication paths in a relay transmission system based on IAB, a similar method can be applied to relay transmission systems other than IAB. That is, the above discussion can be applied to a case where a common relay device is included in multiple communication paths managed by different control devices. In this case, each control device collects status information of the communication paths it manages, and the status information regarding the multiple communication paths is aggregated in at least one of multiple control devices that respectively manage the multiple communication paths including the common relay device. This allows the control device that aggregates the status information to appropriately select a communication path to be used while taking into account the states of the multiple communication paths.

[0059] The above-described status information may be used for purposes other than selecting a communication path. For example, an IAB donor may use the status information to perform a process such as handing over a terminal connected to a boundary IAB node or a downstream IAB node to an IAB node belonging to a communication path that does not include a boundary IAB node. This allows the amount of communication at the boundary IAB node to be adjusted, preventing the boundary IAB node from becoming overloaded. Furthermore, the IAB donor may use the status information to adjust the location of the boundary IAB node, for example, if the boundary IAB node is mobile. This allows the communication quality at the boundary IAB node to be good across multiple communication paths, thereby improving the communication quality of the boundary IAB node. In this way, the status information can be used for various controls related to communication at the boundary IAB node.

[0060] The present invention can also be realized by supplying a program that realizes one or more functions of the above-described embodiments to a system or device via a network or a storage medium, and having one or more processors in the computer of the system or device read and execute the program. It can also be realized by a circuit (e.g., ASIC) that realizes one or more functions.

[0061] The invention is not limited to the above-described embodiments, and various changes and modifications can be made without departing from the spirit and scope of the invention. Accordingly, the following claims are appended to apprise the public of the scope of the invention. [Explanation of symbols]

[0062] 101: Core network, 102, 103: IAB donors, 104 to 107, 110: IAB nodes, 109: UE, 309: Communication path monitoring unit, 310: Status collection unit

Claims

1. A control device, a monitoring means for monitoring a communication path from the control device to a relay device included in the first communication path managed by the control device, and acquiring first status information regarding the communication path; an acquisition means for acquiring, when the relay device is included in a second communication path managed by another control device, second status information relating to a communication path from the other control device to the relay device, among the second communication path managed by the other control device; a control means for controlling communication of the relay device based on the first status information and the second status information; and The control device is characterized in that the monitoring means obtains the first status information by sending a message confirming status information to a device included in a communication path from the control device to the relay device in the first communication path and receiving a response to the message.

2. 2. The control device according to claim 1, wherein the acquisition means acquires the second status information by transmitting a message requesting the second status information to the other control device.

3. 3. The control device according to claim 1, wherein the acquisition means acquires the second status information when the control device controls the relay device.

4. 4. The control device according to claim 1, further comprising a notification unit that notifies the other control devices of the first status information.

5. 5. The control device according to claim 4, wherein the notification means notifies the other control device of the first status information when a message requesting the first status information is received from the other control device.

6. 6. The control device according to claim 4, wherein the notification means notifies the other control devices of the first status information at predetermined intervals.

7. A control device as described in any one of claims 1 to 6, characterized in that the first status information includes the free capacity of a communication buffer in a device included in a communication path from the control device to the relay device in the first communication path, and the second status information includes the free capacity of a communication buffer in a device included in a communication path from the other control device to the relay device in the second communication path.

8. the first status information includes information capable of identifying whether a radio link failure (RLF) has occurred in a link between the control device and a device included in a communication path from the control device to the relay device in the first communication path, A control device as described in any one of claims 1 to 7, characterized in that the second status information includes information that can identify whether an RLF has occurred in a link between a device included in a communication path from the other control device to the relay device in the second communication path and the other control device.

9. A control device as described in any one of claims 1 to 8, characterized in that the first status information includes information indicating the radio wave reception strength at a device included in a communication path from the control device to the relay device in the first communication path, and the second status information includes information indicating the radio wave reception strength at a device included in a communication path from the other control device to the relay device in the second communication path.

10. A control device as described in any one of claims 1 to 9, characterized in that the first status information includes information indicating the time required for a signal to propagate between the control device and a device included in a communication path from the control device to the relay device in the first communication path, and the second status information includes information indicating the time required for a signal to propagate between the other control device and a device included in a communication path from the other control device to the relay device in the second communication path.

11. A control device as described in any one of claims 1 to 10, characterized in that when communication is performed with the relay device or a device connected on the first communication path away from the control device than the relay device, the control means determines, based on the first status information and the second status information, whether to communicate using the communication path between the other control device and the relay device on the second communication path, or to communicate without using the communication path.

12. When the first status information indicates the free space of a first communication buffer in a device between the control device and the relay device, and the second status information indicates the free space of a second communication buffer in a device between the other control device and the relay device, determining, based on the fact that the free space of the first communication buffer is greater than the free space of the second communication buffer, to perform communication by preferentially using the communication path between the control device and the relay device in the first communication path; determining, based on the free space of the first communication buffer being smaller than the free space of the second communication buffer, to perform communication by preferentially using the communication path between the other control device and the relay device on the second communication path; The control device according to claim 11 .

13. When the first status information indicates a first reception strength of radio waves at a device between the control device and the relay device, and the second status information indicates a second reception strength of radio waves at a device between the other control device and the relay device, determining, based on the first reception strength being higher than the second reception strength, to perform communication by preferentially using a communication path between the control device and the relay device in the first communication path; determining, based on the first reception strength being lower than the second reception strength, to perform communication by preferentially using the communication path between the other control device and the relay device on the second communication path; The control device according to claim 11 .

14. The control device according to claim 13, characterized in that the control means makes a decision based on the first reception strength and the second reception strength when the first status information further indicates the free space of a first communication buffer in a device between the control device and the relay device, the second status information further indicates the free space of a second communication buffer in a device between the other control device and the relay device, and both the free space of the first communication buffer and the free space of the second communication buffer exceed a predetermined value.

15. When the first status information indicates a first time required for signal propagation between the control device and a device included in the communication path from the control device to the relay device, and the second status information indicates a second time required for signal propagation between the other control device and a device included in the communication path from the other control device to the relay device, the control means determining, based on the first time period being shorter than the second time period, to perform communication by preferentially using a communication path between the control device and the relay device in the first communication path; determining, based on the first time period being longer than the second time period, to perform communication by preferentially using a communication path between the other control device and the relay device on the second communication path; The control device according to claim 11 .

16. 16. The control device according to claim 15, wherein the control means makes a decision based on the first time and the second time when the first status information further indicates the free space of a first communication buffer in a device between the control device and the relay device, the second status information further indicates the free space of a second communication buffer in a device between the other control device and the relay device, and both the free space of the first communication buffer and the free space of the second communication buffer exceed a predetermined value.

17. 17. The control device according to claim 11, wherein the control means determines not to use the communication path in which a radio link failure (RLF) has occurred when the first status information identifies whether or not a radio link failure (RLF) has occurred in a link between the control device and a device included in the communication path from the control device to the relay device, and the second status information identifies whether or not an RLF has occurred in a link between the other control device and a device included in the communication path from the other control device to the relay device.

18. A control device as described in any one of claims 11 to 17, characterized in that when the first status information indicates that no radio link failure (RLF) has occurred in the link between the control device and a device included in the communication path from the control device to the relay device, and the free space in the communication buffer in the communication path exceeds a predetermined value, the control means decides to use the communication path between the control device and the relay device in the first communication path.

19. 19. The control device according to claim 1, wherein the control device and the other control device are IAB donors in an Integrated Access and Backhaul (IAB) of the 3rd Generation Partnership Project (3GPP), and the relay device is an IAB node.

20. A control method executed by a control device, comprising: monitoring a communication path from the control device to a relay device included in a first communication path managed by the control device, and acquiring first status information regarding the communication path; When the relay device is included in a second communication path managed by another control device, acquiring second status information related to a communication path from the other control device to the relay device among the second communication paths managed by the other control device from the other control device; controlling communication of the relay device based on the first status information and the second status information; Including, A control method characterized in that, in acquiring the first status information, a message confirming status information is sent to a device included in a communication path from the control device to the relay device in the first communication path, and the first status information is acquired by receiving a response to the message.

21. A program for causing a computer to function as the control device according to any one of claims 1 to 19.

Images