Integrated Access and Backhaul Donor Migration Method and System
Patent Information
- Application Number
- KR1020237033027
- Authority / Receiving Office
- KR · KR
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2021-04-01
- Publication Date
- 2026-10-13
- Estimated Expiration
- 2041-04-01
Smart Images

Figure 112023106300896-PCT00005_ABST
Abstract
Description
Technology Field
[0001] This specification generally relates to wireless communication. Background Technology
[0002] Wireless communication technology is moving the world toward an increasingly connected and networked society. The rapid growth of wireless communication and technological advancements have led to increased demand for capacity and connectivity. For example, other aspects such as energy consumption, device costs, spectrum efficiency, and latency are also important in meeting the needs of various communication scenarios. Compared to existing wireless networks, next-generation systems and wireless communication technologies provide support for integrated access and backhaul (IAB), enabling wireless backhauling via New Radio (NR) and flexible, high-density deployment of NR cells, while simultaneously reducing the need for wired transmission infrastructure.
[0003] This specification relates to methods, systems, and devices for integrated access and backhaul (IAB) donor migration for mobile communications including 5th generation (5G) and new radio (NR) communication systems.
[0004] In one exemplary aspect, a wireless communication method is disclosed. The method comprises the steps of transmitting an Xn Application Protocol (XnAP) message containing Internet Protocol (IP) address request information by a first Integrated Access and Backhaul (IAB) donor to a second IAB donor, and receiving the IP address information from the second IAB donor.
[0005] In another exemplary aspect, a wireless communication method is disclosed. The method comprises the step of transmitting an F1 Application Protocol (F1AP) message containing Internet Protocol (IP) address information to an IAB node by a first Integrated Access and Backhaul (IAB) donor, wherein the IP address information includes at least one of the IP address information of the IAB node, the IP address information of the first IAB donor, and the IP address information of the second IAB donor.
[0006] In another exemplary aspect, a wireless communication method is disclosed. The method includes the step of transmitting a control message containing Internet Protocol (IP) address information of an IAB DU to an IAB donor by an Integrated Access and Backhaul (IAB) distributed unit (DU).
[0007] In another exemplary aspect, a wireless communication method is disclosed. The method includes the step of transmitting a control message containing Internet Protocol (IP) address information by a first network node to a second network node.
[0008] In another exemplary aspect, a wireless communication method is disclosed. The method comprises the step of transmitting a message containing transmission action indicator information by a first network node to a second network node, wherein the transmission action indicator information configures the second network node to perform one or more transmission actions with respect to a wireless device.
[0009] In another exemplary aspect, the method described above is implemented in the form of processor executable code and stored on a computer-readable program medium.
[0010] In another exemplary embodiment, a device configured or operable to perform the method described above is disclosed.
[0011] The above and other aspects and their implementations are described in more detail in the drawings, description, and claims. Brief explanation of the drawing
[0012] Figure 1a illustrates an example of an integrated access and backhaul (IAB) network. Figure 1b illustrates an example of an IAB user plane protocol stack. Figure 2 illustrates an example of migration between CUs. Figure 3 illustrates an example in which the central unit (CU) control plane (CP) and the user plane (UP) are separated in a g-NodeB (gNB). FIGS. 4 through 8 illustrate examples of wireless communication methods corresponding to some embodiments of the currently disclosed technology. FIG. 9 is a block diagram representation of a part of a device that may be configured to implement some embodiments of the technology disclosed in the present invention. Specific details for implementing the invention
[0013] As the number of applications and services for digital data continues to explode, the demands and challenges on network resources and operators will also continue to grow. The ability to provide the diverse network performance characteristics required by future services is one of the major technological challenges facing service providers today. Network performance requirements demand connectivity in terms of data rate, latency, QoS, security, availability, and various other parameters, all of which vary by service. Therefore, enabling networks to allocate resources flexibly to provide customized connectivity for each different type of service will significantly enhance their ability to meet future demands.
[0014] To meet these demands, the development of 5th generation (5G) mobile wireless technologies and standards is progressing smoothly. One such technology is a partitioned network architecture in which Radio Access Network (RAN) functionality is divided between a Central Unit (CU) and multiple Distributed Units (DU). For example, RAN functions can be partitioned at the point between the Packet Data Convergence Protocol (PDCP) layer and the Radio Link Control (RLC) layer of the 5G protocol stack, where the DU handles all processes up to the RLC layer functions, and the CU handles the PDCP layer and higher-layer functions prior to the core network. This separation of RAN functions will provide many advantages to mobile network operators. For instance, by isolating the stack above the PDCP layer, the CU can serve as a cloud-based convergence point between multiple heterogeneous technologies in the provided network, thereby enabling the service of multiple heterogeneous DUs.
[0015] Another technology under development for 5G networks is the Integrated Access and Backhaul (IAB) architecture, designed to provide high-speed wireless backhaul to cell sites (e.g., base stations). As data demand and the number of cell sites increase, providing traditional fiber-optic backhaul access to each cell site is becoming increasingly difficult, particularly for small cell base stations. The IAB architecture allows for the provision of both access and backhaul to support, for example, User Equipment (UE) Packet Data Unit (PDU) sessions using the same infrastructure and resources (e.g., IAB nodes). The IAB architecture for New Radio (NR) networks provides wireless backhaul and relay links that enable flexible and dense deployment of NR cells without the need to proportionally increase the density of the transport network. Furthermore, using IAB technology makes it easier to deploy dense networks of self-backhauling NR cells in a more integrated and robust manner. For example, IAB technology for 5G NR networks will support multi-hop relay systems where the network topology also supports redundant access.
[0016] FIG. 1a illustrates a block diagram of an IAB architecture network (100) in which a core network (102) is connected to a donor IAB node (104). As used herein, the term “connected” refers to a wired or cable connection (e.g., fiber optic cable) between two nodes or devices. The donor IAB node (104) is wirelessly coupled to a plurality of intermediate IAB nodes (106a and 106b) and two serving IAB nodes (106c and 106d). As used herein, the term “coupled” refers to direct or indirect and wired or wireless communication between two nodes or devices.
[0017] As illustrated in FIG. 1a, serving IAB nodes (106c and 106d) are each directly coupled to UEs (108a and 108b) and function as serving cell site base stations or access points for UEs (108a and 108b). UEs (108a and 108b) are referred to herein as "access UEs". Serving IAB nodes (106c and 106d) also act as relays and can transmit their respective UE signals to their respective next uplink nodes in the transmission path and transmit downlink signals to their respective UEs (108a and 108b). As illustrated in FIG. 1a, serving IAB node (106c) can transmit uplink UE signals to one or both of the intermediate IAB nodes (106a and 106b) and receive downlink UE signals from one or both of the intermediate IAB nodes (106a and 106b). Intermediate IAB nodes (106a and 106b) can transmit uplink UE signals to the donor IAB node (104) and downlink signals to the serving IAB node (106d). The serving IAB node (106c) can transmit uplink UE signals to the donor IAB node (104), which can then transmit all received signals to the core network (102) and transmit downlink signals from the donor IAB node (104) to the access UE (108a).
[0018] Each of the IAB nodes (106a-106d) may have two functions: a base station (BS) function and a mobile terminal (MT) function. The BS function means that the IAB node can operate like a base station to provide wireless access functions to the UE. As used herein, the “BS part” of an IAB node refers to the corresponding part of the IAB node that includes all hardware, firmware, and / or software related to performing the BS function of the IAB node. The MT function means that the IAB node can operate like a mobile terminal controlled and scheduled by an IAB donor node or a parent IAB node. As used herein, the “MT part” of an IAB node refers to the corresponding part of the IAB node that includes all hardware, firmware, and / or software related to performing the MT function of the IAB node.
[0019] Referring still to FIG. 1a, if the network (100) also implements a partitioned architecture, the donor IAB node (104) will be replaced by a donor CU (not shown) connected to the core network (102) and a donor DU (not shown) connected to the donor CU. Each of the IAB nodes (106a-106d) will be connected to the donor DU in a manner similar to the connection to the donor IAB node (104) as shown in FIG. 1a.
[0020] In a partitioned architecture network, each IAB node (106a-106d) may have two functions: a DU function and a mobile terminal (MT) function. The DU function means that the IAB node can act like a DU to provide a predetermined DU function to the UE. As used herein, the "DU part" of an IAB node refers to the corresponding part of the IAB node that includes all hardware, firmware, and / or software related to performing the DU function of the IAB node. In a partitioned architecture network, the MT function and MT part of the IAB node are the same as those described above for a non-partitioned architecture network.
[0021] Figure 1b illustrates the IAB user plane protocol stack between the IAB-DU and the IAB-donor-CU. F1-U uses the IP transport layer between the IAB-DU and the IAB-donor-CU. The IP layer can be additionally secured. In wireless backhaul, the IP layer is transmitted through the backhaul adaptation protocol (BAP) lower layer, which enables routing over multiple hops and bearer mapping. In each backhaul link, the BAP PDU is carried by the BH RLC channel. Multiple BH RLC channels may be configured on each BH link to allow traffic prioritization and QoS enforcement.
[0022] The following terms are used in this specification.
[0023] IAB-Donor: A gNB that provides network access to the UE through a network of backhaul and access links.
[0024] IAB-Donor-CU: IAB-Donor's gNB-CU terminating the F1 interface toward the IAB node and IAB-Donor-DU.
[0025] IAB-Donor-DU: The gNB-DU of an IAB-donor that hosts the IAB BAP sublayer (defined in TS 38.340) and provides wireless backhaul to IAB nodes.
[0026] IAB-DU: A gNB-DU function on an IAB-donor, supported by the IAB-node, to terminate the NR access interface to the UE and the next-hop IAB node as defined in TS 38.401 and to terminate the F1 protocol to the gNB-CU function.
[0027] IAB-MT: An IAB-node function that terminates the Uu interface to the parent node using the procedures and behaviors specified for the UE, unless otherwise specified. The IAB-MT function used in the 38 series of 3GPP specifications corresponds to the IAB-UE function defined in TS 23.501.
[0028] IAB-Node: A RAN node that supports NR access links to UEs and NR backhaul links to parent and child nodes. IAB-Nodes do not support backhauling over LTE.
[0029] Child node: the next hop neighbor node of IAB-DU and IAB-Donor-DU; the child node is also an IAB-node.
[0030] Parent node: the next hop neighbor node of IAB-MT; the parent node can be an IAB-node or an IAB-donor-DU.
[0031] Upstream: Direction toward the parent node in an IAB topology.
[0032] Downstream: Direction toward child nodes or UEs in the IAB topology.
[0033] Existing IAB systems use intra-donor CU migration, where both the source and target nodes are served by the same IAB donor CU. One of the challenges arising from the implementation of partitioned architecture and IAB architecture technologies in 5G networks is a solution for migration between donor CUs.
[0034] Embodiments of the technology currently disclosed describe methods, systems, and devices for Integrated Access and Backhaul (IAB) donor migration. In an example, a source IAB donor CU and a target IAB donor CU exchange IP address-related information. In another example, a donor CU and an IAB-DU exchange IP address-related information. In yet another example, a CU-CP and a CU-UP exchange IP address-related information.
[0035] This specification uses section headings and subheadings for ease of understanding and does not limit the scope of the disclosed technology and embodiments to a specific section. Accordingly, embodiments disclosed in different sections may be used together. Furthermore, this specification uses examples of 3GPP New Radio (NR) network architectures and 5G protocols only for the sake of understanding, and the disclosed technology and embodiments may be implemented in other wireless systems using communication protocols different from the 3GPP protocol.
[0036] Overview of Migration Between Donor CUs
[0037] During the migration procedure between donor CUs, the source parent node of the migrating IAB node is served by an IAB-donor CU different from the target parent node. FIG. 2 illustrates an example of a migration between donor CUs (or between CUs or between donors). As illustrated herein, IAB-node 3 is migrated between IAB-donor-CU 1 and IAB-donor-CU 2. In some embodiments, a Dual Active Protocol Stack (DAPS) type handover or a conditional handover (CHO) may be utilized for the migration.
[0038] Example of a target donor CU obtaining IP address information
[0039] In some embodiments, during a migration between donors, if the source parent node of the migrating IAB-node is served by an IAB-donor-DU different from the target parent node, a new IP address must be used by the migrating IAB node and / or the donor CU for the IPsec tunnel established between the migrating IAB node and the donor CU through the target donor DU. Since the new IP address is typically anchored at the target donor DU, the new IP address may be assigned by the target donor DU or the target donor CU, or through an Operations, Administration and Maintenance (OAM) framework.
[0040] In some embodiments, the new IP address may be used by the child node and / or the donor CU for an IPsec tunnel established between the child node and the donor CU through the target donor DU.
[0041] One of the technical problems solved by an embodiment of the disclosed technology is how the target donor CU obtained IP address request information.
[0042] (1) In some embodiments, the source donor CU includes IP address request information in the Wireless Resource Control (RRC) Information Element (IE) within the Xn Application Protocol (XnAP) handover request message and transmits it to the target donor.
[0043] (2) In some embodiments, the source donor CU in the XnAP handover request message HandoverPreparationInformation Include IP address request information in the message and send it to the target donor CU.
[0044] (3) In some embodiments, IP address request information is explicitly included in the XnAP handover request message sent from the source donor CU to the target donor CU.
[0045] (4) In some embodiments, IP address request information is included in a new XnAP message transmitted from the source donor CU to the target donor CU.
[0046] In the aforementioned embodiments, the IP address request information includes at least one of the following:
[0047] - Number of IPv4 addresses requested by specific use case
[0048] - Number of IPv6 addresses requested by specific use case
[0049] - Prefixes of IPv6 addresses requested for specific purposes
[0050] - In the above, specific uses include one or more of F1-C traffic, F1-U traffic, non-F1 traffic, and all traffic.
[0051] - Previous IPv4 address(s)
[0052] - Previous IPv6 address(s)
[0053] - Previous IPv6 prefix(s)
[0054] In some embodiments, after receiving IP address request information, the target donor CU allocates an IP address as needed. In other embodiments, the target donor CU transmits the IP address request information to the target donor DU that allocates the IP address as needed.
[0055] Example of Donor CU and IAB-DU obtaining IP address information
[0056] One of the technical problems solved by an embodiment of the disclosed technology is a method for an IAB-DU to obtain updated IP address information.
[0057] (1) In some embodiments, the donor CU transmits updated IP address information of the IAB-DU through an RRC message, for example, an RRCreconfiguration message.
[0058] (2) In some embodiments, the donor CU transmits updated IP address information of the IAB-DU through F1 application protocol (F1AP) messages, for example, GNB-CU CONFIGURATION UPDATE or GNB-DU CONFIGURATION UPDATE ACKNOWLEDGE messages.
[0059] Another technical problem solved by an embodiment of the disclosed technology is a method for the IAB-DU to obtain updated IP address information of the source donor CU.
[0060] (1) In some embodiments, the donor CU transmits updated IP address information to the IAB-DU via F1AP messages, for example, GNB-CU CONFIGURATION UPDATE or GNB-DU CONFIGURATION UPDATE ACKNOWLEDGE messages.
[0061] (2) In some embodiments, the donor CU transmits updated IP address information to the IAB-DU via an RRC message, for example, an RRCreconfiguration message.
[0062] Another technical problem solved by an embodiment of the disclosed technology is a method for a donor CU to obtain updated IP address information of an IAB-DU.
[0063] (1) In some embodiments, after receiving the updated IP address information, the IAB-DU transmits the updated IP address information to the donor CU via an F1AP message, for example, via a GNB-DU CONFIGURATION UPDATE or GNB-CU CONFIGURATION UPDATE ACKNOWLEDGE message.
[0064] (2) In some embodiments, the target donor CU sends the updated IP address information of the IAB-DU to the source donor CU via an XnAP message, for example, a handover (HO) request ACK or a new XnAP message.
[0065] In the above technical solution, the updated IP address information includes at least one of the following:
[0066] - IP address(s) for IPsec for F1-U traffic and optionally corresponding IP address(s) for GPRS Tunneling Protocol (GTP) endpoints
[0067] - IP address(s) for IPsec for F1-C traffic
[0068] - IP address(s) for IPsec for non-F1 traffic
[0069] - IP address(s) for IPsec for all traffic
[0070] - Old IP address(s) for IPsec for F1-U traffic
[0071] - Previous IP address(s) for IPsec for F1-C traffic
[0072] - Old IP address(s) for IPsec for non-F1 traffic
[0073] - Old IP address(s) for IPsec for all traffic
[0074] - Backhaul Adaptation Protocol (BAP) address for the IAB node
[0075] In some embodiments, after the donor CU and IAB-DU receive updated IP address information, the donor CU or IAB-DU establishes an IP security (IPsec) tunnel using the updated IP address.
[0076] The aforementioned embodiment is also applicable to the CU CP-UP separation scenario, where the CU or donor CU is replaced with CU-CP.
[0077] Example of exchanging IP address information for CU CP-UP separation
[0078] For an embodiment including a central unit (CU) control plane (CP)-user plane (UP) separation, the CU includes CU-CP and CU-UP. An exemplary architecture for the separation of gNB-CU-UP and gNB-CU-CP for a donor CU is illustrated in FIG. 3. As illustrated herein, CU-CP and CU-UP exchange E1 messages, gNB-CU-CP transmits F1-C messages to one or more gNB-DUs, and each of the one or more gNB-DUs transmits F1-U messages to gNB-CU-UP.
[0079] One of the technical problems solved by an embodiment of the disclosed technology is a method for CU-CP to obtain updated IP address information of CU-UP.
[0080] (1) In some embodiments, CU-UP transmits updated IP address information to CU-CP via an E1 message. In other embodiments, CU-CP transmits the updated IP address information of CU-UP to IAB-DU using an F1 message.
[0081] Another technical problem solved by an embodiment of the disclosed technology is a method for a donor CU-UP to obtain updated IP address information of an IAB-DU.
[0082] (1) In some embodiments, (e.g., using the embodiment described in the previous section) after obtaining the updated IP address information of IAB-DU, CU-CP transmits the updated IP address information of IAB-DU to CU-UP via an E1 message.
[0083] Example of controlling IAB-DU transmission to UE
[0084] In a donor-to-donor migration, all migrating / descendant IAB-MTs and UEs are migrated to the target donor. Generally, a handover similar to DAPS is applied to IAB-MT migrations, while a standard handover procedure is applied to descendant IAB-MTs and UEs.
[0085] In the case of downlink UE data, the source donor CU must stop transmitting new downlink (DL) data upon receiving an ACK message requesting an HO from the UE. However, some on-the-fly packets transmitted from the source donor CU may arrive at the UE's serving IAB-DU (e.g., an IAB access node, IAB Node 3 in Fig. 2) after receiving a UE condition correction message (e.g., due to retransmission on the backhaul link). Assuming these DL on-the-fly packets transmitted from the source donor CU are delivered to the UE, an error may occur if the UE has already completed Packet Data Convergence Protocol (PDCP) re-establishment and integrity protection is not configured. Otherwise, if integrity protection is configured, these DL on-the-fly packets are discarded by the PDCP lower layer.
[0086] In some embodiments, the source donor CU sends an F1AP message (e.g., a UE CONTEXT MODIFICATION REQUEST message) to the IAB-DU. The F1AP message includes transmit action indicator information used to indicate a specific action that may be taken by the gNB-DU for transmitting data to the UE. In an example, the transmit action indicator information may be used to indicate that the IAB-DU stops transmitting data sent from the source donor CU.
[0087] In some embodiments, the F1AP message includes at least one of the following:
[0088] - Information about the GTP tunnel that needs to be stopped. In the example, the information includes the Transport Network Layer (TNL) address and / or the GTP tunneling endpoint (Tunnel Endpoint ID; TEID).
[0089] - Information about the Data Radio Bearer(s); DRB(s) that must be stopped. For example, the information includes the DRB ID.
[0090] In some embodiments, the target donor CU sends an F1AP message to the IAB-DU. The F1AP message includes transmit action indicator information used to indicate a specific action that may be taken by the gNB-DU for transmitting data to the UE. In the example, the transmit action indicator information may be used to indicate at least one of the following:
[0091] - Initiating data transmission from the target donor CU
[0092] - Restarting data transmission from the target donor CU
[0093] - Stopping data transmission from the target donor CU.
[0094] In some embodiments, the F1AP message includes at least one of the following:
[0095] - Information about the GTP tunnel(s) that need to be stopped, started, or restarted. In the example, the information includes the Transport Network Layer (TNL) address and / or the GTP tunnel endpoint (Tunnel Endpoint ID; TEID).
[0096] - Information about the Data Radio Bearer (DRB) that needs to be stopped, started, or restarted. For example, the information includes the DRB ID.
[0097] Exemplary methods and embodiments of the disclosed technology
[0098] FIG. 4 illustrates an example of a wireless communication method (400) for IAB donor migration. The method (400) includes, in operation (410), the step of transmitting an Xn Application Protocol (XnAP) message containing Internet Protocol (IP) address request information from a first Integrated Access and Backhaul (IAB) donor to a second IAB donor.
[0099] The method (400) includes the step of receiving IP address information from the second IAB donor in the operation (420).
[0100] In some embodiments, the IP address information includes at least one of the IP address information of an IAB node, the IP address information of a first IAB donor, and the IP address information of a second IAB donor.
[0101] In some embodiments, the XnAP message is an XnAP handover request message.
[0102] In some embodiments, IP address request information is included in the Wireless Resource Control (RRC) context information element (IE) of the XnAP handover request message.
[0103] In some embodiments, IP address request information is included in the HandoverPreparationInformation message within the XnAP handover request message.
[0104] In some embodiments, the IP address request information includes at least one of the number of requested IPv4 addresses, the number of requested IPv6 addresses, the use of an IPv6 prefix, the use of a requested IPv4 address, the use of a requested IPv6 address, a previous IPv4 address, a previous IPv6 address, and a previous IPv6 prefix.
[0105] In some embodiments, the IP address information includes at least one of an IP address for IP security (IPsec) for F1-U traffic, an IP address for IPsec for F1-C traffic, an IP address for IPsec for non-F1 traffic, a previous IP address for IPsec for F1-U traffic, a previous IP address for IPsec for F1-C traffic, a previous IP address for IPsec for non-F1 traffic, an IP address for a General Packet Radio Service (GPRS) Tunneling Protocol (GTP) endpoint, and a Backhaul Adaptation Protocol (BAP) address for an IAB node.
[0106] FIG. 5 illustrates an example of a wireless communication method (500) for IAB donor migration. The method (500) includes, in operation (510), the step of transmitting an F1 Application Protocol (F1AP) message containing Internet Protocol (IP) address information by a first Integrated Access and Backhaul (IAB) donor to an IAB node, wherein the IP address information includes at least one of the IP address information of the IAB node, the IP address information of the first IAB donor, and the IP address information of the second IAB donor.
[0107] In some embodiments, the IAB node is configured to migrate from the first IAB donor to the second IAB donor.
[0108] In some embodiments, the F1AP message is a GNB-CU CONFIGURATION UPDATE message or a GNB-DU CONFIGURATION UPDATE ACKNOWLEDGE message.
[0109] FIG. 6 illustrates an example of a wireless communication method (600) for IAB donor migration. The method (600) includes, in operation (610), the step of transmitting a control message containing Internet Protocol (IP) address information of the IAB DU to the IAB donor by the Integrated Access and Backhaul (IAB) Distribution Unit (DU).
[0110] In some embodiments, IP address information is used to establish an IP security (IPsec) tunnel.
[0111] In some embodiments, the control message is an F1 application protocol (F1AP) message or a GNB-DU CONFIGURATION UPDATE message or a GNB-CU CONFIGURATION UPDATE ACKNOWLEDGE message.
[0112] In some embodiments, the IP address information includes at least one of an IP address for IP security (IPsec) for F1-U traffic, an IP address for IPsec for F1-C traffic, an IP address for IPsec for non-F1 traffic, a previous IP address for IPsec for F1-U traffic, a previous IP address for IPsec for F1-C traffic, a previous IP address for IPsec for non-F1 traffic, an IP address for a General Packet Radio Service (GPRS) Tunneling Protocol (GTP) endpoint, and a Backhaul Adaptation Protocol (BAP) address for an IAB node.
[0113] FIG. 7 illustrates an example of a wireless communication method (700) for IAB donor migration. The method (700) includes, in operation (710), the step of transmitting a control message containing Internet Protocol (IP) address information from a first network node to a second network node.
[0114] In some embodiments, the first network node is a central unit (CU) user plane (UP), the second network node is a CU control plane (CP), the control message is an E1 message, and the IP address information includes the IP address information of the first network node.
[0115] In some embodiments, the first network node is a central unit (CU) control plane (CP), the second network node is a CU user plane (UP), the control message is an E1 message, the IP address information includes the IP address information of the third network node, and the third network node is an IAB node configured to connect to the first network node and the second network node.
[0116] In some embodiments, the IP address information includes at least one of an IP address for IP security (IPsec) for F1-U traffic, a previous IP address for IPsec for F1-U traffic, an IP address for a General Packet Radio Service (GPRS) Tunneling Protocol (GTP) endpoint, and a Backhaul Adaptation Protocol (BAP) address for an IAB node.
[0117] FIG. 8 illustrates an example of a wireless communication method (800) for IAB donor migration. The method (800) includes, in operation (810), the step of transmitting a message containing transmission action indicator information that configures the second network node to perform one or more transmission actions for a wireless device by the first network node to the second network node.
[0118] In some embodiments, the first network node is a g-NodeB (gNB), a gNB central unit (gNB-CU), a source IAB donor, or a target IAB donor, the second network node is a gNB-DU or an IAB-DU, and the wireless device is a user equipment (UE).
[0119] In some embodiments, the transmission action indicator information is configured to indicate at least one of stopping data transmission from the source gNB, starting data transmission from the target gNB, restarting data transmission from the target gNB, and stopping data transmission from the target gNB.
[0120] In some embodiments, the message includes (i) information of one or more General Packet Radio Services (GPRS) Tunneling Protocol (GTP) tunnels configured to be started, stopped, or restarted, or (ii) information of one or more Data Radio Bearers (DRBs) configured to be started, stopped, or restarted.
[0121] In some embodiments, information about one of the GTP tunnels includes a Transport Network Layer (TNL) address or a GTP Tunnel Endpoint Identifier (TEID).
[0122] In some embodiments, information on one of the DRBs includes a DRB identifier (ID).
[0123] FIG. 9 is a block diagram representation of a portion of a device according to some embodiments of the technology disclosed herein. For example, the device (905), such as a base station or a wireless device (or UE), may include a processor electronic device (910), such as a microprocessor that implements one or more technologies set forth in this specification. The device (905) may include a transceiver electronic device (915) for transmitting and / or receiving wireless signals through one or more communication interfaces, such as antenna(s) (920), for example. The device (905) may include other communication interfaces for transmitting and receiving data. The device (905) may include one or more memories (not explicitly shown) configured to store information, such as data and / or instructions, for example. In some implementations, the processor electronic device (910) may include at least a portion of the transceiver electronic device (915). In some embodiments, at least some of the disclosed technologies, modules, or functions are implemented using the device (905).
[0124] Some of the embodiments described herein are described in general circumstances of a method or process, which may be implemented in one embodiment by a computer program product embodied on a computer-readable medium, comprising computer-executable instructions, such as program code, executed by a computer in a networked environment. The computer-readable medium may include, but is not limited to, removable and non-removable storage devices such as Read Only Memory (ROM), Random Access Memory (RAM), compact discs (CD), and digital versatile discs (DVD). Accordingly, the computer-readable medium may include non-transient storage media. Generally, a program module may include a routine, program, object, component, data structure, etc., which performs a specific task or implements a specific abstract data type. Computer or processor-executable instructions, associated data structures, and program modules represent examples of program code for executing the steps of the method disclosed herein. A specific sequence of such executable instructions or associated data structures represents an example of a corresponding action for implementing the function described in such a step or process.
[0125] Some of the disclosed embodiments may be implemented as devices or modules using hardware circuits, software, or a combination thereof. For example, a hardware circuit implementation may include discrete analog and / or digital components integrated, for example, as part of a printed circuit board. Alternatively or additionally, the disclosed components or modules may be implemented as Application Specific Integrated Circuit (ASIC) and / or Field-Programmable Gate Array (FPGA) devices. Some implementations may additionally or alternatively include a digital signal processor (DSP), which is a specialized microprocessor having an architecture optimized for the operational needs of digital signal processing associated with the functionality disclosed in this application. Similarly, various components or sub-components within each module may be implemented in software, hardware, or firmware. Connectivity between modules and / or components within modules may be provided using any of the connectivity methods and media known in the art, including but not limited to communication over the Internet, wired, or wireless networks using appropriate protocols.
[0126] Although this specification contains many details, they should not be interpreted as a limitation on the scope of the invention claimed or claimable, but rather as a description of features specific to a particular embodiment. Specific features described in this specification in the context of a separate embodiment may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented separately or in any suitable sub-combination in multiple embodiments. Furthermore, while features may be described above as operating in a specific combination and may be initially claimed as such, one or more features from the claimed combination may be excluded from the combination in some cases, and the claimed combination may be a sub-combination or a variation of the sub-combination. Similarly, operations are depicted in the drawings in a particular order, but this should not be understood as requiring that such operations be performed in the particular order shown or in a sequential order, or that all illustrated operations be performed, in order to achieve a desired result.
[0127] Only a few implementations and examples are described, and other implementations, improvements, and variations may be made based on those described and illustrated in this disclosure.
Claims
Claim 1 A wireless communication method comprising: transmitting an Xn Application Protocol (XnAP) message containing Internet Protocol (IP) address request information by a first integrated access and backhaul (IAB) donor to a second IAB donor, wherein the IP address request information includes a previous IPv4 address, a previous IPv6 address, or a previous IPv6 prefix; and receiving the IP address information from the second IAB donor. Claim 2 A wireless communication method according to claim 1, wherein the IP address information comprises at least one of the IP address information of an IAB node, the IP address information of a first IAB donor, and the IP address information of a second IAB donor. Claim 3 A wireless communication method according to claim 1, wherein the XnAP message includes an XnAP handover request message. Claim 4 A wireless communication method according to paragraph 3, wherein the IP address request information is included in the Radio Resource Control (RRC) Information Element (IE) of the XnAP handover request message. Claim 5 A wireless communication method according to paragraph 3, wherein the IP address request information is included in the HandoverPreparationInformation message within the XnAP handover request message. Claim 6 A wireless communication method according to any one of claims 1 to 5, wherein the IP address request information further comprises at least one of the number of requested IPv4 addresses, the number of requested IPv6 addresses, the use of an IPv6 prefix, the use of the requested IPv4 address, and the use of the requested IPv6 address. Claim 7 A wireless communication method according to any one of claims 1 to 5, wherein the IP address information comprises at least one of an IP address for IP security (IPsec) for F1-U traffic, an IP address for IPsec for F1-C traffic, an IP address for IPsec for non-F1 traffic, a previous IP address for IPsec for the F1-U traffic, a previous IP address for IPsec for the F1-C traffic, a previous IP address for IPsec for the non-F1 traffic, an IP address for a General Packet Radio Service (GPRS) Tunneling Protocol (GTP) endpoint, and a Backhaul Adaptation Protocol (BAP) address for an IAB node. Claim 8 A wireless communication device comprising a processor and a memory, wherein the processor is configured to read a code from the memory and implement a method described in any one of claims 1 to 5. Claim 9 A computer-readable program storage medium storing code that, when executed by a processor, causes the processor to implement the method described in any one of claims 1 to 5. Claim 10 delete Claim 11 delete Claim 12 delete Claim 13 delete Claim 14 delete Claim 15 delete Claim 16 delete Claim 17 delete Claim 18 delete Claim 19 delete Claim 20 delete Claim 21 delete Claim 22 delete Claim 23 delete Claim 24 delete Claim 25 delete Claim 26 delete Claim 27 delete
Citation Information
Patent Citations
Information transmission methods and devices
KR1020210025597A