A method, an apparatus, and a computer readable medium for wireless communication

By establishing redundant paths between CUs in the IAB node and utilizing the combined use of BAP addresses and CU IDs, along with special field processing, the signaling exchange and data packet routing problems under CU redundancy conditions are solved, thus achieving robustness and load balancing of the wireless communication system.

CN116326168BActive Publication Date: 2025-11-28ZTE CORP
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202080105887.4
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2020-10-22
Publication Date
2025-11-28
Estimated Expiration
2040-10-22

AI Technical Summary

Technical Problem

In existing technologies, topology redundancy research on IAB nodes mainly focuses on redundancy within CUs, failing to effectively address signaling exchange and packet routing issues under inter-CU redundancy conditions. This results in inefficient operation and unbalanced load when the backhaul link is blocked.

Method used

By establishing redundant paths between CUs, using the combined use of BAP addresses and CU IDs, and combining OAM configuration and special field processing, packet routing and load balancing of IAB nodes are achieved, including steps such as MeasurementReport message transmission, XnAP message exchange, F1AP message acknowledgment, IP address allocation, and RRCReconfiguration process.

Benefits of technology

Robust operation and load balancing are achieved under redundant paths between CUs, ensuring correct data packet transmission and improving the reliability and efficiency of the wireless communication system.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116326168B_ABST
    Figure CN116326168B_ABST
Patent Text Reader

Abstract

A method of wireless communication is described. The method includes transmitting, from a first centralized unit (CU) configured to communicate with an integrated access and backhaul (IAB) node, a first message to a second CU and receiving, by the first CU, a second message including configuration information, where the first message includes at least one of an identification of the IAB node, an identification of a user equipment in communication with the IAB node.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present Application generally relates to systems, devices, and techniques for wireless communication. BACKGROUND

[0002] Wireless communication technologies are pushing the world towards an increasingly interconnected and networked society. The rapid growth and advancement of wireless communication technologies have resulted in greater demands for capacity and connectivity. Other aspects, such as energy consumption, device cost, spectral efficiency, and latency, are also important to meet the needs of various communication scenarios. Next generation systems and wireless communication technologies need to provide support for more users and devices compared to existing wireless networks. SUMMARY

[0003] The present application relates to methods, systems, and devices for signaling exchange schemes in wireless communications.

[0004] In one aspect, a method of wireless communication is disclosed. The method includes transmitting, from a first centralized unit (CU) configured to communicate with an integrated access and backhaul (IAB) node, a first message to a second CU, and receiving, by the first CU, a second message including configuration information, wherein the first message includes at least one of an identification of the IAB node, an identification of a user equipment in communication with the IAB node.

[0005] In another aspect, a method of wireless communication is disclosed. The method includes receiving, from a first centralized unit (CU) configured to communicate with an integrated access and backhaul (IAB) node, a first message, and transmitting, by the second CU to the first CU, a second message including configuration information.

[0006] In another aspect, a wireless communication apparatus is disclosed that includes a processor configured to perform the disclosed methods.

[0007] In another aspect, a computer readable medium having code stored thereon is disclosed. When implemented by a processor, the code causes the processor to implement the methods described in the present application.

[0008] These and other features are described in the present application. BRIEF DESCRIPTION OF DRAWINGS

[0009] Figure 1 An example of a network deployed with integrated access and backhaul links is shown.

[0010] Figure 2 Inter-central unit (CU) topology redundancy is shown.

[0011] Figure 3 An example of a method for wireless communication based on some embodiments of the disclosed technology is shown.

[0012] Figure 4 An example of a method for wireless communication is shown based on some embodiments of the disclosed technology.

[0013] Figure 5 An example of wireless communication including a base station (BS) and a user equipment (UE) is shown based on some embodiments of the disclosed technology.

[0014] Figure 6 An example of a block diagram of a portion of an apparatus based on some embodiments of the disclosed technology is shown. DETAILED DESCRIPTION

[0015] The disclosed technology provides embodiments and examples of signaling exchange schemes in wireless communication. Some embodiments of the disclosed technology provide signaling interactions between a donor and an IAB node when the IAB node performs dual connectivity.

[0016] Compared with LTE, NR has a larger available bandwidth, and the use of massive MIMO and multi-beam makes it possible to research and apply integrated access and backhaul links (IAB). Through wireless backhaul links and relay links, dense NR cell networks can be deployed more flexibly without increasing the dense deployment of transmission networks accordingly. Figure 1 An example of a network deployed with integrated access and backhaul links is shown in FIG. 1. In FIG. 1, A, B, and C are all access nodes, and a user equipment can access access nodes A, B, and C through an access link. Only access node A has a wired connection with a core network, and access nodes B and C have no wired connection with core network elements. An access node that supports wireless access of a UE and wirelessly transmits data is called an IAB node (IAB node). Figure 1 In FIG. 1, A, B, and C are all access nodes, and a user equipment can access access nodes A, B, and C through an access link. Only access node A has a wired connection with a core network, and access nodes B and C have no wired connection with core network elements. An access node that supports wireless access of a UE and wirelessly transmits data is called an IAB node (IAB node).

