Communication method of network node, communication method of mobile node, mobile node and host device

Abstract

The embodiment of the invention provides a communication method of a network node, a communication method of a mobile node, the mobile node and host equipment. The method comprises the following steps: a first donor-CU receives first indication information, wherein the first indication information comprises identification information related to a third donor-CU; and the first donor-CU sends second indication information used for indicating the context of the traffic to a third donor-CU.

Description

Communication method of network node, communication method of mobile node, mobile node and host device Technical Field

[0001] The embodiments of the present application relate to the field of communications. Background Art

[0002] Future seamless cellular network deployment requires highly flexible and ultra-dense new radio (NR) cell deployment. Ultra-dense networks are one of the goals of 5G, and deploying an NR network without wired backhaul is crucial to achieving these ultra-dense 5G networks. Because 5G millimeter waves reduce cell coverage, wireless self-backhaul systems require multiple hops to meet deployment requirements. 5G's high bandwidth, massive multiple-input multiple-output (MIMO), and beamforming make it easier to develop ultra-dense NR cell wireless self-backhaul systems for 5G than for LTE. To develop this multi-hop system with wireless self-backhaul, 3GPP initiated research and standardization of the Integrated Access and Backhaul (IAB) project in Rel-16.

[0003] In the IAB system, access and backhaul use NR's Uu air interface wireless transmission. The relay node supports both access and backhaul functions. The relay node multiplexes the access link and backhaul link in the time domain, frequency domain, or spatial domain. The access link and backhaul link can use the same or different frequency bands.

[0004] In the IAB network architecture, the relay node is referred to as the IAB-node, which supports both access and backhaul functions. The last-hop access node on the network side is called the IAB-donor, which supports gNB functions and access to the IAB-node. All UE data is backhauled to the IAB-donor via one or more hops via the IAB-node.

[0005] The IAB-node's functionality is divided into two parts: gNB-DU functionality, known as the IAB-DU (distributed unit), and UE functionality, known as the IAB-MT (mobile terminal). The IAB-DU implements network-side device functions, serving one or more cells and connecting to downstream child IAB-nodes (child IAB nodes, or simply child nodes). It provides NR air interface access to the UE and downstream child IAB-nodes and establishes an F1 connection with the IAB donor-CU (host centralized unit). The IAB-MT implements some terminal device functions and connects to the upstream parent IAB-node (parent IAB node, or simply parent node) or IAB donor-DU. The IAB-MT includes physical layer, layer 2, radio resource control (RRC), and non-access stratum (NAS) layer functions, and is indirectly connected to the IAB donor-CU and the core network (CN).

[0006] Figure 1 is a schematic diagram of the IAB architecture in SA mode. Figure 2 is a schematic diagram of the IAB architecture in EN-DC mode. In an IAB system, an IAB-node can access the network in either standalone (SA) or non-standalone (EN-DC) mode.

[0007] Figure 3 is a schematic diagram of an IAB node, its parent IAB node, and its child IAB node. As shown in Figure 3, the IAB-DU of the IAB node connects to the IAB-MT of the child node on the network side, while the IAB-MT of the IAB node connects to the IAB-DU of the parent node on the terminal side.

[0008] Figure 4 shows the F1 user plane (F1-U) protocol stack between the IAB-DU and the IAB donor-CU. Figure 5 shows the F1 control plane (F1-C) protocol stack between the IAB-DU and the IAB donor-CU. As shown in Figures 4 and 5, F1-U and F1-C are built on the transport (IP) layer between the IAB-DU and the IAB donor-CU. In these figures, the two-hop wireless backhaul and one-hop wired backhaul are used.

[0009] On the backhaul link, the transport (IP) layer is carried on the Backhaul Adaptation Protocol (BAP) sublayer. The BAP entity in the IAB node implements the routing function of the IAB system, and the IAB donor-CU provides the routing table. BAP PDUs (Protocol Data Units) are transmitted on the backhaul link's RLC (Radio Link Control) channel. The IAB donor can configure multiple RLC channels on the backhaul link to carry services of different priorities and QoS (Quality of Service). The BAP entity maps BAP PDUs to different backhaul RLC channels.

[0010] It should be noted that the above introduction to the technical background is only for the convenience of providing a clear and complete description of the technical solutions of this application and for the convenience of understanding by those skilled in the art. It cannot be considered that the above technical solutions are well known to those skilled in the art simply because these solutions are explained in the background technology part of this application.

[0011] Summary of the Invention

[0012] The inventors have found that it has been proposed that a mobile node can move within a donor-CU, but how to perform migration, handover and / or radio link failure (RLF) recovery has not yet been defined and supported.

[0013] In order to solve at least one of the above problems, embodiments of the present application provide a communication method for a network node, a communication method for a mobile node, a mobile node, and a host device.

[0014] According to one aspect of an embodiment of the present application, a communication method of a network node is provided, wherein a first donor-CU is an F1 termination donor-CU of a mobile node, a second donor-CU is a non-F1 termination donor-CU of the mobile node before migration or radio link failure (RLF) recovery, and a third donor-CU is a non-F1 termination donor-CU after migration or RLF recovery of the mobile node.

[0015] The method comprises:

[0016] The first donor-CU receives first indication information, where the first indication information includes identification information related to the third donor-CU; and

[0017] The first donor-CU sends second indication information for indicating a context of traffic to the third donor-CU.

[0018] According to another aspect of an embodiment of the present application, a host device is provided, wherein the host device is an F1-terminating donor-CU of a mobile node, a second donor-CU is a non-F1-terminating donor-CU of the mobile node before migration or radio link failure (RLF) recovery, and a third donor-CU is a non-F1-terminating donor-CU after migration or RLF recovery of the mobile node;

[0019] The host device includes:

[0020] a receiving unit configured to receive first indication information, wherein the first indication information includes identification information related to the third donor-CU; and

[0021] A sending unit sends second indication information for indicating the context of traffic to the third donor-CU.

[0022] According to another aspect of an embodiment of the present application, a communication method of a network node is provided, wherein a first donor-CU is an F1-terminated donor-CU of a mobile node, a second donor-CU is a non-F1-terminated donor-CU of the mobile node before migration or radio link failure (RLF) recovery, and a third donor-CU is a non-F1-terminated donor-CU after migration or RLF recovery of the mobile node.

[0023] The method comprises:

[0024] The second donor-CU sends first indication information to the first donor-CU, where the first indication information includes identification information related to the third donor-CU.

[0025] According to another aspect of an embodiment of the present application, a host device is provided, wherein a first donor-CU is an F1-terminated donor-CU of a mobile node, the host device is a non-F1-terminated donor-CU of the mobile node before migration or radio link failure (RLF) recovery, and a third donor-CU is a non-F1-terminated donor-CU after migration or RLF recovery of the mobile node;

[0026] The host device includes:

[0027] A sending unit sends first indication information to the first donor-CU, where the first indication information includes identification information related to the third donor-CU.

[0028] According to another aspect of an embodiment of the present application, a communication method of a network node is provided, wherein a first donor-CU is an F1-terminated donor-CU of a mobile node, a second donor-CU is a non-F1-terminated donor-CU of the mobile node before migration or radio link failure (RLF) recovery, and a third donor-CU is a non-F1-terminated donor-CU after migration or RLF recovery of the mobile node.

[0029] The method comprises:

[0030] The third donor-CU receives second indication information for indicating the context of traffic sent by the first donor-CU according to identification information; wherein the identification information is related to the third donor-CU and is included in the first indication information received by the first donor-CU.

[0031] According to another aspect of an embodiment of the present application, a host device is provided, wherein a first donor-CU is an F1-terminated donor-CU of a mobile node, a second donor-CU is a non-F1-terminated donor-CU of the mobile node before migration or radio link failure (RLF) recovery, and the host device is a non-F1-terminated donor-CU after migration or RLF recovery of the mobile node;

[0032] The host device includes:

[0033] A receiving unit receives second indication information for indicating a context of traffic sent by the first donor-CU according to identification information; wherein the identification information is related to the third donor-CU and is included in the first indication information received by the first donor-CU.

[0034] One of the beneficial effects of the embodiments of the present application is that: a first donor-CU receives first indication information, the first indication information including identification information related to a third donor-CU; and the first donor-CU sends second indication information indicating a traffic context to the third donor-CU based on the identification information. Thus, it is possible to support the movement of a mobile node within a control area without causing service interruption, thereby ensuring the quality of service provided by the mobile node to a user equipment.

[0035] With reference to the description and accompanying drawings that follow, specific embodiments of the present application are disclosed in detail, indicating how the principles of the present application can be employed. It should be understood that the embodiments of the present application are not limited in scope. Within the spirit and scope of the accompanying notes, the embodiments of the present application include many variations, modifications, and equivalents.

[0036] Features described and / or illustrated with respect to one embodiment may be used in the same or similar manner in one or more other embodiments, combined with features in other embodiments, or substituted for features in other embodiments.

[0037] It should be emphasized that the term "include / comprising" when used herein refers to the presence of features, integers, steps or components, but does not exclude the presence or addition of one or more other features, integers, steps or components. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The elements and features described in one figure or one embodiment of the present application can be combined with the elements and features shown in one or more other figures or embodiments. In addition, in the accompanying drawings, similar reference numerals represent corresponding parts in several figures and can be used to indicate corresponding parts used in more than one embodiment.

[0039] The included drawings are used to provide a further understanding of the embodiments of the present application, which constitute a part of the specification, are used to illustrate the implementation methods of the present application, and together with the text description, explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without inventive work. In the drawings:

[0040] FIG1 is a schematic diagram of the IAB architecture in SA mode;

[0041] FIG2 is a schematic diagram of the IAB architecture of the EN-DC mode;

[0042] FIG3 is a schematic diagram of a parent IAB-node and a child IAB-node;

[0043] FIG4 is a schematic diagram of the F1-U protocol stack of the IAB system;

[0044] FIG5 is a schematic diagram of the F1-C protocol stack of the IAB system;

[0045] FIG6 is a schematic diagram of a mobility scenario according to an embodiment of the present application;

[0046] FIG7 is a schematic diagram of topology adaptation within an m-CU according to an embodiment of the present application;

[0047] FIG8 is a schematic diagram of a communication method of a network node according to an embodiment of the present application;

[0048] FIG9 is a signaling flow chart of topology adaptation according to an embodiment of the present application;

[0049] FIG10 is another signaling flow chart of topology adaptation according to an embodiment of the present application;

[0050] FIG11 is another signaling flow chart of topology adaptation according to an embodiment of the present application;

[0051] FIG12 is a signaling flow chart of RLF recovery according to an embodiment of the present application;

[0052] FIG13 is a schematic diagram of a communication method of a network node according to an embodiment of the present application;

[0053] FIG14 is a schematic diagram of a communication method of a network node according to an embodiment of the present application;

[0054] FIG15 is a schematic diagram of a communication method of a mobile node according to an embodiment of the present application;

[0055] FIG16 is a schematic diagram of a host device according to an embodiment of the present application;

[0056] FIG17 is a schematic diagram of a host device according to an embodiment of the present application;

