WO2022234846A1 - 通信制御方法 - Google Patents

通信制御方法 Download PDF

Info

Publication number
WO2022234846A1
WO2022234846A1 PCT/JP2022/019528 JP2022019528W WO2022234846A1 WO 2022234846 A1 WO2022234846 A1 WO 2022234846A1 JP 2022019528 W JP2022019528 W JP 2022019528W WO 2022234846 A1 WO2022234846 A1 WO 2022234846A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
iab
relay node
bsr
lcg
Prior art date
Application number
PCT/JP2022/019528
Other languages
English (en)
French (fr)
Inventor
真人 藤代
ヘンリー チャン
Original Assignee
京セラ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 京セラ株式会社 filed Critical 京セラ株式会社
Priority to JP2023518695A priority Critical patent/JPWO2022234846A1/ja
Publication of WO2022234846A1 publication Critical patent/WO2022234846A1/ja
Priority to US18/502,969 priority patent/US20240073736A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0278—Traffic management, e.g. flow control or congestion control using buffer status reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W16/00—Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/24—Cell structures
    • H04W16/26—Cell enhancers or enhancement, e.g. for tunnels, building shadow
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/24—Reselection being triggered by specific parameters
    • H04W36/30—Reselection being triggered by specific parameters by measured or perceived connection quality data
    • H04W36/305—Handover due to radio link failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/34—Reselection control
    • H04W36/36—Reselection control by user or terminal equipment
    • H04W36/362—Conditional handover
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/22—Communication route or path selection, e.g. power-based or shortest path routing using selective relaying for reaching a BTS [Base Transceiver Station] or an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0055—Transmission or use of information for re-establishing the radio link
    • H04W36/0069—Transmission or use of information for re-establishing the radio link in case of dual connectivity, e.g. decoupled uplink/downlink
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/08—Reselecting an access point
    • H04W36/087—Reselecting an access point between radio units of access points

