Communication control method, relay node, cellular communication system, chipset, and program

Abstract

In a communication control method according to a first aspect: a relay node receives a packet in an upstream direction; and the relay node performs routing processing on the packet, on the basis of routing settings information that has a plurality of routing IDs. Routing processing includes performing inter-donor DU re-routing for the packet if an outgoing back haul link, corresponding to a routing ID that matches destination information included in a BAP header for the packet, is unavailable.

Description

Technical Field

[0001] The present disclosure relates to a communication control method used in a cellular communication system.

Background Art

[0002] In 3GPP (Third Generation Partnership Project), which is a standardization project for cellular communication systems, the introduction of a new relay node called an IAB (Integrated Access and Backhaul) node is being considered (see, for example, "3GPP TS 38.300 V16.7.0 (2021-09)"). One or more relay nodes are interposed in the communication between the base station and the user equipment and perform relay for this communication.

Summary of the Invention

[0003] The communication control method according to the first aspect includes: a relay node receiving an upstream packet; and the relay node performing routing processing on the packet based on routing setting information having a plurality of routing IDs. Performing the routing processing includes performing donor DU inter-routing on the packet when the outflow backhaul link corresponding to the routing ID that matches the destination information included in the BAP header of the packet is unavailable.

[0004] The relay node according to the second aspect is a relay node used in a cellular communication system. The relay node includes a receiving unit that receives an upstream packet, and a control unit that performs routing processing on the packet based on routing setting information having a plurality of routing IDs. In the routing processing, the control unit performs donor DU inter-routing on the packet when the outflow backhaul link corresponding to the routing ID that matches the destination information included in the BAP header of the packet is unavailable.

[0005] The communication control method according to the third aspect is a communication control method used in a cellular communication system. The communication control method includes a step in which a donor node sets a first destination address of a first donor node and a second destination address of a second donor node for a relay node. P The communication control method further includes a step in which the relay node receives an upstream packet. The communication control method further includes a step in which the relay node performs a routing process and determines that the packet cannot be transmitted to the next-hop relay node. The communication control method further includes a step in which, when a first routing ID including a BAP address that matches the first destination address of the packet does not exist in the routing table for the determined packet, the relay node selects a second routing ID including a BAP address that matches the second destination address from the routing table. The communication control method further includes a step in which the relay node writes the second routing ID into the header of the packet. Here, the second destination address is associated with the first destination address.

Brief Description of the Drawings

[0006] [Figure 1] FIG. 1 is a diagram showing a configuration example of a cellular communication system according to an embodiment. [Diagram 2] FIG. 2 is a diagram showing the relationship between IAB nodes, parent nodes, and child nodes. [Diagram 3] FIG. 3 is a diagram showing a configuration example of a gNB (base station) according to an embodiment. [Figure 4] FIG. 4 is a diagram showing a configuration example of an IAB node (relay node) according to an embodiment. [Diagram 5] FIG. 5 is a diagram showing a configuration example of a UE (user equipment) according to an embodiment. [Figure 6] FIG. 6 is a diagram showing an example of a protocol stack related to the RRC connection and NAS connection of an IAB-MT. [Figure 7]FIG. 7 is a diagram showing an example of a protocol stack related to the F1-U protocol. [Figure 8] FIG. 8 is a diagram showing an example of a protocol stack related to the F1-C protocol. [Figure 9] FIG. 9(A) is a diagram showing an example of the topology configuration in the "inside CU / inside donor DU" scenario, FIG. 9(B) is a diagram showing an example of the topology configuration in the "inside CU / between donor DUs" scenario, and FIG. 9(C) is a diagram showing an example of the topology configuration in the "between CUs" scenario. [Figure 10] FIG. 10 is a diagram representing the first operation example according to the first embodiment. [Figure 11] FIG. 11 is a drawing summarizing the first operation example according to the first embodiment. [Figure 12] FIG. 12 is a diagram representing the operation example according to Modification Example 4 of the first embodiment. [Figure 13] FIG. 13 is a diagram representing the second operation example according to the first embodiment. [Figure 14] FIG. 14 is a diagram representing an example of the configuration of the BAP Data PDU packet according to the first embodiment. [Figure 15] FIG. 15 is a diagram representing the third operation example according to the first embodiment. [Figure 16] FIG. 16 is a diagram representing the fourth operation example according to the first embodiment. [Figure 17] FIG. 17 is a diagram representing the fifth operation example according to the first embodiment. [Figure 18] FIG. 18 is a diagram representing the sixth operation example according to the first embodiment. [Figure 19] FIGS. 19(A) and 19(B) are diagrams representing an example of the topology configuration according to the second embodiment. [Figure 20] FIG. 20 is a diagram representing the operation example according to the second embodiment. [Figure 21] FIG. 21 is a diagram representing a modification example according to the second embodiment. [Figure 22] FIG. 22 is a diagram representing the first operation example according to the third embodiment. [Diagram 23] FIG. 23 is a diagram summarizing the first operation example according to the third embodiment. [Figure 24] FIG. 24 is a diagram showing a second operation example according to the third embodiment. [Diagram 25] FIG. 25 is a diagram showing a third operation example according to the third embodiment. [Figure 26] FIG. 26 summarizes the third operation example according to the third embodiment. [Figure 27] FIG. 27 shows a configuration example of an IAB node according to the fourth embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0007] A cellular communication system according to an embodiment will be described with reference to the drawings. In the description of the drawings, the same or similar parts are denoted by the same or similar reference numerals.

[0008] (Configuration of Cellular Communication System) A configuration example of a cellular communication system according to an embodiment will be described. A cellular communication system 1 according to an embodiment is a 3GPP 5G system. Specifically, the radio access method in the cellular communication system 1 is NR (New Radio), which is a 5G radio access method. However, LTE (Long Term Evolution) may be at least partially applied to the cellular communication system 1. Also, the cellular communication system 1 may be applied to future cellular communication systems such as 6G.

[0009] FIG. 1 is a diagram showing a configuration example of a cellular communication system 1 according to an embodiment.

[0010] As shown in FIG. 1, the cellular communication system 1 includes a 5G core network (5GC) 10, user equipment (UE) 100, base station devices (hereinafter sometimes referred to as "base stations") 200-1 and 200-2, and IAB nodes 300-1 and 300-2. The base station 200 may be called a gNB.

[0011] In the following, an example where the base station 200 is an NR base station will be mainly described, but the base station 200 may be an LTE base station (i.e., eNB).

[0012] Note that in the following, the base stations 200-1 and 200-2 may sometimes be referred to as gNB200 (or base station 200), and the IAB nodes 300-1 and 300-2 may sometimes be referred to as IAB node 300, respectively.

[0013] The 5GC 10 has an AMF (Access and Mobility Management Function) 11 and a UPF (User Plane Function) 12. The AMF 11 is a device that performs various mobility controls for the UE 100. The AMF 11 manages information on the area where the UE 100 is located by communicating with the UE 100 using NAS (Non-Access Stratum) signaling. The UPF 12 is a device that performs transfer control of user data.

[0014] Each gNB200 is a fixed radio communication node that manages one or more cells. A cell is a term used to indicate the smallest unit of a radio communication area. A cell may be used as a term to indicate a function or resource for performing radio communication with the UE 100. One cell belongs to one carrier frequency. In the following, the cell and the base station may sometimes be used without distinction.

[0015] Each gNB200 is interconnected with the 5GC 10 via an interface called the NG interface. In FIG. 1, two gNB200-1 and gNB200-2 connected to the 5GC 10 are illustrated as examples.

[0016] Each gNB 200 may be divided into a Central Unit (CU) and a Distributed Unit (DU). The CU and the DU are interconnected via an interface called the F1 interface. The F1 protocol is a communication protocol between the CU and the DU, and includes an F1-C protocol which is a protocol of the control plane and an F1-U protocol which is a protocol of the user plane.

[0017] The cellular communication system 1 supports IAB which enables wireless relaying of NR access using NR in the backhaul. The donor gNB 200-1 (or donor node. Hereinafter, it may be referred to as the "donor node") is a terminal node of the NR backhaul on the network side and is a donor base station equipped with additional functions to support IAB. The backhaul enables multi-hop via a plurality of hops (i.e., a plurality of IAB nodes 300).

[0018] In FIG. 1, an example is shown in which the IAB node 300-1 is wirelessly connected to the donor node 200-1, the IAB node 300-2 is wirelessly connected to the IAB node 300-1, and the F1 protocol is transmitted through two backhaul hops.

[0019] The UE 100 is a mobile wireless communication device that performs wireless communication with a cell. The UE 100 may be any device as long as it is a device that performs wireless communication with the gNB 200 or the IAB node 300. For example, the UE 100 is a mobile phone terminal, a tablet terminal, a notebook PC, a sensor or a device provided in a sensor, a vehicle or a device provided in a vehicle, an aircraft or a device provided in an aircraft. The UE 100 is wirelessly connected to the IAB node 300 or the gNB 200 via an access link. In FIG. 1, an example is shown in which the UE 100 is wirelessly connected to the IAB node 300-2. The UE 100 communicates indirectly with the donor node 200-1 via the IAB node 300-2 and the IAB node 300-1.

[0020] FIG. 2 is a diagram showing an example of the relationship between IAB node 300, parent nodes, and child nodes.

[0021] As shown in FIG. 2, 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.

[0022] An adjacent node (i.e., a higher-level node) on the NR Uu radio interface of the IAB-MT is called a parent node. The parent node is the DU of the parent IAB node or donor node 200. The radio link between the IAB-MT and the parent node is called a backhaul link (BH link). In FIG. 2, an example is shown where the parent nodes of IAB node 300 are IAB nodes 300-P1 and 300-P2. Note that the direction towards the parent node is called upstream. As seen from UE100, the higher-level node of UE100 may correspond to the parent node.

[0023] An adjacent node (i.e., a lower-level node) on the NR access interface of the IAB-DU is called a child node. The IAB-DU manages cells in the same way as gNB200. The IAB-DU terminates the NR Uu radio interface to UE100 and the lower-level IAB nodes. The IAB-DU supports the F1 protocol to the CU of donor node 200-1. In FIG. 2, an example is shown where the child nodes of IAB node 300 are IAB nodes 300-C1 to 300-C3, but UE100 may be included in the child nodes of IAB node 300. Note that the direction towards the child node is called downstream.

[0024] Also, all IAB nodes 300 connected to the donor node 200 via one or more hops form a directed acyclic graph (DAG) topology rooted at the donor node 200 (hereinafter sometimes referred to as the "topology"). In this topology, as shown in FIG. 2, adjacent nodes on the interface of the IAB-DU are child nodes, and adjacent nodes on the interface of the IAB-MT are parent nodes. The donor node 200 centrally performs, for example, resource, topology, and route management of the IAB topology. The donor node 200 is a gNB that provides network access to the UE 100 via a network of a backhaul link and an access link.

[0025] (Configuration of the base station) Next, the configuration of the gNB 200, which is a base station according to the embodiment, will be described. FIG. 3 is a diagram showing a configuration example of the gNB 200. As shown in FIG. 3, the gNB 200 includes a radio communication unit 210, a network communication unit 220, and a control unit 230.

[0026] The radio communication unit 210 performs radio communication with the UE 100 and radio communication with the IAB node 300. The radio communication unit 210 includes a reception unit 211 and a transmission unit 212. The reception unit 211 performs various receptions under the control of the control unit 230. The reception unit 211 includes an antenna, converts (down-converts) the radio signal received by the antenna into a baseband signal (received signal), and outputs it to the control unit 230. The transmission unit 212 performs various transmissions under the control of the control unit 230. The transmission unit 212 includes an antenna, converts (up-converts) the baseband signal (transmission signal) output by the control unit 230 into a radio signal, and transmits it from the antenna.

[0027] 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 unit 220 includes a receiving unit 221 and a transmitting unit 222. The receiving unit 221 performs various receptions under the control of the control unit 230. The receiving unit 221 receives a signal from the outside and outputs the received signal to the control unit 230. The transmitting unit 222 performs various transmissions under the control of the control unit 230. The transmitting unit 222 transmits the transmission signal output by the control unit 230 to the outside.

[0028] The control unit 230 performs various controls in the gNB 200. The control unit 230 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs executed by the processor and information used for the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals, etc. The CPU executes the programs stored in the memory to perform various processes. The processor performs the processing of each layer described later. Also, the control unit 230 may perform each process or each operation in the gNB 200 in each of the following embodiments.

[0029] (Configuration of Relay Node) Next, the configuration of the IAB node 300, which is a relay node (or relay node device; hereinafter, may be referred to as a "relay node") according to the embodiment, will be described. FIG. 4 is a diagram showing a configuration example of the IAB node 300. As shown in FIG. 4, the IAB node 300 has a wireless communication unit 310 and a control unit 320. The IAB node 300 may have a plurality of wireless communication units 310.

[0030] 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.

[0031] The wireless communication unit 310 includes a receiving unit 311 and a transmitting unit 312. The receiving unit 311 performs various receptions under the control of the control unit 320. The receiving unit 311 includes an antenna, converts (down-converts) the radio signal received by the antenna into a baseband signal (received signal), and outputs it to the control unit 320. The transmitting unit 312 performs various transmissions under the control of the control unit 320. The transmitting unit 312 includes an antenna, converts (up-converts) the baseband signal (transmitted signal) output by the control unit 320 into a radio signal, and transmits it from the antenna.

[0032] The control unit 320 performs various controls in the IAB node 300. The control unit 320 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs executed by the processor and information used for the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals, etc. The CPU executes programs stored in the memory to perform various processes. The processor performs the processing of each layer described later. Also, the control unit 320 may perform each process or each operation in the IAB node 300 in each of the following embodiments.

[0033] (Configuration of User Equipment) Next, the configuration of the UE100, which is a user equipment according to the embodiment, will be described. FIG. 5 is a diagram showing a configuration example of the UE100. As shown in FIG. 5, the UE100 includes a wireless communication unit 110 and a control unit 120.

[0034] The wireless communication unit 110 performs wireless communication on the access link, that is, wireless communication with the gNB 200 and wireless communication with the IAB node 300. Further, the wireless communication unit 110 may perform wireless communication on the sidelink, that is, wireless communication with other UEs 100. The wireless communication unit 110 includes a receiving unit 111 and a transmitting unit 112. The receiving unit 111 performs various receptions under the control of the control unit 120. The receiving unit 111 includes an antenna, converts (down-converts) the radio signal received by the antenna into a baseband signal (received signal), and outputs it to the control unit 120. The transmitting unit 112 performs various transmissions under the control of the control unit 120. The transmitting unit 112 includes an antenna, converts (up-converts) the baseband signal (transmitted signal) output by the control unit 120 into a radio signal, and transmits it from the antenna.

[0035] The control unit 120 performs various controls in the UE 100. The control unit 120 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs executed by the processor and information used for the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of the baseband signal, etc. The CPU executes the programs stored in the memory to perform various processes. The processor performs the processing of each layer described later. Further, the control unit 130 may perform each process in the UE 100 in each of the following embodiments.

[0036] (Configuration of the protocol stack) Next, the configuration of the protocol stack according to the embodiment will be described. FIG. 6 is a diagram showing an example of the protocol stack related to the RRC connection and NAS connection of the IAB-MT.

[0037] As shown in FIG. 6, the IAB-MT of the IAB node 300-2 has a physical (PHY) layer, a MAC (Medium Access Control) layer, an RLC (Radio Link Control) layer, a PDCP (Packet Data Convergence Protocol) layer, an RRC (Radio Resource Control) layer, and a NAS (Non-Access Stratum) layer.

[0038] The PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping. Between the PHY layer of the IAB-MT of the IAB node 300-2 and the PHY layer of the IAB-DU of the IAB node 300-1, data and control information are transmitted via a physical channel.

[0039] The MAC layer performs priority control of data, retransmission processing by hybrid ARQ (Hybrid Automatic Repeat reQuest), and random access procedures, etc. 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, data and control information are transmitted via a transport channel. The MAC layer of the IAB-DU includes a scheduler. The scheduler determines the uplink and downlink transport formats (transport block size, modulation and coding scheme (MCS: Modulation and Coding Scheme)) and the allocated resource blocks.

[0040] The RLC layer uses the functions of the MAC layer and the PHY layer to transmit data to the RLC layer on the receiving side. Between the RLC layer of the IAB-MT of the IAB node 300-2 and the RLC layer of the IAB-DU of the IAB node 300-1, data and control information are transmitted via a logical channel.

[0041] The PDCP layer performs header compression / expansion and encryption / decryption. Between the PDCP layer of the IAB-MT of the IAB node 300-2 and the PDCP layer of the donor node 200, data and control information are transmitted via radio bearers.