[0017] An access node that provides wireless backhaul functionality for IAB nodes to connect to a core network is referred to as an IAB donor (IAB) donor. Data for a UE can be transported between access nodes over wireless backhaul links. For example, an access node B can send data received from a UE to an access node A over a wireless backhaul link, and then the access node A sends the UE data to a core network element. For downlink, a core network element can send a UE data packet to the access node A, and then the access node A sends the UE data to the access node B over a wireless backhaul link, and the access node B sends the UE data to the UE over an access link. The access link and the backhaul link can use the same or different carrier frequencies. Further, data for a UE can need to be transported over multi-hop relay backhaul links between access nodes and a core network. Further, support for separate deployment of centralized unit (CU) / distributed unit (DU) is an important technical feature of NR, and thus it is necessary to support IAB functionality in the separate deployment scenario of CU / DU. The goal of topology redundancy is to, for example, enable robust operation in case of backhaul link blockage, and to balance the load on backhaul links. IAB needs to consider the establishment and management of topology redundancy. Currently, topology redundancy research only focuses on intra-CU topology redundancy cases. However, it is agreed in Release 17 IAB to support inter-CU redundancy. Embodiments of the disclosed technology relate to the establishment and management of inter-CU topology redundancy.

[0018] Figure 2 An example of inter-CU topology redundancy is shown. IAB node 3 is referred to as a dual-connected IAB node, starting with a MCG link to the DU part of IAB node 1 and adding a SCG link to the DU part of IAB node 2. In this example, the DU part of IAB node 3 only establishes Fl-C (control plane) with donor CU 1. IAB node 4, IAB node 5, IAB node 6, IAB node 7, and IAB node 8 are child nodes of IAB node 3. A first path is established between IAB node 3 and donor CU 1, and an additional path (referred to as a second path) is established between IAB node 3 and donor CU 1 via a second path. Since the donor DU on the second path is different from the donor DU on the first path, a new IP address anchored at donor DU 2 will be assigned to IAB node 3 and downstream nodes.

[0019] Embodiment 1

[0020] During the procedure for establishing the second path, the BAP address of the dual connectivity IAB node (e.g., IAB node 3) and the BAP address of the upstream IAB node (e.g., IAB node 2) on the second path can be the same since the backhaul adaptation protocol (BAP) address is CU unique. As a result, the data packet that should be sent to the dual connectivity IAB node 3 will be passed by the upstream node to the upper layer. To solve this problem, the orthogonal BAP address space can be allocated to different CUs by operation, administration, and maintenance (OAM) configuration. Alternatively, the CU ID and BAP address can be jointly used to identify the IAB node, where the CU ID is the identifier of the donor CU. In this case, the dual connectivity IAB node and the downstream node can need to obtain the CU identifiers of the donor CU 1 and donor CU 2. The routing configuration of the IAB node and the donor DU for data packet forwarding needs to include the CU ID. Upon receiving a DL data packet, the IAB node determines whether to pass the data packet to the upper layer based on the CU ID and BAP address in the BAP header of the received data packet. Alternatively, the IAB node uses a special field in the BAP header and the BAP address to determine whether the received data packet needs to be passed to the upper layer. Specifically, once the BAP address of the received DL data packet matches the address of the IAB node itself, the IAB node further reads a special field (e.g., 1 bit in the BAP header). For example, if the special field is set to “0”, the IAB node passes the data packet to the upper layer. Otherwise, it forwards the data packet to the child node.

[0021] In the following, a procedure of establishing a redundant path in an IAB topology is described. In the following description, the IAB node can correspond to the IAB node 3 or any one of the subordinate IAB nodes (e.g., IAB nodes 4 to 8) shown in FIG. 1. Figure 2

[0022] Step 1: The MT part of the IAB node (IAB-MT) sends a MeasurementReport message to the DU part of the first parent node. The IAB node can be a dual connectivity IAB node. The MeasurementReport message is based on the measurement configuration previously received by the IAB-MT from the donor CU 1.

[0023] Step 2: The DU part of the first parent node sends an uplink (UL) RRC message transfer message to the donor CU 1 to convey the received MeasurementReport.

[0024] Step 3: The donor CU 1 sends a first Xn application protocol (XnAP) message to the donor CU 2. The first XnAP message can indicate the following information:

[0025] ​1) Identifier of the IAB node

[0026] 2) Identifier of the UE.

[0027] 3) IAB node indication of the IAB node. The host CU 2 can know whether the device supports IAB function based on the IAB node indication.

[0028] 4) Topology information reflecting the topology relationship of the IAB node, any child node, and downstream UEs.

[0029] 5) Load status of the IAB node.

[0030] 6) Bearer mapping configuration and routing configuration of the IAB node.

[0031] 7) Bearer related information. Each bearer is associated with a UE, an IAB-MT, or an IAB-DU. The bearer related information can include i) DRB related information including DRB ID and / or DRB QoS information, ii) QoS flow mapped to a DRB, or iii) BH RLC channel information including BH RLC channel ID and / or QoS parameters related to the BH RLC channel.

[0032] 8) Indication of non-UP traffic type transferred via the second path of the IAB node.

[0033] 9) BAP address of the IAB node.

[0034] 10) IAB-DU configuration including STC information and / or resource configuration.

[0035] The XnAP message can include at least one of the above items 1) to 10).

[0036] The XnAP message can be a non-UE associated message or a UE associated message. If it is a UE associated message, the host CU 1 sends several messages to the host CU 2, where each message is associated with an IAB-MT or a UE.

[0037] The host DU 2 and the host DU 1 can be in different subnets. In this case, the IAB node needs to be anchored at the IP address of the host DU 2 so that it can use the IP address to generate UL IP packets to be routed via the second path. The host CU 1 requests the IP address from the host CU 2 and then sends the IP address to the IAB node.

[0038] In some embodiments (regardless of which solution is employed), the XnAP message can also include a per-use individual IP address request for the IAB node, where the defined use is all traffic, Fl-U, Fl-C, and non-Fl. The per-use IP address request includes the number of IP addresses requested, the type of IP addresses requested, e.g., IPv4, IPv6 / IPv6 prefix.

