Interactions between ORAN and INCF framework

Abstract

Example embodiments of the present disclosure provide a solution for enhancing interactions between open radio access network (ORAN) and integration of network and compute function (INCF) framework. In an example method, a first device including at least a service management and orchestration (SMO) or a non-real time (non-RT) radio access network (RAN) intelligent controller (non-RT RIC) determines a change in a RAN resource pool. Then, the first device transmits, to a second device including a first network function for integration of network and compute, a first notification message for notifying the change in the RAN resource pool. Based on the change in the RAN resource pool, the second device then determines an adjustment of a compute resource pool.

Description

INTERACTIONS BETWEEN ORAN AND INCF FRAMEWORKFIELD

[0001] Various example embodiments relate to the field of communication, and in particular, to devices, methods, apparatuses, and a computer readable medium for enhancing interactions between open radio access network (ORAN) and integration of network and compute function (INCF) framework.BACKGROUND

[0002] A communication network can be seen as a facility that enables communications between two or more communication devices, or provides communication devices access to a data network. A mobile or wireless communication network is one example of a communication network.

[0003] Such communication networks operate in accordance with standards, such as those promulgated by 3GPP (Third Generation Partnership Project) or ETSI (European Telecommunications Standards Institute) . Examples of such standards include the so-called 5G (5th Generation) standard or other standards promulgated by 3GPP.SUMMARY

[0004] In general, example embodiments of the present disclosure provide a solution for communication, especially for enhancing interactions between ORAN and INCF framework. With this solution, dynamic, fine-grained, and optimized provisioning of end-to-end network and compute resources can be achieved, fulfilling application-specific requirements, especially the quality of experience (QoE) , under dynamic condition changes such as changing RAN environments.

[0005] In a first aspect, there is provided a first device including at least a service management and orchestration (SMO) or a non-real time (non-RT) radio access network (RAN) intelligent controller (non-RT RIC) . The first device comprises at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the first device at least to: determine a change in a RAN resource pool; and transmit, to a second device including a first network function for integration of network and compute, a first notification message for notifying the change in the RAN resource pool.

[0006] In a second aspect, there is provided a second device including a first network function for integration of network and compute. The second device comprises at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the second device at least to: receive, from a first device including at least a service management and orchestration (SMO) or a non-real time RAN intelligent controller (non-RT RIC) , a first notification message for notifying a change in a RAN resource pool; and determine an adjustment of a compute resource pool based on the change in the RAN resource pool.

[0007] In a third aspect, there is provided a third device including a near-real time radio access network (RAN) intelligent controller (near-RT RIC) . The third device comprises at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the third device at least to: determine a change in at least one near-RT RIC related RAN resource; and transmit, to a fourth device including a second network function for integration of network and compute, a third notification message for notifying the change in the at least one near-RT RIC related RAN resource.

[0008] In a fourth aspect, there is provided a fourth device including a second network function for integration of network and compute. The fourth device comprises at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the fourth device at least to: receive, from a third device including a near real time (near-RT) radio access network (RAN) intelligent controller (near-RT RIC) , a third notification message for notifying a change in at least one near-RT RIC related RAN resource; determine a local end-to-end (E2E) application instance solution for a terminal device associated with the change in the at least one near-RT RIC related RAN resource; and perform a deployment of the local E2E application instance solution for the terminal device.

[0009] In a fifth aspect, there is provided a third device including an xApp running on a near-real time radio access network (RAN) intelligent controller (near-RT RIC) . The third device comprises at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the third device at least to: determine a change in at least one near RT RIC related RAN resource; and transmit, to a fifth device including an edge application server (EAS) , a fourth notification message for notifying the change in the at least one near RT RIC related RAN resource.

[0010] In a sixth aspect, there is provided a fifth device including an edge application server (EAS) . The fifth device comprises at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the fifth device at least to:receive, from a third device including an xApp running on a near-real time radio access network (RAN) intelligent controller (near-RT RIC) , a fourth notification message for notifying a change in at least one near RT RIC related RAN resource; and determine to perform an adjustment of at least one radio link quality of service (QoS) parameter based on the change in the at least one near RT RIC related RAN resource.

[0011] In a seven aspect, there is provided a method. The method comprises: determining, at a first device including at least a service management orchestration (SMO) or a non-real time (non-RT) radio access network (RAN) intelligent controller (non-RT RIC) , a change in a RAN resource pool; and transmitting, to a second device including a first network function for integration of network and compute, a first notification message for notifying the change in the RAN resource pool.

[0012] In an eighth aspect, there is provided a method. The method comprises: receiving, at a second device including a first network function for integration of network and compute and from a first device including at least a service management and orchestration (SMO) or a non-real time RAN intelligent controller (non-RT RIC) , a first notification message for notifying a change in a RAN resource pool; and determining an adjustment of a compute resource pool based on the change in the RAN resource pool.

[0013] In a ninth aspect, there is provided a method. The method comprises: determining, at a third device including a near-real time radio access network (RAN) intelligent controller (near-RT RIC) , a change in at least one near-RT RIC related RAN resource; and transmitting, to a fourth device including a second network function for integration of network and compute, a third notification message for notifying the change in the at least one near-RT RIC related RAN resource.

[0014] In a tenth aspect, there is provided a method. The method comprises: receiving, at a fourth device including a second network function for integration of network and compute and from a third device including a near real time (near-RT) radio access network (RAN) intelligent controller (near-RT RIC) , a third notification message for notifying a change in at least one near-RT RIC related RAN resource; determining a local end-to-end (E2E) application instance solution for a terminal device associated with the change in the at least one near-RT RIC related RAN resource; and performing a deployment of the local E2E application instance solution for the terminal device.

[0015] In an eleventh aspect, there is provided a method. The method comprises: determining, at a third device including an xApp running on a near-real time radio access network (RAN) intelligent controller (near-RT RIC) , a change in at least one near RT RIC related RAN resource; and transmitting, to a fifth device including an edge application server (EAS) , a fourth notification message for notifying the change in the at least one near RT RIC related RAN resource.

[0016] In a twelfth aspect, there is provided a method. The method comprises: receiving, at a fifth device including an edge application server (EAS) and from a third device including an xApp running on a near-real time radio access network (RAN) intelligent controller (near-RT RIC) , a fourth notification message for notifying a change in at least one near RT RIC related RAN resource; and determining to perform an adjustment of at least one radio link quality of service (QoS) parameter based on the change in the at least one near RT RIC related RAN resource.

[0017] In a thirteenth aspect, there is provided an apparatus. The apparatus comprises: means for determining a change in a RAN resource pool; and means for transmitting, to a second device including a first network function for integration of network and compute, a first notification message for notifying the change in the RAN resource pool.

[0018] In a fourteenth aspect, there is provided an apparatus. The apparatus comprises: means for receiving, from a first device including at least a service management and orchestration (SMO) or a non-real time RAN intelligent controller (non-RT RIC) , a first notification message for notifying a change in a RAN resource pool; and means for determining an adjustment of a compute resource pool based on the change in the RAN resource pool.

[0019] In a fifteenth aspect, there is provided an apparatus. The apparatus comprises: means for determining a change in at least one near-RT RIC related RAN resource; and means for transmitting, to a fourth device including a second network function for integration of network and compute, a third notification message for notifying the change in the at least one near-RT RIC related RAN resource.

[0020] In a sixteenth aspect, there is provided an apparatus. The apparatus comprises: means for receiving, from a third device including a near real time (near-RT) radio access network (RAN) intelligent controller (near-RT RIC) , a third notification message for notifying a change in at least one near-RT RIC related RAN resource; means for determining a local end-to-end (E2E) application instance solution for a terminal device associated with the change in the at least one near-RT RIC related RAN resource; and means for performing a deployment of the local E2E application instance solution for the terminal device.

[0021] In a seventeenth aspect, there is provided an apparatus. The apparatus comprises: means for determining a change in at least one near RT RIC related RAN resource; and means for transmitting, to a fifth device including an edge application server (EAS) , a fourth notification message for notifying the change in the at least one near RT RIC related RAN resource.

[0022] In an eighteenth aspect, there is provided an apparatus. The apparatus comprises: means for receiving, from a third device including an xApp running on a near-real time radio access network (RAN) intelligent controller (near-RT RIC) , a fourth notification message for notifying a change in at least one near RT RIC related RAN resource; and means for determining to perform an adjustment of at least one radio link quality of service (QoS) parameter based on the change in the at least one near RT RIC related RAN resource.

[0023] In a nineteenth aspect, there is provided a computer readable medium comprising program instructions for causing an apparatus to perform at least method of the above third aspect or fourth aspect.

[0024] In a twentieth aspect, there is provided a computer program comprising instructions, which, when executed by an apparatus, cause the apparatus to perform at least the method of the above third aspect or fourth aspect.

[0025] In a twenty-first aspect, there is provided a first device including at least a service management and orchestration (SMO) or a non-real time (non-RT) radio access network (RAN) intelligent controller (non-RT RIC) . The first device comprises: determining circuitry configured to determine a change in a RAN resource pool; and transmitting circuitry configured to transmit, to a second device including a first network function for integration of network and compute, a first notification message for notifying the change in the RAN resource pool.

[0026] In a twenty-second aspect, there is provided a second device including a first network function for integration of network and compute. The second device comprises: receiving circuitry configured to receive, from a first device including at least a service management and orchestration (SMO) or a non-real time RAN intelligent controller (non-RT RIC) , a first notification message for notifying a change in a RAN resource pool; and determining circuitry configured to determine an adjustment of a compute resource pool based on the change in the RAN resource pool.

[0027] In a twenty-third aspect, there is provided a third device including a near-real time radio access network (RAN) intelligent controller (near-RT RIC) . The third device comprises: determining circuitry configured to determine a change in at least one near-RT RIC related RAN resource; and transmitting circuitry configured to transmit, to a fourth device including a second network function for integration of network and compute, a third notification message for notifying the change in the at least one near-RT RIC related RAN resource.

[0028] In a twenty-fourth aspect, there is provided a fourth device including a second network function for integration of network and compute. The fourth device comprises: receiving circuitry configured to receive, from a third device including a near real time (near-RT) radio access network (RAN) intelligent controller (near-RT RIC) , a third notification message for notifying a change in at least one near-RT RIC related RAN resource; determining circuitry configured to determine a local end-to-end (E2E) application instance solution for a terminal device associated with the change in the at least one near-RT RIC related RAN resource; and performing circuitry configured to perform a deployment of the local E2E application instance solution for the terminal device.

[0029] In a twenty-fifth aspect, there is provided a third device including an xApp running on a near-real time radio access network (RAN) intelligent controller (near-RT RIC) . The third device comprises: determining circuitry configured to determine a change in at least one near RT RIC related RAN resource; and transmitting circuitry configured to transmit, to a fifth device including an edge application server (EAS) , a fourth notification message for notifying the change in the at least one near RT RIC related RAN resource.

[0030] In a twenty-sixth aspect, there is provided a fifth device including an edge application server (EAS) . The fifth device comprises: receiving circuitry configured to receive, from a third device including an xApp running on a near-real time radio access network (RAN) intelligent controller (near-RT RIC) , a fourth notification message for notifying a change in at least one near RT RIC related RAN resource; and determining circuitry configured to determine to perform an adjustment of at least one radio link quality of service (QoS) parameter based on the change in the at least one near RT RIC related RAN resource.

[0031] It is to be understood that the summary section is not intended to identify key or essential features of 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 easily comprehensible through the following description.BRIEF DESCRIPTION OF THE DRAWINGS

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

[0033] FIG. 1 illustrates an example communication network in which embodiments of the present disclosure may be implemented;

[0034] FIG. 2 illustrates a flowchart illustrating an example process for enhancing interactions between ORAN and INCF framework according to some embodiments of the present disclosure;

[0035] FIG. 3 illustrates a flowchart illustrating another example process for enhancing interactions between ORAN and INCF framework according to some embodiments of the present disclosure;

[0036] FIG. 4 illustrates a flowchart illustrating another example process for enhancing interactions between ORAN and INCF framework according to some embodiments of the present disclosure;

[0037] FIG. 5 illustrates an overview of the control components and the involved ORAN interfaces in the network architecture according to some example embodiments of the present disclosure;

[0038] FIG. 6 illustrates a schematic diagram of partitioning, alignment, and assignment of control components based on specific requirements for scalability and dynamicity according to some example embodiments of the present disclosure;

[0039] FIG. 7 illustrates a signaling flow for a first resource management loop according to some embodiments of the present disclosure;

