WO2022030578A1 - 通信制御方法 - Google Patents

通信制御方法 Download PDF

Info

Publication number
WO2022030578A1
WO2022030578A1 PCT/JP2021/029108 JP2021029108W WO2022030578A1 WO 2022030578 A1 WO2022030578 A1 WO 2022030578A1 JP 2021029108 W JP2021029108 W JP 2021029108W WO 2022030578 A1 WO2022030578 A1 WO 2022030578A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
relay
iab
base station
donor
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/JP2021/029108
Other languages
English (en)
French (fr)
Inventor
真人 藤代
ヘンリー チャン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kyocera Corp
Original Assignee
Kyocera Corp
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 Kyocera Corp filed Critical Kyocera Corp
Priority to CN202510461340.2A priority Critical patent/CN120282237A/zh
Priority to JP2022541725A priority patent/JP7328458B2/ja
Priority to EP21853606.8A priority patent/EP4178246B1/en
Priority to CN202180068277.6A priority patent/CN116325849A/zh
Publication of WO2022030578A1 publication Critical patent/WO2022030578A1/ja
Priority to US18/164,242 priority patent/US12574986B2/en
Anticipated expiration legal-status Critical
Priority to JP2023127002A priority patent/JP7594637B2/ja
Priority to JP2024204065A priority patent/JP7814477B2/ja
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/18—Management of setup rejection or failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/22—Communication route or path selection, e.g. power-based or shortest path routing using selective relaying for reaching a BTS [Base Transceiver Station] or an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/08—Reselecting an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/27—Transitions between radio resource control [RRC] states
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/02—Buffering or recovering information during reselection ; Modification of the traffic flow during hand-off
    • H04W36/023—Buffering or recovering information during reselection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/19—Connection re-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/22—Manipulation of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/04—Terminal devices adapted for relaying to or from another terminal or user