[0057] FIG18 is a schematic diagram of a host device according to an embodiment of the present application;

[0058] FIG19 is a schematic diagram of a mobile node according to an embodiment of the present application;

[0059] FIG20 is a schematic diagram of an IAB device according to an embodiment of the present application. DETAILED DESCRIPTION

[0060] The above and other features of the present application will become apparent through the following description with reference to the accompanying drawings. In the description and drawings, specific embodiments of the present application are disclosed in detail, which show some embodiments in which the principles of the present application can be adopted. It should be understood that the present application is not limited to the described embodiments. On the contrary, the present application includes all modifications, variations and equivalents that fall within the scope of the attached notes.

[0061] In the embodiments of the present application, the terms "first", "second", etc. are used to distinguish different elements from the name, but do not indicate the spatial arrangement or temporal order of these elements, and these elements should not be limited by these terms. The term "and / or" includes any one and all combinations of one or more of the associated listed terms. The terms "comprising", "including", "having", etc. refer to the presence of the stated features, elements, components or components, but do not exclude the presence or addition of one or more other features, elements, components or components.

[0062] In the embodiments of this application, the singular forms "a," "the," etc. include plural forms and should be broadly understood to mean "a" or "a type" rather than being limited to "one." Furthermore, the term "said" should be understood to include both singular and plural forms, unless the context clearly indicates otherwise. Furthermore, the term "according to" should be understood to mean "at least in part based on...", and the term "based on" should be understood to mean "at least in part based on...", unless the context clearly indicates otherwise.

[0063] In the embodiments of the present application, the term "communication network" or "wireless communication network" may refer to a network that complies with any of the following communication standards, such as New Radio (NR), Long Term Evolution (LTE), Enhanced Long Term Evolution (LTE-A, LTE-Advanced), Wideband Code Division Multiple Access (WCDMA), High-Speed ​​Packet Access (HSPA), etc.

[0064] Furthermore, communication between devices in the communication system may be carried out according to communication protocols of any stage, for example, including but not limited to the following communication protocols: 1G (generation), 2G, 2.5G, 2.75G, 3G, 4G, 4.5G and future 5G, 6G, etc., and / or other communication protocols currently known or to be developed in the future.

[0065] In the embodiments of the present application, the term "network device" refers to, for example, a device in a communication system that connects a terminal device to the communication network and provides services to the terminal device. Network devices may include, but are not limited to, the following devices: base station (BS), access point (AP), transmission reception point (TRP), broadcast transmitter, mobile management entity (MME), gateway, server, radio network controller (RNC), base station controller (BSC), etc.

[0066] Among them, base stations may include but are not limited to: NodeB (NodeB or NB), evolved NodeB (eNodeB or eNB) and 5G base station (gNB), IAB host, etc., and may also include remote radio head (RRH, Remote Radio Head), remote radio unit (RRU, Remote Radio Unit), relay (relay) or low-power node (such as femto, pico, etc.). The term "base station" may include some or all of their functions. Each base station can provide communication coverage for a specific geographical area. The term "cell" can refer to a base station and / or its coverage area, depending on the context in which the term is used.

[0067] In the embodiments of the present application, the term "user equipment" (UE) refers to, for example, a device that accesses a communication network through a network device and receives network services, and may also be referred to as "terminal equipment" (TE). Terminal equipment may be fixed or mobile, and may also be referred to as a mobile station (MS), terminal, user, subscriber station (SS), access terminal (AT), station, etc.

[0068] Among them, terminal devices may include but are not limited to the following devices: cellular phones, personal digital assistants (PDAs), wireless modems, wireless communication devices, handheld devices, machine-type communication devices, laptop computers, cordless phones, smart phones, smart watches, digital cameras, etc.

[0069] For another example, in scenarios such as the Internet of Things (IoT), the terminal device can also be a machine or device for monitoring or measurement, including but not limited to: machine type communication (MTC) terminal, vehicle-mounted communication terminal, device-to-device (D2D) terminal, machine-to-machine (M2M) terminal, and so on.

[0070] Currently, the demand for improved 5G cellular coverage and connectivity is increasing, especially in many outdoor and mobile scenarios, which are more challenging. In some outdoor environments, vehicles equipped with mobile base station relays (such as mobile IABs) can provide a high opportunity to improve cellular coverage and capacity when and where needed. These vehicles either follow a known or predictable route, such as buses and trams, or are placed in convenient locations, such as outside stadiums, hot spots, or emergency scenes.

[0071] These relays use 5G wireless backhaul to the macro network, which can actually provide better 5G coverage and connectivity to nearby UEs. Vehicle relays are also obviously very suitable for improving the connectivity performance of users or devices in the vehicle itself, including scenarios such as passengers in buses, cars, taxis or trains, temporary / professional personnel or equipment. Other target scenarios include vehicle relays can be used to serve user devices with no or very poor macro coverage. Moving vehicles are equipped with small on-board base station relays to provide 5G coverage and communication to nearby UEs inside and / or outside the vehicle, wirelessly connected to the 5G network through the RAN (host) node.

[0072] Taking the IAB node as an example, the IAB-MT can migrate to a parent node under a different IAB-donor-CU. In this case, the collocated IAB-DU and the IAB-DU of the descendant node maintain the F1 connection with the original IAB-donor-CU. This migration is called inter-donor partial migration. The IAB node to which the IAB-MT migrates to the new IAB-donor-CU is called a border IAB node. After the inter-donor partial migration, the F1 traffic of the IAB-DU and the descendant node is routed via the BAP layer of the IAB topology to which the IAB-MT migrates.

[0073] When an SA-mode IAB node declares a backhaul link RLF, it can perform RLF recovery on the parent node under a different IAB-donor-CU. Similar to inter-host partial migration, the collocated IAB-DU and the IAB-DU of the descendant node can maintain the F1 connection with the original IAB-donor-CU.

[0074] A challenge with mobile IAB (mIAB) or mobile relay mobility over a large area is that when it changes IAB hosts, the PDCP (packet data convergence protocol) and RRC connections of the UEs it serves are affected. Consequently, even stationary UEs in vehicles may experience significant signaling overhead due to both idle (due to the need to adjust the TA value to the new gNB-assigned value and change the PDCP endpoint and security for the user plane) and connected mobility.

[0075] Figure 6 is a schematic diagram of a mobility scenario in an embodiment of the present application. As shown in Figure 6, if the DU of the mIAB is served by a CU covering a larger area, the root cause of these mobility-related signaling can be eliminated. In short, it is an advanced approach to provide a dedicated mobility control unit (which may be called m-CU) for the host function of the mIAB to control the UE connected to the mIAB. This enables the mIAB to move within a relatively large RAN coverage area without changing the m-CU. Therefore, the movement of the mIAB between IAB hosts can be invisible to the UE connected to the mIAB as long as the controller is located in the same m-CU.

[0076] However, when the m-CU does not change, how to achieve IAB mobility within the m-CU (intra-m-CU), that is, the migration and RLF recovery of the mIAB, has not yet been defined and supported. The embodiments of the present application relate to the partial migration process of the mIAB within the m-CU, that is, the topology adaptation process within the m-CU.

[0077] In an embodiment of the present application, the m-CU can be a dedicated IAB-donor-CU, that is, the F1-terminating donor-CU of the IAB node or IAB-DU. Partial migration of the IAB node within the m-CU means that the IAB-MT can be migrated to a different IAB-donor-CU or its parent node. In this case, the RRC connection of the IAB-MT is migrated from the source IAB-donor-CU to the target IAB-donor-CU, and the collocated IAB-DU maintains the F1 connection with the original IAB-donor-CU (that is, the m-CU).

[0078] During the movement of mIAB, IAB-MT can continuously migrate to different IAB-donor-CU or the parent node under it. The F1 traffic of IAB-DU is routed through the BAP layer of the IAB topology to which IAB-MT migrates. Similarly, when the mIAB node declares the backhaul link RLF, it can perform RLF recovery at the parent node under different IAB-donor-CU. Like the partial migration within the m-CU, the collocated IAB-DU can maintain the F1 connection with the original m-CU. If the source IAB-donor-CU of the mIAB-MT is the m-CU, the migration process within the m-CU of the mAB is the partial migration / RLF recovery process defined in Rel-17.

[0079] Figure 7 is a schematic diagram of topology adaptation within an m-CU according to an embodiment of the present application. As shown in Figure 7, if the source IAB-donor-CU of the mAB is not an m-CU, the intra-m-CU migration process of the mAB can also be considered as a partial migration process between non-F1 termination hosts, that is, the process of changing the non-F1 termination host.

[0080] In the embodiments of the present application, unless otherwise specified, the IAB node device includes a migration node or its child nodes. In addition, the mobile node is not limited to the IAB node, and for example, a relay, a network-controlled repeater (NCR), etc. are also applicable.

[0081] The following further describes the embodiments of the present application.

[0082] Embodiments of the first aspect

[0083] An embodiment of the present application provides a communication method for a network node, which is described from the perspective of a first donor-CU. The first donor-CU is an F1-terminated donor-CU of a mobile node, the second donor-CU is a non-F1-terminated donor-CU before the mobile node migrates or recovers from a radio link failure (RLF), and may also be referred to as a source donor-CU or an initial donor-CU. The third donor-CU is a non-F1-terminated donor-CU after the mobile node migrates or recovers from an RLF, and may also be referred to as a target donor-CU or a new donor-CU.

[0084] FIG8 is a schematic diagram of a communication method of a network node according to an embodiment of the present application. As shown in FIG8 , the method includes:

[0085] 801. A first donor-CU receives first indication information, where the first indication information includes identification information related to the third donor-CU; and

[0086] 802. The first donor-CU sends second indication information for indicating a traffic context to the third donor-CU.

[0087] It is worth noting that FIG8 above is merely a schematic illustration of an embodiment of the present application, and the present application is not limited thereto. For example, the execution order of the various operations may be appropriately adjusted, and other operations may be added or some operations may be reduced. Those skilled in the art may make appropriate modifications based on the above description, and are not limited to the description of FIG8 above.

[0088] In some embodiments, the first donor-CU is an F1 termination donor-CU for multiple mobile nodes in a designated area; the F1 connections of the multiple mobile nodes always terminate at the first donor-CU. That is, the first donor-CU is the m-CU described in FIG7 .

[0089] Taking Figure 7 as an example, during the topology adaptation process within the m-CU, IAB node 3 (mobile node) performs topology adaptation within the m-CU. In the topology diagram on the left of Figure 7, IAB node 3 is connected to IAB-donor 1 (a collective term for donor-CU 1 and donor-DU 1 in Figure 7 , which illustrates a CU-DU separation scenario; a centralized scenario with the CU and DU coexisting on the same node is also possible) via its parent node, IAB node 1 (parent node IAB node 1 is optional and can also be directly connected to the IAB-donor). This means that the source IAB-donor for IAB-MT 3 is IAB-donor 1 (the second donor-CU), and the endpoint of IAB-MT 3's RRC connection is IAB-donor 1. IAB-donor 1 is also called the non-F1 termination host of IAB node 3. The F1 termination host of IAB node 3 is the m-CU (the first donor-CU) in Figure 7 . The F1 traffic of IAB-DU 3, that is, the traffic of the UE of IAB node 3, passes through IAB-MT 3 and IAB-donor 1 and reaches the m-CU.