[0040] FIG. 8 illustrates another signaling flow for a first resource management according to some embodiments of the present disclosure;

[0041] FIG. 9 illustrates a signaling flow for a second resource management loop according to some embodiments of the present disclosure;

[0042] FIG. 10 illustrates a signaling flow for a third resource management loop according to some embodiments of the present disclosure;

[0043] FIG. 11 illustrates an overview of the interaction between three resource management loops according to some embodiments of the present disclosure;

[0044] FIG. 12 illustrates a flowchart of an example method implemented at a first device according to some embodiments of the present disclosure;

[0045] FIG. 13 illustrates a flowchart of an example method implemented at a second device according to some embodiments of the present disclosure;

[0046] FIG. 14 illustrates a flowchart of an example method implemented at a third device according to some embodiments of the present disclosure;

[0047] FIG. 15 illustrates a flowchart of an example method implemented at a fourth device according to some embodiments of the present disclosure;

[0048] FIG. 16 illustrates a flowchart of an example method implemented at a third device according to some embodiments of the present disclosure;

[0049] FIG. 17 illustrates a flowchart of an example method implemented at a fifth device according to some embodiments of the present disclosure;

[0050] FIG. 18 illustrates a simplified block diagram of a device that is suitable for implementing some example embodiments of the present disclosure; and

[0051] FIG. 19 illustrates a block diagram of an example of a computer-readable medium in accordance with some example embodiments of the present disclosure.

[0052] Throughout the drawings, the same or similar reference numerals represent the same or similar elements.DETAILED DESCRIPTION

[0053] Principles of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. The disclosure described herein can be implemented in various manners other than the ones described below.

[0054] 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 skills in the art to which this disclosure belongs.

[0055] References in the present disclosure to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0056] It shall 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. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0057] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of 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 be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and / or “including” , when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof. As used herein, “at least one of the following: <a list of two or more elements>” and “at least one of <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and” or “or” , mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0058] As used in this application, the term “circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analog  and / or digital circuitry) and (b) combinations of hardware circuits and software, such as (as applicable) : (i) a combination of analog and / or digital hardware circuit (s) with  software / firmware and (ii) any portions of hardware processor (s) with software (including digital signal  processor (s) ) , software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and (c) hardware circuit (s) and or processor (s) , such as a microprocessor (s) or a portion  of a microprocessor (s) , that requires software (for example, firmware) for operation, but the software may not be present when it is not needed for operation.

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

[0060] As used herein, the term “network” , “communication network” or “data network” refers to a network following any suitable communication standards, such as long-term evolution (LTE) , LTE-advanced (LTE-A) , wideband code division multiple access (WCDMA) , high-speed packet access (HSPA) , narrow band Internet of things (NB-IoT) , wireless fidelity (Wi-Fi) and so on. Furthermore, the communications between a terminal device and a network device / element in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the fourth generation (4G) , 4.5G, the future fifth generation (5G) , IEEE 802.11 communication protocols, and / or any other protocols either currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.

[0061] As used herein, the term “network device” refers to a node in a communication network via which a terminal device receives services (e.g., positioning services) therefrom. The network device may refer to a core network device or access network device, such as base station (BS) or an access point (AP) or a transmission and reception point (TRP) , for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , a NR NB (also referred to as a gNB) , a remote radio unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a WiFi device, a relay, a low power node such as a femto, a pico, and so forth, depending on the applied terminology and technology. In the following description, the terms “network device” , “AP device” , “AP” and “access point” may be used interchangeably.

[0062] The term “terminal device” refers to any end device that may be capable of wireless communication. By way of example rather than limitation, a terminal device may also be referred to as a communication device, user equipment (UE) , a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , a station (STA) or station device, or an Access Terminal (AT) . The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA) , portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , USB dongles, smart devices, wireless customer-premises equipment (CPE) , an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD) , a vehicle, a drone, a medical device and applications (for example, remote surgery) , an industrial device and applications (for example, a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts) , a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. In the following description, the terms “station” , “station device” , “STA” , “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.

[0063] FIG. 1 illustrates a schematic diagram of an example communication network 100 in which some embodiments of the present disclosure can be implemented. In FIG. 1, interactions between open radio access network (ORAN) and integration of network and compute function (INCF) framework are depicted schematically. As shown in FIG. 1, the communication network 100 may include at least the first device 110, the second device 120, the third device 130, the fourth device 140, and the fifth device 150. In some embodiments of the present disclosure, the first device 110 may include at least a service management and orchestration (SMO) , or a non-real time (non-RT) radio access network (RAN) intelligent controller (non-RT RIC) located within the SMO; the second device 120 may include a first network function for integration of network and compute, which is also referred to as a central INCF (C-INCF) herein; the third device 130 may include a near-real time radio access network (RAN) intelligent controller (near-RT RIC) , and may optionally include at least one xApps running on the near-RT RIC (not shown in FIG. 1) ; the fourth device 140 may include a second network function for integration of network and compute, which is also referred to as a local INCF (L-INCF) herein; and the fifth device 150 may include an edge application server (EAS) .

[0064] It is to be understood that the number of the first device, the second device, the third device, the fourth device, and the fifth device is only for the purpose of illustration without suggesting any limitations. The communication network 100 may include any suitable number of network devices, terminal devices and cells adapted for implementing embodiments of the present disclosure.

[0065] Communications in the communication network 100 may be implemented according to any proper communication protocol (s) , comprising, but not limited to, cellular communication protocols of the first generation (1G) , the second generation (2G) , the third generation (3G) , the fourth generation (4G) , the fifth generation (5G) and the sixth generation (6G) and on the like, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and / or any other protocols currently known or to be developed in the future. Moreover, the communication may utilize any proper wireless communication technology, comprising 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 (OFDM) , Discrete Fourier Transform spread OFDM (DFT-s-OFDM) and / or any other technologies currently known or to be developed in the future.

[0066] The ORAN alliance specification has defined various important use cases, including, for example, the use cases for “QoE Optimization” and “quality of service (QoS) -based Resource Optimization” . Specifically, the use cases for “QoE Optimization” aim to enhance application QoE under varying radio conditions, while the use cases for “QoS-based Resource Optimization” enables the ORAN to dynamically assign specific RAN QoS to a UE based on context, rather than subscription, during the deployment of demanding applications. These use cases illustrate the requirements for strong interactions between application and RAN QoS management.

[0067] For highly demanding applications, such as extended reality (XR) , there would be a critical need for seamless coordination between network and compute resources. Merely managing network QoS, such as network latency, is insufficient. Instead, it is expected to jointly manage compute QoS (such as processing latency) as well as the network QoS (such as network latency) , since the end-to-end (E2E) application requirements (like E2E applicative latency) are exceedingly stringent.

[0068] Various architectural options incorporating a novel coordination function known as INCF are proposed. Depending on the application requirements, the INCF can make optimal application placement, network and compute resource allocation to respective application per UE.Such placement and allocation of network and compute resources for a distributed application per UE can be referred to as an “E2E application instance solution” herein. The role of the INCF is to provide an “optimal E2E application instance solution” to the (distributed) application per UE. Currently, the applicability of INCF concepts within the core network has been deeply explored, leading to a clear identification of architectural options. However, the application of these concepts within the RAN, and particularly in the context of Open RAN (ORAN) , remains an unresolved challenge.

[0069] Based on this, some solutions have been proposed. In a solution for “QoE optimization” requirement, a mechanism for training a QoE model with regards to RAN metrics and transferring the trained model to a near real time RAN intelligent controller (near-RT RIC) is illustrated. Specifically, in this solution, the non-RT RIC may be responsible for, for example, collecting QoE-related metrics from RAN reports as well as service management and orchestration (SMO) (which can also gather application data) to train artificial intelligence / machine learning (AI / ML) models for QoE optimization in near-RT RIC; training potential ML models for predictive QoE optimization, which can respectively autonomously recognize traffic types, predict quality of experience, or predict available radio bandwidth; generating and sending policies to near-RT RIC to drive the QoE optimization at RAN level in terms of expected behavior. The near-RT RIC may be responsible for, for example, updating the AI / ML models received from non-RT RIC; executing the received AI / ML models such as application classification, QoE prediction, and bandwidth prediction; interpreting and implementing the policies from non-RT RIC to optimize QoE at the RAN level; and sending reports on QoE performance back to the non-RT RIC for evaluation and optimization. The RAN may be responsible for providing detailed network state and UE performance reports to SMO via O1 interface, and supporting QoS enforcement which are expected to influence Radio Resource Management (RRM) behavior.

[0070] However, there are some limitations for this solution. A main drawback is that QoE is only optimized with regards to an ORAN perspective, whereas a true and complete application QoE optimization requires the control of RAN and core network performance as well as compute performance. Further, the SMO is not designed to control (third-party) application compute metrics, and the non-RT RIC / SMO may have no access to fine-grained mappings between application flows and their respective supporting data radio bearers, in which case there could be multiple applications running on a given UE. Furthermore, the adaptation closed loop involving the SMO may be too slow to adapt to rapidly changing radio conditions.

[0071] In another solution, a scenario is assumed where the mobile network operator (MNO) may also offer compute resources (e.g., O-Cloud compute resources) for hosting third-party applications. For example, the MNO might host its ORAN components (such as CU-CP and CU-UP) on a hyper-scaler edge cloud platform. Then, the MNO could leverage the same platform to host third-party applications, each (distributed) application may comprise application modules also referred to as application component functions (ACFs) which are linked with each other via different network connections.

[0072] For scalability purpose, especially per UE and / or per application E2E network and compute QoS assurance, a distributed architecture comprising two types of INCFs (i.e. central INCF (C-INCF) and local INCF (L-INCF) ) is proposed in this solution.

[0073] Specifically, the C-INCF plays a pivotal role in managing and optimizing network resources. It maintains a comprehensive view or database of all network and data network (DN) compute resources, providing a topological overview of L-INCF areas. With knowledge of network metrics between various L-INCF areas, the C-INCF facilitates application-aware mobility across these areas, including mobility of UEs and application clients (ACs) as well as relocation for the edge application server (EAS) . It ensures global optimality in resource allocation and management, and optionally controls central DN (C-DN) compute resources and the central core network, enabling seamless connection of UEs to the central cloud.

[0074] On the other hand, the L-INCF can be used for managing resources within a specific geographic or topological region, also referred to as the L-INCF area. When a UE request is outside its responsibility area, the L-INCF may contact the C-INCF for assistance. With the assistance of the C-INCF, the source L-INCF can identify the target L-INCF and coordinates with it to ensure smooth application-aware mobility. The L-INCF ensures local optimality in resource utilization and management, and also controls local edge DN (L-EDN) compute resources as well as distributed local User Plane Functions (L-UPFs) via the local session management functions (L-SMFs) or alternatively via the intermediate SMFs (I-SMFs) .

[0075] However, this solution lacks an interactive framework that defines behaviors between the L-INCF (or C-INCF) and RAN functions, such as ORAN. Such interaction needs to incorporate standardized interfaces to account for the dynamicity of RAN QoS conditions, such as changing radio conditions.

[0076] In conclusion, to guarantee an optimal QoE for applications, it is required to coordinate the performance of RAN networks, core networks, and compute resources. To achieve this, embodiments of the present disclosure introduce a solution for facilitating a robust and near-instantaneous interaction among applications, compute resource management, and RAN QoS management. Some new interactions and behaviors between the INCFs and the RAN / ORAN functions are introduced. With this solution, dynamic, fine-grained, and optimized provisioning of end-to-end network and compute resources can be achieved, fulfilling application-specific requirements (such as the QoE) under dynamic condition changes such as changing RAN environments.

[0077] In particular, the core idea of embodiments of the present disclosure involves integrating INCF concepts into the ORAN framework by facilitating near-real-time interaction (e.g. within a 100ms order timescale) between the L-INCF and the near-RT RIC. This allows the L-INCF, which is application-aware, to consider rapid RAN condition changes (provided by the near-RT RIC) in its local decision-making processes. Additionally, the L-INCF may also consider the states of compute resources at a quick timescale (approximately a few hundred milliseconds) . Consequently, it is possible to promptly address these changes by collectively enforcing new local network and compute rules, particularly new radio resource scheduling algorithms and associated policies. To achieve this, the present disclosure focuses on managing a new topology at various time scales, which involves identifying the association of control entities (and their interfacing) including INCFs, the network and compute controllers, and specified interfaces.

