WO2020196201A1 - 通信制御方法 - Google Patents

通信制御方法 Download PDF

Info

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
Application number
PCT/JP2020/012148
Other languages
English (en)
French (fr)
Inventor
真人 藤代
ヘンリー チャン
Original Assignee
京セラ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 京セラ株式会社 filed Critical 京セラ株式会社
Priority to JP2021509274A priority Critical patent/JP7303290B2/ja
Publication of WO2020196201A1 publication Critical patent/WO2020196201A1/ja
Priority to US17/483,248 priority patent/US20220015000A1/en
Priority to JP2023102558A priority patent/JP2023120373A/ja

Links

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

第１の態様に係る通信制御方法は、上位装置と下位装置との間の通信を無線で中継する中継装置を用いる方法である。前記通信制御方法は、前記中継装置において、前記上位装置と無線で接続するユーザ装置機能部が、前記下位装置と無線で接続する基地局機能部に対して状態情報を通知するステップを備える。前記状態情報は、前記ユーザ装置機能部のＲＲＣ状態、及び前記上位装置と前記ユーザ装置機能部との間の無線リンク状態のうち、少なくとも一方の状態を示す情報である。

Description

通信制御方法
　本開示は、移動通信システムに用いられる通信制御方法に関する。
　移動通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄ　Ｇｅｎｅｒａｔｉｏｎ　Ｐａｒｔｎｅｒｓｈｉｐ　Ｐｒｏｊｅｃｔ）において、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ　Ａｃｃｅｓｓ　ａｎｄ　Ｂａｃｋｈａｕｌ）ノードと称される新たな中継装置が検討されている。１又は複数の中継装置が基地局とユーザ機器との間の通信に介在し、この通信に対する中継を行う。かかる中継装置は、ユーザ機器機能及び基地局機能を有しており、ユーザ機器機能を用いて上位ノード（基地局又は上位の中継装置）との無線通信を行うとともに、基地局機能を用いて下位ノード（ユーザ機器又は下位の中継装置）との無線通信を行う。
　ユーザ機器と、中継装置又は基地局との間の無線区間は、アクセスリンクと称されることがある。中継装置と、基地局又は他の中継装置との間の無線区間は、バックホールリンクと称されることがある。３ＧＰＰ寄書「ＲＰ－１７０２１７」には、アクセスリンクのデータ通信及びバックホールリンクのデータ通信をレイヤ２において統合及び多重化し、バックホールリンクに動的に無線リソースを割り当てることにより、データ転送経路を動的に切り替える方法が記載されている。
　第１の態様に係る通信制御方法は、上位装置と下位装置との間の通信を無線で中継する中継装置を用いる方法である。前記通信制御方法は、前記中継装置において、前記上位装置と無線で接続するユーザ装置機能部が、前記下位装置と無線で接続する基地局機能部に対して状態情報を通知することを含む。前記状態情報は、前記ユーザ装置機能部のＲＲＣ状態、及び前記上位装置と前記ユーザ装置機能部との間の無線リンク状態のうち、少なくとも一方の状態を示す情報である。
　第２の態様に係る通信制御方法は、上位装置と下位装置との間の通信を無線で中継する中継装置を用いる方法である。前記通信制御方法は、前記中継装置において、前記下位装置と無線で接続する基地局機能部が、前記上位装置と無線で接続するユーザ装置機能部又は前記上位装置を介してドナー装置と通信する通信機能部に対して、状態情報を通知することを含む。前記状態情報は、前記基地局機能部と前記下位装置の間の無線リンク状態を示す情報である。
　第３の態様に係る通信制御方法は、上位装置と下位装置との間の通信を無線で中継する中継装置を用いる方法である。前記通信制御方法は、前記中継装置が、前記中継装置に接続する下位装置から、他の中継装置との無線リンク障害の発生を示す通知を受信することと、前記中継装置が、ドナー装置に対して、前記無線リンク障害に関するメッセージを送信することとを含む。
実施形態に係る移動通信システムの構成を示す図である。 実施形態に係る基地局（ｇＮＢ）の構成を示す図である。 実施形態に係る中継装置（ＩＡＢノード）の構成を示す図である。 実施形態に係るユーザ機器（ＵＥ）の構成を示す図である。 実施形態に係る移動通信システムにおけるユーザプレーンのプロトコルスタック構成の一例を示す図である。 第１実施形態に係る通常動作シーケンスの一例を示す図である。 第１実施形態に係るコンテキスト転送先を決定するためのテーブルの一例を示す図である。 第１実施形態に係る例外動作シーケンスの一例を示す図である。 第１実施形態に係るマルチホップ接続シーケンスの一例を示す図である。 ＲＬＦに関連する動作を示す図である。 第２実施形態に係るＩＡＢノードの動作を示す図である。 第２実施形態に係る動作シーケンスの一例を示す図である。 第２実施形態の変更例に係る動作シーケンスを示す図である。 第３実施形態に係る動作を示す図である。 第４実施形態に係るＩＡＢノードの動作を示す図である。 第４実施形態に係る動作の一例を示す図である。 付記に係る図である。 付記に係る図である。
　図面を参照しながら、実施形態に係る移動通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
　［第１実施形態］
　（移動通信システムの構成）
　本実施形態に係る移動通信システムの構成について説明する。図１は、本実施形態に係る移動通信システム１の構成を示す図である。移動通信システム１は、３ＧＰＰ規格に基づく第５世代（５Ｇ）移動通信システムである。具体的には、移動通信システム１における無線アクセス方式は、５Ｇの無線アクセス方式であるＮＲ（Ｎｅｗ　Ｒａｄｉｏ）である。但し、移動通信システム１には、ＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）が少なくとも部分的に適用されてもよい。
　図１に示すように、移動通信システム１は、５Ｇコアネットワーク（５ＧＣ）１０と、ユーザ機器（ＵＥ）１００と、基地局（ｇＮＢと称される）２００と、ＩＡＢノード３００とを備える。本実施形態において、基地局がＮＲ基地局である一例について主として説明するが、基地局がＬＴＥ基地局（すなわち、ｅＮＢ）であってもよい。
　５ＧＣ１０は、ＡＭＦ（Ａｃｃｅｓｓ　ａｎｄ　Ｍｏｂｉｌｉｔｙ　Ｍａｎａｇｅｍｅｎｔ　Ｆｕｎｃｔｉｏｎ）１１及びＵＰＦ（Ｕｓｅｒ　Ｐｌａｎｅ　Ｆｕｎｃｔｉｏｎ）１２を備える。ＡＭＦ１１は、ＵＥ１００に対する各種モビリティ制御等を行う装置である。ＡＭＦ１１は、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００が在圏するエリアの情報を管理する。ＵＰＦ１２は、ユーザデータの転送制御等を行う装置である。
　ｇＮＢ２００は、ＮＧインターフェイスと称されるインターフェイスを介して、５ＧＣ１０に接続される。図１において、５ＧＣ１０に接続された３つのｇＮＢ２００－１～ｇＮＢ２００－３を例示している。ｇＮＢ２００は、ＵＥ１００との無線通信を行う固定の無線通信装置である。ｇＮＢ２００がドナー機能を有する場合、ｇＮＢ２００は、自身に無線で接続するＩＡＢノードとの無線通信を行ってもよい。
　ｇＮＢ２００は、Ｘｎインターフェイスと称される基地局間インターフェイスを介して、隣接関係にある他のｇＮＢ２００と接続される。図１において、ｇＮＢ２００－１がｇＮＢ２００－２及びｇＮＢ２００－２に接続される一例を示している。
　各ｇＮＢ２００は、１又は複数のセルを管理する。セルは、無線通信エリアの最小単位を示す用語として用いられる。セルは、ＵＥ１００との無線通信を行う機能又はリソースを示す用語として用いられることがある。１つのセルは１つのキャリア周波数に属する。
　ＵＥ１００は、ｇＮＢ２００との無線通信を行う移動可能な無線通信装置である。ＵＥ１００は、ＩＡＢノード３００との無線通信を行ってもよい。ＵＥ１００は、ｇＮＢ２００又はＩＡＢノード３００との無線通信を行う装置であればどのような装置であってもよい。例えば、ＵＥ１００は、携帯電話端末やタブレット端末、ノートＰＣ、センサ若しくはセンサに設けられる装置、又は車両若しくは車両に設けられる装置である。
　図１において、ＵＥ１００－１がｇＮＢ２００－１に無線で接続され、ＵＥ１００－２がＩＡＢノード３００－１に無線で接続され、ＵＥ１００－３がＩＡＢノード３００－２に無線で接続される一例を示している。ＵＥ１００－１は、ｇＮＢ２００－１との通信を直接的に行う。ＵＥ１００－２は、ＩＡＢノード３００－１を介してｇＮＢ２００－１との通信を間接的に行う。ＵＥ１００－３は、ＩＡＢノード３００－１及びＩＡＢノード３００－２を介してｇＮＢ２００－１との通信を間接的に行う。
　ＩＡＢノード３００は、ｅＮＢ２００とＵＥ１００との間の通信に介在し、この通信に対する中継を行う装置（中継装置）である。図１において、ＩＡＢノード３００－１がドナーであるｇＮＢ２００－１に無線で接続され、ＩＡＢノード３００－２がＩＡＢノード３００－１に無線で接続される一例を示している。各ＩＡＢノード３００は、セルを管理する。ＩＡＢノード３００が管理するセルのセルＩＤは、ドナーｇＮＢ２００－１のセルのセルＩＤと同じであってもよいし、異なっていてもよい。
　ＩＡＢノード３００は、ＵＥ機能（ユーザ機器機能）及びｇＮＢ機能（基地局機能）を有する。ＩＡＢノード３００は、ＵＥ機能を用いて上位ノード（ｇＮＢ２００又は上位のＩＡＢノード３００）との無線通信を行うとともに、ｇＮＢ機能を用いて下位ノード（ＵＥ１００又は下位のＩＡＢノード３００）との無線通信を行う。なお、ＵＥ機能とは、ＵＥ１００が有する機能のうち少なくとも一部の機能を意味し、必ずしもＵＥ１００の全ての機能をＩＡＢノード３００が有していなくてもよい。ｇＮＢ機能とは、ｇＮＢ２００の機能のうち少なくとも一部の機能を意味し、必ずしもｇＮＢ２００の全ての機能をＩＡＢノード３００が有していなくてもよい。
　ＵＥ１００と、ＩＡＢノード３００又はｇＮＢ２００との間の無線区間は、アクセスリンク（或いは、Ｕｕ）と称されることがある。ＩＡＢノード３００と、ｇＮＢ２００又は他のＩＡＢノード３００との間の無線区間は、バックホールリンク（或いは、Ｕｎ）と称されることがある。かかるバックホールリンクは、フロントホールリンクと称されてもよい。
　アクセスリンクのデータ通信及びバックホールリンクのデータ通信をレイヤ２において統合及び多重化し、バックホールリンクのデータ通信に動的に無線リソースを割り当て、中継の経路を動的に切り替えることが可能である。なお、アクセスリンク及びバックホールリンクには、ミリ波帯が用いられてもよい。また、アクセスリンク及びバックホールリンクは、時分割及び／又は周波数分割により多重化されてもよい。
　（ｇＮＢの構成）
　本実施形態に係るｇＮＢ２００の構成について説明する。図２は、ｇＮＢ２００の構成を示す図である。図２に示すように、ｇＮＢ２００は、無線通信部２１０と、ネットワーク通信部２２０と、制御部２３０とを備える。
　無線通信部２１０は、ＵＥ１００との無線通信及びＩＡＢノード３００との無線通信に用いられる。無線通信部２１０は、受信部２１１及び送信部２１２を備える。受信部２１１は、制御部２３０の制御下で各種の受信を行う。受信部２１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部２３０に出力する。送信部２１２は、制御部２３０の制御下で各種の送信を行う。送信部２１２はアンテナを含み、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
　ネットワーク通信部２２０は、５ＧＣ１０との有線通信（又は無線通信）及び隣接する他のｇＮＢ２００との有線通信（又は無線通信）に用いられる。ネットワーク通信部２２０は、受信部２２１及び送信部２２２を備える。受信部２２１は、制御部２３０の制御下で各種の受信を行う。受信部２２１は、外部から信号を受信して受信信号を制御部２３０に出力する。送信部２２２は、制御部２３０の制御下で各種の送信を行う。送信部２２２は、制御部２３０が出力する送信信号を外部に送信する。
　制御部２３０は、ｇＮＢ２００における各種の制御を行う。制御部２３０は、少なくとも１つのプロセッサ及び少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサとＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）とを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
　（ＩＡＢノードの構成）
　本実施形態に係るＩＡＢノード３００の構成について説明する。図３は、ＩＡＢノード３００の構成を示す図である。図３に示すように、ＩＡＢノード３００は、無線通信部３１０と、制御部３２０とを備える。
　無線通信部３１０は、ｇＮＢ２００との無線通信（バックホールリンク）及びＵＥ１００との無線通信（アクセスリンク）に用いられる。無線通信部３１０は、受信部３１１及び送信部３１２を備える。受信部３１１は、制御部３２０の制御下で各種の受信を行う。受信部３１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部３２０に出力する。送信部３１２は、制御部３２０の制御下で各種の送信を行う。送信部３１２はアンテナを含み、制御部３２０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
　制御部３２０は、ＩＡＢノード３００における各種の制御を行う。制御部３２０は、少なくとも１つのプロセッサ及び少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
　（ＵＥの構成）
　本実施形態に係るＵＥ１００の構成について説明する。図４は、ＵＥ１００の構成を示す図である。図４に示すように、ＵＥ１００は、無線通信部１１０と、制御部１２０とを備える。
　無線通信部１１０は、アクセスリンクにおける無線通信、すなわち、ｇＮＢ２００との無線通信及びＩＡＢノード３００との無線通信に用いられる。無線通信部１１０は、受信部１１１及び送信部１１２を備える。受信部１１１は、制御部１２０の制御下で各種の受信を行う。受信部１１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１２０に出力する。送信部１１２は、制御部１２０の制御下で各種の送信を行う。送信部１１２はアンテナを含み、制御部１２０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
　制御部１２０は、ＵＥ１００における各種の制御を行う。制御部１２０は、少なくとも１つのプロセッサ及び少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
　（プロトコルスタック構成の一例）
　本実施形態に係る移動通信システム１におけるプロトコルスタック構成の一例について説明する。図５は、ユーザプレーンのプロトコルスタック構成の一例を示す図である。ここでは、図１に示したＵＥ１００－３と５ＧＣ１０のＵＰＦ１２との間のユーザデータ伝送に関するプロトコルスタック構成の一例について説明する。
　図５に示すように、ＵＰＦ１２は、ＧＴＰ－Ｕ（ＧＰＲＳ　Ｔｕｎｎｅｌｉｎｇ　Ｐｒｏｔｏｃｏｌ　ｆｏｒ　Ｕｓｅｒ　Ｐｌａｎｅ）と、ＵＤＰ（Ｕｓｅｒ　Ｄａｔａｇｒａｍ　Ｐｒｏｔｏｃｏｌ）と、ＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）と、レイヤ１／レイヤ２（Ｌ１／Ｌ２）とを備える。ｇＮＢ２００－１（ドナーｇＮＢ）には、これらに対応するプロトコルスタックが設けられる。
　また、ｇＮＢ２００－１は、集約ユニット（ＣＵ：Ｃｅｎｔｒａｌ　Ｕｎｉｔ）と分散ユニット（ＤＵ：Ｄｉｓｔｒｉｂｕｔｅｄ　Ｕｎｉｔ）とを備える。無線インターフェイスのプロトコルスタックのうちＰＤＣＰ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｃｏｎｖｅｒｇｅｎｃｅ　Ｐｒｏｔｏｃｏｌ）以上の各レイヤをＣＵが有し、ＲＬＣ（Ｒａｄｉｏ　Ｌｉｎｋ　Ｃｏｎｔｒｏｌ）以下の各レイヤをＤＵが有する。ＣＵ及びＤＵは、Ｆ１インターフェイスと称されるインターフェイスを介して接続される。
　具体的には、ＣＵは、ＳＤＡＰ（Ｓｅｒｖｉｃｅ　Ｄａｔａ　Ａｄａｐｔａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）と、ＰＤＣＰと、ＩＰと、Ｌ１／Ｌ２とを備える。ＣＵのＳＤＡＰ及びＰＤＣＰは、ＤＵと、ＩＡＢノード３００－１と、ＩＡＢノード３００－２とを介して、ＵＥ１００のＳＤＡＰ及びＰＤＣＰとの通信を行う。
　また、ＤＵは、無線インターフェイスのプロトコルスタックのうち、ＲＬＣと、アダプテーションレイヤ（Ａｄａｐｔ）と、ＭＡＣ（Ｍｅｄｉｕｍ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）と、ＰＨＹ（Ｐｈｙｓｉｃａｌ　ｌａｙｅｒ）とを有する。これらのプロトコルスタックは、ｇＮＢ向けのプロトコルスタックである。なお、アダプテーションレイヤ及びＲＬＣ（Ｓ－ＲＬＣ）は上下関係が逆であってもよい。
　ＩＡＢノード３００－１には、これらに対応するＵＥ向けのプロトコルスタックＳＴ１が設けられる。さらに、ＩＡＢノード３００－１には、ｇＮＢ向けのプロトコルスタックＳＴ２が設けられる。プロトコルスタックＳＴ１及びプロトコルスタックＳＴ２は、何れもレイヤ２以下の各レイヤ（各サブレイヤ）からなる。すなわち、ＩＡＢノード３００－１は、レイヤ２以下の各レイヤを用いてユーザデータの中継を行うレイヤ２中継装置である。ＩＡＢノード３００－１は、レイヤ３以上のレイヤ（具体的には、ＰＤＣＰ以上のレイヤ）を用いることなくデータ中継を行う。なお、ＩＡＢノード３００－２は、ＩＡＢノード３００－１と同様なプロトコルスタック構成を有する。
　ここではユーザプレーンにおけるプロトコルスタック構成について説明した。しかしながら、制御プレーンにおいて、ｇＮＢ２００－１、ＩＡＢノード３００－１、ＩＡＢノード３００－２、及びＵＥ１００－３のそれぞれは、レイヤ３に相当するＲＲＣ（Ｒａｄｉｏ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌ）を備える。
　ｇＮＢ２００－１（ドナーｇＮＢ）のＲＲＣとＩＡＢノード３００－１のＲＲＣとの間にＲＲＣ接続が確立され、このＲＲＣ接続を用いてＲＲＣメッセージが送受信される。また、ｇＮＢ２００－１のＲＲＣとＩＡＢノード３００－２のＲＲＣとの間にＲＲＣ接続が確立され、このＲＲＣ接続を用いてＲＲＣメッセージが送受信される。さらに、ｇＮＢ２００－１のＲＲＣとＵＥ１００－３のＲＲＣとの間にＲＲＣ接続が確立され、このＲＲＣ接続を用いてＲＲＣメッセージが送受信される。
　（移動通信システムにおける動作）
　本実施形態に係る移動通信システム１における動作について説明する。具体的には、ＩＡＢノード３００－１がｇＮＢ２００－１（ドナーｇＮＢ）に無線で接続する場合の動作について説明する。
　かかる場合、最初に、ＩＡＢノード３００－１は、ＵＥ機能を用いてｇＮＢ２００－１とのアクセスリンク接続（第１の無線接続）を確立する。言い換えると、ＩＡＢノード３００－１は、ＵＥ１００として振る舞ってｇＮＢ２００－１とのアクセスリンク接続を確立する。アクセスリンク接続の確立は、ＲＲＣ接続の確立を含む。
　次に、ｇＮＢ２００－１は、アクセスリンク接続を維持しつつ、ＩＡＢノード３００－１のｇＮＢ機能のためのバックホールリンク接続（第２の無線接続）をＩＡＢノード３００－１とｇＮＢ２００－１との間に確立させるメッセージをＩＡＢノード３００－１に送信する。本実施形態において、かかるメッセージは、ＲＲＣ接続を用いて送受信されるＲＲＣ再設定（ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージである。
　その結果、バックホールリンク接続がＩＡＢノード３００－１とｇＮＢ２００－１との間に確立されるため、ＩＡＢノード３００－１とｇＮＢ２００－１との間でバックホールリンクの通信を適切に開始可能とすることができる。
　バックホールリンク接続を確立させるＲＲＣ再設定メッセージは、バックホールリンク接続を構成するベアラ（又はＬ２リンク）の設定情報、及びＩＡＢノード３００－１が送信するべきセルＩＤ（具体的には、セルＩＤに関連付けられた参照信号及び同期信号の送信設定）を含んでもよい。以下において、かかるＲＲＣ再設定メッセージをＩＡＢノード設定メッセージと称する。
　ＩＡＢノード設定メッセージは、デフォルトベアラ（又はデフォルトリンク）の設定情報を含んでもよい。デフォルトベアラ（又はデフォルトリンク）は、例えば、ＳＩＢ（Ｓｙｓｔｅｍ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｂｌｏｃｋ）の中継やＵＥからのＭｓｇ３中継などを行うためのベアラ（又はリンク）である。
　ＩＡＢノード設定メッセージは、ドナーｇＮＢ２００－１側のスタックの設定情報と、オプションでＩＡＢノード３００－２（又はＵＥ１００）側のスタックの設定情報とを含んでもよい。ＩＡＢノード３００－２（又はＵＥ１００）側のスタックの設定情報は、暗示的にドナーｇＮＢ２００－１のＳＩＢで報知されている設定群を再利用してもよいし、オペレータ（ＯＡＭ）から（事前に）設定されてもよい。
　ＩＡＢノード設定メッセージにおける設定内容としては、基本的にＲＲＣ再設定メッセージに含まれる設定全てが対象になり得るが、ＲＬＣ設定（ＡＭ：Ａｃｋｎｏｗｌｅｄｇｅｄ　Ｍｏｄｅ／ＵＭ：Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ　Ｍｏｄｅ／ＴＭ：Ｔｒａｎｓｐａｒｅｎｔ　Ｍｏｄｅ等の動作モード、ＬＣＰ（Ｌｏｇｉｃａｌ　Ｃｈａｎｎｅｌ　Ｐｒｉｏｒｉｔｉｚａｔｉｏｎ）パラメータ等）、ＭＡＣ設定（ＢＳＲ：Ｂｕｆｆｅｒ　Ｓｔａｔｕｓ　Ｒｅｐｏｒｔ／ＴＡＧ：Ｔｉｍｉｎｇ　Ａｄｖａｎｃｅ　Ｇｒｏｕｐ／ＰＨＲ：Ｐｏｗｅｒ　Ｈｅａｄｒｏｏｍパラメータ、ＤＲＸ：Ｄｉｓｃｏｎｔｉｎｕｅｓ　Ｒｅｃｅｐｔｉｏｎ設定等）、ＰＨＹ設定が含まれてもよい。
　また、ＩＡＢノード設定メッセージにおける設定内容には、アダプテーションレイヤの設定（下位側又は上位側の論理チャネルのマッピング（ルーティング）設定、優先度設定等）が含まれてもよい。
　さらに、ＩＡＢノード設定メッセージにおける設定内容には、必要に応じて、ＩＡＢノード３００－１の（仮想的な）ＩＰアドレス（すなわち、Ｌ３アドレス）を含めてもよい。これは、例えばＦ１インターフェイスをＬ２リンク上に確立するために、Ｆ１のプロトコルスタックがＳＣＴＰ　ｏｖｅｒ　ＩＰを想定しているためである。
　なお、ＩＡＢノード設定メッセージにおける設定内容は、ＮＲプロトコルの設定情報に限らず、ＬＴＥプロトコル（ＲＬＣ、ＭＡＣ、ＰＨＹ）の設定情報であってもよい。
　本実施形態において、ＩＡＢノード３００－１は、バックホールリンク接続を確立するよりも前に、ＩＡＢノードの機能（すなわち、レイヤ２中継機能）を有すること又はバックホールリンク接続の確立を要求することを示すインディケーションをｇＮＢ２００－１に送信してもよい。これにより、ｇＮＢ２００－１は、バックホールリンク接続を確立するためのプロシージャを適切に開始できる。以下において、かかるインディケーションをＩＡＢインディケーションと称する。ＩＡＢインディケーションは、ＩＡＢノード３００－１におけるＵＥ機能向けリンクプロトコルスタックをＬＴＥで準備するのか、ＮＲで準備するのか、もしくはその両方か、という意図又は能力を示す情報を含んでもよい。
　なお、ＩＡＢノード３００－１は、ｇＮＢ２００－１とのアクセスリンク接続の確立後にＩＡＢインディケーションを送信してもよいし、ｇＮＢ２００－１とのアクセスリンク接続を確立するプロシージャ中にＩＡＢインディケーションを送信してもよい。
　また、ＩＡＢインディケーションをｇＮＢに送信可能とする条件として、このｇＮＢから、ドナー機能を有することを示すドナー機能識別子を含むＳＩＢを受信しているという条件があってもよい。かかる場合、ＩＡＢノード３００－１は、ｇＮＢ２００－１からＳＩＢによりドナー機能識別子を受信している場合に限り、ｇＮＢ２００－１に対してＩＡＢインディケーションを送信する。
　本実施形態において、ＩＡＢノード３００－１とのバックホールリンク接続を確立するドナー機能をｇＮＢ２００－１が有する場合がある。この場合、ｇＮＢ２００－１は、ＩＡＢノード３００－１からＩＡＢインディケーションを受信した後、ＩＡＢノード設定メッセージをＩＡＢノード３００－１に送信する。一方、ドナー機能をｇＮＢ２００－１が有しない場合、ｇＮＢ２００－１は、ＩＡＢノード３００－１からＩＡＢインディケーションを受信した後、ＩＡＢノード設定メッセージをＩＡＢノード３００－１に送信することに代えて、ＩＡＢノード３００－１のハンドオーバを要求するハンドオーバ要求を他のｇＮＢに送信してもよい。ここで、ｇＮＢ２００－１は、ドナー機能を有する他のｇＮＢの情報を予め記憶していることが好ましい。ｇＮＢ２００－１は、ドナー機能を有する他のｇＮＢの情報をＩＡＢノード３００－１から取得してもよい。ＩＡＢノード３００－１は、５ＧＣ１０（コアネットワーク）から情報を入手、もしくは隣接セルのＳＩＢ（ドナー機能識別子）を確認する。これにより、ＩＡＢノード３００－１は、ドナー機能を有する他のｇＮＢ（隣接セル）の情報を取得し、取得した情報をｇＮＢ２００－１に通知する。ｇＮＢ２００－１は、記憶している情報又はＩＡＢノード３００－１から取得した情報に基づいて、ドナー機能を有する他のｇＮＢに対してハンドオーバ要求を送信する。これにより、ＩＡＢノード３００－１を他のｇＮＢにハンドオーバさせた後に、ＩＡＢノード３００－１が当該他のｇＮＢとのバックホールリンク接続を確立できる。或いは、ドナー機能をｇＮＢ２００－１が有しない場合、ＩＡＢノード３００－１は、５ＧＣ１０に対して、ドナー機能を有するセル（ｇＮＢ）へハンドオーバさせることを要求し、５ＧＣ１０がハンドオーバに係る処理を行ってもよい。
　本実施形態において、ｇＮＢ２００－１は、ＩＡＢノード３００－１からＩＡＢインディケーションを受信したことに応じて、無線測定を設定する測定設定をＩＡＢノード３００－１に送信してもよい。ＩＡＢノード３００－１は、ｇＮＢ２００－１から測定設定を受信した後、無線測定の結果を含む測定報告をｇＮＢ２００－１に送信する。ｇＮＢ２００－１は、ＩＡＢノード３００－１からの測定報告に基づいて、自身（ｇＮＢ２００－１）が適切なドナーｇＮＢであるか又は他のｇＮＢが適切なドナーｇＮＢであるかを判断する。例えば、ｇＮＢ２００－１は、測定報告に基づいて、自身（ｇＮＢ２００－１）に対する測定結果よりも他のｇＮＢに対する測定結果が良好であり、かつ、これらの測定報告の差が閾値よりも大きい場合に、他のｇＮＢが適切なドナーｇＮＢであると判断する。そうでなければ、ｇＮＢ２００－１は、自身が適切なドナーｇＮＢであると判断する。
　そして、自身（ｇＮＢ２００－１）が適切なドナーｇＮＢ２００－１であると判断した場合、ｇＮＢ２００－１は、ＩＡＢノード設定メッセージをＩＡＢノード３００－１に送信する。一方、他のｇＮＢが適切なドナーｇＮＢであると判断した場合、ｇＮＢ２００－１は、ＩＡＢノード設定メッセージをＩＡＢノード３００－１に送信することに代えて、ＩＡＢノード３００－１のハンドオーバを要求するハンドオーバ要求を当該他のｇＮＢに送信する。これにより、ＩＡＢノード３００－１をより無線状態の良好な他のｇＮＢにハンドオーバさせて、ＩＡＢノード３００－１が当該他のｇＮＢとのバックホールリンク接続を確立できる。
　本実施形態において、ｇＮＢ２００－１は、バックホールリンク接続の確立後、ＩＡＢノード３００－１に関するコンテキスト情報を他のｇＮＢに送信してもよい。このコンテキスト情報は、無線側のＡＳレイヤの接続設定（ＲＲＣ再設定の内容）、ネットワーク側のＰＤＵセッションリソース設定（ＡＭＦ又はＲＡＮ（Ｒａｄｉｏ　Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）のＵＥ　ＩＤ、セッションＩＤ、ＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）／スライス設定等）、その他関連情報（ＩＡＢノードの挙動や通信などの履歴情報、及び／又はプリファレンス情報などを含む。
　具体的には、ｇＮＢ２００－１は、ＩＡＢノード３００－１を他のｇＮＢにハンドオーバさせるという判断を行っていなくても、ＩＡＢノード３００－１に関するコンテキスト情報を予め他のｇＮＢに送信する。これにより、ｇＮＢ２００－１とＩＡＢノード３００－１との間の無線状態が悪化し、ＩＡＢノード３００－１が他のｇＮＢとの無線接続を再確立する場合に、予め共有したコンテキスト情報を用いて速やかな再確立を行うことができる。
　ここで、ｇＮＢ２００－１は、ＩＡＢノード３００－１とＩＡＢノード３００－１のドナーｇＮＢの候補とを対応付けるテーブルを保持していることが好ましい。ｇＮＢ２００－１は、テーブル中の候補である他のｇＮＢに対してコンテキスト情報を送信する。これにより、ｇＮＢ２００－１は、コンテキスト情報を適切な他のｇＮＢと共有できる。
　（１）通常動作シーケンスの一例
　図６は、本実施形態に係る移動通信システム１における通常動作シーケンスの一例を示す図である。
　図６に示すように、ステップＳ１０１において、ＩＡＢノード３００－１は、例えばｇＮＢ２００－１に対してランダムアクセスプロシージャを行うことにより、ｇＮＢ２００－１とのアクセスリンク接続（ＲＲＣ接続）を確立する。ＩＡＢノード３００－１は、ランダムアクセスプロシージャ中にｇＮＢ２００－１に送信するメッセージ（例えば、Ｍｓｇ３）にＩＡＢインディケーションを含めてもよい。また、ｇＮＢ２００－１は、ステップＳ１０１において、ＩＡＢノード３００－１に関するコンテキスト情報を取得する。
　ステップＳ１０２において、ＩＡＢノード３００－１は、ｇＮＢ２００－１を介して、５ＧＣ１０（具体的には、ＡＭＦ１１）に対するアタッチプロシージャを行う。ここで、ＩＡＢノード３００－１は、ＩＡＢインディケーションのような通知（つまり、ＩＡＢノードとして動作したいことを示す通知）をＡＭＦ１１に通知してもよい。これにより、ＩＡＢノード３００－１は、ＡＭＦ１１から、ドナーｇＮＢ（セル）の候補リストや下位ノードの有無などのルーティング情報、その他管理情報などを入手してもよい。もしくは、ＡＭＦ１１からドナーｇＮＢの各候補に対して、ＩＡＢノード３００－１のアタッチがあった旨や、ＩＡＢノード３００－１のルーティング情報などのコンテキスト情報を通知してもよい。なお、ＩＡＢノード３００－１が既にアタッチしている場合は、ステップＳ１０２におけるアタッチ処理を省略可能である。具体的には、ＩＡＢノード３００－１は、ステップＳ１０１において、ＲＲＣ再確立（Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）などのように、何らかのエラー発生によってドナーｇＮＢとの接続を再確立しなければならない場合などにおいて、アタッチ処理を省略する。
　ステップＳ１０３において、ＩＡＢノード３００－１は、ＩＡＢインディケーションをｇＮＢ２００－１に送信する。ＩＡＢノード３００－１は、次のイベントのうち１又は複数が満たされたことをトリガとしてＩＡＢインディケーションを送信してもよい。
　・Ｍｓｇ５（ＲＲＣ　Ｃｏｍｐｌｅｔｅ）を送信する際。
　・ｇＮＢとの接続が確立した際（Ｍｓｇ５以降でもよい。例えば最初のＲＲＣ再設定が行われた際）。
　・ＡＭＦからＩＡＢ設定情報（上記参照）を入手した際（既にＩＡＢ設定情報を持っている場合も含む）。
　・単純にＩＡＢノードとして動作したくなった際（上位レイヤからＩＡＢノードとして動作する指示を受信したことを含む）。
　・下位のＩＡＢノード３００－２又はＵＥ１００－３からＩＡＢノードとなるように要求された場合（その旨の要求を示す信号を下位のＩＡＢノード３００－２又はＵＥ１００－３から受信した場合）。
　・下位のＩＡＢノード３００－２又はＵＥ１００－３が既に接続している場合。
　ＩＡＢノード３００－１は、例えばｇＮＢ２００－１に送信するＲＲＣメッセージにＩＡＢインディケーションを含める。かかるＲＲＣメッセージは、ＵＥとしての能力を示す「ＵＥ　Ｃａｐａｂｉｌｉｔｙ　Ｉｎｆｏｒｍａｔｉｏｎ」メッセージであってもよい。但し、ステップＳ１０１においてＩＡＢインディケーションを送信している場合、ステップＳ１０３は省略可能である。
　或いは、ＩＡＢインディケーションは、ＡＭＦ１１からＰＤＵセッションリソースの変更という形でｇＮＢ２００－１に通知されてもよい。なお、ＡＭＦは、ＩＡＢ管理用（専用）のＡＭＦであってもよい。
　本通常動作シーケンスにおいては、ｇＮＢ２００－１がドナー能力を有すると仮定して説明を進める。ｇＮＢ２００－１は、ＩＡＢインディケーションに基づいて、バックホールリンク接続をＩＡＢノード３００－１に確立させる必要があると判断する。
　ステップＳ１０４において、ｇＮＢ２００－１は、無線測定を設定する測定設定をＩＡＢノード３００－１に送信する。ＩＡＢノード３００－１は、測定設定に基づいて無線測定を行う。例えば、ＩＡＢノード３００－１は、現在のサービングセルであるｇＮＢ２００－１のセルと、隣接セルであるｇＮＢ２００－２のセルとに対して受信電力（セル固有参照信号の受信電力）の測定を行う。
　ステップＳ１０５において、ＩＡＢノード３００－１は、無線測定の結果を含む測定報告をｇＮＢ２００－１に送信する。ｇＮＢ２００－１は、測定報告に基づいて、自身（ｇＮＢ２００－１）が適切なドナーｇＮＢであるか又は他のｇＮＢが適切なドナーｇＮＢであるかを判断する。ここでは、ｇＮＢ２００－１が、自身（ｇＮＢ２００－１）が適切なドナーｇＮＢであると判断したと仮定して説明を進める。なお、ステップＳ１０４及びステップＳ１０５の処理は必須ではなく、省略してもよい。
　ステップＳ１０６において、ｇＮＢ２００－１は、ＩＡＢノード設定メッセージ（ＲＲＣ再設定メッセージ）をＩＡＢノード３００－１に送信する。ＩＡＢノード設定メッセージは、ｇＮＢ２００－１のセル（すなわち、ＩＡＢノード３００－１の現在のサービングセル）をハンドオーバ先として指定するハンドオーバ指示を含んでもよい。ＩＡＢノード３００－１は、ＩＡＢノード設定メッセージに基づいて、バックホールリンク接続をｇＮＢ２００－１と確立する処理を行う。かかる確立処理は、ＩＡＢノード設定メッセージ中の設定情報に基づいて、バックホールリンク用のプロトコルスタック（アダプテーション／ＲＬＣ／ＭＡＣ／ＰＨＹエンティティ）を生成したり、パラメータ設定したりする処理を含む。かかる確立処理は、ＵＥ側（のアクセスリンク用）のプロトコルスタックを準備して、同期信号やセル固有参照信号の送信を開始する処理（もしくは、開始する準備をする処理）を含んでもよい。
　ステップＳ１０７において、ＩＡＢノード３００－１は、バックホールリンク接続の確立を含むＩＡＢノード設定が完了したことを示す完了通知メッセージをｇＮＢ２００－１に送信する。ステップＳ１０７以降は、ＩＡＢノード３００－１はｇＮＢ２００－１に対してＵＥとして振る舞うのではなく、ＩＡＢノードとして振る舞う。
　ステップＳ１０８において、ｇＮＢ２００－１は、ステップＳ１０１において取得したコンテキスト情報を、Ｘｎインターフェイス上でｇＮＢ２００－２に転送する。ｇＮＢ２００－１は、ＩＡＢノード３００－１とＩＡＢノード３００－１のドナーｇＮＢの候補とを対応付けるテーブルを保持しており、このテーブルを参照してコンテキスト転送先を決定する。このようにして、ｇＮＢ２００－１が、他のｇＮＢに対してコンテキストを事前に転送しておけば、ＩＡＢノード３００－１と接続しているｇＮＢとの無線接続状態が悪化した場合に、直ぐに、当該他のｇＮＢとの再接続を確立することができる。図７は、コンテキスト転送先を決定するためのテーブルの一例を示す図である。かかるテーブルは、例えばオペレータにより各ｇＮＢに対して予め設定される。図７に示すように、テーブルにおいて、ＩＡＢノードごとに、そのドナーｇＮＢの候補が対応けられている。具体的には、ＩＡＢノードに関する識別子ごとに、そのドナーｇＮＢの候補の識別子が対応けられている。例えば、ＩＡＢノードに地理的に近いｇＮＢがそのＩＡＢノードのドナーｇＮＢの候補として設定される。なお、図７のテーブルは、ｇＮＢとの対応付けの例を示したが、セルＩＤとの対応付けであってもよい。セルＩＤは、物理レイヤセルＩＤでもよく、グローバルセルＩＤでもよい。なお、ｇＮＢ２００－１は、ＩＡＢノード３００－１から受信した測定報告に基づいて、ＩＡＢノード３００－１に地理的に近いｇＮＢ２００－１をドナー候補として決定してもよい。ｇＮＢ２００－１は、当該決定したドナー候補に基づいて、ＩＡＢノード３００－１と当該ＩＡＢノード３００－１のドナーｇＮＢの候補とを対応付けるテーブルを作成又は既存のテーブルを更新してもよい。
　ステップＳ１０９において、ｇＮＢ２００－１は、ＩＡＢノード３００－１とのバックホールリンク接続を確立したことを示す通知を５ＧＣ１０に送信する。もしくは、ｇＮＢ２００－１は、ＩＡＢノード用のＰＤＵセッションの確立要求を５ＧＣ１０に送信してもよい。なお、上述したように、ＰＤＵセッションの確立要求は、ステップＳ１０９よりも先に又はステップＳ１０９においてＡＭＦ１１からｇＮＢ２００－１に送信されてもよい。
　（２）例外動作シーケンスの一例
　図８は、本実施形態に係る移動通信システム１における例外動作シーケンスの一例を示す図である。例外動作シーケンスにおいて、ｇＮＢ２００－１は、ＩＡＢノード３００－１をｇＮＢ２００－２にハンドオーバさせる。
　図８に示すように、ステップＳ２０１において、ＩＡＢノード３００－１は、例えばｇＮＢ２００－１に対してランダムアクセスプロシージャを行うことにより、ｇＮＢ２００－１とのアクセスリンク接続（ＲＲＣ接続）を確立する。ＩＡＢノード３００－１は、ランダムアクセスプロシージャ中にｇＮＢ２００－１に送信するメッセージ（例えば、Ｍｓｇ３）にＩＡＢインディケーションを含めてもよい。また、ｇＮＢ２００－１は、ステップＳ２０１において、ＩＡＢノード３００－１に関するコンテキスト情報を取得する。
　ステップＳ２０２において、ＩＡＢノード３００－１は、ｇＮＢ２００－１を介して、５ＧＣ１０（具体的には、ＡＭＦ１１）に対するアタッチプロシージャを行う。
　ステップＳ２０３において、ＩＡＢノード３００－１は、ＩＡＢインディケーションをｇＮＢ２００－１に送信する。ＩＡＢノード３００－１は、例えばｇＮＢ２００－１に送信するＲＲＣメッセージにＩＡＢインディケーションを含める。かかるＲＲＣメッセージは、ＵＥの能力を示す「ＵＥ　Ｃａｐａｂｉｌｉｔｙ　Ｉｎｆｏｒｍａｔｉｏｎ」メッセージであってもよい。但し、ステップＳ２０１においてＩＡＢインディケーションを送信している場合、ステップＳ２０３は省略可能である。
　ステップＳ２０４において、ｇＮＢ２００－１は、自身がドナー能力を有するか否かを判断する。ｇＮＢ２００－１がドナー能力を有しない場合（ステップＳ２０４：ＮＯ）、ｇＮＢ２００－１は、処理をステップＳ２０８に進める。
　ｇＮＢ２００－１がドナー能力を有する場合（ステップＳ２０４：ＹＥＳ）、ステップＳ２０５において、ｇＮＢ２００－１は、無線測定を設定する測定設定をＩＡＢノード３００－１に送信する。ＩＡＢノード３００－１は、測定設定に基づいて無線測定を行う。例えば、ＩＡＢノード３００－１は、現在のサービングセルであるｇＮＢ２００－１のセルと、隣接セルであるｇＮＢ２００－２のセルとに対して受信電力（セル固有参照信号の受信電力）の測定を行う。
　ステップＳ２０６において、ＩＡＢノード３００－１は、無線測定の結果を含む測定報告をｇＮＢ２００－１に送信する。
　ステップＳ２０７において、ｇＮＢ２００－１は、測定報告に基づいて、自身（ｇＮＢ２００－１）が適切なドナーｇＮＢであるか又は他のｇＮＢが適切なドナーｇＮＢであるかを判断する。自身（ｇＮＢ２００－１）が適切なドナーｇＮＢであると判断した場合（ステップＳ２０７：ＹＥＳ）、ｇＮＢ２００－１は、上述した通常動作シーケンス（図６参照）のステップＳ１０６に処理を進める。
　一方、他のｇＮＢが適切なドナーｇＮＢであると判断した場合（ステップＳ２０７：ＮＯ）、ｇＮＢ２００－１は、ステップＳ２０８に処理を進める。
　ステップＳ２０８において、ｇＮＢ２００－１は、ＩＡＢノード３００－１から受信したＩＡＢインディケーションを含むハンドオーバ要求メッセージをＸｎインターフェイス上でｇＮＢ２００－２に転送する。ｇＮＢ２００－１は、ステップＳ２０１において取得したコンテキスト情報をハンドオーバ要求メッセージに含めてもよい。または、ｇＮＢ２００－１は、ハンドオーバ要求メッセージに、ＩＡＢインディケーションを含める代わりに、ＩＡＢノード３００－１がｇＮＢに対してドナーｇＮＢとして機能することを要求する旨を示す情報を含めて送信してもよい。なお、ステップＳ２０８において、ｇＮＢ２００－１は、ｇＮＢ２００－２がドナー能力を有すると判断した上で、ハンドオーバ要求メッセージをＸｎインターフェイス上でｇＮＢ２００－２に転送してもよい。具体的には、例えば、ｇＮＢ２００－１は、図７に示すテーブルにおいて、ＩＡＢノード３００－１にドナー候補としてｇＮＢ２００－２が対応付けられていると判断した場合に、ハンドオーバ要求メッセージをｇＮＢ２００－２に対して転送してもよい。この場合、ｇＮＢ２００－２がハンドオーバ要求を拒否する可能性が低減されるため、ＩＡＢノード３００－１のハンドオーバをより早急に実行することができる。または、互いに隣接する複数のｇＮＢ２００間でＸｎインターフェイスを介して、自身のドナー能力に関する情報を事前に共有してもよい。これによって、ｇＮＢ２００－１は、ドナー能力を有する隣接のｇＮＢ２００を特定することができ、当該特定した隣接のｇＮＢ２００に対してハンドオーバ要求メッセージを転送することができる。
　ｇＮＢ２００－２は、ハンドオーバ要求メッセージに含まれるＩＡＢインディケーションも考慮して、ＩＡＢノード３００－１のハンドオーバを受け入れるか否かを判断する。ｇＮＢ２００－２は、自身がドナー能力を有しない場合には、ハンドオーバ要求を拒否してもよい。ここではｇＮＢ２００－２がＩＡＢノード３００－１のハンドオーバを受け入れると判断したと仮定して説明を進める。
　ステップＳ２０９において、ｇＮＢ２００－２は、ハンドオーバ肯定応答メッセージをＸｎインターフェイス上でｇＮＢ２００－１に送信する。
　ステップＳ２１０において、ｇＮＢ２００－１は、ｇＮＢ２００－２からのハンドオーバ肯定応答メッセージに基づいて、ハンドオーバ指示メッセージ（ＲＲＣ再設定メッセージ）をＩＡＢノード３００－１に送信する。ハンドオーバ指示メッセージは、ハンドオーバ先のｇＮＢ２００－２（のセル）を指定する情報を含む。
　ステップＳ２１１において、ＩＡＢノード３００－１は、ｇＮＢ２００からのハンドオーバ指示メッセージに基づいて、ｇＮＢ２００－２へのハンドオーバを行う。
　（３）マルチホップ接続シーケンスの一例
　図９は、本実施形態に係る移動通信システム１におけるマルチホップ接続シーケンスの一例を示す図である。マルチホップ接続シーケンスは、ＩＡＢノード３００－１とｇＮＢ２００－１との間にバックホールリンク接続が接続された後において、ＩＡＢノード３００－１にＩＡＢノード３００－２又はＵＥ１００－２が接続する場合のシーケンスである。ここではＩＡＢノード３００－１にＩＡＢノード３００－２が接続する場合について主として説明するが、ＩＡＢノード３００－２をＵＥ１００－２と適宜読み替えてもよい。また、上述した「（１）通常動作シーケンス」と重複する説明を省略する。
　図９に示すように、ステップＳ３０１において、ＩＡＢノード３００－２は、ＩＡＢノード３００－１を介してｇＮＢ２００－１に対してランダムアクセスプロシージャを行うことにより、ｇＮＢ２００－１とのアクセスリンク接続（ＲＲＣ接続）を確立する。ＩＡＢノード３００－２は、ランダムアクセスプロシージャ中にｇＮＢ２００－１に送信するメッセージ（例えば、Ｍｓｇ３）にＩＡＢインディケーションを含めてもよい。また、ｇＮＢ２００－１は、ステップＳ３０１において、ＩＡＢノード３００－２に関するコンテキスト情報を取得する。
　ステップＳ３０２において、ＩＡＢノード３００－２は、ＩＡＢノード３００－２及びｇＮＢ２００－１を介して、５ＧＣ１０（具体的には、ＡＭＦ１１）に対するアタッチプロシージャを行う。ここで、ＩＡＢノード３００－２は、ＩＡＢインディケーションのような通知（つまり、ＩＡＢノードとして動作したいことを示す通知）をＡＭＦ１１に通知してもよい。これにより、ＩＡＢノード３００－２は、ＡＭＦ１１から、ドナーｇＮＢ（セル）の候補リストや下位ノードの有無などのルーティング情報、その他管理情報などを入手してもよい。もしくは、ＡＭＦ１１からドナーｇＮＢの各候補に対して、ＩＡＢノード３００－２のアタッチがあった旨や、ＩＡＢノード３００－２のルーティング情報などのコンテキスト情報を通知してもよい。なお、ＩＡＢノード３００－２が既にアタッチしている場合は、ステップＳ３０２におけるアタッチ処理を省略可能である。具体的には、ＩＡＢノード３００－２は、ＲＲＣ再確立（Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）などのように、何らかのエラー発生によってドナーｇＮＢとの接続を再確立しなければならない場合などにおいて、アタッチ処理を省略する。
　ステップＳ３０３において、ＩＡＢノード３００－２は、ＩＡＢノード３００－１を介してＩＡＢインディケーションをｇＮＢ２００－１に送信する。ＩＡＢノード３００－２は、上述した「（１）通常動作シーケンス」のステップＳ１０３において説明したトリガと同様なトリガに応じてＩＡＢインディケーションを送信してもよい。
　ＩＡＢノード３００－２は、例えばｇＮＢ２００－１に送信するＲＲＣメッセージにＩＡＢインディケーションを含める。かかるＲＲＣメッセージは、ＵＥとしての能力を示す「ＵＥ　Ｃａｐａｂｉｌｉｔｙ　Ｉｎｆｏｒｍａｔｉｏｎ」メッセージであってもよい。但し、ステップＳ３０１においてＩＡＢインディケーションを送信している場合、ステップＳ３０３は省略可能である。
　或いは、ＩＡＢインディケーションは、ＡＭＦ１１からＰＤＵセッションリソースの変更という形でｇＮＢ２００－１に通知されてもよい。なお、ＡＭＦは、ＩＡＢ管理用（専用）のＡＭＦであってもよい。
　本動作シーケンスにおいては、ｇＮＢ２００－１がドナー能力を有すると仮定している。そのため、ｇＮＢ２００－１は、ＩＡＢインディケーションに基づいて、バックホールリンク接続をＩＡＢノード３００－１とＩＡＢノード３００－２との間に確立させる必要があると判断する。
　ステップＳ３０４において、ｇＮＢ２００－１は、無線測定を設定する測定設定をＩＡＢノード３００－２に送信する。ＩＡＢノード３００－２は、測定設定に基づいて無線測定を行う。
　ステップＳ３０５において、ＩＡＢノード３００－２は、無線測定の結果を含む測定報告を、ＩＡＢノード３００－１を介してｇＮＢ２００－１に送信する。ｇＮＢ２００－１は、測定報告に基づいて、自身（ｇＮＢ２００－１）が適切なドナーｇＮＢであるか又は他のｇＮＢが適切なドナーｇＮＢであるかを判断する。ここでは、ｇＮＢ２００－１が、自身（ｇＮＢ２００－１）が適切なドナーｇＮＢであると判断したと仮定して説明を進める。なお、ステップＳ３０４及びステップＳ３０５の処理は必須ではなく、省略してもよい。
　ステップＳ３０６において、ｇＮＢ２００－１は、ＩＡＢノード設定メッセージ（ＲＲＣ再設定メッセージ）をＩＡＢノード３００－２に送信する。ＩＡＢノード３００－２は、ＩＡＢノード設定メッセージに基づいて、バックホールリンク接続をＩＡＢノード３００－１と確立する処理を行う。かかる確立処理は、ＩＡＢノード設定メッセージ中の設定情報に基づいて、バックホールリンク用のプロトコルスタック（アダプテーション／ＲＬＣ／ＭＡＣ／ＰＨＹエンティティ）を生成したり、パラメータ設定したりする処理を含む。かかる確立処理は、ＵＥ側（のアクセスリンク用）のプロトコルスタックを準備して、同期信号やセル固有参照信号の送信を開始する処理（もしくは、開始する準備をする処理）を含んでもよい。
　ステップＳ３０７において、ｇＮＢ２００－１は、ＲＲＣ再設定メッセージをＩＡＢノード３００－１に送信する。かかるＲＲＣ再設定メッセージは、ＩＡＢノード３００－２の追加に伴ってＩＡＢノード３００－１における設定を変更するためのメッセージである。かかるＲＲＣ再設定メッセージは、例えば、ＩＡＢノード３００－２の論理チャネルとＩＡＢノード３００－１のバックホールリンクの論理チャネルとの対応付けを示すマッピング情報を含む。なお、ステップＳ３０７は、ステップＳ３０６の前であってもよいし、ステップＳ３０６と同時であってもよい。
　ステップＳ３０８において、ＩＡＢノード３００－２は、ＩＡＢノード３００－１とのバックホールリンク接続の確立を含むＩＡＢノード設定が完了したことを示す完了通知メッセージをｇＮＢ２００－１に送信する。ステップＳ３０８以降は、ＩＡＢノード３００－２はｇＮＢ２００－１に対してＵＥとして振る舞うのではなく、ＩＡＢノードとして振る舞う。
　ステップＳ３０９において、ＩＡＢノード３００－１は、ＩＡＢノード３００－２とのバックホールリンク接続の確立に伴う設定変更が完了したことを示す完了通知メッセージをｇＮＢ２００－１に送信する。なお、ステップＳ３０９は、ステップＳ３０８の前であってもよいし、ステップＳ３０８と同時であってもよい。
　ステップＳ３１０において、ｇＮＢ２００－１は、ステップＳ３０１において取得したＩＡＢノード３００－２のコンテキスト情報を、Ｘｎインターフェイス上でｇＮＢ２００－２に転送する。
　ステップＳ３１１において、ｇＮＢ２００－１は、ＩＡＢノード３００－２のバックホールリンク接続を確立したことを示す通知を５ＧＣ１０に送信する。もしくは、ｇＮＢ２００－１は、ＩＡＢノード３００－２用のＰＤＵセッションの確立要求を５ＧＣ１０に送信してもよい。なお、上述したように、ＰＤＵセッションの確立要求は、ステップＳ３１１よりも先に又はステップＳ３１１においてＡＭＦ１１からｇＮＢ２００－１に送信されてもよい。
　［第１実施形態の変更例］
　上述した第１実施形態において、ＩＡＢノード３００－１がｇＮＢ２００－１に無線で接続した後に、ｇＮＢ２００－１がドナー能力を有しないことに応じてＩＡＢノード３００－１をハンドオーバさせる一例について説明した。しかしながら、各ｇＮＢ２００は、自身がドナー能力を有するか否かに関する情報をＩＡＢノード３００－１に提供してもよい。これにより、ＩＡＢノード３００－１は、ドナー能力を有するｇＮＢ２００を選択したうえで接続することが可能になる。例えば、ドナー能力を有するｇＮＢ２００は、ドナー能力を有することを示す情報をシステム情報ブロック（ＳＩＢ）に含めてブロードキャストする。ＩＡＢノード３００－１は、かかるＳＩＢに基づいて、接続先とするｇＮＢ２００を選択する。ＩＡＢノード３００－１は、ドナー能力を有するｇＮＢ２００であって、且つ、このｇＮＢ２００からの受信電力が閾値以上である場合に、このｇＮＢ２００を接続先として選択してもよい。または、ｇＮＢ２００がドナー能力を有しない場合には、ＩＡＢノード３００－１は、ｇＮＢ２００から送信されたＳＩＢを受信したことに応じて、他のｇＮＢ２００を再選択してもよい。その後、他のｇＮＢ２００から送信されたＳＩＢにより当該他のｇＮＢ２００がドナー能力を有することが示される場合には、ＩＡＢノード３００－１は、当該他のｇＮＢ２００を接続先として、ランダムアクセスプロシージャを行うと共にＩＡＢインディケーションを送信してもよい。
　或いは、各ｇＮＢ２００は、自身がドナー能力を有することをＳＩＢにより通知することに加えて、又は自身がドナー能力を有することをＳＩＢにより通知することに代えて、自身がＩＡＢノード３００を取り扱う能力を有することをＳＩＢにより通知してもよい。例えば、各ｇＮＢ２００は、自身がＩＡＢノード３００を他のｇＮＢ（ドナーｇＮＢ）にハンドオーバする機能を有することをＳＩＢにより通知してもよい。
　上述した第１実施形態において、ＩＡＢノード３００がランダムアクセスプロシージャ中にｇＮＢ２００に送信するメッセージ（例えば、Ｍｓｇ３）にＩＡＢインディケーションを含める一例について説明した。ここで、Ｍｓｇ３は、例えばＲＲＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔメッセージである。また、ＩＡＢノード３００は、Ｍｓｇ３中のフィールド（情報要素）であるＥｓｔａｂｌｉｓｈｍｅｎｔ　ＣａｕｓｅにＩＡＢインディケーションを含めてもよい。
　或いは、ＩＡＢノード３００は、ランダムアクセスプロシージャ中にｇＮＢ２００に送信するランダムアクセスプリアンブル（Ｍｓｇ１）を利用して、ＩＡＢインディケーションを通知してもよい。例えば、ＩＡＢインディケーション用のＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｃｈａｎｎｅｌ）リソースがＳＩＢにより通知される場合、ＩＡＢノード３００は、通知されたＩＡＢインディケーション用のＰＲＡＣＨリソースの中から選択したＰＲＡＣＨリソースを用いてランダムアクセスプリアンブルを送信する。これにより、ＩＡＢノード３００は、ＩＡＢインディケーションを通知してもよい。ここで、ＰＲＡＣＨリソースとは、時間・周波数リソースであってもよいし、信号系列（プリアンブル系列）であってもよい。
　或いは、ＩＡＢノード３００は、ランダムアクセスプロシージャ以外のタイミングでＩＡＢインディケーションを通知してもよい。例えば、ＩＡＢノード３００は、ＵＥ　Ａｓｓｉｓｔａｎｃｅ　Ｉｎｆｏｒｍａｔｉｏｎメッセージ等のＲＲＣメッセージにＩＡＢインディケーションを含めてもよい。
　上述した第１実施形態において、ｇＮＢ２００が、無線測定を設定する測定設定をＩＡＢノード３００又はＵＥ１００に送信し、無線測定の結果を含む測定報告を受信することにより、自身（ｇＮＢ２００）が適切なドナーｇＮＢであるか又は他のｇＮＢが適切なドナーｇＮＢであるかを当該測定報告に基づいて判断する一例について説明した。しかしながら、ｇＮＢ２００は、このような初期接続時に測定結果を利用する場合に限らず、ネットワークトポロジの変更やデータ転送経路の変更に測定報告を利用してもよい。
　［第２実施形態］
　第２実施形態について、上述した第１実施形態との相違点を主として説明する。本実施形態は、上述した第１実施形態と併用して実施してもよいし、上述した第１実施形態とは別に実施してもよい。
　ＩＡＢノード３００の直下の下位装置は、ＩＡＢノード３００との無線リンク障害（ＲＬＦ）を検知した場合、他のセルを再選択し、再選択したセルに対して接続の再確立を試みる。しかしながら、ＲＬＦは、基本的には下りリンクの受信状態に基づいて検知されるため、ＩＡＢノード３００は、下位装置がＲＬＦを検知したことを把握できない可能性がある。
　ここで、ＲＬＦに関連する下位装置の一般的な動作について説明する。図１０に示すように、下位装置は、Ｎ３１０回連続して同期外れ状態（ｏｕｔ－ｏｆ－ｓｙｎｃ）を検知した場合、無線問題（ｒａｄｉｏ　ｐｒｏｂｌｅｍ）を検知する。下位装置は、無線問題を検知すると、所定のタイマＴ３１０を開始させる。下位装置は、タイマＴ３１０を開始させた後、Ｎ３１１回連続して同期状態（ｉｎ－ｓｙｎｃ）を検知した場合、タイマＴ３１０を停止させる。下位装置は、タイマＴ３１０が満了すると、ＲＬＦを検知するとともに、タイマＴ３１１を開始し、且つセル再選択動作（接続再確立処理）を開始する。そして、下位装置は、接続再確立に成功せずにタイマＴ３１１が満了すると、ＲＲＣアイドルモードに遷移する。
　図１１は、第２実施形態に係るＩＡＢノード３００の動作を示す図である。
　図１１に示すように、ステップＳ６０１において、ＩＡＢノード３００は、自身の直下の下位装置から定期的に送信される上りリンク信号を受信する。下位装置とは、ＵＥ１００、又はＵＥ１００とＩＡＢノード３００との間に介在する他のＩＡＢノードをいう。上りリンク信号は、定期的に送信可能な信号であればよい。例えば、上りリンク信号は、ＭＡＣ　ＣＥ（例えば、バッファ状態報告）、ＲＲＣメッセージ（例えば、測定報告メッセージ）、及び／又は上りリンク参照信号を利用できる。
　ステップＳ６０２において、ＩＡＢノード３００は、下位装置からの上りリンク信号の受信に応じて、タイマを開始させる。このタイマに設定されるタイマ値は、ドナーｇＮＢ２００－１から設定された値であってもよい。タイマ値は、下位装置が上りリンク信号を送信する周期よりも長い時間であってもよい。
　タイマを開始させた後、ＩＡＢノード３００は、下位装置から上りリンク信号を受信した場合（ステップＳ６０３：ＹＥＳ）、ステップＳ６０４において、タイマを停止させる。この場合、処理がステップＳ６０２に戻り、タイマを再開させる。
　一方、下位装置から上りリンク信号を受信することなく（ステップＳ６０３：ＮＯ）、タイマが満了した場合（ステップＳ６０５：ＹＥＳ）、ステップＳ６０６において、ＩＡＢノード３００は、下位装置がＲＬＦを検知したと判断する。ＩＡＢノード３００は、自身の下位装置がＲＬＦを検知したと判断した場合、自身の上位装置に対して、この下位装置に対応する無線ベアラ（バックホールリンク）の解放を要求してもよい。
　第２実施形態によれば、下位装置においてＲＬＦが検知されたことをＩＡＢノード３００が把握できる。
　図１２は、第２実施形態に係る動作シーケンスの一例を示す図である。図１２に示す例において、ＩＡＢノード３００－２は、下位装置としてのＵＥ１００－３と、上位装置としてのＩＡＢノード３００－１とに無線で接続しており、ＵＥ１００－３とＩＡＢノード３００－１との間の通信を無線で中継する。ＩＡＢノード３００－２において、基地局機能部（ＤＵ）はＵＥ１００－３と無線で接続し、ユーザ装置機能部（ＭＴ）はＩＡＢノード３００－１と無線で接続する。
　但し、下位装置は、ＩＡＢノードであってもよい。また、ＩＡＢノード３００－２は、ＩＡＢノード３００－１を介さずにドナー装置（ｇＮＢ２００－１）に無線で接続していてもよい。この場合、上位装置とドナー装置とが同じ装置になる。
　図１２に示すように、ステップＳ６１１において、ＩＡＢノード３００－２の基地局機能部（ＤＵ）は、ＵＥ１００－３との無線リンク障害（ＲＬＦ）を検知する。このようなＲＬＦはＩＡＢノード３００－２の観点で、フロントホール（Ｆｒｏｎｔｈａｕｌ）ＲＬＦと呼ばれてもよい。
　ＲＬＦの検知方法は、上述した方法以外に、ＵＥ１００－３からのＡＣＫ／ＮＡＣＫに基づく方法を用いることができる。具体的には、ＩＡＢノード３００－２の基地局機能部（ＤＵ）は、例えば下りリンクのＨＡＲＱ再送を行っても、ＡＣＫやＮＡＣＫがＵＥ１００－３から返ってこない場合、ＵＥ１００－３とのＲＬＦを検知する。
　ステップＳ６１２において、ＩＡＢノード３００－２の基地局機能部（ＤＵ）は、ＵＥ１００－３とのＲＬＦを検知したことを示す状態情報（ＲＬＦ通知）をＩＡＢノード３００－２のユーザ装置機能部（ＭＴ）に通知する。この状態情報（ＲＬＦ通知）は、ＵＥ１００－３に関する識別子、例えばＵＥ識別子及び／又はベアラ識別子を含んでもよい。
　ステップＳ６１３において、ＩＡＢノード３００－２のユーザ装置機能部（ＭＴ）は、状態情報（ＲＬＦ通知）を含むＲＲＣメッセージを、ＩＡＢノード３００－１を介してドナーｇＮＢ２００－１に送信する。ドナーｇＮＢ２００－１は、このＲＲＣメッセージに含まれる状態情報（ＲＬＦ通知）に基づいて、ＵＥ１００－３に対応するベアラを解放してもよい。
　図１２に示すシーケンスを次のように変更してもよい。
　具体的には、ステップＳ６１２において、ＩＡＢノード３００－２の基地局機能部（ＤＵ）は、ＵＥ１００－３とのＲＬＦを検知したことを示す状態情報（ＲＬＦ通知）をＩＡＢノード３００－２のＦ１－ＡＰエンティティに通知する。この状態情報（ＲＬＦ通知）は、ＵＥ１００－３に関する識別子、例えばＵＥ識別子及び／又はベアラ識別子を含んでもよい。Ｆ１－ＡＰエンティティとは、フロントホールのインターフェイスであるＦ１インターフェイス上でドナーｇＮＢ２００－１との通信を行う通信機能部をいう。
　ステップＳ６１３において、ＩＡＢノード３００－２のユーザ装置機能部（ＭＴ）は、状態情報（ＲＬＦ通知）を含むＦ１－ＡＰメッセージを、ＩＡＢノード３００－１を介してドナーｇＮＢ２００－１に送信する。ドナーｇＮＢ２００－１は、このＦ１－ＡＰメッセージに含まれる状態情報（ＲＬＦ通知）に基づいて、ＵＥ１００－３に対応するベアラを解放してもよい。
　図１２に示すシーケンスを次のように変更してもよい。
　具体的には、ステップＳ６１１において、ＩＡＢノード３００－２の基地局機能部（ＤＵ）は、自身の配下の全ての下位装置がＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移したことを検知する。
　ステップＳ６１２において、ＩＡＢノード３００－２の基地局機能部（ＤＵ）は、自身の配下の全ての下位装置がＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移したことを示す状態情報をＩＡＢノード３００－２のユーザ装置機能部（ＭＴ）又はＦ１－ＡＰエンティティに通知する。
　ステップＳ６１３において、ＩＡＢノード３００－２のユーザ装置機能部（ＭＴ）又はＦ１－ＡＰエンティティは、基地局機能部（ＤＵ）からの状態情報に基づいて、自身のＲＲＣ接続を解放可能であることを示すＲＡＩ（Ｒｅｌｅａｓｅ　Ａｓｓｉｓｔａｎｃｅ　Ｉｎｄｉｃａｔｉｏｎ）を、ＩＡＢノード３００－１を介してドナーｇＮＢ２００－１に送信する。ドナーｇＮＢ２００－１は、このＲＡＩに基づいて、ＵＥ１００－３のＲＲＣ接続を解放してもよい。
　［第２実施形態の変更例］
　第２実施形態において、ＩＡＢノード３００－２は、自身と下位装置との間のＲＬＦをドナーｇＮＢ２００－１に通知していた。しかしながら、下位装置が他のＩＡＢノードとの間で検知したＲＬＦをドナーｇＮＢ２００－１に通知してもよい。
　図１３は、第２実施形態の変更例に係る動作シーケンスを示す図である。図１３において、ＩＡＢノード３００－２とドナーｇＮＢ２００－１との間に他のＩＡＢノードが介在してもよい。
　図１３に示すように、ステップＳ６２１において、ＩＡＢノード３００－２の基地局機能部（ＤＵ）は、ＩＡＢノード３００－２に接続する下位装置（ＵＥ１００－３）から、ＩＡＢノード３００－３とのＲＬＦの発生を示す通知を受信する。この通知は、ＲＲＣ　Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージ又はＲＬＦ　Ｉｎｄｉｃａｔｉｏｎであってもよい。
　例えば、ＵＥ１００－３は、ＩＡＢノード３００－３とのＲＬＦを検知し、ＩＡＢノード３００－２との接続再確立を行う。ここで、ＵＥ１００－３は、ＲＲＣ　ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージをＩＡＢノード３００－２に送信する。このＲＲＣ　Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージは、ＵＥ１００－３の識別子だけではなく、ＵＥ１００－３がＩＡＢノード３００－３に接続していたことを示す情報（ＩＡＢノード３００－３の識別子であってもよい）、及び／又は、ＵＥ１００－３がＩＡＢノード３００－３を介して接続していたドナー装置の識別子等を含んでもよい。
　或いは、ＵＥ１００－３は、ＩＡＢノード３００－３及び３００－２と同時に接続するデュアルコネクティビティ（ＤＣ）通信中に、ＩＡＢノード３００－３とのＲＬＦを検知し、このＲＬＦに関するＲＬＦ　ＩｎｄｉｃａｔｉｏｎをＩＡＢノード３００－２に送信する。ＩＡＢノード３００－３がマスタノード（ＭＮ）として設定されていた場合、このＲＬＦ　Ｉｎｄｉｃａｔｉｏｎは、ＭＣＧ（Ｍａｓｔｅｒ　Ｃｅｌｌ　Ｇｒｏｕｐ）　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎと呼ばれてもよい。ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎは、ＵＥ１００－３の識別子、ＩＡＢノード３００－３の識別子、ＵＥ１００－３がＩＡＢノード３００－３を介して接続していたドナー装置の識別子等を含んでもよい。
　ステップＳ６２２において、ＩＡＢノード３００－２の基地局機能部（ＤＵ）は、ステップＳ６２１でＵＥ１００－３から受信した通知に含まれる情報を、ＩＡＢノード３００－２の端末機能部（ＭＴ）又はＦ１－ＡＰエンティティに通知する。
　ステップＳ６２３において、ＩＡＢノード３００－２の端末機能部（ＭＴ）又はＦ１－ＡＰエンティティは、基地局機能部（ＤＵ）から通知された情報を含むメッセージをドナーｇＮＢ２００－１に送信する。このメッセージは、ＲＲＣメッセージ又はＦ１－ＡＰメッセージである。
　ドナーｇＮＢ２００－１は、受信したメッセージに含まれる情報に基づいて、ＵＥ１００－３が他のドナー装置の配下にあった、すなわち、他のドナー装置のトポロジに属していたと判定した場合、当該他のドナー装置に対して通知を行ってもよい。この通知は、ＵＥ１００－３の識別子及びＩＡＢノード３００－３の識別子のうち少なくとも一方を含んでもよい。
　［第３実施形態］
　第３実施形態について、上述した第１実施形態及び第２実施形態との相違点を主として説明する。本実施形態は、上述した第１実施形態及び第２実施形態と併用して実施してもよいし、上述した第１実施形態及び第２実施形態とは別に実施してもよい。
　図１４は、第３実施形態に係る動作を示す図である。図１４において、「ＤＵ」は基地局機能に相当し、「ＭＴ」はユーザ装置機能に相当する。
　図１４に示すように、ＵＥ１００－３は、ステップＳ７０１乃至Ｓ７０５の手順により上りリンクデータ（ＰＤＵ）をＩＡＢノード３００－２に送信する。具体的には、ＵＥ１００－３は、スケジューリング要求（ＳＲ）をＩＡＢノード３００－２に送信し（ステップＳ７０１）、ＢＳＲ送信用の上りリンク無線リソースの割り当てを受け（ステップＳ７０２）、ＢＳＲを送信し（ステップＳ７０３）、上りリンクデータ送信用の上りリンク無線リソースの割り当てを受け（ステップＳ７０４）、上りリンクデータをＩＡＢノード３００－２に送信する（ステップＳ７０５）。
　同様にして、ＩＡＢノード３００－２は、ステップＳ７０６乃至Ｓ７１０の手順により上りリンクデータ（ＰＤＵ）をＩＡＢノード３００－１に送信する。
　また、ＩＡＢノード３００－１は、ステップＳ７１１乃至Ｓ７１５の手順により上りリンクデータ（ＰＤＵ）をドナーｇＮＢ２００－１に送信する。
　本シーケンスにおいて、各ＩＡＢノード３００は、上りリンク無線リソースの割り当てを要求する第１スケジューリング要求を下位装置から受信する。そして、各ＩＡＢノード３００は、上りリンクデータ（ＰＤＵ）を下位装置から受信するよりも前において、第２スケジューリング要求を上位装置に送信する。
　一般的に、スケジューリング要求は、送信するべき上りリンクデータを有する場合にトリガされるが、本実施形態では、送信するべき上りリンクデータを未だ有していない段階でスケジューリング要求をトリガしている。これにより、円滑な上りリンク無線リソースの割り当てを実現できる。
　例えば、ステップＳ７０６において、ＩＡＢノード３００－２は、ＵＥ１００－３からＢＳＲを受信（ステップＳ７０３）した際に、スケジューリング要求をＩＡＢノード３００－１に送信する。
　ＩＡＢノード３００－２は、ＵＥ１００－３からスケジューリング要求を受信（ステップＳ７０１）した後、ＵＥ１００－３からＢＳＲを受信（ステップＳ７０３）する前に、スケジューリング要求をＩＡＢノード３００－１に送信してもよい。
　ＩＡＢノード３００－２は、ＵＥ１００－３からスケジューリング要求を受信（ステップＳ７０１）した後、ＵＥ１００－３に上りリンク無線リソースを割り当てた際（ステップＳ７０２）に、スケジューリング要求をＩＡＢノード３００－１に送信（トリガ）してもよい。
　ＩＡＢノード３００－２は、ＵＥ１００－３からスケジューリング要求を受信した際（ステップＳ７０１）に、スケジューリング要求をＩＡＢノード３００－１に送信（トリガ）してもよい。
　本実施形態において、各ＩＡＢノード３００は、当該ＩＡＢノード３００が上りリンク送信に利用可能なデータの量を少なくとも示す第１のバッファ状態報告を上位装置に送信する。ここで、上位装置とは、ドナーｇＮＢ２００の配下の他のＩＡＢノード（上位ＩＡＢノード）又はドナーｇＮＢ２００である。上位装置は、第１のバッファ状態報告に基づいて、上りリンク送信用の無線リソースをＩＡＢノード３００に割り当てる。
　ＩＡＢノード３００は、上りリンク送信待ちのデータを一時的に記憶する上りリンクバッファを有する。例えば、ＩＡＢノード３００のＭＡＣレイヤは、当該上りリンクバッファ内のデータ量を示す情報を含む第１のバッファ状態を上位装置のＭＡＣレイヤに通知する。上位装置のＭＡＣレイヤはスケジューラを有しており、第１のバッファ状態に基づいて上りリンク無線リソースをＩＡＢノード３００に割り当て、制御チャネルを介して割当リソースをＩＡＢノード３００に通知する。
　ここで、ＩＡＢノード３００は、複数のＵＥ分の上りリンクデータをバッファリングするため、ＵＥ１００に比べて大容量の上りリンクバッファを有すると考えられる。よって、ＩＡＢノード向けのバッファ状態報告は、ＵＥ向けのバッファ状態報告とは異なるフォーマットを有していてもよい。また、ＩＡＢノード向けのバッファ状態報告が表現可能なデータ量（最大データ量）は、ＵＥ向けのバッファ状態報告が表現可能なデータ量（最大データ量）よりも大きくてもよい。
　ＩＡＢノード向けのバッファ状態報告は、ＩＡＢノード３００の配下のＵＥ１００の数に関する情報を含んでもよい。ＩＡＢノード３００は、自身の配下のＵＥ１００の数をＵＥコンテキストやＣ－ＲＮＴＩ（Ｃｅｌｌ－Ｒａｄｉｏ　Ｎｅｔｗｏｒｋ　Ｔｅｍｐｏｒａｒｙ　Ｉｄｅｎｔｉｆｉｅｒ）等に基づいて判断してもよいし、自身の配下のＵＥ１００の数をドナーｇＮＢ２００から通知されてもよい。ＩＡＢノード３００は、自身の配下のＵＥ１００のうち、自身の上りリンクバッファ内にデータがあるＵＥ１００の数をバッファ状態報告に含めてもよい。言い換えると、ＩＡＢノード３００は、自身がいくつのＵＥ分の上りリンクデータを持っているかをバッファ状態報告により上位装置に通知してもよい。或いは、ＩＡＢノード３００は、自身の配下のＵＥ１００のうち、ＲＲＣコネクティッド状態にあるＵＥ１００の数をバッファ状態報告に含めてもよい。
　ＩＡＢノード向けのバッファ状態報告は、ＩＡＢノード３００の上りリンクバッファ内に実際に存在するデータの量だけではなく、下位装置からのバッファ状態報告（すなわち、潜在的な上りリンクデータ量）が加味されてもよい。これにより、上位装置は、潜在的な上りリンクデータ量を考慮して、上りリンク無線リソースを予めＩＡＢノード３００に割り当てておくことができるため、マルチホップに起因する上りリンクの伝送遅延を抑制できる。
　ＩＡＢノード３００は、下位装置から、下位装置が上りリンク送信に利用可能なデータの量を示す第２のバッファ状態報告を受信する。ＩＡＢノード３００は、第２のバッファ状態報告に基づいて、自身が上りリンク送信に利用可能なデータの量と下位装置が上りリンク送信に利用可能なデータの量とに基づく第１のバッファ状態報告を上位装置に送信する。例えば、ＩＡＢノード３００は、自身が上りリンク送信に利用可能なデータの量と下位装置が上りリンク送信に利用可能なデータの量との合計値を第１のバッファ状態報告に含めてもよい。或いは、ＩＡＢノード３００は、自身が上りリンク送信に利用可能なデータの量を示す第１のＢＳＲ値と、下位装置が上りリンク送信に利用可能なデータの量を示す第２のＢＳＲ値とを別々に第１のバッファ状態報告に含めてもよい。
　なお、ＩＡＢノード３００が上りリンク送信に利用可能なデータ量とは、自身の送信バッファ（ＭＴのバッファ）のデータ量、自身の受信バッファ（ＤＵ）のデータ量、及び／又はアダプテーションエンティティのバッファ量を含んでもよい。
　［第４実施形態］
　第４実施形態について、上述した第１実施形態乃至第３実施形態との相違点を主として説明する。本実施形態は、上述した第１実施形態乃至第３実施形態と併用して実施してもよいし、上述した第１実施形態乃至第３実施形態とは別に実施してもよい。
　図１５は、第４実施形態に係るＩＡＢノード３００の動作を示す図である。
　図１５に示すように、ＩＡＢノード３００は、バックホールリンクを介して上位装置Ａと無線で接続している。上位装置Ａは、上位ＩＡＢノード又はドナーｇＮＢ（ドナー装置）である。
　ＩＡＢノード３００には下位装置Ｂ１及びＢ２が接続しており、下位装置Ｂ２には下位装置Ｂ３が接続している。下位装置Ｂ４は、ＩＡＢノード３００の配下にない装置である。下位装置Ｂ１乃至Ｂ４は、下位ＩＡＢノード又はＵＥである。以下において、下位装置Ｂ１乃至Ｂ４を特に区別しないときは単に下位装置Ｂと呼ぶ。
　第４実施形態において、上位装置Ａと下位装置Ｂとの間の通信を無線で中継するＩＡＢノード３００において、上位装置Ａと無線で接続するユーザ装置機能部（ＭＴ）は、下位装置Ｂと無線で接続する基地局機能部（ＤＵ）に対して状態情報を通知する。
　この状態情報は、ユーザ装置機能部（ＭＴ）のＲＲＣ状態、及び上位装置Ａとユーザ装置機能部（ＭＴ）との間の無線リンク状態（以下、バックホールリンク状態と呼ぶ）のうち、少なくとも一方の状態を示す情報である。これにより、基地局機能部（ＤＵ）は、バックホールリンク側の状態を考慮して下位装置Ｂに対するサービス提供を制御できる。
　ここで、ユーザ装置機能部（ＭＴ）のＲＲＣ状態は、コネクティッド、インアクティブ、及びアイドルのいずれかである。
　バックホールリンク状態は、下記の上記１）乃至６）のうち少なくとも１つの指標、又はこれらの指標の組み合わせに基づく状態である。
　１）ＲＬＦを検知した及びＲＬＦから復帰したなどのＲＬＦ状態
　２）ＲＳＲＰ（Ｒｅｆｅｒｅｎｃｅ　Ｓｉｇｎａｌ　Ｒｅｃｅｉｖｅｄ　Ｐｏｗｅｒ）などの無線品質
　３）ＲＬＣ（Ｒａｄｉｏ　Ｌｉｎｋ　Ｃｏｎｔｒｏｌ）再送回数やＲＡＣＨ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｃｈａｎｎｅｌ）再送回数などのリンク状態
　４）ＲＳＳＩ（Ｒｅｃｅｉｖｅｄ　Ｓｉｇｎａｌ　Ｓｔｒｅｎｇｔｈ　Ｉｎｄｉｃａｔｏｒ）、ＣＢＲ（Ｃｈａｎｎｅｌ　Ｂｕｓｙ　Ｒａｔｉｏ）、ＬＢＴ（Ｌｉｓｔｅｎ　Ｂｅｆｏｒｅ　Ｔａｌｋ）状況などの混雑度
　５）設定されている又は活性化されているセカンダリセル数、ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ　Ｉｎｐｕｔ　Ｍｕｌｔｉｐｌｅ　Ｏｕｔｐｕｔ）レイヤ数、割り当て無線リソース状況（例えば、準静的割り当てにおけるＣｏｎｆｉｇｕｒｅｄ　ｇｒａｎｔの増減、動的割り当てにおけるＤｙｎａｍｉｃ　ｇｒａｎｔの増減）、スループット測定値などの通信容量
　６）上りリンクスケジューリング遅延時間の測定値、上りリンクバッファ中のデータ量などの遅延状態。
　バックホールリンク状態は、上記１）乃至６）の指標に基づくバックホールリンク状態の良好度合い、例えば、閾値よりも良好又は閾値よりも劣悪といった状態であってもよい。
　ユーザ装置機能部（ＭＴ）は、ＲＲＣ状態の変化又はバックホールリンク状態の変化をトリガとして、状態情報を基地局機能部（ＤＵ）に通知してもよい。例えば、ユーザ装置機能部（ＭＴ）は、バックホールリンク状態が閾値条件を満たしたというイベントが発生した際に、状態情報を基地局機能部（ＤＵ）に通知する。
　或いは、ユーザ装置機能部（ＭＴ）は、状態情報を基地局機能部（ＤＵ）に周期的に通知してもよい。
　基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）からの状態情報に基づいて、下位装置Ｂに対するサービス提供を停止してもよい。下位装置Ｂに対するサービス提供を停止するとは、少なくとも１つの下りリンク無線信号の送信を停止することをいう。基地局機能部（ＤＵ）は、ＰＳＳ（Ｐｒｉｍａｒｙ　Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ　Ｓｉｇｎａｌ）、ＰＳＳ（Ｓｅｃｏｎｄａｒｙ　Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ　Ｓｉｇｎａｌ）、ＭＩＢ（Ｍａｓｔｅｒ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｂｌｏｃｋ）の送信を停止してもよい。
　例えば、基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）がＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移した場合、下位装置Ｂに対するサービス提供を停止してもよい。基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）がＲＲＣコネクティッド状態に遷移した場合、下位装置Ｂに対するサービス提供を再開してもよい。
　基地局機能部（ＤＵ）は、バックホールリンクが劣化している場合、例えば、バックホールでＲＬＦが検知された場合、下位装置Ｂに対するサービス提供を停止してもよい。基地局機能部（ＤＵ）は、バックホールリンクが良化した場合、下位装置Ｂに対するサービス提供を再開してもよい。
　或いは、基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）からの状態情報に基づいて、下位装置Ｂに対する無線リソース割り当て（スケジューリング）を制御してもよい。
　基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）がＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移した場合、下位装置Ｂに対するリソース割当を中止してもよい。なお、基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）がＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移した際に、下位装置Ｂに上りリンクリソースを割り当てている場合がある。この場合、基地局機能部（ＤＵ）は、ＲＲＣコネクティッド状態に遷移するようにユーザ装置機能部（ＭＴ）に要求してもよい。
　基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）がＲＲＣコネクティッド状態に遷移した場合、下位装置Ｂに対するリソース割当を再開してもよい。
　基地局機能部（ＤＵ）は、バックホールリンクが劣化している場合、例えば、バックホールでＲＬＦが検知された場合、下位装置Ｂに対するリソース割当を中止してもよい。基地局機能部（ＤＵ）は、バックホールリンクが良化した場合、例えば、バックホールでＲＬＦから復旧した場合、下位装置Ｂに対するリソース割当を再開してもよい。
　或いは、基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）からの状態情報に基づいて、バックホールリンクの劣化を示す通知、例えば、バックホールリンクのＲＬＦ発生を示す通知（以下、ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎと呼ぶ）を下位装置Ｂに送信してもよい。ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎは、ＩＡＢノード３００の識別子を含んでもよい。以下において、バックホールリンクの劣化を示す通知がＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎである一例について説明する。
　基地局機能部（ＤＵ）は、ＲＲＣレイヤよりも下位のレイヤの制御信号によりＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを送信してもよい。基地局機能部（ＤＵ）は下位装置ＢとのＲＲＣ接続を有していないためである。ＲＲＣレイヤよりも下位のレイヤの制御信号は、ＭＡＣ　ＣＥ（Ｃｏｎｔｒｏｌ　Ｅｌｅｍｅｎｔ）、ＲＬＣ　Ｃｏｎｔｒｏｌ　ＰＤＵ（Ｐｒｏｔｏｃｏｌ　Ｄａｔａ　Ｕｎｉｔ）、又はＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ　Ｄｏｗｎｌｉｎｋ　Ｃｏｎｔｒｏｌ　Ｃｈａｎｎｅｌ）であるが、以下においてはＭＡＣ　ＣＥを用いる一例について説明する。
　基地局機能部（ＤＵ）は、ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎをユニキャストで下位装置Ｂに送信してもよい。或いは、基地局機能部（ＤＵ）は、ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎのシグナリング負荷を減らすために、ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎをブロードキャスト又はマルチキャストで送信してもよい。ブロードキャスト又はマルチキャストを用いる場合、下位装置Ｂ３及びＢ４は、接続中のセル（上位ＩＡＢノード）からのＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎだけではなく、その他のセルのＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎもモニタすることで、ＩＡＢノード３００からのＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを受信できる。
　基地局機能部（ＤＵ）は、例えば、予め仕様で定められた固定のＲＮＴＩ（Ｒａｄｉｏ　Ｎｅｔｗｏｒｋ　Ｔｅｍｐｏｒａｒｙ　Ｉｄｅｎｔｉｆｉｅｒ）を用いてＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎをブロードキャストで送信してもよい。基地局機能部（ＤＵ）は、下位装置のグループに割り当てた共通のＲＮＴＩを用いてＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎをマルチキャストで送信してもよい。
　なお、ブロードキャスト／マルチキャストと、ユニキャストとを使い分けてもよい。この場合、基地局機能部（ＤＵ）は、ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎがブロードキャスト／マルチキャストで送信されるか、ユニキャストで送信されるかをＳＩＢで通知（ブロードキャスト）してもよい。下位装置Ｂは、このＳＩＢに基づいて、ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎの待ち受けモード、例えば、ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎのモニタに用いるＲＮＴＩを変更してもよい。
　基地局機能部（ＤＵ）は、バックホールリンクの無線リンク状態が劣化している期間、例えば、バックホールリンクのＲＬＦが発生している期間内において、ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを周期的に送信してもよい。この場合、ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎが周期的に送信される期間内では、ＲＬＦが発生していることになる。或いは、基地局機能部（ＤＵ）は、バックホールリンクのＲＬＦが発生した際にＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを送信し、バックホールリンクのＲＬＦから復旧した際に復旧を示す通知を送信してもよい。以下においては、ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎの周期的な送信により、バックホールリンクのＲＬＦの発生及びＲＬＦからの復旧を下位装置に示す一例について主として説明する。
　下位装置Ｂは、ＩＡＢノード３００からＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを受信する期間内では、バックホールリンクのＲＬＦが発生していると判定する。ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎの送信周期は、ドナー装置からＩＡＢノード３００のユーザ装置機能部（ＭＴ）を介して基地局機能部（ＤＵ）に設定されてもよい。
　ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎがマルチキャストで送信される場合、ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂは、ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎの受信に応じて、ＩＡＢノード３００に対するＡＣＫ／ＮＡＣＫフィードバックの送信を開始してもよい。ＩＡＢノード３００は、配下の全ての下位装置Ｂ１乃至Ｂ３からＡＣＫを受信した場合、ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎの周期的な送信を停止してもよい。
　ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ１乃至Ｂ３は、接続先又は通信経路をＩＡＢノード３００から切り替えるための処理を行ってもよい。このような処理としては、例えば、接続再確立処理、条件付きハンドオーバのトリガ処理、通信経路切替処理、ハンドオーバ用の測定報告処理が挙げられる。なお、下位装置Ｂ１乃至Ｂ３は、このような切り替え処理を開始した後、切り替え処理を完了するまでの間において、ＩＡＢノード３００からのＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを受信しなくなった場合（又はバックホールＲＬＦの復旧を示す通知を受信した場合）、ＩＡＢノード３００のバックホールリンクが復旧したと判定し、切り替え処理を中止してもよい。
　例えば、ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ１乃至Ｂ３は、ＩＡＢノード３００のセル以外のセルを探索するセルサーチを行い、適切なセルに対して接続再確立（ＲＲＣ　Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）を行う。ここで、下位装置Ｂ１乃至Ｂ３とＩＡＢノード３００との間でＲＬＦが発生していなくても、このような接続再確立処理を早期に行う。
　接続再確立処理は、時間的に分散して実行するように制御されていてもよい。例えば、下位装置Ｂ１乃至Ｂ３は、ランダム値やＵＥ－ＩＤを用いて接続再確立処理の実行開始時間を決定することにより、下位装置Ｂ１乃至Ｂ３の接続再確立処理の実行開始時間を分散させ、負荷の集中を防ぐことができる。なお、ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎがユニキャストで送信される場合、基地局機能部（ＤＵ）がＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎの送信タイミングを分散させることにより、下位装置Ｂ１乃至Ｂ３の接続再確立処理の実行開始時間を分散させてもよい。
　ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ１乃至Ｂ３は、自身がＩＡＢノード３００と、ＩＡＢノード３００以外の上位装置とに接続してＤＣ通信を行っている場合、ＩＡＢノード３００を経由する通信経路を他の上位装置に切り替えてもよいし、他の通信装置にＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを送信してもよい。例えば、下位装置Ｂは、ＩＡＢノード３００をマスタノード（ＭＮ）として設定し、他の上位装置をバックアップ用のセカンダリノード（ＳＮ）として設定している場合、ＭＮを経由する通信経路をＳＮに切り替える。
　ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ１乃至Ｂ３は、自身に条件付きハンドオーバが設定されている場合、条件が満たされたとみなして、ハンドオーバを行ってもよい。ハンドオーバ条件がサービングセルの無線品質劣化を示すイベントである場合、サービングセルの無線品質測定結果を低く修正する（例えば、－２００ｄＢｍとみなす）ことにより、強制的にハンドオーバをトリガしてもよい。
　ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ１乃至Ｂ３は、測定報告の送信をトリガしてもよい。ここで、一般的な測定報告はＲＲＣメッセージで送信されるが、基地局機能部（ＤＵ）はＲＲＣレイヤを有していない。このため、ＩＡＢノード３００は、バックホールリンクのＲＬＦから復旧するまでは下位装置Ｂからの測定報告を保持し、バックホールリンクのＲＬＦから（一時的に）復旧した際にドナー装置に転送し、ドナー装置が下位装置Ｂをハンドオーバさせてもよい。
　ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ４は、接続先の候補としてＩＡＢノード３００を除外するための処理を行ってもよい。例えば、ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ４は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態におけるセル再選択動作において、ＩＡＢノード３００のセルの優先度を下げる、もしくは再選択対象から除外する、もしくはＩＡＢノード３００についての受信電力測定値を低く調整する。これにより、接続先の候補としてＩＡＢノード３００が除外されるようにしてもよい。ここで、受信電力測定値を低く調整するために、実際の受信電力測定値に対してオフセット値を適用してもよい。当該オフセット値は予め決められた固定値であってもよい。もしくは当該オフセット値はネットワークから通知された値であってもよく、当該通知は下位装置Ｂ４が現在キャンプしているセルの報知情報（ＳＩＢ）によって通知されてもよい。
　下位装置Ｂ４は、接続先の候補としてＩＡＢノード３００を除外するための処理を、ＲＲＣコネクティッド状態に遷移する際のＲＲＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔ処理又はＲＲＣ　Ｒｅｓｕｍｅ　Ｒｅｑｕｅｓｔ処理を開始する前のタイミングで行ってもよい。
　具体的には、下位装置Ｂ４は、ＲＲＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔを送信する前に、送信先候補のセルがＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを通知しているか否かの確認を行う。下位装置Ｂ４は、送信先候補のセルがＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを通知していない場合はＲＲＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔを送信する。送信先候補のセルがＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを通知している場合はＲＲＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔの送信を停止（もしくは中止）し、前記セル再選択動作を行うことにより、適切なＲＲＣ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔ送信先を選択する。
　下位装置Ｂ４は、ＩＡＢノード３００からのＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを受信しなくなった場合（又はバックホールＲＬＦの復旧を示す通知を受信した場合）、ＩＡＢノード３００のバックホールリンクが復旧したと判定し、接続先の候補としてＩＡＢノード３００を除外するための処理を中止してもよい。
　図１６は、第４実施形態に係る動作の一例を示す図である。図１６において、ＩＡＢノード（Ｐａｒｅｎｔ　ＩＡＢ　ｎｏｄｅ）３００とドナーｇＮＢ（ＩＡＢ　ｄｏｎｅｒ）２００との間に他のＩＡＢノードが介在してもよい。
　図１６に示すように、ステップＳ８０１において、ＩＡＢノード３００のユーザ装置機能部（ＭＴ）は、無線問題（ｒａｄｉｏ　ｐｒｏｂｌｅｍ）を検知する。
　ステップＳ８０２において、ＩＡＢノード３００のユーザ装置機能部（ＭＴ）は、ＲＬＦを検知する（ＲＬＦ　ｄｅｃｌａｒａｔｉｏｎ）。
　ステップＳ８０３において、ＩＡＢノード３００のユーザ装置機能部（ＭＴ）は、ＲＬＦの発生を示す状態情報をＩＡＢノード３００の基地局機能部（ＤＵ）に通知する。
　ステップＳ８０４において、ＩＡＢノード３００の基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）からの通知に応じて、ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎの周期的な送信を開始する。
　ステップＳ８０５において、ＲＬＦ　ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂは、接続先又は通信経路をＩＡＢノード３００から切り替えるための処理を開始する。このような処理としては、例えば、接続再確立処理（Ｅａｒｌｙ　ＲＲＣ　Ｒｅ－ｅｓｔａｂｌｉｓｈｍｅｎｔ）、条件付きハンドオーバのトリガ処理（Ｔｒｉｇｇｅｒｉｎｇ　Ｃｏｎｄｉｔｉｏｎａｌ　ＨＯ）、通信経路切替処理（Ｓｗｉｔｃｈｉｎｇ　ｔｏ　ｒｅｄｕｎｄａｎｔ　ｒｏｕｔｅ）が挙げられる。
　ステップＳ８０６において、ＩＡＢノード３００のユーザ装置機能部（ＭＴ）は、例えばＴ３１０動作中に接続再確立を行うことができず、Ｔ３１０の満了に応じてＲＲＣアイドル状態に遷移する（Ｇｏ　ｔｏ　ＩＤＬＥ）。
　ステップＳ８０７において、ＩＡＢノード３００のユーザ装置機能部（ＭＴ）は、ＲＲＣアイドル状態への遷移を示す状態情報をＩＡＢノード３００の基地局機能部（ＤＵ）に通知する。
　ステップＳ８０８において、ＩＡＢノード３００の基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）からの通知に応じて、下位装置Ｂへのサービス提供を停止する（Ｓｅｒｖｉｃｅ　ｓｔｏｐｐｅｄ）。
　ステップＳ８０９において、下位装置Ｂは、ＩＡＢノード３００からのサービス提供が停止されたことにより、ＲＬＦを検知する。
　［その他の実施形態］
　上述した実施形態において、移動通信システム１が５Ｇ移動通信システムである一例について主として説明した。しかしながら、移動通信システム１における基地局はｅＮＢであってもよい。また、移動通信システム１におけるコアネットワークはＥＰＣ（Ｅｖｏｌｖｅｄ　Ｐａｃｋｅｔ　Ｃｏｒｅ）であってもよい。さらに、ｇＮＢがＥＰＣに接続することもでき、ｅＮＢが５ＧＣに接続することもでき、ｇＮＢとｅＮＢとが基地局間インターフェイス（Ｘｎインターフェイス、Ｘ２インターフェイス）を介して接続されることもできる。
　なお、上述した実施形態に係る各処理をコンピュータに実行させるプログラムが提供されてもよい。また、プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。ＵＥ１００及びｅＮＢ２００が行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップセットが提供されてもよい。
　なお、各図において示されるフローは、適宜組み合わされても良い。
　［付記１］
　１．序論
　統合されたアクセスとバックホールに関する新しいワークアイテムが承認された。ＷＩＤは、目的の１つとしてバックホール無線リンク障害（ＢＨ　ＲＬＦ）処理を指定することを定める。
　以下を含むアーキテクチャ1aに続くＩＡＢノードの仕様
　・[…]
　・低遅延スケジューリング、ＢＨ　ＲＬＦ処理、及びマルチホップトポロジ全体のリソース調整をサポートするためのシグナリングのホップバイホップ伝搬。
　・[…]
　Ｌ２トランスポート及びリソース管理のシグナリングの仕様
　・[…]
　・ＢＨ　ＲＬＦ処理の仕様（例：ダウンストリームＢＨ　ＲＬＦ通知）
　この付記では、研究項目からの結果に加えてＢＨ　ＲＬＦ処理の最初の考慮が議論される。
　２．議論
　ＴＲは、セクション９．７．１４及び９．７．１５において、マルチホップの無線バックホールのＢＨ　ＲＬＦに起因する問題を特定する。セクション間の共通の問題は、子ＩＡＢノード／ＵＥが親ＩＡＢノードにおけるＢＨ　ＲＬＦを認識していないことである。これにより、ＢＨ　ＲＬＦは、ＦＲ２やマルチホッピングなどの高周波数の無線バックホールにおいて頻繁に発生する可能性がある。結果として、ユーザの観点から、サービスの回復が遅れることを含むサービスが大幅に中断される。
　このような悪いユーザーエクスペリエンスを回避するために、ＴＲは次のように潜在的な解決策も特定する。
　９．７．１４アーキテクチャ１ａにおけるＢＨ　ＲＬＦのダウンストリーム通知
　「選択肢１：ＩＡＢノードＤＵはサービスを中止する。その結果、子ノードもＢＨ　ＲＬＦを決定し、上記の手順に従って回復する。」
　「選択肢２：ＩＡＢノードＤＵは、アップストリームＲＬＦについて子ＩＡＢノードに明示的に警告する。この警告を受信した子ＩＡＢノードは、警告をさらに下流に転送し得る。このような警告を受信した各ＩＡＢノードは、上記のＢＨ－ＲＬＦ回復を開始する。」
　「選択肢３：全てのＩＡＢノードは、ＢＨ品質などに関する情報を子又は親のＩＡＢノードと定期的に共有し得る。このようにして、明示的な動作を実行しなくても、ダウンストリーム又はアップストリームＲＬＦを検知し得る。」
　９．７．１５効率的なバックホールリンク障害の復旧
　「バックホール障害のために親ノードとして機能できないノードのリストを含む、バックホール障害に関する情報は、ダウンストリームＩＡＢノードに提供され得る。」（選択肢４）
　「事前（つまり、ＲＬＦの発生前）における代替バックホールリンクとルートの準備」（選択肢５）
　２．１．ＩＡＢノードがサービスを中止する（選択肢１）
　選択肢１は、ＢＨ　ＲＬＦ情報が子ＩＡＢノード及びＵＥに暗示的に伝搬されるため、セクション９．７．１４と９．７．１５との間の共通の問題のための一般的な解決策と見なし得る。ＢＨ　ＲＬＦが子ＩＡＢノードだけでなく、（ＢＨ　ＲＬＦに直面する親ＩＡＢノードに接続される）ＵＥにも影響することを考慮すると、選択肢１は既存のＲＬＦと回復メカニズムに依存することが予想されるため、選択肢１がＲｅｌ－１５　ＵＥでサポートされることは重要な側面である。一方、他の選択肢にはＲｅｌ－１６の機能が必要であろう。Ｒｅｌ－１５　ＵＥの場合でもサービスの中断を最小限に抑えるには、ＢＨ　ＲＬＦの問題のためのベースラインの解決策として選択肢１を指定すべきである。
　提案１：ＲＡＮ２は、選択肢１、つまりＩＡＢノードがＢＨ　ＲＬＦでサービスを停止すること、及び選択肢１はＲｅｌ－１５　ＵＥにも有効であるため、ベースラインの解決策であることに同意すべきである。
　選択肢１の説明によれば、解決策は「子ノードもＢＨ　ＲＬＦを判定する」ことを容易にすべきである。技術的には、子ＩＡＢノードのＭＴ及びＵＥは、「サービス」が中断された場合にＲＬＦを宣言すべきである。簡単な解決策は、ＢＨ　ＲＬＦ下にある親ＩＡＢノードが、ＰＳＳ、ＳＳＳ、ＭＩＢ、及びＳＩＢ１の送信を停止することである。これにより、子ＩＡＢノード及びＵＥの無線問題を意図的に作成する。
　提案２：ＲＡＮ２は、「サービス」を中止することを決定した場合に、ＩＡＢノードがＰＳＳ、ＳＳＳ、ＭＩＢ、及びＳＩＢ１の送信を停止することに同意すべきである。
　提案２に同意できる場合は、いつ信号が停止するかを厳密に定義すべきである。ＢＨ　ＲＬＦにあることはＴＲから大まかに理解できるが、ＢＨ　ＲＬＦが何であるか、及び「サービス」がいつ停止するかは不明確である。明らかに、ＢＨ　ＲＬＦは、ＩＡＢノードのＭＴとＩＡＢドナーのＤＵ（例えば、親ＩＡＢノードのＤＵ）の間のＲＬＦと見なし得る。ＵＥとｇＮＢ間の既存のＲＬＦを使用した場合とまったく同じように理解し得る。したがって、ＢＨ　ＲＬＦは、無線バックホールリンクにおけるＲＬＦとしてモデル化される。
　提案３：ＲＡＮ２は、ＢＨ　ＲＬＦに既存のＲＬＦメカニズムの再利用に同意すべきである。
　提案３に同意できる場合、現在のＵＥの動作はＲＬＦを宣言した後でも、つまりＲＲＣ再確立を開始するためにＲＲＣ接続を維持するため、ＲＬＦでサービスを実際に停止する必要があるかどうかは疑問である。ＵＥがＲＲＣ接続を正常に再確立すると、最小の中断時間でサービスが回復する。そのため、ＩＡＢノードは、ＭＴがＲＲＣ　ＩＤＬＥに入った場合、つまりＲＲＣ再確立が失敗した場合にのみ、「サービス」を停止すべきであることが分かる。
　提案４：ＲＡＮ２は、ＭＴがＲＬＦを宣言した場合ではなく、ＭＴがＲＲＣ　ＩＤＬＥに入った場合、ＩＡＢノードのＤＵが「サービス」を停止することに同意すべきである。
　上記のように、選択肢１は、Ｒｅｌ－１５のＵＥを含むあらゆる種類のケースとデバイスをカバーするための基盤であり、サービスの迅速な回復などの点で最良の解決策を意味するものではない。そのため、このＷＩで規定されるべき他の多くの機能があるので、他の選択肢は選択肢１に加えて依然として有益であり、時間が許す限り議論され得る。
　所見１：選択肢１に加え他の選択肢は、サービス品質をさらに向上させるという点で依然として有益である。
　２．２．ＩＡＢノードはダウンストリームノードに通知する（選択肢２、選択肢４）
　子ＩＡＢノードが回復手順を迅速及び／又は効率的に開始することを容易にするため、親ＩＡＢノードがそのＢＨ　ＲＬＦに関連する情報を子ＩＡＢノードに通知することは役立つ。ＴＲは、「アップストリームＲＬＦについて子ＩＡＢノードに明示的に警告する」（選択肢２）のような可能な情報要素、又は「親ノードとして機能できないノードのリストを含むバックホール障害に関する」（選択肢４）情報をキャプチャする。
　ただし、親ＩＡＢノードでＢＨ　ＲＬＦが発生した場合に、子ＩＡＢノードにそのような情報を提供する方法は不明確である。研究項目は、「ＲＡＮ－３は将来の規範的段階にアーキテクチャ１ａを推奨する」と結論付けた。これは、ＩＡＢノードがＤＵとＭＴで構成され、ＩＡＢドナーが（ＤＵと）ＣＵで構成されることを意味する。ＣＵはＤＵとＣＵとの間のＲＲＣを担当し、ＢＨ　ＲＬＦはＭＴのＲＲＣで検出される。そのため、考慮すべき２つの異なるＲＲＣがある。親ＩＡＢノードのＭＴ上におけるＲＲＣは、ＢＨ　ＲＬＦを検出し、ＩＡＢドナーの異なるＲＲＣは子ＩＡＢノードに送信されるＲＲＣメッセージを生成する。
　物理的な無線リンクがＢＨ　ＲＬＦで切断されることを考慮すると、ダウンストリームノードへの情報はＲＲＣメッセージで伝達できない。つまり、ＣＵによって生成されたＲＲＣメッセージはＢＨ　ＲＬＦのためにＤＵに到達できない。（選択肢２の）「警告」は、ＭＡＣ　ＣＥなどで送信されてもよいが、（選択肢４の）「ノードのリスト」は、ＲＲＣメッセージを使用しない限り、大きすぎ、フレキシブルすぎる。そのため、選択肢２及び／又は選択肢４が導入された場合、ＲＡＮ２は最初にどのシグナリングが使用されるかを検討すべきである。
　所見２：ＣＵへの物理的な無線リンクが切断されているため、ＩＡＢノードのＤＵはＲＲＣメッセージを使用しなくてもよい。
　この情報はＲｅｌ－１６の機能として提供されることは明らかである。つまり、ＩＡＢノード間でのみサポートされ得る。つまり、Ｒｅｌ－１５のＵＥではサポートされない。
　所見３：選択肢２及び選択肢４は、Ｒｅｌ－１６のＩＡＢノードの復旧手順でのみ機能する。
　２．３．全てのＩＡＢノードは定期的に情報を共有する（選択肢３）
　選択肢３では、ＩＡＢノードは共有される情報に基づいてＢＨ　ＲＬＦを検知できる。ＴＲでキャプチャされる情報は、例えば、「ＢＨ品質」である。これは、Ｆ１の既存のＧＮＢ－ＤＵ　ＳＴＡＴＵＳ　ＩＮＤＩＣＡＴＩＯＮである場合とＤＵ間の新しいシグナリングである場合があってもよい。
所見４：選択肢３はＲＡＮ２の範囲外である可能性がある。
　２．４．代替リンクの事前準備（選択肢５）
　選択肢５は、例えば、マルチコネクティビティ（ＭＮ／ＳＮロール変更あり）、条件付きハンドオーバ、又は通常のトポロジ適応又はモビリティ拡張に関連するその他の技術を利用することを目的とする場合がある。ＴＲで「他のＲｅｌ－１６のＷＩの一部として定義された追加の機能／拡張機能を活用してもよい」と述べられているように、選択肢５は、このＷＩ又は他のＷＩの他のトピックで議論される結果を再利用してもよい。
　所見５：選択肢５は、このＷＩ又は他のＷＩでの他のトピックで議論される解決策を再利用してもよい。
　［付記２］
　１．序論
　統合されたアクセス及びバックホールの新しいワークアイテムはＲＡＮ#８２で承認され、マルチホップ無線バックホールの低レイテンシスケジューリングは特定されると見なされる。
　アーキテクチャ１ａに続くＩＡＢノードの仕様
　・[…]
　・マルチホップトポロジ全体での低レイテンシスケジューリング、ＢＨ　ＲＬＦ処理、及びリソース調整をサポートするためのシグナリングのｈｏｐ－ｂｙ－ｈｏｐ伝搬。
　この寄書では、低レイテンシスケジューリングの解決策について議論する。
　２．議論
　この研究項目は、ＴＲ　３８．８７のセクション８．６でキャプチャされた図１７に示すようなマルチホップバックホールのシーケンス手順によるＵＬスケジューリングのレイテンシの問題を特定した。
　ＴＲはまた、「このような遅延を緩和する１つのアプローチは、到着が予想されるデータに基づいてＩＡＢノードでアップリンクリソース要求を開始することで構成される。これにより、ＩＡＢノードは、子ＩＡＢノード又はそれがサービスを提供するＵＥから実際のデータを受信する前に、アップリンクリソースを取得できるようになる。」、及び「ＳＲ／ＢＳＲ及びＵＬスケジューリングの内容及びトリガの詳細は、ＷＩ段階に残される。」という考えられるメカニズムを特定する。
　詳細に飛ぶ前に、前提条件に応じて解決策が多少異なるため、拡張が動的割り当てに必要か、設定されたグラントに必要か、又はその両方に必要かを明確にすべきである。上記のＴＲの論述は、動的リソース割り当ての使用を意図している可能性がありますが、レイテンシの問題は、設定されるグラントには問題でない場合がありますが、場合によってはスペクトル効率において問題がある場合がある。したがって、ＲＡＮ２は、動的リソース割り当てのためにＳＲ、ＢＳＲ、及び／又はＵＬスケジューリングを拡張すべきである。
　提案１：ＲＡＮ２は、マルチホップ無線バックホールでの動的なリソース割り当てのためにＳＲ、ＢＳＲ、及び／又はＵＬスケジューリングを拡張すべきである。
　現在の仕様では、次のように通常のＢＳＲ送信用のリソースがない場合にＳＲがトリガされる。
　ＭＡＣエンティティ
　１＞バッファステータスレポート手順で、少なくとも1つのＢＳＲがトリガされ、キャンセルされていないと判断された場合
　　[…]
　　２＞通常のＢＳＲがトリガされ、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ－ＤｅｌａｙＴｉｍｅｒが実行されていない場合
　　　３＞新しい送信に利用可能なＵＬ－ＳＣＨリソースがない場合、又は
　　　３＞ＭＡＣエンティティが設定されるアップリンクグラントで設定し、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ－Ｍａｓｋがｆａｌｓｅに設定される論理チャネルに対して通常のＢＳＲがトリガされた場合、又は
　　　３＞新しい伝送に使用可能なＵＬ－ＳＣＨリソースが、ＢＳＲをトリガした論理チャネルに設定されたＬＣＰマッピングの制限（５．４.３．１を参照）を満たさない場合、
　　　　４＞スケジューリング要求をトリガする
　したがって、重要な問題の１つは、通常のＢＳＲのトリガを高速化する方法である。通常のＢＳＲは、次のように、データが送信可能になるとトリガされる。
　ＭＡＣエンティティは、ＴＳ３８．３２２及び３８．３２３のデータ量計算手順に従って、論理チャネルで使用可能なＵＬデータの量を決定する。
　次のいずれかのイベントが発生した場合、ＢＳＲがトリガされる。
　－ＬＣＧに属する論理チャネルのＵＬデータは、ＭＡＣエンティティで利用可能になる。
　－このＵＬデータは、任意のＬＣＧに属する利用可能なＵＬデータを含む論理チャネルの優先度よりも高い優先度を持つ論理チャネルに属する。又は、
　－ＬＣＧに属する論理チャネルには、利用可能なＵＬデータが含まれていない。
　この場合、ＢＳＲは「通常ＢＳＲ」と呼ばれる。
　「アーリー通常ＢＳＲトリガ」を有効にするには、送信可能なデータに追加のルールを設定することが簡単である。現在、このようなデータ量の計算手順はＲＬＣ及びＰＤＣＰレイヤでのみ行われているが、バックホールリンクのＭＴのＭＡＣエンティティは、ＤＵに表示されるＵＬデータ量を何らかの形で考慮すべきである。
　提案２：ＲＡＮ２は、ＭＴのＭＡＣエンティティが、同じＩＡＢノードのＤＵで見えるＵＬデータ量を考慮する必要があることに同意すべきである。
　提案２に同意できる場合、ＤＵに見えるデータ量のどれがデータ利用可能な送信とみなされるかを検討すべきである。以下の選択肢が考慮される。
　選択肢１：ＤＵプロトコルスタックのＭＡＣ、ＲＬＣ、ＰＤＣＰ（及び場合によってはアダプテーションレイヤ）におけるバッファの実際のデータ量。
　選択肢２：選択肢１に加えて、子ノード／ＵＥに既にグラントされているデータ量（図１８）。
　選択肢３：選択肢２に加えて、子ノード／ＵＥでの送信に利用可能なデータ、つまり子ノード／ＵＥからのＢＳＲのバッファサイズ（図１４）。
　レイテンシ削減の観点から、選択肢３は、ＩＡＢノードのＤＵが子ノード／ＵＥからＵＬデータを受信したときにそのＩＡＢノードのＭＴがバックホールリンクのリソースをグラントしたことが予想されるため、最適な解決策である。一方、ＭＴでのＵＬグラントの受信とＤＵでのＵＬデータの受信とが十分に同期されていない限り、リソースの浪費が発生する可能性がある。つまり、オーバースケジューリングが発生する可能性がある。選択肢１はリスクが低いが利益も低くなる。選択肢２は、他の選択肢間のバランスの取れた解決策と見なされる。
　提案３：ＲＡＮ２は、送信に利用可能な追加データがＵＥへのＵＬグラント又はＵＥからのＢＳＲに関連するデータ量であるかどうかを議論すべきである。
　［付記３］
　１．序論
　統合されたアクセスとバックホールに関する新しいワークアイテムが承認された。ＷＩＤは、目的の１つとしてバックホール無線リンク障害（ＢＨ　ＲＬＦ）処理を指定することを定める。
　以下を含むアーキテクチャ1aに続くＩＡＢノードの仕様
　・[…]
　・低遅延スケジューリング、ＢＨ　ＲＬＦ処理、及びマルチホップトポロジ全体のリソース調整をサポートするためのシグナリングのホップバイホップ伝搬。
　・[…]
　Ｌ２トランスポート及びリソース管理のシグナリングの仕様
　・[…]
　・ＢＨ　ＲＬＦ処理の仕様（例：ダウンストリームＢＨ　ＲＬＦ通知）
　この付記では、研究項目からの結果に加えてＢＨ　ＲＬＦ処理の最初の考慮が議論される。
　２．議論
　２．１．背景
　ＴＲは、セクション９．７．１４及び９．７．１５において、マルチホップの無線バックホールのＢＨ　ＲＬＦに起因する問題を特定する。セクション間の共通の問題は、子ＩＡＢノード／ＵＥが親ＩＡＢノードにおけるＢＨ　ＲＬＦを認識していないことである。これにより、ＢＨ　ＲＬＦは、ＦＲ２やマルチホッピングなどの高周波数の無線バックホールにおいて頻繁に発生する可能性がある。結果として、ユーザの観点から、サービスの回復が遅れることを含むサービスが大幅に中断される。
　このような悪いユーザーエクスペリエンスを回避するために、ＴＲは次のように潜在的な解決策も特定する。
　９．７．１４アーキテクチャ１ａにおけるＢＨ　ＲＬＦのダウンストリーム通知
　「選択肢１：ＩＡＢノードＤＵはサービスを中止する。その結果、子ノードもＢＨ　ＲＬＦを決定し、上記の手順に従って回復する。」
　「選択肢２：ＩＡＢノードＤＵは、アップストリームＲＬＦについて子ＩＡＢノードに明示的に警告する。この警告を受信した子ＩＡＢノードは、警告をさらに下流に転送し得る。このような警告を受信した各ＩＡＢノードは、上記のＢＨ－ＲＬＦ回復を開始する。」
　「選択肢３：全てのＩＡＢノードは、ＢＨ品質などに関する情報を子又は親のＩＡＢノードと定期的に共有し得る。このようにして、明示的な動作を実行しなくても、ダウンストリーム又はアップストリームＲＬＦを検知し得る。」
　９．７．１５効率的なバックホールリンク障害の復旧
　「バックホール障害のために親ノードとして機能できないノードのリストを含む、バックホール障害に関する情報は、ダウンストリームＩＡＢノードに提供され得る。」（選択肢４）
　「事前（つまり、ＲＬＦの発生前）における代替バックホールリンクとルートの準備」（選択肢５）
　Ｒ２は、少なくともダウンストリームノードへのＢＨ　Ｌｉｎｋ　ＲＬＦでＲＬＦ通知があると想定する。
　代替リンク及び／又はデュアルコネクティビティ（合意されている場合）は、ＢＨ　Ｌｉｎｋの障害時の復旧時に利用され得る。
　現在のＵＥ　ＲＬＦ検出及び回復は、ベースラインとして再利用される。
　例えば、リンクが回復したとき、または回復が進行中のとき、他の表示が必要かどうかは更なる検討が必要である。
　これらの合意は、上記の選択肢２，４，５に基づいており、追加の側面も含まれる。
　２．２．ＩＡＢノードがサービスを中止する（選択肢１）
　選択肢１は、ＢＨ　ＲＬＦ情報が子ＩＡＢノード及びＵＥに暗示的に伝搬されるため、セクション９．７．１４と９．７．１５との間の共通の問題のための一般的な解決策と見なし得る。合意された「ＲＬＦ通知」はＲｅｌ－１６の機能だが、Ｒｅｌ－１５　ＵＥは、ＩＡＢノードとの接続をまだ許可される。Ｒｅｌ－１５　ＵＥの場合でもサービスの中断を最小限に抑えるには、ＢＨ　ＲＬＦの問題のためのベースラインの解決策として選択肢１を指定すべきである。
　所見１：合意された「ＲＬＦ通知」は、Ｒｅｌ－１５　ＵＥの観点からＢＨ　ＲＬＦの問題を解決できない。
　選択肢１の説明によれば、解決策は「子ノードもＢＨ　ＲＬＦを判定する」ことを容易にすべきである。簡単な解決策は、ＢＨ　ＲＬＦ下にある親ＩＡＢノードが、ＰＳＳ、ＳＳＳ、ＭＩＢ、及びＳＩＢ１の送信を停止することである。これにより、子ＩＡＢノード及びＵＥの無線問題を意図的に作成する。
　提案１：ＲＡＮ２は、「サービス」を中止することを決定した場合に、ＩＡＢノードがＰＳＳ、ＳＳＳ、ＭＩＢ、及びＳＩＢ１の送信を停止することに同意すべきである。
　提案１に同意できる場合、ＲＡＮ２はすでに「ＢＨ　Ｌｉｎｋ　ＲＬＦでのＲＬＦ通知」を想定しており、また、現在のＵＥの動作はＲＬＦを宣言した後でも、つまりＲＲＣ再確立を開始するためにＲＲＣ接続を維持するため、ＲＬＦでサービスを実際に停止する必要があるかどうかは疑問である。ＵＥがＲＲＣ接続を正常に再確立すると、最小の中断時間でサービスが回復する。そのため、ＩＡＢノードは、ＭＴがＲＲＣ　ＩＤＬＥに入った場合、つまりＲＲＣ再確立が失敗した場合にのみ、「サービス」を停止すべきであることが分かる。この意味では、ＭＴが（同じＩＡＢノードの）ＤＵにＲＲＣ　ＩＤＬＥに入ること（セットアップ段階でＲＲＣ　Ｃｏｎｎｅｃｔｅｄに移行する可能性もあること）を通知するのは自然である。
　提案２：ＲＡＮ２は、ＭＴがＲＬＦを宣言した場合ではなく、ＭＴがＲＲＣ　ＩＤＬＥに入った場合、ＩＡＢノードのＤＵが「サービス」を停止することに同意すべきである。
　提案３：提案２に同意できる場合、ＲＡＮ２は、ＭＴがＲＲＣ　ＩＤＬＥに入った場合、ＭＴが（同じＩＡＢノードの）ＤＵに通知する必要があるかどうかについてさらに議論する。
　２．３．ＩＡＢノードはダウンストリームノードに通知する（選択肢２、選択肢４）
　子ＩＡＢノードが回復手順を迅速及び／又は効率的に開始することを容易にするため、親ＩＡＢノードがそのＢＨ　ＲＬＦに関連する情報を子ＩＡＢノードに通知することは役立つ。ＴＲは、「アップストリームＲＬＦについて子ＩＡＢノードに明示的に警告する」（選択肢２）のような可能な情報要素、又は「親ノードとして機能できないノードのリストを含むバックホール障害に関する」（選択肢４）情報をキャプチャする。さらに、ＲＡＮ２は、「Ｒ２は、少なくともダウンストリームノードへのＢＨ　Ｌｉｎｋ　ＲＬＦでＲＬＦ通知があると想定する」というベースラインに合意した。
　ただし、親ＩＡＢノードでＢＨ　ＲＬＦが発生した場合に、子ＩＡＢノードにそのような情報を提供する方法は不明確である。研究項目は、「ＲＡＮ－３は将来の規範的段階にアーキテクチャ１ａを推奨する」と結論付けた。これは、ＩＡＢノードがＤＵとＭＴで構成され、ＩＡＢドナーが（ＤＵと）ＣＵで構成されることを意味する。ＣＵはＤＵとＣＵとの間のＲＲＣを担当し、ＢＨ　ＲＬＦはＭＴのＲＲＣで検出される。そのため、考慮すべき２つの異なるＲＲＣがある。親ＩＡＢノードのＭＴ上におけるＲＲＣは、ＢＨ　ＲＬＦを検出し、ＩＡＢドナーの異なるＲＲＣは子ＩＡＢノードに送信されるＲＲＣメッセージを生成する。
　物理的な無線リンクがＢＨ　ＲＬＦで切断されることを考慮すると、ダウンストリームノードへの情報はＲＲＣメッセージで伝達できない。つまり、ＣＵによって生成されたＲＲＣメッセージはＢＨ　ＲＬＦのためにＤＵに到達できない。（選択肢２の）「警告」は、ＭＡＣ　ＣＥで送信されてもよいが、ＭＡＣ　ＣＥは「ノードのリスト」（選択肢４）を伝えるのに適切ではない。したがって、ＲＡＮ２は選択肢２をＭＡＣ　ＣＥで想定し、選択肢４を考慮すべきではない。
　所見２：ＣＵへの物理的な無線リンクが切断されているため、ＩＡＢノードのＤＵはＲＲＣメッセージを使用しなくてもよい。
　提案４：ＲＡＮ２は、ダウンストリームノードへのＲＬＦ通知がＭＡＣ　ＣＥを介して送信されるかどうかを議論すべきである。
　ＲＬＦ通知がいつ/どのようにトリガされるかについても議論されるだろう。情報の名前を考慮すると、ＢＨ　ＲＬＦがＭＴで宣言された時にＲＬＦ通知が送信されるのが素直である。この場合、ＤＵはＢＨ　ＲＬＦに従ってＲＬＦ通知を生成／送信する必要があるため、ＭＴはＲＬＦ宣言を（同じＩＡＢノードの）ＤＵに通知すべきである。前のセクションの提案２に同意できる場合、ＢＨ　ＲＬＦ、つまりＩＡＢノードがＲＬＦ通知を送信するだけの場合、「サービス」が継続し、ＭＴがＲＲＣ　ＩＤＬＥに入ると「サービス」が停止する。
　提案５：ＲＡＮ２は、ＤＵがＭＴによってＲＬＦを通知されるとＲＬＦ通知が送信されることに同意すべきである。
　もう１つの疑問は、ＲＬＦ通知の受信時の（子ＩＡＢノードの）ＭＴ動作である。ＭＴが何らかの回復手順を開始することは想定し得るが、それはＭＴがＲＬＦを宣言する「前の」プロセスであるべきである。つまり、ＲＬＦ通知は、子ノードのＲＬＦをすぐにトリガすべきではない。なぜなら、ＲＬＦの宣言により、さらにダウンストリームノードへのＲＬＦ通知がトリガされ、ＲＬＦ通知は間もなくＩＡＢトポロジ間で伝搬されるからである。不要なトポロジ適応のストリームが発生し、最悪の場合はＩＡＢトポロジが破損する可能性がある。
　提案６：ＲＡＮ２は、ＭＴ/ＵＥがＲＬＦ通知の受信時にＲＬＦを宣言せず、何らかのバックホールリンクの回復を開始するだけであることに同意すべきである。
　ＲＡＮ２は、「Ｒ２は、少なくともダウンリンクノードへのＢＨ　Ｌｉｎｋ　ＲＬＦでＲＬＦ通知があると想定する」ことに同意した。これにより、「ダウンストリームノード」とは、親ノードに直接接続されている子ノード/ＵＥを意味することが自然である。ただし、「ダウンストリームノード」に、親と直接接続していない孫ノード／ＵＥ（つまり、親は孫の観点から祖父母である）も含まれているかどうかは明確ではない。
　孫がＲＬＦ通知を受信できる場合、ＲＬＦ通知の伝播遅延がなくなるため、トポロジの回復が速くなるという利点がある。さらに、副産物として、任意のＩＤＬＥノード／ＵＥがＲＬＦ通知を受信できる場合、再選択の際に考慮される可能性がある。これにより、ノード／ＵＥは、ドナーノードに接続できないため、セルのランクが最高であっても、ＢＨ　ＲＬＦが発生するセルの再選択または接続を回避するよう試みることができる。欠点は、トポロジの適応と管理が複雑になることである。例えば、極端な場合、ＩＡＢトポロジ内の全てのノード／ＵＥが１つのノードからＲＬＦ通知を受信して回復手順を開始すると、多くの不必要なトポロジ変更が行われる可能性があり、最悪の場合、ＩＡＢトポロジが破損する。したがって、上記の長所と短所を考慮して、ＲＬＦ通知を子ノードのみが受信するかどうかを検討すべきである。
　提案７：ＲＡＮ２は、ＲＬＦ通知を子ノードのみが受信するか、孫ノードも受信するかを明確にすべきである。
　前回の会議では、ＲＡＮ２は「例えば、リンクが回復したとき、または回復が進行中のとき、他の指示が必要かどうかはさらに検討する必要がある」とした。
　子ＩＡＢノード又はＵＥの観点から、ＲＬＦ通知が受信されると、何らかのトポロジ適応手順、例えば、他のＩＡＢノードへのＲＲＣ再確立、又は冗長ルートへのプライマリパスの切り替えが開始される。この意味では、バックホールの「リンクが回復した」という情報は、トポロジ適応手順が完了していない場合、例えばＲＲＣ再確立手順で適切なセルが見つからない場合、手順を停止できるため有益である。ただし、ＲＬＦ通知がＢＨ　ＲＬＦ中に繰り返し送信される場合、任意の「他の指示」を規定する必要はない。ＲＬＦ通知が送信されない場合、ＢＨ　ＲＬＦは発生していないことになるからだ。そうでない場合、「サービス」が停止する。したがって、問題は、ＢＨ　ＲＬＦ中にＲＬＦ通知を繰り返し送信するかどうかである。
　提案８：ＲＡＮ２は、ＢＨ　ＲＬＦ中にＲＬＦ通知が繰り返し送信されるかどうかを議論すべきである。
　他の例、つまり「回復が進行中」については、子ノード／ＵＥの動作は不明確である。子ノード／ＵＥをしばらく待機させることだけを意味する場合、ダウンストリームノードへの何らの指示も（ＲＬＦ通知さえ）必要としない可能性がある。したがって、この時点で導入する動機はない。
　２．４．全てのＩＡＢノードは定期的に情報を共有する（選択肢３）
　選択肢３では、ＩＡＢノードは共有される情報に基づいてＢＨ　ＲＬＦを検知できる。ＴＲでキャプチャされる情報は、例えば、「ＢＨ品質」である。これは、Ｆ１の既存のＧＮＢ－ＤＵ　ＳＴＡＴＵＳ　ＩＮＤＩＣＡＴＩＯＮである場合とＤＵ間の新しいシグナリングである場合があってもよい。
所見３：選択肢３はＲＡＮ２の範囲外である可能性がある。
　２．５．代替リンクの事前準備（選択肢５）
　選択肢５は、例えば、マルチコネクティビティ（ＭＮ／ＳＮロール変更あり）、条件付きハンドオーバ、又は通常のトポロジ適応又はモビリティ拡張に関連するその他の技術を利用することを目的とする場合がある。ＴＲで「他のＲｅｌ－１６のＷＩの一部として定義された追加の機能／拡張機能を活用してもよい」と述べられているように、選択肢５は、このＷＩ又は他のＷＩの他のトピックで議論される結果を再利用してもよい。ＲＬＦ通知が「ＭＣＧ　Ｆａｉｌｕｒｅ　Ｉｎｄｉｃａｔｉｏｎ」などの特定の動作をトリガするかどうかなど、ＩＡＢ固有の影響のみが（ある場合）後で議論されるだろう。
　所見４：選択肢５は、このＷＩ又は他のＷＩでの他のトピックで議論される解決策を再利用してもよい。
　本願は、米国仮出願第６２／８２５１４９号（２０１９年３月２８日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。