[0042] The RRC layer controls logical channels, transport channels, and physical channels in response to the establishment, re-establishment, and release of radio bearers. Between the RRC layer of the IAB-MT of the IAB node 300-2 and the RRC layer of the donor node 200, RRC signaling for various settings is transmitted. When there is an RRC connection with the donor node 200, the IAB-MT is in the RRC connected state. When there is no RRC connection with the donor node 200, the IAB-MT is in the RRC idle state.

[0043] The NAS layer located above the RRC layer performs session management, mobility management, etc. Between the NAS layer of the IAB-MT of the IAB node 300-2 and the AMF11, NAS signaling is transmitted.

[0044] Figure 7 is a diagram showing a protocol stack related to the F1-U protocol. Figure 8 is a diagram showing a protocol stack related to the F1-C protocol. Here, an example is shown in which the donor node 200 is split into a CU and a DU.

[0045] As shown in Figure 7, 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 has a BAP (Backhaul Adaptation Protocol) layer as the upper layer of the RLC layer. The BAP layer is a layer that performs routing processing and bearer mapping / demapping processing. In the backhaul, by transmitting the IP layer via the BAP layer, routing over multiple hops becomes possible.

[0046] In each backhaul link, the PDU (Protocol Data Unit) of the BAP layer is transmitted by the backhaul RLC channel (BH NR RLC channel). By configuring a plurality of backhaul RLC channels in each BH link, traffic prioritization and QoS (Quality of Service) control are possible. The association between the BAP PDU and the backhaul RLC channel is performed by the BAP layer of each IAB node 300 and the BAP layer of the donor node 200.

[0047] As shown in FIG. 8, the protocol stack of the F1-C protocol has an F1AP layer and an SCTP layer instead of the GTP-U layer and the UDP layer shown in FIG. 7.

[0048] In the following, the processing or operations performed by the IAB-DU and IAB-MT of the IAB may sometimes be simply described as the processing or operations of the "IAB". For example, the case where the IAB-DU of the IAB node 300-1 transmits a message of the BAP layer to the IAB-MT of the IAB node 300-2 is described as the IAB node 300-1 transmitting the message to the IAB node 300-2. Also, the processing or operations of the DU or CU of the donor node 200 may sometimes be simply described as the processing or operations of the "donor node".

[0049] Also, there may be cases where the upstream direction and the uplink (UL) direction are used without distinction. Further, there may be cases where the downstream direction and the downlink (DL) direction are used without distinction.

[0050] (Routing and Rerouting Scenarios) One of the functions of the BAP layer is routing and re-routing. Routing is, for example, to control which IAB node 300 the received packet is forwarded to. Also, re-routing is, for example, to control the received packet to be forwarded to the destination node (access IAB node or donor node) via an alternative path.

[0051] In 3GPP, studies are being conducted on how to perform routing or re-routing in a network (or topology) formed by a plurality of IAB nodes 300.

[0052] Regarding routing and re-routing, there are the following scenarios.

[0053] (S1) Intra-CU / Intra-donor-DU (S1-1) Routing (S1-2) Re-routing (S2) Intra-CU / Inter-donor-DU (S2-1) Routing (S2-2) Re-routing (S3) Inter-CU (S3-1) Routing (S3-2) Re-routing Considering such scenarios, by examining common procedures or processes for each scenario or individual procedures or processes for each scenario, it is expected to improve the reliability, flexibility, and low latency of packet transfer in the topology.

[0054] Here, each scenario will be described.

[0055] (S1) Regarding the "Intra-CU / Intra-donor-DU" scenario FIG. 9(A) shows a configuration example of a topology in the "inside CU / inside donor DU" scenario.

[0056] As shown in FIG. 9(A), in this scenario, routing and re-routing are performed in the same donor DU (200D) and the same donor CU (200C).

[0057] As shown in FIG. 9(A), between the IAB node 300-1 and the donor DU (200D), there are two paths: a path via the IAB node 300-2 and a path via the IAB node 300-3. The IAB node 300-1 can transfer uplink-direction packets via either path. For downlink-direction packets, the IAB node 300-1 can also transfer the packets transferred via either of the above paths to the IAB node 300-4 or the IAB node 300-5. During routing (S1-1), the existence of such two paths can ensure path redundancy.

[0058] Also, re-routing (S1-2) is so-called local re-routing. For example, when the IAB node 300-1 detects a radio link failure (BH RLF) in the backhaul link to the IAB node 300-2 (hereinafter sometimes referred to as "BH RLF"), it is also possible to switch the uplink-direction packets to the path via the IAB node 300-3, which is an alternative path, and perform re-routing.

[0059] (S2) Regarding the "inside CU / between donor DUs" scenario FIG. 9(B) is a diagram showing a configuration example of a topology in the "inside CU / between donor DUs" scenario.

[0060] As shown in Fig. 9(B), in this scenario, two different DUs, namely donor DU#1 (200D1) and donor DU#2 (200D2), are connected to the CU (200C) of one donor node. In this scenario, although the CUs (200C) of the donor nodes are the same, routing and rerouting are performed via different donor DUs, resulting in a scenario.

[0061] As shown in Fig. 9(B), there are two paths between the IAB node 300-1 and the CU (200C) of the donor node: one via the IAB node 300-2 and the donor DU#1 (200D1), and the other via the IAB node 300-3 and the donor DU#2 (200-D2).

[0062] In the uplink direction routing at the IAB node 300-1, the IAB node 300-1 can transfer packets to the IAB node 300-2 or the IAB node 300-3. Regarding the downlink direction, the IAB node 300-1 can transfer the packets received via any of the above paths to the IAB node 300-4 or the IAB node 300-5.

[0063] In this scenario, although the donor DUs are different, the donor CUs are the same, so it is routing within the same topology. Such routing may be referred to as intra-topology routing.

[0064] Regarding the rerouting in IAB node 300-1, for example, consider the case of switching from the route via IAB node 300-2 to the route via IAB node 300-3 (alternate path). In this case, the donor DU that is the destination of the packet is changed from donor DU#1 (200D1) to donor DU#2 (200D2). That is, the destination BAP address of the packet is changed. Therefore, in 3GPP, it was agreed to perform BAP header rewriting in this scenario. The BAP header rewriting is to rewrite the BAP header from the previous routing ID to the new routing ID. Note that the routing ID is composed of the destination BAP address (Destination) and the path identifier (Path ID).

[0065] (S3) Regarding the "between CUs" scenario FIG. 9(C) is a diagram showing a configuration example of the topology in the "between CUs" scenario.

[0066] As shown in FIG. 9(C), in this scenario, two different CUs, donor CU#1 (200C1) and donor CU#2 (200C2), are provided. And donor DU#1 (200D1) is connected to donor CU#1 (200C1), and donor DU#2 (200D2) is connected to donor CU#2 (200C2).

[0067] Generally, different topologies are formed by different donor CUs. That is, the topology (first topology) formed by the path from donor CU#1 (200C1) to IAB node 300-1 and the topology (second topology) formed by the path from donor CU#2 (200C2) to IAB node 300-1 can be different topologies. IAB node 300-1 is located at the boundary of the two different topologies. Such an IAB node 300-1 may be referred to as a boundary node.

[0068] Regarding the routing (S3-1) of this scenario, at the border IAB node 300-1, it is possible to transfer packets destined for the donor DU#1 (200D1) to the donor DU#2 (200D1) with a different topology. Also, packets destined for the IAB node 300-4 can be transferred via a different topology. For example, a packet sent from the donor CU#1 (200C1) can be transferred to the IAB node 300-4 via the donor CU#2 (200C2), the donor DU#2 (200D2), and the IAB nodes 300-3 and 300-1. In these cases, since the DU of the destination donor node is changed, in 3GPP, it was agreed to rewrite the BAP header.

[0069] When routing is performed between different topologies in this way, it may be referred to as inter-topology routing.

[0070] Regarding the rerouting of this scenario, for example, the border IAB node 300-1 can transfer packets destined for the donor DU#1 (200D1) via an alternative path in the topology at the donor CU#2 (200C2).

[0071] However, regarding the rerouting of this scenario, in 3GPP, it was agreed that at the border IAB node 300-1, it may be applied in the RRC Reestablishment state to the target donor node, the donor CU#2 (200C2), while leaving the F1 connection with the source donor node, the donor CU#1 (200C1).

[0072] The above three scenarios have been described. For these three scenarios, it is desirable to minimize the procedures specific to each scenario as much as possible and identify the procedures or processes common to all scenarios. This is because by having common procedures or processes, the processing can be simplified compared to performing individual processing for each scenario.

[0073] In the embodiment, each scenario will be described in the following order. [First Embodiment] Routing between CUs (First Operation Example) (Second Operation Example) (Third Operation Example) (Fourth Operation Example) (Fifth Operation Example) (Sixth Operation Example) [Second Embodiment] Re-routing between CUs [Third Embodiment] Routing within CU / Donor DU (First Operation Example) (Second Operation Example) (Third Operation Example) In the following description, "BH Routing Configuration" may be referred to as "routing table", "BH RLC Channel Mapping Configuration" may be referred to as "mapping table", and "Header Rewriting Configuration" may be referred to as "header rewriting table".

[0074] Furthermore, "routing between CUs" may be referred to as "routing between topologies", and "re-routing between CUs" may be referred to as "re-routing between topologies".

[0075] Furthermore, "routing within CU / Donor DU" may be referred to as "routing between donor DUs".

[0076] Furthermore, there may be cases where the layer and the entity are used without distinction.

[0077] [First Embodiment] The first embodiment is an embodiment regarding routing between topologies.

[0078] Regarding routing between topologies, 3GPP is discussing the following four Open Issues.

[0079] (Problem 1) "What’s the BAP address added in BAP header in the first topology (i.e. the BAP address of ingress data at the boundary node).”

[0080] (Problem 2) "How to differentiate the concatenated traffic and non-concatenated traffic.”

[0081] (Problem 3) "How to determine whether a data should be delivered to upper layer (for downstream).”

[0082] (Problem 4) "How to determine whether the BAP header of a data should be rewritten (i.e. whether being routed to another topology or its own topology).”

[0083] (Problem 1) is a problem regarding, for example, what BAP address should be set in the header of a BAP packet (BAP PDU) subject to inter-topology routing by the DU of an access IAB node or a donor node. For example, if the boundary IAB node 300-1 can distinguish between a BAP packet subject to inter-topology routing and other packets based on the set BAP address, it can perform inter-topology routing, perform normal routing processing, or process appropriately.

[0084] Problem 2 is, for example, an issue of how the border IAB node 300-1 discriminates between non-cocatenated traffic and concatenated traffic. If the border IAB node can appropriately perform such discrimination, it becomes possible to appropriately perform non-cocatenated traffic and concatenated traffic.

[0085] Problem 3 is, for example, an issue of how the border IAB node discriminates packets to be passed to its upper layer. For example, at the border IAB node, two types of packets, an upstream packet and a downstream packet, can be received. If the border IAB node determines that a packet is addressed to itself in the downstream direction, it can determine that it is an access IAB node and pass it to the upper layer.

[0086] Problem 4 is, for example, an issue of how to rewrite the BAP header. As described above, in non-cocatenated traffic (e.g., Fig. 9(C)), in the case of an uplink packet, the destination donor DU is changed to a donor DU with a different topology. Therefore, if the BAP header can be appropriately rewritten, transfer to a donor DU with a different topology becomes possible, and non-cocatenated traffic can be appropriately performed.

[0087] Regarding the above four problems, 3GPP has proposed the following two Examples.

[0088] Example 1: Add the boundary node's BAP address in the BAP PDU header in the first topology;

[0089] Example 2: Add some proxy / pseudo BAP address of the real destination;

[0090] (Proposal 1) is a proposal to include the BAP address of the border IAB node 300-1 in the header of the BAP packet. A packet containing the BAP address of the border IAB node 300-1 is a packet targeted for inter-topology routing. In the IAB node, if the BAP address of the border IAB node included in the header of the received packet matches its own BAP address, it is also possible to determine that the packet is a packet targeted for inter-topology routing with itself as the border IAB node 300-1.

[0091] (Proposal 2) is a proposal to include a proxy or fake BAP address in the header of the BAP packet. Also in this case, in the IAB node, if the fake BAP address is included in the header of the received BAP packet, it is also possible to determine that the packet is a packet targeted for inter-topology routing.

[0092] (Proposal 1) and (Proposal 2) only show that there are such proposals, and no specific procedures or processes using these proposals have been proposed to 3GPP.

[0093] Therefore, as a first operation example, an operation example of the entire BAP processing for inter-topology routing considering the above four issues will be described.

[0094] (First Operation Example) The first operation example is a communication control method used in a cellular communication system. First, the transmission unit of the BAP layer of a relay node (for example, the IAB node 300-1) receives a packet from the reception unit of the BAP layer of the relay node. Second, the transmission unit determines whether to perform inter-topology routing or intra-topology routing on the packet based on the header information of the packet. Here, the relay node is a border relay node located at the border between topologies.

[0095] Thus, in the first operation example, based on the header information of the received packet, it is determined whether to perform inter-topology routing or intra-topology routing. Therefore, in the first operation example, it is possible to appropriately determine whether to perform inter-topology routing or intra-topology routing, and for example, solutions to (Problem 1) and (Problem 2) can be provided.

[0096] Also, in the first operation example, when the transmission unit determines to perform intra-topology routing, it selects a first routing table for intra-topology routing and a first mapping table for intra-topology routing. On the other hand, when the transmission unit determines to perform inter-topology routing, it selects a second routing table for inter-topology routing and a second mapping table for inter-topology routing.

[0097] Thereby, in the first operation example, it is possible to appropriately select a routing table and a mapping table for inter-topology routing. In the transmission unit, by performing routing processing and mapping processing using these tables, inter-topology routing can be properly performed, and for example, solutions to (Problem 1) and (Problem 2) can be provided.

[0098] Furthermore, in the first operation example, when the transmission unit selects a second routing table and a second mapping table, a header rewriting process is performed to rewrite the header of the BAP packet from the previous routing ID to a new routing ID according to the BAP header rewriting table.

[0099] Thereby, in the first operation example, the destination BAP address can be appropriately rewritten, and inter-topology routing can be appropriately performed, and for example, a solution to (Problem 4) can be provided.

[0100] Hereinafter, the first operation example will be specifically described.

[0101] FIG. 10 is a diagram showing the first operation example according to the first embodiment.

[0102] As shown in FIG. 10, in step S10, the IAB node 300 starts processing.

[0103] In step S11, the IAB node 300 (here, the border IAB node 300-1) is set with a predetermined setting from the donor node 200. The predetermined setting is to receive the following table. That is, the first routing table for in-topology routing, the second mapping table for in-topology routing, the second routing table for inter-topology routing, the second mapping table for inter-topology routing, and the BAP header rewriting table.

[0104] In step S12, the IAB node 300 receives a packet (BAP PDU packet).

[0105] In step S13, the receiving unit of the BAP layer of the IAB node 300 identifies the packet addressed to itself in the downstream or upstream direction of the received packet. Then, the receiving unit outputs the packet addressed to itself to the upper layer, and outputs the other packets to the transmitting unit of the BAP layer of the IAB node 300.

[0106] The receiving unit identifies the packet addressed to itself as follows, for example.

[0107] First, when the destination in the header of the received packet matches the BAP address of the self IAB node 300-1, the receiving unit determines the packet as a candidate packet.

[0108] Second, when the candidate packet is in case (Proposal 1), the receiving unit uses the path ID included in the header of the candidate packet to identify that the packet is addressed to itself. Specifically, when the path ID included in the header of the packet is different from a predetermined path ID (path ID for inter-topology routing packets), the receiving unit identifies that the packet is addressed to itself. Note that the predetermined path ID is set by, for example, the donor node 200. When the candidate packet is in case (Proposal 1), it may be identified as being addressed to itself using an identifier indicating that the packet is a packet to be routed between topologies. Specifically, when the identifier included in the BAP header of the packet is "0" (not a packet to be routed between topologies), the receiving unit identifies that the candidate packet is addressed to itself.

[0109] Third, when the candidate packet is in case (Proposal 2), the receiving unit identifies the candidate packet as being addressed to itself. That is, since it can be confirmed that the destination of the candidate packet matches its own BAP address and is not a false BAP address, a candidate packet whose header destination matches the BAP address of its own IAB node 300 can be a packet addressed to itself in case (Proposal 2).

[0110] When the receiving unit identifies that the candidate packet is addressed to itself, it removes the BAP header and outputs it to the upper layer. The packet addressed to itself is a packet for the IAB node 300-1 to transmit to the UE 100 as an access IAB node. Therefore, in the upper layer, processing is performed so that the packet is transmitted to the UE 100.