[0078] It is noted that, to ensure optimal QoE for application instances, each L-INCF is responsible for managing at least the core network resources and the related forwarding performance, the RAN network resources and the related forwarding performance, and the compute resources and the related processing performance. For the sake of simplicity, the coordination between RAN network resources and compute resources will be mainly discussed hereinafter.

[0079] Further, in some embodiments of the present disclosure, a two-level INCF distributed solution is proposed for addressing the scalability issues. This solution is utilized to effectively manage both non-real-time and near-real-time operational timescales. In coherence with a coordinated management for network and compute controllers, the controllers interfacing with each INCF level may operate at a comparable timescale. In this context, it is possible that compute scaling operations (both up and down) are compliant with stringent timescales, at or below the 100ms level. This is really noticeable when it comes to the latest virtualization technologies, such as Web Assembly (WASM) , or Function as a Service, which take advantage of the advanced virtualization capabilities embedded by the latest processing units.

[0080] FIG. 2 illustrates a flowchart illustrating an example process 200 for enhancing interactions between ORAN and INCF framework according to some embodiments of the present disclosure. For the purpose of discussion, the process 200 will be described with reference to FIG. 1. The process 200 may involve the first device 110 and the second device 120 as illustrated in FIG. 1. It would be appreciated that although the process 200 has been described in the communication network 100 of FIG. 1, this process may be likewise applied to other communication scenarios where different network devices are jointly deployed to provide respective services.

[0081] As shown in FIG. 2, at 210, the first device 110 may determine a change in a RAN resource pool, for example some radio resources are decommissioned, or some new radio resources are commissioned. Then, at 222, the first device 110 may transmit, to the second device 120, a first notification message 224 for notifying the change in the RAN resource pool.

[0082] Based on the first notification message 224 received at 226, at 230, the second device 120 may determine an adjustment of a compute resource pool based on the change in the RAN resource pool. For instance, more compute resources can be allocated to the second device (such as by increasing the local DN within the cluster) where RAN resources have been increased.

[0083] In some embodiments, the compute resource pool is not under control of the first device 110. In such embodiments, the second device 120 may perform the adjustment of the compute resource pool based on the change in the RAN resource pool.

[0084] Alternatively, in some other embodiments, the compute resource pool is under control of the first device 110. In such embodiments, the second device 120 may transmit, to the first device 110, a second notification message for notifying the first device 110 to perform the adjustment of the compute resource pool. Based on receiving this second notification message, the first device 110 may perform the adjustment of the compute resource pool, and then transmit, to the second device 120, a second acknowledgement message responsive to the second notification message.

[0085] In some embodiments, the first device 110 and the second device 120 are included in a first resource management loop (also referred to as a slow (or coarse-grain) closed-loop herein) . In such embodiments, the second device 120 may further determine, together with the first device 110, a change in a topology of a second resource management loop (also referred to as a fast closed-loop herein) including a third device and a fourth device (i.e. the third device 130 and the fourth device 140 as illustrated in FIG. 1) . In such embodiments, the third device includes a near-RT RIC and the fourth device includes a second network function for integration of network and compute. In such embodiments, a management granularity of the second resource management loop is finer than that of the first resource management loop, and a timescale of the second resource management loop is faster than that of the first resource management loop.

[0086] In some embodiments, the change in the topology may comprise at least insertion of at least one of the second network function or the near-RT RIC; removal of at least one of the second network function or the near-RT RIC; creation of at least one of a second interface, a second bis interface, or a third interface; suppression of at least one of the second interface, the second bis interface, or the third interface; or any combination thereof. In some implementations, the second interface connects a near-RT RIC interface to the second network function, the second bis interface connects a near-RT RIC xApp interface to the second network function, and the third interface connects a near-RT RIC Y1 interface to the second network function.

[0087] Further, in the embodiments where the first device 110 and the second device 120 are included in a first resource management loop, the second device 120 may transmit, to the fourth device of the second resource management loop, an indication of a change in a topology of a second resource management loop such as an updated information on the third device, and / or an indication to delegate decision making to the second resource management loop.

[0088] In addition, in such embodiments, the second device 120 may further receive, from the fourth device of the second resource management loop, a report indicating whether the second resource management loop fulfills an application requirement. In case of the report indicating that the application requirement is not fulfilled by the second resource management loop, the second device 120 may perform, together with the first device 110, decision making in the first resource management loop.

[0089] At 242, the second device 120 may transmit, to the first device 110, a first acknowledgement message 244 responsive to the first notification message 224.

[0090] In some embodiments, the first device 110 and the second device 120 may communicate with each other via a first interface (also referred to as interface a herein) connecting either an SMO or a non-RT RIC included in the first device 110 to the first network function included in the second device 120.

[0091] Alternatively, in some other embodiments, the first device 110 and the second device 120 may communicate with each other via a first bis interface (also referred to as interface a bis herein) connecting a non-RT RIC rApp interface to the first network function. In such embodiments, an rApp running on top of the non-RT RIC may function as an agent for the first network function.

[0092] FIG. 3 illustrates a flowchart illustrating an example process 300 for enhancing interactions between ORAN and INCF framework according to some embodiments of the present disclosure. For the purpose of discussion, the process 300 will be described with reference to FIG. 1. The process 300 may involve the third device 130 and the fourth device 140 as illustrated in FIG. 1. It would be appreciated that although the process 300 has been described in the communication network 100 of FIG. 1, this process may be likewise applied to other communication scenarios where different network devices are jointly deployed to provide respective services.

[0093] As shown in FIG. 3, at 310, the third device 130 may determine a change in at least one near-RT RIC related RAN resource, for example the changes in radio conditions due to mobility. Then, at 322, the third device 130 may transmit, to the fourth device 140, a third notification message 324 for notifying the change in the at least one near-RT RIC related RAN resource.

[0094] Based on the third notification message 324 received at 326, at 330, the fourth device 140 may determine a local E2E application instance solution for a terminal device associated with the change in the at least one near-RT RIC related RAN resource. For example, the fourth device 140 may re-calculate the optimal E2E application instance solution for the affected terminal device or application component (AC) . Then, at 340, the fourth device 140 may perform a deployment of the local E2E application instance solution for the terminal device.

[0095] Optionally, in some embodiments, the fourth device 140 may determine, together with the third device 130, to connect an EAS included in a fifth device (i.e. the fifth device 140 as illustrated in FIG. 1) to an xApp running on top of the near-RT RIC included in the third device 130.

[0096] In some embodiments, the third device 130 and the fourth device 140 are included in a second resource management loop. In such embodiments, the fourth device 140 may further receive, from a second device of a first resource management loop, an indication of a change in a topology of the second resource management loop such as an updated information on the third device (e.g. connected to a new third device) , and / or an indication to delegate decision making to the second resource management loop. Alternatively, in such embodiments, the fourth device 140 may further transmit, to a fifth device of a third resource management loop (also referred to as a very fast closed-loop herein) , an indication of a change in a topology of the third resource management loop such as an updated information on the third device, and / or an indication to delegate decision making to the third resource management loop.

[0097] Further, in the embodiments where the third device 130 and the fourth device 140 are included in a second resource management loop, the fourth device 140 may further transmit, to a second device of a first resource management loop, a report indicating whether the second resource management loop fulfills an application requirement. Alternatively, in some embodiments, the fourth device 140 may further receive, from a fifth device of a third resource management loop, a report indicating whether the third resource management loop fulfills an application requirement. In such embodiments, in case that the application requirement is not fulfilled by the third resource management loop, the fourth device 140 may further perform, together with the third device 130, decision making in the second resource management loop.

[0098] At 352, the fourth device 140 may transmit, to the third device 130, a third acknowledgement message 354 responsive to the third notification message 324.

[0099] In some embodiments, the third device 130 and the fourth device 140 may communicate with each other via a second interface (also referred to as interface b herein) connecting a near-RT RIC interface to the second network function. In such embodiments, the second interface may provide near real time exposure of RAN information and RAN programmability to the second network function.

[0100] Alternatively, in some other embodiments, the third device 130 and the fourth device 140 may communicate with each other via a second bis interface (also referred to as interface b bis herein) connecting a near-RT RIC xApp interface to the second network function. In such embodiments, through the second bis interface, an xApp running on top of the near-RT RIC functions may act as an agent for the second network function.

[0101] Alternatively, in some other embodiments, the third device 130 and the fourth device 140 may communicate with each other via a third interface (also referred to as interface c herein) connecting a near-RT RIC Y1 interface to the second network function. In such embodiments, the third interface may provide near real time exposure of a RAN condition change to the second network function.

[0102] In some embodiments, a management granularity of the second resource management loop is finer than that of the first resource management loop, and a timescale of the second resource management loop is faster than that of the first resource management loop, and a management granularity of the third resource management loop is finer than that of the second resource management loop, and a timescale of the third resource management loop is faster than that of the second resource management loop.

[0103] FIG. 4 illustrates a flowchart illustrating an example process 400 for enhancing interactions between ORAN and INCF framework according to some embodiments of the present disclosure. For the purpose of discussion, the process 400 will be described with reference to FIG. 1. The process 400 may involve the third device 130 and the fifth device 150 as illustrated in FIG. 1. To be noted, in the case illustrated in FIG. 4, the third device 130 may include an xApp running on a near-RT RIC. It would be appreciated that although the process 400 has been described in the communication network 100 of FIG. 1, this process may be likewise applied to other communication scenarios where different network devices are jointly deployed to provide respective services.

[0104] As shown in FIG. 4, at 410, the third device 130 may determine a change in at least one near RT RIC related RAN resource, for example the changes in radio conditions due to multiple reasons, such as bad weather conditions, mobile obstacles such as cars or lorries, or the like. Then, at 422, the third device 130 may transmit, to the fifth device 150, a fourth notification message 424 for notifying the change in the at least one at least one near RT RIC related RAN resource.

[0105] In some embodiments, the fifth device 150 may include a network controller. In such embodiments, based on the fourth notification message 424 received at 426, at 430, the fifth device 150 may determine to perform an adjustment of at least one radio link QoS parameter based on the change in the at least one near RT RIC related RAN resource. For example, the fifth device 150 may determine to upgrade or downgrade the RAN QoS associated with the radio links related to a terminal device. Then, the fifth device 150 may transmit, to the third device 130, a fifth notification message for notifying the third device 130 to perform the adjustment of the at least one radio link QoS parameter. Based on receiving the fifth notification message, the third device 130 may perform the adjustment of the at least one radio link QoS parameter, and then transmit, to the fifth device 150, a fifth acknowledgement message responsive to the fifth notification message.

[0106] In some embodiments, the fifth device 150 may include a compute controller. In such embodiments, the fifth device 150 may perform an adjustment of at least one compute resource (e.g. the compute resources allocated to the EAS included in the fifth device 150) based on the change in the at least one near RT RIC related RAN resource.

[0107] In some embodiments, the third device 130 and the fifth device 150 are included in a third resource management loop. In such embodiments, the fifth device 150 may further receive, from a fourth device of a second resource management loop, an indication of a change in a topology of the third resource management loop, and / or an indication to delegate decision making to the third resource management loop. Further, in such embodiments, the fifth device 150 may further transmit, to a fourth device of a second resource management loop, a report indicating whether the third resource management loop fulfills an application requirement.

[0108] At 442, the fifth device 150 may transmit, to the third device 130, a fourth acknowledgement message 444 responsive to the fourth notification message 424.

[0109] In some embodiments, the third device and the fifth device may communicate with each other via a fourth interface (also referred to as interface f herein) connecting a near-RT RIC Y1 interface to the EAS. In such embodiments, the fourth interface may provide real time exposure of a RAN condition from the xApp or the near-RT RIC to the EAS.

[0110] Alternatively, in some other embodiments, the third device and the fifth device may communicate with each other via a fifth interface (also referred to as interface g herein) connecting the near-RT RIC to the EAS. In such embodiments, through the fifth interface, the EAS has access to RAN programmability

[0111] Alternatively, in some other embodiments, the third device and the fifth device may communicate with each other via a fifth bis (also referred to as interface g bis herein) interface connecting a near-RT RIC xApp interface to the EAS. In such embodiments, through the fifth bis interface, the xApp running on top of the near-RT RIC may function as an agent for the EAS.

[0112] In some embodiments, a management granularity of the third resource management loop is finer than that of the second resource management loop, and a timescale of the third resource management loop is faster than that of the second resource management loop.

[0113] In some embodiments of this disclosure, a two-level INCF framework with well-defined interfaces and interaction protocols between each INCF level as well as the managers / controllers within the ORAN architecture is proposed, which involves the creation of novel interfaces and associated behaviors.

