WO2023132284A1 - 通信制御方法 - Google Patents

通信制御方法 Download PDF

Info

Publication number
WO2023132284A1
WO2023132284A1 PCT/JP2022/047872 JP2022047872W WO2023132284A1 WO 2023132284 A1 WO2023132284 A1 WO 2023132284A1 JP 2022047872 W JP2022047872 W JP 2022047872W WO 2023132284 A1 WO2023132284 A1 WO 2023132284A1
Authority
WO
WIPO (PCT)
Prior art keywords
routing
header
topology
node
iab
Prior art date
Application number
PCT/JP2022/047872
Other languages
English (en)
French (fr)
Inventor
真人 藤代
ヘンリー チャン
Original Assignee
京セラ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 京セラ株式会社 filed Critical 京セラ株式会社
Publication of WO2023132284A1 publication Critical patent/WO2023132284A1/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
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/22—Communication route or path selection, e.g. power-based or shortest path routing using selective relaying for reaching a BTS [Base Transceiver Station] or an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H04W72/044—Wireless resource allocation based on the type of the allocated resource
    • H04W72/0457—Variable allocation of band or rate

Definitions

  • the present disclosure relates to a communication control method used in a cellular communication system.
  • IAB Integrated Access and Backhaul nodes
  • a communication control method is a communication control method used in a cellular communication system.
  • the communication control method comprises receiving, from the network, configuration information about incoming links by the border relay node. Further, the communication control method includes identifying a topology to which the incoming link corresponds based on the border relay node and the setting information. Further, in the communication control method, when the topology to which the inflow link corresponds is a predetermined topology, the border relay node determines whether the packet flowing in from the inflow link is based on the header rewriting setting information received from the network. header rewrite processing.
  • a communication control method is a communication control method used in a cellular communication system.
  • the communication control method has a border relay node receiving configuration information indicating correspondence between a topology and a routing ID from a network. Further, the communication control method includes determining, by the border relay node, a routing ID linked to a topology of a packet transmission destination based on setting information received from a network. Further, the communication control method has the edge relay node transmitting the packet including the routing ID in a header.
  • a border relay node has a receiving unit that receives setting information about incoming links from the network. Also, the border relay node has a control unit that identifies a topology to which the inflow link corresponds, based on the setting information. Here, when the topology to which the inflow link corresponds is a predetermined topology, the control unit performs header rewriting processing on packets flowing in from the inflow link based on header rewriting setting information received from the network. I do.
  • a processor is a processor that controls a border relay node.
  • the processor performs the process of receiving configuration information about incoming links from a network. Also, the processor executes a process of identifying a topology to which the inflow link corresponds, based on the setting information. Further, when the topology to which the inflow link corresponds is a predetermined topology, the processor performs header rewriting processing on packets flowing in from the inflow link based on header rewrite setting information received from the network. process and perform.
  • a boundary relay node includes a receiving unit that receives setting information indicating correspondence between topology and routing ID from the network. Also, the border relay node has a control unit that determines a routing ID linked to the topology of the packet transmission destination based on the setting information received from the network. Also, the edge relay node includes a transmission unit that transmits the packet including the routing ID in a header.
  • a processor is a processor that controls a border relay node.
  • the processor executes a process of receiving configuration information indicating correspondence between topology and routing ID from the network. Also, the processor determines a routing ID associated with the topology of the packet transmission destination based on the setting information received from the network. Also, the processor executes a process of transmitting the packet including the routing ID in a header.
  • a communication control method is a communication control method used in a cellular communication system.
  • the communication control method comprises the step of a donor node sending a message regarding routing configuration to relay nodes in the topology. Further, the communication control method has a step of performing a first process in response to reception of the message by the relay node.
  • a communication control method is a communication control method used in a cellular communication system.
  • the communication control method has a step of sending designation information designating a downstream link from the donor node to the border relay node. Further, the communication control method has a step of performing a header rewriting process on a packet received from a downstream link in accordance with designation information by the boundary relay node.
  • a communication control method is a communication control method used in a cellular communication system.
  • the communication control method has a step of setting a first header rewriting table having first classification information and a second header rewriting table having second classification information for a border relay node by a donor node. Further, the communication control method has a step in which the boundary relay node performs header rewrite processing on the packet using at least one of the first header rewrite table and the second header rewrite table.
  • a communication control method is a communication control method used in a cellular communication system.
  • the communication control method includes the step of setting uplink traffic mapping settings including a topology of packet destinations for a border relay node by a donor node. Further, the communication control method has a step of selecting a routing ID linked to a topology based on an upstream traffic mapping setting by a border relay node. Further, the communication control method has a step of transmitting the packet including a routing ID in a header by the border relay node.
  • 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 is a diagram showing a configuration example between nodes according to the first embodiment.
  • FIG. 10 is a diagram showing an operation example of option D1 according to the first embodiment.
  • FIG. 11 is a diagram showing an operation example of option D2 according to the first embodiment.
  • FIG. 12 is a diagram showing an operation example of option U1 according to the first embodiment.
  • FIG. 13 is a diagram showing an operation example of option U2 according to the first embodiment.
  • FIG. 14 is a diagram illustrating an operation example of option C2 according to the first embodiment.
  • FIG. 15 is a diagram showing an example of a border IAB node according to the second embodiment.
  • FIG. 16 is a diagram showing an operation example according to the second embodiment.
  • FIG. 17 is a diagram showing a configuration example of a boundary IAB node according to the third embodiment.
  • FIG. 18 is a diagram showing a first operation example according to the third embodiment.
  • FIG. 19 is a diagram showing a second operation example according to the third embodiment.
  • FIG. 20 is a diagram showing an operation example according to the fourth embodiment.
  • FIG. 21 is a diagram showing an example of a boundary IAB node according to the fifth embodiment.
  • FIG. 22 is a diagram showing an operation example according to the fifth embodiment.
  • FIG. 23 is a diagram representing a scenario for routing and rerouting.
  • FIG. 24 is a diagram representing a routing table applicable in an inter-CU scenario.
  • FIG. 25 is a diagram showing an overview of routing/reroute enhancements for all scenarios.
  • 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. Note that 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. Note that 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. Note that the control unit 120 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 processing according to the first embodiment will be described.
  • the BAP layer of the IAB node 300 performs routing processing. Specifically, for example, the following processing is performed.
  • the BAP layer routes BAP packets based on the BAP routing ID included in the BAP header.
  • the BAP header is added when the packet arrives from higher layers and removed when it reaches the destination node.
  • the setting of the BAP routing ID or routing table is set by the CU of donor node 200 .
  • a BAP routing ID is composed of a BAP address (or Destination or destination BAP address) and a BAP path ID (or route identifier).
  • a BAP address indicates a destination node.
  • the BAP path ID indicates the routing path followed by the packet to the destination.
  • Each IAB node 300 on the route of the packet determines whether the packet has reached its destination, that is, whether it matches the BAP address of the IAB node 300 . Specifically, it is performed based on the BAP address of the BAP routing ID included in the BAP header.
  • the IAB node 300 if the packet has not reached the destination (destination BAP address) (that is, the BAP address (Destination) included in the BAP header does not match the BAP address of its own IAB node), Determine the next hop BAP address (or backhaul link or egress link) based on the included BAP routing ID and routing configuration.
  • the process of controlling the destination of packets is sometimes referred to as, for example, the routing process.
  • the BAP routing ID may be referred to as the routing ID
  • the BAP path ID may be referred to as the path ID
  • the IAB donor DU and the IAB donor CU are sometimes referred to as the DU of the donor node 200 and the CU of the donor node 200, respectively.
  • the BAP path ID included in the routing ID may be referred to as path ID
  • the BAP address included in the routing ID may be referred to as Destination.
  • the access IAB node the node that first processes the packet received from the UE 100 and the last node that processes the packet sent to the UE 100
  • the routing configuration is changed in the intermediate IAB node 300, how the packet is processed may be an issue.
  • the Destination (Destination of the routing ID included in the BAP header of the packet) to which the packet should be originally reached is different (that is, a different route). May route packets. Such routing errors also cause packet loss.
  • the donor node 200 transmits a routing setting change start message and a routing setting change completion message to the access IAB node 300-A. Based on the two messages, the access IAB node 300-A guesses the packet that has already reached the donor node 200, and retransmits the previously transmitted packet based on the result of the guess.
  • a donor node eg, donor node 200
  • a relay node eg, IAB node 300
  • the relay node performs the first process in response to receiving the message.
  • the donor node sends a routing setting change start message to an access relay node (for example, an access IAB node) in response to starting a change of routing settings for a relay node in the topology. 300-A).
  • the process of sending the message includes a process of sending a routing setting change completion message to the access relay node in response to the donor node having completed changing the routing settings for the relay nodes in the topology.
  • the first process includes a process in which the access relay node retransmits a packet transmitted in the upstream direction in the past for a certain period based on the routing setting change start message and the routing setting change completion message.
  • FIG. 9 is a diagram showing a configuration example between nodes according to the first embodiment. As shown in FIG. 9, donor node 200 has sent a routing configuration change start message and a routing configuration change complete message to access IAB node 300-A.
  • the access IAB node 300-A can compensate for (or suppress) the packet loss by retransmitting the packet in which the packet loss is expected.
  • the first operation example will be described separately for the downstream direction and the upstream direction. Also, in the first operation example, there are two options in the downstream direction (option D1 and option D2). In the first operation example, there are also two options for the upstream direction (option U1 and option U2).
  • FIG. 10 is a diagram showing an operation example of option D1 in the downstream direction according to the first embodiment.
  • the donor node 200 starts processing in step S10.
  • step S11 the donor node 200 holds packets that have already been transmitted in the downstream direction in a memory or the like.
  • step S12 after the donor node 200 changes the routing settings of (all) IAB nodes 300 in the topology, packets having headers according to the routing settings before the change (i.e., transmitted packets) are sent to the access IAB node. Guess whether has been reached. For example, the donor node 200 calculates the number of packets reaching the access IAB node per unit time from the past transmission history, and based on the time from when the routing setting was changed to the current time, the number of packets reaching the access IAB node 300-A. Guess the number of packets sent. Note that the CU of the donor node 200 may change the routing setting for the IAB-DU of the access IAB node 300-A using a message according to the F1AP protocol.
  • the donor node 200 attaches headers according to the changed routing settings to packets transmitted in the past for a certain period of time, and then retransmits the packets (blind retransmission). For example, the donor node 200 calculates how far back in the past based on the estimated number of arrived packets and the number of transmitted packets transmitted from the time the routing setting was changed until the current time. Packets transmitted in the past period may be identified.
  • the donor node 200 ends a series of processes.
  • FIG. 11 is a diagram showing an operation example of option D2 in the downstream direction according to the first embodiment.
  • the donor node 200 starts processing in step S20.
  • step S21 the donor node 200 holds the transmitted packet in the memory or the like in the downstream direction.
  • the donor node 200 identifies the likely affected UEs 100 after changing the routing settings for (all) IAB nodes 300 in the topology. For example, the donor node 200 may identify the UE 100 in RRC connected state with the donor node 200 as the UE 100 likely to be affected.
  • step S23 the donor node 200 instructs the UE 100 to transmit a PDCP Status Report.
  • the CU of the donor node 200 transmits the instruction to the UE 100 using an RRC message.
  • the donor node 200 receives the PDCP status report from the UE 100 and identifies packets that have not yet reached the UE 100 based on the FMC (First Missing Count) included in the report.
  • the donor node 200 adds a header according to the changed routing setting to the packet, and then retransmits the packet.
  • the CU of donor node 200 may receive the PDCP status report from UE 100 using an RRC message.
  • the donor node 200 then ends the series of processes.
  • FIG. 12 is a diagram showing an operation example of the upstream direction option U1 according to the first embodiment.
  • step S30 the access IAB node 300-A starts processing.
  • step S31 the access IAB node 300-A holds in memory or the like packets that have already been transmitted in the upstream direction.
  • step S32 when the donor node 200 starts changing the routing settings for the IAB nodes 300 related to the access IAB node 300-A in the topology, the donor node 200 sends a routing setting change start message to the access IAB node 300-A.
  • the routing setting change start message is a message indicating that the routing setting change has started.
  • the CU of donor node 200 may send the message as an F1AP message to the IAB-DU of access IAB node 300-A.
  • the CU of donor node 200 may send the message as an RRC message to the IAB-MT of access IAB node 300-A.
  • step S33 when the donor node 200 completes the routing setting change to the IAB node 300 related to the access IAB node 300-A in the topology, the donor node 200 sends a routing setting change completion message to the access IAB node 300-A.
  • the routing setting change completion message is a message indicating that the routing setting has been changed.
  • the message may be sent as an F1AP message or an RRC message.
  • the routing setting change completion message may include the time required to change the routing setting. The time may be represented by the time from the routing setting start time to the routing setting end time.
  • the access IAB node 300-A guesses which of the transmitted packets has reached the donor node 200 based on the routing setting change start message and the routing setting change complete message.
  • the access IAB node 300-A may infer the arrived packet as follows. That is, the access IAB node 300-A calculates the change time required to change the routing setting from the reception time of the routing setting change start message and the reception time of the routing setting change completion message. Also, the access IAB node 300-A calculates the number of packets reaching the donor node 200 per unit time from the past history. Then, the access IAB node 300-A guesses arrived packets based on the change time and the number of packets.
  • the access IAB node 300-A retransmits (or blind retransmits) a packet that was transmitted in the past for a certain period of time after adding a header according to the changed routing settings.
  • the access IAB node 300-A may retransmit the packets excluding the presumed arrived packets from the transmitted packets held in the memory as the packets transmitted in the past for a certain period of time.
  • the access IAB node 300-A may set the change time required for changing the routing settings to a certain period of time, and resend the transmitted packets for that period of time as packets that were transmitted in the past for the certain period of time. .
  • packets transmitted in the upstream direction in the past for a certain period of time will be retransmitted.
  • step S36 the donor node 200 ends the series of processes.
  • FIG. 13 is a diagram showing an operation example of the upstream direction option U2 according to the first embodiment.
  • step S40 the UE 100 starts processing.
  • step S41 the UE 100 holds the transmitted PDCP Data SDU (Service Data Unit) in memory or the like. At this time, the UE 100 sets a longer than normal Discard Timer value. This is to prevent PDCP SDUs from being discarded due to timer expiration, taking into consideration the arrival delay of multi-hop transfer from UE 100 to donor node 200 .
  • PDCP Data SDU Service Data Unit
  • the donor node 200 changes routing settings for (all) IAB nodes 300 in the topology, and then identifies UEs 100 that are likely to be affected.
  • the donor node 200 may identify the UE 100 that is in the RRC connected state with respect to the donor node 200 as the UE 100 likely to be affected.
  • step S43 the donor node 200 transmits a PDCP status report to the UE 100 concerned. Note that the UE 100 discards the arrived packet (PDCP Data SDU) according to the PDCP status report.
  • step S44 the donor node 200 triggers PDCP data recovery.
  • UE 100 retransmits the PDCP Data SDU it holds to access IAB node 300-A.
  • the access IAB node 300-A adds a header according to the changed routing setting to the packet and transmits the packet to the next hop node.
  • the donor node 200 ends a series of processes.
  • packet loss is compensated for by retransmitting packets that have been transmitted in the past for a certain period of time.
  • the first operation example does not discuss how to deal with the routing miss itself. Therefore, useless packets due to routing errors may be transferred within the topology, resulting in useless resource consumption.
  • each IAB node 300 the routing process is suspended from before the routing setting is changed until the routing setting is changed.
  • the donor node eg donor node 200
  • the relay node stops the routing process and retains the received packet in memory according to the routing stop instruction message.
  • the donor node changes the routing setting to the relay node, and transmits mapping information between the routing ID before the routing setting change and the routing ID after the routing setting change.
  • the relay node resumes routing processing, rewrites the header of the packet held in memory according to the mapping information, and transmits the packet.
  • each IAB node 300 stops routing processing and retains packets in memory before and after the routing setting is changed. This prevents packets due to routing errors from being forwarded within the topology.
  • each IAB node 300 rewrites the routing ID contained in the header of the packet held in the memory by using the mapping information before and after the routing setting change. As a result, the packet rewritten with the correct routing ID after the routing setting change is transferred within the topology. Therefore, it is possible to prevent routing errors.
  • the second operation example according to the first embodiment has two options (option C1 and option C2).
  • Option C1 will be described first. Both options are feasible for packet transmission in both the downstream and upstream directions.
  • the donor node 200 changes the path ID of each routing ID so as not to change the Destination before and after the routing setting is changed.
  • the IAB node 300 receives packets according to the routing settings before the routing settings change.
  • the IAB node 300 performs local re-routing to the Destination.
  • the IAB node 300 can perform local rerouting to the correct Destination. Local rerouting is the routing of packets to alternative paths without regard to routing settings.
  • 1024 Destinations (10 bits) can be set, but when the number of DUs of the IAB node 300 and the donor node 200 in the topology approaches 1024, the same Destination may be used repeatedly. In this case, there is the possibility of a routing miss in option C1.
  • FIG. 14 is a diagram illustrating an operation example of option C2 according to the first embodiment.
  • the donor node 200 starts processing in step S50.
  • step S51 the donor node 200 instructs (all or part of) the IAB nodes 300 in the topology to stop the routing process before changing the routing settings for the IAB nodes 300 in the topology.
  • the stop routing indication message may be sent as an F1AP message or an RRC message.
  • step S52 the IAB node 300 stops routing processing in response to receiving the routing stop instruction message, and holds the received packet (BAP Data PDU) in memory or the like.
  • the donor node 200 changes the routing settings for (all or part of) the IAB nodes 300 in the topology.
  • the CU of the donor node 200 may change the routing settings by sending the changed routing settings to the IAB-DU of the IAB node 300 using the F1AP message.
  • the donor node 200 transmits the mapping information indicating the correspondence between the routing ID before the routing setting change and the routing ID after the routing setting change to (all or part of) the IAB nodes 300 in the topology.
  • the mapping information may be sent by F1AP messages or RRC messages. In the IAB node 300, reception of this mapping information may trigger the restart of the routing process.
  • the donor node 200 may send a resume routing indication message to (all or part of) the IAB nodes 300 in the topology.
  • the Routing Resume Indication message may also be sent as an F1AP message or an RRC message.
  • the IAB node 300 resumes the routing process in response to receiving the routing resume instruction message.
  • the IAB node 300 restarts the routing process and rewrites the (BAP) header of the packet (BAP Data PDU) held in memory according to the mapping information.
  • the BAP layer of the IAB node 300 (or the BAP entity; hereinafter, the BAP layer and the BAP entity may be used without distinction), according to the mapping information, the routing ID included in the header (routing setting routing ID before change) to the routing ID after the routing setting change.
  • the IAB node 300 After receiving the mapping information (or after resuming the routing process), the IAB node 300 does not rewrite the header of a newly received packet using the mapping information.
  • the IAB node 300 may discard the mapping information after rewriting the headers of all packets held in the memory using the mapping information.
  • step S56 the IAB node 300 performs routing processing on the packet using the changed routing settings, and transmits the packet to the next hop node.
  • step S57 a series of processing ends.
  • the IAB node 300 has IAB nodes belonging to multiple topologies. Such an IAB node is called a boundary IAB-node.
  • FIG. 15 is a diagram showing an example of the border IAB node 300-B according to the second embodiment.
  • the border IAB node 300-B has a topology configured by CU#1 (200-C1) of donor node 200 and CU#2 (200-C2) of another donor node. belong to two topologies.
  • the topology configured by CU#1 may be called a main topology
  • the topology configured by CU#2 may be called a sub-topology.
  • Inter-CU routing is, for example, routing packets from a first topology managed by a first CU to a second topology managed by a second CU.
  • the border IAB node 300-B carries out a process of causing packets that have flowed in from the main topology to flow out to the sub-topology.
  • the BAP layer of the border IAB node 300-B uses a header rewriting table (Header Rewriting Configuration) to rewrite the header of the packet (for example, by rewriting the routing ID, Destination is rewritten from CU#1 (200-C1) to CU#2 (200-C2)) to transfer packets.
  • the header rewriting table in the upstream direction is managed by CU#1 (200-C) on the main topology side.
  • the boundary IAB node 300-B performs processing for causing packets that have flowed in from the sub-topology to flow out to the main topology.
  • the BAP layer of the boundary IAB node 300-B uses the header rewriting table to rewrite the header of the packet (for example, by rewriting the routing ID, the Destination of the subtopology (rewriting from the access IAB node to the access IAB node of the main topology) to transfer the packet.
  • the downstream header rewrite table is managed by CU#2 (200-C2) on the sub-topology side.
  • the boundary IAB node 300-B can refer to the header rewriting table and determine whether or not to rewrite the header based on whether or not there is an entry for rewriting the header in the upstream direction.
  • the header rewriting table in the downstream direction is managed by the sub-topology (CU#2 (200-C2)) as described above.
  • the routing ID of the sub-topology is managed by CU#2 (200-C2)
  • the routing ID of the main topology is managed by CU#1 (200-C1). Therefore, the routing ID in the main topology and the routing ID in the subtopology may match.
  • the border IAB node 300-B rewrites the header without distinguishing between the routing ID on the main topology side and the routing ID on the sub-topology side. Therefore, the border IAB node 300-B may erroneously cause packets to flow out to the sub-topology side during routing between CUs in the downstream direction.
  • the SCG side does not necessarily belong to the subtopology. If the MCG (Master Cell Group) side is a sub-topology, downstream packets that flow in from the sub-topology will not be subjected to header rewriting. Conversely, packets that flow in from the SCG on the main topology side are subject to header rewriting.
  • MCG Master Cell Group
  • the donor node 200 designates the link (or the parent node for the boundary IAB node 300-B) whose header is to be rewritten in the downstream direction to the boundary IAB node 300-B.
  • the donor node eg, donor node 200
  • the border relay node eg, border IAB node 300-B
  • the border relay node performs header rewrite processing on packets that flow in from the downstream link, according to the specified information.
  • the boundary IAB node 300-B can identify the packet whose header is to be rewritten, so that the header rewriting process in the downstream direction can be performed appropriately.
  • FIG. 16 is a diagram showing an operation example according to the second embodiment.
  • the donor node 200 starts processing in step S60.
  • the donor node 200 transmits, to the border IAB node 300-B, designation information designating the downstream link (or ingress link) whose header is to be rewritten.
  • the designation information includes inflow links that require header rewriting (or are targets of header rewriting).
  • the designation information may include an MCG or SCG that requires header rewriting.
  • the designation information may also include the BAP address of the parent node or the cell ID of the parent node that requires header rewriting.
  • the designation information may include links corresponding to the topology.
  • the designation information may include information indicating that the main topology is MCG and the sub-topology is SCG, or that the main topology is SCG and the sub-topology is MCG. In this case, the side specified as the sub-topology is the link that requires header rewriting.
  • the designation information may be transmitted by being included in the F1AP message or the RRC message.
  • step S62 the BAP layer of the boundary IAB node 300-B identifies a packet to be rewritten from the packet that has flowed in from the downstream link specified as the specified information according to the specified information, and specifies the packet to be rewritten. Perform rewrite processing.
  • step S63 a series of processing ends.
  • the BAP layer may perform processing to identify the inflow direction for each packet. That is, in the BAP layer, after specifying the inflow direction for each packet, header rewriting processing is performed using either the UL header rewriting table or the DL header rewriting table.
  • the BAP layer exchanges information with other layers in order to specify the packet inflow direction, increasing dependence on other layers.
  • the header rewriting table used in inter-CU routing is classified into a table used on the IAB-MT side of the border IAB node 300-B and a table used on the IAB-DU side. make it
  • a donor node for example, donor node 200
  • a border relay node for example, border IAB node 300-B
  • the border relay node uses at least one of the first header rewrite table and the second header rewrite table to perform header rewrite processing on the packet.
  • the first header rewrite table is a header rewrite table for first inter-CU routing used in the user equipment functional unit (IAB-MT) of the border relay node
  • the second header rewrite table is a header rewrite table for the border relay node.
  • 2 is a header rewriting table for routing between the second CUs used in the base station functional unit (IAB-DU) of the second CU.
  • the user device functional unit refers to the first inter-CU routing header rewriting table to rewrite the header of the packet, and the base station functional unit rewrites the second inter-CU routing header. This includes rewriting the header of the packet with reference to the rewriting table.
  • the header rewrite tables are classified into tables used on the IAB-MT side and tables used on the IAB-DU side, and classified into UL direction and DL direction. not Therefore, it is possible to suppress an increase in processing due to specifying the DL direction or the UL direction for each packet. In addition, it is possible to prevent the BAP layer from becoming more dependent on other layers. Furthermore, since each of the IAB-MT and IAB-DU only has to perform the header rewriting process using the set header rewriting table, it is possible to appropriately perform the header rewriting process.
  • UL and DL may be used with the following meanings, for example. That is, it can be “UL” when a packet is forwarded from the first topology to the second topology. Also, when a packet is transferred from the second topology to the first topology, it can be "DL”. Note that packets transferred from the first topology to the first topology (that is, within the same topology) are not subject to header rewriting.
  • FIG. 17 is a diagram showing a configuration example of the border IAB node 300-B according to the third embodiment.
  • the IAB-MT (300-MT) has a header rewriting table 350-MT for routing between CUs.
  • the header rewriting table 350-MT is a table for rewriting the header of packets in the UL direction.
  • the IAB-DU (300-DU) has a header rewriting table 350-DU for routing between CUs.
  • the header rewrite table 350-DU is a header rewrite table for packets in the DL direction.
  • the header rewriting table 350-MT on the IAB-MT (300-MT) side is referred to as the MT rewriting table 350-MT.
  • DU) side header rewrite table 350-DU may be referred to as DU rewrite table 350-DU.
  • FIG. 18 is a diagram showing a first operation example according to the third embodiment.
  • the donor node 200 starts processing in step S70.
  • the donor node 200 sets, for the border IAB node 300-B, a rewriting table for inter-CU routing having different classification information for DU and MT.
  • donor node 200 sets MT rewrite table 350-MT having first classification information and DU rewrite table 350-DU having second classification information in border IAB node 300-B.
  • the classification information may be information for DU and MT for two rewriting tables. Classification information is associated with each rewriting table. Also, the classification information may be a name that distinguishes two rewriting tables. For example, "BAP Header Rewriting Configuration for IAB-DU” and "BAP Header Rewriting Configuration for IAB-MT". Furthermore, the rewriting table itself may be one table, and each entry (for example, an entry consisting of an old routing ID and a new routing ID) may be associated with classification information for DU and MT.
  • each rewrite table having classification information may be transmitted using, for example, an F1AP message or an RRC message.
  • step S72 the border IAB node 300-B applies the setting. Since classification information exists in the rewrite table, the boundary IAB node 300-B sets the set rewrite table to which position (IAB-MT (300-MT) or IAB-DU (300-DU)). You can easily decide what to do.
  • the BAP layer of the border IAB node 300-B receives the packet (BAP Data PDU) from the upper layer or the previous hop node, and identifies whether the received packet is subject to header rewriting.
  • the BAP transmission unit (BAP Tx unit) of the IAB-MT refers to the header rewriting table 350-MT set in the IAB-MT (300-MT), and the routing ID included in the BAP header of the received packet is If it matches the old routing ID of the header rewriting table 350-MT, it may be identified as a header rewriting target.
  • the BAP transmission unit of the IAB-DU (300-DU) also refers to the header rewriting table 350-DU set in the IAB-DU (300-DU), and the routing included in the BAP header of the received packet If the ID matches the old routing ID of the header rewriting table 350-DU, the packet is identified as subject to header rewriting, and if there is no match, the packet is identified as not subject to header rewriting. may
  • step S74 the BAP layer of the boundary IAB node 300-B performs header rewriting processing on the packet whose header is to be rewritten.
  • the BAP transmission unit of the IAB-MT (300-MT) refers to the MT rewrite table 350-MT (eg, header rewrite table for first inter-CU routing) set in the IAB-MT (300-MT). Then, the BAP header of the packet is rewritten from the old routing ID to the new routing ID.
  • the BAP transmission unit of the IAB-DU converts the DU rewrite table 350-DU (for example, the second inter-CU routing header rewrite table) set in the IAB-DU (300-DU) to By referring to it, the BAP header of the packet is rewritten from the old routing ID to the new routing ID.
  • step S75 the BAP layer of the boundary IAB node 300-B performs routing processing according to the routing settings.
  • step S76 the border IAB node 300-B transmits the packet to the next hop node.
  • step S77 the series of processes ends.
  • rerouting may occur. Rerouting is performed, for example, when routing processing is performed on a received packet using routing settings, but the packet cannot be sent for some reason. Rerouting occurs after the routing process.
  • Such rerouting may occur across topologies.
  • a packet that has flowed in from the first topology was routed to the first topology, but could not be sent, so the packet is rerouted to the second topology.
  • the boundary IAB node 300-B can perform rerouting to the second topology by rewriting the header.
  • the border IAB node 300-B changes the routing ID by header rewrite processing, thereby changing the destination from CU#1 (200-C1) to CU#2 (200-C2). be done.
  • Such rerouting across CUs is called inter-CU rerouting.
  • inter-donor-DU rerouting when CU#1 is DU#1 and CU#2 is DU#2, the routing ID is changed by the header rewriting process, so that Destination is changed from DU#1 to DU#2. may be changed to Such rerouting between DUs is called inter-donor-DU rerouting.
  • Inter-CU re-routing and inter-DU re-routing may be collectively referred to as "header rewriting-based re-routing".
  • Header rewriting based rerouting may include at least one of inter-CU rerouting and inter-DU rerouting.
  • Header rewriting-based rerouting is performed when a packet cannot be sent even though routing processing has been performed. Therefore, header rewriting based rerouting is performed after the routing process.
  • inter-CU routing the received packet is sent to a different topology by performing routing processing after performing header rewriting processing. Therefore, inter-CU routing is performed before routing processing.
  • the boundary IAB node 300-B may not know whether the routing ID (old routing ID) in the table should be processed before the routing process or after the routing process. Therefore, the boundary IAB node 300-B may not be able to appropriately perform inter-CU routing and header rewriting-based rerouting.
  • the first header rewriting table is a header rewriting table for inter-CU routing
  • the second header rewriting table is a header rewriting table for header rewriting base rerouting.
  • header rewriting processing can be performed while distinguishing between the two tables.
  • a header rewriting table for routing between CUs is used, and when performing header rewriting base rerouting processing after routing processing, header rewriting base A header rewriting table for rerouting can be used. Therefore, the border IAB node 300-B can appropriately perform inter-CU routing and header rewriting-based rerouting.
  • the header rewrite table for routing between CUs may be referred to as a "routing header rewrite table”.
  • the header rewriting table for header rewriting base rerouting may be referred to as a "rerouting header rewriting table”.
  • FIG. 19 is a diagram showing a second operation example according to the third embodiment.
  • the donor node 200 starts processing in step S80.
  • the donor node 200 sets the routing header rewriting table and the rerouting header rewriting table for the border IAB node 300-B so that each table has different classification information. For example, donor node 200 sets a routing header rewriting table with first classification information and a rerouting header rewriting table with second classification information in border IAB node 300-B.
  • the classification information may be information for routing (or inter-CU routing) and re-routing (or header rewriting-based rerouting) for two rewriting tables.
  • the classification information is associated with each rewriting table.
  • the classification information may be a name that distinguishes two rewriting tables. For example, it may be "BAP Header Rewriting Configuration for routing" and "BAP Header Rewriting Configuration for re-routing".
  • the rewriting table itself may be one table, and each entry (for example, an entry consisting of an old routing ID and a new routing ID) may be associated with classification information for routing and re-routing.
  • each rewrite table having classification information may be transmitted using, for example, an F1AP message or an RRC message.
  • step S82 the border IAB node 300-B applies the setting.
  • step S83 the BAP layer of the border IAB node 300-B receives a packet (BAP Data PDU) from the upper layer or previous hop node.
  • the BAP layer may perform header rewriting processing for inter-CU routing on the packet.
  • the BAP layer refers to the routing header rewrite table, and if there is an old routing ID that is the same as the routing ID of the packet, performs header rewrite processing for inter-CU routing. Since the routing header rewrite table contains the classification information, the BAP layer can easily identify the table. However, at this timing, the BAP layer does not refer to the header rewriting table for rerouting and does not perform header rewriting based rerouting.
  • step S85 the BAP layer performs routing processing and/or rerouting processing.
  • the rerouting process at this timing is the local rerouting process. That is, the BAP layer performs the routing process, but moves to step S85 again to perform the local rerouting process.
  • step S86 the BAP layer fails routing and/or rerouting.
  • next hop address (Next Hop BAP address) could not be selected under certain evaluation conditions.
  • the evaluation condition may be whether or not the Destination and the path ID match between the packet header and the routing table (routing configuration). Alternatively, the evaluation condition may be whether or not only the Destination matches between the header of the packet and the routing table.
  • the BAP layer performs header rewriting processing on the packet using the header rewriting table for rerouting.
  • the BAP layer may identify whether the packet is subject to header rewriting based rerouting. That is, the BAP layer may specify that the packet is subject to header rewriting-based rerouting if the old routing ID that matches the routing ID included in the BAP header of the packet is in the rerouting header rewriting table. On the other hand, the BAP layer may specify that header rewriting-based rerouting is not a target if there is no old routing ID that matches the routing ID included in the BAP header of the packet in the rerouting header rewriting table.
  • the BAP layer refers to the rerouting header rewriting table and rewrites the BAP header of the packet from the old routing ID to the new routing ID.
  • step S88 the BAP layer performs routing processing or header rewriting-based rerouting processing on the packet.
  • step S89 the border IAB node 300-B transmits the packet to the next hop node according to routing processing or header rewriting-based rerouting processing.
  • step S90 the series of processes ends.
  • the border IAB node 300-B rewrites the header of the packet by inter-CU routing, but fails in routing.
  • the border IAB node 300-B rewrites the header of the packet by inter-DU rerouting, but fails in routing again.
  • Both the header rewriting table used for inter-CU routing and the header rewriting table used for header rewriting-based rerouting assume that the old routing ID included in the entry is the routing ID before header rewriting.
  • the header of the packet will include the rewritten routing ID.
  • the border IAB node 300-B may not be able to appropriately perform inter-CU routing or header rewriting-based rerouting. be.
  • the boundary relay node eg, the boundary IAB node 300-B
  • the boundary relay node rewrites the header of the packet using the inter-CU routing header rewrite table, and then fails in routing. Then, the rewritten routing ID is returned to the routing ID before rewriting.
  • the border relay node rewrites the header of the packet using the rerouting header rewriting table and fails in routing
  • the rewritten routing ID is returned to the routing ID before rewriting.
  • the routing ID is returned to the original routing ID when the routing fails. can be done properly.
  • FIG. 20 is a diagram showing an operation example according to the fourth embodiment.
  • step S100 the BAP layer of the border IAB node 300-B starts processing.
  • the BAP layer receives a packet.
  • the BAP layer may perform header rewriting processing for inter-CU routing on the packet. If there is an old routing ID that matches the routing ID of the packet in the routing header rewriting table, the header is rewritten.
  • the BAP layer may record (or store) information indicating that the header rewriting process has been completed for inter-CU routing in a memory or the like. Alternatively, the BAP layer may record information indicating that the header has been rewritten in memory or the like.
  • the BAP layer fails to route the packet.
  • the BAP layer rewrites the header of inter-CU routing, and if the routing fails, returns the routing ID to the original old routing ID. Also, in this case, the BAP layer may discard (or treat as unprocessed) the rewritten information recorded in the memory or the like.
  • step S104 the BAP layer performs header rewriting processing of header rewriting-based rerouting on the packet.
  • the BAP layer may record, in a memory or the like, information indicating that any of the header rewriting processes for inter-CU rerouting, inter-DU rerouting, and header rewriting-based rerouting has been completed. .
  • the BAP layer may record information indicating that the header has been rewritten.
  • step S105 the BAP layer fails the header rewriting-based rerouting process.
  • step S106 the BAP layer restores (rewrites) the header of the packet rewritten in step S104 to the original routing ID (old routing ID). Also, in this case, the BAP layer may discard (or treat as unprocessed) the rewritten information recorded in the memory or the like.
  • the BAP layer returns the packet to a predetermined procedure such as routing processing.
  • step S108 a series of processing ends.
  • the header is restored to the original routing ID due to routing failure or rerouting failure after rewriting the header, but the original routing ID may be restored by restoring the packet.
  • step S101 when the BAP layer receives a packet, it stores a copy of the packet in memory.
  • step S103 if the routing fails, the BAP layer discards the packet (header rewritten) and obtains a copy of the packet from memory.
  • step S105 when the header rewriting-based rerouting process fails, the BAP layer discards the packet (header rewritten) and obtains a copy of the packet from the memory. As a result, the border IAB node 300-B can restore the original routing ID without rewriting the header.
  • inter-CU routing is mainly considered for user data.
  • inter-CU routing is also possible for F1-C (control signal) traffic.
  • the border IAB node 300-B uses the CP/UP separation function to encapsulate the F1-C packet in an RRC message, and by sending the RRC message in Split SRB1, It is possible to send F1-C packets to the first topology or to the second topology.
  • the boundary IAB node 300-B may also perform inter-CU routing for user data generated at its own node (that is, data received directly from the UE 100 by the boundary IAB node 300-B as an access IAB node). be done.
  • FIG. 21 is a diagram showing an example of the border IAB node 300-B according to the fifth embodiment.
  • the access IAB node creates a BAP header and transmits the packet toward the donor node 200.
  • an access IAB node creates a BAP header as follows.
  • the uplink traffic mapping configuration (Uplink Traffic to Routing ID Mapping Configuration) is set from the donor node 200 .
  • the upstream traffic mapping configuration includes a traffic type identifier and a BAP routing ID. Note that the uplink traffic mapping setting is transmitted from the donor node 200 using an F1AP message.
  • the BAP layer of the access IAB node When the BAP SDU received from the upper layer is FI-U traffic, the BAP layer of the access IAB node creates an entry containing the traffic type identifier corresponding to the Destination IP address of the BAP SDU and the TEID (Tunnel Endpoint Identifier) for upstream traffic Select from mapping settings. On the other hand, the BAP layer selects an entry containing the traffic type identifier of the BAP SDU from the upstream traffic mapping configuration if the BAP SDU is not F1-U traffic.
  • the BAP layer selects the routing ID (Destination and path ID) of the entry.
  • the BAP layer uses the selected routing ID to generate a BAP header, attaches the BAP header to the BAP SDU, and generates a BAP PDU.
  • the current uplink traffic mapping setting basically includes a set of a traffic type identifier and a BAP routing ID. If this one BAP routing ID is assigned to two topologies, if the BAP routing ID exists in the two topologies, the boundary IAB node 300-B should send the BAP PDU to which topology. I don't know. Therefore, the access IAB node may not be able to properly perform inter-CU routing.
  • the border IAB node 300-B which is also the access IAB node, selects a routing ID linked to the topology based on the uplink traffic mapping setting including information on the topology to which the routing ID is applied. An example will be described.
  • a donor node for example, donor node 200
  • sets upbound traffic mapping settings including packet transmission destination topology for border relay nodes for example, border IAB node 300-B.
  • the border relay node selects a topology-linked routing ID based on the upstream traffic mapping setting.
  • the border relay node sends a packet with a routing ID in the header.
  • the border IAB node 300-B which is also the access IAB node, can grasp which topology the routing ID is for, and can appropriately generate a packet for that topology. Therefore, the border IAB node 300-B, which is also the access IAB node, can appropriately perform inter-CU routing.
  • FIG. 22 is a diagram showing an operation example according to the fifth embodiment.
  • the donor node 200 starts processing in step S110.
  • the donor node 200 sets upstream traffic mapping settings for the border IAB node 300-B, which is also the access IAB node.
  • the upstream traffic mapping setting includes information on the topology to be applied (or the topology of the destination) in addition to the existing traffic type identifier and BAP routing ID. This information may hereinafter be referred to as topology information.
  • the topology information may be MCG or SCG. For example, it indicates that the packet transmission destination is MCG or SCG.
  • the topology information may also be the BAP address of border IAB node 300-B. That is, the BAP addresses of the border IAB node 300-B include the BAP address set from the first topology and the BAP address set from the second topology. By using the BAP address as the topology information, it is possible to identify whether the topology of the packet transmission destination is the first topology or the second topology.
  • the topology information may be represented by a topology terminating F1-APs or a topology not terminating F1-APs.
  • the bearer ID may be included in the uplink traffic mapping setting.
  • a bearer ID represents a packet transmission destination.
  • the BAP layer may select a destination associated with each bearer ID. In this way, the destination may be different for each bearer ID.
  • Topology information and bearer IDs may exist in each entry in the upstream traffic mapping configuration. Also, the topology information and the bearer ID may be set separately. For example, different (two) uplink traffic mapping settings for each topology may be notified to the border IAB node 300-B.
  • the BAP layer of the border IAB node 300-B receives the BAP SDU from the upper layer.
  • the BAP layer selects an entry corresponding to the BAP SDU from the upstream traffic mapping settings.
  • step S114 the BAP layer identifies the topology (or packet transmission destination) associated with the entry from the upstream traffic mapping settings.
  • step S115 the BAP layer selects the routing ID associated with the entry and/or topology.
  • the BAP layer uses the routing ID to generate a BAP header, attaches the generated BAP header to the BAP SDU, and generates a BAP PDU.
  • step S117 the BAP layer selects routing settings associated with the identified topology and performs routing processing.
  • step S118 the border IAB node 300-B transmits the packet to the next hop node.
  • step S119 the border IAB node 300-B terminates a series of processes.
  • 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.
  • circuits that execute each process performed by the UE 100 or the gNB 200 may be integrated, and at least part of the UE 100 or the gNB 200 may be configured as a semiconductor integrated circuit (chipset, SoC: System on a chip).
  • chipsset, SoC System on a chip
  • 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.
  • any 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, reference to a first and second element does not imply that only two elements can be employed therein or that the first element must precede the second element in any way.
  • articles are added by translation, such as a, an, and the in English these articles are used in plural unless the context clearly indicates otherwise. shall include things.
  • routing and rerouting need to 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
  • the decision to rewrite the header can operate regardless of whether the reception operation or the transmission operation is modeled.
  • the BAP sublayer has one BAP entity for MT functionality and another collocation BAP entity for DU functionality. including ". Therefore, functional dependencies between entities should be minimized as much as possible.
  • the header rewriting determination result does not affect the reception operation as follows. In other words, the packet is delivered to the transmitter regardless of whether it is determined that the header has been rewritten.
  • the result is used for the transmission operation as follows.
  • the header is rewritten only for packets determined to be subject to header rewriting.
  • the transmission section of the BAP entity When there are BAP Data PDUs to be sent, the transmission section of the BAP entity performs the following processing.
  • the decision to rewrite the header is preferably modeled by the Tx operation. Further consideration is required as to whether to include it in the BAP header rewriting operation or to provide a new section.
  • Proposal 1 For inter-CU routing, RAN2 should agree to model header rewriting decisions in transmission behavior.
  • SCG is sufficient to identify ingress links for inter-topology transition/topology redundancy/RLF recovery, including consideration when SN is an F1 termination node.
  • SCG may not be applicable in all cases, such as CP/UP separation. So it would be a simple matter for the donor side to explicitly indicate which incoming link, MCG or SCG, requires the header rewrite operation.
  • Proposal 2 For inter-CU routing, RAN2 should agree that the donor side configures which ingress link, ie the BAP header of MCG or SCG, needs to be rewritten in IAB-MT.
  • Proposal 3 For inter-CU routing, the donor side has two header rewrite tables used for the Tx part of the BAP entity in IAB-DU (i.e. downstream) and IAB-MT (i.e. upstream) in each It should be agreed to configure a border IAB node.
  • header rewriting operations are incorporated at the same level as transmission and reception operations, and are described below.
  • the header rewrite operation is referenced in the send operation, so it must be included under the send operation.
  • Proposal 4 RAN2 should agree on defining the header rewrite operation under the send operation, that is, in the BAP specification.
  • the donor CU manages the routing table of its topology.
  • the border IAB node In the inter-CU scenario, it is assumed that two donor CUs are involved in routing at the border IAB node and that these donor CUs manage their routing tables independently. In this sense, it is a simple matter for the border IAB node to consist of two routing tables managed separately by these donor CUs.
  • Proposal 5 RAN2 should agree that the border IAB node consists of two routing tables, each managed by a donor CU and another donor CU.
  • Proposal 6 For downstream packets, RAN2 should agree that border IAB nodes always choose the legacy routing table.
  • the applicable routing table differs depending on which topology the packet is sent. Considering that the combined traffic is header rewritten before the routing process, as in the current CR, the border IAB node can select the appropriate routing table as follows.
  • the legacy routing table (for topology #1 in FIG. 24) is selected for packets whose headers are not rewritten.
  • a new routing table (for topology #2 in FIG. 24) is selected for the packet whose header has been rewritten.
  • the packet is processed by existing routing procedures.
  • Proposal 7 For upstream packets, RAN2 should agree that border IAB nodes choose either the legacy routing table or the new routing table, depending on whether the packet in the routing process has rewritten the header. be.
  • header rewriting table for rerouting
  • the border IAB node may be confused as to whether the old routing ID should be rewritten before or after the routing procedure, that is, whether to rewrite the header for routing or for rerouting. . Therefore, it is desirable to separate the header rewriting table for rerouting and the header rewriting table for routing.
  • the routing header rewrite operation is performed before the routing procedure based on the routing header rewrite setting, and the rerouting header rewrite operation is performed after the routing procedure based on the rerouting header rewrite setting.
  • Proposal 8 RAN2 should agree that the header rewriting table for inter-CU rerouting and inter-donor inter-DU rerouting is separate from the inter-CU routing table. Further consideration is needed as to whether a common header rewriting table applies to both rerouting scenarios.
  • RAN2 is UL rerouting based on header rewriting
  • the above can be amended by agreeing to perform header rewriting after outflow link selection.
  • the preconditions for rewriting the BAP header for rerouting are the same as for Rel-16, that is, there is no condition with outgoing link selection, as follows. agreed.
  • the precondition/criteria for "rerouting by BAP header rewrite" is that no available next hop is found based on the BAP routing ID and based on the BAP address in the routing table, similar to R16. (due to BH RLF, congestion, Type-2 Indication, etc.).
  • Proposal 9 RAN2 should agree that outgoing link selection is done within the routing procedure in the same way as Rel-16, ie header rewriting is done before outgoing link selection.
  • the advantage of outflow link selection before header rewriting is to avoid the case where packet rerouting fails after header rewriting.
  • packet rerouting fails after header rewriting.
  • inter-CU rerouting or inter-donor-DU rerouting fails, it is unknown whether or not the header of a rewritten packet will be rewritten, that is, how many times the header will be rewritten for one packet. is.
  • Multiple rewrites of the header can introduce erroneous risk and complexity.
  • the reception of flow control feedback assumes that the IAB node has no available links due to congestion. In this case, the packet will be sent via the outgoing link that has recovered from congestion earlier. Therefore, packets preferably have either the old routing ID or the new routing ID depending on the outgoing link that has been restored.
  • a method can be considered in which the header is returned from the new routing ID to the old routing ID. In this way the packet is returned to its original state, ie with the old routing ID in the header, and can be processed from the beginning of the BAP entity's send operation. This means that routing is performed again for this packet, and rerouting can be performed when routing fails.
  • Proposal 10 RAN2 should discuss whether to return the header if rerouting based on header rewriting (ie, inter-CU rerouting or inter-donor inter-DU rerouting) fails.
  • the BAP path ID matches the path field, and there is an entry in the BH routing configuration with an outgoing link corresponding to the next hop address available: Select the outgoing link corresponding to the entry's next hop address.
  • 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 address available, Select an entry from the BH routing configuration where the BAP address is the same as the Destination field and the outgoing link corresponding to the next hop address is available.
  • header rewrite settings for rerouting
  • at least one outgoing link is available, BAP header rewrite operation is performed.
  • Rel-16 routing and Rel-17 header rewriting-based rerouting appear to repeat the same sentence, that is, the routing procedure. Therefore, it may be considered as a candidate for simplification.
  • Proposal 11 should discuss how to simplify the modeling of rerouting in order to make the specifications clearer.
  • a communication control method used in a cellular communication system a donor node sending a message regarding routing configuration to a relay node in the topology; and the relay node performing a first process in response to receiving the message.
  • the transmitting step includes: sending a routing configuration change initiation message to an access relay node in response to the donor node initiating a routing configuration change to the relay node in the topology; sending a routing configuration change complete message to the access relay node in response to the donor node completing routing configuration changes to the relay nodes in the topology;
  • the step of performing the first process includes: an access relay node retransmitting packets transmitted in the past for a certain period of time in the upstream direction based on the routing configuration change start message and the routing configuration change complete message;
  • the transmitting step includes: said donor node sending a stop routing indication message to said relay nodes in said topology;
  • the step of performing the first process includes: said relay node stopping routing processing according to said routing stop instruction message and holding the received packet in memory; Further, the donor node changes the routing setting to the relay node, and transmits mapping information between the routing ID before the routing setting change and the routing ID after the routing setting change;
  • the communication control method according to (1) above wherein the relay node restarts routing processing, and rewrites and transmits the header of the packet held in the memory according to the mapping information.
  • a communication control method used in a cellular communication system a donor node sending designation information designating a downstream link to a border relay node; and the border relay node performing header rewrite processing on packets flowing in from the downstream link in accordance with the specified information. Communication control method.
  • a communication control method used in a cellular communication system a step of a donor node setting a first header rewriting table having first classification information and a second header rewriting table having second classification information for a border relay node; the border relay node performing header rewrite processing on the packet using at least one of the first header rewrite table and the second header rewrite table; Communication control method.
  • the first header rewriting table is a header rewriting table for first inter-CU routing used in the user equipment functional unit (IAB-MT) of the border relay node
  • the second header rewriting table is the border relay node.
  • a second inter-CU routing header rewriting table used in a node base station functional unit (IAB-DU) wherein the step of performing the header rewriting process includes: rewriting the header of the packet with reference to the rewriting table, and the base station function unit referring to the second inter-CU routing header rewriting table and rewriting the header of the packet; including, The communication control method according to (5) above.
  • the first header rewrite table is a header rewrite table for inter-CU routing
  • the second header rewrite table is a header rewrite table for header rewrite-based rerouting
  • the step of performing the header rewriting process includes: When the border relay node rewrites the header of the packet using the inter-CU routing header rewriting table and fails in routing, the rewritten routing ID is changed to the routing ID before rewriting. a step of returning; a step of returning the rewritten routing ID to the routing ID before rewriting when the border relay node rewrites the header of the packet using the rerouting header rewriting table and fails in routing; and including The communication control method according to (7) above.
  • a communication control method used in a cellular communication system a step of a donor node setting an upstream traffic mapping configuration including a packet destination topology for a border relay node; a step in which the border relay node selects a routing ID associated with the topology based on the upstream traffic mapping setting; said border relay node transmitting said packet including said routing ID in a header; Communication control method.

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）は、バックホールＲＬＣチャネル（ＢＨ　ＮＲ　ＲＬＣチャネル）によって伝送される。各ＢＨリンクで複数のバックホールＲＬＣチャネルを構成することにより、トラフィックの優先順位付け及びＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）制御が可能である。ＢＡＰ　ＰＤＵとバックホールＲＬＣチャネルとの対応付けは、各ＩＡＢノード３００のＢＡＰレイヤ及びドナーノード２００のＢＡＰレイヤによって実行される。
　図８に示すように、Ｆ１－Ｃプロトコルのプロトコルスタックは、図７に示すＧＴＰ－Ｕレイヤ及びＵＤＰレイヤに代えて、Ｆ１ＡＰレイヤ及びＳＣＴＰレイヤを有する。
　なお、以下においては、ＩＡＢのＩＡＢ－ＤＵとＩＡＢ－ＭＴで行われる処理又は動作について、単に「ＩＡＢ」の処理又は動作として説明する場合がある。例えば、ＩＡＢノード３００－１のＩＡＢ－ＤＵが、ＩＡＢノード３００－２のＩＡＢ－ＭＴへＢＡＰレイヤのメッセージを送信することを、ＩＡＢノード３００－１がＩＡＢノード３００－２へ、当該メッセージを送信するものとして説明する。また、ドナーノード２００のＤＵ又はＣＵの処理又は動作についても、単に「ドナーノード」の処理又は動作として説明する場合がある。
　また、アップストリーム方向とアップリンク（ＵＬ）方向とを区別しないで用いる場合がある。更に、ダウンストリーム方向とダウンリンク（ＤＬ）方向とを区別しないで用いる場合がある。
［第１実施形態］
　次に、第１実施形態について説明する。
　最初に、第１実施形態に係るルーティング処理について説明する。
（ルーティング処理）
　ＩＡＢノード３００のＢＡＰレイヤでは、ルーティング処理が行われる。具体的には、例えば、以下のような処理が行われる。
　すなわち、ＢＡＰレイヤは、ＢＡＰヘッダに含まれるＢＡＰルーティングＩＤに基づいて、ＢＡＰパケットをルーティングする。ＢＡＰヘッダは、パケットが上位レイヤから到達したときに追加され、宛先ノードに到達したときに除去される。ＢＡＰルーティングＩＤの設定又はルーティングテーブルは、ドナーノード２００のＣＵによって設定される。ＢＡＰルーティングＩＤは、ＢＡＰアドレス（又はＤｅｓｔｉｎａｔｉｏｎ、或いは宛先ＢＡＰアドレス）とＢＡＰパスＩＤ（又は経路識別子）から構成される。ＢＡＰアドレスは、宛先ノードを示す。また、ＢＡＰパスＩＤは、宛先までにパケットが辿るルーティングパスを示す。
　パケットの経路上の各ＩＡＢノード３００では、パケットが目的地に到達したか否か、すなわち、ＩＡＢノード３００のＢＡＰアドレスと一致しているかどうかを判断する。具体的には、ＢＡＰヘッダに含まれるＢＡＰルーティングＩＤのＢＡＰアドレスに基づいて行われる。ＩＡＢノード３００は、パケットが目的地（宛先ＢＡＰアドレス）に到達していない（すなわち、ＢＡＰヘッダに含まれるＢＡＰアドレス（Ｄｅｓｔｉｎａｔｉｏｎ）が自ＩＡＢノードのＢＡＰアドレスと一致していない）場合、ＢＡＰヘッダに含まれるＢＡＰルーティングＩＤと、ルーティング設定（ｒｏｕｔｉｎｇ　ｃｏｎｆｉｇｕｒａｔｉｏｎ）とに基づいて、次ホップのＢＡＰアドレス（又はバックホールリンク、或いは流出リンク）を決定する。
　このように、パケットの送信先を制御する処理のことを、例えば、ルーティング処理と称する場合がある。
　なお、以下では、ＢＡＰルーティングＩＤをルーティングＩＤ、ＢＡＰパスＩＤをパスＩＤとそれぞれ称する場合がある。また、ＩＡＢドナーＤＵをドナーノード２００のＤＵ、ＩＡＢドナーＣＵをドナーノード２００のＣＵとそれぞれと称する場合がある。更に、ルーティングＩＤに含まれるＢＡＰパスＩＤをパスＩＤ、ルーティングＩＤに含まれるＢＡＰアドレスをＤｅｓｔｉｎａｔｉｏｎとそれぞれ称する場合がある。
（第１実施形態に係る通信制御方法）
　ドナーノード２００が、トポロジ内の全ＩＡＢノードに対して、ルーティング設定（ｒｏｕｔｉｎｇ　ｃｏｎｆｉｇｕｒａｔｉｏｎ）を変更するには、トポロジの規模が大きければ大きいほど、時間がかかることが予想される。
　あるルーティングＩＤが付与されたパケットが、アクセスＩＡＢノード（ＵＥ１００から受信したパケットを最初に処理するノード及びＵＥ１００へ送信するパケットを最後に処理するノード）又はドナーノード２００のＤＵから送信された後、中間のＩＡＢノード３００においてルーティング設定が変更された場合、当該パケットはどのように処理されるかが問題となる場合がある。
　例えば、中間のＩＡＢノード３００では、ルーティング設定が変更されると、本来、到達すべきＤｅｓｔｉｎａｔｉｏｎ（当該パケットのＢＡＰヘッダに含まれるルーティングＩＤのＤｅｓｔｉｎａｔｉｏｎ）とは異なるＤｅｓｔｉｎａｔｉｏｎ（つまり、異なるルート）へ、当該パケットをルーティングする場合がある。このようなルーティングミスはパケットロスが生じる原因ともなる。
　そこで、第１実施形態では、ドナーノード２００は、ルーティング設定変更開始メッセージと、ルーティング設定変更完了メッセージとを、アクセスＩＡＢノード３００－Ａへ送信する。アクセスＩＡＢノード３００－Ａでは、２つのメッセージに基づいて、ドナーノード２００に到達済のパケットを推測し、推測結果に基づいて、過去に送信したパケットを再送信する。
　具体的には、第１に、ドナーノード（例えば、ドナーノード２００）が、トポロジ内の中継ノード（例えば、ＩＡＢノード３００）に対して、ルーティング設定に関するメッセージを送信する。第２に、中継ノードが、メッセージを受信したことに応じて第１の処理を行う。
　ここで、メッセージを送信する処理には、ドナーノードが、トポロジ内の中継ノードに対してルーティング設定の変更を開始したことに応じて、ルーティング設定変更開始メッセージをアクセス中継ノード（例えば、アクセスＩＡＢノード３００－Ａ）へ送信する処理を含む。また、メッセージを送信する処理には、ドナーノードが、トポロジ内の中継ノードに対してルーティング設定の変更を完了したことに応じて、ルーティング設定変更完了メッセージをアクセス中継ノードへ送信する処理を含む。そして、第１の処理には、アクセス中継ノードが、ルーティング設定変更開始メッセージとルーティング設定変更完了メッセージとに基づいて、アップストリーム方向において一定期間過去に送信したパケットを再送信する処理を含む。
　図９は、第１実施形態に係るノード間の構成例を表す図である。図９に示すように、ドナーノード２００が、ルーティング設定変更開始メッセージと、ルーティング設定変更完了メッセージとを、アクセスＩＡＢノード３００－Ａへ送信している。
　これにより、アクセスＩＡＢノード３００－Ａでは、例えば、ルーティング設定変更開始のタイミングとルーティング設定変更完了のタイミングとを把握することができ、ドナーノード２００に到達済のパケット（又はドナーノード２００に到達していないパケット）を精度良く推測することができる。従って、アクセスＩＡＢノード３００－Ａでは、パケットロスが生じたと予想されるパケットを再送信することで、パケットロスを補償する（又は抑制させる）ことが可能となる。
（第１実施形態に係る第１動作例）
　次に、第１実施形態に係る第１動作例について説明する。
　第１動作例は、ダウンストリーム方向とアップストリーム方向とを別々に説明する。また、第１動作例では、ダウンストリーム方向には２つのオプション（オプションＤ１とオプションＤ２）がある。また、第１動作例では、アップストリーム方向についても２つのオプション（オプションＵ１とオプションＵ２）がある。
（ダウンストリーム方向のオプションＤ１）
　図１０は、第１実施形態に係るダウンストリーム方向のオプションＤ１の動作例を表す図である。
　図１０に示すように、ステップＳ１０において、ドナーノード２００は処理を開始する。
　ステップＳ１１において、ドナーノード２００は、ダウンストリーム方向において送信済のパケットをメモリなどに保持する。
　ステップＳ１２において、ドナーノード２００は、トポロジ内の（全ての）ＩＡＢノード３００のルーティング設定を変更した後、変更前のルーティング設定に従ったヘッダを有するパケット（すなわち、送信済パケット）がアクセスＩＡＢノードに到達済かを推測する。例えば、ドナーノード２００は、過去の送信履歴から単位時間あたり、アクセスＩＡＢノードに到達するパケット数を計算し、ルーティング設定変更後から現在時刻までの時間に基づいて、アクセスＩＡＢノード３００－Ａに到達済パケットの数を推測する。なお、ドナーノード２００のＣＵは、アクセスＩＡＢノード３００－ＡのＩＡＢ－ＤＵに対して、Ｆ１ＡＰプロトコルによるメッセージを利用して、ルーティング設定の変更を行ってもよい。
　ステップＳ１３において、ドナーノード２００は、一定期間過去に送信したパケットについて、変更後のルーティング設定に従ったヘッダを付与した上で、当該パケットを再送信（ブラインド再送信）する。例えば、ドナーノード２００は、推測した到達済パケットの数と、ルーティング設定変更後から現在時刻までに送信した送信済パケット数とに基づいて、どれくらい過去に遡ればよいかを計算することで、一定期間過去に送信したパケットを特定してもよい。
　ステップＳ１４において、ドナーノード２００は、一連の処理を終了する。
（ダウンストリーム方向のオプションＤ２）
　図１１は、第１実施形態に係るダウンストリーム方向のオプションＤ２の動作例を表す図である。
　図１１に示すように、ステップＳ２０において、ドナーノード２００は処理を開始する。
　ステップＳ２１において、ドナーノード２００は、ダウンストリーム方向において送信済パケットをメモリなどに保持する。
　ステップＳ２２において、ドナーノード２００は、トポロジ内の（全ての）ＩＡＢノード３００に対してルーティング設定を変更した後、影響を受けそうなＵＥ１００を特定する。例えば、ドナーノード２００は、当該ドナーノード２００とＲＲＣコネクティッド状態のＵＥ１００を、影響を受けそうなＵＥ１００として特定してもよい。
　ステップＳ２３において、ドナーノード２００は、当該ＵＥ１００に対して、ＰＤＣＰステータスレポート（ＰＤＣＰ　Ｓｔａｔｕｓ　Ｒｅｐｏｒｔ）を送信させるよう指示する。例えば、ドナーノード２００のＣＵが、ＲＲＣメッセージを利用して、当該ＵＥ１００に対して当該指示を送信する。
　ステップＳ２４において、ドナーノード２００は、ＵＥ１００から、ＰＤＣＰステータスレポートを受信し、当該レポートに含まれるＦＭＣ（First Missing Count）に基づいて、ＵＥ１００に未到達にパケットを特定する。そして、ドナーノード２００は、当該パケットに対して、変更後のルーティング設定に従ったヘッダを付与した上で、再送信を行う。なお、ドナーノード２００のＣＵは、ＲＲＣメッセージを利用して、ＵＥ１００からＰＤＣＰステータスレポートを受信してもよい。
　そして、ドナーノード２００は、一連の処理を終了する。
（アップストリーム方向のオプションＵ１）
　図１２は、第１実施形態に係るアップストリーム方向のオプションＵ１の動作例を表す図である。
　図１２に示すように、ステップＳ３０において、アクセスＩＡＢノード３００－Ａは、処理を開始する。
　ステップＳ３１において、アクセスＩＡＢノード３００－Ａは、アップストリーム方向における送信済のパケットをメモリなどに保持する。
　ステップＳ３２において、ドナーノード２００は、トポロジ内における、当該アクセスＩＡＢノード３００－Ａに関連するＩＡＢノード３００に対してルーティング設定の変更を開始した時、ルーティング設定変更開始メッセージを、当該アクセスＩＡＢノード３００－Ａへ送信する。ルーティング設定変更開始メッセージは、ルーティング設定の変更が開始されたことを示すメッセージである。例えば、ドナーノード２００のＣＵが、アクセスＩＡＢノード３００－ＡのＩＡＢ－ＤＵへ、Ｆ１ＡＰメッセージとして当該メッセージを送信してもよい。又は、例えば、ドナーノード２００のＣＵが、アクセスＩＡＢノード３００－ＡのＩＡＢ－ＭＴへ、ＲＲＣメッセージとして、当該メッセージを送信してもよい。
　ステップＳ３３において、ドナーノード２００は、トポロジ内における、当該アクセスＩＡＢノード３００－Ａに関連するＩＡＢノード３００に対してルーティング設定の変更を完了した時、ルーティング設定変更完了メッセージを、当該アクセスＩＡＢノード３００－Ａへ送信する。ルーティング設定変更完了メッセージは、ルーティング設定の変更が完了されたことを示すメッセージである。例えば、当該メッセージは、Ｆ１ＡＰメッセージ又はＲＲＣメッセージとして送信されてもよい。なお、ルーティング設定変更完了メッセージには、ルーティング設定の変更に要した時間が含まれてもよい。当該時間は、ルーティング設定開始時刻からルーティング設定終了時刻までの時間で表されてもよい。
　ステップＳ３４において、アクセスＩＡＢノード３００－Ａは、ルーティング設定変更開始メッセージとルーティング設定変更完了メッセージとに基づいて、送信済パケットのうち、ドナーノード２００へ到達した到達済パケットを推測する。例えば、アクセスＩＡＢノード３００－Ａは、以下のようにして到達済パケットを推測してもよい。すなわち、アクセスＩＡＢノード３００－Ａは、ルーティング設定変更開始メッセージを受信した受信時刻とルーティング設定変更完了メッセージを受信した受信時刻とからルーティング設定の変更に要した変更時間を計算する。また、アクセスＩＡＢノード３００－Ａは、過去の履歴から、単位時間あたりにドナーノード２００へ到達したパケット数を計算する。そして、アクセスＩＡＢノード３００－Ａは、当該変更時間と当該パケット数とに基づいて、到達済パケットを推測する。
　ステップＳ３５において、アクセスＩＡＢノード３００－Ａは、一定期間過去に送信したパケットに対して、変更後のルーティング設定に従ったヘッダを付与した上で、再送信（又はブラインド再送信）する。例えば、アクセスＩＡＢノード３００－Ａは、メモリに保持した送信済のパケットから、推測した到達済パケットを除いたパケットを、一定期間過去に送信したパケットとして、再送信してもよい。或いは、例えば、アクセスＩＡＢノード３００－Ａは、ルーティング設定の変更に要した変更時間を、一定期間として、その時間分の送信済パケットを、一定期間過去に送信したパケットとして再送信してもよい。アクセスＩＡＢノード３００－Ａでは、ルーティング設定変更開始メッセージとルーティング設定変更完了メッセージとに基づいて、アップストリーム方向において一定期間過去に送信したパケットを再送信することになる。
　そして、ステップＳ３６において、ドナーノード２００は、一連の処理を終了する。
（アップストリーム方向のオプションＵ２）
　図１３は、第１実施形態に係るアップストリーム方向のオプションＵ２の動作例を表す図である。
　図１３に示すように、ステップＳ４０において、ＵＥ１００は、処理を開始する。
　ステップＳ４１において、ＵＥ１００は、送信済のＰＤＣＰ　Ｄａｔａ　ＳＤＵ（Service Data Unit）をメモリなどに保持する。この際、ＵＥ１００は、通常よりも長いＤｉｓｃａｒｄ　Ｔｉｍｅｒ値を設定しておくようにする。ＵＥ１００からドナーノード２００へのマルチホップ転送の到達遅延を考慮して、タイマ満了によるＰＤＣＰ　ＳＤＵが破棄されるのを防止するためである。
　ステップＳ４２において、ドナーノード２００は、トポロジ内の（全ての）ＩＡＢノード３００に対してルーティング設定を変更し、その後、影響を受けそうなＵＥ１００を特定する。ドナーノード２００は、当該ドナーノード２００に対してＲＲＣコネクティッド状態となっているＵＥ１００を、影響を受けそうなＵＥ１００として特定してもよい。
　ステップＳ４３において、ドナーノード２００は、当該ＵＥ１００に対して、ＰＤＣＰステータスレポートを送信する。なお、ＵＥ１００は、当該ＰＤＣＰステータスレポートに従って、到達済のパケット（ＰＤＣＰ　Ｄａｔａ　ＳＤＵ）を破棄する。
　ステップＳ４４において、ドナーノード２００は、ＰＤＣＰデータ回復（ＰＤＣＰ　Ｄａｔａ　Ｒｅｃｏｖｅｒｙ）をトリガする。ＵＥ１００は、保持しているＰＤＣＰ　Ｄａｔａ　ＳＤＵをアクセスＩＡＢノード３００－Ａへ再送する。アクセスＩＡＢノード３００－Ａでは、当該パケットに対して、変更後のルーティング設定に従ったヘッダを付与して、次ホップノードへ送信する。
　ステップＳ４５において、ドナーノード２００は、一連の処理を終了する。
（第１実施形態に係る第２動作例）
　上述した第１実施形態に係る第１動作例では、一定期間過去の送信済のパケットを再送信するなどにより、パケットロスを補償することについて説明した。
　しかし、ルーティングミスそのものに対する対処方法については、第１動作例では議論されていない。そのため、ルーティングミスによる無駄なパケットがトポロジ内で転送され、無駄なリソースが消費される場合がある。
　そこで、第２動作例では、各ＩＡＢノード３００では、ルーティング設定変更前からルーティング設定変更完了までの間、ルーティング処理が停止され、ルーティング処理再開後、それまでメモリに保持したパケットのヘッダを書き替えて送信する例について説明する。
　具体的には、第１に、ドナーノード（例えば、ドナーノード２００）が、トポロジ内の中継ノード（例えば、ＩＡＢノード３００）に対して、ルーティング停止指示メッセージを送信する。第２に、中継ノードが、ルーティング停止指示メッセージに従って、ルーティング処理を停止するとともに、受信したパケットをメモリに保持する。第３に、ドナーノードが、中継ノードに対して、ルーティング設定を変更し、ルーティング設定変更前のルーティングＩＤとルーティング設定変更後のルーティングＩＤとのマッピング情報を送信する。第４に、中継ノードが、ルーティング処理を再開し、マッピング情報に従って、メモリに保持したパケットのヘッダを書き替えて送信する。
　このように、各ＩＡＢノード３００では、ルーティング設定変更前後で、ルーティング処理が停止され、パケットをメモリに保持している。これにより、ルーティングミスによるパケットがトポロジ内で転送されることを防止している。そして、各ＩＡＢノード３００では、ルーティング処理再開後、それまでメモリに保持したパケットのヘッダに含まれるルーティングＩＤについて、ルーティング設定変更前後のマッピング情報を用いて書き替えている。これにより、ルーティング設定変更後の正しいルーティングＩＤに書き替えられたパケットがトポロジ内に転送されることになる。従って、ルーティングミスを防止させることが可能となる。
　第１実施形態に係る第２動作例は、２つのオプション（オプションＣ１とオプションＣ２）がある。最初にオプションＣ１について説明する。２つのオプションともに、パケットの送信について、ダウンストリーム方向とアップストリーム方向の双方において実施可能である。
（オプションＣ１）
　ドナーノード２００は、ルーティング設定変更時において、各ルーティングＩＤのパスＩＤを変更し、Ｄｅｓｔｉｎａｔｉｏｎをルーティング設定変更前後で変更しないようにする。
　次に、ＩＡＢノード３００は、ルーティング設定変更前のルーティング設定に従ったパケットを受信する。
　次に、ＩＡＢノード３００は、変更後のルーティング設定において、当該パケットのルーティングＩＤに含まれるパスＩＤが変更後のルーティング設定に存在しない場合、Ｄｅｓｔｉｎａｔｉｏｎへのローカルリルーティング（ｌｏｃａｌ　ｒｅ－ｒｏｕｔｉｎｇ）を行う。変更後のルーティング設定には、当該パケットに含まれるパスＩＤが存在しなくても、当該パケットに含まれるＤｅｓｔｉｎａｔｉｏｎがエントリとして存在する。そのため、ＩＡＢノード３００は、正しいＤｅｓｔｉｎａｔｉｏｎへのローカルリルーティングを実行できる。ローカルリルーティングとは、ルーティング設定を考慮しないで代替パス（ａｌｔｅｒｎａｔｉｖｅ　ｐａｔｈ）へパケットをルーティングすることである。
　ただし、Ｄｅｓｔｉｎａｔｉｏｎは１０２４個（１０ビット）設定可能であるが、トポロジ内のＩＡＢノード３００とドナーノード２００のＤＵの個数が１０２４に近づくと、同一のＤｅｓｔｉｎａｔｉｏｎが重複使用される場合がある。この場合、オプションＣ１ではルーティングミスの可能性が存在する。
（オプションＣ２）
　図１４は、第１実施形態に係るオプションＣ２の動作例を表す図である。
　図１４に示すように、ステップＳ５０において、ドナーノード２００は、処理を開始する。
　ステップＳ５１において、ドナーノード２００は、トポロジ内のＩＡＢノード３００に対してルーティング設定変更を行う前に、トポロジ内の（全部又は一部の）ＩＡＢノード３００に対して、ルーティング処理停止を指示するルーティング停止指示メッセージを送信する。ルーティング停止指示メッセージは、Ｆ１ＡＰメッセージ又はＲＲＣメッセージとして送信されてもよい。
　ステップＳ５２において、ＩＡＢノード３００は、ルーティング停止指示メッセージの受信に応じて、ルーティング処理を停止するとともに、受信したパケット（ＢＡＰ　Ｄａｔａ　ＰＤＵ）をメモリなどに保持する。
　ステップＳ５３において、ドナーノード２００は、トポロジ内の（全部又は一部の）ＩＡＢノード３００に対して、ルーティング設定を変更する。例えば、ドナーノード２００のＣＵが、ＩＡＢノード３００のＩＡＢ－ＤＵに対して、Ｆ１ＡＰメッセージを利用して変更後のルーティング設定を送信することで、ルーティング設定の変更が行われてもよい。
　ステップＳ５４において、ドナーノード２００は、ルーティング設定変更前のルーティングＩＤと、ルーティング設定変更後のルーティングＩＤと対応関係を表すマッピング情報を、トポロジ内の（全部又は一部の）ＩＡＢノード３００へ送信する。マッピング情報は、Ｆ１ＡＰメッセージ又はＲＲＣメッセージにより送信されてもよい。なお、ＩＡＢノード３００では、このマッピング情報の受信がルーティング処理再開のトリガとなってもよい。或いは、ドナーノード２００は、マッピング情報を送信後、トポロジ内の（全部又は一部の）ＩＡＢノード３００に対して、ルーティング再開指示メッセージを送信してもよい。ルーティング再開指示メッセージも、Ｆ１ＡＰメッセージ又はＲＲＣメッセージとして送信されてもよい。ＩＡＢノード３００では、ルーティング再開指示メッセージの受信に応じて、ルーティング処理を再開する。
　ステップＳ５５において、ＩＡＢノード３００は、ルーティング処理を再開し、マッピング情報に従って、メモリに保持したパケット（ＢＡＰ　Ｄａｔａ　ＰＤＵ）の（ＢＡＰ）ヘッダを書き換える。具体的には、ＩＡＢノード３００のＢＡＰレイヤ（又はＢＡＰエンティティ。以下では、ＢＡＰレイヤとＢＡＰエンティティとを区別しないで用いる場合がある。）は、マッピング情報に従って、ヘッダに含まれるルーティングＩＤ（ルーティング設定変更前のルーティングＩＤ）を、ルーティング設定変更後のルーティングＩＤへ書き換える。なお、ＩＡＢノード３００は、マッピング情報受信後（又はルーティング処理再開後）、新たに受信したパケットについては、マッピング情報によるヘッダ書き替えを行わない。ＩＡＢノード３００は、メモリに保持した全パケットについて、マッピング情報によるヘッダ書き替えが終了すると、マッピング情報を破棄してもよい。
　ステップＳ５６において、ＩＡＢノード３００は、当該パケットに対して、変更後のルーティング設定によりルーティング処理を行い、次ホップノードへ送信する。
　そして、ステップＳ５７において、一連の処理が終了する。
[第２実施形態]
　次に、第２実施形態について説明する。
　第２実施形態では、ダウンストリーム方向におけるパケットのヘッダ書き替えについて説明する。
　ＩＡＢノード３００には、複数のトポロジに属するＩＡＢノードがある。このようなＩＡＢノードを、境界ＩＡＢノード（ｂｏｕｄａｒｙ　ＩＡＢ－ｎｏｄｅ）と呼ぶ。
　図１５は、第２実施形態に係る境界ＩＡＢノード３００－Ｂの例を表す図である。図１５に示す例では、境界ＩＡＢノード３００－Ｂは、ドナーノード２００のＣＵ＃１（２００－Ｃ１）によって構成されたトポロジと、別のドナーノードのＣＵ＃２（２００－Ｃ２）によって構成されたトポロジの２つのトポロジに属している。
　なお、第２実施形態では、ＣＵ＃１（２００－Ｃ１）によって構成されたトポロジをメイントポロジ、ＣＵ＃２（２００－Ｃ２）によって構成されたトポロジをサブトポロジとそれぞれ称する場合がある。
　境界ＩＡＢノード３００－Ｂでは、ＣＵ間ルーティング（Ｉｎｔｅｒ－ＣＵ　ｒｏｕｔｉｎｇ）において、ヘッダ書き替え処理が行われる。ＣＵ間ルーティングとは、例えば、第１ＣＵが管理する第１トポロジから第２ＣＵが管理する第２トポロジへパケットをルーティングすることである。
　アップストリーム方向のＣＵ間ルーティングに関しては、境界ＩＡＢノード３００－Ｂでは、メイントポロジから流入したパケットを、サブトポロジへ流出させる処理を行う。具体的には、境界ＩＡＢノード３００－ＢのＢＡＰレイヤが、ヘッダ書き替えテーブル（Ｈｅａｄｅｒ　Ｒｅｗｒｉｔｉｎｇ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を利用して、当該パケットに対してヘッダを書き替え（例えば、ルーティングＩＤを書き替えることで、ＤｅｓｔｉｎａｔｉｏｎをＣＵ＃１（２００－Ｃ１）からＣＵ＃２（２００－Ｃ２）へ書き替え）を行って、パケットを転送させている。アップストリーム方向のヘッダ書き替えテーブルは、メイントポロジ側のＣＵ＃１（２００－Ｃ）が管理している。
　一方、ダウンストリーム方向のＣＵ間ルーティングに関しては、境界ＩＡＢノード３００－Ｂでは、サブトポロジから流入したパケットを、メイントポロジに流出させる処理を行う。具体的には、境界ＩＡＢノード３００－ＢのＢＡＰレイヤが、ヘッダ書き替えテーブルを利用して、当該パケットに対してヘッダを書き替え（例えば、ルーティングＩＤを書き替えることで、ＤｅｓｔｉｎａｔｉｏｎをサブトポロジのアクセスＩＡＢノードから、メイントポロジのアクセスＩＡＢノードへ書き替え）を行って、パケットを転送させている。ダウンストリーム方向のヘッダ書き替えテーブルは、サブトポロジ側のＣＵ＃２（２００－Ｃ２）が管理している。
　ここで、境界ＩＡＢノード３００－Ｂでは、ルーティング設定と、アップストリーム方向のヘッダ書き替えテーブルとについて、同一のドナーノード２００（又はＣＵ＃１（２００－Ｃ））により管理されている。そのため、境界ＩＡＢノード３００－Ｂでは、アップストリーム方向のヘッダ書き替えについては、ヘッダ書き替えテーブルを参照して、エントリが存在するか否かにより、ヘッダ書き替えを行うか否かを判断できる。
　一方、境界ＩＡＢノード３００－Ｂにおいて、ダウンストリーム方向のヘッダ書き替えテーブルは、上述したように、サブトポロジ（ＣＵ＃２（２００－Ｃ２））により管理されている。また、サブトポロジのルーティングＩＤはＣＵ＃２（２００－Ｃ２）により管理され、メイントポロジのルーティングＩＤはＣＵ＃１（２００－Ｃ１）により管理されている。そのため、メイントポロジにあるルーティングＩＤと、サブトポロジにあるルーティングＩＤとが一致する場合がある。境界ＩＡＢノード３００－Ｂでは、ダウンストリーム方向におけるヘッダ書き替えの際に、メイントポロジ側のルーティングＩＤと、サブトポロジ側のルーティングＩＤとを区別することなく、ヘッダを書き替える。そのため、境界ＩＡＢノード３００－Ｂでは、ダウンストリーム方向へのＣＵ間ルーティングの際に、パケットを、誤ってサブトポロジ側へ流出させてしまう場合がある。
　そこで、３ＧＰＰでは、ダウンストリーム方向のヘッダ書き替え処理については、境界ＩＡＢノード３００－ＢのＳＣＧ（Secondary Cell Group）側から流入したパケットをヘッダ書き替え対象とすることについて議論している。
　しかし、ＳＣＧ側は、必ずしも、サブトポロジに属しているとは限らない。ＭＣＧ（Master Cell Group）側がサブトポロジとなっている場合、サブトポロジから流入したダウンストリーム方向のパケットは、ヘッダ書き替え対象とはならないことになる。逆に、メイントポロジ側のＳＣＧから流入したパケットがヘッダ書き替え対象となってしまう。
　そこで、第２実施形態では、ドナーノード２００が、境界ＩＡＢノード３００－Ｂに対して、ダウンストリーム方向においてヘッダ書き替えの対象となるリンク（又は境界ＩＡＢノード３００－Ｂに対する親ノード）を指定する例について説明する。
　具体的には、第１に、ドナーノード（例えば、ドナーノード２００）が、ダウンストリームリンクを指定した指定情報を、境界中継ノード（例えば、境界ＩＡＢノード３００－Ｂ）へ送信する。第２に、境界中継ノードが、指定情報に従って、ダウンストリームリンクから流入したパケットに対してヘッダ書替え処理を行う。
　これにより、例えば、境界ＩＡＢノード３００－Ｂでは、ヘッダ書き替え対象のパケットを特定することができるため、ダウンストリーム方向のヘッダ書き替え処理を適切に行うことが可能となる。
（第２実施形態に係る動作例）
　図１６は、第２実施形態に係る動作例を表す図である。
　図１６に示すように、ステップＳ６０において、ドナーノード２００は、処理を開始する。
　ステップＳ６１において、ドナーノード２００は、境界ＩＡＢノード３００－Ｂに対して、ヘッダ書き替え対象となるダウンストリームリンク(又は流入リンク（ｉｎｇｒｅｓｓ　ｌｉｎｋ）)を指定した指定情報を送信する。指定情報には、ヘッダ書き替えが必要な（又はヘッダ書き替えの対象となる）流入リンクが含まれる。具体的には、指定情報には、ヘッダ書き替えが必要なＭＣＧ又はＳＣＧが含まれてもよい。また、指定情報には、ヘッダ書き替えが必要な親ノードのＢＡＰアドレス又は親ノードのセルＩＤが含まれてもよい。更に、指定情報には、トポロジに対応するリンクが含まれてもよい。例えば、メイントポロジはＭＣＧでサブトポロジはＳＣＧ、又は、メイントポロジはＳＣＧでサブトポロジはＭＣＧであることを示す情報が指定情報に含まれてもよい。この場合、サブトポロジとして指定された側が、ヘッダ書き替えが必要なリンクとなる。なお、指定情報は、Ｆ１ＡＰメッセージ又はＲＲＣメッセージに含まれて送信されてもよい。
　ステップＳ６２において、境界ＩＡＢノード３００－ＢのＢＡＰレイヤは、当該指定情報に従って、指定情報として指定されたダウンストリームリンクから流入したパケットを、書き替え対象のパケットを特定し、当該パケットに対してヘッダ書き替え処理を行う。
　そして、ステップＳ６３において、一連の処理が終了する。
[第３実施形態]
　次に第３実施形態について説明する。
　第３実施形態では、様々な種類のヘッダ書き替えテーブルを分類する例について説明する。
　３ＧＰＰでは、ＣＵ間ルーティングを行う際に、境界ＩＡＢノード３００－Ｂに設定されるヘッダ書き替えテーブルを、ＵＬ方向(又はアップストリーム方向)とＤＬ方向（又はダウンストリーム方向）とでどのように異ならせるかについて議論されている。
　ヘッダ書き替えテーブルについては、ＵＬ方向とＤＬ方向とで異なるテーブルが用いられる場合、ＢＡＰレイヤでは、パケット毎の流入方向を特定する処理が行われる場合がある。すなわち、ＢＡＰレイヤでは、パケット毎に、流入方向を特定後、ＵＬ用のヘッダ書き替えテーブル及びＤＬ用のヘッダ書き替えテーブルのいずれかのテーブルを用いて、ヘッダ書き替え処理を行うことになる。
　しかし、境界ＩＡＢノード３００－Ｂにおいて、このような処理を行うことは、ＣＵ間ルーティングの処理を増大させてしまう。また、ＢＡＰレイヤでは、パケットの流入方向を特定するために、他のレイヤとの間で情報交換を行うことになり、他のレイヤとの依存性を高めてしまう。
　そこで、第３実施形態では、ＣＵ間ルーティングで使用されるヘッダ書き替えテーブルを、境界ＩＡＢノード３００－ＢのＩＡＢ－ＭＴ側で使用するテーブルと、ＩＡＢ－ＤＵ側で使用するテーブルとで分類するようにする。
　具体的には、第１に、ドナーノード（例えば、ドナーノード２００）が、境界中継ノード（例えば、境界ＩＡＢノード３００－Ｂ）に対して、第１分類情報を有する第１ヘッダ書き替えテーブルと、第２分類情報を有する第２ヘッダ書き替えテーブルとを設定する。第２に、境界中継ノードが、第１ヘッダ書き替えテーブルと第２ヘッダ書き替えテーブルの少なくともいずれかを用いて、パケットに対してヘッダ書き替え処理を行う。
　ここで、第１ヘッダ書き替えテーブルは、境界中継ノードのユーザ装置機能部（ＩＡＢ－ＭＴ）で使用する第１ＣＵ間ルーティング用ヘッダ書き替えテーブルであり、第２ヘッダ書き替えテーブルは、境界中継ノードの基地局機能部（ＩＡＢ－ＤＵ）で使用する第２ＣＵ間ルーティング用ヘッダ書き替えテーブルである。
　また、ヘッダ書き替え処理は、ユーザ装置機能部が、第１ＣＵ間ルーティング用ヘッダ書き替えテーブルを参照してパケットに対してヘッダ書き替えを行い、基地局機能部が、第２ＣＵ間ルーティング用ヘッダ書き替えテーブルを参照してパケットに対してヘッダ書き替えを行うことを含む。
　このように、第３実施形態では、ヘッダ書き替えテーブルが、ＩＡＢ－ＭＴ側で使用するテーブルと、ＩＡＢ－ＤＵ側で使用するテーブルとで分類されており、ＵＬ方向とＤＬ方向とで分類されていない。そのため、ＤＬ方向又はＵＬ方向をパケット毎に特定することによる処理増大を抑制させることができる。また、ＢＡＰレイヤも他レイヤとの依存性を高めてしまう事態を抑制させることが可能となる。更に、ＩＡＢ－ＭＴとＩＡＢ－ＤＵは、各々、設定されたヘッダ書き替えテーブルを用いてヘッダ書き替え処理を行えばよいだけであるため、適切にヘッダ書き替え処理を行うことも可能となる。
　なお、「ＵＬ」と「ＤＬ」は、例えば、以下を意味で用いる場合がある。すなわち、第１トポロジから第２トポロジへパケットが転送される場合に「ＵＬ」となり得る。また、第２トポロジから第１トポロジにパケットが転送される場合に「ＤＬ」となり得る。なお、第１トポロジから第１トポロジに転送される（すなわち、同一トポロジ内）パケットはヘッダ書き替えの対象外となる。
（第３実施形態に係る第１動作例）
　図１７は、第３実施形態に係る境界ＩＡＢノード３００－Ｂの構成例を表す図である。
　図１７に示すように、ＩＡＢ－ＭＴ（３００－ＭＴ）にはＣＵ間ルーティング用のヘッダ書き替えテーブル３５０－ＭＴを有する。ヘッダ書き替えテーブル３５０－ＭＴは、ＵＬ方向におけるパケットに対するヘッダ書き替えを行うテーブルとなっている。
　また、ＩＡＢ－ＤＵ（３００－ＤＵ）は、ＣＵ間ルーティング用のヘッダ書き替えテーブル３５０－ＤＵを有する。ヘッダ書き替えテーブル３５０－ＤＵは、ＤＬ方向におけるパケットに対するヘッダ書き替えテーブルとなっている。
　なお、第３実施形態に係る第１動作例では、ＩＡＢ－ＭＴ（３００－ＭＴ）側のヘッダ書き替えテーブル３５０－ＭＴを、ＭＴ用書き替えテーブル３５０－ＭＴと称し、ＩＡＢ－ＤＵ（３００－ＤＵ）側のヘッダ書き替えテーブル３５０－ＤＵを、ＤＵ用書き替えテーブル３５０－ＤＵと称する場合がある。
　図１８は、第３実施形態に係る第１動作例を表す図である。
　図１８に示すように、ステップＳ７０において、ドナーノード２００は処理を開始する。
　ステップＳ７１において、ドナーノード２００は、境界ＩＡＢノード３００－Ｂに対して、ＤＵとＭＴとで異なる分類情報を有するＣＵ間ルーティング用の書き替えテーブルを設定する。例えば、ドナーノード２００は、第１分類情報を有するＭＴ用書き替えテーブル３５０－ＭＴと、第２分類情報を有するＤＵ用書き替えテーブル３５０－ＤＵとを境界ＩＡＢノード３００－Ｂに設定する。
　分類情報は、２つの書き替えテーブルに対して、ＤＵ用とＭＴ用という情報であってもよい。分類情報が各書き替えテーブルに紐づけられる。また、分類情報は、２つの書き替えテーブルを区別する名称であってもよい。例えば、「ＢＡＰ　Ｈｅａｄｅｒ　Ｒｅｗｒｉｔｉｎｇ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　ｆｏｒ　ＩＡＢ－ＤＵ」と「ＢＡＰ　Ｈｅａｄｅｒ　Ｒｅｗｒｉｔｉｎｇ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　ｆｏｒ　ＩＡＢ－ＭＴ」である。更に、書き替えテーブル自体は１つのテーブルとし、各エントリ（例えば、旧ルーティングＩＤと新ルーティングＩＤとからなるエントリ）に対して、ＤＵ用とＭＴ用という分類情報を紐づけてもよい。
　なお、分類情報を有する各書き替えテーブルは、例えば、Ｆ１ＡＰメッセージ又はＲＲＣメッセージを用いて送信されてもよい。
　ステップＳ７２において、境界ＩＡＢノード３００－Ｂは、当該設定を適用する。書き替えテーブルには分類情報が存在するため、境界ＩＡＢノード３００－Ｂは、設定された書き替えテーブルをどの位置（ＩＡＢ－ＭＴ（３００－ＭＴ）又はＩＡＢ－ＤＵ（３００－ＤＵ））に設定すればよいか容易に判断できる。
　ステップＳ７３において、境界ＩＡＢノード３００－ＢのＢＡＰレイヤは、パケット（ＢＡＰ　Ｄａｔａ　ＰＤＵ）を、上位レイヤ又は前ホップノードから受信し、受信したパケットがヘッダ書き替え対象か否かを特定する。ＩＡＢ－ＭＴのＢＡＰ送信部（ＢＡＰ　Ｔｘ部）は、ＩＡＢ－ＭＴ（３００－ＭＴ）に設定されたヘッダ書き替えテーブル３５０－ＭＴを参照し、受信したパケットのＢＡＰヘッダに含まれるルーティングＩＤが、当該ヘッダ書き替えテーブル３５０－ＭＴの旧ルーティングＩＤと一致すれば、ヘッダ書き替え対象と特定してもよい。一方、当該ＢＡＰ送信部は、受信したパケットのＢＡＰヘッダに含まれるルーティングＩＤと一致するルーティングＩＤが、当該ヘッダ書き替えテーブル３５０－ＭＴの旧ルーティングＩＤになければ、当該パケットはヘッダ書き替え対象ではないと特定してもよい。ＩＡＢ－ＤＵ（３００－ＤＵ）のＢＡＰ送信部も、同様に、ＩＡＢ－ＤＵ（３００－ＤＵ）に設定されたヘッダ書き替えテーブル３５０－ＤＵを参照し、受信したパケットのＢＡＰヘッダに含まれるルーティングＩＤが、当該ヘッダ書き替えテーブル３５０－ＤＵの旧ルーティングＩＤと一致すれば、当該パケットをヘッダ書き替え対象と特定し、一致するものがなければ、当該パケットをヘッダ書き替え対象ではないと特定してもよい。
　ステップＳ７４において、境界ＩＡＢノード３００－ＢのＢＡＰレイヤは、ヘッダ書き替え対象のパケットに対して、ヘッダ書き替え処理を行う。ＩＡＢ－ＭＴ（３００－ＭＴ）のＢＡＰ送信部は、ＩＡＢ－ＭＴ（３００－ＭＴ）に設定されたＭＴ用書き替えテーブル３５０－ＭＴ（例えば、第１ＣＵ間ルーティング用ヘッダ書き替えテーブル）を参照して、当該パケットのＢＡＰヘッダを、旧ルーティングＩＤから新ルーティングＩＤに書き替える。また、ＩＡＢ－ＤＵ（３００－ＤＵ）のＢＡＰ送信部は、ＩＡＢ－ＤＵ（３００－ＤＵ）に設定されたＤＵ用書き替えテーブル３５０－ＤＵ（例えば、第２ＣＵ間ルーティング用ヘッダ書き替えテーブル）を参照して、当該パケットのＢＡＰヘッダを、旧ルーティングＩＤから新ルーティングＩＤに書き替える。
　ステップＳ７５において、境界ＩＡＢノード３００－ＢのＢＡＰレイヤは、ルーティング設定に従って、ルーティング処理を行う。
　ステップＳ７６において、境界ＩＡＢノード３００－Ｂは、当該パケットを次ホップノードへ送信する。
　そして、ステップＳ７７において、一連の処理が終了する。
（第２実施形態に係る第２動作例）
　第２実施形態に係る第１動作例では、ＣＵ間ルーティング用のヘッダ書き替えテーブルを分類する例について説明した。第２実施形態に係る第２動作例では、ＣＵ間ルーティング用のヘッダ書き替えテーブルと、ＣＵ間リルーティング（又はＤＵ間リルーティング）用のヘッダ書き替えテーブルとを分類する例について説明する。
　ＩＡＢノード３００において、リルーティングが行われる場合がある。リルーティングは、例えば、受信したパケットに対してルーティング設定を用いてルーティング処理を行ったものの、何らかの原因で当該パケットを送信できなかった場合に行われる。リルーティングは、ルーティング処理の後に行われる。
　このようなリルーティングが、トポロジを跨いで行われる場合がある。例えば、境界ＩＡＢノード３００－Ｂにおいて、ＵＬ方向について、第１トポロジから流入したパケットを第１トポロジへルーティング処理を行ったものの、送信できなかったため、当該パケットを第２トポロジへリルーティングするなどである。この場合も、境界ＩＡＢノード３００－Ｂは、ヘッダ書き替え処理を行うことによって、第２トポロジへのリルーティングが可能となる。
　例えば、図１５の場合、境界ＩＡＢノード３００－Ｂは、ヘッダ書き替え処理により、ルーティングＩＤを変更することで、ＤｅｓｔｉｎａｔｉｏｎがＣＵ＃１（２００－Ｃ１）からＣＵ＃２（２００－Ｃ２）に変更される。このようにＣＵ間を跨いだリルーティングのことを、ＣＵ間リルーティング（ｉｎｔｅｒ－ＣＵ　ｒｅ－ｒｏｕｔｉｎｇ）と呼ぶ。
　例えば、図１５において、ＣＵ＃１がＤＵ＃１、ＣＵ＃２がＤＵ＃２であった場合、ヘッダ書き替え処理により、ルーティングＩＤが変更されることで、ＤｅｓｔｉｎａｔｉｏｎがＤＵ＃１からＤＵ＃２へ変更される場合もある。このように、ＤＵ間を跨いだリルーティングのことを、ＤＵ間リルーティング（ｉｎｔｅｒ－ｄｏｎｏｒ－ＤＵ　ｒｅ－ｒｏｕｔｉｎｇ）と呼ぶ。
　ＣＵ間リルーティング（ｉｎｔｅｒ－ＣＵ　ｒｅ－ｒｏｕｔｉｎｇ）とＤＵ間リルーティング（ｉｎｔｅｒ－ｄｏｎｏｒ－ＤＵ　ｒｅ－ｒｏｕｔｉｎｇ）とをまとめて、「ヘッダ書き替えベースリルーティング」と称する場合がある。ヘッダ書き替えベースリルーティングは、ＣＵ間リルーティングとＤＵ間リルーティングのうち少なくとも一方が含まれもよい。
　なお、同一トポロジ内でのリルーティングは、ローカルリルーティングと呼ばれる。
　ヘッダ書き替えベースリルーティングは、ルーティング処理を行ったものの、パケットを送信することができなかった場合に行われる。そのため、ヘッダ書き替えベースリルーティングは、ルーティング処理の後に行われる。
　他方、ＣＵ間ルーティングでは、ヘッダ書き替え処理を行った後で、ルーティング処理を行うことで、受信したパケットを異なるトポロジへ送信する。そのため、ＣＵ間ルーティングは、ルーティング処理の前に行われる。
　ここで、ＣＵ間ルーティング用のヘッダ書き替えテーブルと、ヘッダ書き替えベースリルーティング用のヘッダ書き替えテーブルとが、１つのテーブルにまとめられた場合を考える。この場合、境界ＩＡＢノード３００－Ｂでは、当該テーブル内にあるルーティングＩＤ（旧ルーティングＩＤ）について、ルーティング処理の前に処理すべきか、ルーティング処理の後に処理すべきかわからなくなる場合がある。そのため、境界ＩＡＢノード３００－Ｂでは、ＣＵ間ルーティングとヘッダ書き替えベースリルーティングとを適切行うことができない場合がある。
　そこで、第２実施形態に係る第２動作例では、ＣＵ間ルーティング用のヘッダ書き替えテーブルと、ヘッダ書き替えベースリルーティング用のヘッダ書き替えテーブルとを別分類とする例について説明する。
　具体的には、第１ヘッダ書き替えテーブルは、ＣＵ間ルーティング用ヘッダ書き替えテーブルであり、第２ヘッダ書き替えテーブルは、ヘッダ書き替えベースリルーティング用ヘッダ書き替えテーブルである。
　これにより、例えば、境界ＩＡＢノード３００－ＢのＢＡＰレイヤでは、２つのテーブルを区別してヘッダ書き替え処理を行うことができる。具体的には、ＢＡＰレイヤでは、ルーティング処理前のＣＵ間ルーティング処理を行うときにはＣＵ間ルーティング用のヘッダ書き替えテーブルを用い、ルーティング処理後のヘッダ書き替えベースリルーティング処理を行うときには、ヘッダ書き替えベースリルーティング用のヘッダ書き替えテーブルを用いることが可能となる。従って、境界ＩＡＢノード３００－Ｂは、ＣＵ間ルーティングとヘッダ書き替えベースリルーティングとを適切に行うことができる。
　なお、第３実施形態に係る第２動作例では、ＣＵ間ルーティング用のヘッダ書き替えテーブルを「ルーティング用ヘッダ書き替えテーブル」と称する場合がある。また、ヘッダ書き替えベースリルーティング用のヘッダ書き替えテーブルを「リルーティング用ヘッダ書き替えテーブル」と称する場合がある。
　図１９は、第３実施形態に係る第２動作例を表す図である。
　図１９に示すように、ステップＳ８０において、ドナーノード２００は処理を開始する。
　ステップＳ８１において、ドナーノード２００は、境界ＩＡＢノード３００－Ｂに対して、ルーティング用ヘッダ書き替えテーブルと、リルーティング用ヘッダ書き替えテーブルとで、異なる分類情報を有するように各テーブルを設定する。例えば、ドナーノード２００は、第１分類情報を有するルーティング用ヘッダ書き替えテーブルと、第２分類情報を有するリルーティング用ヘッダ書き替えテーブルとを、境界ＩＡＢノード３００－Ｂに設定する。
　分類情報は、２つの書き替えテーブルに対して、ｒｏｕｔｉｎｇ用（又はＣＵ間ルーティング用）とｒｅ－ｒｏｕｔｉｎｇ用（又はヘッダ書き替えベースリルーティング用）という情報であってもよい。この場合、分類情報が各書き替えテーブルに紐づけられる。また、分類情報は、２つの書き替えテーブルを区別する名称であてもよい。例えば、「ＢＡＰ　Ｈｅａｄｅｒ　Ｒｅｗｒｉｔｉｎｇ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　ｆｏｒ　ｒｏｕｔｉｎｇ」と「ＢＡＰ　Ｈｅａｄｅｒ　Ｒｅｗｒｉｔｉｎｇ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　ｆｏｒ　ｒｅ－ｒｏｕｔｉｎｇ」とであってもよい。更に、書き替えテーブル自体は１つのテーブルとし、各エントリ（例えば、旧ルーティングＩＤと新ルーティングＩＤとからなるエントリ）に対して、ｒｏｕｔｉｎｇ用とｒｅ－ｒｏｕｔｉｎｇ用という分類情報を紐づけてもよい。
　なお、分類情報を有する各書き替えテーブルは、例えば、Ｆ１ＡＰメッセージ又はＲＲＣメッセージを用いて送信されてもよい。
　ステップＳ８２において、境界ＩＡＢノード３００－Ｂは、当該設定を適用する。
　ステップＳ８３において、境界ＩＡＢノード３００－ＢのＢＡＰレイヤは、上位レイヤ又は前ホップノードから、パケット（ＢＡＰ　Ｄａｔａ　ＰＤＵ）を受信する。
　ステップＳ８４において、ＢＡＰレイヤは、当該パケットに対して、ＣＵ間ルーティング用のヘッダ書き替え処理を行ってもよい。ＢＡＰレイヤは、ルーティング用ヘッダ書き替えテーブルを参照して、当該パケットのルーティングＩＤと同一の旧ルーティングＩＤがあれば、ＣＵ間ルーティング用のヘッダ書き替え処理を行う。ＢＡＰレイヤは、ルーティング用ヘッダ書き替えテーブルに分類情報が含まれるため、当該テーブルを容易に判別できる。ただし、ＢＡＰレイヤは、このタイミングにおいては、リルーティング用ヘッダ書き替えテーブルを参照することはなく、ヘッダ書き替えベースリルーティングを行わない。
　ステップＳ８５において、ＢＡＰレイヤは、ルーティング処理及び／又はリルーティング処理を行う。このタイミングでのリルーティング処理は、ローカルリルーティング処理である。すなわち、ＢＡＰレイヤは、ルーティング処理を行ったものの、再び、ステップＳ８５に移行して、ローカルリルーティング処理を行う場合である。
　ステップＳ８６において、ＢＡＰレイヤは、ルーティング及び／又はリルーティングに失敗する。
　ここで、「ルーティングに失敗した」とは、ある評価条件において、次ホップアドレス（Ｎｅｘｔ　Ｈｏｐ　ＢＡＰアドレス）が選択できなかった場合を意味してもよい。評価条件は、パケットのヘッダとルーティングテーブル（ｒｏｕｔｉｎｇ　ｃｏｎｆｉｇｕｒａｔｉｏｎ）とにおいて、Ｄｅｓｔｉｎａｔｉｏｎ及びパスＩＤが一致するか否かであってもよい。又は、評価条件は、パケットのヘッダとルーティングテーブルとにおいて、Ｄｅｓｔｉｎａｔｉｏｎのみ一致するか否かであってもよい。
　ステップＳ８７において、ＢＡＰレイヤは、当該パケットがヘッダ書き替えベースリルーティング対象の場合、当該パケットに対して、リルーティング用ヘッダ書き替えテーブルを用いて、ヘッダ書き替え処理を行う。ＢＡＰレイヤは、当該パケットが、ヘッダ書き替えベースリルーティング対象か否かを特定してもよい。すなわち、ＢＡＰレイヤは、当該パケットのＢＡＰヘッダに含まれるルーティングＩＤと一致する旧ルーティングＩＤが、リルーティング用ヘッダ書き替えテーブルにあれば、ヘッダ書き替えベースリルーティング対象であると特定してもよい。一方、ＢＡＰレイヤは、当該パケットのＢＡＰヘッダに含まれるルーティングＩＤと一致する旧ルーティングＩＤが、リルーティング用ヘッダ書き替えテーブルになければ、ヘッダ書き替えベースリルーティング対象ではないと特定してもよい。ＢＡＰレイヤは、リルーティング用ヘッダ書き替えテーブルを参照して、当該パケットのＢＡＰヘッダを、旧ルーティングＩＤから新ルーティングＩＤに書き替える。
　ステップＳ８８において、ＢＡＰレイヤは、当該パケットに対して、ルーティング処理又はヘッダ書き替えベースリルーティング処理を行う。
　ステップＳ８９において、境界ＩＡＢノード３００－Ｂは、当該パケットを、ルーティング処理又はヘッダ書き替えベースリルーティング処理に従って、次ホップノードへ送信する。
　そして、ステップＳ９０において、一連の処理が終了する。
　なお、第３実施形態では、ＣＵ間リルーティングとＤＵ間リルーティングについては、共通のヘッダ書き替えテーブルを用いるものとする。そのため、第３実施形態では、ＣＵ間リルーティングとＤＵ間リルーティングとを分類するための分類情報は用いない。
[第４実施形態]
　次に、第４実施形態について説明する。
　１つのパケットに対して、何回もヘッダ書き替えが行われるケースがある。例えば、次のようなケースである。すなわち、境界ＩＡＢノード３００－Ｂは、当該パケットに対してＣＵ間ルーティングによりヘッダを書き替えたものの、ルーティングに失敗する。次に、境界ＩＡＢノード３００－Ｂは、当該パケットに対して、ＤＵ間リルーティングによりヘッダを書き替えたものの、再び、ルーティングに失敗する。
　ＣＵ間ルーティングに用いられるヘッダ書き替えテーブルも、ヘッダ書き替えベースリルーティングに用いられるヘッダ書き替えテーブルも、エントリに含まれる旧ルーティングＩＤは、ヘッダ書き替え前のルーティングＩＤであることが前提である。
　しかし、ヘッダ書き替えテーブルによりヘッダ書き替えが行われると、当該パケットのヘッダには書き替え後のルーティングＩＤが含まれることになる。このような場合に、書き替え後のルーティングＩＤに基づいて、ヘッダ書き替え処理を行うと、境界ＩＡＢノード３００－Ｂでは、ＣＵ間ルーティング又はヘッダ書き替えベースリルーティングを適切に行うことができない場合がある。
　そこで、第４実施形態では、ヘッダが書き替えられた後、ルーティング（又はリルーティング）に失敗した場合、当該パケットのヘッダを元のルーティングＩＤに戻す例について説明する。
　具体的には、第１に、境界中継ノード（例えば、境界ＩＡＢノード３００－Ｂ）が、ＣＵ間ルーティング用ヘッダ書き替えテーブルを用いてパケットに対してヘッダ書き替えを行った後、ルーティングに失敗したとき、書き替えたルーティングＩＤを書き替え前のルーティングＩＤに戻す。第２に、境界中継ノードが、リルーティング用ヘッダ書き替えテーブルを用いてパケットに対してヘッダ書き替えを行った後、ルーティングに失敗したとき、書き替えたルーティングＩＤを書き替え前のルーティングＩＤに戻す。
　これにより、ヘッダ書き替えによってヘッダが書き替えられても、ルーティングに失敗したときはルーティングＩＤが元のルーティングＩＤに戻されるため、境界ＩＡＢノード３００－Ｂでは、ＣＵ間ルーティング又はヘッダ書き替えベースリルーティングを適切に行うことができる。
（第４実施形態に係る動作例）
　図２０は、第４実施形態に係る動作例を表す図である。
　図２０に示すように、ステップＳ１００において、境界ＩＡＢノード３００－ＢのＢＡＰレイヤは、処理を開始する。
　ステップＳ１０１において、ＢＡＰレイヤは、パケットを受信する。
　ステップＳ１０２において、ＢＡＰレイヤは、当該パケットに対して、ＣＵ間ルーティングのヘッダ書き替え処理を行ってもよい。ルーティング用ヘッダ書き替えテーブルに、当該パケットのルーティングＩＤと一致する旧ルーティングＩＤが存在すれば、当該ヘッダ書き替え処理を行う。ＢＡＰレイヤは、ヘッダ書き替え処理を行った場合、ＣＵ間ルーティング用にヘッダ書き替え処理済であることを示す情報をメモリなどに記録(又は記憶)してもよい。もしくは、ＢＡＰレイヤは、ヘッダ書き替え処理済であることを示す情報をメモリなどに記録してもよい。
　ステップＳ１０３において、ＢＡＰレイヤは、当該パケットのルーティングに失敗する。ＢＡＰレイヤは、ＣＵ間ルーティングのヘッダ書き替え処理を行って、ルーティングに失敗した場合、ルーティングＩＤを元の旧ルーティングＩＤに戻す。また、この場合、ＢＡＰレイヤは、メモリなどに記録した書き替え処理済の情報を破棄（又は未処理と）してもよい。
　ステップＳ１０４において、ＢＡＰレイヤは、当該パケットに対して、ヘッダ書き替えベースリルーティングのヘッダ書き替え処理を行う。この際、ＢＡＰレイヤは、ＣＵ間リルーティング用、ＤＵ間リルーティング用、及びヘッダ書き替えベースリルーティング用のいずれかのヘッダ書き替え処理が処理済であることを示す情報をメモリなどに記録してもよい。もしくは、ＢＡＰレイヤは、ヘッダ書き替え処理済であることを示す情報を記録してもよい。
　ステップＳ１０５において、ＢＡＰレイヤは、ヘッダ書き替えベースリルーティング処理に失敗する。　
　ステップＳ１０６において、ＢＡＰレイヤは、ステップＳ１０４で書き替えた当該パケットのヘッダを、元のルーティングＩＤ（旧ルーティングＩＤ）に戻す（書き替える）。また、この場合、ＢＡＰレイヤは、メモリなどに記録した書き替え処理済の情報を破棄（又は未処理と）してもよい。
　ステップＳ１０７において、ＢＡＰレイヤは、当該パケットを、ルーティング処理などの所定のプロシージャに戻す。
　そして、ステップＳ１０８において、一連の処理が終了する。
（第４実施形態に係る他の動作例）
　次に、第４実施形態に係る他の動作例について説明する。上述した動作例では、ヘッダ書き替え後のルーティング失敗又はリルーティング失敗により、ヘッダを元のルーティングＩＤに戻す例を示したが、パケットを復元することで元のルーティングＩＤを復元してもよい。具体的には、ステップＳ１０１で、ＢＡＰレイヤがパケットを受信した時に、当該パケットのコピーをメモリに保存する。次に、ステップＳ１０３において、ＢＡＰレイヤは、ルーティングに失敗した場合、当該パケット（ヘッダ書き替え済）を破棄し、メモリから当該パケットのコピーを取得する。また、ステップＳ１０５において、ＢＡＰレイヤは、ヘッダ書き替えベースリルーティング処理に失敗した場合、当該パケット（ヘッダ書き替え済）を破棄し、メモリから当該パケットのコピーを取得する。これにより、境界ＩＡＢノード３００－Ｂでは、ヘッダを再度書き替えることなく、元のルーティングＩＤを復元することができる。
[第５実施形態]
　次に、第５実施形態について説明する。
　３ＧＰＰでは、ＣＵ間ルーティングについて、主に、ユーザデータを対象として検討されている。他方、Ｆ１－Ｃ（制御信号）トラフィックについても、ＣＵ間ルーティングは可能である。例えば、境界ＩＡＢノード３００－Ｂは、ＣＰ／ＵＰ分離（ＣＰ／ＵＰ　ｓｅｐａｒａｔｉｏｎ）機能を用いて、Ｆ１－ＣパケットをＲＲＣメッセージの中にカプセル化し、当該ＲＲＣメッセージをＳｐｌｉｔ　ＳＲＢ１で送信することで、Ｆ１－Ｃパケットを第１トポロジへ又は第２トポロジへ送信することは可能である。
　他方、境界ＩＡＢノード３００－Ｂは、自ノードで発生したユーザデータ（つまり、境界ＩＡＢノード３００－ＢがアクセスＩＡＢノードとして、ＵＥ１００から直接受信したデータ）についても、ＣＵ間ルーティングを行うケースが考えられる。
　図２１は、第５実施形態に係る境界ＩＡＢノード３００－Ｂの例を表す図である。
　一般に、アクセスＩＡＢノードでは、ＢＡＰヘッダを作成して、ドナーノード２００へ向けて、パケットを送信する。例えば、アクセスＩＡＢノードは、以下のようにして、ＢＡＰヘッダを作成する。
　すなわち、アクセスＩＡＢノードは、上りトラフィックマッピング設定(Ｕｐｌｉｎｋ　Ｔｒａｆｆｉｃ　ｔｏ　Ｒｏｕｔｉｎｇ　ＩＤ　Ｍａｐｐｉｎｇ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ)が、ドナーノード２００から設定される。上りトラフィックマッピング設定には、トラフィックタイプ識別子（ｔｒａｆｆｉｃ　ｔｙｐｅ　ｓｐｅｃｉｆｉｅｒ）とＢＡＰルーティングＩＤとが含まれる。なお、上りトラフィックマッピング設定は、Ｆ１ＡＰメッセージによりドナーノード２００から送信される。
　アクセスＩＡＢノードのＢＡＰレイヤは、上位レイヤから受信したＢＡＰ　ＳＤＵがＦＩ－Ｕトラフィックの場合、ＢＡＰ　ＳＤＵのＤｅｓｔｉｎａｔｉｏｎ　ＩＰアドレスとＴＥＩＤ（Tunnel Endpoint Identifier）とに対応するトラフィックタイプ識別子を含むエントリを、上りトラフィックマッピング設定から選択する。一方、ＢＡＰレイヤは、ＢＡＰ　ＳＤＵがＦ１－Ｕトラフィックではない場合、ＢＡＰ　ＳＤＵのトラフィックタイプ識別子を含むエントリを、上りトラフィックマッピング設定から選択する。
　次に、ＢＡＰレイヤは、当該エントリのルーティングＩＤ（ＤｅｓｔｉｎａｔｉｏｎとパスＩＤ）を選択する。そして、ＢＡＰレイヤは、選択したルーティングＩＤを用いて、ＢＡＰヘッダを生成し、当該ＢＡＰ　ＳＤＵにＢＡＰヘッダを付与して、ＢＡＰ　ＰＤＵを生成する。
　ここで、アクセスＩＡＢノードでもある境界ＩＡＢノード３００－Ｂにおいて、ＣＵ間ルーティングを行う場合、以下のような課題がある。すなわち、現状の上りトラフィックマッピング設定は、基本的には、トラフィックタイプ識別子とＢＡＰルーティングＩＤの組が１組含まれる。この１つのＢＡＰルーティングＩＤを、２つのトポロジに割り当ててしまうと、２つのトポロジで当該ＢＡＰルーティングＩＤが存在すれば、境界ＩＡＢノード３００－Ｂは、当該ＢＡＰ　ＰＤＵをどちらのトポロジへ送信すればよいかわからなくなる。そのため、アクセスＩＡＢノードでは、適切にＣＵ間ルーティングを行うことができない場合がある。
　そこで、第５実施形態では、アクセスＩＡＢノードでもある境界ＩＡＢノード３００－Ｂが、ルーティングＩＤが適用されるトポロジの情報を含む上りトラフィックマッピング設定に基づいて、トポロジに紐づいたルーティングＩＤを選択する例について説明する。
　具体的には、第１に、ドナーノード（例えば、ドナーノード２００）が、境界中継ノード（例えば、境界ＩＡＢノード３００－Ｂ）に対して、パケット送信先のトポロジを含む上りトラフィックマッピング設定を設定する。第２に、境界中継ノードは、上りトラフィックマッピング設定に基づいて、トポロジに紐づいたルーティングＩＤを選択する。第３に、境界中継ノードは、ルーティングＩＤをヘッダに含むパケットを送信する。
　これにより、アクセスＩＡＢノードでもある境界ＩＡＢノード３００－Ｂは、ルーティングＩＤがどちらのトポロジ向けのルーティングＩＤかを把握できるため、そのトポロジに向けたパケットを適切に生成することができる。従って、アクセスＩＡＢノードでもある境界ＩＡＢノード３００－Ｂでは、適切にＣＵ間ルーティングを行うことができる。
（第５実施形態に係る動作例）
　図２２は、第５実施形態に係る動作例を表す図である。
　図２２に示すように、ステップＳ１１０において、ドナーノード２００は、処理を開始する。
　ステップＳ１１１において、ドナーノード２００は、アクセスＩＡＢノードでもある境界ＩＡＢノード３００－Ｂに対して、上りトラフィックマッピング設定を設定する。当該上りトラフィックマッピング設定には、既存のトラフィックタイプ識別子とＢＡＰルーティングＩＤとに加え、適用するトポロジ（又は送信先のトポロジ）の情報が含まれる。当該情報を、以下では、トポロジ情報と称する場合がある。
　すなわち、トポロジ情報は、ＭＣＧ又はＳＣＧであってもよい。例えば、パケット送信先がＭＣＧ又はＳＣＧであることを表す。また、トポロジ情報は、境界ＩＡＢノード３００－ＢのＢＡＰアドレスであってもよい。すなわち、境界ＩＡＢノード３００－ＢのＢＡＰアドレスには、第１トポロジから設定されたＢＡＰアドレスと第２トポロジから設定されたＢＡＰアドレスがある。トポロジ情報を、当該ＢＡＰアドレスとすることで、パケット送信先のトポロジが第１トポロジか第２トポロジかを識別することができる。更に、トポロジ情報は、Ｆ１－ＡＰを終端しているトポロジか、Ｆ１－ＡＰを終端していないトポロジかにより表されてもよい。
　なお、オプションとして、上りトラフィックマッピング設定に、ベアラＩＤが含まれてもよい。ベアラＩＤがパケット送信先を表している。例えば、トラフィックタイプ識別子がユーザデータの場合、ＢＡＰレイヤは、ベアラＩＤ毎に紐づいた送信先を選択してもよい。このように、ベアラＩＤ毎に異なる送信先となっていてもよい。
　トポロジ情報とベアラＩＤは、上りトラフィックマッピング設定内の各エントリに存在してもよい。また、当該トポロジ情報とベアラＩＤは、別設定であってもよい。例えば、トポロジ毎に異なる（２つの）上りトラフィックマッピング設定が境界ＩＡＢノード３００－Ｂに通知されてもよい。
　ステップＳ１１２において、境界ＩＡＢノード３００－ＢのＢＡＰレイヤは、上位レイヤからＢＡＰ　ＳＤＵを受信する。
　ステップＳ１１３において、ＢＡＰレイヤは、当該ＢＡＰ　ＳＤＵに対応するエントリを、上りトラフィックマッピング設定から選択する。
　ステップＳ１１４において、ＢＡＰレイヤは、上りトラフィックマッピング設定から、当該エントリに紐づいたトポロジ（又はパケット送信先）を特定する。
　ステップＳ１１５において、ＢＡＰレイヤは、当該エントリ及び／又はトポロジに紐づいたルーティングＩＤを選択する。
　ステップＳ１１６において、ＢＡＰレイヤは、当該ルーティングＩＤを用いてＢＡＰヘッダを生成し、生成したＢＡＰヘッダを、ＢＡＰ　ＳＤＵに付与して、ＢＡＰ　ＰＤＵを生成する。
　ステップＳ１１７において、ＢＡＰレイヤは、特定したトポロジに紐づいたルーティング設定を選択し、ルーティング処理を行う。
　ステップＳ１１８において、境界ＩＡＢノード３００－Ｂは、次ホップノードへ、当該パケットを送信する。
　そして、ステップＳ１１９において、境界ＩＡＢノード３００－Ｂは、一連の処理を終了させる。
［その他の実施形態］
　ＵＥ１００又はｇＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。
　また、ＵＥ１００又はｇＮＢ２００が行う各処理を実行する回路を集積化し、ＵＥ１００又はｇＮＢ２００の少なくとも一部を半導体集積回路（チップセット、ＳｏＣ：Ｓｙｓｔｅｍ　ｏｎ　ａ　ｃｈｉｐ）として構成してもよい。
　以上、図面を参照して一実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。上述した各実施形態、各動作例、各処理、又は各ステップは、矛盾しない範囲で組み合わせることも可能である。
　本開示で使用されている「に基づいて（ｂａｓｅｄ　ｏｎ）」、「に応じて（ｄｅｐｅｎｄｉｎｇ　ｏｎ）」という記載は、別段に明記されていない限り、「のみに基づいて」、「のみに応じて」を意味しない。「に基づいて」という記載は、「のみに基づいて」及び「に少なくとも部分的に基づいて」の両方を意味する。同様に、「に応じて」という記載は、「のみに応じて」及び「に少なくとも部分的に応じて」の両方を意味する。また、「取得する（ｏｂｔａｉｎ／ａｃｑｕｉｒｅ）」は、記憶されている情報の中から情報を取得することを意味してもよく、他のノードから受信した情報の中から情報を取得することを意味してもよく、又は、情報を生成することにより当該情報を取得することを意味してもよい。「含む（ｉｎｃｌｕｄｅ）」、「備える（ｃｏｍｐｒｉｓｅ）」、及びそれらの変形の用語は、列挙する項目のみを含むことを意味せず、列挙する項目のみを含んでもよいし、列挙する項目に加えてさらなる項目を含んでもよいことを意味する。また、本開示において使用されている用語「又は（ｏｒ）」は、排他的論理和ではないことが意図される。さらに、本開示で使用されている「第１」、「第２」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみがそこで採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。本開示において、例えば、英語でのａ，ａｎ，及びｔｈｅのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。
　本願は、米国仮出願第６３／２９６２３２号（２０２２年１月４日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
（付記１）
　導入
　ＲＡＮ２＃１１６ｅでは、ＮＲ向け統合アクセス（Ｉｎｔｅｇｒａｔｅｄ　Ａｃｃｅｓｓ）とバックホールの強化（ｅＩＡＢ）のワークアイテムにおいて、ルーティングとリルーティングの強化が大きく進展し、その合意内容はＴＳ３８．３４０の実行中のＣＲとして支持された。
　この付記では、ルーティング及びリルーティングの詳細について、合意事項と実行中のＣＲの上に、現時点で基本的と思われる事項を中心に議論している。
　議論
　Ｒｅｌ－１７では、図２３に示すように、ルーティング及びリルーティングは、ＣＵ内／ドナーＤＵ内（Ｒｅｌ－１６と同様）、ＣＵ内／ドナーＤＵ間及びＣＵ間などのさまざまなシナリオをカバーする必要がある。これらの機能強化は、ＩＡＢトポロジにおけるパケット転送の信頼性、柔軟性、及び低遅延化に貢献すると期待されるが、ＢＡＰルーティング／リルーティング動作にさらなる複雑さをもたらす可能性がある。したがって、すべてのシナリオに共通の手順を規定し、シナリオ固有の手順を可能な限り少なくすることが望ましい。この意味で、最も複雑なシナリオであるＣＰＵ間ルーティングを最初に検討し、その後、ＣＰＵ間ルーティングの手順が他のシナリオに適用（再利用）可能かどうかも検討する必要がある。
　ＣＵ間ルーティング
　ヘッダ書き替えの判定
　ＲＸまたはＴｘ動作でのモデリングに関する更なる検討が必要な事項
　現在実行中のＣＲでは、ヘッダ書き替えの判断は受信動作に置かれ、以下の更なる検討が必要な事項が取り込まれている。
　なお、ヘッダ書き替えの判定をＲＸ動作とＴＸ動作のどちらでモデル化するかは、議論することができる。
　技術的な観点からは、ヘッダ書き替えの判定は、受信動作、送信動作のいずれでモデル化されても動作可能である。しかし、仕様の観点からは、ＩＡＢ－ＭＴとＩＡＢ－ＤＵに２つのＢＡＰエンティティが存在する、すなわち、「ＩＡＢノードでは、ＢＡＰサブレイヤはＭＴ機能に１つのＢＡＰエンティティとＤＵ機能に別のコロケーションＢＡＰエンティティを含む」とされている。したがって、エンティティ間の機能依存は可能な限り最小にする必要がある。
　ヘッダ書き替えの判定は、送信動作への依存度が高いことが確認されている。実際、ヘッダ書き替えの判定結果は、以下のように受信動作に影響を与えない。すなわち、ヘッダ書き替えと判定されたかどうかに関わらず、パケットは送信部に配送される。
　その他
　境界ＩＡＢノードのＩＡＢ－ＤＵにおけるＢＡＰエンティティの受信部において、ヘッダ書き替え設定に、前ルーティングＩＤのＢＡＰアドレスがＤｅｓｔｉｎａｔｉｏｎフィールドに一致し、前ルーティングＩＤのＢＡＰパスアイデンティティがパスフィールドに一致するエントリがある場合（サブクラス５．２．Ｘで規定）、又は
　境界ＩＡＢノードのＩＡＢ－ＭＴにおけるＢＡＰエンティティの受信部分について、流入リンクがＳＣＧの場合は、
　ＢＡＰデータパケットをＢＡＰヘッダ書き替えのために考慮し、
　ＢＡＰデータパケットを、配置されたＢＡＰエンティティの送信部へ配送する。
　そして、その結果を以下のように送信動作に利用する。すなわち、ヘッダ書き替えの対象と判断されたパケットに対してのみ、ヘッダ書き替えを行う。
　ＢＡＰエンティティの送信部は、送信するＢＡＰ　Ｄａｔａ　ＰＤＵがある場合、以下の処理を行う。
　ＢＡＰ　Ｄａｔａ　ＰＤＵを受信するＢＡＰエンティティがＢＡＰヘッダを書き替える場合、ＢＡＰヘッダを書き替える。
　　流出リンクを決定するためのルーティングを行う。
　　流出ＢＨ　ＲＬＣチャネルを決定する。
　　このＢＡＰ　Ｄａｔａ　ＰＤＵを、選択された流出リンクの選択された流出ＢＨ　ＲＬＣチャネルに送信する。
　所見１：ヘッダ書き替えの判定結果は、受信動作には依存しないが、送信動作には影響を与える。
　この意味で、ヘッダ書き替えの判断は、Ｔｘ操作でモデル化されることが好ましい。ＢＡＰヘッダ書き替え操作の中で取り込むか、新しいセクションを設けるかについては更なる検討が必要である。
　提案１：ＣＵ間ルーティングについて、ＲＡＮ２は、ヘッダ書き替えの決定を送信動作でモデル化することに合意すべきである。
　ダウンストリームのトラフィックに関する更なる検討が必要な事項
　ヘッダ書き替えの必要性の判断方法の詳細については、ダウンストリームトラフィック、すなわち「境界ＩＡＢノードのＩＡＢ－ＭＴにおけるＢＡＰエンティティの受信部について、流入リンクがＳＣＧの場合はＢＡＰヘッダ書き替え用のＢＡＰデータパケットを考慮する」という別の更なる検討事項が取り込まれている。
　なお、ＳＮがＦ１終端ノードである場合の考慮を含め、トポロジ間移行／トポロジ冗長化／ＲＬＦ回復のための流入リンクを特定するためにＳＣＧが十分かどうかについて更なる検討が必要である。
　上述のように、ＳＣＧは、例えばＣＰ／ＵＰ分離のようなすべてのケースに適用できない可能性がある。そのため、ドナー側がどちらの流入リンク、すなわちＭＣＧ又はＳＣＧがヘッダ書き替え操作を必要とするかを明示的に示すことは、単純なことだと考えられる。
　提案２：ＣＵ間ルーティングについて、ドナー側がＩＡＢ－ＭＴにどの流入リンク、すなわちＭＣＧまたはＳＣＧのＢＡＰヘッダの書き替えが必要であるかを設定することにＲＡＮ２は合意すべきである。
　ヘッダ書き替え操作
　ヘッダ書き替えの設定に関する更なる検討が必要な事項
　ＲＡＮ２＃１１６ｅでは、設定の問題について議論し、更なる検討が必要な事項と以下の合意に達した。
　古いルーティングＩＤから新しいルーティングＩＤへのマッピング設定を書き替え、（すべての書き替えの場合）可能な書き替えを制限することについて、詳細は更なる検討が必要である。
　また、現在実行中のＣＲにおいて、以下の更なる検討事項が取り込まれている。
　Ｒ３合意に基づき、ＵＬとＤＬでヘッダ書き替え設定が異なるのか、どのように異なるのかについて更なる検討を行う。ＵＬトラフィックの場合、それらは参照する流出トポロジを示す必要がある。その表示は暗黙的であってもよい。
　現在の実行中のＣＲでは、「ＢＡＰデータＰＤＵがＢＡＰヘッダ書き替えの対象となる場合、ＢＡＰエンティティの送信部はＢＡＰヘッダ書き替え動作を行う」、すなわちヘッダ書き替えを決定した後にＴｘ部でヘッダ書き替えを行うこととされている。この場合、ＩＡＢ－ＤＵでは常にダウンストリーム用のヘッダ書き替え設定が使用され、ＩＡＢ－ＭＴではアップストリーム用のものが使用されるだけである。そこで、２つのヘッダ書き替えテーブルを定義し、それぞれＩＡＢ－ＤＵとＩＡＢ－ＭＴに関連付ける方が簡単であり、ヘッダ書き替えの判定動作と同様である。
　提案３：ＣＵ間ルーティングのために、ドナー側は、ＩＡＢ－ＤＵ（すなわちダウンストリーム）のＢＡＰエンティティのＴｘ部分に使用される２つのヘッダ書き替えテーブルとＩＡＢ－ＭＴ（すなわちアップストリーム）のそれぞれで境界ＩＡＢノードを構成することに合意すべきである。
　ヘッダ書き替え動作における更なる検討が必要な事項
　現在実行中のＣＲでは、ヘッダ書き替え動作は、送信動作、受信動作と同じレベルで取り込まれ、以下の記載が付されている。
　ＢＡＰヘッダ書き替えの方法を取り込むするために使用され、ＣＵ間ルーティング、ＣＵ間リルーティング、ドナーＤＵ間リルーティングのケースで使用することが可能である。本節の必要性／位置／詳細については、ＲＡＮ２がヘッダ書き替えの全ケースについて明確な合意を得た後に確認／改訂される。
　ヘッダ書き替え動作は、送信動作で参照されるため、送信動作の下に取り込む必要がある。
　提案４：ＲＡＮ２は、ヘッダ書き替え操作を送信操作の下で定義すること、すなわち、ＢＡＰ仕様書で合意すべきである。
　ルーティングテーブルの選択
　原則として、ドナーＣＵは自身のトポロジのルーティングテーブルを管理する。ＣＵ間シナリオでは、２つのドナーＣＵが境界ＩＡＢノードでのルーティングに関与し、これらのドナーＣＵは独立してルーティングテーブルを管理することが想定される。この意味で、境界ＩＡＢノードが、これらのドナーＣＵによって別々に管理される２つのルーティングテーブルで構成されることは単純なことである。
　提案５：ＲＡＮ２は、境界ＩＡＢノードが２つのルーティングテーブルで構成され、それぞれドナーＣＵと別のドナーＣＵによって管理されることに合意すべきである。
　提案５に合意する場合、境界ＩＡＢノードがルーティング処理中のトラフィックに適用するルーティングテーブルを選択する方法について議論する価値がある。ＣＵ間シナリオでは、図２に示すように、トポロジ内でルーティングされるトラフィック（レガシールーティングと同様、別名、非連結トラフィック）と、２つのトポロジにまたがってルーティングされるトラフィック（別名、連結トラフィック）の２つのトラフィックカテゴリがある。
　ＢＡＰエンティティのＴｘ部でルーティングを行うことを考えると、図２４に示すように、受信ソース（流入リンク）に関わらず、３つの送信方向（流出リンク）が存在することになる。
　図２４のトポロジ＃１の場合、トラフィックが連結されているかどうかに関わらず、ダウンストリームのトラフィックは常にレガシールーティングテーブルに従うことがわかる。このため、境界ＩＡＢノードはダウンストリームトラフィックのルーティングにレガシールーティングテーブルを適用する必要がある。
　提案６：ダウンストリームパケットについて、ＲＡＮ２は境界ＩＡＢノードが常にレガシールーティングテーブルを選択することに合意すべきである。
　アップストリームのトラフィックについては、パケットがどのトポロジで送信されるかによって、適用できるルーティングテーブルが異なる。現在実行中のＣＲにあるように、結合されたトラフィックはルーティング処理の前にヘッダが書き替えられていると考えると、境界ＩＡＢノードは次のように適切なルーティングテーブルを選択することができる。
　ヘッダを書き替えないパケットには、レガシールーティングテーブル（図２４のトポロジ＃１の場合）が選択される。
　ヘッダを書き替えたパケットに対して、新しいルーティングテーブル（図２４のトポロジ＃２の場合）が選択される。
　適切なルーティングテーブルが選択されると、パケットは既存のルーティング手順によって処理される。
　提案７：アップストリームパケットについて、ＲＡＮ２は、ルーティング処理中のパケットがヘッダを書き替えたかどうかに応じて、境界ＩＡＢノードがレガシールーティングテーブルまたは新しいルーティングテーブルのいずれかを選択することに合意すべきである。
　ＣＵ間リルーティングとドナーＤＵ間リルーティング
　ヘッダ書き替えによるリルート動作の条件
　現在実行中のＣＲでは、ヘッダ書き替えによるリルーティングの条件として、以下の更なる検討が必要な事項が取り込まれている。
　上記の「ヘッダ書き替えテーブル（リルーティング用）が設定されている場合」は、「ヘッダ書き替えテーブルに、前回のルーティングＩＤのＢＡＰアドレスがＤｅｓｔｉｎａｔｉｏｎフィールドと一致し、前回のルーティングＩＤのＢＡＰパスＩＤがパスフィールドと一致するエントリがある場合」と修正する必要がある。
　この問題は、リルーティング（＝ＣＰＵ間リルーティング、ドナーＤＵ間リルーティング）用のヘッダ書き替えテーブルが、ルーティング（＝ＣＰＵ間ルーティング）用のものと分離されているかどうかに関係するものである。ルーティング用のヘッダ書き替えはルーティング手順の前に行われ、リルート用のヘッダ書き替えはルーティング手順の後に行われる。つまり、ルーティング用ヘッダ書き替えはルーティング用ヘッダ書き替えテーブルに基づいて行い、リルート用ヘッダ書き替えはリルート用ヘッダ書き替えテーブルに基づいて行う必要がある。同じヘッダ書き替えテーブルを想定すると、古いルーティングＩＤをルーティング手順の前と後、すなわちルーティング用とリルーティング用のどちらのヘッダ書き替えを行うかで、境界ＩＡＢノードが混乱する可能性があるからである。そのため、リルーティング用のヘッダ書き替えテーブルとルーティング用のヘッダ書き替えテーブルを分離することが望ましい。
　所見２：ルーティング用ヘッダ書き替え動作は、ルーティング用ヘッダ書き替え設定に基づくルーティング手順の前に行われ、リルーティング用ヘッダ書き替え動作は、リルーティング用ヘッダ書き替え設定に基づくルーティング手順の後に行われる。
　また、ＣＵ間リルーティングとドナーＤＵ間リルーティングのヘッダ書き替えテーブルを分離する必要があるかどうかについても問題である。ＣＵ間リルーティングとドナーＤＵ間リルーティングは、どちらもリルーティングのためのシナリオであるため、同じヘッダ書き替えテーブルを使用することができると考えることができる。また、ＣＵ間リルーティング、ドナーＤＵ間リルーティングともに、アップストリームトラフィックのみを対象とすることを想定している。そのため、リルーティングのためのヘッダ書き替えテーブルは、アップストリームとダウンストリームを区別する必要はない。
　しかし、ＣＵ間リルーティングは、この時点で異なるＩＡＢドナー、すなわち異なるトポロジに向けてＲＲＣ復元を行うため（すなわち、過渡的状態）、一方、ドナーＤＵ間リルーティングは、同じトポロジ内の異なるＩＡＢドナーＤＵに宛先ＢＡＰアドレスを変更するだけ（すなわち、静的状態）、経路関連の設定の観点からいくつかの違いがある可能性がある。したがって、さらなる合意が得られるまで、現時点では更なる検討が必要な事項としておくべきだろう。
　以上の所見から、少なくともルーティング用のヘッダ書き替えテーブルとは別に、リルーティング用のヘッダ書き替えテーブルを定義することが望ましい。
　提案８：ＲＡＮ２は、ＣＵ間リルーティングとドナーＤＵ間リルーティングのヘッダ書き替えテーブルが、ＣＵ間ルーティングのテーブルとは別物であることに合意すべきである。共通のヘッダ書き替えテーブルが両方のリルーティングシナリオに適用されるかどうかについては更なる検討が必要である。
　流出リンク選択前後のヘッダ書き替え
　現在実行中のＣＲにおいて、以下の更なる検討が必要な事項が取り込まれている。
　ＲＡＮ２がヘッダ書き替えに基づくＵＬリルーティングの場合、流出リンク選択後にヘッダ書き替えを行うことに合意すれば、上記を修正することができる。
　流出リンクの選択はルーティング手順の中で行われ、ヘッダの書き替え操作はルーティング手順の前に行われることが前提であり、つまり、流出リンクの選択とヘッダの書き替え操作は現在分離されているのである。そのため、これらの処理が混在すると複雑になる。
　また、ＲＡＮ２＃１１６ｅでは、トポロジ内（ドナーＤＵ間リルーティング）において、リルーティングのためのＢＡＰヘッダ書き替えの事前条件はＲｅｌ－１６と同様、すなわち、流出リンク選択との条件なし、として以下のように合意された。
　トポロジ内
　アップストリームの場合、「ＢＡＰヘッダ書き替えによるリルーティング」の前提条件／基準は、Ｒ１６と同様に、ＢＡＰルーティングＩＤに基づき、かつルーティングテーブルのＢＡＰアドレスに基づく利用可能な次ホップが見つからないこと（ＢＨ　ＲＬＦや輻輳、Ｔｙｐｅ－２　Ｉｎｄｉｃａｔｉｏｎなどによる）である。
　ＣＵ間リルーティングにおけるヘッダ書き替えについて、異なる前提条件を考慮することは合理的でない。そこで、ドナーＤＵ間リルーティングとＣＵ間リルーティングの両方に上記の合意を適用すべきである。
　提案９：ＲＡＮ２は、Ｒｅｌ－１６と同様にルーティング手順内で流出リンクの選択が行われること、すなわち流出リンク選択の前にヘッダの書き替えが行われることに合意すべきである。
　ヘッダ書き替え前の流出リンク選択の利点は、ヘッダ書き替え後にパケットのリルーティングに失敗した場合を回避することである。つまり、ＣＵ間リルーティングやドナーＤＵ間リルーティングに失敗した場合、ヘッダ書き替えを行ったパケットはヘッダ書き替えを行うのかどうか、つまり、１つのパケットに対して何回ヘッダ書き替えを行うのかどうかは不明である。ヘッダ書き替えを複数回行うと、誤操作のリスクや複雑さが生じる可能性がある。
　このシナリオでは、すなわち、ＣＵ間またはドナーＤＵ間のリルーティングが失敗した場合、フロー制御フィードバックの受信によって、ＩＡＢノードが輻輳のために利用可能なリンクを持っていないと仮定される。この場合、パケットは先に輻輳から回復した流出リンクを経由して送信されることになる。したがって、パケットは、回復した流出リンクに応じて、古いルーティングＩＤまたは新しいルーティングＩＤのいずれかを持つことが望ましい。
　以上の議論から、ヘッダ書き替えに基づくリルーティングに失敗した場合、ヘッダを新しいルーティングＩＤから古いルーティングＩＤに戻すという方法が考えられる。このようにすれば、パケットは元の状態、すなわちヘッダに古いルーティングＩＤを持つ状態に戻り、ＢＡＰエンティティの送信動作の最初から処理されることができる。このパケットに対して再度ルーティングを行うことを意味し、ルーティングに失敗した場合にはリルーティングを行うことができる。
　提案１０：ＲＡＮ２は、ヘッダ書き替えに基づくリルーティング（すなわち、ＣＵ間リルーティングまたはドナーＤＵ間リルーティング）が失敗した場合に、ヘッダを戻すかどうかを議論すべきである。
　ヘッダ書き替えに基づくリルーティングのモデル化
　Ｒｅｌ－１６では、ルーティングとリルートはルーティングプロセス内でモデル化される。つまり、リルートはルーティングに従う。
　ＢＡＰアドレスがＤｅｓｔｉｎａｔｉｏｎフィールドと一致し、ＢＡＰパスＩＤがパスフィールドと一致し、次ホップアドレスに対応する流出リンクが利用可能なエントリがＢＨルーティング設定に存在する場合、
　そのエントリの次ホップアドレスに対応する流出リンクを選択する。
　ＢＡＰアドレスがＤｅｓｔｉｎａｔｉｏｎフィールドと一致し、次ホップアドレスに対応する流出リンクが利用可能なエントリがＢＨルーティング設定に少なくとも１つ存在する場合、
　ＢＡＰアドレスがＤｅｓｔｉｎａｔｉｏｎフィールドと同じで、次ホップアドレスに対応する流出リンクが利用可能なエントリをＢＨルーティング設定から選択する。
　上記で選択したエントリの次ホップアドレスに対応する流出リンクを選択する。
　現在実行中のＣＲでは、ヘッダ書き替えに基づくリルーティングは、同じモデリング、すなわち、Ｒｅｌ－１６リルーティングに従うものを適用している。
　それ以外の場合は、ヘッダ書き替え設定（リルーティング用）が設定され、少なくとも１つの流出リンクが利用可能である場合、
　ＢＡＰヘッダ書き替え操作を行う。
　ＢＨルーティング設定に、ＢＡＰアドレスがＤｅｓｔｉｎａｔｉｏｎフィールドと一致し、ＢＡＰパスＩＤがパスフィールドと一致し、次ホップアドレスに対応する流出リンクが存在する場合、
　そのエントリの次ホップアドレスに対応する流出リンクを選択する。
　上記のように、Ｒｅｌ－１６ルーティングとＲｅｌ－１７ヘッダ書き替えベースのリルーティングは同じ文章、つまりルーティング手順を再度実行するように見受けられる。そのため、簡略化する候補として考えてもよい。
　また、Ｒｅｌ－１６のローカルリルートは、ルーティング手順の中でリルートが行われるため、明確ではなかった。そこで、ルーティングからリルーティングのセクションを分離することも可能なオプションかもしれない。
　提案１１：ＲＡＮ２は、仕様をより明確にするために、リルーティングのモデリングを簡略化する方法を議論すべきである。
　機能強化の概要
　上記の提案に合意できる場合、すべてのシナリオに対する統合解決策の例を図２５に、またヘッダ書き替えテーブルとルーティングテーブルの概要を表１に示す。
Figure JPOXMLDOC01-appb-T000001
  
　全シナリオの構成強化の概要
（付記２）
　上述の実施形態に関する特徴について記載する。
（１）
　セルラ通信システムで用いる通信制御方法であって、
　ドナーノードが、トポロジ内の中継ノードに対して、ルーティング設定に関するメッセージを送信するステップと、
　前記中継ノードが、前記メッセージを受信したことに応じて第１の処理を行うステップと、を有する
　通信制御方法。
（２）
　前記送信するステップは、
　　前記ドナーノードが、前記トポロジ内の前記中継ノードに対してルーティング設定の変更を開始したことに応じて、ルーティング設定変更開始メッセージをアクセス中継ノードへ送信するステップと、
　　前記ドナーノードが、前記トポロジ内の前記中継ノードに対してルーティング設定の変更を完了したことに応じて、ルーティング設定変更完了メッセージを前記アクセス中継ノードへ送信するステップと、を含み、
　前記第１の処理を行うステップは、
　　アクセス中継ノードが、前記ルーティング設定変更開始メッセージと前記ルーティング設定変更完了メッセージとに基づいて、アップストリーム方向において一定期間過去に送信したパケットを再送信するステップを含む、
　上記（１）に記載の通信制御方法。
（３）
　前記送信するステップは、
　　前記ドナーノードが、前記トポロジ内の前記中継ノードに対して、ルーティング停止指示メッセージを送信するステップを含み、
　前記第１の処理を行うステップは、
　　前記中継ノードが、前記ルーティング停止指示メッセージに従って、ルーティング処理を停止するとともに、受信したパケットをメモリに保持するステップを含み、
　更に、前記ドナーノードが、前記中継ノードに対して、ルーティング設定を変更し、ルーティング設定変更前のルーティングＩＤとルーティング設定変更後のルーティングＩＤとのマッピング情報を送信するステップと、
　前記中継ノードが、ルーティング処理を再開し、前記マッピング情報に従って、前記メモリに保持した前記パケットのヘッダを書き替えて送信するステップと、を有する
　上記（１）に記載の通信制御方法。
（４）
　セルラ通信システムで用いる通信制御方法であって、
　ドナーノードが、ダウンストリームリンクを指定した指定情報を、境界中継ノードへ送信するステップと、
　前記境界中継ノードが、前記指定情報に従って、前記ダウンストリームリンクから流入したパケットに対してヘッダ書替え処理を行うステップと、を有する、
　通信制御方法。
（５）
　セルラ通信システムで用いる通信制御方法であって、
　ドナーノードが、境界中継ノードに対して、第１分類情報を有する第１ヘッダ書き替えテーブルと、第２分類情報を有する第２ヘッダ書き替えテーブルを設定するステップと、
　前記境界中継ノードが、前記第１ヘッダ書き替えテーブルと前記第２ヘッダ書き替えテーブルの少なくともいずれかを用いて、パケットに対してヘッダ書き替え処理を行うステップと、を有する、
　通信制御方法。
（６）
　前記第１ヘッダ書き替えテーブルは、前記境界中継ノードのユーザ装置機能部（ＩＡＢ－ＭＴ）で使用する第１ＣＵ間ルーティング用ヘッダ書き替えテーブルであり、前記第２ヘッダ書き替えテーブルは、前記境界中継ノードの基地局機能部（ＩＡＢ－ＤＵ）で使用する第２ＣＵ間ルーティング用ヘッダ書き替えテーブルであって
　前記ヘッダ書き替え処理を行うステップは、前記ユーザ装置機能部が、前記第１ＣＵ間ルーティング用ヘッダ書き替えテーブルを参照して前記パケットに対してヘッダ書き替えを行い、前記基地局機能部が、前記第２ＣＵ間ルーティング用ヘッダ書き替えテーブルを参照して前記パケットに対してヘッダ書き替えを行うステップを含む、
　上記（５）に記載の通信制御方法。
（７）
　前記第１ヘッダ書き替えテーブルは、ＣＵ間ルーティング用のヘッダ書き替えテーブルであり、前記第２ヘッダ書き替えテーブルは、ヘッダ書き替えベースリルーティング用のヘッダ書き替えテーブルである、
　上記（５）に記載の通信制御方法。
（８）
　前記ヘッダ書き替え処理を行うステップは、
　　前記境界中継ノードが、前記ＣＵ間ルーティング用ヘッダ書き替えテーブルを用いて前記パケットに対してヘッダ書き替えを行った後、ルーティングに失敗したとき、書き替えたルーティングＩＤを書き替え前のルーティングＩＤに戻すステップと、
　　前記境界中継ノードが、前記リルーティング用ヘッダ書き替えテーブルを用いて前記パケットに対してヘッダ書き替えを行った後、ルーティングに失敗したとき、書き替えたルーティングＩＤを書き替え前のルーティングＩＤに戻すステップと、を含む、
　上記（７）に記載の通信制御方法。
（９）
　セルラ通信システムで用いる通信制御方法であって、
　ドナーノードが、境界中継ノードに対して、パケット送信先のトポロジを含む上りトラフィックマッピング設定を設定するステップと、
　前記境界中継ノードが、前記上りトラフィックマッピング設定に基づいて、前記トポロジに紐づいたルーティングＩＤを選択するステップと、
　前記境界中継ノードが、前記ルーティングＩＤをヘッダに含む前記パケットを送信するステップと、を有する、
　通信制御方法。

Claims (7)

  1. 　セルラ通信システムで用いる通信制御方法であって、
    　境界中継ノードが、流入リンクに関する設定情報を、ネットワークから受信することと、
    　前記境界中継ノード、前記設定情報に基づいて、前記流入リンクが対応するトポロジを特定することと、
    　前記境界中継ノードが、前記流入リンクが対応するトポロジが所定のトポロジである場合、前記ネットワークから受信したヘッダ書き替え設定情報に基づいて、前記流入リンクから流入したパケットに対してヘッダ書替え処理を行うことと、を有する、
    　通信制御方法。
  2. 　前記境界中継ノードは、第１トポロジを管理する第１ドナーノードとのF1接続を有するとともに、第２トポロジを管理する第２ドナーノードとのRRC接続を有し、
    　前記所定のトポロジは、前記第２トポロジである
    　請求項１に記載の通信制御方法。
  3. 　セルラ通信システムで用いる通信制御方法であって、
    　境界中継ノードが、トポロジとルーティングＩＤとの対応付けを示す設定情報をネットワークから受信することと、
    　前記境界中継ノードが、ネットワークから受信した設定情報に基づいて、パケット送信先のトポロジに紐づいたルーティングＩＤを決定することと、
    　前記境界中継ノードが、前記ルーティングＩＤをヘッダに含む前記パケットを送信することと、を有する、
    　通信制御方法。
  4. 　境界中継ノードであって、
    　流入リンクに関する設定情報をネットワークから受信する受信部と、
    　前記設定情報に基づいて、前記流入リンクが対応するトポロジを特定する制御部と、
    　前記制御部は、前記流入リンクが対応するトポロジが所定のトポロジである場合、前記ネットワークから受信したヘッダ書き替え設定情報に基づいて、前記流入リンクから流入したパケットに対してヘッダ書替え処理を行う
    　境界中継ノード。
  5. 　境界中継ノードを制御するプロセッサであって、
    　流入リンクに関する設定情報をネットワークから受信する処理と、
    　前記設定情報に基づいて、前記流入リンクが対応するトポロジを特定する処理と、
    　前記流入リンクが対応するトポロジが所定のトポロジである場合、前記ネットワークから受信したヘッダ書き替え設定情報に基づいて、前記流入リンクから流入したパケットに対してヘッダ書替え処理を行う処理と、を実行する、
    　プロセッサ。
  6. 　境界中継ノードであって、
    　トポロジとルーティングＩＤとの対応付けを示す設定情報をネットワークから受信する受信部と、
    　ネットワークから受信した設定情報に基づいて、パケット送信先のトポロジに紐づいたルーティングＩＤを決定する制御部と、
    　前記ルーティングＩＤをヘッダに含む前記パケットを送信する送信部と、を備える
    　境界中継ノード。
  7. 　境界中継ノードを制御するプロセッサであって、
    　トポロジとルーティングＩＤとの対応付けを示す設定情報をネットワークから受信する処理と、
    　ネットワークから受信した設定情報に基づいて、パケット送信先のトポロジに紐づいたルーティングＩＤを決定する処理と、
    　前記ルーティングＩＤをヘッダに含む前記パケットを送信する処理と、を実行する
    　プロセッサ。
PCT/JP2022/047872 2022-01-04 2022-12-26 通信制御方法 WO2023132284A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202263296232P 2022-01-04 2022-01-04
US63/296,232 2022-01-04

Publications (1)

Publication Number Publication Date
WO2023132284A1 true WO2023132284A1 (ja) 2023-07-13

Family

ID=87073637

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/047872 WO2023132284A1 (ja) 2022-01-04 2022-12-26 通信制御方法

Country Status (1)

Country Link
WO (1) WO2023132284A1 (ja)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021206011A1 (ja) * 2020-04-09 2021-10-14 京セラ株式会社 通信制御方法及び中継ノード

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021206011A1 (ja) * 2020-04-09 2021-10-14 京セラ株式会社 通信制御方法及び中継ノード

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
FUTUREWEI: "Analysis of some remaining issues for inter-donor & inter-topology routing", 3GPP DRAFT; R2-2111203, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. electronic; 20211101 - 20211112, 22 October 2021 (2021-10-22), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP052067637 *
KYOCERA: "BAP open issues on BAP#01, BAP#03 and BAP#04", 3GPP DRAFT; R2-2202908, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Online; 20220221 - 20220303, 14 February 2022 (2022-02-14), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP052110757 *
QUALCOMM INCORPORATED: "Status Report to TSG 1 Work plan related evaluation", 3GPP DRAFT; RP-212810, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. TSG RAN, no. Electronic Meeting; 20211206 - 20211217, 2 December 2021 (2021-12-02), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP052086070 *

Similar Documents

Publication Publication Date Title
WO2019214747A1 (zh) 一种配置方法、数据传输方法和装置
CN110636628B (zh) 信息传输方法及装置
CN110831095A (zh) 通信方法和通信装置
CA3170727A1 (en) Data packet transmission method and apparatus, communication node, and storage medium
US20220078661A1 (en) Network nodes and methods supporting multiple connectivity
JP7462026B2 (ja) 方法及び中継ノード
US20230388894A1 (en) Method and apparatus for packet rerouting
US20200412484A1 (en) NR User Plane Signaling Controlled Triggering of PDCP Duplication
GB2602802A (en) Management of radio link failure and deficiencies in integrated access backhauled networks
WO2023132284A1 (ja) 通信制御方法
CN116671149A (zh) 通信控制方法
WO2023068255A1 (ja) 通信制御方法及び境界ｉａｂノード
WO2023068257A1 (ja) 通信制御方法
WO2023068256A1 (ja) 通信制御方法及び中継ノード
WO2023132283A1 (ja) 通信制御方法
WO2023149577A1 (ja) 通信制御方法
WO2023068258A1 (ja) 通信制御方法
WO2023013604A1 (ja) 通信制御方法
WO2023132285A1 (ja) 通信制御方法
WO2022234846A1 (ja) 通信制御方法
US20230262516A1 (en) Communication control method
US20240056940A1 (en) Management of radio link failure and deficiencies in integrated access backhauled networks
WO2023068254A1 (ja) 通信制御方法及び中継ノード
WO2023013603A1 (ja) 通信方法
US20240155461A1 (en) Communication control method

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: 22918868

Country of ref document: EP

Kind code of ref document: A1