Definitions

  • the present disclosure relates to a communication control method used in a cellular communication system.
  • 3GPP Third Generation Partnership Project
  • IAB Integrated Access and Backhaul
  • One or more relay nodes intervene in and relay for communication between the base station and the user equipment.
  • a communication control method is a communication control method used in a cellular communication system.
  • a donor base station having a first relay node under its control and a second relay node that is a parent node of the first relay node transmits a logical channel (LCH) to the first relay node.
  • LCH logical channel
  • the communication control method includes the first relay node transmitting a buffer status report (BSR) to the second relay node based on the correspondence information.
  • BSR buffer status report
  • the communication control method includes the second relay node transmitting an uplink grant (UL grant) to the first relay node based on the correspondence information and the buffer status report.
  • UL grant uplink grant
  • a communication control method is a communication control method used in a cellular communication system.
  • the communication control method includes the upper node of the first relay node setting a setting value regarding the logical channel group to the first relay node. Also, the communication control method includes determining, by the first relay node, a MAC control element (CE) format corresponding to the setting value. Further, the communication control method includes the first relay node sending a buffer status report to a second relay node, which is a parent node of the first relay node, using a MAC control element format.
  • CE MAC control element
  • a communication control method is a communication control method used in a cellular communication system.
  • the communication control method includes setting an integrated buffer status report to the first relay node by a higher node of the first relay node. Further, in the communication control method, the first relay node transmits the integrated buffer status report storing the buffer size corresponding to the logical channel group classified by type of the buffer status report according to the setting to the first relay node. transmitting to a second relay node that is a parent node of the relay node;
  • a communication control method is a communication control method used in a cellular communication system.
  • a donor base station having a first relay node and a second relay node that is a parent node of the first relay node under control performs local rerouting and conditional handover to the first relay node. (CHO) setting.
  • the communication control method is such that the first relay node responds to a failure occurring in the backhaul link from the second relay node and between the second relay node and the parent node of the second relay node. receiving a failure recovery notification indicating that recovery from the failure is being attempted.
  • the communication control method includes the first relay node performing local rerouting or conditional handover in response to receiving the failure recovery notification.
  • FIG. 1 is a diagram showing a configuration example of a cellular communication system according to one embodiment.
  • FIG. 2 is a diagram showing the relationship between IAB nodes, parent nodes, and child nodes.
  • FIG. 3 is a diagram illustrating a configuration example of a gNB (base station) according to one embodiment.
  • FIG. 4 is a diagram showing a configuration example of an IAB node (relay node) according to one embodiment.
  • FIG. 5 is a diagram illustrating a configuration example of a UE (user equipment) according to one embodiment.
  • FIG. 6 is a diagram showing an example of protocol stacks for IAB-MT RRC connection and NAS connection.
  • FIG. 7 is a diagram representing an example protocol stack for the F1-U protocol.
  • FIG. 8 is a diagram representing an example protocol stack for the F1-C protocol.
  • FIG. 9A is a diagram showing an example of legacy BSR transmission according to the first embodiment
  • FIGS. 9B and 9C are diagrams showing examples of transmission of preemptive BSR according to the first embodiment.
  • FIG. 10(A) is a diagram showing a configuration example of a short BSR MAC CE according to the first embodiment
  • FIG. 10(B) is a diagram showing a configuration example of a long BSR MAC CE.
  • FIG. 11 is a diagram showing an operation example according to the first embodiment.
  • FIG. 12A is a diagram showing a configuration example of a cellular communication system according to the first embodiment
  • FIG. 12B is a diagram showing an operation example according to a modification of the first embodiment.
  • FIGS. 13(A) and 13(B) are diagrams showing an example of the BSR MAC CE of the fixed extended format according to the second embodiment.
  • FIGS. 14(A) and 14(B) are diagrams showing an example of BSR MAC CE of fixed extended format according to the second embodiment.
  • FIGS. 15(A) and 15(B) are diagrams showing examples of BSR MAC CE of the variable extension format according to the second embodiment.
  • FIG. 16 is a diagram showing an operation example according to the second embodiment.
  • FIG. 17 shows an operation example according to a modification of the second embodiment.
  • FIG. 18 is a diagram showing an operation example according to the third embodiment.
  • FIG. 19 is a diagram showing an example of relationships between nodes according to the fourth embodiment.
  • FIG. 20 is a diagram showing an operation example according to the fourth embodiment.
  • FIG. 21 is a diagram showing an operation example according to a modification of the fourth embodiment.
  • FIG. 22 is a diagram showing the types of BH RLF notifications.
  • the cellular communication system is a 3GPP 5G system.
  • the radio access scheme in the cellular communication system 1 is NR (New Radio), which is a 5G radio access scheme.
  • NR New Radio
  • LTE Long Term Evolution
  • 6G future cellular communication systems such as 6G may be applied to the cellular communication system.
  • FIG. 1 is a diagram showing a configuration example of a cellular communication system 1 according to one embodiment.
  • a cellular communication system 1 includes a 5G core network (5GC) 10, a user equipment (UE) 100, a base station device (hereinafter sometimes referred to as a "base station") 200. -1, 200-2, and IAB nodes 300-1, 300-2.
  • Base station 200 may be referred to as a gNB.
  • the base station 200 is an NR base station
  • the base station 200 may be an LTE base station (that is, an eNB).
  • base stations 200-1 and 200-2 may be called gNB 200 (or base station 200), and IAB nodes 300-1 and 300-2 may be called IAB node 300, respectively.
  • the 5GC 10 has AMF (Access and Mobility Management Function) 11 and UPF (User Plane Function) 12.
  • the AMF 11 is a device that performs various mobility controls and the like for the UE 100 .
  • the AMF 11 manages information on the area in which the UE 100 resides by communicating with the UE 100 using NAS (Non-Access Stratum) signaling.
  • the UPF 12 is a device that controls transfer of user data.
  • Each gNB 200 is a fixed wireless communication node and manages one or more cells.
  • a cell is used as a term indicating the minimum unit of a wireless communication area.
  • a cell may be used as a term indicating a function or resource for radio communication with the UE 100. Also, a cell may be used without distinguishing it from a base station, such as the gNB 200 .
  • One cell belongs to one carrier frequency.
  • Each gNB 200 is interconnected with the 5GC 10 via an interface called NG interface.
  • NG interface an interface that connects to 5GC 10 to 5GC 10 to 5GC 10 to 5GC 10 to 5GC 10 to 5GC 10.
  • Each gNB 200 may be divided into a central unit (CU: Central Unit) and a distributed unit (DU: Distributed Unit).
  • CU and DU are interconnected through an interface called the F1 interface.
  • the F1 protocol is a communication protocol between the CU and DU, and includes the F1-C protocol, which is a control plane protocol, and the F1-U protocol, which is a user plane protocol.
  • the cellular communication system 1 supports IAB that enables wireless relay of NR access using NR for backhaul.
  • Donor gNB or donor node, hereinafter sometimes referred to as “donor node” 200-1 is a terminal node of the NR backhaul on the network side, and is a donor base station with additional functions to support IAB. be.
  • the backhaul can be multi-hop over multiple hops (ie, multiple IAB nodes 300).
  • IAB node 300-1 wirelessly connects with donor node 200-1
  • IAB node 300-2 wirelessly connects with IAB node 300-1
  • the F1 protocol is carried over two backhaul hops. An example is shown.
  • the UE 100 is a mobile radio communication device that performs radio communication with cells.
  • UE 100 may be any device as long as it performs wireless communication with gNB 200 or IAB node 300 .
  • the UE 100 is a mobile phone terminal and/or a tablet terminal, a notebook PC, a sensor or a device provided in a sensor, a vehicle or a device provided in a vehicle, an unmanned aerial vehicle or a device provided in an unmanned aerial vehicle.
  • UE 100 wirelessly connects to IAB node 300 or gNB 200 via an access link.
  • FIG. 1 shows an example in which UE 100 is wirelessly connected to IAB node 300-2.
  • UE 100 indirectly communicates with donor node 200-1 through IAB node 300-2 and IAB node 300-1.
  • FIG. 2 is a diagram showing the relationship between the IAB node 300, parent nodes, and child nodes.
  • each IAB node 300 has an IAB-DU equivalent to a base station functional unit and an IAB-MT (Mobile Termination) equivalent to a user equipment functional unit.
  • IAB-DU equivalent to a base station functional unit
  • IAB-MT Mobile Termination
  • a neighboring node (ie, upper node) on the NR Uu radio interface of an IAB-MT is called a parent node.
  • the parent node is the DU of the parent IAB node or donor node 200 .
  • a radio link between an IAB-MT and a parent node is called a backhaul link (BH link).
  • FIG. 2 shows an example in which the parent nodes of IAB node 300 are IAB nodes 300-P1 and 300-P2. Note that the direction toward the parent node is called upstream.
  • the upper node of the UE 100 can correspond to the parent node.
  • Adjacent nodes (ie, lower nodes) on the NR access interface of the IAB-DU are called child nodes.
  • IAB-DU like gNB200, manages the cell.
  • the IAB-DU terminates the NR Uu radio interface to the UE 100 and subordinate IAB nodes.
  • IAB-DU supports the F1 protocol to the CU of donor node 200-1.
  • FIG. 2 shows an example in which child nodes of IAB node 300 are IAB nodes 300-C1 to 300-C3, but child nodes of IAB node 300 may include UE100. Note that the direction toward a child node is called downstream.
  • all IAB nodes 300 connected to the donor node 200 via one or more hops have a directed acyclic graph (DAG) topology (hereinafter referred to as (sometimes referred to as "topology").
  • DAG directed acyclic graph
  • adjacent nodes on the IAB-DU interface are child nodes
  • adjacent nodes on the IAB-MT interface are parent nodes, as shown in FIG.
  • the donor node 200 centralizes, for example, IAB topology resources, topology, route management, and the like.
  • Donor node 200 is a gNB that provides network access to UE 100 via a network of backhaul links and access links.
  • FIG. 3 is a diagram showing a configuration example of the gNB 200.
  • the gNB 200 has a wireless communication unit 210, a network communication unit 220, and a control unit 230.
  • the wireless communication unit 210 performs wireless communication with the UE 100 and wireless communication with the IAB node 300.
  • the wireless communication section 210 has a receiving section 211 and a transmitting section 212 .
  • the receiver 211 performs various types of reception under the control of the controller 230 .
  • Reception section 211 includes an antenna, converts (down-converts) a radio signal received by the antenna into a baseband signal (reception signal), and outputs the baseband signal (reception signal) to control section 230 .
  • the transmission section 212 performs various transmissions under the control of the control section 230 .
  • the transmitter 212 includes an antenna, converts (up-converts) a baseband signal (transmission signal) output from the controller 230 into a radio signal, and transmits the radio signal from the antenna.
  • the network communication unit 220 performs wired communication (or wireless communication) with the 5GC 10 and wired communication (or wireless communication) with other adjacent gNBs 200.
  • the network communication section 220 has a receiving section 221 and a transmitting section 222 .
  • the receiving section 221 performs various types of reception under the control of the control section 230 .
  • the receiver 221 receives a signal from the outside and outputs the received signal to the controller 230 .
  • the transmission section 222 performs various transmissions under the control of the control section 230 .
  • the transmission unit 222 transmits the transmission signal output by the control unit 230 to the outside.
  • the control unit 230 performs various controls in the gNB200.
  • 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 for processing by the processor.
  • the processor may include a baseband processor and a CPU (Central Processing Unit).
  • the baseband processor modulates/demodulates and encodes/decodes the baseband signal.
  • the CPU executes programs stored in the memory to perform various processes.
  • the processor processes each layer, which will be described later.
  • the control unit 230 may perform various processes in the gNB 200 (or the donor node 200) in each embodiment described below.
  • FIG. 4 is a diagram showing a configuration example of the IAB node 300.
  • the IAB node 300 has a radio communication section 310 and a control section 320 .
  • the IAB node 300 may have multiple wireless communication units 310 .
  • 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.
  • the wireless communication unit 310 has a receiving unit 311 and a transmitting unit 312.
  • the receiver 311 performs various types of reception under the control of the controller 320 .
  • Receiving section 311 includes an antenna, converts (down-converts) a radio signal received by the antenna into a baseband signal (reception signal), and outputs the baseband signal (reception signal) to control section 320 .
  • the transmission section 312 performs various transmissions under the control of the control section 320 .
  • the transmitter 312 includes an antenna, converts (up-converts) a baseband signal (transmission signal) output from the controller 320 into a radio signal, and transmits the radio signal from the antenna.
  • the control unit 320 performs various controls in the IAB node 300.
  • 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 for processing by the processor.
  • a processor may include a baseband processor and a CPU.
  • the baseband processor modulates/demodulates and encodes/decodes the baseband signal.
  • the CPU executes programs stored in the memory to perform various processes.
  • the processor processes each layer, which will be described later.
  • the control unit 320 may perform various processes in the IAB node 300 in each embodiment described below.
  • FIG. 5 is a diagram showing a configuration example of the UE 100. As shown in FIG. As shown in FIG. 5 , UE 100 has radio communication section 110 and control section 120 .
  • the wireless communication unit 110 performs wireless communication on the access link, that is, wireless communication with the gNB 200 and wireless communication with the IAB node 300. Also, the radio communication unit 110 may perform radio communication on the sidelink, that is, radio communication with another UE 100 .
  • the radio communication unit 110 has a receiving unit 111 and a transmitting unit 112 .
  • the receiver 111 performs various types of reception under the control of the controller 120 .
  • Reception section 111 includes an antenna, converts (down-converts) a radio signal received by the antenna into a baseband signal (reception signal), and outputs the baseband signal (reception signal) to control section 120 .
  • the transmitter 112 performs various transmissions under the control of the controller 120 .
  • the transmitter 112 includes an antenna, converts (up-converts) a baseband signal (transmission signal) output from the controller 120 into a radio signal, and transmits the radio signal from the antenna.
  • the control unit 120 performs various controls in the UE 100.
  • 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 for processing by the processor.
  • a processor may include a baseband processor and a CPU.
  • the baseband processor modulates/demodulates and encodes/decodes the baseband signal.
  • the CPU executes programs stored in the memory to perform various processes.
  • the processor processes each layer, which will be described later.
  • the control unit 120 may perform each process in the UE 100 in each embodiment described below.
  • FIG. 6 is a diagram showing an example of protocol stacks for IAB-MT RRC connection and NAS connection.
  • the IAB-MT of the IAB node 300-2 includes a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, and a PDCP (Packet Data Convergence Protocol) layer, RRC (Radio Resource Control) layer, and NAS (Non-Access Stratum) layer.
  • PHY physical
  • MAC Medium Access Control
  • RLC Radio Link Control
  • PDCP Packet Data Convergence Protocol
  • RRC Radio Resource Control
  • NAS Non-Access Stratum
  • the PHY layer performs encoding/decoding, modulation/demodulation, antenna mapping/demapping, and resource mapping/demapping. Data and control information are transmitted via physical channels between the IAB-MT PHY layer of the IAB node 300-2 and the IAB-DU PHY layer of the IAB node 300-1.
  • the MAC layer performs data priority control, retransmission processing by hybrid ARQ (HARQ: Hybrid Automatic Repeat reQuest), random access procedures, and the like. Data and control information are transmitted via transport channels between the MAC layer of the IAB-MT of the IAB node 300-2 and the MAC layer of the IAB-DU of the IAB node 300-1.
  • the MAC layer of IAB-DU contains the scheduler. The scheduler determines uplink and downlink transport formats (transport block size, modulation and coding scheme (MCS: Modulation and Coding Scheme)) and allocation resource blocks.
  • MCS Modulation and Coding Scheme
  • the RLC layer uses the functions of the MAC layer and PHY layer to transmit data to the RLC layer on the receiving side. Data and control information are transmitted over logical channels between the IAB-MT RLC layer of IAB node 300-2 and the IAB-DU RLC layer of IAB node 300-1.
  • 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 CU of the donor node 200 via radio bearers.
  • the RRC layer controls logical channels, transport channels and physical channels according to radio bearer establishment, re-establishment and release.
  • RRC signaling for various settings is transmitted. If there is an RRC connection with the donor node 200, the IAB-MT is in RRC connected state. When there is no RRC connection with the donor node 200, the IAB-MT is in RRC idle state.
  • the NAS layer located above the RRC layer performs session management and mobility management.
  • NAS signaling is transmitted between the NAS layer of IAB-MT of IAB node 300-2 and the NAS layer of AMF11.
  • FIG. 7 is a diagram representing the protocol stack for the F1-U protocol.
  • FIG. 8 is a diagram representing a protocol stack for the F1-C protocol.
  • the donor node 200 is split into CUs and DUs.
  • each of the IAB-MT of the IAB node 300-2, the IAB-DU of the IAB node 300-1, the IAB-MT of the IAB node 300-1, and the DU of the donor node 200 is It has a BAP (Backhaul Adaptation Protocol) layer as an upper layer.
  • the BAP layer is a layer that performs routing processing and bearer mapping/demapping processing.
  • the IP layer is transported over the BAP layer to allow routing over multiple hops.
  • BAP layer PDUs Protocol Data Units
  • backhaul RLC channels BH NR RLC channels
  • QoS Quality of Service
  • 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 .
  • the CU of the donor node 200 terminates the F1 interface to the IAB node 300 and the DU of the donor node 200.
  • CU of donor node 200 is the gNB-CU function of donor node 200 .
  • the DU of donor node 200 also hosts the IAB BAP sublayer and provides wireless backhaul to IAB node 300 .
  • DU of donor node 200 is the gNB-DU function of donor node 200 .
  • the F1-C protocol stack has an F1AP layer and an SCTP layer instead of the GTP-U layer and UDP layer shown in FIG.
  • the processing or operations performed by the IAB's IAB-DU and IAB-MT may be simply described as "IAB" processing or operations.
  • the IAB-DU of the IAB node 300-1 sends a BAP layer message to the IAB-MT of the IAB node 300-2, and the IAB node 300-1 sends the message to the IAB node 300-2.
  • DU or CU processing or operations of donor node 200 may also be described simply as "donor node” processing or operations.
  • upstream direction and the uplink (UL) direction may be used without distinction.
  • downstream direction and the downlink (DL) direction may be used interchangeably.
  • the BSR transmitted by the UE 100 (hereinafter referred to as “legacy BSR” as appropriate.) is the untransmitted uplink data amount of each layer of MAC, RLC, and PDCP (that is, the amount of uplink buffer) is a logical channel It shows for each group (LCG).
  • Each LCG is a group that includes at least one logical channel and is set according to priority.
  • gNB 200 grasps the untransmitted uplink data amount of UE 100 for each LCG, and performs scheduling so as to allocate uplink radio resources to UE 100 in accordance with this untransmitted uplink data amount. conduct.
  • FIG. 9(A) is a diagram showing an example of legacy BSR transmission according to the first embodiment.
  • it is represented as “Regular BSR”, but hereinafter, "Regular BSR” may also be referred to as legacy BSR.
  • FIG. 9(A) shows an example in which the IAB node 300-T transmits the legacy BSR to the parent node 300-P after receiving data from the child node 300-C.
  • the IAB-MT of the IAB node 300-T uses the legacy BSR to wait for transmission (or buffer ringing) is reported as the buffer size.
  • the IAB-DU of the parent node 300-P allocates uplink radio resources corresponding to this amount of data to the IAB node 300-T.
  • the IAB-MT of the IAB node 300-T uses the assigned uplink radio resources to transmit the data to the parent node 300-P.
  • FIGS. 9(B) and 9(C) are diagrams showing transmission examples of pre-emptive BSRs according to the first embodiment.
  • the IAB-MT of IAB node 300-T sends a preemptive BSR to parent node 300-P. Also, as shown in FIG. 9(C), after the IAB-DU of the IAB node 300-T receives the legacy BSR from the child node 300-C, before transmitting the UL grant to the child node 300-C, the IAB The IAB-MT of node 300-T sends a preemptive BSR to parent node 300-P.
  • the preemptive BSR is transmitted to the parent node 300-P at an earlier timing than the legacy BSR. Therefore, the preemptive BSR can reduce the UL scheduling delay (latency) of the parent node 300-P to the IAB node 300-T compared to the legacy BSR.
  • FIG. 10(A) is a diagram showing a configuration example of a short BSR (Short BSR) MAC CE (hereinafter sometimes referred to as "Short BSR MAC CE") according to the first embodiment.
  • Short BSR MAC CE is used when one LCG (Logical Channel Group) has data available for transmission. That is, when reporting the buffer size of one LCG, short BSR MAC CE is used.
  • the short BSR MAC CE includes an "LCG ID” area and a "buffer size” area.
  • the "LCG ID” area is an area in which the identification information of the logical channel group whose buffer size is reported is stored.
  • the area length of the "LCG ID” area is 3 bits.
  • the "buffer size area” is calculated according to a predetermined calculation procedure across all logical channels in the logical channel group after the MAC PDU is constructed (i.e., after the logical channel prioritization procedure). , is an area in which the total amount of available data is stored. The area length of the "buffer size" area is 5 bits.
  • FIG. 10(B) is a diagram showing a configuration example of a Long BSR MAC CE (hereinafter sometimes referred to as "Long BSR MAC CE") according to the first embodiment.
  • Long BSR MAC CE is used when there is more than one LCG (Logical Channel Group) with data available for transmission. That is, when reporting the buffer sizes of multiple LCGs, the long BSR MAC CE is used.
  • LCG Logical Channel Group
  • FIG. 10(B) also shows a configuration example of a preemptive BSR MAC CE (hereinafter sometimes referred to as "preemptive BSR MAC CE").
  • the BSR MAC CE shown in FIG. 10(B) includes an 'LCG i ' area and a 'buffer size area'.
  • the 'LCG i ' area is an area indicating that the buffer size of the logical channel group i exists. That is, setting LCG i to '1' indicates that the buffer size of logical channel group i is reported. On the other hand, if LCG i is set to '0', it indicates that the buffer size for logical channel group i is not reported.
  • the area length of the 'LCG i ' area is 8 bits.
  • the "buffer size” area is the same as the “buffer size” area of the short BSR MAC CE when the MAC CE shown in FIG. 10(B) is the long BSR MAC CE.
  • the "buffer size area” stores a predetermined buffer size.
  • the predetermined buffer size is the total amount of data expected to arrive at the IAB-MT of the IAB node 300 (IAB node 300-T in the case of FIG. 9) where the preemptive BSR was triggered, and It does not include the total amount of data currently available.
  • the short BSR MAC CE in FIG. 10(A) represents the MAC CE of the short truncated BSR.
  • the long BSR MAC CE in FIG. 10(B) represents the MAC CE of the long truncated BSR.
  • a truncated BSR is a BSR that corresponds to the padding bits (or padding data) that the MAC layer inserts when constructing a MAC PDU. If the padding bits are the same as the size of the short BSR with the subheader added, the MAC CE of FIG. 10(A) is used. Also, if the padding bits are larger than the size of the short BSR plus the subheader, the MAC CE of FIG. 10(B) is used.
  • short BSR MAC CE and short truncated BSR MAC CE are not distinguished, they may be described as short BSR MAC CE.
  • long BSR MAC CE, preemptive BSR MAC CE, and long truncated BSR MAC CE are not distinguished, they may be described as long BSR MAC CE.
  • preemptive BSR and legacy BSR may be referred to as "BSR" when not distinguished from each other.
  • the first embodiment is an example in which the IAB node 300 reports to the parent node the buffer size of each logical channel group associated with the number of hops.
  • a donor base station for example, donor node 200 having first and second relay nodes under its control sends a logical channel to a first relay node (for example, IAB node 300-T).
  • LCH logical channel group
  • the first relay node sends a buffer status report (BSR) to a second relay node (eg, parent node 300-P), which is the parent node of the first relay node, based on the correspondence information.
  • BSR buffer status report
  • the second relay node sends an uplink grant (UL grant) to the first relay node based on the correspondence information and the buffer status report.
  • the number of LCH hops and the LCG are linked.
  • the IAB node 300 uses the BSR to report the number of hops and the buffer size of the linked LCG to the parent node. Since the LCG and the number of hops are associated with each other, the parent node can grasp the buffer size in the LCG as a buffer size corresponding to the number of hops. The parent node allocates uplink radio resources to the IAB node 300 using not only the buffer size but also the number of hops.
  • the parent node can allocate more uplink radio resources than others to the IAB node 300 with a large delay (or a large number of hops), for example. Therefore, it is possible to reduce the delay and ensure the fairness of the entire topology.
  • FIG. 12A is a diagram showing a configuration example of the cellular communication system 1 according to the first embodiment.
  • the donor node 200 has IAB nodes 300-P, 300-T, and 300-C under its control.
  • the topology (or network) that donor node 200 builds may include other IAB nodes.
  • the parent node of the IAB node 300-T is the IAB node 300-P.
  • a child node of the IAB node 300-T is the IAB node 300-C.
  • the IAB node 300-P may be referred to as the parent node 300-P, and the IAB node 300-C as the child node 300-C.
  • the upper node of the IAB node 300-T may be the parent node 300-P. Also, the upper node of the IAB node 300-T may be the donor node 200. FIG. Note that the parent node 300-P may be the donor node 200. FIG.
  • the IAB node 300-T is connected to one parent node 300-P, but multiple parent nodes 300-P1, 300-P2, . . . may be connected with In this case, for example, the IAB node 300-T may be connected with the parent node 300-P1 and the parent node 300-P2 by Dual Connectivity.
  • a master cell group (MCG) in Dual Connectivity is set in the parent node 300-P1
  • a secondary cell group (SCG) is set in the parent node 300-P2. It becomes connectable to two parent nodes 300-P1 and 300-P2.
  • FIG. 12A shows an example in which the child node 300-C is connected to the IAB node 300-T, but instead of the child node 300-C, the UE 100 connects to the IAB node 300-T. may be connected. Moreover, both the child node 300-C and the UE 100 may be connected to the IAB node 300-T. In the following description, it is assumed that the child node 300-C is connected to the IAB node 300-T.
  • FIG. 11 is a diagram showing an operation example according to the first embodiment. The operation example shown in FIG. 11 will be described by appropriately using the configuration example of the cellular communication system 1 shown in FIG. 12(A).
  • step S10 the donor node 200 starts processing.
  • the donor node 200 sets the linking information in which the LCG is linked for each hop count to the IAB node 300-T (the IAB-MT or IAB-DU of it).
  • the linking information is classified according to the number of LCH hops. For example, as the linking information, the LCH hop count "2" is linked to LCG#8 to LCG#15, and the logical channel hop count "3" is linked to LCG#16 to LCG#32. and other information.
  • the number of hops may be the total number of hops in the route to which the LCH belongs.
  • the number of hops may be the number of hops that have passed to reach the IAB node 300-T on the LCH.
  • the number of hops may be the number of remaining hops from the IAB node 300-T to the donor node 200 on the LCH.
  • the linking information may be correspondence information representing the correspondence between the LCH hop count and the LCG.
  • the terms “associating” and “corresponding” may be used without distinction.
  • the CU of the donor node 200 may perform the setting by sending an RRC message including the linking information to the IAB-MT of the IAB node 300-T. Also, the CU of the donor node 200 may perform the setting by sending an F1AP message including the binding information to the IAB-DU of the IAB node 300-T.
  • the donor node 200 may set the linking information to the parent node 300-P.
  • the donor node 200 may perform the setting by sending an RRC message or an F1AP message containing the binding information to the parent node 300-P in the same manner as described above.
  • the parent node 300-P may be preconfigured with hard-coded linking information.
  • the IAB-MT of the IAB node 300-T transmits the BSR to the parent node 300-P according to the setting.
  • the BSR stores the buffer size for each LCG associated with the number of hops.
  • the BSR includes the buffer size of LCG#8 corresponding to the hop number "2", the buffer size of LCG#9 corresponding to the hop number "2", . . . , the buffer size of LCG#15 corresponding to the hop number “2”, . . . , the buffer size of LCG#16 corresponding to the hop count “3”, . . . is stored.
  • the BSR may be a legacy BSR as described above.
  • the BSR may be a preemptive BSR.
  • the IAB-DU of the parent node 300-P identifies the number of hops and buffer status for each LCG using the linking information upon receiving the BSR. For example, when the parent node 300-P receives a report of the buffer size of LCG#15 as the BSR, it uses the linking information to determine that the buffer size is the hop count “2” corresponding to LCG#15. ,Identify.
  • step S14 the IAB-DU of the parent node 300-P allocates uplink radio resources to the IAB-MT of the IAB node 300-T based on the binding information and the BSR.
  • the parent node 300-P then transmits the UL grant including the allocation information to the IAB node 300-T.
  • the IAB-DU of the parent node 300-P allocates more uplink radio resources than others to the IAB-MT of the IAB node 300-T in which the data of the LCG with a larger number of hops is staying. .
  • step S15 the series of processes ends.
  • a modification of the first embodiment is an example of allocating a plurality of LCGs for each number of hops to one LCH.
  • the first relay node for example, the IAB node 300-T
  • the first relay node identifies the logical channel group corresponding to the hop count of the packet received via the logical channel based on the correspondence information, Send a buffer status report containing the buffer size of the channel group to the second relay node (eg, parent node 300-P).
  • FIG. 12(B) is a diagram showing an operation example according to the modification of the first embodiment. The operation example shown in FIG. 12(B) will be described by appropriately using the configuration example of the cellular communication system 1 shown in FIG. 12(A).
  • N UE bearers are mapped to one LCH (BH RLC channel) (1:N mapping). It is assumed that each of the N UE bearers has a different route (number of hops).
  • the IAB node 300-T classifies the packets received via the LCH (BH RLC channel) by the number of hops in step S120.
  • the IAB node 300-T may confirm the hop count as follows, for example.
  • the hop count may be obtained from the header of the received packet. If hop count information is stored in the BAP header of the received BAP packet, (the IAB-DU of) the IAB node 300-T can confirm the hop count by acquiring the hop count information from the BAP header.
  • the hop count may be obtained from the implementation of the IAB node 300-T. That is, the IAB-DU of the IAB node 300-T knows from which BH RLC channel the packet was received. Each time the IAB-DU of the IAB node 300-T receives a packet, it notifies the IAB-MT of the IAB node 300-T which packet went through which route. The IAB-MT of the IAB node 300-T may acquire the hop count based on the information notified from the IAB-DU.
  • the IAB-MT of the IAB node 300-T identifies the LCG corresponding to the classified hop count based on the linking information, and calculates the buffer size for each LCG.
  • the IAB-MT of the IAB node 300-T sends a BSR containing the calculated buffer size to the parent node 300-P.
  • the IAB node 300-T After finishing the processing of step S120, the IAB node 300-T performs the processing from step S13 (FIG. 11) onward, as in the first embodiment.
  • the IAB node 300-T identifies the LCG for each packet and calculates the buffer size, so it can report the buffer size to the parent node 300-P for each packet.
  • the parent node 300-P can allocate more resources to the IAB node 300-T with the longer delayed packet than others. Therefore, it is possible to reduce the delay and further to ensure fairness.
  • the upper limit of the number of LCGs is 8 (eg, FIG. 10(B)) and 3 bits (eg, FIG. 10(B)). 10(A)).
  • the upper limit is expressed as "X number (Y bits)".
  • the upper limit of the number of LCHs is 65,536 (16 bits) for IAB-MT. If the upper limit of the number of LCGs is secured to the same extent as the upper limit of the number of LCHs, the upper limit of the number of LCGs can also be 65,536 (16 bits). Suppose that there are 65,536 (16 bits) LCGs for high-resolution scheduling. In such a case, when the IAB node 300 transmits 65,536 (16-bit) LCGs using the existing BSR MAC CE, it transmits the BSR shown in FIG. 10(B) 8192 times.
  • the upper limit value of LCG can be set, and the IAB node 300-T uses the BSR MAC CE format corresponding to the set upper limit value of LCG to convert the BSR to the parent node 300-P report to.
  • the IAB node 300-T supports fixed extended format BSR MAC CE and variable extended format BSR MAC CE. use.
  • the IAB node 300-T selects (or determines) the MAC CE format corresponding to the upper limit value of the LCG from among these MAC CE formats.
  • a higher node eg, parent node 300-P or donor node 200
  • a first relay node eg, IAB node 300-T
  • the first relay node determines the MAC Control Element (CE) format corresponding to the upper bound.
  • the first relay node sends a buffer status report to a second relay node (eg, parent node 300-P), which is the parent node of the first relay node, using the determined MAC control element format. to send.
  • CE MAC Control Element
  • the IAB node 300-T can report the BSR using the BSR MAC CE corresponding to the upper limit of the LCG, so it is possible to reduce the overhead since the BSR will not be sent multiple times. becomes.
  • FIGS. 13(A) and 13(B) are diagrams showing configuration examples of the BSR MAC CE of the fixed extended format according to the first embodiment.
  • 13(A) and 13(B) are diagrams showing an example in which the upper limit value of LCG is 16 (4 bits).
  • FIG. 13(A) shows an example of short BSR MAC CE when the upper limit value of LCG is 16 (4 bits).
  • FIG. 13(B) shows an example of a long BSR MAC CE when the LCG upper limit is 16 (4 bits).
  • the short BSR MAC CE has 4 bits in the "LCG ID" area to match the upper limit. One bit more than the short BSR MAC CE in FIG. 10(A).
  • the "LCG ID" area stores the identification information of the logical channel group for which the buffer size is reported, which is the same as the existing short BSR MAC CE (Fig. 10(A)).
  • the "BS” area has 5 bits.
  • the "BS” area also stores the total amount of available data according to a predetermined calculation procedure across all LCHs in the LCG, the same as the existing BSR MAC CE. After the "BS" area is "R" (reserved area).
  • the long BSR MAC CE has 16 "LCG i " areas (LCG 0 to LCG 15 ) in accordance with the upper limit.
  • the 'LCG i ' area also stores a value indicating that the same buffer size of LCGi exists as in the existing long BSR MAC CE.
  • the "BS" area shown in FIG. 13B also stores the same predetermined buffer size as the existing long BSR MAC CE.
  • FIGS. 14(A) and 14(B) are diagrams showing examples of the BSR MAC CE of the fixed extended format according to the second embodiment.
  • 14(A) and 14(B) both show an example in which the upper limit value of LCG is 256 (8 bits).
  • FIG. 14(A) shows an example of short BSR MAC CE when the upper limit value of LCG is 256 (8 bits).
  • FIG. 14(B) shows an example of a long BSR MAC CE when the upper limit value of LCG is 256 (8 bits).
  • the "LCG ID” area has 8 bits corresponding to the upper limit.
  • the "BS” area has 5 bits, and the rest are "R”.
  • the IAB node 300-T uses the BSR MAC CE of FIG. 13(A) or FIG. 13(B) when the LCG upper limit is set to 16 (4 bits). If the LCG upper limit is 256 (8 bits), it is decided to use the BSR MAC CE shown in FIG. 14(A) or FIG. 14(B).
  • the upper limit is an example, and when 32 (5 bits) is set as the upper limit, the IAB node 300-T uses a short BSR MAC CE with a 5-bit “LCG ID” area, or a “LCG i ” area may decide to use the long BSR MAC CE with 32 . In addition, when 64 (6 bits) is set as the upper limit, the IAB node 300-T uses a short BSR MAC CE with 6 bits of “LCG ID” or a long BSR with 64 “LCG i ” areas. It may decide to use MAC CE.
  • the IAB node 300-T may decide to use the short BSR MAC CE with the 'LCG ID' field corresponding to the upper limit value or the long BSR MAC CE with the 'LCG i ' field corresponding to the upper limit value. .
  • the IAB node 300-T decides to use the short BSR MAC CE when reporting the buffer size of a specific LCG, and the long BSR MAC CE when reporting the buffer sizes of multiple LCGs. should decide to use the
  • FIGS. 15(A) and 15(B) are diagrams showing examples of variable extension formats according to the second embodiment.
  • FIG. 15(A) represents an example of a short variable extension format for short BSR MAC CE
  • FIG. 15(B) represents an example of long variable extension format for long BSR MAC CE.
  • the short variable extension format further includes an "LCG range” area.
  • the "LCG range” area stores bits corresponding to the upper limit of LCG set in the IAB node 300-T. For example, if the upper limit of LCG is "16 (4 bits)", “00”, if the upper limit of LCG is "256 (8 bits)", “01”, and the upper limit of LCG is " "10” is stored in the case of "16,384 (14 bits)", and "11” is stored in the case that the upper limit value of LCG is "65,536 (16 bits)”.
  • the relationship between the LCG upper limit value and the bits stored in the "LCG range” area may be other than this. Also, the number of bits stored in the "LCG range” area may be 3 or more in accordance with the upper limit of the LCG.
  • the short variable extension format has an "LCG ID” area, but its bit length is variable according to the upper limit of LCG. That is, the "LCG ID” area existing in the (X) area of FIG. 15 (A) can be left-justified in order from the top in the (X) area on the drawing according to the upper limit value. Together with the "LCD ID” area (4 bits) other than the (X) area, it becomes the “LCD ID” area.
  • the upper limit value of LCG is 256 (8 bits)
  • the "BS" area is also aligned to the left following the "LCD ID” area, and the remaining area is "R”.
  • the upper limit of the LCG is 32 (5 bits)
  • the area on the left side of the uppermost area in the (X) area on the drawing will be included in the "LCG ID" area. Become.
  • the "BS" area has 5 bits.
  • the 'BS' field may be more than 5 bits.
  • the long variable extension format also includes an "LCG range" area.
  • the 'LCG range' area stores the same upper limit value of LCG as the 'LCG range' area of the short variable extension format.
  • the IAB node 300-T may optionally use a fixed extended format (FIGS. 13(A) to 14(B)) or a variable extended format (FIGS. 15(A) and 15(B)). good.
  • FIG. 16 is a diagram showing an operation example according to the second embodiment. The operation example shown in FIG. 16 will be described by appropriately using the configuration example of the cellular communication system 1 shown in FIG. 12(A).
  • the IAB node 300-T starts processing in step S30.
  • the upper node (parent node 300-P or donor node 200) sets the upper limit of LCG to the IAB node 300-T.
  • the upper limit values are, for example, 8 (3 bits), 16 (4 bits), 32 (5 bits), . . . , 256 (8 bits), . . . , 16,384 (16 bits), . . . , 65,536 (16 bits).
  • the IAB-DU of the parent node 300-P uses MAC CE or BAP Control PDU to the IAB-MT of the IAB node 300-T .
  • LCG should be set.
  • the CU of the donor node 200 uses the F1AP message or the RRC message to the IAB-DU (or IAB-MT) of the IAB node 300-T, An upper limit value for LCG may be set.
  • the donor node 200 may transmit the upper limit value of LCG to the parent node 300-P.
  • the IAB-MT of the IAB node 300-T that receives the setting of the upper limit of LCG from the donor node 200 may transmit the upper limit to the IAB-DU of the parent node 300-P.
  • the IAB-MT of the IAB node 300-T determines (or selects) the MAC CE format to be used according to the set upper limit. For example, the IAB-MT of the IAB node 300-T selects an existing format (for example, FIG. 10(A) or FIG. 10(B)) when the upper limit is eight. Also, for example, the IAB-MT of the IAB node 300-T, if the upper limit is 16 or more, fixed extension format (eg, FIG. 13 (A) to FIG. 14 (B)) or variable extension format (eg, 15(A) or 15(B)) is selected.
  • fixed extension format eg, FIG. 13 (A) to FIG. 14 (B)
  • variable extension format eg, 15(A) or 15(B)
  • step S33 the IAB-MT of the IAB node 300-T uses the determined format to transmit the legacy BSR and/or preemptive BSR to the parent node 300-P.
  • step S34 the IAB node 300-T ends the series of processes.
  • a modified example of the second embodiment is an example in which the LCG upper limit setting is set to different values for legacy BSR and preemptive BSR.
  • a higher node eg, parent node 300-P or donor node 200
  • sets different upper limits for legacy BSR and preemptive BSR to the first relay node eg, IAB node 300-T.
  • the IAB node 300-T can report buffer sizes according to different upper limits for legacy BSRs and preemptive BSRs. Specifically, for example, it is possible to meet a request that the scheduling resolution may be increased by increasing the upper limit of LCG and the upper limit of preemptive BSR may be small.
  • FIG. 17 is a diagram showing an operation example according to the modification of the second embodiment. The operation example shown in FIG. 17 will be described using the configuration example of the cellular communication system 1 shown in FIG. 12A as appropriate.
  • step S40 the upper node (parent node 300-P or donor node 200) starts processing.
  • the upper node sets the upper limit of LCG to the IAB node 300-T (the IAB-MT or IAB-DU of it) to different values for the legacy BSR and the preemptive BSR.
  • the upper limit value of LCG and the type of BSR are linked and set.
  • the settings may be made using an F1AP message or the like. If the upper node is the parent node 300-P, it may be set using BAP Control PDU or the like.
  • the IAB-MT of the IAB node 300-T determines (or changes) the MAC CE format to be used according to the BSR type. For example, the IAB-MT of the IAB node 300-T selects the BSR MAC CE format of FIG. 13(A) or FIG. 13(B) when the LCG upper limit value for the legacy BSR is 16 (4 bits). , when the upper limit value of LCG for preemptive BSR is 256 (8 bits), select the BSR MAC CE format of FIG. 14(A) or 14(B).
  • step S43 the IAB-MT of the IAB node 300-T transmits legacy BSR and preemptive BSR using the determined MAC CE format.
  • step S44 the IAB node 300-T ends the series of processes.
  • the third embodiment is an example of transmitting legacy BSR and preemptive BSR in one BSR MAC CE.
  • a higher node eg, parent node 300-P or donor node 200
  • a first relay node eg, IAB node 300-T
  • the first relay node in accordance with the settings, sends an integrated buffer status report storing buffer sizes corresponding to logical channel groups classified by type of buffer status report to the parent node of the first relay node.
  • a second relay node eg, parent node 300-P
  • a BSR MAC CE that has been combined into one may be referred to as an integrated BSR.
  • the integrated BSR for example, stores the LCG and the buffer size (BS) of each LCG, similar to the legacy BSR (or preemptive BSR).
  • BS buffer size
  • a MAC CE with the same format as the short BSR MAC CE may be used.
  • a MAC CE with the same format as the long BSR MAC CE may be used.
  • the IAB node 300-T will no longer transmit BSRs with different MAC CE formats, making it possible to prevent processing delays, for example.
  • FIG. 18 is a diagram showing an operation example according to the third embodiment. The operation example shown in FIG. 18 will be described using the configuration example of the cellular communication system 1 shown in FIG. 12A as appropriate.
  • step S50 the upper node (parent node 300-P or donor node 200) starts processing.
  • the upper node sets the integrated BSR to the IAB-MT of the IAB node 300-T.
  • the upper node may perform link setting between the LCG in the integrated BSR and the BSR type.
  • LCG#0 to LCG#3 of the integrated BSR correspond to LCG#0 to LCG#3 of the legacy BSR, respectively
  • LCG#4 to LCG#7 of the integrated BSR correspond to LCG#0 to LCG# of the preemptive BSR. 3, respectively, and settings that indicate that.
  • Such an integrated BSR setting may be set using BAP Control PDU or MAC CE when the upper node is the parent node 300-P. Also, if the upper node is the donor node 200, it may be set using an F1AP message, an RRC message, or the like. Also, the donor node 200 may perform the setting for the parent node 300-P.
  • the IAB-MT of the IAB node 300-T triggers the integrated BSR.
  • the trigger may be a legacy BSR trigger condition.
  • the trigger may also be a preemptive BSR trigger condition.
  • the IAB-MT of the IAB node 300-T may trigger the integrated BSR at the trigger timing of the legacy BSR.
  • the IAB-MT of the IAB node 300-T may trigger the integrated BSR at the trigger timing of the preemptive BSR.
  • the upper node may set in the IAB-MT of the IAB node 300-T which of the two trigger conditions should trigger the integrated BSR.
  • step S53 the IAB-MT of the IAB node 300-T identifies the legacy BSR buffer size (BS-L) and the preemptive BSR buffer size (BS-P). Then, the IAB-MT of the IAB node 300-T stores these buffer sizes in the integrated BSR's MAC CE in association with the LCG.
  • BS-L legacy BSR buffer size
  • BS-P preemptive BSR buffer size
  • the IAB node 300-T associates BS-L#0 to BS-L#3 with LCG#0 to LCG#3, respectively. Also, for example, the IAB node 300-T associates BS-P#0 to BS-P#3 with LCG#4 to LCG#7, respectively. Then, the IAB node 300-T, for example, stores BS-L#0 to BS-L#3 in the MAC CE of the integrated BSR as the buffer sizes of LCG#0 to LCG#3 of the integrated BSR. Also, the IAB node 300-T, for example, stores BS-P#0 to BS-P#3 in the MAC CE of the integrated BSR as the buffer sizes of LCG#4 to LCG#7 of the integrated BSR.
  • step S54 the IAB-MT of the IAB node 300-T transmits the integrated BSR to the parent node 300-P.
  • step S55 the IAB node 300-T ends the series of processes.
  • BH RLF Indication In a network composed of a plurality of IAB nodes 300 , a failure may occur in the backhaul link between the IAB nodes 300 . Such a failure is called "BH RLF (Backhaul Radio Link Failure)".
  • FIG. 19 is a diagram showing an example of relationships between nodes according to the fourth embodiment.
  • FIG. 19 also shows an example of BH RLF according to the fourth embodiment.
  • FIG. 19 shows an example in which BH RLF occurs in the BH link #1 between the IAB node 300-P1, which is the parent node of the IAB node 300-T, and the node 500, which is its parent node.
  • the IAB-DU of the parent node 300-P1 transmits a failure notification to the IAB node 300-T on the downstream side.
  • a failure occurrence notification indicating that a BH RLF has been detected is called a Type 1 BH RLF Indication.
  • the BH link RLF detected by the child node may be Type 1 BH RLF Indication.
  • a recovery attempt notification indicating that recovery from a failure (BH RLF) that occurred in a backhaul link is being attempted is called a Type 2 BH RLF Indication.
  • the example of FIG. 19 shows an example in which the parent node 300-P1 transmits a Type 2 BH RLF Indication to the IAB node 300-T.
  • Type 1 BH RLF Indication and Type 2 BH RLF Indication are not distinguished, they are called Type 1/2 BH RLF Indication.
  • Type 2 BH RLF Indication may be read as Type 1 BH RLF Indication.
  • Type 1 BH RLF Indication is sent when BH RLF is detected, and Type 2 BH RLF Indication is sent when recovery is attempted. Therefore, Type 1 BH RLF Indication and Type 2 BH RLF Indication are substantially the same notification.
  • the IAB node 300-T that has received the Type 2 BH RLF Indication can perform various controls. Details will be described later.
  • Type 2 BH RLF Indication may be referred to as Type 2 Indication.
  • BH RLF may occur on the backhaul link between the IAB nodes 300 .
  • data packets can be forwarded to the destination IAB node 300 (or donor node 200) via an alternative path. Transferring data packets using an alternative path when a line failure occurs is sometimes referred to as local rerouting. Local rerouting is done by ignoring the routing preferences set by the donor node 200 and choosing an alternate path. Alternatively, local rerouting may be performed by selecting an alternate path from among alternate path candidates set by donor node 200 .
  • condition handover In a typical handover, the UE 100 reports measurements of the radio conditions of the serving cell and/or neighboring cells to the gNB 200, and based on this report, the gNB 200 determines handover to the neighboring cell and sends a handover instruction to the UE 100. . For this reason, when the radio condition of the serving cell suddenly deteriorates, communication may be interrupted before handover is executed in general handover.
  • conditional handover can autonomously execute handover to a candidate cell corresponding to the trigger condition when a preset trigger condition is met. Therefore, it is possible to solve problems such as communication interruption in general handover.
  • Conditional handover execution conditions include one or more trigger conditions.
  • a conditional handover configuration includes candidate cells and trigger conditions.
  • a conditional handover configuration may include multiple combinations of candidate cells and trigger conditions.
  • Conditional handover is set, for example, by an RRC message from the CU of donor node 200 to (IAB-MT of) IAB node 300 and/or UE 100 .
  • the IAB node 300-T when the IAB node 300-T receives the Type 2 Indication from the parent node 300-P1, it can perform local rerouting and switch the connection destination to the parent node 300-P2. As a result, the IAB node 300-T can avoid the failed BH link #1 and transmit packets in the upstream direction to the target node (donor node 200), and provide continued service to the UE 100. can provide.
  • the IAB node 300-T receives a Type 2 Indication from the parent node 300-P1, it enables conditional handover. Specifically, the IAB node 300-T switches the connection from the parent node 300-P1 to the parent node 300-P2 by conditional handover. As a result, the IAB node 300-T can avoid the BH link #1 and transmit upstream packets to the destination node, thereby providing continuous service to the UE 100.
  • the IAB node 300-T can execute both local rerouting and conditional handover with reception of Type 2 Indication as a trigger, it selects which one to execute when Type 2 Indication is received. It is possible.
  • the donor node 200 is a node that manages the entire topology. Donor node 200 also has the ability to control the performance of the entire topology.
  • the donor node 200 can set to the IAB node 300-T whether to execute local rerouting or conditional handover by using reception of Type 2 Indication as a trigger.
  • a donor base station eg, donor node 200 having first and second relay nodes under its control sends a local Configure rerouting and conditional handover (CHO).
  • the first relay node receives the second relay node and the second relay node from the second relay node (for example, parent node 300-P1) that is the parent node of the first relay node. receive a failure recovery notification indicating that recovery from a failure that occurred on the backhaul link (eg, BH link #1) between the parent node (eg, node 500) of the .
  • the first relay node performs local rerouting or conditional handover according to the configuration and upon receiving the failure recovery notification.
  • the donor base station further configures to the first relay node whether to perform local rerouting or conditional handover in response to receiving the failure recovery notification.
  • the donor node 200 sets whether the local rerouting or the conditional handover is to be performed for the IAB node 300-T. can be realized.
  • FIG. 20 is a diagram showing an operation example according to the fourth embodiment. An operation example will be described using the configuration example shown in FIG. 19 as appropriate.
  • the donor node 200 starts processing in step S60.
  • step S61 the CU of the donor node 200 sets local rerouting and/or conditional handover to the IAB-MT of the IAB node 300-T.
  • the CU of donor node 200 may utilize RRC messages to configure local rerouting and/or conditional handover.
  • step S62 the CU of the donor node 200 sets the operation when receiving the Type 2 Indication to the IAB-MT of the IAB node 300-T.
  • the operation setting is a setting related to whether to execute local rerouting or conditional handover when a Type 2 Indication is received (or to prioritize).
  • the IAB node 300-T can transfer the packet to the parent node 300-P2 without performing connection switching setting processing. Therefore, from a short-term perspective, there is an advantage that the service can be continued without interruption of communication.
  • the CU of the donor node 200 may set the operation settings to the IAB-MT of the IAB node 300-T using an RRC message.
  • step S63 the IAB-MT of the IAB node 300-T receives Type 2 Indication from the IAB-DU of the parent node 300-P1.
  • step S64 the IAB-MT of the IAB node 300-T executes local rerouting or conditional handover according to the settings.
  • the IAB node 300-T ends a series of processes.
  • a modification of the fourth embodiment is an example in which rules are determined in advance, and the IAB node 300-T executes local rerouting or conditional handover according to the rules, triggered by the reception of the Type 2 Indication.
  • the first relay node for example, the IAB node 300-T
  • the first relay node performs local rerouting or Perform a conditional handover.
  • preset means, for example, being set (stored) in memory when the IAB node 300-T is installed.
  • the IAB-MT of the IAB node 300-T reads out the information about the setting from the memory and executes it, thereby triggering the reception of the Type 2 Indication to execute local rerouting or conditional handover. Alternatively, it may be determined by hard coding in the specification.
  • FIG. 21 is a diagram showing an operation example according to the modification of the fourth embodiment. Steps S71 and S72 are the same as steps S61 and S63 of the fourth embodiment, respectively.
  • the IAB node 300-T executes local rerouting or conditional handover according to predetermined rules.
  • Predetermined rules include, for example, the following. That is, the IAB node 300-T performs local rerouting when a Dual Connectivity connection is established and a path (alternative path) for performing local rerouting exists. Also, the IAB node 300-T executes a conditional handover when there is no Dual Connectivity connection or when there is no path (alternative path) for local rerouting.
  • step S74 the IAB node 300-T ends the series of processes.
  • a program that causes a computer to execute each process performed by the UE 100, the gNB 200, or the IAB node 300 may be provided.
  • the program may be recorded on a computer readable medium.
  • a computer readable medium allows the installation of the program on the computer.
  • 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, but may be, for example, a recording medium such as CD-ROM or DVD-ROM.
  • a circuit that executes each process performed by the UE 100, the gNB 200, or the IAB node 300 is integrated, and at least a part of the UE 100, the gNB 200, or the IAB node 300 is a semiconductor integrated circuit (chipset, SoC (system on a chip)).
  • chipsset, SoC system on a chip
  • the terms “based on” and “depending on,” unless expressly stated otherwise, “based only on.” does not mean The phrase “based on” means both “based only on” and “based at least in part on.” Similarly, the phrase “depending on” means both “only depending on” and “at least partially depending on.” Also, “obtain/acquire” may mean obtaining information among stored information, or it may mean obtaining information among information received from other nodes. or it may mean obtaining the information by generating the information.
  • the terms “include,” “comprise,” and variations thereof are not meant to include only the recited items, and may include only the recited items or in addition to the recited items. Means that it may contain further items.
  • references to elements using the "first,” “second,” etc. designations used in this disclosure do not generally limit the quantity or order of those elements. These designations may be used herein as a convenient method of distinguishing between two or more elements. Thus, references to first and second elements do not imply that only two elements may be employed therein, or that the first element must precede the second element in any way.
  • references to first and second elements do not imply that only two elements may be employed therein, or that the first element must precede the second element in any way.
  • Enhanced topology adaptation • Specification of procedures for inter-donor IAB node migration to enhance robustness and load balancing, including enhancements to reduce signaling load. • Specification of enhancements to reduce service disruption due to IAB node migration and BH RLF restoration. • Specification of enhanced topology redundancy, including support for CP/UP isolation. Topology, routing and transport enhancements: • Specification of enhancements to improve fairness, multi-hop delay, and congestion mitigation across the topology.
  • RAN2#113-e addresses the issues discussed in Rel-17: 'IF' for fairness, 'IL' for delay, or 'IC' for congestion. pointed out the issues marked with .
  • RAN2#113bis-e discussed possible solutions and only reached one consensus.
  • Appendix 1 discusses possible solutions to these problems, focusing on IF-4, IL-2, IL-3, IL-5, IL-6, IC-1 and IC-7.
  • IF-4 IF-4 was designated as: IF-4:
  • the IAB node cannot aggregate more bearers and/or provide more resources for BH RLC channels carrying bearers with a high load per bearer (i.e. the IAB node is cannot provide more resources for BH RLC channels with higher .
  • IF-4 Possible solutions for IF-4 are: • F1: The IAB node is configured with additional information by the CU. • F1-1: relates to the number of bearers in a particular BH RLC channel (actual number, average number, etc.). • F1-2: relates to the QoS of the bearer of a particular BH RLC channel. • F2: Additional information is added to the BAP header. ⁇ F2-1: Bearer ID. • F2-2: Bearer ID and hop count for a particular path. • F2-3: Number of UE DRBs in a particular BAP packet.
  • ⁇ per packet'' scheduling is superior to ⁇ per RLC channel'' scheduling from a technical point of view.
  • These scheduling can be done in the gNB's (or IAB-DU's) DL scheduler.
  • LCP basically provides "per RLC channel" scheduling. In this sense, it may not be necessary to do 'per packet' scheduling only for the DL, given the additional overhead of all BAP PDUs in the DL and UL. Therefore, to improve fairness across Rel-17 topologies, a simpler solution, the F1 solution, is better suited.
  • Proposal 1 RAN2 should agree that IAB donors set up IAB nodes using the number of bearers mapped to each BH RLC channel and the QoS of these bearers. That is, F1-1 and F1-2 are used to resolve IF-4.
  • IL-2 Multi-hop delay- IL-2 IL-2 has been designated as: IL-2: Due to current (Rel-16) limitations on the number of LCGs, IAB nodes may need to report joint buffer status for LCHs with significantly different QoS requirements.
  • IL-2 A possible solution for IL-2 is as follows.
  • L4 A new operation or function is specified for the IAB node.
  • L4-3 The number of LCGs in IAB-MT is increasing.
  • the current LCG The space is 8 (ie maxLCG-ID is 7), which is common for UE and IAB-MT.
  • the current LCH ID space is 32 (ie maxLC-ID).
  • the maximum number of BH LCH IDs i.e. maxLC-ID-Iab-r16
  • the BH LCH ID space i.e. BH-RLC channel ID-r16
  • IAB-MT may require 16,384 LCGs (14 bits). This is certainly feasible, but it may be a little large to add to MAC CE. Some companies have proposed expanding the LCG space to at least 16 (4 bits), or 256 (8 bits). Therefore, RAN2 needs to consider what is best for the extended LCG space.
  • Proposal 2 RAN2 should discuss the optimal maximum numbers for the extended LCG space: 16 (4 bits), 256 (8 bits), 16,384 (14 bits) and even 65,536 (16 bits) .
  • IL-3 IL-3 was designated as: IL-3: Calculation of preemptive BSR buffer size is left to the implementation in Rel-16 and may vary from vendor to vendor.
  • IL-3 A possible solution for IL-3 is as follows. • L4: A new operation or function is specified for the IAB node. L4-1: Buffer size calculation for preemptive BSR is specified.
  • the buffer size calculation is clearly specified. It is based on data available in MAC, RLC and PDCP. For RLC and PDCP, the procedure for calculating the amount of data is specified in each specification. In Rel-16, these mechanisms are reused for data volume calculation of preemptive BSR of IAB-MT.
  • the IAB node has a BAP layer instead of PDCP, and the BAP specification does not calculate the amount of data. Therefore, the current specification lacks data that can be used for transmission. To better schedule fairness across the topology, the buffer size reported in the legacy BSR needs to be more accurate.
  • the calculation of the preemptive BSR buffer size is highly dependent on the IAB-DU implementation, but the specification states that "the buffer size field is It specifies the total amount of data expected and does not include the amount of data currently available in the IAB-MT.”
  • the buffer size field is It specifies the total amount of data expected and does not include the amount of data currently available in the IAB-MT.
  • some IAB nodes, with preemptive BSRs, do not actually arrive may report a buffer size larger than It can be difficult to set the same principles between child nodes and parent nodes. For example, multi-vendor deployments lead to inefficient radio resource allocation, scheduling delays at parent nodes, and unfair resource requests between IABs and MTs. If the IAB node is set up with dual connectivity, it can become more ambiguous. Therefore, the preemptive BSR buffer size calculation needs to be specified more precisely.
  • the buffer size calculation is not specified for IAB-DU. That is, the buffered data at the receiving side (MAC and RLC) of the IAB-DU
  • Proposal 3 RAN2 should agree to specify buffer size calculation for preemptive BSR (and possibly legacy BSR). That is, L4-1 is used to resolve IL-3.
  • the MAC specification defines two conditions as follows. This means that the trigger condition is up to the IAB-MT implementation in Rel-16. Inappropriate UL grants occur because the parent node cannot accurately predict when data will actually be available for transmission.
  • a preemptive BSR may be triggered for the specific case of IAB-MT if any of the following events occur: - A UL grant is provided to a child IAB node or UE. - BSR is received from a child IAB node or UE.
  • the IAB node is configured to trigger a preemptive BSR on either UL grant transmission or BSR reception.
  • the preemptive BSR is actually used in the parent node's IAB-DU, the scheduler. Therefore, at this point, further consideration is needed as to whether the trigger condition is set by the IAB donor or dictated by the parent IAB node.
  • Proposal 4 RAN2 should agree that the triggers used for preemptive BSR are set at the IAB node. Whether done by the IAB donor or its parent IAB node requires further consideration.
  • IL-5 and IL-6 IL-5 has been designated as: • IL-5: CU cannot place bearers with low PDB on routes with less congestion risk (higher resource efficiency) or RLF-free routes.
  • a possible solution for IL-5 is as follows.
  • L3 Additional signaling is introduced from the IAB node to the CU.
  • L3-1 The IAB node's buffer/link status is shared with the CU.
  • L3-2 Individual hop delay measurements per BH RLC channel are shared with the CU.
  • L4 A new operation or function is specified for the IAB node.
  • L4-2 Local rerouting is allowed for purposes other than RLF (eg, based on outgoing link delay).
  • • F4-1 relates to load information per BH RLC channel.
  • • F4-2 relates to per-hop delay and per-hop packet loss on individual links.
  • IL-6 has been designated as: • IL-6: CU cannot configure routing based on actual (real-time) delay per BH RLC channel.
  • IL-6 A possible solution for IL-6 is as follows. • L3: Additional signaling is introduced from the IAB node to the CU. L3-2: Individual hop delay measurements per BH RLC channel are shared with the CU. • F4: Additional signaling is introduced from the IAB node to the CU. • F4-2: relates to per-hop delay and per-hop packet loss on individual links. • L4: A new operation or function is specified for the IAB node. • L4-2: Local rerouting is allowed for purposes other than RLF (eg, based on outgoing link delay).
  • IL-5 and IL-6 may have commonalities regarding additional signaling from the IAB node to the IAB donor, namely L3 and L4, which could be centralized optimization.
  • L3 and L4 which could be centralized optimization.
  • MDT and/or SON procedure can be viewed as a type of MDT and/or SON procedure, as it allows for
  • Proposal 5 RAN2 should agree that IAB nodes report hop-by-hop delay measurements to IAB donors. That is, L3-2 is used to resolve IL-5 and IL-6.
  • RAN2 has already agreed that "type 2 RLF indications can be used to trigger local rerouting" and "local rerouting can be triggered by hop-by-hop flow control indications". Therefore, there is no need to discuss this issue further in this agenda item. Thus, the details of local rerouting can be discussed in another agenda item on enhancing topology adaptation.
  • IC-1 and IC-7 were annotated and designated as follows.
  • R2 concluded that there is sufficient interest among companies to address two issues.
  • IC-1 Existing Rel-16 DL HbH flow control mechanisms cannot be used to alleviate long-term downstream congestion on a single link without relying on packet drops.
  • IC-7 CU (not aware of local congestion) cannot update routing paths that are congested. Both IC-1 and CI-7 are associated with RAN3. It is currently unclear to what extent RAN2 will work on this, as RAN3 seems to be working on this as well.
  • CP-based congestion indications may include the following reports: - per BAP routing ID and/or - link per child node and/or - BH RLC CH ID (Down-selection needs further consideration).
  • CP-based congestion indication reuses the F1APGNB-DU status indication procedure.
  • CP-based congestion indication is related to DL congestion. For the UP-based approach to IAB congestion mitigation, we consider the following two options. ⁇ There is no functional enhancement. • A packet-marking-based approach.
  • an IAB donor When an IAB donor receives a congestion indication from an IAB node, it can be assumed that the IAB donor can avoid the congested path as implied in the RAN2 agreement above. There are several ways to deal with this problem. That is, the IAB donor updates routing settings or directs local rerouting. In the latter case, RAN2 may be involved in how congestion indications are used. In either case, RAN2 must wait for RAN3 to make a decision before making a decision.
  • Finding 4 RAN2 may be involved in how IAB donors behave due to signs of congestion after RAN3 has learned the details.
  • Enhanced topology adaptation • Specification of procedures for inter-donor IAB node migration to enhance robustness and load balancing, including enhancements to reduce signaling load. • Specification of enhancements to reduce service disruption due to IAB node migration and BHRLF recovery. • Specification of enhanced topology redundancy, including support for CP/UP isolation. Topology, routing and transport enhancements: • Specification of enhancements to improve fairness, multi-hop delay, and congestion mitigation across the topology.
  • Appendix 2 discusses various topics of Rel-17eIAB topology adaptation enhancements in addition to the current agreement. Specifically, enhancement of BH RLF indication, enhancement of conditional handover, and enhancement of local rerouting.
  • Rel-16 BH RLF indication This allows the child IAB-MT to recognize the RLF on the parent node's BH link and initiate the RLF recovery procedure.
  • Finding 1 Only Type 4 "recovery failure" was designated as a Rel-16 BH RLF indication.
  • RAN2 agreed to introduce Type 2 “Recovery Attempt” and Type 3 “BH Link Recovery”, but detailed IAB node behavior remains for further study. is necessary.
  • RAN2#113-e RAN2 supporting type 2/3 RLF indication (details need further study).
  • a type 2 RLF indication can be used to trigger local rerouting.
  • Type 2 RLF indications can be used to trigger deactivation of IABs supported by SIBs.
  • Type 2 RLF indications can be used to trigger deactivation or reduction of SR and/or BSR transmissions.
  • RAN2#113bis-e Further consideration is needed if other CHO execution conditions are required (eg, whether a Type 2 RLF indication can be used as a trigger).
  • One of the things under further consideration is whether/how to specify the actions associated with the three possible use cases of the new BHR LF indication that RAN2 has already agreed.
  • the trigger since BH RLF occurs in the UL from the perspective of the IAB node receiving the Type 2 BH RLF indication, the trigger should enable upstream local rerouting, i.e. UL path switching.
  • downstream local rerouting is independent of Type 2 BH RLF indications, as IAB nodes receiving Type 2 BH RLF indications can maintain good BH links with downstream nodes. It can therefore be regarded as an IAB-MT operation that needs to be explicitly specified.
  • Proposal 1 RAN2 should agree to specify that local rerouting should be triggered on the upstream path when IAB-MT receives a type 2 BH RLF indication from the parent node.
  • Proposal 2 RAN2 specifies that when IAB-MT receives a type 3 BH RLF indication from the parent node, it stops local rerouting on the upstream path, i.e. returns to the configured "normal" routing have to agree.
  • the deactivation of the IAB support IE in SIB1 it can be regarded as an IAB-DU operation that was widely considered until its implementation in Rel-16. Therefore, specifying only at stage 2 is probably sufficient. In particular, it can be assumed that the IAB-DU will not remove the IAB-Support IE from SIB1 if there are still alternative routes to the donor. This should be clarified when behavior is specified.
  • Proposal 3 RAN2 should consider whether to remove the IAB-Support IE from SIB1 if the IAB-DU receives a Type 2 BH RLF indication only in stage 2 and there is no alternative route to the IAB donor. be.
  • the IAB-MT will not initiate connection establishment to the parent node.
  • One question is whether the UE is allowed access to the cell (ie parent node) even if the parent node is under BH RLF.
  • the RRC setup request cannot reach the CU, ie the donor, which ultimately harms the user.
  • the cell has the option of barring UE access, stopping SSB transmissions, or broadcasting a type 2BH RLF indication via SIB1. Similar to Proposal 3, if the IAB node has an alternative route to the donor, there is no need to remove the IAB Support IE from SIB1.
  • Proposal 4 RAN2 should consider whether to bar UE access in addition to IAB-MT access when IAB-DU receives Type 2 BH RLF indication and there is no alternative route to the IAB donor. be.
  • Deactivation or reduction of SR and/or BSR transmissions may be considered IAB-MT actions and should be explicitly specified.
  • deactivation may be easier from a specification standpoint.
  • SR and/or BSR can only be sent after receiving Type 3, which can lead to scheduling delays.
  • Reduce on the other hand, may cause unwanted interference, but may allow scheduling to resume immediately after the BH link is restored. Therefore, RAN2 needs to discuss whether to support SR and/or BSR "deactivation", "reduction”, or both. If both are supported, they should be configurable by the IAB donor.
  • Proposal 5 RAN2 should agree to specify that SR and/or BSR transmissions should be deactivated or reduced when IAB-MT receives a Type 2 BH RLF indication from the parent node .
  • Proposal 6 RAN2 should agree to specify that when IAB-MT receives a type 3 BH RLF indication from the parent node, it can resume normal procedures for SR and/or BSR transmission.
  • Proposal 7 RAN2 supports 'deactivation', 'reduction', or both (i.e. configurable) of SR and/or BSR when a Type 2 BH RLF indication is received from a parent node need to consider whether
  • CHO is triggered by receipt of a Type 2BH RLF indication.
  • a Type 2 BH RLF indication sent, the parent node has experienced a BH RLF and is attempting to restore the BH link. This of course means that the IAB node cannot communicate with the donor. If the IAB node is configured with dual connectivity, it may choose to perform local rerouting between the MCG and SCG, as in Proposal 1.
  • IAB nodes need the option to trigger CHO when receiving a type 2BH RLF indication. Additionally, as a further optimization, it is worth considering whether the IAB node should cancel the CHO execution if it receives a type 3 BH RLF indication before it actually executes the CHO.
  • Proposal 8 RAN2 should agree to specify that CHO should be triggered when IAB-MT receives a type 2BH RLF indication from the parent node.
  • Proposal 9 RAN2 should consider whether to cancel CHO execution (if possible) when IAB-MT receives a type 3 BH RLF indication from the parent node.
  • Proposal 1 and Proposal 8 can be agreed upon, that is, for IAB nodes configured with dual connectivity, local rerouting, and CHO at the same time, when receiving a type 2 BH indication, either local rerouting or CHO You can choose to trigger.
  • local rerouting with type 2 reception helps avoid service interruptions, whereas CHO with type 2 reception is better for long-term/topology-wide performance. Since local rerouting and CHO are triggered by conditions other than type 2 reception, it is assumed that they are primarily configured for various purposes such as handover robustness due to event A3.
  • Proposal 10 If both Proposition 1 and Proposition 8 can be agreed, RAN2 should further agree that IAB donors can configure IAB nodes to trigger local rerouting or CHO because they have received a Type 2 BH RLF indication. There is
  • Type 2 and Type 3 BH RLF indications are considered as straightforward to be sent via BAP Control PDUs as is the case for Rel-16 Type 4 BH RLF indications. Similar to proposal 3 above, there is no BAP layer because the UE cannot receive BAP control PDUs. Therefore, it is possible that these BH RLF indications are broadcast over SIB1 and SIB1 is encoded by DU. Therefore, RAN2 needs to consider whether these are sent via BAP Control PDUs or SIB1.
  • Proposal 11 RAN2 should discuss whether Type 2 and Type 3 BH RLF indications are sent via BAP Control PDU or SIB1.
  • Conditional Handover was introduced in Rel-16 to improve mobility robustness. CHO can be used for designated Rel-16IAB. RAN2#113-e and RAN2#113-e have reached the following agreement. Therefore, it is worth considering eIAB CHO extensions in addition to Rel-16 CHO.
  • RAN2#113-e RAN2 discusses CHOs and starts with intra-donor CHO discussions until RAN3 proceeds with discussions on inter-donor IAB node migration.
  • RAN2 confirms the intention that Rel-16 CHO is/can be used for IAB-MT (whether changes are necessary requires further consideration).
  • RAN2 assumes that the Rel-16 specification is the baseline for setting default routes, IP addresses, and target paths for intra-donor CHOs.
  • RAN2#113bis-e IAB-MT CHO use cases should be migration and RLF recovery.
  • RAN2 requires a common solution for intra-CU/intra-DU CHO and intra-CU/inter-DU CHO.
  • CHO event A3 and CHO event A5 are applicable to IAB-MT. Further consideration is needed if other CHO execution conditions are required (eg, whether a Type 2 RLF indication can be used as a trigger).
  • IAB-MT For IAB-MT, selecting one of the triggered cells is not always the best approach, as IAB-MT implements depending on the local radio quality. This is because the overall topology goal may be effectively handled by IAB donors as discussed in RAN2#112-e. Therefore, RAN2 needs to consider how CHO implementation of IAB donor control with additional trigger conditions works as per Proposition 8. For example, an IAB donor can set priority information associated with a CHO candidate in the CHO settings. IAB-MT needs to select the highest priority cell from all triggered CHO candidates that meet a certain radio quality (such as S criteria).
  • Proposal 12 RAN2 should consider whether IAB donor-controlled CHO execution is required as an additional enhancement if all candidate cells trigger CHO upon receipt of a Type 2 BH RLF indication.
  • RAN2#113-e has reached the following agreements related to local rerouting enhancements.
  • a type 2 RLF indication can be used to trigger local rerouting.
  • Local rerouting can be triggered by indicating hop-by-hop flow control. Details such as trigger information, trigger conditions, and the role of CU settings need further study.
  • RAN2 considers inter-donor DU local rerouting in scope.
  • the IAB donor is the most appropriate entity to ensure the purpose of the overall topology.
  • IAB donor controllability should become more important. It is easy for IAB donors to set up alternate paths. This forces the IAB node to choose an alternate path when performing local rerouting. Alternate path modeling needs further study. For example, whether alternate paths have the same routing ID.
  • Proposal 13 RAN2 should consider whether IAB donors can set up IAB nodes using alternate paths in addition to Rel-16 routing settings.
  • IAB donors should be aware of local rerouting and consider that they can start/stop local rerouting at IAB nodes in order to coexist local rerouting and overall topology goals. . For example, based on knowledge of which IAB nodes are currently performing local rerouting, IAB donors can consider whether the goals of the overall topology are still being met. If the IAB donor finds that the objectives of the overall topology cannot be achieved, the IAB donor may instruct the IAB nodes to start/stop local rerouting, or the IAB donor may change the routing configuration of the entire IAB topology. be.
  • the IAB donor may need information and controllability of the local decision of the IAB node.
  • Proposal 14 RAN2 should consider whether IAB nodes need to notify IAB donors when starting/stopping local rerouting.
  • Proposal 15 RAN2 should discuss whether IAB donors can instruct IAB nodes to start/stop local rerouting.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、配下に第１の中継ノード及び当該第１の中継ノードの親ノードである第２の中継ノードを有するドナー基地局が、前記第１の中継ノードへ、論理チャネル（ＬＣＨ）のホップ数と論理チャネルグループ（ＬＣＧ）との対応関係を表す対応情報を設定することを含む。また、前記通信制御方法は、前記第１の中継ノードが、前記第２の中継ノードへ、前記対応情報に基づいて、バッファステータスレポート（ＢＳＲ）を送信することを含む。更に、前記通信制御方法は、前記第２の中継ノードが、前記第１の中継ノードへ、前記対応情報と前記バッファステータスレポートとに基づいて、アップリンクグラント（ＵＬ　ｇｒａｎｔ）を送信することを含む。

Description

通信制御方法
　本開示は、セルラ通信システムに用いる通信制御方法に関する。
　セルラ通信システムの標準化プロジェクトである３ＧＰＰ（Ｔｈｉｒｄ　Ｇｅｎｅｒａｔｉｏｎ　Ｐａｒｔｎｅｒｓｈｉｐ　Ｐｒｏｊｅｃｔ）において、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ　Ａｃｃｅｓｓ　ａｎｄ　Ｂａｃｋｈａｕｌ）ノードと呼ばれる新たな中継ノードの導入が検討されている（例えば、「３ＧＰＰ　ＴＳ　３８．３００　Ｖ１６．５．０（２０２１－０３）」参照）。１又は複数の中継ノードが、基地局とユーザ装置との間の通信に介在し、この通信に対する中継を行う。
　第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、配下に第１の中継ノード及び当該第１の中継ノードの親ノードである第２の中継ノードを有するドナー基地局が、第１の中継ノードへ、論理チャネル（ＬＣＨ）のホップ数と論理チャネルグループ（ＬＣＧ）との対応関係を表す対応情報を設定することを含む。また、前記通信制御方法は、第１の中継ノードが、第２の中継ノードへ、対応情報に基づいて、バッファステータスレポート（ＢＳＲ）を送信することを含む。更に、前記通信制御方法は、第２の中継ノードが、第１の中継ノードへ、対応情報とバッファステータスレポートとに基づいて、アップリンクグラント（ＵＬ　ｇｒａｎｔ）を送信することを含む。
　第２の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、第１の中継ノードの上位ノードが、第１の中継ノードへ、論理チャネルグループに関する設定値を設定することを含む。また、前記通信制御方法は、第１の中継ノードが、設定値に対応するＭＡＣコントロールエレメント（ＣＥ）フォーマットを決定することを含む。更に、前記通信制御方法は、第１の中継ノードが、第１の中継ノードの親ノードである第２の中継ノードへ、ＭＡＣコントロールエレメントフォーマットを用いて、バッファステータスレポートを送信することを含む。
　第３の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、第１の中継ノードの上位ノードが、第１の中継ノードへ、統合バッファステータスレポートの設定を行うことを含む。また、前記通信制御方法は、第１の中継ノードが、設定に従って、バッファステータスレポートの種別毎に分類された論理チャネルグループに対応するバッファサイズが格納された前記統合バッファステータスレポートを、第１の中継ノードの親ノードである第２の中継ノードへ送信することを含む。
　第４の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、第１の中継ノード及び当該第１の中継ノードの親ノードである第２の中継ノードを配下に有するドナー基地局が、第１の中継ノードへ、ローカルリルーティング及び条件付きハンドオーバ（ＣＨＯ）の設定を行うことを含む。また、前記通信制御方法は、第１の中継ノードが、第２の中継ノードから、当該第２の中継ノードと当該第２の中継ノードの親ノードとの間のバックホールリンクで発生した障害に対して当該障害からの回復を試行中であることを示す障害回復通知を受信することを含む。更に、前記通信制御方法は、第１の中継ノードが、障害回復通知の受信に応じて、ローカルリルーティング又は条件付きハンドオーバを実行することを含む。
図１は、一実施形態に係るセルラ通信システムの構成例を表す図である。 図２は、ＩＡＢノードと親ノード（Ｐａｒｅｎｔ　ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ　ｎｏｄｅｓ）との関係を表す図である。 図３は、一実施形態に係るｇＮＢ（基地局）の構成例を表す図である。 図４は、一実施形態に係るＩＡＢノード（中継ノード）の構成例を表す図である。 図５は、一実施形態に係るＵＥ（ユーザ装置）の構成例を表す図である。 図６は、ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックの例を表す図である。 図７は、Ｆ１－Ｕプロトコルに関するプロトコルスタックの例を表す図である。 図８は、Ｆ１－Ｃプロトコルに関するプロトコルスタックの例を表す図である。 図９（Ａ）は第１実施形態に係るレガシーＢＳＲの送信例、図９（Ｂ）と図９（Ｃ）は第１実施形態に係るプリエンプティブＢＳＲの送信例をそれぞれ表す図である。 図１０（Ａ）は第１実施形態に係るショートＢＳＲのＭＡＣ　ＣＥの構成例、図１０（Ｂ）はロングＢＳＲのＭＡＣ　ＣＥの構成例をそれぞれ表す図である。 図１１は、第１実施形態に係る動作例を表す図である。 図１２（Ａ）は第１実施形態に係るセルラ通信システムの構成例、図１２（Ｂ）は第１実施形態の変形例に係る動作例を表す図である。 図１３（Ａ）と図１３（Ｂ）は、第２実施形態に係る固定拡張フォーマットのＢＳＲ　ＭＡＣ　ＣＥの例を表す図である。 図１４（Ａ）と図１４（Ｂ）は、第２実施形態に係る固定拡張フォーマットのＢＳＲ　ＭＡＣ　ＣＥの例を表す図である。 図１５（Ａ）と図１５（Ｂ）は、第２実施形態に係る可変拡張フォーマットのＢＳＲ　ＭＡＣ　ＣＥの例を表す図である。 図１６は、第２実施形態に係る動作例を表す図である。 図１７は、第２実施形態の変形例に係る動作例を表す。 図１８は、第３実施形態に係る動作例を表す図である。 図１９は、第４実施形態に係るノード間の関係例を表す図である。 図２０は、第４実施形態に係る動作例を表す図である。 図２１は、第４実施形態の変形例に係る動作例を表す図である。 図２２は、ＢＨ　ＲＬＦ通知の種類を表す図である。
　図面を参照しながら、実施形態に係るセルラ通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
　（セルラ通信システムの構成）
　まず、一実施形態に係るセルラ通信システムの構成例について説明する。一実施形態に係るセルラ通信システムは３ＧＰＰの５Ｇシステムである。具体的には、セルラ通信システム１における無線アクセス方式は、５Ｇの無線アクセス方式であるＮＲ（Ｎｅｗ　Ｒａｄｉｏ）である。但し、セルラ通信システムには、ＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）が少なくとも部分的に適用されてもよい。また、セルラ通信システムは、６Ｇなど、将来のセルラ通信システムも適用されてよい。
　図１は、一実施形態に係るセルラ通信システム１の構成例を表す図である。
　図１に示すように、セルラ通信システム１は、５Ｇコアネットワーク（５ＧＣ）１０と、ユーザ装置（ＵＥ：Ｕｓｅｒ　Ｅｑｕｉｐｍｅｎｔ）１００、基地局装置（以下、「基地局」と称する場合がある。）２００－１，２００－２、及びＩＡＢノード３００－１，３００－２を有する。基地局２００は、ｇＮＢと呼ばれる場合がある。
　以下において、基地局２００がＮＲ基地局である一例について主として説明するが、基地局２００がＬＴＥ基地局（すなわち、ｅＮＢ）であってもよい。
　なお、以下において、基地局２００－１，２００－２をｇＮＢ２００（又は基地局２００）、ＩＡＢノード３００－１，３００－２をＩＡＢノード３００とそれぞれ称する場合がある。
　５ＧＣ１０は、ＡＭＦ（Ａｃｃｅｓｓ　ａｎｄ　Ｍｏｂｉｌｉｔｙ　Ｍａｎａｇｅｍｅｎｔ　Ｆｕｎｃｔｉｏｎ）１１及びＵＰＦ（Ｕｓｅｒ　Ｐｌａｎｅ　Ｆｕｎｃｔｉｏｎ）１２を有する。ＡＭＦ１１は、ＵＥ１００に対する各種モビリティ制御等を行う装置である。ＡＭＦ１１は、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００が在圏するエリアの情報を管理する。ＵＰＦ１２は、ユーザデータの転送制御等を行う装置である。
　各ｇＮＢ２００は、固定の無線通信ノードであって、１又は複数のセルを管理する。セルは、無線通信エリアの最小単位を示す用語として用いられる。セルは、ＵＥ１００との無線通信を行う機能又はリソースを示す用語として用いられることがある。また、セルは、ｇＮＢ２００など、基地局と区別しないで用いられる場合がある。１つのセルは１つのキャリア周波数に属する。
　各ｇＮＢ２００は、ＮＧインターフェイスと呼ばれるインターフェイスを介して５ＧＣ１０と相互に接続される。図１において、５ＧＣ１０に接続された２つのｇＮＢ２００－１及びｇＮＢ２００－２を例示している。
　各ｇＮＢ２００は、集約ユニット（ＣＵ：Ｃｅｎｔｒａｌ　Ｕｎｉｔ）と分散ユニット（ＤＵ：Ｄｉｓｔｒｉｂｕｔｅｄ　Ｕｎｉｔ）とに分割されてもよい。ＣＵ及びＤＵは、Ｆ１インターフェイスと呼ばれるインターフェイスを介して相互に接続される。Ｆ１プロトコルは、ＣＵとＤＵとの間の通信プロトコルであって、制御プレーンのプロトコルであるＦ１－ＣプロトコルとユーザプレーンのプロトコルであるＦ１－Ｕプロトコルとがある。
　セルラ通信システム１は、バックホールにＮＲを用いてＮＲアクセスの無線中継を可能とするＩＡＢをサポートする。ドナーｇＮＢ（又はドナーノード。以下、「ドナーノード」と称する場合がある。）２００－１は、ネットワーク側のＮＲバックホールの終端ノードであり、ＩＡＢをサポートする追加機能を備えたドナー基地局である。バックホールは、複数のホップ（すなわち、複数のＩＡＢノード３００）を介するマルチホップが可能である。
　図１において、ＩＡＢノード３００－１がドナーノード２００－１と無線で接続し、ＩＡＢノード３００－２がＩＡＢノード３００－１と無線で接続し、Ｆ１プロトコルが２つのバックホールホップで伝送される一例を示している。
　ＵＥ１００は、セルとの無線通信を行う移動可能な無線通信装置である。ＵＥ１００は、ｇＮＢ２００又はＩＡＢノード３００との無線通信を行う装置であればどのような装置であってもよい。例えば、ＵＥ１００は、携帯電話端末及び／又はタブレット端末、ノートＰＣ、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置、無人航空機若しくは無人航空機に設けられる装置である。ＵＥ１００は、アクセスリンクを介してＩＡＢノード３００又はｇＮＢ２００に無線で接続する。図１は、ＵＥ１００がＩＡＢノード３００－２と無線で接続される一例を示している。ＵＥ１００は、ＩＡＢノード３００－２及びＩＡＢノード３００－１を介してドナーノード２００－１と間接的に通信する。
　図２は、ＩＡＢノード３００と、親ノード（Ｐａｒｅｎｔ　ｎｏｄｅｓ）及び子ノード（Ｃｈｉｌｄ　ｎｏｄｅｓ）との関係を表す図である。
　図２に示すように、各ＩＡＢノード３００は、基地局機能部に相当するＩＡＢ－ＤＵとユーザ装置機能部に相当するＩＡＢ－ＭＴ（Ｍｏｂｉｌｅ　Ｔｅｒｍｉｎａｔｉｏｎ）とを有する。
　ＩＡＢ－ＭＴのＮＲ　Ｕｕ無線インターフェイス上の隣接ノード（すなわち、上位ノード）は、親ノードと呼ばれる。親ノードは、親ＩＡＢノード又はドナーノード２００のＤＵである。ＩＡＢ－ＭＴと親ノードとの間の無線リンクは、バックホールリンク（ＢＨリンク）と呼ばれる。図２において、ＩＡＢノード３００の親ノードがＩＡＢノード３００－Ｐ１及び３００－Ｐ２である一例を示している。なお、親ノードへ向かう方向は、アップストリーム（ｕｐｓｔｒｅａｍ）と呼ばれる。ＵＥ１００から見て、ＵＥ１００の上位ノードは親ノードに該当し得る。
　ＩＡＢ－ＤＵのＮＲアクセスインターフェイス上の隣接ノード（すなわち、下位ノード）は、子ノードと呼ばれる。ＩＡＢ－ＤＵは、ｇＮＢ２００と同様に、セルを管理する。ＩＡＢ－ＤＵは、ＵＥ１００及び下位のＩＡＢノードへのＮＲ　Ｕｕ無線インターフェイスを終端する。ＩＡＢ－ＤＵは、ドナーノード２００－１のＣＵへのＦ１プロトコルをサポートする。図２において、ＩＡＢノード３００の子ノードがＩＡＢノード３００－Ｃ１～３００－Ｃ３である一例を示しているが、ＩＡＢノード３００の子ノードにＵＥ１００が含まれてもよい。なお、子ノードへ向かう方向は、ダウンストリーム（ｄｏｗｎｓｔｒｅａｍ）と呼ばれる。
　また、１つ又は複数のホップを介して、ドナーノード２００に接続されている全てのＩＡＢノード３００は、ドナーノード２００をルートとする有向非巡回グラフ（ＤＡＧ：Ｄｉｒｅｃｔｅｄ　Ａｃｙｃｌｉｃ　Ｇｒａｐｈ）トポロジ（以下、「トポロジ」と称する場合がある。）を形成する。このトポロジにおいて、図２に示すように、ＩＡＢ－ＤＵのインターフェイス上の隣り合うノードが子ノード、ＩＡＢ－ＭＴのインターフェイス上の隣り合うノードが親ノードとなる。ドナーノード２００は、例えば、ＩＡＢトポロジのリソース、トポロジ、ルート管理などを集中的に行う。ドナーノード２００は、バックホールリンクとアクセスリンクのネットワークを介して、ＵＥ１００に対して、ネットワークアクセスを提供するｇＮＢである。
　（基地局の構成）
　次に、実施形態に係る基地局であるｇＮＢ２００の構成について説明する。図３は、ｇＮＢ２００の構成例を表す図である。図３に示すように、ｇＮＢ２００は、無線通信部２１０と、ネットワーク通信部２２０と、制御部２３０とを有する。
　無線通信部２１０は、ＵＥ１００との無線通信及びＩＡＢノード３００との無線通信を行う。無線通信部２１０は、受信部２１１及び送信部２１２を有する。受信部２１１は、制御部２３０の制御下で各種の受信を行う。受信部２１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部２３０に出力する。送信部２１２は、制御部２３０の制御下で各種の送信を行う。送信部２１２はアンテナを含み、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。
　ネットワーク通信部２２０は、５ＧＣ１０との有線通信（又は無線通信）及び隣接する他のｇＮＢ２００との有線通信（又は無線通信）を行う。ネットワーク通信部２２０は、受信部２２１及び送信部２２２を有する。受信部２２１は、制御部２３０の制御下で各種の受信を行う。受信部２２１は、外部から信号を受信して受信信号を制御部２３０に出力する。送信部２２２は、制御部２３０の制御下で各種の送信を行う。送信部２２２は、制御部２３０が出力する送信信号を外部に送信する。
　制御部２３０は、ｇＮＢ２００における各種の制御を行う。制御部２３０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサとＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）とを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部２３０は、以下に示す各実施形態において、ｇＮＢ２００（又はドナーノード２００）おける各種処理を行ってもよい。
　（中継ノードの構成）
　次に、実施形態に係る中継ノード（又は中継ノード装置。以下、「中継ノード」と称する場合がある。）であるＩＡＢノード３００の構成について説明する。図４は、ＩＡＢノード３００の構成例を表す図である。図４に示すように、ＩＡＢノード３００は、無線通信部３１０と、制御部３２０とを有する。ＩＡＢノード３００は、無線通信部３１０を複数有していてもよい。
　無線通信部３１０は、ｇＮＢ２００との無線通信（ＢＨリンク）及びＵＥ１００との無線通信（アクセスリンク）を行う。ＢＨリンク通信用の無線通信部３１０とアクセスリンク通信用の無線通信部３１０とが別々に設けられていてもよい。
　無線通信部３１０は、受信部３１１及び送信部３１２を有する。受信部３１１は、制御部３２０の制御下で各種の受信を行う。受信部３１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部３２０に出力する。送信部３１２は、制御部３２０の制御下で各種の送信を行う。送信部３１２はアンテナを含み、制御部３２０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。
　制御部３２０は、ＩＡＢノード３００における各種の制御を行う。制御部３２０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部３２０は、以下に示す各実施形態において、ＩＡＢノード３００における各種処理を行ってもよい。
　（ユーザ装置の構成）
　次に、実施形態に係るユーザ装置であるＵＥ１００の構成について説明する。図５は、ＵＥ１００の構成例を表す図である。図５に示すように、ＵＥ１００は、無線通信部１１０と、制御部１２０とを有する。
　無線通信部１１０は、アクセスリンクにおける無線通信、すなわち、ｇＮＢ２００との無線通信及びＩＡＢノード３００との無線通信を行う。また、無線通信部１１０は、サイドリンクにおける無線通信、すなわち、他のＵＥ１００との無線通信を行ってもよい。無線通信部１１０は、受信部１１１及び送信部１１２を有する。受信部１１１は、制御部１２０の制御下で各種の受信を行う。受信部１１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部１２０に出力する。送信部１１２は、制御部１２０の制御下で各種の送信を行う。送信部１１２はアンテナを含み、制御部１２０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。
　制御部１２０は、ＵＥ１００における各種の制御を行う。制御部１２０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部１２０は、以下に示す各実施形態において、ＵＥ１００における各処理を行ってもよい。
　（プロトコルスタックの構成）
　次に、実施形態に係るプロトコルスタックの構成について説明する。図６は、ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックの例を表す図である。
　図６に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Ｍｅｄｉｕｍ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）レイヤと、ＲＬＣ（Ｒａｄｉｏ　Ｌｉｎｋ　Ｃｏｎｔｒｏｌｌ）レイヤと、ＰＤＣＰ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｃｏｎｖｅｒｇｅｎｃｅ　Ｐｒｏｔｏｃｏｌ）レイヤと、ＲＲＣ（Ｒａｄｉｏ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌ）レイヤと、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）レイヤとを有する。
　ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＰＨＹレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。
　ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ：Ｈｙｂｒｉｄ　Ａｕｔｏｍａｔｉｃ　Ｒｅｐｅａｔ　ｒｅＱｕｅｓｔ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＭＡＣレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ＩＡＢ－ＤＵのＭＡＣレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ：Ｍｏｄｕｌａｔｉｏｎ　ａｎｄ　Ｃｏｄｉｎｇ　Ｓｃｈｅｍｅ））及び割当リソースブロックを決定する。
　ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＲＬＣレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
　ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＰＤＣＰレイヤとドナーノード２００のＣＵのＰＤＣＰレイヤとの間では、無線ベアラを介してデータ及び制御情報が伝送される。
　ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＲＲＣレイヤとドナーノード２００のＣＵのＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ドナーノード２００とのＲＲＣ接続がある場合、ＩＡＢ－ＭＴはＲＲＣコネクティッド状態である。ドナーノード２００とのＲＲＣ接続がない場合、ＩＡＢ－ＭＴはＲＲＣアイドル状態である。
　ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＮＡＳレイヤとＡＭＦ１１のＮＡＳレイヤとの間では、ＮＡＳシグナリングが伝送される。
　図７は、Ｆ１－Ｕプロトコルに関するプロトコルスタックを表す図である。図８は、Ｆ１－Ｃプロトコルに関するプロトコルスタックを表す図である。ここでは、ドナーノード２００がＣＵ及びＤＵに分割されている一例を示す。
　図７に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴ、ＩＡＢノード３００－１のＩＡＢ－ＤＵ、ＩＡＢノード３００－１のＩＡＢ－ＭＴ、及びドナーノード２００のＤＵの各々は、ＲＬＣレイヤの上位レイヤとしてＢＡＰ（Ｂａｃｋｈａｕｌ　Ａｄａｐｔａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）レイヤを有する。ＢＡＰレイヤは、ルーティング処理及びベアラマッピング・デマッピング処理を行うレイヤである。バックホールでは、ＩＰレイヤがＢＡＰレイヤを介して伝送されることにより、複数のホップでのルーティングが可能になる。
　各バックホールリンクにおいて、ＢＡＰレイヤのＰＤＵ（Ｐｒｏｔｏｃｏｌ　Ｄａｔａ　Ｕｎｉｔ）は、バックホールＲＬＣチャネル（ＢＨ　ＮＲ　ＲＬＣチャネル）によって伝送される。各ＢＨリンクで複数のバックホールＲＬＣチャネルを構成することにより、トラフィックの優先順位付け及びＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）制御が可能である。ＢＡＰ　ＰＤＵとバックホールＲＬＣチャネルとの対応付けは、各ＩＡＢノード３００のＢＡＰレイヤ及びドナーノード２００のＢＡＰレイヤによって実行される。
　なお、ドナーノード２００のＣＵは、ＩＡＢノード３００とドナーノード２００のＤＵへのＦ１インターフェイスを終端する。ドナーノード２００のＣＵは、ドナーノード２００のｇＮＢ－ＣＵ機能である。また、ドナーノード２００のＤＵは、ＩＡＢ　ＢＡＰサブレイヤをホストし、ＩＡＢノード３００へワイヤレスバックホールを提供する。ドナーノード２００のＤＵは、ドナーノード２００のｇＮＢ－ＤＵ機能である。
　図８に示すように、Ｆ１－Ｃプロトコルのプロトコルスタックは、図７に示すＧＴＰ－Ｕレイヤ及びＵＤＰレイヤに代えて、Ｆ１ＡＰレイヤ及びＳＣＴＰレイヤを有する。
　なお、以下においては、ＩＡＢのＩＡＢ－ＤＵとＩＡＢ－ＭＴとで行われる処理又は動作について、単に「ＩＡＢ」の処理又は動作として説明する場合がある。例えば、ＩＡＢノード３００－１のＩＡＢ－ＤＵが、ＩＡＢノード３００－２のＩＡＢ－ＭＴへＢＡＰレイヤのメッセージを送信することを、ＩＡＢノード３００－１がＩＡＢノード３００－２へ、当該メッセージを送信するものとして説明する。また、ドナーノード２００のＤＵ又はＣＵの処理又は動作についても、単に「ドナーノード」の処理又は動作として説明する場合がある。
　また、アップストリーム方向とアップリンク（ＵＬ）方向とを区別しないで用いる場合がある。更に、ダウンストリーム方向とダウンリンク（ＤＬ）方向とを区別しないで用いる場合がある。
（第１実施形態）
　次に第１実施形態について説明する。
（ＢＳＲ（Ｂｕｆｆｅｒ　Ｓｔａｔｕｓ　Ｒｅｐｏｒｔ）について）
　一般的に、ＵＥ１００が送信するＢＳＲ（以下、適宜「レガシーＢＳＲ」と呼ぶ。）は、ＭＡＣ、ＲＬＣ、及びＰＤＣＰの各レイヤの未送信上りリンクデータ量（すなわち、上りリンクバッファ量）を論理チャネルグループ（ＬＣＧ）ごとに示すものである。各ＬＣＧは少なくとも１つの論理チャネルを含み、優先度別に設定されるグループである。ｇＮＢ２００は、ＵＥ１００から受信したレガシーＢＳＲに基づいて、ＵＥ１００の未送信上りリンクデータ量をＬＣＧごとに把握し、この未送信上りリンクデータ量に見合った上りリンク無線リソースをＵＥ１００に割り当てるようにスケジューリングを行う。
　図９（Ａ）は、第１実施形態に係るレガシーＢＳＲの送信例を表す図である。図９（Ａ）では、「Ｒｅｇｕｌａｒ　ＢＳＲ」と表されているが、以下では、「Ｒｅｇｕｌａｒ　ＢＳＲ」もレガシーＢＳＲと称する場合がある。
　図９（Ａ）は、ＩＡＢノード３００－Ｔが、子ノード３００－Ｃからデータを受信後、レガシーＢＳＲを親ノード３００－Ｐへ送信する例を表している。
　図９（Ａ）に示すように、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、レガシーＢＳＲを利用して、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴにおけるＭＡＣとＲＬＣとに存在する送信待ち（又はバッファリングしている）データ量を、バッファサイズとして報告する。親ノード３００－ＰのＩＡＢ－ＤＵは、ＩＡＢノード３００－Ｔに対して、このデータ量に見合った上りリンク無線リソースを割り当てる。ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、割り当てられた上りリンク無線リソースを利用して、当該データを、親ノード３００－Ｐへ送信する。
　図９（Ｂ）及び図（Ｃ）は、第１実施形態に係るプリエンプティブＢＳＲ（ｐｒｅ－ｅｍｐｔｉｖｅ　ＢＳＲ）の送信例を表す図である。
　図９（Ｂ）に示すように、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵが、子ノード３００－Ｃへアップリンクグラント（ＵＬ　ｇｒａｎｔ）を送信後、子ノード３００－ＣからＵＬデータを受信する前に、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴが、プリエンプティブＢＳＲを親ノード３００－Ｐへ送信する。また、図９（Ｃ）に示すように、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵが、子ノード３００－ＣからレガシーＢＳＲを受信後、ＵＬ　ｇｒａｎｔを子ノード３００－Ｃへ送信する前に、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴが、プリエンプティブＢＳＲを親ノード３００－Ｐへ送信する。
　このように、プリエンプティブＢＳＲは、レガシーＢＳＲよりも早いタイミングで、親ノード３００－Ｐへ送信される。そのため、プリエンプティブＢＳＲは、レガシーＢＳＲの場合と比較して、親ノード３００－ＰのＩＡＢノード３００－Ｔに対するＵＬスケジューリングの遅延（レイテンシ）を低減させることが可能となる。
　図１０（Ａ）は、第１実施形態に係るショートＢＳＲ（Ｓｈｏｒｔ　ＢＳＲ）のＭＡＣ　ＣＥ（以下、「ショートＢＳＲ　ＭＡＣ　ＣＥ」と称する場合がある。）の構成例を表す図である。１つのＬＣＧ（Ｌｏｇｉｃａｌ　Ｃｈａｎｎｅｌ　Ｇｒｏｕｐ）が送信に利用可能データを有する場合、ショートＢＳＲ　ＭＡＣ　ＣＥが用いられる。すなわち、１つのＬＣＧのバッファサイズを報告する場合は、ショートＢＳＲ　ＭＡＣ　ＣＥが用いられる。
　図１０（Ａ）に示すように、ショートＢＳＲ　ＭＡＣ　ＣＥは、「ＬＣＧ　ＩＤ」領域と「バッファサイズ」領域とを含む。
　「ＬＣＧ　ＩＤ」領域は、バッファサイズが報告される論理チャネルグループの識別情報が格納される領域である。「ＬＣＧ　ＩＤ」領域の領域長は３ビットである。
　「バッファサイズ領域」は、ＭＡＣ　ＰＤＵが構築された後（すなわち、論理チャネル優先順位付け手順（ｌｏｇｏｃａｌ　ｃｈａｎｎｅｌ　ｐｒｉｏｒｉｔｉｚａｔｉｏｎ　ｐｒｏｃｅｄｕｒｅ）後）、論理チャネルグループ内の全ての論理チャネルに亘って、所定の計算手順に従って、利用可能な総データ量が格納される領域である。「バッファサイズ」領域の領域長は５ビットである。
　図１０（Ｂ）は、第１実施形態に係るロングＢＳＲ（Ｌｏｎｇ　ＢＳＲ）のＭＡＣ　ＣＥ（以下、「ロングＢＳＲ　ＭＡＣ　ＣＥ」と称する場合がある。）の構成例を表す図である。１より多いＬＣＧ（Ｌｏｇｉｃａｌ　Ｃｈａｎｎｅｌ　Ｇｒｏｕｐ）が送信に利用可能データを有する存在する場合に、ロングＢＳＲ　ＭＡＣ　ＣＥが用いられる。すなわち、複数のＬＣＧのバッファサイズを報告する場合は、ロングＢＳＲ　ＭＡＣ　ＣＥが用いられる。
　なお、図１０（Ｂ）は、プリエンプティブＢＳＲのＭＡＣ　ＣＥ（以下、「プリエンプティブＢＳＲ　ＭＡＣ　ＣＥ」と称する場合がある。）の構成例も表している。
　図１０（Ｂ）に示すＢＳＲ　ＭＡＣ　ＣＥは、「ＬＣＧｉ」領域と、「バッファサイズ領域」とを含む。
　「ＬＣＧｉ」領域は、論理チャネルグループｉのバッファサイズが存在することを示す領域である。すなわち、ＬＣＧｉに「１」が設定されると、論理チャネルグループｉのバッファファイズが報告されることを表す。他方、ＬＣＧｉに「０」が設定されると、論理チャネルグループｉのバッファサイズが報告されないことを表す。「ＬＣＧｉ」領域の領域長は８ビットである。
　「バッファサイズ」領域は、図１０（Ｂ）に示すＭＡＣ　ＣＥがロングＢＳＲ　ＭＡＣ　ＣＥの場合は、ショートＢＳＲ　ＭＡＣ　ＣＥの「バッファサイズ」領域と同じである。他方、図１０（Ｂ）に示すＭＡＣ　ＣＥがプリエンプティブＢＳＲ　ＭＡＣ　ＣＥの場合、「バッファサイズ領域」は、所定のバッファサイズが格納される。所定のバッファサイズは、プリエンプティブＢＳＲがトリガされたＩＡＢノード３００（図９の場合はＩＡＢノード３００－Ｔ）のＩＡＢ－ＭＴに到着することが期待されるデータの総量であって、ＩＡＢ－ＭＴにおいて現在利用可能なデータの総量は含まない。
　なお、図１０（Ａ）のショートＢＳＲ　ＭＡＣ　ＣＥは、ショートトランケイテッド（Ｔｒｕｎｃａｔｅｄ）ＢＳＲのＭＡＣ　ＣＥを表す。また、図１０（Ｂ）のロングＢＳＲ　ＭＡＣ　ＣＥは、ロングトランケイテッドＢＳＲのＭＡＣ　ＣＥを表す。
　トランケイテッドＢＳＲは、ＭＡＣレイヤがＭＡＣ　ＰＤＵを構成する際に挿入するパディングビット（又はパディングデータ）に対応するＢＳＲである。パディングビットが、ショートＢＳＲにサブヘッダを追加したサイズと同じ場合は、図１０（Ａ）のＭＡＣ　ＣＥが利用される。また、パディングビットが、ショートＢＳＲにサブヘッダを追加したサイズより大きい場合は、図１０（Ｂ）のＭＡＣ　ＣＥが利用される。
　なお、以下では、ショートＢＳＲ　ＭＡＣ　ＣＥとショートトランケイテッドＢＳＲ　ＭＡＣ　ＣＥとを区別しない場合、ショートＢＳＲ　ＭＡＣ　ＣＥとして説明する場合がある。また、ロングＢＳＲ　ＭＡＣ　ＣＥ、プリエンプティブＢＳＲ　ＭＡＣ　ＣＥ、及びロングトランケイテッドＢＳＲ　ＭＡＣ　ＣＥを区別しない場合は、ロングＢＳＲ　ＭＡＣ　ＣＥとして説明する場合がある。
　また、以下では、プリエンプティブＢＳＲとレガシーＢＳＲとを区別しない場合は、「ＢＳＲ」と称する場合がある。
　第１実施形態では、ＩＡＢノード３００が、ホップ数と紐づけられた各論理チャネルグループのバッファサイズを親ノードへ報告する例である。
　具体的には、第１に、配下に第１及び第２の中継ノードを有するドナー基地局（例えばドナーノード２００）が、第１の中継ノード（例えば、ＩＡＢノード３００－Ｔ）へ、論理チャネル（ＬＣＨ）のホップ数と論理チャネルグループ（ＬＣＧ）との対応関係を表す対応情報を設定する。第２に、第１の中継ノードが、第１の中継ノードの親ノードである第２の中継ノード（例えば、親ノード３００－Ｐ）へ、対応情報に基づいて、バッファステータスレポート（ＢＳＲ）を送信する。第３に、第２の中継ノードが、第１の中継ノードへ、対応情報とバッファステータスレポートとに基づいて、アップリンクグラント（ＵＬ　ｇｒａｎｔ）を送信する。
　このように、第１実施形態では、ＬＣＨのホップ数とＬＣＧとを紐づける。ＩＡＢノード３００は、ＢＳＲを利用して、ホップ数と紐づけられたＬＣＧのバッファサイズを親ノードへ報告する。親ノードは、ＬＣＧとホップ数とが紐づけられているため、ＬＣＧ内のバッファサイズを、ホップ数に対応するバッファサイズとして把握できる。親ノードは、バッファサイズだけではなく、ホップ数も用いて、ＩＡＢノード３００に対して、上りリンク無線リソースを割り当てる。
　従って、親ノードは、例えば、遅延の大きい（又はホップ数が大きい）ＩＡＢノード３００に対して、他よりも多くの上りリンク無線リソースを割り当てることが可能となる。そのため、遅延削減を図り、トポロジ全体の公平性確保を実現することが可能となる。
（第１実施形態の構成例）
　まず、第１実施形態の構成例について説明する。図１２（Ａ）は、第１実施形態に係るセルラ通信システム１の構成例を表す図である。
　図１２（Ａ）に示すように、ドナーノード２００は、配下にＩＡＢノード３００－Ｐ，３００－Ｔ，及び３００－Ｃを有する。ドナーノード２００が構築するトポロジ（又はネットワーク）は、他のＩＡＢノードが含まれてもよい。
　ＩＡＢノード３００－Ｔの親ノードは、ＩＡＢノード３００－Ｐである。また、ＩＡＢノード３００－Ｔの子ノードは、ＩＡＢノード３００－Ｃである。以下では、ＩＡＢノード３００－Ｐを親ノード３００－Ｐ、ＩＡＢノード３００－Ｃを子ノード３００－Ｃと称する場合がある。
　ＩＡＢノード３００－Ｔの上位ノードは、親ノード３００－Ｐでもよい。また、ＩＡＢノード３００－Ｔの上位ノードは、ドナーノード２００でもよい。なお、親ノード３００－Ｐがドナーノード２００であってもよい。
　図１２（Ａ）の例では、ＩＡＢノード３００－Ｔは、１つの親ノード３００－Ｐと接続されている例を表しているが、複数の親ノード３００－Ｐ１，３００－Ｐ２，．．．と接続されてもよい。この場合、例えば、ＩＡＢノード３００－Ｔは、Ｄｕａｌ　Ｃｏｎｎｅｃｔｉｖｉｔｙにより、親ノード３００－Ｐ１及び親ノード３００－Ｐ２と接続されてもよい。親ノード３００－Ｐ１には、Ｄｕａｌ　Ｃｏｎｎｅｃｔｉｖｉｔｙにおけるマスタセルグループ（ＭＣＧ）が設定され、親ノード３００－Ｐ２には、セカンダリセルグループ（ＳＣＧ）が設定されることで、ＩＡＢノード３００－Ｔが、２つの親ノード３００－Ｐ１及び３００－Ｐ２に接続可能となる。
　また、図１２（Ａ）の例では、ＩＡＢノード３００－Ｔに子ノード３００－Ｃが接続される例を表しているが、子ノード３００－Ｃに代えて、ＵＥ１００がＩＡＢノード３００－Ｔに接続されてもよい。また、ＩＡＢノード３００－Ｔに子ノード３００－ＣとＵＥ１００とが双方接続されてもよい。なお、以下では、子ノード３００－ＣがＩＡＢノード３００－Ｔに接続されるものとして説明する。
（第１実施形態の動作例）
　図１１は、第１実施形態に係る動作例を表す図である。図１２（Ａ）に示すセルラ通信システム１の構成例を適宜用いて、図１１に示す動作例を説明する。
　図１１に示すように、ステップＳ１０において、ドナーノード２００は、処理を開始する。
　ステップＳ１１において、ドナーノード２００は、ＩＡＢノード３００－Ｔ（のＩＡＢ－ＭＴ又はＩＡＢ－ＤＵ）へ、ホップ数毎にＬＣＧが紐づけられた紐づけ情報を設定する。紐づけ情報は、ＬＣＨのホップ数によって分類される。例えば、紐づけ情報として、ＬＣＨのホップ数「２」が、ＬＣＧ＃８からＬＣＧ＃１５に紐づけられ、論理チャネルのホップ数「３」が、ＬＣＧ＃１６～ＬＣＧ＃３２に紐づけられる、等の情報が含まれる。
　ここで、ホップ数は、当該ＬＣＨが属するルートにおける全ホップ数であってもよい。又は、ホップ数は、当該ＬＣＨにおいて、ＩＡＢノード３００－Ｔに至るまでに経過したホップ数であってもよい。又は、ホップ数は、当該ＬＣＨにおいて、ＩＡＢノード３００－Ｔからドナーノード２００に至るまでの残りホップ数であってもよい。
　このように紐づけ情報は、ＬＣＨのホップ数とＬＣＧとの対応関係を表す対応情報であってもよい。なお、以下では、「紐づける」ことと、「対応する」こととを、区別しないで用いる場合がある。
　なお、ドナーノード２００のＣＵは、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴへ、紐づけ情報を含むＲＲＣメッセージを送信することで、設定を行ってもよい。また、ドナーノード２００のＣＵは、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵへ、紐づけ情報を含むＦ１ＡＰメッセージを送信することで、設定を行ってもよい。
　また、ドナーノード２００は、紐づけ情報を親ノード３００－Ｐへ設定してもよい。この場合、ドナーノード２００は、上記と同様に、紐づけ情報を含むＲＲＣメッセージ又はＦ１ＡＰメッセージを親ノード３００－Ｐへ送信することで、設定を行ってもよい。又は、親ノード３００－Ｐには、紐づけ情報がハードコーディングとして、予め設定されていてもよい。
　ステップＳ１２において、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、設定に従い、親ノード３００－ＰへＢＳＲを送信する。ＢＳＲには、ホップ数と紐づけられたＬＣＧ毎に、バッファサイズが格納される。例えば、ＢＳＲには、ホップ数「２」に対応するＬＣＧ＃８のバッファサイズ、ホップ数「２」に対応するＬＣＧ＃９のバッファサイズ、．．．、ホップ数「２」に対応するＬＣＧ＃１５のバッファサイズ、．．．、ホップ数「３」に対応するＬＣＧ＃１６のバッファサイズ、．．．が格納される。なお、ＢＳＲは、上述したように、レガシーＢＳＲでもよい。また、ＢＳＲは、プリエンプティブＢＳＲでもよい。
　ステップＳ１３において、親ノード３００－ＰのＩＡＢ－ＤＵは、ＢＳＲの受信に応じて、紐づけ情報を用いて、ＬＣＧ毎のホップ数とバッファ状態とを特定する。例えば、親ノード３００－Ｐは、ＢＳＲとして、ＬＣＧ＃１５のバッファサイズの報告を受けたとき、紐づけ情報を用いて、ＬＣＧ＃１５に対応するホップ数「２」のバッファサイズであることを、特定する。
　ステップＳ１４において、親ノード３００－ＰのＩＡＢ－ＤＵは、紐づけ情報とＢＳＲとに基づいて、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴに対して、上りリンク無線リソースを割り当てる。そして、親ノード３００－Ｐは、当該割り当て情報を含む、ＵＬ　ｇｒａｎｔをＩＡＢノード３００－Ｔへ送信する。例えば、親ノード３００－ＰのＩＡＢ－ＤＵは、ホップ数が他よりも大きいＬＣＧのデータが滞留しているＩＡＢノード３００－ＴのＩＡＢ－ＭＴへ、他よりも多くの上りリンク無線リソースを割り当てる。
　そして、ステップＳ１５において、一連の処理が終了する。
（第１実施形態の変形例）
　次に、第１実施形態の変形例について説明する。第１実施形態の変形例は、１つのＬＣＨに対して、ホップ数毎に複数のＬＣＧを割り当てる例である。具体的には、第１の中継ノード（例えば、ＩＡＢノード３００－Ｔ）が、対応情報に基づいて、論理チャネルを介して受信したパケットのホップ数に対応する論理チャネルグループを特定し、当該論理チャネルグループのバッファサイズを含むバッファステータスレポートを第２の中継ノード（例えば、親ノード３００－Ｐ）へ送信する。
　図１２（Ｂ）は第１実施形態の変形例に係る動作例を表す図である。図１２（Ａ）に示すセルラ通信システム１の構成例を適宜用いて、図１２（Ｂ）に示す動作例を説明する。
　ただし、１つのＬＣＨ（ＢＨ　ＲＬＣ　ｃｈａｎｎｅｌ）には、Ｎ本のＵＥベアラがマッピングされる（１：Ｎマッピング）。そして、Ｎ本のＵＥベアラは、各々、他と異なるルート（ホップ数）を有しているものとする。
　ＩＡＢノード３００－Ｔは、紐づけ情報が設定されると（ステップＳ１１：図１１と同じ）、ステップＳ１２０において、ＬＣＨ（ＢＨ　ＲＬＣ　ｃｈａｎｎｅｌ）を介して受信したパケットをホップ数毎に分類する。
　ここで、ＩＡＢノード３００－Ｔは、例えば、以下のようにして、ホップ数を確認してもよい。
　第１に、受信したパケットのヘッダからホップ数を取得してもよい。受信したＢＡＰパケットのＢＡＰヘッダに、ホップ数情報が格納されていれば、ＩＡＢノード３００－Ｔ（のＩＡＢ－ＤＵ）は、ＢＡＰヘッダからホップ数情報を取得することでホップ数を確認できる。
　第２に、ＩＡＢノード３００－Ｔの実装からホップ数を取得してもよい。すなわち、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵは、どのＢＨ　ＲＬＣ　ｃｈａｎｎｅｌからパケットを受信したのかを把握している。ＩＡＢノード３００－ＴのＩＡＢ－ＤＵは、パケットを受信するごとに、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴへ、どのパケットがどのルートを経由したのかを通知する。ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、ＩＡＢ－ＤＵから通知された情報に基づいて、ホップ数を取得してもよい。
　そして、ステップＳ１２０において、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、紐づけ情報に基づいて、分類したホップ数に対応するＬＣＧを特定し、当該ＬＣＧ毎にバッファサイズを算出する。ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、算出したバッファサイズを含むＢＳＲを、親ノード３００－Ｐへ送信する。
　ＩＡＢノード３００－Ｔは、ステップＳ１２０の処理を終了すると、第１実施形態と同様に、ステップＳ１３（図１１）以降の処理を行う。
　第１実施形態の変形例では、ＩＡＢノード３００－Ｔは、パケット毎にＬＣＧを特定して、バッファサイズを算出しているため、パケット単位でバッファサイズを親ノード３００－Ｐへ報告できる。親ノード３００－Ｐは、遅延の大きいパケットを有するＩＡＢノード３００－Ｔへ、他よりも多くのリソースを割り当てることが可能となる。そのため、遅延削減を図り、更には公平性確保を実現することが可能となる。
（第２実施形態）
　次に、第２実施形態について説明する。
　図１０（Ａ）及び図１０（Ｂ）に示すように、３ＧＰＰのリリース１６において、ＬＣＧ数の上限は、ＬＣＧ数で８個（例えば図１０（Ｂ））、ビット数では３ビット（例えば図１０（Ａ））である。以下、上限を、「Ｘ個（Ｙビット）」と表す。
　他方、ＬＣＨ数の上限は、ＩＡＢ－ＭＴについては、６５、５３６個（１６ビット）まで存在する。ＬＣＧ数の上限が、ＬＣＨ数の上限と同じ程度まで確保されると、ＬＣＧ数の上限も、６５、５３６個（１６ビット）とすることが可能である。仮に、高解像度のスケジューリングのために、ＬＣＧ数が６５、５３６個（１６ビット）存在する場合を考える。このような場合、ＩＡＢノード３００が、６５、５３６個（１６ビット）のＬＣＧを、既存のＢＳＲ　ＭＡＣ　ＣＥを利用して送信する場合、図１０（Ｂ）に示すＢＳＲを８１９２回送信する。
　しかし、これでは、オーバーヘッドが大きくなる。
　そこで、第２実施形態では、ＬＣＧの上限値を設定可能とし、ＩＡＢノード３００－Ｔは、設定されたＬＣＧの上限値に対応するＢＳＲ　ＭＡＣ　ＣＥフォーマットを利用して、ＢＳＲを親ノード３００－Ｐへ報告する。
　そのため、ＩＡＢノード３００－Ｔは、既存のＢＳＲ　ＭＡＣ　ＣＥフォーマット（図１０（Ａ）及び図１０（Ｂ））に加えて、固定拡張フォーマットのＢＳＲ　ＭＡＣ　ＣＥと、可変拡張フォーマットのＢＳＲ　ＭＡＣ　ＣＥとを利用する。ＩＡＢノード３００－Ｔは、これらのＭＡＣ　ＣＥフォーマットの中から、ＬＣＧの上限値に対応するＭＡＣ　ＣＥフォーマットを選択する（又は決定する）。
　具体的には、第１に、第１の中継ノード（例えば、ＩＡＢノード３００－Ｔ）の上位ノード（例えば、親ノード３００－Ｐ又はドナーノード２００）が、第１の中継ノードへ、論理チャネルグループの上限値を設定する。第２に、第１の中継ノードが、上限値に対応するＭＡＣコントロールエレメント（ＣＥ）フォーマットを決定する。第３に、第１の中継ノードが、第１の中継ノードの親ノードである第２の中継ノード（例えば、親ノード３００－Ｐ）へ、決定したＭＡＣコントロールエレメントフォーマットを用いて、バッファステータスレポートを送信する。
　このように、ＩＡＢノード３００－Ｔは、ＬＣＧの上限値に対応するＢＳＲ　ＭＡＣ　ＣＥを利用して、ＢＳＲを報告できるため、ＢＳＲを複数回送信することがなくなるため、オーバーヘッド削減を図ることが可能となる。
　次に、固定拡張フォーマットのＢＳＲ　ＭＡＣ　ＣＥ及び可変拡張フォーマットのＢＳＲ　ＭＡＣ　ＣＥの具体例について説明する。
　図１３（Ａ）及び図１３（Ｂ）は、第１実施形態に係る固定拡張フォーマットのＢＳＲ　ＭＡＣ　ＣＥの構成例を表す図である。図１３（Ａ）及び図１３（Ｂ）は、ともに、ＬＣＧの上限値が１６個（４ビット）の場合例を表す図である。このうち、図１３（Ａ）は、ＬＣＧの上限値が１６個（４ビット）の場合のショートＢＳＲ　ＭＡＣ　ＣＥの例を表している。また、図１３（Ｂ）は、ＬＣＧの上限値が１６個（４ビット）の場合のロングＢＳＲ　ＭＡＣ　ＣＥの例を表している。
　図１３（Ａ）に示すように、ＬＣＧの上限値が１６個（４ビット）の場合、ショートＢＳＲ　ＭＡＣ　ＣＥでは、「ＬＣＧ　ＩＤ」領域が上限値に合わせて４ビット存在する。図１０（Ａ）のショートＢＳＲ　ＭＡＣ　ＣＥと比較して、１ビット多い。「ＬＣＧ　ＩＤ」領域には、既存のショートＢＳＲ　ＭＡＣ　ＣＥ（図１０（Ａ））と同じ、バッファサイズが報告される論理チャネルグループの識別情報が格納される。
　なお、「ＢＳ」領域は、５ビット存在する。「ＢＳ」領域も、既存のＢＳＲ　ＭＡＣ　ＣＥと同じ、ＬＣＧ内の全ＬＣＨに亘って、所定の計算手順に従って、利用可能な総データ量が格納される。「ＢＳ」領域以降は、「Ｒ」（リザーブ領域）である。
　図１３（Ｂ）に示すように、ロングＢＳＲ　ＭＡＣ　ＣＥには、「ＬＣＧｉ」領域が、上限値に合わせて１６個（ＬＣＧ０～ＬＣＧ１５）存在する。「ＬＣＧｉ」領域も、既存のロングＢＳＲ　ＭＡＣ　ＣＥと同じ、ＬＣＧｉのバッファサイズが存在することを示す値が格納される。図１３（Ｂ）に示す「ＢＳ」領域も、既存のロングＢＳＲ　ＭＡＣ　ＣＥと同じ所定のバッファサイズが格納される。
　図１４（Ａ）及び図１４（Ｂ）は、第２実施形態に係る固定拡張フォーマットのＢＳＲ　ＭＡＣ　ＣＥの例を表す図である。図１４（Ａ）及び図１４（Ｂ）は、ともに、ＬＣＧの上限値が２５６個（８ビット）の場合の例を表している。このうち、図１４（Ａ）は、ＬＣＧの上限値が２５６個（８ビット）の場合のショートＢＳＲ　ＭＡＣ　ＣＥの例を表している。また、図１４（Ｂ）は、ＬＣＧの上限値が２５６個（８ビット）の場合のロングＢＳＲ　ＭＡＣ　ＣＥの例を表している。
　図１４（Ａ）に示すように、ＬＣＧの上限値が２５６個（８ビット）の場合、「ＬＣＧ　ＩＤ」領域が上限値に合わせて、８ビット存在する。なお、「ＢＳ」領域は、５ビット存在し、それ以降は「Ｒ」である。
　図１４（Ｂ）に示すように、ＬＣＧの上限値が２５６個（８ビット）の場合、「ＬＣＧｉ」領域が２５６個（ＬＣＧ０～ＬＣＧ２５５）存在する。
　このように、ＩＡＢノード３００－Ｔは、ＬＣＧの上限値が、１６個（４ビット）として設定された場合は、図１３（Ａ）又は図１３（Ｂ）のＢＳＲ　ＭＡＣ　ＣＥを使用することを決定し、ＬＣＧの上限値が、２５６個（８ビット）の場合は、図１４（Ａ）又は図１４（Ｂ）に示すＢＳＲ　ＭＡＣ　ＣＥを使用することを決定する。
　上限値は一例であって、３２個（５ビット）が上限値として設定された場合、ＩＡＢノード３００－Ｔは、「ＬＣＧ　ＩＤ」領域が５ビットのショートＢＳＲ　ＭＡＣ　ＣＥ、又は「ＬＣＧｉ」領域が３２個存在するロングＢＳＲ　ＭＡＣ　ＣＥを使用することを決定すればよい。また、６４個（６ビット）が上限値として設定された場合、ＩＡＢノード３００－Ｔは、「ＬＣＧ　ＩＤ」が６ビットのショートＢＳＲ　ＭＡＣ　ＣＥ、又は「ＬＣＧｉ」領域が６４個存在するロングＢＳＲ　ＭＡＣ　ＣＥを使用することを決定すればよい。
　ＩＡＢノード３００－Ｔは、上限値に対応する「ＬＣＧ　ＩＤ」領域を有するショートＢＳＲ　ＭＡＣ　ＣＥ、又は上限値に対応する「ＬＣＧｉ」領域を有するロングＢＳＲ　ＭＡＣ　ＣＥを使用することを決定すればよい。
　なお、ＩＡＢノード３００－Ｔは、ある特定のＬＣＧのバッファサイズを報告する場合は、ショートＢＳＲ　ＭＡＣ　ＣＥを使用することを決定し、複数のＬＣＧのバッファサイズを報告する場合は、ロングＢＳＲ　ＭＡＣ　ＣＥを使用することを決定すればよい。
　図１５（Ａ）及び図１５（Ｂ）は、第２実施形態に係る可変拡張フォーマットの例を表す図である。このうち、図１５（Ａ）は、ショートＢＳＲ　ＭＡＣ　ＣＥ用のショート可変拡張フォーマットの例を表し、図１５（Ｂ）は、ロングＢＳＲ　ＭＡＣ　ＣＥ用のロング可変拡張フォーマットの例を表す。
　図１５（Ａ）に示すように、ショート可変拡張フォーマットには、更に、「ＬＣＧ　ｒａｎｇｅ」領域が含まれる。
　「ＬＣＧ　ｒａｎｇｅ」領域は、ＩＡＢノード３００－Ｔに設定されたＬＣＧの上限値に対応するビットが格納される。例えば、ＬＣＧの上限値が「１６個（４ビット）」の場合は、「００」、ＬＣＧの上限値が「２５６個（８ビット）」の場合は、「０１」、ＬＣＧの上限値が「１６，３８４（１４ビット）」の場合は、「１０」、ＬＣＧの上限値が「６５、５３６（１６ビット）」の場合は、「１１」が格納される。
　ＬＣＧの上限値と「ＬＣＧ　ｒａｎｇｅ」領域に格納されるビットとの関係は、これ以外でもよい。また、「ＬＣＧ　ｒａｎｇｅ」領域に格納されるビット数も、ＬＣＧの上限値に合わせて、３ビット以上あってもよい。
　図１５（Ａ）に示すように、ショート可変拡張フォーマットには、「ＬＣＧ　ＩＤ」領域が存在するが、そのビット長は、ＬＣＧの上限値に合わせて可変となっている。すなわち、図１５（Ａ）の（Ｘ）領域に存在する「ＬＣＧ　ＩＤ」領域は、上限値に合わせて、図面上、（Ｘ）領域において上から順に左詰めで詰めることが可能である。（Ｘ）領域以外の「ＬＣＤ　ＩＤ」領域（４ビット）と合わせて、「ＬＣＤ　ＩＤ」領域となる。
　例えば、ＬＣＧの上限値が２５６個（８ビット）の場合は、図面上、（Ｘ）領域の最も上にある２つの領域と、上から２番目の領域のうち、左から２つの領域とが、「ＬＣＧ　ＩＤ」領域に含まれることになる。「ＢＳ」領域も「ＬＣＤ　ＩＤ」領域に続いて、左詰めとなり、余った領域が「Ｒ」となる。また、例えば、ＬＣＧの上限値が３２個（５ビット）の場合は、図面上、（Ｘ）領域のうち最も上にある領域のうち、左側の領域が「ＬＣＧ　ＩＤ」領域に含まれることになる。
　なお、図１５（Ａ）の例では、「ＢＳ」領域は、５ビット存在する。「ＢＳ」領域は５ビットより多くてもよい。
　図１５（Ｂ）に示すように、ロング可変拡張フォーマットにも、更に、「ＬＣＧ　ｒａｎｇｅ」領域が含まれる。「ＬＣＧ　ｒａｎｇｅ」領域は、ショート可変拡張フォーマットの「ＬＣＧ　ｒａｎｇｅ」領域と同じ、ＬＣＧの上限値が格納される。
　また、「ＬＣＧｉ」領域は、ＬＣＧの上限値に応じて、「ＬＣＧｉ」領域の個数が設定される。例えば、ＬＣＧの上限値が１６個（４ビット）の場合は、ＬＣＧ０～ＬＣＧ１５（ｍ＝１５）までの１６個の「ＬＣＧｉ」領域が設定され、２５６個（８ビット）の場合は、ＬＣＧ０～ＬＣＧ２５５（ｍ＝２５５）までの２５６個の「ＬＣＧｉ」領域が設定される。
　ＩＡＢノード３００－Ｔは、固定拡張フォーマット（図１３（Ａ）～図１４（Ｂ））とするか、可変拡張フォーマット（図１５（Ａ）及び図１５（Ｂ））とするかは、任意でよい。
　図１６は、第２実施形態に係る動作例を表す図である。図１２（Ａ）に示すセルラ通信システム１の構成例を適宜用いて、図１６に示す動作例を説明する。
　図１６に示すように、ステップＳ３０において、ＩＡＢノード３００－Ｔは処理を開始する。
　ステップＳ３１において、上位ノード（親ノード３００－Ｐ又はドナーノード２００）は、ＩＡＢノード３００－Ｔへ、ＬＣＧの上限値を設定する。上限値としては、例えば、８個（３ビット）、１６個（４ビット）、３２個（５ビット）、．．．、２５６個（８ビット）、．．．、１６，３８４個（１６ビット）、．．．、６５，５３６個（１６ビット）のいずれかである。
　なお、上位ノードが、親ノード３００－Ｐの場合は、親ノード３００－ＰのＩＡＢ－ＤＵは、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴに対して、ＭＡＣ　ＣＥ、又はＢＡＰ　Ｃｏｎｔｒｏｌ　ＰＤＵなどを用いて、ＬＣＧの上限値を設定すればよい。また、上位ノードが、ドナーノード２００の場合は、ドナーノード２００のＣＵは、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵ（又はＩＡＢ－ＭＴ）に対して、Ｆ１ＡＰメッセージ、又はＲＲＣメッセージなどを用いて、ＬＣＧの上限値を設定すればよい。
　なお、上位ノードが、ドナーノード２００の場合、ドナーノード２００は、ＬＣＧの上限値を、親ノード３００－Ｐへ送信してもよい。又は、ドナーノード２００からＬＣＧの上限値の設定を受けたＩＡＢノード３００－ＴのＩＡＢ－ＭＴが、親ノード３００－ＰのＩＡＢ－ＤＵへ、当該上限値を送信してもよい。
　ステップＳ３２において、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、設定された上限値に応じて、使用するＭＡＣ　ＣＥフォーマットを決定（又は選択）する。例えば、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、上限値が８個の場合、既存のフォーマット（例えば、図１０（Ａ）又は図１０（Ｂ））を選択する。また、例えば、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、上限値が１６個以上の場合は、固定拡張フォーマット（例えば、図１３（Ａ）から図１４（Ｂ））又は可変拡張フォーマット（例えば、図１５（Ａ）又は図１５（Ｂ））を選択する。
　ステップＳ３３において、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、決定したフォーマットを用いて、レガシーＢＳＲ及び／又はプリエンプティブＢＳＲを、親ノード３００－Ｐへ送信する。
　そして、ステップＳ３４において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。
（第２実施形態の変形例）
　次に、第２実施形態の変形例を説明する。第２実施形態の変形例は、ＬＣＧの上限値設定が、レガシーＢＳＲとプリエンプティブＢＳＲで異なる値に設定される例である。具体的には、上位ノード（例えば、親ノード３００－Ｐ又はドナーノード２００）が、第１の中継ノード（例えば、ＩＡＢノード３００－Ｔ）へ、レガシーＢＳＲとプリエンプティブＢＳＲとで異なる上限値を設定する。
　これにより、例えば、ＩＡＢノード３００－Ｔは、レガシーＢＳＲとプリエンプティブＢＳＲとで、異なる上限値に応じたバッファサイズを報告できる。具体的には、例えば、ＬＣＧの上限値を大きくしてスケジューリング解像度を増加させ、プリエンプティブＢＳＲの上限値は小さくてもよい、などの要求に応えることが可能となる。
　図１７は、第２実施形態の変形例に係る動作例を表す図である。図１２（Ａ）に示すセルラ通信システム１の構成例を適宜用いて、図１７に示す動作例を説明する。
　図１７に示すように、ステップＳ４０において、上位ノード（親ノード３００－Ｐ又はドナーノード２００）は処理を開始する。
　ステップＳ４１において、上位ノードは、ＩＡＢノード３００－Ｔ（のＩＡＢ－ＭＴ又はＩＡＢ－ＤＵ）へ、レガシーＢＳＲとプリエンプティブＢＳＲとで、ＬＣＧの上限値を異なる値に設定する。これにより、例えば、ＬＣＧの上限値とＢＳＲのタイプとが紐づけられて設定される。設定は、第２実施形態と同様に、上位ノードがドナーノード２００の場合は、Ｆ１ＡＰメッセージなどを用いて設定すればよい。上位ノードが親ノード３００－Ｐの場合は、ＢＡＰ　Ｃｏｎｔｒｏｌ　ＰＤＵなどを用いて設定すればよい。
　ステップＳ４２において、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、ＢＳＲのタイプによって、使用するＭＡＣ　ＣＥフォーマットを決定（又は変更）する。例えば、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、レガシーＢＳＲに対するＬＣＧの上限値が１６個（４ビット）の場合は、図１３（Ａ）又は図１３（Ｂ）のＢＳＲ　ＭＡＣ　ＣＥフォーマットを選択し、プリエンプティブＢＳＲに対するＬＣＧの上限値が２５６個（８ビット）の場合、図１４（Ａ）又は１４（Ｂ）のＢＳＲ　ＭＡＣ　ＣＥフォーマットを選択する。
　ステップＳ４３において、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、決定したＭＡＣ　ＣＥフォーマットを用いて、レガシーＢＳＲ及びプリエンプティブＢＳＲを送信する。
　そして、ステップＳ４４において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。
（第３実施形態）
　次に、第３実施形態の例を説明する。第３実施形態は、レガシーＢＳＲとプリエンプティブＢＳＲとを１つのＢＳＲ　ＭＡＣ　ＣＥで送信する例である。
　具体的には、第１に、第１の中継ノード（例えば、ＩＡＢノード３００－Ｔ）の上位ノード（例えば、親ノード３００－Ｐ又はドナーノード２００）が、第１の中継ノードへ、統合バッファステータスレポートの設定を行う。第２に、第１の中継ノードが、設定に従って、バッファステータスレポートの種別毎に分類された論理チャネルグループに対応するバッファサイズが格納された統合バッファステータスレポートを、第１の中継ノードの親ノードである第２の中継ノード（例えば、親ノード３００－Ｐ）へ送信する。
　１つにまとめられたＢＳＲ　ＭＡＣ　ＣＥを、統合ＢＳＲと称する場合がある。統合ＢＳＲは、例えば、レガシーＢＳＲ（又はプリエンプティブＢＳＲ）と同様に、ＬＣＧと、各ＬＣＧのバッファサイズ（ＢＳ）とが格納される。統合ＢＳＲは、ある１つのＬＣＧについてバッファサイズを報告する場合は、ショートＢＳＲ　ＭＡＣ　ＣＥと同じフォーマットのＭＡＣ　ＣＥが用いられてもよい。また、統合ＢＳＲは、複数のＬＣＧについての各バッファサイズを報告する場合は、ロングＢＳＲ　ＭＡＣ　ＣＥと同じフォーマットのＭＡＣ　ＣＥが用いられてもよい。
　これにより、ＩＡＢノード３００－Ｔは、異なるＭＡＣ　ＣＥフォーマットのＢＳＲを送信することがなくなり、例えば、処理遅延を防ぐことが可能となる。
　図１８は、第３実施形態に係る動作例を表す図である。図１２（Ａ）に示すセルラ通信システム１の構成例を適宜用いて、図１８に示す動作例を説明する。
　図１８に示すように、ステップＳ５０において、上位ノード（親ノード３００－Ｐ又はドナーノード２００）は、処理を開始する。
　ステップＳ５１において、上位ノードは、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴへ、統合ＢＳＲを設定する。この場合、上位ノードは、統合ＢＳＲにおけるＬＣＧと、ＢＳＲタイプとの紐づけ設定を行ってもよい。例えば、統合ＢＳＲのＬＣＧ＃０～ＬＣＧ＃３は、レガシーＢＳＲのＬＣＧ＃０～ＬＣＧ＃３にそれぞれ対応し、統合ＢＳＲのＬＣＧ＃４～ＬＣＧ＃７は、プリエンプティブＢＳＲのＬＣＧ＃０～ＬＣＧ＃３にそれぞれ対応する、ことを表す設定などである。
　このような統合ＢＳＲの設定は、上位ノードが親ノード３００－Ｐの場合は、ＢＡＰ　Ｃｏｎｔｒｏｌ　ＰＤＵ又はＭＡＣ　ＣＥなどを用いて設定されてもよい。また、上位ノードがドナーノード２００の場合は、Ｆ１ＡＰメッセージ又はＲＲＣメッセージなどを用いて設定されてもよい。また、ドナーノード２００は、親ノード３００－Ｐに対して、当該設定を行ってもよい。
　ステップＳ５２において、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、統合ＢＳＲをトリガする。トリガは、レガシーＢＳＲのトリガコンディションであってもよい。また、トリガは、プリエンプティブＢＳＲのトリガコンディションであってもよい。例えば、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、レガシーＢＳＲのトリガタイミングで、統合ＢＳＲをトリガしてもよい。また、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、プリエンプティブＢＳＲのトリガタイミングで統合ＢＳＲをトリガしてもよい。上位ノードは、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴに、前記２つのトリガ条件のうちどちらで統合ＢＳＲをトリガすべきかを設定してもよい。
　ステップＳ５３において、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、レガシーＢＳＲのバッファサイズ（ＢＳ－Ｌ）と、プリエンプティブＢＳＲのバッファサイズ（ＢＳ－Ｐ）とを特定する。そして、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、これらのバッファサイズを、ＬＣＧに対応させて統合ＢＳＲのＭＡＣ　ＣＥに格納する。
　例えば、ＩＡＢノード３００－Ｔは、ＢＳ－Ｌ＃０～ＢＳ－Ｌ＃３をＬＣＧ＃０～ＬＣＧ＃３にそれぞれに対応させる。また、例えば、ＩＡＢノード３００－Ｔは、ＢＳ－Ｐ＃０～ＢＳ－Ｐ＃３を、ＬＣＧ＃４～ＬＣＧ＃７にそれぞれ対応させる。そして、ＩＡＢノード３００－Ｔは、例えば、統合ＢＳＲのＬＣＧ＃０～ＬＣＧ＃３のバッファサイズとして、ＢＳ－Ｌ＃０～ＢＳ－Ｌ＃３を統合ＢＳＲのＭＡＣ　ＣＥにそれぞれ格納する。また、ＩＡＢノード３００－Ｔは、例えば、統合ＢＳＲのＬＣＧ＃４～ＬＣＧ＃７のバッファサイズとして、ＢＳ－Ｐ＃０～ＢＳ－Ｐ＃３を統合ＢＳＲのＭＡＣ　ＣＥに格納する。
　ステップＳ５４において、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、統合ＢＳＲを、親ノード３００－Ｐへ送信する。
　そして、ステップＳ５５において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。
（第４実施形態）
　次に、第４実施形態について説明する。
（ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎ）
　複数のＩＡＢノード３００から構成されたネットワークにおいて、ＩＡＢノード３００間のバックホールリンクで障害が発生する場合がある。このような障害を「ＢＨ　ＲＬＦ（Ｂａｃｋｈａｕｌ　Ｒａｄｉｏ　Ｌｉｎｋ　Ｆａｉｌｕｒｅ）」と呼ぶ。
　図１９は、第４実施形態に係るノード間の関係例を表す図である。また、図１９は、第４実施形態に係るＢＨ　ＲＬＦの例も表している。図１９では、ＩＡＢノード３００－Ｔの親ノードであるＩＡＢノード３００－Ｐ１と、更にその親ノードであるノード５００との間のＢＨリンク＃１で、ＢＨ　ＲＬＦが発生した場合の例を表している。
　親ノード３００－Ｐ１のＩＡＢ－ＭＴが、ＢＨ　ＲＬＦを検知したと仮定する。親ノード３００－Ｐ１のＩＡＢ－ＤＵは、ダウンストリーム側のＩＡＢノード３００－Ｔに対して、障害発生通知を送信する。
　ＢＨ　ＲＬＦを検知したことを示す障害発生通知を、Ｔｙｐｅ１　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎと呼ぶ。子ノード（図１９の例では親ノード３００－Ｐ１である）によって検出されたＢＨリンクＲＬＦが、Ｔｙｐｅ１　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎであってもよい。
　また、バックホールリンクで発生した障害（ＢＨ　ＲＬＦ）からの回復を試行中であることを示す回復試行通知を、Ｔｙｐｅ２　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎと呼ぶ。図１９の例では、親ノード３００－Ｐ１がＩＡＢノード３００－Ｔに対して、Ｔｙｐｅ２　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎを送信する例が示されている。
　Ｔｙｐｅ１　ＢＨ　ＲＬＦ　ＩｎｄｉｃａｔｉｏｎとＴｙｐｅ２　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎとを区別しないときは、Ｔｙｐｅ１／２　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎと呼ぶ。なお、各実施形態では、主に、Ｔｙｐｅ２　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎの例を説明するが、Ｔｙｐｅ２　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎを、Ｔｙｐｅ１　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎと読み替えてもよい。上述したように、Ｔｙｐｅ１　ＢＨ　ＲＬＦ　ＩｎｄｉｃａｔｉｏｎはＢＨ　ＲＬＦ検出時、Ｔｙｐｅ２　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎは回復試行時に、それぞれ送信されるが、ＩＡＢノード３００においては、ＢＨ　ＲＬＦ検出後、直ちに、ＢＨ　ＲＬＦの回復試行処理が行われるため、Ｔｙｐｅ１　ＢＨ　ＲＬＦ　ＩｎｄｉｃａｔｉｏｎとＴｙｐｅ２　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎとは、実質的に同じ通知となるためである。
　更に、ＢＨリンクがＢＨ　ＲＬＦからリカバリしたことを示す回復通知もある。このような回復通知を、Ｔｙｐｅ３　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎと呼ぶ。更に、ＢＨリンクがＲＬＦからのリカバリに失敗したことを示す失敗通知もある。このような失敗通知を、Ｔｙｐｅ４　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎと呼ぶ。
　図１９において、Ｔｙｐｅ２　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎを受信したＩＡＢノード３００－Ｔは、様々な制御を行うことができる。詳細は後述する。
　なお、以下では、Ｔｙｐｅ２　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎを、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎと称する場合がある。
（ローカルリルーティング（ｌｏｃａｌ　ｒｅｒｏｕｔｉｎｇ））
　上述したように、複数のＩＡＢノード３００から構成されたネットワークにおいて、ＩＡＢノード３００間のバックホールリンクでＢＨ　ＲＬＦが発生する場合がある。
　複数のＩＡＢノード３００によってパケットを次々と転送させるマルチホップネットワークでは、データパケットを、代替パス（ａｌｔｅｒｎａｔｉｖｅ　ｐａｔｈ）を介して宛先ＩＡＢノード３００（又はドナーノード２００）へ転送させることができる。回線障害が発生した場合において、代替パスを利用してデータパケットを転送することを、ローカルリルーティングと称する場合がある。ローカルリルーティングは、ドナーノード２００によって設定されたルーティング設定を無視して、代替パスを選択することで行われる。もしくは、ローカルリルーティングは、ドナーノード２００によって設定された代替パス候補の中から代替パスを選択することで行われてもよい。
（条件付きハンドオーバ）
　一般的なハンドオーバにおいては、ＵＥ１００がサービングセル及び／又は隣接セルの無線状態の測定値をｇＮＢ２００に報告し、この報告に基づいてｇＮＢ２００が隣接セルへのハンドオーバを決定し、ハンドオーバ指示をＵＥ１００に送信する。このため、サービングセルの無線状態が急激に劣化したような場合、一般的なハンドオーバは、ハンドオーバが実行される前に通信が途絶する場合がある。
　これに対し、条件付きハンドオーバは、予め設定されたトリガ条件が満たされると、当該トリガ条件に対応する候補セルへのハンドオーバを自律的に実行することが可能である。このため、一般的なハンドオーバにおける通信途絶などの問題を解決できる。
　条件付きハンドオーバの実行条件には、１つ以上のトリガ条件を含む。条件付きハンドオーバの設定は、候補セル及びトリガ条件を含む。条件付きハンドオーバの設定は、候補セル及びトリガ条件の複数の組み合わせを複数含んでもよい。条件付きハンドオーバの設定は、例えば、ドナーノード２００のＣＵからＩＡＢノード３００（のＩＡＢ－ＭＴ）及び／又はＵＥ１００へのＲＲＣメッセージなどにより行われる。
（第４実施形態の制御例）
　例えば、図１９に示すように、ＩＡＢノード３００－ＴにＤｕａｌ　Ｃｏｎｎｅｃｔｉｖｉｔｙが設定され、ＩＡＢノード３００－Ｔは、２つの親ノード３００－Ｐ１及び３００－Ｐ２と接続可能である場合を考える。
　このような場合、ＩＡＢノード３００－Ｔは、親ノード３００－Ｐ１からＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信すると、ローカルリルーティングを行って、接続先を親ノード３００－Ｐ２へ切り替えることが可能である。これにより、ＩＡＢノード３００－Ｔは、ｕｐｓｔｒｅａｍ方向へのパケットを、障害が発生したＢＨリンク＃１を回避して、目的ノード（ドナーノード２００）へ送信することができ、継続したサービスをＵＥ１００へ提供できる。
　しかし、ＩＡＢノード３００－ＴにＤｕａｌ　Ｃｏｎｎｅｃｔｉｖｉｔｙが設定されておらず、親ノード３００－Ｐ１のみ接続されたシングル接続の場合を考える。このような場合、ＩＡＢノード３００－Ｔは、親ノード３００－Ｐ１からＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信しても、親ノード３００－Ｐ１に対する接続の切り替えを行うことができず、Ｔｙｐｅ３　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎ又はＴｙｐｅ４　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎを待つまで何もできない状態となる。
　そこで、ＩＡＢノード３００－Ｔは、親ノード３００－Ｐ１からＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信すると、条件付きハンドオーバを実行できるようにする。具体的には、ＩＡＢノード３００－Ｔは、条件付きハンドオーバによって、親ノード３００－Ｐ１から親ノード３００－Ｐ２へ、接続を切り替える。これにより、ＩＡＢノード３００－Ｔは、ｕｐｓｔｒｅａｍ方向へのパケットを、ＢＨリンク＃１を回避して、目的ノードへ送信することができ、継続したサービスをＵＥ１００へ提供できる。
　このように、ＩＡＢノード３００－Ｔは、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎの受信をトリガにして、ローカルリルーティングと条件付きハンドオーバの双方を実行可能な場合、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信した場合に、どちらを実行するかを選択することが可能である。
　この場合、このような選択をＩＡＢノード３００－Ｔの実装依存により、自ら選択できるようにすることも考えられる。
　しかし、ドナーノード２００は、トポロジ全体を管理するノードである。また、ドナーノード２００は、トポロジ全体のパフォーマンスを制御する能力を持っている。
　そこで、第４実施形態では、ドナーノード２００が、ＩＡＢノード３００－Ｔに対して、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎの受信をトリガにして、ローカルリルーティングを実行するのか、条件付きハンドオーバを実行するのかを、設定できるようにする。
　具体的には、第１に、第１及び第２の中継ノードを配下に有するドナー基地局（例えば、ドナーノード２００）が、第１の中継ノード（例えば、ＩＡＢノード３００－Ｔ）へ、ローカルリルーティング及び条件付きハンドオーバ（ＣＨＯ）の設定を行う。第２に、第１の中継ノードが、第１の中継ノードの親ノードである第２の中継ノード（例えば、親ノード３００－Ｐ１）から、当該第２の中継ノードと当該第２の中継ノードの親ノード（例えば、ノード５００）との間のバックホールリンク（例えば、ＢＨリンク＃１）で発生した障害に対して当該障害からの回復を試行中であることを示す障害回復通知を受信する。第３に、第１の中継ノードが、設定に従い、障害回復通知の受信に応じて、ローカルリルーティング又は前記条件付きハンドオーバを実行する。このような場合、更に、ドナー基地局が、障害回復通知の受信に応じて、ローカルリルーティングを実行するのか、又は条件付きハンドオーバを実行するのか、を第１の中継ノードへ設定する。
　このように、ドナーノード２００が、ローカルリルーティングを実行するのか、条件付きハンドオーバを実行するのかを、ＩＡＢノード３００－Ｔに対して設定するようにしているため、トポロジ全体の公平性を考慮した制御を実現することが可能となる。
（第４実施形態の動作例）
　図２０は、第４実施形態に係る動作例を表す図である。図１９に示す構成例を適宜用いて、動作例を説明する。
　図２０に示すように、ステップＳ６０において、ドナーノード２００は、処理を開始する。
　ステップＳ６１において、ドナーノード２００のＣＵは、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴへ、ローカルリルーティング及び／又は条件付きハンドオーバの設定を行う。例えば、ドナーノード２００のＣＵは、ＲＲＣメッセージを利用して、ローカルリルーティング及び又は条件付きハンドオーバの設定を行ってもよい。
　ステップＳ６２において、ドナーノード２００のＣＵは、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴへ、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信した際の動作を設定する。動作設定は、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信した場合に、ローカルリルーティングを実行するのか、条件付きハンドオーバを実行するのか、どちらを実行するのか（又は優先するのか）に関する設定である。
　ここで、「ローカルリルーティングを実行する」ことが設定された場合、ＩＡＢノード３００－Ｔは、接続切り替えに関する設定処理を行うことなく、パケットを親ノード３００－Ｐ２へ転送できる。そのため、短期的な視点では、通信断が発生することなく、サービスを継続できる、というメリットがある。
　一方、「条件付きハンドオーバを実行する」ことが設定された場合、ＩＡＢノード３００－Ｔは、接続切り替えに関する設定処理を行うことになるが、Ｄｕａｌ　Ｃｏｎｎｅｃｔｉｖｉｔｙの再構築も可能である。そのため、長期的な視点では、ネットワークの負荷分散、通信品質（スループット又はレイテンシ）を維持できる、というメリットがある。
　なお、動作設定は、例えば、ドナーノード２００のＣＵが、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴへ、ＲＲＣメッセージを利用して設定してもよい。
　ステップＳ６３において、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、親ノード３００－Ｐ１のＩＡＢ－ＤＵから、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信する。
　ステップＳ６４において、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、設定に従い、ローカルリルーティング又は条件付きハンドオーバを実行する。
　ステップＳ６５において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。
（第４実施形態の変形例）
　次に、第４実施形態の変形例を説明する。第４実施形態の変形例は、予めルールが決まっており、ＩＡＢノード３００－Ｔは、そのルールに従って、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎの受信をトリガにして、ローカルリルーティング又は条件付きハンドオーバを実行する例である。
　具体的には、第１の中継ノード（例えば、ＩＡＢノード３００－Ｔ）が、ローカルリルーティング又は条件付きハンドオーバを実行する際に、第１の中継ノードが、予め設定されたルールに従って、ローカルリルーティング又は条件付きハンドオーバを実行する。
　ここで、「予め設定」とは、例えば、ＩＡＢノード３００－Ｔが設置される際に、メモリに設定（記憶）されていることを表している。ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、当該設定に関する情報等をメモリから読み出して実行することで、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎの受信をトリガにして、ローカルリルーティング又は条件付きハンドオーバを実行する。もしくは、仕様にてハードコーディングで決まっていてもよい。
　図２１は、第４実施形態の変形例に係る動作例を表す図である。ステップＳ７１，Ｓ７２は、第４実施形態のステップＳ６１，Ｓ６３とそれぞれ同一である。
　ステップＳ７２において、ＩＡＢノード３００－Ｔは、予め決められた所定のルールに従って、ローカルリルーティング又は条件付きハンドオーバを実行する。所定のルールとして、例えば、以下がある。すなわち、ＩＡＢノード３００－Ｔは、Ｄｕａｌ　Ｃｏｎｎｅｃｔｉｖｉｔｙ接続を行っている場合であって、ローカルリルーティングを行うためのパス（代替パス）が存在する場合、ローカルリルーティングを行う。また、ＩＡＢノード３００－Ｔは、Ｄｕａｌ　Ｃｏｎｎｅｃｔｉｖｉｔｙ接続を行っていない場合又はローカルリルーティングを行うためのパス（代替パス）が存在しない場合、条件付きハンドオーバを実行する。
　そして、ステップＳ７４において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。
　（その他の実施形態）
　ＵＥ１００、ｇＮＢ２００、又はＩＡＢノード３００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭ又はＤＶＤ－ＲＯＭ等の記録媒体であってもよい。
　また、ＵＥ１００、ｇＮＢ２００、又はＩＡＢノード３００が行う各処理を実行する回路を集積化し、ＵＥ１００、ｇＮＢ２００、又はＩＡＢノード３００の少なくとも一部を半導体集積回路（チップセット、ＳｏＣ（Ｓｙｓｔｅｍ　ｏｎ　ａ　ｃｈｉｐ））として構成してもよい。
　本開示で使用されている「に基づいて（ｂａｓｅｄ　ｏｎ）」、「に応じて（ｄｅｐｅｎｄｉｎｇ　ｏｎ）」という記載は、別段に明記されていない限り、「のみに基づいて」、「のみに応じて」を意味しない。「に基づいて」という記載は、「のみに基づいて」及び「に少なくとも部分的に基づいて」の両方を意味する。同様に、「に応じて」という記載は、「のみに応じて」及び「に少なくとも部分的に応じて」の両方を意味する。また、「取得する（ｏｂｔａｉｎ／ａｃｑｕｉｒｅ）」は、記憶されている情報の中から情報を取得することを意味してもよく、他のノードから受信した情報の中から情報を取得することを意味してもよく、又は、情報を生成することにより当該情報を取得することを意味してもよい。「含む（ｉｎｃｌｕｄｅ）」、「備える（ｃｏｍｐｒｉｓｅ）」、及びそれらの変形の用語は、列挙する項目のみを含むことを意味せず、列挙する項目のみを含んでもよいし、列挙する項目に加えてさらなる項目を含んでもよいことを意味する。また、本開示において使用されている用語「又は（ｏｒ）」は、排他的論理和ではないことが意図される。さらに、本開示で使用されている「第１」、「第２」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみがそこで採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。本開示において、例えば、英語でのａ，ａｎ，及びｔｈｅのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。
　以上、図面を参照して一実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。また、矛盾しない範囲で、各実施形態の全部又は一部を組み合わせることも可能である。
　本願は、米国仮出願第６３／１８５６４８号（２０２１年５月７日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
（付記１）
（導入）　ＮＲの統合アクセスとバックホールの拡張（ｅＩＡＢ）に関する改訂されたワークアイテムは、ＲＡＮ＃８８ｅで承認された。主な目的のいくつかを以下に示す。
トポロジ適応の強化：
・シグナリング負荷を軽減するための機能強化を含む、堅牢性と負荷分散を強化するためのドナー間ＩＡＢノード移行の手順の仕様。
・ＩＡＢノードの移行とＢＨ　ＲＬＦの回復によるサービスの中断を減らすための拡張機能の仕様。
・ＣＰ／ＵＰ分離のサポートを含む、トポロジの冗長性の強化の仕様。
トポロジ、ルーティング、及びトランスポートの機能強化：
・トポロジ全体の公平性、マルチホップ遅延、及び輻輳緩和を改善するための拡張機能の仕様。
　トポロジ、ルーティング、及びトランスポートの機能強化に関して、ＲＡＮ２＃１１３－ｅでは、Ｒｅｌ－１７で議論する問題、つまり、公平性を表す「ＩＦ」、遅延を表す「ＩＬ」、又は輻輳を表す「ＩＣ」でマークされた問題を指摘した。ＲＡＮ２＃１１３ｂｉｓ－ｅでは、考えられる解決策が議論され、１つの合意に達しただけである。ＩＡＢ－ＭＴ用に拡張されるＬＣＧ範囲。ＬＣＧのサイズ及びＢＳＲの拡張は更なる議論が必要である。
　付記１では、ＩＦ－４、ＩＬ－２、ＩＬ－３、ＩＬ－５、ＩＬ－６、ＩＣ－１、及びＩＣ－７に焦点を当てて、これらの問題の可能な解決策について議論する。
（議論）
―トポロジ全体の公平性―
　ＩＦ－４
　ＩＦ－４は次のように指定された：
・ＩＦ－４：ＩＡＢノードは、より多くのベアラを集約する、及び／又はベアラ当たりの負荷が高いベアラを運ぶＢＨ　ＲＬＣチャネルに、より多くのリソースを提供できない（つまり、ＩＡＢノードは、集約負荷がより高いＢＨ　ＲＬＣチャネルに、より多くのリソースを提供できない）。
　リストによると、ＩＦ－４の可能な解決策は次の通りである。
・Ｆ１：ＩＡＢノードは、ＣＵによって追加情報で設定される。
・Ｆ１－１：特定のＢＨ　ＲＬＣチャネル内のベアラの数に関連する（実際の数、平均数など）。
・Ｆ１－２：特定のＢＨ　ＲＬＣチャネルのベアラのＱｏＳに関連する。
・Ｆ２：追加情報がＢＡＰヘッダに追加される。
・Ｆ２－１：ベアラＩＤ。
・Ｆ２－２：特定のパスのベアラＩＤとホップカウント。
・Ｆ２－３：特定のＢＡＰパケット内のＵＥ　ＤＲＢの数。
　Ｆ１ソリューションに関しては、これらはルーティング設定とともに提供されるなど、一度だけ設定される。従って、これらは、より少ないオーバーヘッドを必要とする単純なソリューションであり、より優れた「ＲＬＣチャネルごとの」スケジューリングを可能にする。ただし、これらのソリューションは、ＤＬスケジューリングの「パケットごとの」優先順位付けには使用できない。
　Ｆ２ソリューションに関しては、これらは各ＢＡＰヘッダに追加されるため、「パケットごと」のスケジューリングを実行できる。ただし、これらのソリューションでは、Ｆ１ソリューションと比較して各ＢＡＰ　ＰＤＵでより多くのオーバーヘッドが必要であることは明らかである。
　公平性の向上という点では、技術的な観点から、「パケットごと」のスケジューリングは「ＲＬＣチャネルごと」のスケジューリングよりも優れている。これらのスケジューリングは、ｇＮＢ（又はＩＡＢ－ＤＵ）のＤＬスケジューラで実行できる。一方、ＵＬの場合、ＬＣＰは基本的に「ＲＬＣチャネルごと」のスケジューリングを提供する。この意味で、ＤＬ及びＵＬのすべてのＢＡＰ　ＰＤＵのオーバーヘッドが増えることを考慮すると、ＤＬに対してのみ「パケットごと」のスケジューリングを行う必要はない場合がある。従って、Ｒｅｌ－１７のトポロジ全体の公平性を向上させるには、単純なソリューション、つまりＦ１ソリューションの方が適している。
　提案１：ＲＡＮ２は、ＩＡＢドナーが各ＢＨ　ＲＬＣチャネルにマップされたベアラの数及びこれらのベアラのＱｏＳを使用してＩＡＢノードを設定することに同意する必要がある。つまり、Ｆ１－１及びＦ１－２を使用してＩＦ－４を解決する。
―マルチホップ遅延―
　ＩＬ－２
　ＩＬ－２は次のように指定された：
・ＩＬ－２：ＬＣＧの数に対する現在の（Ｒｅｌ－１６）制限のため、ＩＡＢノードはＱｏＳ要件がかなり異なるＬＣＨのジョイントバッファーステータスを報告する必要がある場合がある。
　ＩＬ－２の可能な解決策は次の通りである。
・Ｌ４：ＩＡＢノードに新しい動作又は機能が指定されている。
・Ｌ４－３：ＩＡＢ－ＭＴのＬＣＧの数が増加している。
　ＲＡＮ２＃１１３ｂｉｓ－ｅで、ＲＡＮ２は「ＩＡＢ－ＭＴのＬＣＧ範囲を拡張することに同意した。ＬＣＧのサイズ及びＢＳＲの拡張は更なる検討が必要である。」現在の仕様によると、現在のＬＣＧスペースは８（つまり、ｍａｘＬＣＧ－ＩＤは７）であり、これはＵＥとＩＡＢ－ＭＴに共通である。ＵＥの場合、現在のＬＣＨ　ＩＤスペースは３２（つまり、ｍａｘＬＣ－ＩＤ）である。ＩＡＢ－ＭＴの場合、ＢＨ　ＬＣＨ　ＩＤの最大数（つまり、ｍａｘＬＣ－ＩＤ－Ｉａｂ－ｒ１６）は６５，８５５であるが、ＢＨ　ＬＣＨ　ＩＤスペース（つまり、ＢＨ－ＲＬＣチャネル　ＩＤ－ｒ１６）は６５，５３６（１６ビット）である。ＵＥに同じ比率が適用される場合（つまり、ＬＣＧ：ＬＣＨ＝１：４）、ＩＡＢ－ＭＴには１６，３８４　ＬＣＧ（１４ビット）が必要になる場合がある。これは確かに実現可能ですが、ＭＡＣ　ＣＥに追加するには少し大きくなる可能性がある。一部の企業は、ＬＣＧスペースを少なくとも１６（４ビット）、又は２５６（８ビット）まで拡張することを提案した。従って、ＲＡＮ２は、拡張ＬＣＧスペースに最適なものを検討する必要がある。
　提案２：ＲＡＮ２は、拡張ＬＣＧスペースに最適な最大数である１６（４ビット）、２５６（８ビット）、１６，３８４（１４ビット）、更に６５，５３６（１６ビット）について議論する必要がある。
　ＩＬ－３
　ＩＬ－３は次のように指定された：
・ＩＬ－３：プリエンプティブＢＳＲのバッファサイズの計算は、Ｒｅｌ－１６での実装に任されているため、ベンダーごとに異なる場合がある。
　ＩＬ－３の可能な解決策は次の通りである。
・Ｌ４：ＩＡＢノードに新しい動作又は機能が指定されている。
・Ｌ４－１：プリエンプティブＢＳＲのバッファサイズ計算が指定されている。
　従来のＢＳＲの場合、バッファサイズの計算は明確に指定されている。これは、ＭＡＣ、ＲＬＣ、及びＰＤＣＰで利用可能なデータに基づいている。ＲＬＣ及びＰＤＣＰの場合、データ量の計算手順は各仕様で指定されている。Ｒｅｌ－１６では、これらのメカニズムは、ＩＡＢ－ＭＴのプリエンプティブＢＳＲのデータ量計算に再利用される。
　ただし、ＩＡＢノードにはＰＤＣＰの代わりにＢＡＰレイヤがあり、ＢＡＰ仕様にはデータ量の計算はない。そのため、現在の仕様では送信に使用できるデータが不足している。トポロジ全体の公平性をより適切にスケジューリングするには、レガシーＢＳＲで報告されるバッファサイズをより正確にする必要がある。
　所見１：ＢＡＰで送信できるデータの手順がないため、レガシーＢＳＲ及びプリエンプティブＢＳＲが不正確になる。
　Ｒｅｌ－１６では、プリエンプティブＢＳＲのバッファサイズの計算は、ＩＡＢ－ＤＵの実装に大きく依存しているが、仕様では、「バッファサイズフィールドは、プリエンプティブＢＳＲがトリガされるノードのＩＡＢ－ＭＴに到着すると予想されるデータの合計量を指定し、ＩＡＢ－ＭＴで現在利用可能なデータの量は含まれない。」指摘されているように、一部のＩＡＢノードは、プリエンプティブＢＳＲで、実際に到着するよりも大きなバッファサイズを報告する可能性がある。子ノードと親ノードとの間に同じ原則を設定することは難しい場合がある。例えば、マルチベンダの展開では、無線リソースの割り当てが非効率になり、親ノードでスケジューリングの遅延が生じ、ＩＡＢ－ＭＴ間のリソース要求が不公平になる。ＩＡＢノードがデュアルコネクティビティで設定されている場合は、よりあいまいになる可能性がある。従って、プリエンプティブＢＳＲのバッファサイズの計算は、より正確に指定する必要がある。１つの問題は、ＩＡＢ－ＤＵに対してバッファサイズの計算が指定されていないことである。つまり、ＩＡＢ－ＤＵの受信側（ＭＡＣ及びＲＬＣ）でバッファリングされたデータである。
　所見２：ＩＡＢ－ＤＵのＭＡＣ及びＲＬＣ受信機にバッファリングされたデータの手順はない。そのため、Ｒｅｌ－１６のプリエンプティブＢＳＲで報告されるデータ量はＩＡＢ－ＤＵの実装次第である。
　提案３：ＲＡＮ２は、プリエンプティブＢＳＲ（及び場合によってはレガシーＢＳＲ）のバッファサイズ計算を指定することに同意する必要がある。つまり、Ｌ４－１を使用してＩＬ－３を解決する。
　もう１つの問題は、プリエンプティブＢＳＲがいつトリガされるかが親ノードの観点から不明確であるということである。ＭＡＣ仕様では、２つの条件を次のように規定している。これは、トリガ条件がＲｅｌ－１６でのＩＡＢ－ＭＴ実装までであることを意味する。親ノードはデータが実際に送信できるようになる時期を正確に予測できないため、不適切なＵＬ　ｇｒａｎｔが発生する。
　設定されている場合、次のイベントのいずれかが発生した場合、ＩＡＢ－ＭＴの特定のケースに対してプリエンプティブＢＳＲがトリガされる可能性がある。
－ＵＬ　ｇｒａｎｔは子ＩＡＢノード又はＵＥに提供される。
－ＢＳＲは、子ＩＡＢノード又はＵＥから受信される。
　簡単な解決策の１つは、ＩＡＢノードが、プリエンプティブＢＳＲをＵＬ　ｇｒａｎｔ送信又はＢＳＲ受信のどちらでトリガするかで設定されていると考えることができる。ＩＡＢドナーによって設定するのは簡単ですが、プリエンプティブＢＳＲは、実際には親ノードのＩＡＢ－ＤＵ、つまりスケジューラで使用される。従って、この時点で、トリガ条件がＩＡＢドナーによって設定されているか、親ＩＡＢノードによって指示されているかは更なる検討が必要である。
　提案４：ＲＡＮ２は、プリエンプティブＢＳＲに使用されるトリガがＩＡＢノードで設定されていることに同意する必要がある。ＩＡＢドナー又はその親ＩＡＢノードのどちらによって行われるかは更なる検討が必要である。
　ＩＬ－５及びＩＬ－６
　ＩＬ－５は次のように指定されました：
・ＩＬ－５：ＣＵは、ＰＤＢが低いベアラを、輻輳リスクが少ない（リソース効率が高い）ルート又はＲＬＦフリーのルートに設置できない。
　ＩＬ－５の可能な解決策は次の通りである。
・Ｌ３：追加のシグナリングがＩＡＢノードからＣＵに導入される。
・Ｌ３－１：ＩＡＢノードのバッファ／リンクステータスはＣＵと共有される。
・Ｌ３－２：ＢＨ　ＲＬＣチャネルごとの個々のホップの遅延測定値はＣＵと共有される。
・Ｌ４：ＩＡＢノードに新しい動作又は機能が指定されている。
・Ｌ４－２：ローカルリルーティングはＲＬＦ以外の目的で許可される（たとえば、発信リンクの遅延に基づく）。
・Ｆ４：追加のシグナリングがＩＡＢノードからＣＵに導入される。
・Ｆ４－１：ＢＨ　ＲＬＣチャネルごとの負荷情報に関連する。
・Ｆ４－２：個々のリンクでのホップごとの遅延及びホップごとのパケット損失に関連する。
　ＩＬ－６は次のように指定された：
・ＩＬ－６：ＣＵは、ＢＨ　ＲＬＣチャネルごとの実際の（リアルタイム）遅延に基づいてルーティングを設定できない。
　ＩＬ－６の可能な解決策は次の通りである。
・Ｌ３：追加のシグナリングがＩＡＢノードからＣＵに導入される。
・Ｌ３－２：ＢＨ　ＲＬＣチャネルごとの個々のホップの遅延測定値はＣＵと共有される。
・Ｆ４：追加のシグナリングがＩＡＢノードからＣＵに導入される。
・Ｆ４－２：個々のリンクでのホップごとの遅延及びホップごとのパケット損失に関連する。
・Ｌ４：ＩＡＢノードに新しい動作又は機能が指定されている。
・Ｌ４－２：ローカルリルーティングはＲＬＦ以外の目的で許可される（たとえば、発信リンクの遅延に基づく）。
　ＩＬ－５及びＩＬ－６の可能な解決策は、ＩＡＢノードからＩＡＢドナーへの追加のシグナル伝達、つまりＬ３及びＬ４に関して共通性を持っている可能性があり、これは、一元化された最適化を可能にするため、ＭＤＴ及び／又はＳＯＮ手順の一種と見なすことができる。
　Ｌ３－１に関しては、現在の仕様では、ＩＡＢノードがある程度のバッファ／リンクステータスをＩＡＢドナーと共有できるようになっていると見なすことができる。例えば、Ｆ１－ＡＰのＲＥＳＯＵＲＣＥ　ＳＴＡＴＵＳ　ＵＰＤＡＴＥやＲＲＣの測定報告フレームワーク。そのため、ＣＵに報告する必要のある追加情報は不明である。
　Ｌ３－２及びＦ４－２に関しては、これらのソリューションはＩＬ－５及びＩＬ－６の両方に一般的に使用でき、遅延測定の観点からは同じと見なすことができる。既存のＬ２測定では、「ＵＥごとのＤＲＢごとのＵＬ　ＰＤＣＰパケット平均遅延」が指定されているが、ＰＤＣＰパケット平均遅延をＩＡＢノードに適用できないことは明らかである。そのため、ＢＡＰレイヤには新しいＬ２測定が必要になると予想される。
　提案５：ＲＡＮ２は、ＩＡＢノードがホップごとの遅延測定結果をＩＡＢドナーに報告することに同意する必要がある。つまり、Ｌ３－２を使用してＩＬ－５及びＩＬ－６を解決する。
　Ｌ４－２に関して、ＲＡＮ２は、「タイプ２　ＲＬＦインジケーションを使用してローカルリルーティングをトリガできる」及び「ローカルリルーティングは、ホップごとのフロー制御のインジケーションによってトリガできる」ことにすでに同意している。従って、このアジェンダ項目でこの問題について更に議論する必要はない。つまり、ローカルリルーティングの詳細については、トポロジ適応の強化に関する他のアジェンダ項目で議論できる。
　所見３：他の目的、つまりＬ４－２のためのローカルリルーティングについては、トポロジ適応の強化の下で議論する。
―輻輳の緩和―
　ＩＣ－１及びＩＣ－７
　ＩＣ－１及びＩＣ－７は、次のように注釈を付けて指定された。
　Ｒ２は、次の２つの問題に対処するために企業間に十分な関心があると結論付けた。
・ＩＣ－１：パケットのドロップに依存せずに、既存のＲｅｌ－１６　ＤＬ　ＨｂＨフロー制御メカニズムを使用して、単一リンクでの長期的なダウンストリーム輻輳を軽減することはできない。
・ＩＣ－７：ＣＵ（ローカルの輻輳状態を認識していない）は、輻輳が発生しているルーティングパスを更新できない。
　ＩＣ－１及びＣＩ－７はどちらもＲＡＮ３に関連している。ＲＡＮ３もこれに取り組んでいるようであるため、ＲＡＮ２がこれにどの程度取り組むかは現在のところ明確ではない。
　ＲＡＮ３は輻輳の兆候について議論しており、次のことに同意した。
ＣＰベースの輻輳インジケーションには、次のレポートが含まれる場合がある：
・ＢＡＰルーティングＩＤごと及び／又は
・子ノードごとのリンク及び／又は
・ＢＨ　ＲＬＣ　ＣＨ　ＩＤ
（ダウンセレクションは更なる検討が必要である）。
ＣＰベースの輻輳インジケーションは、Ｆ１ＡＰＧＮＢ－ＤＵステータスインジケーション手順を再利用する。
ＣＰベースの輻輳インジケーションは、ＤＬ輻輳に関連している。
ＩＡＢ輻輳緩和へのＵＰベースのアプローチについては、次の２つのオプションを検討する。
・機能強化はない。
・パケットマーキングベースのアプローチ。
　ＩＡＢドナーがＩＡＢノードから輻輳インジケーションを受信すると、ＩＡＢドナーは上記のＲＡＮ２の合意で暗示されているように輻輳が発生するパスを回避できると想定できる。この問題に対処するには、いくつかの方法がある。つまり、ＩＡＢドナーは、ルーティング設定を更新するか、ローカルリルーティングを指示する。後者の場合、輻輳インジケーションの使用方法にＲＡＮ２が関与している可能性がある。いずれの場合も、ＲＡＮ２はＲＡＮ３の進行を待ってから決定する必要がある。
　所見４：ＲＡＮ２は、ＲＡＮ３が詳細を把握した後、輻輳の兆候が原因でＩＡＢドナーがどのように行動するかに関与している可能性がある。
（付記２）
（導入）
　ＮＲの統合アクセスとバックホールの拡張（ｅＩＡＢ）に関する改訂されたワークアイテムは、ＲＡＮ＃８８ｅで承認された。いくつかの目的は次の通りである。
トポロジ適応の強化：
・シグナリング負荷を軽減するための機能強化を含む、堅牢性と負荷分散を強化するためのドナー間ＩＡＢノード移行の手順の仕様。
・ＩＡＢノードの移行及びＢＨＲＬＦの回復によるサービスの中断を減らすための拡張機能の仕様。
・ＣＰ／ＵＰ分離のサポートを含む、トポロジの冗長性の強化の仕様。
トポロジ、ルーティング、及びトランスポートの機能強化：
・トポロジ全体の公平性、マルチホップ遅延、及び輻輳緩和を改善するための拡張機能の仕様。
　付記２では、現在の合意に加えて、Ｒｅｌ－１７ｅＩＡＢのトポロジ適応強化のさまざまなトピックについて議論する。具体的には、ＢＨ　ＲＬＦインジケーションの機能強化、条件付きハンドオーバの機能強化、及びローカルリルーティングの機能強化である。
（議論）
　ＢＨ　ＲＬＦインジケーションの機能強化：
Ｒｅｌ－１６の電子メールディスカッションでは、４種類のＢＨ　ＲＬＦ通知が図２２に示すように議論された。
　最後に、タイプ４の「リカバリ障害」のみがＲｅｌ－１６のＢＨ　ＲＬＦインジケーションとして指定された。これにより、子ＩＡＢ－ＭＴは親ノードのＢＨリンク上のＲＬＦを認識し、ＲＬＦ回復手順を開始できる。
　所見１：タイプ４の「回復障害」のみがＲｅｌ－１６のＢＨ　ＲＬＦインジケーションとして指定された。
　Ｒｅｌ－１７の機能強化について、ＲＡＮ２は、タイプ２の「回復の試行」及びタイプ３の「ＢＨリンクの回復」を導入することに同意したが、詳細なＩＡＢノードの動作は引き続き更なる検討が必要である。
　ＲＡＮ２＃１１３－ｅ：
タイプ２／３ＲＬＦインジケーションをサポートするＲＡＮ２（詳細は更なる検討が必要である）。タイプ２ＲＬＦインジケーションを使用して、ローカルリルーティングをトリガできる。タイプ２ＲＬＦインジケーションは、ＳＩＢでサポートされているＩＡＢの非アクティブ化をトリガするために使用できる。タイプ２ＲＬＦインジケーションは、ＳＲ及び／又はＢＳＲ送信の非アクティブ化、又は削減をトリガするために使用できる。
　ＲＡＮ２＃１１３ｂｉｓ－ｅ：
他のＣＨＯ実行条件が必要な場合は更なる検討が必要である（例：タイプ２　ＲＬＦインジケーションをトリガとして使用できるかどうか）。
　更なる検討がなされているものの１つは、ＲＡＮ２がすでに合意している新しいＢＨＲ　ＬＦインジケーションの３つの可能なユースケースに関連する動作を指定するかどうか／どのように指定するかである。
　ローカルリルーティングのトリガに関しては、タイプ２　ＢＨ　ＲＬＦインジケーションを受信するＩＡＢノードの観点からＢＨ　ＲＬＦがＵＬで発生するため、トリガはアップストリームローカルリルーティング、つまりＵＬパスの切り替えを可能にする必要がある。言い換えると、タイプ２　ＢＨ　ＲＬＦインジケーションを受信するＩＡＢノードはダウンストリームノードとの良好なＢＨリンクを維持できるため、ダウンストリームローカルリルーティングはタイプ２ＢＨ　ＲＬＦインジケーションから独立している。従って、明確に指定する必要があるＩＡＢ－ＭＴの動作と見なすことができる。
　提案１：ＲＡＮ２は、ＩＡＢ－ＭＴが親ノードからタイプ２　ＢＨ　ＲＬＦインジケーションを受信したときに、アップストリームパスでローカルリルーティングをトリガすることを指定することに同意する必要がある。
　提案２：ＲＡＮ２は、ＩＡＢ－ＭＴが親ノードからタイプ３　ＢＨ　ＲＬＦインジケーションを受信すると、アップストリームパスでのローカルリルーティングを停止する、つまり、設定された「通常の」ルーティングに戻ることを指定することに同意する必要がある。
　ＳＩＢ１でのＩＡＢサポートＩＥの非アクティブ化に関しては、Ｒｅｌ－１６での実装まで広く考えられていたＩＡＢ－ＤＵの動作と見なすことができる。従って、ステージ２でのみ指定するだけで、おそらく十分である。特に、ＩＡＢ－ＤＵは、ドナーへの代替ルートがまだある場合、ＳＩＢ１からＩＡＢ－Ｓｕｐｐｏｒｔ　ＩＥを削除しないと想定できる。これは、動作が指定されている場合に明確にする必要がある。
　提案３：ＲＡＮ２は、ステージ２でのみＩＡＢ－ＤＵがタイプ２　ＢＨ　ＲＬＦインジケーションを受信し、ＩＡＢドナーへの代替ルートがない場合にＳＩＢ１からＩＡＢ－Ｓｕｐｐｏｒｔ　ＩＥを削除するかどうかを検討する必要がある。
　上記のＲＡＮ２の合意によれば、提案３が同意できるかどうかに関係なく、ＩＡＢ－Ｓｕｐｐｏｒｔ　ＩＥがＳＩＢ１にない場合、ＩＡＢ－ＭＴは親ノードへの接続確立を開始しない。１つの質問は、親ノードがＢＨ　ＲＬＦの下にある場合でも、ＵＥがセル（つまり親ノード）へのアクセスを許可されているかどうかである。ＲＲＣセットアップリクエストはＣＵ、つまりドナーに到達できないため、最終的にはユーザに悪影響を与える。これを回避するために、セルには、ＵＥのアクセスを禁止し、ＳＳＢ送信を停止し、又はＳＩＢ１を介してタイプ２ＢＨ　ＲＬＦインジケーションをブロードキャストするオプションがある。提案３と同様に、ＩＡＢノードにドナーへの代替ルートがある場合、ＩＡＢサポートＩＥをＳＩＢ１から削除する必要はない。
　提案４：ＲＡＮ２は、ＩＡＢ－ＤＵがタイプ２　ＢＨ　ＲＬＦインジケーションを受信し、ＩＡＢドナーへの代替ルートがない場合に、ＩＡＢ－ＭＴアクセスに加えてＵＥアクセスを禁止するかどうかを検討する必要がある。
　ＳＲ及び／又はＢＳＲ送信の非アクティブ化、又は削減に関しては、ＩＡＢ－ＭＴの動作と見なされる可能性があるため、明確に指定する必要がある。非アクティブ化又は削減に関しては、仕様の観点から「非アクティブ化」の方が簡単な場合がある。ただし、ＳＲ及び／又はＢＳＲは、タイプ３の受信後にのみ送信できるため、スケジューリングの遅延が発生する可能性がある。一方、「削減」は、不要な干渉を引き起こす可能性はあるが、ＢＨリンクが回復した直後にスケジューリングを再開できる場合がある。従って、ＲＡＮ２は、ＳＲ及び／又はＢＳＲの「非アクティブ化」、「削減」、又はその両方をサポートするかどうかについて議論する必要がある。両方がサポートされている場合は、ＩＡＢドナーによって設定可能である必要がある。更に、「削減」がサポートされている場合、ＳＲ及び／又はＢＳＲの削減をどのように処理する必要があるかが不明確である。禁止タイマーの概念を再利用することも考えられるが、この時点では更なる検討が必要である。
　提案５：ＲＡＮ２は、ＩＡＢ－ＭＴが親ノードからタイプ２　ＢＨ　ＲＬＦインジケーションを受信したときに、ＳＲ及び／又はＢＳＲ送信を非アクティブ化、又は削減することを指定することに同意する必要がある。
　提案６：ＲＡＮ２は、ＩＡＢ－ＭＴが親ノードからタイプ３　ＢＨ　ＲＬＦインジケーションを受信したときに、ＳＲ及び／又はＢＳＲ送信の通常の手順を再開できることを指定することに同意する必要がある。
　提案７：ＲＡＮ２は、タイプ２　ＢＨ　ＲＬＦインジケーションが親ノードから受信されたときに、ＳＲ及び／又はＢＳＲの「非アクティブ化」、「削減」、又はその両方（つまり、設定可能）をサポートするかどうかを検討する必要がある。
　更なる検討がなされているもののもう１つは、ＣＨＯがタイプ２ＢＨ　ＲＬＦインジケーションの受信によってトリガされるかどうかである。タイプ２ＢＨ　ＲＬＦインジケーションが送信された状態で、親ノードはＢＨ　ＲＬＦを経験し、ＢＨリンクを回復しようとしている。これは、言うまでもなく、ＩＡＢノードがドナーと通信できないことを意味する。ＩＡＢノードがデュアルコネクティビティで設定されている場合、提案１のように、ＭＣＧとＳＣＧとの間でローカルリルーティングを実行することを選択できる。
　ただし、接続が１つしかないＩＡＢノードは何も実行できず、親ノードのＢＨ回復又はタイプ４ＢＨ　ＲＬＦインジケーションの受信のいずれかを待機する必要がある。明らかに、それは長期間のサービス中断及びユーザへの悪影響を引き起こす。従って、ＩＡＢノードには、タイプ２ＢＨ　ＲＬＦインジケーションを受信したときにＣＨＯをトリガするオプションが必要である。更に、さらなる最適化として、ＩＡＢノードが実際にＣＨＯを実行する前にタイプ３　ＢＨ　ＲＬＦインジケーションを受信した場合に、ＩＡＢノードがＣＨＯ実行をキャンセルする必要があるかどうかを検討する価値がある。
　提案８：ＲＡＮ２は、ＩＡＢ－ＭＴが親ノードからタイプ２ＢＨ　ＲＬＦインジケーションを受信したときにＣＨＯをトリガすることを指定することに同意する必要がある。
　提案９：ＲＡＮ２は、ＩＡＢ－ＭＴが親ノードからタイプ３　ＢＨ　ＲＬＦインジケーションを受け取ったときに、（可能であれば）ＣＨＯ実行をキャンセルするかどうかを検討する必要がある。
　提案１及び提案８の両方に合意できる場合、つまり、デュアルコネクティビティ、ローカルリルーティング、及びＣＨＯで同時に設定されたＩＡＢノードの場合、タイプ２　ＢＨインジケーションを受信したときに、ローカルリルーティング又はＣＨＯのどちらをトリガするかを選択できる。たとえば、タイプ２の受信によるローカルリルーティングは、サービスの中断を回避するのに役立ちますが、タイプ２の受信によるＣＨＯは、長期的／トポロジ全体のパフォーマンスに適している。ローカルリルーティング及びＣＨＯは、タイプ２受信以外の条件によってトリガされるため、これらは主に、イベントＡ３によるハンドオーバの堅牢性などのさまざまな目的で設定されていると想定される。
　この場合、いくつかのオプションがある。ＩＡＢノードの実装又はＩＡＢドナーの設定のいずれかである。ドナーがトポロジ全体の目標を管理するノードであることを考えると、トポロジのパフォーマンスを制御できる必要があるため、タイプ２の受信によるローカルリルーティング又はＣＨＯの選択は、ＩＡＢノードの実装に任せるのではなく、ドナーが設定できる必要がある。
　提案１０：提案１及び提案８の両方に合意できる場合、ＲＡＮ２は、タイプ２　ＢＨ　ＲＬＦインジケーションを受信したため、ＩＡＢノードがローカルリルーティング又はＣＨＯをトリガするようにＩＡＢドナーが設定できることに更に同意する必要がある。
　仕様に新しいＢＨ　ＲＬＦインジケーションを実装する方法について説明する必要がある。タイプ２及びタイプ３のＢＨ　ＲＬＦインジケーションは、Ｒｅｌ－１６のタイプ４　ＢＨ　ＲＬＦインジケーションの場合と同様に、ＢＡＰ制御ＰＤＵを介して送信されることは簡単であると考えられる。上記の提案３と同様に、ＵＥはＢＡＰ制御ＰＤＵを受信できないため、ＢＡＰ層がない。従って、これらのＢＨ　ＲＬＦインジケーションがＳＩＢ１を介してブロードキャストされ、ＳＩＢ１がＤＵによってエンコードされる可能性がある。従って、ＲＡＮ２は、これらがＢＡＰ制御ＰＤＵ又はＳＩＢ１のどちらを介して送信されるかを検討する必要がある。
　提案１１：ＲＡＮ２は、タイプ２及びタイプ３のＢＨ　ＲＬＦインジケーションがＢＡＰ制御ＰＤＵ又はＳＩＢ１のどちらを介して送信されるかについて議論する必要がある。
（条件付きハンドオーバの機能強化）
　条件付きハンドオーバ（ＣＨＯ）は、モビリティの堅牢性を向上させるためにＲｅｌ－１６に導入された。ＣＨＯは指定されたＲｅｌ－１６ＩＡＢに使用できる。ＲＡＮ２＃１１３－ｅ及びＲＡＮ２＃１１３－ｅは次の合意に達した。従って、Ｒｅｌ－１６ＣＨＯに加えてｅＩＡＢのＣＨＯ拡張機能を検討する価値がある。
ＲＡＮ２＃１１３－ｅ：
　ＲＡＮ２では、ＣＨＯについて議論し、ＲＡＮ３がドナー間のＩＡＢノードの移行についての議論を進めるまで、ドナー内のＣＨＯの議論から始める。
ＲＡＮ２は、Ｒｅｌ－１６のＣＨＯがＩＡＢ－ＭＴに使用される／使用できるという意図を確認する（変更が必要かどうかは更なる検討が必要である）。
ＲＡＮ２は、Ｒｅｌ－１６仕様が、デフォルトルート、ＩＰアドレス、及びドナー内ＣＨＯのターゲットパスの設定のベースラインであると想定している。
ＲＡＮ２＃１１３ｂｉｓ－ｅ：
　ＩＡＢ－ＭＴのＣＨＯの使用例は、移行とＲＬＦリカバリである必要がある。
ＲＡＮ２には、ＣＵ内／ＤＵ内ＣＨＯ、及びＣＵ内／ＤＵ間ＣＨＯに共通のソリューションが必要である。
ＣＨＯイベントＡ３及びＣＨＯイベントＡ５はＩＡＢ－ＭＴに適用可能である。
他のＣＨＯ実行条件が必要な場合は更なる検討が必要である（例：タイプ２　ＲＬＦインジケーションをトリガとして使用できるかどうか）。
　前セクションの提案８が合意できる場合、ＣＨＯイベントＡ３／Ａ５に依存しないが、タイプ２ＢＨ　ＲＬＦインジケーションによる一種の強制的なトリガであるため、すべてのＣＨＯ候補（つまり、候補セル）が同時にＣＨＯをトリガできる可能性がある。
　現在の仕様によると、「条件付き再設定の実行で複数のＮＲセルがトリガされる場合、どれを選択するかはＵＥの実装次第である。ＵＥは、ビームとビーム品質を考慮して、実行のためにトリガされたセルの１つを選択する。」これは主にＵＥを対象としている。
　所見２：Ｒｅｌ－１６のＣＨＯでは、複数の候補セルがＣＨＯ実行をトリガする場合、どのセルを選択するかはＵＥの実装次第である。
　ＩＡＢ－ＭＴに関しては、ＩＡＢ－ＭＴがローカルの無線品質に応じて実装することにより、トリガされたセルの１つを選択することが常に最良のアプローチであるとは限らない。これは、トポロジ全体の目標は、ＲＡＮ２＃１１２－ｅで議論されているように、ＩＡＢドナーによって効果的に処理される可能性があるためである。従って、ＲＡＮ２は、追加のトリガ条件を使用したＩＡＢドナー制御のＣＨＯ実行が、提案８のようにどのように機能するかを検討する必要がある。例えば、ＩＡＢドナーは、ＣＨＯ設定でＣＨＯ候補に関連付けられた優先度情報を設定できる。ＩＡＢ－ＭＴは、特定の無線品質（Ｓ基準など）を満たすすべてのトリガされたＣＨＯ候補から最も優先度の高いセルを選択する必要がある。
　提案１２：ＲＡＮ２は、タイプ２　ＢＨ　ＲＬＦインジケーションの受信により、すべての候補セルがＣＨＯをトリガする場合に、追加の拡張機能としてＩＡＢドナー制御のＣＨＯ実行が必要かどうかを検討する必要がある。
（ローカルリルーティングの機能強化）
　Ｒｅｌ－１６では、ローカルリルーティングはＢＨ　ＲＬＦが発生した場合にのみ許可される。
たとえば、ＲＬＣ－ＡＭエンティティが確認応答を受信するまで、ＢＡＰエンティティの送信部分でのデータバッファリングは実装次第である。ＢＨ　ＲＬＦの場合、ＢＡＰエンティティの送信部分は、ＢＨ　ＲＬＦの前に下位層によって確認されていないＢＡＰデータＰＤＵを代替パスにリルーティングすることができる。
　ＲＡＮ２＃１１３－ｅは、ローカルリルーティングの機能強化に関連する次の合意を達成した。
タイプ２ＲＬＦインジケーションを使用して、ローカルリルーティングをトリガできる。
ローカルリルーティングは、ホップごとのフロー制御を示すことでトリガできる。トリガ情報、トリガ条件、ＣＵ設定の役割などの詳細は、更なる検討が必要である。
ＲＡＮ２は、ドナー間ＤＵローカルリルーティングが範囲内にあると見なす。
　ただし、ローカルリルーティングの詳細は、少なくとも設定の観点からはまだ不明である。ＲＡＮ２＃１１２－ｅで合意されているように、「ＲＡＮ２は、中央ルートの決定に対する利点を含め、トポロジ全体の目標にどのように対処できるかについて、ローカルリルーティングについて議論する。」Ｒｅｌ－１７の他の場合（つまり、ＢＨ　ＲＬＦに限定されない）。従って、Ｒｅｌ－１６の問題は、トポロジ全体の客観的な観点から検討する必要がある。言うまでもなく、ＩＡＢドナーは、ＩＡＢトポロジの完全な知識と完全な制御を備えているため、トポロジ全体の目的を処理するエンティティである。
　所見３：ＩＡＢドナーは、トポロジ全体の目的を確実にするために最も適切なエンティティである。
　Ｒｅｌ－１６ローカルリルーティングでは、宛先が同じである限り、代替パスとしてパスが選択されることはＩＡＢノードの実装次第である。これは、ローカルリルーティングがローカルの決定に基づいており、ＩＡＢドナーの観点からは制御できないことを意味する。これは、特に多くのローカルの決定が発生してＩＡＢトポロジに蓄積される場合、トポロジ全体の目的と一致しない可能性がある。
　所見４：Ｒｅｌ－１６ローカルリルーティングでは、代替パスとしてどのパスが選択されるかはＩＡＢ－ＭＴの実装次第である。
　従って、ローカルリルーティングがＢＨ　ＲＬＦの場合を超えて拡張される場合、ＩＡＢドナーの可制御性はより重要になるはずである。ＩＡＢドナーが代替パスを設定することは簡単である。これにより、ＩＡＢノードはローカルリルーティングを実行するときに代替パスを選択する必要がある。代替パスのモデリングは更なる検討が必要である。例えば、代替パスが同じルーティングＩＤを持っているかどうかなどである。
　提案１３：ＲＡＮ２は、ＩＡＢドナーがＲｅｌ－１６のルーティング設定に加えて代替パスを使用してＩＡＢノードを設定できるかどうかを検討する必要がある。
　ＩＡＢドナーの可制御性のもう１つの側面として、ＩＡＢドナーはローカルリルーティングを認識し、ローカルリルーティング及びトポロジ全体の目的を共存させるためにＩＡＢノードでローカルリルーティングを開始／停止できることを考慮する必要がある。例えば、ＩＡＢドナーは、どのＩＡＢノードが現在ローカルリルーティングを実行しているかの知識に基づいて、トポロジ全体の目標がまだ達成されているかどうかを検討できる。ＩＡＢドナーがトポロジ全体の目的を達成できないことに気付いた場合、ＩＡＢドナーはＩＡＢノードにローカルリルーティングを開始／停止するように指示するか、ＩＡＢドナーがＩＡＢトポロジ全体のルーティング設定を変更する可能性がある。
　ローカルリルーティングにより、トポロジ全体の目標をどのように処理するかは、ＩＡＢドナーの実装次第であるが、ＩＡＢドナーは、ＩＡＢノードのローカル決定の情報と制御性を必要とする場合がある。
　提案１４：ＲＡＮ２は、ローカルリルーティングの開始／停止時にＩＡＢノードがＩＡＢドナーに通知する必要があるかどうかを検討する必要がある。
　提案１５：ＲＡＮ２は、ＩＡＢドナーがＩＡＢノードにローカルリルーティングを開始／停止するように指示できるかどうかについて議論する必要がある。

Claims (14)

  1. 　セルラ通信システムで用いる通信制御方法であって、
    　第１の中継ノードの上位ノードが、前記第１の中継ノードへ、論理チャネルグループに関する設定値を設定することと、
    　前記第１の中継ノードが、前記設定値に対応するＭＡＣ（Ｍｅｄｉｕｍ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）コントロールエレメント（ＣＥ）フォーマットを決定することと、
    　前記第１の中継ノードが、前記第１の中継ノードの親ノードである第２の中継ノードへ、前記ＭＡＣコントロールエレメントフォーマットを用いて、バッファステータスレポートを送信することと
    　を有する通信制御方法。
  2. 　前記設定値は、前記論理チャネルグループの上限値の設定である
    　請求項１記載の通信制御方法。
  3. 　前記ＭＡＣコントロールエレメントは、ロングバッファステータスレポート又はプリエンプティブバッファステータスレポートについては、拡張された論理チャネルグループｉ（ＬＣＧｉ）領域を含む
    　請求項２記載の通信制御方法。
  4. 　前記ＭＡＣコントロールエレメントは、ショートバッファステータスレポート（Ｓｈｏｒｔ　ＢＳＲ）について、拡張された論理チャネルグループＩＤ（ＬＣＧ　ＩＤ）領域を含む、
    　請求項３記載の通信制御方法。
  5. 　前記拡張された論理チャネルグループＩＤ領域は４ビット以上、前記拡張された論理チャネルグループｉ領域は１６ビット以上である
    　請求項３又は４に記載の通信制御方法。
  6. 　前記ＭＡＣコントロールエレメントは、更に、前記上限値が格納されるＬＣＧレンジ（ＬＣＧ　ｒａｎｇｅ）領域を含む
    　請求項３又は４に記載の通信制御方法。
  7. 　前記上限値を設定することは、前記上位ノードが、前記第１の中継ノードへ、レガシーバッファステータスレポートとプリエンプティブバッファステータスレポートとで異なる上限値を設定することを含む
    　請求項２記載の通信制御方法。
  8. 　セルラ通信システムで用いる通信制御方法であって、
    　配下に第１の中継ノード及び当該第１の中継ノードの親ノードである第２の中継ノードを有するドナー基地局が、前記第１の中継ノードへ、論理チャネル（ＬＣＨ）のホップ数と論理チャネルグループ（ＬＣＧ）との対応関係を表す対応情報を設定することと、
    　前記第１の中継ノードが、前記第２の中継ノードへ、前記対応情報に基づいて、バッファステータスレポート（ＢＳＲ）を送信することと、
    　前記第２の中継ノードが、前記第１の中継ノードへ、前記対応情報と前記バッファステータスレポートとに基づいて、アップリンクグラント（ＵＬ　ｇｒａｎｔ）を送信することと、を有する
    　通信制御方法。
  9. 　更に、前記ドナー基地局が、前記第２の中継ノードへ、前記対応情報を送信することを有する
    　請求項８記載の通信制御方法。
  10. 　前記バッファステータスレポートを送信することは、前記第１の中継ノードが、前記対応情報に基づいて、前記論理チャネルを介して受信したパケットのホップ数に対応する前記論理チャネルグループを特定して、当該論理チャネルグループのバッファサイズを含む前記バッファステータスレポートを前記第２の中継ノードへ送信することを含む
    　請求項８記載の通信制御方法。
  11. 　セルラ通信システムで用いる通信制御方法であって、
    　第１の中継ノードの上位ノードが、前記第１の中継ノードへ、統合バッファステータスレポートの設定を行うことと、
    　前記第１の中継ノードが、前記設定に従って、バッファステータスレポートの種別毎に分類された論理チャネルグループに対応するバッファサイズが格納された前記統合バッファステータスレポートを、前記第１の中継ノードの親ノードである第２の中継ノードへ送信することと
    　を有する通信制御方法。
  12. 　セルラ通信システムで用いる通信制御方法であって、
    　第１の中継ノード及び当該第１の中継ノードの親ノードである第２の中継ノードを配下に有するドナー基地局が、前記第１の中継ノードへ、ローカルリルーティング及び条件付きハンドオーバ（ＣＨＯ）の設定を行うことと、
    　前記第１の中継ノードが、前記第２の中継ノードから、当該第２の中継ノードと当該第２の中継ノードの親ノードとの間のバックホールリンクで発生した障害に対して当該障害からの回復を試行中であることを示す障害回復通知を受信することと、
    　前記第１の中継ノードが、前記障害回復通知の受信に応じて、前記ローカルリルーティング又は前記条件付きハンドオーバを実行することと
    　を有する通信制御方法。
  13. 　更に、前記ドナー基地局が、前記障害回復通知の受信に応じて、前記ローカルリルーティングを実行するのか、又は前記条件付きハンドオーバを実行するのか、を前記第１の中継ノードへ設定することを有する
    　請求項１２記載の通信制御方法。
  14. 　前記ローカルリルーティング又は前記条件付きハンドオーバを実行することは、前記第１の中継ノードが、予め設定されたルールに従って、前記ローカルリルーティング又は前記条件付きハンドオーバをトリガすることを含む
    　請求項１２記載の通信制御方法。
PCT/JP2022/019528 2021-05-07 2022-05-02 通信制御方法 WO2022234846A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2023518695A JPWO2022234846A1 (ja) 2021-05-07 2022-05-02
US18/502,969 US20240073736A1 (en) 2021-05-07 2023-11-06 Communication control method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202163185648P 2021-05-07 2021-05-07
US63/185,648 2021-05-07

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/502,969 Continuation US20240073736A1 (en) 2021-05-07 2023-11-06 Communication control method

Publications (1)

Publication Number Publication Date
WO2022234846A1 true WO2022234846A1 (ja) 2022-11-10

Family

ID=83932731

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/019528 WO2022234846A1 (ja) 2021-05-07 2022-05-02 通信制御方法

Country Status (3)

Country Link
US (1) US20240073736A1 (ja)
JP (1) JPWO2022234846A1 (ja)
WO (1) WO2022234846A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020196201A1 (ja) * 2019-03-28 2020-10-01 京セラ株式会社 通信制御方法
WO2021065763A1 (ja) * 2019-10-03 2021-04-08 京セラ株式会社 通信制御方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020196201A1 (ja) * 2019-03-28 2020-10-01 京セラ株式会社 通信制御方法
WO2021065763A1 (ja) * 2019-10-03 2021-04-08 京セラ株式会社 通信制御方法

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
KYOCERA: "Possible solutions for topology-wide fairness, multi-hop latency and congestion mitigation in eIAB", 3GPP DRAFT; R2-2103370, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Online; 20210412 - 20210420, 2 April 2021 (2021-04-02), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP052174935 *
LG ELECTRONICS INC.: "Further consideration on identified issues for fairness, latency and congestion", 3GPP DRAFT; R2-2103418, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Electronic meeting; 20210412 - 20210420, 2 April 2021 (2021-04-02), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP052174979 *
SAMSUNG: "IAB MAC - miscellaneous corrections and clarifications", 3GPP DRAFT; R2-2008502, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. E-meeting; 20200817 - 20200828, 1 September 2020 (2020-09-01), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051926447 *
ZTE, SANECHIPS: "Discussion on IAB BH RLF handling", 3GPP DRAFT; R2-1915119, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Reno, USA; 20191118 - 20191122, 8 November 2019 (2019-11-08), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051817029 *

Also Published As

Publication number Publication date
JPWO2022234846A1 (ja) 2022-11-10
US20240073736A1 (en) 2024-02-29

Similar Documents

Publication Publication Date Title
KR102630472B1 (ko) 통합된 액세스 및 백홀 베어러 관리를 위한 방법, 장치 및 시스템
US11558866B2 (en) Method and system for protocol layer enhancements in data offload over small cells
CN113424499B (zh) 在iab网络中协助向ue路由数据的cu、网络节点及其中的方法和相应介质
JP6425800B2 (ja) ユーザ端末、通信方法及びプロセッサ
JP7369240B2 (ja) 無線端末
US20140254476A1 (en) Sending data rate information to a wireless access network node
KR102359856B1 (ko) 무선 통신 시스템에서 릴레이의 업링크 버퍼 상태 보고서를 전달하는 방법 및 장치
CN109429267B (zh) 数据传输方法、相关装置及系统
US20230180327A1 (en) Communication control method
WO2020192654A1 (zh) 配置无线链路控制rlc承载的方法和装置
US20240032129A1 (en) Communication control method
WO2022082602A1 (en) Method and apparatus for packet rerouting
US20230328629A1 (en) Communication control method
WO2022202835A1 (ja) 通信制御方法
WO2022234846A1 (ja) 通信制御方法
WO2022239707A1 (ja) 通信制御方法
WO2022153989A1 (ja) 通信制御方法
WO2023132285A1 (ja) 通信制御方法
WO2023068254A1 (ja) 通信制御方法及び中継ノード
WO2023132283A1 (ja) 通信制御方法
JP7397221B2 (ja) 通信制御方法、中継ノード及びプロセッサ
WO2023068258A1 (ja) 通信制御方法
WO2023013603A1 (ja) 通信方法
JP7460856B2 (ja) 通信制御方法
WO2022202976A1 (ja) 通信制御方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22798950

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023518695

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22798950

Country of ref document: EP

Kind code of ref document: A1