Definitions

  • the present disclosure relates to a communication control method used in a cellular communication system.
  • a new relay node called an IAB (Integrated Access and Backhaul) node is defined (for example, "3GPP TS 38.300 V16.2.0”. (2020-07) ”).
  • IAB Integrated Access and Backhaul
  • One or more relay nodes intervene in the communication between the base station and the user device, and relay the communication.
  • the communication control method is a communication control method used in a cellular communication system, in which a relay node that relays data from a relay source node to a plurality of relay destination nodes is set by a routing setting from a donor base station. Select a data relay destination from the plurality of relay destination nodes according to the above, and when the relay node satisfies a predetermined condition, execute local routing to select the data relay destination without following the routing setting. To do and have.
  • the predetermined condition includes a condition that a failure occurrence notification is received from any of the plurality of relay destination nodes.
  • the communication control method is a communication control method used in a cellular communication system, in which a relay node having a user device under its control switches the connection from the first donor base station to the second donor base station. That is, even if the connection is switched, the RRC (Radio Resource Control) connection between the user device and the first donor base station is continued via the second donor base station, and the first donor is continued.
  • the base station uses the RRC connection to transmit a handover command instructing a handover to the second donor base station to the user apparatus via the second donor base station.
  • the communication control method is a communication control method used in a cellular communication system, and the plurality of relay destination nodes include a relay node that relays data from a relay source node to a plurality of relay destination nodes. It has capacity information regarding the data relay capacity of the target relay node from the target relay node, and the relay node controls the data relay based on the capacity information.
  • the communication control method is a communication control method used in a cellular communication system, in which a relay node that relays data from a relay source node to a plurality of relay destination nodes is set by a routing setting from a donor base station. Accordingly, the data relay destination is selected from the plurality of relay destination nodes, and the relay node transmits a routing change request for changing the routing setting to the donor base station.
  • the communication control method is a communication control method used in a cellular communication system, in which a relay node that relays data from a relay source node to a plurality of relay destination nodes is set by a routing setting from a donor base station.
  • the data relay destination is selected from the plurality of relay destination nodes, and when the relay node meets the predetermined conditions, the local routing that selects the data relay destination without following the routing setting is performed. It has the execution and the transmission of historical information about the local routing to the donor base station.
  • FIG. 1 is a diagram showing a configuration of a cellular communication system 1 according to an embodiment.
  • Cellular communication system 1 is a 5th generation (5G) cellular communication system based on the 3GPP standard. Specifically, the wireless access system in the cellular communication system 1 is NR (New Radio), which is a 5G wireless access system. However, LTE (Long Term Evolution) may be applied to the cellular communication system 1 at least partially.
  • 5G 5th generation
  • NR New Radio
  • LTE Long Term Evolution
  • the cellular communication system 1 has a 5G core network (5GC) 10, a user device (UE: User Equipment) 100, a base station (called gNB) 200, and an IAB node 300.
  • the IAB node 300 is an example of a relay node.
  • the base station is an NR base station
  • the base station may be an LTE base station (that is, eNB).
  • the 5GC10 has an AMF (Access and Mobility Management Function) 11 and an UPF (User Plane Function) 12.
  • the AMF 11 is a device that performs various mobility controls and the like for the UE 100.
  • the AMF 11 manages information on the area in which the UE 100 is located by communicating with the UE 100 using NAS (Non-Access Stratum) signaling.
  • the UPF 12 is a device that controls the transfer of user data and the like.
  • Each gNB 200 is a fixed wireless communication node and manages one or a plurality of cells.
  • Cell is used as a term to indicate the smallest unit of wireless communication area.
  • Cell may be used as a term to indicate a function or resource for wireless communication with the UE 100.
  • One cell belongs to one carrier frequency.
  • Each gNB200 is interconnected with the 5GC10 via an interface called an NG interface.
  • FIG. 1 illustrates two gNB200-1 and gNB200-2 connected to 5GC10.
  • Each gNB200 is interconnected with other gNB200s in an adjacent relationship via an inter-base station interface called an Xn interface.
  • FIG. 1 shows an example in which gNB200-1 is connected to gNB200-2.
  • Each gNB 200 may be divided into an aggregate unit (CU: Central Unit) and a distributed unit (DU: Distributed Unit).
  • the CU and DU are connected to each other via an interface called an F1 interface.
  • the F1 protocol is a communication protocol between the CU and the DU, and includes the F1-C protocol, which is a control plane protocol, and the F1-U protocol, which is a user plane protocol.
  • the cellular communication system 1 supports IAB that enables wireless relay of NR access by using NR in the backhaul.
  • the donor gNB200-1 is a terminal node of the NR backhaul on the network side and is a donor base station having an additional function to support IAB.
  • the backhaul can be multi-hop through multiple hops (ie, multiple IAB nodes 300).
  • FIG. 1 an example in which the IAB node 300-1 wirelessly connects to the donor gNB200-1, the IAB node 300-2 wirelessly connects to the IAB node 300-1, and the F1 protocol is transmitted in two backhaul hops. Is shown.
  • the UE 100 is a mobile wireless communication device that performs wireless communication with a cell.
  • the UE 100 may be any device as long as it is a device that performs wireless communication with the gNB 200 or the IAB node 300.
  • the UE 100 is a mobile phone terminal, a tablet terminal, a notebook PC, a sensor, a device provided in the sensor, a vehicle, or a device provided in the vehicle.
  • the UE 100 wirelessly connects to the IAB node 300 or gNB 200 via an access link.
  • FIG. 1 shows an example in which the UE 100 is wirelessly connected to the IAB node 300-2.
  • the UE 100 indirectly communicates with the donor gNB200-1 via the IAB node 300-2 and the IAB node 300-1.
  • FIG. 2 is a diagram showing the relationship between the IAB node 300, the parent node (Parent nodes), and the child node (Child nodes).
  • each IAB node 300 has an IAB-DU corresponding to a base station functional unit and an IAB-MT (Mobile Termination) corresponding to a user equipment functional unit.
  • IAB-DU corresponding to a base station functional unit
  • IAB-MT Mobile Termination
  • the adjacent node (that is, 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 gNB200.
  • the radio link between the IAB-MT and the parent node is called a backhaul link (BH link).
  • FIG. 2 shows an example in which the parent nodes of the IAB node 300 are the IAB nodes 300P1 and 300P2. The direction toward the parent node is called upstream. Seen from the UE 100, the upper node of the UE 100 may correspond to the parent node.
  • the adjacent node (that is, the lower node) on the NR access interface of the IAB-DU is called a child node.
  • the IAB-DU manages the cell in the same manner as the gNB200.
  • 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 donor gNB200-1.
  • FIG. 2 shows an example in which the child nodes of the IAB node 300 are the IAB nodes 300C1 to 300C3, the UE 100 may be included in the child nodes of the IAB node 300.
  • the direction toward the child node is called downstream.
  • FIG. 3 is a diagram showing the configuration of gNB 200.
  • the gNB 200 has a wireless communication unit 210, a network communication unit 220, and a control unit 230.
  • the wireless communication unit 210 performs wireless communication with the UE 100 and wireless communication with the IAB node 300.
  • the wireless communication unit 210 has a reception unit 211 and a transmission unit 212.
  • the receiving unit 211 performs various receptions under the control of the control unit 230.
  • the receiving unit 211 includes an antenna, converts the radio signal received by the antenna into a baseband signal (received signal), and outputs the radio signal to the control unit 230.
  • the transmission unit 212 performs various transmissions under the control of the control unit 230.
  • the transmission unit 212 includes an antenna, converts a baseband signal (transmission signal) output by the control unit 230 into a radio signal, and transmits the baseband signal (transmission signal) from the antenna.
  • the network communication unit 220 performs wired communication (or wireless communication) with 5GC10 and wired communication (or wireless communication) with other adjacent gNB200.
  • the network communication unit 220 has a reception unit 221 and a transmission unit 222.
  • the receiving unit 221 performs various types of reception under the control of the control unit 230.
  • the receiving unit 221 receives a signal from the outside and outputs the received signal to the control unit 230.
  • the transmission unit 222 performs various transmissions under the control of the control unit 230.
  • the transmission unit 222 transmits the transmission signal output by the control unit 230 to the outside.
  • the control unit 230 performs various controls on the gNB 200.
  • the control unit 230 includes at least one memory and at least one processor electrically connected to the memory.
  • the memory stores a program executed by the processor and information used for processing by the processor.
  • the processor may include a baseband processor and a CPU (Central Processing Unit).
  • the baseband processor modulates / demodulates and encodes / decodes the baseband signal.
  • the CPU executes a program stored in the memory to perform various processes.
  • the processor performs processing of each layer described later.
  • FIG. 4 is a diagram showing 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 (BH link) with the gNB 200 and wireless communication (access link) with the UE 100.
  • the wireless communication unit 310 for BH link communication and the wireless communication unit 310 for access link communication may be provided separately.
  • the wireless communication unit 310 has a receiving unit 311 and a transmitting unit 312.
  • the receiving unit 311 performs various receptions under the control of the control unit 320.
  • the receiving unit 311 includes an antenna, converts the radio signal received by the antenna into a baseband signal (received signal), and outputs the radio signal to the control unit 320.
  • the transmission unit 312 performs various transmissions under the control of the control unit 320.
  • the transmission unit 312 includes an antenna, converts a baseband signal (transmission signal) output by the control unit 320 into a radio signal, and transmits the baseband signal (transmission signal) from the antenna.
  • the control unit 320 performs various controls on the IAB node 300.
  • the control unit 320 includes at least one memory and at least one processor electrically connected to the memory.
  • the memory stores a program executed by the processor and information used for processing by the processor.
  • the processor may include a baseband processor and a CPU.
  • the baseband processor modulates / demodulates and encodes / decodes the baseband signal.
  • the CPU executes a program stored in the memory to perform various processes.
  • the processor performs processing of each layer described later.
  • FIG. 5 is a diagram showing the configuration of the UE 100. As shown in FIG. 5, the UE 100 has a wireless communication unit 110 and a control unit 120.
  • the wireless communication unit 110 performs wireless communication on the access link, that is, wireless communication with the gNB 200 and wireless communication with the IAB node 300. Further, the wireless communication unit 110 may perform wireless communication on the side link, that is, wireless communication with another UE 100.
  • the wireless communication unit 110 has a reception unit 111 and a transmission unit 112.
  • the receiving unit 111 performs various types of reception under the control of the control unit 120.
  • the receiving unit 111 includes an antenna, converts the radio signal received by the antenna into a baseband signal (received signal), and outputs the radio signal to the control unit 120.
  • the transmission unit 112 performs various transmissions under the control of the control unit 120.
  • the transmission unit 112 includes an antenna, converts a baseband signal (transmission signal) output by the control unit 120 into a radio signal, and transmits the baseband signal (transmission signal) from the antenna.
  • the control unit 120 performs various controls on the UE 100.
  • the control unit 120 includes at least one memory and at least one processor electrically connected to the memory.
  • the memory stores a program executed by the processor and information used for processing by the processor.
  • the processor may include a baseband processor and a CPU.
  • the baseband processor modulates / demodulates and encodes / decodes the baseband signal.
  • the CPU executes a program stored in the memory to perform various processes.
  • the processor performs processing of each layer described later.
  • FIG. 6 is a diagram showing a protocol stack for RRC connection and NAS connection of IAB-MT.
  • the IAB-MT of the IAB node 300-2 includes a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, and a PDCP (Packet Data Control Protocol). It has a layer, an RRC (Radio PHY Control) layer, and a NAS (Non-Access Stratum) layer.
  • PHY physical
  • MAC Medium Access Control
  • RLC Radio Link Control
  • PDCP Packet Data Control Protocol
  • It has a layer, an RRC (Radio PHY Control) layer, and a NAS (Non-Access Stratum) layer.
  • the PHY layer performs coding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping.
  • Data and control information are transmitted between the PHY layer of the IAB-MT of the IAB node 300-2 and the PHY layer of the IAB-DU of the IAB node 300-1 via a physical channel.
  • the MAC layer performs data priority control, retransmission processing by hybrid ARP (Automatic Repeat Request) (HARQ), random access procedure, and the like. Data and control information are transmitted between the MAC layer of the IAB-MT of the IAB node 300-2 and the MAC layer of the IAB-DU of the IAB node 300-1 via the transport channel.
  • the MAC layer of the IAB-DU includes a scheduler. The scheduler determines the transport format (transport block size, modulation / coding method (MCS)) of the upper and lower links and the allocated resource block.
  • the RLC layer transmits data to the receiving RLC layer by using the functions of the MAC layer and the PHY layer. Data and control information are transmitted between the RLC layer of the IAB-MT of the IAB node 300-2 and the RLC layer of the IAB-DU of the IAB node 300-1 via a logical channel.
  • the PDCP layer performs header compression / decompression and encryption / decryption. Data and control information are transmitted via the radio bearer between the PDCP layer of the IAB-MT of the IAB node 300-2 and the PDCP layer of the donor gNB200.
  • the RRC layer controls logical channels, transport channels, and physical channels according 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 the IAB node 300-2 and the RRC layer of the donor gNB200. If there is an RRC connection with the donor gNB200, the IAB-MT is in the RRC connected state. If there is no RRC connection with the donor gNB200, the IAB-MT is in the RRC idle state.
  • the NAS layer located above the RRC layer performs session management, mobility management, etc.
  • NAS signaling is transmitted between the NAS layer of the IAB-MT of the IAB node 300-2 and the AMF11.
  • FIG. 7 is a diagram showing a protocol stack related to the F1-U protocol.
  • FIG. 8 is a diagram showing a protocol stack for the F1-C protocol.
  • the donor gNB200 is divided into CU and DU.
  • each of the IAB-MT of the IAB node 300-2, the IAB-DU of the IAB node 300-1 and the IAB-MT of the IAB node 300-1 and the DU of the donor gNB200 are above the RLC layer. It has a BAP (Backhaul Adjustment Protocol) layer as a layer.
  • the BAP layer is a layer that performs routing processing and bearer mapping / demapping processing.
  • the IP (Internet Protocol) layer is transmitted via the BAP layer, so that routing with a plurality of hops becomes possible.
  • the PDU (Protocol Data Unit) of the BAP layer is transmitted by the backhaul RLC channel (BH NR RLC channel).
  • the backhaul RLC channel BH NR RLC channel.
  • QoS quality of service
  • the protocol stack of the F1-C protocol replaces the GTP-U (GPRS Tunneling Protocol for User Plane) layer and the UDP (User Datagram Protocol) layer shown in FIG. 7, and is an F1AP (Application Protocol) layer. And SCTP (Stream Control Transmission Protocol) layer.
  • GTP-U GPRS Tunneling Protocol for User Plane
  • UDP User Datagram Protocol
  • SCTP Stream Control Transmission Protocol
  • the IAB node 300 (specifically, IAB-MT) switches the connection between the donor gNB 200.
  • the IAB node 300 may be a movable IAB node 300.
  • Connection switching means handover or RRC re-establishment.
  • Handover means an operation in which the IAB-MT in the RRC connected state switches cells.
  • the RRC re-establishment is an operation in which the IAB-MT in the RRC connected state reconnects with another cell in response to the detection of a wireless link failure.
  • the connection switching is a handover will be described, but the connection switching may be an RRC reestablishment.
  • the operation of the UE 100 under the IAB node 300 becomes a problem. Specifically, when the IAB node 300 switches the connection between the donor gNB 200, a new operation may be required for the UE 100 under the IAB node 300. However, from the viewpoint of backward compatibility, it is not preferable to make changes to the operation of the UE 100.
  • the first embodiment is an embodiment in which the connection switching (for example, handover) of the IAB node 300 between the donor gNB 200 is realized only by changing the operation on the network side (IAB node side) transparently to the UE 100 side.
  • a handover may be referred to as an inter-CU handover.
  • the IAB node 300 having the UE 100 under its control is a second donor base station different from the first donor base station from the source donor gNB200S which is the first donor base station.
  • Handover to a target donor gNB200T is performed.
  • the RRC connection between the UE 100 and the source donor gNB200S is continued via the target donor gNB200T.
  • the source donor gNB200S uses the RRC connection to transmit a handover command instructing the handover to the target donor gNB200T to the UE 100 via the target donor gNB200T.
  • the RRC connection (and PDCP connection) between the UE 100 and the source donor gNB200 continues to be established via the target donor gNB200, and the source donor gNB200S transmits a handover command to the UE 100 using the connection.
  • the handover of the IAB node 300 between the donor gNB 200 can be realized without changing the operation of the UE 100.
  • a data path may be established between the source donor gNB200S and the target donor gNB200T. From the handover of the IAB node 300 to the completion of the handover of the UE 100, the data transfer processing (that is, data forwarding) of the UE 100 may be performed via this data path. As a result, even if the handover of the IAB node 300 is executed first and then the handover of the UE 100 is performed, the data loss of the UE 100 can be prevented.
  • FIG. 9 is a diagram showing an operation according to the first embodiment.
  • step S101 the UE 100 is in a state in which an RRC connection with the source donor gNB200S is established (RRC connected state).
  • the IAB node 300 (IAB-MT) is in a state of establishing an RRC connection with the source donor gNB200S (RRC connected state). At least one intermediate IAB node may intervene between the IAB node 300 and the source donor gNB200S.
  • the UE 100 is under the control of the IAB node 300 (IAB-DU). That is, the UE 100 uses the cell of the IAB node 300 (IAB-DU) as its own serving cell.
  • step S103 the IAB node 300 (IAB-MT) performs RRC reestablishment or handover from the source donor gNB200S to the target donor gNB200T.
  • the description will proceed on the assumption that the IAB node 300 (IAB-MT) performs handover.
  • step S104 the IAB node 300 (IAB-MT) establishes an RRC connection with the target donor gNB200T as a result of the handover.
  • the RRC layer and PDCP layer of the UE 100 remain connected to the source donor gNB200. Therefore, the UE 100 cannot communicate with the target donor gNB200T in either the C plane or the U plane.
  • a tunnel (that is, a data forwarding path) is formed between the source donor gNB200S and the target donor gNB200T.
  • This tunnel may be configured on the inter-base station interface or over the core network.
  • step S105 the UE 100 transmits the uplink user data (User data) to the IAB node 300.
  • the IAB node 300 receives the user data.
  • step S106 the IAB node 300 transmits the user data from the UE 100 to the target donor gNB200T.
  • the target donor gNB200T receives user data.
  • step S107 the target donor gNB200T transfers the user data received in step S106 to the source donor gNB200S (Data forwarding).
  • the source donor gNB200S receives user data.
  • step S108 the source donor gNB200S transfers the user data received in step S107 to UPF12 of the core network.
  • step S109 the source donor gNB200S receives the downlink user data (User data) from the UPF12 of the core network.
  • step S110 the source donor gNB200S transfers the user data received in step S109 to the target donor gNB200T (Data forwarding).
  • the target donor gNB200T receives user data.
  • step S111 the target donor gNB200T transfers the user data received in step S110 to the IAB node 300.
  • the IAB node 300 receives the user data.
  • step S112 the IAB node 300 transmits (relays) the user data received in step S111 to the UE 100.
  • the transmission / reception of user data between the UE 100 and the source donor gNB200S continues via the tunnel between the source donor gNB200S and the target donor gNB200T and the target donor gNB200T.
  • step S113 the source donor gNB200S transmits a handover command (HO Command) instructing the UE 100 to perform a handover to the target donor gNB200T via the tunnel between the source donor gNB200S and the target donor gNB200T to the target donor gNB200T.
  • the target donor gNB200 receives the handover command.
  • step S114 the target donor gNB200T transmits an RRC message (RRC Reconnection) including the handover command received in step S113 to the UE 100.
  • RRC Reconnection RRC Reconnection
  • the target donor gNB200T transmits the RRC message to the UE 100 via the IAB node 300.
  • the UE 100 receives the RRC message.
  • FIG. 10 is a diagram showing a protocol stack at the time of handover command transmission.
  • a handover command (RRC Configuration) is transmitted from the RRC layer of the source donor gNB200S to the RRC layer of the UE 100 via the target donor gNB200T and the IAB node 300.
  • Communication between the source donor gNB200S and the target donor gNB200T is performed by inter-base station communication.
  • FIG. 9 shows an example of GTP, but the present invention is not limited to this.
  • it may be Xn-AP, in which case the handover command is contained (encapsulated) and transmitted in the RRC container of the Xn-AP message.
  • the UE 100 transmits an RRC message (RRC Reconnection Complete) indicating the completion of the handover to the target donor gNB200T in response to the handover command. Specifically, the UE 100 transmits the RRC message to the target donor gNB200T via the IAB node 300. The target donor gNB200T receives the RRC message.
  • the RACH-less handover may be performed without transmitting the random access preamble and receiving the random access response. In this case, the RACH-less handover may be instructed to the UE 100 in the handover command.
  • step S116 the UE 100 establishes an RRC connection with the target donor gNB200T as a result of the handover. From this point, the user data of the UE 100 is switched to communication with the target donor gNB200T.
  • step S117 the UE 100 transmits the uplink user data (User data) to the IAB node 300.
  • the IAB node 300 receives the user data.
  • step S118 the IAB node 300 transmits the user data received in step S117 to the target donor gNB200T.
  • the target donor gNB200T receives user data.
  • step S119 the target donor gNB200T transfers the user data received in step S118 to UPF12 of the core network.
  • step S120 the target donor gNB200T receives the downlink user data (User data) from the UPF12 of the core network.
  • User data downlink user data
  • step S121 the target donor gNB200T transfers the user data received in step S120 to the IAB node 300.
  • the IAB node 300 receives the user data.
  • step S122 the IAB node 300 transmits (relays) the user data received in step S121 to the UE 100.
  • the second embodiment is an embodiment relating to load balancing within the IAB topology.
  • the path in the IAB topology is basically determined semi-fixedly by the routing table (BAP routing ID and path ID), and the CU of the donor gNB 200 collectively manages the routing table.
  • BAP routing ID and path ID the routing table
  • the CU of the donor gNB 200 collectively manages the routing table.
  • the IAB node 300 performs efficient data relay in consideration of the data relay capacity of each of the plurality of relay destination nodes (plurality of paths). Specifically, in the second embodiment, the IAB node 300 that relays data from the relay source node to the plurality of relay destination nodes has the capacity information regarding the data relay capacity of the target IAB node 300 included in the plurality of relay destination nodes. To receive. Then, the IAB node 300 controls data relay based on the received capacity information.
  • the capacity information may include information indicating whether or not there are a plurality of nodes of the next hop of the target IAB node 300 included in the plurality of relay destination nodes.
  • the target IAB node 300 can be regarded as having a large data relay capacity. Therefore, by preferentially relaying data to such a target IAB node 300, a plurality of paths can be efficiently used.
  • the IAB node 300 may receive capacity information for each of the plurality of relay destination nodes, and may control the data transmission ratio to the plurality of relay destination nodes based on the received capacity information. For example, the IAB node 300 relays a large amount of data to a relay destination node having a large data relay capacity, and relays a small amount of data to another relay destination node having a small data relay capacity.
  • the IAB node 300 selects a data relay destination from a plurality of relay destination nodes according to the routing setting (routing table) set from the donor gNB 200.
  • the IAB node 300 may execute local routing that selects a data relay destination without following the routing setting.
  • the predetermined condition may include a condition that a failure occurrence notification or a local routing request is received from any of the plurality of relay destination nodes.
  • the IAB node 300 basically performs routing according to the setting from the donor gNB200S, and when a failure occurs or a request occurs in the relay destination node, the IAB node 300 itself performs local routing, which is appropriate depending on the situation. Data can be relayed to various relay destination nodes.
  • FIG. 11 is a diagram for explaining the upstream relay operation according to the second embodiment.
  • the relay source node of the IAB node 300 is a child node of the IAB node 300
  • the relay destination node of the IAB node 300 is the parent node of the IAB node 300.
  • an IAB topology including an IAB node 300, other IAB nodes 300a to 300g, and a donor gNB200 is formed.
  • the IAB node 300 receives an uplink packet (UL packet) from a child node (which may be a UE 100).
  • the IAB node 300 receives the received uplink packet from the parent node IAB node 300a and the parent node based on the routing setting set from the donor gNB 200 and the information (BAP routing ID) included in the header of the uplink packet. / Or relay to the IAB node 300b.
  • Each of the IAB nodes 300a to 300g transmits information indicating whether or not there are a plurality of nodes of the next hop of the own node to the child node as the capacity information of the own node.
  • capacity information is called "BH connection information”. Specific examples of BH connection information will be described later.
  • a BH having one node in the next hop of the own node is called a "single BH", and a BH having two nodes in the next hop of the own node is called a "dual BH".
  • each of the IAB nodes 300b, 300c, 300e, 300f, and 300g is a single BH.
  • each of the IAB nodes 300a and 300d is a dual BH, and it can be considered that the data relay capacity is larger than that of the single BH.
  • the dual BH may be in a state where a dual connection is established by dual connectivity.
  • the IAB node 300 determines the transmission ratio based on the BH connection information of the parent node (IAB node 300a, 300b). Since the IAB node 300a is a dual BH and the IAB node 300b is a single BH, the total number of BH links of the parent node is 3. Therefore, when performing local routing, the IAB node 300 sets the transmission ratio to the IAB node 300a to "2/3" and the transmission ratio to the IAB node 300b to the remaining "1/3".
  • the transmission ratio of a certain parent node may be set to zero. In this case, the determination of the transmission ratio can be regarded as path selection (path switching).
  • FIG. 12 is a diagram showing an upstream relay operation according to the second embodiment. This operation may be performed by the IAB node 300, at least a portion of which may be performed by the BAP layer and / or the IAB-MT.
  • step S201 the IAB node 300 performs routing based on the routing setting set from the donor gNB 200.
  • the IAB node 300 determines whether or not the start condition of the local routing is satisfied.
  • the start condition is one of the following. Parameters (threshold values, etc.) that determine the start conditions may be set from the donor gNB 200 to the IAB node 300.
  • the BH failure occurrence notification in the parent node is transmitted from the parent node to the IAB node 300 by the BH RLF Inspection, which is a message of the BAP layer.
  • the BH failure occurrence notification may be a notification indicating that an RLF (Radio Link Sphere) has occurred in the BH of the parent node, or a notification indicating that the parent node is in the process of recovering from the RLF of the BH. It may be present, or it may be a notification indicating that the recovery of the BH of the parent node from the RLF has failed.
  • this condition may be satisfied when the scheduling request (SR) transmitted by the IAB node 300 to a certain parent node is ignored more than a certain number of times (for example, the uplink grant does not come). Comparing the uplink throughputs of the parent nodes, this condition corresponds to the case where there is a certain difference (bias) or more in the uplink throughput for a certain period in the past (and the state continues for a certain period or more). May be good. This condition may be met when the uplink throughput of a certain parent node becomes a certain value or less (and the state continues for a certain period or more).
  • the local routing request may be sent from the parent node by a BAP layer message.
  • the local routing request may be transmitted from the donor gNB200 via the parent node by an F1 message or an RRC message.
  • the IAB node 300 may send a response to a local routing request from the parent node, or may notify the parent node of the transmission ratio described later.
  • the local routing request may include an identifier of a bearer (or RLC channel or logical channel) for which local routing is to be performed.
  • the IAB node 300 performs local routing for the target bearer (or RLC channel or logical channel) and does not perform local routing for the non-target bearer (or RLC channel or logical channel) (that is, according to the routing table). Do the routing).
  • the IAB node 300 can grasp the amount of uplink buffer of the child node based on the buffer status report (BSR) received from the child node.
  • BSR buffer status report
  • the BSR may be the one in which the uplink buffer amount of the child node (that is, the grandchild node) of the child node is added. This condition may be applicable when the amount of the uplink buffer indicated by the BSR exceeds a certain level (and the state continues for a certain period or longer).
  • step S202 When the start condition of the local routing is not satisfied (step S202: No), the IAB node 300 continues the routing based on the routing setting set by the donor gNB200 (step S201).
  • the IAB node 300 starts the operation related to the local routing. It should be noted that the IAB node 300 may be able to execute the local routing only when the donor gNB 200 permits the execution of the local routing. This permission is given by the BAP layer message (BAP Control PDU), system information (SIB1), RRC Reconnection, and the like. Whether or not local routing can be executed may be set for each bearer (RLC channel) or may be set collectively for all bearers. Along with such a setting, which of the above conditions is applied and a threshold value used for determining the condition may be set.
  • BAP Control PDU BAP Control PDU
  • SIB1 system information
  • RRC Reconnection Radio Resource Control Protocol
  • Whether or not local routing can be executed may be set for each bearer (RLC channel) or may be set collectively for all bearers. Along with such a setting, which of the above conditions is applied and a threshold value used for determining the condition may be set.
  • step S203 the IAB node 300 receives the BH connection information of each parent node. Note that step S203 may be performed before step S202.
  • the BH connection information of the parent node may include information indicating whether the parent node is a single BH or a dual BH (or a triple BH).
  • the BH connection information of the parent node may include a numerical value indicating the number of BHs of the parent node.
  • the BH connection information may further include information regarding the capacity of each BH link.
  • the information about the capacity of each BH link may be, for example, information indicating at least one of the bandwidth, the number of component carriers, and the frequency band of each BH link, and the average throughput (or the average throughput) of each BH link.
  • Information indicating the maximum throughput, GBR (Guaranteed Bit Rate), etc.) may be used.
  • the BH connection information may be transmitted from the parent node to the IAB node 300.
  • the BH connection information may be an information element included in the BAP Control PDU or system information (for example, SIB1) transmitted by the parent node.
  • SIB1 system information
  • the parent node may transmit BH connection information when it is dual BH (or triple BH), and may not transmit BH connection information when it is single BH.
  • the IAB node 300 determines single BH and dual BH depending on whether or not BH connection information is transmitted.
  • the BH connection information may be transmitted from the donor gNB 200 to the IAB node 300. It may be an information element included in an RRC message (for example, RRC Configuration) or an F1 message (for example, DL Information Transfer) transmitted by the donor gNB200.
  • RRC message for example, RRC Configuration
  • F1 message for example, DL Information Transfer
  • the IAB node 300 determines the uplink packet transmission ratio based on the BH connection information received in step S203. As in the above example, when one parent node is dual BH and the other parent node is single BH, the IAB node 300 sets the transmission ratio to the one parent node to "2/3". Then, the transmission ratio to the other parent node is set to "1/3". Here, for example, when the transmission ratio is set to 0: 1, it is considered that the transmission destination has been switched (locally switched). The IAB node 300 may adjust or determine the transmission ratio based on the information contained in the BH connection information (for example, information regarding the capacity of each BH link). The IAB node 300 may adjust or determine the transmission ratio based on the past transmission throughput history for each parent node (or uplink grant history to child nodes (ie, reception throughput)).
  • the IAB node 300 performs local routing of the uplink packet based on the transmission ratio determined (and adjusted) in step S204.
  • the IAB node 300 may change the header of the locally routed uplink packet. For example, in the BAP header, the routing ID may be changed, or an identifier indicating that the local routing has been performed may be added.
  • the IAB node 300 determines whether or not the termination condition of the local routing is satisfied.
  • the end condition can be the reverse of the start condition described above. For example, the condition that the BH recovery success notification is received from the parent node, the condition that the throughput to a certain parent is recovered, the condition that the local routing stop request is received, and the buffer state of the child node (and grandchild node) are improved. At least one of the conditions that has been done.
  • the termination condition may include the condition that the local routing permission has been revoked (set to disallowed) from the donor gNB200.
  • step S206: No If the end condition of the local routing is not satisfied (step S206: No), the IAB node 300 continues the local routing (step S205). On the other hand, when the termination condition of the local routing is satisfied (step S206: Yes), the IAB node 300 performs routing based on the routing setting set by the donor gNB 200 (step S201).
  • FIG. 13 is a diagram for explaining the downstream relay operation according to the second embodiment.
  • the relay source node of the IAB node 300 is the parent node of the IAB node 300
  • the relay destination node of the IAB node 300 is the child node of the IAB node 300.
  • the parent node and the child node in the above-mentioned upstream relay operation may be exchanged.
  • FIG. 13 shows an example in which each IAB node 300 is a dual BH and there are four paths between the IAB node 300 and the destination node (Destination).
  • FIG. 14 is a diagram showing a downstream relay operation according to the second embodiment. This operation may be performed by the IAB node 300, at least a portion of which may be performed by the BAP layer and / or the IAB-DU. Here, the differences from the upstream relay operation will be mainly described.
  • step S301 the IAB node 300 performs routing based on the routing setting set from the donor gNB 200.
  • the IAB node 300 determines whether or not the start condition of the local routing is satisfied.
  • the start condition is one of the following. Parameters (threshold values, etc.) that determine the start conditions may be set from the donor gNB 200 to the IAB node 300.
  • the IAB node 300 may be able to execute local routing only when local routing is permitted (configured) by the donor gNB 200.
  • the permission may be given by F1 message (F1AP), RRC message, or BAP message.
  • the permission may be set for each bearer (RLC channel) or may be set for all bearers at once.
  • the permission may be an instruction. Further, which of the following conditions is applied, and a threshold value used for determining the condition may be set.
  • the IAB node 300 may determine the radio state from the measurement report from the child node and / or the scheduling result (MCS or the like) for the child node.
  • the IAB-DU of the IAB node 300 transmits a Flow control polling BAP Control PDU to the child node and receives a Flow control polledback BAP Control PDU from the child node. Then, the IAB node 300 (IAB-DU) specifies the available buffer size (free buffer amount) indicated by the Flow control feedback feedback BAP Control PDU, and makes a determination.
  • step S302 When the start condition of the local routing is not satisfied (step S302: No), the IAB node 300 continues the routing based on the routing setting set by the donor gNB200 (step S301).
  • the IAB node 300 starts the operation related to the local routing.
  • the IAB node 300 may select a different path having the same destination from the routing settings and send a downlink packet to the IAB node corresponding to the path. Further, the IAB node 300 may change the header of the downlink packet that has been locally routed. For example, in the BAP header, the routing ID may be changed, or an identifier indicating that the local routing has been performed may be added.
  • the IAB node 300 may receive the available buffer size information from each child node.
  • the IAB node 300 determines the selection of the downstream path and / or the transmission ratio to the child node. Specifically, the IAB node 300 selects another path having the same destination from the stored routing settings. The IAB node 300 may select a plurality of paths, and in this case, the transmission ratio may be determined in the same manner as in the upstream relay operation described above. Selectable path combinations may be preset for the donor gNB 200 to the IAB node 300.
  • step S305 the IAB node 300 performs local routing according to the result of step S304.
  • the IAB node 300 determines whether or not the termination condition of the local routing is satisfied.
  • the end condition can be the reverse of the start condition described above. For example, at least one of the conditions that the throughput of a certain path is recovered above a certain level, the radio state of the child node is recovered above a certain level, and the available buffer size of the child node is recovered above a certain level.
  • the termination condition may include the condition that the local routing permission has been revoked (set to disallowed) from the donor gNB200.
  • step S306 If the end condition of the local routing is not satisfied (step S306: No), the IAB node 300 continues the local routing (step S305). On the other hand, when the termination condition of the local routing is satisfied (step S306: Yes), the IAB node 300 performs routing based on the routing setting set by the donor gNB 200 (step S301).
  • the donor gNB 200 may not be able to grasp the content of the local routing executed by the IAB node 300 (when it was executed and how many times it was executed). If local routing is performed, there may be a flaw in the routing settings by the donor gNB200, or a failure in the IAB topology. Therefore, it is preferable that the donor gNB200 can grasp the contents of the local routing. This allows, for example, the donor gNB200 to optimize the routing settings.
  • the IAB node 300 that relays data from the relay source node to a plurality of relay destination nodes selects a data relay destination from the plurality of relay destination nodes according to the routing setting set from the donor gNB 200.
  • the IAB node 300 executes local routing that selects a data relay destination without following the routing setting (see the second embodiment).
  • the IAB node 300 transmits historical information regarding this local routing (that is, information indicating the contents of the local routing) to the donor gNB 200.
  • FIG. 15 is a diagram showing the operation of the modified example 1 of the second embodiment.
  • step S401 the IAB node 300 performs local routing.
  • the IAB node 300 stores information (local routing information) related to the local routing executed in step S401.
  • the IAB node 300 stores the local routing information each time the local routing is performed.
  • the local routing information may include at least one of a time stamp indicating the execution time of the local routing, a position information (latitude / longitude altitude) indicating the execution time of the local routing, and information indicating the radio status at the time of executing the local routing. good.
  • the local routing information may include a routing ID (path ID and Destiny) before and after the change by local routing.
  • the local routing information may include the topology ID (may be donor gNB ID, gNB-CU ID) of the IAB topology being connected.
  • the local routing information may include information indicating the reason (or condition) for executing the local routing.
  • the local routing information may include information indicating the period during which the local routing was performed (start time, end time) and / or the number of times the local routing was performed.
  • the local routing information may be stored in the BAP layer, or may be reported from the BAP layer to the RRC layer each time and stored in the RRC layer.
  • the IAB node 300 transmits the local routing information saved in step S402 to the donor gNB200.
  • Local routing information is transmitted from the IAB node 300, for example, by an RRC message.
  • the local routing information may be transmitted as a response message in response to a request from the donor gNB200.
  • the local routing information may be transmitted as a UE Information Response to the UE Information Request.
  • This modification is an embodiment in which the donor gNB 200 changes the routing setting of the IAB node 300 at the request of the IAB node 300.
  • the IAB node 300 that relays data from the relay source node to a plurality of relay destination nodes selects a data relay destination from the plurality of relay destination nodes according to the routing setting set from the donor gNB 200.
  • the IAB node 300 sends a routing change request to the donor gNB 200 to change the routing setting.
  • FIG. 16 is a diagram showing the operation of the modified example 2 of the second embodiment.
  • the IAB node 300 transmits a routing change request to the donor gNB 200.
  • the routing change request may be a notification that the routing change is desired.
  • the routing change request may be an RRC message or an F1 (F1AP) message.
  • the routing change request may be specified separately for the upstream routing change and the downstream routing change.
  • the routing change request may be transmitted only when transmission is permitted by the donor gNB200.
  • the IAB node 300 may send a routing change request with the same condition as the start condition of the local routing described in the second embodiment described above being satisfied as a trigger.
  • the conditions and determination thresholds to be used may be set from the donor gNB 200 to the IAB node 300.
  • the IAB node 300 may transmit the routing change request only when the transmission of the routing change request is permitted (set) by the donor gNB 200.
  • the routing change request includes information indicating the reason (or condition) that the routing setting change is necessary, the routing ID (path ID, Destination) of the setting change target, and the RLC Channel ID (bearer ID, LCID may be used) of the setting change target. Of these, at least one may be included.
  • the IAB node 300 may include its own BSR value in the routing change request. Further, the IAB node 300 may include the BSR value in the routing change request for each parent node (in the case of dual connectivity) in the dual BH (in the case of dual connectivity, the IAB node 300 may include the BSR value of its own child node or it. The added own BSR value may be included in the routing change request. Such transmission of the BSR value may be periodically performed by each IAB node 300 in the IAB topology to the donor gNB 200.
  • the IAB node 300 may include its own available buffer size value and / or its own child node's available buffer size value (Flow control fedback BAP Control PDU value) in the routing change request. ..
  • Each IAB node 300 in the IAB topology may periodically transmit such available buffer size values to the donor gNB 200.
  • the donor gNB 200 changes the routing setting of the IAB node 300 in response to the routing change request received in step S501.
  • the IAB node 300 may perform a handover of the IAB node 300 (that is, change the IAB topology) as necessary.
  • the IAB node 300 may start a timer when the routing change request is transmitted, and the transmission of the next routing change request may be prohibited until the timer expires.
  • the timer value of this timer may be set from the donor gNB 200 to the IAB node 300.
  • the relay transmission by IAB has been described as an example, but the present invention is not limited to this, and may be applied to other relay transmission systems.
  • the operation according to the above-described embodiment and modification may be applied to a relay node (layer 3 relay node), a side link relay (relay node using a side link used for direct communication between user devices), and the like. ..
  • the base station in the cellular communication system 1 may be an eNB which is an LTE base station.
  • the core network in the cellular communication system 1 may be an EPC (Evolved Packet Core).
  • the gNB may be connected to the EPC
  • the eNB may be connected to the 5GC
  • the gNB and the eNB may be connected via an inter-base station interface (Xn interface, X2 interface).
  • a program for causing a computer to execute each process according to the above-described embodiment and modification may be provided.
  • the program may also be recorded on a computer-readable medium.
  • Computer-readable media can be used to install programs on a computer.
  • the computer-readable medium on which the program is recorded may be a non-transient recording medium.
  • the non-transient recording medium is not particularly limited, but may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.
  • a chipset composed of a memory for storing a program for executing each process performed by the UE 100, gNB 200, or the IAB node 300 and a processor for executing the program stored in the memory may be provided.
  • Topology Adaptation Enhancements-Procedure specifications for interdonor IAB node movement to enhance robustness and load balancing, including enhancements to reduce signaling load. -Specifications of extended functions for reducing service interruptions due to IAB node movement and BH RLF recovery. -Extended specifications for topology redundancy, including support for CP / UP isolation. Topology, Routing, and Transport Enhancements-Extension specifications to improve overall topology fairness, multi-hop delay, and congestion mitigation.
  • BH backhaul
  • BH RLF BH RLF indication
  • existing functions such as RRC re-establishment, MCG / SCG failure indication, and / or conditional handover. Only the recovery procedure was specified.
  • Proposal 1 RAN2 should assume that the quality of the backhaul link will change dynamically. Therefore, the backhaul RLF is not a rare case like the Rel-17 eIAB.
  • Proposal 2 RAN2 should agree that BH RLF indication type 2 "attempting recovery" has been introduced. Further consideration is needed as to whether it is transmitted via BAP Control PDU, SIB1, or both.
  • Type 3 "BH link recovery" in Rel-17 as well.
  • the type 3 indication is transmitted via the BAP Control PDU, there is an advantage that the downstream IAB node can quickly know the BH link recovery.
  • the UE since the UE does not have a BAP layer, the fact cannot be known. Therefore, RAN2 should discuss whether Type 3 indications are needed.
  • Proposal 3 If Proposal 3 can be agreed, RAN2 should discuss whether explicit BH RLF indications when BH RLF is gone, ie, type 3 "BH link recovery", will be introduced.
  • Proposal 4 RAN2 should agree to reduce / stop scheduling requests after IAB-MT receives a Type 2 indication and resume scheduling requests when the parent node runs out of BH RLF. be.
  • Proposal 5 RAN2 should discuss any other IAB-MT behavior while the parent node is trying to recover the BH link.
  • the IAB-DU that sends the indication
  • the type 2 BH RLF indication will be sent.
  • RLF occurs on this BH link
  • an indication is transmitted, so it is easy for a single-connection BH.
  • the IAB node detects an RLF on the MCG, it initiates the MCG fault information procedure, but the SCG continues to function as a BH link, so it may not be necessary to send a Type 2 indication at this point.
  • the IAB-MT initiates RRC re-establishment, at which point a Type 2 indication is transmitted. Therefore, the type 2 indication is transmitted when the RRC reestablishment is initiated, not when the MCG / SCG failure information is triggered. In any case, this is intended for IAB-DU behavior, so careful consideration should be given to whether / how to capture to specifications. That is, in stages 2 and 3, it should be considered whether note needs to be added or nothing needs to be captured.
  • Proposal 6 RAN2 agrees that IAB-DU may send a Type 2 BH RLF indication when it initiates RRC reestablishment rather than when it initiates any of the RLF recovery procedures. Should be.
  • Proposal 7 RAN2 should discuss whether / how to capture the IAB-DU behavior (ie, Proposal 6) in the specification.
  • Finding 4 In Rel-16, when the IAB node attempts an RRC re-establishment request to a descendant node, the IAB node must wait for the failure and finally move to idle.
  • Proposal 8 RAN2 should agree that optimization of cell (re) selection is considered to avoid re-establishment to inappropriate nodes (eg, descendant nodes).
  • the common concept is considered to be that the IAB-MT is provided in either whitelist or blacklist for the purpose of cell selection.
  • Whitelists and blacklists have advantages depending on the topology and the location of the IAB node, given that topology changes can occur frequently on Rel-17, for example due to "moving interdonor IAB nodes". And there are disadvantages.
  • the blacklist has the advantage of low overhead in this case, as it contains, for example, only the downstream IAB nodes of the IAB node of concern, and in some cases only a small number of child IAB nodes.
  • Findings 5 Whitelists and blacklists have advantages and disadvantages depending on the topology and location of the IAB node.
  • the IAB donor or parent IAB node
  • Proposal 9 RAN2 should agree that the IAB-MT will be provided with a whitelist or blacklist (ie, a selection structure) for the purpose of cell selection to avoid re-establishment to descendant nodes. Further consideration is needed as to whether these lists can also be used for cell reselection procedures.
  • a whitelist or blacklist ie, a selection structure
  • Proposal 9 can be agreed, further consideration should be given to the information, that is, how to provide the white list or blacklist.
  • Option 1 assumes a CHO setting and may require some extensions.
  • Option 2 envisions additional indications, such as type 2 BH RLF indications.
  • Option 3 is intended to provide information about the entire topology that is not in the existing configuration.
  • Option 5 is supposed to be set by OAM, but as the reporter pointed out, this is suspicious.
  • the whitelist / blacklist The delivery method should be a dynamic method. Therefore, option 5, ie OAM, should be excluded. Which method, i.e. which of options 1, 2, or 3 should be the baseline for the extension, needs further consideration.
  • Proposal 10 RAN2 should agree that the whitelist / blacklist is dynamically provided by the parent IAB node or IAB donor each time the topology changes. Further studies are needed for details.
  • the second solution "rerouting buffered PDCP PDUs on the intermediate IAB node," was supported as an implementation choice at the BAP layer. Further, the BAP layer may be executed "for example, data buffering in the transmission part of the BAP entity is implementation-dependent until the RLC-AM entity receives the acknowledgment". These BAP implementations were considered to avoid packet loss in the "most" cases of the Rel-16 deployment scenario, i.e. when using fixed IAB nodes, but are not perfect, for example, as in Figure 19. rice field.
  • the third solution “Introduction of UL Status Delivery,” was a promised solution to guarantee lossless delivery of UL data in view of the evaluation results cited in FIG.
  • the idea was to delay the RLC ARQ to the UE so that it would start when PDCP data recovery in the UE was needed.
  • a fixed IAB node was assumed, it was considered rare that UL packets were dropped due to a topology change, so it was not specified in Rel-16.
  • RAN2 should discuss, in addition to the results captured by TR, an extended mechanism to ensure lossless delivery within the L2 multihop network.
  • Proposal 11 is a solution identified in TR38.874, a mechanism that guarantees lossless delivery under conditions where topology changes may occur frequently based on some form of "UL status delivery". Should be agreed to be introduced.
  • C-2 should be an extended baseline for Rel-17 for lossless delivery of UL packets.
  • C-2 which is the solution to "introduction of UL status distribution" may be an extended baseline for Rel-17, which can also be implemented for Rel-16.
  • Rel-17 should assume a dynamic topology change that causes UL packet loss
  • the extension of Rel-17 will support C-2 as a standard support function.
  • At least the stage 2 specification should explain the overall mechanism based on C-2. Otherwise, the 3GPP standard does not guarantee lossless delivery during the handover of the IAB node.
  • small changes such as RLC and / or BAP are expected in Stage 3, but details may not be specified as they are considered internal behavior of the IAB node.
  • Proposal 12 RAN2 should agree to specify an RLC ARQ mechanism for lossless delivery of UL packets in stage 2. This delays the transmission of the ACK to the child node / UE before receiving the ACK from the parent IAB node (ie, C-2). Whether or not to specify in stage 3 / how to specify it needs further consideration.

Landscapes

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

Abstract

第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法であって、配下にユーザ装置を有する中継ノードが、第１ドナー基地局から第２ドナー基地局への接続切替を行うことと、前記接続切替を行っても、前記ユーザ装置と前記第１ドナー基地局との間のＲＲＣ（Ｒａｄｉｏ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌ）接続を前記第２ドナー基地局経由で継続することと、前記第１ドナー基地局が、前記ＲＲＣ接続を用いて、前記第２ドナー基地局へのハンドオーバを指示するハンドオーバ指令を前記第２ドナー基地局経由で前記ユーザ装置に送信することとを有する。

Description

通信制御方法
　本開示は、セルラ通信システムで用いる通信制御方法に関する。
　セルラ通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄ　Ｇｅｎｅｒａｔｉｏｎ　Ｐａｒｔｎｅｒｓｈｉｐ　Ｐｒｏｊｅｃｔ）において、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ　Ａｃｃｅｓｓ　ａｎｄ　Ｂａｃｋｈａｕｌ）ノードと呼ばれる新たな中継ノードが規定されている（例えば、「３ＧＰＰ　ＴＳ　３８．３００　Ｖ１６．２．０　（２０２０－０７）」参照）。１又は複数の中継ノードが基地局とユーザ装置との間の通信に介在し、この通信に対する中継を行う。
　第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法であって、中継元ノードから複数の中継先ノードへデータ中継を行う中継ノードが、ドナー基地局から設定されたルーティング設定に従って前記複数の中継先ノードの中からデータ中継先を選択することと、前記中継ノードが、所定条件が満たされた場合、前記ルーティング設定に従わずに前記データ中継先を選択するローカルルーティングを実行することと、を有する。前記所定条件は、前記複数の中継先ノードのいずれかから障害発生通知を受信したという条件を含む。
　第２の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法であって、配下にユーザ装置を有する中継ノードが、第１ドナー基地局から第２ドナー基地局への接続切替を行うことと、前記接続切替を行っても、前記ユーザ装置と前記第１ドナー基地局との間のＲＲＣ（Ｒａｄｉｏ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌ）接続を前記第２ドナー基地局経由で継続することと、前記第１ドナー基地局が、前記ＲＲＣ接続を用いて、前記第２ドナー基地局へのハンドオーバを指示するハンドオーバ指令を前記第２ドナー基地局経由で前記ユーザ装置に送信することとを有する。
　第３の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法であって、中継元ノードから複数の中継先ノードへデータ中継を行う中継ノードが、前記複数の中継先ノードに含まれる対象中継ノードのデータ中継容量に関する容量情報を前記対象中継ノードから受信することと、前記中継ノードが、前記容量情報に基づいて前記データ中継を制御することとを有する。
　第４の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法であって、中継元ノードから複数の中継先ノードへデータ中継を行う中継ノードが、ドナー基地局から設定されたルーティング設定に従って、前記複数の中継先ノードの中からデータ中継先を選択することと、前記中継ノードが、前記ルーティング設定を変更するためのルーティング変更要求を前記ドナー基地局に送信することとを有する。
　第５の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法であって、中継元ノードから複数の中継先ノードへデータ中継を行う中継ノードが、ドナー基地局から設定されたルーティング設定に従って、前記複数の中継先ノードの中からデータ中継先を選択することと、前記中継ノードが、所定条件が満たされた場合、前記ルーティング設定に従わずに前記データ中継先を選択するローカルルーティングを実行することと、前記ローカルルーティングに関する履歴情報を前記ドナー基地局に送信することとを有する。
実施形態に係るセルラ通信システムの構成を示す図である。 ＩＡＢノードと親ノード（Ｐａｒｅｎｔ　ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ　ｎｏｄｅｓ）との関係を示す図である。 実施形態に係るｇＮＢ（基地局）の構成を示す図である。 実施形態に係るＩＡＢノード（中継ノード）の構成を示す図である。 実施形態に係るＵＥ（ユーザ装置）の構成を示す図である。 ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックを示す図である。 Ｆ１－Ｕプロトコルに関するプロトコルスタックを示す図である。 Ｆ１－Ｃプロトコルに関するプロトコルスタックを示す図である。 第１実施形態に係る動作を示す図である。 第１実施形態に係るハンドオーバ指令伝送時におけるプロトコルスタックを示す図である。 第２実施形態に係るアップストリーム中継動作を説明するための図である。 第２実施形態に係るアップストリーム中継動作を示す図である。 第２実施形態に係るダウンストリーム中継動作を説明するための図である。 第２実施形態に係るダウンストリーム中継動作を示す図である。 第２実施形態の変更例１の動作を示す図である。 第２実施形態の変更例２の動作を示す図である。 ＢＨ　ＲＬＦ通知のタイプを示す図である。 子孫ノードへの再確立を回避するための特定された解決策を示す図である。 ｈｏｐ－ｂｙ－ｈｏｐ　ＲＬＣ　ＡＲＱの場合のＵＬデータのロスレス配信のメカニズムの比較を示す図である。 ＵＬステータス配信の導入のオプションを示す図である。
　図面を参照しながら、一実施形態に係るセルラ通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
　（セルラ通信システムの構成）
　まず、実施形態に係るセルラ通信システムの構成について説明する。図１は、実施形態に係るセルラ通信システム１の構成を示す図である。
　セルラ通信システム１は、３ＧＰＰ規格に基づく第５世代（５Ｇ）セルラ通信システムである。具体的には、セルラ通信システム１における無線アクセス方式は、５Ｇの無線アクセス方式であるＮＲ（Ｎｅｗ　Ｒａｄｉｏ）である。但し、セルラ通信システム１には、ＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）が少なくとも部分的に適用されてもよい。
　図１に示すように、セルラ通信システム１は、５Ｇコアネットワーク（５ＧＣ）１０と、ユーザ装置（ＵＥ：Ｕｓｅｒ　Ｅｑｕｉｐｍｅｎｔ）１００と、基地局（ｇＮＢと呼ばれる）２００と、ＩＡＢノード３００とを有する。ＩＡＢノード３００は、中継ノードの一例である。
　以下において、基地局がＮＲ基地局である一例について主として説明するが、基地局がＬＴＥ基地局（すなわち、ｅＮＢ）であってもよい。
　５ＧＣ１０は、ＡＭＦ（Ａｃｃｅｓｓ　ａｎｄ　Ｍｏｂｉｌｉｔｙ　Ｍａｎａｇｅｍｅｎｔ　Ｆｕｎｃｔｉｏｎ）１１及びＵＰＦ（Ｕｓｅｒ　Ｐｌａｎｅ　Ｆｕｎｃｔｉｏｎ）１２を有する。ＡＭＦ１１は、ＵＥ１００に対する各種モビリティ制御等を行う装置である。ＡＭＦ１１は、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００が在圏するエリアの情報を管理する。ＵＰＦ１２は、ユーザデータの転送制御等を行う装置である。
　各ｇＮＢ２００は、固定の無線通信ノードであって、１又は複数のセルを管理する。セルは、無線通信エリアの最小単位を示す用語として用いられる。セルは、ＵＥ１００との無線通信を行う機能又はリソースを示す用語として用いられることがある。１つのセルは１つのキャリア周波数に属する。
　各ｇＮＢ２００は、ＮＧインターフェイスと呼ばれるインターフェイスを介して５ＧＣ１０と相互に接続される。図１において、５ＧＣ１０に接続された２つのｇＮＢ２００－１及びｇＮＢ２００－２を例示している。
　各ｇＮＢ２００は、Ｘｎインターフェイスと呼ばれる基地局間インターフェイスを介して、隣接関係にある他のｇＮＢ２００と相互に接続される。図１において、ｇＮＢ２００－１がｇＮＢ２００－２と接続される一例を示している。
　各ｇＮＢ２００は、集約ユニット（ＣＵ：Ｃｅｎｔｒａｌ　Ｕｎｉｔ）と分散ユニット（ＤＵ：Ｄｉｓｔｒｉｂｕｔｅｄ　Ｕｎｉｔ）とに分割されていてもよい。ＣＵ及びＤＵは、Ｆ１インターフェイスと呼ばれるインターフェイスを介して相互に接続される。Ｆ１プロトコルは、ＣＵとＤＵとの間の通信プロトコルであって、制御プレーンのプロトコルであるＦ１－ＣプロトコルとユーザプレーンのプロトコルであるＦ１－Ｕプロトコルとがある。
　セルラ通信システム１は、バックホールにＮＲを用いてＮＲアクセスの無線中継を可能とするＩＡＢをサポートする。ドナーｇＮＢ２００－１は、ネットワーク側のＮＲバックホールの終端ノードであり、ＩＡＢをサポートする追加機能を備えたドナー基地局である。バックホールは、複数のホップ（すなわち、複数のＩＡＢノード３００）を介するマルチホップが可能である。
　図１において、ＩＡＢノード３００－１がドナーｇＮＢ２００－１と無線で接続し、ＩＡＢノード３００－２がＩＡＢノード３００－１と無線で接続し、Ｆ１プロトコルが２つのバックホールホップで伝送される一例を示している。
　ＵＥ１００は、セルとの無線通信を行う移動可能な無線通信装置である。ＵＥ１００は、ｇＮＢ２００又はＩＡＢノード３００との無線通信を行う装置であればどのような装置であっても構わない。例えば、ＵＥ１００は、携帯電話端末やタブレット端末、ノートＰＣ、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置である。ＵＥ１００は、アクセスリンクを介してＩＡＢノード３００又はｇＮＢ２００に無線で接続する。図１において、ＵＥ１００がＩＡＢノード３００－２と無線で接続される一例を示している。ＵＥ１００は、ＩＡＢノード３００－２及びＩＡＢノード３００－１を介してドナーｇＮＢ２００－１と間接的に通信する。
　図２は、ＩＡＢノード３００と親ノード（Ｐａｒｅｎｔ　ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ　ｎｏｄｅｓ）との関係を示す図である。
　図２に示すように、各ＩＡＢノード３００は、基地局機能部に相当するＩＡＢ－ＤＵとユーザ装置機能部に相当するＩＡＢ－ＭＴ（Ｍｏｂｉｌｅ　Ｔｅｒｍｉｎａｔｉｏｎ）とを有する。
　ＩＡＢ－ＭＴのＮＲ　Ｕｕ無線インターフェイス上の隣接ノード（すなわち、上位ノード）は、親ノードと呼ばれる。親ノードは、親ＩＡＢノード又はドナーｇＮＢ２００のＤＵである。ＩＡＢ－ＭＴと親ノードとの間の無線リンクは、バックホールリンク（ＢＨリンク）と呼ばれる。図２において、ＩＡＢノード３００の親ノードがＩＡＢノード３００Ｐ１及び３００Ｐ２である一例を示している。なお、親ノードへ向かう方向は、アップストリーム（ｕｐｓｔｒｅａｍ）と呼ばれる。ＵＥ１００から見て、ＵＥ１００の上位ノードは親ノードに該当し得る。
　ＩＡＢ－ＤＵのＮＲアクセスインターフェイス上の隣接ノード（すなわち、下位ノード）は、子ノードと呼ばれる。ＩＡＢ－ＤＵは、ｇＮＢ２００と同様に、セルを管理する。ＩＡＢ－ＤＵは、ＵＥ１００及び下位のＩＡＢノードへのＮＲ　Ｕｕ無線インターフェイスを終端する。ＩＡＢ－ＤＵは、ドナーｇＮＢ２００－１のＣＵへのＦ１プロトコルをサポートする。図２において、ＩＡＢノード３００の子ノードがＩＡＢノード３００Ｃ１乃至３００Ｃ３である一例を示しているが、ＩＡＢノード３００の子ノードにＵＥ１００が含まれてもよい。なお、子ノードへ向かう方向は、ダウンストリーム（ｄｏｗｎｓｔｒｅａｍ）と呼ばれる。
　（基地局の構成）
　次に、実施形態に係る基地局であるｇＮＢ２００の構成について説明する。図３は、ｇＮＢ２００の構成を示す図である。図３に示すように、ｇＮＢ２００は、無線通信部２１０と、ネットワーク通信部２２０と、制御部２３０とを有する。
　無線通信部２１０は、ＵＥ１００との無線通信及びＩＡＢノード３００との無線通信を行う。無線通信部２１０は、受信部２１１及び送信部２１２を有する。受信部２１１は、制御部２３０の制御下で各種の受信を行う。受信部２１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部２３０に出力する。送信部２１２は、制御部２３０の制御下で各種の送信を行う。送信部２１２はアンテナを含み、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
　ネットワーク通信部２２０は、５ＧＣ１０との有線通信（又は無線通信）及び隣接する他のｇＮＢ２００との有線通信（又は無線通信）を行う。ネットワーク通信部２２０は、受信部２２１及び送信部２２２を有する。受信部２２１は、制御部２３０の制御下で各種の受信を行う。受信部２２１は、外部から信号を受信して受信信号を制御部２３０に出力する。送信部２２２は、制御部２３０の制御下で各種の送信を行う。送信部２２２は、制御部２３０が出力する送信信号を外部に送信する。
　制御部２３０は、ｇＮＢ２００における各種の制御を行う。制御部２３０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサとＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）とを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。
　（中継ノードの構成）
　次に、実施形態に係る中継ノードであるＩＡＢノード３００の構成について説明する。図４は、ＩＡＢノード３００の構成を示す図である。図４に示すように、ＩＡＢノード３００は、無線通信部３１０と、制御部３２０とを有する。ＩＡＢノード３００は、無線通信部３１０を複数有していてもよい。
　無線通信部３１０は、ｇＮＢ２００との無線通信（ＢＨリンク）及びＵＥ１００との無線通信（アクセスリンク）を行う。ＢＨリンク通信用の無線通信部３１０とアクセスリンク通信用の無線通信部３１０とが別々に設けられていてもよい。
　無線通信部３１０は、受信部３１１及び送信部３１２を有する。受信部３１１は、制御部３２０の制御下で各種の受信を行う。受信部３１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部３２０に出力する。送信部３１２は、制御部３２０の制御下で各種の送信を行う。送信部３１２はアンテナを含み、制御部３２０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
　制御部３２０は、ＩＡＢノード３００における各種の制御を行う。制御部３２０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。
　（ユーザ装置の構成）
　次に、実施形態に係るユーザ装置であるＵＥ１００の構成について説明する。図５は、ＵＥ１００の構成を示す図である。図５に示すように、ＵＥ１００は、無線通信部１１０と、制御部１２０とを有する。
　無線通信部１１０は、アクセスリンクにおける無線通信、すなわち、ｇＮＢ２００との無線通信及びＩＡＢノード３００との無線通信を行う。また、無線通信部１１０は、サイドリンクにおける無線通信、すなわち、他のＵＥ１００との無線通信を行ってもよい。無線通信部１１０は、受信部１１１及び送信部１１２を有する。受信部１１１は、制御部１２０の制御下で各種の受信を行う。受信部１１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１２０に出力する。送信部１１２は、制御部１２０の制御下で各種の送信を行う。送信部１１２はアンテナを含み、制御部１２０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
　制御部１２０は、ＵＥ１００における各種の制御を行う。制御部１２０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。
　（プロトコルスタックの構成）
　次に、実施形態に係るプロトコルスタックの構成について説明する。図６は、ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックを示す図である。
　図６に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Ｍｅｄｉｕｍ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）レイヤと、ＲＬＣ（Ｒａｄｉｏ　Ｌｉｎｋ　Ｃｏｎｔｒｏｌ）レイヤと、ＰＤＣＰ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｃｏｎｖｅｒｇｅｎｃｅ　Ｐｒｏｔｏｃｏｌ）レイヤと、ＲＲＣ（Ｒａｄｉｏ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌ）レイヤと、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）レイヤとを有する。
　ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＰＨＹレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。
　ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（Ａｕｔｏｍａｔｉｃ　Ｒｅｐｅａｔ　Ｒｅｑｕｅｓｔ）（ＨＡＲＱ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＭＡＣレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ＩＡＢ－ＤＵのＭＡＣレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及び割当リソースブロックを決定する。
　ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＲＬＣレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
　ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＰＤＣＰレイヤとドナーｇＮＢ２００のＰＤＣＰレイヤとの間では、無線ベアラを介してデータ及び制御情報が伝送される。
　ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＲＲＣレイヤとドナーｇＮＢ２００のＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ドナーｇＮＢ２００とのＲＲＣ接続がある場合、ＩＡＢ－ＭＴはＲＲＣコネクティッド状態である。ドナーｇＮＢ２００とのＲＲＣ接続がない場合、ＩＡＢ－ＭＴはＲＲＣアイドル状態である。
　ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＮＡＳレイヤとＡＭＦ１１との間では、ＮＡＳシグナリングが伝送される。
　図７は、Ｆ１－Ｕプロトコルに関するプロトコルスタックを示す図である。図８は、Ｆ１－Ｃプロトコルに関するプロトコルスタックを示す図である。ここでは、ドナーｇＮＢ２００がＣＵ及びＤＵに分割されている一例を示す。
　図７に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴ、ＩＡＢノード３００－１のＩＡＢ－ＤＵ、ＩＡＢノード３００－１のＩＡＢ－ＭＴ、及びドナーｇＮＢ２００のＤＵのそれぞれは、ＲＬＣレイヤの上位レイヤとしてＢＡＰ（Ｂａｃｋｈａｕｌ　Ａｄａｐｔａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）レイヤを有する。ＢＡＰレイヤは、ルーティング処理及びベアラマッピング・デマッピング処理を行うレイヤである。バックホールでは、ＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）レイヤがＢＡＰレイヤを介して伝送されることにより、複数のホップでのルーティングが可能になる。
　各バックホールリンクにおいて、ＢＡＰレイヤのＰＤＵ（Ｐｒｏｔｏｃｏｌ　Ｄａｔａ　Ｕｎｉｔ）は、バックホールＲＬＣチャネル（ＢＨ　ＮＲ　ＲＬＣチャネル）によって伝送される。各ＢＨリンクで複数のバックホールＲＬＣチャネルを構成することにより、トラフィックの優先順位付け及びＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）制御が可能である。ＢＡＰ　ＰＤＵとバックホールＲＬＣチャネルとの対応付けは、各ＩＡＢノード３００のＢＡＰレイヤ及びドナーｇＮＢ２００のＢＡＰレイヤによって実行される。
　図８に示すように、Ｆ１－Ｃプロトコルのプロトコルスタックは、図７に示すＧＴＰ－Ｕ（ＧＰＲＳ　Ｔｕｎｎｅｌｌｉｎｇ　Ｐｒｏｔｏｃｏｌ　ｆｏｒ　Ｕｓｅｒ　Ｐｌａｎｅ）レイヤ及びＵＤＰ（Ｕｓｅｒ　Ｄａｔａｇｒａｍ　Ｐｒｏｔｏｃｏｌ）レイヤに代えて、Ｆ１ＡＰ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）レイヤ及びＳＣＴＰ（Ｓｔｒｅａｍ　Ｃｏｎｔｒｏｌ　Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｐｒｏｔｏｃｏｌ）レイヤを有する。
　（第１実施形態）
　次に、上述のようなセルラ通信システム１の構成を前提として、セルラ通信システム１の動作について説明する。
　第１実施形態において、ＩＡＢノード３００（具体的には、ＩＡＢ－ＭＴ）がドナーｇＮＢ２００間で接続切替を行うシナリオを想定する。ＩＡＢノード３００は、移動可能なＩＡＢノード３００であってもよい。接続切替とは、ハンドオーバ又はＲＲＣ再確立をいう。ハンドオーバとは、ＲＲＣコネクティッド状態にあるＩＡＢ－ＭＴがセルを切り替える動作をいう。ＲＲＣ再確立とは、ＲＲＣコネクティッド状態にあるＩＡＢ－ＭＴが無線リンク障害の検知に応じて他セルと再接続する動作をいう。以下において、接続切替がハンドオーバである一例について説明するが、接続切替がＲＲＣ再確立であってもよい。
　ＩＡＢノード３００がドナーｇＮＢ２００間で接続切替を行うシナリオにおいて、このＩＡＢノード３００の配下のＵＥ１００の動作が問題になる。具体的には、ＩＡＢノード３００がドナーｇＮＢ２００間で接続切替を行う場合、このＩＡＢノード３００の配下のＵＥ１００に新たな動作が必要になり得る。しかしながら、後方互換性の観点からは、ＵＥ１００の動作に変更を加えることは好ましくない。
　第１実施形態は、ＵＥ１００側には透過的に、ネットワーク側（ＩＡＢノード側）における動作変更だけでドナーｇＮＢ２００間でのＩＡＢノード３００の接続切替（例えば、ハンドオーバ）を実現する実施例である。このようなハンドオーバは、インターＣＵハンドオーバと呼ばれてもよい。
　具体的には、第１実施形態において、第１に、配下にＵＥ１００を有するＩＡＢノード３００は、第１ドナー基地局であるソースドナーｇＮＢ２００Ｓから、第１ドナー基地局と異なる第２ドナー基地局であるターゲットドナーｇＮＢ２００Ｔへのハンドオーバを行う。第２に、当該ハンドオーバを行っても、ＵＥ１００とソースドナーｇＮＢ２００Ｓとの間のＲＲＣ接続をターゲットドナーｇＮＢ２００Ｔ経由で継続する。第３に、ソースドナーｇＮＢ２００Ｓは、当該ＲＲＣ接続を用いて、ターゲットドナーｇＮＢ２００Ｔへのハンドオーバを指示するハンドオーバ指令をターゲットドナーｇＮＢ２００Ｔ経由でＵＥ１００に送信する。
　すなわち、ＵＥ１００とソースドナーｇＮＢ２００との間のＲＲＣ接続（及びＰＤＣＰ接続）は、ターゲットドナーｇＮＢ２００経由で確立状態が継続され、ソースドナーｇＮＢ２００Ｓは、当該接続を用いてハンドオーバ指令をＵＥ１００に送信する。これにより、ＵＥ１００に動作変更を加えることなく、ドナーｇＮＢ２００間でのＩＡＢノード３００のハンドオーバを実現できる。
　第１実施形態において、ソースドナーｇＮＢ２００ＳとターゲットドナーｇＮＢ２００Ｔとの間にデータパスを確立してもよい。ＩＡＢノード３００のハンドオーバからＵＥ１００のハンドオーバの完了までにおいて、このデータパスを介してＵＥ１００のデータの転送処理（すなわち、データフォワーディング）を行ってもよい。これにより、先にＩＡＢノード３００のハンドオーバを実行し、その後にＵＥ１００のハンドオーバを行っても、ＵＥ１００のデータの消失を防止できる。
　図９は、第１実施形態に係る動作を示す図である。
　図９に示すように、ステップＳ１０１において、ＵＥ１００は、ソースドナーｇＮＢ２００ＳとのＲＲＣ接続を確立した状態（ＲＲＣコネクティッド状態）にある。
　ステップＳ１０２において、ＩＡＢノード３００（ＩＡＢ－ＭＴ）は、ソースドナーｇＮＢ２００ＳとのＲＲＣ接続を確立した状態（ＲＲＣコネクティッド状態）にある。ＩＡＢノード３００とソースドナーｇＮＢ２００Ｓとの間に少なくとも１つの中間ＩＡＢノードが介在してもよい。ＵＥ１００は、ＩＡＢノード３００（ＩＡＢ－ＤＵ）の配下にある。すなわち、ＵＥ１００は、ＩＡＢノード３００（ＩＡＢ－ＤＵ）のセルを自身のサービングセルとしている。
　ステップＳ１０３において、ＩＡＢノード３００（ＩＡＢ－ＭＴ）は、ソースドナーｇＮＢ２００ＳからターゲットドナーｇＮＢ２００ＴへのＲＲＣ再確立（ＲＲＣ　Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）又はハンドオーバ（Ｈａｎｄｏｖｅｒ）を行う。ここではＩＡＢノード３００（ＩＡＢ－ＭＴ）がハンドオーバを行うと仮定して説明を進める。
　ステップＳ１０４において、ＩＡＢノード３００（ＩＡＢ－ＭＴ）は、ハンドオーバの結果、ターゲットドナーｇＮＢ２００ＴとのＲＲＣ接続を確立する。
　この時点では、ＵＥ１００のＲＲＣレイヤ及びＰＤＣＰレイヤは、ソースドナーｇＮＢ２００との接続状態が残っている。このため、ＵＥ１００は、ターゲットドナーｇＮＢ２００Ｔとの通信はＣプレーン及びＵプレーンいずれも行うことができない。
　ここで、ソースドナーｇＮＢ２００ＳとターゲットドナーｇＮＢ２００Ｔとの間でトンネル（すなわち、データフォワーディングのパス）を形成する。このトンネルは、基地局間インターフェイス上に設定されてもよいし、コアネットワークを介して設定されてもよい。
　ステップＳ１０５において、ＵＥ１００は、上りリンクのユーザデータ（Ｕｓｅｒ　ｄａｔａ）をＩＡＢノード３００に送信する。ＩＡＢノード３００は、ユーザデータを受信する。
　ステップＳ１０６において、ＩＡＢノード３００は、ＵＥ１００からのユーザデータをターゲットドナーｇＮＢ２００Ｔに送信する。ターゲットドナーｇＮＢ２００Ｔは、ユーザデータを受信する。
　ステップＳ１０７において、ターゲットドナーｇＮＢ２００Ｔは、ステップＳ１０６で受信したユーザデータをソースドナーｇＮＢ２００Ｓに転送する（Ｄａｔａ　ｆｏｒｗａｒｄｉｎｇ）。ソースドナーｇＮＢ２００Ｓは、ユーザデータを受信する。
　ステップＳ１０８において、ソースドナーｇＮＢ２００Ｓは、ステップＳ１０７で受信したユーザデータをコアネットワークのＵＰＦ１２に転送する。
　ステップＳ１０９において、ソースドナーｇＮＢ２００Ｓは、下りリンクのユーザデータ（Ｕｓｅｒ　ｄａｔａ）をコアネットワークのＵＰＦ１２から受信する。
　ステップＳ１１０において、ソースドナーｇＮＢ２００Ｓは、ステップＳ１０９で受信したユーザデータをターゲットドナーｇＮＢ２００Ｔに転送する（Ｄａｔａ　ｆｏｒｗａｒｄｉｎｇ）。ターゲットドナーｇＮＢ２００Ｔは、ユーザデータを受信する。
　ステップＳ１１１において、ターゲットドナーｇＮＢ２００Ｔは、ステップＳ１１０で受信したユーザデータをＩＡＢノード３００に転送する。ＩＡＢノード３００は、ユーザデータを受信する。
　ステップＳ１１２において、ＩＡＢノード３００は、ステップＳ１１１で受信したユーザデータをＵＥ１００に送信（中継）する。
　このように、ＵＥ１００とソースドナーｇＮＢ２００Ｓとの間のユーザデータの送受信は、ソースドナーｇＮＢ２００ＳとターゲットドナーｇＮＢ２００Ｔとの間のトンネル及びターゲットドナーｇＮＢ２００Ｔ経由で継続する。
　ステップＳ１１３において、ソースドナーｇＮＢ２００Ｓは、ソースドナーｇＮＢ２００ＳとターゲットドナーｇＮＢ２００Ｔとの間のトンネルを介して、ターゲットドナーｇＮＢ２００ＴへのハンドオーバをＵＥ１００に指示するハンドオーバ指令（ＨＯ　Ｃｏｍｍａｎｄ）をターゲットドナーｇＮＢ２００Ｔに送信する。ターゲットドナーｇＮＢ２００は、ハンドオーバ指令を受信する。
　ステップＳ１１４において、ターゲットドナーｇＮＢ２００Ｔは、ステップＳ１１３で受信したハンドオーバ指令を含むＲＲＣメッセージ（ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）をＵＥ１００に送信する。具体的には、ターゲットドナーｇＮＢ２００Ｔは、当該ＲＲＣメッセージをＩＡＢノード３００経由でＵＥ１００に送信する。ＵＥ１００は、当該ＲＲＣメッセージを受信する。
　図１０は、ハンドオーバ指令伝送時におけるプロトコルスタックを示す図である。図１０に示すように、ソースドナーｇＮＢ２００ＳのＲＲＣレイヤからＵＥ１００のＲＲＣレイヤに対して、ターゲットドナーｇＮＢ２００Ｔ及びＩＡＢノード３００経由でハンドオーバ指令（ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）を伝送する。ソースドナーｇＮＢ２００ＳとターゲットドナーｇＮＢ２００Ｔとの通信は基地局間通信で行われる。図９ではＧＴＰの例を示しているが、これに限らない。例えば、Ｘｎ－ＡＰであってもよく、この場合、ハンドオーバ指令はＸｎ－ＡＰメッセージのＲＲＣコンテナに内包されて（カプセル化されて）伝送される。
　図９に戻り、ステップＳ１１５において、ＵＥ１００は、ハンドオーバ指令に応じて、ハンドオーバ完了を示すＲＲＣメッセージ（ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ　Ｃｏｍｐｌｅｔｅ）をターゲットドナーｇＮＢ２００Ｔに送信する。具体的には、ＵＥ１００は、当該ＲＲＣメッセージをＩＡＢノード３００経由でターゲットドナーｇＮＢ２００Ｔに送信する。ターゲットドナーｇＮＢ２００Ｔは、当該ＲＲＣメッセージを受信する。ここで、ＵＥ１００は、ＩＡＢノード３００の配下にあり続けているため、ランダムアクセスプリアンブルの送信及びランダムアクセスレスポンスの受信を省略したＲＡＣＨ－ｌｅｓｓハンドオーバを行ってもよい。この場合、ハンドオーバ指令においてＲＡＣＨ－ｌｅｓｓハンドオーバがＵＥ１００に指示されてもよい。
　ステップＳ１１６において、ＵＥ１００は、ハンドオーバの結果、ターゲットドナーｇＮＢ２００ＴとのＲＲＣ接続を確立する。この時点から、ＵＥ１００のユーザデータはターゲットドナーｇＮＢ２００Ｔとの通信に切り替わる。
　ステップＳ１１７において、ＵＥ１００は、上りリンクのユーザデータ（Ｕｓｅｒ　ｄａｔａ）をＩＡＢノード３００に送信する。ＩＡＢノード３００は、ユーザデータを受信する。
　ステップＳ１１８において、ＩＡＢノード３００は、ステップＳ１１７で受信したユーザデータをターゲットドナーｇＮＢ２００Ｔに送信する。ターゲットドナーｇＮＢ２００Ｔは、ユーザデータを受信する。
　ステップＳ１１９において、ターゲットドナーｇＮＢ２００Ｔは、ステップＳ１１８で受信したユーザデータをコアネットワークのＵＰＦ１２に転送する。
　ステップＳ１２０において、ターゲットドナーｇＮＢ２００Ｔは、下りリンクのユーザデータ（Ｕｓｅｒ　ｄａｔａ）をコアネットワークのＵＰＦ１２から受信する。
　ステップＳ１２１において、ターゲットドナーｇＮＢ２００Ｔは、ステップＳ１２０で受信したユーザデータをＩＡＢノード３００に転送する。ＩＡＢノード３００は、ユーザデータを受信する。
　ステップＳ１２２において、ＩＡＢノード３００は、ステップＳ１２１で受信したユーザデータをＵＥ１００に送信（中継）する。
　（第２実施形態）
　次に、第２実施形態について、上述の実施形態との相違点を主として説明する。
　第２実施形態は、ＩＡＢトポロジ内での負荷分散（ｌｏａｄ　ｂａｌａｎｃｉｎｇ）に関する実施形態である。ＩＡＢノード３００は、基本的にルーティングテーブル（ＢＡＰルーティングＩＤ及びパスＩＤ）によりＩＡＢトポロジ内のパスが半固定的に決定されており、ドナーｇＮＢ２００のＣＵがルーティングテーブルを一括管理している。しかしながら、複数パスを効率的に用いることができれば、より動的な負荷分散が可能になると考えられる。
　第２実施形態において、ＩＡＢノード３００は、複数の中継先ノード（複数のパス）のそれぞれのデータ中継容量を考慮して効率的なデータ中継を行う。具体的には、第２実施形態において、中継元ノードから複数の中継先ノードへデータ中継を行うＩＡＢノード３００は、当該複数の中継先ノードに含まれる対象ＩＡＢノード３００のデータ中継容量に関する容量情報を受信する。そして、ＩＡＢノード３００は、受信した容量情報に基づいてデータ中継を制御する。
　容量情報は、複数の中継先ノードに含まれる対象ＩＡＢノード３００の次ホップのノードが複数存在するか否かを示す情報を含んでもよい。対象ＩＡＢノード３００の次ホップのノードが複数存在する場合、対象ＩＡＢノード３００はデータ中継容量が大きいとみなすことができる。このため、このような対象ＩＡＢノード３００に対して優先的にデータを中継することで、複数パスを効率的に用いることができる。
　ＩＡＢノード３００は、複数の中継先ノードのそれぞれについて容量情報を受信し、受信した容量情報に基づいて、複数の中継先ノードに対するデータ送信比率を制御してもよい。例えば、ＩＡＢノード３００は、データ中継容量が大きい中継先ノードに対して多くのデータを中継し、データ中継容量が小さい他の中継先ノードに対して少ないデータを中継する。
　上述のように、ＩＡＢノード３００は、ドナーｇＮＢ２００から設定されたルーティング設定（ルーティングテーブル）に従って複数の中継先ノードの中からデータ中継先を選択する。ＩＡＢノード３００は、所定条件が満たされた場合、ルーティング設定に従わずにデータ中継先を選択するローカルルーティングを実行してもよい。ここで、所定条件は、複数の中継先ノードのいずれかから障害発生通知又はローカルルーティング要求を受信したという条件を含んでもよい。
　このように、ＩＡＢノード３００は、基本的にはドナーｇＮＢ２００Ｓからの設定に従ってルーティングを行い、中継先ノードの障害発生時又は要求発生時にはＩＡＢノード３００自らローカルルーティングを行うことにより、状況に応じて適切な中継先ノードにデータを中継可能になる。
　（１）アップストリーム中継動作
　第２実施形態に係るアップストリーム中継動作について説明する。
　図１１は、第２実施形態に係るアップストリーム中継動作を説明するための図である。アップストリーム中継動作において、ＩＡＢノード３００の中継元ノードは当該ＩＡＢノード３００の子ノードであり、ＩＡＢノード３００の中継先ノードは当該ＩＡＢノード３００の親ノードである。
　図１１に示すように、ＩＡＢノード３００と、他のＩＡＢノード３００ａ乃至３００ｇと、ドナーｇＮＢ２００とを含むＩＡＢトポロジが形成されている。ＩＡＢノード３００は、子ノード（ＵＥ１００であり得る）から上りリンクパケット（ＵＬ　ｐａｃｋｅｔ）を受信する。ＩＡＢノード３００は、受信した上りリンクパケットを、ドナーｇＮＢ２００から設定されたルーティング設定と、当該上りリンクパケットのヘッダに含まれる情報（ＢＡＰルーティングＩＤ）とに基づいて、親ノードであるＩＡＢノード３００ａ及び／又はＩＡＢノード３００ｂに中継する。
　ＩＡＢノード３００ａ乃至３００ｇのそれぞれは、自ノードの次ホップのノードが複数存在するか否かを示す情報を自ノードの容量情報として子ノードに送信する。アップストリーム中継動作において、このような容量情報を「ＢＨ接続情報」と呼ぶ。ＢＨ接続情報の具体例については後述する。このようなＢＨ接続情報を各ＩＡＢノード３００が子ノードに送信することにより、子ノードは、自身の親ノードの潜在的な容量を把握できるため、ローカルルーティング時において効率的なデータ中継を行うことができる。
　自ノードの次ホップのノードが１つであるＢＨを「シングルＢＨ」と呼び、自ノードの次ホップのノードが２つであるＢＨを「デュアルＢＨ」と呼ぶ。図１１の例において、ＩＡＢノード３００ｂ、３００ｃ、３００ｅ、３００ｆ、及び３００ｇのそれぞれはシングルＢＨである。一方、ＩＡＢノード３００ａ及び３００ｄのそれぞれはデュアルＢＨであり、シングルＢＨに比べてデータ中継容量が大きいとみなすことができる。なお、デュアルＢＨは、デュアルコネクティビティにより二重で接続が確立された状態であってもよい。
　例えば、ＩＡＢノード３００は、親ノード（ＩＡＢノード３００ａ、３００ｂ）のＢＨ接続情報に基づいて送信比率を決定する。ＩＡＢノード３００ａがデュアルＢＨであって、ＩＡＢノード３００ｂがシングルＢＨであるため、親ノードの総ＢＨリンク数は３である。このため、ＩＡＢノード３００は、ローカルルーティングを行う場合、ＩＡＢノード３００ａに対する送信比率を「２／３」に設定し、ＩＡＢノード３００ｂに対する送信比率を残りの「１／３」に設定する。なお、ある親ノードの送信比率をゼロに設定してもよい。この場合、送信比率の決定は、パス選択（パス切替）とみなすことができる。
　図１２は、第２実施形態に係るアップストリーム中継動作を示す図である。この動作はＩＡＢノード３００により実行され、そのうちの少なくとも一部がＢＡＰレイヤ及び／又はＩＡＢ－ＭＴにより実行されてもよい。
　図１２に示すように、ステップＳ２０１において、ＩＡＢノード３００は、ドナーｇＮＢ２００から設定されたルーティング設定に基づいたルーティングを行う。
　ステップＳ２０２において、ＩＡＢノード３００は、ローカルルーティングの開始条件が満たされたか否かを判定する。例えば、開始条件は次のいずれかである。開始条件を定めるパラメータ（閾値等）は、ドナーｇＮＢ２００からＩＡＢノード３００に設定されてもよい。
　・親ノードからＢＨの障害発生通知を受信したという条件：
　例えば、親ノードにおけるＢＨの障害発生通知は、ＢＡＰレイヤのメッセージであるＢＨ　ＲＬＦ　Ｉｎｄｉｃａｔｉｏｎにより親ノードからＩＡＢノード３００に送信される。ＢＨの障害発生通知は、親ノードのＢＨでＲＬＦ（Ｒａｄｉｏ　Ｌｉｎｋ　Ｆａｉｌｕｒｅ）が発生したことを示す通知であってもよいし、親ノードがＢＨのＲＬＦからのリカバリ処理中であることを示す通知であってもよいし、親ノードのＢＨのＲＬＦからのリカバリに失敗したことを示す通知であってもよい。
　・ある親ノードへの上りリンクスループットが一定以下に低下したという条件：
　例えば、ある親ノードに対してＩＡＢノード３００が送信したスケジューリング要求（ＳＲ）が一定回数以上無視された（例えば、上りリンクグラントが来なかった）場合が本条件に該当してもよい。親ノード同士の上りリンクスループットを比較して、過去一定期間上りリンクスループットに一定以上の差（偏り）が発生した場合（かつ、その状態が一定期間以上継続した場合）が本条件に該当してもよい。ある親ノードの上りリンクスループットが一定値以下となった場合（かつ、その状態が一定期間以上継続した場合）が本条件に該当してもよい。
　・親ノードからローカルルーティング要求を受信したという条件：
　ローカルルーティング要求は、ＢＡＰレイヤのメッセージにより親ノードから送信されてもよい。ローカルルーティング要求は、Ｆ１メッセージ又はＲＲＣメッセージによりドナーｇＮＢ２００から親ノード経由で送信されてもよい。ＩＡＢノード３００は、親ノードからのローカルルーティング要求に対して応答を送信してもよいし、後述の送信比率を親ノードに通知してもよい。
　当該ローカルルーティング要求は、ローカルルーティングを行う対象となるベアラ（又はＲＬＣチャネル、又は論理チャネル）の識別子を含んでもよい。ＩＡＢノード３００は、対象のベアラ（又はＲＬＣチャネル、又は論理チャネル）についてローカルルーティングを行い、対象外のベアラ（又はＲＬＣチャネル、又は論理チャネル）についてはローカルルーティングを行わない（すなわち、ルーティングテーブルに従ったルーティングを行う）。
　・ＩＡＢノード３００又はその子ノードの上りリンクバッファ量が一定以上になった（かつ、その状態が一定期間以上継続した）という条件：
　例えば、ＩＡＢノード３００は、子ノードから受信するバッファ状態報告（ＢＳＲ）に基づいて子ノードの上りリンクバッファ量を把握できる。ＢＳＲは、当該子ノードのさらに子ノード（すなわち、孫ノード）の上りリンクバッファ量を加味したものであってもよい。ＢＳＲが示す上りリンクバッファ量が一定以上になった場合（かつ、その状態が一定期間以上継続した場合）が本条件に該当してもよい。
　ローカルルーティングの開始条件が満たされない場合（ステップＳ２０２：Ｎｏ）、ＩＡＢノード３００は、ドナーｇＮＢ２００から設定されたルーティング設定に基づいたルーティングを継続する（ステップＳ２０１）。
　一方、ローカルルーティングの開始条件が満たされた場合（ステップＳ２０２：Ｙｅｓ）、ＩＡＢノード３００は、ローカルルーティングに関する動作を開始する。なお、ＩＡＢノード３００は、ドナーｇＮＢ２００からローカルルーティングの実行が許可されている場合のみ、ローカルルーティングを実行できるとしてもよい。この許可は、ＢＡＰレイヤのメッセージ（ＢＡＰ　Ｃｏｎｔｒｏｌ　ＰＤＵ）、システム情報（ＳＩＢ１）、又はＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ等で行われる。ローカルルーティングの実行可否は、ベアラ（ＲＬＣ　ｃｈａｎｎｅｌ）ごとに設定されてもよいし、全てのベアラに一括設定されてもよい。このような設定と共に、上記のいずれの条件を適用するのか、及びその条件判定に用いる閾値が設定されてもよい。
　ステップＳ２０３において、ＩＡＢノード３００は、各親ノードのＢＨ接続情報を受信する。なお、ステップＳ２０３は、ステップＳ２０２の前に行われてもよい。
　親ノードのＢＨ接続情報は、当該親ノードがシングルＢＨであるのか又はデュアルＢＨであるのか（又はトリプルＢＨであるのか）を示す情報を含んでもよい。親ノードのＢＨ接続情報は、当該親ノードのＢＨの数を示す数値を含んでもよい。ＢＨ接続情報は、各ＢＨリンクのキャパシティに関する情報をさらに含んでもよい。各ＢＨリンクのキャパシティに関する情報は、例えば、各ＢＨリンクの帯域幅、コンポーネントキャリア数、及び周波数帯のうち少なくとも１つを示す情報であってもよいし、各ＢＨリンクの平均スループット（或いは、最大スループット、ＧＢＲ（Ｇｕａｒａｎｔｅｅｄ　Ｂｉｔ　Ｒａｔｅ）等）を示す情報であってもよい。
　ＢＨ接続情報は、親ノードからＩＡＢノード３００に送信されてもよい。例えば、ＢＨ接続情報は、親ノードが送信するＢＡＰ　Ｃｏｎｔｒｏｌ　ＰＤＵ又はシステム情報（例えばＳＩＢ１）に含まれる情報要素であってもよい。親ノードは、自身がデュアルＢＨ（又はトリプルＢＨ）である場合はＢＨ接続情報を送信し、シングルＢＨの場合はＢＨ接続情報を送信しないとしてもよい。ＩＡＢノード３００は、ＢＨ接続情報の送信有無により、シングルＢＨ及びデュアルＢＨを判別する。
　或いは、ＢＨ接続情報は、ドナーｇＮＢ２００からＩＡＢノード３００に送信されてもよい。ドナーｇＮＢ２００が送信するＲＲＣメッセージ（例えばＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）又はＦ１メッセージ（例えばＤＬ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔｒａｎｓｆｅｒ）に含まれる情報要素であってもよい。
　ステップＳ２０４において、ＩＡＢノード３００は、ステップＳ２０３で受信したＢＨ接続情報に基づいて、上りリンクのパケット送信比率を決定する。上述の例のように、ＩＡＢノード３００は、一方の親ノードがデュアルＢＨであって、他方の親ノードがシングルＢＨである場合、当該一方の親ノードに対する送信比率を「２／３」に設定し、当該他方の親ノードに対する送信比率を「１／３」に設定する。ここで、例えば送信比率を０対１に設定する場合、送信先をスイッチした（ローカルスイッチした）と考えられる。ＩＡＢノード３００は、ＢＨ接続情報に含まれる情報（例えば、各ＢＨリンクのキャパシティに関する情報）に基づいて、送信比率を調整又は決定してもよい。ＩＡＢノード３００は、各親ノードに対する過去の送信スループット履歴（或いは、子ノードへの上りリンクグラント履歴（すなわち、受信スループット））に基づいて送信比率を調整又は決定してもよい。
　ステップＳ２０５において、ＩＡＢノード３００は、ステップＳ２０４で決定（及び調整）した送信比率に基づいて、上りリンクパケットのローカルルーティングを行う。ＩＡＢノード３００は、ローカルルーティングを行った上りリンクパケットのヘッダを変更してもよい。例えば、ＢＡＰヘッダにおいて、ルーティングＩＤの変更を行ってもよく、ローカルルーティングが行われたことを示す識別子を付与してもよい。
　ステップＳ２０６において、ＩＡＢノード３００は、ローカルルーティングの終了条件が満たされたか否かを判定する。終了条件は、上述の開始条件の逆の条件とすることができる。例えば、親ノードからＢＨのリカバリ成功通知を受信したという条件、ある親へのスループットが回復したという場合、ローカルルーティング停止要求を受信したという条件、及び子ノード（及び孫ノード）のバッファ状態が改善したという条件のうち、少なくとも１つである。終了条件は、ドナーｇＮＢ２００からローカルルーティング許可が取り消された（不許可に設定された）という条件を含んでもよい。
　ローカルルーティングの終了条件が満たされていない場合（ステップＳ２０６：Ｎｏ）、ＩＡＢノード３００は、ローカルルーティングを継続する（ステップＳ２０５）。一方、ローカルルーティングの終了条件が満たされた場合（ステップＳ２０６：Ｙｅｓ）、ＩＡＢノード３００は、ドナーｇＮＢ２００から設定されたルーティング設定に基づいたルーティングを行う（ステップＳ２０１）。
　（２）ダウンストリーム中継動作
　第２実施形態に係るダウンストリーム中継動作について説明する。
　図１３は、第２実施形態に係るダウンストリーム中継動作を説明するための図である。ダウンストリーム中継動作において、ＩＡＢノード３００の中継元ノードは当該ＩＡＢノード３００の親ノードであり、ＩＡＢノード３００の中継先ノードは当該ＩＡＢノード３００の子ノードである。ダウンストリーム中継動作においては、上述のアップストリーム中継動作における親ノードと子ノードとを入れ替えればよい。なお、図１３において、各ＩＡＢノード３００がデュアルＢＨであって、ＩＡＢノード３００と宛先ノード（Ｄｅｓｔｉｎａｔｉｏｎ）との間に４つのパスが存在する一例を示している。
　図１４は、第２実施形態に係るダウンストリーム中継動作を示す図である。この動作はＩＡＢノード３００により実行され、そのうちの少なくとも一部がＢＡＰレイヤ及び／又はＩＡＢ－ＤＵにより実行されてもよい。ここでは、アップストリーム中継動作との相違点を主として説明する。
　図１４に示すように、ステップＳ３０１において、ＩＡＢノード３００は、ドナーｇＮＢ２００から設定されたルーティング設定に基づいたルーティングを行う。
　ステップＳ３０２において、ＩＡＢノード３００は、ローカルルーティングの開始条件が満たされたか否かを判定する。例えば、開始条件は次のいずれかである。開始条件を定めるパラメータ（閾値等）は、ドナーｇＮＢ２００からＩＡＢノード３００に設定されてもよい。ＩＡＢノード３００は、ドナーｇＮＢ２００からローカルルーティングが許可（設定）されている場合のみ、ローカルルーティングが実行可能であってもよい。当該許可は、Ｆ１メッセージ（Ｆ１ＡＰ）、ＲＲＣメッセージ、又はＢＡＰメッセージにより行われてもよい。当該許可は、ベアラ（ＲＬＣ　ｃｈａｎｎｅｌ）ごとに設定されてもよいし、全てのベアラに一括設定されてもよい。当該許可は、指示であってもよい。また、下記の条件のうちいずれの条件を適用するのか、及びその条件判定に用いる閾値が設定されてもよい。
　・あるパスのスループットが一定以下に低下した場合（かつ、その状態が一定期間以上継続した）という条件。
　・ある子ノードの無線状態が悪くなった（かつ、その状態が一定期間以上継続した）という条件：
　例えば、ＩＡＢノード３００は、子ノードからの測定報告及び／又は子ノードに対するスケジューリング結果（ＭＣＳ等）から無線状態を判定してもよい。
　・ある子ノードの利用可能バッファサイズが一定以下を下回った（かつ、その状態が一定期間以上継続した）という条件：
　例えば、ＩＡＢノード３００のＩＡＢ－ＤＵは、Ｆｌｏｗ　ｃｏｎｔｒｏｌ　ｐｏｌｌｉｎｇ　ＢＡＰ　Ｃｏｎｔｒｏｌ　ＰＤＵを子ノードへ送信し、Ｆｌｏｗ　ｃｏｎｔｒｏｌ　ｆｅｅｄｂａｃｋ　ＢＡＰ　Ｃｏｎｔｒｏｌ　ＰＤＵを子ノードから受信する。そして、ＩＡＢノード３００（ＩＡＢ－ＤＵ）は、Ｆｌｏｗ　ｃｏｎｔｒｏｌ　ｆｅｅｄｂａｃｋ　ＢＡＰ　Ｃｏｎｔｒｏｌ　ＰＤＵで示される利用可能バッファサイズ（空きバッファ量）を特定し、判定を行う。
　ローカルルーティングの開始条件が満たされない場合（ステップＳ３０２：Ｎｏ）、ＩＡＢノード３００は、ドナーｇＮＢ２００から設定されたルーティング設定に基づいたルーティングを継続する（ステップＳ３０１）。
　一方、ローカルルーティングの開始条件が満たされた場合（ステップＳ３０２：Ｙｅｓ）、ＩＡＢノード３００は、ローカルルーティングに関する動作を開始する。ＩＡＢノード３００は、ルーティング設定の中から宛先（Ｄｅｓｔｉｎａｔｉｏｎ）が同一である異なるパスを選択し、当該パスに対応するＩＡＢノードへ下りリンクパケットを送信してもよい。また、ＩＡＢノード３００は、ローカルルーティングを行った下りリンクパケットのヘッダを変更してもよい。例えば、ＢＡＰヘッダにおいて、ルーティングＩＤの変更を行ってもよく、ローカルルーティングが行われたことを示す識別子を付与してもよい。
　ステップＳ３０３において、ＩＡＢノード３００は、各子ノードから利用可能バッファサイズ情報を受信してもよい。
　ステップＳ３０４において、ＩＡＢノード３００は、ダウンストリームパスの選択及び／又は子ノードへの送信比率を決定する。具体的には、ＩＡＢノード３００は、記憶しているルーティング設定の中から、同一の宛先を有する他のパスを選択する。ＩＡＢノード３００は、複数のパスを選択してもよく、この場合、上述のアップストリーム中継動作と同様にして送信比率を決定してもよい。ドナーｇＮＢ２００からＩＡＢノード３００に対して、選択可能なパスの組み合わせが予め設定されていてもよい。
　ステップＳ３０５において、ＩＡＢノード３００は、ステップＳ３０４の結果に応じてローカルルーティングを行う。
　ステップＳ３０６において、ＩＡＢノード３００は、ローカルルーティングの終了条件が満たされたか否かを判定する。終了条件は、上述の開始条件の逆の条件とすることができる。例えば、あるパスのスループットが一定以上に回復したという条件、子ノードの無線状態が一定以上に回復したという条件、子ノードの利用可能バッファサイズが一定以上に回復したという条件のうち、少なくとも１つである。終了条件は、ドナーｇＮＢ２００からローカルルーティング許可が取り消された（不許可に設定された）という条件を含んでもよい。
　ローカルルーティングの終了条件が満たされていない場合（ステップＳ３０６：Ｎｏ）、ＩＡＢノード３００は、ローカルルーティングを継続する（ステップＳ３０５）。一方、ローカルルーティングの終了条件が満たされた場合（ステップＳ３０６：Ｙｅｓ）、ＩＡＢノード３００は、ドナーｇＮＢ２００から設定されたルーティング設定に基づいたルーティングを行う（ステップＳ３０１）。
　（第２実施形態の変更例１）
　次に、第２実施形態の変更例１について、上述の実施形態との相違点を主として説明する。
　上述の第２実施形態において、ＩＡＢノード３００により実行されたローカルルーティングの内容（いつ実行されたか及び何回実施されたか）についてはドナーｇＮＢ２００が把握できない虞がある。ローカルルーティングが実行された場合、ドナーｇＮＢ２００によるルーティング設定に不備がある、或いはＩＡＢトポロジ内で障害が発生した可能性がある。このため、ローカルルーティングの内容をドナーｇＮＢ２００が把握できることが好ましい。これにより、例えばドナーｇＮＢ２００がルーティング設定を最適化することが可能になる。
　本変更例において、中継元ノードから複数の中継先ノードへデータ中継を行うＩＡＢノード３００は、ドナーｇＮＢ２００から設定されたルーティング設定に従って、複数の中継先ノードの中からデータ中継先を選択する。ＩＡＢノード３００は、所定条件が満たされた場合、ルーティング設定に従わずにデータ中継先を選択するローカルルーティングを実行する（第２実施形態を参照）。ＩＡＢノード３００は、このローカルルーティングに関する履歴情報（すなわち、ローカルルーティングの内容を示す情報）をドナーｇＮＢ２００に送信する。
　図１５は、第２実施形態の変更例１の動作を示す図である。
　図１５に示すように、ステップＳ４０１において、ＩＡＢノード３００は、ローカルルーティングを行う。
　ステップＳ４０２において、ＩＡＢノード３００は、ステップＳ４０１で実行したローカルルーティングに関する情報（ローカルルーティング情報）を保存する。ＩＡＢノード３００は、ローカルルーティングを行うたびにそのローカルルーティング情報を保存する。
　ローカルルーティング情報は、ローカルルーティングの実行時刻を示すタイムスタンプ、ローカルルーティングの実行時刻を示す位置情報（緯度経度高度）、ローカルルーティングの実行時の無線状況を示す情報のうち、少なくとも１つを含んでもよい。ローカルルーティング情報は、ローカルルーティングによる変更前後のルーティングＩＤ（パスＩＤ及びＤｅｓｔｉｎａｔｉｏｎ）を含んでもよい。ローカルルーティング情報は、接続中のＩＡＢトポロジのトポロジＩＤ（ドナーｇＮＢ　ＩＤ、ｇＮＢ－ＣＵ　ＩＤでもよい）を含んでもよい。ローカルルーティング情報は、ローカルルーティングを実行した理由（又は条件）を示す情報を含んでもよい。ローカルルーティング情報は、ローカルルーティングを行っていた期間（開始時間、終了時間）及び／又はローカルルーティングを行った回数を示す情報を含んでもよい。なお、ローカルルーティング情報は、ＢＡＰレイヤで保存してもよいし、ＢＡＰレイヤからＲＲＣレイヤに都度報告されてＲＲＣレイヤで保存されてもよい。
　ステップＳ４０３において、ＩＡＢノード３００は、ステップＳ４０２で保存したローカルルーティング情報をドナーｇＮＢ２００へ送信する。ローカルルーティング情報は、例えばＲＲＣメッセージによりＩＡＢノード３００から送信される。当該ローカルルーティング情報は、ドナーｇＮＢ２００からの要求に応じて、応答メッセージとして送信されてもよい。例えば、当該ローカルルーティング情報は、ＵＥ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｒｅｑｕｅｓｔに対する、ＵＥ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｒｅｓｐｏｎｓｅとして送信されてもよい。
　（第２実施形態の変更例２）
　次に、第２実施形態の変更例２について、上述の実施形態との相違点を主として説明する。本変更例は、ＩＡＢノード３００からの要求によりドナーｇＮＢ２００がＩＡＢノード３００のルーティング設定を変更する実施例である。
　本変更例において、中継元ノードから複数の中継先ノードへデータ中継を行うＩＡＢノード３００は、ドナーｇＮＢ２００から設定されたルーティング設定に従って、複数の中継先ノードの中からデータ中継先を選択する。ＩＡＢノード３００は、ルーティング設定を変更するためのルーティング変更要求をドナーｇＮＢ２００に送信する。
　図１６は、第２実施形態の変更例２の動作を示す図である。
　図１６に示すように、ステップＳ５０１において、ＩＡＢノード３００は、ルーティング変更要求をドナーｇＮＢ２００に送信する。ルーティング変更要求は、ルーティング変更を希望する旨の通知であってもよい。ルーティング変更要求は、ＲＲＣメッセージ又はＦ１（Ｆ１ＡＰ）メッセージであってもよい。ルーティング変更要求は、アップストリームルーティング変更の場合とダウンストリームルーティング変更の場合とで別々に規定されてもよい。当該ルーティング変更要求は、ドナーｇＮＢ２００から送信が許可されている場合のみ送信できる、としてもよい。
　ＩＡＢノード３００は、上述の第２実施形態で説明したローカルルーティングの開始条件と同じ条件が満たされたことをトリガとして、ルーティング変更要求を送信してもよい。どのような条件及び判定閾値を用いるかは、ドナーｇＮＢ２００からＩＡＢノード３００に設定されてもよい。ＩＡＢノード３００は、ドナーｇＮＢ２００からルーティング変更要求の送信が許可（設定）されている場合のみルーティング変更要求の送信を行うとしてもよい。
　ルーティング変更要求は、ルーティング設定変更が必要となった理由（又は条件）を示す情報、設定変更対象のルーティングＩＤ（パスＩＤ、Ｄｅｓｔｉｎａｔｉｏｎ）、設定変更対象のＲＬＣ　Ｃｈａｎｎｅｌ　ＩＤ（ベアラＩＤ、ＬＣＩＤでもよい）のうち、少なくとも１つを含んでもよい。
　アップストリームルーティング変更の場合、ＩＡＢノード３００は、自身のＢＳＲ値をルーティング変更要求に含めてもよい。また、ＩＡＢノード３００は、デュアルＢＨ（デュアルコネクティビティの場合、親ノードごと（パス毎）にＢＳＲ値をルーティング変更要求に含めてもよい。ＩＡＢノード３００は、自身の子ノードのＢＳＲ値又はそれが加味された自身のＢＳＲ値をルーティング変更要求に含めてもよい。このようなＢＳＲ値の送信は、ＩＡＢトポロジ内の各ＩＡＢノード３００が定期的にドナーｇＮＢ２００に対して行ってもよい。
　ダウンストリームルーティング変更の場合、ＩＡＢノード３００は、自身の利用可能バッファサイズ値及び／又は自身の子ノードの利用可能バッファサイズ値（Ｆｌｏｗ　ｃｏｎｔｒｏｌ　ｆｅｅｄｂａｃｋ　ＢＡＰ　Ｃｏｎｔｒｏｌ　ＰＤＵ値）をルーティング変更要求に含めてもよい。このような利用可能バッファサイズ値の送信は、ＩＡＢトポロジ内の各ＩＡＢノード３００が定期的にドナーｇＮＢ２００に対して行ってもよい。
　ステップＳ５０２において、ドナーｇＮＢ２００は、ステップＳ５０１で受信したルーティング変更要求に応じてＩＡＢノード３００のルーティング設定を変更する。ＩＡＢノード３００は、必要に応じて、ＩＡＢノード３００のハンドオーバ（すなわち、ＩＡＢトポロジ変更）を行ってもよい。
　なお、ＩＡＢノード３００は、ルーティング変更要求を送信した際にタイマを始動し、このタイマが満了するまで次のルーティング変更要求の送信が禁止されてもよい。このタイマのタイマ値は、ドナーｇＮＢ２００からＩＡＢノード３００に対して設定されてもよい。
　（その他の実施形態）
　上述の実施形態及び変更例は、別々の実施形態及び変更例を相互に組み合わせて実施可能である。また、第２実施形態の変更例１及び２は、第２実施形態と併用してもよいし、第２実施形態とは別に実施してもよい。
　上述の実施形態及び変更例において、ＩＡＢによる中継伝送を例として説明したがこれに限られず、その他の中継伝送システムに適用してもよい。例えば、上述の実施形態及び変更例に係る動作を、リレーノード（レイヤ３中継ノード）、サイドリンクリレー（ユーザ装置間の直接通信に用いるサイドリンクを使った中継ノード）などに適用してもよい。
　上述の実施形態において、セルラ通信システム１が５Ｇセルラ通信システムである一例について主として説明した。しかしながら、セルラ通信システム１における基地局はＬＴＥ基地局であるｅＮＢであってもよい。また、セルラ通信システム１におけるコアネットワークはＥＰＣ（Ｅｖｏｌｖｅｄ　Ｐａｃｋｅｔ　Ｃｏｒｅ）であってもよい。さらに、ｇＮＢがＥＰＣに接続することもでき、ｅＮＢが５ＧＣに接続することもでき、ｇＮＢとｅＮＢとが基地局間インターフェイス（Ｘｎインターフェイス、Ｘ２インターフェイス）を介して接続されてもよい。
　上述の実施形態及び変更例に係る各処理をコンピュータに実行させるプログラムが提供されてもよい。また、プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。ＵＥ１００、ｇＮＢ２００、又はＩＡＢノード３００が行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップセットが提供されてもよい。
　本願は、米国仮出願第６３／０６１８８７号（２０２０年８月６日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
　（付記）
　（導入）
　ＮＲ　ｅＩＡＢ（Ｅｎｈａｎｃｅｍｅｎｔｓ　ｔｏ　Ｉｎｔｅｇｒａｔｅｄ　Ａｃｃｅｓｓ　ＡＮＤ　Ｂａｃｋｈａｕｌ）に関する改訂されたワークアイテムが承認された。いくつかの目的は次の通りである。
　トポロジ適応の拡張
　　・シグナリング負荷を軽減するための機能拡張を含む、堅牢性及び負荷分散を強化するためのインタードナーＩＡＢノード移動のための手順の仕様。
　　・ＩＡＢノード移動及びＢＨ　ＲＬＦ回復によるサービス中断削減のための拡張機能の仕様。
　　・ＣＰ／ＵＰ分離のサポートを含む、トポロジの冗長性に対する拡張の仕様。
　トポロジ、ルーティング、及びトランスポートの機能拡張
　　・トポロジ全体の公平性、マルチホップ遅延、及び輻輳緩和を改善するための拡張機能の仕様。
　この付記では、バックホールリンク品質の想定、ＢＨ　ＲＬＦインジケーションの拡張、ＢＨ　ＲＬＦ回復及びセル（再）選択、及びロスレス配信の拡張の観点から、Ｒｅｌ－１７　ｅＩＡＢのトポロジ適応拡張の最初の考慮事項について議論する。
　（議論）
　（バックホールリンク品質の想定）
　Ｒｅｌ－１５の研究段階で、ＴＲは、要件の背景の１つとして、「無線バックホールリンクは、車両などの移動物体、季節の変化（葉）、インフラストラクチャの変化（新しい建物）などによる閉塞に対して脆弱である。このような脆弱性は、物理的に静止しているＩＡＢノードにも当てはまる。」と述べている。そのため、ＴＲでキャプチャされたように、マルチホップ／無線バックホールに起因するさまざまな課題とこれらの潜在的な解決策が研究された。
　所見１：Ｒｅｌ－１５の研究では、不安定なバックホールリンクによって引き起こされるさまざまな課題とこれらの潜在的な解決策が特定され、ＴＲ３８．８７４で十分にキャプチャされた。
　Ｒｅｌ－１６の規範的なワークでは、ＩＡＢノードは静止している、即ち、「固定ＩＡＢノード」であると想定された。そのため、バックホール（ＢＨ）は、ミリ波を介したバックホールリンク及び／又は管理されていない方法で展開される可能性のあるローカルエリアＩＡＢノードの場合でも、適切に設計された展開で十分に安定した。そのため、ＢＨ　ＲＬＦの基本機能、即ち、ＢＨ　ＲＬＦインジケーション（別名、「回復失敗」のタイプ４）及びＲＲＣ再確立、ＭＣＧ／ＳＣＧ障害インジケーション、及び／又は条件付きハンドオーバなどの既存機能と組み合わされた回復手順のみが規定された。
　所見２：Ｒｅｌ－１６　ＩＡＢでは、十分に安定したバックホールリンクを持つ固定ＩＡＢノードのみが想定された。
　Ｒｅｌ－１７の拡張では、意図されたユースケースの1つは「モバイルＩＡＢノード」であり、ＷＩＤに明示的に記載されていなくても、「インタードナーＩＡＢノード移動」の一部である可能性がある。さらに、「ＩＡＢノード移動及びＢＨ　ＲＬＦ回復によるサービス中断削減のための拡張機能」及び「トポロジの冗長性に対する拡張」のようなＷＩＤにおけるサブ目的は、ＢＨリンクが安定していないことを明確に意図しており、移動及びＢＨ　ＲＬＦはＲｅｌ－１７展開のシナリオで頻繁に発生する。従って、Ｒｅｌ－１７の議論によれば、ＲＡＮ２は最初にＢＨリンクの想定について共通の理解を有するべきである。
　提案１：ＲＡＮ２は、バックホールリンクの品質が動的に変化することを想定すべきである。従って、バックホールＲＬＦは、Ｒｅｌ－１７　ｅＩＡＢのようにまれなケースではない。
　（ＢＨ　ＲＬＦインジケーションの拡張）
　Ｒｅｌ－１６のＥメールディスカッションでは、図１７に示すような４種類のＢＨ　ＲＬＦ通知が議論された。
　最後に、タイプ４の「回復失敗」のみがＲｅｌ－１６のＢＨ　ＲＬＦインジケーションとして規定され、これにより、子ＩＡＢ－ＭＴはＢＨリンク上のＲＬＦを考慮し、ＲＬＦ回復手順を開始する。
　所見３：Ｒｅｌ－１６では、タイプ４の「回復障害」のみがＢＨ　ＲＬＦインジケーションとして規定された。
　一方で、多くの企業は依然として他の種類のインジケーションが有益であると考えていたので、それはＥメールでさらに議論された。１３社中８社がタイプ２の「回復を試みている」を導入することを好み、他の２社はＲｅｌ－１７で議論されると考えた。従って、大多数の企業は、Ｒｅｌ－１７にタイプ２のインジケーションを導入する準備ができていると考えていると見なされ得る。ＢＡＰ　Ｃｏｎｔｒｏｌ　ＰＤＵ、ＳＩＢ１、又はその両方を使用することなどによって、タイプ２のインジケーションを送信する方法は、更なる検討が必要である。なお、タイプ１及びタイプ２は全く同じ意味である。
　提案２：ＲＡＮ２は、ＢＨ　ＲＬＦインジケーションのタイプ２の「回復を試みている」が導入されていることに合意すべきである。ＢＡＰ　Ｃｏｎｔｒｏｌ　ＰＤＵ、ＳＩＢ１、又はその両方を介して送信されるかは更なる検討が必要である。
　さらに、１３社のうち９社が、Ｒｅｌ－１７でもタイプ３の「ＢＨリンク回復」について議論することに合意した。詳細には、そのような明示的なインジケーションは本当に必要かが検討され得る。例えば、タイプ２のインジケーションがＳＩＢ１を介して送信される場合、ＢＨリンクがＲＬＦの下にない（即ち、「回復される」）と、インジケーションはブロードキャストされなくなる。従って、ダウンストリームＩＡＢノード及びＵＥは、ＳＩＢ１にタイプ２のインジケーションがないことに基づいてＢＨリンクが回復したかどうかを認識するであろう。もちろん、タイプ３のインジケーションがＢＡＰ　Ｃｏｎｔｒｏｌ　ＰＤＵを介して送信される場合、ダウンストリームＩＡＢノードがＢＨリンク回復をすばやく知ることができるという利点がある。但し、この場合、ＵＥはＢＡＰレイヤを持たないため、事実を知ることができない。従って、ＲＡＮ２は、タイプ３のインジケーションが必要かを議論すべきである。
　提案３：提案３に合意できる場合、ＲＡＮ２は、ＢＨ　ＲＬＦがなくなったときの明示的なＢＨ　ＲＬＦインジケーション、即ち、タイプ３の「ＢＨリンク回復」が導入されるかについて議論すべきである。
　提案２及び／又は提案３に合意できる場合、インジケーションを受信したＩＡＢ－ＭＴのＢＨリンクの回復下における動作を検討すべきである。ＩＡＢ－ＭＴは、タイプ２を受信するとＳＲを削減/停止し、タイプ３を受信する（即ち、親ＩＡＢノードでＢＨ　ＲＬＦがなくなる）と動作を再開することが提案された。これは、親ノードがＢＨリンクを回復しようとするときに望ましいＩＡＢ－ＭＴの動作の1つである。全てのＲＢを中断するなど、他のＩＡＢ－ＭＴの動作も可能であると想定される。
　提案４：ＲＡＮ２は、ＩＡＢ－ＭＴがタイプ２のインジケーションを受信した後、スケジューリング要求を削減/停止し、親ノードでＢＨ　ＲＬＦがなくなった場合に、スケジューリング要求を再開することに合意すべきである。
　提案５：ＲＡＮ２は、親ノードがＢＨリンクを回復しようとしている間、他のＩＡＢ-ＭＴの動作がある場合、議論すべきである。
　インジケーションを送信するＩＡＢ－ＤＵに関して、ＩＡＢノードのBHリンクがRLF下にある場合、タイプ２のＢＨ　ＲＬＦインジケーションを送信することが想定される。このＢＨリンクでＲＬＦが発生するとインジケーションが送信されるため、単一接続のＢＨの場合は簡単である。しかしながら、二重接続のＢＨの場合は少し複雑になる。例えば、ＩＡＢノードがＭＣＧでＲＬＦを検出すると、ＭＣＧ障害情報手順を開始するが、ＳＣＧは引き続きＢＨリンクとして機能するため、この時点でタイプ２のインジケーションを送信する必要がない可能性がある。Ｔ３１６の満了などで、ＭＣＧ障害情報手順が失敗した場合、ＩＡＢ－ＭＴはＲＲＣ再確立を開始するため、この時点でタイプ２のインジケーションが送信される。従って、タイプ２のインジケーションは、ＭＣＧ／ＳＣＧ障害情報がトリガされたときではなく、ＲＲＣ再確立が開始されたときに送信される。いずれにせよ、これはＩＡＢ－ＤＵの動作を対象としているため、仕様にキャプチャするかどうか／どのようにキャプチャするかを慎重に検討すべきである。即ち、ステージ２、ステージ３で、ｎｏｔｅを追加するか或いは何もキャプチャする必要がないかを検討すべきである。
　提案６：ＲＡＮ２は、ＩＡＢ－ＤＵがＲＬＦ回復手順のいずれかを開始するときではなく、ＲＲＣ再確立を開始するときに、タイプ２のＢＨ　ＲＬＦインジケーションを送信する可能性があることに合意すべきである。
　提案７：ＲＡＮ２は、仕様でＩＡＢ-ＤＵの動作（即ち、提案６）をキャプチャするかどうか/どのようにキャプチャするかについて議論すべきである。
　（ＢＨ　ＲＬＦ回復及びセル（再）選択の拡張）
　ＲＲＣ再確立手順では、ＩＡＢ－ＭＴは、適切なセルを見つけるために、最初にセル選択手順を実行する。このセル選択手順では、ＩＡＢ－ＭＴが子孫ノードを選択する可能性があるなど、潜在的な課題がＲｅｌ－１６で指摘された。従って、それはＥメールディスカッションで議論された。
　図１８に示すように、考えられる５つの解決策について、ラポーターの見解とともに議論及び要約した。
　結論は、「Ｒｅｌ－１６ではこのトピックに関してこれ以上のアクションは取らない」であった。これは、ＲＡＮ２が「オプション４：ＢＨ接続がない場合、ＲＲＣ再確立は失敗するため、何も必要ない」に合意したことを意味する。オプション４は、失敗（Ｔ３０１の満了）を待ち、最終的にアイドルに移動する必要があるため、ＢＨ　ＲＬＦ回復にさらに時間が必要である場合でも、Ｒｅｌ－１６の展開シナリオでは受け入れ可能であった。
　所見４：Ｒｅｌ－１６では、ＩＡＢノードが子孫ノードに対してＲＲＣ再確立要求を試行した場合、ＩＡＢノードはその失敗を待ち、最終的にアイドルに移動する必要がある。
　Ｒｅｌ－１７では、提案１の観点から、セル（再）選択及びＲＲＣ再確立が頻繁に発生する可能性がある。従って、準最適な動作、即ち、所見４に従う動作は、ＩＡＢトポロジの安定性及びサービス継続性の観点からパフォーマンスが大幅に低下を引き起こすであろう。従って、ＢＨ　ＲＬＦ回復中のＩＡＢ－ＭＴの動作を最適化するために、上記のメールディスカッションのラポーターが述べているように、「このトピックについては、Ｒｅｌ－１７で再度議論され得る」。
　提案８：ＲＡＮ２は、不適切なノード（例えば、子孫ノード）への再確立を回避するために、セル（再）選択の最適化が検討されることに合意すべきである。
　上記のオプション４を除いて特定された解決策の中で、共通概念は、セル選択の目的で、ＩＡＢ－ＭＴはホワイトリストまたはブラックリストのいずれかの種類で提供されることであると見なされ得る。例えば、「インタードナーＩＡＢノードの移動」によって、トポロジ変更がＲｅｌ－１７で頻繁に発生する可能性があることを考えると、ホワイトリストとブラックリストには、トポロジ及びＩＡＢノードの位置に応じて長所と短所とがある。
　例えば、ＩＡＢドナーの近くのＩＡＢノード、即ち、ＤＡＧトポロジの最上位の観点からは、候補ノードの数が少なく、場合によってはＩＡＢドナーＤＵのみであるため、ホワイトリストを提供する方が合理的である。
　しかしながら、ＩＡＢドナーから遠く離れたＩＡＢノード、即ち、ＤＡＧトポロジの最下位からの観点である別の例では、ホワイトリストに膨大な数の候補ノードを含める必要がある可能性がある。代わりに、ブラックリストは、例えば、懸念されるＩＡＢノードのダウンストリームＩＡＢノードのみを含み、場合によっては少数の子ＩＡＢノードのみを含むため、この場合はオーバーヘッドが少ないという利点がある。
　ホワイトリストの懸念事項の１つは、Ｒｅｌ－１７の「インタードナーＩＡＢノードの移動」の性質上、異なる／隣接するＩＡＢトポロジに属する候補ＩＡＢノードを含める必要がある場合があり、リストのサイズが大きくなる可能性があることである。一方で、ダウンストリームＩＡＢノードは同じＩＡＢトポロジに属していることは言うまでもないため、ブラックリストはそれを気にする必要がない。
　所見５：ホワイトリスト及びブラックリストには、ＩＡＢノードのトポロジ及び位置に応じて長所と短所とがある。
　従って、セル選択の目的で子ＩＡＢノードに情報を提供する場合、ＩＡＢドナー（又は親ＩＡＢノード）がホワイトリスト又はブラックリストのどちらかを選択できることが望ましい。なお、当該情報は、セル再選択の目的で再利用することが有益であると考えられる。
　提案９：ＲＡＮ２は、子孫ノードへの再確立を回避するために、セル選択の目的でＩＡＢ－ＭＴにホワイトリスト又はブラックリスト（即ち、選択構造）が提供されることに合意すべきである。これらのリストをセル再選択手順にも使用できるかは更なる検討が必要である。
　提案９に合意できる場合、情報、即ち、ホワイトリスト又はブラックリストの提供方法をさらに検討すべきである。オプション１は、ＣＨＯ設定を想定しており、いくつかの拡張が必要になる可能性がある。オプション２は、追加のインジケーションを想定しており、例えば、タイプ２のＢＨ　ＲＬＦインジケーションなどである。オプション３は、既存設定にはないトポロジ全体の情報を提供することを想定している。オプション５は、ＯＡＭによる設定を想定しているが、ラポーターが指摘したように、これは疑わしい。
　Ｒｅｌ－１７の想定（即ち、提案１）、即ち、トポロジ変更が発生したら、親ＩＡＢノード又はＩＡＢドナーが子ＩＡＢノードにリストを提供すべきであることを再度考慮すると、ホワイトリスト／ブラックリストの提供方法は動的な方法であるべきである。従って、オプション５、即ち、ＯＡＭは除外すべきである。どの方法、即ち、オプション１、２、又は３のうちのどの方法を拡張のベースラインにするかは、更なる検討が必要である。
　提案１０：ＲＡＮ２は、トポロジが変更されるたびに、ホワイトリスト／ブラックリストが親ＩＡＢノード又はＩＡＢドナーによって動的に提供されることに合意すべきである。詳細は更なる検討が必要である。
　（ロスレス配信の拡張）
　Ｒｅｌ－１５の研究段階では、マルチホップＲＬＣ　ＡＲＱの課題が、ＴＲのセクション８．２．３で議論され、キャプチャされた。Ｒｅｌ－１６では、プロトコルスタックは分離されていないＲＬＣ層を有するＩＡＢに対して定義された。つまり、Ｒｅｌ－１６では、ｅｎｄ－ｔｏ－ｅｎｄ　ＡＲＱは除外され、ｈｏｐ－ｂｙ－ｈｏｐ　ＡＲＱが採用された。
　ｈｏｐ－ｂｙ－ｈｏｐ　ＡＲＱに関しては、ｅｎｄ－ｔｏ－ｅｎｄの信頼性、即ち、ＵＬパケットでのロスレス配信における課題が特定された。図１９に示すように、３つの解決策が特定され、評価された。
　Ｒｅｌ－１６では、第１の解決策である「ＰＤＣＰプロトコル／手順の変更」はＲｅｌ－１５　UEに影響を与えるため、採用されなかった。
　第２の解決策である「中間ＩＡＢノードでバッファリングされたＰＤＣＰ　ＰＤＵの再ルーティング」は、ＢＡＰレイヤでの実装選択としてサポートされた。さらに、ＢＡＰレイヤは、「例えば、ＲＬＣ－ＡＭエンティティが確認応答を受信するまで、ＢＡＰエンティティの送信部分でのデータバッファリングすることは、実装依存」で実行してもよい。これらのＢＡＰ実装は、Ｒｅｌ－１６展開シナリオの「ほとんど」の場合、即ち、固定ＩＡＢノードを使用した場合、パケット損失を回避するために考慮されたが、例えば、図１９のように完全ではなかった。
　第３の解決策である「ＵＬステータス配信の導入」は、図１９に引用されている評価結果を考慮して、ＵＬデータのロスレス配信を保証するための約束された解決策であった。アイデアは、ＵＥへのＲＬＣ　ＡＲＱを遅延させ、ＵＥでのＰＤＣＰデータ回復が必要なときに開始されるようにすることであった。しかしながら、固定ＩＡＢノードが想定されていたため、トポロジ変更によりＵＬパケットがドロップされることはまれであると見なされていたため、Ｒｅｌ－１６では規定されなかった。
　Ｒｅｌ－１７の想定を考えると、即ち、提案１の観点から、Ｒｅｌ－１７で頻繁に発生するトポロジ変更中にULパケットを損失することがもはやまれではないため、第３の解決策をさらに検討すべきである。従って、ＲＡＮ２は、ＴＲでキャプチャされた結果に加えて、Ｌ２マルチホップネットワーク内でロスレス配信を保証するための拡張メカニズムについて議論すべきである。
　提案１１：ＲＡＮ２は、ＴＲ３８．８７４で特定される解決策、即ち、何らかの形式の「ＵＬステータス配信」に基づいてトポロジ変更が頻繁に発生する可能性がある条件下で、ロスレス配信を保証するメカニズムを導入することに合意すべきである。
　第３の解決策、即ち、「ＵＬステータス配信の導入」の詳細については、図２０に示すように、ＥメールディスカッションでＣ－１及びＣ－２の２つのオプションについて議論した。
　上記のＣ－１に関して、マルチホップＬ２ネットワークを介したｅｎｄ－ｔｏ－ｅｎｄのシグナリング転送のために、ＩＡＢドナーからの「確認」をＢＡＰ又はＲＲＣで規定する必要があると想定される。従って、このオプションを規定するためには、比較的高い標準的な取り組みが必要になるであろう。
　上記のＣ－２に関して、ＩＡＢトポロジで十分に機能する場合、ＯＡＭがこのオプションを使用して全てのＩＡＢノードを設定すると想定される必要があっても、ＲＬＣ　ＡＣＫをＵＥ（又はダウンストリームＩＡＢノード）に送信する場合、最終的にＩＡＢ－ＤＵ実装に依存するため、Ｒｅｌ－１６　ＩＡＢノードに対しても実際に実装可能である。さらに、ｈｏｐ－ｂｙ－ｈｏｐフィードバックを想定し、追加のＣｏｎｔｒｏｌ　ＰＤＵを想定しないため、Ｃ－１よりも簡単である。従って、Ｃ－２は、ＵＬパケットのロスレス配信のためのＲｅｌ－１７の拡張ベースラインであるべきである。
　所見６：「ＵＬステータス配信の導入」の解決策であるＣ－２は、Ｒｅｌ－１７の拡張ベースラインとなる可能性があり、これは、Ｒｅｌ－１６に対しても実装可能である。
　但し、Ｒｅｌ－１７は、ＵＬパケット損失を引き起こす動的なトポロジ変更を想定すべきであるため、Ｒｅｌ－１７の拡張はＣ－２を標準のサポート機能としてサポートするであろう。少なくともステージ２の仕様では、Ｃ－２に基づく全体的なメカニズムを説明すべきである。それ以外の場合、３ＧＰＰ標準では、ＩＡＢノードのハンドオーバ中にロスレス配信が保証されない。さらに、ステージ３ではＲＬＣ及び／又はＢＡＰなどの小さな変更が予想されますが、ＩＡＢノードの内部動作と見なされるため、詳細を規定しない可能性もある。
　提案１２：ＲＡＮ２は、ステージ２でＵＬパケットをロスレス配信するためのＲＬＣ　ＡＲＱメカニズムを規定することに合意すべきである。これは、親ＩＡＢノードからＡＣＫを受信する前に、子ノード／ＵＥへのＡＣＫの送信を遅らせる（即ち、Ｃ－２）。ステージ３で規定するかどうか／どのように規定するかは更なる検討が必要である。

Claims (12)

  1. 　セルラ通信システムで用いる通信制御方法であって、
    　中継元ノードから複数の中継先ノードへデータ中継を行う中継ノードが、ドナー基地局から設定されたルーティング設定に従って前記複数の中継先ノードの中からデータ中継先を選択することと、
    　前記中継ノードが、所定条件が満たされた場合、前記ルーティング設定に従わずに前記データ中継先を選択するローカルルーティングを実行することと、を有し、
    　前記所定条件は、前記複数の中継先ノードのいずれかから障害発生通知を受信したという条件を含む
    　通信制御方法。
  2. 　前記所定条件は、前記複数の中継先ノードのいずれかからｆｌｏｗ　ｃｏｎｔｒｏｌに関する情報を受信したという条件を含む
    　請求項１に記載の通信制御方法。
  3. 　前記所定条件は、前記複数の中継先ノードのいずれかからローカルルーティング要求を受信したという条件を含む
    　請求項１又は２に記載の通信制御方法。
  4. 　前記所定条件は、前記中継ノード又は前記中継元ノードのいずれかの上りリンクバッファ量が一定以上になったという条件を含む
    　請求項１乃至３のいずれか１項に記載の通信制御方法。
  5. 　前記中継ノードが、ドナーノードから前記ローカルルーティングを許可することを示す情報を受信することをさらに含む
    　請求項１乃至４のいずれか１項に記載の通信制御方法。
  6. 　セルラ通信システムで用いる通信制御方法であって、
    　配下にユーザ装置を有する中継ノードが、第１ドナー基地局から第２ドナー基地局への接続切替を行うことと、
    　前記接続切替を行っても、前記ユーザ装置と前記第１ドナー基地局との間のＲＲＣ（Ｒａｄｉｏ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌ）接続を前記第２ドナー基地局経由で継続することと、
    　前記第１ドナー基地局が、前記ＲＲＣ接続を用いて、前記第２ドナー基地局へのハンドオーバを指示するハンドオーバ指令を前記第２ドナー基地局経由で前記ユーザ装置に送信することと、を有する
    　通信制御方法。
  7. 　前記第１ドナー基地局と前記第２ドナー基地局との間にデータパスを確立することと、
    　前記接続切替から前記ハンドオーバの完了までにおいて、前記データパスを介して前記ユーザ装置のデータの転送処理を行うことと、をさらに有する
    　請求項６に記載の通信制御方法。
  8. 　セルラ通信システムで用いる通信制御方法であって、
    　中継元ノードから複数の中継先ノードへデータ中継を行う中継ノードが、前記複数の中継先ノードに含まれる対象中継ノードのデータ中継容量に関する容量情報を受信することと、
    　前記中継ノードが、前記容量情報に基づいて前記データ中継を制御することと、を有する
    　通信制御方法。
  9. 　前記容量情報は、前記対象中継ノードの次ホップのノードが複数存在するか否かを示す情報を含む
    　請求項８に記載の通信制御方法。
  10. 　前記受信することは、前記中継ノードが、前記複数の中継先ノードのそれぞれの前記容量情報を受信することを含み、
    　前記制御することは、前記容量情報に基づいて、前記複数の中継先ノードに対するデータ送信比率を制御することを含む
    　請求項８又は９に記載の通信制御方法。
  11. 　セルラ通信システムで用いる通信制御方法であって、
    　中継元ノードから複数の中継先ノードへデータ中継を行う中継ノードが、ドナー基地局から設定されたルーティング設定に従って、前記複数の中継先ノードの中からデータ中継先を選択することと、
    　前記中継ノードが、前記ルーティング設定を変更するためのルーティング変更要求を前記ドナー基地局に送信することと、を有する
    　通信制御方法。
  12. 　セルラ通信システムで用いる通信制御方法であって、
    　中継元ノードから複数の中継先ノードへデータ中継を行う中継ノードが、ドナー基地局から設定されたルーティング設定に従って、前記複数の中継先ノードの中からデータ中継先を選択することと、
    　前記中継ノードが、所定条件が満たされた場合、前記ルーティング設定に従わずに前記データ中継先を選択するローカルルーティングを実行することと、
    　前記ローカルルーティングに関する履歴情報を前記ドナー基地局に送信することと、を有する
    　通信制御方法。
PCT/JP2021/029108 2020-08-06 2021-08-05 通信制御方法 Ceased WO2022030578A1 (ja)

Priority Applications (7)

Application Number Priority Date Filing Date Title
CN202510461340.2A CN120282237A (zh) 2020-08-06 2021-08-05 通信控制方法、中继节点以及处理器
JP2022541725A JP7328458B2 (ja) 2020-08-06 2021-08-05 通信制御方法、中継ノード及びプロセッサ
EP21853606.8A EP4178246B1 (en) 2020-08-06 2021-08-05 Iab local routing conditioned by buffer size
CN202180068277.6A CN116325849A (zh) 2020-08-06 2021-08-05 通信控制方法
US18/164,242 US12574986B2 (en) 2020-08-06 2023-02-03 Communication control method
JP2023127002A JP7594637B2 (ja) 2020-08-06 2023-08-03 通信制御方法、第１ドナー基地局、及びシステム
JP2024204065A JP7814477B2 (ja) 2020-08-06 2024-11-22 通信制御方法、第１ドナー基地局、及びシステム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202063061887P 2020-08-06 2020-08-06
US63/061,887 2020-08-06

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/164,242 Continuation US12574986B2 (en) 2020-08-06 2023-02-03 Communication control method

Publications (1)

Publication Number Publication Date
WO2022030578A1 true WO2022030578A1 (ja) 2022-02-10

Family

ID=80118104

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/029108 Ceased WO2022030578A1 (ja) 2020-08-06 2021-08-05 通信制御方法

Country Status (5)

Country Link
US (1) US12574986B2 (ja)
EP (1) EP4178246B1 (ja)
JP (3) JP7328458B2 (ja)
CN (2) CN116325849A (ja)
WO (1) WO2022030578A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023169153A1 (zh) * 2022-03-07 2023-09-14 华为技术有限公司 通信方法和装置
US20230413127A1 (en) * 2020-10-21 2023-12-21 Fujitsu Limited Migration method and apparatus for iab-node
JPWO2024034571A1 (ja) * 2022-08-08 2024-02-15

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2605492B (en) * 2021-03-30 2026-04-01 Samsung Electronics Co Ltd Improvements in and relating to data loss due to donor change in a multi-hop network
US12156187B2 (en) * 2021-11-23 2024-11-26 At&T Intellectual Property I, L.P. Frequency division multiplexing operation for integrated access and backhaul (IAB)
US12556990B2 (en) * 2022-12-14 2026-02-17 Verizon Patent And Licensing Inc. Systems and methods for handover for mobile integrated access and backhaul nodes
KR20240163896A (ko) * 2023-05-11 2024-11-19 삼성전자주식회사 차세대 이동통신 시스템에서 액세스 백홀 결합 시스템의 이동을 위한 랜덤 액세스 없이 핸드오버를 하는 방법 및 장치
JP7619407B1 (ja) 2023-09-08 2025-01-22 ａｒｔｉｅｎｃｅ株式会社 活性エネルギー線硬化型組成物

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000004469A (ja) * 1998-06-17 2000-01-07 Nec Corp 無線通信システムと基地装置及び無線伝送路最適化の方法
JP2004096247A (ja) * 2002-08-29 2004-03-25 Ntt Docomo Inc データ通信システム、データ通信方法、通信端末及び中継装置
JP2014500662A (ja) * 2010-11-05 2014-01-09 インターデイジタル パテント ホールディングス インコーポレイテッド 中継ノードのインタフェースに関連するレイヤ２測定およびネットワーク負荷平衡時の中継ノードの扱い
JP2015084601A (ja) * 2015-02-04 2015-04-30 京セラ株式会社 無線中継局及び制御方法
JP2018533311A (ja) * 2015-11-05 2018-11-08 ソニー株式会社 無線通信システムにおける電子装置及び無線通信方法
US20190223078A1 (en) * 2018-03-28 2019-07-18 Alexander Sirotkin Next generation node-b (gnb) for integrated access and backhaul (iab) relay in new radio (nr) networks
WO2020064861A1 (en) * 2018-09-27 2020-04-02 Sony Corporation Methods, wireless communications networks and infrastructure equipment

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016155991A1 (en) * 2015-03-31 2016-10-06 Sony Corporation Congestion avoidance in a network with base station and relay nodes
WO2020032127A1 (ja) * 2018-08-08 2020-02-13 京セラ株式会社 中継装置
JP7301059B2 (ja) * 2018-09-14 2023-06-30 株式会社Ｎｔｔドコモ 無線通信装置、無線通信方法及びシステム
CN115190531B (zh) * 2019-04-30 2025-10-03 华为技术有限公司 数据传输的方法和装置
CN114868369A (zh) * 2019-12-31 2022-08-05 联想(北京)有限公司 用于在通信系统中路由数据的方法及设备
US20230139323A1 (en) * 2020-03-11 2023-05-04 Sharp Kabushiki Kaisha Notification message for backhaul radio link failure in wireless relay networks
EP4128990A1 (en) * 2020-04-02 2023-02-08 Telefonaktiebolaget LM Ericsson (publ) Preventing reestablishment at descendant nodes with no alternative paths in integrated access backhaul
EP4233384A1 (en) * 2020-10-22 2023-08-30 Telefonaktiebolaget LM Ericsson (publ) Rerouting of ul/dl traffic in an iab network

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000004469A (ja) * 1998-06-17 2000-01-07 Nec Corp 無線通信システムと基地装置及び無線伝送路最適化の方法
JP2004096247A (ja) * 2002-08-29 2004-03-25 Ntt Docomo Inc データ通信システム、データ通信方法、通信端末及び中継装置
JP2014500662A (ja) * 2010-11-05 2014-01-09 インターデイジタル パテント ホールディングス インコーポレイテッド 中継ノードのインタフェースに関連するレイヤ２測定およびネットワーク負荷平衡時の中継ノードの扱い
JP2015084601A (ja) * 2015-02-04 2015-04-30 京セラ株式会社 無線中継局及び制御方法
JP2018533311A (ja) * 2015-11-05 2018-11-08 ソニー株式会社 無線通信システムにおける電子装置及び無線通信方法
US20190223078A1 (en) * 2018-03-28 2019-07-18 Alexander Sirotkin Next generation node-b (gnb) for integrated access and backhaul (iab) relay in new radio (nr) networks
WO2020064861A1 (en) * 2018-09-27 2020-04-02 Sony Corporation Methods, wireless communications networks and infrastructure equipment

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
See also references of EP4178246A4
SONY: "Routing details in IAB", 3GPP DRAFT; R2-1913295, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Chongqing, China; 20191014 - 20191018, 3 October 2019 (2019-10-03), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051791304 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230413127A1 (en) * 2020-10-21 2023-12-21 Fujitsu Limited Migration method and apparatus for iab-node
WO2023169153A1 (zh) * 2022-03-07 2023-09-14 华为技术有限公司 通信方法和装置
JPWO2024034571A1 (ja) * 2022-08-08 2024-02-15

Also Published As

Publication number Publication date
US20230180327A1 (en) 2023-06-08
US12574986B2 (en) 2026-03-10
EP4178246A1 (en) 2023-05-10
JP2025024206A (ja) 2025-02-19
JP2023145706A (ja) 2023-10-11
JP7814477B2 (ja) 2026-02-16
JP7328458B2 (ja) 2023-08-16
CN120282237A (zh) 2025-07-08
EP4178246B1 (en) 2025-09-24
CN116325849A (zh) 2023-06-23
JP7594637B2 (ja) 2024-12-04
EP4178246A4 (en) 2024-01-03
JPWO2022030578A1 (ja) 2022-02-10

Similar Documents

Publication Publication Date Title
JP7814477B2 (ja) 通信制御方法、第１ドナー基地局、及びシステム
JP7658003B2 (ja) 通信制御方法
WO2015027719A1 (zh) 一种协作多流传输数据的方法及基站
JP7770528B2 (ja) 通信制御方法、第１ドナーネットワークノード及びセルラ通信システム
JP2024156993A (ja) 通信制御方法、中継ノード、プロセッサ、プログラム及びシステム
US20240032129A1 (en) Communication control method
US20240179543A1 (en) Communication control method
US20230354139A1 (en) Communication control method
JP7646678B2 (ja) 通信制御方法
JP2026071305A (ja) Ｉａｂノード、ｉａｂノードのチップセット、通信制御方法、第１ドナー基地局、第２ドナー基地局、通信システム及びプログラム
JP7592143B2 (ja) 通信制御方法、中継ノード及びプロセッサ
US12621745B2 (en) Communication control method
WO2023068254A1 (ja) 通信制御方法及び中継ノード
WO2023132285A1 (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: 21853606

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022541725

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2021853606

Country of ref document: EP

Effective date: 20230206

NENP Non-entry into the national phase

Ref country code: DE

WWG Wipo information: grant in national office

Ref document number: 2021853606

Country of ref document: EP