[0111] On the other hand, the receiving unit outputs a packet that it has identified as not being addressed to itself among the received packets to the transmitting unit of the BAP layer.

[0112] In step S14, the transmitting unit selects the routing mode of the packet received from the receiving unit. The routing modes are intra-topology routing and inter-topology routing.

[0113] The determination method is performed, for example, as follows. That is, when at least any of the following applies to the header information of the packet, the transmission unit determines that the packet is an inter-topology routing target packet (inter-topology routing mode), and otherwise determines the in-topology routing mode (in-topology routing mode).

[0114] M1: When it matches a specific routing ID indicating inter-topology routing, or M2: When it matches a specific path ID indicating inter-topology routing, or M3: When it matches a specific BAP address indicating inter-topology routing (for example, Proposal (2)), or M4: When the identifier indicating whether it is an inter-topology transfer indicates an inter-topology transfer (for example, "1"), or M5: When the destination BAP address of the BAP packet matches a BAP address associated with a topology different from the specified BAP address, or M6: When routing mode information is provided for each packet from the receiving unit and the information indicates inter-topology routing (or in-topology routing). In the receiving unit, the routing mode may be determined using the above M1 to M5.

[0115] The details of M5 above will be described in the second operation example.

[0116] The transmission unit may store the packet in different buffers according to the determination result. For example, when the transmission unit determines that the packet is an inter-topology routing target packet, it stores the packet in a buffer for inter-topology routing. Also, for example, when the transmission unit determines that the packet is an in-topology routing target packet, it stores the packet in a buffer for in-topology routing.

[0117] In step S15, the transmission unit selects a routing table and a mapping table. The transmission unit may, by default, select the first routing table for in-topology routing.

[0118] Then, in step S14, when the transmission unit determines that the packet is for inter-topology routing, if the second routing table for inter-topology routing is set, the transmission unit selects the second routing table. Further, if the second mapping table is set, the transmission unit selects the second mapping table.

[0119] On the other hand, when the transmission unit determines that the packet is for inter-topology routing and the second routing table is not set, the IAB node 300 selects the first routing table for in-topology routing on the assumption that it is not the border IAB node 300-1. That is, although the transmission unit determines that the packet is for inter-topology routing by, for example, matching a specific routing ID, the second routing table is not set in the IAB node 300. For example, this applies to the case of IAB nodes (IAB nodes 300-2 and 300-3) located between the donor DU and the border IAB node 300-1. In such IAB nodes, although the packet is recognized as a packet for inter-topology routing, since the second routing table is not set, inter-topology routing is not performed for the packet. In this case, the transmission unit selects the first routing table.

[0120] Similarly, when the second mapping table is not set, the transmission unit selects the first mapping table.

[0121] On the other hand, the transmission unit is at step S 15In the case where the packet is determined to be a packet to be routed within the topology, the first routing table is selected. Further, the transmission unit selects the second mapping table.

[0122] Note that the transmission unit may store the packet in different buffers for each routing table. When the transmission unit selects the first routing table, it stores the packet in the buffer for the first routing table. Also, when the transmission unit selects the second routing table, it stores the packet in the buffer for the second routing table.

[0123] In step S16, the transmission unit performs BAP header rewriting processing on the packet. That is, when the transmission unit performs inter-topology routing on the packet (or when the second routing table and the second mapping table are selected in step S15), it performs BAP header rewriting processing.

[0124] The transmission unit performs BAP header rewriting processing using the header rewriting table. The BAP header rewriting table includes entries containing the old routing ID (the previous routing ID) and the new routing ID (the new routing ID). Specifically, when an entry containing the old routing ID that matches the routing ID included in the header of the packet exists in the header rewriting table, the transmission unit rewrites the routing ID included in the header of the packet with the new routing ID of the entry.

[0125] Note that if the entry including the old routing ID that matches the routing ID included in the header of the packet does not exist in the header rewrite table, the transmission unit may determine that the packet is not a packet subject to inter-topology routing. In this case, the transmission unit does not perform the BAP header rewrite process. Or, in this case, the transmission unit may perform a process such as rerouting. That is, when an entry including the BAP address part of the old routing ID that matches the destination of the packet exists in the header rewrite table, the transmission unit may rewrite the routing ID of the BAP header of the packet to the new routing ID of the entry.

[0126] In step S17, the transmission unit performs routing processing and mapping processing on the packet.

[0127] First, the transmission unit performs routing processing using the routing table (the first routing table or the second routing table) selected in step S15. Specifically, when an entry that matches the destination and path ID included in the header of the packet exists in the selected routing table and the egress backhaul link corresponding to the next hop BAP address of the entry is available, the transmission unit selects the egress backhaul link.

[0128] Here, when using the first routing table, it is a case of intra-topology routing. That is, for both downlink direction packets and uplink direction packets, in the case of intra-topology routing, routing processing is performed using the first routing table.

[0129] On the other hand, when using the second routing table, it is inter-topology routing. The IAB node 300-1, as a border IAB node, performs inter-topology routing processing on the received packet. For example, the IAB node 300-1 performs routing processing on a packet destined for the donor DU#1 (200D1) so that it becomes a packet directed to the donor DU#1 (200D2).

[0130] Second, the transmission unit performs mapping processing using the mapping table (the first mapping table or the second mapping table) selected in step S15. Specifically, the transmission unit selects the egress backhaul RLC channel of the entry when an entry that matches the ingress backhaul RLC channel of the packet, the ingress backhaul link of the packet, and the selected egress backhaul link in the above mapping processing exists in the selected mapping table.

[0131] The transmission unit outputs the packet to the selected egress backhaul RLC channel of the selected egress backhaul link.

[0132] In step S18, the IAB node 300 transmits the packet to the next-hop node. In this case, the IAB node 300 (the border IAB node 300-1) transmits the packet, for example, to the donor DU#2 (200D2) by inter-topology routing. Or, the IAB node 300 transmits the packet, for example, to the donor DU#1 (200D1) by intra-topology routing.

[0133] In step S19, the IAB node 300 ends a series of processes.

[0134] (Summary of the first operation example) FIG. 11 is a drawing summarizing the first operation example according to the first embodiment.

[0135] In FIG. 11, the BAP reception process (step S30) corresponds to steps S11 to S13 in FIG. 10. Also, in FIG. 11, the routing mode selection (step S31) corresponds to step S14 in FIG. 10. Further, in FIG. 11, the routing table / mapping table selection (step S32) corresponds to step S15 in FIG. 10. Further, in FIG. 11, the BAP header rewriting process (step S33) corresponds to step S16 in FIG. 10. Further, in FIG. 11, the routing process / mapping process (step S34) corresponds to step S17 in FIG. 10.

[0136] (Modification Example of the First Operation Example)

[0137] (Modification Example 1) The first operation example may be executed when the second routing table, the second mapping table, and the header rewriting table are set. That is, when the second routing table, the second mapping table, or the header rewriting table is not set, the first operation example may not be performed.

[0138] (Modification Example 2) In the first operation example, the scenario of "inter-topology routing" (S3-1) was described. Regarding the BAP header rewriting, it has been agreed in 3GPP that it is also performed in the scenario of "intra-CU / inter-donor CU rerouting" (S2-2).

[0139] Therefore, at least a part of the first operation example may be applied to scenarios other than the scenario of "inter-topology routing". For example, when applied to the scenario of "intra-CU / inter-donor DU rerouting" (S2-2) or the scenario of "intra-CU / intra-donor DU routing" (S1-2), the operations may be performed by respectively reading "intra-topology or inter-topology" in the first operation example as "normal routing or inter-donor DU routing", etc.

[0140] (Modification Example 3) In the first operation example, an example was described in which two tables, i.e., a first routing table for in-topology routing and a second routing table for inter-topology routing, were used for the routing table. For example, three or more routing tables may be set for the routing table.

[0141] For example, in FIG. 9(C), assume a case where the IAB node 300-1 performs inter-topology routing for the donor CU#1(200C2) (hereinafter sometimes referred to as the "second donor") under the donor CU#1(200C1) (hereinafter sometimes referred to as the "first donor"). After the inter-topology routing, in the downstream direction, the first donor manages the routing ID, and in the upstream direction, the second donor manages the routing ID. In this case, if there is no negotiation between the first donor and the second donor, the same routing ID may be used.

[0142] For example, assume that after the inter-topology routing, the IAB node 300-1 receives a packet from a lower node and performs routing processing. In this case, the IAB node 300-1 selects an entry that matches the routing ID of the packet from the routing table. However, if the same routing ID exists in the downstream routing table managed by the first donor and the upstream routing table managed by the second donor, the IAB node 300-1 may search for the entry with the same routing ID from the downstream routing table. In this case, the IAB node 300-1 may transfer the packet received from the lower node to the lower node again.

[0143] Therefore, in Modification 3, for the inter-topology routing table, two routing tables, i.e., the upstream inter-topology routing table and the downstream inter-topology routing table, are set in the IAB node 300-1. Also, for the intra-topology routing table, the upstream intra-topology routing table and the downstream intra-topology routing table are set in the IAB node 300-1.

[0144] For example, the IAB node 300-1 determines that a packet received from a lower node is in the upstream direction, and performs routing processing using an inter-topology table or an intra-topology table associated with the upstream direction.

[0145] Thereby, even when the same routing ID is used between topologies, the IAB node 300-1 can appropriately forward the packet.

[0146] (Modification 4) In the first operation example, the BAP header rewriting process is performed after the routing table / mapping table selection (step S32) and before the routing process / mapping process (step S34).

[0147] Modification 4 is an example in which the BAP header rewriting process is performed at the beginning of the BAP transmission process.

[0148] FIG. 12 is a diagram showing an operation example according to Modification 4 of the first embodiment.

[0149] As shown in FIG. 12, the BAP transmission process is performed in the following order. That is, the BAP header rewriting process (step S33), the routing mode selection (step S31), the routing table / mapping table selection (step S32), and the routing process / mapping process (step S34).

[0150] In step S33, the transmission unit performs BAP header rewriting processing. The transmission unit performs the following processing, for example.

[0151] That is, when the transmission unit of the BAP layer of the IAB node 300-1 receives a BAP packet (BAP PDU) from the reception unit of the BAP layer of the IAB node 300-1, in step S33, it performs BAP header rewriting processing. Specifically, the transmission unit performs the following processing. First, the transmission unit determines whether an entry including the old routing ID that matches the routing ID included in the header of the packet exists in the header rewriting table.

[0152] If the entry exists in the header rewriting table, the transmission unit rewrites the routing ID included in the BAP header of the packet to the new routing ID in the entry. On the other hand, if the entry does not exist in the header rewriting table, the transmission unit does not perform BAP header rewriting. In this case, the transmission unit may determine that the packet was not the target of inter-topology routing. Or, in this case, the transmission unit may perform re-routing processing. That is, if an entry including the BAP address of the old routing ID that matches the destination in the header of the packet exists in the header rewriting table, the transmission unit rewrites the routing ID of the BAP header to the new routing ID included in the entry.

[0153] Second, if the transmission unit performs BAP header rewriting, it may store the packet in a buffer for the BAP header rewritten packet. On the other hand, if the transmission unit does not perform BAP header rewriting, it may store the packet in a buffer for the BAP header unrewritten packet.

[0154] After that, in step S31, the transmission unit performs routing mode selection (step S31). The transmission unit performs, for example, the following processing. That is, when the BAP header is rewritten, the transmission unit may determine that the packet is a packet to be routed between topologies. Also, when the BAP header is not rewritten, the transmission unit may determine that the packet is a packet to be routed within a topology. Step S31 may be omitted.

[0155] After that, in step S32, the transmission unit selects a routing table / mapping table. The transmission unit performs, for example, the following processing. That is, the transmission unit may select a second routing table and a second mapping table associated with the new routing ID selected at the time of BAP header rewriting. In this case, the association information between the new routing ID and each table is set from the donor node 200 to the IAB node 300-1. After that, in step S34, the transmission unit performs routing processing and mapping processing. The two processes are the same as in the first operation example.

[0156] In the first operation example, an example of using two routing tables (and two mapping tables) applicable to the in-topology scenario and the between-topology scenario has been described, but it is not limited to this. One routing table (and one mapping table) used in both the in-topology scenario and the between-topology scenario may be defined. In this case, each entry in the table may include information indicating whether it is an entry applicable to the in-topology scenario or an entry applicable to the between-topology scenario. The information may be information indicating whether it is applicable to a packet with the BAP header rewritten or a packet without the BAP header rewritten. Alternatively, the information is the sending outIt may be an identifier indicating the previous topology (or the donor that manages the topology). Alternatively, the information may be information indicating whether it should be applied to upstream packets or downstream packets. The IAB node 300-1 subjects only the entries that match the specified routing mode (or scenario) to the routing process (and mapping process) as targets (candidates).

[0157] (Second operation example) Next, a second operation example according to the first embodiment will be described.

[0158] The second operation example is also an operation example for identifying whether a packet received by the IAB node 300-1 is a packet subject to inter-topology routing.

