Communication control method
The communication control method addresses the challenges of packet transfer and rerouting in cellular communication systems by enabling relay nodes to perform inter-topology routing and local rerouting through BAP header rewriting and alternative routing ID settings, resulting in enhanced system resilience and performance.
Patent Information
- Application Number
- JP2024221266
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2021-08-03
- Filing Date
- 2024-12-18
- Publication Date
- 2025-03-18
AI Technical Summary
In cellular communication systems, existing technologies face challenges in efficiently managing packet transfer and rerouting in scenarios involving relay nodes, particularly when inter-topology routing and local rerouting are required.
The proposed communication control method involves sending information about BAP header rewriting support from the relay node to the donor node, setting inter-topology routing and alternative routing IDs, and performing local rerouting using these settings to ensure efficient packet forwarding.
This method enables efficient packet transfer control by allowing relay nodes to perform inter-topology routing and local rerouting effectively, thereby improving communication system resilience and performance.
Smart Images

Figure 2025038129000001_ABST
Abstract
Description
[Technical field]
[0001] The present invention relates to a communication control method for use in a cellular communication system. [Background technology]
[0002] In 3GPP (Third Generation Partnership Project) (registered trademark, hereinafter the same), a standardization project for cellular communication systems, the introduction of a new relay node called an IAB (Integrated Access and Backhaul) node is being considered. One or more relay nodes are involved in communication between a base station and a user device, and relay this communication. [Prior art documents] [Non-patent literature]
[0003] [Non-Patent Document 1] 3GPP TS 38.300 V16.6.0 (2021-06) Summary of the Invention
[0004] A communication control method according to a first aspect is a communication control method for use in a cellular communication system, the communication control method including the steps of: a relay node transmitting information indicating that the relay node supports a BAP (Backhaul Adaptation Protocol) header rewriting function to a donor node; the donor node configuring the relay node for inter-topology routing; and the relay node forwarding a data packet in accordance with the configuration for the inter-topology routing.
[0005] 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 donor node setting an alternative routing ID associated with a routing ID in a relay node. The communication control method also includes the relay node determining to perform local rerouting to forward a data packet to an alternative path. The communication control method further includes the relay node receiving a data packet from another relay node. The communication control method also includes, when the relay node is unable to use the alternative routing ID, performing local rerouting using another routing ID including a destination address matching a destination address included in the data packet.
[0006] A communication control method according to a third aspect is a communication control method for use in a cellular communication system. The communication control method includes a donor node setting a plurality of alternative routing IDs in a relay node. The communication control method also includes the relay node determining to perform local rerouting to forward a data packet to an alternative path. The communication control method further includes the relay node receiving a data packet from another relay node. The communication control method also includes the relay node performing local rerouting using any of the plurality of alternative routing IDs. [Brief description of the drawings]
[0007] [Figure 1] FIG. 1 is a diagram showing an example of the configuration of a cellular communication system according to an embodiment. [Diagram 2] FIG. 2 is a diagram showing the relationship between IAB nodes, parent nodes, and child nodes. [Diagram 3] FIG. 3 is a diagram showing an example configuration of a gNB (base station) according to one embodiment. [Figure 4] FIG. 4 is a diagram illustrating a configuration example of an IAB node (relay node) according to an embodiment. [Diagram 5] FIG. 5 is a diagram illustrating a configuration example of a UE (user equipment) according to an embodiment. [Figure 6] FIG. 6 is a diagram showing an example of a protocol stack related to an RRC connection and a NAS connection of an IAB-MT. [Figure 7] FIG. 7 is a diagram showing an example of a protocol stack related to the F1-U protocol. [Figure 8] FIG. 8 is a diagram showing an example of a protocol stack for the F1-C protocol. [Figure 9] FIG. 9 is a diagram illustrating an example of inter-topology routing according to the first embodiment. [Figure 10] FIG. 10 is a diagram illustrating an example of operation according to the first embodiment. [Figure 11] FIG. 11 is a diagram illustrating an example of operation according to the second embodiment. [Figure 12] FIG. 12 is a diagram illustrating an example of operation according to the third embodiment. [Figure 13] FIG. 13 is a diagram illustrating an example of a relationship between IAB nodes according to the fourth embodiment. [Figure 14] FIG. 14 is a diagram illustrating an example of operation according to the fourth embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0008] An object of the present disclosure is to provide a communication control method for appropriately controlling packet forwarding.
[0009] 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.
[0010] (Configuration of Cellular Communication System) A configuration example of a cellular communication system according to an embodiment will be described. The cellular communication system 1 according to an embodiment is a 3GPP 5G system. Specifically, the radio access method in the cellular communication system 1 is NR (New Radio), which is a 5G radio access method. However, LTE (Long Term Evolution) may be applied at least partially to the cellular communication system 1. Furthermore, the cellular communication system 1 may also be applied to future cellular communication systems such as 6G.
[0011] FIG. 1 is a diagram showing an example of the configuration of a cellular communication system 1 according to an embodiment.
[0012] As shown in Fig. 1, the cellular communication system 1 includes a 5G core network (5GC) 10, a user equipment (UE: User Equipment) 100, base station devices (hereinafter, sometimes referred to as "base stations") 200-1 and 200-2, and IAB nodes 300-1 and 300-2. The base station 200 may be referred to as a gNB.
[0013] 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).
[0014] 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.
[0015] The 5GC 10 has an Access and Mobility Management Function (AMF) 11 and a User Plane Function (UPF) 12. The AMF 11 is a device that performs various mobility controls for the UE 100. The AMF 11 manages information on the area in which the UE 100 is located by communicating with the UE 100 using Non-Access Stratum (NAS) signaling. The UPF 12 is a device that performs transfer control of user data.
[0016] Each gNB 200 is a fixed wireless communication node and manages one or more cells. A cell is used as a term indicating the smallest unit of a wireless communication area. A cell may be used as a term indicating a function or resource for performing wireless communication with a UE 100. One cell belongs to one carrier frequency. In the following, a cell and a base station may be used without distinction.
[0017] Each gNB 200 is mutually connected to the 5GC 10 via an interface called an NG interface. In FIG. 1, two gNBs 200-1 and 200-2 connected to the 5GC 10 are illustrated.
[0018] Each gNB 200 may be divided into a central unit (CU) and a distributed unit (DU). The CU and the DU are connected to each other via an interface called an F1 interface. The F1 protocol is a communication protocol between the CU and the DU, and includes an F1-C protocol, which is a control plane protocol, and an F1-U protocol, which is a user plane protocol.
[0019] The cellular communication system 1 supports IAB, which enables wireless relay of NR access using NR for backhaul. The donor gNB 200-1 (or donor node, hereinafter sometimes referred to as "donor node") is a terminal node of the NR backhaul on the network side, and is a donor base station with additional functions that support IAB. The backhaul can be multi-hopped via multiple hops (i.e., multiple IAB nodes 300).
[0020] FIG. 1 illustrates an example in which IAB node 300-1 wirelessly connects to donor node 200-1, IAB node 300-2 wirelessly connects to IAB node 300-1, and the F1 protocol is transmitted over two backhaul hops.
[0021] The UE 100 is a mobile wireless communication device that performs wireless communication with a cell. The UE 100 may be any device that performs wireless communication with the gNB 200 or the IAB node 300. For example, the UE 100 is a mobile phone terminal, a tablet terminal, a laptop computer, a sensor or a device provided in a sensor, a vehicle or a device provided in a vehicle, or an aircraft or a device provided in an aircraft. The UE 100 wirelessly connects to the IAB node 300 or the gNB 200 via an access link. FIG. 1 shows an example in which the UE 100 is wirelessly connected to the IAB node 300-2. The UE 100 indirectly communicates with the donor node 200-1 via the IAB node 300-2 and the IAB node 300-1.
[0022] FIG. 2 is a diagram showing an example of the relationship between an IAB node 300, parent nodes, and child nodes.
[0023] 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.
[0024] An adjacent node (i.e., an upper node) on the NR Uu radio interface of the IAB-MT is called a parent node. The parent node is a DU of the parent IAB node or the donor node 200. The radio link between the IAB-MT and the parent node is called a backhaul link (BH link). FIG. 2 shows an example in which the parent nodes of the IAB node 300 are IAB nodes 300-P1 and 300-P2. The direction toward the parent node is called upstream. From the perspective of the UE 100, the upper node of the UE 100 may correspond to the parent node.
[0025] Adjacent nodes (i.e., lower nodes) on the NR access interface of the IAB-DU are called child nodes. The IAB-DU manages cells, similar to the gNB 200. The IAB-DU terminates the NR Uu radio interface to the UE 100 and the lower IAB nodes. The IAB-DU supports the F1 protocol to the CU of the donor node 200-1. In FIG. 2, an example is shown in which the child nodes of the IAB node 300 are the IAB nodes 300-C1 to 300-C3, but the child nodes of the IAB node 300 may include the UE 100. The direction toward the child nodes is called downstream.
[0026] (Base station configuration) Next, a configuration of the gNB 200 which is a base station according to the embodiment will be described. Fig. 3 is a diagram showing an example of the configuration of the gNB 200. As shown in Fig. 3, the gNB 200 has a wireless communication unit 210, a network communication unit 220, and a control unit 230.
[0027] The wireless communication unit 210 performs wireless communication with the UE 100 and wireless communication with the IAB node 300. The wireless communication unit 210 has a receiving unit 211 and a transmitting unit 212. The receiving unit 211 performs various receptions under the control of the control unit 230. The receiving unit 211 includes an antenna, and converts (down-converts) a wireless signal received by the antenna into a baseband signal (received signal) and outputs the signal to the control unit 230. The transmitting unit 212 performs various transmissions under the control of the control unit 230. The transmitting unit 212 includes an antenna, and converts (up-converts) a baseband signal (transmitted signal) output by the control unit 230 into a wireless signal and transmits the signal from the antenna.
[0028] The network communication unit 220 performs wired communication (or wireless communication) with the 5GC10 and wired communication (or wireless communication) with other adjacent gNBs 200. The network communication unit 220 has a receiving unit 221 and a transmitting unit 222. The receiving unit 221 performs various receptions under the control of the control unit 230. The receiving unit 221 receives a signal from the outside and outputs the received signal to the control unit 230. The transmitting unit 222 performs various transmissions under the control of the control unit 230. The transmitting unit 222 transmits the transmission signal output by the control unit 230 to the outside.
[0029] The control unit 230 performs various controls in the gNB 200. The control unit 230 includes at least one memory and at least one processor electrically connected to the memory. The memory stores programs executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of baseband signals. The CPU executes programs stored in the memory to perform various processing. The processor performs processing of each layer, which will be described later. In addition, the control unit 230 may perform each processing or each operation in the gNB 200 in each embodiment.
[0030] (Configuration of relay node) Next, the configuration of the IAB node 300, which is a relay node (or relay node device, hereinafter sometimes referred to as a "relay node") according to the embodiment, will be described. FIG. 4 is a diagram showing an example of the configuration of the IAB node 300. As shown in FIG. 4, the IAB node 300 has a wireless communication unit 310 and a control unit 320. The IAB node 300 may have multiple wireless communication units 310.
[0031] 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.
[0032] The wireless communication unit 310 has a receiving unit 311 and a transmitting unit 312. The receiving unit 311 performs various receptions under the control of the control unit 320. The receiving unit 311 includes an antenna, and converts (down-converts) a wireless signal received by the antenna into a baseband signal (received signal), and outputs the signal to the control unit 320. The transmitting unit 312 performs various transmissions under the control of the control unit 320. The transmitting unit 312 includes an antenna, and converts (up-converts) a baseband signal (transmitted signal) output by the control unit 320 into a wireless signal, and transmits the signal from the antenna.
[0033] The control unit 320 performs various controls in the IAB node 300. The control unit 320 includes at least one memory and at least one processor electrically connected to the memory. The memory stores a program executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of a baseband signal. The CPU executes a program stored in the memory to perform various processing. The processor performs processing of each layer, which will be described later. In addition, the control unit 320 may perform each processing or each operation in the IAB node 300 in each embodiment.
[0034] (Configuration of user device) Next, a configuration of the UE 100 which is a user device according to the embodiment will be described. Fig. 5 is a diagram showing an example of the configuration of the UE 100. As shown in Fig. 5, the UE 100 includes a radio communication unit 110 and a control unit 120.
[0035] The wireless communication unit 110 performs wireless communication in an access link, that is, wireless communication with the gNB 200 and wireless communication with the IAB node 300. The wireless communication unit 110 may also perform wireless communication in a side link, that is, wireless communication with another UE 100. The wireless communication unit 110 has a receiving unit 111 and a transmitting unit 112. The receiving unit 111 performs various receptions under the control of the control unit 120. The receiving unit 111 includes an antenna, and converts (down-converts) a wireless signal received by the antenna into a baseband signal (received signal) and outputs the signal to the control unit 120. The transmitting unit 112 performs various transmissions under the control of the control unit 120. The transmitting unit 112 includes an antenna, and converts (up-converts) a baseband signal (transmitted signal) output by the control unit 120 into a wireless signal and transmits the signal from the antenna.
[0036] The control unit 120 performs various controls in the UE 100. The control unit 120 includes at least one memory and at least one processor electrically connected to the memory. The memory stores a program executed by the processor and information used in the processing by the processor. The processor may include a baseband processor and a CPU. The baseband processor performs modulation / demodulation and encoding / decoding of a baseband signal. The CPU executes a program stored in the memory to perform various processing. The processor performs processing of each layer, which will be described later. The control unit 130 may perform each processing in the UE 100 in each of the following embodiments.
[0037] (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.
[0038] 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.
[0039] The PHY layer performs encoding / decoding, modulation / demodulation, antenna mapping / demapping, and resource mapping / demapping. Data and control information are transmitted between the PHY layer of the IAB-MT of the IAB node 300-2 and the PHY layer of the IAB-DU of the IAB node 300-1 via a physical channel.
[0040] The MAC layer performs data priority control, retransmission processing using hybrid ARQ (HARQ), random access procedures, etc. Data and control information are transmitted between the MAC layer of the IAB-MT of IAB node 300-2 and the MAC layer of the IAB-DU of IAB node 300-1 via a transport channel. The MAC layer of the IAB-DU includes a scheduler. The scheduler determines the transport format (transport block size, modulation and coding scheme (MCS)) and the assigned resource blocks for uplink and downlink.
[0041] The RLC layer transmits data to the RLC layer on the receiving side by utilizing the functions of the MAC layer and the PHY layer. Data and control information are transmitted between the RLC layer of the IAB-MT of the IAB node 300-2 and the RLC layer of the IAB-DU of the IAB node 300-1 via a logical channel.
[0042] 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.
[0043] The RRC layer controls logical channels, transport channels, and physical channels according to the establishment, re-establishment, and release of radio bearers. RRC signaling for various settings is transmitted between the RRC layer of the IAB-MT of the IAB node 300-2 and the RRC layer of the donor node 200. When there is an RRC connection with the donor node 200, the IAB-MT is in an RRC connected state. When there is no RRC connection with the donor node 200, the IAB-MT is in an RRC idle state.
[0044] The NAS layer, which is located above the RRC layer, performs session management, mobility management, etc. NAS signaling is transmitted between the NAS layer of the IAB-MT of the IAB node 300-2 and the AMF 11.
[0045] Fig. 7 is a diagram showing a protocol stack for the F1-U protocol. Fig. 8 is a diagram showing a protocol stack for the F1-C protocol. Here, an example is shown in which the donor node 200 is divided into a CU and a DU.
[0046] As shown in Fig. 7, each of the IAB-MT of the IAB node 300-2, the IAB-DU of the IAB node 300-1, the IAB-MT of the IAB node 300-1, and the DU of the donor node 200 has a BAP (Backhaul Adaptation Protocol) layer as a layer above the RLC layer. The BAP layer is a layer that performs routing processing and bearer mapping / demapping processing. In the backhaul, the IP layer is transmitted through the BAP layer, enabling routing in multiple hops.
[0047] In each backhaul link, PDUs (Protocol Data Units) of the BAP layer are transmitted by a backhaul RLC channel (BH NR RLC channel). By configuring multiple backhaul RLC channels in each BH link, traffic prioritization and QoS control are possible. The association between BAP PDUs and backhaul RLC channels is performed by the BAP layer of each IAB node 300 and the BAP layer of the donor node 200.
[0048] 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.
[0049] In the following, the processing or operation performed by the IAB-DU and IAB-MT of the IAB may be simply described as the processing or operation of the "IAB". For example, the transmission of a BAP layer message by the IAB-DU of the IAB node 300-1 to the IAB-MT of the IAB node 300-2 will be described as the IAB node 300-1 transmitting the message to the IAB node 300-2. In addition, the processing or operation of the DU or CU of the donor node 200 may be simply described as the processing or operation of the "donor node".
[0050] 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.
[0051] [First embodiment] Next, a first embodiment will be described.
[0052] First, routing, local rerouting, and inter-topology routing in the first embodiment will be described.
[0053] (About routing) Routing in the IAB node 300 will now be described.
[0054] One of the functions of the BAP layer is the function of routing packets to the next hop. In a network formed by multiple IAB nodes 300, each IAB node 300 can forward a received packet to the next hop, ultimately causing the packet to be transmitted to the destination IAB node 300 (or the donor node 200). Routing is, for example, controlling to which IAB node 300 a received packet is forwarded.
[0055] For example, the routing of a packet is performed as follows. That is, the IAB-CU of the donor node 200 provides a routing setting to the IAB-DU of each IAB node 300. The provided routing setting includes a routing ID and a BAP address of the next hop. The routing ID is composed of a destination BAP address (Destination) and a path ID (Path ID). When each IAB node 300 receives a packet (BAP packet), it extracts the routing ID included in the header of the packet and obtains the destination BAP address from the extracted routing ID. Each IAB node 300 judges whether the destination BAP address matches the BAP address of its own IAB node 300. When the destination BAP address matches its own BAP address, each IAB node 300 judges that the data packet has reached the destination. On the other hand, when the destination BAP address does not match its own BAP address, each IAB node 300 transfers the packet to the IAB node 300 of the BAP address of the next hop according to the routing setting.
[0056] In this way, each IAB node 300 forwards the received BAP packet to the next hop according to the routing settings set by the donor node 200, and transmits the packet to the destination BAP address.
[0057] (About local rerouting) Next, local rerouting will be described.
[0058] In a network made up of a plurality of IAB nodes 300, a backhaul radio link failure (BH RLF) may occur in a backhaul link between the IAB nodes 300. The BH RLF is one type of line failure.
[0059] In a multi-hop network in which a packet is transferred one after another by a plurality of IAB nodes 300, a data packet can be transferred to a destination IAB node 300 (or a donor node 200) via an alternative path. Even if a line failure occurs, if there is an alternative path to the same destination IAB node 300, it is possible to send a data packet to the destination IAB node by avoiding the path where the line failure occurred. Transferring a data packet using an alternative path is sometimes called local rerouting. Local rerouting is performed by selecting an alternative path while ignoring the routing setting set by the donor node 200. Alternatively, local rerouting may be performed by selecting an alternative path from alternative path candidates set by the donor node 200.
[0060] The IAB node 300 performs local rerouting, for example, as follows. That is, the IAB node 300 receives a data packet (BAP packet) from another IAB node. The IAB node 300 extracts a routing ID from the BAP header of the received BAP packet. The IAB node 300 extracts a destination BAP address (Destination) from the routing ID. The IAB node 300 selects another routing ID that includes the same BAP address as the destination BAP address. The other routing ID is set in advance in the IAB node 300 by the donor node 200. The IAB node 300 transmits (transfers) the received BAP packet to the destination BAP using the selected other routing ID.
[0061] When the donor node 200 sets an alternative path, local rerouting is performed, for example, as follows. That is, the donor node 200 sets the routing ID of the alternative path used in local rerouting in the IAB node 300. The IAB node 300 extracts the routing ID from the BAP packet to be locally rerouted, and selects the routing ID of the alternative path corresponding to the extracted routing ID. The IAB node 300 forwards the packet using the routing ID of the selected alternative path.
[0062] Hereinafter, the routing ID of the alternative path set by the donor node 200 for local rerouting will be referred to as an alternative routing ID. Like the routing ID, the alternative routing ID is also composed of a destination BAP address and a path ID.
[0063] The IAB node 300 in which the alternative routing ID is set can execute local rerouting using the alternative routing ID corresponding to the routing ID of the BAP packet without checking the destination BAP address included in the routing ID of the BAP packet. Therefore, the IAB node 300 can suppress delays and reduce processing load.
[0064] (Inter-Topology Routing) Next, inter-topology routing will be described.
[0065] FIG. 9 is a diagram illustrating an example of inter-topology routing according to the first embodiment.
[0066] All IAB nodes 300 connected to the donor node 200 via one or more hops form a directed acyclic graph (DAG) topology (hereinafter, may be referred to as a "topology") with the donor node 200 as the root. One topology includes one donor node 200. FIG. 9 shows an example in which a topology TP1 with the donor node 200-1 as the root and a topology TP2 with the donor node 200-2 as the root are formed.
[0067] For example, assume that an RLF occurs in the IAB node 300 in topology TP1. In this case, service may be restored more quickly by forwarding packets to a destination node in another topology TP2, avoiding the path where the RLF occurred. Also, for load balancing between topologies TP1 and TP2, for example, the communication load of topology TP1 may be reduced by forwarding packets generated in topology TP1 via topology TP2.
[0068] Therefore, packet forwarding control may be performed by inter-topology routing, which is the control of packet forwarding from one topology TP1 to another topology TP2.
[0069] As described above, the BAP header of the BAP packet (BAP PDU) includes a routing ID. The routing ID is basically set by the donor node 200. Therefore, the routing ID is used within the topology of the donor node 200.
[0070] When inter-topology routing is performed, the topology (or the donor node 200) is changed. Therefore, the routing ID is changed. In other words, the destination BAP address (Destination) and the path ID are changed by inter-topology routing.
[0071] In the IAB node 300, the routing ID can be changed by rewriting the routing ID included in the BAP header of the BAP packet to the changed routing ID. Rewriting the routing ID included in the BAP header to the changed routing ID is sometimes called BAP header rewriting. The IAB node 300 has a BAP header rewriting function, so it is possible to rewrite the routing ID.
[0072] The BAP header rewriting may be performed by the IAB node 300 located at the boundary with another topology. The IAB node 300 located at the boundary of a topology may be called a boundary IAB node. FIG. 9 shows an example in which the IAB node 300-B has a BAP header rewriting function as a boundary IAB node. FIG. 9 shows an example in which the IAB node 300-B transmits (transfers) a BAP packet in which the routing ID has been rewritten by the BAP header rewriting function to a destination node in another topology TP2.
[0073] Note that the BAP header rewriting may also be performed in local rerouting. That is, in local rerouting, a routing ID different from the routing ID included in the target BAP packet is used. Therefore, when performing local rerouting, the IAB node 300 can rewrite the BAP header and transfer the BAP packet including the changed routing ID.
[0074] (Communication control method according to the first embodiment) When inter-topology routing is performed, the donor node 200-1 needs to perform settings related to inter-topology routing for the IAB node 300-B in the topology TP1.
[0075] However, if the IAB node 300-B to be configured does not have a BAP header rewriting function, the donor node 200-1 may not be able to efficiently configure the IAB node 300-B regarding inter-topology routing.
[0076] Therefore, in the first embodiment, the IAB node 300-B transmits, to the donor node 200-1, information indicating whether or not the IAB node 300-B has a BAP header rewriting function.
[0077] Specifically, first, a relay node (e.g., IAB node 300-B) transmits information indicating that it supports the BAP header rewriting function to a donor node (e.g., donor node 200-1). Second, the donor node performs a predetermined setting on the relay node. Third, the relay node forwards the data packet in accordance with the predetermined setting. Here, the predetermined setting is at least one of a setting related to inter-topology routing for forwarding data packets between topologies and a setting related to local rerouting for forwarding data packets to an alternative path.
[0078] In this way, the donor node 200-1 can receive information indicating that the IAB node 300-B supports the BAP header rewriting function. Therefore, the donor node 200-1 can efficiently perform at least one of the settings related to inter-topology routing and the settings related to local rerouting for the IAB node 300-B. Therefore, it becomes possible to efficiently perform packet forwarding control.
[0079] (Operation example according to the first embodiment) FIG. 10 is a diagram illustrating an example of operation according to the first embodiment.
[0080] As shown in FIG. 10, in step S10, the IAB node 300-B starts the process.
[0081] In step S11, the IAB node 300-B transmits information indicating that the IAB node 300-B supports the BAP header rewriting function to the donor node 200-1. The IAB node 300-B may transmit information indicating whether the IAB node 300-B supports the BAP header rewriting function to the donor node 200-1.
[0082] The IAB-MT of the IAB node 300-B may include the information in an RRC message such as a UE Capability Information message or a UE Assistance Information message and transmit the information to the CU of the donor node 200-1. Alternatively, the IAB-DU of the IAB node 300-B may transmit an F1AP message including the information to the CU of the donor node 200-1.
[0083] In step S12, upon receiving the information, the donor node 200-1 performs a predetermined setting for the IAB node 300-B. Here, the predetermined setting is at least one of (A1) a setting related to inter-topology routing and (A2) a setting related to local rerouting.
[0084] (A1) The settings for inter-topology routing are, for example, as follows:
[0085] That is, first, the donor node 200-1 sets a dual connectivity (DC) method for the IAB node 300-B, with the donor node 200-1 as the master node and the donor node 200-2 of the other topology TP2 as the secondary node. This allows the IAB node 300-B to be directly connected to the donor node 200-2, and therefore can become a boundary IAB node located at the boundary of the topology TP1. In addition, the IAB node 300-B can also secure an alternative path.
[0086] Secondly, the donor node 200-1 sets an inter-topology routing table for the IAB node 300-1. The inter-topology routing table may include a routing ID in the own topology TP1 and a routing ID in another topology TP2 corresponding to the routing ID. Alternatively, the inter-topology routing table may not include a routing ID in the own topology TP1, but may include a routing ID in the other topology TP2. The IAB node 300-B can use the routing table to obtain a routing ID to the other topology TP2 and execute the BAP header rewriting function.
[0087] (A2) The settings for local rerouting are, for example, as follows:
[0088] That is, first, the donor node 200-1 may perform DC setting for the IAB node 300-B. The DC setting may be DC setting between the donor node 200-1 and the IAB node in the topology TP1. Or, the DC setting may be DC setting between the IAB node in the own topology TP1 and the IAB node (or the donor node 200-2) of the other topology TP2. In either case, the donor node 200-1 can set an alternative path for local rerouting by DC setting.
[0089] Secondly, the donor node 200-1 sets an alternative routing ID for the IAB node 300-B. At this time, the donor node 200-1 sets an alternative routing ID associated with each routing ID. This enables the IAB node 300-B to execute local rerouting for a BAP packet to be locally rerouted, using an alternative routing ID corresponding to the routing ID extracted from the BAP packet.
[0090] In step S13, the IAB node 300-B executes at least one of inter-topology routing and local rerouting according to a predetermined setting. The IAB node 300-B rewrites the routing ID included in the BAP header of the BAP packet to be subjected to inter-topology routing based on the inter-topology routing table. Then, the IAB node 300-B transmits the rewritten BAP packet to the donor node 200-2. Also, the IAB node 300-B rewrites the routing ID included in the BAP header of the BAP packet to be subjected to local rerouting to an alternative routing ID. Then, the IAB node 300-B transmits the rewritten BAP packet using an alternative path.
[0091] Then, in step S14, the IAB node 300-B ends the series of processes.
[0092] [Second embodiment] Next, a second embodiment will be described.
[0093] As described above, in the local rerouting operation, the IAB node 300 may extract a routing ID from the BAP header and select another routing ID that is the same as the destination BAP address (Destination) included in the routing ID.
[0094] As described above, in the local rerouting operation, the IAB node 300 may operate using an alternative routing ID set by the donor node 200.
[0095] Currently, the latter case is being considered in 3GPP. Regarding the operation of local rerouting, the former operation is sometimes referred to as "Rel-16 operation" and the latter operation is sometimes referred to as "Rel-17 operation."
[0096] In the second embodiment, the IAB node 300-B performs local rerouting by Rel-17 operation, but falls back to Rel-16 operation if an alternative routing ID is unavailable.
[0097] Specifically, first, a donor node (e.g., donor node 200) sets an alternative routing ID associated with the routing ID in a relay node (e.g., IAB node 300). Second, the relay node decides to perform local rerouting to forward the data packet to an alternative path. Third, the relay node receives a data packet from another relay node. Fourth, if the relay node cannot use the alternative routing ID, it performs local rerouting using another routing ID that includes a destination address that matches the destination address included in the data packet.
[0098] As a result, even if the IAB node 300 cannot use an alternative routing ID, it is possible to perform local rerouting by performing Rel-16 operations, thereby enabling efficient packet forwarding control.
[0099] (Operation example according to the second embodiment) FIG. 11 is a diagram illustrating an example of operation according to the second embodiment.
[0100] As shown in FIG. 11, in step S20, the donor node 200 starts the process.
[0101] In step S21, the donor node 200 sets an alternative routing ID to the IAB node 300. The donor node 200 sets the alternative routing ID in association with (or in correspondence with) a routing ID that is a target of local rerouting. The donor node 200 sets an alternative routing ID for each routing ID that is a target of local rerouting.
[0102] The CU of the donor node 200 may perform the setting by transmitting an F1AP message including information on the setting to the IAB-DU of the IAB node 300. The CU of the donor node 200 may perform the setting by transmitting an RRC message including information on the setting to the IAB-MT of the IAB node 300.
[0103] In step S22, when the IAB node 300 detects a predetermined condition, it decides to execute local rerouting. The predetermined condition includes a predetermined condition in the upstream of the IAB node 300 and a predetermined condition in the downstream of the IAB node 300.
[0104] The predetermined condition upstream is one of detection of a BH RLF, reception of a Type 4 BH RLF Indication, reception of a Type 2 BH RLF Indication, and reception of UL flow control feedback.
[0105] The BH RLF is one of the line failures that the IAB-MT of the IAB node 300 detects on the backhaul link. The Type 4 BH RLF Indication is a failure notification indicating that recovery from the BH RLF has failed. The Type 2 BH RLF Indication is a failure occurrence notification indicating that recovery from the BH RLF is being attempted. The UL flow control feedback is flow control feedback that is planned to be introduced in Rel-17, and is flow control feedback that the IAB node 300 transmits to child nodes.
[0106] On the other hand, the predetermined condition in the downstream is either reception of DL flow control feedback or any communication abnormality.
[0107] The DL flow control feedback is flow control feedback that the IAB-MT of the IAB node 300 sends to the parent node of the IAB node 300 when the buffer load of the IAB node 300 exceeds a certain threshold.
[0108] When the IAB node 300 detects any of the predetermined conditions, it decides to perform local rerouting.
[0109] In step S23, the IAB node 300 determines whether the alternative routing ID set by the donor node 200 is available. For example, when there is a route (or a path, or a link) that does not meet any of the predetermined conditions in step S22, the IAB node 300 may determine that the alternative routing ID corresponding to the route is available.
[0110] Furthermore, when an alternative route set from the donor node 200 exists, the IAB node 300 may determine that the alternative routing ID corresponding to the route is available.
[0111] Furthermore, if (a part or all of) the alternative route set from the donor node 200 detects one or more of the specified conditions in step S22, the IAB node 300 may determine that the alternative routing ID corresponding to the route is unusable.
[0112] Furthermore, if an alternative route is not set from the donor node 200, the IAB node 300 may determine that the alternative routing ID corresponding to the route is unavailable.
[0113] If the IAB node 300 determines in step S23 that the alternative routing ID is available (YES in step S23), the process proceeds to step S24. On the other hand, if the IAB node 300 determines in step S23 that the alternative routing ID is unavailable (NO in step S23), the process proceeds to step S26.
[0114] In step S24, the IAB node 300 executes local rerouting using the alternative routing ID. For example, when the IAB node 300 receives a BAP packet (BAP PDU) including a routing ID to be locally rerouted from another IAB node, the IAB node 300 transfers the BAP packet using the alternative routing ID associated with the routing ID. The destination BAP address included in the alternative routing ID is the same as the destination BAP address included in the routing ID, but the path ID is different. Therefore, the IAB node 300 may transmit the BAP packet to a path corresponding to the path ID included in the alternative routing ID. The IAB node 300 may execute the BAP header rewriting described in the first embodiment. Specifically, since the destination BAP address is the same, the path ID is rewritten to the path ID of the alternative routing ID.
[0115] Then, in step S25, the IAB node 300 ends the series of processes.
[0116] On the other hand, in step S26, the IAB node 300 falls back to the operation of Rel-16. That is, since the alternative routing ID set by the donor node 200 is unavailable, the IAB node 300 extracts a routing ID from the BAP packet (BAP PDU) to be locally rerouted, and selects another routing ID that matches the destination BAP address included in the routing ID. Then, the IAB node 300 transmits the BAP packet using the selected other routing ID.
[0117] In step S26, unlike step S24, the IAB node 300 does not need to rewrite the BAP header. That is, the routing ID in the header of the BAP packet to be sent is different from the routing ID to be sent. Specifically, the destination BAP address is the same, but the path ID is different.
[0118] Then, in step S25, the IAB node 300 ends the series of processes.
[0119] [Third embodiment] Next, a third embodiment will be described.
[0120] In the second embodiment, an example has been described in which the IAB node 300 determines whether or not an alternative routing ID is available, and performs the operation of Rel-16 if the alternative routing ID is unavailable.
[0121] For example, if the donor node 200 can set multiple alternative routing IDs for the IAB node 300 in advance, the probability that the IAB node 300 will perform local rerouting using the alternative routing IDs (i.e., perform Rel-17 operations) can be increased.
[0122] Therefore, in the third embodiment, the donor node 200 sets a plurality of alternative routing IDs for the IAB node 300.
[0123] Specifically, first, a donor node (e.g., donor node 200) sets multiple alternative routing IDs in a relay node (e.g., IAB node 300). Second, the relay node decides to perform local rerouting to forward a data packet to an alternative path. Third, the relay node receives a data packet from another relay node. Fourth, the relay node performs local rerouting using one of the multiple alternative routing IDs.
[0124] This allows, for example, multiple alternative routing IDs to be set, which increases the probability of performing Rel-17 operations and enables efficient packet forwarding control.
[0125] (Operation example according to the third embodiment) FIG. 12 is a diagram illustrating an example of operation according to the third embodiment.
[0126] As shown in FIG. 12, in step S30, the donor node 200 starts the process.
[0127] In step S31, the donor node 200 sets multiple alternative routing IDs in the IAB node 300. The multiple alternative routing IDs may be set in a list format. The order of entries of the multiple alternative routing IDs in the list format may be the usage priority. The alternative routing IDs may be added to the list (or compiled) in order of usage priority. The CU of the donor node 200 may be set using an RRC message, an F1AP message, or the like, as in the second embodiment (step S21 in FIG. 11).
[0128] In step S32, the IAB node 300 that has received the setting detects a predetermined condition and determines to execute local rerouting. The predetermined condition is the same as that in the second embodiment (step S22 in FIG. 11).
[0129] In step S33, the IAB node 300 selects an available alternative routing ID from multiple alternative routing IDs. For example, the IAB node 300 determines whether each of multiple alternative routing IDs is available, and selects an available alternative routing ID. When multiple alternative routing IDs are shown in a list format, the IAB node 300 may determine whether each of the alternative routing IDs is available, starting from the alternative routing ID shown as the first entry, and select the first alternative routing ID determined to be available as the available alternative routing ID. Whether or not an alternative routing ID is available may be the same as in the second embodiment (step S23 in FIG. 11).
[0130] If the IAB node 300 determines that all of the multiple alternative routing IDs are unavailable, it may fall back to the operation of Rel-16, as in the second embodiment (step S26 in FIG. 11).
[0131] In step S34, when the IAB node 300 receives a BAP packet (BAP PDU) to be locally rerouted from another IAB node, the IAB node 300 executes local rerouting using the selected alternative routing ID. The local rerouting using the alternative routing ID may be the same as that in the second embodiment (step S24 in FIG. 11).
[0132] Then, in step S35, the IAB node 300 ends the series of processes.
[0133] [Fourth embodiment] Next, a fourth embodiment will be described.
[0134] FIG. 13 is a diagram illustrating an example of a relationship between IAB nodes according to the fourth embodiment.
[0135] As shown in Fig. 13, a DC is set in the IAB node 300-1. For example, the master node is the IAB node 300-P1. Also, the secondary node is the IAB node 300-P2. In this case, the IAB node (master node) 300-P1 manages the master cell group (MCG). Also, the IAB node (secondary node) 300-P2 manages the secondary cell group (SCG). The IAB node 300-P1 and the IAB node 300-P2 are parent nodes of the IAB node 300-1.
[0136] Assume that a BH RLF occurs in either BH link #1 between IAB node 300-1 and IAB node 300-P1, or BH link #2 between IAB node 300-1 and IAB node 300-P2. The BH RLF that occurs in BH link #1 may be referred to as an "MCG BH RLF." Also, the BH RLF that occurs in BH link #2 may be referred to as an "SCG BH RLF."
[0137] In this situation, the fourth embodiment assumes the following two scenarios. That is, the first scenario is to set an alternative routing ID for IAB node 300-1 when IAB node 300-1 detects either an MCG BH RLF or an SCG BH RLF. The second scenario is to set an alternative routing ID for IAB node 300-2 when parent node IAB node 300-1 detects either an MCG BH RLF or an SCG BH RLF.
[0138] In the fourth embodiment, the donor node 200 sets an alternative routing ID for each cell group. Specifically, the donor node (for example, the donor node 200) sets an alternative routing ID for each cell group in a relay node (for example, the IAB node 300-1 or the IAB node 300-2).
[0139] This allows the donor node 200 to set the alternative routing ID to be different between the IAB node 300-1 and the IAB node 300-2, for example. Therefore, the donor node 200 can set the alternative routing ID taking into account the first scenario and the second scenario.
[0140] Also, for example, the donor node 200 can set different alternative routing IDs for local rerouting for the MCG BH RLF and for local rerouting for the SCG BH RLF. Therefore, the IAB node 300-1 can execute local rerouting according to each of the MCG BH RLF and the SCG BH RLF, and can appropriately forward received packets.
[0141] (Operation example of the fourth embodiment) FIG. 14 is a diagram illustrating an example of operation according to the fourth embodiment.
[0142] As shown in FIG. 14, in step S40, the donor node 200 starts the process.
[0143] In step S41, the donor node 200 sets an alternative routing ID for each cell group (CG) for the IAB node 300. For example, the donor node 200 sets a first alternative routing ID for the MCG BH RLF, and sets a second alternative routing ID for the SCG BH RLF.
[0144] The setting of the alternative routing ID for each CG may include information indicating whether the donor node 200 sets the ID for the IAB node 300-1 (B1) or the IAB node 300-2 (B2). The donor node 200 may further set the following information for the cases (B1) and (B2).
[0145] (B1) When setting to IAB node 300-1 The case where the donor node 200 sets the IAB node 300-1 is when the IAB node 300-1 itself detects the BH RLF. This corresponds to the first scenario. The donor node 200 may set a first alternative routing ID for the MCG BH RLF and a second alternative routing ID for the SCG BH RLF.
[0146] (B2) When setting to IAB node 300-2 On the other hand, the donor node 200 sets the IAB node 300-2 when the IAB node 300-2 receives a Type 2 BH RLF Indication from the IAB node 300-1 (for example, FIG. 13). This corresponds to the second scenario. The donor node 200 may set a third alternative routing ID for the MCG BH RLF in the parent node 300-1, and a fourth alternative routing ID for the SCG BH RLF in the parent node 300-1. In this case, the third alternative routing ID is an alternative routing ID to be applied to the IAB node 300-2, which is a child node of the parent node 300-1, when an MCG BH RLF occurs in the parent node 300-1. Moreover, the fourth alternative routing ID is an alternative routing ID to be applied to the IAB node 300-2, which is a child node of the parent node 300-1, when an SCG BH RLF occurs in the parent node 300-1.
[0147] The IAB node 300 considers the above (B1) and (B2) and determines the first scenario (own BH A first alternative routing ID and a second alternative routing ID may be set for the first scenario (parent node 300-1 detects a BH RLF), and a third alternative routing ID and a fourth alternative routing ID may be set for the second scenario (parent node 300-1 detects a BH RLF).
[0148] In step S42, the IAB node 300-1 or the IAB node 300-2 decides to perform local rerouting. When the IAB node 300-1 detects either the MCG BH RLF or the SCG BH RLF, the IAB node 300-1 decides to perform local rerouting. In addition, the IAB node 300-2 decides to perform local rerouting when the parent node 300 detects either the MCG BH RLF or the SCG BH RLF. When a Type 2 BH RLF Indication is received from IAB node 300-1, it determines to execute local rerouting. The Type 2 BH RLF Indication may include information indicating whether a BH RLF (MCG BH RLF) has occurred on the MCG side or a BH RLF (SCG BH RLF) has occurred on the SCG side in the parent node IAB node 300-1. Alternatively, the information may be transmitted together with the Type 2 BH RLF Indication.
[0149] In step S43, when the IAB node 300-1 or the IAB node 300-2 receives the BAP packet (BAP PDU) to be locally rerouted, it executes local rerouting on the BAP packet by using the alternative routing ID for each CG.
[0150] For example, if IAB node 300-1 detects the MCG BH RLF, it performs local rerouting using the first alternative routing ID.
[0151] Also, for example, when the IAB node 300-1 detects the SCG BH RLF, it performs local rerouting using the second alternative routing ID.
[0152] Furthermore, for example, the IAB node 300-2 receives an MCG If information is received indicating that a BH RLF has occurred, perform local rerouting using the third alternative routing ID.
[0153] Furthermore, for example, the IAB node 300-2 receives an SCG If information is received indicating that a BH RLF has occurred, perform local rerouting using the fourth alternative routing ID.
[0154] The operation of the local rerouting itself using the alternative routing ID may be similar to that in the second embodiment (step S24 in FIG. 11).
[0155] Then, in step S44, the IAB node 300-1 or the IAB node 300-2 ends the series of processes.
[0156] [Other embodiments] A program may be provided that causes a computer to execute each process performed by the UE 100 or the gNB 200. The program may be recorded in a computer-readable medium. The computer-readable medium can be used to install the program in a computer. Here, the computer-readable medium on which the program is recorded may be a non- The non-transitory recording medium may be a transient recording medium. The non-transitory recording medium is not particularly limited, but may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.
[0157] In addition, circuits that execute each process performed by UE100 or gNB200 may be integrated, and at least a part of UE100 or gNB200 may be configured as a semiconductor integrated circuit (chip set, SoC).
[0158] As used in this disclosure, the terms "based on" and "depending on" do not mean "based only on" or "depending only on," unless otherwise specified. The term "based on" means both "based only on" and "based at least in part on." Similarly, the term "depending on" means both "based only on" and "based at least in part on." Additionally, "obtain / acquire" may mean obtaining information from stored information, from information received from other nodes, or by generating information. The terms "include," "comprise," and variations thereof do not mean including only the items listed, but may include only the items listed, or may include additional items in addition to the items listed. Additionally, the term "or" as used in this disclosure is not intended to be an exclusive or. Additionally, any reference to elements using designations such as "first," "second," etc., as used in this disclosure is not intended to generally limit the quantity or order of those elements. These designations may be used herein as a convenient method of distinguishing between two or more elements. Thus, reference to a first and a second element does not imply that only two elements may be employed therein or that the first element must precede the second element in some manner. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles are intended to include the plural unless the context clearly indicates otherwise.
[0159] 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 and the like are possible without departing from the scope of the invention. In addition, it is also possible to combine all or part of each embodiment as long as there is no contradiction.
[0160] This application claims priority to Japanese Patent Application No. 2021-127856 (filed August 3, 2021), the entire contents of which are incorporated herein by reference. [Explanation of symbols]
[0161] 1: Mobile communication systems 10:5GC 100:UE 110: Wireless communication unit 120: Control section 200 (200-1 to 200-3): gNB (donor node) 210: Wireless Communication Department 220: Network Communication Department 230: Control section 300 (300-1, 300-2, 300-P1, 300-P2): IAB node 310: Wireless Communication Department 320: Control section
Claims
1. A communication control method for use in a cellular communication system, comprising: A relay node receives a configuration for inter-topology routing from a first donor node; the relay node rewriting a routing ID included in a BAP (Backhaul Adaptation Protocol) packet to a routing ID of another topology in accordance with the setting; The relay node transmits the rewritten BAP packet to a second donor node belonging to the other topology, The setting includes information indicating that the routing ID is the routing ID of the other topology. Communications control method.
2. The setting includes a first routing ID in the own topology and information indicating that a second routing ID is a routing ID of the other topology, The rewriting step includes a step of the relay node rewriting the first routing ID included in the BAP packet to the second routing ID according to the setting. The communication control method according to claim 1.
3. A relay node of a cellular communication system, comprising: A receiver that receives a configuration regarding inter-topology routing from a first donor node; a control unit that rewrites a routing ID included in a BAP packet to a routing ID of another topology according to the setting; a transmitter that transmits the rewritten BAP packet to a second donor node that belongs to the other topology, The setting includes information indicating that the routing ID is the routing ID of the other topology. Relay node.
4. The setting includes a first routing ID in the own topology and information indicating that a second routing ID is a routing ID of the other topology, The control unit rewrites the first routing ID included in the BAP packet to the second routing ID in accordance with the setting. The relay node according to claim 3.
5. A relay node; A first donor node; a second donor node, The relay node receives a configuration for inter-topology routing from the first donor node; The relay node rewrites the routing ID included in the BAP packet to the routing ID of another topology according to the setting, The relay node transmits the rewritten BAP packet to the second donor node belonging to the other topology; The setting includes information indicating that the routing ID is the routing ID of the other topology. Cellular communication systems.
6. The setting includes a first routing ID in the own topology and information indicating that a second routing ID is a routing ID of the other topology, The relay node rewrites the first routing ID included in the BAP packet to the second routing ID in accordance with the setting.
6. A cellular communication system according to claim 5.
7. A relay node in a cellular communication system, A process of receiving a configuration regarding inter-topology routing from a first donor node; A process of rewriting the routing ID included in the BAP packet to the routing ID of another topology according to the setting; a process of transmitting the rewritten BAP packet to a second donor node belonging to the other topology; The setting includes information indicating that the routing ID is the routing ID of the other topology. program.
8. The setting includes a first routing ID in the own topology and information indicating that a second routing ID is a routing ID of the other topology, The rewriting process includes a process of rewriting the first routing ID included in the BAP packet to the second routing ID according to the setting. The program according to claim 7.
9. A chipset for a relay node in a cellular communication system, comprising: receiving a configuration regarding inter-topology routing by a first donor node; rewriting the routing ID included in the BAP packet to the routing ID of another topology according to the setting; and transmitting the rewritten BAP packet to a second donor node belonging to the other topology; The setting includes information indicating that the routing ID is the routing ID of the other topology. Chipset.
10. The setting includes a first routing ID in the own topology and information indicating that a second routing ID is a routing ID of the other topology, The rewriting includes rewriting the first routing ID included in the BAP packet to the second routing ID according to the setting. The chipset of claim 9.
Citation Information
Cited By
Ventilation system
EP4807153A1