WO2022149470A1 - 通信制御方法 - Google Patents

通信制御方法 Download PDF

Info

Publication number
WO2022149470A1
WO2022149470A1 PCT/JP2021/047568 JP2021047568W WO2022149470A1 WO 2022149470 A1 WO2022149470 A1 WO 2022149470A1 JP 2021047568 W JP2021047568 W JP 2021047568W WO 2022149470 A1 WO2022149470 A1 WO 2022149470A1
Authority
WO
WIPO (PCT)
Prior art keywords
iab
node
relay node
iab node
conditional handover
Prior art date
Application number
PCT/JP2021/047568
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 JP2022573993A priority Critical patent/JPWO2022149470A1/ja
Publication of WO2022149470A1 publication Critical patent/WO2022149470A1/ja
Priority to US18/347,228 priority patent/US20230354139A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/34—Reselection control
    • H04W36/36—Reselection control by user or terminal equipment
    • H04W36/362—Conditional handover
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • 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
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/24—Reselection being triggered by specific parameters
    • H04W36/249—Reselection being triggered by specific parameters according to timing information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/24—Reselection being triggered by specific parameters
    • H04W36/30—Reselection being triggered by specific parameters by measured or perceived connection quality data
    • H04W36/305—Handover due to radio link failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • 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.
  • 3GPP Third Generation Partnership Project
  • IAB Integrated Access and Backhaul
  • One or more relay nodes intervene in the communication between the base station and the user device, and relay the communication.
  • the communication control method is the communication control method used in the cellular communication system.
  • the communication control method includes that the relay node receives a flow control feedback message or a failure occurrence notification message from the parent node of the relay node. Further, the communication control method includes that the relay node executes a conditional handover according to a certain period of time after receiving the flow control feedback message or the failure occurrence notification message.
  • the communication control method according to the second aspect is the communication control method used in the cellular communication system.
  • the communication control method is that the relay node attempts to transfer a data packet to the parent node of the relay node, and if the relay node cannot transfer the data packet for a certain period of time, a conditional handover is performed. Have to do.
  • the communication control method is the communication control method used in the cellular communication system.
  • a donor base station having a first relay node under its control sets a conditional handover setting for the first relay node, and the first relay node makes the setting. It has the ability to perform conditional handovers based on.
  • FIG. 1 is a diagram showing a configuration example of a cellular communication system according to an embodiment.
  • FIG. 2 is a diagram showing the relationship between the IAB node, the parent node (Parent nodes), and the child node (Child nodes).
  • FIG. 3 is a diagram showing a configuration example of a gNB (base station) according to an embodiment.
  • FIG. 4 is a diagram showing a configuration example of an IAB node (relay node) according to an embodiment.
  • FIG. 5 is a diagram showing a configuration example of a UE (user device) according to an embodiment.
  • FIG. 6 is a diagram showing an example of a protocol stack for RRC connection and NAS connection of IAB-MT.
  • FIG. 7 is a diagram showing an example of a protocol stack for the F1-U protocol.
  • FIG. 8 is a diagram showing an example of a protocol stack for the F1-C protocol.
  • FIG. 9 is a diagram showing an example in which conditional handover is performed.
  • FIG. 10 is a diagram showing an example in which conditional handover is performed.
  • FIG. 11 is a diagram showing an operation example according to the first embodiment.
  • FIG. 12 is a diagram showing an operation example according to the second embodiment.
  • FIG. 13 is a diagram showing an operation example according to the third embodiment.
  • FIG. 14 is a diagram showing an operation example according to the fourth embodiment.
  • FIG. 15 is a diagram showing an example when there are a plurality of candidate cells.
  • FIG. 16 is a diagram showing an operation example according to the fifth embodiment.
  • FIG. 17 is a diagram showing an operation example according to the sixth embodiment.
  • FIG. 18 is a diagram showing the type of BH RLF notification.
  • FIG. 19 is a diagram showing the transmission option of the extended BH RLF indication.
  • FIG. 20 is a diagram relating to the execution of CHO.
  • FIG. 21 is a diagram showing a identified solution for avoiding re-establishment to a descendant node.
  • FIG. 22 is a diagram showing a comparison of the mechanism of lossless distribution of UL data in the hop-by-hop ARQ.
  • FIG. 23 is a diagram showing options for introducing UL status distribution.
  • FIG. 24 is a diagram showing RAN2 signaling that may occur at the transition of IAB nodes between donors.
  • the cellular communication system 1 is a 5G system of 3GPP.
  • the wireless access system in the cellular communication system 1 is NR (New Radio), which is a 5G wireless access system.
  • NR New Radio
  • LTE Long Term Evolution
  • the cellular communication system 1 may be applied to a future cellular communication system such as 6G.
  • FIG. 1 is a diagram showing a configuration example of the cellular communication system 1 according to the embodiment.
  • the cellular communication system 1 includes a 5G core network (5GC) 10, a user device (UE: User Equipment) 100, and a base station device (hereinafter, may be referred to as a “base station”) 200. It has -1,200-2, and IAB nodes 300-1,300-2.
  • the base station 200 may be referred to as a gNB.
  • the base station 200 may be an LTE base station (that is, an eNB).
  • base stations 200-1 and 200-2 may be referred to as gNB200 (or base station 200), and IAB nodes 300-1 and 300-2 may be referred to as IAB node 300, respectively.
  • the 5GC10 has an AMF (Access and Mobility Management Function) 11 and an 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 is located by communicating with the UE 100 using NAS (Non-Access Stratum) signaling.
  • the UPF 12 is a device that controls transfer of user data and the like.
  • Each gNB 200 is a fixed wireless communication node and manages one or a plurality of cells.
  • Cell is used as a term to indicate the smallest unit of wireless communication area.
  • Cell may be used as a term to indicate a function or resource for wireless communication with the UE 100. Further, the cell may be used without distinguishing it from a base station such as gNB200.
  • One cell belongs to one carrier frequency.
  • Each gNB200 is interconnected with the 5GC10 via an interface called an NG interface.
  • FIG. 1 illustrates two gNB200-1 and gNB200-2 connected to 5GC10.
  • Each gNB 200 may be divided into an aggregate unit (CU: Central Unit) and a distributed unit (DU: Distributed Unit).
  • the CU and DU are connected to each other via an interface called an F1 interface.
  • the F1 protocol is a communication protocol between the CU and the 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 by using NR in the backhaul.
  • Donor gNB (or IAB node; hereinafter may be referred to as “IAB node”) 200-1 is a terminal node of the NR backhaul on the network side, and is a donor base station having an additional function to support IAB. be.
  • the backhaul can be multi-hop through multiple hops (ie, multiple IAB nodes 300).
  • the IAB node 300-1 wirelessly connects to the IAB donor 200-1
  • the IAB node 300-2 wirelessly connects to the IAB node 300-1
  • the F1 protocol is transmitted in two backhaul hops. An example is shown.
  • the UE 100 is a mobile wireless communication device that performs wireless communication with a cell.
  • the UE 100 may be any device as long as it is a device that performs wireless communication with the gNB 200 or the IAB node 300.
  • the UE 100 is a mobile phone terminal, a tablet terminal, a notebook PC, a sensor or a device provided in the sensor, and / or a vehicle or a device provided in the vehicle.
  • the UE 100 wirelessly connects to the IAB node 300 or gNB 200 via an access link.
  • FIG. 1 shows an example in which the UE 100 is wirelessly connected to the IAB node 300-2.
  • the UE 100 indirectly communicates with the IAB donor 200-1 via the IAB node 300-2 and the IAB node 300-1.
  • FIG. 2 is a diagram showing the relationship between the IAB node 300, the parent node (Parent nodes), and the child node (Child nodes).
  • each IAB node 300 has an IAB-DU corresponding to a base station functional unit and an IAB-MT (Mobile Termination) corresponding to a user equipment functional unit.
  • IAB-DU corresponding to a base station functional unit
  • IAB-MT Mobile Termination
  • the adjacent node (that is, the upper node) on the NR Uu radio interface of the IAB-MT is called the parent node.
  • the parent node is the parent IAB node or the DU of the IAB donor 200.
  • the radio link between the IAB-MT and the parent node is called a backhaul link (BH link).
  • FIG. 2 shows an example in which the parent nodes of the IAB node 300 are the IAB nodes 300-P1 and 300-P2. The direction toward the parent node is called upstream. Seen from the UE 100, the upper node of the UE 100 may correspond to the parent node.
  • the adjacent node (that is, the lower node) on the NR access interface of the IAB-DU is called a child node.
  • the IAB-DU manages the cell in the same manner as the gNB200.
  • the IAB-DU terminates the NR Uu radio interface to the UE 100 and lower IAB nodes.
  • the IAB-DU supports the F1 protocol to the CU of the IAB donor 200-1.
  • FIG. 2 shows an example in which the child nodes of the IAB node 300 are the IAB nodes 300-C1 to 300-C3, the UE 100 may be included in the child nodes of the IAB node 300.
  • the direction toward the child node is called downstream.
  • all IAB nodes 300 connected to the IAB donor 200 via one or more hops have a directed acyclic graph (DAG) topology (hereinafter referred to as “Directed Acyclic Graph)” routed to the IAB donor 200.
  • DAG directed acyclic graph
  • topology Sometimes referred to as "topology”.
  • adjacent nodes on the IAB-DU interface are child nodes and adjacent nodes on the IAB-MT interface are parent nodes.
  • the IAB donor 200 concentrates on, for example, the resources, topology, route management, and the like of the IAB topology.
  • FIG. 3 is a diagram showing a configuration example of 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 unit 210 has a reception unit 211 and a transmission unit 212.
  • the receiving unit 211 performs various receptions under the control of the control unit 230.
  • the receiving unit 211 includes an antenna, converts (down-converts) a radio signal received by the antenna into a baseband signal (received signal), and outputs the radio signal to the control unit 230.
  • the transmission unit 212 performs various transmissions under the control of the control unit 230.
  • the transmission unit 212 includes an antenna, converts (up-converts) a baseband signal (transmission signal) output by the control unit 230 into a radio signal, and transmits the baseband signal (transmission signal) from the antenna.
  • the network communication unit 220 performs wired communication (or wireless communication) with 5GC10 and wired communication (or wireless communication) with other adjacent gNB200.
  • the network communication unit 220 has a reception unit 221 and a transmission unit 222.
  • the receiving unit 221 performs various types of reception under the control of the control unit 230.
  • the receiving unit 221 receives a signal from the outside and outputs the received signal to the control unit 230.
  • the transmission unit 222 performs various transmissions under the control of the control unit 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 on the gNB 200.
  • the control unit 230 includes at least one memory and at least one processor electrically connected to the memory.
  • the memory stores a program executed by the processor and information used for processing by the processor.
  • the processor may include a baseband processor and a CPU (Central Processing Unit).
  • the baseband processor modulates / demodulates and encodes / decodes the baseband signal.
  • the CPU executes a program stored in the memory to perform various processes.
  • the processor performs processing of each layer described later. Further, the control unit 230 may perform each process in the gNB 200 in each of the following embodiments.
  • FIG. 4 is a diagram showing a configuration example of the IAB node 300.
  • the IAB node 300 has a wireless communication unit 310 and a control unit 320.
  • the IAB node 300 may have a plurality of 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 receiving unit 311 performs various receptions under the control of the control unit 320.
  • the receiving unit 311 includes an antenna, converts (down-converts) a radio signal received by the antenna into a baseband signal (received signal), and outputs the radio signal to the control unit 320.
  • the transmission unit 312 performs various transmissions under the control of the control unit 320.
  • the transmission unit 312 includes an antenna, converts (up-converts) a baseband signal (transmission signal) output by the control unit 320 into a radio signal, and transmits the baseband signal (transmission signal) from the antenna.
  • the control unit 320 performs various controls on the IAB node 300.
  • the control unit 320 includes at least one memory and at least one processor electrically connected to the memory.
  • the memory stores a program executed by the processor and information used for processing by the processor.
  • the processor may include a baseband processor and a CPU.
  • the baseband processor modulates / demodulates and encodes / decodes the baseband signal.
  • the CPU executes a program stored in the memory to perform various processes.
  • the processor performs processing of each layer described later. Further, the control unit 320 may perform each process in the IAB node 300 in each of the following embodiments.
  • FIG. 5 is a diagram showing a configuration example of the UE 100. As shown in FIG. 5, the UE 100 has a wireless communication unit 110 and a control unit 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. Further, the wireless communication unit 110 may perform wireless communication on the side link, that is, wireless communication with another UE 100.
  • the wireless communication unit 110 has a reception unit 111 and a transmission unit 112.
  • the receiving unit 111 performs various receptions under the control of the control unit 120.
  • the receiving unit 111 includes an antenna, converts (down-converts) a radio signal received by the antenna into a baseband signal (received signal), and outputs the radio signal to the control unit 120.
  • the transmission unit 112 performs various transmissions under the control of the control unit 120.
  • the transmission unit 112 includes an antenna, converts (up-converts) a baseband signal (transmission signal) output by the control unit 120 into a radio signal, and transmits the baseband signal (transmission signal) from the antenna.
  • the control unit 120 performs various controls on the UE 100.
  • the control unit 120 includes at least one memory and at least one processor electrically connected to the memory.
  • the memory stores a program executed by the processor and information used for processing by the processor.
  • the processor may include a baseband processor and a CPU.
  • the baseband processor modulates / demodulates and encodes / decodes the baseband signal.
  • the CPU executes a program stored in the memory to perform various processes.
  • the processor performs processing of each layer described later.
  • the control unit 130 may perform each process in the UE 100 in each of the following embodiments.
  • FIG. 6 is a diagram showing an example of a protocol stack for RRC connection and NAS connection of IAB-MT.
  • 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 Control Protocol). It has a layer, an RRC (Radio PHY Control) layer, and a NAS (Non-Access Stratum) layer.
  • PHY physical
  • MAC Medium Access Control
  • RLC Radio Link Control
  • PDCP Packet Data Control Protocol
  • It has a layer, an RRC (Radio PHY Control) layer, and a NAS (Non-Access Stratum) layer.
  • the PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping.
  • Data and control information are transmitted between the PHY layer of the IAB-MT of the IAB node 300-2 and the PHY layer of the IAB-DU of the IAB node 300-1 via a physical channel.
  • the MAC layer performs data priority control, retransmission processing by hybrid ARP (Hybrid Automatic Repeat request), random access procedure, and the like. Data and control information are transmitted 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 via the transport channel.
  • the MAC layer of the IAB-DU includes a scheduler. The scheduler determines the transport format (transport block size, modulation / coding method (MCS)) of the upper and lower links and the allocated resource block.
  • the RLC layer transmits data to the receiving RLC layer by using the functions of the MAC layer and the PHY layer. Data and control information are transmitted between the RLC layer of the IAB-MT of the IAB node 300-2 and the RLC layer of the IAB-DU of the IAB node 300-1 via a logical channel.
  • the PDCP layer performs header compression / decompression and encryption / decryption. Data and control information are transmitted between the PDCP layer of the IAB-MT of the IAB node 300-2 and the PDCP layer of the IAB donor 200 via the radio bearer.
  • the RRC layer controls the logical channel, transport channel, and physical channel according to the establishment, re-establishment, and release of the radio bearer.
  • RRC signaling for various settings is transmitted between the RRC layer of the IAB-MT of the IAB node 300-2 and the RRC layer of the IAB donor 200. If there is an RRC connection with the IAB donor 200, the IAB-MT is in the RRC connected state. If there is no RRC connection with the IAB donor 200, the IAB-MT is in the RRC idle state.
  • the NAS layer located above the RRC layer performs session management, mobility management, etc.
  • NAS signaling is transmitted between the NAS layer of the IAB-MT of the IAB node 300-2 and the AMF11.
  • FIG. 7 is a diagram showing a protocol stack related to the F1-U protocol.
  • FIG. 8 is a diagram showing a protocol stack for the F1-C protocol.
  • the IAB donor 200 is divided into CU and DU.
  • each of the IAB-MT of the IAB node 300-2, the IAB-DU of the IAB node 300-1 and the IAB-MT of the IAB node 300-1 and the DU of the IAB donor 200 are of the RLC layer. It has a BAP (Backhaul Adjustment Protocol) layer as an upper layer.
  • the BAP layer is a layer that performs routing processing and bearer mapping / demapping processing. In the backhaul, the IP layer is transmitted via the BAP layer, which enables routing in multiple hops.
  • the PDU (Protocol Data Unit) of the BAP layer is transmitted by the backhaul RLC channel (BH NR RLC channel).
  • BH NR RLC channel backhaul RLC channel
  • Each BH link constitutes a plurality of backhaul RLC channels. This makes it possible to prioritize traffic and control quality of service (QoS).
  • QoS quality of service
  • the association between the BAP PDU and the backhaul RLC channel is performed by the BAP layer of each IAB node 300 and the BAP layer of the IAB donor 200.
  • the CU of the IAB donor 200 is a gNB-CU function of the IAB donor 200 that terminates the F1 interface to the DU of the IAB node 300 and the IAB donor 200.
  • the DU of the IAB donor 200 is also a gNB-DU function of the IAB donor 200 that hosts the IAB BAP sublayer and provides a wireless backhaul to the IAB node 300.
  • the protocol stack of the F1-C protocol has an F1AP layer and an SCTP (Stream Control Transmission Protocol) layer instead of the GTP-U layer and the UDP layer shown in FIG. 7.
  • SCTP Stream Control Transmission Protocol
  • IAB-DU and IAB-MT of IAB may be simply described as the processing or operation of "IAB".
  • 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.
  • the processing or operation of the DU or CU of the IAB donor 200 may also be described simply as the processing or operation of the "IAB donor".
  • the upstream direction and the uplink (UL) direction may be used without distinguishing between the upstream direction and the uplink (UL) direction.
  • the downstream direction and the downlink (DL) direction may be used without distinction.
  • Conditional handover may be performed in the cellular communication system 1.
  • Conditional Handover (CHO) is a handover executed when one or more execution conditions (or trigger conditions) are satisfied.
  • conditional handover will be described.
  • the UE 100 reports the measured value of the radio state of the serving cell and / or the adjacent cell to the gNB 200, and based on this report, the gNB 200 determines the handover to the adjacent cell and transmits the handover instruction to the UE 100. .. Therefore, when the radio state of the serving cell is suddenly deteriorated, in general handover, communication may be interrupted before the handover is executed.
  • the execution condition of the conditional handover includes one or more trigger conditions.
  • Conditional handover settings include candidate cells and trigger conditions.
  • the conditional handover setting may include a plurality of combinations of candidate cells and trigger conditions.
  • the conditional handover is set, for example, by unicast signaling from the CU of the IAB donor 200 to the IAB-DU of the IAB node 300 and the UE 100 (for example, an RRC Configuration message).
  • FIG. 9 is a diagram showing an example in which conditional handover is performed.
  • the IAB node 300-T is in the RRC connected state with respect to its parent node, the IAB node 300-P1. Then, when it is determined that the IAB-MT of the IAB node 300-T satisfies the trigger condition, the serving cell (or the IAB node 300-P1 that manages the serving cell) is selected from the target cell (or the IAB node 300 that manages the target cell). Perform conditional handover to P2).
  • the cell and the IAB node 300 that manages the cell may be used without distinction. Therefore, the handover from the serving cell to the target cell and the handover from the IAB node 300-P1 that manages the serving cell to the IAB node 300-P2 that manages the target cell may be used interchangeably.
  • the trigger condition is satisfied in the IAB node 300-T, if the conditional handover is executed immediately, the handover may be executed even though the situation is improved. Such a conditional handover becomes a useless handover. Due to such useless handover, the entire topology may be in a non-optimal state.
  • the conditional handover is not executed immediately when the trigger condition is satisfied, but the conditional handover is executed after a certain period of time has elapsed after receiving the predetermined message. That is, the trigger condition in the first embodiment is "a certain period of time has passed after receiving the predetermined message".
  • the relay node receives a flow control feedback (flow control feedback) message or a failure occurrence notification message from the parent node of the relay node.
  • the relay node executes the conditional handover according to the elapse of a certain period after receiving the flow control feedback message or the failure occurrence notification message.
  • the "predetermined message” is a "flow control feedback message or a failure occurrence notification message”.
  • the IAB node 300-T since the IAB node 300-T is performed after a certain period of time has elapsed after receiving the predetermined message, it is possible not to perform the conditional handover when the situation is improved. Therefore, in the first embodiment, the execution of unnecessary conditional handover is suppressed, and the entire topology can be maintained in the optimum state.
  • the "flow control feedback message” is a message used for flow control.
  • the "failure occurrence notification message” is a notification message used when a failure occurs in the BH link.
  • two messages will be described.
  • flow control In the cellular communication system 1, flow control may be performed. Flow control can avoid packet drop-related congestion (or congestion, hereinafter sometimes referred to as “congestion”) at the IAB node 300 and the IAB donor 200.
  • congestion packet drop-related congestion
  • Downstream flow control in 3GPP is supported by the BAP sublayer.
  • the IAB-MT of the IAB node 300 provides feedback information on the buffer size available in each ingress (inflow) BH RLC channel to the parent node. Send to.
  • the message containing this feedback information is a flow control feedback message.
  • Flow control in the upstream direction is not specified in 3GPP. In this case, in 3GPP, it is said that it is performed by UL scheduling on the MAC layer (or by UL grant) due to implementation dependence.
  • the IAB-DU of the parent node 300-P1 can send a flow control feedback message to the IAB-MT of its child node IAB node 300-T. be.
  • the flow control feedback message may be included in a BAP layer message, for example, a BAP Control PDU.
  • the flow control feedback message may be transmitted using a MAC CE or RRC message.
  • the IAB node 300-P1 includes the flow control feedback message in the system information block type 1 (SIB1: System Information Block Type 1) and transmits it to the UE 100, or transmits it to the UE 100 using the MAC CE.
  • SIB1 System Information Block Type 1
  • the IAB node 300-P1 can send a flow control feedback message to the UE 100.
  • the IAB node 300-P1 establishes a backhaul (BH # 1) link with its upper IAB node.
  • the IAB-MT of the IAB node 300-P1 is in the RRC connected state.
  • the IAB-MT of the IAB node 300-P1 has detected a radio link failure (BH RLF: Backhaul Radio Link Failure) of the BH # 1 link.
  • BH RLF Backhaul Radio Link Failure
  • the IAB-MT of the IAB node 300-P1 detects the BH RLF when the out-of-sync state (out-of-sync) is detected under certain conditions.
  • the IAB-DU of the IAB node 300-P1 detects the BH RLF
  • Type 1 Instruction is an example of a failure occurrence notification indicating that BH RLF has been detected.
  • Type2 Instruction is an example of a failure occurrence notification indicating that recovery from BH RLF is being attempted.
  • the IAB-DU of the IAB node 300-P1 can transmit the Type1 / 2 Indication to the IAB-MT (or UE100) of the IAB node 300-T when it does not distinguish between the Type1 Indication and the Type2 Indication.
  • Type1 / 2 Instruction is also an example of failure notification.
  • a message including such a failure occurrence notification is a failure occurrence notification message.
  • the failure occurrence notification message may also be included in the BAP layer message, for example, the BAP Control PDU.
  • the IAB node 300-P1 can transmit the failure occurrence notification message to the UE 100 by including it in the SIB 1 and transmitting it to the UE 100, or by transmitting it to the UE 100 using the MAC CE. ..
  • Type3 Inspection (RLF recovered) and Type4 Inspection (Recovery failure).
  • Type3 Instruction is a recovery notification indicating that the IAB node 300-T has recovered from the BH RLF.
  • Type4Indication is an example of a recovery failure notification indicating that the IAB node 300-T has failed to recover from the BH RLF.
  • FIG. 11 is a diagram showing an operation example according to the first embodiment.
  • the IAB donor 200 sets the conditional handover in step S11.
  • the IAB node 300-T measures a certain period of time after receiving the flow control feedback message or the failure occurrence notification message from the parent node 300-P1.
  • the failure occurrence notification message is BH RLF Type 1 Instruction, Type 2 Instruction, or Type 1/2 Instruction.
  • the fixed period starts from the time when the flow control feedback message or the failure occurrence notification message is received.
  • the IAB node 300-T activates the timer, and when the count value reaches the timer value, determines that the fixed period has expired.
  • the timer value may be set in advance from the IAB donor 200 or the parent node 300-P1 to the IAB node 300-T. Alternatively, the timer value may be included in the flow control feedback message or the failure occurrence notification message.
  • the number of times the flow control feedback message is received may be used. That is, when the IAB node 300-T receives the flow control feedback message from the parent node 300-P1 or the child node 300-C1, the counter is incremented.
  • the IAB node 300-T determines that a certain period of time has elapsed when the counter value reaches the threshold value.
  • the threshold may be preset by the IAB donor 200 or the parent node 300-P1 or may be included in the flow control feedback message.
  • the determination by these timers and the determination by the counter may be combined. That is, the IAB node 300-T activates the timer and increments the counter when the flow control feedback message is first received.
  • the IAB node 300-T determines that a certain period of time has elapsed. When the timer expires, the IAB node 300-T resets (ie, sets to zero) the counter value.
  • step S13 the IAB node 300-T executes a conditional handover according to the elapse of a certain period of time.
  • the IAB node 300-T performs a conditional handover to the IAB node 300-P2 that manages the target cell.
  • step S14 the IAB node 300-T ends a series of processes.
  • a conditional handover execution determination may be made according to the request from the parent node 300-P1 or the child node 300-C1.
  • the parent node 300-P1 or the child node 300-C1 includes an identifier in the flow control feedback message indicating whether or not a conditional handover should be performed.
  • the IAB node 300-T determines whether or not to perform a conditional handover based on the identifier.
  • the parent node 300-P1 or the child node 300-C1 can control the conditional handover of the IAB node 300-T according to the congestion situation.
  • step S13 if a predetermined message is received before a certain period of time elapses, the IAB node 300-T can be prevented from executing the conditional handover.
  • a predetermined message there is a flow control leaving feedback message.
  • the flow control withdrawal message is, for example, a message used to notify that the parent node 300-P1 that has sent the flow control feedback message in a congested situation has improved from the congested situation and returned to the normal state. ..
  • there is Type 3 Instruction of BH RLF Upon receiving such a predetermined message, the IAB node 300-T may stop the timer.
  • the second embodiment is an example of executing a conditional handover when the IAB node 300 cannot transfer a data packet for a certain period of time.
  • the relay node (for example, IAB node 300) tries to transfer the data packet to the parent node of the relay node.
  • the relay node executes a conditional handover.
  • the trigger condition for the conditional handover is "the data packet could not be transferred to the parent node for a certain period of time”.
  • the IAB-MT of the IAB node 300-T attempts to transfer the data packet to the IAB-DU of the parent node 300-P1. Then, if the transfer cannot be performed for a certain period of time, the IAB-MT of the IAB node 300-T executes a conditional handover to the IAB node 300-P2 that manages the target cell.
  • the IAB node 300 executes a conditional handover when the data packet cannot be transferred for a certain period of time.
  • the IAB node 300 can give up on the IAB node that manages the serving cell and perform a conditional handover to another IAB node. Therefore, in the second embodiment, it is possible to reduce the delay of data packet transfer.
  • FIG. 12 is a diagram showing an operation example according to the second embodiment.
  • the IAB donor 200 sets the conditional handover in step S21.
  • step S22 the IAB node 300-T attempts to transfer the data packet to the parent node 300-P1.
  • step S23 the IAB node 300-T executes a conditional handover when the data packet cannot be transferred for a certain period of time.
  • a conditional handover when the data packet cannot be transferred for a certain period of time.
  • the IAB node 300-T sends an SR or a buffer status report (BSR: Buffer Status Report) to the parent node 300-P1. After that, it is the case that UL grant is not received for a certain period of time.
  • BSR Buffer Status Report
  • (A3) or "when the data packet cannot be transferred for a certain period of time" is a case where the IAB node 300-T reaches a certain number of retransmissions of HARQ or RLC to the parent node 300-P1. ..
  • the threshold value for the fixed number of times is smaller than the threshold value for determining BH RLF due to RLC retransmission failure.
  • (A5) or "when the data packet cannot be transferred for a certain period of time” means that the IAB node 300-T detects a radio abnormality (radio problem) for the parent node 300-P1 (the radio abnormality is recovered). If a certain amount of time has passed (without doing). However, in this case, it is desirable that the threshold value for the fixed time period is smaller (shorter) than the threshold value for determining BH RLF due to a radio abnormality.
  • (A6) or "when the data packet cannot be transferred for a certain period of time" means that the IAB node 300-T triggers a measurement report to the parent node 300-P1 (the radio measurement). If a certain amount of time has passed (without sending a report). However, in this case, it is desirable that the threshold value for the fixed time period is smaller (shorter) than the threshold value for determining BH RLF according to the radio measurement report.
  • the "fixed number of times” and “fixed time” in the above (A1) to (A8) may be set by the parent node 300-P1 or the IAB donor 200. Further, the IAB node 300-T may measure a "fixed time” by using an internal timer. Furthermore, the "fixed number of times", “fixed time”, and timer are separate for each BH RLC channel, each LCG (Logical Channel Group), each source and / or destination (destination), or each routing ID. May be present or measured in.
  • step S24 the IAB node 300-T ends a series of processes.
  • the third embodiment is an example in which the IAB node 300 executes a conditional handover when it receives a flow control feedback message from its parent node and further receives a failure occurrence notification message.
  • the relay node receives the flow control feedback message from the parent node, and further receives the failure occurrence notification message from the parent node, so that a certain period of time does not elapse. , Perform conditional feedback.
  • the trigger condition for the conditional handover is "a flow control feedback message has been received from the parent node, and a failure occurrence notification message has been received from the parent node".
  • the IAB node 300 is handed over to a parent node different from the parent node that sent the flow control message, so that the "congestion" situation in the parent node can be improved.
  • the IAB node 300 is a parent node in a "congested" situation, and the data packet transfer is delayed in the upstream direction because the handover is performed to a parent node different from the parent node in which BH RLF occurs. It is also possible to reduce the number of.
  • FIG. 13 is a diagram showing an operation example according to the third embodiment.
  • the IAB node 300 When the IAB node 300 starts processing in step S30, the IAB node 300 receives a conditional handover setting from the IAB donor 200 in step S31.
  • step S32 the IAB node 300 receives the flow control feedback message from the parent node.
  • the IAB node 300 executes local rerouting.
  • local rerouting will be described.
  • BH RLF occurs on a backhaul link
  • local rerouting is performed and data packets are transferred via an alternative path.
  • the IAB donor 200 sets the routing for each IAB node 300.
  • Each IAB node 300 selects a relay node that transfers data packets from a plurality of relay nodes according to the routing setting.
  • Local rerouting is, for example, ignoring such routing settings and selecting an alternative path to forward the data packet to that alternative path. Since the data packet is transferred from the first IAB node to the second IAB node on the alternative path by local rerouting, it is possible to reduce the delay of data packet transfer, for example.
  • the parent node 300-P1 can send a flow control feedback message to the IAB node 300-T when the buffer size exceeds a certain amount.
  • the IAB node 300-T can grasp the occurrence of "congestion" in the parent node 300-P1 by receiving the message. Then, when the IAB node 300-T confirms that the parent node 300-P1 is "crowded", the IAB node 300-T executes local rerouting. In the example of FIG. 9, the IAB node 300-T selects the path to the parent node 300-P2 as an alternative path by local rerouting. The IAB node 300-T forwards the data packet to the alternative path.
  • Step S32 of FIG. 13 may be "determined that the IAB node 300 is in a situation of performing local rerouting".
  • the IAB node 300 receives the Type1 Instruction, the Type2 Instruction, or the Type1 / 2 Instruction from the parent node. It is confirmed in step S33 that the IAB node 300 has received the flow control feedback message from the parent node and further received the failure occurrence notification message in addition to step S32.
  • step S33 may be "receive a failure occurrence notification message from the same parent node while the IAB node 300 is performing local rerouting".
  • the "same parent node” is, for example, a parent node on the path (or main path) immediately before the IAB node 300 selects an alternative path.
  • the parent node 300-P1 since the parent node 300-P1 transmits the flow control feedback message, the parent node 300-P1 becomes the “same parent node”.
  • step S34 the IAB node 300 executes (or triggers) a conditional handover.
  • the IAB node 300-T will perform a conditional handover to the parent node 300-P2.
  • step S35 the IAB node 300 ends a series of processes.
  • the fourth embodiment is an example in which the IAB donor 200 sets which trigger condition is used in the IAB node 300 among a plurality of trigger conditions in the conditional handover.
  • the donor base station for example, IAB donor 200
  • the first relay node for example, IAB node 300
  • Set one or more trigger conditions to use This makes it possible to set trigger conditions according to, for example, the relay node.
  • FIG. 14 is a diagram showing an operation example according to the fourth embodiment.
  • the IAB node 300 is given one or more trigger conditions to be used by the IAB node 300 from among a plurality of trigger conditions in the conditional handover.
  • the CU of the IAB donor 200 sets a trigger condition to the IAB-MT or IAB-DU of the IAB node 300 by using an RRC message or an F1-AP message.
  • the trigger conditions include, for example, the following.
  • the trigger condition is one or more of the above (B1) to (B5). Since multiple trigger conditions are allowed, the trigger condition is "received BH RLF Type 1/2 Instruction" (B2) + “received flow control feedback message from the parent node” (B3). ) May be set. Further, regarding (B2), Type1 Instruction or Type2 Instruction may be used instead of Type1 / 2 Instruction.
  • step S42 the IAB node 300 executes (or triggers) a conditional handover when the set trigger condition is satisfied.
  • step S43 the IAB node 300 ends a series of processes.
  • the parent node 300-P1 of the IAB node 300-T transmits the Type1 / 2 Instruction of BH RLF to the IAB node 300-T, and the IAB node 300-T performs a conditional handover.
  • the IAB node 300-T performs a conditional handover.
  • the IAB node 300-T selects the cell having the best radio condition in each of the candidate cells # 1 and # 2, for example, the candidate cell # 1.
  • the number of hops from the IAB node 300-T to the target (IAB donor 200 in the example of FIG. 15) via the parent node 300-P2 is determined via the parent node 300-P3 that manages the candidate cell # 2. It may be more than the number of hops to reach. In this case, the former has a larger number of hops than the latter, so that the delay in data packet transfer becomes larger.
  • selecting the candidate cell with the best wireless condition may not necessarily mean selecting the optimum route.
  • the IAB donor 200 sets the priority of the candidate cell for the conditional handover. Specifically, first, the donor base station (for example, IAB donor 200) sets the priority for each candidate cell for the first relay node (for example, IAB node 300-T). Second, the first relay node selects the candidate cell with the highest priority as the target cell and performs a conditional handover with respect to the target cell. This makes it possible to select the optimum route with a reduced delay in data packet transfer, for example.
  • FIG. 16 is a diagram showing an operation example according to the fifth embodiment.
  • the IAB donor 200 sets the conditional handover to the IAB node 300-T in step S51.
  • the CU of the IAB donor 200 sends an RRC reconfiguration message including the priority of each candidate cell to the IAB-DU (or UE100) of the IAB node 300-T in addition to the candidate cell and the trigger condition.
  • Settings may be made. For example, in the example of FIG. 15, the priority of the candidate cell # 1 is "1", the priority of the candidate cell # 2 is "2", and the like.
  • the F1-AP message and / or the MAC CE may be used to make a setting including the priority.
  • the trigger condition for the conditional handover may be the trigger condition described in the first embodiment, in addition to receiving the Type1 / 2 Instruction of the BH RLF, and may be described in the second embodiment or the third embodiment. It may be a trigger condition. Alternatively, the trigger condition may be event A3 or event A5. Event A3 is an event in which the radio state of the adjacent cell is better than the radio state of the serving cell by a predetermined amount (predetermined offset) or more. Further, the event A5 is an event in which the radio state of the serving cell is deteriorated from the first threshold value and the radio state of the adjacent cell is better than the second threshold value.
  • step S52 when the IAB node 300-T satisfies the trigger condition such as receiving the Type1 / 2 Instruction, the IAB node 300-T executes (or triggers) the conditional handover according to the setting of the conditional handover.
  • the IAB node 300-T selects the cell with the highest priority as the target cell based on the set priority.
  • which cell is selected may depend on the implementation of the IAB node 300-T. For example, when there are a plurality of cells having the highest priority, the IAB node 300-T may select the cell having the highest radio quality as the target cell.
  • the IAB node 300-T applies the conditional handover setting to the selected target cell.
  • step S53 the IAB node 300-T starts accessing the target cell according to the applied conditional handover setting.
  • step S54 the IAB node 300-T ends a series of processes.
  • the IAB donor 200 may further set a minimum radio quality threshold to the IAB node 300-T as a conditional handover setting.
  • the minimum radio quality threshold is, for example, expressed by RSRP (Reference Signal Received Power), RSRQ (Reference Signal Received Quality), and / or SINR (Signal to Interface plus Noise Radio).
  • RSRP Reference Signal Received Power
  • RSRQ Reference Signal Received Quality
  • SINR Signal to Interface plus Noise Radio
  • the IAB node 300 when BH RLF occurs in the candidate cell for conditional handover, the IAB node 300 removes the candidate cell from the candidate cell and prevents it from being selected as the target cell.
  • the first relay node (for example, IAB node 300-T) is the second relay node (for example, IAB node 300-P1) that manages the candidate cell (for example, candidate cell # 1). If the backhaul link with the parent node of the second relay node is normal, the candidate cell is selected as the target cell and conditional handover is executed for the target cell. If not normal, the first relay node selects another candidate cell. This makes it possible, for example, to reduce the likelihood that conditional handover will fail.
  • FIG. 17 is a diagram showing an operation example in the sixth embodiment.
  • the conditional handover setting may include designated information that specifies whether or not to confirm the BH RLF of the target cell.
  • the designated information may be included in the RRC reset message, the F1-AP message, or the like together with the candidate cell and the trigger condition, as in the fifth embodiment.
  • step S62 the IAB node 300 executes (or triggers) a conditional handover when a trigger condition such as receiving a Type1 / 2 Indication is satisfied. Also in the sixth embodiment, it is assumed that a plurality of candidate cells are triggered. Then, the IAB-MT of the IAB node 300 selects the target cell as follows, for example.
  • the IAB node 300 first temporarily selects the target cell. For example, in the example of FIG. 15, the IAB node 300-T tentatively selects the candidate cell # 1 (or the parent node 300-P2) as the target cell.
  • the tentative selection of the target cell may be selected based on the priority as in the fifth embodiment.
  • the tentative selection of the target cell may be selected based on the priority from the candidate cells exceeding the minimum radio quality threshold.
  • the IAB node 300-T confirms whether or not the BH link of the temporarily selected target cell is normal (or whether or not BH RLF has occurred). Specifically, the IAB node 300-T confirms whether or not the parent node 300-P2 has transmitted the Type 1/2 Instruction. That is, it is confirmed whether or not BH RLF is generated in the BH link between the parent node 300-P2 and the further parent node of the parent node 300-P2.
  • the IAB node 300-T may confirm whether or not the Type1 / 2 Instruction has been transmitted on the parent node 300-P2 by confirming the received BAP Control PDU. Further, for example, the IAB node 300-T may inquire of the parent node 300-P2 to confirm whether or not the Type1 / 2 Instruction has been transmitted. In the case of the UE 100 instead of the IAB node 300-T, the US100 confirms whether or not the Type1 / 2 Instruction has been transmitted by confirming the Type1 / 2 Instruction included in the notified SIB1. All of these may be Type1 Instruction or Type2 Instruction instead of Type1 / 2 Instruction. Whether or not the BH RLF of the tentatively selected target cell is normal may be determined by the IAB node 300-T confirming whether or not the parent node 300-P2 has transmitted the IAB Support IE.
  • the IAB node 300-T determines that the BH link of the temporarily selected target cell is normal, the IAB node 300-T selects the cell as the target cell.
  • the IAB node 300-T is a candidate cell # managed by the parent node 300-P2 (or the parent node 300-P2) when the BH link of the tentatively selected parent node 300-P2 is normal. Select 1) as the target cell.
  • the IAB node 300-T determines that the BH link of the tentatively selected target cell is not normal, another candidate cell is tentatively selected as the target cell.
  • the IAB node 300-T temporarily selects the candidate cell # 2 (or the parent node 300-P3) and temporarily selects the target cell. In, confirm whether or not BH RLF has occurred.
  • the confirmation method is the same as the above-mentioned example. Further, when there are a plurality of target cells to be provisionally selected, they may be selected according to the priority of each candidate cell.
  • step S63 the IAB node 300 starts accessing the target cell according to the setting of the conditional handover.
  • step S64 the IAB node 300 ends a series of processes.
  • the UE 100 may be used instead of the IAB node 300-T.
  • the UE 100 can receive the flow control feedback message or the failure occurrence message from the parent node 300-P1 by using the SIB1 or the like. Therefore, the UE 100 can execute the conditional handover when the trigger conditions described in the first to sixth embodiments are satisfied.
  • the trigger condition to be set in the UE 100 described in the third embodiment can also be set by using the RRC message or the F1-AP message.
  • a program may be provided that causes a computer to execute each process performed by the UE 100, gNB 200, or IAB node 300.
  • the program may be recorded on a computer-readable medium.
  • Computer-readable media can be used to install programs on a computer.
  • the computer-readable medium on which the program is recorded may be a non-transient recording medium.
  • the non-transient recording medium is not particularly limited, but may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.
  • a circuit that executes each process performed by the UE 100, gNB 200, or IAB node 300 may be integrated, and at least a part of the UE 100, gNB 200, or IAB node 300 may be configured as a semiconductor integrated circuit (chipset, SoC). ..
  • Topology Adaptation Enhancements-Procedure specifications for interdonor IAB node movement to enhance robustness and load balancing, including enhancements to reduce signaling load. -Specifications of extended functions for reducing service interruptions due to IAB node movement and BH RLF recovery. -Extended specifications for topology redundancy, including support for CP / UP isolation. Topology, Routing, and Transport Enhancements-Extension specifications to improve overall topology fairness, multi-hop delay, and congestion mitigation.
  • RAN2 discusses enhancements to RLF indications / handling with a focus on reducing service interruptions after BH RLF. CHO and potential IAB-specific extensions of CHO are under consideration. • DAPS and potential IAB-specific extensions to DAPS have not been ruled out at this time (although the lack of PDCP makes it unclear how to support DAPS). -For message bundling, RAN2 waits for further progress in RAN3, at least for topology adaptation procedures. RAN2 discusses local rerouting, including benefits for central routing decisions, and how to address overall topology goals.
  • RAN2 has agreed to "consider expanding topology adaptation to improve robustness (eg for rapid shadowing)". This means that BH RLF occurs more frequently in Rel-17 than in the case of Rel-16, as the radio state is expected to change more dynamically.
  • the problem with Rel-16 is that the child IAB node cannot transfer upstream data during parental RLF recovery, or even if data is transferred, the parent cannot transfer data due to BH RLF. Therefore, in any case, the data cannot reach the IAB donor and the service is interrupted.
  • Finding 3 Using Rel-16's BH RLF indication (type 4), data transfer is interrupted at the IAB node while the parent's RLF recovery is in progress.
  • the parent BH RLF should be notified to the child IAB node as soon as possible in order to take appropriate action to reduce the delay. This is in line with RAN2's agreement that "RAN2 will discuss the expansion of RLF indication / handling with a focus on reducing service interruptions after BH RLF.” Therefore, RAN2 should introduce a type 2 "attempting recovery" BH RLF indication. In addition, type 1 and type 2 have the same meaning.
  • Proposal 1 RAN2 should agree that the BH RLF indication type 2 "attempting recovery" has been introduced. Further consideration is needed as to whether it is transmitted via BAP Control PDU, SIB1, or both.
  • the downstream IAB node and UE recognize whether the BH link has been restored based on the absence of type 2 indications in SIB1.
  • the downstream IAB node can quickly know the BH link recovery.
  • the disadvantage is that its recovery is unknown. Therefore, RAN2 should consider whether Type 3 indications are really needed.
  • Proposal 2 If Proposal 1 can be agreed, RAN2 should consider whether explicit BH RLF indications, ie, type 3 "BH link recovery", should be introduced when BH RLF is gone. ..
  • Proposal 1 and / or Proposal 2 can be agreed, the operation of the IAB-MT that received the indication should be considered while the BH link is recovering. It has been proposed that IAB-MT reduce / stop SR when it receives a Type 2 indication and resume operation when it receives a Type 3 indication (ie, the parent IAB node loses BH RLF). .. This is one of the desirable IAB-MT behaviors when the parent node attempts to restore the BH link. It is assumed that other IAB-MT operations such as interrupting all RBs are also possible.
  • Proposal 3 RAN2 should agree to reduce / stop scheduling requests after IAB-MT receives a Type 2 indication and resume scheduling requests when the parent node runs out of BH RLF. be.
  • RAN2 will discuss the expansion of RLF indication / handling with a focus on reducing service interruptions after BH RLF", rather, which IAB-MT should do to reduce service interruptions.
  • CHO conditional handover
  • a common aspect of local rerouting and CHO is the need for certain trigger conditions. Therefore, Type 2 indications may function for such purposes. Therefore, in addition to Proposal 3, RAN2 should discuss the behavior of other IAB-MTs when the parent is trying to recover from BH RLF.
  • Proposal 4 RAN2 should discuss the behavior of other IAB-MTs when receiving Type 2 BH RLF indications. Further consideration is needed, such as triggering local rerouting and / conditional handover.
  • Conditional Handover (Extended conditional handover) Conditional Handover (CHO) is introduced in Rel-16 to improve mobility robustness.
  • CHO can be used for the specified Rel-16 IAB.
  • RAN2 agreed that "CHO and potential IAB-specific extensions of CHO are under consideration.” Therefore, in addition to the Rel-16 CHO baseline, it is worth considering the CHO extensions of eIAB.
  • the Rel-16 CHO as shown in FIG. 20, when the corresponding CHO event (A3 / A5) is satisfied, or when the selected cell is a CHO candidate as a result of cell selection for RRC reestablishment. Is executed.
  • the CHO event A3 / A5 can be met when the IAB node experiences BH RLF on the BH link.
  • these trigger conditions cannot be satisfied in the RLF peculiar to IAB, that is, the RLF by receiving the BH RLF indication (type 4) because the radio state of the BH link of the IAB node itself is good.
  • one of the desirable actions is to execute CHO when the IAB node receives the BH RLF indication.
  • Findings 4 Rel-16 CHO has a CHO event A3 at IAB-MT because the parent's BH RLF recovery is in progress and even if it fails, the BH link between IAB-MT and the parent is still good. Not automatically triggered / executed by / A5.
  • Proposal 5 RAN2 should discuss whether additional trigger conditions for CHO are specified, at least when the IAB node receives the BH RLF indication (type 4). If additional trigger conditions are introduced, further consideration is needed to determine whether they are applicable to Type 2.
  • the current specification states, "If performing a conditional reconfiguration triggers multiple NR cells, the choice depends on the UE implementation. For example, the UE considers the beam and beam quality. Select one of the cells triggered for execution. " This is primarily intended for UEs.
  • Finding 5 In Rel-16 CHO, when multiple candidate cells trigger CHO execution, which cell is selected depends on the implementation of the UE.
  • IAB-MT For IAB-MT, it is always best if IAB-MT chooses one of the implementation-triggered cells, depending on local radio quality etc., because the purpose of the entire topology is properly handled by the IAB donor. Not exclusively. Therefore, RAN2 should discuss how to confirm the execution of CHO for IAB donor control for additional trigger conditions such as Proposal 5.
  • the IAB donor may set priority information associated with CHO candidates in the CHO setting. The IAB-MT should select the highest priority cell from all triggered CHO candidates that meet a particular radio quality (such as S-criterion).
  • Proposal 6 RAN2 should consider whether IAB donor-controlled CHO execution is required as an additional extension if all candidate cells trigger CHO upon receipt of BH RLF indication.
  • Rel-17 should aim to apply local rerouting to other cases agreed by RAN2 to improve load balancing, signaling reduction, robustness and / or service interruption.
  • BH RLF indications as in Proposal 4 (to improve robustness / service interruption) and / or by receiving flow control feedback (for load balancing / congestion mitigation), etc.
  • BH It is worth considering additional conditions for starting / stopping local rerouting other than RLF. That is, in general, parents and / or children should be able to conditionally trigger local rerouting of IAB nodes.
  • Finding 6 In Rel-16, local rerouting is allowed only in the case of BH RLF. This improves robustness and service interruptions.
  • Proposal 7 RAN2 should discuss whether additional conditions will be introduced to start / stop local rerouting. This allows other IAB nodes to be triggered, such as by receiving a BH RLF indication as in Proposal 1 and / or by receiving a flow control feedback.
  • Finding 7 In the local rerouting of Rel-16, which path is selected as an alternative path depends on the implementation of IAB-MT.
  • IAB donors should become more important if local rerouting is extended beyond the case of BH RLF. It is clear that the IAB donor can set an alternative path, as the IAB node must select an alternative path when performing local rerouting. Modeling of alternative paths requires further consideration, such as whether the alternative paths have the same routing ID.
  • Proposal 8 RAN2 should consider whether the IAB donor can set an alternative path to the IAB node in addition to the routing settings of Rel-16.
  • IAB donors should be aware of local rerouting, even if they start / stop local rerouting on the IAB node for the coexistence of local rerouting and the purpose of the entire topology. Good things should be considered. For example, the IAB donor may consider whether the overall topology objective is still achieved, based on the awareness of which IAB node is currently performing local rerouting. If the IAB donor finds that the overall topology goal cannot be achieved, the IAB donor may instruct the IAB node to start / stop local rerouting, or the IAB donor may change the routing settings for the entire IAB topology. ..
  • Proposal 9 RAN2 should discuss whether the IAB node needs to notify the IAB donor when local rerouting starts / stops.
  • Proposal 10 RAN2 should discuss whether the IAB donor can instruct the IAB node to start / stop local rerouting.
  • Finding 8 In Rel-16, when the IAB node attempts an RRC re-establishment request to a descendant node, the IAB node must wait for the failure and finally move to idle.
  • Proposal 11 RAN2 should agree that optimization of cell (re) selection is considered to avoid re-establishment to inappropriate nodes (eg, descendant nodes).
  • the common concept is considered to be that the IAB-MT is provided in either the allow list or the block list for the purpose of cell selection. obtain.
  • allow and block lists have advantages depending on the topology and the location of the IAB nodes. And there are disadvantages.
  • the block list may be more appropriate in order to reduce overhead, for example, because it contains only the downstream IAB nodes of the IAB node of concern and, in some cases, only a small number of child IAB nodes.
  • Findings 9 The allow list and block list have advantages and disadvantages depending on the topology and location of the IAB node.
  • the IAB donor or parent IAB node
  • Proposal 12 RAN2 should agree that the IAB-MT will be provided with an allow list or block list (ie, a selection structure) for the purpose of cell selection to avoid re-establishment to descendant nodes. Further consideration is needed as to whether these lists can also be used for cell reselection procedures.
  • an allow list or block list ie, a selection structure
  • Proposal 12 can be agreed, further consideration should be given to how the information (ie, permit list or block list) is provided.
  • Option 1 assumes a CHO setting and may require some extensions.
  • Option 2 envisions additional indications, such as type 2 BH RLF indications.
  • Option 3 is intended to provide information about the entire topology that is not in the existing configuration.
  • Option 5 is supposed to be set by OAM, but as the reporter pointed out, this is suspicious.
  • Proposal 13 RAN2 should agree that the allow list / block list is dynamically provided by the parent IAB node or IAB donor each time the topology changes. Further studies are needed for details.
  • the second solution "Reroute buffered PDCP PDUs at intermediate IAB nodes," was supported as an implementation choice at the BAP layer. Further, the BAP layer may be executed "for example, data buffering in the transmission part of the BAP entity is implementation-dependent until the RLC-AM entity receives the acknowledgment". These BAP implementations were considered to avoid packet loss in the "most" cases of the Rel-16 deployment scenario, i.e. when using fixed IAB nodes, but are not perfect, for example, as in Figure 36. rice field.
  • the third solution “Introduction of UL status distribution,” was a promising solution for guaranteeing lossless distribution of UL data in consideration of the evaluation results cited in FIG. 36.
  • the idea was to delay the RLC ARQ to the UE so that it would start when PDCP data recovery in the UE was needed.
  • a fixed IAB node was assumed, it was considered rare that UL packets were dropped due to a topology change, so it was not specified in Rel-16.
  • RAN2 should discuss, in addition to the results captured by TR, an extended mechanism to ensure lossless delivery within the L2 multihop network.
  • Proposal 14 is a solution identified in TR38.874, a mechanism that guarantees lossless delivery under conditions where topology changes may occur frequently based on some form of "UL status delivery". Should be agreed to be introduced.
  • C-2 should be an extended baseline for Rel-17 for lossless delivery of UL packets.
  • Finding 10 C-2, which is the solution to "introduction of UL status distribution", may be an extended baseline for Rel-17, which can also be implemented for Rel-16.
  • Rel-17 should assume a dynamic topology change that causes UL packet loss
  • the extension of Rel-17 will support C-2 as a standard support function.
  • At least the stage 2 specification should explain the overall mechanism based on C-2. Otherwise, the 3GPP standard does not guarantee lossless delivery during the handover of the IAB node.
  • small changes such as RLC and / or BAP are expected in stage 3, but details may not be specified as they are considered internal behavior of the IAB node.
  • Proposal 15 RAN2 should agree to specify an RLC ARQ mechanism for lossless delivery of UL packets in stage 2. This delays the transmission of the ACK to the child node / UE before receiving the ACK from the parent IAB node (ie, C-2). Whether or not to specify in stage 3 / how to specify it needs further consideration.
  • Rel-17 aims to specify the movement of the Interdonor IAB node, which will provide robust operation and will be applied to mobile IAB nodes.
  • the movement of the Interdonor IAB node of Rel-17 is performed during the active phase, so the movement of the Interdonor IAB node of one IAB node affects the entire topology. causes a service interruption.
  • moving an interdonor IAB node in Rel-17 is a method of moving all IAB nodes in the IAB topology to another IAB donor, specifically an RRC reconfiguration with synchronization (ie, a handover command). Need to be considered how is provided to these affected IAB nodes.
  • -Case 1 When the parent is moved first, the RRC signaling path between the child and the source donor is released. Therefore, it is unclear how the child node can be moved.
  • -Case 2 When the child is first moved, the RRC signaling path to the target donor via the parent node has not yet been established. Therefore, it is unclear how the child node will access the target donor (ie, how to complete the RRC reconfiguration and send it to the target donor).
  • the CHO may be reused using some extensions of the child node. That is, when the parent node is moved, the CHO is executed on the child node.
  • the transmission of the child node's RRC reconfiguration to the target donor may be delayed, for example, by its parent node.
  • the overall procedure for moving interdonor IAB nodes is being considered in RAN3, but RAN2 needs to consider the impact of RAN2 on how to reconfigure multiple IAB nodes in a multi-hop network.
  • Proposal 16 RAN2 needs to consider how to reconfigure the multi-hop IAB node for interdonor IAB node movement.

Landscapes

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

Abstract

第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードが、前記中継ノードの親ノードからフロー制御フィードバックメッセージ又は障害発生通知メッセージを受信することを有する。また、前記通信制御方法は、前記中継ノードが、前記フロー制御フィードバックメッセージ又は前記障害発生通知メッセージを受信後、一定期間経過したことに応じて、条件付きハンドオーバを実行することを有する。

Description

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

Claims (9)

  1. 　セルラ通信システムで用いる通信制御方法であって、
    　中継ノードが、前記中継ノードの親ノードからフロー制御フィードバックメッセージ又は障害発生通知メッセージを受信することと、
    　前記中継ノードが、前記フロー制御フィードバックメッセージ又は前記障害発生通知メッセージを受信後、一定期間経過したことに応じて、条件付きハンドオーバを実行することと、
    　を有する通信制御方法。
  2. 　前記実行することは、前記中継ノードが、前記親ノードから前記フロー制御フィードバックメッセージを受信し、さらに、前記親ノードから前記障害発生通知メッセージを受信したことに応じて、一定期間経過することなく、前記条件付きハンドオーバを実行することを含む、請求項１記載の通信制御方法。
  3. 　前記障害発生通知メッセージは、前記中継ノードと前記親ノードとの間のバックホールリンクの無線リンク障害を検知したことを示すメッセージ、及び前記バックホールリンクの無線リンク障害からの回復を試行中であることを示すメッセージのうち少なくとも一方を含む、請求項１記載の通信制御方法。
  4. 　セルラ通信システムで用いる通信制御方法であって、
    　中継ノードが、当該中継ノードの親ノードへ、データパケットの転送を試みることと、
    　前記中継ノードが、一定期間、前記データパケットの転送ができなかった場合、条件付きハンドオーバを実行することと、
    　を有する通信制御方法。
  5. 　セルラ通信システムで用いる通信制御方法であって、
    　配下に第１の中継ノードを有するドナー基地局が、前記第１の中継ノードに対して、条件付きハンドオーバに関する設定を行うことと、
    　前記第１の中継ノードが、前記設定に基づいて、前記条件付きハンドオーバを実行することと、
    　を有する通信制御方法。
  6. 　前記設定を行うことは、前記ドナー基地局が、前記第１の中継ノードに対して、前記条件付きハンドオーバに関する複数のトリガ条件のうち、前記第１の中継ノードが用いるべき１以上のトリガ条件を設定することを含み、
    　前記実行することは、前記第１の中継ノードが、前記設定されたトリガ条件を満たす場合に、前記条件付きハンドオーバを実行することを含む、請求項５記載の通信制御方法。
  7. 　前記設定を行うことは、前記ドナー基地局が、前記第１の中継ノードに対して、候補セル毎の優先順位を設定することと、
    　前記実行することは、前記第１の中継ノードが、最も優先順位の高い候補セルをターゲットセルとして選択し、前記ターゲットセルに対して前記条件付きハンドオーバを実行することを含む、請求項５記載の通信制御方法。
  8. 　前記設定を行うことは、前記ドナー基地局が、前記第１の中継ノードに対して、最低無線品質閾値を設定することを含み、
    　前記実行することは、前記第１の中継ノードが、前記最低無線品質閾値を上回る無線品質を有する候補セルの中から、最も優先順位の高い候補セルをターゲットセルとして選択し、前記ターゲットセルに対して前記条件付きハンドオーバを実行することを含む、請求項７記載の通信制御方法。
  9. 　前記実行することは、
    　　前記第１の中継ノードが、候補セルを管理する第２の中継ノードと当該第２の中継ノードの親ノードとの間のバックホールリンクが正常な場合、前記候補セルをターゲットセルとして選択して前記ターゲットセルに対して条件付きハンドオーバを実行することと、
    　　前記第１の中継ノードが、前記バックホールリンクが正常でない場合、他の候補セルを選択することと、
    を含む、請求項６記載の通信制御方法。
PCT/JP2021/047568 2021-01-06 2021-12-22 通信制御方法 WO2022149470A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2022573993A JPWO2022149470A1 (ja) 2021-01-06 2021-12-22
US18/347,228 US20230354139A1 (en) 2021-01-06 2023-07-05 Communication control method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202163134275P 2021-01-06 2021-01-06
US63/134,275 2021-01-06

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/347,228 Continuation US20230354139A1 (en) 2021-01-06 2023-07-05 Communication control method

Publications (1)

Publication Number Publication Date
WO2022149470A1 true WO2022149470A1 (ja) 2022-07-14

Family

ID=82357306

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/047568 WO2022149470A1 (ja) 2021-01-06 2021-12-22 通信制御方法

Country Status (3)

Country Link
US (1) US20230354139A1 (ja)
JP (1) JPWO2022149470A1 (ja)
WO (1) WO2022149470A1 (ja)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017513255A (ja) * 2014-03-03 2017-05-25 テレフオンアクチーボラゲット エルエム エリクソン（パブル） セル間でのモビリティ及び／又はアクセス選択のステアリング
WO2020128848A1 (en) * 2018-12-18 2020-06-25 Telefonaktiebolaget Lm Ericsson (Publ) Conditional mobility selection
US20200267795A1 (en) * 2019-02-14 2020-08-20 Lg Electronics Inc. Method and apparatus for handling backhaul link failure in wireless communication system
WO2020196201A1 (ja) * 2019-03-28 2020-10-01 京セラ株式会社 通信制御方法
WO2020202447A1 (ja) * 2019-04-01 2020-10-08 富士通株式会社 基地局装置、端末装置、無線通信システム及び接続変更方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017513255A (ja) * 2014-03-03 2017-05-25 テレフオンアクチーボラゲット エルエム エリクソン（パブル） セル間でのモビリティ及び／又はアクセス選択のステアリング
WO2020128848A1 (en) * 2018-12-18 2020-06-25 Telefonaktiebolaget Lm Ericsson (Publ) Conditional mobility selection
US20200267795A1 (en) * 2019-02-14 2020-08-20 Lg Electronics Inc. Method and apparatus for handling backhaul link failure in wireless communication system
WO2020196201A1 (ja) * 2019-03-28 2020-10-01 京セラ株式会社 通信制御方法
WO2020202447A1 (ja) * 2019-04-01 2020-10-08 富士通株式会社 基地局装置、端末装置、無線通信システム及び接続変更方法

Also Published As

Publication number Publication date
US20230354139A1 (en) 2023-11-02
JPWO2022149470A1 (ja) 2022-07-14

Similar Documents

Publication Publication Date Title
JP7433455B2 (ja) リンク切替、リンク切替構成方法、装置、通信ノード及び媒体
US20210168666A1 (en) Communication method and communications apparatus
US7590064B1 (en) Method and system of flow control in multi-hop wireless access networks
US11949490B2 (en) Relay apparatus
WO2015027719A1 (zh) 一种协作多流传输数据的方法及基站
JP7291763B2 (ja) 通信制御方法
WO2021090686A1 (ja) 通信制御方法及び無線中継装置
US20230180327A1 (en) Communication control method
JP2024079777A (ja) 通信制御方法
US11706053B2 (en) Differential latency measurement
TWI807527B (zh) 降低多分支傳輸中封包延遲的方法和裝置
US20240032129A1 (en) Communication control method
US20230328607A1 (en) Communication control method
US20230080014A1 (en) Communication control method
WO2014169863A1 (zh) 终端小区切换中与无线局域网互操作决策的方法及装置
WO2022149470A1 (ja) 通信制御方法
WO2022030575A1 (ja) 通信制御方法
WO2021090687A1 (ja) 通信制御方法及び無線中継装置
WO2022145309A1 (ja) 通信制御方法
US20240179543A1 (en) Communication control method
WO2022030517A1 (ja) 通信制御方法
WO2023068258A1 (ja) 通信制御方法
WO2022153989A1 (ja) 通信制御方法
CN118140528A (zh) 通信控制方法和中继节点

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022573993

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21917690

Country of ref document: EP

Kind code of ref document: A1