WO2024070923A1 - 通信制御方法 - Google Patents

通信制御方法 Download PDF

Info

Publication number
WO2024070923A1
WO2024070923A1 PCT/JP2023/034429 JP2023034429W WO2024070923A1 WO 2024070923 A1 WO2024070923 A1 WO 2024070923A1 JP 2023034429 W JP2023034429 W JP 2023034429W WO 2024070923 A1 WO2024070923 A1 WO 2024070923A1
Authority
WO
WIPO (PCT)
Prior art keywords
iab
node
rach
handover
iab node
Prior art date
Application number
PCT/JP2023/034429
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 京セラ株式会社
Publication of WO2024070923A1 publication Critical patent/WO2024070923A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/08—Reselecting an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices

Definitions

  • This disclosure relates to a communication control method for use in a cellular communication system.
  • the 3GPP (Third Generation Partnership Project), a standardization project for cellular communication systems, is considering the introduction of a new relay node called an IAB (Integrated Access and Backhaul) node (see, for example, Non-Patent Document 1).
  • IAB Integrated Access and Backhaul
  • One or more relay nodes intervene in communication between a base station and user equipment and relay this communication.
  • the communication control method is a communication control method used in a cellular communication system.
  • the communication control method includes a step in which a distributed unit (DU) transmits resource information regarding resources used in a user equipment during a RACH-less handover to a central unit (CU), and a step in which the central unit transmits a handover command including the resource information to the user equipment.
  • DU distributed unit
  • CU central unit
  • the communication control method is a communication control method used in a cellular communication system.
  • the communication control method includes a step in which a central unit (CU) transmits validity period information indicating a validity period of resources used in a user equipment during a conditional RACH-less handover to a distributed unit (DU), and the distributed unit transmits the validity period information to the central unit.
  • the communication control method also includes a step in which the central unit transmits a conditional reconfiguration including the validity period information to the user equipment.
  • FIG. 1 is a diagram showing an example of the configuration of a cellular communication system according to an embodiment.
  • FIG. 2 is a diagram showing the relationship between the IAB node, parent nodes, and child nodes.
  • Figure 3 is a diagram showing an example configuration of a gNB (base station) according to one embodiment.
  • FIG. 4 is a diagram illustrating a configuration example of an IAB node (relay node) according to an embodiment.
  • FIG. 5 is a diagram illustrating a configuration example of a UE (user equipment) according to an embodiment.
  • FIG. 6 is a diagram showing an example of a protocol stack related to an IAB-MT RRC connection and a NAS connection.
  • FIG. 7 is a diagram showing an example of a protocol stack for the F1-U protocol.
  • FIG. 8 is a diagram showing an example of a protocol stack for the F1-C protocol.
  • 9A and 9B are diagrams illustrating an example of a complete move according to the first embodiment.
  • 10A and 10B are diagrams illustrating an example of a complete move according to the first embodiment.
  • FIG. 11 is a diagram showing an example of the relationship between a CU, a DU, and a UE according to the first embodiment.
  • 12(A) and 12(B) are diagrams showing an example of the relationship between a CU, a DU, and a UE according to the first embodiment.
  • 13A and 13B are diagrams showing an example of the relationship between a CU, a DU, and a UE according to the first embodiment.
  • FIG. 14 is a diagram illustrating an example of an operation according to the first embodiment.
  • FIG. 15 is a diagram illustrating an example of an operation according to the second embodiment.
  • Figure 16 shows a diagram illustrating RACH-less handover using a TA (Timing Advance) value and/or a UL grant.
  • FIG. 17 illustrates scenarios and sub-cases of UE cell reselection.
  • FIG. 18 illustrates a scenario for a PCI collision.
  • the cellular communication system 1 is a 3GPP 5G system.
  • the radio access method in the cellular communication system 1 is NR (New Radio), which is a 5G radio access method.
  • NR New Radio
  • LTE Long Term Evolution
  • the cellular communication system 1 may also be applied to future cellular communication systems such as 6G.
  • FIG. 1 is a diagram showing an example of the configuration of a cellular communication system 1 according to one embodiment.
  • the cellular communication system 1 includes a 5G core network (5GC) 10, a user equipment (UE) 100, base station equipment (hereinafter sometimes referred to as "base stations") 200-1, 200-2, and IAB nodes 300-1, 300-2.
  • the base station 200 may be referred to as a gNB.
  • the base station 200 may also be an LTE base station (i.e., an eNB).
  • LTE base station i.e., an eNB
  • base stations 200-1 and 200-2 may be referred to as gNB 200 (or base station 200), and IAB nodes 300-1 and 300-2 may be referred to as IAB node 300.
  • the 5GC10 has an AMF (Access and Mobility Management Function) 11 and a UPF (User Plane Function) 12.
  • the AMF 11 is a device that performs various mobility controls for the UE 100.
  • the AMF 11 manages information about the area in which the UE 100 is located by communicating with the UE 100 using NAS (Non-Access Stratum) signaling.
  • the UPF 12 is a device that performs transfer control of user data, etc.
  • Each gNB200 is a fixed wireless communication node and manages one or more cells.
  • a cell is used as a term indicating the smallest unit of a wireless communication area.
  • a cell is sometimes used as a term indicating a function or resource for performing wireless communication with a UE100.
  • One cell belongs to one carrier frequency. In the following, there may be no distinction between a cell and a base station.
  • Each gNB200 is interconnected with the 5GC10 via an interface called the NG interface.
  • Figure 1 shows two gNBs, gNB200-1 and gNB200-2, connected to the 5GC10.
  • Each gNB200 may be divided into a central unit (CU) and a distributed unit (DU).
  • the CU and DU are connected to each other via an interface called the F1 interface.
  • the F1 protocol is a communication protocol between the CU and DU, and includes the F1-C protocol, which is a control plane protocol, and the F1-U protocol, which is a user plane protocol.
  • the cellular communication system 1 supports IAB, which enables wireless relay of NR access using NR for backhaul.
  • the donor gNB 200-1 (or donor node, hereinafter sometimes referred to as the "donor node") is the terminal node of the NR backhaul on the network side, and is a donor base station with additional functions to support IAB.
  • the backhaul is capable of multi-hopping via multiple hops (i.e., multiple IAB nodes 300).
  • IAB node 300-1 wirelessly connects to donor node 200-1
  • IAB node 300-2 wirelessly connects to IAB node 300-1
  • the F1 protocol is transmitted over two backhaul hops.
  • UE100 is a mobile wireless communication device that performs wireless communication with a cell.
  • UE100 may be any device that performs wireless communication with a gNB200 or an IAB node300.
  • UE100 is a mobile phone terminal and/or a tablet terminal, a notebook PC, a sensor or a device provided in a sensor, a vehicle or a device provided in a vehicle, or an aircraft or a device provided in an aircraft.
  • UE100 wirelessly connects to the IAB node300 or gNB200 via an access link.
  • FIG. 1 shows an example in which UE100 is wirelessly connected to IAB node300-2.
  • UE100 indirectly communicates with donor node200-1 via IAB node300-2 and IAB node300-1.
  • FIG. 2 shows an example of the relationship between the IAB node 300, parent nodes, and child nodes.
  • each IAB node 300 has an IAB-DU, which corresponds to a base station function unit, and an IAB-MT (Mobile Termination), which corresponds to a user equipment function unit.
  • IAB-DU which corresponds to a base station function unit
  • IAB-MT Mobile Termination
  • the adjacent node (i.e., the upper node) on the NR Uu radio interface of the IAB-MT is called the parent node.
  • the parent node is the parent IAB node or the DU of the donor node 200.
  • the radio link between the IAB-MT and the parent node is called the backhaul link (BH link).
  • BH link backhaul link
  • FIG. 2 an example is shown in which the parent nodes of the IAB node 300 are IAB nodes 300-P1 and 300-P2.
  • the direction toward the parent node is called the upstream. From the perspective of the UE 100, the upper node of the UE 100 may be the parent node.
  • Neighboring nodes i.e., lower nodes on the NR access interface of the IAB-DU are called child nodes.
  • the IAB-DU manages the cell, similar to the gNB 200.
  • the IAB-DU terminates the NR Uu radio interface to the UE 100 and lower IAB nodes.
  • the IAB-DU supports the F1 protocol to the CU of the donor node 200-1.
  • FIG. 2 an example is shown in which the child nodes of the IAB node 300 are IAB nodes 300-C1 to 300-C3, but the child nodes of the IAB node 300 may include the UE 100.
  • the direction toward the child nodes is called downstream.
  • all IAB nodes 300 connected to the donor node 200 via one or more hops form a directed acyclic graph (DAG) topology (hereinafter sometimes referred to as "topology") with the donor node 200 as the root.
  • DAG directed acyclic graph
  • adjacent nodes on the IAB-DU interface are child nodes
  • adjacent nodes on the IAB-MT interface are parent nodes.
  • the donor node 200 centralizes, for example, resource, topology, and route management of the IAB topology.
  • the donor node 200 is a gNB that provides network access to the UE 100 via a network of backhaul links and access links.
  • Fig. 3 is a diagram showing an example of the configuration of the gNB 200.
  • the gNB 200 has a wireless communication unit 210, a network communication unit 220, and a control unit 230.
  • the wireless communication unit 210 performs wireless communication with the UE 100 and with the IAB node 300.
  • the wireless communication unit 210 has 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, and converts (down-converts) a wireless signal received by the antenna into a baseband signal (received signal) and outputs the signal to the control unit 230.
  • the transmitting unit 212 performs various transmissions under the control of the control unit 230.
  • the transmitting unit 212 includes an antenna, and converts (up-converts) a baseband signal (transmitted signal) output by the control unit 230 into a wireless signal and transmits the signal from the antenna.
  • the network communication unit 220 performs wired communication (or wireless communication) with the 5GC10 and wired communication (or wireless communication) with other adjacent gNBs 200.
  • the network communication unit 220 has a receiving unit 221 and a transmitting unit 222.
  • the receiving unit 221 performs various receptions under the control of the control unit 230.
  • the receiving unit 221 receives signals from the outside and outputs the received signals to the control unit 230.
  • the transmitting unit 222 performs various transmissions under the control of the control unit 230.
  • the transmitting unit 222 transmits the transmission signals output by the control unit 230 to the outside.
  • the control unit 230 performs various controls in the gNB 200.
  • the control unit 230 includes at least one memory and at least one processor electrically connected to the memory.
  • the memory stores programs executed by the processor and information used in processing by the processor.
  • the processor may include a baseband processor and a CPU.
  • the baseband processor performs modulation/demodulation and encoding/decoding of baseband signals.
  • the CPU executes programs stored in the memory to perform various processes.
  • the processor performs processing of each layer, which will be described later. Note that the control unit 230 may perform each process or operation in the gNB 200 in each of the embodiments shown below.
  • FIG. 4 is a diagram showing an example of the configuration of the IAB node 300.
  • the IAB node 300 has a wireless communication unit 310 and a control unit 320.
  • the IAB node 300 may have a plurality of wireless communication units 310.
  • the wireless communication unit 310 performs wireless communication with the gNB 200 (BH link) and wireless communication with the UE 100 (access link).
  • the wireless communication unit 310 for BH link communication and the wireless communication unit 310 for access link communication may be provided separately.
  • the wireless communication unit 310 has a receiving unit 311 and a transmitting unit 312.
  • the receiving unit 311 performs various receptions under the control of the control unit 320.
  • the receiving unit 311 includes an antenna, and converts (down-converts) the wireless signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 320.
  • the transmitting unit 312 performs various transmissions under the control of the control unit 320.
  • the transmitting unit 312 includes an antenna, and converts (up-converts) the baseband signal (transmitted signal) output by the control unit 320 into a wireless signal and transmits it from the antenna.
  • the control unit 320 performs various controls in the IAB node 300.
  • the control unit 320 includes at least one memory and at least one processor electrically connected to the memory.
  • the memory stores programs executed by the processor and information used in processing by the processor.
  • the processor may include a baseband processor and a CPU.
  • the baseband processor performs modulation/demodulation and encoding/decoding of baseband signals.
  • the CPU executes programs stored in the memory to perform various processes.
  • the processor performs processing of each layer, which will be described later. Note that the control unit 320 may perform each process or operation in the IAB node 300 in each of the embodiments shown below.
  • Fig. 5 is a diagram showing an example of the configuration of the UE 100. As shown in Fig. 5, the UE 100 has a radio communication unit 110 and a control unit 120.
  • the wireless communication unit 110 performs wireless communication in the access link, i.e., wireless communication with the gNB 200 and wireless communication with the IAB node 300.
  • the wireless communication unit 110 may also perform wireless communication in the side link, i.e., wireless communication with other UEs 100.
  • the wireless communication unit 110 has a receiving unit 111 and a transmitting unit 112.
  • the receiving unit 111 performs various receptions under the control of the control unit 120.
  • the receiving unit 111 includes an antenna, and converts (down-converts) a wireless signal received by the antenna into a baseband signal (received signal) and outputs it to the control unit 120.
  • the transmitting unit 112 performs various transmissions under the control of the control unit 120.
  • the transmitting unit 112 includes an antenna, and converts (up-converts) a baseband signal (transmitted signal) output by the control unit 120 into a wireless signal and transmits it from the antenna.
  • the control unit 120 performs various controls in the UE 100.
  • the control unit 120 includes at least one memory and at least one processor electrically connected to the memory.
  • the memory stores programs executed by the processor and information used in the processing by the processor.
  • the processor may include a baseband processor and a CPU.
  • the baseband processor performs modulation/demodulation and encoding/decoding of baseband signals.
  • the CPU executes programs stored in the memory to perform various processing.
  • the processor performs processing of each layer, which will be described later. Note that the control unit 120 may perform each processing in the UE 100 in each of the embodiments shown below.
  • Fig. 6 is a diagram showing an example of a protocol stack related to an RRC connection and a NAS connection of an IAB-MT.
  • the IAB-MT of IAB node 300-2 has a physical (PHY) layer, a Medium Access Control (MAC) layer, a Radio Link Control (RLC) layer, a Packet Data Convergence Protocol (PDCP) layer, a Radio Resource Control (RRC) layer, and a Non-Access Stratum (NAS) layer.
  • PHY physical
  • MAC Medium Access Control
  • RLC Radio Link Control
  • PDCP Packet Data Convergence Protocol
  • RRC Radio Resource Control
  • NAS Non-Access Stratum
  • the PHY layer performs encoding/decoding, modulation/demodulation, antenna mapping/demapping, and resource mapping/demapping. Data and control information are transmitted via a physical channel between the PHY layer of the IAB-MT of IAB node 300-2 and the PHY layer of the IAB-DU of IAB node 300-1.
  • the MAC layer performs data priority control, retransmission processing using Hybrid Automatic Repeat reQuest (HARQ), random access procedures, etc.
  • Data and control information are transmitted between the MAC layer of the IAB-MT of IAB node 300-2 and the MAC layer of the IAB-DU of IAB node 300-1 via a transport channel.
  • the MAC layer of the IAB-DU includes a scheduler. The scheduler determines the transport format (transport block size, modulation and coding scheme (MCS)) and the allocated resource blocks for the uplink and downlink.
  • MCS modulation and coding scheme
  • the RLC layer uses the functions of the MAC layer and PHY layer to transmit data to the RLC layer on the receiving side. Data and control information are transmitted between the RLC layer of the IAB-MT of IAB node 300-2 and the RLC layer of the IAB-DU of IAB node 300-1 via logical channels.
  • the PDCP layer performs header compression/decompression, and encryption/decryption. Data and control information are transmitted between the PDCP layer of the IAB-MT of IAB node 300-2 and the PDCP layer of the donor node 200 via a radio bearer.
  • the RRC layer controls logical channels, transport channels, and physical channels in response to the establishment, re-establishment, and release of radio bearers.
  • RRC signaling for various settings is transmitted between the RRC layer of the IAB-MT of IAB node 300-2 and the RRC layer of the donor node 200.
  • the IAB-MT When there is an RRC connection with the donor node 200, the IAB-MT is in an RRC connected state. When there is no RRC connection with the donor node 200, the IAB-MT is in an RRC idle state.
  • the NAS layer which is located above the RRC layer, performs session management, mobility management, etc.
  • NAS signaling is transmitted between the NAS layer of the IAB-MT of IAB node 300-2 and AMF 11.
  • FIG. 7 is a diagram showing the protocol stack for the F1-U protocol.
  • FIG. 8 is a diagram showing the protocol stack for the F1-C protocol.
  • the donor node 200 is divided into a CU and a DU.
  • the IAB-MT of IAB node 300-2, the IAB-DU of IAB node 300-1, the IAB-MT of IAB node 300-1, and the DU of donor node 200 each have a BAP (Backhaul Adaptation Protocol) layer above the RLC layer.
  • the BAP layer is a layer that performs routing processing and bearer mapping/demapping processing. In the backhaul, the IP layer is transmitted via the BAP layer, making routing over multiple hops possible.
  • the PDUs (Protocol Data Units) of the BAP layer are transmitted by a backhaul RLC channel (BH NR RLC channel).
  • BH NR RLC channel backhaul RLC channel
  • traffic prioritization and QoS (Quality of Service) control are possible.
  • the correspondence between the BAP PDUs and the backhaul RLC channels is performed by the BAP layer of each IAB node 300 and the BAP layer of the donor node 200.
  • the protocol stack of the F1-C protocol has an F1AP layer and an SCTP layer instead of the GTP-U layer and UDP layer shown in Figure 7.
  • the processing or operations performed by the IAB-DU and IAB-MT of the IAB may be described simply as the processing or operations of the "IAB.”
  • the transmission of a BAP layer message by the IAB-DU of IAB node 300-1 to the IAB-MT of IAB node 300-2 will be described as IAB node 300-1 sending that message to IAB node 300-2.
  • the processing or operations of the DU or CU of the donor node 200 may be described simply as the processing or operations of the "donor node.”
  • the terms may be used without distinguishing between the upstream direction and the uplink (UL) direction. Furthermore, the terms may be used without distinguishing between the downstream direction and the downlink (DL) direction.
  • a mobile IAB node is, for example, an IAB node that is moving.
  • a mobile IAB node may be an IAB node that can move.
  • a mobile IAB node may be an IAB node that has the ability to move.
  • a mobile IAB node may be an IAB node that is currently stationary but is certain to move in the future (or is expected to move in the future).
  • the mobile IAB node makes it possible, for example, for a UE 100 under the mobile IAB node to receive services from the mobile IAB node while moving in accordance with the movement of the mobile IAB node.
  • a UE 100 on board a vehicle receives services via a mobile IAB node installed on the vehicle.
  • IAB nodes that do not move.
  • IAB nodes are sometimes called intermediate IAB nodes.
  • An intermediate IAB node is, for example, an IAB node that does not move.
  • the intermediate IAB node may be a stationary IAB node.
  • An intermediate IAB node may be a stationary IAB node.
  • the intermediate IAB node may be an IAB node that remains stationary (or does not move) installed at the installation location.
  • the intermediate IAB node may be a stationary IAB node that does not move.
  • An intermediate IAB node may be a fixed IAB node.
  • a mobile IAB node can also be connected to an intermediate IAB node.
  • a mobile IAB node can also be connected to a donor node 200.
  • a mobile IAB node can also change its connection destination due to migration or handover.
  • the source of the connection may be an intermediate IAB node.
  • the source of the connection may be the donor node 200.
  • the destination of the connection may be an intermediate IAB node.
  • the destination of the connection may be the donor node 200.
  • the mobile IAB node may be called a "mobile IAB node.”
  • the mobile IAB node may also be called a "migrating IAB node.” In either case, it may be referred to as a mobile IAB node.
  • a mobile IAB node may move between donor nodes 200 .
  • Figures 9(A) to 10(B) are diagrams showing an example of the procedure when the mobile IAB node 300M moves from the source donor node 200-S to the target donor node 200-T.
  • the mobile IAB node 300M has a UE 100 under it.
  • the example in Figure 9(A) shows an example in which the UE 100 is present in the cell range formed by IAB-DU#1 of the mobile IAB node 300M.
  • the UE 100 can move together with the mobile IAB node 300M.
  • Figure 9 (A) shows an example of the initial condition.
  • IAB-DU#1 of the mobile IAB node 300M has established an F1 connection to the CU of the source donor node 200-S.
  • IAB-MT of the mobile IAB node 300M has established an RRC connection to the CU of the source donor node 200-S.
  • Figure 9 (B) shows an example in which the mobile IAB node 300M has moved to the target donor node 200-T, resulting in a state of partial migration with respect to the target donor node 200-T.
  • the IAB-DU#1 (and UE100) of the mobile IAB node 300M is terminated in the CU of the source donor node 200-S, while the IAB-MT of the mobile IAB node 300M has moved to the CU of the target donor node 200-T.
  • the IAB-MT of the mobile IAB node 300M has established an RRC connection with the CU of the target donor node 200-T.
  • the IAB-DU of the mobile IAB node 300M has established an F1 connection with the source donor node 200-S.
  • Partial mobility refers to a state in which, for example, the connection of UE 100 under mobile IAB node 300M remains with source donor node 200-S via IAB-DU #1 of mobile IAB node 300M.
  • FIG. 10(A) shows an example of a case where the mobile IAB node 300M subsequently enters a state of phase 1 of full migration with respect to the target donor node 200-T.
  • the UE 100 In phase 1 of full migration, the UE 100 remains connected to the source donor node 200-S via IAB-DU#1, but a new IAB-DU#2 has established an F1 connection with the CU of the target donor node 200-T.
  • IAB-DU#1 and IAB-DU#2 may be logical IAB-DUs.
  • One physical IAB-DU may contain two logical IAB-DUs (IAB-DU#1 and IAB-DU#2).
  • Figure 10 (B) shows an example of the case where the mobile IAB node 300M then enters phase 2 of complete movement with respect to the target donor node 200-T.
  • phase 2 of complete movement the connection of the mobile IAB node 300M (and UE 100) has moved from the CU of the source donor node 200-S to the CU of the target donor node 200-T.
  • Complete movement refers to, for example, a state in which the connection of the UE 100 has moved to the target donor node 200-T via IAB-DU #2 of the mobile IAB node 300M.
  • the mobile IAB node 300M may be referred to as the "dual DU approach.”
  • the dual DU approach is performed when the UE 100 moves from one CU and DU to another CU and DU.
  • RACH-less handover In 3GPP, RACH-less handover (RACH-less HO) is specified (for example, 3GPP TS 36.300 V17.1.0 (2022-06)). RACH-less handover is a handover that skips a random access procedure. In RACH-less handover in the LTE system, for example, the following process is performed.
  • UE100 receives an RRC connection reconfiguration (RRCConnectionReconfiguration) message from the source cell.
  • the RRC connection reconfiguration message includes an information element (MobilityControlInfo) that includes parameters (such as a Timing Advance (TA) value and/or an UL grant) used when UE100 performs a RACH-less handover.
  • UE100 uses the parameters included in the RRC connection reconfiguration message to transmit an RRC connection reconfiguration complete (RRCConnectionReconfigurationComplete) message to the target cell without performing a random access (RACH) procedure.
  • RACH random access
  • the random access procedure is skipped, so the delay in the handover execution time can be improved compared to when the random access procedure is executed in the UE 100.
  • the UE 100 under the mobile IAB node 300M may perform a RACH-less handover.
  • the UE 100 changes the connection destination from the IAB-DU #1 (or the cell formed by the IAB-DU #1; i.e., the source cell) of the mobile IAB node 300M to the IAB-DU #2 (or the cell formed by the IAB-DU #2; i.e., the target cell) (see FIG. 10(A) and FIG. 10(B)). Therefore, the UE 100 performs a handover from the IAB-DU #1 to the IAB-DU #2.
  • the IAB-DU #1 and the IAB-DU #2 are logical DUs, and may be the same DU physically. That is, when two DUs (or two cells) are provided using the same antenna system, the physical distance between the UE 100 and the antenna system is the same, so the TA value can also be considered to be the same. Therefore, when the UE 100 performs a handover from the IAB-DU #1 to the IAB-DU #2, it is possible to avoid disconnection and the like by performing a RACH-less handover rather than performing a random access procedure for the IAB-DU #2, and it is possible to perform communication appropriately.
  • the UE 100 can complete the RACH-less handover by transmitting an RRC reconfiguration complete (RRCReconfigurationComplete) message.
  • RRC reconfiguration complete is used instead of the RRC connection reconfiguration complete (RRCConnectionReconfigurationComplete) message in the LTE system.
  • uplink resource information i.e., UL grant
  • DCI downlink control information
  • RACH-less handover is configured by the CU, since it is configured using an RRC reconfiguration message. That is, the UL grant is configured by the DU, and the RACH-less handover is configured by the CU. If the CU does not have information about the UL grant, it may not be able to properly configure the RACH-less handover for the UE 100. In this case, the UE 100 cannot transmit an RRC reconfiguration completion message and cannot properly perform the RACH-less handover.
  • the first embodiment aims to enable UE 100 to appropriately perform RACH-less handover.
  • the distributed unit (DU) transmits resource information regarding resources used in the user equipment (e.g., UE 100) during RACH-less handover to the central unit (CU).
  • the central unit transmits a handover command including the resource information to the user equipment.
  • resource information used by UE100 during RACH-less handover is transmitted from DU to CU, so that CU can appropriately configure RACH-less handover for UE100 using the resource information. Therefore, UE100 can appropriately execute RACH-less handover.
  • FIG. 11 is a diagram showing an example of the relationship between a CU, a DU, and a UE 100 according to the first embodiment.
  • a UE 100 moves from a source side DU (or a source cell formed by the source side DU) to a target side DU (or a target cell formed by the target side DU)
  • the UE 100 executes a handover (RACH-less handover in the first embodiment) to the target side DU of the movement destination.
  • CU The relationship between CU, DU, and UE100 can be classified into the following two types, for example:
  • the CU is included in the donor node 200
  • the DU is included in the mobile IAB node 300M. That is, the CU is the CU (IAB-donor-CU) of the donor node 200, and the DU is the IAB-DU of the mobile IAB node 300M.
  • Figures 12(A) and 12(B) show examples of relationships in such cases.
  • Figure 12(A) shows an example of inter-donor migration
  • Figure 12(B) shows an example of intra-donor migration.
  • the mobile IAB node 300M may be a fixed IAB node.
  • the CU and DU are included in gNB200. That is, the CU is a CU of gNB200, and the DU is a DU of gNB200.
  • Figures 13(A) and 13(B) show examples of the relationship in such a case.
  • Figure 13(A) shows an example of inter-gNB handover (Inter-gNB HO)
  • Figure 13(B) shows an example of intra-gNB handover (Intra-gNB HO).
  • the source cell and target cell may be provided from the same DU.
  • Such a handover is called intra-DU (Intra-DU HO).
  • the IAB-MT of the mobile IAB node 300M has UE functionality in the mobile IAB node. Therefore, the mobile IAB node 300M itself may perform a RACH-less handover to the donor node 200.
  • the UE 100 can be read as the mobile IAB node 300M and the gNB 200 as the donor node 200.
  • FIG. 14 is a diagram illustrating an example of an operation according to the first embodiment.
  • step S10 the CU decides to set up a RACH-less handover for the UE 100.
  • the CU of the target donor node 200-T decides to set up a RACH-less handover for the UE 100 under the mobile IAB node 300M because the mobile IAB node 300M is moving.
  • the CU of the source donor node 200-S may notify the CU of the target donor node 200-T by using an Xn message that a RACH-less handover can be set for the UE 100 under the mobile IAB node 300M because the mobile IAB node 300M is moving.
  • the CU may request the DU (the DU providing the target cell) to reserve resources (or UL resources) for RACH-less handover.
  • the CU may make the request by transmitting a resource reservation request message requesting the reservation of resources for RACH-less handover.
  • a resource reservation request message requesting the reservation of resources for RACH-less handover.
  • the resource reservation request message may be a message requesting the allocation of an UL grant for RACH-less handover.
  • the resource reservation request message may request the provision of resource information (or UL grant information) for RACH-less handover allocated by the DU.
  • the resource reservation request message may request the establishment of a UE context (UE Context Setup) and may include an identifier indicating that this is a RACH-less handover.
  • the resource reservation request message may include a setting value desired by the CU (or a setting value to be included in the RRC reconfiguration message).
  • the DU transmits UL grant information for RACH-less handover to the CU.
  • the UL grant information represents, for example, resource information related to resources used in the UE 100 during a RACH-less handover.
  • the DU may transmit the UL grant information by transmitting a resource information message including the UL grant information for RACH-less handover to the CU.
  • the target side DU IAB-DU #2 of the mobile IAB node 300M in the example of FIG. 10(A)
  • the UL grant information included in the resource information message may be UL resource setting information.
  • the information may be PUSCH (Physical Uplink Shared Channel) resource setting information.
  • the CU includes UL grant information for RACH-less handover in the handover command.
  • the handover command may be an RRC Reconfiguration message including an information element (e.g., reconfiguration with synchronization (reconfigurationWithSync)) used by the UE 100 to establish synchronization with the target cell during handover.
  • the UL grant information for RACH-less handover may be included in the reconfiguration with synchronization.
  • the CU of the target donor node 200-T includes the UL grant information in the handover command.
  • the CU transmits a handover command to the UE 100.
  • the CU of the target donor node 200-T transmits an Xn message including a handover command to the CU of the source donor node 200-S
  • the CU of the source donor node 200-S transmits the handover command to the UE 100.
  • the CU of the source donor node 200-S extracts the handover command from the Xn message and transmits an F1 message including the handover command to the source side DU of the mobile IAB node 300M (IAB-DU #1 of the mobile IAB node 300M in the example of FIG. 10(A)).
  • the source side DU source cell extracts the handover command from the F1 message and transmits the handover command to the UE 100.
  • step S15 UE100 extracts UL grant information and the like from the handover command, and transmits an RRC reconfiguration complete (RRCReconfigurationComplete) message to the target side DU (target cell) using the resources indicated by the UL grant information without performing a random access procedure.
  • RRC reconfiguration complete RRCReconfigurationComplete
  • UE100 executes a RACH-less handover using the resources allocated by the target side DU.
  • the above-described operation example according to the first embodiment has been described mainly in the case where the mobile IAB node 300M performs inter-donor migration, but is not limited thereto.
  • the above-described operation example is also applicable to the case where the mobile IAB node 300M performs intra-donor migration (FIG. 12(B)).
  • the CU of the donor node 200 may make a resource reservation request to the IAB-DU of the mobile IAB node 300M (step S11).
  • the IAB-DU of the mobile IAB node 300M transmits a UL grant for RACH-less handover to the CU of the donor node 200 (step S12).
  • the CU of the donor node 200 transmits a handover command including the UL grant to the UE 100 (step S14).
  • the above-described operation example can also be applied to inter-gNB handover ( Figure 13 (A)).
  • the source side DU can be read as the DU of the source side gNB 200-1
  • the target side DU can be read as the DU of the target side gNB 200-2.
  • the above-mentioned operation example can also be applied to intra-gNB handover ( Figure 13 (B)).
  • the source side DU should be read as the source side DU of gNB200
  • the target side DU should be read as the target side DU of gNB200.
  • the above-mentioned operation example can also be applied when the mobile IAB node 300M itself performs a RACH-less handover to the donor node 200.
  • the source side DU should be read as the DU of the source donor node 200-S
  • the target side DU should be read as the DU of the target donor node 200-T
  • the UE 100 should be read as the mobile IAB node 300M.
  • the CU of the target donor node 200-T sends a handover command to the CU of the source donor node 200-S using an Xn message
  • the CU of the source donor node 200-S sends a handover command to the mobile IAB node 300M.
  • the source side DU should be read as the source side DU of the donor node 200
  • the target side DU should be read as the target side DU of the donor node 200
  • the UE 100 should be read as the mobile IAB node 300M.
  • the operation example shown in FIG. 14 may also be applied to intra-DU handover (intra-DU HO).
  • the first embodiment is also applicable to a case where a conditional handover (CHO) is performed as a RACH-less handover.
  • the CU may request the target side DU to secure resources for the conditional RACH-less handover (step S11).
  • the request may be made by a resource securing request message as in the first embodiment.
  • the target side DU transmits UL grant information representing resources for the conditional RACH-less handover to the CU (step S12).
  • the UL grant information may be included in a resource information message.
  • the CU may include the UL grant information in the conditional reconfiguration and transmit an RRC reconfiguration message including a conditional additional reconfiguration to the UE 100 (step S14).
  • conditional handover is performed as a RACH-less handover.
  • a conditional handover performed as a RACH-less handover may be referred to as a conditional RACH-less handover (Conditional RACH-less HO).
  • conditional handover (CHO)
  • the UE 100 reports the measurement values of the radio conditions of the serving cell and/or the neighboring cell to the gNB 200, and the gNB 200 determines the handover to the neighboring cell based on this report and transmits a handover instruction to the UE 100. For this reason, in a case where the radio conditions of the serving cell suddenly deteriorate, a typical handover may result in communication being interrupted before the handover is performed.
  • a conditional handover when a preset trigger condition is satisfied, the UE 100 can autonomously execute a handover to a candidate cell that corresponds to the trigger condition. This solves problems such as communication interruption that occur in general handovers.
  • the conditional handover is configured by conditional reconfiguration.
  • the conditional reconfiguration is one of the information elements (IEs) included in the RRC reconfiguration message.
  • the conditional reconfiguration is configured, for example, by transmitting an RRC reconfiguration message from the CU of the donor node 200 to the IAB-MT of the IAB node 300 (or the UE 100).
  • the conditional reconfiguration includes candidate cells and execution conditions used in the conditional handover.
  • the execution conditions include one or more trigger conditions. When the trigger conditions are met, the IAB-MT of the IAB node 300 (or the UE 100) starts executing a handover to the candidate cell.
  • a resource (UL resource) is required to execute the RACH-less handover.
  • a resource (or radio resource) is required to transmit an RRC reconfiguration complete (RRCReconfigurationComplete) message to the target cell.
  • the UE 100 does not immediately access the target cell. Therefore, a source for transmitting the RRC reconfiguration completion message is reserved for a certain period of time.
  • maintaining the resource for a certain period of time or longer may not be desirable from the perspective of resource efficiency. This is because there are cases where it is better to use the resource for other communications rather than maintaining the resource for a certain period of time or longer.
  • the second embodiment aims to ensure efficient use of radio resources while securing resources for conditional RACH-less handover.
  • the central unit transmits to the distributed unit (DU) validity period information indicating the validity period of resources used in the user equipment (e.g., UE 100) during a conditional RACH-less handover, and the distributed unit transmits the validity period information to the central unit.
  • the central unit transmits a conditional reconfiguration including the validity period information to the user equipment.
  • UE 100 is notified of the validity period of the resources used in the conditional RACH-less handover, and when the validity period has elapsed, the resources are released and can be used for other communications. Therefore, in the cellular communication system 1, resources for the conditional RACH-less handover can be secured while making effective use of the resources.
  • the central device is the CU and the distributed devices are the DUs.
  • An example of the relationship between the CU, DU, and UE 100 is also the same as in the first embodiment.
  • FIG. 15 is a diagram showing an example of operation according to the second embodiment. The example of operation shown in FIG. 15 will be mainly explained using the example of inter-donor movement shown in FIG. 12(A) (or complete movement shown in FIG. 9(A) to FIG. 10(B)).
  • step S20 the CU decides to set up a conditional RACH-less handover for the UE 100.
  • the CU of the target donor node 200-T decides to set up a conditional RACH-less handover for the UE 100 under the mobile IAB node 300M.
  • the CU may request the DU to secure resources (or UL resources) for a conditional RACH-less handover.
  • the request may be made by a resource securing request message.
  • the CU of the target donor node 200-T has established an F1 connection with the target side DU (IAB-DU#2 of the mobile IAB node 300M in the example of FIG. 10(A))
  • it transmits a resource securing request message as an F1 message to the target side DU.
  • the resource securing request message may include validity period information indicating the validity period of the resources for the conditional RACH-less handover.
  • the validity period may be represented by a timer value.
  • the validity period may be determined by the CU.
  • the DU may transmit to the CU resource information indicating the resource for conditional RACH-less handover, together with validity period information indicating the validity period of the resource.
  • the transmission may be performed using a resource information message.
  • the resource information message includes the resource information and the validity period information.
  • the validity period may be determined by the DU and transmitted to the CU. That is, the validity period may be determined by the CU (step S21).
  • the validity period may be determined by the DU (step S22).
  • the target side DU (IAB-DU#2 of the mobile IAB node 300M in the example of FIG. 10(A)) transmits a resource information message including the validity period information as an F1 message to the CU of the target donor node 200-T.
  • the CU includes the validity period information in the conditional reconfiguration.
  • the validity period may be associated with each conditional reconfiguration (or with each entry in the configuration list).
  • the validity period may be commonly applied to all conditional reconfigurations.
  • the CU of the target donor node 200-T includes the validity period information in the conditional reconfiguration.
  • the CU transmits a conditional reconfiguration including the validity period information to the UE 100.
  • the conditional reconfiguration may be transmitted in an RRC reconfiguration message.
  • the CU of the target donor node 200-T transmits an RRC reconfiguration message including the conditional reconfiguration to the CU of the source donor node 200-S using an Xn message, and the CU of the source donor node 200-S transmits the RRC reconfiguration message to the UE 100.
  • the CU of the source donor node 200-S extracts the RRC reconfiguration message from the Xn message and transmits an F1 message including the RRC reconfiguration message to the source side DU of the mobile IAB node 300M (IAB-DU #1 of the mobile IAB node 300M in the example of FIG. 10(A)). Then, the source side DU extracts the RRC reconfiguration message from the F1 message and transmits the RRC reconfiguration message to the UE 100.
  • step S24 UE 100 receives the conditional reconfiguration. If the conditional reconfiguration includes validity period information, UE 100 starts counting with a timer. UE 100 may start counting with a timer when it receives the conditional reconfiguration.
  • step S25 the UE 100 determines whether the count value of the timer has reached the validity period (i.e., whether the timer has expired).
  • step S25 When the timer expires (Yes in step S25), UE 100 discards the conditional reconfiguration in step S26. That is, UE 100 discards the conditional reconfiguration because the validity period of the resources for the conditional RACH-less handover has elapsed. Then, UE 100 ends the series of processes in step S27.
  • step S28 when the trigger condition is satisfied (Yes in step S28) before the timer expires (No in step S25), UE100 transmits an RRC reconfiguration completion message to the target DU in step S29. That is, when the trigger condition indicated in the conditional reconfiguration is satisfied before the validity period elapses, UE100 executes a conditional RACH-less handover by transmitting an RRC reconfiguration completion message to the target DU.
  • the trigger condition is not satisfied (No in step S28) before the timer expires (No in step S25)
  • UE100 proceeds to step S25 and repeats the above-mentioned processing (steps S25 to S28).
  • the operation example according to the first embodiment has been described mainly in the case where the mobile IAB node 300M performs inter-donor migration, but is not limited thereto.
  • the above-described operation example can also be applied to the case where the mobile IAB node 300M performs intra-donor migration (FIG. 12(B)). In this case, it can be implemented by replacing the target side DU and the source side DU in the same manner as in the first embodiment.
  • the operation example according to the first embodiment can also be applied to inter-gNB handover (FIG. 13(A)). Furthermore, the above-described operation example can also be applied to intra-gNB handover (FIG. 13(B)). Furthermore, the above-described operation example can also be applied to a case where the mobile IAB node 300M performs a RACH-less handover to its own donor node 200. In either case, the CU, target side DU, source side DU, and/or UE can be read in the same way as in the first embodiment.
  • the validity period described in the second embodiment may be a value determined in advance by specifications (or a value determined by hard coding). In this case, the validity period is not transmitted from the CU to the UE 100.
  • the conditional RACH-less handover is set (step S24)
  • the UE 100 starts counting the timer and determines whether the timer has expired based on whether the count value has reached a predetermined value.
  • a conditional PS cell change is a procedure in which, for example, when an execution condition is met, UE 100 changes the PS cell that is the primary cell of the secondary cell group.
  • the conditional PS cell change is set by CPC configuration.
  • the CPC configuration includes the execution condition and information on the candidate PS cells.
  • the CU may set RACH-less handover in the conditional PS cell change to UE 100 by including validity period information in the CPC configuration and transmitting it to UE 100 (step S24).
  • UE 100 discards the CPC configuration, and if the execution condition is met before the timer expires, executes the PS cell change by RACH-less handover.
  • conditional PS cell addition is a procedure for adding a PS cell in UE 100 when, for example, the PS cell addition conditions are met.
  • the conditional PS cell addition is configured by CPA configuration.
  • the CPA configuration includes execution conditions and information on candidate PS cells.
  • the CU may configure RACH-less handover in the conditional PS cell addition in UE 100 by including validity period information in the CPA configuration and transmitting it to UE 100 (step S23).
  • UE 100 discards the CPA configuration, and when the execution conditions are met before the timer expires, executes the PS cell addition by RACH-less handover.
  • the validity period may be used by the CU.
  • the validity period may be notified by the Xn message from the CU of the target donor node 200-T to the CU of the source donor node 200-S.
  • the CU of the source donor node 200-S sets the conditional RACH-less handover to the UE 100 (or when the setting is received from the CU of the target donor node 200-T)
  • the CU of the source donor node 200-S starts a timer in which the validity period is set.
  • the timer expires (for example, when the count value by the timer reaches the validity period)
  • the CU of the source donor node 200-S may remove the setting of the RACH-less handover from the UE 100.
  • the base station is an NR base station (gNB)
  • the base station may be an LTE base station (eNB) or a 6G base station.
  • the base station may also be a relay node such as an IAB (Integrated Access and Backhaul) node.
  • the base station may be a DU of an IAB node.
  • the UE 100 may also be an MT (Mobile Termination) of an IAB node.
  • network node primarily refers to a base station, but may also refer to a core network device or part of a base station (CU, DU, or RU).
  • a program may be provided that causes a computer to execute each process performed by UE100 or gNB200.
  • the program may be recorded on a computer-readable medium.
  • 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, and may be, for example, a recording medium such as a CD-ROM or DVD-ROM.
  • circuits that execute each process performed by UE100 or gNB200 may be integrated, and at least a portion of UE100 or gNB200 may be configured as a semiconductor integrated circuit (chip set, SoC: System on a chip).
  • the terms “based on” and “depending on/in response to” do not mean “based only on” or “only in response to” unless otherwise specified.
  • the term “based on” means both “based only on” and “based at least in part on”.
  • the term “in response to” means both “only in response to” and “at least in part on”.
  • the terms “include”, “comprise”, and variations thereof do not mean including only the recited items, but may include only the recited items or may include additional items in addition to the recited items.
  • the term “or” as used in this disclosure is not intended to mean an exclusive or.
  • a communication control method for use in a cellular communication system comprising: a distributed unit (DU) sending resource information to a central unit (CU) regarding resources used in a user equipment during a RACH-less handover; the central device transmitting a handover command including the resource information to the user equipment.
  • DU distributed unit
  • CU central unit
  • the method further includes a step of the central device transmitting a resource reservation request message to the distributed device to request reservation of the resource,
  • the step of transmitting the resource information includes a step of transmitting a resource information message including the resource information to the central device in response to receiving the resource reservation request message by the distributed device.
  • a communication control method for use in a cellular communication system comprising: A central unit (CU) transmits validity period information indicating a validity period of a resource used in a user equipment during a conditional RACH-less handover to a distributed unit (DU), and the distributed unit transmits the validity period information to the central unit; The central device transmits a conditional reconfiguration including the validity period information to the user device.
  • CU central unit
  • DU distributed unit
  • the WID for mobile IABs was revised in RAN#97e with the following objectives:
  • the detailed objectives of WI are as follows: Define mobility/topology adaptation procedures to achieve IAB node mobility, including inter-donor mobility (full mobility) of the entire mobile IAB node.
  • a mobile IAB node can connect to a fixed (intermediate) IAB node. Optimizations specific to the scenario where a mobile IAB node connects to a stationary (intermediate) IAB node or directly to an IAB donor DU are not prioritized.
  • - Mobility of dual-attached IAB nodes is deprioritized. Enhances mobility of IAB nodes and their UEs, including aspects related to group mobility.
  • RACH-less handover of Rel-18 UE RAN2#119e reached the following agreement: R2 assumes that for on-board RRC CONNECTED UEs handed over with a mobile IAB node, a RACH-less procedure may be considered (also dependent on the assumption of UL synchronization).
  • RACH-less handover is configured as follows using the applicable Timing Advance (TA) and Uplink Grant (UL) information in MobilityControlInfo:
  • TA Timing Advance
  • UL Uplink Grant
  • the UE is assumed to apply the latest TA value to access the target cell. In other words, the "physical" distance from the UE must be the same. Therefore, there is no need for the UE to set an explicit TA value.
  • RACH-less handover is used in other scenarios, for example, for a mobile IAB-MT handover, a generic approach like the LTE configuration is required.
  • Proposal 1 RAN2 should discuss whether the UE should implicitly apply the latest TA value or explicitly configure the corresponding TA value for RACH-less handover of the UE.
  • the UE needs to send RRCReconfigurationComplete within the UL resources provided by the target cell, so UL grant information needs to be set in the UE.
  • Proposal 2 RAN2 should agree for RACH-less handover of the UE that UL grant information is set by the target IAB donor CU.
  • Proposal 3 RAN2 should agree that RACH-less handover is configured with a handover command (reconfiguration with synchronization).
  • RACH-less handover can also be applied to conditional handover.
  • RAN2#119e agreed that it would be useful to support conditional RACH-less handover since "R2 assumes that CHO or delayed RRC configuration can be the baseline for group mobility.”
  • Proposal 4 RAN2 should discuss whether RACH-less handover can also be configured as a conditional handover (conditional reconfiguration).
  • WID makes it clear that legacy UEs should be served by mobile IAB nodes.
  • the following principles should be respected: - Mobile IAB nodes should be able to serve legacy UEs.
  • - Solutions that provide mobile IAB optimization may involve enhancements to Rel-18 UE.
  • CHO Conditional Handover
  • RAN2 agreed on “delayed RRC config" as one of the candidates. However, it is not clear whether this "delayedRRCconfig” is intended to be the same as the deferred/conditional delivery of RRC reconfiguration messages defined in Rel-17, i.e. solution 1. If it is deferred/conditional delivery, it will work for legacy UEs including Rel-15 UEs. If not, it may not work depending on the intended solution(s). Therefore, RAN2 needs to clarify what is intended by "delayed RRC config".
  • Proposal 5 RAN2 should clarify whether the deferred/conditional delivery of RRC messages specified in Rel-17 is the same as the "delayed RRC config" agreed upon at the previous meeting.
  • RAN2#119e supported the following arguments: P3: Regarding the "dual-DU-way" with full transition, RAN2 can discuss whether the legacy UE should consider the two logical cells/DUs as separate physical cells or as the same physical cell, and in which case what procedures the legacy UE needs to perform.
  • CHO is used for Rel-16 UE, i.e., there is only A3/A5 based trigger, if these PCIs are the same, the UE may perceive the RSRP from the source cell as the same as the RSRP from the target cell, and therefore the condition cannot be met.
  • the PCI of the target cell needs to be different from the PCI of the source cell.
  • Proposal 6 RAN2 should assume that the two logical cells/DUs have different PCIs.
  • RAN2 discusses a scenario in which it enhances cell (re)selection with a mobile IAB node, for example based on the mobile IAB node's broadcast parameters.
  • Scenario A A mobile IAB node is moving with a camped UE.
  • Sub-case A1 The UE (such as a train) needs to camp on a mobile IAB node.
  • Sub-case A2 Surrounding UEs (e.g. outside the train) must not camp on the moving IAB node.
  • Scenario B A mobile IAB node is parked with a camped UE.
  • Subcase B1 The UE (e.g., still on the train) remains on the mobile IAB node.
  • Sub-case B2 The UE (eg, gets off a train) needs to reselect a fixed cell (eg, a macrocell).
  • Subcase B3 A surrounding UE (e.g., riding a train) needs to reselect a mobile IAB node.
  • Sub-case B4 Surrounding UEs (eg still at the station) should stay in fixed cells.
  • Subcases A2, B3, and B4 are desirable behaviors for surrounding UEs.
  • WID specifies that there are no optimizations targeted at surrounding UEs.
  • subcase B3 the UE becomes subcase B1 or B2 after getting on the train, but the initial state of the UE remains that of a surrounding UE. Therefore, these subcases are not of interest.
  • the UE moves together with the mobile IAB node. Therefore, the RSRP and RSRQ from the mobile IAB node are always stable and sufficiently good. For example, the mobile IAB node broadcasts its frequency priority as "7" or broadcasts its cell as an HSDN cell.
  • a train has multiple cars and a mobile IAB node is deployed in each car. Even if the UE moves between cars, one of the cells of the mobile IAB node is always more stable than the external macro cell from the perspective of the UE in the train. Furthermore, as a typical case, we assume that the mobile IAB node cells are operating on the same frequency. In this case, the existing intra-frequency cell reselection, i.e., R criterion, works well.
  • cell reselection based on existing radio conditions works well and does not need to be augmented with, for example, some broadcast information.
  • a UE moving with an IAB node can remain on the IAB node based on existing radio condition based cell reselection and appropriate frequency priority.
  • subcases B1 and B2 there is no way for the AS to know whether the user will stay on the train or leave the train. In this case, even if the mobile IAB node broadcasts some information, the UE cannot decide which cell (mobile IAB node or fixed macro cell) to reselect to in the end. Therefore, which cell the UE should reselect to ultimately depends on the radio conditions and frequency priorities.
  • the existing cell reselection mechanism i.e. based on radio conditions and frequency priority, still works well. Therefore, no enhancements are needed for the UE to perform cell reselection.
  • HSDN is useful for subcase A1 because it can be supported by mobile IAB nodes without specification changes.
  • Proposal 7 RAN2 should agree that no enhancements are required for a UE to perform cell reselection with a mobile IAB node.
  • Mobile IAB Node Indication RAN2#119e supported the following points: P2: It can be discussed whether the mobile IAB-MT needs to send a mobile IAB indication (capability or mobility) to the IAB donor CU.
  • IAB Node Indication is sent via Msg5, which is intended to be used by the provider to select an AMF that supports IAB. Therefore, depending on whether the provider needs to select an AMF that supports mobile IAB, it is one of the points as to whether to send mobile IAB Node Indication via Msg5, which is up to RAN3.
  • the donor CU can obtain real-time mobility status. Such mobility status information is considered useful for predictive mobility control.
  • the presenter clarified that the mobile IAB node indication is necessary for the donor to configure the mobile IAB node with the appropriate measurement settings.
  • the mobile IAB node indication should be sent by the IAB-MT.
  • Msg5 Msg5 or Capability signaling, and this is up to RAN3.
  • Proposal 8 RAN2 should agree that the mobile IAB node indication is sent in an RRC message. It is up to RAN3 whether the RRC message is Msg5 or Capability signaling.
  • mobile IAB nodes only provide services to UEs.
  • a mobile IAB node does not have any descendant IAB nodes and serves only UEs.
  • RAN2#119e has agreed to the following: - Not broadcasting the IAB support indication is sufficient to prevent other IAB nodes from accessing the mobile IAB (without further impact on the specification).
  • Proposal 9 RAN2 should agree to include in the Stage-2 specification that in this release, when an IAB node acts as a mobile IAB node, it shall not set the IAB support IE in the SIB.
  • the WID for mobile IABs was revised in RAN#97e with the following objectives:
  • the detailed objectives of WI are as follows: Define mobility/topology adaptation procedures to achieve IAB node mobility, including inter-donor mobility (full mobility) of the entire mobile IAB node.
  • a mobile IAB node can connect to a fixed (intermediate) IAB node. Optimizations specific to the scenario where a mobile IAB node connects to a stationary (intermediate) IAB node or directly to an IAB donor-DU are not prioritized.
  • - Mobility of dual-attached IAB nodes is deprioritized. Enhances mobility of IAB nodes and their UEs, including aspects related to group mobility. There is no optimization for targeting surrounding UEs.
  • Solutions should avoid touching on topics already discussed in Rel-17 or topics excluded from Rel-17, with the exception of IAB node mobility specific enhancements. Mitigation of interference due to IAB node mobility, including avoidance of potential reference and control signal collisions (PCI, RACH, etc.). The following principles should be respected: - Mobile IAB nodes should be able to serve legacy UEs. - Solutions that provide mobile IAB optimization may involve enhancements to Rel-18 UE.
  • One of the objectives is to mitigate interference due to IAB node mobility. This appendix discusses potential issues regarding PCI collisions and RACH configuration collisions.
  • Dynamic PCI change mechanism RAN2#119e supported the following arguments: P4: RAN2 may discuss whether there are any PCI partitioning issues that need/can be addressed (for use in application scenarios) if found within the R2 scope. From the R2 perspective, it may discuss the need and feasibility of a dynamic PCI change mechanism. Also, discuss whether enhancements to current UE/MT reporting would be useful/necessary to improve PCI collision detection.
  • Scenario 1 The PCI of a mobile IAB node collides with an adjacent cell.
  • Scenario 2 The PCIs of two moving IAB nodes that move to the same target donor collide.
  • PCI partitioning if PCI partitioning is used, the PCI space of the mobile IAB nodes may need to be further separated or a global PCI (i.e., not reusable in the PLMN) may need to be assigned to each IAB node. Given the limited number of PCIs, PCI partitioning is not a practical solution.
  • scenario 2 requires a dynamic PCI change mechanism.
  • Proposal 1 RAN2 should agree that a dynamic PCI change mechanism is necessary, especially in the case of PCI collision between two mobile IAB nodes.
  • IAB-MT measurements There are three possible approaches to avoid PCI collisions: IAB-MT measurements, UE reporting, and network coordination.
  • the donor In UE reporting, if the UE detects and reports the same PCI from different cells, the donor is expected to request the mobile IAB node to change the PCI. However, it is questionable whether the UE can determine whether different cells use the same PCI. Similarly, by the time the UE detects the same PCI, a PCI collision may already have occurred.
  • the source donor queries the target donor whether the PCI used by the migrating mobile IAB node is acceptable.
  • the target donor may ask the same to nearby gNBs, for example, whether another mobile IAB node in the vicinity of the target donor uses the same PCI, to avoid future PCI collisions.
  • This approach can avoid PCI collisions in advance. Therefore, RAN2 should consider that dynamic PCI changes only occur during the migration of a mobile IAB node, and there is no enhancement from the perspective of RAN2. It is up to RAN3 how RAN3 avoids and changes PCI collisions during the migration of a mobile IAB node.
  • Proposal 2 RAN2 should assume that dynamic PCI changes occur only during IAB node transition procedures and that PCI conflicts are resolved by network adjustments. It is up to RAN3, not RAN2, how to avoid PCI conflicts.
  • RACH setup collision RAN2#119e supported the following points: P5: RAN2 can discuss whether there is a RACH setup collision problem between the mobile IAB and the fixed network from RAN2's perspective and/or whether RAN2 should ask RAN1 to consider RAN1 related aspects.
  • a UE may send a PRACH to cell A, but it may also be received by cell B, and the UE may receive an RAR from cell B. If RAN2 identifies these possible issues, it should request a detailed analysis from RAN1.
  • RAN1 is a suitable group for analyzing RACH configuration collision issues.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

一態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、分散装置（ＤＵ）が、ＲＡＣＨレスハンドオーバの際にユーザ装置において用いられるリソースに関するリソース情報を中央装置（ＣＵ）へ送信するステップと、中央装置が、リソース情報を含むハンドオーバコマンドをユーザ装置へ送信するステップと、を有する。

Description

通信制御方法
　本開示は、セルラ通信システムに用いる通信制御方法に関する。
　セルラ通信システムの標準化プロジェクトである３ＧＰＰ（Third Generation Partnership Project）において、ＩＡＢ（Integrated Access and Backhaul）ノードと呼ばれる新たな中継ノードの導入が検討されている（例えば、非特許文献１参照）。１又は複数の中継ノードが、基地局とユーザ装置との間の通信に介在し、この通信に対する中継を行う。
３ＧＰＰ　ＴＳ　３８．３００　Ｖ１７．１．０（２０２２－０６）
　第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、分散装置（ＤＵ）が、ＲＡＣＨレスハンドオーバの際にユーザ装置において用いられるリソースに関するリソース情報を中央装置（ＣＵ）へ送信するステップと、中央装置が、リソース情報を含むハンドオーバコマンドをユーザ装置へ送信するステップと、を有する。
　第２の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中央装置（ＣＵ）が、条件付きＲＡＣＨレスハンドオーバの際にユーザ装置において用いられるリソースの有効期間を表す有効期間情報を分散装置（ＤＵ）へ送信する、及び、分散装置が、有効期間情報を中央装置へ送信することのいずれかを行うステップを有する。また、前記通信制御方法は、中央装置が、有効期間情報を含む条件付き再設定をユーザ装置へ送信するステップを有する。
図１は、一実施形態に係るセルラ通信システムの構成例を示す図である。 図２は、ＩＡＢノードと親ノード（Ｐａｒｅｎｔ　ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ　ｎｏｄｅｓ）との関係を示す図である。 図３は、一実施形態に係るｇＮＢ（基地局）の構成例を示す図である。 図４は、一実施形態に係るＩＡＢノード（中継ノード）の構成例を示す図である。 図５は、一実施形態に係るＵＥ（ユーザ装置）の構成例を示す図である。 図６は、ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックの例を示す図である。 図７は、Ｆ１－Ｕプロトコルに関するプロトコルスタックの例を示す図である。 図８は、Ｆ１－Ｃプロトコルに関するプロトコルスタックの例を示す図である。 図９（Ａ）と図９（Ｂ）は、第１実施形態に係る完全移動の例を表す図である。 図１０（Ａ）と図１０（Ｂ）は、第１実施形態に係る完全移動の例を表す図である。 図１１は、第１実施形態に係るＣＵとＤＵとＵＥとの関係例を表す図である。 図１２（Ａ）と図１２（Ｂ）は、第１実施形態に係るＣＵとＤＵとＵＥとの関係例を表す図である。 図１３（Ａ）と図１３（Ｂ）は、第１実施形態に係るＣＵとＤＵとＵＥとの関係例を表す図である。 図１４は、第１実施形態に係る動作例を表す図である。 図１５は、第２実施形態に係る動作例を表す図である。 図１６は、ＴＡ（Ｔｉｍｉｎｇ　Ａｄｖａｎｃｅ）値及び／又はＵＬグラントを用いたＲＡＣＨレスハンドオーバを示す図である。 図１７は、ＵＥのセル再選択のシナリオとサブケースを示す図である。 図１８は、ＰＣＩ衝突のためのシナリオを示す図である。
　図面を参照しながら、実施形態に係るセルラ通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
［第１実施形態］
　（セルラ通信システムの構成）
　一実施形態に係るセルラ通信システムの構成例について説明する。一実施形態に係るセルラ通信システム１は３ＧＰＰの５Ｇシステムである。具体的には、セルラ通信システム１における無線アクセス方式は、５Ｇの無線アクセス方式であるＮＲ（New Radio）である。但し、セルラ通信システム１には、ＬＴＥ（Long Term Evolution）が少なくとも部分的に適用されてもよい。また、セルラ通信システム１は、６Ｇなど、将来のセルラ通信システムも適用されてよい。
　図１は、一実施形態に係るセルラ通信システム１の構成例を示す図である。
　図１に示すように、セルラ通信システム１は、５Ｇコアネットワーク（５ＧＣ）１０と、ユーザ装置（ＵＥ：User Equipment）１００、基地局装置（以下、「基地局」と称する場合がある。）２００－１，２００－２、及びＩＡＢノード３００－１，３００－２を有する。基地局２００は、ｇＮＢと呼ばれる場合がある。
　以下において、基地局２００がＮＲ基地局である一例について主として説明するが、基地局２００がＬＴＥ基地局（すなわち、ｅＮＢ）であってもよい。
　なお、以下において、基地局２００－１，２００－２をｇＮＢ２００（又は基地局２００）、ＩＡＢノード３００－１，３００－２をＩＡＢノード３００とそれぞれ称する場合がある。
　５ＧＣ１０は、ＡＭＦ（Access and Mobility Management Function）１１及びＵＰＦ（User Plane Function）１２を有する。ＡＭＦ１１は、ＵＥ１００に対する各種モビリティ制御等を行う装置である。ＡＭＦ１１は、ＮＡＳ（Non-Access Stratum）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００が在圏するエリアの情報を管理する。ＵＰＦ１２は、ユーザデータの転送制御等を行う装置である。
　各ｇＮＢ２００は、固定の無線通信ノードであって、１又は複数のセルを管理する。セルは、無線通信エリアの最小単位を示す用語として用いられる。セルは、ＵＥ１００との無線通信を行う機能又はリソースを示す用語として用いられることがある。１つのセルは１つのキャリア周波数に属する。以下では、セルと基地局とを区別しないで用いる場合がある。
　各ｇＮＢ２００は、ＮＧインターフェイスと呼ばれるインターフェイスを介して５ＧＣ１０と相互に接続される。図１において、５ＧＣ１０に接続された２つのｇＮＢ２００－１及びｇＮＢ２００－２を例示している。
　各ｇＮＢ２００は、集約ユニット（ＣＵ：Central Unit）と分散ユニット（ＤＵ：Distributed Unit）とに分割されていてもよい。ＣＵ及びＤＵは、Ｆ１インターフェイスと呼ばれるインターフェイスを介して相互に接続される。Ｆ１プロトコルは、ＣＵとＤＵとの間の通信プロトコルであって、制御プレーンのプロトコルであるＦ１－ＣプロトコルとユーザプレーンのプロトコルであるＦ１－Ｕプロトコルとがある。
　セルラ通信システム１は、バックホールにＮＲを用いてＮＲアクセスの無線中継を可能とするＩＡＢをサポートする。ドナーｇＮＢ２００－１（又はドナーノード。以下、「ドナーノード」と称する場合がある。）は、ネットワーク側のＮＲバックホールの終端ノードであり、ＩＡＢをサポートする追加機能を備えたドナー基地局である。バックホールは、複数のホップ（すなわち、複数のＩＡＢノード３００）を介するマルチホップが可能である。
　図１において、ＩＡＢノード３００－１がドナーノード２００－１と無線で接続し、ＩＡＢノード３００－２がＩＡＢノード３００－１と無線で接続し、Ｆ１プロトコルが２つのバックホールホップで伝送される一例を示している。
　ＵＥ１００は、セルとの無線通信を行う移動可能な無線通信装置である。ＵＥ１００は、ｇＮＢ２００又はＩＡＢノード３００との無線通信を行う装置であればどのような装置であってもよい。例えば、ＵＥ１００は、携帯電話端末及び／又はタブレット端末、ノートＰＣ、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置、飛行体若しくは飛行体に設けられる装置である。ＵＥ１００は、アクセスリンクを介してＩＡＢノード３００又はｇＮＢ２００に無線で接続する。図１において、ＵＥ１００がＩＡＢノード３００－２と無線で接続される一例を示している。ＵＥ１００は、ＩＡＢノード３００－２及びＩＡＢノード３００－１を介してドナーノード２００－１と間接的に通信する。
　図２は、ＩＡＢノード３００と親ノード（Ｐａｒｅｎｔ　ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ　ｎｏｄｅｓ）との関係例を示す図である。
　図２に示すように、各ＩＡＢノード３００は、基地局機能部に相当するＩＡＢ－ＤＵとユーザ装置機能部に相当するＩＡＢ－ＭＴ（Mobile Termination）とを有する。
　ＩＡＢ－ＭＴのＮＲ　Ｕｕ無線インターフェイス上の隣接ノード（すなわち、上位ノード）は、親ノードと呼ばれる。親ノードは、親ＩＡＢノード又はドナーノード２００のＤＵである。ＩＡＢ－ＭＴと親ノードとの間の無線リンクは、バックホールリンク（ＢＨリンク）と呼ばれる。図２において、ＩＡＢノード３００の親ノードがＩＡＢノード３００－Ｐ１及び３００－Ｐ２である一例を示している。なお、親ノードへ向かう方向は、アップストリーム（ｕｐｓｔｒｅａｍ）と呼ばれる。ＵＥ１００から見て、ＵＥ１００の上位ノードは親ノードに該当し得る。
　ＩＡＢ－ＤＵのＮＲアクセスインターフェイス上の隣接ノード（すなわち、下位ノード）は、子ノードと呼ばれる。ＩＡＢ－ＤＵは、ｇＮＢ２００と同様に、セルを管理する。ＩＡＢ－ＤＵは、ＵＥ１００及び下位のＩＡＢノードへのＮＲ　Ｕｕ無線インターフェイスを終端する。ＩＡＢ－ＤＵは、ドナーノード２００－１のＣＵへのＦ１プロトコルをサポートする。図２において、ＩＡＢノード３００の子ノードがＩＡＢノード３００－Ｃ１～３００－Ｃ３である一例を示しているが、ＩＡＢノード３００の子ノードにＵＥ１００が含まれてもよい。なお、子ノードへ向かう方向は、ダウンストリーム（ｄｏｗｎｓｔｒｅａｍ）と呼ばれる。
　また、１つ又は複数のホップを介して、ドナーノード２００に接続されている全てのＩＡＢノード３００は、ドナーノード２００をルートとする有向非巡回グラフ（ＤＡＧ：Directed Acyclic Graph）トポロジ（以下、「トポロジ」と称する場合がある。）を形成する。このトポロジにおいて、図２に示すように、ＩＡＢ－ＤＵのインターフェイス上の隣り合うノードが子ノード、ＩＡＢ－ＭＴのインターフェイス上の隣り合うノードが親ノードとなる。ドナーノード２００は、例えば、ＩＡＢトポロジのリソース、トポロジ、ルート管理などを集中的に行う。ドナーノード２００は、バックホールリンクとアクセスリンクのネットワークを介して、ＵＥ１００に対して、ネットワークアクセスを提供するｇＮＢである。
　（基地局の構成）
　次に、実施形態に係る基地局であるｇＮＢ２００の構成について説明する。図３は、ｇＮＢ２００の構成例を示す図である。図３に示すように、ｇＮＢ２００は、無線通信部２１０と、ネットワーク通信部２２０と、制御部２３０とを有する。
　無線通信部２１０は、ＵＥ１００との無線通信及びＩＡＢノード３００との無線通信を行う。無線通信部２１０は、受信部２１１及び送信部２１２を有する。受信部２１１は、制御部２３０の制御下で各種の受信を行う。受信部２１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部２３０に出力する。送信部２１２は、制御部２３０の制御下で各種の送信を行う。送信部２１２はアンテナを含み、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。
　ネットワーク通信部２２０は、５ＧＣ１０との有線通信（又は無線通信）及び隣接する他のｇＮＢ２００との有線通信（又は無線通信）を行う。ネットワーク通信部２２０は、受信部２２１及び送信部２２２を有する。受信部２２１は、制御部２３０の制御下で各種の受信を行う。受信部２２１は、外部から信号を受信して受信信号を制御部２３０に出力する。送信部２２２は、制御部２３０の制御下で各種の送信を行う。送信部２２２は、制御部２３０が出力する送信信号を外部に送信する。
　制御部２３０は、ｇＮＢ２００における各種の制御を行う。制御部２３０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサとＣＰＵとを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。なお、制御部２３０は、以下に示す各実施形態において、ｇＮＢ２００における各処理又は各動作を行ってもよい。
　（中継ノードの構成）
　次に、実施形態に係る中継ノード（又は中継ノード装置。以下、「中継ノード」と称する場合がある。）であるＩＡＢノード３００の構成について説明する。図４は、ＩＡＢノード３００の構成例を示す図である。図４に示すように、ＩＡＢノード３００は、無線通信部３１０と、制御部３２０とを有する。ＩＡＢノード３００は、無線通信部３１０を複数有していてもよい。
　無線通信部３１０は、ｇＮＢ２００との無線通信（ＢＨリンク）及びＵＥ１００との無線通信（アクセスリンク）を行う。ＢＨリンク通信用の無線通信部３１０とアクセスリンク通信用の無線通信部３１０とが別々に設けられていてもよい。
　無線通信部３１０は、受信部３１１及び送信部３１２を有する。受信部３１１は、制御部３２０の制御下で各種の受信を行う。受信部３１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部３２０に出力する。送信部３１２は、制御部３２０の制御下で各種の送信を行う。送信部３１２はアンテナを含み、制御部３２０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。
　制御部３２０は、ＩＡＢノード３００における各種の制御を行う。制御部３２０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。なお、制御部３２０は、以下に示す各実施形態において、ＩＡＢノード３００における各処理又は各動作を行ってもよい。
　（ユーザ装置の構成）
　次に、実施形態に係るユーザ装置であるＵＥ１００の構成について説明する。図５は、ＵＥ１００の構成例を示す図である。図５に示すように、ＵＥ１００は、無線通信部１１０と、制御部１２０とを有する。
　無線通信部１１０は、アクセスリンクにおける無線通信、すなわち、ｇＮＢ２００との無線通信及びＩＡＢノード３００との無線通信を行う。また、無線通信部１１０は、サイドリンクにおける無線通信、すなわち、他のＵＥ１００との無線通信を行ってもよい。無線通信部１１０は、受信部１１１及び送信部１１２を有する。受信部１１１は、制御部１２０の制御下で各種の受信を行う。受信部１１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部１２０に出力する。送信部１１２は、制御部１２０の制御下で各種の送信を行う。送信部１１２はアンテナを含み、制御部１２０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。
　制御部１２０は、ＵＥ１００における各種の制御を行う。制御部１２０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。なお、制御部１２０は、以下に示す各実施形態において、ＵＥ１００における各処理を行うようにしてもよい。
　（プロトコルスタックの構成）
　次に、実施形態に係るプロトコルスタックの構成について説明する。図６は、ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックの例を示す図である。
　図６に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Medium Access Control）レイヤと、ＲＬＣ（Radio Link Control）レイヤと、ＰＤＣＰ（Packet Data Convergence Protocol）レイヤと、ＲＲＣ（Radio Resource Control）レイヤと、ＮＡＳ（Non-Access Stratum）レイヤとを有する。
　ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＰＨＹレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。
　ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ：Ｈｙｂｒｉｄ　Ａｕｔｏｍａｔｉｃ　Ｒｅｐｅａｔ　ｒｅＱｕｅｓｔ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＭＡＣレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ＩＡＢ－ＤＵのＭＡＣレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ：Ｍｏｄｕｌａｔｉｏｎ　ａｎｄ　Ｃｏｄｉｎｇ　Ｓｃｈｅｍｅ））及び割当リソースブロックを決定する。
　ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＲＬＣレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
　ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＰＤＣＰレイヤとドナーノード２００のＰＤＣＰレイヤとの間では、無線ベアラを介してデータ及び制御情報が伝送される。
　ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＲＲＣレイヤとドナーノード２００のＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ドナーノード２００とのＲＲＣ接続がある場合、ＩＡＢ－ＭＴはＲＲＣコネクティッド状態である。ドナーノード２００とのＲＲＣ接続がない場合、ＩＡＢ－ＭＴはＲＲＣアイドル状態である。
　ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＮＡＳレイヤとＡＭＦ１１との間では、ＮＡＳシグナリングが伝送される。
　図７は、Ｆ１－Ｕプロトコルに関するプロトコルスタックを示す図である。図８は、Ｆ１－Ｃプロトコルに関するプロトコルスタックを示す図である。ここでは、ドナーノード２００がＣＵ及びＤＵに分割されている一例を示す。
　図７に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴ、ＩＡＢノード３００－１のＩＡＢ－ＤＵ、ＩＡＢノード３００－１のＩＡＢ－ＭＴ、及びドナーノード２００のＤＵの各々は、ＲＬＣレイヤの上位レイヤとしてＢＡＰ（Backhaul Adaptation Protocol）レイヤを有する。ＢＡＰレイヤは、ルーティング処理及びベアラマッピング・デマッピング処理を行うレイヤである。バックホールでは、ＩＰレイヤがＢＡＰレイヤを介して伝送されることにより、複数のホップでのルーティングが可能になる。
　各バックホールリンクにおいて、ＢＡＰレイヤのＰＤＵ（Protocol Data Unit）は、バックホールＲＬＣチャネル（ＢＨ　ＮＲ　ＲＬＣチャネル）によって伝送される。各ＢＨリンクで複数のバックホールＲＬＣチャネルを構成することにより、トラフィックの優先順位付け及びＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）制御が可能である。ＢＡＰ　ＰＤＵとバックホールＲＬＣチャネルとの対応付けは、各ＩＡＢノード３００のＢＡＰレイヤ及びドナーノード２００のＢＡＰレイヤによって実行される。
　図８に示すように、Ｆ１－Ｃプロトコルのプロトコルスタックは、図７に示すＧＴＰ－Ｕレイヤ及びＵＤＰレイヤに代えて、Ｆ１ＡＰレイヤ及びＳＣＴＰレイヤを有する。
　なお、以下においては、ＩＡＢのＩＡＢ－ＤＵとＩＡＢ－ＭＴで行われる処理又は動作について、単に「ＩＡＢ」の処理又は動作として説明する場合がある。例えば、ＩＡＢノード３００－１のＩＡＢ－ＤＵが、ＩＡＢノード３００－２のＩＡＢ－ＭＴへＢＡＰレイヤのメッセージを送信することを、ＩＡＢノード３００－１がＩＡＢノード３００－２へ、当該メッセージを送信するものとして説明する。また、ドナーノード２００のＤＵ又はＣＵの処理又は動作についても、単に「ドナーノード」の処理又は動作として説明する場合がある。
　また、アップストリーム方向とアップリンク（ＵＬ）方向とを区別しないで用いる場合がある。更に、ダウンストリーム方向とダウンリンク（ＤＬ）方向とを区別しないで用いる場合がある。
　（移動ＩＡＢノード）
　現在、３ＧＰＰでは、移動ＩＡＢノード（ｍｏｂｉｌｅ　ＩＡＢ　ｎｏｄｅ）の導入に向けた検討が開始されている。移動ＩＡＢノードとは、例えば、移動しているＩＡＢノードである。移動ＩＡＢノードは、移動可能なＩＡＢノードであってもよい。或いは、移動ＩＡＢノードは、移動する能力を有するＩＡＢノードであってもよい。或いは、移動ＩＡＢノードは、現在静止しているものの、将来移動することが確実な（又は将来移動することが予想される）ＩＡＢノードであってもよい。
　移動ＩＡＢノードによって、例えば、移動ＩＡＢノード配下のＵＥ１００が移動ＩＡＢノードの移動に伴って移動しながら、移動ＩＡＢノードからサービスの提供を受けることが可能となる。例えば、乗り物に乗車しているユーザ（又はＵＥ１００）が、乗り物に設置された移動ＩＡＢノードを介して、サービスの提供を受けるケースなどが想定される。
　一方、移動ＩＡＢノードに対して、移動することがないＩＡＢノードも存在する。このようなＩＡＢノードを、中間ＩＡＢノード（ｉｎｔｅｒｍｅｄｉａｔｅ　ＩＡＢ　ｎｏｄｅ）と称する場合がある。中間ＩＡＢノードは、例えば、移動しないＩＡＢノードである。或いは、中間ＩＡＢノードは、静止したＩＡＢノードでもよい。中間ＩＡＢノードは、静止ＩＡＢノード（ｓｔａｔｉｏｎａｒｙ　ＩＡＢ　ｎｏｄｅ）であってもよい。或いは、中間ＩＡＢノードは、設置場所に設置されたまま静止した（又は移動しない）ＩＡＢノードであってもよい。或いは、中間ＩＡＢノードは、移動することなく静止したＩＡＢノードであってもよい。中間ＩＡＢノードは、固定ＩＡＢノードであってもよい。
　移動ＩＡＢノードは、中間ＩＡＢノードに接続することもできる。また、移動ＩＡＢノードは、ドナーノード２００に接続することもできる。移動ＩＡＢノードは、移動（ｍｉｇｒａｔｉｏｎ又はハンドオーバ）により接続先を変更することも可能である。接続元は、中間ＩＡＢノードでもよい。当該接続元は、ドナーノード２００でもよい。また、接続先は、中間ＩＡＢノードでもよい。当該接続先は、ドナーノード２００でもよい。
　なお、以下では、移動ＩＡＢノードの移動（ｍｉｇｒａｔｉｏｎ）と、移動ＩＡＢノードのハンドオーバ（ｈａｎｄｏｖｅｒ）とを区別しないで用いる場合がある。
　また、以下では、移動ＩＡＢノードは、「ｍｏｂｉｌｅ　ＩＡＢ　ｎｏｄｅ」であってもよい。当該移動ＩＡＢノードは、「ｍｉｇｒａｔｉｎｇ　ＩＡＢ　ｎｏｄｅ」であってもよい。いずれの場合も、移動ＩＡＢノードと表記する場合がある。
　（移動ＩＡＢノードの完全移動（Ｆｕｌｌ　ｍｉｇｒａｔｉｏｎ））
　移動ＩＡＢノード（ｍｏｂｉｌｅ　ＩＡＢ　ｎｏｄｅ）が、ドナーノード（ＩＡＢ－ｄｏｎｏｒ）２００間を移動する場合がある。
　図９（Ａ）乃至図１０（Ｂ）は、移動ＩＡＢノード３００Ｍがソースドナーノード２００－Ｓからターゲットドナーノード２００－Ｔへの移動が行われる場合の手順の例を表す図である。なお、移動ＩＡＢノード３００Ｍは、配下にＵＥ１００を有する。図９（Ａ）の例では、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵ＃１により形成されたセル範囲にＵＥ１００が在圏する例を示している。ＵＥ１００は、移動ＩＡＢノード３００Ｍとともに移動することができる。
　図９（Ａ）は、初期状態（Ｉｎｉｔｉａｌ　ｃｏｎｄｉｔｉｏｎ）の例を表している。移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵ＃１は、ソースドナーノード２００－ＳのＣＵに対してＦ１接続を確立している。また、移動ＩＡＢノード３００ＭのＩＡＢ－ＭＴは、ソースドナーノード２００－ＳのＣＵに対してＲＲＣ接続を確立している。
　図９（Ｂ）は、移動ＩＡＢノード３００Ｍは、ターゲットドナーノード２００－Ｔへの移動により、ターゲットドナーノード２００－Ｔに対して、部分移動（Ｐａｒｔｉａｌ　ｍｉｇｒａｔｉｏｎ）の状態となった場合の例を表している。図９（Ｂ）に示すように、部分移動では、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵ＃１（及びＵＥ１００）が、ソースドナーノード２００－ＳのＣＵで終端される一方で、移動ＩＡＢノード３００ＭのＩＡＢ－ＭＴがターゲットドナーノード２００－ＴのＣＵへ移動した状態となっている。移動ＩＡＢノード３００ＭのＩＡＢ－ＭＴは、ターゲットドナーノード２００－ＴのＣＵとＲＲＣ接続を確立している。また、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵは、ソースドナーノード２００－ＳとＦ１接続を確立している。部分移動とは、例えば、移動ＩＡＢノード３００Ｍ配下のＵＥ１００の接続が、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵ＃１を介してソースドナーノード２００－Ｓに残っている状態をいう。
　図１０（Ａ）は、その後、移動ＩＡＢノード３００Ｍが、ターゲットドナーノード２００－Ｔに対して、完全移動（Ｆｕｌｌ　ｍｉｇｒａｔｉｏｎ）のフェーズ１の状態となった場合の例を表す。完全移動のフェーズ１では、ＵＥ１００が、ＩＡＢ－ＤＵ＃１を介してソースドナーノード２００－Ｓとの接続が残っているものの、新たなＩＡＢ－ＤＵ＃２がターゲットドナーノード２００－ＴのＣＵに対して、Ｆ１接続を確立した状態となっている。ここで、ＩＡＢ－ＤＵ＃１とＩＡＢ－ＤＵ＃２は、論理的なＩＡＢ－ＤＵであってもよい。１つの物理的なＩＡＢ－ＤＵにおいて、論理的な２つのＩＡＢ－ＤＵ（ＩＡＢ－ＤＵ＃１及びＩＡＢ－ＤＵ＃２）が含まれてもよい。
　図１０（Ｂ）は、その後、移動ＩＡＢノード３００Ｍが、ターゲットドナーノード２００－Ｔに対して、完全移動のフェーズ２の状態となった場合の例を表す。完全移動のフェーズ２では、移動ＩＡＢノード３００Ｍ（及びＵＥ１００）の接続が、ソースドナーノード２００－ＳのＣＵからターゲットドナーノード２００－ＴのＣＵへ移動した状態となっている。完全移動とは、例えば、ＵＥ１００の接続が、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵ＃２を介してターゲットドナーノード２００－Ｔへ移っている状態をいう。
　なお、移動ＩＡＢノード３００Ｍによる２つのＤＵ（ＩＡＢ－ＤＵ＃１及びＩＡＢ－ＤＵ＃２）を用いたＣＵ間の移動を、「デュアルＤＵアプローチ」と称する場合がある。例えば、ＵＥ１００が、一方のＣＵ及びＤＵから、他方のＣＵ及びＤＵへ移動することで、デュアルＤＵアプローチが行われる。
　（ＲＡＣＨレスハンドオーバ）
　３ＧＰＰでは、ＲＡＣＨレスハンドオーバ（ＲＡＣＨ－ｌｅｓｓ　ＨＯ）について規定されている（例えば、３ＧＰＰ　ＴＳ　３６．３００　Ｖ１７．１．０　（２０２２－０６））。ＲＡＣＨレスハンドオーバとは、ランダムアクセスプロシージャ（ｒａｎｄｏｍ　ａｃｃｅｓｓ　ｐｒｏｃｅｄｕｒｅ）をスキップしたハンドオーバのことである。ＬＴＥシステムにおけるＲＡＣＨレスハンドオーバでは、例えば、以下のような処理が行われる。
　すなわち、ＵＥ１００は、ソースセルから、ＲＲＣ接続再設定（ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージを受信する。ＲＲＣ接続再設定メッセージには、ＵＥ１００がＲＡＣＨレスハンドオーバを行う際に用いられるパラメータ（ＴＡ（Timing Advance）値及び／又はＵＬグラントなど）を含む情報要素（ＭｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏ）が含まれる。ＵＥ１００は、当該ＲＲＣ接続再設定メッセージに含まれるパラメータを利用して、ターゲットセルに対して、ランダムアクセス（ＲＡＣＨ）プロシージャを実行することなく、ＲＲＣ接続再設定完了（ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージを送信する。以上により、ＲＡＣＨレスハンドオーバが実行され、ＵＥ１００は、ターゲットセルに対し上り方向の同期を確立することができる。
　ＲＡＣＨレスハンドオーバでは、ランダムアクセスプロシージャがスキップされるため、ＵＥ１００においてランダムアクセスプロシージャが実行される場合と比較して、ハンドオーバの実行時間の遅延を改善させることができる。
　（第１実施形態に係る通信制御方法）
　移動ＩＡＢノード３００Ｍの配下のＵＥ１００がＲＡＣＨレスハンドオーバを行ってもよい場合がある。例えば、移動ＩＡＢノード３００Ｍの完全移動（Ｆｕｌｌ　ｍｉｇｒａｔｉｏｎ）では、ＵＥ１００は、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵ＃１（又はＩＡＢ－ＤＵ＃１により形成されたセル；すなわちソースセル）から、ＩＡＢ－ＤＵ＃２（又はＩＡＢ－ＤＵ＃２により形成されたセル；すなわちターゲットセル）へ接続先を変更することになる（図１０（Ａ）及び図１０（Ｂ）参照）。そのため、ＵＥ１００は、ＩＡＢ－ＤＵ＃１からＩＡＢ－ＤＵ＃２へのハンドオーバを行う。しかし、ＩＡＢ－ＤＵ＃１とＩＡＢ－ＤＵ＃２は論理的なＤＵであり、物理的には同一のＤＵとなる場合がある。すなわち、同一のアンテナシステムを用いて２つのＤＵ（又は２つのセル）が提供される場合、ＵＥ１００と当該アンテナシステムとの物理的な距離は同一のため、ＴＡ値も同一とみなすことができる。従って、ＵＥ１００は、ＩＡＢ－ＤＵ＃１からＩＡＢ－ＤＵ＃２へのハンドオーバの際に、ＩＡＢ－ＤＵ＃２に対してランダムアクセスプロシージャを実行するよりも、ＲＡＣＨレスハンドオーバを行った方が接続の遮断なども回避することができ、適切に通信を行うことが可能になる。
　一方、５Ｇシステムにおいて、ＵＥ１００は、ＲＲＣ再設定完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージを送信することで、ＲＡＣＨレスハンドオーバを完了させることができる。５Ｇシステムでは、ＬＴＥシステムにおけるＲＲＣ接続再設定完了（ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージに代えて、ＲＲＣ再設定完了メッセージとなる。
　一般に、上り方向のリソース情報（すなわち、ＵＬグラント（ＵＬ　ｇｒａｎｔ））は、下り制御情報（ＤＣＩ：Downlink Control Information）を用いてＤＵにより設定される。一方、ＲＡＣＨレスハンドオーバはＲＲＣ再設定メッセージを用いて設定されるため、ＣＵにより設定される。すなわち、ＵＬグラントはＤＵにより設定され、ＲＡＣＨレスハンドオーバはＣＵにより設定される。ＣＵは、ＵＬグラントに関する情報がなければ、ＲＡＣＨレスハンドオーバをＵＥ１００に対して適切に設定することができない場合がある。この場合、ＵＥ１００は、ＲＲＣ再設定完了メッセージを送信することができず、ＲＡＣＨレスハンドオーバを適切に実行することができない。
　そこで、第１実施形態では、ＵＥ１００がＲＡＣＨレスハンドオーバを適切に実行することを目的としている。
　そのため、第１実施形態では、第１に、分散装置（ＤＵ）が、ＲＡＣＨレスハンドオーバの際にユーザ装置（例えばＵＥ１００）において用いられるリソースに関するリソース情報を中央装置（ＣＵ）へ送信する。第２に、中央装置が、リソース情報を含むハンドオーバコマンドをユーザ装置へ送信する。
　このように、ＤＵからＣＵへ、ＲＡＣＨレスハンドオーバの際にＵＥ１００において用いられるリソース情報が送信されるため、ＣＵは、ＵＥ１００に対して、当該リソース情報を用いてＲＡＣＨレスハンドオーバを適切に設定することができる。よって、ＵＥ１００は、ＲＡＣＨレスハンドオーバを適切に実行することが可能となる。
　（ＣＵとＤＵとＵＥ１００との関係）
　ここで、ＲＡＣＨレスハンドオーバが行われる際のＣＵとＤＵとＵＥ１００との関係例について説明する。なお、ＣＵは中央装置であってもよく、ＤＵは分散装置であってもよい。
　図１１は、第１実施形態に係るＣＵとＤＵとＵＥ１００との関係例を表す図である。一般的には、図１１に示すように、ＵＥ１００がソース側ＤＵ（又はソース側ＤＵにより形成されたソースセル）から、ターゲット側ＤＵ（又はターゲット側ＤＵにより形成されたターゲットセル）へ移動する際に、ＵＥ１００は、移動先のターゲット側ＤＵに対してハンドオーバ（第１実施形態ではＲＡＣＨレスハンドオーバ）を実行する。
　ＣＵとＤＵとＵＥ１００の関係は、例えば、以下の２つに分類できる。
　第１に、ＣＵがドナーノード２００に含まれ、ＤＵが移動ＩＡＢノード３００Ｍに含まれる場合である。すなわち、ＣＵがドナーノード２００のＣＵ（ＩＡＢ－ｄｏｎｏｒ－ＣＵ）であり、ＤＵが移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵとなる場合である。図１２（Ａ）及び図１２（Ｂ）は、このような場合の関係例を表している。図１２（Ａ）はドナー間移動（Ｉｎｔｅｒ－ｄｏｎｏｒ　ｍｉｇｒａｔｉｏｎ）の例を表し、図１２（Ｂ）はドナー内移動（Ｉｎｔｒａ－ｄｏｎｏｒ　ｍｉｇｒａｔｉｏｎ）の例を表している。なお、移動ＩＡＢノード３００Ｍは固定ＩＡＢノードでもよい。
　第２に、ＣＵ及びＤＵがｇＮＢ２００に含まれる場合である。すなわち、ＣＵがｇＮＢ２００のＣＵであり、ＤＵがｇＮＢ２００のＤＵである場合である。図１３（Ａ）及び図１３（Ｂ）は、このような場合の関係例を表している。図１３（Ａ）はｇＮＢ間ハンドオーバ（Ｉｎｔｅｒ－ｇＮＢ　ＨＯ）の例を表し、図１３（Ｂ）はｇＮＢ内ハンドオーバ（Ｉｎｔｒａ－ｇＮＢ　ＨＯ）の例を表している。なお、ソースセルとターゲットセルとは同一のＤＵから提供されてもよい。このようなハンドオーバは、ＤＵ内（Ｉｎｔｒａ－ＤＵ　ＨＯ）と呼ばれる。
　なお、移動ＩＡＢノード３００ＭのＩＡＢ－ＭＴは、移動ＩＡＢノードにおいてＵＥ機能を有している。そのため、移動ＩＡＢノード３００Ｍ自身がドナーノード２００に対してＲＡＣＨレスハンドオーバを行う場合もある。この場合、図１３（Ａ）及び図１３（Ｂ）において、ＵＥ１００を移動ＩＡＢノード３００Ｍ、ｇＮＢ２００をドナーノード２００と読み替えることができる。
　以下に示す動作例では、主に、図１２（Ａ）に示すドナー間移動（或いは図９（Ａ）乃至図１０（Ｂ）に示す完全移動）の例で説明する場合がある。
　（第１実施形態に係る動作例）
　図１４は、第１実施形態に係る動作例を表す図である。
　図１４に示すように、ステップＳ１０において、ＣＵは、ＵＥ１００に対してＲＡＣＨレスハンドオーバを設定することを決定する。例えば、ターゲットドナーノード２００－ＴのＣＵが、移動ＩＡＢノード３００Ｍが移動するため、移動ＩＡＢノード３００Ｍ配下のＵＥ１００に対してＲＡＣＨレスハンドオーバを設定することを決定する。もしくは、ソースドナーノード２００－ＳのＣＵが、移動ＩＡＢノード３００Ｍが移動するため、移動ＩＡＢノード３００Ｍ配下のＵＥ１００に対してＲＡＣＨレスハンドオーバの設定が可能であることを、Ｘｎメッセージを用いて、ターゲットドナーノード２００－ＴのＣＵへ通知してもよい。
　ステップＳ１１において、ＣＵは、ＤＵ（ターゲットセルを提供するＤＵ）に対して、ＲＡＣＨレスハンドオーバ用のリソース（又はＵＬリソース）の確保を要求してもよい。ＣＵは、ＲＡＣＨレスハンドオーバ用のリソース確保を要求するリソース確保要求メッセージを送信することで当該要求を行ってもよい。例えば、ターゲットドナーノード２００－ＴのＣＵは、ターゲット側ＤＵ（図１０（Ａ）の例では、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵ＃２）との間でＦ１接続を確立している場合、リソース確保要求メッセージをＦ１メッセージとして、ターゲット側ＤＵへ送信する。リソース確保要求メッセージは、ＲＡＣＨレスハンドオーバ用のＵＬグラントの割り当てを要求するメッセージであってもよい。或いは、リソース確保要求メッセージは、ＤＵが割り当てたＲＡＣＨレスハンドオーバ用のリソース情報（又はＵＬグラント情報）の提供を要求するものであってもよい。或いは、リソース確保要求メッセージは、ＵＥコンテキストの確立（ＵＥ　Ｃｏｎｔｅｘｔ　Ｓｅｔｕｐ）を要求するとともに、ＲＡＣＨレスハンドオーバであることを示す識別子が含まれてもよい。或いは、リソース確保要求メッセージには、ＣＵが希望する設定値（又はＲＲＣ再設定メッセージに含める設定値）が含まれてもよい。
　ステップＳ１２において、ＤＵは、ＲＡＣＨレスハンドオーバ用のＵＬグラント情報をＣＵへ送信する。ＵＬグラント情報は、例えば、ＲＡＣＨレスハンドオーバの際にＵＥ１００において用いられるリソースに関するリソース情報を表している。ＤＵは、ＲＡＣＨレスハンドオーバ用のＵＬグラント情報を含むリソース情報メッセージをＣＵへ送信することで当該ＵＬグラント情報の送信が行われてもよい。例えば、ターゲット側ＤＵ（図１０（Ａ）の例では、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵ＃２）は、ターゲットドナーノード２００－ＴのＣＵとの間でＦ１接続を確立している場合、ＵＬグラント情報を含むリソース情報メッセージをＦ１メッセージとして、ターゲットドナーノード２００－ＴのＣＵへ送信する。リソース情報メッセージに含まれるＵＬグラント情報は、ＵＬリソース設定情報であってもよい。当該情報は、ＰＵＳＣＨ（Physical Uplink Shared Channel）リソース設定情報であってもよい。
　ステップＳ１３において、ＣＵは、ＲＡＣＨレスハンドオーバ用のＵＬグラント情報をハンドオーバコマンドに含める。ハンドオーバコマンドは、ＵＥ１００がハンドオーバの際にターゲットセルと同期を確立するために用いられる情報要素（例えば同期付き再設定（reconfigurationWithSync））を含むＲＲＣ再設定（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージであってもよい。ＲＡＣＨレスハンドオーバ用のＵＬグラント情報は同期付き再設定に含まれてもよい。例えば、ターゲットドナーノード２００－ＴのＣＵは、当該ＵＬグラント情報をハンドオーバコマンドに含めるようにする。
　ステップＳ１４において、ＣＵは、ＵＥ１００へ、ハンドオーバコマンドを送信する。例えば、ターゲットドナーノード２００－ＴのＣＵは、ソースドナーノード２００－ＳのＣＵへ、ハンドオーバコマンドを含むＸｎメッセージを送信し、ソースドナーノード２００－ＳのＣＵは、ＵＥ１００へ、ハンドオーバコマンドを送信する。この場合、ソースドナーノード２００－ＳのＣＵは、Ｘｎメッセージからハンドオーバコマンドを取り出し、当該ハンドオーバコマンドを含むＦ１メッセージを、移動ＩＡＢノード３００Ｍのソース側ＤＵ（図１０（Ａ）の例では、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵ＃１）へ送信する。そして、当該ソース側ＤＵ（ソースセル）は、Ｆ１メッセージからハンドオーバコマンドを取り出して、当該ハンドオーバコマンドをＵＥ１００へ送信する。
　ステップＳ１５において、ＵＥ１００は、ハンドオーバコマンドからＵＬグラント情報などを抽出し、ランダムアクセスプロシージャを行うことなく、ＵＬグラント情報により表されたリソースを利用して、ＲＲＣ再設定完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージを、ターゲット側ＤＵ（ターゲットセル）へ送信する。これにより、ＵＥ１００では、ＲＡＣＨレスハンドオーバが行われる。ＵＥ１００は、ターゲット側ＤＵにより割り当てられたリソースを用いて、ＲＡＣＨレスハンドオーバを実行することになる。
　（第１実施形態に係る他の例１）
　上述した第１実施形態に係る動作例は、主に、移動ＩＡＢノード３００Ｍがドナー間移動（Ｉｎｔｅｒ－ｄｏｎｏｒ　ｍｉｇｒａｔｉｏｎ）を行う場合の例で説明したが、これに限定されない。上述した動作例は、移動ＩＡＢノード３００Ｍがドナーノード内移動を行う場合（図１２（Ｂ））にも適用可能である。この場合、ドナーノード２００のＣＵが移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵに対してリソース確保要求を行ってもよい（ステップＳ１１）。また、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵがＲＡＣＨレスハンドオーバ用のＵＬグラントをドナーノード２００のＣＵへ送信する（ステップＳ１２）。そして、ドナーノード２００のＣＵが、当該ＵＬグラントを含むハンドオーバコマンドをＵＥ１００へ送信する（ステップＳ１４）。
　また、上述した動作例は、ｇＮＢ間ハンドオーバ（図１３（Ａ））にも適用可能である。この場合、図１４において、ソース側ＤＵをソース側ｇＮＢ２００－１のＤＵと読み替え、ターゲット側ＤＵをターゲット側ｇＮＢ２００－２のＤＵと読み替えればよい。
　更に、上述した動作例は、ｇＮＢ内ハンドオーバ（図１３（Ｂ））にも適用可能である。この場合、図１４において、ソース側ＤＵをｇＮＢ２００のソース側ＤＵと読み替え、ターゲット側ＤＵをｇＮＢ２００のターゲット側ＤＵと読み替えればよい。
　更に、上述した動作例は、移動ＩＡＢノード３００Ｍ自身がドナーノード２００に対してＲＡＣＨレスハンドオーバを行う場合にも適用可能である。
　第１に、移動ＩＡＢノード３００Ｍがドナー間移動（Ｉｎｔｅｒ－ｄｏｎｏｒ　ｍｉｇｒａｔｉｏｎ）を行う場合は、図１４において、ソース側ＤＵをソースドナーノード２００－ＳのＤＵと読み替え、ターゲット側ＤＵをターゲットドナーノード２００－ＴのＤＵと読み替え、更に、ＵＥ１００を移動ＩＡＢノード３００Ｍと読み替えればよい。この場合、図１４において、ターゲットドナーノード２００－ＴのＣＵが、Ｘｎメッセージでハンドオーバコマンドをソースドナーノード２００－ＳのＣＵへ送信し、ソースドナーノード２００－ＳのＣＵが、ハンドオーバコマンドを移動ＩＡＢノード３００Ｍへ送信することになる。
　第２に、移動ＩＡＢノード３００Ｍがドナー内移動（Ｉｎｔｒａ－ｄｏｎｏｒ　ｍｉｇｒａｔｉｏｎ）を行う場合は、図１４において、ソース側ＤＵをドナーノード２００のソース側ＤＵと読み替え、ターゲット側ＤＵをドナーノード２００のターゲット側ＤＵと読み替え、更に、ＵＥ１００を移動ＩＡＢノード３００Ｍと読み替えればよい。図１４に示す動作例は、ＤＵ内ハンドオーバ（ｉｎｔｒａ－ＤＵ　ＨＯ）にも適用されてもよい。
　（第１実施形態に係る他の例２）
　第１実施形態では、ＲＡＣＨレスハンドオーバの例について説明したが、これに限定されない。例えば、第１実施形態では、条件付きハンドオーバ（ＣＨＯ）がＲＡＣＨレスハンドオーバで行われる場合でも適用可能である。この場合、ＣＵは、条件付きＲＡＣＨレスハンドオーバ用のリソースの確保をターゲット側ＤＵへ要求してもよい（ステップＳ１１）。当該要求は第１実施形態と同様にリソース確保要求メッセージにより行われてもよい。また、ターゲット側ＤＵは、条件付きＲＡＣＨレスハンドオーバ用のリソースを表すＵＬグラント情報をＣＵへ送信する（ステップＳ１２）。当該ＵＬグラント情報はリソース情報メッセージに含まれてもよい。また、ＣＵは、条件付き再設定（ｃｏｎｄｉｔｉｏｎａｌ　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）に当該ＵＬグラント情報を含めて、条件追記再設定を含むＲＲＣ再設定（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージをＵＥ１００へ送信してもよい（ステップＳ１４）。
［第２実施形態］
　次に、第２実施形態について説明する。第２実施形態では、主に、第１実施形態との相違点を中心に説明する。
　第２実施形態では、条件付きハンドオーバがＲＡＣＨレスハンドオーバで行われる場合の例について説明する。条件付きハンドオーバがＲＡＣＨレスハンドオーバで行われることを、以下では、条件付きＲＡＣＨレスハンドオーバ（Ｃｏｎｄｉｔｉｏｎａｌ　ＲＡＣＨ－ｌｅｓｓ　ＨＯ）と称する場合がある。
　（条件付きハンドオーバ）
　ここで、条件付きハンドオーバ（ＣＨＯ）について説明する。一般的なハンドオーバにおいては、ＵＥ１００がサービングセル及び／又は隣接セルの無線状態の測定値をｇＮＢ２００に報告し、この報告に基づいてｇＮＢ２００が隣接セルへのハンドオーバを決定し、ハンドオーバ指示をＵＥ１００に送信する。このため、サービングセルの無線状態が急激に劣化したような場合、一般的なハンドオーバは、ハンドオーバが実行される前に通信が途絶する場合がある。
　これに対し、条件付きハンドオーバは、予め設定されたトリガ条件が満たされると、ＵＥ１００は、当該トリガ条件に対応する候補セルへのハンドオーバを自律的に実行することが可能である。このため、一般的なハンドオーバにおける通信途絶などの問題を解決できる。
　条件付きハンドオーバの設定は、条件付き再設定（ｃｏｎｄｉｔｉｏｎａｌ　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）により行われる。条件付き再設定は、ＲＲＣ再設定（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージに含まれる情報要素（ＩＥ）の一つである。条件付き再設定は、例えば、ドナーノード２００のＣＵからＩＡＢノード３００のＩＡＢ－ＭＴ（又はＵＥ１００）へ、ＲＲＣ再設定メッセージを送信することで設定が行われる。条件付き再設定は、条件付きハンドオーバで利用される候補セル及び実行条件を含む。実行条件には１つ以上のトリガ条件を含む。ＩＡＢノード３００のＩＡＢ－ＭＴ（又はＵＥ１００）は、トリガ条件が満たされると、候補セルへのハンドオーバの実行を開始する。
　（第２実施形態に係る通信制御方法）
　上述したように、例えば、ＵＥ１００が条件付きハンドオーバを行う場合、ＵＥ１００は、トリガ条件が満たされるまで、ターゲットセルへのアクセスを開始しない。つまり、ＵＥ１００は、条件付き再設定の設定が行われた後、直ちに、ターゲットセルへのアクセスを開始するわけではない。また、条件付きハンドオーバでは、複数のターゲットセルへのアクセスを設定することもできる。しかし、あるターゲットセルに対してはトリガ条件が満たされることなく、ＵＥ１００によるアクセスが行われない場合もある。
　条件付きＲＡＣＨレスハンドオーバの場合であっても、トリガ条件が満たされると、ＲＡＣＨレスハンドオーバを実行するため、当該実行のためのリソース（ＵＬリソース）が必要となる。具体的には、ＲＲＣ再設定完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージをターゲットセルへ送信するためのリソース（又は無線リソース）が必要である。
　上述したように、条件付きハンドオーバでは、ＵＥ１００は直ちにターゲットセルへのアクセスを行うわけではない。そのため、ＲＲＣ再設定完了メッセージを送信するためのソースの確保が一定時間行われることになる。
　しかし、当該リソースを一定時間以上、維持しておくのは、リソースの効率化の観点では望ましいこととは言えない場合がある。当該リソースを一定時間以上維持する場合よりも、当該リソースを他の通信で利用させた方が良い場合もあるからである。
　そこで、第２実施形態では、条件付きＲＡＣＨレスハンドオーバのためのリソースを確保しつつ、無線リソースの有効活用化を図ることを目的としている。
　そのため、第２実施形態では、第１に、中央装置（ＣＵ）が、条件付きＲＡＣＨレスハンドオーバの際にユーザ装置（例えばＵＥ１００）において用いられるリソースの有効期間を表す有効期間情報を分散装置（ＤＵ）へ送信する、及び、分散装置が、有効期間情報を中央装置へ送信することのいずれかを行う。第２に、中央装置が、有効期間情報を含む条件付き再設定をユーザ装置へ送信する。
　このように、ＵＥ１００では、条件付きＲＡＣＨレスハンドオーバで用いられるリソースの有効期間が通知されるため、有効期間が経過すると、当該リソースが解放されて、他の通信に利用することが可能となる。よって、セルラ通信システム１では、条件付きＲＡＣＨレスハンドオーバのためのリソースを確保しつつ、当該リソースの有効活用化を図ることができる。
　なお、中央装置がＣＵであり、分散装置がＤＵであることは第１実施形態と同様である。ＣＵとＤＵとＵＥ１００との関係例も第１実施形態と同様である。
　（第２実施形態に係る動作例）
　次に、第２実施形態に係る動作例について説明する。
　図１５は、第２実施形態に係る動作例を表す図である。図１５に示す動作例では、主に、図１２（Ａ）に示すドナー間移動（或いは図９（Ａ）乃至図１０（Ｂ）に示す完全移動）の例で説明する。
　図１５に示すように、ステップＳ２０において、ＣＵは、ＵＥ１００に対して条件付きＲＡＣＨレスハンドオーバを設定することを決定する。例えば、ターゲットドナーノード２００－ＴのＣＵが、移動ＩＡＢノード３００Ｍ配下のＵＥ１００に対して条件付きＲＡＣＨレスハンドオーバを設定することを決定する。
　ステップＳ２１において、ＣＵは、ＤＵに対して、条件付きＲＡＣＨレスハンドオーバ用のリソース（又はＵＬリソース）の確保を要求してもよい。第１実施形態と同様に、リソース確保要求メッセージにより当該要求が行われてもよい。例えば、ターゲットドナーノード２００－ＴのＣＵは、ターゲット側ＤＵ（図１０（Ａ）の例では、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵ＃２）との間でＦ１接続を確立している場合、リソース確保要求メッセージをＦ１メッセージとして、ターゲット側ＤＵへ送信する。リソース確保要求メッセージには、条件付きＲＡＣＨレスハンドオーバ用のリソースの有効期間を表す有効期間情報が含まれてもよい。当該有効期間はタイマ値により表されてもよい。当該有効期間はＣＵが決定してもよい。
　ステップＳ２２において、ＤＵは、ＣＵに対して、条件付きＲＡＣＨレスハンドオーバ用のリソースを表すリソース情報とともに、当該リソースの有効期間を表す有効期間情報を送信してもよい。第１実施形態と同様に、リソース情報メッセージを用いて送信が行われてもよい。この場合、リソース情報メッセージには、当該リソース情報と当該有効期間情報とが含まれる。当該有効期間はＤＵが決定し、ＣＵへ送信してもよい。すなわち、当該有効期間は、ＣＵが決定してもよい（ステップＳ２１）。当該有効期間は、ＤＵが決定してもよい（ステップＳ２２）。例えば、ターゲット側ＤＵ（図１０（Ａ）の例では、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵ＃２）が、有効期間情報を含むリソース情報メッセージをＦ１メッセージとして、ターゲットドナーノード２００－ＴのＣＵへ送信する。
　ステップＳ２３において、ＣＵは、当該有効期間情報を条件付き再設定（ｃｏｎｄｉｔｉｏｎａｌ　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）に含める。当該有効期間は、条件付き再設定毎（又は設定リストのエントリ毎）に紐づけられてもよい。当該有効期間は、全ての条件付き再設定において共通に適用されてもよい。例えば、ターゲットドナーノード２００－ＴのＣＵは、当該有効期間情報を条件付き再設定に含めるようにする。
　ステップＳ２４において、ＣＵは、有効期間情報を含む条件付き再設定をＵＥ１００へ送信する。条件付き再設定は、ＲＲＣ再設定（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージに含まれて送信されてもよい。例えば、ターゲットドナーノード２００－ＴのＣＵは、ソースドナーノード２００－ＳのＣＵへ、条件付き再設定を含むＲＲＣ再設定メッセージを、Ｘｎメッセージを利用して送信し、ソースドナーノード２００－ＳのＣＵが当該ＲＲＣ再設定メッセージをＵＥ１００へ送信する。この場合、ソースドナーノード２００－ＳのＣＵは、Ｘｎメッセージから当該ＲＲＣ再設定メッセージを取り出し、当該ＲＲＣ再設定メッセージを含むＦ１メッセージを、移動ＩＡＢノード３００Ｍのソース側ＤＵ（図１０（Ａ）の例では、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵ＃１）へ送信する。そして、当該ソース側ＤＵは、Ｆ１メッセージから当該ＲＲＣ再設定メッセージを取り出して、当該ＲＲＣ再設定メッセージをＵＥ１００へ送信する。
　ステップＳ２４において、ＵＥ１００は、条件付き再設定を受信する。ＵＥ１００は、条件付き再設定に有効期間情報が含まれている場合、タイマによるカウントを開始する。ＵＥ１００は、条件付き再設定を受信したときにタイマのカウントを開始してもよい。
　ステップＳ２５において、ＵＥ１００は、タイマによるカウント値が有効期間に達したか否か（すなわち、タイマが満了したか否か）を判定する。
　ＵＥ１００は、タイマが満了すると（ステップＳ２５においてＹｅｓ）、ステップＳ２６において、条件付き再設定を破棄する。すなわち、ＵＥ１００は、条件付きＲＡＣＨレスハンドオーバ用のリソースの有効期間が経過したため、条件付き再設定を破棄する。そして、ＵＥ１００は、ステップＳ２７において一連の処理を終了する。
　一方、ＵＥ１００は、タイマが満了する前に（ステップＳ２５においてＮｏ）、トリガ条件を満たすとき（ステップＳ２８でＹｅｓ）、ステップＳ２９において、ＲＲＣ再設定完了メッセージをターゲットＤＵへ送信する。すなわち、有効期間が経過する前に、条件付き再設定で示されたトリガ条件を満たしたとき、ＵＥ１００は、ＲＲＣ再設定完了メッセージをターゲットＤＵへ送信することで、条件付きＲＡＣＨレスハンドオーバを実行する。一方、ＵＥ１００は、タイマが満了する前に（ステップＳ２５においてＮｏ）、トリガ条件を満たさないとき（ステップＳ２８でＮｏ）、ステップＳ２５へ移行して上述した処理（ステップＳ２５からステップＳ２８）を繰り返す。
　（第１実施形態に係る他の例１）
　第１実施形態に係る動作例は、主に、移動ＩＡＢノード３００Ｍがドナー間移動（Ｉｎｔｅｒ－ｄｏｎｏｒ　ｍｉｇｒａｔｉｏｎ）を行う場合の例で説明したが、これに限定されない。上述した動作例は、移動ＩＡＢノード３００Ｍがドナーノード内移動を行う場合（図１２（Ｂ））にも適用可能である。この場合、第１実施形態と同様にターゲット側ＤＵ及びソース側ＤＵを読み替えることで実施可能である。
　また、第１実施形態に係る動作例は、ｇＮＢ間ハンドオーバ（図１３（Ａ））にも適用可能である。更に、上述した動作例は、ｇＮＢ内ハンドオーバ（図１３（Ｂ））にも適用可能である。更に、上述した動作例は、移動ＩＡＢノード３００Ｍ自身のドナーノード２００に対してＲＡＣＨレスハンドオーバを行う場合にも適用可能である。いずれの場合も、ＣＵ、ターゲット側ＤＵ、ソース側ＤＵ、及び／又はＵＥを、第１実施形態と同様に読み替えることで実施可能である。
　（第２実施形態に係る他の例２）
　第２実施形態で説明した有効期間は、予め仕様で決められた値（又はハードコーディングにより決められた値）が用いられてもよい。この場合、ＣＵからＵＥ１００へ有効期間は送信されない。ＵＥ１００では、条件付きＲＡＣＨレスハンドオーバの設定が行われた場合（ステップＳ２４）、タイマのカウントを開始して、カウント値が予め決められた値に達したか否かにより、タイマが満了したか否かを判定する。
　（第２実施形態に係る他の例３）
　第２実施形態では、条件付きハンドオーバにおいてＲＡＣＨレスハンドオーバが行われる例について説明したが、これに限定されない。例えば、他の条件付きセル変更の手順においてＲＡＣＨレスハンドオーバが行われる場合においても適用可能である。他の条件付きセル変更の手順としては、例えば、条件付きＰＳセル変更（ＣＰＣ：Conditional PSCell Change）又は条件付きＰＳセル追加（ＣＰＡ：Conditional PSCell Addition）などがある。
　条件付きＰＳセル変更は、例えば、実行条件が満たされた場合に、ＵＥ１００において、セカンダリセルグループのプライマリセルであるＰＳセルを変更する手順のことである。条件付きＰＳセル変更は、ＣＰＣ設定（ＣＰＣ　ｃｏｎｆｉｇｕｒａｔｉｏｎ）により設定が行われる。ＣＰＣ設定には、実行条件、及び候補となるＰＳセルの情報などが含まれる。ＣＵは、ＣＰＣ設定に有効期間情報を含めて、ＵＥ１００へ送信することで（ステップＳ２４）、条件付きＰＳセル変更におけるＲＡＣＨレスハンドオーバをＵＥ１００に設定してもよい。ＵＥ１００では、タイマが満了すると、ＣＰＣ設定を破棄し、タイマ満了前に実行条件が満たされると、ＲＡＣＨレスハンドオーバによりＰＳセル変更を実行する。
　また、条件付きＰＳセル追加は、例えば、ＰＳセル追加条件が満たされた場合、ＵＥ１００において、ＰＳセルを追加する手順のことである。条件付きＰＳセル追加は、ＣＰＡ設定（ＣＰＡ　ｃｏｎｆｉｇｕｒａｔｉｏｎ）により設定が行われる。ＣＰＡ設定には、実行条件、及び候補となるＰＳセルの情報などが含まれる。ＣＵは、ＣＰＡ設定に有効期間情報を含めてＵＥ１００へ送信することで（ステップＳ２３）、条件付きＰＳセル追加におけるＲＡＣＨレスハンドオーバをＵＥ１００に設定してもよい。ＵＥ１００では、タイマが満了すると、ＣＰＡ設定を破棄し、タイマ満了前に実行条件が満たされると、ＲＡＣＨレスハンドオーバによりＰＳセル追加を実行する。
　（第２実施形態に係る他の例４）
　第２実施形態では、有効期間情報をＵＥ１００に設定する例について説明したがこれに限らない。当該有効期間はＣＵが用いてもよい。当該有効期間は、ターゲットドナーノード２００－ＴのＣＵからソースドナーノード２００－ＳのＣＵにＸｎメッセージにより通知されてもよい。例えば、ソースドナーノード２００－ＳのＣＵは、当該条件付きＲＡＣＨレスハンドオーバの設定をＵＥ１００に対して行ったとき（もしくは、当該設定をターゲットドナーノード２００－ＴのＣＵから受信したとき）に、当該有効期間をセットしたタイマを起動する。ソースドナーノード２００－ＳのＣＵは、当該タイマが満了したとき（例えばタイマによるカウント値が有効期間に達したとき）、当該ＲＡＣＨレスハンドオーバの設定をＵＥ１００から解除（Ｒｅｍｏｖｅ）してもよい。
［その他の実施形態］
　上述の各動作フローは、別個独立に実施する場合に限らず、２以上の動作フローを組み合わせて実施可能である。例えば、１つの動作フローの一部のステップを他の動作フローに追加してもよいし、１つの動作フローの一部のステップを他の動作フローの一部のステップと置換してもよい。各フローにおいて、必ずしもすべてのステップを実行する必要は無く、一部のステップのみを実行してもよい。
　上述の実施形態及び実施例において、基地局がＮＲ基地局（ｇＮＢ）である一例について説明したが基地局がＬＴＥ基地局（ｅＮＢ）又は６Ｇ基地局であってもよい。また、基地局は、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ　Ａｃｃｅｓｓ　ａｎｄ　Ｂａｃｋｈａｕｌ）ノード等の中継ノードであってもよい。基地局は、ＩＡＢノードのＤＵであってもよい。また、ＵＥ１００は、ＩＡＢノードのＭＴ（Ｍｏｂｉｌｅ　Ｔｅｒｍｉｎａｔｉｏｎ）であってもよい。
　また、用語「ネットワークノード」は、主として基地局を意味するが、コアネットワークの装置又は基地局の一部（ＣＵ、ＤＵ、又はＲＵ）を意味してもよい。
　ＵＥ１００又はｇＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭ又はＤＶＤ－ＲＯＭ等の記録媒体であってもよい。
　また、ＵＥ１００又はｇＮＢ２００が行う各処理を実行する回路を集積化し、ＵＥ１００又はｇＮＢ２００の少なくとも一部を半導体集積回路（チップセット、ＳｏＣ：Ｓｙｓｔｅｍ　ｏｎ　ａ　ｃｈｉｐ）として構成してもよい。
　本開示で使用されている「に基づいて（ｂａｓｅｄ　ｏｎ）」、「に応じて（ｄｅｐｅｎｄｉｎｇ　ｏｎ／ｉｎ　ｒｅｓｐｏｎｓｅ　ｔｏ）」という記載は、別段に明記されていない限り、「のみに基づいて」、「のみに応じて」を意味しない。「に基づいて」という記載は、「のみに基づいて」及び「に少なくとも部分的に基づいて」の両方を意味する。同様に、「に応じて」という記載は、「のみに応じて」及び「に少なくとも部分的に応じて」の両方を意味する。「含む（ｉｎｃｌｕｄｅ）」、「備える（ｃｏｍｐｒｉｓｅ）」、及びそれらの変形の用語は、列挙する項目のみを含むことを意味せず、列挙する項目のみを含んでもよいし、列挙する項目に加えてさらなる項目を含んでもよいことを意味する。また、本開示において使用されている用語「又は（ｏｒ）」は、排他的論理和ではないことが意図される。さらに、本開示で使用されている「第１」、「第２」等の呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみがそこで採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。本開示において、例えば、英語でのａ，ａｎ，及びｔｈｅのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。
　以上、図面を参照して一実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。また、各実施形態、各動作例、又は各処理は、矛盾しない範囲で適宜組み合わせることも可能である。
　本願は、米国仮出願第６３／４１０７１０号（２０２２年９月２８日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
（第１付記）
　（付記１）
　セルラ通信システムで用いられる通信制御方法であって、
　分散装置（ＤＵ）が、ＲＡＣＨレスハンドオーバの際にユーザ装置において用いられるリソースに関するリソース情報を中央装置（ＣＵ）へ送信するステップと、
　前記中央装置が、前記リソース情報を含むハンドオーバコマンドを前記ユーザ装置へ送信するステップと、を有する
　通信制御方法。
　（付記２）
　前記中央装置が、前記リソースの確保を要求するリソース確保要求メッセージを前記分散装置へ送信するステップ、を更に有し、
　前記リソース情報を送信するステップは、前記分散装置が、前記リソース確保要求メッセージを受信したことに応じて、前記リソース情報を含むリソース情報メッセージを前記中央装置へ送信するステップを含む、
　付記１記載の通信制御方法。
　（付記３）
　前記中央装置はドナーノードに含まれ、前記分散装置は移動中継ノードに含まれる
　付記１又は付記２に記載の通信制御方法。
　（付記４）
　前記中央装置及び前記分散装置は、ネットワークノード（又はネットワーク装置）に含まれる
　付記１乃至付記３のいずれかに記載の通信制御方法。
　（付記５）
　前記ＲＡＣＨレスハンドオーバは、条件付きＲＡＣＨレスハンドオーバである
　付記１乃至付記４のいずれかに記載の通信制御方法。
　（付記６）
　セルラ通信システムで用いられる通信制御方法であって、
　中央装置（ＣＵ）が、条件付きＲＡＣＨレスハンドオーバの際にユーザ装置において用いられるリソースの有効期間を表す有効期間情報を分散装置（ＤＵ）へ送信する、及び、前記分散装置が、前記有効期間情報を前記中央装置へ送信することのいずれかを行うステップと、
　前記中央装置が、前記有効期間情報を含む条件付き再設定を前記ユーザ装置へ送信するステップと、を有する
　通信制御方法。
　（付記７）
　前記ユーザ装置が、前記有効期間が経過したとき、前記条件付き再設定を破棄し、前記有効期間が経過する前に、前記条件付き再設定で示されたトリガ条件を満たしたとき、ＲＡＣＨレスハンドオーバを実行するステップ、を更に有する
　付記６記載の通信制御方法。
（第２付記）
　導入
　移動ＩＡＢに関するＷＩＤはＲＡＮ＃９７ｅで改訂され、以下のような目的が示された。
　　ＷＩの詳細な目的は以下の通りである。
　・移動ＩＡＢノード全体のドナー間移動（完全移動）を含む、ＩＡＢノードのモビリティを実現するための移動／トポロジ適応の手順を定義する。
　　－移動ＩＡＢノードは、固定（中間）ＩＡＢノードに接続することができる。移動ＩＡＢノードが静止（中間）ＩＡＢノードに接続するシナリオ、又はＩＡＢドナーＤＵに直接接続するシナリオに特化した最適化は優先されない。
　　－デュアル接続されたＩＡＢノードのモビリティは優先順位が下がる。
　・グループモビリティに関連する面を含め、ＩＡＢノードとそのＵＥのモビリティを強化する。周囲のＵＥをターゲットとするための最適化はない。
　　注：ソリューションでは、Ｒｅｌ－１７で既に議論されたトピックや、Ｒｅｌ－１７から除外されたトピックに触れることは避けるべきであるが、ＩＡＢノードモビリティに特化した機能拡張は例外である。
　・潜在的な参照信号と制御信号の衝突（ＰＣＩ、ＲＡＣＨなど）の回避を含む、ＩＡＢノードモビリティによる干渉の緩和。
　　以下の原則を尊重すべきである。
　　－移動ＩＡＢノードはレガシーＵＥにサービスを提供できるべきである。
　　－移動ＩＡＢの最適化を提供するソリューションは、Ｒｅｌ－１８ＵＥの機能拡張を伴う可能性がある。
　Ｒｅｌ－１８における主要な課題の１つは、移動ＩＡＢノード間の移動中に、複数の子孫ＵＥのハンドオーバをいかに効率的に実行するかということである。この付記では、移動ＩＡＢのモビリティ強化の詳細について説明する。
　議論
　Ｒｅｌ－１８ＵＥのＲＡＣＨレスハンドオーバ
　ＲＡＮ２＃１１９ｅは以下の合意に達した。
　　Ｒ２は、移動ＩＡＢノードとともに引き渡されるオンボードＲＲＣ　ＣＯＮＮＥＣＴＥＤ　ＵＥについては、ＲＡＣＨレス手順が考慮される可能性があると仮定している（ＵＬ同期の仮定にも依存する）。
　ＬＴＥでは、ＲＡＣＨレスハンドオーバは、ＭｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏ内で、適用可能なタイミングアドバンス（ＴＡ）及びアップリンクグラント（ＵＬ）の情報を用いて、以下のように設定される。
　ＩＡＢノード移行時のＵＥのＲＡＣＨレスハンドオーバにおけるＴＡ値については、ソースセルとターゲットセルが同じ「物理」ＤＵ（ただし、デュアル「論理」ＤＵ）を介して提供されるため、ＵＥはターゲットセルにアクセスするために最新のＴＡ値を適用すると考えられる。つまり、ＵＥからの「物理」距離は同じである必要がある。したがって、ＵＥが明示的なＴＡ値を設定する必要はない。一方、ＲＡＣＨレスハンドオーバを他のシナリオ、例えば移動ＩＡＢ－ＭＴのハンドオーバに使用する場合は、ＬＴＥ設定のような汎用的なアプローチが必要になる。
　提案１：ＲＡＮ２は、ＵＥのＲＡＣＨレスハンドオーバについて、ＵＥが暗黙的に最新のＴＡ値を適用するか、明示的に該当するＴＡ値を設定するかについて議論すべきである。
　ＵＥはターゲットセルから与えられたＵＬリソース内でＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅを送信する必要があるため、ＵＬグラント情報をＵＥに設定する必要がある。
　提案２：ＲＡＮ２は、ＵＬグラント情報がターゲットＩＡＢドナーＣＵによって設定されることに、ＵＥのＲＡＣＨレスハンドオーバについて合意すべきである。
　ＮＲのＲＲＣ　ＩＥ構造を考慮すると、ＲＡＣＨレスハンドオーバはハンドオーバプロシージャ中にターゲットＩＡＢドナーＣＵによって示されるため、ＲＡＣＨレス設定はＣｅｌｌＧｒｏｕｐＣｏｎｆｉｇ内のｒｅｃｏｎｆｉｇｕｒａｔｉｏｎＷｉｔｈＳｙｎｃに含まれると仮定できる。
　提案３：ＲＡＮ２は、ＲＡＣＨレスハンドオーバがハンドオーバコマンド（同期を伴う再設定）で設定されることに合意すべきである。
　１つの疑問は、ＲＡＣＨレスハンドオーバが条件付きハンドオーバにも適用できるかどうかである。ＲＡＮ２＃１１９ｅは、「Ｒ２は、ＣＨＯ又は遅延ＲＲＣ設定がグループモビリティのベースラインとなり得ると仮定している」ため、条件付きＲＡＣＨレスハンドオーバをサポートすることが有用であると考えることに合意した。
　提案４：ＲＡＮ２は、ＲＡＣＨレスハンドオーバを条件付きハンドオーバ（条件付き再設定）でも設定できるかどうかを議論すべきである。
　レガシーＵＥのハンドオーバ手順
　ＲＡＮ２＃１１９ｅは以下の合意に達した。
　Ｒ２は、ＣＨＯ又は遅延ＲＲＣ設定（ｄｅｌａｙｅｄ　ＲＲＣ　ｃｏｎｆｉｇ）がグループモビリティのベースラインとなり得ると仮定している（ＩＡＢＭＴのモビリティに適用可能な場合については更なる検討が必要である）。
　ＷＩＤは、レガシーＵＥが移動ＩＡＢノードによって提供されるべきことを明確にしている。
　以下の原則を尊重すべきである。
　－移動ＩＡＢノードはレガシーＵＥにサービスを提供できるべきである。
　－移動ＩＡＢの最適化を提供するソリューションは、Ｒｅｌ－１８ＵＥの機能拡張を伴う可能性がある。
　条件付きハンドオーバ（ＣＨＯ：Ｃｏｎｄｉｔｉｏｎａｌ　Ｈａｎｄｏｖｅｒ）がＲｅｌ－１６で導入されたため、Ｒｅｌ－１５ＵＥは条件付き再設定機能をサポートしていない。そのため、ＣＨＯを移動ＩＡＢノード移行時のグループモビリティのベースラインとすることはできない。従来のハンドオーバコマンドをベースラインとし、ＣＨＯはＲｅｌ－１６以降のＵＥの効率的なグループモビリティのために何らかの機能拡張を提供すべきである。
　所見１：条件付きハンドオーバはＲｅｌ－１６で導入されたが、移動ＩＡＢノードもＲｅｌ－１５ＵＥに対応すべきである。そのため、従来のハンドオーバコマンドは、Ｒｅｌ－１５ＵＥのモビリティを制御する唯一の方法である。
　従来のハンドオーバコマンドに関しては、ＲＡＮ２は「ｄｅｌａｙｅｄ　ＲＲＣ　ｃｏｎｆｉｇ」を候補の１つとして合意した。ただし、この「ｄｅｌａｙｅｄＲＲＣｃｏｎｆｉｇ」が、Ｒｅｌ－１７で規定されたＲＲＣ再設定メッセージの保留／条件付き配信、つまりソリューション１と同じものを意図しているかどうかは明確ではない。保留／条件付き配信であれば、Ｒｅｌ－１５ＵＥを含むレガシーＵＥで動作する。そうでない場合、意図するソリューション（複数可）によっては動作しない可能性がある。そのため、ＲＡＮ２は「遅延ＲＲＣ設定（ｄｅｌａｙｅｄ　ＲＲＣ　ｃｏｎｆｉｇ）」が何を意図しているのかを明確にする必要がある。
　提案５：ＲＡＮ２は、Ｒｅｌ－１７で規定されているＲＲＣメッセージの保留／条件付き配信と、前回会合で合意した「ｄｅｌａｙｅｄ　ＲＲＣ　ｃｏｎｆｉｇ」が同じかどうかを明確にすべきである。
　ＲＡＮ２＃１１９ｅは、以下の論点を支持した。
　　Ｐ３：完全移行を行う「ｄｕａｌ－ＤＵ－ｗａｙ」に関して、ＲＡＮ２は、レガシーＵＥが２つの論理セル／ＤＵを別個の物理セルと見なすべきか、同じ物理セルと見なすべきか、またどちらの場合にレガシーＵＥがどのような手順を実行する必要があるかについて議論することができる。
　同じＰＣＩへのハンドオーバはシグナリングの観点からは可能かもしれないが、ＵＥが何らかのエラーを起こすリスクがあるかどうかについては不明である。
　さらに、ＣＨＯがＲｅｌ－１６ＵＥに使用される場合、つまりＡ３／Ａ５ベースのトリガしかない場合、これらのＰＣＩが同じであれば、ＵＥはソースセルからのＲＳＲＰとターゲットセルからのＲＳＲＰが同じであると認識する可能性があるため、条件を満たすことはできない。
　また、移動ＩＡＢノードの移行中にＰＣＩを変更する必要がある場合、つまりＰＣＩ衝突を回避するためには、ターゲットセルのＰＣＩはソースセルのＰＣＩと異なる必要がある。
　つまり、ソースセルとターゲットセルが「物理的に」同じＩＡＢノードから提供されていたとしても、ＰＣＩは異なる。
　提案６：ＲＡＮ２は、２つの論理セル／ＤＵが異なるＰＣＩを持つと仮定すべきである。
　Ｒｅｌ－１８ＵＥのセル再選択
　ＲＡＮ２＃１１９ｅは、以下の論点を支持した。
　　Ｐ１：ＲＡＮ２は、例えば移動ＩＡＢノードのブロードキャストパラメータに基づいて、移動ＩＡＢノードとの間でセル（再）選択を強化するシナリオについて議論する。
　２つの主要なシナリオといくつかのサブケースは以下のように考えられる。
　・シナリオＡ：移動ＩＡＢノードがキャンプＵＥと共に移動している。
　　・サブケースＡ１：ＵＥ（電車など）は移動ＩＡＢノードに留まる必要がある。
　　・サブケースＡ２：周囲のＵＥ（電車の外側など）は、移動ＩＡＢノード上でキャンプしてはならない。
　・シナリオＢ：移動ＩＡＢノードがキャンプ中のＵＥと一緒に停車している。
　　・サブケースＢ１：ＵＥ（例えば、まだ電車に乗っている）は移動ＩＡＢノードに留まる。
　　・サブケースＢ２：ＵＥ（たとえば、電車を降りる）は、固定セル（たとえば、マクロセル）を再選択する必要がある。
　　・サブケースＢ３：周囲のＵＥ（たとえば、電車に乗る）は、移動ＩＡＢノードを再選択する必要があります。
　　・サブケースＢ４：周囲のＵＥ（たとえば、まだ駅にいる）は、固定セルに留まるべきである。
　サブケースＡ２、Ｂ３、及びＢ４は、周囲のＵＥに望ましい動作である。ただし、ＷＩＤには、周囲のＵＥをターゲットとする最適化がないことが明記されている。サブケースＢ３については、ＵＥが電車に乗った後にサブケースＢ１又はＢ２になるが、ＵＥの初期状態は周囲のＵＥのままである。したがって、これらのサブケースは対象外である。
　グループモビリティに関連する面を含め、ＩＡＢ－ノードとそのＵＥのモビリティを強化する。周囲のＵＥをターゲットとするための最適化はない。
　所見２：周囲のＵＥをターゲットにした最適化は、ＷＩの範囲外である。
　サブケースＡ１では、ＵＥは移動ＩＡＢノードと一緒に移動する。そのため、移動ＩＡＢノードからのＲＳＲＰ及びＲＳＲＱは常に安定しており、十分に良好である。例えば、移動ＩＡＢノードが自ノードの周波数の優先度を「７」とブロードキャストするか、又は自ノードのセルをＨＳＤＮセルとしてブロードキャストする場合などである。
　また、列車には複数の車両があり、移動ＩＡＢノードは各車両に配備されていると考えることもできる。ＵＥが車両間を移動する場合でも、列車内のＵＥから見て、移動ＩＡＢノードのセルの１つは、外部のマクロセルよりも常に安定している。さらに、典型的なケースとして、移動ＩＡＢノードセルが同じ周波数で動作していると仮定する。この場合、既存の周波数内セル再選択、すなわちＲ基準は適切に機能する。
　そのため、既存の無線状態に基づくセル再選択はうまく機能し、例えば、いくつかのブロードキャスト情報を使って拡張する必要はない。
　所見３：ＩＡＢノードとともに移動するＵＥは、既存の無線条件ベースのセル再選択と適切な周波数優先順位に基づいて、ＩＡＢノードに留まることができる。
　サブケースＢ１及びＢ２の場合、ユーザが列車に留まるか、列車から離脱するかをＡＳが把握する方法はない。この場合、たとえ移動ＩＡＢノードが何らかの情報をブロードキャストしたとしても、ＵＥは最後にどちらのセル（移動ＩＡＢノード又は固定マクロセル）を再選択すべきかを決定することはできない。そのため、ＵＥがどのセルに再選択すべきであるかは、最終的には無線条件と周波数の優先順位による。
　所見４：ＵＥと移動ＩＡＢノードが停止した場合、ＵＥがユーザの意図を把握していない限り、ＵＥは移動ＩＡＢノードを再選択すべきかどうかを判断できない。
　要約すると、既存のセル再選択メカニズム、つまり無線条件と周波数優先度に基づくセル再選択メカニズムは、依然としてうまく機能する。そのため、ＵＥがセル再選択を実行するための機能拡張は必要ない。
　ＨＳＤＮは、仕様を変更することなく移動ＩＡＢノードでサポートできるため、サブケースＡ１に有用である。
　提案７：ＲＡＮ２は、ＵＥが移動ＩＡＢノードとの間でセル再選択を実行するための機能拡張は必要ないことに合意すべきである。
　移動ＩＡＢノード表示
　ＲＡＮ２＃１１９ｅは、以下の論点を支持した。
　　Ｐ２：移動ＩＡＢ－ＭＴがＩＡＢドナーＣＵに移動ＩＡＢ　ｉｎｄｉｃａｔｉｏｎ（能力（Ｃａｐａｂｉｌｉｔｙ）又はモビリティ）を送信する必要があるかどうかを議論できる。
　ＲＡＮ３＃１１７ｅでは、以下の合意がなされた。
　　ドナーＣＵは、ＩＡＢノードが「移動可能（ｍｏｂｉｌｅ）」であることを把握するべきである。
　Ｒｅｌ－１６ＩＡＢでは、ＩＡＢ　Ｎｏｄｅ　ＩｎｄｉｃａｔｉｏｎはＭｓｇ５を介して送信され、これは提供者がＩＡＢをサポートするＡＭＦを選択するために使用することを目的としている。したがって、提供者が移動ＩＡＢをサポートするＡＭＦを選択する必要があるかどうかに応じて、移動ＩＡＢ　Ｎｏｄｅ　ＩｎｄｉｃａｔｉｏｎをＭｓｇ５経由で送信するかどうかについてはポイントの１つであり、これはＲＡＮ３次第である。
　ＩｍｍｅｄｉａｔｅＭＤＴのような既存の測定レポートを通じて、ドナーＣＵがリアルタイムのモビリティ状態を取得できることが指摘されている。このような移動状態情報は、予測的な移動制御に有用であると考えられる。報告者は、移動ＩＡＢノード表示は、提供者が移動ＩＡＢノードを適切な測定設定で設定するために必要であることを明らかにした。
　したがって、少なくともＡＳの観点からは、移動ＩＡＢノード表示はＩＡＢ－ＭＴによって送信されるべきである。しかし、このような表示をＭｓｇ５で送信する必要があるのか、Ｃａｐａｂｉｌｉｔｙシグナリングで送信する必要があるのかは不明であり、ＲＡＮ３次第である。
　提案８：ＲＡＮ２は、移動ＩＡＢノード表示がＲＲＣメッセージで送信されることに合意すべきである。ＲＲＣメッセージがＭｓｇ５であるかＣａｐａｂｉｌｉｔｙシグナリングであるかはＲＡＮ３次第である。
　移動ＩＡＢノードのアクセス制限
　ＷＩＤでは、移動ＩＡＢ－ノードはＵＥにしかサービスを提供しないとされている。
　－移動ＩＡＢノードは、子孫ＩＡＢノードを持たず、ＵＥのみにサービスを提供する。
　この要件を確保するため、ＲＡＮ２＃１１９ｅは以下のとおり合意した。
　－ＩＡＢサポート表示をブロードキャストしない方法は、他のＩＡＢノードが移動ＩＡＢにアクセスするのを防ぐのに十分である（それ以上の仕様上の影響はない）。
　「（それ以上の仕様上の影響はない）」の部分については、実装に委ねるだけで本当に十分なのか疑問である。ＷＩＤでは、移動ＩＡＢノードが他の移動ＩＡＢノードにアクセスできないことが明確に要求されているため、移動ＩＡＢの実装における混乱を避けるために、仕様でこの前提を明確にする必要があると考えられる。そのため、Ｓｔａｇｅ－２仕様では、上記の合意を取り入れるか、「移動ＩＡＢノードは、このリリースでは他の移動ＩＡＢノードにアクセスできない」と明確にすることが望ましい。
　提案９：ＲＡＮ２は、本リリースにおいてＩＡＢノードが移動ＩＡＢノードとして動作する場合、ＳＩＢにＩＡＢサポートＩＥを設定しないことをＳｔａｇｅ－２仕様に盛り込むことに合意すべきである。
　導入
　移動ＩＡＢに関するＷＩＤはＲＡＮ＃９７ｅで改訂され、以下のような目的が示された。
　ＷＩの詳細な目的は以下の通りである。
　・移動ＩＡＢノード全体のドナー間移動（完全移動）を含む、ＩＡＢノードのモビリティを実現するための移動／トポロジ適応の手順を定義する。
　　－移動ＩＡＢノードは、固定（中間）ＩＡＢノードに接続することができる。移動ＩＡＢノードが静止（中間）ＩＡＢノードに接続するシナリオ、又はＩＡＢドナー－ＤＵに直接接続するシナリオに特化した最適化は優先されない。
　　－デュアル接続されたＩＡＢノードのモビリティは優先順位が下がる。
　・グループモビリティに関連する面を含め、ＩＡＢノードとそのＵＥのモビリティを強化する。周囲のＵＥをターゲットとするための最適化はない。
　　注：ソリューションでは、Ｒｅｌ－１７で既に議論されたトピックや、Ｒｅｌ－１７から除外されたトピックに触れることは避けるべきであるが、ＩＡＢノードモビリティに特化した機能拡張は例外である。
　・潜在的な参照信号と制御信号の衝突（ＰＣＩ、ＲＡＣＨなど）の回避を含む、ＩＡＢノードモビリティによる干渉の緩和。
　　以下の原則を尊重すべきである。
　　－移動ＩＡＢノードはレガシーＵＥにサービスを提供できるべきである。
　　－移動ＩＡＢの最適化を提供するソリューションは、Ｒｅｌ－１８ＵＥの機能拡張を伴う可能性がある。
　その目的の１つは、ＩＡＢノードのモビリティによる干渉の緩和である。この付記では、ＰＣＩ衝突とＲＡＣＨ設定の衝突に関する潜在的な問題について議論する。
　議論
　動的なＰＣＩ変更メカニズム（Ｄｙｎａｍｉｃ　ＰＣＩ　ｃｈａｎｇｅ　ｍｅｃｈａｎｉｓｍ）
　ＲＡＮ２＃１１９ｅは、以下の論点を支持した。
　　Ｐ４：ＲＡＮ２は、Ｒ２スコープ内で見つかった場合、（適用シナリオで使用するために）対処する必要がある／対処できるＰＣＩパーティショニングの問題があるかどうかを議論してもよい。Ｒ２の観点から、動的ＰＣＩ変更メカニズムの必要性と実現可能性について議論してもよい。また、ＰＣＩ衝突検出を改善するために、現在のＵＥ／ＭＴ報告に対する機能強化が有用か、必要かについても議論する。
　ＰＣＩ衝突の２つのシナリオは以下のように考えられる。
　・シナリオ１：移動ＩＡＢノードのＰＣＩが隣接セルに衝突する。
　・シナリオ２：同じターゲットドナーに移動した２つの移動ＩＡＢノードのＰＣＩ同士が衝突する。
　シナリオ１では、固定セル（マクロセルなど）用のＰＣＩスペースと移動ＩＡＢ－ノード用のＰＣＩスペースが分離されていれば、既存のＰＣＩパーティショニングが機能する場合もある。しかし、スモールセルが多いエリアではＰＣＩが不足するなど、ＰＣＩスペースが小さいと問題になるケースもある。
　シナリオ２では、ＰＣＩパーティショニングを使用する場合、移動ＩＡＢノードのＰＣＩスペースはさらに分離されるか、あるいはグローバルＰＣＩ（すなわちＰＬＭＮでは再利用不可）を各ＩＡＢノードに割り当てる必要があるかもしれない。ＰＣＩの数に限りがあることを考慮すると、ＰＣＩパーティショニングは現実的な解決策ではない。
　特にシナリオ２では、動的（ｄｙｎａｍｉｃ）なＰＣＩ変更メカニズムが必要となる。
　提案１：ＲＡＮ２は、特に２つのモバイルＩＡＢノード間でＰＣＩが衝突した場合に、動的なＰＣＩ変更メカニズムが必要であることに合意すべきである。
　ＰＣＩ衝突の回避には、ＩＡＢ－ＭＴ測定、ＵＥ報告、及びネットワーク調整の３つのアプローチが考えられる。
　ＩＡＢ－ＭＴ測定では、移動ＩＡＢノードが隣接セルから同じＰＣＩを検出した場合、移動ＩＡＢノードが自身のＰＣＩを変更すると考えられる。しかし、ＩＡＢ－ＭＴが同じＰＣＩを検出した時点で、すでにＰＣＩの衝突が発生していることになる。
　ＵＥ報告では、ＵＥが異なるセルから同じＰＣＩを検出して報告した場合、ドナーは移動ＩＡＢノードにＰＣＩを変更するよう要求すると考えられる。しかし、異なるセルが同じＰＣＩを使用しているかどうかをＵＥが判断できるかどうかは疑問である。同様に、ＵＥが同じＰＣＩを検出した時点で、すでにＰＣＩの衝突が発生している可能性もある。
　ネットワーク調整では、移動ＩＡＢノードの移行中に、ソースドナーがターゲットドナーに、移行する移動ＩＡＢノードが使用するＰＣＩが許容可能かどうかを問い合わせると考えられる。さらに、ターゲットドナーは、将来のＰＣＩ衝突を回避するために、例えば、ターゲットドナーの近隣にある別の移動ＩＡＢノードが同じＰＣＩを使用しているかどうかなど、近隣のｇＮＢに同じことを尋ねることが考えられる。このアプローチでは、事前にＰＣＩの衝突を回避することができる。したがって、ＲＡＮ２は、動的なＰＣＩ変更は移動ＩＡＢノードの移動中にのみ発生するものと考えるべきであり、ＲＡＮ２から見て拡張はない。ＲＡＮ３が移動ＩＡＢノードの移行中にどのようにＰＣＩ衝突を回避し、変更するかについてはＲＡＮ３次第である。
　提案２：ＲＡＮ２は、動的なＰＣＩの変更はＩＡＢノードの移行手順中にのみ発生し、ＰＣＩの衝突はネットワークの調整によって解決されると仮定する必要がある。ＰＣＩ衝突をどのように回避するかについてはＲＡＮ３次第であり、ＲＡＮ２次第ではない。
　ＲＡＣＨ設定の衝突
　ＲＡＮ２＃１１９ｅは以下の論点を支持した。
　　Ｐ５：ＲＡＮ２は、ＲＡＮ２の観点から移動ＩＡＢと固定ネットワーク間のＲＡＣＨ設定の衝突の問題があるかどうか、及び／又はＲＡＮ２がＲＡＮ１にＲＡＮ１関連の側面を検討するよう依頼すべきかどうかを議論することができる。
　近接する２つのセルで同じＰＲＡＣＨ設定が使用されている場合、ＰＲＡＣＨの衝突率が増加するという問題が発生する可能性がある。さらに、誤ったＲＡＲもリスクとなる可能性がある。ＵＥがセルＡにＰＲＡＣＨを送信しているにもかかわらず、セルＢでも受信され、ＵＥがセルＢからＲＡＲを受信してしまう場合などである。ＲＡＮ２がこれらの可能性のある問題を特定した場合、ＲＡＮ２はＲＡＮ１に詳細の分析を依頼する必要がある。
　所見１：ＲＡＮ１は、ＲＡＣＨ設定の衝突問題を分析するのに適したグループである。

Claims (7)

  1. 　セルラ通信システムで用いられる通信制御方法であって、
    　分散装置（ＤＵ）が、ＲＡＣＨ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｃｈａｎｎｅｌ）レスハンドオーバの際にユーザ装置において用いられるリソースに関するリソース情報を中央装置（ＣＵ）へ送信することと、
    　前記中央装置が、前記リソース情報を含むハンドオーバコマンドを前記ユーザ装置へ送信することと、を有する
    　通信制御方法。
  2. 　前記中央装置が、前記リソースの確保を要求するリソース確保要求メッセージを前記分散装置へ送信すること、を更に有し、
    　前記リソース情報を送信することは、前記分散装置が、前記リソース確保要求メッセージを受信したことに応じて、前記リソース情報を含むリソース情報メッセージを前記中央装置へ送信することを含む、
    　請求項１記載の通信制御方法。
  3. 　前記中央装置はドナーノードに含まれ、前記分散装置は移動中継ノードに含まれる
    　請求項１記載の通信制御方法。
  4. 　前記中央装置及び前記分散装置は、ネットワークノードに含まれる
    　請求項１記載の通信制御方法。
  5. 　前記ＲＡＣＨレスハンドオーバは、条件付きＲＡＣＨレスハンドオーバである
    　請求項１記載の通信制御方法。
  6. 　セルラ通信システムで用いられる通信制御方法であって、
    　中央装置（ＣＵ）が、条件付きＲＡＣＨ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｃｈａｎｎｅｌ）レスハンドオーバの際にユーザ装置において用いられるリソースの有効期間を表す有効期間情報を分散装置（ＤＵ）へ送信する、及び、前記分散装置が、前記有効期間情報を前記中央装置へ送信することのいずれかを行うことと、
    　前記中央装置が、前記有効期間情報を含む条件付き再設定を前記ユーザ装置へ送信することと、を有する
    　通信制御方法。
  7. 　前記ユーザ装置が、前記有効期間が経過したとき、前記条件付き再設定を破棄し、前記有効期間が経過する前に、前記条件付き再設定で示されたトリガ条件を満たしたとき、ＲＡＣＨレスハンドオーバを実行すること、を更に有する
    　請求項６記載の通信制御方法。
PCT/JP2023/034429 2022-09-28 2023-09-22 通信制御方法 WO2024070923A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202263410710P 2022-09-28 2022-09-28
US63/410,710 2022-09-28

Publications (1)

Publication Number Publication Date
WO2024070923A1 true WO2024070923A1 (ja) 2024-04-04

Family

ID=90477738

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/034429 WO2024070923A1 (ja) 2022-09-28 2023-09-22 通信制御方法

Country Status (1)

Country Link
WO (1) WO2024070923A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017130852A1 (ja) * 2016-01-25 2017-08-03 京セラ株式会社 無線端末及び基地局
JP2019534632A (ja) * 2016-10-07 2019-11-28 テレフオンアクチーボラゲット エルエム エリクソン（パブル） Ｒａｃｈレスハンドオーバ中のターゲットセルにおけるアップリンクグラントの有効時間の制御

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017130852A1 (ja) * 2016-01-25 2017-08-03 京セラ株式会社 無線端末及び基地局
JP2019534632A (ja) * 2016-10-07 2019-11-28 テレフオンアクチーボラゲット エルエム エリクソン（パブル） Ｒａｃｈレスハンドオーバ中のターゲットセルにおけるアップリンクグラントの有効時間の制御

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
KYOCERA: "Mobility enhancements for mobile IAB", 3GPP TSG RAN WG2 #119BIS-E R2-2210429, 30 September 2022 (2022-09-30), XP052263748 *
KYOCERA: "UE handover aspects for mobile IAB", 3GPP TSG RAN WG2 #119-E R2-2208292, 10 August 2022 (2022-08-10), XP052261603 *

Similar Documents

Publication Publication Date Title
US10757618B2 (en) Method and apparatus for performing handover
US10674521B2 (en) Method and apparatus for transmitting and receiving data in wireless communication system
JP6502582B2 (ja) 基地局及びユーザ端末
US10149221B2 (en) Method and apparatus for performing operation related to radio link failure in a heterogeneous network
KR101521892B1 (ko) 무선통신 시스템에서 핸드오버 장치 및 방법
KR102219227B1 (ko) 무선 통신 시스템에서 스몰 셀에 대하여 데이터를 전달하기 위한 방법 및 장치
EP3133864B1 (en) Method and system for controlling access of csg in dual-connection architecture
US10616927B2 (en) Method by which terminal transmits V2X signal in wireless communication system, and terminal using method
JP2023062171A (ja) 中継装置
US20120252355A1 (en) Apparatus and method for handing over relays
JP6800841B2 (ja) 基地局及び無線端末
US20130016648A1 (en) Connectivity Setup For Dynamic Wireless Mesh Networks
WO2020057294A1 (en) Method and apparatus for mobility optimization
CN112867027A (zh) 用于已连接用户设备的链路管理
US20180376530A1 (en) Radio terminal and base station
JP6371008B2 (ja) 通信方法、セルラ基地局及び無線ｌａｎ終端ノード
CN116671178A (zh) 在sl中继情况下的失败监视和恢复机制
WO2024070923A1 (ja) 通信制御方法
KR20240036073A (ko) 경로 전환 및 핸드오버를 처리하기 위한 단말 장치, 네트워크 노드 및 그 방법
US20220287126A1 (en) Sidelink transmission continuity
WO2024096053A1 (ja) 通信制御方法
WO2016072465A1 (ja) 基地局及びプロセッサ
WO2024096052A1 (ja) 通信制御方法
JP7453479B2 (ja) 通信制御方法
WO2024029520A1 (ja) 通信制御方法

Legal Events

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

Ref document number: 23872149

Country of ref document: EP

Kind code of ref document: A1