[0090] During IAB node 3's mobility, it will migrate to the topology shown on the right side of Figure 7. IAB node 3 connects to IAB-donor 2 (collectively referred to as donor-CU 2 and donor-DU 2 in Figure 7) through its parent node, IAB node 2 (parent node IAB node 2 is optional; it can also connect directly to an IAB-donor). This means that IAB-MT 3's target IAB-donor is IAB-donor 2 (the third donor-CU), and the RRC connection endpoint for IAB-MT 3 is IAB-donor 2. IAB-donor 2 becomes the non-F1 termination host for IAB node 3. The F1 termination host for IAB node 3 remains the m-CU shown in Figure 7. F1 traffic for IAB-DU 3, and therefore traffic for UEs connected to IAB node 3, flows through IAB-MT 3 and IAB-donor 2 to the m-CU.

[0091] In some embodiments, the first donor-CU receives address information sent by the mobile node, indicating that the mobile node is anchored on the donor-DU (eg, donor-DU 2 in FIG. 7 ) of the third donor-CU.

[0092] In some embodiments, the second indication information is sent by transmitting a migration management request message, and the second indication information includes downlink address information so that the third donor-CU configures or modifies downlink mapping.

[0093] In some embodiments, the first donor-CU receives a transport migration management response message sent by the third donor-CU, where the transport migration management response message includes mapping information of the traffic to be offloaded and / or layer 2 information in the topology of the third donor-CU.

[0094] In some embodiments, the first donor-CU sends uplink backhaul information of traffic to the mobile node.

[0095] The above schematically illustrates the partial migration between hosts. The following further illustrates the first indication information.

[0096] In some implementations, the first indication information is sent by the second donor-CU via a transport migration modification request message; and the first donor-CU sends a transport migration modification response message to the second donor-CU.

[0097] The transport migration modification request message includes the target cell global identifier of the mobile node or the global node identifier of the target host node. For example, the target cell global identifier of the mobile node or the global node identifier of the target host node is included in the traffic released information element carried by the transport migration modification request message.

[0098] In addition, the transport migration modification request message may further include a traffic release reason, wherein the traffic release reason includes: the mobile node performs an inter-host handover, or the mobile node performs an inter-host radio link failure (RLF) recovery.

[0099] The following further illustrates the topology adaptation process of the embodiment of the present application through signaling interaction.

[0100] FIG9 is a signaling flow chart of topology adaptation according to an embodiment of the present application.

[0101] As shown in Figure 9, the migrated IAB node (IAB node 3) undergoes a change to a non-F1 terminating host, while maintaining its F1 terminating host. Figure 9 assumes that the migrated node has a parent node on both the source and target paths, as well as intermediate nodes between the parent node and the IAB-donor. These nodes do not need to exist, in which case the parent node of the migrated node is the IAB-donor.

[0102] As shown in Figure 9, the process includes:

[0103] 901. The source IAB-donor-CU sends an Xn HANDOVER REQUEST message to the target IAB-donor-CU. This message may include the TNL (transport network layer) address information of the migrating IAB node in the RRC container.

[0104] 902. The target IAB-donor-CU sends a UE CONTEXT SETUP REQUEST message to the IAB-DU of the target parent node to create a UE context for the migrated IAB-MT and establish a bearer for signaling and optional data traffic of the migrated IAB-MT.

[0105] 903. The IAB-DU of the target parent node replies with a UE CONTEXT SETUP RESPONSE message to the target IAB-donor-CU.

[0106] 904. The target IAB-donor-CU performs admission control and provides a new RRC configuration via part of the HANDOVER REQUEST ACKNOWLEDGE message. The RRC configuration includes the migrating node's BAP address in the target IAB-donor-CU's topology, the default BH RLC channel, and the default BAP routing identifier configuration for uplink F1-C / non-F1 traffic mapping on the target path. The RRC configuration may also include the migrating node's new TNL address(es) anchored on the target IAB-donor-DU.

[0107] 905. The source IAB-donor-CU sends a UE CONTEXT MODIFICATION REQUEST message to the source parent node IAB-DU, which includes the RRCReconfiguration message received from the target IAB-donor-CU.

[0108] 906. The source parent node IAB-DU forwards the received RRCReconfiguration message to the migration IAB-MT.

[0109] 907. The source parent node IAB-DU replies with a UE CONTEXT MODIFICATION RESPONSE message to the source IAB-donor-CU.

[0110] 908. The migrating IAB-MT performs a random access procedure to the target parent node IAB-DU.

[0111] 909. The migrating IAB-MT responds with an RRCReconfigurationComplete message to the target parent node IAB-DU.

[0112] 910. The target parent node IAB-DU sends a UL RRC MESSAGE TRANSFER message to the target IAB-donor-CU, which carries the received RRCReconfigurationComplete message.

[0113] 911. If necessary, the target IAB-donor-CU triggers a path switching process for the migrating IAB-MT.

[0114] 912. The target IAB-donor-CU sends a UE CONTEXT RELEASE message to the source IAB-donor-CU.

[0115] If the source IAB-donor-CU is an m-CU, as long as the target path is used to transmit traffic between the migrating node and the source IAB-donor-CU, both the source IAB-donor-CU and the target IAB-donor-CU need to save the migrating node's XnAP UE ID. If the source IAB-donor-CU is not an m-CU, the target path does not need to transmit traffic between the migrating node and the source IAB-donor-CU (that is, the migrating node's traffic does not pass through the source IAB-donor-CU), and the source IAB-donor-CU can release the migrating node's XnAP UE ID.

[0116] 913. The source IAB-donor-CU may release the routing entries of the BH RLC channel and the BAP sublayer on the source path from the source parent node of the migrating IAB node to the source IAB-donor-DU.

[0117] 914. The target IAB-donor-CU configures the BH RLC channel and BAP sublayer routing entries on the target path from the migrating IAB node to the target IAB-donor-DU, as well as the downlink mapping of the target path for the migrating IAB node on the target IAB-donor-DU. These configurations support the transport of F1-C traffic on the target path.

[0118] 915. The F1-C connection between the migrating IAB node and the m-CU is switched to the target path using the new TNL address information of the migrating IAB node. The migrating IAB node may report the new TNL address it intends to use for F1-U traffic to the m-CU via a gNB-DU CONFIGURATION UPDATE message.

[0119] If an IPsec tunnel is used for TNL protection, the migrating IAB node can use MOBIKE (IETF RFC 4555) to migrate the IPsec tunnel to a new external IP address. After the MOBIKE process is complete, the migrating IAB-DU initiates the gNB-DU Configuration Update process on the F1AP. During this process, the IAB-donor-CU can determine whether the existing internal IP address (for example, for SCTP-stream control transmission protocol association) and downlink F-TEID (Fully Qualified Tunnel Endpoint Identifier) ​​can be reused.

[0120] If a new TNL address is configured for F1-C traffic, a new SCTP association can be created between the migrating IAB node and the F1 terminating IAB-donor-CU using the new TNL address information of the migrating IAB. The migrating IAB node sends the F1AP's gNB-DU CONFIGURATION UPDATE message to the F1 terminating IAB-donor-CU (m-CU). The message may include the new (external) IP address and the corresponding new (internal) IP address for switching F1-U traffic to the target path.

[0121] 916. The source IAB-donor-CU sends an IAB TRANSPORT MIGRATION MODIFICATION REQUEST message to the m-CU to request the release of all offloaded traffic. This message may contain the node ID (or target cell ID) of the target IAB-donor-CU, the reason for the traffic offload release, etc.

[0122] 917. The m-CU replies with an IAB TRANSPORT MIGRATION MODIFICATION RESPONSE message to the source IAB-donor-CU.

[0123] 918. The m-CU sends an IAB TRANSPORT MIGRATION MANAGEMENT REQUEST message to the target IAB-donor-CU to provide the context of the traffic to be offloaded. This message may include new downlink TNL address information, which the target IAB-donor-CU uses to configure or modify downlink mapping on the IAB-donor-DU.

[0124] 919. The target IAB-donor-CU may configure or modify the BH RLC channel and BAP sublayer routing entries on the target path from the migrating IAB node to the target IAB-donor-CU, as well as the downlink mapping of the target path for the migrating IAB node on the target IAB-donor-DU. These configurations may support the transport of user plane and non-user plane traffic on the target path.

[0125] 920. The target IAB-donor-CU responds to the m-CU with an IAB Transport Migration Management Response message, which provides mapping information for the traffic to be offloaded. This message contains Layer 2 information for the target IAB-donor-CU topology, which is necessary to configure the upstream mapping of the traffic indicated in 918 on the migrating IAB node. This message also contains the DSCP (Differentiated Services Code Point) / IPv6 flow label value used to configure the downstream mapping of the traffic indicated in 918.

[0126] 921. The F1-U connection of the migrating IAB node to the m-CU is switched by using the new TNL address of the migrating IAB node. Based on the uplink backhaul information received from the target IAB-donor-CU in 1020, the m-CU provides the IAB-DU of the migrating IAB node with updated uplink backhaul information about the traffic indicated in 918. The m-CU may also update the uplink backhaul information associated with non-user plane traffic. This step may use UE-associated signaling or non-UE-associated signaling on the E1 and / or F1 interface. During implementation, it must be ensured that possible contention is avoided, that is, conflicting configurations cannot be performed simultaneously using the UE-associated process and the non-UE-associated process.

[0127] 922. If necessary, repeat steps 918 to 921. This allows the m-CU to request more traffic offload, or request to modify or release the offloaded traffic. The target IAB-donor-CU can deny the m-CU's request to increase or modify traffic offload in whole or in part.

[0128] The target IAB-donor-CU can use the TRANSPORT MIGRATION MODIFICATION REQUEST message to request modifications to the Layer 2 transport for offloaded traffic in the target IAB-donor-CU's topology. Based on the request, the m-CU reconfigures the uplink backhaul mapping and confirms the modification with an IAB TRANSPORT MIGRATION MODIFICATION RESPONSE message. The target IAB-donor-CU can further reconfigure the TNL address of the migrating IAB node via RRC.

[0129] The above signaling process is merely an illustrative example of the present application, but the present application is not limited thereto. For more specific information about the signaling process, please refer to the relevant art. Furthermore, for example, the execution order of the various operations may be appropriately adjusted, and other operations may be added or some operations may be reduced. Those skilled in the art may make appropriate modifications based on the above content, and are not limited to the description in FIG. 9 above.

[0130] In this embodiment of the present application, the existing IAB TRANSPORT MIGRATION MODIFICATION REQUEST message is enhanced at 916. This XnAP message is sent by a non-F1 terminating IAB-donor-CU of a border IAB node to an F1 terminating IAB-donor-CU to modify or release (e.g., for traffic fallback purposes) the configuration related to the migration traffic of the border IAB node.

