WO2023068258A1 - 通信制御方法 - Google Patents

通信制御方法 Download PDF

Info

Publication number
WO2023068258A1
WO2023068258A1 PCT/JP2022/038728 JP2022038728W WO2023068258A1 WO 2023068258 A1 WO2023068258 A1 WO 2023068258A1 JP 2022038728 W JP2022038728 W JP 2022038728W WO 2023068258 A1 WO2023068258 A1 WO 2023068258A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
notification
routing
iab
indication
Prior art date
Application number
PCT/JP2022/038728
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 JP2023554697A priority Critical patent/JPWO2023068258A5/ja
Publication of WO2023068258A1 publication Critical patent/WO2023068258A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/14—Relay systems
    • H04B7/15—Active relay systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W16/00—Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/24—Cell structures
    • H04W16/26—Cell enhancers or enhancement, e.g. for tunnels, building shadow
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/19—Connection re-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/20—Interfaces between hierarchically similar devices between access points

Definitions

  • the present disclosure relates to a communication control method used in a cellular communication system.
  • IAB Integrated Access and Backhaul nodes
  • a communication control method is a communication control method used in a cellular communication system.
  • the relay node sets a dual connection scheme with a first parent node managing a master cell group as a master node and a second parent node managing a secondary cell group as a secondary node.
  • the relay node has detected a radio link failure on one of a first backhaul link with the first parent node and a second backhaul link with the second parent node. sending a first notification indicating detection of the radio link failure to a child node; and if the relay node recovers from the radio link failure after sending the first notification, the radio link failure. and sending a second notification to the child node indicating recovery from.
  • a relay node is a relay node used in a cellular communication system.
  • the relay node comprises a processor.
  • the processor sets a first parent node that manages a master cell group as a master node and a second parent node that manages a secondary cell group as a secondary node, and performs processing for setting a dual connection method, and the first parent node.
  • a radio link failure is detected on one of the first backhaul link between and the second backhaul link between the second parent node, a second indicating the detection of the radio link failure and transmitting a second notification indicating recovery from the radio link failure to the child node when recovery from the radio link failure has occurred after the transmission of the first notification. Execute the processing to be performed.
  • FIG. 1 is a diagram illustrating 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 illustrating 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 showing an example protocol stack for the F1-U protocol.
  • FIG. 8 is a diagram showing an example protocol stack for the F1-C protocol.
  • FIG. 9 is a diagram showing a configuration example between nodes according to the first embodiment.
  • FIG. 10 is a diagram showing a configuration example between nodes according to the first embodiment.
  • FIG. 11 is a diagram showing an operation example according to the first embodiment.
  • FIG. 12 is a diagram illustrating a configuration example between nodes according to the first embodiment.
  • FIG. 13 is a diagram showing a configuration example between nodes according to the second embodiment.
  • FIG. 14 is a diagram showing an operation example according to the second embodiment.
  • FIG. 15 is a diagram showing an operation example according to the third embodiment.
  • FIG. 16 is a diagram showing an operation example according to the fourth embodiment.
  • FIGS. 10 is a diagram showing a configuration example between nodes according to the first embodiment.
  • FIG. 11 is a diagram showing an operation example according to the first embodiment.
  • FIG. 12 is a diagram illustrating a configuration example between nodes according to the first
  • FIGS. 21A to 21C are diagrams showing configuration examples of topologies according to the seventh embodiment.
  • 22A and 22B are diagrams showing an operation example according to the appendix.
  • 23A and 23B are diagrams showing an operation example according to the appendix.
  • 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
  • 6G future cellular communication systems such as 6G may be applied to the cellular communication system 1 .
  • 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: User Equipment) 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.
  • One cell belongs to one carrier frequency.
  • the terms cell and base station may be used without distinction.
  • 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 200-1 (or donor node, hereinafter sometimes referred to as "donor node") is a network-side NR backhaul termination node and a donor base station with additional functionality to support IAB.
  • 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, a vehicle or a device provided in the vehicle, an aircraft or a device provided in the aircraft.
  • 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 an example of the relationship between the IAB node 300, parent nodes, and child nodes.
  • each IAB node 300 has an IAB-DU corresponding to a base station function unit and an IAB-MT (Mobile Termination) corresponding to a user equipment function unit.
  • IAB-DU corresponding to a base station function 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.
  • 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 230 may perform each process or each operation in the gNB 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 or each operation in the IAB node 300 in each embodiment described below.
  • FIG. 5 is a diagram showing a configuration example of the UE 100. As shown in FIG. As shown in FIG. 5 , UE 100 has radio communication section 110 and control section 120 .
  • the wireless communication unit 110 performs wireless communication on the access link, that is, wireless communication with the gNB 200 and wireless communication with the IAB node 300. Also, the radio communication unit 110 may perform radio communication on the sidelink, that is, radio communication with another UE 100 .
  • the radio communication unit 110 has a receiving unit 111 and a transmitting unit 112 .
  • the receiver 111 performs various types of reception under the control of the controller 120 .
  • Reception section 111 includes an antenna, converts (down-converts) a radio signal received by the antenna into a baseband signal (reception signal), and outputs the baseband signal (reception signal) to control section 120 .
  • the transmitter 112 performs various transmissions under the control of the controller 120 .
  • the transmitter 112 includes an antenna, converts (up-converts) a baseband signal (transmission signal) output from the controller 120 into a radio signal, and transmits the radio signal from the antenna.
  • the control unit 120 performs various controls in the UE 100.
  • Control unit 120 includes at least one memory and at least one processor electrically connected to the memory.
  • the memory stores programs executed by the processor and information used for processing by the processor.
  • a processor may include a baseband processor and a CPU.
  • the baseband processor modulates/demodulates and encodes/decodes the baseband signal.
  • the CPU executes programs stored in the memory to perform various processes.
  • the processor processes each layer, which will be described later.
  • the control unit 120 may perform each process in the UE 100 in each embodiment described below.
  • FIG. 6 is a diagram showing an example of protocol stacks for IAB-MT RRC connection and NAS connection.
  • the IAB-MT of the IAB node 300-2 includes a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, and a PDCP (Packet Data Convergence Protocol) layer, an RRC (Radio Resource Control) layer, and a 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 the IAB-MT of the IAB node 300-2 and the AMF 11.
  • FIG. 7 is a diagram showing a protocol stack for the F1-U protocol.
  • FIG. 8 is a diagram showing 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
  • Traffic prioritization and QoS control are possible by configuring multiple backhaul RLC channels on each BH link.
  • 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 F1-C protocol stack has an F1AP layer and an SCTP layer instead of the GTP-U layer and UDP layer shown in FIG.
  • the processing or operations performed by the IAB's IAB-DU and IAB-MT may be simply described as "IAB" processing or operations.
  • the IAB-DU of the IAB node 300-1 sends a BAP layer message to the IAB-MT of the IAB node 300-2, and the IAB node 300-1 sends the message to the IAB node 300-2.
  • DU or CU processing or operations of donor node 200 may also be described simply as "donor node” processing or operations.
  • upstream direction and the uplink (UL) direction may be used without distinction.
  • downstream direction and the downlink (DL) direction may be used interchangeably.
  • Type 2 BH RLF Indication and Type 3 BH RLF Indication according to the first embodiment will be described.
  • FIG. 9 is a diagram showing a configuration example between nodes according to the first embodiment.
  • the cellular communication system 1 shown in FIG. 9 includes an IAB node 300-T, parent nodes (IAB nodes) 300-P1 and 300-P2, and child nodes (IAB nodes) 300-C.
  • the IAB node 300-P1 is the parent node of the IAB node 300-T.
  • IAB node 300-P1 may be referred to as parent node 300-P1.
  • a backhaul link (BH link) #1 is established between the IAB-DU of the parent node 300-P1 and the IAB-MT of the IAB node 300-T.
  • the parent node 300-P1 may be (the DU#1 of) the donor node 200.
  • the IAB node 300-P2 is also the parent node of the IAB node 300-T.
  • IAB node 300-P2 may be referred to as parent node 300-P2.
  • a BH link #2 is also established between the IAB-DU of the parent node 300-P2 and the IAB-MT of the IAB node 300-T.
  • the parent node 300-P2 may be (the DU#2 of) the donor node 200.
  • the IAB node 300-C is a child node of the IAB node 300-T.
  • the IAB node 300-C may be referred to as a child node 300-C.
  • a BH link #3 is also established between the IAB-MT of the child node 300-C and the IAB-DU of the IAB node 300-T.
  • BH RLF Radio Link Failure
  • the IAB-DU of the IAB node 300-T can send a Type 1 BH RLF Indication (hereinafter sometimes referred to as "Type 1 Indication") to the child node 300-C on the downstream side.
  • Type 1 Indication is an example of a failure notification indicating that BH RLF has been detected.
  • Type 2 Indication is an example of a recovery attempt notification (or failure occurrence notification) indicating that recovery from BH RLF is being attempted.
  • Type 1/2 Indication BH RLF Indication
  • Type 1/2 Indication is also an example of failure notification.
  • Type 1 Indication may be read as Type 2 Indication.
  • Type 1 Indication is sent at the time of BH RLF detection, and Type 2 Indication is sent at the time of recovery attempt.
  • the IAB-MT of the IAB node 300-T performs recovery trial processing of the BH RLF immediately after the BH RLF is issued. Therefore, two Indications can be regarded as substantially the same Indication.
  • Type 3 Indication may be a recovery notification indicating that the BH link has recovered from the BH RLF.
  • Type 4 Indication is also a failure notification indicating that the BH link has failed to recover from the BH RLF.
  • FIG. 9 shows an example in which the IAB node 300-T transmits a Type 2 Indication to the child node 300-C.
  • Type BH RLF Indications may be included in the BAP Control PDU or MAC CE and transmitted.
  • IAB node 300-T can utilize resources provided by two different parent nodes 300-P1 and 300-P2.
  • One parent node can be a master node (MN) that manages a master cell group (hereinafter sometimes referred to as "MCG”).
  • MCG master cell group
  • SCG secondary cell group
  • a MCG is a cell group of serving cells associated with a master node.
  • the MCG comprises a primary cell (Sp-Cell or P-Cell) and optionally one or more secondary cells (S-Cells).
  • a SCG is a group of serving cells associated with a secondary node.
  • the SCG comprises a primary cell (Sp-Cell or PS-Cell) and optionally one or more secondary cells (S-Cells).
  • the Sp cell is the primary cell in the MCG and also the primary cell in the SCG.
  • the master node and secondary nodes are logical entities.
  • the following description assumes that the master node corresponds to the parent node 300-P1 and the secondary node corresponds to the parent node 300-P2.
  • the IAB node 300-T can connect to the secondary node by managing the SCG while connecting to the master node that manages the MCG.
  • the IAB node 300-T simultaneously connects to each parent node 300-P1 and 300-P2 to perform wireless communication. As a result, the throughput of the IAB node 300-T can be improved.
  • EN-DC (E-UTRA (Evolved Universal Terrestrial Radio Access)-NR Dual Connectivity)
  • E-UTRA Evolved Universal Terrestrial Radio Access
  • NR Dual Connectivity EN-DC
  • the IAB node 300-T is connected with one eNB (evolved Node B) functioning as a master node and connected with one en-gNB functioning as a secondary node.
  • An eNB is an LTE base station that provides E-UTRA services.
  • en-gNB is an NR base station that provides NR service.
  • NR base station that provides NR service.
  • the parent node 300-P1 that is the master node can be the eNB, and the parent node 300-P2 that is the secondary node can be the en-gNB.
  • MCG performs processing related to control (C-Plane).
  • SCG processes data (U-Plane).
  • NR-DC NR-NR Dual Connectivity
  • MCG and SCG are capable of handling control and data. So, for example, IAB node 300-T can simultaneously transmit data to and receive data from parent nodes 300-P1 and 300-P2, both of which are gNBs.
  • Type 2 Indication is generated (or transmitted) when BH RLF (hereinafter sometimes referred to as “RLF”) is detected in case of single connection.
  • RLF BH RLF
  • FIG. 9 shows an example of the former case
  • FIG. 10 shows an example of the latter case.
  • the child node 300-C that received the Type 2 Indication does not know whether the RLF is occurring on the MCG side or the SCG side just by receiving the Type 2 Indication. Sometimes.
  • the IAB node 300-T can add additional information to the Type 2 Indication and transmit it.
  • the child node 300-C that has received the additional information can perform routing processing or rerouting processing based on the additional information.
  • RLF may occur (simultaneously) on both the MCG side and the SCG side.
  • the child node 300-C receives the Type 2 Indication corresponding to the RLF generated on the MCG side and the Type 2 Indication corresponding to the RLF generated on the SCG side.
  • the IAB node 300-T transmits Type 3 Indication to the child node 300-C.
  • the IAB node 300-T adds additional information to the Type 3 Indication and transmits it to the child node 300-C.
  • the relay node uses the first parent node (eg, parent node 300-P1) that manages the master cell group as the master node, and the secondary cell group as the master node.
  • a dual connection scheme is set with a second parent node to manage (eg, parent node 300-P2) as a secondary node.
  • the relay node has a first backhaul link (eg, BH link #1) with the first parent node and a second backhaul link (eg, BH link #1) with the second parent node.
  • a second notification (eg, Type 3 Indication) indicating recovery from a radio link failure that occurred in at least one of them is transmitted to the child node (eg, child node 300-C).
  • the second notification includes second additional information, and the second additional information indicates at least the second routing ID that has become available.
  • the child node 300-C can perform appropriate processing based on the routing ID that has become available, such as returning to normal routing operation when local rerouting has been performed. .
  • a routing ID is composed of a destination BAP address (Destination) and a path identifier (Path ID).
  • FIG. 11 is a diagram showing an operation example according to the first embodiment.
  • step S10 the IAB node 300-T starts processing.
  • DC is set for the IAB node 300-T after step S10 and before step S11. That is, in the IAB node 300-T, a DC is set with the parent node 300-P1 that manages the MCG as the master node and the parent node 300-P2 that manages the SCG as the secondary node.
  • the IAB node 300-T detects the RLF (or detects that it is being restored from the RLF).
  • the RLF may be BH link #1 on the MCG side or BH link #2 on the SCG side. Also, RLF may occur simultaneously in BH link #1 on the MCG side and BH link #2 on the SCG side.
  • the IAB-MT of the IAB node 300-T may detect the RLF on a RLF by RLF basis, whether the RLF occurs on each BH link at the same time or separately.
  • the IAB node 300-T transmits a Type 2 Indication to the child node 300-C.
  • the IAB node 300-T independently transmits Type 2 Indication for each detected RLF. For example, when the IAB node 300-T detects an RLF generated on the BH link #1 on the MCG side, it transmits a Type 2 Indication corresponding to the RLF, and when it detects an RLF generated on the BH link #2 on the SCG side, Send a Type 2 Indication corresponding to the relevant RLF.
  • the IAB node 300-T adds additional information to the Type 2 Indication and transmits it.
  • the additional information may be information about routes affected by the RLF.
  • the additional information includes unusable CG (for example, information indicating whether MCG is unusable or SCG is unusable), unusable routing ID, and unusable link quality. At least one may be included. Furthermore, the additional information may include an unusable BH RLC channel ID (BH RLC channel ID). By receiving an unusable BH RLC channel ID, the child node 300-C can stop transmission to that BH RLC channel or perform routing to other BH RLC channels. .
  • unusable CG for example, information indicating whether MCG is unusable or SCG is unusable
  • unusable routing ID for example, information indicating whether MCG is unusable or SCG is unusable
  • unusable link quality At least one may be included.
  • the additional information may include an unusable BH RLC channel ID (BH RLC channel ID).
  • Child node 300-C will be described below assuming that upon receiving a Type 2 Indication containing additional information, local rerouting to another parent node is performed. Local rerouting is, for example, switching transmission from one parent node to another parent node on an alternate path.
  • child node 300-C is routed from IAB node 300-T (the parent node for child node 300-C) to another IAB node (another parent node for child node 300-C) on an alternate path. Toggle sending to.
  • the IAB node 300-T detects recovery of the RLF occurring in the BH link.
  • the IAB node 300-T independently detects recovery from RLF on the MCG side and recovery from RLF on the SCG side.
  • step S14 the IAB node 300-T transmits Type 3 Indication to the child node 300-C.
  • the IAB node 300-T detects recovery from the RLF on the MCG side, it transmits a Type 3 Indication corresponding to the recovery, and upon detecting recovery from the RLF on the RCG side, it transmits a Type 3 Indication corresponding to the recovery. .
  • FIG. 12 is a diagram showing a configuration example between nodes according to the first embodiment. As shown in FIG. 12, the IAB node 300-T transmits Type 3 Indication to the child node 300-C.
  • the IAB node 300-T adds additional information to the Type 3 Indication and transmits it.
  • the additional information may be information on routes affected by the restoration.
  • the additional information includes the CG that has become available (for example, information indicating whether the MCG or SCG has become available), the routing ID that has become available, and the link that can be used. Includes quality (for example, update of available throughput) and/or BH RLC channel IDs that have become available.
  • step S15 in response to receiving the Type 3 Indication, the child node 300-C stops the local rerouting operation and performs normal routing operation according to the additional information. For example, child node 300-C stops local rerouting for routing IDs that become available. Further, for example, it is assumed that the child node 300-C has received routing ID #1 that has become available as additional information, and has performed local rerouting for routing ID #2. In this case, routing ID #2 is still a disabled routing ID. Child node 300-C will continue local rerouting for routing ID #2.
  • the child node 300-C that has received the additional information can grasp the information of the route affected by the restoration, and can control communication according to the additional information.
  • step S16 the child node 300-C ends the series of processes.
  • the IAB node 300-T transmits Type 3 Indication including additional information to the child node 300-C.
  • the IAB node 300-T may transmit a Type 3 Indication that does not contain additional information.
  • child node 300-C may determine that all routing IDs of the BH links associated with that Type3 Indication are now available.
  • inter-donor DU rerouting may occur.
  • the inter-donor rerouting is, for example, rerouting in which the route is switched from the first DU of the donor node 200 to the second DU of the donor node 200 .
  • FIG. 13 is a diagram showing a configuration example between nodes according to the second embodiment.
  • FIG. 13 represents an example of inter-donor rerouting.
  • DU #1 of donor node 200 (hereinafter, “donor DU #1”) (200D1) is transferred to DU #2 of donor node 200 (hereinafter, “donor DU #2”). (200D2).
  • the destination of packets in the upstream direction is changed from the BAP address of donor DU#1 to the BAP address of donor DU#2.
  • FIG. 13 shows an example in which DC settings are performed in the IAB node 300-T and the parent nodes 300-P1 and 300-P2.
  • the IAB node 300-T detects RLF on the BH link on the MCG side or the BH link on the SCG side, it can transmit a Type 2 Indication including additional information.
  • the IAB node 300-T detects the RLF on the BH link on the MCG side, as the additional information, all the destinations (Destination: BAP address of donor DU # 1) linked to the MCG side A routing ID may also be sent.
  • the IAB node 300-T detects RLF on the BH link on the SCG side, as the additional information, the IAB node 300-T has a destination (Destination: BAP address of donor DU#2 (200D2)) linked to the SCG side. All routing IDs may be sent.
  • the IAB node 300-T transmits all the routing IDs associated with the destination as additional information, the additional information overhead is large.
  • the IAB node 300-T transmits the disabled destination BAP address to the child node 300-C as additional information of Type 2 Indication.
  • a relay node for example, the IAB node 300-T
  • a parent node for example, the parent node 300-P1
  • the relay node sends a first notification to the child node (eg, child node 300-C) indicating that it is attempting to recover from the radio link failure.
  • the first notification includes additional information, and the additional information includes the destination BAP address.
  • the IAB node 300-T can reduce the size of the additional information added to the Type 2 Indication and suppress the overhead of the additional information.
  • FIG. 14 is a diagram showing an operation example according to the second embodiment.
  • the IAB node 300-T starts processing in step S20.
  • the IAB node 300-T detects the RLF (or detects that it is being restored from the RLF).
  • the IAB node 300-T identifies routable routing IDs and non-routable routing IDs. Specifically, for example, it is as follows.
  • a single connection is a form in which the IAB node 300-T does not have an alternative path and is connected only to one parent node 300-P.
  • all routing IDs are non-routable routing IDs because there is no alternate path. In this case there is no routable routing ID. Therefore, in the case of a single connection, all routing IDs can be non-routable routing IDs.
  • the second is the case of DC connection.
  • an IAB node 300-T is simultaneously connected to two parent nodes 300-P1 and 300-P2. It should be noted that when the DC connection is made, the DC setting is made for the IAB node 300-T between steps S20 and S21.
  • routing or rerouting may be done by an intra-donor-DU ("Intra-donor-DU").
  • the intra-donor DU has the same destination and multiple routes.
  • intra-donor DU although RLF is detected, some routing IDs cannot be used because there are alternative paths, but other routing IDs can be used.
  • inter-donor-DU In the case of DC connections, routing or rerouting may occur between donor DUs ("Inter-donor-DU").
  • the inter-donor DU is, for example, a form in which routing or rerouting is performed between DUs of different donor nodes, as shown in FIG.
  • the Destination for example, the BAP address of donor DU#1 (200D1)
  • the Destination upstream of the BH link on which the RLF is occurring becomes routable. Therefore, all routing IDs with this Destination are disabled.
  • BAP address of donor DU #2 (200D2) upstream of another BH link, since RLF is not detected on the route, all routing IDs having this Destination are available.
  • step S23 the IAB node 300-T confirms the destination of the routing ID that cannot be routed.
  • the IAB node 300-T checks whether a destination with a non-routable routing ID exists in a destination with a routable routing ID.
  • the IAB node 300-T adds the destination of the routing ID that is not routable to the additional information of Type 2 Indication include in
  • the additional information includes the destination of the routing ID that cannot be routed.
  • the destination of the unroutable routing ID (BAP address of donor DU#1 (200D1)) and the destination of the routable routing ID (donor DU#2 (200D2)) is a different destination. Therefore, it applies when the destination of the unroutable routing ID (BAP address of donor DU#1 (200D1)) does not exist in the destination of the routable routing ID (BAP address of donor DU#2 (200D2)). do. Therefore, in this case, the destination (BAP address of donor DU #1 (200D1)) of the routing ID that cannot be routed is included in the additional information.
  • the IAB node 300-T includes a list of routing IDs that are not routable in the additional information when the destination of the routing ID that is not routable exists in the destination of the routing ID that is routable.
  • the IAB node 300-T includes in the additional information a list of routing IDs for which routing IDs are not possible.
  • step S24 the IAB node 300-T transmits Type 2 Indication including the additional information to the child node 300-C.
  • step S25 the child node 300-T determines that all routing IDs having the Destination are unusable in response to receiving the Type 2 Indication. Since the additional information includes a destination that cannot be routed, the child node 300-T determines that the routing ID including the destination is an unusable routing ID.
  • step S26 the child node 300-T ends the series of processes.
  • the IAB node 300-T can prevent transmission of Type 2 Indication to the child node 300-C even if RLF occurs on the MCG side. This is because the IAB node 300-T can use the SCG to transfer data to the parent node 300-P2.
  • the IAB node 300-T it may be complicated to determine the type of DC and whether the SCG or MCG is processing data. If the IAB node 300-T can transmit or not transmit the Type 2 Indication without judging the type of DC, it will be possible to perform processing easily.
  • the Type 2 Indication is not transmitted unless a route that cannot be used by RLF exists in the routing table and/or the mapping table. Also, in the third embodiment, an example will be described in which a Type 2 Indication is sent if an unusable route exists in the routing table and/or the mapping table.
  • the relay node manages the first parent node (eg, parent node 300-P1) that manages the master cell group as the master node and the secondary cell group.
  • a dual connection scheme is set with a second parent node (for example, parent node 300-P2) as a secondary node.
  • the relay node detects a radio link failure that has occurred in at least one of the first backhaul link with the first parent node and the second backhaul link with the second parent node. do.
  • the relay node indicates that it is attempting to recover from a radio link failure if there is first route information in the routing table and/or mapping table indicating an unusable route due to the radio link failure.
  • the first notification (eg, Type 2 Indication) is sent to the child node (eg, child node 300-C) and the first route information does not exist in the routing table and/or the mapping table, the first notification is sent to the child node do not send.
  • the IAB node 300-T can transmit the Type 2 Indication with reduced complicated processing.
  • FIG. 15 is a diagram showing an operation example according to the third embodiment.
  • the IAB node 300-T starts processing in step S30.
  • IAB node 300-T performs DC setting between steps S30 and S31, as in the first embodiment.
  • IAB node 300-T is capable of wireless communication simultaneously with parent nodes 300-P1 and 300-P2.
  • step S31 the IAB-MT of the IAB node 300-T detects RLF.
  • the IAB node 300-T may continue to perform RRC re-establishment procedures, MCG Failure Information procedures, and SCG Failure Information procedures.
  • step S32 the RRC layer of the IAB-MT of the IAB node 300-T transmits the first information indicating that the RLF has been detected (or that the BH link is being restored) to the IAB node 300-T. Output to the BAP layer of the IAB-DU.
  • the RRC layer may output the first information to the BAP layer of the IAB-DU of the IAB node 300-T via the F1AP layer of the IAB-DU of the IAB node 300-T.
  • the first information may include information indicating on which link the RLF occurred. Specifically, the first information may include information indicating whether RLF has occurred in the MCG or whether the RLF has occurred in the MCG. Also, the first information may include an outflow BH link ID (egress BH link ID) that designates the BH link in which the RLF occurs as an outflow BH link. Further, the first information may include the Next hop BAP address of the IAB node 300-T on the BH link where the RLF occurred. The first information may include at least one of information indicating MCG or SCG, outgoing BH link ID, and next hop BAP address.
  • outflow BH link ID egress BH link ID
  • step S33 the BAP layer confirms whether or not there is an unusable route in response to the input of the first information. Specifically, the BAP layer determines whether route information corresponding to (or including the first information) exists in the routing configuration (or routing table) and/or the mapping configuration (or mapping table). to confirm.
  • the confirmation for the routing table is as follows.
  • the BAP layer confirms whether or not the route information (here, routing ID and/or outflow BH link) corresponding to the first information exists in the routing table.
  • the confirmation for the mapping table is, for example, as follows.
  • the BAP layer confirms whether or not the route information (here, egress BH RLC channel) corresponding to the first information exists in the mapping table.
  • step S34 if an unusable route exists in the routing table and/or mapping table (YES in step S34), the BAP layer performs the processing of step S35. On the other hand, in step S34, the BAP layer performs the process of step S38 if no usable route exists in the routing table and/or mapping table (NO in step S34).
  • a case where an unusable route exists is a case where route information corresponding to the first information exists in the routing table and/or the mapping table. For example, if the RLF occurs on the MCG side, the route information on the MCG side exists in the routing table and/or the mapping table. In such a case, the BAP layer performs steps S35 and S36.
  • a case where there is no unusable route is a case where the route information corresponding to the first information does not exist in the routing table and/or the mapping table.
  • the BAP layer does not transmit Type 2 Indication even if it receives the first information from the RRC layer.
  • the BAP layer can prevent Type 2 Indication from being sent. Become. Therefore, the BAP layer performs the process of step S38.
  • step S35 the BAP layer identifies unusable routes.
  • the BAP layer identifies unusable routes so that lower nodes (for example, child node 300-C) can grasp them. That is, when the BAP layer determines steps S33 and S34 using the routing ID as route information (when the routing ID corresponds to an unusable route), the routing ID is used as it is to It may be identified as a possible route. In addition, when the BAP layer determines steps S33 and S34 using an outflow BH link as route information (when the outflow BH link corresponds to an unusable route), the inflow BH link corresponding to the outflow BH link is determined. An ingress BH link may be identified as an unusable route.
  • the BAP layer determines steps S33 and S34 using the outflow BH RLC channel as route information (when the outflow BH RLC channel corresponds to an unusable route)
  • the outflow BH RLC channel A corresponding ingress BH RLC channel may be identified as an unusable route.
  • the BAP layer transmits Type 2 Indication.
  • the BAP layer may transmit the Type 2 Indication only to the child node 300-C connected to the route identified in step S35.
  • the BAP layer may transmit the Type 2 Indication only to the child node 300-C connected to the incoming BH link identified as an unusable route. In this case, the BAP layer does not need to send Type 2 Indication to child nodes that are not connected to the specified incoming BH link.
  • Type 2 Indication may include an unusable route as additional information.
  • An unusable route may be an unusable routing ID or the like.
  • step S37 the IAB node 300-T ends the series of processes.
  • step S38 the BAP layer does not transmit Type 2 Indication.
  • step S38 the IAB node 300-T ends the series of processes.
  • 3rd Embodiment demonstrated the example which a BAP layer processes step S35 from step S33.
  • the F1AP layer of the IAB-DU of the IAB node 300-T may perform the processing from step S33 to step S35.
  • the operation in this case is, for example, as follows.
  • step S32 the IAB-DU RRC layer of the IAB node 300-T outputs the first information to the F1AP layer.
  • the F1AP layer may perform similar processing.
  • the F1AP layer outputs the unusable route identified in step S35 to the IAB-DU BAP layer of the IAB node 300-T.
  • the BAP layer may perform the processing after step S36.
  • the relay node detects that it has recovered from the radio link failure. Secondly, the relay node has recovered from the radio link failure if there is second route information in the routing table and/or the mapping table indicating a route that can be used due to the recovery from the radio link failure. to the child node (eg, child node 300-C), and if the second route information does not exist in the routing table and/or the mapping table, the second notification is sent to the child node Do not send to
  • FIG. 16 is a diagram showing an operation example according to the fourth embodiment.
  • step S40 the IAB node 300-T starts processing.
  • IAB node 300-T performs DC setting between steps S40 and S41, as in the third embodiment.
  • IAB node 300-T is capable of wireless communication simultaneously with parent nodes 300-P1 and 300-P2.
  • step S41 the IAB-MT of the IAB node 300-T detects RLF.
  • step S42 the RRC layer of the IAB-MT of the IAB node 300-T outputs the second information indicating recovery from the RLF to the BAP layer of the IAB-DU of the IAB node 300-T.
  • the second information may include information indicating which link's RLF has recovered. Specifically, the second information may include information indicating whether the recovery was made with the MCG or whether the recovery was made with the MCG. Also, the second information may include an outflow BH link ID (egress BH link ID) that designates the recovered BH link as an outflow BH link. Additionally, the second information may include the Next hop BAP address of the IAB node 300-T on the restored BH link. The second information may include at least one of information indicating MCG or SCG, outflow BH link ID, and next hop BAP address.
  • step S43 the BAP layer confirms whether or not there is a usable route in response to the input of the second information. Specifically, the BAP layer determines whether route information corresponding to (or including) the second information exists in the routing configuration (or routing table) and/or the mapping configuration (or mapping table). to confirm.
  • the confirmation for the routing table is as follows.
  • the BAP layer checks whether route information (here, routing ID and/or outflow BH link) corresponding to (or including) the second information exists in the routing table.
  • route information here, routing ID and/or outflow BH link
  • the confirmation for the mapping table is, for example, as follows.
  • the BAP layer checks whether the route information (here, egress BH RLC channel) corresponding to (or including) the second information exists in the mapping table. do.
  • step S44 if the available route exists in the routing table and/or mapping table (YES in step S44), the BAP layer performs the processing of step S45. On the other hand, in step S44, if the available route does not exist in the routing table and/or the mapping table (NO in step S44), the BAP layer performs the processing of step S48.
  • a case where a usable route exists is a case where route information corresponding to the second information exists in the routing table and/or the mapping table. For example, if recovery from RLF occurs on the MCG side, the route information on the MCG side is present in the routing table and/or the mapping table. In such a case, the BAP layer performs steps S45 and S46.
  • the route information corresponding to the second information does not exist in the routing table and/or mapping table.
  • the route information on the MCG side does not exist in the routing table and/or the mapping table.
  • the BAP layer does not transmit Type 3 Indication even if it receives the second information from the RRC layer. Therefore, the BAP layer performs the process of step S48.
  • the BAP layer identifies unusable routes.
  • the BAP layer identifies routes that have become available so that lower nodes (eg, child node 300-C) can see them. That is, the BAP layer can identify the routing ID, ingress BH link, or ingress BH RLC channel as a route that has become available, as in the third embodiment. good.
  • the BAP layer transmits Type 2 Indication.
  • the BAP layer may transmit the Type 3 Indication only to the child node 300-C connected to the route identified in step S45.
  • the BAP layer may transmit Type 3 Indication only to the child node 300-C connected to the specified incoming BH link. In this case, the BAP layer does not need to send Type 2 Indication to child nodes that are not connected to the specified incoming BH link.
  • Type 3 Indication may include the available route as additional information.
  • the routes that have become available include routing IDs that have become available.
  • step S47 the IAB node 300-T ends the series of processes.
  • step S48 if there is no unusable route (NO in step S44), the BAP layer does not transmit Type 3 Indication.
  • step S48 the IAB node 300-T ends the series of processes.
  • the processing from step S43 to step S45 may be performed by the IAB-DU F1AP layer of the IAB node 300-T. That is, steps S43 to S45 may be performed by the F1AP layer instead of the BAP layer.
  • the F1AP layer outputs the route information identified in step S45 to the IAB-DU BAP layer of the IAB node 300-T. Then, the BAP layer may perform the processing after step S46.
  • the IAB node 300-T may transmit a Type 2 Indication including an unusable routing ID to the child node 300-C. Further, in the fourth embodiment, it was explained that the IAB node 300-T may transmit the Type 2 Indication including the available routing ID to the child node 300-C.
  • the specific operations in the BAP layer when the child node 300-C receives a Type 2 Indication containing an unusable routing ID and a Type 3 Indication containing a usable routing ID An example will be described.
  • the relay node eg, IAB node 300-T
  • a first notification eg, Type 2 Indication
  • the relay node sends a first notification (eg, Type 2 Indication) indicating that it is attempting recovery from a radio link failure to a child node ( For example, it is transmitted to the child node 300-C).
  • a first notification eg, Type 2 Indication
  • the child node performs a first routing process assuming that the first routing ID does not exist in the routing table.
  • a second indication e.g., Type 3 Indication
  • the child node uses the entry in the routing table that includes the second routing ID to perform the second Perform routing processing.
  • FIGS. 17A and 17B are diagrams showing configuration examples between nodes according to the fifth embodiment.
  • FIG. 18 is a diagram showing an operation example according to the fifth embodiment. The operation example shown in FIG. 18 will be described with appropriate reference to the configuration examples shown in FIGS. 17A and 17B.
  • the child node 300-C starts processing in step S50.
  • step S51 the BAP layer of child node 300-C receives Type 2 Indication from parent node 300-P1.
  • FIG. 17(A) shows an example in which the child node 300-C receives the Type 2 Indication.
  • the Type 2 Indication contains, as additional information, a routing ID that has become unroutable due to RLF.
  • the BAP layer of the child node 300-C performs routing processing assuming that the entry does not exist in the routing table. That is, the BAP layer assumes that the entry containing the routing ID included in the Type 2 Indication does not exist in the routing table (or is an unusable entry), and performs routing processing. In this case, since the BAP entry does not exist in the routing table, a search is made for an entry in the routing table that matches the destination of the routing ID, and local rerouting is performed to the routing ID of the entry.
  • the first routing process for example, corresponds to such local rerouting process.
  • FIG. 17A shows an example in which the child node 300-C switches the route to the parent node 300-P2 by the local rerouting process.
  • the child node 300-C receives Type 3 Indication from the parent node 300-P1.
  • FIG. 17B shows an example in which the child node 300-C receives the Type 3 Indication.
  • the Type 3 Indication contains, as additional information, a routing ID that has become routable due to recovery from the RLF.
  • step S54 the child node 300-C searches the routing table for an entry corresponding to the routing ID. conduct. That is, the child node 300-C stops the local rerouting process and performs the normal routing process because the entry exists in the routing table.
  • FIG. 17B shows an example in which the child node 300-C switches the route from the parent node 300-P2 to the parent node 300-P1.
  • step S55 the child node 300-C ends the series of processes.
  • FIG. 19 is a diagram showing a configuration example between nodes according to the sixth embodiment.
  • the child node 300-C receives a Type 2 Indication from the parent node 300-P, as shown in FIG. In this case, if the child node 300-C fails to receive the Type 3 Indication or the Type 4 Indication from the parent node 300-P after that, the child node 300-C does not know what kind of processing should be performed. There is also
  • the parent node 300-P was unable to send Type 3 Indication and Type 4 Indication for some reason. Also, even if the parent node 300-P transmits Type 3 Indication and Type 4 Indication, the child node 300-C may not receive them for some reason.
  • the child node 300-C starts counting a timer when it receives a Type 2 Indication, and when the count value reaches a predetermined value, BH link restoration processing is started.
  • a relay node receives a timer value setting from a donor node (eg donor node 200).
  • a first notification e.g., Type 2 Indication.
  • the relay node starts counting with a timer upon receiving the first notification.
  • a second notification for example, Type 3 Indication
  • a third notification for example, Type 4 Indication
  • FIG. 20 is a diagram showing an operation example according to the sixth embodiment.
  • the child node 300-C starts processing in step S60.
  • the child node 300-C receives the setting of the timer value from the donor node 200 or the parent node 300-P.
  • Child node 300-C may receive the setting of the timer value from donor node 200 using an RRC message or an F1AP message.
  • the child node 300-C may receive the setting of the timer value from the parent node 300-P using the BAP Control PDU.
  • the child node 300-C receives the Type 2 Indication from the parent node 300-P.
  • the child node 300-C starts counting the timer in response to receiving the Type 2 Indication.
  • step S63 the child node 300-C determines whether it has received a Type 3 Indication or a Type 4 Indication from the parent node 300-P.
  • the child node 300-C receives the Type 3 Indication or the Type 4 Indication from the parent node 300-P (YES in step S63)
  • it performs the process of step S64.
  • the child node 300-C does not receive the Type 3 Indication or the Type 4 Indication from the parent node 300-P (NO in step S63)
  • step S64 the child node 300-C stops counting the timer.
  • step S65 the child node 300-C ends the series of processes.
  • step S66 the child node 300-C determines whether the count value of the timer has reached the timer value (whether the timer has expired). When the count value of the timer reaches the timer value (YES in step S66), the child node 300-C performs the process of step S67. On the other hand, if the count value of the timer has not reached the timer value (NO in step S66), the child node 300-C proceeds to step S63 and repeats the above-described processing.
  • step S67 the child node 300-C performs restoration processing.
  • the recovery process may be an RLF declaration.
  • the child node 300-C may declare the RLF generated in the BH link of the parent node 300-P.
  • the recovery process may be execution of an RRC re-establishment procedure.
  • child node 300-C may initiate an RRC re-establishment procedure towards parent node 300-P.
  • the recovery process may be the execution of the MCG Failure Information procedure or the SCG Failure Information procedure according to the additional information included in the Type 2 Indication. For example, if the additional information includes information indicating RLF on the MCG side, the child node 300-C executes the MCG failure information procedure, and if the additional information includes information indicating RLF on the SCG side , may perform the SCG failure information procedure.
  • step S65 the child node 300-C ends the series of processes.
  • 3GPP is studying how to perform rerouting in a network (or topology) formed by multiple IAB nodes 300 .
  • routing is, for example, controlling to which IAB node 300 the received packet is transferred.
  • FIG. 21A shows a topology configuration example in the “Inside CU/Inside Donor DU” scenario.
  • Rerouting (S1-2) in this scenario is so-called local rerouting.
  • the IAB node 300-1 detects the BH RLF for the IAB node 300-2, it performs rerouting by switching to a route via the IAB node 300-3, which is an alternative path, for packets in the uplink direction.
  • FIG. 21B is a diagram showing a configuration example of the topology in the “Intra-CU/Between Donor-DU” scenario.
  • the donor DU that is the destination of the packet is changed from donor DU#1 (200D1) to donor DU#2 (200D2). That is, the destination BAP address of the packet is changed. Therefore, 3GPP has agreed to rewrite the BAP header in this scenario. Rewriting the BAP header is to rewrite the BAP header from the previous routing ID to the new routing ID.
  • FIG. 21C is a diagram showing a configuration example of the topology in the “Between CUs” scenario.
  • donor CU#1 200C1
  • donor CU#2 200C2
  • a donor DU#1 200D1
  • a donor DU#2 200D2
  • a donor CU#2 200C2
  • a topology formed by a route from donor CU#1 (200C1) to IAB node 300-1 and a topology formed by a route from donor CU#2 (200C2) to IAB node 300-1 It can be a topology different from the topology (second topology).
  • IAB node 300-1 is located at the boundary of two different topologies. Such an IAB node 300-1 may be called a boundary IAB node.
  • the border IAB node 300-1 can forward packets destined for donor DU#1 (200D1) via the topological alternative path in donor CU#2 (200C2). .
  • the border IAB node 300-1 maintains the F1 connection with donor CU#1 (200C1), which is the source donor node, while maintaining donor CU#2, which is the target donor node. It was agreed that it may be applied in the RRC Re-establishment state for (200C2).
  • IAB node 300-4 and IAB node 300-5 receive Type 2 Indication from IAB node 300-1.
  • Type 2 Indication includes the additional information described in the first embodiment.
  • the IAB node 300-4 and the IAB node 300-5 receive Type 3 Indication from the IAB node 300-1.
  • Type 3 Indication includes the additional information described in the first embodiment.
  • the IAB node 300-4 receives the Type 2 Indication from the IAB node 300-1.
  • Type 2 Indication includes the additional information described in the first embodiment.
  • the IAB node 300-4 receives Type 3 Indication from the IAB node 300-1.
  • Type 3 Indication includes the additional information described in the first embodiment.
  • IAB node 300-1 detects RLF in the BH link with IAB node 300-2.
  • the IAB node 300-1 confirms the BAP address of the donor DU#1 (200D1) as the destination of the routing ID that cannot be routed.
  • IAB node 300-1 transmits Type 3 Indication including the BAP address to IAB node 300-4.
  • the operation examples, processes, etc. described in the third embodiment are applicable to scenario (S1-2), scenario (S2-2), and scenario (S3-2). That is, for example, when the IAB node 300-1 detects RLF on the BH link with the IAB node 300-2, there must be route information unusable by RLF in the routing table and/or the mapping table. For example, Type 2 Indication is not sent to lower nodes. The IAB node 300-1 transmits a Type 2 Indication to lower nodes if route information that cannot be used by RLF exists in the routing table and/or the mapping table.
  • the operation examples, processes, etc. described in the fourth embodiment are applicable to scenario (S1-2), scenario (S2-2), and scenario (S3-2). That is, for example, when the IAB node 300-1 detects recovery from RLF on the BH link with the IAB node 300-2, the route information made available by the recovery is stored in the routing table and/or the mapping table. , the Type 3 Indication is not sent to the lower node. The IAB node 300-1 transmits a Type 3 Indication to the lower nodes if the route information made available by the restoration exists in the routing table and/or the mapping table.
  • the IAB node 300-4 receives Type 2 Indication from the IAB node 300-1. If the additional information includes a routing ID that has become unusable due to RLF, the IAB node 300-4 performs the first routing processing assuming that the routing table does not have an entry including the routing ID. IAB node 300-4 also receives Type 3 Indication from IAB node 300-1. If the additional information includes a routing ID that has become usable by recovery from the RLF, the IAB node 300-4 uses the entry included in the routing table to perform the second routing process.
  • the operation examples, processes, etc. described in the sixth embodiment are also applicable to scenario (S1-2), scenario (S2-2), and scenario (S3-2). That is, the IAB node 300-4 starts counting the timer when receiving the Type 2 Indication from the IAB node 300-1, and performs recovery processing when the count value reaches the timer value.
  • the IAB node 300 may report the triggering and stopping of local rerouting to the donor node 200.
  • the report may include cause information indicating the cause of the trigger or stop.
  • the cause information may be additional information included in Type 2 Indication (first, second, and fifth embodiments), or additional information included in Type 3 Indication (first embodiment). There may be.
  • the report may include information on routes that have triggered or stopped local rerouting.
  • the route information may be a routing ID or a BH RLC channel ID.
  • the IAB node 300 may send the report to the donor node 200 immediately upon triggering or stopping local rerouting. Alternatively, the IAB node 300 may send the report after the fact. When transmitting after the fact, the IAB node 300 may record (log) the trigger or stop, the cause information, and the route information as the local rerouting is triggered and stopped. The IAB node 300 may transmit the record (log) to the donor node 200 as the report upon request from the donor node 200 .
  • each embodiment, each operation example, each process, or each step described in the first to eighth embodiments can be combined with each other. All or part of each of the first to eighth embodiments can be combined without contradiction. With such a combination, it may be possible to standardize procedures or processes in all scenarios.
  • a program that causes a computer to execute each process performed by the UE 100 or the gNB 200 may be provided.
  • the program may be recorded on a computer readable medium.
  • a computer readable medium allows the installation of the program on the computer.
  • the computer-readable medium on which the program is recorded may be a non-transitory recording medium.
  • the non-transitory recording medium is not particularly limited, but may be, for example, a recording medium such as CD-ROM or DVD-ROM.
  • a circuit that executes each process performed by the UE 100 or gNB 200 may be integrated, and at least part of the UE 100 or gNB 200 may be configured as a semiconductor integrated circuit (chipset, SoC).
  • the terms “based on” and “depending on,” unless expressly stated otherwise, “based only on.” does not mean The phrase “based on” means both “based only on” and “based at least in part on.” Similarly, the phrase “depending on” means both “only depending on” and “at least partially depending on.” Also, “obtain/acquire” may mean obtaining information among stored information, or it may mean obtaining information among information received from other nodes. or it may mean obtaining the information by generating the information.
  • the terms “include,” “comprise,” and variations thereof are not meant to include only the recited items, and may include only the recited items or in addition to the recited items. Means that it may contain further items.
  • references to elements using the "first,” “second,” etc. designations used in this disclosure do not generally limit the quantity or order of those elements. These designations may be used herein as a convenient method of distinguishing between two or more elements. Thus, references to first and second elements do not imply that only two elements may be employed therein, or that the first element must precede the second element in any way.
  • references to first and second elements do not imply that only two elements may be employed therein, or that the first element must precede the second element in any way.
  • RAN2 agreed on trigger conditions for Type 2 Indication as follows.
  • the trigger for generating Type 2 RLF Indication is when RLF is detected. Further consideration is needed for both single-connection and double-connection cases.
  • Type2 Indication In RAN2#113-e, the use case of Type2 Indication from the perspective of child nodes was agreed as follows.
  • RAN2 supports RLF Indication of Type 2/3 (specified operation, impact of TS, details need further study).
  • Type 2 RLF Indication can trigger local rerouting.
  • An RLF Indication of Type 2 can trigger deactivation of IABs supported by SIBs.
  • Type 2 RLF Indication can be used as a trigger to stop or reduce transmission of SR or BSR.
  • a child node may forward upstream packets if the parent node (the IAB node in question) can perform local rerouting, that is, due to dual connections.
  • EN-DC Another EN-DC scenario is also worthy of consideration.
  • the MCG link ie MeNB
  • SCG link ie SgNB
  • the SCG RLF directly affects the child node's packet forwarding
  • the IAB node needs to send a Type 2 Indication to the child node.
  • MCG RLF LTE link
  • the SCG link is still available during the subsequent RRC connection re-establishment procedure, and if re-establishment fails, a Type 4 Indication is sent as in Rel-16. Therefore, Type 2 Indication may not be necessary.
  • a simple solution would be for a Type 2 Indication to be sent when at least one route is unavailable by BH RLF.
  • This solution can cover both single and double connection cases and both NR-DC and EN-DC.
  • BH RLF in single-connection BH RLF, all routes become unusable.
  • EN-DC MCG RLF does not affect any routes and SCG RLF disables all routes.
  • BH RLF may or may not affect some routes, depending on the BH link-to-route mapping. Therefore, RAN2 should agree on this unified operation regarding the trigger conditions for Type 2 Indication. .
  • Proposal 1 RAN2 should send a Type 2 BH RLF Indication when at least one route is unavailable during BH RLF, regardless of whether the IAB node is single-connected or dual-connected (including EN-DC). should agree. .
  • Option A is a simple operation, but the parent node loses either the MCG or SCG link due to BH RLF, so there is a possibility that the parent node will be overloaded.
  • Option B requires the Type 2 Indication to convey additional information, but can distribute the load to the two parent nodes of the child node. Therefore, option B is expected to be effective in improving the performance of the overall topology.
  • the child node can have the option of whether to perform "partial" local rerouting for better load balancing (i.e. option B).
  • Proposal 2 RAN2 should discuss whether to perform "partial" local rerouting on child nodes (ie option B) when a dual-connected parent node experiences BH RLF.
  • partial rerouting i.e. option B
  • the child node must decide which traffic can remain on the original route and which traffic should be subject to local rerouting. So we need to know which routes are not available.
  • the Type 2 Indication contains a routing ID that cannot be used for BH RLF, it is easy to know.
  • a child node that receives a Type 2 Indication considers the routing ID notified by the Type 2 Indication to be unusable, and the BAP layer of the child node executes local rerouting. Therefore, RAN2 should agree on these actions at the concerned node and child nodes.
  • Proposal 3 RAN2 should agree that the Type 2 BH RLF Indication indicates a routing ID that is not available for BH RLF.
  • Proposal 4 RAN2 should agree that if a routing ID is indicated in the received Type 2 BH RLF Indication, the child node considers the routing ID unavailable.
  • Type2 indication is for child nodes to perform local rerouting as RAN2 has agreed.
  • RAN2#114-e as with Rel-16, the child node declares BH RLF according to the instruction of Type4 and finally performs local rerouting, so how Type2 and Type4 work together was discussed. .
  • the provider can set local rerouting when Type 2 is received. This makes sense because the provider controls the purpose of the entire topology and knows the latest performance of the entire topology.
  • Proposal 5 RAN2 should agree whether or not to perform local rerouting upon receipt of a Type 2 BH RLF Indication, donors configure IAB nodes.
  • the provider can be able to set for the relevant IAB node whether or not to send a Type 2 Indication when BH RLF is detected. For example, if the IAB node in question implements Rel-17 functionality and its child nodes only support Rel-16 (a "mixed" deployment), the provider can turn this off.
  • Proposal 6 RAN2 should agree on whether the donor side should send the Type 2 BH RLF Indication to the IAB node when its BH RLF is detected. .
  • Type 3 indication for single connection and double connection In RAN2#114-e, RAN2 agreed on the trigger conditions for Type 3 Indication as follows.
  • Type 3 RLF Indication is normal recovery after BH RLF. Further consideration is required for both single connection and dual connection.
  • Type 3 Indication restores the operation of the child node started by receiving Type 2. Therefore, Type 3 Indication is valid only when the child node receives Type 2 Indication. Since only Type 2 Indication depends on these cases, such conditions for Type 3 Indication are commonly applicable to both single and double connections, eg, Proposal 1 above.
  • Proposal 7 RAN2 should only send Type 3 BH RLF Indication in addition to the agreed action, i.e., when BH RLF recovery is successful, and only when Type 2 BH RLF Indication has been sent. It should be agreed upon as common to connection cases.
  • Type 3 Indication should only be used when at least one route becomes reusable due to successful BH RLF recovery, that is, when the state changes from "unavailable” to “available”. It would be reasonable to send This behavior, like the proposal, can be applied to single-connection and double-connection cases, including NR-DC and EN-DC.
  • Proposal 8 RAN2 should agree that a Type 3 BH RLF Indication will be sent when BH RLF is successfully recovered and at least one route is reusable.
  • proposal 3 it is necessary to notify child nodes of the routing ID that has become reusable. Child nodes consider these routing IDs to be routable and stop local rerouting of the traffic in question.
  • Proposal 9 RAN2 should agree that Type 3 BH RLF Indication indicates a routing ID that has become reusable due to successful BH RLF recovery.
  • Proposal 10 RAN2 should agree to consider the routing ID available to the child node if the routing ID is indicated in the received Type 3 BH RLF Indication.
  • Propagation of Type 2 Indications aims to provide better topology management, such as load balancing and reducing service interruptions.
  • Proposal 11 RAN2 should agree that propagation of Type2 Indication to descendant nodes is supported. Further consideration will be given to detailed conditions such as forwarding only if the IAB node does not perform local rerouting.
  • Type 2 RLF Indication can be used to stop or reduce the transmission of SR or BSR
  • This is considered an IAB-MT behavior and should be clearly defined.
  • deactivation may be simpler in terms of specifications. However, it means that SR and BSR can only be transmitted after receiving Type 3 Indication, which may cause scheduling delays.
  • Reduce on the other hand, may cause unnecessary interference, but may allow scheduling to resume immediately after the BH link recovers. So, it should be discussed whether RAN2 supports SR and/or BSR "deactivation", "reduction”, or both.
  • Proposal 12 RAN2 should agree to stipulate that IAB-MT stop or reduce SR and/or BSR transmissions when it receives a Type 2 BH RLF Indication.
  • Proposal 13 when receiving Type 2 BH RLF Indication, decides whether to support "deactivation”, “reduction”, or both of SR and/or BSR (that is, whether it is configurable) should be discussed.

Landscapes

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

Abstract

第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードが、マスターセルグループを管理する第１親ノードをマスターノードとし、セカンダリセルグループを管理する第２親ノードをセカンダリノードとして、二重接続方式が設定されることと、前記中継ノードが、前記第１親ノードとの間の第１バックホールリンクと、前記第２親ノードとの間の第２バックホールリンクのうちの一方のリンク上に無線リンク障害を検知した場合、前記無線リンク障害の検知を示す第１通知を、子ノードへ送信することと、前記中継ノードが、前記第１通知を送信した後、前記無線リンク障害から回復した場合、前記無線リンク障害から回復したことを示す第２通知を、前記子ノードへ送信することと、を有する。

Description

通信制御方法
　本開示は、セルラ通信システムに用いる通信制御方法に関する。
　セルラ通信システムの標準化プロジェクトである３ＧＰＰ（Third Generation Partnership Project）において、ＩＡＢ（Integrated Access and Backhaul）ノードと呼ばれる新たな中継ノードの導入が検討されている（例えば、「３ＧＰＰ　ＴＳ　３８．３００　Ｖ１６．７．０（２０２１－０９）」参照）。１又は複数の中継ノードが、基地局とユーザ装置との間の通信に介在し、この通信に対する中継を行う。
　第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードが、マスターセルグループを管理する第１親ノードをマスターノードとし、セカンダリセルグループを管理する第２親ノードをセカンダリノードとして、二重接続方式が設定されることと、前記中継ノードが、前記第１親ノードとの間の第１バックホールリンクと、前記第２親ノードとの間の第２バックホールリンクのうちの一方のリンク上に無線リンク障害を検知した場合、前記無線リンク障害の検知を示す第１通知を、子ノードへ送信することと、前記中継ノードが、前記第１通知を送信した後、前記無線リンク障害から回復した場合、前記無線リンク障害から回復したことを示す第２通知を、前記子ノードへ送信することと、を有する。
　第２の態様に係る中継ノードは、セルラ通信システムで用いる中継ノードである。前記中継ノードは、プロセッサを備える。前記プロセッサは、マスターセルグループを管理する第１親ノードをマスターノードとし、セカンダリセルグループを管理する第２親ノードをセカンダリノードとして、二重接続方式が設定される処理と、前記第１親ノードとの間の第１バックホールリンクと、前記第２親ノードとの間の第２バックホールリンクのうちの一方のリンク上に無線リンク障害を検知した場合、前記無線リンク障害の検知を示す第１通知を、子ノードへ送信する処理と、前記第１通知を送信した後、前記無線リンク障害から回復した場合、前記無線リンク障害から回復したことを示す第２通知を、前記子ノードへ送信する処理と、を実行する。
図１は、一実施形態に係るセルラ通信システムの構成例を示す図である。 図２は、ＩＡＢノードと親ノード（Ｐａｒｅｎｔ　ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ　ｎｏｄｅｓ）との関係を示す図である。 図３は、一実施形態に係るｇＮＢ（基地局）の構成例を示す図である。 図４は、一実施形態に係るＩＡＢノード（中継ノード）の構成例を示す図である。 図５は、一実施形態に係るＵＥ（ユーザ装置）の構成例を示す図である。 図６は、ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックの例を示す図である。 図７は、Ｆ１－Ｕプロトコルに関するプロトコルスタックの例を示す図である。 図８は、Ｆ１－Ｃプロトコルに関するプロトコルスタックの例を示す図である。 図９は、第１実施形態に係るノード間の構成例を表す図である。 図１０は、第１実施形態に係るノード間の構成例を表す図である。 図１１は、第１実施形態に係る動作例を表す図である。 図１２は、第１実施形態に係るノード間の構成例を表す図である。 図１３は、第２実施形態に係るノード間の構成例を表す図である。 図１４は、第２実施形態に係る動作例を表す図である。 図１５は、第３実施形態に係る動作例を表す図である。 図１６は、第４実施形態に係る動作例を表す図である。 図１７（Ａ）と図１７（Ｂ）は第５実施形態に係るノード間の構成例を表す図である。 図１８は、第５実施形態に係る動作例を表す図である。 図１９は、第６実施形態に係るノード間の構成例を表す図である。 図２０は、第６実施形態に係る動作例を表す図である。 図２１（Ａ）から図２１（Ｃ）は、第７実施形態に係るトポロジの構成例を表す図である。 図２２は、付記にかかる動作例を表す図である。 図２３は、付記にかかる動作例を表す図である。
　図面を参照しながら、実施形態に係るセルラ通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
　（セルラ通信システムの構成）
　一実施形態に係るセルラ通信システムの構成例について説明する。一実施形態に係るセルラ通信システム１は３ＧＰＰの５Ｇシステムである。具体的には、セルラ通信システム１における無線アクセス方式は、５Ｇの無線アクセス方式であるＮＲ（New Radio）である。但し、セルラ通信システム１には、ＬＴＥ（Long Term Evolution）が少なくとも部分的に適用されてもよい。また、セルラ通信システム１は、６Ｇなど、将来のセルラ通信システムも適用されてよい。
　図１は、一実施形態に係るセルラ通信システム１の構成例を示す図である。
　図１に示すように、セルラ通信システム１は、５Ｇコアネットワーク（５ＧＣ）１０と、ユーザ装置（ＵＥ：User Equipment）１００、基地局装置（以下、「基地局」と称する場合がある。）２００－１，２００－２、及びＩＡＢノード３００－１，３００－２を有する。基地局２００は、ｇＮＢと呼ばれる場合がある。
　以下において、基地局２００がＮＲ基地局である一例について主として説明するが、基地局２００がＬＴＥ基地局（すなわち、ｅＮＢ）であってもよい。
　なお、以下において、基地局２００－１，２００－２をｇＮＢ２００（又は基地局２００）、ＩＡＢノード３００－１，３００－２をＩＡＢノード３００とそれぞれ称する場合がある。
　５ＧＣ１０は、ＡＭＦ（Access and Mobility Management Function）１１及びＵＰＦ（User Plane Function）１２を有する。ＡＭＦ１１は、ＵＥ１００に対する各種モビリティ制御等を行う装置である。ＡＭＦ１１は、ＮＡＳ（Non-Access Stratum）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００が在圏するエリアの情報を管理する。ＵＰＦ１２は、ユーザデータの転送制御等を行う装置である。
　各ｇＮＢ２００は、固定の無線通信ノードであって、１又は複数のセルを管理する。セルは、無線通信エリアの最小単位を示す用語として用いられる。セルは、ＵＥ１００との無線通信を行う機能又はリソースを示す用語として用いられることがある。１つのセルは１つのキャリア周波数に属する。以下では、セルと基地局とを区別しないで用いる場合がある。
　各ｇＮＢ２００は、ＮＧインターフェイスと呼ばれるインターフェイスを介して５ＧＣ１０と相互に接続される。図１において、５ＧＣ１０に接続された２つのｇＮＢ２００－１及びｇＮＢ２００－２を例示している。
　各ｇＮＢ２００は、集約ユニット（ＣＵ：Central Unit）と分散ユニット（ＤＵ：Distributed Unit）とに分割されていてもよい。ＣＵ及びＤＵは、Ｆ１インターフェイスと呼ばれるインターフェイスを介して相互に接続される。Ｆ１プロトコルは、ＣＵとＤＵとの間の通信プロトコルであって、制御プレーンのプロトコルであるＦ１－ＣプロトコルとユーザプレーンのプロトコルであるＦ１－Ｕプロトコルとがある。
　セルラ通信システム１は、バックホールにＮＲを用いてＮＲアクセスの無線中継を可能とするＩＡＢをサポートする。ドナーｇＮＢ２００－１（又はドナーノード。以下、「ドナーノード」と称する場合がある。）は、ネットワーク側のＮＲバックホールの終端ノードであり、ＩＡＢをサポートする追加機能を備えたドナー基地局である。バックホールは、複数のホップ（すなわち、複数のＩＡＢノード３００）を介するマルチホップが可能である。
　図１において、ＩＡＢノード３００－１がドナーノード２００－１と無線で接続し、ＩＡＢノード３００－２がＩＡＢノード３００－１と無線で接続し、Ｆ１プロトコルが２つのバックホールホップで伝送される一例を示している。
　ＵＥ１００は、セルとの無線通信を行う移動可能な無線通信装置である。ＵＥ１００は、ｇＮＢ２００又はＩＡＢノード３００との無線通信を行う装置であればどのような装置であってもよい。例えば、ＵＥ１００は、携帯電話端末やタブレット端末、ノートＰＣ、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置、飛行体若しくは飛行体に設けられる装置である。ＵＥ１００は、アクセスリンクを介してＩＡＢノード３００又はｇＮＢ２００に無線で接続する。図１において、ＵＥ１００がＩＡＢノード３００－２と無線で接続される一例を示している。ＵＥ１００は、ＩＡＢノード３００－２及びＩＡＢノード３００－１を介してドナーノード２００－１と間接的に通信する。
　図２は、ＩＡＢノード３００と親ノード（Ｐａｒｅｎｔ　ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ　ｎｏｄｅｓ）との関係例を示す図である。
　図２に示すように、各ＩＡＢノード３００は、基地局機能部に相当するＩＡＢ－ＤＵとユーザ装置機能部に相当するＩＡＢ－ＭＴ（Mobile Termination）とを有する。
　ＩＡＢ－ＭＴのＮＲ　Ｕｕ無線インターフェイス上の隣接ノード（すなわち、上位ノード）は、親ノードと呼ばれる。親ノードは、親ＩＡＢノード又はドナーノード２００のＤＵである。ＩＡＢ－ＭＴと親ノードとの間の無線リンクは、バックホールリンク（ＢＨリンク）と呼ばれる。図２において、ＩＡＢノード３００の親ノードがＩＡＢノード３００－Ｐ１及び３００－Ｐ２である一例を示している。なお、親ノードへ向かう方向は、アップストリーム（ｕｐｓｔｒｅａｍ）と呼ばれる。ＵＥ１００から見て、ＵＥ１００の上位ノードは親ノードに該当し得る。
　ＩＡＢ－ＤＵのＮＲアクセスインターフェイス上の隣接ノード（すなわち、下位ノード）は、子ノードと呼ばれる。ＩＡＢ－ＤＵは、ｇＮＢ２００と同様に、セルを管理する。ＩＡＢ－ＤＵは、ＵＥ１００及び下位のＩＡＢノードへのＮＲ　Ｕｕ無線インターフェイスを終端する。ＩＡＢ－ＤＵは、ドナーノード２００－１のＣＵへのＦ１プロトコルをサポートする。図２において、ＩＡＢノード３００の子ノードがＩＡＢノード３００－Ｃ１～３００－Ｃ３である一例を示しているが、ＩＡＢノード３００の子ノードにＵＥ１００が含まれてもよい。なお、子ノードへ向かう方向は、ダウンストリーム（ｄｏｗｎｓｔｒｅａｍ）と呼ばれる。
　また、１つ又は複数のホップを介して、ドナーノード２００に接続されている全てのＩＡＢノード３００は、ドナーノード２００をルートとする有向非巡回グラフ（ＤＡＧ：Directed Acyclic Graph）トポロジ（以下、「トポロジ」と称する場合がある。）を形成する。このトポロジにおいて、図２に示すように、ＩＡＢ－ＤＵのインターフェイス上の隣り合うノードが子ノード、ＩＡＢ－ＭＴのインターフェイス上の隣り合うノードが親ノードとなる。ドナーノード２００は、例えば、ＩＡＢトポロジのリソース、トポロジ、ルート管理などを集中的に行う。ドナーノード２００は、バックホールリンクとアクセスリンクのネットワークを介して、ＵＥ１００に対して、ネットワークアクセスを提供するｇＮＢである。
　（基地局の構成）
　次に、実施形態に係る基地局であるｇＮＢ２００の構成について説明する。図３は、ｇＮＢ２００の構成例を示す図である。図３に示すように、ｇＮＢ２００は、無線通信部２１０と、ネットワーク通信部２２０と、制御部２３０とを有する。
　無線通信部２１０は、ＵＥ１００との無線通信及びＩＡＢノード３００との無線通信を行う。無線通信部２１０は、受信部２１１及び送信部２１２を有する。受信部２１１は、制御部２３０の制御下で各種の受信を行う。受信部２１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部２３０に出力する。送信部２１２は、制御部２３０の制御下で各種の送信を行う。送信部２１２はアンテナを含み、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。
　ネットワーク通信部２２０は、５ＧＣ１０との有線通信（又は無線通信）及び隣接する他のｇＮＢ２００との有線通信（又は無線通信）を行う。ネットワーク通信部２２０は、受信部２２１及び送信部２２２を有する。受信部２２１は、制御部２３０の制御下で各種の受信を行う。受信部２２１は、外部から信号を受信して受信信号を制御部２３０に出力する。送信部２２２は、制御部２３０の制御下で各種の送信を行う。送信部２２２は、制御部２３０が出力する送信信号を外部に送信する。
　制御部２３０は、ｇＮＢ２００における各種の制御を行う。制御部２３０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサとＣＰＵとを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部２３０は、以下に示す各実施形態において、ｇＮＢ２００における各処理又は各動作を行ってもよい。
　（中継ノードの構成）
　次に、実施形態に係る中継ノード（又は中継ノード装置。以下、「中継ノード」と称する場合がある。）であるＩＡＢノード３００の構成について説明する。図４は、ＩＡＢノード３００の構成例を示す図である。図４に示すように、ＩＡＢノード３００は、無線通信部３１０と、制御部３２０とを有する。ＩＡＢノード３００は、無線通信部３１０を複数有していてもよい。
　無線通信部３１０は、ｇＮＢ２００との無線通信（ＢＨリンク）及びＵＥ１００との無線通信（アクセスリンク）を行う。ＢＨリンク通信用の無線通信部３１０とアクセスリンク通信用の無線通信部３１０とが別々に設けられていてもよい。
　無線通信部３１０は、受信部３１１及び送信部３１２を有する。受信部３１１は、制御部３２０の制御下で各種の受信を行う。受信部３１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部３２０に出力する。送信部３１２は、制御部３２０の制御下で各種の送信を行う。送信部３１２はアンテナを含み、制御部３２０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。
　制御部３２０は、ＩＡＢノード３００における各種の制御を行う。制御部３２０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部３２０は、以下に示す各実施形態において、ＩＡＢノード３００における各処理又は各動作を行ってもよい。
　（ユーザ装置の構成）
　次に、実施形態に係るユーザ装置であるＵＥ１００の構成について説明する。図５は、ＵＥ１００の構成例を示す図である。図５に示すように、ＵＥ１００は、無線通信部１１０と、制御部１２０とを有する。
　無線通信部１１０は、アクセスリンクにおける無線通信、すなわち、ｇＮＢ２００との無線通信及びＩＡＢノード３００との無線通信を行う。また、無線通信部１１０は、サイドリンクにおける無線通信、すなわち、他のＵＥ１００との無線通信を行ってもよい。無線通信部１１０は、受信部１１１及び送信部１１２を有する。受信部１１１は、制御部１２０の制御下で各種の受信を行う。受信部１１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部１２０に出力する。送信部１１２は、制御部１２０の制御下で各種の送信を行う。送信部１１２はアンテナを含み、制御部１２０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。
　制御部１２０は、ＵＥ１００における各種の制御を行う。制御部１２０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部１２０は、以下に示す各実施形態において、ＵＥ１００における各処理を行うようにしてもよい。
　（プロトコルスタックの構成）
　次に、実施形態に係るプロトコルスタックの構成について説明する。図６は、ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックの例を示す図である。
　図６に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Medium Access Control）レイヤと、ＲＬＣ（Radio Link Control）レイヤと、ＰＤＣＰ（Packet Data Convergence Protocol）レイヤと、ＲＲＣ（Radio Resource Control）レイヤと、ＮＡＳ（Non-Access Stratum）レイヤとを有する。
　ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＰＨＹレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。
　ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＭＡＣレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ＩＡＢ－ＤＵのＭＡＣレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及び割当リソースブロックを決定する。
　ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＲＬＣレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
　ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＰＤＣＰレイヤとドナーノード２００のＰＤＣＰレイヤとの間では、無線ベアラを介してデータ及び制御情報が伝送される。
　ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＲＲＣレイヤとドナーノード２００のＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ドナーノード２００とのＲＲＣ接続がある場合、ＩＡＢ－ＭＴはＲＲＣコネクティッド状態である。ドナーノード２００とのＲＲＣ接続がない場合、ＩＡＢ－ＭＴはＲＲＣアイドル状態である。
　ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＮＡＳレイヤとＡＭＦ１１との間では、ＮＡＳシグナリングが伝送される。
　図７は、Ｆ１－Ｕプロトコルに関するプロトコルスタックを示す図である。図８は、Ｆ１－Ｃプロトコルに関するプロトコルスタックを示す図である。ここでは、ドナーノード２００がＣＵ及びＤＵに分割されている一例を示す。
　図７に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴ、ＩＡＢノード３００－１のＩＡＢ－ＤＵ、ＩＡＢノード３００－１のＩＡＢ－ＭＴ、及びドナーノード２００のＤＵの各々は、ＲＬＣレイヤの上位レイヤとしてＢＡＰ（Backhaul Adaptation Protocol）レイヤを有する。ＢＡＰレイヤは、ルーティング処理及びベアラマッピング・デマッピング処理を行うレイヤである。バックホールでは、ＩＰレイヤがＢＡＰレイヤを介して伝送されることにより、複数のホップでのルーティングが可能になる。
　各バックホールリンクにおいて、ＢＡＰレイヤのＰＤＵ（Protocol Data Unit）は、バックホールＲＬＣチャネル（ＢＨ　ＮＲ　ＲＬＣチャネル）によって伝送される。各ＢＨリンクで複数のバックホールＲＬＣチャネルを構成することにより、トラフィックの優先順位付け及びＱｏＳ制御が可能である。ＢＡＰ　ＰＤＵとバックホールＲＬＣチャネルとの対応付けは、各ＩＡＢノード３００のＢＡＰレイヤ及びドナーノード２００のＢＡＰレイヤによって実行される。
　図８に示すように、Ｆ１－Ｃプロトコルのプロトコルスタックは、図７に示すＧＴＰ－Ｕレイヤ及びＵＤＰレイヤに代えて、Ｆ１ＡＰレイヤ及びＳＣＴＰレイヤを有する。
　なお、以下においては、ＩＡＢのＩＡＢ－ＤＵとＩＡＢ－ＭＴで行われる処理又は動作について、単に「ＩＡＢ」の処理又は動作として説明する場合がある。例えば、ＩＡＢノード３００－１のＩＡＢ－ＤＵが、ＩＡＢノード３００－２のＩＡＢ－ＭＴへＢＡＰレイヤのメッセージを送信することを、ＩＡＢノード３００－１がＩＡＢノード３００－２へ、当該メッセージを送信するものとして説明する。また、ドナーノード２００のＤＵ又はＣＵの処理又は動作についても、単に「ドナーノード」の処理又は動作として説明する場合がある。
　また、アップストリーム方向とアップリンク（ＵＬ）方向とを区別しないで用いる場合がある。更に、ダウンストリーム方向とダウンリンク（ＤＬ）方向とを区別しないで用いる場合がある。
［第１実施形態］
　次に、第１実施形態について説明する。
　最初に、第１実施形態に係るＴｙｐｅ２　ＢＨ　ＲＬＦ　ＩｎｄｉｃａｔｉｏｎとＴｙｐｅ３　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎについて説明する。
（Ｔｙｐｅ２　ＢＨ　ＲＬＦ　ＩｎｄｉｃａｔｉｏｎとＴｙｐｅ３　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎ）
　図９は、第１実施形態に係るノード間の構成例を示す図である。
　図９に示すセルラ通信システム１は、ＩＡＢノード３００－Ｔ、親ノード（ＩＡＢノード）３００－Ｐ１と親ノード３００－Ｐ２、及び子ノード（ＩＡＢノード）３００－Ｃを含む。
　ＩＡＢノード３００－Ｐ１は、ＩＡＢノード３００－Ｔの親ノードである。以下、ＩＡＢノード３００－Ｐ１を親ノード３００－Ｐ１と称する場合がある。親ノード３００－Ｐ１のＩＡＢ－ＤＵとＩＡＢノード３００－ＴのＩＡＢ－ＭＴとの間でバックホールリンク（ＢＨリンク）＃１が確立されている。なお、親ノード３００－Ｐ１は、ドナーノード２００（のＤＵ＃１）であってもよい。
　ＩＡＢノード３００－Ｐ２も、ＩＡＢノード３００－Ｔの親ノードである。以下、ＩＡＢノード３００－Ｐ２を親ノード３００－Ｐ２と称する場合がある。親ノード３００－Ｐ２のＩＡＢ－ＤＵとＩＡＢノード３００－ＴのＩＡＢ－ＭＴとの間でもＢＨリンク＃２が確立されている。なお、親ノード３００－Ｐ２は、ドナーノード２００（のＤＵ＃２）であってもよい。
　ＩＡＢノード３００－Ｃは、ＩＡＢノード３００－Ｔの子ノードである。以下、ＩＡＢノード３００－Ｃを子ノード３００－Ｃと称する場合がある。子ノード３００－ＣのＩＡＢ－ＭＴとＩＡＢノード３００－ＴのＩＡＢ－ＤＵとの間でもＢＨリンク＃３が確立されている。
　このような構成において、ＢＨリンク＃１で無線リンク障害（ＢＨ　ＲＬＦ（Radio Link Failure））が発生し、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴがこのＢＨ　ＲＬＦを検知した仮定する。
　ＩＡＢノード３００－ＴのＩＡＢ－ＤＵは、ダウンストリーム側の子ノード３００－Ｃへ、Ｔｙｐｅ１　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎ（以下、「Ｔｙｐｅ１　Ｉｎｄｉｃａｔｉｏｎ」と称する場合がある。）を送信できる。Ｔｙｐｅ１　Ｉｎｄｉｃａｔｉｏｎは、ＢＨ　ＲＬＦを検知したことを示す障害発生通知の一例である。
　また、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴが、当該ＢＨ　ＲＬＦに対する回復動作を検知した場合、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵは、子ノード３００－Ｃへ、Ｔｙｐｅ２　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎ（以下、「Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎ」と称する場合がある。）を送信できる。Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎは、ＢＨ　ＲＬＦからの回復を試行中であることを示す回復試行通知（又は障害発生通知）の一例である。
　なお、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵは、Ｔｙｐｅ１　ＩｎｄｉｃａｔｉｏｎとＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎとを区別しないときは、子ノードへ、Ｔｙｐｅ１／２　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎ（以下、「Ｔｙｐｅ１／２　Ｉｎｄｉｃａｔｉｏｎ」と称する場合がある。）を送信できる。Ｔｙｐｅ１／２　Ｉｎｄｉｃａｔｉｏｎも、障害発生通知の一例である。
　ここで、Ｔｙｐｅ１　ＩｎｄｉｃａｔｉｏｎをＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎと読み替えてもよい。Ｔｙｐｅ１　ＩｎｄｉｃａｔｉｏｎはＢＨ　ＲＬＦ検出時、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎは回復試行時に、それぞれ送信される。しかし、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、ＢＨ　ＲＬＦ出後、直ちに、ＢＨ　ＲＬＦの回復試行処理を行う。そのため、２つのＩｎｄｉｃａｔｉｏｎを実質的に同じＩｎｄｉｃａｔｉｏｎと見ることができる。
　更に、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴが、当該ＢＨ　ＲＬＦからの回復を検知した場合、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵは、子ノード３００－Ｃへ、Ｔｙｐｅ３　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎ（以下、「Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎ」と称する場合がある。）を送信できる。Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎは、ＢＨリンクがＢＨ　ＲＬＦからリカバリしたことを示す回復通知でもよい。
　更に、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴが、当該ＢＨ　ＲＬＦからの回復に失敗したことを検知した場合、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵは、子ノードへ、Ｔｙｐｅ４　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎ（以下、「Ｔｙｐｅ４　Ｉｎｄｉｃａｔｉｏｎ」と称する場合がある。）を送信できる。Ｔｙｐｅ４　Ｉｎｄｉｃａｔｉｏｎは、ＢＨリンクがＢＨ　ＲＬＦからリカバリに失敗したことを示す失敗通知でもある。
　図９では、ＩＡＢノード３００－Ｔが、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを、子ノード３００－Ｃへ送信する例を表している。
　なお、これらのＴｙｐｅ　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎは、ＢＡＰ　Ｃｏｎｔｒｏｌ　ＰＤＵ又はＭＡＣ　ＣＥに含まれて送信されてもよい。
（二重接続方式（ＤＣ：Dual Connectivity））
　ＩＡＢノード３００－Ｔは、２つの異なる親ノード３００－Ｐ１及び３００－Ｐ２から提供されるリソースを利用することが可能である。一方の親ノードが、マスターセルグループ（以下、「ＭＣＧ」と称する場合がある。）を管理するマスターノード（ＭＮ）となり得る。他方の親ノードが、セカンダリセルグループ（以下、「ＳＣＧ」と称する場合がある。）を管理するセカンダリノード（ＳＮ）となり得る。
　ＭＣＧは、マスターノードに関連付けられているサービングセルのセルグループである。ＭＣＧは、プライマリセル（Ｓｐセル又はＰセル）と、オプションで１以上のセカンダリセル（Ｓセル）とを有する。
　ＳＣＧは、セカンダリノードに関連付けられているサービングセルのグループである。ＳＣＧは、プライマリセル（Ｓｐセル又はＰＳセル）と、オプションで１以上のセカンダリセル（Ｓセル）とを有する。Ｓｐセルは、ＭＣＧにおけるプライマリセルであり、ＳＣＧにおけるプライマリセルでもある。
　ここで、マスターノードとセカンダリノードは、論理的なエンティティ（ｅｎｔｉｔｙ）である。第１実施形態では、マスターノードは親ノード３００－Ｐ１に対応し、セカンダリノードは親ノード３００－Ｐ２に対応するものとして、以下説明する。
　ＩＡＢノード３００－Ｔは、ＭＣＧを管理するマスターノードと接続しつつ、ＳＣＧを管理するとセカンダリノードと接続することができる。この場合、ＩＡＢノード３００－Ｔは、各親ノード３００－Ｐ１及び３００－Ｐ２に同時に接続して、無線通信を行う。これにより、ＩＡＢノード３００－Ｔでは、スループット向上を図ることができる。
　二重接続方式（以下、「ＤＣ」と称する場合がある。）の種類の１つとして、ＥＮ－ＤＣ（（E-UTRA(Evolved Universal Terrestrial Radio Access)-NR Dual Connectivity））がある。ＥＮ－ＤＣでは、ＩＡＢノード３００－Ｔは、マスターノードとして機能する１つのｅＮＢ（evolved Node B）と接続されるとともに、セカンダリノードとして機能する１つのｅｎ－ｇＮＢと接続される。ｅＮＢは、Ｅ－ＵＴＲＡサービスを提供するＬＴＥ基地局である。また、ｅｎ－ｇＮＢは、ＮＲサービスを提供するＮＲ基地局である。例えば、図９の例では、マスターノードである親ノード３００－Ｐ１がｅＮＢ、セカンダリノードである親ノード３００－Ｐ２がｅｎ－ｇＮＢとなり得る。ＥＮ－ＤＣでは、ＭＣＧが制御（Ｃ－Ｐｌａｎｅ）に関する処理を行う。一方、ＳＣＧはデータ（Ｕ－Ｐｌａｎｅ）に関する処理を行う。
　ＤＣの種類には、他にもＮＲ－ＤＣ（NR-NR Dual Connectivity）がある。ＮＲ－ＤＣは、マスターノードもセカンダリノードもｇＮＢである。ＮＲ－ＤＣでは、ＭＣＧもＳＣＧも、ともに、制御とデータに関する処理を行うことができる。そのため、例えば、ＩＡＢノード３００－Ｔは、ともにｇＮＢである親ノード３００－Ｐ１及び３００－Ｐ２との間で同時にデータを送受信できる。
（第１実施形態に係る通信制御方法）
　３ＧＰＰでは、シングル接続の場合、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎの生成（又は送信）は、ＢＨ　ＲＬＦ（以下、「ＲＬＦ」と称する場合がある。）検出時であることが合意されている。
　一方、ＤＣの場合、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎがどのような場合に送信されるのかについては、３ＧＰＰではまだ決定されていない。
　ＤＣの場合についても、シングル接続の場合と同様に、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎの生成（又は送信）は、ＲＬＦ検出時とすることも可能である。
　この場合、２つのケースが考えられる。すなわち、ＭＣＧ側で発生したＲＬＦが検知されて、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎが送信されるケースと、ＳＣＧ側で発生したＲＬＦが検知されて、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎが送信されるケースである。図９は、前者のケースの例を示し、図１０は、後者のケースの例を示している。
　このような場合において、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信した子ノード３００－Ｃは、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信しただけでは、ＭＣＧ側でＲＬＦが発生しているのか、ＳＣＧ側でＲＬＦが発生しているのか、分からない場合がある。
　そこで、ＩＡＢノード３００－Ｔは、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏに付加情報を付加して送信することができる。付加情報を受信した子ノード３００－Ｃは、付加情報に基づいて、ルーティング処理又はリルーティング処理などを行うことが可能となる。
　更に、ＭＣＧ側とＳＣＧ側の双方でＲＬＦが（同時に）発生する場合もある。この場合、子ノード３００－Ｃは、ＭＣＧ側で発生したＲＬＦに対応するＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎと、ＳＣＧ側で発生したＲＬＦに対応するＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎの２つを受信する。
　その後、ＭＣＧ側で発生したＲＬＦが回復したと仮定する。この場合、ＩＡＢノード３００－Ｔは、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを、子ノード３００－Ｃへ送信する。
　子ノード３００－Ｃは、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを受信しても、ＭＣＧ側で発生したＲＬＦが回復したのか、ＳＣＧ側で発生したＲＬＦが回復したのか、わからない場合がある。
　そこで、第１実施形態では、ＩＡＢノード３００－ＴがＴｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎに付加情報を付加して、子ノード３００－Ｃへ送信する。
　具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００－Ｔ）が、マスターセルグループを管理する第１親ノード（例えば、親ノード３００－Ｐ１）をマスターノードとし、セカンダリセルグループを管理する第２親ノード（例えば、親ノード３００－Ｐ２）をセカンダリノードとして、二重接続方式が設定される。第２に、中継ノードが、第１親ノードとの間の第１バックホールリンク（例えば、ＢＨリンク＃１）と、第２親ノードとの間の第２バックホールリンク（例えば、ＢＨリンク＃２）のうち、少なくともいずれかで発生した無線リンク障害から回復したことを示す第２通知（例えば、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎ）を、子ノード（例えば、子ノード３００－Ｃ）へ送信する。ここで、第２通知は、第２付加情報を含み、第２付加情報は、少なくとも、使用可能となった第２ルーティングＩＤを示す。
　これにより、例えば、子ノード３００－Ｃは、使用可能になったルーティングＩＤに基づいて、ローカルリルーティングを実行していた場合に通常のルーティング動作に戻すなど、適切な処理を行うことが可能となる。
　なお、ルーティングＩＤは、宛先ＢＡＰアドレス（Ｄｅｓｔｉｎａｔｉｏｎ）と経路識別子（Ｐａｔｈ　ＩＤ）とにより構成される。
（第１実施形態に係る動作例）
　図１１は、第１実施形態に係る動作例を表す図である。
　図１１に示すように、ステップＳ１０において、ＩＡＢノード３００－Ｔは、処理を開始する。
　なお、ＩＡＢノード３００－Ｔは、ステップＳ１０の後、ステップＳ１１の前において、ＤＣが設定されるものとする。すなわち、ＩＡＢノード３００－Ｔは、ＭＣＧを管理する親ノード３００－Ｐ１をマスターノードとし、ＳＣＧを管理する親ノード３００－Ｐ２をセカンダリノードとして、ＤＣが設定されるものとする。
　ステップＳ１１において、ＩＡＢノード３００－Ｔは、ＲＬＦを検知する（又はＲＬＦから復旧中であることを検知する）。ＲＬＦは、ＭＣＧ側のＢＨリンク＃１でもよいし、ＳＣＧ側のＢＨリンク＃２でもよい。また、ＲＬＦは、ＭＣＧ側のＢＨリンク＃１とＳＣＧ側のＢＨリンク＃２とで同時に発生してもよい。ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、ＲＬＦが各ＢＨリンクで同時に発生した場合でも個別に発生した場合でも、ＲＬＦ毎に当該ＲＬＦを検知してもよい。
　ステップＳ１２において、ＩＡＢノード３００－Ｔは、子ノード３００－Ｃへ、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信する。ＩＡＢノード３００－Ｔは、検知したＲＬＦ毎に独立してＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信する。例えば、ＩＡＢノード３００－Ｔは、ＭＣＧ側のＢＨリンク＃１で発生したＲＬＦを検知すると、当該ＲＬＦに対応するＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信し、ＳＣＧ側のＢＨリンク＃２で発生したＲＬＦを検知すると、当該ＲＬＦに対応するＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信する。
　ここで、ＩＡＢノード３００－Ｔは、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎに付加情報を付加して送信する。付加情報は、当該ＲＬＦによって影響を受けるルートの情報であってもよい。
　具体的には、付加情報は、使用不可能なＣＧ（例えば、ＭＣＧが使用不可能か、ＳＣＧが使用不可能かを示す情報）、使用不可能なルーティングＩＤ、及び使用不可能なリンク品質の少なくともいずれかを含んでもよい。更に、付加情報は、使用不可能なＢＨ　ＲＬＣ　チャネルＩＤ（ＢＨ　ＲＬＣ　ｃｈａｎｎｅｌ　ＩＤ）を含んでもよい。子ノード３００－Ｃは、使用不可能なＢＨ　ＲＬＣチャネルＩＤを受信することで、当該ＢＨ　ＲＬＣチャネルへの送信を停止したり、他のＢＨ　ＲＬＣチャネルへのルーティングを行ったりすることが可能となる。
　なお、子ノード３００－Ｃは、付加情報を含むＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信したことにより、他の親ノードへのローカルリルーティングを実行するものとして、以下説明する。ローカルリルーティングとは、例えば、ある親ノードから、代替パス上の他の親ノードへ送信を切り替えることである。図９の例では、子ノード３００－Ｃは、ＩＡＢノード３００－Ｔ（子ノード３００－Ｃにとって親ノード）から、代替パス上の他のＩＡＢノード（子ノード３００－Ｃにとって別の親ノード）へ送信を切り替える。
　図１１に戻り、ステップＳ１３において、ＩＡＢノード３００－Ｔは、ＢＨリンクで発生したＲＬＦの復旧を検知する。ＩＡＢノード３００－Ｔは、ＭＣＧ側におけるＲＬＦからの復旧と、ＳＣＧ側におけるＲＬＦからの復旧について、それぞれ独立して検知する。
　ステップＳ１４において、ＩＡＢノード３００－Ｔは、子ノード３００－Ｃへ、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを送信する。ＩＡＢノード３００－Ｔは、ＭＣＧ側におけるＲＬＦからの復旧を検知すると、当該復旧に対応するＴｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを送信し、ＲＣＧ側におけるＲＬＦからの復旧を検知すると、当該復旧に対応するＴｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを送信する。
　図１２は、第１実施形態に係るノード間の構成例を表す図である。図１２に示すように、ＩＡＢノード３００－Ｔは、子ノード３００－Ｃへ、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを送信する。
　ここで、ＩＡＢノード３００－Ｔは、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎに付加情報を付加して送信する。付加情報は、当該復旧により影響を受けるルートの情報であってもよい。
　具体的には、付加情報は、使用可能となったＣＧ（例えば、使用可能となったのはＭＣＧであるのかＳＣＧであるのかを示す情報）、使用可能となったルーティングＩＤ、使用可能なリンク品質（例えば、使用可能なスループットの更新）、及び使用可能となったＢＨ　ＲＬＣチャネルＩＤの少なくともいずれかを含む。
　ステップＳ１５において、子ノード３００－Ｃは、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを受信したことに応じて、付加情報に従って、ローカルリルーティング動作を停止し、通常のルーティング動作を行う。例えば、子ノード３００－Ｃは、使用可能となったルーティングＩＤについて、ローカルリルーティングを停止する。また、例えば、子ノード３００－Ｃは、使用可能となったルーティングＩＤ＃１を付加情報として受信し、ルーティングＩＤ＃２についてローカルリルーティングを実行していたと仮定する。この場合、ルーティングＩＤ＃２は依然として、使用不可能なルーティングＩＤである。子ノード３００－Ｃは、ルーティングＩＤ＃２については、ローカルリルーティングを継続することになる。
　このように、付加情報を受信した子ノード３００－Ｃは、復旧により影響を受けるルートの情報を把握することができ、付加情報に従って、通信を制御することが可能となる。
　そして、ステップＳ１６において、子ノード３００－Ｃは、一連の処理を終了する。
（第１実施形態の変形例）
　第１実施形態では、ＩＡＢノード３００－Ｔは、付加情報を含むＴｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを子ノード３００－Ｃへ送信する例について説明した。例えば、ＩＡＢノード３００－Ｔは、付加情報を含まないＴｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを送信してもよい。この場合、子ノード３００－Ｃは、当該Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎに関連するＢＨリンクの全てのルーティングＩＤが使用可能になったと判断してもよい。
［第２実施形態］
　次に、第２実施形態について説明する。
　ローカルリルーティングに関して、ドナーＤＵ間リルーティングが行われる場合がある。ドナー間リルーティングとは、例えば、ドナーノード２００の第１ＤＵから当該ドナーノード２００の第２ＤＵへ経路が切り替わるリルーティングのことである。
　図１３は、第２実施形態に係るノード間の構成例を表す図である。図１３は、ドナー間リルーティングの例を表している。
　図１３の例では、ドナー間リルーティングにより、ドナーノード２００のＤＵ＃１（以下、「ドナーＤＵ＃１」）（２００Ｄ１）から、ドナーノード２００のＤＵ＃２（以下、「ドナーＤＵ＃２」）（２００Ｄ２）へ切り替えられる。この場合、アップストリーム方向のパケットの宛先が、ドナーＤＵ＃１のＢＡＰアドレスから、ドナーＤＵ＃２のＢＡＰアドレスへと変更されることになる。
　なお、図１３では、第１実施形態と同様に、ＩＡＢノード３００－Ｔと、親ノード３００－Ｐ１及び３００－Ｐ２とにおいて、ＤＣ設定が行われた例を表している。
　そして、ＩＡＢノード３００－Ｔは、ＭＣＧ側のＢＨリンク又はＳＣＧ側のＢＨリンクでＲＬＦを検知した場合、付加情報を含むＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信できる。
　ここで、ＩＡＢノード３００－Ｔは、ＭＣＧ側のＢＨリンクでのＲＬＦを検知した場合、当該付加情報として、ＭＣＧ側に紐づいた宛先（Ｄｅｓｔｉｎａｔｉｏｎ：ドナーＤＵ＃１のＢＡＰアドレス）を有する全てのルーティングＩＤを、送信する場合もある。
　また、ＩＡＢノード３００－Ｔは、ＳＣＧ側のＢＨリンクでのＲＬＦを検知した場合、当該付加情報として、ＳＣＧ側に紐づいた宛先（Ｄｅｓｔｉｎａｔｉｏｎ：ドナーＤＵ＃２（２００Ｄ２）のＢＡＰアドレス）を有する全てのルーティングＩＤを、送信する場合もある。
　しかし、ＩＡＢノード３００－Ｔが、付加情報として、宛先に紐づいた全てのルーティングＩＤを送信するには、付加情報のオーバーヘッドが大きい。
　そこで、第２実施形態では、ＩＡＢノード３００－Ｔは、使用不可能になった宛先ＢＡＰアドレスをＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎの付加情報として、子ノード３００－Ｃへ送信する例について説明する。
　具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００－Ｔ）が、親ノード（例えば、親ノード３００－Ｐ１）との間のバックホールリンクで発生した無線リンク障害により、使用不可能となったルーティングＩＤに含まれる宛先ＢＡＰアドレスを確認する。第２に、中継ノードが、無線リンク障害に対して回復試行中であることを示す第１通知を、子ノード（例えば、子ノード３００－Ｃ）へ送信する。ここで、第１通知は、付加情報を含み、付加情報は、宛先ＢＡＰアドレスを含む。
　これにより、ＩＡＢノード３００－Ｔは、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎに付加される付加情報のサイズをコンパクトにして、付加情報のオーバーヘッドを抑制することができる。
（第２実施形態に係る動作例）
　図１４は、第２実施形態に係る動作例を表す図である。
　図１４に示すように、ステップＳ２０において、ＩＡＢノード３００－Ｔは、処理を開始する。
　ステップＳ２１において、ＩＡＢノード３００－Ｔは、ＲＬＦを検知する（又はＲＬＦから復旧中であることを検知する）。
　ステップＳ２２において、ＩＡＢノード３００－Ｔは、ルーティング可能なルーティングＩＤと、ルーティングが不可能なルーティングＩＤとを特定する。具体的には、例えば、以下となる。
　第１に、シングル接続の場合である。シングル接続とは、ＩＡＢノード３００－Ｔに代替パスが存在せず、１つの親ノード３００－Ｐとのみ接続された形態である。シングル接続の場合、代替パスが存在しないため、全てのルーティングＩＤがルーティング不可能なルーティングＩＤとなる。この場合、ルーティング可能なルーティングＩＤは存在しない。そのため、シングル接続の場合、全てのルーティングＩＤがルーティング不可能なルーティングＩＤとなり得る。
　第２に、ＤＣ接続の場合である。例えば、ＩＡＢノード３００－Ｔが、２つの親ノード３００－Ｐ１及び３００－Ｐ２に同時に接続された場合である。なお、ＤＣ接続が行われる場合、ステップＳ２０とステップＳ２１の間で、ＩＡＢノード３００－Ｔに対してＤＣ設定が行われるものとする。
　ＤＣ接続の場合、イントラドナーＤＵ（「Ｉｎｔｒａ－ｄｏｎｏｒ－ＤＵ」）によってルーティング又はリルーティングが行われる場合がある。イントラドナーＤＵは、宛先（Ｄｅｓｔｉｎａｔｉｏｎ）は同じであって、複数の経路が存在する形態である。イントラドナーＤＵの場合、ＲＬＦを検知するものの、代替パスが存在するため、一部のルーティングＩＤは使用不可能であるものの、それ以外のルーティングＩＤは使用可能である。
　ＤＣ接続の場合、ドナーＤＵ間（「Ｉｎｔｅｒ－ｄｏｎｏｒ－ＤＵ」）によってルーティング又はリルーティングが行われる場合がある。ドナー間ＤＵは、例えば、図１３に示すように、ドナーノードの異なるＤＵ間で、ルーティング又はリルーティングが行われる形態である。ドナー間ＤＵの場合、当該ＲＬＦが発生しているＢＨリンクの上流のＤｅｓｔｉｎａｔｉｏｎ（例えば、ドナーＤＵ＃１（２００Ｄ１）のＢＡＰアドレス）がルーティング不可能となる。そのため、当該Ｄｅｓｔｉｎａｔｉｏｎを有する全てのルーティングＩＤが使用不可能となる。他方、別のＢＨリンクの上流のＤｅｓｔｉｎａｔｉｏｎ（ドナーＤＵ＃２（２００Ｄ２）のＢＡＰアドレス）については、経路上ではＲＬＦを検知していないため、当該Ｄｅｓｔｉｎａｔｉｏｎを有する全てのルーティングＩＤは使用可能となる。
　ステップＳ２３において、ＩＡＢノード３００－Ｔは、ルーティングが不可能なルーティングＩＤの宛先（Ｄｅｓｔｉｎａｔｉｏｎ）を確認する。
　具体的には、ＩＡＢノード３００－Ｔは、ルーティングが不可能なルーティングＩＤの宛先が、ルーティング可能なルーティングＩＤの宛先に存在するか否かを確認する。
　そして、ＩＡＢノード３００－Ｔは、ルーティングが不可能なルーティングＩＤの宛先が、ルーティングが可能なルーティングＩＤの宛先に存在しない場合、当該ルーティングが不可能なルーティングＩＤの宛先を、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎの付加情報に含める。
　例えば、上述したシングル接続の場合、ルーティング可能なルーティングＩＤの宛先が存在しないため、ルーティングが不可能なルーティングＩＤの宛先がルーティング可能なルーティングＩＤの宛先に存在しない場合に該当する。この場合、ルーティングが不可能なルーティングＩＤの宛先が当該付加情報に含まれることになる。
　また、例えば、上述したドナーＤＵ間による場合、ルーティング不可能なルーティングＩＤの宛先（ドナーＤＵ＃１（２００Ｄ１）のＢＡＰアドレス）と、ルーティング可能なルーティングＩＤの宛先（ドナーＤＵ＃２（２００Ｄ２））とは、異なる宛先となっている。従って、ルーティングが不可能なルーティングＩＤの宛先（ドナーＤＵ＃１（２００Ｄ１）のＢＡＰアドレス）が、ルーティング可能なルーティングＩＤの宛先（ドナーＤＵ＃２（２００Ｄ２）のＢＡＰアドレス）に存在しない場合に該当する。従って、この場合、ルーティングが不可能なルーティングＩＤの宛先（ドナーＤＵ＃１（２００Ｄ１）のＢＡＰアドレス）が、当該付加情報に含まれることになる。
　一方、ＩＡＢノード３００－Ｔは、ルーティングが不可能なルーティングＩＤの宛先が、ルーティングが可能なルーティングＩＤの宛先に存在する場合、ルーティングが不可能なルーティングＩＤのリストを、当該付加情報に含めるようにする。
　例えば、上述したように、イントラドナーＤＵによる場合、ある宛先へのルーティングが不可能となったとしても、代替パスが存在するため、同一の宛先において、ルーティングが可能な場合も存在する。従って、この場合、ＩＡＢノード３００－Ｔは、ルーティングＩＤが不可能なルーティングＩＤのリストを、当該付加情報に含めるようにする。
　ステップＳ２４において、ＩＡＢノード３００－Ｔは、当該付加情報を含むＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを子ノード３００－Ｃへ送信する。
　ステップＳ２５において、子ノード３００－Ｔは、当該Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信したことに応じて、当該宛先（Ｄｅｓｔｉｎａｔｉｏｎ）を有する全てのルーティングＩＤが使用不可能であると判定する。当該付加情報には、ルーティングが不可能な宛先（Ｄｅｓｔｉｎａｔｉｏｎ）が含まれるため、子ノード３００－Ｔは、当該宛先を含むルーティングＩＤは使用不可能なルーティングＩＤと判定する。
　そして、ステップＳ２６において、子ノード３００－Ｔは、一連の処理を終了する。
［第３実施形態］
　第１実施形態において、ＤＣの種別として、ＥＮ－ＤＣがあることを述べた。ＥＮ－ＤＣでは、上述したように、ＭＣＧが制御（Ｃ－Ｐｌａｎｅ）に関する処理を行い、ＳＣＧがデータ（Ｕ－Ｐｌａｎｅ）に関する処理を行う。そのため、ＭＣＧ側にＲＬＦが発生しても、少なくともデータの送信を維持することが可能である。ＮＲ－ＤＣについても、例えば、ＳＣＧがデータに関する処理し、ＭＣＧが制御に関する処理を行う場合、ＥＮ－ＤＣと同じ状況となり得る。
　このような場合、ＩＡＢノード３００－Ｔは、ＭＣＧ側でＲＬＦが発生しても、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを子ノード３００－Ｃへ送信しないようにすることも可能である。ＩＡＢノード３００－Ｔは、ＳＣＧを利用して、親ノード３００－Ｐ２へデータを転送できるからである。
　しかし、ＩＡＢノード３００－Ｔにおいて、ＤＣの種別を判定したり、ＳＣＧとＭＣＧのどちらの側でデータに関する処理を行っているかを判定したりすることは、処理が複雑になる場合もある。ＩＡＢノード３００－Ｔは、ＤＣの種別を判定する等をすることなく、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信したり、送信しなかったりすることができれば、簡易に処理を行うことが可能となる。
　そこで、第３実施形態では、ＲＬＦによる使用不可能なルートがルーティングテーブル及び／又はマッピングテーブルに存在しなければ、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信しない例について説明する。また、第３実施形態では、使用不可能なルートがルーティングテーブル及び／又はマッピングテーブル存在すれば、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信する例について説明する。
　具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００－Ｔ）が、マスターセルグループを管理する第１親ノード（例えば、親ノード３００－Ｐ１）をマスターノード、セカンダリセルグループを管理する第２親ノード（例えば、親ノード３００－Ｐ２）をセカンダリノードとして、二重接続方式が設定される。第２に、中継ノードが、第１親ノードとの間の第１バックホールリンクと、第２親ノードとの間の第２バックホールリンクのうち、少なくともいずれかで発生した無線リンク障害を検知する。第３に、中継ノードが、無線リンク障害により使用不可能なルートを示す第１ルート情報がルーティングテーブル及び／又はマッピングテーブルに存在する場合、無線リンク障害に対して回復試行中であることを示す第１通知（例えば、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎ）を子ノード（例えば、子ノード３００－Ｃ）へ送信し、第１ルート情報がルーティングテーブル及び／又はマッピングテーブル存在しない場合、前記第１通知を前記子ノードへ送信しないようにする。
　これにより、例えば、ＩＡＢノード３００－Ｔは、ＭＣＧ側でＲＬＦを検知した場合でも、ＭＣＧ側のルート情報がルーティングテーブル及び／又はマッピングテーブルに存在しなければ、当該ＲＬＦを無視して、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信しないようにすることができる。そのため、ＩＡＢノード３００－Ｔでは、ＥＮ－ＤＣが設定されて、ＭＣＧ側でＲＬＦが発生しても、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信しないようにすることができる。従って、ＩＡＢノード３００－Ｔでは、複雑な処理を抑制したＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎの送信を行うことが可能となる。
（第３実施形態に係る動作例）
　図１５は、第３実施形態に係る動作例を表す図である。
　図１５に示すように、ステップＳ３０において、ＩＡＢノード３００－Ｔは、処理を開始する。
　なお、ＩＡＢノード３００－Ｔは、第１実施形態と同様に、ステップＳ３０とステップＳ３１の間で、ＤＣ設定が行われる。ＩＡＢノード３００－Ｔは、親ノード３００－Ｐ１及び３００－Ｐ２と同時に無線通信が可能となる。
　ステップＳ３１において、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、ＲＬＦを検知する。ＩＡＢノード３００－Ｔは、引き続き、ＲＲＣ再確立（ＲＲＣ　ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）手順、ＭＣＧ失敗情報（ＭＣＧ　Ｆａｉｌｕｒｅ　Ｉｎｆｏｒｍａｔｉｏｎ）手順、ＳＣＧ失敗情報（ＳＣＧ　Ｆａｉｌｕｒｅ　Ｉｎｆｏｒｍａｔｉｏｎ）手順を実行してもよい。
　ステップＳ３２において、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴのＲＲＣレイヤは、ＲＬＦを検知したこと（又は当該ＢＨリンクが復旧中であることを）を示す第１情報を、当該ＩＡＢノード３００－ＴのＩＡＢ－ＤＵのＢＡＰレイヤへ出力する。
　例えば、当該ＲＲＣレイヤは、当該ＩＡＢノード３００－ＴのＩＡＢ－ＤＵのＦ１ＡＰレイヤを経由して、当該ＩＡＢノード３００－ＴのＩＡＢ－ＤＵのＢＡＰレイヤへ、第１情報を出力してもよい。
　第１情報は、どのリンクでＲＬＦが発生したのかを示す情報が含まれてもよい。具体的には、第１情報は、ＭＣＧでＲＬＦが発生したのか、ＭＣＧでＲＬＦ発生したのかを示す情報が含まれてもよい。また、第１情報は、ＲＬＦが発生したＢＨリンクを流出ＢＨリンクとする流出ＢＨリンクＩＤ（ｅｇｒｅｓｓ　ＢＨ　ｌｉｎｋ　ＩＤ）が含まれてもよい。更に、第１情報は、ＲＬＦが発生したＢＨリンク上のＩＡＢノード３００－Ｔの次ホップＢＡＰアドレス（Ｎｅｘｔ　ｈｏｐ　ＢＡＰ　ａｄｄｒｅｓｓ）が含まれてもよい。第１情報は、ＭＣＧかＳＣＧかを示す情報、流出ＢＨリンクＩＤ、及び次ホップＢＡＰアドレスの少なくともいずれかが含まれてもよい。
　ステップＳ３３において、ＢＡＰレイヤは、第１情報の入力に応じて、使用不可能なルートが存在するか否かを確認する。具体的には、ＢＡＰレイヤは、第１情報に対応する（又は第１情報を含む）ルート情報が、ルーティング設定（又はルーティングテーブル）及び／又はマッピング設定（又はマッピングテーブル）に存在するか否かを確認する。
　第１に、ルーティングテーブルに対する確認は、例えば、以下となる。
　すなわち、ＢＡＰレイヤは、第１情報に対応する、ルート情報（ここでは、ルーティングＩＤ及び／又は流出ＢＨリンク）が、ルーティングテーブルに存在するか否かを確認する。
　第２に、マッピングテーブルに対する確認は、例えば、以下となる。
　すなわち、ＢＡＰレイヤは、第１情報に対応する、ルート情報（ここでは、流出ＢＨ　ＲＬＣチャネル（ｅｇｒｅｓｓ　ＢＨ　ＲＬＣ　ｃｈａｎｎｅｌ））が、マッピングテーブルに存在するか否かを確認する。
　ステップＳ３４において、ＢＡＰレイヤは、使用不可能なルートが、ルーティングテーブル及び／又はマッピングテーブルに存在すれば（ステップＳ３４でＹＥＳ）、ステップＳ３５の処理を行う。一方、ステップＳ３４において、ＢＡＰレイヤは、使用可能なルートがルーティングテーブル及び／又はマッピングテーブルに存在しなければ（ステップＳ３４でＮＯ）、ステップＳ３８の処理を行う。
　使用不可能なルートが存在する場合（ステップＳ３４でＹＥＳ）とは、第１情報に対応する、ルート情報が、ルーティングテーブル及び／又はマッピングテーブルに存在する場合である。例えば、ＲＬＦがＭＣＧ側で発生した場合、ＭＣＧ側のルート情報が、ルーティングテーブル及び／又はマッピングテーブルに存在する場合である。このような場合、ＢＡＰレイヤは、ステップＳ３５とステップＳ３６を行う。
　使用不可能なルートが存在しない場合（ステップＳ３４でＮＯ）とは、第１情報に対応するルート情報が、ルーティングテーブル及び／又はマッピングテーブルに存在しない場合である。例えば、ＲＬＦがＭＣＧ側で発生した場合であっても、ＭＣＧ側のルート情報が、ルーティングテーブル及び／又はマッピングテーブルに存在しない場合である。このような場合、ＢＡＰレイヤは、ＲＲＣレイヤから第１情報を受け取っても、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信しない。つまり、ＭＣＧ側でＲＬＦが発生しても、ルーティングテーブル及び／又はマッピングテーブルに対応するエントリ（又は対応するルート情報）がなければ、ＢＡＰレイヤは、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信しないようにすることが可能となる。そのため、ＢＡＰレイヤは、ステップＳ３８の処理を行う。
　ステップＳ３５において、ＢＡＰレイヤは、使用不可能なルートを特定する。
　ここで、ＢＡＰレイヤは、下位ノード（例えば、子ノード３００－Ｃ）が把握できるように、使用不可能なルートを特定する。すなわち、ＢＡＰレイヤは、ルート情報として、ルーティングＩＤを用いて、ステップＳ３３とステップＳ３４を判定した場合（当該ルーティングＩＤが使用不可能なルートに対応する場合）、ルーティングＩＤをそのまま用いて、使用不可能なルートとして特定してもよい。また、ＢＡＰレイヤは、ルート情報として、流出ＢＨリンクを用いて、ステップＳ３３とステップＳ３４を判定した場合（当該流出ＢＨリンクが使用不可能なルートに対応する場合）、流出ＢＨリンクに対応する流入ＢＨリンク（ｉｎｇｒｅｓｓ　ＢＨ　ｌｉｎｋ）を、使用不可能なルートとして特定してもよい。更に、ＢＡＰレイヤは、ルート情報として、流出ＢＨ　ＲＬＣチャネルを用いて、ステップＳ３３とステップＳ３４を判定した場合（当該流出ＢＨ　ＲＬＣチャネルが使用不可能なルートに対応する場合）、流出ＢＨ　ＲＬＣチャネルに対応する流入ＢＨ　ＲＬＣチャネル（ｉｎｇｒｅｓｓ　ＢＨ　ＲＬＣ　ｃｈａｎｎｅｌ）を、使用不可能なルートとして特定してもよい。
　ステップＳ３６において、ＢＡＰレイヤは、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信する。ＢＡＰレイヤは、ステップＳ３５で特定したルートと繋がっている子ノード３００－Ｃのみへ、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信してもよい。例えば、ＢＡＰレイヤは、使用不可能なルートとして特定した流入ＢＨリンクと繋がっている子ノード３００－Ｃのみへ、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信してもよい。この場合、ＢＡＰレイヤは、特定した流入ＢＨリンクと繋がっていない子ノードへ、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信しなくてもよい。
　なお、当該Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎには、使用不可能なルートが付加情報として含まれてもよい。使用不可能なルートは、使用不可能なルーティングＩＤなどであってもよい。
　そして、ステップＳ３７において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。
　一方、ステップＳ３８において、ＢＡＰレイヤは、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信しない。
　そして、ステップＳ３８において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。
（第３実施形態の変形例）
　第３実施形態では、ＢＡＰレイヤがステップＳ３３からステップＳ３５の処理を行う例について説明した。例えば、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵのＦ１ＡＰレイヤがステップＳ３３からステップＳ３５の処理を行ってもよい。この場合の動作は、例えば、以下となる。
　すなわち、ステップＳ３２において、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵのＲＲＣレイヤは、当該Ｆ１ＡＰレイヤへ第１情報を出力する。
　ステップＳ３３からステップＳ３５は、ＢＡＰレイヤに代えて、当該Ｆ１ＡＰレイヤが、同様の処理を行えばよい。この場合、当該Ｆ１ＡＰレイヤは、ステップＳ３５で特定した使用不可能なルートを、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵのＢＡＰレイヤへ出力する。そして、ＢＡＰレイヤは、ステップＳ３６以降の処理を行えばよい。
［第４実施形態］
　第３実施形態では、ＲＬＦによる使用不可能なルートがルーティングテーブル及び／又はマッピングテーブルに存在しなければ、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信せず、使用不可能なルートが存在すれば、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信する例を説明した。
　第４実施形態では、ＲＬＦから回復したルートがルーティングテーブル及び／又はマッピングテーブルに存在しなければ、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを送信せず、回復したルートがルーティングテーブル及び／又はマッピングテーブルに存在すれば、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを送信する例を説明する。
　具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００－Ｔ）が、無線リンク障害から回復したことを検知する。第２に、中継ノードが、無線リンク障害からの回復により使用することが可能となったルートを示す第２ルート情報がルーティングテーブル及び／又はマッピングテーブルに存在する場合、無線リンク障害から回復したことを示す第２通知（例えば、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎ）を子ノード（例えば、子ノード３００－Ｃ）へ送信し、第２ルート情報がルーティングテーブル及び／又はマッピングテーブルに存在しない場合、第２通知を子ノードへ送信しない。
　これにより、例えば、第４実施形態でも、第３実施形態と同様に、複雑な処理を抑制したＴｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎの送信を行うことが可能となる。
（第４実施形態に係る動作例）
　図１６は、第４実施形態に係る動作例を表す図である。
　図１６に示すように、ステップＳ４０において、ＩＡＢノード３００－Ｔは、処理を開始する。
　なお、ＩＡＢノード３００－Ｔは、第３実施形態と同様に、ステップＳ４０とステップＳ４１の間で、ＤＣ設定が行われる。ＩＡＢノード３００－Ｔは、親ノード３００－Ｐ１及び３００－Ｐ２と同時に無線通信が可能となる。
　ステップＳ４１において、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、ＲＬＦを検知する。
　ステップＳ４２において、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴのＲＲＣレイヤは、ＲＬＦから回復したことを示す第２情報を、当該ＩＡＢノード３００－ＴのＩＡＢ－ＤＵのＢＡＰレイヤへ出力する。
　第２情報は、どのリンクのＲＬＦが回復したのかを示す情報が含まれてもよい。具体的には、第２情報は、ＭＣＧで回復したのか、ＭＣＧで回復したのかを示す情報が含まれてもよい。また、第２情報は、回復したＢＨリンクを流出ＢＨリンクとする流出ＢＨリンクＩＤ（ｅｇｒｅｓｓ　ＢＨ　ｌｉｎｋ　ＩＤ）が含まれてもよい。更に、第２情報は、回復したＢＨリンク上のＩＡＢノード３００－Ｔの次ホップＢＡＰアドレス（Ｎｅｘｔ　ｈｏｐ　ＢＡＰ　ａｄｄｒｅｓｓ）が含まれてもよい。第２情報には、ＭＣＧかＳＣＧかを示す情報、流出ＢＨリンクＩＤ、及び次ホップＢＡＰアドレスの少なくともいずれかが含まれてもよい。
　ステップＳ４３において、ＢＡＰレイヤは、第２情報の入力に応じて、使用可能となったルートが存在するか否かを確認する。具体的には、ＢＡＰレイヤは、第２情報に対応する（又は第２情報を含む）ルート情報が、ルーティング設定（又はルーティングテーブル）及び／又はマッピング設定（又はマッピングテーブル）に存在するか否かを確認する。
　第１に、ルーティングテーブルに対する確認は、例えば、以下となる。
　すなわち、ＢＡＰレイヤは、第２情報に対応する（又は第２情報を含む）、ルート情報（ここでは、ルーティングＩＤ及び／又は流出ＢＨリンク）が、ルーティングテーブルに存在するか否かを確認する。
　第２に、マッピングテーブルに対する確認は、例えば、以下となる。
　すなわち、ＢＡＰレイヤは、第２情報に対応する（又は第２情報を含む）、ルート情報（ここでは、流出ＢＨ　ＲＬＣチャネル（ｅｇｒｅｓｓ　ＢＨ　ＲＬＣ　ｃｈａｎｎｅｌ））が、マッピングテーブルに存在するか否かを確認する。
　ステップＳ４４において、ＢＡＰレイヤは、使用可能となったルートがルーティングテーブル及び／又はマッピングテーブルに存在すれば（ステップＳ４４でＹＥＳ）、ステップＳ４５の処理を行う。一方、ステップＳ４４において、ＢＡＰレイヤは、使用可能になったルートがルーティングテーブル及び／又はマッピングテーブルに存在しなければ（ステップＳ４４でＮＯ）、ステップＳ４８の処理を行う。
　使用可能になったルートが存在する場合（ステップＳ４４でＹＥＳ）とは、第２情報に対応する、ルート情報が、ルーティングテーブル及び／又はマッピングテーブルに存在する場合である。例えば、ＲＬＦからの回復がＭＣＧ側で発生した場合、ＭＣＧ側のルート情報が、ルーティングテーブル及び／又はマッピングテーブルに存在する場合である。このような場合、ＢＡＰレイヤは、ステップＳ４５とステップＳ４６を行う。
　一方、使用可能となったルートが存在しない場合（ステップＳ４４でＮＯ）とは、第２情報に対応するルート情報が、ルーティングテーブル及び／又はマッピングテーブルに存在しない場合である。例えば、ＲＬＦからの回復がＭＣＧ側で発生した場合であっても、ＭＣＧ側のルート情報が、ルーティングテーブル及び／又はマッピングテーブルに存在しない場合である。このような場合、ＢＡＰレイヤは、ＲＲＣレイヤから第２情報を受け取っても、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを送信しない。そのため、ＢＡＰレイヤは、ステップＳ４８の処理を行う。
　ステップＳ４５において、ＢＡＰレイヤは、使用不可能なルートを特定する。ＢＡＰレイヤは、下位ノード（例えば、子ノード３００－Ｃ）が把握できるように、使用可能となったルートを特定する。すなわち、ＢＡＰレイヤは、第３実施形態と同様に、ルーティングＩＤ、流入ＢＨリンク（ｉｎｇｒｅｓｓ　ＢＨ　ｌｉｎｋ）、又は流入ＢＨ　ＲＬＣチャネル（ｉｎｇｒｅｓｓ　ＢＨ　ＲＬＣ　ｃｈａｎｎｅｌ）を、使用可能となったルートとして特定してもよい。
　ステップＳ４６において、ＢＡＰレイヤは、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信する。ＢＡＰレイヤは、ステップＳ４５で特定したルートと繋がっている子ノード３００－Ｃのみへ、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを送信してもよい。例えば、ＢＡＰレイヤは、特定した流入ＢＨリンクと繋がっている子ノード３００－Ｃのみへ、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを送信してもよい。この場合、ＢＡＰレイヤは、特定した流入ＢＨリンクと繋がっていない子ノードへ、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信しなくてもよい。
　なお、当該Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎには、使用可能となったルートが付加情報として含まれてもよい。使用可能となったルートとしては、使用可能になったルーティングＩＤなどが含まれる。
　そして、ステップＳ４７において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。
　一方、ステップＳ４８において、ＢＡＰレイヤは、使用不可能なルートが存在しない場合（ステップＳ４４でＮＯ）、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを送信しない。
　そして、ステップＳ４８において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。
（第４実施形態の変形例）
　第３実施形態の変形例と同様に、ステップＳ４３からステップＳ４５の処理を、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵのＦ１ＡＰレイヤが行ってもよい。すなわち、ステップＳ４３からステップＳ４５は、ＢＡＰレイヤに代えて、当該Ｆ１ＡＰレイヤが、同様の処理を行えばよい。この場合、当該Ｆ１ＡＰレイヤは、ステップＳ４５で特定したルート情報を、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵのＢＡＰレイヤへ出力する。そして、ＢＡＰレイヤは、ステップＳ４６以降の処理を行えばよい。
［第５実施形態］
　第３実施形態では、ＩＡＢノード３００－Ｔが、使用不可能なルーティングＩＤを含むＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを子ノード３００－Ｃへ送信してもよいことについて説明した。また、第４実施形態では、ＩＡＢノード３００－Ｔが、使用可能なルーティングＩＤを含むＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを子ノード３００－Ｃへ送信してもよいことについて説明した。
　第５実施形態では、子ノード３００－Ｃが、使用不可能なルーティングＩＤが含むＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信した場合と、使用可能なルーティングＩＤを含むＴｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを受信した場合のＢＡＰレイヤにおける具体的な動作例について説明する。
　具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００－Ｔ）が、無線リンク障害に対して回復試行中であることを示す第１通知（例えば、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎ）を、子ノード（例えば、子ノード３００－Ｃ）へ送信する。第２に、子ノードが、使用不可能な第１ルーティングＩＤを含む第１通知を受信したことに応じて、第１ルーティングＩＤはルーティングテーブルに存在しないものとして第１ルーティング処理を行う。第３に、子ノードが、使用可能な第２ルーティングＩＤを含む第２通知（例えば、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎ）を受信したことに応じて、第２ルーティングＩＤを含むルーティングテーブル内のエントリを用いて第２ルーティング処理を行う。
　これにより、子ノード３００－Ｃは、ＲＬＦにより使用不可能となったルーティングＩＤを含むＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信し、ＲＬＦからの回復により使用可能となったルーティングＩＤを含むＴｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを受信した場合でも、適切に処理を行うことができる。
（第５実施形態に係る動作例）
　図１７（Ａ）と図１７（Ｂ）は第５実施形態に係るノード間の構成例を表す図である。また、図１８は、第５実施形態に係る動作例を表す図である。図１７（Ａ）と図１７（Ｂ）に示す構成例を適宜参照しながら、図１８に示す動作例を説明する。
　図１８に示すように、ステップＳ５０において、子ノード３００－Ｃは、処理を開始する。
　ステップＳ５１において、子ノード３００－ＣのＢＡＰレイヤは、親ノード３００－Ｐ１から、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信する。図１７（Ａ）は、子ノード３００－Ｃが当該Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信する例を表している。当該Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎには、ＲＬＦにより、ルーティング不可能となったルーティングＩＤが付加情報として含まれている。
　図１８に戻り、ステップＳ５２において、子ノード３００－ＣのＢＡＰレイヤは、ルーティングテーブルにおいて、当該エントリが存在しないものとして、ルーティング処理を行う。すなわち、ＢＡＰレイヤは、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎに含まれるルーティングＩＤを含むエントリが、ルーティングテーブルに存在しないもの（又は、使用不可能なエントリ）とみなして、ルーティング処理を行う。この場合、ＢＡＰエントリは、ルーティングテーブルに当該エントリが存在しないため、当該ルーティングＩＤの宛先（Ｄｅｓｔｉｎａｔｉｏｎ）と一致する、ルーティングテーブルのエントリを検索し、当該エントリのルーティングＩＤへ、ローカルリルーティングを行う。第１ルーティング処理は、例えば、このようなローカルリルーティング処理に対応する。図１７（Ａ）は、当該ローカルリルーティング処理により、子ノード３００－Ｃが、親ノード３００－Ｐ２へ、経路を切り替えた例を表している。
　図１８に戻り、ステップＳ５３において、子ノード３００－Ｃは、親ノード３００－Ｐ１から、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを受信する。図１７（Ｂ）は、子ノード３００－Ｃが当該Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを受信する例を表している。当該Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎには、ＲＬＦからの回復により、ルーティング可能となったルーティングＩＤが付加情報として含まれている。
　図１８に戻り、ステップＳ５４において、子ノード３００－Ｃは、当該ルーティングＩＤに該当するエントリをルーティングテーブルから検索し、当該エントリが存在すれば、当該エントリの使用を再開し、通常のルーティング処理を行う。すなわち、子ノード３００－Ｃは、ルーティングテーブルに当該エントリが存在するため、ローカルリルーティング処理を停止し、通常のルーティング処理を行う。図１７（Ｂ）では、子ノード３００－Ｃが、親ノード３００－Ｐ２から親ノード３００－Ｐ１へ経路を切り替える例を表している。
　そして、ステップＳ５５において、子ノード３００－Ｃは、一連の処理を終了する。
［第６実施形態］
　図１９は、第６実施形態に係るノード間の構成例を表す図である。
　図１９に示すように、子ノード３００－Ｃが、親ノード３００－Ｐから、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信した場合を仮定する。この場合、その後、子ノード３００－Ｃが、親ノード３００－Ｐから、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎ又はＴｙｐｅ４　Ｉｎｄｉｃａｔｉｏｎを受信できなかった場合、子ノード３００－Ｃは、どのような処理を行えばよいのか、わからない場合もある。
　これは、親ノード３００－Ｐが、何らかの原因により、Ｔｙｐｅ３　ＩｎｄｉｃａｔｉｏｎとＴｙｐｅ４　Ｉｎｄｉｃａｔｉｏｎとを送信できなかったのかもしれない。また、親ノード３００－Ｐが、Ｔｙｐｅ３　ＩｎｄｉｃａｔｉｏｎとＴｙｐｅ４　Ｉｎｄｉｃａｔｉｏｎとを送信しても、子ノード３００－Ｃが何らかの原因により受信できなかったのかもしれない。
　このような場合、親ノード３００－Ｐの意図と、子ノード３００－Ｃの動作とにミスマッチが生じ、トポロジ全体として意図した動作にならず、効率が悪くなる場合がある。特に、図１９に示すようなシングル接続の場合、子ノード３００－Ｃは、親ノード３００－Ｐへのアップストリーム方向の送信ができなくなってしまう。
　そこで、第６実施形態では、子ノード３００－Ｃは、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信した時にタイマのカウントを開始し、カウント値が所定値に達すると、ＢＨリンクの復旧処理を開始する例について説明する。
　具体的には、第１に、中継ノード（例えば、子ノード３００－Ｃ）が、ドナーノード（例えば、ドナーノード２００）からタイマ値の設定を受ける。第２に、中継ノードが、親ノード（例えば、親ノード３００－Ｐ）から、親ノードのバックホールリンクで発生した無線リンク障害に対して回復試行中であることを示す第１通知（例えば、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎ）を受信する。第３に、中継ノードが、第１通知の受信に応じて、タイマによるカウントを開始する。第４に、中継ノードが、無線リンク障害から回復したことを示す第２通知（例えば、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎ）と、無線リンク障害からの回復に失敗したことを示す第３通知（例えば、Ｔｙｐｅ４　Ｉｎｄｉｃａｔｉｏｎ）のいずれも受信することなく、タイマによるカウント値がタイマ値に達した場合、復旧処理を行う。
　これにより、例えば、親ノード３００－Ｐと子ノード３００－Ｃとの間のミスマッチを抑制し、トポロジ全体として意図した動作に近づけるようにすることが可能となる。
（第６実施形態に係る動作例）
　図２０は、第６実施形態に係る動作例を表す図である。
　図２０に示すように、ステップＳ６０において、子ノード３００－Ｃは、処理を開始する。
　ステップＳ６１において、子ノード３００－Ｃは、ドナーノード２００又は親ノード３００－Ｐから、タイマ値の設定を受信する。子ノード３００－Ｃは、ドナーノード２００から、ＲＲＣメッセージ又はＦ１ＡＰメッセージを利用して当該タイマ値の設定を受信してもよい。また、子ノード３００－Ｃは、親ノード３００－Ｐから、ＢＡＰ　Ｃｏｎｔｒｏｌ　ＰＤＵを利用して当該タイマ値の設定を受信してもよい。
　ステップＳ６２において、子ノード３００－Ｃは、親ノード３００－Ｐから、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信する。子ノード３００－Ｃは、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎの受信に応じて、タイマのカウントを開始する。
　ステップＳ６３において、子ノード３００－Ｃは、親ノード３００－Ｐから、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎ、又はＴｙｐｅ４　Ｉｎｄｉｃａｔｉｏｎを受信したか否かを判定する。子ノード３００－Ｃは、親ノード３００－Ｐから、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎ、又はＴｙｐｅ４　Ｉｎｄｉｃａｔｉｏｎを受信した場合（ステップＳ６３でＹＥＳ）、ステップＳ６４の処理を行う。一方、子ノード３００－Ｃは、親ノード３００－Ｐから、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎ、又はＴｙｐｅ４　Ｉｎｄｉｃａｔｉｏｎを受信しなかった場合（ステップＳ６３でＮＯ）、ステップＳ６６の処理を行う。
　ステップＳ６４において、子ノード３００－Ｃは、タイマのカウントを停止する。
　そして、ステップＳ６５において、子ノード３００－Ｃは、一連の処理を終了する。
　一方、ステップＳ６６において、子ノード３００－Ｃは、タイマのカウント値がタイマ値に達したか（タイマが満了したか）否かを判定する。子ノード３００－Ｃは、タイマのカウント値がタイマ値に達した場合（ステップＳ６６でＹＥＳ）、ステップＳ６７の処理を行う。一方、子ノード３００－Ｃは、タイマのカウント値がタイマ値に達していない場合（ステップＳ６６でＮＯ）、ステップＳ６３へ移行し、上述した処理を繰り返す。
　ステップＳ６７において、子ノード３００－Ｃは、復旧処理を行う。
　復旧処理は、ＲＬＦの宣言（ｄｅｃｌａｒｅ）であってもよい。例えば、子ノード３００－Ｃは、親ノード３００－ＰのＢＨリンクで発生したＲＬＦについて、当該ＲＬＦの宣言を行ってもよい。
　また、復旧処理は、ＲＲＣ再確立（ＲＲＣ　Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）手順の実行であってもよい。例えば、子ノード３００－Ｃは、親ノード３００－Ｐに対して、ＲＲＣ再確立手順を開始してもよい。
　更に、復旧処理は、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎに含まれる付加情報に応じたＭＣＧ失敗情報（ＭＣＧ　Ｆａｉｌｕｒｅ　Ｉｎｆｏｒｍａｔｉｏｎ）手順又はＳＣＧ失敗情報（ＳＣＧ　Ｆａｉｌｕｒｅ　Ｉｎｆｏｒｍａｔｉｏｎ）手順の実行であってもよい。例えば、子ノード３００－Ｃは、当該付加情報としてＭＣＧ側でのＲＬＦを示す情報が含まれる場合、ＭＣＧ失敗情報手順を実行し、当該付加情報としてＳＣＧ側でのＲＬＦを示す情報が含まれる場合、ＳＣＧ失敗情報手順を実行してもよい。
　そして、ステップＳ６５において、子ノード３００－Ｃは、一連の処理を終了する。
［第７実施形態］
　３ＧＰＰでは、複数のＩＡＢノード３００によって形成されたネットワーク（又はトポロジ）において、どのようにリルーティングを行うのかについての検討が行われている。
　現在、ルーティングとリルーティングに関して、以下のシナリオがある。
（Ｓ１）ＣＵ内／ドナーＤＵ内（Ｉｎｔｒａ－ＣＵ／Ｉｎｔｒａ－ｄｏｎｏｒ－ＤＵ）
　（Ｓ１－１）ルーティング
　（Ｓ１－２）リルーティング
（Ｓ２）ＣＵ内／ドナーＤＵ間（Ｉｎｔｒａ－ＣＵ／Ｉｎｔｅｒ－ｄｏｎｏｒ－ＤＵ）
　（Ｓ２－１）ルーティング
　（Ｓ２－２）リルーティング
（Ｓ３）ＣＵ間（Ｉｎｔｅｒ－ＣＵ）
　（Ｓ３－１）ルーティング
　（Ｓ３－２）リルーティング
　このようなシナリオを考慮した上で、各シナリオに共通の手順又は処理を検討したり、各シナリオ個別の手順又は処理を検討したりすることで、トポロジにおける、パケット転送の信頼性、柔軟性、及び低遅延性を向上させることが期待される。
　なお、ルーティングとは、例えば、受信したパケットをどのＩＡＢノード３００へ転送するかを制御することである。
　ここでは、リルーティングに着目して、各シナリオについて説明する。
（Ｓ１）「ＣＵ内／ドナーＤＵ内」シナリオについて
　図２１（Ａ）は、「ＣＵ内／ドナーＤＵ内」シナリオにおけるトポロジの構成例を表している。
　当該シナリオにおけるリルーティング（Ｓ１－２）は、所謂、ローカルリルーティングである。例えば、ＩＡＢノード３００－１が、ＩＡＢノード３００－２に対するＢＨ　ＲＬＦを検出したとき、アップリンク方向のパケットについて、代替パスであるＩＡＢノード３００－３を介した経路に切り替えて、リルーティングを行う。
（Ｓ２）「ＣＵ内／ドナーＤＵ間」シナリオについて
　図２１（Ｂ）は、「ＣＵ内／ドナーＤＵ間」シナリオにおけるトポロジの構成例を表す図である。
　ＩＡＢノード３００－１におけるリルーティングに関しては、例えば、ＩＡＢノード３００－２経由の経路から、ＩＡＢノード３００－３経由の経路（代替パス）に切り替えたと仮定する。この場合、当該パケットの宛先となるドナーＤＵが、ドナーＤＵ＃１（２００Ｄ１）からドナーＤＵ＃２（２００Ｄ２）へ変更される。すなわち、パケットの宛先ＢＡＰアドレスが変更される。そのため、３ＧＰＰでは、当該シナリオで、ＢＡＰヘッダの書き替えを行うことが合意された。ＢＡＰヘッダの書き替えは、直前のルーティングＩＤ（ｐｒｅｖｉｏｕｓ　ｒｏｕｔｉｎｇ　ＩＤ）から新たなルーティングＩＤ（ｎｅｗ　ｒｏｕｔｉｎｇ　ＩＤ）へのＢＡＰヘッダを書き替えることである。
（Ｓ３）「ＣＵ間」シナリオについて
　図２１（Ｃ）は「ＣＵ間」シナリオにおけるトポロジの構成例を表す図である。
　図２１（Ｃ）に示すように、当該シナリオでは、ドナーＣＵ＃１（２００Ｃ１）とドナーＣＵ＃２（２００Ｃ２）の２つの異なるＣＵが設けられる。そして、ドナーＣＵ＃１（２００Ｃ１）にはドナーＤＵ＃１（２００Ｄ１）が接続され、ドナーＣＵ＃２（２００Ｃ２）にはドナーＤＵ＃２（２００Ｄ２）が接続される構成となっている。
　一般的に、異なるドナーＣＵにより、異なるトポロジが形成される。すなわち、ドナーＣＵ＃１（２００Ｃ１）からＩＡＢノード３００－１へ至る経路で形成されたトポロジ（第１トポロジ）と、ドナーＣＵ＃２（２００Ｃ２）からＩＡＢノード３００－１へ至る経路で形成されたトポロジ（第２トポロジ）とは異なるトポロジとなり得る。ＩＡＢノード３００－１は、２つの異なるトポロジの境界に位置する。このようなＩＡＢノード３００－１を境界ＩＡＢノード（ｂｏｕｎｄａｒｙ　ｎｏｄｅ）と称する場合がある。
　当該シナリオのリルーティングに関しては、例えば、境界ＩＡＢノード３００－１は、ドナーＣＵ＃２（２００Ｃ２）におけるトポロジ上の代替パスを介して、ドナーＤＵ＃１（２００Ｄ１）宛てのパケットを転送することができる。
　ただし、当該シナリオのリルーティングに関して、３ＧＰＰでは、境界ＩＡＢノード３００－１において、ソースドナーノードであるドナーＣＵ＃１（２００Ｃ１）とはＦ１接続を残したまま、ターゲットのドナーノードであるドナーＣＵ＃２（２００Ｃ２）に対してＲＲＣ再確立（ＲＲＣ　Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）状態で適用されてもよい、ことが合意された。
（第７実施形態に係る通信制御方法）
　第１実施形態で説明した動作例、処理などは、シナリオ（Ｓ１－２）、シナリオ（Ｓ２－２）、及びシナリオ（Ｓ３－２）に適用可能である。
　第１実施形態をシナリオ（Ｓ２－２）に適用した場合は、例えば、以下となる。すなわち、図２１（Ｂ）に示すように、ＩＡＢノード３００－４及びＩＡＢノード３００－５は、ＩＡＢノード３００－１から、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信する。Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎには、第１実施形態で説明した付加情報が含まれる。また、ＩＡＢノード３００－４及びＩＡＢノード３００－５は、ＩＡＢノード３００－１から、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを受信する。Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎには、第１実施形態で説明した付加情報が含まれる。
　また、第１実施形態をシナリオ（Ｓ２－３）に適用した場合は、例えば、以下となる。すなわち、図２１（Ｃ）に示すように、ＩＡＢノード３００－４では、ＩＡＢノード３００－１から、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信する。Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎには、第１実施形態で説明した付加情報が含まれる。また、ＩＡＢノード３００－４は、ＩＡＢノード３００－１から、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを受信する。Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎには、第１実施形態で説明した付加情報が含まれる。
　第２実施形態で説明した動作例、処理なども、シナリオ（Ｓ３－２）に適用可能である。なお、シナリオ（Ｓ２－２）は、第２実施形態で説明したため説明を割愛する。
　第２実施形態をシナリオ（Ｓ３－２）に適用した場合は、例えば、以下となる。すなわち、図２１（Ｃ）に示すように、ＩＡＢノード３００－１は、ＩＡＢノード３００－２との間のＢＨリンクにおけるＲＬＦを検知する。ＩＡＢノード３００－１は、ルーティングが不可能なルーティングＩＤの宛先（Ｄｅｓｔｉｎａｔｉｏｎ）として、ドナーＤＵ＃１（２００Ｄ１）のＢＡＰアドレスを確認する。そして、ＩＡＢノード３００－１は、当該ＢＡＰアドレスを含むＴｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを、ＩＡＢノード３００－４へ送信する。
　第３実施形態で説明した動作例、処理などは、シナリオ（Ｓ１－２）、シナリオ（Ｓ２－２）、及びシナリオ（Ｓ３－２）に適用可能である。すなわち、ＩＡＢノード３００－１は、例えば、ＩＡＢノード３００－２との間のＢＨリンクでのＲＬＦを検知した場合、ＲＬＦによって使用不可能なルート情報がルーティングテーブル及び／又はマッピングテーブルに存在しなければ、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを、下位ノードへ送信しない。ＩＡＢノード３００－１は、ＲＬＦによって使用不可能なルート情報がルーティングテーブル及び／又はマッピングテーブルに存在すれば、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを、下位ノードへ送信する。
　第４実施形態で説明した動作例、処理などは、シナリオ（Ｓ１－２）、シナリオ（Ｓ２－２）、及びシナリオ（Ｓ３－２）に適用可能である。すなわち、ＩＡＢノード３００－１は、例えば、ＩＡＢノード３００－２との間のＢＨリンクでのＲＬＦからの回復を検知した場合、回復によって使用可能となったルート情報がルーティングテーブル及び／又はマッピングテーブルに存在しなければ、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを、下位ノードへ送信しない。ＩＡＢノード３００－１は、当該回復によって使用可能となったルート情報がルーティングテーブル及び／又はマッピングテーブルに存在すれば、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを、下位ノードへ送信する。
　第５実施形態で説明した動作例、処理なども、シナリオ（Ｓ１－２）、シナリオ（Ｓ２－２）、及びシナリオ（Ｓ３－２）に適用可能である。すなわち、ＩＡＢノード３００－４は、ＩＡＢノード３００－１からＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信する。付加情報として、ＲＬＦにより使用不可能となったルーティングＩＤが含まれる場合、ＩＡＢノード３００－４は、当該ルーティングＩＤを含むエントリがルーティングテーブルに存在しないものとして、第１ルーティング処理を行う。また、ＩＡＢノード３００－４は、ＩＡＢノード３００－１からＴｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを受信する。付加情報として、ＲＬＦからの回復により使用可能となったルーティングＩＤが含まれる場合、ＩＡＢノード３００－４は、ルーティングテーブルに含まれる当該エントリを利用して、第２ルーティング処理を行う。
　第６実施形態で説明した動作例、処理なども、シナリオ（Ｓ１－２）、シナリオ（Ｓ２－２）、及びシナリオ（Ｓ３－２）に適用可能である。すなわち、ＩＡＢノード３００－４は、ＩＡＢノード３００－１からＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信したときにタイマのカウントを開始し、カウント値がタイマ値に達した場合、復旧処理を行う。
［第８実施形態］
　上述した実施形態では、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎの受信により、ローカルリルーティングを開始（又はトリガ）したり、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎの受信により、ローカルリルーティングの動作を停止したりする例について説明した。
　ＩＡＢノード３００は、ローカルリルーティングのトリガ及び停止をドナーノード２００へ報告してもよい。
　当該報告には、トリガ又は停止の原因を示す原因情報を含んでもよい。当該原因情報は、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎに含まれる付加情報（第１実施形態、第２実施形態、及び第５実施形態）であってもよいし、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎに含まれる付加情報（第１実施形態）であってもよい。
　当該報告は、ローカルリルーティングのトリガ又は停止を行ったルートの情報を含んでもよい。当該ルート情報は、ルーティングＩＤ又はＢＨ　ＲＬＣチャネルＩＤであってもよい。
　ＩＡＢノード３００は、当該報告をローカルリルーティングのトリガ又は停止に伴い、即座にドナーノード２００へ送信してもよい。又は、ＩＡＢノード３００は、当該報告を事後に送信してもよい。事後に送信する場合、ＩＡＢノード３００は、ローカルリルーティングのトリガ及び停止に伴い、当該トリガ又は停止、前記原因情報、前記ルート情報を記録（ログ）してもよい。ＩＡＢノード３００は、ドナーノード２００からの要求に伴い、当該記録（ログ）を、当該報告としてドナーノード２００へ送信してもよい。
［その他の実施形態］
　第１実施形態から第８実施形態で説明した各実施形態、各動作例、各処理、又は各ステップは、相互に組み合わせることが可能である。第１実施形態から第８実施形態の各実施形態の全部又は一部は矛盾しない範囲で組み合わせることが可能である。このような組み合わせにより、全てのシナリオにおいて手順又は処理の共通化を図ることができる場合もある。
　ＵＥ１００又はｇＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。
　また、ＵＥ１００又はｇＮＢ２００が行う各処理を実行する回路を集積化し、ＵＥ１００又はｇＮＢ２００の少なくとも一部を半導体集積回路（チップセット、ＳｏＣ）として構成してもよい。
　以上、図面を参照して一実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
　本開示で使用されている「に基づいて（ｂａｓｅｄ　ｏｎ）」、「に応じて（ｄｅｐｅｎｄｉｎｇ　ｏｎ）」という記載は、別段に明記されていない限り、「のみに基づいて」、「のみに応じて」を意味しない。「に基づいて」という記載は、「のみに基づいて」及び「に少なくとも部分的に基づいて」の両方を意味する。同様に、「に応じて」という記載は、「のみに応じて」及び「に少なくとも部分的に応じて」の両方を意味する。また、「取得する（ｏｂｔａｉｎ／ａｃｑｕｉｒｅ）」は、記憶されている情報の中から情報を取得することを意味してもよく、他のノードから受信した情報の中から情報を取得することを意味してもよく、又は、情報を生成することにより当該情報を取得することを意味してもよい。「含む（ｉｎｃｌｕｄｅ）」、「備える（ｃｏｍｐｒｉｓｅ）」、及びそれらの変形の用語は、列挙する項目のみを含むことを意味せず、列挙する項目のみを含んでもよいし、列挙する項目に加えてさらなる項目を含んでもよいことを意味する。また、本開示において使用されている用語「又は（ｏｒ）」は、排他的論理和ではないことが意図される。さらに、本開示で使用されている「第１」、「第２」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみがそこで採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。本開示において、例えば、英語でのａ，ａｎ，及びｔｈｅのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。
　本願は、米国仮出願第６３／２５７２４６号（２０２１年１０月１９日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
（付記）
　導入
　ｅＩＡＢ（Ｅｎｈａｎｃｅｍｅｎｔｓ　ｔｏ　Ｉｎｔｅｇｒａｔｅｄ　Ａｃｃｅｓｓ　ａｎｄ　Ｂａｃｋｈａｕｌ　ｆｏｒ　ＮＲ）は、ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎとローカルリルーティングのサポートを含むトポロジ適応の強化を目的としている。
　本付記では、Ｔｙｐｅ２／３ＢＨ　ＲＬＦの詳細について説明する。
　議論
　二重接続方式の場合のＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎの送信
　ＲＡＮ２＃１１４－ｅにおいて、ＲＡＮ２はＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎのトリガ条件について以下のように合意した。
　Ｔｙｐｅ２のＲＬＦ　Ｉｎｄｉｃａｔｉｏｎを生成するトリガは、ＲＬＦ検出時である。更なる検討は、シングル接続と二重接続の両方のケースに必要である。
　親ノードとのシングル接続の場合、合意は非常に簡単である。一方、２つの親ノードとの二重接続の場合、どのようにＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信するか、さらに議論すべきである。
　ＲＡＮ２＃１１３－ｅにおいて、子ノードの観点からのＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎのユースケースが以下のように合意された。
　　ＲＡＮ２はＴｙｐｅ２／３のＲＬＦ　Ｉｎｄｉｃａｔｉｏｎをサポートする（規定されたる動作、ＴＳの影響、詳細については更なる検討が必要である）。
　　Ｔｙｐｅ２のＲＬＦ　Ｉｎｄｉｃａｔｉｏｎは、ローカルリルーティングをトリガすることができる。
　　Ｔｙｐｅ２のＲＬＦ　Ｉｎｄｉｃａｔｉｏｎは、ＳＩＢでサポートされるＩＡＢの無効化のトリガすることができる。
　　Ｔｙｐｅ２のＲＬＦ　Ｉｎｄｉｃａｔｉｏｎは、ＳＲやＢＳＲの送信の停止や削減のトリガとして使用することができる。
　上記の合意事項の文脈では、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信した子ノードが、当該ＩＡＢノードでのＢＨ　ＲＬＦにより、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信した当該ＩＡＢノードにアップストリームパケットを転送しないことは、予想される動作と考えることができる。これは、「親ノードが２つあるＩＡＢノードが（ＤＣを介して）一方の親ノードからＴｙｐｅ２のＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎを受信した場合、ＩＡＢノードはもう一方の親ノードへのローカルリルーティングをトリガしてもよい」という合意とも一致するものである。
　所見１：親ノードがシングルＢＨ接続の場合、子ノードはＴｙｐｅ２　ＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎを送信したＩＡＢノードへアップストリームパケットを転送することは期待できない場合がある。
　図２２の（ｂ）に示すように、当該ＩＡＢノードが二重接続方式を持つ場合、Ｒｅｌ－１６の動作としてローカルリルーティングを実行することがあるため、所見１は常に正しいわけではない。
　注：ＲＬＣ－ＡＭエンティティが確認応答を受信するまでのＢＡＰエンティティ送信部でのデータバッファリングは、実装次第である。ＢＨ　ＲＬＦの場合、ＢＡＰエンティティの送信部は、ＢＨ　ＲＬＦの前に下位レイヤで確認されなかったＢＡＰデータＰＤＵを代替パスにリルーティングさせてもよい。
　したがって、ＭＣＧのＢＨ　ＲＬＦの後でも代替パスがある場合、当該ＩＡＢノードがＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信すべきかどうかについては疑問が残る。ＭＣＧ障害情報手順の間、当該ＩＡＢノードはローカルリルーティングを継続する可能性があることに注意するべきである。
　所見２：子ノードは、親ノード（当該ＩＡＢノード）がローカルリルーティングを実行できる場合、つまり二重接続のために、アップストリームパケットを転送することがある。
　ＥＮ－ＤＣのもう１つのシナリオも検討に値する。ＥＮ－ＤＣでは、ＭＣＧリンク（つまりＭｅＮＢ）は制御プレーンのシグナリングのためにのみ使用され、データは常にＳＣＧリンク（つまりＳｇＮＢ）を介して転送される。この場合、ＳＣＧ　ＲＬＦは子ノードのパケット転送に直接影響を与えるため、当該ＩＡＢノードは子ノードに対してＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信する必要がある。一方、ＭＣＧ　ＲＬＦ（ＬＴＥリンク）の場合は、その後のＲＲＣ接続再確立手順の間、ＳＣＧリンクはまだ使用可能であり、再確立に失敗した場合はＲｅｌ－１６と同様にＴｙｐｅ４　Ｉｎｄｉｃａｔｉｏｎが送信されるため、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎが必要ない場合がある。
　所見３：ＥＮ－ＤＣでは、ＭＣＧ（つまりＬＴＥリンク）を介してローカルリルーティングを行うことができないため、ＳＣＧ　ＲＬＦ（つまりＮＲリンク）の際にＴｙｐｅ２のＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎを送信する必要がある。
　所見４：ＥＮ－ＤＣでは、パケット転送は常にＳＣＧ（すなわちＮＲリンク）を介して行われるため、ＭＣＧ　ＲＬＦ（すなわちＬＴＥリンク）の際にＴｙｐｅ２のＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎを送信する必要はない。
　上記の所見を考慮すると、ＢＨ　ＲＬＦによって少なくとも１つのルートが利用できない場合、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎが送信されるというのがシンプルな解決策であると考えられる。この解決策は、シングル接続と二重接続の両方の場合、またＮＲ－ＤＣとＥＮ－ＤＣの両方をカバーすることができる。例えば、シングルコネクションのＢＨ　ＲＬＦでは、すべてのルートが使用できなくなる。ＥＮ－ＤＣでは、ＭＣＧ　ＲＬＦはどのルートにも影響を与えず、ＳＣＧ　ＲＬＦはすべてのルートを使用不可にする。ＮＲ－ＤＣでは、ＢＨ　ＲＬＦは、ＢＨリンクとルートのマッピングによって、いくつかのルートに影響を与える場合と与えない場合がある。そのため、ＲＡＮ２はＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎのトリガ条件について、この統一された動作に合意すべきである。。
　提案１：ＲＡＮ２は、ＩＡＢノードがシングル接続か二重接続（ＥＮ－ＤＣを含む）かを問わず、ＢＨ　ＲＬＦ時に少なくとも１つのルートが利用できない場合にＴｙｐｅ２のＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎが送信されることに合意すべきである。。
　Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎ受信時の部分的なローカルリルーティング
　二重接続方式を持つ子ノードがＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信したときにどのように動作するかを検討する必要がある。親ノード（当該ＩＡＢノード）がＢＨ　ＲＬＦを検出したが、まだローカルリルーティングを実行できる場合、二重接続の子ノードには、以下のいくつかの動作の選択肢がある（図２３参照）。
　選択肢Ａ：すべてのアップストリームトラフィックがこの親ノードに残り、子ノードでのローカルリルーティングはない。
選択肢Ｂ：アップストリームトラフィックの一部が別の親ノードにリルートされる、つまり、「部分的」なローカルリルーティングである。
　選択肢Ａは単純な動作だが、ＢＨ　ＲＬＦによって親ノードがＭＣＧ又はＳＣＧのどちらかのリンクを失うため、親ノードに過負荷が発生する可能性がある。一方、選択肢Ｂは、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎが追加情報を伝える必要があるが、子ノードの２つの親ノードに負荷を分散することができる。そのため、選択肢Ｂはトポロジー全体のパフォーマンスを向上させるために有効であると予想される。
　所見５：Ｔｙｐｅ２のＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎを受信すると、子ノードはより良い負荷分散のために「部分的な」ローカルリルーティングを実行するかどうかの選択肢を持つことができる（すなわち、選択肢Ｂ）。
　提案２：ＲＡＮ２は、二重接続の親ノードがＢＨ　ＲＬＦを経験した場合、子ノード（すなわち選択肢Ｂ）で「部分的な」ローカルリルーティングを実行するかどうかを議論すべきである。
　提案２のように部分的なリルーティング（つまり選択肢Ｂ）が好ましい動作である場合、子ノードはどのトラフィックが元のルートに残れるか、どのトラフィックをローカルリルーティングの対象とすべきかを判断しなければならないため、どのルートが利用できないかを知る必要がある。Ｔｙｐｅ２　ＩｎｄｉｃａｔｉｏｎにＢＨ　ＲＬＦのために利用できないルーティングＩＤが含まれている場合は、容易に知ることができる。Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信した子ノードは、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎで通知されたルーティングＩＤを使用不可とみなし、子ノードのＢＡＰレイヤがローカルリルーティングを実行する。そのため、ＲＡＮ２は関係するノードと子ノードでこれらの動作に合意すべきである。
　提案３：ＲＡＮ２は、Ｔｙｐｅ２のＢＨ　ＲＬＦ　ＩｎｄｉｃａｔｉｏｎがＢＨ　ＲＬＦのために利用できないルーティングＩＤを示すことに合意すべきである。
　提案４：ＲＡＮ２は、受信したＴｙｐｅ２のＢＨ　ＲＬＦ　ＩｎｄｉｃａｔｉｏｎでルーティングＩＤが示された場合、子ノードがルーティングＩＤを利用できないものとみなすことに合意すべきである。
　Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎのためのドナーの制御性
　Ｔｙｐｅ２の表示で最も有望なユースケースは、ＲＡＮ２が合意したように、子ノードがローカルリルーティングを実行することである。ＲＡＮ２＃１１４－ｅでは、Ｒｅｌ－１６と同様に、Ｔｙｐｅ４の指示によって子ノードがＢＨ　ＲＬＦを宣言し、最終的にローカルリルーティングを行うため、Ｔｙｐｅ２とＴｙｐｅ４がどのように連動するかが議論された。Ｔｙｐｅ２受信時のローカルリルーティングは提供者が設定可能であると指摘されている。提供者はトポロジ全体の目的を管理し、トポロジ全体の最新のパフォーマンスを知っているため、これは理にかなっている。
　提案５：ＲＡＮ２は、Ｔｙｐｅ２のＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎの受信時にローカルリルーティングを実行するかどうか、ドナーがＩＡＢノードを設定することに合意すべきである。
　さらに、ＢＨ　ＲＬＦが検出されたときにＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを送信するかどうかを、提供者が当該ＩＡＢノードに対して設定できるようにする必要がある。例えば、当該ＩＡＢノードがＲｅｌ－１７の機能を実装し、その子ノードがＲｅｌ－１６のみをサポートする場合（「混合」配置）、提供者はこれをオフにすることができる。
　提案６：ＲＡＮ２は、ドナー側がＩＡＢノードに対して、そのＢＨ　ＲＬＦの検出時にＴｙｐｅ２のＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎを送信するかどうかを設定することに合意すべきである。。
　シングル接続及び二重接続の場合におけるＴｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎ
　ＲＡＮ２＃１１４－ｅにおいて、ＲＡＮ２はＴｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎのトリガ条件について以下のように合意した。
　Ｔｙｐｅ３のＲＬＦ　Ｉｎｄｉｃａｔｉｏｎの送信のトリガは、ＢＨ　ＲＬＦ後の正常な回復である。シングル接続、二重接続のいずれでも更なる検討が必要である。
　Ｔｙｐｅ３はＴｙｐｅ２の受信によって開始された子ノードの動作を元に戻すというのが共通の認識であると考えられる。そのため、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎは子ノードがＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信した場合のみ有効である。Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎのみがこれらのケースに依存するため、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎに関するこのような条件は、例えば上記の提案１のように、シングル接続と二重接続の両方に共通して適用可能である。
　提案７：ＲＡＮ２は、合意された動作、すなわちＢＨ　ＲＬＦの回復に成功した場合に加え、Ｔｙｐｅ２のＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎを送信した場合にのみ、Ｔｙｐｅ３のＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎを送信することをシングル接続及び二重接続ケースに共通するものとして合意すべきである。
　提案１が合意できるのであれば、少なくとも１つのルートがＢＨ　ＲＬＦ回復の成功により再利用可能になったとき、つまり状態が「利用不可」から「利用可能」に変化したときにのみ、Ｔｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎを送信するのが妥当であろう。この動作は、提案と同様に、ＮＲ－ＤＣとＥＮ－ＤＣを含むシングル接続と二重接続のケースに適用することができる。
　提案８：ＲＡＮ２は、ＢＨ　ＲＬＦの回復に成功し少なくとも１つのルートが再利用可能になると、Ｔｙｐｅ３のＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎが送信されることに合意するべきである。
　また、提案３に合意できる場合は、再利用可能になったルーティングＩＤを子ノードにも通知する必要がある。子ノードはこれらのルーティングＩＤをルーティング可能であるとみなし、該当するトラフィックのローカルリルーティングを停止させる。
　提案９：ＲＡＮ２は、Ｔｙｐｅ３のＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎが、ＢＨ　ＲＬＦ回復の成功により再利用可能となったルーティングＩＤを示すことに合意すべきである。
　提案１０：ＲＡＮ２は、受信したＴｙｐｅ３のＢＨ　ＲＬＦ　ＩｎｄｉｃａｔｉｏｎでルーティングＩＤが示された場合、子ノードがルーティングＩＤを利用できるとみなすことに合意すべきである。
　Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎの伝播
　Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎのプロパゲーションは、負荷分散やサービス中断の低減など、より良いトポロジ管理を提供することを目的としている。
　具体的には、様々な提案がされている。そのうちの１つは、ＩＡＢノードがＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを受信し、代替パスがない場合、Ｔｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎを転送するものであり、これは主に提案１の選択肢１によるＩＡＢノードの動作と一致するものである。言い換えれば、この条件は、提案２の部分的なローカルリルーティングを含め、ＩＡＢノードがローカルリルーティングを行わない条件と解釈することも可能である。もう一つの選択肢は、安定したトポロジ管理のために期待されるＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎの伝搬を１ホップのみに制限することである。二重接続の場合、つまり提案１ではＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎがどのように送信されるか、また子ノードでの「部分的」なローカルリルーティングを考慮するか、つまり提案２に依存することに変わりはない。そのため、詳細は現時点では更なる検討が必要としておくべきである。
　提案１１：ＲＡＮ２は、子孫ノードへのＴｙｐｅ２　Ｉｎｄｉｃａｔｉｏｎの伝搬がサポートされることに合意すべきである。ＩＡＢノードがローカルリルーティングを行わない場合のみ転送するなど、詳細な条件について更なる検討を行う。
　Ｔｙｐｅ２　ＩｎｄｉｃａｔｉｏｎによるＳＲやＢＳＲの無効化又は削減
　ＲＡＮ２は「Ｔｙｐｅ２ＲＬＦ　ＩｎｄｉｃａｔｉｏｎはＳＲやＢＳＲの送信を停止又は削減するために使用できる」と合意したが、この合意をどのように扱うかについては議論されていない。これはＩＡＢ－ＭＴの動作と考えられるため、明確に規定されるべきである。非活性化・削減については、「非活性化」の方が仕様的にはシンプルかもしれない。しかし、それはＳＲやＢＳＲがＴｙｐｅ３　Ｉｎｄｉｃａｔｉｏｎの受信後にのみ送信できることを意味し、スケジューリングの遅延を引き起こす可能性がある。一方、「低減」は、不必要な干渉を引き起こす可能性はあるが、ＢＨリンクが回復した直後にスケジューリングを再開することができる場合がある。そこで、ＲＡＮ２は、ＳＲ及び／又はＢＳＲの「非活性化」、「低減」、又はその両方をサポートするかどうかを議論すべきである。両方がサポートされる場合、ＩＡＢドナーによって設定可能であるべきである。さらに、「縮小」がサポートされる場合、ＳＲ及び／又はＢＳＲの縮小がどのように処理されるべきかについては不明確である。禁止タイマの概念を再利用することも考えられるが、現時点では更なる検討が必要であるとして残すべきである。
　提案１２：ＲＡＮ２は、Ｔｙｐｅ２のＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎを受信した場合、ＩＡＢ－ＭＴがＳＲ及び／又はＢＳＲ送信を停止又は削減することを規定することに合意すべきである。
　提案１３：ＲＡＮ２は、Ｔｙｐｅ２のＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎを受信したときに、ＳＲ及び／又はＢＳＲの「非活性化」、「低減」、又はその両方をサポートするかどうか（つまり、設定可能かどうか）を議論すべきである。

Claims (11)

  1. 　セルラ通信システムで用いる通信制御方法であって、
    　中継ノードが、マスターセルグループを管理する第１親ノードをマスターノードとし、セカンダリセルグループを管理する第２親ノードをセカンダリノードとして、二重接続方式が設定されることと、
    　前記中継ノードが、前記第１親ノードとの間の第１バックホールリンクと、前記第２親ノードとの間の第２バックホールリンクのうちの一方のリンク上に無線リンク障害を検知した場合、前記無線リンク障害の検知を示す第１通知を、子ノードへ送信することと、
    　前記中継ノードが、前記第１通知を送信した後、前記無線リンク障害から回復した場合、前記無線リンク障害から回復したことを示す第２通知を、前記子ノードへ送信することと、を有する。
    　通信制御方法。
  2. 　セルラ通信システムで用いる通信制御方法であって、
    　中継ノードが、マスターセルグループを管理する第１親ノードをマスターノードとし、セカンダリセルグループを管理する第２親ノードをセカンダリノードとして、二重接続方式が設定されるステップと、
    　前記中継ノードが、前記第１親ノードとの間の第１バックホールリンクと、前記第２親ノードとの間の第２バックホールリンクのうち、少なくともいずれかで発生した無線リンク障害から回復したことを示す第２通知を、前記子ノードへ送信するステップと、を有し、
    　前記第２通知は、第２付加情報を含み、前記第２付加情報は、少なくとも、使用可能な第２ルーティングＩＤを含む、
    　通信制御方法。
  3. 　前記第２付加情報は、使用可能なセルグループ、使用可能な品質、及び使用可能なバックホールＲＬＣチャネルの少なくともいずれかを含む、
    　請求項２記載の通信制御方法。
  4. 　更に、前記中継ノードが、前記無線リンク障害に対して回復試行中であることを示す第１通知を、前記子ノードへ送信するステップを有し、
    　前記第１通知は、第１付加情報を含み、前記第１付加情報は、少なくとも、使用不可能なバックホールＲＬＣチャネルＩＤを含む、
    　請求項２記載の通信制御方法。
  5. 　更に、前記中継ノードが、前記無線リンク障害に対して回復試行中であることを示す第１通知を、前記子ノードへ送信するステップと、
    　前記子ノードが、使用不可能となった第１ルーティングＩＤを含む前記第１通知を受信したことに応じて、前記第１ルーティングＩＤはルーティングテーブルに存在しないものとして第１ルーティング処理を行うステップと、
    　前記子ノードが、使用可能な第２ルーティングＩＤを含む前記第２通知を受信したことに応じて、前記第２ルーティングＩＤを含む前記ルーティングテーブル内のエントリを用いて第２ルーティング処理を行うステップと、を有する、
    　請求項２記載の通信制御方法。
  6. 　セルラ通信システムで用いる通信制御方法であって、
    　中継ノードが、親ノードとの間のバックホールリンクで発生した無線リンク障害により、使用不可能となったルーティングＩＤに含まれる宛先ＢＡＰアドレスを確認するステップと、
    　前記中継ノードが、前記無線リンク障害に対して回復試行中であることを示す第１通知を、子ノードへ送信するステップと、を有し、
    　前記第１通知は、付加情報を含み、前記付加情報は、前記宛先ＢＡＰアドレスを含む、
    　通信制御方法。
  7. 　セルラ通信システムで用いる通信制御方法であって、
    　中継ノードが、マスターセルグループを管理する第１親ノードをマスターノード、セカンダリセルグループを管理する第２親ノードをセカンダリノードとして、二重接続方式が設定されるステップと、
    　前記中継ノードが、前記第１親ノードとの間の第１バックホールリンクと、前記第２親ノードとの間の第２バックホールリンクのうち、少なくともいずれかで発生した無線リンク障害を検知するステップと、
    　前記中継ノードが、前記無線リンク障害により使用不可能なルートを示す第１ルート情報がルーティングテーブル及び／又はマッピングテーブルに存在する場合、前記無線リンク障害に対して回復試行中であることを示す第１通知を子ノードへ送信し、前記第１ルート情報が前記ルーティングテーブル及び／又はマッピングテーブルに存在しない場合、前記第１通知を前記子ノードへ送信しないステップと、を有する、
    　通信制御方法。
  8. 　更に、前記中継ノードが、前記無線リンク障害から回復したことを検知するステップと、
    　前記中継ノードが、前記無線リンク障害からの回復により使用することが可能となったルートを示す第２ルート情報がルーティングテーブル及び／又はマッピングテーブル存在する場合、前記無線リンク障害から回復したことを示す第２通知を前記子ノードへ送信し、前記第２ルート情報がルーティングテーブル及び／又はマッピングテーブルに存在しない場合、前記第２通知を前記子ノードへ送信しないステップと、を有する、
    　請求項７記載の通信制御方法。
  9. 　セルラ通信システムで用いる通信制御方法であって、
    　中継ノードが、ドナーノードからタイマ値の設定を受けるステップと、
    　前記中継ノードが、親ノードから、前記親ノードのバックホールリンクで発生した無線リンク障害に対して回復試行中であることを示す第１通知を受信するステップと、
    　前記中継ノードが、前記第１通知の受信に応じて、タイマによるカウントを開始するステップと、
    　前記中継ノードが、前記無線リンク障害から回復したことを示す第２通知と、前記無線リンク障害からの回復に失敗したことを示す第３通知のいずれも受信することなく、前記タイマによるカウント値が前記タイマ値に達した場合、復旧処理を行うステップと、を有する、
    　通信制御方法。
  10. 　更に、前記中継ノードが、前記第２通知と前記第３通知のいずれかを受信したことに応じて、前記タイマのカウントを停止するステップを有する、
    　請求項９記載の通信制御方法。
  11. 　セルラ通信システムで用いる中継ノードであって、
    　マスターセルグループを管理する第１親ノードをマスターノードとし、セカンダリセルグループを管理する第２親ノードをセカンダリノードとして、二重接続方式が設定される処理と、
    　前記第１親ノードとの間の第１バックホールリンクと、前記第２親ノードとの間の第２バックホールリンクのうちの一方のリンク上に無線リンク障害を検知した場合、前記無線リンク障害の検知を示す第１通知を、子ノードへ送信する処理と、
    　前記中継ノードが、前記第１通知を送信した後、前記無線リンク障害から回復した場合、前記無線リンク障害から回復したことを示す第２通知を、前記子ノードへ送信する処理と、を実行するプロセッサを備える。
    　中継ノード。
PCT/JP2022/038728 2021-10-19 2022-10-18 通信制御方法 WO2023068258A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2023554697A JPWO2023068258A5 (ja) 2022-10-18 通信制御方法、中継ノード、セルラ通信システム、チップセット、及びプログラム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202163257246P 2021-10-19 2021-10-19
US63/257,246 2021-10-19

Publications (1)

Publication Number Publication Date
WO2023068258A1 true WO2023068258A1 (ja) 2023-04-27

Family

ID=86059114

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/038728 WO2023068258A1 (ja) 2021-10-19 2022-10-18 通信制御方法

Country Status (1)

Country Link
WO (1) WO2023068258A1 (ja)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210243636A1 (en) * 2018-10-25 2021-08-05 Huawei Technologies Co., Ltd. Communication Control Method And Apparatus

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210243636A1 (en) * 2018-10-25 2021-08-05 Huawei Technologies Co., Ltd. Communication Control Method And Apparatus

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
QUALCOMM INCORPORATED: "IAB BH RLF handling", 3GPP DRAFT; R2-1906419, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, 2 May 2019 (2019-05-02), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , pages 1 - 3, XP051710734 *
QUALCOMM INCORPORATED: "Status on RAN WI NR_IAB", 3GPP DRAFT; S3-191516, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG3, no. Reno (US); 20190506 - 20190510, 29 April 2019 (2019-04-29), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051721679 *

Also Published As

Publication number Publication date
JPWO2023068258A1 (ja) 2023-04-27

Similar Documents

Publication Publication Date Title
JP7189219B2 (ja) 中継装置
JP7291763B2 (ja) 通信制御方法
JP7522797B2 (ja) 通信制御方法
US20230078657A1 (en) Communication control method
JP2023145706A (ja) 通信制御方法
JP2024079777A (ja) 通信制御方法
US20240032129A1 (en) Communication control method
US20230328607A1 (en) Communication control method
US20230080014A1 (en) Communication control method
WO2023068255A1 (ja) 通信制御方法及び境界ｉａｂノード
WO2023068258A1 (ja) 通信制御方法
JP7483864B2 (ja) 通信制御方法、中継ノード、移動通信システム、チップセット及びプログラム
WO2023013603A1 (ja) 通信方法
WO2023132283A1 (ja) 通信制御方法
WO2023132285A1 (ja) 通信制御方法
WO2023013604A1 (ja) 通信制御方法
WO2023068254A1 (ja) 通信制御方法及び中継ノード
WO2023149577A1 (ja) 通信制御方法
US20230262516A1 (en) Communication control method
WO2022234846A1 (ja) 通信制御方法
WO2023132284A1 (ja) 通信制御方法
JP7397221B2 (ja) 通信制御方法、中継ノード及びプロセッサ
WO2023002987A1 (ja) 通信制御方法
WO2023140334A1 (ja) 通信制御方法
WO2023068256A1 (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: 22883562

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2023554697

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE