Communication Control Method

Abstract

To provide a communication control method for use in a relay node in a cellular communication system.SOLUTION: A communication control method includes the steps of transmitting a message regarding routing configuration from a donor node to a relay node in a topology, and performing a first process in response to receiving the message by the relay node (IAB node).SELECTED DRAWING: Figure 16

Description

[Technical Field]

[0001] The present disclosure relates to a communication control method for use in a cellular communication system. [Background technology]

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

[0003] A communication control method according to a first aspect is a communication control method used in a cellular communication system. The communication control method includes a boundary relay node receiving configuration information related to an inflow link from a network. The communication control method also includes the boundary relay node identifying a topology to which the inflow link corresponds based on the configuration information. The communication control method also includes the boundary relay node performing a header rewrite process on packets that have flowed in from the inflow link based on header rewrite configuration information received from the network if the topology to which the inflow link corresponds is a predetermined topology.

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

[0005] A boundary relay node according to a third aspect has a receiving unit that receives configuration information related to an inflow link from a network. The boundary relay node also has a control unit that identifies a topology to which the inflow link corresponds based on the configuration information. Here, when the topology to which the inflow link corresponds is a predetermined topology, the control unit performs a header rewrite process on packets that have flowed in from the inflow link based on header rewrite configuration information received from the network.

[0006] A processor according to a fourth aspect is a processor that controls a boundary relay node. The processor executes a process of receiving configuration information related to an inflow link from a network. The processor also executes a process of identifying a topology to which the inflow link corresponds based on the configuration information. The processor also executes a process of performing a header rewrite process on packets that have flowed in from the inflow link based on header rewrite configuration information received from the network if the topology to which the inflow link corresponds is a predetermined topology.

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

[0008] A processor according to a sixth aspect is a processor that controls a boundary relay node. The processor executes a process of receiving configuration information indicating a correspondence between a topology and a routing ID from a network. The processor also executes a process of determining a routing ID associated with a topology of a packet destination based on the configuration information received from the network. The processor also executes a process of transmitting the packet that includes the routing ID in a header. [Brief explanation of the drawings]

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

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

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

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

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

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

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

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

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

[0018] Each gNB 200 is interconnected with the 5GC 10 via an interface called an NG interface. Figure 1 illustrates two gNBs, gNB 200-1 and gNB 200-2, connected to the 5GC 10.

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

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

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

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

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

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

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

[0026] Adjacent nodes (i.e., lower nodes) on the NR access interface of the IAB-DU are called child nodes. The IAB-DU manages a cell, similar to the gNB 200. The IAB-DU terminates the NR Uu radio interface to the UE 100 and lower IAB nodes. The IAB-DU supports the F1 protocol to the CU of the donor node 200-1. While FIG. 2 shows an example in which the child nodes of the IAB node 300 are IAB nodes 300-C1 to 300-C3, the child nodes of the IAB node 300 may also include the UE 100. The direction toward the 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 FIG. 2, adjacent nodes on the IAB-DU interface are child nodes, and adjacent nodes on the IAB-MT interface are parent nodes. The donor node 200 centrally manages, for example, resources, topology, and route management of the IAB topology. The donor node 200 is a gNB that provides network access to the UE 100 via a network of backhaul links and access links.

[0028] (Base station configuration) Next, a configuration of the gNB 200, which is a base station according to the embodiment, will be described. Fig. 3 is a diagram showing an example configuration of the gNB 200. As shown in Fig. 3, the gNB 200 has a radio 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 wireless communication with the IAB node 300. The wireless communication unit 210 has a receiving unit 211 and a transmitting unit 212. The receiving unit 211 performs various types of reception under the control of the control unit 230. The receiving unit 211 includes an antenna, and converts (down-converts) a wireless signal received by the antenna into a baseband signal (received signal), and outputs the signal to the control unit 230. The transmitting unit 212 performs various types of transmission under the control of the control unit 230. The transmitting unit 212 includes an antenna, and converts (up-converts) a baseband signal (transmitted signal) output by the control unit 230 into a wireless signal, and transmits the signal from the antenna.

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

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

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

[0033] The wireless communication unit 310 performs wireless communication (BH link) with the gNB 200 and wireless communication (access link) with the UE 100. The wireless communication unit 310 for BH link communication and the wireless communication unit 310 for access link communication may be provided separately.

[0034] The wireless communication unit 310 has 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 (down-converts) a radio signal received by the antenna into a baseband signal (received signal), and outputs the signal to the control unit 320. The transmitting unit 312 performs various types of transmission under the control of the control unit 320. The transmitting unit 312 includes an antenna, and converts (up-converts) a baseband signal (transmitted signal) output by the control unit 320 into a radio signal, and transmits the signal 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 in processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processes. The processor performs processing of each layer, which will be described later. Note that the control unit 320 may perform each process or operation in the IAB node 300 in each of the embodiments described below.

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

[0037] The radio communication unit 110 performs radio communication in the access link, i.e., radio communication with the gNB 200 and radio communication with the IAB node 300. The radio communication unit 110 may also perform radio communication in the side link, i.e., radio communication with another UE 100. The radio communication unit 110 has a receiving unit 111 and a transmitting unit 112. The receiving unit 111 performs various receptions under the control of the control unit 120. The receiving unit 111 includes an antenna, and converts (down-converts) a radio signal received by the antenna into a baseband signal (received signal), and outputs the signal to the control unit 120. The transmitting unit 112 performs various transmissions under the control of the control unit 120. The transmitting unit 112 includes an antenna, and converts (up-converts) a baseband signal (transmitted signal) output by the control unit 120 into a radio signal, and transmits the signal 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 in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processing. The processor performs processing of each layer, which will be described later. Note that the control unit 120 may perform each processing in the UE 100 in each of the embodiments described below.

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

[0040] As shown in FIG. 6, the IAB-MT of IAB node 300-2 has a physical (PHY) layer, a medium access control (MAC) layer, a radio link control (RLC) layer, a packet data convergence protocol (PDCP) layer, a radio resource control (RRC) layer, and a non-access stratum (NAS) layer.

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

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

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

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

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

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

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

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

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

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

[0051] In the following, the processing or operations performed by the IAB-DU and IAB-MT of the IAB may be simply referred to as the processing or operations of the "IAB." 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 the IAB node 300-1 sending the message to IAB node 300-2. In addition, the processing or operations of the DU or CU of the donor node 200 may be simply referred to as the processing or operations of the "donor node."

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

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

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

[0055] That is, the BAP layer routes BAP packets based on the BAP routing ID included in the BAP header. The BAP header is added when a packet arrives from an upper layer and is removed when the packet reaches the destination node. The BAP routing ID setting or routing table is set by the CU of the donor node 200. The BAP routing ID consists of a BAP address (or Destination, or destination BAP address) and a BAP path ID (or route identifier). The BAP address indicates the destination node. The BAP path ID indicates the routing path that the packet follows to reach the destination.

