WO2022210546A1 - 通信制御方法 - Google Patents

通信制御方法 Download PDF

Info

Publication number
WO2022210546A1
WO2022210546A1 PCT/JP2022/015026 JP2022015026W WO2022210546A1 WO 2022210546 A1 WO2022210546 A1 WO 2022210546A1 JP 2022015026 W JP2022015026 W JP 2022015026W WO 2022210546 A1 WO2022210546 A1 WO 2022210546A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
iab
parent node
parent
relay node
Prior art date
Application number
PCT/JP2022/015026
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 JP2023511267A priority Critical patent/JPWO2022210546A1/ja
Publication of WO2022210546A1 publication Critical patent/WO2022210546A1/ja
Priority to US18/477,037 priority patent/US20240032129A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/19—Connection re-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition
    • 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
    • H04W40/00—Communication routing or communication path finding
    • H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/18—Management of setup rejection or failure

Definitions

  • the present disclosure relates to a communication control method executed by a relay node.
  • 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.
  • the relay node responds to a failure occurring in a backhaul link between a first parent node of the relay node and a node that is a further parent node of the first parent node. receiving a recovery attempt notification from the first parent node indicating that the parent node of is attempting to recover from the failure. Further, in the communication control method, the relay node transfers the first packet received from the first parent node to a child node of the relay node in response to receiving the recovery attempt notification, and forwarding a second packet received from to a second parent node, which is the parent node of the relay node.
  • a communication control method is a communication control method used in a cellular communication system.
  • the communication control method is such that, in response to a failure occurring in a backhaul link between a parent node of the relay node and a node that is a further parent node of the parent node, the first parent node receiving a recovery attempt notification from the first parent node indicating that recovery from is being attempted.
  • the relay node that has received the recovery attempt notification does not have an alternative path to the donor node
  • the cell of the relay node supports IAB and the cell is an IAB node. broadcasting system information that does not include IAB support, which is an information element indicating that the cell is considered for cell selection in
  • a communication control method is a communication control method used in a cellular communication system.
  • a relay node recovers from a failure occurring in a backhaul link between a parent node of the relay node and a node that is a further parent node of the parent node.
  • a recovery attempt notification indicating that the recovery attempt is being attempted is received from the parent node
  • a setting is made such that the predetermined transmission is not performed or the predetermined transmission is performed within a predetermined number of transmissions.
  • the communication control method has the relay node not performing the predetermined transmission or performing the predetermined transmission less than or equal to the predetermined number of transmissions according to the setting in response to the reception of the recovery attempt notification.
  • said predetermined transmissions are transmissions of scheduling requests, buffer status reports and/or UL packets to said parent node.
  • a communication control method is a communication control method used in a cellular communication system.
  • the relay node responds to a failure occurring in a backhaul link between a first parent node of the relay node and a node that is a further parent node of the first parent node. receiving a recovery attempt notification from the first parent node indicating that the parent node of is attempting to recover from the failure. Further, in the communication control method, in response to receiving the recovery attempt notification, the relay node receives the recovery attempt notification via a second parent node that is a parent node of the relay node. to the donor node.
  • 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. 9 is a diagram showing an example of BH RLF according to the first embodiment.
  • FIG. 10 is a diagram showing an operation example according to the first embodiment.
  • FIG. 11 is a diagram showing an operation example according to the second embodiment.
  • FIG. 12(A) shows an example of SR and BSR according to the third embodiment, and
  • FIG. 12(B) shows an example of Type 2 Indication according to the third embodiment.
  • FIG. 13 is a diagram showing an operation example according to the third embodiment.
  • FIG. 14 is a diagram illustrating an operation example according to modification 1 of the third embodiment.
  • FIG. 15 is a diagram illustrating an operation example according to modification 2 of the third embodiment.
  • FIG. 16 is a diagram showing an operation example according to the third modification of the third embodiment.
  • FIG. 17 is a diagram showing a configuration example of an IAB network according to the fourth embodiment.
  • FIG. 18 is a diagram showing an operation example according to the fourth embodiment.
  • FIG. 19 is a diagram showing the types of BH RLF notifications.
  • FIG. 20 is a diagram representing an identified solution for avoiding re-establishment to descendant nodes.
  • FIG. 21 is a diagram representing a comparison of mechanisms for lossless delivery of UL data in the case of hop-by-hop RLC ARQ.
  • FIG. 22 is a diagram representing options for the introduction of UL status delivery.
  • the cellular communication system 1 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
  • the cellular communication system may also be applied to future cellular communication systems such as 6G.
  • 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, a tablet terminal, a notebook PC, a sensor or a device provided in the sensor, and/or a vehicle or a device provided in the 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 each process 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 each process in the IAB node 300 in each embodiment described below.
  • the control unit 320 may perform each function of IAB-MT or IAB-DU in the IAB node 300 .
  • 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, hybrid ARQ (HARQ) retransmission processing, random access procedures, and so on. 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)) 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 IAB-MT PDCP layer of IAB node 300-2 and the PDCP layer of 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. Between the IAB-MT RRC layer of the IAB node 300-2 and the RRC layer of the donor node 200, 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 is the gNB-CU function of the donor node 200 that terminates the F1 interface to the IAB node 300 and the DU of the donor node 200.
  • DU of donor node 200 is also the gNB-DU function of donor node 200 that hosts the IAB BAP sublayer and provides wireless backhaul to IAB node 300 .
  • 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. described as what to do.
  • processing or operations in the DU or CU of donor node 200 may also be described simply as processing or operations of the "donor node.”
  • upstream direction and the uplink (UL) direction may be used without distinction.
  • downstream direction and the downlink (DL) direction may be used interchangeably.
  • One of the functions of the BAP layer is the function of routing packets to the next hop.
  • each IAB node 300 forwards the received packet to the next hop, thereby finally sending the packet to the destination IAB node 300 (or donor node 200).
  • I'm trying Routing is, for example, controlling to which IAB node 300 a received packet is transferred.
  • Packet routing is performed, for example, as follows. That is, the IAB-CU of the donor node 200 provides routing configuration to the IAB-DU of each IAB node 300 .
  • the routing configuration provided includes a routing ID and the BAP address of the next hop.
  • a routing ID consists of a (destination) BAP address and a BAP path ID.
  • Each IAB node 300 upon receiving a packet (BAP packet), reads the destination BAP address included in the header of the packet.
  • Each IAB node 300 determines whether or not the destination BAP address matches the BAP address of its own IAB node 300 .
  • Each IAB node 300 determines that the data packet has reached its destination when the destination BAP address matches its own BAP address.
  • each IAB node 300 forwards the packet to the IAB node 300 of the BAP address of the next hop according to the routing setting when the destination BAP address does not match its own BAP address.
  • each IAB node 300 forwards the received BAP packet to the next hop according to the routing settings set by the donor node 200.
  • 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. 9 is a diagram showing an example of BH RLF according to the first embodiment.
  • FIG. 9 shows an example in which BH RLF occurs in BH link #1 between IAB node 300-P1, which is the parent node of IAB node 300-T, and node 500, which is its parent node.
  • node 500 is the parent node or gNB 200 (or donor node 200) of parent node 300-P1.
  • 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.
  • Type 2 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.
  • Notification indicating that the child node (parent node 300-P1 in the example of FIG. 9) is attempting to recover from BH RLF is Type 2 BH RLF Indication.
  • Type 1/2 BH RLF Indication an example of Type 2 BH RLF Indication will be mainly described, but 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 example shown in FIG. 9 represents an example in which the parent node 300-P1 transmits a Type 2 BH RLF Indication to its child node, the IAB node 300-T.
  • the IAB node 300-T that receives 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 .
  • the IAB node 300-T represents an example of local rerouting to the parent node 300-P2 on the alternate path. Note that the two parent nodes 300-P1 and 300-P2 are connected to the same donor node 200. FIG.
  • the routing configuration by donor node 200 includes the BAP address of the next hop. Therefore, the IAB node 300 forwards the packet to the next hop according to the routing settings. However, when local rerouting is applied, the IAB node 300 may cause all packets to be forwarded to alternate paths. For example, in the example of FIG. 9, the IAB node 300-T forwards both the packet received from the parent node 300-P1 and the packet received from the child node 300-C to the parent node 300-P2 by local rerouting. there is a possibility. Alternatively, if there are multiple child nodes 300-C, the IAB node 300-T may forward the packet received from the parent node 300-P1 to another child node 300-C on the alternate path.
  • the fact that the IAB node 300-T has received a BH RLF Indication such as Type 1 BH RLF Indication or Type 2 BH RLF Indication means that the wireless link in the BH link #1 between the parent node 300-P1 and the node 500 A failure has occurred.
  • a BH RLF Indication such as Type 1 BH RLF Indication or Type 2 BH RLF Indication
  • the wireless link in the BH link #1 between the parent node 300-P1 and the node 500 A failure has occurred.
  • the BH link between parent node 300-P1 and IAB node 300-T is normal.
  • the first embodiment assumes that the BH link between parent node 300-P1 and IAB node 300-T is normal.
  • the IAB node 300-T that has received the Type 2 Indication from the parent node 300-P1 does not perform local rerouting for all packets, but in the upstream direction of the IAB node 300-T. Perform local rerouting. IAB node 300-T performs the normal routing set by donor node 200 for the downstream direction.
  • the relay node eg, IAB node 300-T
  • the first parent node eg, parent node 300-P1
  • a recovery attempt notification (for example, Type 2 Indication) indicating that the first parent node is trying to recover from a failure that occurred in the backhaul link between the nodes (for example, node 500) is sent to the 1 from the parent node.
  • the relay node in response to receiving the recovery attempt notification, forwards the first packet received from the first parent node to a child node of the relay node (eg, child node 300-C), and the child node forwards the second packet received from to the second parent node (for example, parent node 300-P2) that is the parent node of the relay node.
  • the relay node checks the destination BAP address included in the header of the received packet, and if the BAP address matches the preset BAP address of the donor node, it is determined to be in the upstream direction, and they do not match. If so, it may be determined to be in the downstream direction.
  • the IAB node 300-T executes local rerouting for packet transmission in the upstream direction, and executes routing setup by the donor node 200 for packet transmission in the downstream direction. Therefore, the IAB node 300-T can perform transfer appropriately without changing the transfer destination of all packets to be transferred.
  • FIG. 10 is a diagram showing an operation example according to the first embodiment. An operation example will be described by using the configuration example shown in FIG. 9 as appropriate.
  • step S10 the IAB node 300-T starts processing.
  • step S11 the IAB node 300-T receives Type 2 Indication from the parent node 300-P1.
  • step S12 the IAB node 300-T performs local rerouting for packet transfer in the upstream direction, and the routing configuration set by the donor node 200 for packet transfer in the downstream direction (hereinafter referred to as , sometimes referred to as “normal routing”).
  • Packets in the upstream direction include packets in the upstream direction buffered in the IAB node 300-T and packets newly received from the child node 300-C after receiving the Type 2 Indication. Specifically, after receiving the packet waiting for transmission in the upstream direction existing in the IAB-MT of the IAB node 300-T and the Type 2 Indication, the IAB-DU of the IAB node 300-T sends received packets.
  • the IAB-MT (or BAP entity) of IAB node 300-T performs local rerouting for packets in the upstream direction, selects an alternative path, and to the parent node 300-P2.
  • downstream packets include downstream packets buffered in the IAB node 300-T and packets received from the parent node 300-P1 after receiving Type 2 Indication.
  • the IAB-MT of the IAB node 300-T receives from the parent node 300-P1 including packets that The IAB-DU (or BAP entity) of the IAB node 300-T performs normal routing on packets in the downstream direction and forwards the packets according to the routing settings.
  • step S13 the IAB node 300-T determines whether or not it has received a Type 3 BH RLF Indication (hereinafter sometimes referred to as "Type 3 Indication") from the parent node 300-P1.
  • Type 3 Indication is a recovery notification indicating recovery from BH PLF.
  • step S13 if the IAB node 300-T does not receive the Type 3 Indication (NO in step S13), it proceeds to step S12 and performs the processing of S12 until it receives the Type 3 Indication.
  • step S13 when the IAB node 300-T receives the Type 3 Indication (YES in step S13), it performs the processing of step S14.
  • the IAB node 300-T stops performing local rerouting for forwarding packets in the upstream direction.
  • the IAB node 300-T since the IAB node 300-T received the Type 3 Indication from the parent node 300-P1, it stops local rerouting.
  • the IAB node 300-T forwards packets in the upstream direction to the parent node 300-P1 by stopping local rerouting.
  • step S15 the IAB node 300-T ends the series of processes.
  • Type 2 Indication may be used to trigger the deactivation of IAB support (IAB-Support) included in System Information Block (SIB) 1.
  • IAB support is one of the information elements contained in SIB1.
  • IAB support is an information element (IAB-Support IE ).
  • UE 100 or child node 300-C that receives SIB1 including IAB support can recognize that IAB node 300-T that transmitted SIB1 supports IAB.
  • the IAB node 300-T receives a Type 2 Indication from its parent node 300-P1.
  • the donor node 200 can be accessed using the alternative path.
  • the donor node 200 cannot be accessed from the IAB node 300-T, and the child node 300-C or the UE 100 cannot access the IAB node 300-T via the IAB node 300-T. may not be able to receive service from the network.
  • the IAB support (IAB-Support IE) information element Broadcast system information that does not include
  • IAB node 300-T has an alternate path to donor node 200, it broadcasts system information including IAB support.
  • a relay node for example, IAB node 300-T connects a parent node (for example, parent node 300-P1) of the relay node and a node (for example, node 500) which is a further parent node of the parent node.
  • a recovery attempt notification (for example, Type 2 Indication) is received from the first parent node indicating that the first parent node is attempting to recover from the failure that occurred in the backhaul link.
  • the relay node that received the recovery attempt notification does not have an alternative path to the donor node, the relay node's cell supports IAB and the cell is considered for the IAB node's cell selection.
  • System information not including IAB support which is an information element indicating a cell, is broadcast.
  • the child node 300-C or the UE 100 can appropriately determine whether or not it is possible to receive the IAB service from the IAB node 300-T.
  • FIG. 11 is a diagram showing an operation example according to the second embodiment. An operation example will be described by using the configuration example shown in FIG. 9 as appropriate.
  • step S20 the IAB node 300-T starts processing.
  • the IAB node 300-T receives the Type 2 Indication from the parent node 300-P1.
  • the IAB node 300-T determines whether an alternative path to the donor node 200 exists. For example, in FIG. 9, dual connectivity (DC (Dual Connectivity)) with parent node 300-P1 as the master node (or master cell group) and parent node 300-P2 as the secondary node (or secondary cell group) is set. Assume that In such a case, IAB node 300-T can determine that there is an alternate path to parent node 300-P2 as an alternate path to parent node 300-P1. On the other hand, if the IAB node 300-T does not have such dual connectivity and has a single connection with the parent node 300-P1, there is no alternative path.
  • DC Direct Connectivity
  • the IAB node 300-T determines that there is an alternative path to the donor node 200 if the parent node 300-P2 is set as a secondary node by setting the DC, and if the DC is not set , it may be determined that there is no alternate path to donor node 200 .
  • the setting of the DC is performed, for example, by the CU of the donor node 200 to the IAB-MT of the IAB node 300-T using an RRC Reconfiguration message.
  • step S22 determines in step S22 that there is no alternative path to the donor node 200 (NO in step S22), it performs the process of step S23.
  • step S23 the IAB node 300-T removes the information element IAB support (IAB-Support IE) from SIB1.
  • the IAB node 300-T then broadcasts SIB1 that does not include IAB support.
  • step S24 the IAB node 300-T determines whether or not the Type 3 Indication has been received from the parent node 300-P1.
  • step S24 if the IAB node 300-T determines that the Type 3 Indication has not been received from the parent node 300-P1 (NO in step S24), it repeats the processing of step S23 until it receives the Type 3 Indication.
  • step S24 determines in step S24 that it has received a Type 3 Indication from the parent node 300-P1 (YES in step S24), it performs step S25.
  • step S25 the IAB node 300-T sets the information element IAB support (IAB-Support IE) to SIB1.
  • the IAB node 300-T then broadcasts SIB1 including IAB support.
  • step S26 the IAB node 300-T ends the series of processes.
  • the IAB node 300-T determines in step S22 that there is an alternative path to the donor node 200 (YES in step S22), it proceeds to step S25 and repeats the above-described processes. In this case, since there is an alternative path, the IAB node 300-T broadcasts SIB1 including IAB support.
  • SR and BSR SR (Scheduling Request) and BSR (Buffer Status Report) according to the third embodiment will be described.
  • FIG. 12(A) is a diagram showing an example of SR and BSR according to the third embodiment.
  • the IAB-MT of the IAB node 300-T uses the BSR to transmit the amount of data in the transmission buffer of each logical channel to the IAB-DU of the parent node 300-P. have a function.
  • the IAB-DU of the parent node 300-P allocates uplink radio link radio resources (UL resources) based on the BSR.
  • the IAB-MT of IAB node 300-T uses UL resources to transmit data to parent node 300-P.
  • the IAB node 300-T assigns a logical channel group (LCG: Logical Channel Group) to each logical channel.
  • the IAB node 300-T then notifies the parent node 300-P of the transmission buffer capacity for each LCG as BSR.
  • the BSR may be a preemptive BSR (pre-emptive BSR). While the BSR actually informs the IAB node 300-T of the buffer amount of waiting packets waiting to be sent, the preemptive BSR indicates the amount of packets expected to reach the IAB node 300-T not yet buffered as a packet waiting to be sent).
  • the IAB node 300-T transmits the BSR using PUSCH (Physical Uplink Shared Channel). However, the IAB node 300-T transmits SR using PUCCH (Physical Uplink Control Channel) if PUSCH is not assigned when transmitting BSR. The IAB node 300-T transmits SR using PRACH (Physical Random Access Channel) when PUCCH for transmitting SR is not assigned. Parent node 300-P allocates UL resources to IAB node 300-T based on the SR, and IAB node 300-T uses the UL resources to transmit data.
  • PUSCH Physical Uplink Shared Channel
  • PUCCH Physical Uplink Control Channel
  • PRACH Physical Random Access Channel
  • the IAB node 300-T can transmit BSR and/or SR using PUSCH and PUCCH.
  • Type 2 Indication may be used to trigger deactivation or reduction of SR and/or BSR.
  • Type 2 Indicators may be used to trigger no (or no) transmission of SR and/or BSR. Reduction is to transmit at a predetermined number of times of transmission or less, which is less than the original number of times of transmission.
  • Type 2 Indication may be used to trigger transmission of SR and/or BSR less than or equal to a predetermined number of transmissions.
  • FIG. 12(B) is a diagram showing an example of Type 2 Indication according to the third embodiment.
  • the IAB node 300-T receives a Type 2 Indication from the parent node 300-P, as shown in FIG. 12(B).
  • the IAB node 300-T transmits an SR or BSR to the parent node 300-P and receives radio resource allocation from the parent node 300-P.
  • the parent node 300-P cannot forward the packet to the node 500 because RLF has occurred.
  • IAB node 300-T may waste packet forwarding to parent node 300-P.
  • the IAB node 300-T that has received the Type 2 Indication does not transmit SR and/or BSR, or if the number of transmissions is less than a predetermined number of transmissions, then such packet transfer will be eliminated or more less. Therefore, it is effective for the IAB node 300-T that has received the Type 2 Indication not to transmit SR and/or BSR, or to limit the number of transmissions to a predetermined number of transmissions or less.
  • SR and/or BSR are transmitted a predetermined number of times or less, but the number of transmissions themselves is less than the original number of transmissions, so interference with other cells can be prevented. . Also, in the case of deactivation, since transmission is not performed, it is possible to further prevent interference with other cells.
  • the parent node 300-P transmits Type 3 Indication to the IAB node 300-T and receives SR and/or BSR from the IAB node 300-T. Then schedule. Therefore, the parent node 300-P may experience a delay compared to scheduling immediately after the BH RLF is resolved. On the other hand, in the case of reduction, if the parent node 300-P receives the SR and/or BSR immediately after the BH RLF is resolved, the delay will be less than in the case of deactivation.
  • the IAB node 300-T when the IAB node 300-T receives a Type 2 Indication, the IAB node 300-T receives a setting as to whether transmission of SR, BSR, and/or UL packets should be deactivated or reduced. Then, when the IAB node 300-T receives the Type 2 Indication, it deactivates or reduces transmission of SR, BSR, and/or UL packets according to the setting.
  • a relay node (eg, IAB node 300-T) is a parent node (eg, parent node 300-P) of the relay node and a node (eg, node 500-P) which is a parent node of the parent node (eg, node 500-P). ) does not perform the prescribed transmission when a recovery attempt notification is received from the parent node indicating that the parent node is attempting to recover from the failure that occurred on the backhaul link between A setting is received to perform a predetermined transmission within a predetermined number of transmissions.
  • a recovery attempt notification is received from the parent node indicating that the parent node is attempting to recover from the failure that occurred on the backhaul link between
  • a setting is received to perform a predetermined transmission within a predetermined number of transmissions.
  • the relay node in response to receiving the recovery attempt notification, the relay node does not perform a predetermined transmission to the parent node or performs a predetermined transmission less than or equal to the predetermined number of transmissions to the parent node according to the setting.
  • a predetermined transmission is the transmission of SR, BSR and/or UL packets. In the following, transmission of SR, BSR and/or UL packets may be referred to as "predetermined transmission”.
  • the IAB node 300-T will not transmit packets to the parent node 300-P that is attempting to recover from the failure, or the number of transmissions will be less than the predetermined number of times, so that unnecessary packet transmission can be suppressed.
  • the IAB node 300-T since the IAB node 300-T does not perform the predetermined transmission or the number of transmissions is less than the predetermined number, it can prevent interference with other cells compared to normal transmission.
  • the IAB node 300-T has less delay when the reduction setting is performed than when the deactivation setting is performed.
  • FIG. 13 is a diagram showing an operation example according to the third embodiment.
  • the IAB node 300-T starts processing in step S30.
  • the IAB node 300-T receives a setting as to whether to deactivate or reduce a predetermined transmission upon receiving a Type 2 Indication.
  • the setting may be performed by donor node 200 .
  • the IAB-CU of the donor node 200 performs the setting for the IAB-MT of the IAB node 300-T using an RRC message such as an RRC reconfiguration message.
  • the setting may be made by the parent node 300-P.
  • the IAB-DU of the parent node 300-P makes the relevant settings for the IAB-MT of the IAB node 300-T using MAC CE or BAP Control PDU.
  • the IAB node 300-T receives the Type 2 Indication from the parent node 300-P.
  • step S33 the IAB node 300-T deactivates or reduces a predetermined transmission according to the setting in step S31.
  • the IAB node 300-T may keep the triggered predetermined transmission pending in the buffer.
  • the IAB node 300-T may not trigger SR, BSR and/or UL packets.
  • step S34 the IAB node 300-T determines whether or not a Type 3 Indication has been received from the parent node 300-P.
  • step S34 determines in step S34 that the Type 3 Indication has not been received (NO in step S34), it proceeds to step S33 and repeats the processing of step S33 until it receives the Type 3 Indication.
  • step S34 determines in step S34 that it has received a Type 3 Indication (YES in step S34), it performs step S35.
  • the IAB node 300-T performs a predetermined transmission (re-)activation or normal transmission.
  • Normal transmission means performing a predetermined transmission without reducing the number of transmissions.
  • the IAB node 300-T may read the SR, BSR, and/or UL packets pending in the buffer from the buffer and transmit them. That is, the IAB node 300-T forwards the triggered SR, BSR, and/or UL packet to the lower layer upon receipt of the Type 3 Indication.
  • the IAB node 300-T may be in a state that may trigger SR, BSR, and/or UL packets.
  • step S36 the IAB node 300-T ends the series of processes.
  • Modification 1 of the third embodiment In the third embodiment, an example has been described in which, when the IAB node 300-T receives the Type 2 Indication, the reduction is performed so that the number of transmissions of the predetermined transmission is equal to or less than the predetermined number of transmissions.
  • Modified Example 1 is an example of implementing reduction using a prohibit timer.
  • the relay node receives setting of the prohibition timer value.
  • the relay node receives the recovery attempt notification and performs the predetermined transmission within the predetermined number of transmissions.
  • the predetermined transmission is not performed until the prohibition timer value expires, and the prohibition timer value expires. Then, predetermined transmission is performed.
  • the relay node can perform the predetermined transmission within the predetermined number of times of transmission.
  • FIG. 14 is a diagram showing an operation example according to modification 1 of the third embodiment.
  • the IAB node 300-T starts processing in step S30.
  • the IAB node 300-T sets a prohibition timer value for reducing a predetermined transmission when receiving a Type 2 Indication.
  • the inhibit timer value may be set by donor node 200 .
  • donor node 200 may configure by sending an RRC message, such as an RRC reconfiguration message, to IAB node 300-T.
  • the inhibit timer value may be set by the parent node 300-P.
  • the parent node 300-P may make settings by transmitting a MAC CE or BAP Control PDU to the IAB node 300-T.
  • the IAB node 300-T receives the Type 2 Indication.
  • the IAB node 300-T starts the prohibition timer.
  • step S34 the IAB node 300-T does not trigger SR, BSR and/or UL packets while the prohibit timer is running.
  • the IAB node 300-T pending transmission of SR, BSR, and/or UL packets.
  • the IAB node 300-T may hold pending SR, BSR, and/or UL packets in its buffer.
  • step S35 the IAB node 300-T determines whether the prohibition timer has expired. Whether or not the prohibition timer has expired is determined by whether or not the prohibition timer has reached the prohibition timer value.
  • step S35 determines in step S35 that the prohibition timer has not expired (NO in step S35), it proceeds to step S34 and repeats the processing of step S34 until it expires.
  • step S35 determines in step S35 that the prohibition timer has expired (YES in step S35), it performs the processing of step S36.
  • the IAB node 300-T allows the triggering of SR, BSR, and/or UL packets.
  • the IAB node 300-T is permitted to perform predetermined transmissions, and performs predetermined transmissions (at predetermined timings).
  • the IAB node 300-T may transmit pending SR, BSR, and/or UL packets (at predetermined times).
  • the IAB node 300-T restarts the prohibition timer.
  • the IAB node 300-T may restart the prohibit timer when the prohibit timer expires, or may restart the prohibit timer when a predetermined transmission is performed.
  • step S38 the IAB node 300-T determines whether or not the Type 3 Indication has been received from the parent node 300-P. In step S38, when the IAB node 300-T determines that the Type 3 Indication has not been received (NO in step S38), the process proceeds to step S34, and the above-described processes are repeated.
  • step S38 determines in step S38 that it has received a Type 3 Indication (YES in step S38), it performs step S39.
  • the IAB node 300-T stops the prohibition timer.
  • step S40 the IAB node 300-T ends the series of processes.
  • the IAB node 300-T when the IAB node 300-T receives a Type 2 Indication, it starts the prohibition timer, does not transmit SR, BSR, and/or UL packets while the prohibition timer is running, and the prohibition timer expires. Then, predetermined transmission is performed. As a result, the IAB node 300-T can reduce the number of transmissions of the predetermined transmission after receiving the Type 2 Indication, and achieve reduction of the predetermined transmission.
  • Modification 1 of the third embodiment has described an example in which a prohibition timer is used to implement reduction for a predetermined transmission after receiving a Type 2 Indication.
  • Modification 2 of the third embodiment is an example in which a counter is used to implement reduction for a predetermined transmission after receiving Type 2 Indication.
  • the relay node receives setting of the counter value. Secondly, when the relay node receives the recovery attempt notification and performs predetermined transmission for a predetermined number of transmissions or less, it does not perform predetermined transmission until the transmission chance of predetermined transmission reaches the counter threshold value. When the opportunity reaches the counter threshold, perform the predetermined transmission. As a result, after receiving the recovery attempt notification, the relay node can perform the predetermined transmission within the predetermined number of transmissions.
  • FIG. 15 is a diagram showing an operation example according to modification 2 of the third embodiment.
  • the IAB node 300-T starts processing in step S50.
  • the IAB node 300-T sets a counter threshold for reducing a predetermined transmission when receiving a Type 2 Indication.
  • the counter threshold may be set by donor node 200 .
  • the donor node 200 may configure the IAB node 300-T using RRC messages such as RRC reconfiguration messages.
  • the counter threshold may be set by the parent node 300-P.
  • the parent node 300-P may make settings for the IAB node 300-T using MAC CE or BAP Control PDU.
  • the IAB node 300-T receives the Type 2 Indication from the parent node 300-P.
  • step S53 the IAB node 300-T sets the counter value of the counter to "0".
  • step S54 the IAB node 300-T increments the counter value when an SR, BSR, and/or UL packet transmission opportunity comes. In other words, the IAB node 300-T increments the counter value without transmitting even if there is an opportunity to transmit SR, BSR, and /UL packets.
  • the SR transmission opportunity is the predetermined timing of the PUCCH.
  • a BSR transmission opportunity is a predetermined timing of PUSCH.
  • the transmission opportunity for UL packets is also the predetermined timing of PUSCH.
  • step S55 the IAB node 300-T determines whether the counter value has reached the counter threshold value. If the IAB node 300-T determines in step S55 that the counter value has not reached the counter threshold value (NO in step S55), it repeats the processing of step S54 until the counter value reaches the counter threshold value.
  • step S55 determines in step S55 that the counter value has reached the counter threshold value (YES in step S55), it performs step S56.
  • the IAB node 300-T performs a predetermined transmission at the transmission opportunity of the predetermined transmission.
  • step S57 the IAB node 300-T sets the counter value to "0".
  • the IAB node 300-T may set the counter value to "0" when the counter value reaches the counter threshold, or set the counter value to "0" when a predetermined transmission is performed. May be set.
  • step S58 the IAB node 300-T determines whether or not it has received a Type 3 Indication from the parent node 300-P.
  • step S58 when the IAB node 300-T determines that the Type 3 Indication has not been received from the parent node 300-P (NO in step S58), the process proceeds to step S54 and repeats the above-described processes.
  • step S58 determines in step S58 that it has received the Type 3 Indication from the parent node 300-P (YES in step S58), it performs the processing of step S59.
  • the IAB node 300-T stops the counting operation of the counter.
  • the IAB node 300-T ends the series of processes.
  • the IAB node 300-T upon receiving the Type2 Indication, counts with a counter without transmitting at the SR, BSR, and/or UL packet transmission opportunities, and when the count value reaches the count threshold , the transmission is performed at a transmission opportunity of a predetermined transmission.
  • the IAB node 300-T can reduce the number of transmissions of the predetermined transmission and achieve reduction of the predetermined transmission.
  • Modification 3 of the third embodiment In the third embodiment, when Type 2 Indication is received, reduction is described in which the number of transmissions of SR and/or BSR is set to a predetermined number of transmissions or less. On the other hand, in Modification 3 of the third embodiment, when the parent node 300-P that transmits the Type 2 Indication receives SR and/or BSR by reduction from the child node (IAB node 300-T), This is an example of not transmitting a UL grant to a child node.
  • a relay node eg, IAB node 300-T
  • a parent node eg, parent node 300-P
  • the relay node performs a predetermined transmission within a predetermined number of times of transmission according to the settings.
  • a parent node should not send a UL grant to a relay node in response to receiving scheduling requests and/or buffer status reports less than a predetermined number of transmissions.
  • the relay node will no longer forward the packet to the parent node that is trying to recover from the BH RLF, and will be able to perform proper transmission.
  • FIG. 16 is a diagram showing an operation example according to the third modified example of the third embodiment.
  • step S70 the IAB node 300-T starts processing.
  • step S71 the IAB node 300-T sets reduction for transmission of SR and/or BSR when Type 2 Indication is received.
  • the setting itself may be performed by the donor node 200 or by the parent node 300-P as in the third embodiment.
  • the IAB node 300-T receives the Type 2 Indication from the parent node 300-P.
  • step S73 the IAB node 300-T reduces transmission of SR and/or BSR according to the settings.
  • step S74 even if the parent node 300-P receives the SR and/or BSR, it does not transmit the UL grant to the child node (IAB node 300-T) that transmitted the SR and/or BSR.
  • step S75 the parent node 300-P determines whether or not the BH RLF recovery has succeeded. For example, the parent node 300-P performs cell selection processing for the node on the BH link where the BH RLF occurred, and determines whether or not a cell that satisfies the minimum radio quality for that node is found. You may If the parent node 300-P determines that the BH RLF recovery has not succeeded (NO in step S75), it repeats the process of step S74 until it succeeds.
  • step S75 when the parent node 300-P determines that the BH RLF recovery has succeeded (YES in step S75), it performs the processing of step S76.
  • step S76 when the parent node 300-P receives the SR and/or BSR, it transmits the UL grant to the child node (IAB node 300-T). Note that the parent node 300-P may transmit the Type 3 Indication to the child node, and then transmit the UL grant.
  • step S77 the parent node 300-P ends the series of processes.
  • the IAB node 300-T that has received the Type 2 Indication sends a notification to the donor node 200 via the parent node 300-P2 indicating that the Type 2 Indication has been received from the parent node 300-P1. be.
  • FIG. 17 is a diagram showing a configuration example of an IAB network according to the fourth embodiment.
  • the donor node 200 centrally manages IAB topology resources, topology, routes, etc. in the IAB network. For example, as shown in FIG. 17, RLF occurs on BH link #1 between parent node 300-P1 and its parent node, node 500, and parent node 300-P1 attempts to recover from the BH RLF. Suppose you are in In such a case, if the donor node 200 can grasp that the IAB node is in such a situation, it becomes possible to centrally manage the entire IAB node 300 under its control.
  • the IAB node 300-T receives a Type 2 Indication from the parent node 300-P1, even if it notifies the parent node 300-P1 of the reception, RLF occurs on the BH link #1. , the notification does not reach the donor node 200 .
  • the IAB node 300-T it is assumed that two routes of parent node 300-P1 and parent node 300-P2 are secured by DC setting. In this case, the IAB node 300-T can send the notification to the donor node 200 via the parent node 300-P2.
  • the relay node eg, IAB node 300-T
  • the first parent node eg, parent node 300-P1
  • a recovery attempt notification indicating that the first parent node is trying to recover from a failure that occurred in the backhaul link between the parent node (for example, the node 500) is sent to the first receive from the parent node of
  • the relay node acknowledges receipt of the recovery attempt notification from the first parent node by way of the second parent node, which is the parent node of the relay node, in response to receiving the recovery attempt notification. Send to node. This allows the relay node to transmit the receipt of the recovery attempt notification from the first parent node to the donor node via the second parent node. Therefore, it becomes possible to contribute to centralized management by the donor node.
  • FIG. 18 is a diagram showing an operation example according to the fourth embodiment. Note that in the operation example shown in FIG. 18, it is assumed that the IAB node 300-T is configured for dual connectivity (DC). For example, the CU of the donor node 200 uses an RRC message (for example, an RRC reconfiguration message) to the IAB-MT of the IAB node 300-T to establish the parent node 300-P1 as MCG (Master Cell Group), the parent It is assumed that node 300-P2 is set to SCG (Secondary Cell Group).
  • RRC message for example, an RRC reconfiguration message
  • step S90 the IAB node 300-T starts processing.
  • step S91 the IAB node 300-T receives Type 2 Indication from the parent node 300-P1.
  • the IAB node 300-T decides to perform local rerouting to the parent node 300-P2, which is different from the parent node 300-P1 (with respect to packet forwarding in the upstream direction), as in the first embodiment. You may
  • the IAB node 300-T transmits to the donor node 200 via another parent node 300-P2 a notification indicating that it has received a Type 2 Indication from the parent node 300-P1.
  • This notification indicates that instead of (or in addition to) receiving a Type 2 Indication from the parent node 300-P1, it has decided to execute local rerouting (in relation to forwarding packets in the upstream direction).
  • Such notice may include:
  • Routing ID (or Path ID) before local rerouting:
  • the routing ID is specified by the donor node 200 to the IAB node 300-T before the IAB node 300-T decides to perform local rerouting. This is the set routing ID.
  • Routing ID (or path ID) after local rerouting:
  • the routing ID is the routing ID set by the IAB node 300-T after the IAB node 300-T decided to perform local rerouting.
  • the routing ID includes the parent node 300-P2 or the donor node's BAP address and/or path ID.
  • the IAB node 300-T will itself generate the routing ID whose destination BAP address is the parent node 300-T and include it in the notification.
  • the donor node 200 sets an alternative path (or alternative routing ID) to the IAB node 300-T, and the IAB node 300-T indicates A2) from among the set alternative paths.
  • a routing ID may be selected.
  • A5) Reason information (Cause) indicating "local rerouting by receiving Type 2 Indication” All or part of A1) to A5) above may be included in the notification.
  • the notification may be transmitted by the IAB-MT of the IAB node 300-T transmitting an RRC message including the notification to the CU of the donor node 200 via the parent node 300-P2. .
  • the donor node 200 executes rerouting of packets addressed to the IAB node 300-T.
  • donor node 200 causes packets destined for IAB node 300-T or downstream via IAB node 300-T to be sent via an alternate path via parent node 300-P2. .
  • step S94 the IAB node 300-T ends the series of processes.
  • the IAB node 300-T may transmit a notification indicating that the Type 3 Indication has been received from the parent node 300-P1 to the donor node 200 in response to receiving the Type 3 Indication from the parent node 300-P1. .
  • a notification may be sent indicating that local rerouting has stopped.
  • the IAB node 300-T may send the notification to the donor node 200 via the parent node 300-P1 or to the donor node via the parent node 300-P2.
  • 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.
  • the UE 100, gNB 200, or a circuit that executes each process performed by the IAB node 300 is integrated, and at least a portion of the UE 100, gNB 200, or IAB node 300 is a semiconductor integrated circuit (chipset, SoC (System-on-a- chip)).
  • 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 discusses conditional handovers and begins discussions on intra-donor conditional handovers up to inter-donor IAB node transitions facilitated in RAN3.
  • RAN2 confirms its intention that Rel-16 conditional handover is/can be used for IAB-MT (whether changes are required needs further consideration).
  • RAN2 assumes that the Rel-16 specification is the baseline for setting default routes, IP addresses, and target paths for intra-donor conditional handovers.
  • - RAN2 supports Type 2/3 RLF Indication (details need further study).
  • a Type 2 RLF Indication can be used to trigger local rerouting.
  • Type 2 RLF Indication can be used to trigger deactivation of IABs supported by SIBs.
  • Type 2 RLF Indication can be used to trigger deactivation or reduction of SR and/or BSR transmissions.
  • Local rerouting can be triggered by indicating hop-by-hop flow control. Details such as trigger information, trigger conditions, role of CU setting, etc. need further study.
  • RAN2 considers local rerouting of inter-donor DUs in scope.
  • This appendix describes various topics of topology adaptation enhancements for Rel-17 eIABs. Specifically, BH RLF Indication enhancements, conditional handover enhancements, local rerouting enhancements, and some other enhancements.
  • Type 4 "recovery failure” was defined as a 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.
  • RAN2 agreed to introduce Type 2 "Attempting recovery” and Type 3 "Recovery of BH link”.
  • Type 2 RLF Indication can be used to trigger local rerouting.
  • Type 2 RLF Indication can be used to trigger deactivation of IABs supported by SIBs.
  • Type 2 RLF Indication can be used to trigger deactivation or reduction of SR and/or BSR transmissions.
  • Proposal 1 RAN2 should agree to stipulate 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 should specify that when IAB-MT receives a Type 3 BH RLF Indication from the parent node, it will stop local rerouting on the upstream path, that is, return to the configured "normal" routing. I have to agree.
  • the deactivation of the IAB-Support IE in SIB1 it can be regarded as the operation of IAB-DU until it is widely implemented in Rel-16. Therefore, specifying only at stage 2 is probably sufficient. For operational details, it is assumed that the IAB-DU may not remove the IAB-Support IE from SIB1 if there is still an alternate path to the donor. This should be clarified when the 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 path to the IAB donor.
  • the IAB-Support IE if the IAB-Support IE is not present in SIB1, the IAB-MT will not initiate connection establishment to the parent node.
  • One question is whether the UE is allowed access to the cell (parent node) even if the parent node is under BH RLF. This has a negative impact on the user as the RRC setup request cannot reach the CU, ie the donor. To avoid this, for example, the cell either prohibits UE access, stops SSB, or broadcasts Type 2 BH RLF Indication via SIB1. Similar to proposal 3, there is no need to remove the IAB Support IE from SIB1 if the IAB node has an alternate path to the donor.
  • 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 path to IAB donor .
  • deactivation or reduction of SR and/or BSR transmissions it is necessary to clearly define them as they may be regarded as IAB-MT operations.
  • deactivation may be easier from a specification point of view.
  • SR and/or BSR can only be sent after receiving Type 3, which may cause scheduling delays.
  • “reduction” may allow scheduling to resume immediately after the BH link recovers.
  • unwanted interference occurs. 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 stipulate deactivation or reduction of SR and/or BSR transmissions when IAB-MT receives a Type 2 BH RLF Indication from the parent node.
  • Proposal 6 RAN2 should agree to stipulate that the normal procedure for SR and/or BSR transmission can be resumed when IAB-MT receives a Type 3 BH RLF Indication from the parent node.
  • Proposal 7 RAN2 considers whether to support SR and/or BSR "deactivation”, “reduction”, or both (i.e. configurable) when Type 2 BH RLF Indication is received from the parent node There is a need to.
  • Type 2 and Type 3 BH RLF Indication can be easily transmitted via BAP control PDU.
  • the UE cannot receive the BAP control PDUs because the UE does not have a BAP layer. Therefore, these BH RLF Indications may be broadcast over SIB1 and SIB1 may be encoded by DU. Therefore, RAN2 needs to consider whether these are sent via BAP Control PDUs or SIB1.
  • Proposal 8 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. Our understanding is that conditional handover can be used for the Rel-16 IAB specified. RAN2#113-e reached the following agreement: Therefore, it is worth considering eIAB conditional handover extensions in addition to Rel-16 conditional handovers.
  • RAN2 discusses conditional handovers and begins discussions on intra-donor conditional handovers up to inter-donor IAB node transitions facilitated in RAN3. • RAN2 confirms its intention that Rel-16 conditional handover can/can be used for IAB-MT (whether changes are required needs further study). • RAN2 assumes that the Rel-16 specification is the baseline for setting default routes, IP addresses, and target paths for intra-donor conditional handovers.
  • conditional handover when the corresponding conditional handover event (A3/A5) is satisfied or when the selected cell is a conditional handover candidate as a result of RRC re-establishment cell selection executed.
  • the following principles apply to conditional handovers: -
  • the conditional handover configuration includes the conditional handover candidate cell configuration generated by the candidate gNB and the execution conditions generated by the source gNB. • Execution conditions are set with one or two trigger conditions (conditional handover events A3/A5). Only a single RS Type is supported, and up to two different trigger quantities (RSRP and RSRQ, RSRP and SINR, etc.) can be set simultaneously to evaluate conditional handover execution conditions for a single candidate cell.
  • the UE After RLF is declared, the UE does the following: • Remain in the RRC connected state. For conditional handover, for the RLF of the source cell: Select a suitable cell, and if the selected cell is a conditional handover candidate and the network configures the UE to attempt conditional handover after RLF, the UE will attempt to perform conditional handover once. do. Otherwise, re-establishment is performed. • Enter the RRC idle state if no suitable cell is found within a certain time after the RLF is declared.
  • Conditional handover events A3/A5 can be met when an IAB node experiences BH RLF on a BH link.
  • these trigger conditions cannot be satisfied by the IAB-specific RLF, that is, the RLF by receiving the BH RLF Indication (Type 4).
  • one desired action is for the IAB node to perform a conditional handover when it receives a BH RLF Indication.
  • conditional handovers are not supported even if the parent node's BH RLF recovery is in progress and fails because the BH link between the IAB-MT and the parent node still exists. Not automatically triggered/executed by conditional handover events A3/A5 at the MT.
  • Proposal 9 RAN2 should discuss whether additional trigger conditions for conditional handover are defined, that is, at least when the IAB node receives a BH RLF Indication (Type 4). If introduced, further examination is required to see if it can be applied to Type 2.
  • Proposal 9 does not depend on conditional handover events A3/A5, but is a kind of forced trigger by BH RLF Indication, so that all conditional handover candidates (i.e. candidate cells) are simultaneously conditional A handover may be triggered.
  • conditional handover it is up to the UE implementation which cell to choose when multiple candidate cells trigger conditional handover execution.
  • IAB-MT IAB-MT triggered by implementation depending on local radio quality etc Selecting one of the identified cells is not always the best approach. Therefore, RAN2 needs to consider how IAB donor-controlled conditional handover execution with additional trigger conditions works as in Proposal 9. For example, an IAB donor can configure priority information associated with a conditional handover candidate in the conditional handover configuration. The IAB-MT needs to select the highest priority cell from all triggered conditional handover candidates that meet a certain radio quality (such as the S criterion).
  • a certain radio quality such as the S criterion
  • Proposal 10 RAN2 should consider whether it is necessary to perform IAB donor-controlled conditional handovers as an additional extension if all candidate cells trigger conditional handovers upon receipt of the BH RLF Indication. be.
  • 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.
  • Rel-16 local rerouting, it is up to the IAB node implementation which path is selected as the alternative path as long as the destination is the same. This means that local rerouting is based on local decisions and cannot be controlled from the IAB donor's perspective. This may be inconsistent with the goals of the overall topology, especially when many local decisions are generated and accumulated in the IAB topology.
  • IAB donor controllability should become more important. It is straightforward for IAB donors to be able 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 11 RAN2 should consider whether IAB donors can set up IAB nodes using alternate paths in addition to Rel-16 routing settings.
  • IAB donor controllability Another aspect of IAB donor controllability is that IAB donors should be aware of local rerouting and consider that they can start/stop local rerouting at IAB nodes for local rerouting and topology-wide coexistence. For example, an IAB donor can consider whether the overall topology goals are still being met based on which IAB nodes are currently performing local rerouting. 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 12 RAN2 should consider whether IAB nodes need to notify IAB donors when starting/stopping local rerouting.
  • Proposal 13 RAN2 should discuss whether IAB donors can instruct IAB nodes to start/stop local rerouting.
  • Proposal 14 RAN2 should agree that optimization of cell (re)selection should be considered to avoid re-establishment to inappropriate nodes (eg, descendant nodes).
  • the IAB-MT is offered either in a whitelist or blacklist kind. obtain.
  • whitelists and blacklists have advantages depending on the topology and location of the IAB nodes. and disadvantages.
  • IAB nodes near the IAB donor i.e., from the top-level perspective of the DAG topology
  • the number of candidate nodes is small, possibly only IAB donor DUs, so it is more reasonable to provide a whitelist. be.
  • the blacklist contains, for example, only downstream IAB nodes of the concerned IAB node, and possibly only a few child IAB nodes, which in this case has the advantage of less overhead.
  • the IAB donor or parent IAB node
  • whitelisting or blacklisting it is desirable for the IAB donor (or parent IAB node) to be able to choose between whitelisting or blacklisting. Note that it may be beneficial to reuse this information for cell reselection purposes.
  • Proposal 15 RAN2 should agree that the IAB-MT is provided with a whitelist or blacklist (ie selection structure) for the purpose of cell selection, in order to avoid re-establishment to descendant nodes. Whether these lists can also be used for cell reselection procedures needs further study.
  • a whitelist or blacklist ie selection structure
  • Option 1 assumes a CHO setting and may require some enhancements.
  • Option 2 assumes additional indications, such as type 2 BH RLF indications.
  • Option 3 is intended to provide information on the entire topology that is not present in existing settings.
  • Option 5 assumes setting by OAM, but as the rapporteur pointed out, this is questionable.
  • the whitelist/blacklist provision method is dynamic. should be the way. Therefore, option 5, OAM, should be ruled out. Which method, ie, option 1, 2, or 3, should be the baseline for expansion needs further consideration.
  • Proposal 16 RAN2 should agree that the whitelist/blacklist is dynamically provided by the parent IAB node or IAB donor whenever the topology changes. Further study is required for details.
  • the second solution "rerouting PDCP PDUs buffered at intermediate IAB nodes", was supported as an implementation option at the BAP layer. Further, the BAP layer may perform "implementation dependent, eg, data buffering in the transmit portion of the BAP entity until the RLC-AM entity receives an acknowledgment". These BAP implementations were considered to avoid packet loss in "most" cases of Rel-16 deployment scenarios, i.e. when using fixed IAB nodes, but were not perfect, e.g. rice field.
  • the third solution "Introducing UL Status Delivery”, was the promised solution to ensure lossless delivery of UL data, given the evaluation results cited in Figure 20.
  • the idea was to delay the RLC ARQ to the UE so that PDCP data recovery at the UE is initiated when needed.
  • RAN2 should discuss enhanced mechanisms to ensure lossless delivery within L2 multi-hop networks in addition to results captured in TR.
  • Proposal 17: RAN2 is based on the solution specified in TR38.874, i.e. a mechanism to ensure lossless delivery under conditions where topology changes may occur frequently, based on some form of "UL status delivery" should agree to introduce
  • C-2 should be an enhanced baseline of Rel-17 for lossless delivery of UL packets.
  • Solution C-2 for "Introducing UL Status Delivery” may be an enhanced baseline for Rel-17, which can also be implemented for Rel-16.
  • Proposal 18 RAN2 should agree to define an RLC ARQ mechanism for lossless delivery of UL packets in Stage 2. This delays sending an ACK to the child node/UE before receiving an ACK from the parent IAB node (ie C-2). Whether/how to specify in Stage 3 requires further consideration.