[0131] For example, the enhanced part may be to add a new IE or field in the message, such as adding a new field in the Traffic To Be Released Information IE, indicating that the sender, that is, the non-F1 termination host of the IAB node, serves as the source host of the IAB node, switches the IAB node to the target host and informs the target host node of the node identifier or the cell identifier of the target cell.

[0132] Table 1 shows an example of a traffic to be released information element in an embodiment of the present application, which is an enhanced Traffic To Be Released Information IE.

[0133] Table 1

[0134]

[0135] As shown in Table 1, a field such as Target Cell Global ID can be added to the Full Release group to indicate the target cell global identity (CGI) of the IAB node. This field can also be replaced with the global NG-RAN node identity indicating the target donor node, such as Target Global NG-RAN Node ID.

[0136] Because the cell global identifier contains the global NR-RAN node identifier, the F1 termination host of the IAB node can know the target IAB host of the IAB node through the received message. When the F1 termination host of the IAB node receives the target cell identifier or the node identifier of the target IAB host, it can perform the IAB transmission migration management process on the target host node and migrate the F1 traffic of IAB node 3 to the topology of the target host node.

[0137] A field called Cause can be added to the Full Release group to indicate the reason for releasing all traffic. For example, the value could be HO (handover), indicating that the migrating IAB node performed an inter-host handover. New values, such as Handover, can be defined in the Cause IE of the XnAP.

[0138] In some other embodiments, the first indication information is sent by the second donor-CU via a migration notification message in an XnAP message. Optionally, the first donor-CU sends a migration notification confirmation message to the second donor-CU.

[0139] The relocation notification message includes a target cell global identifier of the mobile node or a global node identifier of the target host node. Furthermore, the relocation notification message includes a relocation reason. The relocation reason includes: the mobile node performing an inter-host handover, or the mobile node performing an inter-host radio link failure (RLF) recovery.

[0140] The following further illustrates the topology adaptation process of the embodiment of the present application through signaling interaction.

[0141] FIG10 is another signaling flow chart of topology adaptation according to an embodiment of the present application.

[0142] As shown in Figure 10, the migrated IAB node (IAB node 3) changes to a non-F1 terminating host, maintaining its F1 terminating host. Figure 10 assumes that the migrated node has a parent node on both the source and target paths, as well as intermediate nodes between the parent node and the IAB-donor. These nodes do not need to exist, in which case the parent node of the migrated node is the IAB-donor.

[0143] The process shown in Figure 10 is essentially the same as that in Figure 9 , and the details are not repeated here. The difference is that steps 916 and 917 in Figure 9 have been replaced with a new basic Xn process (shown as steps 1016 and 1017 ). This can be either a Class 1 or a Class 2 basic process. This new Xn process serves the same purpose as steps 916 and 917 in Figure 9 : it is used by the source IAB host node to notify the m-CU that the IAB-MT of IAB node 3 has been switched to the target IAB host. This process can be called the IAB Migration Notification process.

[0144] As shown in Figure 10, the non-F1 terminating IAB-donor-CU of the border IAB node sends a notification message to the F1 terminating IAB-donor-CU, such as an IAB MIGRATION NOTIFICATION message. In addition to the message type, the F1 terminating IAB host UE XnAP ID, the non-F1 terminating IAB host UE XnAP ID, the message may also include the target cell global identifier, the reason for the notification, etc.

[0145] Table 2 shows an example of an information element in a notification message according to an embodiment of the present application.

[0146] Table 2

[0147]

[0148] As shown in Table 2, the specific content of IE is the same as the corresponding fields in Table 1.

[0149] If the procedure is Type 2, the m-CU does not need to reply. If the procedure is Type 1, the m-CU must reply to the sender, for example, with an IAB MIGRATION NOTIFICATION ACKNOWLEDGE message. This message indicates successful receipt of the IAB MIGRATION NOTIFICATION message and may also indicate to the source IAB host node that it can release the XnAP UE ID of the migrating node stored in the source IAB host node.

[0150] In some implementations, the first indication information is sent by the mobile node via an F1AP message.

[0151] For example, the F1AP message is a gNB-DU configuration update message, and the gNB configuration update message includes: address information of the mobile node anchored on the donor-DU of the third donor-CU and the first indication information. For example, the F1AP message includes a target cell global identifier of the mobile IAB node or a global node identifier of a target donor node.

[0152] In addition, the F1AP message includes a migration reason, wherein the migration reason includes: the mobile node performs an inter-host handover, or the mobile node performs an inter-host radio link failure (RLF) recovery.

[0153] The following further illustrates the topology adaptation process of the embodiment of the present application through signaling interaction.

[0154] FIG11 is another signaling flow chart of topology adaptation according to an embodiment of the present application.

[0155] As shown in Figure 11, the migrated IAB node (IAB node 3) undergoes a change to a non-F1 terminating host, maintaining its F1 terminating host. Figure 11 assumes that the migrated node has a parent node on both the source and target paths, as well as intermediate nodes between the parent node and the IAB-donor. These nodes do not need to exist, in which case the parent node of the migrated node is the IAB-donor.

[0156] The process shown in Figure 11 is essentially the same as that in Figure 9 , and the details are not repeated here. The difference is that in step 1115 of Figure 11 , the DU of the border IAB node can be used to notify the m-CU that the mobile equipment (MT) of the border IAB node has been handed over to the cell of the target IAB host node. This can be achieved by F1AP signaling from the border IAB-DU to the m-CU. For example, the gNB-DU CONFIGURATION UPDATE message of the enhanced F1AP can be used to report the target cell global identifier of the migrating IAB-MT to the m-CU.

[0157] Specifically, at 1115, the F1-C connection between the migrating IAB node and the m-CU is switched to the target path using the migrating IAB node's new TNL address information. The migrating IAB node may report the new TNL address it intends to use for F1-U traffic to the m-CU via a gNB-DU CONFIGURATION UPDATE message. In the gNB-DU CONFIGURATION UPDATE message, the migrating IAB-DU may also report the target cell global identity of the migrating IAB-MT.

[0158] Table 3 shows an example of the modified gNB-DU CONFIGURATION UPDATE message.

[0159] Table 3

[0160]

[0161] As shown in Table 3, the indication information of the IAB-MT target cell is added to the message, such as the IAB Migration Target Cell CGI IE. The target cell CGI of the IAB node migration is composed of the PLMN-Identity (Public Land Mobile Network-Identity) and cellIdentity (cell identity) obtained by the migrating IAB-MT from the SIB1 message of the target cell.

[0162] Similar to the previous implementation, this IE can also be replaced with the identifier of the target host node, such as the global NG-RAN node identifier. This IE is called, for example, IAB Migration Target Global NG-RAN Node ID. This global node identifier can also be obtained from the PLMN-Identity and cellIdentity (cell identifier) ​​obtained by the migrating IAB-MT from the SIB1 message of the target cell. The message can also include the IAB Migration Cause IE. Similar to the previous implementation, a new value can be defined in the Cause IE of the F1AP, such as Handover.

[0163] As shown in FIG. 11 , 916 and 917 in FIG. 9 or 1016 and 1017 in FIG. 10 may be removed.

[0164] The topology adaptation process of the embodiment of the present application is described above by taking handover as an example. The following is a schematic description of revocation.

[0165] An IAB node may migrate within an m-CU due to traffic offloading or node mobility. Traffic offloading or mobility performed during topology adaptation within the m-CU for the migrated IAB node can be fully rolled back.

[0166] For example, a non-F1-terminating IAB-donor-CU can initiate a full traffic fallback to the m-CU by executing the XnAP handover preparation process. When the migrating IAB-MT switches to the m-CU, the IAB-DU traffic of the migrating IAB node is routed through the m-CU topology. At this point, both the F1-terminating host and the RRC-terminating node of the migrating IAB node are m-CUs, thus completing the partial migration state.

[0167] For another example, a non-F1-terminating IAB-donor-CU can also initiate a full traffic fallback to the previous source IAB-donor-CU by executing the XnAP handover preparation process. This process is equivalent to performing topology adaptation within the m-CU again, and the process is consistent with the previous embodiment. Traffic from the IAB-DU of the migrated IAB node is rerouted along the previous source path.

[0168] In some embodiments, the first donor-CU requests the third donor-CU to release all offload traffic or release part of the offload traffic by transmitting a migration management request message.

[0169] For example, the m-CU can initiate a full traffic fallback by requesting the non-F1 terminating IAB-donor-CU to release all offloaded traffic. This request involves sending an IAB TRANSPORT MIGRATION MANAGEMENT REQUEST message to the non-F1 terminating IAB-donor-CU. This message triggers the XnAP handover preparation process for migrating the IAB-MT to the m-CU.

[0170] For another example, the m-CU may also request the non-F1 terminating IAB-donor-CU to release part of the offloaded traffic through the IAB TRANSPORT MIGRATION MANAGEMENT REQUEST message.

[0171] The following is a schematic illustration of RLF recovery.

[0172] The IAB node's radio link failure (RLF) recovery process within the m-CU allows the IAB node to recover to the parent node under another IAB-donor-CU when it detects a backhaul RLF, while maintaining the m-CU as the F1-terminated IAB-donor-CU. The recovered IAB node then becomes a boundary node. The IAB-MT RLF recovery process is the same as the inter-host backhaul RLF recovery process in the prior art, as shown in steps 1201-1213 in Figure 12. During the RLF recovery process, the second donor-CU of the IAB node is also called the initial donor-CU, and the third donor-CU is also called the new donor-CU.

[0173] During the F1 transmission migration process of the boundary IAB node, the same steps as the topology adaptation method within the m-CU are adopted, which is consistent with the aforementioned embodiment. Figures 9 to 11 can be adaptively modified to the RLF recovery process of the corresponding IAB node within the m-CU.

[0174] Figure 12 is a signaling diagram of the RLF recovery process according to an embodiment of the present application. As shown in Figure 12, the corresponding steps in 1218 are the same as the corresponding steps in Figures 9 to 11 (e.g., steps 914 to 922, or steps 1014 to 1022, or steps 1114 to 1120), and are not further described here. The Cause value in each corresponding embodiment indicates the reason for releasing all traffic or the reason for migration. For example, the Cause value in the RLF recovery process can be RLF recovery, indicating that the IAB node has performed inter-host RLF recovery.

[0175] The new IAB-donor-CU can use the TRANSPORT MIGRATION MODIFICATION REQUEST message to request modifications to the Layer 2 transport of offloaded traffic in the new IAB-donor-CU's topology. The m-CU reconfigures the uplink backhaul mapping based on the request and confirms the modification with an IAB TRANSPORT MIGRATION MODIFICATION RESPONSE message. The new IAB-donor-CU can further reconfigure the TNL address of the restored IAB node via RRC. The traffic fallback process for the restored IAB node via RLF is the same as the fallback process for the migrated node described above.

[0176] The above embodiments can solve the problems of IAB node migration between non-F1 host nodes, RLF recovery, traffic fallback, etc., thereby supporting the IAB node to move within the control area of ​​the m-CU and ensuring the service quality of the mobile IAB node to the UE.

[0177] The above embodiments are merely exemplary of the present invention, but the present invention is not limited thereto. Appropriate modifications may be made based on the above embodiments. For example, the above embodiments may be used alone, or one or more of the above embodiments may be combined.

