Communication control method, relay node, communication system, program, and chip set

Abstract

To provide a communication control method, a relay node, a communication system, a program, and a chip set for use in a cellular communication system.SOLUTION: A communication control method is used in a cellular communication system. The communication control method includes: causing a donor node, which has a relay node subordinate thereto, to set the relay node (IAB node) for whether or not to notify a parent node of the relay node of flow control feedback information relating to a congestion state of each backhaul RLC (Radio Link Control) channel of the relay node; and causing the relay node to notify the parent node of the flow control feedback information in accordance with the setting.SELECTED DRAWING: Figure 12

Description

[Technical field]

[0001] The present disclosure relates to a communication control method, a relay node, a communication system, a program, and a chipset for use in a cellular communication system. [Background technology]

[0002] In the cellular communication system standardization project 3GPP (Third Generation Partnership Project) (registered trademark, hereinafter the same), the introduction of a new relay node called an IAB (Integrated Access and Backhaul) node is being considered (see, for example, "3GPP TS 38.300 V16.3.0 (2020-09)"). One or more relay nodes are involved in communication between a base station and a user device, and relay this communication. Summary of the Invention

[0003] A communication control method according to a first aspect is a communication control method used in a cellular communication system. The communication control method includes a donor base station having a relay node under its control, which sets, for the relay node, whether or not to cause a scheduler of the relay node to perform priority control in forwarding data packets. The communication control method also includes the relay node operating the scheduler according to the setting.

[0004] A communication control method according to a second aspect is a communication control method used in a cellular communication system. The communication control method includes a relay node transmitting, to a donor base station having the relay node under its control, first information indicating a throughput for each route, second information indicating a number of discarded data packets, or third information indicating that a failure occurrence notification has been received. The communication control method also includes the donor base station performing a predetermined operation based on the first information, the second information, or the third information.

[0005] A communication control method according to a third aspect is a communication control method used in a cellular communication system. The communication control method includes a relay node between a parent node and a child node transmitting a preemptive buffer status report to the parent node. The communication control method also includes the parent node receiving the preemptive buffer status report. The communication control method further includes, in the transmitting, the relay node storing a first data amount of first data residing in the child node and a second data amount of second data residing in the relay node in different areas of the preemptive buffer status report. [Brief description of the drawings]

[0006] [Figure 1] FIG. 1 is a diagram illustrating an example of the configuration of a cellular communication system according to an embodiment. [Diagram 2] FIG. 2 is a diagram showing the relationship between IAB nodes, parent nodes, and child nodes. [Diagram 3] FIG. 3 is a diagram illustrating an example configuration of a gNB (base station) according to one embodiment. [Figure 4] FIG. 4 is a diagram illustrating a configuration example of an IAB node (relay node) according to an embodiment. [Diagram 5] FIG. 5 is a diagram illustrating an example of a configuration of a UE (user equipment) according to an embodiment. [Figure 6] FIG. 6 is a diagram illustrating an example of a protocol stack related to an RRC connection and a NAS connection of an IAB-MT. [Figure 7] FIG. 7 is a diagram illustrating an example of a protocol stack for the F1-U protocol. [Figure 8] FIG. 8 is a diagram illustrating an example of a protocol stack for the F1-C protocol. [Figure 9] FIG. 9 is a diagram illustrating a setting example according to the first embodiment. [Figure 10] FIG. 10 is a diagram illustrating a setting example according to the first embodiment. [Figure 11] FIG. 11 is a diagram illustrating an example of operation according to the first embodiment. [Figure 12] FIG. 12 is a diagram illustrating an example of operation according to the first embodiment. [Figure 13] FIG. 13 is a diagram illustrating an example of operation according to the second embodiment. [Figure 14] FIG. 14 is a diagram illustrating an example of operation according to the third embodiment. [Figure 15] FIG. 15 is a diagram illustrating an example of transmission of a failure occurrence notification according to the fourth embodiment. [Figure 16] FIG. 16 is a diagram illustrating an example of operation according to the fourth embodiment. [Figure 17] FIG. 17(A) shows an example of normal BSR transmission, and FIG. 17(B) and FIG. 17(C) show examples of pre-emptive BSR transmission. [Figure 18] FIG. 18 illustrates an example of the configuration of a pre-emptive BSR MAC CE. [Figure 19] FIG. 19 is a diagram illustrating an example of the relationship between an IAB node, a parent node, and a child node. [Figure 20] FIG. 20 is a diagram illustrating an example of operation in the fifth embodiment. [Figure 21] FIG. 21 is a diagram illustrating an example of operation according to the sixth embodiment. [Figure 22] FIG. 22 is a diagram showing an example of transmission of a pre-emptive BSR and a normal BSR. [Figure 23] FIG. 23 is a diagram illustrating an example of operation according to the seventh embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0008] (Configuration of Cellular Communication System) First, a configuration example of a cellular communication system according to an embodiment will be described. The cellular communication system 1 according to an embodiment is a 3GPP 5G system. Specifically, the radio access method in the cellular communication system 1 is NR (New Radio), which is a 5G radio access method. However, LTE (Long Term Evolution) may be applied at least partially to the cellular communication system. Furthermore, the cellular communication system 1 may also be applied to future cellular communication systems such as 6G.

[0009] FIG. 1 is a diagram illustrating an example of the configuration of a cellular communication system 1 according to an embodiment.

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

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

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

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

[0014] Each gNB 200 is a fixed wireless communication node and manages one or more cells. A cell is used as a term indicating the smallest unit of a wireless communication area. A cell may be used as a term indicating a function or resource for performing wireless communication with a UE 100. A cell may be used without distinction from a base station, such as the gNB 200. One cell belongs to one carrier frequency.

[0015] Each gNB 200 is mutually connected to the 5GC 10 via an interface called an NG interface. In FIG. 1, two gNBs 200-1 and 200-2 connected to the 5GC 10 are illustrated.

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

[0017] The cellular communication system 1 supports IAB, which enables wireless relay of NR access using NR for backhaul. The donor gNB (or IAB donor, hereinafter sometimes referred to as "IAB donor") 200-1 is a terminal node of the NR backhaul on the network side, and is a donor base station with additional functions that support IAB. The backhaul can be multi-hopped via multiple hops (i.e., multiple IAB nodes 300).

[0018] FIG. 1 illustrates an example in which an IAB node 300-1 wirelessly connects to an IAB donor 200-1, an IAB node 300-2 wirelessly connects to an IAB node 300-1, and the F1 protocol is transmitted over two backhaul hops.

