Communication Control Method

Abstract

A communication control method according to a first embodiment of the present invention is for use in a cellular communication system. The communication control method includes transmitting, by a donor base station having first and second relay nodes under control thereof, a trigger type of a pre-emptive buffer status report (pre-emptive BSR) to the second relay mode which is a master node of the first relay node. Further, the communication control method includes triggering, by the first relay node, the pre-emptive buffer status report in accordance with the trigger type toward the second relay node.

Description

[Technical Field]

[0001] The present disclosure relates to a communication control method for use in a cellular communication system. [Background technology]

[0002] The Third Generation Partnership Project (3GPP), 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.4.0(2020-12)"). 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 first and second relay nodes subordinate thereto transmitting a trigger type of a preemptive buffer status report (pre-emptive BSR) to a second relay node that is a parent node of the first relay node. The communication control method also includes the first relay node triggering the preemptive buffer status report to the second relay node according to the trigger type.

[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 second relay node, which is a parent node of a first relay node, transmitting a trigger type of a preemptive buffer status report (pre-emptive BSR) to the first relay node. The communication control method also includes the first relay node triggering the preemptive buffer status report to the second relay node according to the trigger type.

[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 first relay node, which is a child node of a second relay node, transmitting a trigger type of a preemptive buffer status report (pre-emptive BSR) to the second relay node. The communication control method also includes the first relay node triggering the preemptive buffer status report to the second relay node according to the trigger type.

[0006] A communication control method according to a fourth aspect is a communication control method used in a cellular communication system. The communication control method includes a donor base station having a plurality of relay nodes subordinate thereto transmitting a trigger type of a preemptive buffer status report (pre-emptive BSR) to a first relay node directly subordinate to the donor base station, the first relay node transmitting the trigger type to a second relay node that is a child node of the first relay node, and repeating this process for all relay nodes subordinate to the donor base station. The communication control method also includes all relay nodes triggering the preemptive buffer status report in accordance with the trigger type. [Brief explanation of the drawings]

[0007] [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 an example of transmitting a preemptive BSR according to the first embodiment. [Figure 10] FIG. 10 is a diagram illustrating an example of the configuration of a Pre-emptive BSR MAC CE according to the first embodiment. [Figure 11] FIG. 11 is a diagram illustrating a setting example 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. 13A is a diagram illustrating a transmission example according to the second embodiment, and FIG. 13B is a diagram illustrating a configuration example of "usePreBSR" according to the second embodiment. [Figure 14] FIG. 14 is a diagram illustrating an example of operation according to the second embodiment. [Figure 15] FIG. 15(A) is a diagram showing a setting example according to a modified example of the second embodiment, and FIG. 15(B) is a diagram showing an operation example according to the modified example of the second embodiment. [Figure 16] FIG. 16(A) is a diagram illustrating a transmission example according to the third embodiment, and FIG. 16(B) is a diagram illustrating an operation example according to the third embodiment. [Figure 17] FIG. 17 shows a setting example according to a modified example of the third embodiment. [Figure 18] FIG. 18 is a diagram illustrating an example of operation according to a modification of the third embodiment. [Figure 19] FIG. 19 is a diagram illustrating a setting example according to the fourth embodiment. [Figure 20] FIG. 20 is a diagram illustrating an example of operation according to the fourth embodiment. [Figure 21] FIG. 21 is a diagram illustrating a setting example according to the fifth embodiment. [Figure 22]FIG. 22 is a diagram illustrating an example of operation according to the fifth embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0008] 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.

[0009] (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, future cellular communication systems such as 6G may also be applied to the cellular communication system.

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

[0011] 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.

[0012] 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).

[0013] 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.

[0014] 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.

[0015] 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.

[0016] 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.

[0017] 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.

[0018] The cellular communication system 1 supports IAB, which enables wireless relay of NR access using NR for backhaul. The donor gNB (or donor node, hereinafter sometimes referred to as the "donor node") 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).

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

[0020] 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 donor node 200-1 via the IAB node 300-2 and the IAB node 300-1.

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

[0022] 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.

[0023] 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 the DU of the parent IAB node or the donor node 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.

[0024] 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 donor node 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.

[0025] Furthermore, all IAB nodes 300 connected to the donor node 200 via one or more hops form a directed acyclic graph (DAG) topology (hereinafter, sometimes referred to as "topology") with the donor node 200 as the root. In this topology, as shown in FIG. 2, adjacent nodes on the IAB-DU interface are child nodes, and adjacent nodes on the IAB-MT interface are parent nodes. The donor node 200 centrally manages, for example, resources, topology, and route management of the IAB topology. The donor node 200 is a gNB that provides network access to the UE 100 via a network of backhaul links and access links.

[0026] (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.

[0027] 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.

[0028] 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.

[0029] 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 (or donor node 200) in each of the embodiments shown below.

[0030] (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.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] (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.

[0035] 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.

[0036] 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.

[0037] (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.

[0038] 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.

[0039] 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.

[0040] The MAC layer performs data priority control, retransmission processing using Hybrid ARQ (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.

[0041] 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.

[0042] 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 donor node 200 via a radio bearer.

[0043] The RRC layer controls logical channels, transport channels, and physical channels in response 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 donor node 200. When there is an RRC connection with the donor node 200, the IAB-MT is in an RRC connected state. When there is no RRC connection with the donor node 200, the IAB-MT is in an RRC idle state.

[0044] 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.

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

[0046] 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 donor node 200 each have a BAP (Backhaul Adaptation Protocol) 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 via the BAP layer, enabling routing over multiple hops.

[0047] In each backhaul link, PDUs (Protocol Data Units) of the BAP layer are transmitted via a backhaul RLC channel (BH NR RLC channel). Configuring multiple backhaul RLC channels in each BH link enables 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 donor node 200.

[0048] Note that the CU of the donor node 200 is a gNB-CU function of the donor node 200 that terminates the F1 interface to the IAB node 300 and the DU of the donor node 200. Also, the DU of the donor node 200 is a gNB-DU function of the donor node 200 that hosts the IAB BAP sublayer and provides wireless backhaul to the IAB node 300.

[0049] As shown in FIG. 8, the protocol stack of the F1-C protocol has an F1AP layer and an SCTP layer instead of the GTP-U layer and UDP layer shown in FIG.

[0050] 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 IAB node 300-2. In addition, the processing or operations of the DU or CU of the donor node 200 may be simply referred to as the processing or operations of the "donor node."

[0051] 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. (First embodiment) (About preemptive BSR (Buffer Status Report)) Generally, the BSR transmitted by the UE 100 (hereinafter referred to as "regular BSR" where appropriate) indicates the amount of untransmitted uplink data (i.e., uplink buffer capacity) of each of the MAC, RLC, and PDCP layers for each logical channel group (LCG). Each LCG is a group consisting of at least one logical channel and set according to priority. Based on the regular BSR received from the UE 100, the gNB 200 determines the amount of untransmitted uplink data of the UE 100 for each LCG, and performs scheduling to allocate uplink radio resources to the UE 100 that correspond to the amount of untransmitted uplink data.

[0052] FIG. 9(A) is a diagram showing an example of regular BSR transmission between IAB nodes. FIG. 9(A) shows an example in which IAB node 300-2 transmits a regular BSR to parent node 300-1 after receiving data from child node 300-3. IAB node 300-2 reports the amount of data waiting to be transmitted (or the amount of buffered data) present in IAB node 300-2 (the MAC and RLC of IAB-MT) to parent node 300-1 using the regular BSR as a buffer size. Then, uplink radio resources corresponding to this data amount are allocated by parent node 300-1. IAB node 300-2 then transmits the data to parent node 300-1 using the radio resources.

[0053] On the other hand, Figures 9(B) and 9(C) are diagrams showing examples of transmitting a preemptive BSR. As shown in Figure 9(B), IAB node 300-2 transmits a preemptive BSR after transmitting a UL grant to child node 300-3 and before receiving UL data from child node 300-3. Also, as shown in Figure 9(C), IAB node 300-2 transmits a preemptive BSR after receiving a regular BSR from child node 300-3 and before transmitting a UL grant to child node 300-3.

[0054] In this way, the preemptive BSR is transmitted to the parent node 300-1 earlier than the regular BSR, which makes it possible to reduce the delay in UL scheduling by the parent node 300-1 for the IAB node 300-2 compared to the case of the regular BSR.

[0055] FIG. 10 is a diagram showing an example of the configuration of a Pre-emptive BSR MAC CE. Like a regular BSR, a Pre-emptive BSR is transmitted using a MAC CE. As shown in FIG. 10, the Pre-emptive BSR MAC CE is i and buffer size fields.

[0056] LCGi is a field indicating the presence of a buffer size for logical channel group i. i When LCG is set to "1", it indicates that the buffer size of logical channel group i is to be reported. i When set to "0", it indicates that the buffer size for logical channel group i is not reported.

[0057] The buffer size identifies the total amount of data expected to arrive at the IAB-MT of the IAB node 300 for which a preemptive BSR was triggered, and does not include the total amount of data currently available at the IAB-MT.

[0058] The above explains preemptive BSR, but to summarize, it can be described as follows:

[0059] That is, when configured, if either of the following events (A1) or (A2) occurs, in the specific case of IAB-MT, a preemptive BSR is triggered. (A1) A UL grant is provided to the child node or UE. (A2) Receive a BSR from a child node or UE.

[0060] (A1) corresponds to FIG. 9(B), and (A2) corresponds to FIG. 9(C).

[0061] There are two types of triggers for preemptive BSR as described above, but the LCG reported is i Calculation of the expected data volume, related LCH (Logical Channel), etc. is implementation dependent.

[0062] However, for example, in FIG. 9(B) or 9(C), from the viewpoint of parent node 300-1, even if it receives a preemptive BSR, it does not know the transmission timing of UL data transmitted from IAB node 300-2 (hereinafter, sometimes referred to as "child node 300-2"). If parent node 300-1 can allocate radio resources for the UL data of child node 300-2 immediately before child node 300-2 transmits the UL data and transmit the UL grant to child node 300-2, it can transmit the UL grant at the appropriate timing. However, because parent node 300-1 does not know the transmission timing of the UL data, it may not be able to transmit the UL grant at the appropriate timing.

[0063] As described above, the buffer size included in the preemptive BSR is defined as "identifying the total amount of data expected to arrive at the IAB-MT of the IAB node 300 where the preemptive BSR was triggered, but does not include the total amount of data currently available in the IAB-MT." Although the buffer size is implementation-dependent, it is unclear whether the "data expected to arrive at the IAB-MT of the IAB node 300" refers to data buffered in the IAB-DU of the child node 300-2, data buffered in the IAB-MT of the IAB node 300-3, which is the child node of the child node 300-2, or both. Furthermore, the timing at which the preemptive BSR is triggered differs between (A1) and (A2). Because data changes constantly, the amount of data may differ depending on the timing. Therefore, the buffer size may also differ between (A1) and (A2). The parent node 300-1, upon receiving the buffer size report, is unable to accurately predict the buffer size. Therefore, the parent node 300-1 that receives the report is unable to generate an appropriate UL grant and transmit the appropriate UL grant to the child node 300-2.

[0064] From the above, for preemptive BSR, the timing of receiving UL data is known from the parent node 300-1. and others Therefore, there is a problem in that an appropriate UL grant cannot be transmitted to the child node 300-2 at an appropriate time.

[0065] To solve this problem, the donor node can configure the IAB node that sends the preemptive BSR to decide which event (A1) or (A2) will trigger the preemptive BSR.

[0066] However, even if an IAB node can set which event will cause it to send a preemptive BSR, the parent node receiving the preemptive BSR does not know which event will trigger (or send) the preemptive BSR. Therefore, the parent node does not know when it will receive UL data, and may not be able to send an appropriate UL grant at the appropriate time.

[0067] Therefore, in the first embodiment, the donor node 200 transmits the trigger type of preemptive BSR set in the child node 300-2 to the parent node 300-1. Specifically, a donor base station (e.g., donor node 200) having first and second relay nodes under it transmits the trigger type of preemptive BSR to a second relay node (e.g., parent node 300-1) that is the parent node of the first relay node (e.g., child node 300-2). At this time, the donor base station transmits the trigger type set in the first relay node to the second relay node. Secondly, the first relay node triggers preemptive BSR to the second relay node in accordance with the trigger type.

[0068] 11 is a diagram showing a setting example according to the first embodiment. In the following, "trigger type" refers to information indicating either one of the events (or timing) of (A1) and (A2). In the following, "trigger" and "transmission" may be used interchangeably.

[0069] Note that Figure 11 shows an example in which there is at least one IAB node between the donor node 200 and the IAB node 300-P, but there may not be such an IAB node, and the IAB node 300-P may exist directly below the donor node 200.

[0070] In FIG. 11, IAB node 300-P is a parent node of IAB node 300-C. Furthermore, IAB node 300-C is a child node of IAB node 300-P. Hereinafter, they may be referred to as parent node 300-P and child node 300-C. Child node 300-C may be UE 100. In this case, when donor node 200 and UE 100 are RRC connected, donor node 200 can directly configure UE 100 using an RRC message.

[0071] As shown in FIG. 11, the donor node 200 first sets the trigger type of preemptive BSR for the child node 300-C. Then, the donor node 200 transmits the trigger type of preemptive BSR set for the child node 300-C to the parent node 300-P. In other words, the parent node 300-P acquires information about the trigger type of the received preemptive BSR. Then, the child node 300-C transmits the preemptive BSR to the parent node 300-P according to the set trigger type.

[0072] Fig. 12 is a diagram illustrating an example of operation according to the first embodiment. The example of operation shown in Fig. 12 will be explained by appropriately using the relationship shown in Fig. 11.

[0073] In step S10, the donor node 200 starts the process.

[0074] In step S11, the donor node 200 sets the trigger type of preemptive BSR to the child node 300-C. The CU of the donor node 200 may perform the setting by transmitting an RRC message to the IAB-MT of the child node 300-C. Alternatively, the CU of the donor node 200 may perform the setting by transmitting an F1AP message to the IAB-DU of the child node 300-C. Note that the parent node 300-P may transmit the trigger type (or preference information) used by the child node 300-C to the donor node 200. In this case, the donor node 200 sets the trigger type to the child node 300-C in response to this notification.

[0075] In step S12, the donor node 200 transmits the trigger type set in the child node 300-C to the parent node 300-P. The transmission of the trigger type may be performed by an RRC message or an F1AP message, as in step S11. Note that the parent node 300-P may inquire of the donor node 200 about the current setting value of the trigger type. In other words, the parent node 300-P may inquire about the trigger type set in the child node 300-C. In this case, the donor node 200 transmits the trigger type to the parent node 300-P in response to the inquiry.

[0076] The donor node 200 may transmit mapping information between logical channel groups (LCGs) and logical channels (LCHs) along with the trigger type to the parent node 300-P. For example, the mapping information may be LCG1 = LCH1 to LCH3, LCG2 = LCH4 to LCH6, etc. The logical channel group includes at least one logical channel. The buffer size reported as a preemptive BSR is calculated for each logical channel group in which data exists. By the parent node 300-P knowing the buffer size for each logical channel group included in the preemptive BSR and the logical channels included in the logical channel group, QoS (Quality of Service) information can be used for scheduling when provided for each logical channel. The trigger type and / or the mapping information between the logical channel group and the logical channel may be associated with an identifier of the child node 300-C. Examples of such identifiers include a UE ID, a C-RNTI, and an F1AP UE ID.

[0077] In step S13, the IAB-MT of the child node 300-C triggers a preemptive BSR to the IAB-DU of the parent node 300-P in accordance with the set trigger type.

[0078] In step S14, the IAB-DU of the parent node 300-P schedules radio resources based on the trigger type received from the donor node 200 and the preemptive BSR received from the child node 300-C. The IAB-DU of the parent node 300-P transmits a UL grant including the scheduling result to the IAB-MT of the child node 300-C.

[0079] In step S15, the parent node 300-P ends the series of processes.

[0080] As described above, in the first embodiment, the donor node 200 sets the trigger type of the preemptive BSR set for the child node 300-C for the parent node 300-P (step S12). Therefore, the parent node 300-P can grasp the trigger type set for the child node 300-C and can grasp whether the preemptive BSR will be triggered by the event (A1) or (A2). Therefore, the parent node 300-P can anticipate that timing and transmit a UL grant at an appropriate timing. Furthermore, by grasping at least which event, (A1) or (A2), triggered the preemptive BSR, the parent node 300-P can predict an appropriate buffer size and allocate radio resources, and can transmit an appropriate UL grant to the child node 300-C. (Second embodiment) The second embodiment is an example in which a parent node 300-P transmits to a child node 300-C a trigger type of a preemptive BSR that the child node 300-C should use. Specifically, first, a second relay node (e.g., parent node 300-P) that is a parent node of a first relay node (e.g., child node 300-C) transmits the trigger type of a preemptive BSR to the first relay node. Second, the first relay node triggers a preemptive BSR to the second relay node according to the trigger type.

[0081] In this way, in the second embodiment as well, the parent node 300-P can grasp the trigger type triggered by the child node 300-C, and can therefore transmit an appropriate UL grant to the child node 300-C at the appropriate timing, as in the first embodiment.

[0082] 13A is a diagram illustrating a transmission example according to the second embodiment. The parent node 300-P transmits a trigger type to the child node 300-C. The child node 300-C triggers a preemptive BSR to the parent node 300-P in accordance with the trigger type.

[0083] FIG. 14 is a diagram illustrating an example of operation in the second embodiment.

[0084] In step S20, the parent node 300-P starts processing.

[0085] In step S21, the parent node 300-P transmits the trigger type of the preemptive BSR to the child node 300-C. This transmission may be an instruction of the trigger type from the parent node 300-P to the child node 300-C. For example, the trigger type is transmitted by the IAB-DU of the parent node 300-P transmitting a MAC CE (Control Element) or a BAP Control PDU including the trigger type to the IAB-MT of the child node 300-C. The trigger type may be transmitted using SIB1 (System Information Block 1).

[0086] Note that, before step S21, the donor node 200 may configure the parent node 300-P to permit the child node 300-C to use the preemptive BSR. In 3GPP, an information element included in an RRC message (RRC setup message) is "usePreBSR," which can configure permission to use the preemptive BSR. FIG. 13(B) is a diagram showing an example of the configuration of "usePreBSR" according to the second embodiment. For example, the donor node 200 configures permission to use the preemptive BSR by transmitting an RRC message including "usePreBSR" to the child node 300-C. Then, in step S21, the donor node 200 notifies the parent node 300-P that permission to use the preemptive BSR has been configured for the child node 300-C. That is, the parent node 300-P may perform the processing of step S21 upon being notified by the donor node 200 that permission to use the preemptive BSR has been configured for the child node 300-C.

[0087] When use permission is set for the child node 300-C by the donor node 200, the child node 300-C may apply the received trigger type upon receiving the trigger type from the parent node 300-P. On the other hand, when use permission is not set by the donor node 200, the child node 300-C may ignore the received trigger type upon receiving the trigger type from the parent node 300-P.

[0088] Furthermore, in step S21, the child node 300-C that has received the trigger type may transmit a response indicating whether or not to accept the received trigger type to the parent node 300-P. For example, when the child node 300-C receives an unsupported trigger type, it transmits a response indicating that it refuses (or does not accept) the acceptance to the parent node 300-P. The response may be made by inserting one bit of information (whether or not to accept) into the header portion of the (Pre-emptive) BSR MAC CE, or may be made by a separate, dedicated MAC CE.

[0089] In step S22, the child node 300-C triggers a preemptive BSR to the parent node 300-P in accordance with the trigger type received from the parent node 300-P.

[0090] In step S23, the parent node 300-P performs scheduling based on the trigger type transmitted to the child node 300-C and the preemptive BSR received from the child node 300-C. Then, the parent node 300-P transmits a UL grant to the child node 300-C.

[0091] In step S24, the parent node 300-P ends the series of processes. (Variation) A modified example of the second embodiment will be described. The modified example is an example in which the donor node 200 configures the parent node 300-P to allow it to determine the trigger type of the child node 300-C. Specifically, first, a donor base station (e.g., the donor node 200) having first and second relay nodes subordinate thereto configures the second relay node (e.g., the parent node 300-P) to allow it to determine the trigger type of the first relay node (e.g., the child node 300-C). Second, the configured second relay node transmits the trigger type to the first relay node.

[0092] Fig. 15(A) is a diagram showing a setting example according to a modified example of the second embodiment. Fig. 15(B) is a diagram showing an operation example according to the modified example of the second embodiment. The operation example according to the modified example will be explained using Fig. 15(B) while referring to Fig. 15(A) as needed.

[0093] As shown in FIG. 15(B), in step S30, the donor node 200 starts the process.

[0094] In step S31, the donor node 200 grants permission to the parent node 300-P to determine the trigger type of the child node 300-C. This setting is performed, for example, by using an RRC message or an F1AP message. In this case, the message may list "event (A1)," "event (A2)," and "child node may determine the trigger type," and represent any one of them as selectable. Specifically, the message may list "UL grant transmission" (=A1), "BSR reception" (=A2), and "self-decision" (= "child node may determine the trigger type"), and indicate whether the selected or unselected one is selected by "true" or "false" (or "1" or "0").

[0095] Thereafter, similarly to the second embodiment, the processes from step S21 onward (FIG. 14), i.e., the process in which the parent node 300-P transmits the trigger type to the child node 300-C, are performed. Note that the child node 300-C may determine that permission has been granted based on a notification from the parent node 300-P, even if permission for preemptive BSR has not been set by the donor node 200. The parent node 300-P may further notify the child node 300-C that permission has been granted from the donor node 200.

[0096] In the modified example, the parent node 300-P receives permission setting from the donor node 200 and is able to set a trigger type for the child node 300-C. (Third embodiment) The third embodiment is an example in which a child node 300-C transmits to a parent node 300-P the trigger type of the preemptive BSR used by the child node 300-C. Specifically, first, a first relay node (e.g., child node 300-C), which is a child node of a second relay node (e.g., parent node 300-P), transmits the trigger type of the preemptive BSR to the second relay node. Second, the first relay node triggers a preemptive BSR to the second relay node according to the trigger type.

[0097] In the third embodiment, the parent node 300-P also receives the trigger type used by the child node 300-C from the child node 300-C, and is therefore able to grasp the trigger type used by the child node 300-C. Therefore, the parent node 300-P can transmit an appropriate UL grant at an appropriate timing, as in the first embodiment.

[0098] 16(A) is a diagram showing a transmission example according to the third embodiment. The child node 300-C transmits a trigger type to the parent node 300-P. In this case, the trigger type of the child node 300-C may be set by the donor node 200 or may be determined depending on the implementation of the child node 300-C. Then, the child node 300-C triggers a preemptive BSR to the parent node 300-P in accordance with the transmitted trigger type.

[0099] FIG. 16B is a diagram illustrating an example of operation according to the third embodiment.

[0100] In step S40, the child node 300-C starts processing.

[0101] In step S41, the child node 300-C transmits the trigger type used by the child node 300-C to the parent node 300-P. With regard to the timing of transmission, the child node 300-C may transmit the trigger type when the trigger type is set by the donor node 200, or may transmit the trigger type when the child node 300-C sets the trigger type itself. Alternatively, the child node 300-C may transmit the trigger type every time it transmits a preemptive BSR. The trigger type may be transmitted using a MAC CE or a BAP Control PDU. When a MAC CE is used, the trigger type may be represented by one bit information "UL grant (=A1) or BSR (=A2)" in the header section of the (Preemptive) BSR MAC CE, or the trigger type may be transmitted separately using a dedicated MAC CE.

[0102] When the trigger type is represented as one bit of information in the header section of the Pre-emptive BSR MAC CE, the trigger type may be changed (dynamically) for each preemptive BSR transmission. For example, when the child node 300-C triggers the first preemptive BSR, it inserts one bit of information (A1) into the header section of the pre-emptive BSR MAC CE and triggers the preemptive BSR at timing (A1). Then, when the child node 300-C transmits the next preemptive BSR, it inserts one bit of information (A2) into the header section and triggers the preemptive BSR at timing (A2), and so on.

[0103] When a trigger type is transmitted by a dedicated MAC CE, the trigger type may be fixed from this transmission onwards until the next trigger type is transmitted by the dedicated MAC CE.

[0104] In either case, when the trigger type is represented as one-bit information in the header section of the Pre-emptive BSR MAC CE, or when the trigger type is transmitted by a dedicated MAC CE, the trigger type may be transmitted by (only) the MAC header of the MAC PDU. That is, the MAC header includes an LCID (Logical Channel ID), and the LCID allows the MAC CE to identify the trigger type and Pre-emptive BSR. For example, LCID=313 indicates that the trigger type is (A), and LCID=312 indicates that the trigger type is (B). Furthermore, for example, LCID=311 indicates that the Pre-emptive BSR MAC CE has trigger type (A). In this case, the buffer size (BS) is also reported by the corresponding MAC CE. Furthermore, for example, LCID=310 indicates that the Pre-emptive BSR MAC CE has trigger type (B). In this case, the BS is also reported by the corresponding MAC CE.

[0105] In step S42, the child node 300-C triggers a preemptive BSR in accordance with the trigger type transmitted to the parent node 300-P.

[0106] In step S43, the parent node 300-P performs scheduling based on the trigger type received from the child node 300-C and the preemptive BSR received from the child node 300-C. Then, the parent node 300-P transmits a UL grant to the child node 300-C.

[0107] In step S44, the parent node 300-P ends the series of processes. (Modification of the Third Embodiment) A modified example of the third embodiment is an example in which the donor node 200 performs a setting to permit the child node 300-C to determine a dynamic trigger. Specifically, a donor base station (for example, the donor node 200) having a first and second relay node under its control performs a setting to permit the first relay node (for example, the child node 300-C) to determine the trigger type. Secondly, the first relay node for which the setting has been performed transmits the trigger type to the second relay node (for example, the parent node 300-P). In this modified example, ,child It is assumed that the node 300-C itself dynamically changes the trigger type.

[0108] Fig. 17 is a diagram illustrating a setting example according to a modification of the third embodiment. As illustrated in Fig. 17, the donor node 200 sets permission for dynamic trigger determination for the child node 300-C. The child node 300-C determines the trigger type by itself and triggers a preemptive BSR.

[0109] FIG. 18 is a diagram illustrating an example of operation according to a modification of the third embodiment.

[0110] In step S50, the donor node 200 starts the process.

[0111] In step S51, the donor node 200 sets the child node 300-C to permit dynamic trigger determination. The permission for dynamic trigger determination may be permission for the child node 300-C itself to determine the trigger type. Such setting may be performed using an RRC message or an F1AP message. As in the modified example of the second embodiment, the message may list "event (A1)," "event (A2)," and "dynamic trigger determination," and indicate that one of them has been selected. Alternatively, the message may list "UL grant transmission" (= A1), "BSR reception" (= A2), and "dynamic triggers" (="child node may dynamically determine trigger"), and indicate that one has been selected or not by "true" or "false" (or "1" or "0").

[0112] In step S52, the child node 300-C determines the trigger type itself and triggers a preemptive BSR to the parent node 300-P in accordance with the determined trigger type. The child node 300-C transmits the trigger type to the parent node 300-P before, during, or after transmitting the preemptive BSR. The transmission of the trigger type to the parent node 300-P is the same as in the third embodiment.

[0113] In the modified example, the parent node 300-P also receives the trigger type from the child node 300-C, and therefore can transmit an appropriate UL grant to the child node 300-C at an appropriate timing, similar to the first embodiment and the like.

[0114] In the modified example, the donor node 200 sets permission for dynamic trigger determination for the child node 300-C, but the parent node 300-P may also grant permission for dynamic trigger determination to the child node 300-C. For example, the parent node 300-P may grant permission by transmitting a MAC CE or a BAP Control PDU including permission for the determination to the child node 300-C. (Fourth embodiment) The fourth embodiment is an example in which the donor node 200 sets a trigger type for the parent node 300-P, and the parent node 300-P transmits the trigger type to the child node 300-C. Specifically, first, a donor base station (e.g., the donor node 200) having first and second relay nodes subordinate thereto transmits a trigger type of preemptive BSR to a second relay node (e.g., the parent node 300-P) that is the parent node of the first relay node (e.g., the child node 300-C). Second, the second relay node transmits the trigger type to the first relay node. Third, the first relay node triggers preemptive BSR in accordance with the trigger type received from the second relay node.

[0115] In the fourth embodiment as well, the parent node 300-P can grasp the trigger type used by the child node 300-C because the parent node 300-P receives the setting of the trigger type used by the child node 300-C from the donor node 200. Therefore, in the fourth embodiment as well, the parent node 300-P can transmit an appropriate UL grant to the child node 300-C at an appropriate timing, similar to the first embodiment and the like.

[0116] Fig. 19 is a diagram illustrating a setting example according to the fourth embodiment. As illustrated in Fig. 19, the donor node 200 sets the trigger type of the preemptive BSR to be used by the child node 300-C for the parent node 300-P. Then, the parent node 300-P transmits the trigger type set by the donor node 200 to the child node 300-C. The child node 300-C triggers the preemptive BSR in accordance with the trigger type received from the parent node 300-P.

[0117] FIG. 20 is a diagram illustrating an example of operation according to the fourth embodiment.

[0118] In step S60, the donor node 200 starts the process.

[0119] In step S61, the donor node 200 sets, to the parent node 300-P, a trigger type to be used by the child node 300-C. The trigger type is set by an RRC message or an F1AP message, or a BAP Control PDU or a MAC CE. In step S61, the parent node 300-P may transmit, to the donor node 200, the trigger type (or preference information) to be used by the child node 300-C. In this case, the donor node 200 sets the trigger type to the parent node 300-P in response to receiving the trigger type. Note that, instead of this setting, the donor node 200 may use a modification of the second embodiment to set the trigger type to the parent node 300-P. That is, the donor node 200 may set, to the parent node 300-P, permission to determine the trigger type of the child node 300-C. In this case, the parent node 300-P receives this permission setting and transmits the trigger type to the child node 300-C. Furthermore, the donor node 200 may set the trigger type to the parent node 300-P using a modified example of the third embodiment instead of the above setting. That is, the donor node 200 may set permission for the parent node 300-P to allow the child node 300-C to determine the trigger type by itself. In this case, the parent node 300-P receives this permission setting and notifies the child node 300-C of the permission to determine the trigger type by itself, and the child node 300-C receives this notification and determines the trigger type by itself.

[0120] In step S62, the parent node 300-P transmits a trigger type of the preemptive BSR to the child node 300-C. The trigger type may be transmitted using a MAC CE or a BAP Control PDU. Upon receiving the trigger type, the child node 300-C may transmit a response indicating whether or not the request is acceptable to the parent node 300-P, similar to step S21 (FIG. 14) in the second embodiment.

[0121] In step S63, the child node 300-C transmits a preemptive BSR to the parent node 300-P in accordance with the trigger type received from the parent node 300-P.

[0122] In step S64, the parent node 300-P performs scheduling based on the trigger type set by the donor node 200 and the preemptive BSR received from the child node 300-C. The parent node 300-P transmits a UL grant to the child node 300-C.

[0123] In step S65, the parent node 300-P ends the series of processes. (Fifth embodiment) The fifth embodiment is an example in which a trigger type is transmitted to all IAB nodes 300 included in the entire topology constructed by a donor node 200. Specifically, first, a donor base station (e.g., donor node 200) having a plurality of relay nodes under its control transmits a trigger type of preemptive BSR to a first relay node (e.g., IAB node 300-1) directly under the donor base station, and the first relay node transmits the trigger type to a second relay node (e.g., IAB node 300-2) that is a child node of the first relay node, and this is repeated for all relay nodes under the donor base station. Second, all relay nodes trigger preemptive BSR according to the trigger type.

[0124] FIG. 21 is a diagram illustrating a configuration example according to the fifth embodiment. FIG. 21 illustrates an example in which one IAB node 300 is connected to the donor node 200, and one IAB node 300-2 is connected to the IAB node 300-1. However, multiple IAB nodes 300 may be connected directly below the donor node 200, or multiple IAB nodes 300 may be connected as child nodes of the IAB node 300-1. In this way, multiple IAB nodes may be connected directly below the donor node 200 and each IAB node 300. In addition, in the topology constructed by the donor node 200, the node located farthest from the network may be an IAB node or a UE 100.

[0125] 22 is a diagram illustrating an example of operation according to the fifth embodiment. The example of operation in FIG. 22 will be described with reference to FIG. 21 as needed.

[0126] In step S70, the donor node 200 starts the process.

[0127] In step S71, the donor node 200 transmits a trigger type of preemptive BSR to the IAB node 300-1 directly below it. The trigger type may be transmitted by an RRC message or an F1AP message. Alternatively, the trigger type may be transmitted using MAC CE or BAP PDU Control.

[0128] In step S72, the IAB node 300-1 transmits to its child node, the IAB node 300-2, the trigger type received from the donor node 200. The trigger type may be transmitted using MAC CE or BAP Control PDU.

[0129] In step S73, the IAB node 300-2 transmits the trigger type received from the IAB node 300-1 to the IAB node 300-3, which is its child node.

[0130] Thereafter, all IAB nodes 300 under the donor node 200 repeat this process.

[0131] In step S74, each IAB node 300 or UE 100 triggers a preemptive BSR to the donor node 200 or parent node 300 according to the received trigger type.

[0132] In step S75, the donor node 200 or the parent node 300 performs scheduling based on the transmitted trigger type and the received preemptive BSR, and transmits a UL grant to the child node 300 or the UE 100.

[0133] In step S76, the donor node 200 or the parent node 300 ends the series of processes.

[0134] In the fifth embodiment, all IAB nodes 300 or UEs 100 in the topology can transmit preemptive BSRs according to the same trigger type. Therefore, in the fifth embodiment, as in the first embodiment, the parent node 300 or donor node 200 can transmit an appropriate UL grant to the child node 300 or UE 100 at an appropriate timing.

[0135] (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.

[0136] 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).

[0137] 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.

[0138] This application claims priority to U.S. Provisional Application No. 63 / 166,507 (filed March 26, 2021), the entire contents of which are incorporated herein by reference.

[0139] (Addendum) Multi-hop latency IL-2 IL-2 is defined as follows: IL-2: Due to the current (Rel-16) limitation on the number of LCGs, IAB nodes may need to report joint buffer status for LCHs with significantly different QoS requirements.

[0140] Possible solutions for IL-2 include: L4: New behavior or functionality is defined for IAB nodes. L4-3: The number of LCGs in IAB-MT increases.

[0141] In Rel-16, the number of LCGs for a UE was reused for IAB-MT, i.e., up to eight LCGs. Considering that many LCHs are configured for BH links, IAB nodes are required to report legacy BSR and preemptive BSR with LCG restrictions. Therefore, expanding the LCG space is expected to reduce the number of LCHs aggregated within each LCG, leading to finer scheduling granularity and improved fairness across the topology, so RAN2 needs to increase the number of LCGs. This applies to both legacy BSR and preemptive BSR.

[0142] Proposal 1: RAN2 needs to agree to increase the number of LCGs for BSR and preemptive BSR, i.e., use L4-3 to resolve IL-2.

[0143] IL-3 IL-3 is defined as follows: IL-3: The calculation of buffer size for preemptive BSR is left to the implementation in Rel-16 and may vary from vendor to vendor.

[0144] Possible solutions for IL-3 include: L4: New behavior or functionality is defined for IAB nodes. L4-1: Buffer size calculation for preemptive BSR is specified.

[0145] For traditional 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 their specifications. In Rel-16, these mechanisms are reused for the data volume calculation of IAB-MT preemptive BSR.

[0146] However, IAB nodes have a BAP layer instead of PDCP, and the BAP specification does not include data volume calculations. Therefore, the current specification lacks sufficient data available for transmission. To achieve better scheduling fairness across the topology, the buffer size reported by legacy BSR needs to be more accurate.

[0147] Observation 1: The lack of a procedure for sending data in a BAP makes legacy BSR and preemptive BSR inaccurate.

[0148] In Rel-16, the calculation of the buffer size for preemptive BSR depends heavily on the implementation of the IAB-DU. While the specification provides a rough guideline, it states that "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." As noted in the specification, some IAB nodes may report a larger buffer size in the preemptive BSR than the amount of data actually arriving. Applying the same principle between child and parent nodes can be difficult. For example, in multi-vendor deployments, radio resource allocation and scheduling delays at the parent node can lead to inefficiencies and unfair resource requests between IAB-MTs. As noted in the specification, the situation can become even more ambiguous when IAB nodes are configured with dual connectivity. Therefore, the calculation of the buffer size for preemptive BSR needs to be more precisely specified. The problem is that the IAB-DU does not specify the buffer size calculation. That is, the data buffered at the receiver side of the IAB-DU (MAC and RLC).

[0149] Observation 2: There are no procedures for buffered data in the MAC and RLC receivers of IAB-DU, and the amount of data reported in the Rel-16 preemptive BSR is up to the implementation of IAB-DU.

[0150] Proposal 3: RAN2 should agree to specify the buffer size calculation for preemptive BSR (and possibly legacy BSR), i.e., take L4-1 to solve IL-3.

[0151] Another problem is that it is unclear from the parent node's perspective when a preemptive BSR will be triggered. The MAC specification states the following two conditions: The trigger condition depends on the implementation of IAB-MT in Rel-16. This means that the parent node cannot accurately predict when it will be ready to send data, which can lead to inappropriate UL authorization.

[0152] If configured, a preemptive BSR may be triggered in the specific case of IAB-MT if any of the following events occur: -UL permission is provided to the child IAB node or UE. - Receives a BSR from a child IAB node or UE.

[0153] A simple solution would be for the IAB node to configure whether the BSR should be triggered by a UL grant transmission or by a BSR reception. While configuring this at the IAB donor would be straightforward, in practice the parent IAB-DU, i.e., the scheduler, uses preemptive BSR. At this point, it remains to be seen whether the trigger condition should be configured by the IAB donor or dictated by the parent IAB node.

[0154] Proposal 4: RAN2 should agree to allow IAB nodes to set the triggers used for preemptive BSR. Whether this should be done by the IAB donor or its parent IAB node requires further study.

[0155] IL-5 and IL-6 IL-5 is defined as follows: IL-5: CU cannot place bearers with low PDB on paths with low congestion risk (high resource efficiency) or paths without RLF.

[0156] Possible solutions for IL-5 include:

[0157] L3: Introduction of additional signaling from IAB nodes to CU.

[0158] L3-1: Shares the buffer / link status of IAB nodes with the CU.

[0159] L3-2: Share per-hop delay measurements per BH RLC channel with the CU.

[0160] L4: New behaviors and functions are defined for IAB nodes.

[0161] L4-2: Allow local rerouting for purposes other than RLF (e.g., based on outgoing link delay).

[0162] F4: Introduce additional signaling from IAB nodes to CU.

[0163] F4-1: BH RLC Load information for each channel.

[0164] F4-2: Delay per hop and packet loss per hop of individual links.

[0165] IL-6 is defined as follows: IL-6:CU cannot configure routing based on the actual (real-time) latency per BH RLC channel.

[0166] Possible solutions for IL-6 include:

[0167] L3: Introduce additional signaling from IAB nodes to CU.

[0168] L3-2: Share per-hop delay measurements per BH RLC channel with the CU.

[0169] F4: Introduce additional signaling from IAB nodes to CU.

[0170] F4-2: Delay per hop and packet loss per hop of individual links.

[0171] L4: New behaviors and functions are defined for IAB nodes.

[0172] L4-2: Allow local rerouting for purposes other than RLF (e.g., based on outgoing link delay).

[0173] The IL-5 and IL-6 solutions may have something in common in that they provide additional signals from the IAB node to the IAB donor, and thus can be seen as a type of SON procedure pointed out in MDT to allow for centralized optimization.

[0174] For L3-1, the current specification seems to assume that IAB nodes can share some buffer / link state with IAB donors, e.g., via F1-AP RESOURCE STATUS UPDATE and / or RRC measurement reporting framework, so it is unclear what additional reporting is required on top of that.

[0175] For L3-2 and F4-2, both IL-5 and IL-6 are common solutions, and can be considered the same in terms of latency measurement. While the existing L2 measurement specifies "UL PDCP Packet Average Delay per DRB per UE," it is clear that PDCP Packet Average Delay cannot be applied to IAB nodes. Therefore, a new L2 measurement that takes into account at least BAP is expected to be necessary.

[0176] Proposal 3: RAN2 needs to agree that IAB nodes report per-hop delay measurements to the IAB donor, i.e., take L3-2 to resolve IL-5 and IL-6.

[0177] Regarding L4-2, RAN2 has already agreed that "the indication of a Type-2 RLF can be used as a trigger for local rerouting" and "local rerouting can be triggered by an indication of hop-by-hop flow control." Therefore, there is no need to discuss this further in this agenda. That is, the details of local rerouting can be discussed in another agenda item for topology adaptation enhancements.

[0178] Observation 3: Local rerouting for other purposes, namely L4-2, is discussed in the Enhanced Topology Adaptation section.

[0179] Congestion relief IC-1 and IC-7 IC-1 and IC-7 are defined with the following remarks:

[0180] R2 believes that companies are highly interested in the following two issues:

[0181] IC-1: Long-lasting downstream congestion on a single link cannot be alleviated using existing Rel-16 DL HbH flow control mechanisms without resorting to packet dropping.

[0182] IC-7: The CU cannot update congested routes (because it does not know the local congestion situation).

[0183] Both IC-1 and CI-7 are related to RAN3. Since RAN3 seems to be working on it, it is unclear at this point how much R2 will work on it.

[0184] RAN3 has been discussing congestion indication and has agreed to the following: The CP-based congestion indication may include a broadcast. -By BAP routing ID, and / or -For each child link and / or -BH RLC CH ID (Down selection is FFS) The CP-based congestion indication reuses the F1AP GNB-DU status indication procedure. CP-based congestion indication is related to DL congestion.

[0185] Consider the following two options for the IAB's UP-based approach to congestion mitigation: -No function expansion -Packet marking-based approach IAB donor receives congestion from IAB node display If the IAB donor receives a RAN2 notification, it is assumed that the IAB donor can avoid the congested path, as implied in the RAN2 agreement above. In other words, there are two ways to do this: the IAB donor can update the routing configuration or instruct local rerouting. In the latter case, the IAB donor can avoid the congested path. display RAN2 may be involved in how RAN3 is used. In any case, RAN2 should wait for the progress of RAN3 at this point.

[0186] Finding 4: RAN2 saw a surge in IAB donors after RAN3 had detailed information. display This may affect how actions are taken by the organization.

Claims

1. A communication control method for use in a cellular communication system, comprising: A second relay node, which is a parent node of a first relay node, transmits a trigger type of a preemptive buffer status report to the first relay node; the first relay node triggering the preemptive buffer status report to the second relay node according to the trigger type; The method further comprises a donor base station having the first and second relay nodes under its control performing a setting to permit the second relay node to determine a trigger type of the first relay node, transmitting the trigger type includes the second relay node, in which the setting is performed, transmitting the trigger type to the first relay node. Communication control method.

2. A communication control method for use in a cellular communication system, comprising: A first relay node, which is a child node of a second relay node, transmits a trigger type of a preemptive buffer status report (pre-emptive BSR) to the second relay node; the first relay node triggering the preemptive buffer status report to the second relay node according to the trigger type. Communication control method.

3. The method further includes a donor base station having the first and second relay nodes under its control performing a setting to permit the first relay node to determine the trigger type, transmitting the trigger type includes the first relay node, in which the setting is performed, transmitting the trigger type to the second relay node. The communication control method according to claim 2.

4. A communication control method for use in a cellular communication system, comprising: A donor base station having a plurality of relay nodes under its control transmits a trigger type of a preemptive buffer status report (preemptive BSR) to a first relay node immediately under the donor base station, and the first relay node transmits the trigger type to a second relay node that is a child node of the first relay node, and this is repeated for all relay nodes under the donor base station; all the relay nodes trigger the preemptive buffer status report according to the trigger type; Communication control method.

5. a first relay node that is a child node of a second relay node, a transmitter for transmitting a trigger type of a preemptive buffer status report (pre-emptive BSR) to the second relay node; a control unit that triggers the preemptive buffer status report to the second relay node according to the trigger type. First relay node.

6. A processor that controls a first relay node that is a child node of a second relay node, transmitting a trigger type of a preemptive buffer status report (pre-emptive BSR) to the second relay node; and triggering the preemptive buffer status report to the second relay node according to the trigger type. Processor.

Images