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

Abstract

Packet loss is suppressed at relay nodes. [Solution] The communication control method according to the first embodiment is a communication control method used in a cellular communication system. The communication control method includes the step of a donor node sending a message regarding routing settings to a relay node in the topology. The communication control method also includes the step of a relay node performing a first process in response to receiving the message.

Description

Technical Field

[0001] The present disclosure relates to a communication control method, a border relay node, a chipset, a cellular communication system, and a program.

Background Art

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

Summary of the Invention

[0003] The communication control method according to the first aspect is a communication control method used in a cellular communication system. The communication control method includes the border relay node receiving setting information regarding the inflow link from the network. Further, the communication control method includes the border relay node identifying the topology corresponding to the inflow link based on the setting information. Further, the communication control method includes the border relay node performing header rewriting processing on the packet flowing in from the inflow link based on the header rewriting setting information received from the network when the topology corresponding to the inflow link is a predetermined topology.

[0004] The second aspect of the communication control method is a communication control method used in a cellular communication system. The communication control method comprises a boundary relay node receiving configuration information from the network indicating the correspondence between topology and routing ID. The communication control method also comprises the boundary relay node determining a routing ID associated with the topology of the packet destination based on the configuration information received from the network. The communication control method also comprises the boundary relay node transmitting the packet, which includes the routing ID in its header.

[0005] A boundary relay node according to the third embodiment has a receiving unit that receives configuration information regarding inflow links from the network. The boundary relay node also has a control unit that identifies the topology to which the inflow link corresponds based on the configuration information. Here, if the topology to which the inflow link corresponds is a predetermined topology, the control unit performs header rewriting processing on packets that have flown in from the inflow link based on the header rewriting configuration information received from the network.

[0006] The processor according to the fourth embodiment is a processor that controls a boundary relay node. The processor performs a process of receiving configuration information regarding an inflow link from the network. The processor also performs a process of identifying the topology to which the inflow link corresponds based on the configuration information. Furthermore, if the topology to which the inflow link corresponds is a predetermined topology, the processor performs a process of performing a header rewrite on packets that have flown in from the inflow link based on the header rewrite configuration information received from the network.

[0007] The boundary relay node according to the fifth embodiment includes a receiving unit that receives configuration information from the network indicating the correspondence between topology and routing ID. The boundary relay node also includes a control unit that determines a routing ID associated with the topology of the packet destination based on the configuration information received from the network. The boundary relay node also includes a transmitting unit that transmits the packet, which includes the routing ID in its header.

[0008] The processor according to the sixth embodiment is a processor that controls a boundary relay node. The processor performs a process of receiving configuration information from the network that indicates the correspondence between topology and routing ID. The processor also performs a process of determining the routing ID associated with the topology of the packet destination based on the configuration information received from the network. The processor also performs a process of sending the packet, which includes the routing ID in its header. [Brief explanation of the drawing]

[0009] [Figure 1] Figure 1 shows an example configuration of a cellular communication system according to one embodiment. [Figure 2] Figure 2 shows the relationship between IAB nodes, parent nodes, and child nodes. [Figure 3] Figure 3 shows an example configuration of a gNB (base station) according to one embodiment. [Figure 4] Figure 4 shows an example configuration of an IAB node (relay node) according to one embodiment. [Figure 5] Figure 5 shows an example configuration of a UE (User Equipment) according to one embodiment. [Figure 6] Figure 6 shows an example of a protocol stack for IAB-MT RRC and NAS connections. [Figure 7] Figure 7 shows an example of a protocol stack for the F1-U protocol. [Figure 8]Figure 8 shows an example of a protocol stack for the F1-C protocol. [Figure 9] Figure 9 is a diagram showing an example of the configuration between nodes according to the first embodiment. [Figure 10] Figure 10 is a diagram illustrating an example of the operation of option D1 according to the first embodiment. [Figure 11] Figure 11 is a diagram illustrating an example of the operation of option D2 according to the first embodiment. [Figure 12] Figure 12 is a diagram illustrating an example of the operation of option U1 according to the first embodiment. [Figure 13] Figure 13 is a diagram illustrating an example of the operation of option U2 according to the first embodiment. [Figure 14] Figure 14 is a diagram illustrating an example of the operation of option C2 according to the first embodiment. [Figure 15] Figure 15 is a diagram showing an example of a boundary IAB node according to the second embodiment. [Figure 16] Figure 16 is a diagram illustrating an example of operation according to the second embodiment. [Figure 17] Figure 17 is a diagram showing an example configuration of a boundary IAB node according to the third embodiment. [Figure 18] Figure 18 is a diagram showing a first example of operation according to the third embodiment. [Figure 19] Figure 19 is a diagram showing a second example of operation according to the third embodiment. [Figure 20] Figure 20 is a diagram illustrating an example of operation according to the fourth embodiment. [Figure 21] Figure 21 is a diagram showing an example of a boundary IAB node according to the fifth embodiment. [Figure 22] Figure 22 is a diagram illustrating an example of operation according to the fifth embodiment. [Figure 23] Figure 23 is a diagram illustrating routing and rerouting scenarios. [Figure 24] Figure 24 shows a routing table applicable to inter-CU scenarios. [Figure 25]FIG. 25 is a diagram showing an overview of the routing / re-routing function enhancement for all scenarios.

Embodiments for Carrying Out the Invention

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