[0039] Step 4: The host CU 2 sends FlAP messages on the second path to the host DU 2 and the one or more IAB nodes to confirm the admitted bearers and BH RLC channels. For example, in Figure 2 , the IAB node 2 corresponds to the IAB node on the second path. The host CU 2 then responds to the host CU 1 with a second XnAP message that can include admitted bearer information. Each bearer is associated with a UE, IAB-MT, or IAB-DU. The bearer information can include at least one of: i) DRB related information including DRB ID and / or DRB QoS information, ii) QoS flows mapped to a DRB, or iii) BH RLC channel information including BH RLC channel ID and / or QoS parameters related to the BH RLC channel.

[0040] In some embodiments, the second XnAP message can optionally include: (1) UL BH configuration for GTP tunnels including BAP routing ID, optional next hop BAP address, and egress BH RLC CH ID, and / or (2) UL BH information for non-UP traffic including IMP routing ID, optional next hop BAP address, and egress BH RLC CH ID.

[0041] In some embodiments, the second XnAP message can optionally include information related to the host DU 2 and the IAB node that is served by the host CU 2 and corresponds to an upstream node of the IAB node. Such information includes topology related information, an identifier of the host DU 2, an identifier of the IAB node, a BAP address, a load status, bearer mapping, and routing configuration.

[0042] The second XnAP message can optionally include an IAB-DU configuration including STC information and / or resource configuration. The host DU 2 configuration including STC information and / or resource configuration can optionally be sent to the host CU 1. The IAB-DU (e.g., Figure 2 The DU part of the IAB node 2 in

[0043] In some embodiments, the second XnAP message can be a non-UE associated message or a UE associated message.

[0044] If the host CU 1 requests the host CU 2 to allocate one or more IP addresses, the host CU 2 can initiate the IAB TNL address allocation procedure to obtain IP addresses from the host DU 2. The host CU 2 sends to the host CU 1 via the second XnAP message the IP addresses allocated for each usage of the IAB node. The one or more IP addresses of the host DU 2 can also be included in the message.

[0045] If the host CU 2 determines to setup SRB3 for the IAB node, it will provide the SRB3 configuration of the IAB node to the host CU 1 via the second XnAP message.

[0046] Step 5: The host CU 1 sends a DL RRC message transfer message to the first parent IAB node (e.g., IAB node 1 in Figure 2 which is the first parent node of the IAB node 3) including the generated RRCReconfiguration message.

[0047] Step 6: The first parent IAB node forwards the received RRCReconfiguration message to the MT of the IAB node 3.

[0048] Step 7: The MT of the IAB node responds with a RRCReconfigurationComplete message.

[0049] The RRCReconfiguration message can contain one or more TNL addresses of the IAB-DU which are anchored at the host DU 2. The message can also include the IP address of the host DU 2. Thus, the IAB node can infer the anchor point of the received IP address.

[0050] If the host CU 1 does not request IP addresses from the host 2, the IAB node can request IP addresses by sending an IABOtherInformation message. After receiving the IABOtherInformation message, the host CU 1 either requests IP addresses from the host 2 or forwards the IABOtherInformation message to the host CU 2. The message can be sent after step 9.

[0051] Step 8: The DU part of the first parent IAB node sends an UL RRC message transfer message to the host CU 1 to convey the received RRCReconfigurationComplete message.

[0052] If the MT part of the IAB node 3 establishes an RRC connection with the donor CU 2, the RRCReconfigurationComplete message includes the SN RRC response message for the donor CU 2, if needed. If the SN Reconfiguration Complete is received from the IAB-MT, the donor CU 1 informs the donor CU 2 that the IAB-MT has successfully completed the reconfiguration procedure via the SN Reconfiguration Complete message including the SN RRC response message.

[0053] Step 9: The random access procedure is performed at the DU part of the IAB node 2.

[0054] Step 10: The donor CU 2 sends the BH RLC channel and BAP-layer routing entry configuration for the IAB node (e.g. IAB node 2) and the donor DU 2 on the second path. These configurations can be performed in an earlier stage, e.g. immediately after step 4.

[0055] Step 11: The new TNL address is added to the one or more F1-C associations of the dual-connected IAB-DU with the donor CU 1. The donor CU 1 can configure the new UL BH information for the F1AP messages on the second path.

[0056] Step 12: The donor CU 1 can migrate its F1-U tunnels with the dual-connected IAB-DU from the first path to the second path via the UE CONTEXT MODIFICATION REQUEST message.

[0057] Step 13: The DU part of the dual-connected IAB node replies with the UE CONTEXT MODIFICATION RESPONSE message.

[0058] Steps 12 and 13 can be performed for a subset of the UE bearers, e.g. to balance the load between the first and the second path.

[0059] Embodiment 2

[0060] In this embodiment, the BAP address conflict is resolved by a negotiation between the donor CU 1 and the donor CU 2. In the following, a procedure for establishing a redundant path in an IAB topology is described. In the following description, the IAB nodes can correspond to the IAB node 3 or any of the child IAB nodes (as e.g. shown in Figure 2 IAB node 4 to IAB node 8).

[0061] Step 1: The MT part of the IAB node (IAB-MT) sends a MeasurementReport message to the DU part of the first parent node. The IAB node can be a dual- connected IAB node. The MeasurementReport message is based on the measurement configuration previously received by the IAB-MT from the donor CU 1.

[0062] Step 2: The DU part of the first parent node sends an uplink (UL) RRC message transfer message to the donor CU 1 to convey the received MeasurementReport.

[0063] Step 3: The donor CU 1 sends a first Xn application protocol (XnAP) message to the donor CU 2. The first XnAP message can indicate the following information:

[0064] 1) an identifier of the IAB node

[0065] 2) a UE identifier.

[0066] 3) an IAB node indication of the IAB node. The donor CU 2 can know whether the device supports IAB function based on the IAB node indication.