[0114] Specifically, at the global or central level, some new interfaces between the C-INCF and the SMO are introduced, allowing a slow (i.e., second-order timescale) and globally coarse-grained control loop. This loop is designed to cope with high-level RAN parameters, such as RAN topology change, new cell deployments change, and new frequency bands activated. The global / high-level interaction plays a crucial role in enabling flexible and localized management of the low-level controller topology (the details for the interactions between the control loops will be illustrated hereinafter) . This allows for the reconfiguration of local-level interactions among controllers in response to high-level and coarse-grained changes, including adjustments of network topology between ORAN sites, changes in ORAN site network resources (e.g., deployment of new frequency bands) , changes in ORAN site compute resources (e.g., addition of new compute nodes to the local compute cluster) , and changes in ORAN site UE “load” (number of UEs) , or the like.

[0115] Moreover, at a local or fine-grained level (for example, with regards to some specific geographical / topological areas or ORAN sites) , some new interfaces between L-INCF and the (local) near-RT RIC are introduced. These interfaces enable the local controller topology to facilitate a fast (e.g. 100ms-order timescale) control loop for swiftly determining, deploying, and monitoring the optimal application instance in response to an application service request, ensuring the enforcement of the desired application QoE.

[0116] Additionally, a setup for a near-real-time dynamic sub-controller topology is proposed, which may incorporate at least one EAS. This sub-controller topology is dynamically interfaced, via new interfaces, between the EAS and a selected (local) near-RT RIC, or more specifically, a “real-time” xApp running on the near-RT RIC. Once established, this sub-controller topology allows for a real-time control loop (potentially operating within a 100ms timescale) , ensuring the enforcement of the desired application QoE.

[0117] FIG. 5 illustrates an overview of the control components and the involved ORAN interfaces in the network architecture according to some example embodiments of the present disclosure. As illustrated in FIG. 5, in addition to the conventional 3GPP interfaces (such as interfaces Uu, F1-c, F1-u, E1, or the like) and ORAN interfaces (such as interfaces O1, O2, A1, E2, Y1, or the like) as well as some recently introduced (such as interfaces d and e) , the network architecture according to the present disclosure may also comprise some newly added interfaces, such as interface a, b, c, which are presented as bold solid line. Optionally, the new interfaces may further comprise various interfaces that can be used based on specific requirements or preferences, such as interface f and g, which are presented as bold dashed line. For the purpose of clarity, Table 1 below provides a detailed description of each interface along with the corresponding RAN-resources-versus-compute-resource adjustment closed-loops. For simplicity, compute controllers are regarded as part of the respective INCFs. Table 1: Description of new interfaces and associated closed loops

[0118] FIG. 6 illustrates a schematic diagram of partitioning, alignment, and assignment of control components based on specific requirements for scalability and dynamicity according to some example embodiments of the present disclosure. As illustrated in FIG. 6, the static links or components (such as the non-RT RIC / SMO, or the C-INCF) are depicted with solid line, whereas the dynamic links or components (such as the near-RT RIC, or the L-INCF) are depicted with dashed line. The static components and links are manually configured and set up by the operator. Conversely, the dynamic components are dynamically inserted or removed by the non-RT RIC and C-INCF, respectively.

[0119] The process of insertion or removal of the L-INCF by the C-INCF (and similarly, the near-RT RIC by the non-RT RIC) can be implemented similarly to the insertion or removal of the I-SMF by the SMF, as specified in TS 23.502 clause 4.23.

[0120] For example, the L-INCF could be instantiated by the C-INCF (playing the role of manager) , and similarly, the near-RT RIC could be instantiated by the non-RT RIC. Subsequently, the C-INCF (or non-RT RIC) would connect the L-INCF (or near-RT RIC) to the integration fabric, which serves as the network infrastructure supporting control plane connectivity. Following this, the C-INCF (or non-RT RIC) would communicate the address of the associated near-RT RIC (or L-INCF) to the L-INCF (or near-RT RIC) , thereby enabling mutual connectivity between the near-RT RIC and L-INCF.

[0121] In the following, the control loops according to the present disclosure will be described. Specifically, for each control loop categorized based on their granularity and timescales, the availability of models encoding the application QoS / QoE behaviors can be assumed. It is noted that all these control loops might potentially utilize a same AI-trained model.

[0122] In FIGS. 7 and 8, signaling flows for a first resource management loop according to some embodiments of the present disclosure are illustrated. The first resource management loop (also referred to as a slow (or coarse-grain) closed-loop herein) facilitates a flexible and localized management of the low-level controller topology, allowing for adjustments and optimizations at a coarse-grained level in terms of partitioning the RAN and compute resources across various lower-level responsibilities.

[0123] Depending on whether the first device controls the compute resources of the EAS (i.e., whether the EAS is deployed in the O-Cloud or not) , there are two distinct implementations.

[0124] FIG. 7 illustrates a signaling flow 700 for a first resource management loop according to some embodiments of the present disclosure. In the scenario illustrated in FIG. 7, the compute resource pool is not under control of the first device 110, that is, the EAS is not deployed within the O-Cloud. For the purpose of discussion, the signaling flow 700 will be described with reference to FIG. 1. The signaling flow 700 may involve the first device 110 and the second device 120 as illustrated in FIG. 1. It would be appreciated that although the signaling flow 700 has been described in the communication network 100 of FIG. 1, this process may be likewise applied to other communication scenarios where different network devices are jointly deployed to provide respective services.

[0125] At 710, the first device 110 may determine that some pool of RAN resources has been changed, for example, some radio resources are decommissioned, or some new radio resources are commissioned.

[0126] At 720, the first device 110 may transmit, to the second device 120, notification message (i.e. the first notification message 224 described in FIG. 2) for notifying the change in the RAN resource pool.

[0127] At 730, the second device 120 may adapt compute resource pool to align with the RAN resource pool changes, for example, more compute can be allocated to L-INCF (e.g. by increasing local DN of the cluster) where RAN resources have been increased.

[0128] Potentially, at 740, the first device 110 and the second device 120 may collaborate to determine a change in the topology of lower-level loop (i.e. second resource management loop including a third device and a fourth device) . For example, the change in the topology may comprise at least insertion of at least one of the second network function (i.e. the L-INCF) or the near-RT RIC; removal of at least one of the second network function or the near-RT RIC; creation of at least one of interface b (the second interface) , interface b bis (the second bis interface) , or interface c (the third interface) ; or suppression of at least one of the interface b, the interface b bis , or the interface c.

[0129] At 750, the second device 120 may transmit, to the first device 110, an acknowledgement for the notification message received at 720, i.e. the first acknowledgement message 244 described in FIG. 2.

[0130] FIG. 8 illustrates another signaling flow 800 for a first resource management loop according to some embodiments of the present disclosure. In the scenario illustrated in FIG. 8, the compute resource pool is under control of the first device 110, that is, the EAS is deployed within the O-Cloud. For the purpose of discussion, the signaling flow 800 will be described with reference to FIG. 1. The signaling flow 800 may involve the first device 110 and the second device 120 as illustrated in FIG. 1. It would be appreciated that although the signaling flow 800 has been described in the communication network 100 of FIG. 1, this process may be likewise applied to other communication scenarios where different network devices are jointly deployed to provide respective services.

[0131] Similar to FIG. 7, at 810, the first device 110 may determine that some pool of RAN resources has been changed, for example, some radio resources are decommissioned, or some new radio resources are commissioned. At 820, the first device 110 may transmit, to the second device 120, notification message (i.e. the first notification message 224 described in FIG. 2) for notifying the change in the RAN resource pool.

[0132] Then, at 830, the second device 120 may determine to adapt compute resource pool to align with the RAN resource pool changes, for example, more compute can be allocated to L-INCF (e.g. by increasing local DN of the cluster) where RAN resources have been increased.

[0133] Potentially, at 840, the first device 110 and the second device 120 may collaborate to determine a change in the topology of lower-level loop (i.e. second resource management loop including a third device and a fourth device) . For example, the change in the topology may comprise at least insertion of at least one of the second network function (i.e. the L-INCF) or the near-RT RIC; removal of at least one of the second network function or the near-RT RIC; creation of at least one of interface b (the second interface) , interface b bis (the second bis interface) , or interface c (the third interface) ; or suppression of at least one of the interface b, the interface b bis , or the interface c.

[0134] At 850, since the first device 110 controls the O-cloud (i.e. EAS compute resources) , the second device 120 may inform the first device 110 to perform the adjustment of the compute resource pool, for example, by transmitting a second notification message described above. Based on receiving this notification message, the first device 110 may perform the adjustment of the compute resource pool. Then, at 860, the first device 110 may transmit, to the second device 120, an acknowledgement (the second acknowledgement message) for the notification message received at 850.

[0135] At 870, the second device 120 may transmit, to the first device 110, an acknowledgement for the notification message received at 820, i.e. the first acknowledgement message 244 described in FIG. 2.

[0136] FIG. 9 illustrates a signaling flow 900 for a second resource management loop according to some embodiments of the present disclosure. For the purpose of discussion, the signaling flow 900 will be described with reference to FIG. 1. The signaling flow 900 may involve the third device 130 and the fourth device 140 as illustrated in FIG. 1. It would be appreciated that although the signaling flow 900 has been described in the communication network 100 of FIG. 1, this process may be likewise applied to other communication scenarios where different network devices are jointly deployed to provide respective services.

[0137] The second resource management loop (also referred to as a fast closed-loop herein) is responsible for providing the terminal device, or precisely, the application client (AC) running on the UE, with an optimal network (i.e. network path via a protocol data unit (PDU) session) and compute solution (such as a selected EAS with optimal compute resources) .

[0138] While the establishment of the (local) PDU session may not be near real-time, finer-grain adjustments are more likely to be near real-time. These adjustments may include modifications to the PDU session, such as QoS parameters change, scaling up the EAS, or transitioning to a more compute-powerful and co-located EAS.

[0139] At 910, the third device 130 may determine a change in at least one near-RT RIC related RAN resource, for example the changes in radio conditions due to the terminal mobility.

[0140] At 920, the third device 130 may notifies the fourth device 140 about the change in at least one near-RT RIC related RAN resource, for example, by transmitting a notification (for example, the third notification message 324) to the fourth device 140.

[0141] At 930, the fourth device 140 may re-calculate the optimal E2E application instance solution for the affected terminal device or AC. Then, at 940, the fourth device 140 may perform a deployment of the local E2E application instance solution for the affected terminal device.

[0142] Optionally, at 950, the third device 130 and the fourth device 140 may collaborate to determine a connection between an EAS and a dedicated xApp running on top of the near-RT RIC. In this case, the fourth device 140 may delegate very fine grain optimization to the EAS, which could be considered in certain case as a very fine grain INCF.

[0143] At 960, the fourth device 140 may transmit, to the third device 130, an acknowledgement for the notification message received at 920, i.e. the third acknowledgement message 354 described in FIG. 3.

[0144] FIG. 10 illustrates a signaling flow 1000 for a third resource management loop according to some embodiments of the present disclosure. For the purpose of discussion, the signaling flow 1000 will be described with reference to FIG. 1. The signaling flow 1000 may involve the third device 130 and the fifth device 150 as illustrated in FIG. 1. It would be appreciated that although the signaling flow 1000 has been described in the communication network 100 of FIG. 1, this process may be likewise applied to other communication scenarios where different network devices are jointly deployed to provide respective services.

[0145] To be noted, in some implementations, the EAS can serve as an Application Function (AF) , incorporating both user plane (UP) and control plane (CP) functionalities. In the context of third resource management loop (also referred to as a very fast closed-loop herein) , the primary focus is on the CP aspect of the EAS. In the case illustrated in FIG. 10, the third device 130 may include an xApp running on a near-RT RIC.

[0146] At 1010, the third device 130 may detects real time RAN resource changes –e.g. due to bad weather conditions, mobile obstacles such as cars or lorries, etc. At 1020, the third device 130 may notify the fifth device 150 about the change, for example, by transmitting a notification (for example, the fourth notification message 424) to the fifth device 150.

[0147] At 1030, the fifth device 150 may include a network controller. In this case, the fifth device 150 could decide to perform an adjustment of at least one radio link QoS parameter based on the change in the at least one near RT RIC related RAN resource, for example, to upgrade / downgrade the RAN QoS associated with the radio links associated with the terminal device.

[0148] At 1040, the fifth device 150 may transmit, to the third device 130, a notification (i.e. the fifth notification message) for notifying the third device 130 to perform the adjustment of the at least one radio link QoS parameter.

