Device, method, apparatus and computer-readable medium for IAB communication

Abstract

Embodiments of the present disclosure relate to devices, methods, apparatuses, and computer-readable media for communication during topology adaptation between donors. A first device sends first information about a first communication interface between a first device and a third device to a second device, receives an indication from the second device to retain context information associated with at least one fourth device and the first communication interface, and uses the context information in communication via the second communication interface between the first device and the second device. The second device receives the first information, sends a request to obtain the context information to a third device, and receives the context information from the third device. In this way, the reconstruction process can be simplified, and signaling on the Xn interface, the F1 interface, and the wireless backhaul can be minimized. In addition, service interruption and latency for terminal devices when the IAB donor changes can be reduced.

Description

Technical Field

[0001] Embodiments of the present disclosure generally relate to the field of telecommunications, and more particularly to devices, methods, apparatuses, and computer-readable media for communication during inter-donor topology adaptation and / or inter-donor mobility. Background Art

[0002] Integrated Access and Backhaul (IAB) enables wireless relay of NR access by using New Radio (NR) for backhaul. The relay node is called an IAB node. The terminating node of the NR backhaul on the network side is called an IAB donor. An IAB donor represents a gNB with additional functionality to support IAB. The backhaul can occur via a single hop of an IAB node or multiple hops of an IAB node.

[0003] In some scenarios, the IAB node may change its attachment point from a source IAB donor to a target IAB donor that is different from the source IAB donor. This topology adaptation may be referred to as inter-donor topology adaptation. For example, in the case where the IAB donor is a mobile IAB node, the change of the IAB donor may also be referred to as inter-donor mobility. The mobile IAB node may be implemented on a vehicle such as a bus. The process for inter-donor topology adaptation may involve: removing the F1 application protocol (F1AP) context of the terminal device connected to the IAB node during the establishment of the F1 interface between the IAB node and the target IAB donor, and then rebuilding the F1AP context between the IAB node and the target IAB donor when the terminal device performs a radio resource control (RRC) reconstruction process. This may affect all child (or descendant) IAB nodes of the IAB node and all terminal devices connected to the child IAB nodes. Therefore, it is necessary to discuss how to manage the FIAP context for the terminal device. Summary of the invention

[0004] In general, example embodiments of the present disclosure provide a scheme for communication during inter-donor topology adaptation.

[0005] In a first aspect, a first device is provided. The first device includes: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code are configured to, together with the at least one processor, cause the first device to: send first information about a first communication interface between the first device and a third device to a second device at the first device; receive from the second device an indication to retain context information associated with at least one fourth device and the first communication interface; and use the context information in communication via a second communication interface between the first device and the second device.

[0006] In a second aspect, a second device is provided. The second device includes: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code are configured to, together with the at least one processor, cause the second device to: receive first information about a first communication interface between a first device and a third device at the second device; send a request to the third device for obtaining context information associated with at least one fourth device and the first communication interface based on the first information; and receive the context information from the third device for communication via a second communication interface between the first device and the second device.

[0007] In a third aspect, a third device is provided. A second device comprises: at least one processor; and at least one memory comprising computer program code; the at least one memory and the computer program code are configured to, together with the at least one processor, cause the third device to: receive, at the third device, a request from the second device to obtain context information, the context information being associated with at least one fourth device and a first communication interface between the first device and the third device; and send the context information to the second device.

[0008] In a fourth aspect, a method implemented at a device is provided. The method includes: sending, at a first device, first information about a first communication interface between the first device and a third device to a second device; receiving from the second device an indication to retain context information associated with at least one fourth device and the first communication interface; and using the context information in communication via a second communication interface between the first device and the second device.

[0009] In a fifth aspect, a method implemented at a device is provided. The method includes: receiving, at the second device, first information about a first communication interface between a first device and a third device; sending, based on the first information, a request to the third device for obtaining context information associated with at least one fourth device and the first communication interface; and receiving the context information from the third device for communication via a second communication interface between the first device and the second device.

[0010] In a sixth aspect, a method implemented at a device is provided. The method includes: receiving, at a third device, a request from a second device to obtain context information, the context information being associated with at least one fourth device and a first communication interface between the first device and the third device; and sending the context information to the second device.

[0011] In a seventh aspect, a device is provided, comprising: a component for sending, at the first device, first information about a first communication interface between the first device and a third device to a second device; a component for receiving, from the second device, an indication to retain context information associated with at least one fourth device and the first communication interface; and a component for using the context information in communication via the second communication interface between the first device and the second device.

[0012] In an eighth aspect, a device is provided, comprising: a component for receiving first information about a first communication interface between a first device and a third device at a second device; a component for sending, based on the first information, a message for obtaining context information to the third device, the context information being associated with at least one fourth device and the first communication interface; and a component for receiving the context information from the third device for communication via a second communication interface between the first device and the second device.

[0013] In a ninth aspect, a device is provided, comprising: a component for receiving, at a third device, a request for obtaining context information from a second device, wherein the context information is associated with at least one fourth device and a first communication interface between the first device and the third device; and a component for sending the context information to the second device.

[0014] In a tenth aspect, a computer-readable medium comprising a computer program is provided, wherein the computer program is used to cause an apparatus to at least execute the method according to the fourth aspect above.

[0015] In an eleventh aspect, a computer-readable medium comprising a computer program is provided, wherein the computer program is used to cause an apparatus to at least execute the method according to the fifth aspect above.

[0016] In a twelfth aspect, a computer-readable medium comprising a computer program is provided, wherein the computer program is used to cause an apparatus to at least execute the method according to the sixth aspect above.

[0017] It should be understood that the invention summary is not intended to identify the key or essential features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Some example embodiments will now be described with reference to the accompanying drawings, in which:

[0019] Figure 1 shows an example communication network in which embodiments of the present disclosure may be implemented;

[0020] Figure 2shows a signaling diagram illustrating a communication process during inter-donor topology adaptation according to some example embodiments of the present disclosure;

[0021] Figure 3 A signaling diagram illustrating a communication process during an inter-donor topology according to some other example embodiments of the present disclosure;

[0022] Figure 4 shows a signaling diagram illustrating a communication process during an inter-donor topology according to some other example embodiments of the present disclosure;

[0023] Figure 5 A flowchart showing a method implemented at a first device according to some example embodiments of the present disclosure is shown;

[0024] Figure 6 A flowchart showing a method implemented at a second device according to some example embodiments of the present disclosure is shown;

[0025] Figure 7 A flowchart of a method implemented at a third device according to some example embodiments of the present disclosure is shown;

[0026] Figure 8 shows a simplified block diagram of an apparatus suitable for implementing some other embodiments of the present disclosure; and

[0027] Fig. 9 A block diagram of an example computer-readable medium according to some example embodiments of the present disclosure is shown.

[0028] Throughout the drawings, the same or similar reference numerals refer to the same or similar elements. DETAILED DESCRIPTION

[0029] The principles of the present disclosure will now be described with reference to some example embodiments. It should be understood that these embodiments are described for illustrative purposes only and to help those skilled in the art understand and implement the present disclosure without implying any limitation on the scope of the present disclosure. The disclosure described herein can be implemented in various ways different from the ways described below.

[0030] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs.

[0031] References in the specification to "one embodiment," "an embodiment," "an example embodiment," etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment necessarily includes the particular feature, structure, or characteristic. Furthermore, these terms do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an example embodiment, it should be understood that it is within the knowledge of those skilled in the art to affect the feature, structure, or characteristic in conjunction with other embodiments, whether or not explicitly described.

[0032] It should be understood that although the terms "first" and "second" etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, without departing from the scope of the exemplary embodiments, the first element may be referred to as the second element, and similarly, the second element may be referred to as the first element. As used herein, the term "and / or" includes any and all combinations of one or more of the listed items.

[0033] The terms used herein are only used for the purpose of describing specific embodiments and are not intended to limit the exemplary embodiments. As used herein, the singular forms "a", "an" and "the" are also intended to include the plural forms unless the context clearly indicates otherwise. It will be further understood that the terms "include", "comprise", "have", "have", "contain" and / or "including" when used herein indicate the presence of the features, elements and / or components, etc., but do not exclude the presence or addition of one or more other features, elements, components and / or combinations thereof.

[0034] As used in this application, the term "circuitry" may refer to one or more or all of the following:

[0035] (a) hardware circuit implementation only (e.g., implementation only in analog and / or digital circuits) and

[0036] (b) a combination of hardware circuitry and software, such as (where applicable):

[0037] (i) a combination of analog and / or digital hardware circuitry and software / firmware, and