[0067] 4) topology information reflecting the topology relationship of the IAB node, any child node, and downstream UEs.

[0068] 5) a load status of the IAB node.

[0069] 6) a bearer mapping configuration and a routing configuration of the IAB node.

[0070] 7) bearer related information. Each bearer is associated with a UE, an IAB-MT, or an IAB-DU. The bearer related information can include i) DRB related information including a DRB ID and / or a DRB QoS information, ii) a QoS flow mapped to a DRB, or iii) BH RLC channel information including a BH RLC channel ID and / or a QoS parameter related to the BH RLC channel.

[0071] 8) an indication of a non-UP traffic type transferred via a second path of the IAB node.

[0072] 9) a BAP address of the IAB node.

[0073] 10) an IAB-DU configuration including STC information and / or resource configuration.

[0074] The XnAP message can include at least one of the above items 1) to 10).

[0075] The XnAP message can be a non-UE associated message or a UE associated message. If it is a UE associated message, the host CU 1 sends several messages to the host CU 2, where each message is associated with an IAB-MT or a UE.

[0076] The host DU 2 and the host DU 1 can be in different subnets. In this case, the IAB node needs to be anchored at an IP address at the host DU 2 so that it can use this IP address to generate UL IP packets that will be routed via the second path. The host CU 1 directly requests the IP address from the host CU 2 and then sends the IP address to the IAB node.

[0077] In some embodiments (regardless of which solution is employed), the XnAP message can also include a separate IP address request per usage of the IAB node, where the defined usage is all traffic, Fl-U, Fl-C, and non-Fl. Each usage of the IP address request includes the number of IP addresses requested, the type of IP addresses requested, e.g., IPv4, IPv6 / IPv6 prefix.

[0078] Step 4: The host CU 2 sends FlAP messages to the host DU 2 and the one or more IAB nodes on the second path to confirm the admitted bearers and BH RLC channels. For example, in Figure 2 , the IAB node 2 corresponds to the IAB node on the second path. The host CU 2 then responds to the host CU 1 with a second XnAP message that can include admitted bearer information. Each bearer is associated with a UE, IAB-MT, or IAB-DU. The bearer information can include at least one of: i) DRB related information including DRB ID and / or DRB QoS information, ii) QoS flows that are mapped to DRBs, or iii) BH RLC channel information including BH RLC channel ID and / or QoS parameters related to the BH RLC channel.

[0079] In some embodiments, the second XnAP message can optionally include: (1) UL BH configuration of GTP tunnel for the UE / IAB-MT, which includes BAP routing ID, optional next hop BAP address, and egress BH RLC CH ID, and / or (2) UL BH information for non-uplink traffic of the IAB node, which includes BAP routing ID, optional next hop BAP address, and egress BH RLC CH ID.

[0080] In some embodiments, the second XnAP message can optionally include information related to the host DU 2 and an upstream IAB node served by the host CU 2 and corresponding to an upstream node of the IAB node. Such information includes topology related information, BAP address, load status, bearer mapping and routing configuration.

[0081] In some embodiments, the second XnAP message can be a non-UE associated message or a UE associated message.

[0082] If a BAP address conflict occurs, the host CU 2 provides several candidate BAP addresses for the IAB node to the host CU 1 via the second XnAP message. The host CU 1 then selects one BAP address (“BAP address 2”) from the candidates and feeds this BAP address back to the host CU 2 via a third XnAP message 3. The host CU 2 stores this BAP address.

[0083] If the host CU 1 requests the host CU 2 to allocate one or more IP addresses, the host CU 2 can initiate an IAB N3 address allocation procedure to obtain IP addresses from the host DU 2. The host CU 2 sends the IP addresses allocated for each usage of the IAB node to the host CU 1 via the second XnAP message. The one or more IP addresses of the host DU 2 can also be included in the message.

[0084] If the host CU 2 determines to setup SRB3 for the IAB node, it will provide the SRB3 configuration for the IAB node to the host CU 1 via the second XnAP message.

[0085] Step 5: The host CU 1 sends a DL RRC message transfer message to the IAB node 1 in the first parent IAB node (e.g., Figure 3 which is the first parent node of the IAB node 3), which includes the generated RRCReconfiguration message.

[0086] Step 6: The first parent IAB node forwards the received RRCReconfiguration message to the MT of the IAB node 3.

[0087] Step 7: The MT of the IAB node responds with an RRCReconfigurationComplete message.

[0088] The RRCReconfiguration message can contain one or more TNL addresses of the IAB-DU which are anchored at the host DU 2. The message can also include the IP address of the host DU 2. Thus, the IAB node can infer the anchor point of the received IP address.

[0089] In some embodiments, the RRCReconfiguration message can contain the BAP address allocated by donor 2 (donor 2 consists of donor CU 2 and donor DU 2) and an indication that the BAP address is used for the second path. The IAB node stores the BAP address. Thus, the IAB node has two BAP addresses. The original one is used for the first path, while the received one is used for the second path.

[0090] In some embodiments, the RRCReconfiguration message can contain the BAP address allocated by donor 2. The IAB node replaces the previously stored BAP address with the received address. In this case, the donor CU 1 needs to update the routing configuration of the donor DU 1 and the IAB node on the first path.

[0091] Step 8: The DU part of the first parent IAB node sends an UL RRC message transfer message to the donor CU 1 to convey the received RRCReconfigurationComplete message.

[0092] If the MT part of the IAB node 3 establishes an RRC connection with the donor CU 2, the RRCReconfigurationComplete message includes the SN RRC response message of the donor CU 2, if needed. If the SN Reconfiguration Complete is received from the IAB-MT, the donor CU 1 informs the donor CU 2 that the IAB-MT has successfully completed the reconfiguration procedure via the SN Reconfiguration Complete message including the SN RRC response message.

