WO2022149470A1 - 通信制御方法 - Google Patents

通信制御方法 Download PDF

Info

Publication number
WO2022149470A1
WO2022149470A1 PCT/JP2021/047568 JP2021047568W WO2022149470A1 WO 2022149470 A1 WO2022149470 A1 WO 2022149470A1 JP 2021047568 W JP2021047568 W JP 2021047568W WO 2022149470 A1 WO2022149470 A1 WO 2022149470A1
Authority
WO
WIPO (PCT)
Prior art keywords
iab
node
relay node
iab node
conditional handover
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/JP2021/047568
Other languages
English (en)
French (fr)
Japanese (ja)
Inventor
真人 藤代
ヘンリー チャン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kyocera Corp
Original Assignee
Kyocera Corp
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 Kyocera Corp filed Critical Kyocera Corp
Priority to JP2022573993A priority Critical patent/JP7586935B2/ja
Publication of WO2022149470A1 publication Critical patent/WO2022149470A1/ja
Priority to US18/347,228 priority patent/US20230354139A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/34Reselection control
    • H04W36/36Reselection control by user or terminal equipment
    • H04W36/362Conditional handover
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W16/00Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/24Cell structures
    • H04W16/26Cell enhancers or enhancement, e.g. for tunnels, building shadow
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W24/00Supervisory, monitoring or testing arrangements
    • H04W24/04Arrangements for maintaining operational condition
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/24Reselection being triggered by specific parameters
    • H04W36/249Reselection being triggered by specific parameters according to timing information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/24Reselection being triggered by specific parameters
    • H04W36/30Reselection being triggered by specific parameters by measured or perceived connection quality data
    • H04W36/305Handover due to radio link failure
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W92/00Interfaces specially adapted for wireless communication networks
    • H04W92/16Interfaces between hierarchically similar devices
    • H04W92/20Interfaces between hierarchically similar devices between access points

Definitions

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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
PCT/JP2021/047568 2021-01-06 2021-12-22 通信制御方法 Ceased WO2022149470A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2022573993A JP7586935B2 (ja) 2021-01-06 2021-12-22 通信制御方法
US18/347,228 US20230354139A1 (en) 2021-01-06 2023-07-05 Communication control method

Applications Claiming Priority (2)

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

Related Child Applications (1)

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

Publications (1)

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

Family

ID=82357306

Family Applications (1)

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

Country Status (3)

Country Link
US (1) US20230354139A1 (https=)
JP (1) JP7586935B2 (https=)
WO (1) WO2022149470A1 (https=)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023279385A1 (en) * 2021-07-09 2023-01-12 Lenovo (Beijing) Limited Method and apparatus for wireless communication

Citations (5)

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

Patent Citations (5)

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

Also Published As

Publication number Publication date
JPWO2022149470A1 (https=) 2022-07-14
US20230354139A1 (en) 2023-11-02
JP7586935B2 (ja) 2024-11-19

Similar Documents

Publication Publication Date Title
JP7291763B2 (ja) 通信制御方法
US20210168666A1 (en) Communication method and communications apparatus
JP7814477B2 (ja) 通信制御方法、第1ドナー基地局、及びシステム
JP7658003B2 (ja) 通信制御方法
US20210159968A1 (en) Relay apparatus
WO2015027719A1 (zh) 一种协作多流传输数据的方法及基站
JP7495491B2 (ja) 通信制御方法及び通信装置
JP7770528B2 (ja) 通信制御方法、第1ドナーネットワークノード及びセルラ通信システム
US20240032129A1 (en) Communication control method
JP2024156993A (ja) 通信制御方法、中継ノード、プロセッサ、プログラム及びシステム
JP7586935B2 (ja) 通信制御方法
US20240179543A1 (en) Communication control method
JP7592143B2 (ja) 通信制御方法、中継ノード及びプロセッサ
US12621745B2 (en) Communication control method
WO2022030517A1 (ja) 通信制御方法
JP2026071305A (ja) Iabノード、iabノードのチップセット、通信制御方法、第1ドナー基地局、第2ドナー基地局、通信システム及びプログラム

Legal Events

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

Ref document number: 21917690

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022573993

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21917690

Country of ref document: EP

Kind code of ref document: A1