Device, method, apparatus and computer readable medium for topological redundancy

Abstract

Embodiments of this disclosure relate to topological redundancy. A first device sends a request to a second device for establishing a context for a third device served by the first device. The first device receives the context from the second device. The first device sends the context to the third device for communication between the third device and the first device via a fourth device. The fourth device is managed by the second device.

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 topology redundancy. Background Art

[0002] Integrated Access Backhaul (IAB) implements wireless relay for New Radio (NR) access by using NR for backhaul. The relay node is called IAB node. The terminating node of NR backhaul on the network side is called IAB-Host. IAB-Host represents a gNB with additional functionality to support IAB. Backhaul can be done over a single hop or via multiple hops.

[0003] In the IAB topology, topology redundancy is enabled. The purpose of topology redundancy is to achieve robust operation, for example, in the event of backhaul link congestion, and to balance the load across backhaul links. In Release 16 of the 3rd Generation Partnership Project (3GPP) specification, the topology redundancy process within the centralized unit (CU) enables the establishment and release of redundant paths in the IAB topology under the same IAB-host-CU. Inter-host topology adaptation (inter-host TA) is a goal of Release 17. Inter-host topology redundancy is a related feature. Inter-host redundancy is also called inter-CU redundancy. Inter-CU redundancy differs from intra-CU redundancy in that the primary cell group (MCG) link and the secondary cell group (SCG) link belong to different IAB-hosts. However, it is unclear how to support topology redundancy in inter-host new radio dual connectivity. Summary of the invention

[0004] Generally speaking, example embodiments of the present disclosure provide a topology redundancy solution.