[0038] (ii) any portion of a hardware processor with software (including a digital signal processor, software and memory that work together to enable a device such as a mobile phone or server to perform various functions), and

[0039] (c) Hardware circuits and / or processors, such as a microprocessor or portion of a microprocessor, whose operation requires software (such as firmware), but the software may not be present when the operation does not require the software.

[0040] This definition of circuitry applies to all uses of the term in this application, including in any claims. As another example, as used in this application, the term circuitry also covers merely a hardware circuit or processor (or multiple processors) or a portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware implementation. For example, the term circuitry also covers a baseband integrated circuit or processor integrated circuit for a mobile device or similar integrated circuit in a server, cellular network device, or other computing or network device, if applicable to the particular claim element.

[0041] As used herein, the term "communication network" refers to a network that complies with any suitable communication standard, such as a fifth generation (5G) system, long term evolution (LTE), LTE advanced (LTE-A), wideband code division multiple access (WCDMA), high speed packet access (HSPA), narrowband Internet of Things (NB-IoT), etc. In addition, the communication between the terminal equipment and the network equipment in the communication network can be performed according to any suitable generation of communication protocols, including but not limited to the first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), fourth generation (4G), 4.5G, future fifth generation (5G) new radio (NR) communication protocol and / or any other protocol currently known or to be developed in the future. The embodiments of the present disclosure can be applied to various communication systems. In view of the rapid development of communication, there will certainly be future types of communication technologies and systems that can implement the present disclosure. The scope of the present disclosure should not be considered to be limited to the above-mentioned systems.

[0042] As used herein, the term "network equipment" refers to a node in a communication network through which a terminal device accesses the network and receives services therefrom. Depending on the terminology and technology applied, a network equipment may refer to a base station (BS) or access point (AP) such as a NodeB (NodeB or NB), an evolved NodeB (eNodeB or eNB), a NR next-generation NodeB (gNB), a remote radio unit (RRU), a radio head (RH), a remote radio head (RRH), a relay, a low-power node such as a femto node, a pico node, etc. The radio access network (RAN) split architecture includes: a gNB centralized unit (gNB CU), which hosts the radio resource control (RRC), the service data adaptation protocol (SDAP); and a packet data convergence protocol (PDCP), which controls multiple gNB distributed units (gNB-DUs), hosts the radio link control (RLC), the media access control (MAC) and the physical layer (PHY).

[0043] The term "terminal device" refers to any terminal device capable of wireless communication. As an example and not limitation, the terminal device may also be referred to as a communication device, user equipment (UE), user station (SS), portable user station, mobile station (MS) or access terminal (AT). The terminal device may include, but is not limited to, a mobile phone, a cellular phone, a smart phone, a voice over IP (VoIP) phone, a wireless local loop phone, a tablet computer, a wearable terminal device, a personal digital assistant (PDA), a portable computer, a desktop computer, an image capture terminal device such as a digital camera, a game terminal device, a music storage and playback device, a vehicle-mounted wireless terminal device, a wireless terminal, a mobile station, a laptop embedded device (LEE), a laptop embedded device (LME), a USB dongle, a smart device, a wireless customer premises equipment (CPE), an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical equipment and applications (such as remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices running in industrial and / or automated processing chain environments), consumer electronic devices, devices running on commercial and / or industrial wireless networks, etc. In the following description, the terms "terminal device", "communication device", "terminal", "user equipment" and "UE" may be used interchangeably.

[0044] While in various example embodiments, the functions described herein may be performed in fixed and / or wireless network nodes, in other example embodiments, the functions may be implemented in a user equipment device (e.g., a mobile phone or tablet or laptop or desktop computer or mobile IoT device or fixed IoT device). For example, the user equipment device may be appropriately equipped with corresponding capabilities as described in conjunction with fixed and / or wireless network nodes. The user equipment device may be a user device and / or a control device, such as a chipset or processor, configured to control the user device when installed in the user device. Examples of such functions include boot server functions and / or home subscriber servers, which may be implemented in the user equipment device by providing software to the user equipment device (configured to cause the user equipment device to execute from the perspective of these functions / nodes).

[0045] In the IAB network architecture, the IAB node supports the gNB distributed unit (DU) function to terminate the NR access interface to the terminal device and the child IAB node, and supports the F1 interface to the gNB centralized unit (CU) on the IAB donor. The IAB node also supports the NR Uu radio interface, known as the mobile terminal (MT) function, to connect to the DU of another IAB node or the IAB donor, and to the gNB-CU on the IAB donor via RRC.

[0046] In some scenarios, an IAB node may need to change its serving node or parent node (which may be under the same or different donor), for example due to a possible failure on the backhaul (BH) connection or a change in the IAB topology or movement of an IAB node. In the latter case, the IAB node may change its attachment point from the source IAB donor to a target IAB donor that is different from the source IAB donor. This topology adaptation may be referred to as inter-donor topology adaptation. An IAB node that changes its attachment point is referred to as a migrated IAB node.

[0047] Conventionally, in the process for inter-donor topology adaptation, the migrating IAB node needs to establish an F1 interface with the target IAB donor. During the setup or establishment of the F1 interface, the context of the terminal device (including the sub-IAB-MT) connected to the migrating IAB node will be removed. Then, for example, when the terminal device performs an RRC connection reconstruction or recovery process, the context for the terminal device (including the sub-IAB-MT) will be reestablished in the migrating IAB node and the target IAB donor.

[0048] In this case, all terminal devices connected to the migration IAB node will be affected. When the context is removed, the service of the terminal device is interrupted, and when the context is rebuilt, the service of the terminal device can be restored. The complete context of all terminal devices needs to be transmitted on the BH radio link control (RLC) channel between the migration IAB node and the target IAB donor. In addition, all sub-IAB nodes will also be affected. For example, the BH RLC channel between the migration IAB node and the sub-IAB node needs to be released and rebuilt. This also affects all terminal devices connected to the sub-IAB node because the context of the terminal device will be deleted and rebuilt when the DU in the sub-IAB node sets the F1 interface with the target IAB donor.

[0049] Considering the fact that the same physical IAB node (i.e., the migration IAB node and the child IAB node) serves the terminal device before and after the inter-donor topology adaptation, i.e., the IAB node of the terminal device is static relative to the serving terminal device, a more effective solution is needed to manage the contexts in the affected IAB nodes (i.e., the migration IAB node and its child IAB nodes) and the target IAB donor.

[0050] In order to at least partially solve the above and other potential problems, an example embodiment of the present disclosure provides a scheme for communicating during topology adaptation between donors. In this scheme, the context information of the terminal device associated with the communication interface between the affected IAB node (i.e., the migration IAB node and the sub-IAB node) and the source IAB donor is reused for communication via the communication interface between the affected IAB node (i.e., the migration IAB node and the sub-IAB node) and the target IAB donor. In this way, the reconstruction process of the terminal device using the communication interface between the affected IAB node (i.e., the migration IAB node and the sub-IAB node) and the target IAB donor can be simplified, and the signaling on the Xn interface, the F1 interface and the wireless backhaul can be minimized. In addition, service interruption and latency for the terminal device can be reduced when the IAB donor changes.

[0051] Figure 1 An example communication network 100 is shown in which embodiments of the present disclosure may be implemented. The communication network 100 includes a first device 110, a second device 120, a third device 130, and a fourth device 140. In this example, the first device 110 is shown as an IAB node (also referred to as an IAB node device), the second device 120 and the third device 130 are shown as IAB donors (also referred to as IAB donor devices) serving the IAB node device, and the fourth device 140 is shown as a device served by the first device 110. In some embodiments, the fourth device 140 may be a terminal device served by the first device 110. In some embodiments, the fourth device 140 may be an IAB node device (also referred to as a sub-IAB node device) served by the first device 110.

[0052] The IAB donor (e.g., the second device 120) is composed of an IAB donor CU (e.g., CU 122) and one or more IAB donor DUs (e.g., DU 121). In the case where the control plane and the user plane are separated, the IAB donor may be composed of an IAB donor central unit control plane (IAB donor CU-CP), multiple IAB donor central unit user planes (IAB donor CU-UPs), and multiple IAB donor DUs. It should be understood that the number of the first device, the second device, the third device, and the fourth device is given for illustrative purposes and does not imply any limitation of the present disclosure. The communication network 100 may include any suitable number of first devices, second devices, third devices, and fourth devices suitable for implementing the implementation of the present disclosure.