[0056] Each IAB node 300 on the packet route 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 its own IAB node), the IAB node 300 determines the BAP address of the next hop (or backhaul link, or outgoing link) based on the BAP routing ID included in the BAP header and the routing configuration.

[0057] The process of controlling the destination of a packet in this way is sometimes called, for example, a routing process.

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

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

[0060] If a packet with a certain routing ID is sent from an access IAB node (a node that first processes packets received from UE 100 and a node that last processes packets to be sent to UE 100) or a DU of a donor node 200, and then the routing settings are changed in an intermediate IAB node 300, a problem may arise as to how the packet is processed.

[0061] For example, when the routing setting is changed in the intermediate IAB node 300, the packet may be routed to a destination (i.e., a different route) different from the destination it should have been (the destination of the routing ID included in the BAP header of the packet). Such a routing error may cause packet loss.

[0062] Therefore, in the first embodiment, the donor node 200 transmits a routing setting change start message and a routing setting change completion message to the access IAB node 300-A. The access IAB node 300-A estimates packets that have already arrived at the donor node 200 based on the two messages, and retransmits packets that have been transmitted in the past based on the estimation results.

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

[0064] Here, the message transmitting process includes a process of transmitting a routing setting change start message to an access relay node (e.g., access IAB node 300-A) in response to the donor node starting to change the routing setting for a relay node in the topology. The message transmitting process also includes a process of transmitting a routing setting change completion message to the access relay node in response to the donor node completing the routing setting change for a relay node in the topology. The first process includes a process of the access relay node retransmitting a packet that was transmitted in the upstream direction within a certain period of time based on the routing setting change start message and the routing setting change completion message.

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

[0066] This allows the access IAB node 300-A to grasp, for example, the timing of starting a routing setting change and the timing of completing the routing setting change, and to accurately estimate packets that have already arrived at the donor node 200 (or packets that have not yet arrived at the donor node 200). Therefore, the access IAB node 300-A can compensate for (or suppress) packet loss by retransmitting packets that are expected to have been lost.

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

[0068] The first operation example describes the downstream direction and the upstream direction separately. Also, in the first operation example, there are two options for the downstream direction (Option D1 and Option D2). Also, in the first operation example, there are two options for the upstream direction (Option U1 and Option U2).

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

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

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

[0072] In step S12, after changing the routing settings of (all) IAB nodes 300 in the topology, the donor node 200 estimates whether packets having headers according to the routing settings before the change (i.e., transmitted packets) have already reached the access IAB node. For example, the donor node 200 calculates the number of packets arriving at the access IAB node per unit time from past transmission history, and estimates the number of packets that have already reached the access IAB node 300-A based on the time from the change in routing settings to the current time. Note that the CU of the donor node 200 may change the routing settings to the IAB-DU of the access IAB node 300-A using a message according to the F1AP protocol.

[0073] In step S13, the donor node 200 retransmits (blind retransmits) packets transmitted within a certain period of time after adding a header according to the changed routing setting. For example, the donor node 200 may identify packets transmitted within a certain period of time by calculating how far back it should go based on the estimated number of packets that have arrived and the number of packets that have been transmitted since the routing setting was changed until the current time.

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

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

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

[0077] In step S21, the donor node 200 stores the transmitted packets in the downstream direction in a memory or the like.

[0078] In step S22, the donor node 200 identifies UEs 100 that are likely to be affected after changing the routing settings for (all) IAB nodes 300 in the topology. For example, the donor node 200 may identify UEs 100 that are in an RRC connected state with the donor node 200 as UEs 100 that are likely to be affected.

[0079] In step S23, the donor node 200 instructs the UE 100 to transmit a PDCP status report. For example, the CU of the donor node 200 transmits the instruction to the UE 100 by using an RRC message.

[0080] In step S24, the donor node 200 receives a PDCP status report from the UE 100, and identifies packets that have not yet arrived at the UE 100 based on an FMC (First Missing Count) included in the report. The donor node 200 then adds a header to the packet in accordance with the changed routing setting, and retransmits the packet. Note that the CU of the donor node 200 may receive the PDCP status report from the UE 100 by using an RRC message.

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

[0082] (Option U1 in upstream direction) FIG. 12 is a diagram illustrating an example of the operation of the option U1 in the upstream direction according to the first embodiment.

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

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

[0085] In step S32, when the donor node 200 starts a change in the routing configuration for an IAB node 300 associated with the access IAB node 300-A in the topology, the donor node 200 transmits a routing configuration change initiation message to the access IAB node 300-A. The routing configuration change initiation message is a message indicating that a change in the routing configuration has been initiated. For example, the CU of the donor node 200 may transmit the 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 transmit the 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 completes the change of the routing configuration for the IAB node 300 associated with the access IAB node 300-A in the topology, the donor node 200 transmits a routing configuration change completion message to the access IAB node 300-A. The routing configuration change completion message is a message indicating that the change of the routing configuration has been completed. For example, the message may be transmitted 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. The time may be expressed as the time from the routing configuration start time to the routing configuration end time.

[0087] In step S34, the access IAB node 300-A estimates which of the transmitted packets have reached the donor node 200, based on the routing setting change start message and the routing setting change completion message. For example, the access IAB node 300-A may estimate which packets have reached the donor node 200 as follows. That is, the access IAB node 300-A calculates the change time required to change the routing setting from the reception time of the routing setting change start message and the reception time of the routing setting change completion message. The access IAB node 300-A also calculates the number of packets that have reached the donor node 200 per unit time from past history. Then, the access IAB node 300-A estimates which packets have reached the 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 transmitted within a certain period of time after adding headers according to the changed routing setting. For example, the access IAB node 300-A may retransmit packets, excluding the estimated packets that have arrived from the transmitted packets stored in its memory, as packets transmitted within a certain period of time. Alternatively, for example, the access IAB node 300-A may set the change time required to change the routing setting as a certain period of time and retransmit transmitted packets for that period of time as packets transmitted within a certain period of time. The access IAB node 300-A retransmits packets transmitted within a certain period of time in the upstream direction based on the routing setting change start message and the routing setting change completion message.

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

[0090] (Option U2 in upstream direction) FIG. 13 is a diagram illustrating an example of the operation of option U2 in the upstream direction according to the first embodiment.

[0091] As shown in FIG. 13, in step S40, the UE 100 starts the process.

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

[0093] In step S42, the donor node 200 changes the routing settings for (all) IAB nodes 300 in the topology, and then identifies UEs 100 that are likely to be affected. The donor node 200 may identify UEs 100 that are in an RRC connected state with the donor node 200 as UEs 100 that are likely to be affected.

[0094] In step S43, the donor node 200 transmits a PDCP status report to the UE 100. The UE 100 discards the packet (PDCP Data SDU) that has already arrived in accordance with the PDCP status report.

[0095] In step S44, the donor node 200 triggers PDCP data recovery. The UE 100 retransmits the PDCP data SDU that it has stored to the access IAB node 300-A. The access IAB node 300-A adds a header to the packet in accordance with the changed routing setting, and transmits the packet to the next hop node.

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