[0093] Step 9: A random access procedure is performed at the DU part of the IAB node 2.

[0094] Step 10: The donor CU 2 sends the BH RLC channel and BAP layer routing entries configured for the IAB node (e.g., IAB node 2) and the donor DU 2 on the second path. These configurations can be performed at an earlier stage, e.g., immediately after step 4.

[0095] Step 11: The new TNL address is added to the one or more F1-C associations of the dual-connected IAB-DU with the donor CU 1. The donor CU 1 can configure the new UL BH information for F1AP messages on the second path.

[0096] Step 12: The donor CU 1 can migrate its F1-U tunnels from the first path to the second path for the dual-connected IAB-DU via a UE CONTEXT MODIFICATION REQUEST message.

[0097] Step 13: The DU part of the dual-connected IAB node replies with a UE Context Modification Response message. Steps 12 and 13 can be performed for a subset of the UE bearers, e.g., to balance the load between the first and second path.

[0098] Embodiment 3

[0099] This embodiment will discuss the BH configuration of the donor DU 2 and the related IAB node in the redundant topology, where the BH configuration includes the BH RLC channel configuration, the routing configuration and the BH RLC channel mapping.

[0100] For a BAP SDU received from upper layers at the donor DU 2, the BAP entity performs the mapping to the egress BH RLC channel based on the downlink traffic to BH RLC channel mapping configuration. Each entry of the downlink traffic to BH RLC channel mapping configuration contains the following:

[0101] 1) Destination IP address, which is indicated by the Destination IAB TNL Address IE in the IP header information IE including IPv4 address or IPv6 address or IPv6 address prefix,

[0102] 2) IPv6 Flow Label, if configured, which is indicated by the IPv6 Flow Label IE in the IP header information IE,

[0103] 3) DSCP, if configured, which is indicated by the DSCP IE in the DS Information List IE in the IP header information IE,

[0104] 4) Egress link ID, which is indicated by the Next Hop BAP Address IE in the BH information IE, or by the BAP Address IE configured in the UE associated F1AP message, and

[0105] 5) Egress BH RLC channel ID, which is indicated by the Egress BH RLC CH ID IE in the BH information IE, or by the BH RLC CH ID IE in the UE associated F1AP message.

[0106] The donor CU 1 can migrate its F1-U tunnel with the dual-connected IAB-DU from the first path to the second path. For IP packets transmitted in the F1-U tunnel, the donor DU 2 needs to know the downlink traffic to BH RLC channel mapping configuration for them. Otherwise, the donor DU 2 cannot determine to which egress link or egress BH RLC channel the IP packets need to be delivered. Regarding how to configure the DL mapping for the donor DU 2, the following options can be considered.

[0107] Option 1: The host CU 1 provides the IPv6 flow label and / or DSCP of the F1-U tunnel to the host CU 2 via XnAP message. The host CU 2 generates the DL mapping configuration and sends it to the host DU 2. In this case, the host CU 2 determines the BH configuration and sends it to the IAB nodes on the second path between the dual-connected IAB node and the second-path IAB host DU. The host CU 2 determines the BH configuration of the dual-connected IAB node and the child IAB node and sends this BH configuration to the host CU 1 via XnAP message with the IAB node identifier. The host CU 1 then forwards this BH configuration to the child node via F1AP message.

[0108] Option 2: The host CU 2 determines the DL mapping configuration and sends it to the host DU 2. The host CU 2 also sends the IPv6 flow label and / or DSCP (optionally, IP address) of the F1-U tunnel to the host CU 1. The host CU 1 can use it to set the DSCP and / or flow label field for the downlink IP packets sent from the host CU 1 to the host CU 2. In this case, the host CU 2 determines the BH configuration and sends it to the IAB nodes on the second path between the dual-connected IAB node and the second-path IAB host DU. The host CU 2 determines the BH configuration of the dual-connected IAB node and the child IAB node and sends this BH configuration to the host CU 1 via XnAP message with the IAB node identifier. The host CU 1 then forwards this BH configuration to the child node via F1AP message.

[0109] Option 3: The host CU 1 determines the DL mapping configuration and sends it to the host CU 2 via XnAP message, including the identifier of the host DU 2. The host CU 2 then forwards this configuration to the host DU 2 via F1AP message. In this case, the host CU 1 determines the BH configuration of the IAB nodes on the second path between the dual-connected IAB node and the second-path IAB host DU. The host CU 1 then sends these configurations to the host CU 2 via XnAP message along with the IAB node identifier. The host CU 2 forwards the BH configuration to the IAB nodes along the second path. The host CU 1 to child IAB node BH RLC channels, routing, and BH RLC channel mapping.

[0110] Embodiment 4

[0111] If it is difficult for the host DU 2 to send / receive IP packets directly to / from the host CU 1, the packets need to be forwarded by the host CU 2. This embodiment describes how to forward the packets by the host CU 2.

[0112] Firstly, the host DU 2 needs to distinguish the data packets to be de-capsulated by the host CU 2 and the data packets to be forwarded by the host CU 2. The following solutions can be considered.

[0113] Solution 1: Introduce a special field in the BAP header. This special field informs the host DU which layer the BAP SDU needs to be transferred to, e.g. IP layer or F1AP layer.

[0114] Solution 2: The host CU 1 configures the host DU with a list. This list includes BAP addresses. After receiving an UL data packet, the host DU reads the BAP header and obtains the BAP address, then it decides based on the list which layer the BAP SDU needs to be transferred to, e.g. IP layer or F1AP layer. For example, if the BAP address is in the list, the host DU transfers the BAP SDU to the F1AP layer.

[0115] In the following, it is discussed how the host CU 2 forwards UL / DL data packets.