[0053] For example, although only one first device is shown as an IAB node, the communication network 100 may also include one or more upstream IAB nodes connected between the first device 110 and the second device 120 or between the first device 110 and the third device 130. Of course, the communication network 100 may also include one or more downstream IAB nodes (i.e., child IAB nodes). In addition, although only one fourth device is shown, the communication network 100 may also include more fourth devices served by the first device 110.

[0054] The communication in the communication system 100 can be implemented according to any appropriate communication protocol, including but not limited to cellular communication protocols of the first generation (1G), the second generation (2G), the third generation (3G), the fourth generation (4G) and the fifth generation (5G), such as wireless local area network communication protocols such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11, and / or any other protocol currently known or developed in the future. In addition, the communication can utilize any appropriate wireless communication technology, including but not limited to: code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), frequency division duplex (FDD), time division duplex (TDD), multiple input multiple output (MIMO), orthogonal frequency division multiple access (OFDMA) and / or any other technology currently known or to be developed in the future.

[0055] In this example, the first device 110 includes an MT 111 and a DU 112. The first device 110 is connected to the second device 120 or the third device 130 via the MT 111. The first device 110 establishes an RLC channel to the terminal device and to the MT of the downstream IAB node (not shown) via the DU 112. The DU 112 has an F1 control plane interface (F1-C) connection with a control plane (CP) of an IAB donor CU (IAB donor CU-CP). For example, the DU 112 may have an F1 interface with the CU 122 in the second device 120 or an F1 interface with the CU 132 in the third device 130.

[0056] The second device 120 includes a DU 121 to support the MT of the terminal device and one or more downstream IAB nodes. The second device 120 also includes a DU for all IAB nodes and a CU 122 for the DU's own DU (e.g., DU 121). Similarly, the third device 130 includes one or more DUs, such as DU 131, to support the MT of the terminal device and one or more downstream IAB nodes. The third device 130 also includes a DU for all IAB nodes and a CU 132 for the DU's own DU (e.g., DU 131). It is assumed that the DU on the IAB node can establish an F1 interface with only one IAB donor CU-CP. This IAB donor can be changed by topology adaptation.

[0057] It should be understood that although DU 121 and CU 122 are shown as being implemented on a single entity, DU 121 and CU 122 may be implemented on separate entities, such as in the case of a cloud-based deployment. Similarly, DU 131 and CU 132 may be implemented on a single entity or separate entities.

[0058] In some example embodiments, the DU 112 in the first device 110 is connected to the CU 132 in the third device 130 using an F1 interface (also referred to herein as a first communication interface for convenience). Both the F1 control plane interface (F1-C) and the F1 user plane interface (F1-U) operate on an RLC channel on a wireless backhaul between the MT 111 in the first device 110 and the DU 131 in the third device 130. It should be understood that the F1 interface is merely an example, and any suitable communication interface may be used between the first device 110 and the third device 130.

[0059] In some scenarios, the first device 110 may change its attachment point from the DU 131 in the third device 130 to the DU 121 in the second device 120, thereby causing the IAB donor CU to change from the CU 132 in the third device 130 to the CU 122 in the second device 120. For convenience, the CU 132 is also referred to as the source CU, and the CU 122 is also referred to as the target CU. When the first device 110 changes the IAB donor from the third device 130 to the second device 120, the DU 112 of the first device 110 needs to set or establish an F1 interface (also referred to herein as the second communication interface for convenience) with the target CU 122. It should be understood that the F1 interface is merely an example, and any appropriate communication interface may be used between the first device 110 and the second device 120.

[0060] According to an embodiment of the present disclosure, context information associated with at least one fourth device 140 and a first communication interface between the first device 110 and the third device 130 is retained during the setup or establishment of the second communication interface, and, for example, when the fourth device 140 reestablishes an RRC connection via the second communication interface or resumes an RRC connection or other communication with the first device 110, is reused for the fourth device 140. In this way, the RRC reconstruction or RRC recovery process can be simplified, and signaling can be minimized. In addition, service interruption and delay for terminal devices when the IAB donor changes can be reduced.

[0061] The following will refer to Figures 2 to 7 The principles and implementations of the present disclosure are described in detail. Figure 2 A signaling diagram illustrating a communication process 200 for use during inter-donor topology adaptation according to some example embodiments of the present disclosure is shown. The process 200 may involve an IAB node affected by the inter-donor topology adaptation, a source donor (e.g., the third device 130), and a target donor (e.g., the second device 120). The affected IAB node may be a migration IAB node (e.g., the first device 110) or, if present, a child IAB node of the migration IAB node (another first device not shown). For the purpose of discussion, reference will be made to Figure 1 The process 200 is described by taking the migration of the IAB node as an example of the affected IAB node. In this case, the process 200 may involve the following steps: Figure 1 The first device 110, the second device 120 and the third device 130 are shown. It should be understood that although Figure 1 The process 200 is described in the communication network 100 of FIG. 1 , but the process can also be applied to other communication scenarios.

[0062] like Figure 2 As shown, the first device 110 sends 201 information about the first communication interface between the first device 110 and the third device 130 to the second device 120 (for convenience, also referred to as the first information herein). Any suitable information that can uniquely identify the first communication interface is feasible. In some embodiments, the information may include an identifier of the third device 130. In some embodiments, the information may include an identifier of the CU 132 of the third device 130. For example, the identifier may be a global NG-RAN node identifier (ID) of the CU 132. As another example, the identifier may be a gNB-CU name of the CU 132. As another example, the identifier may be a transport layer address of the CU 132. Of course, any other suitable information that can uniquely identify the third device 130 (i.e., the source donor) is also feasible.

[0063] In some embodiments, the information may also include an identifier of the first device 110. In some embodiments, the information may include an identifier of the DU 112 of the first device 110, or an identifier of the MT 111 of the first device 111. For example, the identifier may be a gNB-DU ID of the DU 112. As another example, the identifier may be a gNB-DU name of the DU 112. As another example, the identifier may be a transport layer address of the DU 112. In another example, the identifier may be a backhaul adaptation protocol (BAP) address or identifier assigned to the first device 110 by the third device 130. Of course, any other suitable information that can uniquely identify the first device 110, i.e., the migrating IAB node or the sub-IAB node of the migrating IAB node is also feasible. In some other embodiments, the information may also include a cell identifier (or multiple identifiers) of the first device 110. For example, the first device 110 uses the cell identifier for the first communication interface with the third device 130.

[0064] In some alternative embodiments, the information may be sent from the third device 130 to the second device 120 during initiation of handover preparation of the first device 110 from the third device 130 to the second device 120. In some alternative embodiments, the first device 110 may send the information during setup or establishment of a second communication interface between the first device 110 and the second device 120. In some example embodiments, the first device 110 may send the information in a request for setup or establishment of the second communication interface. In an example embodiment where the communication interface is an F1 interface, the request for setup or establishment of the communication interface may be an F1 setup request message or any other suitable F1 message.

[0065] Upon receiving the information about the first communication interface, the second device 120 sends 202 to the first device 110 an indication that context information associated with at least one fourth device 140 and the first communication interface may be retained. The indication may be in any suitable form. In some embodiments, the context information may refer to context information for all devices served by the first device 110. In some embodiments, after acquiring the context information from the third device 130 as shown in 206, the second device 120 may send 202 to the first device 110 an indication that context information associated with at least one fourth device 140 and the first communication interface may be retained.

[0066] In some embodiments, the second device 120 may send an indication during initiation of a handover from the third device 130 to the second device 120. For example, when the second device 120 sends a handover request confirmation message to the third device 130 to accept an inbound handover for the first device 110, the second device 120 may include the indication in the handover command message. In some alternative embodiments, the second device 120 may send an indication during setup or establishment of a second communication interface between the first device 110 and the second device 120. In some example embodiments, the second device 120 may send the indication in a response to a request for setup or establishment of the second communication interface. In an example embodiment in which the communication interface is an F1 interface, the response may be an F1 setup response message or any other suitable message.

[0067] Upon receiving the indication, the first device 110 retains 203 the context information for communication via the second communication interface between the first device 110 and the second device 120. In some embodiments, the first device 110 maintains the context information without removing it during setup or establishment of the second communication interface, and reuses the context information for communication via the second communication interface.

[0068] Continue to refer Figure 2 , upon receiving the information about the first communication interface, the second device 120 sends 204 to the third device 130 a request for obtaining context information of at least one fourth device 140 associated with the first communication interface. In some embodiments, the request may include information about the first communication interface. In some embodiments, the request may include an identifier of the third device 130. In some embodiments, the request may include an identifier of the first device 110 and, optionally, a cell identifier of one or more cells of the first device 110. In another embodiment, when an Xn interface is established between the second device 120 and the third device 130, the request may be an Xn Application Protocol (XnAP) message, such as an XnAP RETRIEVE UE CONTEXT REQUEST message or any other suitable XnAP message.

