Communication control method, relay node, communication system, program, and chipset

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 used in a cellular communication system. [Background technology]

[0002] The Third Generation Partnership Project (3GPP) (registered trademark; the same applies hereinafter), a standardization project for cellular communication systems, is considering the introduction of a new relay node called an Integrated Access and Backhaul (IAB) node (see, for example, "3GPP TS 38.300 V16.3.0 (2020-09)"). One or more relay nodes intervene 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 subordinate thereto, configuring the relay node as to 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 in accordance with the configuration.

[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 that has the relay node under its control, first information indicating a throughput for each route, second information indicating the 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 located 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 transmitting step further includes the relay node storing a first amount of first data residing in the child node and a second amount of second data residing in the relay node in different areas of the preemptive buffer status report. [Brief explanation 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. [Figure 2] FIG. 2 is a diagram showing the relationship between IAB nodes, parent nodes, and child nodes. [Figure 3] FIG. 3 is a diagram illustrating an example configuration of a gNB (base station) according to one embodiment. [Figure 4] FIG. 4 is a diagram illustrating an example of the configuration of an IAB node (relay node) according to an embodiment. [Figure 5] FIG. 5 is a diagram illustrating an example of the configuration of a UE (user equipment) according to an embodiment. [Figure 6] FIG. 6 is a diagram illustrating an example of a protocol stack for 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 sending 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 INVENTION

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

[0008] (Configuration of a 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 apply 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] 1, the cellular communication system 1 includes a 5G core network (5GC) 10, user equipment (UE) 100, base station devices (hereinafter sometimes referred to as "base stations") 200-1 and 200-2, and IAB nodes 300-1 and 300-2. The base station 200 may be referred to as a gNB.

[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 about the area in which the UE 100 is located by communicating with the UE 100 using Non-Access Stratum (NAS) signaling. The UPF 12 is a device that performs transfer control of user data, etc.

[0014] Each gNB 200 is a fixed wireless communication node that manages one or more cells. The term cell is used to indicate the smallest unit of a wireless communication area. The term cell may also be used to indicate a function or resource for performing wireless communication with the UE 100. The term cell may also 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 interconnected with the 5GC 10 via an interface called an NG interface. Figure 1 illustrates two gNBs, gNB 200-1 and gNB 200-2, connected to the 5GC 10.

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

[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 the terminal node of the NR backhaul on the network side and is a donor base station with additional functions to support IAB. The backhaul can be multi-hop via multiple hops (i.e., multiple IAB nodes 300).

[0018] FIG. 1 illustrates an example in which IAB node 300-1 wirelessly connects with IAB donor 200-1, IAB node 300-2 wirelessly connects with 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 may be a mobile phone terminal, a tablet terminal, a laptop computer, 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 a cell, similar to the gNB 200. The IAB-DU terminates the NR Uu radio interface to the UE 100 and lower IAB nodes. The IAB-DU supports the F1 protocol to the CU of the IAB donor 200-1. While FIG. 2 shows an example in which the child nodes of the IAB node 300 are IAB nodes 300-C1 to 300-C3, the child nodes of the IAB node 300 may also include the UE 100. The direction toward the child nodes is called downstream.

[0024] Furthermore, all 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 Figure 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 centrally manages, for example, resources, topology, and route management of the IAB topology.

[0025] (Base station configuration) Next, the 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 configuration of the gNB 200. As shown in Fig. 3, the gNB 200 has a radio communication unit 210, a network communication unit 220, and a control unit 230.

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

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

[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 processing by the processor. The processor may include a baseband processor and a CPU (Central Processing Unit). The baseband processor performs modulation / demodulation, encoding / decoding, etc. of baseband signals. The CPU executes programs stored in the memory to perform various processes. The processor performs processing of each layer, which will be described later. Furthermore, the control unit 230 may be configured to perform each process in the gNB 200 in each of the embodiments shown below.

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

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

[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 programs executed by the processor and information used in processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processes. The processor performs processing of each layer, which will be described later. Furthermore, the control unit 320 may perform each process 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 equipment 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 radio communication unit 110 performs radio communication in the access link, i.e., radio communication with the gNB 200 and radio communication with the IAB node 300. The radio communication unit 110 may also perform radio communication in the side link, i.e., radio communication with another UE 100. The radio communication unit 110 has a receiving unit 111 and a transmitting unit 112. The receiving unit 111 performs various receptions under the control of the control unit 120. The receiving unit 111 includes an antenna, and converts (down-converts) a radio signal received by the antenna into a baseband signal (received signal), and outputs the signal to the control unit 120. The transmitting unit 112 performs various transmissions under the control of the control unit 120. The transmitting unit 112 includes an antenna, and converts (up-converts) a baseband signal (transmitted signal) output by the control unit 120 into a radio signal, and transmits the signal from the antenna.

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

[0036] (Protocol stack configuration) Next, the configuration of a protocol stack according to the 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 the IAB node 300-2 includes a physical (PHY) layer, a MAC (Medium Access Control) layer, and an RLC (Radio Link Control) layer. l ) 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 IAB node 300-2 and the PHY layer of the IAB-DU of 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 in IAB node 300-2 and the MAC layer of the IAB-DU in IAB node 300-1 via a transport channel. The MAC layer of the IAB-DU includes a scheduler, which determines the transport format (transport block size, modulation and coding scheme (MCS)) and allocated resource blocks for the uplink and downlink.

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

[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 the RRC connected state. When there is no RRC connection with the IAB donor 200, the IAB-MT is in the RRC idle state.

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

[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 the IAB donor 200 is divided into a CU and a DU.

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

[0046] In each backhaul link, BAP layer PDUs (Protocol Data Units) are transmitted via a backhaul RLC channel (BH NR RLC channel). Each BH link has 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] 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. 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 an SCTP (Stream Control Transmission Protocol) layer instead of the GTP-U layer and UDP layer shown in FIG.

[0049] In the following, the processing or operations performed by the IAB-DU and IAB-MT of the IAB may be simply referred to as the processing or operations of the "IAB." For example, the transmission of a BAP layer message from the IAB-DU of IAB node 300-1 to the IAB-MT of IAB node 300-2 will be described as the IAB node 300-1 sending the message to the IAB node 300-2. In addition, the processing or operations of the DU or CU of the IAB donor 200 may be simply referred to as the processing or operations 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 called topology-wide fairness (hereinafter, sometimes referred to as "fairness"). Fairness provides a mechanism for managing Quality of Service (QoS) so that the required QoS is satisfied across the entire topology, regardless of where UE 100 connects in the IAB network. For example, in FIG. 1, fairness can be said to mean managing the entire topology so that UE 100 receives the same QoS whether connected to IAB node 300-2 or IAB donor 200-1.

[0052] Approaches to such fairness can be categorized into the following two types, 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 scheduler implementation.Furthermore, (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 subordinate relay node (e.g., the IAB node 300) sets to the relay node whether or not to cause the scheduler of the relay node to perform priority control in the forwarding of data packets. Second, the relay node operates the scheduler in accordance with the setting. Hereinafter, priority control in the forwarding of 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 perform data packet forwarding control. Data packet forwarding control is, for example, an example of fairness control. By setting in this way, for example, the IAB donor 200 can specify whether or not to cause the IAB node 300-T to perform fairness control (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] The IAB donor 200 starts processing in step S10, and then in step S11 sets whether or not to cause the IAB node 300-T to perform fairness control for IAB. Specific examples of fairness control include the following.

[0063] (B1) Prioritizing the transfer of data packets that have passed through a large number of hops (in the past). This allows, for example, data packets with large delays to be transferred with priority, thereby achieving 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 a large delay are transferred first, 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 preferentially, thereby reducing transfer delays due to large amounts of data and achieving the above-mentioned fairness.

[0066] (B4) Prioritizing 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 configure fairness control by combining the above (B1) to (B4). The IAB donor 200 may also configure the IAB node 300-T with a UE bearer ID or a BH RLC channel ID to be excluded from such fairness control. Furthermore, the IAB donor 200 may configure fairness control for the IAB node 300 by transmitting an RRC message, an F1-AP message, a MAC CE, or the like to the IAB node 300-T.

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

[0069] For example, the header of the BAP Data PDU contains a hop count that is incremented each time the packet passes through an IAB node 300. When the above (B1) is set, the scheduler prioritizes the transfer of data packets that have passed through a larger number of hops based on the hop count.

[0070] For example, the header of the BAP Data PDU contains 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 data packets with a larger 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 with priority, 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 has been described, but this is not limiting. Fairness control may also be performed in routing processing. Specifically, in the BAP layer, priority is given to routing processing of priority packets (e.g., packets with a large number of remaining hops). In other words, the BAP layer passes (or forwards) priority packets to a lower layer (e.g., the 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 can configure the IAB node 300 regarding fairness control, and the IAB node 300 can perform routing processing in accordance with the configuration.

[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 to notify the parent node or child node of the assist information. The assist information is information used by the scheduler of the parent node or child node of the relay node to control the forwarding of data packets. 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 in which the IAB donor 200 sets whether to notify the IAB node 300-T of assist information. Such a setting enables the parent node 300-P or the child node 300-C of the IAB node 300-T to perform fairness control based on the assist information. Therefore, such a setting enables the IAB donor 200 to (indirectly) specify (A1) above 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] In step S20, the IAB donor 200 starts processing, and in step S21, the IAB node 300-T is configured to determine whether or not to notify the parent node 300-P or child node 300-C of the IAB node 300-T of scheduling assistance information. This 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 each time the PDU passes through an IAB node 300. Examples of such information include 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 a message used, for example, when the IAB node 300-T is congested, to notify the parent node 300-P or the child node 300-C that 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 this is not limiting. 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 number of remaining hops, the number of UE bearers, priority information (e.g., QoS setting information), forwarding delay information (e.g., actual measured average latency for a certain period), and / or congestion information (e.g., load, radio resource usage rate, or margin) 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 from 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 configuration. As a result, for example, the IAB donor 200 can achieve fairness by updating the routing configuration using the approach (A2) above.

[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 the 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 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 throughput. In this case, the parent node may report the throughput.

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

[0090] In addition, by the IAB node 300 reporting the throughput information as in step S31, the IAB node 300 can report to the IAB donor 200 an accurate throughput that corresponds to the implementation capability 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 a packet can be delayed between the UE 100 and the UPF 12. Packets 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) that has 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 discards in the IAB node 300 and update routing settings, thereby achieving fairness using the approach (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 validity 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 timestamp information included in the header of the BAP Data PDU and compares it with the set validity period. As a result, the IAB node 300 determines whether the delay time is within the validity period. If the timestamp information is expressed as time information when the data packet was sent from the source, the IAB node 300 may calculate the delay time by comparing the current time with the timestamp information.

[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 the data packet is received).

[0100] In step S45, the IAB node 300 reports the recorded information to the IAB donor 200. For example, the IAB node 300 reports when the number of discarded packets reaches or exceeds 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 recorded information to the IAB donor 200 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 predetermined operations such as updating 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 illustrating 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 its parent node, upper node 300-U. In this case, parent node 300-P sends a failure occurrence notification indicating that a BH RLF has occurred to IAB node 300-T.

[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 a BH RLF at parent node 300-P, the performance of the entire topology may be degraded (such as congestion or delays).

[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 configuration. This makes it possible to prevent, for example, a performance degradation of the entire topology. Furthermore, for example, by having the IAB donor 200 aggregate information, it becomes possible to achieve fairness using the approach (A2) above.

[0108] The failure occurrence notification includes a Type 1 Indication (RLF detected) of BH RLF. The Type 1 Indication is an indication sent by the IAB-DU of the parent node 300-P to 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 BH RLF. The Type 2 Indication is an indication sent by the IAB-DU of the parent node 300-P to the IAB-MT of the IAB node 300-T (or the UE 100) when it detects a recovery operation from a BH RLF. When there is no distinction between Type 1 Indication and Type 2 Indication, the IAB-DU of the parent node 300-P can send a Type 1 / 2 Indication to the IAB-MT of the IAB node 300-T (or the UE 100). The Type 1 / 2 Indication is also an example of a failure occurrence notification.

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

[0110] The IAB node 300-T starts processing in step S50, and then receives a Type 1 / 2 indication of the BH RLF from the 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 another parent node 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 Type 1 / 2 Indication via an MCG (Master Cell Group), it may transmit the notification via an SCG (Secondary Cell Group) (SRB (Signaling Radio Bearer) 3). Alternatively, when the IAB node 300-T receives a Type 1 / 2 Indication via an SCG, it may transmit the notification via an MCG (SRB1). Alternatively, the IAB node 300-T may transmit the notification via Split SRB1.

[0113] In step S53, in response to receiving the Type 1 / 2 Indication, the IAB donor 200 recognizes that a BH RLF has occurred in the parent node 300-P and performs a predetermined operation, such as updating the routing configuration, 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, Type 1 / 2 Indication may be replaced with Type 3 Indication, Type 4 Indication, or a flow control feedback message.

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

[0117] Furthermore, the flow control feedback message is a message sent 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 preemptive buffer status report (BSR (Buffer Status Report), hereinafter sometimes referred to as "preemptive BSR") may be performed. Here, the preemptive BSR will be explained.

[0119] (pre-emptive BSR) FIG. 17(A) shows an example of transmission of a regular BSR, and FIGS. 17(B) and 17(C) 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] Also, 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, and therefore 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 a normal BSR. Fig. 18 is a diagram showing an example of the configuration of a 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 fields for LCGi and buffer size.

[0125] LCGi is a field 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 where the pre-emptive BSR was triggered, and does not include the total amount of data currently available at the IAB-MT. Buffer sizes are described in more detail below.

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

[0128] However, the scheduling timing of the data stored in the IAB-DU of IAB node 300-T is different from the scheduling timing of the data stored in the IAB-MT of child node 300-C. Therefore, even if 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) located 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 field 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 field 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 fields, making it possible to schedule the first data and the second data at different times.

[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 (its 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. This identification may be made 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. This identification may be made from the amount of data remaining in the receiving MAC SDU, receiving RLC PDU, and / or receiving BAP PDU (which may include the transmitting BAP PDU) remaining in the IAB node 300-T, for example. Note 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 has been described in which BS#1 and BS#2 are included in one pre-emptive BSR MAC CE, but BS#1 and BS#2 may be included in different pre-emptive BSR MAC CEs. In this case, 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] 18 is just an example. For example, the pre-emptive BSR MAC CE may have any configuration as long as it is a MAC CE that includes a buffer size field.

[0138] (Sixth embodiment) The sixth embodiment is an example in which the amount of data residing in the IAB-DU of the IAB node 300-T and the amount of data residing in the IAB-MT of the child node 300-C are distinguished using the LCGi of the 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 field corresponding to the first logical channel group, which is a third buffer size field 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 the IAB node 300-T with an LCG that stores the BSR value (or buffer size value) of the child node 300-C. 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 that stores 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 remaining in the IAB-MT of the child node 300-C in the BS (e.g., BS#1) corresponding to the set LCG (e.g., LCG0). As in the fifth embodiment, the data remaining 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.

[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 the IAB node 300-T has already received from the child node 300-C. 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] Note that, instead of the IAB donor 200 setting an LCG, 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. 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 other than the LCG (e.g., LCG2). 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 the IAB node 300-T reports the amount of data remaining in the child node 300-C by a pre-emptive BSR, and reports the amount of data remaining in the IAB node 300-T by a normal BSR.

[0152] FIG. 22 is a diagram illustrating 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 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 remaining in its own IAB-MT and IAB-DU using a BSR. Also, the IAB node 300-T reports the amount of data remaining 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 first data remaining 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 second data remaining 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 it 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 based on, for example, 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 based on, for example, 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 determined in the same manner as in the fifth embodiment, for example.

[0161] In step S83, the IAB node 300-T transmits the normal BSR MAC CE and the 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] According to this operation example, the buffer size of the pre-emptive BSR MAC CE specified in 3GPP TS38.321 will be 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 example of operation 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 on a computer-readable medium. Using the computer-readable medium, the program can be installed on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.

[0166] In addition, circuits that execute each process performed by UE100, gNB200, or IAB node 300 may be integrated, and at least a portion of UE100, gNB200, or IAB node 300 may be configured as a semiconductor integrated circuit (chipset, 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 can be made without departing from the scope of the invention. Furthermore, it is also possible to combine all or part of each embodiment within a consistent range.

[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] (Addendum) (introduction) A revised work item on Enhancements to Integrated Access and Backhaul (eIAB) for NR was approved. Some of the objectives are:

[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 across topologies, multi-hop delays, and congestion mitigation.

[0171] The following agreement was reached regarding topology, routing, and transport enhancements:

[0172] R2 assumes that the Rel-17 IAB work will not define 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 for managing QoS so 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 can be evaluated requires further study. ·RAN2 will not discuss DLE 2E flow control extensions without input from RAN3. Further study is needed to determine 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 appendix discusses 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 area expansion) In Rel-16, the number of LCGs for the UE, i.e., up to eight LCGs, was reused for IAB-MT. Many companies have proposed increasing the number of LCGs. Expanding the LCG area reduces the number of LCHs per LCG, providing finer scheduling granularity and contributing to fairness across the topology. Therefore, RAN2 should increase the number of LCGs. This applies to both legacy BSR 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 procedures are 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 BAP does not calculate the data volume. Therefore, the current specification lacks data available for transmission. For better scheduling for fairness across the topology, the buffer size reported by 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 is highly dependent on the IAB-DU implementation. However, 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, not the amount of data currently available at the IAB-MT." Some IAB nodes may report a larger buffer size in the preemptive BSR than the amount of data actually expected to arrive. In multi-vendor deployments, it may be difficult to enforce the same principle between child and parent nodes. This can lead to inefficient radio resource allocation, scheduling delays at the parent, and unfair resource requests between IAB-MTs. The situation may become even more ambiguous when IAB nodes are configured with dual connectivity. Therefore, the calculation of the buffer size for preemptive BSR should be more precisely specified.

[0179] Proposal 3: RAN2 should specify the calculation of 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 using schedulers, etc. - Centralized fairness optimization, such as updating routing settings

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

[0182] On the other hand, in centralized fairness optimization, IAB donors are reported along with information or measurements such as congestion status, delay / latency, etc., to determine, for example, routing configuration updates. Therefore, 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 enhance topology-wide fairness.

[0184] Proposal 4: RAN2 should discuss whether fairness enforcement across the topology should be achieved through a localized / distributed approach (e.g., by each scheduler), 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 for 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:

2. A relay node under the donor node, a receiving unit that 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; a transmitter 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, configuration information for configuring whether to notify a parent node of the relay node of flow control feedback information regarding a congestion state for each backhaul RLC (Radio Link Control) channel of the relay node; The relay node notifies the parent node of the flow control feedback information in accordance with the setting information. Communication system.

4. To the relay node under the donor node, receiving, from the donor node, configuration information for setting whether to notify a parent node of the relay node of flow control feedback information regarding a congestion state for 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 that controls a relay node under a donor node, receiving, from the donor node, configuration information for setting whether to notify a parent node of the relay node of flow control feedback information regarding a congestion state for 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