WO2022085696A1 - 通信制御方法 - Google Patents

通信制御方法 Download PDF

Info

Publication number
WO2022085696A1
WO2022085696A1 PCT/JP2021/038658 JP2021038658W WO2022085696A1 WO 2022085696 A1 WO2022085696 A1 WO 2022085696A1 JP 2021038658 W JP2021038658 W JP 2021038658W WO 2022085696 A1 WO2022085696 A1 WO 2022085696A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
iab
relay node
failure
notification
Prior art date
Application number
PCT/JP2021/038658
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 CN202180086330.5A priority Critical patent/CN116671149A/zh
Priority to JP2022557567A priority patent/JPWO2022085696A1/ja
Priority to EP21882837.4A priority patent/EP4224902A4/en
Publication of WO2022085696A1 publication Critical patent/WO2022085696A1/ja
Priority to US18/303,808 priority patent/US20230328629A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/34—Modification of an existing route
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/22—Alternate routing
    • 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/0005—Control or signalling for completing the hand-off
    • H04W36/0083—Determination of parameters used for hand-off, e.g. generation or modification of neighbour cell lists
    • H04W36/00837—Determination of triggering parameters for hand-off
    • 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
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/04—Terminal devices adapted for relaying to or from another terminal or user

Definitions

  • the present invention relates to a communication control method used in a cellular communication system.
  • 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 is that the relay node that detects the occurrence of a failure in the backhaul link between the relay node and the parent node of the relay node sends a notification instructing the execution of conditional handover and communication.
  • the device has to receive the notification.
  • the communication control method is the communication control method used in the cellular communication system.
  • the first relay node that has detected the occurrence of a failure in the backhaul link between the first relay node and the parent node of the first relay node indicates the occurrence of the failure.
  • the occurrence notification includes transferability information indicating whether or not to transfer the failure occurrence notification, and is to be transmitted to the second relay node.
  • the second relay node transfers the failure occurrence notification received from the first relay node according to the transfer possibility information, or the second relay node receives the notification from the second relay node. It has to not forward the failure notification.
  • the communication control method is the communication control method used in the cellular communication system.
  • the first relay node transmits a failure occurrence notification indicating that a failure has occurred in the backhaul link, or a recovery failure notification indicating that recovery from the failure has failed in the backhaul link.
  • the first request requesting the change of the route priority is transmitted to the second relay node.
  • the second relay node reaches the fourth relay node from the second relay node via the third relay node in response to the reception of the first request. It has the priority of one route and / or the priority of a second route from the second relay node to the fourth relay node via the fifth relay node.
  • the communication control method includes that the second relay node transmits a packet according to the changed priority of the first route and / or the changed priority of the second route.
  • the communication control method is the communication control method used in the cellular communication system.
  • the second relay node receives a failure occurrence notification indicating that a failure has occurred in the backhaul link from the first relay node, and the second relay node has the failure occurrence.
  • the main path setting is deactivated, and the alternative path setting for the main path is activated.
  • 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 a configuration example of the cellular communication system according to the first embodiment.
  • FIG. 10 is a diagram showing an operation example of the first embodiment.
  • FIG. 11 is a diagram showing a configuration example of the cellular communication system according to the third embodiment.
  • FIG. 12 is a diagram showing an operation example of the third embodiment.
  • FIG. 13 is a diagram showing a configuration example of the cellular communication system according to the fourth embodiment.
  • FIG. 14 is a diagram showing an operation example of the fourth embodiment.
  • FIG. 15 is a diagram showing an operation example of the fifth embodiment.
  • FIG. 16 is a diagram showing the types of BH RLF notifications.
  • FIG. 17 is a diagram showing transmission options of the extended BH RLF indication.
  • FIG. 18 shows a specific solution for avoiding re-establishment to descendant nodes.
  • FIG. 19 is a diagram showing a comparison of the mechanism of lossless distribution of UL data in the case of hop-by-hop RLCARQ.
  • FIG. 20 is a diagram showing options of “C) Introducing UL status distribution”.
  • FIG. 21 is a diagram illustrating RAN2 signaling problems that can occur with IAB node movement 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 future cellular communication systems such as 6G.
  • FIG. 1 is a diagram showing a configuration example of a cellular communication system 1 according to an 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 the 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.
  • One cell belongs to one carrier frequency. In the following, cells and base stations may be used without distinction.
  • 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.
  • the donor gNB200-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.
  • the backhaul can be multi-hop through multiple hops (ie, multiple IAB nodes 300).
  • FIG. 1 an example in which the IAB node 300-1 wirelessly connects to the donor gNB200-1, the IAB node 300-2 wirelessly connects to the IAB node 300-1, and the F1 protocol is transmitted in two backhaul hops. 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, a vehicle or a device provided in the vehicle, a flying object or a device provided in the flying object.
  • 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 donor gNB200-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 donor gNB200.
  • 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 300P1 and 300P2. 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 Uu 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 donor gNB200-1.
  • FIG. 2 shows an example in which the child node of the IAB node 300 is the IAB node 300C1-300C3, the UE 100 may be included in the child node of the IAB node 300.
  • the direction toward the child node is called downstream.
  • 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 on the IAB node 300 in each of the following embodiments.
  • FIG. 5 is a diagram showing the configuration 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 Response 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 Response Control) layer, and a NAS (Non-Access Stratum) layer.
  • RRC Radio Response Control
  • NAS Non-Access Stratum
  • the PHY layer performs coding / 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 ARQ (HARQ), 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.
  • MCS modulation / coding method
  • 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 via the radio bearer between the PDCP layer of the IAB-MT of the IAB node 300-2 and the PDCP layer of the donor gNB200.
  • the RRC layer controls logical channels, transport channels, and physical channels according to the establishment, re-establishment, and release of radio bearers.
  • RRC signaling for various settings is transmitted between the RRC layer of the IAB-MT of the IAB node 300-2 and the RRC layer of the donor gNB200. If there is an RRC connection with the donor gNB200, the IAB-MT is in the RRC connected state. If there is no RRC connection with the donor gNB200, 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 donor gNB200 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 donor gNB200 are above the RLC layer. It has a BAP (Backhaul Adjustment Protocol) layer as a 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).
  • the backhaul RLC channel BH NR RLC channel.
  • 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
  • FIG. 9 is a diagram showing a configuration example of the cellular communication system 1 according to the first embodiment.
  • the cellular communication system 1 shown in FIG. 9 includes a node 500, an IAB node 300-T, an IAB node 300-C, and a UE 100.
  • the IAB node 300-C and the UE 100 may be communication devices.
  • the node 500 is a parent node of the IAB node 300-T, and is a gNB200 (or a donor node; hereinafter, “gNB200” may be referred to as a “donor node”) or an IAB node 300 (parent IAB node).
  • the IAB-MT of the IAB node 300-T has established a backhaul link (BH link) # 1 with the node 500.
  • the IAB-MT of the IAB node 300-T is in the RRC connected state.
  • the IAB node 300-C is a child node (child IAB node) of the IAB node 300-T.
  • the IAB-MT of the IAB node 300-C has established a BH link # 2 with the IAB node 300-T.
  • the IAB-MT of the IAB node 300-C is in the RRC connected state.
  • the IAB-MT of the IAB node 300-C may be in the RRC idle state without establishing the BH link # 2 with the IAB node 300-T.
  • the UE 100 has established an access link with the IAB node 300-T.
  • the UE 100 is in the RRC connected state.
  • the UE 100 may be in the RRC idle state without establishing an access link with the IAB node 300-T.
  • the IAB-MT of the IAB node 300-T detects the radio link failure of the BH link # 1 (BH RLF (Radio Link Failure)).
  • the IAB-MT of the IAB node 300-T detects the BH RLF as follows, and performs a recovery trial for recovery from the BH RLF.
  • the IAB-MT of the IAB node 300-T detects an out-of-sync state (out-of-sync) N310 times in a row, it detects a radio problem (radio problem) and starts the timer T310 (). Start). After starting the timer T310, the IAB-MT of the IAB node 300-T stops the timer T310 when the synchronization state (in-sync) is continuously detected N311 times.
  • the IAB-MT of the IAB node 300-T detects the RLF and starts the timer T311 (that is, starts the RRC reestablishment process) when the timer T310 expires without stopping the timer T310. Perform cell selection processing to recover the BH link.
  • the IAB-MT of the IAB node 300-T selects an appropriate cell by the cell selection process, and stops the timer T311 when the BH link is restored for the selected cell.
  • a suitable cell is one that meets at least the minimum radio quality standards.
  • the IAB-MT of the IAB node 300-T transitions to the RRC idle state when the timer T311 expires without succeeding in recovering the BH link.
  • failure to recover from BH RLF after detecting BH RLF (that is, timer T311 has expired) may be referred to as failure of BH link recovery.
  • 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.
  • Type 1/2 Indication can be transmitted to the IAB-MT and the UE 100 of the IAB node 300-C.
  • Type1 / 2 Instruction is also an example of failure notification.
  • Type3 Inspection 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.
  • Each Indication may be included in the BAP Control PDU or MAC CE and transmitted in the BH link. Further, each Instruction may be included in SIB1 and transmitted in the access link.
  • the IAB-MT of the IAB node 300-T detects the BH RLF of the BH link # 1
  • the radio state of the BH link # 2 and the radio state of the access link may be good. Therefore, there is a concern that the IAB node 300-C and the UE 100 may stay in the cell of the IAB node 300-T that has detected the BH RLF.
  • the IAB node 300-T transmits a notification indicating the execution instruction of the conditional handover to at least one of the IAB node 300-C and the UE 100.
  • the relay node that detects the occurrence of a failure in the backhaul link between the relay node and the parent node of the relay node sends a notification instructing the execution of the conditional handover.
  • the communication device receives the notification.
  • Communication devices are, for example, IAB nodes 300-C and UE100. Thereby, for example, when the IAB node 300-T detects the occurrence of a failure in the backhaul link, the IAB node 300-C or the UE 100 can execute a conditional handover to switch the connection to another IAB node. It becomes.
  • conditional handover is a handover executed when one or more handover execution conditions (or trigger conditions) are satisfied.
  • the conditional handover setting includes a candidate cell for the handover and a trigger condition for the handover.
  • the conditional handover setting may include a plurality of combinations of candidate cells and trigger conditions.
  • the conditional handover settings further include the RRC settings corresponding to the candidate cells.
  • 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 conditional handover when the preset trigger condition is satisfied, the handover to the candidate cell corresponding to the trigger condition can be autonomously executed. Therefore, problems such as communication blackout in general handover can be solved.
  • 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.
  • 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.
  • FIG. 10 is a diagram showing an operation example according to the first embodiment.
  • the operation example shown in FIG. 10 shows the operation example in the cellular communication system 1 in FIG.
  • the IAB node 300-T shown in FIG. 9 may be referred to as an upper node 300-T
  • the IAB node 300-C may be referred to as a lower node 300-C.
  • step S100 the cellular communication system 1 starts processing.
  • the donor node sets a conditional handover (CHO (Conditional Handover)) for the lower nodes 300-C and the UE 100.
  • the trigger condition included in the conditional handover setting may include "reception of a notification indicating an execution instruction of the conditional handover".
  • the conditional handover may be set by unicast signaling (for example, RRC Reconnection message) from the CU of the donor node to the IAB-DU of the lower node 300-C and the UE 100.
  • unicast signaling for example, RRC Reconnection message
  • the upper node 300-T When the upper node 300-T detects the BH RLF in step S102, the upper node 300-T transmits a notification indicating the execution instruction of the conditional handover to the lower nodes 300-C and the UE 100.
  • the notification indicating the execution instruction of the conditional handover may be included in a message of the BAP layer, for example, a BAP Control PDU (Protocol Data Unit).
  • the execution instruction may be included in MAC CE (MAC Control Element).
  • the IAB-MT of the lower node 300-C connected to the IAB-DU of the upper node 300-T can receive the BAP layer message including the execution instruction from the IAB-DU of the upper node 300-T.
  • the IAB-DU of the upper node 300-T includes the execution instruction in the system information block type 1 (SIB (System Information Block) 1) and transmits the execution instruction.
  • SIB System Information Block
  • the notification in step S102 may be set by the donor node as to whether or not the notification is performed. This can be achieved by the CU of the donor node making such a setting for the IAB-DU of the upper node 300-T by signaling. Alternatively, the higher-level node 300-T may perform step S102 only when the IAB node 300-C or the UE 100 is present under the control. Such a setting may also be made by the CU of the donor node.
  • step S103 when the lower node 300-C receives the notification indicating the execution instruction of the conditional handover, the lower node 300-C executes the conditional handover. In order to satisfy one of the trigger conditions of the conditional handover, "reception of the notification indicating the execution instruction of the conditional handover", the lower node 300-C will execute the handover.
  • RSRP Reference Signal Received Power: reference signal received power
  • the lower node 300-C may apply TTT (Time to Tiger: time trigger) or wait for the execution of the conditional handover for a certain period of time.
  • TTT Time to Tiger: time trigger
  • the lower node 300-C may cancel the trigger condition and does not perform the conditional handover.
  • the TTT may be set by the CU of the donor node in step S101.
  • step 104 the cellular communication system 1 ends a series of processes.
  • Type 1 Instruction there may be "reception of Type 1 Instruction".
  • the lower node 300-C or the UE 100 receives the Type 1 Instruction from the upper node 300-T, so that the trigger condition of the conditional handover is satisfied and the handover is performed.
  • the upper node 300-T detects a failure (BH RLF)
  • the lower node 300-C or the UE 100 performs a handover to another IAB node 300.
  • a trigger condition there may be "reception of Type 2 Instruction”.
  • the lower node 300-C or the UE 100 receives the Type 2 Instruction from the upper node 300-T, so that the trigger condition of the conditional handover is satisfied and the handover is performed.
  • the upper node 300-T is in the recovery operation for the failure (BH RLF)
  • the lower node 300-C or the UE 100 will perform a handover to another IAB node 300.
  • a trigger condition " There may be "Reception of Type 4 Instruction”.
  • the lower node 300-C or the UE 100 receives the Type 4 Instruction from the upper node 300-T, so that the trigger condition of the conditional handover is satisfied and the handover is performed.
  • the upper node 300-T detects a recovery failure due to a failure (BH RLF)
  • the lower node 300-C or the UE 100 performs a handover to another IAB node 300.
  • Such a setting may be made, for example, in step 101 (FIG. 10) of the first embodiment.
  • the CU of the donor node sets a conditional handover in the IAB-DU or UE100 of the lower node 300-C with the reception of Type1, Type2, or Type4 Instruction as a trigger condition.
  • the lower node may start RRC reestablishment (RRC Restabrishment) all at once by receiving Type1 / 2 Instruction.
  • RRC Restabrishment RRC Restabrishment
  • the topology of the IAB node 300 may collapse.
  • all IAB nodes 300 in the topology may transfer RRC re-establishment, etc. even to IAB nodes that do not need to execute RRC re-establishment, etc. by transferring Type1 / 2 Instruction. Further, even if all the IAB nodes 300 execute RRC re-establishment or the like, the connection is disturbed and the signaling does not reach the donor node, so that such processing is not considered to be successful. Further, in the first place, the IAB is performed by the centralized processing by the donor node, and there is a possibility that the IAB may fall into an uncontrollable state from the center.
  • the transfer enable / disable information is included in the Type1 / 2 Instruction.
  • the transfer hop number information is included in the Type1 / 2 Instruction.
  • the first relay node that detects the occurrence of a failure in the backhaul link between the first relay node and the parent node of the first relay node is a failure indicating the occurrence of a failure.
  • the occurrence notification includes transfer availability information indicating whether or not to transfer the failure occurrence notification, and is transmitted to the second relay node.
  • the second relay node transfers the failure occurrence notification received from the first relay node or does not transfer the failure occurrence notification received from the first relay node according to the transfer possibility information.
  • the IAB node 300 can properly transfer the Type 1/2 Indication, and the topology can be quickly recovered and the influence on the entire topology can be minimized.
  • FIG. 11 is a diagram showing a configuration example of the cellular communication system 1 according to the third embodiment.
  • the IAB-MT of the IAB node (or upper node) 300-T detects a failure of the BH link # 1 with the node 500 by the method described in the first embodiment.
  • the IAB-DU of the IAB node 300-T transmits the Type 1 Indication, the Type 2 Indication, or the Type 1/2 Indication including transferability information and the like to the IAB-MT of the IAB node 300-C which is a lower node.
  • the lower node 300-C may or may not transfer the received Instruction to the lower IAB node 300 according to the transfer possibility information and the like included in these Indications.
  • FIG. 12 is a diagram showing an operation example in the third embodiment.
  • step S110 the cellular communication system 1 starts processing.
  • step S111 when the IAB-MT of the IAB node 300-T detects the BH RLF on its own BH link # 1, the IAB-DU of the IAB node 300-T moves to the IAB-MT of the lower node 300-C.
  • Send Type1 Instruction when it is detected that the IAB-MT of the IAB node 300-T has started the recovery operation of the BH RLF at the BH link # 1, the IAB-DU of the IAB node 300-T has the lower node 300-.
  • Type2 Instruction is transmitted to C's IAB-MT. If the IAB-DU of the IAB node 300-T does not distinguish between the Type 1 Indication and the Type 2 Indication, the Type 1/2 Indication is transmitted to the IAB-MT of the lower node 300-C.
  • Type1 Information, Type2 Information, and Type1 / 2 Instruction include the following information.
  • these Indications include the type information (type information) of the Indication.
  • type information indicating that it is Type1 is included.
  • the type information may include the types of these Indications.
  • these Indications include transfer enable / disable information indicating whether or not to transfer this Indication. For example, in the case of "0", transfer is not possible, and in the case of "1", transfer is possible (transfer implementation).
  • the information may include information on whether or not the instruction is transmitted according to the BH RLF of the own IAB node 300.
  • “0” may represent its own BH RLF
  • "1" may represent the BH RLF of the parent node of its own IAB node 300.
  • the IAB node 300-T detects the BH RLC on its own BH link # 1 and transmits the Type 1 Instruction to the lower node 300-C
  • the IAB node 300-T is used as the information.
  • "0" and the lower node 300-C include "1" as the information, and transfer the Type 1 Instruction.
  • the information may include information as to whether or not the instruction is transmitted in response to the instruction from the higher-level node 300-T.
  • the lower node 300-C receives the Type 1 Indication from the upper node 300-T
  • the lower node 300-C further lowers the Type 1 Indication including information indicating that the Type 1 Indication is transmitted in response to the Indication from the upper node 300-T. Transfer to.
  • these Indications may include transfer hop information.
  • transfer hop information For example, in FIG. 11, consider the case where the IAB node 300-T is the highest IAB node on a predetermined topology. In this case, when the IAB-MT of the IAB node 300-T detects the BH RLF, the information includes "0" as the transfer hop number information and transmits the BH RLF. Then, each time a transfer is performed, the number of transfer hops is incremented. Each IAB node 300 includes the incremented number of transfer hops in the Type 1 Instruction and further transfers to a lower node.
  • the upper limit of the number of transfer hops may be set by the CU of the donor node for the IAB-DU (or IAB-MT) of each IAB node 300 by signaling.
  • the IAB-DU of each IAB node 300 compares the transfer hop number information included in each received Instruction with the upper limit value, and transfers or does not transfer the received Instruction according to the comparison result. For example, when the transfer hop number information is the same as the upper limit value, the IAB-DU of the IAB node 300 does not transfer the received Instruction, and when the transfer hop number is smaller than the upper limit value, the received Instruction is transferred.
  • step S112 the lower node 300-C determines whether or not to transfer the received Instruction to the lower IAB node 300 according to the information contained in the received Instruction. Then, the lower node 300-C transfers or does not transfer the received Instruction according to the determination.
  • the IAB-DU of the lower node 300-C does not transfer the received Instruction when "0" is included as the transfer enable / disable information.
  • the IAB-DU of the lower node 300-C transfers the received Instruction to the lower node when "1" is included as the transfer enable / disable information.
  • the Information includes information on the number of transfer hops, it will be as follows. That is, the IAB-DU of the lower node 300-C compares the transfer hop number information included in each received instruction with the upper limit value, and if the transfer hop number information is the same as the upper limit value, does not transfer the received instruction. On the other hand, the IAB-DU of the lower node 300-C transfers the received Instruction when the number of transfer hops is smaller than the upper limit value. Alternatively, when the number of transfer hops exceeds the upper limit, it may be determined that the IAB-DU of the lower node 300-C does not transfer the received Instruction. If the number of transfer hops is the same as or smaller than the upper limit, the IAB-DU of the lower node 300-C may transfer the received Instruction.
  • step S113 the cellular communication system 1 ends a series of processes.
  • the notification indicating the execution instruction of the conditional handover described in the first embodiment may be the transfer target.
  • the IAB node 300-T may transmit the notification including the transfer possibility information or the transfer hop number information.
  • route priority (or route priority) is discussed with respect to IAB.
  • the route priority is, for example, a priority in which a plurality of routes (or routes, hereinafter may be referred to as "routes") are set for the same destination in IAB, and are set for each route. Is.
  • FIG. 13 is a diagram showing an example of the cellular communication system 1 in the fourth embodiment.
  • the IAB node 300-T is the upper node
  • the IAB node 300-C is the lower node.
  • the route # 1 from the IAB node 300-R1 to the IAB node 300-D exists on the lower side of the lower node 300-C.
  • priority higher than priority "1”
  • the route with the lowest number of hops may be assigned the highest priority. It should be noted that such a priority can be set by the CU of the donor node by signaling the IAB-DU of each IAB node 300.
  • the lower node 300-C when the lower node 300-C receives, for example, the Type1 / 2 Instruction from the upper node 300-T, the route priority set for each route is changed, and then when the Type3 Instruction is received, the lower node 300-C changes the route priority. Return the route priority to the state before the change.
  • a failure occurrence notification indicating that a failure has occurred in the backhaul link or a recovery failure notification indicating that the first relay node has failed to recover from the failure in the backhaul link is sent.
  • the first request for changing the route priority is transmitted to the second relay node.
  • the priority of the first route from the second relay node to the fourth relay node via the third relay node in response to the reception of the first request by the second relay node. And / or change the priority of the second route from the second relay node to the fourth relay node via the fifth relay node.
  • the second relay node transmits a packet according to the priority of the changed first route and / or the priority of the changed second route.
  • FIG. 14 is a diagram showing an operation example in the fourth embodiment.
  • step S120 the cellular communication system 1 starts processing.
  • the upper node 300-T detects the RLF of the BH link # 1.
  • the upper node 300-T may detect a recovery failure of the BH link # 1 for the RLF.
  • the higher-level node 300-T may receive the Type1 / 2 Instruction transmitted from the higher-level IAB node 300.
  • the higher-level node 300-T may receive the Type 4 Instruction transmitted from the higher-level IAB node 300.
  • the upper node 300-T transmits a notification indicating a route priority change request to the lower node 300-C.
  • a notification indicating a route priority change request For example, in step S121, when the upper node 300-T detects the RLF of the BH link # 1, Type1 / 2 Instruction is transmitted to the lower node 300-C.
  • the Type1 / 2 Instruction itself may indicate a request to change the route priority.
  • the Type1 / 2 Instruction may include an indicator as to whether or not to change the route priority.
  • the Type 4 Instruction is transmitted to the lower node 300-C.
  • the Type 4 Instruction itself may indicate a request to change the route priority.
  • the Type 4 Instruction may include an indicator as to whether or not to change the route priority.
  • the upper node 300-T may transmit the Type1 / 2 Instruction or the Type4 Instruction received from the higher IAB node 300 to the lower node 300-C.
  • This Type1 / 2 Instruction or Type4 Instruction itself may indicate a request to change the route priority, or even if each Instruction includes an indicator as to whether or not to change the route priority. good.
  • the notification indicating the route priority change request may be transmitted using BAP Control PDU, SIB1, MAC CE, or the like.
  • step S123 the lower node 300-C changes the route priority.
  • the following are examples of changes to the route priority.
  • the lower node 300-C may regard the priority of the route with the highest priority (route # 1) as the lowest priority at present. In this case, in the example of FIG. 13, route # 1 has the lowest priority and route # 2 has the highest priority.
  • the lower node 300-C may regard the priority of the route of the second priority as the highest priority at present.
  • the route # 2 which is the second priority has the highest priority.
  • the lower node 300-C may lower the priority of the route having the highest priority by one or several at present. In this case, in the example of FIG. 13, if the lower node 300-C is to be lowered by two, the priority of the route # 1 is changed from "1" to "3". As a result, the priority of the changed route # 1 is lower than the priority "2" of the route # 2, and the route # 2 has the priority over the route # 1.
  • the lower node 300-C may currently raise the priority of routes other than the highest priority by one or several. In this case, in the example of FIG. 13, if the number is increased by two, the lower node 300-C changes the priority of the route # 2 from "2" to "0". As a result, route # 2 has the highest priority, which is higher than the priority of route # 1.
  • route priority may be temporary. Further, the lower node 300-C may change the priority of all the routes by combining not only the priority of some routes but also the above 1) to 4).
  • the lower node 300-C performs the routing process for the packet according to the changed route priority.
  • the IAB-MT of the lower node 300-C sends the packet addressed to the IAB node 300-D to the IAB node 300 on the route # 2 instead of the IAB node 300-R1 on the route # 1. -Send to R2.
  • step S125 when the upper node 300-T detects the restoration of the BH link # 1, it sends a notification indicating that the route priority is returned to the state before the change to the lower node 300-C.
  • the notification may be Type 3 Instruction itself. That is, the Type 3 Instruction itself may be a notification indicating that the route priority is returned to the original state before the change. Alternatively, the Type 3 Instruction may include an indicator indicating that the route priority is returned to the state before the change.
  • the recovery of the backhaul link is detected by the upper node 300-T receiving the Type 3 Instruction transmitted from the IAB node 300 higher than the upper node 300-T as well as the BH link # 1. May be.
  • the upper node 300-T will send a notification indicating that the route priority will be returned to the state before the change.
  • the lower node 300-C may perform a process of returning the route priority to the state before the change based on the normal recovery of its own BH link. For example, when the RRC Recovery to another parent node is successful, the process of returning the route priority to the state before the change is performed.
  • the lower node 300-C performs a process of returning the route priority to the original state before the change.
  • the IAB-DU (or IAB-MT) of the lower node 300-C may change the route priority set by step S123 to the priority set by the donor node.
  • the IAB-DU of the lower node 300-C may request the CU of the donor node to return the route priority to the state before the change.
  • the CU of the donor node may reset the route priority before the change by retransmitting the routing configuration transmitted before the route priority change to the IAB-DU of the lower node 300-C. ..
  • step S127 the lower node 300-C performs packet routing processing according to the route priority before the route priority is changed. For example, in the example of FIG. 13, the lower node 300-C sets the destination of the packet addressed to the IAB node 300-D from the IAB node 300-R2 on the route # 2 to the IAB node 300-R1 on the route # 1. Change to.
  • step S1208 the cellular communication system 1 ends a series of processes.
  • Type1 / 2 Instruction has been described in the fourth embodiment, Type1 Instruction or Type2 Instruction may be used instead of Type1 / 2 Instruction.
  • the second relay node receives a failure occurrence notification indicating that a failure has occurred in the backhaul link from the first relay node.
  • the second relay node deactivates the main path setting and activates the alternative path setting for the main path in response to the reception of the failure occurrence notification.
  • the path of route # 1 is the main path and the path of route # 2 is the alternative path.
  • the routing configuration includes, for example, the BAP address of each IAB node 300 on the main path and the BAP address of each IAB node 300 on the alternative path.
  • the former can be information about the setting of the main path, and the latter can be information about the setting of the alternative path.
  • FIG. 15 is a diagram showing an operation example of the fifth embodiment.
  • the IAB node 300-C starts processing in step S130.
  • step S131 when the IAB node 300-C receives the Type1 / 2 Instruction from the upper node 300-T, it deactivates the main path setting and activates the alternative path setting.
  • the IAB-DU of the IAB node 300-C stops reading the information regarding the setting of the main path stored in the memory, and starts reading the information regarding the setting of the alternative path stored in the memory.
  • the IAB node 300-C routes the packet to the activated path.
  • the IAB-DU of the IAB node 300-C transmits the packet received from the upper node 300-T to the IAB-MT of the IAB node 300-R2 based on the information regarding the setting of the alternative path.
  • step S133 when the IAB node 300-C receives the Type3 Instruction from the upper node 300-T, it activates the main path setting and deactivates the alternative path setting.
  • the IAB-DU of the IAB node 300-C starts reading the information about the setting of the main path stored in the memory and stops reading the information about the setting of the alternative path stored in the memory.
  • the IAB node 300-C routes the packet to the activated path.
  • the IAB-DU of the IAB node 300-C transmits the packet received from the upper node 300-T to the IAB-MT of the IAB node 300-R1 based on the information regarding the setting of the main path.
  • step S135 the IAB node 300-C ends a series of processes.
  • Type1 / 2 Instruction has been described in the fifth embodiment, Type1 Instruction or Type2 Instruction may be used instead of Type1 / 2 Instruction.
  • a program may be provided that causes the computer to execute each process performed by the UE 100 or the gNB 200.
  • 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 or the gNB 200 may be integrated, and at least a part of the UE 100 or the gNB 200 may be configured as a semiconductor integrated circuit (chipset, System on a chip).
  • 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.
  • BH backhaul
  • BH RLF BH RLF indication
  • existing functions such as RRC re-establishment, MCG / SCG failure indication, and / or conditional handover. Only the recovery procedure was specified.
  • Proposal 1 RAN2 should assume that the quality of the backhaul link will change dynamically. Therefore, backhaul RLF is not a rare case in Rel-17 eIAB.
  • Rel-16 BH RLF indication which allows the child IAB-MT to recognize the RLF on the BH link and initiate the RLF recovery procedure.
  • Proposal 2 RAN2 should agree that 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.
  • Proposal 3 If Proposal 2 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. ..
  • 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 4 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.
  • Local rerouting is expected to be used for congestion mitigation, load balancing, etc., but it may also be used for service continuity even in the case of upstream BH RLF such as a parent node.
  • an IAB node can execute local rerouting when it receives a type 2 indication, but with a routing setting such as Rel-16, an upstream BH RLF can be sent to the IAB node by receiving a type 3 indication.
  • the normal recovery notification is given, it returns to the normal routing.
  • Proposal 5 RAN2 should discuss any other IAB-MT behavior while the parent node is trying to recover the BH link, such as local rerouting.
  • the IAB-DU that sends the indication
  • the type 2 BH RLF indication will be sent.
  • RLF occurs on this BH link
  • an indication is transmitted, so it is easy for a single-connection BH.
  • the IAB node detects an RLF on the MCG, it initiates the MCG fault information procedure, but the SCG continues to function as a BH link, so there is no need to send a Type 2 indication at this point.
  • Type 2 indications are transmitted when RRC re-establishment is initiated, not when MCG / SCG failure information is triggered. In any case, this is intended for IAB-DU behavior, so careful consideration should be given to whether / how to capture to specifications. That is, in stages 2 and 3, it should be considered whether note needs to be added or nothing needs to be captured.
  • Proposal 6 RAN2 agrees that IAB-DU may send a Type 2 BH RLF indication when it initiates RRC reestablishment rather than when it initiates any of the RLF recovery procedures. Should be.
  • Proposal 7 RAN2 should discuss whether / how to capture the IAB-DU behavior (ie, Proposal 6) in the specification.
  • CHO extension function with indication (type 4) Conditional Handover (CHO) was introduced in Rel-16, and in our understanding, CHO can be used as-is for Rel-16 IAB. Many companies have proposed the extension of CHO or its use for the movement of interdonor IAB nodes.
  • CHO is executed 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.
  • These trigger conditions can be met when the IAB node experiences BH RLF on the BH link.
  • the radio state of the BH link owned by the IAB node is good, that is, under the RLF peculiar to IAB such as RLF by receiving the BH RLF indication (type 4), these cannot be satisfied.
  • one of the desirable actions is to execute CHO when the IAB node receives the BH RLF indication.
  • Proposal 8 RAN2 needs to consider whether additional trigger conditions for CHO are defined, that is, at least when the IAB node receives the BH RLF indication (type 4). If introduced, further consideration is needed to see if it can be applied to Type 2.
  • Finding 4 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 9 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 whitelist or blacklist for the purpose of cell selection.
  • Whitelists and blacklists have advantages depending on the topology and the location of the IAB node, given that topology changes can occur frequently on Rel-17, for example due to "moving interdonor IAB nodes". And there are disadvantages.
  • the blacklist may be more appropriate 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 5 Whitelists and blacklists have advantages and disadvantages depending on the topology and location of the IAB node.
  • the IAB donor or parent IAB node
  • Proposal 10 RAN2 should agree that the IAB-MT will be provided with a whitelist or blacklist (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.
  • a whitelist or blacklist ie, a selection structure
  • Option 10 If Proposal 10 can be agreed, further consideration should be given to how the information (ie, whitelist or blacklist) 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 11 RAN2 should agree that the whitelist / blacklist 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 19. 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.
  • 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 12 is a solution identified in TR38.874, a mechanism that guarantees lossless delivery under conditions where topological 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.
  • 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 13 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.
  • the IAB node integration procedure has been introduced in Rel-16, which is used for the initial integration of IAB nodes. In other words, it is still in the service outage stage.
  • 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. Unlike Rel-16, 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 and of the service. Cause 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).
  • Rel-17 may not be expected as a solution.
  • 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 14 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)
  • Radio Relay Systems (AREA)