[0069] In some embodiments, the second device 120 may send the request for obtaining the context information during initiation of a handover from the third device 130 to the second device 120. In some alternative embodiments, the second device 120 may send the request for obtaining the context information during setup or establishment of a second communication interface between the first device 110 and the second device 120. In some alternative embodiments, the second device 120 may send the request for obtaining the context information during RRC reestablishment or RRC recovery of at least one fourth device 140.

[0070] In some embodiments, the second device 120 may send a request for obtaining context information of all fourth devices 140 on the first communication interface. In this way, communication latency may be reduced. In some alternative embodiments, the second device 120 may send a request including a cell identifier of one or more cells of the first device 110 in order to obtain context information of the fourth device 140 served by one or more cells of the first device 110. In some alternative embodiments, the second device 120 may send a request for obtaining context information of some fourth devices on the first communication interface. For example, the second device 120 may send a request for obtaining context information of one fourth device on the first communication interface.

[0071] Upon receiving the request for obtaining context information, the third device 130 sends 205 the requested context information to the second device 120. In some embodiments, the context information may include UE context information related to the first communication interface. In an example embodiment in which the communication interface is an F1 interface, the UE context information is related to the F1 interface. In some embodiments, the UE context information may include context information related to a terminal device served by the first device 110. In some embodiments, the UE context information may include context information related to a sub-IAB node served by the first device 110. For example, the UE context information may include at least one of the following: a gNB-CU UE F1AP ID assigned by the third device 130, a gNB-DU UE F1AP ID assigned by the first device 110, radio resource configuration information, signaling radio bearer (SRB) information, data radio bearer (DRB) information, BH RLC channel information when the fourth device 140 is an IAB-MT, F1-U tunnel information, etc. Of course, the UE context information may also include any other information established in the first device 110 and the third device 130 during the usual F1AP UE context setup process. It should be noted that this is merely an example, and the present application does not limit the content of the context information.

[0072] In some embodiments, the third device 130 may send context information for at least one fourth device or a list of fourth devices. In some embodiments, the third device 130 may send context information for all fourth devices served by one or more specific cells of the first device 110. In some embodiments, the third device 130 may send context information for all fourth devices associated with the first communication interface. In another embodiment, when an Xn interface is established between the second device 120 and the third device 130, the context information may be sent via an XnAP message (e.g., an XnAP RETRIEVE UE CONTEXT RESPONSE message or any other suitable XnAP message).

[0073] In some embodiments, the third device 130 may also send 206 to the second device 120 information (for convenience, also referred to herein as second information) for verifying an RRC connection reestablishment request or an RRC recovery request from at least one fourth device 140. In another embodiment, when an Xn interface is established between the second device 120 and the third device 130, the second information may be sent via an XnAP message. In some embodiments, the third device 130 may send the context information together with the second information to the second device 120.

[0074] In some embodiments, the second information may include a UE identity for a fourth device 140. In some embodiments, the UE identity may include at least one of the following: a cell radio network temporary identifier (C-RNTI) assigned to the fourth device 140, a physical cell identity (PCI) of a cell to which the fourth device 140 is connected to the first device 110, ShortMAC-I, ShortI-RNTI value, resumeMAC-I, or any other information that can be used to verify the fourth device 140, etc. ShortMAC-I is used to identify and verify the fourth device 140 when the RRC connection is reestablished. ShortMAC-I is the 16 least significant bits of a message authentication code for data integrity of a signaling message (MAC-1), which is calculated using the access stratum (AS) security configuration of the cell of the first device 110 that is serving the fourth device 140. Compared with the I-RNTI value, the Short_RNTI value is used to identify the suspended UE context of the UE in RRC_INACTIVE using fewer bits. resumeMAC-I is an authentication token that facilitates UE authentication at the gNB, where the 16 least significant bits of MAC-I are calculated using the Access Stratum (AS) security configuration.

[0075] In some embodiments, upon receiving the context information, the second device 120 may update 207 some or all of the context information to adapt to the second communication interface. In an example embodiment where the communication interface is an F1 interface, the context information is associated with the F1 interface. In some embodiments, the updated context information may include at least one of the following: an updated gNB-CU UE F1AP ID assigned by the second device 120, a gNB-DU UE F1AP ID for identifying the fourth device 140 in the first device 110, updated information of radio resource configuration, updated information of SRBs, updated information of DRBs, updated information of backhaul RLC channels when the fourth device 140 is an IAB-MT, updated information of F1-U tunnels, etc. Of course, the updated UE context information may also include any other information updated in the first device 110 and the third device 130 during the usual F1AP UE context modification process. It should be noted that this is merely an example and the present application does not limit the content of the updated context information. In the example embodiment where the communication interface is an F1 interface, the second device 120 may update 207 the context information via an F1AP UE context modification procedure or any other suitable F1AP procedure.

[0076] In some embodiments, when at least one fourth device 140 initiates an RRC connection reestablishment request or an RRC recovery request, the second device 120 may verify 208 the RRC connection reestablishment request or the RRC recovery request using the second information received from the third device 130. In some embodiments, verification may be performed before updating the context information. Of course, the present disclosure does not limit the order of verification and updating.

[0077] In some embodiments, during an RRC connection reestablishment procedure or an RRC recovery request of at least one fourth device 140, the second device 120 may send 209 updated context information to the first device 110. In some embodiments where the second communication interface is an F1 interface, the second device 120 may send the updated context information in an F1AP message, such as an F1AP UE CONTEXT MODIFICATION REQUEST message or other F1AP message.

[0078] Upon receiving the updated context information, the first device 110 may update the context information retained by 210 using the updated context information. Using the updated context information, the first device 110 may continue to perform the RRC reestablishment process or the RRC recovery process. In this way, when the IAB donor changes, the reestablishment process or the recovery process may be simplified by eliminating the complete reestablishment of the context information in the IAB node. This minimizes the signaling on the Xn interface, the F1 interface, and the wireless backhaul, and reduces the service interruption and latency of the terminal device when the IAB donor changes.

[0079] Will refer to Figure 3 and Figure 4 Describe in more detail. Figure 3 Example context information transmission during establishment of a second communication interface (eg, during an F1 setup process) is described. Figure 4 Example context information transmission during connection re-establishment of a terminal device (eg, during an Xn Get UE Context procedure) is described.

[0080] Figure 3 A signaling diagram illustrating a process 300 for inter-donor topology adaptation according to some other example embodiments of the present disclosure is shown. For the purpose of discussion, reference will be made to Figure 1 Describe process 300. Process 300 may involve Figure 1 The first device 110, the second device 120, the third device 130 and the fourth device 140 are shown. It should be understood that although Figure 1 The process 300 is described in the communication network 100 of FIG. 1 , but the process can also be applied to other communication scenarios. Figure 3 Context information transfer during setup or establishment of a second communication interface is described.

[0081] When initiating a handover of the first device 110 from the third device 130 to the second device 120, the CU 122 of the second device 120 configures a new adaptation layer route on the wireless BH between the first device 110 and the DU 121 of the second device 120. Then, the first device 110 performs a DU setup process and sets or establishes a communication interface with the CU 122 of the second device 120. When the DU 112 of the first device 110 needs to set or establish a communication interface with the CU 122 of the second device 120, the DU 112 of the first device 110 may perform a DU setup process. Figure 3 process.

[0082] like Figure 3As shown, the first device 110 sends 301 information about a first communication interface between the first device 110 and the third device 130 to the second device 120 (for convenience, also referred to herein as first information). In this example, the first device 110 sends the information in a request for setting or establishing a second communication interface between the first device 110 and the second device 120. In an example embodiment where the communication interface is an F1 interface, the request for establishing the second communication interface may be an F1 SETUP REQUEST message.

[0083] Any suitable information that can uniquely identify the first communication interface is feasible. In some embodiments, the information may include an identifier of the third device 130. In some embodiments, the information may include an identifier of the CU 132 of the third device 130. For example, the identifier may be a global NG-RAN node identifier (ID) of the CU 132. As another example, the identifier may be a gNB-CU name of the CU 132. As another example, the identifier may be a transport layer address of the CU 132. Of course, any other suitable information that can uniquely identify the third device 130 (i.e., the source donor) is also feasible.