[0159] As shown in FIG. 9(C), the border IAB node 300-1 is connected to two topologies. Each topology is assumed to be managed by each donor node (donor CU#1 (200C1) and donor CU#2 (200C2)). Therefore, the BAP address of the border IAB node 300-1 will have two BAP addresses, the BAP address managed by the donor CU#(200C1) and the BAP address managed by the donor CU#2 (200C). In principle, the BAP address is unique within the topology.

[0160] As shown in the above (Case 2), as a method for identifying a packet subject to inter-topology routing, a proposal has been made to assign a proxy / pseudo BAP address to the border IAB node 300-1. In this case, the border IAB node 300-1 may be assigned two proxy BAP addresses, the proxy BAP address assigned by the donor CU#1 (200C1) and the proxy BAP address assigned by the donor CU#2 (200C2). Furthermore, as described above, the border IAB node 300-1 is assigned two self BAP addresses by these two donors as its self BAP addresses.

[0161] Therefore, the boundary IAB node 300-1 may be assigned four BAP addresses. Identifying packets targeted for inter-topology routing using these four BAP addresses may involve complex processing.

[0162] Also, the BAP layer may determine from which topology the packet has arrived in order to select a BAP address.

[0163] Thus, in the second operation example, the IAB node 300-1 identifies the topology of the incoming packet, identifies the BAP address associated with the identified topology as its own BAP address, and uses the identified BAP address to perform BAP reception processing and BAP transmission processing in the same manner as in the first operation example.

[0164] That is, first, the BAP address of the relay node (e.g., IAB node 300-1) in each topology is set at the relay node from the donor node (e.g., donor node 200). Second, the relay node is set with association information that associates the topology with the incoming backhaul link and / or association information that associates the topology with the incoming backhaul RLC channel from the donor node. Third, the BAP layer of the relay node receives a packet. Fourth, the BAP layer identifies the topology to which the packet belongs based on the incoming backhaul link and / or incoming backhaul RLC channel of the packet, and identifies the BAP address associated with the identified topology as the BAP address of the relay node. Here, the relay node is a boundary relay node (e.g., boundary IAB node 300-1) located at the boundary between topologies.

[0165] As a result, for example, it is only necessary to use two BAP addresses associated with each topology without using four BAP addresses, so the processing can be simplified compared to the case of using four BAP addresses.

[0166] FIG. 13 is a diagram illustrating a second operation example according to the first embodiment.

[0167] Here, assume that the IAB node (here, the border IAB node) 300-1 has connections with two topologies. For example, as shown in FIG. 9(C), the border IAB node 300-1 has connections with the donor CU#1 (200C1) and the donor CU#2 (200C2). In this case, the relationship between the border IAB node 300-1 and the two donor nodes may be a relationship between the border IAB node 300-1 and a donor node having an F1AP connection, and the border IAB node 300-1 and a donor node not having an F1AP connection. Also, the relationship may be a relationship between the border IAB node 300-1 and a donor node having a first (main or master) F1AP connection, and the border IAB node 300-1 and a donor node having a second (secondary) F1AP connection. Further, the relationship may be a relationship between the border IAB node 300-1 and a donor node having an RRC connection, and the border IAB node 300-1 and a donor node not having an RRC connection. Further, the relationship may be a relationship between the border IAB node 300-1 and a donor node having an MCG (Master Cell Group) connection, and the border IAB node 300-1 and a donor node having an SCG (Secondary Cell Group) connection.

[0168] As shown in FIG. 13, in step S40, the IAB node 300-1 starts processing.

[0169] In step S41, the IAB node 300-1 sets the BAP address of each topology from the donor node. The BAP address is set using F1AP or RRC.

[0170] For example, when the F1AP connection or the RRC connection of the IAB node 300-1 in FIG. 9(C) is only connected to the donor CU#1 (200C1), the BAP address in the donor CU#2 (200C2) is notified from the donor CU#2 (200C2) to the donor CU#1 (200C1). Then, the BAP address is set from the donor CU#1 (200C1) to the IAB node 300-1. Through such a path, the BAP address in the topology on the donor CU#2 (200C2) side may be set.

[0171] When both the F1AP connection and the RRC connection exist for each donor node, the donor CU#1 (200C1) sets the BAP address in the topology it manages to the IAB node 300-1 by using an F1AP message or an RRC message. Also, the donor CU#2 (200C2) sets the BAP address in the topology it manages to the IAB node 300-1 by using an F1AP message or an RRC message.

[0172] The BAP address may be set by associating it with the topology (or donor node). For example, the first BAP address may be set in association with the first topology (for example, the topology managed by the donor CU#1 (200C1)), and the second BAP address may be set in association with the second topology (for example, the topology managed by the donor CU#2 (200C2)).

[0173] The IAB node 300-1 associates the BAP address for each topology (or donor node) and stores it in the buffer.

[0174] In step S42, the IAB node 300-1 has the association information between the topology and the ingress backhaul link (and / or the ingress backhaul RLC channel) set from the donor node.

[0175] For example, association information indicating that the first topology is associated with a first ingress backhaul link (and / or a first ingress backhaul RLC channel) and the second topology is associated with a second ingress backhaul (and / or a second ingress backhaul RLC channel) is set. Alternatively, association information may be set only for the second ingress backhaul link (and / or the second ingress backhaul RLC channel) associated with the second topology. In Rel-16, since all ingress backhaul links (and / or ingress backhaul RLC channels) belong to the first topology, at the IAB node 300-1, if there is no association information, it can be determined as the first topology, and if there is association information, it can be determined as the second topology.

[0176] In this way, based on the association information in step S42, the IAB node 300-1 can identify the topology to which the packet belongs from the packet's ingress source.

[0177] In step S43, the BAP layer of the IAB node 300-1 receives the packet. Then, the BAP layer checks the ingress backhaul link (and / or ingress backhaul RLC channel) of the packet. That is, based on the ingress backhaul link (and / or ingress backhaul RLC channel) of the packet, the BAP layer checks the topology associated with the ingress backhaul link (and / or ingress backhaul RLC channel).

[0178] First, when the ingress backhaul link (and / or ingress backhaul RLC channel) is associated with the first topology, the BAP layer identifies the BAP address associated with the first topology as its own BAP address (for example, the first BAP address). The BAP address associated with each topology is set in step S41.

[0179] Second, when the incoming backhaul link (and / or incoming backhaul RLC channel) is associated with the second topology, the BAP layer identifies the BAP address associated with the second topology as its own BAP address (e.g., the second BAP address).

[0180] In step S43, the BAP layer identifies the topology to which the received packet belongs from the source of the packet, and identifies the BAP address associated with (or corresponding to) the identified topology.

[0181] In step S44, the BAP layer checks the Destination included in the header of the packet.

[0182] First, when the destination matches its own BAP address identified in step S43, the BAP layer determines that the packet is addressed to itself and outputs the packet to the upper layer. That is, when the destination matches its own BAP address (e.g., the first BAP address) identified in step S43, similar to the first operation example, the packet is a downstream packet in the first topology, and the self-IAB node 300-1 is an access IAB node. In such a case, since the IAB node 300-1 transmits the packet to the subordinate UE100, the BAP layer outputs the packet to the upper layer.

[0183] Second, when the destination does not match its own BAP address identified in step S43, the BAP layer determines that it is a routing target. The receiving unit of the BAP layer outputs the packet determined to be a routing target to the transmitting unit of the BAP layer.

[0184] The BAP layer performs the following processing on the packet that is a routing target.

[0185] First, if the destination of the packet matches the BAP address associated with the second topology specified in step S43 (or the BAP address for inter-topology routing), the BAP layer may determine that the packet is a packet to be subjected to inter-topology routing. That is, when the destination BAP address of the packet matches the BAP address (for example, the second BAP address) associated with a topology (for example, the second topology) different from the specified BAP address (for example, the first BAP address), the BAP layer determines that the packet is a packet to be subjected to inter-topology routing. After the determination, the BAP layer may perform BAP header rewriting processing on the packet in the same manner as in the first operation example. Alternatively, if step S44 is performed in the receiving section of the BAP layer, the receiving section may output the packet as an object for inter-topology routing (or by adding information indicating that it is such an object) to the transmitting section of the BAP layer.

[0186] Second, if the destination of the packet does not match the BAP address associated with the second topology specified in step S43 (or the BAP address for inter-topology routing), the BAP layer may determine that the packet is an object for intra-topology routing. The BAP layer does not perform BAP header rewriting processing on the packet. Alternatively, if step S44 is performed in the receiving section of the BAP layer, the receiving section may output the packet as an object for intra-topology routing (or by adding information indicating that it is such an object) to the transmitting section of the BAP layer.

[0187] In step S45, the BAP layer performs routing processing and mapping processing in the same manner as in the first operation example. The BAP layer may perform routing processing and mapping processing on the packet determined to be an object for inter-topology routing using the second routing table and the second mapping table. Alternatively, the BAP layer may perform routing processing and mapping processing on the packet determined to be an object for inter-topology routing using the first routing table and the first mapping table.

[0188] In step S46, the IAB node 300-1 ends a series of processes.

[0189] (Third operation example) Next, the third operation example of the first embodiment will be described.

[0190] In 3GPP, it has been proposed to include an identifier indicating whether the packet is a BAP packet subject to inter-topology routing in the header of the BAP packet.

[0191] For example, in FIG. 9(C), when the border IAB node 300-1 receives the packet from a lower node, based on the identifier included in the header of the packet, it can identify that the packet is a packet subject to inter-topology routing.

[0192] On the other hand, the IAB node 300-3 that has received the packet can also determine that the packet is a packet subject to inter-topology routing based on the identifier. Therefore, there is a possibility of incorrect operation in the IAB node 300-3.

[0193] Therefore, in the third operation example, when the IAB node (border IAB node) 300-1 performs inter-topology routing, it rewrites the identifier to a value (for example, "0") indicating that the packet is not a packet subject to inter-topology routing.

[0194] Specifically, in the header rewriting process, the identifier indicating inter-topology routing included in the header information of the BAP packet is rewritten from "1" to "0".

[0195] Thereby, the IAB node 300-3 that has received the packet for which inter-topology routing has been performed will no longer perform inter-topology routing on the packet, and incorrect operation can be suppressed.

[0196] FIG. 14 is a diagram showing a configuration example of a BAP Data PDU packet according to the first embodiment. An identifier indicating that the packet is a packet for inter-topology routing may be included in at least one of the three reserved areas (“R”).

[0197] FIG. 15 is a diagram showing a third operation example according to the first embodiment.

[0198] In step S50, the border IAB node 300-1 starts processing.

[0199] In step S51, the border IAB node 300-1 receives a BAP packet.

[0200] In step S52, the BAP layer of the border IAB node 300-1 checks the identifier included in the header of the packet. When the identifier is “1” indicating that inter-topology routing is to be performed, the BAP layer determines that the received packet is a packet for inter-topology routing. Note that when the identifier is “0”, the BAP layer determines that the packet is not a packet for inter-topology routing. Hereinafter, the description will continue assuming that the packet is a packet for inter-topology routing.

[0201] In step S53, the BAP layer performs BAP header rewriting processing on the packet. Similar to the first operation example and the like, when an entry including an old routing ID that matches the routing ID included in the header of the packet exists in the header rewriting table, the BAP layer rewrites the routing ID included in the header of the packet to the new routing ID included in the entry. Then, the BAP layer rewrites the identifier from the value “1” indicating that inter-topology routing is to be performed to the value “0” indicating that inter-topology routing is not to be performed. Alternatively, the BAP layer writes “0” to the area of the BAP header in which the identifier is included.

[0202] In step S54, similar to the first operation example, the BAP layer performs routing processing and mapping processing, and outputs the packet to the lower layer.

[0203] In step S55, the border IAB node 300-1 transmits the packet to the next-hop node.

[0204] In step S56, the border IAB node 300-1 ends a series of processes.

[0205] (Fourth operation example) Next, the fourth operation example of the first embodiment will be described.

[0206] In the first operation example, when the BAP layer selects a routing table, it selects the first routing table or the second routing table.

[0207] However, there may be a case where the BAP layer cannot identify which routing table is the first routing table or the second routing table.

[0208] Therefore, in the fourth operation example, an example is given in which an identifier for identifying two routing tables is included in each routing table. Similarly, for the mapping table, an example is given in which an identifier for identifying the first mapping table and the second mapping table is included in each mapping table.

[0209] Specifically, the first routing table and the second routing table include first identification information for identifying the first routing table and the second routing table, and the first mapping table and the second mapping table include second identification information for identifying the first mapping table and the second mapping table.

[0210] Here, in the first operation example, M1 to M6 were described as identification methods for identifying that the packet is a packet subject to inter-topology routing.

[0211] Also, based on the direction of the packet, it is also possible to identify that the packet is a packet subject to inter-topology routing. For example, in FIG. 9(C), since negotiation is not performed between donor nodes, the downstream routing ID used in the topology of donor CU #1 (200C1) and the upstream routing ID used in the topology of donor CU #2 (200C2) may be the same. Therefore, an identifier indicating the direction is included in each table. Then, at the IAB node 300-2, if it can be confirmed that the direction of the received packet is the upstream direction, it can be recognized that it is subject to inter-topology routing, and based on the identifier, the second routing table and the second mapping table used in the upstream direction can be used.

[0212] Therefore, the following five identifiers are the objects to be discriminated.

[0213] T1: Routing ID T2: Path ID T3: BAP address T4: An identifier indicating whether it is an inter-topology transfer is a flag value indicating inter-topology transfer (for example, "1") T5: Upstream or downstream For example, at the IAB node 300-1, regarding the routing ID, if a specific routing ID indicating inter-topology routing is included in the table, the table can be determined as the second routing table.

[0214] On the other hand, for example, at the IAB node 300-1, if a specific routing ID indicating inter-topology routing is not included in the table (or if a routing ID indicating intra-topology routing is included in the table), the table can be determined as the first routing table.

[0215] The same applies to T2 to T4.

[0216] Regarding T5, for example, when the packet is an upstream packet, the IAB node 300-1 may determine a table including an identifier indicating the upstream direction as the second routing table. Also, for example, when the packet is a downstream packet, the IAB node 300-1 may determine a table including an identifier indicating the downstream direction as the first routing table.

[0217] FIG. 16 is a diagram showing a fourth operation example according to the first embodiment.

[0218] As shown in FIG. 16, in step S60, the donor node starts the process.

[0219] In step S61, the donor node sets a first routing table for inter-topology routing and a second routing table for intra-topology routing for the IAB node 300-1.

[0220] Each of the two tables includes an identifier for identifying the first routing table and the second routing table.

[0221] In step S62, the IAB node 300-1 receives a packet.

[0222] In step S63, the BAP layer of the IAB node 300-1 checks the header of the packet and determines the routing table to be applied. For example, when the information contained in the header matches a specific identifier indicating inter-topology routing, the BAP layer determines the routing table containing the identifier as the second routing table. On the other hand, when the information contained in the header does not correspond to a specific identifier indicating inter-topology routing (or when the information corresponds to a specific identifier indicating intra-topology routing), the BAP layer determines the routing table not containing the identifier as the first routing table. The BAP layer performs routing processing using the determined routing table.

[0223] Then, in step S64, the IAB node 300-1 ends a series of processes.

[0224] (Modification example of the fourth operation example) In the fourth operation example, an example in which two routing tables, i.e., the first routing table and the second routing table, are used for the routing table has been described. For example, three or more routing tables may be used. For example, for the border IAB node 300-1, since three or more multi-connectivities are assumed, one routing table may be used for each connection.

[0225] (Fifth operation example) Next, the fifth operation example in the first embodiment will be described.

[0226] In the fourth operation example described above, an example of specifying the table to be applied based on the direction of the packet has been described.

[0227] However, in 3GPP, how to specify the direction of the packet has not been discussed.

[0228] Therefore, in the fifth operation example, an operation example for identifying whether the received packet is in the downstream direction or the upstream direction will be described.

[0229] Specifically, first, the receiving unit (for example, the receiving unit of the BAP layer) identifies whether the direction of the received BAP packet is the downstream direction or the upstream direction. Second, when there are a first routing table and a second routing table for each direction of the BAP packet, the transmitting unit selects the first routing table or the second routing table corresponding to the identified direction.

[0230] Thereby, for example, in the IAB node 300-1, it becomes possible to appropriately transfer the received packet using the routing table corresponding to the identified direction.

[0231] FIG. 17 is a diagram showing the fifth operation example according to the first embodiment.

[0232] As shown in FIG. 17, in step S70, the IAB node 300 starts the process.

[0233] In step S71, the IAB node 300 receives a packet.

[0234] In step S72, the BAP layer of the IAB node 300 identifies the direction of the packet. For example, the BAP layer may identify the direction of the packet as follows.

[0235] That is, when the BAP layer receives the packet from a child node of the IAB node 300 (corresponding backhaul link), it determines that it is in the upstream direction. Also, when the BAP layer receives the packet from the UE 100 (corresponding access link), it determines that it is in the upstream direction. On the other hand, when the BAP layer receives the packet from a parent node of the IAB node 300 (corresponding backhaul link), it determines that it is in the downstream direction. Also, when the BAP layer receives the packet in the IAB-DU of the IAB node 300, it determines that it is in the upstream direction. Also, when the BAP layer receives the packet in the IAB-MT of the IAB node 300, it determines that it is in the downstream direction.

[0236] In step S73, the BAP layer performs a predetermined process using the determined direction of the packet. The predetermined process is any of the following processes.

[0237] First, when there are two routing tables for each direction of the packet, the BAP layer selects the routing table corresponding to the determined direction. That is, when the determined direction of the packet is the upstream direction, the BAP layer selects the first routing table or the second routing table corresponding to the upstream direction. On the other hand, when the determined direction of the packet is the downstream direction, the BAP layer selects the first routing table or the second routing table corresponding to the downstream direction. Then, the BAP layer performs routing processing using the selected routing table.

[0238] Second, when the routing table does not exist for each packet direction but the packet direction is specified in the entries in the routing table, the BAP layer performs routing processing on the entry corresponding to the specified direction. For example, assume that there are a first routing table and a second routing table, the packet direction is specified in the entries in the first routing table, and the packet direction is specified in the entries in the second routing table. In this case, the BAP layer performs routing processing using the entry corresponding to the specified direction (upstream direction or downstream direction) in the first routing table or the second routing table.

[0239] In step S74, the IAB node 300 transmits the packet to the next-hop node.

[0240] Then, in step S75, the IAB node 300 ends the series of processes.

[0241] (Modification Example of the Fifth Operation Example) In the fifth operation example, an example of performing routing processing was described. The fifth operation example may be applied to mapping processing.

[0242] That is, the BAP layer identifies the direction of the received packet in the same manner as in the fifth operation example. When there are two mapping tables for each packet direction, the BAP layer selects the first mapping table or the second mapping table corresponding to the identified direction and performs mapping processing using the selected mapping table. Also, when the mapping table does not exist for each packet but the packet direction is specified in the entries in the mapping table, the BAP layer performs mapping processing using the entry corresponding to the direction in the first mapping table or the second mapping table.

[0243] (Sixth Operation Example) In the third operation example, an identifier indicating that it is a target for inter-topology routing was described.

[0244] In the sixth operation example, it will be described how the donor DU or the access IAB node writes the identifier into the header of the packet.

[0245] Specifically, first, the CU of the donor node (for example, donor 200) makes a setting as to whether to write to an identifier indicating inter-topology routing in association with the routing ID to the DU of the donor node or the access IAB node. Second, the DU of the donor node or the access IAB node transmits a BAP packet with a BAP header including the routing ID and the identifier to the next-hop node according to the setting.

[0246] Thereby, for example, the DU of the donor node 200 and the access IAB node can appropriately write the identifier in the BAP header.

[0247] FIG. 18 is a diagram showing the sixth operation example according to the first embodiment.

[0248] As shown in FIG. 18, in step S80, the donor node 200 starts processing.

[0249] In step S81, the CU of the donor node 200 makes a setting as to whether to write to an identifier indicating inter-topology routing in association with the routing ID to the DU of the donor node 200 or the access IAB node.

[0250] First, the setting for the access IAB node is made using F1AP. That is, the donor node 200 makes the setting by transmitting "Uplink Traffic to Routing ID Mapping Configuration" to the access IAB node. The mapping setting includes the following IEs.

[0251] U1: Traffic type specifier U2: Routing ID U3: Information on whether to write an identifier indicating inter-topology routing Here, regarding the above U3, when the IE is included in the mapping setting, it may be assumed that the identifier is written to the BAP header, and when the IE is not included in the mapping setting, the identifier is not written to the BAP header. Also, regarding the above U3, it may be assumed that the identifier is written to the BAP header when the information is "1", and the identifier is not written to the BAP header when the information is "0". "1" and "0" may be reversed. Further, the information may be indicated by "True" or "False". Also, the information may be indicated by "Yes" or "No".

[0252] Second, the setting of the donor node 200 to the DU is performed using a predetermined IE ("IP-to-layer-2 traffic mapping Information List IE"). That is, the CU of the donor node 200 performs the setting by outputting "Downlink Traffic to Routing ID Mapping Configuration" to the DU of the donor node 200. The mapping setting includes the following IEs.

[0253] D1: Destination IP Address D2: IPv6 flow label D3: DSCP (Differentiated Services Code Point) D4: Routing ID D5: Information on whether to write an identifier indicating inter-topology routing Even in this mapping setting, similar to the setting for the access IAB node, D5 is included. Similar to U3, when this IE is included in this mapping setting, it may be assumed that this identifier is written into the BAP header (or it is specified that writing is to be performed), and when this IE is not included in this mapping setting, it may be assumed that this identifier is not written into the BAP header (or writing is not specified). It may also be assumed that this identifier is written into the BAP header when this information is "1", and this identifier is not written into the BAP header when this information is "0". "1" and "0" may be reversed. This information may be indicated by "True" or "False". Also, this information may be indicated by "Yes" or "No".

[0254] Incidentally, an operation example in the access IAB node will be described below.

[0255] In step S82, the BAP layer of the access IAB node receives a BAP packet (BAP SDU) from the upper layer.

[0256] First, the BAP layer selects an entry including a traffic descriptor corresponding to the packet from this mapping setting ("Uplink Traffic to Routing ID Mapping Configuration").

[0257] Second, the BAP layer sets the routing ID in the selected entry as the routing ID to be written into the BAP header.

[0258] Then, third, in the selected entry, when writing to the identifier indicating inter-topology routing is specified, the BAP layer sets this identifier in the BAP header to "1". On the other hand, when writing to this identifier is not specified in the selected entry, the BAP layer sets this identifier to "0".

[0259] Fourth, the BAP layer adds a BAP header including a routing ID and the identifier to the packet (BAP SDU) to generate a BAP PDU.

[0260] In step S83, the BAP layer of the access IAB node performs routing processing and mapping processing on the BAP PDU and transmits it to the next-hop node.

[0261] Then, in step S84, the BAP layer of the access IAB node ends a series of processes.

[0262] Here, regarding steps S82 and S83, when the DU of the donor node 200 performs processing, the "access IAB node" in steps S82 and S83 may be replaced with the "DU of the donor node 200", and the mapping setting may be set to "Downlink Traffic to Routing ID Mapping Configuration".

[0263] The first embodiment regarding the scenario (S3-1) of inter-topology routing has been described above. Next, the scenario (S3-2) of inter-topology rerouting will be described.

[0264] [Second Embodiment] Next, the second embodiment will be described.

[0265] In the second embodiment, inter-topology rerouting will be described.

[0266] In 3GPP, it has been agreed to support inter-topology rerouting. Inter-topology rerouting is that an IAB node reroutes a packet to the CU of the original donor node (or source donor node) via an alternative path on the topology of the CU of the target donor node.

[0267] Regarding inter-topology routing, in 3GPP, when an IAB node performs recovery from a BH RLF via RRC Reestablishment in a new donor CU, it is agreed that the ongoing F1 connection with the original donor node may be maintained and routing may be performed via the recovered path.

[0268] That is, inter-topology routing at the IAB node may be applied to the target donor node in the state of RRC reestablishment while leaving the F1 connection with the source donor node. In other words, at the IAB node, inter-topology routing may be applied in a transitional state where the F1 connection with the target donor node is not established, rather than in the state of dual connectivity (DC) with two donor nodes.

[0269] In such a transitional state, the IAB node may not be able to execute inter-topology routing even if it uses the Rel-16 local routing procedure.

[0270] That is, in the Rel-16 local routing procedure, a routing ID that matches the destination included in the BAP header of the BAP packet is selected from the routing table, and the packet is forwarded.

[0271] However, the routing table of the source donor node does not have a routing ID to the target donor node (or the BAP address of the DU of the target donor node as the destination). This is because the two donor nodes have different topologies, and the CU of each donor node manages the BAP addresses of each topology.

[0272] Therefore, even if the CU of the source donor node sets the routing table to the IAB node, the IAB node cannot forward the packet to the target donor node.

[0273] Even if the IAB node can transfer the packet to the target donor node, the target donor node may not be able to determine whether the packet is addressed to itself or to the source donor node.

[0274] Therefore, in the second embodiment, the target donor node sets a communication path for inter-topology routing to the IAB node, and the IAB node 300 transfers the packet via the communication path.

[0275] Specifically, first, a relay node (for example, the IAB node 300) detects a radio link failure of the backhaul in the connection with the first donor node (for example, the source donor node) or the connection with the first upper node. Second, when the relay node performs RRC re-establishment with the second donor node (for example, the target donor node) or the second upper node, the relay node notifies information indicating that communication with the first donor node is to be continued. Here, the first upper node is a node managed by the first donor node and is an upper node of the relay node. Also, the second upper node is a node managed by the second donor node and is an upper node of the relay node.

[0276] Thereby, for example, the target donor node can recognize that communication continues between the IAB node and the source donor node, and trigger this notification to set a communication path for inter-topology routing to the IAB node. And even in the above-described transitional state, the IAB node can appropriately transfer the received packet using the communication path.

[0277] FIGS. 19(A) and 19(B) are diagrams showing a configuration example of a topology according to the second embodiment.

[0278] In Fig. 19(A), an example is shown where a BH RLF has occurred in the backhaul link between the IAB node 300 and the donor node A (200 - A). Also, in Fig. 19(B), an example is shown where a BH RLF has occurred in the backhaul link between the IAB node 300 and the upper node 300 - P1. In Fig. 19(B), the IAB node 300 - P1 is a node managed by the donor node A (200 - A). Also, the IAB node 300 - P2 is a node managed by the donor node B (200 - B).

[0279] Fig. 20 is a diagram showing an operation example according to the second embodiment. The operation example shown in Fig. 20 will be described with appropriate reference to the configuration examples shown in Fig. 19(A) and Fig. 19(B).

[0280] As shown in Fig. 20, in step S90, the IAB node 300 starts the process.

[0281] In step S91, a BH RLF occurs in the backhaul link. For example, in the example of Fig. 19(A), the IAB - MT of the IAB node 300 detects a BH RLF in the backhaul link with the donor node A (200 - A). Also, in the example of Fig. 19(B), the IAB - MT of the IAB node 300 detects a BH RLF with the IAB node 300 - P1.

[0282] Returning to Fig. 20, in step S92, the IAB node 300 selects the donor node B (200 - B) by cell selection. The IAB node 300 may select the IAB node 300 - P2 managed by the donor node B (200 - B) by cell selection.

[0283] In step S93, the IAB node 300 executes an RRC re - establishment procedure for the donor node B (200 - B). For example, the following procedure is executed.

[0284] First, the IAB node 300 transmits an RRC Reestablishment Request message to the donor node B (200-B). The IAB node 300 may transmit the message to the donor node B (200-B) via the IAB node 300-P2.

[0285] At this time, the IAB node 300 may notify the donor node B (200-B) of information (or a request) indicating continuation of communication with the donor node A (200-A) in the message. Alternatively, the IAB node 300 may notify the donor node B (200-B) of information indicating that the IAB node 300 itself has the ability of inter-topology relaying in the message. Alternatively, the IAB node 300 may notify the donor node B (200-B) of information indicating that the F1 connection with the donor node A (200-A) remains in the message. Or, the IAB node 300 may notify the donor node B (200-B) of a request for establishment of a communication path with the donor node A (200-A) in the message.

[0286] Note that the notification may be performed in each message of a subsequent RRC Reestablishment Complete or a later UE Assistanve Information.

[0287] Second, the donor node B (200-B) accepts the RRC reestablishment request and transmits an RRC Reestablishment message to the IAB node 300.

[0288] Third, in response to reception of the RRC reestablishment message, the IAB node 300 transmits an RRC Reestablishment Complete message to the donor node B (200-B).

[0289] As described above, an RRC connection is established between the IAB node 300 and the donor node B (200-B).

[0290] In step S94, the donor node B (200-B) establishes a communication path (GTP (GPRS (General Packet Radio System) Tunnelling Protocol)) with the donor node A (200-A). This is for the donor node B (200-B) to use the communication path to send upstream packets routed between topologies at the IAB node 300 to the donor node A (200-A). In addition, the donor node A (200-A) also establishes a communication path (GTP) with the donor node B (200-B). This is for the donor node A (200-A) to send downstream packets to the donor node B (200-B).

[0291] For example, the donor node B (200-B) sends a communication path establishment request message to the donor node A (200-A). Then, in response to receiving the message, the donor node A (200-A) sends an affirmative response message to the donor node B (200-B). Thereby, the communication path may be established. The request message may include an identifier of the IAB node 300, a GTP TEID (Tunnel Endpoint Identifier) for receiving downstream packets, and an IP address. The affirmative response message may include a GTP TEID for receiving upstream packets and an IP address.

[0292] Note that the establishment of the GTP communication path may be performed before the donor node B (200-B) sends an RRC Reestablishment message to the IAB node 300.

[0293] In step S95, the donor node B(200 - B) sets up a communication path for inter - topology relaying to the IAB node 300. That is, the second donor node (for example, the donor node B(200 - B)) sets up a communication path for inter - topology relaying to the relay node (for example, the IAB node 300).

[0294] The donor node B(200 - B) sets up a communication path for the IAB node 300 by using the RRC connection established in step S93. Specifically, the CU of the donor node B(200 - B) sets up the communication path by sending an RRC re - configuration message to the IAB - MT of the IAB node 300. The message includes settings for establishing a (temporary) backhaul RLC channel (BH RLC channel) for inter - topology relaying.

[0295] First, the settings may include a (temporary) routing table for inter - topology relaying. The routing table may include a routing ID and a Next Hop BAP Address.

[0296] Second, the settings may include a (temporary) mapping table for inter - topology relaying. The mapping table may include an ingress BH RLC channel, an egress BH RLC channel, an ingress BH link, and an egress BH link.

[0297] Third, the settings may include the BAP address of the IAB node 300. The BAP address is the BAP address for the IAB node 300 managed by the donor node B(200 - B).

[0298] Fourthly, the setting may include the BAP address of the DU of the donor node B (200 - B).

[0299] Fifthly, the setting may include a BAP header rewrite table.

[0300] When the RRC layer of the IAB node 300 receives the setting, it outputs the setting to the BAP layer of the IAB node 300. The BAP layer may handle the setting as a routing table and / or a mapping table.

[0301] In step S96, the BAP layer of the IAB node 300 performs inter-topology rerouting processing according to the setting. For example, the BAP layer of the IAB node performs the following processing.

[0302] First, the BAP layer rewrites the BAP header of the packet destined for the donor node A (200 - A) that is staying according to the setting to the routing ID for the DU of the donor node B (200 - B).

[0303] Second, the BAP layer identifies the next-hop BAP address (or the egress backhaul link corresponding to the next-hop BAP address) from the routing ID according to the setting. In this case, the BAP layer may use the routing table for inter-topology rerouting according to the setting. For example, the BAP layer may read an entry that matches the routing ID from the routing table for inter-topology rerouting and identify the egress backhaul link corresponding to the next-hop BAP address of the entry.

[0304] Thirdly, the BAP layer identifies the outflow backhaul RLC channel from the said setting. In this case, the BAP layer may utilize the mapping table for inter-topology routing according to the said setting. For example, the BAP layer may read an entry that matches the inflow backhaul RLC channel, the inflow backhaul, and the identified outflow backhaul link of the said packet, and identify the outflow backhaul RLC channel included in the said entry.

[0305] Fourthly, the BAP layer outputs the said packet that has been held up to the identified outflow backhaul RLC channel of the identified outflow backhaul link.

[0306] Regarding the identification of the said outflow backhaul link and the identification of the said outflow backhaul RLC channel, for example, the processing may be performed as follows. That is, for the packet waiting to be transmitted and held up at the IAB node 300, when there is no entry in the routing table that matches the routing ID included in the header of the said packet and there is no entry in the routing table that matches the destination included in the header of the said packet, the BAP layer selects the backhaul RLC channel set in the said setting as the destination, and transmits the held-up packet via the selected backhaul RLC channel. That is, in such a case, the BAP layer transmits the held-up packet to the communication path for inter-topology routing.

[0307] Also, the BAP layer of the IAB node 300 may receive the downlink-direction packet transmitted by the donor node A (200-A) from the inflow backhaul link and the inflow backhaul RLC channel according to the said setting via the donor node B (200-B).

[0308] In step S97, when the F1 connection between the donor node A (200-A) and the IAB node 300 is released, the donor node A (200-A) or the IAB node 300 notifies the donor node B (200-B) of information indicating that the F1 communication has been completed (for example, the discard request of the said communication path).

[0309] For example, donor node A (200-A) sends a communication discard request for inter-topology relaying between donor node B (200-B) and IAB node 300 to donor node B (200-B). Then, donor node B (200-B) can also execute the notification and the communication discard simultaneously by returning an affirmative response to the discard request to donor node A (200-A). Alternatively, the F1 layer of the IAB node may send an F1 setup request to donor node B (200-B) to implicitly notify that the F1 connection has been released.

[0310] In step S98, donor node B (200-B) removes the backhaul RLC channel setting for inter-topology relaying (or the communication path setting for inter-topology relaying) set in step S95 from IAB node 300. That is, the relay node (for example, IAB node 300) discards the communication path setting for inter-topology relaying when the F1 connection with the first donor node (for example, donor node A (200-A)) or the F1 connection with the first upper node (for example, IAB node 300-P1) is released.

[0311] For example, donor node B (200-B) may instruct IAB node 300 to remove the setting. Also 、I AB node 300 may automatically remove the setting. In the latter case, IAB node 300 may remove the setting triggered by the notification of the completion of F1 communication in step S97.

[0312] In step S99, donor node B (200-B) ends a series of processes.

[0313] (Modification of the Second Embodiment) In the second embodiment, the IAB node 300 re - establishes an RRC connection with the donor node B (200 - B), and the donor node B (200 - B) uses an RRC message to configure a communication path for inter - topology routing for the IAB node 300.

[0314] In a modification of the second embodiment, instead of using RRC, an example of using F1 to configure the communication path is given. Specifically, first, the relay node (for example, the IAB node 300) detects a BH RLF in the connection with the first donor node (for example, the donor node A (200 - A)) or the connection with the first upper - level node (for example, the IAB node 300 - P1). Second, when the relay node performs an F1 setup for the second donor node (for example, the donor node B (200 - B)) or the second upper - level node (for example, the IAB node 300 - P2), the relay node notifies information indicating that communication with the first donor node is to be continued. Here, the first upper - level node is a node managed by the first donor node and is an upper - level node of the relay node. Also, the second upper - level node is a node managed by the second donor node and is an upper - level node of the relay node.

[0315] Thereby, for example, in the target donor node, it can be grasped that communication is continued between the IAB node and the source donor node. Triggered by this notification, it becomes possible to configure a communication path for inter - topology routing for the IAB node using an F1AP message. And with the configuration of the communication path, the IAB node can appropriately perform inter - topology routing.

[0316] FIG. 21 is a diagram showing a modification according to the second embodiment.

[0317] As shown in FIG. 21, in step S100, the IAB node 300 starts processing.

[0318] Steps S101 and S102 are the same as steps S91 and S92 in the second embodiment, respectively.

[0319] In step S103, the IAB node 300 executes an RRC re - establishment procedure with the donor node B (200 - B) to re - establish an RRC connection with the donor node B (200 - B). Thereafter, the IAB node 300 executes an F1 setup procedure to establish an F1 connection with the donor node B (200 - B).

[0320] Note that the F1 setup procedure is performed between the IAB - DU of the IAB node 300 and the CU of the donor node B (200 - B). The F1 setup procedure is performed, for example, as follows.

[0321] First, the IAB node 300 sends an F1 Setup Request message to the donor node B (200 - B). At this time, similar to the second embodiment, the IAB node 300 notifies, in this message, information indicating that communication with the donor node A (200 - A) continues. Or, similar to the second embodiment, the IAB node 300 may notify information indicating that it has the ability of inter - topology routing. Also, the IAB node 300 may notify information indicating that the F1 connection with the donor node A (200 - A) remains. Note that the notification may be made in a later F1 Setup Response message or an even later UE assistance information message.

[0322] Second, the donor node B (200 - B) accepts the request and sends an F1 Setup Response message to the IAB node 300.

[0323] Thereby, an F1 connection is established between the IAB node 300 and the donor node B (200 - B).

[0324] Step S104 is the same as step S94 of the second embodiment.

[0325] In step S105, the donor node B(200 - B) sets up a (temporary) communication path for inter-topology relaying to the IAB node 300. This setup is performed using an F1 re-configuration update message. The setup content is the same as that of the second embodiment. Similar to the second embodiment, this setup includes the setup for establishing a (temporary) backhaul RLC channel for inter-topology relaying. When the F1AP layer of the IAB node 300 receives this setup, it outputs the setup to the BAP layer of the IAB node 300. Similar to the second embodiment, the BAP layer may handle this setup as a routing table and / or a mapping table.

[0326] Note that this setup may also be performed using an F1 setup response message.

[0327] In step S106, the BAP layer of the IAB node 300 performs inter-topology relaying processing according to this setup. The inter-topology relaying processing itself is the same as that of the second embodiment.

[0328] Steps S107 and S108 are the same as steps S97 and S98 of the second embodiment, respectively.

[0329] Then, in step S109, the donor node B(200 - B) ends a series of processes.

[0330] The second embodiment regarding the scenario (S3 - 2) of inter-topology relaying has been described above. Next, the scenario (S2 - 2) of donor DU relaying will be described.

[0331] [Third Embodiment] Next, the third embodiment will be described.

[0332] The third embodiment describes donor DU relaying.

[0333] For example, in the case of the topology configuration example shown in FIG. 9(B), there are multiple DUs in the donor node. Therefore, there are also multiple BAP addresses of the DUs in the donor node. In the example of FIG. 9(B), there are two BAP addresses, namely the BAP address of the donor node DU#1 (200D1) and the BAP address of the donor node DU#2 (200D2).

[0334] Here, regarding the downstream packets, the source (the DU of the donor node) is not involved in the routing process in the IAB node 300-1. Also, regarding the downstream packets, the destination (the access IAB node) remains unchanged even if routing processing is performed. Therefore, it is expected that there will be no particular problem with the donor DU inter-rerouting in the downstream direction.

[0335] On the other hand, regarding the upstream direction, when donor DU inter-rerouting is performed, the destination (the DU of the donor node) changes. That is, for each packet, the destination BAP address is changed. For this reason, in the IAB node 300-1, the BAP header rewriting process may be performed. In 3GPP, “‘previous routing ID to new routing ID’ BAP rewriting” has been agreed upon as the BAP header rewriting process.

[0336] Here, in this scenario, there are two issues.

[0337] First, different from routing, rerouting, in principle, once performs the routing process and then performs the routing process again for the packets with no destination. Therefore, it is necessary to consider the timing of performing the BAP header rewriting process.

[0338] Second, it is not clear whether the IAB node 300-1 appropriately selects a route that matches the destination of the received packet, or whether an alternative path is explicitly set by the donor node. Therefore, a complicated setting may be considered.

[0339] (First operation example) Next, the first operation example according to the third embodiment will be described.

[0340] In the first operation example, once the routing process is performed, the BAP header rewriting process is performed on the packets that could not be transmitted, and then the routing process is performed again.

[0341] Specifically, first, a relay node (for example, IAB node 300-1) receives a packet. Second, the relay node performs a routing process on the packet and checks that the next-hop BAP address cannot be selected or the egress backhaul link cannot be selected. Third, the relay node determines that the packet for which the check was performed is a packet to be subject to donor DU inter-routing. Fourth, the relay node performs a routing process again on the packet that has been determined to be a packet to be subject to donor DU inter-routing.

[0342] Thereby, for example, it is possible to perform processing in accordance with the principle of re-routing, that is, perform the routing process and then perform the routing process again on the packets with no destination.

[0343] Then, the relay node executes a BAP header rewriting process for rewriting the destination of the packet on the packet that has been determined to be a packet subject to donor DU inter-routing. In this case, the relay node performs a routing process again on the packet whose destination has been rewritten.

[0344] Thereby, for example, in IAB node 300-1, the BAP header rewriting process, the routing process, and the routing process again can be appropriately performed.

[0345] FIG. 22 is a diagram showing the first operation example according to the third embodiment. For example, FIG. 22 will be described while appropriately referring to the configuration example shown in FIG. 9(B).

[0346] As shown in FIG. 22, in step S110, the IAB node 300-1 starts processing.

[0347] In step S111, the IAB node 300-1 receives a predetermined setting from the donor node 200. The predetermined setting is, for example, as follows.

[0348] First, the setting of the header rewrite table is performed. In this case, in the header rewrite table, the header rewrite table for inter-topology routing described in the first embodiment and the header rewrite table for donor DU inter-rerouting according to the third embodiment are set. The two tables may include identifiers for identifying each table.

[0349] Second, the BAP addresses of two donor DUs are set. In the example of FIG. 9(B), the BAP addresses of two donor DUs, donor DU#1 (200D1) and donor DU#2 (200D2), are set. Note that three or more BAP addresses may be set.

[0350] In step S112, the transmission unit of the BAP layer of the IAB node 300-1 receives a packet from the reception unit of the BAP layer of the IAB node 300-1. Here, similar to the first embodiment, the reception unit of the BAP layer may output a packet addressed to itself in the downstream direction to the upper layer. For example, since it is an access IAB node itself, routing processing or the like may not be performed. Therefore, the transmission unit receives a packet other than the packet addressed to itself from the reception unit.

[0351] In step S113, the transmission unit performs routing processing on the packet. In the routing processing, for example, the following processing is performed.

[0352] First, the transmission unit checks the BAP header of the packet and determines that there is no entry in the routing table where the destination and the path ID match, or even if such an entry exists, the next-hop BAP address corresponding to the entry is not available (Rel-16 routing process).

[0353] Second, the transmission unit checks the BAP header of the packet and determines that there is no entry in the routing table where the destination matches, or even if such an entry exists, the next-hop BAP address corresponding to the entry is not available (Rel-16 rerouting process).

[0354] That is, the transmission unit checks the above two conditions and determines that the next-hop BAP address cannot be selected.

[0355] If the next-hop BAP address is available, the transmission unit checks that the corresponding outflow backhaul link is not available. That is, the transmission unit determines that the outflow backhaul link cannot be selected.

[0356] Third, in the mapping process, the transmission unit may check that the outflow backhaul RLC channel cannot be selected. That is, the transmission unit may check that there is no entry in the mapping table that matches the inflow backhaul RLC channel and the inflow backhaul link of the packet, and the outflow backhaul link selected in the routing process.

[0357] Fourthly, the transmission unit checks the BAP header of the packet and verifies that the destination is the BAP address of the DU of the donor node 200 (for example, the donor node DU#1 (200D1)). The BAP address of the DU of the donor node is set for the IAB node 300-1 by the donor node 200 in step S111, for example. Therefore, the transmission unit can verify by comparing this BAP address with the destination of the packet. By this verification, it is possible to prevent rewriting of the BAP header in the downstream direction and perform header rewriting for packets in the upstream direction.

[0358] Fifthly, when the transmission unit verifies that the packet is addressed to the DU of the donor node 200, it may mark the packet as a packet for donor DU - to - donor DU routing (or in the upstream direction). Instead of marking, the transmission unit may store the packet in a special transmission buffer (i.e., a buffer for donor DU - to - donor DU routing).

[0359] When the transmission unit determines that the packet is a packet for donor DU - to - donor DU routing (or in the upstream direction) and a header rewrite table is set, it proceeds to the next header rewrite process.

[0360] In step S114, the transmission unit performs a header rewrite process on the packet. The header rewrite process is the same as step S16 (Figure 10) of the first operation example in the first embodiment.

[0361] In step S115, the transmission unit performs routing processing and mapping processing again on the packet for which the header rewrite process has been completed. Through these two processes, the transmission unit selects an outflow backhaul link and an outflow backhaul RLC channel.

[0362] In step S116, the transmission unit outputs the packet to the selected outflow backhaul RLC channel of the selected outflow backhaul link. Then, the IAB node 300-1 transmits the packet to the selected next-hop node.

[0363] In step S117, the IAB node 300-1 ends a series of processes.

[0364] (Summary of the first operation example) FIG. 23 is a diagram summarizing the first operation example according to the third embodiment.

[0365] In FIG. 23, step S120 corresponds to step S112 in FIG. 22. Step S122 in FIG. 23 corresponds to step S113 in FIG. 22. Step S123 in FIG. 23 corresponds to step S114 in FIG. 22.

[0366] As shown in FIG. 23, the transmission unit performs routing processing and mapping processing (step S122), and performs BAP header rewriting processing (step S123) on a packet that could not be routed in the routing processing or a packet that could not be mapped in the mapping processing.

[0367] Then, the transmission unit performs routing processing and mapping processing again, and transmits the processed packet as a packet that has been rerouted between donor DUs to the next-hop node.

[0368] (Modification example of the first operation example) At least a part of the first operation example according to the third embodiment is also applicable to scenarios other than routing between donor DUs.

[0369] (Second operation example) Next, the second operation example according to the third embodiment will be described.

[0370] Section 5.2.1.1, "General" of 3GPP TS38.340 V16.5.0 (2016-06) states the following. "NOTE: Data buffering on the transmitting part of the BAP entity, e.g., until RLC-AM entity has received an acknowledgement, is up to implementation. In case of BH RLF, the transmitting part of the BAP entity may reroute the BAP Data PDUs, which has not been acknowledged by lower layer before the BH RLF, to an alternative path in accordance with clause 5.2.1.3." As shown in the underlined part, routing in 3GPP is performed for packets in the transmitted packets for which an Ack has not been confirmed at the lower layer.

[0371] Therefore, in the second operation example, an operation example of performing donor DU-to-DU routing for transmitted packets will be described.

[0372] Specifically, first, the relay node (e.g., IAB node 300-1) stores a copy (or duplicate) of the packet in the buffer after packet transmission. Second, the relay node selects a packet to be subject to donor DU-to-DU routing from the packets stored in the buffer. Third, the relay node performs BAP header rewriting processing to rewrite the destination of the selected packet. Fourth, the relay node performs routing processing again on the packet on which the BAP packet rewriting processing has been performed.

[0373] Thereby, for example, in IAB node 300-1, it is possible to select a packet to be subject to donor DU-to-DU routing from the packets staying in the buffer, and it becomes possible to appropriately perform donor DU-to-DU routing.

[0374] FIG. 24 is a diagram showing a second operation example according to the third embodiment.

[0375] As shown in FIG. 24, in step S130, IAB node 300-1 starts processing.

[0376] In step S131, after the BAP layer of IAB node 300-1 transmits a packet, it stores a copy of the packet in a buffer. The BAP layer may store at least one of the routing ID, next-hop BAP address, outgoing backhaul link, and outgoing backhaul RLC channel used for transmitting the packet, in association with the packet stored in the buffer. Alternatively, it may have a plurality of buffers associated with any of the routing ID, next-hop BAP address, outgoing backhaul link, and outgoing backhaul RLC channel. In this case, the BAP layer may store a copy of the packet in the corresponding buffer according to the destination of the packet. Note that when the BAP layer receives a delivery confirmation notification of the packet from a lower layer (RLC), it deletes the packet (or its copy) stored in the buffer from the buffer.

[0377] In step S132, when the BAP layer determines to perform donor DU inter-routing, it selects a packet to be the target of the donor DU inter-routing from among the packets stored in the buffer. The determination of performing the donor DU inter-routing and the selection of the donor DU inter-routing target packet are performed, for example, as follows.

[0378] First, when the IAB node 300-1 detects a BH RLF, it determines to execute the routing. The IAB node 300-1 may identify the egress backhaul link where the BH RLF is detected. Alternatively, the IAB node 300-1 may identify at least one of the routing ID, next-hop BAP address, and egress backhaul RLC channel affected by the egress backhaul link. The IAB node 300-1 selects a packet associated with the identified egress backhaul link (or at least one of the routing ID, next-hop BAP address, and egress backhaul RLC channel) from the buffer. The packet may become the routing target packet.

[0379] Second, when the IAB node 300-1 receives a Type 2 BH RLC Indication, it determines to execute the routing. The Type 2 BH RLC Indication is an Indication indicating that recovery from the BH RLF is in progress. The IAB-DU of the IAB node 300-P1, which is the upper node of the IAB node 300-1, sends the Indication to the IAB-MT of the IAB node 300-1. The IAB node 300-1 may identify the egress backhaul link where the Indication is received. Alternatively, when the routing ID and the backhaul RLC channel ID that cannot be routed (or are affected or should be routed) by the Indication are notified, the IAB node 300-1 may identify these IDs. Alternatively, the IAB node 300-1 may identify the next-hop BAP address affected from the identified information. The IAB node 300-1 selects a packet associated with the identified egress backhaul link (or at least one of the routing ID, egress backhaul RLC channel, and next-hop BAP address) from the buffer. The packet may become the routing target packet.

[0380] Thirdly, when the IAB node 300-1 receives flow control feedback in the uplink direction from its upper node, it determines to perform the routing. The IAB node 300-1 that has received the flow control feedback from the upper node can avoid congestion between IAB nodes by performing control such as reducing the amount of data transmitted to the upper node. The IAB-MT (of the BAP layer) of the IAB node 300-1 can receive the feedback transmitted from the IAB-DU of the upper node. The IAB node 300-1 may identify the outgoing backhaul link that has received the feedback. Alternatively, the IAB node 300-1 may identify a routing ID or a backhaul RLC channel associated with the available buffer size affected by the feedback. When the available buffer size falls below a threshold (set by the donor node 200), the routing ID or the backhaul RLC channel associated with the buffer size may be targeted for the routing. Alternatively, the IAB node 300-1 may identify the next-hop BAP address from the identified information. The IAB node 300-1 selects a packet from the buffer that is associated with at least one of the identified routing ID, outgoing backhaul link, outgoing backhaul RLC channel, and next-hop BAP address. The packet can be the packet targeted for the routing.

[0381] When the IAB node 300-1 performs the routing based on any other criterion, it may similarly select the packet targeted for the routing.

[0382] In step S133, the IAB node 300-1 performs BAP header rewriting processing on the selected packet. The BAP header rewriting processing is the same as the first operation example of the first embodiment (step S16 in FIG. 10).

[0383] In step S134, the IAB node 300-1 performs the routing process and the mapping process again on the packet for which the BAP header rewriting process has been performed, before transmitting the packet. The IAB node 300-1 transmits the processed packet to the next-hop node.

[0384] Then, in step S135, the IAB node 300-1 ends a series of processes.

[0385] (Modification example of the second operation example) At least a part of the second operation example is applicable to scenarios other than donor DU inter-routing.

[0386] (Third operation example) Next, a third operation example according to the third embodiment will be described.

[0387] In the first and second embodiments, an example has been described in which the BAP layer of the IAB node 300 performs BAP header rewriting with reference to the BAP header rewriting table set from the donor node 200.

[0388] On the other hand, in Rel-16, the BAP layer appropriately selects a routing ID of a re-routing destination from among routing IDs that match the destination of the BAP header, with reference to a normal routing table. This was because in Rel-16, in-CU / intra-donor DU re-routing (S1-2) was assumed, and it was premised that there was a route to the re-routing destination within the same topology, so no problem could occur.

[0389] Here, consider the problems when the same concept (that is, the concept when there is no BAP header rewriting table) is applied to donor DU inter-routing.

[0390] First, regarding the downstream direction, the destination is the access IAB node, which is the same as Rel-16. Therefore, regarding the downstream direction, we will not consider the issues.

[0391] Second, regarding the upstream direction, there are multiple DUs of the donor node (= multiple destination BAP addresses). However, the multiple DUs of the donor node are managed by the CU of the same donor node. Therefore, in the routing table managed by the CU of the donor node, for example, there should be two BAP addresses (destinations), namely the BAP address of donor DU#1 (200D1) and the BAP address of donor U#2 (200D2).

[0392] However, even if we refer to the routing table only based on the destination included in the BAP header (for example, donor DU#1 (200D1)), since the BAP address itself is different from that of the DU of another donor node (for example, donor DU#2 (200D2)), it may not be possible to select the routing ID to the DU of the other donor as a candidate.

[0393] Also, in 3GPP, regarding donor DU inter-routing, it has already been agreed to perform BAP header rewriting from the previous routing ID to a new routing ID.

[0394] Therefore, in the third operation example, the donor node 200 sets an alternative destination (for example, donor DU#2 (200D2)) associated with the destination (for example, donor DU#1 (200D1)) to the IAB node 300-1. Then, the IAB node 300-1 selects a routing ID including the alternative destination from the routing table and writes the selected routing ID into the BAP header to perform BAP header rewriting.

[0395] Specifically, first, a donor node (for example, donor node 200) sets a first destination address of a first donor node (for example, donor DU#1 (200D1)) and a second destination address of a second donor node (for example, donor DU#2 (200D2)) for a relay node (for example, IAB node 300-1). Second, the relay node receives an upstream packet. Third, the relay node performs routing processing and determines that the packet cannot be transmitted to the next-hop relay node. Fourth, when a first routing ID including a BAP address that matches the first destination address of the determined packet does not exist in the routing table, the relay node selects a second routing ID including a BAP address that matches the second destination address from the routing table. Fifth, the relay node writes the second routing ID into the header of the packet. Here, the second destination address is associated with the first destination address.

[0396] Thereby, the IAB node 300-1 can perform BAP header rewriting without using the BAP header rewriting table during donor DU inter-routing.

[0397] FIG. 25 is a diagram showing a third operation example according to the third embodiment.

[0398] As shown in FIG. 25, in step S140, the IAB node 300-1 starts processing.

[0399] In step S141, the IAB node 300-1 receives a predetermined setting from the donor node 200. The predetermined setting is, for example, as follows.

[0400] That is, the predetermined setting is the BAP address for a plurality of DUs of the donor node 200. Alternatively, the predetermined setting is an alternative destination used for donor DU - to - donor DU relaying. For example, the BAP address of a certain destination (e.g., donor DU#1 (200D1)) and the BAP address of an alternative destination (e.g., donor DU#2 (200D2)) are associated and set. Alternatively, an identifier indicating that a certain destination (e.g., donor DU#1 (200D1) and donor DU#2 (200D2)) can be used as an alternative destination (in the upstream direction) may be set.

[0401] In step S142, the IAB node 300 - 1 receives a packet from a lower - level node.

[0402] In step S143, the IAB node 300 - 1 performs normal routing processing and confirms that the next - hop node cannot be selected (or cannot be transmitted). The processing in step S143 may be the same as, for example, the first operation example (step S113 in FIG. 22) according to the third embodiment.

[0403] In step S144, the IAB node 300 - 1 searches the routing table for a routing ID having a BAP address that matches the destination included in the header of the packet.

[0404] First, when an entry including the routing ID exists in the routing table and the corresponding next - hop BAP address, the outflow backhaul link, and the outflow backhaul RLC channel are available, the IAB node 300 - 1 performs routing processing again according to the setting.

[0405] Second, if the entry does not exist in the routing table, if the corresponding next-hop BAP address is unavailable (or congested), or if the corresponding outgoing backhaul link and / or outgoing backhaul RLC channel is unavailable (or congested), proceed to the following process.

[0406] That is, when the IAB node 300-1 determines that the packet is in the upstream direction, it searches the routing table for a routing ID that includes a BAP address that matches an alternative destination (the BAP address of the DU of a different donor node different from the destination) associated with the destination of the packet.

[0407] Here, the method for determining the upstream direction is that when the destination included in the header of the packet matches the BAP address of the DU of the donor node 200 set in step S141, the IAB node can determine that the packet is in the upstream direction. Also, when an alternative destination that matches the destination included in the header of the packet exists in the setting according to step S141, the IAB node 300-1 can determine that it is in the upstream direction.

[0408] If, as a result of the search, the IAB node 300-1 finds a routing ID in the routing table that includes the BAP address of the DU of a different donor node (or alternative destination), it selects that routing ID. Then, the IAB node 300-1 selects the next-hop BAP address corresponding to that routing ID, and selects the corresponding outgoing backhaul link and the outgoing backhaul RLC channel. At this time, the IAB node 300-1 confirms that the selected next-hop BAP address, outgoing backhaul link, and outgoing backhaul RLC channel are available for transmission.

[0409] In step S145, the IAB node 300-1 writes the selected routing ID into the header of the packet. That is, when the IAB node 300-1 selects a routing ID including an alternative destination, it writes the routing ID into the header. Thereby, BAP header rewriting is performed. Here, the IAB node 300-1 may report information regarding BAP header rewriting to the donor. The information may be the routing ID before rewriting (i.e., the old routing ID or Previous Routing ID) and / or the routing ID after rewriting (i.e., the new routing ID or New Routing ID) when BAP header rewriting is performed along with the rerouting process. The information may further include the time (timestamp) information when the rerouting was executed and the number of packets for which the rerouting was executed. The information may be recorded (logged) in the internal memory of the IAB node 300-1 every time the routing process occurs. The reporting may be performed every time (i.e., immediately) the routing process is performed, or may be performed in response to a request from the donor (i.e., later).

[0410] In step S146, the BAP layer of the IAB node 300-1 outputs the packet to the selected outflow backhaul RLC channel of the selected outflow backhaul link. The IAB node 300-1 transmits the packet to the next-hop IAB node (or towards the donor DU#2 (200D2)).

[0411] Then, in step S147, the IAB node 300-1 ends a series of processes.

[0412] (Summary of the third operation example) FIG. 26 summarizes the third operation example according to the third embodiment.

[0413] In FIG. 26, step S150 corresponds to step S142 in FIG. 25. Step S152 in FIG. 26 corresponds to steps S143 and S144 in FIG. 25. Step S153 in FIG. 26 corresponds to step S145 in FIG. 25.

[0414] In step S150, the IAB node 300-1 performs BAP reception processing. In this case, similar to the first embodiment, the IAB node 300-1 receives not only upstream direction packets but also downstream direction packets, and when the packet is addressed to itself (the packet is in the downstream direction and the IAB node 300-1 can be an access IAB node), it may be output to the upper node. In this case, the IAB node 300-1 performs BAP transmission processing (step S151) on packets other than the packets addressed to itself among the received packets.

[0415] In step S152, the BAP layer of the IAB node 300-1 performs routing processing and mapping processing. In this case, the BAP layer determines that an upstream direction packet to be routed to a destination different from the destination included in the header of the received packet is a packet to be rewritten with a BAP header (steps S143 and S144 in FIG. 25). Further, the BAP layer searches the routing table for a routing ID including the BAP address of the CU of another donor node associated with the destination of the header.

[0416] Then, in step S153, the BAP layer performs BAP header rewriting processing on the packet to be rewritten with a BAP header using the routing ID (step S144 in FIG. 25).

[0417] On the other hand, in step S152, the BAP layer transmits an upstream packet that can be routed to the same destination as the destination included in the header to the next-hop node. Also, the IAB node 300-1 transmits a downstream packet to be processed by BAP transmission to the next-hop node through routing processing and mapping processing.

[0418] (Modification of the Third Operation Example) At least a part of the third operation example according to the third embodiment is applicable to scenarios other than donor DU inter-routing.

[0419] [Fourth Embodiment] In the first to third embodiments, each scenario of inter-topology routing (S3-1), inter-topology rerouting (S3-1), and donor DU inter-routing (S2-2) has been described respectively.

[0420] Then, in all scenarios, there may be a problem of how to make the procedures or processes as common as possible.

[0421] FIG. 27 shows an example of the case where the procedures or processes are made common in all scenarios. FIG. 27 shows a configuration example of the IAB node 300 according to the fourth embodiment.

[0422] As shown in FIG. 27, the IAB node 300 includes a transmission unit 330-T and a reception unit 330-R.

[0423] The transmission unit 330-T includes a BAP header rewriting determination unit 331, a BAP header rewriting unit 332, a routing / mapping table selection unit 333, a routing / rerouting processing unit 334, and a mapping processing unit 335.

[0424] The reception unit 330-R includes an upper layer output determination unit 336.

[0425] The upper layer output determination unit 336 determines whether to output the received packet to the upper layer or output the packet to the transmission unit 330-T. For example, as described in the first embodiment, the determination may be made based on an identifier included in the header of the packet indicating whether it is a target for inter-topology routing.

[0426] The BAP header rewriting determination unit 331 determines whether to perform BAP header rewriting on the packet received from the reception unit 330-R. The BAP header rewriting determination unit 331 may determine a packet to be subjected to BAP header rewriting (= a packet that is a target for inter-topology routing), for example, based on whether the header of the packet matches a specific routing ID, as described in the first embodiment. The BAP header rewriting determination unit 331 outputs a packet that is a target for BAB header rewriting to the BAP header rewriting unit 332, and outputs a packet that is not a target for BAP header rewriting to the routing / re-routing processing unit 334.

[0427] The BAP header rewriting unit 332 rewrites the BAP header of the packet. The BAP header rewriting unit 332 may perform the rewriting using a BAP header rewriting table, as described in the first embodiment. Also, the BAP header rewriting unit 332 may be configured not to perform BAP header rewriting on a packet that has never undergone routing processing, and to perform BAP header rewriting on a packet output from the routing / re-routing processing unit 334. The routing / mapping table selection unit 333 selects a routing table and a mapping table. The routing / mapping table selection unit 333 may select, for example, a second routing table and a second mapping table, as described in the first embodiment.

[0428] The routing / re-routing processing unit 334 performs routing processing and / or re-routing processing on the packets with the BAP header rewritten, and may also perform routing processing and / or re-routing processing on the packets without the BAP header rewritten. As described in the third embodiment, the routing / re-routing processing unit 334 may once perform routing processing (and / or re-routing processing), and output the packets with no destination to the BAP header rewriting unit 332.

[0429] The mapping processing unit 335 performs mapping processing on the packets after routing processing or the packets after re-routing processing using a mapping table. The mapping processing unit 335 transmits the processed packets to the next-hop node via the outflow backhaul RLC channel.

[0430] As described above, the configuration example of the IAB node 300 shown in FIG. 27 is an example.

[0431] Each embodiment, each operation example, each process, or each step described in the first to fourth embodiments can be combined with each other. All or part of the embodiments of the first to fourth embodiments can be combined within a non-conflicting range. By such combination, it may be possible to standardize procedures or processes in all scenarios.

[0432] [Other Embodiments] A program for causing 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. Using the computer-readable medium, it is possible to install the program on a computer. Here, 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, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.

[0433] Also, circuits that execute each process performed by the UE 100 or the gNB 200 may be integrated, and at least a part of the UE 100 or the gNB 200 may be configured as a semiconductor integrated circuit (chipset, SoC: System on a chip).

[0434] As used in this disclosure, the descriptions “based on” and “depending on” do not mean “only based on” and “only depending on” unless otherwise specified. The description “based on” means both “only based on” and “at least partially based on”. Similarly, the description “depending on” means both “only depending on” and “at least partially depending on”. Also, “obtain / acquire” may mean obtaining information from stored information, obtaining information from information received from other nodes, or obtaining the information by generating the information. Terms such as “include”, “comprise”, and their variants do not mean including only the listed items, and may include only the listed items or may further include additional items in addition to the listed items. Also, the term “or” used in this disclosure is not intended to be an exclusive disjunction. Furthermore, any reference to elements using designations such as “first”, “second”, etc. used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used in this specification as a convenient way to distinguish between two or more elements. Therefore, references to the first and second elements do not mean that only two elements can be employed there or that the first element must precede the second element in some form. In this disclosure, for example, when articles are added by translation like a, an, and the in English, these articles shall be construed to include a plurality if not otherwise indicated from the context.

[0435] The above has described one embodiment in detail with reference to the drawings. However, the specific configuration is not limited to the above, and various design changes and the like can be made without departing from the gist.

[0436] This application claims the priority of U.S. Provisional Application No. 63 / 257,238 (filed on October 19, 2021), and all of its content is incorporated herein by reference.

[0437] (Appendix) Introduction In RAN2#115E, the work item of enhanced integrated access and backhaul (EIAB) for NR reached the following agreement regarding the enhancement of topology adaptation.

[0438] The set threshold of the available buffer size based on flow control feedback is used to determine congestion for the purpose of local routing.

[0439] In the case of within the CU, support donor DU - to - donor DU routing in at least the scenarios of NR - DC, donor DU - to - donor DU recovery, and donor DU - to - donor DU mobility.

[0440] Support CU - to - CU routing. That is, the IAB node reroutes data to the original donor CU via an alternative BAP path on the topology of the target CU.

[0441] In donor DU - to - donor DU routing, support rewriting of the BAP header from the previous routing ID to a new routing ID.

[0442] Further discuss the open issues of CU - to - CU routing in RAN2. What is the BAP address added to the BAP header of the initial topology (i.e., the BAP address of the incoming data at the border node)? How to distinguish between concatenated traffic routing and non - concatenated traffic routing? Method for determining whether to deliver data to the upper layer (for downstream). Method for determining whether to rewrite the BAP header of the data (whether to be routed to another topology or to the local topology).

[0443] As a baseline, in CU - to - CU routing, support 1:1 and N:1 mapping from the "previous routing ID" to the "new routing ID" for rewriting the BAP header at the boundary node.

[0444] As a baseline, in CU - to - CU routing, support 1:1 and N:1 mapping from the "inflow BH link + inflow BH RLC ID" of the bearer mapping at the boundary node to the "outflow BH link + outflow BH RLC ID".

[0445] This appendix discusses the extension of routing and re - routing for various scenarios.

[0446] Discussion In REL - 17, as shown in Figure 9, routing and re - routing need to cover various scenarios such as within the CU / within the donor DU (similar to REL - 16), between the CU / within the donor DU, and between CUs. These enhancements to the functionality are expected to contribute to the reliability, flexibility, or low - latency of packet transfer in the IAB topology, but may introduce additional complexity to the BAP routing / re - routing operation. Therefore, it is desirable to define procedures common to all scenarios and minimize scenario - specific procedures. In this sense, it is necessary to first consider the most complex scenario, CU - to - CU routing, and then examine whether the procedures for CU - to - CU routing can be applied (reused) to other scenarios.

[0447] Routing between CUs Regarding routing between CUs, four Open Issues have been agreed upon. This serves as a good starting point for considering how to resolve the Open Issues.

[0448] Open Issue 1: What is the BAP address added to the BAP header of the first topology (i.e., the BAP address of the incoming data at the border node)?

[0449] Some solution examples are shown as follows. Example 1: Add the BAP address of the border node to the BAP PDU header of the first topology. Example 2: Add the proxy / fake BAP address of the actual destination.

[0450] On the other hand, in RAN3, the following has been agreed upon regarding the redundancy of the topology. 1A: RAN3 assumes that the border node has only one BAP address in each topology. 1B: RAN3 assumes that in each topology, the BAP address of the border node of that topology is used only to identify the packets that must be passed to the upper layer.

[0451] Although both examples are functional, Example 1 is considered to be more in line with the assumptions of RAN3 (especially 1A). Furthermore, Example 1 is very simple from the perspective of the REL-16 routing mechanism because the border node is considered an endpoint of the first topology, such as an IAB-donor DU or an access IAB node. Also, Example 1 has a lower risk of "misrouting" when the intermediate IAB node performs local rerouting. In this sense, RAN2 should agree on Example 1 for further discussion.

[0452] Proposal 1: RAN2 should agree that in the first topology, the BAP address of the border node is added to the BAP data PDU header (i.e., the destination field).

[0453] Open Issue2: Method for discriminating between in-topology routing (concatenated traffic) and inter-topology routing (non-cocatenated traffic)

[0454] If agreeing with Proposal 1, in-topology routing (concatenated traffic (routing between two topologies belonging to different IAB donor CUs)) has the BAP address of the border IAB node in the destination field of the BAP data PDU header. On the other hand, inter-topology routing (non-cocatenated traffic (routing within a topology belonging to one IAB donor CU)) has another BAP address, that is, the BAP address of the IAB donor DU or the access IAB node. That is, if the destination does not match the BAP address of the border IAB node, the BAP data PDU is delivered from the receiving part to the transmitting part of the collocation BAP entity. Therefore, no special processing is required in the receiving part. However, it should be noted that the following Open Issue 3 still exists.

[0455] Proposal 2: RAN2 should agree that no special processing is required in the receiving part of the BAP entity to determine inter-topology routing (non-cocatenated traffic), that is, the operation of REL-16 is applied.

[0456] Open Issue 3: Method for determining the feasibility of data delivery to the upper layer (downstream)

[0457] If agreeing to Proposal 1, the in-topology routing (concatenated traffic) and the traffic destined for the border IAB node will have the same destination in each BAP data PDU header, that is, the BAP address of the border IAB node. Therefore, the receiving part of the BAP entity of the border IAB node can discriminate them by the path field or the new flag (using any of the three "R" bits) in each BAP data PDU header.

[0458] When using the path field, the routing ID space is consumed according to the number of paths set between the border IAB node and the IAB donor DU / access IAB node. To reuse the existing fields in the BAP header, there is no additional overhead in the data stream.

[0459] When the new flag is used, it consumes the "R" bit, so there are only three reserved bits. To use the "R" bit in the BAP header, there is no additional overhead. Also, this flag is assumed to be useful when the transmitting part of the BAP entity decides whether to rewrite the BAP header.

[0460] Considering the above advantages and disadvantages, it is desirable to define a new flag using one "R" bit to discriminate the routed data. Needless to say, if this new flag is set to "0", it will be exactly the same as the BAP header format of REL-16. Therefore, the receiving part of the BAP entity will send the data to the upper layer according to the operation of REL-16.

[0461] Proposal 3: For CU-CU routing, RAN2 should agree to define a new flag using one "R" bit in the BAP data PDU header to discriminate the routed data and the data delivered to the upper layer.

[0462] Open Issue 4: How to determine whether to rewrite the BAP header of the data (whether to be routed to another topology or routed to its own topology)

[0463] If Proposal 2 and Proposal 3 are agreed, the transmitting part of the BAP entity can first check the new flag of each BAP data PDU header. If the new flag is "0" (i.e., inter-topology routing (non-cocatenated traffic) including REL-16 BAP data PDUs or "routed to its own topology"), the REL-16 routing procedure is executed. (That is, in the case of in-topology routing (concatenated traffic) or "routed to another topology"), the BAP header rewriting operation is executed before the routing procedure. Since this is not "re-routing", it is natural that the BAP header rewriting operation is performed in advance.

[0464] Proposal 4: RAN2 should agree to use the new flag of the BAP data PDU header in Proposal 3 to determine whether to rewrite the BAP header for CU-CU routing.

[0465] Proposal 5: For CU-CU routing, RAN2 should agree that the BAP header rewriting is executed before the routing procedure.

[0466] If Proposal 3 and Proposal 5 are agreed, the new flag is used at the border IAB node. Therefore, it may become meaningless after the BAP header rewriting operation or rather cause unnecessary errors in the second topology. Therefore, it is safe to rewrite the flag to "0" at the border IAB node. This is considered to be easy to do during the BAP header rewriting operation.

[0467] Proposal 6: For CU-CU routing, RAN2 should discuss whether to also rewrite the new flag in Proposal 3 during the BAP header rewriting operation, that is, reset it to "0".

[0468] Other possible problems Selection of routing table If Proposal 5 is agreed, the data with the header rewritten according to the header rewrite setting will proceed to the routing procedure. In this case, since the header of the data has already been rewritten to the new routing ID as RAN2 agreed to "support inter-topology routing by rewriting the BAP header based on BAP routing ID option 4 for the priority of RAN2", the routing table set in the first topology, that is, the BH routing setting is not valid. Otherwise, since the BAP address of each IAB node is unique within the topology and not unique between two topologies (i.e., two CUs) even in the CU-CU routing scenario, there may be a risk of confusion or "misrouting". Therefore, the routing table needs to use the one configured by the second topology.

[0469] Proposal 7: In the CU-CU scenario, RAN2 should agree to be configured with two routing tables used by the border node to route to the first topology and the second topology respectively.

[0470] If Proposal 7 is agreed, before the routing procedure, a routing table selection procedure for each data may be required. The mechanism is considered very simple. For a certain data, if the header is rewritten (or the new flag is set to "1"), the second routing table is applied. Otherwise, the first routing table (i.e., the same as REL-16) is applied.

[0471] Proposal 8: In the CU-CU scenario, RAN2 should discuss whether a procedure for selecting the routing table of the second topology is required for in-topology routing (concatenated traffic).

[0472] Selection of BH RLC Channel Mapping Table When the next-hop BAP address is determined in the routing procedure, mapping to the outgoing BH RLC channel is performed based on the determined incoming BH link, incoming BH RLC channel, and outgoing BH link prepared in the mapping table (= BH RLC channel mapping setting). The following notes are recorded in the current running CR of TS38.340.

[0473] Note: Further consideration is required on how to record bearer mapping at the border IAB node (further consideration is also required on whether the current specification already supports bearer mapping at the border IAB node for routing between CUs).

[0474] In the case of the inter-CU scenario, the incoming BH link and RLC channel belong to the first topology, and the outgoing BH link is associated with the second topology. Since the BAP address and RLC channel are managed by the CU (i.e., for each topology), a new mapping table is required to connect the two topologies. Specifically, the structure of the REL-16 mapping table can be reused, but it needs to be composed of a mapping table different from REL-16. Otherwise, if the same BAP address (i.e., incoming / outgoing link ID) and / or the same BH RLC channel ID are used in both topologies, there is a risk of "incorrect mapping". In this case, the selection of the mapping table similar to Proposal 8 may be required.

[0475] Proposal 9: In the inter-CU scenario, RAN2 shall agree that the border IAB node is composed of another mapping table (in addition to the REL-16 mapping table), and that mapping table is applied to in-topology routing (concatenated traffic).

[0476] RAN2 to discuss whether a procedure to select an individual mapping table for connecting the two topologies of Proposal 9 in the CU - to - CU scenario is necessary for in - topology routing (concatenated traffic).

[0477] Inter - CU re - routing Applicability of BAP header rewriting operation

[0478] RAN2 has agreed on "support for inter - ICU re - routing, i.e., an IAB node re - routes data to the original donor CU via an alternative BAP path on the topology of the target CU". Generally, this agreement can be regarded as similar to inter - CU routing. However, in detail, when the IAB node re - establishes an RRC connection with the target donor CU and the F1 connection with the source donor CU is still maintained (i.e., partial handover), inter - CU re - routing is applied. RAN3 has agreed on the following description which is likely to be applied to this scenario.

[0479] In partial donor - to - donor handover, the IP address, BAP address, BH RLC CH, and default mapping used by the border node for traffic of a specific topology are assigned by the CU of that topology and they are configured via RRC.

[0480] In addition to the above configuration, the RRC (of the target donor CU) also provides a (simple) routing table and / or header rewriting settings used by the border IAB node. This is because the original routing ID of the BAP header of the data rerouted to the original second topology is no longer valid, i.e., the border IAB node needs to know the valid routing ID in the new second topology managed by the target donor CU. In this sense, the BAP header rewriting operation is also necessary for inter-CU rerouting. In contrast to inter-CU routing, the BAP header rewriting operation is performed as "rerouting" when the routing procedure fails, as already recorded in the BAP RUNNING CR. Also, if Proposal 7 and Proposal 8 are agreed upon, the selection of the routing table may also be applicable to inter-CU rerouting. Also, if Proposal 9 and Proposal 10 are agreed upon, the selection of the BH RLC channel mapping table may also be applicable.

[0481] Thereafter, the border IAB node can send data to the next-hop BAP address via the BH RLC channel configured by the RRC of the new second topology, i.e., by the target donor CU.

[0482] Proposal 11: For inter-CU rerouting, RAN2 should agree that the border IAB node is configured by the RRC signal from the target donor with an IP address, BAP address, BH RLC channel and default mapping (as agreed by RAN3), and a default routing ID (or a simplified header rewriting table), etc.

[0483] Proposal 12: For inter-CU rerouting, RAN2 should agree to perform the BAP header rewriting operation when the routing (REL-16 routing) fails.

[0484] RAN2 should discuss whether the routing table selection (if Proposal 8 is introduced) and the mapping table selection (if Proposal 10 is introduced) are applicable for CU-CU relaying.

[0485] Intra-CU / Intra-DU relaying

[0486] RAN2 has agreed to support the rewriting of the "new routing ID from the previous routing ID" BAP header in donor DU-DU relaying. On the other hand, RAN3 has agreed as follows.

[0487] RAN3 hopes that the border node will perform BAP header rewriting for both UL and DL traffic only for traffic routed in the BAP layer from a BH link of one topology to a BH link of an adjacent topology.

[0488] Since the topology is managed by the donor CU and the two donor DUs within the donor CU are considered as intra-CU topology reduction, it is considered that the relaying between donor DUs is still executed within one topology. In this case, the agreement of RAN2 may conflict with the priority of RAN3. However, due to the change of the destination of the upstream traffic by the donor DU-DU relaying, that is, from the BAP address of one donor DU to the BAP address of another donor DU, the BAP header rewriting operation is naturally necessary. For the downstream traffic, since the destination (BAP address of the access IAB node) does not change, the BAP header rewriting operation may not be necessary. In fact, it is assumed that the downstream traffic is not subject to donor DU-DU relaying (i.e., it is just local relaying). Therefore, RAN2 should confirm its agreement even if it is different from the priority of RAN3.

[0489] Proposal 14: Regarding CU-internal / DU-interconnect routing, at least for upstream traffic, confirm the previous RAN2 agreement of "supporting the rewriting of the BAP header from the previous routing ID to a new routing ID".

[0490] In Proposal 14, since this is "routing", when the REL-16 routing fails, similar to the CU-interconnect routing in Proposal 12, perform the BAP header rewriting operation. This is already recorded in the current RUNNING CR of TS 38.340 and can be simply confirmed.

[0491] Proposal 15: Regarding CU-internal / Donor DU routing, RAN2 should confirm that the BAP header rewriting operation is performed when the routing (i.e., REL-16 routing) fails, as recorded in the current execution CR of TS38.340.

[0492] CU-internal / Donor DU-internal routing (= local routing) Applicability of the BAP header rewriting operation

[0493] The routing within CU-internal / Donor DU is called local routing and has already been supported since REL-16 as follows.

[0494] Note: The data buffering in the BAP entity transmitter until the RLC-AM entity receives the confirmation response depends on the implementation. In the case of BH RLF, the transmitter of the BAP entity can route the BAP data PDU that was not confirmed by the lower layer before BH RLF to the alternative path according to Section 5.2.1.3.

[0495] When there is at least one entry in the BH routing setting where the BAP address matches the destination field and the outgoing link corresponding to the next-hop BAP address is available From the BH routing settings, select an entry where the BAP address is the same as the destination field and the egress link corresponding to the next-hop BAP address is available. Select the egress link corresponding to the next-hop BAP address of the entry selected above.

[0496] According to the current specification, the IAB node can send the BAP data PDU via a routing ID that matches the destination but not the data path as a result of local routing.

[0497] On the other hand, in RAN2#112-E, it was agreed that the local routing of REL-17 should consider the goals of the entire topology as follows. RAN2 will discuss local routing, including its advantages for central route determination, and how it can address the goals of the entire topology.

[0498] Considering the above agreement, in the local route of REL-16, there is a problem that the selection of the alternative path is left to the implementation of the IAB node and may be difficult to manage from the perspective of the donor. In the REL-16 IAB topology, local routing is only permitted when the IAB node detects BH RLF, that is, only in a specific abnormal state, so it does not pose a major problem. However, in REL-17, local routing is permitted under other conditions (e.g., congestion), so although it is not the case, there are still issues regarding how to meet the above agreement. To achieve the goals of the entire topology, it is very easy to understand that the donor who manages the entire topology is most suitable. In this sense, the donor needs to enhance the controllability of local routing in terms of alternative path setting compared to the REL-16 mechanism.

[0499] Finding 1: In the local routing of REL-16, which alternative path to select depends on the implementation of the IAB node and cannot be managed by the donor.

[0500] Observation 2: The IAB donor is the most suitable node to work towards the topology-wide goal through local routing.

[0501] To solve this problem, the BAP header rewriting operation is considered as one solution. RAN2 agrees as follows. Assume that the IAB donor sets an (alternative) egress link that can be used in local routing (further consideration of at least the same destination and the same routing ID is required).

[0502] The egress link is associated with the N next-hop BAP address, and the next-hop BAP address is determined by the routing ID. Therefore, it is natural for the donor side to set a new routing ID for the IAB node to perform local routing, which is very similar to the header rewriting settings in other (re)routing scenarios.

[0503] RAN3 hopes to execute the BAP header writing operation only in the inter-topology scenario, but RAN2 has already agreed to execute it also in the intra-topology scenario, that is, the DU routing between donors as described above.

[0504] Therefore, it seems worthwhile to discuss whether the BAP header rewriting operation is also applicable to the routing within the CU / within the DU, and thus whether it is only executed when the header rewriting setting is configured (option).

[0505] Proposal 16: RAN2 should discuss the option when the BAP header rewriting is also applicable to local routing (i.e., the routing within the CU / between the DUs), and the IAB node is composed of the mapping between the old routing ID and the new routing ID (i.e., similar to the header rewriting setting in the current execution CR of TS38.340).

[0506] Local Route Command by Donor As another aspect of the controllability of the IAB donor, it is necessary to consider that the IAB donor can recognize local routing and start / stop local routing at the IAB node, so that the local routing and the overall topology goals can coexist. For example, if the IAB donor notices that it cannot achieve the overall topology goal, the IAB donor can instruct the IAB node to start / stop local routing.

[0507] How to handle the overall topology goal by local routing depends entirely on the implementation of the IAB donor, but the IAB donor may need the local decision information and controllability of the IAB node.

[0508] Proposal 17: RAN2 should discuss whether the IAB node needs to notify the IAB donor when starting / stopping local routing.

[0509] Proposal 18: RAN2 should discuss whether the IAB donor can instruct the IAB node to start / stop local routing, for example, for load distribution between routes.

[0510] Summary of enhanced functions If the above proposals are agreed, an example of a unified solution for all scenarios is shown in Figure 27.

Claims

1. A communication control method used in a cellular communication system, wherein a relay node receives upstream packets, and the relay node performs routing processing on the packets based on routing setting information having a plurality of routing IDs, and performing the routing processing includes performing donor DU - to - donor DU rerouting on the packet when an egress backhaul link corresponding to a routing ID that matches the destination information included in the BAP header of the packet is unavailable and the donor node has instructed the relay node that donor DU - to - donor DU rerouting is possible, a communication control method.

2. Furthermore, the relay node performs BAP header rewriting processing for rewriting the destination of the packet for which the donor DU - to - donor DU rerouting is performed. The communication control method according to claim 1.

3. Performing the BAP header rewriting processing includes writing the predetermined routing ID into the header of the packet when an egress backhaul link corresponding to the predetermined routing ID included in the routing setting information is available. The communication control method according to claim 2.

4. The relay node further receives the routing setting information applicable to both intra - topology routing and inter - topology routing from a donor node, and in the routing setting information, an entry applicable to the inter - topology routing includes information indicating that it is the inter - topology routing. The communication control method according to claim 1.

5. The relay node performs the donor DU - to - donor DU rerouting between different topologies belonging to different donor CUs. The communication control method according to claim 1.

6. the BAP address of the relay node in each topology is set, the BAP layer of the relay node receives the packet, and when the BAP address of the relay node in the topology associated with the ingress backhaul RLC channel of the packet matches the destination BAP address included in the header of the packet, the packet is output to an upper layer. The communication control method according to claim 1.

7. The relay node is a boundary relay node having two connections, namely a connection with the first topology of the first donor node and a connection with the second topology of the second donor node. The communication control method according to claim 6.

8. The relay node has an RRC connection with one of the first donor node and the second donor node, and has an F1 connection with the other of the first donor node and the second donor node. The communication control method according to claim 7.

9. The relay node is set with a first BAP address in the first topology managed by the first donor node, is set with a second BAP address in the second topology managed by the second donor node. The communication control method according to claim 7.

10. Each of the first BAP address and the second BAP address is set in the relay node by an F1AP message or an RRC message. The communication control method according to claim 9.

11. Outputting the packet to the upper layer includes removing the BAP header of the packet, and outputting the packet with the BAP header removed to the upper layer. The communication control method according to claim 6.

12. Outputting the packet to the upper layer includes the receiving part of the BAP layer outputting the packet to the upper layer. The communication control method according to claim 6.

13. The receiving part of the BAP layer further outputs the packet to the transmitting part of the BAP layer when the BAP address of the relay node in the topology associated with the incoming backhaul RLC channel of the packet does not match the destination BAP address included in the header of the packet. The communication control method according to claim 6.

14. A relay node used in a cellular communication system, comprising a receiving unit that receives packets in the upstream direction, and a control unit that performs routing processing on the packets based on routing setting information having a plurality of routing IDs. In the routing process, when the outflow backhaul link corresponding to the routing ID that matches the destination information included in the BAP header of the packet is unavailable, and the donor node has instructed the relay node that donor DU - to - donor rerouting is possible, the control unit performs the donor DU - to - donor rerouting on the packet. Relay node.

15. A cellular communication system comprising the relay node according to claim 14.

16. A chipset that executes the communication control method according to claim 1.

17. A program that causes a relay node to execute the communication control method according to claim 1.

Images