[0116] After receiving an UL data packet from a child node, the host DU 2 decides according to the BAP address or configuration whether to transfer this data packet to the F1AP layer. If yes, it encapsulates this IP data packet into a F1AP message (e.g. in a container) and sends this F1AP message to the host 2 CU-CP. The host 2 CU-CP extracts the IP data packet from the container and then forwards this IP data packet to the host CU 1 via IP routing. Alternatively, the host 2 CU-CP can encapsulate this IP data packet in an XnAP message and send this XnAP message to the host CU 1.

[0117] When sending a DL IP data packet, the host CU 1 can send it to the host 2 CU-CP via IP routing or encapsulate this IP data packet into an XnAP message. After receiving this IP data packet from the host CU 1, the host 2 CU-CP encapsulates this IP data packet into F1AP and sends it to the host DU 2. The host DU 2 de-encapsulates the F1AP message and obtains the IP data packet. The host DU 2 transfers this data packet to the corresponding BH RLC channel based on the mapping configuration.

[0118] The hosts can exchange via the Xn interface whether direct data packet transfer between a host CU and a host DU belonging to another host is supported.

[0119] Embodiment 5

[0120] Assuming the new IAB node connects to a dual-connected IAB node or any downstream node. Upon receiving the RRC setup request message for the new accessing IAB node, the donor CU 1 can forward the RRC setup message to the donor CU 2 to request the donor CU 2 to establish the RRC connection between it and the new accessing IAB node. If the donor CU 2 allows the access of the IAB node, it will send an RRCSetup message to the donor CU 1. Then, the donor CU 1 forwards the RRCSetup message to the new accessing IAB node.

[0121] Embodiments and examples of the above disclosed wireless communication methods can facilitate handover procedures in multimedia broadcast multicast services. Figure 4 An example of a wireless communication method is shown. The method 300 includes, at operation 310, transmitting, from a first centralized unit (CU) configured to communicate with an integrated access and backhaul (IAB) node, a first message to a second CU. The method 300 also includes, at operation 320, receiving, by the first CU, a second message including configuration information.

[0122] Figure 5 Another example of a wireless communication method is shown. The method 400 includes, at operation 410, receiving, from a first centralized unit (CU) configured to communicate with an integrated access and backhaul (IAB) node, a first message. The method 400 also includes, at operation 420, transmitting, by the second CU to the first CU, a second message including bearer information.

[0123] The above-described embodiments will be applicable to wireless communications. Figure 6 An example of a wireless communication system (e.g., a 5G or NR cellular network) including a BS 520 and one or more user equipment (UE) 511, 512, and 513 is shown. In some embodiments, the UEs use embodiments of the disclosed techniques 531, 532, 533 to access the BS (e.g., the network), which then enables subsequent communications (541, 542, 543) from the BS to the UEs. The UEs can be, for example, smartphones, tablets, mobile computers, machine-to-machine (M2M) devices, Internet of Things (IoT) devices, etc.

[0124] ​An example of a block diagram representation showing a portion of an apparatus is shown. An apparatus 610, such as a base station or user equipment which can be any wireless device (or UE), can include processor electronics 620, such as a microprocessor implementing one or more techniques given in the present application. The apparatus 610 can include transceiver electronics 630 to transmit and / or receive wireless signals through one or more communication interfaces, such as an antenna 640. The apparatus 610 can include other communication interfaces for transmitting and receiving data. The apparatus 610 can include one or more memories (not explicitly shown) configured to store information, such as data and / or instructions. In some implementations, the processor electronics 620 can include at least a portion of the transceiver electronics 630. In some embodiments, the disclosed techniques, modules or functions at least some of which are implemented using the apparatus 610.

[0125] Additional features of the above-described methods / techniques, which can be preferably implemented in some implementations, are described below using a clause-based description format.

[0126] 1. A method of wireless communication comprising: transmitting, from a first centralized unit (CU) configured to communicate with an integrated access and backhaul (IAB) node, a first message to a second CU; and receiving, by the first CU, a second message comprising configuration information, and wherein the first message comprises at least one of an identification of an IAB node, an identification of a user equipment in communication with the IAB node.

[0127] 2. The method of clause 1, wherein the first CU and the second CU correspond to a donor CU.

[0128] 3. The method of clause 1, wherein the first message further comprises i) an IAB node indication of the IAB node and ii) at least one of a topology relationship between the IAB node, a child node, and the user equipment in communication with the IAB node and the child node.

[0129] 4. The method of clause 1, wherein the first message further comprises at least one of: i) a load status of the IAB node, ii) a bearer mapping configuration and a routing configuration of the IAB node, iii) bearer information, iv) an indication of a control plane traffic type communicated via a second communication path, v) a backhaul adaptation protocol (BAP) address of the IAB node, vi) configuration information of a DU (Distributed Unit) portion of the IAB node.

[0130] 5. The method of clause 1, further comprising: transmitting an IP address request for one or more IP addresses.

[0131] 6. The method of clause 1, wherein the second message includes bearer information associated with the user equipment and / or the IAB node.

[0132] 7. The method of clause 4 or 6, wherein the bearer information includes at least one of: i) data radio bearer (DRB) related information including one of a DRB identification (ID) and DRB quality of service (QoS) information, ii) a QoS flow mapped to the DRB, or iii) backhaul (BH) radio link control (RLC) channel information and BH RLC channel QoS information.

[0133] 8. The method of clause 6, wherein the second message further includes at least one of: i) an uplink (UL) backhaul (BH) configuration of a GTP (GPRS Tunneling Protocol) tunnel, or ii) uplink BH information of a non-UP traffic type of the IAB node.

