WO2022234846A1 - 通信制御方法 - Google Patents
通信制御方法 Download PDFInfo
- Publication number
- WO2022234846A1 WO2022234846A1 PCT/JP2022/019528 JP2022019528W WO2022234846A1 WO 2022234846 A1 WO2022234846 A1 WO 2022234846A1 JP 2022019528 W JP2022019528 W JP 2022019528W WO 2022234846 A1 WO2022234846 A1 WO 2022234846A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- node
- iab
- relay node
- bsr
- lcg
- Prior art date
Links
- 238000004891 communication Methods 0.000 title claims abstract description 83
- 238000000034 method Methods 0.000 title claims abstract description 71
- 230000010267 cellular communication Effects 0.000 claims abstract description 30
- 235000008694 Humulus lupulus Nutrition 0.000 claims abstract description 27
- 238000011084 recovery Methods 0.000 claims description 24
- 230000004044 response Effects 0.000 claims description 4
- 101150014328 RAN2 gene Proteins 0.000 description 53
- 238000010586 diagram Methods 0.000 description 49
- 230000005540 biological transmission Effects 0.000 description 27
- 238000012545 processing Methods 0.000 description 21
- 230000008569 process Effects 0.000 description 17
- 208000027744 congestion Diseases 0.000 description 16
- 230000001960 triggered effect Effects 0.000 description 15
- 230000006870 function Effects 0.000 description 12
- 101150096310 SIB1 gene Proteins 0.000 description 10
- 230000009977 dual effect Effects 0.000 description 10
- 230000011664 signaling Effects 0.000 description 10
- 230000004048 modification Effects 0.000 description 9
- 238000012986 modification Methods 0.000 description 9
- 108010002616 Interleukin-5 Proteins 0.000 description 8
- 108090001005 Interleukin-6 Proteins 0.000 description 8
- 230000009849 deactivation Effects 0.000 description 8
- 238000005259 measurement Methods 0.000 description 8
- 230000009467 reduction Effects 0.000 description 7
- 238000011144 upstream manufacturing Methods 0.000 description 7
- 101150074586 RAN3 gene Proteins 0.000 description 6
- 230000006978 adaptation Effects 0.000 description 6
- 230000005012 migration Effects 0.000 description 6
- 238000013508 migration Methods 0.000 description 6
- 108010002386 Interleukin-3 Proteins 0.000 description 5
- 239000013256 coordination polymer Substances 0.000 description 5
- 230000007774 longterm Effects 0.000 description 5
- 108010002350 Interleukin-2 Proteins 0.000 description 4
- 208000016344 lissencephaly with cerebellar hypoplasia Diseases 0.000 description 4
- 238000007726 management method Methods 0.000 description 4
- 238000013507 mapping Methods 0.000 description 4
- 238000013459 approach Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 230000001934 delay Effects 0.000 description 3
- 230000001965 increasing effect Effects 0.000 description 3
- 230000000116 mitigating effect Effects 0.000 description 3
- 238000012913 prioritisation Methods 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 125000002485 formyl group Chemical group [H]C(*)=O 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 230000002411 adverse Effects 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 230000008859 change 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
- 230000003111 delayed effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000013468 resource allocation Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 208000024891 symptom Diseases 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0278—Traffic management, e.g. flow control or congestion control using buffer status reports
-
- 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
- H04W36/00—Hand-off or reselection arrangements
- H04W36/24—Reselection being triggered by specific parameters
- H04W36/30—Reselection being triggered by specific parameters by measured or perceived connection quality data
- H04W36/305—Handover due to radio link failure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/34—Reselection control
- H04W36/36—Reselection control by user or terminal equipment
- H04W36/362—Conditional handover
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
- H04W40/22—Communication route or path selection, e.g. power-based or shortest path routing using selective relaying for reaching a BTS [Base Transceiver Station] or an access point
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/04—Wireless resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/0055—Transmission or use of information for re-establishing the radio link
- H04W36/0069—Transmission or use of information for re-establishing the radio link in case of dual connectivity, e.g. decoupled uplink/downlink
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/08—Reselecting an access point
- H04W36/087—Reselecting an access point between radio units of access points
Definitions
- the present disclosure relates to a communication control method used in a cellular communication system.
- 3GPP Third Generation Partnership Project
- IAB Integrated Access and Backhaul
- One or more relay nodes intervene in and relay for communication between the base station and the user equipment.
- a communication control method is a communication control method used in a cellular communication system.
- a donor base station having a first relay node under its control and a second relay node that is a parent node of the first relay node transmits a logical channel (LCH) to the first relay node.
- LCH logical channel
- the communication control method includes the first relay node transmitting a buffer status report (BSR) to the second relay node based on the correspondence information.
- BSR buffer status report
- the communication control method includes the second relay node transmitting an uplink grant (UL grant) to the first relay node based on the correspondence information and the buffer status report.
- UL grant uplink grant
- a communication control method is a communication control method used in a cellular communication system.
- the communication control method includes the upper node of the first relay node setting a setting value regarding the logical channel group to the first relay node. Also, the communication control method includes determining, by the first relay node, a MAC control element (CE) format corresponding to the setting value. Further, the communication control method includes the first relay node sending a buffer status report to a second relay node, which is a parent node of the first relay node, using a MAC control element format.
- CE MAC control element
- a communication control method is a communication control method used in a cellular communication system.
- the communication control method includes setting an integrated buffer status report to the first relay node by a higher node of the first relay node. Further, in the communication control method, the first relay node transmits the integrated buffer status report storing the buffer size corresponding to the logical channel group classified by type of the buffer status report according to the setting to the first relay node. transmitting to a second relay node that is a parent node of the relay node;
- a communication control method is a communication control method used in a cellular communication system.
- a donor base station having a first relay node and a second relay node that is a parent node of the first relay node under control performs local rerouting and conditional handover to the first relay node. (CHO) setting.
- the communication control method is such that the first relay node responds to a failure occurring in the backhaul link from the second relay node and between the second relay node and the parent node of the second relay node. receiving a failure recovery notification indicating that recovery from the failure is being attempted.
- the communication control method includes the first relay node performing local rerouting or conditional handover in response to receiving the failure recovery notification.
- FIG. 1 is a diagram showing 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 showing 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 representing an example protocol stack for the F1-U protocol.
- FIG. 8 is a diagram representing an example protocol stack for the F1-C protocol.
- FIG. 9A is a diagram showing an example of legacy BSR transmission according to the first embodiment
- FIGS. 9B and 9C are diagrams showing examples of transmission of preemptive BSR according to the first embodiment.
- FIG. 10(A) is a diagram showing a configuration example of a short BSR MAC CE according to the first embodiment
- FIG. 10(B) is a diagram showing a configuration example of a long BSR MAC CE.
- FIG. 11 is a diagram showing an operation example according to the first embodiment.
- FIG. 12A is a diagram showing a configuration example of a cellular communication system according to the first embodiment
- FIG. 12B is a diagram showing an operation example according to a modification of the first embodiment.
- FIGS. 13(A) and 13(B) are diagrams showing an example of the BSR MAC CE of the fixed extended format according to the second embodiment.
- FIGS. 14(A) and 14(B) are diagrams showing an example of BSR MAC CE of fixed extended format according to the second embodiment.
- FIGS. 15(A) and 15(B) are diagrams showing examples of BSR MAC CE of the variable extension format according to the second embodiment.
- FIG. 16 is a diagram showing an operation example according to the second embodiment.
- FIG. 17 shows an operation example according to a modification of the second embodiment.
- FIG. 18 is a diagram showing an operation example according to the third embodiment.
- FIG. 19 is a diagram showing an example of relationships between nodes according to the fourth embodiment.
- FIG. 20 is a diagram showing an operation example according to the fourth embodiment.
- FIG. 21 is a diagram showing an operation example according to a modification of the fourth embodiment.
- FIG. 22 is a diagram showing the types of BH RLF notifications.
- the cellular communication system 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.
- 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) 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. Also, a cell may be used without distinguishing it from a base station, such as the gNB 200 .
- One cell belongs to one carrier frequency.
- 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 or donor node, hereinafter sometimes referred to as “donor node” 200-1 is a terminal node of the NR backhaul on the network side, and is a donor base station with additional functions to support IAB. be.
- 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 and/or a tablet terminal, a notebook PC, a sensor or a device provided in a sensor, a vehicle or a device provided in a vehicle, an unmanned aerial vehicle or a device provided in an unmanned aerial vehicle.
- 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 the relationship between the IAB node 300, parent nodes, and child nodes.
- each IAB node 300 has an IAB-DU equivalent to a base station functional unit and an IAB-MT (Mobile Termination) equivalent to a user equipment functional unit.
- IAB-DU equivalent to a base station functional 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.
- the processor may include a baseband processor and a CPU (Central Processing Unit).
- the baseband processor modulates/demodulates and encodes/decodes the baseband signal.
- the CPU executes 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 various processes in the gNB 200 (or the donor node 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 various processes 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, RRC (Radio Resource Control) layer, and 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, retransmission processing by hybrid ARQ (HARQ: Hybrid Automatic Repeat reQuest), random access procedures, and the like. 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: Modulation and Coding Scheme)) 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 PDCP layer of the IAB-MT of the IAB node 300-2 and the PDCP layer of the CU of the 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.
- 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 IAB-MT of IAB node 300-2 and the NAS layer of AMF11.
- FIG. 7 is a diagram representing the protocol stack for the F1-U protocol.
- FIG. 8 is a diagram representing 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
- QoS Quality of Service
- 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 CU of the donor node 200 terminates the F1 interface to the IAB node 300 and the DU of the donor node 200.
- CU of donor node 200 is the gNB-CU function of donor node 200 .
- the DU of donor node 200 also hosts the IAB BAP sublayer and provides wireless backhaul to IAB node 300 .
- DU of donor node 200 is the gNB-DU function of 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.
- the BSR transmitted by the UE 100 (hereinafter referred to as “legacy BSR” as appropriate.) is the untransmitted uplink data amount of each layer of MAC, RLC, and PDCP (that is, the amount of uplink buffer) is a logical channel It shows for each group (LCG).
- Each LCG is a group that includes at least one logical channel and is set according to priority.
- gNB 200 grasps the untransmitted uplink data amount of UE 100 for each LCG, and performs scheduling so as to allocate uplink radio resources to UE 100 in accordance with this untransmitted uplink data amount. conduct.
- FIG. 9(A) is a diagram showing an example of legacy BSR transmission according to the first embodiment.
- it is represented as “Regular BSR”, but hereinafter, "Regular BSR” may also be referred to as legacy BSR.
- FIG. 9(A) shows an example in which the IAB node 300-T transmits the legacy BSR to the parent node 300-P after receiving data from the child node 300-C.
- the IAB-MT of the IAB node 300-T uses the legacy BSR to wait for transmission (or buffer ringing) is reported as the buffer size.
- the IAB-DU of the parent node 300-P allocates uplink radio resources corresponding to this amount of data to the IAB node 300-T.
- the IAB-MT of the IAB node 300-T uses the assigned uplink radio resources to transmit the data to the parent node 300-P.
- FIGS. 9(B) and 9(C) are diagrams showing transmission examples of pre-emptive BSRs according to the first embodiment.
- the IAB-MT of IAB node 300-T sends a preemptive BSR to parent node 300-P. Also, as shown in FIG. 9(C), after the IAB-DU of the IAB node 300-T receives the legacy BSR from the child node 300-C, before transmitting the UL grant to the child node 300-C, the IAB The IAB-MT of node 300-T sends a preemptive BSR to parent node 300-P.
- the preemptive BSR is transmitted to the parent node 300-P at an earlier timing than the legacy BSR. Therefore, the preemptive BSR can reduce the UL scheduling delay (latency) of the parent node 300-P to the IAB node 300-T compared to the legacy BSR.
- FIG. 10(A) is a diagram showing a configuration example of a short BSR (Short BSR) MAC CE (hereinafter sometimes referred to as "Short BSR MAC CE") according to the first embodiment.
- Short BSR MAC CE is used when one LCG (Logical Channel Group) has data available for transmission. That is, when reporting the buffer size of one LCG, short BSR MAC CE is used.
- the short BSR MAC CE includes an "LCG ID” area and a "buffer size” area.
- the "LCG ID” area is an area in which the identification information of the logical channel group whose buffer size is reported is stored.
- the area length of the "LCG ID” area is 3 bits.
- the "buffer size area” is calculated according to a predetermined calculation procedure across all logical channels in the logical channel group after the MAC PDU is constructed (i.e., after the logical channel prioritization procedure). , is an area in which the total amount of available data is stored. The area length of the "buffer size" area is 5 bits.
- FIG. 10(B) is a diagram showing a configuration example of a Long BSR MAC CE (hereinafter sometimes referred to as "Long BSR MAC CE") according to the first embodiment.
- Long BSR MAC CE is used when there is more than one LCG (Logical Channel Group) with data available for transmission. That is, when reporting the buffer sizes of multiple LCGs, the long BSR MAC CE is used.
- LCG Logical Channel Group
- FIG. 10(B) also shows a configuration example of a preemptive BSR MAC CE (hereinafter sometimes referred to as "preemptive BSR MAC CE").
- the BSR MAC CE shown in FIG. 10(B) includes an 'LCG i ' area and a 'buffer size area'.
- the 'LCG i ' area is an area indicating that the buffer size of the logical channel group i exists. That is, setting LCG i to '1' indicates that the buffer size of logical channel group i is reported. On the other hand, if LCG i is set to '0', it indicates that the buffer size for logical channel group i is not reported.
- the area length of the 'LCG i ' area is 8 bits.
- the "buffer size” area is the same as the “buffer size” area of the short BSR MAC CE when the MAC CE shown in FIG. 10(B) is the long BSR MAC CE.
- the "buffer size area” stores a predetermined buffer size.
- the predetermined buffer size is the total amount of data expected to arrive at the IAB-MT of the IAB node 300 (IAB node 300-T in the case of FIG. 9) where the preemptive BSR was triggered, and It does not include the total amount of data currently available.
- the short BSR MAC CE in FIG. 10(A) represents the MAC CE of the short truncated BSR.
- the long BSR MAC CE in FIG. 10(B) represents the MAC CE of the long truncated BSR.
- a truncated BSR is a BSR that corresponds to the padding bits (or padding data) that the MAC layer inserts when constructing a MAC PDU. If the padding bits are the same as the size of the short BSR with the subheader added, the MAC CE of FIG. 10(A) is used. Also, if the padding bits are larger than the size of the short BSR plus the subheader, the MAC CE of FIG. 10(B) is used.
- short BSR MAC CE and short truncated BSR MAC CE are not distinguished, they may be described as short BSR MAC CE.
- long BSR MAC CE, preemptive BSR MAC CE, and long truncated BSR MAC CE are not distinguished, they may be described as long BSR MAC CE.
- preemptive BSR and legacy BSR may be referred to as "BSR" when not distinguished from each other.
- the first embodiment is an example in which the IAB node 300 reports to the parent node the buffer size of each logical channel group associated with the number of hops.
- a donor base station for example, donor node 200 having first and second relay nodes under its control sends a logical channel to a first relay node (for example, IAB node 300-T).
- LCH logical channel group
- the first relay node sends a buffer status report (BSR) to a second relay node (eg, parent node 300-P), which is the parent node of the first relay node, based on the correspondence information.
- BSR buffer status report
- the second relay node sends an uplink grant (UL grant) to the first relay node based on the correspondence information and the buffer status report.
- the number of LCH hops and the LCG are linked.
- the IAB node 300 uses the BSR to report the number of hops and the buffer size of the linked LCG to the parent node. Since the LCG and the number of hops are associated with each other, the parent node can grasp the buffer size in the LCG as a buffer size corresponding to the number of hops. The parent node allocates uplink radio resources to the IAB node 300 using not only the buffer size but also the number of hops.
- the parent node can allocate more uplink radio resources than others to the IAB node 300 with a large delay (or a large number of hops), for example. Therefore, it is possible to reduce the delay and ensure the fairness of the entire topology.
- FIG. 12A is a diagram showing a configuration example of the cellular communication system 1 according to the first embodiment.
- the donor node 200 has IAB nodes 300-P, 300-T, and 300-C under its control.
- the topology (or network) that donor node 200 builds may include other IAB nodes.
- the parent node of the IAB node 300-T is the IAB node 300-P.
- a child node of the IAB node 300-T is the IAB node 300-C.
- the IAB node 300-P may be referred to as the parent node 300-P, and the IAB node 300-C as the child node 300-C.
- the upper node of the IAB node 300-T may be the parent node 300-P. Also, the upper node of the IAB node 300-T may be the donor node 200. FIG. Note that the parent node 300-P may be the donor node 200. FIG.
- the IAB node 300-T is connected to one parent node 300-P, but multiple parent nodes 300-P1, 300-P2, . . . may be connected with In this case, for example, the IAB node 300-T may be connected with the parent node 300-P1 and the parent node 300-P2 by Dual Connectivity.
- a master cell group (MCG) in Dual Connectivity is set in the parent node 300-P1
- a secondary cell group (SCG) is set in the parent node 300-P2. It becomes connectable to two parent nodes 300-P1 and 300-P2.
- FIG. 12A shows an example in which the child node 300-C is connected to the IAB node 300-T, but instead of the child node 300-C, the UE 100 connects to the IAB node 300-T. may be connected. Moreover, both the child node 300-C and the UE 100 may be connected to the IAB node 300-T. In the following description, it is assumed that the child node 300-C is connected to the IAB node 300-T.
- FIG. 11 is a diagram showing an operation example according to the first embodiment. The operation example shown in FIG. 11 will be described by appropriately using the configuration example of the cellular communication system 1 shown in FIG. 12(A).
- step S10 the donor node 200 starts processing.
- the donor node 200 sets the linking information in which the LCG is linked for each hop count to the IAB node 300-T (the IAB-MT or IAB-DU of it).
- the linking information is classified according to the number of LCH hops. For example, as the linking information, the LCH hop count "2" is linked to LCG#8 to LCG#15, and the logical channel hop count "3" is linked to LCG#16 to LCG#32. and other information.
- the number of hops may be the total number of hops in the route to which the LCH belongs.
- the number of hops may be the number of hops that have passed to reach the IAB node 300-T on the LCH.
- the number of hops may be the number of remaining hops from the IAB node 300-T to the donor node 200 on the LCH.
- the linking information may be correspondence information representing the correspondence between the LCH hop count and the LCG.
- the terms “associating” and “corresponding” may be used without distinction.
- the CU of the donor node 200 may perform the setting by sending an RRC message including the linking information to the IAB-MT of the IAB node 300-T. Also, the CU of the donor node 200 may perform the setting by sending an F1AP message including the binding information to the IAB-DU of the IAB node 300-T.
- the donor node 200 may set the linking information to the parent node 300-P.
- the donor node 200 may perform the setting by sending an RRC message or an F1AP message containing the binding information to the parent node 300-P in the same manner as described above.
- the parent node 300-P may be preconfigured with hard-coded linking information.
- the IAB-MT of the IAB node 300-T transmits the BSR to the parent node 300-P according to the setting.
- the BSR stores the buffer size for each LCG associated with the number of hops.
- the BSR includes the buffer size of LCG#8 corresponding to the hop number "2", the buffer size of LCG#9 corresponding to the hop number "2", . . . , the buffer size of LCG#15 corresponding to the hop number “2”, . . . , the buffer size of LCG#16 corresponding to the hop count “3”, . . . is stored.
- the BSR may be a legacy BSR as described above.
- the BSR may be a preemptive BSR.
- the IAB-DU of the parent node 300-P identifies the number of hops and buffer status for each LCG using the linking information upon receiving the BSR. For example, when the parent node 300-P receives a report of the buffer size of LCG#15 as the BSR, it uses the linking information to determine that the buffer size is the hop count “2” corresponding to LCG#15. ,Identify.
- step S14 the IAB-DU of the parent node 300-P allocates uplink radio resources to the IAB-MT of the IAB node 300-T based on the binding information and the BSR.
- the parent node 300-P then transmits the UL grant including the allocation information to the IAB node 300-T.
- the IAB-DU of the parent node 300-P allocates more uplink radio resources than others to the IAB-MT of the IAB node 300-T in which the data of the LCG with a larger number of hops is staying. .
- step S15 the series of processes ends.
- a modification of the first embodiment is an example of allocating a plurality of LCGs for each number of hops to one LCH.
- the first relay node for example, the IAB node 300-T
- the first relay node identifies the logical channel group corresponding to the hop count of the packet received via the logical channel based on the correspondence information, Send a buffer status report containing the buffer size of the channel group to the second relay node (eg, parent node 300-P).
- FIG. 12(B) is a diagram showing an operation example according to the modification of the first embodiment. The operation example shown in FIG. 12(B) will be described by appropriately using the configuration example of the cellular communication system 1 shown in FIG. 12(A).
- N UE bearers are mapped to one LCH (BH RLC channel) (1:N mapping). It is assumed that each of the N UE bearers has a different route (number of hops).
- the IAB node 300-T classifies the packets received via the LCH (BH RLC channel) by the number of hops in step S120.
- the IAB node 300-T may confirm the hop count as follows, for example.
- the hop count may be obtained from the header of the received packet. If hop count information is stored in the BAP header of the received BAP packet, (the IAB-DU of) the IAB node 300-T can confirm the hop count by acquiring the hop count information from the BAP header.
- the hop count may be obtained from the implementation of the IAB node 300-T. That is, the IAB-DU of the IAB node 300-T knows from which BH RLC channel the packet was received. Each time the IAB-DU of the IAB node 300-T receives a packet, it notifies the IAB-MT of the IAB node 300-T which packet went through which route. The IAB-MT of the IAB node 300-T may acquire the hop count based on the information notified from the IAB-DU.
- the IAB-MT of the IAB node 300-T identifies the LCG corresponding to the classified hop count based on the linking information, and calculates the buffer size for each LCG.
- the IAB-MT of the IAB node 300-T sends a BSR containing the calculated buffer size to the parent node 300-P.
- the IAB node 300-T After finishing the processing of step S120, the IAB node 300-T performs the processing from step S13 (FIG. 11) onward, as in the first embodiment.
- the IAB node 300-T identifies the LCG for each packet and calculates the buffer size, so it can report the buffer size to the parent node 300-P for each packet.
- the parent node 300-P can allocate more resources to the IAB node 300-T with the longer delayed packet than others. Therefore, it is possible to reduce the delay and further to ensure fairness.
- the upper limit of the number of LCGs is 8 (eg, FIG. 10(B)) and 3 bits (eg, FIG. 10(B)). 10(A)).
- the upper limit is expressed as "X number (Y bits)".
- the upper limit of the number of LCHs is 65,536 (16 bits) for IAB-MT. If the upper limit of the number of LCGs is secured to the same extent as the upper limit of the number of LCHs, the upper limit of the number of LCGs can also be 65,536 (16 bits). Suppose that there are 65,536 (16 bits) LCGs for high-resolution scheduling. In such a case, when the IAB node 300 transmits 65,536 (16-bit) LCGs using the existing BSR MAC CE, it transmits the BSR shown in FIG. 10(B) 8192 times.
- the upper limit value of LCG can be set, and the IAB node 300-T uses the BSR MAC CE format corresponding to the set upper limit value of LCG to convert the BSR to the parent node 300-P report to.
- the IAB node 300-T supports fixed extended format BSR MAC CE and variable extended format BSR MAC CE. use.
- the IAB node 300-T selects (or determines) the MAC CE format corresponding to the upper limit value of the LCG from among these MAC CE formats.
- a higher node eg, parent node 300-P or donor node 200
- a first relay node eg, IAB node 300-T
- the first relay node determines the MAC Control Element (CE) format corresponding to the upper bound.
- the first relay node sends a buffer status report to a second relay node (eg, parent node 300-P), which is the parent node of the first relay node, using the determined MAC control element format. to send.
- CE MAC Control Element
- the IAB node 300-T can report the BSR using the BSR MAC CE corresponding to the upper limit of the LCG, so it is possible to reduce the overhead since the BSR will not be sent multiple times. becomes.
- FIGS. 13(A) and 13(B) are diagrams showing configuration examples of the BSR MAC CE of the fixed extended format according to the first embodiment.
- 13(A) and 13(B) are diagrams showing an example in which the upper limit value of LCG is 16 (4 bits).
- FIG. 13(A) shows an example of short BSR MAC CE when the upper limit value of LCG is 16 (4 bits).
- FIG. 13(B) shows an example of a long BSR MAC CE when the LCG upper limit is 16 (4 bits).
- the short BSR MAC CE has 4 bits in the "LCG ID" area to match the upper limit. One bit more than the short BSR MAC CE in FIG. 10(A).
- the "LCG ID" area stores the identification information of the logical channel group for which the buffer size is reported, which is the same as the existing short BSR MAC CE (Fig. 10(A)).
- the "BS” area has 5 bits.
- the "BS” area also stores the total amount of available data according to a predetermined calculation procedure across all LCHs in the LCG, the same as the existing BSR MAC CE. After the "BS" area is "R" (reserved area).
- the long BSR MAC CE has 16 "LCG i " areas (LCG 0 to LCG 15 ) in accordance with the upper limit.
- the 'LCG i ' area also stores a value indicating that the same buffer size of LCGi exists as in the existing long BSR MAC CE.
- the "BS" area shown in FIG. 13B also stores the same predetermined buffer size as the existing long BSR MAC CE.
- FIGS. 14(A) and 14(B) are diagrams showing examples of the BSR MAC CE of the fixed extended format according to the second embodiment.
- 14(A) and 14(B) both show an example in which the upper limit value of LCG is 256 (8 bits).
- FIG. 14(A) shows an example of short BSR MAC CE when the upper limit value of LCG is 256 (8 bits).
- FIG. 14(B) shows an example of a long BSR MAC CE when the upper limit value of LCG is 256 (8 bits).
- the "LCG ID” area has 8 bits corresponding to the upper limit.
- the "BS” area has 5 bits, and the rest are "R”.
- the IAB node 300-T uses the BSR MAC CE of FIG. 13(A) or FIG. 13(B) when the LCG upper limit is set to 16 (4 bits). If the LCG upper limit is 256 (8 bits), it is decided to use the BSR MAC CE shown in FIG. 14(A) or FIG. 14(B).
- the upper limit is an example, and when 32 (5 bits) is set as the upper limit, the IAB node 300-T uses a short BSR MAC CE with a 5-bit “LCG ID” area, or a “LCG i ” area may decide to use the long BSR MAC CE with 32 . In addition, when 64 (6 bits) is set as the upper limit, the IAB node 300-T uses a short BSR MAC CE with 6 bits of “LCG ID” or a long BSR with 64 “LCG i ” areas. It may decide to use MAC CE.
- the IAB node 300-T may decide to use the short BSR MAC CE with the 'LCG ID' field corresponding to the upper limit value or the long BSR MAC CE with the 'LCG i ' field corresponding to the upper limit value. .
- the IAB node 300-T decides to use the short BSR MAC CE when reporting the buffer size of a specific LCG, and the long BSR MAC CE when reporting the buffer sizes of multiple LCGs. should decide to use the
- FIGS. 15(A) and 15(B) are diagrams showing examples of variable extension formats according to the second embodiment.
- FIG. 15(A) represents an example of a short variable extension format for short BSR MAC CE
- FIG. 15(B) represents an example of long variable extension format for long BSR MAC CE.
- the short variable extension format further includes an "LCG range” area.
- the "LCG range” area stores bits corresponding to the upper limit of LCG set in the IAB node 300-T. For example, if the upper limit of LCG is "16 (4 bits)", “00”, if the upper limit of LCG is "256 (8 bits)", “01”, and the upper limit of LCG is " "10” is stored in the case of "16,384 (14 bits)", and "11” is stored in the case that the upper limit value of LCG is "65,536 (16 bits)”.
- the relationship between the LCG upper limit value and the bits stored in the "LCG range” area may be other than this. Also, the number of bits stored in the "LCG range” area may be 3 or more in accordance with the upper limit of the LCG.
- the short variable extension format has an "LCG ID” area, but its bit length is variable according to the upper limit of LCG. That is, the "LCG ID” area existing in the (X) area of FIG. 15 (A) can be left-justified in order from the top in the (X) area on the drawing according to the upper limit value. Together with the "LCD ID” area (4 bits) other than the (X) area, it becomes the “LCD ID” area.
- the upper limit value of LCG is 256 (8 bits)
- the "BS" area is also aligned to the left following the "LCD ID” area, and the remaining area is "R”.
- the upper limit of the LCG is 32 (5 bits)
- the area on the left side of the uppermost area in the (X) area on the drawing will be included in the "LCG ID" area. Become.
- the "BS" area has 5 bits.
- the 'BS' field may be more than 5 bits.
- the long variable extension format also includes an "LCG range" area.
- the 'LCG range' area stores the same upper limit value of LCG as the 'LCG range' area of the short variable extension format.
- the IAB node 300-T may optionally use a fixed extended format (FIGS. 13(A) to 14(B)) or a variable extended format (FIGS. 15(A) and 15(B)). good.
- FIG. 16 is a diagram showing an operation example according to the second embodiment. The operation example shown in FIG. 16 will be described by appropriately using the configuration example of the cellular communication system 1 shown in FIG. 12(A).
- the IAB node 300-T starts processing in step S30.
- the upper node (parent node 300-P or donor node 200) sets the upper limit of LCG to the IAB node 300-T.
- the upper limit values are, for example, 8 (3 bits), 16 (4 bits), 32 (5 bits), . . . , 256 (8 bits), . . . , 16,384 (16 bits), . . . , 65,536 (16 bits).
- the IAB-DU of the parent node 300-P uses MAC CE or BAP Control PDU to the IAB-MT of the IAB node 300-T .
- LCG should be set.
- the CU of the donor node 200 uses the F1AP message or the RRC message to the IAB-DU (or IAB-MT) of the IAB node 300-T, An upper limit value for LCG may be set.
- the donor node 200 may transmit the upper limit value of LCG to the parent node 300-P.
- the IAB-MT of the IAB node 300-T that receives the setting of the upper limit of LCG from the donor node 200 may transmit the upper limit to the IAB-DU of the parent node 300-P.
- the IAB-MT of the IAB node 300-T determines (or selects) the MAC CE format to be used according to the set upper limit. For example, the IAB-MT of the IAB node 300-T selects an existing format (for example, FIG. 10(A) or FIG. 10(B)) when the upper limit is eight. Also, for example, the IAB-MT of the IAB node 300-T, if the upper limit is 16 or more, fixed extension format (eg, FIG. 13 (A) to FIG. 14 (B)) or variable extension format (eg, 15(A) or 15(B)) is selected.
- fixed extension format eg, FIG. 13 (A) to FIG. 14 (B)
- variable extension format eg, 15(A) or 15(B)
- step S33 the IAB-MT of the IAB node 300-T uses the determined format to transmit the legacy BSR and/or preemptive BSR to the parent node 300-P.
- step S34 the IAB node 300-T ends the series of processes.
- a modified example of the second embodiment is an example in which the LCG upper limit setting is set to different values for legacy BSR and preemptive BSR.
- a higher node eg, parent node 300-P or donor node 200
- sets different upper limits for legacy BSR and preemptive BSR to the first relay node eg, IAB node 300-T.
- the IAB node 300-T can report buffer sizes according to different upper limits for legacy BSRs and preemptive BSRs. Specifically, for example, it is possible to meet a request that the scheduling resolution may be increased by increasing the upper limit of LCG and the upper limit of preemptive BSR may be small.
- FIG. 17 is a diagram showing an operation example according to the modification of the second embodiment. The operation example shown in FIG. 17 will be described using the configuration example of the cellular communication system 1 shown in FIG. 12A as appropriate.
- step S40 the upper node (parent node 300-P or donor node 200) starts processing.
- the upper node sets the upper limit of LCG to the IAB node 300-T (the IAB-MT or IAB-DU of it) to different values for the legacy BSR and the preemptive BSR.
- the upper limit value of LCG and the type of BSR are linked and set.
- the settings may be made using an F1AP message or the like. If the upper node is the parent node 300-P, it may be set using BAP Control PDU or the like.
- the IAB-MT of the IAB node 300-T determines (or changes) the MAC CE format to be used according to the BSR type. For example, the IAB-MT of the IAB node 300-T selects the BSR MAC CE format of FIG. 13(A) or FIG. 13(B) when the LCG upper limit value for the legacy BSR is 16 (4 bits). , when the upper limit value of LCG for preemptive BSR is 256 (8 bits), select the BSR MAC CE format of FIG. 14(A) or 14(B).
- step S43 the IAB-MT of the IAB node 300-T transmits legacy BSR and preemptive BSR using the determined MAC CE format.
- step S44 the IAB node 300-T ends the series of processes.
- the third embodiment is an example of transmitting legacy BSR and preemptive BSR in one BSR MAC CE.
- a higher node eg, parent node 300-P or donor node 200
- a first relay node eg, IAB node 300-T
- the first relay node in accordance with the settings, sends an integrated buffer status report storing buffer sizes corresponding to logical channel groups classified by type of buffer status report to the parent node of the first relay node.
- a second relay node eg, parent node 300-P
- a BSR MAC CE that has been combined into one may be referred to as an integrated BSR.
- the integrated BSR for example, stores the LCG and the buffer size (BS) of each LCG, similar to the legacy BSR (or preemptive BSR).
- BS buffer size
- a MAC CE with the same format as the short BSR MAC CE may be used.
- a MAC CE with the same format as the long BSR MAC CE may be used.
- the IAB node 300-T will no longer transmit BSRs with different MAC CE formats, making it possible to prevent processing delays, for example.
- FIG. 18 is a diagram showing an operation example according to the third embodiment. The operation example shown in FIG. 18 will be described using the configuration example of the cellular communication system 1 shown in FIG. 12A as appropriate.
- step S50 the upper node (parent node 300-P or donor node 200) starts processing.
- the upper node sets the integrated BSR to the IAB-MT of the IAB node 300-T.
- the upper node may perform link setting between the LCG in the integrated BSR and the BSR type.
- LCG#0 to LCG#3 of the integrated BSR correspond to LCG#0 to LCG#3 of the legacy BSR, respectively
- LCG#4 to LCG#7 of the integrated BSR correspond to LCG#0 to LCG# of the preemptive BSR. 3, respectively, and settings that indicate that.
- Such an integrated BSR setting may be set using BAP Control PDU or MAC CE when the upper node is the parent node 300-P. Also, if the upper node is the donor node 200, it may be set using an F1AP message, an RRC message, or the like. Also, the donor node 200 may perform the setting for the parent node 300-P.
- the IAB-MT of the IAB node 300-T triggers the integrated BSR.
- the trigger may be a legacy BSR trigger condition.
- the trigger may also be a preemptive BSR trigger condition.
- the IAB-MT of the IAB node 300-T may trigger the integrated BSR at the trigger timing of the legacy BSR.
- the IAB-MT of the IAB node 300-T may trigger the integrated BSR at the trigger timing of the preemptive BSR.
- the upper node may set in the IAB-MT of the IAB node 300-T which of the two trigger conditions should trigger the integrated BSR.
- step S53 the IAB-MT of the IAB node 300-T identifies the legacy BSR buffer size (BS-L) and the preemptive BSR buffer size (BS-P). Then, the IAB-MT of the IAB node 300-T stores these buffer sizes in the integrated BSR's MAC CE in association with the LCG.
- BS-L legacy BSR buffer size
- BS-P preemptive BSR buffer size
- the IAB node 300-T associates BS-L#0 to BS-L#3 with LCG#0 to LCG#3, respectively. Also, for example, the IAB node 300-T associates BS-P#0 to BS-P#3 with LCG#4 to LCG#7, respectively. Then, the IAB node 300-T, for example, stores BS-L#0 to BS-L#3 in the MAC CE of the integrated BSR as the buffer sizes of LCG#0 to LCG#3 of the integrated BSR. Also, the IAB node 300-T, for example, stores BS-P#0 to BS-P#3 in the MAC CE of the integrated BSR as the buffer sizes of LCG#4 to LCG#7 of the integrated BSR.
- step S54 the IAB-MT of the IAB node 300-T transmits the integrated BSR to the parent node 300-P.
- step S55 the IAB node 300-T ends the series of processes.
- BH RLF Indication In a network composed of a plurality of IAB nodes 300 , a failure may occur in the backhaul link between the IAB nodes 300 . Such a failure is called "BH RLF (Backhaul Radio Link Failure)".
- FIG. 19 is a diagram showing an example of relationships between nodes according to the fourth embodiment.
- FIG. 19 also shows an example of BH RLF according to the fourth embodiment.
- FIG. 19 shows an example in which BH RLF occurs in the BH link #1 between the IAB node 300-P1, which is the parent node of the IAB node 300-T, and the node 500, which is its parent node.
- the IAB-DU of the parent node 300-P1 transmits a failure notification to the IAB node 300-T on the downstream side.
- a failure occurrence notification indicating that a BH RLF has been detected is called a Type 1 BH RLF Indication.
- the BH link RLF detected by the child node may be Type 1 BH RLF Indication.
- a recovery attempt notification indicating that recovery from a failure (BH RLF) that occurred in a backhaul link is being attempted is called a Type 2 BH RLF Indication.
- the example of FIG. 19 shows an example in which the parent node 300-P1 transmits a Type 2 BH RLF Indication to the IAB node 300-T.
- Type 1 BH RLF Indication and Type 2 BH RLF Indication are not distinguished, they are called Type 1/2 BH RLF Indication.
- Type 2 BH RLF Indication may be read as Type 1 BH RLF Indication.
- Type 1 BH RLF Indication is sent when BH RLF is detected, and Type 2 BH RLF Indication is sent when recovery is attempted. Therefore, Type 1 BH RLF Indication and Type 2 BH RLF Indication are substantially the same notification.
- the IAB node 300-T that has received the Type 2 BH RLF Indication can perform various controls. Details will be described later.
- Type 2 BH RLF Indication may be referred to as Type 2 Indication.
- BH RLF may occur on the backhaul link between the IAB nodes 300 .
- data packets can be forwarded to the destination IAB node 300 (or donor node 200) via an alternative path. Transferring data packets using an alternative path when a line failure occurs is sometimes referred to as local rerouting. Local rerouting is done by ignoring the routing preferences set by the donor node 200 and choosing an alternate path. Alternatively, local rerouting may be performed by selecting an alternate path from among alternate path candidates set by donor node 200 .
- condition handover In a typical handover, the UE 100 reports measurements of the radio conditions of the serving cell and/or neighboring cells to the gNB 200, and based on this report, the gNB 200 determines handover to the neighboring cell and sends a handover instruction to the UE 100. . For this reason, when the radio condition of the serving cell suddenly deteriorates, communication may be interrupted before handover is executed in general handover.
- conditional handover can autonomously execute handover to a candidate cell corresponding to the trigger condition when a preset trigger condition is met. Therefore, it is possible to solve problems such as communication interruption in general handover.
- Conditional handover execution conditions include one or more trigger conditions.
- a conditional handover configuration includes candidate cells and trigger conditions.
- a conditional handover configuration may include multiple combinations of candidate cells and trigger conditions.
- Conditional handover is set, for example, by an RRC message from the CU of donor node 200 to (IAB-MT of) IAB node 300 and/or UE 100 .
- the IAB node 300-T when the IAB node 300-T receives the Type 2 Indication from the parent node 300-P1, it can perform local rerouting and switch the connection destination to the parent node 300-P2. As a result, the IAB node 300-T can avoid the failed BH link #1 and transmit packets in the upstream direction to the target node (donor node 200), and provide continued service to the UE 100. can provide.
- the IAB node 300-T receives a Type 2 Indication from the parent node 300-P1, it enables conditional handover. Specifically, the IAB node 300-T switches the connection from the parent node 300-P1 to the parent node 300-P2 by conditional handover. As a result, the IAB node 300-T can avoid the BH link #1 and transmit upstream packets to the destination node, thereby providing continuous service to the UE 100.
- the IAB node 300-T can execute both local rerouting and conditional handover with reception of Type 2 Indication as a trigger, it selects which one to execute when Type 2 Indication is received. It is possible.
- the donor node 200 is a node that manages the entire topology. Donor node 200 also has the ability to control the performance of the entire topology.
- the donor node 200 can set to the IAB node 300-T whether to execute local rerouting or conditional handover by using reception of Type 2 Indication as a trigger.
- a donor base station eg, donor node 200 having first and second relay nodes under its control sends a local Configure rerouting and conditional handover (CHO).
- the first relay node receives the second relay node and the second relay node from the second relay node (for example, parent node 300-P1) that is the parent node of the first relay node. receive a failure recovery notification indicating that recovery from a failure that occurred on the backhaul link (eg, BH link #1) between the parent node (eg, node 500) of the .
- the first relay node performs local rerouting or conditional handover according to the configuration and upon receiving the failure recovery notification.
- the donor base station further configures to the first relay node whether to perform local rerouting or conditional handover in response to receiving the failure recovery notification.
- the donor node 200 sets whether the local rerouting or the conditional handover is to be performed for the IAB node 300-T. can be realized.
- FIG. 20 is a diagram showing an operation example according to the fourth embodiment. An operation example will be described using the configuration example shown in FIG. 19 as appropriate.
- the donor node 200 starts processing in step S60.
- step S61 the CU of the donor node 200 sets local rerouting and/or conditional handover to the IAB-MT of the IAB node 300-T.
- the CU of donor node 200 may utilize RRC messages to configure local rerouting and/or conditional handover.
- step S62 the CU of the donor node 200 sets the operation when receiving the Type 2 Indication to the IAB-MT of the IAB node 300-T.
- the operation setting is a setting related to whether to execute local rerouting or conditional handover when a Type 2 Indication is received (or to prioritize).
- the IAB node 300-T can transfer the packet to the parent node 300-P2 without performing connection switching setting processing. Therefore, from a short-term perspective, there is an advantage that the service can be continued without interruption of communication.
- the CU of the donor node 200 may set the operation settings to the IAB-MT of the IAB node 300-T using an RRC message.
- step S63 the IAB-MT of the IAB node 300-T receives Type 2 Indication from the IAB-DU of the parent node 300-P1.
- step S64 the IAB-MT of the IAB node 300-T executes local rerouting or conditional handover according to the settings.
- the IAB node 300-T ends a series of processes.
- a modification of the fourth embodiment is an example in which rules are determined in advance, and the IAB node 300-T executes local rerouting or conditional handover according to the rules, triggered by the reception of the Type 2 Indication.
- the first relay node for example, the IAB node 300-T
- the first relay node performs local rerouting or Perform a conditional handover.
- preset means, for example, being set (stored) in memory when the IAB node 300-T is installed.
- the IAB-MT of the IAB node 300-T reads out the information about the setting from the memory and executes it, thereby triggering the reception of the Type 2 Indication to execute local rerouting or conditional handover. Alternatively, it may be determined by hard coding in the specification.
- FIG. 21 is a diagram showing an operation example according to the modification of the fourth embodiment. Steps S71 and S72 are the same as steps S61 and S63 of the fourth embodiment, respectively.
- the IAB node 300-T executes local rerouting or conditional handover according to predetermined rules.
- Predetermined rules include, for example, the following. That is, the IAB node 300-T performs local rerouting when a Dual Connectivity connection is established and a path (alternative path) for performing local rerouting exists. Also, the IAB node 300-T executes a conditional handover when there is no Dual Connectivity connection or when there is no path (alternative path) for local rerouting.
- step S74 the IAB node 300-T ends the series of processes.
- a program that causes a computer to execute each process performed by the UE 100, the gNB 200, or the IAB node 300 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, the gNB 200, or the IAB node 300 is integrated, and at least a part of the UE 100, the gNB 200, or the IAB node 300 is a semiconductor integrated circuit (chipset, SoC (system on a chip)).
- chipsset, SoC system on a chip
- 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.
- Enhanced topology adaptation • Specification of procedures for inter-donor IAB node migration to enhance robustness and load balancing, including enhancements to reduce signaling load. • Specification of enhancements to reduce service disruption due to IAB node migration and BH RLF restoration. • Specification of enhanced topology redundancy, including support for CP/UP isolation. Topology, routing and transport enhancements: • Specification of enhancements to improve fairness, multi-hop delay, and congestion mitigation across the topology.
- RAN2#113-e addresses the issues discussed in Rel-17: 'IF' for fairness, 'IL' for delay, or 'IC' for congestion. pointed out the issues marked with .
- RAN2#113bis-e discussed possible solutions and only reached one consensus.
- Appendix 1 discusses possible solutions to these problems, focusing on IF-4, IL-2, IL-3, IL-5, IL-6, IC-1 and IC-7.
- IF-4 IF-4 was designated as: IF-4:
- the IAB node cannot aggregate more bearers and/or provide more resources for BH RLC channels carrying bearers with a high load per bearer (i.e. the IAB node is cannot provide more resources for BH RLC channels with higher .
- IF-4 Possible solutions for IF-4 are: • F1: The IAB node is configured with additional information by the CU. • F1-1: relates to the number of bearers in a particular BH RLC channel (actual number, average number, etc.). • F1-2: relates to the QoS of the bearer of a particular BH RLC channel. • F2: Additional information is added to the BAP header. ⁇ F2-1: Bearer ID. • F2-2: Bearer ID and hop count for a particular path. • F2-3: Number of UE DRBs in a particular BAP packet.
- ⁇ per packet'' scheduling is superior to ⁇ per RLC channel'' scheduling from a technical point of view.
- These scheduling can be done in the gNB's (or IAB-DU's) DL scheduler.
- LCP basically provides "per RLC channel" scheduling. In this sense, it may not be necessary to do 'per packet' scheduling only for the DL, given the additional overhead of all BAP PDUs in the DL and UL. Therefore, to improve fairness across Rel-17 topologies, a simpler solution, the F1 solution, is better suited.
- Proposal 1 RAN2 should agree that IAB donors set up IAB nodes using the number of bearers mapped to each BH RLC channel and the QoS of these bearers. That is, F1-1 and F1-2 are used to resolve IF-4.
- IL-2 Multi-hop delay- IL-2 IL-2 has been designated as: IL-2: Due to current (Rel-16) limitations on the number of LCGs, IAB nodes may need to report joint buffer status for LCHs with significantly different QoS requirements.
- IL-2 A possible solution for IL-2 is as follows.
- L4 A new operation or function is specified for the IAB node.
- L4-3 The number of LCGs in IAB-MT is increasing.
- the current LCG The space is 8 (ie maxLCG-ID is 7), which is common for UE and IAB-MT.
- the current LCH ID space is 32 (ie maxLC-ID).
- the maximum number of BH LCH IDs i.e. maxLC-ID-Iab-r16
- the BH LCH ID space i.e. BH-RLC channel ID-r16
- IAB-MT may require 16,384 LCGs (14 bits). This is certainly feasible, but it may be a little large to add to MAC CE. Some companies have proposed expanding the LCG space to at least 16 (4 bits), or 256 (8 bits). Therefore, RAN2 needs to consider what is best for the extended LCG space.
- Proposal 2 RAN2 should discuss the optimal maximum numbers for the extended LCG space: 16 (4 bits), 256 (8 bits), 16,384 (14 bits) and even 65,536 (16 bits) .
- IL-3 IL-3 was designated as: IL-3: Calculation of preemptive BSR buffer size is left to the implementation in Rel-16 and may vary from vendor to vendor.
- IL-3 A possible solution for IL-3 is as follows. • L4: A new operation or function is specified for the IAB node. L4-1: Buffer size calculation for preemptive BSR is specified.
- the buffer size calculation is clearly specified. It is based on data available in MAC, RLC and PDCP. For RLC and PDCP, the procedure for calculating the amount of data is specified in each specification. In Rel-16, these mechanisms are reused for data volume calculation of preemptive BSR of IAB-MT.
- the IAB node has a BAP layer instead of PDCP, and the BAP specification does not calculate the amount of data. Therefore, the current specification lacks data that can be used for transmission. To better schedule fairness across the topology, the buffer size reported in the legacy BSR needs to be more accurate.
- the calculation of the preemptive BSR buffer size is highly dependent on the IAB-DU implementation, but the specification states that "the buffer size field is It specifies the total amount of data expected and does not include the amount of data currently available in the IAB-MT.”
- the buffer size field is It specifies the total amount of data expected and does not include the amount of data currently available in the IAB-MT.
- some IAB nodes, with preemptive BSRs, do not actually arrive may report a buffer size larger than It can be difficult to set the same principles between child nodes and parent nodes. For example, multi-vendor deployments lead to inefficient radio resource allocation, scheduling delays at parent nodes, and unfair resource requests between IABs and MTs. If the IAB node is set up with dual connectivity, it can become more ambiguous. Therefore, the preemptive BSR buffer size calculation needs to be specified more precisely.
- the buffer size calculation is not specified for IAB-DU. That is, the buffered data at the receiving side (MAC and RLC) of the IAB-DU
- Proposal 3 RAN2 should agree to specify buffer size calculation for preemptive BSR (and possibly legacy BSR). That is, L4-1 is used to resolve IL-3.
- the MAC specification defines two conditions as follows. This means that the trigger condition is up to the IAB-MT implementation in Rel-16. Inappropriate UL grants occur because the parent node cannot accurately predict when data will actually be available for transmission.
- a preemptive BSR may be triggered for the specific case of IAB-MT if any of the following events occur: - A UL grant is provided to a child IAB node or UE. - BSR is received from a child IAB node or UE.
- the IAB node is configured to trigger a preemptive BSR on either UL grant transmission or BSR reception.
- the preemptive BSR is actually used in the parent node's IAB-DU, the scheduler. Therefore, at this point, further consideration is needed as to whether the trigger condition is set by the IAB donor or dictated by the parent IAB node.
- Proposal 4 RAN2 should agree that the triggers used for preemptive BSR are set at the IAB node. Whether done by the IAB donor or its parent IAB node requires further consideration.
- IL-5 and IL-6 IL-5 has been designated as: • IL-5: CU cannot place bearers with low PDB on routes with less congestion risk (higher resource efficiency) or RLF-free routes.
- a possible solution for IL-5 is as follows.
- L3 Additional signaling is introduced from the IAB node to the CU.
- L3-1 The IAB node's buffer/link status is shared with the CU.
- L3-2 Individual hop delay measurements per BH RLC channel are shared with the CU.
- L4 A new operation or function is specified for the IAB node.
- L4-2 Local rerouting is allowed for purposes other than RLF (eg, based on outgoing link delay).
- • F4-1 relates to load information per BH RLC channel.
- • F4-2 relates to per-hop delay and per-hop packet loss on individual links.
- IL-6 has been designated as: • IL-6: CU cannot configure routing based on actual (real-time) delay per BH RLC channel.
- IL-6 A possible solution for IL-6 is as follows. • L3: Additional signaling is introduced from the IAB node to the CU. L3-2: Individual hop delay measurements per BH RLC channel are shared with the CU. • F4: Additional signaling is introduced from the IAB node to the CU. • F4-2: relates to per-hop delay and per-hop packet loss on individual links. • L4: A new operation or function is specified for the IAB node. • L4-2: Local rerouting is allowed for purposes other than RLF (eg, based on outgoing link delay).
- IL-5 and IL-6 may have commonalities regarding additional signaling from the IAB node to the IAB donor, namely L3 and L4, which could be centralized optimization.
- L3 and L4 which could be centralized optimization.
- MDT and/or SON procedure can be viewed as a type of MDT and/or SON procedure, as it allows for
- Proposal 5 RAN2 should agree that IAB nodes report hop-by-hop delay measurements to IAB donors. That is, L3-2 is used to resolve IL-5 and IL-6.
- RAN2 has already agreed that "type 2 RLF indications can be used to trigger local rerouting" and "local rerouting can be triggered by hop-by-hop flow control indications". Therefore, there is no need to discuss this issue further in this agenda item. Thus, the details of local rerouting can be discussed in another agenda item on enhancing topology adaptation.
- IC-1 and IC-7 were annotated and designated as follows.
- R2 concluded that there is sufficient interest among companies to address two issues.
- IC-1 Existing Rel-16 DL HbH flow control mechanisms cannot be used to alleviate long-term downstream congestion on a single link without relying on packet drops.
- IC-7 CU (not aware of local congestion) cannot update routing paths that are congested. Both IC-1 and CI-7 are associated with RAN3. It is currently unclear to what extent RAN2 will work on this, as RAN3 seems to be working on this as well.
- CP-based congestion indications may include the following reports: - per BAP routing ID and/or - link per child node and/or - BH RLC CH ID (Down-selection needs further consideration).
- CP-based congestion indication reuses the F1APGNB-DU status indication procedure.
- CP-based congestion indication is related to DL congestion. For the UP-based approach to IAB congestion mitigation, we consider the following two options. ⁇ There is no functional enhancement. • A packet-marking-based approach.
- an IAB donor When an IAB donor receives a congestion indication from an IAB node, it can be assumed that the IAB donor can avoid the congested path as implied in the RAN2 agreement above. There are several ways to deal with this problem. That is, the IAB donor updates routing settings or directs local rerouting. In the latter case, RAN2 may be involved in how congestion indications are used. In either case, RAN2 must wait for RAN3 to make a decision before making a decision.
- Finding 4 RAN2 may be involved in how IAB donors behave due to signs of congestion after RAN3 has learned the details.
- Enhanced topology adaptation • Specification of procedures for inter-donor IAB node migration to enhance robustness and load balancing, including enhancements to reduce signaling load. • Specification of enhancements to reduce service disruption due to IAB node migration and BHRLF recovery. • Specification of enhanced topology redundancy, including support for CP/UP isolation. Topology, routing and transport enhancements: • Specification of enhancements to improve fairness, multi-hop delay, and congestion mitigation across the topology.
- Appendix 2 discusses various topics of Rel-17eIAB topology adaptation enhancements in addition to the current agreement. Specifically, enhancement of BH RLF indication, enhancement of conditional handover, and enhancement of local rerouting.
- Rel-16 BH RLF indication This allows the child IAB-MT to recognize the RLF on the parent node's BH link and initiate the RLF recovery procedure.
- Finding 1 Only Type 4 "recovery failure" was designated as a Rel-16 BH RLF indication.
- RAN2 agreed to introduce Type 2 “Recovery Attempt” and Type 3 “BH Link Recovery”, but detailed IAB node behavior remains for further study. is necessary.
- RAN2#113-e RAN2 supporting type 2/3 RLF indication (details need further study).
- a type 2 RLF indication can be used to trigger local rerouting.
- Type 2 RLF indications can be used to trigger deactivation of IABs supported by SIBs.
- Type 2 RLF indications can be used to trigger deactivation or reduction of SR and/or BSR transmissions.
- RAN2#113bis-e Further consideration is needed if other CHO execution conditions are required (eg, whether a Type 2 RLF indication can be used as a trigger).
- One of the things under further consideration is whether/how to specify the actions associated with the three possible use cases of the new BHR LF indication that RAN2 has already agreed.
- the trigger since BH RLF occurs in the UL from the perspective of the IAB node receiving the Type 2 BH RLF indication, the trigger should enable upstream local rerouting, i.e. UL path switching.
- downstream local rerouting is independent of Type 2 BH RLF indications, as IAB nodes receiving Type 2 BH RLF indications can maintain good BH links with downstream nodes. It can therefore be regarded as an IAB-MT operation that needs to be explicitly specified.
- Proposal 1 RAN2 should agree to specify that local rerouting should be triggered on the upstream path when IAB-MT receives a type 2 BH RLF indication from the parent node.
- Proposal 2 RAN2 specifies that when IAB-MT receives a type 3 BH RLF indication from the parent node, it stops local rerouting on the upstream path, i.e. returns to the configured "normal" routing have to agree.
- the deactivation of the IAB support IE in SIB1 it can be regarded as an IAB-DU operation that was widely considered until its implementation in Rel-16. Therefore, specifying only at stage 2 is probably sufficient. In particular, it can be assumed that the IAB-DU will not remove the IAB-Support IE from SIB1 if there are still alternative routes to the donor. This should be clarified when behavior is specified.
- Proposal 3 RAN2 should consider whether to remove the IAB-Support IE from SIB1 if the IAB-DU receives a Type 2 BH RLF indication only in stage 2 and there is no alternative route to the IAB donor. be.
- the IAB-MT will not initiate connection establishment to the parent node.
- One question is whether the UE is allowed access to the cell (ie parent node) even if the parent node is under BH RLF.
- the RRC setup request cannot reach the CU, ie the donor, which ultimately harms the user.
- the cell has the option of barring UE access, stopping SSB transmissions, or broadcasting a type 2BH RLF indication via SIB1. Similar to Proposal 3, if the IAB node has an alternative route to the donor, there is no need to remove the IAB Support IE from SIB1.
- Proposal 4 RAN2 should consider whether to bar UE access in addition to IAB-MT access when IAB-DU receives Type 2 BH RLF indication and there is no alternative route to the IAB donor. be.
- Deactivation or reduction of SR and/or BSR transmissions may be considered IAB-MT actions and should be explicitly specified.
- deactivation may be easier from a specification standpoint.
- SR and/or BSR can only be sent after receiving Type 3, which can lead to scheduling delays.
- Reduce on the other hand, may cause unwanted interference, but may allow scheduling to resume immediately after the BH link is restored. Therefore, RAN2 needs to discuss whether to support SR and/or BSR "deactivation", "reduction”, or both. If both are supported, they should be configurable by the IAB donor.
- Proposal 5 RAN2 should agree to specify that SR and/or BSR transmissions should be deactivated or reduced when IAB-MT receives a Type 2 BH RLF indication from the parent node .
- Proposal 6 RAN2 should agree to specify that when IAB-MT receives a type 3 BH RLF indication from the parent node, it can resume normal procedures for SR and/or BSR transmission.
- Proposal 7 RAN2 supports 'deactivation', 'reduction', or both (i.e. configurable) of SR and/or BSR when a Type 2 BH RLF indication is received from a parent node need to consider whether
- CHO is triggered by receipt of a Type 2BH RLF indication.
- a Type 2 BH RLF indication sent, the parent node has experienced a BH RLF and is attempting to restore the BH link. This of course means that the IAB node cannot communicate with the donor. If the IAB node is configured with dual connectivity, it may choose to perform local rerouting between the MCG and SCG, as in Proposal 1.
- IAB nodes need the option to trigger CHO when receiving a type 2BH RLF indication. Additionally, as a further optimization, it is worth considering whether the IAB node should cancel the CHO execution if it receives a type 3 BH RLF indication before it actually executes the CHO.
- Proposal 8 RAN2 should agree to specify that CHO should be triggered when IAB-MT receives a type 2BH RLF indication from the parent node.
- Proposal 9 RAN2 should consider whether to cancel CHO execution (if possible) when IAB-MT receives a type 3 BH RLF indication from the parent node.
- Proposal 1 and Proposal 8 can be agreed upon, that is, for IAB nodes configured with dual connectivity, local rerouting, and CHO at the same time, when receiving a type 2 BH indication, either local rerouting or CHO You can choose to trigger.
- local rerouting with type 2 reception helps avoid service interruptions, whereas CHO with type 2 reception is better for long-term/topology-wide performance. Since local rerouting and CHO are triggered by conditions other than type 2 reception, it is assumed that they are primarily configured for various purposes such as handover robustness due to event A3.
- Proposal 10 If both Proposition 1 and Proposition 8 can be agreed, RAN2 should further agree that IAB donors can configure IAB nodes to trigger local rerouting or CHO because they have received a Type 2 BH RLF indication. There is
- Type 2 and Type 3 BH RLF indications are considered as straightforward to be sent via BAP Control PDUs as is the case for Rel-16 Type 4 BH RLF indications. Similar to proposal 3 above, there is no BAP layer because the UE cannot receive BAP control PDUs. Therefore, it is possible that these BH RLF indications are broadcast over SIB1 and SIB1 is encoded by DU. Therefore, RAN2 needs to consider whether these are sent via BAP Control PDUs or SIB1.
- Proposal 11 RAN2 should discuss whether Type 2 and Type 3 BH RLF indications are sent via BAP Control PDU or SIB1.
- Conditional Handover was introduced in Rel-16 to improve mobility robustness. CHO can be used for designated Rel-16IAB. RAN2#113-e and RAN2#113-e have reached the following agreement. Therefore, it is worth considering eIAB CHO extensions in addition to Rel-16 CHO.
- RAN2#113-e RAN2 discusses CHOs and starts with intra-donor CHO discussions until RAN3 proceeds with discussions on inter-donor IAB node migration.
- RAN2 confirms the intention that Rel-16 CHO is/can be used for IAB-MT (whether changes are necessary requires further consideration).
- RAN2 assumes that the Rel-16 specification is the baseline for setting default routes, IP addresses, and target paths for intra-donor CHOs.
- RAN2#113bis-e IAB-MT CHO use cases should be migration and RLF recovery.
- RAN2 requires a common solution for intra-CU/intra-DU CHO and intra-CU/inter-DU CHO.
- CHO event A3 and CHO event A5 are applicable to IAB-MT. Further consideration is needed if other CHO execution conditions are required (eg, whether a Type 2 RLF indication can be used as a trigger).
- IAB-MT For IAB-MT, selecting one of the triggered cells is not always the best approach, as IAB-MT implements depending on the local radio quality. This is because the overall topology goal may be effectively handled by IAB donors as discussed in RAN2#112-e. Therefore, RAN2 needs to consider how CHO implementation of IAB donor control with additional trigger conditions works as per Proposition 8. For example, an IAB donor can set priority information associated with a CHO candidate in the CHO settings. IAB-MT needs to select the highest priority cell from all triggered CHO candidates that meet a certain radio quality (such as S criteria).
- Proposal 12 RAN2 should consider whether IAB donor-controlled CHO execution is required as an additional enhancement if all candidate cells trigger CHO upon receipt of a Type 2 BH RLF indication.
- RAN2#113-e has reached the following agreements related to local rerouting enhancements.
- a type 2 RLF indication can be used to trigger local rerouting.
- Local rerouting can be triggered by indicating hop-by-hop flow control. Details such as trigger information, trigger conditions, and the role of CU settings need further study.
- RAN2 considers inter-donor DU local rerouting in scope.
- the IAB donor is the most appropriate entity to ensure the purpose of the overall topology.
- IAB donor controllability should become more important. It is easy for IAB donors to set up alternate paths. This forces the IAB node to choose an alternate path when performing local rerouting. Alternate path modeling needs further study. For example, whether alternate paths have the same routing ID.
- Proposal 13 RAN2 should consider whether IAB donors can set up IAB nodes using alternate paths in addition to Rel-16 routing settings.
- IAB donors should be aware of local rerouting and consider that they can start/stop local rerouting at IAB nodes in order to coexist local rerouting and overall topology goals. . For example, based on knowledge of which IAB nodes are currently performing local rerouting, IAB donors can consider whether the goals of the overall topology are still being met. If the IAB donor finds that the objectives of the overall topology cannot be achieved, the IAB donor may instruct the IAB nodes to start/stop local rerouting, or the IAB donor may change the routing configuration of the entire IAB topology. be.
- the IAB donor may need information and controllability of the local decision of the IAB node.
- Proposal 14 RAN2 should consider whether IAB nodes need to notify IAB donors when starting/stopping local rerouting.
- Proposal 15 RAN2 should discuss whether IAB donors can instruct IAB nodes to start/stop local rerouting.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
第1の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、配下に第1の中継ノード及び当該第1の中継ノードの親ノードである第2の中継ノードを有するドナー基地局が、前記第1の中継ノードへ、論理チャネル(LCH)のホップ数と論理チャネルグループ(LCG)との対応関係を表す対応情報を設定することを含む。また、前記通信制御方法は、前記第1の中継ノードが、前記第2の中継ノードへ、前記対応情報に基づいて、バッファステータスレポート(BSR)を送信することを含む。更に、前記通信制御方法は、前記第2の中継ノードが、前記第1の中継ノードへ、前記対応情報と前記バッファステータスレポートとに基づいて、アップリンクグラント(UL grant)を送信することを含む。
Description
本開示は、セルラ通信システムに用いる通信制御方法に関する。
セルラ通信システムの標準化プロジェクトである3GPP(Third Generation Partnership Project)において、IAB(Integrated Access and Backhaul)ノードと呼ばれる新たな中継ノードの導入が検討されている(例えば、「3GPP TS 38.300 V16.5.0(2021-03)」参照)。1又は複数の中継ノードが、基地局とユーザ装置との間の通信に介在し、この通信に対する中継を行う。
第1の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、配下に第1の中継ノード及び当該第1の中継ノードの親ノードである第2の中継ノードを有するドナー基地局が、第1の中継ノードへ、論理チャネル(LCH)のホップ数と論理チャネルグループ(LCG)との対応関係を表す対応情報を設定することを含む。また、前記通信制御方法は、第1の中継ノードが、第2の中継ノードへ、対応情報に基づいて、バッファステータスレポート(BSR)を送信することを含む。更に、前記通信制御方法は、第2の中継ノードが、第1の中継ノードへ、対応情報とバッファステータスレポートとに基づいて、アップリンクグラント(UL grant)を送信することを含む。
第2の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、第1の中継ノードの上位ノードが、第1の中継ノードへ、論理チャネルグループに関する設定値を設定することを含む。また、前記通信制御方法は、第1の中継ノードが、設定値に対応するMACコントロールエレメント(CE)フォーマットを決定することを含む。更に、前記通信制御方法は、第1の中継ノードが、第1の中継ノードの親ノードである第2の中継ノードへ、MACコントロールエレメントフォーマットを用いて、バッファステータスレポートを送信することを含む。
第3の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、第1の中継ノードの上位ノードが、第1の中継ノードへ、統合バッファステータスレポートの設定を行うことを含む。また、前記通信制御方法は、第1の中継ノードが、設定に従って、バッファステータスレポートの種別毎に分類された論理チャネルグループに対応するバッファサイズが格納された前記統合バッファステータスレポートを、第1の中継ノードの親ノードである第2の中継ノードへ送信することを含む。
第4の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、第1の中継ノード及び当該第1の中継ノードの親ノードである第2の中継ノードを配下に有するドナー基地局が、第1の中継ノードへ、ローカルリルーティング及び条件付きハンドオーバ(CHO)の設定を行うことを含む。また、前記通信制御方法は、第1の中継ノードが、第2の中継ノードから、当該第2の中継ノードと当該第2の中継ノードの親ノードとの間のバックホールリンクで発生した障害に対して当該障害からの回復を試行中であることを示す障害回復通知を受信することを含む。更に、前記通信制御方法は、第1の中継ノードが、障害回復通知の受信に応じて、ローカルリルーティング又は条件付きハンドオーバを実行することを含む。
図面を参照しながら、実施形態に係るセルラ通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
(セルラ通信システムの構成)
まず、一実施形態に係るセルラ通信システムの構成例について説明する。一実施形態に係るセルラ通信システムは3GPPの5Gシステムである。具体的には、セルラ通信システム1における無線アクセス方式は、5Gの無線アクセス方式であるNR(New Radio)である。但し、セルラ通信システムには、LTE(Long Term Evolution)が少なくとも部分的に適用されてもよい。また、セルラ通信システムは、6Gなど、将来のセルラ通信システムも適用されてよい。
まず、一実施形態に係るセルラ通信システムの構成例について説明する。一実施形態に係るセルラ通信システムは3GPPの5Gシステムである。具体的には、セルラ通信システム1における無線アクセス方式は、5Gの無線アクセス方式であるNR(New Radio)である。但し、セルラ通信システムには、LTE(Long Term Evolution)が少なくとも部分的に適用されてもよい。また、セルラ通信システムは、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との無線通信を行う機能又はリソースを示す用語として用いられることがある。また、セルは、gNB200など、基地局と区別しないで用いられる場合がある。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をサポートする。ドナーgNB(又はドナーノード。以下、「ドナーノード」と称する場合がある。)200-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(Central Processing Unit)とを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部230は、以下に示す各実施形態において、gNB200(又はドナーノード200)おける各種処理を行ってもよい。
(中継ノードの構成)
次に、実施形態に係る中継ノード(又は中継ノード装置。以下、「中継ノード」と称する場合がある。)である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 Controll)レイヤと、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:Hybrid Automatic Repeat reQuest)による再送処理、及びランダムアクセスプロシージャ等を行う。IABノード300-2のIAB-MTのMACレイヤとIABノード300-1のIAB-DUのMACレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。IAB-DUのMACレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット(トランスポートブロックサイズ、変調・符号化方式(MCS:Modulation and Coding Scheme))及び割当リソースブロックを決定する。
RLCレイヤは、MACレイヤ及びPHYレイヤの機能を利用してデータを受信側のRLCレイヤに伝送する。IABノード300-2のIAB-MTのRLCレイヤとIABノード300-1のIAB-DUのRLCレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
PDCPレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。IABノード300-2のIAB-MTのPDCPレイヤとドナーノード200のCUのPDCPレイヤとの間では、無線ベアラを介してデータ及び制御情報が伝送される。
RRCレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。IABノード300-2のIAB-MTのRRCレイヤとドナーノード200のCUのRRCレイヤとの間では、各種設定のためのRRCシグナリングが伝送される。ドナーノード200とのRRC接続がある場合、IAB-MTはRRCコネクティッド状態である。ドナーノード200とのRRC接続がない場合、IAB-MTはRRCアイドル状態である。
RRCレイヤの上位に位置するNASレイヤは、セッション管理及びモビリティ管理等を行う。IABノード300-2のIAB-MTのNASレイヤとAMF11のNASレイヤとの間では、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(Quality of Service)制御が可能である。BAP PDUとバックホールRLCチャネルとの対応付けは、各IABノード300のBAPレイヤ及びドナーノード200のBAPレイヤによって実行される。
なお、ドナーノード200のCUは、IABノード300とドナーノード200のDUへのF1インターフェイスを終端する。ドナーノード200のCUは、ドナーノード200のgNB-CU機能である。また、ドナーノード200のDUは、IAB BAPサブレイヤをホストし、IABノード300へワイヤレスバックホールを提供する。ドナーノード200のDUは、ドナーノード200のgNB-DU機能である。
図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実施形態について説明する。
(BSR(Buffer Status Report)について)
一般的に、UE100が送信するBSR(以下、適宜「レガシーBSR」と呼ぶ。)は、MAC、RLC、及びPDCPの各レイヤの未送信上りリンクデータ量(すなわち、上りリンクバッファ量)を論理チャネルグループ(LCG)ごとに示すものである。各LCGは少なくとも1つの論理チャネルを含み、優先度別に設定されるグループである。gNB200は、UE100から受信したレガシーBSRに基づいて、UE100の未送信上りリンクデータ量をLCGごとに把握し、この未送信上りリンクデータ量に見合った上りリンク無線リソースをUE100に割り当てるようにスケジューリングを行う。
一般的に、UE100が送信するBSR(以下、適宜「レガシーBSR」と呼ぶ。)は、MAC、RLC、及びPDCPの各レイヤの未送信上りリンクデータ量(すなわち、上りリンクバッファ量)を論理チャネルグループ(LCG)ごとに示すものである。各LCGは少なくとも1つの論理チャネルを含み、優先度別に設定されるグループである。gNB200は、UE100から受信したレガシーBSRに基づいて、UE100の未送信上りリンクデータ量をLCGごとに把握し、この未送信上りリンクデータ量に見合った上りリンク無線リソースをUE100に割り当てるようにスケジューリングを行う。
図9(A)は、第1実施形態に係るレガシーBSRの送信例を表す図である。図9(A)では、「Regular BSR」と表されているが、以下では、「Regular BSR」もレガシーBSRと称する場合がある。
図9(A)は、IABノード300-Tが、子ノード300-Cからデータを受信後、レガシーBSRを親ノード300-Pへ送信する例を表している。
図9(A)に示すように、IABノード300-TのIAB-MTは、レガシーBSRを利用して、IABノード300-TのIAB-MTにおけるMACとRLCとに存在する送信待ち(又はバッファリングしている)データ量を、バッファサイズとして報告する。親ノード300-PのIAB-DUは、IABノード300-Tに対して、このデータ量に見合った上りリンク無線リソースを割り当てる。IABノード300-TのIAB-MTは、割り当てられた上りリンク無線リソースを利用して、当該データを、親ノード300-Pへ送信する。
図9(B)及び図(C)は、第1実施形態に係るプリエンプティブBSR(pre-emptive BSR)の送信例を表す図である。
図9(B)に示すように、IABノード300-TのIAB-DUが、子ノード300-Cへアップリンクグラント(UL grant)を送信後、子ノード300-CからULデータを受信する前に、IABノード300-TのIAB-MTが、プリエンプティブBSRを親ノード300-Pへ送信する。また、図9(C)に示すように、IABノード300-TのIAB-DUが、子ノード300-CからレガシーBSRを受信後、UL grantを子ノード300-Cへ送信する前に、IABノード300-TのIAB-MTが、プリエンプティブBSRを親ノード300-Pへ送信する。
このように、プリエンプティブBSRは、レガシーBSRよりも早いタイミングで、親ノード300-Pへ送信される。そのため、プリエンプティブBSRは、レガシーBSRの場合と比較して、親ノード300-PのIABノード300-Tに対するULスケジューリングの遅延(レイテンシ)を低減させることが可能となる。
図10(A)は、第1実施形態に係るショートBSR(Short BSR)のMAC CE(以下、「ショートBSR MAC CE」と称する場合がある。)の構成例を表す図である。1つのLCG(Logical Channel Group)が送信に利用可能データを有する場合、ショートBSR MAC CEが用いられる。すなわち、1つのLCGのバッファサイズを報告する場合は、ショートBSR MAC CEが用いられる。
図10(A)に示すように、ショートBSR MAC CEは、「LCG ID」領域と「バッファサイズ」領域とを含む。
「LCG ID」領域は、バッファサイズが報告される論理チャネルグループの識別情報が格納される領域である。「LCG ID」領域の領域長は3ビットである。
「バッファサイズ領域」は、MAC PDUが構築された後(すなわち、論理チャネル優先順位付け手順(logocal channel prioritization procedure)後)、論理チャネルグループ内の全ての論理チャネルに亘って、所定の計算手順に従って、利用可能な総データ量が格納される領域である。「バッファサイズ」領域の領域長は5ビットである。
図10(B)は、第1実施形態に係るロングBSR(Long BSR)のMAC CE(以下、「ロングBSR MAC CE」と称する場合がある。)の構成例を表す図である。1より多いLCG(Logical Channel Group)が送信に利用可能データを有する存在する場合に、ロングBSR MAC CEが用いられる。すなわち、複数のLCGのバッファサイズを報告する場合は、ロングBSR MAC CEが用いられる。
なお、図10(B)は、プリエンプティブBSRのMAC CE(以下、「プリエンプティブBSR MAC CE」と称する場合がある。)の構成例も表している。
図10(B)に示すBSR MAC CEは、「LCGi」領域と、「バッファサイズ領域」とを含む。
「LCGi」領域は、論理チャネルグループiのバッファサイズが存在することを示す領域である。すなわち、LCGiに「1」が設定されると、論理チャネルグループiのバッファファイズが報告されることを表す。他方、LCGiに「0」が設定されると、論理チャネルグループiのバッファサイズが報告されないことを表す。「LCGi」領域の領域長は8ビットである。
「バッファサイズ」領域は、図10(B)に示すMAC CEがロングBSR MAC CEの場合は、ショートBSR MAC CEの「バッファサイズ」領域と同じである。他方、図10(B)に示すMAC CEがプリエンプティブBSR MAC CEの場合、「バッファサイズ領域」は、所定のバッファサイズが格納される。所定のバッファサイズは、プリエンプティブBSRがトリガされたIABノード300(図9の場合はIABノード300-T)のIAB-MTに到着することが期待されるデータの総量であって、IAB-MTにおいて現在利用可能なデータの総量は含まない。
なお、図10(A)のショートBSR MAC CEは、ショートトランケイテッド(Truncated)BSRのMAC CEを表す。また、図10(B)のロングBSR MAC CEは、ロングトランケイテッドBSRのMAC CEを表す。
トランケイテッドBSRは、MACレイヤがMAC PDUを構成する際に挿入するパディングビット(又はパディングデータ)に対応するBSRである。パディングビットが、ショートBSRにサブヘッダを追加したサイズと同じ場合は、図10(A)のMAC CEが利用される。また、パディングビットが、ショートBSRにサブヘッダを追加したサイズより大きい場合は、図10(B)のMAC CEが利用される。
なお、以下では、ショートBSR MAC CEとショートトランケイテッドBSR MAC CEとを区別しない場合、ショートBSR MAC CEとして説明する場合がある。また、ロングBSR MAC CE、プリエンプティブBSR MAC CE、及びロングトランケイテッドBSR MAC CEを区別しない場合は、ロングBSR MAC CEとして説明する場合がある。
また、以下では、プリエンプティブBSRとレガシーBSRとを区別しない場合は、「BSR」と称する場合がある。
第1実施形態では、IABノード300が、ホップ数と紐づけられた各論理チャネルグループのバッファサイズを親ノードへ報告する例である。
具体的には、第1に、配下に第1及び第2の中継ノードを有するドナー基地局(例えばドナーノード200)が、第1の中継ノード(例えば、IABノード300-T)へ、論理チャネル(LCH)のホップ数と論理チャネルグループ(LCG)との対応関係を表す対応情報を設定する。第2に、第1の中継ノードが、第1の中継ノードの親ノードである第2の中継ノード(例えば、親ノード300-P)へ、対応情報に基づいて、バッファステータスレポート(BSR)を送信する。第3に、第2の中継ノードが、第1の中継ノードへ、対応情報とバッファステータスレポートとに基づいて、アップリンクグラント(UL grant)を送信する。
このように、第1実施形態では、LCHのホップ数とLCGとを紐づける。IABノード300は、BSRを利用して、ホップ数と紐づけられたLCGのバッファサイズを親ノードへ報告する。親ノードは、LCGとホップ数とが紐づけられているため、LCG内のバッファサイズを、ホップ数に対応するバッファサイズとして把握できる。親ノードは、バッファサイズだけではなく、ホップ数も用いて、IABノード300に対して、上りリンク無線リソースを割り当てる。
従って、親ノードは、例えば、遅延の大きい(又はホップ数が大きい)IABノード300に対して、他よりも多くの上りリンク無線リソースを割り当てることが可能となる。そのため、遅延削減を図り、トポロジ全体の公平性確保を実現することが可能となる。
(第1実施形態の構成例)
まず、第1実施形態の構成例について説明する。図12(A)は、第1実施形態に係るセルラ通信システム1の構成例を表す図である。
まず、第1実施形態の構成例について説明する。図12(A)は、第1実施形態に係るセルラ通信システム1の構成例を表す図である。
図12(A)に示すように、ドナーノード200は、配下にIABノード300-P,300-T,及び300-Cを有する。ドナーノード200が構築するトポロジ(又はネットワーク)は、他のIABノードが含まれてもよい。
IABノード300-Tの親ノードは、IABノード300-Pである。また、IABノード300-Tの子ノードは、IABノード300-Cである。以下では、IABノード300-Pを親ノード300-P、IABノード300-Cを子ノード300-Cと称する場合がある。
IABノード300-Tの上位ノードは、親ノード300-Pでもよい。また、IABノード300-Tの上位ノードは、ドナーノード200でもよい。なお、親ノード300-Pがドナーノード200であってもよい。
図12(A)の例では、IABノード300-Tは、1つの親ノード300-Pと接続されている例を表しているが、複数の親ノード300-P1,300-P2,...と接続されてもよい。この場合、例えば、IABノード300-Tは、Dual Connectivityにより、親ノード300-P1及び親ノード300-P2と接続されてもよい。親ノード300-P1には、Dual Connectivityにおけるマスタセルグループ(MCG)が設定され、親ノード300-P2には、セカンダリセルグループ(SCG)が設定されることで、IABノード300-Tが、2つの親ノード300-P1及び300-P2に接続可能となる。
また、図12(A)の例では、IABノード300-Tに子ノード300-Cが接続される例を表しているが、子ノード300-Cに代えて、UE100がIABノード300-Tに接続されてもよい。また、IABノード300-Tに子ノード300-CとUE100とが双方接続されてもよい。なお、以下では、子ノード300-CがIABノード300-Tに接続されるものとして説明する。
(第1実施形態の動作例)
図11は、第1実施形態に係る動作例を表す図である。図12(A)に示すセルラ通信システム1の構成例を適宜用いて、図11に示す動作例を説明する。
図11は、第1実施形態に係る動作例を表す図である。図12(A)に示すセルラ通信システム1の構成例を適宜用いて、図11に示す動作例を説明する。
図11に示すように、ステップS10において、ドナーノード200は、処理を開始する。
ステップS11において、ドナーノード200は、IABノード300-T(のIAB-MT又はIAB-DU)へ、ホップ数毎にLCGが紐づけられた紐づけ情報を設定する。紐づけ情報は、LCHのホップ数によって分類される。例えば、紐づけ情報として、LCHのホップ数「2」が、LCG#8からLCG#15に紐づけられ、論理チャネルのホップ数「3」が、LCG#16~LCG#32に紐づけられる、等の情報が含まれる。
ここで、ホップ数は、当該LCHが属するルートにおける全ホップ数であってもよい。又は、ホップ数は、当該LCHにおいて、IABノード300-Tに至るまでに経過したホップ数であってもよい。又は、ホップ数は、当該LCHにおいて、IABノード300-Tからドナーノード200に至るまでの残りホップ数であってもよい。
このように紐づけ情報は、LCHのホップ数とLCGとの対応関係を表す対応情報であってもよい。なお、以下では、「紐づける」ことと、「対応する」こととを、区別しないで用いる場合がある。
なお、ドナーノード200のCUは、IABノード300-TのIAB-MTへ、紐づけ情報を含むRRCメッセージを送信することで、設定を行ってもよい。また、ドナーノード200のCUは、IABノード300-TのIAB-DUへ、紐づけ情報を含むF1APメッセージを送信することで、設定を行ってもよい。
また、ドナーノード200は、紐づけ情報を親ノード300-Pへ設定してもよい。この場合、ドナーノード200は、上記と同様に、紐づけ情報を含むRRCメッセージ又はF1APメッセージを親ノード300-Pへ送信することで、設定を行ってもよい。又は、親ノード300-Pには、紐づけ情報がハードコーディングとして、予め設定されていてもよい。
ステップS12において、IABノード300-TのIAB-MTは、設定に従い、親ノード300-PへBSRを送信する。BSRには、ホップ数と紐づけられたLCG毎に、バッファサイズが格納される。例えば、BSRには、ホップ数「2」に対応するLCG#8のバッファサイズ、ホップ数「2」に対応するLCG#9のバッファサイズ、...、ホップ数「2」に対応するLCG#15のバッファサイズ、...、ホップ数「3」に対応するLCG#16のバッファサイズ、...が格納される。なお、BSRは、上述したように、レガシーBSRでもよい。また、BSRは、プリエンプティブBSRでもよい。
ステップS13において、親ノード300-PのIAB-DUは、BSRの受信に応じて、紐づけ情報を用いて、LCG毎のホップ数とバッファ状態とを特定する。例えば、親ノード300-Pは、BSRとして、LCG#15のバッファサイズの報告を受けたとき、紐づけ情報を用いて、LCG#15に対応するホップ数「2」のバッファサイズであることを、特定する。
ステップS14において、親ノード300-PのIAB-DUは、紐づけ情報とBSRとに基づいて、IABノード300-TのIAB-MTに対して、上りリンク無線リソースを割り当てる。そして、親ノード300-Pは、当該割り当て情報を含む、UL grantをIABノード300-Tへ送信する。例えば、親ノード300-PのIAB-DUは、ホップ数が他よりも大きいLCGのデータが滞留しているIABノード300-TのIAB-MTへ、他よりも多くの上りリンク無線リソースを割り当てる。
そして、ステップS15において、一連の処理が終了する。
(第1実施形態の変形例)
次に、第1実施形態の変形例について説明する。第1実施形態の変形例は、1つのLCHに対して、ホップ数毎に複数のLCGを割り当てる例である。具体的には、第1の中継ノード(例えば、IABノード300-T)が、対応情報に基づいて、論理チャネルを介して受信したパケットのホップ数に対応する論理チャネルグループを特定し、当該論理チャネルグループのバッファサイズを含むバッファステータスレポートを第2の中継ノード(例えば、親ノード300-P)へ送信する。
次に、第1実施形態の変形例について説明する。第1実施形態の変形例は、1つのLCHに対して、ホップ数毎に複数のLCGを割り当てる例である。具体的には、第1の中継ノード(例えば、IABノード300-T)が、対応情報に基づいて、論理チャネルを介して受信したパケットのホップ数に対応する論理チャネルグループを特定し、当該論理チャネルグループのバッファサイズを含むバッファステータスレポートを第2の中継ノード(例えば、親ノード300-P)へ送信する。
図12(B)は第1実施形態の変形例に係る動作例を表す図である。図12(A)に示すセルラ通信システム1の構成例を適宜用いて、図12(B)に示す動作例を説明する。
ただし、1つのLCH(BH RLC channel)には、N本のUEベアラがマッピングされる(1:Nマッピング)。そして、N本のUEベアラは、各々、他と異なるルート(ホップ数)を有しているものとする。
IABノード300-Tは、紐づけ情報が設定されると(ステップS11:図11と同じ)、ステップS120において、LCH(BH RLC channel)を介して受信したパケットをホップ数毎に分類する。
ここで、IABノード300-Tは、例えば、以下のようにして、ホップ数を確認してもよい。
第1に、受信したパケットのヘッダからホップ数を取得してもよい。受信したBAPパケットのBAPヘッダに、ホップ数情報が格納されていれば、IABノード300-T(のIAB-DU)は、BAPヘッダからホップ数情報を取得することでホップ数を確認できる。
第2に、IABノード300-Tの実装からホップ数を取得してもよい。すなわち、IABノード300-TのIAB-DUは、どのBH RLC channelからパケットを受信したのかを把握している。IABノード300-TのIAB-DUは、パケットを受信するごとに、IABノード300-TのIAB-MTへ、どのパケットがどのルートを経由したのかを通知する。IABノード300-TのIAB-MTは、IAB-DUから通知された情報に基づいて、ホップ数を取得してもよい。
そして、ステップS120において、IABノード300-TのIAB-MTは、紐づけ情報に基づいて、分類したホップ数に対応するLCGを特定し、当該LCG毎にバッファサイズを算出する。IABノード300-TのIAB-MTは、算出したバッファサイズを含むBSRを、親ノード300-Pへ送信する。
IABノード300-Tは、ステップS120の処理を終了すると、第1実施形態と同様に、ステップS13(図11)以降の処理を行う。
第1実施形態の変形例では、IABノード300-Tは、パケット毎にLCGを特定して、バッファサイズを算出しているため、パケット単位でバッファサイズを親ノード300-Pへ報告できる。親ノード300-Pは、遅延の大きいパケットを有するIABノード300-Tへ、他よりも多くのリソースを割り当てることが可能となる。そのため、遅延削減を図り、更には公平性確保を実現することが可能となる。
(第2実施形態)
次に、第2実施形態について説明する。
次に、第2実施形態について説明する。
図10(A)及び図10(B)に示すように、3GPPのリリース16において、LCG数の上限は、LCG数で8個(例えば図10(B))、ビット数では3ビット(例えば図10(A))である。以下、上限を、「X個(Yビット)」と表す。
他方、LCH数の上限は、IAB-MTについては、65、536個(16ビット)まで存在する。LCG数の上限が、LCH数の上限と同じ程度まで確保されると、LCG数の上限も、65、536個(16ビット)とすることが可能である。仮に、高解像度のスケジューリングのために、LCG数が65、536個(16ビット)存在する場合を考える。このような場合、IABノード300が、65、536個(16ビット)のLCGを、既存のBSR MAC CEを利用して送信する場合、図10(B)に示すBSRを8192回送信する。
しかし、これでは、オーバーヘッドが大きくなる。
そこで、第2実施形態では、LCGの上限値を設定可能とし、IABノード300-Tは、設定されたLCGの上限値に対応するBSR MAC CEフォーマットを利用して、BSRを親ノード300-Pへ報告する。
そのため、IABノード300-Tは、既存のBSR MAC CEフォーマット(図10(A)及び図10(B))に加えて、固定拡張フォーマットのBSR MAC CEと、可変拡張フォーマットのBSR MAC CEとを利用する。IABノード300-Tは、これらのMAC CEフォーマットの中から、LCGの上限値に対応するMAC CEフォーマットを選択する(又は決定する)。
具体的には、第1に、第1の中継ノード(例えば、IABノード300-T)の上位ノード(例えば、親ノード300-P又はドナーノード200)が、第1の中継ノードへ、論理チャネルグループの上限値を設定する。第2に、第1の中継ノードが、上限値に対応するMACコントロールエレメント(CE)フォーマットを決定する。第3に、第1の中継ノードが、第1の中継ノードの親ノードである第2の中継ノード(例えば、親ノード300-P)へ、決定したMACコントロールエレメントフォーマットを用いて、バッファステータスレポートを送信する。
このように、IABノード300-Tは、LCGの上限値に対応するBSR MAC CEを利用して、BSRを報告できるため、BSRを複数回送信することがなくなるため、オーバーヘッド削減を図ることが可能となる。
次に、固定拡張フォーマットのBSR MAC CE及び可変拡張フォーマットのBSR MAC CEの具体例について説明する。
図13(A)及び図13(B)は、第1実施形態に係る固定拡張フォーマットのBSR MAC CEの構成例を表す図である。図13(A)及び図13(B)は、ともに、LCGの上限値が16個(4ビット)の場合例を表す図である。このうち、図13(A)は、LCGの上限値が16個(4ビット)の場合のショートBSR MAC CEの例を表している。また、図13(B)は、LCGの上限値が16個(4ビット)の場合のロングBSR MAC CEの例を表している。
図13(A)に示すように、LCGの上限値が16個(4ビット)の場合、ショートBSR MAC CEでは、「LCG ID」領域が上限値に合わせて4ビット存在する。図10(A)のショートBSR MAC CEと比較して、1ビット多い。「LCG ID」領域には、既存のショートBSR MAC CE(図10(A))と同じ、バッファサイズが報告される論理チャネルグループの識別情報が格納される。
なお、「BS」領域は、5ビット存在する。「BS」領域も、既存のBSR MAC CEと同じ、LCG内の全LCHに亘って、所定の計算手順に従って、利用可能な総データ量が格納される。「BS」領域以降は、「R」(リザーブ領域)である。
図13(B)に示すように、ロングBSR MAC CEには、「LCGi」領域が、上限値に合わせて16個(LCG0~LCG15)存在する。「LCGi」領域も、既存のロングBSR MAC CEと同じ、LCGiのバッファサイズが存在することを示す値が格納される。図13(B)に示す「BS」領域も、既存のロングBSR MAC CEと同じ所定のバッファサイズが格納される。
図14(A)及び図14(B)は、第2実施形態に係る固定拡張フォーマットのBSR MAC CEの例を表す図である。図14(A)及び図14(B)は、ともに、LCGの上限値が256個(8ビット)の場合の例を表している。このうち、図14(A)は、LCGの上限値が256個(8ビット)の場合のショートBSR MAC CEの例を表している。また、図14(B)は、LCGの上限値が256個(8ビット)の場合のロングBSR MAC CEの例を表している。
図14(A)に示すように、LCGの上限値が256個(8ビット)の場合、「LCG ID」領域が上限値に合わせて、8ビット存在する。なお、「BS」領域は、5ビット存在し、それ以降は「R」である。
図14(B)に示すように、LCGの上限値が256個(8ビット)の場合、「LCGi」領域が256個(LCG0~LCG255)存在する。
このように、IABノード300-Tは、LCGの上限値が、16個(4ビット)として設定された場合は、図13(A)又は図13(B)のBSR MAC CEを使用することを決定し、LCGの上限値が、256個(8ビット)の場合は、図14(A)又は図14(B)に示すBSR MAC CEを使用することを決定する。
上限値は一例であって、32個(5ビット)が上限値として設定された場合、IABノード300-Tは、「LCG ID」領域が5ビットのショートBSR MAC CE、又は「LCGi」領域が32個存在するロングBSR MAC CEを使用することを決定すればよい。また、64個(6ビット)が上限値として設定された場合、IABノード300-Tは、「LCG ID」が6ビットのショートBSR MAC CE、又は「LCGi」領域が64個存在するロングBSR MAC CEを使用することを決定すればよい。
IABノード300-Tは、上限値に対応する「LCG ID」領域を有するショートBSR MAC CE、又は上限値に対応する「LCGi」領域を有するロングBSR MAC CEを使用することを決定すればよい。
なお、IABノード300-Tは、ある特定のLCGのバッファサイズを報告する場合は、ショートBSR MAC CEを使用することを決定し、複数のLCGのバッファサイズを報告する場合は、ロングBSR MAC CEを使用することを決定すればよい。
図15(A)及び図15(B)は、第2実施形態に係る可変拡張フォーマットの例を表す図である。このうち、図15(A)は、ショートBSR MAC CE用のショート可変拡張フォーマットの例を表し、図15(B)は、ロングBSR MAC CE用のロング可変拡張フォーマットの例を表す。
図15(A)に示すように、ショート可変拡張フォーマットには、更に、「LCG range」領域が含まれる。
「LCG range」領域は、IABノード300-Tに設定されたLCGの上限値に対応するビットが格納される。例えば、LCGの上限値が「16個(4ビット)」の場合は、「00」、LCGの上限値が「256個(8ビット)」の場合は、「01」、LCGの上限値が「16,384(14ビット)」の場合は、「10」、LCGの上限値が「65、536(16ビット)」の場合は、「11」が格納される。
LCGの上限値と「LCG range」領域に格納されるビットとの関係は、これ以外でもよい。また、「LCG range」領域に格納されるビット数も、LCGの上限値に合わせて、3ビット以上あってもよい。
図15(A)に示すように、ショート可変拡張フォーマットには、「LCG ID」領域が存在するが、そのビット長は、LCGの上限値に合わせて可変となっている。すなわち、図15(A)の(X)領域に存在する「LCG ID」領域は、上限値に合わせて、図面上、(X)領域において上から順に左詰めで詰めることが可能である。(X)領域以外の「LCD ID」領域(4ビット)と合わせて、「LCD ID」領域となる。
例えば、LCGの上限値が256個(8ビット)の場合は、図面上、(X)領域の最も上にある2つの領域と、上から2番目の領域のうち、左から2つの領域とが、「LCG ID」領域に含まれることになる。「BS」領域も「LCD ID」領域に続いて、左詰めとなり、余った領域が「R」となる。また、例えば、LCGの上限値が32個(5ビット)の場合は、図面上、(X)領域のうち最も上にある領域のうち、左側の領域が「LCG ID」領域に含まれることになる。
なお、図15(A)の例では、「BS」領域は、5ビット存在する。「BS」領域は5ビットより多くてもよい。
図15(B)に示すように、ロング可変拡張フォーマットにも、更に、「LCG range」領域が含まれる。「LCG range」領域は、ショート可変拡張フォーマットの「LCG range」領域と同じ、LCGの上限値が格納される。
また、「LCGi」領域は、LCGの上限値に応じて、「LCGi」領域の個数が設定される。例えば、LCGの上限値が16個(4ビット)の場合は、LCG0~LCG15(m=15)までの16個の「LCGi」領域が設定され、256個(8ビット)の場合は、LCG0~LCG255(m=255)までの256個の「LCGi」領域が設定される。
IABノード300-Tは、固定拡張フォーマット(図13(A)~図14(B))とするか、可変拡張フォーマット(図15(A)及び図15(B))とするかは、任意でよい。
図16は、第2実施形態に係る動作例を表す図である。図12(A)に示すセルラ通信システム1の構成例を適宜用いて、図16に示す動作例を説明する。
図16に示すように、ステップS30において、IABノード300-Tは処理を開始する。
ステップS31において、上位ノード(親ノード300-P又はドナーノード200)は、IABノード300-Tへ、LCGの上限値を設定する。上限値としては、例えば、8個(3ビット)、16個(4ビット)、32個(5ビット)、...、256個(8ビット)、...、16,384個(16ビット)、...、65,536個(16ビット)のいずれかである。
なお、上位ノードが、親ノード300-Pの場合は、親ノード300-PのIAB-DUは、IABノード300-TのIAB-MTに対して、MAC CE、又はBAP Control PDUなどを用いて、LCGの上限値を設定すればよい。また、上位ノードが、ドナーノード200の場合は、ドナーノード200のCUは、IABノード300-TのIAB-DU(又はIAB-MT)に対して、F1APメッセージ、又はRRCメッセージなどを用いて、LCGの上限値を設定すればよい。
なお、上位ノードが、ドナーノード200の場合、ドナーノード200は、LCGの上限値を、親ノード300-Pへ送信してもよい。又は、ドナーノード200からLCGの上限値の設定を受けたIABノード300-TのIAB-MTが、親ノード300-PのIAB-DUへ、当該上限値を送信してもよい。
ステップS32において、IABノード300-TのIAB-MTは、設定された上限値に応じて、使用するMAC CEフォーマットを決定(又は選択)する。例えば、IABノード300-TのIAB-MTは、上限値が8個の場合、既存のフォーマット(例えば、図10(A)又は図10(B))を選択する。また、例えば、IABノード300-TのIAB-MTは、上限値が16個以上の場合は、固定拡張フォーマット(例えば、図13(A)から図14(B))又は可変拡張フォーマット(例えば、図15(A)又は図15(B))を選択する。
ステップS33において、IABノード300-TのIAB-MTは、決定したフォーマットを用いて、レガシーBSR及び/又はプリエンプティブBSRを、親ノード300-Pへ送信する。
そして、ステップS34において、IABノード300-Tは、一連の処理を終了する。
(第2実施形態の変形例)
次に、第2実施形態の変形例を説明する。第2実施形態の変形例は、LCGの上限値設定が、レガシーBSRとプリエンプティブBSRで異なる値に設定される例である。具体的には、上位ノード(例えば、親ノード300-P又はドナーノード200)が、第1の中継ノード(例えば、IABノード300-T)へ、レガシーBSRとプリエンプティブBSRとで異なる上限値を設定する。
次に、第2実施形態の変形例を説明する。第2実施形態の変形例は、LCGの上限値設定が、レガシーBSRとプリエンプティブBSRで異なる値に設定される例である。具体的には、上位ノード(例えば、親ノード300-P又はドナーノード200)が、第1の中継ノード(例えば、IABノード300-T)へ、レガシーBSRとプリエンプティブBSRとで異なる上限値を設定する。
これにより、例えば、IABノード300-Tは、レガシーBSRとプリエンプティブBSRとで、異なる上限値に応じたバッファサイズを報告できる。具体的には、例えば、LCGの上限値を大きくしてスケジューリング解像度を増加させ、プリエンプティブBSRの上限値は小さくてもよい、などの要求に応えることが可能となる。
図17は、第2実施形態の変形例に係る動作例を表す図である。図12(A)に示すセルラ通信システム1の構成例を適宜用いて、図17に示す動作例を説明する。
図17に示すように、ステップS40において、上位ノード(親ノード300-P又はドナーノード200)は処理を開始する。
ステップS41において、上位ノードは、IABノード300-T(のIAB-MT又はIAB-DU)へ、レガシーBSRとプリエンプティブBSRとで、LCGの上限値を異なる値に設定する。これにより、例えば、LCGの上限値とBSRのタイプとが紐づけられて設定される。設定は、第2実施形態と同様に、上位ノードがドナーノード200の場合は、F1APメッセージなどを用いて設定すればよい。上位ノードが親ノード300-Pの場合は、BAP Control PDUなどを用いて設定すればよい。
ステップS42において、IABノード300-TのIAB-MTは、BSRのタイプによって、使用するMAC CEフォーマットを決定(又は変更)する。例えば、IABノード300-TのIAB-MTは、レガシーBSRに対するLCGの上限値が16個(4ビット)の場合は、図13(A)又は図13(B)のBSR MAC CEフォーマットを選択し、プリエンプティブBSRに対するLCGの上限値が256個(8ビット)の場合、図14(A)又は14(B)のBSR MAC CEフォーマットを選択する。
ステップS43において、IABノード300-TのIAB-MTは、決定したMAC CEフォーマットを用いて、レガシーBSR及びプリエンプティブBSRを送信する。
そして、ステップS44において、IABノード300-Tは、一連の処理を終了する。
(第3実施形態)
次に、第3実施形態の例を説明する。第3実施形態は、レガシーBSRとプリエンプティブBSRとを1つのBSR MAC CEで送信する例である。
次に、第3実施形態の例を説明する。第3実施形態は、レガシーBSRとプリエンプティブBSRとを1つのBSR MAC CEで送信する例である。
具体的には、第1に、第1の中継ノード(例えば、IABノード300-T)の上位ノード(例えば、親ノード300-P又はドナーノード200)が、第1の中継ノードへ、統合バッファステータスレポートの設定を行う。第2に、第1の中継ノードが、設定に従って、バッファステータスレポートの種別毎に分類された論理チャネルグループに対応するバッファサイズが格納された統合バッファステータスレポートを、第1の中継ノードの親ノードである第2の中継ノード(例えば、親ノード300-P)へ送信する。
1つにまとめられたBSR MAC CEを、統合BSRと称する場合がある。統合BSRは、例えば、レガシーBSR(又はプリエンプティブBSR)と同様に、LCGと、各LCGのバッファサイズ(BS)とが格納される。統合BSRは、ある1つのLCGについてバッファサイズを報告する場合は、ショートBSR MAC CEと同じフォーマットのMAC CEが用いられてもよい。また、統合BSRは、複数のLCGについての各バッファサイズを報告する場合は、ロングBSR MAC CEと同じフォーマットのMAC CEが用いられてもよい。
これにより、IABノード300-Tは、異なるMAC CEフォーマットのBSRを送信することがなくなり、例えば、処理遅延を防ぐことが可能となる。
図18は、第3実施形態に係る動作例を表す図である。図12(A)に示すセルラ通信システム1の構成例を適宜用いて、図18に示す動作例を説明する。
図18に示すように、ステップS50において、上位ノード(親ノード300-P又はドナーノード200)は、処理を開始する。
ステップS51において、上位ノードは、IABノード300-TのIAB-MTへ、統合BSRを設定する。この場合、上位ノードは、統合BSRにおけるLCGと、BSRタイプとの紐づけ設定を行ってもよい。例えば、統合BSRのLCG#0~LCG#3は、レガシーBSRのLCG#0~LCG#3にそれぞれ対応し、統合BSRのLCG#4~LCG#7は、プリエンプティブBSRのLCG#0~LCG#3にそれぞれ対応する、ことを表す設定などである。
このような統合BSRの設定は、上位ノードが親ノード300-Pの場合は、BAP Control PDU又はMAC CEなどを用いて設定されてもよい。また、上位ノードがドナーノード200の場合は、F1APメッセージ又はRRCメッセージなどを用いて設定されてもよい。また、ドナーノード200は、親ノード300-Pに対して、当該設定を行ってもよい。
ステップS52において、IABノード300-TのIAB-MTは、統合BSRをトリガする。トリガは、レガシーBSRのトリガコンディションであってもよい。また、トリガは、プリエンプティブBSRのトリガコンディションであってもよい。例えば、IABノード300-TのIAB-MTは、レガシーBSRのトリガタイミングで、統合BSRをトリガしてもよい。また、IABノード300-TのIAB-MTは、プリエンプティブBSRのトリガタイミングで統合BSRをトリガしてもよい。上位ノードは、IABノード300-TのIAB-MTに、前記2つのトリガ条件のうちどちらで統合BSRをトリガすべきかを設定してもよい。
ステップS53において、IABノード300-TのIAB-MTは、レガシーBSRのバッファサイズ(BS-L)と、プリエンプティブBSRのバッファサイズ(BS-P)とを特定する。そして、IABノード300-TのIAB-MTは、これらのバッファサイズを、LCGに対応させて統合BSRのMAC CEに格納する。
例えば、IABノード300-Tは、BS-L#0~BS-L#3をLCG#0~LCG#3にそれぞれに対応させる。また、例えば、IABノード300-Tは、BS-P#0~BS-P#3を、LCG#4~LCG#7にそれぞれ対応させる。そして、IABノード300-Tは、例えば、統合BSRのLCG#0~LCG#3のバッファサイズとして、BS-L#0~BS-L#3を統合BSRのMAC CEにそれぞれ格納する。また、IABノード300-Tは、例えば、統合BSRのLCG#4~LCG#7のバッファサイズとして、BS-P#0~BS-P#3を統合BSRのMAC CEに格納する。
ステップS54において、IABノード300-TのIAB-MTは、統合BSRを、親ノード300-Pへ送信する。
そして、ステップS55において、IABノード300-Tは、一連の処理を終了する。
(第4実施形態)
次に、第4実施形態について説明する。
次に、第4実施形態について説明する。
(BH RLF Indication)
複数のIABノード300から構成されたネットワークにおいて、IABノード300間のバックホールリンクで障害が発生する場合がある。このような障害を「BH RLF(Backhaul Radio Link Failure)」と呼ぶ。
複数のIABノード300から構成されたネットワークにおいて、IABノード300間のバックホールリンクで障害が発生する場合がある。このような障害を「BH RLF(Backhaul Radio Link Failure)」と呼ぶ。
図19は、第4実施形態に係るノード間の関係例を表す図である。また、図19は、第4実施形態に係るBH RLFの例も表している。図19では、IABノード300-Tの親ノードであるIABノード300-P1と、更にその親ノードであるノード500との間のBHリンク#1で、BH RLFが発生した場合の例を表している。
親ノード300-P1のIAB-MTが、BH RLFを検知したと仮定する。親ノード300-P1のIAB-DUは、ダウンストリーム側のIABノード300-Tに対して、障害発生通知を送信する。
BH RLFを検知したことを示す障害発生通知を、Type1 BH RLF Indicationと呼ぶ。子ノード(図19の例では親ノード300-P1である)によって検出されたBHリンクRLFが、Type1 BH RLF Indicationであってもよい。
また、バックホールリンクで発生した障害(BH RLF)からの回復を試行中であることを示す回復試行通知を、Type2 BH RLF Indicationと呼ぶ。図19の例では、親ノード300-P1がIABノード300-Tに対して、Type2 BH RLF Indicationを送信する例が示されている。
Type1 BH RLF IndicationとType2 BH RLF Indicationとを区別しないときは、Type1/2 BH RLF Indicationと呼ぶ。なお、各実施形態では、主に、Type2 BH RLF Indicationの例を説明するが、Type2 BH RLF Indicationを、Type1 BH RLF Indicationと読み替えてもよい。上述したように、Type1 BH RLF IndicationはBH RLF検出時、Type2 BH RLF Indicationは回復試行時に、それぞれ送信されるが、IABノード300においては、BH RLF検出後、直ちに、BH RLFの回復試行処理が行われるため、Type1 BH RLF IndicationとType2 BH RLF Indicationとは、実質的に同じ通知となるためである。
更に、BHリンクがBH RLFからリカバリしたことを示す回復通知もある。このような回復通知を、Type3 BH RLF Indicationと呼ぶ。更に、BHリンクがRLFからのリカバリに失敗したことを示す失敗通知もある。このような失敗通知を、Type4 BH RLF Indicationと呼ぶ。
図19において、Type2 BH RLF Indicationを受信したIABノード300-Tは、様々な制御を行うことができる。詳細は後述する。
なお、以下では、Type2 BH RLF Indicationを、Type2 Indicationと称する場合がある。
(ローカルリルーティング(local rerouting))
上述したように、複数のIABノード300から構成されたネットワークにおいて、IABノード300間のバックホールリンクでBH RLFが発生する場合がある。
上述したように、複数のIABノード300から構成されたネットワークにおいて、IABノード300間のバックホールリンクでBH RLFが発生する場合がある。
複数のIABノード300によってパケットを次々と転送させるマルチホップネットワークでは、データパケットを、代替パス(alternative path)を介して宛先IABノード300(又はドナーノード200)へ転送させることができる。回線障害が発生した場合において、代替パスを利用してデータパケットを転送することを、ローカルリルーティングと称する場合がある。ローカルリルーティングは、ドナーノード200によって設定されたルーティング設定を無視して、代替パスを選択することで行われる。もしくは、ローカルリルーティングは、ドナーノード200によって設定された代替パス候補の中から代替パスを選択することで行われてもよい。
(条件付きハンドオーバ)
一般的なハンドオーバにおいては、UE100がサービングセル及び/又は隣接セルの無線状態の測定値をgNB200に報告し、この報告に基づいてgNB200が隣接セルへのハンドオーバを決定し、ハンドオーバ指示をUE100に送信する。このため、サービングセルの無線状態が急激に劣化したような場合、一般的なハンドオーバは、ハンドオーバが実行される前に通信が途絶する場合がある。
一般的なハンドオーバにおいては、UE100がサービングセル及び/又は隣接セルの無線状態の測定値をgNB200に報告し、この報告に基づいてgNB200が隣接セルへのハンドオーバを決定し、ハンドオーバ指示をUE100に送信する。このため、サービングセルの無線状態が急激に劣化したような場合、一般的なハンドオーバは、ハンドオーバが実行される前に通信が途絶する場合がある。
これに対し、条件付きハンドオーバは、予め設定されたトリガ条件が満たされると、当該トリガ条件に対応する候補セルへのハンドオーバを自律的に実行することが可能である。このため、一般的なハンドオーバにおける通信途絶などの問題を解決できる。
条件付きハンドオーバの実行条件には、1つ以上のトリガ条件を含む。条件付きハンドオーバの設定は、候補セル及びトリガ条件を含む。条件付きハンドオーバの設定は、候補セル及びトリガ条件の複数の組み合わせを複数含んでもよい。条件付きハンドオーバの設定は、例えば、ドナーノード200のCUからIABノード300(のIAB-MT)及び/又はUE100へのRRCメッセージなどにより行われる。
(第4実施形態の制御例)
例えば、図19に示すように、IABノード300-TにDual Connectivityが設定され、IABノード300-Tは、2つの親ノード300-P1及び300-P2と接続可能である場合を考える。
例えば、図19に示すように、IABノード300-TにDual Connectivityが設定され、IABノード300-Tは、2つの親ノード300-P1及び300-P2と接続可能である場合を考える。
このような場合、IABノード300-Tは、親ノード300-P1からType2 Indicationを受信すると、ローカルリルーティングを行って、接続先を親ノード300-P2へ切り替えることが可能である。これにより、IABノード300-Tは、upstream方向へのパケットを、障害が発生したBHリンク#1を回避して、目的ノード(ドナーノード200)へ送信することができ、継続したサービスをUE100へ提供できる。
しかし、IABノード300-TにDual Connectivityが設定されておらず、親ノード300-P1のみ接続されたシングル接続の場合を考える。このような場合、IABノード300-Tは、親ノード300-P1からType2 Indicationを受信しても、親ノード300-P1に対する接続の切り替えを行うことができず、Type3 BH RLF Indication又はType4 BH RLF Indicationを待つまで何もできない状態となる。
そこで、IABノード300-Tは、親ノード300-P1からType2 Indicationを受信すると、条件付きハンドオーバを実行できるようにする。具体的には、IABノード300-Tは、条件付きハンドオーバによって、親ノード300-P1から親ノード300-P2へ、接続を切り替える。これにより、IABノード300-Tは、upstream方向へのパケットを、BHリンク#1を回避して、目的ノードへ送信することができ、継続したサービスをUE100へ提供できる。
このように、IABノード300-Tは、Type2 Indicationの受信をトリガにして、ローカルリルーティングと条件付きハンドオーバの双方を実行可能な場合、Type2 Indicationを受信した場合に、どちらを実行するかを選択することが可能である。
この場合、このような選択をIABノード300-Tの実装依存により、自ら選択できるようにすることも考えられる。
しかし、ドナーノード200は、トポロジ全体を管理するノードである。また、ドナーノード200は、トポロジ全体のパフォーマンスを制御する能力を持っている。
そこで、第4実施形態では、ドナーノード200が、IABノード300-Tに対して、Type2 Indicationの受信をトリガにして、ローカルリルーティングを実行するのか、条件付きハンドオーバを実行するのかを、設定できるようにする。
具体的には、第1に、第1及び第2の中継ノードを配下に有するドナー基地局(例えば、ドナーノード200)が、第1の中継ノード(例えば、IABノード300-T)へ、ローカルリルーティング及び条件付きハンドオーバ(CHO)の設定を行う。第2に、第1の中継ノードが、第1の中継ノードの親ノードである第2の中継ノード(例えば、親ノード300-P1)から、当該第2の中継ノードと当該第2の中継ノードの親ノード(例えば、ノード500)との間のバックホールリンク(例えば、BHリンク#1)で発生した障害に対して当該障害からの回復を試行中であることを示す障害回復通知を受信する。第3に、第1の中継ノードが、設定に従い、障害回復通知の受信に応じて、ローカルリルーティング又は前記条件付きハンドオーバを実行する。このような場合、更に、ドナー基地局が、障害回復通知の受信に応じて、ローカルリルーティングを実行するのか、又は条件付きハンドオーバを実行するのか、を第1の中継ノードへ設定する。
このように、ドナーノード200が、ローカルリルーティングを実行するのか、条件付きハンドオーバを実行するのかを、IABノード300-Tに対して設定するようにしているため、トポロジ全体の公平性を考慮した制御を実現することが可能となる。
(第4実施形態の動作例)
図20は、第4実施形態に係る動作例を表す図である。図19に示す構成例を適宜用いて、動作例を説明する。
図20は、第4実施形態に係る動作例を表す図である。図19に示す構成例を適宜用いて、動作例を説明する。
図20に示すように、ステップS60において、ドナーノード200は、処理を開始する。
ステップS61において、ドナーノード200のCUは、IABノード300-TのIAB-MTへ、ローカルリルーティング及び/又は条件付きハンドオーバの設定を行う。例えば、ドナーノード200のCUは、RRCメッセージを利用して、ローカルリルーティング及び又は条件付きハンドオーバの設定を行ってもよい。
ステップS62において、ドナーノード200のCUは、IABノード300-TのIAB-MTへ、Type2 Indicationを受信した際の動作を設定する。動作設定は、Type2 Indicationを受信した場合に、ローカルリルーティングを実行するのか、条件付きハンドオーバを実行するのか、どちらを実行するのか(又は優先するのか)に関する設定である。
ここで、「ローカルリルーティングを実行する」ことが設定された場合、IABノード300-Tは、接続切り替えに関する設定処理を行うことなく、パケットを親ノード300-P2へ転送できる。そのため、短期的な視点では、通信断が発生することなく、サービスを継続できる、というメリットがある。
一方、「条件付きハンドオーバを実行する」ことが設定された場合、IABノード300-Tは、接続切り替えに関する設定処理を行うことになるが、Dual Connectivityの再構築も可能である。そのため、長期的な視点では、ネットワークの負荷分散、通信品質(スループット又はレイテンシ)を維持できる、というメリットがある。
なお、動作設定は、例えば、ドナーノード200のCUが、IABノード300-TのIAB-MTへ、RRCメッセージを利用して設定してもよい。
ステップS63において、IABノード300-TのIAB-MTは、親ノード300-P1のIAB-DUから、Type2 Indicationを受信する。
ステップS64において、IABノード300-TのIAB-MTは、設定に従い、ローカルリルーティング又は条件付きハンドオーバを実行する。
ステップS65において、IABノード300-Tは、一連の処理を終了する。
(第4実施形態の変形例)
次に、第4実施形態の変形例を説明する。第4実施形態の変形例は、予めルールが決まっており、IABノード300-Tは、そのルールに従って、Type2 Indicationの受信をトリガにして、ローカルリルーティング又は条件付きハンドオーバを実行する例である。
次に、第4実施形態の変形例を説明する。第4実施形態の変形例は、予めルールが決まっており、IABノード300-Tは、そのルールに従って、Type2 Indicationの受信をトリガにして、ローカルリルーティング又は条件付きハンドオーバを実行する例である。
具体的には、第1の中継ノード(例えば、IABノード300-T)が、ローカルリルーティング又は条件付きハンドオーバを実行する際に、第1の中継ノードが、予め設定されたルールに従って、ローカルリルーティング又は条件付きハンドオーバを実行する。
ここで、「予め設定」とは、例えば、IABノード300-Tが設置される際に、メモリに設定(記憶)されていることを表している。IABノード300-TのIAB-MTは、当該設定に関する情報等をメモリから読み出して実行することで、Type2 Indicationの受信をトリガにして、ローカルリルーティング又は条件付きハンドオーバを実行する。もしくは、仕様にてハードコーディングで決まっていてもよい。
図21は、第4実施形態の変形例に係る動作例を表す図である。ステップS71,S72は、第4実施形態のステップS61,S63とそれぞれ同一である。
ステップS72において、IABノード300-Tは、予め決められた所定のルールに従って、ローカルリルーティング又は条件付きハンドオーバを実行する。所定のルールとして、例えば、以下がある。すなわち、IABノード300-Tは、Dual Connectivity接続を行っている場合であって、ローカルリルーティングを行うためのパス(代替パス)が存在する場合、ローカルリルーティングを行う。また、IABノード300-Tは、Dual Connectivity接続を行っていない場合又はローカルリルーティングを行うためのパス(代替パス)が存在しない場合、条件付きハンドオーバを実行する。
そして、ステップS74において、IABノード300-Tは、一連の処理を終了する。
(その他の実施形態)
UE100、gNB200、又はIABノード300が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、CD-ROM又はDVD-ROM等の記録媒体であってもよい。
UE100、gNB200、又はIABノード300が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、CD-ROM又はDVD-ROM等の記録媒体であってもよい。
また、UE100、gNB200、又はIABノード300が行う各処理を実行する回路を集積化し、UE100、gNB200、又はIABノード300の少なくとも一部を半導体集積回路(チップセット、SoC(System on a chip))として構成してもよい。
本開示で使用されている「に基づいて(based on)」、「に応じて(depending on)」という記載は、別段に明記されていない限り、「のみに基づいて」、「のみに応じて」を意味しない。「に基づいて」という記載は、「のみに基づいて」及び「に少なくとも部分的に基づいて」の両方を意味する。同様に、「に応じて」という記載は、「のみに応じて」及び「に少なくとも部分的に応じて」の両方を意味する。また、「取得する(obtain/acquire)」は、記憶されている情報の中から情報を取得することを意味してもよく、他のノードから受信した情報の中から情報を取得することを意味してもよく、又は、情報を生成することにより当該情報を取得することを意味してもよい。「含む(include)」、「備える(comprise)」、及びそれらの変形の用語は、列挙する項目のみを含むことを意味せず、列挙する項目のみを含んでもよいし、列挙する項目に加えてさらなる項目を含んでもよいことを意味する。また、本開示において使用されている用語「又は(or)」は、排他的論理和ではないことが意図される。さらに、本開示で使用されている「第1」、「第2」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定するものではない。これらの呼称は、2つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第1及び第2の要素への参照は、2つの要素のみがそこで採用され得ること、又は何らかの形で第1の要素が第2の要素に先行しなければならないことを意味しない。本開示において、例えば、英語でのa,an,及びtheのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。
以上、図面を参照して一実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。また、矛盾しない範囲で、各実施形態の全部又は一部を組み合わせることも可能である。
本願は、米国仮出願第63/185648号(2021年5月7日出願)の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
(付記1)
(導入) NRの統合アクセスとバックホールの拡張(eIAB)に関する改訂されたワークアイテムは、RAN#88eで承認された。主な目的のいくつかを以下に示す。
トポロジ適応の強化:
・シグナリング負荷を軽減するための機能強化を含む、堅牢性と負荷分散を強化するためのドナー間IABノード移行の手順の仕様。
・IABノードの移行とBH RLFの回復によるサービスの中断を減らすための拡張機能の仕様。
・CP/UP分離のサポートを含む、トポロジの冗長性の強化の仕様。
トポロジ、ルーティング、及びトランスポートの機能強化:
・トポロジ全体の公平性、マルチホップ遅延、及び輻輳緩和を改善するための拡張機能の仕様。
(導入) NRの統合アクセスとバックホールの拡張(eIAB)に関する改訂されたワークアイテムは、RAN#88eで承認された。主な目的のいくつかを以下に示す。
トポロジ適応の強化:
・シグナリング負荷を軽減するための機能強化を含む、堅牢性と負荷分散を強化するためのドナー間IABノード移行の手順の仕様。
・IABノードの移行とBH RLFの回復によるサービスの中断を減らすための拡張機能の仕様。
・CP/UP分離のサポートを含む、トポロジの冗長性の強化の仕様。
トポロジ、ルーティング、及びトランスポートの機能強化:
・トポロジ全体の公平性、マルチホップ遅延、及び輻輳緩和を改善するための拡張機能の仕様。
トポロジ、ルーティング、及びトランスポートの機能強化に関して、RAN2#113-eでは、Rel-17で議論する問題、つまり、公平性を表す「IF」、遅延を表す「IL」、又は輻輳を表す「IC」でマークされた問題を指摘した。RAN2#113bis-eでは、考えられる解決策が議論され、1つの合意に達しただけである。IAB-MT用に拡張されるLCG範囲。LCGのサイズ及びBSRの拡張は更なる議論が必要である。
付記1では、IF-4、IL-2、IL-3、IL-5、IL-6、IC-1、及びIC-7に焦点を当てて、これらの問題の可能な解決策について議論する。
(議論)
―トポロジ全体の公平性―
IF-4
IF-4は次のように指定された:
・IF-4:IABノードは、より多くのベアラを集約する、及び/又はベアラ当たりの負荷が高いベアラを運ぶBH RLCチャネルに、より多くのリソースを提供できない(つまり、IABノードは、集約負荷がより高いBH RLCチャネルに、より多くのリソースを提供できない)。
(議論)
―トポロジ全体の公平性―
IF-4
IF-4は次のように指定された:
・IF-4:IABノードは、より多くのベアラを集約する、及び/又はベアラ当たりの負荷が高いベアラを運ぶBH RLCチャネルに、より多くのリソースを提供できない(つまり、IABノードは、集約負荷がより高いBH RLCチャネルに、より多くのリソースを提供できない)。
リストによると、IF-4の可能な解決策は次の通りである。
・F1:IABノードは、CUによって追加情報で設定される。
・F1-1:特定のBH RLCチャネル内のベアラの数に関連する(実際の数、平均数など)。
・F1-2:特定のBH RLCチャネルのベアラのQoSに関連する。
・F2:追加情報がBAPヘッダに追加される。
・F2-1:ベアラID。
・F2-2:特定のパスのベアラIDとホップカウント。
・F2-3:特定のBAPパケット内のUE DRBの数。
・F1:IABノードは、CUによって追加情報で設定される。
・F1-1:特定のBH RLCチャネル内のベアラの数に関連する(実際の数、平均数など)。
・F1-2:特定のBH RLCチャネルのベアラのQoSに関連する。
・F2:追加情報がBAPヘッダに追加される。
・F2-1:ベアラID。
・F2-2:特定のパスのベアラIDとホップカウント。
・F2-3:特定のBAPパケット内のUE DRBの数。
F1ソリューションに関しては、これらはルーティング設定とともに提供されるなど、一度だけ設定される。従って、これらは、より少ないオーバーヘッドを必要とする単純なソリューションであり、より優れた「RLCチャネルごとの」スケジューリングを可能にする。ただし、これらのソリューションは、DLスケジューリングの「パケットごとの」優先順位付けには使用できない。
F2ソリューションに関しては、これらは各BAPヘッダに追加されるため、「パケットごと」のスケジューリングを実行できる。ただし、これらのソリューションでは、F1ソリューションと比較して各BAP PDUでより多くのオーバーヘッドが必要であることは明らかである。
公平性の向上という点では、技術的な観点から、「パケットごと」のスケジューリングは「RLCチャネルごと」のスケジューリングよりも優れている。これらのスケジューリングは、gNB(又はIAB-DU)のDLスケジューラで実行できる。一方、ULの場合、LCPは基本的に「RLCチャネルごと」のスケジューリングを提供する。この意味で、DL及びULのすべてのBAP PDUのオーバーヘッドが増えることを考慮すると、DLに対してのみ「パケットごと」のスケジューリングを行う必要はない場合がある。従って、Rel-17のトポロジ全体の公平性を向上させるには、単純なソリューション、つまりF1ソリューションの方が適している。
提案1:RAN2は、IABドナーが各BH RLCチャネルにマップされたベアラの数及びこれらのベアラのQoSを使用してIABノードを設定することに同意する必要がある。つまり、F1-1及びF1-2を使用してIF-4を解決する。
―マルチホップ遅延―
IL-2
IL-2は次のように指定された:
・IL-2:LCGの数に対する現在の(Rel-16)制限のため、IABノードはQoS要件がかなり異なるLCHのジョイントバッファーステータスを報告する必要がある場合がある。
IL-2
IL-2は次のように指定された:
・IL-2:LCGの数に対する現在の(Rel-16)制限のため、IABノードはQoS要件がかなり異なるLCHのジョイントバッファーステータスを報告する必要がある場合がある。
IL-2の可能な解決策は次の通りである。
・L4:IABノードに新しい動作又は機能が指定されている。
・L4-3:IAB-MTのLCGの数が増加している。
・L4:IABノードに新しい動作又は機能が指定されている。
・L4-3:IAB-MTのLCGの数が増加している。
RAN2#113bis-eで、RAN2は「IAB-MTのLCG範囲を拡張することに同意した。LCGのサイズ及びBSRの拡張は更なる検討が必要である。」現在の仕様によると、現在のLCGスペースは8(つまり、maxLCG-IDは7)であり、これはUEとIAB-MTに共通である。UEの場合、現在のLCH IDスペースは32(つまり、maxLC-ID)である。IAB-MTの場合、BH LCH IDの最大数(つまり、maxLC-ID-Iab-r16)は65,855であるが、BH LCH IDスペース(つまり、BH-RLCチャネル ID-r16)は65,536(16ビット)である。UEに同じ比率が適用される場合(つまり、LCG:LCH=1:4)、IAB-MTには16,384 LCG(14ビット)が必要になる場合がある。これは確かに実現可能ですが、MAC CEに追加するには少し大きくなる可能性がある。一部の企業は、LCGスペースを少なくとも16(4ビット)、又は256(8ビット)まで拡張することを提案した。従って、RAN2は、拡張LCGスペースに最適なものを検討する必要がある。
提案2:RAN2は、拡張LCGスペースに最適な最大数である16(4ビット)、256(8ビット)、16,384(14ビット)、更に65,536(16ビット)について議論する必要がある。
IL-3
IL-3は次のように指定された:
・IL-3:プリエンプティブBSRのバッファサイズの計算は、Rel-16での実装に任されているため、ベンダーごとに異なる場合がある。
IL-3は次のように指定された:
・IL-3:プリエンプティブBSRのバッファサイズの計算は、Rel-16での実装に任されているため、ベンダーごとに異なる場合がある。
IL-3の可能な解決策は次の通りである。
・L4:IABノードに新しい動作又は機能が指定されている。
・L4-1:プリエンプティブBSRのバッファサイズ計算が指定されている。
・L4:IABノードに新しい動作又は機能が指定されている。
・L4-1:プリエンプティブBSRのバッファサイズ計算が指定されている。
従来のBSRの場合、バッファサイズの計算は明確に指定されている。これは、MAC、RLC、及びPDCPで利用可能なデータに基づいている。RLC及びPDCPの場合、データ量の計算手順は各仕様で指定されている。Rel-16では、これらのメカニズムは、IAB-MTのプリエンプティブBSRのデータ量計算に再利用される。
ただし、IABノードにはPDCPの代わりにBAPレイヤがあり、BAP仕様にはデータ量の計算はない。そのため、現在の仕様では送信に使用できるデータが不足している。トポロジ全体の公平性をより適切にスケジューリングするには、レガシーBSRで報告されるバッファサイズをより正確にする必要がある。
所見1:BAPで送信できるデータの手順がないため、レガシーBSR及びプリエンプティブBSRが不正確になる。
Rel-16では、プリエンプティブBSRのバッファサイズの計算は、IAB-DUの実装に大きく依存しているが、仕様では、「バッファサイズフィールドは、プリエンプティブBSRがトリガされるノードのIAB-MTに到着すると予想されるデータの合計量を指定し、IAB-MTで現在利用可能なデータの量は含まれない。」指摘されているように、一部のIABノードは、プリエンプティブBSRで、実際に到着するよりも大きなバッファサイズを報告する可能性がある。子ノードと親ノードとの間に同じ原則を設定することは難しい場合がある。例えば、マルチベンダの展開では、無線リソースの割り当てが非効率になり、親ノードでスケジューリングの遅延が生じ、IAB-MT間のリソース要求が不公平になる。IABノードがデュアルコネクティビティで設定されている場合は、よりあいまいになる可能性がある。従って、プリエンプティブBSRのバッファサイズの計算は、より正確に指定する必要がある。1つの問題は、IAB-DUに対してバッファサイズの計算が指定されていないことである。つまり、IAB-DUの受信側(MAC及びRLC)でバッファリングされたデータである。
所見2:IAB-DUのMAC及びRLC受信機にバッファリングされたデータの手順はない。そのため、Rel-16のプリエンプティブBSRで報告されるデータ量はIAB-DUの実装次第である。
提案3:RAN2は、プリエンプティブBSR(及び場合によってはレガシーBSR)のバッファサイズ計算を指定することに同意する必要がある。つまり、L4-1を使用してIL-3を解決する。
もう1つの問題は、プリエンプティブBSRがいつトリガされるかが親ノードの観点から不明確であるということである。MAC仕様では、2つの条件を次のように規定している。これは、トリガ条件がRel-16でのIAB-MT実装までであることを意味する。親ノードはデータが実際に送信できるようになる時期を正確に予測できないため、不適切なUL grantが発生する。
設定されている場合、次のイベントのいずれかが発生した場合、IAB-MTの特定のケースに対してプリエンプティブBSRがトリガされる可能性がある。
-UL grantは子IABノード又はUEに提供される。
-BSRは、子IABノード又はUEから受信される。
-UL grantは子IABノード又はUEに提供される。
-BSRは、子IABノード又はUEから受信される。
簡単な解決策の1つは、IABノードが、プリエンプティブBSRをUL grant送信又はBSR受信のどちらでトリガするかで設定されていると考えることができる。IABドナーによって設定するのは簡単ですが、プリエンプティブBSRは、実際には親ノードのIAB-DU、つまりスケジューラで使用される。従って、この時点で、トリガ条件がIABドナーによって設定されているか、親IABノードによって指示されているかは更なる検討が必要である。
提案4:RAN2は、プリエンプティブBSRに使用されるトリガがIABノードで設定されていることに同意する必要がある。IABドナー又はその親IABノードのどちらによって行われるかは更なる検討が必要である。
IL-5及びIL-6
IL-5は次のように指定されました:
・IL-5:CUは、PDBが低いベアラを、輻輳リスクが少ない(リソース効率が高い)ルート又はRLFフリーのルートに設置できない。
IL-5は次のように指定されました:
・IL-5:CUは、PDBが低いベアラを、輻輳リスクが少ない(リソース効率が高い)ルート又はRLFフリーのルートに設置できない。
IL-5の可能な解決策は次の通りである。
・L3:追加のシグナリングがIABノードからCUに導入される。
・L3-1:IABノードのバッファ/リンクステータスはCUと共有される。
・L3-2:BH RLCチャネルごとの個々のホップの遅延測定値はCUと共有される。
・L4:IABノードに新しい動作又は機能が指定されている。
・L4-2:ローカルリルーティングはRLF以外の目的で許可される(たとえば、発信リンクの遅延に基づく)。
・F4:追加のシグナリングがIABノードからCUに導入される。
・F4-1:BH RLCチャネルごとの負荷情報に関連する。
・F4-2:個々のリンクでのホップごとの遅延及びホップごとのパケット損失に関連する。
・L3:追加のシグナリングがIABノードからCUに導入される。
・L3-1:IABノードのバッファ/リンクステータスはCUと共有される。
・L3-2:BH RLCチャネルごとの個々のホップの遅延測定値はCUと共有される。
・L4:IABノードに新しい動作又は機能が指定されている。
・L4-2:ローカルリルーティングはRLF以外の目的で許可される(たとえば、発信リンクの遅延に基づく)。
・F4:追加のシグナリングがIABノードからCUに導入される。
・F4-1:BH RLCチャネルごとの負荷情報に関連する。
・F4-2:個々のリンクでのホップごとの遅延及びホップごとのパケット損失に関連する。
IL-6は次のように指定された:
・IL-6:CUは、BH RLCチャネルごとの実際の(リアルタイム)遅延に基づいてルーティングを設定できない。
・IL-6:CUは、BH RLCチャネルごとの実際の(リアルタイム)遅延に基づいてルーティングを設定できない。
IL-6の可能な解決策は次の通りである。
・L3:追加のシグナリングがIABノードからCUに導入される。
・L3-2:BH RLCチャネルごとの個々のホップの遅延測定値はCUと共有される。
・F4:追加のシグナリングがIABノードからCUに導入される。
・F4-2:個々のリンクでのホップごとの遅延及びホップごとのパケット損失に関連する。
・L4:IABノードに新しい動作又は機能が指定されている。
・L4-2:ローカルリルーティングはRLF以外の目的で許可される(たとえば、発信リンクの遅延に基づく)。
・L3:追加のシグナリングがIABノードからCUに導入される。
・L3-2:BH RLCチャネルごとの個々のホップの遅延測定値はCUと共有される。
・F4:追加のシグナリングがIABノードからCUに導入される。
・F4-2:個々のリンクでのホップごとの遅延及びホップごとのパケット損失に関連する。
・L4:IABノードに新しい動作又は機能が指定されている。
・L4-2:ローカルリルーティングはRLF以外の目的で許可される(たとえば、発信リンクの遅延に基づく)。
IL-5及びIL-6の可能な解決策は、IABノードからIABドナーへの追加のシグナル伝達、つまりL3及びL4に関して共通性を持っている可能性があり、これは、一元化された最適化を可能にするため、MDT及び/又はSON手順の一種と見なすことができる。
L3-1に関しては、現在の仕様では、IABノードがある程度のバッファ/リンクステータスをIABドナーと共有できるようになっていると見なすことができる。例えば、F1-APのRESOURCE STATUS UPDATEやRRCの測定報告フレームワーク。そのため、CUに報告する必要のある追加情報は不明である。
L3-2及びF4-2に関しては、これらのソリューションはIL-5及びIL-6の両方に一般的に使用でき、遅延測定の観点からは同じと見なすことができる。既存のL2測定では、「UEごとのDRBごとのUL PDCPパケット平均遅延」が指定されているが、PDCPパケット平均遅延をIABノードに適用できないことは明らかである。そのため、BAPレイヤには新しいL2測定が必要になると予想される。
提案5:RAN2は、IABノードがホップごとの遅延測定結果をIABドナーに報告することに同意する必要がある。つまり、L3-2を使用してIL-5及びIL-6を解決する。
L4-2に関して、RAN2は、「タイプ2 RLFインジケーションを使用してローカルリルーティングをトリガできる」及び「ローカルリルーティングは、ホップごとのフロー制御のインジケーションによってトリガできる」ことにすでに同意している。従って、このアジェンダ項目でこの問題について更に議論する必要はない。つまり、ローカルリルーティングの詳細については、トポロジ適応の強化に関する他のアジェンダ項目で議論できる。
所見3:他の目的、つまりL4-2のためのローカルリルーティングについては、トポロジ適応の強化の下で議論する。
―輻輳の緩和―
IC-1及びIC-7
IC-1及びIC-7は、次のように注釈を付けて指定された。
R2は、次の2つの問題に対処するために企業間に十分な関心があると結論付けた。
・IC-1:パケットのドロップに依存せずに、既存のRel-16 DL HbHフロー制御メカニズムを使用して、単一リンクでの長期的なダウンストリーム輻輳を軽減することはできない。
・IC-7:CU(ローカルの輻輳状態を認識していない)は、輻輳が発生しているルーティングパスを更新できない。
IC-1及びCI-7はどちらもRAN3に関連している。RAN3もこれに取り組んでいるようであるため、RAN2がこれにどの程度取り組むかは現在のところ明確ではない。
IC-1及びIC-7
IC-1及びIC-7は、次のように注釈を付けて指定された。
R2は、次の2つの問題に対処するために企業間に十分な関心があると結論付けた。
・IC-1:パケットのドロップに依存せずに、既存のRel-16 DL HbHフロー制御メカニズムを使用して、単一リンクでの長期的なダウンストリーム輻輳を軽減することはできない。
・IC-7:CU(ローカルの輻輳状態を認識していない)は、輻輳が発生しているルーティングパスを更新できない。
IC-1及びCI-7はどちらもRAN3に関連している。RAN3もこれに取り組んでいるようであるため、RAN2がこれにどの程度取り組むかは現在のところ明確ではない。
RAN3は輻輳の兆候について議論しており、次のことに同意した。
CPベースの輻輳インジケーションには、次のレポートが含まれる場合がある:
・BAPルーティングIDごと及び/又は
・子ノードごとのリンク及び/又は
・BH RLC CH ID
(ダウンセレクションは更なる検討が必要である)。
CPベースの輻輳インジケーションは、F1APGNB-DUステータスインジケーション手順を再利用する。
CPベースの輻輳インジケーションは、DL輻輳に関連している。
IAB輻輳緩和へのUPベースのアプローチについては、次の2つのオプションを検討する。
・機能強化はない。
・パケットマーキングベースのアプローチ。
CPベースの輻輳インジケーションには、次のレポートが含まれる場合がある:
・BAPルーティングIDごと及び/又は
・子ノードごとのリンク及び/又は
・BH RLC CH ID
(ダウンセレクションは更なる検討が必要である)。
CPベースの輻輳インジケーションは、F1APGNB-DUステータスインジケーション手順を再利用する。
CPベースの輻輳インジケーションは、DL輻輳に関連している。
IAB輻輳緩和へのUPベースのアプローチについては、次の2つのオプションを検討する。
・機能強化はない。
・パケットマーキングベースのアプローチ。
IABドナーがIABノードから輻輳インジケーションを受信すると、IABドナーは上記のRAN2の合意で暗示されているように輻輳が発生するパスを回避できると想定できる。この問題に対処するには、いくつかの方法がある。つまり、IABドナーは、ルーティング設定を更新するか、ローカルリルーティングを指示する。後者の場合、輻輳インジケーションの使用方法にRAN2が関与している可能性がある。いずれの場合も、RAN2はRAN3の進行を待ってから決定する必要がある。
所見4:RAN2は、RAN3が詳細を把握した後、輻輳の兆候が原因でIABドナーがどのように行動するかに関与している可能性がある。
(付記2)
(導入)
NRの統合アクセスとバックホールの拡張(eIAB)に関する改訂されたワークアイテムは、RAN#88eで承認された。いくつかの目的は次の通りである。
トポロジ適応の強化:
・シグナリング負荷を軽減するための機能強化を含む、堅牢性と負荷分散を強化するためのドナー間IABノード移行の手順の仕様。
・IABノードの移行及びBHRLFの回復によるサービスの中断を減らすための拡張機能の仕様。
・CP/UP分離のサポートを含む、トポロジの冗長性の強化の仕様。
トポロジ、ルーティング、及びトランスポートの機能強化:
・トポロジ全体の公平性、マルチホップ遅延、及び輻輳緩和を改善するための拡張機能の仕様。
(導入)
NRの統合アクセスとバックホールの拡張(eIAB)に関する改訂されたワークアイテムは、RAN#88eで承認された。いくつかの目的は次の通りである。
トポロジ適応の強化:
・シグナリング負荷を軽減するための機能強化を含む、堅牢性と負荷分散を強化するためのドナー間IABノード移行の手順の仕様。
・IABノードの移行及びBHRLFの回復によるサービスの中断を減らすための拡張機能の仕様。
・CP/UP分離のサポートを含む、トポロジの冗長性の強化の仕様。
トポロジ、ルーティング、及びトランスポートの機能強化:
・トポロジ全体の公平性、マルチホップ遅延、及び輻輳緩和を改善するための拡張機能の仕様。
付記2では、現在の合意に加えて、Rel-17eIABのトポロジ適応強化のさまざまなトピックについて議論する。具体的には、BH RLFインジケーションの機能強化、条件付きハンドオーバの機能強化、及びローカルリルーティングの機能強化である。
(議論)
BH RLFインジケーションの機能強化:
Rel-16の電子メールディスカッションでは、4種類のBH RLF通知が図22に示すように議論された。
BH RLFインジケーションの機能強化:
Rel-16の電子メールディスカッションでは、4種類のBH RLF通知が図22に示すように議論された。
最後に、タイプ4の「リカバリ障害」のみがRel-16のBH RLFインジケーションとして指定された。これにより、子IAB-MTは親ノードのBHリンク上のRLFを認識し、RLF回復手順を開始できる。
所見1:タイプ4の「回復障害」のみがRel-16のBH RLFインジケーションとして指定された。
Rel-17の機能強化について、RAN2は、タイプ2の「回復の試行」及びタイプ3の「BHリンクの回復」を導入することに同意したが、詳細なIABノードの動作は引き続き更なる検討が必要である。
RAN2#113-e:
タイプ2/3RLFインジケーションをサポートするRAN2(詳細は更なる検討が必要である)。タイプ2RLFインジケーションを使用して、ローカルリルーティングをトリガできる。タイプ2RLFインジケーションは、SIBでサポートされているIABの非アクティブ化をトリガするために使用できる。タイプ2RLFインジケーションは、SR及び/又はBSR送信の非アクティブ化、又は削減をトリガするために使用できる。
タイプ2/3RLFインジケーションをサポートするRAN2(詳細は更なる検討が必要である)。タイプ2RLFインジケーションを使用して、ローカルリルーティングをトリガできる。タイプ2RLFインジケーションは、SIBでサポートされているIABの非アクティブ化をトリガするために使用できる。タイプ2RLFインジケーションは、SR及び/又はBSR送信の非アクティブ化、又は削減をトリガするために使用できる。
RAN2#113bis-e:
他のCHO実行条件が必要な場合は更なる検討が必要である(例:タイプ2 RLFインジケーションをトリガとして使用できるかどうか)。
他のCHO実行条件が必要な場合は更なる検討が必要である(例:タイプ2 RLFインジケーションをトリガとして使用できるかどうか)。
更なる検討がなされているものの1つは、RAN2がすでに合意している新しいBHR LFインジケーションの3つの可能なユースケースに関連する動作を指定するかどうか/どのように指定するかである。
ローカルリルーティングのトリガに関しては、タイプ2 BH RLFインジケーションを受信するIABノードの観点からBH RLFがULで発生するため、トリガはアップストリームローカルリルーティング、つまりULパスの切り替えを可能にする必要がある。言い換えると、タイプ2 BH RLFインジケーションを受信するIABノードはダウンストリームノードとの良好なBHリンクを維持できるため、ダウンストリームローカルリルーティングはタイプ2BH RLFインジケーションから独立している。従って、明確に指定する必要があるIAB-MTの動作と見なすことができる。
提案1:RAN2は、IAB-MTが親ノードからタイプ2 BH RLFインジケーションを受信したときに、アップストリームパスでローカルリルーティングをトリガすることを指定することに同意する必要がある。
提案2:RAN2は、IAB-MTが親ノードからタイプ3 BH RLFインジケーションを受信すると、アップストリームパスでのローカルリルーティングを停止する、つまり、設定された「通常の」ルーティングに戻ることを指定することに同意する必要がある。
SIB1でのIABサポートIEの非アクティブ化に関しては、Rel-16での実装まで広く考えられていたIAB-DUの動作と見なすことができる。従って、ステージ2でのみ指定するだけで、おそらく十分である。特に、IAB-DUは、ドナーへの代替ルートがまだある場合、SIB1からIAB-Support IEを削除しないと想定できる。これは、動作が指定されている場合に明確にする必要がある。
提案3:RAN2は、ステージ2でのみIAB-DUがタイプ2 BH RLFインジケーションを受信し、IABドナーへの代替ルートがない場合にSIB1からIAB-Support IEを削除するかどうかを検討する必要がある。
上記のRAN2の合意によれば、提案3が同意できるかどうかに関係なく、IAB-Support IEがSIB1にない場合、IAB-MTは親ノードへの接続確立を開始しない。1つの質問は、親ノードがBH RLFの下にある場合でも、UEがセル(つまり親ノード)へのアクセスを許可されているかどうかである。RRCセットアップリクエストはCU、つまりドナーに到達できないため、最終的にはユーザに悪影響を与える。これを回避するために、セルには、UEのアクセスを禁止し、SSB送信を停止し、又はSIB1を介してタイプ2BH RLFインジケーションをブロードキャストするオプションがある。提案3と同様に、IABノードにドナーへの代替ルートがある場合、IABサポートIEをSIB1から削除する必要はない。
提案4:RAN2は、IAB-DUがタイプ2 BH RLFインジケーションを受信し、IABドナーへの代替ルートがない場合に、IAB-MTアクセスに加えてUEアクセスを禁止するかどうかを検討する必要がある。
SR及び/又はBSR送信の非アクティブ化、又は削減に関しては、IAB-MTの動作と見なされる可能性があるため、明確に指定する必要がある。非アクティブ化又は削減に関しては、仕様の観点から「非アクティブ化」の方が簡単な場合がある。ただし、SR及び/又はBSRは、タイプ3の受信後にのみ送信できるため、スケジューリングの遅延が発生する可能性がある。一方、「削減」は、不要な干渉を引き起こす可能性はあるが、BHリンクが回復した直後にスケジューリングを再開できる場合がある。従って、RAN2は、SR及び/又はBSRの「非アクティブ化」、「削減」、又はその両方をサポートするかどうかについて議論する必要がある。両方がサポートされている場合は、IABドナーによって設定可能である必要がある。更に、「削減」がサポートされている場合、SR及び/又はBSRの削減をどのように処理する必要があるかが不明確である。禁止タイマーの概念を再利用することも考えられるが、この時点では更なる検討が必要である。
提案5:RAN2は、IAB-MTが親ノードからタイプ2 BH RLFインジケーションを受信したときに、SR及び/又はBSR送信を非アクティブ化、又は削減することを指定することに同意する必要がある。
提案6:RAN2は、IAB-MTが親ノードからタイプ3 BH RLFインジケーションを受信したときに、SR及び/又はBSR送信の通常の手順を再開できることを指定することに同意する必要がある。
提案7:RAN2は、タイプ2 BH RLFインジケーションが親ノードから受信されたときに、SR及び/又はBSRの「非アクティブ化」、「削減」、又はその両方(つまり、設定可能)をサポートするかどうかを検討する必要がある。
更なる検討がなされているもののもう1つは、CHOがタイプ2BH RLFインジケーションの受信によってトリガされるかどうかである。タイプ2BH RLFインジケーションが送信された状態で、親ノードはBH RLFを経験し、BHリンクを回復しようとしている。これは、言うまでもなく、IABノードがドナーと通信できないことを意味する。IABノードがデュアルコネクティビティで設定されている場合、提案1のように、MCGとSCGとの間でローカルリルーティングを実行することを選択できる。
ただし、接続が1つしかないIABノードは何も実行できず、親ノードのBH回復又はタイプ4BH RLFインジケーションの受信のいずれかを待機する必要がある。明らかに、それは長期間のサービス中断及びユーザへの悪影響を引き起こす。従って、IABノードには、タイプ2BH RLFインジケーションを受信したときにCHOをトリガするオプションが必要である。更に、さらなる最適化として、IABノードが実際にCHOを実行する前にタイプ3 BH RLFインジケーションを受信した場合に、IABノードがCHO実行をキャンセルする必要があるかどうかを検討する価値がある。
提案8:RAN2は、IAB-MTが親ノードからタイプ2BH RLFインジケーションを受信したときにCHOをトリガすることを指定することに同意する必要がある。
提案9:RAN2は、IAB-MTが親ノードからタイプ3 BH RLFインジケーションを受け取ったときに、(可能であれば)CHO実行をキャンセルするかどうかを検討する必要がある。
提案1及び提案8の両方に合意できる場合、つまり、デュアルコネクティビティ、ローカルリルーティング、及びCHOで同時に設定されたIABノードの場合、タイプ2 BHインジケーションを受信したときに、ローカルリルーティング又はCHOのどちらをトリガするかを選択できる。たとえば、タイプ2の受信によるローカルリルーティングは、サービスの中断を回避するのに役立ちますが、タイプ2の受信によるCHOは、長期的/トポロジ全体のパフォーマンスに適している。ローカルリルーティング及びCHOは、タイプ2受信以外の条件によってトリガされるため、これらは主に、イベントA3によるハンドオーバの堅牢性などのさまざまな目的で設定されていると想定される。
この場合、いくつかのオプションがある。IABノードの実装又はIABドナーの設定のいずれかである。ドナーがトポロジ全体の目標を管理するノードであることを考えると、トポロジのパフォーマンスを制御できる必要があるため、タイプ2の受信によるローカルリルーティング又はCHOの選択は、IABノードの実装に任せるのではなく、ドナーが設定できる必要がある。
提案10:提案1及び提案8の両方に合意できる場合、RAN2は、タイプ2 BH RLFインジケーションを受信したため、IABノードがローカルリルーティング又はCHOをトリガするようにIABドナーが設定できることに更に同意する必要がある。
仕様に新しいBH RLFインジケーションを実装する方法について説明する必要がある。タイプ2及びタイプ3のBH RLFインジケーションは、Rel-16のタイプ4 BH RLFインジケーションの場合と同様に、BAP制御PDUを介して送信されることは簡単であると考えられる。上記の提案3と同様に、UEはBAP制御PDUを受信できないため、BAP層がない。従って、これらのBH RLFインジケーションがSIB1を介してブロードキャストされ、SIB1がDUによってエンコードされる可能性がある。従って、RAN2は、これらがBAP制御PDU又はSIB1のどちらを介して送信されるかを検討する必要がある。
提案11:RAN2は、タイプ2及びタイプ3のBH RLFインジケーションがBAP制御PDU又はSIB1のどちらを介して送信されるかについて議論する必要がある。
(条件付きハンドオーバの機能強化)
条件付きハンドオーバ(CHO)は、モビリティの堅牢性を向上させるためにRel-16に導入された。CHOは指定されたRel-16IABに使用できる。RAN2#113-e及びRAN2#113-eは次の合意に達した。従って、Rel-16CHOに加えてeIABのCHO拡張機能を検討する価値がある。
条件付きハンドオーバ(CHO)は、モビリティの堅牢性を向上させるためにRel-16に導入された。CHOは指定されたRel-16IABに使用できる。RAN2#113-e及びRAN2#113-eは次の合意に達した。従って、Rel-16CHOに加えてeIABのCHO拡張機能を検討する価値がある。
RAN2#113-e:
RAN2では、CHOについて議論し、RAN3がドナー間のIABノードの移行についての議論を進めるまで、ドナー内のCHOの議論から始める。
RAN2は、Rel-16のCHOがIAB-MTに使用される/使用できるという意図を確認する(変更が必要かどうかは更なる検討が必要である)。
RAN2は、Rel-16仕様が、デフォルトルート、IPアドレス、及びドナー内CHOのターゲットパスの設定のベースラインであると想定している。
RAN2では、CHOについて議論し、RAN3がドナー間のIABノードの移行についての議論を進めるまで、ドナー内のCHOの議論から始める。
RAN2は、Rel-16のCHOがIAB-MTに使用される/使用できるという意図を確認する(変更が必要かどうかは更なる検討が必要である)。
RAN2は、Rel-16仕様が、デフォルトルート、IPアドレス、及びドナー内CHOのターゲットパスの設定のベースラインであると想定している。
RAN2#113bis-e:
IAB-MTのCHOの使用例は、移行とRLFリカバリである必要がある。
RAN2には、CU内/DU内CHO、及びCU内/DU間CHOに共通のソリューションが必要である。
CHOイベントA3及びCHOイベントA5はIAB-MTに適用可能である。
他のCHO実行条件が必要な場合は更なる検討が必要である(例:タイプ2 RLFインジケーションをトリガとして使用できるかどうか)。
IAB-MTのCHOの使用例は、移行とRLFリカバリである必要がある。
RAN2には、CU内/DU内CHO、及びCU内/DU間CHOに共通のソリューションが必要である。
CHOイベントA3及びCHOイベントA5はIAB-MTに適用可能である。
他のCHO実行条件が必要な場合は更なる検討が必要である(例:タイプ2 RLFインジケーションをトリガとして使用できるかどうか)。
前セクションの提案8が合意できる場合、CHOイベントA3/A5に依存しないが、タイプ2BH RLFインジケーションによる一種の強制的なトリガであるため、すべてのCHO候補(つまり、候補セル)が同時にCHOをトリガできる可能性がある。
現在の仕様によると、「条件付き再設定の実行で複数のNRセルがトリガされる場合、どれを選択するかはUEの実装次第である。UEは、ビームとビーム品質を考慮して、実行のためにトリガされたセルの1つを選択する。」これは主にUEを対象としている。
所見2:Rel-16のCHOでは、複数の候補セルがCHO実行をトリガする場合、どのセルを選択するかはUEの実装次第である。
IAB-MTに関しては、IAB-MTがローカルの無線品質に応じて実装することにより、トリガされたセルの1つを選択することが常に最良のアプローチであるとは限らない。これは、トポロジ全体の目標は、RAN2#112-eで議論されているように、IABドナーによって効果的に処理される可能性があるためである。従って、RAN2は、追加のトリガ条件を使用したIABドナー制御のCHO実行が、提案8のようにどのように機能するかを検討する必要がある。例えば、IABドナーは、CHO設定でCHO候補に関連付けられた優先度情報を設定できる。IAB-MTは、特定の無線品質(S基準など)を満たすすべてのトリガされたCHO候補から最も優先度の高いセルを選択する必要がある。
提案12:RAN2は、タイプ2 BH RLFインジケーションの受信により、すべての候補セルがCHOをトリガする場合に、追加の拡張機能としてIABドナー制御のCHO実行が必要かどうかを検討する必要がある。
(ローカルリルーティングの機能強化)
Rel-16では、ローカルリルーティングはBH RLFが発生した場合にのみ許可される。
たとえば、RLC-AMエンティティが確認応答を受信するまで、BAPエンティティの送信部分でのデータバッファリングは実装次第である。BH RLFの場合、BAPエンティティの送信部分は、BH RLFの前に下位層によって確認されていないBAPデータPDUを代替パスにリルーティングすることができる。
Rel-16では、ローカルリルーティングはBH RLFが発生した場合にのみ許可される。
たとえば、RLC-AMエンティティが確認応答を受信するまで、BAPエンティティの送信部分でのデータバッファリングは実装次第である。BH RLFの場合、BAPエンティティの送信部分は、BH RLFの前に下位層によって確認されていないBAPデータPDUを代替パスにリルーティングすることができる。
RAN2#113-eは、ローカルリルーティングの機能強化に関連する次の合意を達成した。
タイプ2RLFインジケーションを使用して、ローカルリルーティングをトリガできる。
ローカルリルーティングは、ホップごとのフロー制御を示すことでトリガできる。トリガ情報、トリガ条件、CU設定の役割などの詳細は、更なる検討が必要である。
RAN2は、ドナー間DUローカルリルーティングが範囲内にあると見なす。
タイプ2RLFインジケーションを使用して、ローカルリルーティングをトリガできる。
ローカルリルーティングは、ホップごとのフロー制御を示すことでトリガできる。トリガ情報、トリガ条件、CU設定の役割などの詳細は、更なる検討が必要である。
RAN2は、ドナー間DUローカルリルーティングが範囲内にあると見なす。
ただし、ローカルリルーティングの詳細は、少なくとも設定の観点からはまだ不明である。RAN2#112-eで合意されているように、「RAN2は、中央ルートの決定に対する利点を含め、トポロジ全体の目標にどのように対処できるかについて、ローカルリルーティングについて議論する。」Rel-17の他の場合(つまり、BH RLFに限定されない)。従って、Rel-16の問題は、トポロジ全体の客観的な観点から検討する必要がある。言うまでもなく、IABドナーは、IABトポロジの完全な知識と完全な制御を備えているため、トポロジ全体の目的を処理するエンティティである。
所見3:IABドナーは、トポロジ全体の目的を確実にするために最も適切なエンティティである。
Rel-16ローカルリルーティングでは、宛先が同じである限り、代替パスとしてパスが選択されることはIABノードの実装次第である。これは、ローカルリルーティングがローカルの決定に基づいており、IABドナーの観点からは制御できないことを意味する。これは、特に多くのローカルの決定が発生してIABトポロジに蓄積される場合、トポロジ全体の目的と一致しない可能性がある。
所見4:Rel-16ローカルリルーティングでは、代替パスとしてどのパスが選択されるかはIAB-MTの実装次第である。
従って、ローカルリルーティングがBH RLFの場合を超えて拡張される場合、IABドナーの可制御性はより重要になるはずである。IABドナーが代替パスを設定することは簡単である。これにより、IABノードはローカルリルーティングを実行するときに代替パスを選択する必要がある。代替パスのモデリングは更なる検討が必要である。例えば、代替パスが同じルーティングIDを持っているかどうかなどである。
提案13:RAN2は、IABドナーがRel-16のルーティング設定に加えて代替パスを使用してIABノードを設定できるかどうかを検討する必要がある。
IABドナーの可制御性のもう1つの側面として、IABドナーはローカルリルーティングを認識し、ローカルリルーティング及びトポロジ全体の目的を共存させるためにIABノードでローカルリルーティングを開始/停止できることを考慮する必要がある。例えば、IABドナーは、どのIABノードが現在ローカルリルーティングを実行しているかの知識に基づいて、トポロジ全体の目標がまだ達成されているかどうかを検討できる。IABドナーがトポロジ全体の目的を達成できないことに気付いた場合、IABドナーはIABノードにローカルリルーティングを開始/停止するように指示するか、IABドナーがIABトポロジ全体のルーティング設定を変更する可能性がある。
ローカルリルーティングにより、トポロジ全体の目標をどのように処理するかは、IABドナーの実装次第であるが、IABドナーは、IABノードのローカル決定の情報と制御性を必要とする場合がある。
提案14:RAN2は、ローカルリルーティングの開始/停止時にIABノードがIABドナーに通知する必要があるかどうかを検討する必要がある。
提案15:RAN2は、IABドナーがIABノードにローカルリルーティングを開始/停止するように指示できるかどうかについて議論する必要がある。
Claims (14)
- セルラ通信システムで用いる通信制御方法であって、
第1の中継ノードの上位ノードが、前記第1の中継ノードへ、論理チャネルグループに関する設定値を設定することと、
前記第1の中継ノードが、前記設定値に対応するMAC(Medium Access Control)コントロールエレメント(CE)フォーマットを決定することと、
前記第1の中継ノードが、前記第1の中継ノードの親ノードである第2の中継ノードへ、前記MACコントロールエレメントフォーマットを用いて、バッファステータスレポートを送信することと
を有する通信制御方法。 - 前記設定値は、前記論理チャネルグループの上限値の設定である
請求項1記載の通信制御方法。 - 前記MACコントロールエレメントは、ロングバッファステータスレポート又はプリエンプティブバッファステータスレポートについては、拡張された論理チャネルグループi(LCGi)領域を含む
請求項2記載の通信制御方法。 - 前記MACコントロールエレメントは、ショートバッファステータスレポート(Short BSR)について、拡張された論理チャネルグループID(LCG ID)領域を含む、
請求項3記載の通信制御方法。 - 前記拡張された論理チャネルグループID領域は4ビット以上、前記拡張された論理チャネルグループi領域は16ビット以上である
請求項3又は4に記載の通信制御方法。 - 前記MACコントロールエレメントは、更に、前記上限値が格納されるLCGレンジ(LCG range)領域を含む
請求項3又は4に記載の通信制御方法。 - 前記上限値を設定することは、前記上位ノードが、前記第1の中継ノードへ、レガシーバッファステータスレポートとプリエンプティブバッファステータスレポートとで異なる上限値を設定することを含む
請求項2記載の通信制御方法。 - セルラ通信システムで用いる通信制御方法であって、
配下に第1の中継ノード及び当該第1の中継ノードの親ノードである第2の中継ノードを有するドナー基地局が、前記第1の中継ノードへ、論理チャネル(LCH)のホップ数と論理チャネルグループ(LCG)との対応関係を表す対応情報を設定することと、
前記第1の中継ノードが、前記第2の中継ノードへ、前記対応情報に基づいて、バッファステータスレポート(BSR)を送信することと、
前記第2の中継ノードが、前記第1の中継ノードへ、前記対応情報と前記バッファステータスレポートとに基づいて、アップリンクグラント(UL grant)を送信することと、を有する
通信制御方法。 - 更に、前記ドナー基地局が、前記第2の中継ノードへ、前記対応情報を送信することを有する
請求項8記載の通信制御方法。 - 前記バッファステータスレポートを送信することは、前記第1の中継ノードが、前記対応情報に基づいて、前記論理チャネルを介して受信したパケットのホップ数に対応する前記論理チャネルグループを特定して、当該論理チャネルグループのバッファサイズを含む前記バッファステータスレポートを前記第2の中継ノードへ送信することを含む
請求項8記載の通信制御方法。 - セルラ通信システムで用いる通信制御方法であって、
第1の中継ノードの上位ノードが、前記第1の中継ノードへ、統合バッファステータスレポートの設定を行うことと、
前記第1の中継ノードが、前記設定に従って、バッファステータスレポートの種別毎に分類された論理チャネルグループに対応するバッファサイズが格納された前記統合バッファステータスレポートを、前記第1の中継ノードの親ノードである第2の中継ノードへ送信することと
を有する通信制御方法。 - セルラ通信システムで用いる通信制御方法であって、
第1の中継ノード及び当該第1の中継ノードの親ノードである第2の中継ノードを配下に有するドナー基地局が、前記第1の中継ノードへ、ローカルリルーティング及び条件付きハンドオーバ(CHO)の設定を行うことと、
前記第1の中継ノードが、前記第2の中継ノードから、当該第2の中継ノードと当該第2の中継ノードの親ノードとの間のバックホールリンクで発生した障害に対して当該障害からの回復を試行中であることを示す障害回復通知を受信することと、
前記第1の中継ノードが、前記障害回復通知の受信に応じて、前記ローカルリルーティング又は前記条件付きハンドオーバを実行することと
を有する通信制御方法。 - 更に、前記ドナー基地局が、前記障害回復通知の受信に応じて、前記ローカルリルーティングを実行するのか、又は前記条件付きハンドオーバを実行するのか、を前記第1の中継ノードへ設定することを有する
請求項12記載の通信制御方法。 - 前記ローカルリルーティング又は前記条件付きハンドオーバを実行することは、前記第1の中継ノードが、予め設定されたルールに従って、前記ローカルリルーティング又は前記条件付きハンドオーバをトリガすることを含む
請求項12記載の通信制御方法。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2023518695A JPWO2022234846A1 (ja) | 2021-05-07 | 2022-05-02 | |
US18/502,969 US20240073736A1 (en) | 2021-05-07 | 2023-11-06 | Communication control method |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US202163185648P | 2021-05-07 | 2021-05-07 | |
US63/185,648 | 2021-05-07 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US18/502,969 Continuation US20240073736A1 (en) | 2021-05-07 | 2023-11-06 | Communication control method |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2022234846A1 true WO2022234846A1 (ja) | 2022-11-10 |
Family
ID=83932731
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2022/019528 WO2022234846A1 (ja) | 2021-05-07 | 2022-05-02 | 通信制御方法 |
Country Status (3)
Country | Link |
---|---|
US (1) | US20240073736A1 (ja) |
JP (1) | JPWO2022234846A1 (ja) |
WO (1) | WO2022234846A1 (ja) |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2020196201A1 (ja) * | 2019-03-28 | 2020-10-01 | 京セラ株式会社 | 通信制御方法 |
WO2021065763A1 (ja) * | 2019-10-03 | 2021-04-08 | 京セラ株式会社 | 通信制御方法 |
-
2022
- 2022-05-02 WO PCT/JP2022/019528 patent/WO2022234846A1/ja active Application Filing
- 2022-05-02 JP JP2023518695A patent/JPWO2022234846A1/ja active Pending
-
2023
- 2023-11-06 US US18/502,969 patent/US20240073736A1/en active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2020196201A1 (ja) * | 2019-03-28 | 2020-10-01 | 京セラ株式会社 | 通信制御方法 |
WO2021065763A1 (ja) * | 2019-10-03 | 2021-04-08 | 京セラ株式会社 | 通信制御方法 |
Non-Patent Citations (4)
Title |
---|
KYOCERA: "Possible solutions for topology-wide fairness, multi-hop latency and congestion mitigation in eIAB", 3GPP DRAFT; R2-2103370, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Online; 20210412 - 20210420, 2 April 2021 (2021-04-02), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP052174935 * |
LG ELECTRONICS INC.: "Further consideration on identified issues for fairness, latency and congestion", 3GPP DRAFT; R2-2103418, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Electronic meeting; 20210412 - 20210420, 2 April 2021 (2021-04-02), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP052174979 * |
SAMSUNG: "IAB MAC - miscellaneous corrections and clarifications", 3GPP DRAFT; R2-2008502, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. E-meeting; 20200817 - 20200828, 1 September 2020 (2020-09-01), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051926447 * |
ZTE, SANECHIPS: "Discussion on IAB BH RLF handling", 3GPP DRAFT; R2-1915119, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Reno, USA; 20191118 - 20191122, 8 November 2019 (2019-11-08), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051817029 * |
Also Published As
Publication number | Publication date |
---|---|
JPWO2022234846A1 (ja) | 2022-11-10 |
US20240073736A1 (en) | 2024-02-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR102630472B1 (ko) | 통합된 액세스 및 백홀 베어러 관리를 위한 방법, 장치 및 시스템 | |
US11558866B2 (en) | Method and system for protocol layer enhancements in data offload over small cells | |
CN113424499B (zh) | 在iab网络中协助向ue路由数据的cu、网络节点及其中的方法和相应介质 | |
JP6425800B2 (ja) | ユーザ端末、通信方法及びプロセッサ | |
JP7369240B2 (ja) | 無線端末 | |
US20140254476A1 (en) | Sending data rate information to a wireless access network node | |
KR102359856B1 (ko) | 무선 통신 시스템에서 릴레이의 업링크 버퍼 상태 보고서를 전달하는 방법 및 장치 | |
CN109429267B (zh) | 数据传输方法、相关装置及*** | |
US20230180327A1 (en) | Communication control method | |
WO2020192654A1 (zh) | 配置无线链路控制rlc承载的方法和装置 | |
US20240032129A1 (en) | Communication control method | |
WO2022082602A1 (en) | Method and apparatus for packet rerouting | |
US20230328629A1 (en) | Communication control method | |
WO2022202835A1 (ja) | 通信制御方法 | |
WO2022234846A1 (ja) | 通信制御方法 | |
WO2022239707A1 (ja) | 通信制御方法 | |
WO2022153989A1 (ja) | 通信制御方法 | |
WO2023132285A1 (ja) | 通信制御方法 | |
WO2023068254A1 (ja) | 通信制御方法及び中継ノード | |
WO2023132283A1 (ja) | 通信制御方法 | |
JP7397221B2 (ja) | 通信制御方法、中継ノード及びプロセッサ | |
WO2023068258A1 (ja) | 通信制御方法 | |
WO2023013603A1 (ja) | 通信方法 | |
JP7460856B2 (ja) | 通信制御方法 | |
WO2022202976A1 (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: 22798950 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2023518695 Country of ref document: JP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 22798950 Country of ref document: EP Kind code of ref document: A1 |