[0084] In some embodiments, the information may also include an identifier of the first device 110. In some embodiments, the information may include an identifier of the DU 112 of the first device 110, or an identifier of the MT 111 of the first device 111. For example, the identifier may be a gNB-DU ID of the DU 112. As another example, the identifier may be a gNB-DU name of the DU 112. As another example, the identifier may be a transport layer address of the DU 112. In another example, the identifier may be a BAP address or identifier assigned to the first device 110 by the third device 130. Of course, any other suitable information that can uniquely identify the first device 110, i.e., the migration IAB node or the child IAB node of the migration IAB node is also feasible. In some other embodiments, the information may also include a cell identifier (or multiple identifiers) of the first device 110. For example, the first device 110 uses the cell identifier for the first communication interface with the third device 130.

[0085] Upon receiving the information about the first communication interface, the second device 120 sends 302 to the third device 130 a request for obtaining context information associated with at least one fourth device 140 and the first communication interface. In some embodiments, the request may include information about the first communication interface. In some embodiments, the request may include an identifier of the third device 130. In some embodiments, the request may include an identifier of the first device 110. In some embodiments, the request may include one or more cell identifiers of the first device 110.

[0086] In this example, the second device 120 may initiate an XnAP process to obtain context information from the third device 130. In some embodiments, the second device 120 may send a request for obtaining context information of all fourth devices associated with the first communication interface. In this way, the communication delay reestablished between the first device 110 and the second device 120 may be reduced. In some alternative embodiments, the second device 120 may send a request including a cell identifier of one or more cells of the first device 110 in order to obtain context information of fourth devices in one or more cells provided by the first device 110. In some alternative embodiments, the second device 120 may send a request for obtaining context information of some fourth devices associated with the first communication interface.

[0087] Upon receiving the request for obtaining context information, the third device 130 sends 303 the requested context information to the second device 120. In some embodiments, the context information may include UE context information related to the first communication interface. In an example embodiment where the communication interface is an F1 interface, the UE context information is related to the F1 interface. In some embodiments, the UE context information may include at least one of the following: a gNB-CU UE F1AP ID assigned by the third device 130, a gNB-DU UE F1AP ID assigned by the first device 110, radio resource configuration information, SRB information, DRB information, BH RLC channel information when the fourth device 140 is an IAB-MT, F1-U tunnel information, etc. Of course, the UE context information may also include any other information established in the first device 110 and the third device 130 during the usual F1AP UE context establishment process. It should be noted that this is merely an example and the present application does not limit the content of the context information.

[0088] In some embodiments, the third device 130 may send context information for one fourth device or a list of fourth devices. In some embodiments, the third device 130 may send context information for all fourth devices served by one or more specific cells of the first device 110. In some embodiments, the third device 130 may send context information for all fourth devices associated with the first communication interface.

[0089] In some embodiments, the third device 130 may also send information (also referred to herein as second information for convenience) for verifying an RRC connection reestablishment request or an RRC recovery request from at least one fourth device 140 to the second device 120. For example, the CU 132 of the third device 130 may send the second information of each connected terminal device to the CU 122 of the second device 120. In some embodiments, the third device 130 may send the context information and the second information together to the second device 120.

[0090] In some embodiments, the second information may include a UE identity of the fourth device 140. In some embodiments, the UE identity may include at least one of the following: a C-RNTI assigned to the fourth device 140, a PCI of a cell to which the fourth device 140 is connected to the first device 110, a shortMAC-I, a ShortI-RNTI value, a resumeMAC-I, or any other information that can be used to verify the fourth device 140.

[0091] In some embodiments, the second information may include a token. At least one of a cell radio network temporary identifier (C-RNTI), a physical cell ID (PCI), and a target cell ID may be allocated by the IAB node (ie, the first device 110), and the source gNB (ie, the third device 130) may generate a token and provide it to the target donor (ie, the second device 120). In this way, the target donor (ie, the second device 120) may verify the token received later in the RRC connection reestablishment request or the RRC recovery request on behalf of the source donor (ie, the third device 130).

[0092] In some embodiments, upon receiving the context information, the second device 120 may save the context information and decide whether to reuse it completely. In some embodiments, the second device 120 may update 304 some or all of the context information to adapt to the second communication interface. For example, the second device 120 may update 304 part of the context information. In an example embodiment where the communication interface is an F1 interface, the context information is related to the F1 interface. In some embodiments, the updated context information may include at least one of the following: an updated gNB-CU UE F1AP ID assigned by the second device 120, a gNB-DU UE F1AP ID for identifying the fourth device 140 in the first device 110, updated radio resource configuration information, updated SRB information, updated DRB information, updated backhaul RLC channel information when the fourth device 140 is an IAB-MT, updated F1-U tunnel information, etc. Of course, the updated UE context information may also include any other information updated in the first device 110 and the third device 130 during the usual F1AP UE context modification process. It should be noted that this is merely an example, and the present application does not limit the content of the updated context information.

[0093] In some embodiments, the target donor CU CP (i.e., the CP of the CU 122 of the second device 120) initiates an E1 application protocol (E1AP) context setup for at least the fourth device 140 in the target donor CUUP (i.e., the user plane (UP) of the CU 122 of the second device 120). The E1AP message also includes downlink fully qualified TEID (DL F-TEID) information in the first device 110 (e.g., the migrating IAB node). This is different from the usual E1AP UE context setup, during which the DL F-TEID is not known. The target donor CU CP may also take into account a new IP address assigned to the first device 110, such as the migrating IAB node when setting up the E1AP context in the target donor CU CP.

[0094] Continue to refer Figure 3 , the second device 120 sends 305 to the first device 110 an indication to retain context information associated with at least one fourth device 140 and the first communication interface. The indication may be in any suitable form. In this example, the second device 120 may send the indication in a response to a request for setting or establishing a second communication interface. In an example embodiment where the communication interface is an F1 interface, the response may be an F1 setup response message.

[0095] Upon receiving the indication, the first device 110 retains 306 the context information for communication via the second communication interface between the first device 110 and the second device 120. In some embodiments, the first device 110 maintains the context information without removing it during setup or establishment of the second communication interface, and reuses the context information for communication via the second communication interface.

[0096] In some embodiments, when the first device 110 is disconnected from the third device 130, the first device 110 stops DU operation (including over-the-air transmission). After the first device 110 is connected to the second device 120, the first device 110 resumes DU operation (including over-the-air transmission). During this period, when the first device 110 stops DU operation, the fourth device 140 may detect a radio link failure (RLF), and when the first device 110 resumes DU operation, the fourth device 140 may reconnect with the first device 110. When declaring RLF to the old DU (in this example, the DU 112 of the first device 110 when the DU operation is stopped), the fourth device 140 may select 307 a new DU (in this example, the DU 112 of the first device 110 when the DU operation is resumed) and initiate 308 an RRC connection reestablishment process via the first device 110. The first device 110 may send 309 an F1 INITIAL UL RRC message to the CP of the CU 122 of the second device 120. Since the CU 122 of the second device 120 has already acquired the context information from the CU 132 of the third device 130, the CU 122 of the second device 120 does not need to initiate the XnAP acquisition UE context process as currently used in the reconstruction process. In another example, the RRC_INACTIVE fourth device initiates an RRC connection recovery process with the first device 110. Since the CU 122 of the second device 120 has already acquired the context information from the CU 132 of the third device 130, the CU 122 of the second device 120 does not need to initiate the XnAP acquisition UE context process as currently used in the RRC connection reconstruction process or the RRC connection recovery process. Therefore, the RRC connection reconstruction process or the recovery process is significantly simplified, and the communication delay is reduced.

[0097] In some embodiments, using the second information received from the third device 130, the second device 120 may verify 310 information received in the RRC Reestablishment Request message or the RRC Recovery Request message, such as a token.

[0098] In some embodiments where the second device 120 updates the context information, the second device 120 may send 311 the updated context information, for example, via a FIAP UE context modification procedure. The first device 110 may find 312 context information for the fourth device 140. For example, the first device 110 may find the context information based on the old gNB-DU UE FIAP ID and replace the old C-RNTI or PCI with the new C-RNTI or PCI. Other processes to complete the reestablishment may then be performed 313 in a conventional manner and are omitted here for simplicity.

[0099] use Figure 3 In the process of resetting the context information of the first device 110 (e.g., migrating the IAB node) when the IAB donor is changed, the resetting process or the recovery process can be significantly simplified by eliminating the complete resetting of the context information in the first device 110 (e.g., migrating the IAB node). This minimizes the signaling on the Xn interface, the F1 interface, and the wireless backhaul, and reduces the service interruption and delay for the terminal device when the IAB donor is changed.