[0178] As can be seen from the above embodiment, the first donor-CU receives first indication information including identification information related to the third donor-CU; and the first donor-CU sends second indication information indicating a traffic context to the third donor-CU based on the identification information. This allows the mobile node to move within the control area without causing service interruption, thereby ensuring the quality of service provided by the mobile node to the user equipment.

[0179] Embodiments of the second aspect

[0180] The embodiment of the present application provides a communication method for a network node, which is described from the perspective of a second donor-CU. The contents identical to those of the embodiment of the first aspect are not repeated here. The first donor-CU is an F1-terminated donor-CU of a mobile node, the second donor-CU is a non-F1-terminated donor-CU of the mobile node before migration or radio link failure (RLF) recovery, and the third donor-CU is a non-F1-terminated donor-CU after migration or RLF recovery.

[0181] FIG13 is a schematic diagram of a communication method of a network node according to an embodiment of the present application. As shown in FIG13 , the method includes:

[0182] 1301. The second donor-CU sends first indication information to the first donor-CU, where the first indication information includes identification information related to the third donor-CU.

[0183] It is worth noting that FIG13 above is merely a schematic illustration of an embodiment of the present application, and the present application is not limited thereto. For example, the execution order of the various operations may be appropriately adjusted, and other operations may be added or some operations may be reduced. Those skilled in the art may make appropriate modifications based on the above description, and are not limited to the description of FIG13 above.

[0184] In some embodiments, the first indication information is sent by the second donor-CU by transmitting a migration modification request message; as shown in FIG13 , the method may further include:

[0185] 1302. The second donor-CU receives the transmission migration modification response message sent by the first donor-CU.

[0186] In some embodiments, the transmission migration modification request message includes a target cell global identifier of the mobile node or a global node identifier of a target donor node.

[0187] In some embodiments, the target cell global identifier of the mobile node or the global node identifier of the target donor node is included in the traffic released information element carried by the transport migration modification request message.

[0188] In some embodiments, the transmission migration modification request message includes a traffic release reason.

[0189] In some embodiments, the traffic release reason includes: the mobile node performing an inter-host handover, or the mobile node performing an inter-host radio link failure (RLF) recovery.

[0190] In some embodiments, the first indication information is sent by the second donor-CU via a migration notification message in an XnAP message.

[0191] In some embodiments, the second donor-CU receives a migration notification confirmation message sent by the first donor-CU.

[0192] In some embodiments, the relocation notification message includes a target cell global identifier of the mobile node or a global node identifier of a target host node.

[0193] In some embodiments, the migration notification message includes a migration reason.

[0194] In some embodiments, the migration reason includes: the mobile node performing an inter-host handover, or the mobile node performing an inter-host radio link failure (RLF) recovery.

[0195] The above embodiments are merely exemplary of the present invention, but the present invention is not limited thereto. Appropriate modifications may be made based on the above embodiments. For example, the above embodiments may be used alone, or one or more of the above embodiments may be combined.

[0196] As can be seen from the above embodiment, the second donor-CU sends first indication information to the first donor-CU, where the first indication information includes identification information related to the third donor-CU; wherein the identification information is used by the first donor-CU to send second indication information indicating a traffic context to the third donor-CU. This supports the movement of mobile nodes within the control area without causing service interruption, thereby ensuring the quality of service provided by the mobile nodes to user equipment.

[0197] Embodiments of the third aspect

[0198] The present embodiment provides a communication method for a network node, which is described from the perspective of a third donor-CU. The contents identical to those of the first and second embodiments are not repeated here. The first donor-CU is an F1-terminated donor-CU of a mobile node, the second donor-CU is a non-F1-terminated donor-CU of the mobile node before migration or radio link failure (RLF) recovery, and the third donor-CU is a non-F1-terminated donor-CU after migration or RLF recovery.

[0199] FIG14 is a schematic diagram of a communication method of a network node according to an embodiment of the present application. As shown in FIG14 , the method includes:

[0200] 1401. The third donor-CU receives second indication information for indicating the context of traffic sent by the first donor-CU according to identification information; wherein the identification information is related to the third donor-CU and is included in the first indication information received by the first donor-CU.

[0201] It is worth noting that FIG14 above merely illustrates an embodiment of the present application and is not intended to be limiting. For example, the execution order of the various operations may be appropriately adjusted, and other operations may be added or some operations may be omitted. Those skilled in the art may make appropriate modifications based on the above description and are not limited to the description in FIG14 above.

[0202] In some embodiments, the second indication information is sent by transmitting a migration management request message. As shown in FIG14 , the method may further include:

[0203] 1402. The third donor-CU configures or modifies the downlink mapping according to the downlink address information included in the second indication information.

[0204] In some embodiments, the third donor-CU sends a transport migration management response message to the first donor-CU, wherein the transport migration management response message includes mapping information of the traffic to be offloaded and / or layer 2 information in the topology of the third donor-CU.

[0205] In some embodiments, the third donor-CU initiates traffic fallback of switching the mobile terminal (MT) of the mobile node to the first donor-CU.

[0206] In some embodiments, in the event that the mobile terminal of the mobile node is handed over to the first donor-CU, traffic of the distribution unit (DU) of the mobile node is routed through the topology of the first donor-CU.

[0207] In some embodiments, the third donor-CU initiates traffic fallback of the mobile terminal of the mobile node switching to the second donor-CU.

[0208] In some embodiments, in case the mobile terminal of the mobile node is handed over to the second donor-CU, the traffic of the distribution unit of the mobile node is routed through the topology of the second donor-CU.

[0209] The above embodiments are merely exemplary of the present invention, but the present invention is not limited thereto. Appropriate modifications may be made based on the above embodiments. For example, the above embodiments may be used alone, or one or more of the above embodiments may be combined.

[0210] As can be seen from the above embodiment, the third donor-CU receives second indication information indicating a traffic context sent by the first donor-CU based on identification information; wherein the identification information is related to the third donor-CU and included in the first indication information received by the first donor-CU. This supports the movement of mobile nodes within the control area without causing service interruption, thereby ensuring the quality of service provided by the mobile nodes to user equipment.

[0211] Embodiments of the fourth aspect

[0212] The embodiments of the present application provide a communication method for a mobile node, which is described from the perspective of the mobile node. The contents identical to those of the first to third embodiments are not repeated here. The first donor-CU is an F1-terminated donor-CU of the mobile node, the second donor-CU is a non-F1-terminated donor-CU of the mobile node before migration or radio link failure (RLF) recovery, and the third donor-CU is a non-F1-terminated donor-CU after migration or RLF recovery.

[0213] FIG15 is a schematic diagram of a communication method of a mobile node according to an embodiment of the present application. As shown in FIG15 , the method includes:

[0214] 1501 : The F1-C connection between the mobile node and the first donor-CU is switched to a target path by using the address information of the mobile node anchored on the donor-DU of the third donor-CU.

[0215] It is worth noting that FIG15 above is merely a schematic illustration of an embodiment of the present application, and the present application is not limited thereto. For example, the execution order of the various operations may be appropriately adjusted, and other operations may be added or some operations may be removed. Those skilled in the art may make appropriate modifications based on the above description, and are not limited to the description of FIG15 above.

[0216] In some embodiments, as shown in FIG15 , the method may further include:

[0217] 1502. The mobile node sends, to the first donor-CU, address information indicating that the mobile node is anchored on the donor-DU of the third donor-CU.

[0218] In some embodiments, the mobile node sends first indication information to the first donor-CU, wherein the first indication information includes identification information related to the third donor-CU; wherein the identification information is used by the first donor-CU to send second indication information for indicating the context of traffic to the third donor-CU.

[0219] In some embodiments, the F1-U connection of the mobile node to the first donor-CU is handed over by using the address of the mobile node anchored on the donor-DU of the third donor-CU.

[0220] In some embodiments, the mobile node receives uplink return information of traffic sent by the first donor-CU.

[0221] In some embodiments, the first indication information is sent by the mobile node via an F1AP message.

[0222] In some embodiments, the F1AP message is a gNB-DU configuration update message, and the gNB configuration update message includes: address information of the mobile node anchored on the donor-DU of the third donor-CU and the first indication information.

[0223] In some embodiments, the F1AP message includes a target cell global identifier of the mobile IAB node or a global node identifier of a target host node.

[0224] In some embodiments, the F1AP message includes a migration reason, wherein the migration reason includes: the mobile node performs an inter-host handover, or the mobile node performs an inter-host radio link failure (RLF) recovery.

[0225] The above embodiments are merely exemplary of the present invention, but the present invention is not limited thereto. Appropriate modifications may be made based on the above embodiments. For example, the above embodiments may be used alone, or one or more of the above embodiments may be combined.

[0226] As can be seen from the above embodiment, the F1-C connection between the mobile node and the first donor-CU is switched to the target path by using the mobile node's address information anchored on the donor-DU of the third donor-CU. This supports the mobile node's mobility within the control area without causing service interruption, ensuring the mobile node's quality of service to user equipment.

[0227] Embodiments of the fifth aspect

[0228] The present embodiment provides a host device, and the contents common to the embodiments of aspects 1 to 4 are not repeated here. The device may be, for example, an IAB donor-CU in an IAB system (such as the first donor-CU in the embodiments of aspects 1 to 4), or may be one or more components, assemblies, or modules configured in the IAB donor-CU.

[0229] The host device is an F1-terminated donor-CU of the mobile node, the second donor-CU is a non-F1-terminated donor-CU before the mobile node migrates or recovers from a radio link failure (RLF), and the third donor-CU is a non-F1-terminated donor-CU after the mobile node migrates or recovers from an RLF.

[0230] FIG16 is a schematic diagram of a host device according to an embodiment of the present application. As shown in FIG16 , the host device 1600 includes:

[0231] A receiving unit 1601 receives first indication information, where the first indication information includes identification information related to the third donor-CU; and

[0232] The sending unit 1602 sends second indication information indicating the context of traffic to the third donor-CU.

[0233] In some embodiments, the host device is an F1 terminating donor-CU for multiple mobile nodes in a designated area; the F1 connections of the multiple mobile nodes always terminate at the host device.

[0234] In some embodiments, the receiving unit 1601 further receives address information sent by the mobile node, in which the mobile node is anchored on the donor-DU of the third donor-CU.

[0235] In some embodiments, the second indication information is sent by transmitting a migration management request message, and the second indication information includes downlink address information so that the third donor-CU configures or modifies downlink mapping;

[0236] The receiving unit 1601 also receives a transmission migration management response message sent by the third donor-CU, where the transmission migration management response message includes mapping information of the traffic to be offloaded and / or layer 2 information in the topology of the third donor-CU.

[0237] In some embodiments, the sending unit 1602 further sends uplink return information of traffic to the mobile node.

[0238] In some embodiments, the first indication information is sent by the second donor-CU by transmitting a migration modification request message;

[0239] The sending unit 1602 also sends a transmission migration modification response message to the second donor-CU.

[0240] In some embodiments, the transmission migration modification request message includes a target cell global identifier of the mobile node or a global node identifier of a target host node;

