This patent document generally relates to systems, devices, and techniques for wireless communications.
Wireless communication technologies are moving the world toward an increasingly connected and networked society. The rapid growth of wireless communications and advances in technology has led to greater demand for capacity and connectivity. Other aspects, such as energy consumption, device cost, spectral efficiency, and latency are also important to meeting the needs of various communication scenarios. In comparison with the existing wireless networks, next generation systems and wireless communication techniques need to provide support for an increased number of users and devices.
This document relates to methods, systems, and devices for data transfer schemes in wireless communications.
In one aspect, a wireless communication method is disclosed. The method performing, by a first node of an integrated access and backhaul (IAB) network, a data transmission with a second node in the IAB.
In another aspect, a wireless communication method is disclosed. The method includes configuring, by a first node of an integrated access and backhaul (IAB) network connected to a second node of the IAB network, a packet transmission that is routable to a third node of the IAB network.
In another aspect, a wireless communication method is disclosed. The method includes configuring, by a central unit of an IAB (integrated access and backhaul) donor, a distributed unit of the IAB-donor to allow a packet transmission to be routable via the distributed unit of the IAB-donor.
These, and other features, are described in the present document.
The disclosed technology provides implementations and examples of resource coordination schemes in wireless communications.
Integrated access and backhaul (IAB) supports wireless backhauling via new radio (NR) enabling flexible and very dense deployment of NR cells while reducing the need for wireline transport infrastructure. Compared with LTE, NR has a larger available bandwidth. The use of massive MIMO and multi-beam makes the research and application of IAB links possible. Through wireless backhaul links and relay links, dense NR cell networks can be deployed with more flexible without the need to increase the dense deployment of transmission networks accordingly.
The data of the UE can be transmitted between the access nodes through the wireless backhaul link. For example, the access node B may send the data received from the UE to the access node A through a wireless backhaul link, and then the access node A sends the UE data to the core network element. For the downlink, the core network element can send the UE data packet to the access node A, and then the access node A sends the UE data to the access node B through the wireless backhaul link, and the access node B sends the UE through the access link so that the data is sent to the UE. The access link and the backhaul link can use the same or different carrier frequencies. In addition, the data of the UE may need to be transmitted through the multi-hop relay backhaul link between the access node and the core network.
Supporting the separate deployment of a central unit (CU)/distributed unit (DU) and/or supporting an IAB function in CU/DU separated deployment scenario is an important technical aspects in NR. Currently, it is not always available for an IAB donor-DU to forward a packet with IP address not in its subnet, where the IP address is a source IP address and/or a destination IP address. Implementations of the disclosed technology provide mechanisms to enable such IP packet transmission over the donor-DU.
Various implementations discussed in this patent document can be applied to an IAB topology as shown in
In
The IAB node 3 is originally connected with the IAB node 1 (hereinafter “first IAB node”) that is connected with the first IAB donor DU 12 and the first IAB donor CU 14. Under some circumstances, the first IAB donor CU 14 may decide the data transmission of a packet originally scheduled to the first IAB donor CU 14 to be routed to the IAB node 2 that is connected with the second IAB donor DU 22. After the routing to the second IAB donor DU 22, the traffic received from the IAB node 4 is transferred to the second IAB donor DU 22 instead of the first IAB donor DU 12. The disclosed technology provide various implementations to assist the data transmission via the second IAB donor. Although the IP-based tunneling is discussed in the below as the example of the data transmission, the data transmission is not limited thereto and the implementations of the disclosed technology can be applied to various transmission techniques in wireless communications.
Implementation 1
This implementation proposes to establish an IP-based tunneling between the 1st IAB donor DU 12 and the 2nd IAB donor DU 22 to enable data transfer via the 2nd IAB donor DU 22. The techniques discussed in this implementation can be applied to the IAB topology shown in
The IAB donor CU may send a configuration to the IAB donor DU, which includes the mapping between an identity of the neighboring IAB donor DU and the belonging IP subnet or the IP prefix or IP addresses of the neighboring IAB donor DU. In some implementations, the IAB donor CU may send an indication to the IAB donor DU that the packet with such IP information can be transferred through the tunnel between the donor DU and the neighboring donor DU.
Downlink (DL)
Step 1: The 1st IAB-donor CU-CP (a control plane of the 1st IAB-donor-CU 14) may send, to the 2nd IAB-donor-CU 24, at least one of following information:
Step 2: The 2nd IAB-donor-CU 24 may send, to the 2nd IAB-donor-DU 22, at least one of following information:
Step 3: The 2nd IAB-donor-DU 22 may send, to the 2nd IAB-donor-CU 24, at least one of following information:
Step 4: The 2nd IAB-donor-CU 24 may send, to the 1st IAB-donor CU-CP, at least one of following information:
Step 5: The 1st donor CU 14 may configure data transmission to support the data transfer via the second IAB donor DU 22. In some implementations, the 1st IAB-donor-CU 14 updates the Downlink Traffic to Routing ID Mapping Configuration for the 1st IAB-donor-DU 12. In some implementation, such update may be done by removing the entries related to the migrated packets. In some implementations, the 1st IAB-donor-CU 14 sends, to the 1st IAB-donor-DU 12, the data transmission configuration. Each entry of the data transmission configuration contains at least one of the following items:
Uplink (UL)
Step 1: The 1st IAB-donor CU-CP may send, to the 2nd IAB-donor-CU 24, at least one of following information:
Step 2: The 2nd IAB-donor-CU 24 may send, to the 2nd IAB-donor-DU 22, at least one of the following information:
Step 3: The 2nd IAB-donor-DU 22 may send, to the 2nd IAB-donor-CU, at least one of the following information:
Step 4: The 2nd IAB-donor-CU 24 may send, to the 1st IAB-donor CU, at least one of the following information:
Step 5: The 1st IAB-donor CU may send, to the 1st IAB-donor-DU 12, at least one of the following information:
Step 6: The descendant node (the IAB node 3) still uses the previous IP address, which is in the 1st IAB-donor-DU domain, to encapsulate the UL packet. After receiving such packet, the 2nd IAB-donor-DU 22 can recognize that the source IP address is not in its own IP subnet but in the 1st IAB-donor-DU domain. Then the packet will be delivered to the 1st IAB-donor-DU via IP tunneling.
Implementation 2
This implementation proposes to establish an IP-based tunneling between the 1st IAB-donor-CU 14 and the 2nd IAB-donor-DU 22 to enable the data transfer via the 2nd IAB-donor-DU 22. The 1st donor CU 14 comprises the 1st donor CU-CP (control plane) and the 1st donor CU-UP (user plane).
Downlink (DL)
Step 1: The 1st IAB-donor CU-CP may send, to the 2nd IAB-donor-CU 24, at least one of the following information:
Step 2: The 2nd IAB-donor-CU 24 may send, to the 2nd IAB-donor-DU, at least one of the following information:
Step 3: The 2nd IAB-donor-DU 22 may send, to the 2nd IAB-donor-CU 24, at least one of the following information:
Step 4: The 2nd IAB-donor-CU 24 may send, to the 1st IAB-donor CU-CP, at least one of the following information:
Step 5: the 1st IAB-donor CU-UP does not know whether a packet needs to be delivered via an IP tunnel. So the 1st IAB-donor CU-CP may need to configure the 1st IAB-donor CU-UP the downlink traffic via IP tunnel configuration, which includes at least one of the following items:
Each items above is optional and can be included in or omitted from the configuration based on implementations.
Uplink (UL)
Step 1: The 1st IAB-donor CU-CP may send, to the 2nd IAB-donor-CU 24, at least one of the following information:
Step 2: The 2nd IAB-donor-CU 24 may send, to the 2nd IAB-donor-DU 22, at least one of the following information:
Step 3: The 2nd IAB-donor-DU 22 may send, to the 2nd IAB-donor-CU 24, at least one of the following information:
Step 4: The 2nd IAB-donor-CU may send, to the 1st IAB-donor CU-CP, at least one of the following information:
Step 5: The 1st IAB-donor CU-CP may send, to the 1st IAB-donor CU-UP, at least one of the following information:
Step 6: The descendant node still uses the previous IP address, which is in the 1st IAB-donor-DU domain, to encapsulate the UL packet. After receiving such packet, the 2nd IAB-donor-DU 22 can recognize that the source IP address is not in its own IP subnet but the packet can be delivered to the 1st donor CU-UP via IP tunneling.
Implementation 3
This implementation focuses on the DL packet transmission from the 2nd donor DU 22 to the descendant node. The 1st donor CU 14 provides the 2nd donor CU 24 with the IP information of DL packets, e.g. the belonging IP subnet or the IP prefix or IP addresses of the DL packet. Then, the 2nd donor CU 24 sends the 2nd donor DU 22 the IP information. In some implementations, the 2nd donor CU 24 sends an indication to inform the 2nd donor DU 22 that DL packets with the IP information need to be allowed to be routed. In some implementations, the 1st donor CU 22 sends an indication to inform the second donor DU 22 that DL packets with the IP information need to be allowed to be routed.
Implementation 4
This implementation focuses on the DL packet transmission from the 2nd donor DU 22 to the descendant node. The 2nd donor DU 22 allocates new IP addresses, and 1st donor-CU uses the new IP addresses to encapsulate DL packets, but the new IP addresses are not configured to the descendant node. As a result, the descendant node would discard these DL packets. To solve this problem, the first donor CU 12 provides the descendant node with the IP information of the DL packets, where the IP address information can be IP addresses, or IP prefixes or IP subnets identity. In some implementations, an indication, which informs the descendant node that DL packets with the IP information need to be allowed to be routed.
Implementation 5
This implementation proposes establishing an IP-based tunneling between the source CU (e.g., the first donor CU 14 in
In DL, the additional IP header is added by the 1st donor CU-UP or CU-CP and is removed by the boundary node.
In UL, the boundary node adds an additional IP header to the packet received from its child node (e.g., the IAB node 4 in
In both DL and UL scenarios, the IP address in the additional IP header is routable via the 2nd donor DU 22.
The boundary node, as an intermediate IAB node, needs to support IP header addition/removal. In some implementations, not all the DL/UL packet requires to be added/removed the additional IP header, and thus the IAB-donor CU-CP needs to inform the IAB-donor CU-UP the packet requiring additional IP header adding or removal.
Assume that the traffic of an F1-U tunnel is routed via the 2nd donor DU 22. The 1st donor CU-CP may send the 1st donor CU-UP the IP address of the F1-U tunnel, which is in the second donor DU's IP domain, together with an indication to inform the 1st donor CU-UP that the packet from the F1-U tunnel requires additional IP header adding or removal. The 1st donor CU-CP may send another indication to inform the 1st donor CU-UP that the IP address is the destination IP address of the additional IP header for the DL IP packet.
In some implementations, the boundary IAB node (e.g., IAB node 3 in
In some implementations, the 1st donor CU 14 can send, to the boundary IAB node, a backhaul adaptation protocol (BAP) address of a child node together with an indication informing that the packet from/to the child node needs additional IP header addition/removal. The child-node BAP address can be used to identify the child node of the boundary node. In some implementations, the 1st donor CU 14 can send, to the boundary IAB node, a UL/DL ingress BH RLC channel together with an indication informing that the packet from the UL/DL ingress BH RLC channel needs additional IP header addition/removal. In some implementations, the 1st donor CU 14 can send, to the boundary IAB node, a UL/DL egress BH RLC channel together with an indication informing that the packet to the UL/DL egress BH RLC channel needs additional IP header addition/removal. In some implementations, the 1st donor CU 14 can send, to the boundary IAB node, a routing ID and an indication informing that the packet with the routing ID needs additional IP header addition/removal. In some implementations, the 1st donor CU 14 can send, to the boundary IAB node, at least one of a UE bearer identity, an indication indicating that the packet from the UE bearer needs the adding or the removing of the packet header.
In some implementations, all the UL packets delivered to the second parent node need additional IP header addition.
In some implementations, the DL packet from the second parent node and to be forwarded needs additional IP header removal.
In some implementations, the 1st donor CU 14 indicates the boundary node which IP address(es) is used for additional IP header addition. Alternatively, the boundary node may decide the IP address by itself.
Implementation 6
This implementation discusses IP address rewritten by a second donor DU (e.g., the second donor DU 22 in
The first donor CU 12 uses the IP addresses anchoring to the second donor DU 22 for packet transmission. When the second donor DU 22 receives one or more those packets, it replaces those IP addresses by the ones used by descendant nodes (e.g., the IAB node 4) which are anchored at the first donor DU 12.
The second donor CU 24 configures the IP address mapping for the second donor DU 22. The IP address mapping configured by the second donor CU 24 includes at least one of the following:
Each items above is optional and can be included in or omitted from the configuration based on implementations. By configuring the IP address mapping including the above information, the second donor CU 24 informs the second donor DU 22 that the IP address needs to be rewritten for the packet with the above information. The IP address to be rewritten is also sent by the second donor CU 24 to the second donor DU 22. When receiving a downlink (DL) packet, the second donor DU 22 replaces the source IP address with the new IP address (e.g., the IP address to be re-written).
Implementation 7
Implementation 7 will be discussed with reference to
The 1st donor CU 14 determines to set up GTP-U tunnel between the first donor DU 12 and the second donor DU 22. Alternatively, the first donor CU 14 sends an F1AP message to the first donor DU 12 about the establishment of the GTP-U tunnel. The 1st donor CU 14 may include the identity of the second donor DU 22 in the F1AP message. The 1st donor DU 12 may responds, to the 1st donor CU 1, an IP address and TEID (unique tunnel endpoint identifier), which are used to set up GTP-U tunnel between the 1st donor DU 12 and the second donor DU 22.
The 1st donor CU 14 sends an XnAP message to the second donor CU 2 including an IP address and TEID, which are used to set up GTP-U tunnel between the 1st donor DU 12 and the second donor DU 22. The 1st donor CU 14 may also send the identity of the 1st donor DU 12 to the second donor CU 24. The 1st donor CU 14 may include the identity of the second donor DU 22 in the XnAP message as well. Then the second donor CU 24 sends an F1AP message to the second donor DU 22, including, optionally the identity of the first donor DU 12, an IP address and TEID, which are used to set up GTP-U tunnel between the 1st donor DU 12 and the second donor DU 22.
In some implementations, the second donor DU 22 sends, to the second donor CU 24, an IP address and TEID, which are used to set up GTP-U tunnel between the 1st donor DU 12 and the second donor DU 22, via an F1AP message. The second donor CU 24 may respond, to the 1st donor CU 14, an XnAP message that includes at least one of the following:
Each items above is optional and can be included in or omitted from the configuration based on implementations.
Upon receiving the XnAP message, the 1st donor CU 14 may send, to the 1st donor DU 12, at least one of the following information:
Each items above is optional and can be included in or omitted from the configuration based on implementations.
The second donor CU 24 determines routing ID of the migrated packet, and sends the routing IDs to the 1st donor CU 22. The 1st donor CU 22 may configure the 1st donor DU so that the packet will be delivered to the neighbouring donor DU via GTP-U tunnel. The configuration performed by the 1st donor CU 22 may include at least one of the following:
Each items above is optional and can be included in or omitted from the configuration based on implementations.
The implementations as discussed above will apply to a wireless communication.
Additional features of the above-described methods/techniques that may be preferably implemented in some implementations are described below using a clause-based description format.
It is intended that the specification, together with the drawings, be considered exemplary only, where exemplary means an example and, unless otherwise stated, does not imply an ideal or a preferred embodiment. As used herein, the use of “or” is intended to include “and/or”, unless the context clearly indicates otherwise.
Some of the embodiments described herein are described in the general context of methods or processes, which may be implemented in one embodiment by a computer program product, embodied in a computer-readable medium, including computer-executable instructions, such as program code, executed by computers in networked environments. A computer-readable medium may include removable and non-removable storage devices including, but not limited to, Read Only Memory (ROM), Random Access Memory (RAM), compact discs (CDs), digital versatile discs (DVD), etc. Therefore, the computer-readable media can include a non-transitory storage media. Generally, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer- or processor-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps or processes.
Some of the disclosed embodiments can be implemented as devices or modules using hardware circuits, software, or combinations thereof. For example, a hardware circuit implementation can include discrete analog and/or digital components that are, for example, integrated as part of a printed circuit board. Alternatively, or additionally, the disclosed components or modules can be implemented as an Application Specific Integrated Circuit (ASIC) and/or as a Field Programmable Gate Array (FPGA) device. Some implementations may additionally or alternatively include a digital signal processor (DSP) that is a specialized microprocessor with an architecture optimized for the operational needs of digital signal processing associated with the disclosed functionalities of this application. Similarly, the various components or sub-components within each module may be implemented in software, hardware or firmware. The connectivity between the modules and/or components within the modules may be provided using any one of the connectivity methods and media that is known in the art, including, but not limited to, communications over the Internet, wired, or wireless networks using the appropriate protocols.
While this document contains many specifics, these should not be construed as limitations on the scope of an invention that is claimed or of what may be claimed, but rather as descriptions of features specific to particular embodiments. Certain features that are described in this document in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or a variation of a sub-combination. Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results.
Only a few implementations and examples are described and other implementations, enhancements and variations can be made based on what is described and illustrated in this disclosure.
This patent document is a continuation of and claims benefit of priority to International Patent Application No. PCT/CN2021/110179, filed on Aug. 3, 2021. The entire content of the before-mentioned patent application is incorporated by reference as part of the disclosure of this application.
Number | Date | Country | |
---|---|---|---|
Parent | PCT/CN2021/110179 | Aug 2021 | US |
Child | 18430441 | US |