Abstract

第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードと前記中継ノードの親ノードとの間のバックホールリンクにおける障害の発生を検知した前記中継ノードが、条件付きハンドオーバの実行を指示する通知を送信することと、通信装置が、前記通知を受信することとを有する。

Description

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

Claims (10)

  1. 　セルラ通信システムで用いる通信制御方法であって、
    　中継ノードと前記中継ノードの親ノードとの間のバックホールリンクにおける障害の発生を検知した前記中継ノードが、条件付きハンドオーバの実行を指示する通知を送信することと、
    　通信装置が、前記通知を受信することと、
    　を有する通信制御方法。
  2. 　ドナーノードが、前記通信装置に対して、前記条件付きハンドオーバの実行条件として、前記条件付きハンドオーバの実行を指示する前記通知の受信を設定すること
    　をさらに有する請求項１記載の通信制御方法。
  3. 　ドナーノードが、前記通信装置に対して、前記条件付きハンドオーバの実行条件として、
    　前記障害の発生を示す障害発生通知の受信、又は
    　発生した前記障害からの回復に失敗したことを示す回復失敗通知の受信、
    を設定すること
    　をさらに有する請求項１記載の通信制御方法。
  4. 　セルラ通信システムで用いる通信制御方法であって、
    　第１の中継ノードと前記第１の中継ノードの親ノードとの間のバックホールリンクにおける障害の発生を検知した前記第１の中継ノードが、前記障害の発生を示す障害発生通知に、当該障害発生通知を転送するか否かを示す転送可否情報を含めて、第２の中継ノードへ前記障害発生通知を送信することと、
    　前記第２の中継ノードが、前記転送可否情報に従って、前記第１の中継ノードから受信した前記障害発生通知を転送する、又は前記第１の中継ノードから受信した前記障害発生通知を転送しないことと、
    　を有する通信制御方法。
  5. 　前記送信することは、前記第１の中継ノードが、前記障害発生通知に代えて、前記障害発生通知が転送される毎にインクリメントされる転送ホップ数情報を含む前記障害発生通知を前記第２の中継ノードへ送信することを含む、請求項４記載の通信制御方法。
  6. 　セルラ通信システムで用いる通信制御方法であって、
    　第１の中継ノードが、バックホールリンクにおいて障害が発生したことを示す障害発生通知、又は前記バックホールリンクにおいて前記障害からの回復に失敗したことを示す回復失敗通知を送信する際に、経路優先度の変更を要求する第１の要求を第２の中継ノードへ送信することと、
    　前記第２の中継ノードが、前記第１の要求の受信に応じて、前記第２の中継ノードから第３の中継ノードを介して第４の中継ノードへ至る第１の経路の優先度、及び／又は前記第２の中継ノードから第５の中継ノードを介して前記第４の中継ノードへ至る第２の経路の優先度を変更することと、
    　前記第２の中継ノードが、変更した前記第１の経路の優先度及び／又は変更した前記第２の経路の優先度に従って、パケットを送信することと、
    　を有する通信制御方法。
  7. 　前記第１の要求は、前記障害発生通知又は前記回復失敗通知である、請求項６記載の通信制御方法。
  8. 　前記第１の中継ノードが、前記障害が復旧したことに応じて、前記経路優先度を変更前に戻すことを要求する第２の要求を前記第２の中継ノードへ送信することと、
    　前記第２の中継ノードが、前記第２の要求の受信に応じて、変更した前記第１の経路の優先度及び／又は前記第２の経路の優先度を、変更前の前記第１の経路の優先度及び／又は前記第２の経路の優先度に戻すことと、
    　をさらに有する請求項６記載の通信制御方法。
  9. 　セルラ通信システムで用いる通信制御方法であって、
    　第２の中継ノードが、バックホールリンクにおいて障害が発生したことを示す障害発生通知を第１の中継ノードから受信することと、
    　前記第２の中継ノードが、前記障害発生通知の受信に応じて、メインパスの設定をディアクティベートし、前記メインパスに対する代替パスの設定をアクティベートすることと、
    　を有する通信制御方法。
  10. 　前記第２の中継ノードが、前記第１の中継ノードから、前記障害が回復したことを示す回復通知を受信することと、
    　前記第２の中継ノードが、前記回復通知の受信に応じて、前記メインパスの設定をアクティベートし、前記代替パスの設定をディアクティベートすることと、
    　をさらに有する請求項９記載の通信制御方法。