Landscapes

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

Abstract

一態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードが、中継ノードの第１の親ノードと当該第１の親ノードの更に親ノードであるノードとの間のバックホールリンクで発生した障害に対して第１の親ノードが当該障害からの回復を試行中であることを示す回復試行通知を、第１の親ノードから受信することを有する。また、前記通信制御方法は、中継ノードが、回復試行通知の受信に応じて、前記第１の親ノードから受信した第１のパケットを前記中継ノードの子ノードへ転送し、前記子ノードから受信した第２のパケットを前記中継ノードの親ノードである第２の親ノードへ転送することを有する。

Description

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

Claims (12)

  1. 　セルラ通信システムで用いる通信制御方法であって、
    　中継ノードが、前記中継ノードの第１の親ノードと当該第１の親ノードの更に親ノードであるノードとの間のバックホールリンクで発生した障害に対して前記第１の親ノードが当該障害からの回復を試行中であることを示す回復試行通知を、前記第１の親ノードから受信することと、
    　前記中継ノードが、前記回復試行通知の受信に応じて、前記第１の親ノードから受信した第１のパケットを前記中継ノードの子ノードへ転送し、前記子ノードから受信した第２のパケットを前記中継ノードの親ノードである第２の親ノードへ転送することと、を有する、
    　通信制御方法。
  2. 　更に、前記中継ノードが、前記障害から回復したことを示す回復通知を前記第１の親ノードから受信することを含み、
    　前記転送することは、前記中継ノードが、前記第２のパケットを前記第２の親ノードへ転送することなく、前記第１の親ノードへ転送することを含む、
    　請求項１記載の通信制御方法。
  3. 　セルラ通信システムで用いる通信制御方法であって、
    　中継ノードが、前記中継ノードの親ノードと当該親ノードの更に親ノードであるノードとの間のバックホールリンクで発生した障害に対して第１の親ノードが当該障害からの回復を試行中であることを示す回復試行通知を、前記第１の親ノードから受信することと、
    　前記回復試行通知を受信した前記中継ノードが、ドナーノードへの代替パスが存在しない場合に、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ　Ａｃｃｅｓｓ　ａｎｄ　Ｂａｃｋｈａｕｌ）サポートを含まないシステム情報をブロードキャストで送信することと、を有し、
    　前記ＩＡＢサポートは、前記中継ノードのセルがＩＡＢをサポートし、かつ、当該セルがＩＡＢノードのセル選択として考慮されるセルであることを示す情報要素である、
    　通信制御方法。
  4. 　前記中継ノードが、前記ドナーノードへの代替パスが存在する場合、前記ＩＡＢサポートを含む前記システム情報をブロードキャストで送信することを有する、
    　請求項３記載の通信制御方法。
  5. 　前記中継ノードが、前記障害から回復したことを示す回復通知を前記親ノードから受信することと、
    　前記中継ノードが、前記回復通知の受信に応じて、前記ＩＡＢサポートを含む前記システム情報をブロードキャストで送信することと、を有する、
    　請求項３記載の通信制御方法。
  6. 　セルラ通信システムで用いる通信制御方法であって、
    　中継ノードが、前記中継ノードの親ノードと当該親ノードの更に親ノードであるノードとの間のバックホールリンクで発生した障害に対して前記親ノードが当該障害からの回復を試行中であることを示す回復試行通知を前記親ノードから受信した場合に、所定の送信を行わない又は所定送信回数以下で前記所定の送信を行う設定を受けることと、
    　前記中継ノードが、前記回復試行通知の受信に応じて、前記設定に従って、前記所定の送信を行わない又は前記所定送信回数以下で前記所定の送信を行うことと、を有し、
    　前記所定の送信は、前記親ノードへ、スケジューリング要求、バッファステータスレポート、及び／又はＵＬ（Ｕｐｌｉｎｋ）パケットの送信である、
    　通信制御方法。
  7. 　更に、前記中継ノードが、前記障害から回復したことを示す回復通知を前記親ノードから受信することを含み、
    　前記所定の送信を行うことは、前記中継ノードが、前記回復通知の受信に応じて、送信回数を減らすことなく、前記所定の送信を行うことを含む、
    　請求項６記載の通信制御方法。
  8. 　前記設定を受けることは、前記中継ノードが、禁止タイマー値の設定を受けることを含み、
    　前記所定の送信を行うことは、前記中継ノードが、前記禁止タイマー値が満了するまで、前記所定の送信を行わないで、前記禁止タイマー値が満了すると、前記所定の送信を行うことで、前記所定送信回数以下で前記所定の送信を行うことを含む、
    　請求項６記載の通信制御方法。
  9. 　前記設定を受けることは、前記中継ノードが、カウンタ値の設定を受けることを含み、
    　前記所定の送信を行うことは、前記中継ノードが、前記所定の送信の送信機会が前記カウンタ値に達するまで、前記所定の送信を行わないで、前記送信機会が前記カウンタ値に達すると、前記所定の送信を行うことで、前記所定送信回数以下で前記所定の送信を行うことを含む、
    　請求項６記載の通信制御方法。
  10. 　更に、前記親ノードが、前記中継ノードから、前記スケジューリング要求及び／又は前記バッファステータスレポートを前記所定送信回数以下で受信したことに応じて、前記中継ノードへ、ＵＬグラントを送信しないことを含む、
    　請求項６記載の通信制御方法。
  11. 　更に、ドナーノード又は前記親ノードが、前記設定を行うことを含む、
    　請求項６記載の通信制御方法。
  12. 　セルラ通信システムで用いる通信制御方法であって、
    　中継ノードが、前記中継ノードの第１の親ノードと当該第１の親ノードの更に親ノードであるノードとの間のバックホールリンクで発生した障害に対して前記第１の親ノードが当該障害からの回復を試行中であることを示す回復試行通知を、前記第１の親ノードから受信することと、
    　前記中継ノードが、前記回復試行通知を受信したことに応じて、前記第１の親ノードから前記回復試行通知を受信したことを、前記中継ノードの親ノードである第２の親ノードを介してドナーノードへ送信することと、を有する
    　通信制御方法。