[0019] The UE 100 is a mobile wireless communication device that performs wireless communication with a cell. The UE 100 may be any device that performs wireless communication with the gNB 200 or the IAB node 300. For example, the UE 100 is a mobile phone terminal, a tablet terminal, a laptop PC, a sensor or a device provided in a sensor, and / or a vehicle or a device provided in a vehicle. The UE 100 wirelessly connects to the IAB node 300 or the gNB 200 via an access link. FIG. 1 shows an example in which the UE 100 is wirelessly connected to the IAB node 300-2. The UE 100 indirectly communicates with the IAB donor 200-1 via the IAB node 300-2 and the IAB node 300-1.

[0020] FIG. 2 is a diagram showing the relationship between the IAB node 300, parent nodes, and child nodes.

[0021] As shown in FIG. 2, each IAB node 300 has an IAB-DU corresponding to a base station function unit and an IAB-MT (Mobile Termination) corresponding to a user equipment function unit.

[0022] An adjacent node (i.e., an upper node) on the NR Uu radio interface of the IAB-MT is called a parent node. The parent node is a parent IAB node or a DU of the IAB donor 200. The radio link between the IAB-MT and the parent node is called a backhaul link (BH link). FIG. 2 shows an example in which the parent nodes of the IAB node 300 are IAB nodes 300-P1 and 300-P2. The direction toward the parent node is called upstream. From the perspective of the UE 100, the upper node of the UE 100 may correspond to the parent node.

[0023] Adjacent nodes (i.e., lower nodes) on the NR access interface of the IAB-DU are called child nodes. The IAB-DU manages cells, similar to the gNB 200. The IAB-DU terminates the NR Uu radio interface to the UE 100 and the lower IAB nodes. The IAB-DU supports the F1 protocol to the CU of the IAB donor 200-1. In FIG. 2, an example is shown in which the child nodes of the IAB node 300 are the IAB nodes 300-C1 to 300-C3, but the child nodes of the IAB node 300 may include the UE 100. The direction toward the child nodes is called downstream.

[0024] Moreover, all the IAB nodes 300 connected to the IAB donor 200 via one or more hops form a directed acyclic graph (DAG) topology (hereinafter, sometimes referred to as "topology") with the IAB donor 200 as the root. In this topology, as shown in Fig. 2, adjacent nodes on the IAB-DU interface are child nodes, and adjacent nodes on the IAB-MT interface are parent nodes. The IAB donor 200, for example, centralizes the management of resources, topology, routes, etc. of the IAB topology.

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

[0026] The wireless communication unit 210 performs wireless communication with the UE 100 and wireless communication with the IAB node 300. The wireless communication unit 210 has a receiving unit 211 and a transmitting unit 212. The receiving unit 211 performs various receptions under the control of the control unit 230. The receiving unit 211 includes an antenna, and converts (down-converts) a wireless signal received by the antenna into a baseband signal (received signal) and outputs the signal to the control unit 230. The transmitting unit 212 performs various transmissions under the control of the control unit 230. The transmitting unit 212 includes an antenna, and converts (up-converts) a baseband signal (transmitted signal) output by the control unit 230 into a wireless signal and transmits the signal from the antenna.

[0027] The network communication unit 220 performs wired communication (or wireless communication) with the 5GC10 and wired communication (or wireless communication) with other adjacent gNBs 200. The network communication unit 220 has a receiving unit 221 and a transmitting unit 222. The receiving unit 221 performs various receptions under the control of the control unit 230. The receiving unit 221 receives a signal from the outside and outputs the received signal to the control unit 230. The transmitting unit 222 performs various transmissions under the control of the control unit 230. The transmitting unit 222 transmits the transmission signal output by the control unit 230 to the outside.

[0028] The control unit 230 performs various controls in the gNB 200. The control unit 230 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation / demodulation and encoding / decoding of a baseband signal. The CPU executes programs stored in the memory to perform various processing. The processor performs processing of each layer, which will be described later. Furthermore, the control unit 230 may perform each processing in the gNB 200 in each of the embodiments shown below.

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

[0030] The wireless communication unit 310 performs wireless communication (BH link) with the gNB 200 and wireless communication (access link) with the UE 100. The wireless communication unit 310 for BH link communication and the wireless communication unit 310 for access link communication may be provided separately.

[0031] The wireless communication unit 310 has a receiving unit 311 and a transmitting unit 312. The receiving unit 311 performs various receptions under the control of the control unit 320. The receiving unit 311 includes an antenna, and converts (down-converts) a wireless signal received by the antenna into a baseband signal (received signal), and outputs the signal to the control unit 320. The transmitting unit 312 performs various transmissions under the control of the control unit 320. The transmitting unit 312 includes an antenna, and converts (up-converts) a baseband signal (transmitted signal) output by the control unit 320 into a wireless signal, and transmits the signal from the antenna.

[0032] The control unit 320 performs various controls in the IAB node 300. The control unit 320 includes at least one memory and at least one processor electrically connected to the memory. The memory stores a program executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of a baseband signal. The CPU executes a program stored in the memory to perform various processing. The processor performs processing of each layer, which will be described later. The control unit 320 may also perform each processing in the IAB node 300 in each of the embodiments shown below.

[0033] (Configuration of user device) Next, a configuration of the UE 100 which is a user device according to the embodiment will be described. Fig. 5 is a diagram illustrating an example of the configuration of the UE 100. As shown in Fig. 5, the UE 100 includes a radio communication unit 110 and a control unit 120.

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

[0035] The control unit 120 performs various controls in the UE 100. The control unit 120 includes at least one memory and at least one processor electrically connected to the memory. The memory stores a program executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of a baseband signal. The CPU executes a program stored in the memory to perform various processing. The processor performs processing of each layer, which will be described later. The control unit 130 may also perform each processing in the UE 100 in each of the following embodiments.

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

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

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

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

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

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

[0042] The RRC layer controls logical channels, transport channels, and physical channels according to the establishment, re-establishment, and release of radio bearers. RRC signaling for various settings is transmitted between the RRC layer of the IAB-MT of the IAB node 300-2 and the RRC layer of the IAB donor 200. When there is an RRC connection with the IAB donor 200, the IAB-MT is in an RRC connected state. When there is no RRC connection with the IAB donor 200, the IAB-MT is in an RRC idle state.

[0043] The NAS layer, which is located above the RRC layer, performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of the IAB-MT of the IAB node 300-2 and the AMF 11.

[0044] Figure 7 shows a protocol stack for the F1-U protocol. Figure 8 shows a protocol stack for the F1-C protocol. Here, an example is shown in which an IAB donor 200 is divided into a CU and a DU.

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