PCT/JP2021/038658 2020-10-21 2021-10-19 通信制御方法 WO2022085696A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN202180086330.5A CN116671149A (zh) 2020-10-21 2021-10-19 通信控制方法
JP2022557567A JPWO2022085696A1 (ja) 2020-10-21 2021-10-19
EP21882837.4A EP4224902A4 (en) 2020-10-21 2021-10-19 COMMUNICATION CONTROL METHODS
US18/303,808 US20230328629A1 (en) 2020-10-21 2023-04-20 Communication control method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202063094428P 2020-10-21 2020-10-21
US63/094,428 2020-10-21

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/303,808 Continuation US20230328629A1 (en) 2020-10-21 2023-04-20 Communication control method

Publications (1)

Publication Number Publication Date
WO2022085696A1 true WO2022085696A1 (ja) 2022-04-28

Family

ID=81290542

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/038658 WO2022085696A1 (ja) 2020-10-21 2021-10-19 通信制御方法

Country Status (5)

Country Link
US (1) US20230328629A1 (ja)
EP (1) EP4224902A4 (ja)
JP (1) JPWO2022085696A1 (ja)
CN (1) CN116671149A (ja)
WO (1) WO2022085696A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024073204A1 (en) * 2022-09-29 2024-04-04 Qualcomm Incorporated User equipment handover

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020196201A1 (ja) * 2019-03-28 2020-10-01 京セラ株式会社 通信制御方法
WO2020196124A1 (ja) * 2019-03-25 2020-10-01 京セラ株式会社 ハンドオーバ制御方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3858092A1 (en) * 2018-09-27 2021-08-04 Sharp Kabushiki Kaisha Systems, devices, and methods for handling radio link monitoring and radio link failures in wireless relay networks
WO2020167036A1 (en) * 2019-02-14 2020-08-20 Lg Electronics Inc. Method and apparatus for failure notification on backhaul link in wireless communication system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020196124A1 (ja) * 2019-03-25 2020-10-01 京セラ株式会社 ハンドオーバ制御方法
WO2020196201A1 (ja) * 2019-03-28 2020-10-01 京セラ株式会社 通信制御方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
NOKIA, NOKIA SHANGHAI BELL: "Route priority and local routing", 3GPP DRAFT; R2-1915699, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Reno, USA; 20191118 - 20191122, 7 November 2019 (2019-11-07), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051816074 *
See also references of EP4224902A4
ZTE, SANECHIPS: "Discussion on IAB BH RLF handling", 3GPP DRAFT; R2-1915119, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Reno, USA; 20191118 - 20191122, 8 November 2019 (2019-11-08), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051817029 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024073204A1 (en) * 2022-09-29 2024-04-04 Qualcomm Incorporated User equipment handover