[0149] At 1050, based on receiving the notification, the third device 130 may perform the adjustment of the at least one radio link QoS parameter.

[0150] At 1060, transmit, the third device 130 may transmit, to the fifth device 150, an acknowledgement (the fifth acknowledgement message) for the notification message received at 1040.

[0151] At 1070, the fifth device 150 may include a compute controller. In this case, the fifth device 150 may perform an adjustment of at least one compute resource based on the change in the at least one near RT RIC related RAN resource, for example, to reduce / increase processing latency when RAN latency is increased / decreased.

[0152] At 1080, the fifth device 150 may transmit, to the third device 130, an acknowledgement for the notification message received at 1020, i.e. the fourth acknowledgement message 444 described in FIG. 4.

[0153] FIG. 11 illustrates an overview of the interaction between three resource management loops according to some embodiments of the present disclosure. As illustrated in FIG. 11, each upper-level closed loop controls the topology of the lower-level closed loops, and delegates a finer decision-making responsibility to them. The lower-level closed loops then report back to the upper-level loop about their capabilities to fulfill application requirements at the corresponding granularity. In case a lower-level loop be unable to fulfill these requirements, decision-making is reverted to the upper-level loop for appropriate actions, such as adjusting coarse-grained RAN and / or compute resources at the top-level loop, re-selecting the optimal EAS, and modifying PDU sessions at the middle-level loop.

[0154] FIG. 12 illustrates a flowchart of an example method 1200 implemented at a first device including at least an SMO or a non-RT RIC, according to some embodiments of the present disclosure. For the purpose of discussion, the method 1200 will be described from the perspective of the first device 110 with reference to FIG. 1.

[0155] At block 1210, the first device may determine a change in a RAN resource pool. At block 1220, the first device may transmit, to a second device including a first network function for integration of network and compute, a first notification message for notifying the change in the RAN resource pool.

[0156] In some embodiments, the first device may further receive, from the second device, a first acknowledgement message responsive to the first notification message.

[0157] In some embodiments, a compute resource pool is under control of the first device. In such embodiments, the first device may further receive, from the second device, a second notification message for notifying the first device to perform an adjustment of the compute resource pool. Then, based on receiving the second notification message, the first device may further perform the adjustment of the compute resource pool. Then, the first device may further transmit, to the second device, a second acknowledgement message responsive to the second notification message.

[0158] In some embodiments, the first device and the second device are included in a first resource management loop. In such embodiments, the first device may further determine, together with the second device, a change in a topology of a second resource management loop including a third device and a fourth device. In such embodiments, the third device includes a near-RT RIC and the fourth device includes a second network function for integration of network and compute.

[0159] In some embodiments, the change in the topology may comprise at least insertion of at least one of the second network function or the near-RT RIC; removal of at least one of the second network function or the near-RT RIC; creation of at least one of a second interface, a second bis interface, or a third interface; suppression of at least one of the second interface, the second bis interface, or the third interface; or any combination thereof. In some implementations, the second interface connects a near-RT RIC interface to the second network function, the second bis interface connects a near-RT RIC xApp interface to the second network function, and the third interface connects a near-RT RIC Y1 interface to the second network function.

[0160] In some embodiments, a management granularity of the second resource management loop is finer than that of the first resource management loop, and a timescale of the second resource management loop is faster than that of the first resource management loop.

[0161] In some embodiments, the first device and the second device may communicate with each other via a first interface connecting either an SMO or a non-RT RIC included in the first device to the first network function included in the second device.

[0162] Alternatively, in some embodiments, the first device and the second device may communicate with each other via a first bis interface connecting a non-RT RIC rApp interface to the first network function. In such embodiments, an rApp running on top of the non-RT RIC may function as an agent for the first network function.

[0163] FIG. 13 illustrates a flowchart of an example method 1300 implemented at a second device including a first network function for integration of network and compute, according to some embodiments of the present disclosure. For the purpose of discussion, the method 1300 will be described from the perspective of the second device 120 with reference to FIG. 1.

[0164] At block 1310, the second device may receive, from a first device including at least an SMO or a non-RT RIC, a first notification message for notifying a change in a RAN resource pool. At block 1320, the second device may determine an adjustment of a compute resource pool based on the change in the RAN resource pool.

[0165] In some embodiments, the second device may further transmit, to the first device, a first acknowledgement message responsive to the first notification message.

[0166] In some embodiments, the compute resource pool is not under control of the first device. In such embodiments, the second device may further perform the adjustment of the compute resource pool based on the change in the RAN resource pool.

[0167] Alternatively, in some embodiments, the compute resource pool is under control of the first device. In such embodiments, the second device may further transmit, to the first device, a second notification message for notifying the first device to perform the adjustment of the compute resource pool. Then, the second device may further receive, from the first device, a second acknowledgement message responsive to the second notification message.

[0168] In some embodiments, the first device and the second device are included in a first resource management loop. In such embodiments, the second device may further determine, together with the first device, a change in a topology of a second resource management loop including a third device and a fourth device. In such embodiments, the third device includes a near-RT RIC and the fourth device includes a second network function for integration of network and compute.

[0169] In some embodiments, the change in the topology may comprise at least insertion of at least one of the second network function or the near-RT RIC; removal of at least one of the second network function or the near-RT RIC; creation of at least one of a second interface, a second bis interface, or a third interface; suppression of at least one of the second interface, the second bis interface, or the third interface; or any combination thereof. In some implementations, the second interface connects a near-RT RIC interface to the second network function, the second bis interface connects a near-RT RIC xApp interface to the second network function, and the third interface connects a near-RT RIC Y1 interface to the second network function.

[0170] In some embodiments, the first device and the second device are included in a first resource management loop. In such embodiments, the second device may further transmit, to a fourth device of a second resource management loop, an indication of a change in a topology of a second resource management loop, and / or an indication to delegate decision making to the second resource management loop.

[0171] In some embodiments, the first device and the second device are included in a first resource management loop. In such embodiments, the second device may further receive, from a fourth device of a second resource management loop, a report indicating whether the second resource management loop fulfills an application requirement. In such embodiments, the second device may further perform, together with the first device, decision making in the first resource management loop in case that the application requirement is not fulfilled by the second resource management loop.

[0172] In some embodiments, the first device and the second device may communicate with each other via a first interface connecting either an SMO or a non RT RIC included in the first device to the first network function included in the second device.

[0173] Alternatively, in some embodiments, the first device and the second device may communicate with each other via a first bis interface connecting a non-RT RIC rApp interface to the first network function. In such embodiments, an rApp running on top of the non-RT RIC may function as an agent for the first network function.

[0174] In some embodiments, a management granularity of the second resource management loop is finer than that of the first resource management loop, and a timescale of the second resource management loop is faster than that of the first resource management loop.

[0175] FIG. 14 illustrates a flowchart of an example method 1400 implemented at a third device including a near-RT RIC, according to some embodiments of the present disclosure. For the purpose of discussion, the method 1400 will be described from the perspective of the third device 130 with reference to FIG. 1.

[0176] At block 1410, the third device may determine a change in at least one near-RT RIC related RAN resource. At block 1420, the third device may transmit, to a fourth device including a second network function for integration of network and compute, a third notification message for notifying the change in the at least one near-RT RIC related RAN resource.

[0177] In some embodiments, the third device may further receive, from the fourth device, a third acknowledgement message responsive to the third notification message.

[0178] In some embodiments, the third device may further determine, together with the fourth device, to connect an edge application server (EAS) in a fifth device to an xApp running on top of the near-RT RIC included in the third device.

[0179] In some embodiments, the third device and the fourth device may communicate with each other via a second interface connecting a near-RT RIC interface to the second network function. In such embodiments, the second interface may provide near real time exposure of RAN information and RAN programmability to the second network function;

[0180] Alternatively, in some embodiments, the third device and the fourth device may communicate with each other via a second bis interface connecting a near-RT RIC xApp interface to the second network function. In such embodiments, through the second bis interface, an xApp running on top of the near-RT RIC functions may act as an agent for the second network function; or

[0181] Alternatively, in some embodiments, the third device and the fourth device may communicate with each other via a third interface connecting a near-RT RIC Y1 interface to the second network function. In such embodiments, the third interface may provide near real time exposure of a RAN condition change to the second network function.

[0182] FIG. 15 illustrates a flowchart of an example method 1500 implemented at a fourth device including a second network function for integration of network and compute, according to some embodiments of the present disclosure. For the purpose of discussion, the method 1500 will be described from the perspective of the fourth device 140 with reference to FIG. 1.

[0183] At block 1510, the fourth device may receive, from a third device including a near-RT RIC, a third notification message for notifying a change in at least one near-RT RIC related RAN resource. At block 1520, the fourth device may determine a local E2E application instance solution for a terminal device associated with the change in the at least one near-RT RIC related RAN resource. At block 1530, the fourth device may perform a deployment of the local E2E application instance solution for the terminal device.

[0184] In some embodiments, the fourth device may further transmit, to the third device, a third acknowledgement message responsive to the third notification message.

[0185] In some embodiments, the fourth device may further determine, together with the third device, to connect an edge application server (EAS) in a fifth device to an xApp running on top of the near-RT RIC included in the third device.

[0186] In some embodiments, the third device and the fourth device are included in a second resource management loop. In such embodiments, the fourth device may further receive, from a second device of a first resource management loop, an indication to delegate decision making to the second resource management loop. Alternatively, the fourth device may further transmit, to a fifth device of a third resource management loop, an indication to delegate decision making to the third resource management loop.

[0187] In some embodiments, the third device and the fourth device are included in a second resource management loop. In such embodiments, the fourth device may further receive, from a second device of a first resource management loop, an indication of a change in a topology of the second resource management loop. Alternatively, the fourth device may further transmit, to a fifth device of a third resource management loop, an indication of a change in a topology of the third resource management loop.

[0188] In some embodiments, the third device and the fourth device are included in a second resource management loop. In such embodiments, the fourth device may further transmit, to a second device of a first resource management loop, a report indicating whether the second resource management loop fulfills an application requirement. Alternatively, the fourth device may further receive, from a fifth device of a third resource management loop, a report indicating whether the third resource management loop fulfills an application requirement. In such embodiments, the fourth device may further perform, together with the third device, decision making in the second resource management loop in case that the application requirement is not fulfilled by the third resource management loop.

[0189] In some embodiments, the third device and the fourth device may communicate with each other via a second interface connecting a near-RT RIC interface to the second network function. In such embodiments, the second interface may provide near real time exposure of RAN information and RAN programmability to the second network function;

[0190] Alternatively, in some embodiments, the third device and the fourth device may communicate with each other via a second bis interface connecting a near-RT RIC xApp interface to the second network function. In such embodiments, through the second bis interface, an xApp running on top of the near-RT RIC functions may act as an agent for the second network function.

[0191] Alternatively, in some embodiments, the third device and the fourth device may communicate with each other via a third interface connecting a near-RT RIC Y1 interface to the second network function. In such embodiments, the third interface may provide near real time exposure of a RAN condition change to the second network function.

[0192] In some embodiments, a management granularity of the second resource management loop is finer than that of the first resource management loop, and a timescale of the second resource management loop is faster than that of the first resource management loop, and a management granularity of the third resource management loop is finer than that of the second resource management loop, and a timescale of the third resource management loop is faster than that of the second resource management loop.

[0193] FIG. 16 illustrates a flowchart of an example method 1600 implemented at a third device including an xApp running on a near-RT RIC, according to some embodiments of the present disclosure. For the purpose of discussion, the method 1600 will be described from the perspective of the third device 130 with reference to FIG. 1.

[0194] At block 1610, the third device may determine a change in at least one near RT RIC related RAN resource. At block 1620, the third device may transmit, to a fifth device including an EAS, a fourth notification message for notifying the change in the at least one near RT RIC related RAN resource.

[0195] In some embodiments, the third device may further receive, from the fifth device, a fourth acknowledgement message responsive to the fourth notification message.

[0196] In some embodiments, the third device may further receive, from the fifth device, a fifth notification message for notifying the third device to perform an adjustment of at least one radio link quality of service (QoS) parameter. Then, based on receiving the fifth notification message, the third device may further perform the adjustment of the at least one radio link QoS parameter. Then, the third device may further transmit, to the fifth device, a fifth acknowledgement message responsive to the fifth notification message.

[0197] In some embodiments, the third device and the fifth device communicate with each other via a fourth interface connecting a near-RT RIC Y1 interface to the EAS. In such embodiments, the fourth interface may provide real time exposure of a RAN condition from the xApp or the near-RT RIC to the EAS.