[0046] In each backhaul link, PDUs (Protocol Data Units) of the BAP layer are transmitted by a backhaul RLC channel (BH NR RLC channel). Each BH link configures multiple backhaul RLC channels, which allows for traffic prioritization and QoS control. The association between BAP PDUs and backhaul RLC channels is performed by the BAP layer of each IAB node 300 and the BAP layer of the IAB donor 200.

[0047] In addition, the CU of the IAB donor 200 terminates the F1 interface to the IAB node 300 and the DU of the IAB donor 200, and is the gNB-CU function of the IAB donor 200. In addition, the DU of the IAB donor 200 hosts the IAB BAP sublayer, provides wireless backhaul to the IAB node 300, and is the gNB-DU function of the IAB donor 200.

[0048] As shown in FIG. 8, the protocol stack of the F1-C protocol has an F1AP layer and a Stream Control Transmission Protocol (SCTP) layer instead of the GTP-U layer and UDP layer shown in FIG.

[0049] In the following, the processing or operation performed by the IAB-DU and IAB-MT of the IAB may be simply described as the processing or operation of the "IAB." For example, the transmission of a BAP layer message by the IAB-DU of the IAB node 300-1 to the IAB-MT of the IAB node 300-2 will be described as the IAB node 300-1 transmitting the message to the IAB node 300-2. In addition, the processing or operation of the DU or CU of the IAB donor 200 may be simply described as the processing or operation of the "IAB donor."

[0050] Also, the upstream direction and the uplink (UL) direction may be used interchangeably, and the downstream direction and the downlink (DL) direction may be used interchangeably.

[0051] (First embodiment) In IAB, there is a concept of topology-wide fairness (hereinafter, sometimes referred to as "fairness"). Fairness provides a mechanism for managing Quality of Service (QoS) so that the QoS required in the entire topology is satisfied, regardless of where UE 100 connects to in the IAB network. For example, in FIG. 1, fairness can be said to mean managing the entire topology so that UE 100 obtains the same QoS whether it connects to IAB node 300-2 or IAB donor 200-1.

[0052] Approaches to such fairness can be divided into two categories, for example:

[0053] (A1) Local / distributed fairness optimization

[0054] (A2) Centralized fairness optimization

[0055] For example, (A1) is performed by the scheduler of each IAB node 300. The IAB node 300 can achieve optimization such as (A1) by providing information such as the number of remaining hops to the scheduler.

[0056] On the other hand, (A2) is performed, for example, by updating the routing settings by the IAB donor 200. The IAB node 300 reports information such as congestion status and / or delay information to the IAB donor 200, thereby enabling the routing settings to be updated.

[0057] Although (A1) has the advantage of being able to achieve higher speeds, the advantage is limited to local connections and may vary depending on the implementation of the scheduler. Also, (A2) can solve the optimization of the entire topology, but may not be able to solve fairness on a packet-by-packet basis.

[0058] Therefore, one approach to fairness is to mix (A1) and (A2). By mixing the two, it is possible to enjoy the benefits of (A1) and (A2) and minimize the disadvantages of (A1) and (A2).

[0059] The first embodiment is an example in which, in such a mixed case, the IAB donor 200 specifies to the IAB node 300 whether or not to perform (A1). Specifically, first, a donor base station (e.g., the IAB donor 200) having a relay node (e.g., the IAB node 300) under its control sets to the relay node whether or not to cause the scheduler of the relay node to perform priority control in forwarding data packets. Second, the relay node operates the scheduler in accordance with the setting. Hereinafter, priority control in forwarding data packets may be simply referred to as data packet forwarding control.

[0060] FIG. 9 is a diagram showing an example in which the IAB donor 200 sets, for the IAB node 300-T, whether or not to cause the scheduler of the IAB node 300-T to control the forwarding of data packets. The forwarding control of data packets is, for example, an example of control regarding fairness. By such a setting, for example, the IAB donor 200 can specify whether or not to cause the IAB node 300-T to control regarding fairness (hereinafter, sometimes referred to as "fairness control"). This makes it possible to specify the above (A1).

[0061] FIG. 11 is a diagram illustrating an example of operation according to the first embodiment.

[0062] When the IAB donor 200 starts processing in step S10, in step S11, it sets whether or not to cause the IAB node 300-T to perform fairness control for the IAB. Specific examples of fairness control include the following.

[0063] (B1) Prioritize the transfer of data packets that have passed through a large number of (past) hops. This allows, for example, data packets with large delays to be transferred with priority, making it possible to achieve the above-mentioned fairness.

[0064] (B2) Prioritize the transfer of data packets with a large number of remaining hops (in the future). In this case, as in (B1), data packets with large delays are transferred preferentially, making it possible to achieve fairness.

[0065] (B3) Prioritize the transfer of data packets with a large number of UE bearers multiplexed per BH RLC channel ("N" in 1:N mapping). This allows, for example, data packets with a large amount of data to be transferred with priority, thereby reducing transfer delays caused by large amounts of data and achieving the above-mentioned fairness.

[0066] (B4) Prioritize the transfer of data packets with a long elapsed time based on a timestamp. This allows, for example, data packets with a long elapsed time based on a certain time to be transferred with priority, thereby reducing transfer delays and achieving fairness.

[0067] The IAB donor 200 may set the fairness control by combining the above (B1) to (B4). The IAB donor 200 may set the UE bearer ID or the BH RLC channel ID to be excluded from such fairness control in the IAB node 300-T. Furthermore, the IAB donor 200 may set the fairness control for the IAB node 300 by transmitting an RRC message, an F1-AP message, or a MAC CE to the IAB node 300-T.

[0068] In step S12, the IAB node 300-T operates the scheduler according to the settings. That is, the IAB-DU (scheduler) of the IAB node 300-T controls the transfer of data packets according to the settings in (B1) to (B4) above. Specifically, the process is as follows.

[0069] For example, the header of the BAP Data PDU includes a hop count that is incremented each time the packet passes through an IAB node 300. When the above (B1) is set, the scheduler transfers a data packet having a larger number of hops on the basis of the hop count.

[0070] For example, the header of the BAP Data PDU includes the number of hops to the target, and the number of hops is decremented each time the packet passes through an IAB node 300. When the above (B2) is set, the scheduler prioritizes the transfer of a data packet with a large number of remaining hops based on the number of hops.

[0071] When the above (B3) is set, the scheduler checks the number of bearers multiplexed for each UE 100 per BH RLC channel, and transfers data packets with a large number of bearers multiplexed with priority.

[0072] When the above (B4) is set, the scheduler transfers data packets with a longer elapsed time preferentially, based on the timestamp value included in the header of the BAP Data PDU.

