Patent Application
20240205794
This application pertains to the field of communication technologies, and specifically relates to a data routing method and apparatus, a node, and a storage medium.
If data in a first topology needs to be sent to a terminal through a second topology, the second topology needs to configure corresponding route mapping for the packet. First, the data is routed to a boundary node, and the boundary node re-writes a header of the packet. Then, the boundary node routes the data to a node in the second topology.
However, the boundary node cannot determine whether data currently sent to the boundary node needs to be sent to the second topology, resulting in high complexity of data routing and excessive resource occupation.
Embodiments of this application provide a data routing method and apparatus, a node, and a storage medium, to resolve a problem of high complexity of data routing and excessive resource occupation.
According to a first aspect, a data routing method is provided. The method includes:
According to a second aspect, a data routing method is provided. The method includes:
According to a third aspect, a data routing apparatus is provided. The apparatus includes:
According to a fourth aspect, a data routing apparatus is provided. The apparatus includes:
According to a fifth aspect, a boundary node is provided. The boundary node includes a processor, a memory, and a program or an instruction that is stored in the memory and can be run on the processor, and the program or the instruction is executed by the processor to implement the steps of the method according to the first aspect.
According to a sixth aspect, a boundary node is provided, including a processor and a communication interface. The communication interface is configured to:
The processor is configured to:
The communication interface is further configured to:
According to a seventh aspect, a generation node is provided. The generation node includes a processor, a memory, and a program or an instruction that is stored in the memory and that can be run on the processor, and the program or the instruction is executed by the processor to implement the steps of the method according to the second aspect.
According to an eighth aspect, a generation node is provided, including a processor and a communication interface. The processor is configured to:
The communication interface is configured to:
According to a ninth aspect, a readable storage medium is provided. The readable storage medium stores a program or an instruction, and the program or the instruction is executed by a processor to implement the steps of the method according to the first aspect or the steps of the method according to the second aspect.
According to a tenth aspect, a chip is provided. The chip includes a processor and a communication interface, the communication interface is coupled to the processor, and the processor is configured to run a program or an instruction to implement the method according to the first aspect or the method according to the second aspect.
According to an eleventh aspect, a computer program/program product is provided. The computer program/program product is stored in a non-transient storage medium, and the program/program product is executed by at least one processor to implement the steps of the method according to the first aspect or the steps of the method according to the second aspect.
In the embodiments of this application, a boundary node determines ownership of a destination node of a packet based on first information in a header of the packet in a first topology; in a case that it is determined that the destination node of the packet belongs to a second topology, re-write the header of the packet based on the first information; and transmit a re-written packet to the destination node, to ensure that the boundary node can directly distinguish, from the header of the received packet, whether the data needs to be routed to the second topology, thereby reducing difficulty of data routing and saving resources.
The following clearly describes the technical solutions in the embodiments of this application with reference to the accompanying drawings in the embodiments of this application. Apparently, the described embodiments are some but not all of the embodiments of this application. All other embodiments obtained by a person of ordinary skill based on the embodiments of this application shall fall within the protection scope of this application.
In the specification and claims of this application, the terms “first”, “second”, and the like are intended to distinguish between similar objects but do not describe a specific order or sequence. It should be understood that the terms used in such a way are interchangeable in proper circumstances so that the embodiments of this application can be implemented in orders other than the order illustrated or described herein. Objects classified by “first” and “second” are usually of a same type, and the number of objects is not limited. For example, there may be one or more first objects. In addition, in the specification and claims, “and/or” represents at least one of connected objects, that is, A and/or B represent three cases: only A, only B, and both A and B are included, and the character “/” generally represents an “or” relationship between associated objects.
It should be noted that technologies described in the embodiments of this application are not limited to a Long Time Evolution (Long Time Evolution, LTE)/LTE-Advanced (LTE-Advanced, LTE-A) system, and may further be applied to other wireless communication systems such as Code Division Multiple Access (Code Division Multiple Access, CDMA), Time Division Multiple Access (Time Division Multiple Access, TDMA), Frequency Division Multiple Access (Frequency Division Multiple Access, FDMA), Orthogonal Frequency Division Multiple Access (Orthogonal Frequency Division Multiple Access, OFDMA), single-carrier frequency division multiple access (Single-carrier Frequency-Division Multiple Access, SC-FD-MA), and other systems. The terms “system” and “network” in the embodiments of this application may be used interchangeably. The technologies described can be applied to both the systems and the radio technologies mentioned above as well as to other systems and radio technologies. The following describes a New Radio (New Radio, NR) system for example purposes, and NR terms are used in most of the following descriptions. These technologies can also be applied to applications other than an NR system application, such as a 6th generation (6th Generation, 6G) communication system.
With reference to the accompanying drawings, the following describes in detail a data routing method and apparatus, a node, and a storage medium provided in the embodiments of this application by using some embodiments and application scenes thereof.
First, the following content is introduced:
An integrated access backhaul (integrated access backhaul, IAB) system is a technology in a communication system.
The IAB system includes a centralized unit-distributed unit (Centralized Unit-Distributed Unit, CU-DU).
The introduction of the IAB system can resolve a problem that the wired transmission network is not deployed properly when access points are deployed intensively. That is, when there is no wired transmission network, the access points may rely on wireless backhaul.
A radio link between IAB nodes is referred to as a backhaul link (BH link), and a backhaul radio link control channel (Backhaul RLC channel, BH RLC channel) is configured on the BH link for wireless backhaul.
For inter-topology routing (inter-topology routing), a boundary node (boundary IAB-node) may re-write (re-writing) a BAP header of a packet based on a BAP routing ID 1 in a first topology carried in a header (BAP header) of the original packet, and fill a BAP routing ID 2 in a second topology into the BAP header of the packet.
A first topology (First topology) is a topology segment before a boundary node that a packet experiences in a transmission process. For example, for downlink data generated at a CU 2, a solid line part on the right side in the figure is a first topology. If uplink data that needs to be sent to the CU 2 is generated by an IAB4, a dotted line part consisting of all points is a first topology.
A second topology (Second topology) is a topology segment after a boundary node that a packet experiences in a transmission process. For example, for downlink data generated at a CU 2, a dotted line part consisting of all points is a second topology. If uplink data that needs to be sent to the CU 2 is generated by an IAB4, a solid line part on the right side in the figure is a second topology.
At present, the boundary node cannot distinguish the following two types of data:
(1) Data that requires packet header re-writing (BAP header re-writing): For example, if a CU 2 node helps a CU 1 node route data, the data needs to be transmitted to the IAB4 node. Therefore, when passing through an IAB3 node, BAP header re-writing needs to be performed for the data.
(2) Data that does not require BAP header re-writing: For example, data sent by the CU 2 to the IAB3 node is not transmitted after being received by the IAB3 node, but is delivered to an upper layer of the node.
If the boundary node selects Py of another second topology based on Px of the first topology, there are the following defects:
(a) Path ID space of the first topology is occupied. For example, Px needs to be different from a Path ID used by data that does not require route. Otherwise, the boundary node cannot distinguish whether re-writing is required.
(b) Because Px is used to indicate Py mapping in the second topology, a large amount of Path ID space needs to be further occupied.
It is assumed that two pieces of data need to be routed to different terminations in the second topology. One is for an IAB4, and the other is for an IAB5. Path IDs of the two pieces of data are Px1 and Px2, and cannot be the same. Otherwise, an intermediate node is mapped to a same routing ID. Therefore, both Px1 and Px2 represent a route A1->A3->A4 in the first topology, but a plurality of path IDs need to be used to represent the route.
(c) The boundary node needs to maintain a complex BAP header re-writing table, and each Px in the table needs to have a separate entry (Ay, Py).
That is, a large quantity of path IDS need to be occupied to perform inter-donor routing, thereby affecting allocation of path IDs in the topology. The CU 1 needs to maintain a complex BAP header re-writing table for each boundary node, which increases complexity of operations of the boundary node.
Therefore, it is not clear how to specifically distinguish whether data is delivered to the boundary node or whether BAP header re-writing needs to be performed for the boundary node, and re-writing is performed according to which mapping, to reduce difficulty of data routing and save resources.
Step 610: The boundary node determines ownership of a destination node of the packet based on first information in a header of the packet.
Step 620: In a case that the destination node of the packet belongs to a second topology, the boundary node re-writes the header of the packet based on the first information.
Step 630: The boundary node transmits a re-written packet to the destination node in the second topology.
Optionally, the packet in the first topology is generated by a generation node in the first topology.
Optionally, the header of the packet in the first topology includes the first information, and the first information may be used by the boundary node to determine the ownership of the destination node of the packet, that is, used by the boundary node to determine whether the destination node of the packet belongs to the second topology. In other words, the first information may be used by the boundary node to distinguish whether the packet needs to be delivered to an upper layer of the boundary node or whether header re-writing (BAP header re-writing) needs to be performed at the boundary node.
Optionally, after receiving the packet in the first topology, the boundary node may determine, based on the first information in the header of the packet, whether the destination node of the packet belongs to the second topology, that is, determine whether the packet needs to be delivered to an upper layer of the boundary node or whether header re-writing needs to be performed at the boundary node.
Optionally, in a case that the boundary node determines that the destination node of the packet belongs to the second topology, the boundary node may re-write the header of the packet based on the first information, and transmit the re-written packet to the destination node in the second topology, so that the packet can be effectively transmitted in the second topology.
Optionally, a destination IAB node is the destination node.
Optionally, re-writing (re-writing) of the header of the packer may also be referred to as overwriting of the header of the packer.
This embodiment of this application provides a data routing method in a topology redundancy scene. In a case that the boundary node determines that the destination node of the packet belongs to the second topology, the boundary node may perform routing ID re-writing (re-writing) on a BAP header of the packet in the first topology to change into a routing ID in the second topology, so that the packet can be routed by the boundary node from the first topology to the second topology, thereby implementing load-balancing in inter-donor redundancy.
In this embodiment of this application, a boundary node determines, based on first information in a header of a packet in a first topology, whether a destination node of the packet belongs to a second topology; in a case that it is determined that the destination node of the packet belongs to a second topology, re-write the header of the packet based on the first information; and transmit a re-written packet to the destination node, to ensure that the boundary node can directly distinguish, from the header of the received packet, whether the data needs to be routed to the second topology, thereby reducing difficulty of data routing and saving resources.
Optionally, the determining, by the boundary node, ownership of a destination node of the packet based on first information in a header of the packet includes:
Optionally, in this embodiment of this application, the boundary node may determine the ownership of the destination node of the packet according to a backhaul adaptation protocol destination address (destination BAP address, which may also be referred to as a BAP destination address) in the first information, that is, determine whether header re-writing needs to be performed.
Optionally, the boundary node may match the BAP destination address in the first information with an address of the boundary node. If it is found that the BAP destination address in the first information is the same as a first virtual address of the boundary node, it may be determined that the destination node of the packet belongs to the second topology, that is, header re-writing needs to be performed.
Optionally, the first BAP virtual address may be a preset virtual address.
Optionally, the first BAP virtual address may correspond to the first destination node information group.
Optionally, a correspondence between the first BAP virtual address and the first destination node information group may be preset.
Optionally, the boundary node may be mapped to the first destination node information group based on the first BAP virtual address, to determine the first destination address and the first path ID of the destination node in the second topology, that is, the routing path from the boundary node to the destination node in the second topology.
Optionally, after the generation node (Donor-DU or access node) in the first topology generates a BAP PDU for data that requires inter-donor routing, when the BAP PDU is routed to the boundary node, the boundary node may determine, according to whether a BAP destination address carried in the BAP PDU is the same as the first BAP virtual address, whether cross-topology routing needs to be performed for the packet, and if yes, further determine a BAP routing ID corresponding to the PDU in the second topology based on the BAP destination address carried in the BAP PDU, and re-write the BAP routing ID into a header of the BAP PDU for transmission in the second topology.
Optionally, in this embodiment of this application, the first information in the BAP header of the PDU on which inter-donor routing is performed may include a destination BAP address, and the destination BAP address may be the same as the first virtual address.
Optionally, in this embodiment of this application, the boundary node may perform BAP header re-writing according to the first BAP virtual address (first logical/virtual BAP address). That is, a path ID is replaced with a BAP address, thereby effectively reducing complexity of packet routing and saving transmission resources.
Optionally, the re-writing, by the boundary node, the header of the packet based on the first information includes:
Optionally, the CU in the first topology and/or the CU in the second topology may configure a plurality of logical/virtual BAP addresses for the boundary node, that is, second BAP virtual addresses, where each second BAP virtual address corresponds to one second destination node information group (Destination BAP address, Path ID) in the second topology.
Optionally, the at least one second BAP virtual address, the corresponding one or more second destination node information groups, and the mapping relationship between the two may be reflected in the second mapping table.
The second mapping table includes at least one second BAP virtual address, and each second BAP virtual address may correspond to one or more second destination node information groups.
Optionally, the second mapping table may be preset, and is locally stored by the boundary node.
Optionally, in a case that the BAP destination address carried in the BAP PDU is the same as the first BAP virtual address, after determining that cross-topology routing needs to be performed for the packet, the boundary node may determine, based on the BAP destination address carried in the BAP PDU, the BAP routing ID corresponding to the PDU in the second topology, that is, the boundary node may find, based on the second mapping table locally stored by the boundary node, the first destination node information group corresponding to the first BAP virtual address, and further determine, based on the first destination node information group, the first destination address and the first path ID that are corresponding to the first BAP virtual address in the second topology, and re-write the two IDs into the BAP header of the packet.
Optionally, the boundary node may re-find, according to a legacy routing rule, a next-hop node for the BAP PDU whose header is re-written to submit data, until the data is routed to the destination node displayed in the BAP header.
Optionally, a definition of the second mapping table may include at least one of the following:
The second mapping table may be shown in the following Table 1, and includes at least one of the following:
Table 1 is only an example of the second mapping table, and is not used as a limitation on the second mapping table and content thereof.
Optionally, the BAP address of the destination IAB node is a destination address of the destination node.
Optionally, a real BAP address of the boundary node is a real address of the boundary node.
Optionally, for an uplink, the boundary node may maintain a set of second mapping tables, and for a downlink, the boundary node may maintain another set of same or different second mapping tables. The generation node may maintain a first mapping table corresponding to the boundary node, so that the first information in the header of the packet generated by the generation node may be accurately indicated.
Optionally, the determining, by the boundary node, ownership of a destination node of the packet based on first information in a header of the packet further includes:
Optionally, after receiving the packet (BAP PDU), the boundary node may determine whether a BAP destination address in the BAP header is an address of the boundary node. If no, the data is submitted to a next hop (next IAB node) according to legacy behavior. If yes, it may be further determined whether the BAP address is a virtual address or a real address of the boundary node.
Optionally, if the boundary node determines that the BAP destination address in the first information is the same as the real address of the boundary node, that is, determines that the BAP destination address in the BAP header is the real address of the boundary node, it indicates that the data is transmitted to the boundary node instead of being routed to another topology, and the PDU may be delivered to the upper layer of the BAP layer of the boundary node after the header is removed.
Optionally, the determining, by the boundary node, ownership of a destination node of the packet based on first information in a header of the packet includes:
Optionally, in this embodiment of this application, 1 bit (that is, the first indication information) may be used in the header to indicate that the PDU is a packet that requires cross-topology routing (to-be-routed packet), and a path ID in the second topology is carried.
Optionally, in this embodiment of this application, the boundary node may determine the ownership of the destination node of the packet according to the first indication information in the first information, that is, determine whether header re-writing (header re-writing) needs to be performed.
Optionally, the first indication information is used to directly indicate that the destination node of the packet belongs to the second topology, that is, when determining that the first information includes the first indication information, the boundary node may directly determine that the destination node of the packet belongs to the second topology, that is, header re-writing needs to be performed.
Optionally, after the generation node (Donor-DU or access node) in the first topology generates a BAP PDU for data that requires inter-donor routing, when the BAP PDU is routed to the boundary node, the boundary node determines, according to the first indication information carried in the BAP PDU, that header re-writing needs to be performed for the PDU, determines a BAP routing ID corresponding to the packet in the second topology, and rewrites the BAP routing ID into a header of the BAP PDU for transmission in the second topology.
Optionally, in this embodiment of this application, the operation in which the generation node (donor-DU or access node) of the packet configures the BAP routing ID for data that requires cross-topology routing (to-be-routed data) is omitted, thereby effectively reducing complexity of packet routing and saving transmission resources.
Optionally, the first information further includes a second path ID, and the second path ID is used to indicate a routing path from the boundary node to the destination node in the second topology.
Optionally,
Optionally, the re-writing, by the boundary node, the header of the packet based on the first information includes:
Optionally, after determining, according to the first indication information carried in the BAP PDU, that cross-topology routing needs to be performed for the packet, the boundary node may determine, based on the second path ID and the third mapping table in the first information, the second destination address that has the mapping relationship with the second path ID in the third mapping table, and may further re-write the two IDs into the BAP header of the PDU.
Optionally, the boundary node may re-find, according to a legacy routing rule, a next-hop node for the BAP PDU whose header is re-written to submit data, until the data is routed to the destination node displayed in the BAP header.
Optionally, after receiving the BAP PDU, another IAB node in the first topology may determine whether the first indication information indicates that cross-topology routing (BAP header re-writing) needs to be performed for the PDU. If the first indication information indicates that cross-topology routing needs to be performed, the data is routed only according to the BAP destination address. If there is no indication of the first indication information or the second indication information indicates that cross-topology routing does not need to be performed, the data is routed according to the legacy routing rule.
Optionally, content of the third mapping table may include at least one of the following:
Optionally, the third mapping table includes at least one third path ID and at least one third destination address.
Optionally, each third path ID may correspond to one or more third destination addresses.
Optionally, when determining, based on the second path ID and the third mapping table in the first information, that the second destination address that has the mapping relationship with the second path ID in the third mapping table, the boundary node may find, in the third mapping table, the third path ID that is the same as the second path ID, and then determine that the third destination address corresponding to the third path ID is the second destination address of the destination node corresponding to the second path ID in the second topology, that is, the second destination address of the destination node of the packet.
Optionally, for an uplink, the boundary node may maintain a set of third mapping tables, and for a downlink, the boundary node may maintain another set of same or different third mapping tables.
Optionally, the determining, by the boundary node, ownership of a destination node of the packet based on first information in a header of the packet further includes:
Optionally, after receiving the BAP PDU, the boundary node may determine whether a BAP destination address in the BAP header is an address of the boundary node. If no, the data is submitted to a next hop (a next IAB node) according to legacy behavior. If yes, it may be further determined whether the first indication information indicates that cross-topology routing needs to be performed.
Optionally, if the second indication information indicates that cross-topology routing does not need to be performed, it may indicate that the data is transmitted to the boundary node instead of being routed to another topology, and the PDU may be delivered to the upper layer of the BAP layer of the boundary node after the header is removed.
Optionally, in a case that the first information includes the second indication information, the first information may further include a sixth path ID, and the sixth path ID is a routing path from a generation node of the packet to the boundary node in the first topology.
Optionally, the determining, by the boundary node, ownership of a destination node of the packet based on first information in a header of the packet includes:
Optionally, in this embodiment of this application, a virtual address of the boundary node may be used to indicate that the PDU is a to-be-routed packet.
Optionally, the third BAP virtual address may be used to directly indicate that cross-topology routing needs to be performed for the packet, that is, when determining that the first information includes the third BAP virtual address (the BAP destination address in the first information is the same as the third BAP virtual address of the boundary node), the boundary node may directly determine that the destination node of the packet belongs to the second topology, that is, header re-writing needs to be performed.
Optionally, after the generation node (Donor-DU or access node) in the first topology generates a BAP PDU for data that requires inter-donor routing, when the BAP PDU is routed to the boundary node, the boundary node determines, according to a third BAP virtual address carried in the BAP PDU, that header re-writing needs to be performed for the PDU, determines a BAP routing ID corresponding to the PDU in the second topology, and rewrites the BAP routing ID into a header of the BAP PDU for transmission in the second topology.
Optionally, the third BAP virtual address may be a preset virtual address, and is used to directly indicate that header re-writing needs to be performed for the packet.
Optionally, the third BAP virtual address is configured for the boundary node by the first centralized unit CU in the first topology or the second centralized unit CU in the second topology. That is, the CU in the first topology and/or the CU in the second topology may configure one logical/virtual BAP address for the boundary node, to directly indicate that cross-topology routing needs to be performed for the packet.
Optionally, each boundary node (boundary node) may have a fixed third BAP virtual address.
Optionally, each boundary node may have two fixed third BAP virtual addresses, one for routing of uplink data and the other for routing of downlink data.
Optionally, the first information further includes a fourth path ID, and the fourth path ID is used to indicate a routing path from the boundary node to the destination node in the second topology; and
Optionally, in a case that the boundary node determines that the BAP destination address in the first information is the same as the third BAP virtual address of the boundary node, the first information may further include a fourth path ID, and the fourth path ID is used to indicate a routing path from the boundary node to the destination node in the second topology.
Optionally, after determining, according to the third BAP virtual address carried in the BAP PDU, that header re-writing needs to be performed for the PDU, the boundary node may find, based on the local fourth mapping table, the fifth path ID that is in the at least one fifth path ID and that is the same as the fourth path ID, the fifth destination address corresponding to the fifth path ID that is the same as the fourth path ID, that is, the fourth destination address corresponding to the fourth path ID. In this case, the fourth destination address of the destination node in the second topology may be determined, and further the two IDs may be re-written into the BAP header of the packet.
Optionally, the BAP header of the PDU on which inter-donor routing is performed may carry the following information:
Optionally, if the BAP destination address is a logical address of the boundary node, the fifth path ID that is the same as the fourth path ID is found according to the fourth mapping table at the boundary node (the fourth path ID corresponds to the second topology, and corresponds to an address of a real destination node to which the PDU ultimately needs to be transmitted, that is, the fourth destination address), and further the fifth destination address corresponding to the fifth path ID may be determined, that is, the BAP destination address corresponding to the fourth path ID, and the two IDs may be re-written into the BAP header of the PDU.
Optionally, the boundary node may re-find, according to a legacy routing rule, a next-hop node for the BAP PDU whose header is re-written to submit data, until the data is routed to the destination node displayed in the BAP header.
Optionally, content of the fourth mapping table may include at least one of the following:
Optionally, for an uplink, the boundary node may maintain a set of fourth mapping tables, and for a downlink, the boundary node may maintain another set of same or different fourth mapping tables.
Optionally, the determining, by the boundary node, ownership of a destination node of the packet based on first information in a header of the packet includes:
Optionally, after receiving the BAP PDU, the boundary node may determine whether a BAP destination address in the BAP header is an address of the boundary node. If no, the data is submitted to a next hop (a next IAB node) according to legacy behavior. If yes, it may be further determined whether the BAP address is a virtual address or a real address of the boundary node.
Optionally, if the boundary node determines that the BAP destination address in the first information is the same as the real address of the boundary node, that is, determines that the BAP destination address in the BAP header is the real address of the boundary node, it indicates that the data packet is transmitted to the boundary node instead of being routed to another topology, and the PDU may be delivered to the upper layer of the BAP layer of the boundary node after the header is removed.
Optionally, the first information further includes a seventh path ID, and the seventh path ID is used to indicate a routing path from a generation node of the packet to the boundary node in the first topology.
Optionally, in a case that the destination node of the packet is the boundary node, the first information further includes a seventh path ID, and the seventh path ID is used to indicate a routing path from a generation node of the packet to the boundary node in the first topology.
Optionally, the determining, by the boundary node, ownership of a destination node of the packet based on first information in a header of the packet further includes:
Optionally, after receiving the BAP PDU, the boundary node may determine whether a BAP destination address in the BAP header is an address of the boundary node. If no, the boundary node determines that the BAP destination address in the first information is different from all addresses of the boundary node, and the data may be submitted to a next hop (a next IAB node) according to legacy behavior.
Optionally, the routing rule specified in the protocol may be an existing legacy routing rule, or may be a routing rule specified in a communication protocol.
Optionally, this embodiment of this application provides a data routing method in a topology redundancy scene. The boundary node performs, according to a preset mapping rule, routing ID re-writing (re-writing) on a packet BAP header in a topology 1 to change into a routing ID in a topology 2, so that the packet can be routed by the boundary node from the topology 1 to the topology 2, thereby implementing load-balancing in inter-donor redundancy. The boundary node does not need to maintain an additional (and complex) mapping table, but follows a table in a legacy technology. Therefore, a quantity of available path IDs in the topology 1 is not reduced, and only a small quantity of BAP address needs to be occupied.
In this embodiment of this application, a boundary node determines ownership of a destination node of a packet based on first information in a header of the packet in a first topology; in a case that it is determined that the destination node of the packet belongs to a second topology, re-write the header of the packet based on the first information; and transmit a re-written packet to the destination node, to ensure that the boundary node can directly distinguish, from the header of the received packet, whether the data needs to be routed to the second topology, thereby reducing difficulty of data routing and saving resources.
Step 800: A generation node in a first topology generates a packet, where a header of the packet includes first information, and the first information is used to indicate ownership of a destination node of the packet.
Step 810: The generation node sends the packet to a boundary node.
Optionally, the packet in the first topology is generated by the generation node in the first topology.
Optionally, the header of the packet in the first topology includes the first information, and the first information may be used by the boundary node to determine the ownership of the destination node of the packet, that is, used by the boundary node to distinguish whether the packet needs to be delivered to an upper layer of the boundary node or whether header re-writing (BAP header re-writing) needs to be performed at the boundary node.
Optionally, the ownership of the destination node of the packet is known to the generation node.
Optionally, after receiving the packet in the first topology, the boundary node may determine the ownership of the destination node of the packet based on the first information in the header of the packet, that is, determine whether the packet needs to be delivered to an upper layer of the boundary node or whether header re-writing needs to be performed at the boundary node.
Optionally, in a case that the boundary node determines that the destination node of the packet belongs to the second topology, the boundary node may re-write the header of the packet based on the first information, and transmit the re-written packet to the destination node in the second topology, so that the packet can be effectively transmitted in the second topology.
This embodiment of this application provides a data routing method in a topology redundancy scene. In a case that the boundary node determines that the destination node of the packet belongs to the second topology, the boundary node may perform routing ID re-writing (re-writing) on a BAP header of the packet in the first topology to change into a routing ID in the second topology, so that the packet can be routed by the boundary node from the first topology to the second topology, thereby implementing load-balancing in inter-donor redundancy.
In this embodiment of this application, a boundary node determines ownership of a destination node of a packet based on first information in a header of the packet in a first topology; in a case that it is determined that the destination node of the packet belongs to a second topology, re-write the header of the packet based on the first information; and transmit a re-written packet to the destination node, to ensure that the boundary node can directly distinguish, from the header of the received packet, whether the data needs to be routed to the second topology, thereby reducing difficulty of data routing and saving resources.
Optionally, before the generating, by a generation node in a first topology, a packet, the method further includes:
Optionally, the generation node locally stores one first mapping table, and the first mapping table is used to determine at least one first BAP virtual address of the boundary node.
Optionally, the generation node may first determine the first destination address of the packet at the destination node in the second topology, and then determine the first path ID based on the first destination address, where the first path ID is used to indicate a path ID from the boundary node to the destination node in the second topology; and determine the boundary node that needs to re-write the header of the packet.
Optionally, the first BAP virtual address corresponding to the first mapping information may be determined in the first mapping table based on the local first mapping information, and the first mapping information may include any one or any combination of the following:
Optionally, for example, the first mapping information includes the real address of the boundary node and the first path ID. The generation node may first determine the first destination address of the packet at the destination node in the second topology, and then determine the first path ID based on the first destination address, where the first path ID is used to indicate a path ID from the boundary node to the destination node in the second topology; and determine the boundary node that needs to re-write the header of the packet. That is, at least one eighth path ID corresponding to the real address of the boundary node may be determined in the first mapping table, and an eighth path ID that is the same as the first path ID may be determined. Further, a fourth BAP virtual address corresponding to the eighth path ID that is the same as the first path ID is determined as the first BAP virtual address that has the mapping relationship with the first path ID, that is, the BAP destination address in the first information in the header of the packet may be set to be the same as the first BAP virtual address.
Optionally, the mapping relationship that is between the mapping information in the first mapping table and the fourth BAP virtual address and that is locally stored by the generation node is the same as the mapping relationship that is between the second BAP virtual address in the second mapping table and the second destination node information group and that is locally stored by the boundary node.
Optionally, generation objects of the first mapping table are a CU in the first topology and/or a CU in the second topology.
Optionally, the first mapping table may be shown in the following Table 2, and include at least one of the following:
Table 2 is only an example of the first mapping table, and is not used as a limitation on the first mapping table and content thereof. Optionally, in a case that the destination node of the packet is the boundary node, the generating, by a generation node in a first topology, a packet includes:
Optionally, in a case that the destination node of the packet is the boundary node, the real address of the boundary node may be directly used as the BAP destination address in the first information in the header of the packet generated by the generation node.
Optionally, after receiving the BAP PDU, the boundary node may determine whether a BAP destination address in the BAP header is an address of the boundary node. If no, the data is submitted to a next hop (a next IAB node) according to legacy behavior. If yes, it may be further determined whether the BAP address is a virtual address or a real address of the boundary node.
Optionally, if the boundary node determines that the BAP destination address in the first information is the same as the real address of the boundary node, that is, determines that the BAP destination address in the BAP header is the real address of the boundary node, it indicates that the data is transmitted to the boundary node instead of being routed to another topology, and the PDU may be delivered to the upper layer of the BAP layer of the boundary node after the header is removed.
Optionally, in a case that the destination node of the packet belongs to a second topology, the generating, by a generation node in a first topology, a packet includes:
Optionally, in this embodiment of this application, 1 bit (that is, the first indication information) may be used in the BAP header to indicate that the PDU is a to-be-routed packet, and a path ID in the second topology is carried.
Optionally, in a case that the destination node of the packet belongs to the second topology, the BAP destination address in the first information in the header of the packet that may be generated by the generation node is the same as the real address of the boundary node, and the first information includes the first indication information, which is used to directly indicate the boundary node that cross-topology routing needs to be performed for the packet.
Optionally, in this embodiment of this application, the boundary node may determine the ownership of the destination node of the packet according to the first indication information in the first information, that is, determine whether header re-writing needs to be performed.
Optionally, the first indication information is used to directly indicate that the destination node of the packet belongs to the second topology, that is, when determining that the first information includes the first indication information, the boundary node may directly determine that the destination node of the packet belongs to the second topology, that is, header re-writing needs to be performed.
Optionally, after the generation node (Donor-DU or access node) in the first topology generates a BAP PDU for data that requires inter-donor routing, when the BAP PDU is routed to the boundary node, the boundary node determines, according to the first indication information carried in the BAP PDU, that header re-writing needs to be performed for the PDU, determines a BAP routing ID corresponding to the packet in the second topology, and rewrites the BAP routing ID into a header of the BAP PDU for transmission in the second topology.
Optionally, in this embodiment of this application, the operation in which the donor-DU/access node configures the BAP routing ID of the to-be-routed data is omitted, thereby effectively reducing complexity of packet routing and saving transmission resources.
Optionally, the first information further includes a second path ID, and the second path ID is used to indicate a routing path from the boundary node to the destination node in the second topology.
Optionally, in a case that the destination node of the packet belongs to the second topology, the BAP destination address in the first information in the header of the packet that may be generated by the generation node is the same as the real address of the boundary node, and when the first information includes the first indication information, the first information may further include a second path ID, where the second path ID is used to indicate a routing path from the boundary node to the destination node in the second topology.
Optionally, in a case that the destination node of the packet is the boundary node, the generating, by a generation node in a first topology, a packet includes:
Optionally, in a case that the destination node of the packet is the boundary node, the BAP destination address in the first information in the header of the packet that may be generated by the generation node is the same as the real address of the boundary node, and the first information includes the second indication information, which is used to directly indicate the boundary node that cross-topology routing does not need to be performed for the packet.
Optionally, after receiving the BAP PDU, the boundary node may determine whether a BAP destination address in the BAP header is an address of the boundary node. If no, the data is submitted to a next hop (a next IAB node) according to legacy behavior. If yes, it may be further determined whether the first indication information indicates that cross-topology routing needs to be performed.
Optionally, if the second indication information indicates that cross-topology routing does not need to be performed, it may indicate that the data is transmitted to the boundary node instead of being routed to another topology, and the PDU may be delivered to the upper layer of the BAP layer of the boundary node after the header is removed.
Optionally, in a case that the destination node of the packet belongs to a second topology, the generating, by a generation node in a first topology, a packet includes:
Optionally, in this embodiment of this application, a virtual address of the boundary node may be used to indicate that the PDU is a to-be-routed packet.
Optionally, in a case that the destination node of the packet belongs to the second topology, the BAP destination address in the first information in the header of the packet generated by the generation node may be the same as the third BAP virtual address.
Optionally, after the generation node (Donor-DU or access node) in the first topology generates a BAP PDU for data that requires inter-donor routing, when the BAP PDU is routed to the boundary node, the boundary node determines, according to a third BAP virtual address carried in the BAP PDU, that header re-writing needs to be performed for the PDU, determines a BAP routing ID corresponding to the PDU in the second topology, and rewrites the BAP routing ID into a header of the BAP PDU for transmission in the second topology. Optionally, the third BAP virtual address is configured for the boundary node by the first centralized unit CU in the first topology or the second centralized unit CU in the second topology. That is, the CU in the first topology and/or the second topology may configure one logical/virtual BAP address for the boundary node, to directly indicate that cross-topology routing needs to be performed for the packet.
Optionally, each boundary node may have a fixed third BAP virtual address.
Optionally, each boundary node may have two fixed third BAP virtual addresses, one for routing of uplink data and the other for routing of downlink data.
Optionally, the first information further includes a fourth path ID, and the fourth path ID is used to indicate a routing path from the boundary node to the destination node in the second topology.
Optionally, in a case that the boundary node determines that the BAP destination address in the first information is the same as the third BAP virtual address of the boundary node, the first information may further include a fourth path ID, and the fourth path ID is used to indicate a routing path from the boundary node to the destination node in the second topology.
Optionally, in a case that the destination node of the packet is the boundary node, the generating, by a generation node in a first topology, a packet includes:
generating, by the generation node, the packet, where the BAP destination address in the first information in the header of the packet is the same as a real address of the boundary node.
Optionally, in a case that the destination node of the packet is the boundary node, the BAP destination address in the first information in the header of the packet that may be generated by the generation node is the same as the real address of the boundary node, and the first information includes the third BAP virtual address, which is used to directly indicate the boundary node that cross-topology routing does not need to be performed for the packet.
Optionally, after receiving the BAP PDU, the boundary node may determine whether a BAP destination address in the BAP header is an address of the boundary node. If no, the data is submitted to a next hop (a next IAB node) according to legacy behavior. If yes, it may be further determined whether the BAP address is a virtual address or a real address of the boundary node.
Optionally, if the boundary node determines that the BAP destination address in the first information is the same as the real address of the boundary node, that is, determines that the BAP destination address in the BAP header is the real address of the boundary node, it indicates that the data packet is transmitted to the boundary node instead of being routed to another topology, and the PDU may be delivered to the upper layer of the BAP layer of the boundary node after the header is removed.
Optionally, in a case that the destination node of the packet does not belong to the second topology, the generating, by a generation node in a first topology, a packet includes:
Optionally, in a case that the destination node of the packet does not belong to the second topology, the BAP destination address in the first information in the header of the packet generated by the generation node is different from all addresses of the boundary node.
Optionally, after receiving the BAP PDU, the boundary node may determine whether a BAP destination address in the BAP header is an address of the boundary node. If no, the boundary node determines that the BAP destination address in the first information is different from all addresses of the boundary node, and the data may be submitted to a next hop (a next IAB node) according to legacy behavior.
In this embodiment of this application, a boundary node determines ownership of a destination node of a packet based on first information in a header of the packet in a first topology; in a case that it is determined that the destination node of the packet belongs to a second topology, re-write the header of the packet based on the first information; and transmit a re-written packet to the destination node, to ensure that the boundary node can directly distinguish, from the header of the received packet, whether the data needs to be routed to the second topology, thereby reducing difficulty of data routing and saving resources.
It should be noted that the data routing method provided in the embodiments of this application may be performed by a data routing apparatus, or a control module that is in the data routing apparatus and that is configured to perform the data routing method. In the embodiments of this application, an example in which the data routing apparatus performs the data routing method is used to describe the data routing apparatus provided in the embodiments of this application.
The first receiving module 910 is configured to receive a packet in a first topology.
The first determining module 920 is configured to determine ownership of a destination node of the packet based on first information in a header of the packet.
The first re-writing module 930 is configured to: in a case that the destination node of the packet belongs to a second topology, re-write the header of the packet based on the first information.
The first transmission module 940 is configured to transmit a re-written packet to the destination node in the second topology.
Optionally, the data routing apparatus may receive a packet in a first topology by using the first receiving module 910; determine ownership of a destination node of the packet based on first information in a header of the packet by using the first determining module 920; in a case that the destination node of the packet belongs to a second topology, re-write the header of the packet based on the first information by using the first re-writing module 930; and then transmit a re-written packet to the destination node in the second topology by using the first transmission module 940.
In this embodiment of this application, a boundary node determines ownership of a destination node of a packet based on first information in a header of the packet in a first topology; in a case that it is determined that the destination node of the packet belongs to a second topology, re-write the header of the packet based on the first information; and transmit a re-written packet to the destination node, to ensure that the boundary node can directly distinguish, from the header of the received packet, whether the data needs to be routed to the second topology, thereby reducing difficulty of data routing and saving resources.
Optionally, the first determining module is further configured to:
Optionally, the first re-writing module is further configured to:
Optionally, the first determining module is further configured to:
Optionally, the first determining module is further configured to:
Optionally, the first information further includes a second path ID, and the second path ID is used to indicate a routing path from the boundary node to the destination node in the second topology.
Optionally, the first re-writing module is further configured to:
Optionally, the first determining module is further configured to:
Optionally, the first determining module is further configured to:
Optionally, the first information further includes a fourth path ID, and the fourth path ID is used to indicate a routing path from the boundary node to the destination node in the second topology; and
Optionally, the first determining module is further configured to:
Optionally, the first information further includes a seventh path ID, and the seventh path ID is used to indicate a routing path from a generation node of the packet to the boundary node in the first topology.
Optionally, the first determining module is further configured to:
In this embodiment of this application, a boundary node determines ownership of a destination node of a packet based on first information in a header of the packet in a first topology; in a case that it is determined that the destination node of the packet belongs to a second topology, re-write the header of the packet based on the first information; and transmit a re-written packet to the destination node, to ensure that the boundary node can directly distinguish, from the header of the received packet, whether the data needs to be routed to the second topology, thereby reducing difficulty of data routing and saving resources.
The data routing apparatus in this embodiment of this application may be an apparatus, an apparatus or an electronic device with an operating system, or a component, an integrated circuit, or a chip in a terminal. The apparatus or the electronic device may be a mobile terminal or a non-mobile terminal. For example, the mobile terminal may include but is not limited to the foregoing listed types of the terminal 11. The non-mobile terminal may be a server, a network attached storage (Network Attached Storage, NAS), a personal computer (personal computer, PC), a television (television, TV), a teller machine, or a self-service machine. This is not specifically limited in this embodiment of this application.
The first sending module 1020 is configured to send the packet to a boundary node.
Optionally, the data routing apparatus may generate a packet in a first topology by using the first generation module 1010, where a header of the packet includes first information, and the first information is used to indicate ownership of a destination node of the packet; and send the packet to a boundary node by using the first sending module 1020.
In this embodiment of this application, a boundary node determines ownership of a destination node of a packet based on first information in a header of the packet in a first topology; in a case that it is determined that the destination node of the packet belongs to a second topology, re-write the header of the packet based on the first information; and transmit a re-written packet to the destination node, to ensure that the boundary node can directly distinguish, from the header of the received packet, whether the data needs to be routed to the second topology, thereby reducing difficulty of data routing and saving resources.
Optionally, the apparatus further includes:
Optionally, the first generation module is further configured to:
Optionally, the first generation module is further configured to:
Optionally, the first information further includes a second path ID, and the second path ID is used to indicate a routing path from the boundary node to the destination node in the second topology.
Optionally, the first generation module is further configured to:
Optionally, the first generation module is further configured to:
Optionally, the first information further includes a fourth path ID, and the fourth path ID is used to indicate a routing path from the boundary node to the destination node in the second topology.
Optionally, the first generation module is further configured to:
Optionally, the first generation module is further configured to:
In this embodiment of this application, a boundary node determines ownership of a destination node of a packet based on first information in a header of the packet in a first topology; in a case that it is determined that the destination node of the packet belongs to a second topology, re-write the header of the packet based on the first information; and transmit a re-written packet to the destination node, to ensure that the boundary node can directly distinguish, from the header of the received packet, whether the data needs to be routed to the second topology, thereby reducing difficulty of data routing and saving resources.
The data routing apparatus in this embodiment of this application may be an apparatus, an apparatus or an electronic device with an operating system, or a component, an integrated circuit, or a chip in a terminal. The apparatus or the electronic device may be a mobile terminal or a non-mobile terminal. For example, the mobile terminal may include but is not limited to the foregoing listed types of the terminal 11. The non-mobile terminal may be a server, a network attached storage (Network Attached Storage, NAS), a personal computer (personal computer, PC), a television (television, TV), a teller machine, or a self-service machine. This is not specifically limited in this embodiment of this application.
The data routing apparatus provided in this embodiment of this application can implement the processes implemented in the method embodiments of
Optionally,
An embodiment of this application further provides a boundary node, including a processor and a communication interface. The communication interface is configured to:
The processor is configured to:
The communication interface is further configured to:
This boundary node embodiment corresponds to the foregoing boundary node method embodiment. Each implementation process and implementation of the foregoing method embodiment may be applicable to this boundary node embodiment, and a same technical effect can be achieved.
Specifically, an embodiment of this application further provides a boundary node.
The band processing apparatus may be located in the baseband apparatus 1203. The method performed by the boundary node in the foregoing embodiment may be implemented in the baseband apparatus 1203. The baseband apparatus 1203 includes a processor 1204 and a memory 1205.
The baseband apparatus 1203 may include, for example, at least one baseband board, where a plurality of chips are disposed on the baseband board. As shown in
The baseband apparatus 1203 may further include a network interface 1206, configured to exchange information with the radio frequency apparatus 1202. For example, the interface is a common public radio interface (common public radio interface, CPRI for short).
Specifically, the boundary node in this embodiment of the present invention further includes an instruction or a program that is stored in the memory 1205 and that can be run on the processor 1204. The processor 1204 invokes the instruction or the program in the memory 1205 to perform the method performed by the modules shown in
The processor 1204 is configured to:
In this embodiment of this application, a boundary node determines ownership of a destination node of a packet based on first information in a header of the packet in a first topology; in a case that it is determined that the destination node of the packet belongs to a second topology, re-write the header of the packet based on the first information; and transmit a re-written packet to the destination node, to ensure that the boundary node can directly distinguish, from the header of the received packet, whether the data needs to be routed to the second topology, thereby reducing difficulty of data routing and saving resources.
Optionally, the processor 1204 is further configured to:
Optionally, the processor 1204 is further configured to:
Optionally, the processor 1204 is further configured to:
Optionally, the processor 1204 is further configured to:
Optionally, the first information further includes a second path ID, and the second path ID is used to indicate a routing path from the boundary node to the destination node in the second topology.
Optionally, the processor 1204 is further configured to:
Optionally, the processor 1204 is further configured to:
Optionally, the processor 1204 is further configured to:
Optionally, the first information further includes a fourth path ID, and the fourth path ID is used to indicate a routing path from the boundary node to the destination node in the second topology; and
Optionally, the processor 1204 is further configured to:
Optionally, the first information further includes a seventh path ID, and the seventh path ID is used to indicate a routing path from a generation node of the packet to the boundary node in the first topology.
Optionally, the processor 1204 is further configured to:
In this embodiment of this application, a boundary node determines ownership of a destination node of a packet based on first information in a header of the packet in a first topology; in a case that it is determined that the destination node of the packet belongs to a second topology, re-write the header of the packet based on the first information; and transmit a re-written packet to the destination node, to ensure that the boundary node can directly distinguish, from the header of the received packet, whether the data needs to be routed to the second topology, thereby reducing difficulty of data routing and saving resources.
An embodiment of this application further provides a generation node, including a processor and a communication interface. The processor is configured to:
The communication interface is configured to:
This generation node device embodiment corresponds to the foregoing generation node method embodiment. Each implementation process and implementation of the foregoing method embodiment may be applicable to this generation node embodiment, and a same technical effect can be achieved.
Specifically, an embodiment of this application further provides a generation node.
The band processing apparatus may be located in the baseband apparatus 1303. The method performed by the generation node in the foregoing embodiment may be implemented in the baseband apparatus 1303. The baseband apparatus 1303 includes a processor 1304 and a memory 1305.
The baseband apparatus 1303 may include, for example, at least one baseband board, where a plurality of chips are disposed on the baseband board. As shown in
The baseband apparatus 1303 may further include a network interface 1306, configured to exchange information with the radio frequency apparatus 1302. For example, the interface is a common public radio interface (common public radio interface, CPRI for short).
Specifically, the generation node in this embodiment of the present invention further includes an instruction or a program that is stored in the memory 1305 and that can be run on the processor 1304. The processor 1304 invokes the instruction or the program in the memory 1305 to perform the method performed by the modules shown in
The processor 1304 is configured to:
In this embodiment of this application, a boundary node determines ownership of a destination node of a packet based on first information in a header of the packet in a first topology; in a case that it is determined that the destination node of the packet belongs to a second topology, re-write the header of the packet based on the first information; and transmit a re-written packet to the destination node, to ensure that the boundary node can directly distinguish, from the header of the received packet, whether the data needs to be routed to the second topology, thereby reducing difficulty of data routing and saving resources.
Optionally, the processor 1304 is further configured to:
Optionally, in a case that the destination node of the packet is the boundary node, the processor 1304 is further configured to:
Optionally, in a case that the destination node of the packet belongs to a second topology, the processor 1304 is further configured to:
Optionally, the first information further includes a second path ID, and the second path ID is used to indicate a routing path from the boundary node to the destination node in the second topology.
Optionally, in a case that the destination node of the packet is the boundary node, the processor 1304 is further configured to:
Optionally, in a case that the destination node of the packet belongs to a second topology, the processor 1304 is further configured to:
Optionally, the first information further includes a fourth path ID, and the fourth path ID is used to indicate a routing path from the boundary node to the destination node in the second topology.
Optionally, in a case that the destination node of the packet is the boundary node, the processor 1304 is further configured to:
Optionally, in a case that the destination node of the packet does not belong to the second topology, the processor 1304 is further configured to:
In this embodiment of this application, a boundary node determines ownership of a destination node of a packet based on first information in a header of the packet in a first topology; in a case that it is determined that the destination node of the packet belongs to a second topology, re-write the header of the packet based on the first information; and transmit a re-written packet to the destination node, to ensure that the boundary node can directly distinguish, from the header of the received packet, whether the data needs to be routed to the second topology, thereby reducing difficulty of data routing and saving resources.
An embodiment of this application further provides a readable storage medium. The readable storage medium stores a program or an instruction, and the program or the instruction is executed by a processor to implement the processes in the foregoing data routing method embodiment, and a same technical effect can be achieved. To avoid repetition, details are not described herein again.
The processor is a processor in the terminal in the foregoing embodiment. The readable storage medium includes a computer readable storage medium, for example, a read-only memory (Read-Only Memory, ROM), a random access memory (Random Access Memory, RAM), a magnetic disk, or an optical disc.
An embodiment of this application further provides a chip. The chip includes a processor and a communication interface, the communication interface is coupled to the processor, and the processor is configured to run a program or an instruction to implement the processes of the foregoing data routing method embodiment, and a same technical effect can be achieved. To avoid repetition, details are not described herein again.
It should be understood that the chip mentioned in this embodiment of this application may also be referred to as a system-level chip, a system chip, a chip system, or an on-chip system chip.
An embodiment of this application further provides a computer program/program product. The computer program/program product is stored in a non-transient storage medium, and the program/program product is executed by at least one processor to implement the processes of the foregoing data routing method embodiment, and a same technical effect can be achieved. To avoid repetition, details are not described herein again.
It should be noted that, in this specification, the terms “include”, “comprise”, or their any other variant is intended to cover a non-exclusive inclusion, so that a process, a method, an article, or an apparatus that includes a list of elements not only includes those elements but also includes other elements which are not expressly listed, or further includes elements inherent to such process, method, article, or apparatus. An element preceded by “includes a . . . ” does not, without more constraints, preclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element. In addition, it should be noted that the scope of the method and the apparatus in the embodiments of this application is not limited to performing functions in an illustrated or discussed sequence, and may further include performing functions in a basically simultaneous manner or in a reverse sequence according to the functions concerned. For example, the described method may be performed in an order different from that described, and the steps may be added, omitted, or combined. In addition, features described with reference to some examples may be combined in other examples.
| Number | Date | Country | Kind |
|---|---|---|---|
| 202110893480.9 | Aug 2021 | CN | national |
This application is a continuation of International Application No. PCT/CN2022/108946 filed on Jul. 29, 2022, which claims priority of Chinese Patent Application No. 202110893480.9 filed on Aug. 4, 2021, which are incorporated herein by reference in their entireties.
| Number | Date | Country | |
|---|---|---|---|
| Parent | PCT/CN2022/108946 | Jul 2022 | WO |
| Child | 18430463 | US |