PCT/JP2022/015026 2021-03-29 2022-03-28 通信制御方法 WO2022210546A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2023511267A JPWO2022210546A1 (ja) 2021-03-29 2022-03-28
US18/477,037 US20240032129A1 (en) 2021-03-29 2023-09-28 Communication control method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202163167227P 2021-03-29 2021-03-29
US63/167,227 2021-03-29

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/477,037 Continuation US20240032129A1 (en) 2021-03-29 2023-09-28 Communication control method

Publications (1)

Publication Number Publication Date
WO2022210546A1 true WO2022210546A1 (ja) 2022-10-06

Family

ID=83456315

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/015026 WO2022210546A1 (ja) 2021-03-29 2022-03-28 通信制御方法

Country Status (3)

Country Link
US (1) US20240032129A1 (ja)
JP (1) JPWO2022210546A1 (ja)
WO (1) WO2022210546A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230269656A1 (en) * 2022-02-18 2023-08-24 Qualcomm Incorporated Conditional authorization of mobile nodes

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
FUTUREWEI: "RAN2 impacts of Rel.17 IAB topology adaptation enhancements", 3GPP DRAFT; R2-2101798, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. electronic; 20210125 - 20210205, 15 January 2021 (2021-01-15), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051974663 *
QUALCOMM INCORPORATED (EMAIL DISCUSSION RAPPORTEUR): "Report from [Post112-e][066][eIAB] Topology Adaptation (QC)", 3GPP DRAFT; R2-2102238, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, 21 January 2021 (2021-01-21), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP052170900 *