[0011] (Configuration of the 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 at least partially applied to the cellular communication system 1. Also, future cellular communication systems such as 6G may be applied to the cellular communication system 1.

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

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

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

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

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

[0017] Each gNB200 is a fixed wireless communication node that manages one or more cells. The term "cell" is used to refer to the smallest unit of a wireless communication area. The term "cell" may also be used to refer to the function or resource that enables wireless communication with the UE100. One cell belongs to one carrier frequency. Hereafter, the terms "cell" and "base station" may be used interchangeably.

[0018] Each gNB200 is interconnected with the 5GC10 via an interface called the NG interface. Figure 1 illustrates two gNB200-1 and gNB200-2 connected to the 5GC10.

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

[0020] Cellular communication system 1 supports IAB, which enables wireless relay of NR access using NR for backhaul. Donor gNB200-1 (or donor node; hereinafter sometimes referred to as "donor node") is the network-side NR backhaul termination node and is a donor base station with additional functions to support IAB. Backhaul can be multi-hop, via multiple hops (i.e., multiple IAB nodes 300).

[0021] Figure 1 shows an example where IAB node 300-1 is wirelessly connected to donor node 200-1, and IAB node 300-2 is wirelessly connected to IAB node 300-1, with the F1 protocol being transmitted over two backhaul hops.

[0022] The UE100 is a mobile wireless communication device that communicates wirelessly with a cell. The UE100 can be any device that communicates wirelessly with the gNB200 or IAB node 300. For example, the UE100 may be a mobile phone terminal, tablet terminal, notebook PC, sensor or device installed on a sensor, vehicle or device installed on a vehicle, aircraft or device installed on an aircraft. The UE100 connects wirelessly to the IAB node 300 or gNB200 via an access link. Figure 1 shows an example of the UE100 connecting wirelessly to IAB node 300-2. The UE100 communicates indirectly with donor node 200-1 via IAB node 300-2 and IAB node 300-1.

[0023] Figure 2 shows an example of the relationship between IAB node 300, parent nodes, and child nodes.

[0024] As shown in Figure 2, each IAB node 300 has an IAB-DU, which corresponds to the base station function unit, and an IAB-MT (Mobile Termination), which corresponds to the user equipment function unit.

[0025] On the IAB-MT's NR Uu radio interface, adjacent nodes (i.e., higher-level nodes) are called parent nodes. A parent node is the DU of the parent IAB node or donor node 200. The radio link between the IAB-MT and the parent node is called a backhaul link (BH link). Figure 2 shows an example where the parent nodes of IAB node 300 are IAB nodes 300-P1 and 300-P2. The direction toward the parent node is called upstream. From the perspective of UE100, the higher-level node of UE100 may be a parent node.

[0026] Adjacent nodes (i.e., lower-level nodes) on the NR access interface of an IAB-DU are called child nodes. The IAB-DU manages cells, similar to the gNB200. The IAB-DU terminates the NR Uu radio interface to the UE100 and lower-level IAB nodes. The IAB-DU supports the F1 protocol to the CU of donor node 200-1. Figure 2 shows an example where the child nodes of IAB node 300 are IAB nodes 300-C1 to 300-C3, but the child nodes of IAB node 300 may also include the UE100. The direction toward child nodes is called downstream.

[0027] Furthermore, all 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 Figure 2, adjacent nodes on the IAB-DU interface become child nodes, and adjacent nodes on the IAB-MT interface become parent nodes. The donor node 200 centrally manages, for example, the resources, topology, and route management of the IAB topology. The donor node 200 is a gNB that provides network access to the UE100 via the backhaul link and access link network.

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

[0029] The wireless communication unit 210 performs wireless communication with the UE 100 and with the IAB node 300. The wireless communication unit 210 includes a receiving unit 211 and a transmitting unit 212. The receiving unit 211 performs various types of reception under the control of the control unit 230. The receiving unit 211 includes an antenna and converts the wireless signal received by the antenna into a baseband signal (received signal) (downconvert) and outputs it to the control unit 230. The transmitting unit 212 performs various types of transmission under the control of the control unit 230. The transmitting unit 212 includes an antenna and converts the baseband signal (transmitted signal) output by the control unit 230 into a wireless signal (upconvert) and transmits it from the antenna.

[0030] The network communication unit 220 performs wired (or wireless) communication with 5GC10 and with other adjacent gNB200s. The network communication unit 220 has a receiving unit 221 and a transmitting unit 222. The receiving unit 221 performs various types of reception under the control of the control unit 230. The receiving unit 221 receives signals from the outside and outputs the received signals to the control unit 230. The transmitting unit 222 performs various types of transmission under the control of the control unit 230. The transmitting unit 222 transmits the transmission signals output by the control unit 230 to the outside.

[0031] The control unit 230 performs various controls in the gNB200. The control unit 230 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs executed by the processor and information used for processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation, demodulation, encoding, decoding, etc., of the baseband signal. The CPU executes programs stored in the memory and performs various processing. The processor performs processing for each layer described later. In each of the embodiments shown below, the control unit 230 may perform each processing or operation in the gNB200.

[0032] (Configuration of relay nodes) Next, the configuration of the IAB node 300, which is a relay node (or relay node device; hereinafter sometimes referred to as "relay node") according to the embodiment, will be described. Figure 4 is a diagram showing an example of the configuration of the IAB node 300. As shown in Figure 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.

[0033] The wireless communication unit 310 performs wireless communication with the gNB200 (BH link) and wireless communication with the UE100 (access link). The wireless communication unit 310 for BH link communication and the wireless communication unit 310 for access link communication may be provided separately.

[0034] The wireless communication unit 310 includes a receiving unit 311 and a transmitting unit 312. The receiving unit 311 performs various types of reception under the control of the control unit 320. The receiving unit 311 includes an antenna and converts the wireless signal received by the antenna into a baseband signal (received signal) (downconvert) and outputs it to the control unit 320. The transmitting unit 312 performs various types of transmission under the control of the control unit 320. The transmitting unit 312 includes an antenna and converts the baseband signal (transmitted signal) output by the control unit 320 into a wireless signal (upconvert) and transmits it from the antenna.

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

[0036] (User device configuration) Next, the configuration of the user device UE100 according to the embodiment will be described. Figure 5 is a diagram showing an example of the configuration of UE100. As shown in Figure 5, UE100 has a wireless communication unit 110 and a control unit 120.

[0037] The wireless communication unit 110 performs wireless communication on the access link, i.e., wireless communication with the gNB200 and wireless communication with the IAB node 300. The wireless communication unit 110 may also perform wireless communication on the side link, i.e., wireless communication with other UE100s. The wireless communication unit 110 has a receiving unit 111 and a transmitting unit 112. The receiving unit 111 performs various types of reception under the control of the control unit 120. The receiving unit 111 includes an antenna and converts the wireless signal received by the antenna into a baseband signal (received signal) (downconvert) and outputs it to the control unit 120. The transmitting unit 112 performs various types of transmission under the control of the control unit 120. The transmitting unit 112 includes an antenna and converts the baseband signal (transmitted signal) output by the control unit 120 into a wireless signal (upconvert) and transmits it from the antenna.

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

[0039] (Protocol stack configuration) Next, the configuration of the protocol stack according to the embodiment will be described. Figure 6 shows an example of a protocol stack for IAB-MT RRC connection and NAS connection.

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

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

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

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

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

[0045] The RRC layer controls the logical channel, transport channel, and physical channel in response to the establishment, re-establishment, and release of the radio bearer. RRC signaling for various settings is transmitted between the RRC layer of the IAB-MT on IAB node 300-2 and the RRC layer of donor node 200. If there is an RRC connection with donor node 200, the IAB-MT is in the RRC connected state. If there is no RRC connection with donor node 200, the IAB-MT is in the RRC idle state.

[0046] The NAS layer, located above the RRC layer, handles session management and mobility management, among other things. NAS signaling is transmitted between the NAS layer of IAB-MT on IAB node 300-2 and AMF11.

[0047] Figure 7 shows the protocol stack for the F1-U protocol. Figure 8 shows the protocol stack for the F1-C protocol. Here, an example is shown where donor node 200 is divided into CU and DU.

[0048] As shown in Figure 7, each of the IAB-MT on IAB node 300-2, the IAB-DU on IAB node 300-1, the IAB-MT on IAB node 300-1, and the DU on donor node 200 has a BAP (Backhaul Adaptation Protocol) layer as a layer above the RLC layer. The BAP layer is the layer that performs routing and bearer mapping / demapping. In backhaul, routing across multiple hops is possible because the IP layer is transmitted through the BAP layer.

[0049] In each backhaul link, the BAP layer's PDUs (Protocol Data Units) are transmitted via backhaul RLC channels (BH NR RLC channels). By configuring multiple backhaul RLC channels in each BH link, traffic prioritization and QoS (Quality of Service) control are possible. The mapping 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.

[0050] As shown in Figure 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 Figure 7.

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

[0052] Furthermore, the upstream direction and the uplink (UL) direction may not be distinguished. Additionally, the downstream direction and the downlink (DL) direction may not be distinguished.

[0053] [First Embodiment] Next, the first embodiment will be described.

[0054] First, the routing process according to the first embodiment will be described. (Routing process) Routing processing is performed at the BAP layer of IAB node 300. Specifically, the following processes are performed, for example:

[0055] In other words, the BAP layer routes BAP packets based on the BAP routing ID contained in the BAP header. The BAP header is added when the packet arrives from a higher layer and removed when it reaches the destination node. The BAP routing ID is set, or the routing table is set, by the CU on donor node 200. The BAP routing ID consists of the BAP address (or Destination, or destination BAP address) and the BAP path ID (or route identifier). The BAP address indicates the destination node. The BAP path ID indicates the routing path the packet follows to the destination.

[0056] Each IAB node 300 along the packet's path determines whether the packet has reached its destination, i.e., whether it matches the BAP address of the IAB node 300. Specifically, this is done based on the BAP address of the BAP routing ID included in the BAP header. If the packet has not reached its destination (destination BAP address) (i.e., the BAP address (Destination) included in the BAP header does not match the BAP address of the IAB node 300), the IAB node 300 determines the BAP address of the next hop (or backhaul link, or outflow link) based on the BAP routing ID included in the BAP header and the routing configuration.

[0057] The process of controlling the destination of packets is sometimes referred to as routing.

[0058] In the following, BAP routing ID may be referred to as routing ID, and BAP path ID as path ID. Also, IAB donor DU may be referred to as DU of donor node 200, and IAB donor CU may be referred to as CU of donor node 200. Furthermore, BAP path ID included in routing ID may be referred to as path ID, and BAP address included in routing ID may be referred to as destination.

[0059] (Communication control method according to the first embodiment) For donor node 200 to change the routing configuration for all IAB nodes in the topology, the larger the topology, the longer it is expected to take.

[0060] A potential issue arises when a packet with a specific routing ID is sent from an access IAB node (the node that first processes packets received from UE100 and the node that last processes packets sent to UE100) or the DU of donor node 200, and then the routing configuration is changed at an intermediate IAB node 300. In such cases, how the packet is handled can be a problem.

[0061] For example, if the routing settings are changed at the intermediate IAB node 300, it may route the packet to a different destination (i.e., a different route) than the destination it should have originally reached (the destination specified in the routing ID included in the packet's BAP header). Such routing errors can cause packet loss.

[0062] Therefore, in the first embodiment, the donor node 200 sends a routing configuration change start message and a routing configuration change completion message to the access IAB node 300-A. Based on the two messages, the access IAB node 300-A infers which packets have already reached the donor node 200 and, based on the inference result, retransmits packets that were previously sent.

[0063] Specifically, firstly, a donor node (e.g., donor node 200) sends a message regarding routing configuration to a relay node in the topology (e.g., IAB node 300). Secondly, the relay node performs the first processing in response to receiving the message.

[0064] Here, the process of sending a message includes sending a routing configuration change start message to the access relay node (e.g., access IAB node 300-A) in response to the donor node initiating a routing configuration change for the relay nodes in the topology. The process of sending a message also includes sending a routing configuration change completion message to the access relay node in response to the donor node completing the routing configuration change for the relay nodes in the topology. The first process also includes the access relay node retransmitting packets that were previously sent in the upstream direction for a certain period of time, based on the routing configuration change start message and the routing configuration change completion message.

[0065] Figure 9 is a diagram showing an example of the configuration between nodes according to the first embodiment. As shown in Figure 9, the donor node 200 sends a routing configuration change start message and a routing configuration change completion message to the access IAB node 300-A.

[0066] This allows access IAB node 300-A to determine, for example, the timing of the start and completion of routing configuration changes, and to accurately predict which packets have reached donor node 200 (or which have not yet reached donor node 200). Consequently, access IAB node 300-A can compensate for (or suppress) packet loss by retransmitting packets that are expected to have experienced packet loss.

[0067] (First example of operation according to the first embodiment) Next, a first example of operation according to the first embodiment will be described.

[0068] The first example describes the downstream and upstream directions separately. Furthermore, the first example presents two options for the downstream direction (Option D1 and Option D2). Similarly, the first example also presents two options for the upstream direction (Option U1 and Option U2).

[0069] (Downstream option D1) Figure 10 is a diagram illustrating an example of the operation of option D1 in the downstream direction according to the first embodiment.

[0070] As shown in Figure 10, in step S10, the donor node 200 starts processing.

[0071] In step S11, the donor node 200 holds the packets that have been transmitted in the downstream direction in memory or elsewhere.

[0072] In step S12, the donor node 200 changes the routing settings of all IAB nodes 300 in the topology and then estimates whether packets with headers conforming to the previous routing settings (i.e., transmitted packets) have reached the access IAB node. For example, the donor node 200 calculates the number of packets that reach the access IAB node per unit time from past transmission history and estimates the number of packets that have reached access IAB node 300-A based on the time elapsed since the routing setting change. The CU of the donor node 200 may also change the routing settings of the IAB-DU of access IAB node 300-A using messages via the F1AP protocol.

[0073] In step S13, the donor node 200 retransmits (blind retransmission) packets that were sent a certain period in the past, after adding a header according to the modified routing settings. For example, the donor node 200 may identify packets sent a certain period in the past by calculating how far back it needs to go based on the estimated number of arrived packets and the number of transmitted packets sent from the time the routing settings were changed until the present time.

[0074] In step S14, the donor node 200 terminates the series of processes.

[0075] (Downstream option D2) Figure 11 is a diagram illustrating an example of the operation of option D2 in the downstream direction according to the first embodiment.

[0076] As shown in Figure 11, in step S20, the donor node 200 starts processing.

[0077] In step S21, the donor node 200 holds the transmitted packets in memory or elsewhere in the downstream direction.

[0078] In step S22, the donor node 200 modifies the routing settings for all IAB nodes 300 in the topology and then identifies the UE100 that may be affected. For example, the donor node 200 may identify any UE100 that is connected to the donor node 200 via RRC as a UE100 that may be affected.

[0079] In step S23, the donor node 200 instructs the UE 100 to send a PDCP Status Report. For example, the CU of the donor node 200 sends this instruction to the UE 100 using an RRC message.

[0080] In step S24, the donor node 200 receives a PDCP status report from the UE100 and identifies packets that have not yet reached the UE100 based on the FMC (First Missing Count) included in the report. The donor node 200 then adds a header according to the modified routing settings to these packets and retransmits them. The CU of the donor node 200 may also receive the PDCP status report from the UE100 using an RRC message.

[0081] Then, donor node 200 completes the series of processes.

[0082] (Upstream option U1) Figure 12 is a diagram illustrating an example of the operation of the upstream option U1 according to the first embodiment.

[0083] As shown in Figure 12, in step S30, the access IAB node 300-A starts processing.

[0084] In step S31, the access IAB node 300-A holds the packets that have been transmitted in the upstream direction in memory or elsewhere.

[0085] In step S32, when the donor node 200 begins to change the routing configuration for the IAB node 300 associated with the access IAB node 300-A in the topology, it sends a routing configuration change start message to the access IAB node 300-A. The routing configuration change start message is a message indicating that a change in the routing configuration has begun. For example, the CU of the donor node 200 may send this message as an F1AP message to the IAB-DU of the access IAB node 300-A. Alternatively, for example, the CU of the donor node 200 may send this message as an RRC message to the IAB-MT of the access IAB node 300-A.

[0086] In step S33, when the donor node 200 has completed the routing configuration changes for the IAB node 300 associated with the access IAB node 300-A within the topology, it sends a routing configuration change completion message to the access IAB node 300-A. The routing configuration change completion message indicates that the routing configuration changes have been completed. For example, this message may be sent as an F1AP message or an RRC message. The routing configuration change completion message may also include the time required to change the routing configuration. This time may be expressed as the time from the start time of the routing configuration to the end time of the routing configuration.

[0087] In step S34, access IAB node 300-A estimates the number of packets that have reached donor node 200 from the transmitted packets, based on the routing configuration change start message and the routing configuration change completion message. For example, access IAB node 300-A may estimate the number of packets that have reached donor node 200 as follows: Access IAB node 300-A calculates the change time required to change the routing configuration from the reception time when it received the routing configuration change start message and the reception time when it received the routing configuration change completion message. Access IAB node 300-A also calculates the number of packets that reached donor node 200 per unit time from past history. Then, access IAB node 300-A estimates the number of packets that have reached donor node 200 based on the change time and the number of packets.

[0088] In step S35, the access IAB node 300-A retransmits (or blindly retransmits) packets that were sent a certain period in the past, after adding a header according to the modified routing configuration. For example, the access IAB node 300-A may retransmit packets that have been sent a certain period in the past, excluding the estimated arrived packets from the transmitted packets held in memory. Alternatively, for example, the access IAB node 300-A may define the time required to change the routing configuration as a certain period, and retransmit the transmitted packets for that period as packets sent a certain period in the past. Based on the routing configuration change start message and the routing configuration change completion message, the access IAB node 300-A will retransmit packets sent a certain period in the upstream direction.

[0089] Then, in step S36, the donor node 200 terminates the series of processes.

[0090] (Upstream option U2) Figure 13 is a diagram illustrating an example of the operation of the upstream option U2 according to the first embodiment.

[0091] As shown in Figure 13, in step S40, UE100 starts processing.

[0092] In step S41, UE100 stores the transmitted PDCP Data SDU (Service Data Unit) in memory or elsewhere. At this time, UE100 sets a longer-than-usual Discard Timer value. This is to prevent the PDCP SDU from being discarded due to timer expiration, taking into account the arrival delay of the multi-hop transfer from UE100 to the donor node 200.

[0093] In step S42, the donor node 200 modifies the routing settings for all IAB nodes 300 in the topology and then identifies the UE100 that may be affected. The donor node 200 may also identify any UE100 that is RRC connected to the donor node 200 as a UE100 that may be affected.

[0094] In step S43, the donor node 200 sends a PDCP status report to the UE100. The UE100 then discards the received packets (PDCP Data SDU) according to the PDCP status report.

[0095] In step S44, the donor node 200 triggers PDCP Data Recovery. UE100 retransmits the PDCP Data SDU it holds to the access IAB node 300-A. Access IAB node 300-A adds a header to the packet according to the modified routing configuration and sends it to the next hop node.

[0096] In step S45, the donor node 200 terminates the series of processes.

[0097] (Second example of operation according to the first embodiment) In the first operational example according to the first embodiment described above, the compensation for packet loss was explained by retransmitting packets that had been sent a certain period in the past.

[0098] However, the first example does not discuss how to deal with routing errors themselves. As a result, unnecessary packets due to routing errors may be forwarded within the topology, leading to wasted resources.

[0099] Therefore, in the second operational example, we will describe an example in which each IAB node 300 suspends routing processing from before the routing configuration change until the routing configuration change is completed, and after the routing processing resumes, it rewrites the header of the packets that were previously held in memory and sends them.

[0100] Specifically, firstly, a donor node (e.g., donor node 200) sends a routing stop instruction message to a relay node in the topology (e.g., IAB node 300). Secondly, the relay node stops routing in accordance with the routing stop instruction message and holds the received packets in memory. Thirdly, the donor node changes the routing configuration and sends mapping information to the relay node between the routing ID before the routing configuration change and the routing ID after the routing configuration change. Fourthly, the relay node resumes routing, rewrites the header of the packets held in memory according to the mapping information, and sends them.

[0101] In this way, each IAB node 300 pauses routing processing before and after a routing configuration change, and holds packets in memory. This prevents packets with routing errors from being forwarded within the topology. Then, after routing processing resumes, each IAB node 300 rewrites the routing ID contained in the header of the packets that were previously held in memory using the mapping information before and after the routing configuration change. As a result, packets with the correct routing ID after the routing configuration change are forwarded within the topology. Therefore, routing errors can be prevented.

[0102] The second operational example according to the first embodiment has two options (option C1 and option C2). Option C1 will be described first. Both options can be implemented for packet transmission in both the downstream and upstream directions.

[0103] (Option C1) When routing configurations are changed, donor node 200 changes the path ID of each routing ID, ensuring that the Destination does not change before and after the routing configuration changes.

[0104] Next, IAB node 300 receives packets according to the routing configuration before the routing configuration change.

[0105] Next, IAB node 300 performs local rerouting to the destination if the path ID included in the packet's routing ID does not exist in the modified routing configuration. Even if the path ID included in the packet does not exist in the modified routing configuration, the destination included in the packet still exists as an entry. Therefore, IAB node 300 can perform local rerouting to the correct destination. Local rerouting is the process of routing a packet to an alternative path without considering the routing configuration.

[0106] However, while 1024 (10 bits) destinations can be set, if the number of DUs in the topology (300 IAB nodes and 200 donor nodes) approaches 1024, the same destination may be used multiple times. In this case, option C1 may result in routing errors.

[0107] (Option C2) Figure 14 is a diagram illustrating an example of the operation of option C2 according to the first embodiment.

[0108] As shown in Figure 14, in step S50, the donor node 200 starts processing.

[0109] In step S51, before making routing configuration changes to the IAB nodes 300 in the topology, the donor node 200 sends a routing stop instruction message to (all or some) of the IAB nodes 300 in the topology, instructing them to stop routing. The routing stop instruction message may be sent as an F1AP message or an RRC message.

[0110] In step S52, the IAB node 300 stops the routing process upon receiving the routing stop instruction message and stores the received packet (BAP Data PDU) in memory or elsewhere.

[0111] In step S53, the donor node 200 modifies the routing configuration for (all or some) of the IAB nodes 300 in the topology. For example, the routing configuration may be changed by the CU of the donor node 200 sending the modified routing configuration to the IAB-DU of the IAB node 300 using an F1AP message.

[0112] In step S54, the donor node 200 sends mapping information to (all or some) of the IAB nodes 300 in the topology, which represents the correspondence between the routing ID before the routing configuration change and the routing ID after the routing configuration change. The mapping information may be sent as an F1AP message or an RRC message. The reception of this mapping information may trigger the resumption of routing processing at the IAB nodes 300. Alternatively, after sending the mapping information, the donor node 200 may send a routing resumption instruction message to (all or some) of the IAB nodes 300 in the topology. The routing resumption instruction message may also be sent as an F1AP message or an RRC message. The IAB nodes 300 resume routing processing in response to the receipt of the routing resumption instruction message.

[0113] In step S55, the IAB node 300 resumes routing and rewrites the (BAP) header of the packets (BAP Data PDU) held in memory according to the mapping information. Specifically, the BAP layer (or BAP entity; hereafter, the BAP layer and BAP entity may be used interchangeably) of the IAB node 300 rewrites the routing ID included in the header (routing ID before the routing configuration change) to the routing ID after the routing configuration change, according to the mapping information. After receiving the mapping information (or after resuming routing processing), the IAB node 300 does not rewrite the header of newly received packets according to the mapping information. Once the IAB node 300 has finished rewriting the headers according to the mapping information for all packets held in memory, it may discard the mapping information.

[0114] In step S56, the IAB node 300 processes the packet using the modified routing settings and sends it to the next hop node.

[0115] Then, in step S57, the series of processes is completed. [Second Embodiment] Next, a second embodiment will be described.

[0116] In the second embodiment, packet header rewriting in the downstream direction will be described.

[0117] IAB node 300 contains IAB nodes belonging to multiple topologies. Such IAB nodes are called boundary IAB nodes.

[0118] Figure 15 is a diagram showing an example of boundary IAB node 300-B according to the second embodiment. In the example shown in Figure 15, boundary IAB node 300-B belongs to two topologies: one configured by CU#1 (200-C1) of donor node 200, and the other configured by CU#2 (200-C2) of another donor node.

[0119] In the second embodiment, the topology configured by CU#1 (200-C1) may be referred to as the main topology, and the topology configured by CU#2 (200-C2) may be referred to as the sub-topology.

[0120] At boundary IAB node 300-B, header rewriting is performed during inter-CU routing. Inter-CU routing refers to routing packets, for example, from the first topology managed by the first CU to the second topology managed by the second CU.

[0121] Regarding upstream inter-CU routing, the boundary IAB node 300-B processes packets flowing in from the main topology and forwarding them to the subtopology. Specifically, the BAP layer of boundary IAB node 300-B uses a Header Rewriting Configuration table to rewrite the header of the packet (for example, by rewriting the routing ID, the destination is rewritten from CU#1 (200-C1) to CU#2 (200-C2)) and forwards the packet. The upstream header rewriting table is managed by CU#1 (200-C) on the main topology side.

[0122] On the other hand, regarding downstream inter-CU routing, the boundary IAB node 300-B processes packets flowing in from the subtopology to the main topology. Specifically, the BAP layer of boundary IAB node 300-B uses a header rewriting table to rewrite the header of the packet (for example, by rewriting the routing ID, the destination is rewritten from the access IAB node of the subtopology to the access IAB node of the main topology) and forwards the packet. The downstream header rewriting table is managed by CU#2 (200-C2) on the subtopology side.

[0123] Here, at boundary IAB node 300-B, the routing settings and the upstream header rewriting table are managed by the same donor node 200 (or CU#1 (200-C)). Therefore, at boundary IAB node 300-B, for upstream header rewriting, it can refer to the header rewriting table and determine whether or not to perform a header rewrite based on whether an entry exists.

[0124] On the other hand, at boundary IAB node 300-B, the downstream header rewriting table is managed by the subtopology (CU#2 (200-C2)) as described above. Furthermore, the routing ID of the subtopology is managed by CU#2 (200-C2), and the routing ID of the main topology is managed by CU#1 (200-C1). Therefore, the routing ID in the main topology and the routing ID in the subtopology may match. At boundary IAB node 300-B, when rewriting the header in the downstream direction, the header is rewritten without distinguishing between the routing ID on the main topology side and the routing ID on the subtopology side. Therefore, at boundary IAB node 300-B, when routing between CUs in the downstream direction, packets may be mistakenly leaked to the subtopology side.

[0125] Therefore, 3GPP is discussing that, for downstream header rewriting processing, packets flowing in from the SCG (Secondary Cell Group) side of boundary IAB node 300-B should be subject to header rewriting.

[0126] However, the SCG (Sequence Controller Group) does not necessarily belong to a subtopology. If the MCG (Master Cell Group) is a subtopology, downstream packets flowing in from the subtopology will not be subject to header rewriting. Conversely, packets flowing in from the SCG on the main topology side will be subject to header rewriting.

[0127] Therefore, in the second embodiment, an example is described in which the donor node 200 specifies to the boundary IAB node 300-B the link that will be subject to header rewriting in the downstream direction (or the parent node for the boundary IAB node 300-B).

[0128] Specifically, firstly, the donor node (e.g., donor node 200) sends specification information specifying the downstream link to the boundary relay node (e.g., boundary IAB node 300-B). Secondly, the boundary relay node performs header rewriting on packets flowing in from the downstream link according to the specification information.

[0129] This allows, for example, the boundary IAB node 300-B to identify packets whose headers need to be rewritten, enabling it to properly perform header rewriting in the downstream direction.

[0130] (Example of operation according to the second embodiment) Figure 16 is a diagram illustrating an example of operation according to the second embodiment.

[0131] As shown in Figure 16, in step S60, the donor node 200 starts processing.

[0132] In step S61, the donor node 200 sends designation information to the boundary IAB node 300-B, specifying the downstream links (or ingress links) that are subject to header rewriting. The designation information includes the ingress links that require (or are subject to) header rewriting. Specifically, the designation information may include the MCG or SCG that requires header rewriting. The designation information may also include the BAP address or cell ID of the parent node that requires header rewriting. Furthermore, the designation information may include links corresponding to the topology. For example, the designation information may include information indicating that the main topology is MCG and the subtopology is SCG, or that the main topology is SCG and the subtopology is MCG. In this case, the side designated as the subtopology is the link that requires header rewriting. The designation information may also be sent in an F1AP message or an RRC message.

[0133] In step S62, the BAP layer of boundary IAB node 300-B identifies packets that have flown in from the downstream link specified as specified information as packets to be rewritten, and performs header rewriting on those packets.

[0134] Then, in step S63, the series of processes is completed. [Third Embodiment] Next, a third embodiment will be described.

[0135] In the third embodiment, an example of classifying various types of header rewriting tables is described.

[0136] 3GPP is discussing how to differentiate the header rewriting table set on boundary IAB node 300-B for the UL direction (or upstream direction) and the DL direction (or downstream direction) when performing inter-CU routing.

[0137] Regarding header rewriting tables, if different tables are used for the UL (ultralink) and DL (download) directions, the BAP (Blockchain Application Program) layer may perform a process to determine the incoming direction for each packet. In other words, the BAP layer determines the incoming direction for each packet and then performs header rewriting using either the UL header rewriting table or the DL header rewriting table.

[0138] However, performing such processing at the boundary IAB node 300-B would increase the processing load for inter-CU routing. Furthermore, the BAP layer would have to exchange information with other layers to determine the direction of packet inflow, increasing its dependencies on other layers.

[0139] Therefore, in the third embodiment, the header rewriting tables used for inter-CU routing are classified into a table used on the IAB-MT side of boundary IAB node 300-B and a table used on the IAB-DU side.

[0140] Specifically, firstly, a donor node (e.g., donor node 200) sets up a first header rewrite table containing first classification information and a second header rewrite table containing second classification information for the boundary relay node (e.g., boundary IAB node 300-B). Secondly, the boundary relay node performs header rewriting on packets using at least one of the first and second header rewrite tables.

[0141] Here, the first header rewrite table is the header rewrite table for routing between the first CU used by the user equipment function unit (IAB-MT) of the boundary relay node, and the second header rewrite table is the header rewrite table for routing between the second CU used by the base station function unit (IAB-DU) of the boundary relay node.

[0142] Furthermore, the header rewriting process includes the user device function unit rewriting the header of a packet by referring to the header rewriting table for routing between the first CU, and the base station function unit rewriting the header of a packet by referring to the header rewriting table for routing between the second CU.

[0143] Thus, in the third embodiment, the header rewriting tables are classified into tables used by the IAB-MT and tables used by the IAB-DU, and are not classified by UL direction and DL direction. Therefore, it is possible to suppress the increase in processing caused by specifying the DL direction or UL direction for each packet. Furthermore, it is possible to suppress situations in which the BAP layer becomes highly dependent on other layers. Moreover, since the IAB-MT and IAB-DU only need to perform header rewriting processing using the configured header rewriting tables, it is possible to perform header rewriting processing appropriately.

[0144] Note that "UL" and "DL" may be used with the following meanings, for example: A packet forwarded from the first topology to the second topology may be "UL," and a packet forwarded from the second topology to the first topology may be "DL." Packets forwarded from the first topology to the first topology (i.e., within the same topology) are not subject to header rewriting.

[0145] (First example of operation according to the third embodiment) Figure 17 is a diagram showing an example configuration of boundary IAB node 300-B according to the third embodiment.

[0146] As shown in Figure 17, the IAB-MT (300-MT) has a header rewriting table 350-MT for inter-CU routing. The header rewriting table 350-MT is a table that performs header rewriting for packets in the UL direction.

[0147] Furthermore, IAB-DU (300-DU) has a header rewriting table 350-DU for inter-CU routing. Header rewriting table 350-DU is a header rewriting table for packets in the DL direction.

[0148] In the first operational example according to the third embodiment, the header rewrite table 350-MT on the IAB-MT (300-MT) side may be referred to as the MT rewrite table 350-MT, and the header rewrite table 350-DU on the IAB-DU (300-DU) side may be referred to as the DU rewrite table 350-DU.

[0149] Figure 18 is a diagram showing a first example of operation according to the third embodiment.

[0150] As shown in Figure 18, in step S70, the donor node 200 starts processing.

[0151] In step S71, the donor node 200 sets up rewrite tables for inter-CU routing with different classification information for DUs and MTs at the boundary IAB node 300-B. For example, the donor node 200 sets up a rewrite table 350-MT for MTs with first classification information and a rewrite table 350-DU for DUs with second classification information at the boundary IAB node 300-B.

[0152] The classification information may be for DU and MT for the two rewrite tables. The classification information is associated with each rewrite table. The classification information may also be a name that distinguishes the two rewrite tables. For example, "BAP Header Rewriting Configuration for IAB-DU" and "BAP Header Rewriting Configuration for IAB-MT". Furthermore, the rewrite table itself may be a single table, and the classification information for DU and MT may be associated with each entry (for example, an entry consisting of the old routing ID and the new routing ID).

[0153] Each rewrite table containing classification information may be transmitted, for example, using an F1AP message or an RRC message.

[0154] In step S72, boundary IAB node 300-B applies the setting. Since classification information exists in the rewrite table, boundary IAB node 300-B can easily determine where (IAB-MT (300-MT) or IAB-DU (300-DU)) the configured rewrite table should be set.

[0155] In step S73, the BAP layer of the boundary IAB node 300-B receives a packet (BAP Data PDU) from an upper layer or previous hop node and determines whether the received packet is subject to header rewriting. The BAP transmission unit (BAP Tx unit) of the IAB-MT refers to the header rewriting table 350-MT configured in the IAB-MT (300-MT), and if the routing ID included in the BAP header of the received packet matches the old routing ID in the header rewriting table 350-MT, it may determine that the packet is subject to header rewriting. On the other hand, if the routing ID that matches the routing ID included in the BAP header of the received packet does not exist in the old routing IDs of the header rewriting table 350-MT, the BAP transmission unit may determine that the packet is not subject to header rewriting. Similarly, the BAP transmission unit of the IAB-DU (300-DU) may refer to the header rewriting table 350-DU configured in the IAB-DU (300-DU). If the routing ID included in the BAP header of the received packet matches the old routing ID in the header rewriting table 350-DU, the packet may be identified as a target for header rewriting. If there is no match, the packet may be identified as not a target for header rewriting.

[0156] In step S74, the BAP layer of boundary IAB node 300-B performs header rewriting on packets that are subject to header rewriting. The BAP transmission unit of IAB-MT(300-MT) refers to the MT rewriting table 350-MT (for example, the header rewriting table for routing between the first CU) configured in IAB-MT(300-MT) and rewrites the BAP header of the packet from the old routing ID to the new routing ID. Similarly, the BAP transmission unit of IAB-DU(300-DU) refers to the DU rewriting table 350-DU (for example, the header rewriting table for routing between the second CU) configured in IAB-DU(300-DU) and rewrites the BAP header of the packet from the old routing ID to the new routing ID.

[0157] In step S75, the BAP layer of boundary IAB node 300-B performs routing according to the routing configuration.

[0158] In step S76, the boundary IAB node 300-B sends the packet to the next hop node.

[0159] Then, in step S77, the series of processes is completed.

[0160] (Second example of operation according to the third embodiment) In the first operational example according to the third embodiment, an example of classifying the header rewriting table for inter-CU routing was described. In the second operational example according to the third embodiment, an example of classifying the header rewriting table for inter-CU routing and the header rewriting table for inter-CU rerouting (or inter-DU rerouting) is described.

[0161] Rerouting may occur at IAB node 300. Rerouting occurs, for example, when a received packet is routed using the routing settings, but for some reason the packet could not be sent. Rerouting takes place after the routing process is completed.

[0162] Such rerouting can occur across topologies. For example, at boundary IAB node 300-B, a packet flowing in from the first topology in the UL direction may be routed back to the first topology, but if transmission fails, the packet may be rerouted to the second topology. In this case as well, boundary IAB node 300-B can rerout to the second topology by performing a header rewrite operation.

[0163] For example, in Figure 15, boundary IAB node 300-B changes the routing ID through a header rewrite process, changing the destination from CU#1 (200-C1) to CU#2 (200-C2). This type of rerouting across CUs is called inter-CU rerouting.

[0164] For example, in Figure 15, if CU#1 is DU#1 and CU#2 is DU#2, the routing ID may change due to the header rewriting process, which could change the Destination from DU#1 to DU#2. This type of rerouting across DUs is called inter-donor-DU rerouting.

[0165] Inter-CU rerouting and inter-donor-DU rerouting are sometimes collectively referred to as "header rewrite-based rerouting." Header rewrite-based rerouting may include at least one of inter-CU rerouting or inter-DU rerouting.

[0166] Rerouting within the same topology is called local rerouting.

[0167] Header rewrite-based rerouting occurs when routing processing has been performed but the packet could not be sent. Therefore, header rewrite-based rerouting is performed after the routing processing.

[0168] On the other hand, in inter-CU routing, the routing process is performed after the header rewriting process, sending the received packet to a different topology. Therefore, inter-CU routing is performed before the routing process.

[0169] Now, consider the case where the header rewriting table for inter-CU routing and the header rewriting table for header rewriting-based rerouting are combined into a single table. In this case, boundary IAB node 300-B may not know whether the routing IDs (old routing IDs) in that table should be processed before or after routing. Therefore, boundary IAB node 300-B may not be able to properly perform inter-CU routing and header rewriting-based rerouting.

[0170] Therefore, in the second operational example according to the third embodiment, an example is described in which the header rewriting table for inter-CU routing and the header rewriting table for header rewriting-based rerouting are classified separately.

[0171] Specifically, the first header rewrite table is a header rewrite table for inter-CU routing, and the second header rewrite table is a header rewrite table for header rewrite-based rerouting.

[0172] This allows, for example, the BAP layer of boundary IAB node 300-B to distinguish between two tables and perform header rewriting processing. Specifically, the BAP layer can use the header rewriting table for inter-CU routing when performing inter-CU routing processing before routing processing, and use the header rewriting table for header rewriting-based rerouting when performing header rewriting-based rerouting processing after routing processing. Therefore, boundary IAB node 300-B can appropriately perform both inter-CU routing and header rewriting-based rerouting.

[0173] In the second operational example according to the third embodiment, the header rewriting table for inter-CU routing may be referred to as the "routing header rewriting table." Furthermore, the header rewriting table for header rewriting-based rerouting may be referred to as the "rerouting header rewriting table."

[0174] Figure 19 is a diagram showing a second example of operation according to the third embodiment.

[0175] As shown in Figure 19, in step S80, the donor node 200 starts processing.

[0176] In step S81, the donor node 200 configures the routing header rewriting table and the rerouting header rewriting table for the boundary IAB node 300-B so that they have different classification information. For example, the donor node 200 configures the boundary IAB node 300-B with a routing header rewriting table that has first classification information and a rerouting header rewriting table that has second classification information.

[0177] The classification information may be for two rewrite tables, such as "for routing (or inter-CU routing)" and "for re-routing (or header rewrite-based rerouting)." In this case, the classification information is associated with each rewrite table. The classification information may also be a name that distinguishes the two rewrite tables. For example, it could be "BAP Header Rewriting Configuration for routing" and "BAP Header Rewriting Configuration for re-routing." Furthermore, the rewrite table itself may be a single table, and classification information such as "for routing" and "for re-routing" may be associated with each entry (for example, an entry consisting of an old routing ID and a new routing ID).

[0178] Each rewrite table containing classification information may be transmitted, for example, using an F1AP message or an RRC message.

[0179] In step S82, boundary IAB node 300-B applies the setting.

[0180] In step S83, the BAP layer of boundary IAB node 300-B receives a packet (BAP Data PDU) from an upper layer or previous hop node.

[0181] In step S84, the BAP layer may perform a header rewrite process for inter-CU routing on the packet. The BAP layer refers to the routing header rewrite table and, if there is an old routing ID identical to the routing ID of the packet, performs the header rewrite process for inter-CU routing. The BAP layer can easily identify the routing header rewrite table because it contains classification information. However, at this time, the BAP layer does not refer to the rerouting header rewrite table and does not perform header rewrite-based rerouting.

[0182] In step S85, the BAP layer performs routing and / or rerouting. The rerouting process at this time is local rerouting. That is, the BAP layer performs routing but then proceeds back to step S85 to perform local rerouting again.

[0183] In step S86, the BAP layer fails to route and / or reroute.

[0184] Here, "routing failed" may mean that, under certain evaluation conditions, the next hop BAP address could not be selected. The evaluation condition may be whether the Destination and Path ID match in the packet header and the routing configuration. Alternatively, the evaluation condition may be whether only the Destination matches in the packet header and the routing configuration.

[0185] In step S87, if the packet is subject to header rewrite-based rerouting, the BAP layer performs a header rewrite operation on the packet using the rerouting header rewrite table. The BAP layer may also determine whether or not the packet is subject to header rewrite-based rerouting. That is, the BAP layer may determine that the packet is subject to header rewrite-based rerouting if the old routing ID that matches the routing ID contained in the BAP header of the packet is found in the rerouting header rewrite table. On the other hand, the BAP layer may determine that the packet is not subject to header rewrite-based rerouting if the old routing ID that matches the routing ID contained in the BAP header of the packet is not found in the rerouting header rewrite table. The BAP layer refers to the rerouting header rewrite table and rewrites the BAP header of the packet from the old routing ID to the new routing ID.

[0186] In step S88, the BAP layer performs routing or header rewrite-based rerouting on the packet.

[0187] In step S89, the boundary IAB node 300-B sends the packet to the next hop node according to routing processing or header rewrite-based rerouting processing.

[0188] Then, in step S90, the series of processes is completed.

[0189] In the third embodiment, a common header rewriting table is used for inter-CU rerouting and inter-DU rerouting. Therefore, in the third embodiment, classification information for distinguishing between inter-CU rerouting and inter-DU rerouting is not used. [Fourth Embodiment] Next, a fourth embodiment will be described.

[0190] There are cases where the header of a single packet is rewritten multiple times. For example, consider the following case: Boundary IAB node 300-B rewrites the header of the packet via inter-CU routing, but the routing fails. Next, boundary IAB node 300-B rewrites the header of the packet again via inter-DU rerouting, but the routing fails once more.

[0191] Both the header rewriting table used for inter-CU routing and the header rewriting table used for header rewriting-based rerouting assume that the old routing ID included in the entries is the routing ID before the header rewriting.

[0192] However, when a header is rewritten using the header rewrite table, the header of that packet will contain the rewritten routing ID. In such cases, if the header rewrite process is performed based on the rewritten routing ID, the boundary IAB node 300-B may not be able to properly perform inter-CU routing or header rewrite-based rerouting.

[0193] Therefore, in the fourth embodiment, we will describe an example in which, if routing (or rerouting) fails after the header has been rewritten, the header of the packet is restored to its original routing ID.

[0194] Specifically, firstly, if a boundary relay node (for example, boundary IAB node 300-B) rewrites the header of a packet using the inter-CU routing header rewriting table and then fails to route, it reverts the rewritten routing ID back to the original routing ID. Secondly, if a boundary relay node rewrites the header of a packet using the rerouting header rewriting table and then fails to route, it reverts the rewritten routing ID back to the original routing ID.

[0195] As a result, even if the header is rewritten due to header rewriting, the routing ID will be reverted to the original routing ID if routing fails, allowing boundary IAB node 300-B to properly perform inter-CU routing or header rewrite-based rerouting.

[0196] (Example of operation according to the fourth embodiment) Figure 20 is a diagram illustrating an example of operation according to the fourth embodiment.

[0197] As shown in Figure 20, in step S100, the BAP layer of boundary IAB node 300-B starts processing.

[0198] In step S101, the BAP layer receives a packet.

[0199] In step S102, the BAP layer may perform a header rewrite process for inter-CU routing on the packet. If a previous routing ID matching the routing ID of the packet exists in the routing header rewrite table, the header rewrite process is performed. If the BAP layer performs a header rewrite process, it may record (or store) information in memory or elsewhere indicating that the header has been rewritten for inter-CU routing. Alternatively, the BAP layer may record information in memory or elsewhere indicating that the header has been rewritten.

[0200] In step S103, the BAP layer fails to route the packet. The BAP layer performs a header rewrite process for inter-CU routing, and if routing fails, it reverts the routing ID back to the original old routing ID. In this case, the BAP layer may also discard (or leave as unprocessed) the rewritten information stored in memory or elsewhere.

[0201] In step S104, the BAP layer performs a header rewrite operation for the packet using header rewrite-based rerouting. At this time, the BAP layer may record information in memory or elsewhere indicating that one of the header rewrite operations—for inter-CU rerouting, inter-DU rerouting, or header rewrite-based rerouting—has been completed. Alternatively, the BAP layer may record information indicating that the header rewrite operation has been completed.

[0202] In step S105, the BAP layer fails to perform the header rewrite base rerouting process.

[0203] In step S106, the BAP layer rewrites the header of the packet that was rewritten in step S104 back to its original routing ID (old routing ID). In this case, the BAP layer may also discard (or leave as unprocessed) the rewritten information stored in memory or elsewhere.

[0204] In step S107, the BAP layer returns the packet to a predetermined procedure, such as routing.

[0205] Then, in step S108, the series of processes is completed.

[0206] (Other examples of operation according to the fourth embodiment) Next, other operational examples of the fourth embodiment will be described. In the operational examples described above, the header is returned to its original routing ID due to routing failure or rerouting failure after header rewriting, but the original routing ID may also be restored by restoring the packet. Specifically, in step S101, when the BAP layer receives a packet, it saves a copy of the packet to memory. Next, in step S103, if routing fails, the BAP layer discards the packet (with rewritten header) and retrieves a copy of the packet from memory. Also, in step S105, if the header rewrite-based rerouting process fails, the BAP layer discards the packet (with rewritten header) and retrieves a copy of the packet from memory. As a result, the boundary IAB node 300-B can restore the original routing ID without rewriting the header again. [Fifth Embodiment] Next, a fifth embodiment will be described.

[0207] In 3GPP, inter-CU routing is primarily considered for user data. However, inter-CU routing is also possible for F1-C (control signal) traffic. For example, boundary IAB node 300-B can use the CP / UP separation function to encapsulate F1-C packets within an RRC message and send that RRC message using Split SRB1, thereby sending F1-C packets to either the first or second topology.

[0208] On the other hand, boundary IAB node 300-B may also perform inter-CU routing for user data generated on its own node (i.e., data received directly from UE100 by boundary IAB node 300-B as an access IAB node).

[0209] Figure 21 is a diagram showing an example of boundary IAB node 300-B according to the fifth embodiment.

[0210] Generally, an access IAB node creates a BAP header and sends the packet to donor node 200. For example, an access IAB node creates a BAP header as follows:

[0211] In other words, the access IAB node receives its Uplink Traffic to Routing ID Mapping Configuration from donor node 200. This configuration includes the traffic type specifier and the BAP routing ID. The Uplink Traffic to Routing ID Mapping Configuration is sent from donor node 200 via an F1AP message.

[0212] The BAP layer of an access IAB node selects an entry from the inbound traffic mapping configuration that includes the traffic type identifier corresponding to the BAP SDU's Destination IP address and TEID (Tunnel Endpoint Identifier) ​​if the BAP SDU received from the upper layer is FI-U traffic. On the other hand, if the BAP layer does not have F1-U traffic, it selects an entry from the inbound traffic mapping configuration that includes the BAP SDU's traffic type identifier.

[0213] Next, the BAP layer selects the routing ID (Destination and Path ID) for the entry. Then, using the selected routing ID, the BAP layer generates a BAP header and adds it to the BAP SDU to generate a BAP PDU.

[0214] Here, when performing inter-CU routing at the boundary IAB node 300-B, which is also an access IAB node, the following challenges arise. Specifically, the current inbound traffic mapping configuration basically includes one pair of traffic type identifier and BAP routing ID. If this one BAP routing ID is assigned to two topologies, and that BAP routing ID exists in both topologies, the boundary IAB node 300-B will not know which topology to send the BAP PDU to. Therefore, access IAB nodes may not be able to perform inter-CU routing properly.

[0215] Therefore, in the fifth embodiment, we will describe an example in which the boundary IAB node 300-B, which is also an access IAB node, selects a routing ID associated with the topology based on an inbound traffic mapping configuration that includes information about the topology to which the routing ID is applied.

[0216] Specifically, firstly, the donor node (e.g., donor node 200) configures an uplink traffic mapping setting, including the packet destination topology, for the boundary relay node (e.g., boundary IAB node 300-B). Secondly, the boundary relay node selects a routing ID associated with the topology based on the uplink traffic mapping setting. Thirdly, the boundary relay node sends a packet with the routing ID in the header.

[0217] As a result, the boundary IAB node 300-B, which is also an access IAB node, can determine which topology a routing ID is intended for, and thus generate packets appropriately for that topology. Therefore, the boundary IAB node 300-B, which is also an access IAB node, can perform inter-CU routing correctly.

[0218] (Example of operation according to the fifth embodiment) Figure 22 is a diagram illustrating an example of operation according to the fifth embodiment.

[0219] As shown in Figure 22, in step S110, the donor node 200 starts processing.

[0220] In step S111, the donor node 200 configures an inbound traffic mapping setting for the boundary IAB node 300-B, which is also an access IAB node. This inbound traffic mapping setting includes the existing traffic type identifier and BAP routing ID, as well as information on the topology to be applied (or the destination topology). This information may be referred to as topology information below.

[0221] In other words, the topology information may be MCG or SCG. For example, it indicates that the packet destination is MCG or SCG. Alternatively, the topology information may be the BAP address of the boundary IAB node 300-B. That is, the BAP address of the boundary IAB node 300-B includes BAP addresses set from the first topology and BAP addresses set from the second topology. By using the BAP address as the topology information, it is possible to identify whether the topology of the packet destination is the first topology or the second topology. Furthermore, the topology information may also be represented by whether the topology terminates F1-AP or not.

[0222] As an option, the uplink traffic mapping settings may include a bearer ID. The bearer ID represents the packet destination. For example, if the traffic type identifier is user data, the BAP layer may select a destination associated with each bearer ID. In this way, each bearer ID may have a different destination.

[0223] Topology information and bearer IDs may be present in each entry within the inbound traffic mapping configuration. Furthermore, this topology information and bearer ID may be configured separately. For example, two different inbound traffic mapping configurations may be notified to the boundary IAB node 300-B for each topology.

[0224] In step S112, the BAP layer of boundary IAB node 300-B receives the BAP SDU from the upper layer.

[0225] In step S113, the BAP layer selects the entry corresponding to the BAP SDU from the uplink traffic mapping configuration.

[0226] In step S114, the BAP layer identifies the topology (or packet destination) associated with the entry from the uplink traffic mapping configuration.

[0227] In step S115, the BAP layer selects the routing ID associated with the entry and / or topology.

[0228] In step S116, the BAP layer generates a BAP header using the routing ID, and adds the generated BAP header to the BAP SDU to generate a BAP PDU.

[0229] In step S117, the BAP layer selects the routing configuration associated with the identified topology and performs the routing process.

[0230] In step S118, boundary IAB node 300-B transmits the packet to the next hop node.

[0231] Then, in step S119, the boundary IAB node 300-B terminates the series of processes.

[0232] [Other embodiments] A program may be provided that causes a computer to perform each of the processes that UE100 or gNB200 performs. The program may be recorded on a computer-readable medium. Using a computer-readable medium, it is possible to install the program on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, but may be a recording medium such as a CD-ROM or DVD-ROM.

[0233] Alternatively, the circuits that perform each process carried out by the UE100 or gNB200 may be integrated, and at least a portion of the UE100 or gNB200 may be configured as a semiconductor integrated circuit (chipset, SoC: System on a chip).

[0234] 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 can be made without departing from the gist of the invention. The embodiments, operation examples, processes, or steps described above can also be combined in a way that is not contradictory.

[0235] The terms "based on" and "depending on" used in this disclosure do not mean "based solely on" or "depending solely on" unless otherwise specified. The term "based on" means both "based solely on" and "at least partially on." Similarly, the term "depending on" means both "at least partially on" and "at least partially on." Also, "obtain / acquire" may mean obtaining information from stored information, obtaining information from information received from other nodes, or obtaining information by generating it. The terms "include," "comprise," and their variations do not mean to include only the listed items, but may include only the listed items, or may include additional items in addition to the listed items. Also, the term "or" used in this disclosure is not intended to mean exclusive OR. Furthermore, any reference to elements using designations such as "first," "second," etc., used in this disclosure does not limit the quantity or order of those elements in general. These designations may be used herein as a convenient way to distinguish between two or more elements. Therefore, references to the first and second elements do not imply that only two elements may be employed therein, or that the first element must precede the second element in any way. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles shall be plural unless it is clearly indicated otherwise by the context.

[0236] This application claims priority to U.S. Provisional Application No. 63 / 296232 (filed January 4, 2022), the entirety of which is incorporated into the specification of this application. (Note 1) introduction In RAN2#116e, significant progress was made in routing and rerouting enhancements for the Integrated Access and eIAB (Backhaul Enhancement) work items for NR, and the agreement was supported as a running CR in TS38.340.

[0237] This addendum discusses the details of routing and rerouting, focusing on what are currently considered fundamental aspects, building upon agreed-upon procedures and ongoing CRs.

[0238] Discussion In Rel-17, as shown in Figure 23, routing and rerouting need to cover various scenarios, such as within a CU / within a donor DU (similar to Rel-16), between CUs / donor DUs, and between CUs. While these enhancements are expected to contribute to the reliability, flexibility, and low latency of packet forwarding in IAB topologies, they may introduce further complexity to BAP routing / rerouting operations. Therefore, it is desirable to define procedures common to all scenarios and minimize scenario-specific procedures as much as possible. In this sense, the most complex scenario, inter-CU routing, should be considered first, and then it should be considered whether the procedures for inter-CU routing can be applied (reused) to other scenarios.

[0239] Inter-CU routing Header rewrite detection Further consideration is needed regarding modeling in RX or Tx operation. In the currently running CR, the decision to rewrite the header is placed in the receive operation, and the following matters requiring further consideration have been incorporated.

[0240] Furthermore, it is possible to discuss whether to model the header rewrite determination using RX operation or TX operation.

[0241] From a technical standpoint, header rewriting can be modeled as either a receive operation or a transmit operation. However, from a specification standpoint, there are two BAP entities in IAB-MT and IAB-DU; that is, "In an IAB node, the BAP sublayer includes one BAP entity for MT functionality and another colocation BAP entity for DU functionality." Therefore, functional dependencies between entities must be minimized as much as possible.

[0242] It has been confirmed that the determination of header rewriting is highly dependent on the transmission operation. In fact, the result of the header rewriting determination does not affect the reception operation, as follows: regardless of whether or not header rewriting is determined, the packet is delivered to the transmission unit.

[0243] others In the receiving section of the BAP entity in the IAB-DU of a boundary IAB node, if the header rewrite setting contains an entry where the BAP address of the previous routing ID matches the Destination field and the BAP path identity of the previous routing ID matches the Path field (as defined in subclass 5.2.X), or Regarding the receiving portion of BAP entities in the IAB-MT of a boundary IAB node, if the inflow link is SCG, Consider the BAP data packet for BAP header rewriting. The BAP data packet is delivered to the transmitting unit of the deployed BAP entity.

[0244] The results are then used in the transmission process as follows: header rewriting is performed only on packets that are determined to be subject to header rewriting.

[0245] The sending section of a BAP entity performs the following actions if there is a BAP Data PDU to send.

[0246] If a BAP entity receiving a BAP Data PDU modifies the BAP header, it modifies the BAP header.

[0247] Perform routing to determine the outgoing link.

[0248] Determine the outflow BH RLC channel.

[0249] This BAP Data PDU is sent to the selected leak BH RLC channel on the selected leak link.

[0250] Finding 1: The header rewriting determination result does not depend on the receiving operation, but it does affect the transmitting operation.

[0251] In this sense, it is preferable that the decision to rewrite the header be modeled by a transaction operation. Further consideration is needed regarding whether to incorporate it within the BAP header rewrite operation or to create a new section.

[0252] Proposal 1: Regarding inter-CU routing, RAN2 should agree to model the header rewriting decision in the transmit operation.

[0253] Further consideration is needed regarding downstream traffic. Regarding the details of how to determine the need for header rewriting, another further consideration has been incorporated: downstream traffic, specifically the receiving portion of BAP entities in the IAB-MT of a boundary IAB node, where if the inflow link is SCG, BAP data packets for BAP header rewriting should be considered.

[0254] Further consideration is needed regarding whether the SCG is sufficient to identify inflow links for inter-topology transitions / topology redundancy / RLF recovery, including the case where the SN is an F1 termination node.

[0255] As mentioned above, SCG may not be applicable to all cases, such as CP / UP separation. Therefore, it is considered simple for the donor to explicitly indicate which inflow link, i.e., MCG or SCG, requires the header rewriting operation.

[0256] Proposal 2: Regarding inter-CU routing, RAN2 should agree that the donor side should configure which inflow links, i.e., MCG or SCG BAP headers, need to be rewritten in IAB-MT.

[0257] Header rewriting operation Matters requiring further consideration regarding header rewriting settings In RAN2#116e, we discussed configuration issues and reached the following agreements regarding matters requiring further consideration.

[0258] Further consideration is needed regarding rewriting the mapping settings from old routing IDs to new routing IDs, and (in the case of all rewrites) limiting the possible rewrites.

[0259] Furthermore, the following additional considerations are being incorporated into the ongoing CR (Critical Review).

[0260] Based on the R3 agreement, further investigation will be conducted into whether and how header rewriting settings differ between UL and DL. For UL traffic, they must indicate the outgoing topology they refer to. This indication may be implicit.

[0261] In the current running CR, it is specified that "when the BAP data PDU is subject to BAP header rewriting, the transmission part of the BAP entity performs the BAP header rewriting operation", that is, after determining the header rewriting, the header rewriting is performed by the Tx part. In this case, in the IAB-DU, the header rewriting setting for the downstream is always used, and in the IAB-MT, only the one for the upstream is used. Therefore, it is simpler to define two header rewriting tables and associate them with the IAB-DU and IAB-MT respectively, which is the same as the operation for determining the header rewriting.

[0262] Proposal 3: For CU-to-CU routing, the donor side should agree to configure the boundary IAB nodes with two header rewriting tables used in the Tx part of the BAP entity of the IAB-DU (i.e., downstream) and that of the IAB-MT (i.e., upstream) respectively.

[0263] Matters Requiring Further Consideration in the Header Rewriting Operation In the currently running CR, the header rewriting operation is incorporated at the same level as the transmission and reception operations, with the following description attached.

[0264] It is used to incorporate the method of BAP header rewriting and can be used in the cases of CU-to-CU routing, CU-to-CU rerouting, and donor DU-to-DU rerouting. Regarding the necessity / position / details of this section, it will be confirmed / revised after RAN2 obtains a clear agreement on all cases of header rewriting.

[0265] Since the header rewriting operation is referenced in the transmission operation, it needs to be incorporated under the transmission operation.

[0266] Proposal 4: RAN2 should define the header rewriting operation under the transmission operation, that is, it should be agreed in the BAP specification.

[0267] Selection of the Routing Table In principle, a donor CU manages the routing table for its own topology. In an inter-CU scenario, it is assumed that two donor CUs are involved in routing at the boundary IAB node, and these donor CUs manage their routing tables independently. In this sense, it is straightforward that the boundary IAB node consists of two routing tables, each managed separately by these donor CUs.

[0268] Proposal 5: RAN2 should agree that each boundary IAB node consists of two routing tables, each managed by a donor CU and another donor CU.

[0269] If we agree to Proposal 5, it is worth discussing how the boundary IAB node selects the routing table to apply to the traffic being routed. In the inter-CU scenario, as shown in Figure 2, there are two traffic categories: traffic routed within the topology (similar to legacy routing, also known as unconnected traffic) and traffic routed across two topologies (also known as connected traffic).

[0270] When routing is performed in the Tx section of a BAP entity, as shown in Figure 24, there are three transmission directions (outflow links) regardless of the receiving source (inflow link).

[0271] In topology #1 in Figure 24, it can be seen that downstream traffic always follows the legacy routing table, regardless of whether the traffic is concatenated or not. Therefore, the boundary IAB node must apply the legacy routing table to the routing of downstream traffic.

[0272] Proposal 6: Regarding downstream packets, RAN2 should agree that boundary IAB nodes should always select the legacy routing table.

[0273] For upstream traffic, the applicable routing table differs depending on the topology in which the packets are sent. Assuming that the combined traffic has its header rewritten before routing processing, as in the currently running CR, the boundary IAB node can select the appropriate routing table as follows:

[0274] For packets whose headers are not rewritten, the legacy routing table (as in topology #1 in Figure 24) is selected.

[0275] For packets with rewritten headers, a new routing table (in the case of topology #2 in Figure 24) is selected.

[0276] Once the appropriate routing table is selected, the packets are processed according to the existing routing procedure.

[0277] Proposal 7: Regarding upstream packets, RAN2 should agree that the boundary IAB node should choose either the legacy routing table or the new routing table depending on whether the packet being routed has had its header rewritten.

[0278] Inter-CU rerouting and donor-DU rerouting Conditions for rerouting due to header rewriting The currently running CR incorporates the following items that require further consideration as conditions for rerouting based on header rewriting.

[0279] The phrase "If a header rewrite table (for rerouting) is configured" needs to be corrected to "If the header rewrite table contains an entry where the BAP address of the previous routing ID matches the Destination field, and the BAP path ID of the previous routing ID matches the Path field."

[0280] This issue relates to whether the header rewriting tables for rerouting (=CU-to-CU rerouting, donor-DU-to-DU rerouting) are separate from those for routing (=CU-to-CU routing). Routing header rewriting is performed before the routing procedure, while rerouting header rewriting is performed after the routing procedure. In other words, routing header rewriting must be performed based on the routing header rewriting table, and rerouting header rewriting must be performed based on the rerouting header rewriting table. Assuming the same header rewriting table is used, boundary IAB nodes may become confused depending on whether the old routing ID is rewritten before or after the routing procedure, i.e., whether it is for routing or rerouting. Therefore, it is desirable to separate the header rewriting tables for rerouting and routing.

[0281] Finding 2: Routing header rewriting operations are performed before routing procedures based on routing header rewriting settings, while rerouting header rewriting operations are performed after routing procedures based on rerouting header rewriting settings.

[0282] Another issue is whether it is necessary to separate the header rewriting tables for inter-CU rerouting and inter-donor DU rerouting. Since both inter-CU rerouting and inter-donor DU rerouting are rerouting scenarios, one might think that the same header rewriting table can be used. Also, both inter-CU rerouting and inter-donor DU rerouting are assumed to target only upstream traffic. Therefore, the header rewriting table for rerouting does not need to distinguish between upstream and downstream.

[0283] However, CU-CU routing performs RRC restoration for different IAB donors, i.e., different topologies, at this point (i.e., in the transitional state), while donor DU-DU routing changes the destination BAP address for different IAB donor DUs within the same topology (i.e., in the static state). Therefore, there may be some differences from the perspective of path-related settings. Thus, until further agreement is reached, it should be regarded as an item that requires further consideration at present.

[0284] From the above findings, it is desirable to define a header rewrite table for routing separately from at least the header rewrite table for routing.

[0285] Proposal 8: RAN2 should agree that the header rewrite tables for CU-CU routing and donor DU-DU routing are different from the table for CU-CU routing. Further consideration is required on whether a common header rewrite table is applicable to both routing scenarios.

[0286] Header Rewrite Before and After Egress Link Selection In the currently ongoing CR, the following items that require further consideration are incorporated.

[0287] If RAN2 agrees to perform header rewrite after egress link selection in the case of UL routing based on header rewrite, the above can be corrected.

[0288] It is assumed that the selection of the egress link is performed within the routing procedure, and the header rewrite operation is performed before the routing procedure. That is, the selection of the egress link and the header rewrite operation are currently separated. Therefore, these processes become complicated when they are mixed.

[0289] Furthermore, in RAN2#116e, within the topology (rerouting between donor DUs), the preconditions for rewriting the BAP header for rerouting were agreed to be the same as in Rel-16, i.e., without any conditions related to outflow link selection, as follows:

[0290] Within topology For upstream routing, the prerequisite / criteria for "rerouting by BAP header rewriting" is the same as in R16: no available next hop can be found based on the BAP routing ID and the BAP address in the routing table (due to BH RLF, congestion, Type-2 Indication, etc.).

[0291] It is not reasonable to consider different preconditions for header rewriting in inter-CU rerouting. Therefore, the above agreement should apply to both donor-DU inter-rerouting and inter-CU rerouting.

[0292] Proposal 9: RAN2 should agree that, similar to Rel-16, outgoing link selection should occur within the routing procedure, i.e., header rewriting should occur before outgoing link selection.

[0293] The advantage of selecting the outgoing link before header rewriting is that it avoids the possibility of packet rerouting failure after header rewriting. In other words, if inter-CU rerouting or donor-DU rerouting fails, it is unclear whether a packet that has undergone header rewriting will undergo header rewriting again, i.e., how many times the header will be rewritten for a single packet. Performing header rewriting multiple times can introduce risks of error and complexity.

[0294] In this scenario, if rerouting between CUs or donor DUs fails, the reception of flow control feedback assumes that the IAB node has no available links due to congestion. In this case, packets will be sent via the outgoing link that recovered from congestion earlier. Therefore, packets should ideally have either the old routing ID or the new routing ID, depending on the recovered outgoing link.

[0295] From the above discussion, one possible approach is to revert the header from the new routing ID back to the old routing ID if rerouting based on header rewriting fails. In this way, the packet returns to its original state, i.e., with the old routing ID in the header, and can be processed from the beginning of the BAP entity's transmission operation. This means routing can be attempted again for this packet, and if routing fails, rerouting can be performed.

[0296] Proposal 10: RAN2 should discuss whether to revert the header if header rewriting-based rerouting (i.e., inter-CU rerouting or donor-DU rerouting) fails.

[0297] Modeling rerouting based on header rewriting In Rel-16, routing and rerouting are modeled within the routing process; that is, rerouting follows routing.

[0298] If the BAP address matches the Destination field, the BAP Path ID matches the Path field, and an entry exists in the BH routing configuration where an outgoing link corresponding to the next hop address is available, Select the leaked link corresponding to the next hop address of that entry.

[0299] If the BAP address matches the Destination field and there is at least one entry in the BH routing configuration where an outgoing link corresponding to the next hop address is available, Select an entry from the BH routing configuration where the BAP address is the same as the Destination field and an outgoing link corresponding to the next hop address is available.

[0300] Select the outflow link corresponding to the next hop address of the entry selected above.

[0301] In the currently running CR, header rewriting-based rerouting applies the same modeling, namely, that which follows Rel-16 rerouting.

[0302] Otherwise, if header rewriting settings (for rerouting) are configured and at least one outgoing link is available, Perform a BAP header rewrite operation.

[0303] If the BH routing configuration has a BAP address that matches the Destination field, a BAP Path ID that matches the Path field, and an outgoing link corresponding to the next hop address exists, Select the leaked link corresponding to the next hop address of that entry.

[0304] As described above, Rel-16 routing and Rel-17 header rewriting-based rerouting appear to execute the same procedure, i.e., the routing steps again. Therefore, they can be considered as candidates for simplification.

[0305] Furthermore, local rerouting in Rel-16 was unclear because it occurred within the routing procedure itself. Therefore, separating the rerouting section from the routing section might be a possible option.

[0306] Proposal 11: RAN2 should discuss ways to simplify rerouting modeling in order to make the specification clearer.

[0307] Summary of Feature Enhancements If you agree to the above proposal, Figure 25 shows an example of an integrated solution for all scenarios, and Table 1 shows an overview of the header rewrite table and routing table.

[0308] [Table 1] Overview of the overall scenario configuration enhancements

[0309] (Note 2) The features of the above-described embodiment are described below.

[0310] (1) A communication control method used in a cellular communication system, The donor node sends a message regarding routing configuration to the relay nodes in the topology, The relay node performs a first process in response to receiving the message. Communication control method.

[0311] (2) The aforementioned transmission step is, The steps include: sending a routing configuration change commencement message to the access relay node in response to the donor node initiating a routing configuration change for the relay node in the topology; The donor node sends a routing configuration change completion message to the access relay node in response to the completion of routing configuration changes for the relay nodes in the topology, The step of performing the first processing described above is: The access relay node includes the step of retransmitting packets that were previously sent in the upstream direction for a certain period of time, based on the routing configuration change start message and the routing configuration change completion message. The communication control method described in (1) above.

[0312] (3) The aforementioned transmission step is, The donor node includes the step of sending a routing stop instruction message to the relay node in the topology, The step of performing the first processing described above is: The relay node includes the steps of stopping the routing process in accordance with the routing stop instruction message and holding the received packets in memory, Furthermore, the donor node modifies the routing settings and sends mapping information between the routing ID before the routing setting change and the routing ID after the routing setting change to the relay node. The relay node has the step of resuming routing processing, rewriting the header of the packet held in memory according to the mapping information, and sending it. The communication control method described in (1) above.

[0313] (4) A communication control method used in a cellular communication system, The donor node sends specified information, which indicates the downstream link, to the boundary relay node. The boundary relay node performs a header rewriting process on packets flowing in from the downstream link according to the specified information, Communication control method.

[0314] (5) A communication control method used in a cellular communication system, The donor node sets up a first header rewrite table containing first classification information and a second header rewrite table containing second classification information for the boundary relay node. The boundary relay node performs a header rewriting process on a packet using at least one of the first header rewriting table and the second header rewriting table. Communication control method.

[0315] (6) The first header rewriting table is a header rewriting table for routing between first CUs used by the user equipment function unit (IAB-MT) of the boundary relay node, and the second header rewriting table is a header rewriting table for routing between second CUs used by the base station function unit (IAB-DU) of the boundary relay node. The step of performing the header rewriting process includes the steps of the user device function unit performing header rewriting on the packet by referring to the first inter-CU routing header rewriting table, and the base station function unit performing header rewriting on the packet by referring to the second inter-CU routing header rewriting table. The communication control method described in (5) above.

[0316] (7) The first header rewrite table is a header rewrite table for inter-CU routing, and the second header rewrite table is a header rewrite table for header rewrite-based rerouting. The communication control method described in (5) above.

[0317] (8) The step of performing the header rewriting process is: If the boundary relay node rewrites the header of the packet using the inter-CU routing header rewriting table and then fails to route, the rewritten routing ID is restored to the routing ID before rewriting. The boundary relay node, after rewriting the header of the packet using the rerouting header rewriting table, and then fails to route the packet, includes the step of restoring the rewritten routing ID to the routing ID before rewriting. The communication control method described in (7) above.

[0318] (9) A communication control method used in a cellular communication system, The donor node configures an uplink traffic mapping configuration for the boundary relay node, including the topology of the packet destination. The boundary relay node selects a routing ID associated with the topology based on the upstream traffic mapping settings, The boundary relay node transmits the packet, which includes the routing ID in its header. Communication control method.

Claims

1. A communication control method used in a cellular communication system, The boundary relay node receives configuration information from the network that shows the mapping between topology and routing IDs, The boundary relay node determines the routing ID associated with the topology of the packet destination based on the configuration information, The boundary relay node transmits the packet, which includes the routing ID in its header. Communication control method.

2. It is a boundary relay node, A receiving unit that receives configuration information from the network indicating the correspondence between topology and routing ID, A control unit that determines the routing ID associated with the topology of the packet destination based on the aforementioned configuration information, A transmitting unit that transmits the packet containing the routing ID in its header, Boundary relay node.

3. A chipset for a boundary relay node, Receiving configuration information from the network that shows the mapping between topology and routing ID, Based on the aforementioned configuration information, the routing ID associated with the topology of the packet destination is determined, Sending the packet containing the routing ID in its header, including Chipset.

4. A cellular communication system having boundary relay nodes, The boundary relay node receives configuration information from the network that indicates the correspondence between topology and routing ID. The boundary relay node determines the routing ID associated with the topology of the packet destination based on the configuration information, The boundary relay node transmits the packet, which includes the routing ID in its header. Cellular communication system.

5. At the boundary relay node of the cellular communication system, The process involves receiving configuration information from the network that shows the mapping between topology and routing IDs, Based on the aforementioned configuration information, a process is performed to determine the routing ID associated with the topology of the packet destination, The process of sending the packet containing the routing ID in the header is performed. program.

Images