[0073] In step S13, the IAB node 300 ends the series of processes.

[0074] In the above-described embodiment, an example of fairness control (priority control) by a scheduler is shown, but the present invention is not limited to this. Fairness control may also be performed in routing processing. Specifically, in the BAP layer, a packet that should be prioritized (e.g., a packet with a large number of remaining hops) is prioritized in routing processing. In other words, the BAP layer passes (or transfers) the prioritized packet to a lower layer (e.g., an RLC layer) before (or earlier than) other packets. In this case, it should be noted that, as in the above-described embodiment, the IAB donor 200 sets the IAB node 300 regarding fairness control, and the IAB node 300 can perform routing processing according to the setting.

[0075] Another example of the first embodiment will be described.

[0076] In another example of the first embodiment, first, a donor base station (e.g., IAB donor 200) sets a relay node (e.g., IAB node 300) as to whether or not to notify the parent node or child node of assist information. The assist information is information for controlling the forwarding of data packets in a scheduler of the parent node or child node of the relay node. Second, the relay node notifies the parent node or child node of the assist information according to the setting.

[0077] 10 is a diagram showing an example of setting whether the IAB donor 200 notifies the IAB node 300-T of the assist information. With such a setting, the parent node 300-P or the child node 300-C of the IAB node 300-T can execute fairness control based on the assist information. Therefore, with such a setting, the IAB donor 200 can (indirectly) specify the above (A1) to (the scheduler of) the parent node 300-P or the child node 300-C of the IAB node 300-T.

[0078] FIG. 12 is a diagram illustrating an example of operation according to another example of the first embodiment.

[0079] When the IAB donor 200 starts processing in step S20, in step S21, the IAB node 300-T is configured as to whether or not to notify the parent node 300-P or child node 300-C of the IAB node 300-T of the scheduling assist information. The configuration is performed using an RRC message, an F1-AP message, or the like.

[0080] The assist information may be information included in the header of the BAP Data PDU and may be information that changes every time the IAB node 300 passes through. Such information may be, for example, a hop count value or a timestamp value for measuring transfer latency. The assist information may also be congestion information such as a flow control feedback message. The flow control feedback message is, for example, a message used to notify the parent node 300-P or the child node 300-C of congestion when the IAB node 300-T is congested.

[0081] In step S22, the IAB node 300-T notifies the parent node 300-P or the child node 300-C of the assist information according to the setting. The scheduler of the parent node 300-P or the child node 300-C performs fairness control (for example, all or part of (B1) to (B4)) based on the assist information.

[0082] In step S23, the IAB node 300-T ends the series of processes.

[0083] In another example of the first embodiment, the assist information is provided from the IAB node 300-T to the parent node 300-P or the child node 300-C, but the present invention is not limited to this. The assist information may be provided from the IAB donor 200 to the IAB node 300-T, and the IAB node 300-T that receives the assist information may perform fairness control. In this case, the assist information may be the remaining hop count, the number of UE bearers, priority information (e.g., QoS setting information), forwarding delay information (e.g., actual average latency for a certain period of time), and / or congestion degree information (e.g., load, usage rate or margin of wireless resources) for each BH RLF channel or each routing ID. The assist information may be information aggregated by the IAB donor 200 in the second embodiment.

[0084] Second embodiment Regarding fairness, when the approach (A2) described in the first embodiment is adopted, it is better to aggregate information of the IAB nodes 300 to the IAB donor 200 as much as possible. This is because the IAB donor 200 is the one that grasps the fairness of the entire topology, and the IAB donor 200 can play a central role in realizing fairness.

[0085] In the second embodiment, first, a relay node (e.g., IAB node 300) transmits first information indicating the throughput for each route to a donor base station (e.g., IAB donor 200) that has the relay node under its control. Second, the donor base station performs a predetermined operation based on the first information. As the predetermined operation, the IAB donor 200 updates the routing setting. Thereby, for example, the IAB donor 200 can achieve fairness by updating the routing setting through the above approach (A2).

[0086] FIG. 13 is a diagram illustrating an example of operation according to the second embodiment.

[0087] When the IAB node 300 starts processing in step S30, it notifies the IAB donor 200 of throughput information for each route in step S31.

[0088] In the DL direction, the link state of the BH link between the IAB node 300 and its child node or the access link between the IAB node 300 and the UE 100 is represented as the throughput. In this case, the IAB node 300 may report the throughput. On the other hand, in the UL direction, the link state of the BH link between the IAB node 300 and its parent node is represented as the throughput. In this case, the parent node may report the throughput.

[0089] The throughput information may be expressed as at least one of the maximum throughput and the minimum throughput of the BH link or the access link. The throughput information may be a theoretical value and / or an effective value. The throughput information may also be an average throughput in a certain period of time. The certain period of time (e.g., the past 10 seconds) may be set by the IAB donor 200. The throughput information may be the throughput for each path instead of the throughput information for each route.

[0090] In addition, as in step S31, the IAB node 300 reports the throughput information, so that the IAB node 300 can report to the IAB donor 200 an accurate throughput according to the implementation of the scheduler of the IAB node 300 or the load status of the scheduler.

[0091] In step S32, the IAB donor 200 updates the routing settings based on the throughput information.

[0092] In step S33, the IAB donor 200 ends the series of processes.

[0093] Third embodiment One of the QoS characteristics of 5G is the Packet Delay Budget (PDB). The PDB represents the upper limit of the time that a packet is delayed between the UE 100 and the UPF 12. Packets that are delayed beyond the PDB may be discarded at local discretion. By setting the PDB, the scheduler can avoid having to process unexpected values.

[0094] In this way, the packet discard by the PDB is performed locally, and therefore the IAB donor 200 cannot detect the packet discard.

[0095] Therefore, in the third embodiment, when the IAB node 300 discards a packet, it reports the number of discarded packets to the IAB donor 200. Specifically, first, a relay node (e.g., the IAB node 300) transmits second information indicating the number of discarded data packets to a donor base station (e.g., the IAB donor 200) having the relay node under its control. Second, the donor base station performs a predetermined operation based on the second information. As a result, for example, the IAB donor 200 can detect packet discard in the IAB node 300 and update routing settings, thereby realizing fairness by the approach of (A2) above.

[0096] FIG. 14 is a diagram illustrating an example of operation according to the third embodiment.

[0097] In step S40, the IAB node 300 starts processing, and in step S41, a valid period for packet forwarding is set by the IAB donor 200. The setting is performed using, for example, an RRC message and / or an F1-AP message.