[0241] The target cell global identifier of the mobile node or the global node identifier of the target host node is included in the traffic released information element carried by the transport migration modification request message.

[0242] In some embodiments, the transport migration modification request message includes a traffic release reason;

[0243] The traffic release reason includes: the mobile node performs an inter-host handover, or the mobile node performs an inter-host radio link failure (RLF) recovery.

[0244] In some embodiments, the first indication information is sent by the second donor-CU via a migration notification message in an XnAP message;

[0245] The sending unit 1602 also sends a migration notification confirmation message to the second donor-CU.

[0246] In some embodiments, the relocation notification message includes a target cell global identifier of the mobile node or a global node identifier of a target host node.

[0247] In some embodiments, the migration notification message includes a traffic release reason;

[0248] The traffic release reason includes: the mobile node performs an inter-host handover, or the mobile node performs an inter-host radio link failure (RLF) recovery.

[0249] In some embodiments, the first indication information is sent by the mobile node via an F1AP message;

[0250] The F1AP message is a gNB-DU configuration update message, and the gNB configuration update message includes: address information of the mobile node anchored on the donor-DU of the third donor-CU and the first indication information.

[0251] In some embodiments, the F1AP message includes a migration reason;

[0252] The migration reason includes: the mobile node performs an inter-host handover, or the mobile node performs an inter-host radio link failure (RLF) recovery.

[0253] In some embodiments, the sending unit 1602 further requests the third donor-CU to release all offload traffic or release part of the offload traffic by transmitting a migration management request message.

[0254] The above embodiments are merely exemplary of the present invention, but the present invention is not limited thereto. Appropriate modifications may be made based on the above embodiments. For example, the above embodiments may be used alone, or one or more of the above embodiments may be combined.

[0255] It is worth noting that the above only describes the components or modules related to the present application, but the present application is not limited thereto. The host device 1600 of the embodiment of the present application may also include other components or modules. For the specific contents of these components or modules, reference may be made to the relevant art.

[0256] In addition, for the sake of simplicity, FIG16 only illustrates the connection relationship or signal direction between various components or modules. However, it should be clear to those skilled in the art that various related technologies such as bus connection can be used. The above-mentioned components or modules can be implemented by hardware facilities such as processors, memories, transmitters, and receivers; the implementation of this application is not limited to this.

[0257] As can be seen from the above embodiment, the first donor-CU receives first indication information including identification information related to the third donor-CU; and the first donor-CU sends second indication information indicating a traffic context to the third donor-CU based on the identification information. This allows the mobile node to move within the control area without causing service interruption, thereby ensuring the quality of service provided by the mobile node to the user equipment.

[0258] Embodiments of the sixth aspect

[0259] The present embodiment provides a host device, and the contents common to the embodiments of aspects 1 to 4 are not repeated here. The device may be, for example, an IAB donor-CU in an IAB system (such as the second donor-CU in the embodiments of aspects 1 to 4), or may be one or more components, assemblies, or modules configured in the IAB donor-CU.

[0260] The first donor-CU is the F1 termination donor-CU of the mobile node, the host device is the non-F1 termination donor-CU before the mobile node migrates or the radio link failure (RLF) is recovered, and the third donor-CU is the non-F1 termination donor-CU after the mobile node migrates or the RLF is recovered.

[0261] FIG17 is a schematic diagram of a host device according to an embodiment of the present application. As shown in FIG17 , the host device 1700 includes:

[0262] The sending unit 1701 sends first indication information to the first donor-CU, where the first indication information includes identification information related to the third donor-CU.

[0263] In some embodiments, the first indication information is sent by the second donor-CU by transmitting a migration modification request message; as shown in FIG17 , the host device 1700 may further include:

[0264] The receiving unit 1702 receives the transmission migration modification response message sent by the first donor-CU.

[0265] In some embodiments, the first indication information is sent by the second donor-CU via a migration notification message in an XnAP message; the receiving unit 1702 also receives a migration notification confirmation message sent by the first donor-CU.

[0266] The above embodiments are merely exemplary of the present invention, but the present invention is not limited thereto. Appropriate modifications may be made based on the above embodiments. For example, the above embodiments may be used alone, or one or more of the above embodiments may be combined.

[0267] It is worth noting that the above only describes the components or modules related to the present application, but the present application is not limited thereto. The host device 1700 of the embodiment of the present application may also include other components or modules. For the specific contents of these components or modules, reference may be made to the relevant art.

[0268] In addition, for the sake of simplicity, FIG17 only illustrates the connection relationship or signal direction between various components or modules. However, it should be clear to those skilled in the art that various related technologies such as bus connection can be used. The above-mentioned components or modules can be implemented by hardware facilities such as processors, memories, transmitters, and receivers; the implementation of this application is not limited to this.

[0269] As can be seen from the above embodiment, the second donor-CU sends first indication information to the first donor-CU, where the first indication information includes identification information related to the third donor-CU; wherein the identification information is used by the first donor-CU to send second indication information indicating a traffic context to the third donor-CU. This supports the movement of mobile nodes within the control area without causing service interruption, thereby ensuring the quality of service provided by the mobile nodes to user equipment.

[0270] Embodiments of the seventh aspect

[0271] The present embodiment provides a host device, and the contents common to the embodiments of aspects 1 to 4 are not repeated here. The device may be, for example, an IAB donor-CU in an IAB system (such as the third donor-CU in the embodiments of aspects 1 to 4), or may be one or more components, assemblies, or modules configured in the IAB donor-CU.

[0272] The first donor-CU is the F1 termination donor-CU of the mobile node, the second donor-CU is the non-F1 termination donor-CU before the mobile node migrates or the radio link failure (RLF) is recovered, and the host device is the non-F1 termination donor-CU after the mobile node migrates or the RLF is recovered.

[0273] FIG18 is a schematic diagram of a host device according to an embodiment of the present application. As shown in FIG18 , the host device 1800 includes:

[0274] A receiving unit 1801 receives second indication information for indicating a traffic context sent by the first donor-CU according to identification information;

[0275] The identification information is related to the third donor-CU and is included in the first indication information received by the first donor-CU.

[0276] In some embodiments, the second indication information is sent by transmitting a migration management request message. As shown in FIG18 , the host device 1800 may further include:

[0277] The processing unit 1802 configures or modifies the downlink mapping according to the downlink address information included in the second indication information.

[0278] In some embodiments, as shown in FIG18 , the host device 1800 may further include:

[0279] The sending unit 1803 sends a transmission migration management response message to the first donor-CU, where the transmission migration management response message includes mapping information of the traffic to be offloaded and / or layer 2 information in the topology of the third donor-CU.

[0280] The above embodiments are merely exemplary of the present invention, but the present invention is not limited thereto. Appropriate modifications may be made based on the above embodiments. For example, the above embodiments may be used alone, or one or more of the above embodiments may be combined.

[0281] It is worth noting that the above only describes the components or modules related to the present application, but the present application is not limited thereto. The host device 1800 of the embodiment of the present application may also include other components or modules. For the specific contents of these components or modules, reference may be made to the relevant art.

[0282] In addition, for the sake of simplicity, FIG18 only illustrates the connection relationship or signal direction between various components or modules. However, it should be clear to those skilled in the art that various related technologies such as bus connection can be used. The above-mentioned components or modules can be implemented by hardware facilities such as processors, memories, transmitters, and receivers; the implementation of this application is not limited to this.

[0283] As can be seen from the above embodiment, the third donor-CU receives second indication information indicating a traffic context sent by the first donor-CU based on identification information; wherein the identification information is related to the third donor-CU and includes the first indication information received by the first donor-CU. This supports the movement of mobile nodes within the control area without causing service interruption, thereby ensuring the quality of service provided by the mobile node to user equipment.

[0284] Embodiments of the eighth aspect

[0285] The present application provides a mobile node. The contents identical to those in the first to fourth aspects of the present application are not further described. The mobile node may be, for example, an IAB node in an IAB system (such as the mobile IAB node in the first to fourth aspects of the present application), or may be one or more components, assemblies, or modules configured in the IAB node.

[0286] FIG19 is a schematic diagram of a mobile node according to an embodiment of the present application. As shown in FIG19 , the mobile node 1900 includes a mobile terminal (MT) 1901 and a distributed unit (DU) 1902. The mobile terminal (MT) 1901 of the mobile node switches from the second donor-CU or recovers from RLF to the third donor-CU.

[0287] The F1-C connection between the distribution unit (DU) 1902 of the mobile node and the first donor-CU is switched to a target path by using the address information of the mobile node anchored on the donor-DU of the third donor-CU.

[0288] In some embodiments, the distribution unit (DU) 1902 of the mobile node sends address information of the mobile node anchored on the donor-DU of the third donor-CU to the first donor-CU.

[0289] In some embodiments, the distribution unit (DU) 1902 of the mobile node sends first indication information to the first donor-CU, where the first indication information includes identification information related to the third donor-CU.

[0290] In some embodiments, the F1-U connection of the mobile node's distribution unit (DU) 1902 to the first donor-CU is handed over using the mobile node's address anchored on the donor-DU of the third donor-CU.

[0291] In some embodiments, the distribution unit (DU) 1902 of the mobile node receives uplink return information of the traffic sent by the first donor-CU.

[0292] In some embodiments, the first indication information is sent by the mobile node via an F1AP message.

[0293] In some embodiments, the F1AP message is a gNB-DU configuration update message, and the gNB configuration update message includes: address information of the mobile node anchored on the donor-DU of the third donor-CU and the first indication information.

[0294] In some embodiments, the F1AP message includes a target cell global identifier of the mobile IAB node or a global node identifier of a target host node.

[0295] In some embodiments, the F1AP message includes a migration reason.

[0296] In some embodiments, the migration reason includes: the mobile node performing an inter-host handover, or the mobile node performing an inter-host radio link failure (RLF) recovery.

[0297] The above embodiments are merely exemplary of the present invention, but the present invention is not limited thereto. Appropriate modifications may be made based on the above embodiments. For example, the above embodiments may be used alone, or one or more of the above embodiments may be combined.

[0298] It is worth noting that the above only describes the components or modules related to the present application, but the present application is not limited thereto. The mobile node 1900 of the embodiment of the present application may also include other components or modules. For the specific contents of these components or modules, reference may be made to the relevant art.

[0299] In addition, for the sake of simplicity, FIG19 only illustrates the connection relationship or signal direction between various components or modules. However, it should be clear to those skilled in the art that various related technologies such as bus connection can be used. The above-mentioned components or modules can be implemented by hardware facilities such as processors, memories, transmitters, and receivers; the implementation of this application is not limited to this.

[0300] As can be seen from the above embodiment, the F1-C connection between the mobile node and the first donor-CU is switched to the target path by using the mobile node's address information anchored on the donor-DU of the third donor-CU. This supports the mobile node's mobility within the control area without causing service interruption, ensuring the quality of service provided by the mobile node to the user equipment.

[0301] Embodiments of the ninth aspect

[0302] An embodiment of the present application provides a communication system, including a donor device and a mobile node (eg, an IAB-node). For details about the network architecture and specific contents of the donor device and the IAB node, reference may be made to related technologies, which will be omitted here.