[0100] Figure 4 A signaling diagram illustrating a process 400 for inter-donor topology adaptation according to some other example embodiments of the present disclosure is shown. For the purpose of discussion, reference will be made to Figure 1 Process 400 is described. Process 400 may include the following: Figure 1 The first device 110, the second device 120, the third device 130 and the fourth device 140 are shown. It should be understood that although Figure 1 The process 400 is described in the communication network 100 of FIG. 4 , but the process can also be applied to other communication scenarios.

[0101] When initiating a handover of the first device 110 from the third device 130 to the second device 120, the CU 122 of the second device 120 configures a new adaptation layer route on the wireless BH between the first device 110 and the DU 121 of the second device 120. Then, the first device 120 performs a DU setup process and establishes a communication interface with the CU 122 of the second device 120. When the DU 112 of the first device 110 needs to establish a communication interface with the CU 122 of the second device 120, the DU 112 of the first device 110 may perform a DU setup process. Figure 4 process.

[0102] like Figure 4As shown, the first device 110 sends 401 information about a first communication interface between the first device 110 and the third device 130 (also referred to herein as first information for convenience) to the second device 120. In this example, the first device 110 sends the information in a request for setting or establishing a second communication interface between the first device 110 and the second device 120. In an example embodiment where the communication interface is an F1 interface, the request for establishing the second communication interface may be an F1 setup request message.

[0103] Any suitable information that can uniquely identify the first communication interface is feasible. In some embodiments, the information may include an identifier of the third device 130. In some embodiments, the information may include an identifier of the CU 132 of the third device 130. For example, the identifier may be a global NG-RAN node ID of the CU 132. As another example, the identifier may be a gNB-CU name of the CU 132. As another example, the identifier may be a transport layer address of the CU 132. Of course, any other suitable information that can uniquely identify the third device 130 (i.e., the source donor) is also feasible.

[0104] In some embodiments, the information may also include an identifier of the first device 110. In some embodiments, the information may include an identifier of the DU 112 of the first device 110, or an identifier of the MT 111 of the first device 111. For example, the identifier may be a gNB-DU ID of the DU 112. As another example, the identifier may be a gNB-DU name of the DU 112. As another example, the identifier may be a transport layer address of the DU 112. In another example, the identifier may be a BAP address or identifier assigned to the first device 110 by the third device 130. Of course, any other suitable information that can uniquely identify the first device 110 (i.e., a migrated IAB node or a sub-IAB node of a migrated IAB node) is also feasible. In some other embodiments, the information may also include a cell identifier (or multiple identifiers) of the first device 110. For example, the first device 110 uses the cell identifier for the first communication interface with the third device 130.

[0105] Upon receiving the information about the first communication interface, the second device 120 sends 402 to the first device 110 an indication to retain context information associated with at least one fourth device 140 and the first communication interface. The indication may be in any suitable form. In this example, the second device 120 may send the indication in a response to a request for setting or establishing the second communication interface. In an example embodiment where the communication interface is an F1 interface, the response may be an F1 setup response message.

[0106] Upon receiving the indication, the first device 110 retains 403 the context information for communication via the second communication interface between the first device 110 and the second device 120. In some embodiments, the first device 110 retains the context information without removing it during establishment of the second communication interface and reuses the context information for communication via the second communication interface.

[0107] In some embodiments, when the first device 110 is disconnected from the third device 130, the first device 110 stops DU operation (including over-the-air transmission). After the first device 110 is connected to the second device 120, the first device 110 resumes DU operation (including over-the-air transmission). During this period, the fourth device 140 may detect RLF when the first device 110 stops DU operation, and reconnect with the first device 110 when the first device 110 resumes DU operation. When declaring RLF to the old DU (in this example, the DU 112 of the first device 110 when the DU operation is stopped), the fourth device 140 may select 404 a new DU (in this example, the DU 112 of the first device 110 when the DU operation is resumed) and initiate 405 a connection reestablishment process via the first device 110. The first device 110 may send 406 an F1 INITIAL UL RRC message to the CP of the CU 122 of the second device 120. Then, the second device 120 initiates an Xn Get UE Context process.

[0108] During the Xn UE context acquisition process, the second device 120 sends 407 to the third device 130 a request for obtaining context information of the fourth device 140 about the first communication interface. In some embodiments where the communication interface is an F1 interface, the request may be an Xn UE context acquisition request message. In some embodiments, the request may include information about the first communication interface. In some embodiments, the request may include an identifier of the third device 130. In some embodiments, the request may include an identifier of the first device 110. In some embodiments, the request may include an identifier of the fourth device 140. Of course, the request may include any other suitable information. In some embodiments where the request may include information for verifying a connection reconstruction request or a recovery request from the fourth device 140, the third device 130 may verify a connection reconstruction request or a recovery request from the fourth device 140 based on the information.

[0109] In response to the request, the third device 130 sends 408 context information associated with the fourth device 140 and the first communication interface to the second device 120. In some embodiments, the context information may include UE context information associated with the first communication interface. In the example embodiment where the communication interface is an F1 interface, the UE context information is associated with the F1 interface. In some embodiments, the UE context information may include context information associated with a terminal device served by the first device 110. In some embodiments, the UE context information may include context information associated with a sub-IAB node served by the first device 110. For example, the UE context information may include at least one of the following: a gNB-CU UE F1AP ID assigned by the third device 130, a gNB-DU UE F1AP ID assigned by the first device 110, information of radio resource configuration, information of SRBs, information of DRBs, information of BH RLC channels when the fourth device 140 is an IAB-MT, information of F1-U tunnels, etc. Of course, the UE context information may also include any other information established in the first device 110 and the third device 130 during the usual F1AP UE context establishment process. It should be noted that this is merely an example, and the present application does not limit the content of the context information.

[0110] Upon receiving the context information, the second device 120 may save the context information and decide whether to reuse it completely. In some embodiments, the second device 120 may update 409 the context information to adapt to the second communication interface. For example, the second device 120 may update part of the context information. In an example embodiment where the communication interface is an F1 interface, the updated context information is related to the F1 interface. In some embodiments, the updated context information may include at least one of the following: an updated gNB-CU UE F1AP ID assigned by the second device 120, a gNB-DU UE F1AP ID for identifying the fourth device 140 in the first device 110, updated radio resource configuration information, updated SRB information, updated DRB information, updated backhaul RLC channel information when the fourth device 140 is an IAB-MT, updated F1-U tunnel information, etc. Of course, the updated UE context information may also include any other information updated in the first device 110 and the third device 130 during the usual F1AP UE context modification process. It should be noted that this is merely an example, and the present application does not limit the content of the updated context information.

[0111] In some embodiments, the target donor CU-CP (i.e., the CP of the CU 122 of the second device 120) may initiate an E1 application protocol (E1AP) context setup for at least the fourth device 140 in the target donor CU-UP (i.e., the user plane (UP) of the CU 122 of the second device 120). The E1AP message additionally includes DL F-TEID information in the first device 110 (e.g., the migrating IAB node). This is different from the usual E1AP UE context setup procedure, during which the DL F-TEID is not known. When establishing the E1AP context in the target donor CU UP, the target donor CU-CP may also take into account the new IP address assigned to the first device 110 (e.g., the migrating IAB node).

[0112] In some embodiments where the second device 120 updates the context information, the second device 120 may send 410 the updated context information, for example, via a FIAP UE context modification procedure. The first device 110 may find 411 the retained context information of the fourth device 140. For example, the first device 110 may find the retained context information based on the old gNB-DU UE FIAP ID and replace the old C-RNTI or PCI with the new C-RNTI or PCI. Other processes are then performed 412 in a conventional manner to complete the reestablishment and are omitted here for simplicity.

[0113] use Figure 4 The RRC connection reestablishment process or the recovery process can be simplified by eliminating the complete reconstruction of the context information in the first device 110 (e.g., the migration IAB node) when the IAB donor changes, while slightly modifying the current specification. This also reduces the signaling on the Xn interface, the F1 interface, and the wireless backhaul, and improves the service interruption and latency for the terminal device when the IAB donor changes.

[0114] Figure 5 1 is a flowchart of an example method 500 implemented at a first device according to some example embodiments of the present disclosure. The method 500 may be implemented at a device that is a migration IAB node or a child IAB node of a migration IAB node, for example Figure 1 For convenience, reference will be made to the first device 110. Figure 1 Method 500 is described.

[0115] At block 510, the first device 110 sends first information about a first communication interface between the first device 110 and the third device 130 to the second device 120. In some embodiments, the first information may include at least one of: a cell identifier of the first device 110 for the first communication interface, an identifier of the first device 110, and an identifier of the third device 130. In some embodiments, sending may include sending the first information to the second device 120 in a setup request for the second communication interface.