[0097] (Second operation example according to the first embodiment) In the first operation example according to the first embodiment described above, a packet loss is compensated for by, for example, retransmitting packets that have been transmitted in the past for a certain period of time.

[0098] However, the first operation example does not discuss how to deal with the routing error itself, which may result in unnecessary packets being forwarded within the topology due to the routing error, resulting in unnecessary resource consumption.

[0099] Therefore, in the second operation example, we will explain an example in which the routing process is stopped in each IAB node 300 from before the routing setting change until the routing setting change is completed, and after the routing process is resumed, the headers of the packets that have been held in memory until then are rewritten and sent.

[0100] Specifically, first, a donor node (e.g., donor node 200) sends a routing stop instruction message to a relay node (e.g., IAB node 300) in the topology. Second, the relay node stops routing processing in accordance with the routing stop instruction message and stores the received packets in memory. Third, the donor node changes the routing settings to the relay node and sends mapping information between the routing ID before the routing setting change and the routing ID after the routing setting change. Fourth, the relay node resumes routing processing and rewrites the header of the packet stored in memory in accordance with the mapping information before sending the packet.

[0101] In this way, each IAB node 300 stops the routing process before and after the routing setting change and stores packets in memory. This prevents packets caused by a routing error from being forwarded within the topology. Then, after resuming the routing process, each IAB node 300 rewrites the routing ID contained in the header of the packet that was previously stored in memory using the mapping information before and after the routing setting change. This allows packets that have been rewritten with the correct routing ID after the routing setting change to be forwarded within the topology. This makes it possible to prevent routing errors.

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

[0103] (Option C1) When changing the routing setting, the donor node 200 changes the path ID of each routing ID, and does not change the destination before and after the change of the routing setting.

[0104] Next, the IAB node 300 receives packets according to the routing settings before the routing settings were changed.

[0105] Next, if the path ID included in the routing ID of the packet does not exist in the changed routing setting, the IAB node 300 performs local re-routing to the destination. Even if the path ID included in the packet does not exist in the changed routing setting, the destination included in the packet exists as an entry. Therefore, the IAB node 300 can perform local re-routing to the correct destination. Local re-routing is the routing of a packet to an alternative path without considering the routing setting.

[0106] However, although 1024 destinations (10 bits) can be set, if the number of DUs in the IAB node 300 and donor node 200 in the topology approaches 1024, the same destination may be used multiple times. In this case, there is a possibility of a routing error in option C1.

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

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

[0109] In step S51, the donor node 200 transmits a routing stop instruction message to (all or some of) the IAB nodes 300 in the topology to instruct them to stop routing processing before changing the routing settings of the IAB nodes 300 in the topology. The routing stop instruction message may be transmitted as an F1AP message or an RRC message.

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

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

[0112] In step S54, the donor node 200 transmits mapping information indicating the correspondence between the routing IDs before the routing setting change and the routing IDs after the routing setting change to (all or some of) the IAB nodes 300 in the topology. The mapping information may be transmitted by an F1AP message or an RRC message. Note that, in the IAB node 300, reception of this mapping information may trigger restart of the routing process. Alternatively, after transmitting the mapping information, the donor node 200 may transmit a routing restart instruction message to (all or some of) the IAB nodes 300 in the topology. The routing restart instruction message may also be transmitted as an F1AP message or an RRC message. In response to receiving the routing restart instruction message, the IAB node 300 restarts the routing process.

[0113] In step S55, the IAB node 300 resumes the routing process and rewrites the (BAP) header of the packet (BAP Data PDU) stored in memory in accordance with the mapping information. Specifically, the BAP layer (or BAP entity; hereinafter, the BAP layer and BAP entity may be used interchangeably) of the IAB node 300 rewrites the routing ID (the routing ID before the routing setting change) included in the header to the routing ID after the routing setting change in accordance with the mapping information. Note that after receiving the mapping information (or after resuming the routing process), the IAB node 300 does not rewrite the header of newly received packets using the mapping information. After completing the header rewriting using the mapping information for all packets stored in memory, the IAB node 300 may discard the mapping information.

[0114] In step S56, the IAB node 300 performs routing processing on the packet using the changed routing settings, and transmits the packet to the next hop node.

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

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

[0117] Some IAB nodes 300 belong to multiple topologies. Such IAB nodes are called boundary IAB nodes.

[0118] Fig. 15 is a diagram illustrating an example of a boundary IAB node 300-B according to the second embodiment. In the example illustrated in Fig. 15, the boundary IAB node 300-B belongs to two topologies: a topology configured by CU#1 (200-C1) of the donor node 200, and a topology 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] The boundary IAB node 300-B performs header rewriting processing in inter-CU routing, which is, for example, routing a packet from a first topology managed by a first CU to a second topology managed by a second CU.