[0303] In some embodiments, the communication system includes: a first donor-CU, a second donor-CU, a third donor-CU, a donor-DU of each donor-CU, and a mobile node. Each donor-DU may implement operations corresponding to each donor-CU and mobile node. For details, please refer to related technologies and the description is omitted here.

[0304] The first donor-CU is the F1 termination donor-CU of the mobile node, the second donor-CU is the non-F1 termination donor-CU before the mobile node migrates or the radio link failure (RLF) is recovered, and the third donor-CU is the non-F1 termination donor-CU after the mobile node migrates or the RLF is recovered.

[0305] The first donor-CU receives first indication information including identification information related to the third donor-CU; and the first donor-CU sends second indication information for indicating a context of traffic to the third donor-CU.

[0306] The second donor-CU sends first indication information to the first donor-CU, where the first indication information includes identification information related to the third donor-CU.

[0307] The third donor-CU receives second indication information for indicating the context of traffic sent by the first donor-CU according to identification information; wherein the identification information is related to the third donor-CU and is included in the first indication information received by the first donor-CU.

[0308] The F1-C connection between the mobile node and the first donor-CU is switched to a target path by using address information of the mobile node anchored on the donor-DU of the third donor-CU.

[0309] An embodiment of the present application further provides an IAB device, which may be an IAB host device or an IAB node (a migration node or a child node).

[0310] Figure 20 is a schematic diagram of an IAB device according to an embodiment of the present application. As shown in Figure 20 , IAB device 2000 may include a processor (e.g., a central processing unit (CPU)) 2001 and a memory 2002 ; the memory 2002 is coupled to the processor 2001 . The memory 2002 may store various data and may also store an information processing program 2005 , which is executed under the control of the CPU 2001 .

[0311] For example, the processor 2001 may be configured to execute a program to implement the communication method of the network node in the embodiment of the first aspect. For example, the processor 2001 may be configured to perform the following control: receiving first indication information including identification information related to a third donor-CU; and sending second indication information indicating a traffic context to the third donor-CU.

[0312] For another example, the processor 2001 may be configured to execute a program to implement the communication method of the network node in the embodiment of the second aspect. For example, the processor 2001 may be configured to perform the following control: sending first indication information to the first donor-CU, where the first indication information includes identification information related to the third donor-CU.

[0313] For another example, the processor 2001 may be configured to execute a program to implement the communication method of the network node in the embodiment of the third aspect. For example, the processor 2001 may be configured to perform the following control: receiving second indication information for indicating a traffic context sent by the first donor-CU based on identification information; wherein the identification information is related to the third donor-CU and included in the first indication information received by the first donor-CU.

[0314] For another example, the processor 2001 may be configured to execute a program to implement the communication method for the mobile node in the embodiment of the fourth aspect. For example, the processor 2001 may be configured to perform the following control: the F1-C connection between the mobile node and the first donor-CU is switched to the target path by using the address information of the mobile node anchored on the donor-DU of the third donor-CU.

[0315] Furthermore, as shown in FIG20 , IAB device 2000 may further include a transceiver 2003 and an antenna 2004. The functions of these components are similar to those in the prior art and are not further described here. It is worth noting that IAB device 2000 does not necessarily include all of the components shown in FIG20 . Furthermore, IAB device 2000 may also include components not shown in FIG20 , for which reference may be made to the prior art.

[0316] An embodiment of the present application also provides a computer-readable program, wherein when the program is executed in an IAB device, the program causes a computer to execute the communication method of the network node of the embodiments of the first to third aspects or the communication method of the mobile node of the embodiment of the fourth aspect in the IAB device.

[0317] An embodiment of the present application also provides a storage medium storing a computer-readable program, wherein the computer-readable program enables a computer to execute the communication method of the network node of the embodiments of the first to third aspects or the communication method of the mobile node of the embodiment of the fourth aspect in an IAB device.

[0318] The above devices and methods of the present application can be implemented by hardware or by a combination of hardware and software. The present application relates to such a computer-readable program that, when executed by a logic component, enables the logic component to implement the devices or components described above, or enables the logic component to implement the various methods or steps described above. The logic component is, for example, a field programmable logic component, a microprocessor, a processor used in a computer, etc. The present application also relates to a storage medium for storing the above program, such as a hard disk, a magnetic disk, an optical disk, a DVD, a flash memory, etc.

[0319] The method / device described in conjunction with the embodiments of the present application can be directly embodied as hardware, a software module executed by a processor, or a combination of the two. For example, one or more of the functional block diagrams shown in the figure and / or one or more combinations of functional block diagrams can correspond to various software modules of the computer program flow or to various hardware modules. These software modules can respectively correspond to the various steps shown in the figure. These hardware modules can be implemented by solidifying these software modules, for example, using a field programmable gate array (FPGA).

[0320] The software module may be located in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. A storage medium may be coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium; or the storage medium may be an integral part of the processor. The processor and the storage medium may be located in an ASIC. The software module may be stored in the memory of the mobile terminal or in a memory card that can be inserted into the mobile terminal. For example, if the device (such as a mobile terminal) uses a large-capacity MEGA-SIM card or a large-capacity flash memory device, the software module may be stored in the MEGA-SIM card or the large-capacity flash memory device.

[0321] One or more of the functional blocks and / or one or more combinations of functional blocks described in the accompanying drawings may be implemented as a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, or any appropriate combination thereof for performing the functions described in this application. One or more of the functional blocks and / or one or more combinations of functional blocks described in the accompanying drawings may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in communication with a DSP, or any other such configuration.

[0322] The present application has been described above in conjunction with specific embodiments. However, those skilled in the art should understand that these descriptions are merely illustrative and are not intended to limit the scope of protection of the present application. Those skilled in the art may make various modifications and variations to the present application based on the spirit and principles of the present application, and such modifications and variations are also within the scope of the present application.

[0323] Regarding the above implementation methods disclosed in this embodiment, the following additional notes are also disclosed:

[0324] 1. A communication method for a network node, wherein a first donor-CU is an F1-terminated donor-CU of a mobile node, a second donor-CU is a non-F1-terminated donor-CU of the mobile node before migration or radio link failure (RLF) recovery, and a third donor-CU is a non-F1-terminated donor-CU of the mobile node after migration or RLF recovery;

[0325] The method comprises:

[0326] The first donor-CU receives first indication information, where the first indication information includes identification information related to the third donor-CU; and

[0327] The first donor-CU sends second indication information for indicating a context of traffic to the third donor-CU.

[0328] 2. The method according to Note 1, wherein the first donor-CU is an F1 termination donor-CU for multiple mobile nodes in a specified area; the F1 connections of the multiple mobile nodes always terminate at the first donor-CU.

[0329] 3. The method according to Note 1 or 2, wherein the method further comprises:

[0330] The first donor-CU receives address information sent by the mobile node, in which the mobile node is anchored on the donor-DU of the third donor-CU.

[0331] 4. The method according to any one of Notes 1 to 3, wherein the second indication information is sent by transmitting a migration management request message, and the second indication information includes downlink address information so that the third donor-CU configures or modifies the downlink mapping.

[0332] 5. The method according to Supplement 4, wherein the method further comprises:

[0333] The first donor-CU receives a transmission migration management response message sent by the third donor-CU, where the transmission migration management response message includes mapping information of the traffic to be offloaded and / or layer 2 information in the topology of the third donor-CU.

[0334] 6. The method according to any one of Notes 1 to 5, wherein the method further comprises:

[0335] The first donor-CU sends uplink backhaul information of traffic to the mobile node.

[0336] 7. The method according to any one of Notes 1 to 6, wherein the first indication information is sent by the second donor-CU by transmitting a migration modification request message; the method further comprising:

[0337] The first donor-CU sends a transmission migration modification response message to the second donor-CU.

[0338] 8. The method according to Note 7, wherein the transmission migration modification request message includes the target cell global identifier of the mobile node or the global node identifier of the target host node.

[0339] 9. The method according to Note 8, wherein the target cell global identifier of the mobile node or the global node identifier of the target host node is included in the traffic released information element carried by the transmission migration modification request message.

[0340] 10. The method according to any one of Notes 7 to 9, wherein the transmission migration modification request message includes a traffic release reason.

[0341] 11. The method according to Note 10, wherein the reason for the traffic release includes: the mobile node performs an inter-host handover, or the mobile node performs an inter-host radio link failure (RLF) recovery.

[0342] 12. The method according to any one of Notes 1 to 6, wherein the first indication information is sent by the second donor-CU via a migration notification message in an XnAP message.

[0343] 13. The method according to Supplementary Note 12, further comprising:

[0344] The first donor-CU sends a migration notification confirmation message to the second donor-CU.

[0345] 14. The method according to Note 12 or 13, wherein the migration notification message includes the target cell global identifier of the mobile node or the global node identifier of the target host node.

[0346] 15. The method according to any one of Notes 12 to 14, wherein the migration notification message includes a migration reason.

[0347] 16. The method according to Note 15, wherein the migration reason includes: the mobile node performing an inter-host handover, or the mobile node performing an inter-host radio link failure (RLF) recovery.

[0348] 17. The method according to any one of Notes 1 to 6, wherein the first indication information is sent by the mobile node via an F1AP message.

[0349] 18. The method according to Note 17, wherein the F1AP message is a gNB-DU configuration update message, and the gNB configuration update message includes: address information of the mobile node anchored on the donor-DU of the third donor-CU and the first indication information.

[0350] 19. The method according to Note 17 or 18, wherein the F1AP message includes the target cell global identifier of the mobile IAB node or the global node identifier of the target host node.

[0351] 20. The method according to any one of Notes 17 to 19, wherein the F1AP message includes a migration reason.

[0352] 21. The method according to Note 20, wherein the migration reason includes: the mobile node performing an inter-host handover, or the mobile node performing an inter-host radio link failure (RLF) recovery.

[0353] 22. The method according to any one of Notes 1 to 21, wherein the method further comprises:

[0354] The first donor-CU requests the third donor-CU to release all offload traffic or release part of the offload traffic by transmitting a migration management request message.

[0355] 23. A communication method for a network node, wherein a first donor-CU is an F1-terminated donor-CU of a mobile node, a second donor-CU is a non-F1-terminated donor-CU of the mobile node before migration or radio link failure (RLF) recovery, and a third donor-CU is a non-F1-terminated donor-CU of the mobile node after migration or RLF recovery;

[0356] The method comprises:

[0357] The third donor-CU receives second indication information for indicating a traffic context sent by the first donor-CU according to the identification information;

[0358] The identification information is related to the third donor-CU and is included in the first indication information received by the first donor-CU.

[0359] 24. The method according to supplementary note 23, wherein the second indication information is sent by transmitting a migration management request message, the method further comprising:

[0360] The third donor-CU configures or modifies downlink mapping according to the downlink address information included in the second indication information.

[0361] 25. The method according to Supplementary Note 24, further comprising:

[0362] The third donor-CU sends a transport migration management response message to the first donor-CU, where the transport migration management response message includes mapping information of the traffic to be offloaded and / or layer 2 information in the topology of the third donor-CU.

