COMMUNICATION CONTROL METHOD, IAB NODE, CELLULAR COMMUNICATION SYSTEM, CHIP SET, AND PROGRAM

Abstract

A communication control method according to a first aspect is a communication control method in a boundary IAB node. The boundary IAB node has an RRC connection with a first IAB donor which controls a first IAB topology, and an RRC connection with a second IAB donor that controls a second IAB topology. The boundary IAB node has an F1 connection with the first IAB donor, but does not have an F1 connection with the second IAB donor. The communication control method includes: receiving BAP header rewriting configuration information from the first IAB donor; receiving a BAP packet from a lower IAB node; performing BAP header rewriting processing on the received BAP packet on the basis of the BAP packet header information and the BAP header rewriting configuration information; and routing the BAP packet, which has undergone the BAP header rewriting processing, via the second IAP topology.

Description

[Technical field]

[0001] The present disclosure relates to a communication control method and a border IAB node. [Background technology]

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

[0003] A communication control method according to a first aspect is a communication control method in a border IAB node. The border IAB node has an RRC connection with a first IAB donor that controls a first IAB topology and an RRC connection with a second IAB donor that controls a second IAB topology. The border IAB node has an F1 connection with the first IAB donor and does not have an F1 connection with the second IAB donor. The communication control method includes receiving BAP header rewrite setting information from the first IAB donor, receiving a BAP packet from a lower IAB node, performing a BAP header rewrite process on the received BAP packet based on header information of the BAP packet and the BAP header rewrite setting information, and routing the BAP packet that has been subjected to the BAP header rewrite process via the second IAB topology.

[0004] A border IAB node according to a second aspect has an RRC connection with a first IAB donor that controls a first IAB topology and an RRC connection with a second IAB donor that controls a second IAB topology. The border IAB node has an F1 connection with the first IAB donor and does not have an F1 connection with the second IAB donor. The border IAB node includes a processor. The processor executes the following processes: receiving BAP header rewrite setting information from the first IAB donor; receiving a BAP packet from a lower IAB node; performing a BAP header rewrite process on the received BAP packet based on the header information of the BAP packet and the BAP header rewrite setting information; and routing the BAP packet that has been subjected to the BAP header rewrite process via the second IAB topology. [Brief description of the drawings]

[0005] [Figure 1] FIG. 1 is a diagram showing an example of the configuration 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 an example configuration of a gNB (base station) according to one embodiment. [Figure 4] FIG. 4 is a diagram illustrating a configuration example of an IAB node (relay node) according to an embodiment. [Diagram 5] FIG. 5 is a diagram illustrating 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 an RRC connection and a 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 for the F1-C protocol. [Figure 9]FIG. 9(A) is a diagram showing an example of a topology configuration in an "intra-CU / intra-donor-DU" scenario, FIG. 9(B) is an "intra-CU / between-donor-DU" scenario, and FIG. 9(C) is a diagram showing an example of a topology configuration in an "inter-CU" scenario. [Figure 10] FIG. 10 is a diagram illustrating a first operation example according to the first embodiment. [Figure 11] FIG. 11 is a diagram summarizing a first operation example according to the first embodiment. [Figure 12] FIG. 12 is a diagram illustrating an example of an operation according to the fourth modification of the first embodiment. [Figure 13] FIG. 13 is a diagram illustrating a second operation example according to the first embodiment. [Figure 14] FIG. 14 is a diagram illustrating an example of the configuration of a BAP Data PDU packet according to the first embodiment. [Figure 15] FIG. 15 is a diagram illustrating a third operation example according to the first embodiment. [Figure 16] FIG. 16 is a diagram illustrating a fourth operation example according to the first embodiment. [Figure 17] FIG. 17 is a diagram illustrating a fifth operation example according to the first embodiment. [Figure 18] FIG. 18 is a diagram illustrating a sixth operation example according to the first embodiment. [Figure 19] 19(A) and 19(B) are diagrams illustrating an example of a topology configuration according to the second embodiment. [Figure 20] FIG. 20 is a diagram illustrating an example of operation according to the second embodiment. [Figure 21] FIG. 21 is a diagram illustrating a modified example according to the second embodiment. [Figure 22] FIG. 22 is a diagram illustrating a first operation example according to the third embodiment. [Figure 23] FIG. 23 is a diagram summarizing a first operation example according to the third embodiment. [Figure 24] FIG. 24 is a diagram illustrating a second operation example according to the third embodiment. [Diagram 25] FIG. 25 is a diagram illustrating a third operation example according to the third embodiment. [Figure 26]FIG. 26 summarizes a third operation example according to the third embodiment. [Figure 27] FIG. 27 illustrates an example of the configuration of an IAB node according to the fourth embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0007] (Configuration of Cellular Communication System) A configuration example of a cellular communication system according to an embodiment will be described. The 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 applied at least partially to the cellular communication system 1. Furthermore, the cellular communication system 1 may also be applied to future cellular communication systems such as 6G.

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

[0009] As shown in Fig. 1, the cellular communication system 1 includes a 5G core network (5GC) 10, a user equipment (UE: User Equipment) 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 referred to as a gNB.

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

[0011] In the following, the base stations 200-1 and 200-2 may be referred to as gNB 200 (or base station 200), and the IAB nodes 300-1 and 300-2 may be referred to as IAB node 300.

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

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

[0014] Each gNB 200 is mutually connected to the 5GC 10 via an interface called an NG interface. In FIG. 1, two gNBs 200-1 and 200-2 connected to the 5GC 10 are illustrated.

[0015] Each gNB 200 may be divided into a central unit (CU) and a distributed unit (DU). The CU and the DU are connected to each other via an interface called an F1 interface. The F1 protocol is a communication protocol between the CU and the DU, and includes an F1-C protocol, which is a control plane protocol, and an F1-U protocol, which is a user plane protocol.

[0016] The cellular communication system 1 supports IAB, which enables wireless relay of NR access using NR for backhaul. The donor gNB 200-1 (or donor node, hereinafter sometimes referred to as "donor node") is a terminal node of the NR backhaul on the network side, and is a donor base station with additional functions that support IAB. The backhaul can be multi-hopped via multiple hops (i.e., multiple IAB nodes 300).

[0017] FIG. 1 illustrates an example in which IAB node 300-1 wirelessly connects to donor node 200-1, IAB node 300-2 wirelessly connects to IAB node 300-1, and the F1 protocol is transmitted over two backhaul hops.

[0018] The UE 100 is a mobile wireless communication device that performs wireless communication with a cell. The UE 100 may be any 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 laptop computer, a sensor or a device provided in a sensor, a vehicle or a device provided in a vehicle, or an aircraft or a device provided in an aircraft. The UE 100 wirelessly connects to the IAB node 300 or the gNB 200 via an access link. FIG. 1 shows an example in which the UE 100 is wirelessly connected to the IAB node 300-2. The UE 100 indirectly communicates with the donor node 200-1 via the IAB node 300-2 and the IAB node 300-1.

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

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

[0021] An adjacent node (i.e., an upper node) on the NR Uu radio interface of the IAB-MT is called a parent node. The parent node is a DU of the parent IAB node or the donor node 200. The radio link between the IAB-MT and the parent node is called a backhaul link (BH link). FIG. 2 shows an example in which the parent nodes of the IAB node 300 are IAB nodes 300-P1 and 300-P2. The direction toward the parent node is called upstream. From the perspective of the UE 100, the upper node of the UE 100 may correspond to the parent node.

[0022] Adjacent nodes (i.e., lower nodes) on the NR access interface of the IAB-DU are called child nodes. The IAB-DU manages cells, similar to the gNB 200. The IAB-DU terminates the NR Uu radio interface to the UE 100 and the lower IAB nodes. The IAB-DU supports the F1 protocol to the CU of the donor node 200-1. In FIG. 2, an example is shown in which the child nodes of the IAB node 300 are the IAB nodes 300-C1 to 300-C3, but the child nodes of the IAB node 300 may include the UE 100. The direction toward the child nodes is called downstream.

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

[0024] (Base station configuration) Next, a configuration of the gNB 200 which is a base station according to the embodiment will be described. Fig. 3 is a diagram showing an example of the configuration of the gNB 200. As shown in Fig. 3, the gNB 200 has a wireless communication unit 210, a network communication unit 220, and a control unit 230.

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

[0026] The network communication unit 220 performs wired communication (or wireless communication) with the 5GC10 and wired communication (or wireless communication) with other adjacent gNBs 200. The network communication unit 220 has a receiving unit 221 and a transmitting unit 222. The receiving unit 221 performs various receptions under the control of the control unit 230. The receiving unit 221 receives 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.

[0027] The control unit 230 performs various controls in the gNB 200. The control unit 230 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processing. The processor performs processing of each layer, which will be described later. Furthermore, the control unit 230 may perform each processing or each operation in the gNB 200 in each of the embodiments shown below.

[0028] (Configuration of relay node) Next, the configuration of the IAB node 300, which is a relay node (or relay node device, hereinafter sometimes referred to as a "relay node") according to the embodiment, will be described. FIG. 4 is a diagram showing an example of the configuration 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 multiple wireless communication units 310.

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

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

[0031] 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 a program executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of a baseband signal. The CPU executes a program stored in the memory to perform various processing. The processor performs processing of each layer, which will be described later. The control unit 320 may also perform each processing or each operation in the IAB node 300 in each of the following embodiments.

[0032] (Configuration of user device) Next, a configuration of the UE 100 which is a user device according to the embodiment will be described. Fig. 5 is a diagram showing an example of the configuration of the UE 100. As shown in Fig. 5, the UE 100 includes a radio communication unit 110 and a control unit 120.

[0033] The wireless communication unit 110 performs wireless communication in an access link, that is, wireless communication with the gNB 200 and wireless communication with the IAB node 300. The wireless communication unit 110 may also perform wireless communication in a side link, that is, wireless communication with another UE 100. The wireless communication unit 110 has a receiving unit 111 and a transmitting unit 112. The receiving unit 111 performs various receptions under the control of the control unit 120. The receiving unit 111 includes an antenna, and converts (down-converts) a wireless signal received by the antenna into a baseband signal (received signal) and outputs the signal to the control unit 120. The transmitting unit 112 performs various transmissions under the control of the control unit 120. The transmitting unit 112 includes an antenna, and converts (up-converts) a baseband signal (transmitted signal) output by the control unit 120 into a wireless signal and transmits the signal from the antenna.

[0034] 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 a program executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of a baseband signal. The CPU executes a program stored in the memory to perform various processing. The processor performs processing of each layer described later. The control unit 130 may perform each processing in the UE 100 in each of the following embodiments.

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

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

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

[0038] The MAC layer performs data priority control, retransmission processing using Hybrid Automatic Repeat reQuest (HARQ), random access procedures, etc. Data and control information are transmitted between the MAC layer of the IAB-MT of IAB node 300-2 and the MAC layer of the IAB-DU of IAB node 300-1 via a transport channel. The MAC layer of the IAB-DU includes a scheduler. The scheduler determines the transport format (transport block size, modulation and coding scheme (MCS)) and the assigned resource blocks for uplink and downlink.

[0039] The RLC layer transmits data to the RLC layer on the receiving side by utilizing the functions of the MAC layer and the PHY layer. Data and control information are transmitted between the RLC layer of the IAB-MT of the IAB node 300-2 and the RLC layer of the IAB-DU of the IAB node 300-1 via a logical channel.

[0040] The PDCP layer performs header compression / decompression and encryption / decryption. Data and control information are transmitted between the PDCP layer of the IAB-MT of the IAB node 300-2 and the PDCP layer of the donor node 200 via a radio bearer.

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