[0098] In step S42, when receiving a data packet, the IAB node 300 determines whether the data packet is within the validity period. For example, the IAB node 300 calculates the delay time of the data packet based on the time stamp information included in the header of the BAP Data PDU, and compares it with the set validity period. In this way, the IAB node 300 determines whether the delay time is within the validity period. If the time stamp information is expressed as time information at the time of transmitting the data packet in the source, the IAB node 300 may compare the current time with the time stamp information to calculate the delay time.

[0099] If the data packet is not within the validity period in step S43 (NO in step S43), the IAB node 300 discards the data packet in step S44. At this time, the IAB node 300 counts the number of discarded data packets and stores the count value and associated information as recorded information in a memory or the like. The associated information includes, for example, an ingress BH RLC channel ID, a routing ID (or a destination ID, or a path ID), and / or a delay time (the delay at the time of receiving the data packet).

[0100] In step S45, the IAB node 300 reports the record information to the IAB donor 200. For example, the IAB node 300 reports when the number of discarded packets becomes equal to or greater than a certain number (within a certain period of time). Alternatively, the IAB node 300 may report at regular intervals. Alternatively, the IAB node 300 may report when a request is received from the IAB donor 200. The IAB node 300 may report the record information to the IAB donor 200 by using a BAP message or the like.

[0101] In step S46, the IAB node 300 ends the series of processes. Note that the IAB donor 200 performs a predetermined operation, such as updating the routing settings, based on the recorded information.

[0102] On the other hand, in step S43, if the data packet is within the validity period (YES in step S43), the IAB node 300 forwards the received data packet to the next hop.

[0103] Then, in step S46, the IAB node 300 ends the series of processes.

[0104] (Fourth embodiment) FIG. 15 is a diagram showing an example in which the IAB node 300 transmits a failure occurrence notification message to the IAB donor 200. In FIG.

[0105] 15, it is assumed that a BH RLF (Back Haul Radio Link Failure) occurs in the BH link between parent node 300-P of IAB node 300 and upper node 300-U, which is its parent node. In this case, parent node 300-P notifies IAB node 300-T of a failure occurrence notification indicating that a BH RLF has occurred.

[0106] However, the failure occurrence notification is sent from parent node 300-P to IAB node 300-T, and not to IAB donor 200. Therefore, IAB donor 200 cannot detect that a BH RLF has occurred at parent node 300-P. If IAB donor 200 cannot detect the BH RLF at parent node 300-P, there is a risk that the performance of the entire topology will degrade (congestion, delays, etc.).

[0107] Therefore, in the fourth embodiment, when the IAB node 300 receives a failure occurrence notification, it reports the reception to the IAB donor 200. Specifically, first, a relay node (e.g., the IAB node 300) transmits third information indicating that the failure occurrence notification has been received to a donor base station (e.g., the IAB donor 200) that has the relay node under its control. Second, the donor base station performs a predetermined operation based on the third information. As the predetermined operation, for example, the IAB donor 200 updates the routing setting. This makes it possible to prevent, for example, a performance degradation of the entire topology. Also, for example, it is possible to realize fairness by the approach of (A2) above by having the IAB donor 200 aggregate information.

[0108] The failure occurrence notification includes a Type 1 Indication (RLF detected) of the BH RLF. The Type 1 Indication is an indication that the IAB-DU of the parent node 300-P notifies the IAB node 300-T (or the UE 100) when it detects a BH RLF. The failure occurrence notification also includes a Type 2 Indication (Trying to recover) of the BH RLF. The Type 2 Indication is an indication that the IAB-DU of the parent node 300-P notifies the IAB-MT of the IAB node 300-T (or the UE 100) when it detects a recovery operation from the BH RLF. When the Type 1 Indication and the Type 2 Indication are not differentiated, the IAB-DU of the parent node 300-P can notify the IAB-MT of the IAB node 300-T (or the UE 100) of a Type 1 / 2 Indication. The Type 1 / 2 Indication is also an example of a failure occurrence notification.

[0109] 16 is a diagram illustrating an example of an operation according to the fourth embodiment. Note that, in the following, a Type 1 / 2 Indication will be described as an example of a failure occurrence notification, but a Type 1 Indication or a Type 2 Indication may also be used.

[0110] IAB node 300-T starts processing in step S50, and then receives a Type 1 / 2 Indication of the BH RLF from parent node 300-P in step S51.

[0111] In step S52, the IAB node 300-T notifies the IAB donor 200 that it has received the Type 1 / 2 Indication. The notification may include the cell ID of the parent node 300-P, the gNB ID of the parent node 300-P, and / or the BAP address of the parent node 300-P.

[0112] In addition, when the IAB node 300-T is connected to the parent node 300-P and other parent nodes by DC (Dual Connectivity), the transmission path of this notification may be, for example, as follows. That is, when the IAB node 300-T receives a Type1 / 2 Indication via an MCG (Master Cell Group), it may transmit the notification via an SCG (Secondary Cell Group) (SRB (Signaling Radio Bearer) 3). Or, when the IAB node 300-T receives a Type1 / 2 Indication via an SCG, it may transmit the notification via an MCG (SRB1). Or, the IAB node 300-T may transmit the notification via a Split SRB1.

[0113] In step S53, in response to receiving the Type 1 / 2 Indication, the IAB donor 200 recognizes that the BH RLF has occurred in the parent node 300-P and performs a predetermined operation, such as updating the routing setting, instructing the IAB node 300-T to perform local rerouting, or performing a handover for the IAB node 300-T.

[0114] In step S54, the IAB node 300 ends the series of processes.

[0115] In the above operation example, instead of the Type 1 / 2 Indication, a Type 3 Indication, a Type 4 Indication, or a flow control feedback message may be used.

[0116] Type 3 Indication (RLF recovered) is a failure recovery notification sent to the IAB node 300-T when the parent node 300-P recovers from the BH RLF. Type 4 Indication (Recovery failure) is an example of a recovery failure notification sent to the IAB node 300-T when the parent node 300-P fails to recover from the BH RLF. The failure recovery notification and recovery failure notification are, for example, notifications regarding a wireless link failure in the BH link.

[0117] Moreover, the flow control feedback message is a message notified from the parent node 300-P when, for example, congestion of data packets occurs in the parent node 300-P.

[0118] Fifth embodiment Regarding UL direction scheduling, a pre-emptive buffer status report (hereinafter, sometimes referred to as "pre-emptive BSR") may be performed. Here, the pre-emptive BSR will be described.

[0119] (pre-emptive BSR) FIG. 17A shows an example of transmission of a regular BSR, and FIG. 17B and FIG. 17C show examples of transmission of a pre-emptive BSR.