[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 a request to a second device for establishing a context of a third device served by the first device; receive the context from the second device; and send the context to the third device for communication between the third device and the first device via a fourth device, the fourth device being managed by 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 a request from a first device to establish a context for a third device served by the first device; establish a context for the third device; and send a context to the first device for communication between the third device and the first device via a fourth device, the fourth device being managed by the second device.

[0007] In a third aspect, a third device is provided. The third 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, enable the third device to: receive a context of the third device from a first device serving the third device, the context being established by a second device; and communicate with the first device via a fourth device using the context information, the fourth device being managed by the second device.

[0008] In a fourth aspect, a method implemented at a device is provided. The method includes: sending a request from a first device to a second device to establish a context for a third device served by the first device; receiving the context from the second device; and sending the context to the third device for communication between the third device and the first device via a fourth device, the fourth device being managed by the second device.

[0009] In a fifth aspect, a method implemented at a device is provided. The method includes: receiving, at a second device, from a first device, a request to establish a context for a third device served by the first device; establishing a context for the third device; and sending the context to the first device for communication between the third device and the first device via a fourth device, the fourth device being managed by 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 context of a third device from a first device, the first device serving the third device, the context being established by a second device; and communicating with the first device via a fourth device using the context information, the fourth device being managed by the second device.

[0011] In a seventh aspect, an apparatus is provided, comprising: a component for sending a request from a first device to a second device for establishing a context for a third device served by the first device; a component for receiving the context from the second device; and a component for sending the context to the third device for communication between the third device and the first device via a fourth device, the fourth device being managed by the second device.

[0012] In an eighth aspect, an apparatus is provided, comprising: a component for receiving, at a second device, a request from a first device for establishing a context for a third device served by the first device; a component for establishing a context for the third device; and a component for sending the context to the first device for communication between the third device and the first device via a fourth device, the fourth device being managed by the second device.

[0013] In a ninth aspect, a device is provided, comprising: a component for receiving a context of a third device from a first device at a third device, the first device serving the third device, the context being established by the second device; and a component for communicating with the first device via a fourth device using the context information, the fourth device being managed by 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 a device 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 a device 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 a device to at least execute the method according to the sixth aspect above.

[0017] It should be understood that the summary is not intended to identify the key or essential features of the embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become readily 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 2 A conventional communication network in which intra-CU DC is implemented is shown;

[0021] Figure 3 A signaling diagram illustrating a topology redundancy process for a conventional communication network is shown;

[0022] Figure 4 shows a signaling diagram illustrating a process for topology redundancy according to some 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 is shown according to some example embodiments of the present disclosure.

[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 this disclosure 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 phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an exemplary embodiment, it is considered to be within the knowledge of those skilled in the art to affect such 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, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element, and similarly, a second element may be referred to as a first element. As used herein, the term "and / or" includes any and all combinations of one or more of the listed terms.

[0033] The terms used herein are for the purpose of describing particular embodiments only and are not intended to limit the example embodiments. As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the terms "include", "comprise", "have", "have", "include" and / or "comprising" when used herein specify the presence of stated 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, more than one, or all of the following:

[0035] (a) only hardware circuit implementation (e.g., only implementation 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) a hardware processor (including a digital signal processor) with software, software and any portion of 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 (e.g., a microprocessor or a portion of a microprocessor) that require software (e.g., firmware) to operate, but where software is not required to operate, the software may not be present.

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

[0041] As used herein, the term "communication network" refers to a network that follows any suitable communication standard, such as a fifth generation (5G) system, long term evolution (LTE), advanced LTE (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 device and the network device in the communication network can be performed according to any suitable generation of communication protocols, including but not limited to the first generation (1G), the second generation (2G), 2.5G, 2.75G, the third generation (3G), the fourth generation (4G), 4.5G, the 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 are of course future types of communication technologies and systems, using which the present disclosure can be implemented. It should not be regarded as limiting the scope of the present invention to the above-mentioned systems.

[0042] As used herein, the term "network device" refers to a node in a communication network via which a terminal device accesses the network and receives services from it. Depending on the terminology and technology applied, a network device may refer to a base station (BS) or an access point (AP), such as a Node B (Node B or NB), an evolved Node B (eNodeB or eNB), a NR next-generation Node B (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, a pico, etc. The RAN split architecture includes a gNB-CU (centralized unit, hosting RRC, SDAP, and PDCP) that controls multiple gNB-DUs (distributed units, hosting RLC, MAC, and PHY).

[0043] The term "terminal device" refers to any terminal device capable of wireless communication. By way of example and not limitation, a terminal device may also be referred to as a communication device, user equipment (UE), subscriber station (SS), portable subscriber 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 endpoint, a mobile station, a laptop embedded device (LEE), a laptop mounted device (LME), a USB dongle, a smart device, a wireless client equipment (CPE), an Internet of Things (IoT) device, a watch or other wearable device, a head mounted display (HMD), a vehicle, a target, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated process chain environments, consumer electronic devices, devices operating 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] Although 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 (such as a cellular phone or a tablet computer or a laptop computer or a desktop computer or a mobile device or a fixed device). The user equipment device may, for example, be appropriately equipped with the corresponding capabilities described in conjunction with the 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 a processor, which is configured to control the user device when installed therein. Examples of such functions include a bootstrap server function and / or a home user server, which may be implemented in a user equipment device by providing the user equipment device with software configured to cause the user equipment device to execute from the perspective of these functions / nodes.

[0045] Figure 1An example communication network 100 in which embodiments of the present disclosure may be implemented is shown. The communication network 100 includes a first device 110, a second device 120, a third device 130, a fourth device 140, a fifth device 150, a sixth device 160, and a seventh device 170. The sixth device 160 is managed by the first device 110 (e.g., at least partially controlled by and / or in operable communication with the first device 110). The fourth device 140 is managed by the second device 120. In some example embodiments, each of the third device 130, the fifth device 150, and the seventh device 170 may be served by the first device 110. In such example embodiments, an F1 interface may be established or established between the third device 130 and the first device 110, between the fifth device 150 and the first device 110, and between the seventh device 170 and the first device 110, respectively.

[0046] It should be understood that although the first device 110 and the sixth device 160 are shown as being implemented on separate entities, the first device 110 and the sixth device 160 may be implemented on a single entity. Similarly, the second device 120 and the fourth device 140 may be implemented on a single entity.

[0047] It should also be understood that the number of the first, second, third, fourth, fifth, sixth, and seventh devices 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 the first, second, third, fourth, fifth, sixth, and seventh devices suitable for implementing the present disclosure.

[0048] The communication in the communication network 100 may be implemented according to any appropriate communication protocol, including but not limited to cellular communication protocols of the first generation (1G), second generation (2G), third generation (3G), fourth generation (4G) and fifth generation (5G), wireless local area network communication protocols such as 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 may 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.

[0049] In some example embodiments, the first device 110 includes a centralized unit (CU) of the first IAB host, the second device 120 includes a CU of the second IAB host, the sixth device 160 includes a distributed unit (DU) of the first IAB host, the fourth device 140 includes a DU of the second IAB host, and each of the third device 130, the fifth device 150, and the seventh device 170 includes an IAB node. Hereinafter, the CU 110 of the first IAB host is also referred to as a first IAB-host-CU 110, the DU 160 of the first IAB host is also referred to as a first IAB-host-DU 160, the CU 120 of the second IAB host is also referred to as a second IAB-host-CU 120, and the DU 140 of the second IAB host is also referred to as a second IAB-host-DU 140. An Xn Application Protocol (XnAP) interface is established between the first device 110 and the second device 120. An F1 application protocol (F1AP) interface is established between a DU (eg, the sixth device 160, the fifth device 150, the third device 130) and a CU (eg, the first device 110). A DU establishes an F1AP interface with only one CU.

[0050] In such an example embodiment, the IAB node 150 is in dual connection (DC) or in inter-host DC with different IAB hosts. In this case, the IAB node 150 has two paths to the first IAB-host-CU 110 via different IAB-host-DUs, and the different IAB-host-DUs are managed by different IAB-host-CUs. In other words, the IAB node 150 has a first path toward the first IAB-host-CU 110 via the first IAB-host-DU 160 and a second path toward the first IAB-host-CU 110 via the second IAB-host-DU 140. The first path can be referred to as a redundant path of the second path, and vice versa.

[0051] In some example embodiments, the third device 130 initiates communication with the first device 110 via the fifth device 150 after the fifth device 150 has communicated with both the first device 110 and the second device 120. In other words, after the fifth device 150 is connected with both the first device 110 and the second device 120, the third device 130 is connected with the first device 110 via the fifth device 150.

[0052] When the third device 130 is connected to the first device 110 via the fifth device 150, the first device 110 sends a request to the second device 120 for establishing a context of the third device 130. Upon receiving the request, the second device 120 establishes a context of the third device 130 and sends the context to the first device 110. Then, the first device 110 sends the context to the third device 130. The third device 130 then communicates with the first device 110 via the fourth device 140 using the context. In this way, topological redundancy of the third device 130 is enabled. In the event of a congestion in the backhaul link of the first path, or in order to balance the load across the backhaul link, the service of the third device 130 can be quickly switched to the second path, and vice versa.

[0053] In other example embodiments, after the third device 130 has communicated with the first device 110 via the fifth device 150, the fifth device 150 becomes in communication with both the first device 110 and the second device 120. In other words, after the third device 130 is connected to the first device 110 via the fifth device 150, the fifth device 150 becomes connected to both the first device 110 and the second device 120. In such example embodiments, when the fifth device 150 becomes connected to both the first device 110 and the second device 120, the first device 110 sends a request to the second device 120 for establishing a context for the third device 130.

[0054] In other example embodiments, the third device 130 has communicated with the first device 110 via the fifth device 150, and the fifth device 150 has communicated with both the first device 110 and the second device 120. The first device 110 determines that a context of the third device 130 needs to be established in the second device 120. The determination may be based on quality, for example, when the link quality of the communication link between the fifth device 150 and the first device 110 is below a threshold. The determination may also be based on a traffic load, for example, when the traffic load of the communication link between the fifth device 150 and the first device 110 is above a threshold. The determination may also be based on a quality of service of a traffic to / from the third device 130, for example, when the quality of service of the communication link between the fifth device 150 and the first device 110 cannot meet the required quality of service of the traffic to / from the third device 130. The determination may also be based on an operator policy or a subscription of a terminal device served by the third device 130.

[0055] As described above, in Release 16, the intra-CU topology redundancy process enables the establishment and release of redundant paths in the IAB topology under the same IAB-Host-CU. Figure 2 An example of a conventional communication network 200 in which intra-CU DC is implemented is shown.

[0056] As shown, the communication network 200 includes an IAB-host-CU 210, a first path IAB-host-DU 220, a second path IAB-host-DU 230, an IAB node 240, a terminal device 250, and an IAB node 260. The first path IAB-host-DU 220 and the second path IAB-host-DU 230 are both managed by the IAB-host-CU 210. The IAB node 240 is served by the IAB-host-CU 210. In such an example embodiment, an F1-C interface is established between the IAB node 240 and the IAB-host-CU 210.

[0057] exist Figure 2 In the embodiment, the IAB node 240 is in the intra-host DC. In this case, the IAB node 240 has two paths to the IAB-host-CU 210 via different IAB-host-DUs, and the different IAB-host-DUs are managed by the same IAB-host-CU. In other words, the IAB node 240 has a first path to the IAB-host-CU 210 via the first path IAB-host-DU 220 and a second path to the IAB-host-CU 210 via the second path IAB-host-DU 230. In this case, the first path is referred to as a redundant path of the second path, and vice versa.

[0058] Figure 3 Shown for Figure 2 An example of a process 300 for establishing a second path in a conventional communication network 200 is shown.

[0059] As shown in the figure, before the second path is established, the IAB node 240 sends uplink user data of the terminal device 250 to the IAB-host-CU 210 via the first path IAB-host-DU 220, and receives downlink user data of the terminal device 250 from the IAB-host-CU 210 via the first path IAB-host-DU220.

[0060] The IAB node 240 sends (301) a measurement report message to the first path IAB-host-DU 220. The measurement report is based on the measurement configuration that the IAB node 240 previously received from the IAB-host-CU 210.

[0061] The first path IAB-host-DU 220 sends (302) a UL RRC MESSAGE TRANSFER message to the IAB-host-CU 210 to transfer the received measurement report.

[0062] The IAB-host-CU 210 sends (303) a UE CONTEXT SETUP REQUEST message to the second path IAB-host-DU 230 to create a UE context for the IAB node 240 and to establish one or more bearers. These bearers can be used by the IAB node 240 for its own signaling and optionally for data traffic.

[0063] The second path IAB-Host-DU 230 responds (304) to the IAB-Host-CU 210 with a UE CONTEXT SETUP RESPONSE message.

[0064] The IAB-host-CU 210 sends (305) a UE CONTEXTMODIFICATION REQUEST message to the first path IAB-host-DU 220, which includes the generated RRCReconfiguration message. The RRCReconfiguration message may include one or more TNL addresses for the IAB node 240, which are anchored at the second path IAB-host-DU 230. The IAB-host-CU 210 may actively obtain these TNL addresses from the second path IAB-host-DU 230. In the case of using IPsec tunnel mode to protect F1 and non-F1 services, the assigned TNL address is an external IP address. If the first path and the second path use the same IAB-host-DU, TNL address assignment is not required.

[0065] The first path IAB-host-DU 220 forwards ( 306 ) the received RRCReconfiguration message to the IAB node 240 .

[0066] The IAB node 240 responds (307) to the first path IAB-Host-DU 220 with an RRCReconfigurationComplete message.

[0067] The first path IAB-host-DU 220 sends (308) a UL RRC MESSAGE TRANSFER message to the IAB-host-CU 210 to transfer the received RRCReconfigurationComplete message.

[0068] A random access procedure is performed (309) at the second path IAB-Host-DU 230.

[0069] The IAB-host-CU 210 configures (310) a backhaul radio link control (RLC) channel and a backhaul adaptation protocol (BAP) layer routing entry on the second path between the IAB node 240 and the second path IAB-host-DU. These configurations can be performed at an earlier stage, for example, immediately after step 303.

[0070] The new TNL address (if any) assigned in steps 305 and 306 is added 311 to the F1-C association of the DU of the IAB node 240 and the IAB-host-CU 210. The IAB-host-CU 210 may configure new UL backhaul information for F1 Application Protocol (F1AP) messages on the second path.

[0071] IAB-host-CU 210 may migrate ( 312 ) the F1-U tunnel it has with IAB node 240 from the first path to the second path via a UE CONTEXT MODIFICATION REQUEST message.

[0072] The IAB node 240 responds to the IAB-host-CU 210 with a UE CONTEXT MODIFICATION RESPONSE message (313).

[0073] In this way, the second path is established. After the second path is established, the IAB node 240 can send uplink user data of the terminal device 250 to the IAB-host-CU 210 via the second path IAB-host-DU 230, and receive downlink user data of the terminal device 250 from the IAB-host-CU 210 via the second path IAB-host-DU 230.

[0074] However, process 300 does not apply to communication network 100 in which inter-CU DC can be implemented.

[0075] In order to at least partially solve the above and other potential problems, an example embodiment of the present disclosure provides a solution for topological redundancy. In this solution, a first device sends a request to a second device for establishing a context of a third device. After receiving the request, the second device establishes a context of the third device and sends the context to the first device. Then, the first device sends the context to the third device. The third device then uses the context to communicate with the first device via a fourth device. In this way, topological redundancy of the third device is achieved.

[0076] The following will refer to Figures 4 to 7 The principles and implementations of the present disclosure are described in detail. Figure 4A signaling diagram illustrating a process 400 for topology redundancy according to some 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, the fourth device 140, the fifth device 150, the sixth device 160 and the seventh device 170 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.

[0077] like Figure 4 As shown, the first device 110 sends (403) to the second device 120 a request for establishing a context for the third device 130. Thus, the second device 120 receives (404) the request from the first device 110.

[0078] In some example embodiments, after the fifth device 150 has communicated with the first device 110 via the sixth device 160 and with the second device 120 via the fourth device 140, the third device 130 initiates communication with the first device 110 via the fifth device 150. In other words, after the fifth device 150 is connected with both the first device 110 and the second device 120 (401), the third device 130 is connected with the first device 110 via the fifth device 150 (402). In such example embodiments, when the third device 130 is connected with the first device 110 via the fifth device 150, the first device 110 sends a request to the second device 120 for establishing a context for the third device 130.

[0079] In other example embodiments, after the third device 130 has communicated with the first device 110 via the fifth device 150, the fifth device 150 becomes in communication with the first device 110 via the sixth device 160, and communicates with the second device 120 via the fourth device 140. In other words, after the third device 130 is connected to the first device 110 via the fifth device 150, the fifth device 150 becomes connected to both the first device 110 and the second device 120. In such an example embodiment, when the fifth device 150 becomes connected to both the first device 110 and the second device 120, the first device 110 recognizes that the fifth device 150 has a descendant node (i.e., the third device 130) that can also benefit from the second path. Therefore, the first device 110 sends a request to the second device 120 for establishing a context for the third device 130.

[0080] In other example embodiments, after the third device 130 has communicated with the first device 110 via the fifth device 150 and the fifth device 150 has communicated with both the first device 110 and the second device 120, the first device 110 sends a request to the second device 120 for establishing a context of the third device 130. The first device 110 determines that a context of the third device 130 needs to be established in the second device 120. The determination may be based on quality, for example, when the link quality of the communication link between the fifth device 150 and the first device 110 is below a threshold. The determination may also be based on a traffic load, for example, when the traffic load of the communication link between the fifth device 150 and the first device 110 is above a threshold. The determination may also be based on a quality of service of a traffic to / from the third device 130, for example, when the quality of service of the communication link between the fifth device 150 and the first device 110 cannot meet the required quality of service of the traffic to / from the third device 130, or when the quality of service of the traffic to / from the third device 130 requires high reliability. The determination may also be based on an operator policy or a subscription of a terminal device served by the third device 130.

[0081] In some example embodiments, the request includes at least one of: an identification (ID) of the third device 130 assigned by the first device 110, information of the fourth device 140, information about a transport layer address to be assigned by the second device 120, or information about traffic of the third device 130 to be routed via the fourth device 140. In some example embodiments, the transport layer address may include an IP address.

[0082] In some example embodiments, the identification of third device 130 assigned by first device 110 may include at least a BAP ID assigned by first device 110, or a master new generation radio access network (M-NG-RAN) node UE XnAP ID, or any other identification that may uniquely identify third device 130 via an Xn interface between first device 110 and second device 120. The M-NG-RAN node UE XnAP ID may uniquely identify third device 130 via an Xn interface within an M-NG-RAN node.

[0083] In some example embodiments, the information of fourth device 140 may identify fourth device 140. That is, fourth device 140 should be the same device that serves fifth device 150. In some example embodiments, the information of fourth device 140 may include an identification of fourth device 140. For example, the identification of fourth device 140 may include at least a BAPID assigned by first device 110, or a BAP ID assigned by second device 120, or a cell identification of a cell in fourth device 140 that serves fifth device 150, or any other identification that may uniquely identify fourth device 140 in second device 120.

[0084] In some example embodiments, the information about the transport layer address to be assigned by second device 120 may include IP address request information of third device 130. For example, the information about the transport layer address may include information received from third device 130 during the RRC IAB other information procedure.

[0085] In some example embodiments, the information about the traffic of third device 130 to be routed via fourth device 140 may include quality of service (QoS) information of F1-C traffic or F1-U traffic of third device 130 to be routed via fourth device 140. In some example embodiments, the information about non-F1-U traffic of third device 130 to be routed via fourth device 140 may include traffic types, for example, UE-associated F1AP traffic, non-UE-associated F1AP traffic, non-F1 traffic, BAP control PDU traffic, and the like.

[0086] In some example embodiments, the second device 120 may determine whether to establish a context for the third device 130 based on the received information (e.g., information about the service of the third device 130). For example, if the second device 120 determines that there are sufficient backhaul resources for the F1-C service or the F1-U service based on the QoS information, the second device 120 may determine to accept the F1 control plane interface (F1-C) service or the F1 user plane interface (F1-U) service. Therefore, the second device 120 may determine to establish a context for the third device 130. On the other hand, if the second device 120 determines that there are not sufficient backhaul resources for the F1-C service or the F1-U service based on the QoS information, the second device 120 may determine not to accept one or more specific types of F1-C services, or all F1-C services, or one or more specific F1-U services, or all F1-U services. Furthermore, the second device 120 may determine not to establish a context for the third device 130, and send a rejection message to the first device 110. This means that the first device 110 cannot configure the third device 130 with the second path.

[0087] In some example embodiments, the third device 130 communicates with the first device 110 via the fifth device 150. In such example embodiments, the request also includes an identification of the fifth device.

[0088] In some example embodiments, second device 120 may configure in fourth device 140 a mapping of traffic of third device 130 to a backhaul radio link control (RLC) channel, and configure in fourth device 140 a routing of the traffic via fourth device 140 based on the information about the traffic. In another embodiment, second device 120 may configure fourth device 140 later, for example, after establishing (405) a context in the second device, or after second device 120 sends (406) a context to first device 110.

[0089] In some example embodiments, the first device 110 may send a request via an XnAP process. The XnAP process may be different from the current XnAP S-NG-RAN node addition preparation process. During the XnAP S-NG-RAN node addition preparation process, RRC-related IEs are exchanged between the master node (MN) and the secondary node (SN), and radio resource configuration is performed in the SN. The XnAP process for sending the request may not require any RRC-related operations of the third device 130 in the second device 120, and may not cause any radio resource configuration of the third device 130 in the second device 120. For example, the second device 120 may not maintain the RRC state or RRC context of the third device 130. Therefore, the context established in the second device 120 (hereinafter also referred to as limited context) is different from the context established in the current XnAP S-NG-RAN node addition preparation process. The XnAP process for sending the request may be a new XnAP process, that is, a modification of the current XnAP process. The XnAP process for sending the request may be non-UE-associated signaling and may be used to request limited context establishment of multiple descendant IAB nodes of the fifth device 150. For example, the first device 110 may send an XnAP message to the second device 120, the XnAP message including a request for establishing a context of the third device 130 and for establishing a context of the seventh device 170.

[0090] Continue to refer Figure 4 , after receiving the request, the second device 120 establishes ( 405 ) a context for the third device 130 .

[0091] In some example embodiments, the established context includes at least one of the following: a BAP ID of the third device 130 assigned by the second device 120, a transport layer address of the third device 130 assigned by the second device 120, a BAP ID of the fourth device 140 assigned by the second device 120, a flow label of the service of the third device 130 assigned by the second device 120, a differentiated services code point (DSCP) or a service class code point of the service of the third device 130 assigned by the second device 120, or a routing ID of the uplink service of the third device 130 assigned by the second device 120, or any other information required to send the service to the third device 130 via the fourth device 140 or to receive the service from the third device 130 via the fourth device 140.

[0092] The second device 120 sends (406) the context to the first device 110. Thus, the first device 110 receives (407) the context from the second device 120. Then, the first device 110 sends (408) the context to the third device 130. It should be understood that the first device 110 may send all or part of the context received as described above to the third device 130. For example, when the first device 110 sends downlink (DL) traffic to the third device 130 via the fourth device 140, the flow label or DSCP may be used only by the first device 110. Accordingly, the third device 130 receives (409) the context.

[0093] In some example embodiments, the first device 110 sends the context to the third device 130 in a radio resource control (RRC) message or an F1 application protocol (F1AP) message. For example, in the case where the context includes a transport layer address of the third device 130 assigned by the second device 120 for the F1-C service, the first device 110 sends the context in an RRC message (e.g., an RRCReconfiguration message) or an F1AP message (e.g., a GNB-CU CONFIGURATION UPDATE message). In the case where the context includes a routing ID for uplink traffic of the third device 130 for the F1-U service, the first device 110 sends the context in the F1AP message. In some example embodiments, the RRC message may not include any access stratum (AS) configuration.

[0094] In some example embodiments, the first device 110 may also configure the third device 130 to use the context in communications between the third device 130 and the first device 110 .

[0095] The third device 130 in turn uses ( 410 ) the context to communicate with the first device 110 via the fourth device 140 .

[0096] According to the present disclosure, topological redundancy of the third device 130 is enabled. In some example embodiments, depending on the context, the F1-C or F1-U traffic of the third device 130 may use a first path routed via the sixth device 160, or a second path routed via the fourth device 140. For example, during the F1AP UE context establishment of the UE connected to the third device 130, the first device 110 may indicate that the traffic for the GTP-U tunnel needs to be routed via the fourth device 140. Therefore, the third device 130 may use the received IP address assigned by the second device 120 for the DL full tunnel endpoint identifier (F-TEID). Therefore, the DL F1-U traffic may be routed to the third device 130 via the fourth device 140. The third device 130 may use the received routing ID and the IP address assigned by the second device 120 for the uplink (UL) traffic to be routed via the fourth device 140.

[0097] After the context is established, the context may be further modified or released. The first device 110 may initiate a modification process, for example, when a new service needs to be routed via the fourth device 140 or an existing service needs to be removed. For example, when the wireless backhaul is loaded and cannot support the service routed via the fourth device 140, the second device 120 may also initiate the modification process. For example, when the third device 130 is disconnected from the fifth device 150, the first device 110 or the second device 120 may start a release process.

[0098] The above steps may also be performed on other descendant nodes of the fifth device 150 (e.g., the seventh device 170). In summary, without the present disclosure, the third device 130 and the seventh device 170 only have contexts (e.g., IP addresses, BAP IDs, routing IDs, etc.) assigned by the first device 110 that are only related to the first path, and can only use the first path. In the event of a problem with the first path, the third device 130 and the seventh device 170 must stop operating. The third device 130 and the seventh device 170 cannot use the second path. This causes serious problems for terminal devices connected to the third device 130 and the seventh device 170.

[0099] With the present disclosure, the third device 130 and the seventh device 170 can benefit from topology redundancy. For example, in the event that there is a problem with the first path (or vice versa), the third device 130 and the seventh device 170 can switch to the second path.

[0100] To better understand the advantages of the present disclosure, reference will be made to Figure 1 and Figure 2 Description Example In this example, the following assumptions are made.

[0101] Reference shows the topological redundancy within the host Figure 2 , the IAB node 240 receives the RRCReconfiguration message including the following information:

[0102] - BAP ID #11 assigned by the IAB host-CU 210;

[0103] - IP address #A11 assigned by the IAB-host-CU 210, and information that the first path IAB-host-DU 220 has BAPID #1;

[0104] -IP address #A12 assigned by the IAB-host-CU 210, and information that the second path IAB-host-DU 230 has BAPID#2.

[0105] When the terminal device 250 is connected to the IAB node 240 and needs to establish a data radio bearer (DRB) and an F1-U tunnel, the DU of the IAB node 240 selects IP address #A11 or #A12. For example, if the IAB-host 1-CU 210 wants to route UL / DL F1-U via the second path IAB-host-DU 230, the DU of the IAB node 240 will provide #A12 to the IAB-host-CU 210 as part of the DL F-TEID.

[0106] Similar to IAB node 240, IAB node 260 receives an RRCReconfiguration message including the following information:

[0107] - BAP ID #21 assigned by the IAB host-CU 210;

[0108] - IP address #A21 assigned by IAB-Host-CU 210, first path IAB-Host

[0109] - DU 220 has information about BAP ID#1 assigned to the IP address;

[0110] - IP address #A22 assigned by the IAB-Host-CU 210, and the second path IAB-Host-DU 230 has information of BAPID#2.

[0111] The IAB node 260 selects IP address #A21 or #A22 for the F1-U DL F-TEID.

[0112] Understandably, Figure 2In the network 200, the IAB node 240 and the IAB node 260 may have a first path routed via the first path IAB-host-DU 220 and a second path routed via the second path IAB-host-DU 230. In the event of a problem with the first path, the IAB nodes 240 and 260 may switch to the second path (or vice versa).

[0113] refer to Figure 1 , the fifth device 150 receives an RRCReconfiguration message including the following information:

[0114] -BAP ID#11 assigned by the first device 110, and BAP ID#20 assigned by the second device 120

[0115] BAP ID#12;

[0116] - IP address #A11 assigned by the first device 110, and information that the sixth device 160 has BAP ID #1;

[0117] - IP address #A12 assigned by the second device 120, and information that the fourth device 140 has BAP ID #2.

[0118] When the UE is connected to the fifth device 150 and needs to establish a DRB / F1-U tunnel, the fifth device 150 selects IP address #A11 or #A12. For example, if the first device 110 wants to route UL / DL F1-U via the fourth device 140, the fifth device 150 will provide #A12 to the first device 110 as part of the DL F-TEID.

[0119] Similar to the fifth device 150, the third device 130 receives the RRCReconfiguration message including the following information:

[0120] - BAP ID #21 assigned by the first device 110 and BAP ID #22 assigned by the second device 120;

[0121] - IP address #A21 assigned by the first device 110, and information that the sixth device 160 has BAP ID #1;

[0122] - IP address #A22 assigned by the second device 120, and information that the fourth device 140 has BAP ID #2.

[0123] The third device 130 selects IP address #A21 or #A22 for the F1-U DL F-TEID.

[0124] In summary, even if the third device 130 is separately connected to the fifth device 150 and communicates only with the first device 110, the second device 120 establishes a context for the third device 130, and the third device 130 receives the context related to the redundant path via the fourth device 140. Therefore, the redundant path can be enabled for the single-connected third device 130. It should be noted that the third device 130 may not need to know whether the sixth device 160 and the fourth device 140 belong to the same or different host-CUs.

[0125] Understandably, Figure 1 In the network 100 in FIG. 1 , the fifth device 150 has not only a context associated with the first path assigned by the first device 110 (e.g., BAP ID#11, routing ID, IP address, etc.), but also a context associated with the second path assigned by the second device 120 (e.g., BAP ID#12, routing ID, IP address, etc.). Similarly, the third device 130 has not only a context associated with the first path assigned by the first device 110 (e.g., BAP ID#21, routing ID, IP address, etc.), but also a context associated with the second path assigned by the second device 120 (e.g., BAP ID#22, routing ID, IP address, etc.). In the event that one path (e.g., the first path) has a problem, the fifth device 150 and the third device 130 do not have to stop operating. Instead, the fifth device 150 and the third device 130 can switch to another path (e.g., the second path) and use the other path.

[0126] Figure 5 FIG. 5 is a flowchart showing an example method 500 implemented at a device according to some example embodiments of the present disclosure. For the purpose of discussion, reference will be made to Figure 1 The method 500 is described from the perspective of the first device 110. It should be understood that the method 500 may also be implemented in Figure 1 The method is implemented at the second device 120 in the embodiment.

[0127] In block 510 , the first device 110 sends a request to the second device 120 to establish a context for the third device 130 served by the first device 110 .

[0128] At block 520 , the first device 110 receives a context from the second device 120 .

[0129] At block 530 , the first device 110 sends the context to the third device 130 for communication between the third device 130 and the first device 110 via the fourth device 140 . The fourth device 140 is managed by the second device 120 .

[0130] In some example embodiments, the context includes at least one of: a backhaul adaptation protocol address of the third device assigned by the second device, a transport layer address of the third device assigned by the second device, a backhaul adaptation protocol address of a fourth device assigned by the second device, a flow label for a service of the third device assigned by the second device, a differentiated services code point or a service class code point for a service of the third device assigned by the second device, or a routing identifier for an uplink service of the third device assigned by the second device.

[0131] In some example embodiments, sending the context to the third device includes sending the context in a radio resource control message or an F1 application protocol message; and the method 500 further includes configuring the third device to use the context in communications between the third device and the first device.

[0132] In some example embodiments, the request includes at least one of: an identification of a third device assigned by the first device, information of a fourth device, information about a transport layer address to be assigned by the second device, or information about traffic of the third device to be routed via the fourth device.

[0133] In some example embodiments, the third device communicates with the first device via the fifth device.In such example embodiments, the request also includes an identification of the fifth device.

[0134] In some example embodiments, sending the request includes: if it is determined that the fifth device has communicated with the first device and the second device, then when the third device initiates communication with the first device via the fifth device, sending the request to the second device; based on determining that the fifth device changes to communicate with both the first device and the second device after the third device has communicated with the first device via the fifth device, sending the request to the second device; or if it is determined that the service between the first device and the third device needs to be offloaded via the fourth device, then after the fifth device has communicated with the first device and the second device, and the third device has communicated with the first device via the fifth device, sending the request to the second device.

[0135] In some example embodiments, the first device includes a centralized unit of a first access backhaul integrated host, the second device includes a centralized unit of a second access backhaul integrated host, the third device includes a first access backhaul integrated node, and the fourth device includes a distributed unit of a second access backhaul integrated host.

[0136] In some example embodiments, the fifth device comprises an access backhaul integrated node.

[0137] Figure 6 FIG. 6 is a flowchart showing an example method 600 implemented at a device according to some example embodiments of the present disclosure. For the purpose of discussion, reference will be made to Figure 1 The method 600 is described from the perspective of the second device 120. It should be understood that the method 600 may also be implemented in Figure 1 The method is implemented at the first device 110 in the embodiment.

[0138] In block 610 , the second device 120 receives a request from the first device 110 to establish a context for the third device 130 served by the first device 110 .

[0139] At block 620 , the second device 120 establishes a context for the third device 130 .

[0140] At block 630 , the second device 120 sends the context to the first device 110 for communication between the third device 130 and the first device 110 via the fourth device 140 . The fourth device 140 is managed by the second device 120 .

[0141] In some example embodiments, the context includes at least one of the following: a backhaul adaptation protocol address of the third device assigned by the second device, a transport layer address of the third device assigned by the second device, a backhaul adaptation protocol address of a fourth device assigned by the second device, a flow label for a service of the third device assigned by the second device, a differentiated services code point or a service class code point for a service of the third device assigned by the second device, or a routing identifier for an uplink service of the third device assigned by the second device.

[0142] In some example embodiments, the request includes at least one of: an identification of a third device assigned by the first device, information of a fourth device, information about a transport layer address to be assigned by the second device, or information about traffic of the third device to be routed via the fourth device.

[0143] In some example embodiments, establishing the context of the third device includes: if it is determined based on the information about the service that there are backhaul resources for the service, establishing the context of the third device.

[0144] In some example embodiments, the method 600 further comprises: configuring, in the fourth device, mapping of the service to the backhaul radio link control channel based on the information about the service; and configuring, in the fourth device, routing of the service via the fourth device based on the information about the service.

[0145] In some example embodiments, the third device communicates with the first device via the fifth device.In such example embodiments, the request also includes an identification of the fifth device.

[0146] In some example embodiments, the first device includes a centralized unit of a first access backhaul integrated host, the second device includes a centralized unit of a second access backhaul integrated host, the third device includes a first access backhaul integrated node, and the fourth device includes a distributed unit of a second access backhaul integrated host.

[0147] In some example embodiments, an apparatus capable of performing any of the methods in method 500 (e.g., first device 110) may include a component for performing 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.

[0148] In some example embodiments, the apparatus includes components for sending a request from a first device to a second device to establish a context for a third device served by the first device; components for receiving the context from the second device; and components for sending the context to the third device for communication between the third device and the first device via a fourth device, the fourth device being managed by the second device.

[0149] In some example embodiments, the context includes at least one of the following: a backhaul adaptation protocol address of the third device assigned by the second device, a transport layer address of the third device assigned by the second device, a backhaul adaptation protocol address of a fourth device assigned by the second device, a flow label for a service of the third device assigned by the second device, a differentiated services code point or a service class code point for a service of the third device assigned by the second device, or a routing identifier for an uplink service of the third device assigned by the second device.

[0150] In some example embodiments, the means for sending the context to the third device includes: means for sending the context in a radio resource control message or an F1 application protocol message; and the apparatus further includes means for configuring the third device to use the context in communications between the third device and the first device.

[0151] In some example embodiments, the request includes at least one of: an identification of a third device assigned by the first device, information of a fourth device, information about a transport layer address to be assigned by the second device, or information about a third device to be routed via the fourth device.

[0152] In some example embodiments, the third device communicates with the first device via the fifth device.In such example embodiments, the request also includes an identification of the fifth device.

[0153] In some example embodiments, the apparatus for sending the request includes: a component for sending a request to the second device when the third device initiates communication with the first device via the fifth device if it is determined that the fifth device has communicated with the first device and the second device; a component for sending a request to the second device if it is determined that the fifth device changes to communicate with both the first device and the second device after the third device has communicated with the first device via the fifth device; or a component for sending a request to the second device after the fifth device has communicated with the first device and the second device, and the third device has communicated with the first device via the fifth device, if it is determined that the service between the first device and the third device needs to be offloaded via the fourth device.

[0154] In some example embodiments, the first device includes a centralized unit of a first access backhaul integrated host, the second device includes a centralized unit of a second access backhaul integrated host, the third device includes a first access backhaul integrated node, and the fourth device includes a distributed unit of a second access backhaul integrated host.

[0155] In some example embodiments, the fifth device comprises an access backhaul integrated node.

[0156] In some example embodiments, an apparatus capable of performing any of the methods in method 600 (e.g., second device 120) may include a component for performing 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.

[0157] In some example embodiments, the apparatus includes components for receiving, at a second device, from a first device a request to establish a context for a third device served by the first device; components for establishing a context for the third device; and components for sending the context to the first device for communication between the third device and the first device via a fourth device, the fourth device being managed by the second device.

[0158] In some example embodiments, the context includes at least one of the following: a backhaul adaptation protocol address of the third device assigned by the second device, a transport layer address of the third device assigned by the second device, a backhaul adaptation protocol address of a fourth device assigned by the second device, a flow label for a service of the third device assigned by the second device, a differentiated services code point or a service class code point for a service of the third device assigned by the second device, or a routing identifier for an uplink service of the third device assigned by the second device.

[0159] In some example embodiments, the request includes at least one of: an identification of a third device assigned by the first device, information of a fourth device, information about a transport layer address to be assigned by the second device, or information about traffic of the third device to be routed via the fourth device.

[0160] In some example embodiments, the means for establishing the context of the third device includes means for establishing the context of the third device if it is determined based on the information about the service that there are backhaul resources for the service.

[0161] In some example embodiments, the apparatus further comprises: means for configuring, in the fourth device, mapping of the service to the backhaul radio link control channel based on the information about the service; and means for configuring, in the fourth device, routing of the service via the fourth device based on the information about the service.

[0162] In some example embodiments, the third device communicates with the first device via the fifth device.In such example embodiments, the request also includes an identification of the fifth device.

[0163] In some example embodiments, the first device includes a centralized unit of a first access backhaul integrated host, the second device includes a centralized unit of a second access backhaul integrated host, the third device includes a first access backhaul integrated node, and the fourth device includes a distributed unit of a second access backhaul integrated host.

[0164] Figure 7 FIG. 7 is a flowchart showing an example method 700 implemented at a device according to some example embodiments of the present disclosure. For the purpose of discussion, reference will be made to Figure 1 The method 700 is described from the perspective of the third device 130. It should be understood that the method 700 may also be implemented in Figure 1 The seventh device 170 is implemented in.

[0165] In block 710 , the third device 130 receives a context of the third device 130 from the first device 110 serving the third device 130 . The context is established by the second device 120 .

[0166] At block 720 , the third device 130 uses the context information in communicating with the first device via a fourth device, which is managed by the second device.

[0167] In some example embodiments, the context includes at least one of the following: a backhaul adaptation protocol address of the third device assigned by the second device, a transport layer address of the third device assigned by the second device, a backhaul adaptation protocol address of a fourth device assigned by the second device, a flow label for a service of the third device assigned by the second device, a differentiated services code point or a service class code point for a service of the third device assigned by the second device, or a routing identifier for an uplink service of the third device assigned by the second device.

[0168] In some example embodiments, receiving the context comprises receiving the context in a radio resource control message or an F1 application protocol message.

[0169] In some example embodiments, the third device communicates with the first device via the fifth device.

[0170] In some example embodiments, the first device includes a centralized unit of a first access backhaul integrated host, the second device includes a centralized unit of a second access backhaul integrated host, the third device includes a first access backhaul integrated node, and the fourth device includes a distributed unit of a second access backhaul integrated host.

[0171] In some example embodiments, the fifth device comprises an access backhaul integrated node.

[0172] In some example embodiments, an apparatus capable of executing any method 700 (e.g., third device 130) may include a component for executing each step of method 700. The component may be implemented in any suitable form. For example, the component may be implemented in a circuit or a software module.

[0173] In some example embodiments, the apparatus includes a component for receiving, at a third device, a context of a third device from a first device, the first device serving the third device, the context being established by the second device; and a component for communicating with the first device via a fourth device using the context information, the fourth device being managed by the second device.

[0174] In some example embodiments, the context includes at least one of the following: a backhaul adaptation protocol address of the third device assigned by the second device, a transport layer address of the third device assigned by the second device, a backhaul adaptation protocol address of a fourth device assigned by the second device, a flow label for a service of the third device assigned by the second device, a differentiated services code point or a service class code point for a service of the third device assigned by the second device, or a routing identifier for an uplink service of the third device assigned by the second device.

[0175] In some example embodiments, means for receiving the context comprises means for receiving the context in a radio resource control message or an F1 application protocol message.

[0176] In some example embodiments, the third device communicates with the first device via the fifth device.

[0177] In some example embodiments, the first device includes a centralized unit of a first access backhaul integrated host, the second device includes a centralized unit of a second access backhaul integrated host, the third device includes a first access backhaul integrated node, and the fourth device includes a distributed unit of a second access backhaul integrated host.

[0178] In some example embodiments, the fifth device comprises an access backhaul integrated node.

[0179] Figure 8 800 is a simplified block diagram of a device 800 suitable for implementing an embodiment of the present disclosure. The device 800 may be provided to implement a communication device, such as the first device 110, the second device 120, or the third device 130. As shown, 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.

[0180] 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.

[0181] Processor 810 may be of any type suitable for the local technology network and may include one or more of the following: as non-limiting examples, 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 that synchronizes a main processor.

[0182] 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 disk, compact disk (CD), digital video disk (DVD), 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.

[0183] Computer program 830 includes computer executable instructions executed by associated processor 810. Program 830 may be stored in ROM 820. Processor 810 may perform any suitable actions and processes by loading program 830 into RAM 822.

[0184] The embodiments of the present disclosure can be implemented by means of program 830, so that the device 800 can execute the following steps: Figures 5 to 7 Any process of the present disclosure discussed. The embodiments of the present disclosure may also be implemented by hardware or a combination of software and hardware.

[0185] 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., in the memory 820) or in other storage devices accessible by 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.

[0186] It should be understood that future networks may utilize network function virtualization (NFV), which is a network architecture concept that proposes virtualizing network node functions into "building blocks" or entities that can be operationally connected or linked together to provide services. A virtualized network function (VNF) may include one or more virtual machines that use standard or general-purpose servers rather than custom hardware to run computer program code. Cloud computing or data storage may also be used. In radio communications, this may mean node operations to be performed at least in part in a central / centralized unit CU (e.g., a server, host, or node) that is operably coupled to a distributed unit DU (e.g., a radio head / node). Node operations may also be distributed among multiple servers, nodes, or hosts. It should also be understood that the assignment of labor between core network operations and base station operations may vary depending on the implementation.

[0187] In one embodiment, the server can generate a virtual network through which the server communicates with the distributed units. In general, virtual networking can involve the process of combining hardware and software network resources and network functions into a single software-based management entity (virtual network). Such a virtual network can provide a flexible distribution of operations between servers and wireless heads / nodes. In fact, any digital signal processing task can be performed in the CU or DU, and the boundaries of transferring responsibilities between the CU and DU can be selected based on the implementation.

[0188] Thus, in one embodiment, a CU-DU architecture is implemented. In this case, the device 800 may be included in a central unit (e.g., a control unit, an edge cloud server, a server) that is operably coupled (e.g., via a wireless or wired network) to a distributed unit (e.g., a remote radio head / node). That is, the central unit (e.g., an edge cloud server) and the distributed units may be independent devices that communicate with each other via a radio path or via a wired connection. Alternatively, they may be in the same entity that communicates via a wired connection, etc. The edge cloud or edge cloud server may serve multiple distributed units or radio access networks. In one embodiment, at least some of the processes may be performed by the central unit. In another embodiment, the device 800 may alternatively be included in a distributed unit, and at least some of the processes may be performed by the distributed unit.

[0189] In one embodiment, the execution of at least some functions of the device 800 can be shared between two physically separate devices (DU and CU) that form an operational entity. Therefore, it can be seen that the apparatus describes an operational entity comprising one or more physically separate devices for performing at least some of the described processes. In one embodiment, such a CU-DU architecture can provide a flexible distribution of operations between the CU and the DU. In fact, any digital signal processing task can be performed in the CU or the DU, and the boundaries for transferring responsibilities between the CU and the DU can be selected based on the implementation. In one embodiment, the device 800 controls the execution of the process regardless of the location of the device and regardless of where the process / function is executed.

[0190] 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 embodiments of the present disclosure are shown and described as block diagrams, flow charts, or using some other graphical representations, it should be understood that the blocks, devices, systems, techniques, or methods described herein may be implemented in hardware, software, firmware, dedicated circuits or logic, general hardware or controllers or other computing devices, or some combination thereof, as non-limiting examples.

[0191] 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 a program module executed in a device on a target real or virtual processor to perform the above referenced Figures 5 to 7The method 500, 600 or 700 described. In general, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The functions of program modules can be combined or separated between program modules as needed in various embodiments. The machine executable instructions of program modules can be executed in local or distributed devices. In distributed devices, program modules can be located in local and remote storage media.

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

[0193] 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 various processes and operations as described above. Examples of carriers include signals, computer readable media, etc.

[0194] 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, an electrical, magnetic, optical, electromagnetic, infrared or semiconductor system, apparatus or device, or any suitable combination of the foregoing. More specific examples of computer readable storage media would include an electrical connection having one or more conductors, a portable computer 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 foregoing.

[0195] In addition, although operations are described in a particular order, this should not be understood as requiring the specific order shown or to perform these operations in sequence, or to perform all the operations shown, to achieve 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 should be interpreted as descriptions of features peculiar to a particular embodiment. Certain features described in the context of a separate embodiment may also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment may also be implemented in multiple embodiments individually or in any suitable sub-combination.

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

Claims

1. A first device for communication, 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 a request to a second device for information related to a third device served by the first device; receiving the information from the second device; as well as sending the information to the third device for communication between the third device and the first device via a fourth device, the fourth device being managed by the second device; The information includes at least one of the following: a backhaul adaptation protocol address of the third device assigned by the second device, a transport layer address of the third device assigned by the second device, a backhaul adaptation protocol address of the fourth device assigned by the second device, a flow label for a service of the third device assigned by the second device, a differentiated services code point or a class of service code point assigned by the second device for a service of the third device, or a routing identifier assigned by the second device for uplink traffic of the third device; The first device includes a centralized unit of a first access and backhaul integrated host, the second device includes a centralized unit of a second access and backhaul integrated host, the third device includes a first access and backhaul integrated node, and the fourth device includes a distributed unit of the second access and backhaul integrated host.

2. The first device according to claim 1, wherein the first device is caused to send the information to the third device by: sending the information in a radio resource control message or an F1 application protocol message; and Wherein the first device is further caused to configure the third device to use the information in the communication between the third device and the first device.

3. The first device according to claim 1, wherein the request comprises at least one of the following: an identification of the third device assigned by the first device, information of the fourth device, information about a transport layer address to be assigned by the second device, or Information about traffic of the third device to be routed via the fourth device. The first device of claim 1 , wherein the third device communicates with the first device via a fifth device. The first device of claim 4 , wherein the request further comprises an identification of the fifth device.

6. The first device of claim 4, wherein the first device is caused to send the request to the second device by: If it is determined that the fifth device has communicated with both the first device and the second device, sending the request to the second device when the third device initiates communication with the first device via the fifth device; If it is determined that the fifth device becomes in communication with both the first device and the second device after the third device has communicated with the first device via the fifth device, sending the request to the second device; or If it is determined that the traffic between the first device and the third device needs to be offloaded via the fourth device, the request is sent to the second device after the fifth device has communicated with both the first device and the second device and the third device has communicated with the first device via the fifth device.

7. A second device for communication, 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, from a first device, a request for information related to a third device served by the first device; determining the information of the third device; as well as sending the information to the first device for communication between the third device and the first device via a fourth device, the fourth device being managed by the second device; The information includes at least one of the following: a backhaul adaptation protocol address of the third device assigned by the second device, a transport layer address of the third device assigned by the second device, a backhaul adaptation protocol address of the fourth device assigned by the second device, a flow label for a service of the third device assigned by the second device, a differentiated services code point or a class of service code point assigned by the second device for a service of the third device, or a routing identifier assigned by the second device for uplink traffic of the third device; The first device includes a centralized unit of a first access and backhaul integrated host, the second device includes a centralized unit of a second access and backhaul integrated host, the third device includes a first access and backhaul integrated node, and the fourth device includes a distributed unit of the second access and backhaul integrated host.

8. The second device according to claim 7, wherein the request comprises at least one of the following: an identification of the third device assigned by the first device, information of the fourth device, information about a transport layer address to be assigned by the second device, or Information about traffic of the third device to be routed via the fourth device.

9. The second device according to claim 8, wherein the second device is caused to determine the information of the third device by: If it is determined based on the information about the service that backhaul resources exist for the service, the information of the third device is determined.

10. The second device according to claim 8, wherein the second device is further configured to: Based on the information about the service, configuring, in the fourth device, mapping of the service to a backhaul radio link control channel; and Based on the information about the service, routing of the service via the fourth device is configured in the fourth device. The second device of claim 7 , wherein the third device communicates with the first device via a fifth device.

12. The second device of claim 11, wherein the request further comprises an identification of the fifth device.

13. A third device for communication, 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 third device to: receiving information related to the third device from a first device serving the third device, the information being determined by a second device; and using the information in communicating with the first device via a fourth device, the fourth device being managed by the second device; The information includes at least one of the following: a backhaul adaptation protocol address of the third device assigned by the second device, a transport layer address of the third device assigned by the second device, a backhaul adaptation protocol address of the fourth device assigned by the second device, a flow label for a service of the third device assigned by the second device, a differentiated services code point or a class of service code point assigned by the second device for a service of the third device, or a routing identifier assigned by the second device for uplink traffic of the third device; The first device includes a centralized unit of a first access and backhaul integrated host, the second device includes a centralized unit of a second access and backhaul integrated host, the third device includes a first access and backhaul integrated node, and the fourth device includes a distributed unit of the second access and backhaul integrated host.

14. The third device according to claim 13, wherein the third device is caused to receive the information by: The information is received in a radio resource control message or an F1 application protocol message.

15. The third device of claim 13, wherein the third device communicates with the first device via a fifth device.

Images