Also Published As

Publication number Publication date
JPWO2022210546A1 (ja) 2022-10-06
US20240032129A1 (en) 2024-01-25

Similar Documents

Publication Publication Date Title
US10321359B2 (en) Controlling data offload in response to feedback information
US20210185755A1 (en) Method and apparatus for discarding buffered data while keeping connection in cp-up separation
WO2015027719A1 (zh) 一种协作多流传输数据的方法及基站
JP7291763B2 (ja) 通信制御方法
US20230180327A1 (en) Communication control method
JP2024079777A (ja) 通信制御方法
US20240032129A1 (en) Communication control method
US20230328607A1 (en) Communication control method
US20230080014A1 (en) Communication control method
WO2022030575A1 (ja) 通信制御方法
JP7397221B2 (ja) 通信制御方法、中継ノード及びプロセッサ
WO2022149470A1 (ja) 通信制御方法
WO2023068254A1 (ja) 通信制御方法及び中継ノード
JP7506271B2 (ja) 通信制御方法及び中継ノード
US20240179543A1 (en) Communication control method
WO2022234846A1 (ja) 通信制御方法
WO2023068258A1 (ja) 通信制御方法
WO2022030517A1 (ja) 通信制御方法
WO2023132285A1 (ja) 通信制御方法
US20240080262A1 (en) Communication method and apparatus
WO2024096052A1 (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: 22780757

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023511267

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: 22780757

Country of ref document: EP

Kind code of ref document: A1