[0134] 9. The method of clause 6, wherein the second message further includes at least one of topology related information, an identifier of a distributed unit of the second CU, an identifier of an IAB node served by the second CU on the second communication path, a BAP address, a load status, a bearer mapping and routing configuration, or configuration information of a distributed unit of the IAB node.

[0135] 10. The method of clause 1, further comprising sending a reconfiguration message to the IAB node served by the first CU, the reconfiguration message including information related to a radio resource control (RRC) connection.

[0136] 11. The method of clause 10, wherein the reconfiguration message includes at least one of: i) one or more transport network layer (TNL) addresses of the IAB node, ii) a BAP address or iii) an indication that the BAP address is used for the second communication path.

[0137] 12. The method of clause 1, further comprising receiving a candidate BAP address of the IAB node from the second CU.

[0138] 13. The method of clause 1, further comprising sending information to the second CU, the information including at least one of: i) a flow label or ii) a differentiated services code point (DSCP) for F1-U tunnel or control plane traffic type.

[0139] 14. The method of clause 1, further comprising receiving, from the second CU, at least one of: i) a flow label or ii) a differentiated services code point (DSCP) for F1-U tunnel or control plane traffic type.

[0140] 15. The method of clause 1, further comprising sending, to the second CU, an identifier of a distributed unit of the second CU and a DL mapping configuration.

[0141] 16. The method of clause 1, further comprising sending, to the second CU, an identifier of an IAB node served by the second CU on the second communication path and a BH configuration.

[0142] 17. The method of clause 15 or 16, the DL mapping configuration and the BH configuration can be at least one of a BH RLC channel configuration, a routing configuration, or a BH RLC channel mapping.

[0143] 18. The method of clause 1, further comprising sending a data packet by including a CU ID and a BAP address in a header of the data packet, the CU ID corresponding to an identifier of the first CU or the second CU.

[0144] 19. A method of wireless communication, comprising: receiving, from a first centralized unit (CU) configured to communicate with an integrated access and backhaul (IAB) node, a first message; and sending, by the second CU to the first CU, a second message including the configuration information.

[0145] 20. The method of clause 19, wherein the first CU and the second CU correspond to a donor CU.

[0146] 21. The method of clause 19, wherein the second message further includes at least one of: i) an uplink (UL) backhaul (BH) configuration of a GTP tunnel, ii) an UL BH information of a non-UP traffic type of the IAB node.

[0147] 22. The method of clause 19, wherein the second message further includes one or more IP addresses for the IAB node.

[0148] 23. The method of clause 19, wherein the second message further includes a candidate BAP address for the IAB node.

[0149] 24. The method of clause 19, further comprising receiving, from the first CU, at least one of: i) a flow label, ii) a differentiated services code point (DSCP) for F1-U tunnel or control plane traffic type.

[0150] 25. The method of clause 19, further comprising sending at least one of i) a flow label or ii) a differentiated services code point (DSCP) for F1-U tunneling or control plane traffic type to the first CU.

[0151] 26. The method of clause 19, further comprising sending an identifier and a BH configuration of the IAB node to the first CU, the IAB node having dual connectivity.

[0152] 27. The method of clause 19, further comprising sending an identifier and a BH configuration of a downstream IAB node to the first CU. The downstream node is a node located in a direction from the IAB donor to a user equipment.

[0153] 28. The method of clause 26 or 27, wherein the BH configuration comprises at least one of a BH RLC channel configuration, a routing configuration, or a BH RLC channel mapping.

[0154] 29. A communication device comprising a processor configured to implement a method recited in any one or more of clauses 1 to 28.

[0155] 30. A computer readable medium having code stored thereon, which when executed, causes a processor to implement a method recited in any one or more of clauses 1 to 28.

[0156] In some embodiments, a base station can be configured to implement some or all of the base station-side techniques described in this application.

[0157] It is intended that the specification and drawings be considered exemplary only, with the example being illustrative and not necessarily the best mode or preferred embodiments. As used in this document, the use of "or" is intended to include "and / or", unless stated otherwise or the context clearly indicates otherwise.

[0158] Some embodiments described herein are described in the general context of methods or processes, which can 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 can 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 (DVDs), etc. Thus, computer-readable medium can include non-transitory storage media. Generally, program modules can 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.

[0159] Some disclosed embodiments can be implemented as devices or modules using hardware circuitry, software, or a combination thereof. For example, hardware circuitry implementations can include discrete analog and / or digital components, such as integrated as part of a printed circuit board. Alternatively or additionally, disclosed components or modules can be implemented as application specific integrated circuits (ASICs) and / or field programmable gate array (FPGA) devices. Some implementations can additionally or alternatively include digital signal processors (DSPs), which are specialized microprocessors having an architecture optimized for the operational demands of digital signal processing associated with the functionality disclosed herein. Similarly, various components or subcomponents within each module can be implemented in software, hardware, or firmware. Connections between the modules and / or components within the modules can be provided using any of the connection methods and media known in the art, including but not limited to communication over the Internet, wired or wireless networks using appropriate protocols.

[0160] Although the present application contains many details, these should not be construed as limiting the scope of any invention or of any claim that can be presented, but as merely describing features that can be present in some embodiments of the particular invention. Certain features that are, for clarity, described above in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are, for brevity, described in the context of a single embodiment can also be implemented separately or in any suitable subcombination. 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.

[0161] Only some implementations and examples are described and other implementations, enhancements and variations can be made based on what is described and illustrated in this disclosure.

Claims

1. A method for wireless communication, comprising: A first message is sent from a first centralized unit (CU) that communicates with the integrated access and backhaul IAB node to a second CU that communicates with the IAB node. The first message includes the bearer mapping configuration and routing configuration of the IAB node, as well as an IP address request. The first CU receives from the second CU a second message including bearer information associated with the IAB node and one or more IP addresses for the IAB node. The bearer information includes the backhaul BH Radio Link Control (RLC) channel ID and BH RLC channel QoS information. The first message also includes the identifier of the IAB node.

