WO2020196201A1 - 通信制御方法 - Google Patents
通信制御方法 Download PDFInfo
- Publication number
- WO2020196201A1 WO2020196201A1 PCT/JP2020/012148 JP2020012148W WO2020196201A1 WO 2020196201 A1 WO2020196201 A1 WO 2020196201A1 JP 2020012148 W JP2020012148 W JP 2020012148W WO 2020196201 A1 WO2020196201 A1 WO 2020196201A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- iab node
- rlf
- function unit
- gnb
- notification
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 115
- 238000004891 communication Methods 0.000 title claims abstract description 96
- 230000005540 biological transmission Effects 0.000 claims description 59
- 230000008569 process Effects 0.000 claims description 49
- 230000001960 triggered effect Effects 0.000 claims description 13
- 230000008859 change Effects 0.000 claims description 7
- 230000006866 deterioration Effects 0.000 claims description 4
- 230000006870 function Effects 0.000 description 131
- 238000005259 measurement Methods 0.000 description 50
- 239000000872 buffer Substances 0.000 description 35
- 101150014328 RAN2 gene Proteins 0.000 description 24
- 238000010295 mobile communication Methods 0.000 description 23
- 238000011084 recovery Methods 0.000 description 21
- 238000012545 processing Methods 0.000 description 18
- 238000010586 diagram Methods 0.000 description 15
- 230000006978 adaptation Effects 0.000 description 14
- 238000012546 transfer Methods 0.000 description 13
- 230000011664 signaling Effects 0.000 description 10
- 230000007704 transition Effects 0.000 description 10
- 238000007726 management method Methods 0.000 description 8
- 238000013468 resource allocation Methods 0.000 description 8
- 230000004044 response Effects 0.000 description 8
- 101150096310 SIB1 gene Proteins 0.000 description 4
- 230000006399 behavior Effects 0.000 description 4
- 238000011144 upstream manufacturing Methods 0.000 description 4
- 101000741965 Homo sapiens Inactive tyrosine-protein kinase PRAG1 Proteins 0.000 description 3
- 102100038659 Inactive tyrosine-protein kinase PRAG1 Human genes 0.000 description 3
- 230000009471 action Effects 0.000 description 3
- 230000003111 delayed effect Effects 0.000 description 3
- 238000001514 detection method Methods 0.000 description 3
- 238000007689 inspection Methods 0.000 description 3
- 238000013507 mapping Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000000737 periodic effect Effects 0.000 description 3
- 230000000644 propagated effect Effects 0.000 description 3
- 101100086716 Caenorhabditis elegans ran-3 gene Proteins 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000009977 dual effect Effects 0.000 description 2
- 238000011160 research Methods 0.000 description 2
- 230000001052 transient effect Effects 0.000 description 2
- 101100533725 Mus musculus Smr3a gene Proteins 0.000 description 1
- 108010076504 Protein Sorting Signals Proteins 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 239000006227 byproduct Substances 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000009191 jumping Effects 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000012913 prioritisation Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 230000003595 spectral effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000005641 tunneling Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Images
Classifications
-
- 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
- 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/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/24—Connectivity information management, e.g. connectivity discovery or connectivity update
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/04—Large scale networks; Deep hierarchical networks
- H04W84/042—Public Land Mobile systems, e.g. cellular systems
- H04W84/047—Public Land Mobile systems, e.g. cellular systems using dedicated repeater stations
Definitions
- the present disclosure relates to a communication control method used in a mobile communication system.
- a new relay device called an IAB (Integrated Access and Backhaul) node is being studied.
- One or more relay devices intervene in the communication between the base station and the user equipment, and relay the communication.
- Such a relay device has a user device function and a base station function, and uses the user device function to perform wireless communication with a higher-level node (base station or higher-level relay device) and uses the base station function to perform lower-level communication. Performs wireless communication with a node (user device or lower relay device).
- the wireless section between the user device and the relay device or base station is sometimes called an access link.
- the radio section between the relay device and the base station or other relay device is sometimes referred to as a backhaul link.
- the data transfer path is operated by integrating and multiplexing access link data communication and backhaul link data communication at layer 2 and dynamically allocating radio resources to the backhaul link. The method of switching is described.
- the communication control method is a method using a relay device that wirelessly relays communication between a higher-level device and a lower-level device.
- the communication control method includes that, in the relay device, a user device function unit wirelessly connected to the higher-level device notifies a base station function unit wirelessly connected to the lower-level device of state information.
- the state information is information indicating at least one of the RRC state of the user device function unit and the wireless link state between the higher-level device and the user device function unit.
- the communication control method is a method using a relay device that wirelessly relays communication between a higher-level device and a lower-level device.
- a base station function unit wirelessly connected to the lower device communicates with a donor device via a user device function unit wirelessly connected to the host device or the host device.
- the state information is information indicating a wireless link state between the base station functional unit and the lower device.
- the communication control method is a method using a relay device that wirelessly relays communication between a higher-level device and a lower-level device.
- the relay device receives a notification indicating the occurrence of a wireless link failure with another relay device from a lower device connected to the relay device, and the relay device notifies the donor device. It includes transmitting a message regarding the wireless link failure.
- FIG. 1 is a diagram showing a configuration of a mobile communication system 1 according to the present embodiment.
- the mobile communication system 1 is a fifth generation (5G) mobile communication system based on the 3GPP standard.
- the wireless access system in the mobile communication system 1 is NR (New Radio), which is a 5G wireless access system.
- NR New Radio
- LTE Long Term Evolution
- the mobile communication system 1 includes a 5G core network (5GC) 10, a user device (UE) 100, a base station (referred to as gNB) 200, and an IAB node 300.
- 5GC 5G core network
- UE user device
- gNB base station
- IAB node 300 IAB node 300.
- the base station may be an LTE base station (that is, eNB).
- the 5GC10 includes an AMF (Access and Mobility Management Function) 11 and an UPF (User Plane Function) 12.
- the AMF 11 is a device that performs various mobility controls and the like for the UE 100.
- the AMF 11 manages information on the area in which the UE 100 resides by communicating with the UE 100 using NAS (Non-Access Stratum) signaling.
- the UPF 12 is a device that controls the transfer of user data and the like.
- the gNB 200 is connected to the 5GC10 via an interface called an NG interface. In FIG. 1, three gNB200-1 to gNB200-3 connected to 5GC10 are illustrated.
- the gNB 200 is a fixed wireless communication device that performs wireless communication with the UE 100. When the gNB 200 has a donor function, the gNB 200 may perform wireless communication with an IAB node that wirelessly connects to itself.
- the gNB 200 is connected to another gNB 200 that is adjacent to the gNB 200 via an inter-base station interface called an Xn interface.
- FIG. 1 shows an example in which gNB200-1 is connected to gNB200-2 and gNB200-2.
- Each gNB 200 manages one or more cells.
- Cell is used as a term to indicate the smallest unit of wireless communication area.
- the cell may be used as a term indicating a function or resource for wireless communication with the UE 100.
- One cell belongs to one carrier frequency.
- the UE 100 is a mobile wireless communication device that performs wireless communication with the gNB 200.
- the UE 100 may perform wireless communication with the IAB node 300.
- the UE 100 may be any device that performs wireless communication with the gNB 200 or the IAB node 300.
- the UE 100 is a mobile phone terminal, a tablet terminal, a notebook PC, a sensor or a device provided in the sensor, or a vehicle or a device provided in the vehicle.
- FIG. 1 shows an example in which UE 100-1 is wirelessly connected to gNB200-1, UE100-2 is wirelessly connected to IAB node 300-1, and UE100-3 is wirelessly connected to IAB node 300-2. ing.
- the UE 100-1 directly communicates with the gNB 200-1.
- the UE 100-2 indirectly communicates with the gNB 200-1 via the IAB node 300-1.
- the UE 100-3 indirectly communicates with the gNB 200-1 via the IAB node 300-1 and the IAB node 300-2.
- the IAB node 300 is a device (relay device) that intervenes in the communication between the eNB 200 and the UE 100 and relays the communication.
- FIG. 1 shows an example in which the IAB node 300-1 is wirelessly connected to the donor gNB200-1 and the IAB node 300-2 is wirelessly connected to the IAB node 300-1.
- Each IAB node 300 manages a cell.
- the cell ID of the cell managed by the IAB node 300 may be the same as or different from the cell ID of the cell of the donor gNB200-1.
- the IAB node 300 has a UE function (user equipment function) and a gNB function (base station function).
- the IAB node 300 uses the UE function to perform wireless communication with the upper node (gNB 200 or the upper IAB node 300), and also uses the gNB function to perform wireless communication with the lower node (UE 100 or the lower IAB node 300).
- the UE function means at least a part of the functions of the UE 100, and the IAB node 300 does not necessarily have all the functions of the UE 100.
- the gNB function means at least a part of the functions of the gNB 200, and the IAB node 300 does not necessarily have all the functions of the gNB 200.
- the radio section between the UE 100 and the IAB node 300 or gNB 200 may be referred to as an access link (or Uu).
- the radio section between the IAB node 300 and the gNB 200 or other IAB node 300 may be referred to as a backhaul link (or Un).
- a backhaul link may be referred to as a fronthaul link.
- a millimeter wave band may be used for the access link and the backhaul link.
- the access link and the backhaul link may be multiplexed by time division and / or frequency division.
- FIG. 2 is a diagram showing the configuration of gNB 200.
- the gNB 200 includes a wireless communication unit 210, a network communication unit 220, and a control unit 230.
- the wireless communication unit 210 is used for wireless communication with the UE 100 and wireless communication with the IAB node 300.
- the wireless communication unit 210 includes a receiving unit 211 and a transmitting unit 212.
- the receiving unit 211 performs various receptions under the control of the control unit 230.
- the receiving unit 211 includes an antenna, converts the radio signal received by the antenna into a baseband signal (received signal), and outputs the radio signal to the control unit 230.
- the transmission unit 212 performs various transmissions under the control of the control unit 230.
- the transmission unit 212 includes an antenna, converts a baseband signal (transmission signal) output by the control unit 230 into a radio signal, and transmits the baseband signal (transmission signal) from the antenna.
- the network communication unit 220 is used for wired communication (or wireless communication) with 5GC10 and wired communication (or wireless communication) with another adjacent gNB200.
- the network communication unit 220 includes a reception unit 221 and a transmission unit 222.
- the receiving unit 221 performs various types of reception under the control of the control unit 230.
- the receiving unit 221 receives a signal from the outside and outputs the received signal to the control unit 230.
- the transmission unit 222 performs various transmissions under the control of the control unit 230.
- the transmission unit 222 transmits the transmission signal output by the control unit 230 to the outside.
- the control unit 230 performs various controls on the gNB 200.
- the control unit 230 includes at least one processor and at least one memory.
- the memory stores a program executed by the processor and information used for processing by the processor.
- the processor may include a baseband processor and a CPU (Central Processing Unit).
- the baseband processor modulates / demodulates and encodes / decodes the baseband signal.
- the CPU executes a program stored in the memory to perform various processes.
- the processor executes a process described later.
- FIG. 3 is a diagram showing the configuration of the IAB node 300.
- the IAB node 300 includes a wireless communication unit 310 and a control unit 320.
- the wireless communication unit 310 is used for wireless communication with the gNB 200 (backhaul link) and wireless communication with the UE 100 (access link).
- the wireless communication unit 310 includes a receiving unit 311 and a transmitting unit 312.
- the receiving unit 311 performs various types of reception under the control of the control unit 320.
- the receiving unit 311 includes an antenna, converts the radio signal received by the antenna into a baseband signal (received signal), and outputs the radio signal to the control unit 320.
- the transmission unit 312 performs various transmissions under the control of the control unit 320.
- the transmission unit 312 includes an antenna, converts the baseband signal (transmission signal) output by the control unit 320 into a radio signal, and transmits the baseband signal (transmission signal) from the antenna.
- the control unit 320 performs various controls on the IAB node 300.
- the control unit 320 includes at least one processor and at least one memory.
- the memory stores a program executed by the processor and information used for processing by the processor.
- the processor may include a baseband processor and a CPU.
- the baseband processor modulates / demodulates and encodes / decodes the baseband signal.
- the CPU executes a program stored in the memory to perform various processes.
- the processor executes a process described later.
- FIG. 4 is a diagram showing the configuration of the UE 100. As shown in FIG. 4, the UE 100 includes a wireless communication unit 110 and a control unit 120.
- the wireless communication unit 110 is used for wireless communication on the access link, that is, wireless communication with the gNB 200 and wireless communication with the IAB node 300.
- the wireless communication unit 110 includes a receiving unit 111 and a transmitting unit 112.
- the receiving unit 111 performs various types of reception under the control of the control unit 120.
- the receiving unit 111 includes an antenna, converts the radio signal received by the antenna into a baseband signal (received signal), and outputs the radio signal to the control unit 120.
- the transmission unit 112 performs various transmissions under the control of the control unit 120.
- the transmission unit 112 includes an antenna, converts a baseband signal (transmission signal) output by the control unit 120 into a radio signal, and transmits the baseband signal (transmission signal) from the antenna.
- the control unit 120 performs various controls on the UE 100.
- the control unit 120 includes at least one processor and at least one memory.
- the memory stores a program executed by the processor and information used for processing by the processor.
- the processor may include a baseband processor and a CPU.
- the baseband processor modulates / demodulates and encodes / decodes the baseband signal.
- the CPU executes a program stored in the memory to perform various processes.
- the processor executes a process described later.
- FIG. 5 is a diagram showing an example of a protocol stack configuration of the user plane.
- a protocol stack configuration relating to user data transmission between the UE 100-3 shown in FIG. 1 and the UPF 12 of the 5GC10 will be described.
- UPF12 includes GTP-U (GPRS Tunneling Protocol for User Plane), UDP (User Datagram Protocol), IP (Internet Protocol), and Layer 1 / Layer 2 (L1 / L2). Be prepared.
- the gNB200-1 (donor gNB) is provided with a protocol stack corresponding to these.
- the gNB 200-1 includes an aggregation unit (CU: Central Unit) and a distribution unit (DU: Distributed Unit).
- the CU has each layer of PDCP (Packet Data Convergence Protocol) or higher in the protocol stack of the wireless interface, and the DU has each layer below RLC (Radio Link Control).
- PDCP Packet Data Convergence Protocol
- RLC Radio Link Control
- the CU includes SDAP (Service Data Adaptation Protocol), PDCP, IP, and L1 / L2.
- SDAP Service Data Adaptation Protocol
- PDCP Packet Control Protocol
- IP Packet Control Protocol
- L1 / L2 Low-power Packet Control Protocol
- the SDAP and PDCP of the CU communicate with the SDAP and PDCP of the UE 100 via the DU, the IAB node 300-1 and the IAB node 300-2.
- the DU has an RLC, an adaptation layer (Adapt), a MAC (Medium Access Control), and a PHY (Physical layer) in the protocol stack of the wireless interface.
- RLC Radio Link Control
- Adapt adaptation layer
- MAC Medium Access Control
- PHY Physical layer
- the IAB node 300-1 is provided with the protocol stack ST1 for the UE corresponding to these. Further, the IAB node 300-1 is provided with the protocol stack ST2 for gNB. Both the protocol stack ST1 and the protocol stack ST2 are composed of layers (each sublayer) below layer 2. That is, the IAB node 300-1 is a layer 2 relay device that relays user data using each layer of layer 2 or lower. The IAB node 300-1 relays data without using a layer of layer 3 or higher (specifically, a layer of PDCP or higher).
- the IAB node 300-2 has a protocol stack configuration similar to that of the IAB node 300-1.
- each of the gNB 200-1, the IAB node 300-1, the IAB node 300-2, and the UE 100-3 is provided with an RRC (Radio Resource Control) corresponding to layer 3.
- RRC Radio Resource Control
- An RRC connection is established between the RRC of gNB200-1 (donor gNB) and the RRC of IAB node 300-1, and RRC messages are transmitted and received using this RRC connection. Further, an RRC connection is established between the RRC of the gNB200-1 and the RRC of the IAB node 300-2, and an RRC message is transmitted and received using this RRC connection. Further, an RRC connection is established between the RRC of gNB200-1 and the RRC of UE100-3, and RRC messages are transmitted and received using this RRC connection.
- the IAB node 300-1 establishes an access link connection (first wireless connection) with the gNB200-1 by using the UE function.
- the IAB node 300-1 behaves as the UE 100 and establishes an access link connection with the gNB200-1.
- Establishing an access link connection includes establishing an RRC connection.
- the gNB200-1 establishes a backhaul link connection (second wireless connection) for the gNB function of the IAB node 300-1 with the IAB node 300-1 and the gNB200-1 while maintaining the access link connection.
- a message to be established in the meantime is transmitted to the IAB node 300-1.
- such a message is an RRC Reconfiguration message transmitted and received using an RRC connection.
- the backhaul link connection is established between the IAB node 300-1 and gNB200-1, so that the backhaul link communication can be appropriately started between the IAB node 300-1 and gNB200-1. can do.
- the RRC reset message for establishing the backhaul link connection includes the setting information of the bearer (or L2 link) constituting the backhaul link connection and the cell ID (specifically, the cell ID) to be transmitted by the IAB node 300-1.
- the transmission settings of the reference signal and the synchronization signal associated with) may be included.
- such an RRC reset message will be referred to as an IAB node setting message.
- the IAB node setting message may include the setting information of the default bearer (or default link).
- the default bearer (or default link) is, for example, a bearer (or link) for relaying SIB (System Information Block) or Msg3 relay from the UE.
- SIB System Information Block
- the IAB node setting message may include the stack setting information on the donor gNB200-1 side and optionally the stack setting information on the IAB node 300-2 (or UE100) side.
- the setting group implicitly notified by the SIB of the donor gNB200-1 may be reused, or the operator (OAM) may (in advance). ) May be set.
- RRC reset message can be targeted as the setting contents in the IAB node setting message, but the operation mode such as RLC setting (AM: Macintosh Mode / UM: Macintosh MODE / TM: Transpartent Mode) , LCP (Logical Channel Prioritization) parameters, etc.), MAC settings (BSR: Buffer Status Report / TAG: Timing Advance Group / PHR: Power Headroom parameters, DRX: Discontinue settings, etc. PHY.
- RLC setting AM: Macintosh Mode / UM: Macintosh MODE / TM: Transpartent Mode
- LCP Logical Channel Prioritization
- the setting content in the IAB node setting message may include the setting of the adaptation layer (mapping (routing) setting of the logical channel on the lower side or the upper side, priority setting, etc.).
- the setting content in the IAB node setting message may include the (virtual) IP address (that is, the L3 address) of the IAB node 300-1 as necessary. This is because, for example, in order to establish the F1 interface on the L2 link, the protocol stack of F1 assumes the TCP over IP.
- the setting content in the IAB node setting message is not limited to the setting information of the NR protocol, but may be the setting information of the LTE protocol (RLC, MAC, PHY).
- the IAB node 300-1 has the function of the IAB node (that is, the layer 2 relay function) or requests the establishment of the backhaul link connection before establishing the backhaul link connection.
- An indication indicating the above may be transmitted to gNB200-1. This allows the gNB200-1 to properly initiate a procedure for establishing a backhaul link connection.
- an indication will be referred to as an IAB indication.
- the IAB indication may include information indicating the intent or capability of whether the link protocol stack for UE functions at IAB node 300-1 is prepared in LTE, NR, or both.
- the IAB node 300-1 may transmit an IAB instruction after establishing an access link connection with gNB200-1, or transmits an IAB instruction during a procedure for establishing an access link connection with gNB200-1. You may.
- condition for enabling the transmission of the IAB indication to the gNB there may be a condition that an SIB including a donor function identifier indicating that the gNB has a donor function is received from this gNB.
- the IAB node 300-1 transmits the IAB indication to the gNB200-1 only when the donor function identifier is received from the gNB200-1 by the SIB.
- the gNB 200-1 may have a donor function for establishing a backhaul link connection with the IAB node 300-1.
- the gNB 200-1 sends an IAB node setting message to the IAB node 300-1 after receiving the IAB indication from the IAB node 300-1.
- the gNB200-1 receives the IAB instruction from the IAB node 300-1 and then sends the IAB node setting message to the IAB node 300-1 instead.
- a handover request requesting the handover of the IAB node 300-1 may be transmitted to another gNB.
- the gNB 200-1 stores information of another gNB having a donor function in advance.
- the gNB 200-1 may acquire information on other gNBs having a donor function from the IAB node 300-1.
- the IAB node 300-1 obtains information from 5GC10 (core network) or confirms the SIB (donor function identifier) of the adjacent cell.
- the IAB node 300-1 acquires the information of another gNB (adjacent cell) having the donor function, and notifies the gNB 200-1 of the acquired information.
- the gNB 200-1 transmits a handover request to another gNB having a donor function based on the stored information or the information acquired from the IAB node 300-1.
- the IAB node 300-1 can establish a backhaul link connection with the other gNB.
- the IAB node 300-1 requests the 5GC10 to hand over to the cell (gNB) having the donor function, and the 5GC10 performs the processing related to the handover. May be good.
- the gNB 200-1 may transmit the measurement setting for setting the wireless measurement to the IAB node 300-1 in response to receiving the IAB indication from the IAB node 300-1.
- the IAB node 300-1 After receiving the measurement setting from the gNB200-1, the IAB node 300-1 transmits a measurement report including the result of the radio measurement to the gNB200-1.
- the gNB200-1 determines whether itself (gNB200-1) is a suitable donor gNB or another gNB is a suitable donor gNB based on the measurement report from the IAB node 300-1. For example, gNB200-1 is based on the measurement report when the measurement result for other gNB is better than the measurement result for itself (gNB200-1) and the difference between these measurement reports is larger than the threshold value. , Determine that the other gNB is the appropriate donor gNB. Otherwise, gNB200-1 determines that it is the appropriate donor gNB.
- the gNB200-1 sends an IAB node setting message to the IAB node 300-1.
- the gNB 200-1 requests the handover of the IAB node 300-1 instead of transmitting the IAB node setting message to the IAB node 300-1.
- the handover request is transmitted to the other gNB.
- the IAB node 300-1 can be handed over to another gNB having a better wireless state, and the IAB node 300-1 can establish a backhaul link connection with the other gNB.
- the gNB 200-1 may transmit context information regarding the IAB node 300-1 to another gNB after the backhaul link connection is established.
- This context information includes the connection setting of the AS layer on the radio side (contents of RRC resetting), the PDU session resource setting on the network side (AMF or RAN (Radio Access Network) UE ID, session ID, Quality of Service). / Slice settings, etc.) and other related information (history information such as IAB node behavior and communication, and / or preference information, etc. are included.
- the gNB 200-1 transmits the context information regarding the IAB node 300-1 to another gNB in advance even if it has not determined that the IAB node 300-1 is handed over to another gNB.
- the radio condition between the gNB 200-1 and the IAB node 300-1 deteriorates, and when the IAB node 300-1 reestablishes a wireless connection with another gNB, the context information shared in advance is used. A quick re-establishment can be done.
- the gNB 200-1 holds a table that associates the IAB node 300-1 with the candidate donor gNB of the IAB node 300-1.
- gNB200-1 transmits context information to other gNBs that are candidates in the table. This allows the gNB 200-1 to share contextual information with other appropriate gNBs.
- FIG. 6 is a diagram showing an example of the normal operation sequence in the mobile communication system 1 according to the present embodiment.
- the IAB node 300-1 establishes an access link connection (RRC connection) with the gNB200-1 by, for example, performing a random access procedure for the gNB200-1.
- the IAB node 300-1 may include the IAB indication in the message (eg, Msg3) sent to the gNB200-1 during the random access procedure.
- the gNB 200-1 acquires the context information regarding the IAB node 300-1 in step S101.
- the IAB node 300-1 performs an attach procedure to 5GC10 (specifically, AMF11) via gNB200-1.
- the IAB node 300-1 may notify the AMF 11 of a notification such as an IAB indication (that is, a notification indicating that it wants to operate as an IAB node).
- the IAB node 300-1 may obtain the candidate list of the donor gNB (cell), the routing information such as the presence / absence of the lower node, and other management information from the AMF11.
- AMF11 may notify each candidate of the donor gNB of context information such as the attachment of the IAB node 300-1 and the routing information of the IAB node 300-1.
- the attach process in step S102 can be omitted. Specifically, the IAB node 300-1 performs the attach process in step S101 when the connection with the donor gNB must be reestablished due to the occurrence of some error such as RRC reestablishment (Reestability). Omit.
- the IAB node 300-1 transmits the IAB indication to the gNB200-1.
- the IAB node 300-1 may transmit an IAB instruction triggered by the satisfaction of one or more of the following events.
- the IAB node 300-1 includes the IAB indication in the RRC message transmitted to, for example, gNB200-1.
- Such an RRC message may be a "UE Capability Information" message indicating the ability as a UE.
- step S103 can be omitted.
- the IAB indication may be notified from AMF11 to gNB200-1 in the form of a change in the PDU session resource.
- the AMF may be an AMF for IAB management (dedicated).
- the gNB200-1 determines that a backhaul link connection needs to be established at the IAB node 300-1 based on the IAB indication.
- the gNB 200-1 transmits the measurement setting for setting the wireless measurement to the IAB node 300-1.
- the IAB node 300-1 performs wireless measurement based on the measurement setting. For example, the IAB node 300-1 measures the received power (received power of the cell-specific reference signal) with respect to the cell of the current serving cell, gNB200-1, and the cell of the adjacent cell, gNB200-2.
- step S105 the IAB node 300-1 transmits a measurement report including the result of the radio measurement to the gNB 200-1. Based on the measurement report, gNB200-1 determines whether itself (gNB200-1) is a suitable donor gNB or another gNB is a suitable donor gNB. Here, the description will proceed on the assumption that gNB200-1 has determined that it (gNB200-1) is an appropriate donor gNB. The processes of steps S104 and S105 are not essential and may be omitted.
- the gNB 200-1 transmits an IAB node setting message (RRC reset message) to the IAB node 300-1.
- the IAB node configuration message may include a handover instruction designating the cell of the gNB200-1 (ie, the current serving cell of the IAB node 300-1) as the handover destination.
- the IAB node 300-1 performs a process of establishing a backhaul link connection with gNB200-1 based on the IAB node setting message.
- Such an establishment process includes a process of generating a protocol stack (adaptation / RLC / MAC / PHY entity) for backhaul link and setting parameters based on the setting information in the IAB node setting message.
- Such an establishment process may include a process of preparing a protocol stack on the UE side (for access links) and starting transmission of a synchronization signal or a cell-specific reference signal (or a process of preparing to start transmission).
- step S107 the IAB node 300-1 sends a completion notification message to the gNB 200-1 indicating that the IAB node setting including the establishment of the backhaul link connection is completed. From step S107 onward, the IAB node 300-1 does not behave as a UE with respect to the gNB200-1, but as an IAB node.
- step S108 gNB200-1 transfers the context information acquired in step S101 to gNB200-2 on the Xn interface.
- the gNB 200-1 holds a table that associates the IAB node 300-1 with the candidate donor gNB of the IAB node 300-1, and determines the context transfer destination with reference to this table. In this way, if the gNB 200-1 transfers the context to another gNB in advance, the wireless connection state with the gNB connected to the IAB node 300-1 deteriorates immediately. A reconnection with the other gNB can be established.
- FIG. 7 is a diagram showing an example of a table for determining the context transfer destination. Such a table is preset for each gNB by, for example, an operator. As shown in FIG.
- the donor gNB candidates are associated with each IAB node.
- the identifier of the candidate of the donor gNB is associated with each identifier related to the IAB node.
- a gNB geographically close to an IAB node is set as a candidate for a donor gNB for that IAB node.
- the table of FIG. 7 shows an example of association with gNB, it may be associated with cell ID.
- the cell ID may be a physical layer cell ID or a global cell ID.
- gNB200-1 may determine gNB200-1 geographically close to IAB node 300-1 as a donor candidate based on the measurement report received from IAB node 300-1.
- the gNB 200-1 may create a table for associating the IAB node 300-1 with the donor gNB candidate of the IAB node 300-1 or update an existing table based on the determined donor candidate.
- step S109 gNB200-1 sends a notification to 5GC10 indicating that a backhaul link connection with IAB node 300-1 has been established.
- the gNB 200-1 may send a request to establish a PDU session for the IAB node to the 5GC10.
- the request for establishing the PDU session may be transmitted from AMF11 to gNB200-1 before step S109 or in step S109.
- FIG. 8 is a diagram showing an example of an exceptional operation sequence in the mobile communication system 1 according to the present embodiment.
- the gNB 200-1 hands over the IAB node 300-1 to the gNB 200-2.
- the IAB node 300-1 establishes an access link connection (RRC connection) with the gNB200-1 by, for example, performing a random access procedure for the gNB200-1.
- the IAB node 300-1 may include the IAB indication in the message (eg, Msg3) sent to the gNB200-1 during the random access procedure.
- the gNB 200-1 acquires the context information regarding the IAB node 300-1 in step S201.
- step S202 the IAB node 300-1 performs an attach procedure to 5GC10 (specifically, AMF11) via gNB200-1.
- 5GC10 specifically, AMF11
- step S203 the IAB node 300-1 transmits the IAB indication to the gNB200-1.
- the IAB node 300-1 includes the IAB indication in the RRC message transmitted to, for example, the gNB200-1.
- Such an RRC message may be a "UE Capability Information" message indicating the capability of the UE.
- step S203 can be omitted.
- step S204 gNB200-1 determines whether or not it has donor ability. If gNB200-1 does not have donor capacity (step S204: NO), gNB200-1 proceeds to step S208.
- step S205 the gNB200-1 transmits the measurement setting for setting the wireless measurement to the IAB node 300-1.
- the IAB node 300-1 performs wireless measurement based on the measurement setting. For example, the IAB node 300-1 measures the received power (received power of the cell-specific reference signal) with respect to the cell of the current serving cell, gNB200-1, and the cell of the adjacent cell, gNB200-2.
- step S206 the IAB node 300-1 transmits a measurement report including the result of the radio measurement to the gNB 200-1.
- step S207 gNB200-1 determines whether itself (gNB200-1) is an appropriate donor gNB or another gNB is an appropriate donor gNB based on the measurement report. If it is determined that itself (gNB200-1) is an appropriate donor gNB (step S207: YES), gNB200-1 proceeds to step S106 of the above-mentioned normal operation sequence (see FIG. 6).
- step S207 if it is determined that the other gNB is an appropriate donor gNB (step S207: NO), gNB200-1 proceeds to step S208.
- the gNB 200-1 transfers the handover request message including the IAB indication received from the IAB node 300-1 to the gNB 200-2 on the Xn interface.
- the gNB 200-1 may include the context information acquired in step S201 in the handover request message.
- the gNB 200-1 may transmit the handover request message with information indicating that the IAB node 300-1 requires the gNB to function as the donor gNB instead of including the IAB indication. Good.
- the gNB 200-1 may transfer the handover request message to the gNB 200-2 on the Xn interface after determining that the gNB 200-2 has the donor ability. Specifically, for example, when gNB200-1 determines in the table shown in FIG.
- the gNB200-1 sends a handover request message to gNB200-2. May be transferred to.
- the handover of the IAB node 300-1 can be executed more quickly.
- information regarding its own donor capacity may be shared in advance between a plurality of gNB 200s adjacent to each other via the Xn interface. Thereby, the gNB 200-1 can identify the adjacent gNB 200 having the donor ability, and can transfer the handover request message to the specified adjacent gNB 200.
- the gNB 200-2 determines whether or not to accept the handover of the IAB node 300-1 in consideration of the IAB indication included in the handover request message.
- the gNB 200-2 may reject the handover request if it does not have the donor ability.
- the description will proceed on the assumption that the gNB 200-2 has determined to accept the handover of the IAB node 300-1.
- step S209 the gNB 200-2 transmits a handover acknowledgment message to the gNB 200-1 on the Xn interface.
- step S210 the gNB 200-1 transmits a handover instruction message (RRC reset message) to the IAB node 300-1 based on the handover acknowledgment message from the gNB 200-2.
- the handover instruction message includes information for designating the handover destination gNB200-2 (cell).
- step S211 the IAB node 300-1 performs a handover to the gNB 200-2 based on the handover instruction message from the gNB 200.
- FIG. 9 is a diagram showing an example of the multi-hop connection sequence in the mobile communication system 1 according to the present embodiment.
- the multi-hop connection sequence is when the IAB node 300-2 or UE100-2 connects to the IAB node 300-1 after the backhaul link connection is connected between the IAB node 300-1 and the gNB200-1. It is a sequence.
- the case where the IAB node 300-2 is connected to the IAB node 300-1 will be mainly described, but the IAB node 300-2 may be appropriately read as the UE 100-2. Further, the description overlapping with the above-mentioned "(1) Normal operation sequence" will be omitted.
- the IAB node 300-2 performs an access link connection (RRC) with the gNB200-1 by performing a random access procedure to the gNB200-1 via the IAB node 300-1. Connection) is established.
- the IAB node 300-2 may include the IAB indication in the message (eg, Msg3) sent to the gNB200-1 during the random access procedure.
- gNB200-1 acquires context information regarding the IAB node 300-2 in step S301.
- the IAB node 300-2 performs an attach procedure to 5GC10 (specifically, AMF11) via the IAB node 300-2 and gNB200-1.
- the IAB node 300-2 may notify the AMF 11 of a notification such as an IAB indication (that is, a notification indicating that it wants to operate as an IAB node).
- the IAB node 300-2 may obtain the candidate list of the donor gNB (cell), the routing information such as the presence / absence of the lower node, and other management information from the AMF11.
- AMF11 may notify each candidate of the donor gNB of context information such as the attachment of the IAB node 300-2 and the routing information of the IAB node 300-2.
- the attach process in step S302 can be omitted. Specifically, the IAB node 300-2 omits the attach process when it is necessary to reestablish the connection with the donor gNB due to the occurrence of some error, such as RRC re-establishment (Reestability).
- step S303 the IAB node 300-2 transmits the IAB indication to the gNB200-1 via the IAB node 300-1.
- the IAB node 300-2 may transmit an IAB instruction in response to a trigger similar to the trigger described in step S103 of "(1) Normal operation sequence" described above.
- the IAB node 300-2 includes the IAB indication in the RRC message transmitted to, for example, gNB200-1.
- Such an RRC message may be a "UE Capability Information" message indicating the ability as a UE.
- step S303 can be omitted.
- the IAB indication may be notified from AMF11 to gNB200-1 in the form of a change in the PDU session resource.
- the AMF may be an AMF for IAB management (dedicated).
- gNB200-1 determines that it is necessary to establish a backhaul link connection between the IAB node 300-1 and the IAB node 300-2 based on the IAB indication.
- step S304 the gNB 200-1 transmits the measurement setting for setting the wireless measurement to the IAB node 300-2.
- the IAB node 300-2 performs wireless measurement based on the measurement setting.
- step S305 the IAB node 300-2 transmits a measurement report including the result of the radio measurement to the gNB 200-1 via the IAB node 300-1.
- gNB200-1 determines whether itself (gNB200-1) is a suitable donor gNB or another gNB is a suitable donor gNB.
- the description will proceed on the assumption that gNB200-1 has determined that it (gNB200-1) is an appropriate donor gNB.
- the processes of steps S304 and S305 are not essential and may be omitted.
- the gNB 200-1 transmits an IAB node setting message (RRC reset message) to the IAB node 300-2.
- the IAB node 300-2 performs a process of establishing a backhaul link connection with the IAB node 300-1 based on the IAB node setting message.
- Such an establishment process includes a process of generating a protocol stack (adaptation / RLC / MAC / PHY entity) for backhaul link and setting parameters based on the setting information in the IAB node setting message.
- Such an establishment process may include a process of preparing a protocol stack on the UE side (for access links) and starting transmission of a synchronization signal or a cell-specific reference signal (or a process of preparing to start transmission).
- step S307 the gNB 200-1 transmits an RRC reset message to the IAB node 300-1.
- the RRC reset message is a message for changing the setting in the IAB node 300-1 with the addition of the IAB node 300-2.
- Such an RRC reset message includes, for example, mapping information indicating the association between the logical channel of the IAB node 300-2 and the logical channel of the backhaul link of the IAB node 300-1. Note that step S307 may be before step S306 or at the same time as step S306.
- step S308 the IAB node 300-2 sends a completion notification message to the gNB 200-1 indicating that the IAB node setting including the establishment of the backhaul link connection with the IAB node 300-1 is completed.
- the IAB node 300-2 behaves as an IAB node rather than acting as a UE with respect to gNB200-1.
- step S309 the IAB node 300-1 sends a completion notification message to the gNB 200-1 indicating that the setting change accompanying the establishment of the backhaul link connection with the IAB node 300-2 has been completed. Note that step S309 may be before step S308 or at the same time as step S308.
- step S310 gNB200-1 transfers the context information of the IAB node 300-2 acquired in step S301 to gNB200-2 on the Xn interface.
- step S311 the gNB 200-1 sends a notification to the 5GC10 indicating that the backhaul link connection of the IAB node 300-2 has been established.
- the gNB 200-1 may send a PDU session establishment request for the IAB node 300-2 to the 5GC10.
- the PDU session establishment request may be transmitted from AMF11 to gNB200-1 before step S311 or in step S311.
- each gNB 200 may provide information to the IAB node 300-1 as to whether or not it has donor capacity.
- the IAB node 300-1 can be connected after selecting the gNB 200 having the donor ability.
- the gNB 200 having donor ability broadcasts information indicating that it has donor ability by including it in a system information block (SIB).
- SIB system information block
- the IAB node 300-1 selects the gNB 200 as the connection destination based on the SIB.
- the IAB node 300-1 may select the gNB 200 as a connection destination when the gNB 200 has a donor ability and the received power from the gNB 200 is equal to or more than the threshold value.
- the IAB node 300-1 may reselect another gNB 200 in response to receiving the SIB transmitted from the gNB 200.
- the IAB node 300-1 performs a random access procedure with the other gNB200 as the connection destination. IAB indications may be sent.
- each gNB 200 has the ability to handle the IAB node 300 in addition to notifying by SIB that it has donor capacity, or in place of notifying by SIB that it has donor capacity. You may notify by SIB that you have. For example, each gNB 200 may notify by SIB that it has a function of handing over the IAB node 300 to another gNB (donor gNB).
- Msg3 is, for example, an RRC Setup Request message.
- the IAB node 300 may include the IAB indication in the establishment case, which is a field (information element) in Msg3.
- the IAB node 300 may notify the IAB indication using the random access preamble (Msg1) transmitted to the gNB 200 during the random access procedure.
- Msg1 the random access preamble
- the PRACH resource may be a time / frequency resource or a signal sequence (preamble sequence).
- the IAB node 300 may notify the IAB indication at a timing other than the random access procedure.
- the IAB node 300 may include the IAB indication in the RRC message such as the UE Assistance Information message.
- the gNB 200 transmits the measurement setting for setting the radio measurement to the IAB node 300 or the UE 100, and receives the measurement report including the result of the radio measurement, whereby the gNB 200 is a suitable donor.
- An example of determining whether the gNB is a gNB or another gNB is an appropriate donor gNB based on the measurement report has been described.
- the gNB 200 is not limited to using the measurement result at the time of such initial connection, and may use the measurement report for changing the network topology or changing the data transfer route.
- the subordinate device directly under the IAB node 300 detects a radio link failure (RLF) with the IAB node 300, it reselects another cell and tries to reestablish the connection to the reselected cell.
- RLF radio link failure
- the IAB node 300 may not be able to grasp that the lower device has detected the RLF.
- the lower device detects an out-of-sync state (out-of-sync) N310 times in a row, it detects a radio problem (radio problem).
- the lower device detects a radio problem, it starts a predetermined timer T310.
- the lower device stops the timer T310 when the synchronization state (in-sync) is continuously detected N311 times.
- the timer T310 expires, the lower device detects the RLF, starts the timer T311 and starts the cell reselection operation (connection reestablishment process). Then, when the timer T311 expires without succeeding in reestablishing the connection, the lower device transitions to the RRC idle mode.
- FIG. 11 is a diagram showing the operation of the IAB node 300 according to the second embodiment.
- the IAB node 300 receives an uplink signal periodically transmitted from a subordinate device directly under the IAB node 300.
- the lower device refers to the UE 100 or another IAB node intervening between the UE 100 and the IAB node 300.
- the uplink signal may be a signal that can be transmitted periodically.
- MAC CE for example, buffer state report
- RRC message for example, measurement report message
- / or uplink reference signal can be used as the uplink signal.
- step S602 the IAB node 300 starts the timer in response to the reception of the uplink signal from the lower device.
- the timer value set in this timer may be the value set from the donor gNB200-1.
- the timer value may be a time longer than the cycle in which the lower device transmits the uplink signal.
- step S603 After starting the timer, when the IAB node 300 receives the uplink signal from the lower device (step S603: YES), the IAB node 300 stops the timer in step S604. In this case, the process returns to step S602 and restarts the timer.
- step S606 the IAB node 300 determines that the lower device has detected the RLF. To do. When the IAB node 300 determines that its lower device has detected the RLF, it may request its higher device to release the wireless bearer (backhaul link) corresponding to this lower device.
- the IAB node 300 can grasp that the RLF is detected in the lower device.
- FIG. 12 is a diagram showing an example of an operation sequence according to the second embodiment.
- the IAB node 300-2 is wirelessly connected to the UE 100-3 as a lower device and the IAB node 300-1 as a higher device, and the UE 100-3 and the IAB node 300-1 are connected. Wirelessly relay communication with and from.
- the base station function unit (DU) wirelessly connects to the UE 100-3
- the user device function unit (MT) wirelessly connects to the IAB node 300-1.
- the lower device may be an IAB node.
- the IAB node 300-2 may be wirelessly connected to the donor device (gNB200-1) without going through the IAB node 300-1.
- the host device and the donor device are the same device.
- step S611 the base station function unit (DU) of the IAB node 300-2 detects a radio link failure (RLF) with the UE 100-3.
- RLF radio link failure
- Such an RLF may be referred to as a Frontal RLF from the perspective of the IAB node 300-2.
- a method based on ACK / NACK from UE 100-3 can be used in addition to the method described above. Specifically, if the base station function unit (DU) of the IAB node 300-2 does not return ACK or NACK from UE100-3 even if the downlink HARQ is retransmitted, for example, the RLF with UE100-3 Is detected.
- DU base station function unit
- the base station function unit (DU) of the IAB node 300-2 provides the state information (RLF notification) indicating that the RLF with the UE 100-3 has been detected to the user device function unit (MT) of the IAB node 300-2.
- This status information (RLF notification) may include an identifier for the UE 100-3, such as a UE identifier and / or a bearer identifier.
- step S613 the user equipment function unit (MT) of the IAB node 300-2 transmits an RRC message including status information (RLF notification) to the donor gNB200-1 via the IAB node 300-1.
- the donor gNB200-1 may release the bearer corresponding to the UE 100-3 based on the state information (RLF notification) included in this RRC message.
- the sequence shown in FIG. 12 may be changed as follows.
- the base station function unit (DU) of the IAB node 300-2 provides state information (RLF notification) indicating that the RLF with the UE 100-3 has been detected in the F1 of the IAB node 300-2.
- state information (RLF notification) may include an identifier for the UE 100-3, such as a UE identifier and / or a bearer identifier.
- the F1-AP entity refers to a communication function unit that communicates with the donor gNB200-1 on the F1 interface, which is the interface of the front hall.
- step S613 the user equipment function unit (MT) of the IAB node 300-2 transmits an F1-AP message including status information (RLF notification) to the donor gNB200-1 via the IAB node 300-1.
- the donor gNB200-1 may release the bearer corresponding to the UE 100-3 based on the state information (RLF notification) included in this F1-AP message.
- the sequence shown in FIG. 12 may be changed as follows.
- step S611 the base station function unit (DU) of the IAB node 300-2 detects that all the lower devices under its control have transitioned to the RRC idle state or the RRC inactive state.
- step S612 the base station function unit (DU) of the IAB node 300-2 provides state information indicating that all the subordinate devices under its control have transitioned to the RRC idle state or the RRC inactive state. Notify the user equipment function unit (MT) or F1-AP entity of.
- the user equipment function unit (MT) or F1-AP entity of the IAB node 300-2 can release its RRC connection based on the state information from the base station function unit (DU).
- the indicated RAI Releasure Assistance Inspection
- Donor gNB200-1 may release the RRC connection of UE100-3 based on this RAI.
- the IAB node 300-2 has notified the donor gNB200-1 of the RLF between itself and the subordinate device.
- the subordinate device may notify the donor gNB200-1 of the RLF detected with the other IAB node.
- FIG. 13 is a diagram showing an operation sequence according to a modified example of the second embodiment.
- another IAB node may intervene between the IAB node 300-2 and the donor gNB200-1.
- step S621 the base station function unit (DU) of the IAB node 300-2 is connected to the IAB node 300-3 from the lower device (UE100-3) connected to the IAB node 300-2.
- This notification may be an RRC Restamination message or an RLF Inspection.
- the UE 100-3 detects the RLF with the IAB node 300-3 and reestablishes the connection with the IAB node 300-2.
- the UE 100-3 transmits an RRC Restabrishment message to the IAB node 300-2.
- This RRC Restamination message is not only the identifier of the UE 100-3, but also the information indicating that the UE 100-3 was connected to the IAB node 300-3 (may be the identifier of the IAB node 300-3), and /. Alternatively, it may include the identifier of the donor device to which the UE 100-3 is connected via the IAB node 300-3 and the like.
- the UE 100-3 detects the RLF with the IAB node 300-3 during the dual connectivity (DC) communication connected at the same time as the IAB nodes 300-3 and 300-2, and sets the RLF index related to this RLF to the IAB node 300 Send to -2.
- this RLF Indication may be called an MCG (Master Cell Group) RLF Indication.
- the RLF Inspection may include an identifier of the UE 100-3, an identifier of the IAB node 300-3, an identifier of the donor device to which the UE 100-3 is connected via the IAB node 300-3, and the like.
- step S622 the base station function unit (DU) of the IAB node 300-2 uses the information included in the notification received from the UE 100-3 in step S621 as the terminal function unit (MT) of the IAB node 300-2 or F1-. Notify the AP entity.
- step S623 the terminal function unit (MT) or F1-AP entity of the IAB node 300-2 transmits a message including the information notified from the base station function unit (DU) to the donor gNB200-1.
- This message is an RRC message or an F1-AP message.
- the donor gNB200-1 determines that the UE 100-3 was under the control of another donor device, that is, belongs to the topology of the other donor device, based on the information contained in the received message, the other donor device is concerned. Notification may be given to the donor device. This notification may include at least one of the identifier of the UE 100-3 and the identifier of the IAB node 300-3.
- FIG. 14 is a diagram showing an operation according to the third embodiment.
- "DU” corresponds to the base station function
- "MT" corresponds to the user device function.
- the UE 100-3 transmits uplink data (PDU) to the IAB node 300-2 according to the procedure of steps S701 to S705. Specifically, the UE 100-3 transmits a scheduling request (SR) to the IAB node 300-2 (step S701), receives an allocation of uplink radio resources for BSR transmission (step S702), and transmits the BSR. (Step S703), the uplink radio resource for uplink data transmission is allocated (step S704), and the uplink data is transmitted to the IAB node 300-2 (step S705).
- SR scheduling request
- the IAB node 300-2 transmits uplink data (PDU) to the IAB node 300-1 according to the procedure of steps S706 to S710.
- the IAB node 300-1 transmits uplink data (PDU) to the donor gNB200-1 according to the procedure of steps S711 to S715.
- PDU uplink data
- each IAB node 300 receives a first scheduling request requesting the allocation of uplink radio resources from the lower device. Then, each IAB node 300 transmits a second scheduling request to the higher-level device before receiving the uplink data (PDU) from the lower-level device.
- PDU uplink data
- the scheduling request is triggered when it has the uplink data to be transmitted, but in the present embodiment, the scheduling request is triggered at the stage where the uplink data to be transmitted is not yet possessed. As a result, smooth allocation of uplink radio resources can be realized.
- step S706 when the IAB node 300-2 receives the BSR from the UE 100-3 (step S703), the IAB node 300-2 transmits a scheduling request to the IAB node 300-1.
- the IAB node 300-2 sends the scheduling request to the IAB node 300-1 after receiving the scheduling request from the UE 100-3 (step S701) and before receiving the BSR from the UE 100-3 (step S703). Good.
- the IAB node 300-2 After receiving the scheduling request from the UE 100-3 (step S701), the IAB node 300-2 transmits the scheduling request to the IAB node 300-1 when allocating the uplink radio resource to the UE 100-3 (step S702). (Trigger) may be used.
- the IAB node 300-2 may transmit (trigger) the scheduling request to the IAB node 300-1.
- each IAB node 300 transmits a first buffer state report indicating at least the amount of data that the IAB node 300 can use for uplink transmission to the host device.
- the host device is another IAB node (upper IAB node) or donor gNB200 under the donor gNB200. The host device allocates radio resources for uplink transmission to the IAB node 300 based on the first buffer status report.
- the IAB node 300 has an uplink buffer that temporarily stores data waiting for uplink transmission. For example, the MAC layer of the IAB node 300 notifies the MAC layer of the host device of the first buffer state including information indicating the amount of data in the uplink buffer. The MAC layer of the host device has a scheduler, allocates uplink radio resources to the IAB node 300 based on the first buffer state, and notifies the IAB node 300 of the allocated resources via the control channel.
- the IAB node 300 buffers the uplink data for a plurality of UEs, it is considered that the IAB node 300 has a larger capacity uplink buffer than the UE 100. Therefore, the buffer status report for the IAB node may have a different format from the buffer status report for the UE. Further, the amount of data that can be expressed by the buffer state report for the IAB node (maximum amount of data) may be larger than the amount of data that can be expressed by the buffer state report for the UE (maximum amount of data).
- the buffer status report for the IAB node may include information about the number of UEs 100 under the IAB node 300.
- the IAB node 300 may determine the number of UEs 100 under its own control based on the UE context, C-RNTI (Cell-Radio Network Temporary Identifier), etc., and notifies the number of UEs 100 under its own control from the donor gNB200. May be done.
- the IAB node 300 may include in the buffer status report the number of UEs 100 that have data in its uplink buffer among the UEs 100 under its control. In other words, the IAB node 300 may notify the host device by buffer status reporting how many UEs of uplink data it has.
- the IAB node 300 may include the number of UEs 100 in the RRC connected state among the UEs 100 under its control in the buffer state report.
- the buffer status report for the IAB node takes into account not only the amount of data actually existing in the uplink buffer of the IAB node 300, but also the buffer status report (that is, the potential uplink data amount) from the lower device. You may. As a result, the host device can allocate the uplink radio resource to the IAB node 300 in advance in consideration of the potential uplink data amount, so that the uplink transmission delay due to multi-hop can be suppressed. ..
- the IAB node 300 receives from the subordinate device a second buffer status report indicating the amount of data that the subordinate device can use for uplink transmission. Based on the second buffer status report, the IAB node 300 reports the first buffer status based on the amount of data that it can use for uplink transmission and the amount of data that the lower device can use for uplink transmission. To the host device. For example, the IAB node 300 may include the total value of the amount of data available for uplink transmission by itself and the amount of data available for uplink transmission by the lower device in the first buffer state report. Alternatively, the IAB node 300 has a first BSR value indicating the amount of data available for uplink transmission by itself and a second BSR value indicating the amount of data available to the lower device for uplink transmission. It may be included in the first buffer status report separately.
- the amount of data that the IAB node 300 can use for uplink transmission is the amount of data in its own transmission buffer (MT buffer), the amount of data in its own reception buffer (DU), and / or the amount of buffer in the adaptation entity. May include.
- FIG. 15 is a diagram showing the operation of the IAB node 300 according to the fourth embodiment.
- the IAB node 300 is wirelessly connected to the host device A via the backhaul link.
- the host device A is a host IAB node or donor gNB (donor device).
- the lower devices B1 and B2 are connected to the IAB node 300, and the lower device B3 is connected to the lower device B2.
- the lower device B4 is a device that is not under the control of the IAB node 300.
- the lower devices B1 to B4 are lower IAB nodes or UEs. In the following, when the lower devices B1 to B4 are not particularly distinguished, they are simply referred to as lower devices B.
- the user device function unit (MT) that wirelessly connects to the upper device A is wirelessly connected to the lower device B. Notify the status information to the base station function unit (DU) connected by.
- This state information includes at least one of the RRC state of the user device function unit (MT) and the wireless link state (hereinafter referred to as backhaul link state) between the host device A and the user device function unit (MT). This is information indicating the state of.
- the base station function unit (DU) can control the service provision to the lower device B in consideration of the state on the backhaul link side.
- the RRC state of the user equipment function unit (MT) is either connected, inactive, or idle.
- the backhaul link state is a state based on at least one index among the above 1) to 6) below, or a combination of these indexes.
- RLF state such as detection of RLF and recovery from RLF
- Radio quality such as RSRP (Reference Signal Received Power) 3) Number of RLC (Radio Link Control) retransmissions, number of RACH (Random Access Channel) retransmissions, etc.
- Congestion level such as RSSI (Received Signal Throughput Indicator), CBR (Channel Busy Radio), LBT (Listen Before Talk) status 5) Number of secondary cells set or activated, MIMO (Multi) Output) Number of layers, allocation radio resource status (for example, increase / decrease of Configured grant in quasi-static allocation, increase / decrease of Dynamic grant in dynamic allocation), communication capacity such as throughput measurement value 6) Measurement value of uplink scheduling delay time, Delayed state such as the amount of data in the uplink buffer.
- RSSI Receiveived Signal Throughput Indicator
- CBR Channel Busy Radio
- LBT Listen Before Talk
- MIMO Multi
- allocation radio resource status for example, increase / decrease of Configured grant in quasi-static allocation, increase / decrease of Dynamic grant in dynamic allocation
- communication capacity such as throughput measurement value 6) Measurement value of uplink scheduling delay time, Delayed state such as the amount of data in the uplink buffer.
- the backhaul link state may be a state in which the degree of goodness of the backhaul link state based on the indicators 1) to 6) above, for example, better than the threshold value or worse than the threshold value.
- the user equipment function unit (MT) may notify the base station function unit (DU) of the state information by using a change in the RRC state or a change in the backhaul link state as a trigger. For example, the user equipment function unit (MT) notifies the base station function unit (DU) of the state information when an event that the backhaul link state satisfies the threshold condition occurs.
- the user equipment function unit (MT) may periodically notify the base station function unit (DU) of the status information.
- the base station function unit (DU) may stop providing services to the lower device B based on the status information from the user device function unit (MT). Stopping the service provision to the lower device B means stopping the transmission of at least one downlink radio signal.
- the base station function unit (DU) may stop the transmission of PSS (Primary Synchronization Signal), PSS (Secondary Synchronization Signal), and MIB (Master Information Block).
- the base station function unit (DU) may stop providing services to the lower device B when the user device function unit (MT) transitions to the RRC idle state or the RRC inactive state.
- the base station function unit (DU) may resume the service provision to the lower device B when the user device function unit (MT) transitions to the RRC connected state.
- the base station function unit (DU) may stop providing services to the lower device B when the backhaul link is deteriorated, for example, when RLF is detected in the backhaul.
- the base station function unit (DU) may resume providing services to the lower device B when the backhaul link is improved.
- the base station function unit (DU) may control the radio resource allocation (scheduling) to the lower device B based on the state information from the user device function unit (MT).
- the base station function unit (DU) may cancel the resource allocation to the lower device B when the user device function unit (MT) transitions to the RRC idle state or the RRC inactive state.
- the base station function unit (DU) may allocate uplink resources to the lower device B when the user device function unit (MT) transitions to the RRC idle state or the RRC inactive state.
- the base station function unit (DU) may request the user device function unit (MT) to transition to the RRC connected state.
- the base station function unit (DU) may resume resource allocation to the lower device B when the user device function unit (MT) transitions to the RRC connected state.
- the base station function unit (DU) may cancel the resource allocation to the lower device B when the backhaul link is deteriorated, for example, when RLF is detected in the backhaul.
- the base station function unit (DU) may resume resource allocation to the lower device B when the backhaul link is improved, for example, when the backhaul recovers from the RLF.
- the base station function unit (DU) receives a notification indicating deterioration of the backhaul link, for example, a notification indicating the occurrence of RLF of the backhaul link (hereinafter, RLF) based on the state information from the user device function unit (MT).
- a notification may be transmitted to the lower device B.
- the RLF notification may include the identifier of the IAB node 300.
- the base station function unit (DU) may transmit the RLF notification by the control signal of the layer lower than the RRC layer. This is because the base station function unit (DU) does not have an RRC connection with the lower device B.
- the control signal of the layer lower than the RRC layer is MAC CE (Control Element), RLC Control PDU (Protocol Data Unit), or PDCCH (Physical Downlink Control Channel), but MAC CE will be used below as an example. To do.
- the base station function unit (DU) may transmit the RLF notification to the lower device B by unicast.
- the base station function unit (DU) may transmit the RLF notification by broadcasting or multicast in order to reduce the signaling load of the RLF notification.
- the lower devices B3 and B4 monitor not only the RLF notification from the connected cell (upper IAB node) but also the RLF notification of other cells, so that the lower device B3 and B4 monitor the RLF notification from the IAB node 300. Can be received.
- the base station function unit (DU) may broadcast the RLF notification using, for example, a fixed RNTI (Radio Network Temporary Identifier) defined in advance in the specifications.
- the base station function unit (DU) may transmit the RLF notification by multicast using a common RNTI assigned to a group of lower devices.
- the base station function unit (DU) may notify (broadcast) by SIB whether the RLF notification is transmitted by broadcast / multicast or unicast. Based on this SIB, the lower device B may change the standby mode of the RLF notification, for example, the RNTI used for monitoring the RLF notification.
- the base station function unit (DU) may periodically transmit the RLF notification during the period when the radio link state of the backhaul link is deteriorated, for example, during the period when the RLF of the backhaul link is generated. .. In this case, RLF is generated within the period in which the RLF notification is periodically transmitted.
- the base station function unit (DU) may transmit an RLF notification when an RLF of the backhaul link occurs, and may transmit a notification indicating restoration when the RLF of the backhaul link is restored.
- the lower device B determines that the backhaul link RLF has occurred within the period of receiving the RLF notification from the IAB node 300.
- the transmission cycle of the RLF notification may be set from the donor device to the base station function unit (DU) via the user device function unit (MT) of the IAB node 300.
- the lower device B that has received the RLF notification may start transmitting the ACK / NACK feedback to the IAB node 300 in response to the reception of the RLF notification.
- the IAB node 300 may stop the periodic transmission of the RLF notification.
- the subordinate devices B1 to B3 that have received the RLF notification may perform a process for switching the connection destination or the communication path from the IAB node 300. Examples of such processing include connection reestablishment processing, conditional handover trigger processing, communication path switching processing, and measurement report processing for handover. It should be noted that the lower devices B1 to B3 do not receive the RLF notification from the IAB node 300 (or restore the backhaul RLF) after the switching process is started and before the switching process is completed. When the notification shown is received), it may be determined that the backhaul link of the IAB node 300 has been restored, and the switching process may be stopped.
- the lower devices B1 to B3 that have received the RLF notification perform a cell search for searching for cells other than the cells of the IAB node 300, and reestablish the connection (RRC Restoration) for the appropriate cells.
- RRC Restoration reestablish the connection
- the connection reestablishment process may be controlled so as to be distributed in time.
- the lower devices B1 to B3 distribute the execution start time of the connection reestablishment process of the lower devices B1 to B3 by determining the execution start time of the connection reestablishment process using a random value or the UE-ID. It is possible to prevent load concentration.
- the base station function unit (DU) distributes the transmission timing of the RLF notification to distribute the execution start time of the connection reestablishment processing of the lower devices B1 to B3. May be good.
- the lower devices B1 to B3 that have received the RLF notification are connected to the IAB node 300 and the higher device other than the IAB node 300 to perform DC communication, the lower devices B1 to B3 have another communication path via the IAB node 300. It may be switched to a higher-level device, or RLF notification may be transmitted to another communication device. For example, when the lower device B sets the IAB node 300 as the master node (MN) and the other higher device as the secondary node (SN) for backup, the lower device B switches the communication path via the MN to the SN. ..
- MN master node
- SN secondary node
- the subordinate devices B1 to B3 that have received the RLF notification are set for conditional handover, they may consider that the conditions are satisfied and perform the handover.
- the handover condition is an event indicating deterioration of the radio quality of the serving cell
- the handover may be forcibly triggered by modifying the radio quality measurement result of the serving cell to be low (for example, assuming that it is ⁇ 200 dBm).
- Subordinate devices B1 to B3 that have received the RLF notification may trigger the transmission of the measurement report.
- the general measurement report is transmitted as an RRC message, but the base station function unit (DU) does not have an RRC layer. Therefore, the IAB node 300 retains the measurement report from the lower device B until it recovers from the backhaul link RLF, and transfers it to the donor device when it recovers from the backhaul link RLF (temporarily). The donor device may hand over the lower device B.
- the lower device B4 that has received the RLF notification may perform a process for excluding the IAB node 300 as a candidate for the connection destination.
- the lower device B4 that has received the RLF notification lowers the priority of the cell of the IAB node 300 or excludes it from the reselection target in the cell reselection operation in the RRC idle state or the RRC inactive state, or the IAB node 300.
- Adjust the received power measurement for As a result, the IAB node 300 may be excluded as a candidate for the connection destination.
- an offset value may be applied to the actual received power measurement value.
- the offset value may be a predetermined fixed value.
- the offset value may be a value notified from the network, and the notification may be notified by the notification information (SIB) of the cell in which the lower device B4 is currently camping.
- SIB notification information
- the lower device B4 may perform the process for excluding the IAB node 300 as a candidate for the connection destination at the timing before starting the RRC Set Request process or the RRC Request Request process when transitioning to the RRC connected state. ..
- the lower device B4 confirms whether or not the destination candidate cell has notified the RLF notification before transmitting the RRC Set Request. If the destination candidate cell does not notify the RLF notification, the lower device B4 transmits the RRC Set Request Request. When the destination cell is notifying the RLF notification, the transmission of the RRC Set Request is stopped (or stopped), and the cell reselection operation is performed to select an appropriate RRC Set Request destination.
- the lower device B4 When the lower device B4 no longer receives the RLF notification from the IAB node 300 (or receives a notification indicating the recovery of the backhaul RLF), the lower device B4 determines that the backhaul link of the IAB node 300 has been restored and connects to the connection destination. The process for excluding the IAB node 300 as a candidate for is may be stopped.
- FIG. 16 is a diagram showing an example of the operation according to the fourth embodiment.
- another IAB node may intervene between the IAB node (Parent IAB node) 300 and the donor gNB (IAB donor) 200.
- step S801 the user equipment function unit (MT) of the IAB node 300 detects a radio problem (radio problem).
- step S802 the user device function unit (MT) of the IAB node 300 detects the RLF (RLF declaration).
- step S803 the user equipment function unit (MT) of the IAB node 300 notifies the base station function unit (DU) of the IAB node 300 of the state information indicating the occurrence of RLF.
- step S804 the base station function unit (DU) of the IAB node 300 starts the periodic transmission of the RLF notification in response to the notification from the user device function unit (MT).
- step S805 the lower device B that has received the RLF notification starts the process for switching the connection destination or the communication path from the IAB node 300.
- a connection reestablishment process (Early RRC Re-estival), a conditional handover trigger process (Triggering Conditional HO), and a communication path switching process (Switching to redundant route).
- step S806 the user device function unit (MT) of the IAB node 300 cannot reestablish the connection, for example, during the operation of the T310, and transitions to the RRC idle state according to the expiration of the T310 (Go to IDLE).
- step S807 the user equipment function unit (MT) of the IAB node 300 notifies the base station function unit (DU) of the IAB node 300 of the state information indicating the transition to the RRC idle state.
- step S808 the base station function unit (DU) of the IAB node 300 stops providing the service to the lower device B in response to the notification from the user device function unit (MT) (Service stopped).
- step S809 the lower device B detects the RLF because the service provision from the IAB node 300 is stopped.
- the base station in the mobile communication system 1 may be an eNB.
- the core network in the mobile communication system 1 may be an EPC (Evolved Packet Core).
- the gNB can be connected to the EPC
- the eNB can be connected to the 5GC
- the gNB and the eNB can be connected via the inter-base station interface (Xn interface, X2 interface).
- a program that causes a computer to execute each process according to the above-described embodiment may be provided.
- the program may also be recorded on a computer-readable medium.
- Computer-readable media can be used to install programs on a computer.
- the computer-readable medium on which the program is recorded may be a non-transient recording medium.
- the non-transient recording medium is not particularly limited, but may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.
- a chipset composed of a memory for storing a program for executing each process performed by the UE 100 and the eNB 200 and a processor for executing the program stored in the memory may be provided.
- IAB node specifications following architecture 1a, including:
- TR identifies in sections 9.7.14 and 9.7.15 the problems caused by the BH RLF of multi-hop radio backhaul.
- a common problem between sections is that the child IAB node / UE is unaware of the BH RLF on the parent IAB node. This can cause BH RLF to occur frequently in high frequency radio backhaul such as FR2 and multi-hopping. As a result, from the user's point of view, the service is significantly interrupted, including delayed recovery of the service.
- TR also identifies potential solutions as follows:
- Option 1 is a general solution for the common problem between sections 9.7.14 and 9.7.15, as BH RLF information is implicitly propagated to child IAB nodes and UEs. Can be considered. Given that BH RLF affects not only the child IAB node, but also the UE (connected to the parent IAB node facing the BH RLF), Option 1 is expected to rely on existing RLF and recovery mechanisms. Therefore, it is an important aspect that Option 1 is supported by the Rel-15 UE. On the other hand, other options will require the functionality of Rel-16. To minimize service interruptions even for Rel-15 UEs, option 1 should be specified as the baseline solution for the BH RLF problem.
- Proposal 1 RAN2 should agree that Option 1, i.e., the IAB node stops service at BH RLF, and Option 1 is also valid for Rel-15 UE, so it is a baseline solution. is there.
- the solution should make it easy to "determine BH RLF also for child nodes".
- the MTs and UEs of the child IAB nodes should declare an RLF if the "service" is interrupted.
- a simple solution is for the parent IAB node under BH RLF to stop transmitting PSS, SSS, MIB, and SIB1. This intentionally creates a radio problem for the child IAB node and the UE.
- Proposal 2 RAN2 should agree that the IAB node will stop transmitting PSS, SSS, MIB, and SIB1 if it decides to discontinue the "service".
- the BH RLF can be considered as an RLF between the MT of the IAB node and the DU of the IAB donor (eg, the DU of the parent IAB node). It can be understood in exactly the same way as using the existing RLF between the UE and gNB. Therefore, the BH RLF is modeled as an RLF in a wireless backhaul link.
- Proposal 3 RAN2 should agree to reuse the existing RLF mechanism in BH RLF.
- Proposal 4 RAN2 should agree that the DU of the IAB node will stop the "service" when the MT enters the RRC IDLE, not when the MT declares an RLF.
- Option 1 is the basis for covering all types of cases and devices, including the UE of Rel-15, and does not mean the best solution in terms of quick recovery of service, etc. .. Therefore, as there are many other features to be defined in this WI, the other options are still beneficial in addition to Option 1 and can be discussed as time permits.
- Findings 1 In addition to Option 1, other options are still beneficial in terms of further improving quality of service.
- the IAB node notifies the downstream node (option 2, option 4) It is useful for the parent IAB node to inform the child IAB node of information related to its BH RLF in order to facilitate the child IAB node to initiate the recovery procedure quickly and / or efficiently.
- the TR may have possible information elements such as "explicitly warn child IAB nodes about upstream RLF" (option 2), or "on backhaul failures including a list of nodes that cannot function as parent nodes" (option 4). ) Capture the information.
- RAN-3 recommends architecture 1a for future normative stages.
- CU is in charge of RRC between DU and CU, and BH RLF is detected by RRC of MT. Therefore, there are two different RRCs to consider.
- the RRC on the MT of the parent IAB node detects the BH RLF, and the different RRCs of the IAB donors generate RRC messages sent to the child IAB nodes.
- the information to the downstream node cannot be transmitted by the RRC message. That is, the RRC message generated by the CU cannot reach the DU due to the BH RLF.
- the "warning" (of option 2) may be sent by MAC CE or the like, but the "list of nodes” (of option 4) is too large and too flexible unless an RRC message is used. Therefore, if option 2 and / or option 4 is introduced, RAN2 should first consider which signaling is used.
- Finding 2 The DU of the IAB node does not have to use the RRC message because the physical wireless link to the CU is broken.
- All IAB nodes share information on a regular basis (option 3)
- the IAB node can detect the BH RLF based on the shared information.
- the information captured by the TR is, for example, "BH quality". This may be the existing GNU-DU STATUS INDICATION of F1 or the new signaling between DUs.
- Option 5 may be aimed at utilizing, for example, multi-connectivity (with MN / SN role changes), conditional handover, or other techniques related to normal topology adaptation or mobility expansion.
- Option 5 is another of this WI or other WI, as stated in the TR that "additional features / extensions defined as part of the other Rel-16 WI may be utilized". You may reuse the results discussed in the topic.
- Findings 5 may reuse the solutions discussed in this WI or other topics in other WIs.
- IAB node following architecture 1a ⁇
- IAB node following architecture 1a ⁇
- IAB node following architecture 1a ⁇
- IAB node following architecture 1a ⁇
- IAB node following architecture 1a ⁇
- IAB node following architecture 1a ⁇
- IAB node following architecture 1a ⁇
- IAB node following architecture 1a ⁇
- IAB node following architecture 1a ⁇
- IAB node following architecture 1a ⁇
- One approach to mitigate such delays consists of initiating an uplink resource request at the IAB node based on the data expected to arrive. Thereby, the IAB node becomes a child. Uplink resources will be available before the IAB node or the UE it serves will receive the actual data. ”, And“ SR / BSR and UL scheduling details and trigger details are in the WI stage. Identify the possible mechanism of "remaining in.”
- RAN2 should extend SR, BSR, and / or UL scheduling for dynamic resource allocation.
- Proposal 1 RAN2 should extend SR, BSR, and / or UL scheduling for dynamic resource allocation in multi-hop radio backhaul.
- SR is triggered when there is no resource for normal BSR transmission as shown below.
- a normal BSR is triggered when data becomes available for transmission, as follows:
- the MAC entity determines the amount of UL data available on the logical channel according to the data volume calculation procedure of TS38.322 and 38.323.
- BSR is triggered when any of the following events occur.
- This UL data belongs to a logical channel with a higher priority than the logical channel containing the available UL data belonging to any LCG. Or -The logical channel belonging to the LCG does not contain available UL data.
- BSR is called "normal BSR".
- Proposal 2 RAN2 should agree that the MT MAC entity needs to consider the amount of UL data visible in the DU of the same IAB node.
- Option 1 The actual amount of data in the buffer in the MAC, RLC, PDCP (and in some cases the adaptation layer) of the DU protocol stack.
- Option 2 In addition to Option 1, the amount of data already granted to the child node / UE (Fig. 18).
- Option 3 In addition to Option 2, the data that can be used for transmission on the child node / UE, that is, the buffer size of the BSR from the child node / UE (FIG. 14).
- option 3 is optimal because it is expected that the MT of the IAB node grants the backhaul link resource when the DU of the IAB node receives UL data from the child node / UE.
- the solution On the other hand, unless the reception of UL grant in MT and the reception of UL data in DU are sufficiently synchronized, resource waste may occur. That is, overscheduling may occur.
- Option 1 has lower risk but lower profit.
- Option 2 is considered a balanced solution among the other options.
- Proposal 3 RAN2 should discuss whether the additional data available for transmission is the amount of data associated with the UL grant to the UE or the BSR from the UE.
- TR also identifies potential solutions as follows:
- R2 has an RLF notification at least in BH Link RLF to the downstream node.
- Alternate links and / or dual connectivity can be used during recovery in the event of a BH Link failure.
- the current UE RLF detection and recovery will be reused as a baseline.
- Option 1 is a general solution for the common problem between sections 9.7.14 and 9.7.15, as BH RLF information is implicitly propagated to child IAB nodes and UEs. Can be considered.
- the agreed "RLF notification” is a feature of Rel-16, but the Rel-15 UE is still allowed to connect to the IAB node. To minimize service interruptions even for Rel-15 UEs, option 1 should be specified as the baseline solution for the BH RLF problem.
- Finding 1 The agreed "RLF notification” cannot solve the BH RLF problem from the perspective of the Rel-15 UE.
- the solution should make it easy to "determine BH RLF also for child nodes".
- a simple solution is for the parent IAB node under BH RLF to stop transmitting PSS, SSS, MIB, and SIB1. This intentionally creates a radio problem for the child IAB node and the UE.
- Proposal 1 RAN2 should agree that the IAB node will stop transmitting PSS, SSS, MIB, and SIB1 if it decides to discontinue the "service".
- RAN2 has already assumed "RRF notification in BH Link RLF" and the current UE behavior is RRC even after declaring RLF, that is, to initiate RRC reestablishment. It is doubtful whether the service actually needs to be stopped at the RLF to stay connected.
- the IAB node should stop the "service” only when the MT enters the RRC IDLE, that is, when the RRC reestablishment fails. In this sense, it is natural for the MT to notify the DU (of the same IAB node) that it will enter RRC IDLE (it may transition to RRC Connected during the setup stage).
- Proposal 2 RAN2 should agree that the DU of the IAB node will stop the "service" when the MT enters the RRC IDLE, not when the MT declares an RLF.
- Proposal 3 If Proposal 2 is agreed, RAN2 further discusses whether MT needs to notify DU (of the same IAB node) if MT enters RRC IDLE.
- the IAB node notifies the downstream node (option 2, option 4) It is useful for the parent IAB node to inform the child IAB node of information related to its BH RLF in order to facilitate the child IAB node to initiate the recovery procedure quickly and / or efficiently.
- the TR may have possible information elements such as "explicitly warn child IAB nodes about upstream RLF" (option 2), or "on backhaul failures including a list of nodes that cannot function as parent nodes" (option 4). ) Capture the information.
- RAN2 agreed to a baseline that "R2 assumes that there is an RLF notification at least in the BH Link RLF to the downstream node".
- RAN-3 recommends architecture 1a for future normative stages.
- CU is in charge of RRC between DU and CU, and BH RLF is detected by RRC of MT. Therefore, there are two different RRCs to consider.
- the RRC on the MT of the parent IAB node detects the BH RLF, and the different RRCs of the IAB donors generate RRC messages sent to the child IAB nodes.
- the information to the downstream node cannot be transmitted by the RRC message. That is, the RRC message generated by the CU cannot reach the DU due to the BH RLF.
- the "warning" (of option 2) may be sent by the MAC CE, but the MAC CE is not appropriate to convey the "list of nodes" (option 4). Therefore, RAN2 should assume option 2 with MAC CE and should not consider option 4.
- Finding 2 The DU of the IAB node does not have to use the RRC message because the physical wireless link to the CU is broken.
- Proposal 4 RAN2 should discuss whether RLF notifications to downstream nodes are sent via MAC CE.
- Proposal 5 RAN2 should agree that the RLF notification will be sent when the DU is notified of the RLF by MT.
- Proposal 6 RAN2 should agree that the MT / UE does not declare the RLF when it receives the RLF notification, it only initiates some backhaul link recovery.
- the "downstream node” naturally means a child node / UE that is directly connected to the parent node.
- the "downstream node” also includes grandchild nodes / UEs that are not directly connected to the parent (that is, the parent is a grandparent from the perspective of the grandchild).
- the grandchild can receive the RLF notification, there is an advantage that the recovery of the topology is quick because the propagation delay of the RLF notification is eliminated.
- any IDLE node / UE can receive RLF notifications, it may be considered during reselection.
- the node / UE cannot connect to the donor node, it is possible to try to avoid reselection or connection of the cell in which BH RLF occurs even if the cell rank is the highest.
- the disadvantage is the complexity of topology adaptation and management.
- Proposal 7 RAN2 should clarify whether the RLF notification is received only by the child node or the grandchild node as well.
- some topology adaptation procedure for example, RRC reestablishment to another IAB node, or switching of the primary path to the redundant route is started.
- the backhaul "link restored" information is useful because the procedure can be stopped if the topology adaptation procedure has not been completed, for example if the RRC reestablishment procedure does not find a suitable cell.
- the RLF notification is repeatedly transmitted during BH RLF, it is not necessary to specify any "other instructions”. This is because if the RLF notification is not sent, BH RLF has not occurred. Otherwise, the "service" will stop. Therefore, the question is whether to repeatedly send RLF notifications during BH RLF.
- Proposal 8 RAN2 should discuss whether RLF notifications are repeatedly transmitted during BH RLF.
- IAB nodes share information on a regular basis (option 3)
- the IAB node can detect the BH RLF based on the shared information.
- the information captured by the TR is, for example, "BH quality". This may be the existing GNU-DU STATUS INDICATION of F1 or the new signaling between DUs.
- Finding 3 Option 3 may be outside the scope of RAN2.
- Option 5 may be aimed at utilizing, for example, multi-connectivity (with MN / SN role changes), conditional handover, or other techniques related to normal topology adaptation or mobility expansion.
- Option 5 is another of this WI or other WI, as stated in the TR that "additional features / extensions defined as part of the other Rel-16 WI may be utilized". You may reuse the results discussed in the topic. Only IAB-specific effects (if any) will be discussed later, such as whether RLF notifications trigger certain actions such as "MCG Fairure Information”.
- Findings 4 may reuse the solutions discussed in this WI or other topics in other WIs.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
第1の態様に係る通信制御方法は、上位装置と下位装置との間の通信を無線で中継する中継装置を用いる方法である。前記通信制御方法は、前記中継装置において、前記上位装置と無線で接続するユーザ装置機能部が、前記下位装置と無線で接続する基地局機能部に対して状態情報を通知するステップを備える。前記状態情報は、前記ユーザ装置機能部のRRC状態、及び前記上位装置と前記ユーザ装置機能部との間の無線リンク状態のうち、少なくとも一方の状態を示す情報である。
Description
本開示は、移動通信システムに用いられる通信制御方法に関する。
移動通信システムの標準化プロジェクトである3GPP(3rd Generation Partnership Project)において、IAB(Integrated Access and Backhaul)ノードと称される新たな中継装置が検討されている。1又は複数の中継装置が基地局とユーザ機器との間の通信に介在し、この通信に対する中継を行う。かかる中継装置は、ユーザ機器機能及び基地局機能を有しており、ユーザ機器機能を用いて上位ノード(基地局又は上位の中継装置)との無線通信を行うとともに、基地局機能を用いて下位ノード(ユーザ機器又は下位の中継装置)との無線通信を行う。
ユーザ機器と、中継装置又は基地局との間の無線区間は、アクセスリンクと称されることがある。中継装置と、基地局又は他の中継装置との間の無線区間は、バックホールリンクと称されることがある。3GPP寄書「RP-170217」には、アクセスリンクのデータ通信及びバックホールリンクのデータ通信をレイヤ2において統合及び多重化し、バックホールリンクに動的に無線リソースを割り当てることにより、データ転送経路を動的に切り替える方法が記載されている。
第1の態様に係る通信制御方法は、上位装置と下位装置との間の通信を無線で中継する中継装置を用いる方法である。前記通信制御方法は、前記中継装置において、前記上位装置と無線で接続するユーザ装置機能部が、前記下位装置と無線で接続する基地局機能部に対して状態情報を通知することを含む。前記状態情報は、前記ユーザ装置機能部のRRC状態、及び前記上位装置と前記ユーザ装置機能部との間の無線リンク状態のうち、少なくとも一方の状態を示す情報である。
第2の態様に係る通信制御方法は、上位装置と下位装置との間の通信を無線で中継する中継装置を用いる方法である。前記通信制御方法は、前記中継装置において、前記下位装置と無線で接続する基地局機能部が、前記上位装置と無線で接続するユーザ装置機能部又は前記上位装置を介してドナー装置と通信する通信機能部に対して、状態情報を通知することを含む。前記状態情報は、前記基地局機能部と前記下位装置の間の無線リンク状態を示す情報である。
第3の態様に係る通信制御方法は、上位装置と下位装置との間の通信を無線で中継する中継装置を用いる方法である。前記通信制御方法は、前記中継装置が、前記中継装置に接続する下位装置から、他の中継装置との無線リンク障害の発生を示す通知を受信することと、前記中継装置が、ドナー装置に対して、前記無線リンク障害に関するメッセージを送信することとを含む。
図面を参照しながら、実施形態に係る移動通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
[第1実施形態]
(移動通信システムの構成)
本実施形態に係る移動通信システムの構成について説明する。図1は、本実施形態に係る移動通信システム1の構成を示す図である。移動通信システム1は、3GPP規格に基づく第5世代(5G)移動通信システムである。具体的には、移動通信システム1における無線アクセス方式は、5Gの無線アクセス方式であるNR(New Radio)である。但し、移動通信システム1には、LTE(Long Term Evolution)が少なくとも部分的に適用されてもよい。
(移動通信システムの構成)
本実施形態に係る移動通信システムの構成について説明する。図1は、本実施形態に係る移動通信システム1の構成を示す図である。移動通信システム1は、3GPP規格に基づく第5世代(5G)移動通信システムである。具体的には、移動通信システム1における無線アクセス方式は、5Gの無線アクセス方式であるNR(New Radio)である。但し、移動通信システム1には、LTE(Long Term Evolution)が少なくとも部分的に適用されてもよい。
図1に示すように、移動通信システム1は、5Gコアネットワーク(5GC)10と、ユーザ機器(UE)100と、基地局(gNBと称される)200と、IABノード300とを備える。本実施形態において、基地局がNR基地局である一例について主として説明するが、基地局がLTE基地局(すなわち、eNB)であってもよい。
5GC10は、AMF(Access and Mobility Management Function)11及びUPF(User Plane Function)12を備える。AMF11は、UE100に対する各種モビリティ制御等を行う装置である。AMF11は、NAS(Non-Access Stratum)シグナリングを用いてUE100と通信することにより、UE100が在圏するエリアの情報を管理する。UPF12は、ユーザデータの転送制御等を行う装置である。
gNB200は、NGインターフェイスと称されるインターフェイスを介して、5GC10に接続される。図1において、5GC10に接続された3つのgNB200-1~gNB200-3を例示している。gNB200は、UE100との無線通信を行う固定の無線通信装置である。gNB200がドナー機能を有する場合、gNB200は、自身に無線で接続するIABノードとの無線通信を行ってもよい。
gNB200は、Xnインターフェイスと称される基地局間インターフェイスを介して、隣接関係にある他のgNB200と接続される。図1において、gNB200-1がgNB200-2及びgNB200-2に接続される一例を示している。
各gNB200は、1又は複数のセルを管理する。セルは、無線通信エリアの最小単位を示す用語として用いられる。セルは、UE100との無線通信を行う機能又はリソースを示す用語として用いられることがある。1つのセルは1つのキャリア周波数に属する。
UE100は、gNB200との無線通信を行う移動可能な無線通信装置である。UE100は、IABノード300との無線通信を行ってもよい。UE100は、gNB200又はIABノード300との無線通信を行う装置であればどのような装置であってもよい。例えば、UE100は、携帯電話端末やタブレット端末、ノートPC、センサ若しくはセンサに設けられる装置、又は車両若しくは車両に設けられる装置である。
図1において、UE100-1がgNB200-1に無線で接続され、UE100-2がIABノード300-1に無線で接続され、UE100-3がIABノード300-2に無線で接続される一例を示している。UE100-1は、gNB200-1との通信を直接的に行う。UE100-2は、IABノード300-1を介してgNB200-1との通信を間接的に行う。UE100-3は、IABノード300-1及びIABノード300-2を介してgNB200-1との通信を間接的に行う。
IABノード300は、eNB200とUE100との間の通信に介在し、この通信に対する中継を行う装置(中継装置)である。図1において、IABノード300-1がドナーであるgNB200-1に無線で接続され、IABノード300-2がIABノード300-1に無線で接続される一例を示している。各IABノード300は、セルを管理する。IABノード300が管理するセルのセルIDは、ドナーgNB200-1のセルのセルIDと同じであってもよいし、異なっていてもよい。
IABノード300は、UE機能(ユーザ機器機能)及びgNB機能(基地局機能)を有する。IABノード300は、UE機能を用いて上位ノード(gNB200又は上位のIABノード300)との無線通信を行うとともに、gNB機能を用いて下位ノード(UE100又は下位のIABノード300)との無線通信を行う。なお、UE機能とは、UE100が有する機能のうち少なくとも一部の機能を意味し、必ずしもUE100の全ての機能をIABノード300が有していなくてもよい。gNB機能とは、gNB200の機能のうち少なくとも一部の機能を意味し、必ずしもgNB200の全ての機能をIABノード300が有していなくてもよい。
UE100と、IABノード300又はgNB200との間の無線区間は、アクセスリンク(或いは、Uu)と称されることがある。IABノード300と、gNB200又は他のIABノード300との間の無線区間は、バックホールリンク(或いは、Un)と称されることがある。かかるバックホールリンクは、フロントホールリンクと称されてもよい。
アクセスリンクのデータ通信及びバックホールリンクのデータ通信をレイヤ2において統合及び多重化し、バックホールリンクのデータ通信に動的に無線リソースを割り当て、中継の経路を動的に切り替えることが可能である。なお、アクセスリンク及びバックホールリンクには、ミリ波帯が用いられてもよい。また、アクセスリンク及びバックホールリンクは、時分割及び/又は周波数分割により多重化されてもよい。
(gNBの構成)
本実施形態に係るgNB200の構成について説明する。図2は、gNB200の構成を示す図である。図2に示すように、gNB200は、無線通信部210と、ネットワーク通信部220と、制御部230とを備える。
本実施形態に係るgNB200の構成について説明する。図2は、gNB200の構成を示す図である。図2に示すように、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は、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
(IABノードの構成)
本実施形態に係るIABノード300の構成について説明する。図3は、IABノード300の構成を示す図である。図3に示すように、IABノード300は、無線通信部310と、制御部320とを備える。
本実施形態に係るIABノード300の構成について説明する。図3は、IABノード300の構成を示す図である。図3に示すように、IABノード300は、無線通信部310と、制御部320とを備える。
無線通信部310は、gNB200との無線通信(バックホールリンク)及びUE100との無線通信(アクセスリンク)に用いられる。無線通信部310は、受信部311及び送信部312を備える。受信部311は、制御部320の制御下で各種の受信を行う。受信部311はアンテナを含み、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部320に出力する。送信部312は、制御部320の制御下で各種の送信を行う。送信部312はアンテナを含み、制御部320が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
制御部320は、IABノード300における各種の制御を行う。制御部320は、少なくとも1つのプロセッサ及び少なくとも1つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びCPUを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
(UEの構成)
本実施形態に係るUE100の構成について説明する。図4は、UE100の構成を示す図である。図4に示すように、UE100は、無線通信部110と、制御部120とを備える。
本実施形態に係るUE100の構成について説明する。図4は、UE100の構成を示す図である。図4に示すように、UE100は、無線通信部110と、制御部120とを備える。
無線通信部110は、アクセスリンクにおける無線通信、すなわち、gNB200との無線通信及びIABノード300との無線通信に用いられる。無線通信部110は、受信部111及び送信部112を備える。受信部111は、制御部120の制御下で各種の受信を行う。受信部111はアンテナを含み、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部120に出力する。送信部112は、制御部120の制御下で各種の送信を行う。送信部112はアンテナを含み、制御部120が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
制御部120は、UE100における各種の制御を行う。制御部120は、少なくとも1つのプロセッサ及び少なくとも1つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びCPUを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
(プロトコルスタック構成の一例)
本実施形態に係る移動通信システム1におけるプロトコルスタック構成の一例について説明する。図5は、ユーザプレーンのプロトコルスタック構成の一例を示す図である。ここでは、図1に示したUE100-3と5GC10のUPF12との間のユーザデータ伝送に関するプロトコルスタック構成の一例について説明する。
本実施形態に係る移動通信システム1におけるプロトコルスタック構成の一例について説明する。図5は、ユーザプレーンのプロトコルスタック構成の一例を示す図である。ここでは、図1に示したUE100-3と5GC10のUPF12との間のユーザデータ伝送に関するプロトコルスタック構成の一例について説明する。
図5に示すように、UPF12は、GTP-U(GPRS Tunneling Protocol for User Plane)と、UDP(User Datagram Protocol)と、IP(Internet Protocol)と、レイヤ1/レイヤ2(L1/L2)とを備える。gNB200-1(ドナーgNB)には、これらに対応するプロトコルスタックが設けられる。
また、gNB200-1は、集約ユニット(CU:Central Unit)と分散ユニット(DU:Distributed Unit)とを備える。無線インターフェイスのプロトコルスタックのうちPDCP(Packet Data Convergence Protocol)以上の各レイヤをCUが有し、RLC(Radio Link Control)以下の各レイヤをDUが有する。CU及びDUは、F1インターフェイスと称されるインターフェイスを介して接続される。
具体的には、CUは、SDAP(Service Data Adaptation Protocol)と、PDCPと、IPと、L1/L2とを備える。CUのSDAP及びPDCPは、DUと、IABノード300-1と、IABノード300-2とを介して、UE100のSDAP及びPDCPとの通信を行う。
また、DUは、無線インターフェイスのプロトコルスタックのうち、RLCと、アダプテーションレイヤ(Adapt)と、MAC(Medium Access Control)と、PHY(Physical layer)とを有する。これらのプロトコルスタックは、gNB向けのプロトコルスタックである。なお、アダプテーションレイヤ及びRLC(S-RLC)は上下関係が逆であってもよい。
IABノード300-1には、これらに対応するUE向けのプロトコルスタックST1が設けられる。さらに、IABノード300-1には、gNB向けのプロトコルスタックST2が設けられる。プロトコルスタックST1及びプロトコルスタックST2は、何れもレイヤ2以下の各レイヤ(各サブレイヤ)からなる。すなわち、IABノード300-1は、レイヤ2以下の各レイヤを用いてユーザデータの中継を行うレイヤ2中継装置である。IABノード300-1は、レイヤ3以上のレイヤ(具体的には、PDCP以上のレイヤ)を用いることなくデータ中継を行う。なお、IABノード300-2は、IABノード300-1と同様なプロトコルスタック構成を有する。
ここではユーザプレーンにおけるプロトコルスタック構成について説明した。しかしながら、制御プレーンにおいて、gNB200-1、IABノード300-1、IABノード300-2、及びUE100-3のそれぞれは、レイヤ3に相当するRRC(Radio Resource Control)を備える。
gNB200-1(ドナーgNB)のRRCとIABノード300-1のRRCとの間にRRC接続が確立され、このRRC接続を用いてRRCメッセージが送受信される。また、gNB200-1のRRCとIABノード300-2のRRCとの間にRRC接続が確立され、このRRC接続を用いてRRCメッセージが送受信される。さらに、gNB200-1のRRCとUE100-3のRRCとの間にRRC接続が確立され、このRRC接続を用いてRRCメッセージが送受信される。
(移動通信システムにおける動作)
本実施形態に係る移動通信システム1における動作について説明する。具体的には、IABノード300-1がgNB200-1(ドナーgNB)に無線で接続する場合の動作について説明する。
本実施形態に係る移動通信システム1における動作について説明する。具体的には、IABノード300-1がgNB200-1(ドナーgNB)に無線で接続する場合の動作について説明する。
かかる場合、最初に、IABノード300-1は、UE機能を用いてgNB200-1とのアクセスリンク接続(第1の無線接続)を確立する。言い換えると、IABノード300-1は、UE100として振る舞ってgNB200-1とのアクセスリンク接続を確立する。アクセスリンク接続の確立は、RRC接続の確立を含む。
次に、gNB200-1は、アクセスリンク接続を維持しつつ、IABノード300-1のgNB機能のためのバックホールリンク接続(第2の無線接続)をIABノード300-1とgNB200-1との間に確立させるメッセージをIABノード300-1に送信する。本実施形態において、かかるメッセージは、RRC接続を用いて送受信されるRRC再設定(RRC Reconfiguration)メッセージである。
その結果、バックホールリンク接続がIABノード300-1とgNB200-1との間に確立されるため、IABノード300-1とgNB200-1との間でバックホールリンクの通信を適切に開始可能とすることができる。
バックホールリンク接続を確立させるRRC再設定メッセージは、バックホールリンク接続を構成するベアラ(又はL2リンク)の設定情報、及びIABノード300-1が送信するべきセルID(具体的には、セルIDに関連付けられた参照信号及び同期信号の送信設定)を含んでもよい。以下において、かかるRRC再設定メッセージをIABノード設定メッセージと称する。
IABノード設定メッセージは、デフォルトベアラ(又はデフォルトリンク)の設定情報を含んでもよい。デフォルトベアラ(又はデフォルトリンク)は、例えば、SIB(System Information Block)の中継やUEからのMsg3中継などを行うためのベアラ(又はリンク)である。
IABノード設定メッセージは、ドナーgNB200-1側のスタックの設定情報と、オプションでIABノード300-2(又はUE100)側のスタックの設定情報とを含んでもよい。IABノード300-2(又はUE100)側のスタックの設定情報は、暗示的にドナーgNB200-1のSIBで報知されている設定群を再利用してもよいし、オペレータ(OAM)から(事前に)設定されてもよい。
IABノード設定メッセージにおける設定内容としては、基本的にRRC再設定メッセージに含まれる設定全てが対象になり得るが、RLC設定(AM:Acknowledged Mode/UM:Unacknowledged Mode/TM:Transparent Mode等の動作モード、LCP(Logical Channel Prioritization)パラメータ等)、MAC設定(BSR:Buffer Status Report/TAG:Timing Advance Group/PHR:Power Headroomパラメータ、DRX:Discontinues Reception設定等)、PHY設定が含まれてもよい。
また、IABノード設定メッセージにおける設定内容には、アダプテーションレイヤの設定(下位側又は上位側の論理チャネルのマッピング(ルーティング)設定、優先度設定等)が含まれてもよい。
さらに、IABノード設定メッセージにおける設定内容には、必要に応じて、IABノード300-1の(仮想的な)IPアドレス(すなわち、L3アドレス)を含めてもよい。これは、例えばF1インターフェイスをL2リンク上に確立するために、F1のプロトコルスタックがSCTP over IPを想定しているためである。
なお、IABノード設定メッセージにおける設定内容は、NRプロトコルの設定情報に限らず、LTEプロトコル(RLC、MAC、PHY)の設定情報であってもよい。
本実施形態において、IABノード300-1は、バックホールリンク接続を確立するよりも前に、IABノードの機能(すなわち、レイヤ2中継機能)を有すること又はバックホールリンク接続の確立を要求することを示すインディケーションをgNB200-1に送信してもよい。これにより、gNB200-1は、バックホールリンク接続を確立するためのプロシージャを適切に開始できる。以下において、かかるインディケーションをIABインディケーションと称する。IABインディケーションは、IABノード300-1におけるUE機能向けリンクプロトコルスタックをLTEで準備するのか、NRで準備するのか、もしくはその両方か、という意図又は能力を示す情報を含んでもよい。
なお、IABノード300-1は、gNB200-1とのアクセスリンク接続の確立後にIABインディケーションを送信してもよいし、gNB200-1とのアクセスリンク接続を確立するプロシージャ中にIABインディケーションを送信してもよい。
また、IABインディケーションをgNBに送信可能とする条件として、このgNBから、ドナー機能を有することを示すドナー機能識別子を含むSIBを受信しているという条件があってもよい。かかる場合、IABノード300-1は、gNB200-1からSIBによりドナー機能識別子を受信している場合に限り、gNB200-1に対してIABインディケーションを送信する。
本実施形態において、IABノード300-1とのバックホールリンク接続を確立するドナー機能をgNB200-1が有する場合がある。この場合、gNB200-1は、IABノード300-1からIABインディケーションを受信した後、IABノード設定メッセージをIABノード300-1に送信する。一方、ドナー機能をgNB200-1が有しない場合、gNB200-1は、IABノード300-1からIABインディケーションを受信した後、IABノード設定メッセージをIABノード300-1に送信することに代えて、IABノード300-1のハンドオーバを要求するハンドオーバ要求を他のgNBに送信してもよい。ここで、gNB200-1は、ドナー機能を有する他のgNBの情報を予め記憶していることが好ましい。gNB200-1は、ドナー機能を有する他のgNBの情報をIABノード300-1から取得してもよい。IABノード300-1は、5GC10(コアネットワーク)から情報を入手、もしくは隣接セルのSIB(ドナー機能識別子)を確認する。これにより、IABノード300-1は、ドナー機能を有する他のgNB(隣接セル)の情報を取得し、取得した情報をgNB200-1に通知する。gNB200-1は、記憶している情報又はIABノード300-1から取得した情報に基づいて、ドナー機能を有する他のgNBに対してハンドオーバ要求を送信する。これにより、IABノード300-1を他のgNBにハンドオーバさせた後に、IABノード300-1が当該他のgNBとのバックホールリンク接続を確立できる。或いは、ドナー機能をgNB200-1が有しない場合、IABノード300-1は、5GC10に対して、ドナー機能を有するセル(gNB)へハンドオーバさせることを要求し、5GC10がハンドオーバに係る処理を行ってもよい。
本実施形態において、gNB200-1は、IABノード300-1からIABインディケーションを受信したことに応じて、無線測定を設定する測定設定をIABノード300-1に送信してもよい。IABノード300-1は、gNB200-1から測定設定を受信した後、無線測定の結果を含む測定報告をgNB200-1に送信する。gNB200-1は、IABノード300-1からの測定報告に基づいて、自身(gNB200-1)が適切なドナーgNBであるか又は他のgNBが適切なドナーgNBであるかを判断する。例えば、gNB200-1は、測定報告に基づいて、自身(gNB200-1)に対する測定結果よりも他のgNBに対する測定結果が良好であり、かつ、これらの測定報告の差が閾値よりも大きい場合に、他のgNBが適切なドナーgNBであると判断する。そうでなければ、gNB200-1は、自身が適切なドナーgNBであると判断する。
そして、自身(gNB200-1)が適切なドナーgNB200-1であると判断した場合、gNB200-1は、IABノード設定メッセージをIABノード300-1に送信する。一方、他のgNBが適切なドナーgNBであると判断した場合、gNB200-1は、IABノード設定メッセージをIABノード300-1に送信することに代えて、IABノード300-1のハンドオーバを要求するハンドオーバ要求を当該他のgNBに送信する。これにより、IABノード300-1をより無線状態の良好な他のgNBにハンドオーバさせて、IABノード300-1が当該他のgNBとのバックホールリンク接続を確立できる。
本実施形態において、gNB200-1は、バックホールリンク接続の確立後、IABノード300-1に関するコンテキスト情報を他のgNBに送信してもよい。このコンテキスト情報は、無線側のASレイヤの接続設定(RRC再設定の内容)、ネットワーク側のPDUセッションリソース設定(AMF又はRAN(Radio Access Network)のUE ID、セッションID、QoS(Quality of Service)/スライス設定等)、その他関連情報(IABノードの挙動や通信などの履歴情報、及び/又はプリファレンス情報などを含む。
具体的には、gNB200-1は、IABノード300-1を他のgNBにハンドオーバさせるという判断を行っていなくても、IABノード300-1に関するコンテキスト情報を予め他のgNBに送信する。これにより、gNB200-1とIABノード300-1との間の無線状態が悪化し、IABノード300-1が他のgNBとの無線接続を再確立する場合に、予め共有したコンテキスト情報を用いて速やかな再確立を行うことができる。
ここで、gNB200-1は、IABノード300-1とIABノード300-1のドナーgNBの候補とを対応付けるテーブルを保持していることが好ましい。gNB200-1は、テーブル中の候補である他のgNBに対してコンテキスト情報を送信する。これにより、gNB200-1は、コンテキスト情報を適切な他のgNBと共有できる。
(1)通常動作シーケンスの一例
図6は、本実施形態に係る移動通信システム1における通常動作シーケンスの一例を示す図である。
図6は、本実施形態に係る移動通信システム1における通常動作シーケンスの一例を示す図である。
図6に示すように、ステップS101において、IABノード300-1は、例えばgNB200-1に対してランダムアクセスプロシージャを行うことにより、gNB200-1とのアクセスリンク接続(RRC接続)を確立する。IABノード300-1は、ランダムアクセスプロシージャ中にgNB200-1に送信するメッセージ(例えば、Msg3)にIABインディケーションを含めてもよい。また、gNB200-1は、ステップS101において、IABノード300-1に関するコンテキスト情報を取得する。
ステップS102において、IABノード300-1は、gNB200-1を介して、5GC10(具体的には、AMF11)に対するアタッチプロシージャを行う。ここで、IABノード300-1は、IABインディケーションのような通知(つまり、IABノードとして動作したいことを示す通知)をAMF11に通知してもよい。これにより、IABノード300-1は、AMF11から、ドナーgNB(セル)の候補リストや下位ノードの有無などのルーティング情報、その他管理情報などを入手してもよい。もしくは、AMF11からドナーgNBの各候補に対して、IABノード300-1のアタッチがあった旨や、IABノード300-1のルーティング情報などのコンテキスト情報を通知してもよい。なお、IABノード300-1が既にアタッチしている場合は、ステップS102におけるアタッチ処理を省略可能である。具体的には、IABノード300-1は、ステップS101において、RRC再確立(Reestablishment)などのように、何らかのエラー発生によってドナーgNBとの接続を再確立しなければならない場合などにおいて、アタッチ処理を省略する。
ステップS103において、IABノード300-1は、IABインディケーションをgNB200-1に送信する。IABノード300-1は、次のイベントのうち1又は複数が満たされたことをトリガとしてIABインディケーションを送信してもよい。
・Msg5(RRC Complete)を送信する際。
・gNBとの接続が確立した際(Msg5以降でもよい。例えば最初のRRC再設定が行われた際)。
・AMFからIAB設定情報(上記参照)を入手した際(既にIAB設定情報を持っている場合も含む)。
・単純にIABノードとして動作したくなった際(上位レイヤからIABノードとして動作する指示を受信したことを含む)。
・下位のIABノード300-2又はUE100-3からIABノードとなるように要求された場合(その旨の要求を示す信号を下位のIABノード300-2又はUE100-3から受信した場合)。
・下位のIABノード300-2又はUE100-3が既に接続している場合。
IABノード300-1は、例えばgNB200-1に送信するRRCメッセージにIABインディケーションを含める。かかるRRCメッセージは、UEとしての能力を示す「UE Capability Information」メッセージであってもよい。但し、ステップS101においてIABインディケーションを送信している場合、ステップS103は省略可能である。
或いは、IABインディケーションは、AMF11からPDUセッションリソースの変更という形でgNB200-1に通知されてもよい。なお、AMFは、IAB管理用(専用)のAMFであってもよい。
本通常動作シーケンスにおいては、gNB200-1がドナー能力を有すると仮定して説明を進める。gNB200-1は、IABインディケーションに基づいて、バックホールリンク接続をIABノード300-1に確立させる必要があると判断する。
ステップS104において、gNB200-1は、無線測定を設定する測定設定をIABノード300-1に送信する。IABノード300-1は、測定設定に基づいて無線測定を行う。例えば、IABノード300-1は、現在のサービングセルであるgNB200-1のセルと、隣接セルであるgNB200-2のセルとに対して受信電力(セル固有参照信号の受信電力)の測定を行う。
ステップS105において、IABノード300-1は、無線測定の結果を含む測定報告をgNB200-1に送信する。gNB200-1は、測定報告に基づいて、自身(gNB200-1)が適切なドナーgNBであるか又は他のgNBが適切なドナーgNBであるかを判断する。ここでは、gNB200-1が、自身(gNB200-1)が適切なドナーgNBであると判断したと仮定して説明を進める。なお、ステップS104及びステップS105の処理は必須ではなく、省略してもよい。
ステップS106において、gNB200-1は、IABノード設定メッセージ(RRC再設定メッセージ)をIABノード300-1に送信する。IABノード設定メッセージは、gNB200-1のセル(すなわち、IABノード300-1の現在のサービングセル)をハンドオーバ先として指定するハンドオーバ指示を含んでもよい。IABノード300-1は、IABノード設定メッセージに基づいて、バックホールリンク接続をgNB200-1と確立する処理を行う。かかる確立処理は、IABノード設定メッセージ中の設定情報に基づいて、バックホールリンク用のプロトコルスタック(アダプテーション/RLC/MAC/PHYエンティティ)を生成したり、パラメータ設定したりする処理を含む。かかる確立処理は、UE側(のアクセスリンク用)のプロトコルスタックを準備して、同期信号やセル固有参照信号の送信を開始する処理(もしくは、開始する準備をする処理)を含んでもよい。
ステップS107において、IABノード300-1は、バックホールリンク接続の確立を含むIABノード設定が完了したことを示す完了通知メッセージをgNB200-1に送信する。ステップS107以降は、IABノード300-1はgNB200-1に対してUEとして振る舞うのではなく、IABノードとして振る舞う。
ステップS108において、gNB200-1は、ステップS101において取得したコンテキスト情報を、Xnインターフェイス上でgNB200-2に転送する。gNB200-1は、IABノード300-1とIABノード300-1のドナーgNBの候補とを対応付けるテーブルを保持しており、このテーブルを参照してコンテキスト転送先を決定する。このようにして、gNB200-1が、他のgNBに対してコンテキストを事前に転送しておけば、IABノード300-1と接続しているgNBとの無線接続状態が悪化した場合に、直ぐに、当該他のgNBとの再接続を確立することができる。図7は、コンテキスト転送先を決定するためのテーブルの一例を示す図である。かかるテーブルは、例えばオペレータにより各gNBに対して予め設定される。図7に示すように、テーブルにおいて、IABノードごとに、そのドナーgNBの候補が対応けられている。具体的には、IABノードに関する識別子ごとに、そのドナーgNBの候補の識別子が対応けられている。例えば、IABノードに地理的に近いgNBがそのIABノードのドナーgNBの候補として設定される。なお、図7のテーブルは、gNBとの対応付けの例を示したが、セルIDとの対応付けであってもよい。セルIDは、物理レイヤセルIDでもよく、グローバルセルIDでもよい。なお、gNB200-1は、IABノード300-1から受信した測定報告に基づいて、IABノード300-1に地理的に近いgNB200-1をドナー候補として決定してもよい。gNB200-1は、当該決定したドナー候補に基づいて、IABノード300-1と当該IABノード300-1のドナーgNBの候補とを対応付けるテーブルを作成又は既存のテーブルを更新してもよい。
ステップS109において、gNB200-1は、IABノード300-1とのバックホールリンク接続を確立したことを示す通知を5GC10に送信する。もしくは、gNB200-1は、IABノード用のPDUセッションの確立要求を5GC10に送信してもよい。なお、上述したように、PDUセッションの確立要求は、ステップS109よりも先に又はステップS109においてAMF11からgNB200-1に送信されてもよい。
(2)例外動作シーケンスの一例
図8は、本実施形態に係る移動通信システム1における例外動作シーケンスの一例を示す図である。例外動作シーケンスにおいて、gNB200-1は、IABノード300-1をgNB200-2にハンドオーバさせる。
図8は、本実施形態に係る移動通信システム1における例外動作シーケンスの一例を示す図である。例外動作シーケンスにおいて、gNB200-1は、IABノード300-1をgNB200-2にハンドオーバさせる。
図8に示すように、ステップS201において、IABノード300-1は、例えばgNB200-1に対してランダムアクセスプロシージャを行うことにより、gNB200-1とのアクセスリンク接続(RRC接続)を確立する。IABノード300-1は、ランダムアクセスプロシージャ中にgNB200-1に送信するメッセージ(例えば、Msg3)にIABインディケーションを含めてもよい。また、gNB200-1は、ステップS201において、IABノード300-1に関するコンテキスト情報を取得する。
ステップS202において、IABノード300-1は、gNB200-1を介して、5GC10(具体的には、AMF11)に対するアタッチプロシージャを行う。
ステップS203において、IABノード300-1は、IABインディケーションをgNB200-1に送信する。IABノード300-1は、例えばgNB200-1に送信するRRCメッセージにIABインディケーションを含める。かかるRRCメッセージは、UEの能力を示す「UE Capability Information」メッセージであってもよい。但し、ステップS201においてIABインディケーションを送信している場合、ステップS203は省略可能である。
ステップS204において、gNB200-1は、自身がドナー能力を有するか否かを判断する。gNB200-1がドナー能力を有しない場合(ステップS204:NO)、gNB200-1は、処理をステップS208に進める。
gNB200-1がドナー能力を有する場合(ステップS204:YES)、ステップS205において、gNB200-1は、無線測定を設定する測定設定をIABノード300-1に送信する。IABノード300-1は、測定設定に基づいて無線測定を行う。例えば、IABノード300-1は、現在のサービングセルであるgNB200-1のセルと、隣接セルであるgNB200-2のセルとに対して受信電力(セル固有参照信号の受信電力)の測定を行う。
ステップS206において、IABノード300-1は、無線測定の結果を含む測定報告をgNB200-1に送信する。
ステップS207において、gNB200-1は、測定報告に基づいて、自身(gNB200-1)が適切なドナーgNBであるか又は他のgNBが適切なドナーgNBであるかを判断する。自身(gNB200-1)が適切なドナーgNBであると判断した場合(ステップS207:YES)、gNB200-1は、上述した通常動作シーケンス(図6参照)のステップS106に処理を進める。
一方、他のgNBが適切なドナーgNBであると判断した場合(ステップS207:NO)、gNB200-1は、ステップS208に処理を進める。
ステップS208において、gNB200-1は、IABノード300-1から受信したIABインディケーションを含むハンドオーバ要求メッセージをXnインターフェイス上でgNB200-2に転送する。gNB200-1は、ステップS201において取得したコンテキスト情報をハンドオーバ要求メッセージに含めてもよい。または、gNB200-1は、ハンドオーバ要求メッセージに、IABインディケーションを含める代わりに、IABノード300-1がgNBに対してドナーgNBとして機能することを要求する旨を示す情報を含めて送信してもよい。なお、ステップS208において、gNB200-1は、gNB200-2がドナー能力を有すると判断した上で、ハンドオーバ要求メッセージをXnインターフェイス上でgNB200-2に転送してもよい。具体的には、例えば、gNB200-1は、図7に示すテーブルにおいて、IABノード300-1にドナー候補としてgNB200-2が対応付けられていると判断した場合に、ハンドオーバ要求メッセージをgNB200-2に対して転送してもよい。この場合、gNB200-2がハンドオーバ要求を拒否する可能性が低減されるため、IABノード300-1のハンドオーバをより早急に実行することができる。または、互いに隣接する複数のgNB200間でXnインターフェイスを介して、自身のドナー能力に関する情報を事前に共有してもよい。これによって、gNB200-1は、ドナー能力を有する隣接のgNB200を特定することができ、当該特定した隣接のgNB200に対してハンドオーバ要求メッセージを転送することができる。
gNB200-2は、ハンドオーバ要求メッセージに含まれるIABインディケーションも考慮して、IABノード300-1のハンドオーバを受け入れるか否かを判断する。gNB200-2は、自身がドナー能力を有しない場合には、ハンドオーバ要求を拒否してもよい。ここではgNB200-2がIABノード300-1のハンドオーバを受け入れると判断したと仮定して説明を進める。
ステップS209において、gNB200-2は、ハンドオーバ肯定応答メッセージをXnインターフェイス上でgNB200-1に送信する。
ステップS210において、gNB200-1は、gNB200-2からのハンドオーバ肯定応答メッセージに基づいて、ハンドオーバ指示メッセージ(RRC再設定メッセージ)をIABノード300-1に送信する。ハンドオーバ指示メッセージは、ハンドオーバ先のgNB200-2(のセル)を指定する情報を含む。
ステップS211において、IABノード300-1は、gNB200からのハンドオーバ指示メッセージに基づいて、gNB200-2へのハンドオーバを行う。
(3)マルチホップ接続シーケンスの一例
図9は、本実施形態に係る移動通信システム1におけるマルチホップ接続シーケンスの一例を示す図である。マルチホップ接続シーケンスは、IABノード300-1とgNB200-1との間にバックホールリンク接続が接続された後において、IABノード300-1にIABノード300-2又はUE100-2が接続する場合のシーケンスである。ここではIABノード300-1にIABノード300-2が接続する場合について主として説明するが、IABノード300-2をUE100-2と適宜読み替えてもよい。また、上述した「(1)通常動作シーケンス」と重複する説明を省略する。
図9は、本実施形態に係る移動通信システム1におけるマルチホップ接続シーケンスの一例を示す図である。マルチホップ接続シーケンスは、IABノード300-1とgNB200-1との間にバックホールリンク接続が接続された後において、IABノード300-1にIABノード300-2又はUE100-2が接続する場合のシーケンスである。ここではIABノード300-1にIABノード300-2が接続する場合について主として説明するが、IABノード300-2をUE100-2と適宜読み替えてもよい。また、上述した「(1)通常動作シーケンス」と重複する説明を省略する。
図9に示すように、ステップS301において、IABノード300-2は、IABノード300-1を介してgNB200-1に対してランダムアクセスプロシージャを行うことにより、gNB200-1とのアクセスリンク接続(RRC接続)を確立する。IABノード300-2は、ランダムアクセスプロシージャ中にgNB200-1に送信するメッセージ(例えば、Msg3)にIABインディケーションを含めてもよい。また、gNB200-1は、ステップS301において、IABノード300-2に関するコンテキスト情報を取得する。
ステップS302において、IABノード300-2は、IABノード300-2及びgNB200-1を介して、5GC10(具体的には、AMF11)に対するアタッチプロシージャを行う。ここで、IABノード300-2は、IABインディケーションのような通知(つまり、IABノードとして動作したいことを示す通知)をAMF11に通知してもよい。これにより、IABノード300-2は、AMF11から、ドナーgNB(セル)の候補リストや下位ノードの有無などのルーティング情報、その他管理情報などを入手してもよい。もしくは、AMF11からドナーgNBの各候補に対して、IABノード300-2のアタッチがあった旨や、IABノード300-2のルーティング情報などのコンテキスト情報を通知してもよい。なお、IABノード300-2が既にアタッチしている場合は、ステップS302におけるアタッチ処理を省略可能である。具体的には、IABノード300-2は、RRC再確立(Reestablishment)などのように、何らかのエラー発生によってドナーgNBとの接続を再確立しなければならない場合などにおいて、アタッチ処理を省略する。
ステップS303において、IABノード300-2は、IABノード300-1を介してIABインディケーションをgNB200-1に送信する。IABノード300-2は、上述した「(1)通常動作シーケンス」のステップS103において説明したトリガと同様なトリガに応じてIABインディケーションを送信してもよい。
IABノード300-2は、例えばgNB200-1に送信するRRCメッセージにIABインディケーションを含める。かかるRRCメッセージは、UEとしての能力を示す「UE Capability Information」メッセージであってもよい。但し、ステップS301においてIABインディケーションを送信している場合、ステップS303は省略可能である。
或いは、IABインディケーションは、AMF11からPDUセッションリソースの変更という形でgNB200-1に通知されてもよい。なお、AMFは、IAB管理用(専用)のAMFであってもよい。
本動作シーケンスにおいては、gNB200-1がドナー能力を有すると仮定している。そのため、gNB200-1は、IABインディケーションに基づいて、バックホールリンク接続をIABノード300-1とIABノード300-2との間に確立させる必要があると判断する。
ステップS304において、gNB200-1は、無線測定を設定する測定設定をIABノード300-2に送信する。IABノード300-2は、測定設定に基づいて無線測定を行う。
ステップS305において、IABノード300-2は、無線測定の結果を含む測定報告を、IABノード300-1を介してgNB200-1に送信する。gNB200-1は、測定報告に基づいて、自身(gNB200-1)が適切なドナーgNBであるか又は他のgNBが適切なドナーgNBであるかを判断する。ここでは、gNB200-1が、自身(gNB200-1)が適切なドナーgNBであると判断したと仮定して説明を進める。なお、ステップS304及びステップS305の処理は必須ではなく、省略してもよい。
ステップS306において、gNB200-1は、IABノード設定メッセージ(RRC再設定メッセージ)をIABノード300-2に送信する。IABノード300-2は、IABノード設定メッセージに基づいて、バックホールリンク接続をIABノード300-1と確立する処理を行う。かかる確立処理は、IABノード設定メッセージ中の設定情報に基づいて、バックホールリンク用のプロトコルスタック(アダプテーション/RLC/MAC/PHYエンティティ)を生成したり、パラメータ設定したりする処理を含む。かかる確立処理は、UE側(のアクセスリンク用)のプロトコルスタックを準備して、同期信号やセル固有参照信号の送信を開始する処理(もしくは、開始する準備をする処理)を含んでもよい。
ステップS307において、gNB200-1は、RRC再設定メッセージをIABノード300-1に送信する。かかるRRC再設定メッセージは、IABノード300-2の追加に伴ってIABノード300-1における設定を変更するためのメッセージである。かかるRRC再設定メッセージは、例えば、IABノード300-2の論理チャネルとIABノード300-1のバックホールリンクの論理チャネルとの対応付けを示すマッピング情報を含む。なお、ステップS307は、ステップS306の前であってもよいし、ステップS306と同時であってもよい。
ステップS308において、IABノード300-2は、IABノード300-1とのバックホールリンク接続の確立を含むIABノード設定が完了したことを示す完了通知メッセージをgNB200-1に送信する。ステップS308以降は、IABノード300-2はgNB200-1に対してUEとして振る舞うのではなく、IABノードとして振る舞う。
ステップS309において、IABノード300-1は、IABノード300-2とのバックホールリンク接続の確立に伴う設定変更が完了したことを示す完了通知メッセージをgNB200-1に送信する。なお、ステップS309は、ステップS308の前であってもよいし、ステップS308と同時であってもよい。
ステップS310において、gNB200-1は、ステップS301において取得したIABノード300-2のコンテキスト情報を、Xnインターフェイス上でgNB200-2に転送する。
ステップS311において、gNB200-1は、IABノード300-2のバックホールリンク接続を確立したことを示す通知を5GC10に送信する。もしくは、gNB200-1は、IABノード300-2用のPDUセッションの確立要求を5GC10に送信してもよい。なお、上述したように、PDUセッションの確立要求は、ステップS311よりも先に又はステップS311においてAMF11からgNB200-1に送信されてもよい。
[第1実施形態の変更例]
上述した第1実施形態において、IABノード300-1がgNB200-1に無線で接続した後に、gNB200-1がドナー能力を有しないことに応じてIABノード300-1をハンドオーバさせる一例について説明した。しかしながら、各gNB200は、自身がドナー能力を有するか否かに関する情報をIABノード300-1に提供してもよい。これにより、IABノード300-1は、ドナー能力を有するgNB200を選択したうえで接続することが可能になる。例えば、ドナー能力を有するgNB200は、ドナー能力を有することを示す情報をシステム情報ブロック(SIB)に含めてブロードキャストする。IABノード300-1は、かかるSIBに基づいて、接続先とするgNB200を選択する。IABノード300-1は、ドナー能力を有するgNB200であって、且つ、このgNB200からの受信電力が閾値以上である場合に、このgNB200を接続先として選択してもよい。または、gNB200がドナー能力を有しない場合には、IABノード300-1は、gNB200から送信されたSIBを受信したことに応じて、他のgNB200を再選択してもよい。その後、他のgNB200から送信されたSIBにより当該他のgNB200がドナー能力を有することが示される場合には、IABノード300-1は、当該他のgNB200を接続先として、ランダムアクセスプロシージャを行うと共にIABインディケーションを送信してもよい。
上述した第1実施形態において、IABノード300-1がgNB200-1に無線で接続した後に、gNB200-1がドナー能力を有しないことに応じてIABノード300-1をハンドオーバさせる一例について説明した。しかしながら、各gNB200は、自身がドナー能力を有するか否かに関する情報をIABノード300-1に提供してもよい。これにより、IABノード300-1は、ドナー能力を有するgNB200を選択したうえで接続することが可能になる。例えば、ドナー能力を有するgNB200は、ドナー能力を有することを示す情報をシステム情報ブロック(SIB)に含めてブロードキャストする。IABノード300-1は、かかるSIBに基づいて、接続先とするgNB200を選択する。IABノード300-1は、ドナー能力を有するgNB200であって、且つ、このgNB200からの受信電力が閾値以上である場合に、このgNB200を接続先として選択してもよい。または、gNB200がドナー能力を有しない場合には、IABノード300-1は、gNB200から送信されたSIBを受信したことに応じて、他のgNB200を再選択してもよい。その後、他のgNB200から送信されたSIBにより当該他のgNB200がドナー能力を有することが示される場合には、IABノード300-1は、当該他のgNB200を接続先として、ランダムアクセスプロシージャを行うと共にIABインディケーションを送信してもよい。
或いは、各gNB200は、自身がドナー能力を有することをSIBにより通知することに加えて、又は自身がドナー能力を有することをSIBにより通知することに代えて、自身がIABノード300を取り扱う能力を有することをSIBにより通知してもよい。例えば、各gNB200は、自身がIABノード300を他のgNB(ドナーgNB)にハンドオーバする機能を有することをSIBにより通知してもよい。
上述した第1実施形態において、IABノード300がランダムアクセスプロシージャ中にgNB200に送信するメッセージ(例えば、Msg3)にIABインディケーションを含める一例について説明した。ここで、Msg3は、例えばRRC Setup Requestメッセージである。また、IABノード300は、Msg3中のフィールド(情報要素)であるEstablishment CauseにIABインディケーションを含めてもよい。
或いは、IABノード300は、ランダムアクセスプロシージャ中にgNB200に送信するランダムアクセスプリアンブル(Msg1)を利用して、IABインディケーションを通知してもよい。例えば、IABインディケーション用のPRACH(Physical Random Access Channel)リソースがSIBにより通知される場合、IABノード300は、通知されたIABインディケーション用のPRACHリソースの中から選択したPRACHリソースを用いてランダムアクセスプリアンブルを送信する。これにより、IABノード300は、IABインディケーションを通知してもよい。ここで、PRACHリソースとは、時間・周波数リソースであってもよいし、信号系列(プリアンブル系列)であってもよい。
或いは、IABノード300は、ランダムアクセスプロシージャ以外のタイミングでIABインディケーションを通知してもよい。例えば、IABノード300は、UE Assistance Informationメッセージ等のRRCメッセージにIABインディケーションを含めてもよい。
上述した第1実施形態において、gNB200が、無線測定を設定する測定設定をIABノード300又はUE100に送信し、無線測定の結果を含む測定報告を受信することにより、自身(gNB200)が適切なドナーgNBであるか又は他のgNBが適切なドナーgNBであるかを当該測定報告に基づいて判断する一例について説明した。しかしながら、gNB200は、このような初期接続時に測定結果を利用する場合に限らず、ネットワークトポロジの変更やデータ転送経路の変更に測定報告を利用してもよい。
[第2実施形態]
第2実施形態について、上述した第1実施形態との相違点を主として説明する。本実施形態は、上述した第1実施形態と併用して実施してもよいし、上述した第1実施形態とは別に実施してもよい。
第2実施形態について、上述した第1実施形態との相違点を主として説明する。本実施形態は、上述した第1実施形態と併用して実施してもよいし、上述した第1実施形態とは別に実施してもよい。
IABノード300の直下の下位装置は、IABノード300との無線リンク障害(RLF)を検知した場合、他のセルを再選択し、再選択したセルに対して接続の再確立を試みる。しかしながら、RLFは、基本的には下りリンクの受信状態に基づいて検知されるため、IABノード300は、下位装置がRLFを検知したことを把握できない可能性がある。
ここで、RLFに関連する下位装置の一般的な動作について説明する。図10に示すように、下位装置は、N310回連続して同期外れ状態(out-of-sync)を検知した場合、無線問題(radio problem)を検知する。下位装置は、無線問題を検知すると、所定のタイマT310を開始させる。下位装置は、タイマT310を開始させた後、N311回連続して同期状態(in-sync)を検知した場合、タイマT310を停止させる。下位装置は、タイマT310が満了すると、RLFを検知するとともに、タイマT311を開始し、且つセル再選択動作(接続再確立処理)を開始する。そして、下位装置は、接続再確立に成功せずにタイマT311が満了すると、RRCアイドルモードに遷移する。
図11は、第2実施形態に係るIABノード300の動作を示す図である。
図11に示すように、ステップS601において、IABノード300は、自身の直下の下位装置から定期的に送信される上りリンク信号を受信する。下位装置とは、UE100、又はUE100とIABノード300との間に介在する他のIABノードをいう。上りリンク信号は、定期的に送信可能な信号であればよい。例えば、上りリンク信号は、MAC CE(例えば、バッファ状態報告)、RRCメッセージ(例えば、測定報告メッセージ)、及び/又は上りリンク参照信号を利用できる。
ステップS602において、IABノード300は、下位装置からの上りリンク信号の受信に応じて、タイマを開始させる。このタイマに設定されるタイマ値は、ドナーgNB200-1から設定された値であってもよい。タイマ値は、下位装置が上りリンク信号を送信する周期よりも長い時間であってもよい。
タイマを開始させた後、IABノード300は、下位装置から上りリンク信号を受信した場合(ステップS603:YES)、ステップS604において、タイマを停止させる。この場合、処理がステップS602に戻り、タイマを再開させる。
一方、下位装置から上りリンク信号を受信することなく(ステップS603:NO)、タイマが満了した場合(ステップS605:YES)、ステップS606において、IABノード300は、下位装置がRLFを検知したと判断する。IABノード300は、自身の下位装置がRLFを検知したと判断した場合、自身の上位装置に対して、この下位装置に対応する無線ベアラ(バックホールリンク)の解放を要求してもよい。
第2実施形態によれば、下位装置においてRLFが検知されたことをIABノード300が把握できる。
図12は、第2実施形態に係る動作シーケンスの一例を示す図である。図12に示す例において、IABノード300-2は、下位装置としてのUE100-3と、上位装置としてのIABノード300-1とに無線で接続しており、UE100-3とIABノード300-1との間の通信を無線で中継する。IABノード300-2において、基地局機能部(DU)はUE100-3と無線で接続し、ユーザ装置機能部(MT)はIABノード300-1と無線で接続する。
但し、下位装置は、IABノードであってもよい。また、IABノード300-2は、IABノード300-1を介さずにドナー装置(gNB200-1)に無線で接続していてもよい。この場合、上位装置とドナー装置とが同じ装置になる。
図12に示すように、ステップS611において、IABノード300-2の基地局機能部(DU)は、UE100-3との無線リンク障害(RLF)を検知する。このようなRLFはIABノード300-2の観点で、フロントホール(Fronthaul)RLFと呼ばれてもよい。
RLFの検知方法は、上述した方法以外に、UE100-3からのACK/NACKに基づく方法を用いることができる。具体的には、IABノード300-2の基地局機能部(DU)は、例えば下りリンクのHARQ再送を行っても、ACKやNACKがUE100-3から返ってこない場合、UE100-3とのRLFを検知する。
ステップS612において、IABノード300-2の基地局機能部(DU)は、UE100-3とのRLFを検知したことを示す状態情報(RLF通知)をIABノード300-2のユーザ装置機能部(MT)に通知する。この状態情報(RLF通知)は、UE100-3に関する識別子、例えばUE識別子及び/又はベアラ識別子を含んでもよい。
ステップS613において、IABノード300-2のユーザ装置機能部(MT)は、状態情報(RLF通知)を含むRRCメッセージを、IABノード300-1を介してドナーgNB200-1に送信する。ドナーgNB200-1は、このRRCメッセージに含まれる状態情報(RLF通知)に基づいて、UE100-3に対応するベアラを解放してもよい。
図12に示すシーケンスを次のように変更してもよい。
具体的には、ステップS612において、IABノード300-2の基地局機能部(DU)は、UE100-3とのRLFを検知したことを示す状態情報(RLF通知)をIABノード300-2のF1-APエンティティに通知する。この状態情報(RLF通知)は、UE100-3に関する識別子、例えばUE識別子及び/又はベアラ識別子を含んでもよい。F1-APエンティティとは、フロントホールのインターフェイスであるF1インターフェイス上でドナーgNB200-1との通信を行う通信機能部をいう。
ステップS613において、IABノード300-2のユーザ装置機能部(MT)は、状態情報(RLF通知)を含むF1-APメッセージを、IABノード300-1を介してドナーgNB200-1に送信する。ドナーgNB200-1は、このF1-APメッセージに含まれる状態情報(RLF通知)に基づいて、UE100-3に対応するベアラを解放してもよい。
図12に示すシーケンスを次のように変更してもよい。
具体的には、ステップS611において、IABノード300-2の基地局機能部(DU)は、自身の配下の全ての下位装置がRRCアイドル状態又はRRCインアクティブ状態に遷移したことを検知する。
ステップS612において、IABノード300-2の基地局機能部(DU)は、自身の配下の全ての下位装置がRRCアイドル状態又はRRCインアクティブ状態に遷移したことを示す状態情報をIABノード300-2のユーザ装置機能部(MT)又はF1-APエンティティに通知する。
ステップS613において、IABノード300-2のユーザ装置機能部(MT)又はF1-APエンティティは、基地局機能部(DU)からの状態情報に基づいて、自身のRRC接続を解放可能であることを示すRAI(Release Assistance Indication)を、IABノード300-1を介してドナーgNB200-1に送信する。ドナーgNB200-1は、このRAIに基づいて、UE100-3のRRC接続を解放してもよい。
[第2実施形態の変更例]
第2実施形態において、IABノード300-2は、自身と下位装置との間のRLFをドナーgNB200-1に通知していた。しかしながら、下位装置が他のIABノードとの間で検知したRLFをドナーgNB200-1に通知してもよい。
第2実施形態において、IABノード300-2は、自身と下位装置との間のRLFをドナーgNB200-1に通知していた。しかしながら、下位装置が他のIABノードとの間で検知したRLFをドナーgNB200-1に通知してもよい。
図13は、第2実施形態の変更例に係る動作シーケンスを示す図である。図13において、IABノード300-2とドナーgNB200-1との間に他のIABノードが介在してもよい。
図13に示すように、ステップS621において、IABノード300-2の基地局機能部(DU)は、IABノード300-2に接続する下位装置(UE100-3)から、IABノード300-3とのRLFの発生を示す通知を受信する。この通知は、RRC Reestablishmentメッセージ又はRLF Indicationであってもよい。
例えば、UE100-3は、IABノード300-3とのRLFを検知し、IABノード300-2との接続再確立を行う。ここで、UE100-3は、RRC ReestablishmentメッセージをIABノード300-2に送信する。このRRC Reestablishmentメッセージは、UE100-3の識別子だけではなく、UE100-3がIABノード300-3に接続していたことを示す情報(IABノード300-3の識別子であってもよい)、及び/又は、UE100-3がIABノード300-3を介して接続していたドナー装置の識別子等を含んでもよい。
或いは、UE100-3は、IABノード300-3及び300-2と同時に接続するデュアルコネクティビティ(DC)通信中に、IABノード300-3とのRLFを検知し、このRLFに関するRLF IndicationをIABノード300-2に送信する。IABノード300-3がマスタノード(MN)として設定されていた場合、このRLF Indicationは、MCG(Master Cell Group) RLF Indicationと呼ばれてもよい。RLF Indicationは、UE100-3の識別子、IABノード300-3の識別子、UE100-3がIABノード300-3を介して接続していたドナー装置の識別子等を含んでもよい。
ステップS622において、IABノード300-2の基地局機能部(DU)は、ステップS621でUE100-3から受信した通知に含まれる情報を、IABノード300-2の端末機能部(MT)又はF1-APエンティティに通知する。
ステップS623において、IABノード300-2の端末機能部(MT)又はF1-APエンティティは、基地局機能部(DU)から通知された情報を含むメッセージをドナーgNB200-1に送信する。このメッセージは、RRCメッセージ又はF1-APメッセージである。
ドナーgNB200-1は、受信したメッセージに含まれる情報に基づいて、UE100-3が他のドナー装置の配下にあった、すなわち、他のドナー装置のトポロジに属していたと判定した場合、当該他のドナー装置に対して通知を行ってもよい。この通知は、UE100-3の識別子及びIABノード300-3の識別子のうち少なくとも一方を含んでもよい。
[第3実施形態]
第3実施形態について、上述した第1実施形態及び第2実施形態との相違点を主として説明する。本実施形態は、上述した第1実施形態及び第2実施形態と併用して実施してもよいし、上述した第1実施形態及び第2実施形態とは別に実施してもよい。
第3実施形態について、上述した第1実施形態及び第2実施形態との相違点を主として説明する。本実施形態は、上述した第1実施形態及び第2実施形態と併用して実施してもよいし、上述した第1実施形態及び第2実施形態とは別に実施してもよい。
図14は、第3実施形態に係る動作を示す図である。図14において、「DU」は基地局機能に相当し、「MT」はユーザ装置機能に相当する。
図14に示すように、UE100-3は、ステップS701乃至S705の手順により上りリンクデータ(PDU)をIABノード300-2に送信する。具体的には、UE100-3は、スケジューリング要求(SR)をIABノード300-2に送信し(ステップS701)、BSR送信用の上りリンク無線リソースの割り当てを受け(ステップS702)、BSRを送信し(ステップS703)、上りリンクデータ送信用の上りリンク無線リソースの割り当てを受け(ステップS704)、上りリンクデータをIABノード300-2に送信する(ステップS705)。
同様にして、IABノード300-2は、ステップS706乃至S710の手順により上りリンクデータ(PDU)をIABノード300-1に送信する。
また、IABノード300-1は、ステップS711乃至S715の手順により上りリンクデータ(PDU)をドナーgNB200-1に送信する。
本シーケンスにおいて、各IABノード300は、上りリンク無線リソースの割り当てを要求する第1スケジューリング要求を下位装置から受信する。そして、各IABノード300は、上りリンクデータ(PDU)を下位装置から受信するよりも前において、第2スケジューリング要求を上位装置に送信する。
一般的に、スケジューリング要求は、送信するべき上りリンクデータを有する場合にトリガされるが、本実施形態では、送信するべき上りリンクデータを未だ有していない段階でスケジューリング要求をトリガしている。これにより、円滑な上りリンク無線リソースの割り当てを実現できる。
例えば、ステップS706において、IABノード300-2は、UE100-3からBSRを受信(ステップS703)した際に、スケジューリング要求をIABノード300-1に送信する。
IABノード300-2は、UE100-3からスケジューリング要求を受信(ステップS701)した後、UE100-3からBSRを受信(ステップS703)する前に、スケジューリング要求をIABノード300-1に送信してもよい。
IABノード300-2は、UE100-3からスケジューリング要求を受信(ステップS701)した後、UE100-3に上りリンク無線リソースを割り当てた際(ステップS702)に、スケジューリング要求をIABノード300-1に送信(トリガ)してもよい。
IABノード300-2は、UE100-3からスケジューリング要求を受信した際(ステップS701)に、スケジューリング要求をIABノード300-1に送信(トリガ)してもよい。
本実施形態において、各IABノード300は、当該IABノード300が上りリンク送信に利用可能なデータの量を少なくとも示す第1のバッファ状態報告を上位装置に送信する。ここで、上位装置とは、ドナーgNB200の配下の他のIABノード(上位IABノード)又はドナーgNB200である。上位装置は、第1のバッファ状態報告に基づいて、上りリンク送信用の無線リソースをIABノード300に割り当てる。
IABノード300は、上りリンク送信待ちのデータを一時的に記憶する上りリンクバッファを有する。例えば、IABノード300のMACレイヤは、当該上りリンクバッファ内のデータ量を示す情報を含む第1のバッファ状態を上位装置のMACレイヤに通知する。上位装置のMACレイヤはスケジューラを有しており、第1のバッファ状態に基づいて上りリンク無線リソースをIABノード300に割り当て、制御チャネルを介して割当リソースをIABノード300に通知する。
ここで、IABノード300は、複数のUE分の上りリンクデータをバッファリングするため、UE100に比べて大容量の上りリンクバッファを有すると考えられる。よって、IABノード向けのバッファ状態報告は、UE向けのバッファ状態報告とは異なるフォーマットを有していてもよい。また、IABノード向けのバッファ状態報告が表現可能なデータ量(最大データ量)は、UE向けのバッファ状態報告が表現可能なデータ量(最大データ量)よりも大きくてもよい。
IABノード向けのバッファ状態報告は、IABノード300の配下のUE100の数に関する情報を含んでもよい。IABノード300は、自身の配下のUE100の数をUEコンテキストやC-RNTI(Cell-Radio Network Temporary Identifier)等に基づいて判断してもよいし、自身の配下のUE100の数をドナーgNB200から通知されてもよい。IABノード300は、自身の配下のUE100のうち、自身の上りリンクバッファ内にデータがあるUE100の数をバッファ状態報告に含めてもよい。言い換えると、IABノード300は、自身がいくつのUE分の上りリンクデータを持っているかをバッファ状態報告により上位装置に通知してもよい。或いは、IABノード300は、自身の配下のUE100のうち、RRCコネクティッド状態にあるUE100の数をバッファ状態報告に含めてもよい。
IABノード向けのバッファ状態報告は、IABノード300の上りリンクバッファ内に実際に存在するデータの量だけではなく、下位装置からのバッファ状態報告(すなわち、潜在的な上りリンクデータ量)が加味されてもよい。これにより、上位装置は、潜在的な上りリンクデータ量を考慮して、上りリンク無線リソースを予めIABノード300に割り当てておくことができるため、マルチホップに起因する上りリンクの伝送遅延を抑制できる。
IABノード300は、下位装置から、下位装置が上りリンク送信に利用可能なデータの量を示す第2のバッファ状態報告を受信する。IABノード300は、第2のバッファ状態報告に基づいて、自身が上りリンク送信に利用可能なデータの量と下位装置が上りリンク送信に利用可能なデータの量とに基づく第1のバッファ状態報告を上位装置に送信する。例えば、IABノード300は、自身が上りリンク送信に利用可能なデータの量と下位装置が上りリンク送信に利用可能なデータの量との合計値を第1のバッファ状態報告に含めてもよい。或いは、IABノード300は、自身が上りリンク送信に利用可能なデータの量を示す第1のBSR値と、下位装置が上りリンク送信に利用可能なデータの量を示す第2のBSR値とを別々に第1のバッファ状態報告に含めてもよい。
なお、IABノード300が上りリンク送信に利用可能なデータ量とは、自身の送信バッファ(MTのバッファ)のデータ量、自身の受信バッファ(DU)のデータ量、及び/又はアダプテーションエンティティのバッファ量を含んでもよい。
[第4実施形態]
第4実施形態について、上述した第1実施形態乃至第3実施形態との相違点を主として説明する。本実施形態は、上述した第1実施形態乃至第3実施形態と併用して実施してもよいし、上述した第1実施形態乃至第3実施形態とは別に実施してもよい。
第4実施形態について、上述した第1実施形態乃至第3実施形態との相違点を主として説明する。本実施形態は、上述した第1実施形態乃至第3実施形態と併用して実施してもよいし、上述した第1実施形態乃至第3実施形態とは別に実施してもよい。
図15は、第4実施形態に係るIABノード300の動作を示す図である。
図15に示すように、IABノード300は、バックホールリンクを介して上位装置Aと無線で接続している。上位装置Aは、上位IABノード又はドナーgNB(ドナー装置)である。
IABノード300には下位装置B1及びB2が接続しており、下位装置B2には下位装置B3が接続している。下位装置B4は、IABノード300の配下にない装置である。下位装置B1乃至B4は、下位IABノード又はUEである。以下において、下位装置B1乃至B4を特に区別しないときは単に下位装置Bと呼ぶ。
第4実施形態において、上位装置Aと下位装置Bとの間の通信を無線で中継するIABノード300において、上位装置Aと無線で接続するユーザ装置機能部(MT)は、下位装置Bと無線で接続する基地局機能部(DU)に対して状態情報を通知する。
この状態情報は、ユーザ装置機能部(MT)のRRC状態、及び上位装置Aとユーザ装置機能部(MT)との間の無線リンク状態(以下、バックホールリンク状態と呼ぶ)のうち、少なくとも一方の状態を示す情報である。これにより、基地局機能部(DU)は、バックホールリンク側の状態を考慮して下位装置Bに対するサービス提供を制御できる。
ここで、ユーザ装置機能部(MT)のRRC状態は、コネクティッド、インアクティブ、及びアイドルのいずれかである。
バックホールリンク状態は、下記の上記1)乃至6)のうち少なくとも1つの指標、又はこれらの指標の組み合わせに基づく状態である。
1)RLFを検知した及びRLFから復帰したなどのRLF状態
2)RSRP(Reference Signal Received Power)などの無線品質
3)RLC(Radio Link Control)再送回数やRACH(Random Access Channel)再送回数などのリンク状態
4)RSSI(Received Signal Strength Indicator)、CBR(Channel Busy Ratio)、LBT(Listen Before Talk)状況などの混雑度
5)設定されている又は活性化されているセカンダリセル数、MIMO(Multiple Input Multiple Output)レイヤ数、割り当て無線リソース状況(例えば、準静的割り当てにおけるConfigured grantの増減、動的割り当てにおけるDynamic grantの増減)、スループット測定値などの通信容量
6)上りリンクスケジューリング遅延時間の測定値、上りリンクバッファ中のデータ量などの遅延状態。
2)RSRP(Reference Signal Received Power)などの無線品質
3)RLC(Radio Link Control)再送回数やRACH(Random Access Channel)再送回数などのリンク状態
4)RSSI(Received Signal Strength Indicator)、CBR(Channel Busy Ratio)、LBT(Listen Before Talk)状況などの混雑度
5)設定されている又は活性化されているセカンダリセル数、MIMO(Multiple Input Multiple Output)レイヤ数、割り当て無線リソース状況(例えば、準静的割り当てにおけるConfigured grantの増減、動的割り当てにおけるDynamic grantの増減)、スループット測定値などの通信容量
6)上りリンクスケジューリング遅延時間の測定値、上りリンクバッファ中のデータ量などの遅延状態。
バックホールリンク状態は、上記1)乃至6)の指標に基づくバックホールリンク状態の良好度合い、例えば、閾値よりも良好又は閾値よりも劣悪といった状態であってもよい。
ユーザ装置機能部(MT)は、RRC状態の変化又はバックホールリンク状態の変化をトリガとして、状態情報を基地局機能部(DU)に通知してもよい。例えば、ユーザ装置機能部(MT)は、バックホールリンク状態が閾値条件を満たしたというイベントが発生した際に、状態情報を基地局機能部(DU)に通知する。
或いは、ユーザ装置機能部(MT)は、状態情報を基地局機能部(DU)に周期的に通知してもよい。
基地局機能部(DU)は、ユーザ装置機能部(MT)からの状態情報に基づいて、下位装置Bに対するサービス提供を停止してもよい。下位装置Bに対するサービス提供を停止するとは、少なくとも1つの下りリンク無線信号の送信を停止することをいう。基地局機能部(DU)は、PSS(Primary Synchronization Signal)、PSS(Secondary Synchronization Signal)、MIB(Master Information Block)の送信を停止してもよい。
例えば、基地局機能部(DU)は、ユーザ装置機能部(MT)がRRCアイドル状態又はRRCインアクティブ状態に遷移した場合、下位装置Bに対するサービス提供を停止してもよい。基地局機能部(DU)は、ユーザ装置機能部(MT)がRRCコネクティッド状態に遷移した場合、下位装置Bに対するサービス提供を再開してもよい。
基地局機能部(DU)は、バックホールリンクが劣化している場合、例えば、バックホールでRLFが検知された場合、下位装置Bに対するサービス提供を停止してもよい。基地局機能部(DU)は、バックホールリンクが良化した場合、下位装置Bに対するサービス提供を再開してもよい。
或いは、基地局機能部(DU)は、ユーザ装置機能部(MT)からの状態情報に基づいて、下位装置Bに対する無線リソース割り当て(スケジューリング)を制御してもよい。
基地局機能部(DU)は、ユーザ装置機能部(MT)がRRCアイドル状態又はRRCインアクティブ状態に遷移した場合、下位装置Bに対するリソース割当を中止してもよい。なお、基地局機能部(DU)は、ユーザ装置機能部(MT)がRRCアイドル状態又はRRCインアクティブ状態に遷移した際に、下位装置Bに上りリンクリソースを割り当てている場合がある。この場合、基地局機能部(DU)は、RRCコネクティッド状態に遷移するようにユーザ装置機能部(MT)に要求してもよい。
基地局機能部(DU)は、ユーザ装置機能部(MT)がRRCコネクティッド状態に遷移した場合、下位装置Bに対するリソース割当を再開してもよい。
基地局機能部(DU)は、バックホールリンクが劣化している場合、例えば、バックホールでRLFが検知された場合、下位装置Bに対するリソース割当を中止してもよい。基地局機能部(DU)は、バックホールリンクが良化した場合、例えば、バックホールでRLFから復旧した場合、下位装置Bに対するリソース割当を再開してもよい。
或いは、基地局機能部(DU)は、ユーザ装置機能部(MT)からの状態情報に基づいて、バックホールリンクの劣化を示す通知、例えば、バックホールリンクのRLF発生を示す通知(以下、RLF notificationと呼ぶ)を下位装置Bに送信してもよい。RLF notificationは、IABノード300の識別子を含んでもよい。以下において、バックホールリンクの劣化を示す通知がRLF notificationである一例について説明する。
基地局機能部(DU)は、RRCレイヤよりも下位のレイヤの制御信号によりRLF notificationを送信してもよい。基地局機能部(DU)は下位装置BとのRRC接続を有していないためである。RRCレイヤよりも下位のレイヤの制御信号は、MAC CE(Control Element)、RLC Control PDU(Protocol Data Unit)、又はPDCCH(Physical Downlink Control Channel)であるが、以下においてはMAC CEを用いる一例について説明する。
基地局機能部(DU)は、RLF notificationをユニキャストで下位装置Bに送信してもよい。或いは、基地局機能部(DU)は、RLF notificationのシグナリング負荷を減らすために、RLF notificationをブロードキャスト又はマルチキャストで送信してもよい。ブロードキャスト又はマルチキャストを用いる場合、下位装置B3及びB4は、接続中のセル(上位IABノード)からのRLF notificationだけではなく、その他のセルのRLF notificationもモニタすることで、IABノード300からのRLF notificationを受信できる。
基地局機能部(DU)は、例えば、予め仕様で定められた固定のRNTI(Radio Network Temporary Identifier)を用いてRLF notificationをブロードキャストで送信してもよい。基地局機能部(DU)は、下位装置のグループに割り当てた共通のRNTIを用いてRLF notificationをマルチキャストで送信してもよい。
なお、ブロードキャスト/マルチキャストと、ユニキャストとを使い分けてもよい。この場合、基地局機能部(DU)は、RLF notificationがブロードキャスト/マルチキャストで送信されるか、ユニキャストで送信されるかをSIBで通知(ブロードキャスト)してもよい。下位装置Bは、このSIBに基づいて、RLF notificationの待ち受けモード、例えば、RLF notificationのモニタに用いるRNTIを変更してもよい。
基地局機能部(DU)は、バックホールリンクの無線リンク状態が劣化している期間、例えば、バックホールリンクのRLFが発生している期間内において、RLF notificationを周期的に送信してもよい。この場合、RLF notificationが周期的に送信される期間内では、RLFが発生していることになる。或いは、基地局機能部(DU)は、バックホールリンクのRLFが発生した際にRLF notificationを送信し、バックホールリンクのRLFから復旧した際に復旧を示す通知を送信してもよい。以下においては、RLF notificationの周期的な送信により、バックホールリンクのRLFの発生及びRLFからの復旧を下位装置に示す一例について主として説明する。
下位装置Bは、IABノード300からRLF notificationを受信する期間内では、バックホールリンクのRLFが発生していると判定する。RLF notificationの送信周期は、ドナー装置からIABノード300のユーザ装置機能部(MT)を介して基地局機能部(DU)に設定されてもよい。
RLF notificationがマルチキャストで送信される場合、RLF notificationを受信した下位装置Bは、RLF notificationの受信に応じて、IABノード300に対するACK/NACKフィードバックの送信を開始してもよい。IABノード300は、配下の全ての下位装置B1乃至B3からACKを受信した場合、RLF notificationの周期的な送信を停止してもよい。
RLF notificationを受信した下位装置B1乃至B3は、接続先又は通信経路をIABノード300から切り替えるための処理を行ってもよい。このような処理としては、例えば、接続再確立処理、条件付きハンドオーバのトリガ処理、通信経路切替処理、ハンドオーバ用の測定報告処理が挙げられる。なお、下位装置B1乃至B3は、このような切り替え処理を開始した後、切り替え処理を完了するまでの間において、IABノード300からのRLF notificationを受信しなくなった場合(又はバックホールRLFの復旧を示す通知を受信した場合)、IABノード300のバックホールリンクが復旧したと判定し、切り替え処理を中止してもよい。
例えば、RLF notificationを受信した下位装置B1乃至B3は、IABノード300のセル以外のセルを探索するセルサーチを行い、適切なセルに対して接続再確立(RRC Reestablishment)を行う。ここで、下位装置B1乃至B3とIABノード300との間でRLFが発生していなくても、このような接続再確立処理を早期に行う。
接続再確立処理は、時間的に分散して実行するように制御されていてもよい。例えば、下位装置B1乃至B3は、ランダム値やUE-IDを用いて接続再確立処理の実行開始時間を決定することにより、下位装置B1乃至B3の接続再確立処理の実行開始時間を分散させ、負荷の集中を防ぐことができる。なお、RLF notificationがユニキャストで送信される場合、基地局機能部(DU)がRLF notificationの送信タイミングを分散させることにより、下位装置B1乃至B3の接続再確立処理の実行開始時間を分散させてもよい。
RLF notificationを受信した下位装置B1乃至B3は、自身がIABノード300と、IABノード300以外の上位装置とに接続してDC通信を行っている場合、IABノード300を経由する通信経路を他の上位装置に切り替えてもよいし、他の通信装置にRLF notificationを送信してもよい。例えば、下位装置Bは、IABノード300をマスタノード(MN)として設定し、他の上位装置をバックアップ用のセカンダリノード(SN)として設定している場合、MNを経由する通信経路をSNに切り替える。
RLF notificationを受信した下位装置B1乃至B3は、自身に条件付きハンドオーバが設定されている場合、条件が満たされたとみなして、ハンドオーバを行ってもよい。ハンドオーバ条件がサービングセルの無線品質劣化を示すイベントである場合、サービングセルの無線品質測定結果を低く修正する(例えば、-200dBmとみなす)ことにより、強制的にハンドオーバをトリガしてもよい。
RLF notificationを受信した下位装置B1乃至B3は、測定報告の送信をトリガしてもよい。ここで、一般的な測定報告はRRCメッセージで送信されるが、基地局機能部(DU)はRRCレイヤを有していない。このため、IABノード300は、バックホールリンクのRLFから復旧するまでは下位装置Bからの測定報告を保持し、バックホールリンクのRLFから(一時的に)復旧した際にドナー装置に転送し、ドナー装置が下位装置Bをハンドオーバさせてもよい。
RLF notificationを受信した下位装置B4は、接続先の候補としてIABノード300を除外するための処理を行ってもよい。例えば、RLF notificationを受信した下位装置B4は、RRCアイドル状態又はRRCインアクティブ状態におけるセル再選択動作において、IABノード300のセルの優先度を下げる、もしくは再選択対象から除外する、もしくはIABノード300についての受信電力測定値を低く調整する。これにより、接続先の候補としてIABノード300が除外されるようにしてもよい。ここで、受信電力測定値を低く調整するために、実際の受信電力測定値に対してオフセット値を適用してもよい。当該オフセット値は予め決められた固定値であってもよい。もしくは当該オフセット値はネットワークから通知された値であってもよく、当該通知は下位装置B4が現在キャンプしているセルの報知情報(SIB)によって通知されてもよい。
下位装置B4は、接続先の候補としてIABノード300を除外するための処理を、RRCコネクティッド状態に遷移する際のRRC Setup Request処理又はRRC Resume Request処理を開始する前のタイミングで行ってもよい。
具体的には、下位装置B4は、RRC Setup Requestを送信する前に、送信先候補のセルがRLF notificationを通知しているか否かの確認を行う。下位装置B4は、送信先候補のセルがRLF notificationを通知していない場合はRRC Setup Requestを送信する。送信先候補のセルがRLF notificationを通知している場合はRRC Setup Requestの送信を停止(もしくは中止)し、前記セル再選択動作を行うことにより、適切なRRC Setup Request送信先を選択する。
下位装置B4は、IABノード300からのRLF notificationを受信しなくなった場合(又はバックホールRLFの復旧を示す通知を受信した場合)、IABノード300のバックホールリンクが復旧したと判定し、接続先の候補としてIABノード300を除外するための処理を中止してもよい。
図16は、第4実施形態に係る動作の一例を示す図である。図16において、IABノード(Parent IAB node)300とドナーgNB(IAB doner)200との間に他のIABノードが介在してもよい。
図16に示すように、ステップS801において、IABノード300のユーザ装置機能部(MT)は、無線問題(radio problem)を検知する。
ステップS802において、IABノード300のユーザ装置機能部(MT)は、RLFを検知する(RLF declaration)。
ステップS803において、IABノード300のユーザ装置機能部(MT)は、RLFの発生を示す状態情報をIABノード300の基地局機能部(DU)に通知する。
ステップS804において、IABノード300の基地局機能部(DU)は、ユーザ装置機能部(MT)からの通知に応じて、RLF notificationの周期的な送信を開始する。
ステップS805において、RLF notificationを受信した下位装置Bは、接続先又は通信経路をIABノード300から切り替えるための処理を開始する。このような処理としては、例えば、接続再確立処理(Early RRC Re-establishment)、条件付きハンドオーバのトリガ処理(Triggering Conditional HO)、通信経路切替処理(Switching to redundant route)が挙げられる。
ステップS806において、IABノード300のユーザ装置機能部(MT)は、例えばT310動作中に接続再確立を行うことができず、T310の満了に応じてRRCアイドル状態に遷移する(Go to IDLE)。
ステップS807において、IABノード300のユーザ装置機能部(MT)は、RRCアイドル状態への遷移を示す状態情報をIABノード300の基地局機能部(DU)に通知する。
ステップS808において、IABノード300の基地局機能部(DU)は、ユーザ装置機能部(MT)からの通知に応じて、下位装置Bへのサービス提供を停止する(Service stopped)。
ステップS809において、下位装置Bは、IABノード300からのサービス提供が停止されたことにより、RLFを検知する。
[その他の実施形態]
上述した実施形態において、移動通信システム1が5G移動通信システムである一例について主として説明した。しかしながら、移動通信システム1における基地局はeNBであってもよい。また、移動通信システム1におけるコアネットワークはEPC(Evolved Packet Core)であってもよい。さらに、gNBがEPCに接続することもでき、eNBが5GCに接続することもでき、gNBとeNBとが基地局間インターフェイス(Xnインターフェイス、X2インターフェイス)を介して接続されることもできる。
上述した実施形態において、移動通信システム1が5G移動通信システムである一例について主として説明した。しかしながら、移動通信システム1における基地局はeNBであってもよい。また、移動通信システム1におけるコアネットワークはEPC(Evolved Packet Core)であってもよい。さらに、gNBがEPCに接続することもでき、eNBが5GCに接続することもでき、gNBとeNBとが基地局間インターフェイス(Xnインターフェイス、X2インターフェイス)を介して接続されることもできる。
なお、上述した実施形態に係る各処理をコンピュータに実行させるプログラムが提供されてもよい。また、プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、CD-ROMやDVD-ROM等の記録媒体であってもよい。UE100及びeNB200が行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップセットが提供されてもよい。
なお、各図において示されるフローは、適宜組み合わされても良い。
[付記1]
1.序論
統合されたアクセスとバックホールに関する新しいワークアイテムが承認された。WIDは、目的の1つとしてバックホール無線リンク障害(BH RLF)処理を指定することを定める。
1.序論
統合されたアクセスとバックホールに関する新しいワークアイテムが承認された。WIDは、目的の1つとしてバックホール無線リンク障害(BH RLF)処理を指定することを定める。
以下を含むアーキテクチャ1aに続くIABノードの仕様
・[…]
・低遅延スケジューリング、BH RLF処理、及びマルチホップトポロジ全体のリソース調整をサポートするためのシグナリングのホップバイホップ伝搬。
・[…]
L2トランスポート及びリソース管理のシグナリングの仕様
・[…]
・BH RLF処理の仕様(例:ダウンストリームBH RLF通知)
この付記では、研究項目からの結果に加えてBH RLF処理の最初の考慮が議論される。
・[…]
・低遅延スケジューリング、BH RLF処理、及びマルチホップトポロジ全体のリソース調整をサポートするためのシグナリングのホップバイホップ伝搬。
・[…]
L2トランスポート及びリソース管理のシグナリングの仕様
・[…]
・BH RLF処理の仕様(例:ダウンストリームBH RLF通知)
この付記では、研究項目からの結果に加えてBH RLF処理の最初の考慮が議論される。
2.議論
TRは、セクション9.7.14及び9.7.15において、マルチホップの無線バックホールのBH RLFに起因する問題を特定する。セクション間の共通の問題は、子IABノード/UEが親IABノードにおけるBH RLFを認識していないことである。これにより、BH RLFは、FR2やマルチホッピングなどの高周波数の無線バックホールにおいて頻繁に発生する可能性がある。結果として、ユーザの観点から、サービスの回復が遅れることを含むサービスが大幅に中断される。
TRは、セクション9.7.14及び9.7.15において、マルチホップの無線バックホールのBH RLFに起因する問題を特定する。セクション間の共通の問題は、子IABノード/UEが親IABノードにおけるBH RLFを認識していないことである。これにより、BH RLFは、FR2やマルチホッピングなどの高周波数の無線バックホールにおいて頻繁に発生する可能性がある。結果として、ユーザの観点から、サービスの回復が遅れることを含むサービスが大幅に中断される。
このような悪いユーザーエクスペリエンスを回避するために、TRは次のように潜在的な解決策も特定する。
9.7.14アーキテクチャ1aにおけるBH RLFのダウンストリーム通知
「選択肢1:IABノードDUはサービスを中止する。その結果、子ノードもBH RLFを決定し、上記の手順に従って回復する。」
「選択肢2:IABノードDUは、アップストリームRLFについて子IABノードに明示的に警告する。この警告を受信した子IABノードは、警告をさらに下流に転送し得る。このような警告を受信した各IABノードは、上記のBH-RLF回復を開始する。」
「選択肢3:全てのIABノードは、BH品質などに関する情報を子又は親のIABノードと定期的に共有し得る。このようにして、明示的な動作を実行しなくても、ダウンストリーム又はアップストリームRLFを検知し得る。」
9.7.15効率的なバックホールリンク障害の復旧
「バックホール障害のために親ノードとして機能できないノードのリストを含む、バックホール障害に関する情報は、ダウンストリームIABノードに提供され得る。」(選択肢4)
「事前(つまり、RLFの発生前)における代替バックホールリンクとルートの準備」(選択肢5)
「選択肢1:IABノードDUはサービスを中止する。その結果、子ノードもBH RLFを決定し、上記の手順に従って回復する。」
「選択肢2:IABノードDUは、アップストリームRLFについて子IABノードに明示的に警告する。この警告を受信した子IABノードは、警告をさらに下流に転送し得る。このような警告を受信した各IABノードは、上記のBH-RLF回復を開始する。」
「選択肢3:全てのIABノードは、BH品質などに関する情報を子又は親のIABノードと定期的に共有し得る。このようにして、明示的な動作を実行しなくても、ダウンストリーム又はアップストリームRLFを検知し得る。」
9.7.15効率的なバックホールリンク障害の復旧
「バックホール障害のために親ノードとして機能できないノードのリストを含む、バックホール障害に関する情報は、ダウンストリームIABノードに提供され得る。」(選択肢4)
「事前(つまり、RLFの発生前)における代替バックホールリンクとルートの準備」(選択肢5)
2.1.IABノードがサービスを中止する(選択肢1)
選択肢1は、BH RLF情報が子IABノード及びUEに暗示的に伝搬されるため、セクション9.7.14と9.7.15との間の共通の問題のための一般的な解決策と見なし得る。BH RLFが子IABノードだけでなく、(BH RLFに直面する親IABノードに接続される)UEにも影響することを考慮すると、選択肢1は既存のRLFと回復メカニズムに依存することが予想されるため、選択肢1がRel-15 UEでサポートされることは重要な側面である。一方、他の選択肢にはRel-16の機能が必要であろう。Rel-15 UEの場合でもサービスの中断を最小限に抑えるには、BH RLFの問題のためのベースラインの解決策として選択肢1を指定すべきである。
選択肢1は、BH RLF情報が子IABノード及びUEに暗示的に伝搬されるため、セクション9.7.14と9.7.15との間の共通の問題のための一般的な解決策と見なし得る。BH RLFが子IABノードだけでなく、(BH RLFに直面する親IABノードに接続される)UEにも影響することを考慮すると、選択肢1は既存のRLFと回復メカニズムに依存することが予想されるため、選択肢1がRel-15 UEでサポートされることは重要な側面である。一方、他の選択肢にはRel-16の機能が必要であろう。Rel-15 UEの場合でもサービスの中断を最小限に抑えるには、BH RLFの問題のためのベースラインの解決策として選択肢1を指定すべきである。
提案1:RAN2は、選択肢1、つまりIABノードがBH RLFでサービスを停止すること、及び選択肢1はRel-15 UEにも有効であるため、ベースラインの解決策であることに同意すべきである。
選択肢1の説明によれば、解決策は「子ノードもBH RLFを判定する」ことを容易にすべきである。技術的には、子IABノードのMT及びUEは、「サービス」が中断された場合にRLFを宣言すべきである。簡単な解決策は、BH RLF下にある親IABノードが、PSS、SSS、MIB、及びSIB1の送信を停止することである。これにより、子IABノード及びUEの無線問題を意図的に作成する。
提案2:RAN2は、「サービス」を中止することを決定した場合に、IABノードがPSS、SSS、MIB、及びSIB1の送信を停止することに同意すべきである。
提案2に同意できる場合は、いつ信号が停止するかを厳密に定義すべきである。BH RLFにあることはTRから大まかに理解できるが、BH RLFが何であるか、及び「サービス」がいつ停止するかは不明確である。明らかに、BH RLFは、IABノードのMTとIABドナーのDU(例えば、親IABノードのDU)の間のRLFと見なし得る。UEとgNB間の既存のRLFを使用した場合とまったく同じように理解し得る。したがって、BH RLFは、無線バックホールリンクにおけるRLFとしてモデル化される。
提案3:RAN2は、BH RLFに既存のRLFメカニズムの再利用に同意すべきである。
提案3に同意できる場合、現在のUEの動作はRLFを宣言した後でも、つまりRRC再確立を開始するためにRRC接続を維持するため、RLFでサービスを実際に停止する必要があるかどうかは疑問である。UEがRRC接続を正常に再確立すると、最小の中断時間でサービスが回復する。そのため、IABノードは、MTがRRC IDLEに入った場合、つまりRRC再確立が失敗した場合にのみ、「サービス」を停止すべきであることが分かる。
提案4:RAN2は、MTがRLFを宣言した場合ではなく、MTがRRC IDLEに入った場合、IABノードのDUが「サービス」を停止することに同意すべきである。
上記のように、選択肢1は、Rel-15のUEを含むあらゆる種類のケースとデバイスをカバーするための基盤であり、サービスの迅速な回復などの点で最良の解決策を意味するものではない。そのため、このWIで規定されるべき他の多くの機能があるので、他の選択肢は選択肢1に加えて依然として有益であり、時間が許す限り議論され得る。
所見1:選択肢1に加え他の選択肢は、サービス品質をさらに向上させるという点で依然として有益である。
2.2.IABノードはダウンストリームノードに通知する(選択肢2、選択肢4)
子IABノードが回復手順を迅速及び/又は効率的に開始することを容易にするため、親IABノードがそのBH RLFに関連する情報を子IABノードに通知することは役立つ。TRは、「アップストリームRLFについて子IABノードに明示的に警告する」(選択肢2)のような可能な情報要素、又は「親ノードとして機能できないノードのリストを含むバックホール障害に関する」(選択肢4)情報をキャプチャする。
子IABノードが回復手順を迅速及び/又は効率的に開始することを容易にするため、親IABノードがそのBH RLFに関連する情報を子IABノードに通知することは役立つ。TRは、「アップストリームRLFについて子IABノードに明示的に警告する」(選択肢2)のような可能な情報要素、又は「親ノードとして機能できないノードのリストを含むバックホール障害に関する」(選択肢4)情報をキャプチャする。
ただし、親IABノードでBH RLFが発生した場合に、子IABノードにそのような情報を提供する方法は不明確である。研究項目は、「RAN-3は将来の規範的段階にアーキテクチャ1aを推奨する」と結論付けた。これは、IABノードがDUとMTで構成され、IABドナーが(DUと)CUで構成されることを意味する。CUはDUとCUとの間のRRCを担当し、BH RLFはMTのRRCで検出される。そのため、考慮すべき2つの異なるRRCがある。親IABノードのMT上におけるRRCは、BH RLFを検出し、IABドナーの異なるRRCは子IABノードに送信されるRRCメッセージを生成する。
物理的な無線リンクがBH RLFで切断されることを考慮すると、ダウンストリームノードへの情報はRRCメッセージで伝達できない。つまり、CUによって生成されたRRCメッセージはBH RLFのためにDUに到達できない。(選択肢2の)「警告」は、MAC CEなどで送信されてもよいが、(選択肢4の)「ノードのリスト」は、RRCメッセージを使用しない限り、大きすぎ、フレキシブルすぎる。そのため、選択肢2及び/又は選択肢4が導入された場合、RAN2は最初にどのシグナリングが使用されるかを検討すべきである。
所見2:CUへの物理的な無線リンクが切断されているため、IABノードのDUはRRCメッセージを使用しなくてもよい。
この情報はRel-16の機能として提供されることは明らかである。つまり、IABノード間でのみサポートされ得る。つまり、Rel-15のUEではサポートされない。
所見3:選択肢2及び選択肢4は、Rel-16のIABノードの復旧手順でのみ機能する。
2.3.全てのIABノードは定期的に情報を共有する(選択肢3)
選択肢3では、IABノードは共有される情報に基づいてBH RLFを検知できる。TRでキャプチャされる情報は、例えば、「BH品質」である。これは、F1の既存のGNB-DU STATUS INDICATIONである場合とDU間の新しいシグナリングである場合があってもよい。
所見4:選択肢3はRAN2の範囲外である可能性がある。
選択肢3では、IABノードは共有される情報に基づいてBH RLFを検知できる。TRでキャプチャされる情報は、例えば、「BH品質」である。これは、F1の既存のGNB-DU STATUS INDICATIONである場合とDU間の新しいシグナリングである場合があってもよい。
所見4:選択肢3はRAN2の範囲外である可能性がある。
2.4.代替リンクの事前準備(選択肢5)
選択肢5は、例えば、マルチコネクティビティ(MN/SNロール変更あり)、条件付きハンドオーバ、又は通常のトポロジ適応又はモビリティ拡張に関連するその他の技術を利用することを目的とする場合がある。TRで「他のRel-16のWIの一部として定義された追加の機能/拡張機能を活用してもよい」と述べられているように、選択肢5は、このWI又は他のWIの他のトピックで議論される結果を再利用してもよい。
選択肢5は、例えば、マルチコネクティビティ(MN/SNロール変更あり)、条件付きハンドオーバ、又は通常のトポロジ適応又はモビリティ拡張に関連するその他の技術を利用することを目的とする場合がある。TRで「他のRel-16のWIの一部として定義された追加の機能/拡張機能を活用してもよい」と述べられているように、選択肢5は、このWI又は他のWIの他のトピックで議論される結果を再利用してもよい。
所見5:選択肢5は、このWI又は他のWIでの他のトピックで議論される解決策を再利用してもよい。
[付記2]
1.序論
統合されたアクセス及びバックホールの新しいワークアイテムはRAN#82で承認され、マルチホップ無線バックホールの低レイテンシスケジューリングは特定されると見なされる。
1.序論
統合されたアクセス及びバックホールの新しいワークアイテムはRAN#82で承認され、マルチホップ無線バックホールの低レイテンシスケジューリングは特定されると見なされる。
アーキテクチャ1aに続くIABノードの仕様
・[…]
・マルチホップトポロジ全体での低レイテンシスケジューリング、BH RLF処理、及びリソース調整をサポートするためのシグナリングのhop-by-hop伝搬。
・[…]
・マルチホップトポロジ全体での低レイテンシスケジューリング、BH RLF処理、及びリソース調整をサポートするためのシグナリングのhop-by-hop伝搬。
この寄書では、低レイテンシスケジューリングの解決策について議論する。
2.議論
この研究項目は、TR 38.87のセクション8.6でキャプチャされた図17に示すようなマルチホップバックホールのシーケンス手順によるULスケジューリングのレイテンシの問題を特定した。
この研究項目は、TR 38.87のセクション8.6でキャプチャされた図17に示すようなマルチホップバックホールのシーケンス手順によるULスケジューリングのレイテンシの問題を特定した。
TRはまた、「このような遅延を緩和する1つのアプローチは、到着が予想されるデータに基づいてIABノードでアップリンクリソース要求を開始することで構成される。これにより、IABノードは、子IABノード又はそれがサービスを提供するUEから実際のデータを受信する前に、アップリンクリソースを取得できるようになる。」、及び「SR/BSR及びULスケジューリングの内容及びトリガの詳細は、WI段階に残される。」という考えられるメカニズムを特定する。
詳細に飛ぶ前に、前提条件に応じて解決策が多少異なるため、拡張が動的割り当てに必要か、設定されたグラントに必要か、又はその両方に必要かを明確にすべきである。上記のTRの論述は、動的リソース割り当ての使用を意図している可能性がありますが、レイテンシの問題は、設定されるグラントには問題でない場合がありますが、場合によってはスペクトル効率において問題がある場合がある。したがって、RAN2は、動的リソース割り当てのためにSR、BSR、及び/又はULスケジューリングを拡張すべきである。
提案1:RAN2は、マルチホップ無線バックホールでの動的なリソース割り当てのためにSR、BSR、及び/又はULスケジューリングを拡張すべきである。
現在の仕様では、次のように通常のBSR送信用のリソースがない場合にSRがトリガされる。
MACエンティティ
1>バッファステータスレポート手順で、少なくとも1つのBSRがトリガされ、キャンセルされていないと判断された場合
[…]
2>通常のBSRがトリガされ、logicalChannelSR-DelayTimerが実行されていない場合
3>新しい送信に利用可能なUL-SCHリソースがない場合、又は
3>MACエンティティが設定されるアップリンクグラントで設定し、logicalChannelSR-Maskがfalseに設定される論理チャネルに対して通常のBSRがトリガされた場合、又は
3>新しい伝送に使用可能なUL-SCHリソースが、BSRをトリガした論理チャネルに設定されたLCPマッピングの制限(5.4.3.1を参照)を満たさない場合、
4>スケジューリング要求をトリガする
1>バッファステータスレポート手順で、少なくとも1つのBSRがトリガされ、キャンセルされていないと判断された場合
[…]
2>通常のBSRがトリガされ、logicalChannelSR-DelayTimerが実行されていない場合
3>新しい送信に利用可能なUL-SCHリソースがない場合、又は
3>MACエンティティが設定されるアップリンクグラントで設定し、logicalChannelSR-Maskがfalseに設定される論理チャネルに対して通常のBSRがトリガされた場合、又は
3>新しい伝送に使用可能なUL-SCHリソースが、BSRをトリガした論理チャネルに設定されたLCPマッピングの制限(5.4.3.1を参照)を満たさない場合、
4>スケジューリング要求をトリガする
したがって、重要な問題の1つは、通常のBSRのトリガを高速化する方法である。通常のBSRは、次のように、データが送信可能になるとトリガされる。
MACエンティティは、TS38.322及び38.323のデータ量計算手順に従って、論理チャネルで使用可能なULデータの量を決定する。
次のいずれかのイベントが発生した場合、BSRがトリガされる。
-LCGに属する論理チャネルのULデータは、MACエンティティで利用可能になる。
-このULデータは、任意のLCGに属する利用可能なULデータを含む論理チャネルの優先度よりも高い優先度を持つ論理チャネルに属する。又は、
-LCGに属する論理チャネルには、利用可能なULデータが含まれていない。
-LCGに属する論理チャネルには、利用可能なULデータが含まれていない。
この場合、BSRは「通常BSR」と呼ばれる。
「アーリー通常BSRトリガ」を有効にするには、送信可能なデータに追加のルールを設定することが簡単である。現在、このようなデータ量の計算手順はRLC及びPDCPレイヤでのみ行われているが、バックホールリンクのMTのMACエンティティは、DUに表示されるULデータ量を何らかの形で考慮すべきである。
提案2:RAN2は、MTのMACエンティティが、同じIABノードのDUで見えるULデータ量を考慮する必要があることに同意すべきである。
提案2に同意できる場合、DUに見えるデータ量のどれがデータ利用可能な送信とみなされるかを検討すべきである。以下の選択肢が考慮される。
選択肢1:DUプロトコルスタックのMAC、RLC、PDCP(及び場合によってはアダプテーションレイヤ)におけるバッファの実際のデータ量。
選択肢2:選択肢1に加えて、子ノード/UEに既にグラントされているデータ量(図18)。
選択肢3:選択肢2に加えて、子ノード/UEでの送信に利用可能なデータ、つまり子ノード/UEからのBSRのバッファサイズ(図14)。
レイテンシ削減の観点から、選択肢3は、IABノードのDUが子ノード/UEからULデータを受信したときにそのIABノードのMTがバックホールリンクのリソースをグラントしたことが予想されるため、最適な解決策である。一方、MTでのULグラントの受信とDUでのULデータの受信とが十分に同期されていない限り、リソースの浪費が発生する可能性がある。つまり、オーバースケジューリングが発生する可能性がある。選択肢1はリスクが低いが利益も低くなる。選択肢2は、他の選択肢間のバランスの取れた解決策と見なされる。
提案3:RAN2は、送信に利用可能な追加データがUEへのULグラント又はUEからのBSRに関連するデータ量であるかどうかを議論すべきである。
[付記3]
1.序論
統合されたアクセスとバックホールに関する新しいワークアイテムが承認された。WIDは、目的の1つとしてバックホール無線リンク障害(BH RLF)処理を指定することを定める。
1.序論
統合されたアクセスとバックホールに関する新しいワークアイテムが承認された。WIDは、目的の1つとしてバックホール無線リンク障害(BH RLF)処理を指定することを定める。
以下を含むアーキテクチャ1aに続くIABノードの仕様
・[…]
・低遅延スケジューリング、BH RLF処理、及びマルチホップトポロジ全体のリソース調整をサポートするためのシグナリングのホップバイホップ伝搬。
・[…]
・[…]
・低遅延スケジューリング、BH RLF処理、及びマルチホップトポロジ全体のリソース調整をサポートするためのシグナリングのホップバイホップ伝搬。
・[…]
L2トランスポート及びリソース管理のシグナリングの仕様
・[…]
・BH RLF処理の仕様(例:ダウンストリームBH RLF通知)
この付記では、研究項目からの結果に加えてBH RLF処理の最初の考慮が議論される。
・[…]
・BH RLF処理の仕様(例:ダウンストリームBH RLF通知)
この付記では、研究項目からの結果に加えてBH RLF処理の最初の考慮が議論される。
2.議論
2.1.背景
TRは、セクション9.7.14及び9.7.15において、マルチホップの無線バックホールのBH RLFに起因する問題を特定する。セクション間の共通の問題は、子IABノード/UEが親IABノードにおけるBH RLFを認識していないことである。これにより、BH RLFは、FR2やマルチホッピングなどの高周波数の無線バックホールにおいて頻繁に発生する可能性がある。結果として、ユーザの観点から、サービスの回復が遅れることを含むサービスが大幅に中断される。
2.1.背景
TRは、セクション9.7.14及び9.7.15において、マルチホップの無線バックホールのBH RLFに起因する問題を特定する。セクション間の共通の問題は、子IABノード/UEが親IABノードにおけるBH RLFを認識していないことである。これにより、BH RLFは、FR2やマルチホッピングなどの高周波数の無線バックホールにおいて頻繁に発生する可能性がある。結果として、ユーザの観点から、サービスの回復が遅れることを含むサービスが大幅に中断される。
このような悪いユーザーエクスペリエンスを回避するために、TRは次のように潜在的な解決策も特定する。
9.7.14アーキテクチャ1aにおけるBH RLFのダウンストリーム通知
「選択肢1:IABノードDUはサービスを中止する。その結果、子ノードもBH RLFを決定し、上記の手順に従って回復する。」
「選択肢2:IABノードDUは、アップストリームRLFについて子IABノードに明示的に警告する。この警告を受信した子IABノードは、警告をさらに下流に転送し得る。このような警告を受信した各IABノードは、上記のBH-RLF回復を開始する。」
「選択肢3:全てのIABノードは、BH品質などに関する情報を子又は親のIABノードと定期的に共有し得る。このようにして、明示的な動作を実行しなくても、ダウンストリーム又はアップストリームRLFを検知し得る。」
9.7.15効率的なバックホールリンク障害の復旧
「バックホール障害のために親ノードとして機能できないノードのリストを含む、バックホール障害に関する情報は、ダウンストリームIABノードに提供され得る。」(選択肢4)
「事前(つまり、RLFの発生前)における代替バックホールリンクとルートの準備」(選択肢5)
「選択肢1:IABノードDUはサービスを中止する。その結果、子ノードもBH RLFを決定し、上記の手順に従って回復する。」
「選択肢2:IABノードDUは、アップストリームRLFについて子IABノードに明示的に警告する。この警告を受信した子IABノードは、警告をさらに下流に転送し得る。このような警告を受信した各IABノードは、上記のBH-RLF回復を開始する。」
「選択肢3:全てのIABノードは、BH品質などに関する情報を子又は親のIABノードと定期的に共有し得る。このようにして、明示的な動作を実行しなくても、ダウンストリーム又はアップストリームRLFを検知し得る。」
9.7.15効率的なバックホールリンク障害の復旧
「バックホール障害のために親ノードとして機能できないノードのリストを含む、バックホール障害に関する情報は、ダウンストリームIABノードに提供され得る。」(選択肢4)
「事前(つまり、RLFの発生前)における代替バックホールリンクとルートの準備」(選択肢5)
R2は、少なくともダウンストリームノードへのBH Link RLFでRLF通知があると想定する。
代替リンク及び/又はデュアルコネクティビティ(合意されている場合)は、BH Linkの障害時の復旧時に利用され得る。
現在のUE RLF検出及び回復は、ベースラインとして再利用される。
例えば、リンクが回復したとき、または回復が進行中のとき、他の表示が必要かどうかは更なる検討が必要である。
これらの合意は、上記の選択肢2,4,5に基づいており、追加の側面も含まれる。
2.2.IABノードがサービスを中止する(選択肢1)
選択肢1は、BH RLF情報が子IABノード及びUEに暗示的に伝搬されるため、セクション9.7.14と9.7.15との間の共通の問題のための一般的な解決策と見なし得る。合意された「RLF通知」はRel-16の機能だが、Rel-15 UEは、IABノードとの接続をまだ許可される。Rel-15 UEの場合でもサービスの中断を最小限に抑えるには、BH RLFの問題のためのベースラインの解決策として選択肢1を指定すべきである。
選択肢1は、BH RLF情報が子IABノード及びUEに暗示的に伝搬されるため、セクション9.7.14と9.7.15との間の共通の問題のための一般的な解決策と見なし得る。合意された「RLF通知」はRel-16の機能だが、Rel-15 UEは、IABノードとの接続をまだ許可される。Rel-15 UEの場合でもサービスの中断を最小限に抑えるには、BH RLFの問題のためのベースラインの解決策として選択肢1を指定すべきである。
所見1:合意された「RLF通知」は、Rel-15 UEの観点からBH RLFの問題を解決できない。
選択肢1の説明によれば、解決策は「子ノードもBH RLFを判定する」ことを容易にすべきである。簡単な解決策は、BH RLF下にある親IABノードが、PSS、SSS、MIB、及びSIB1の送信を停止することである。これにより、子IABノード及びUEの無線問題を意図的に作成する。
提案1:RAN2は、「サービス」を中止することを決定した場合に、IABノードがPSS、SSS、MIB、及びSIB1の送信を停止することに同意すべきである。
提案1に同意できる場合、RAN2はすでに「BH Link RLFでのRLF通知」を想定しており、また、現在のUEの動作はRLFを宣言した後でも、つまりRRC再確立を開始するためにRRC接続を維持するため、RLFでサービスを実際に停止する必要があるかどうかは疑問である。UEがRRC接続を正常に再確立すると、最小の中断時間でサービスが回復する。そのため、IABノードは、MTがRRC IDLEに入った場合、つまりRRC再確立が失敗した場合にのみ、「サービス」を停止すべきであることが分かる。この意味では、MTが(同じIABノードの)DUにRRC IDLEに入ること(セットアップ段階でRRC Connectedに移行する可能性もあること)を通知するのは自然である。
提案2:RAN2は、MTがRLFを宣言した場合ではなく、MTがRRC IDLEに入った場合、IABノードのDUが「サービス」を停止することに同意すべきである。
提案3:提案2に同意できる場合、RAN2は、MTがRRC IDLEに入った場合、MTが(同じIABノードの)DUに通知する必要があるかどうかについてさらに議論する。
2.3.IABノードはダウンストリームノードに通知する(選択肢2、選択肢4)
子IABノードが回復手順を迅速及び/又は効率的に開始することを容易にするため、親IABノードがそのBH RLFに関連する情報を子IABノードに通知することは役立つ。TRは、「アップストリームRLFについて子IABノードに明示的に警告する」(選択肢2)のような可能な情報要素、又は「親ノードとして機能できないノードのリストを含むバックホール障害に関する」(選択肢4)情報をキャプチャする。さらに、RAN2は、「R2は、少なくともダウンストリームノードへのBH Link RLFでRLF通知があると想定する」というベースラインに合意した。
子IABノードが回復手順を迅速及び/又は効率的に開始することを容易にするため、親IABノードがそのBH RLFに関連する情報を子IABノードに通知することは役立つ。TRは、「アップストリームRLFについて子IABノードに明示的に警告する」(選択肢2)のような可能な情報要素、又は「親ノードとして機能できないノードのリストを含むバックホール障害に関する」(選択肢4)情報をキャプチャする。さらに、RAN2は、「R2は、少なくともダウンストリームノードへのBH Link RLFでRLF通知があると想定する」というベースラインに合意した。
ただし、親IABノードでBH RLFが発生した場合に、子IABノードにそのような情報を提供する方法は不明確である。研究項目は、「RAN-3は将来の規範的段階にアーキテクチャ1aを推奨する」と結論付けた。これは、IABノードがDUとMTで構成され、IABドナーが(DUと)CUで構成されることを意味する。CUはDUとCUとの間のRRCを担当し、BH RLFはMTのRRCで検出される。そのため、考慮すべき2つの異なるRRCがある。親IABノードのMT上におけるRRCは、BH RLFを検出し、IABドナーの異なるRRCは子IABノードに送信されるRRCメッセージを生成する。
物理的な無線リンクがBH RLFで切断されることを考慮すると、ダウンストリームノードへの情報はRRCメッセージで伝達できない。つまり、CUによって生成されたRRCメッセージはBH RLFのためにDUに到達できない。(選択肢2の)「警告」は、MAC CEで送信されてもよいが、MAC CEは「ノードのリスト」(選択肢4)を伝えるのに適切ではない。したがって、RAN2は選択肢2をMAC CEで想定し、選択肢4を考慮すべきではない。
所見2:CUへの物理的な無線リンクが切断されているため、IABノードのDUはRRCメッセージを使用しなくてもよい。
提案4:RAN2は、ダウンストリームノードへのRLF通知がMAC CEを介して送信されるかどうかを議論すべきである。
RLF通知がいつ/どのようにトリガされるかについても議論されるだろう。情報の名前を考慮すると、BH RLFがMTで宣言された時にRLF通知が送信されるのが素直である。この場合、DUはBH RLFに従ってRLF通知を生成/送信する必要があるため、MTはRLF宣言を(同じIABノードの)DUに通知すべきである。前のセクションの提案2に同意できる場合、BH RLF、つまりIABノードがRLF通知を送信するだけの場合、「サービス」が継続し、MTがRRC IDLEに入ると「サービス」が停止する。
提案5:RAN2は、DUがMTによってRLFを通知されるとRLF通知が送信されることに同意すべきである。
もう1つの疑問は、RLF通知の受信時の(子IABノードの)MT動作である。MTが何らかの回復手順を開始することは想定し得るが、それはMTがRLFを宣言する「前の」プロセスであるべきである。つまり、RLF通知は、子ノードのRLFをすぐにトリガすべきではない。なぜなら、RLFの宣言により、さらにダウンストリームノードへのRLF通知がトリガされ、RLF通知は間もなくIABトポロジ間で伝搬されるからである。不要なトポロジ適応のストリームが発生し、最悪の場合はIABトポロジが破損する可能性がある。
提案6:RAN2は、MT/UEがRLF通知の受信時にRLFを宣言せず、何らかのバックホールリンクの回復を開始するだけであることに同意すべきである。
RAN2は、「R2は、少なくともダウンリンクノードへのBH Link RLFでRLF通知があると想定する」ことに同意した。これにより、「ダウンストリームノード」とは、親ノードに直接接続されている子ノード/UEを意味することが自然である。ただし、「ダウンストリームノード」に、親と直接接続していない孫ノード/UE(つまり、親は孫の観点から祖父母である)も含まれているかどうかは明確ではない。
孫がRLF通知を受信できる場合、RLF通知の伝播遅延がなくなるため、トポロジの回復が速くなるという利点がある。さらに、副産物として、任意のIDLEノード/UEがRLF通知を受信できる場合、再選択の際に考慮される可能性がある。これにより、ノード/UEは、ドナーノードに接続できないため、セルのランクが最高であっても、BH RLFが発生するセルの再選択または接続を回避するよう試みることができる。欠点は、トポロジの適応と管理が複雑になることである。例えば、極端な場合、IABトポロジ内の全てのノード/UEが1つのノードからRLF通知を受信して回復手順を開始すると、多くの不必要なトポロジ変更が行われる可能性があり、最悪の場合、IABトポロジが破損する。したがって、上記の長所と短所を考慮して、RLF通知を子ノードのみが受信するかどうかを検討すべきである。
提案7:RAN2は、RLF通知を子ノードのみが受信するか、孫ノードも受信するかを明確にすべきである。
前回の会議では、RAN2は「例えば、リンクが回復したとき、または回復が進行中のとき、他の指示が必要かどうかはさらに検討する必要がある」とした。
子IABノード又はUEの観点から、RLF通知が受信されると、何らかのトポロジ適応手順、例えば、他のIABノードへのRRC再確立、又は冗長ルートへのプライマリパスの切り替えが開始される。この意味では、バックホールの「リンクが回復した」という情報は、トポロジ適応手順が完了していない場合、例えばRRC再確立手順で適切なセルが見つからない場合、手順を停止できるため有益である。ただし、RLF通知がBH RLF中に繰り返し送信される場合、任意の「他の指示」を規定する必要はない。RLF通知が送信されない場合、BH RLFは発生していないことになるからだ。そうでない場合、「サービス」が停止する。したがって、問題は、BH RLF中にRLF通知を繰り返し送信するかどうかである。
提案8:RAN2は、BH RLF中にRLF通知が繰り返し送信されるかどうかを議論すべきである。
他の例、つまり「回復が進行中」については、子ノード/UEの動作は不明確である。子ノード/UEをしばらく待機させることだけを意味する場合、ダウンストリームノードへの何らの指示も(RLF通知さえ)必要としない可能性がある。したがって、この時点で導入する動機はない。
2.4.全てのIABノードは定期的に情報を共有する(選択肢3)
選択肢3では、IABノードは共有される情報に基づいてBH RLFを検知できる。TRでキャプチャされる情報は、例えば、「BH品質」である。これは、F1の既存のGNB-DU STATUS INDICATIONである場合とDU間の新しいシグナリングである場合があってもよい。
所見3:選択肢3はRAN2の範囲外である可能性がある。
選択肢3では、IABノードは共有される情報に基づいてBH RLFを検知できる。TRでキャプチャされる情報は、例えば、「BH品質」である。これは、F1の既存のGNB-DU STATUS INDICATIONである場合とDU間の新しいシグナリングである場合があってもよい。
所見3:選択肢3はRAN2の範囲外である可能性がある。
2.5.代替リンクの事前準備(選択肢5)
選択肢5は、例えば、マルチコネクティビティ(MN/SNロール変更あり)、条件付きハンドオーバ、又は通常のトポロジ適応又はモビリティ拡張に関連するその他の技術を利用することを目的とする場合がある。TRで「他のRel-16のWIの一部として定義された追加の機能/拡張機能を活用してもよい」と述べられているように、選択肢5は、このWI又は他のWIの他のトピックで議論される結果を再利用してもよい。RLF通知が「MCG Failure Indication」などの特定の動作をトリガするかどうかなど、IAB固有の影響のみが(ある場合)後で議論されるだろう。
選択肢5は、例えば、マルチコネクティビティ(MN/SNロール変更あり)、条件付きハンドオーバ、又は通常のトポロジ適応又はモビリティ拡張に関連するその他の技術を利用することを目的とする場合がある。TRで「他のRel-16のWIの一部として定義された追加の機能/拡張機能を活用してもよい」と述べられているように、選択肢5は、このWI又は他のWIの他のトピックで議論される結果を再利用してもよい。RLF通知が「MCG Failure Indication」などの特定の動作をトリガするかどうかなど、IAB固有の影響のみが(ある場合)後で議論されるだろう。
所見4:選択肢5は、このWI又は他のWIでの他のトピックで議論される解決策を再利用してもよい。
本願は、米国仮出願第62/825149号(2019年3月28日出願)の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
Claims (12)
- 上位装置と下位装置との間の通信を無線で中継する中継装置を用いる通信制御方法であって、
前記中継装置において、前記下位装置と無線で接続する基地局機能部が、前記上位装置と無線で接続するユーザ装置機能部又は前記上位装置を介してドナー装置と通信する通信機能部に対して、状態情報を通知することを含み、
前記状態情報は、前記基地局機能部と前記下位装置の間の無線リンク状態を示す情報である
通信制御方法。 - 前記基地局機能部と前記下位装置の間の無線リンク障害の発生を前記状態情報が示す場合、前記ユーザ装置機能部又は前記通信機能部が、前記無線リンク障害を通知するメッセージを前記ドナー装置に送信することをさらに含む
請求項1に記載の通信制御方法。 - 上位装置と下位装置との間の通信を無線で中継する中継装置を用いる通信制御方法であって、
前記中継装置において、前記上位装置と無線で接続するユーザ装置機能部が、前記下位装置と無線で接続する基地局機能部に対して状態情報を通知することを含み、
前記状態情報は、前記ユーザ装置機能部のRRC状態、及び前記上位装置と前記ユーザ装置機能部との間の無線リンク状態のうち、少なくとも一方の状態を示す情報である
通信制御方法。 - 前記状態情報を通知することは、前記状態の変化をトリガとして、前記状態情報を前記基地局機能部に通知することを含む
請求項3に記載の通信制御方法。 - 前記基地局機能部が、前記状態情報に基づいて、前記下位装置に対するサービス提供を停止することをさらに含む
請求項3又は4に記載の通信制御方法。 - 前記基地局機能部が、前記状態情報に基づいて、前記上位装置と前記ユーザ装置機能部との間の無線リンク状態の劣化を示す通知を前記下位装置に送信することをさらに含む
請求項2乃至5のいずれか1項に記載の通信制御方法。 - 前記通知を受信した前記下位装置が、接続先又は通信経路を前記中継装置から切り替えるための処理を行うことをさらに含む
請求項6に記載の通信制御方法。 - 前記下位装置に通知を送信することは、前記基地局機能部においてRRCレイヤよりも下位のレイヤの制御信号により前記通知を送信することを有する
請求項6又は7に記載の通信制御方法。 - 前記下位装置に通知を送信することは、前記通知をブロードキャスト又はマルチキャストで送信することを有する
請求項6乃至8のいずれか1項に記載の通信制御方法。 - 前記中継装置の配下にない他の下位装置が前記通知を受信した場合、前記他の下位装置が、接続先の候補として前記中継装置を除外するための処理を行うことをさらに含む
請求項9に記載の通信制御方法。 - 前記下位装置に通知を送信することは、前記上位装置と前記ユーザ装置機能部との間の無線リンク状態が劣化している期間内において前記通知を周期的に送信することを有する
請求項6乃至10のいずれか1項に記載の通信制御方法。 - 上位装置と下位装置との間の通信を無線で中継する中継装置を用いる通信制御方法であって、
前記中継装置が、前記中継装置に接続する下位装置から、他の中継装置との無線リンク障害の発生を示す通知を受信することと、
前記中継装置が、ドナー装置に対して、前記無線リンク障害に関するメッセージを送信することと、を含む
通信制御方法。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021509274A JP7303290B2 (ja) | 2019-03-28 | 2020-03-18 | 通信制御方法 |
US17/483,248 US20220015000A1 (en) | 2019-03-28 | 2021-09-23 | Communication control method |
JP2023102558A JP2023120373A (ja) | 2019-03-28 | 2023-06-22 | 通信制御方法、第1中継装置及びプロセッサ |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201962825149P | 2019-03-28 | 2019-03-28 | |
US62/825,149 | 2019-03-28 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/483,248 Continuation US20220015000A1 (en) | 2019-03-28 | 2021-09-23 | Communication control method |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2020196201A1 true WO2020196201A1 (ja) | 2020-10-01 |
Family
ID=72611907
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2020/012148 WO2020196201A1 (ja) | 2019-03-28 | 2020-03-18 | 通信制御方法 |
Country Status (3)
Country | Link |
---|---|
US (1) | US20220015000A1 (ja) |
JP (2) | JP7303290B2 (ja) |
WO (1) | WO2020196201A1 (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPWO2022085696A1 (ja) * | 2020-10-21 | 2022-04-28 | ||
WO2022149470A1 (ja) * | 2021-01-06 | 2022-07-14 | 京セラ株式会社 | 通信制御方法 |
WO2022168662A1 (ja) * | 2021-02-02 | 2022-08-11 | 株式会社Nttドコモ | 無線通信ノード、無線通信システム及び無線通信方法 |
WO2022234846A1 (ja) * | 2021-05-07 | 2022-11-10 | 京セラ株式会社 | 通信制御方法 |
EP4258732A4 (en) * | 2021-01-04 | 2024-05-15 | Kyocera Corporation | COMMUNICATION CONTROL METHODS |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CA3193416C (en) * | 2020-08-06 | 2024-05-28 | Ofinno, Llc | Uplink resource release |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20190373519A1 (en) * | 2017-02-02 | 2019-12-05 | Intel IP Corporation | Generation node-b (gnb), user equipment (ue) and methods for handover based on multi-connectivity in new radio (nr) systems |
-
2020
- 2020-03-18 JP JP2021509274A patent/JP7303290B2/ja active Active
- 2020-03-18 WO PCT/JP2020/012148 patent/WO2020196201A1/ja active Application Filing
-
2021
- 2021-09-23 US US17/483,248 patent/US20220015000A1/en active Pending
-
2023
- 2023-06-22 JP JP2023102558A patent/JP2023120373A/ja active Pending
Non-Patent Citations (7)
Title |
---|
KYOCERA: "Consideration of low latency scheduling for multi-hop backhauling", 3GPP TSG RAN WG2 #105 R2-1900925, 15 February 2019 (2019-02-15), XP051602296 * |
KYOCERA: "Consideration of low latency scheduling for multi-hop backhauling", 3GPP TSG RAN WG2 #105BIS R2-1903733, 28 March 2019 (2019-03-28), XP051692996 * |
KYOCERA: "Consideration of topology adaptation upon BH RLF", 3GPP TSG RAN WG2 #105 R2-1900919, 15 February 2019 (2019-02-15), XP051602290 * |
KYOCERA: "Further consideration of topology adaptation upon BH RLF", 3GPP TSG RAN WG2 #105BIS R2-1903730, 28 March 2019 (2019-03-28), XP051692993 * |
LG ELECTRONICS INC: "BH RLF reporting to JAB donor node", 3GPP TSG RAN WG2 #105 R2-1902018, 15 February 2019 (2019-02-15), pages 1 - 2, XP051603364 * |
QUALCOMM INCORPORATED: "Backhaul RLF notification for IAB", 3GPP TSG RAN WG2 #105 R2-1900812, 14 February 2019 (2019-02-14), pages 1 - 3, XP051602186 * |
ZTE, SANECHIPS: "Discussion on JAB BH RLF handling", 3GPP TSG RAN WG2 #105 R2-1900571, 15 February 2019 (2019-02-15), pages 1 - 6, XP051601951 * |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPWO2022085696A1 (ja) * | 2020-10-21 | 2022-04-28 | ||
WO2022085696A1 (ja) * | 2020-10-21 | 2022-04-28 | 京セラ株式会社 | 通信制御方法 |
EP4224902A4 (en) * | 2020-10-21 | 2024-05-29 | Kyocera Corporation | COMMUNICATION CONTROL METHODS |
EP4258732A4 (en) * | 2021-01-04 | 2024-05-15 | Kyocera Corporation | COMMUNICATION CONTROL METHODS |
WO2022149470A1 (ja) * | 2021-01-06 | 2022-07-14 | 京セラ株式会社 | 通信制御方法 |
WO2022168662A1 (ja) * | 2021-02-02 | 2022-08-11 | 株式会社Nttドコモ | 無線通信ノード、無線通信システム及び無線通信方法 |
WO2022234846A1 (ja) * | 2021-05-07 | 2022-11-10 | 京セラ株式会社 | 通信制御方法 |
Also Published As
Publication number | Publication date |
---|---|
JPWO2020196201A1 (ja) | 2020-10-01 |
JP7303290B2 (ja) | 2023-07-04 |
JP2023120373A (ja) | 2023-08-29 |
US20220015000A1 (en) | 2022-01-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2020196201A1 (ja) | 通信制御方法 | |
US20210219368A1 (en) | Relay apparatus | |
JP7413316B2 (ja) | 中継装置 | |
JP6977187B2 (ja) | 通信制御方法 | |
JP7189219B2 (ja) | 中継装置 | |
JPWO2019216371A1 (ja) | 移動通信システム、中継ノード、及び基地局 | |
JP7252367B2 (ja) | 通信制御方法及び無線中継装置 | |
WO2021161891A1 (ja) | 通信制御方法 | |
US11019678B2 (en) | Telecommunications apparatus and methods | |
JP7052146B2 (ja) | 通信制御方法 | |
JP2023120360A (ja) | 通信制御方法 | |
US20220264400A1 (en) | Communication control method and wireless relay apparatus | |
WO2022210546A1 (ja) | 通信制御方法 | |
WO2022030575A1 (ja) | 通信制御方法 | |
JP7483864B2 (ja) | 通信制御方法、中継ノード、移動通信システム、チップセット及びプログラム | |
CN116671149A (zh) | 通信控制方法 | |
WO2020158253A1 (ja) | 中継装置及びその制御方法 | |
CN116897556A (zh) | 通信控制方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 20778801 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 2021509274 Country of ref document: JP Kind code of ref document: A |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 20778801 Country of ref document: EP Kind code of ref document: A1 |