[0042] The NAS layer, which is located above the RRC layer, performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of the IAB-MT of the IAB node 300-2 and the AMF 11.

[0043] Fig. 7 is a diagram showing a protocol stack for the F1-U protocol. Fig. 8 is a diagram showing a protocol stack for the F1-C protocol. Here, an example is shown in which the donor node 200 is divided into a CU and a DU.

[0044] As shown in Fig. 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 a layer above the RLC layer. The BAP layer is a layer that performs routing processing and bearer mapping / demapping processing. In the backhaul, the IP layer is transmitted through the BAP layer, enabling routing in multiple hops.

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

[0046] 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 UDP layer shown in FIG.

[0047] In the following, the processing or operation performed by the IAB-DU and IAB-MT of the IAB may be simply described as the processing or operation of the "IAB". For example, the transmission of a BAP layer message by the IAB-DU of the IAB node 300-1 to the IAB-MT of the IAB node 300-2 will be described as the IAB node 300-1 transmitting the message to the IAB node 300-2. In addition, the processing or operation of the DU or CU of the donor node 200 may be simply described as the processing or operation of the "donor node".

[0048] Also, the upstream direction and the uplink (UL) direction may be used interchangeably, and the downstream direction and the downlink (DL) direction may be used interchangeably.

[0049] (Routing and rerouting scenarios) One of the functions of the BAP layer is routing and re-routing. Routing, for example, is to control to which IAB node 300 a received packet is to be transferred. Re-routing, for example, is to control to transfer a received packet to a destination node (access IAB node or donor node) via an alternative path.

[0050] In 3GPP, how to perform routing or rerouting in a network (or topology) formed by a plurality of IAB nodes 300 is being considered.

[0051] Regarding routing and rerouting, there are the following scenarios:

[0052] (S1)Intra-CU / Intra-donor-DU (S1-1) Routing (S1-2) Rerouting (S2) Intra-CU / Inter-donor-DU (S2-1) Routing (S2-2) Rerouting (S3) Inter-CU (S3-1) Routing (S3-2) Rerouting Taking such scenarios into consideration, it is expected that by considering procedures or processes common to each scenario, as well as procedures or processes specific to each scenario, it will be possible to improve the reliability, flexibility, and low latency of packet forwarding in the topology.

[0053] Here, each scenario will be described.

[0054] (S1) About the "Inside CU / Inside donor DU" scenario FIG. 9(A) shows an example of a topology configuration in the "intra-CU / intra-donor-DU" scenario.

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

[0056] As shown in FIG. 9(A), there are two routes between the IAB node 300-1 and the donor DU (200D): a route via the IAB node 300-2 and a route via the IAB node 300-3. The IAB node 300-1 can forward packets in the uplink direction to either route. The IAB node 300-1 can also forward packets in the downlink direction that have been forwarded via either of the routes to the IAB node 300-4 or the IAB node 300-5. In routing (S1-1), the existence of these two routes ensures redundancy in the routes.

[0057] In addition, the rerouting (S1-2) is a so-called local rerouting. For example, when the IAB node 300-1 detects a radio link failure (BH RLF (Radio Link Failure)) (hereinafter, sometimes referred to as "BH RLF") in a backhaul link to the IAB node 300-2, it is also possible to perform rerouting by switching the route of the uplink direction packet to an alternative path via the IAB node 300-3.

[0058] (S2) About the "Intra-CU / Inter-donor-DU" scenario FIG. 9B is a diagram showing an example of a topology configuration in the "intra-CU / inter-donor-DU" scenario.

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

[0060] As shown in Figure 9 (B), there are two paths between IAB node 300-1 and donor node CU (200C): a path via IAB node 300-2 and donor DU #1 (200D1), and a path via IAB node 300-3 and donor DU #2 (200-D2).

[0061] In the uplink direction routing in the IAB node 300-1, the IAB node 300-1 can forward a packet to the IAB node 300-2 or the IAB node 300-3. In the downlink direction, the IAB node 300-1 can forward a packet forwarded via any of the above routes to the IAB node 300-4 or the IAB node 300-5. Transfer Can be sent.

[0062] In this scenario, the DUs of the donor nodes are different, but the CUs of the donor nodes are the same, so the routing is within the same topology. Such routing is sometimes called intra-topology routing.

[0063] Regarding rerouting in the IAB node 300-1, for example, consider a case where a route via the IAB node 300-2 is switched to a route (alternative path) via the IAB node 300-3. 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. For this reason, 3GPP agreed to rewrite the BAP header in this scenario. Rewriting the BAP header means rewriting the BAP header from the previous routing ID (previous routing ID) to a new routing ID (new routing ID). The routing ID is composed of a destination BAP address (Destination) and a path identifier (Path ID).

[0064] (S3) About the "Inter-CU" scenario FIG. 9C is a diagram showing an example of a topology configuration in the “inter-CU” scenario.

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

[0066] In general, different topologies are formed by different donor CUs. That is, the topology (first topology) formed on the path from donor CU#1 (200C1) to the IAB node 300-1 and the topology (second topology) formed on the path from donor CU#2 (200C2) to the IAB node 300-1 may be different. The IAB node 300-1 is located on the boundary between two different topologies. Such an IAB node 300-1 may be called a boundary IAB node.

[0067] Regarding the routing (S3-1) of this scenario, the boundary IAB node 300-1 can forward a packet addressed to donor DU #1 (200D1) to donor DU #2 (200D1) of a different topology. Also, a packet addressed to the IAB node 300-4 can be forwarded via a different topology. For example, a packet transmitted from donor CU #1 (200C1) can be forwarded to the IAB node 300-4 via donor CU #2 (200C2), donor DU #2 (200D2), IAB nodes 300-3 and 300-1. In these cases, the DU of the destination donor node is changed, so it was agreed in 3GPP to rewrite the BAP header.

[0068] Such routing between different topologies is sometimes called inter-topology routing.

[0069] Regarding rerouting in this scenario, for example, the border IAB node 300-1 can forward a packet addressed to the donor DU#1 (200D1) via an alternative path on the topology in the donor CU#2 (200C2).

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

[0071] Three scenarios have been explained above. For these three scenarios, it is desirable to reduce the procedures specific to each scenario as much as possible and specify procedures or processes common to all the scenarios. This is because the processes can be simplified by using common procedures or processes compared to individual processes for each scenario.

[0072] In this embodiment, each scenario will be described in the following order.

[0073] [First embodiment] Inter-CU routing (First operation example) (Second operation example) (Third operation example) (Fourth operation example) (Fifth operation example) (Sixth operation example) [Second embodiment] Inter-CU rerouting [Third embodiment] Intra-CU / donor-DU rerouting (First operation example) (Second operation example) (Third operation example) In the following description, "BH Routing Configuration" may be referred to as a "routing table." Furthermore, "BH RLC Channel Mapping Configuration" may be referred to as a "mapping table." Furthermore, "Header Rewriting Configuration" may be referred to as a "header rewriting table."

[0074] Furthermore, "inter-CU routing" may be referred to as "inter-topology routing," and "inter-CU rerouting" may be referred to as "inter-topology rerouting."

[0075] Furthermore, "intra-CU / donor-DU rerouting" may be referred to as "donor-DU rerouting".

[0076] Furthermore, layers and entities are sometimes used interchangeably.

[0077] [First embodiment] The first embodiment is an embodiment regarding inter-topology routing.

[0078] Regarding inter-topology routing, the following four open issues are being discussed in 3GPP.

[0079] (Assignment 1) "What's the BAP address added in BAP header in the first topology (ie the BAP address of ingress data at the boundary node)."

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

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

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

[0083] (Problem 1) is a problem about what BAP address should be set in the header of the BAP packet (BAP PDU) to be routed between topologies by the DU of the access IAB node or the donor node. For example, if the border IAB node 300-1 can distinguish between the BAP packet to be routed between topologies and the packet not based on the set BAP address, it can appropriately process the packet by performing inter-topology routing or normal routing processing.