[0198] Alternatively, in some embodiments, the third device and the fifth device communicate with each other via a fifth interface connecting the near-RT RIC to the EAS. In such embodiments, through the fifth interface, the EAS may have access to RAN programmability.

[0199] Alternatively, in some embodiments, the third device and the fifth device communicate with each other via a fifth bis interface connecting a near-RT RIC xApp interface to the EAS. In such embodiments, through the fifth bis interface, the xApp running on top of the near-RT RIC may function as an agent for the EAS.

[0200] FIG. 17 illustrates a flowchart of an example method 1700 implemented at a fifth device including an EAS, according to some embodiments of the present disclosure. For the purpose of discussion, the method 1700 will be described from the perspective of the fifth device 150 with reference to FIG. 1.

[0201] At block 1710, the fifth device may receive, from a third device including an xApp running on a near-real time radio access network (RAN) intelligent controller (near-RT RIC) , a fourth notification message for notifying a change in at least one near RT RIC related RAN resource. At block 1720, the fifth device may determine to perform an adjustment of at least one radio link quality of service (QoS) parameter based on the change in the at least one near RT RIC related RAN resource.

[0202] In some embodiments, the fifth device may further transmit, to the third device, a fourth acknowledgement message responsive to the fourth notification message.

[0203] In some embodiments, the fifth device may further transmit, to the third device, a fifth notification message for notifying the third device to perform the adjustment of the at least one radio link QoS parameter. Then, the fifth device may further receive, from the third device, a fifth acknowledgement message responsive to the fifth notification message.

[0204] In some embodiments, the fifth device may further perform an adjustment of at least one compute resource (e.g. the compute resources allocated to the EAS included in the fifth device) based on the change in the at least one near RT RIC related RAN resource.

[0205] In some embodiments, the third device and the fifth device are included in a third resource management loop. In such embodiments, the fifth device may further receive, from a fourth device of a second resource management loop, an indication of a change in a topology of the third resource management loop, and / or an indication to delegate decision making to the third resource management loop.

[0206] In some embodiments, the third device and the fifth device are included in a third resource management loop. In such embodiments, the fifth device may further transmit, to a fourth device of a second resource management loop, a report indicating whether the third resource management loop fulfills an application requirement.

[0207] In some embodiments, the third device and the fifth device communicate with each other via a fourth interface connecting a near-RT RIC Y1 interface to the EAS. In such embodiments, the fourth interface may provide real time exposure of a RAN condition from the xApp or the near-RT RIC to the EAS.

[0208] Alternatively, in some embodiments, the third device and the fifth device communicate with each other via a fifth interface connecting the near-RT RIC to the EAS. In such embodiments, through the fifth interface, the EAS may have access to RAN programmability.

[0209] Alternatively, in some embodiments, the third device and the fifth device communicate with each other via a fifth bis interface connecting a near-RT RIC xApp interface to the EAS. In such embodiments, through the fifth bis interface, the xApp running on top of the near-RT RIC may function as an agent for the EAS.

[0210] In some embodiments, a management granularity of the third resource management loop is finer than that of the second resource management loop, and a timescale of the third resource management loop is faster than that of the second resource management loop.

[0211] In some embodiments, an apparatus capable of performing any of the method 1200 (for example, the first device 110 including at least an SMO or a non-RT RIC) may comprise means for performing the respective steps of the method 1200. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[0212] In some embodiments, the apparatus may comprise means for determining a change in a RAN resource pool; and means for transmitting, to a second device including a first network function for integration of network and compute, a first notification message for notifying the change in the RAN resource pool.

[0213] In some embodiments, the apparatus may further comprise means for receiving, from the second device, a first acknowledgement message responsive to the first notification message.

[0214] In some embodiments, a compute resource pool is under control of the first device. In such embodiments, the apparatus may further comprise means for receiving, from the second device, a second notification message for notifying the first device to perform an adjustment of the compute resource pool; means for performing the adjustment of the compute resource pool based on receiving the second notification message; and means for transmitting, to the second device, a second acknowledgement message responsive to the second notification message.

[0215] In some embodiments, the first device and the second device are included in a first resource management loop. In such embodiments, the apparatus may further comprise means for determining, together with the second device, a change in a topology of a second resource management loop including a third device and a fourth device. In such embodiments, the third device includes a near-RT RIC and the fourth device includes a second network function for integration of network and compute.

[0216] In some embodiments, the change in the topology may comprise at least insertion of at least one of the second network function or the near-RT RIC; removal of at least one of the second network function or the near-RT RIC; creation of at least one of a second interface, a second bis interface, or a third interface; suppression of at least one of the second interface, the second bis interface, or the third interface; or any combination thereof. In some implementations, the second interface connects a near-RT RIC interface to the second network function, the second bis interface connects a near-RT RIC xApp interface to the second network function, and the third interface connects a near-RT RIC Y1 interface to the second network function.

[0217] In some embodiments, a management granularity of the second resource management loop is finer than that of the first resource management loop, and a timescale of the second resource management loop is faster than that of the first resource management loop.

[0218] In some embodiments, the first device and the second device may communicate with each other via a first interface connecting either an SMO or a non-RT RIC included in the first device to the first network function included in the second device.

[0219] Alternatively, in some embodiments, the first device and the second device may communicate with each other via a first bis interface connecting a non-RT RIC rApp interface to the first network function. In such embodiments, an rApp running on top of the non-RT RIC may function as an agent for the first network function.

[0220] In some embodiments, the apparatus may further comprise means for performing other steps of some embodiments of method 1200. In some embodiments, the means may comprise at least one processor and at least one memory comprising computer program code, wherein the at least one memory and computer program code are configured with the at least one processor to cause the performance of the apparatus.

[0221] In some embodiments, an apparatus capable of performing any of the method 1300 (for example, the second device 120 including a first network function for integration of network and compute) may comprise means for performing the respective steps of the method 1300. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[0222] In some embodiments, the apparatus may comprise means for receiving, from a first device including at least an SMO or a non-RT RIC, a first notification message for notifying a change in a RAN resource pool; and means for determining an adjustment of a compute resource pool based on the change in the RAN resource pool.

[0223] In some embodiments, the apparatus may further comprise means for transmitting, to the first device, a first acknowledgement message responsive to the first notification message.

[0224] In some embodiments, the compute resource pool is not under control of the first device. In such embodiments, the apparatus may further comprise means for performing the adjustment of the compute resource pool based on the change in the RAN resource pool.

[0225] Alternatively, in some embodiments, the compute resource pool is under control of the first device. In such embodiments, the apparatus may further comprise means for transmitting, to the first device, a second notification message for notifying the first device to perform the adjustment of the compute resource pool; and means for receive, from the first device, a second acknowledgement message responsive to the second notification message.

[0226] In some embodiments, the first device and the second device are included in a first resource management loop. In such embodiments, the apparatus may further comprise means for determining, together with the first device, a change in a topology of a second resource management loop including a third device and a fourth device, wherein the third device includes a near-RT RIC and the fourth device includes a second network function for integration of network and compute.

[0227] In some embodiments, the change in the topology may comprise at least insertion of at least one of the second network function or the near-RT RIC; removal of at least one of the second network function or the near-RT RIC; creation of at least one of a second interface, a second bis interface, or a third interface; suppression of at least one of the second interface, the second bis interface, or the third interface; or any combination thereof. In some implementations, the second interface connects a near-RT RIC interface to the second network function, the second bis interface connects a near-RT RIC xApp interface to the second network function, and the third interface connects a near-RT RIC Y1 interface to the second network function.

[0228] In some embodiments, the first device and the second device are included in a first resource management loop. In such embodiments, the apparatus may further comprise means for transmitting, to a fourth device of a second resource management loop, an indication of a change in a topology of a second resource management loop, and / or an indication to delegate decision making to the second resource management loop.

[0229] In some embodiments, the first device and the second device are included in a first resource management loop. In such embodiments, the apparatus may further comprise means for receiving, from a fourth device of a second resource management loop, a report indicating whether the second resource management loop fulfills an application requirement. In such embodiments, the apparatus may further comprise means for performing, together with the first device, decision making in the first resource management loop in case that the application requirement is not fulfilled by the second resource management loop.

[0230] In some embodiments, the first device and the second device may communicate with each other via a first interface connecting either an SMO or a non-RT RIC included in the first device to the first network function included in the second device.

[0231] Alternatively, in some embodiments, the first device and the second device may communicate with each other via a first bis interface connecting a non-RT RIC rApp interface to the first network function. In such embodiments, an rApp running on top of the non-RT RIC may function as an agent for the first network function.

[0232] In some embodiments, a management granularity of the second resource management loop is finer than that of the first resource management loop, and a timescale of the second resource management loop is faster than that of the first resource management loop.

[0233] In some embodiments, the apparatus may further comprise means for performing other steps of some embodiments of method 1300. In some embodiments, the means may comprise at least one processor and at least one memory comprising computer program code, wherein the at least one memory and computer program code are configured with the at least one processor to cause the performance of the apparatus.

[0234] In some embodiments, an apparatus capable of performing any of the method 1400 (for example, the third device 130 including a near-RT RIC) may comprise means for performing the respective steps of the method 1400. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[0235] In some embodiments, the apparatus may comprise means for determining a change in at least one near-RT RIC related RAN resource; and means for transmitting, to a fourth device including a second network function for integration of network and compute, a third notification message for notifying the change in the at least one near-RT RIC related RAN resource.

[0236] In some embodiments, the apparatus may further comprise means for receiving, from the fourth device, a third acknowledgement message responsive to the third notification message.

[0237] In some embodiments, the apparatus may further comprise means for determining, together with the fourth device, to connect an edge application server (EAS) in a fifth device to an xApp running on top of the near-RT RIC included in the third device.

[0238] In some embodiments, the third device and the fourth device may communicate with each other via a second interface connecting a near-RT RIC interface to the second network function. In such embodiments, the second interface may provide near real time exposure of RAN information and RAN programmability to the second network function;

[0239] Alternatively, in some embodiments, the third device and the fourth device may communicate with each other via a second bis interface connecting a near-RT RIC xApp interface to the second network function. In such embodiments, through the second bis interface, an xApp running on top of the near-RT RIC functions may act as an agent for the second network function; or

[0240] Alternatively, in some embodiments, the third device and the fourth device may communicate with each other via a third interface connecting a near-RT RIC Y1 interface to the second network function. In such embodiments, the third interface may provide near real time exposure of a RAN condition change to the second network function.

[0241] In some embodiments, the apparatus may further comprise means for performing other steps of some embodiments of method 1400. In some embodiments, the means may comprise at least one processor and at least one memory comprising computer program code, wherein the at least one memory and computer program code are configured with the at least one processor to cause the performance of the apparatus.

[0242] In some embodiments, an apparatus capable of performing any of the method 1500 (for example, the fourth device 140 including a second network function for integration of network and compute) may comprise means for performing the respective steps of the method 1500. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[0243] In some embodiments, the apparatus may comprise means for receiving, from a third device including a near-RT RIC, a third notification message for notifying a change in at least one near-RT RIC related RAN resource; means for determining a local E2E application instance solution for a terminal device associated with the change in the at least one near-RT RIC related RAN resource; and means for performing a deployment of the local E2E application instance solution for the terminal device.

[0244] In some embodiments, the apparatus may further comprise means for transmitting, to the third device, a third acknowledgement message responsive to the third notification message.

[0245] In some embodiments, the apparatus may further comprise means for determining, together with the third device, to connect an edge application server (EAS) in a fifth device to an xApp running on top of the near-RT RIC included in the third device.

[0246] In some embodiments, the third device and the fourth device are included in a second resource management loop. In such embodiments, the apparatus may further comprise means for receiving, from a second device of a first resource management loop, an indication to delegate decision making to the second resource management loop; and means for transmitting, to a fifth device of a third resource management loop, an indication to delegate decision making to the third resource management loop.

[0247] In some embodiments, the third device and the fourth device are included in a second resource management loop. In such embodiments, the apparatus may further comprise means for receiving, from a second device of a first resource management loop, an indication of a change in a topology of the second resource management loop; and means for transmitting, to a fifth device of a third resource management loop, an indication of a change in a topology of the third resource management loop.

[0248] In some embodiments, the third device and the fourth device are included in a second resource management loop. In such embodiments, the apparatus may further comprise means for transmitting, to a second device of a first resource management loop, a report indicating whether the second resource management loop fulfills an application requirement; and means for receiving, from a fifth device of a third resource management loop, a report indicating whether the third resource management loop fulfills an application requirement. In such embodiments, the apparatus may further comprise means for performing, together with the third device, decision making in the second resource management loop in case that the application requirement is not fulfilled by the third resource management loop.