Claims (12)

  1. 　上位装置と下位装置との間の通信を無線で中継する中継装置を用いる通信制御方法であって、
    　前記中継装置において、前記下位装置と無線で接続する基地局機能部が、前記上位装置と無線で接続するユーザ装置機能部又は前記上位装置を介してドナー装置と通信する通信機能部に対して、状態情報を通知することを含み、
    　前記状態情報は、前記基地局機能部と前記下位装置の間の無線リンク状態を示す情報である
    　通信制御方法。
  2. 　前記基地局機能部と前記下位装置の間の無線リンク障害の発生を前記状態情報が示す場合、前記ユーザ装置機能部又は前記通信機能部が、前記無線リンク障害を通知するメッセージを前記ドナー装置に送信することをさらに含む
    　請求項１に記載の通信制御方法。
  3. 　上位装置と下位装置との間の通信を無線で中継する中継装置を用いる通信制御方法であって、
    　前記中継装置において、前記上位装置と無線で接続するユーザ装置機能部が、前記下位装置と無線で接続する基地局機能部に対して状態情報を通知することを含み、
    　前記状態情報は、前記ユーザ装置機能部のＲＲＣ状態、及び前記上位装置と前記ユーザ装置機能部との間の無線リンク状態のうち、少なくとも一方の状態を示す情報である
    　通信制御方法。
  4. 　前記状態情報を通知することは、前記状態の変化をトリガとして、前記状態情報を前記基地局機能部に通知することを含む
    　請求項３に記載の通信制御方法。
  5. 　前記基地局機能部が、前記状態情報に基づいて、前記下位装置に対するサービス提供を停止することをさらに含む
    　請求項３又は４に記載の通信制御方法。
  6. 　前記基地局機能部が、前記状態情報に基づいて、前記上位装置と前記ユーザ装置機能部との間の無線リンク状態の劣化を示す通知を前記下位装置に送信することをさらに含む
    　請求項２乃至５のいずれか１項に記載の通信制御方法。
  7. 　前記通知を受信した前記下位装置が、接続先又は通信経路を前記中継装置から切り替えるための処理を行うことをさらに含む
    　請求項６に記載の通信制御方法。
  8. 　前記下位装置に通知を送信することは、前記基地局機能部においてＲＲＣレイヤよりも下位のレイヤの制御信号により前記通知を送信することを有する
    　請求項６又は７に記載の通信制御方法。
  9. 　前記下位装置に通知を送信することは、前記通知をブロードキャスト又はマルチキャストで送信することを有する
    　請求項６乃至８のいずれか１項に記載の通信制御方法。
  10. 　前記中継装置の配下にない他の下位装置が前記通知を受信した場合、前記他の下位装置が、接続先の候補として前記中継装置を除外するための処理を行うことをさらに含む
    　請求項９に記載の通信制御方法。
  11. 　前記下位装置に通知を送信することは、前記上位装置と前記ユーザ装置機能部との間の無線リンク状態が劣化している期間内において前記通知を周期的に送信することを有する
    　請求項６乃至１０のいずれか１項に記載の通信制御方法。
  12. 　上位装置と下位装置との間の通信を無線で中継する中継装置を用いる通信制御方法であって、
    　前記中継装置が、前記中継装置に接続する下位装置から、他の中継装置との無線リンク障害の発生を示す通知を受信することと、
    　前記中継装置が、ドナー装置に対して、前記無線リンク障害に関するメッセージを送信することと、を含む
    　通信制御方法。
PCT/JP2020/012148 2019-03-28 2020-03-18 通信制御方法 WO2020196201A1 (ja)

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 通信制御方法、第１中継装置及びプロセッサ

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)

* Cited by examiner, † Cited by third party
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 株式会社Ｎｔｔドコモ 無線通信ノード、無線通信システム及び無線通信方法
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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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 株式会社Ｎｔｔドコモ 無線通信ノード、無線通信システム及び無線通信方法
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