[0121] Regarding inter-CU routing in the upstream direction, the boundary IAB node 300-B performs processing to send packets that have flowed in from the main topology out to the sub-topology. Specifically, the BAP layer of the boundary IAB node 300-B uses a header rewriting table (Header Rewriting Configuration) to rewrite the header of the packet (for example, by rewriting the routing ID, the destination is rewritten from CU#1 (200-C1) to CU#2 (200-C2)), and then 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, for downstream inter-CU routing, the boundary IAB node 300-B performs processing to send packets that have flowed in from the sub-topology out to the main topology. Specifically, the BAP layer of the boundary IAB node 300-B uses a header rewrite 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 sub-topology to the access IAB node of the main topology), and then forwards the packet. The downstream header rewrite table is managed by CU#2 (200-C2) on the sub-topology side.

[0123] Here, in the boundary IAB node 300-B, the routing configuration and the upstream header rewrite table are managed by the same donor node 200 (or CU#1 (200-C)). Therefore, in regard to upstream header rewrite, the boundary IAB node 300-B can refer to the header rewrite table and determine whether to perform header rewrite depending on whether an entry exists in the table.

[0124] On the other hand, in the boundary IAB node 300-B, the header rewrite table for the downstream direction is managed by the sub-topology (CU#2 (200-C2)) as described above. Furthermore, the routing ID of the sub-topology 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 sub-topology may match. When rewriting a header in the downstream direction, the boundary IAB node 300-B rewrites the header without distinguishing between the routing ID on the main topology side and the routing ID on the sub-topology side. Therefore, when routing between CUs in the downstream direction, the boundary IAB node 300-B may erroneously send a packet to the sub-topology side.

[0125] Therefore, in 3GPP, with regard to the header rewriting process in the downstream direction, there is discussion about targeting the header rewriting of packets that have flowed in from the SCG (Secondary Cell Group) side of the border IAB node 300-B.

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

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

[0128] Specifically, first, a donor node (e.g., donor node 200) transmits designation information specifying a downstream link to a boundary relay node (e.g., boundary IAB node 300-B). Second, the boundary relay node performs a header rewriting process on packets that have flowed in from the downstream link in accordance with the designation information.

[0129] As a result, for example, the boundary IAB node 300-B can identify the packet whose header is to be rewritten, and can therefore appropriately perform the header rewriting process in the downstream direction.

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

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

[0132] In step S61, the donor node 200 transmits, to the border IAB node 300-B, designation information that designates a downstream link (or ingress link) to be subject to header rewriting. The designation information includes the ingress link that requires header rewriting (or is 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 of the parent node that requires header rewriting or the cell ID of the parent node. Furthermore, the designation information may include a link corresponding to the topology. For example, the designation information may include information indicating that the main topology is the MCG and the sub-topology is the SCG, or the main topology is the SCG and the sub-topology is the MCG. In this case, the side designated as the sub-topology is the link that requires header rewriting. The designation information may be transmitted in a state that the designation information is included in an F1AP message or an RRC message.

[0133] In step S62, the BAP layer of the boundary IAB node 300-B identifies, in accordance with the designation information, the packet that has flowed in from the downstream link designated as the designation information as a packet to be rewritten, and performs a header rewriting process on the packet.

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

[0135] In the third embodiment, an example of classifying various types of header rewrite tables will be described.

[0136] In 3GPP, when performing inter-CU routing, how to make the header rewrite table set in the border IAB node 300-B different for the UL direction (or upstream direction) and the DL direction (or downstream direction) is being discussed.

[0137] Regarding the header rewrite table, when different tables are used for the UL direction and the DL direction, the BAP layer may perform a process to identify the inflow direction for each packet. That is, after identifying the inflow direction for each packet, the BAP layer performs a header rewrite process using either the UL header rewrite table or the DL header rewrite table.

[0138] However, performing such processing at the boundary IAB node 300-B increases the amount of inter-CU routing processing. Also, the BAP layer exchanges information with other layers to identify the packet inflow direction, which increases the dependency on other layers.

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

[0140] Specifically, first, a donor node (e.g., donor node 200) sets a first header rewrite table having first classification information and a second header rewrite table having second classification information for a border relay node (e.g., border IAB node 300-B). Second, the border relay node performs header rewrite processing on the packet using at least one of the first header rewrite table and the second header rewrite table.

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

[0142] The header rewriting process also includes the user equipment function unit performing header rewriting on the packet by referring to a header rewriting table for first inter-CU routing, and the base station function unit performing header rewriting on the packet by referring to a header rewriting table for second inter-CU routing.

[0143] As described above, in the third embodiment, the header rewrite tables are classified into tables used on the IAB-MT side and tables used on the IAB-DU side, and are not classified into UL and DL directions. This makes it possible to suppress the increase in processing load caused by identifying the DL or UL direction for each packet. It is also possible to suppress the situation in which the BAP layer increases its dependency on other layers. Furthermore, since the IAB-MT and IAB-DU only need to perform header rewrite processing using the configured header rewrite tables, it is possible to perform header rewrite processing appropriately.

[0144] Note that "UL" and "DL" may be used to mean, for example, the following: That is, when a packet is transferred from a first topology to a second topology, it can be "UL." Also, when a packet is transferred from a second topology to the first topology, it can be "DL." Note that packets transferred from the first topology to the first topology (i.e., within the same topology) are not subject to header rewriting.

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

[0146] 17, the IAB-MT (300-MT) has a header rewrite table 350-MT for inter-CU routing. The header rewrite table 350-MT is a table for rewriting the headers of packets in the UL direction.

[0147] The IAB-DU (300-DU) also has a header rewrite table 350-DU for inter-CU routing. The header rewrite table 350-DU is a header rewrite table for packets in the DL direction.

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

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

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

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

[0152] The classification information may be information for DU and MT for the two rewrite tables. The classification information is linked to each rewrite table. The classification information may also be a name that distinguishes between 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 classification information for DU and MT may be linked to each entry (for example, an entry consisting of an old routing ID and a new routing ID).

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

[0154] In step S72, the border IAB node 300-B applies the setting. Because the rewrite table contains classification information, the border IAB node 300-B can easily determine the position (IAB-MT (300-MT) or IAB-DU (300-DU)) at which the set rewrite table should be set.

[0155] In step S73, the BAP layer of the border IAB node 300-B receives a packet (BAP Data PDU) from an upper layer or a previous hop node and determines whether the received packet is a header rewrite target. The BAP transmitter (BAP Tx unit) of the IAB-MT may refer to the header rewrite table 350-MT set in the IAB-MT (300-MT) and determine that the packet is a header rewrite target if the routing ID included in the BAP header of the received packet matches the old routing ID in the header rewrite table 350-MT. On the other hand, the BAP transmitter may determine that the packet is not a header rewrite target if the old routing ID in the header rewrite table 350-MT does not match the routing ID included in the BAP header of the received packet. Similarly, the BAP transmitting unit of the IAB-DU (300-DU) may refer to the header rewriting table 350-DU set in the IAB-DU (300-DU), 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-DU, it may identify the packet as one for which the header is to be rewritten, and if there is no match, it may identify the packet as one for which the header is not to be rewritten.

[0156] In step S74, the BAP layer of the boundary IAB node 300-B performs a header rewrite process on the packet whose header is to be rewritten. The BAP transmitter of the IAB-MT (300-MT) refers to the MT rewrite table 350-MT (for example, the header rewrite table for first inter-CU routing) set in the IAB-MT (300-MT) and rewrites the BAP header of the packet from the old routing ID to the new routing ID. In addition, the BAP transmitter of the IAB-DU (300-DU) refers to the DU rewrite table 350-DU (for example, the header rewrite table for second inter-CU routing) set in the 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 the boundary IAB node 300-B performs routing processing in accordance with the routing setting.

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

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

[0160] (Second operation example according to the third embodiment) In the first operation example according to the third embodiment, an example of classifying the header rewrite table for inter-CU routing has been described. In the second operation example according to the third embodiment, an example of classifying the header rewrite table for inter-CU routing and the header rewrite table for inter-CU rerouting (or inter-DU rerouting) will be described.

[0161] Rerouting may be performed in the IAB node 300. Rerouting is performed, for example, when a routing process is performed on a received packet using a routing setting, but the packet cannot be sent for some reason. Rerouting is performed after the routing process.

[0162] Such rerouting may be performed across topologies. For example, in the border IAB node 300-B, a packet that has flowed in from a first topology in the UL direction is routed to the first topology, but the packet cannot be transmitted, so the border IAB node 300-B reroutes the packet to a second topology. In this case, the border IAB node 300-B can reroute the packet to the second topology by performing a header rewriting process.

[0163] 15, the boundary IAB node 300-B changes the routing ID through header rewriting processing, thereby 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] 15, if CU#1 is DU#1 and CU#2 is DU#2, the header rewriting process may change the routing ID, thereby changing the destination from DU#1 to DU#2. This type of rerouting across DUs is called inter-DU rerouting (inter-donor-DU re-routing).

[0165] Inter-CU re-routing and inter-DU re-routing may be collectively referred to as "header rewriting based re-routing." Header re-writing based re-routing may include at least one of inter-CU re-routing and inter-DU re-routing.

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

[0167] Header rewriting-based rerouting is performed when a packet cannot be sent despite the routing process being performed, and therefore, header rewriting-based rerouting is performed after the routing process.

[0168] On the other hand, in inter-CU routing, the header is rewritten first, and then the routing process is performed, so that the received packet is sent to a different topology. Therefore, inter-CU routing is performed before the routing process.

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

[0170] Therefore, in a second operation example according to the third embodiment, an example will be described in which a header rewrite table for inter-CU routing and a header rewrite table for header rewrite-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 the boundary IAB node 300-B to distinguish between the two tables when performing header rewriting processing. Specifically, the BAP layer can use the header rewrite table for inter-CU routing when performing inter-CU routing processing before the routing processing, and can use the header rewrite table for header rewrite-based rerouting when performing header rewrite-based rerouting processing after the routing processing. Therefore, the boundary IAB node 300-B can appropriately perform inter-CU routing and header rewrite-based rerouting.

[0173] In the second operation example according to the third embodiment, the header rewrite table for inter-CU routing may be referred to as a "header rewrite table for routing." Also, the header rewrite table for header rewrite-based rerouting may be referred to as a "header rewrite table for rerouting."

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

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

[0176] In step S81, the donor node 200 sets a routing header rewrite table and a rerouting header rewrite table for the border IAB node 300-B so that each table has different classification information. For example, the donor node 200 sets a routing header rewrite table having first classification information and a rerouting header rewrite table having second classification information for the border IAB node 300-B.

[0177] The classification information may be information for two rewrite tables, such as for routing (or for inter-CU routing) and for re-routing (or for header rewrite-based rerouting). In this case, the classification information is linked to each rewrite table. The classification information may also be a name that distinguishes between the two rewrite tables. For example, it may 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 for routing and re-routing may be linked to each entry (for example, an entry consisting of an old routing ID and a new routing ID).

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

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

[0180] In step S83, the BAP layer of the border IAB node 300-B receives a packet (BAP Data PDU) from an upper layer or a 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 that is the same as the routing ID of the packet, performs a header rewrite process for inter-CU routing. The BAP layer can easily identify the routing header rewrite table because the routing header rewrite table contains classification information. However, at this timing, 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 processing and / or rerouting processing. The rerouting processing at this timing is local rerouting processing. That is, the BAP layer has performed routing processing, but returns to step S85 to perform local rerouting processing again.

[0183] In step S86, the BAP layer fails in routing and / or rerouting.

[0184] Here, "routing failed" may mean that a next hop address (Next Hop BAP address) could not be selected under a certain evaluation condition. The evaluation condition may be whether or not the destination and path ID match between the packet header and the routing table (routing configuration). Alternatively, the evaluation condition may be whether or not only the destination matches between the packet header and the routing table.

[0185] In step S87, if the packet is a target for header rewriting-based rerouting, the BAP layer performs header rewriting processing on the packet using the header rewriting table for rerouting. The BAP layer may determine whether the packet is a target for header rewriting-based rerouting. That is, the BAP layer may determine that the packet is a target for header rewriting-based rerouting if the header rewriting table for rerouting contains an old routing ID that matches the routing ID included in the BAP header of the packet. On the other hand, the BAP layer may determine that the packet is not a target for header rewriting-based rerouting if the header rewriting table for rerouting does not contain an old routing ID that matches the routing ID included in the BAP header of the packet. The BAP layer refers to the header rewriting table for rerouting 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 processing or header rewriting-based rerouting processing on the packet.

[0187] In step S89, the border IAB node 300-B transmits the packet to the next hop node according to the routing process or the header rewriting-based rerouting process.

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

[0189] In the third embodiment, a common header rewrite table is used for inter-CU rerouting and inter-DU rerouting. Therefore, in the third embodiment, classification information for classifying 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. The border IAB node 300-B rewrites the header of the packet by inter-CU routing, but fails to route it. Next, the border IAB node 300-B rewrites the header of the packet by inter-DU rerouting, but fails to route it again.

[0191] In both the header rewrite table used for inter-CU routing and the header rewrite table used for header rewrite-based rerouting, it is assumed that the old routing ID included in the entry is the routing ID before the header rewrite.

[0192] However, when the header is rewritten using the header rewrite table, the header of the packet includes the rewritten routing ID. In such a case, 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, an example will be described in which, if routing (or rerouting) fails after the header has been rewritten, the header of the packet is restored to the original routing ID.

[0194] Specifically, first, when a border relay node (e.g., border IAB node 300-B) rewrites the header of a packet using an inter-CU routing header rewrite table and then fails in routing, it restores the rewritten routing ID to the routing ID before rewriting. Second, when a border relay node rewrites the header of a packet using a rerouting header rewrite table and then fails in routing, it restores the rewritten routing ID to the routing ID before rewriting.

[0195] As a result, even if the header is rewritten by header rewriting, if routing fails, the routing ID is restored to the original routing ID, so that the boundary IAB node 300-B can appropriately perform inter-CU routing or header rewrite-based rerouting.

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

[0197] As shown in FIG. 20, in step S100, the BAP layer of the 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 an old routing ID that matches the routing ID of the packet exists in the header rewrite table for routing, the BAP layer performs the header rewrite process. When the BAP layer has performed the header rewrite process, the BAP layer may record (or store) information indicating that the header rewrite process for inter-CU routing has been completed in a memory or the like. Alternatively, the BAP layer may record information indicating that the header rewrite process has been completed in a memory or the like.

[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 the routing fails, it restores the routing ID to the original old routing ID. In this case, the BAP layer may discard (or leave as unprocessed) the rewritten information recorded in memory or the like.

[0201] In step S104, the BAP layer performs header rewriting processing for header rewriting-based rerouting on the packet. At this time, the BAP layer may record information indicating that any of the header rewriting processing for inter-CU rerouting, inter-DU rerouting, and header rewriting-based rerouting has been processed in a memory or the like. Alternatively, the BAP layer may record information indicating that the header rewriting processing has been processed.

[0202] In step S105, the BAP layer fails in the header rewriting based rerouting process.

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

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

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

[0206] (Another operation example according to the fourth embodiment) Next, another operation example according to the fourth embodiment will be described. In the above-described operation example, the header is restored to the original routing ID when routing or rerouting fails after header rewriting. However, the original routing ID may be restored by restoring the packet. Specifically, in step S101, when the BAP layer receives a packet, it stores a copy of the packet in memory. Next, in step S103, if routing fails, the BAP layer discards the packet (with the header rewritten) and obtains a copy of the packet from memory. Also, in step S105, if the header rewriting-based rerouting process fails, the BAP layer discards the packet (with the header rewritten) and obtains a copy of the packet from memory. This allows the border IAB node 300-B to 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 mainly being considered for user data. On the other hand, inter-CU routing is also possible for F1-C (control signal) traffic. For example, the border IAB node 300-B can transmit F1-C packets to the first topology or the second topology by using a CP / UP separation function to encapsulate the F1-C packets in an RRC message and transmitting the RRC message using Split SRB1.

[0208] On the other hand, it is conceivable that the boundary IAB node 300-B may also perform inter-CU routing on user data generated in the node itself (that is, data that the boundary IAB node 300-B receives directly from the UE 100 as an access IAB node).

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

[0210] Generally, the access IAB node creates a BAP header and transmits the packet toward the donor node 200. For example, the access IAB node creates a BAP header as follows.

[0211] That is, the access IAB node receives an uplink traffic mapping configuration from the donor node 200. The uplink traffic mapping configuration includes a traffic type specifier and a BAP routing ID. The uplink traffic mapping configuration is transmitted from the donor node 200 by an F1AP message.

[0212] If the BAP SDU received from the upper layer is FI-U traffic, the BAP layer of the access IAB node selects an entry including a traffic type identifier corresponding to the Destination IP address and TEID (Tunnel Endpoint Identifier) ​​of the BAP SDU from the upstream traffic mapping configuration. On the other hand, if the BAP SDU is not FI-U traffic, the BAP layer selects an entry including the traffic type identifier of the BAP SDU from the upstream traffic mapping configuration.

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

[0214] Here, when performing inter-CU routing at the border IAB node 300-B, which is also an access IAB node, there is the following problem. That is, the current upstream traffic mapping setting basically includes one pair of a traffic type identifier and a BAP routing ID. If this one BAP routing ID is assigned to two topologies, and if the BAP routing ID exists in both topologies, the border IAB node 300-B will not know to which topology the BAP PDU should be sent. As a result, the access IAB node may not be able to perform inter-CU routing appropriately.

[0215] Therefore, in the fifth embodiment, an example will be described in which the border IAB node 300-B, which is also an access IAB node, selects a routing ID associated with a topology based on an upstream traffic mapping setting including information on the topology to which the routing ID is applied.

[0216] Specifically, first, a donor node (e.g., donor node 200) sets an upstream traffic mapping configuration including a topology of a packet destination to a border relay node (e.g., border IAB node 300-B). Second, the border relay node selects a routing ID associated with the topology based on the upstream traffic mapping configuration. Third, the border relay node transmits a packet including the routing ID in its header.

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

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

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

[0220] In step S111, the donor node 200 sets an upstream traffic mapping configuration for the border IAB node 300-B, which is also an access IAB node. The upstream traffic mapping configuration includes information on the topology to be applied (or the topology of the destination) in addition to the existing traffic type identifier and BAP routing ID. Hereinafter, this information may be referred to as topology information.

[0221] That is, the topology information may be an MCG or an SCG. For example, it indicates that the packet destination is an MCG or an SCG. Furthermore, 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 a BAP address set from the first topology and a BAP address set from the second topology. By using the BAP address as the topology information, it is possible to identify whether the topology of the packet destination is the first topology or the second topology. Furthermore, the topology information may be represented by whether the topology terminates F1-AP or does not terminate F1-AP.

[0222] As an option, the upstream traffic mapping configuration may include a bearer ID. The bearer ID indicates 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, different destinations may be assigned to different bearer IDs.

[0223] The topology information and the bearer ID may be included in each entry in the upstream traffic mapping configuration. Alternatively, the topology information and the bearer ID may be configured separately. For example, different (two) upstream traffic mapping configurations may be notified to the border IAB node 300-B for each topology.

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

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

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

[0227] In step S115, the BAP layer selects a 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 a routing setting associated with the identified topology and performs routing processing.

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

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

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

[0233] In addition, circuits that execute each process performed by UE100 or gNB200 may be integrated, and at least a portion of UE100 or gNB200 may be configured as a semiconductor integrated circuit (chip set, 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 the above, and various design changes can be made within the scope of the gist. The above-described embodiments, operation examples, processes, or steps can also be combined within the scope of not causing any contradiction.

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

[0236] This application claims priority to U.S. Provisional Application No. 63 / 296,232 (filed January 4, 2022), the entire contents of which are incorporated herein by reference. (Appendix 1) introduction In RAN2#116e, the work item Integrated Access and Backhaul Enhancements for NR (eIAB) made significant progress on routing and rerouting enhancements, and the agreement was endorsed as an ongoing CR in TS38.340.

[0237] This appendix discusses the details of routing and rerouting, focusing on what is currently considered basic, based on the agreed upon terms and ongoing CR.

[0238] Discussion In Rel-17, as shown in Figure 23, routing and rerouting must cover various scenarios, such as intra-CU / intra-donor-DU (similar to Rel-16), intra-CU / inter-donor-DU, and inter-CU. These enhancements are expected to contribute to the reliability, flexibility, and low latency of packet forwarding in the IAB topology, but may also introduce additional complexity into BAP routing / rerouting operations. Therefore, it is desirable to specify procedures common to all scenarios and minimize scenario-specific procedures as much as possible. In this sense, inter-CU routing, which is the most complex scenario, should be considered first, and then it should also be considered whether the inter-CU routing procedures can be applied (reused) to other scenarios.

[0239] Inter-CU routing Header rewriting decision Further considerations for modeling in RX or Tx operation In the current CR, the decision to rewrite headers is placed on the receiving operation, and the following items that require further consideration have been incorporated:

[0240] It is open to debate whether the decision to rewrite the header should be modeled as an RX operation or a TX operation.

[0241] From a technical perspective, the header rewriting decision can be modeled either in the receive or the transmit operation. However, from a specification perspective, there are two BAP entities in IAB-MT and IAB-DU, i.e., "In an IAB node, the BAP sublayer contains one BAP entity for the MT function and another co-located BAP entity for the DU function." Therefore, functional dependencies between entities must be minimized as much as possible.

[0242] It has been confirmed that the decision to rewrite headers is highly dependent on the sending operation. In fact, the result of the decision to rewrite headers does not affect the receiving operation as follows: In other words, the packet is delivered to the sender regardless of whether the header is rewritten.

[0243] others In the receiver part of the BAP entity in the IAB-DU of the border IAB node, if there is an entry in the header rewrite configuration 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 specified in subclass 5.2.X), or For the receiving part of the BAP entity in the IAB-MT of the border IAB node, if the incoming link is an SCG, Considering BAP data packets for BAP header rewriting, It delivers BAP data packets to the transmitter of the deployed BAP entity.

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

[0245] When there is a BAP Data PDU to transmit, the transmitter of the BAP entity performs the following process.

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

[0247] Routing is performed to determine outgoing links.

[0248] Determine the outgoing BH RLC channel.

[0249] This BAP Data PDU is transmitted to the selected outgoing BH RLC channel of the selected outgoing link.

[0250] Observation 1: The result of header rewriting is independent of receiving behavior, but affects sending behavior.

[0251] In this sense, it is preferable that the header rewriting decision be modeled in the Tx operation. Further consideration is needed as to whether to incorporate it into the BAP header rewriting operation or to create a new section.

[0252] Proposal 1: For inter-CU routing, RAN2 should agree to model the header rewrite decision in the sending behavior.

[0253] Further considerations regarding downstream traffic The details of how to determine the need for header rewriting incorporate another additional consideration of downstream traffic, i.e., "for the receiver of the BAP entity in the IAB-MT of the border IAB node, if the incoming link is an SCG, consider the BAP data packet for BAP header rewriting."

[0254] Further study is needed to determine whether the SCG is sufficient to identify incoming links for inter-topology transition / topology redundancy / RLF recovery, including consideration of the case where the SN is an F1 terminal node.

[0255] As mentioned above, SCG may not be applicable in all cases, e.g., CP / UP split, so it may be simple for the donor side to explicitly indicate which incoming link, i.e., MCG or SCG, requires the header rewriting operation.

[0256] Proposal 2: For inter-CU routing, RAN2 should agree that the donor side configures the IAB-MT on which incoming link, i.e., MCG or SCG, needs to have its BAP header rewritten.

[0257] Header rewriting operations Further considerations regarding header rewriting configuration At RAN2#116e, configuration issues were discussed and the following items were agreed upon as requiring further consideration:

[0258] The details of rewriting the mapping from old routing IDs to new routing IDs and (in the case of all rewrites) limiting the rewrites that are possible require further study.

[0259] Additionally, the following additional considerations have been incorporated into the ongoing CR:

[0260] Based on the R3 agreement, further study will be conducted on whether and how header rewrite configuration differs between UL and DL. For UL traffic, they must indicate the outgoing topology they refer to. That indication may be implicit.

[0261] In the current CR, "when a BAP data PDU is subject to BAP header rewriting, the transmitter of the BAP entity performs the BAP header rewriting operation," i.e., after deciding to rewrite the header, the Tx part performs the header rewriting. In this case, the downstream header rewriting setting is always used in IAB-DU, and the upstream one is only used in IAB-MT. Therefore, it is simpler to define two header rewriting tables and associate them with IAB-DU and IAB-MT, respectively, which is similar to the header rewriting decision operation.

[0262] Proposal 3: For inter-CU routing, the donor side should agree to configure two header rewrite tables used for the Tx part of the BAP entity in IAB-DU (i.e., downstream) and one in IAB-MT (i.e., upstream) at the border IAB node.

[0263] Issues requiring further consideration in header rewriting operations In the currently running CR, header rewriting operations are incorporated at the same level as sending and receiving operations, and the following description is attached:

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

[0265] The header rewrite operation is referenced by the send operation, so it needs to be included under the send operation.

[0266] Proposal 4: RAN2 should agree to define the header rewriting operation under the transmission operation, i.e., in the BAP specification.

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

[0268] Proposal 5: RAN2 should agree that the border IAB node will be configured with two routing tables, managed by the donor CU and another donor CU, respectively.

[0269] If we agree with Proposal 5, it is worth discussing how border IAB nodes select the routing table to apply to traffic during the routing process. In inter-CU scenarios, as shown in Figure 2, there are two categories of traffic: traffic routed within a topology (a.k.a. disjoint traffic, similar to legacy routing) and traffic routed across two topologies (a.k.a. concatenated traffic).

[0270] Considering that routing is performed in the Tx part of the BAP entity, there are three transmission directions (outgoing links) regardless of the receiving source (incoming link), as shown in FIG.

[0271] In the case of Topology #1 in Figure 24, we can see that downstream traffic always follows the legacy routing table, regardless of whether the traffic is concatenated or not, so the border IAB nodes must apply the legacy routing table to route downstream traffic.

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

[0273] For upstream traffic, the applicable routing table varies depending on the topology the packet is sent in. Assuming that the headers of the combined traffic are rewritten before the routing process, as in the current CR, the border IAB node can select the appropriate routing table as follows:

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

[0275] A new routing table (in the case of topology #2 in FIG. 24) is selected for the packet whose header has been rewritten.

[0276] Once the appropriate routing table is selected, the packet is processed according to the existing routing procedures.

[0277] Proposal 7: For upstream packets, RAN2 should agree that the border IAB nodes should select either the legacy routing table or the new routing table depending on whether the packet undergoing routing processing has had its header rewritten.

[0278] Inter-CU rerouting and donor-DU rerouting Conditions for rerouting by header rewriting The currently implemented CR includes the following items that require further study as conditions for rerouting by header rewriting:

[0279] "When a header rewrite table (for rerouting) is set" needs to be corrected to "When 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 is related to whether the header rewrite table for rerouting (= inter-CU rerouting, donor-DU rerouting) is separate from the one for routing (= inter-CU routing). Header rewrite for routing is performed before the routing procedure, and header rewrite for rerouting is performed after the routing procedure. In other words, header rewrite for routing must be performed based on the header rewrite table for routing, and header rewrite for rerouting must be performed based on the header rewrite table for rerouting. If the same header rewrite table is used, the border IAB node 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 for rerouting. Therefore, it is desirable to separate the header rewrite table for rerouting from the header rewrite table for routing.

[0281] Observation 2: The routing header rewrite operation is performed before the routing procedure based on the routing header rewrite configuration, and the rerouting header rewrite operation is performed after the routing procedure based on the rerouting header rewrite configuration.

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

[0283] However, there may be some differences in terms of route-related configuration, since inter-CU rerouting performs RRC restoration towards a different IAB donor, i.e., a different topology, at this point (i.e., transient state), while inter-donor-DU rerouting changes the destination BAP address to a different IAB donor DU within the same topology (i.e., static state). Therefore, this should be left as an issue for further study at this time until further agreement is reached.

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

[0285] Proposal 8: RAN2 should agree that the header rewrite tables for inter-CU rerouting and donor inter-DU rerouting are separate from the table for inter-CU routing. Further study is needed to determine whether a common header rewrite table applies to both rerouting scenarios.

[0286] Rewriting headers before and after selecting outflow links The ongoing CR has included the following items that require further consideration:

[0287] In the case of UL rerouting based on header rewriting in RAN2, the above can be modified if it agrees to perform header rewriting after outgoing link selection.

[0288] The outgoing link selection is assumed to be performed during the routing procedure, and the header rewriting operation is assumed to be performed before the routing procedure, meaning that the outgoing link selection and the header rewriting operation are currently separated. Therefore, mixing these processes would be complicated.

[0289] In addition, in RAN2#116e, within the topology (rerouting between donor DUs), the preconditions for rewriting the BAP header for rerouting are the same as those in Rel-16, that is, there is no condition with the outgoing link selection, and it was agreed as follows:

[0290] In a topology In the upstream case, the prerequisite / criteria for "rerouting by BAP header rewriting" is the same as R16: no available next hop is found based on the BAP Routing ID and based on 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, so the above agreement should be applied to both donor inter-DU rerouting and inter-CU rerouting.

[0292] Proposal 9: RAN2 should agree that outgoing link selection is performed within the routing procedure, as in Rel-16, i.e., header rewriting is performed before outgoing link selection.

[0293] The advantage of selecting an outgoing link before header rewriting is that it avoids the case where packet rerouting fails after header rewriting. In other words, if inter-CU rerouting or inter-donor-DU rerouting fails, it is unclear whether the header of the packet that has undergone header rewriting will be rewritten, that is, how many times the header will be rewritten for one packet. Rewriting the header multiple times may result in the risk of incorrect operation and complexity.

[0294] In this scenario, i.e., if rerouting between CUs or donor DUs fails, it is assumed that the IAB node has no available links due to congestion due to the receipt of flow control feedback. In this case, the packet will be sent via the outflow link that previously recovered from congestion. Therefore, it is desirable for the packet to have either the old routing ID or the new routing ID depending on the recovered outflow link.

[0295] From the above discussion, if rerouting based on header rewriting fails, a method can be considered to change the header from the new routing ID to the old routing ID. In this way, the packet returns to its original state, i.e., the state with the old routing ID in the header, and can be processed from the beginning of the sending operation of the BAP entity. This means that routing is performed again on this packet, and rerouting can be performed if routing fails.

[0296] Proposal 10: RAN2 should discuss whether to restore the header when rerouting based on header rewriting (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, i.e. 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 with an available outgoing link corresponding to the next hop address, Select the outgoing link that corresponds to the next hop address of that entry.

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

[0300] Select the outgoing link that corresponds to the next hop address of the entry selected above.

[0301] In the current implementation of CR, rerouting based on header rewriting follows the same modeling, i.e., Rel-16 rerouting.

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

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

[0304] As mentioned above, Rel-16 routing and Rel-17 header rewriting based rerouting appear to repeat the same sentence, i.e. routing steps, and therefore may be considered candidates for simplification.

[0305] Also, local rerouting in Rel-16 was not clear because the rerouting is done within the routing procedure, so separating the rerouting section from the routing might be a possible option.

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

[0307] Enhancement Summary If the above suggestions can be agreed upon, an example of a unified solution for all scenarios is shown in Figure 25, and an overview of the header rewrite table and routing table is shown in Table 1.

[0308] [Table 1] Overview of configuration enhancements for all scenarios

[0309] (Appendix 2) The features of the above-described embodiment will now be described.

[0310] (1) A communication control method for use in a cellular communication system, comprising: a donor node sending a message regarding routing configuration to a relay node in the topology; performing a first process by the relay node in response to receiving the message. Communication control method.

[0311] (2) The transmitting step includes: transmitting a routing configuration change initiation message to an access relay node in response to the donor node initiating a routing configuration change for the relay node in the topology; transmitting a routing configuration change completion message to the access relay node in response to the donor node completing a routing configuration change for the relay node in the topology; The step of performing the first processing includes: the access relay node retransmitting a packet that was transmitted in the past for a certain period of time in an upstream direction based on the routing setting change start message and the routing setting change completion message; The communication control method according to (1) above.

[0312] (3) The transmitting step includes: the donor node sending a routing stop indication message to the relay node in the topology; The step of performing the first processing includes: the relay node stops routing processing in accordance with the routing stop instruction message and stores the received packet in a memory; Furthermore, the donor node changes the routing setting to the relay node, and transmits mapping information between a routing ID before the change of the routing setting and a routing ID after the change of the routing setting to the relay node; the relay node restarting the routing process, rewriting the header of the packet stored in the memory in accordance with the mapping information, and transmitting the packet. The communication control method according to (1) above.

[0313] (4) A communication control method for use in a cellular communication system, comprising: a step of the donor node transmitting designation information designating a downstream link to a border relay node; the boundary relay node performing a header rewriting process on the packet that has flowed in from the downstream link in accordance with the designation information, Communication control method.

[0314] (5) A communication control method for use in a cellular communication system, comprising: A step in which the donor node sets a first header rewrite table having first classification information and a second header rewrite table having second classification information for the border relay node; the border relay node performing a header rewrite process on the packet using at least one of the first header rewrite table and the second header rewrite table, Communication control method.

[0315] (6) The first header rewriting table is a header rewriting table for first inter-CU routing used in a user equipment function unit (IAB-MT) of the boundary relay node, and the second header rewriting table is a header rewriting table for second inter-CU routing used in a base station function unit (IAB-DU) of the boundary relay node. The step of performing the header rewriting process includes a step in which the user equipment function unit rewrites the header of the packet by referring to the first inter-CU routing header rewrite table, and the base station function unit rewrites the header of the packet by referring to the second inter-CU routing header rewrite table. The communication control method according to (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 according to (5) above.

[0317] (8) The step of performing the header rewriting process includes: a step of restoring the rewritten routing ID to the routing ID before rewriting when routing fails after the boundary relay node rewrites the header of the packet using the inter-CU routing header rewrite table; and when routing fails after the border relay node has rewritten the header of the packet using the header rewriting table for rerouting, returning the rewritten routing ID to the routing ID before rewriting. The communication control method according to (7) above.

[0318] (9) A communication control method for use in a cellular communication system, comprising: A donor node configures an upstream traffic mapping configuration including a topology of packet destinations to a border relay node; the border relay node selecting a routing ID associated with the topology based on the upstream traffic mapping configuration; The border relay node transmits the packet including the routing ID in a header. Communication control method.

Claims

1. A communication control method for use in a cellular communication system, comprising: a border relay node receiving configuration information regarding an incoming link from a network; The border relay node identifies a topology corresponding to the incoming link based on the setting information; When the topology corresponding to the inflow link is a topology to be rewritten, the boundary relay node performs a header rewriting process on the packet that has flowed in from the inflow link based on header rewriting setting information received from the network. Communication control method.

2. The packet received from the inflow link is a packet transmitted in the downstream direction. The communication control method according to claim 1.

3. A border relay node, a receiving unit that receives configuration information regarding incoming links from a network; a control unit that identifies a topology corresponding to the incoming link based on the setting information, When the topology corresponding to the incoming link is a topology to be subjected to header rewriting, the control unit performs a header rewriting process on the packet that has flowed in from the incoming link based on header rewriting setting information received from the network. Border relay node.

4. A chipset for a border relay node, receiving configuration information from a network regarding incoming links; Identifying a topology corresponding to the incoming link based on the setting information; When the topology corresponding to the incoming link is a topology to be subjected to header rewriting, performing a header rewriting process on the packet that has flowed in from the incoming link based on header rewriting setting information received from the network. Chipset.

5. 1. A cellular communication system having a first donor node, a second donor node, and a border relay node, The border relay node receives configuration information regarding an incoming link from a network; The border relay node identifies a topology corresponding to the incoming link based on the setting information; When the topology corresponding to the inflow link is a topology to be subjected to header rewriting, the border relay node performs a header rewriting process on the packet that has flowed in from the inflow link based on the header rewriting setting information received from the network. Cellular communication systems.

6. At the boundary relay node of the cellular communication system, receiving configuration information about incoming links from a network; A process of identifying a topology corresponding to the incoming link based on the setting information; and if the topology corresponding to the incoming link is a topology to be subjected to header rewriting, a process of performing a header rewriting process on the packets that have flowed in from the incoming link based on the header rewriting setting information received from the network is executed. program.

Images