WO2023068258A1 - 通信制御方法 - Google Patents
通信制御方法 Download PDFInfo
- Publication number
- WO2023068258A1 WO2023068258A1 PCT/JP2022/038728 JP2022038728W WO2023068258A1 WO 2023068258 A1 WO2023068258 A1 WO 2023068258A1 JP 2022038728 W JP2022038728 W JP 2022038728W WO 2023068258 A1 WO2023068258 A1 WO 2023068258A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- node
- notification
- routing
- iab
- indication
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 91
- 238000004891 communication Methods 0.000 title claims abstract description 67
- 238000011084 recovery Methods 0.000 claims abstract description 50
- 230000010267 cellular communication Effects 0.000 claims abstract description 24
- 238000001514 detection method Methods 0.000 claims abstract description 7
- 230000008569 process Effects 0.000 claims description 48
- 238000012545 processing Methods 0.000 claims description 48
- 238000013507 mapping Methods 0.000 claims description 43
- 230000009977 dual effect Effects 0.000 claims description 19
- 230000004044 response Effects 0.000 claims description 9
- 238000010586 diagram Methods 0.000 description 44
- 210000004027 cell Anatomy 0.000 description 27
- 101150014328 RAN2 gene Proteins 0.000 description 25
- 230000005540 biological transmission Effects 0.000 description 22
- 238000011144 upstream manufacturing Methods 0.000 description 11
- 230000006870 function Effects 0.000 description 6
- 238000007726 management method Methods 0.000 description 6
- 230000006399 behavior Effects 0.000 description 5
- 230000009849 deactivation Effects 0.000 description 5
- 235000008694 Humulus lupulus Nutrition 0.000 description 4
- 238000012790 confirmation Methods 0.000 description 4
- 230000011664 signaling Effects 0.000 description 4
- 238000012546 transfer Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 230000009467 reduction Effects 0.000 description 3
- 230000006978 adaptation Effects 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 230000003139 buffering effect Effects 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 230000006837 decompression Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 210000004457 myocytus nodalis Anatomy 0.000 description 1
- 238000012913 prioritisation Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B7/00—Radio transmission systems, i.e. using radiation field
- H04B7/14—Relay systems
- H04B7/15—Active relay systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W16/00—Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
- H04W16/24—Cell structures
- H04W16/26—Cell enhancers or enhancement, e.g. for tunnels, building shadow
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/19—Connection re-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W92/00—Interfaces specially adapted for wireless communication networks
- H04W92/16—Interfaces between hierarchically similar devices
- H04W92/20—Interfaces between hierarchically similar devices between access points
Definitions
- the present disclosure relates to a communication control method used in a cellular communication system.
- IAB Integrated Access and Backhaul nodes
- a communication control method is a communication control method used in a cellular communication system.
- the relay node sets a dual connection scheme with a first parent node managing a master cell group as a master node and a second parent node managing a secondary cell group as a secondary node.
- the relay node has detected a radio link failure on one of a first backhaul link with the first parent node and a second backhaul link with the second parent node. sending a first notification indicating detection of the radio link failure to a child node; and if the relay node recovers from the radio link failure after sending the first notification, the radio link failure. and sending a second notification to the child node indicating recovery from.
- a relay node is a relay node used in a cellular communication system.
- the relay node comprises a processor.
- the processor sets a first parent node that manages a master cell group as a master node and a second parent node that manages a secondary cell group as a secondary node, and performs processing for setting a dual connection method, and the first parent node.
- a radio link failure is detected on one of the first backhaul link between and the second backhaul link between the second parent node, a second indicating the detection of the radio link failure and transmitting a second notification indicating recovery from the radio link failure to the child node when recovery from the radio link failure has occurred after the transmission of the first notification. Execute the processing to be performed.
- FIG. 1 is a diagram illustrating a configuration example of a cellular communication system according to one embodiment.
- FIG. 2 is a diagram showing the relationship between IAB nodes, parent nodes, and child nodes.
- FIG. 3 is a diagram illustrating a configuration example of a gNB (base station) according to one embodiment.
- FIG. 4 is a diagram illustrating a configuration example of an IAB node (relay node) according to one embodiment.
- FIG. 5 is a diagram illustrating a configuration example of a UE (user equipment) according to one embodiment.
- FIG. 6 is a diagram showing an example of protocol stacks for IAB-MT RRC connection and NAS connection.
- FIG. 7 is a diagram showing an example protocol stack for the F1-U protocol.
- FIG. 8 is a diagram showing an example protocol stack for the F1-C protocol.
- FIG. 9 is a diagram showing a configuration example between nodes according to the first embodiment.
- FIG. 10 is a diagram showing a configuration example between nodes according to the first embodiment.
- FIG. 11 is a diagram showing an operation example according to the first embodiment.
- FIG. 12 is a diagram illustrating a configuration example between nodes according to the first embodiment.
- FIG. 13 is a diagram showing a configuration example between nodes according to the second embodiment.
- FIG. 14 is a diagram showing an operation example according to the second embodiment.
- FIG. 15 is a diagram showing an operation example according to the third embodiment.
- FIG. 16 is a diagram showing an operation example according to the fourth embodiment.
- FIGS. 10 is a diagram showing a configuration example between nodes according to the first embodiment.
- FIG. 11 is a diagram showing an operation example according to the first embodiment.
- FIG. 12 is a diagram illustrating a configuration example between nodes according to the first
- FIGS. 21A to 21C are diagrams showing configuration examples of topologies according to the seventh embodiment.
- 22A and 22B are diagrams showing an operation example according to the appendix.
- 23A and 23B are diagrams showing an operation example according to the appendix.
- the cellular communication system 1 is a 3GPP 5G system.
- the radio access scheme in the cellular communication system 1 is NR (New Radio), which is a 5G radio access scheme.
- NR New Radio
- LTE Long Term Evolution
- 6G future cellular communication systems such as 6G may be applied to the cellular communication system 1 .
- FIG. 1 is a diagram showing a configuration example of a cellular communication system 1 according to one embodiment.
- a cellular communication system 1 includes a 5G core network (5GC) 10, a user equipment (UE: User Equipment) 100, a base station device (hereinafter sometimes referred to as a "base station") 200. -1, 200-2, and IAB nodes 300-1, 300-2.
- Base station 200 may be referred to as a gNB.
- the base station 200 is an NR base station
- the base station 200 may be an LTE base station (that is, an eNB).
- base stations 200-1 and 200-2 may be called gNB 200 (or base station 200), and IAB nodes 300-1 and 300-2 may be called IAB node 300, respectively.
- the 5GC 10 has AMF (Access and Mobility Management Function) 11 and UPF (User Plane Function) 12.
- the AMF 11 is a device that performs various mobility controls and the like for the UE 100 .
- the AMF 11 manages information on the area in which the UE 100 resides by communicating with the UE 100 using NAS (Non-Access Stratum) signaling.
- the UPF 12 is a device that controls transfer of user data.
- Each gNB 200 is a fixed wireless communication node and manages one or more cells.
- a cell is used as a term indicating the minimum unit of a wireless communication area.
- a cell may be used as a term indicating a function or resource for radio communication with the UE 100.
- One cell belongs to one carrier frequency.
- the terms cell and base station may be used without distinction.
- Each gNB 200 is interconnected with the 5GC 10 via an interface called NG interface.
- NG interface an interface that connects to 5GC 10 to 5GC 10 to 5GC 10 to 5GC 10 to 5GC 10 to 5GC 10.
- Each gNB 200 may be divided into a central unit (CU: Central Unit) and a distributed unit (DU: Distributed Unit).
- CU and DU are interconnected through an interface called the F1 interface.
- the F1 protocol is a communication protocol between the CU and DU, and includes the F1-C protocol, which is a control plane protocol, and the F1-U protocol, which is a user plane protocol.
- the cellular communication system 1 supports IAB that enables wireless relay of NR access using NR for backhaul.
- Donor gNB 200-1 (or donor node, hereinafter sometimes referred to as "donor node") is a network-side NR backhaul termination node and a donor base station with additional functionality to support IAB.
- the backhaul can be multi-hop over multiple hops (ie, multiple IAB nodes 300).
- IAB node 300-1 wirelessly connects with donor node 200-1
- IAB node 300-2 wirelessly connects with IAB node 300-1
- the F1 protocol is carried over two backhaul hops. An example is shown.
- the UE 100 is a mobile radio communication device that performs radio communication with cells.
- UE 100 may be any device as long as it performs wireless communication with gNB 200 or IAB node 300 .
- the UE 100 is a mobile phone terminal, a tablet terminal, a notebook PC, a sensor or a device provided in the sensor, a vehicle or a device provided in the vehicle, an aircraft or a device provided in the aircraft.
- UE 100 wirelessly connects to IAB node 300 or gNB 200 via an access link.
- FIG. 1 shows an example in which UE 100 is wirelessly connected to IAB node 300-2.
- UE 100 indirectly communicates with donor node 200-1 through IAB node 300-2 and IAB node 300-1.
- FIG. 2 is a diagram showing an example of the relationship between the IAB node 300, parent nodes, and child nodes.
- each IAB node 300 has an IAB-DU corresponding to a base station function unit and an IAB-MT (Mobile Termination) corresponding to a user equipment function unit.
- IAB-DU corresponding to a base station function unit
- IAB-MT Mobile Termination
- a neighboring node (ie, upper node) on the NR Uu radio interface of an IAB-MT is called a parent node.
- the parent node is the DU of the parent IAB node or donor node 200 .
- a radio link between an IAB-MT and a parent node is called a backhaul link (BH link).
- FIG. 2 shows an example in which the parent nodes of IAB node 300 are IAB nodes 300-P1 and 300-P2. Note that the direction toward the parent node is called upstream.
- the upper node of the UE 100 can correspond to the parent node.
- Adjacent nodes (ie, lower nodes) on the NR access interface of the IAB-DU are called child nodes.
- IAB-DU like gNB200, manages the cell.
- the IAB-DU terminates the NR Uu radio interface to the UE 100 and subordinate IAB nodes.
- IAB-DU supports the F1 protocol to the CU of donor node 200-1.
- FIG. 2 shows an example in which child nodes of IAB node 300 are IAB nodes 300-C1 to 300-C3, but child nodes of IAB node 300 may include UE100. Note that the direction toward a child node is called downstream.
- all IAB nodes 300 connected to the donor node 200 via one or more hops have a directed acyclic graph (DAG) topology (hereinafter referred to as (sometimes referred to as "topology").
- DAG directed acyclic graph
- adjacent nodes on the IAB-DU interface are child nodes
- adjacent nodes on the IAB-MT interface are parent nodes, as shown in FIG.
- the donor node 200 centralizes, for example, IAB topology resources, topology, route management, and the like.
- Donor node 200 is a gNB that provides network access to UE 100 via a network of backhaul links and access links.
- FIG. 3 is a diagram showing a configuration example of the gNB 200.
- the gNB 200 has a wireless communication unit 210, a network communication unit 220, and a control unit 230.
- the wireless communication unit 210 performs wireless communication with the UE 100 and wireless communication with the IAB node 300.
- the wireless communication section 210 has a receiving section 211 and a transmitting section 212 .
- the receiver 211 performs various types of reception under the control of the controller 230 .
- Reception section 211 includes an antenna, converts (down-converts) a radio signal received by the antenna into a baseband signal (reception signal), and outputs the baseband signal (reception signal) to control section 230 .
- the transmission section 212 performs various transmissions under the control of the control section 230 .
- the transmitter 212 includes an antenna, converts (up-converts) a baseband signal (transmission signal) output from the controller 230 into a radio signal, and transmits the radio signal from the antenna.
- the network communication unit 220 performs wired communication (or wireless communication) with the 5GC 10 and wired communication (or wireless communication) with other adjacent gNBs 200.
- the network communication section 220 has a receiving section 221 and a transmitting section 222 .
- the receiving section 221 performs various types of reception under the control of the control section 230 .
- the receiver 221 receives a signal from the outside and outputs the received signal to the controller 230 .
- the transmission section 222 performs various transmissions under the control of the control section 230 .
- the transmission unit 222 transmits the transmission signal output by the control unit 230 to the outside.
- the control unit 230 performs various controls in the gNB200.
- Control unit 230 includes at least one memory and at least one processor electrically connected to the memory.
- the memory stores programs executed by the processor and information used for processing by the processor.
- a processor may include a baseband processor and a CPU.
- the baseband processor modulates/demodulates and encodes/decodes the baseband signal.
- the CPU executes programs stored in the memory to perform various processes.
- the processor processes each layer, which will be described later.
- the control unit 230 may perform each process or each operation in the gNB 200 in each embodiment described below.
- FIG. 4 is a diagram showing a configuration example of the IAB node 300.
- the IAB node 300 has a radio communication section 310 and a control section 320 .
- the IAB node 300 may have multiple wireless communication units 310 .
- the wireless communication unit 310 performs wireless communication (BH link) with the gNB 200 and wireless communication (access link) with the UE 100.
- the wireless communication unit 310 for BH link communication and the wireless communication unit 310 for access link communication may be provided separately.
- the wireless communication unit 310 has a receiving unit 311 and a transmitting unit 312.
- the receiver 311 performs various types of reception under the control of the controller 320 .
- Receiving section 311 includes an antenna, converts (down-converts) a radio signal received by the antenna into a baseband signal (reception signal), and outputs the baseband signal (reception signal) to control section 320 .
- the transmission section 312 performs various transmissions under the control of the control section 320 .
- the transmitter 312 includes an antenna, converts (up-converts) a baseband signal (transmission signal) output from the controller 320 into a radio signal, and transmits the radio signal from the antenna.
- the control unit 320 performs various controls in the IAB node 300.
- Control unit 320 includes at least one memory and at least one processor electrically connected to the memory.
- the memory stores programs executed by the processor and information used for processing by the processor.
- a processor may include a baseband processor and a CPU.
- the baseband processor modulates/demodulates and encodes/decodes the baseband signal.
- the CPU executes programs stored in the memory to perform various processes.
- the processor processes each layer, which will be described later.
- the control unit 320 may perform each process or each operation in the IAB node 300 in each embodiment described below.
- FIG. 5 is a diagram showing a configuration example of the UE 100. As shown in FIG. As shown in FIG. 5 , UE 100 has radio communication section 110 and control section 120 .
- the wireless communication unit 110 performs wireless communication on the access link, that is, wireless communication with the gNB 200 and wireless communication with the IAB node 300. Also, the radio communication unit 110 may perform radio communication on the sidelink, that is, radio communication with another UE 100 .
- the radio communication unit 110 has a receiving unit 111 and a transmitting unit 112 .
- the receiver 111 performs various types of reception under the control of the controller 120 .
- Reception section 111 includes an antenna, converts (down-converts) a radio signal received by the antenna into a baseband signal (reception signal), and outputs the baseband signal (reception signal) to control section 120 .
- the transmitter 112 performs various transmissions under the control of the controller 120 .
- the transmitter 112 includes an antenna, converts (up-converts) a baseband signal (transmission signal) output from the controller 120 into a radio signal, and transmits the radio signal from the antenna.
- the control unit 120 performs various controls in the UE 100.
- Control unit 120 includes at least one memory and at least one processor electrically connected to the memory.
- the memory stores programs executed by the processor and information used for processing by the processor.
- a processor may include a baseband processor and a CPU.
- the baseband processor modulates/demodulates and encodes/decodes the baseband signal.
- the CPU executes programs stored in the memory to perform various processes.
- the processor processes each layer, which will be described later.
- the control unit 120 may perform each process in the UE 100 in each embodiment described below.
- FIG. 6 is a diagram showing an example of protocol stacks for IAB-MT RRC connection and NAS connection.
- the IAB-MT of the IAB node 300-2 includes a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, and a PDCP (Packet Data Convergence Protocol) layer, an RRC (Radio Resource Control) layer, and a NAS (Non-Access Stratum) layer.
- PHY physical
- MAC Medium Access Control
- RLC Radio Link Control
- PDCP Packet Data Convergence Protocol
- RRC Radio Resource Control
- NAS Non-Access Stratum
- the PHY layer performs encoding/decoding, modulation/demodulation, antenna mapping/demapping, and resource mapping/demapping. Data and control information are transmitted via physical channels between the IAB-MT PHY layer of the IAB node 300-2 and the IAB-DU PHY layer of the IAB node 300-1.
- the MAC layer performs data priority control, hybrid ARQ (HARQ) retransmission processing, random access procedures, and so on. Data and control information are transmitted via transport channels between the MAC layer of the IAB-MT of the IAB node 300-2 and the MAC layer of the IAB-DU of the IAB node 300-1.
- the MAC layer of IAB-DU contains the scheduler. The scheduler determines uplink and downlink transport formats (transport block size, modulation and coding scheme (MCS)) and allocation resource blocks.
- MCS modulation and coding scheme
- the RLC layer uses the functions of the MAC layer and PHY layer to transmit data to the RLC layer on the receiving side. Data and control information are transmitted over logical channels between the IAB-MT RLC layer of IAB node 300-2 and the IAB-DU RLC layer of IAB node 300-1.
- the PDCP layer performs header compression/decompression and encryption/decryption. Data and control information are transmitted between the IAB-MT PDCP layer of IAB node 300-2 and the PDCP layer of donor node 200 via radio bearers.
- the RRC layer controls logical channels, transport channels and physical channels according to radio bearer establishment, re-establishment and release. Between the IAB-MT RRC layer of the IAB node 300-2 and the RRC layer of the donor node 200, RRC signaling for various settings is transmitted. If there is an RRC connection with the donor node 200, the IAB-MT is in RRC connected state. When there is no RRC connection with the donor node 200, the IAB-MT is in RRC idle state.
- the NAS layer located above the RRC layer performs session management and mobility management.
- NAS signaling is transmitted between the NAS layer of the IAB-MT of the IAB node 300-2 and the AMF 11.
- FIG. 7 is a diagram showing a protocol stack for the F1-U protocol.
- FIG. 8 is a diagram showing a protocol stack for the F1-C protocol.
- the donor node 200 is split into CUs and DUs.
- each of the IAB-MT of the IAB node 300-2, the IAB-DU of the IAB node 300-1, the IAB-MT of the IAB node 300-1, and the DU of the donor node 200 is It has a BAP (Backhaul Adaptation Protocol) layer as an upper layer.
- the BAP layer is a layer that performs routing processing and bearer mapping/demapping processing.
- the IP layer is transported over the BAP layer to allow routing over multiple hops.
- BAP layer PDUs Protocol Data Units
- backhaul RLC channels BH NR RLC channels
- Traffic prioritization and QoS control are possible by configuring multiple backhaul RLC channels on each BH link.
- the association between BAP PDUs and backhaul RLC channels is performed by the BAP layer of each IAB node 300 and the BAP layer of the donor node 200 .
- the F1-C protocol stack has an F1AP layer and an SCTP layer instead of the GTP-U layer and UDP layer shown in FIG.
- the processing or operations performed by the IAB's IAB-DU and IAB-MT may be simply described as "IAB" processing or operations.
- the IAB-DU of the IAB node 300-1 sends a BAP layer message to the IAB-MT of the IAB node 300-2, and the IAB node 300-1 sends the message to the IAB node 300-2.
- DU or CU processing or operations of donor node 200 may also be described simply as "donor node” processing or operations.
- upstream direction and the uplink (UL) direction may be used without distinction.
- downstream direction and the downlink (DL) direction may be used interchangeably.
- Type 2 BH RLF Indication and Type 3 BH RLF Indication according to the first embodiment will be described.
- FIG. 9 is a diagram showing a configuration example between nodes according to the first embodiment.
- the cellular communication system 1 shown in FIG. 9 includes an IAB node 300-T, parent nodes (IAB nodes) 300-P1 and 300-P2, and child nodes (IAB nodes) 300-C.
- the IAB node 300-P1 is the parent node of the IAB node 300-T.
- IAB node 300-P1 may be referred to as parent node 300-P1.
- a backhaul link (BH link) #1 is established between the IAB-DU of the parent node 300-P1 and the IAB-MT of the IAB node 300-T.
- the parent node 300-P1 may be (the DU#1 of) the donor node 200.
- the IAB node 300-P2 is also the parent node of the IAB node 300-T.
- IAB node 300-P2 may be referred to as parent node 300-P2.
- a BH link #2 is also established between the IAB-DU of the parent node 300-P2 and the IAB-MT of the IAB node 300-T.
- the parent node 300-P2 may be (the DU#2 of) the donor node 200.
- the IAB node 300-C is a child node of the IAB node 300-T.
- the IAB node 300-C may be referred to as a child node 300-C.
- a BH link #3 is also established between the IAB-MT of the child node 300-C and the IAB-DU of the IAB node 300-T.
- BH RLF Radio Link Failure
- the IAB-DU of the IAB node 300-T can send a Type 1 BH RLF Indication (hereinafter sometimes referred to as "Type 1 Indication") to the child node 300-C on the downstream side.
- Type 1 Indication is an example of a failure notification indicating that BH RLF has been detected.
- Type 2 Indication is an example of a recovery attempt notification (or failure occurrence notification) indicating that recovery from BH RLF is being attempted.
- Type 1/2 Indication BH RLF Indication
- Type 1/2 Indication is also an example of failure notification.
- Type 1 Indication may be read as Type 2 Indication.
- Type 1 Indication is sent at the time of BH RLF detection, and Type 2 Indication is sent at the time of recovery attempt.
- the IAB-MT of the IAB node 300-T performs recovery trial processing of the BH RLF immediately after the BH RLF is issued. Therefore, two Indications can be regarded as substantially the same Indication.
- Type 3 Indication may be a recovery notification indicating that the BH link has recovered from the BH RLF.
- Type 4 Indication is also a failure notification indicating that the BH link has failed to recover from the BH RLF.
- FIG. 9 shows an example in which the IAB node 300-T transmits a Type 2 Indication to the child node 300-C.
- Type BH RLF Indications may be included in the BAP Control PDU or MAC CE and transmitted.
- IAB node 300-T can utilize resources provided by two different parent nodes 300-P1 and 300-P2.
- One parent node can be a master node (MN) that manages a master cell group (hereinafter sometimes referred to as "MCG”).
- MCG master cell group
- SCG secondary cell group
- a MCG is a cell group of serving cells associated with a master node.
- the MCG comprises a primary cell (Sp-Cell or P-Cell) and optionally one or more secondary cells (S-Cells).
- a SCG is a group of serving cells associated with a secondary node.
- the SCG comprises a primary cell (Sp-Cell or PS-Cell) and optionally one or more secondary cells (S-Cells).
- the Sp cell is the primary cell in the MCG and also the primary cell in the SCG.
- the master node and secondary nodes are logical entities.
- the following description assumes that the master node corresponds to the parent node 300-P1 and the secondary node corresponds to the parent node 300-P2.
- the IAB node 300-T can connect to the secondary node by managing the SCG while connecting to the master node that manages the MCG.
- the IAB node 300-T simultaneously connects to each parent node 300-P1 and 300-P2 to perform wireless communication. As a result, the throughput of the IAB node 300-T can be improved.
- EN-DC (E-UTRA (Evolved Universal Terrestrial Radio Access)-NR Dual Connectivity)
- E-UTRA Evolved Universal Terrestrial Radio Access
- NR Dual Connectivity EN-DC
- the IAB node 300-T is connected with one eNB (evolved Node B) functioning as a master node and connected with one en-gNB functioning as a secondary node.
- An eNB is an LTE base station that provides E-UTRA services.
- en-gNB is an NR base station that provides NR service.
- NR base station that provides NR service.
- the parent node 300-P1 that is the master node can be the eNB, and the parent node 300-P2 that is the secondary node can be the en-gNB.
- MCG performs processing related to control (C-Plane).
- SCG processes data (U-Plane).
- NR-DC NR-NR Dual Connectivity
- MCG and SCG are capable of handling control and data. So, for example, IAB node 300-T can simultaneously transmit data to and receive data from parent nodes 300-P1 and 300-P2, both of which are gNBs.
- Type 2 Indication is generated (or transmitted) when BH RLF (hereinafter sometimes referred to as “RLF”) is detected in case of single connection.
- RLF BH RLF
- FIG. 9 shows an example of the former case
- FIG. 10 shows an example of the latter case.
- the child node 300-C that received the Type 2 Indication does not know whether the RLF is occurring on the MCG side or the SCG side just by receiving the Type 2 Indication. Sometimes.
- the IAB node 300-T can add additional information to the Type 2 Indication and transmit it.
- the child node 300-C that has received the additional information can perform routing processing or rerouting processing based on the additional information.
- RLF may occur (simultaneously) on both the MCG side and the SCG side.
- the child node 300-C receives the Type 2 Indication corresponding to the RLF generated on the MCG side and the Type 2 Indication corresponding to the RLF generated on the SCG side.
- the IAB node 300-T transmits Type 3 Indication to the child node 300-C.
- the IAB node 300-T adds additional information to the Type 3 Indication and transmits it to the child node 300-C.
- the relay node uses the first parent node (eg, parent node 300-P1) that manages the master cell group as the master node, and the secondary cell group as the master node.
- a dual connection scheme is set with a second parent node to manage (eg, parent node 300-P2) as a secondary node.
- the relay node has a first backhaul link (eg, BH link #1) with the first parent node and a second backhaul link (eg, BH link #1) with the second parent node.
- a second notification (eg, Type 3 Indication) indicating recovery from a radio link failure that occurred in at least one of them is transmitted to the child node (eg, child node 300-C).
- the second notification includes second additional information, and the second additional information indicates at least the second routing ID that has become available.
- the child node 300-C can perform appropriate processing based on the routing ID that has become available, such as returning to normal routing operation when local rerouting has been performed. .
- a routing ID is composed of a destination BAP address (Destination) and a path identifier (Path ID).
- FIG. 11 is a diagram showing an operation example according to the first embodiment.
- step S10 the IAB node 300-T starts processing.
- DC is set for the IAB node 300-T after step S10 and before step S11. That is, in the IAB node 300-T, a DC is set with the parent node 300-P1 that manages the MCG as the master node and the parent node 300-P2 that manages the SCG as the secondary node.
- the IAB node 300-T detects the RLF (or detects that it is being restored from the RLF).
- the RLF may be BH link #1 on the MCG side or BH link #2 on the SCG side. Also, RLF may occur simultaneously in BH link #1 on the MCG side and BH link #2 on the SCG side.
- the IAB-MT of the IAB node 300-T may detect the RLF on a RLF by RLF basis, whether the RLF occurs on each BH link at the same time or separately.
- the IAB node 300-T transmits a Type 2 Indication to the child node 300-C.
- the IAB node 300-T independently transmits Type 2 Indication for each detected RLF. For example, when the IAB node 300-T detects an RLF generated on the BH link #1 on the MCG side, it transmits a Type 2 Indication corresponding to the RLF, and when it detects an RLF generated on the BH link #2 on the SCG side, Send a Type 2 Indication corresponding to the relevant RLF.
- the IAB node 300-T adds additional information to the Type 2 Indication and transmits it.
- the additional information may be information about routes affected by the RLF.
- the additional information includes unusable CG (for example, information indicating whether MCG is unusable or SCG is unusable), unusable routing ID, and unusable link quality. At least one may be included. Furthermore, the additional information may include an unusable BH RLC channel ID (BH RLC channel ID). By receiving an unusable BH RLC channel ID, the child node 300-C can stop transmission to that BH RLC channel or perform routing to other BH RLC channels. .
- unusable CG for example, information indicating whether MCG is unusable or SCG is unusable
- unusable routing ID for example, information indicating whether MCG is unusable or SCG is unusable
- unusable link quality At least one may be included.
- the additional information may include an unusable BH RLC channel ID (BH RLC channel ID).
- Child node 300-C will be described below assuming that upon receiving a Type 2 Indication containing additional information, local rerouting to another parent node is performed. Local rerouting is, for example, switching transmission from one parent node to another parent node on an alternate path.
- child node 300-C is routed from IAB node 300-T (the parent node for child node 300-C) to another IAB node (another parent node for child node 300-C) on an alternate path. Toggle sending to.
- the IAB node 300-T detects recovery of the RLF occurring in the BH link.
- the IAB node 300-T independently detects recovery from RLF on the MCG side and recovery from RLF on the SCG side.
- step S14 the IAB node 300-T transmits Type 3 Indication to the child node 300-C.
- the IAB node 300-T detects recovery from the RLF on the MCG side, it transmits a Type 3 Indication corresponding to the recovery, and upon detecting recovery from the RLF on the RCG side, it transmits a Type 3 Indication corresponding to the recovery. .
- FIG. 12 is a diagram showing a configuration example between nodes according to the first embodiment. As shown in FIG. 12, the IAB node 300-T transmits Type 3 Indication to the child node 300-C.
- the IAB node 300-T adds additional information to the Type 3 Indication and transmits it.
- the additional information may be information on routes affected by the restoration.
- the additional information includes the CG that has become available (for example, information indicating whether the MCG or SCG has become available), the routing ID that has become available, and the link that can be used. Includes quality (for example, update of available throughput) and/or BH RLC channel IDs that have become available.
- step S15 in response to receiving the Type 3 Indication, the child node 300-C stops the local rerouting operation and performs normal routing operation according to the additional information. For example, child node 300-C stops local rerouting for routing IDs that become available. Further, for example, it is assumed that the child node 300-C has received routing ID #1 that has become available as additional information, and has performed local rerouting for routing ID #2. In this case, routing ID #2 is still a disabled routing ID. Child node 300-C will continue local rerouting for routing ID #2.
- the child node 300-C that has received the additional information can grasp the information of the route affected by the restoration, and can control communication according to the additional information.
- step S16 the child node 300-C ends the series of processes.
- the IAB node 300-T transmits Type 3 Indication including additional information to the child node 300-C.
- the IAB node 300-T may transmit a Type 3 Indication that does not contain additional information.
- child node 300-C may determine that all routing IDs of the BH links associated with that Type3 Indication are now available.
- inter-donor DU rerouting may occur.
- the inter-donor rerouting is, for example, rerouting in which the route is switched from the first DU of the donor node 200 to the second DU of the donor node 200 .
- FIG. 13 is a diagram showing a configuration example between nodes according to the second embodiment.
- FIG. 13 represents an example of inter-donor rerouting.
- DU #1 of donor node 200 (hereinafter, “donor DU #1”) (200D1) is transferred to DU #2 of donor node 200 (hereinafter, “donor DU #2”). (200D2).
- the destination of packets in the upstream direction is changed from the BAP address of donor DU#1 to the BAP address of donor DU#2.
- FIG. 13 shows an example in which DC settings are performed in the IAB node 300-T and the parent nodes 300-P1 and 300-P2.
- the IAB node 300-T detects RLF on the BH link on the MCG side or the BH link on the SCG side, it can transmit a Type 2 Indication including additional information.
- the IAB node 300-T detects the RLF on the BH link on the MCG side, as the additional information, all the destinations (Destination: BAP address of donor DU # 1) linked to the MCG side A routing ID may also be sent.
- the IAB node 300-T detects RLF on the BH link on the SCG side, as the additional information, the IAB node 300-T has a destination (Destination: BAP address of donor DU#2 (200D2)) linked to the SCG side. All routing IDs may be sent.
- the IAB node 300-T transmits all the routing IDs associated with the destination as additional information, the additional information overhead is large.
- the IAB node 300-T transmits the disabled destination BAP address to the child node 300-C as additional information of Type 2 Indication.
- a relay node for example, the IAB node 300-T
- a parent node for example, the parent node 300-P1
- the relay node sends a first notification to the child node (eg, child node 300-C) indicating that it is attempting to recover from the radio link failure.
- the first notification includes additional information, and the additional information includes the destination BAP address.
- the IAB node 300-T can reduce the size of the additional information added to the Type 2 Indication and suppress the overhead of the additional information.
- FIG. 14 is a diagram showing an operation example according to the second embodiment.
- the IAB node 300-T starts processing in step S20.
- the IAB node 300-T detects the RLF (or detects that it is being restored from the RLF).
- the IAB node 300-T identifies routable routing IDs and non-routable routing IDs. Specifically, for example, it is as follows.
- a single connection is a form in which the IAB node 300-T does not have an alternative path and is connected only to one parent node 300-P.
- all routing IDs are non-routable routing IDs because there is no alternate path. In this case there is no routable routing ID. Therefore, in the case of a single connection, all routing IDs can be non-routable routing IDs.
- the second is the case of DC connection.
- an IAB node 300-T is simultaneously connected to two parent nodes 300-P1 and 300-P2. It should be noted that when the DC connection is made, the DC setting is made for the IAB node 300-T between steps S20 and S21.
- routing or rerouting may be done by an intra-donor-DU ("Intra-donor-DU").
- the intra-donor DU has the same destination and multiple routes.
- intra-donor DU although RLF is detected, some routing IDs cannot be used because there are alternative paths, but other routing IDs can be used.
- inter-donor-DU In the case of DC connections, routing or rerouting may occur between donor DUs ("Inter-donor-DU").
- the inter-donor DU is, for example, a form in which routing or rerouting is performed between DUs of different donor nodes, as shown in FIG.
- the Destination for example, the BAP address of donor DU#1 (200D1)
- the Destination upstream of the BH link on which the RLF is occurring becomes routable. Therefore, all routing IDs with this Destination are disabled.
- BAP address of donor DU #2 (200D2) upstream of another BH link, since RLF is not detected on the route, all routing IDs having this Destination are available.
- step S23 the IAB node 300-T confirms the destination of the routing ID that cannot be routed.
- the IAB node 300-T checks whether a destination with a non-routable routing ID exists in a destination with a routable routing ID.
- the IAB node 300-T adds the destination of the routing ID that is not routable to the additional information of Type 2 Indication include in
- the additional information includes the destination of the routing ID that cannot be routed.
- the destination of the unroutable routing ID (BAP address of donor DU#1 (200D1)) and the destination of the routable routing ID (donor DU#2 (200D2)) is a different destination. Therefore, it applies when the destination of the unroutable routing ID (BAP address of donor DU#1 (200D1)) does not exist in the destination of the routable routing ID (BAP address of donor DU#2 (200D2)). do. Therefore, in this case, the destination (BAP address of donor DU #1 (200D1)) of the routing ID that cannot be routed is included in the additional information.
- the IAB node 300-T includes a list of routing IDs that are not routable in the additional information when the destination of the routing ID that is not routable exists in the destination of the routing ID that is routable.
- the IAB node 300-T includes in the additional information a list of routing IDs for which routing IDs are not possible.
- step S24 the IAB node 300-T transmits Type 2 Indication including the additional information to the child node 300-C.
- step S25 the child node 300-T determines that all routing IDs having the Destination are unusable in response to receiving the Type 2 Indication. Since the additional information includes a destination that cannot be routed, the child node 300-T determines that the routing ID including the destination is an unusable routing ID.
- step S26 the child node 300-T ends the series of processes.
- the IAB node 300-T can prevent transmission of Type 2 Indication to the child node 300-C even if RLF occurs on the MCG side. This is because the IAB node 300-T can use the SCG to transfer data to the parent node 300-P2.
- the IAB node 300-T it may be complicated to determine the type of DC and whether the SCG or MCG is processing data. If the IAB node 300-T can transmit or not transmit the Type 2 Indication without judging the type of DC, it will be possible to perform processing easily.
- the Type 2 Indication is not transmitted unless a route that cannot be used by RLF exists in the routing table and/or the mapping table. Also, in the third embodiment, an example will be described in which a Type 2 Indication is sent if an unusable route exists in the routing table and/or the mapping table.
- the relay node manages the first parent node (eg, parent node 300-P1) that manages the master cell group as the master node and the secondary cell group.
- a dual connection scheme is set with a second parent node (for example, parent node 300-P2) as a secondary node.
- the relay node detects a radio link failure that has occurred in at least one of the first backhaul link with the first parent node and the second backhaul link with the second parent node. do.
- the relay node indicates that it is attempting to recover from a radio link failure if there is first route information in the routing table and/or mapping table indicating an unusable route due to the radio link failure.
- the first notification (eg, Type 2 Indication) is sent to the child node (eg, child node 300-C) and the first route information does not exist in the routing table and/or the mapping table, the first notification is sent to the child node do not send.
- the IAB node 300-T can transmit the Type 2 Indication with reduced complicated processing.
- FIG. 15 is a diagram showing an operation example according to the third embodiment.
- the IAB node 300-T starts processing in step S30.
- IAB node 300-T performs DC setting between steps S30 and S31, as in the first embodiment.
- IAB node 300-T is capable of wireless communication simultaneously with parent nodes 300-P1 and 300-P2.
- step S31 the IAB-MT of the IAB node 300-T detects RLF.
- the IAB node 300-T may continue to perform RRC re-establishment procedures, MCG Failure Information procedures, and SCG Failure Information procedures.
- step S32 the RRC layer of the IAB-MT of the IAB node 300-T transmits the first information indicating that the RLF has been detected (or that the BH link is being restored) to the IAB node 300-T. Output to the BAP layer of the IAB-DU.
- the RRC layer may output the first information to the BAP layer of the IAB-DU of the IAB node 300-T via the F1AP layer of the IAB-DU of the IAB node 300-T.
- the first information may include information indicating on which link the RLF occurred. Specifically, the first information may include information indicating whether RLF has occurred in the MCG or whether the RLF has occurred in the MCG. Also, the first information may include an outflow BH link ID (egress BH link ID) that designates the BH link in which the RLF occurs as an outflow BH link. Further, the first information may include the Next hop BAP address of the IAB node 300-T on the BH link where the RLF occurred. The first information may include at least one of information indicating MCG or SCG, outgoing BH link ID, and next hop BAP address.
- outflow BH link ID egress BH link ID
- step S33 the BAP layer confirms whether or not there is an unusable route in response to the input of the first information. Specifically, the BAP layer determines whether route information corresponding to (or including the first information) exists in the routing configuration (or routing table) and/or the mapping configuration (or mapping table). to confirm.
- the confirmation for the routing table is as follows.
- the BAP layer confirms whether or not the route information (here, routing ID and/or outflow BH link) corresponding to the first information exists in the routing table.
- the confirmation for the mapping table is, for example, as follows.
- the BAP layer confirms whether or not the route information (here, egress BH RLC channel) corresponding to the first information exists in the mapping table.
- step S34 if an unusable route exists in the routing table and/or mapping table (YES in step S34), the BAP layer performs the processing of step S35. On the other hand, in step S34, the BAP layer performs the process of step S38 if no usable route exists in the routing table and/or mapping table (NO in step S34).
- a case where an unusable route exists is a case where route information corresponding to the first information exists in the routing table and/or the mapping table. For example, if the RLF occurs on the MCG side, the route information on the MCG side exists in the routing table and/or the mapping table. In such a case, the BAP layer performs steps S35 and S36.
- a case where there is no unusable route is a case where the route information corresponding to the first information does not exist in the routing table and/or the mapping table.
- the BAP layer does not transmit Type 2 Indication even if it receives the first information from the RRC layer.
- the BAP layer can prevent Type 2 Indication from being sent. Become. Therefore, the BAP layer performs the process of step S38.
- step S35 the BAP layer identifies unusable routes.
- the BAP layer identifies unusable routes so that lower nodes (for example, child node 300-C) can grasp them. That is, when the BAP layer determines steps S33 and S34 using the routing ID as route information (when the routing ID corresponds to an unusable route), the routing ID is used as it is to It may be identified as a possible route. In addition, when the BAP layer determines steps S33 and S34 using an outflow BH link as route information (when the outflow BH link corresponds to an unusable route), the inflow BH link corresponding to the outflow BH link is determined. An ingress BH link may be identified as an unusable route.
- the BAP layer determines steps S33 and S34 using the outflow BH RLC channel as route information (when the outflow BH RLC channel corresponds to an unusable route)
- the outflow BH RLC channel A corresponding ingress BH RLC channel may be identified as an unusable route.
- the BAP layer transmits Type 2 Indication.
- the BAP layer may transmit the Type 2 Indication only to the child node 300-C connected to the route identified in step S35.
- the BAP layer may transmit the Type 2 Indication only to the child node 300-C connected to the incoming BH link identified as an unusable route. In this case, the BAP layer does not need to send Type 2 Indication to child nodes that are not connected to the specified incoming BH link.
- Type 2 Indication may include an unusable route as additional information.
- An unusable route may be an unusable routing ID or the like.
- step S37 the IAB node 300-T ends the series of processes.
- step S38 the BAP layer does not transmit Type 2 Indication.
- step S38 the IAB node 300-T ends the series of processes.
- 3rd Embodiment demonstrated the example which a BAP layer processes step S35 from step S33.
- the F1AP layer of the IAB-DU of the IAB node 300-T may perform the processing from step S33 to step S35.
- the operation in this case is, for example, as follows.
- step S32 the IAB-DU RRC layer of the IAB node 300-T outputs the first information to the F1AP layer.
- the F1AP layer may perform similar processing.
- the F1AP layer outputs the unusable route identified in step S35 to the IAB-DU BAP layer of the IAB node 300-T.
- the BAP layer may perform the processing after step S36.
- the relay node detects that it has recovered from the radio link failure. Secondly, the relay node has recovered from the radio link failure if there is second route information in the routing table and/or the mapping table indicating a route that can be used due to the recovery from the radio link failure. to the child node (eg, child node 300-C), and if the second route information does not exist in the routing table and/or the mapping table, the second notification is sent to the child node Do not send to
- FIG. 16 is a diagram showing an operation example according to the fourth embodiment.
- step S40 the IAB node 300-T starts processing.
- IAB node 300-T performs DC setting between steps S40 and S41, as in the third embodiment.
- IAB node 300-T is capable of wireless communication simultaneously with parent nodes 300-P1 and 300-P2.
- step S41 the IAB-MT of the IAB node 300-T detects RLF.
- step S42 the RRC layer of the IAB-MT of the IAB node 300-T outputs the second information indicating recovery from the RLF to the BAP layer of the IAB-DU of the IAB node 300-T.
- the second information may include information indicating which link's RLF has recovered. Specifically, the second information may include information indicating whether the recovery was made with the MCG or whether the recovery was made with the MCG. Also, the second information may include an outflow BH link ID (egress BH link ID) that designates the recovered BH link as an outflow BH link. Additionally, the second information may include the Next hop BAP address of the IAB node 300-T on the restored BH link. The second information may include at least one of information indicating MCG or SCG, outflow BH link ID, and next hop BAP address.
- step S43 the BAP layer confirms whether or not there is a usable route in response to the input of the second information. Specifically, the BAP layer determines whether route information corresponding to (or including) the second information exists in the routing configuration (or routing table) and/or the mapping configuration (or mapping table). to confirm.
- the confirmation for the routing table is as follows.
- the BAP layer checks whether route information (here, routing ID and/or outflow BH link) corresponding to (or including) the second information exists in the routing table.
- route information here, routing ID and/or outflow BH link
- the confirmation for the mapping table is, for example, as follows.
- the BAP layer checks whether the route information (here, egress BH RLC channel) corresponding to (or including) the second information exists in the mapping table. do.
- step S44 if the available route exists in the routing table and/or mapping table (YES in step S44), the BAP layer performs the processing of step S45. On the other hand, in step S44, if the available route does not exist in the routing table and/or the mapping table (NO in step S44), the BAP layer performs the processing of step S48.
- a case where a usable route exists is a case where route information corresponding to the second information exists in the routing table and/or the mapping table. For example, if recovery from RLF occurs on the MCG side, the route information on the MCG side is present in the routing table and/or the mapping table. In such a case, the BAP layer performs steps S45 and S46.
- the route information corresponding to the second information does not exist in the routing table and/or mapping table.
- the route information on the MCG side does not exist in the routing table and/or the mapping table.
- the BAP layer does not transmit Type 3 Indication even if it receives the second information from the RRC layer. Therefore, the BAP layer performs the process of step S48.
- the BAP layer identifies unusable routes.
- the BAP layer identifies routes that have become available so that lower nodes (eg, child node 300-C) can see them. That is, the BAP layer can identify the routing ID, ingress BH link, or ingress BH RLC channel as a route that has become available, as in the third embodiment. good.
- the BAP layer transmits Type 2 Indication.
- the BAP layer may transmit the Type 3 Indication only to the child node 300-C connected to the route identified in step S45.
- the BAP layer may transmit Type 3 Indication only to the child node 300-C connected to the specified incoming BH link. In this case, the BAP layer does not need to send Type 2 Indication to child nodes that are not connected to the specified incoming BH link.
- Type 3 Indication may include the available route as additional information.
- the routes that have become available include routing IDs that have become available.
- step S47 the IAB node 300-T ends the series of processes.
- step S48 if there is no unusable route (NO in step S44), the BAP layer does not transmit Type 3 Indication.
- step S48 the IAB node 300-T ends the series of processes.
- the processing from step S43 to step S45 may be performed by the IAB-DU F1AP layer of the IAB node 300-T. That is, steps S43 to S45 may be performed by the F1AP layer instead of the BAP layer.
- the F1AP layer outputs the route information identified in step S45 to the IAB-DU BAP layer of the IAB node 300-T. Then, the BAP layer may perform the processing after step S46.
- the IAB node 300-T may transmit a Type 2 Indication including an unusable routing ID to the child node 300-C. Further, in the fourth embodiment, it was explained that the IAB node 300-T may transmit the Type 2 Indication including the available routing ID to the child node 300-C.
- the specific operations in the BAP layer when the child node 300-C receives a Type 2 Indication containing an unusable routing ID and a Type 3 Indication containing a usable routing ID An example will be described.
- the relay node eg, IAB node 300-T
- a first notification eg, Type 2 Indication
- the relay node sends a first notification (eg, Type 2 Indication) indicating that it is attempting recovery from a radio link failure to a child node ( For example, it is transmitted to the child node 300-C).
- a first notification eg, Type 2 Indication
- the child node performs a first routing process assuming that the first routing ID does not exist in the routing table.
- a second indication e.g., Type 3 Indication
- the child node uses the entry in the routing table that includes the second routing ID to perform the second Perform routing processing.
- FIGS. 17A and 17B are diagrams showing configuration examples between nodes according to the fifth embodiment.
- FIG. 18 is a diagram showing an operation example according to the fifth embodiment. The operation example shown in FIG. 18 will be described with appropriate reference to the configuration examples shown in FIGS. 17A and 17B.
- the child node 300-C starts processing in step S50.
- step S51 the BAP layer of child node 300-C receives Type 2 Indication from parent node 300-P1.
- FIG. 17(A) shows an example in which the child node 300-C receives the Type 2 Indication.
- the Type 2 Indication contains, as additional information, a routing ID that has become unroutable due to RLF.
- the BAP layer of the child node 300-C performs routing processing assuming that the entry does not exist in the routing table. That is, the BAP layer assumes that the entry containing the routing ID included in the Type 2 Indication does not exist in the routing table (or is an unusable entry), and performs routing processing. In this case, since the BAP entry does not exist in the routing table, a search is made for an entry in the routing table that matches the destination of the routing ID, and local rerouting is performed to the routing ID of the entry.
- the first routing process for example, corresponds to such local rerouting process.
- FIG. 17A shows an example in which the child node 300-C switches the route to the parent node 300-P2 by the local rerouting process.
- the child node 300-C receives Type 3 Indication from the parent node 300-P1.
- FIG. 17B shows an example in which the child node 300-C receives the Type 3 Indication.
- the Type 3 Indication contains, as additional information, a routing ID that has become routable due to recovery from the RLF.
- step S54 the child node 300-C searches the routing table for an entry corresponding to the routing ID. conduct. That is, the child node 300-C stops the local rerouting process and performs the normal routing process because the entry exists in the routing table.
- FIG. 17B shows an example in which the child node 300-C switches the route from the parent node 300-P2 to the parent node 300-P1.
- step S55 the child node 300-C ends the series of processes.
- FIG. 19 is a diagram showing a configuration example between nodes according to the sixth embodiment.
- the child node 300-C receives a Type 2 Indication from the parent node 300-P, as shown in FIG. In this case, if the child node 300-C fails to receive the Type 3 Indication or the Type 4 Indication from the parent node 300-P after that, the child node 300-C does not know what kind of processing should be performed. There is also
- the parent node 300-P was unable to send Type 3 Indication and Type 4 Indication for some reason. Also, even if the parent node 300-P transmits Type 3 Indication and Type 4 Indication, the child node 300-C may not receive them for some reason.
- the child node 300-C starts counting a timer when it receives a Type 2 Indication, and when the count value reaches a predetermined value, BH link restoration processing is started.
- a relay node receives a timer value setting from a donor node (eg donor node 200).
- a first notification e.g., Type 2 Indication.
- the relay node starts counting with a timer upon receiving the first notification.
- a second notification for example, Type 3 Indication
- a third notification for example, Type 4 Indication
- FIG. 20 is a diagram showing an operation example according to the sixth embodiment.
- the child node 300-C starts processing in step S60.
- the child node 300-C receives the setting of the timer value from the donor node 200 or the parent node 300-P.
- Child node 300-C may receive the setting of the timer value from donor node 200 using an RRC message or an F1AP message.
- the child node 300-C may receive the setting of the timer value from the parent node 300-P using the BAP Control PDU.
- the child node 300-C receives the Type 2 Indication from the parent node 300-P.
- the child node 300-C starts counting the timer in response to receiving the Type 2 Indication.
- step S63 the child node 300-C determines whether it has received a Type 3 Indication or a Type 4 Indication from the parent node 300-P.
- the child node 300-C receives the Type 3 Indication or the Type 4 Indication from the parent node 300-P (YES in step S63)
- it performs the process of step S64.
- the child node 300-C does not receive the Type 3 Indication or the Type 4 Indication from the parent node 300-P (NO in step S63)
- step S64 the child node 300-C stops counting the timer.
- step S65 the child node 300-C ends the series of processes.
- step S66 the child node 300-C determines whether the count value of the timer has reached the timer value (whether the timer has expired). When the count value of the timer reaches the timer value (YES in step S66), the child node 300-C performs the process of step S67. On the other hand, if the count value of the timer has not reached the timer value (NO in step S66), the child node 300-C proceeds to step S63 and repeats the above-described processing.
- step S67 the child node 300-C performs restoration processing.
- the recovery process may be an RLF declaration.
- the child node 300-C may declare the RLF generated in the BH link of the parent node 300-P.
- the recovery process may be execution of an RRC re-establishment procedure.
- child node 300-C may initiate an RRC re-establishment procedure towards parent node 300-P.
- the recovery process may be the execution of the MCG Failure Information procedure or the SCG Failure Information procedure according to the additional information included in the Type 2 Indication. For example, if the additional information includes information indicating RLF on the MCG side, the child node 300-C executes the MCG failure information procedure, and if the additional information includes information indicating RLF on the SCG side , may perform the SCG failure information procedure.
- step S65 the child node 300-C ends the series of processes.
- 3GPP is studying how to perform rerouting in a network (or topology) formed by multiple IAB nodes 300 .
- routing is, for example, controlling to which IAB node 300 the received packet is transferred.
- FIG. 21A shows a topology configuration example in the “Inside CU/Inside Donor DU” scenario.
- Rerouting (S1-2) in this scenario is so-called local rerouting.
- the IAB node 300-1 detects the BH RLF for the IAB node 300-2, it performs rerouting by switching to a route via the IAB node 300-3, which is an alternative path, for packets in the uplink direction.
- FIG. 21B is a diagram showing a configuration example of the topology in the “Intra-CU/Between Donor-DU” scenario.
- the donor DU that is the destination of the packet is changed from donor DU#1 (200D1) to donor DU#2 (200D2). That is, the destination BAP address of the packet is changed. Therefore, 3GPP has agreed to rewrite the BAP header in this scenario. Rewriting the BAP header is to rewrite the BAP header from the previous routing ID to the new routing ID.
- FIG. 21C is a diagram showing a configuration example of the topology in the “Between CUs” scenario.
- donor CU#1 200C1
- donor CU#2 200C2
- a donor DU#1 200D1
- a donor DU#2 200D2
- a donor CU#2 200C2
- a topology formed by a route from donor CU#1 (200C1) to IAB node 300-1 and a topology formed by a route from donor CU#2 (200C2) to IAB node 300-1 It can be a topology different from the topology (second topology).
- IAB node 300-1 is located at the boundary of two different topologies. Such an IAB node 300-1 may be called a boundary IAB node.
- the border IAB node 300-1 can forward packets destined for donor DU#1 (200D1) via the topological alternative path in donor CU#2 (200C2). .
- the border IAB node 300-1 maintains the F1 connection with donor CU#1 (200C1), which is the source donor node, while maintaining donor CU#2, which is the target donor node. It was agreed that it may be applied in the RRC Re-establishment state for (200C2).
- IAB node 300-4 and IAB node 300-5 receive Type 2 Indication from IAB node 300-1.
- Type 2 Indication includes the additional information described in the first embodiment.
- the IAB node 300-4 and the IAB node 300-5 receive Type 3 Indication from the IAB node 300-1.
- Type 3 Indication includes the additional information described in the first embodiment.
- the IAB node 300-4 receives the Type 2 Indication from the IAB node 300-1.
- Type 2 Indication includes the additional information described in the first embodiment.
- the IAB node 300-4 receives Type 3 Indication from the IAB node 300-1.
- Type 3 Indication includes the additional information described in the first embodiment.
- IAB node 300-1 detects RLF in the BH link with IAB node 300-2.
- the IAB node 300-1 confirms the BAP address of the donor DU#1 (200D1) as the destination of the routing ID that cannot be routed.
- IAB node 300-1 transmits Type 3 Indication including the BAP address to IAB node 300-4.
- the operation examples, processes, etc. described in the third embodiment are applicable to scenario (S1-2), scenario (S2-2), and scenario (S3-2). That is, for example, when the IAB node 300-1 detects RLF on the BH link with the IAB node 300-2, there must be route information unusable by RLF in the routing table and/or the mapping table. For example, Type 2 Indication is not sent to lower nodes. The IAB node 300-1 transmits a Type 2 Indication to lower nodes if route information that cannot be used by RLF exists in the routing table and/or the mapping table.
- the operation examples, processes, etc. described in the fourth embodiment are applicable to scenario (S1-2), scenario (S2-2), and scenario (S3-2). That is, for example, when the IAB node 300-1 detects recovery from RLF on the BH link with the IAB node 300-2, the route information made available by the recovery is stored in the routing table and/or the mapping table. , the Type 3 Indication is not sent to the lower node. The IAB node 300-1 transmits a Type 3 Indication to the lower nodes if the route information made available by the restoration exists in the routing table and/or the mapping table.
- the IAB node 300-4 receives Type 2 Indication from the IAB node 300-1. If the additional information includes a routing ID that has become unusable due to RLF, the IAB node 300-4 performs the first routing processing assuming that the routing table does not have an entry including the routing ID. IAB node 300-4 also receives Type 3 Indication from IAB node 300-1. If the additional information includes a routing ID that has become usable by recovery from the RLF, the IAB node 300-4 uses the entry included in the routing table to perform the second routing process.
- the operation examples, processes, etc. described in the sixth embodiment are also applicable to scenario (S1-2), scenario (S2-2), and scenario (S3-2). That is, the IAB node 300-4 starts counting the timer when receiving the Type 2 Indication from the IAB node 300-1, and performs recovery processing when the count value reaches the timer value.
- the IAB node 300 may report the triggering and stopping of local rerouting to the donor node 200.
- the report may include cause information indicating the cause of the trigger or stop.
- the cause information may be additional information included in Type 2 Indication (first, second, and fifth embodiments), or additional information included in Type 3 Indication (first embodiment). There may be.
- the report may include information on routes that have triggered or stopped local rerouting.
- the route information may be a routing ID or a BH RLC channel ID.
- the IAB node 300 may send the report to the donor node 200 immediately upon triggering or stopping local rerouting. Alternatively, the IAB node 300 may send the report after the fact. When transmitting after the fact, the IAB node 300 may record (log) the trigger or stop, the cause information, and the route information as the local rerouting is triggered and stopped. The IAB node 300 may transmit the record (log) to the donor node 200 as the report upon request from the donor node 200 .
- each embodiment, each operation example, each process, or each step described in the first to eighth embodiments can be combined with each other. All or part of each of the first to eighth embodiments can be combined without contradiction. With such a combination, it may be possible to standardize procedures or processes in all scenarios.
- a program that causes a computer to execute each process performed by the UE 100 or the gNB 200 may be provided.
- the program may be recorded on a computer readable medium.
- a computer readable medium allows the installation of the program on the computer.
- the computer-readable medium on which the program is recorded may be a non-transitory recording medium.
- the non-transitory recording medium is not particularly limited, but may be, for example, a recording medium such as CD-ROM or DVD-ROM.
- a circuit that executes each process performed by the UE 100 or gNB 200 may be integrated, and at least part of the UE 100 or gNB 200 may be configured as a semiconductor integrated circuit (chipset, SoC).
- the terms “based on” and “depending on,” unless expressly stated otherwise, “based only on.” does not mean The phrase “based on” means both “based only on” and “based at least in part on.” Similarly, the phrase “depending on” means both “only depending on” and “at least partially depending on.” Also, “obtain/acquire” may mean obtaining information among stored information, or it may mean obtaining information among information received from other nodes. or it may mean obtaining the information by generating the information.
- the terms “include,” “comprise,” and variations thereof are not meant to include only the recited items, and may include only the recited items or in addition to the recited items. Means that it may contain further items.
- references to elements using the "first,” “second,” etc. designations used in this disclosure do not generally limit the quantity or order of those elements. These designations may be used herein as a convenient method of distinguishing between two or more elements. Thus, references to first and second elements do not imply that only two elements may be employed therein, or that the first element must precede the second element in any way.
- references to first and second elements do not imply that only two elements may be employed therein, or that the first element must precede the second element in any way.
- RAN2 agreed on trigger conditions for Type 2 Indication as follows.
- the trigger for generating Type 2 RLF Indication is when RLF is detected. Further consideration is needed for both single-connection and double-connection cases.
- Type2 Indication In RAN2#113-e, the use case of Type2 Indication from the perspective of child nodes was agreed as follows.
- RAN2 supports RLF Indication of Type 2/3 (specified operation, impact of TS, details need further study).
- Type 2 RLF Indication can trigger local rerouting.
- An RLF Indication of Type 2 can trigger deactivation of IABs supported by SIBs.
- Type 2 RLF Indication can be used as a trigger to stop or reduce transmission of SR or BSR.
- a child node may forward upstream packets if the parent node (the IAB node in question) can perform local rerouting, that is, due to dual connections.
- EN-DC Another EN-DC scenario is also worthy of consideration.
- the MCG link ie MeNB
- SCG link ie SgNB
- the SCG RLF directly affects the child node's packet forwarding
- the IAB node needs to send a Type 2 Indication to the child node.
- MCG RLF LTE link
- the SCG link is still available during the subsequent RRC connection re-establishment procedure, and if re-establishment fails, a Type 4 Indication is sent as in Rel-16. Therefore, Type 2 Indication may not be necessary.
- a simple solution would be for a Type 2 Indication to be sent when at least one route is unavailable by BH RLF.
- This solution can cover both single and double connection cases and both NR-DC and EN-DC.
- BH RLF in single-connection BH RLF, all routes become unusable.
- EN-DC MCG RLF does not affect any routes and SCG RLF disables all routes.
- BH RLF may or may not affect some routes, depending on the BH link-to-route mapping. Therefore, RAN2 should agree on this unified operation regarding the trigger conditions for Type 2 Indication. .
- Proposal 1 RAN2 should send a Type 2 BH RLF Indication when at least one route is unavailable during BH RLF, regardless of whether the IAB node is single-connected or dual-connected (including EN-DC). should agree. .
- Option A is a simple operation, but the parent node loses either the MCG or SCG link due to BH RLF, so there is a possibility that the parent node will be overloaded.
- Option B requires the Type 2 Indication to convey additional information, but can distribute the load to the two parent nodes of the child node. Therefore, option B is expected to be effective in improving the performance of the overall topology.
- the child node can have the option of whether to perform "partial" local rerouting for better load balancing (i.e. option B).
- Proposal 2 RAN2 should discuss whether to perform "partial" local rerouting on child nodes (ie option B) when a dual-connected parent node experiences BH RLF.
- partial rerouting i.e. option B
- the child node must decide which traffic can remain on the original route and which traffic should be subject to local rerouting. So we need to know which routes are not available.
- the Type 2 Indication contains a routing ID that cannot be used for BH RLF, it is easy to know.
- a child node that receives a Type 2 Indication considers the routing ID notified by the Type 2 Indication to be unusable, and the BAP layer of the child node executes local rerouting. Therefore, RAN2 should agree on these actions at the concerned node and child nodes.
- Proposal 3 RAN2 should agree that the Type 2 BH RLF Indication indicates a routing ID that is not available for BH RLF.
- Proposal 4 RAN2 should agree that if a routing ID is indicated in the received Type 2 BH RLF Indication, the child node considers the routing ID unavailable.
- Type2 indication is for child nodes to perform local rerouting as RAN2 has agreed.
- RAN2#114-e as with Rel-16, the child node declares BH RLF according to the instruction of Type4 and finally performs local rerouting, so how Type2 and Type4 work together was discussed. .
- the provider can set local rerouting when Type 2 is received. This makes sense because the provider controls the purpose of the entire topology and knows the latest performance of the entire topology.
- Proposal 5 RAN2 should agree whether or not to perform local rerouting upon receipt of a Type 2 BH RLF Indication, donors configure IAB nodes.
- the provider can be able to set for the relevant IAB node whether or not to send a Type 2 Indication when BH RLF is detected. For example, if the IAB node in question implements Rel-17 functionality and its child nodes only support Rel-16 (a "mixed" deployment), the provider can turn this off.
- Proposal 6 RAN2 should agree on whether the donor side should send the Type 2 BH RLF Indication to the IAB node when its BH RLF is detected. .
- Type 3 indication for single connection and double connection In RAN2#114-e, RAN2 agreed on the trigger conditions for Type 3 Indication as follows.
- Type 3 RLF Indication is normal recovery after BH RLF. Further consideration is required for both single connection and dual connection.
- Type 3 Indication restores the operation of the child node started by receiving Type 2. Therefore, Type 3 Indication is valid only when the child node receives Type 2 Indication. Since only Type 2 Indication depends on these cases, such conditions for Type 3 Indication are commonly applicable to both single and double connections, eg, Proposal 1 above.
- Proposal 7 RAN2 should only send Type 3 BH RLF Indication in addition to the agreed action, i.e., when BH RLF recovery is successful, and only when Type 2 BH RLF Indication has been sent. It should be agreed upon as common to connection cases.
- Type 3 Indication should only be used when at least one route becomes reusable due to successful BH RLF recovery, that is, when the state changes from "unavailable” to “available”. It would be reasonable to send This behavior, like the proposal, can be applied to single-connection and double-connection cases, including NR-DC and EN-DC.
- Proposal 8 RAN2 should agree that a Type 3 BH RLF Indication will be sent when BH RLF is successfully recovered and at least one route is reusable.
- proposal 3 it is necessary to notify child nodes of the routing ID that has become reusable. Child nodes consider these routing IDs to be routable and stop local rerouting of the traffic in question.
- Proposal 9 RAN2 should agree that Type 3 BH RLF Indication indicates a routing ID that has become reusable due to successful BH RLF recovery.
- Proposal 10 RAN2 should agree to consider the routing ID available to the child node if the routing ID is indicated in the received Type 3 BH RLF Indication.
- Propagation of Type 2 Indications aims to provide better topology management, such as load balancing and reducing service interruptions.
- Proposal 11 RAN2 should agree that propagation of Type2 Indication to descendant nodes is supported. Further consideration will be given to detailed conditions such as forwarding only if the IAB node does not perform local rerouting.
- Type 2 RLF Indication can be used to stop or reduce the transmission of SR or BSR
- This is considered an IAB-MT behavior and should be clearly defined.
- deactivation may be simpler in terms of specifications. However, it means that SR and BSR can only be transmitted after receiving Type 3 Indication, which may cause scheduling delays.
- Reduce on the other hand, may cause unnecessary interference, but may allow scheduling to resume immediately after the BH link recovers. So, it should be discussed whether RAN2 supports SR and/or BSR "deactivation", "reduction”, or both.
- Proposal 12 RAN2 should agree to stipulate that IAB-MT stop or reduce SR and/or BSR transmissions when it receives a Type 2 BH RLF Indication.
- Proposal 13 when receiving Type 2 BH RLF Indication, decides whether to support "deactivation”, “reduction”, or both of SR and/or BSR (that is, whether it is configurable) should be discussed.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
第1の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードが、マスターセルグループを管理する第1親ノードをマスターノードとし、セカンダリセルグループを管理する第2親ノードをセカンダリノードとして、二重接続方式が設定されることと、前記中継ノードが、前記第1親ノードとの間の第1バックホールリンクと、前記第2親ノードとの間の第2バックホールリンクのうちの一方のリンク上に無線リンク障害を検知した場合、前記無線リンク障害の検知を示す第1通知を、子ノードへ送信することと、前記中継ノードが、前記第1通知を送信した後、前記無線リンク障害から回復した場合、前記無線リンク障害から回復したことを示す第2通知を、前記子ノードへ送信することと、を有する。
Description
本開示は、セルラ通信システムに用いる通信制御方法に関する。
セルラ通信システムの標準化プロジェクトである3GPP(Third Generation Partnership Project)において、IAB(Integrated Access and Backhaul)ノードと呼ばれる新たな中継ノードの導入が検討されている(例えば、「3GPP TS 38.300 V16.7.0(2021-09)」参照)。1又は複数の中継ノードが、基地局とユーザ装置との間の通信に介在し、この通信に対する中継を行う。
第1の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードが、マスターセルグループを管理する第1親ノードをマスターノードとし、セカンダリセルグループを管理する第2親ノードをセカンダリノードとして、二重接続方式が設定されることと、前記中継ノードが、前記第1親ノードとの間の第1バックホールリンクと、前記第2親ノードとの間の第2バックホールリンクのうちの一方のリンク上に無線リンク障害を検知した場合、前記無線リンク障害の検知を示す第1通知を、子ノードへ送信することと、前記中継ノードが、前記第1通知を送信した後、前記無線リンク障害から回復した場合、前記無線リンク障害から回復したことを示す第2通知を、前記子ノードへ送信することと、を有する。
第2の態様に係る中継ノードは、セルラ通信システムで用いる中継ノードである。前記中継ノードは、プロセッサを備える。前記プロセッサは、マスターセルグループを管理する第1親ノードをマスターノードとし、セカンダリセルグループを管理する第2親ノードをセカンダリノードとして、二重接続方式が設定される処理と、前記第1親ノードとの間の第1バックホールリンクと、前記第2親ノードとの間の第2バックホールリンクのうちの一方のリンク上に無線リンク障害を検知した場合、前記無線リンク障害の検知を示す第1通知を、子ノードへ送信する処理と、前記第1通知を送信した後、前記無線リンク障害から回復した場合、前記無線リンク障害から回復したことを示す第2通知を、前記子ノードへ送信する処理と、を実行する。
図面を参照しながら、実施形態に係るセルラ通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
(セルラ通信システムの構成)
一実施形態に係るセルラ通信システムの構成例について説明する。一実施形態に係るセルラ通信システム1は3GPPの5Gシステムである。具体的には、セルラ通信システム1における無線アクセス方式は、5Gの無線アクセス方式であるNR(New Radio)である。但し、セルラ通信システム1には、LTE(Long Term Evolution)が少なくとも部分的に適用されてもよい。また、セルラ通信システム1は、6Gなど、将来のセルラ通信システムも適用されてよい。
一実施形態に係るセルラ通信システムの構成例について説明する。一実施形態に係るセルラ通信システム1は3GPPの5Gシステムである。具体的には、セルラ通信システム1における無線アクセス方式は、5Gの無線アクセス方式であるNR(New Radio)である。但し、セルラ通信システム1には、LTE(Long Term Evolution)が少なくとも部分的に適用されてもよい。また、セルラ通信システム1は、6Gなど、将来のセルラ通信システムも適用されてよい。
図1は、一実施形態に係るセルラ通信システム1の構成例を示す図である。
図1に示すように、セルラ通信システム1は、5Gコアネットワーク(5GC)10と、ユーザ装置(UE:User Equipment)100、基地局装置(以下、「基地局」と称する場合がある。)200-1,200-2、及びIABノード300-1,300-2を有する。基地局200は、gNBと呼ばれる場合がある。
以下において、基地局200がNR基地局である一例について主として説明するが、基地局200がLTE基地局(すなわち、eNB)であってもよい。
なお、以下において、基地局200-1,200-2をgNB200(又は基地局200)、IABノード300-1,300-2をIABノード300とそれぞれ称する場合がある。
5GC10は、AMF(Access and Mobility Management Function)11及びUPF(User Plane Function)12を有する。AMF11は、UE100に対する各種モビリティ制御等を行う装置である。AMF11は、NAS(Non-Access Stratum)シグナリングを用いてUE100と通信することにより、UE100が在圏するエリアの情報を管理する。UPF12は、ユーザデータの転送制御等を行う装置である。
各gNB200は、固定の無線通信ノードであって、1又は複数のセルを管理する。セルは、無線通信エリアの最小単位を示す用語として用いられる。セルは、UE100との無線通信を行う機能又はリソースを示す用語として用いられることがある。1つのセルは1つのキャリア周波数に属する。以下では、セルと基地局とを区別しないで用いる場合がある。
各gNB200は、NGインターフェイスと呼ばれるインターフェイスを介して5GC10と相互に接続される。図1において、5GC10に接続された2つのgNB200-1及びgNB200-2を例示している。
各gNB200は、集約ユニット(CU:Central Unit)と分散ユニット(DU:Distributed Unit)とに分割されていてもよい。CU及びDUは、F1インターフェイスと呼ばれるインターフェイスを介して相互に接続される。F1プロトコルは、CUとDUとの間の通信プロトコルであって、制御プレーンのプロトコルであるF1-CプロトコルとユーザプレーンのプロトコルであるF1-Uプロトコルとがある。
セルラ通信システム1は、バックホールにNRを用いてNRアクセスの無線中継を可能とするIABをサポートする。ドナーgNB200-1(又はドナーノード。以下、「ドナーノード」と称する場合がある。)は、ネットワーク側のNRバックホールの終端ノードであり、IABをサポートする追加機能を備えたドナー基地局である。バックホールは、複数のホップ(すなわち、複数のIABノード300)を介するマルチホップが可能である。
図1において、IABノード300-1がドナーノード200-1と無線で接続し、IABノード300-2がIABノード300-1と無線で接続し、F1プロトコルが2つのバックホールホップで伝送される一例を示している。
UE100は、セルとの無線通信を行う移動可能な無線通信装置である。UE100は、gNB200又はIABノード300との無線通信を行う装置であればどのような装置であってもよい。例えば、UE100は、携帯電話端末やタブレット端末、ノートPC、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置、飛行体若しくは飛行体に設けられる装置である。UE100は、アクセスリンクを介してIABノード300又はgNB200に無線で接続する。図1において、UE100がIABノード300-2と無線で接続される一例を示している。UE100は、IABノード300-2及びIABノード300-1を介してドナーノード200-1と間接的に通信する。
図2は、IABノード300と親ノード(Parent nodes)と子ノード(Child nodes)との関係例を示す図である。
図2に示すように、各IABノード300は、基地局機能部に相当するIAB-DUとユーザ装置機能部に相当するIAB-MT(Mobile Termination)とを有する。
IAB-MTのNR Uu無線インターフェイス上の隣接ノード(すなわち、上位ノード)は、親ノードと呼ばれる。親ノードは、親IABノード又はドナーノード200のDUである。IAB-MTと親ノードとの間の無線リンクは、バックホールリンク(BHリンク)と呼ばれる。図2において、IABノード300の親ノードがIABノード300-P1及び300-P2である一例を示している。なお、親ノードへ向かう方向は、アップストリーム(upstream)と呼ばれる。UE100から見て、UE100の上位ノードは親ノードに該当し得る。
IAB-DUのNRアクセスインターフェイス上の隣接ノード(すなわち、下位ノード)は、子ノードと呼ばれる。IAB-DUは、gNB200と同様に、セルを管理する。IAB-DUは、UE100及び下位のIABノードへのNR Uu無線インターフェイスを終端する。IAB-DUは、ドナーノード200-1のCUへのF1プロトコルをサポートする。図2において、IABノード300の子ノードがIABノード300-C1~300-C3である一例を示しているが、IABノード300の子ノードにUE100が含まれてもよい。なお、子ノードへ向かう方向は、ダウンストリーム(downstream)と呼ばれる。
また、1つ又は複数のホップを介して、ドナーノード200に接続されている全てのIABノード300は、ドナーノード200をルートとする有向非巡回グラフ(DAG:Directed Acyclic Graph)トポロジ(以下、「トポロジ」と称する場合がある。)を形成する。このトポロジにおいて、図2に示すように、IAB-DUのインターフェイス上の隣り合うノードが子ノード、IAB-MTのインターフェイス上の隣り合うノードが親ノードとなる。ドナーノード200は、例えば、IABトポロジのリソース、トポロジ、ルート管理などを集中的に行う。ドナーノード200は、バックホールリンクとアクセスリンクのネットワークを介して、UE100に対して、ネットワークアクセスを提供するgNBである。
(基地局の構成)
次に、実施形態に係る基地局であるgNB200の構成について説明する。図3は、gNB200の構成例を示す図である。図3に示すように、gNB200は、無線通信部210と、ネットワーク通信部220と、制御部230とを有する。
次に、実施形態に係る基地局であるgNB200の構成について説明する。図3は、gNB200の構成例を示す図である。図3に示すように、gNB200は、無線通信部210と、ネットワーク通信部220と、制御部230とを有する。
無線通信部210は、UE100との無線通信及びIABノード300との無線通信を行う。無線通信部210は、受信部211及び送信部212を有する。受信部211は、制御部230の制御下で各種の受信を行う。受信部211はアンテナを含み、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換(ダウンコンバート)して制御部230に出力する。送信部212は、制御部230の制御下で各種の送信を行う。送信部212はアンテナを含み、制御部230が出力するベースバンド信号(送信信号)を無線信号に変換(アップコンバート)してアンテナから送信する。
ネットワーク通信部220は、5GC10との有線通信(又は無線通信)及び隣接する他のgNB200との有線通信(又は無線通信)を行う。ネットワーク通信部220は、受信部221及び送信部222を有する。受信部221は、制御部230の制御下で各種の受信を行う。受信部221は、外部から信号を受信して受信信号を制御部230に出力する。送信部222は、制御部230の制御下で各種の送信を行う。送信部222は、制御部230が出力する送信信号を外部に送信する。
制御部230は、gNB200における各種の制御を行う。制御部230は、少なくとも1つのメモリと、メモリと電気的に接続された少なくとも1つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサとCPUとを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部230は、以下に示す各実施形態において、gNB200における各処理又は各動作を行ってもよい。
(中継ノードの構成)
次に、実施形態に係る中継ノード(又は中継ノード装置。以下、「中継ノード」と称する場合がある。)であるIABノード300の構成について説明する。図4は、IABノード300の構成例を示す図である。図4に示すように、IABノード300は、無線通信部310と、制御部320とを有する。IABノード300は、無線通信部310を複数有していてもよい。
次に、実施形態に係る中継ノード(又は中継ノード装置。以下、「中継ノード」と称する場合がある。)であるIABノード300の構成について説明する。図4は、IABノード300の構成例を示す図である。図4に示すように、IABノード300は、無線通信部310と、制御部320とを有する。IABノード300は、無線通信部310を複数有していてもよい。
無線通信部310は、gNB200との無線通信(BHリンク)及びUE100との無線通信(アクセスリンク)を行う。BHリンク通信用の無線通信部310とアクセスリンク通信用の無線通信部310とが別々に設けられていてもよい。
無線通信部310は、受信部311及び送信部312を有する。受信部311は、制御部320の制御下で各種の受信を行う。受信部311はアンテナを含み、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換(ダウンコンバート)して制御部320に出力する。送信部312は、制御部320の制御下で各種の送信を行う。送信部312はアンテナを含み、制御部320が出力するベースバンド信号(送信信号)を無線信号に変換(アップコンバート)してアンテナから送信する。
制御部320は、IABノード300における各種の制御を行う。制御部320は、少なくとも1つのメモリと、メモリと電気的に接続された少なくとも1つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びCPUを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部320は、以下に示す各実施形態において、IABノード300における各処理又は各動作を行ってもよい。
(ユーザ装置の構成)
次に、実施形態に係るユーザ装置であるUE100の構成について説明する。図5は、UE100の構成例を示す図である。図5に示すように、UE100は、無線通信部110と、制御部120とを有する。
次に、実施形態に係るユーザ装置であるUE100の構成について説明する。図5は、UE100の構成例を示す図である。図5に示すように、UE100は、無線通信部110と、制御部120とを有する。
無線通信部110は、アクセスリンクにおける無線通信、すなわち、gNB200との無線通信及びIABノード300との無線通信を行う。また、無線通信部110は、サイドリンクにおける無線通信、すなわち、他のUE100との無線通信を行ってもよい。無線通信部110は、受信部111及び送信部112を有する。受信部111は、制御部120の制御下で各種の受信を行う。受信部111はアンテナを含み、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換(ダウンコンバート)して制御部120に出力する。送信部112は、制御部120の制御下で各種の送信を行う。送信部112はアンテナを含み、制御部120が出力するベースバンド信号(送信信号)を無線信号に変換(アップコンバート)してアンテナから送信する。
制御部120は、UE100における各種の制御を行う。制御部120は、少なくとも1つのメモリと、メモリと電気的に接続された少なくとも1つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びCPUを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部120は、以下に示す各実施形態において、UE100における各処理を行うようにしてもよい。
(プロトコルスタックの構成)
次に、実施形態に係るプロトコルスタックの構成について説明する。図6は、IAB-MTのRRC接続及びNAS接続に関するプロトコルスタックの例を示す図である。
次に、実施形態に係るプロトコルスタックの構成について説明する。図6は、IAB-MTのRRC接続及びNAS接続に関するプロトコルスタックの例を示す図である。
図6に示すように、IABノード300-2のIAB-MTは、物理(PHY)レイヤと、MAC(Medium Access Control)レイヤと、RLC(Radio Link Control)レイヤと、PDCP(Packet Data Convergence Protocol)レイヤと、RRC(Radio Resource Control)レイヤと、NAS(Non-Access Stratum)レイヤとを有する。
PHYレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。IABノード300-2のIAB-MTのPHYレイヤとIABノード300-1のIAB-DUのPHYレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。
MACレイヤは、データの優先制御、ハイブリッドARQ(HARQ)による再送処理、及びランダムアクセスプロシージャ等を行う。IABノード300-2のIAB-MTのMACレイヤとIABノード300-1のIAB-DUのMACレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。IAB-DUのMACレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット(トランスポートブロックサイズ、変調・符号化方式(MCS))及び割当リソースブロックを決定する。
RLCレイヤは、MACレイヤ及びPHYレイヤの機能を利用してデータを受信側のRLCレイヤに伝送する。IABノード300-2のIAB-MTのRLCレイヤとIABノード300-1のIAB-DUのRLCレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
PDCPレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。IABノード300-2のIAB-MTのPDCPレイヤとドナーノード200のPDCPレイヤとの間では、無線ベアラを介してデータ及び制御情報が伝送される。
RRCレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。IABノード300-2のIAB-MTのRRCレイヤとドナーノード200のRRCレイヤとの間では、各種設定のためのRRCシグナリングが伝送される。ドナーノード200とのRRC接続がある場合、IAB-MTはRRCコネクティッド状態である。ドナーノード200とのRRC接続がない場合、IAB-MTはRRCアイドル状態である。
RRCレイヤの上位に位置するNASレイヤは、セッション管理及びモビリティ管理等を行う。IABノード300-2のIAB-MTのNASレイヤとAMF11との間では、NASシグナリングが伝送される。
図7は、F1-Uプロトコルに関するプロトコルスタックを示す図である。図8は、F1-Cプロトコルに関するプロトコルスタックを示す図である。ここでは、ドナーノード200がCU及びDUに分割されている一例を示す。
図7に示すように、IABノード300-2のIAB-MT、IABノード300-1のIAB-DU、IABノード300-1のIAB-MT、及びドナーノード200のDUの各々は、RLCレイヤの上位レイヤとしてBAP(Backhaul Adaptation Protocol)レイヤを有する。BAPレイヤは、ルーティング処理及びベアラマッピング・デマッピング処理を行うレイヤである。バックホールでは、IPレイヤがBAPレイヤを介して伝送されることにより、複数のホップでのルーティングが可能になる。
各バックホールリンクにおいて、BAPレイヤのPDU(Protocol Data Unit)は、バックホールRLCチャネル(BH NR RLCチャネル)によって伝送される。各BHリンクで複数のバックホールRLCチャネルを構成することにより、トラフィックの優先順位付け及びQoS制御が可能である。BAP PDUとバックホールRLCチャネルとの対応付けは、各IABノード300のBAPレイヤ及びドナーノード200のBAPレイヤによって実行される。
図8に示すように、F1-Cプロトコルのプロトコルスタックは、図7に示すGTP-Uレイヤ及びUDPレイヤに代えて、F1APレイヤ及びSCTPレイヤを有する。
なお、以下においては、IABのIAB-DUとIAB-MTで行われる処理又は動作について、単に「IAB」の処理又は動作として説明する場合がある。例えば、IABノード300-1のIAB-DUが、IABノード300-2のIAB-MTへBAPレイヤのメッセージを送信することを、IABノード300-1がIABノード300-2へ、当該メッセージを送信するものとして説明する。また、ドナーノード200のDU又はCUの処理又は動作についても、単に「ドナーノード」の処理又は動作として説明する場合がある。
また、アップストリーム方向とアップリンク(UL)方向とを区別しないで用いる場合がある。更に、ダウンストリーム方向とダウンリンク(DL)方向とを区別しないで用いる場合がある。
[第1実施形態]
次に、第1実施形態について説明する。
次に、第1実施形態について説明する。
最初に、第1実施形態に係るType2 BH RLF IndicationとType3 BH RLF Indicationについて説明する。
(Type2 BH RLF IndicationとType3 BH RLF Indication)
図9は、第1実施形態に係るノード間の構成例を示す図である。
図9は、第1実施形態に係るノード間の構成例を示す図である。
図9に示すセルラ通信システム1は、IABノード300-T、親ノード(IABノード)300-P1と親ノード300-P2、及び子ノード(IABノード)300-Cを含む。
IABノード300-P1は、IABノード300-Tの親ノードである。以下、IABノード300-P1を親ノード300-P1と称する場合がある。親ノード300-P1のIAB-DUとIABノード300-TのIAB-MTとの間でバックホールリンク(BHリンク)#1が確立されている。なお、親ノード300-P1は、ドナーノード200(のDU#1)であってもよい。
IABノード300-P2も、IABノード300-Tの親ノードである。以下、IABノード300-P2を親ノード300-P2と称する場合がある。親ノード300-P2のIAB-DUとIABノード300-TのIAB-MTとの間でもBHリンク#2が確立されている。なお、親ノード300-P2は、ドナーノード200(のDU#2)であってもよい。
IABノード300-Cは、IABノード300-Tの子ノードである。以下、IABノード300-Cを子ノード300-Cと称する場合がある。子ノード300-CのIAB-MTとIABノード300-TのIAB-DUとの間でもBHリンク#3が確立されている。
このような構成において、BHリンク#1で無線リンク障害(BH RLF(Radio Link Failure))が発生し、IABノード300-TのIAB-MTがこのBH RLFを検知した仮定する。
IABノード300-TのIAB-DUは、ダウンストリーム側の子ノード300-Cへ、Type1 BH RLF Indication(以下、「Type1 Indication」と称する場合がある。)を送信できる。Type1 Indicationは、BH RLFを検知したことを示す障害発生通知の一例である。
また、IABノード300-TのIAB-MTが、当該BH RLFに対する回復動作を検知した場合、IABノード300-TのIAB-DUは、子ノード300-Cへ、Type2 BH RLF Indication(以下、「Type2 Indication」と称する場合がある。)を送信できる。Type2 Indicationは、BH RLFからの回復を試行中であることを示す回復試行通知(又は障害発生通知)の一例である。
なお、IABノード300-TのIAB-DUは、Type1 IndicationとType2 Indicationとを区別しないときは、子ノードへ、Type1/2 BH RLF Indication(以下、「Type1/2 Indication」と称する場合がある。)を送信できる。Type1/2 Indicationも、障害発生通知の一例である。
ここで、Type1 IndicationをType2 Indicationと読み替えてもよい。Type1 IndicationはBH RLF検出時、Type2 Indicationは回復試行時に、それぞれ送信される。しかし、IABノード300-TのIAB-MTは、BH RLF出後、直ちに、BH RLFの回復試行処理を行う。そのため、2つのIndicationを実質的に同じIndicationと見ることができる。
更に、IABノード300-TのIAB-MTが、当該BH RLFからの回復を検知した場合、IABノード300-TのIAB-DUは、子ノード300-Cへ、Type3 BH RLF Indication(以下、「Type3 Indication」と称する場合がある。)を送信できる。Type3 Indicationは、BHリンクがBH RLFからリカバリしたことを示す回復通知でもよい。
更に、IABノード300-TのIAB-MTが、当該BH RLFからの回復に失敗したことを検知した場合、IABノード300-TのIAB-DUは、子ノードへ、Type4 BH RLF Indication(以下、「Type4 Indication」と称する場合がある。)を送信できる。Type4 Indicationは、BHリンクがBH RLFからリカバリに失敗したことを示す失敗通知でもある。
図9では、IABノード300-Tが、Type2 Indicationを、子ノード300-Cへ送信する例を表している。
なお、これらのType BH RLF Indicationは、BAP Control PDU又はMAC CEに含まれて送信されてもよい。
(二重接続方式(DC:Dual Connectivity))
IABノード300-Tは、2つの異なる親ノード300-P1及び300-P2から提供されるリソースを利用することが可能である。一方の親ノードが、マスターセルグループ(以下、「MCG」と称する場合がある。)を管理するマスターノード(MN)となり得る。他方の親ノードが、セカンダリセルグループ(以下、「SCG」と称する場合がある。)を管理するセカンダリノード(SN)となり得る。
IABノード300-Tは、2つの異なる親ノード300-P1及び300-P2から提供されるリソースを利用することが可能である。一方の親ノードが、マスターセルグループ(以下、「MCG」と称する場合がある。)を管理するマスターノード(MN)となり得る。他方の親ノードが、セカンダリセルグループ(以下、「SCG」と称する場合がある。)を管理するセカンダリノード(SN)となり得る。
MCGは、マスターノードに関連付けられているサービングセルのセルグループである。MCGは、プライマリセル(Spセル又はPセル)と、オプションで1以上のセカンダリセル(Sセル)とを有する。
SCGは、セカンダリノードに関連付けられているサービングセルのグループである。SCGは、プライマリセル(Spセル又はPSセル)と、オプションで1以上のセカンダリセル(Sセル)とを有する。Spセルは、MCGにおけるプライマリセルであり、SCGにおけるプライマリセルでもある。
ここで、マスターノードとセカンダリノードは、論理的なエンティティ(entity)である。第1実施形態では、マスターノードは親ノード300-P1に対応し、セカンダリノードは親ノード300-P2に対応するものとして、以下説明する。
IABノード300-Tは、MCGを管理するマスターノードと接続しつつ、SCGを管理するとセカンダリノードと接続することができる。この場合、IABノード300-Tは、各親ノード300-P1及び300-P2に同時に接続して、無線通信を行う。これにより、IABノード300-Tでは、スループット向上を図ることができる。
二重接続方式(以下、「DC」と称する場合がある。)の種類の1つとして、EN-DC((E-UTRA(Evolved Universal Terrestrial Radio Access)-NR Dual Connectivity))がある。EN-DCでは、IABノード300-Tは、マスターノードとして機能する1つのeNB(evolved Node B)と接続されるとともに、セカンダリノードとして機能する1つのen-gNBと接続される。eNBは、E-UTRAサービスを提供するLTE基地局である。また、en-gNBは、NRサービスを提供するNR基地局である。例えば、図9の例では、マスターノードである親ノード300-P1がeNB、セカンダリノードである親ノード300-P2がen-gNBとなり得る。EN-DCでは、MCGが制御(C-Plane)に関する処理を行う。一方、SCGはデータ(U-Plane)に関する処理を行う。
DCの種類には、他にもNR-DC(NR-NR Dual Connectivity)がある。NR-DCは、マスターノードもセカンダリノードもgNBである。NR-DCでは、MCGもSCGも、ともに、制御とデータに関する処理を行うことができる。そのため、例えば、IABノード300-Tは、ともにgNBである親ノード300-P1及び300-P2との間で同時にデータを送受信できる。
(第1実施形態に係る通信制御方法)
3GPPでは、シングル接続の場合、Type2 Indicationの生成(又は送信)は、BH RLF(以下、「RLF」と称する場合がある。)検出時であることが合意されている。
3GPPでは、シングル接続の場合、Type2 Indicationの生成(又は送信)は、BH RLF(以下、「RLF」と称する場合がある。)検出時であることが合意されている。
一方、DCの場合、Type2 Indicationがどのような場合に送信されるのかについては、3GPPではまだ決定されていない。
DCの場合についても、シングル接続の場合と同様に、Type2 Indicationの生成(又は送信)は、RLF検出時とすることも可能である。
この場合、2つのケースが考えられる。すなわち、MCG側で発生したRLFが検知されて、Type2 Indicationが送信されるケースと、SCG側で発生したRLFが検知されて、Type2 Indicationが送信されるケースである。図9は、前者のケースの例を示し、図10は、後者のケースの例を示している。
このような場合において、Type2 Indicationを受信した子ノード300-Cは、Type2 Indicationを受信しただけでは、MCG側でRLFが発生しているのか、SCG側でRLFが発生しているのか、分からない場合がある。
そこで、IABノード300-Tは、Type2 Indicatioに付加情報を付加して送信することができる。付加情報を受信した子ノード300-Cは、付加情報に基づいて、ルーティング処理又はリルーティング処理などを行うことが可能となる。
更に、MCG側とSCG側の双方でRLFが(同時に)発生する場合もある。この場合、子ノード300-Cは、MCG側で発生したRLFに対応するType2 Indicationと、SCG側で発生したRLFに対応するType2 Indicationの2つを受信する。
その後、MCG側で発生したRLFが回復したと仮定する。この場合、IABノード300-Tは、Type3 Indicationを、子ノード300-Cへ送信する。
子ノード300-Cは、Type3 Indicationを受信しても、MCG側で発生したRLFが回復したのか、SCG側で発生したRLFが回復したのか、わからない場合がある。
そこで、第1実施形態では、IABノード300-TがType3 Indicationに付加情報を付加して、子ノード300-Cへ送信する。
具体的には、第1に、中継ノード(例えば、IABノード300-T)が、マスターセルグループを管理する第1親ノード(例えば、親ノード300-P1)をマスターノードとし、セカンダリセルグループを管理する第2親ノード(例えば、親ノード300-P2)をセカンダリノードとして、二重接続方式が設定される。第2に、中継ノードが、第1親ノードとの間の第1バックホールリンク(例えば、BHリンク#1)と、第2親ノードとの間の第2バックホールリンク(例えば、BHリンク#2)のうち、少なくともいずれかで発生した無線リンク障害から回復したことを示す第2通知(例えば、Type3 Indication)を、子ノード(例えば、子ノード300-C)へ送信する。ここで、第2通知は、第2付加情報を含み、第2付加情報は、少なくとも、使用可能となった第2ルーティングIDを示す。
これにより、例えば、子ノード300-Cは、使用可能になったルーティングIDに基づいて、ローカルリルーティングを実行していた場合に通常のルーティング動作に戻すなど、適切な処理を行うことが可能となる。
なお、ルーティングIDは、宛先BAPアドレス(Destination)と経路識別子(Path ID)とにより構成される。
(第1実施形態に係る動作例)
図11は、第1実施形態に係る動作例を表す図である。
図11は、第1実施形態に係る動作例を表す図である。
図11に示すように、ステップS10において、IABノード300-Tは、処理を開始する。
なお、IABノード300-Tは、ステップS10の後、ステップS11の前において、DCが設定されるものとする。すなわち、IABノード300-Tは、MCGを管理する親ノード300-P1をマスターノードとし、SCGを管理する親ノード300-P2をセカンダリノードとして、DCが設定されるものとする。
ステップS11において、IABノード300-Tは、RLFを検知する(又はRLFから復旧中であることを検知する)。RLFは、MCG側のBHリンク#1でもよいし、SCG側のBHリンク#2でもよい。また、RLFは、MCG側のBHリンク#1とSCG側のBHリンク#2とで同時に発生してもよい。IABノード300-TのIAB-MTは、RLFが各BHリンクで同時に発生した場合でも個別に発生した場合でも、RLF毎に当該RLFを検知してもよい。
ステップS12において、IABノード300-Tは、子ノード300-Cへ、Type2 Indicationを送信する。IABノード300-Tは、検知したRLF毎に独立してType2 Indicationを送信する。例えば、IABノード300-Tは、MCG側のBHリンク#1で発生したRLFを検知すると、当該RLFに対応するType2 Indicationを送信し、SCG側のBHリンク#2で発生したRLFを検知すると、当該RLFに対応するType2 Indicationを送信する。
ここで、IABノード300-Tは、Type2 Indicationに付加情報を付加して送信する。付加情報は、当該RLFによって影響を受けるルートの情報であってもよい。
具体的には、付加情報は、使用不可能なCG(例えば、MCGが使用不可能か、SCGが使用不可能かを示す情報)、使用不可能なルーティングID、及び使用不可能なリンク品質の少なくともいずれかを含んでもよい。更に、付加情報は、使用不可能なBH RLC チャネルID(BH RLC channel ID)を含んでもよい。子ノード300-Cは、使用不可能なBH RLCチャネルIDを受信することで、当該BH RLCチャネルへの送信を停止したり、他のBH RLCチャネルへのルーティングを行ったりすることが可能となる。
なお、子ノード300-Cは、付加情報を含むType2 Indicationを受信したことにより、他の親ノードへのローカルリルーティングを実行するものとして、以下説明する。ローカルリルーティングとは、例えば、ある親ノードから、代替パス上の他の親ノードへ送信を切り替えることである。図9の例では、子ノード300-Cは、IABノード300-T(子ノード300-Cにとって親ノード)から、代替パス上の他のIABノード(子ノード300-Cにとって別の親ノード)へ送信を切り替える。
図11に戻り、ステップS13において、IABノード300-Tは、BHリンクで発生したRLFの復旧を検知する。IABノード300-Tは、MCG側におけるRLFからの復旧と、SCG側におけるRLFからの復旧について、それぞれ独立して検知する。
ステップS14において、IABノード300-Tは、子ノード300-Cへ、Type3 Indicationを送信する。IABノード300-Tは、MCG側におけるRLFからの復旧を検知すると、当該復旧に対応するType3 Indicationを送信し、RCG側におけるRLFからの復旧を検知すると、当該復旧に対応するType3 Indicationを送信する。
図12は、第1実施形態に係るノード間の構成例を表す図である。図12に示すように、IABノード300-Tは、子ノード300-Cへ、Type3 Indicationを送信する。
ここで、IABノード300-Tは、Type3 Indicationに付加情報を付加して送信する。付加情報は、当該復旧により影響を受けるルートの情報であってもよい。
具体的には、付加情報は、使用可能となったCG(例えば、使用可能となったのはMCGであるのかSCGであるのかを示す情報)、使用可能となったルーティングID、使用可能なリンク品質(例えば、使用可能なスループットの更新)、及び使用可能となったBH RLCチャネルIDの少なくともいずれかを含む。
ステップS15において、子ノード300-Cは、Type3 Indicationを受信したことに応じて、付加情報に従って、ローカルリルーティング動作を停止し、通常のルーティング動作を行う。例えば、子ノード300-Cは、使用可能となったルーティングIDについて、ローカルリルーティングを停止する。また、例えば、子ノード300-Cは、使用可能となったルーティングID#1を付加情報として受信し、ルーティングID#2についてローカルリルーティングを実行していたと仮定する。この場合、ルーティングID#2は依然として、使用不可能なルーティングIDである。子ノード300-Cは、ルーティングID#2については、ローカルリルーティングを継続することになる。
このように、付加情報を受信した子ノード300-Cは、復旧により影響を受けるルートの情報を把握することができ、付加情報に従って、通信を制御することが可能となる。
そして、ステップS16において、子ノード300-Cは、一連の処理を終了する。
(第1実施形態の変形例)
第1実施形態では、IABノード300-Tは、付加情報を含むType3 Indicationを子ノード300-Cへ送信する例について説明した。例えば、IABノード300-Tは、付加情報を含まないType3 Indicationを送信してもよい。この場合、子ノード300-Cは、当該Type3 Indicationに関連するBHリンクの全てのルーティングIDが使用可能になったと判断してもよい。
第1実施形態では、IABノード300-Tは、付加情報を含むType3 Indicationを子ノード300-Cへ送信する例について説明した。例えば、IABノード300-Tは、付加情報を含まないType3 Indicationを送信してもよい。この場合、子ノード300-Cは、当該Type3 Indicationに関連するBHリンクの全てのルーティングIDが使用可能になったと判断してもよい。
[第2実施形態]
次に、第2実施形態について説明する。
次に、第2実施形態について説明する。
ローカルリルーティングに関して、ドナーDU間リルーティングが行われる場合がある。ドナー間リルーティングとは、例えば、ドナーノード200の第1DUから当該ドナーノード200の第2DUへ経路が切り替わるリルーティングのことである。
図13は、第2実施形態に係るノード間の構成例を表す図である。図13は、ドナー間リルーティングの例を表している。
図13の例では、ドナー間リルーティングにより、ドナーノード200のDU#1(以下、「ドナーDU#1」)(200D1)から、ドナーノード200のDU#2(以下、「ドナーDU#2」)(200D2)へ切り替えられる。この場合、アップストリーム方向のパケットの宛先が、ドナーDU#1のBAPアドレスから、ドナーDU#2のBAPアドレスへと変更されることになる。
なお、図13では、第1実施形態と同様に、IABノード300-Tと、親ノード300-P1及び300-P2とにおいて、DC設定が行われた例を表している。
そして、IABノード300-Tは、MCG側のBHリンク又はSCG側のBHリンクでRLFを検知した場合、付加情報を含むType2 Indicationを送信できる。
ここで、IABノード300-Tは、MCG側のBHリンクでのRLFを検知した場合、当該付加情報として、MCG側に紐づいた宛先(Destination:ドナーDU#1のBAPアドレス)を有する全てのルーティングIDを、送信する場合もある。
また、IABノード300-Tは、SCG側のBHリンクでのRLFを検知した場合、当該付加情報として、SCG側に紐づいた宛先(Destination:ドナーDU#2(200D2)のBAPアドレス)を有する全てのルーティングIDを、送信する場合もある。
しかし、IABノード300-Tが、付加情報として、宛先に紐づいた全てのルーティングIDを送信するには、付加情報のオーバーヘッドが大きい。
そこで、第2実施形態では、IABノード300-Tは、使用不可能になった宛先BAPアドレスをType2 Indicationの付加情報として、子ノード300-Cへ送信する例について説明する。
具体的には、第1に、中継ノード(例えば、IABノード300-T)が、親ノード(例えば、親ノード300-P1)との間のバックホールリンクで発生した無線リンク障害により、使用不可能となったルーティングIDに含まれる宛先BAPアドレスを確認する。第2に、中継ノードが、無線リンク障害に対して回復試行中であることを示す第1通知を、子ノード(例えば、子ノード300-C)へ送信する。ここで、第1通知は、付加情報を含み、付加情報は、宛先BAPアドレスを含む。
これにより、IABノード300-Tは、Type2 Indicationに付加される付加情報のサイズをコンパクトにして、付加情報のオーバーヘッドを抑制することができる。
(第2実施形態に係る動作例)
図14は、第2実施形態に係る動作例を表す図である。
図14は、第2実施形態に係る動作例を表す図である。
図14に示すように、ステップS20において、IABノード300-Tは、処理を開始する。
ステップS21において、IABノード300-Tは、RLFを検知する(又はRLFから復旧中であることを検知する)。
ステップS22において、IABノード300-Tは、ルーティング可能なルーティングIDと、ルーティングが不可能なルーティングIDとを特定する。具体的には、例えば、以下となる。
第1に、シングル接続の場合である。シングル接続とは、IABノード300-Tに代替パスが存在せず、1つの親ノード300-Pとのみ接続された形態である。シングル接続の場合、代替パスが存在しないため、全てのルーティングIDがルーティング不可能なルーティングIDとなる。この場合、ルーティング可能なルーティングIDは存在しない。そのため、シングル接続の場合、全てのルーティングIDがルーティング不可能なルーティングIDとなり得る。
第2に、DC接続の場合である。例えば、IABノード300-Tが、2つの親ノード300-P1及び300-P2に同時に接続された場合である。なお、DC接続が行われる場合、ステップS20とステップS21の間で、IABノード300-Tに対してDC設定が行われるものとする。
DC接続の場合、イントラドナーDU(「Intra-donor-DU」)によってルーティング又はリルーティングが行われる場合がある。イントラドナーDUは、宛先(Destination)は同じであって、複数の経路が存在する形態である。イントラドナーDUの場合、RLFを検知するものの、代替パスが存在するため、一部のルーティングIDは使用不可能であるものの、それ以外のルーティングIDは使用可能である。
DC接続の場合、ドナーDU間(「Inter-donor-DU」)によってルーティング又はリルーティングが行われる場合がある。ドナー間DUは、例えば、図13に示すように、ドナーノードの異なるDU間で、ルーティング又はリルーティングが行われる形態である。ドナー間DUの場合、当該RLFが発生しているBHリンクの上流のDestination(例えば、ドナーDU#1(200D1)のBAPアドレス)がルーティング不可能となる。そのため、当該Destinationを有する全てのルーティングIDが使用不可能となる。他方、別のBHリンクの上流のDestination(ドナーDU#2(200D2)のBAPアドレス)については、経路上ではRLFを検知していないため、当該Destinationを有する全てのルーティングIDは使用可能となる。
ステップS23において、IABノード300-Tは、ルーティングが不可能なルーティングIDの宛先(Destination)を確認する。
具体的には、IABノード300-Tは、ルーティングが不可能なルーティングIDの宛先が、ルーティング可能なルーティングIDの宛先に存在するか否かを確認する。
そして、IABノード300-Tは、ルーティングが不可能なルーティングIDの宛先が、ルーティングが可能なルーティングIDの宛先に存在しない場合、当該ルーティングが不可能なルーティングIDの宛先を、Type2 Indicationの付加情報に含める。
例えば、上述したシングル接続の場合、ルーティング可能なルーティングIDの宛先が存在しないため、ルーティングが不可能なルーティングIDの宛先がルーティング可能なルーティングIDの宛先に存在しない場合に該当する。この場合、ルーティングが不可能なルーティングIDの宛先が当該付加情報に含まれることになる。
また、例えば、上述したドナーDU間による場合、ルーティング不可能なルーティングIDの宛先(ドナーDU#1(200D1)のBAPアドレス)と、ルーティング可能なルーティングIDの宛先(ドナーDU#2(200D2))とは、異なる宛先となっている。従って、ルーティングが不可能なルーティングIDの宛先(ドナーDU#1(200D1)のBAPアドレス)が、ルーティング可能なルーティングIDの宛先(ドナーDU#2(200D2)のBAPアドレス)に存在しない場合に該当する。従って、この場合、ルーティングが不可能なルーティングIDの宛先(ドナーDU#1(200D1)のBAPアドレス)が、当該付加情報に含まれることになる。
一方、IABノード300-Tは、ルーティングが不可能なルーティングIDの宛先が、ルーティングが可能なルーティングIDの宛先に存在する場合、ルーティングが不可能なルーティングIDのリストを、当該付加情報に含めるようにする。
例えば、上述したように、イントラドナーDUによる場合、ある宛先へのルーティングが不可能となったとしても、代替パスが存在するため、同一の宛先において、ルーティングが可能な場合も存在する。従って、この場合、IABノード300-Tは、ルーティングIDが不可能なルーティングIDのリストを、当該付加情報に含めるようにする。
ステップS24において、IABノード300-Tは、当該付加情報を含むType2 Indicationを子ノード300-Cへ送信する。
ステップS25において、子ノード300-Tは、当該Type2 Indicationを受信したことに応じて、当該宛先(Destination)を有する全てのルーティングIDが使用不可能であると判定する。当該付加情報には、ルーティングが不可能な宛先(Destination)が含まれるため、子ノード300-Tは、当該宛先を含むルーティングIDは使用不可能なルーティングIDと判定する。
そして、ステップS26において、子ノード300-Tは、一連の処理を終了する。
[第3実施形態]
第1実施形態において、DCの種別として、EN-DCがあることを述べた。EN-DCでは、上述したように、MCGが制御(C-Plane)に関する処理を行い、SCGがデータ(U-Plane)に関する処理を行う。そのため、MCG側にRLFが発生しても、少なくともデータの送信を維持することが可能である。NR-DCについても、例えば、SCGがデータに関する処理し、MCGが制御に関する処理を行う場合、EN-DCと同じ状況となり得る。
第1実施形態において、DCの種別として、EN-DCがあることを述べた。EN-DCでは、上述したように、MCGが制御(C-Plane)に関する処理を行い、SCGがデータ(U-Plane)に関する処理を行う。そのため、MCG側にRLFが発生しても、少なくともデータの送信を維持することが可能である。NR-DCについても、例えば、SCGがデータに関する処理し、MCGが制御に関する処理を行う場合、EN-DCと同じ状況となり得る。
このような場合、IABノード300-Tは、MCG側でRLFが発生しても、Type2 Indicationを子ノード300-Cへ送信しないようにすることも可能である。IABノード300-Tは、SCGを利用して、親ノード300-P2へデータを転送できるからである。
しかし、IABノード300-Tにおいて、DCの種別を判定したり、SCGとMCGのどちらの側でデータに関する処理を行っているかを判定したりすることは、処理が複雑になる場合もある。IABノード300-Tは、DCの種別を判定する等をすることなく、Type2 Indicationを送信したり、送信しなかったりすることができれば、簡易に処理を行うことが可能となる。
そこで、第3実施形態では、RLFによる使用不可能なルートがルーティングテーブル及び/又はマッピングテーブルに存在しなければ、Type2 Indicationを送信しない例について説明する。また、第3実施形態では、使用不可能なルートがルーティングテーブル及び/又はマッピングテーブル存在すれば、Type2 Indicationを送信する例について説明する。
具体的には、第1に、中継ノード(例えば、IABノード300-T)が、マスターセルグループを管理する第1親ノード(例えば、親ノード300-P1)をマスターノード、セカンダリセルグループを管理する第2親ノード(例えば、親ノード300-P2)をセカンダリノードとして、二重接続方式が設定される。第2に、中継ノードが、第1親ノードとの間の第1バックホールリンクと、第2親ノードとの間の第2バックホールリンクのうち、少なくともいずれかで発生した無線リンク障害を検知する。第3に、中継ノードが、無線リンク障害により使用不可能なルートを示す第1ルート情報がルーティングテーブル及び/又はマッピングテーブルに存在する場合、無線リンク障害に対して回復試行中であることを示す第1通知(例えば、Type2 Indication)を子ノード(例えば、子ノード300-C)へ送信し、第1ルート情報がルーティングテーブル及び/又はマッピングテーブル存在しない場合、前記第1通知を前記子ノードへ送信しないようにする。
これにより、例えば、IABノード300-Tは、MCG側でRLFを検知した場合でも、MCG側のルート情報がルーティングテーブル及び/又はマッピングテーブルに存在しなければ、当該RLFを無視して、Type2 Indicationを送信しないようにすることができる。そのため、IABノード300-Tでは、EN-DCが設定されて、MCG側でRLFが発生しても、Type2 Indicationを送信しないようにすることができる。従って、IABノード300-Tでは、複雑な処理を抑制したType2 Indicationの送信を行うことが可能となる。
(第3実施形態に係る動作例)
図15は、第3実施形態に係る動作例を表す図である。
図15は、第3実施形態に係る動作例を表す図である。
図15に示すように、ステップS30において、IABノード300-Tは、処理を開始する。
なお、IABノード300-Tは、第1実施形態と同様に、ステップS30とステップS31の間で、DC設定が行われる。IABノード300-Tは、親ノード300-P1及び300-P2と同時に無線通信が可能となる。
ステップS31において、IABノード300-TのIAB-MTは、RLFを検知する。IABノード300-Tは、引き続き、RRC再確立(RRC reestablishment)手順、MCG失敗情報(MCG Failure Information)手順、SCG失敗情報(SCG Failure Information)手順を実行してもよい。
ステップS32において、IABノード300-TのIAB-MTのRRCレイヤは、RLFを検知したこと(又は当該BHリンクが復旧中であることを)を示す第1情報を、当該IABノード300-TのIAB-DUのBAPレイヤへ出力する。
例えば、当該RRCレイヤは、当該IABノード300-TのIAB-DUのF1APレイヤを経由して、当該IABノード300-TのIAB-DUのBAPレイヤへ、第1情報を出力してもよい。
第1情報は、どのリンクでRLFが発生したのかを示す情報が含まれてもよい。具体的には、第1情報は、MCGでRLFが発生したのか、MCGでRLF発生したのかを示す情報が含まれてもよい。また、第1情報は、RLFが発生したBHリンクを流出BHリンクとする流出BHリンクID(egress BH link ID)が含まれてもよい。更に、第1情報は、RLFが発生したBHリンク上のIABノード300-Tの次ホップBAPアドレス(Next hop BAP address)が含まれてもよい。第1情報は、MCGかSCGかを示す情報、流出BHリンクID、及び次ホップBAPアドレスの少なくともいずれかが含まれてもよい。
ステップS33において、BAPレイヤは、第1情報の入力に応じて、使用不可能なルートが存在するか否かを確認する。具体的には、BAPレイヤは、第1情報に対応する(又は第1情報を含む)ルート情報が、ルーティング設定(又はルーティングテーブル)及び/又はマッピング設定(又はマッピングテーブル)に存在するか否かを確認する。
第1に、ルーティングテーブルに対する確認は、例えば、以下となる。
すなわち、BAPレイヤは、第1情報に対応する、ルート情報(ここでは、ルーティングID及び/又は流出BHリンク)が、ルーティングテーブルに存在するか否かを確認する。
第2に、マッピングテーブルに対する確認は、例えば、以下となる。
すなわち、BAPレイヤは、第1情報に対応する、ルート情報(ここでは、流出BH RLCチャネル(egress BH RLC channel))が、マッピングテーブルに存在するか否かを確認する。
ステップS34において、BAPレイヤは、使用不可能なルートが、ルーティングテーブル及び/又はマッピングテーブルに存在すれば(ステップS34でYES)、ステップS35の処理を行う。一方、ステップS34において、BAPレイヤは、使用可能なルートがルーティングテーブル及び/又はマッピングテーブルに存在しなければ(ステップS34でNO)、ステップS38の処理を行う。
使用不可能なルートが存在する場合(ステップS34でYES)とは、第1情報に対応する、ルート情報が、ルーティングテーブル及び/又はマッピングテーブルに存在する場合である。例えば、RLFがMCG側で発生した場合、MCG側のルート情報が、ルーティングテーブル及び/又はマッピングテーブルに存在する場合である。このような場合、BAPレイヤは、ステップS35とステップS36を行う。
使用不可能なルートが存在しない場合(ステップS34でNO)とは、第1情報に対応するルート情報が、ルーティングテーブル及び/又はマッピングテーブルに存在しない場合である。例えば、RLFがMCG側で発生した場合であっても、MCG側のルート情報が、ルーティングテーブル及び/又はマッピングテーブルに存在しない場合である。このような場合、BAPレイヤは、RRCレイヤから第1情報を受け取っても、Type2 Indicationを送信しない。つまり、MCG側でRLFが発生しても、ルーティングテーブル及び/又はマッピングテーブルに対応するエントリ(又は対応するルート情報)がなければ、BAPレイヤは、Type2 Indicationを送信しないようにすることが可能となる。そのため、BAPレイヤは、ステップS38の処理を行う。
ステップS35において、BAPレイヤは、使用不可能なルートを特定する。
ここで、BAPレイヤは、下位ノード(例えば、子ノード300-C)が把握できるように、使用不可能なルートを特定する。すなわち、BAPレイヤは、ルート情報として、ルーティングIDを用いて、ステップS33とステップS34を判定した場合(当該ルーティングIDが使用不可能なルートに対応する場合)、ルーティングIDをそのまま用いて、使用不可能なルートとして特定してもよい。また、BAPレイヤは、ルート情報として、流出BHリンクを用いて、ステップS33とステップS34を判定した場合(当該流出BHリンクが使用不可能なルートに対応する場合)、流出BHリンクに対応する流入BHリンク(ingress BH link)を、使用不可能なルートとして特定してもよい。更に、BAPレイヤは、ルート情報として、流出BH RLCチャネルを用いて、ステップS33とステップS34を判定した場合(当該流出BH RLCチャネルが使用不可能なルートに対応する場合)、流出BH RLCチャネルに対応する流入BH RLCチャネル(ingress BH RLC channel)を、使用不可能なルートとして特定してもよい。
ステップS36において、BAPレイヤは、Type2 Indicationを送信する。BAPレイヤは、ステップS35で特定したルートと繋がっている子ノード300-Cのみへ、Type2 Indicationを送信してもよい。例えば、BAPレイヤは、使用不可能なルートとして特定した流入BHリンクと繋がっている子ノード300-Cのみへ、Type2 Indicationを送信してもよい。この場合、BAPレイヤは、特定した流入BHリンクと繋がっていない子ノードへ、Type2 Indicationを送信しなくてもよい。
なお、当該Type2 Indicationには、使用不可能なルートが付加情報として含まれてもよい。使用不可能なルートは、使用不可能なルーティングIDなどであってもよい。
そして、ステップS37において、IABノード300-Tは、一連の処理を終了する。
一方、ステップS38において、BAPレイヤは、Type2 Indicationを送信しない。
そして、ステップS38において、IABノード300-Tは、一連の処理を終了する。
(第3実施形態の変形例)
第3実施形態では、BAPレイヤがステップS33からステップS35の処理を行う例について説明した。例えば、IABノード300-TのIAB-DUのF1APレイヤがステップS33からステップS35の処理を行ってもよい。この場合の動作は、例えば、以下となる。
第3実施形態では、BAPレイヤがステップS33からステップS35の処理を行う例について説明した。例えば、IABノード300-TのIAB-DUのF1APレイヤがステップS33からステップS35の処理を行ってもよい。この場合の動作は、例えば、以下となる。
すなわち、ステップS32において、IABノード300-TのIAB-DUのRRCレイヤは、当該F1APレイヤへ第1情報を出力する。
ステップS33からステップS35は、BAPレイヤに代えて、当該F1APレイヤが、同様の処理を行えばよい。この場合、当該F1APレイヤは、ステップS35で特定した使用不可能なルートを、IABノード300-TのIAB-DUのBAPレイヤへ出力する。そして、BAPレイヤは、ステップS36以降の処理を行えばよい。
[第4実施形態]
第3実施形態では、RLFによる使用不可能なルートがルーティングテーブル及び/又はマッピングテーブルに存在しなければ、Type2 Indicationを送信せず、使用不可能なルートが存在すれば、Type2 Indicationを送信する例を説明した。
第3実施形態では、RLFによる使用不可能なルートがルーティングテーブル及び/又はマッピングテーブルに存在しなければ、Type2 Indicationを送信せず、使用不可能なルートが存在すれば、Type2 Indicationを送信する例を説明した。
第4実施形態では、RLFから回復したルートがルーティングテーブル及び/又はマッピングテーブルに存在しなければ、Type3 Indicationを送信せず、回復したルートがルーティングテーブル及び/又はマッピングテーブルに存在すれば、Type3 Indicationを送信する例を説明する。
具体的には、第1に、中継ノード(例えば、IABノード300-T)が、無線リンク障害から回復したことを検知する。第2に、中継ノードが、無線リンク障害からの回復により使用することが可能となったルートを示す第2ルート情報がルーティングテーブル及び/又はマッピングテーブルに存在する場合、無線リンク障害から回復したことを示す第2通知(例えば、Type3 Indication)を子ノード(例えば、子ノード300-C)へ送信し、第2ルート情報がルーティングテーブル及び/又はマッピングテーブルに存在しない場合、第2通知を子ノードへ送信しない。
これにより、例えば、第4実施形態でも、第3実施形態と同様に、複雑な処理を抑制したType3 Indicationの送信を行うことが可能となる。
(第4実施形態に係る動作例)
図16は、第4実施形態に係る動作例を表す図である。
図16は、第4実施形態に係る動作例を表す図である。
図16に示すように、ステップS40において、IABノード300-Tは、処理を開始する。
なお、IABノード300-Tは、第3実施形態と同様に、ステップS40とステップS41の間で、DC設定が行われる。IABノード300-Tは、親ノード300-P1及び300-P2と同時に無線通信が可能となる。
ステップS41において、IABノード300-TのIAB-MTは、RLFを検知する。
ステップS42において、IABノード300-TのIAB-MTのRRCレイヤは、RLFから回復したことを示す第2情報を、当該IABノード300-TのIAB-DUのBAPレイヤへ出力する。
第2情報は、どのリンクのRLFが回復したのかを示す情報が含まれてもよい。具体的には、第2情報は、MCGで回復したのか、MCGで回復したのかを示す情報が含まれてもよい。また、第2情報は、回復したBHリンクを流出BHリンクとする流出BHリンクID(egress BH link ID)が含まれてもよい。更に、第2情報は、回復したBHリンク上のIABノード300-Tの次ホップBAPアドレス(Next hop BAP address)が含まれてもよい。第2情報には、MCGかSCGかを示す情報、流出BHリンクID、及び次ホップBAPアドレスの少なくともいずれかが含まれてもよい。
ステップS43において、BAPレイヤは、第2情報の入力に応じて、使用可能となったルートが存在するか否かを確認する。具体的には、BAPレイヤは、第2情報に対応する(又は第2情報を含む)ルート情報が、ルーティング設定(又はルーティングテーブル)及び/又はマッピング設定(又はマッピングテーブル)に存在するか否かを確認する。
第1に、ルーティングテーブルに対する確認は、例えば、以下となる。
すなわち、BAPレイヤは、第2情報に対応する(又は第2情報を含む)、ルート情報(ここでは、ルーティングID及び/又は流出BHリンク)が、ルーティングテーブルに存在するか否かを確認する。
第2に、マッピングテーブルに対する確認は、例えば、以下となる。
すなわち、BAPレイヤは、第2情報に対応する(又は第2情報を含む)、ルート情報(ここでは、流出BH RLCチャネル(egress BH RLC channel))が、マッピングテーブルに存在するか否かを確認する。
ステップS44において、BAPレイヤは、使用可能となったルートがルーティングテーブル及び/又はマッピングテーブルに存在すれば(ステップS44でYES)、ステップS45の処理を行う。一方、ステップS44において、BAPレイヤは、使用可能になったルートがルーティングテーブル及び/又はマッピングテーブルに存在しなければ(ステップS44でNO)、ステップS48の処理を行う。
使用可能になったルートが存在する場合(ステップS44でYES)とは、第2情報に対応する、ルート情報が、ルーティングテーブル及び/又はマッピングテーブルに存在する場合である。例えば、RLFからの回復がMCG側で発生した場合、MCG側のルート情報が、ルーティングテーブル及び/又はマッピングテーブルに存在する場合である。このような場合、BAPレイヤは、ステップS45とステップS46を行う。
一方、使用可能となったルートが存在しない場合(ステップS44でNO)とは、第2情報に対応するルート情報が、ルーティングテーブル及び/又はマッピングテーブルに存在しない場合である。例えば、RLFからの回復がMCG側で発生した場合であっても、MCG側のルート情報が、ルーティングテーブル及び/又はマッピングテーブルに存在しない場合である。このような場合、BAPレイヤは、RRCレイヤから第2情報を受け取っても、Type3 Indicationを送信しない。そのため、BAPレイヤは、ステップS48の処理を行う。
ステップS45において、BAPレイヤは、使用不可能なルートを特定する。BAPレイヤは、下位ノード(例えば、子ノード300-C)が把握できるように、使用可能となったルートを特定する。すなわち、BAPレイヤは、第3実施形態と同様に、ルーティングID、流入BHリンク(ingress BH link)、又は流入BH RLCチャネル(ingress BH RLC channel)を、使用可能となったルートとして特定してもよい。
ステップS46において、BAPレイヤは、Type2 Indicationを送信する。BAPレイヤは、ステップS45で特定したルートと繋がっている子ノード300-Cのみへ、Type3 Indicationを送信してもよい。例えば、BAPレイヤは、特定した流入BHリンクと繋がっている子ノード300-Cのみへ、Type3 Indicationを送信してもよい。この場合、BAPレイヤは、特定した流入BHリンクと繋がっていない子ノードへ、Type2 Indicationを送信しなくてもよい。
なお、当該Type3 Indicationには、使用可能となったルートが付加情報として含まれてもよい。使用可能となったルートとしては、使用可能になったルーティングIDなどが含まれる。
そして、ステップS47において、IABノード300-Tは、一連の処理を終了する。
一方、ステップS48において、BAPレイヤは、使用不可能なルートが存在しない場合(ステップS44でNO)、Type3 Indicationを送信しない。
そして、ステップS48において、IABノード300-Tは、一連の処理を終了する。
(第4実施形態の変形例)
第3実施形態の変形例と同様に、ステップS43からステップS45の処理を、IABノード300-TのIAB-DUのF1APレイヤが行ってもよい。すなわち、ステップS43からステップS45は、BAPレイヤに代えて、当該F1APレイヤが、同様の処理を行えばよい。この場合、当該F1APレイヤは、ステップS45で特定したルート情報を、IABノード300-TのIAB-DUのBAPレイヤへ出力する。そして、BAPレイヤは、ステップS46以降の処理を行えばよい。
第3実施形態の変形例と同様に、ステップS43からステップS45の処理を、IABノード300-TのIAB-DUのF1APレイヤが行ってもよい。すなわち、ステップS43からステップS45は、BAPレイヤに代えて、当該F1APレイヤが、同様の処理を行えばよい。この場合、当該F1APレイヤは、ステップS45で特定したルート情報を、IABノード300-TのIAB-DUのBAPレイヤへ出力する。そして、BAPレイヤは、ステップS46以降の処理を行えばよい。
[第5実施形態]
第3実施形態では、IABノード300-Tが、使用不可能なルーティングIDを含むType2 Indicationを子ノード300-Cへ送信してもよいことについて説明した。また、第4実施形態では、IABノード300-Tが、使用可能なルーティングIDを含むType2 Indicationを子ノード300-Cへ送信してもよいことについて説明した。
第3実施形態では、IABノード300-Tが、使用不可能なルーティングIDを含むType2 Indicationを子ノード300-Cへ送信してもよいことについて説明した。また、第4実施形態では、IABノード300-Tが、使用可能なルーティングIDを含むType2 Indicationを子ノード300-Cへ送信してもよいことについて説明した。
第5実施形態では、子ノード300-Cが、使用不可能なルーティングIDが含むType2 Indicationを受信した場合と、使用可能なルーティングIDを含むType3 Indicationを受信した場合のBAPレイヤにおける具体的な動作例について説明する。
具体的には、第1に、中継ノード(例えば、IABノード300-T)が、無線リンク障害に対して回復試行中であることを示す第1通知(例えば、Type2 Indication)を、子ノード(例えば、子ノード300-C)へ送信する。第2に、子ノードが、使用不可能な第1ルーティングIDを含む第1通知を受信したことに応じて、第1ルーティングIDはルーティングテーブルに存在しないものとして第1ルーティング処理を行う。第3に、子ノードが、使用可能な第2ルーティングIDを含む第2通知(例えば、Type3 Indication)を受信したことに応じて、第2ルーティングIDを含むルーティングテーブル内のエントリを用いて第2ルーティング処理を行う。
これにより、子ノード300-Cは、RLFにより使用不可能となったルーティングIDを含むType2 Indicationを受信し、RLFからの回復により使用可能となったルーティングIDを含むType3 Indicationを受信した場合でも、適切に処理を行うことができる。
(第5実施形態に係る動作例)
図17(A)と図17(B)は第5実施形態に係るノード間の構成例を表す図である。また、図18は、第5実施形態に係る動作例を表す図である。図17(A)と図17(B)に示す構成例を適宜参照しながら、図18に示す動作例を説明する。
図17(A)と図17(B)は第5実施形態に係るノード間の構成例を表す図である。また、図18は、第5実施形態に係る動作例を表す図である。図17(A)と図17(B)に示す構成例を適宜参照しながら、図18に示す動作例を説明する。
図18に示すように、ステップS50において、子ノード300-Cは、処理を開始する。
ステップS51において、子ノード300-CのBAPレイヤは、親ノード300-P1から、Type2 Indicationを受信する。図17(A)は、子ノード300-Cが当該Type2 Indicationを受信する例を表している。当該Type2 Indicationには、RLFにより、ルーティング不可能となったルーティングIDが付加情報として含まれている。
図18に戻り、ステップS52において、子ノード300-CのBAPレイヤは、ルーティングテーブルにおいて、当該エントリが存在しないものとして、ルーティング処理を行う。すなわち、BAPレイヤは、Type2 Indicationに含まれるルーティングIDを含むエントリが、ルーティングテーブルに存在しないもの(又は、使用不可能なエントリ)とみなして、ルーティング処理を行う。この場合、BAPエントリは、ルーティングテーブルに当該エントリが存在しないため、当該ルーティングIDの宛先(Destination)と一致する、ルーティングテーブルのエントリを検索し、当該エントリのルーティングIDへ、ローカルリルーティングを行う。第1ルーティング処理は、例えば、このようなローカルリルーティング処理に対応する。図17(A)は、当該ローカルリルーティング処理により、子ノード300-Cが、親ノード300-P2へ、経路を切り替えた例を表している。
図18に戻り、ステップS53において、子ノード300-Cは、親ノード300-P1から、Type3 Indicationを受信する。図17(B)は、子ノード300-Cが当該Type3 Indicationを受信する例を表している。当該Type3 Indicationには、RLFからの回復により、ルーティング可能となったルーティングIDが付加情報として含まれている。
図18に戻り、ステップS54において、子ノード300-Cは、当該ルーティングIDに該当するエントリをルーティングテーブルから検索し、当該エントリが存在すれば、当該エントリの使用を再開し、通常のルーティング処理を行う。すなわち、子ノード300-Cは、ルーティングテーブルに当該エントリが存在するため、ローカルリルーティング処理を停止し、通常のルーティング処理を行う。図17(B)では、子ノード300-Cが、親ノード300-P2から親ノード300-P1へ経路を切り替える例を表している。
そして、ステップS55において、子ノード300-Cは、一連の処理を終了する。
[第6実施形態]
図19は、第6実施形態に係るノード間の構成例を表す図である。
図19は、第6実施形態に係るノード間の構成例を表す図である。
図19に示すように、子ノード300-Cが、親ノード300-Pから、Type2 Indicationを受信した場合を仮定する。この場合、その後、子ノード300-Cが、親ノード300-Pから、Type3 Indication又はType4 Indicationを受信できなかった場合、子ノード300-Cは、どのような処理を行えばよいのか、わからない場合もある。
これは、親ノード300-Pが、何らかの原因により、Type3 IndicationとType4 Indicationとを送信できなかったのかもしれない。また、親ノード300-Pが、Type3 IndicationとType4 Indicationとを送信しても、子ノード300-Cが何らかの原因により受信できなかったのかもしれない。
このような場合、親ノード300-Pの意図と、子ノード300-Cの動作とにミスマッチが生じ、トポロジ全体として意図した動作にならず、効率が悪くなる場合がある。特に、図19に示すようなシングル接続の場合、子ノード300-Cは、親ノード300-Pへのアップストリーム方向の送信ができなくなってしまう。
そこで、第6実施形態では、子ノード300-Cは、Type2 Indicationを受信した時にタイマのカウントを開始し、カウント値が所定値に達すると、BHリンクの復旧処理を開始する例について説明する。
具体的には、第1に、中継ノード(例えば、子ノード300-C)が、ドナーノード(例えば、ドナーノード200)からタイマ値の設定を受ける。第2に、中継ノードが、親ノード(例えば、親ノード300-P)から、親ノードのバックホールリンクで発生した無線リンク障害に対して回復試行中であることを示す第1通知(例えば、Type2 Indication)を受信する。第3に、中継ノードが、第1通知の受信に応じて、タイマによるカウントを開始する。第4に、中継ノードが、無線リンク障害から回復したことを示す第2通知(例えば、Type3 Indication)と、無線リンク障害からの回復に失敗したことを示す第3通知(例えば、Type4 Indication)のいずれも受信することなく、タイマによるカウント値がタイマ値に達した場合、復旧処理を行う。
これにより、例えば、親ノード300-Pと子ノード300-Cとの間のミスマッチを抑制し、トポロジ全体として意図した動作に近づけるようにすることが可能となる。
(第6実施形態に係る動作例)
図20は、第6実施形態に係る動作例を表す図である。
図20は、第6実施形態に係る動作例を表す図である。
図20に示すように、ステップS60において、子ノード300-Cは、処理を開始する。
ステップS61において、子ノード300-Cは、ドナーノード200又は親ノード300-Pから、タイマ値の設定を受信する。子ノード300-Cは、ドナーノード200から、RRCメッセージ又はF1APメッセージを利用して当該タイマ値の設定を受信してもよい。また、子ノード300-Cは、親ノード300-Pから、BAP Control PDUを利用して当該タイマ値の設定を受信してもよい。
ステップS62において、子ノード300-Cは、親ノード300-Pから、Type2 Indicationを受信する。子ノード300-Cは、Type2 Indicationの受信に応じて、タイマのカウントを開始する。
ステップS63において、子ノード300-Cは、親ノード300-Pから、Type3 Indication、又はType4 Indicationを受信したか否かを判定する。子ノード300-Cは、親ノード300-Pから、Type3 Indication、又はType4 Indicationを受信した場合(ステップS63でYES)、ステップS64の処理を行う。一方、子ノード300-Cは、親ノード300-Pから、Type3 Indication、又はType4 Indicationを受信しなかった場合(ステップS63でNO)、ステップS66の処理を行う。
ステップS64において、子ノード300-Cは、タイマのカウントを停止する。
そして、ステップS65において、子ノード300-Cは、一連の処理を終了する。
一方、ステップS66において、子ノード300-Cは、タイマのカウント値がタイマ値に達したか(タイマが満了したか)否かを判定する。子ノード300-Cは、タイマのカウント値がタイマ値に達した場合(ステップS66でYES)、ステップS67の処理を行う。一方、子ノード300-Cは、タイマのカウント値がタイマ値に達していない場合(ステップS66でNO)、ステップS63へ移行し、上述した処理を繰り返す。
ステップS67において、子ノード300-Cは、復旧処理を行う。
復旧処理は、RLFの宣言(declare)であってもよい。例えば、子ノード300-Cは、親ノード300-PのBHリンクで発生したRLFについて、当該RLFの宣言を行ってもよい。
また、復旧処理は、RRC再確立(RRC Reestablishment)手順の実行であってもよい。例えば、子ノード300-Cは、親ノード300-Pに対して、RRC再確立手順を開始してもよい。
更に、復旧処理は、Type2 Indicationに含まれる付加情報に応じたMCG失敗情報(MCG Failure Information)手順又はSCG失敗情報(SCG Failure Information)手順の実行であってもよい。例えば、子ノード300-Cは、当該付加情報としてMCG側でのRLFを示す情報が含まれる場合、MCG失敗情報手順を実行し、当該付加情報としてSCG側でのRLFを示す情報が含まれる場合、SCG失敗情報手順を実行してもよい。
そして、ステップS65において、子ノード300-Cは、一連の処理を終了する。
[第7実施形態]
3GPPでは、複数のIABノード300によって形成されたネットワーク(又はトポロジ)において、どのようにリルーティングを行うのかについての検討が行われている。
3GPPでは、複数のIABノード300によって形成されたネットワーク(又はトポロジ)において、どのようにリルーティングを行うのかについての検討が行われている。
現在、ルーティングとリルーティングに関して、以下のシナリオがある。
(S1)CU内/ドナーDU内(Intra-CU/Intra-donor-DU)
(S1-1)ルーティング
(S1-2)リルーティング
(S2)CU内/ドナーDU間(Intra-CU/Inter-donor-DU)
(S2-1)ルーティング
(S2-2)リルーティング
(S3)CU間(Inter-CU)
(S3-1)ルーティング
(S3-2)リルーティング
このようなシナリオを考慮した上で、各シナリオに共通の手順又は処理を検討したり、各シナリオ個別の手順又は処理を検討したりすることで、トポロジにおける、パケット転送の信頼性、柔軟性、及び低遅延性を向上させることが期待される。
(S1-1)ルーティング
(S1-2)リルーティング
(S2)CU内/ドナーDU間(Intra-CU/Inter-donor-DU)
(S2-1)ルーティング
(S2-2)リルーティング
(S3)CU間(Inter-CU)
(S3-1)ルーティング
(S3-2)リルーティング
このようなシナリオを考慮した上で、各シナリオに共通の手順又は処理を検討したり、各シナリオ個別の手順又は処理を検討したりすることで、トポロジにおける、パケット転送の信頼性、柔軟性、及び低遅延性を向上させることが期待される。
なお、ルーティングとは、例えば、受信したパケットをどのIABノード300へ転送するかを制御することである。
ここでは、リルーティングに着目して、各シナリオについて説明する。
(S1)「CU内/ドナーDU内」シナリオについて
図21(A)は、「CU内/ドナーDU内」シナリオにおけるトポロジの構成例を表している。
図21(A)は、「CU内/ドナーDU内」シナリオにおけるトポロジの構成例を表している。
当該シナリオにおけるリルーティング(S1-2)は、所謂、ローカルリルーティングである。例えば、IABノード300-1が、IABノード300-2に対するBH RLFを検出したとき、アップリンク方向のパケットについて、代替パスであるIABノード300-3を介した経路に切り替えて、リルーティングを行う。
(S2)「CU内/ドナーDU間」シナリオについて
図21(B)は、「CU内/ドナーDU間」シナリオにおけるトポロジの構成例を表す図である。
図21(B)は、「CU内/ドナーDU間」シナリオにおけるトポロジの構成例を表す図である。
IABノード300-1におけるリルーティングに関しては、例えば、IABノード300-2経由の経路から、IABノード300-3経由の経路(代替パス)に切り替えたと仮定する。この場合、当該パケットの宛先となるドナーDUが、ドナーDU#1(200D1)からドナーDU#2(200D2)へ変更される。すなわち、パケットの宛先BAPアドレスが変更される。そのため、3GPPでは、当該シナリオで、BAPヘッダの書き替えを行うことが合意された。BAPヘッダの書き替えは、直前のルーティングID(previous routing ID)から新たなルーティングID(new routing ID)へのBAPヘッダを書き替えることである。
(S3)「CU間」シナリオについて
図21(C)は「CU間」シナリオにおけるトポロジの構成例を表す図である。
図21(C)は「CU間」シナリオにおけるトポロジの構成例を表す図である。
図21(C)に示すように、当該シナリオでは、ドナーCU#1(200C1)とドナーCU#2(200C2)の2つの異なるCUが設けられる。そして、ドナーCU#1(200C1)にはドナーDU#1(200D1)が接続され、ドナーCU#2(200C2)にはドナーDU#2(200D2)が接続される構成となっている。
一般的に、異なるドナーCUにより、異なるトポロジが形成される。すなわち、ドナーCU#1(200C1)からIABノード300-1へ至る経路で形成されたトポロジ(第1トポロジ)と、ドナーCU#2(200C2)からIABノード300-1へ至る経路で形成されたトポロジ(第2トポロジ)とは異なるトポロジとなり得る。IABノード300-1は、2つの異なるトポロジの境界に位置する。このようなIABノード300-1を境界IABノード(boundary node)と称する場合がある。
当該シナリオのリルーティングに関しては、例えば、境界IABノード300-1は、ドナーCU#2(200C2)におけるトポロジ上の代替パスを介して、ドナーDU#1(200D1)宛てのパケットを転送することができる。
ただし、当該シナリオのリルーティングに関して、3GPPでは、境界IABノード300-1において、ソースドナーノードであるドナーCU#1(200C1)とはF1接続を残したまま、ターゲットのドナーノードであるドナーCU#2(200C2)に対してRRC再確立(RRC Reestablishment)状態で適用されてもよい、ことが合意された。
(第7実施形態に係る通信制御方法)
第1実施形態で説明した動作例、処理などは、シナリオ(S1-2)、シナリオ(S2-2)、及びシナリオ(S3-2)に適用可能である。
第1実施形態で説明した動作例、処理などは、シナリオ(S1-2)、シナリオ(S2-2)、及びシナリオ(S3-2)に適用可能である。
第1実施形態をシナリオ(S2-2)に適用した場合は、例えば、以下となる。すなわち、図21(B)に示すように、IABノード300-4及びIABノード300-5は、IABノード300-1から、Type2 Indicationを受信する。Type2 Indicationには、第1実施形態で説明した付加情報が含まれる。また、IABノード300-4及びIABノード300-5は、IABノード300-1から、Type3 Indicationを受信する。Type3 Indicationには、第1実施形態で説明した付加情報が含まれる。
また、第1実施形態をシナリオ(S2-3)に適用した場合は、例えば、以下となる。すなわち、図21(C)に示すように、IABノード300-4では、IABノード300-1から、Type2 Indicationを受信する。Type2 Indicationには、第1実施形態で説明した付加情報が含まれる。また、IABノード300-4は、IABノード300-1から、Type3 Indicationを受信する。Type3 Indicationには、第1実施形態で説明した付加情報が含まれる。
第2実施形態で説明した動作例、処理なども、シナリオ(S3-2)に適用可能である。なお、シナリオ(S2-2)は、第2実施形態で説明したため説明を割愛する。
第2実施形態をシナリオ(S3-2)に適用した場合は、例えば、以下となる。すなわち、図21(C)に示すように、IABノード300-1は、IABノード300-2との間のBHリンクにおけるRLFを検知する。IABノード300-1は、ルーティングが不可能なルーティングIDの宛先(Destination)として、ドナーDU#1(200D1)のBAPアドレスを確認する。そして、IABノード300-1は、当該BAPアドレスを含むType3 Indicationを、IABノード300-4へ送信する。
第3実施形態で説明した動作例、処理などは、シナリオ(S1-2)、シナリオ(S2-2)、及びシナリオ(S3-2)に適用可能である。すなわち、IABノード300-1は、例えば、IABノード300-2との間のBHリンクでのRLFを検知した場合、RLFによって使用不可能なルート情報がルーティングテーブル及び/又はマッピングテーブルに存在しなければ、Type2 Indicationを、下位ノードへ送信しない。IABノード300-1は、RLFによって使用不可能なルート情報がルーティングテーブル及び/又はマッピングテーブルに存在すれば、Type2 Indicationを、下位ノードへ送信する。
第4実施形態で説明した動作例、処理などは、シナリオ(S1-2)、シナリオ(S2-2)、及びシナリオ(S3-2)に適用可能である。すなわち、IABノード300-1は、例えば、IABノード300-2との間のBHリンクでのRLFからの回復を検知した場合、回復によって使用可能となったルート情報がルーティングテーブル及び/又はマッピングテーブルに存在しなければ、Type3 Indicationを、下位ノードへ送信しない。IABノード300-1は、当該回復によって使用可能となったルート情報がルーティングテーブル及び/又はマッピングテーブルに存在すれば、Type3 Indicationを、下位ノードへ送信する。
第5実施形態で説明した動作例、処理なども、シナリオ(S1-2)、シナリオ(S2-2)、及びシナリオ(S3-2)に適用可能である。すなわち、IABノード300-4は、IABノード300-1からType2 Indicationを受信する。付加情報として、RLFにより使用不可能となったルーティングIDが含まれる場合、IABノード300-4は、当該ルーティングIDを含むエントリがルーティングテーブルに存在しないものとして、第1ルーティング処理を行う。また、IABノード300-4は、IABノード300-1からType3 Indicationを受信する。付加情報として、RLFからの回復により使用可能となったルーティングIDが含まれる場合、IABノード300-4は、ルーティングテーブルに含まれる当該エントリを利用して、第2ルーティング処理を行う。
第6実施形態で説明した動作例、処理なども、シナリオ(S1-2)、シナリオ(S2-2)、及びシナリオ(S3-2)に適用可能である。すなわち、IABノード300-4は、IABノード300-1からType2 Indicationを受信したときにタイマのカウントを開始し、カウント値がタイマ値に達した場合、復旧処理を行う。
[第8実施形態]
上述した実施形態では、Type2 Indicationの受信により、ローカルリルーティングを開始(又はトリガ)したり、Type3 Indicationの受信により、ローカルリルーティングの動作を停止したりする例について説明した。
上述した実施形態では、Type2 Indicationの受信により、ローカルリルーティングを開始(又はトリガ)したり、Type3 Indicationの受信により、ローカルリルーティングの動作を停止したりする例について説明した。
IABノード300は、ローカルリルーティングのトリガ及び停止をドナーノード200へ報告してもよい。
当該報告には、トリガ又は停止の原因を示す原因情報を含んでもよい。当該原因情報は、Type2 Indicationに含まれる付加情報(第1実施形態、第2実施形態、及び第5実施形態)であってもよいし、Type3 Indicationに含まれる付加情報(第1実施形態)であってもよい。
当該報告は、ローカルリルーティングのトリガ又は停止を行ったルートの情報を含んでもよい。当該ルート情報は、ルーティングID又はBH RLCチャネルIDであってもよい。
IABノード300は、当該報告をローカルリルーティングのトリガ又は停止に伴い、即座にドナーノード200へ送信してもよい。又は、IABノード300は、当該報告を事後に送信してもよい。事後に送信する場合、IABノード300は、ローカルリルーティングのトリガ及び停止に伴い、当該トリガ又は停止、前記原因情報、前記ルート情報を記録(ログ)してもよい。IABノード300は、ドナーノード200からの要求に伴い、当該記録(ログ)を、当該報告としてドナーノード200へ送信してもよい。
[その他の実施形態]
第1実施形態から第8実施形態で説明した各実施形態、各動作例、各処理、又は各ステップは、相互に組み合わせることが可能である。第1実施形態から第8実施形態の各実施形態の全部又は一部は矛盾しない範囲で組み合わせることが可能である。このような組み合わせにより、全てのシナリオにおいて手順又は処理の共通化を図ることができる場合もある。
第1実施形態から第8実施形態で説明した各実施形態、各動作例、各処理、又は各ステップは、相互に組み合わせることが可能である。第1実施形態から第8実施形態の各実施形態の全部又は一部は矛盾しない範囲で組み合わせることが可能である。このような組み合わせにより、全てのシナリオにおいて手順又は処理の共通化を図ることができる場合もある。
UE100又はgNB200が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、CD-ROMやDVD-ROM等の記録媒体であってもよい。
また、UE100又はgNB200が行う各処理を実行する回路を集積化し、UE100又はgNB200の少なくとも一部を半導体集積回路(チップセット、SoC)として構成してもよい。
以上、図面を参照して一実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
本開示で使用されている「に基づいて(based on)」、「に応じて(depending on)」という記載は、別段に明記されていない限り、「のみに基づいて」、「のみに応じて」を意味しない。「に基づいて」という記載は、「のみに基づいて」及び「に少なくとも部分的に基づいて」の両方を意味する。同様に、「に応じて」という記載は、「のみに応じて」及び「に少なくとも部分的に応じて」の両方を意味する。また、「取得する(obtain/acquire)」は、記憶されている情報の中から情報を取得することを意味してもよく、他のノードから受信した情報の中から情報を取得することを意味してもよく、又は、情報を生成することにより当該情報を取得することを意味してもよい。「含む(include)」、「備える(comprise)」、及びそれらの変形の用語は、列挙する項目のみを含むことを意味せず、列挙する項目のみを含んでもよいし、列挙する項目に加えてさらなる項目を含んでもよいことを意味する。また、本開示において使用されている用語「又は(or)」は、排他的論理和ではないことが意図される。さらに、本開示で使用されている「第1」、「第2」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定するものではない。これらの呼称は、2つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第1及び第2の要素への参照は、2つの要素のみがそこで採用され得ること、又は何らかの形で第1の要素が第2の要素に先行しなければならないことを意味しない。本開示において、例えば、英語でのa,an,及びtheのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。
本願は、米国仮出願第63/257246号(2021年10月19日出願)の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
(付記)
導入
eIAB(Enhancements to Integrated Access and Backhaul for NR)は、BH RLF Indicationとローカルリルーティングのサポートを含むトポロジ適応の強化を目的としている。
導入
eIAB(Enhancements to Integrated Access and Backhaul for NR)は、BH RLF Indicationとローカルリルーティングのサポートを含むトポロジ適応の強化を目的としている。
本付記では、Type2/3BH RLFの詳細について説明する。
議論
二重接続方式の場合のType2 Indicationの送信
RAN2#114-eにおいて、RAN2はType2 Indicationのトリガ条件について以下のように合意した。
二重接続方式の場合のType2 Indicationの送信
RAN2#114-eにおいて、RAN2はType2 Indicationのトリガ条件について以下のように合意した。
Type2のRLF Indicationを生成するトリガは、RLF検出時である。更なる検討は、シングル接続と二重接続の両方のケースに必要である。
親ノードとのシングル接続の場合、合意は非常に簡単である。一方、2つの親ノードとの二重接続の場合、どのようにType2 Indicationを送信するか、さらに議論すべきである。
RAN2#113-eにおいて、子ノードの観点からのType2 Indicationのユースケースが以下のように合意された。
RAN2はType2/3のRLF Indicationをサポートする(規定されたる動作、TSの影響、詳細については更なる検討が必要である)。
Type2のRLF Indicationは、ローカルリルーティングをトリガすることができる。
Type2のRLF Indicationは、SIBでサポートされるIABの無効化のトリガすることができる。
Type2のRLF Indicationは、SRやBSRの送信の停止や削減のトリガとして使用することができる。
RAN2はType2/3のRLF Indicationをサポートする(規定されたる動作、TSの影響、詳細については更なる検討が必要である)。
Type2のRLF Indicationは、ローカルリルーティングをトリガすることができる。
Type2のRLF Indicationは、SIBでサポートされるIABの無効化のトリガすることができる。
Type2のRLF Indicationは、SRやBSRの送信の停止や削減のトリガとして使用することができる。
上記の合意事項の文脈では、Type2 Indicationを受信した子ノードが、当該IABノードでのBH RLFにより、Type2 Indicationを送信した当該IABノードにアップストリームパケットを転送しないことは、予想される動作と考えることができる。これは、「親ノードが2つあるIABノードが(DCを介して)一方の親ノードからType2のBH RLF Indicationを受信した場合、IABノードはもう一方の親ノードへのローカルリルーティングをトリガしてもよい」という合意とも一致するものである。
所見1:親ノードがシングルBH接続の場合、子ノードはType2 BH RLF Indicationを送信したIABノードへアップストリームパケットを転送することは期待できない場合がある。
図22の(b)に示すように、当該IABノードが二重接続方式を持つ場合、Rel-16の動作としてローカルリルーティングを実行することがあるため、所見1は常に正しいわけではない。
注:RLC-AMエンティティが確認応答を受信するまでのBAPエンティティ送信部でのデータバッファリングは、実装次第である。BH RLFの場合、BAPエンティティの送信部は、BH RLFの前に下位レイヤで確認されなかったBAPデータPDUを代替パスにリルーティングさせてもよい。
したがって、MCGのBH RLFの後でも代替パスがある場合、当該IABノードがType2 Indicationを送信すべきかどうかについては疑問が残る。MCG障害情報手順の間、当該IABノードはローカルリルーティングを継続する可能性があることに注意するべきである。
所見2:子ノードは、親ノード(当該IABノード)がローカルリルーティングを実行できる場合、つまり二重接続のために、アップストリームパケットを転送することがある。
EN-DCのもう1つのシナリオも検討に値する。EN-DCでは、MCGリンク(つまりMeNB)は制御プレーンのシグナリングのためにのみ使用され、データは常にSCGリンク(つまりSgNB)を介して転送される。この場合、SCG RLFは子ノードのパケット転送に直接影響を与えるため、当該IABノードは子ノードに対してType2 Indicationを送信する必要がある。一方、MCG RLF(LTEリンク)の場合は、その後のRRC接続再確立手順の間、SCGリンクはまだ使用可能であり、再確立に失敗した場合はRel-16と同様にType4 Indicationが送信されるため、Type2 Indicationが必要ない場合がある。
所見3:EN-DCでは、MCG(つまりLTEリンク)を介してローカルリルーティングを行うことができないため、SCG RLF(つまりNRリンク)の際にType2のBH RLF Indicationを送信する必要がある。
所見4:EN-DCでは、パケット転送は常にSCG(すなわちNRリンク)を介して行われるため、MCG RLF(すなわちLTEリンク)の際にType2のBH RLF Indicationを送信する必要はない。
上記の所見を考慮すると、BH RLFによって少なくとも1つのルートが利用できない場合、Type2 Indicationが送信されるというのがシンプルな解決策であると考えられる。この解決策は、シングル接続と二重接続の両方の場合、またNR-DCとEN-DCの両方をカバーすることができる。例えば、シングルコネクションのBH RLFでは、すべてのルートが使用できなくなる。EN-DCでは、MCG RLFはどのルートにも影響を与えず、SCG RLFはすべてのルートを使用不可にする。NR-DCでは、BH RLFは、BHリンクとルートのマッピングによって、いくつかのルートに影響を与える場合と与えない場合がある。そのため、RAN2はType2 Indicationのトリガ条件について、この統一された動作に合意すべきである。。
提案1:RAN2は、IABノードがシングル接続か二重接続(EN-DCを含む)かを問わず、BH RLF時に少なくとも1つのルートが利用できない場合にType2のBH RLF Indicationが送信されることに合意すべきである。。
Type2 Indication受信時の部分的なローカルリルーティング
二重接続方式を持つ子ノードがType2 Indicationを受信したときにどのように動作するかを検討する必要がある。親ノード(当該IABノード)がBH RLFを検出したが、まだローカルリルーティングを実行できる場合、二重接続の子ノードには、以下のいくつかの動作の選択肢がある(図23参照)。
選択肢A:すべてのアップストリームトラフィックがこの親ノードに残り、子ノードでのローカルリルーティングはない。
選択肢B:アップストリームトラフィックの一部が別の親ノードにリルートされる、つまり、「部分的」なローカルリルーティングである。
二重接続方式を持つ子ノードがType2 Indicationを受信したときにどのように動作するかを検討する必要がある。親ノード(当該IABノード)がBH RLFを検出したが、まだローカルリルーティングを実行できる場合、二重接続の子ノードには、以下のいくつかの動作の選択肢がある(図23参照)。
選択肢A:すべてのアップストリームトラフィックがこの親ノードに残り、子ノードでのローカルリルーティングはない。
選択肢B:アップストリームトラフィックの一部が別の親ノードにリルートされる、つまり、「部分的」なローカルリルーティングである。
選択肢Aは単純な動作だが、BH RLFによって親ノードがMCG又はSCGのどちらかのリンクを失うため、親ノードに過負荷が発生する可能性がある。一方、選択肢Bは、Type2 Indicationが追加情報を伝える必要があるが、子ノードの2つの親ノードに負荷を分散することができる。そのため、選択肢Bはトポロジー全体のパフォーマンスを向上させるために有効であると予想される。
所見5:Type2のBH RLF Indicationを受信すると、子ノードはより良い負荷分散のために「部分的な」ローカルリルーティングを実行するかどうかの選択肢を持つことができる(すなわち、選択肢B)。
提案2:RAN2は、二重接続の親ノードがBH RLFを経験した場合、子ノード(すなわち選択肢B)で「部分的な」ローカルリルーティングを実行するかどうかを議論すべきである。
提案2のように部分的なリルーティング(つまり選択肢B)が好ましい動作である場合、子ノードはどのトラフィックが元のルートに残れるか、どのトラフィックをローカルリルーティングの対象とすべきかを判断しなければならないため、どのルートが利用できないかを知る必要がある。Type2 IndicationにBH RLFのために利用できないルーティングIDが含まれている場合は、容易に知ることができる。Type2 Indicationを受信した子ノードは、Type2 Indicationで通知されたルーティングIDを使用不可とみなし、子ノードのBAPレイヤがローカルリルーティングを実行する。そのため、RAN2は関係するノードと子ノードでこれらの動作に合意すべきである。
提案3:RAN2は、Type2のBH RLF IndicationがBH RLFのために利用できないルーティングIDを示すことに合意すべきである。
提案4:RAN2は、受信したType2のBH RLF IndicationでルーティングIDが示された場合、子ノードがルーティングIDを利用できないものとみなすことに合意すべきである。
Type2 Indicationのためのドナーの制御性
Type2の表示で最も有望なユースケースは、RAN2が合意したように、子ノードがローカルリルーティングを実行することである。RAN2#114-eでは、Rel-16と同様に、Type4の指示によって子ノードがBH RLFを宣言し、最終的にローカルリルーティングを行うため、Type2とType4がどのように連動するかが議論された。Type2受信時のローカルリルーティングは提供者が設定可能であると指摘されている。提供者はトポロジ全体の目的を管理し、トポロジ全体の最新のパフォーマンスを知っているため、これは理にかなっている。
Type2の表示で最も有望なユースケースは、RAN2が合意したように、子ノードがローカルリルーティングを実行することである。RAN2#114-eでは、Rel-16と同様に、Type4の指示によって子ノードがBH RLFを宣言し、最終的にローカルリルーティングを行うため、Type2とType4がどのように連動するかが議論された。Type2受信時のローカルリルーティングは提供者が設定可能であると指摘されている。提供者はトポロジ全体の目的を管理し、トポロジ全体の最新のパフォーマンスを知っているため、これは理にかなっている。
提案5:RAN2は、Type2のBH RLF Indicationの受信時にローカルリルーティングを実行するかどうか、ドナーがIABノードを設定することに合意すべきである。
さらに、BH RLFが検出されたときにType2 Indicationを送信するかどうかを、提供者が当該IABノードに対して設定できるようにする必要がある。例えば、当該IABノードがRel-17の機能を実装し、その子ノードがRel-16のみをサポートする場合(「混合」配置)、提供者はこれをオフにすることができる。
提案6:RAN2は、ドナー側がIABノードに対して、そのBH RLFの検出時にType2のBH RLF Indicationを送信するかどうかを設定することに合意すべきである。。
シングル接続及び二重接続の場合におけるType3 Indication
RAN2#114-eにおいて、RAN2はType3 Indicationのトリガ条件について以下のように合意した。
RAN2#114-eにおいて、RAN2はType3 Indicationのトリガ条件について以下のように合意した。
Type3のRLF Indicationの送信のトリガは、BH RLF後の正常な回復である。シングル接続、二重接続のいずれでも更なる検討が必要である。
Type3はType2の受信によって開始された子ノードの動作を元に戻すというのが共通の認識であると考えられる。そのため、Type3 Indicationは子ノードがType2 Indicationを受信した場合のみ有効である。Type2 Indicationのみがこれらのケースに依存するため、Type3 Indicationに関するこのような条件は、例えば上記の提案1のように、シングル接続と二重接続の両方に共通して適用可能である。
提案7:RAN2は、合意された動作、すなわちBH RLFの回復に成功した場合に加え、Type2のBH RLF Indicationを送信した場合にのみ、Type3のBH RLF Indicationを送信することをシングル接続及び二重接続ケースに共通するものとして合意すべきである。
提案1が合意できるのであれば、少なくとも1つのルートがBH RLF回復の成功により再利用可能になったとき、つまり状態が「利用不可」から「利用可能」に変化したときにのみ、Type3 Indicationを送信するのが妥当であろう。この動作は、提案と同様に、NR-DCとEN-DCを含むシングル接続と二重接続のケースに適用することができる。
提案8:RAN2は、BH RLFの回復に成功し少なくとも1つのルートが再利用可能になると、Type3のBH RLF Indicationが送信されることに合意するべきである。
また、提案3に合意できる場合は、再利用可能になったルーティングIDを子ノードにも通知する必要がある。子ノードはこれらのルーティングIDをルーティング可能であるとみなし、該当するトラフィックのローカルリルーティングを停止させる。
提案9:RAN2は、Type3のBH RLF Indicationが、BH RLF回復の成功により再利用可能となったルーティングIDを示すことに合意すべきである。
提案10:RAN2は、受信したType3のBH RLF IndicationでルーティングIDが示された場合、子ノードがルーティングIDを利用できるとみなすことに合意すべきである。
Type2 Indicationの伝播
Type2 Indicationのプロパゲーションは、負荷分散やサービス中断の低減など、より良いトポロジ管理を提供することを目的としている。
Type2 Indicationのプロパゲーションは、負荷分散やサービス中断の低減など、より良いトポロジ管理を提供することを目的としている。
具体的には、様々な提案がされている。そのうちの1つは、IABノードがType2 Indicationを受信し、代替パスがない場合、Type2 Indicationを転送するものであり、これは主に提案1の選択肢1によるIABノードの動作と一致するものである。言い換えれば、この条件は、提案2の部分的なローカルリルーティングを含め、IABノードがローカルリルーティングを行わない条件と解釈することも可能である。もう一つの選択肢は、安定したトポロジ管理のために期待されるType2 Indicationの伝搬を1ホップのみに制限することである。二重接続の場合、つまり提案1ではType2 Indicationがどのように送信されるか、また子ノードでの「部分的」なローカルリルーティングを考慮するか、つまり提案2に依存することに変わりはない。そのため、詳細は現時点では更なる検討が必要としておくべきである。
提案11:RAN2は、子孫ノードへのType2 Indicationの伝搬がサポートされることに合意すべきである。IABノードがローカルリルーティングを行わない場合のみ転送するなど、詳細な条件について更なる検討を行う。
Type2 IndicationによるSRやBSRの無効化又は削減
RAN2は「Type2RLF IndicationはSRやBSRの送信を停止又は削減するために使用できる」と合意したが、この合意をどのように扱うかについては議論されていない。これはIAB-MTの動作と考えられるため、明確に規定されるべきである。非活性化・削減については、「非活性化」の方が仕様的にはシンプルかもしれない。しかし、それはSRやBSRがType3 Indicationの受信後にのみ送信できることを意味し、スケジューリングの遅延を引き起こす可能性がある。一方、「低減」は、不必要な干渉を引き起こす可能性はあるが、BHリンクが回復した直後にスケジューリングを再開することができる場合がある。そこで、RAN2は、SR及び/又はBSRの「非活性化」、「低減」、又はその両方をサポートするかどうかを議論すべきである。両方がサポートされる場合、IABドナーによって設定可能であるべきである。さらに、「縮小」がサポートされる場合、SR及び/又はBSRの縮小がどのように処理されるべきかについては不明確である。禁止タイマの概念を再利用することも考えられるが、現時点では更なる検討が必要であるとして残すべきである。
RAN2は「Type2RLF IndicationはSRやBSRの送信を停止又は削減するために使用できる」と合意したが、この合意をどのように扱うかについては議論されていない。これはIAB-MTの動作と考えられるため、明確に規定されるべきである。非活性化・削減については、「非活性化」の方が仕様的にはシンプルかもしれない。しかし、それはSRやBSRがType3 Indicationの受信後にのみ送信できることを意味し、スケジューリングの遅延を引き起こす可能性がある。一方、「低減」は、不必要な干渉を引き起こす可能性はあるが、BHリンクが回復した直後にスケジューリングを再開することができる場合がある。そこで、RAN2は、SR及び/又はBSRの「非活性化」、「低減」、又はその両方をサポートするかどうかを議論すべきである。両方がサポートされる場合、IABドナーによって設定可能であるべきである。さらに、「縮小」がサポートされる場合、SR及び/又はBSRの縮小がどのように処理されるべきかについては不明確である。禁止タイマの概念を再利用することも考えられるが、現時点では更なる検討が必要であるとして残すべきである。
提案12:RAN2は、Type2のBH RLF Indicationを受信した場合、IAB-MTがSR及び/又はBSR送信を停止又は削減することを規定することに合意すべきである。
提案13:RAN2は、Type2のBH RLF Indicationを受信したときに、SR及び/又はBSRの「非活性化」、「低減」、又はその両方をサポートするかどうか(つまり、設定可能かどうか)を議論すべきである。
Claims (11)
- セルラ通信システムで用いる通信制御方法であって、
中継ノードが、マスターセルグループを管理する第1親ノードをマスターノードとし、セカンダリセルグループを管理する第2親ノードをセカンダリノードとして、二重接続方式が設定されることと、
前記中継ノードが、前記第1親ノードとの間の第1バックホールリンクと、前記第2親ノードとの間の第2バックホールリンクのうちの一方のリンク上に無線リンク障害を検知した場合、前記無線リンク障害の検知を示す第1通知を、子ノードへ送信することと、
前記中継ノードが、前記第1通知を送信した後、前記無線リンク障害から回復した場合、前記無線リンク障害から回復したことを示す第2通知を、前記子ノードへ送信することと、を有する。
通信制御方法。 - セルラ通信システムで用いる通信制御方法であって、
中継ノードが、マスターセルグループを管理する第1親ノードをマスターノードとし、セカンダリセルグループを管理する第2親ノードをセカンダリノードとして、二重接続方式が設定されるステップと、
前記中継ノードが、前記第1親ノードとの間の第1バックホールリンクと、前記第2親ノードとの間の第2バックホールリンクのうち、少なくともいずれかで発生した無線リンク障害から回復したことを示す第2通知を、前記子ノードへ送信するステップと、を有し、
前記第2通知は、第2付加情報を含み、前記第2付加情報は、少なくとも、使用可能な第2ルーティングIDを含む、
通信制御方法。 - 前記第2付加情報は、使用可能なセルグループ、使用可能な品質、及び使用可能なバックホールRLCチャネルの少なくともいずれかを含む、
請求項2記載の通信制御方法。 - 更に、前記中継ノードが、前記無線リンク障害に対して回復試行中であることを示す第1通知を、前記子ノードへ送信するステップを有し、
前記第1通知は、第1付加情報を含み、前記第1付加情報は、少なくとも、使用不可能なバックホールRLCチャネルIDを含む、
請求項2記載の通信制御方法。 - 更に、前記中継ノードが、前記無線リンク障害に対して回復試行中であることを示す第1通知を、前記子ノードへ送信するステップと、
前記子ノードが、使用不可能となった第1ルーティングIDを含む前記第1通知を受信したことに応じて、前記第1ルーティングIDはルーティングテーブルに存在しないものとして第1ルーティング処理を行うステップと、
前記子ノードが、使用可能な第2ルーティングIDを含む前記第2通知を受信したことに応じて、前記第2ルーティングIDを含む前記ルーティングテーブル内のエントリを用いて第2ルーティング処理を行うステップと、を有する、
請求項2記載の通信制御方法。 - セルラ通信システムで用いる通信制御方法であって、
中継ノードが、親ノードとの間のバックホールリンクで発生した無線リンク障害により、使用不可能となったルーティングIDに含まれる宛先BAPアドレスを確認するステップと、
前記中継ノードが、前記無線リンク障害に対して回復試行中であることを示す第1通知を、子ノードへ送信するステップと、を有し、
前記第1通知は、付加情報を含み、前記付加情報は、前記宛先BAPアドレスを含む、
通信制御方法。 - セルラ通信システムで用いる通信制御方法であって、
中継ノードが、マスターセルグループを管理する第1親ノードをマスターノード、セカンダリセルグループを管理する第2親ノードをセカンダリノードとして、二重接続方式が設定されるステップと、
前記中継ノードが、前記第1親ノードとの間の第1バックホールリンクと、前記第2親ノードとの間の第2バックホールリンクのうち、少なくともいずれかで発生した無線リンク障害を検知するステップと、
前記中継ノードが、前記無線リンク障害により使用不可能なルートを示す第1ルート情報がルーティングテーブル及び/又はマッピングテーブルに存在する場合、前記無線リンク障害に対して回復試行中であることを示す第1通知を子ノードへ送信し、前記第1ルート情報が前記ルーティングテーブル及び/又はマッピングテーブルに存在しない場合、前記第1通知を前記子ノードへ送信しないステップと、を有する、
通信制御方法。 - 更に、前記中継ノードが、前記無線リンク障害から回復したことを検知するステップと、
前記中継ノードが、前記無線リンク障害からの回復により使用することが可能となったルートを示す第2ルート情報がルーティングテーブル及び/又はマッピングテーブル存在する場合、前記無線リンク障害から回復したことを示す第2通知を前記子ノードへ送信し、前記第2ルート情報がルーティングテーブル及び/又はマッピングテーブルに存在しない場合、前記第2通知を前記子ノードへ送信しないステップと、を有する、
請求項7記載の通信制御方法。 - セルラ通信システムで用いる通信制御方法であって、
中継ノードが、ドナーノードからタイマ値の設定を受けるステップと、
前記中継ノードが、親ノードから、前記親ノードのバックホールリンクで発生した無線リンク障害に対して回復試行中であることを示す第1通知を受信するステップと、
前記中継ノードが、前記第1通知の受信に応じて、タイマによるカウントを開始するステップと、
前記中継ノードが、前記無線リンク障害から回復したことを示す第2通知と、前記無線リンク障害からの回復に失敗したことを示す第3通知のいずれも受信することなく、前記タイマによるカウント値が前記タイマ値に達した場合、復旧処理を行うステップと、を有する、
通信制御方法。 - 更に、前記中継ノードが、前記第2通知と前記第3通知のいずれかを受信したことに応じて、前記タイマのカウントを停止するステップを有する、
請求項9記載の通信制御方法。 - セルラ通信システムで用いる中継ノードであって、
マスターセルグループを管理する第1親ノードをマスターノードとし、セカンダリセルグループを管理する第2親ノードをセカンダリノードとして、二重接続方式が設定される処理と、
前記第1親ノードとの間の第1バックホールリンクと、前記第2親ノードとの間の第2バックホールリンクのうちの一方のリンク上に無線リンク障害を検知した場合、前記無線リンク障害の検知を示す第1通知を、子ノードへ送信する処理と、
前記中継ノードが、前記第1通知を送信した後、前記無線リンク障害から回復した場合、前記無線リンク障害から回復したことを示す第2通知を、前記子ノードへ送信する処理と、を実行するプロセッサを備える。
中継ノード。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2023554697A JPWO2023068258A5 (ja) | 2022-10-18 | 通信制御方法、中継ノード、セルラ通信システム、チップセット、及びプログラム |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US202163257246P | 2021-10-19 | 2021-10-19 | |
US63/257,246 | 2021-10-19 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2023068258A1 true WO2023068258A1 (ja) | 2023-04-27 |
Family
ID=86059114
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2022/038728 WO2023068258A1 (ja) | 2021-10-19 | 2022-10-18 | 通信制御方法 |
Country Status (1)
Country | Link |
---|---|
WO (1) | WO2023068258A1 (ja) |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20210243636A1 (en) * | 2018-10-25 | 2021-08-05 | Huawei Technologies Co., Ltd. | Communication Control Method And Apparatus |
-
2022
- 2022-10-18 WO PCT/JP2022/038728 patent/WO2023068258A1/ja unknown
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20210243636A1 (en) * | 2018-10-25 | 2021-08-05 | Huawei Technologies Co., Ltd. | Communication Control Method And Apparatus |
Non-Patent Citations (2)
Title |
---|
QUALCOMM INCORPORATED: "IAB BH RLF handling", 3GPP DRAFT; R2-1906419, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, 2 May 2019 (2019-05-02), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , pages 1 - 3, XP051710734 * |
QUALCOMM INCORPORATED: "Status on RAN WI NR_IAB", 3GPP DRAFT; S3-191516, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG3, no. Reno (US); 20190506 - 20190510, 29 April 2019 (2019-04-29), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051721679 * |
Also Published As
Publication number | Publication date |
---|---|
JPWO2023068258A1 (ja) | 2023-04-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP7189219B2 (ja) | 中継装置 | |
JP7291763B2 (ja) | 通信制御方法 | |
JP7522797B2 (ja) | 通信制御方法 | |
US20230078657A1 (en) | Communication control method | |
JP2023145706A (ja) | 通信制御方法 | |
JP2024079777A (ja) | 通信制御方法 | |
US20240032129A1 (en) | Communication control method | |
US20230328607A1 (en) | Communication control method | |
US20230080014A1 (en) | Communication control method | |
WO2023068255A1 (ja) | 通信制御方法及び境界iabノード | |
WO2023068258A1 (ja) | 通信制御方法 | |
JP7483864B2 (ja) | 通信制御方法、中継ノード、移動通信システム、チップセット及びプログラム | |
WO2023013603A1 (ja) | 通信方法 | |
WO2023132283A1 (ja) | 通信制御方法 | |
WO2023132285A1 (ja) | 通信制御方法 | |
WO2023013604A1 (ja) | 通信制御方法 | |
WO2023068254A1 (ja) | 通信制御方法及び中継ノード | |
WO2023149577A1 (ja) | 通信制御方法 | |
US20230262516A1 (en) | Communication control method | |
WO2022234846A1 (ja) | 通信制御方法 | |
WO2023132284A1 (ja) | 通信制御方法 | |
JP7397221B2 (ja) | 通信制御方法、中継ノード及びプロセッサ | |
WO2023002987A1 (ja) | 通信制御方法 | |
WO2023140334A1 (ja) | 通信制御方法 | |
WO2023068256A1 (ja) | 通信制御方法及び中継ノード |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 22883562 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 2023554697 Country of ref document: JP Kind code of ref document: A |
|
NENP | Non-entry into the national phase |
Ref country code: DE |