[0120] 17(A), after receiving data from child node 300-C, IAB node 300-T transmits a normal BSR to parent node 300-P. Based on the BSR, parent node 300-P performs scheduling for IAB node 300-T and transmits a UL grant to IAB node 300-T.

[0121] On the other hand, as shown in FIG. 17(B), after transmitting a UL grant to the child node 300-C, the IAB node 300-T transmits a pre-emptive BSR to the parent node 300-P before receiving data from the child node 300-C.

[0122] Furthermore, as shown in FIG. 17(C), after receiving a BSR from the child node 300-C, the IAB node 300-T transmits a pre-emptive BSR to the parent node 300-P before transmitting a UL grant to the child node 300-C.

[0123] In this way, the pre-emptive BSR is transmitted to the parent node 300-P at an earlier timing than the normal BSR, so that it is possible to reduce the delay in UL scheduling in the IAB node 300-T.

[0124] The pre-emptive BSR is transmitted using the MAC CE in the same manner as the normal BSR. Fig. 18 is a diagram showing a configuration example of the pre-emptive BSR MAC CE (hereinafter, sometimes referred to as "pre-emptive BSR"). As shown in Fig. 18, the pre-emptive BSR MAC CE includes each area of ​​LCGi and buffer size.

[0125] LCGi is an area indicating the presence of a buffer size for logical channel group (LCG) i. That is, when "1" is set in LCGi, it indicates that the buffer size for logical channel group (LCG) i is reported. On the other hand, when "0" is set in LCGi, it indicates that the buffer size for logical channel group i is not reported.

[0126] The buffer size identifies the total amount of data expected to arrive at the IAB-MT of the IAB node 300 for which a pre-emptive BSR was triggered, and does not include the total amount of data currently available at the IAB-MT. The buffer size is described in more detail below.

[0127] FIG. 19 is a diagram showing an example of the relationship between the IAB node 300, the parent node 300-P, and the child node 300-C. FIG. 19 shows an example in which the IAB node 300-T transmits a pre-emptive BSR to the parent node 300-P. In the example of FIG. 19, the buffer size area stores the total amount of data expected to arrive at the IAB-MT of the parent node 300-P in which the pre-emptive BSR is triggered. The data expected to arrive at the IAB-MT of the parent node 300-P is the total amount of data staying in the IAB-DU of the IAB node 300-T and data staying in the IAB-MT of the child node 300-C. In other words, the buffer size stored in the buffer size area of ​​the pre-emptive BSR is the amount of data that is a mixture of data staying in the IAB-DU of the IAB node 300-T and data staying in the IAB-MT of the child node 300-C.

[0128] However, the scheduling timing of the data residing in the IAB-DU of the IAB node 300-T is different from the scheduling timing of the data residing in the IAB-MT of the child node 300-C. Therefore, even if the parent node 300-P receives a pre-emptive BSR, it may not know at what timing to schedule the two pieces of data with different scheduling timings.

[0129] Therefore, in the fifth embodiment, the IAB node 300-T stores the amount of data accumulated in its own IAB-DU and the amount of data accumulated in the IAB-MT of the child node 300-C in different buffer size areas of the pre-emptive BSR. Then, the IAB node 300-T transmits the pre-emptive BSR to the parent node 300-P.

[0130] Specifically, first, a relay node (e.g., IAB node 300) between a parent node (e.g., parent node 300-P) and a child node (e.g., child node 300-C) transmits a preemptive buffer status report (pre-emptive BSR) to the parent node. At this time, the relay node stores a first data amount of the first data residing in the child node in a first buffer size area of ​​the pre-emptive BSR. In addition, the relay node stores a second data amount of the second data residing in the relay node in a second buffer size area of ​​the pre-emptive BSR. Second, the parent node receives the pre-emptive BSR. As a result, for example, the parent node 300-P can receive a pre-emptive BSR in which the first data amount and the second data amount are stored in different areas, and therefore it becomes possible to perform scheduling for the first data and the second data at different timings.

[0131] FIG. 20 is a diagram illustrating an example of the operation of the fifth embodiment.

[0132] When the IAB node 300-T starts processing in step S60, it triggers a pre-emptive BSR in step S61.

[0133] In step S62, the IAB node 300-T stores the amount of data remaining in the IAB-MT of the child node 300-C in the BS (Buffer Size) #1 area of ​​the pre-emptive BSR MAC CE, and stores the amount of data remaining in its own (IAB-DU) in the BS #2 area. At this time, the IAB node 300-T identifies the amount of data remaining in the child node 300-C. The amount of data may be identified from the buffer size included in the BSR received from the child node 300-C, or from the UL grant value scheduled by the IAB node 300-T for the child node 300-C. The IAB node 300-T also identifies the amount of data remaining in its own IAB-DU. The amount of data may be identified from the amount of data of the receiving MAC SDU, the receiving RLC PDU, and / or the receiving BAP PDU (which may include the transmitting BAP PDU) remaining in the IAB node 300-T, for example. It should be noted that BS#1 and BS#2 are separate buffer size regions in the MAC CE.

[0134] In step S63, the IAB node 300-T transmits a pre-emptive BSR MAC CE including BS#1 and BS#2 to the parent node 300-P.

[0135] In step S64, the IAB node 300-T ends the series of processes.

[0136] In step S63, an example in which BS#1 and BS#2 are included in one pre-emptive BSR MAC CE has been described, but BS#1 and BS#2 may be included in different pre-emptive BSR MAC CEs. In this case, the IAB node 300-T transmits a pre-emptive BSR MAC CE including BS#1 and a pre-emptive BSR MAC CE including BS#2.

[0137] Also, the pre-emptive BSR MAC CE shown in Fig. 18 is just an example. For example, the pre-emptive BSR MAC CE may be a pre-emptive BSR MAC CE of any configuration as long as it is a MAC CE that includes a buffer size area.

[0138] Sixth embodiment The sixth embodiment is an example in which the amount of data residing in the IAB-DU of an IAB node 300-T and the amount of data residing in the IAB-MT of a child node 300-C are distinguished by using the LCGi of a pre-emptive BSR.

[0139] Specifically, first, a donor base station (e.g., IAB donor 200) having a subordinate relay node (e.g., IAB node 300-T) sets a first logical channel group for the relay node. Second, the relay node stores a first data amount of the first data residing in a child node of the relay node in a buffer size area corresponding to the first logical channel group, which is a third buffer size area of ​​the preemptive buffer status report.

[0140] FIG. 21 is a diagram illustrating an example of operation according to the sixth embodiment.

[0141] In step S70, the IAB donor 200 begins the process.