[0116] At block 520, the first device 110 receives an indication from the second device 120 to retain context information associated with the at least one fourth device 140 and the first communication interface. In some embodiments, receiving may include receiving the indication from the second device 120 in a response to the setup request.

[0117] At block 530 , the first device 110 uses the context information in communications via the second communication interface between the first device 110 and the second device 120 .

[0118] In some embodiments, the first device 110 may also receive updated context information from the second device 120. In some embodiments, the first device 110 may also update the retained context information with the updated context information.

[0119] Figure 6 6 is a flowchart showing an example method 600 implemented at a second device according to some example embodiments of the present disclosure. The method 600 may be implemented at a device that is a target IAB donor, for example Figure 1 For convenience, reference will be made to the second device 120. Figure 1 Method 600 is described.

[0120] At block 610, the second device 120 receives first information about a first communication interface between the first device 110 and the third device 130 from the first device 110. In some embodiments, the first information may include at least one of: a cell identifier of the first device 110 for the first communication interface, an identifier of the first device 110, and an identifier of the third device 130. In some embodiments, receiving may include receiving the first information from the first device 110 in a setup request for the second communication interface.

[0121] At block 620, the second device 120 sends a request for obtaining context information associated with at least one fourth device 140 and the first communication interface to the third device 130 based on the first information. In some embodiments, the request may include at least one of the following: an identifier of the third device 130, an identifier of the first device 110, a cell identifier of the first device 110, and an identifier of the fourth device 140.

[0122] In some embodiments, the second device 120 may also send an indication to the first device 110 indicating to retain context information associated with the at least one fourth device 140 and the first communication interface. In some embodiments, the sending may include sending the indication to the first device 110 in a response to the setting request. In some other embodiments, the sending may be performed after the second device 120 receives the context information from the third device 130.

[0123] In block 630, the second device 120 receives context information of at least one fourth device 140 for communicating via the second communication interface between the first device 110 and the second device 120 from the third device 130. In some embodiments, the second device 120 may update the context information and send the updated context information to the first device 110.

[0124] In some embodiments, the second device 120 may also receive second information from the third device 130 for verifying an RRC connection reconstruction request or a restoration request from at least one fourth device 140, and verify the RRC connection reconstruction request or the restoration request from at least one fourth device 140 based on the second information.

[0125] Figure 7 1 is a flowchart of an example method 700 implemented at a third device according to some example embodiments of the present disclosure. The method 700 may be implemented at a device that is a source IAB donor, for example Figure 1 For convenience, reference will be made to the third device 130. Figure 1 Method 700 is described.

[0126] At block 710, the third device 130 receives a request from the second device 120 for obtaining context information associated with at least one fourth device 140 and a first communication interface between the first device 110 and the third device 130. In some embodiments, the request may include at least one of: an identification of the third device 130, an identification of the first device 110, a cell identification of the first device 110, and an identification of the fourth device 140.

[0127] At block 720, the third device 130 sends context information to the second device 120 for communication via the second communication interface between the first device 110 and the second device 120. In some embodiments, the third device 130 may send second information to the second device 120 for verifying a connection reestablishment request or a recovery request from at least one fourth device 140.

[0128] It should be understood that reference Figures 1 to 4The description of the features also applies to methods 500, 600 and 700 and has the same effect. Therefore, the details of these features are omitted.

[0129] In some example embodiments, any device capable of executing method 500 (e.g., first device 110) may include a component for executing each step of method 500. The component may be implemented in any suitable form. For example, the component may be implemented in a circuit or a software module.

[0130] In some example embodiments, the apparatus includes: a component for sending, at the first device, to a second device, first information about a first communication interface between the first device and a third device; a component for receiving, from the second device, an indication to retain context information associated with at least one fourth device and the first communication interface; and a component for using the context information in communication via a second communication interface between the first device and the second device.

[0131] In some example embodiments, the means for sending the first information may include means for sending the first information to the second device in a setup request for the second communication interface, and the means for receiving the indication may include means for receiving the indication from the second device in a response to the setup request.

[0132] In some example embodiments, the first information may include at least one of an identification of the third device and an identification of the first device.

[0133] In some example embodiments, the apparatus may further comprise means for receiving updated context information from the second device. In some example embodiments, the apparatus may further comprise means for updating the context information using the updated context information.

[0134] In some example embodiments, any device capable of executing method 600 (e.g., second device 120) may include a component for executing each step of method 600. The component may be implemented in any suitable form. For example, the component may be implemented in a circuit or a software module.

[0135] In some example embodiments, the apparatus includes a component for receiving, at a second device, first information about a first communication interface between a first device and a third device; a component for sending, based on the first information, a request to the third device to obtain context information associated with at least one fourth device and the first communication interface; and a component for receiving context information from the third device for communication via a second communication interface between the first device and the second device.

[0136] In some example embodiments, the apparatus may further comprise means for sending an indication to the first device indicating to retain context information associated with at least one fourth device and the first communication interface.

[0137] In some example embodiments, means for receiving the first information may include means for receiving the first information from the first device in a setup request for the second communication interface, and means for sending an indication in a response to the setup request.

[0138] In some example embodiments, means for receiving the first information may include means for receiving the first information from the third device in a request to switch the first device from the third device to the second device, and means for sending an indication in a response to a setup request.

[0139] In some example embodiments, the apparatus may further include: a component for receiving second information for verifying the connection reestablishment request from the at least one fourth device from the third device; and a component for verifying the connection reestablishment request from the at least one fourth device based on the second information.

[0140] In some example embodiments, the apparatus may further include means for updating context information. In some example embodiments, the apparatus may further include means for sending updated context information to the first device. In some example embodiments, the first information may include at least one of an identification of the third device and an identification of the first device.

[0141] In some example embodiments, any device capable of executing method 700 (e.g., third device 130) may include components for executing the various steps of method 700. The components may be implemented in any suitable form. For example, the components may be implemented in a circuit or a software module.

[0142] In some example embodiments, the apparatus includes: a component for receiving a request from a second device for obtaining context information associated with at least one fourth device and a first communication interface between the first device and a third device; and a component for sending the context information to the second device for communication via a second communication interface between the first device and the second device.

[0143] In some example embodiments, the apparatus may further include means for sending, to the second device, second information for verifying the connection reestablishment request from the at least one fourth device.

[0144] In some example embodiments, the request may include at least one of an identification of the third device and an identification of the first device.

[0145] In some example embodiments, the first device may be an IAB node device, each of the second device and the third device may be an IAB donor device, and the fourth device may be at least one of a terminal device served by the first device and an IAB node device.

[0146] Figure 8 800 is a simplified block diagram of a device 800 suitable for implementing embodiments of the present disclosure. The device 800 may be provided to implement a communication device, such as Figure 1 The first device 110, the second device 120 or the third device 130 is shown. As shown in the figure, the device 800 includes one or more processors 810, one or more memories 820 coupled to the processor 810, and one or more communication modules 840 coupled to the processor 810.

[0147] The communication module 840 is used for two-way communication. The communication module 840 has at least one antenna to facilitate communication. The communication interface may represent any interface required to communicate with other network elements.

[0148] Processor 810 may be of any type suitable for the local technology network, and may include, as non-limiting examples, one or more of: a general purpose computer, a special purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture. Device 800 may have multiple processors, such as application-specific integrated circuit chips that are time-slaved to a clock synchronized with a main processor.

[0149] The memory 820 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 824, electrically programmable read-only memory (EPROM), flash memory, hard disks, compact disks (CDs), digital video disks (DVDs), and other magnetic and / or optical memories. Examples of volatile memories include, but are not limited to, random access memory (RAM) 822 and other volatile memories that do not persist over the duration of a power outage.

[0150] The computer program 830 includes computer executable instructions executed by the associated processor 810. The program 830 may be stored in the ROM 824. The processor 810 may perform any suitable actions and processes by loading the program 830 into the RAM 822.

[0151] The embodiments of the present disclosure may be implemented by a program 830 so that the device 800 may execute the reference Figures 2 to 7Any process of the present disclosure discussed. The embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

[0152] In some embodiments, the program 830 may be tangibly embodied in a computer-readable medium that may be included in the device 800 (e.g., memory 820) or other storage device accessible to the device 800. The device 800 may load the program 830 from the computer-readable medium to the RAM 822 for execution. The computer-readable medium may include any type of tangible non-volatile memory, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc. Fig. 9 An example of a computer readable medium 900 in the form of a CD or DVD is shown. The computer readable medium has a program 830 stored thereon.