[0363] 26. The method according to any one of Notes 23 to 25, wherein the method further comprises:

[0364] The third donor-CU initiates traffic fallback for the mobile terminal (MT) of the mobile node to switch to the first donor-CU.

[0365] 27. The method according to Note 26, wherein, when the mobile terminal of the mobile node switches to the first donor-CU, the traffic of the distribution unit (DU) of the mobile node is routed through the topology of the first donor-CU.

[0366] 28. The method according to any one of Notes 23 to 25, further comprising:

[0367] The third donor-CU initiates traffic fallback for the mobile terminal of the mobile node to switch to the second donor-CU.

[0368] 29. The method according to Note 28, wherein, when the mobile terminal of the mobile node switches to the second donor-CU, the traffic of the distribution unit of the mobile node is routed through the topology of the second donor-CU.

[0369] 30. A communication method for a network node, wherein a first donor-CU is an F1-terminated donor-CU of a mobile node, a second donor-CU is a non-F1-terminated donor-CU of the mobile node before migration or radio link failure (RLF) recovery, and a third donor-CU is a non-F1-terminated donor-CU of the mobile node after migration or RLF recovery;

[0370] The method comprises:

[0371] The second donor-CU sends first indication information to the first donor-CU, where the first indication information includes identification information related to the third donor-CU;

[0372] The identification information is used by the first donor-CU to send second indication information for indicating the context of traffic to the third donor-CU.

[0373] 31. The method according to supplementary note 30, wherein the first indication information is sent by the second donor-CU by transmitting a migration modification request message; the method further comprising:

[0374] The second donor-CU receives the transmission migration modification response message sent by the first donor-CU.

[0375] 32. The method according to Note 31, wherein the transmission migration modification request message includes the target cell global identifier of the mobile node or the global node identifier of the target host node.

[0376] 33. A method according to Note 32, wherein the target cell global identifier of the mobile node or the global node identifier of the target host node is included in the traffic released information element carried by the transmission migration modification request message.

[0377] 34. A method according to any one of Notes 31 to 33, wherein the transmission migration modification request message includes a traffic release reason.

[0378] 35. The method according to Note 34, wherein the reason for the traffic release includes: the mobile node performs an inter-host handover, or the mobile node performs an inter-host radio link failure (RLF) recovery.

[0379] 36. The method according to Note 30, wherein the first indication information is sent by the second donor-CU via a migration notification message in an XnAP message.

[0380] 37. The method according to Supplementary Note 36, further comprising:

[0381] The second donor-CU receives the migration notification confirmation message sent by the first donor-CU.

[0382] 38. The method according to Note 36 or 37, wherein the migration notification message includes the target cell global identifier of the mobile node or the global node identifier of the target host node.

[0383] 39. The method according to any one of Notes 36 to 38, wherein the migration notification message includes a migration reason.

[0384] 40. The method according to Note 39, wherein the migration reason includes: the mobile node performing an inter-host handover, or the mobile node performing an inter-host radio link failure (RLF) recovery.

[0385] 41. A communication method for a mobile node, wherein a first donor-CU is an F1-terminated donor-CU of the mobile node, a second donor-CU is a non-F1-terminated donor-CU of the mobile node before migration or radio link failure (RLF) recovery, and a third donor-CU is a non-F1-terminated donor-CU of the mobile node after migration or RLF recovery;

[0386] The method comprises:

[0387] The F1-C connection between the mobile node and the first donor-CU is switched to a target path by using address information of the mobile node anchored on the donor-DU of the third donor-CU.

[0388] 42. The method according to Supplement 41, wherein the method further comprises:

[0389] The mobile node sends address information of the mobile node anchored on the donor-DU of the third donor-CU to the first donor-CU.

[0390] 43. The method according to Note 41 or 42, wherein the method further comprises:

[0391] The mobile node sends first indication information to the first donor-CU, where the first indication information includes identification information related to the third donor-CU;

[0392] The identification information is used by the first donor-CU to send second indication information for indicating the context of traffic to the third donor-CU.

[0393] 44. The method according to any one of Notes 41 to 43, wherein the method further comprises:

[0394] The F1-U connection of the mobile node to the first donor-CU is handed over by using the address of the mobile node anchored on the donor-DU of the third donor-CU.

[0395] 45. The method according to any one of Notes 41 to 44, wherein the method further comprises:

[0396] The mobile node receives uplink return information of the traffic sent by the first donor-CU.

[0397] 46. ​​The method according to Note 43, wherein the first indication information is sent by the mobile node via an F1AP message.

[0398] 47. The method according to Note 46, wherein the F1AP message is a gNB-DU configuration update message, and the gNB configuration update message includes: address information of the mobile node anchored on the donor-DU of the third donor-CU and the first indication information.

[0399] 48. The method according to Note 46 or 47, wherein the F1AP message includes the target cell global identifier of the mobile IAB node or the global node identifier of the target host node.

[0400] 49. A method according to any one of Notes 46 to 48, wherein the F1AP message includes a migration reason.

[0401] 50. The method according to Note 49, wherein the migration reason includes: the mobile node performing an inter-host handover, or the mobile node performing an inter-host radio link failure (RLF) recovery.

[0402] 51. A mobile node comprising a memory and a processor, wherein the memory stores a computer program, wherein the processor is configured to execute the computer program to implement the communication method of the mobile node as described in any one of Notes 41 to 50.

[0403] 52. A donor device comprising a memory and a processor, wherein the memory stores a computer program, wherein the processor is configured to execute the computer program to implement the communication method of the network node as described in any one of Notes 1 to 40.

[0404] 53. A communication system comprising: a first donor-CU, a second donor-CU, a third donor-CU, and a mobile node; the first donor-CU is an F1-terminating donor-CU of the mobile node, the second donor-CU is a non-F1-terminating donor-CU of the mobile node before migration or radio link failure (RLF) recovery, and the third donor-CU is a non-F1-terminating donor-CU of the mobile node after migration or RLF recovery;

[0405] The first donor-CU receives first indication information, where the first indication information includes identification information related to the third donor-CU; and the first donor-CU sends second indication information for indicating a traffic context to the third donor-CU;

[0406] The second donor-CU sends first indication information to the first donor-CU, where the first indication information includes identification information related to the third donor-CU;

[0407] The third donor-CU receives second indication information for indicating a traffic context sent by the first donor-CU according to the identification information; wherein the identification information is related to the third donor-CU and includes the first indication information received by the first donor-CU;

[0408] The F1-C connection between the mobile node and the first donor-CU is switched to a target path by using address information of the mobile node anchored on the donor-DU of the third donor-CU.

Claims

1. A host device, wherein: The host device is an F1-terminated donor-CU of the mobile node, the second donor-CU is a non-F1-terminated donor-CU before the mobile node migrates or the radio link fails and recovers, and the third donor-CU is a non-F1-terminated donor-CU after the mobile node migrates or the radio link fails and recovers; The host device includes: a receiving unit configured to receive first indication information, wherein the first indication information includes identification information related to the third donor-CU; and A sending unit sends second indication information for indicating the context of traffic to the third donor-CU.

2. The host device according to claim 1, wherein: The host device is an F1 terminating donor-CU for multiple mobile nodes in a designated area; the F1 connections of the multiple mobile nodes always terminate at the host device.

3. The host device according to claim 1, wherein: The receiving unit further receives address information sent by the mobile node, in which the mobile node is anchored on the donor-DU of the third donor-CU.

4. The host device according to claim 1, wherein: The second indication information is sent by transmitting a migration management request message, and the second indication information includes downlink address information so that the third donor-CU configures or modifies downlink mapping; The receiving unit also receives a transmission migration management response message sent by the third donor-CU, where the transmission migration management response message includes mapping information of the traffic to be offloaded and / or layer 2 information in the topology of the third donor-CU.

5. The host device according to claim 1, wherein: The sending unit further sends uplink return information of traffic to the mobile node. The host device according to claim 1 , wherein: The first indication information is sent by the second donor-CU by transmitting a migration modification request message; The sending unit also sends a transmission migration modification response message to the second donor-CU.

7. The host device according to claim 6, wherein: The transmission migration modification request message includes the target cell global identifier of the mobile node or the global node identifier of the target host node; The target cell global identifier of the mobile node or the global node identifier of the target host node is included in the traffic released information element carried by the transport migration modification request message.

8. The host device according to claim 6, wherein: The transmission migration modification request message includes a traffic release reason; The traffic release reason includes: the mobile node performs an inter-host handover, or the mobile node performs an inter-host radio link failure recovery.

9. The host device according to claim 1, wherein: The first indication information is sent by the second donor-CU through a migration notification message in an XnAP message.

10. The host device according to claim 9, wherein: The relocation notification message includes the global identifier of the target cell of the mobile node or the global node identifier of the target host node.

11. The host device according to claim 9, wherein: The migration notification message includes a migration reason; The migration reason includes: the mobile node performs an inter-host handover, or the mobile node performs an inter-host radio link failure recovery.

12. The host device according to claim 1, wherein: The first indication information is sent by the mobile node through an F1AP message; the F1AP message is a gNB-DU configuration update message.

13. The host device according to claim 12, wherein: The F1AP message includes the migration reason; The migration reason includes: the mobile node performs an inter-host handover, or the mobile node performs an inter-host radio link failure recovery.

14. The host device according to claim 1, wherein: The sending unit further requests the third donor-CU to release all offload traffic or release part of the offload traffic by transmitting a migration management request message.

15. A host device, wherein: The first donor-CU is an F1-terminated donor-CU of the mobile node, the host device is a non-F1-terminated donor-CU before the mobile node migrates or the radio link fails and recovers, and the third donor-CU is a non-F1-terminated donor-CU after the mobile node migrates or the radio link fails and recovers; The host device includes: A sending unit sends first indication information to the first donor-CU, where the first indication information includes identification information related to the third donor-CU.

16. The host device according to claim 15, wherein: The first indication information is sent by the host device by transmitting a migration modification request message; the host device further includes: A receiving unit receives a transmission migration modification response message sent by the first donor-CU.

17. The host device according to claim 15, wherein: The first indication information is sent by the host device through a migration notification message in an XnAP message; The host device further includes: A receiving unit receives a migration notification confirmation message sent by the first donor-CU.

18. A host device, wherein: The first donor-CU is an F1-terminated donor-CU of the mobile node, the second donor-CU is a non-F1-terminated donor-CU before the mobile node migrates or the radio link fails and recovers, and the host device is a non-F1-terminated donor-CU after the mobile node migrates or the radio link fails and recovers; The host device includes: a receiving unit configured to receive second indication information for indicating a traffic context sent by the first donor-CU according to the identification information; The identification information is related to the host device and is included in the first indication information received by the first donor-CU.

19. The host device according to claim 18, wherein: The second indication information is sent by transmitting a migration management request message, and the host device further includes: A processing unit configured or modified downlink mapping according to the downlink address information included in the second indication information.

20. The host device according to claim 19, wherein: The host device further includes: A sending unit sends a transport migration management response message to the first donor-CU, where the transport migration management response message includes mapping information of the traffic to be offloaded and / or layer 2 information in the topology of the host device.

Images