[0142] In step S71, the IAB donor 200 configures an LCG for storing the BSR value (or buffer size value) of the child node 300-C for the IAB node 300-T. The configuration is performed using an RRC message, an F1-AP message, or the like. For example, the IAB donor 200 configures LCG0 (FIG. 18) as the LCG for storing the BSR value of the child node 300-C.

[0143] In step S72, the IAB node 300-T triggers a pre-emptive BSR.

[0144] In step S73, the IAB node 300-T stores the amount of data retained in the IAB-MT of the child node 300-C in a BS (e.g., BS#1) corresponding to the set LCG (e.g., LCG0). The data retained in the child node 300-C may be identified in the IAB node 300-T based on the BSR from the child node 300-C or the UL grant value to the child node 300-C, as in the fifth embodiment.

[0145] In step S74, the IAB node 300-T transmits a pre-emptive BSR MAC CE including the BS to the parent node 300-P.

[0146] In step S75, the IAB node 300-T ends the series of processes.

[0147] The above-described operation example is an example of transmitting the amount of data remaining in the child node 300-C. The amount of data remaining in the IAB-DU of the IAB node 300-T itself is transmitted, for example, as follows.

[0148] That is, the data residing in the IAB-DU of the IAB node 300-T is data that has already been received from the child node 300-C in the IAB node 300-T. The IAB node 300-T can determine which logical channel to use to transmit the data by comparing the data with the configured routing information. The IAB node 300-T can then identify the LCG (e.g., LCG1) corresponding to the logical channel, and store the data residing in the IAB-DU of the IAB node 300-T in the BS (e.g., BS#2) corresponding to the LCG.

[0149] Such processing is performed, for example, in step S73 of the operation example shown in Fig. 21. That is, the IAB node 300-T stores the amount of data residing in the IAB-MT of the child node 300-C in a BS (e.g., BS#1) corresponding to the LCG set by the IAB donor 200. The IAB node 300-T stores the amount of data residing in its own IAB-DU in a BS (e.g., BS#2) corresponding to the LCG identified from the routing information.

[0150] In addition, the amount of data remaining in the child node 300-C may be stored in a BS (e.g., BS#3) corresponding to an LCG other than the LCG identified from the routing information, instead of the LCG setting by the IAB donor 200. That is, the IAB node 300 stores the amount of data remaining in the IAB-DU of the IAB node 300-T in a BS (e.g., BS#2) corresponding to the LCG (e.g., LCG1) identified from the routing information. On the other hand, the IAB node 300 stores the amount of data remaining in the IAB-MT of the child node 300-C in a BS (e.g., BS#3) corresponding to an LCG (e.g., LCG2) other than the LCG. Therefore, the IAB node 300-T can reliably store and transmit the amounts of two pieces of data in different buffer size areas in the pre-emptive BSR MAC CE.

[0151] Seventh embodiment The seventh embodiment is an example in which an IAB node 300-T reports the amount of data remaining in a child node 300-C by a pre-emptive BSR, and reports the amount of data remaining in an IAB node 300-T by a normal BSR.

[0152] FIG. 22 is a diagram showing an example in which the IAB node 300 transmits a pre-emptive BSR and a normal BSR to the parent node 300-P.

[0153] Currently, the normal BSR reports only the amount of data stored in the IAB-MT. However, since the data stored in the IAB-DU of the IAB node 300-T can also be sent immediately, it is better to send it using the normal BSR rather than the pre-emptive BSR.

[0154] Therefore, in the seventh embodiment, the IAB node 300-T reports the amount of data stored in its own IAB-MT and IAB-DU using a BSR. Also, the IAB node 300-T reports the amount of data stored in the IAB-MT of the child node 300-C using a pre-emptive BSR.

[0155] Specifically, a relay node (e.g., IAB node 300-T) transmits a first amount of the first data residing in a child node (e.g., child node 300-C) to a parent node (e.g., parent node 300-P) using a pre-emptive BSR. The relay node transmits a second amount of the second data residing in the relay node using a buffer status report.

[0156] FIG. 23 is a diagram illustrating an example of operation according to the seventh embodiment.

[0157] As shown in FIG. 23, in step S80, the IAB node 300-T starts the process.

[0158] In step S81, the IAB node 300-T triggers a normal BSR and a pre-emptive BSR.

[0159] In step S82, the IAB node 300-T identifies data residing in its own IAB-DU and IAB-MT, and stores the data in the BS of the normal BSR MAC CE. The IAB node 300-T identifies the amount of data residing in its own IAB-DU, for example, based on the sending and receiving BAP PDUs, the receiving RLC PDU, and / or the receiving MAC SDU. The IAB node 300-T also identifies the amount of data residing in its own IAB-MT, for example, based on the sending MAC SDU and / or the sending RLC PDU.

[0160] In step S82, the IAB node 300-T stores the amount of data remaining in the IAB-MT of the child node 300-C in the BS of the pre-emptive BSR MAC CE. The amount of data remaining in the child node 300-C is specified in the same manner as in the fifth embodiment, for example.

[0161] In step S83, the IAB node 300-T transmits a normal BSR MAC CE and a pre-emptive BSR MAC CE to the parent node 300-P.

[0162] In step S84, the IAB node 300-T ends the series of processes.

[0163] In accordance with this operation example, the buffer size of the pre-emptive BSR MAC CE specified in 3GPP TS38.321 is changed from "the total amount of data expected to arrive at the IAB-MT of the node where the pre-emptive BSR is triggered" to "the total amount of data expected to arrive at the IAB-DU of the node where the pre-emptive BSR is triggered."

[0164] In the operation example in FIG. 23, the IAB node 300-T may transmit the pre-emptive BSR MAC CE and the BSR MAC CE at different timings.

[0165] (Other embodiments) A program may be provided that causes a computer to execute each process performed by the UE 100, the gNB 200, or the IAB node 300. The program may be recorded in a computer-readable medium. Using the computer-readable medium, it is possible to install the program in the computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.

[0166] In addition, circuits that execute each process performed by the UE 100, the gNB 200, or the IAB node 300 may be integrated, and at least a part of the UE 100, the gNB 200, or the IAB node 300 may be configured as a semiconductor integrated circuit (chip set, SoC).

[0167] Although one embodiment has been described in detail above with reference to the drawings, the specific configuration is not limited to the above, and various design changes and the like are possible without departing from the scope of the invention. In addition, it is also possible to combine all or part of each embodiment as long as there is no contradiction.

[0168] This application claims priority to U.S. Provisional Application No. 63 / 136,472 (filed January 12, 2021), the entire contents of which are incorporated herein by reference.

[0169] (Additional Note) (introduction) A revised work item on Enhancements to Integrated Access and Backhaul (eIAB) for NR was approved. Some of the objectives are to:

[0170] Topology Adaptation Extensions Specification of procedures for inter-donor IAB node mobility to enhance robustness and load balancing, including enhancements to reduce signaling load. -Specify extensions to reduce service interruptions due to IAB node movement and BH RLF recovery. · Specification of extensions to topology redundancy, including support for CP / UP separation. Topology, Routing and Transport Enhancements Specification of extensions to improve fairness, multi-hop delays, and congestion mitigation across topologies.

[0171] Regarding topology, routing, and transport enhancements, the following agreement was reached:

[0172] R2 assumes that the Rel-17 IAB work will not define any new end-user QoS metrics on top of the existing 5G QoS framework. Rel-17 IAB work will include agreeing on a definition of fairness across topologies. Fairness across topology provides a mechanism to manage QoS such that the required QoS is met across the topology, regardless of where the UE is attached in the IAB network. Variations on this definition are not excluded. How the success of such a mechanism would be evaluated requires further study. · RAN2 will not discuss DLE 2E flow control extensions without input from RAN3. Further study is required as to whether RAN2 will deprioritize splitting radio bearer data to two or more paths. (RAN3 agreed to deprioritize multi-route support for data splitting in IAB)

[0173] This addendum discusses the Rel-17 IAB topology, routing, and transport extensions, focusing on BSR and preemptive BSR extensions, and a general framework for fairness across topologies.

[0174] (Discussion) (Extending BSR and Preemptive BSR) (LCG region expansion) In Rel-16, the number of LCGs for the UE, i.e. up to 8 LCGs, was reused for IAB-MT. Many companies suggested increasing the number of LCGs. Expanding the LCG area reduces the number of LCHs per LCG, which provides finer granularity in scheduling and seems to contribute to fairness across the topology. Therefore, RAN2 should increase the number of LCGs. This is applicable for both legacy and preemptive BSR.

[0175] Proposal 1: RAN2 should agree to increase the number of LCGs for BSR and preemptive BSR.

[0176] (Buffer size calculation) For legacy BSR, the buffer size calculation is clearly specified. It is based on the data available in MAC, RLC, and PDCP. For RLC and PDCP, the data volume calculation procedure is specified in each specification. In Rel-16, these mechanisms are reused in IAB-MT. However, IAB nodes have a BAP layer instead of PDCP, and there is no data volume calculation in BAP. Therefore, the current specification lacks data available for transmission. For better scheduling for fairness across the topology, the buffer size reported in legacy BSR should be more accurate.

[0177] Proposal 2: RAN2 should discuss whether to specify a procedure for calculating data volume for BAP.

[0178] In Rel-16, the calculation of the buffer size for preemptive BSR depends heavily on the implementation of IAB-DU, but the specification provides a rough guideline: "The buffer size field identifies the total amount of data expected to arrive at the IAB-MT of the node where the preemptive BSR is triggered, and does not include the amount of data currently available at the IAB-MT." Some IAB nodes may report a larger buffer size in the preemptive BSR than is actually expected to arrive. In some cases, such as multi-vendor deployments, it may be difficult to set up the same principle between child and parent nodes. This causes inefficient radio resource allocation, scheduling delays at the parent, and unfairness in resource requests between IAB-MTs. It may become more ambiguous when IAB nodes are configured with dual connectivity. Therefore, the calculation of the buffer size for preemptive BSR should be specified more precisely.

[0179] Proposal 3: RAN2 should specify the calculation of the buffer size for preemptive BSR.

[0180] (Fairness across the topology) Enhancing fairness across the topology can be categorized by two approaches: - Optimization of local / distributed fairness by schedulers, etc. - Optimizing centralized fairness by updating routing settings, etc.

[0181] Regarding local / distributed fairness optimization, for example, to optimize the scheduler algorithm, IAB nodes are provided with information such as profit metric, number of remaining hops, etc. We realize that some solutions are highly dependent on each scheduler implementation. It is only desirable to specify common / general information, if it exists, that may be useful for all implementations.

[0182] On the other hand, in centralized fairness optimization, IAB donors are reported with information or measurements such as congestion state, delay / latency, etc., to determine, for example, routing configuration updates. Thus, this approach can be considered a kind of MDT and SON.

[0183] In our view, these approaches have advantages and disadvantages. The localized / distributed approach may be a faster mechanism, but the benefits are limited within the local connection and may vary depending on the scheduler implementation. The centralized approach may solve topology-wide / large-scale optimization, but may not work for per-packet fairness. Therefore, RAN2 should discuss which (or both) approaches are more desirable to enforce topology-wide fairness.

[0184] Proposal 4: RAN2 should discuss whether fairness enforcement across the topology should be achieved through a local / distributed approach (e.g., by each scheduler), or a centralized approach (e.g., by IAB-donor-CU with routing configuration updates), or both.

Claims

1. A communication control method for use in a cellular communication system, comprising: A donor node having a relay node under its control sets whether or not to cause the relay node to notify a parent node of the relay node of flow control feedback information regarding a congestion state of each backhaul RLC (Radio Link Control) channel of the relay node; the relay node notifying the parent node of the flow control feedback information in accordance with the setting; A communication control method comprising the steps of:

2. There is a relay node under the donor node, A receiving unit that receives, from the donor node, setting information for setting whether or not to notify a parent node of the relay node of flow control feedback information regarding a congestion state of each backhaul RLC (Radio Link Control) channel of the relay node; a transmission unit that notifies the parent node of the flow control feedback information in accordance with the setting information. Relay node.

3. A communication system having a donor node and a relay node subordinate to the donor node, The relay node receives, from the donor node, setting information for setting whether to notify a parent node of the relay node of flow control feedback information regarding a congestion state of each backhaul RLC (Radio Link Control) channel of the relay node; The relay node notifies the parent node of the flow control feedback information according to the setting information. Communication systems.

4. To the relay node under the donor node, A process of receiving, from the donor node, setting information for setting whether or not to notify a parent node of the relay node of flow control feedback information regarding a congestion state of each backhaul RLC (Radio Link Control) channel of the relay node; and notifying the parent node of the flow control feedback information in accordance with the setting information. program.

5. A chipset for controlling a relay node under a donor node, A process of receiving, from the donor node, setting information for setting whether or not to notify a parent node of the relay node of flow control feedback information regarding a congestion state of each backhaul RLC (Radio Link Control) channel of the relay node; and notifying the parent node of the flow control feedback information in accordance with the setting information. Chipset.

Images