WO2023068256A1 - 通信制御方法及び中継ノード - Google Patents

通信制御方法及び中継ノード Download PDF

Info

Publication number
WO2023068256A1
WO2023068256A1 PCT/JP2022/038726 JP2022038726W WO2023068256A1 WO 2023068256 A1 WO2023068256 A1 WO 2023068256A1 JP 2022038726 W JP2022038726 W JP 2022038726W WO 2023068256 A1 WO2023068256 A1 WO 2023068256A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
bap
routing
donor
packet
Prior art date
Application number
PCT/JP2022/038726
Other languages
English (en)
French (fr)
Inventor
真人 藤代
ヘンリー チャン
Original Assignee
京セラ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 京セラ株式会社 filed Critical 京セラ株式会社
Priority to JP2023554695A priority Critical patent/JPWO2023068256A1/ja
Publication of WO2023068256A1 publication Critical patent/WO2023068256A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W16/00—Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/24—Cell structures
    • H04W16/26—Cell enhancers or enhancement, e.g. for tunnels, building shadow
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support

Definitions

  • the present disclosure relates to a communication control method and relay node used in a cellular communication system.
  • IAB Integrated Access and Backhaul nodes
  • a relay node is set with a BAP address of the relay node in each topology from a donor node, a BAP layer of the relay node receives a packet, The BAP layer outputs the packet to upper layers if the BAP address of the relay node in the topology associated with the incoming backhaul RLC channel of the packet matches the destination BAP address included in the header of the packet.
  • a relay node includes a processor.
  • the processor executes processing in which the BAP address of the relevant relay node in each topology is set from the donor node.
  • the processor performs processing for the BAP layer of the relay node to receive the packet.
  • the processor causes the BAP layer to transmit the packet if the BAP address of the relay node in the topology associated with the incoming backhaul RLC channel of the packet matches a destination BAP address included in a header of the packet. Execute the process to output to the upper layer.
  • FIG. 1 is a diagram illustrating a configuration example of a cellular communication system according to one embodiment.
  • FIG. 2 is a diagram showing the relationship between IAB nodes, parent nodes, and child nodes.
  • FIG. 3 is a diagram illustrating a configuration example of a gNB (base station) according to one embodiment.
  • FIG. 4 is a diagram illustrating a configuration example of an IAB node (relay node) according to one embodiment.
  • FIG. 5 is a diagram illustrating a configuration example of a UE (user equipment) according to one embodiment.
  • FIG. 6 is a diagram showing an example of protocol stacks for IAB-MT RRC connection and NAS connection.
  • FIG. 7 is a diagram showing an example protocol stack for the F1-U protocol.
  • FIG. 8 is a diagram showing an example protocol stack for the F1-C protocol.
  • FIG. 9(A) shows a topology configuration example in an “intra-CU/intra-donor-DU” scenario
  • FIG. 9(B) in an “intra-CU/between-donor-DU” scenario
  • FIG. 9(C) in an “between-CU” scenario.
  • FIG. 10 is a diagram showing a first operation example according to the first embodiment.
  • FIG. 11 is a diagram summarizing the first operation example according to the first embodiment.
  • FIG. 12 is a diagram illustrating an operation example according to modification 4 of the first embodiment.
  • FIG. 13 is a diagram showing a second operation example according to the first embodiment.
  • FIG. 14 is a diagram showing a configuration example of a BAP Data PDU packet according to the first embodiment.
  • FIG. 15 is a diagram showing a third operation example according to the first embodiment.
  • FIG. 16 is a diagram showing a fourth operation example according to the first embodiment.
  • FIG. 17 is a diagram showing a fifth operation example according to the first embodiment.
  • FIG. 18 is a diagram showing a sixth operation example according to the first embodiment.
  • FIGS. 19A and 19B are diagrams showing configuration examples of topologies according to the second embodiment.
  • FIG. 20 is a diagram showing an operation example according to the second embodiment.
  • FIG. 21 is a diagram showing a modification according to the second embodiment.
  • FIG. 22 is a diagram showing a first operation example according to the third embodiment.
  • FIG. 23 is a diagram summarizing the first operation example according to the third embodiment.
  • FIG. 24 is a diagram showing a second operation example according to the third embodiment.
  • FIG. 25 is a diagram showing a third operation example according to the third embodiment.
  • FIG. 26 summarizes the third operation example according to the third embodiment.
  • FIG. 27 shows a configuration example of an IAB node according to the fourth embodiment.
  • the cellular communication system 1 is a 3GPP 5G system.
  • the radio access scheme in the cellular communication system 1 is NR (New Radio), which is a 5G radio access scheme.
  • NR New Radio
  • LTE Long Term Evolution
  • 6G future cellular communication systems such as 6G may be applied to the cellular communication system 1 .
  • FIG. 1 is a diagram showing a configuration example of a cellular communication system 1 according to one embodiment.
  • a cellular communication system 1 includes a 5G core network (5GC) 10, a user equipment (UE: User Equipment) 100, a base station device (hereinafter sometimes referred to as a "base station") 200. -1, 200-2, and IAB nodes 300-1, 300-2.
  • Base station 200 may be referred to as a gNB.
  • the base station 200 is an NR base station
  • the base station 200 may be an LTE base station (that is, an eNB).
  • base stations 200-1 and 200-2 may be called gNB 200 (or base station 200), and IAB nodes 300-1 and 300-2 may be called IAB node 300, respectively.
  • the 5GC 10 has AMF (Access and Mobility Management Function) 11 and UPF (User Plane Function) 12.
  • the AMF 11 is a device that performs various mobility controls and the like for the UE 100 .
  • the AMF 11 manages information on the area in which the UE 100 resides by communicating with the UE 100 using NAS (Non-Access Stratum) signaling.
  • the UPF 12 is a device that controls transfer of user data.
  • Each gNB 200 is a fixed wireless communication node and manages one or more cells.
  • a cell is used as a term indicating the minimum unit of a wireless communication area.
  • a cell may be used as a term indicating a function or resource for radio communication with the UE 100.
  • One cell belongs to one carrier frequency.
  • the terms cell and base station may be used without distinction.
  • Each gNB 200 is interconnected with the 5GC 10 via an interface called NG interface.
  • NG interface an interface that connects to 5GC 10 to 5GC 10 to 5GC 10 to 5GC 10 to 5GC 10 to 5GC 10.
  • Each gNB 200 may be divided into a central unit (CU: Central Unit) and a distributed unit (DU: Distributed Unit).
  • CU and DU are interconnected through an interface called the F1 interface.
  • the F1 protocol is a communication protocol between the CU and DU, and includes the F1-C protocol, which is a control plane protocol, and the F1-U protocol, which is a user plane protocol.
  • the cellular communication system 1 supports IAB that enables wireless relay of NR access using NR for backhaul.
  • Donor gNB 200-1 (or donor node, hereinafter sometimes referred to as "donor node") is a network-side NR backhaul termination node and a donor base station with additional functionality to support IAB.
  • the backhaul can be multi-hop over multiple hops (ie, multiple IAB nodes 300).
  • IAB node 300-1 wirelessly connects with donor node 200-1
  • IAB node 300-2 wirelessly connects with IAB node 300-1
  • the F1 protocol is carried over two backhaul hops. An example is shown.
  • the UE 100 is a mobile radio communication device that performs radio communication with cells.
  • UE 100 may be any device as long as it performs wireless communication with gNB 200 or IAB node 300 .
  • the UE 100 is a mobile phone terminal, a tablet terminal, a notebook PC, a sensor or a device provided in the sensor, a vehicle or a device provided in the vehicle, an aircraft or a device provided in the aircraft.
  • UE 100 wirelessly connects to IAB node 300 or gNB 200 via an access link.
  • FIG. 1 shows an example in which UE 100 is wirelessly connected to IAB node 300-2.
  • UE 100 indirectly communicates with donor node 200-1 through IAB node 300-2 and IAB node 300-1.
  • FIG. 2 is a diagram showing an example of the relationship between the IAB node 300, parent nodes, and child nodes.
  • each IAB node 300 has an IAB-DU corresponding to a base station function unit and an IAB-MT (Mobile Termination) corresponding to a user equipment function unit.
  • IAB-DU corresponding to a base station function unit
  • IAB-MT Mobile Termination
  • a neighboring node (ie, upper node) on the NR Uu radio interface of an IAB-MT is called a parent node.
  • the parent node is the DU of the parent IAB node or donor node 200 .
  • a radio link between an IAB-MT and a parent node is called a backhaul link (BH link).
  • FIG. 2 shows an example in which the parent nodes of IAB node 300 are IAB nodes 300-P1 and 300-P2. Note that the direction toward the parent node is called upstream.
  • the upper node of the UE 100 can correspond to the parent node.
  • Adjacent nodes (ie, lower nodes) on the NR access interface of the IAB-DU are called child nodes.
  • IAB-DU like gNB200, manages the cell.
  • the IAB-DU terminates the NR Uu radio interface to the UE 100 and subordinate IAB nodes.
  • IAB-DU supports the F1 protocol to the CU of donor node 200-1.
  • FIG. 2 shows an example in which child nodes of IAB node 300 are IAB nodes 300-C1 to 300-C3, but child nodes of IAB node 300 may include UE100. Note that the direction toward a child node is called downstream.
  • all IAB nodes 300 connected to the donor node 200 via one or more hops have a directed acyclic graph (DAG) topology (hereinafter referred to as (sometimes referred to as "topology").
  • DAG directed acyclic graph
  • adjacent nodes on the IAB-DU interface are child nodes
  • adjacent nodes on the IAB-MT interface are parent nodes, as shown in FIG.
  • the donor node 200 centralizes, for example, IAB topology resources, topology, route management, and the like.
  • Donor node 200 is a gNB that provides network access to UE 100 via a network of backhaul links and access links.
  • FIG. 3 is a diagram showing a configuration example of the gNB 200.
  • the gNB 200 has a wireless communication unit 210, a network communication unit 220, and a control unit 230.
  • the wireless communication unit 210 performs wireless communication with the UE 100 and wireless communication with the IAB node 300.
  • the wireless communication section 210 has a receiving section 211 and a transmitting section 212 .
  • the receiver 211 performs various types of reception under the control of the controller 230 .
  • Reception section 211 includes an antenna, converts (down-converts) a radio signal received by the antenna into a baseband signal (reception signal), and outputs the baseband signal (reception signal) to control section 230 .
  • the transmission section 212 performs various transmissions under the control of the control section 230 .
  • the transmitter 212 includes an antenna, converts (up-converts) a baseband signal (transmission signal) output from the controller 230 into a radio signal, and transmits the radio signal from the antenna.
  • the network communication unit 220 performs wired communication (or wireless communication) with the 5GC 10 and wired communication (or wireless communication) with other adjacent gNBs 200.
  • the network communication section 220 has a receiving section 221 and a transmitting section 222 .
  • the receiving section 221 performs various types of reception under the control of the control section 230 .
  • the receiver 221 receives a signal from the outside and outputs the received signal to the controller 230 .
  • the transmission section 222 performs various transmissions under the control of the control section 230 .
  • the transmission unit 222 transmits the transmission signal output by the control unit 230 to the outside.
  • the control unit 230 performs various controls in the gNB200.
  • Control unit 230 includes at least one memory and at least one processor electrically connected to the memory.
  • the memory stores programs executed by the processor and information used for processing by the processor.
  • a processor may include a baseband processor and a CPU.
  • the baseband processor modulates/demodulates and encodes/decodes the baseband signal.
  • the CPU executes programs stored in the memory to perform various processes.
  • the processor processes each layer, which will be described later.
  • the control unit 230 may perform each process or each operation in the gNB 200 in each embodiment described below.
  • FIG. 4 is a diagram showing a configuration example of the IAB node 300.
  • the IAB node 300 has a radio communication section 310 and a control section 320 .
  • the IAB node 300 may have multiple wireless communication units 310 .
  • the wireless communication unit 310 performs wireless communication (BH link) with the gNB 200 and wireless communication (access link) with the UE 100.
  • the wireless communication unit 310 for BH link communication and the wireless communication unit 310 for access link communication may be provided separately.
  • the wireless communication unit 310 has a receiving unit 311 and a transmitting unit 312.
  • the receiver 311 performs various types of reception under the control of the controller 320 .
  • Receiving section 311 includes an antenna, converts (down-converts) a radio signal received by the antenna into a baseband signal (reception signal), and outputs the baseband signal (reception signal) to control section 320 .
  • the transmission section 312 performs various transmissions under the control of the control section 320 .
  • the transmitter 312 includes an antenna, converts (up-converts) a baseband signal (transmission signal) output from the controller 320 into a radio signal, and transmits the radio signal from the antenna.
  • the control unit 320 performs various controls in the IAB node 300.
  • Control unit 320 includes at least one memory and at least one processor electrically connected to the memory.
  • the memory stores programs executed by the processor and information used for processing by the processor.
  • a processor may include a baseband processor and a CPU.
  • the baseband processor modulates/demodulates and encodes/decodes the baseband signal.
  • the CPU executes programs stored in the memory to perform various processes.
  • the processor processes each layer, which will be described later.
  • the control unit 320 may perform each process or each operation in the IAB node 300 in each embodiment described below.
  • FIG. 5 is a diagram showing a configuration example of the UE 100. As shown in FIG. As shown in FIG. 5 , UE 100 has radio communication section 110 and control section 120 .
  • the wireless communication unit 110 performs wireless communication on the access link, that is, wireless communication with the gNB 200 and wireless communication with the IAB node 300. Also, the radio communication unit 110 may perform radio communication on the sidelink, that is, radio communication with another UE 100 .
  • the radio communication unit 110 has a receiving unit 111 and a transmitting unit 112 .
  • the receiver 111 performs various types of reception under the control of the controller 120 .
  • Reception section 111 includes an antenna, converts (down-converts) a radio signal received by the antenna into a baseband signal (reception signal), and outputs the baseband signal (reception signal) to control section 120 .
  • the transmitter 112 performs various transmissions under the control of the controller 120 .
  • the transmitter 112 includes an antenna, converts (up-converts) a baseband signal (transmission signal) output from the controller 120 into a radio signal, and transmits the radio signal from the antenna.
  • the control unit 120 performs various controls in the UE 100.
  • Control unit 120 includes at least one memory and at least one processor electrically connected to the memory.
  • the memory stores programs executed by the processor and information used for processing by the processor.
  • a processor may include a baseband processor and a CPU.
  • the baseband processor modulates/demodulates and encodes/decodes the baseband signal.
  • the CPU executes programs stored in the memory to perform various processes.
  • the processor processes each layer, which will be described later.
  • the control unit 130 may perform each process in the UE 100 in each embodiment described below.
  • FIG. 6 is a diagram showing an example of protocol stacks for IAB-MT RRC connection and NAS connection.
  • the IAB-MT of the IAB node 300-2 includes a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, and a PDCP (Packet Data Convergence Protocol) layer, an RRC (Radio Resource Control) layer, and a NAS (Non-Access Stratum) layer.
  • PHY physical
  • MAC Medium Access Control
  • RLC Radio Link Control
  • PDCP Packet Data Convergence Protocol
  • RRC Radio Resource Control
  • NAS Non-Access Stratum
  • the PHY layer performs encoding/decoding, modulation/demodulation, antenna mapping/demapping, and resource mapping/demapping. Data and control information are transmitted via physical channels between the IAB-MT PHY layer of the IAB node 300-2 and the IAB-DU PHY layer of the IAB node 300-1.
  • the MAC layer performs data priority control, retransmission processing by hybrid ARQ (HARQ: Hybrid Automatic Repeat reQuest), random access procedures, and the like. Data and control information are transmitted via transport channels between the MAC layer of the IAB-MT of the IAB node 300-2 and the MAC layer of the IAB-DU of the IAB node 300-1.
  • the MAC layer of IAB-DU contains the scheduler. The scheduler determines uplink and downlink transport formats (transport block size, modulation and coding scheme (MCS: Modulation and Coding Scheme)) and allocation resource blocks.
  • MCS Modulation and Coding Scheme
  • the RLC layer uses the functions of the MAC layer and PHY layer to transmit data to the RLC layer on the receiving side. Data and control information are transmitted over logical channels between the IAB-MT RLC layer of IAB node 300-2 and the IAB-DU RLC layer of IAB node 300-1.
  • the PDCP layer performs header compression/decompression and encryption/decryption. Data and control information are transmitted between the IAB-MT PDCP layer of IAB node 300-2 and the PDCP layer of donor node 200 via radio bearers.
  • the RRC layer controls logical channels, transport channels and physical channels according to radio bearer establishment, re-establishment and release. Between the IAB-MT RRC layer of the IAB node 300-2 and the RRC layer of the donor node 200, RRC signaling for various settings is transmitted. If there is an RRC connection with the donor node 200, the IAB-MT is in RRC connected state. When there is no RRC connection with the donor node 200, the IAB-MT is in RRC idle state.
  • the NAS layer located above the RRC layer performs session management and mobility management.
  • NAS signaling is transmitted between the NAS layer of the IAB-MT of the IAB node 300-2 and the AMF 11.
  • FIG. 7 is a diagram showing a protocol stack for the F1-U protocol.
  • FIG. 8 is a diagram showing a protocol stack for the F1-C protocol.
  • the donor node 200 is split into CUs and DUs.
  • each of the IAB-MT of the IAB node 300-2, the IAB-DU of the IAB node 300-1, the IAB-MT of the IAB node 300-1, and the DU of the donor node 200 is It has a BAP (Backhaul Adaptation Protocol) layer as an upper layer.
  • the BAP layer is a layer that performs routing processing and bearer mapping/demapping processing.
  • the IP layer is transported over the BAP layer to allow routing over multiple hops.
  • BAP layer PDUs Protocol Data Units
  • backhaul RLC channels BH NR RLC channels
  • QoS Quality of Service
  • the association between BAP PDUs and backhaul RLC channels is performed by the BAP layer of each IAB node 300 and the BAP layer of the donor node 200 .
  • the F1-C protocol stack has an F1AP layer and an SCTP layer instead of the GTP-U layer and UDP layer shown in FIG.
  • the processing or operations performed by the IAB's IAB-DU and IAB-MT may be simply described as "IAB" processing or operations.
  • the IAB-DU of the IAB node 300-1 sends a BAP layer message to the IAB-MT of the IAB node 300-2, and the IAB node 300-1 sends the message to the IAB node 300-2.
  • DU or CU processing or operations of donor node 200 may also be described simply as "donor node” processing or operations.
  • upstream direction and the uplink (UL) direction may be used without distinction.
  • downstream direction and the downlink (DL) direction may be used interchangeably.
  • Routing is, for example, controlling to which IAB node 300 a received packet is transferred. Also, rerouting is, for example, controlling the transfer of a received packet to a destination node (access IAB node or donor node) via an alternative path.
  • 3GPP is studying how to perform routing or rerouting in a network (or topology) formed by multiple IAB nodes 300.
  • FIG. 9A shows a configuration example of the topology in the “Inside CU/Inside Donor DU” scenario.
  • routing and rerouting are performed in the same donor DU (200D) and the same donor CU (200C).
  • the route via the IAB node 300-2 and the route via the IAB node 300-3 there are two routes between the IAB node 300-1 and the donor DU (200D): the route via the IAB node 300-2 and the route via the IAB node 300-3.
  • the IAB node 300-1 can transfer packets in the uplink direction to either route.
  • the IAB node 300-1 is also capable of forwarding packets forwarded through any of the routes described above to the IAB node 300-4 or the IAB node 300-5, even for packets in the downlink direction.
  • S1-1 the presence of such two routes makes it possible to ensure redundancy for the routes.
  • rerouting is so-called local rerouting.
  • BH RLF Radio Link Failure
  • IAB node 300-1 detects a radio link failure (BH RLF (Radio Link Failure)) (hereinafter sometimes referred to as "BH RLF") in the backhaul link to the IAB node 300-2
  • BH RLF Radio Link Failure
  • FIG. 9B is a diagram showing a configuration example of the topology in the “Intra-CU/Between Donor-DU” scenario.
  • donor DU#1 200D1
  • donor DU#2 200D2
  • CU (200C) of one donor node the same, but routing and rerouting are performed via different donor DUs.
  • IAB node 300-1 For routing in the uplink direction in IAB node 300-1, IAB node 300-1 can forward packets to IAB node 300-2 or IAB node 300-3. Also in the downlink direction, the IAB node 300-1 can transfer packets forwarded through any of the routes to the IAB node 300-4 or the IAB node 300-5.
  • the DUs of the donor nodes are different, but the CUs of the donor nodes are the same, so the routing is within the same topology.
  • Such routing is sometimes referred to as intra-topological routing.
  • the donor DU that is the destination of the packet is changed from donor DU#1 (200D1) to donor DU#2 (200D2). That is, the destination BAP address of the packet is changed. Therefore, 3GPP has agreed to rewrite the BAP header in this scenario. Rewriting the BAP header is to rewrite the BAP header from the previous routing ID to the new routing ID.
  • a routing ID is composed of a destination BAP address (Destination) and a path identifier (Path ID).
  • FIG. 9C is a diagram showing a configuration example of the topology in the “Between CUs” scenario.
  • donor CU#1 200C1
  • donor CU#2 200C2
  • a donor DU#1 200D1
  • a donor DU#2 200D2
  • a donor CU#2 200C2
  • a topology formed by a route from donor CU#1 (200C1) to IAB node 300-1 and a topology formed by a route from donor CU#2 (200C2) to IAB node 300-1 It can be a topology different from the topology (second topology).
  • IAB node 300-1 is located at the boundary of two different topologies. Such an IAB node 300-1 may be called a boundary IAB node.
  • the boundary IAB node 300-1 can forward packets addressed to donor DU#1 (200D1) to donor DU#2 (200D1) of a different topology.
  • packets destined for IAB node 300-4 can be forwarded via a different topology.
  • a packet sent from donor CU#1 (200C1) is sent to IAB node 300-4 via donor CU#2 (200C2), donor DU#2 (200D2), and IAB nodes 300-3 and 300-1. can be transferred. Since the DU of the donor node that is the destination is also changed in these cases, 3GPP has agreed to rewrite the BAP header.
  • inter-topology routing Such routing between different topologies is sometimes referred to as inter-topology routing.
  • the border IAB node 300-1 can forward packets destined for donor DU#1 (200D1) via the topological alternative path in donor CU#2 (200C2). .
  • the border IAB node 300-1 maintains the F1 connection with donor CU#1 (200C1), which is the source donor node, while maintaining donor CU#2, which is the target donor node. It was agreed that it may be applied in the RRC Re-establishment state for (200C2).
  • inter-CU routing may be referred to as “inter-topology routing”
  • inter-CU rerouting may be referred to as “inter-topology rerouting”.
  • intra-CU/inter-donor DU rerouting may be referred to as “inter-donor DU rerouting”.
  • the first embodiment is an embodiment for inter-topology routing.
  • 3GPP is discussing the following four open issues.
  • Process 1 is, for example, what kind of BAP address should be set in the header of the BAP packet (BAP PDU) targeted for inter-topology routing by the DU of the access IAB node or donor node. For example, if the boundary IAB node 300-1 can distinguish between BAP packets to be routed between topologies and packets not to be routed between topologies based on the set BAP address, the boundary IAB node 300-1 performs routing between topologies, normal routing processing, can be properly treated.
  • Process 2 is, for example, how the border IAB node 300-1 distinguishes between inter-topology routing (non-cocatenated traffic) and intra-topology routing (concatenated traffic). If the boundary IAB node can appropriately perform such determination, it will be possible to appropriately perform inter-topology routing and intra-topology routing.
  • Process 3 is, for example, how the boundary IAB node determines packets to be passed to its own upper layer.
  • a border IAB node can receive two packets, one from the upstream direction and the other from the downstream direction. If the packet is addressed to itself in the downstream direction, the boundary IAB node can determine that it is the access IAB node and pass the packet to the upper layer.
  • (Problem 4) is, for example, how to rewrite the BAP header.
  • the destination donor DU is changed to a donor DU with a different topology. Therefore, if the BAP header can be rewritten appropriately, it becomes possible to transfer to a donor DU with a different topology, and it becomes possible to perform inter-topology routing appropriately.
  • 3GPP has proposed the following two examples (drafts).
  • Plant 1 is a proposal to include the BAP address of the border IAB node 300-1 in the BAP packet header. Packets containing the BAP address of the boundary IAB node 300-1 are proposed to be inter-topology routing target packets. If the BAP address of the boundary IAB node included in the header of the received packet matches the BAP address of the IAB node itself, the IAB node determines that the packet is an inter-topology routing target packet as the boundary IAB node 300-1. It is also possible to
  • Plant 2 is a proposal to include a proxy or fake BAP address in the BAP packet header. Also in this case, if the header of the received BAP packet contains a fake BAP address, the IAB node can determine that the packet is the packet to be inter-topologically routed.
  • a first operation example is a communication control method used in a cellular communication system.
  • the transmitter of the BAP layer of the relay node receives the packet from the receiver of the BAP layer of the relay node.
  • the transmitter determines whether inter-topology routing or intra-topology routing is to be performed for the packet based on the header information of the packet.
  • the relay node is a boundary relay node located at the boundary between topologies.
  • the first operation example it is determined whether inter-topology routing or intra-topology routing is to be performed based on the header information of the received packet. Therefore, in the first operation example, it is possible to appropriately determine whether inter-topology routing or intra-topology routing is to be performed.
  • the transmission unit selects the first routing table for intra-topology routing and the first mapping table for intra-topology routing.
  • the transmitting unit selects the second routing table for inter-topology routing and the second mapping table for inter-topology routing.
  • the routing table and mapping table for inter-topology routing can be appropriately selected.
  • the transmission unit can appropriately perform inter-topology routing, and can provide solutions to, for example, (problem 1) and (problem 2). can.
  • the transmitting unit selects the second routing table and the second mapping table
  • the header of the BAP packet is changed from the previous routing ID to the new routing according to the BAP header rewriting table.
  • Header rewrite processing for rewriting to ID is performed.
  • the destination BAP address can be appropriately rewritten, inter-topology routing can be performed appropriately, and, for example, a solution to (Problem 4) can be provided.
  • the first operation example will be specifically described below.
  • FIG. 10 is a diagram showing a first operation example according to the first embodiment.
  • the IAB node 300 starts processing in step S10.
  • the IAB node 300 (here, the border IAB node 300-1) is set by the donor node 200 in a predetermined manner.
  • the predetermined setting is to receive the table shown below. That is, a first routing table for intra-topology routing, a second mapping table for intra-topology routing, a second routing table for inter-topology routing, a second mapping table for inter-topology routing, and a BAP header rewriting table. .
  • the IAB node 300 receives the packet (BAP PDU packet).
  • step S13 the BAP layer receiving unit of the IAB node 300 identifies packets addressed to itself in the downstream direction or the upstream direction among the received packets. Then, the receiving unit outputs packets addressed to itself to the upper layer, and outputs other packets to the transmitting unit of the BAP layer of the IAB node 300 .
  • the receiving unit identifies packets addressed to itself as follows.
  • the receiving unit determines that the packet is a candidate packet.
  • the receiving unit uses the path ID included in the header of the candidate packet to identify that the packet is addressed to itself. Specifically, when the path ID included in the header of the packet is different from a predetermined path ID (path ID for inter-topology routing packet), the receiver identifies the packet as being addressed to itself. do. Note that the predetermined path ID is set by the donor node 200, for example. If the candidate packet is of (plan 1), it may be identified that it is a packet addressed to itself using an identifier indicating that the packet is an inter-topology routing target packet. Specifically, when the identifier included in the BAP header of the packet is "0" (the packet is not an inter-topology routing target packet), the receiving unit identifies the candidate packet as being addressed to itself.
  • the receiving unit identifies the candidate packet as a packet addressed to itself. That is, since it can be confirmed that the destination of the candidate packet matches its own BAP address and is not a fake BAP address, the candidate packet whose header destination matches the BAP address of its own IAB node 300 is ), it can be a packet addressed to itself.
  • a self-addressed packet is a packet for self IAB node 300-1 to transmit to UE 100 as an access IAB node. Therefore, in the upper layer, processing is performed so that the packet is transmitted to the UE 100 .
  • the receiving unit outputs the packets identified as not addressed to itself among the received packets to the transmitting unit of the BAP layer.
  • step S14 the transmitter selects the routing mode of the packet received from the receiver. Routing modes include intra-topology routing and inter-topology routing.
  • the determination method is, for example, as follows. That is, the transmitting unit determines that the packet is an inter-topology routing target packet (inter-topology routing mode) if at least one of the following conditions applies to the header information of the packet. Intra-routing mode (in-topology routing mode) is determined.
  • M1 Matching with a specific routing ID indicating inter-topology routing
  • M2 Matching with a specific path ID indicating inter-topology routing
  • M3 Inter-topology routing If it matches a specific BAP address (e.g., proposal (2))
  • M4 If the identifier indicating whether inter-topology transfer indicates inter-topology transfer (e.g., "1")
  • M5 BAP packet If the destination BAP address matches a BAP address linked to a different topology than the specified BAP address, or M6:
  • the receiving unit provides routing mode information for each packet, and the information is routing).
  • the receiving unit may determine the routing mode using M1 to M5.
  • the transmission unit may store the packet in a different buffer depending on the determination result. For example, when the transmission unit determines that the packet is a packet for inter-topology routing, the transmission unit stores the packet in the buffer for inter-topology routing. Further, for example, when the transmitting unit determines that the packet is a packet for intra-topology routing, the transmitting unit stores the packet in the intra-topology routing buffer.
  • step S15 the transmission unit selects a routing table and a mapping table.
  • the sender may, by default, select the first routing table for intra-topology routing.
  • step S14 when the transmission unit determines that the packet is to be inter-topology routing, if the second routing table for inter-topology routing is set, it selects the second routing table. Furthermore, if the second mapping table is set, the transmitting unit selects the second mapping table.
  • the transmission unit determines that the packet is for inter-topology routing
  • the transmission unit determines that the packet is for inter-topology routing because the packet matches a specific routing ID, but the IAB node 300 does not set the second routing table.
  • the IAB node 300 does not set the second routing table.
  • the IAB nodes IAB node 300-2 and IAB node 300-3 located halfway between the donor DU and border IAB node 300-1.
  • Such an IAB node recognizes the packet as a packet for inter-topology routing, but does not execute inter-topology routing for the packet because the second routing table has not been set. In this case, the transmitter selects the first routing table.
  • the transmitting unit selects the first mapping table when the second mapping table is not set.
  • the transmission unit determines in step S15 that the packet is a packet to be routed within the topology, it selects the first routing table. Further, the transmitter selects a second mapping table.
  • the transmission unit may store the packet in a different buffer for each routing table.
  • the transmission unit stores the packet in the first routing table buffer.
  • the transmission unit stores the packet in the second routing table buffer.
  • step S16 the transmission unit performs BAP header rewriting processing on the packet. That is, when inter-topology routing is performed for the packet (or when the second routing table and the second mapping table are selected in step S15), the transmission unit performs BAP header rewriting processing.
  • the transmission unit uses the header rewrite table to perform BAP header rewrite processing.
  • the BAP header rewrite table contains entries containing an old routing ID (previous routing ID) and a new routing ID (new routing ID). Specifically, if there is an entry in the header rewrite table that includes the old routing ID that matches the routing ID included in the header of the packet, the sending unit replaces the routing ID included in the header of the packet with the routing ID included in the header of the packet. Rewrite to the new routing ID of the entry.
  • the transmission unit determines that the packet is not a packet for inter-topology routing. You can judge. In this case, the transmission unit does not perform the BAP header rewriting process. Alternatively, in this case, the transmission unit may perform processing such as rerouting processing. That is, if an entry containing the BAP address part of the old routing ID that matches the destination of the packet exists in the header rewriting table, the transmission unit replaces the routing ID of the BAP header of the packet with the entry of the entry. It may be rewritten to a new routing ID.
  • step S17 the transmission unit performs routing processing and mapping processing on the packet.
  • the transmission unit performs routing processing using the routing table (first routing table or second routing table) selected in step S15. Specifically, the transmission unit determines that an entry matching the destination (Destination) and path ID (Path ID) contained in the header of the packet exists in the selected routing table, and the next hop BAP of the entry (Next Hop If the egress backhaul link (BH link) corresponding to the BAP) address is available, select the egress backhaul link.
  • the routing table first routing table or second routing table
  • the case of using the first routing table is the case of intra-topology routing. That is, in the case of intra-topology routing, routing processing is performed using the first routing table for both packets in the downlink direction and packets in the uplink direction.
  • the case of using the second routing table is the case of inter-topology routing.
  • the IAB node 300-1 performs inter-topology routing processing on the received packet. For example, the IAB node 300-1 performs routing processing so that a packet addressed to the donor DU#1 (200D1) becomes a packet directed to the donor DU#1 (200D2).
  • the transmission unit performs mapping processing using the mapping table (first mapping table or second mapping table) selected in step S15. Specifically, the transmission unit matches the ingress backhaul RLC channel (ingress BH RLC channel) of the packet, the ingress backhaul link (ingress BH link) of the packet, and the outflow backhaul link selected in the mapping process. If an entry exists in the selected mapping table, select the egress backhaul RLC channel (egress BH RLC channel) for that entry.
  • the mapping table first mapping table or second mapping table
  • the transmitting unit outputs the packet to the selected outflow backhaul RLC channel of the selected outflow backhaul link.
  • the IAB node 300 transmits the packet to the next hop node.
  • the IAB node 300 (boundary IAB node 300-1) transmits the packet to, for example, the donor DU #2 (200D2) by inter-topology routing.
  • the IAB node 300 transmits the packet to, for example, the donor DU#1 (200D1) by intra-topology routing.
  • the IAB node 300 ends a series of processes.
  • FIG. 11 is a diagram summarizing the first operation example according to the first embodiment.
  • the BAP reception process corresponds to steps S11 to S13 in FIG. 11
  • routing mode selection corresponds to step S14 in FIG.
  • routing table/mapping table selection corresponds to step S15 in FIG.
  • the BAP header rewriting process corresponds to step S16 in FIG.
  • the routing process/mapping process corresponds to step S17 in FIG.
  • the first operation example may be performed when the second routing table, the second mapping table, and the header rewriting table are set. That is, if the second routing table, the second mapping table, or the header rewrite table are not set, the first operation example may not be performed.
  • Modification 2 In the first operation example, the scenario (S3-1) of "inter-topology routing" has been described. It is agreed in 3GPP that BAP header rewriting is also performed in the “intra-CU/inter-donor-CU rerouting” scenario (S2-2).
  • the first operation example may be applied to scenarios other than the "inter-topology routing" scenario.
  • the “intra-CU/inter-donor-DU rerouting” scenario (S2-2) or the “intra-CU/intra-donor-DU rerouting” scenario (S1-2) may be read as "normal routing or inter-donor DU rerouting", respectively, and operations may be performed.
  • Modification 3 In the first operation example, an example using two routing tables, the first routing table for intra-topology routing and the second routing table for inter-topology routing, has been described. For example, for routing tables, three or more routing tables may be set.
  • the IAB node 300-1 under the donor CU#1 (200C1) (hereinafter sometimes referred to as the "first donor")
  • the donor CU#1 (200C2) (hereinafter (which may be referred to as “second donor”).
  • the routing ID is managed by the first donor in the downstream direction
  • the routing ID is managed by the second donor in the upstream direction.
  • the same routing ID may be used if there is no negotiation between the first donor and the second donor.
  • the IAB node 300-1 receives a packet from a lower node after inter-topology routing and performs routing processing. In this case, the IAB node 300-1 selects an entry matching the routing ID of the packet from the routing table. However, if the same routing ID exists in the downstream routing table managed by the first donor and the upstream routing table managed by the second donor, the IAB node 300-1 uses the same routing ID. entry from the routing table in the downstream direction. In this case, the IAB node 300-1 may transfer the packet received from the lower node to the lower node again.
  • two routing tables an upstream inter-topology routing table and a downstream inter-topology routing table, are set in the IAB node 300-1.
  • the intra-topology routing table an upstream intra-topology routing table and a downstream intra-topology routing table are set in the IAB node 300-1.
  • the IAB node 300-1 determines that a packet received from a lower node is in the upstream direction, and performs routing processing using the inter-topology table or intra-topology table associated with the upstream direction.
  • the IAB node 300-1 can appropriately transfer packets.
  • Modification 4 In the first operation example, the BAP header rewriting process was performed after the routing table/mapping table selection (step S32) and before the routing process/mapping process (step S34).
  • Modification 4 is an example in which the BAP header rewriting process is performed first in the BAP transmission process.
  • FIG. 12 is a diagram showing an operation example according to modification 4 of the first embodiment.
  • BAP transmission processing is performed in the following order. That is, BAP header rewriting processing (step S33), routing mode selection (step S31), routing table/mapping table selection (step S32), and routing processing/mapping processing (step S34).
  • step S33 the transmitting unit performs BAP header rewriting processing.
  • the transmitter performs, for example, the following processes.
  • the BAP header rewriting process is performed in step S33. Specifically, the transmission unit performs the following processing. First, the transmitter determines whether an entry containing the old routing ID that matches the routing ID contained in the header of the packet exists in the header rewriting table.
  • the transmission unit rewrites the routing ID included in the BAP header of the packet to the new routing ID in the entry.
  • the transmitter does not rewrite the BAP header.
  • the transmitter may determine that the packet was not subject to inter-topology routing.
  • the transmission unit may perform rerouting processing. That is, if an entry containing the BAP address of the old routing ID that matches the destination (Destination) in the header of the packet exists in the header rewriting table, the routing ID of the BAP header is replaced with the new rewrite to a valid routing ID.
  • the transmission unit may store the packet in the buffer for BAP header-rewritten packets.
  • the transmission unit may store the packet in a buffer for BAP header unrewritten packets.
  • step S31 the transmission unit selects a routing mode (step S31).
  • the transmitter performs, for example, the following processes. That is, when the BAP header is rewritten, the transmission unit may determine that the packet is a packet to be inter-topology routing. Further, when the BAP header is not rewritten, the transmission unit may determine that the packet is a packet to be subjected to intra-topology routing. Step S31 may be omitted.
  • the transmission unit selects a routing table/mapping table. For example, the transmission unit performs the following processing. That is, the transmitting unit may select the second routing table and the second mapping table associated with the new routing ID selected when rewriting the BAP header. In this case, the new routing ID and the linking information with each table are set from the donor node 200 to the IAB node 300-1.
  • step S34 the transmission unit performs routing processing and mapping processing.
  • the two processes are the same as in the first operation example.
  • each entry in the table may include information indicating whether the entry is applied to the intra-topology scenario or the inter-topology scenario.
  • the information may be information indicating whether to apply to a packet whose BAP header has been rewritten or to a packet whose BAP header has not been rewritten.
  • the information may be an identifier indicating the topology of the destination of the packet (or the donor managing the topology).
  • the information may be information indicating whether to apply to upstream packets or to downstream packets.
  • the IAB node 300-1 targets (candidates) for routing processing (and mapping processing) only entries that match the specified routing mode (or scenario).
  • the second operation example is also an operation example of identifying whether or not a packet received by the IAB node 300-1 is an inter-topology routing target packet.
  • the border IAB node 300-1 is connected with two topologies. Each topology is assumed to be managed by each donor node (donor CU#1 (200C1) and donor CU#2 (200C2)). Therefore, the BAP address of the boundary IAB node 300-1 has two BAP addresses, the BAP address managed by the donor CU# (200C1) and the BAP address managed by the donor CU#2 (200C). In principle, the BAP address should be unique within the topology.
  • border IAB node 300-1 is assigned two pseudo BAP addresses, one assigned by donor CU#1 (200C1) and one assigned by donor CU#2 (200C2). There is Further, as described above, border IAB node 300-1 is assigned two self-BAP addresses by these two donors as self-BAP addresses.
  • the border IAB node 300-1 may be assigned four BAP addresses. Using these four BAP addresses to identify packets to be inter-topologically routed may involve complicated processing.
  • the BAP layer may determine from which topology the packet has flowed in order to select the BAP address.
  • the IAB node 300-1 identifies the topology of the incoming packet, identifies the BAP address associated with the topology as its own BAP address, and uses the identified BAP address to As in the first operation example, BAP reception processing and BAP transmission processing are performed.
  • the relay node (eg, IAB node 300-1) is set with the BAP address of the relay node in each topology from the donor node (eg, donor node 200).
  • the relay node is configured with binding information linking the topology and the ingress backhaul link and/or linking information linking the topology and the ingress backhaul RLC channel from the donor node.
  • the BAP layer of the relay node receives the packet.
  • the BAP layer identifies the topology to which the packet belongs based on the inflow backhaul link and/or the inflow backhaul RLC channel of the packet, and uses the BAP address associated with the identified topology as the BAP address of the relay node. Identify.
  • the relay node is a boundary relay node (for example, boundary IAB node 300-1) located at the boundary between topologies.
  • FIG. 13 is a diagram showing a second operation example according to the first embodiment.
  • border IAB node 300-1 has connections with two topologies.
  • border IAB node 300-1 has a connection between donor CU #1 (200C1) and donor CU #2 (200C2).
  • the relationship between border IAB node 300-1 and the two donor nodes is as follows: border IAB node 300-1 and the donor node with F1AP connection, and border IAB node 300-1 with the donor node without F1AP connection. It can be a relationship.
  • the relationship is also between border IAB node 300-1 and a donor node having a first (main or master) F1AP connection and border IAB node 300-1 and a donor node having a second (secondary) F1AP connection. good. Further, the relationship may be a relationship between the border IAB node 300-1 and a donor node that has an RRC connection and a donor node that does not have an RRC connection with the border IAB node 300-1. Furthermore, the relationship is a relationship between a donor node having an MCG (Master Cell Group) connection with the boundary IAB node 300-1 and a donor node having an SCG (Secondary Cell Group) connection with the boundary IAB node 300-1. good too.
  • MCG Master Cell Group
  • step S40 the IAB node 300-1 starts processing.
  • step S41 the IAB node 300-1 is set with the BAP address of each topology from the donor node.
  • the BAP address is set using F1AP or RRC.
  • the BAP address in donor CU#2 (200C2) is the donor CU# 2 (200C2) to the donor CU#1 (200C1). Then, the BAP address is set from the donor CU#1 (200C1) to the IAB node 300-1.
  • Such a route may set the BAP address in the topology on the donor CU#2 (200C2) side.
  • the donor CU#1 (200C1) sends the BAP address in the topology managed by itself to the IAB node 300-1 using the F1AP message or the RRC message. set.
  • Donor CU#2 (200C2) also sets the BAP address in the topology it manages to IAB node 300-1 using the F1AP message or the RRC message.
  • the BAP address may be set in association with the topology (or donor node).
  • the first BAP address is set in association with the first topology (eg, the topology managed by donor CU #1 (200C1))
  • the second BAP address is set in association with the second topology (eg, donor CU #2 (200C2) managed topology).
  • the IAB node 300-1 associates the BAP address with each topology (or donor node) and stores it in a buffer.
  • step S42 the IAB node 300-1 is set with the linking information between the topology and the ingress backhaul link (ingress BH link) (and/or the ingress backhaul RLC channel (ingress BH RLC channel)) from the donor node. be.
  • a first topology is associated with a first ingress backhaul link (and/or a first ingress backhaul RLC channel) and a second topology is associated with a second ingress backhaul (and/or a second ingress backhaul RLC channel).
  • the tying information may be set only for the second inflow backhaul link (and/or the second inflow backhaul RLC channel) that is tied to the second topology.
  • the IAB node 300-1 determines the first topology if there is no binding information, If there is linking information, it can be determined as the second topology.
  • the linking information obtained in step S42 enables the IAB node 300-1 to identify the topology to which the packet belongs from the source of the packet.
  • the BAP layer of the IAB node 300-1 receives the packet.
  • the BAP layer identifies the incoming backhaul link (and/or incoming backhaul RLC channel) for the packet. That is, the BAP layer confirms the topology associated with the ingress backhaul link (and/or ingress backhaul RLC channel) based on the ingress backhaul link (and/or ingress backhaul RLC channel) of the packet. do.
  • the BAP layer replaces the BAP address associated with the first topology with its own BAP address. (eg, first BAP address).
  • a BAP address associated with each topology is set in step S41.
  • the BAP layer replaces the BAP address associated with the second topology with its own BAP address. (for example, second BAP address).
  • the BAP layer identifies the topology to which the packet belongs from the inflow source of the received packet, and identifies the BAP address associated with (or corresponding to) the identified topology.
  • step S44 the BAP layer confirms the destination (Destination) included in the header of the packet.
  • the BAP layer determines that the packet is addressed to itself and outputs the packet to the upper layer. That is, if the destination matches the own BAP address (for example, the first BAP address) specified in step S43, the packet is a packet in the downstream direction in the first topology, as in the first operation example, This is the case where self IAB node 300-1 is the access IAB node. In such a case, since the IAB node 300-1 transmits the packet to the UE 100 under its control, the BAP layer outputs the packet to the upper layer.
  • the own BAP address for example, the first BAP address
  • the BAP layer determines that the destination is to be routed.
  • the BAP layer receiver outputs the packet determined to be routed to the BAP layer transmitter.
  • the BAP layer performs the following processing on packets to be routed.
  • the BAP layer transfers the packet to the inter-topology routing target. packet. That is, in the BAP layer, the destination BAP address of the packet matches the BAP address (e.g., second BAP address) associated with a different topology (e.g., second topology) from the identified BAP address (e.g., first BAP address) If so, the packet is determined as an inter-topology routing target packet. After the determination, the BAP layer may perform BAP header rewriting processing on the packet in the same manner as in the first operation example. Alternatively, when step S44 is performed by the BAP layer receiving unit, the receiving unit outputs the packet to the BAP layer transmitting unit as an inter-topology routing target (or by adding information that is the target). good too.
  • the BAP layer may perform BAP header rewriting processing on the packet in the same manner as in the first operation example.
  • the BAP layer regards the packet as an intra-topology routing target. You can judge. The BAP layer does not perform BAP header rewrite processing on the packet.
  • the receiving unit outputs the packet to the BAP layer transmitting unit as an intra-topology routing target (or by adding information that is the target). good too.
  • the BAP layer performs routing processing and mapping processing as in the first operation example.
  • the BAP layer may use the second routing table and the second mapping table to perform routing processing and mapping processing on packets determined to be inter-topology routing targets. Also, the BAP layer may perform routing processing and mapping processing using the first routing table and the first mapping table for packets determined to be inter-topology routing targets.
  • the IAB node 300-1 ends a series of processes.
  • 3GPP it is proposed to include an identifier in the header of a BAP packet that indicates whether or not the packet is a BAP packet for inter-topology routing.
  • the packet when the boundary IAB node 300-1 receives the packet from a lower node, the packet is an inter-topology routing target packet based on the identifier included in the header of the packet. can identify something.
  • the IAB node 300-3 that has received the packet can also determine that the packet is an inter-topology routing target packet based on the identifier. Therefore, IAB node 300-3 may perform an erroneous operation.
  • the IAB node (boundary IAB node) 300-1 sets the identifier to a value (for example, "0") indicating that the packet is not an inter-topology routing target packet. rewrite to
  • the identifier indicating inter-topology routing included in the header information of the BAP packet is rewritten from "1" to "0".
  • the IAB node 300-3 that has received the packet that has undergone inter-topology routing will no longer perform inter-topology routing for the packet, thereby suppressing erroneous operations.
  • FIG. 14 is a diagram showing a configuration example of a BAP Data PDU packet according to the first embodiment.
  • An identifier indicating that the packet is an object of inter-topology routing may be included in at least one of the three reserved areas (“R”).
  • FIG. 15 is a diagram showing a third operation example according to the first embodiment.
  • step S50 the border IAB node 300-1 starts processing.
  • step S51 the border IAB node 300-1 receives the BAP packet.
  • step S52 the BAP layer of the border IAB node 300-1 confirms the identifier contained in the header of the packet.
  • the BAP layer determines that the received packet is the inter-topology routing target packet.
  • the identifier is "0"
  • the BAP layer determines that the packet is not an inter-topology routing target packet. In the following description, the packet is assumed to be an inter-topology routing target packet.
  • step S53 the BAP layer performs BAP header rewriting processing on the packet.
  • the BAP layer performs the routing contained in the header of the packet. Rewrite the ID to the new routing ID contained in the entry. Then, the BAP layer rewrites the identifier from the value "1" indicating that inter-topology routing is performed to the value "0" indicating that inter-topology routing is not performed. Alternatively, the BAP layer writes "0" to the area of the BAP header containing the identifier.
  • step S54 the BAP layer performs routing processing and mapping processing in the same manner as in the first operation example, and outputs the packet to the lower layer.
  • step S55 the border IAB node 300-1 transmits the packet to the next hop node.
  • step S56 the border IAB node 300-1 ends the series of processes.
  • the BAP layer selects the first routing table or the second routing table when selecting the routing table.
  • the BAP layer may not be able to identify which routing table is the first routing table or which is the second routing table.
  • each mapping table includes an identifier for identifying the first mapping table and the second mapping table.
  • the first routing table and the second routing table include first identification information that identifies the first routing table and the second routing table
  • the first mapping table and the second mapping table include: A second identification is included that identifies the first mapping table and the second mapping table.
  • M1 to M6 have been described as identification methods for identifying that the packet is a packet for inter-topology routing.
  • the packet is a packet for inter-topology routing by the direction of the packet.
  • the downstream routing ID used in the topology of donor CU #1 (200C1) and the topology of donor CU #2 (200C2) The routing ID used in the upstream direction may be the same. Therefore, an identifier indicating the direction is included in each table. Then, if the IAB node 300-2 can confirm that the direction of the received packet is the upstream direction, it recognizes that the packet is to be routed between topologies, and based on the identifier, uses the first packet to be used in the upstream direction. 2 routing table and a second mapping table can be used.
  • T1 routing ID
  • T2 Path ID
  • T3 BAP address
  • T4 Identifier indicating whether inter-topology transfer is a flag value indicating inter-topology transfer (for example, "1")
  • T5 Upstream or Downstream
  • the IAB node 300-1 can determine the table as the second routing table if the table contains a specific routing ID indicating routing between topologies.
  • the table can be determined as the first routing table.
  • the IAB node 300-1 may determine the table containing the identifier indicating the upstream direction as the second routing table. good. Also, for example, when the packet is a packet in the downstream direction, the IAB node 300-1 may determine the table containing the identifier indicating the downstream direction as the first routing table.
  • FIG. 16 is a diagram showing a fourth operation example according to the first embodiment.
  • the donor node starts processing in step S60.
  • step S61 the donor node sets the first routing table for inter-topology routing and the second routing table for intra-topology routing for the IAB node 300-1.
  • Each of the two tables includes an identifier that identifies the first routing table and the second routing table.
  • the IAB node 300-1 receives the packet.
  • the BAP layer of the IAB node 300-1 checks the header of the packet and determines the routing table to apply. For example, if the information contained in the header matches a specific identifier indicating inter-topology routing, the BAP layer determines the routing table containing the identifier as the second routing table. On the other hand, if the information contained in the header does not correspond to a specific identifier indicating inter-topology routing (or if the information corresponds to a specific identifier indicating intra-topology routing), the BAP layer does not include the identifier. Determine the table as the first routing table. The BAP layer performs routing processing using the determined routing table.
  • step S64 the IAB node 300-1 ends the series of processes.
  • 3GPP does not discuss how to identify the packet direction.
  • the receiver (for example, the receiver of the BAP layer) identifies whether the direction of the received BAP packet is the downstream direction or the upstream direction. Secondly, when the first routing table and the second routing table exist for each direction of the BAP packet, the transmitter selects the first routing table or the second routing table corresponding to the specified direction.
  • the IAB node 300-1 can appropriately transfer the received packet using the routing table corresponding to the specified direction.
  • FIG. 17 is a diagram showing a fifth operation example according to the first embodiment.
  • step S70 the IAB node 300 starts processing.
  • the IAB node 300 receives the packet.
  • the BAP layer of the IAB node 300 identifies the direction of the packet.
  • the BAP layer may identify the direction of the packet as follows.
  • the BAP layer when the BAP layer receives the packet from (the backhaul link corresponding to) the child node of the IAB node 300, it specifies that the packet is in the upstream direction. Also, when the BAP layer receives the packet from (the access link corresponding to) the UE 100, it specifies that it is in the upstream direction. On the other hand, if the BAP layer receives the packet from (the backhaul link corresponding to) the parent node of the IAB node 300, it identifies the downstream direction. Also, when the BAP layer receives the packet in the IAB-DU of the IAB node 300, it identifies the upstream direction. Also, when the IAB-MT of the IAB node 300 receives the packet, the BAP layer identifies the packet as being in the downstream direction.
  • step S73 the BAP layer performs predetermined processing using the identified packet direction.
  • the predetermined process is one of the following processes.
  • the BAP layer selects the routing table corresponding to the specified direction. That is, if the identified packet direction is the upstream direction, the BAP layer selects the first routing table or the second routing table corresponding to the upstream direction. On the other hand, if the identified packet direction is the downstream direction, the BAP layer selects the first routing table or the second routing table corresponding to the downstream direction. The BAP layer then uses the selected routing table to perform routing processing.
  • the BAP layer performs routing for the entry corresponding to the specified direction. For example, assume that there are a first routing table and a second routing table, with an entry in the first routing table specifying packet direction and an entry in the second routing table specifying packet direction. In this case, the BAP layer performs routing processing using the entry corresponding to the specified direction (upstream direction or downstream direction) in the first routing table or the second routing table.
  • step S74 the IAB node 300 transmits the packet to the next hop node.
  • step S75 the IAB node 300 ends the series of processes.
  • the BAP layer identifies the direction of the received packet as in the fifth operation example. Then, when there are two mapping tables for each direction of the packet, the BAP layer selects the first mapping table or the second mapping table corresponding to the specified direction, and uses the selected mapping table for mapping processing. I do. Also, if the mapping table does not exist for each packet and the direction of the packet is specified in the entry in the mapping table, the BAP layer corresponds to the direction in the first mapping table or the second mapping table. The mapping process is performed using the entry for
  • the sixth example of operation describes how the donor DU or access IAB node writes the identifier into the header of the packet.
  • the CU of the donor node associates the DU of the donor node or the access IAB node with the routing ID and writes an identifier indicating inter-topology routing. Set whether to perform or not.
  • the donor node's DU or access IAB node sends a BAP packet with a BAP header containing a routing ID and an identifier to the next hop node according to the configuration.
  • FIG. 18 is a diagram showing a sixth operation example according to the first embodiment.
  • the donor node 200 starts processing in step S80.
  • step S81 the CU of the donor node 200 sets whether or not to write to the identifier indicating inter-topology routing in association with the routing ID for the DU or access IAB node of the donor node 200.
  • the setting to the access IAB node is set using F1AP. That is, the donor node 200 makes settings by transmitting "Uplink Traffic to Routing ID Mapping Configuration" to the access IAB node.
  • the mapping settings include the following IEs.
  • U1 Traffic type specifier
  • U2 routing ID
  • U3 Information as to whether to write an identifier indicating inter-topology routing If not included, the identifier may not be written to the BAP header.
  • the identifier may be written in the BAP header when the information is "1”, and the identifier may not be written in the BAP header when the information is "0". "1" and "0" may be reversed. Further, the information may be indicated by “True” or "False”. Also, the information may be indicated as "Yes” or "No”.
  • the settings for the DU of the donor node 200 are set using a predetermined IE ("IP-to-layer-2 traffic mapping Information List IE"). That is, the CU of the donor node 200 performs setting by outputting "Downlink Traffic to Routing ID Mapping Configuration" to the DU of the donor node 200.
  • the mapping settings include the following IEs.
  • D1 Destination IP Address
  • D2 IPv6 flow level (IPv6 flow label)
  • D3 DSCP (Differentiated Services Code Point)
  • D4 Routing ID
  • D5 Information as to whether to write an identifier indicating inter-topology routing
  • D5 is included in the mapping setting as well as the setting for the access IAB node.
  • D5 writes the identifier into the BAP header when the IE is included in the mapping setting (or writes is specified), and when the IE is not included in the mapping setting.
  • the identifier may not be written (or not specified) in the BAP header.
  • the identifier may be written in the BAP header when the information is "1", and the identifier may not be written in the BAP header when the information is "0". "1" and "0" may be reversed.
  • the information may be indicated by “True” or “False”. Also, the information may be indicated as "Yes” or "No”.
  • the BAP layer of the access IAB node receives a BAP packet (BAP SDU) from the upper layer.
  • BAP SDU BAP packet
  • the BAP layer selects an entry containing the traffic specifier corresponding to the packet from the mapping configuration ("Uplink Traffic to Routing ID Mapping Configuration").
  • the BAP layer uses the routing ID in the selected entry as the routing ID to write to the BAP header.
  • the BAP layer sets the identifier in the BAP header to "1". On the other hand, if writing to the identifier is not specified in the selected entry, the BAP layer sets the identifier to "0".
  • the BAP layer adds a BAP header containing the routing ID and the identifier to the packet (BAP SDU) to generate the BAP PDU.
  • step S83 the BAP layer of the access IAB node performs routing processing and mapping processing on the BAP PDU and transmits it to the next hop node.
  • step S84 the BAP layer of the access IAB node ends a series of processes.
  • steps S82 and S83 when the DU of the donor node 200 performs the processing, the "access IAB node" in steps S82 and S83 is replaced with the "DU of the donor node 200", and the mapping setting is set to "Downlink Traffic to Routing ID Mapping Configuration".
  • Inter-topological rerouting is the IAB node rerouting packets to the original donor node's (or source donor node's) CU via the topological alternate path of the target donor node's CU.
  • inter-topology rerouting in 3GPP, when an IAB node performs recovery from BH RLF via RRC Re-establishment with a new donor CU, the ongoing F1 connection with the original donor node , and rerouting may occur via the restored paths.
  • inter-topology rerouting at the IAB node may be applied with RRC re-establishment to the target donor node while leaving the F1 connection with the source donor node.
  • inter-topology rerouting is applied in a transient state where the F1 connection with the target donor node is unestablished, not in the state of Dual Connectivity (DC) with two donor nodes. there is a possibility.
  • DC Dual Connectivity
  • a routing ID that matches the destination (Destination) included in the BAP header of the BAP packet is selected from the routing table and the packet is transferred.
  • the routing table of the source donor node there is no routing ID to the target donor node (or the BAP address of the DU whose destination is the target donor node). This is because the two donor nodes have different topologies, and the CU of each donor node manages the BAP addresses and the like of each topology.
  • the IAB node cannot forward the packet to the target donor node.
  • the target donor node may not be able to ascertain whether the packet is addressed to itself or the source donor node.
  • the target donor node sets a communication path for inter-topology rerouting to the IAB node, and the IAB node 300 transfers packets via the communication path.
  • the relay node eg., IAB node 300
  • the relay node indicates to the second donor node (e.g., the target donor node) or the second upper node that it will continue communication with the first donor node when performing RRC re-establishment.
  • the first upper node is a node managed by the first donor node and a higher node of the relay node.
  • the second higher node is a node managed by the second donor node and is a higher node of the relay node.
  • the target donor node can grasp that the communication is continued between the IAB node and the source donor node, and triggers the setting of the communication path for inter-topology rerouting by the IAB node. It becomes possible to do it for Then, even in the transient state described above, the IAB node can appropriately transfer the received packet using the communication channel.
  • FIGS. 19A and 19B are diagrams showing configuration examples of topologies according to the second embodiment.
  • FIG. 19(A) shows an example in which BH RLF occurs in the backhaul link between the IAB node 300 and the donor node A (200-A).
  • FIG. 19B shows an example in which BH RLF occurs in the backhaul link between the IAB node 300 and the upper node 300-P1.
  • IAB node 300-P1 is a node managed by donor node A (200-A).
  • the IAB node 300-P2 is a node managed by the donor node B (200-B).
  • FIG. 20 is a diagram showing an operation example according to the second embodiment. The operation example shown in FIG. 20 will be described with reference to the configuration examples shown in FIGS. 19A and 19B as appropriate.
  • the IAB node 300 starts processing in step S90.
  • step S91 BH RLF occurs in the backhaul link.
  • the IAB-MT of IAB node 300 detects BH RLF on the backhaul link with donor node A (200-A).
  • the IAB-MT of the IAB node 300 detects BH RLF with the IAB node 300-P1.
  • the IAB node 300 selects the donor node B (200-B) by cell selection.
  • IAB node 300 may select IAB node 300-P2 managed by donor node B (200-B) through cell selection.
  • step S93 the IAB node 300 executes the RRC Reestablishment procedure for the donor node B (200-B). For example, the following steps are performed.
  • the IAB node 300 sends an RRC Reestablishment Request message to the donor node B (200-B).
  • IAB node 300 may send the message to donor node B (200-B) via IAB node 300-P2.
  • the IAB node 300 may notify the donor node B (200-B) of information (or a request) indicating continuation of communication with the donor node A (200-A) in the message.
  • the IAB node 300 may notify the donor node B (200-B) of information indicating that the IAB node 300 has inter-topology rerouting capability in the message.
  • the IAB node 300 may notify the donor node B (200-B) of information indicating that the F1 connection with the donor node A (200-A) remains in the message.
  • the IAB node 300 may notify the donor node B (200-B) of a request to establish a communication path with the donor node A (200-A) in the message.
  • the notification may be made in a later RRC Reestablishment Complete message or a later UE Assistance Information message.
  • the donor node B (200-B) accepts the RRC re-establishment request and sends an RRC Re-establishment message to the IAB node 300.
  • the IAB node 300 transmits an RRC Re-establishment Complete message to the donor node B (200-B) in response to receiving the RRC re-establishment message.
  • an RRC connection is established between the IAB node 300 and the donor node B (200-B).
  • donor node B (200-B) establishes a communication channel (GTP (GPRS (General Packet Radio System) Tunnelling Protocol)) with donor node A (200-A). This is because the donor node B (200-B) uses the communication channel to transmit upstream packets inter-topologically routed in the IAB node 300 to the donor node A (200-A).
  • donor node A (200-A) also establishes a communication path (GTP) with donor node B (200-B). This is because donor node A (200-A) transmits packets in the downstream direction to donor node B (200-B).
  • donor node B (200-B) sends a communication path establishment request message to donor node A (200-A).
  • Donor node A (200-A) then sends an acknowledgment message to donor node B (200-B) in response to receiving the message.
  • the communication channel may be established.
  • the request message may include the identifier of the IAB node 300, the GTP TEID (Tunnel Endpoint Identifier) for downstream packet reception, and the IP address.
  • the acknowledgment message may include the GTP TEID and IP address for upstream packet reception.
  • the establishment of the GTP communication path may be performed before the donor node B (200-B) sends the IAB node 300 an RRC Re-establishment message.
  • the donor node B (200-B) sets up a communication path for inter-topology rerouting to the IAB node 300. That is, the second donor node (eg, donor node B (200-B)) sets up a communication path for inter-topology rerouting to the relay node (eg, IAB node 300).
  • the second donor node eg, donor node B (200-B)
  • the relay node eg, IAB node 300.
  • the donor node B (200-B) uses the RRC connection established in step S93 to set up a communication channel for the IAB node 300. Specifically, the CU of the donor node B (200-B) sets up the communication path by transmitting an RRC Reconfiguration message to the IAB-MT of the IAB node 300.
  • FIG. The message includes settings for establishing a (temporary) backhaul RLC channel (BH RLC channel) for inter-topology rerouting.
  • BH RLC channel temporary backhaul RLC channel
  • the configuration may include a (temporary) routing table for inter-topology rerouting.
  • the routing table may include a routing ID and a next hop BAP address (Next Hop BAP Address).
  • the configuration may include a (temporary) mapping table for inter-topology rerouting.
  • the mapping table includes an ingress BH RLC channel, an egress BH RLC channel, an ingress BH link, and an egress BH link. may be included.
  • the setting may include the BAP address of the IAB node 300.
  • the BAP address is the BAP address for the IAB node 300 managed by the donor node B (200-B).
  • the configuration may include the BAP address of the DU of donor node B (200-B).
  • the setting may include a BAP header rewriting table.
  • the RRC layer of the IAB node 300 Upon receiving the setting, the RRC layer of the IAB node 300 outputs the setting to the BAP layer of the IAB node 300.
  • the BAP layer may treat the settings as routing tables and/or mapping tables.
  • step S96 the BAP layer of the IAB node 300 performs inter-topology rerouting processing according to the settings.
  • the BAP layer of the IAB node performs the following processing.
  • the BAP layer rewrites the BAP header of the staying packet addressed to the donor node A (200-A) to the routing ID for the DU of the donor node B (200-B) according to the setting.
  • the BAP layer identifies the next-hop BAP address (or the outgoing backhaul link corresponding to the next-hop BAP address) from the routing ID according to the settings.
  • the BAP layer may utilize routing tables for inter-topology rerouting according to the configuration. For example, the BAP layer may read the entry matching the routing ID from the routing table for inter-topology rerouting and identify the outgoing backhaul link corresponding to the entry's next-hop BAP address.
  • the BAP layer identifies the outgoing backhaul RLC channel from the configuration.
  • the BAP layer may utilize a mapping table for inter-topology rerouting according to the configuration. For example, the BAP layer may read the entry matching the packet's ingress backhaul RLC channel, ingress backhaul, and specified egress backhaul link, and identify the egress backhaul RLC channel contained in the entry.
  • the BAP layer outputs the stuck packet to the specified outflow backhaul RLC channel of the specified outflow backhaul link.
  • the following processing may be performed. That is, the BAP layer does not have an entry in the routing table that matches the routing ID included in the header of the packet waiting to be sent that stays in the IAB node 300, and matches the destination included in the header of the packet. If there is no entry in the routing table, the backhaul RLC channel set in the setting is selected as the destination, and the staying packet is transmitted via the selected backhaul RLC channel. In other words, in such a case, the BAP layer sends a staying packet to the communication channel for inter-topology rerouting.
  • the BAP layer of the IAB node 300 transmits the downlink packet transmitted by the donor node A (200-A) from the inflow backhaul link and the inflow backhaul RLC channel to the donor node B (200- B).
  • the donor node A (200-A) or the IAB node 300 indicates that the F1 communication is complete when the F1 connection between the donor node A (200-A) and the IAB node 300 is released.
  • Information (for example, a request to discard the communication channel) is notified to the donor node B (200-B).
  • donor node A (200-A) transmits a request to discard communication for inter-topology rerouting between donor node B (200-B) and IAB node 300 to donor node B (200-B). Then, the donor node B (200-B) returns an acknowledgment to the discard request to the donor node A (200-A), so that the notification and the discarding of the communication can be performed at the same time.
  • the F1 layer of the IAB node may implicitly signal that the F1 connection has been released by sending an F1 setup request to the donor node B (200-B).
  • the donor node B removes from the IAB node 300 the backhaul RLC channel setting for inter-topology rerouting (or setting of the communication path for inter-topology rerouting) set in step S95. That is, a relay node (eg, IAB node 300) establishes an F1 connection with a first donor node (eg, donor node A (200-A)) or an F1 connection with a first upper node (eg, IAB node 300-P1). When the connection is released, discard the channel settings for inter-topology rerouting.
  • a relay node eg, IAB node 300
  • the donor node B may instruct the IAB node 300 to remove the setting.
  • the IAB node 300 may automatically remove the setting. In the latter case, the IAB node 300 may be triggered by the F1 communication completion notification in step S97 to remove the setting.
  • the donor node B (200-B) ends a series of processes.
  • the IAB node 300 re-establishes an RRC connection to the donor node B (200-B), and the donor node B (200-B) uses the RRC message to send the IAB node 300 In response, we set up communication paths for inter-topology rerouting.
  • the modification of the second embodiment is an example in which the communication path is set using F1 instead of RRC.
  • a relay node eg, IAB node 300
  • a first donor node eg, donor node A (200-A)
  • a first upper node eg, IAB node 300 - BH RLF is detected in connection with P1.
  • a relay node performs F1 setup to a second donor node (eg, donor node B (200-B)) or a second upper node (eg, IAB node 300-P2)
  • the first upper node is a node managed by the first donor node and a higher node of the relay node.
  • the second higher node is a node managed by the second donor node and is a higher node of the relay node.
  • the target donor node can grasp that communication will continue between the IAB node and the source donor node, and this notification can be used as a trigger to set up a communication path for inter-topology rerouting using the F1AP message.
  • this notification can be used as a trigger to set up a communication path for inter-topology rerouting using the F1AP message.
  • the IAB node can appropriately perform inter-topology rerouting.
  • FIG. 21 is a diagram showing a modification according to the second embodiment.
  • the IAB node 300 starts processing in step S100.
  • Steps S101 and S102 are the same as steps S91 and S92 of the second embodiment, respectively.
  • step S103 the IAB node 300 executes the RRC re-establishment procedure with the donor node B (200-B) to re-establish the RRC connection with the donor node B (200-B).
  • the IAB node 300 then performs an F1 setup procedure to establish an F1 connection with the donor node B (200-B).
  • the F1 setup procedure is performed between the IAB-DU of the IAB node 300 and the CU of the donor node B (200-B).
  • the F1 setup procedure is performed, for example, as follows.
  • the IAB node 300 sends an F1 Setup Request message to the donor node B (200-B). At this time, the IAB node 300 notifies information indicating that communication with the donor node A (200-A) will be continued in the message, as in the second embodiment. Alternatively, as in the second embodiment, the IAB node 300 may notify information indicating that it has inter-topology rerouting capability, and the F1 connection with the donor node A (200-A) is You may notify the information which shows that it remains. Note that the notification may be made in a later F1 Setup Response message or a later UE Assistance Information message.
  • the donor node B (200-B) accepts the request and sends an F1 setup response message to the IAB node 300.
  • Step S104 is the same as step S94 in the second embodiment.
  • the donor node B sets up a (temporary) communication path for inter-topology rerouting to the IAB node 300.
  • the setting is performed using an F1 Configuration Update message.
  • the setting contents are the same as in the second embodiment.
  • the settings include settings for establishing a (temporary) backhaul RLC channel for inter-topology rerouting, as in the second embodiment.
  • the F1AP layer of the IAB node 300 outputs the settings to the BAP layer of the IAB node 300 .
  • the BAP layer may treat the setting as a routing table and/or a mapping table, as in the second embodiment.
  • step S106 the BAP layer of the IAB node 300 performs inter-topology rerouting processing according to the settings.
  • the inter-topology rerouting process itself is the same as in the second embodiment.
  • Steps S107 and S108 are the same as steps S97 and S98 of the second embodiment, respectively.
  • step S109 the donor node B (200-B) ends the series of processes.
  • the third embodiment describes rerouting between donor DUs.
  • the originator DU of the donor node
  • the destination access IAB node
  • the IAB node 300-1 may perform BAP header rewriting processing.
  • "'previous routing ID to new routing ID' BAP rewriting" has been agreed as a BAP header rewriting process.
  • rerouting differs from routing in principle in that routing processing is performed once, and routing processing is performed again for packets that have no destination. Therefore, it is necessary to consider the timing of performing the BAP header rewriting process.
  • the IAB node 300-1 appropriately selects a route that matches the destination of the received packet, or whether an alternate path is explicitly set by the donor node. Therefore, the setting may become complicated.
  • the first operation example is an operation example in which routing processing is performed once, BAP header rewriting processing is performed on packets that could not be transmitted, and then routing processing is performed again.
  • the relay node receives the packet. Secondly, the relay node performs routing processing on the packet and confirms that it cannot select the next-hop BAP address or select the outgoing backhaul link. Third, the relay node determines that the confirmed packet is a target packet for inter-donor DU rerouting. Fourthly, the relay node performs the routing process again on the packet determined to be the target packet for the inter-donor DU rerouting.
  • the relay node executes BAP header rewriting processing for rewriting the destination of the packet determined as the packet to be rerouted between donor DUs. In this case, the relay node performs routing processing again for the packet whose destination has been rewritten.
  • the IAB node 300-1 can appropriately perform BAP header rewriting processing, routing processing, and routing processing again.
  • FIG. 22 is a diagram showing a first operation example according to the third embodiment. For example, FIG. 22 will be described with reference to the configuration example shown in FIG. 9B as appropriate.
  • step S110 the IAB node 300-1 starts processing.
  • step S111 the IAB node 300-1 receives predetermined settings from the donor node 200.
  • Predetermined settings are, for example, as follows.
  • the header rewriting table is set.
  • the header rewriting table for inter-topology routing described in the first embodiment and the header rewriting table for rerouting between donor DUs according to the third embodiment are set in the header rewriting table.
  • the two tables may include identifiers that identify each table.
  • the BAP addresses of the two donor DUs are set.
  • two BAP addresses of donor DU#1 (200D1) and donor DU#2 (200D2) are set.
  • the number of BAP addresses to be set may be three or more.
  • the BAP layer transmission unit of the IAB node 300-1 receives the packet from the BAP layer reception unit of the IAB node 300-1.
  • the receiving unit of the BAP layer may output packets addressed to itself in the downstream direction to the upper layer, as in the first embodiment. For example, since it is an access IAB node, it does not need to perform routing processing. Therefore, the transmitter receives packets other than packets addressed to itself from the receiver.
  • step S113 the transmission unit performs routing processing on the packet.
  • the routing process for example, the following processes are performed.
  • the sending unit checks the BAP header of the packet and finds that there is no entry in the routing table that matches the destination (Destination) and path ID (Path ID), or even if the entry exists, the Check that the next-hop BAP address corresponding to the entry is not available (Rel-16 routing process).
  • the sending unit checks the BAP header of the packet and finds that no entry with a matching destination exists in the routing table, or even if the entry exists, the next hop BAP address corresponding to the entry is used. Confirm that it is not available (Rel-16 rerouting process).
  • the transmission unit confirms the above two and confirms that the next hop BAP address cannot be selected.
  • the sender confirms that if the next-hop BAP address is available, the corresponding outgoing backhaul link is not available. That is, the transmitter confirms that the outflow backhaul link cannot be selected.
  • the transmitter may confirm that the outgoing backhaul RLC channel cannot be selected in the mapping process. That is, the transmitter may confirm that there is no entry in the mapping table that matches the incoming backhaul RLC channel and the incoming backhaul link of the packet and the outgoing backhaul link selected in the routing process.
  • the transmitting unit confirms the BAP header of the packet and confirms that the destination is the BAP address of the DU of donor node 200 (for example, donor node DU#1 (200D1)).
  • the BAP address of the DU of the donor node is set for the IAB node 300-1 by the donor node 200 in step S111, for example. Therefore, the transmission unit can confirm by comparing this BAP address with the destination of the packet. Note that this confirmation makes it possible to prevent rewriting of the BAP header in the downstream direction and to rewrite the header of packets in the upstream direction.
  • the transmitting unit when the transmitting unit confirms that the packet is addressed to the DU of the donor node 200, it may mark the packet as a packet to be rerouted between donor DUs (or in the upstream direction).
  • the sender may store the packet in a special send buffer (ie, inter-donor DU rerouting buffer) instead of marking.
  • the transmitting unit proceeds to the next header rewriting process.
  • step S114 the transmission unit performs header rewriting processing on the packet.
  • the header rewriting process is the same as step S16 (FIG. 10) of the first operation example in the first embodiment.
  • step S115 the transmission unit performs routing processing and mapping processing again on the packet for which the header rewriting processing has been completed.
  • the transmitter selects the egress backhaul link and the egress backhaul RLC channel by two processes.
  • step S116 the transmission unit outputs the packet to the selected outflow backhaul RLC channel of the selected outflow backhaul link.
  • the IAB node 300-1 then transmits the packet to the selected next hop node.
  • the IAB node 300-1 ends a series of processes.
  • FIG. 23 is a diagram summarizing the first operation example according to the third embodiment.
  • step S120 corresponds to step S112 in FIG.
  • step S122 in FIG. 23 corresponds to step S113 in FIG.
  • step S123 in FIG. 23 corresponds to step S114 in FIG.
  • the transmission unit performs routing processing and mapping processing (step S122), and rewrites the BAP header for packets that could not be routed in the routing processing or could not be mapped in the mapping processing. Processing is performed (step S123).
  • the transmission unit performs routing processing and mapping processing again, and transmits the processed packet to the next hop node as a packet that has been rerouted between donor DUs.
  • At least part of the first operation example according to the third embodiment is also applicable to scenarios other than rerouting between donor DUs.
  • the relay node (eg, the IAB node 300-1) stores a duplicate (or copy) of the packet in a buffer.
  • the relay node selects packets to be rerouted between donor DUs from the packets stored in the buffer.
  • the relay node performs BAP header rewriting processing for rewriting the destination of the selected packet.
  • the relay node performs the routing process again on the packet that has undergone the BAP packet rewriting process.
  • the IAB node 300-1 can select a packet to be rerouted between donor DUs from among the packets staying in the buffer, and can appropriately perform rerouting between donor DUs. .
  • FIG. 24 is a diagram showing a second operation example according to the third embodiment.
  • step S130 the IAB node 300-1 starts processing.
  • the BAP layer of the IAB node 300-1 stores a copy of the packet in the buffer.
  • the BAP layer stores at least one of the routing ID, the next hop BAP address, the outflow backhaul link, and the outflow backhaul RLC channel used to transmit the packet in association with the packet stored in the buffer. may Alternatively, it may have multiple buffers associated with any of the routing ID, next hop BAP address, outgoing backhaul link, and outgoing backhaul RLC channel.
  • the BAP layer may store a copy of the packet in the appropriate buffer depending on the destination of the packet.
  • the BAP layer receives a notification of delivery confirmation of the packet from the lower layer (RLC), it deletes (a copy of) the packet stored in the buffer from the buffer.
  • step S132 when the BAP layer determines to perform inter-donor DU rerouting, it selects packets to be subjected to inter-donor DU rerouting from among the packets stored in the buffer.
  • the execution determination of the inter-donor DU rerouting and the selection of the inter-donor DU rerouting target packet are performed, for example, as follows.
  • the IAB node 300-1 determines to execute the rerouting when BH RLF is detected.
  • the IAB node 300-1 may identify the outgoing backhaul link that detected the BH RLF.
  • IAB node 300-1 may identify at least one of the routing ID, next-hop BAP address, and outgoing backhaul RLC channel affected by the outgoing backhaul link.
  • the IAB node 300-1 selects packets associated with the identified outgoing backhaul link (or at least one of routing ID, next-hop BAP address, and outgoing backhaul RLC channel) from the buffer. The packet can be the rerouted packet.
  • the IAB node 300-1 determines to execute the rerouting when receiving a Type 2 BH RLC Indication.
  • Type 2 BH RLC Indication is an Indication indicating that recovery from BH RLF is underway.
  • the IAB-DU of the IAB node 300-P1 which is the upper node of the IAB node 300-1, transmits the Indication to the IAB-MT of the IAB node 300-1.
  • the IAB node 300-1 may identify the outgoing backhaul link that received the Indication. Alternatively, the IAB node 300-1 can not be routed to the Indication (or should be affected or rerouted), and if the routing ID and the backhaul RLC channel ID are notified, even if these IDs are specified good.
  • the IAB node 300-1 may identify the affected next-hop BAP address from the identified information.
  • the IAB node 300-1 selects packets associated with the identified outflow backhaul link (or at least one of routing ID, outflow backhaul RLC channel, and next hop BAP address) from the buffer.
  • the packet can be the rerouted packet.
  • the IAB node 300-1 determines to execute the rerouting when receiving flow control feedback in the uplink direction from a node higher than the IAB node 300-1.
  • the IAB node 300-1 which has received the flow control feedback from the upper node, performs control such as reducing the amount of data transmitted to the upper node, thereby avoiding congestion between IAB nodes. .
  • the (BAP layer of) IAB-MT of IAB node 300-1 can receive the feedback sent from the IAB-DU of the upper node.
  • IAB node 300-1 may identify the outgoing backhaul link on which the feedback was received. Alternatively, the IAB node 300-1 may identify the routing ID or backhaul RLC channel associated with the affected available buffer size from the feedback.
  • the routing ID or backhaul RLC channel associated with the buffer size may be subject to rerouting.
  • the IAB node 300-1 may identify the next hop BAP address from the identified information.
  • the IAB node 300-1 selects packets associated with at least one of the specified routing ID, outflow backhaul link, outflow backhaul RLC channel, and next-hop BAP address from the buffer. The packet can be the rerouted packet.
  • the IAB node 300-1 executes the rerouting based on some other criteria, it may similarly select the packet to be rerouted.
  • step S133 the IAB node 300-1 performs BAP header rewriting processing on the selected packet.
  • the BAP header rewriting process is the same as the first operation example (step S16 in FIG. 10) of the first embodiment.
  • step S134 the IAB node 300-1 re-performs the routing processing and mapping processing that were performed before the packet transmission on the packet that has undergone the BAP header rewriting processing.
  • the IAB node 300-1 transmits the processed packet to the next hop node.
  • step S135 the IAB node 300-1 ends the series of processes.
  • At least part of the second operational example is also applicable to scenarios other than donor inter-DU rerouting.
  • the BAP layer of the IAB node 300 refers to the BAP header rewrite table set by the donor node 200 and rewrites the BAP header has been described.
  • the BAP layer refers to the normal routing table and appropriately selects the routing ID of the rerouting destination from among the routing IDs that match the destination of the BAP header.
  • S1-2 intra-CU/intra-donor DU rerouting
  • the destination is the access IAB node, which is no different from Rel-16. Therefore, we will not consider the issues in the downstream direction.
  • the routing table is referred to using only the destination (for example, donor DU #1 (200D1)) included in the BAP header as a clue, the DU of another donor node (for example, donor DU #2 (200D2)) cannot be identified. Since the BAP address itself is different, the routing ID to the DU of the other donor may not be selected as a candidate.
  • 3GPP has already agreed to rewrite the BAP header from the previous routing ID to the new routing ID for rerouting between donor DUs.
  • the donor node 200 sends an alternative destination (alternative destination (eg, donor DU #2 (200D2))) linked with the destination (eg, donor DU #1 (200D1)) to the IAB node Set to 300-1. Then, the IAB node 300-1 selects the routing ID including the alternative destination from the routing table and writes the selected routing ID in the BAP header, thereby rewriting the BAP header.
  • alternative destination eg, donor DU #2 (200D2)
  • the destination eg, donor DU #1 (200D1)
  • a donor node eg, donor node 200
  • a relay node eg, IAB node 300-1
  • a first donor node eg, donor DU#1 (200D1)
  • a second destination address of a second donor node eg, donor DU#2 (200D2)
  • relay nodes receive packets in the upstream direction.
  • the relay node performs routing processing and determines that the packet cannot be sent to the next-hop relay node.
  • the relay node if the relay node does not have a first routing ID including a BAP address that matches the first destination address of the packet in the routing table for the determined packet, the BAP address that matches the second destination address from the routing table.
  • the relay node writes the second routing ID into the header of the packet.
  • the second destination address is associated with the first destination address.
  • the IAB node 300-1 can rewrite the BAP header without using the BAP header rewriting table when rerouting between donor DUs.
  • FIG. 25 is a diagram showing a third operation example according to the third embodiment.
  • step S140 the IAB node 300-1 starts processing.
  • step S141 the IAB node 300-1 receives predetermined settings from the donor node 200.
  • Predetermined settings are, for example, as follows.
  • the predetermined settings are BAP addresses for multiple DUs of donor node 200 .
  • the predetermined setting is an alternative destination used for rerouting between donor DUs.
  • a BAP address of a certain destination for example, donor DU#1 (200D1)
  • a BAP address of an alternative destination for example, donor DU#2 (200D2)
  • an identifier may be set to indicate that certain destinations (for example, donor DU#1 (200D1) and donor DU#2 (200D2)) can be used as alternate destinations (in the upstream direction).
  • the IAB node 300-1 receives the packet from the lower node.
  • step S143 the IAB node 300-1 performs normal routing processing and confirms that the next hop node cannot be selected (or cannot be transmitted).
  • the processing in step S143 may be the same as, for example, the first operation example (step S113 in FIG. 22) according to the third embodiment.
  • step S144 the IAB node 300-1 searches the routing table for a routing ID having a BAP address that matches the destination (Destination) included in the header of the packet.
  • IAB node 300-1 has an entry in its routing table with the routing ID and the corresponding next-hop BAP address, outgoing backhaul link, and outgoing backhaul RLC channel are available. In this case, the routing process is performed again according to the settings.
  • the corresponding next-hop BAP address is unavailable (or congested), or the corresponding egress backhaul link and/or egress backhaul RLC channel is If unusable (or congested), proceed to the following process.
  • the IAB node 300-1 determines that the packet is in the upstream direction, it matches the alternate destination (the BAP address of the DU of another donor node different from the destination) linked to the destination of the packet. Search the routing table for the routing ID containing the BAP address to be accessed.
  • the upstream direction determination method is that if the destination included in the header of the packet matches the BAP address of the DU of the donor node 200 set in step S141, the IAB node determines that the packet is up. It can be determined that it is in the stream direction. Also, if there is an alternative destination that matches the destination included in the header of the packet in step S141, the IAB node 300-1 can determine that the destination is upstream.
  • the IAB node 300-1 selects the routing ID when the routing table contains the BAP address of the DU of another donor node (or alternative destination). The IAB node 300-1 then selects the routing ID and corresponding next-hop BAP address, and selects the corresponding egress backhaul link and egress backhaul RLC channel. At this time, the IAB node 300-1 confirms that the selected next-hop BAP address, outgoing backhaul link, and outgoing backhaul RLC channel are available.
  • the IAB node 300-1 writes the selected routing ID into the header of the packet. That is, when the IAB node 300-1 selects a routing ID including an alternative destination, it writes the routing ID into the header. As a result, the BAP header is rewritten.
  • the IAB node 300-1 may report information regarding the BAP header rewriting to the donor.
  • the information is the routing ID before rewriting (that is, the old routing ID or Previous Routing ID) and/or the routing ID after rewriting (that is, the new Routing ID or New Routing ID).
  • the information may further include time (time) information when rerouting was performed and the number of packets for which rerouting was performed.
  • This information may be recorded (logged) in the internal memory of IAB node 300-1 each time a rerouting process occurs. Such reporting may be done each time the rerouting process takes place (ie, immediately) or upon request from the donor (ie, at a later time).
  • step S146 the BAP layer of the IAB node 300-1 outputs the packet to the selected outflow backhaul RLC channel of the selected outflow backhaul link.
  • the IAB node 300-1 transmits the packet to the next hop IAB node (or toward the donor DU#2 (200D2)).
  • step S147 the IAB node 300-1 ends the series of processes.
  • FIG. 26 summarizes the third operation example according to the third embodiment.
  • step S150 corresponds to step S142 in FIG.
  • Step S152 in FIG. 26 corresponds to steps S143 and S144 in FIG.
  • Step S153 in FIG. 26 corresponds to step S145 in FIG.
  • the IAB node 300-1 performs BAP reception processing.
  • the IAB node 300-1 receives packets not only in the upstream direction but also in the downstream direction, as in the first embodiment. 300-1 can be an access IAB node), it may be output to a higher node.
  • the IAB node 300-1 performs BAP transmission processing (step S151) on packets other than packets addressed to itself among the received packets.
  • step S152 the BAP layer of the IAB node 300-1 performs routing processing and mapping processing.
  • the BAP layer determines that an upstream packet routed to a destination different from the destination included in the header of the received packet is a packet to be rewritten with the BAP header (steps S143 and S144 in FIG. 25). Also, the BAP layer searches the routing table for a routing ID including the BAP address of the CU of another donor node linked to the destination of the header.
  • step S153 the BAP layer uses the routing ID to perform BAP header rewriting processing on the packet whose BAP header is to be rewritten (step S144 in FIG. 25).
  • step S152 the BAP layer transmits to the next hop node an upstream packet that is routable to the same destination as that included in the header. Also, the IAB node 300-1 transmits downstream packets to be subjected to BAP transmission processing to the next hop node by routing processing and mapping processing.
  • At least part of the third operation example according to the third embodiment is also applicable to scenarios other than rerouting between donor DUs.
  • FIG. 27 shows an example of common procedures or processes for all scenarios.
  • FIG. 27 shows a configuration example of the IAB node 300 according to the fourth embodiment.
  • the IAB node 300 has a transmitter 330-T and a receiver 330-R.
  • the transmission unit 330-T has a BAP header rewrite determination unit 331, a BAP header rewrite unit 332, a routing/mapping table selection unit 333, a routing/rerouting processing unit 334, and a mapping processing unit 335.
  • the receiving section 330-R has an upper layer output determining section 336.
  • the upper layer output determination unit 336 determines whether to output the received packet to the upper layer or output the packet to the transmission unit 330-T. For example, as described in the first embodiment, determination may be made based on an identifier included in the header of the packet and indicating whether or not the packet is for inter-topology routing.
  • the BAP header rewriting unit 332 rewrites the BAP header of the packet.
  • the BAP header rewriting unit 332 may perform rewriting using a BAP header rewriting table as described in the first embodiment. Also, the BAP header rewriting unit 332 does not perform BAP header rewriting for packets that have never undergone routing processing, and for packets output from the routing/rerouting processing unit 334, BAP header rewriting unit 332 You may make it rewrite.
  • the routing/mapping table selection unit 333 selects a routing table and a mapping table. The routing/mapping table selection unit 333 may select, for example, the second routing table and the second mapping table as described in the first embodiment.
  • the routing/rerouting processing unit 334 performs routing processing and/or rerouting processing on packets whose BAP headers have been rewritten, and routing processing and/or rerouting processing on packets whose BAP headers have not been rewritten. may As described in the third embodiment, the routing/rerouting processing unit 334 once performs routing processing (and/or rerouting processing) and outputs packets with no destination to the BAP header rewriting unit 332. good.
  • the mapping processing unit 335 uses a mapping table to perform mapping processing on packets after routing processing or packets after rerouting processing.
  • the mapping processor 335 transmits the processed packet to the next hop node via the egress backhaul RLC channel.
  • the configuration example of the IAB node 300 shown in FIG. 27 is an example.
  • each embodiment, each operation example, each process, or each step described in the first to fourth embodiments can be combined with each other. All or part of each of the first to fourth embodiments can be combined without contradiction. With such a combination, it may be possible to standardize procedures or processes in all scenarios.
  • a program that causes a computer to execute each process performed by the UE 100 or the gNB 200 may be provided.
  • the program may be recorded on a computer readable medium.
  • a computer readable medium allows the installation of the program on the computer.
  • the computer-readable medium on which the program is recorded may be a non-transitory recording medium.
  • the non-transitory recording medium is not particularly limited, but may be, for example, a recording medium such as CD-ROM or DVD-ROM.
  • a circuit that executes each process performed by the UE 100 or gNB 200 may be integrated, and at least part of the UE 100 or gNB 200 may be configured as a semiconductor integrated circuit (chipset, SoC).
  • the terms “based on” and “depending on,” unless expressly stated otherwise, “based only on.” does not mean The phrase “based on” means both “based only on” and “based at least in part on.” Similarly, the phrase “depending on” means both “only depending on” and “at least partially depending on.” Also, “obtain/acquire” may mean obtaining information among stored information, or it may mean obtaining information among information received from other nodes. or it may mean obtaining the information by generating the information.
  • the terms “include,” “comprise,” and variations thereof are not meant to include only the recited items, and may include only the recited items or in addition to the recited items. Means that it may contain further items.
  • references to elements using the "first,” “second,” etc. designations used in this disclosure do not generally limit the quantity or order of those elements. These designations may be used herein as a convenient method of distinguishing between two or more elements. Thus, references to first and second elements do not imply that only two elements may be employed therein, or that the first element must precede the second element in any way.
  • references to first and second elements do not imply that only two elements may be employed therein, or that the first element must precede the second element in any way.
  • a configured threshold of available buffer size based on flow control feedback is used to determine congestion for the purpose of local rerouting.
  • inter-donor DU rerouting at least in the scenarios of NR-DC between donor DUs, inter-donor inter-DU recovery, and inter-donor inter-DU mobility.
  • the IAB node reroutes the data to the original donor CU via the target CU's topological alternate BAP path.
  • routing and rerouting should cover various scenarios such as intra-CU/intra-donor DU (similar to REL-16), intra-CU/inter-donor DU and inter-CU, as shown in FIG.
  • intra-CU/intra-donor DU similar to REL-16
  • intra-CU/inter-donor DU intra-CU/inter-donor DU
  • inter-CU inter-CU
  • There is These enhancements are expected to contribute to packet forwarding reliability, flexibility, or low latency in IAB topologies, but may introduce additional complexity to BAP routing/rerouting operations. Therefore, it is desirable to define procedures that are common to all scenarios and to have as few scenario-specific procedures as possible. In this sense, the most complex scenario, inter-CPU routing, should be considered first, and then whether the procedure for inter-CPU routing can be applied (reused) to other scenarios.
  • Example 1 Add the BAP address of the border node to the BAP PDU header of the first topology.
  • Example 2 Add a surrogate/fake BAP address for the real destination.
  • RAN3 agrees on topology redundancy as follows. 1A: RAN3 assumes that border nodes have only one BAP address in each topology. 1B: RAN3 assumes that in each topology, the BAP addresses of the boundary nodes of that topology are only used to identify packets that must be passed to upper layers.
  • Example 1 is considered more consistent with the assumptions of RAN3 (especially 1A). Furthermore, Example 1 is very simple from the REL-16 routing mechanism point of view, since border nodes are considered as endpoints of the first topology, like IAB-Donor DUs and access IAB nodes. Also, Example 1 has a lower risk of "misrouting" when intermediate IAB nodes perform local rerouting. In this sense, RAN2 should agree with Example 1 for further discussion.
  • Proposal 1 RAN2 should agree that the BAP address of the border node is added to the BAP data PDU header (ie destination field) in the initial topology.
  • intra-topology routing concatenated traffic (routing between two topologies belonging to different IAB donor CUs)
  • inter-topology routing has other BAP addresses, ie the BAP addresses of IAB donor DUs or access IAB nodes. That is, if the destination does not match the border IAB node's BAP address, the BAP data PDU is delivered from the receiver to the sender of the co-located BAP entity. Therefore, no special processing is required in the receiver.
  • the following Open Issue 3 still exists.
  • Proposal 2 RAN2 agrees that no special processing is required to determine inter-topological routing (non-cocatenated traffic) in the receiving part of the BAP entity, i.e. REL-16 behavior is applied. should.
  • routing ID space is consumed according to the number of paths established between border IAB nodes and IAB donor DU/access IAB nodes. There is no additional overhead in the data stream due to reuse of existing fields in the BAP header.
  • the new flag When the new flag is used, it consumes 'R' bits, so there are only 3 reserved bits. There is no additional overhead since it uses the 'R' bit of the BAP header. It is also assumed that this flag is useful in deciding whether or not to rewrite the BAP header in the sending part of the BAP entity.
  • Proposal 3 For inter-CU routing, RAN2 uses one 'R' bit in the BAP data PDU header to define a new flag to distinguish between routed data and data delivered to higher layers should agree.
  • the sender of the BAP entity can first check the new flag in each BAP data PDU header. If the new flag is ⁇ 0'' (i.e. inter-topology routing containing REL-16 BAP data PDUs ((non-cocatenated traffic) or ⁇ routed to its own topology''), the REL-16 routing procedure is executed. (ie concatenated traffic or "routed to another topology")), a BAP header rewrite operation is performed before the routing procedure. Since this is not "rerouting", it is natural that the BAP header rewriting operation is performed in advance.
  • Proposal 4 RAN2 agrees to use the new flag in the BAP data PDU header of Proposal 3 to determine whether to rewrite the BAP header for inter-CU routing.
  • Proposal 5 For inter-CU routing, RAN2 should agree that BAP header rewriting is performed before the routing procedure.
  • Proposal 6 Regarding inter-CU routing, RAN2 should discuss whether the new flag in Proposal 3 should be rewritten by the BAP header rewriting operation, that is, whether it should be reset to "0".
  • Routing Tables If proposal 5 is agreed, data whose headers have been rewritten according to the header rewriting settings will proceed to the routing procedure. In this case, the data header is already rewritten with a new routing ID as RAN2 has agreed that "RAN2's priority is to support inter-topology routing by rewriting the BAP header based on BAP routing ID option 4". Therefore, the routing table set in the first topology, namely the BH routing setting, is not valid. Otherwise, the BAP address for each IAB node is unique within the topology and not between two topologies (i.e. two CUs) even in an inter-CU routing scenario, creating a risk of confusion or "misrouting" Sometimes. Therefore, the routing table should use the one configured by the second topology.
  • Proposal 7 In the inter-CU scenario, RAN2 should agree that border nodes are configured with two routing tables that are used to route to the first and second topologies respectively.
  • Proposal 7 a routing table selection procedure for each data may be required before the routing procedure.
  • the mechanism is considered very simple: for certain data, when the header is rewritten (or when the new flag is set to "1"), the second routing table is applied. Otherwise, the first routing table (ie the same as REL-16) is applied.
  • Proposal 8 In inter-CU scenarios, RAN2 should discuss whether a procedure to select the routing table of the second topology is necessary for concatenated traffic.
  • the current running CR of TS38.340 contains the following annotations:
  • incoming BH links and RLC channels belong to the first topology, and outgoing BH links are associated with the second topology.
  • BAP addresses and RLC channels are managed by the CU (ie per topology)
  • a new mapping table is required to connect the two topologies.
  • the structure of the REL-16 mapping table can be reused, but must be configured with a different mapping table from REL-16. Otherwise, there is a risk of "mis-mapping" if the same BAP address (ie ingress/egress link ID) and/or the same BH RLC channel ID are used in both topologies. In this case, it may be necessary to select a mapping table similar to Proposal 8.
  • Proposal 9 In inter-CU scenarios, RAN2 assumes that the border IAB nodes are configured with a separate mapping table (in addition to the REL-16 mapping table), and that mapping table is applied for concatenated traffic within the topology. agree.
  • Proposal 10 In the inter-CU scenario, RAN2 will discuss whether the procedure of selecting separate mapping tables for connecting the two topologies of Proposal 9 is necessary for concatenated traffic.
  • RAN2 agreed to ⁇ support inter-ICU rerouting, i.e., the IAB node reroutes data to the original donor CU via an alternate BAP path on the target CU's topology''.
  • this agreement can be viewed as similar to inter-CU routing.
  • inter-CU rerouting is applied when the IAB node re-establishes the RRC connection with the target donor CU and the F1 connection with the source donor CU is still maintained (i.e. partial migration).
  • RAN3 agreed on the following statements which are likely to apply to this scenario.
  • the IP addresses, BAP addresses, BH RLC CHs and default mappings used by border nodes for traffic of a particular topology are assigned by the CU of that topology and they are configured via RRC. be done.
  • the RRC (of the target donor CU) also provides rewriting settings for (simple) routing tables and/or headers used by border IAB nodes. Because the original routing ID in the BAP header of the data rerouted to the original second topology is no longer valid, i.e. the border IAB node has a valid routing ID in the new second topology managed by the target donor CU. Because I need to know. In this sense, the BAP header rewriting operation is also necessary for inter-CU rerouting. In contrast to inter-CU routing, the BAP header rewrite operation is performed when the routing procedure fails, as it is a "reroute", as already covered in the BAP RUNNING CR. Routing table selection may also be applied to inter-CU rerouting if Proposals 7 and 8 are agreed upon. Also, if Proposals 9 and 10 are agreed upon, the selection of BH RLC channel mapping tables may also apply.
  • the border IAB node can then send data to the next-hop BAP address via the BH RLC channel set up by the RRC of the new second topology, ie the target donor CU.
  • Proposal 11 For inter-CU rerouting, RAN2, via RRC signaling from the target donor, allows the border IAB nodes to provide the IP address, BAP address, BH RLC channel and default mapping (as RAN3 agreed), and the default It should be agreed that it consists of a routing ID (or simplified header rewriting table) or the like.
  • Proposal 12 Regarding inter-CU rerouting, RAN2 should agree to rewrite the BAP header when routing (REL-16 routing) fails.
  • Proposal 13 RAN2 should discuss whether routing table selection (when Proposal 8 is introduced) and mapping table selection (when Proposal 10 is introduced) are applicable to inter-CU rerouting.
  • RAN2 has agreed to support rewriting of the ⁇ previous routing ID to new routing ID'' BAP header in inter-donor DU rerouting.
  • RAN3 has agreed as follows.
  • RAN3 wants border nodes to perform BAP header rewriting for both UL and DL traffic only for traffic routed at the BAP layer from a BH link of one topology to a BH link of an adjacent topology.
  • RAN2 Since the topology is managed by the donor CU and two donor DUs within the donor CU are considered intra-CU topology reduction, rerouting between donor DUs is still considered to be performed within one topology. In this case, RAN2's agreement may conflict with RAN3's priority. However, since donor inter-DU rerouting changes the destination of upstream traffic, i.e., from a donor DU's BAP address to another donor DU's BAP address, the BAP header rewrite operation is of course necessary. be. For downstream traffic, the BAP header rewrite operation may not be necessary since the destination (BAP address of the access IAB node) is not changed. In fact, downstream traffic is assumed not to be subject to inter-donor DU rerouting (ie, only local rerouting). Therefore, RAN2 should confirm the agreement even if it differs from RAN3's priority.
  • Proposal 14 For intra-CU/inter-DU rerouting, at least for upstream traffic, confirm RAN2's previous agreement to support 'previous Routing ID to new Routing ID' BAP header rewriting. .
  • Proposal 14 since this is "rerouting", similar to the inter-CU rerouting in Proposal 12, when REL-16 routing fails, the BAP header is rewritten. This is already included in the current TS 38.340 RUNNING CR and can be simply verified.
  • Proposal 15 For intra-CU/inter-donor DU rerouting, RAN2 will perform a BAP header rewrite operation upon routing (i.e. REL-16 routing) failure, as documented in the current running CR of TS38.340 should be ensured that
  • Intra-CU/intra-donor DU rerouting is called local rerouting and is already supported from REL-16 as follows.
  • the BAP address matches the destination field and there is at least one entry in the BH routing configuration with an outgoing link corresponding to the next hop BAP address available. From the BH routing configuration, select the entry where the BAP address is the same as the destination field and the outgoing link corresponding to the next-hop BAP address is available. Select the outgoing link corresponding to the next-hop BAP address of the entry selected above.
  • an IAB node can send a BAP data PDU via a routing ID that matches the destination but not the data path as a result of local rerouting.
  • RAN2#112-E agreed that REL-17 local rerouting should consider the overall topology goals as follows. RAN2 discusses local rerouting, including its advantages over central routing, and how it can address overall topology goals.
  • REL-16 local reroute leaves the choice of alternative paths up to the IAB node implementation, which can be difficult to manage from the donor's perspective.
  • REL-16 IAB topology local reroute is allowed only when an IAB node detects BH RLF, that is, only in certain abnormal conditions, so this is not a big problem.
  • REL-17 allows local reroute under other conditions (eg, congestion conditions), there is still the question of how to meet the above agreement, but not exclusively. It is very easy to understand that a donor who manages the whole topology is the best fit to achieve the goal of the whole topology. In this sense, donors need more control over local rerouting in terms of alternate path setup compared to the REL-16 mechanism.
  • IAB donors are the most suitable nodes to address the overall topology goals by local rerouting.
  • RAN2 has agreed to: Suppose the IAB donor sets up an (alternative) outgoing link that can be used for local rerouting (at least same destination, same routing ID needs further consideration).
  • Outgoing links are associated with N-next-hop BAP addresses, which are determined by routing IDs. Therefore, it is natural for the donor side to set a new routing ID in the IAB node to perform local rerouting, which is very similar to the header rewrite setting in other (re)routing scenarios.
  • RAN3 wants to perform the BAP header write operation only in the inter-topology scenario, but RAN2 has already agreed to perform it also in the intra-topology scenario, i.e. inter-donor DU rerouting, as described above. .
  • Proposal 16 RAN2, if BAP header rewriting is also applied to local rerouting (i.e. intra-CU/inter-DU rerouting) and IAB nodes are configured with a mapping between old and new routing IDs (i.e. , analogous to the header rewrite settings in the current TS38.340 implementation CR) options should be discussed.
  • local rerouting i.e. intra-CU/inter-DU rerouting
  • IAB nodes are configured with a mapping between old and new routing IDs (i.e. , analogous to the header rewrite settings in the current TS38.340 implementation CR) options should be discussed.
  • IAB donor Local Reroute Commands Another aspect of IAB donor controllability is that IAB donors are aware of local rerouting and can start/stop local rerouting on IAB nodes so that local rerouting and topology-wide goals can coexist. There is something to consider. For example, if the IAB donor finds that the overall topology goal cannot be achieved, the IAB donor can instruct the IAB nodes to start/stop local rerouting.
  • Proposal 17 RAN2 should discuss whether IAB nodes should notify IAB donors when starting/stopping local rerouting.
  • Proposal 18 RAN2 should discuss whether IAB donors can instruct IAB nodes to start/stop local rerouting, such as for load balancing between routes.

Landscapes

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

Abstract

第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードが、ドナーノードから、各トポロジにおける当該中継ノードのＢＡＰアドレスが設定されることと、前記中継ノードのＢＡＰレイヤが、パケットを受信することと、前記ＢＡＰレイヤが、前記パケットの流入バックホールＲＬＣチャネルと対応付けられる前記トポロジにおける前記中継ノードのＢＡＰアドレスが、前記パケットのヘッダに含まれる宛先ＢＡＰアドレスと一致する場合、前記パケットを上位レイヤへ出力することとを有する。

Description

通信制御方法及び中継ノード
　本開示は、セルラ通信システムに用いる通信制御方法及び中継ノードに関する。
　セルラ通信システムの標準化プロジェクトである３ＧＰＰ（Third Generation Partnership Project）において、ＩＡＢ（Integrated Access and Backhaul）ノードと呼ばれる新たな中継ノードの導入が検討されている（例えば、「３ＧＰＰ　ＴＳ　３８．３００　Ｖ１６．７．０（２０２１－０９）」参照）。１又は複数の中継ノードが、基地局とユーザ装置との間の通信に介在し、この通信に対する中継を行う。
　第１の態様に係る通信制御方法は、中継ノードが、ドナーノードから、各トポロジにおける当該中継ノードのＢＡＰアドレスが設定されることと、前記中継ノードのＢＡＰレイヤが、パケットを受信することと、前記ＢＡＰレイヤが、前記パケットの流入バックホールＲＬＣチャネルと対応付けられる前記トポロジにおける前記中継ノードのＢＡＰアドレスが、前記パケットのヘッダに含まれる宛先ＢＡＰアドレスと一致する場合、前記パケットを上位レイヤへ出力することとを有する。
　第２の態様に係る中継ノードは、プロセッサを備える。前記プロセッサは、ドナーノードから、各トポロジにおける当該中継ノードのＢＡＰアドレスが設定される処理を実行する。前記プロセッサは、前記中継ノードのＢＡＰレイヤが、パケットを受信する処理を実行する。前記プロセッサは、前記ＢＡＰレイヤが、前記パケットの流入バックホールＲＬＣチャネルと対応付けられる前記トポロジにおける前記中継ノードのＢＡＰアドレスが、前記パケットのヘッダに含まれる宛先ＢＡＰアドレスと一致する場合、前記パケットを上位レイヤへ出力する処理を実行する。
図１は、一実施形態に係るセルラ通信システムの構成例を示す図である。 図２は、ＩＡＢノードと親ノード（Ｐａｒｅｎｔ　ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ　ｎｏｄｅｓ）との関係を示す図である。 図３は、一実施形態に係るｇＮＢ（基地局）の構成例を示す図である。 図４は、一実施形態に係るＩＡＢノード（中継ノード）の構成例を示す図である。 図５は、一実施形態に係るＵＥ（ユーザ装置）の構成例を示す図である。 図６は、ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックの例を示す図である。 図７は、Ｆ１－Ｕプロトコルに関するプロトコルスタックの例を示す図である。 図８は、Ｆ１－Ｃプロトコルに関するプロトコルスタックの例を示す図である。 図９（Ａ）は「ＣＵ内／ドナーＤＵ内」シナリオ、図９（Ｂ）は「ＣＵ内／ドナーＤＵ間」シナリオ、図９（Ｃ）は「ＣＵ間」シナリオにおけるトポロジの構成例を示す図である。 図１０は、第１実施形態に係る第１動作例を表す図である。 図１１は、第１実施形態に係る第１動作例をまとめた図面である。 図１２は、第１実施形態の変形例４に係る動作例を表す図である。 図１３は、第１実施形態に係る第２動作例を表す図である。 図１４は、第１実施形態に係るＢＡＰ　Ｄａｔａ　ＰＤＵパケットの構成例を表す図である。 図１５は、第１実施形態に係る第３動作例を表す図である。 図１６は、第１実施形態に係る第４動作例を表す図である。 図１７は、第１実施形態に係る第５動作例を表す図である。 図１８は、第１実施形態に係る第６動作例を表す図である。 図１９（Ａ）と図１９（Ｂ）は、第２実施形態に係るトポロジの構成例を表す図である。 図２０は、第２実施形態に係る動作例を表す図である。 図２１は、第２実施形態に係る変形例を表す図である。 図２２は、第３実施形態に係る第１動作例を表す図である。 図２３は、第３実施形態に係る第１動作例をまとめた図である。 図２４は、第３実施形態に係る第２動作例を表す図である。 図２５は、第３実施形態に係る第３動作例を表す図である。 図２６は、第３実施形態に係る第３動作例をまとめたものである。 図２７は、第４実施形態に係るＩＡＢノードの構成例を表している。
　図面を参照しながら、実施形態に係るセルラ通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
　（セルラ通信システムの構成）
　一実施形態に係るセルラ通信システムの構成例について説明する。一実施形態に係るセルラ通信システム１は３ＧＰＰの５Ｇシステムである。具体的には、セルラ通信システム１における無線アクセス方式は、５Ｇの無線アクセス方式であるＮＲ（New Radio）である。但し、セルラ通信システム１には、ＬＴＥ（Long Term Evolution）が少なくとも部分的に適用されてもよい。また、セルラ通信システム１は、６Ｇなど、将来のセルラ通信システムも適用されてよい。
　図１は、一実施形態に係るセルラ通信システム１の構成例を示す図である。
　図１に示すように、セルラ通信システム１は、５Ｇコアネットワーク（５ＧＣ）１０と、ユーザ装置（ＵＥ：User Equipment）１００、基地局装置（以下、「基地局」と称する場合がある。）２００－１，２００－２、及びＩＡＢノード３００－１，３００－２を有する。基地局２００は、ｇＮＢと呼ばれる場合がある。
　以下において、基地局２００がＮＲ基地局である一例について主として説明するが、基地局２００がＬＴＥ基地局（すなわち、ｅＮＢ）であってもよい。
　なお、以下において、基地局２００－１，２００－２をｇＮＢ２００（又は基地局２００）、ＩＡＢノード３００－１，３００－２をＩＡＢノード３００とそれぞれ称する場合がある。
　５ＧＣ１０は、ＡＭＦ（Access and Mobility Management Function）１１及びＵＰＦ（User Plane Function）１２を有する。ＡＭＦ１１は、ＵＥ１００に対する各種モビリティ制御等を行う装置である。ＡＭＦ１１は、ＮＡＳ（Non-Access Stratum）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００が在圏するエリアの情報を管理する。ＵＰＦ１２は、ユーザデータの転送制御等を行う装置である。
　各ｇＮＢ２００は、固定の無線通信ノードであって、１又は複数のセルを管理する。セルは、無線通信エリアの最小単位を示す用語として用いられる。セルは、ＵＥ１００との無線通信を行う機能又はリソースを示す用語として用いられることがある。１つのセルは１つのキャリア周波数に属する。以下では、セルと基地局とを区別しないで用いる場合がある。
　各ｇＮＢ２００は、ＮＧインターフェイスと呼ばれるインターフェイスを介して５ＧＣ１０と相互に接続される。図１において、５ＧＣ１０に接続された２つのｇＮＢ２００－１及びｇＮＢ２００－２を例示している。
　各ｇＮＢ２００は、集約ユニット（ＣＵ：Central Unit）と分散ユニット（ＤＵ：Distributed Unit）とに分割されていてもよい。ＣＵ及びＤＵは、Ｆ１インターフェイスと呼ばれるインターフェイスを介して相互に接続される。Ｆ１プロトコルは、ＣＵとＤＵとの間の通信プロトコルであって、制御プレーンのプロトコルであるＦ１－ＣプロトコルとユーザプレーンのプロトコルであるＦ１－Ｕプロトコルとがある。
　セルラ通信システム１は、バックホールにＮＲを用いてＮＲアクセスの無線中継を可能とするＩＡＢをサポートする。ドナーｇＮＢ２００－１（又はドナーノード。以下、「ドナーノード」と称する場合がある。）は、ネットワーク側のＮＲバックホールの終端ノードであり、ＩＡＢをサポートする追加機能を備えたドナー基地局である。バックホールは、複数のホップ（すなわち、複数のＩＡＢノード３００）を介するマルチホップが可能である。
　図１において、ＩＡＢノード３００－１がドナーノード２００－１と無線で接続し、ＩＡＢノード３００－２がＩＡＢノード３００－１と無線で接続し、Ｆ１プロトコルが２つのバックホールホップで伝送される一例を示している。
　ＵＥ１００は、セルとの無線通信を行う移動可能な無線通信装置である。ＵＥ１００は、ｇＮＢ２００又はＩＡＢノード３００との無線通信を行う装置であればどのような装置であってもよい。例えば、ＵＥ１００は、携帯電話端末やタブレット端末、ノートＰＣ、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置、飛行体若しくは飛行体に設けられる装置である。ＵＥ１００は、アクセスリンクを介してＩＡＢノード３００又はｇＮＢ２００に無線で接続する。図１において、ＵＥ１００がＩＡＢノード３００－２と無線で接続される一例を示している。ＵＥ１００は、ＩＡＢノード３００－２及びＩＡＢノード３００－１を介してドナーノード２００－１と間接的に通信する。
　図２は、ＩＡＢノード３００と親ノード（Ｐａｒｅｎｔ　ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ　ｎｏｄｅｓ）との関係例を示す図である。
　図２に示すように、各ＩＡＢノード３００は、基地局機能部に相当するＩＡＢ－ＤＵとユーザ装置機能部に相当するＩＡＢ－ＭＴ（Mobile Termination）とを有する。
　ＩＡＢ－ＭＴのＮＲ　Ｕｕ無線インターフェイス上の隣接ノード（すなわち、上位ノード）は、親ノードと呼ばれる。親ノードは、親ＩＡＢノード又はドナーノード２００のＤＵである。ＩＡＢ－ＭＴと親ノードとの間の無線リンクは、バックホールリンク（ＢＨリンク）と呼ばれる。図２において、ＩＡＢノード３００の親ノードがＩＡＢノード３００－Ｐ１及び３００－Ｐ２である一例を示している。なお、親ノードへ向かう方向は、アップストリーム（ｕｐｓｔｒｅａｍ）と呼ばれる。ＵＥ１００から見て、ＵＥ１００の上位ノードは親ノードに該当し得る。
　ＩＡＢ－ＤＵのＮＲアクセスインターフェイス上の隣接ノード（すなわち、下位ノード）は、子ノードと呼ばれる。ＩＡＢ－ＤＵは、ｇＮＢ２００と同様に、セルを管理する。ＩＡＢ－ＤＵは、ＵＥ１００及び下位のＩＡＢノードへのＮＲ　Ｕｕ無線インターフェイスを終端する。ＩＡＢ－ＤＵは、ドナーノード２００－１のＣＵへのＦ１プロトコルをサポートする。図２において、ＩＡＢノード３００の子ノードがＩＡＢノード３００－Ｃ１～３００－Ｃ３である一例を示しているが、ＩＡＢノード３００の子ノードにＵＥ１００が含まれてもよい。なお、子ノードへ向かう方向は、ダウンストリーム（ｄｏｗｎｓｔｒｅａｍ）と呼ばれる。
　また、１つ又は複数のホップを介して、ドナーノード２００に接続されている全てのＩＡＢノード３００は、ドナーノード２００をルートとする有向非巡回グラフ（ＤＡＧ：Directed Acyclic Graph）トポロジ（以下、「トポロジ」と称する場合がある。）を形成する。このトポロジにおいて、図２に示すように、ＩＡＢ－ＤＵのインターフェイス上の隣り合うノードが子ノード、ＩＡＢ－ＭＴのインターフェイス上の隣り合うノードが親ノードとなる。ドナーノード２００は、例えば、ＩＡＢトポロジのリソース、トポロジ、ルート管理などを集中的に行う。ドナーノード２００は、バックホールリンクとアクセスリンクのネットワークを介して、ＵＥ１００に対して、ネットワークアクセスを提供するｇＮＢである。
　（基地局の構成）
　次に、実施形態に係る基地局であるｇＮＢ２００の構成について説明する。図３は、ｇＮＢ２００の構成例を示す図である。図３に示すように、ｇＮＢ２００は、無線通信部２１０と、ネットワーク通信部２２０と、制御部２３０とを有する。
　無線通信部２１０は、ＵＥ１００との無線通信及びＩＡＢノード３００との無線通信を行う。無線通信部２１０は、受信部２１１及び送信部２１２を有する。受信部２１１は、制御部２３０の制御下で各種の受信を行う。受信部２１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部２３０に出力する。送信部２１２は、制御部２３０の制御下で各種の送信を行う。送信部２１２はアンテナを含み、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。
　ネットワーク通信部２２０は、５ＧＣ１０との有線通信（又は無線通信）及び隣接する他のｇＮＢ２００との有線通信（又は無線通信）を行う。ネットワーク通信部２２０は、受信部２２１及び送信部２２２を有する。受信部２２１は、制御部２３０の制御下で各種の受信を行う。受信部２２１は、外部から信号を受信して受信信号を制御部２３０に出力する。送信部２２２は、制御部２３０の制御下で各種の送信を行う。送信部２２２は、制御部２３０が出力する送信信号を外部に送信する。
　制御部２３０は、ｇＮＢ２００における各種の制御を行う。制御部２３０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサとＣＰＵとを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部２３０は、以下に示す各実施形態において、ｇＮＢ２００における各処理又は各動作を行ってもよい。
　（中継ノードの構成）
　次に、実施形態に係る中継ノード（又は中継ノード装置。以下、「中継ノード」と称する場合がある。）であるＩＡＢノード３００の構成について説明する。図４は、ＩＡＢノード３００の構成例を示す図である。図４に示すように、ＩＡＢノード３００は、無線通信部３１０と、制御部３２０とを有する。ＩＡＢノード３００は、無線通信部３１０を複数有していてもよい。
　無線通信部３１０は、ｇＮＢ２００との無線通信（ＢＨリンク）及びＵＥ１００との無線通信（アクセスリンク）を行う。ＢＨリンク通信用の無線通信部３１０とアクセスリンク通信用の無線通信部３１０とが別々に設けられていてもよい。
　無線通信部３１０は、受信部３１１及び送信部３１２を有する。受信部３１１は、制御部３２０の制御下で各種の受信を行う。受信部３１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部３２０に出力する。送信部３１２は、制御部３２０の制御下で各種の送信を行う。送信部３１２はアンテナを含み、制御部３２０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。
　制御部３２０は、ＩＡＢノード３００における各種の制御を行う。制御部３２０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部３２０は、以下に示す各実施形態において、ＩＡＢノード３００における各処理又は各動作を行ってもよい。
　（ユーザ装置の構成）
　次に、実施形態に係るユーザ装置であるＵＥ１００の構成について説明する。図５は、ＵＥ１００の構成例を示す図である。図５に示すように、ＵＥ１００は、無線通信部１１０と、制御部１２０とを有する。
　無線通信部１１０は、アクセスリンクにおける無線通信、すなわち、ｇＮＢ２００との無線通信及びＩＡＢノード３００との無線通信を行う。また、無線通信部１１０は、サイドリンクにおける無線通信、すなわち、他のＵＥ１００との無線通信を行ってもよい。無線通信部１１０は、受信部１１１及び送信部１１２を有する。受信部１１１は、制御部１２０の制御下で各種の受信を行う。受信部１１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部１２０に出力する。送信部１１２は、制御部１２０の制御下で各種の送信を行う。送信部１１２はアンテナを含み、制御部１２０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。
　制御部１２０は、ＵＥ１００における各種の制御を行う。制御部１２０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部１３０は、以下に示す各実施形態において、ＵＥ１００における各処理を行うようにしてもよい。
　（プロトコルスタックの構成）
　次に、実施形態に係るプロトコルスタックの構成について説明する。図６は、ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックの例を示す図である。
　図６に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Medium Access Control）レイヤと、ＲＬＣ（Radio Link Control）レイヤと、ＰＤＣＰ（Packet Data Convergence Protocol）レイヤと、ＲＲＣ（Radio Resource Control）レイヤと、ＮＡＳ（Non-Access Stratum）レイヤとを有する。
　ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＰＨＹレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。
　ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ：Ｈｙｂｒｉｄ　Ａｕｔｏｍａｔｉｃ　Ｒｅｐｅａｔ　ｒｅＱｕｅｓｔ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＭＡＣレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ＩＡＢ－ＤＵのＭＡＣレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ：Ｍｏｄｕｌａｔｉｏｎ　ａｎｄ　Ｃｏｄｉｎｇ　Ｓｃｈｅｍｅ））及び割当リソースブロックを決定する。
　ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＲＬＣレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
　ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＰＤＣＰレイヤとドナーノード２００のＰＤＣＰレイヤとの間では、無線ベアラを介してデータ及び制御情報が伝送される。
　ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＲＲＣレイヤとドナーノード２００のＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ドナーノード２００とのＲＲＣ接続がある場合、ＩＡＢ－ＭＴはＲＲＣコネクティッド状態である。ドナーノード２００とのＲＲＣ接続がない場合、ＩＡＢ－ＭＴはＲＲＣアイドル状態である。
　ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＮＡＳレイヤとＡＭＦ１１との間では、ＮＡＳシグナリングが伝送される。
　図７は、Ｆ１－Ｕプロトコルに関するプロトコルスタックを示す図である。図８は、Ｆ１－Ｃプロトコルに関するプロトコルスタックを示す図である。ここでは、ドナーノード２００がＣＵ及びＤＵに分割されている一例を示す。
　図７に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴ、ＩＡＢノード３００－１のＩＡＢ－ＤＵ、ＩＡＢノード３００－１のＩＡＢ－ＭＴ、及びドナーノード２００のＤＵの各々は、ＲＬＣレイヤの上位レイヤとしてＢＡＰ（Backhaul Adaptation Protocol）レイヤを有する。ＢＡＰレイヤは、ルーティング処理及びベアラマッピング・デマッピング処理を行うレイヤである。バックホールでは、ＩＰレイヤがＢＡＰレイヤを介して伝送されることにより、複数のホップでのルーティングが可能になる。
　各バックホールリンクにおいて、ＢＡＰレイヤのＰＤＵ（Protocol Data Unit）は、バックホールＲＬＣチャネル（ＢＨ　ＮＲ　ＲＬＣチャネル）によって伝送される。各ＢＨリンクで複数のバックホールＲＬＣチャネルを構成することにより、トラフィックの優先順位付け及びＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）制御が可能である。ＢＡＰ　ＰＤＵとバックホールＲＬＣチャネルとの対応付けは、各ＩＡＢノード３００のＢＡＰレイヤ及びドナーノード２００のＢＡＰレイヤによって実行される。
　図８に示すように、Ｆ１－Ｃプロトコルのプロトコルスタックは、図７に示すＧＴＰ－Ｕレイヤ及びＵＤＰレイヤに代えて、Ｆ１ＡＰレイヤ及びＳＣＴＰレイヤを有する。
　なお、以下においては、ＩＡＢのＩＡＢ－ＤＵとＩＡＢ－ＭＴで行われる処理又は動作について、単に「ＩＡＢ」の処理又は動作として説明する場合がある。例えば、ＩＡＢノード３００－１のＩＡＢ－ＤＵが、ＩＡＢノード３００－２のＩＡＢ－ＭＴへＢＡＰレイヤのメッセージを送信することを、ＩＡＢノード３００－１がＩＡＢノード３００－２へ、当該メッセージを送信するものとして説明する。また、ドナーノード２００のＤＵ又はＣＵの処理又は動作についても、単に「ドナーノード」の処理又は動作として説明する場合がある。
　また、アップストリーム方向とアップリンク（ＵＬ）方向とを区別しないで用いる場合がある。更に、ダウンストリーム方向とダウンリンク（ＤＬ）方向とを区別しないで用いる場合がある。
（ルーティング及びリルーティングのシナリオ）
　ＢＡＰレイヤの機能の１つに、ルーティング（ｒｏｕｔｉｎｇ）とリルーティング（ｒｅ－ｒｏｕｔｉｎｇ）がある。ルーティングは、例えば、受信したパケットをどのＩＡＢノード３００へ転送するかを制御することである。また、リルーティングは、例えば、受信したパケットを、代替パス（alternative path）を介して宛先ノード（アクセスＩＡＢノード又はドナーノード）へ転送するように制御することである。
　３ＧＰＰでは、複数のＩＡＢノード３００によって形成されたネットワーク（又はトポロジ）において、どのようにルーティング又はリルーティングを行うのかについての検討が行われている。
　ルーティング及びリルーティングに関して、以下のシナリオがある。
（Ｓ１）ＣＵ内／ドナーＤＵ内（Ｉｎｔｒａ－ＣＵ／Ｉｎｔｒａ－ｄｏｎｏｒ－ＤＵ）
　（Ｓ１－１）ルーティング
　（Ｓ１－２）リルーティング
（Ｓ２）ＣＵ内／ドナーＤＵ間（Ｉｎｔｒａ－ＣＵ／Ｉｎｔｅｒ－ｄｏｎｏｒ－ＤＵ）
　（Ｓ２－１）ルーティング
　（Ｓ２－２）リルーティング
（Ｓ３）ＣＵ間（Ｉｎｔｅｒ－ＣＵ）
　（Ｓ３－１）ルーティング
　（Ｓ３－２）リルーティング
　このようなシナリオを考慮した上で、各シナリオに共通の手順又は処理を検討したり、各シナリオ個別の手順又は処理を検討したりすることで、トポロジにおける、パケット転送の信頼性、柔軟性、及び低遅延性を向上させることが期待される。
　ここで、各シナリオについて説明する。
（Ｓ１）「ＣＵ内／ドナーＤＵ内」シナリオについて
　図９（Ａ）は、「ＣＵ内／ドナーＤＵ内」シナリオにおけるトポロジの構成例を表している。
　図９（Ａ）に示すように、当該シナリオにおいては、同一のドナーＤＵ（２００Ｄ）と同一のドナーＣＵ（２００Ｃ）において、ルーティングとリルーティングが行われる。
　図９（Ａ）に示すように、ＩＡＢノード３００－１とドナーＤＵ（２００Ｄ）との間には、ＩＡＢノード３００－２を介した経路と、ＩＡＢノード３００－３を介した経路の２つの経路が存在する。ＩＡＢノード３００－１は、アップリンク方向のパケットについては、いずれかの経路に転送させることが可能である。ＩＡＢノード３００－１は、ダウンリンク方向のパケットについても、前記いずれかの経路で転送されてきたパケットを、ＩＡＢノード３００－４又はＩＡＢノード３００－５へ転送させることも可能である。ルーティング（Ｓ１－１）に際しては、このような２つの経路が存在することで、経路について冗長性を確保することができる。
　また、リルーティング（Ｓ１－２）は、所謂、ローカルリルーティングである。例えば、ＩＡＢノード３００－１が、ＩＡＢノード３００－２に対するバックホールリンクにおける無線リンク障害（ＢＨ　ＲＬＦ（Radio Link Failure））（以下、「ＢＨ　ＲＬＦ」と称する場合がある。）を検出したとき、アップリンク方向のパケットについて、代替パスであるＩＡＢノード３００－３を介した経路に切り替えて、リルーティングを行うことも可能である。
（Ｓ２）「ＣＵ内／ドナーＤＵ間」シナリオについて
　図９（Ｂ）は、「ＣＵ内／ドナーＤＵ間」シナリオにおけるトポロジの構成例を表す図である。
　図９（Ｂ）に示すように、当該シナリオでは、１つのドナーノードのＣＵ（２００Ｃ）に、ドナーＤＵ＃１（２００Ｄ１）とドナーＤＵ＃２（２００Ｄ２）の２つの異なるＤＵが接続される。当該シナリオでは、ドナーノードのＣＵ（２００Ｃ）は同一であるものの、異なるドナーＤＵを介して、ルーティングとリルーティングが行われるシナリオとなっている。
　図９（Ｂ）に示すように、ＩＡＢノード３００－１とドナーノードのＣＵ（２００Ｃ）との間には、ＩＡＢノード３００－２とドナーＤＵ＃１（２００Ｄ１）とを介した経路と、ＩＡＢノード３００－３とドナーＤＵ＃２（２００－Ｄ２）とを介した経路の２つの経路がある。
　ＩＡＢノード３００－１におけるアップリンク方向のルーティングでは、ＩＡＢノード３００－１は、ＩＡＢノード３００－２又はＩＡＢノード３００－３へ、パケットを転送できる。ダウンリンク方向についても、前記いずれかの経路で転送されてきたパケットを、ＩＡＢノード３００－１は、ＩＡＢノード３００－４又はＩＡＢノード３００－５へパケットを転送できる。
　当該シナリオにおいては、ドナーノードのＤＵは異なるが、ドナーノードのＣＵは同じであるため、同一トポロジ内でのルーティングとなる。このようなルーティングを、トポロジ内ルーティングと称する場合がある。
　ＩＡＢノード３００－１におけるリルーティングに関しては、例えば、ＩＡＢノード３００－２経由の経路から、ＩＡＢノード３００－３経由の経路（代替パス）に切り替えた場合を考える。この場合、当該パケットの宛先となるドナーＤＵが、ドナーＤＵ＃１（２００Ｄ１）からドナーＤＵ＃２（２００Ｄ２）へ変更される。すなわち、パケットの宛先ＢＡＰアドレスが変更される。そのため、３ＧＰＰでは、当該シナリオで、ＢＡＰヘッダの書き替えを行うことが合意された。ＢＡＰヘッダの書き替えは、直前のルーティングＩＤ（ｐｒｅｖｉｏｕｓ　ｒｏｕｔｉｎｇ　ＩＤ）から新たなルーティングＩＤ（ｎｅｗ　ｒｏｕｔｉｎｇ　ＩＤ）へのＢＡＰヘッダを書き替えることである。なお、ルーティングＩＤは、宛先ＢＡＰアドレス（Ｄｅｓｔｉｎａｔｉｏｎ）と経路識別子（Ｐａｔｈ　ＩＤ）とから構成される。
（Ｓ３）「ＣＵ間」シナリオについて
　図９（Ｃ）は「ＣＵ間」シナリオにおけるトポロジの構成例を表す図である。
　図９（Ｃ）に示すように、当該シナリオでは、ドナーＣＵ＃１（２００Ｃ１）とドナーＣＵ＃２（２００Ｃ２）の２つの異なるＣＵが設けられる。そして、ドナーＣＵ＃１（２００Ｃ１）にはドナーＤＵ＃１（２００Ｄ１）が接続され、ドナーＣＵ＃２（２００Ｃ２）にはドナーＤＵ＃２（２００Ｄ２）が接続される構成となっている。
　一般的に、異なるドナーＣＵにより、異なるトポロジが形成される。すなわち、ドナーＣＵ＃１（２００Ｃ１）からＩＡＢノード３００－１へ至る経路で形成されたトポロジ（第１トポロジ）と、ドナーＣＵ＃２（２００Ｃ２）からＩＡＢノード３００－１へ至る経路で形成されたトポロジ（第２トポロジ）とは異なるトポロジとなり得る。ＩＡＢノード３００－１は、２つの異なるトポロジの境界に位置する。このようなＩＡＢノード３００－１を境界ＩＡＢノード（ｂｏｕｎｄａｒｙ　ｎｏｄｅ）と称する場合がある。
　当該シナリオのルーティング（Ｓ３－１）に関しては、境界ＩＡＢノード３００－１では、ドナーＤＵ＃１（２００Ｄ１）宛てのパケットを、異なるトポロジのドナーＤＵ＃２（２００Ｄ１）へ転送することが可能である。また、ＩＡＢノード３００－４宛のパケットを、異なるトポロジを介して転送することができる。例えばドナーＣＵ＃１（２００Ｃ１）から送信されたパケットが、ドナーＣＵ＃２（２００Ｃ２）、ドナーＤＵ＃２（２００Ｄ２）、ＩＡＢノード３００－３及び３００－１を介して、ＩＡＢノード３００－４に転送できる。これら場合も宛先となるドナーノードのＤＵが変更されるため、３ＧＰＰにおいては、ＢＡＰヘッダの書き替えを行うことが合意された。
　このように異なるトポロジ間でルーティングが行われることを、トポロジ間ルーティングと称する場合がある。
　当該シナリオのリルーティングに関しては、例えば、境界ＩＡＢノード３００－１は、ドナーＣＵ＃２（２００Ｃ２）におけるトポロジ上の代替パスを介して、ドナーＤＵ＃１（２００Ｄ１）宛てのパケットを転送することができる。
　ただし、当該シナリオのリルーティングに関して、３ＧＰＰでは、境界ＩＡＢノード３００－１において、ソースドナーノードであるドナーＣＵ＃１（２００Ｃ１）とはＦ１接続を残したまま、ターゲットのドナーノードであるドナーＣＵ＃２（２００Ｃ２）に対してＲＲＣ再確立（ＲＲＣ　Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）状態で適用されてもよい、ことが合意された。
　以上、３つのシナリオについて説明した。これら３つのシナリオについては、できるだけ、各シナリオ固有の手続を少なくして、全てのシナリオに共通な手順又は処理を特定することが望ましい。共通の手順又は処理とすることにより、シナリオ毎に個別の処理を行う場合よりも、処理を簡略化できるからである。
　実施形態では、以下の順番で各シナリオについて説明する。
［第１実施形態］ＣＵ間ルーティング
　（第１動作例）
　（第２動作例）
　（第３動作例）
　（第４動作例）
　（第５動作例）
　（第６動作例）
［第２実施形態］ＣＵ間リルーティング
［第３実施形態］ＣＵ内／ドナーＤＵ間リルーティング
　（第１動作例）
　（第２動作例）
　（第３動作例）
　なお、以下の説明において、「ＢＨ　Ｒｏｕｔｉｎｇ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ」を「ルーティングテーブル」と称する場合がある。また、「ＢＨ　ＲＬＣ　Ｃｈａｎｎｅｌ　Ｍａｐｐｉｎｇ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ」を「マッピングテーブル」と称する場合がある。更に、「Ｈｅａｄｅｒ　Ｒｅｗｒｉｔｉｎｇ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ」を「ヘッダ書き替えテーブル」と称する場合がある。
　更に、「ＣＵ間ルーティング」を「トポロジ間ルーティング」、「ＣＵ間リルーティング」を「トポロジ間リルーティング」とそれぞれ称する場合がある。
　更に、「ＣＵ内／ドナーＤＵ間リルーティング」を「ドナーＤＵ間リルーティング」と称する場合がある。
　更に、レイヤとエンティティとを区別しないで用いる場合がある。
［第１実施形態］
　第１実施形態では、トポロジ間ルーティングについての実施形態である。
　トポロジ間ルーティングに関して、３ＧＰＰでは、以下の４つのＯｐｅｎ　Ｉｓｓｕｅ（課題）が議論されている。
（課題１）「What’s the BAP address added in BAP header in the first topology (i.e. the BAP address of ingress data at the boundary node).」
（課題２）「How to differentiate the concatenated traffic and non-concatenated traffic.」
（課題３）「How to determine whether a data should be delivered to upper layer (for downstream).」
（課題４）「How to determine whether the BAP header of a data should be rewritten (i.e. whether being routed to another topology or its own topology).」
　（課題１）は、例えば、アクセスＩＡＢノード又はドナーノードのＤＵが、トポロジ間ルーティング対象のＢＡＰパケット（ＢＡＰ　ＰＤＵ）のヘッダに、どのようなＢＡＰアドレスをセットすればよいかについての課題である。例えば、境界ＩＡＢノード３００－１は、セットされたＢＡＰアドレスに基づいて、トポロジ間ルーティング対象のＢＡＰパケットとそうでないパケットとを判別できれば、トポロジ間ルーティングを行ったり、通常のルーティング処理を行ったり、適切に処理することができる。
　（課題２）は、例えば、境界ＩＡＢノード３００－１が、トポロジ間ルーティング（ｎｏｎ－ｃｏｃａｔｅｎａｔｅｄ　ｔｒａｆｆｉｃ）とトポロジ内ルーティング（ｃｏｎｃａｔｅｎａｔｅｄ　ｔｒａｆｆｉｃ）とをどのように判別するかについての課題である。境界ＩＡＢノードが係る判別を適切に行うことができれば、トポロジ間ルーティングとトポロジ内ルーティングとを適切に行うことが可能となる。
　（課題３）は、例えば、境界ＩＡＢノードが、自身の上位レイヤに渡すべきパケットをどのように判別するかについての課題である。例えば、境界ＩＡＢノードでは、アップストリーム方向からのパケットとダウンストリーム方向からのパケットの２つのパケットを受信できる。境界ＩＡＢノードは、ダウンストリーム方向における自身宛てのパケットであれば、自身がアクセスＩＡＢノードであると判別して、上位レイヤへ渡すことが可能である。
　（課題４）は、例えば、ＢＡＰヘッダをどのように書き替えるのかについての課題である。上述したように、トポロジ間ルーティング（例えば、図９（Ｃ））では、アップリンク方向のパケットの場合、宛先ドナーＤＵは、トポロジが異なるドナーＤＵへと変更される。そのため、ＢＡＰヘッダを適切に書き替えることができれば、トポロジが異なるドナーＤＵへの転送が可能となり、適切にトポロジ間ルーティングを行うことが可能となる。
　以上の４つの課題に対して、３ＧＰＰでは、以下の２つのＥｘａｍｐｌｅ（案）が提案されている。
　（案１）：Add the boundary node’s BAP address, in the BAP PDU header in the first topology;
　（案２）：Add some proxy/pseudo BAP address of the real destination；
　（案１）は、ＢＡＰパケットのヘッダに、境界ＩＡＢノード３００－１のＢＡＰアドレスを含ませる提案である。境界ＩＡＢノード３００－１のＢＡＰアドレスを含むパケットは、トポロジ間ルーティングの対象パケットとする案である。ＩＡＢノードでは、受信したパケットのヘッダに含まれる境界ＩＡＢノードのＢＡＰアドレスと自身のＢＡＰアドレスとが一致すれば、自身が境界ＩＡＢノード３００－１として、当該パケットをトポロジ間ルーティング対象のパケットを判定することも可能である。
　（案２）は、ＢＡＰパケットのヘッダに、代理又は偽ＢＡＰアドレスを含ませる提案である。この場合も、ＩＡＢノードでは、受信したＢＡＰパケットのヘッダに偽ＢＡＰアドレスが含まれていれば、当該パケットをトポロジ間ルーティング対象のパケットと判定することも可能である。
　（案１）と（案２）についてはこのような案があることが示されているだけであり、これらの案を用いた具体的な手順又は処理などについては、３ＧＰＰには提案されていない。
　そこで、第１動作例として、上記した４つの課題を考慮した、トポロジ間ルーティングのＢＡＰ処理全体についての動作例を説明する。
（第１動作例）
　第１動作例は、セルラ通信システムで用いる通信制御方法である。第１に、中継ノード（例えば、ＩＡＢノード３００－１）のＢＡＰレイヤの送信部が、中継ノードのＢＡＰレイヤの受信部から、パケットを受信する。第２に、送信部が、パケットのヘッダ情報に基づいて、パケットに対して、トポロジ間ルーティングを行うのか、トポロジ内ルーティングを行うのかを判定する。ここで、中継ノードは、トポロジ間の境界に位置する境界中継ノードである。
　このように第１動作例では、受信したパケットのヘッダ情報に基づいて、トポロジ間ルーティングを行うのか、トポロジ内ルーティングを行うのかを判定する。そのため、第１動作例では、トポロジ間ルーティングを行うのか、トポロジ内ルーティングを行うのかを適切に判定でき、例えば、（課題１）と（課題２）に対する解決策を与えることができる。
　また、第１動作例では、送信部は、トポロジ内ルーティングを行うと判定した場合、トポロジ内ルーティング用の第１ルーティングテーブルとトポロジ内ルーティング用の第１マッピングテーブルとを選択する。他方、送信部は、トポロジ間ルーティングを行うと判定した場合、トポロジ間ルーティング用の第２ルーティングテーブルとトポロジ間ルーティング用の第２マッピングテーブルとを選択する。
　これにより、第１動作例では、トポロジ間ルーティング用のルーティングテーブルとマッピングテーブルを適切に選択することができる。送信部では、これらのテーブルを用いてルーティング処理とマッピング処理とを行うことで、トポロジ間ルーティングを適正に行うことができ、例えば、（課題１）と（課題２）に対する解決策を与えることができる。
　更に、第１動作例では、送信部が、第２のルーティングテーブルと第２のマッピングテーブルとを選択した場合、ＢＡＰヘッダ書き替えテーブルに従って、ＢＡＰパケットのヘッダを、直前のルーティングＩＤから新たなルーティングＩＤへ書き替えるヘッダ書き替え処理を行う。
　これにより、第１動作例では、宛先ＢＡＰアドレスを適切に書き替えて、トポロジ間ルーティングを適切に行うことができ、例えば、（課題４）に対する解決策を与えることができる。
　以下、第１動作例について具体的に説明する。
　図１０は、第１実施形態に係る第１動作例を表す図である。
　図１０に示すように、ステップＳ１０において、ＩＡＢノード３００は処理を開始する。
　ステップＳ１１において、ＩＡＢノード３００（ここでは、境界ＩＡＢノード３００－１）は、ドナーノード２００から所定の設定が行われる。所定の設定は、以下に示すテーブルを受信することである。すなわち、トポロジ内ルーティング用の第１ルーティングテーブル、トポロジ内ルーティング用の第２マッピングテーブル、トポロジ間ルーティング用の第２ルーティングテーブル、トポロジ間ルーティング用の第２マッピングテーブル、及びＢＡＰヘッダ書き替えテーブルである。
　ステップＳ１２において、ＩＡＢノード３００は、パケット（ＢＡＰ　ＰＤＵパケット）を受信する。
　ステップＳ１３において、ＩＡＢノード３００のＢＡＰレイヤの受信部は、受信したパケットについて、自身宛てのダウンストリーム方向又はアップストリーム方向のパケットを識別する。そして、受信部は、自身宛てのパケットを上位レイヤへ出力し、それ以外のパケットを、ＩＡＢノード３００のＢＡＰレイヤの送信部へ出力する。
　受信部は、例えば、以下のようにして自身宛てのパケットを識別する。
　第１に、受信部は、受信したパケットのヘッダ内の宛先（Ｄｅｓｔｉｎａｔｉｏｎ）が、自ＩＡＢノード３００－１のＢＡＰアドレスと一致する場合に、当該パケットを候補パケットと判定する。
　第２に、候補パケットが（案１）の場合、受信部は、候補パケットのヘッダに含まれるパスＩＤを用いて、当該パケットが自身宛てのパケットであることを識別する。具体的には、受信部は、当該パケットのヘッダに含まれるパスＩＤが、所定のパスＩＤ（トポロジ間ルーティングパケット用のパスＩＤ）と異なる場合に、当該パケットは自身宛てのパケットであると識別する。なお、所定のパスＩＤは、例えば、ドナーノード２００によって設定される。候補パケットが（案１）の場合、トポロジ間ルーティング対象のパケットであることを示す識別子を用いて、自身宛てのパケットであることを識別してもよい。具体的には、受信部は、当該パケットのＢＡＰヘッダに含まれる当該識別子が“０”（トポロジ間ルーティング対象のパケットではない）の場合に、候補パケットは自身宛てのパケットであると識別する。
　第３に、候補パケットが（案２）の場合、受信部は、候補パケットを自身宛てのパケットと識別する。つまり、候補パケットの宛先は、自身のＢＡＰアドレスと一致しており、偽ＢＡＰアドレスではないことが確認できるため、ヘッダの宛先が自ＩＡＢノード３００のＢＡＰアドレスと一致する候補パケットは、（案２）の場合、自身宛てのパケットとなり得る。
　受信部は、候補パケットが自身宛てのパケットと識別した場合、ＢＡＰヘッダを取り除いて、上位レイヤへ出力する。自身宛てのパケットは、自ＩＡＢノード３００－１がアクセスＩＡＢノードとして、ＵＥ１００へ送信するためのパケットである。そのため、上位レイヤでは、当該パケットがＵＥ１００へ送信されるよう処理が行われる。
　一方、受信部は、受信したパケットのうち、自身宛てのパケットではないと識別したパケットを、ＢＡＰレイヤの送信部へ出力する。
　ステップＳ１４において、送信部は、受信部から受け取った当該パケットのルーティングモードを選択する。ルーティングモードは、トポロジ内ルーティングとトポロジ間ルーティングとがある。
　判定方法は、例えば、以下のように行われる。すなわち、送信部は、当該パケットのヘッダ情報について、少なくとも、以下のいずれかに該当する場合に、当該パケットがトポロジ間ルーティング対象パケットである（トポロジ間ルーティングモード）と判定し、そうでない場合、トポロジ内ルーティングモード（トポロジ内ルーティングモード）と判定する。
　Ｍ１：トポロジ間ルーティングであることを示す特定のルーティングＩＤと一致する場合、又は
　Ｍ２：トポロジ間ルーティングであることを示す特定のパスＩＤと一致する場合、又は
　Ｍ３：トポロジ間ルーティングであることを示す特定のＢＡＰアドレス（例えば、提案（２））と一致する場合、又は
　Ｍ４：トポロジ間転送か否かを示す識別子がトポロジ間転送を示す場合（例えば、“１”）、又は
　Ｍ５：ＢＡＰパケットの宛先ＢＡＰアドレスが、特定したＢＡＰアドレスとは異なるトポロジに紐づいたＢＡＰアドレスと一致する場合、又は
　Ｍ６：受信部からパケット毎にルーティングモード情報が提供され、当該情報がトポロジ間ルーティング（又はトポロジ内ルーティング）を示している場合。受信部において、上記Ｍ１～Ｍ５を用いてルーティングモードを判定してもよい。
　上記Ｍ５の詳細は第２動作例で説明する。
　送信部は、判定結果に応じて、異なるバッファに当該パケットを格納してもよい。例えば、送信部は、当該パケットがトポロジ間ルーティング対象のパケットと判定した場合、当該パケットをトポロジ間ルーティング用のバッファに格納する。また、例えば、送信部は、当該パケットがトポロジ内ルーティング対象のパケットと判定した場合、当該パケットをトポロジ内ルーティング用のバッファに格納する。
　ステップＳ１５において、送信部は、ルーティングテーブルとマッピングテーブルとを選択する。送信部は、デフォルトとして、トポロジ内ルーティング用の第１ルーティングテーブルを選択するようにしてもよい。
　そして、送信部は、ステップＳ１４において、トポロジ間ルーティング対象のパケットと判定した場合、トポロジ間ルーティング用の第２ルーティングテーブルが設定されていれば、当該第２ルーティングテーブルを選択する。更に、第２マッピングテーブルが設定されていれば、送信部は、当該第２マッピングテーブルを選択する。
　一方、送信部は、トポロジ間ルーティング対象のパケットと判定した場合において、第２ルーティングテーブルが設定されていない場合、当該ＩＡＢノード３００は、境界ＩＡＢノード３００－１ではなかったとして、トポロジ内ルーティング用の第１ルーティングテーブルを選択する。すなわち、送信部は、当該パケットを、特定のルーティングＩＤと一致する等により、トポロジ間ルーティング対象のパケットと判定したものの、ＩＡＢノード３００では、第２ルーティングテーブルが設定されていなかった場合である。例えば、ドナーＤＵと境界ＩＡＢノード３００－１との間の中間に位置するＩＡＢノード（ＩＡＢノード３００－２及びＩＡＢノード３００－３）の場合がこれにあたる。このようなＩＡＢノードでは、当該パケットを、トポロジ間ルーティング対象のパケットであると認識するものの、第２ルーティングテーブルの設定を受けてないので、当該パケットに対してはトポロジ間ルーティングを実行しない。この場合は、送信部は、第１ルーティングテーブルを選択する。
　同様に、送信部は、第２マッピングテーブルが設定されていない場合、第１マッピングテーブルを選択する。
　一方、送信部は、ステップＳ１５において、当該パケットがトポロジ内ルーティング対象のパケットと判定した場合、第１ルーティングテーブルを選択する。更に、送信部は、第２マッピングテーブルを選択する。
　なお、送信部は、当該パケットを、ルーティングテーブル毎に異なるバッファに格納してもよい。送信部は、第１ルーティングテーブルを選択した場合は、当該パケットを第１ルーティングテーブル用バッファに格納する。また、送信部は、第２ルーティングテーブルを選択した場合は、当該パケットを第２ルーティングテーブル用バッファに格納する。
　ステップＳ１６において、送信部は、当該パケットに対して、ＢＡＰヘッダ書き替え処理を行う。すなわち、送信部は、当該パケットについてトポロジ間ルーティングを行う場合（又は、ステップＳ１５において、第２ルーティングテーブルと第２マッピングテーブルとを選択した場合）、ＢＡＰヘッダ書き替え処理を行う。
　送信部は、ヘッダ書き替えテーブルを利用して、ＢＡＰヘッダ書き替え処理を行う。ＢＡＰヘッダ書き替えテーブルには、旧ルーティングＩＤ（直前のルーティングＩＤ）と新ルーティングＩＤ（新たなルーティングＩＤ）とを含むエントリが含まれる。具体的には、送信部は、当該パケットのヘッダに含まれるルーティングＩＤと一致する、旧ルーティングＩＤを含むエントリがヘッダ書き替えテーブルに存在する場合、当該パケットのヘッダに含まれるルーティングＩＤを、当該エントリの新ルーティングＩＤに書き替える。
　なお、送信部は、当該パケットのヘッダに含まれるルーティングＩＤと一致する、旧ルーティングＩＤを含む当該エントリがヘッダ書き替えテーブルに存在しなかった場合、当該パケットはトポロジ間ルーティング対象のパケットではないと判定してもよい。この場合、送信部は、ＢＡＰヘッダ書き替え処理を行わない。又は、この場合、送信部は、リルーティング処理のような処理を行ってもよい。すなわち、送信部は、当該パケットの宛先（Ｄｅｓｔｉｎａｔｉｏｎ）と一致する、旧ルーティングＩＤのＢＡＰアドレス部を含むエントリがヘッダ書き替えテーブルに存在する場合、当該パケットのＢＡＰヘッダのルーティングＩＤを、当該エントリの新ルーティングＩＤへ書き替えてもよい。
　ステップＳ１７において、送信部は、当該パケットに対してルーティング処理とマッピング処理とを行う。
　第１に、送信部は、ステップＳ１５で選択したルーティングテーブル（第１ルーティングテーブル又は第２ルーティングテーブル）を用いてルーティング処理を行う。具体的には、送信部は、当該パケットのヘッダに含まれる宛先（Ｄｅｓｔｉｎａｔｉｏｎ）とパスＩＤ（Ｐａｔｈ　ＩＤ）と一致するエントリが、選択したルーティングテーブルに存在し、当該エントリの次ホップＢＡＰ（Ｎｅｘｔ　Ｈｏｐ　ＢＡＰ）アドレスに対応する流出バックホールリンク（ｅｇｒｅｓｓ　ＢＨ　ｌｉｎｋ）が利用可能な場合、当該流出バックホールリンクを選択する。
　ここで、第１ルーティングテーブルを用いる場合は、トポロジ内ルーティングの場合である。すなわち、ダウンリンク方向のパケットに対しても、アップリンク方向のパケットに対しても、トポロジ内ルーティングの場合は、第１ルーティングテーブルを用いてルーティング処理が行われる。
　他方、第２ルーティングテーブルを用いる場合は、トポロジ間ルーティングの場合である。ＩＡＢノード３００－１が境界ＩＡＢノードとして、受信したパケットに対して、トポロジ間ルーティング処理を行う。例えば、ＩＡＢノード３００－１は、ドナーＤＵ＃１（２００Ｄ１）宛てのパケットを、ドナーＤＵ＃１（２００Ｄ２）へ向けたパケットとなるように、ルーティング処理を行う。
　第２に、送信部は、ステップＳ１５で選択したマッピングテーブル（第１マッピングテーブル又は第２マッピングテーブル）を用いてマッピング処理を行う。具体的には、送信部は、当該パケットの流入バックホールＲＬＣチャネル（ｉｎｇｒｅｓｓ　ＢＨ　ＲＬＣ　ｃｈａｎｎｅｌ）、当該パケットの流入バックホールリンク（ｉｎｇｒｅｓｓ　ＢＨ　ｌｉｎｋ）、及び上記マッピング処理で選択した流出バックホールリンクと一致するエントリが、選択したマッピングテーブルに存在する場合、当該エントリの流出バックホールＲＬＣチャネル（ｅｇｒｅｓｓ　ＢＨ　ＲＬＣ　ｃｈａｎｎｅｌ）を選択する。
　送信部は、選択した流出バックホールリンクの選択した流出バックホールＲＬＣチャネルへ、当該パケットを出力する。
　ステップＳ１８において、ＩＡＢノード３００は、当該パケットを次ホップのノードへ送信する。この場合、ＩＡＢノード３００（境界ＩＡＢノード３００－１）は、トポロジ間ルーティングにより、例えば、ドナーＤＵ＃２（２００Ｄ２）へ向けて当該パケットを送信する。又は、ＩＡＢノード３００は、トポロジ内ルーティングにより、例えば、ドナーＤＵ＃１（２００Ｄ１）へ向けて当該パケットを送信する。
　ステップＳ１９において、ＩＡＢノード３００は、一連の処理を終了する。
（第１動作例のまとめ）
　図１１は、第１実施形態に係る第１動作例をまとめた図面である。
　図１１において、ＢＡＰ受信処理（ステップＳ３０）は、図１０におけるステップＳ１１からステップＳ１３に対応する。また、図１１において、ルーティングモード選択（ステップＳ３１）は、図１０におけるステップＳ１４に対応する。更に、図１１において、ルーティングテーブル／マッピングテーブル選択（ステップＳ３２）は、図１０におけるステップＳ１５に対応する。更に、図１１において、ＢＡＰヘッダ書き替え処理（ステップＳ３３）は、図１０におけるステップＳ１６に対応する。更に、図１１において、ルーティング処理／マッピング処理（ステップＳ３４）は、図１０におけるステップＳ１７に対応する。
（第１動作例の変形例）
（変形例１）
　第１動作例は、第２ルーティングテーブル、第２マッピングテーブル、及びヘッダ書き替えテーブルが設定されている場合に実行されてもよい。すなわち、第２ルーティングテーブル、第２マッピングテーブル、又はヘッダ書き替えテーブルが設定されていない場合、第１動作例が行われなくてもよい。
（変形例２）
　第１動作例では、「トポロジ間ルーティング」のシナリオ（Ｓ３－１）の例で説明した。ＢＡＰヘッダ書き替えについては、「ＣＵ内／ドナーＣＵ間リルーティング」のシナリオ（Ｓ２－２）でも行われることが３ＧＰＰにおいて合意されている。
　従って、第１動作例の少なくとも一部については、「トポロジ間ルーティング」のシナリオ以外のシナリオに適用されてもよい。例えば、「ＣＵ内／ドナーＤＵ間リルーティング」のシナリオ（Ｓ２－２）、又は「ＣＵ内／ドナーＤＵ内リルーティング」のシナリオ（Ｓ１－２）に適用される場合、第１動作例における「トポロジ内又はトポロジ間」を「通常ルーティング又はドナーＤＵ間リルーティング」等とそれぞれ読み替えて動作が行われてよい。
（変形例３）
　第１動作例では、ルーティングテーブルについて、トポロジ内ルーティング用の第１ルーティングテーブルと、トポロジ間ルーティング用の第２ルーティングテーブルの２つのテーブルを用いた例を説明した。例えば、ルーティングテーブルについては、３つ以上のルーティングテーブルが設定されてもよい。
　例えば、図９（Ｃ）において、ＩＡＢノード３００－１がドナーＣＵ＃１（２００Ｃ１）（以下、「第１ドナー」と称する場合がある。）配下において、ドナーＣＵ＃１（２００Ｃ２）（以下では「、第２ドナー」と称する場合がある。）に対するトポロジ間ルーティングを行う場合を仮定する。トポロジ間ルーティング後のトポロジは、ダウンストリーム方向では、第１ドナーがルーティングＩＤを管理し、アップストリーム方向では、第２ドナーがルーティングＩＤを管理する。この場合、第１ドナーと第２ドナーとでネゴシエーションがない場合、同一のルーティングＩＤが使用される可能性がある。
　例えば、ＩＡＢノード３００－１が、トポロジ間ルーティング後、下位ノードからパケットを受信し、ルーティング処理を行うと仮定する。この場合、ＩＡＢノード３００－１は、当該パケットのルーティングＩＤと一致するエントリをルーティングテーブルから選択する。しかし、第１ドナーが管理するダウンストリーム方向のルーティングテーブルと、第２ドナーが管理するアップストリーム方向のルーティングテーブルとで、同一のルーティングＩＤが存在する場合、ＩＡＢノード３００－１は、同一ルーティングＩＤのエントリを、ダウンストリーム方向のルーティングテーブルから検索する場合がある。この場合、ＩＡＢノード３００－１は、下位ノードから受信したパケットを再び下位ノードへ転送する場合がある。
　そこで、変形例３では、トポロジ間ルーティングテーブルについて、アップストリーム用のトポロジ間ルーティングテーブルと、ダウンストリーム用のトポロジ間ルーティングテーブルの２つのルーティングテーブルがＩＡＢノード３００－１に設定される。また、トポロジ内ルーティングテーブルについて、アップストリーム用のトポロジ内ルーティングテーブルと、ダウンストリーム用のトポロジ内ルーティングテーブルとがＩＡＢノード３００－１に設定される。
　例えば、ＩＡＢノード３００－１は、下位ノードから受信したパケットを、アップストリーム方向と判定して、アップストリーム方向と紐づいた、トポロジ間テーブル又はトポロジ内テーブルを用いてルーティング処理を行う。
　これにより、トポロジ間で同一ルーティングＩＤを用いた場合であっても、ＩＡＢノード３００－１は、パケットを適切に転送できる。
（変形例４）
　第１動作例では、ＢＡＰヘッダ書き替え処理は、ルーティングテーブル／マッピングテーブル選択（ステップＳ３２）の後であって、ルーティング処理／マッピング処理（ステップＳ３４）の前に行われた。
　変形例４は、ＢＡＰヘッダ書き替え処理が、ＢＡＰ送信処理の最初に行われる例である。
　図１２は、第１実施形態の変形例４に係る動作例を表す図である。
　図１２に示すように、ＢＡＰ送信処理は、以下の順で行われる。すなわち、ＢＡＰヘッダ書き替え処理（ステップＳ３３）、ルーティングモード選択（ステップＳ３１）、ルーティングテーブル／マッピングテーブル選択（ステップＳ３２）、及びルーティング処理／マッピング処理（ステップＳ３４）である。
　ステップＳ３３において、送信部は、ＢＡＰヘッダ書き替え処理を行う。送信部は、例えば、以下の処理を行う。
　すなわち、ＩＡＢノード３００－１のＢＡＰレイヤの送信部は、ＩＡＢノード３００－１のＢＡＰレイヤの受信部から、ＢＡＰパケット（ＢＡＰ　ＰＤＵ）を受信すると、ステップＳ３３において、ＢＡＰヘッダ書き替え処理を行う。具体的には、送信部は、以下の処理を行う。
　第１に、送信部は、当該パケットのヘッダに含まれるルーティングＩＤと一致する、旧ルーティングＩＤを含むエントリがヘッダ書き替えテーブルに存在するか否かを判定する。
　送信部は、当該エントリがヘッダ書き替えテーブルに存在する場合、当該パケットの当該ＢＡＰヘッダに含まれるルーティングＩＤを、当該エントリ内の新たなルーティングＩＤへ書き替える。他方、送信部は、当該エントリがヘッダ書き替えテーブルに存在しない場合、ＢＡＰヘッダ書き替えを行わない。この場合、送信部は、当該パケットについて、トポロジ間ルーティングの対象ではなかったと判定してもよい。又は、この場合、送信部は、リルーティング的な処理を行ってもよい。すなわち、当該パケットのヘッダ内の宛先（Ｄｅｓｔｉｎａｔｉｏｎ）と一致する、旧ルーティングＩＤのＢＡＰアドレスを含むエントリが、ヘッダ書き替えテーブルに存在する場合、当該ＢＡＰヘッダのルーティングＩＤを、当該エントリに含まれる新たなルーティングＩＤへ書き替える。
　第２に、送信部は、ＢＡＰヘッダ書き替えを行った場合、ＢＡＰヘッダ書き替え実施済パケット用のバッファに、当該パケットを格納してもよい。他方、送信部は、ＢＡＰヘッダ書き替えを行わなかった場合、ＢＡＰヘッダ未書き替えパケット用のバッファに、当該パケットを格納してもよい。
　その後、ステップＳ３１において、送信部は、ルーティングモード選択（ステップＳ３１）を行う。送信部は、例えば、以下の処理を行う。すなわち、送信部は、ＢＡＰヘッダ書き替えを行った場合、当該パケットを、トポロジ間ルーティング対象のパケットであると判定してもよい。また、送信部は、ＢＡＰヘッダ書き替えを行わなかった場合、当該パケットを、トポロジ内ルーティング対象のパケットであると判定してもよい。ステップＳ３１は省略されてもよい。
　その後、ステップＳ３２において、送信部は、ルーティングテーブル／マッピングテーブルを選択する。送信部は、例えば、以下のような処理を行う。すなわち、送信部は、ＢＡＰヘッダ書き替え時において選択した新たなルーティングＩＤと紐づいた第２ルーティングテーブルと第２マッピングテーブルとを選択してもよい。この場合、新たなルーティングＩＤと各テーブルとの紐付け情報が、ドナーノード２００からＩＡＢノード３００－１に設定される。
　その後、ステップＳ３４において、送信部は、ルーティング処理とマッピング処理とを行う。２つの処理は、第１動作例と同様である。
　第１動作例では、トポロジ内シナリオとトポロジ間シナリオに適用する２つのルーティングテーブル（及び２つのマッピングテーブル）を用いる例を説明したが、これに限らない。トポロジ内シナリオとトポロジ間シナリオの両方で使用する１つのルーティングテーブル（及び１つのマッピングテーブル）を定義してもよい。この場合、テーブル内の各エントリには、トポロジ内シナリオに適用するエントリであるのか、トポロジ間シナリオに適用するエントリであるのかを示す情報が含まれていてもよい。当該情報は、ＢＡＰヘッダ書き替えを行ったパケットに適用するのか、ＢＡＰヘッダ書き替えを行わなかったパケットに適用するのかを示す情報であってもよい。或いは、当該情報はパケットの送出先のトポロジ（または当該トポロジを管理するドナー）を示す識別子であってもよい。或いは、当該情報はアップストリームのパケットに適用すべきか、ダウンストリームのパケットに適用すべきかを示す情報であってもよい。ＩＡＢノード３００－１は、特定したルーティングモード（もしくはシナリオ）に合致するエントリのみをルーティング処理（及びマッピング処理）の対象（候補）とする。
（第２動作例）
　次に、第１実施形態に係る第２動作例について説明する。
　第２動作例も、ＩＡＢノード３００－１が受信したパケットについて、トポロジ間ルーティング対象のパケットか否かを識別する動作例である。
　図９（Ｃ）に示すように、境界ＩＡＢノード３００－１は、２つのトポロジと接続される。各トポロジは、各ドナーノード（ドナーＣＵ＃１（２００Ｃ１）とドナーＣＵ＃２（２００Ｃ２））で管理されることが想定される。そのため、境界ＩＡＢノード３００－１のＢＡＰアドレスは、ドナーＣＵ＃（２００Ｃ１）が管理するＢＡＰアドレスと、ドナーＣＵ＃２（２００Ｃ）が管理するＢＡＰアドレスの２つのＢＡＰアドレスを有することになる。なお、ＢＡＰアドレスはトポロジ内で一意であることが原則である。
　上記（案２）で示されるように、トポロジ間ルーティング対象のパケットを識別する方法として、偽ＢＡＰアドレス（ｐｒｏｘｙ／pseudo　ＢＡＰ　Ａｄｄｒｅｓｓ）を境界ＩＡＢノード３００－１に割り当てる案が提案されている。この場合、境界ＩＡＢノード３００－１には、ドナーＣＵ＃１（２００Ｃ１）によって割り当てられる偽ＢＡＰアドレスと、ドナーＣＵ＃２（２００Ｃ２）によって割り当てられる偽ＢＡＰアドレスの２つの偽ＢＡＰアドレスが割り当てられる場合がある。更に、上述したように、境界ＩＡＢノード３００－１は、自ＢＡＰアドレスとして、これら２つのドナーによって、２つの自ＢＡＰアドレスが割り当てられる。
　従って、境界ＩＡＢノード３００－１には、４つのＢＡＰアドレスが割り当てられる場合がある。この４つのＢＡＰアドレスを用いて、トポロジ間ルーティング対象のパケットを識別するには、複雑な処理となる場合がある。
　また、ＢＡＰレイヤは、ＢＡＰアドレスを選択するために、どのトポロジから当該パケットが流入してきたのかを判定する可能性もある。
　そこで、第２動作例では、ＩＡＢノード３００－１は、流入したパケットのトポロジを特定し、当該トポロジと紐づけられたＢＡＰアドレスを自身のＢＡＰアドレスとして特定し、特定したＢＡＰアドレスを用いて、第１動作例と同様に、ＢＡＰ受信処理とＢＡＰ送信処理を行う。
　すなわち、第１に、中継ノード（例えば、ＩＡＢノード３００－１）が、ドナーノード（例えば、ドナーノード２００）から、各トポロジにおける当該中継ノードのＢＡＰアドレスが設定される。第２に、中継ノードが、ドナーノードから、トポロジと流入バックホールリンクとを紐づける紐付け情報、及び／又は、トポロジと流入バックホールＲＬＣチャネルとを紐付ける紐付け情報、が設定される。第３に、中継ノードのＢＡＰレイヤが、パケットを受信する。第４に、ＢＡＰレイヤが、パケットの流入バックホールリンク及び／又は流入バックホールＲＬＣチャネルに基づいて、パケットが属するトポロジを特定し、特定したトポロジに紐づいたＢＡＰアドレスを中継ノードのＢＡＰアドレスとして特定する。ここで、中継ノードは、トポロジ間の境界に位置する境界中継ノード（例えば、境界ＩＡＢノード３００－１）である。
　これにより、例えば、４つのＢＡＰアドレスを用いることなく、各トポロジに紐づけられた２つのＢＡＰアドレスを用いるだけでよいため、４つのＢＡＰアドレスを用いる場合と比較して、処理を簡略化することが可能である。
　図１３は、第１実施形態に係る第２動作例を表す図である。
　ここで、ＩＡＢノード（ここでは、境界ＩＡＢノード）３００－１は、２つのトポロジとの接続を有していると仮定する。例えば、図９（Ｃ）に示すように、境界ＩＡＢノード３００－１は、ドナーＣＵ＃１（２００Ｃ１）とドナーＣＵ＃２（２００Ｃ２）との接続を有する。この場合、境界ＩＡＢノード３００－１と２つのドナーノードとの関係は、境界ＩＡＢノード３００－１とＦ１ＡＰ接続を有するドナーノードと、境界ＩＡＢノード３００－１とＦ１ＡＰ接続を有しないドナーノードとの関係であってもよい。また、当該関係は、境界ＩＡＢノード３００－１と第１（メイン又はマスタ）Ｆ１ＡＰ接続を有するドナーノードと、境界ＩＡＢノード３００－１と第２（セカンダリ）Ｆ１ＡＰ接続を有するドナーノードとの関係でもよい。更に、当該関係は、境界ＩＡＢノード３００－１とＲＲＣ接続を有するドナーノードと、境界ＩＡＢノード３００－１とＲＲＣ接続を有しないドナーノードとの関係であってもよい。更に、当該関係は、境界ＩＡＢノード３００－１とＭＣＧ（Master Cell Group）接続を有するドナーノードと、境界ＩＡＢノード３００－１とＳＣＧ（Secondary Cell Group）接続を有するドナーノードとの関係であってもよい。
　図１３に示すように、ステップＳ４０において、ＩＡＢノード３００－１は、処理を開始する。
　ステップＳ４１において、ＩＡＢノード３００－１は、ドナーノードから、各トポロジのＢＡＰアドレスが設定される。当該ＢＡＰアドレスは、Ｆ１ＡＰ又はＲＲＣを利用して設定される。
　例えば、図９（Ｃ）のＩＡＢノード３００－１は、Ｆ１ＡＰ接続又はＲＲＣ接続がドナーＣＵ＃１（２００Ｃ１）との接続しかない場合、ドナーＣＵ＃２（２００Ｃ２）におけるＢＡＰアドレスは、ドナーＣＵ＃２（２００Ｃ２）からドナーＣＵ＃１（２００Ｃ１）へ通知される。そして、ドナーＣＵ＃１（２００Ｃ１）からＩＡＢノード３００－１へ、当該ＢＡＰアドレスが設定される。このような経路により、ドナーＣＵ＃２（２００Ｃ２）側のトポロジにおける当該ＢＡＰアドレス設定されてもよい。
　Ｆ１ＡＰ接続とＲＲＣ接続がともにドナーノード毎に存在する場合、ドナーＣＵ＃１（２００Ｃ１）は、自身が管理するトポロジにおけるＢＡＰアドレスを、Ｆ１ＡＰメッセージ又はＲＲＣメッセージを利用して、ＩＡＢノード３００－１に設定する。また、ドナーＣＵ＃２（２００Ｃ２）も、自身が管理するトポロジにおけるＢＡＰアドレスを、Ｆ１ＡＰメッセージ又はＲＲＣメッセージを利用して、ＩＡＢノード３００－１に設定する。
　当該ＢＡＰアドレスは、トポロジ（又はドナーノード）との対応を紐づけて設定されてもよい。例えば、第１ＢＡＰアドレスは第１トポロジ（例えば、ドナーＣＵ＃１（２００Ｃ１）が管理するトポロジ）と紐づけられて設定され、第２ＢＡＰアドレスは第２トポロジ（例えば、ドナーＣＵ＃２（２００Ｃ２）が管理するトポロジ）と紐づけられて設定されてもよい。
　ＩＡＢノード３００－１は、当該ＢＡＰアドレスをトポロジ（又はドナーノード）毎に紐づけて、バッファに記憶する。
　ステップＳ４２において、ＩＡＢノード３００－１は、ドナーノードから、トポロジと流入バックホールリンク（ｉｎｇｒｅｓｓ　ＢＨ　ｌｉｎｋ）（及び／又は流入バックホールＲＬＣチャネル（ｉｎｇｒｅｓｓ　ＢＨ　ＲＬＣ　ｃｈａｎｎｅｌ））との紐付け情報が設定される。
　例えば、第１トポロジは第１流入バックホールリンク（及び／又は第１流入バックホールＲＬＣチャネル）と紐づけられ、第２トポロジは第２流入バックホール（及び／又は第２流入バックホールＲＬＣチャネル）と紐づけられていることを示す紐付け情報が設定される。又は、第２トポロジに紐づいた第２流入バックホールリンク（及び／又は第２流入バックホールＲＬＣチャネル）についてのみ紐付け情報が設定されてもよい。Ｒｅｌ－１６では、全ての流入バックホールリンク（及び／又は流入バックホールＲＬＣチャネル）が第１トポロジに属するため、ＩＡＢノード３００－１では、紐づけ情報がなければ、第１トポロジと判定し、紐付け情報があれば第２トポロジと判定可能である。
　このように、ステップＳ４２による紐付け情報により、ＩＡＢノード３００－１は、パケットの流入元から、当該パケットが属するトポロジを特定することが可能となる。
　ステップＳ４３において、ＩＡＢノード３００－１のＢＡＰレイヤは、パケットを受信する。そして、ＢＡＰレイヤは、当該パケットの流入バックホールリンク（及び／又は流入バックホールＲＬＣチャネル）を確認する。すなわち、ＢＡＰレイヤは、当該パケットの流入バックホールリンク（及び／又は流入バックホールＲＬＣチャネル）に基づいて、当該流入バックホールリンク（及び／又は流入バックホールＲＬＣチャネル）に紐づけられたトポロジを確認する。
　第１に、ＢＡＰレイヤは、当該流入バックホールリンク（及び／又は流入バックホールＲＬＣチャネル）が第１トポロジに紐づけられていた場合、第１トポロジに紐づけられたＢＡＰアドレスを自身のＢＡＰアドレス（例えば、第１ＢＡＰアドレス）と特定する。各トポロジに紐づけられたＢＡＰアドレスは、ステップＳ４１において設定されている。
　第２に、ＢＡＰレイヤは、当該流入バックホールリンク（及び／又は流入バックホールＲＬＣチャネル）が第２トポロジに紐づけられていた場合、第２トポロジに紐づけられたＢＡＰアドレスを自身のＢＡＰアドレス（例えば、第２ＢＡＰアドレス）と特定する。
　ステップＳ４３により、ＢＡＰレイヤは、受信したパケットの流入元から、当該パケットの属するトポロジを特定し、特定したトポロジに紐づけられた（又は対応する）ＢＡＰアドレスを特定している。
　ステップＳ４４において、ＢＡＰレイヤは、当該パケットのヘッダに含まれる宛先（Ｄｅｓｔｉｎａｔｉｏｎ）を確認する。
　第１に、ＢＡＰレイヤは、当該宛先が、ステップＳ４３で特定した自身のＢＡＰアドレスと一致する場合、自身宛てのパケットと判定し、当該パケットを上位レイヤへ出力する。すなわち、当該宛先が、ステップＳ４３で特定した自身のＢＡＰアドレス（例えば、第１ＢＡＰアドレス）と一致する場合は、第１動作例と同様に、当該パケットが第１トポロジにおけるダウンストリーム方向のパケットで、自ＩＡＢノード３００－１がアクセスＩＡＢノードとなっている場合である。このような場合は、ＩＡＢノード３００－１は、配下のＵＥ１００へ当該パケットを送信するため、ＢＡＰレイヤは、当該パケットを上位レイヤへ出力する。
　第２に、ＢＡＰレイヤは、当該宛先が、ステップＳ４３で特定した自身のＢＡＰアドレスと一致しない場合、ルーティング対象と判定する。ＢＡＰレイヤの受信部は、ＢＡＰレイヤの送信部へ、ルーティング対象と判定したパケットを出力する。
　ＢＡＰレイヤは、ルーティング対象のパケットに対して以下の処理を行う。
　第１に、ＢＡＰレイヤは、当該宛先が、ステップＳ４３で特定した第２トポロジに紐づけられたＢＡＰアドレス（又はトポロジ間ルーティング用のＢＡＰアドレス）と一致する場合、当該パケットを、トポロジ間ルーティング対象のパケットと判定してもよい。すなわち、ＢＡＰレイヤは、当該パケットの宛先ＢＡＰアドレスが、特定したＢＡＰアドレス（例えば第１ＢＡＰアドレス）とは異なるトポロジ（例えば、第２トポロジ）に紐づいたＢＡＰアドレス（例えば、第２ＢＡＰアドレス）と一致する場合、当該パケットをトポロジ間ルーティング対象のパケットと判定する。ＢＡＰレイヤは、判定後、当該パケットに対して、第１動作例と同様にＢＡＰヘッダ書き替え処理を行ってもよい。若しくは、ステップＳ４４がＢＡＰレイヤの受信部で行われる場合、受信部は、当該パケットを、トポロジ間ルーティング対象として（又は当該対象である情報を付加して）、ＢＡＰレイヤの送信部へ出力してもよい。
　第２に、ＢＡＰレイヤは、当該宛先が、ステップＳ４３で特定した第２トポロジに紐づけられたＢＡＰアドレス（又はトポロジ間ルーティング用のＢＡＰアドレス）と一致しない場合、当該パケットをトポロジ内ルーティング対象と判定してもよい。ＢＡＰレイヤは、当該パケットに対して、ＢＡＰヘッダ書き替え処理を行わない。若しくは、ステップＳ４４がＢＡＰレイヤの受信部で行われる場合、受信部は、当該パケットを、トポロジ内ルーティング対象として（又は当該対象である情報を付加して）、ＢＡＰレイヤの送信部へ出力してもよい。
　ステップＳ４５において、ＢＡＰレイヤは、第１動作例と同様に、ルーティング処理とマッピング処理とを行う。ＢＡＰレイヤは、トポロジ間ルーティング対象と判定したパケットに対して、第２ルーティングテーブルと第２マッピングテーブルとを用いて、ルーティング処理とマッピング処理とを行ってもよい。また、ＢＡＰレイヤは、トポロジ間ルーティング対象と判定したパケットに対して、第１ルーティングテーブルと第１マッピングテーブルとを用いて、ルーティング処理とマッピング処理とを行ってもよい。
　ステップＳ４６において、ＩＡＢノード３００－１は、一連の処理を終了する。
（第３動作例）
　次に、第１実施形態の第３動作例について説明する。
　３ＧＰＰにおいて、ＢＡＰパケットのヘッダに、当該パケットがトポロジ間ルーティング対象のＢＡＰパケットか否かを示す識別子を含めることが提案されている。
　例えば、図９（Ｃ）において、境界ＩＡＢノード３００－１は、当該パケットを下位ノードから受信した場合、当該パケットのヘッダに含まれる当該識別子に基づいて、当該パケットはトポロジ間ルーティング対象のパケットであることを識別することができる。
　他方、当該パケットを受信したＩＡＢノード３００－３は、当該識別子に基づいて、当該パケットをトポロジ間ルーティング対象のパケットであると判定することも可能である。そのため、ＩＡＢノード３００－３では、誤った動作を行う可能性がある。
　そこで、第３動作例では、ＩＡＢノード（境界ＩＡＢノード）３００－１は、トポロジ間ルーティングを行うと、当該識別子を、トポロジ間ルーティング対象のパケットではないことを示す値（例えば、“０”）に書き替える。
　具体的には、ヘッダ書き替え処理において、ＢＡＰパケットのヘッダ情報に含まれる、トポロジ間ルーティングを示す識別子を“１”から“０”に書き替える。
　これにより、トポロジ間ルーティングが行われたパケットを受信したＩＡＢノード３００－３は、更に、当該パケットに対してトポロジ間ルーティングを行うことがなくなり、誤った動作を抑制できる。
　図１４は、第１実施形態に係るＢＡＰ　Ｄａｔａ　ＰＤＵパケットの構成例を表す図である。トポロジ間ルーティング対象のパケットであることを示す識別子は、３つのリザーブ領域（“Ｒ”）のうち、少なくともいずれかに含まれてよい。
　図１５は、第１実施形態に係る第３動作例を表す図である。
　ステップＳ５０において、境界ＩＡＢノード３００－１は、処理を開始する。
　ステップＳ５１において、境界ＩＡＢノード３００－１は、ＢＡＰパケットを受信する。
　ステップＳ５２において、境界ＩＡＢノード３００－１のＢＡＰレイヤは、当該パケットのヘッダに含まれる当該識別子を確認する。ＢＡＰレイヤは、当該識別子がトポロジ間ルーティングを行うことを示す“１”の場合、受信したパケットを、トポロジ間ルーティング対象のパケットであると判定する。なお、ＢＡＰレイヤは、当該識別子が“０”の場合、当該パケットを、トポロジ間ルーティング対象のパケットではないと判定する。以下では、当該パケットは、トポロジ間ルーティング対象のパケットであるとして説明を続ける。
　ステップＳ５３において、ＢＡＰレイヤは、当該パケットにＢＡＰヘッダ書き替え処理を行う。第１動作例等と同様に、ＢＡＰレイヤは、当該パケットのヘッダに含まれるルーティングＩＤと一致する、旧ルーティングＩＤを含むエントリがヘッダ書き替えテーブルに存在する場合、当該パケットのヘッダに含まれるルーティングＩＤを、当該エントリに含まれる新ルーティングＩＤに書き替える。そして、ＢＡＰレイヤは、当該識別子を、トポロジ間ルーティングを行うことを示す値“１”から、トポロジ間ルーティングを行わないことを示す値“０”に書き替える。又は、ＢＡＰレイヤは、当該識別子が含まれるＢＡＰヘッダの領域に“０”を書き込む。
　ステップＳ５４において、ＢＡＰレイヤは、第１動作例と同様に、ルーティング処理とマッピング処理とを行い、当該パケットを下位レイヤへ出力する。
　ステップＳ５５において、境界ＩＡＢノード３００－１は、当該パケットを次ホップノードへ送信する。
　ステップＳ５６において、境界ＩＡＢノード３００－１は、一連の処理を終了する。
（第４動作例）
　次に、第１実施形態の第４動作例について説明する。
　第１動作例では、ＢＡＰレイヤが、ルーティングテーブルを選択する際に、第１ルーティングテーブル又は第２ルーティングテーブルを選択するようにした。
　しかし、ＢＡＰレイヤは、いずれのルーティングテーブルが第１ルーティングテーブルであるのか、又は第２ルーティングテーブルであるのか識別できない場合がある。
　そこで、第４動作例では、２つのルーティングテーブルを識別する識別子を各ルーティングテーブルに含ませるようにする例である。マッピングテーブルについても、同様に、第１マッピングテーブルと第２マッピングテーブルとを識別する識別子を各マッピングテーブルに含ませる例である。
　具体的には、第１ルーティングテーブルと第２ルーティングテーブルには、第１ルーティングテーブルと第２ルーティングテーブルとを識別する第１識別情報が含まれ、第１マッピングテーブルと第２マッピングテーブルには、第１マッピングテーブルと第２マッピングテーブルとを識別する第２識別情報が含まれる。
　ここで、第１動作例において、当該パケットがトポロジ間ルーティング対象のパケットであることを識別する識別方法として、Ｍ１からＭ６を説明した。
　また、パケットの方向により、当該パケットがトポロジ間ルーティング対象のパケットであることを識別することも可能である。例えば、図９（Ｃ）において、ドナーノード間でネゴシエーションが行われないため、ドナーＣＵ＃１（２００Ｃ１）のトポロジで使用するダウンストリーム方向のルーティングＩＤと、ドナーＣＵ＃２（２００Ｃ２）のトポロジで使用するアップストリーム方向のルーティングＩＤとが同じになる場合がある。そこで、方向を示す識別子を各テーブルに含めるようにする。そして、ＩＡＢノード３００－２において、受信したパケットの方向がアップストリーム方向であることを確認できれば、トポロジ間ルーティング対象であることを把握して、当該識別子に基づいて、アップストリーム方向で使用する第２ルーティングテーブルと第２マッピングテーブルとを使用することができる。
　そこで、以下の５つの識別子を判別対象とする。
　Ｔ１：ルーティングＩＤ
　Ｔ２：パスＩＤ
　Ｔ３：ＢＡＰアドレス
　Ｔ４：トポロジ間転送か否かを示す識別子がトポロジ間転送を示すフラグ値（例えば、“１”）
　Ｔ５：アップストリーム又はダウンストリーム
　例えば、ＩＡＢノード３００－１では、ルーティングＩＤに関し、トポロジ間ルーティングを示す特定のルーティングＩＤが当該テーブルに含まれていれば、当該テーブルを第２ルーティングテーブルと判定できる。
　他方、例えば、ＩＡＢノード３００－１では、トポロジ間ルーティングを示す特定のルーティングＩＤが当該テーブルに含まれていなければ（或いは、トポロジ内ルーティングを示すルーティングＩＤが当該テーブルに含まれていれば）、当該テーブルを第１ルーティングテーブルと判定できる。
　Ｔ２からＴ４についても同様である。
　なお、Ｔ５に関しては、例えば、ＩＡＢノード３００－１は、当該パケットがアップストリーム方向のパケットである場合、アップストリーム方向であることを示す識別子を含むテーブルを、第２ルーティングテーブルと判定してもよい。また、例えば、ＩＡＢノード３００－１は、当該パケットがダウンストリーム方向のパケットである場合、ダウンストリーム方向であることを示す識別子を含むテーブルを、第１ルーティングテーブルと判定してもよい。
　図１６は、第１実施形態に係る第４動作例を表す図である。
　図１６に示すように、ステップＳ６０において、ドナーノードは、処理を開始する。
　ステップＳ６１において、ドナーノードは、ＩＡＢノード３００－１に対して、トポロジ間ルーティング用の第１ルーティングテーブルと、トポロジ内ルーティング用の第２ルーティングテーブルとを設定する。
　２つのテーブルには、各々、第１ルーティングテーブルと第２ルーティングテーブルとを識別する識別子が含まれる。
　ステップＳ６２において、ＩＡＢノード３００－１は、パケットを受信する。
　ステップＳ６３において、ＩＡＢノード３００－１のＢＡＰレイヤは、当該パケットのヘッダを確認し、適用するルーティングテーブルを判定する。例えば、ＢＡＰレイヤは、ヘッダに含まれる情報がトポロジ間ルーティングを示す特定の識別子と一致する場合、当該識別子を含むルーティングテーブルを第２ルーティングテーブルと判定する。他方、ＢＡＰレイヤは、ヘッダに含まれる情報がトポロジ間ルーティングを示す特定の識別子に該当しない場合（或いは、当該情報がトポロジ内ルーティングを示す特定の識別子に該当する場合）、当該識別子を含まないルーティングテーブルを第１ルーティングテーブルと判定する。ＢＡＰレイヤは、判定したルーティングテーブルを用いて、ルーティング処理を行う。
　そして、ステップＳ６４において、ＩＡＢノード３００－１は、一連の処理を終了する。
（第４動作例の変形例）
　第４動作例では、ルーティングテーブルについて、第１ルーティングテーブルと第２ルーティングテーブルの２つのルーティングテーブルが利用される例について説明した。例えば、３つ以上のルーティングテーブルが利用されてもよい。例えば、境界ＩＡＢノード３００－１について、３つ以上のマルチ接続（ｍｕｌｔｉ－ｃｏｎｎｅｃｔｉｖｉｔｙ）が想定されるため、各接続に１つのルーティングテーブルが利用されてもよい。
（第５動作例）
　次に、第１実施形態における第５動作例について説明する。
　上述した第４動作例では、パケットの方向に基づいて、適用するテーブルを特定する例について説明した。
　しかし、３ＧＰＰでは、パケットの方向をどのように特定するかについては議論されていない。
　そこで、第５動作例では、受信したパケットがダウンストリーム方向であるのか、受信したパケットがアップストリーム方向であるのか、その方向を特定する動作例について説明する。
　具体的には、第１に、受信部（例えば、ＢＡＰレイヤの受信部）が、受信したＢＡＰパケットの方向についてダウンストリーム方向かアップストリーム方向かを特定する。第２に、ＢＡＰパケットの方向毎に第１ルーティングテーブル及び第２ルーティングテーブルが存在する場合、送信部が、特定した方向に対応する第１ルーティングテーブル又は第２ルーティングテーブルを選択する。
　これにより、例えば、ＩＡＢノード３００－１では、特定した方向に対応するルーティングテーブルを用いて、受信したパケットを適切に転送することが可能となる。
　図１７は、第１実施形態に係る第５動作例を表す図である。
　図１７に示すように、ステップＳ７０において、ＩＡＢノード３００は、処理を開始する。
　ステップＳ７１において、ＩＡＢノード３００は、パケットを受信する。
　ステップＳ７２において、ＩＡＢノード３００のＢＡＰレイヤは、当該パケットの方向を特定する。例えば、ＢＡＰレイヤは、以下のようにして当該パケットの方向を特定してもよい。
　すなわち、ＢＡＰレイヤは、ＩＡＢノード３００の子ノード（に対応するバックホールリンク）から当該パケットを受信した場合は、アップストリーム方向であると特定する。また、ＢＡＰレイヤは、ＵＥ１００（に対応するアクセスリンク）から当該パケットを受信した場合も、アップストリーム方向であると特定する。他方、ＢＡＰレイヤは、ＩＡＢノード３００の親ノード（に対応するバックホールリンク）から当該パケットを受信した場合、ダウンストリーム方向であると特定する。また、ＢＡＰレイヤは、ＩＡＢノード３００のＩＡＢ－ＤＵにおいて当該パケットを受信した場合、アップストリーム方向であると特定する。また、ＢＡＰレイヤは、ＩＡＢノード３００のＩＡＢ－ＭＴにおいて当該パケットを受信した場合、ダウンストリーム方向であると特定する。
　ステップＳ７３において、ＢＡＰレイヤは、特定したパケットの方向を用いて、所定の処理を行う。当該所定の処理は、以下のいずれかの処理である。
　第１に、ルーティングテーブルがパケットの方向毎に２つ存在する場合、ＢＡＰレイヤは、特定した方向に対応するルーティングテーブルを選択する。すなわち、特定したパケットの方向がアップストリーム方向の場合は、ＢＡＰレイヤは、アップストリーム方向に対応する、第１ルーティングテーブル又は第２ルーティングテーブルを選択する。他方、特定したパケットの方向がダウンストリーム方向の場合は、ＢＡＰレイヤは、ダウンストリーム方向に対応する、第１ルーティングテーブル又は第２ルーティングテーブルを選択する。そして、ＢＡＰレイヤは、選択したルーティングテーブルを用いて、ルーティング処理を行う。
　第２に、ルーティングテーブルがパケットの方向毎に存在せずに、ルーティングテーブル内のエントリの中でパケットの方向が指定されている場合、ＢＡＰレイヤは、特定した方向に対応するエントリを対象としてルーティング処理を行う。例えば、第１ルーティングテーブルと第２ルーティングテーブルが存在し、第１ルーティングテーブル内のエントリでパケットの方向が指定され、第２ルーティングテーブル内のエントリでパケットの方向が指定されていると仮定する。この場合、ＢＡＰレイヤは、第１ルーティングテーブル又は第２ルーティングテーブル内における、特定した方向（アップストリーム方向又はダウンストリーム方向）に対応するエントリを用いて、ルーティング処理を行う。
　ステップＳ７４において、ＩＡＢノード３００は、当該パケットを、次ホップノードへ送信する。
　そして、ステップＳ７５において、ＩＡＢノード３００は、一連の処理を終了する。
（第５動作例の変形例）
　第５動作例では、ルーティング処理を行う例について説明した。第５動作例は、マッピング処理に適用してもよい。
　すなわち、ＢＡＰレイヤは、第５動作例と同様に、受信したパケットの方向を特定する。そして、マッピングテーブルがパケットの方向毎に２つ存在する場合は、ＢＡＰレイヤは、特定した方向に対応する、第１マッピングテーブル又は第２マッピングテーブルを選択し、選択したマッピングテーブルを用いてマッピング処理を行う。また、マッピングテーブルがパケット毎に存在しないで、マッピングテーブル内のエントリの中でパケットの方向が指定されている場合は、ＢＡＰレイヤは、第１マッピングテーブル又は第２マッピングテーブルにおける、当該方向に対応するエントリを用いてマッピング処理を行う。
（第６動作例）
　第３動作例では、トポロジ間ルーティング対象であることを示す識別子について説明した。
　第６動作例では、ドナーＤＵ又はアクセスＩＡＢノードがどのようにして当該識別子をパケットのヘッダに書き込むのかについて説明する。
　具体的には、第１に、ドナーノード（例えば、ドナー２００）のＣＵが、ドナーノードのＤＵ又はアクセスＩＡＢノードに対して、ルーティングＩＤと紐づけて、トポロジ間ルーティングを示す識別子への書き込みを行うか否かの設定を行う。第２に、ドナーノードのＤＵ又はアクセスＩＡＢノードが、設定に従って、ルーティングＩＤと識別子とを含むＢＡＰヘッダを付与したＢＡＰパケットを、次ホップノードへ送信する。
　これにより、例えば、ドナーノード２００のＤＵとアクセスＩＡＢノードは、ＢＡＰヘッダに当該識別子を適切に書き込みことが可能となる。
　図１８は、第１実施形態に係る第６動作例を表す図である。
　図１８に示すように、ステップＳ８０において、ドナーノード２００は、処理を開始する。
　ステップＳ８１において、ドナーノード２００のＣＵは、ドナーノード２００のＤＵ又はアクセスＩＡＢノードに対して、ルーティングＩＤと紐づいて、トポロジ間ルーティングを示す識別子への書き込みを行うか否かの設定を行う。
　第１に、アクセスＩＡＢノードへの設定については、Ｆ１ＡＰを利用して設定される。すなわち、ドナーノード２００は、アクセスＩＡＢノードに対して、「Ｕｐｌｉｎｋ　Ｔｒａｆｆｉｃ　ｔｏ　Ｒｏｕｔｉｎｇ　ＩＤ　Ｍａｐｐｉｎｇ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ」を、送信することで設定を行う。当該マッピング設定には、以下のＩＥが含まれる。
　Ｕ１：トラフィックタイプ指定子（Ｔｒａｆｆｉｃ　ｔｙｐｅ　ｓｐｅｃｉｆｉｅｒ）
　Ｕ２：ルーティングＩＤ
　Ｕ３：トポロジ間ルーティングを示す識別子を書き込みか否かの情報
　ここで、上記Ｕ３に関し、当該ＩＥが当該マッピング設定に含まれる場合に、当該識別子をＢＡＰヘッダに書き込むとし、当該ＩＥが当該マッピング設定に含まれてない場合に、当該識別子をＢＡＰヘッダに書き込まない、としてもよい。また、上記Ｕ３に関し、当該情報が“１”の場合に当該識別子をＢＡＰヘッダに書き込むとし、当該情報が“０”の場合に当該識別子をＢＡＰヘッダに書き込まない、としてもよい。“１”と“０”は逆でもよい。更に、当該情報が“Ｔｒｕｅ”又は“Ｆａｌｓｅ”により示されてもよい。また、当該情報が“Ｙｅｓ”又は“Ｎｏ”で示されてもよい。
　第２に、ドナーノード２００のＤＵへの設定については、所定のＩＥ（「ＩＰ－ｔｏ－ｌａｙｅｒ－２　ｔｒａｆｆｉｃ　ｍａｐｐｉｎｇ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｌｉｓｔ　ＩＥ」）を利用して、設定される。すなわち、ドナーノード２００のＣＵは、ドナーノード２００のＤＵに対して、「Ｄｏｗｎｌｉｎｋ　Ｔｒａｆｆｉｃ　ｔｏ　Ｒｏｕｔｉｎｇ　ＩＤ　Ｍａｐｐｉｎｇ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ」を出力することで設定を行う。当該マッピング設定には、以下のＩＥが含まれる。
　Ｄ１：宛先ＩＰアドレス（Ｄｅｓｔｉｎａｔｉｏｎ　ＩＰ　Ａｄｄｒｅｓｓ）
　Ｄ２：ＩＰｖ６フローレベル（ＩＰｖ６　ｆｌｏｗ　ｌａｂｅｌ）
　Ｄ３：ＤＳＣＰ（Differentiated Services Code Point）
　Ｄ４：ルーティングＩＤ
　Ｄ５：トポロジ間ルーティングを示す識別子を書き込みか否かの情報
　当該マッピング設定においても、アクセスＩＡＢノードへの設定と同様に、Ｄ５が含まれる。Ｄ５は、Ｕ３と同様に、当該ＩＥが当該マッピング設定に含まれる場合に、当該識別子をＢＡＰヘッダに書き込むとし（又は書き込みが指定されているとし）、当該ＩＥが当該マッピング設定に含まれない場合に、当該識別子をＢＡＰヘッダに書き込まない（又は書き込みが指定されていない）、としてもよい。当該情報が“１”の場合に当該識別子をＢＡＰヘッダに書き込むとし、当該情報が“０”の場合に当該識別子をＢＡＰヘッダに書き込まない、としてもよい。“１”と“０”は逆でもよい。当該情報が“Ｔｒｕｅ”又は“Ｆａｌｓｅ”により示されてもよい。また、当該情報が“Ｙｅｓ”又は“Ｎｏ”で示されてもよい。
　なお、以下では、アクセスＩＡＢノードにおける動作例について説明する。
　ステップＳ８２において、アクセスＩＡＢノードのＢＡＰレイヤは、上位レイヤから、ＢＡＰパケット（ＢＡＰ　ＳＤＵ）を受信する。
　第１に、ＢＡＰレイヤは、当該パケットに対応するトラフィック指定子を含むエントリを、当該マッピング設定（「Ｕｐｌｉｎｋ　Ｔｒａｆｆｉｃ　ｔｏ　Ｒｏｕｔｉｎｇ　ＩＤ　Ｍａｐｐｉｎｇ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ」）から選択する。
　第２に、ＢＡＰレイヤは、選択したエントリ内のルーティングＩＤを、ＢＡＰヘッダへ書き込むルーティングＩＤとする。
　そして、第３に、ＢＡＰレイヤは、選択したエントリ内において、トポロジ間ルーティングを示す識別子への書き込みが指定されていた場合、ＢＡＰヘッダにおける当該識別子を“１”とする。他方、選択したエントリ内において、当該識別子への書き込みが指定されていなかった場合、ＢＡＰレイヤは、当該識別子を“０”とする。
　第４に、ＢＡＰレイヤは、ルーティングＩＤと当該識別子とを含むＢＡＰヘッダを、当該パケット（ＢＡＰ　ＳＤＵ）に付加して、ＢＡＰ　ＰＤＵを生成する。
　ステップＳ８３において、アクセスＩＡＢノードのＢＡＰレイヤは、当該ＢＡＰ　ＰＤＵに対して、ルーティング処理とマッピング処理とを行い、次ホップのノードへ送信する。
　そして、ステップＳ８４において、アクセスＩＡＢノードのＢＡＰレイヤは、一連の処理を終了する。
　ここで、ステップＳ８２とステップＳ８３について、ドナーノード２００のＤＵが処理を行う場合、ステップＳ８２とステップＳ８３における「アクセスＩＡＢノード」を「ドナーノード２００のＤＵ」と置き換え、マッピング設定を「Ｄｏｗｎｌｉｎｋ　Ｔｒａｆｆｉｃ　ｔｏ　Ｒｏｕｔｉｎｇ　ＩＤ　Ｍａｐｐｉｎｇ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ」とすればよい。
　以上、トポロジ間ルーティングのシナリオ（Ｓ３－１）に関する第１実施形態について説明した。次に、トポロジ間リルーティングのシナリオ（Ｓ３－２）について説明する。
［第２実施形態］
　次に、第２実施形態について説明する。
　第２実施形態では、トポロジ間リルーティングについて説明する。
　３ＧＰＰにおいては、トポロジ間リルーティングをサポートすることが合意されている。トポロジ間リルーティングは、ＩＡＢノードが、ターゲットドナーノードのＣＵのトポロジ上の代替パスを介して、オリジナルドナーノード（又はソースドナーノード）のＣＵへパケットをリルーティングすることである。
　トポロジ間リルーティングに関し、３ＧＰＰでは、ＩＡＢノードが、新たなドナーＣＵでのＲＲＣ再確立（ＲＲＣ　Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）を介して、ＢＨ　ＲＬＦからの回復を実行する場合、元のドナーノードとの進行中のＦ１接続を維持し、回復されたパスを介してリルーティングが行われてもよい、ことが合意されている。
　つまり、ＩＡＢノードにおけるトポロジ間リルーティングは、ソースドナーノードとのＦ１接続を残したまま、ターゲットドナーノードに対してはＲＲＣ再確立の状態で適用される可能性がある。言い換えると、ＩＡＢノードでは、２つのドナーノードとの二重接続（ＤＣ：Dual Connectivity）の状態ではなく、ターゲットドナーノードとのＦ１接続が未確立である過渡状態で、トポロジ間リルーティングが適用される可能性がある。
　このような過渡状態において、ＩＡＢノードがＲｅｌ－１６のローカルリルーティングの手順を用いてトポロジ間リルーティングを実行しても、実行できない場合がある。
　すなわち、Ｒｅｌ－１６のローカルリルーティングの手順では、ＢＡＰパケットのＢＡＰヘッダに含まれる宛先（Ｄｅｓｔｉｎａｔｉｏｎ）と一致するルーティングＩＤをルーティングテーブルから選択して、当該パケットを転送する。
　しかし、ソースドナーノードのルーティングテーブルには、ターゲットドナーノードへのルーティングＩＤ（或いは、宛先（Ｄｅｓｔｉｎａｔｉｏｎ）がターゲットドナーノードのＤＵのＢＡＰアドレス）は存在しない。２つのドナーノードは、トポロジが異なり、各ドナーノードのＣＵで各トポロジのＢＡＰアドレスなどを管理するからである。
　そのため、ソースドナーノードのＣＵが、ＩＡＢノードへ当該ルーティングテーブルを設定しても、ＩＡＢノードは、ターゲットドナーノードへ当該パケットを転送できない。
　仮に、ＩＡＢノードがターゲットドナーノードへ当該パケットを転送できても、ターゲットドナーノードは、当該パケットが自身宛てなのか、ソースドナーノード宛てなのか、把握できない場合がある。
　そこで、第２実施形態では、ターゲットドナーノードがトポロジ間リルーティング用の通信路をＩＡＢノードに設定し、ＩＡＢノード３００は、当該通信路を介して、パケットを転送する。
　具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００）が、第１ドナーノード（例えば、ソースドナーノード）との接続又は第１上位ノードとの接続において、バックホールの無線リンク障害を検出する。第２に、中継ノードが、第２ドナーノード（例えば、ターゲットドナーノード）又は第２上位ノードに対して、ＲＲＣ再確立を実施した際に、第１ドナーノードとの通信を継続することを示す情報を通知する。ここで、第１上位ノードは、第１ドナーノードが管理するノードであって、中継ノードの上位ノードである。また、第２上位ノードは、第２ドナーノードが管理するノードであって、中継ノードの上位ノードである。
　これにより、例えば、ターゲットドナーノードでは、ＩＡＢノードとソースドナーノードとの間で通信が継続されることを把握でき、この通知をトリガにして、トポロジ間リルーティング用の通信路の設定を、ＩＡＢノードに対して行うことが可能となる。そして、上述した過渡状態においても、ＩＡＢノードは、当該通信路を利用して、受信したパケットを適切に転送することが可能となる。
　図１９（Ａ）と図１９（Ｂ）は、第２実施形態に係るトポロジの構成例を表す図である。
　図１９（Ａ）では、ＩＡＢノード３００とドナーノードＡ（２００－Ａ）との間のバックホールリンクでＢＨ　ＲＬＦが発生している例を表している。また、図１９（Ｂ）では、ＩＡＢノード３００と上位ノード３００－Ｐ１との間のバックホールリンクでＢＨ　ＲＬＦが発生している例を表している。図１９（Ｂ）において、ＩＡＢノード３００－Ｐ１は、ドナーノードＡ（２００－Ａ）が管理するノードである。また、ＩＡＢノード３００－Ｐ２は、ドナーノードＢ（２００－Ｂ）が管理するノードである。
　図２０は、第２実施形態に係る動作例を表す図である。図２０に示す動作例は、図１９（Ａ）と図１９（Ｂ）に示す構成例を適宜参照しながら説明する。
　図２０に示すように、ステップＳ９０において、ＩＡＢノード３００は、処理を開始する。
　ステップＳ９１において、バックホールリンクにおいてＢＨ　ＲＬＦが発生する。例えば、図１９（Ａ）の例では、ＩＡＢノード３００のＩＡＢ－ＭＴが、ドナーノードＡ（２００－Ａ）との間のバックホールリンクでのＢＨ　ＲＬＦを検出する。また、図１９（Ｂ）の例では、ＩＡＢノード３００のＩＡＢ－ＭＴが、ＩＡＢノード３００－Ｐ１との間のＢＨ　ＲＬＦを検出する。
　図２０に戻り、ステップＳ９２において、ＩＡＢノード３００は、セル選択により、ドナーノードＢ（２００－Ｂ）を選択する。ＩＡＢノード３００は、セル選択により、ドナーノードＢ（２００－Ｂ）が管理するＩＡＢノード３００－Ｐ２を選択してもよい。
　ステップＳ９３において、ＩＡＢノード３００は、ドナーノードＢ（２００－Ｂ）に対して、ＲＲＣ再確立（ＲＲＣ　Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）手順を実行する。例えば、以下の手順が実行される。
　第１に、ＩＡＢノード３００は、ドナーノードＢ（２００－Ｂ）に対して、ＲＲＣ再確立要求（ＲＲＣ　Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｒｅｑｕｅｓｔ）メッセージを送信する。ＩＡＢノード３００は、ＩＡＢノード３００－Ｐ２を介してドナーノードＢ（２００－Ｂ）に対して、当該メッセージを送信してもよい。
　この際、ＩＡＢノード３００は、当該メッセージにおいて、ドナーノードＡ（２００－Ａ）との通信を継続することを示す情報（又は要求）をドナーノードＢ（２００－Ｂ）へ通知してもよい。若しくは、ＩＡＢノード３００は、当該メッセージにおいて、自ＩＡＢノード３００がトポロジ間リルーティングの能力を有していることを示す情報をドナーノードＢ（２００－Ｂ）へ通知してもよい。若しくは、ＩＡＢノード３００は、当該メッセージにおいて、ドナーノードＡ（２００－Ａ）とのＦ１接続が残っていることを示す情報をドナーノードＢ（２００－Ｂ）へ通知してもよい。或いは、ＩＡＢノード３００は、当該メッセージにおいてドナーノードＡ（２００－Ａ）との通信路の確立要求をドナーノードＢ（２００－Ｂ）へ通知してもよい。
　なお、当該通知は、後のＲＲＣ再確立完了（ＲＲＣ　Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｃｏｍｐｌｅｔｅ）、又は、更に後のＵＥアシスタンス情報（ＵＥ　Ａｓｓｉｓｔａｎｖｅ　Ｉｎｆｏｒｍａｔｉｏｎ）の各メッセージにおいて行われてもよい。
　第２に、ドナーノードＢ（２００－Ｂ）は、ＲＲＣ再確立要求を受け入れ、ＩＡＢノード３００へ、ＲＲＣ再確立（ＲＲＣ　Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）メッセージを送信する。
　第３に、ＩＡＢノード３００は、当該ＲＲＣ再確立メッセージの受信に応じて、ＲＲＣ再確立完了（ＲＲＣ　Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｃｏｍｐｌｅｔｅ）メッセージを、ドナーノードＢ（２００－Ｂ）へ送信する。
　以上により、ＩＡＢノード３００とドナーノードＢ（２００－Ｂ）との間でＲＲＣ接続が確立される。
　ステップＳ９４において、ドナーノードＢ（２００－Ｂ）は、ドナーノードＡ（２００－Ａ）との間で通信路（ＧＴＰ（GPRS(General Packet Radio System) Tunnelling Protocol））を確立する。ドナーノードＢ（２００－Ｂ）が当該通信路を利用して、ＩＡＢノード３００においてトポロジ間ルーティングされたアップストリーム方向のパケットをドナーノードＡ（２００－Ａ）へ送信するためである。加えて、ドナーノードＡ（２００－Ａ）も、ドナーノードＢ（２００－Ｂ）との間で通信路（ＧＴＰ）を確立する。ドナーノードＡ（２００－Ａ）が、ドナーノードＢ（２００－Ｂ）へ、ダウンストリーム方向のパケットを送信するためである。
　例えば、ドナーノードＢ（２００－Ｂ）が、通信路確立要求メッセージをドナーノードＡ（２００－Ａ）へ送信する。そして、ドナーノードＡ（２００－Ａ）が、当該メッセージの受信に応じて、肯定応答メッセージをドナーノードＢ（２００－Ｂ）へ送信する。これにより、当該通信路が確立されてもよい。当該要求メッセージには、ＩＡＢノード３００の識別子、ダウンストリームパケット受信用のＧＴＰ　ＴＥＩＤ（Tunnel Endpoint Identifier）、及びＩＰアドレスが含まれてもよい。当該肯定応答メッセージには、アップストリームパケット受信用のＧＴＰ　ＴＥＩＤ、及びＩＰアドレスが含まれてもよい。
　なお、ＧＴＰ通信路の確立は、ドナーノードＢ（２００－Ｂ）がＩＡＢノード３００へ、ＲＲＣ再確立（ＲＲＣ　Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）メッセージを送信する前に行われてもよい。
　ステップＳ９５において、ドナーノードＢ（２００－Ｂ）は、ＩＡＢノード３００に対して、トポロジ間リルーティング用の通信路を設定する。すなわち、第２ドナーノード（例えば、ドナーノードＢ（２００－Ｂ））が、中継ノード（例えば、ＩＡＢノード３００）に対して、トポロジ間リルーティング用の通信路を設定する。
　ドナーノードＢ（２００－Ｂ）は、ステップＳ９３で確立したＲＲＣ接続を利用して、ＩＡＢノード３００に対して通信路の設定を行う。具体的には、ドナーノードＢ（２００－Ｂ）のＣＵは、ＩＡＢノード３００のＩＡＢ－ＭＴへ、ＲＲＣ再設定（ＲＲＣ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージを送信することで、通信路の設定を行う。当該メッセージには、トポロジ間リルーティング用の（テンポラリな）バックホールＲＬＣチャネル（ＢＨ　ＲＬＣ　ｃｈａｎｎｅｌ）を確立するための設定を含む。
　第１に、当該設定には、トポロジ間リルーティング用の（テンポラリな）ルーティングテーブルが含まれてもよい。当該ルーティングテーブルには、ルーティングＩＤ、次ホップＢＡＰアドレス（Ｎｅｘｔ　Ｈｏｐ　ＢＡＰ　Ａｄｄｒｅｓｓ）が含まれてもよい。
　第２に、当該設定には、トポロジ間リルーティング用の（テンポラリな）マッピングテーブルが含まれてもよい。当該マッピングテーブルには、流入バックホールＲＬＣチャネル（ｉｎｇｒｅｓｓ　ＢＨ　ＲＬＣ　ｃｈａｎｎｅｌ）、流出バックホールＲＬＣチャネル（ｅｇｒｅｓｓ　ＢＨ　ＲＬＣ　ｃｈａｎｎｅｌ）、流入バックホールリンク（ｉｎｇｒｅｓｓ　ＢＨ　ｌｉｎｋ）、及び流出バックホールリンク（ｅｇｒｅｓｓ　ＢＨ　ｌｉｎｋ）が含まれてもよい。
　第３に、当該設定には、ＩＡＢノード３００のＢＡＰアドレスが含まれてもよい。当該ＢＡＰアドレスは、ドナーノードＢ（２００－Ｂ）が管理するＩＡＢノード３００に対するＢＡＰアドレスである。
　第４に、当該設定には、ドナーノードＢ（２００－Ｂ）のＤＵのＢＡＰアドレスが含まれてもよい。
　第５に、当該設定には、ＢＡＰヘッダ書き替えテーブルが含まれてもよい。
　ＩＡＢノード３００のＲＲＣレイヤは、当該設定を受信すると、当該設定を、ＩＡＢノード３００のＢＡＰレイヤへ出力する。ＢＡＰレイヤは、当該設定を、ルーティングテーブル及び／又はマッピングテーブルとして取り扱ってもよい。
　ステップＳ９６において、ＩＡＢノード３００のＢＡＰレイヤは、当該設定に従い、トポロジ間リルーティング処理を行う。例えば、ＩＡＢノードのＢＡＰレイヤは、以下の処理を行う。
　第１に、ＢＡＰレイヤは、滞留しているドナーノードＡ（２００－Ａ）宛てのパケットのＢＡＰヘッダを、当該設定に従い、ドナーノードＢ（２００－Ｂ）のＤＵ向けのルーティングＩＤに書き替える。
　第２に、ＢＡＰレイヤは、当該設定に従い、当該ルーティングＩＤから次ホップＢＡＰアドレス（又は次ホップＢＡＰアドレスに対応する流出バックホールリンク）を特定する。この場合、ＢＡＰレイヤは、当該設定によるトポロジ間リルーティング用のルーティングテーブルを利用してもよい。例えば、ＢＡＰレイヤは、当該ルーティングＩＤと一致するエントリを、トポロジ間リルーティング用のルーティングテーブルから読み出し、当該エントリの次ホップＢＡＰアドレスに対応する流出バックホールリンクを特定してもよい。
　第３に、ＢＡＰレイヤは、当該設定から流出バックホールＲＬＣチャネルを特定する。この場合、ＢＡＰレイヤは、当該設定によるトポロジ間リルーティング用のマッピングテーブルを利用してもよい。例えば、ＢＡＰレイヤは、当該パケットの流入バックホールＲＬＣチャネル、流入バックホール、特定した流出バックホールリンクと一致するエントリを読み出し、当該エントリに含まれる流出バックホールＲＬＣチャネルを特定してもよい。
　第４に、ＢＡＰレイヤは、特定した流出バックホールリンクの特定した流出バックホールＲＬＣチャネルへ、滞留している当該パケットを出力する。
　なお、上記流出バックホールリンクの特定と、上記流出バックホールＲＬＣチャネルの特定とに関し、例えば、以下のように処理が行われてもよい。すなわち、ＢＡＰレイヤは、ＩＡＢノード３００に滞留する送信待ちのパケットについて、当該パケットのヘッダに含まれるルーティングＩＤと一致するエントリがルーティングテーブルに無く、かつ、当該パケットのヘッダに含まれる宛先と一致するエントリがルーティングテーブルに無い場合、当該設定で設定されたバックホールＲＬＣチャネルを送信先として選択し、選択したバックホールＲＬＣチャネルを介して、滞留パケットを送信する。つまり、ＢＡＰレイヤは、このような場合に、トポロジ間リルーティング用の通信路へ滞留パケットを送信する。
　また、ＩＡＢノード３００のＢＡＰレイヤは、当該設定に従い、流入バックホールリンクと流入バックホールＲＬＣチャネルから、ドナーノードＡ（２００－Ａ）が送信したダウンリンク方向のパケットを、ドナーノードＢ（２００－Ｂ）を介して受信してもよい。
　ステップＳ９７において、ドナーノードＡ（２００－Ａ）又はＩＡＢノード３００は、ドナーノードＡ（２００－Ａ）とＩＡＢノード３００との間のＦ１接続が解放された場合、Ｆ１通信が完了したことを示す情報（例えば、前記通信路の破棄要求）を、ドナーノードＢ（２００－Ｂ）へ通知する。
　例えば、ドナーノードＡ（２００－Ａ）が、ドナーノードＢ（２００－Ｂ）とＩＡＢノード３００間のトポロジ間リルーティング用の通信の破棄要求を、ドナーノードＢ（２００－Ｂ）へ送信する。そして、ドナーノードＢ（２００－Ｂ）は、当該破棄要求に対する肯定応答をドナーノードＡ（２００－Ａ）へ返送することで、当該通知と当該通信の破棄とを同時に実行することも可能である。若しくは、ＩＡＢノードのＦ１レイヤが、Ｆ１セットアップ要求をドナーノードＢ（２００－Ｂ）へ送信することで、暗示的に、当該Ｆ１接続が解放されたことを通知してもよい。
　ステップＳ９８において、ドナーノードＢ（２００－Ｂ）は、ＩＡＢノード３００から、ステップＳ９５で設定した、トポロジ間リルーティング用のバックホールＲＬＣチャネル設定（又はトポロジ間リルーティング用の通信路の設定）を取り除く。すなわち、中継ノード（例えば、ＩＡＢノード３００）は、第１ドナーノード（例えば、ドナーノードＡ（２００－Ａ））とのＦ１接続又は第１上位ノード（例えば、ＩＡＢノード３００－Ｐ１）とのＦ１接続が解放された場合、トポロジ間リルーティング用の通信路の設定を破棄する。
　例えば、ドナーノードＢ（２００－Ｂ）は、ＩＡＢノード３００に対して、当該設定を取り除くよう指示を行ってもよい。また、ＩＡＢノード３００が自動的に当該設定を取り除いてもよい。後者の場合、ＩＡＢノード３００は、ステップＳ９７におけるＦ１通信完了の通知をトリガにして、当該設定を取り除いてもよい。
　ステップＳ９９において、ドナーノードＢ（２００－Ｂ）は、一連の処理を終了する。
（第２実施形態の変形例）
　第２実施形態では、ＩＡＢノード３００は、ドナーノードＢ（２００－Ｂ）に対してＲＲＣ接続を再確立し、ドナーノードＢ（２００－Ｂ）は、ＲＲＣメッセージを利用して、ＩＡＢノード３００に対して、トポロジ間リルーティング用の通信路の設定を行った。
　第２実施形態の変形例では、ＲＲＣに代えて、Ｆ１を利用して、当該通信路の設定を行う例である。具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００）が、第１ドナーノード（例えば、ドナーノードＡ（２００－Ａ））との接続又は第１上位ノード（例えば、ＩＡＢノード３００－Ｐ１）との接続において、ＢＨ　ＲＬＦを検出する。第２に、中継ノードが、第２ドナーノード（例えば、ドナーノードＢ（２００－Ｂ））又は第２上位ノード（例えば、ＩＡＢノード３００－Ｐ２）に対して、Ｆ１セットアップを実施した際に、第１ドナーノードとの通信を継続することを示す情報を通知する。ここで、第１上位ノードは、第１ドナーノードが管理するノードであって、中継ノードの上位ノードである。また、第２上位ノードは、第２ドナーノードが管理するノードであって、中継ノードの上位ノードである。
　これにより、例えば、ターゲットドナーノードでは、ＩＡＢノードとソースドナーノードとの間で通信が継続されることを把握でき、この通知をトリガにして、トポロジ間リルーティング用の通信路の設定を、Ｆ１ＡＰメッセージを利用して、ＩＡＢノードに対して行うことが可能となる。そして、当該通信路の設定により、ＩＡＢノードは、トポロジ間リルーティングを適切に行うことが可能となる。
　図２１は、第２実施形態に係る変形例を表す図である。
　図２１に示すように、ステップＳ１００において、ＩＡＢノード３００は処理を開始する。
　ステップＳ１０１とステップＳ１０２は、第２実施形態のステップＳ９１とステップＳ９２とそれぞれ同じである。
　ステップＳ１０３において、ＩＡＢノード３００は、ドナーノードＢ（２００－Ｂ）との間で、ＲＲＣ再確立手順を実行して、ドナーノードＢ（２００－Ｂ）との間でＲＲＣ接続を再確立する。その後、ＩＡＢノード３００は、Ｆ１セットアップ手順を実行して、ドナーノードＢ（２００－Ｂ）との間でＦ１接続を確立する。
　なお、Ｆ１セットアップ手順は、ＩＡＢノード３００のＩＡＢ－ＤＵとドナーノードＢ（２００－Ｂ）のＣＵとの間で行われる。Ｆ１セットアップ手順は、例えば、以下のようして行われる。
　第１に、ＩＡＢノード３００は、ドナーノードＢ（２００－Ｂ）へ、Ｆ１セットアップ要求（Ｆ１　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔ）メッセージを送信する。この際に、ＩＡＢノード３００は、第２実施形態と同様に、当該メッセージにおいて、ドナーノードＡ（２００－Ａ）との通信を継続することを示す情報を通知する。又は、ＩＡＢノード３００は、第２実施形態と同様に、トポロジ間リルーティングの能力を有していることを示す情報を通知してもよいし、ドナーノードＡ（２００－Ａ）とのＦ１接続が残っていることを示す情報を通知してもよい。なお、当該通知は、後のＦ１セットアップ応答（Ｆ１　Ｓｅｔｕｐ　Ｒｅｓｐｏｎｓｅ）メッセージ、又は、更に後のＵＥアシスタンス情報メッセージにおいて行われてもよい。
　第２に、ドナーノードＢ（２００－Ｂ）は、当該要求を受け入れて、ＩＡＢノード３００へ、Ｆ１セットアップ応答メッセージを送信する。
　これにより、ＩＡＢノード３００とドナーノードＢ（２００－Ｂ）との間でＦ１接続が確立する。
　ステップＳ１０４は、第２実施形態のステップＳ９４と同じである。
　ステップＳ１０５において、ドナーノードＢ（２００－Ｂ）は、ＩＡＢノード３００に対して、トポロジ間リルーティング用の（テンポラリな）通信路を設定する。当該設定は、Ｆ１再設定更新（Ｆ１　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　Ｕｐｄａｔｅ）メッセージを用いて行われる。設定内容は、第２実施形態と同じである。当該設定には、第２実施形態と同様に、トポロジ間リルーティング用の（テンポラリな）バックホールＲＬＣチャネルを確立するための設定が含まれる。ＩＡＢノード３００のＦ１ＡＰレイヤは、当該設定を受信すると、当該設定をＩＡＢノード３００のＢＡＰレイヤへ出力する。ＢＡＰレイヤは、第２実施形態と同様に、当該設定を、ルーティングテーブル及び／又はマッピングテーブルとして扱ってもよい。
　なお、当該設定は、Ｆ１セットアップ応答メッセージを用いて行われてもよい。
　ステップＳ１０６において、ＩＡＢノード３００のＢＡＰレイヤは、当該設定に従い、トポロジ間リルーティング処理を行う。トポロジ間リルーティング処理自体は、第２実施形態と同様である。
　ステップＳ１０７とステップＳ１０８は、第２実施形態のステップＳ９７とステップＳ９８とそれぞれ同じである。
　そして、ステップＳ１０９において、ドナーノードＢ（２００－Ｂ）は、一連の処理を終了する。
　以上、トポロジ間リルーティングのシナリオ（Ｓ３－２）に関する第２実施形態について説明した。次に、ドナーＤＵ間リルーティングのシナリオ（Ｓ２－２）について説明する。
［第３実施形態］
　次に、第３実施形態について説明する。
　第３実施形態は、ドナーＤＵ間リルーティングについて説明する。
　例えば、図９（Ｂ）に示すトポロジ構成例の場合、ドナーノードのＤＵが複数存在する。そのため、ドナーノードのＤＵのＢＡＰアドレスも複数存在する。図９（Ｂ）の例では、ドナーノードＤＵ＃１（２００Ｄ１）のＢＡＰアドレスと、ドナーノードＤＵ＃２（２００Ｄ２）のＢＡＰアドレスの２つが存在する。
　ここで、ダウンストリーム方向のパケットに関し、発信元（ドナーノードのＤＵ）は、ＩＡＢノード３００－１におけるルーティング処理に関与しない。また、ダウンストリーム方向のパケットに関し、宛先（アクセスＩＡＢノード）は、ルーティング処理を行っても変わらない。そのため、ダウンストリーム方向のドナーＤＵ間リルーティングは、とくに問題は生じないことが予想される。
　一方、アップストリーム方向に関し、ドナーＤＵ間リルーティングを行うと、宛先（ドナーノードのＤＵ）が変わる。つまり、各パケットについて、宛先ＢＡＰアドレスが変更となる。このため、ＩＡＢノード３００－１では、ＢＡＰヘッダ書き替え処理が行われる場合がある。３ＧＰＰでは、ＢＡＰヘッダ書き替え処理として、「“ｐｒｅｖｉｏｕｓ　ｒｏｕｔｉｎｇ　ＩＤ　ｔｏ　ｎｅｗ　ｒｏｕｔｉｎｇ　ＩＤ”　ＢＡＰ　ｒｅｗｒｉｔｉｎｇ」が合意された。
　ここで、本シナリオでは、２つの課題がある。
　第１に、リルーティングは、ルーティングとは異なり、一旦、ルーティング処理を行い、行先のないパケットに対して、再度ルーティング処理を行うことが原則である。そのため、ＢＡＰヘッダ書き替え処理を行うタイミングを考慮する必要がある。
　第２に、ＩＡＢノード３００－１が受信したパケットの宛先（Ｄｅｓｔｉｎａｔｉｏｎ）と一致するルートを適当に選択するのか、或いは、ドナーノードによって、代替パスが明示的に設定されるのかが明確ではない。そのため、設定が複雑になる場合も考えられる。
（第１動作例）
　次に、第３実施形態に係る第１動作例について説明する。
　第１動作例では、一旦、ルーティング処理を行い、送信できなかったパケットに対してＢＡＰヘッダ書き替え処理を行い、その後、再度ルーティング処理を行う動作例である。
　具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００－１）が、パケットを受信する。第２に、中継ノードが、当該パケットに対して、ルーティング処理を行い、次ホップＢＡＰアドレスを選択できないこと、又は流出バックホールリンクを選択できないこと、を確認する。第３に、中継ノードが、確認を行った当該パケットをドナーＤＵ間リルーティングの対象のパケットと判定する。第４に、中継ノードが、ドナーＤＵ間リルーティングの対象のパケットと判定した当該パケットに対して、再度ルーティング処理を行う。
　これにより、例えば、ルーティング処理を行い、行先のないパケットに対して、再度ルーティング処理を行うという、リルーティングの原則に則った処理を行うことができる。
　そして、中継ノードが、ドナーＤＵ間リルーティング対象のパケットと判定した当該パケットに対して、当該パケットの宛先を書き替えるＢＡＰヘッダ書き替え処理を実行する。この場合、中継ノードは、パケットの宛先を書き替えたパケットに対して、再度ルーティング処理を行う。
　これにより、例えば、ＩＡＢノード３００－１では、ＢＡＰヘッダ書き替え処理、ルーティング処理、及び再度のルーティング処理を適切に行うことができる。
　図２２は、第３実施形態に係る第１動作例を表す図である。例えば、図９（Ｂ）に示す構成例を適宜参照しながら、図２２を説明する。
　図２２に示すように、ステップＳ１１０において、ＩＡＢノード３００－１は、処理を開始する。
　ステップＳ１１１において、ＩＡＢノード３００－１は、ドナーノード２００から、所定の設定を受ける。所定の設定は、例えば、以下である。
　第１に、ヘッダ書き替えテーブルの設定が行われる。この場合、ヘッダ書き替えテーブルには、第１実施形態で説明したトポロジ間ルーティング用のヘッダ書き替えテーブルと、第３実施形態に係るドナーＤＵ間リルーティング用のヘッダ書き替えテーブルとが設定される。２つのテーブルには、各テーブルを識別する識別子が含まれてもよい。
　第２に、２つのドナーＤＵのＢＡＰアドレスが設定される。図９（Ｂ）の例では、ドナーＤＵ＃１（２００Ｄ１）とドナーＤＵ＃２（２００Ｄ２）の２つのＢＡＰアドレスが設定される。なお、設定されるＢＡＰアドレスは、３つ以上あってもよい。
　ステップＳ１１２において、ＩＡＢノード３００－１のＢＡＰレイヤの送信部は、ＩＡＢノード３００－１のＢＡＰレイヤの受信部から、パケットを受信する。ここで、ＢＡＰレイヤの受信部は、第１実施形態と同様に、ダウンストリーム方向における自身宛てのパケットを、上位レイヤへ出力してもよい。例えば、自身がアクセスＩＡＢノードのため、ルーティング処理などを行わなくてもよいからである。従って、送信部は、受信部から、自身宛のパケット以外のパケットを受信する。
　ステップＳ１１３において、送信部は、当該パケットに対して、ルーティング処理を行う。ルーティング処理では、例えば、以下の処理が行われる。
　第１に、送信部は、当該パケットのＢＡＰヘッダを確認し、宛先（Ｄｅｓｔｉｎａｔｉｏｎ）とパスＩＤ（Ｐａｔｈ　ＩＤ）が一致するエントリがルーティングテーブルに存在しない、又は、当該エントリが存在しても、当該エントリに対応する次ホップＢＡＰアドレスが使用可能（ａｖａｉｌａｂｌｅ）ではないことを確認する（Ｒｅｌ－１６のルーティング処理）。
　第２に、送信部は、当該パケットのＢＡＰヘッダを確認し、宛先が一致するエントリがルーティングテーブルに存在しない、又は、当該エントリが存在しても、当該エントリに対応する次ホップＢＡＰアドレスが使用可能（ａｖａｉｌａｂｌｅ）ではないことを確認する（Ｒｅｌ－１６のリルーティング処理）。
　つまり、送信部は、上記２つを確認し、次ホップＢＡＰアドレスが選択できない状態になっていることを確認する。
　送信部は、次ホップＢＡＰアドレスが使用可能である場合、対応する流出バックホールリンクが使用可能（ａｖａｉｌａｂｌｅ）ではないことを確認する。つまり、送信部は、流出バックホールリンクが選択できない状態であることを確認する。
　第３に、送信部は、マッピング処理において、流出バックホールＲＬＣチャネルが選択できないことを確認してもよい。すなわち、送信部は、当該パケットの流入バックホールＲＬＣチャネルと流入バックホールリンク、及びルーティング処理で選択した流出バックホールリンクと一致するエントリが、マッピングテーブルに存在しないことを確認してもよい。
　第４に、送信部は、当該パケットのＢＡＰヘッダを確認し、宛先がドナーノード２００のＤＵ（例えば、ドナーノードＤＵ＃１（２００Ｄ１））のＢＡＰアドレスであることを確認する。ドナーノードのＤＵのＢＡＰアドレスは、例えば、ステップＳ１１１においてドナーノード２００によってＩＡＢノード３００－１に対して設定されている。そのため、送信部は、このＢＡＰアドレスと当該パケットの宛先とを比較することで確認可能である。なお、当該確認によって、ダウンストリーム方向に対するＢＡＰヘッダの書き替えを防止し、アップストリーム方向のパケットに対してヘッダ書き替えを行うようにすることが可能となる。
　第５に、送信部は、当該パケットがドナーノード２００のＤＵ宛てであることを確認すると、ドナーＤＵ間リルーティング対象（又はアップストリーム方向）のパケットであるとして、マーキングをしてもよい。送信部は、マーキングの代わりに、特別な送信バッファ（すなわち、ドナーＤＵ間リルーティング用バッファ）に当該パケットを格納してもよい。
　送信部は、当該パケットが、ドナーＤＵ間リルーティング対象（又はアップストリーム方向）のパケットであり、かつ、ヘッダ書き替えテーブルが設定されている場合、次のヘッダ書き替え処理へ移行する。
　ステップＳ１１４において、送信部は、当該パケットに対して、ヘッダ書き替え処理を行う。ヘッダ書き替え処理は、第１実施形態における第１動作例のステップＳ１６（図１０）と同様である。
　ステップＳ１１５において、送信部は、ヘッダ書き替え処理が完了したパケットに対して、再度ルーティング処理と再度マッピング処理を行う。送信部は、２つの処理により、流出バックホールリンクと流出バックホールＲＬＣチャネルとを選択する。
　ステップＳ１１６において、送信部は、選択した流出バックホールリンクの選択した流出バックホールＲＬＣチャネルへ、当該パケットを出力する。そして、ＩＡＢノード３００－１は、当該パケットを、選択した次ホップのノードへ送信する。
　ステップＳ１１７において、ＩＡＢノード３００－１は、一連の処理を終了する。
（第１動作例のまとめ）
　図２３は、第３実施形態に係る第１動作例をまとめた図である。
　図２３において、ステップＳ１２０は、図２２のステップＳ１１２に対応する。図２３のステップＳ１２２は、図２２のステップＳ１１３に対応する。図２３のステップＳ１２３は、図２２のステップＳ１１４に対応する。
　図２３に示すように、送信部は、ルーティング処理とマッピング処理（ステップＳ１２２）を行って、ルーティング処理においてルーティングできなかったパケット、又はマッピング処理においてマッピングできなかったパケットに対して、ＢＡＰヘッダ書き替え処理を行う（ステップＳ１２３）。
　そして、送信部は、再度、ルーティング処理とマッピング処理を行って、処理済のパケットをドナーＤＵ間リルーティング済のパケットとして、次ホップノードへ送信する。
（第１動作例の変形例）
　第３実施形態に係る第１動作例の少なくとも一部は、ドナーＤＵ間リルーティング以外のシナリオにも適用可能である。
（第２動作例）
　次に、第３実施形態に係る第２動作例について説明する。
　３ＧＰＰ　ＴＳ３８．３４０　Ｖ１６．５．０（２０１６－０６）の５．２．１．１「Ｇｅｎｅｒａｌ」には、以下の記載がある。
「NOTE:       Data buffering on the transmitting part of the BAP entity, e.g., until RLC-AM entity has received an acknowledgement, is up to implementation. In case of BH RLF, the transmitting part of the BAP entity may reroute the BAP Data PDUs, which has not been acknowledged by lower layer before the BH RLF, to an alternative path in accordance with clause 5.2.1.3.」
　下線部に示すように、３ＧＰＰにおけるリルーティングは、送信済のパケットのうち、下位レイヤにおいてＡｃｋが確認されなかったパケットに対して行われる。
　そこで、第２動作例では、送信済のパケットに対して、ドナーＤＵ間リルーティングを行う動作例について説明する。
　具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００－１）が、パケット送信後、当該パケットの複製（又はコピー）をバッファに記憶する。第２に、中継ノードが、バッファに記憶したパケットから、ドナーＤＵ間リルーティング対象のパケットを選択する。第３に、中継ノードが、選択したパケットに対して、当該パケットの宛先を書き替えるＢＡＰヘッダ書き替え処理を行う。第４に、中継ノードが、ＢＡＰパケット書き替え処理を行ったパケットに対して、再度ルーティング処理を行う。
　これにより、例えば、ＩＡＢノード３００－１では、バッファに滞留しているパケットの中から、ドナーＤＵ間リルーティング対象のパケットを選択することができ、適切にドナーＤＵ間リルーティングを行うことが可能となる。
　図２４は、第３実施形態に係る第２動作例を表す図である。
　図２４に示すように、ステップＳ１３０において、ＩＡＢノード３００－１は、処理を開始する。
　ステップＳ１３１において、ＩＡＢノード３００－１のＢＡＰレイヤは、パケットを送信後、当該パケットのコピーをバッファに格納する。ＢＡＰレイヤは、当該パケットの送信に用いた、ルーティングＩＤ、次ホップＢＡＰアドレス、流出バックホールリンク、及び流出バックホールＲＬＣチャネルの少なくも１つを、バッファに格納した当該パケットと紐づけて格納してもよい。若しくは、ルーティングＩＤ、次ホップＢＡＰアドレス、流出バックホールリンク、及び流出バックホールＲＬＣチャネルのいずれかに紐づいた複数のバッファを有してもよい。この場合、ＢＡＰレイヤは、当該パケットの送信先に応じて、該当するバッファに当該パケットのコピーを格納してもよい。なお、ＢＡＰレイヤは、下位レイヤ（ＲＬＣ）より、当該パケットの送達確認の通知を受けた場合、バッファに格納した当該パケット（のコピー）をバッファから削除する。
　ステップＳ１３２において、ＢＡＰレイヤは、ドナーＤＵ間リルーティングの実行を判断したとき、ドナーＤＵ間リルーティングの対象となるパケットを、バッファに格納したパケットの中から選択する。当該ドナーＤＵ間リルーティングの実行判断と当該ドナーＤＵ間リルーティング対象パケットの選択は、例えば、以下のようにして行われる。
　第１に、ＩＡＢノード３００－１は、ＢＨ　ＲＬＦを検出した場合に当該リルーティングを実行すると判断する。ＩＡＢノード３００－１は、当該ＢＨ　ＲＬＦを検出した流出バックホールリンクを特定してもよい。若しくは、ＩＡＢノード３００－１は、当該流出バックホールリンクから影響を受ける、ルーティングＩＤ、次ホップＢＡＰアドレス、及び流出バックホールＲＬＣチャネルの少なくとも１つを特定してもよい。ＩＡＢノード３００－１は、特定した流出バックホールリンク（又は、ルーティングＩＤ、次ホップＢＡＰアドレス、及び流出バックホールＲＬＣチャネルの少なくとも１つ）と紐づいたパケットをバッファから選択する。当該パケットが当該リルーティング対象パケットとなり得る。
　第２に、ＩＡＢノード３００－１は、Ｔｙｐｅ２　ＢＨ　ＲＬＣ　Ｉｎｄｉｃａｔｉｏｎを受信した場合に当該リルーティングを実行すると判断する。Ｔｙｐｅ２　ＢＨ　ＲＬＣ　Ｉｎｄｉｃａｔｉｏｎは、ＢＨ　ＲＬＦからの回復を施行中であることを示すＩｎｄｉｃａｔｉｏｎである。ＩＡＢノード３００－１の上位ノードであるＩＡＢノード３００－Ｐ１のＩＡＢ－ＤＵが、ＩＡＢノード３００－１のＩＡＢ－ＭＴへ当該Ｉｎｄｉｃａｔｉｏｎを送信する。ＩＡＢノード３００－１は、当該Ｉｎｄｉｃａｔｉｏｎを受信した流出バックホールリンクを特定してもよい。若しくは、ＩＡＢノード３００－１は、当該Ｉｎｄｉｃａｔｉｏｎにルーティングできない（又は影響を受ける、若しくはリルーティングすべき）、ルーティングＩＤとバックホールＲＬＣチャネルＩＤとが通知されている場合、これらのＩＤを特定してもよい。若しくは、ＩＡＢノード３００－１は、特定したこれらの情報から、影響を受ける次ホップＢＡＰアドレスを特定してもよい。ＩＡＢノード３００－１は、特定した流出バックホールリンク（又は、ルーティングＩＤ、流出バックホールＲＬＣチャネル、及び次ホップＢＡＰアドレスの少なくとも１つ）に紐づいたパケットをバッファから選択する。当該パケットが当該リルーティング対象パケットとなり得る。
　第３に、ＩＡＢノード３００－１は、アップリンク方向のフロー制御フィードバック（Ｆｌｏｗ　ｃｏｎｔｒｏｌ　ｆｅｅｄｂａｃｋ）を、ＩＡＢノード３００－１の上位ノードから受信した場合に当該リルーティングを実行すると判断する。当該フロー制御フィードバックを上位ノードから受信したＩＡＢノード３００－１は、上位ノードへのデータ送信量などを少なくするなどの制御を行うことで、ＩＡＢノード間の混雑を回避すること等が可能となる。ＩＡＢノード３００－１のＩＡＢ－ＭＴ（のＢＡＰレイヤ）が、上位ノードのＩＡＢ－ＤＵから送信された当該フィードバックを受信できる。ＩＡＢノード３００－１は、当該フィードバックを受信した流出バックホールリンクを特定してもよい。若しくは、ＩＡＢノード３００－１は、当該フィードバックにより、影響を受ける使用可能バッファサイズ（ａｖａｉｌａｂｌｅ　ｂｕｆｆｅｒ　ｓｉｚｅ）と紐づいたルーティングＩＤ又はバックホールＲＬＣチャネルを特定してもよい。使用可能なバッファサイズが閾値（ドナーノード２００により設定）を下回った場合に、当該バッファサイズと紐づいたルーティングＩＤ又はバックホールＲＬＣチャネルを、当該リルーティング対象としてもよい。若しくは、ＩＡＢノード３００－１は、特定したこれらの情報から次ホップＢＡＰアドレスを特定してもよい。ＩＡＢノード３００－１は、特定したルーティングＩＤ、流出バックホールリンク、流出バックホールＲＬＣチャネル、及び次ホップＢＡＰアドレスのうち少なくとも１つに紐づいたパケットをバッファから選択する。当該パケットが当該リルーティング対象パケットとなり得る。
　ＩＡＢノード３００－１は、他の何等かの基準で当該リルーティングを実行する場合も、同様にして、当該リルーティング対象のパケットを選択してもよい。
　ステップＳ１３３において、ＩＡＢノード３００－１は、選択したパケットに対して、ＢＡＰヘッダ書き替え処理を行う。ＢＡＰヘッダ書き替え処理は、第１実施形態の第１動作例（図１０のステップＳ１６）と同様である。
　ステップＳ１３４において、ＩＡＢノード３００－１は、ＢＡＰヘッダ書き替え処理を行ったパケットに対して、パケット送信前に行ったルーティング処理とマッピング処理とを再度行う。ＩＡＢノード３００－１は、処理済の当該パケットを次ホップノードへ送信する。
　そして、ステップＳ１３５において、ＩＡＢノード３００－１は、一連の処理を終了する。
（第２動作例の変形例）
　第２動作例の少なくとも一部は、ドナーＤＵ間リルーティング以外のシナリオにも適用可能である。
（第３動作例）
　次に、第３実施形態に係る第３動作例について説明する。
　第１実施形態と第２実施形態では、ＩＡＢノード３００のＢＡＰレイヤが、ドナーノード２００から設定されたＢＡＰヘッダ書き替えテーブルを参照して、ＢＡＰヘッダ書き替えを行う例を説明した。
　一方、Ｒｅｌ－１６では、ＢＡＰレイヤが、通常のルーティングテーブルを参照して、ＢＡＰヘッダの宛先（Ｄｅｓｔｉｎａｔｉｏｎ）と一致するルーティングＩＤの中から、リルーティング先のルーティングＩＤを適当に選択していた。これは、Ｒｅｌ－１６では、ＣＵ内／ドナーＤＵ内リルーティング（Ｓ１－２）が想定されていたため、同一トポロジ内にリルーティング先のルートがあることが前提であったため、問題は生じ得なかった。
　ここで、同様のコンセプト（つまり、ＢＡＰヘッダ書き替えテーブルが存在しない場合のコンセプト）がドナーＤＵ間リルーティングに適用される場合の課題について検討する。
　第１に、ダウンストリーム方向については、宛先はアクセスＩＡＢノードであり、これは、Ｒｅｌ－１６と変わらない。そのためダウンストリーム方向については、課題については検討しないことにする。
　第２に、アップストリーム方向については、ドナーノードのＤＵが複数存在する（＝宛先ＢＡＰアドレスが複数存在する）。ただし、ドナーノードの複数のＤＵは、同一のドナーノードのＣＵに管理される。そのため、当該ドナーノードのＣＵが管理するルーティングテーブルには、例えば、ドナーＤＵ＃１（２００Ｄ１）のＢＡＰアドレスと、ドナーＵ＃２（２００Ｄ２）のＢＡＰアドレスの２つのＢＡＰアドレス（宛先）が存在するはずである。
　しかし、ＢＡＰヘッダに含まれる宛先（例えば、ドナーＤＵ＃１（２００Ｄ１））だけを手掛かりにルーティングテーブルを参照しても、別のドナーノードのＤＵ（例えば、ドナーＤＵ＃２（２００Ｄ２））とはＢＡＰアドレス自体が異なるため、当該別のドナーのＤＵへのルーティングＩＤを候補として選択できない場合がある。
　また、３ＧＰＰでは、ドナーＤＵ間リルーティングについて、直前のルーティングＩＤから新たなルーティングＩＤへのＢＡＰヘッダ書き替えを行うことが既に合意済である。
　そこで、第３動作例は、ドナーノード２００が、宛先（例えば、ドナーＤＵ＃１（２００Ｄ１））と紐づけられたａｌｔｅｒｎａｔｉｖｅ　ｄｅｓｔｉｎａｔｉｏｎ（代替宛先（例えば、ドナーＤＵ＃２（２００Ｄ２）））をＩＡＢノード３００－１に設定する。そして、ＩＡＢノード３００－１は、代替宛先を含むルーティングＩＤをルーティングテーブルから選択し、選択したルーティングＩＤをＢＡＰヘッダに書き込むことで、ＢＡＰヘッダ書き替えを行う。
　具体的には、第１に、ドナーノード（例えば、ドナーノード２００）が、中継ノード（例えば、ＩＡＢノード３００－１）に対して、第１ドナーノード（例えば、ドナーＤＵ＃１（２００Ｄ１））の第１宛先アドレスと、第２ドナーノード（例えば、ドナーＤＵ＃２（２００Ｄ２））の第２宛先アドレスとを設定する。第２に、中継ノードが、アップストリーム方向のパケットを受信する。第３に、中継ノードが、ルーティング処理を行い、パケットを次ホップ中継ノードへ送信できないことを判別する。第４に、中継ノードが、判別したパケットに対して、当該パケットの第１宛先アドレスと一致するＢＡＰアドレスを含む第１ルーティングＩＤがルーティングテーブルに存在しない場合、第２宛先アドレスと一致するＢＡＰアドレスを含む第２ルーティングＩＤをルーティングテーブルから選択する。第５に、中継ノードが、第２ルーティングＩＤを当該パケットのヘッダに書き込む。ここで、第２宛先アドレスは第１宛先アドレスに紐づけられている。
　これにより、ＩＡＢノード３００－１は、ドナーＤＵ間リルーティングに際して、ＢＡＰヘッダ書き替えテーブルを使用することなく、ＢＡＰヘッダ書き替えを行うことが可能となる。
　図２５は、第３実施形態に係る第３動作例を表す図である。
　図２５に示すように、ステップＳ１４０において、ＩＡＢノード３００－１は、処理を開始する。
　ステップＳ１４１において、ＩＡＢノード３００－１は、ドナーノード２００から所定の設定を受ける。所定の設定は、例えば、以下である。
　すなわち、所定の設定は、ドナーノード２００の複数のＤＵについてのＢＡＰアドレスである。若しくは、所定の設定は、ドナーＤＵ間リルーティングに用いる代替宛先（ａｌｔｅｒｎａｔｉｖｅ　ｄｅｓｔｉｎａｔｉｏｎ）である。例えば、ある宛先（例えば、ドナーＤＵ＃１（２００Ｄ１））のＢＡＰアドレスと、代替宛先（例えば、ドナーＤＵ＃２（２００Ｄ２））のＢＡＰアドレスと、が紐づけられて設定される。若しくは、ある宛先（例えば、ドナーＤＵ＃１（２００Ｄ１）とドナーＤＵ＃２（２００Ｄ２））が（アップストリーム方向の）代替宛先として使用可能であることを示す識別子が設定されてもよい。
　ステップＳ１４２において、ＩＡＢノード３００－１は、パケットを下位ノードから受信する。
　ステップＳ１４３において、ＩＡＢノード３００－１は、通常のルーティング処理を行い、次ホップノードが選択できない（又は送信できない）ことを確認する。ステップＳ１４３における処理は、例えば、第３実施形態に係る第１動作例（図２２のステップＳ１１３）と同様でもよい。
　ステップＳ１４４において、ＩＡＢノード３００－１は、当該パケットのヘッダに含まれる宛先（Ｄｅｓｔｉｎａｔｉｏｎ）と一致するＢＡＰアドレスを有するルーティングＩＤをルーティングテーブルにおいて検索する。
　第１に、ＩＡＢノード３００－１は、当該ルーティングＩＤを含むエントリがルーティングテーブルに存在し、対応する次ホップＢＡＰアドレス、流出バックホールリンク、及び流出バックホールＲＬＣチャネルが使用可能（ａｖａｉｌａｂｌｅ）である場合、当該設定に従って、再度ルーティング処理を行う。
　第２に、当該エントリがルーティングテーブルに存在しない場合、対応する次ホップＢＡＰアドレスが使用不可能（ｕｎａｖｉｌａｂｌｅ、又はｃｏｎｇｅｓｔｅｄ）である場合、又は対応する流出バックホールリンク及び／又は流出バックホールＲＬＣチャネルが使用不可能（ｕｎａｖｉｌａｂｌｅ、又はｃｏｎｇｅｓｔｅｄ）である場合、以下の処理へ進む。
　すなわち、ＩＡＢノード３００－１は、当該パケットがアップストリーム方向であると判定したとき、当該パケットの宛先と紐づけられた代替宛先（当該宛先とは異なる別ドナーノードのＤＵのＢＡＰアドレス）と一致するＢＡＰアドレスを含むルーティングＩＤをルーティングテーブルにおいて検索する。
　ここで、アップストリーム方向であることの判定方法は、当該パケットのヘッダに含まれる宛先が、ステップＳ１４１で設定されたドナーノード２００のＤＵのＢＡＰアドレスと一致した場合、ＩＡＢノードは当該パケットがアップストリーム方向であると判定できる。また、当該パケットのヘッダに含まれる宛先と一致する代替宛先がステップＳ１４１による設定で存在する場合に、ＩＡＢノード３００－１は、アップストリーム方向であると判定できる。
　ＩＡＢノード３００－１は、当該検索の結果、ルーティングテーブルに、別ドナーノード（又は代替宛先）のＤＵのＢＡＰアドレスを含むルーティングＩＤが存在する場合、当該ルーティングＩＤを選択する。その後、ＩＡＢノード３００－１は、当該ルーティングＩＤと対応する次ホップＢＡＰアドレスを選択し、対応する流出バックホールリンクと、流出バックホールＲＬＣチャネルとを選択する。この際、ＩＡＢノード３００－１は、選択した次ホップＢＡＰアドレス、流出バックホールリンク、及び流出バックホールＲＬＣチャネルが送信可能（ａｖａｉｌａｂｌｅ）であることを確認する。
　ステップＳ１４５において、ＩＡＢノード３００－１は、当該選択したルーティングＩＤを当該パケットのヘッダに書き込む。つまり、ＩＡＢノード３００－１は、代替宛先を含むルーティングＩＤを選択した場合に、当該ルーティングＩＤをヘッダに書き込む。これにより、ＢＡＰヘッダ書き替えが行われる。ここで、ＩＡＢノード３００－１は、ＢＡＰヘッダ書き替えに関する情報をドナーへ報告してもよい。当該情報は、リルーティング処理に伴ってＢＡＰヘッダ書き替えを行った場合の、書き替え前のルーティングＩＤ（すなわち、旧ルーティングＩＤ又はPrevious Routing ID）及び／又は書き替え後のルーティングＩＤ（すなわち、新たなルーティングＩＤ又はNew Routing ID）であってもよい。当該情報は更にリルーティングが実行された時間（時刻）情報、リルーティングが実行されたパケット数を含んでもよい。当該情報は、リルーティング処理が発生するたびにＩＡＢノード３００－１の内部メモリに記録（ログ）されてもよい。当該報告は、リルーティング処理が行われる毎に（すなわち即座に）行われてもよく、ドナーからの要求に伴って（すなわち後で）行われてもよい。
　ステップＳ１４６において、ＩＡＢノード３００－１のＢＡＰレイヤは、選択した流出バックホールリンクの選択した流出バックホールＲＬＣチャネルへ、当該パケットを出力する。ＩＡＢノード３００－１は、当該パケットを次ホップのＩＡＢノードへ（又はドナーＤＵ＃２（２００Ｄ２）へ向けて）送信する。
　そして、ステップＳ１４７において、ＩＡＢノード３００－１は、一連の処理を終了する。
（第３動作例のまとめ）
　図２６は、第３実施形態に係る第３動作例をまとめたものである。
　図２６において、ステップＳ１５０は、図２５のステップＳ１４２に対応する。図２６のステップＳ１５２は、図２５のステップＳ１４３とステップＳ１４４に対応する。図２６のステップＳ１５３は、図２５のステップＳ１４５に対応する。
　ステップＳ１５０において、ＩＡＢノード３００－１はＢＡＰ受信処理を行う。この場合、ＩＡＢノード３００－１は、第１実施形態と同様に、アップストリーム方向だけではなく、ダウンストリーム方向のパケットも受信し、当該パケットが自身宛て（当該パケットがダウンストリーム方向で、ＩＡＢノード３００－１がアクセスＩＡＢノードとなり得る）の場合、上位ノードへ出力するようにしてもよい。この場合、ＩＡＢノード３００－１は、受信パケットのうち、自身宛てのパケット以外のパケットに対して、ＢＡＰ送信処理（ステップＳ１５１）を行う。
　ステップＳ１５２において、ＩＡＢノード３００－１のＢＡＰレイヤは、ルーティング処理とマッピング処理を行う。この場合、ＢＡＰレイヤは、受信パケットのヘッダに含まれる宛先と異なる宛先へルーティングするアップストリーム方向のパケットをＢＡＰヘッダ書き替え対象のパケットと判定する（図２５のステップＳ１４３とステップＳ１４４）。また、ＢＡＰレイヤは、当該ヘッダの宛先と紐づいた別のドナーノードのＣＵのＢＡＰアドレスを含むルーティングＩＤをルーティングテーブルから検索する。
　そして、ステップＳ１５３において、ＢＡＰレイヤは、ＢＡＰヘッダ書き替え対象のパケットに対して、当該ルーティングＩＤを用いてＢＡＰヘッダ書き替え処理を行う（図２５のステップＳ１４４）。
　他方、ステップＳ１５２において、ＢＡＰレイヤは、当該ヘッダに含まれる宛先と同一の宛先へルーティング可能なアップストリーム方向のパケットを、次ホップのノードへ送信する。また、ＩＡＢノード３００－１は、ＢＡＰ送信処理対象のダウンストリーム方向のパケットも、ルーティング処理とマッピング処理により、次ホップのノードへ送信する。
（第３動作例の変形例）
　第３実施形態に係る第３動作例の少なくとも一部は、ドナーＤＵ間リルーティング以外のシナリオにも適用可能である。
［第４実施形態］
　第１実施形態から第３実施形態では、トポロジ間ルーティング（Ｓ３－１）、トポロジ間リルーティング（Ｓ３－１）、ドナーＤＵ間リルーティング（Ｓ２－２）の各シナリオについてそれぞれ説明した。
　では、全てのシナリオにおいて、できるだけ共通の手順又は処理とするにはどのようにすればよいかが問題となる場合がある。
　図２７は、手順又は処理を全てのシナリオで共通化した場合の一例を表す。図２７は、第４実施形態に係るＩＡＢノード３００の構成例を表している。
　図２７に示すように、ＩＡＢノード３００は、送信部３３０－Ｔと、受信部３３０－Ｒとを有する。
　送信部３３０－Ｔは、ＢＡＰヘッダ書き替え決定部３３１、ＢＡＰヘッダ書き替え部３３２、ルーティング／マッピングテーブル選択部３３３、ルーティング／リルーティング処理部３３４、及びマッピング処理部３３５を有する。
　受信部３３０－Ｒは、上位レイヤ出力決定部３３６を有する。
　上位レイヤ出力決定部３３６は、受信パケットを上位レイヤへ出力するか、当該パケットを送信部３３０－Ｔへ出力するかを決定する。例えば、第１実施形態で説明したように、当該パケットのヘッダに含まれる、トポロジ間ルーティング対象であるか否かを示す識別子に基づいて決定してもよい。
　ＢＡＰヘッダ書き替え決定部３３１は、受信部３３０－Ｒから受け取った当該パケットについて、ＢＡＰヘッダ書き替えを行うか否かを決定する。ＢＡＰヘッダ書き替え決定部３３１は、例えば、第１実施形態で説明したように、当該パケットのヘッダが特定のルーティングＩＤにマッチするか否かにより、ＢＡＰヘッダ書き替え対象のパケット（＝トポロジ間ルーティング対象のパケット）を決定してもよい。ＢＡＰヘッダ書き替え決定部３３１は、ＢＡＢヘッダ書き替え対象のパケットをＢＡＰヘッダ書き替え部３３２へ出力し、ＢＡＰヘッダ書き替え対象ではないパケットをルーティング／リルーティング処理部３３４へ出力する。
　ＢＡＰヘッダ書き替え部３３２は、当該パケットのＢＡＰヘッダを書き替える。ＢＡＰヘッダ書き替え部３３２は、第１実施形態で説明したように、ＢＡＰヘッダ書き替えテーブルを用いて書き替えを行ってもよい。また、ＢＡＰヘッダ書き替え部３３２は、一度もルーティング処理を行っていないパケットに対してはＢＡＰヘッダ書き替えを行わないようにし、ルーティング／リルーティング処理部３３４から出力されたパケットに対して、ＢＡＰヘッダ書き替えを行うようにしてもよい。
　ルーティング／マッピングテーブル選択部３３３は、ルーティングテーブルとマッピングテーブルとを選択する。ルーティング／マッピングテーブル選択部３３３は、例えば、第１実施形態で説明したように、第２ルーティングテーブルと第２マッピングテーブルとを選択してもよい。
　ルーティング／リルーティング処理部３３４は、ＢＡＰヘッダ書き替えを行ったパケットに対してルーティング処理及び／又はリルーティング処理を行い、ＢＡＰヘッダ書き替えを行っていないパケットに対してルーティング処理及び／又はリルーティング処理を行ってもよい。ルーティング／リルーティング処理部３３４は、第３実施形態で説明したように、一旦、ルーティング処理（及び／又はリルーティング処理）を行い、行先の無いのパケットを、ＢＡＰヘッダ書き替え部３３２へ出力してもよい。
　マッピング処理部３３５は、ルーティング処理後のパケット、又はリルーティング処理後のパケットに対して、マッピングテーブルを用いてマッピング処理を行う。マッピング処理部３３５は、処理済のパケットを、流出バックホールＲＬＣチャネルを介して、次ホップノードへ送信する。
　上述したように、図２７に示すＩＡＢノード３００の構成例は一例である。
　第１実施形態から第４実施形態で説明した各実施形態、各動作例、各処理、又は各ステップは、相互に組み合わせることが可能である。第１実施形態から第４実施形態の各実施形態の全部又は一部は矛盾しない範囲で組み合わせることが可能である。このような組み合わせにより、全てのシナリオにおいて手順又は処理の共通化を図ることができる場合もある。
［その他の実施形態］
　ＵＥ１００又はｇＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。
　また、ＵＥ１００又はｇＮＢ２００が行う各処理を実行する回路を集積化し、ＵＥ１００又はｇＮＢ２００の少なくとも一部を半導体集積回路（チップセット、ＳｏＣ）として構成してもよい。
　以上、図面を参照して一実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
　本開示で使用されている「に基づいて（ｂａｓｅｄ　ｏｎ）」、「に応じて（ｄｅｐｅｎｄｉｎｇ　ｏｎ）」という記載は、別段に明記されていない限り、「のみに基づいて」、「のみに応じて」を意味しない。「に基づいて」という記載は、「のみに基づいて」及び「に少なくとも部分的に基づいて」の両方を意味する。同様に、「に応じて」という記載は、「のみに応じて」及び「に少なくとも部分的に応じて」の両方を意味する。また、「取得する（ｏｂｔａｉｎ／ａｃｑｕｉｒｅ）」は、記憶されている情報の中から情報を取得することを意味してもよく、他のノードから受信した情報の中から情報を取得することを意味してもよく、又は、情報を生成することにより当該情報を取得することを意味してもよい。「含む（ｉｎｃｌｕｄｅ）」、「備える（ｃｏｍｐｒｉｓｅ）」、及びそれらの変形の用語は、列挙する項目のみを含むことを意味せず、列挙する項目のみを含んでもよいし、列挙する項目に加えてさらなる項目を含んでもよいことを意味する。また、本開示において使用されている用語「又は（ｏｒ）」は、排他的論理和ではないことが意図される。さらに、本開示で使用されている「第１」、「第２」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみがそこで採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。本開示において、例えば、英語でのａ，ａｎ，及びｔｈｅのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。
　本願は、米国仮出願第６３／２５７２２８号（２０２１年１０月１９日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
（付記）
　導入
　ＲＡＮ２＃１１５Ｅにおいて、ＮＲ向け統合アクセス及びバックホールの強化（ＥＩＡＢ）の作業項目は、トポロジ適応の強化について以下の合意に達した。
　フロー制御フィードバックに基づく利用可能なバッファサイズの設定された閾値は、ローカルリルーティングの目的のために、輻輳を決定するために使用される。
　ＣＵ内の場合、少なくともドナーＤＵ間のＮＲ－ＤＣ、ドナーＤＵ間回復、ドナーＤＵ間移動のシナリオでは、ドナーＤＵ間リルーティングをサポートすること。
　ＣＵ間リルーティングをサポートする。すなわち、ＩＡＢノードはターゲットＣＵのトポロジ上の代替ＢＡＰパスを介して、元のドナーＣＵにデータをリルーティングする。
　ドナーDU間のリルーティングにおいて、「直前のルーティングＩＤから新たなルーティングＩＤへ」のBAPヘッダの書き替えをサポートする。
　ＲＡＮ２でＣＵ間ルーティングのＯｐｅｎ　Ｉｓｓｕｅをさらに議論する。
　最初のトポロジのＢＡＰヘッダに追加されるＢＡＰアドレス（すなわち、境界ノードにおける流入データのＢＡＰアドレス）とは何か。
　トポロジ内ルーティング（ｃｏｎｃａｔｅｎａｔｅｄ　ｔｒａｆｆｉｃ）とトポロジ間ルーティング（ｎｏｎ－ｃｏｃａｔｅｎａｔｅｄ　ｔｒａｆｆｉｃ）とをどのように判別するか。
　上位レイヤ（ダウンストリーム用）にデータを配信すべきかどうかの決定方法。
　データのＢＡＰヘッダを書き替えるべきかどうか（他のトポロジにルーティングされるか、自トポロジにルーティングされるか）の決定方法。
　ベースラインとして、ＣＵ間ルーティングにおいて、境界ノードでのＢＡＰヘッダの書き替えのための「直前のルーティングＩＤ」から「新たなルーティングＩＤへ」の１：１及びＮ：１マッピングをサポートすること。
　ベースラインとして、ＣＵ間ルーティングにおいて、境界ノードでのベアラマッピングの「流入ＢＨリンク＋流入ＢＨ　ＲＬＣ　ＩＤ」から「流出ＢＨリンク＋流出ＢＨ　ＲＬＣ　ＩＤ」への１：１及びＮ：１マッピングをサポートすること。
　この付記では、様々なシナリオのためのルーティングとリルーティングの拡張について議論している。
　議論
　ＲＥＬ－１７では、図９に示すように、ルーティング及びリルーティングは、ＣＵ内／ドナーＤＵ内（ＲＥＬ－１６と同様）、ＣＵ内／ドナーＤＵ間及びＣＵ間などのさまざまなシナリオをカバーする必要がある。これらの機能強化は、ＩＡＢトポロジにおけるパケット転送の信頼性、柔軟性、又は低遅延化に貢献すると期待されるが、ＢＡＰルーティング／リルーティング動作にさらなる複雑さをもたらす可能性がある。したがって、すべてのシナリオに共通の手順を規定し、シナリオ固有の手順を可能な限り少なくすることが望ましい。この意味で、最も複雑なシナリオであるＣＰＵ間ルーティングを最初に検討し、その後、ＣＰＵ間ルーティングの手順が他のシナリオに適用（再利用）可能かどうかについて検討する必要がある。
　ＣＵ間ルーティング
　ＣＵ間ルーティングについては、４つのＯｐｅｎ　Ｉｓｓｕｅに合意している。Ｏｐｅｎ　Ｉｓｓｕｅをどのように解決するかについて検討する良い出発点となる。
　Ｏｐｅｎ　Ｉｓｓｕｅ１：最初のトポロジのＢＡＰヘッダに付加されるＢＡＰアドレス（すなわち、境界ノードでの流入データのＢＡＰアドレス）は何か。
　以下のようにいくつかの解決例が示されている。
　　例１：最初のトポロジのＢＡＰ　ＰＤＵヘッダに、境界ノードのＢＡＰアドレスを追加する。
　　例2：実際の宛先の代理／偽BAPアドレスを追加する。
　一方、ＲＡＮ３では、トポロジの冗長性について以下のように合意している。
　　１Ａ：ＲＡＮ３は、境界ノードが各トポロジで１つのＢＡＰアドレスのみを有すると仮定する。
　　１Ｂ：ＲＡＮ３は、各トポロジにおいて、そのトポロジの境界ノードのＢＡＰアドレスは、上位レイヤに渡されなければならないパケットを識別するためにのみ使用されると仮定している。
　両方の例が機能可能であるが、例１はＲＡＮ３の仮定（特に１Ａ）とより一致すると考えられる。さらに、例１は、境界ノードがＩＡＢ－ドナーＤＵやアクセスＩＡＢノードのように、最初のトポロジのエンドポイントとして考えられるため、ＲＥＬ－１６ルーティングメカニズムの観点から非常に単純であると言える。また、例１は、中間ＩＡＢノードがローカルリルーティングを実行する場合、「誤ルーティング」のリスクが低くなる。この意味で、ＲＡＮ２はさらなる議論のために例１に合意すべきである。
　提案１：ＲＡＮ２は、最初のトポロジにおいて、境界ノードのＢＡＰアドレスがＢＡＰデータＰＤＵヘッダ（すなわち、宛先フィールド）に追加されることに合意すべきである。
　Ｏｐｅｎ　Ｉｓｓｕｅ２：トポロジ内ルーティング（ｃｏｎｃａｔｅｎａｔｅｄ　ｔｒａｆｆｉｃ）とトポロジ間ルーティング（ｎｏｎ－ｃｏｃａｔｅｎａｔｅｄ　ｔｒａｆｆｉｃ）とを判別する方法
　提案１に合意する場合、トポロジ内ルーティング（ｃｏｎｃａｔｅｎａｔｅｄ　ｔｒａｆｆｉｃ（異なるＩＡＢドナーＣＵに属する２つのトポロジ間のルーティング））は、ＢＡＰデータＰＤＵヘッダの宛先フィールドに境界ＩＡＢノードのＢＡＰアドレスを持つ。一方、トポロジ間ルーティング（ｎｏｎ－ｃｏｃａｔｅｎａｔｅｄ　ｔｒａｆｆｉｃ（１つのＩＡＢドナーＣＵに属するトポロジ内のルーティング））は、他のＢＡＰアドレス、すなわち、ＩＡＢドナーＤＵ又はアクセスＩＡＢノードのＢＡＰアドレスを持つ。つまり、宛先が境界ＩＡＢノードのＢＡＰアドレスと一致しない場合、ＢＡＰデータＰＤＵは受信部からコロケーションＢＡＰエンティティの送信部へ配送される。そのため、受信部では特別な処理は必要ない。ただし、以下のＯｐｅｎ　Ｉｓｓｕｅ３がまだ存在することに留意する必要がある。
　提案２：ＲＡＮ２は、ＢＡＰエンティティの受信部において、トポロジ間ルーティング（ｎｏｎ－ｃｏｃａｔｅｎａｔｅｄ　ｔｒａｆｆｉｃ）を決定するために特別な処理を必要としないこと、つまりＲＥＬ－１６の動作が適用されることに合意すべきである。
　Ｏｐｅｎ　Ｉｓｓｕｅ３：上位レイヤー（ダウンストリーム）へのデータ配信の可否の決定方法
　提案１に合意する場合、トポロジ内ルーティング（ｃｏｎｃａｔｅｎａｔｅｄ　ｔｒａｆｆｉｃ）と境界ＩＡＢノード宛のトラフィックは、各ＢＡＰデータＰＤＵヘッダにおいて同じ宛先、すなわち、境界ＩＡＢノードのＢＡＰアドレスを持つことになる。そこで、境界ＩＡＢノードのＢＡＰエンティティの受信部は、各ＢＡＰデータＰＤＵヘッダのパスフィールド又は新しいフラグ（３つの「Ｒ」ビットのいずれかを使用）によりそれらを判別することができる。
　パスフィールドを使用する場合、境界ＩＡＢノードとＩＡＢドナーＤＵ／アクセスＩＡＢノード間に設定されるパスの数に応じて、ルーティングＩＤスペースが消費される。ＢＡＰヘッダの既存フィールドを再利用するため、データストリームに追加のオーバーヘッドはない。
　新しいフラグが使用される場合、それは「Ｒ」ビットを消費し、それによって、３つの予約ビットがあるだけである。ＢＡＰヘッダの「Ｒ」ビットを使用するため、追加のオーバーヘッドはない。また、このフラグは、ＢＡＰエンティティの送信部において、ＢＡＰヘッダを書き替えるか否かを決定する際にも有用であると想定される。
　上記の利点と欠点を考慮すると、ルーティングされるデータを判別するために、１つの「Ｒ」ビットを使用した新しいフラグを定義することが望ましい。言うまでもなく、この新しいフラグを「０」に設定すれば、ＲＥＬ－１６のＢＡＰヘッダ形式と完全に同じになるため、ＢＡＰエンティティの受信部はＲＥＬ－１６の動作に従ってデータを上位レイヤに送出することになる。
　提案３：ＣＵ間ルーティングのために、ＲＡＮ２はＢＡＰデータＰＤＵヘッダの１つの「Ｒ」ビットを使用して、ルーティングされるデータと上位レイヤに配信されるデータを判別するための新しいフラグを定義することに合意すべきである。
　Ｏｐｅｎ　Ｉｓｓｕe４：データのＢＡＰヘッダを書き替えるべきかどうか（別のトポロジにルーティングされるか、自トポロジにルーティングされるか）を決定する方法
　提案２及び提案３が合意される場合、ＢＡＰエンティティの送信部は、まず各ＢＡＰデータＰＤＵヘッダの新しいフラグを確認することができる。新フラグが「０」であれば（すなわち、ＲＥＬ－１６　ＢＡＰデータＰＤＵを含むトポロジ間ルーティング（（ｎｏｎ－ｃｏｃａｔｅｎａｔｅｄ　ｔｒａｆｆｉｃ）又は「自身のトポロジにルーティングされる」）、ＲＥＬ－１６ルーティング手順が実行される。（すなわち、トポロジ内ルーティング（ｃｏｎｃａｔｅｎａｔｅｄ　ｔｒａｆｆｉｃ）又は「別のトポロジにルーティングされる」））の場合、ルーティング手順の前にＢＡＰヘッダの書き替え動作が実行される。これは「リルーティング」ではないため、ＢＡＰヘッダの書き替え動作が事前に行われるのは当然である。
　提案４：提案３のＢＡＰデータＰＤＵヘッダの新フラグを使用して、ＣＵ間ルーティングのために、ＢＡＰヘッダの書き替えを行うかどうかを決定することにＲＡＮ２は合意すること。
　提案５：ＣＵ間ルーティングについて、ＲＡＮ２は、ルーティング手順の前にＢＡＰヘッダの書き替えが実行されることに合意すること。
　提案３及び提案５が合意された場合、境界ＩＡＢノードで新しいフラグが使用される。そのため、ＢＡＰヘッダの書き替え動作後は無意味になるか、むしろ第２トポロジで不要なエラーを引き起こす可能性がある。そのため、境界ＩＡＢノードでフラグを「０」に書き替えることが安全である。これは、ＢＡＰヘッダの書き替え動作の中で行うのが簡単であると考えられる。
　提案６：ＣＵ間ルーティングについて、提案３の新フラグもＢＡＰヘッダの書き替え動作で書き替える、すなわち「０」にリセットするかどうかをＲＡＮ２で議論すべきである。
　その他考えられる問題
　ルーティングテーブルの選択
　提案５が合意される場合、ヘッダの書き替え設定に従ってヘッダが書き替えられたデータは、ルーティング手順に進むことになる。この場合、ＲＡＮ２が「RAN2の優先順位は、BAPルーティングID選択肢4に基づくBAPヘッダの書き替えによるトポロジ間ルーティングをサポートすること」に合意した通り、既にデータのヘッダは新しいルーティングＩＤに書き替えられているため、最初のトポロジで設定したルーティングテーブル、すなわちＢＨルーティング設定は有効ではない。そうでなければ、各ＩＡＢノードのＢＡＰアドレスはトポロジ内で一意であり、ＣＵ間ルーティングシナリオでも２つのトポロジ（すなわち２つのＣＵ）間では一意ではないため、混乱や「誤ルーティング」のリスクが生じる場合がある。そのため、ルーティングテーブルは２番目のトポロジによって構成されたものを使用する必要がある。
　提案７：ＣＵ間シナリオでは、ＲＡＮ２は、境界ノードが最初のトポロジと２番目のトポロジにそれぞれルーティングするために使用される２つのルーティングテーブルで設定されることに合意すべきである。
　提案７が合意される場合、ルーティング手順の前に、各データのルーティングテーブル選択手順が必要となる場合がある。その仕組みは非常にシンプルに考えられており、あるデータについて、ヘッダが書き替えられた場合（又は新しいフラグが「１」に設定された場合）、２番目のルーティングテーブルが適用される。そうでなければ、最初のルーティングテーブル（すなわち、ＲＥＬ－１６と同じもの）が適用される。
　提案８：ＣＵ間シナリオでは、ＲＡＮ２は、トポロジ内ルーティング（ｃｏｎｃａｔｅｎａｔｅｄ　ｔｒａｆｆｉｃ）に対して、第２のトポロジのルーティングテーブルを選択する手順が必要であるかどうかを議論すべきである。
　ＢＨ　ＲＬＣチャネルマッピングテーブル選択
　ルーティング手順でネクストホップＢＡＰアドレスが決定されると、マッピングテーブル（＝ＢＨ　ＲＬＣチャネルマッピング設定）に用意されている、決定した流入ＢＨリンク、流入ＢＨ　ＲＬＣチャネル、流出ＢＨリンクに基づいて、流出ＢＨ　ＲＬＣチャネルへのマッピングが行われる。ＴＳ３８．３４０の現在の実行ＣＲでは、以下の注釈が収録されている。
　注：境界ＩＡＢノードでのベアラマッピングをどのように収録するかについては更なる検討が必要である（現在の仕様が既にＣＵ間ルーティングのための境界ＩＡＢノードでのベアラマッピングをサポートしているかどうかについても更なる必要が検討である）。
　ＣＵ間シナリオの場合、流入ＢＨリンクとＲＬＣチャネルは第１トポロジに属し、流出ＢＨリンクは第２トポロジに関連付けられる。ＢＡＰアドレスとＲＬＣチャネルがＣＵによって（つまりトポロジごとに）管理されるため、２つのトポロジに接続するためには新しいマッピングテーブルが必要になる。具体的には、ＲＥＬ－１６のマッピングテーブルの構造を再利用することができるが、ＲＥＬ－１６とは異なるマッピングテーブルで構成される必要がある。そうでなければ、両方のトポロジで同じＢＡＰアドレス（すなわち、流入／流出リンクＩＤ）及び／又は同じＢＨ　ＲＬＣチャネルＩＤが使用されている場合、「誤マッピング」のリスクがある。この場合、提案８と同様のマッピングテーブルの選択が必要となる場合がある。
　提案９：ＣＵ間シナリオでは、ＲＡＮ２は、境界ＩＡＢノードが（ＲＥＬ－１６マッピングテーブルに加えて）別のマッピングテーブルで構成され、そのマッピングテーブルはトポロジ内ルーティング（ｃｏｎｃａｔｅｎａｔｅｄ　ｔｒａｆｆｉｃ）に適用されることに合意するものとする。
　提案１０：ＣＵ間シナリオにおいて、提案９の２つのトポロジを接続するための個別のマッピングテーブルを選択する手順が、トポロジ内ルーティング（ｃｏｎｃａｔｅｎａｔｅｄ　ｔｒａｆｆｉｃ）に必要かどうかをＲＡＮ２で議論する。
　ＣＵ間リルート
　ＢＡＰヘッダの書き替え動作の適用性
　ＲＡＮ２は、「ＩＣＵ間リルーティングのサポート、すなわちＩＡＢノードがターゲットＣＵのトポロジ上の代替ＢＡＰパスを介して元のドナーＣＵにデータをリルーティングする」ことに合意した。一般に、この合意はＣＵ間ルーティングと同様と見なすことができる。しかし、詳細には、ＩＡＢノードがターゲットドナーＣＵとのＲＲＣ接続を再確立し、ソースドナーＣＵとのＦ１接続がまだ保持されている場合（つまり、部分移行）、ＣＵ間リルーティングが適用される。ＲＡＮ３は、このシナリオに適用される可能性が高い以下の記載に合意した。
　部分的なドナー間移行では、特定のトポロジのトラフィックのために境界ノードが使用するＩＰアドレス、ＢＡＰアドレス、ＢＨ　ＲＬＣ　ＣＨ及びデフォルトマッピングは、そのトポロジのＣＵによって割り当てられ、それらはＲＲＣを介して設定される。
　上記の構成に加えて、（ターゲットドナーＣＵの）ＲＲＣは、境界ＩＡＢノードが使用する（単純な）ルーティングテーブル及び／又はヘッダの書き替え設定も提供する。なぜなら、元の第２のトポロジにリルートされたデータのＢＡＰヘッダの元のルーティングＩＤはもはや有効ではなく、すなわち境界ＩＡＢノードはターゲットドナーＣＵが管理する、新しい第２のトポロジで有効なルーティングＩＤを知る必要があるからである。この意味で、ＢＡＰヘッダの書き替え動作は、ＣＵ間リルーティングにも必要である。ＣＵ間ルーティングとは対照的に、ＢＡＰヘッダの書き替え動作は、ＢＡＰ　ＲＵＮＮＩＮＧ　ＣＲで既に収録されているように、ルーティング手順が失敗した時点で、「リルーティング」であるため、実行される。また、提案７及び提案８が合意されれば、ルーティングテーブルの選択は、ＣＵ間リルーティングにも適用される可能性がある。また、提案９及び提案１０が合意されれば、ＢＨ　ＲＬＣチャネルマッピングテーブルの選択も適用される場合がある。
　その後、境界ＩＡＢノードは、新しい第２トポロジのＲＲＣによって設定されたＢＨ　ＲＬＣチャネル、つまりターゲットドナーＣＵによって、ネクストホップＢＡＰアドレスにデータを送信することができる。
　提案１１：ＣＵ間リルーティングのために、ＲＡＮ２は、ターゲットドナーからのＲＲＣ信号を介して、境界ＩＡＢノードがＩＰアドレス、ＢＡＰアドレス、ＢＨ　ＲＬＣチャネル及びデフォルトマッピング（ＲＡＮ３が合意したように）、及びデフォルトルーティングＩＤ（又は簡略化したヘッダの書き替えテーブル）などにより構成されることに合意すべきである。
　提案１２：ＣＵ間リルーティングについては、ルーティング（ＲＥＬ－１６ルーティング）が失敗した時点でＢＡＰヘッダの書き替え動作を行うことにＲＡＮ２が合意すべきである。
　提案１３：ＣＵ間リルーティングについて、ルーティングテーブル選択（提案８の導入された場合）、マッピングテーブル選択（提案１０の導入された場合）が適用できるかどうかをＲＡＮ２は議論すべきである。
　ＣＵ内／ＤＵ内リルーティング
　ＲＡＮ２は「ドナーＤＵ間リルーティングでは、『直前のルーティングＩＤから新たなルーティングＩＤ』ＢＡＰヘッダの書き替えをサポートする」ことに合意した。一方、ＲＡＮ３は、以下のように合意している。
　ＲＡＮ３は、あるトポロジのＢＨリンクから隣接トポロジのＢＨリンクにＢＡＰレイヤでルーティングされるトラフィックに対してのみ、ＵＬ及びＤＬトラフィックの両方について、境界ノードがＢＡＰヘッダの書き替えを実行することを望む。
　トポロジはドナーＣＵによって管理され、ドナーＣＵ内の２つのドナーＤＵはＣＵ内トポロジ還元とみなされるため、ドナーＤＵ間のリルーティングは依然として一つのトポロジ内で実行されていると考えられる。この場合、ＲＡＮ２の合意はＲＡＮ３の優先順位と衝突する可能性がある。しかし、ドナーＤＵ間リルーティングにより、アップストリームトラフィックの宛先が変更される、すなわち、ドナーＤＵのＢＡＰアドレスから他のドナーＤＵのＢＡＰアドレスに変更されるため、ＢＡＰヘッダの書き替え動作は当然に必要である。ダウンストリームトラフィックについては、宛先（アクセスＩＡＢノードのＢＡＰアドレス）が変更されないため、ＢＡＰヘッダの書き替え動作は必要ない場合がある。実際、下りのトラフィックは、ドナーＤＵ間リルーティングの対象にはならない（つまり、ローカルリルーティングに過ぎない）と想定される。したがって、ＲＡＮ２は、ＲＡＮ３の優先順位と異なっていても、その合意を確認すべきである。
　提案１４：ＣＵ内／ＤＵ間リルーティングについて、少なくともアップストリームトラフィックについては、「『直前のルーティングＩＤから新たなルーティングＩＤ』のＢＡＰヘッダの書き替えをサポートする」というＲＡＮ２のこれまでの合意を確認する。
　提案１４において、これは「リルーティング」であるため、提案１２のＣＵ間リルーティングと同様に、ＲＥＬ－１６ルーティングが失敗した時点で、ＢＡＰヘッダの書き替え動作を行う。これは、現在のＴＳ　３８．３４０のＲＵＮＮＩＮＧ　ＣＲに既に収録されており、単純に確認することが可能である。
　提案１５：ＣＵ内／ドナー間ＤＵリルーティングについて、ＲＡＮ２は、ＴＳ３８．３４０の現在の実行ＣＲで収録されているように、ルーティング（すなわちＲＥＬ－１６ルーティング）が失敗した時点でＢＡＰヘッダの書き替え動作が行われることを確認すべきである。
　ＣＵ内／ドナーＤＵ内リルーティング（＝ローカルリルーティング）
　ＢＡＰヘッダの書き替え動作の適用可否
　ＣＵ内／ドナーＤＵ内のリルーティングはローカルリルーティングと呼ばれ、以下のようにＲＥＬ－１６から既にサポートされている。
　注：ＲＬＣ－ＡＭエンティティが確認応答を受信するまでのＢＡＰエンティティ送信部でのデータバッファリングは、実装次第である。ＢＨ　ＲＬＦの場合、ＢＡＰエンティティの送信部は、ＢＨ　ＲＬＦ以前に下位レイヤから確認されなかったＢＡＰデータＰＤＵを５．２．１．３節に従って代替パスにリルーティングさせることができる。
　ＢＡＰアドレスが宛先フィールドと一致し、ネクストホップＢＡＰアドレスに対応する流出リンクが利用可能なエントリがＢＨルーティング設定に少なくとも一つ存在する場合、
　ＢＨルーティング設定から、ＢＡＰアドレスが宛先フィールドと同じで、ネクストホップＢＡＰアドレスに対応する流出リンクが利用できるエントリを選択する。
　上記で選択したエントリのネクストホップＢＡＰアドレスに対応する流出リンクを選択する。
　上記現行の仕様によれば、ＩＡＢノードは、ローカルリルーティングの結果、宛先にはマッチするがデータのパスにはマッチしないルーティングＩＤを介してＢＡＰデータＰＤＵを送信することができる。
　一方、ＲＡＮ２＃１１２－Ｅでは、ＲＥＬ－１７のローカルリルーティングは、以下のようにトポロジ全体の目標を考慮すべきであると合意した。
　ＲＡＮ２は、中央経路決定に対する利点を含むローカルリルーティングと、トポロジ全体の目標にどのように対処できるかを議論する。
　上記の合意を考えると、ＲＥＬ－１６のローカルリルートでは、代替パスの選択がＩＡＢノードの実装に任されており、ドナーの観点からは管理しにくい場合があるという問題がある。ＲＥＬ－１６　ＩＡＢトポロジでは、ＩＡＢノードがＢＨ　ＲＬＦを検出した場合のみ、つまり特定の異常状態でのみローカルリルートが許可されるため、大きな問題にはならない。しかし、ＲＥＬ－１７では、他の条件（例えば、輻輳状態）でもローカルリルートが許可されるため、その限りではないが、上記の合意を満たす方法についてはまだ問題が残されている。トポロジ全体の目標を達成するためには、トポロジ全体を管理するドナーが最も適していることは、非常に理解しやすい。この意味で、ドナーはＲＥＬ－１６メカニズムと比較して、代替パス設定という点でローカルリルーティングの制御性をより高める必要がある。
　所見１：ＲＥＬ－１６のローカルリルーティングでは、どの代替パスを選択するかはＩＡＢノードの実装次第であり、ドナーが管理することはできない。
　所見２：ＩＡＢドナーは、ローカルリルーティングにより、トポロジ全体の目標に取り組むのに最も適したノードである。
　この問題を解決するために、ＢＡＰヘッダの書き替え動作が一つの解決策になると考えられる。ＲＡＮ２は以下に合意している。
　ＩＡＢドナーが、ローカルリルーティング（少なくとも同じ宛先、同じルーティングＩＤの更なる検討が必要である）で使用できる（代替）流出リンクを設定すると仮定する。
　流出リンクはＮネクストホップＢＡＰアドレスに関連付けられ、ネクストホップＢＡＰアドレスはルーティングＩＤで決定される。したがって、ドナー側がＩＡＢノードに新たなルーティングＩＤを設定してローカルリルーティングを行うことは当然であり、これは他の（リ）ルーティングシナリオのヘッダの書き替え設定と非常に似ている。
　ＲＡＮ３は、ＢＡＰヘッダの書き込み動作をトポロジ間シナリオでのみ実行することを望んでいるが、ＲＡＮ２は、前述したように、トポロジ内シナリオ、すなわちドナー間ＤＵリルーティングでも実行することに既に合意している。
　そこで、ＢＡＰヘッダの書き替え動作が、ＣＵ内／ＤＵ内リルーティングにも適用され、それによって、ヘッダの書き替え設定が設定されている場合のみ実行されるかどうかを議論する価値があると思われる（選択肢）。
　提案１６：ＲＡＮ２は、ＢＡＰヘッダの書き替えがローカルリルーティング（すなわち、ＣＵ内／ＤＵ間リルーティング）にも適用され、ＩＡＢノードが古いルーティングＩＤと新しいルーティングＩＤの間のマッピングで構成される場合（すなわち、現在のＴＳ３８．３４０の実行ＣＲにおけるヘッダの書き替え設定に類似している場合）の選択肢について議論すべきである。
　ドナーによるローカルリルートコマンド
　ＩＡＢドナーの制御性のもう一つの側面として、ＩＡＢドナーがローカルリルーティングを認識し、ＩＡＢノードでローカルリルーティングを開始／停止することで、ローカルリルーティングとトポロジ全体の目標が共存可能であることを考慮する必要がある。例えば、ＩＡＢドナーがトポロジ全体の目的を達成できないことに気付いた場合、ＩＡＢドナーはＩＡＢノードにローカルリルーティングを開始／停止するように指示することができる。
　ローカルリルーティングによるトポロジ全体の目的をどのように扱うかは、完全にＩＡＢドナーの実装次第だが、ＩＡＢドナーはＩＡＢノードのローカルな決定の情報と制御性を必要とする場合がある。
　提案１７：ＲＡＮ２は、ローカルリルーティングの開始／停止時にＩＡＢノードがＩＡＢドナーに通知する必要があるかどうかを議論すべきである。
　提案１８：ＲＡＮ２は、ＩＡＢドナーがＩＡＢノードに対して、ルート間の負荷分散のためなどにローカルリルーティングの開始／停止を指示できるかどうかを議論するべきである。
　機能強化のまとめ
　上記の提案が合意される場合、全てのシナリオを統一したソリューションの例を図２７に示す。

Claims (8)

  1. 　セルラ通信システムで用いる通信制御方法であって、
    　中継ノードが、ドナーノードから、各トポロジにおける当該中継ノードのＢＡＰアドレスが設定されることと、
    　前記中継ノードのＢＡＰレイヤが、パケットを受信することと、
    　前記ＢＡＰレイヤが、前記パケットの流入バックホールＲＬＣチャネルと対応付けられる前記トポロジにおける前記中継ノードのＢＡＰアドレスが、前記パケットのヘッダに含まれる宛先ＢＡＰアドレスと一致する場合、前記パケットを上位レイヤへ出力することと、を、有する
    　通信制御方法。
  2. 　セルラ通信システムで用いる通信制御方法であって、
    　中継ノードが、第１ドナーノードとの接続又は第１上位ノードとの接続において、バックホールリンクの無線リンク障害を検出することと、
    　前記中継ノードが、第２ドナーノード又は第２上位ノードに対して、ＲＲＣ再確立又はＦ１セットアップを実施した際に、前記第１ドナーノードとの通信を継続することを示す情報を通知することと、を有し、
    　前記第１上位ノードは、前記第１ドナーノードが管理するノードであって、前記中継ノードの上位ノードであり、
    　前記第２上位ノードは、前記第２ドナーノードが管理するノードであって、前記中継ノードの上位ノードである、
    　通信制御方法。
  3. 　前記情報は、前記中継ノードがＣＵ間ルーティング能力を有していることを示す情報である、
    　請求項２記載の通信制御方法。
  4. 　更に、前記第２ドナーノードが、前記中継ノードに対して、ＣＵ間リルーティング用の通信路を設定することを有する、
    　通信制御方法。
  5. 　更に、前記ＢＡＰレイヤが、前記ＩＡＢノードに滞留するパケットのヘッダに含まれるルーティングＩＤと一致するエントリがルーティングテーブルに無く、かつ、当該パケットのヘッダに含まれる宛先と一致するエントリが前記ルーティングテーブルに無い場合、前記リルーティング用の通信路へ前記パケットを送信することを有する、
    　請求項４記載の通信制御方法。
  6. 　更に、前記中継ノードが、前記第１ドナーノードとのＦ１接続又は前記第１上位ノードとのＦ１接続が解放された場合、前記ＣＵ間リルーティング用の通信路の設定を破棄することを有する、
    　請求項４記載の通信制御方法。
  7. 　セルラ通信システムで用いる中継ノードであって、
    　ドナーノードから、各トポロジにおける当該中継ノードのＢＡＰアドレスが設定される処理と、
    　前記中継ノードのＢＡＰレイヤが、パケットを受信する処理と、
    　前記ＢＡＰレイヤが、前記パケットの流入バックホールＲＬＣチャネルと対応付けられる前記トポロジにおける前記中継ノードのＢＡＰアドレスが、前記パケットのヘッダに含まれる宛先ＢＡＰアドレスと一致する場合、前記パケットを上位レイヤへ出力する処理と、を実行するプロセッサを備える
    　中継ノード。
  8. 　セルラ通信システムで用いる中継ノードであって、
    　第１ドナーノードとの接続又は第１上位ノードとの接続において、バックホールリンクの無線リンク障害を検出する処理と、
    　第２ドナーノード又は第２上位ノードに対して、ＲＲＣ再確立又はＦ１セットアップを実施した際に、前記第１ドナーノードとの通信を継続することを示す情報を通知する処理と、を実行するプロセッサを備え、
    　前記第１上位ノードは、前記第１ドナーノードが管理するノードであって、前記中継ノードの上位ノードであり、
    　前記第２上位ノードは、前記第２ドナーノードが管理するノードであって、前記中継ノードの上位ノードである、
    　中継ノード。
PCT/JP2022/038726 2021-10-19 2022-10-18 通信制御方法及び中継ノード WO2023068256A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2023554695A JPWO2023068256A1 (ja) 2021-10-19 2022-10-18

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202163257228P 2021-10-19 2021-10-19
US63/257,228 2021-10-19

Publications (1)

Publication Number Publication Date
WO2023068256A1 true WO2023068256A1 (ja) 2023-04-27

Family

ID=86059110

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/038726 WO2023068256A1 (ja) 2021-10-19 2022-10-18 通信制御方法及び中継ノード

Country Status (2)

Country Link
JP (1) JPWO2023068256A1 (ja)
WO (1) WO2023068256A1 (ja)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021062803A1 (zh) * 2019-09-30 2021-04-08 华为技术有限公司 一种数据包传输方法及装置

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021062803A1 (zh) * 2019-09-30 2021-04-08 华为技术有限公司 一种数据包传输方法及装置

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
CANON RESEARCH CENTRE FRANCE: "Discussion on inter-donor DU local re-routing", 3GPP TSG RAN WG2 #115-E, R2-2107114, 2 August 2021 (2021-08-02), XP052044142 *
NOKIA, NOKIA SHANGHAI BELL: "discussion on Inter-CU topology redundancy", 3GPP TSG RAN WG3 #113-E, R3-213532, 6 August 2021 (2021-08-06), XP052035345 *
SAMSUNG: "Discussion on inter-donor-DU re-routing", 3GPP TSG RAN WG3 #112-E, R3-211944, 7 May 2021 (2021-05-07), XP052002193 *

Also Published As

Publication number Publication date
JPWO2023068256A1 (ja) 2023-04-27

Similar Documents

Publication Publication Date Title
WO2019214747A1 (zh) 一种配置方法、数据传输方法和装置
JP5088091B2 (ja) 基地局装置、通信方法及び移動通信システム
WO2008040170A1 (fr) Système de communication par retransmission sans fil à bonds multiples, et procédé et dispositif de transmission de données sens desendant associés au système
US20230388894A1 (en) Method and apparatus for packet rerouting
CN116325849A (zh) 通信控制方法
GB2602802A (en) Management of radio link failure and deficiencies in integrated access backhauled networks
WO2023068256A1 (ja) 通信制御方法及び中継ノード
WO2023068255A1 (ja) 通信制御方法及び境界ｉａｂノード
WO2023068257A1 (ja) 通信制御方法
JP7483864B2 (ja) 通信制御方法、中継ノード、移動通信システム、チップセット及びプログラム
WO2023046878A1 (en) Routing data in an integrated access and backhaul network
WO2023132284A1 (ja) 通信制御方法
WO2023149577A1 (ja) 通信制御方法
WO2023132285A1 (ja) 通信制御方法
WO2023132283A1 (ja) 通信制御方法
WO2023013604A1 (ja) 通信制御方法
WO2023068258A1 (ja) 通信制御方法
WO2022234846A1 (ja) 通信制御方法
US20230262516A1 (en) Communication control method
WO2023013603A1 (ja) 通信方法
WO2023068254A1 (ja) 通信制御方法及び中継ノード
US20240155461A1 (en) Communication control method
US20240056940A1 (en) Management of radio link failure and deficiencies in integrated access backhauled networks
US20240022965A1 (en) Traffic transmission schemes in wireless communications
WO2022153989A1 (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: 22883560

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2023554695

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2022883560

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2022883560

Country of ref document: EP

Effective date: 20240418