[0153] In general, various embodiments of the present disclosure may be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software, which may be executed by a controller, microprocessor, or other computing device. Although various aspects of the present disclosure are shown and described as block diagrams, flow charts, or using some other illustrations, it should be understood that the block diagrams, devices, systems, techniques, or methods described herein may be implemented as non-limiting examples in hardware, software, firmware, dedicated circuits or logic, general hardware or controllers or other computing devices, or some combination thereof.

[0154] The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer executable instructions, such as instructions included in program modules, which are executed in a device on a target real or virtual processor to perform the above-referenced Figure 5 , Figure 6 and Figure 7 Methods 500, 600 and 700 are described. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In various embodiments, the functions of program modules can be combined or divided between program modules as needed. The machine executable instructions of program modules can be executed in local or distributed devices. In distributed devices, program modules can be located in both local storage media and remote storage media.

[0155] The program code for executing the disclosed method may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device so that when executed by the processor or controller, the program code causes the functions / operations specified in the flow chart and / or block diagram to be implemented. The program code may be executed entirely on the machine as a stand-alone software package, partially on the machine, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0156] In the context of the present disclosure, computer program codes or related data may be carried by any suitable carrier to enable a device, apparatus or processor to perform the above-mentioned various processes and operations. Examples of carriers include signals, computer-readable media, etc.

[0157] The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or apparatuses, or any suitable combination of the above. More specific examples of computer readable storage media include an electrical connection with one or more wires, a portable computer floppy disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0158] In addition, although operations are described in a particular order, this should not be construed as requiring that such operations be performed in the particular order or sequence shown, or that all illustrated operations be performed in order to obtain the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these details should not be interpreted as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to a particular embodiment. Certain features described in the context of a separate embodiment may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination.

[0159] Although the disclosure has been described in language specific to structural features and / or methodological acts, it should be understood that the disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A first device, comprising: at least one processor; as well as at least one memory including computer program code; The at least one memory and the computer program code are configured to, with the at least one processor, cause the first device to: Sending, at the first device, first information about a first communication interface between the first device and a third device to a second device; receiving, from the second device, an indication to retain context information associated with at least one fourth device and the first communication interface, the context information being the context information of all devices served by the first device; as well as The first device does not remove the context information during establishment of a second communication interface between the first device and the second device, and uses the context information in communications via the second communication interface; wherein the first device is caused to send the first information in the following manner: sending the first information to the second device in a setup request for the second communication interface, and The first device is caused to receive the indication in the following manner: receiving the indication in a response to the setting request from the second device. 2 . The first device according to claim 1 , wherein the first information comprises at least one of the following: an identifier of the third device, an identifier of the first device, and an identifier of a cell of the first device.

3. The first device according to claim 1, wherein the first device is further configured to: Updated context information is received from the second device.

4. The first device according to claim 3, wherein the first device is further configured to: The context information is updated using the updated context information.

5. The first device according to claim 1, wherein the first device is an integrated access and backhaul (IAB) node device, each of the second device and the third device is an IAB donor device, and the fourth device is at least one of a terminal device and an IAB node device served by the first device.

6. A second device, comprising: at least one processor; as well as at least one memory including computer program code; The at least one memory and the computer program code are configured to, with the at least one processor, cause the second device to: receiving, at the second device, first information about a first communication interface between the first device and a third device; Sending, based on the first information, to the third device a request for obtaining context information associated with at least one fourth device and the first communication interface, the context information referring to the context information of all devices served by the first device; receiving the context information from the third device for use in communicating via a second communication interface between the first device and the second device; as well as sending, to the first device, an indication to retain the context information associated with the at least one fourth device and the first communication interface; wherein the second device is caused to receive the first information by: receiving the first information from the first device in a setup request for the second communication interface, and wherein the second device is caused to send the indication by: sending the indication to the first device in a response to the setting request; The second device is further configured to: receiving, from the third device, second information for verifying a connection reestablishment request or a restoration request from the at least one fourth device; and Based on the second information, the connection reestablishment request or the restoration request from the at least one fourth device is verified.

7. The second device according to claim 6, wherein the second device is caused to receive the first information by: receiving the first information from the third device in a request for switching the first device from the third device to the second device, and The second device is caused to send the indication in the following manner: sending the indication to the first device in a response to the setting request.

8. The second device according to claim 6, wherein the second device is further configured to: The context information is updated.

9. The second device according to claim 8, wherein the second device is further configured to: The updated context information is sent to the first device. 10 . The second device according to claim 6 , wherein the first information comprises at least one of the following: an identifier of the third device, an identifier of the first device, and an identifier of a cell of the first device.

11. The second device according to claim 6, wherein the first device is an integrated access and backhaul (IAB) node device, each of the second device and the third device is an IAB donor device, and the fourth device is at least one of a terminal device and an IAB node device served by the first device.

12. A method for communication, comprising: sending, at a first device, to a second device, first information about a first communication interface between the first device and a third device; receiving, from the second device, an indication to retain context information associated with at least one fourth device and the first communication interface, the context information being the context information of all devices served by the first device; as well as The first device does not remove the context information during establishment of a second communication interface between the first device and the second device, and uses the context information in communications via the second communication interface; wherein the sending comprises: sending the first information to the second device in a setting request for the second communication interface, and The receiving comprises: receiving the indication in a response to the setting request from the second device. 13 . The method according to claim 12 , wherein the first information comprises at least one of the following: an identifier of the third device, an identifier of the first device, and an identifier of a cell of the first device.

14. The method according to claim 12, further comprising: Updated context information is received from the second device.

15. The method according to claim 14, further comprising: The context information is updated using the updated context information.

16. A method for communication, comprising: receiving, at the second device, first information regarding a first communication interface between the first device and a third device; Sending, based on the first information, to the third device a request for obtaining context information associated with at least one fourth device and the first communication interface, the context information referring to the context information of all devices served by the first device; receiving the context information from the third device for use in communicating via a second communication interface between the first device and the second device; as well as sending, to the first device, an indication to retain the context information associated with the at least one fourth device and the first communication interface; Wherein receiving the first information comprises: receiving the first information from the first device in a setting request for the second communication interface; Wherein sending the indication comprises: sending the indication to the first device in a response to the setting request; The method further comprises: receiving, from the third device, second information for verifying a connection reestablishment request or a restoration request from the at least one fourth device; and Based on the second information, the connection reestablishment request or the restoration request from the at least one fourth device is verified.

17. The method of claim 16, wherein receiving the first information comprises: receiving the first information from the third device in a request for switching the first device from the third device to the second device, and The sending of the indication includes: sending the indication to the first device in a response to the setting request.

18. The method according to claim 16, further comprising: The context information is updated.

19. The method according to claim 18, further comprising: The updated context information is sent to the first device. 20 . The method according to claim 16 , wherein the first information comprises at least one of the following: an identifier of the third device, an identifier of the first device, and an identifier of a cell of the first device.

21. An apparatus for communication, comprising: means for sending, at a first device, to a second device, first information about a first communication interface between the first device and a third device; means for receiving, from the second device, an indication to retain context information associated with at least one fourth device and the first communication interface, the context information being the context information of all devices served by the first device; as well as means for using the context information in communications via a second communications interface between the first device and the second device; wherein the first device does not remove the context information during establishment of the second communication interface; The means for sending the first information comprises means for sending the first information to the second device in a setup request for the second communication interface, and the means for receiving the indication comprises means for receiving the indication from the second device in a response to the setup request.

22. An apparatus for communication, comprising: means for receiving, at a second device, first information regarding a first communication interface between the first device and a third device; a means for sending, based on the first information, to the third device, a component for obtaining context information, the context information being associated with at least one fourth device and the first communication interface, the context information being the context information of all devices served by the first device; means for receiving the context information from the third device for use in communicating via a second communication interface between the first device and the second device; as well as means for sending to the first device an indication to retain context information associated with at least one fourth device and the first communication interface; wherein the means for receiving the first information comprises: means for receiving the first information from the first device in a request for setting the second communication interface, and means for sending an indication in a response to the request for setting; The device also includes: means for receiving, from the third device, second information for verifying a connection reestablishment request from the at least one fourth device; and means for verifying a connection reestablishment request from the at least one fourth device based on the second information.

23. A non-transitory computer readable medium comprising program instructions for causing an apparatus to perform the method according to any one of claims 12 to 15.

24. A non-transitory computer readable medium comprising program instructions for causing an apparatus to perform the method according to any one of claims 16 to 20.

Images