[0249] In some embodiments, the third device and the fourth device may communicate with each other via a second interface connecting a near-RT RIC interface to the second network function. In such embodiments, the second interface may provide near real time exposure of RAN information and RAN programmability to the second network function;

[0250] Alternatively, in some embodiments, the third device and the fourth device may communicate with each other via a second bis interface connecting a near-RT RIC xApp interface to the second network function. In such embodiments, through the second bis interface, an xApp running on top of the near-RT RIC functions may act as an agent for the second network function; or

[0251] Alternatively, in some embodiments, the third device and the fourth device may communicate with each other via a third interface connecting a near-RT RIC Y1 interface to the second network function. In such embodiments, the third interface may provide near real time exposure of a RAN condition change to the second network function.

[0252] In some embodiments, a management granularity of the second resource management loop is finer than that of the first resource management loop, and a timescale of the second resource management loop is faster than that of the first resource management loop, and a management granularity of the third resource management loop is finer than that of the second resource management loop, and a timescale of the third resource management loop is faster than that of the second resource management loop.

[0253] In some embodiments, the apparatus may further comprise means for performing other steps of some embodiments of method 1500. In some embodiments, the means may comprise at least one processor and at least one memory comprising computer program code, wherein the at least one memory and computer program code are configured with the at least one processor to cause the performance of the apparatus.

[0254] In some embodiments, an apparatus capable of performing any of the method 1600 (for example, the third device 130 including an xApp running on a near-RT RIC) may comprise means for performing the respective steps of the method 1600. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[0255] In some embodiments, the apparatus may comprise means for determining a change in at least one near RT RIC related RAN resource; and means for transmitting, to a fifth device including an EAS, a fourth notification message for notifying the change in the at least one near RT RIC related RAN resource.

[0256] In some embodiments, the apparatus may further comprise means for receiving, from the fifth device, a fourth acknowledgement message responsive to the fourth notification message.

[0257] In some embodiments, the apparatus may further comprise means for receiving, from the fifth device, a fifth notification message for notifying the third device to perform an adjustment of at least one radio link quality of service (QoS) parameter; means for performing the adjustment of the at least one radio link QoS parameter based on receiving the fifth notification message; and means for transmitting, to the fifth device, a fifth acknowledgement message responsive to the fifth notification message.

[0258] In some embodiments, the third device and the fifth device communicate with each other via a fourth interface connecting a near-RT RIC Y1 interface to the EAS. In such embodiments, the fourth interface may provide real time exposure of a RAN condition from the xApp or the near-RT RIC to the EAS.

[0259] Alternatively, in some embodiments, the third device and the fifth device communicate with each other via a fifth interface connecting the near-RT RIC to the EAS. In such embodiments, through the fifth interface, the EAS may have access to RAN programmability.

[0260] Alternatively, in some embodiments, the third device and the fifth device communicate with each other via a fifth bis interface connecting a near-RT RIC xApp interface to the EAS. In such embodiments, through the fifth bis interface, the xApp running on top of the near-RT RIC may function as an agent for the EAS.

[0261] In some embodiments, the apparatus may further comprise means for performing other steps of some embodiments of method 1600. In some embodiments, the means may comprise at least one processor and at least one memory comprising computer program code, wherein the at least one memory and computer program code are configured with the at least one processor to cause the performance of the apparatus.

[0262] In some embodiments, an apparatus capable of performing any of the method 1700 (for example, the fifth device 150 including an EAS) may comprise means for performing the respective steps of the method 1700. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[0263] In some embodiments, the apparatus may comprise means for receiving, from a third device including an xApp running on a near-real time radio access network (RAN) intelligent controller (near-RT RIC) , a fourth notification message for notifying a change in at least one near RT RIC related RAN resource; and means for determining to perform an adjustment of at least one radio link quality of service (QoS) parameter based on the change in the at least one near RT RIC related RAN resource.

[0264] In some embodiments, the apparatus may further comprise means for transmitting, to the third device, a fourth acknowledgement message responsive to the fourth notification message.

[0265] In some embodiments, the apparatus may further comprise means for transmitting, to the third device, a fifth notification message for notifying the third device to perform the adjustment of the at least one radio link QoS parameter; and means for receiving, from the third device, a fifth acknowledgement message responsive to the fifth notification message.

[0266] In some embodiments, the apparatus may further comprise means for performing an adjustment of at least one compute resource (e.g. the compute resources allocated to the EAS included in the fifth device) based on the change in the at least one near RT RIC related RAN resource.

[0267] In some embodiments, the third device and the fifth device are included in a third resource management loop. In such embodiments, the apparatus may further comprise means for receiving, from a fourth device of a second resource management loop, an indication of a change in a topology of the third resource management loop, and / or an indication to delegate decision making to the third resource management loop.

[0268] In some embodiments, the third device and the fifth device are included in a third resource management loop. In such embodiments, the apparatus may further comprise means for transmitting, to a fourth device of a second resource management loop, a report indicating whether the third resource management loop fulfills an application requirement.

[0269] In some embodiments, the third device and the fifth device communicate with each other via a fourth interface connecting a near-RT RIC Y1 interface to the EAS. In such embodiments, the fourth interface may provide real time exposure of a RAN condition from the xApp or the near-RT RIC to the EAS.

[0270] Alternatively, in some embodiments, the third device and the fifth device communicate with each other via a fifth interface connecting the near-RT RIC to the EAS. In such embodiments, through the fifth interface, the EAS may have access to RAN programmability.

[0271] Alternatively, in some embodiments, the third device and the fifth device communicate with each other via a fifth bis interface connecting a near-RT RIC xApp interface to the EAS. In such embodiments, through the fifth bis interface, the xApp running on top of the near-RT RIC may function as an agent for the EAS.

[0272] In some embodiments, a management granularity of the third resource management loop is finer than that of the second resource management loop, and a timescale of the third resource management loop is faster than that of the second resource management loop.

[0273] In some embodiments, the apparatus may further comprise means for performing other steps of some embodiments of method 1700. In some embodiments, the means may comprise at least one processor and at least one memory comprising computer program code, wherein the at least one memory and computer program code are configured with the at least one processor to cause the performance of the apparatus.

[0274] FIG. 18 illustrates a simplified block diagram of a device 1800 that is suitable for implementing some example embodiments of the present disclosure.

[0275] The device 1800 may be provided to implement the communication device, for example the first device 110, the second device 120, the third device 130, the fourth device 140, and the fifth device 150 as shown in FIG. 1. As shown, the device 1800 includes one or more processors 1810, one or more memories 1820 coupled to the processor 1810, and one or more communication modules 1840 coupled to the processor 1810.

[0276] The communication module 1840 is for bidirectional communications. The communication module 1840 has at least one antenna to facilitate communication. The communication interface may represent any interface that is necessary for communication with other network elements.

[0277] The processor 1810 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 1800 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

[0278] The memory 1820 may include one or more non-volatile memories and one or more volatile memories. Examples of the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 1824, an electrically programmable read only memory (EPROM) , a flash memory, a hard disk, a compact disc (CD) , a digital video disk (DVD) , and other magnetic storage and / or optical storage. Examples of the volatile memories include, but are not limited to, a random-access memory (RAM) 1822 and other volatile memories that will not last in the power-down duration.

[0279] A computer program 1830 includes computer executable instructions that are executed by the associated processor 1810. The program 1830 may be stored in the ROM 1824. The processor 1810 may perform any suitable actions and processing by loading the program 1830 into the RAM 1822.

[0280] The embodiments of the present disclosure may be implemented by means of the program 1830 so that the device 1800 may perform any process of the disclosure as discussed with reference to FIGS. 12 to 17. The embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

[0281] In some embodiments, the program 1830 may be tangibly contained in a computer readable medium which may be included in the device 1800 (such as in the memory 1820) or other storage devices that are accessible by the device 1800. The device 1800 may load the program 1830 from the computer readable medium to the RAM 1822 for execution. The computer readable medium may include any types of tangible non-volatile storage, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like.

[0282] FIG. 19 illustrates a block diagram of an example of a computer-readable medium 1000 in accordance with some example embodiments of the present disclosure.

[0283] Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose 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. While various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0284] 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 those included in program modules, being executed in a device on a target real or virtual processor, to carry out the methods 1200 to 1700 as described above with reference to FIGS. 12 to 17. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

[0285] Program code for carrying out methods of the present disclosure 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, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

[0286] In the context of the present disclosure, the computer program codes or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above. Examples of the carrier include a signal, computer readable medium, and the like.

[0287] The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, 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 disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. The term “non-transitory, ” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM) .

[0288] Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.

[0289] Although the present disclosure has been described in languages specific to structural features and / or methodological acts, it is to be understood that the present 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