Also Published As

Publication number Publication date
EP4224902A1 (en) 2023-08-09
EP4224902A4 (en) 2024-05-29
US20230328629A1 (en) 2023-10-12
JPWO2022085696A1 (ja) 2022-04-28
CN116671149A (zh) 2023-08-29

Similar Documents

Publication Publication Date Title
US20210168666A1 (en) Communication method and communications apparatus
WO2015027719A1 (zh) 一种协作多流传输数据的方法及基站
JP7291763B2 (ja) 通信制御方法
JP7252367B2 (ja) 通信制御方法及び無線中継装置
JP7212199B2 (ja) 通信制御方法
US20230180327A1 (en) Communication control method
US20240032129A1 (en) Communication control method
US20230328629A1 (en) Communication control method
US20230328607A1 (en) Communication control method
US20230189377A1 (en) Communication control method
WO2021090687A1 (ja) 通信制御方法及び無線中継装置
WO2022149470A1 (ja) 通信制御方法
JP2024079777A (ja) 通信制御方法
WO2022145309A1 (ja) 通信制御方法
US20240179543A1 (en) Communication control method
WO2022030517A1 (ja) 通信制御方法
CN114557023A (zh) 用于逐跳流量控制的方法及设备
WO2023068258A1 (ja) 通信制御方法
JP7495491B2 (ja) 通信制御方法及び通信装置
US20240080262A1 (en) Communication method and apparatus
WO2024029521A1 (ja) 通信制御方法
CN116686393A (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: 21882837

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022557567

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2021882837

Country of ref document: EP

Effective date: 20230420

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 202180086330.5

Country of ref document: CN