[0084] (Problem 2) is, for example, when the border IAB node 300-1 performs inter-topology routing (non- n If the border IAB node can properly distinguish between inter-topology routing and intra-topology routing, it will be possible to properly perform inter-topology routing and intra-topology routing.

[0085] (Problem 3) is a problem on how a border IAB node determines which packets should be passed to its upper layer. For example, a border IAB node can receive two packets, one from the upstream direction and one from the downstream direction. If the packet is addressed to the border IAB node in the downstream direction, the border IAB node can determine that it is an access IAB node and pass the packet to the upper layer.

[0086] (Problem 4) is, for example, a problem regarding how to rewrite the BAP header. As described above, in inter-topology routing (e.g., FIG. 9(C)), in the case of an uplink-direction packet, the destination donor DU is changed to a donor DU with a different topology. Therefore, if the BAP header can be appropriately rewritten, it becomes possible to transfer the packet to a donor DU with a different topology, and it becomes possible to appropriately perform inter-topology routing.

[0087] In response to the above four issues, the following two examples (proposals) have been proposed in 3GPP.

[0088] (Plan 1): Add the boundary node's BAP address, in the BAP PDU header in the first topology;

[0089] (Plan 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. This is a proposal to treat a packet including the BAP address of the border IAB node 300-1 as a target packet for inter-topology routing. If the BAP address of the border IAB node included in the header of a received packet matches its own BAP address, the IAB node itself identifies itself as the border IAB node 300-1 and treats the packet as a target packet for inter-topology routing. and It is also possible to judge.

[0091] (Proposal 2) is a proposal to include a proxy or fake BAP address in the header of the BAP packet. In this case, if the IAB node receives a BAP packet and finds that the packet contains a fake BAP address in the header, it can determine that the packet is a packet to be routed between topologies.

[0092] Regarding (Proposal 1) and (Proposal 2), the existence of such proposals has merely been indicated, and no specific procedures or processes using these proposals have been proposed to 3GPP.

[0093] Therefore, as a first operation example, an operation example regarding the entire BAP processing of inter-topology routing, taking into consideration the above four problems, will be described.

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

[0095] In this way, in the first operation example, it is determined whether to perform inter-topology routing or intra-topology routing based on the header information of the received packet. Therefore, in the first operation example, it is possible to appropriately determine whether to perform inter-topology routing or intra-topology routing, and it is possible to provide a solution to, for example, (Problem 1) and (Problem 2).

[0096] In the first operation example, when the transmitting unit determines that intra-topology routing is to be performed, the transmitting unit selects a first routing table for intra-topology routing and a first mapping table for intra-topology routing. On the other hand, when the transmitting unit determines that inter-topology routing is to be performed, the transmitting unit selects a second routing table for inter-topology routing and a second mapping table for inter-topology routing.

[0097] As a result, in the first operation example, it is possible to appropriately select a routing table and a mapping table for inter-topology routing. In the transmitting unit, by performing routing processing and mapping processing using these tables, it is possible to appropriately perform inter-topology routing, and it is possible to provide a solution to, for example, (Problem 1) and (Problem 2).

[0098] Furthermore, in the first operation example, when the transmitting unit selects the second routing table and the second mapping table, a header rewrite 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 rewrite table.

[0099] As a result, in the first operation example, the destination BAP address can be appropriately rewritten to appropriately perform inter-topology routing, thereby providing a solution to, for example, (problem 4).

[0100] The first operation example will now be described in detail.

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

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

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

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

[0105] In step S13, the receiving unit of the BAP layer of the IAB node 300 identifies the received packets as downstream or upstream packets addressed to itself. Then, the receiving unit outputs the packets 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 receiver identifies packets addressed to itself, for example, in the following manner.

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

[0108] Secondly, when the candidate packet is (Plan 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. The predetermined path ID is set by, for example, the donor node 200. When the candidate packet is (Plan 1), the receiving unit may identify that the packet is addressed to itself by 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, if the candidate packet is (Plan 2), the receiving unit identifies the candidate packet as a packet addressed to itself. In other words, since it can be confirmed that the destination of the candidate packet matches its own BAP address and is not a fake 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 the case of (Plan 2).

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

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

[0112] In step S14, the transmitting unit selects a routing mode for the packet received from the receiving unit, which can be either intra-topology routing or inter-topology routing.

[0113] The determination method is, for example, as follows: That is, the transmitting unit determines that the packet is an inter-topology routing target packet (inter-topology routing mode) if at least any of the following is true for the header information of the packet, and otherwise determines that the packet is an intra-topology routing mode (intra-topology routing mode).

[0114] M1: If it matches a specific routing ID that indicates inter-topology routing, or M2: If it matches a specific path ID that indicates inter-topology routing, or M3: If it matches a specific BAP address that indicates inter-topology routing (e.g., proposal (2)), or M4: If the identifier indicating whether or not the transfer is between topologies indicates a transfer between topologies (e.g., “1”), or M5: If the destination BAP address of the BAP packet matches a BAP address associated with a different topology than the identified 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 intra-topology routing), the receiving unit may determine the routing mode using the above M1 to M5.

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

[0116] The transmitting unit may store the packet in a different buffer depending on the determination result. For example, when the transmitting unit determines that the packet is a packet to be routed between topologies, the transmitting unit stores the packet in a buffer for inter-topology routing. Also, for example, when the transmitting unit determines that the packet is a packet to be routed within a topology, the transmitting unit stores the packet in a buffer for intra-topology routing.

[0117] In step S15, the sender selects a routing table and a mapping table. The sender may select as a default the first routing table for intra-topology routing.

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

[0119] On the other hand, when the transmitting unit determines that the packet is a packet to be routed between topologies and the second routing table is not set, the transmitting unit selects the first routing table for intra-topology routing, assuming that the IAB node 300 is not the boundary IAB node 300-1. That is, the transmitting unit determines that the packet is a packet to be routed between topologies because the packet matches a specific routing ID, but the second routing table is not set in the IAB node 300. For example, this is the case of IAB nodes (IAB nodes 300-2 and 300-3) located midway between the donor DU and the boundary IAB node 300-1. Although such an IAB node recognizes that the packet is a packet to be routed between topologies, it does not execute inter-topology routing for the packet because the second routing table is not set. In this case, the transmitting unit selects the first routing table.

[0120] Similarly, if the second mapping table is not set, the transmitter selects the first mapping table.

[0121] On the other hand, if the transmitting unit determines in step S15 that the packet is a packet to be routed within the topology, the transmitting unit selects the first routing table, and further selects the second mapping table.

[0122] The transmitting unit may store the packet in a different buffer for each routing table. When the transmitting unit selects the first routing table, the transmitting unit stores the packet in the buffer for the first routing table. When the transmitting unit selects the second routing table, the transmitting unit stores the packet in the buffer for the second routing table.

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

[0124] The transmitting unit performs the BAP header rewriting process by using the header rewriting table. The BAP header rewriting table contains entries including an old routing ID (the previous routing ID) and a new routing ID (a new routing ID). Specifically, if 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 transmitting unit rewrites the routing ID included in the header of the packet to the new routing ID of the entry.

[0125] In addition, 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 transmitting unit may determine that the packet is not a packet to be routed between topologies. In this case, the transmitting unit does not perform the BAP header rewrite process. Alternatively, in this case, the transmitting unit may perform a process such as a rerouting process. That is, if 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 transmitting 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 transmitting unit performs routing and mapping processes on the packet.

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

[0128] Here, the first routing table is used in the case of intra-topology routing. That is, in the case of intra-topology routing, the first routing table is used to perform routing processing for both downlink and uplink packets.

[0129] On the other hand, the case where the second routing table is used is the case of 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 routes a packet addressed to donor DU#1 (200D1) to donor DU#2 (200D2). 2 Routing processing is performed so that the packets are directed to (200D2).

[0130] Second, the transmitter performs a mapping process using the mapping table (the first mapping table or the second mapping table) selected in step S15. Specifically, if an entry that matches the ingress backhaul RLC channel (ingress BH RLC channel) of the packet, the ingress backhaul link (ingress BH link) of the packet, and the outgoing backhaul link selected in the mapping process exists in the selected mapping table, the transmitter selects the outgoing backhaul RLC channel (egress BH RLC channel) of the entry.

[0131] The transmitter outputs the packet to a selected outgoing backhaul RLC channel of the selected outgoing 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 (border IAB node 300-1) transmits the packet to, for example, the donor DU #2 (200D2) by inter-topology routing. Alternatively, the IAB node 300 transmits the packet to, for example, the donor DU #1 (200D1) by intra-topology routing.

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

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

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

[0136] (Modification of the first operation example)

[0137] (Variation 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 executed.

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

[0139] Therefore, at least a part of the first operation example may be applied to a scenario 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 / inter-donor-DU rerouting" (S1-2), the operation may be performed by replacing "intra-topology or inter-topology" in the first operation example with "normal routing or inter-donor-DU rerouting," etc.

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

[0141] For example, in FIG. 9C, the IAB node 300-1 is under the control of a donor CU#1 (200C1) (hereinafter, sometimes referred to as a “first donor”). 2Assume that inter-topology routing is performed for (200C2) (hereinafter, sometimes referred to as the "second donor"). In the topology after inter-topology routing, the first donor manages the routing ID in the downstream direction, and the second donor manages the routing ID in the upstream direction. 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 the IAB node 300-1 receives a packet from a lower node after inter-topology routing and performs routing processing. In this case, the IAB node 300-1 selects an entry 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 an entry with the same routing ID from the downstream routing table. In this case, the IAB node 300-1 may forward the packet received from the lower node to the lower node again.

[0143] Therefore, in the third modification, two inter-topology routing tables, an inter-topology routing table for upstream and an inter-topology routing table for downstream, are set in the IAB node 300-1 as inter-topology routing tables. Also, as intra-topology routing tables, an intra-topology routing table for upstream and an intra-topology routing table for downstream are set in the IAB node 300-1 as intra-topology routing tables.

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

[0145] As a result, even if the same routing ID is used between topologies, the IAB node 300-1 can properly forward packets.

[0146] (Variation 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] The fourth modification 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 illustrating an example of an operation according to the fourth modification of the first embodiment.

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

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

[0151] That is, when the transmitting unit of the BAP layer of the IAB node 300-1 receives a BAP packet (BAP PDU) from the receiving unit of the BAP layer of the IAB node 300-1, the transmitting unit performs a BAP header rewriting process in step S33. 。 First, the transmitting unit determines whether or not an entry including an old routing ID that matches the routing ID included in the header of the packet exists in the header rewrite table.

[0152] If the entry exists in the header rewrite table, the transmitting 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 rewrite table, the transmitting unit does not rewrite the BAP header. In this case, the transmitting unit may determine that the packet was not subject to inter-topology routing. Or, in this case, the transmitting unit may perform a rerouting-like process. That is, if an entry including a BAP address of an old routing ID that matches the destination in the header of the packet exists in the header rewrite table, the transmitting unit rewrites the routing ID of the BAP header to the new routing ID included in the entry.

[0153] Secondly, when the transmitting unit rewrites the BAP header, the transmitting unit may store the packet in a buffer for packets whose BAP header has been rewritten. On the other hand, when the transmitting unit does not rewrite the BAP header, the transmitting unit may store the packet in a buffer for packets whose BAP header has not been rewritten.

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

[0155] After that, in step S32, the transmitting unit selects a routing table / mapping table. The transmitting unit performs the following process, for example. That is, the transmitting unit may select a second routing table and a second mapping table associated with the new routing ID selected when rewriting the BAP header. 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.

[0156] After that, in step S34, the transmitting unit performs routing processing and mapping processing. These two processes are similar to those in the first operation example.

[0157] In the first operation example, an example of using two routing tables (and two mapping tables) to be applied to the intra-topology scenario and the inter-topology scenario has been described, but the present invention is not limited to this. One routing table (and one mapping table) to be used in both the intra-topology scenario and the inter-topology scenario may be defined. In this case, each entry in the table may include information indicating whether it is an entry to be applied to the intra-topology scenario or the inter-topology scenario. The information may be information indicating whether it is applied to a packet in which the BAP header has been rewritten or to a packet in which the BAP header has not been rewritten. Alternatively, the information may be an identifier indicating the topology (or the donor that manages the topology) to which the packet is to be sent. Alternatively, the information may be information indicating whether it should be applied to an upstream packet or a downstream packet. The IAB node 300-1 sets only entries that match the specified routing mode (or scenario) as targets (candidates) for routing processing (and mapping processing).

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

[0159] The second operation example is also an operation example in which the IAB node 300-1 identifies whether or not a received packet is a packet to be routed between topologies.

[0160] As shown in FIG. 9C, the boundary IAB node 300-1 is connected to two topologies. It is assumed that each topology is managed by each donor node (donor CU#1 (200C1) and donor CU#2 (200C2)). Therefore, the BAP address of the boundary IAB node 300-1 is the same as that of the donor CU#1 (200C1) and donor CU#2 (200C2). 1 (200C1) and the BAP address managed by donor CU#2 (200C 2 ) is managed by the BAP address. In principle, the BAP address must be unique within the topology.

[0161] As shown in the above (Proposal 2), a proposal has been proposed to assign a false BAP address (proxy / pseudo BAP Address) to the border IAB node 300-1 as a method for identifying packets to be routed between topologies. In this case, the border IAB node 300-1 may be assigned two false BAP addresses, one assigned by donor CU#1 (200C1) and the other assigned by donor CU#2 (200C2). Furthermore, as described above, the border IAB node 300-1 is assigned two own BAP addresses by these two donors as its own BAP address.

[0162] Thus, the border IAB node 300-1 may be assigned four BAP addresses, and using these four BAP addresses to identify packets to be routed between topologies may be a complex process.

[0163] The BAP layer may also determine from which topology the packet has come in in order to select a BAP address.

[0164] Therefore, in the second operation example, the IAB node 300-1 identifies the topology of the incoming packet, identifies the BAP address associated with the topology as its own BAP address, and performs BAP receiving processing and BAP transmitting processing using the identified BAP address, as in the first operation example.

[0165] That is, first, a relay node (e.g., IAB node 300-1) is set with a BAP address of the relay node in each topology from a donor node (e.g., donor node 200). Second, the relay node is set with binding information binding a topology with an incoming backhaul link and / or binding information binding a topology with an incoming backhaul RLC channel from the donor node. Third, the BAP layer of the relay node receives a packet. Fourth, the BAP layer identifies a 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 border relay node (e.g., border IAB node 300-1) located at the boundary between topologies.

[0166] This makes it possible to simplify processing compared to the case where four BAP addresses are used, since it is possible to use only two BAP addresses associated with each topology, rather than four BAP addresses, for example.

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

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

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

[0170] In step S41, the IAB node 300-1 is set with a BAP address of each topology by the donor node. The BAP address is set using F1AP or RRC.

[0171] For example, in the case of the IAB node 300-1 in Fig. 9(C), when the only F1AP connection or RRC connection is with 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. The BAP address in the topology on the donor CU #2 (200C2) side may be set by such a route.

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

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

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

[0175] In step S42, the IAB node 300-1 receives, from the donor node, binding information between the topology and the ingress backhaul link (ingress BH link) (and / or the ingress backhaul RLC channel (ingress BH RLC channel)).

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

[0177] In this way, the tying information in step S42 enables the IAB node 300-1 to identify the topology to which the packet belongs, based on the source of the packet.

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

[0179] First, if the incoming backhaul link (and / or the incoming 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 (e.g., the first BAP address). The BAP address associated with each topology is set in step S41.

[0180] Second, if the incoming backhaul link (and / or the incoming backhaul RLC channel) is bound to the second topology, the BAP layer identifies the BAP address bound to the second topology as its own BAP address (e.g., the second BAP address).

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

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

[0183] First, if 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, if the destination matches its own BAP address identified in step S43 (for example, the first BAP address), the packet is a downstream packet in the first topology, and the IAB node 300-1 is the access IAB node, as in the first operation example. In such a case, the IAB node 300-1 transmits the packet to the subordinate UE 100, so the BAP layer outputs the packet to the upper layer.

[0184] Secondly, if the destination does not match the BAP address of the BAP layer specified in step S43, the BAP layer determines that the packet is to be routed. The receiving unit of the BAP layer outputs the packet determined to be routed to the transmitting unit of the BAP layer.

[0185] The BAP layer performs the following processes on packets to be routed.

[0186] First, the BAP layer may determine that the packet is a packet to be routed between topologies when the destination of the packet matches the BAP address (or the BAP address for inter-topology routing) associated with the second topology identified in step S43. That is, the BAP layer determines that the packet is a packet to be routed between topologies when the destination BAP address of the packet matches the BAP address (e.g., the second BAP address) associated with a topology (e.g., the second topology) different from the identified BAP address (e.g., the first BAP address). After the determination, the BAP layer may perform a BAP header rewrite process on the packet in the same manner as in the first operation example. Alternatively, when step S44 is performed in the receiving unit of the BAP layer, the receiving unit may output the packet to the transmitting unit of the BAP layer as a packet to be routed between topologies (or by adding information that the packet is a target).

[0187] Secondly, if the destination does not match the BAP address (or the BAP address for inter-topology routing) associated with the second topology identified in step S43, the BAP layer may determine that the packet is to be routed within the topology. The BAP layer does not perform a BAP header rewrite process on the packet. Alternatively, if step S44 is performed in the receiving section of the BAP layer, the receiving section may output the packet to the transmitting section of the BAP layer as a packet to be routed within the topology (or by adding information indicating that the packet is to be routed).

[0188] 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 the target of inter-topology routing using the second routing table and the second mapping table. Also, the BAP layer may perform routing processing and mapping processing on the packet determined to be the target of inter-topology routing using the first routing table and the first mapping table.

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

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

[0191] In 3GPP, it is proposed to include in the header of a BAP packet an identifier indicating whether or not the packet is a BAP packet to be routed between topologies.

[0192] For example, in FIG. 9(C), when the border IAB node 300-1 receives the packet from a lower node, it can identify that the packet is a packet to be routed between topologies based on the identifier contained in the header of the packet.

[0193] On the other hand, the IAB node 300-3 that received the packet may determine that the packet is a packet to be routed between topologies based on the identifier, which may result in an erroneous operation of the IAB node 300-3.

[0194] 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 to be routed between topologies.

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

[0196] As a result, the IAB node 300-3 that receives a packet that has been routed between topologies will not further route the packet between topologies, making it possible to prevent erroneous operation.

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

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

[0199] In step S50, the border IAB node 300-1 starts the process.

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

[0201] In step S52, the BAP layer of the border IAB node 300-1 checks the identifier included in the header of the packet. If the identifier is "1" indicating that inter-topology routing is to be performed, the BAP layer determines that the received packet is a packet to be routed between topologies. If the identifier is "0", the BAP layer determines that the packet is not a packet to be routed between topologies. In the following, the explanation will be continued assuming that the packet is a packet to be routed between topologies.

[0202] In step S53, the BAP layer performs a BAP header rewrite process on the packet. As in the first operation example, if an entry including an old routing ID that matches the routing ID included in the header of the packet exists in the header rewrite 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 a value of "1" indicating that inter-topology routing is performed to a value of "0" indicating that inter-topology routing is not performed. Alternatively, the BAP layer writes "0" in the area of ​​the BAP header including the identifier.

[0203] In step S54, the BAP layer performs the routing process and the mapping process in the same manner as in the first operation example, and outputs the packet to the lower layer.

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

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

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

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

[0208] However, the BAP layer may not be able to identify which routing table is the primary routing table or which is the secondary routing table.

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

[0210] Specifically, the first routing table and the second routing table include first identification information that identifies the first routing table and the second routing table, and the first mapping table and the second mapping table include second identification information that identifies the first mapping table and the second mapping table.

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

[0212] It is also possible to identify that the packet is a packet to be routed between topologies based on the direction of the packet. For example, in FIG. 9(C), since no negotiation is 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, if the IAB node 300-2 can confirm that the direction of the received packet is the upstream direction, it can know that the packet is a packet to be routed between topologies, and can use the second routing table and the second mapping table to be used in the upstream direction based on the identifier.

[0213] Therefore, the following five identifiers are subject to discrimination.

[0214] T1: Routing ID T2: Password ID T3:BAP address T4: The identifier indicating whether the transfer is between topologies is a flag value indicating transfer between topologies (for example, "1") T5: Upstream or downstream For example, in the IAB node 300-1, with regard to the routing ID, if the table contains a specific routing ID indicating inter-topology routing, the table can be determined to be the second routing table.

[0215] On the other hand, for example, in IAB node 300-1, if the table does not contain a specific routing ID indicating inter-topology routing (or if the table contains a routing ID indicating intra-topology routing), the table can be determined to be the first routing table.

[0216] The same applies to T2 to T4.

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

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

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

[0220] In step S61, the donor node notifies the IAB node 300-1 of the topology Inside The first routing table for routing and the topology between and a second routing table for routing.

[0221] The two tables each include an identifier that identifies the first routing table and the second routing table.

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

[0223] 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, if the information included in the header matches a specific identifier indicating inter-topology routing, the BAP layer determines the routing table including the identifier as the second routing table. On the other hand, if the information included in the header does not correspond to the specific identifier indicating inter-topology routing (or corresponds to the specific identifier indicating intra-topology routing), the BAP layer determines the routing table not including the identifier as the first routing table. The BAP layer performs routing processing using the determined routing table.

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

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

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

[0227] In the above-mentioned fourth operation example, an example has been described in which a table to be applied is specified based on the packet direction.

[0228] However, 3GPP has not discussed how to identify the direction of a packet.

[0229] In the fifth operation example, an operation example will be described in which the direction of a received packet is specified, that is, whether the received packet is in the downstream direction or the upstream direction.

[0230] Specifically, first, a receiver (e.g., a receiver of a BAP layer) identifies whether the direction of a received BAP packet is downstream or upstream. Second, when a first routing table and a second routing table exist for each direction of the BAP packet, a transmitter selects the first routing table or the second routing table corresponding to the identified direction.

[0231] As a result, for example, the IAB node 300-1 can appropriately forward the received packet using the routing table corresponding to the identified direction.

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

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

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

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

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

[0237] In step S73, the BAP layer performs a predetermined process using the identified packet direction. The predetermined process is one of the following processes.

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

[0239] Secondly, when a routing table does not exist for each packet direction and the packet direction is specified in an entry in the routing table, the BAP layer performs routing processing using the entry corresponding to the specified direction. For example, assume that a first routing table and a second routing table exist, and the packet direction is specified in an entry in the first routing table and the packet direction is specified in an entry in the second routing table. In this case, the BAP layer performs routing processing using an entry in the first routing table or the second routing table that corresponds to the specified direction (upstream direction or downstream direction).

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

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

[0242] (Modification of the fifth operation example) In the fifth operation example, an example of performing routing processing has been described. The fifth operation example may also be applied to mapping processing.

[0243] That is, the BAP layer identifies the direction of the received packet in the same manner as in the fifth operation example. If 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. If there is no mapping table for each packet and the packet direction is specified in an entry in the mapping table, the BAP layer performs mapping processing using an entry in the first mapping table or the second mapping table corresponding to the direction.

[0244] (Sixth operation example) In the third operation example, the identifier indicating that it is a target for inter-topology routing has been described.

[0245] In the sixth operation example, it will be described how a donor DU or an access IAB node writes the identifier into the packet's header.

[0246] Specifically, first, the CU of the donor node (e.g., donor 200) configures the DU or access IAB node of the donor node as to whether or not to write to an identifier indicating inter-topology routing in association with a routing ID. Second, the DU or access IAB node of the donor node transmits a BAP packet to which a BAP header including a routing ID and an identifier is added to the next hop node according to the configuration.

[0247] This allows, for example, the DU of the donor node 200 and the access IAB node to properly write the identifier in the BAP header.

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

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

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

[0251] First, the setting to the access IAB node is set using F1AP. That is, the donor node 200 sets the setting by sending "Uplink Traffic to Routing ID Mapping Configuration" to the access IAB node. The mapping setting includes the following IE:

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

[0253] Secondly, the setting for the DU of the donor node 200 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.

[0254] D1: Destination IP Address D2: IPv6 flow label (IPv6 flow label) D3:DSCP(Differentiated Services Code Point) D4: Routing ID D5: Information on whether to write an identifier indicating inter-topology routing The mapping setting also includes D5, as in the setting for the access IAB node. Like U3, D5 may be such that if the IE is included in the mapping setting, the identifier is written in the BAP header (or writing is specified), and if the IE is not included in the mapping setting, the identifier is not written in the BAP header (or writing is not specified). If the information is "1", the identifier is written in the BAP header, and if the information is "0", the identifier is not written in the BAP header. "1" and "0" may be reversed. The information may be indicated by "True" or "False". Also, the information may be indicated by "Yes" or "No".

[0255] In the following, an example of operation in the access IAB node will be described.

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

[0257] First, the BAP layer selects an entry that includes a traffic specifier corresponding to the packet from the mapping configuration ("Uplink Traffic to Routing ID Mapping Configuration").

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

[0259] And thirdly, if writing to an identifier indicating inter-topology routing is specified in the selected entry, the BAP layer sets the identifier in the BAP header to "1." On the other hand, if writing to the identifier is not specified in the selected entry, the BAP layer sets the identifier to "0."

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

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

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

[0263] Here, in regard to steps S82 and S83, if the DU of the donor node 200 performs the processing, the “access IAB node” in steps S82 and S83 should be replaced with the “DU of the donor node 200”, and the mapping setting should be “Downlink Traffic to Routing ID Mapping Configuration”.

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

[0265] [Second embodiment] Next, a second embodiment will be described.

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

[0267] In 3GPP, it is agreed to support inter-topology rerouting, where an IAB node reroutes a packet to a 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.

[0268] Regarding inter-topology rerouting, it is agreed in 3GPP that when an IAB node performs recovery from a BH RLF via RRC Reestablishment with a new donor CU, it may maintain an ongoing F1 connection with the original donor node and rerouting may occur via the restored path.

[0269] That is, inter-topology rerouting at an IAB node may be applied in a state of RRC re-establishment to a target donor node while keeping F1 connectivity with the source donor node. In other words, inter-topology rerouting may be applied at an IAB node in a transient state where F1 connectivity with a target donor node is not established, not in a state of dual connectivity (DC) with two donor nodes.

[0270] In such a transient state, even if an IAB node performs inter-topology rerouting using the Rel-16 local rerouting procedure, it may not be able to perform the rerouting.

[0271] That is, in the Rel-16 local rerouting 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.

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

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

[0274] Even if the IAB node can forward the packet to the target donor node, the target donor node may not know whether the packet is intended for itself or the source donor node.

[0275] Therefore, in the second embodiment, the target donor node sets a communication path for inter-topology rerouting to the IAB node, and the IAB node 300 forwards the packet via that communication path.

[0276] Specifically, first, a relay node (e.g., IAB node 300) detects a backhaul radio link failure in a connection with a first donor node (e.g., source donor node) or a connection with a first upper node. Second, the relay node notifies a second donor node (e.g., target donor node) or a second upper node of information indicating that communication with the first donor node will be continued when RRC re-establishment is performed. 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.

[0277] As a result, for example, the target donor node can know that communication between the IAB node and the source donor node continues, and can use this notification as a trigger to set up a communication path for inter-topology rerouting to the IAB node. Even in the above-mentioned transient state, the IAB node can appropriately forward received packets using the communication path.

[0278] 19(A) and 19(B) are diagrams illustrating an example of a topology configuration according to the second embodiment.

[0279] FIG. 19(A) shows an example in which a BH RLF occurs in a backhaul link between the IAB node 300 and donor node A (200-A). FIG. 19(B) shows an example in which a BH RLF occurs in a backhaul link between the IAB node 300 and upper node 300-P1. In FIG. 19(B), the IAB node 300-P1 is a node managed by the donor node A (200-A). The IAB node 300-P2 is a node managed by the donor node B (200-B).

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

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

[0282] In step S91, a BH RLF occurs in a 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 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 IAB node 300-P1.

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

[0284] In step S93, the IAB node 300 executes an RRC reestablishment procedure with the donor node B (200-B). For example, the following procedure is executed.

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

[0286] At this time, the IAB node 300 may notify the donor node B (200-B) of information (or a request) indicating that communication with the donor node A (200-A) is to be continued in the message. Alternatively, the IAB node 300 may notify the donor node B (200-B) of information indicating that the IAB node 300 has the capability of inter-topology rerouting 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. Alternatively, the IAB node 300 may notify the donor node B (200-B) of a request to establish a communication path with the donor node A (200-A) in the message.

[0287] This notification may be sent after the RRC reestablishment completion or after the UE assistance information. c This may be done in each message of the Interference Information.

[0288] Second, the donor node B (200-B) accepts the RRC re-establishment request and sends an RRC Reestablishment message to the IAB node 300.

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

[0290] As a result of the above, an RRC connection is established between the IAB node 300 and the donor node B (200-B).

[0291] In step S94, the donor node B (200-B) establishes a communication path (GTP (General Packet Radio System (GPRS) Tunnelling Protocol)) between the donor node B (200-A). This is because the donor node B (200-B) uses this communication path to transmit 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) between the donor node B (200-B). This is because the donor node A (200-A) transmits downstream packets to the donor node B (200-B).

[0292] For example, the donor node B (200-B) transmits 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) transmits an acknowledgment message to the donor node B (200-B). This may establish the communication path. The request message may include an identifier of the IAB node 300, a GTP Tunnel Endpoint Identifier (TEID) for receiving downstream packets, and an IP address. The acknowledgment message may include a GTP TEID for receiving upstream packets and an IP address.

[0293] In addition, the establishment of the GTP communication path may be performed before the donor node B (200-B) transmits an RRC reestablishment message to the IAB node 300.

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

[0295] The donor node B (200-B) uses the RRC connection established in step S93 to set up a communication path to the IAB node 300. Specifically, the CU of the donor node B (200-B) sets up a communication path by transmitting an RRC reconfiguration 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 rerouting.

[0296] First, the configuration may include a (temporary) routing table for inter-topology rerouting, which may include a routing ID and a next hop BAP address.

[0297] Second, the configuration may include a (temporary) mapping table for inter-topology rerouting, which may include an ingress backhaul RLC channel, an egress backhaul RLC channel, an ingress backhaul link, and an egress backhaul link.

[0298] Thirdly, the setting may include a BAP address of the IAB node 300. The BAP address is a BAP address for the IAB node 300 managed by the donor node B (200-B).

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

[0300] Fifth, the setting may include a BAP header rewrite table.

[0301] Upon receiving the configuration, the RRC layer of the IAB node 300 outputs the configuration to the BAP layer of the IAB node 300. The BAP layer may treat the configuration as a routing table and / or a mapping table.

[0302] In step S96, the BAP layer of the IAB node 300 performs inter-topology rerouting processing in accordance with the setting. For example, the BAP layer of the IAB node performs the following processing.

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

[0304] Second, the BAP layer identifies a next hop BAP address (or an outflow 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 a 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 an outflow backhaul link corresponding to the next hop BAP address of the entry.

[0305] Third, the BAP layer identifies an outgoing backhaul RLC channel from the configuration. In this case, the BAP layer may use a mapping table for inter-topology rerouting according to the configuration. For example, the BAP layer may read an entry that matches the incoming backhaul RLC channel, incoming backhaul, and identified outgoing backhaul link of the packet, and identify the outgoing backhaul RLC channel included in the entry.

[0306] Fourth, the BAP layer outputs the queued packet to the identified outgoing backhaul RLC channel of the identified outgoing backhaul link.

[0307] The above-mentioned outgoing backhaul link and outgoing backhaul RLC channel may be specified, for example, as follows. That is, when there is no entry in the routing table that matches the routing ID included in the header of a packet waiting to be transmitted that is retained in the IAB node 300 and there is no entry in the routing table that matches the destination included in the header of the packet, the BAP layer selects the backhaul RLC channel set in the setting as the transmission destination and transmits the retained packet via the selected backhaul RLC channel. That is, in such a case, the BAP layer transmits the retained packet to a communication path for inter-topology rerouting.

[0308] In addition, the BAP layer of the IAB node 300 may receive downlink packets transmitted by donor node A (200-A) via donor node B (200-B) from the incoming backhaul link and the incoming backhaul RLC channel in accordance with the setting.

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

[0310] For example, the donor node A (200-A) transmits to the donor node B (200-B) a request to discard communication for inter-topology rerouting between the donor node B (200-B) and the IAB node 300. The donor node B (200-B) can then simultaneously notify the donor node A (200-A) and discard the communication by returning an acknowledgment to the discard request. Alternatively, the F1 layer of the IAB node can implicitly notify the donor node B (200-B) that the F1 connection has been released by transmitting an F1 setup request to the donor node B (200-B).

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

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

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

[0314] (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 set up a communication path for inter-topology rerouting to the IAB node 300.

[0315] In the modified example of the second embodiment, the communication path is set up using F1 instead of RRC. Specifically, first, a relay node (for example, IAB node 300) detects a BH RLF in a connection with a first donor node (for example, donor node A (200-A)) or a connection with a first upper node (for example, IAB node 300-P1). Second, the relay node notifies a second donor node (for example, donor node B (200-B)) or a second upper node (for example, IAB node 300-P2) of information indicating that communication with the first donor node will be continued when F1 setup is performed. 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.

[0316] As a result, for example, the target donor node can know that communication between the IAB node and the source donor node is continuing, and this notification can be used as a trigger to set up a communication path for inter-topology rerouting to the IAB node using an F1AP message. Then, by setting up this communication path, the IAB node can appropriately perform inter-topology rerouting.

[0317] FIG. 21 is a diagram illustrating a modified example according to the second embodiment.

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

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

[0320] In step S103, the IAB node 300 performs 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). After that, the IAB node 300 performs an F1 setup procedure to establish an F1 connection with the donor node B (200-B).

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

[0322] First, the IAB node 300 transmits an F1 Setup Request message to the donor node B (200-B). At this time, the IAB node 300 notifies, in the message, information indicating that communication with the donor node A (200-A) will be continued, as in the second embodiment. Alternatively, the IAB node 300 may notify, in the message, information indicating that it has the capability of inter-topology rerouting, or information indicating that the F1 connection with the donor node A (200-A) remains, as in the second embodiment. Note that the notification may be performed in a later F1 Setup Response message or a further later UE assistance information message.

[0323] Second, the donor node B (200-B) accepts the request and sends an F1 setup response message to the IAB node 300.

[0324] This establishes an F1 connection between the IAB node 300 and the donor node B (200-B).

[0325] Step S104 is the same as step S94 in the second embodiment.

[0326] In step S105, the donor node B (200-B) configures a (temporary) communication path for inter-topology rerouting for the IAB node 300. The configuration is performed using an F1 configuration update message. The configuration content is the same as that of the second embodiment. The configuration includes a (temporary) backhaul RLC channel for inter-topology rerouting, as in the second embodiment. Upon receiving the configuration, the F1AP layer of the IAB node 300 outputs the configuration to the BAP layer of the IAB node 300. The BAP layer may handle the configuration as a routing table and / or a mapping table, as in the second embodiment.

[0327] This setting may be performed using an F1 setup response message.

[0328] In step S106, the BAP layer of the IAB node 300 performs inter-topology rerouting processing in accordance with the setting. The inter-topology rerouting processing itself is the same as that in the second embodiment.

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

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

[0331] The second embodiment relating to the inter-topology rerouting scenario (S3-2) has been described above. Next, the donor inter-DU rerouting scenario (S2-2) will be described.

[0332] [Third embodiment] Next, a third embodiment will be described.

[0333] In the third embodiment, rerouting between donor DUs will be described.

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

[0335] Here, for downstream packets, the source (DU of the donor node) is not involved in the routing process in the IAB node 300-1. Also, for downstream packets, the destination (access IAB node) does not change even if routing process is performed. Therefore, it is expected that there will be no particular problem with downstream donor DU rerouting.

[0336] On the other hand, when rerouting between donor DUs is performed in the upstream direction, the destination (DU of the donor node) changes. In other words, the destination BAP address changes for each packet. For this reason, the IAB node 300-1 may perform a BAP header rewriting process. In 3GPP, "'previous routing ID to new routing ID' BAP rewriting" has been agreed upon as a BAP header rewriting process.

[0337] Here, there are two challenges in this scenario.

[0338] First, rerouting differs from routing in that it basically performs routing once and then performs routing again for packets with no destination. Therefore, it is necessary to consider the timing of rewriting the BAP header.

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

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

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

[0342] 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 outflow backhaul link cannot be selected. Third, the relay node determines that the packet for which the check has been performed is a packet to be subject to donor DU inter-routing. Fourth, the relay node performs a routing process again on the packet determined to be a packet to be subject to donor DU inter-routing.

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

[0344] Then, the relay node executes a BAP header rewriting process for rewriting the destination of the packet on the packet 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.

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

[0346] 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).

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

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

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

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

[0351] In step S112, the transmitting unit of the BAP layer of the IAB node 300-1 receives a packet from the receiving unit of the BAP layer of the IAB node 300-1. Here, the receiving unit of the BAP layer may output a packet addressed to itself in the downstream direction to a higher layer, as in the first embodiment. For example, this is because the receiving unit itself is an access IAB node and does not need to perform routing processing. Therefore, the transmitting unit receives packets other than the packet addressed to itself from the receiving unit.

[0352] In step S113, the transmitting unit performs a routing process on the packet. In the routing process, for example, the following process is performed.

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

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

[0355] That is, the transmitting unit checks the above two points and confirms that the next hop BAP address cannot be selected.

[0356] If the next hop BAP address is available, the transmitter determines that the corresponding outgoing backhaul link is not available, i.e., the transmitter determines that the outgoing backhaul link is not selectable.

[0357] Third, the transmitter may determine that the outgoing backhaul RLC channel cannot be selected in the mapping process, i.e., the transmitter may determine that there is no entry in the mapping table that matches the incoming backhaul RLC channel and incoming backhaul link of the packet and the outgoing backhaul link selected in the routing process.

[0358] Fourth, the transmitting unit checks the BAP header of the packet, and confirms that the destination is the BAP address of the DU of the donor node 200 (for example, donor node DU #1 (200D1)). The BAP address of the DU of the donor node is set for the IAB node 300-1 by the donor node 200 in step S111, for example. Therefore, the transmitting unit can check by comparing this BAP address with the destination of the packet. Note that this check makes it possible to prevent the BAP header from being rewritten in the downstream direction, and to rewrite the header of the packet in the upstream direction.

[0359] Fifth, when the transmitting unit confirms that the packet is addressed to a DU of the donor node 200, the transmitting unit may mark the packet as a packet to be subjected to donor-DU rerouting (or in the upstream direction). Instead of marking, the transmitting unit may store the packet in a special transmission buffer (i.e., a buffer for donor-DU rerouting).

[0360] If the packet is a packet to be rerouted between donor DUs (or in the upstream direction) and the header rewrite table is set, the transmitting unit moves to the next header rewrite process.

[0361] In step S114, the transmitting unit performs a header rewriting process on the packet. The header rewriting process is similar to step S16 (FIG. 10) of the first operation example in the first embodiment.

[0362] In step S115, the transmitting unit performs routing and mapping again on the packet for which the header rewriting process has been completed. The transmitting unit selects an outgoing backhaul link and an outgoing backhaul RLC channel through these two processes.

[0363] In step S116, the transmitter outputs the packet to the selected outgoing backhaul RLC channel of the selected outgoing backhaul link, and the IAB node 300-1 transmits the packet to the selected next hop node.

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

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

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

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

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

[0369] (Modification 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 donor-DU rerouting.

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

[0371] The following is written in 5.2.1.1 "General" of 3GPP TS38.340 V16.5.0 (2016-06). "NOTE: Data buffering on the transmitting part of the BAP entity, eg, until RLC-AM entity has received an acknowledgment, 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 indicated by the underlined portion, rerouting in 3GPP is performed on packets that have already been transmitted and for which the Ack has not been confirmed in a lower layer.

[0372] Therefore, in the second operation example, an operation example in which inter-donor DU rerouting is performed on a transmitted packet will be described.

[0373] Specifically, first, after a relay node (for example, the IAB node 300-1) transmits a packet, it stores a duplicate (or copy) of the packet in a buffer. Second, the relay node selects a packet to be rerouted between donor DUs from the packets stored in the buffer. Third, the relay node performs a BAP header rewrite process for rewriting the destination of the selected packet. Fourth, the relay node performs a BAP header rewrite process for the selected packet. header The rewritten packet is subjected to routing processing again.

[0374] As a result, for example, the IAB node 300-1 can select packets that are targets for donor-DU rerouting from among packets retained in the buffer, and can appropriately perform donor-DU rerouting.

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

[0376] As shown in FIG. 24, in step S130, the IAB node 300-1 starts the process.

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

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

[0379] First, the IAB node 300-1 determines to perform the rerouting when it detects a BH RLF. The IAB node 300-1 may identify an outgoing backhaul link that detects the BH RLF. Alternatively, the IAB node 300-1 may identify at least one of a routing ID, a next hop BAP address, and an outgoing backhaul RLC channel that are affected by the outgoing backhaul link. The IAB node 300-1 selects a packet associated with the identified outgoing backhaul link (or at least one of a routing ID, a next hop BAP address, and an outgoing backhaul RLC channel) from the buffer. The packet may be a packet to be rerouted.

[0380] Secondly, the IAB node 300-1 determines to execute the rerouting when it receives a Type 2 BH RLC Indication. The Type 2 BH RLC Indication is an indication indicating that recovery from a BH RLF is being performed. The IAB-DU of the IAB node 300-P1, which is an upper node of the IAB node 300-1, transmits the indication to the IAB-MT of the IAB node 300-1. The IAB node 300-1 may identify the outflow backhaul link that received the indication. Alternatively, the IAB node 300-1 may identify a routing ID and a backhaul RLC channel ID that cannot be routed (or is affected, or should be rerouted) in the indication, if these IDs are notified. Alternatively, the IAB node 300-1 may identify an affected next hop BAP address from the identified information. The IAB node 300-1 selects a packet associated with the identified outgoing backhaul link (or at least one of the routing ID, the outgoing backhaul RLC channel, and the next hop BAP address) from the buffer. The packet may be the rerouting target packet.

[0381] Thirdly, the IAB node 300-1 determines to execute the rerouting when it receives flow control feedback in the uplink direction from the upper node of the IAB node 300-1. The IAB node 300-1 that receives the flow control feedback from the upper node performs control such as reducing the amount of data transmission to the upper node, thereby making it possible to avoid congestion between IAB nodes. The IAB-MT (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 outflow backhaul link that received the feedback. Alternatively, the IAB node 300-1 may identify a routing ID or a backhaul RLC channel associated with an available buffer size that is 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 rerouting. Alternatively, the IAB node 300-1 may specify the next hop BAP address from the specified information. The IAB node 300-1 selects a packet associated with at least one of the specified routing ID, outgoing backhaul link, outgoing backhaul RLC channel, and next hop BAP address from the buffer. The packet may be the rerouting target packet.

[0382] IAB node 300-1 may similarly select packets to be rerouted if the rerouting is performed based on some other criteria.

[0383] In step S133, the IAB node 300-1 performs a BAP header rewriting process on the selected packet. The BAP header rewriting process is similar to the first operation example of the first embodiment (step S16 in FIG. 10).

[0384] In step S134, the IAB node 300-1 performs the routing process and mapping process that were performed before the packet transmission again on the packet on which the BAP header rewriting process was performed. The IAB node 300-1 transmits the processed packet to the next hop node.

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

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

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

[0388] In the first and second embodiments, an example has been described in which the BAP layer of the IAB node 300 refers to the BAP header rewrite table set by the donor node 200 to rewrite the BAP header.

[0389] On the other hand, in Rel-16, the BAP layer referred to the normal routing table and appropriately selected the routing ID of the rerouting destination from among the routing IDs that matched the destination of the BAP header. This was because Rel-16 assumed intra-CU / intra-donor-DU rerouting (S1-2), and it was assumed that the rerouting destination route was within the same topology, so no problems could arise.

[0390] We now consider the issues when a similar concept (i.e., in the absence of a BAP header rewrite table) is applied to donor inter-DU rerouting.

[0391] First, for the downstream direction, the destination is the access IAB node, which is unchanged from Rel-16, so we will not consider issues for the downstream direction.

[0392] Secondly, in the upstream direction, there are multiple DUs of the donor node (= there are multiple destination BAP addresses). However, 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, the BAP address of donor DU#1 (200D1) and the BAP address of donor DU#2 (200D2) are not included. D There should be two BAP addresses (destinations) for the BAP address of U#2 (200D2).

[0393] However, even if the routing table is referenced using only the destination included in the BAP header (e.g., donor DU #1 (200D1)), the BAP address itself is different from that of a DU of another donor node (e.g., donor DU #2 (200D2)), so it may not be possible to select the routing ID to the DU of that other donor as a candidate.

[0394] In addition, in 3GPP, it has already been agreed that for inter-donor DU rerouting, the BAP header will be rewritten from the previous routing ID to a new routing ID.

[0395] Therefore, in the third operation example, the donor node 200 sets an alternative destination (e.g., donor DU #2 (200D2)) linked to a destination (e.g., donor DU #1 (200D1)) in 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 to the BAP header, thereby rewriting the BAP header.

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

[0397] This enables the IAB node 300-1 to rewrite the BAP header when performing donor-DU rerouting without using a BAP header rewrite table.

[0398] FIG. 25 is a diagram illustrating a third operation example according to the third embodiment.

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

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

[0401] That is, the predetermined setting is a BAP address for multiple DUs of the donor node 200. Or, the predetermined setting is an alternative destination used for rerouting between donor DUs. 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 linked and set. Or, 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.

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

[0403] In step S143, the IAB node 300-1 performs normal routing processing and confirms that the next hop node cannot be selected (or transmission cannot be performed). 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.

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

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

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

[0407] 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 including a BAP address that matches an alternative destination linked to the destination of the packet (the BAP address of a DU of another donor node different from the destination).

[0408] Here, the method of determining whether the packet is in the upstream direction is as follows: if the destination included in the header of the packet matches the BAP address of the DU of the donor node 200 set in step S141, the IAB node can determine that the packet is in the upstream direction. Also, if an alternative destination that matches the destination included in the header of the packet exists in the setting in step S141, the IAB node 300-1 can determine that the packet is in the upstream direction.

[0409] If the IAB node 300-1 finds a routing ID including a BAP address of a DU of another donor node (or an alternative destination) in the routing table as a result of the search, the IAB node 300-1 selects the routing ID. Then, the IAB node 300-1 selects a next hop BAP address corresponding to the routing ID, and selects a corresponding outgoing backhaul link and 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.

[0410] 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, the IAB node 300-1 writes the routing ID into the header. This causes the BAP header to be rewritten. Here, the IAB node 300-1 may report information about the BAP header rewrite to the donor. The information may be the routing ID before the rewrite (i.e., the old routing ID or Previous Routing ID) and / or the routing ID after the rewrite (i.e., the new routing ID or New Routing ID) when the BAP header is rewritten in association with the rerouting process. The information may further include information about the time when the rerouting is performed and the number of packets that are rerouted. The information may be recorded (logged) in the internal memory of the IAB node 300-1 every time the rerouting process occurs. The report may be made every time the rerouting process is performed (i.e., immediately), or may be made in association with a request from the donor (i.e., later).

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

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

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

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

[0415] In step S150, the IAB node 300-1 performs a BAP receiving process. In this case, the IAB node 300-1 may receive not only upstream packets but also downstream packets as in the first embodiment, and output the packets to a higher-level node if the packets are addressed to the node (if the packets are downstream, the IAB node 300-1 may be an access IAB node). In this case, the IAB node 300-1 performs a BAP sending process (step S151) for packets other than those addressed to the node among the received packets.

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

[0417] Then, in step S153, the BAP layer performs the BAP header rewriting process on the packet whose BAP header is to be rewritten, using the routing ID (step S144 in FIG. 25).

[0418] On the other hand, in step S152, the BAP layer transmits upstream packets 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 downstream packets that are the subject of the BAP transmission process to the next hop node by routing and mapping processes.

[0419] (Modification of the third operation example) At least a part of the third operation example according to the third embodiment is also applicable to scenarios other than donor-DU rerouting.

[0420] [Fourth embodiment] In the first to third embodiments, the inter-topology routing (S3-1), the inter-topology rerouting (S3- 2 ), and donor-DU rerouting (S2-1).

[0421] So, the question may arise as to how to make the procedures or processes as common as possible across all scenarios.

[0422] Fig. 27 shows an example of a case where a procedure or process is common to all scenarios. Fig. 27 shows an example of the configuration of an IAB node 300 according to the fourth embodiment.

[0423] As shown in FIG. 27, the IAB node 300 includes a transmitting unit 330-T and a receiving unit 330-R.

[0424] The transmitting unit 330 -T has a BAP header rewriting determining unit 331 , a BAP header rewriting unit 332 , a routing / mapping table selecting unit 333 , a routing / rerouting processing unit 334 , and a mapping processing unit 335 .

[0425] The receiving unit 330-R includes an upper layer output determining unit 336.

[0426] The upper layer output determination unit 336 determines whether to output the received packet to the upper layer or 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, which indicates whether the packet is subject to inter-topology routing.

[0427] The BAP header rewriting determination unit 331 determines whether or not to rewrite the BAP header of the packet received from the receiving unit 330-R. For example, as described in the first embodiment, the BAP header rewriting determination unit 331 may determine a packet to be rewritten as a target for BAP header rewriting (= a packet to be routed between topologies) depending on whether or not the header of the packet matches a specific routing ID. P Packets to be rewritten are output to the BAP header rewriting unit 332, and packets not to be rewritten are output to the routing / rerouting processing unit 334.

[0428] The BAP header rewriting unit 332 rewrites the BAP header of the packet. As described in the first embodiment, the BAP header rewriting unit 332 may perform the rewriting using a BAP header rewriting table. In addition, the BAP header rewriting unit 332 may not rewrite the BAP header of a packet that has never been subjected to routing processing, and may rewrite the BAP header of a packet output from the routing / rerouting 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.

[0429] The routing / rerouting processor 334 may perform a routing process and / or a rerouting process on a packet whose BAP header has been rewritten, and may perform a routing process and / or a rerouting process on a packet whose BAP header has not been rewritten. As described in the third embodiment, the routing / rerouting processor 334 may once perform a routing process (and / or a rerouting process) and output a packet with no destination to the BAP header rewriter 332.

[0430] The mapping unit 335 performs mapping processing on the packet after the routing processing or the packet after the rerouting processing using a mapping table. The mapping unit 335 transmits the processed packet to the next hop node via the outgoing backhaul RLC channel.

[0431] As described above, the configuration example of the IAB node 300 shown in FIG. 27 is just one example.

[0432] The embodiments, operation examples, processes, or steps described in the first to fourth embodiments can be combined with each other. All or part of the first to fourth embodiments can be combined to the extent that no contradiction occurs. Such combinations may allow commonality of procedures or processes in all scenarios.

[0433] [Other embodiments] A program may be provided that causes a computer to execute each process performed by the UE 100 or the gNB 200. The program may be recorded in a computer-readable medium. Using the computer-readable medium, it is possible to install the program in the computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.

[0434] In addition, circuits that execute each process performed by UE100 or gNB200 may be integrated, and at least a part of UE100 or gNB200 may be configured as a semiconductor integrated circuit (chip set, SoC).

[0435] Although one embodiment has been described in detail above with reference to the drawings, the specific configuration is not limited to that described above, and various design changes, etc. are possible without departing from the spirit and scope of the present invention.

[0436] As used in this disclosure, the terms "based on" and "depending on" do not mean "based only on" or "depending only on," unless otherwise specified. The term "based on" means both "based only on" and "based at least in part on." Similarly, the term "depending on" means both "based only on" and "based at least in part on." Additionally, "obtain / acquire" may mean obtaining information from stored information, from information received from other nodes, or by generating information. The terms "include," "comprise," and variations thereof do not mean including only the items listed, but may include only the items listed, or may include additional items in addition to the items listed. Additionally, the term "or" as used in this disclosure is not intended to be an exclusive or. Additionally, any reference to elements using designations such as "first," "second," etc., as used in this disclosure is not intended to generally limit the quantity or order of those elements. These designations may be used herein as a convenient method of distinguishing between two or more elements. Thus, reference to a first and a second element does not imply that only two elements may be employed therein or that the first element must precede the second element in some manner. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles are intended to include the plural unless the context clearly indicates otherwise.

[0437] This application claims priority to U.S. Provisional Application No. 63 / 257,223 (filed October 19, 2021), the entire contents of which are incorporated herein by reference.

[0438] (Additional Note) introduction In RAN2#115E, the work item Enhancements to Integrated Access and Backhaul for NR (EIAB) reached the following agreements on topology adaptation enhancements:

[0439] A configured threshold of available buffer size based on flow control feedback is used to determine congestion for purposes of local rerouting.

[0440] In the case of intra-CU, at least in the scenarios of NR-DC between donor DUs, inter-donor DU recovery, and inter-donor DU mobility, inter-donor DU rerouting shall be supported.

[0441] Supports inter-CU rerouting, i.e., the IAB node reroutes data to the original donor CU via an alternative BAP path on the target CU's topology.

[0442] When rerouting between donor DUs, it supports rewriting the BAP header from "the previous routing ID to the new routing ID".

[0443] Further discuss the open issue of inter-CU routing in RAN2. 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)? How to distinguish between intra-topology routing (concatenated traffic) and inter-topology routing (non-cocatenated traffic)? How to determine whether data should be delivered to a higher layer (downstream). How to determine whether the BAP header of data should be rewritten (whether it is routed to another topology or to its own topology).

[0444] As a baseline, in inter-CU routing, 1:1 and N:1 mapping from the "previous routing ID" to the "new routing ID" for rewriting the BAP header at the border node is supported.

[0445] As a baseline, in inter-CU routing, 1:1 and N:1 bearer mapping at border nodes from "incoming BH link + incoming BH RLC ID" to "outgoing BH link + outgoing BH RLC ID" is supported.

[0446] This appendix discusses extensions to routing and rerouting for various scenarios.

[0447] Discussion In REL-17, as shown in Figure 9, routing and rerouting must cover various scenarios such as intra-CU / intra-donor DU (similar to REL-16), intra-CU / inter-donor DU and inter-CU. Although these enhancements are expected to contribute to the reliability, flexibility or low latency of packet forwarding in IAB topology, they may bring further complexity to BAP routing / rerouting operations. Therefore, it is desirable to specify procedures common to all scenarios and minimize scenario-specific procedures as much as possible. In this sense, the most complex scenario is CU Inter-routing is considered first, then CU It is necessary to consider whether the inter-routing procedure can be applied (reused) to other scenarios.

[0448] Inter-CU Routing There are four open issues agreed to on inter-CU routing, which are a good starting point for thinking about how to resolve the open issues:

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

[0450] Some example solutions are given below. Example 1: Add the BAP address of the boundary node to the BAP PDU header of the first topology. Example 2: Adding a proxy / fake BAP address for a real destination.

[0451] On the other hand, in RAN3, the following agreement is reached on topology redundancy: 1A:RAN3 assumes that a border node has only one BAP address in each topology. 1B:RAN3 assumes that in each topology, the BAP addresses of the border nodes of that topology are used only to identify packets that must be passed to upper layers.

[0452] Although both examples are workable, example 1 is considered to be more consistent with RAN3's assumptions (especially 1A). Moreover, example 1 is much simpler in terms of REL-16 routing mechanism since border nodes are considered as endpoints of the initial topology, like IAB-donor DUs and access IAB nodes. Also, example 1 has a lower risk of "misrouting" in case intermediate IAB nodes perform local rerouting. In this sense, RAN2 should agree with example 1 for further discussion.

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

[0454] Open Issue 2: How to distinguish between intra-topology routing (concatenated traffic) and inter-topology routing (non-cocatenated traffic)

[0455] If agreeing to Proposal 1, the 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, the inter-topology routing (non-cocatenated traffic (routing within a topology belonging to one IAB donor CU)) has another BAP address, i.e., 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 collocated BAP entity. Therefore, no special processing is required at the receiving part. However, it should be noted that the following Open Issue3 still exists.

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

[0457] Open Issue3: Method for determining the feasibility of data delivery to the upper layer (downstream)

[0458] 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, i.e., the BAP address of the border IAB node, in each BAP data PDU header. Therefore, the receiving part of the BAP entity of the border IAB node can distinguish them by the path field of each BAP data PDU header or a new flag (using any of the three "R" bits).

[0459] When using the path field, routing ID space is consumed according to the number of paths established between the border IAB node and the IAB donor DU / access IAB node. There is no additional overhead in the data stream since it reuses the existing fields in the BAP header.

[0460] If the new flag is used, it consumes an "R" bit, so there are only three reserved bits. There is no additional overhead, since it uses the "R" bit of the BAP header. This flag is also assumed to be useful in the sending part of the BAP entity in deciding whether to rewrite the BAP header or not.

[0461] Considering the above advantages and disadvantages, it is desirable to define a new flag with one "R" bit to determine which data should be routed. Needless to say, if this new flag is set to "0", the BAP header format is completely the same as REL-16, so the receiver of the BAP entity will send data to the upper layer according to the REL-16 behavior.

[0462] Proposal 3: For inter-CU routing, RAN2 should agree to define a new flag to distinguish between data to be routed and data to be delivered to upper layers using one “R” bit in the BAP data PDU header.

[0463] Open Issue 4: How to determine whether to rewrite the BAP header of data (whether it is routed to another topology or to your own topology)

[0464] If proposal 2 and proposal 3 are agreed upon, the sender of the BAP entity can first check the NEW flag in each BAP DATA PDU header. If the NEW flag is "0" (i.e. inter-topology routing with REL-16 BAP DATA PDU (non-cocatenated traffic or "routed to own topology"), the REL-16 routing procedure is performed. If the NEW flag is "0" (i.e. intra-topology routing (concatenated traffic or "routed to another topology")), the BAP header rewrite operation is performed before the routing procedure. Since this is not "rerouting", it makes sense that the BAP header rewrite operation is performed beforehand.

[0465] Proposal 4: RAN2 agrees to use the new flag in the BAP data PDU header in Proposal 3 to determine whether to rewrite the BAP header for inter-CU routing.

[0466] Proposal 5: For inter-CU routing, RAN2 agrees that the BAP header rewrite is performed before the routing procedure.

[0467] If proposals 3 and 5 are agreed upon, a new flag will be used at the border IAB nodes. Therefore, after the BAP header rewrite operation, it will become meaningless or may even cause unnecessary errors in the second topology. Therefore, it is safe to rewrite the flag to "0" at the border IAB nodes. This is considered easy to do during the BAP header rewrite operation.

[0468] Proposal 6: Regarding inter-CU routing, RAN2 should discuss whether the new flag in Proposal 3 should also be rewritten by the BAP header rewrite operation, i.e., reset to "0".

[0469] Other possible issues Routing Table Selection If proposal 5 is agreed, the data whose header has been rewritten according to the header rewrite configuration will proceed to the routing procedure. In this case, the routing table configured in the first topology, i.e., the BH routing configuration, is not valid because the header of the data has already been rewritten to a new routing ID as RAN2 agreed that "RAN2's priority is to support inter-topology routing by BAP header rewrite based on BAP routing ID option 4". Otherwise, there may be a risk of confusion or "mis-routing" because the BAP address of each IAB node is unique within a topology and is not unique between two topologies (i.e., two CUs) even in an inter-CU routing scenario. Therefore, the routing table configured by the second topology must be used.

[0470] Proposal 7: In an inter-CU scenario, it should be agreed that RAN2 is configured with two routing tables that are used by the border nodes to route to the first and second topologies, respectively.

[0471] If Proposal 7 is agreed upon, a routing table selection step may be required for each piece of data before the routing step. The mechanism is very simple: for a piece of 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.

[0472] Proposal 8: In inter-CU scenarios, RAN2 should discuss whether a procedure is required to select the routing table of the second topology for intra-topology routing (concatenated traffic).

[0473] BH RLC channel mapping table selection When the next hop BAP address is determined in the routing procedure, it is mapped to the outgoing BH RLC channel based on the determined incoming BH link, incoming BH RLC channel, and outgoing BH link provided in the mapping table (=BH RLC channel mapping setting). The current implementation CR of TS38.340 contains the following notes:

[0474] NOTE: Further study is needed on how to include bearer mapping at border IAB nodes (also whether the current specification already supports bearer mapping at border IAB nodes for inter-CU routing).

[0475] For inter-CU scenarios, the incoming BH links and RLC channels belong to the first topology, while the outgoing BH links are associated with the second topology. Since the BAP addresses and RLC channels are managed by the CU (i.e. per topology), new mapping tables are needed to connect the two topologies. Specifically, the structure of the mapping table of REL-16 can be reused, but it needs to be configured with a different mapping table than REL-16. Otherwise, there is a risk of "mis-mapping" if the same BAP addresses (i.e. incoming / outgoing link IDs) and / or the same BH RLC channel IDs are used in both topologies. In this case, a selection of mapping tables similar to that of proposal 8 may be required.

[0476] Proposal 9: In inter-CU scenarios, RAN2 shall agree that the border IAB nodes are configured with another mapping table (in addition to the REL-16 mapping table) and that this mapping table applies to intra-topology routing (concatenated traffic).

[0477] Proposal 10: In inter-CU scenarios, we discuss in RAN2 whether the procedure of selecting separate mapping tables for connecting two topologies in Proposal 9 is necessary for intra-topology routing (concatenated traffic).

[0478] Inter-CU rerouting Applicability of BAP header rewrite operation

[0479] RAN2 is 「C In general, this agreement can be considered similar to inter-CU routing. However, in detail, inter-CU rerouting applies when an IAB node re-establishes an RRC connection with a target donor CU and the F1 connection with the source donor CU is still preserved (i.e. partial migration). RAN3 agreed on the following statements that are likely to apply in this scenario:

[0480] In partial inter-donor transition, the IP addresses, BAP addresses, BH RLC CH and default mappings used by the border node for traffic of a particular topology are assigned by the CU of that topology and they are configured via RRC.

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

[0482] The border IAB node can then transmit data to the next-hop BAP address via the BH RLC channel set up by the RRC of the new second topology, i.e., the target donor CU.

[0483] Proposal 11: For inter-CU rerouting, RAN2 should agree via RRC signaling from the target donor that the border IAB nodes are configured with IP addresses, BAP addresses, BH RLC channels and default mappings (as agreed by RAN3), and default routing IDs (or simplified header rewrite tables), etc.

[0484] Proposal 12: Regarding inter-CU rerouting, RAN2 should agree to rewrite the BAP header when routing (REL-16 routing) fails.

[0485] Proposal 13: For inter-CU rerouting, RAN2 should discuss whether routing table selection (if proposal 8 is introduced) or mapping table selection (if proposal 10 is introduced) can be applied.

[0486] Intra-CU / intra-DU rerouting

[0487] RAN2 agreed that "in inter-donor DU rerouting, the rewriting of the BAP header from the previous routing ID to the new routing ID is supported." On the other hand, RAN3 agreed as follows:

[0488] RAN3 wants the border nodes to perform BAP header rewrite for both UL and DL traffic only for traffic routed at the BAP layer from a BH link of one topology to a BH link of an adjacent topology.

[0489] Since the topology is managed by the donor CU and the two donor DUs in the donor CU are considered as intra-CU topology reduction, the rerouting between donor DUs is still considered to be performed within one topology. In this case, the agreement of RAN2 may conflict with the priority of RAN3. However, the BAP header rewrite operation is naturally necessary because the donor DU-to-donor DU rerouting changes the destination of the upstream traffic, i.e., from the BAP address of the donor DU to the BAP address of the other donor DU. For downstream traffic, the destination (BAP address of the access IAB node) does not change, so the BAP header rewrite operation may not be necessary. In fact, it is assumed that the downstream traffic is not subject to donor DU-to-donor DU rerouting (i.e., only local rerouting). Therefore, RAN2 should confirm the agreement even if it is different from the priority of RAN3.

[0490] Proposal 14: Regarding intra-CU / inter-DU rerouting, at least for upstream traffic, confirm the previous agreement of RAN2 that "rewriting of the BAP header from 'previous routing ID to new routing ID' is supported."

[0491] In Proposal 14, this is "rerouting", so when REL-16 routing fails, the BAP header is rewritten, just like with inter-CU rerouting in Proposal 12. This is already included in the RUNNING CR of the current TS 38.340, and can be easily confirmed.

[0492] Proposal 15: Inside CU / Donna -D U between Regarding rerouting, RAN2 should ensure that the BAP header rewrite operation is performed when routing (i.e. REL-16 routing) fails, as described in the current implementation of TS38.340.

[0493] Intra-CU / intra-donor-DU rerouting (=local rerouting) Applicability of BAP header rewrite operation

[0494] Rerouting within a CU / donor DU is called local rerouting and is already supported in REL-16 as follows:

[0495] NOTE: Data buffering in the BAP entity transmitter until the RLC-AM entity receives an acknowledgment is up to the implementation. In the case of a BH RLF, the BAP entity transmitter may reroute BAP data PDUs that were not acknowledged by lower layers before the BH RLF to an alternative path according to clause 5.2.1.3.

[0496] If there is at least one entry in the BH routing configuration whose BAP address matches the destination field and whose outgoing link corresponding to the next-hop BAP address is available, From the BH routing configuration, select an entry whose BAP address is the same as the destination field and whose outgoing link corresponding to the next hop BAP address is available. Select the outgoing link that corresponds to the next hop BAP address of the entry selected above.

[0497] According to the current specification, an IAB node may send a BAP data PDU via a routing ID that matches the destination but does not match the path of the data as a result of local rerouting.

[0498] On the other hand, in RAN2#112-E, it was agreed that REL-17 local rerouting should take into account the topology-wide goals as follows: RAN2 discusses local rerouting including its advantages over central routing and how it can address topology-wide goals.

[0499] Given the above agreement, there is a problem with REL-16 local reroute that the selection of alternative paths is left to the implementation of the IAB nodes, which may be difficult to manage from the donor's perspective. In the REL-16 IAB topology, local reroute is allowed only when the IAB node detects a BH RLF, i.e., only in certain abnormal conditions, so it is not a big problem. However, in REL-17, local reroute is allowed in other conditions (e.g., congestion conditions), so there is still a problem on how to satisfy the above agreement, although not to the extent that it is. It is quite understandable that to achieve the goal of the entire topology, the donor is best suited to manage the entire topology. In this sense, the donor needs to have more control over local reroute in terms of alternative path setup compared to the REL-16 mechanism.

[0500] Observation 1: In REL-16 local rerouting, the choice of which alternative path to choose is up to the IAB node implementation and cannot be controlled by the donor.

[0501] Observation 2: IAB donors are the nodes best suited to address topology-wide goals through local rerouting.

[0502] To solve this problem, rewriting the BAP header is considered to be one solution. RAN2 has agreed to the following: Assume that the IAB donor sets up (alternative) outgoing links that can be used for local rerouting (at least same destination, same routing ID, further consideration is needed).

[0503] Leaked Link Hane The first hop BAP address is associated with the first hop BAP address, and the next hop BAP address is determined by the routing ID. Therefore, it makes sense for the donor side to configure a new routing ID in the IAB node to perform local rerouting, which is very similar to the header rewrite configuration in other (re)routing scenarios.

[0504] RAN3 wants to perform the BAP header write operation only in the inter-topology scenario, while RAN2, as mentioned above, wants to perform the BAP header write operation only in the intra-topology scenario, i.e., -D U between It has already been agreed to carry this out in rerouting as well.

[0505] Therefore, it seems worth discussing whether the BAP header rewrite operation also applies to intra-CU / intra-DU rerouting, and is therefore only performed when the header rewrite setting is set (option).

[0506] Proposal 16: RAN2 should discuss the option if BAP header rewrite also applies to local rerouting (i.e. intra-CU / inter-DU rerouting) and IAB nodes are configured with mapping between old and new routing IDs (i.e. similar to the header rewrite configuration in the current TS38.340 implementation CR).

[0507] Local reroute command by donor Another aspect of IAB donor controllability is that local rerouting and topology-wide goals can coexist, with the IAB donor being aware of local rerouting and initiating / stopping local rerouting at IAB nodes. For example, if the IAB donor realizes that it cannot achieve its topology-wide goals, it can instruct the IAB nodes to start / stop local rerouting.

[0508] How the IAB donor handles topology-wide objectives with local rerouting is entirely up to the implementation, but the IAB donor may require information about and control over the local decisions of IAB nodes.

[0509] Proposal 17: RAN2 should discuss whether IAB nodes should notify IAB donors when local rerouting starts / stops.

[0510] Proposal 18: RAN2 should discuss whether IAB donors can instruct IAB nodes to start / stop local rerouting, for example for load balancing between routes.

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

Claims

1. 1. A method for controlling communications in an IAB node having an F1 connection with a first IAB donor controlling a first IAB topology, an RRC connection with a second IAB donor controlling a second IAB topology, and no F1 connection with the second IAB donor, comprising: receiving BAP header rewrite setting information including a first routing ID and a second routing ID as entries from the first IAB donor; receiving routing configuration information from the first IAB donor, the routing configuration information including a routing ID and a next hop BAP address as an entry and applicable to intra-topology routing and inter-topology routing; a receiving portion of a BAP layer of the IAB node receiving a BAP packet from a lower node; a transmission part of the BAP layer performs a BAP header rewriting process to rewrite the first routing ID of the received BAP packet to the second routing ID based on header information of the BAP packet and the BAP header rewriting setting information; The transmitting portion of the BAP layer performs the inter-topology routing via the second IAB topology on the BAP packet on which the BAP header rewriting process has been performed, In the routing configuration information, an entry to be applied to the inter-topology routing includes an indicator indicating that the entry is the inter-topology routing; The performing of the inter-topology routing includes performing the inter-topology routing using the routing ID included in the entry in which the indicator is set. Communications control method.

2. The performing of the BAP header rewriting process includes performing the BAP header rewriting process when a routing ID included in header information of the BAP packet matches the first routing ID. The communication control method according to claim 1 .

3. A BAP address of the IAB node in each topology is set; and if a BAP address of the IAB node in the topology associated with an ingress backhaul RLC channel of the BAP packet matches a destination BAP address included in a header of the BAP packet, the receiving portion of the BAP layer outputs the BAP packet to an upper layer. The communication control method according to claim 1 .

4. The IAB node: A first BAP address in the first IAB topology managed by the first IAB donor is set; A second BAP address in the second IAB topology managed by the second IAB donor is set. The communication control method according to claim 3.

5. Each of the first BAP address and the second BAP address is configured in the IAB node by an F1AP message or an RRC message. The communication control method according to claim 4.

6. outputting the BAP packet to the upper layer, removing a BAP header from the BAP packet; and outputting the BAP packet from which the BAP header has been removed to the upper layer. The communication control method according to claim 3.

7. and outputting the BAP packet to the transmitting portion of the BAP layer if the BAP address of the IAB node in the topology associated with the ingress backhaul RLC channel of the BAP packet does not match the destination BAP address included in the header of the BAP packet. The communication control method according to claim 3.

8. 1. An IAB node having an F1 connection with a first IAB donor controlling a first IAB topology, an RRC connection with a second IAB donor controlling a second IAB topology, and no F1 connection with the second IAB donor, receiving BAP header rewrite setting information including a first routing ID and a second routing ID as entries from the first IAB donor; receiving routing configuration information from the first IAB donor, the routing configuration information including a routing ID and a next hop BAP address as an entry and applicable to intra-topology routing and inter-topology routing; A process in which a receiving portion of a BAP layer of the IAB node receives a BAP packet from a lower node; a process in which a transmitting portion of the BAP layer performs a BAP header rewriting process to rewrite the first routing ID of the received BAP packet to the second routing ID based on header information of the BAP packet and the BAP header rewriting setting information; the transmitting portion of the BAP layer performs a process of performing the inter-topology routing via the second IAB topology on the BAP packet on which the BAP header rewriting process has been performed; In the routing configuration information, an entry to be applied to the inter-topology routing includes an indicator indicating that the entry is the inter-topology routing; The process of performing the inter-topology routing includes a process of performing the inter-topology routing using the routing ID included in the entry in which the indicator is set. IAB node.

9. A cellular communication system comprising the IAB node of claim 8.

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

11. A program for causing an IAB node to execute the communication control method according to claim 1.

Images