2. The method according to claim 1, wherein, The first CU and the second CU correspond to the host CU.

3. The method according to claim 1, wherein, The first message also includes at least one of i) an IAB node indication of the IAB node and ii) a topological relationship between the IAB node, its subordinate nodes, and the user equipment communicating with the IAB node and its subordinate nodes.

4. The method according to claim 1, wherein, The first message further includes at least one of the following: i) the load status of the IAB node, ii) an indication of the control plane traffic type transmitted via the second communication path, iii) the backhaul adaptation protocol (BAP) address of the IAB node, and iv) the configuration information of the distributed unit (DU) portion of the IAB node.

5. The method according to claim 1, wherein, The bearer information includes at least one of the following: i) Data Radio Bearer (DRB) related information, which includes at least one of DRB identifier ID and DRB Quality of Service (QoS) information; ii) QoS streams mapped to the DRB.

6. The method according to claim 1, wherein, The second message also includes at least one of the following: i) uplink UL backhaul BH configuration of the GPRS tunneling protocol GTP tunnel, or ii) uplink BH information of the non-UP traffic type of the IAB node.

7. The method according to claim 1, wherein, The second message also includes information related to the second distributed unit (DU) and the IAB node served by the second CU, wherein the second distributed unit (DU) is a second DU of the IAB node served by the second CU, and the information related to the second distributed unit (DU) and the IAB node served by the second CU includes at least one of the following: topology-related information, identifier of the distributed unit of the second CU, identifier of the IAB node served by the second CU on the second communication path, BAP address, load status, bearer mapping and routing configuration, or configuration information of the distributed unit of the IAB node.

8. The method according to claim 1, further comprising: The first CU sends a reconfiguration message to the IAB node served by the first CU. The reconfiguration message includes information related to the Radio Resource Control (RRC) connection.

9. The method according to claim 8, wherein, The reconfiguration message includes at least one of the following: i) one or more Transport Network Layer (TNL) addresses of the second Distributed Unit (DU), ii) a BAP address assigned by the IAB node served by the second CU, or iii) the BAP address used as an indication of the second communication path, wherein the second Distributed Unit (DU) is a second DU of the IAB node served by the second CU.

10. The method according to claim 1, further comprising: The first CU receives the candidate BAP address of the IAB node from the second CU.

11. The method according to claim 1, further comprising: The first CU sends information to the second CU, the information including at least one of the following: i) a flow label for the F1-U tunnel or ii) a Differentiated Service Code Point (DSCP) for the F1-U tunnel.

12. The method according to claim 1, further comprising: The first CU receives at least one of the following from the second CU: i) a flow tag for the F1-U tunnel or ii) a Differentiated Service Code Point (DSCP) for the F1-U tunnel.

13. The method according to claim 1, further comprising: The first CU sends the identifier of the distributed unit of the second CU and the DL mapping configuration to the second CU.

14. The method according to claim 1, further comprising: The first CU sends the identifier and BH configuration of the IAB node served by the second CU on the second communication path to the second CU.

15. The method according to claim 13 or 14, wherein the DL mapping configuration and BH configuration can be at least one of BH RLC channel configuration, routing configuration, or BH RLC channel mapping.

16. The method according to claim 1, further comprising: The data packet is sent by including a CU ID and a BAP address in the packet header, wherein the CU ID corresponds to the identifier of the first CU or the second CU.

17. A method for wireless communication, comprising: The second centralized unit CU, which communicates with the integrated access and backhaul IAB nodes, receives a first message from the first centralized unit CU, which also communicates with the integrated access and backhaul IAB nodes. The first message includes the bearer mapping configuration and routing configuration of the IAB nodes, as well as an IP address request. The second CU sends a second message to the first CU, including bearer information associated with the IAB node and one or more IP addresses for the IAB node. The bearer information includes the backhaul BH Radio Link Control (RLC) channel ID and BH RLC channel QoS information. The first message also includes the identifier of the IAB node.

18. The method according to claim 17, wherein, The first CU and the second CU correspond to the host CU.

19. The method of claim 17, wherein, The second message also includes at least one of the following: i) uplink UL backhaul BH configuration of the GTP tunnel, ii) uplink BH information of the non-UP traffic type of the IAB node.

20. The method of claim 17, wherein, The second message also includes candidate BAP addresses for the IAB node.

21. The method of claim 17, further comprising: The second CU receives at least one of the following from the first CU: i) a flow tag for the F1-U tunnel, ii) a Differentiated Service Code Point (DSCP) for the F1-U tunnel.

22. The method of claim 17, further comprising: The second CU sends at least one of the following to the first CU: i) a flow tag for the F1-U tunnel or ii) a Differentiated Service Code Point (DSCP) for the F1-U tunnel.

23. The method of claim 17, further comprising: The second CU sends the identifier and BH configuration of the IAB node to the first CU. The IAB node has dual connections.

24. The method of claim 17, further comprising: The second CU sends the identifier and BH configuration of the downstream IAB node to the first CU.

25. The method according to claim 23 or 24, wherein, The BH configuration includes at least one of BH RLC channel configuration, routing configuration, or BH RLC channel mapping.

26. A communication device comprising a processor and a memory, the processor being configured to read instructions from the memory to perform the method of any one of claims 1 to 25.

27. A computer-readable medium having code stored thereon, which, when executed, causes a processor to perform the method of any one of claims 1 to 25.

Citation Information

Patent Citations

  • Connection reconstruction method, context acquisition method, context management method, connection reconstruction method, node and medium

    CN111526544A