A first device including at least a service management and orchestration (SMO) or a non-real time (non-RT) radio access network (RAN) intelligent controller (non-RT RIC) , the first device comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the first device at least to:determine a change in a RAN resource pool; andtransmit, to a second device including a first network function for integration of network and compute, a first notification message for notifying the change in the RAN resource pool.The first device of claim 1, wherein the first device is further caused to:receive, from the second device, a first acknowledgement message responsive to the first notification message.The first device of claim 1 or 2, wherein a compute resource pool is under control of the first device, and the first device is further caused to:receive, from the second device, a second notification message for notifying the first device to perform an adjustment of the compute resource pool;based on receiving the second notification message, perform the adjustment of the compute resource pool; andtransmit, to the second device, a second acknowledgement message responsive to the second notification message.The first device of any of claims 1 to 3, wherein the first device and the second device are included in a first resource management loop, and the first device is further caused to:determine, together with the second device, a change in a topology of a second resource management loop including a third device and a fourth device, wherein the third device includes a near-RT RIC and the fourth device includes a second network function for integration of network and compute.The first device of claim 4, wherein the change in the topology comprises at least one of the following:insertion of at least one of the second network function or the near-RT RIC;removal of at least one of the second network function or the near-RT RIC;creation of at least one of a second interface, a second bis interface, or a third interface, wherein the second interface connects a near-RT RIC interface to the second network function, the second bis interface connects a near-RT RIC xApp interface to the second network function, and the third interface connects a near-RT RIC Y1 interface to the second network function; orsuppression of at least one of the second interface, the second bis interface, or the third interface.The first device of claim 4 or 5, wherein a management granularity of the second resource management loop is finer than that of the first resource management loop, and a timescale of the second resource management loop is faster than that of the first resource management loop.The first device of any of claims 1 to 6, wherein the first device and the second device communicate with each other via at least one of the following:a first interface connecting either an SMO or a non-RT RIC included in the first device to the first network function included in the second device; ora first bis interface connecting a non-RT RIC rApp interface to the first network function, wherein an rApp running on top of the non-RT RIC functions as an agent for the first network function.A second device including a first network function for integration of network and compute, the second device comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the second device at least to:receive, from a first device including at least a service management and orchestration (SMO) or a non-real time RAN intelligent controller (non-RT RIC) , a first notification message for notifying a change in a RAN resource pool; anddetermine an adjustment of a compute resource pool based on the change in the RAN resource pool.The second device of claim 8, wherein the second device is further caused to:transmit, to the first device, a first acknowledgement message responsive to the first notification message.The second device of claim 8 or 9, wherein the compute resource pool is not under control of the first device, and the second device is further caused to:perform the adjustment of the compute resource pool based on the change in the RAN resource pool.The second device of claim 8 or 9, wherein the compute resource pool is under control of the first device, and the second device is further caused to:transmit, to the first device, a second notification message for notifying the first device to perform the adjustment of the compute resource pool; andreceive, from the first device, a second acknowledgement message responsive to the second notification message.The second device of any of claims 8 to 11, wherein the first device and the second device are included in a first resource management loop, and the second device is further caused to:determine, together with the first device, a change in a topology of a second resource management loop including a third device and a fourth device, wherein the third device includes a near-RT RIC and the fourth device includes a second network function for integration of network and compute.The second device of claim 12, wherein the change in the topology comprises at least one of the following:insertion of at least one of the second network function or the near-RT RIC;removal of at least one of the second network function or the near-RT RIC;creation of at least one of a second interface, a second bis interface, or a third interface, wherein the second interface connects a near-RT RIC interface to the second network function, the second bis interface connects a near-RT RIC xApp interface to the second network function, and the third interface connects a near-RT RIC Y1 interface to the second network function; orsuppression of at least one of the second interface, the second bis interface, or the third interface.The second device of any of claims 8 to 13, wherein the first device and the second device are included in a first resource management loop, and the second device is further caused to at least one of the following:transmit, to a fourth device of a second resource management loop, an indication of a change in a topology of a second resource management loop; ortransmit, to the fourth device of the second resource management loop, an indication to delegate decision making to the second resource management loop.The second device of any of claims 8 to 14, wherein the first device and the second device are included in a first resource management loop, and the second device is further caused to:receive, from a fourth device of a second resource management loop, a report indicating whether the second resource management loop fulfills an application requirement.The second device of claim 15, wherein the second device is further caused to:based on determining that the application requirement is not fulfilled by the second resource management loop, perform, together with the first device, decision making in the first resource management loop.The second device of any of claims 8 to 16, wherein the first device and the second device communicate with each other via at least one of the following:a first interface connecting either an SMO or a non-RT RIC included in the first device to the first network function included in the second device; ora first bis interface connecting a non-RT RIC rApp interface to the first network function, wherein an rApp running on top of the non-RT RIC functions as an agent for the first network function.The second device of any of claims 12 to 17, wherein a management granularity of the second resource management loop is finer than that of the first resource management loop, and a timescale of the second resource management loop is faster than that of the first resource management loop.A third device including a near-real time radio access network (RAN) intelligent controller (near-RT RIC) , the third device comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the third device at least to:determine a change in at least one near-RT RIC related RAN resource; andtransmit, to a fourth device including a second network function for integration of network and compute, a third notification message for notifying the change in the at least one near-RT RIC related RAN resource.The third device of claim 19, wherein the third device is further caused to:receive, from the fourth device, a third acknowledgement message responsive to the third notification message.The third device of claim 19 or 20, wherein the third device is further caused to:determine, together with the fourth device, to connect an edge application server (EAS) in a fifth device to an xApp running on top of the near-RT RIC included in the third device.The third device of any of claims 19 to 21, wherein the third device and the fourth device communicate with each other via at least one of the following:a second interface connecting a near-RT RIC interface to the second network function, which provides near real time exposure of RAN information and RAN programmability to the second network function;a second bis interface connecting a near-RT RIC xApp interface to the second network function, through which an xApp running on top of the near-RT RIC functions acts as an agent for the second network function; ora third interface connecting a near-RT RIC Y1 interface to the second network function, which provides near real time exposure of a RAN condition change to the second network function.A fourth device including a second network function for integration of network and compute, the fourth device comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the fourth device at least to:receive, from a third device including a near real time (near-RT) radio access network (RAN) intelligent controller (near-RT RIC) , a third notification message for notifying a change in at least one near-RT RIC related RAN resource;determine a local end-to-end (E2E) application instance solution for a terminal device associated with the change in the at least one near-RT RIC related RAN resource; andperform a deployment of the local E2E application instance solution for the terminal device.The fourth device of claim 23, wherein the fourth device is further caused to:transmit, to the third device, a third acknowledgement message responsive to the third notification message.The fourth device of claim 23 or 24, wherein the fourth device is further caused to:determine, together with the third device, to connect an edge application server (EAS) in a fifth device to an xApp running on top of the near-RT RIC included in the third device.The fourth device of any of claims 23 to 25, wherein the third device and the fourth device are included in a second resource management loop, and the fourth device is further caused to at least one of the following:receive, from a second device of a first resource management loop, an indication to delegate decision making to the second resource management loop; ortransmit, to a fifth device of a third resource management loop, an indication to delegate decision making to the third resource management loop.The fourth device of any of claims 23 to 26, wherein the third device and the fourth device are included in a second resource management loop, and the fourth device is further caused to at least one of the following:receive, from a second device of a first resource management loop, an indication of a change in a topology of the second resource management loop; ortransmit, to a fifth device of a third resource management loop, an indication of a change in a topology of the third resource management loop.The fourth device of any of claims 23 to 27, wherein the third device and the fourth device are included in a second resource management loop, and the fourth device is further caused to at least one of the following:transmit, to a second device of a first resource management loop, a report indicating whether the second resource management loop fulfills an application requirement; orreceive, from a fifth device of a third resource management loop, a report indicating whether the third resource management loop fulfills an application requirement.The fourth device of any of claim 28, wherein the fourth device is further caused to:based on determining that the application requirement is not fulfilled by the third resource management loop, perform, together with the third device, decision making in the second resource management loop.The fourth device of any of claims 23 to 29, wherein the third device and the fourth device communicate with each other via at least one of the following:a second interface connecting a near-RT RIC interface to the second network function, which provides near real time exposure of RAN information and RAN programmability to the second network function;a second bis interface connecting a near-RT RIC xApp interface to the second network function, through which an xApp running on top of the near-RT RIC functions acts as an agent for the second network function; ora third interface connecting a near-RT RIC Y1 interface to the second network function, which provides near real time exposure of a RAN condition change to the second network function.The fourth device of any of claims 26 to 30, wherein:a management granularity of the second resource management loop is finer than that of the first resource management loop, and a timescale of the second resource management loop is faster than that of the first resource management loop, anda management granularity of the third resource management loop is finer than that of the second resource management loop, and a timescale of the third resource management loop is faster than that of the second resource management loop.A third device including an xApp running on a near-real time radio access network (RAN) intelligent controller (near-RT RIC) , the third device comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the third device at least to:determine a change in at least one near RT RIC related RAN resource; andtransmit, to a fifth device including an edge application server (EAS) , a fourth notification message for notifying the change in the at least one near RT RIC related RAN resource.The third device of claim 32, wherein the third device is further caused to:receive, from the fifth device, a fourth acknowledgement message responsive to the fourth notification message.The third device of claim 32 or 33, wherein the third device is further caused to:receive, from the fifth device, a fifth notification message for notifying the third device to perform an adjustment of at least one radio link quality of service (QoS) parameter;based on receiving the fifth notification message, perform the adjustment of the at least one radio link QoS parameter; andtransmit, to the fifth device, a fifth acknowledgement message responsive to the fifth notification message.The third device of any of claims 32 to 34, wherein the third device and the fifth device communicate with each other via at least one of the following:a fourth interface connecting a near-RT RIC Y1 interface to the EAS, which provides real time exposure of a RAN condition from the xApp or the near-RT RIC to the EAS;a fifth interface connecting the near-RT RIC to the EAS, through which the EAS has access to RAN programmability; ora fifth bis interface connecting a near-RT RIC xApp interface to the EAS, through which the xApp running on top of the near-RT RIC functions as an agent for the EAS.A fifth device including an edge application server (EAS) , the fifth device comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the fifth device at least to:receive, from a third device including an xApp running on a near-real time radio access network (RAN) intelligent controller (near-RT RIC) , a fourth notification message for notifying a change in at least one near RT RIC related RAN resource; anddetermine to perform an adjustment of at least one radio link quality of service (QoS) parameter based on the change in the at least one near RT RIC related RAN resource.The fifth device of claim 36, wherein the fifth device is further caused to:transmit, to the third device, a fourth acknowledgement message responsive to the fourth notification message.The fifth device of claim 36 or 37, wherein the fifth device is further caused to:transmit, to the third device, a fifth notification message for notifying the third device to perform the adjustment of the at least one radio link QoS parameter; andreceive, from the third device, a fifth acknowledgement message responsive to the fifth notification message.The fifth device of any of claims 36 to 38, wherein the fifth device is further caused to:perform an adjustment of at least one compute resource based on the change in the at least one near RT RIC related RAN resource.The fifth device of any of claims 36 to 39, wherein the third device and the fifth device are included in a third resource management loop, and the fifth device is further caused to at least one of the following:receive, from a fourth device of a second resource management loop, an indication of a change in a topology of the third resource management loop; orreceive, from the fourth device of the second resource management loop, an indication to delegate decision making to the third resource management loop.The fifth device of any of claims 36 to 40, wherein the third device and the fifth device are included in a third resource management loop, and the fifth device is further caused to:transmit, to a fourth device of a second resource management loop, a report indicating whether the third resource management loop fulfills an application requirement.The fifth device of any of claims 36 to 41, wherein the third device and the fifth device communicate with each other via at least one of the following:a fourth interface connecting a near-RT RIC Y1 interface to the EAS, which provides real time exposure of a RAN condition from the xApp or the near-RT RIC to the EAS;a fifth interface connecting the near-RT RIC to the EAS, through which the EAS has access to RAN programmability; ora fifth bis interface connecting a near-RT RIC xApp interface to the EAS, through which the xApp running on top of the near-RT RIC functions as an agent for the EAS.The fifth device of any of claims 40 to 42, wherein a management granularity of the third resource management loop is finer than that of the second resource management loop, and a timescale of the third resource management loop is faster than that of the second resource management loop.A method comprising:determining, at a first device including at least a service management orchestration (SMO) or a non-real time (non-RT) radio access network (RAN) intelligent controller (non-RT RIC) , a change in a RAN resource pool; andtransmitting, to a second device including a first network function for integration of network and compute, a first notification message for notifying the change in the RAN resource pool.A method comprising:receiving, at a second device including a first network function for integration of network and compute and from a first device including at least a service management and orchestration (SMO) or a non-real time RAN intelligent controller (non-RT RIC) , a first notification message for notifying a change in a RAN resource pool; anddetermining an adjustment of a compute resource pool based on the change in the RAN resource pool.A method comprising:determining, at a third device including a near-real time radio access network (RAN) intelligent controller (near-RT RIC) , a change in at least one near-RT RIC related RAN resource; andtransmitting, to a fourth device including a second network function for integration of network and compute, a third notification message for notifying the change in the at least one near-RT RIC related RAN resource.A method comprising:receiving, at a fourth device including a second network function for integration of network and compute and from a third device including a near real time (near-RT) radio access network (RAN) intelligent controller (near-RT RIC) , a third notification message for notifying a change in at least one near-RT RIC related RAN resource;determining a local end-to-end (E2E) application instance solution for a terminal device associated with the change in the at least one near-RT RIC related RAN resource; andperforming a deployment of the local E2E application instance solution for the terminal device.A method comprising:determining, at a third device including an xApp running on a near-real time radio access network (RAN) intelligent controller (near-RT RIC) , a change in at least one near RT RIC related RAN resource; andtransmitting, to a fifth device including an edge application server (EAS) , a fourth notification message for notifying the change in the at least one near RT RIC related RAN resource.A method comprising:receiving, at a fifth device including an edge application server (EAS) and from a third device including an xApp running on a near-real time radio access network (RAN) intelligent controller (near-RT RIC) , a fourth notification message for notifying a change in at least one near RT RIC related RAN resource; anddetermining to perform an adjustment of at least one radio link quality of service (QoS) parameter based on the change in the at least one near RT RIC related RAN resource.An apparatus comprising:means for determining a change in a RAN resource pool; andmeans for transmitting, to a second device including a first network function for integration of network and compute, a first notification message for notifying the change in the RAN resource pool.An apparatus comprising:means for receiving, from a first device including at least a service management and orchestration (SMO) or a non-real time RAN intelligent controller (non-RT RIC) , a first notification message for notifying a change in a RAN resource pool; andmeans for determining an adjustment of a compute resource pool based on the change in the RAN resource pool.An apparatus comprising:means for determining a change in at least one near-RT RIC related RAN resource; andmeans for transmitting, to a fourth device including a second network function for integration of network and compute, a third notification message for notifying the change in the at least one near-RT RIC related RAN resource.An apparatus comprising:means for receiving, from a third device including a near real time (near-RT) radio access network (RAN) intelligent controller (near-RT RIC) , a third notification message for notifying a change in at least one near-RT RIC related RAN resource;means for determining a local end-to-end (E2E) application instance solution for a terminal device associated with the change in the at least one near-RT RIC related RAN resource; andmeans for performing a deployment of the local E2E application instance solution for the terminal device.An apparatus comprising:means for determining a change in at least one near RT RIC related RAN resource; andmeans for transmitting, to a fifth device including an edge application server (EAS) , a fourth notification message for notifying the change in the at least one near RT RIC related RAN resource.An apparatus comprising:means for receiving, from a third device including an xApp running on a near-real time radio access network (RAN) intelligent controller (near-RT RIC) , a fourth notification message for notifying a change in at least one near RT RIC related RAN resource; andmeans for determining to perform an adjustment of at least one radio link quality of service (QoS) parameter based on the change in the at least one near RT RIC related RAN resource.A computer readable medium comprising program instructions that, when executed by an apparatus, cause the apparatus to perform at least the method of claims 44 to 49.

Images