Managing the interaction between O-Cloud resource management and orchestration and wireless access network orchestration administration and maintenance functions.

Abstract

Methods, systems, and devices are provided for managing the interaction between the O-Cloud Resource Management and Orchestration (ORMO) Service Management Orchestration Function (SMOF) and the Radio Access Network Operations Administration Maintenance (RANOAM) Function. The method may include ORMO receiving services related to the SMOF from Service Management and Exposure (SME), ORMO sending a request to the SMOF to drain traffic from at least one Network Function (NF), and ORMO sending a request to Topology Exposure and Inventory Management (TE / IV) to update the inventory.

Description

Technical Field

[0001] Systems and methods consistent with embodiments of the present disclosure relate to managing interactions between Open Radio Access Network (O-RAN) Cloud (O-Cloud) resource management and orchestration (ORMO) and Radio Access Network Orchestration Administration Maintenance (RAN OAM) functions.

Background Art

[0002] A radio access network (RAN) is an important component in a communication system that connects end-user devices (or user equipment) to other parts of the network. The RAN includes a combination of various network elements (NEs) that connect end-user devices to the core network. Conventionally, the hardware and / or software of a specific RAN were vendor-specific.

[0003] The emergence of Open RAN (O-RAN) technology has enabled multiple vendors to provide hardware and / or software to a communication system. For this purpose, O-RAN decomposes RAN functions into a Centralized Unit (CU), a Distributed Unit (DU), and a Radio Unit (RU). The CU is a logical node for hosting RAN sub-layers of Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP). The DU is a logical node for hosting RAN sub-layers of Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY). The RU is a physical node that converts radio signals from an antenna into digital signals that can be transmitted to the DU over a fronthaul. Since these entities have open protocols and interfaces between them, they can be developed by different vendors.

[0004] Figure 1 illustrates an O-RAN architecture in related technologies. Referring to Figure 1, the RAN functionality in the O-RAN architecture is controlled and optimized by the RIC. The RIC is a software-defined component that implements modular applications to achieve the multi-vendor operability required in the O-RAN system and to automate and optimize RAN operations. RICs are divided into two types: non-real-time RICs and near-real-time RICs.

[0005] Non-RT RICs are the control point of the non-real-time control loop and operate on a timescale longer than one second within the Service Management and Orchestration (SMO) framework. Their functionality is implemented through modular applications called rApps (rApp 1, ..., rApp N) and includes providing policy-based guidance and enrichment across the A1 interface, which is an interface enabling communication between Non-RT RICs and Near-RT RICs; performing data analytics; artificial intelligence / machine learning (AI / ML) training and inference for RAN optimization; and / or recommending configuration management actions on the O1 interface, which is an interface connecting SMO to RAN management elements (e.g., Near-RT RICs, O-RAN Aggregation Units (O-CUs), O-RAN Distributed Units (O-DUs), etc.).

[0006] Near-RT RICs operate on timescales between 10 milliseconds and 1 second and connect to O-DUs, O-CUs (decomposed into O-CU control planes (O-CU-CP) and O-CU user planes (O-CU-UP)), and open evolved NodeBs (O-eNBs) via E2 interfaces. Near-RT RICs use E2 interfaces to control the underlying RAN elements (E2 nodes / network functions (NFs)) on a near real-time control loop. Near-RT RICs monitor, suspend / stop, override, and control E2 nodes (O-CUs, O-DUs, O-eNBs) via policies. For example, Near-RT RICs set policy parameters on the activated functions of E2 nodes. Furthermore, Near-RT RICs host xApps to implement functions such as Quality of Service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, and security. The two types of RICs work together to optimize O-RAN. For example, a Non-RT RIC provides policies, data, and AI / ML models enabled and used by a Near-RT RIC for RAN optimization via the A1 interface, and the Near-RT RIC returns policy feedback (i.e., how the policies set by the Non-RT RIC are working).

[0007] The MO framework on which the Non-RT RIC resides manages and coordinates the RAN elements. Specifically, the SMO includes FOCOM (Federated O-Cloud Orchestration and Management), a Network Function Orchestrator (NFO) that manages virtual network functions (VNFs) based on virtual machines (VMs) and VNFs based on containers (i.e., instances), and OAM as part of the SMO that manages and coordinates what is represented as the O-RAN Cloud (O-Cloud). The O-Cloud is a collection of RICs, O-CUs, O-DUs, supporting software components (e.g., operating systems and runtime environments), and physical RAN nodes that host the SMO itself. In other words, the SMO manages the O-Cloud from within. The O2 interface is the interface between the SMO and the O-Cloud on which it resides. Through the O2 interface, the SMO provides Infrastructure Management Services (IMS) and Deployment Management Services (DMS). The O2 interface may transmit O2 telemetry data to the SMO, such as O-Cloud configuration or arbitrary logical function data, energy consumption, node health, etc. [Overview of the Initiative] [Problems that the invention aims to solve]

[0008] In related technologies, O-Cloud Resource Management and Orchestration (ORMO) (which may consist of both the aforementioned NFO and FOCOM) needs to interact with other SMO functions (SMOFs) such as RAN Operation Administration and Maintenance (RAN OAM), Topology Exposure and Inventory Management (TE&IV), and other Non-RT RIC SMOFs.

[0009] Network functions (NFs) are typically orchestrated by ORMO's NFO-related capabilities, and these NF applications are configured through the RAN OAM via the O1 interface. For example, in the case of NF scaling, before any active NF deployment is terminated, the NF instance traffic associated with that deployment must be distributed among the remaining active NF deployments. Therefore, the NFO needs to instruct the RAN OAM to drain the traffic of the NF deployment to be terminated. However, in this scenario, it is necessary to ensure that the RAN OAM, through its interaction with other SMOFs such as the NFO, Non-RT RIC, TE&IV, or RAN OAM, has policies in place regarding how traffic should be distributed among other NF deployments.

[0010] Therefore, it is necessary to be able to seamlessly manage the interaction between ORMO and RAN OAM. [Means for solving the problem]

[0011] Embodiments of this disclosure provide methods and systems for managing interactions between an O-Cloud Resource Management and Orchestration (ORMO) Service Management Orchestration Function (SMOF) and a Radio Access Network Operations Administration Maintenance (RANOAM) Function. The methods may include ORMO receiving services related to the SMOF from Service Management and Exposure (SME), ORMO sending a request to the SMOF to drain traffic from at least one Network Function (NF), and ORMO sending a request to Topology Exposure and Inventory Management (TE / IV) to update the inventory.

[0012] According to the embodiment, a method may be provided for managing the interaction between the O-Cloud Resource Management and Orchestration (ORMO) Service Management Orchestration Function (SMOF) and the Radio Access Network Operations Administration Maintenance (RANOAM) Function. The method may include ORMO receiving services from Service Management and Exposure (SME) regarding the Service Orchestration (SO) SMOF, ORMO sending a request to the SO SMOF to terminate and redeploy at least one Network Function (NF), and ORMO sending a request to Topology Exposure and Inventory Management (TE / IV) to update the inventory.

[0013] According to the embodiment, a method may be provided for managing the interaction between the O-Cloud Resource Management and Orchestration (ORMO) Service Management Orchestration Function (SMOF) and the Radio Access Network Operations Administration Maintenance (RANOAM) function. The method may include ORMO receiving services from Service Management and Exposure (SME) regarding the Service Orchestration and Assurance (SOA) SMOF, ORMO sending a request to the SOA SMOF to drain traffic from at least one Network Function (NF), and ORMO sending a request to Topology Exposure and Inventory Management (TE / IV) to update the inventory.

[0014] Thus, because ORMO can facilitate interaction with RANOAM and other SMOFs, it can be understood that seamless interaction between different SMOFs can be achieved to facilitate the management of NF instances.

[0015] Additional aspects may be partially presented in the following description, partially revealed from the description, or realized by implementing the embodiments presented in this disclosure. [Brief explanation of the drawing]

[0016] Features, aspects, and advantages of certain exemplary embodiments of the disclosure are described below with reference to the accompanying drawings, where similar reference numerals represent similar elements.

[0017] Figure 1 illustrates an O-RAN architecture related to the relevant technologies.

[0018] Figure 2 illustrates a call flow diagram for the interaction between ORMO and RANOAM SMOF according to one embodiment.

[0019] Figure 3 illustrates a call flow diagram for the interaction between ORMO and RANOAM SMOF, including SO SMOF, according to one embodiment.

[0020] Figure 4 illustrates a call flow diagram for the interaction between ORMO and RANOAM SMOF, including SOA SMOF, according to one embodiment.

[0021] Figure 5 illustrates an example of an environment in which the system and / or methods described herein may be implemented.

[0022] Figure 6 illustrates an example of a device component according to one embodiment.

[0023] Figures 7A-7C illustrate a call flow diagram for the interaction between ORMO and RANOAM SMOF according to one embodiment.

[0024] Figures 8A to 8D illustrate a call flow diagram for the interaction between ORMO and RANOAM SMOF, including SO SMOF, according to one embodiment.

[0025] Figures 9A - 9C illustrate a call flow diagram regarding the interaction between RANOAM SMOF including ORMO and SOA SMOF according to an embodiment.

Mode for Carrying Out the Invention

[0026] The following description of the detailed examples refers to the accompanying drawings. The same reference numerals in different figures may identify the same or similar elements.

[0027] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementation to the exact forms disclosed. Changes and modifications are possible in light of the foregoing disclosure or may be obtained from the practice of the implementation. Further, one or more features or components of one embodiment may be integrated with or combined with those of other embodiments (or one or more features of other embodiments). Additionally, in the flowchart and operation descriptions provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be executed simultaneously (at least partially), and the order of one or more operations may be interchanged. ]

[0028] It becomes clear that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual special control hardware or software code used to implement these systems and / or methods does not limit the implementation. For this reason, the operations and behaviors of the systems and / or methods are described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0029] Even if certain combinations of features are described in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features may be combined in ways different from those specifically described in the claims and / or disclosed in the specification. Each of the dependent claims listed below may depend directly on only one claim, but the disclosure of possible implementations includes each dependent claim in combination with all other claims in the group of claims.

[0030] None of the elements, actions, or commands used herein should be interpreted as important or essential unless explicitly stated otherwise. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." When only one item is intended, the term "one" or similar is used. Also, as used herein, the terms "has," "have," "having," "include," "including," etc., are intended to be open-ended terms. Furthermore, the phrase "based on" means "at least partially based on" unless explicitly stated otherwise. Furthermore, expressions such as "at least one of A and B" or "at least one of A or B" are understood to include only A, only B, or both A and B.

[0031] The embodiment is directed toward O-Cloud resource optimization, a process that utilizes O-Cloud resources in an efficient manner and eliminates waste of O-Cloud resources by selecting, provisioning, and appropriately sizing resources within O-Cloud. According to the embodiment, network functions (NFs) within O-Cloud are orchestrated as VNFs / CNFs. The SMO (NFO, FOCOM) handles the management and orchestration of the VNFs / CNFs and the underlying O-Cloud infrastructure. The SMO's management, orchestration, and optimization capabilities can be improved by intelligent observability analysis from the VNFs / CNFs and O-Cloud related to the embodiment.

[0032] Non-RT RIC hosts third-party applications, such as rApps in SMOs, that can collect and read various O1 and O2-related observability data and metrics through O1 and O2-related services. These third-party rApps can be used in examples to provide guidance and / or recommendations to NFOs and FOCOMs for the management, orchestration, and optimization of VNFs / CNFs and the underlying O-Cloud infrastructure.

[0033] A Service Orchestrator (SO) and / or Service Assurance (SA) SMOF (SMOF) may be provided according to the embodiment. The SO SMOF and / or SA SMOF may support the orchestration of various procedures necessary for the interaction between RANOAM-related functions and for providing NFO / FOCOM-based services together with service assurance. The SO SMOF may use a set of recipes to define the steps involved in service generation, and such steps may be executed in sequence to ensure that the services are generated. For this reason, the SO SMOF and / or SA SMOF may work together to ensure that network services are generated and maintained in a consistent and reliable manner. The SO SMOF ensures that services are generated correctly, and the SA SMOF ensures that they are performed as expected. This leads to an overall improvement in the quality of service for the network.

[0034] As an example of possible interaction between ORMO and RANOAM, NF traffic draining is primarily discussed below, but it should be understood that other possible interactions can be realized through the following embodiments and configurations. For example, reconfiguring NF post-NF instantiation by configuration or DMS is a possible interaction between NFO and RANOAM that can be implemented. Inquiring about the operational and administrative usage status of NFs can also be a possible request sent from NFO to RANOAM. Notifications regarding NF status and health can also be sent from NFO to RANOAM. NFO can also send responses to actions initiated by RANOAM to RANOAM. RANOAM can also send notifications regarding NF configuration, traffic draining, and fault reporting to NFO.

[0035] It should be understood that ORMO(FOCOM / NFO) may support the capability to receive notifications from RANOAM. ORMO(FOCOM / NFO) may support the capability to configure NF deployments through RANOAM. RANOAM may support the capability to receive notifications from ORMO SMOFs. RANOAM may support the capability to send notifications to other SMOFs.

[0036] Embodiments of this disclosure provide methods and systems for managing interactions between O-Cloud Resource Management and Orchestration (ORMO) Service Management Orchestration Functions (SMOFs) and Radio Access Network Operations Administration Maintenance (RANOAM) functions. These may include ORMO receiving services related to the SMOF from Service Management and Exposure (SME), ORMO sending requests to the SMOF to drain traffic from at least one Network Function (NF), and ORMO sending requests to Topology Exposure and Inventory Management (TE / IV) to update the inventory. Thus, ORMO can facilitate interactions with RANOAM and other SMOFs, and it can be understood that seamless interactions between different SMOFs can be achieved to facilitate the management of NF instances.

[0037] Embodiments of this disclosure may be directed to use cases for ORMO and RANOAM SMOF interactions. The background and goals of the use cases may be as follows:

[0038] O-Cloud orchestration and management require seamless interaction with other SMO functions such as RANOAM, TE&IV, and Non-RT RIC SMOF. This use case may focus on interaction with RAN OAM SMOF.

[0039] Network functions are orchestrated by ORMO's NFO-related capabilities, but these NF applications are configured through the RAN OAM via the O1 interface. In the case of NF scaling in, before any NF deployment (i.e., NF instance) is terminated, the traffic associated with that NF deployment must be distributed among the remaining NF deployments. Here, the NFO needs to instruct the RAN OAM to drain the traffic of the NF deployment to be terminated. The RAN OAM checks the policy for distributing traffic among NF deployments through the NFO, Non-RT RIC, TE&IV, or other SMOFs such as the RAN OAM.

[0040] NF traffic draining is an example of the necessary interaction between ORMO and RAN OAM, and there may be many more examples (but not limited to these), such as:

[0041] NFO -> RANOAM:DMS: To configure or reconfigure an NF post-NF instantiation.

[0042] NFO -> RANOAM: To inquire about the operational and administrative usage status of NF.

[0043] NFO -> RANOAM: NF status and health notifications.

[0044] NFO -> RANOAM: Response to actions initiated by RANOAM.

[0045] RANOAM -> NFO: Notifications regarding NF configuration, traffic draining, and fault reporting.

[0046] The following capabilities may be required for O-Cloud orchestration and management in relation to interactions with other RAN OAMs.

[0047] FOCOM / NFO to support the capability to receive notifications from RANOAM.

[0048] FOCOM / NFO supports the capability to configure NF deployment through RAN OAM.

[0049] RAN OAM to support the capability to receive notifications from ORMO SMOF.

[0050] RAN OAM to support the capability to send notifications to other SMOFs.

[0051] Entities / resources that may be involved in a use case are described as follows:

[0052] SME SMOF: In a decoupled service-based SMO architecture, an SME can be used as a universal SMO service (SMOS) that handles service management and exposure for any SMOS within the SMO. SMOF authorization to determine which services an SMOF can discover, supporting the ability to discover available services from the SMOF. Support for retrieving stored service information and filtering available services based on selection criteria that may be provided by the SMOF.

[0053] Non-RT RIC SMOF: Support for monitoring and evaluating NF PM / FM / CM data via O1 and O2 for NF traffic draining.

[0054] ORMO SMOF (NFO and FOCOM): Support for registering capabilities for NFO-related services with SMEs, etc. Support for receiving and sending necessary notifications regarding RANOAM SMOF for the NF deployment lifecycle.

[0055] O-Cloud (IMS and DMS): Support for receiving actions and feedback from ORMO SMOF (NFO and FOCOM) and implementing them on the O-Cloud platform via IMS and DMS.

[0056] Topology Exposure and Inventory Management (TE&IV) SMOF: Support for updating topology exposures and inventories based on requests from other SMOFs.

[0057] RAN OAM SMOF: Supports requests from other SMOFs regarding services such as PM, FM, and CM. Notifies other SMOFs of changes mentioned in CM requests.

[0058] The Service Orchestrator (SO) and Service Assurance (SA) SMOF (Service Orchestrator of the RAN OAM) support orchestration of various procedures necessary for service assurance based on NFO / FOCOM and interaction between RAN OAM-related functions. The SO uses a set of recipes to define the steps involved in service generation and executes these steps in sequence to ensure that services are generated correctly. The SO and SA may collaborate to ensure that network services are generated and maintained in a consistent and reliable manner. The SO ensures that services are generated correctly, and the SA ensures that they are performed as expected. This leads to an overall improvement in service quality for network customers.

[0059] Furthermore, according to the embodiment, the following requirements may be provided for the component element and SMOF.

[0060] ORMO Functionality (ORMOF) Requirements

[0061] ORMOF may support NFO registration with SME SMOF and / or FOCOM-related services. ORMOF may support traffic draining requests to service orchestrators and guarantees in cases of NF termination, etc. ORMOF may support initiating O2DMS / O2IMS actions based on SOA or SO recommendations. ORMOF may support confirmation of notifications regarding RAN OAM SMOF.

[0062] Non-RT RIC Function (NRTRF) Requirements

[0063] NRTRF may support the role of guaranteeing SOF in cases such as NF traffic draining. NRTRF may also support the discovery of SOF or SOAF-related services on SMEs.

[0064] SOA Functionality (SOAF) Requirements

[0065] SOAF may support the registration of SOA-related services on SMEs. SOAF may support the discovery of SOA-related services through SMEs. SOAF may support the role of a service orchestrator to facilitate procedures between various SMOFs within an SMO. SOAF may support the role of service assurance to enable SLA-based procedures within an SMO. SOAF may support ORMOF and RAN OAMF-related data collection. SOAF may support the storage and registration on SMEs / DMEs for discovery purposes of related end-to-end NF application-related, O-Cloud infrastructure-related, and NF deployment-related automated procedures.

[0066] SO Function (SOF) Requirements

[0067] SOF may support the role of a service orchestrator to facilitate procedures between various SMOFs within the SMO. SOF may support the registration of SO-related services on the SME. SOF may support the discovery of SO-related services through the SME. SOF may support the storage and registration on the SME / DME for discovery purposes of related end-to-end NF application-related, O-Cloud infrastructure-related, and NF deployment-related automated procedures.

[0068] The above "requirements" should be understood as not necessarily limiting the functionality of the elements to those requirements, and that specific functionality may depend on the specific implementation.

[0069] Figure 2 illustrates a call flow diagram for the interaction between ORMO and RANOAM SMOF according to one embodiment. In particular, the following use case may be implemented when the rApp and / or machine learning (ML) model functions as a service assurance (SA). That is, the rApp and / or ML model may provide a recommendation to take action on a particular NF (e.g., recommend draining a particular NF instance or node). This particular use case does not include service assurance.

[0070] DMS200 and IMS210 may run within O-Cloud. ORMO SMOF (which may include NFO and FOCOM)220, RANOAM SMOF230, TE&IV SMOF240, Service Management and Exposure (SME)250, Data Management and Exposure (DME)260, and Non-RT RIC SMOF270 may run within the SMO framework. E2 node 280 may run within the O-RAN node.

[0071] The DMS200 and IMS210 are intended to receive actions and feedback from the ORMO SMOF220 and provide support for implementing those actions on the O-Cloud platform.

[0072] The ORMO SMOF220 may include NFO and FOCOM functionality. In particular, it may support registration capabilities for NFO-related services with SME250, etc. The ORMO SMOF220 may also support receiving and sending necessary notifications regarding the NF deployment lifecycle to and from the RANOAM SMOF230.

[0073] RANOAM SMOF230 supports requests from other SMOFs regarding performance management (PM), fault management (FM), and configuration management (CM) services. RANOAM SMOF may also be responsible for notifying other SMOFs of changes mentioned in CM requests.

[0074] The TE&IV SMOF240 may also be responsible for providing support for updating topology exposures and inventories based on requests from other SMOFs.

[0075] SME250 may be used as a universal SMO service (SMOS) in an SMO architecture based on decoupled services by handling service management and exposure for any SMOS within the SMO. SME250 may support the ability to discover available services from a particular SMOF and may provide authorization for SMOFs to determine which services an SMOF can discover. SME250 may support the retrieval of stored service information and provide filtering of available services based on selection criteria provided by the SMOF. Thus, according to the embodiment, it may be possible to discover services related to an SMOF using SME250.

[0076] According to the embodiment, the DME260 may be used to provide PM data.

[0077] The Non-RT RIC SMOF270 may also be responsible for providing support for monitoring NF PM / FM / CM data via the O1 and O2 interfaces for the purpose of draining NF traffic.

[0078] The embodiment illustrated in Figure 2 may enable configuration management (CM) interaction between ORMO SMOF and RANOAM SMOF. SME250 may function as a service exposure entity, Non-RT RIC SMOF270 may function as an analytical function, ORMO SMOF220 (which may include NFO and FOCOM functions) may function as an O-Cloud orchestration and management function, and RAN OAMF230 may function as a CM application entity.

[0079] In this embodiment illustrated in Figure 2, it can be assumed that the O2 interface connection is established between the SMO and the O-Cloud, the O1 interface connection is enabled, and the network is operational.

[0080] This embodiment in Figure 2 may be initiated when ORMO SMOF220 initiates a request to RANOAM SMOF230.

[0081] In Step 1, RANOAM SMOF230 may register its services related to performance management (PM), fault management (FM), and CM as SME250.

[0082] In step 2, the RANOAM SMOF230 may receive a message from the SME250 indicating that the service registration was successful. According to some embodiments, this may include receiving a service profile ID.

[0083] In step 3, ORMO SMOF220 may discover RANOAM-related services with SME250.

[0084] In step 4, ORMO SMOF220 may receive RANOAM-related services from SME250.

[0085] It may become necessary to drain traffic from a specific NF instance (for example, due to recommendations from rApp or due to performance issues).

[0086] In step 5, ORMO SMOF220 may request RANOAM SMOF230 to drain traffic from a specific NF instance.

[0087] In step 6, the RANOAM SMOF230 may notify the Non-RT RIC SMOF270 of traffic draining requests for a specific NF instance. Specifically, this may involve the Non-RT RIC SMOF270 monitoring the PM and FM for that specific NF instance.

[0088] In step 7, the Non-RT RIC SMOF270 may query and collect PM data from the DME260.

[0089] In step 8, the Non-RT RIC SMOF270 may query and collect FM and CM data from the RANOAM SMOF230.

[0090] In step 9, RANOAM SMOF230 may configure NF traffic distribution to distribute traffic from one NF instance to another and send the configuration to E2 node 280.

[0091] In step 10, E2 node 280 may apply the NF traffic distribution configuration received from RANOAM SMOF230.

[0092] In step 11, E2 node 280 may notify RANOAM SMOF230 that traffic distribution is complete.

[0093] In step 12, the RANAOAM SMOF230 may notify the Non-RT RIC SMOF270 that traffic allocation is complete (for example, it may forward the notification).

[0094] In step 13, the Non-RT RIC SMOF270 may evaluate the performance of the drained NF and decide whether to roll back or take any corrective action to restore the desired performance of the NF. This step may be performed optionally.

[0095] In step 14, the Non-RT RIC SMOF270 may send an evaluation report to the RANOAM SMOF230. This report may include an indication that a rollback should be performed. This step is optional.

[0096] In step 15, the RANOAM SMOF230 may send a notification to the ORMO SMOF220 indicating that NF draining is complete.

[0097] In step 16, ORMO SMOF220 may send a request to DMS200 to terminate NF deployment, based on the notification received from RANOAM SMOF230 in step 15.

[0098] In step 17, ORMO SMOF220 may update its inventory with TE&IV240.

[0099] The above use cases may be terminated when O-Cloud becomes inactive, or when the operator disables the use of rApp as a policy function and / or ML model for the policy function (for example, when rApp and / or ML model are no longer used as SA).

[0100] An example implementation of the steps in Figure 2 for a use case of interaction between RAN OAM SMOF and NFO / FOCOM without rApp as SO and SA may be summarized according to the following table. "(M)" may indicate a required step, and "(O)" may indicate an optional step. However, it should be understood that the specific steps used may depend on the specific implementation. [Table 1]

[0101] Figure 3 illustrates a call flow diagram of the interaction between ORMO and RANOAM SMOF, including SO SMOF, according to one embodiment. In particular, the following use cases introduce SO SMOF350, which may function as a service orchestration entity. rApp and / or machine learning (ML) models may function as service assurance (SA).

[0102] DMS300, IMS310, ORMO SMOF320, RANOAM SMOF330, TE&IV SMOF340, SME360, DME370, Non-RT RIC SMOF380, and E2 node 390 may be the same as DMS200, IMS210, ORMO SMOF220, RANOAM SMOF230, TE&IV SMOF240, SME250, DME260, Non-RT RIC SMOF270, and E2 node 280 as described above, with reference to Figure 2. Therefore, redundant descriptions are omitted to improve readability.

[0103] The embodiment illustrated in Figure 3 may enable configuration management (CM) interaction between ORMO SMOF and RANOAM SMOF. SME360 may function as a service exposure entity, Non-RT RIC SMOF380 may function as an analytical function, ORMO SMOF320 (which may include NFO and FOCOM functions) may function as an O-Cloud orchestration and management function, RAN OAMF330 may function as a CM application entity, and SO SMOF350 may function as a service orchestration entity.

[0104] This embodiment in Figure 3 may be initiated when ORMO SMOF320 initiates a request to SO SMOF350.

[0105] In Step 1, RANOAM SMOF330 may register its services related to performance management (PM), fault management (FM), and CM as SME350.

[0106] In step 2, the RANOAM SMOF330 may receive a message from the SME360 indicating that the service registration was successful. According to some embodiments, this may include receiving a service profile ID.

[0107] In step 3, ORMO SMOF320 may discover SO-related services with SME360.

[0108] In step 4, ORMO SMOF320 may receive SO-related services from SME360.

[0109] It may become necessary to drain traffic from a specific NF instance (for example, due to recommendations from rApp or due to performance issues).

[0110] In step 5, ORMO SMOF320 may request SO SMOF350 to drain traffic from a specific NF instance.

[0111] Alternatively, in step 6, the Non-RT RIC SMOF380 may request that the SO SMOF350 drain traffic from a specific NF instance. This is based on the possibility that the Non-RT RIC SMOF380 can detect an issue with the NF deployment on O-Cloud and request that the deployment be terminated.

[0112] In step 7, SO SMOF350 may query and collect topology details of the resources allocated from NF and TE&IV340.

[0113] In step 8, SO SMOF350 may send a request to ORMO SMOF320 to redeploy the NF.

[0114] In step 9, ORMO SMOF320 may create an NF instance by sending a request to DMS300.

[0115] In step 10, ORMO SMOF320 may notify SO SMOF350 that an instance of NF has been created.

[0116] In step 11, SO SMOF350 may send a request to RANOAM SMOF330 to drain NF and redistribute traffic.

[0117] In step 12, the RANOAM SMOF330 may notify the Non-RT RIC SMOF380 of traffic draining requests for a specific NF instance. Specifically, this could also mean that the Non-RT RIC SMOF370 monitors the PM and FM for a specific NF instance.

[0118] In step 13, the Non-RT RIC SMOF380 may query and collect PM data from the DME370.

[0119] In step 14, the Non-RT RIC SMOF380 may query and collect FM and CM data from the RANOAM SMOF330.

[0120] In step 15, RANOAM SMOF330 may configure NF traffic distribution to distribute traffic from one NF instance to another and send the configuration to E2 node 390.

[0121] In step 16, E2 node 390 may apply the NF traffic distribution configuration received from RANOAM SMOF330.

[0122] In step 17, E2 node 390 may notify RANOAM SMOF330 that traffic distribution is complete.

[0123] In step 18, RANOAM SMOF330 may notify SO SMOF350 that traffic allocation is complete (for example, it may forward the notification).

[0124] In step 19, the RANAOAM SMOF330 may notify the Non-RT RIC SMOF380 that traffic allocation is complete (for example, it may forward the notification).

[0125] In step 20, the Non-RT RIC SMOF380 may evaluate the performance of the drained NF and decide whether to roll back or take any corrective action to restore the desired performance of the NF. This step may be performed optionally.

[0126] In step 21, the Non-RT RIC SMOF380 may send an evaluation report to the RANOAM SMOF330. This report may indicate that there are no performance issues (e.g., success). This step is optional.

[0127] Alternatively, if there is a performance issue, in step 22, the Non-RT RIC SMOF380 may send a failure assessment report to the RANOAM SMOF330 indicating that a rollback or corrective action should be taken. This step is optional. The SO SMOF350 may choose to take such a corrective action based on receiving this assessment report.

[0128] In step 23, SO SMOF350 may send a request to ORMO SMOF320 to terminate NF deployment.

[0129] In step 24, ORMO SMOF320 may send a request to DMS300 to terminate NF deployment, based on the request it received from SO SMOF350 in step 23.

[0130] In step 25, ORMO SMOF320 may update its inventory with TE&IV340.

[0131] In addition to or instead of step 25, in step 26, SO SMOF350 may update its inventory with TE&IV340.

[0132] The above use cases may be terminated when O-Cloud becomes inactive, or when the operator disables the use of rApp as a policy function and / or ML model for the policy function (for example, when rApp and / or ML model are no longer used as SA).

[0133] An example implementation of the steps in Figure 3 for a use case of interaction between RAN OAM SMOF and NFO / FOCOM with rApp as SO and SA may be summarized according to the following table. "(M)" may indicate a required step, and "(O)" may indicate an optional step. However, it should be understood that the specific steps used may depend on the specific implementation. [Table 2] JPEG2026511517000004.jpg52170

[0134] Figure 4 illustrates a call flow diagram for the interaction between RANOAM SMOFs, including ORMO, Service Orchestration, and Assurance (SOA) SMOFs, according to one embodiment. In particular, the following use cases introduce an SOA SMOF450 which may provide both SO and SA functions.

[0135] DMS400, IMS410, ORMO SMOF420, RANOAM SMOF430, TE&IV SMOF440, SME460, DME470, Non-RT RIC SMOF480, and E2 node 490 may be the same as DMS200, IMS210, ORMO SMOF220, RANOAM SMOF230, TE&IV SMOF240, SME250, DME260, Non-RT RIC SMOF270, and E2 node 280 as described above, with reference to Figure 2. Therefore, redundant descriptions are omitted to improve readability.

[0136] The embodiment illustrated in Figure 4 may enable configuration management (CM) interaction between ORMO SMOF and RANOAM SMOF. SME460 may function as a service exposure entity, Non-RT RIC SMOF480 may function as an analytical function, ORMO SMOF420 (which may include NFO and FOCOM functions) may function as an O-Cloud orchestration and management function, RAN OAMF430 may function as a CM application entity, and SOA SMOF450 may function as a service orchestration entity.

[0137] This embodiment in Figure 4 may be initiated when ORMO SMOF420 initiates a request to SOA SMOF450.

[0138] In Step 1, RANOAM SMOF430 may register its services related to performance management (PM), fault management (FM), and CM as SME450.

[0139] In step 2, the RANOAM SMOF430 may receive a message from the SME460 indicating that the service registration was successful. According to some embodiments, this may include receiving a service profile ID.

[0140] In step 3, ORMO SMOF420 may discover SOA-related services with SME460.

[0141] In step 4, ORMO SMOF420 may receive SOA-related services from SME460.

[0142] It may become necessary to drain traffic from a specific NF instance (for example, due to recommendations from rApp or due to performance issues). This may be detected by ORMO SMOF420. In this case, in step 5, ORMO SMOF420 may request SOA SMOF450 to terminate and redeploy the specific NF instance.

[0143] Alternatively, instead of step 5, the SOA may detect problems with NF deployment based on an automated algorithm for SA, for example. For this reason, in step 6, the SOA SMOF450 may request and terminate the NF itself.

[0144] In step 7, SOA SMOF450 may query and collect topology details of the resources allocated from NF and TE&IV440.

[0145] In step 8, the SOA SMOF450 may send a request to the ORMO SMOF420 to redeploy the NF.

[0146] In step 9, the SOA SMOF450 may send a request to the RANOAM SMOF430 to drain the NF and redistribute the traffic.

[0147] In step 10, the RANOAM SMOF430 may notify the Non-RT RIC SMOF480 of traffic draining requests for a particular NF instance. Specifically, this could also mean that the Non-RT RIC SMOF470 monitors the PM and FM for a particular NF instance.

[0148] In step 11, the Non-RT RIC SMOF480 may query and collect PM data from the DME470.

[0149] In step 12, the Non-RT RIC SMOF480 may query and collect FM and CM data from the RANOAM SMOF430.

[0150] In step 13, the RANOAM SMOF430 distributes traffic from a specific NF instance to other NF instances and sends the configuration to the E2 node 490. NF traffic distribution may be configured.

[0151] In step 14, E2 node 490 may apply the NF traffic distribution configuration received from RANOAM SMOF430.

[0152] In step 15, E2 node 490 may notify RANOAM SMOF430 that traffic distribution is complete.

[0153] In step 16, the RANOAM SMOF430 may notify the SOA SMOF450 that traffic allocation is complete (for example, it may forward the notification).

[0154] In step 17, the RANAOAM SMOF430 may notify the Non-RT RIC SMOF480 that traffic allocation is complete (for example, it may forward the notification).

[0155] In step 18, the Non-RT RIC SMOF480 may evaluate the performance of the drained NF and decide whether to roll back or take any corrective action to restore the desired performance of the NF. This step may be performed optionally.

[0156] In step 19, the Non-RT RIC SMOF480 may send an evaluation report to the SOA SMOF450, which may indicate that there are no performance issues (e.g., success). This step is optional.

[0157] Alternatively, if there are performance issues, step 20 may involve the Non-RT RIC SMOF480 sending a failure assessment report to the SOA SMOF450 indicating that a rollback or corrective action should be taken. This step is optional. The SOA SMOF450 may choose to take such a corrective action based on receiving this assessment report.

[0158] In step 21, the SOA SMOF450 may send a request to the ORMO SMOF420 to terminate the NF deployment.

[0159] In step 22, ORMO SMOF420 may send a request to DMS400 to terminate NF deployment, based on the fact that it received a request from SOA SMOF450 in step 21.

[0160] In step 23, ORMO SMOF420 may update its inventory with TE&IV440.

[0161] In addition to or instead of step 23, step 24 may involve updating the inventory of SOA SMOF450 with TE&IV440.

[0162] The above use cases may be terminated when O-Cloud becomes inactive, or when the operator disables the use of rApp as a policy function and / or ML model for the policy function (for example, when rApp and / or ML model are no longer used as SA).

[0163] An example implementation of the steps in Figure 4 for a use case of interaction between RAN OAM SMOF with SOA and NFO / FOCOM may be summarized according to the following table. "(M)" may indicate a required step, and "(O)" may indicate an optional step. However, it should be understood that the specific steps used may depend on the specific implementation. [Table 3] JPEG2026511517000006.jpg37170

[0164] Based on the above embodiments, ORMO can facilitate interaction with RANOAM and other SMOFs, and therefore, seamless interaction between different SMOFs can be achieved to facilitate the management of NF instances.

[0165] Figure 5 is a diagram of an example environment 500 in which the system and / or method described herein may be implemented. As shown in Figure 5, the environment 500 may include a user device 510, a platform 520, and a network 530. The devices in environment 500 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In embodiments, any functions and operations described above with reference to Figures 2-4 may be performed by any combination of the elements illustrated in Figure 5.

[0166] User device 510 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information related to platform 520. For example, user device 510 may include computing devices (e.g., desktop computers, laptop computers, tablet computers, handheld computers, smart speakers, servers, etc.), mobile phones (e.g., smartphones, wireless phones), wearable devices (e.g., smart glasses or smartwatches), or similar devices. In some implementations, user device 510 may receive information from and / or transmit information to platform 520.

[0167] Platform 520 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, Platform 520 may include a cloud server or a group of cloud servers. In some implementations, Platform 520 may be designed to be modular so that certain software components can be swapped (in or out) depending on specific needs. Thus, Platform 520 may be easily and / or quickly reconfigured for different applications.

[0168] In some implementations, as shown, platform 520 may be hosted in a cloud computing environment 522. Although the implementations described herein describe platform 520 as being hosted in a cloud computing environment 522, in some implementations, platform 520 may not be cloud-based (i.e., it may be implemented outside a cloud computing environment) or may be partially cloud-based.

[0169] The cloud computing environment 522 includes an environment that hosts platform 520. The cloud computing environment 522 may provide services that do not require end-user (e.g., user device 510) knowledge of the physical location and configuration of the systems and / or devices that host platform 520, such as computation, software, data access, and storage. As shown, the cloud computing environment 522 may also include a group of computing resources 524 (collectively referred to as “computing resources 524” and individually as “computing resources 524”).

[0170] Computing resource 524 includes one or more personal computers, a cluster of computing devices, a workstation computer, a server device, or other types of computation and / or communication devices. In some implementations, computing resource 524 may host platform 520. Cloud resources may include compute instances running in computing resource 524, storage devices provided in computing resource 524, data transfer devices provided by computing resource 524, etc. In some implementations, computing resource 524 may communicate with other computing resources 524 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0171] As further shown in Figure 5, the computing resource 524 includes a group of cloud resources such as one or more applications ("APP") 524-1, one or more virtual machines ("VM") 524-2, virtualized storage ("VS") 524-3, and one or more hypervisors ("HYP") 524-4. While this embodiment refers to virtualized network functionality, one or more other embodiments are understood to be implemented in at least one of the following: containers, cloud-native services, one or more container platforms, etc. For example, in one or more other embodiments, any of the aforementioned components (e.g., nodes, E2 nodes, SMO functionality, RIC, systems, devices, etc.) may be software-based components deployed or hosted in a server cluster, such as a hybrid cloud server or data center server. The software-based components may be containerized and deployed and controlled by one or more machines called "nodes" that run containerized network elements and are addressable. In this regard, the server cluster may include at least one master node and several worker nodes. Here, the master node controls and manages the associated set of worker nodes.

[0172] Application 524-1 includes one or more software applications that may be provided to or accessed by the user device 510. Application 524-1 may eliminate the need to install and run software applications on the user device 510. For example, Application 524-1 may include any other software that can be provided via the platform 520 and its associated software and / or the cloud computing environment 522. In some implementations, one application 524-1 may send and receive information to and from one or more other applications 524-1 via a virtual machine 524-2.

[0173] The virtual machine 524-2 includes a software implementation of a device (e.g., a computer) that runs a program like a physical device. Depending on the extent to which the virtual machine 524-2 is used and its correspondence to any real-world device, the virtual machine 524-2 may be a system virtual machine or a process virtual machine. A system virtual machine may provide a complete system platform that supports the execution of a complete operating system ("OS"). A process virtual machine may run a single program or support a single process. In some implementations, the virtual machine 524-2 may run on behalf of a user (e.g., a user device 510) and manage the infrastructure of a cloud computing environment 522, such as data management, synchronization, or long-duration data transfer.

[0174] Virtualized storage 524-3 includes one or more storage systems and / or one or more devices or computing resources 524 that use virtualization technology within the storage systems. In some implementations, within the context of the storage system, the types of virtualization may include block virtualization and file virtualization. Block virtualization may represent an abstraction (or isolation) of logical storage from physical storage so that the storage system may be accessed without considering the physical storage or heterogeneous structure. Isolation can provide administrators of the storage system with flexibility in managing storage for end users. File virtualization may remove the dependency between data accessed at the file level and the location where the files are physically stored. This may enable optimized storage usage, server consolidation, and / or performance of non-destructive file migration.

[0175] The hypervisor 524-4 may provide hardware virtualization technology that enables multiple operating systems (e.g., "guest operating systems") to run simultaneously on a host computer such as computing resource 524. The hypervisor 524-4 may present a virtual operating platform to the guest operating systems and may manage the execution of the guest operating systems. Multiple instances of various operating systems may share virtualized hardware resources.

[0176] Network 530 includes one or more wired and / or wireless networks. For example, Network 530 may include cellular networks (e.g., 5G networks, LTE (long-term evolution) networks, 3G networks, CDMA (code division multiple access) networks, etc.), PLMN (public land mobile network), local area networks (LANs), wide area networks (WANs), MAN (metropolitan area networks), telephone networks (e.g., PSTN (Public Switched Telephone Network), private networks, ad hoc networks, intranets, the Internet, fiber optic networks, etc.), and / or combinations of these or other types of networks.

[0177] The number and arrangement of devices and networks shown in Figure 5 are provided as an example. In practice, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or devices and / or networks in different arrangements than those shown in Figure 5. Furthermore, two or more devices shown in Figure 5 may be implemented within a single device, and a single device shown in Figure 5 may be implemented as multiple distributed devices. In addition or alternatively, a set of devices in environment 500 (e.g., one or more devices) may perform one or more functions that are described as being performed by other sets of devices in environment 500.

[0178] Figure 6 shows an example of the components of device 600. Device 600 may correspond to user device 510 and / or platform 520. As shown in Figure 6, device 600 may include a bus 610, a processor 620, memory 630, a storage component 640, an input component 650, an output component 660, and a communication interface 670.

[0179] Bus 610 includes components that enable communication between components of device 600. Processor 620 may be implemented in hardware, firmware, or a combination of hardware and software. Processor 620 may be a central processing unit (CPU), graphics processing unit (GPU), acceleration unit (APU), microprocessor, microcontroller, digital signal processor (DSP), FPGA (field-programmable gate array), ASIC (application-specific integrated circuit), or other types of processing components. In some implementations, processor 620 includes one or more processors that are programmable to perform functions. Memory 630 includes random access memory (RAM), read-only memory (ROM), and / or other types of dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory) that store information and / or instructions for use by processor 620.

[0180] The storage component 640 stores information and / or software related to the operation and use of device 600. For example, the storage component 640 may include, along with a corresponding drive, a hard disk (e.g., magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cartridge, magnetic tape, and / or other types of non-temporary computer-readable media. The input component 650 includes components that enable device 600 to receive information via user input (e.g., a touchscreen display, keyboard, keypad, mouse, buttons, switches, and / or a microphone). In addition or alternatively, the input component 650 may include sensors for measuring information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). The output component 660 includes components that provide output information from device 600 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).

[0181] The communication interface 670 includes transceiver-like components (e.g., a transceiver and / or separate receiver and transmitter) that enable device 600 to communicate with other devices via wired connections, wireless connections, or a combination of wired and wireless connections. The communication interface 670 enables device 600 to receive information from and / or provide information to other devices. For example, the communication interface 670 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a Universal Serial Bus (USB) interface, a Wi-Fi interface, a cellular network interface, and the like.

[0182] Device 600 may execute one or more processes described herein. Device 600 may execute these processes depending on a processor 620 that executes software instructions stored in a non-temporary computer-readable medium such as memory 630 and / or storage component 640. The computer-readable medium is defined herein as a non-temporary memory device. A memory device includes a memory space in a single physical storage device or a memory space distributed across multiple physical storage devices.

[0183] Software instructions may be read into memory 630 and / or storage component 640 from other computer-readable media or other devices via the communication interface 670. When executed, the software instructions stored in memory 630 and / or storage component 640 may cause the processor 620 to execute one or more processes described herein.

[0184] In addition, or instead of, wired circuits may be used to execute one or more of the processes described herein, either in place of or in combination with software instructions. Thus, the implementations described herein are not limited to any particular combination of hardware circuits and software.

[0185] The number and arrangement of components shown in Figure 6 are provided as an example. In practice, device 600 may include additional components, fewer components, different components, or components in different arrangements than those shown in Figure 6. In addition or alternatively, a set of components of device 600 (e.g., one or more components) may perform one or more functions that are described as being performed by other sets of components of device 600.

[0186] In the embodiments, any operation or process shown in Figures 2-4 may be implemented by or using any elements illustrated in Figures 5 and 6. Other embodiments are understood to be, but are not limited thereto, and may be implemented in a variety of different architectures (e.g., bare metal architecture, any cloud-based architecture, or deployment architectures such as Kubernetes, Docker, or OpenStack).

[0187] Use cases relating to one or more embodiments are further described below.

[0188] Use case: ORMO and RANOAM SMOF interaction

[0189] Use case background and goals

[0190] O-Cloud orchestration and management require seamless interaction with other SMO functions such as RANOAM, TE&IV, and Non-RT RIC SMOF. This use case focuses on interaction with RAN OAM SMOF.

[0191] Network functions are orchestrated by ORMO's NFO-related capabilities, but these NF applications are configured through the RAN OAM via the O1 interface. In the case of NF scaling in, before any NF deployment (i.e., NF instance) is terminated, the traffic associated with that NF deployment must be distributed among the remaining NF deployments. Here, the NFO needs to instruct the RAN OAM to drain the traffic of the NF deployment to be terminated. The RAN OAM checks the policy for distributing traffic among NF deployments through the NFO, Non-RT RIC, TE&IV, or other SMOFs such as the RAN OAM.

[0192] NF traffic draining is an example of the necessary interaction between ORMO and RAN OAM, and there may be many more examples, such as the following:

[0193] NFO -> RANOAM:DMS: To configure or reconfigure an NF post-NF instantiation.

[0194] NFO -> RANOAM: To inquire about the operational and administrative usage status of NF.

[0195] NFO -> RANOAM: NF status and health notifications.

[0196] NFO -> RANOAM: Response to actions initiated by RANOAM.

[0197] RANOAM -> NFO: Notifications regarding NF configuration, traffic draining, and fault reporting.

[0198] The following capabilities are essential for O-Cloud orchestration and management in relation to interactions with other RAN OAMs.

[0199] FOCOM / NFO to support the capability to receive notifications from RANOAM.

[0200] FOCOM / NFO supports the capability to configure NF deployment through RAN OAM.

[0201] RAN OAM to support the capability to receive notifications from ORMO SMOF.

[0202] RAN OAM to support the capability to send notifications to other SMOFs.

[0203] Entities / resources involved in the use case 1) SME SMOF a) In a decoupled service-based SMO architecture, the SME can be used as a universal SMOS that handles service management and exposure for any SMOS within the SMO. b) Authorization of SMOFs to determine which services an SMOF can discover, in order to support the ability to discover available services from an SMOF. c) Support for retrieving stored service information and performing filtering of available services based on selection criteria that may be provided by SMOF. 2) Non-RT RIC SMOF a) Support for monitoring and evaluating NF PM / FM / CM data via O1 and O2 for NF traffic draining. 3) ORMO SMOF (NFO and FOCOM) a) Support for registering capabilities related to NFO services with SMEs, etc. b) Support for receiving and sending necessary notifications about RANOAM SMOF regarding the NF deployment lifecycle. 4) O-Cloud (IMS and DMS) a) Support for receiving actions and feedback from ORMO SMOF (NFO and FOCOM) and implementing them on the O-Cloud platform via IMS and DMS. 5) Topology Exposure and Inventory Management (TE&IV) SMOF a) Support for updating topology exposures and inventories based on requests from other SMOFs. 6) RAN OAM SMOF a) Supporting requests from other SMOFs regarding services such as PM, FM, and CM. b) Notify other SMOFs of any changes mentioned in a CM request. 7) Service Orchestrator (SO) and Service Assurance (SA) SMOF a) Support for orchestrating the various procedures necessary for the interaction between RAN OAM-related functions and for service assurance based on NFO / FOCOM. b) The service provider (SO) uses a set of recipes to define the steps involved in generating the service, and executes these steps in sequence to ensure that the service is generated correctly. c) The Service Provider (SO) and Service Advisor (SA) will collaborate to ensure that network services are generated and maintained in a consistent and reliable manner. The SO will ensure that services are generated correctly, and the SA will ensure that they are performed as expected. This will lead to an overall improvement in the quality of service for network customers.

[0204] Scenario 1: Interaction of RAN OAM SMOF with NFO / FOCOM without rApp as SO and SA [Table 4] JPEG2026511517000008.jpg43170@startuml https: / / plantuml.com / sequence-diagram !pragma teoz true skinparam ParticipantPadding 5 skinparam BoxPadding 10 skinparam defaultFontSize 12 skinparam lifelineStrategy solid autonumber Box “O-Cloud” #lightseagreen participant “DMS” as DMS participant “IMS” as IMS End box Box "Service Management and Orchestration Framework" #gold Participant “ORMO SMOF\n(NFO & FOCOM)” as ORMO Participant “RANOAM SMOF” as OAM Participant “TE & IV SMOF” as TEIV Participant “SME” as SME Participant “DME” as DME Participant “Non-RT RIC SMOF” as nRT End box Box " O-RAN Nodes" #lightpink Participant "E2-Node(s)" as E2NODES End box group Service registeration Note over OAM RANOAM SMOF to register services Related to PM, FM ,CM with SME End note OAM -> SME : Register services SME -> OAM : Success (Service Profile ID) end group Service discovery Note over ORMO , SME ORMO SMOF i.e. NFO / FOCOM tp discover RANOAM related to services with SME . End note ORMO -> SME : < <r1>> Discover RANOAM SMOF Related services SME -> ORMO : < <r1>> Discovery Result end group ORMO to OAM Interaction for Traffic Draining Note over ORMO, OAM There are possible interactions such as there is need to to drain traffic from perticular instace of NF application End note Alt ORMO Initiates ORMO -> OAM : Drain NF traffic Else Non-RT RIC Initiates OAM -> nRT : Notify Drain NF traffic Note over OAM, nRT RANAOM receives request to drain traffic for particular instance of NF application RANOAM Notifies nRT about same in order to monitor PM / FM of respective NF application End note nRT <-> DME : Query & collect PM Data nRT <-> OAM : Query & collect FM / CM Data Note over OAM, E2NODES RANOAM to distribute traffic from target NF instance to be drained to other instances of NF instances End Note OAM -> E2NODES : < <o1>> Configure NF Traffic Distribution E2NODES -> E2NODES : Enforce NF\nTraffic Distribution E2NODES -> OAM : < <o1>> Completion of NF Traffic Distribution OAM -> nRT : Notify Completion of Drain NF traffic Note Over nRT, OAM Monitor performance of drained NF & evaluate Decision to rollback or any corrective action to recover desired performance of NF end note nRT -> nRT : Evaluate\nPerformance of NF nRT -> OAM : Successful Evaluation Report OAM -> ORMO : Completion of NF traffic draining ORMO -> DMS : Terminate NF Deployment end group Inventory Update ORMO <-> TEIV : Update Inventory End @enduml

[0205] Figures 7A to 7C illustrate a call flow diagram for the interaction between ORMO and RANOAM SMOF according to one embodiment. Figures 7A to 7C may also illustrate a use case for Scenario 1.

[0206] Scenario 2: Interaction of RAN OAM SMOF with NFO / FOCOM with rApp as SO and SA [Table 5] JPEG2026511517000010.jpg77170@startuml 'https: / / plantuml.com / sequence-diagram !pragma teoz true skinparam ParticipantPadding 5 skinparam BoxPadding 10 skinparam defaultFontSize 12 skinparam lifelineStrategy solid autonumber Box "O-Cloud” #lightseagreen participant "DMS” as DMS participant "IMS” as IMS End box Box "Service Management and Orchestration Framework" #gold Participant "ORMO SMOF\n(NFO & FOCOM)” as ORMO Participant "RANOAM SMOF” as OAM Participant "TE & IV SMOF” as TEIV Participant "SO SMOF” as SO Participant "SME” as SME Participant "DME” as DME Participant "Non-RT RIC SMOF” as nRT End box Box " O-RAN Nodes" #lightpink Participant "E2-Node(s)" as E2NODES End box group Service registeration Note over OAM RANOAM SMOF to register services Related to PM, FM ,CM with SME End note OAM -> SME : Register services SME -> OAM : Success (Service Profile ID) end group Service discovery Note over ORMO , SME ORMO SMOF i.e. NFO / FOCOM to discover SO&A related to services with SME . End note ORMO -> SME : < <r1>> Discover SOA SMOF Related services SME -> ORMO : < <r1>> Discovery Result end Note over ORMO, OAM There are possible interactions such as there is need to to drain traffic from particular instance of NF application End note Alt ORMO Initiates ORMO -> SO : Terminating & Redeploy NF Else Non-RT RIC Initiates Note over nRT, SO Non-RT RIC can detect issue with NF deployment or O-Cloud and requesting to terminate and redeploy NF End note nRT -> SO : Terminating & redeploy NF end Note over SO, TEIV SO can query details of NF traffic policy , IP details, etc. to provide details about traffic redistribution . Non-RT RIC can provide traffic redistribution policy. End note SO <-> TEIV : Query Topology details of NF & allocated resources SO <-> ORMO : Redeploy NF ORMO <-> DMS : Create NF Instance ORMO <-> SO : Notify Creation of NF Instance SO <-> OAM : Drain NF and Redistribute Traffic Group Non-RT RIC Data collection SO -> nRT : Notify Drain NF traffic Note Left RANAOM receives request to drain traffic for particular instance of NF application RANOAM SO Notifies nRT about same in order to monitor PM / FM of respective NF application End note nRT <-> DME : Query & collect PM Data nRT <-> OAM : Query & collect FM / CM Data Note over OAM, E2NODES RANOAM to distribute traffic from target NF instance to be drained to other instances of NF End Note End Group RAN OAM executes traffic draining OAM -> E2NODES : < <o1>> Configure NF Traffic Distribution E2NODES -> E2NODES : Enforce NF\nTraffic Distribution E2NODES -> OAM : < <o1>> Completion of NF Traffic Distribution OAM -> SO : Notify Completion of Drain NF traffic OAM -> nRT : Notify Completion of Drain NF traffic End Group Non-RT RIC as Assurance nRT -> nRT : Evaluate\nPerformance of NF Note left Monitor performace of drained NF & evaluate Decision to rollback or any corrective action to recover desired performance of NF end note Alt Successful nRT -> SO : Successful Evaluation Report Else Failed nRT -> SO : Failed Evaluation Report & revised policy or recommendation Note Over SO, nRT SO to execute revised policy or recommendation in similar manner as mentioned on previous steps end note End End SO <-> ORMO : Terminate NF Deployment ORMO <-> DMS : Terminate NF Deployment alt Inventory Update ORMO <-> TEIV : Update Inventory Else SO <-> TEIV : Update Inventory @enduml

[0207] Figures 8A to 8D illustrate a call flow diagram for the interaction between ORMO and RANOAM SMOF, including SO SMOF, according to one embodiment. Figures 8A to 8D may also illustrate a use case for Scenario 2.

[0208] Scenario 3: Interaction of RAN OAM SMOF with SOA to NFO / FOCOM [Table 6] JPEG2026511517000012.jpg75170@startuml https: / / plantuml.com / sequence-diagram !pragma teoz true skinparam ParticipantPadding 5 skinparam BoxPadding 10 skinparam defaultFontSize 12 skinparam lifelineStrategy solid autonumber Box "O-Cloud" #lightseagreen participant "DMS" as DMS participant "IMS" as IMS End box Box "Service Management and Orchestration Framework" #gold Participant "ORMO SMOF\n(NFO & FOCOM)" as ORMO Participant "RANOAM SMOF” as OAM Participant "TE & IV SMOF” as TEIV Participant "SOA SMOF” as SOA Participant "SME” as SME Participant "DME” as DME Participant "Non-RT RIC SMOF” as nRT End box Box " O-RAN Nodes" #lightpink Participant "E2-Node(s)" as E2NODES End box group Service registeration Note over OAM RANOAM SMOF to register services Related to PM, FM ,CM with SME End note OAM -> SME : Register services SME -> OAM : Success (Service Profile ID) end group Service discovery Note over ORMO , SME ORMO SMOF i.e. NFO / FOCOM to discover SO&A related to services with SME . End note ORMO -> SME : < <r1>> Discover SOA SMOF Related services SME -> ORMO : < <r1>> Discovery Result end Alt ORMO Initiates Note over ORMO, SOA ORMO detect issue and there is need to drain traffic from particular instance of NF application End note ORMO -> SOA : Need to Terminate & Redeploy NF Else SOA Initiates Note over ORMO, SOA SO can detect issue with NF deployment based on automation algorithm For service assurance ,then requesting to terminate and redeploy NF End note SOA -> SOA : Terminating & redeploy NF end Note over TEIV, SOA SO to query details of NF traffic policy , IP details, etc., to provide details about traffic redistribution . Create traffic redistribution policy. End note SOA <-> TEIV : Query Resource details of NF SOA <-> ORMO : Redeploy NF SOA <-> OAM : Distribute Traffic SOA -> nRT : Notify Drain NF traffic Note over OAM, nRT RANAOM receives request to drain traffic for particular instance of NF application RANOAM Notifies nRT about same in order to monitor PM / FM of respective NF application End note Group SOA Data collection SOA <-> DME : Query & collect PM Data SOA <-> OAM : Query & collect FM / CM Data End Group RAN OAM Executes traffic draining Note over OAM, E2NODES RANOAM to distributes traffic from target NF instance to be drained to other instances of NF instances End Note OAM -> E2NODES : < <o1>> Configure NF Traffic Distribution E2NODES -> E2NODES : Enforce NF\nTraffic Distribution E2NODES -> OAM : < <o1>> Completion of NF Traffic Distribution OAM -> SOA : Notify Completion of Drain NF traffic OAM -> nRT : Notify Completion of Drain NF traffic End Alt Successful Note Over SOA Monitor performance of drained NF & evaluate Decision to rollback or any corrective action to recover desired performance of NF end note SOA -> SOA : Successful Evaluation Report Else Failed SOA -> SOA : Failed Evaluation Report &\n revised policy or recommendation End SOA <-> ORMO : Terminate NF Deployment ORMO <-> DMS : Terminate NF Deployment alt Inventory Update ORMO <-> TEIV : Update Inventory Else SOA <-> TEIV : Update Inventory End @enduml

[0209] Figures 9A to 9C illustrate a call flow diagram regarding the interaction between RANOAM SMOF including ORMO and SOA SMOF according to an embodiment. Figures 9A to 9C may illustrate a use case for Scenario 3.

[0210] 7 Recommended Functional Requirements

[0211] 7.x ORMOF Requirements [Table 7]

[0212] 7.x NRTRF Requirements [Table 8]

[0213] 7.x SOAF Requirements [Table 9]

[0214] 7.x SOF Requirements [Table 10]

[0215] The above disclosure provides illustration and description, but is not intended to be comprehensive or to limit the implementation to the exact form disclosed. Changes and modifications are possible in light of the above disclosure or may be obtained from the implementation of the implementation.

[0216] Some embodiments may also relate to systems, methods, and / or computer-readable media at a technical level of any possible integration. Furthermore, one or more of the above components may be implemented as instructions that are stored on a computer-readable medium and are executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-temporary storage medium (or medium) that stores computer-readable program instructions for causing a processor to perform an operation.

[0217] A computer-readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital multipurpose disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooves on which instructions are recorded, or any suitable combination thereof. The computer-readable storage medium used herein is not to be interpreted as a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmitting media (e.g., light pulses passing through fiber optic cables), or electrical signals transmitted through wires.

[0218] The computer-readable program instructions described herein may be downloaded from computer-readable storage media to each computing / processing device, or downloaded to an external computer or external storage device via a network such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer-readable program instructions from the network and transfers them to storage in the computer-readable storage media within each computing / processing device.

[0219] The computer-readable program code / instructions for performing the operation may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, procedural programming languages ​​such as the C programming language, or similar programming languages. The computer-readable program instructions may be executed as a standalone software package, either entirely on the user's computer, partially on the user's computer, partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or wide area network (WAN), and the connection may be to an external computer (for example, via the Internet using an Internet Service Provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, an FPGA (field-programmable gate array), or a programmable logic array (PLA) may execute computer-readable program instructions by utilizing state information of computer-readable program instructions to personalize the electronic circuit in order to perform a side or operation.

[0220] These computer-readable program instructions may be provided to a general-purpose computer, a dedicated computer, or a processor of another programmable data processing device to generate a device such that instructions executed via the processor of a computer or other programmable data processing device generate means for implementing functions / actions described in flowcharts and / or block diagrams (one or more blocks). These computer-readable program instructions may be stored on a computer-readable storage medium on which the instructions are stored can be instructed to make a computer, a programmable data processing device, and / or other device function in a particular manner such that the storage medium containing the instructions contains a work containing instructions that implement aspects of functions / actions described in flowcharts and / or block diagrams (one or more blocks).

[0221] These computer-readable program instructions may be loaded onto a computer, other programmable device, or other device so that a series of operational steps are executed on the computer, other programmable device, or other device to generate a computer-implemented process in which instructions executed on the computer, other programmable device, or other device implement the functions / actions described in the flowchart and / or block diagram (one or more blocks).

[0222] The illustrated flowcharts and block diagrams illustrate the architecture, functions, and operations of possible implementations of systems, methods, and computer-readable media according to various embodiments. Here, each block in the flowchart or block diagram may represent a microservice, module, segment, or portion of instructions containing one or more executable instructions to implement a particular logical function. The methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or different arrangements of blocks than those shown in the diagrams. In some alternative implementations, the functions shown in the blocks may occur outside the order shown in the diagrams. For example, two blocks shown consecutively may actually be executed simultaneously or substantially simultaneously, depending on the functions involved, or the blocks may be executed in reverse order. Each block in the illustrated block diagrams and / or flowcharts, and combinations of blocks in the illustrated block diagrams and / or flowcharts, may be implemented by a system based on dedicated hardware that performs a particular function or action, or by executing a combination of dedicated hardware and computer instructions.

[0223] It is evident that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

[0224] Various aspects of the embodiment

[0225] Various further aspects and features of the embodiments of this disclosure may be defined by the following items: Item 1: A method for managing the interaction between the O-Cloud Resource Management and Orchestration (ORMO) Service Management Orchestration function (SMOF) and the Radio Access Network Operations Administration Maintenance (RANOAM) function, The aforementioned ORMO receives SMOF-related services from Service Management and Exposure (SME), The ORMO sends a request to the SMOF to drain traffic from at least one network function (NF), The ORMO sends a request to the Topology Exposure and Inventory Management (TE / IV) to update the inventory, A method that includes this. Item 2: The aforementioned SMOF is a RANOAM SMOF. Upon receiving the request from the ORMO, the RANOAM SMOF is configured to notify the non-real-time (nRT) RIC SMOF of the request to drain the traffic of at least one NF. Upon notification of the request to drain the traffic of at least one NF, the nRT RIC SMOF is configured to query and collect performance management (PM) data from the data management entity (DME) and fault management (FM), and configuration management (CM) data from the RANOAM SMOF. The method described in item 1. Item 3: Upon receiving the FM and CM data, the RANOAM SMOF is configured to transmit the NF traffic distribution configuration to the E2 node. The E2 node is configured to apply NF traffic allocation based on the NF traffic allocation configuration in order to drain at least one NF, and to send a notification to the RANOAM SMOF that the application of the NF traffic allocation has been completed. The method described in item 2. Item 4: The method according to item 3, wherein upon receiving the notification that the NF traffic allocation has been completed, the RANOAM SMOF is configured to forward the notification that the NF traffic allocation has been completed to the nRT RIC SMOF. Item 5: The method according to item 4, wherein, upon receiving notification from the RANOAM SMOF that the NF traffic distribution has been completed, the nRT RIC SMOF is configured to evaluate the performance of the drained at least one NF and, based on the evaluated performance, send a report to the RANOAM SMOF recommending whether or not to roll back the NF traffic distribution configuration. Item 6: The method according to item 5, wherein upon receiving the aforementioned report, the RANOAM SMOF is configured to send a notification to the ORMO indicating that traffic draining has been completed. Item 7: The method of item 6, further comprising the ORMO sending a request to the DMS to terminate the at least one NF deployment upon receiving the notification from the RANOAM SMOF. Item 8: A method for managing the interaction between the O-Cloud Resource Management and Orchestration (ORMO) Service Management Orchestration function (SMOF) and the Radio Access Network Operations Administration Maintenance (RANOAM) function, Through the aforementioned ORMO, services related to Service Orchestration (SO) SMOF are received from Service Management and Exposure (SME), The ORMO sends a request to the SO SMOF to terminate and redeploy at least one network function (NF), The ORMO sends a request to the Topology Exposure and Inventory Management (TE / IV) to update the inventory, A method that includes this. Item 9: The method according to item 8, wherein, upon receiving the request from the ORMO, the SO SMOF is configured to query the topology details of the resources allocated from the at least one NF and the TE / IV, and to send a request to the ORMO to redeploy the at least one NF. Item 10: When the SO SMOF receives the request to redeploy at least one of the aforementioned NFs, The aforementioned ORMO sends a request to the Deployment Management Service (DMS) to create a new NF instance, The ORMO sends a notification to the SO SMOF that the new NF instance has been created, The method described in item 9, which further includes the following. Item 11: Upon receiving the notification from the ORMO that the new NF instance has been created, the SO SMOF is configured to send a request to the RANOAM SMOF to drain the at least one NF. Upon receiving the request from the SO SMOF to drain the traffic of at least one NF, the RANOAM SMOF is configured to notify the non-real-time (nRT) RIC SMOF of the request to drain the traffic of at least one NF. Upon notification of the request to drain the traffic of at least one NF, the nRT RIC SMOF is configured to query and collect performance management (PM) data from the data management entity (DME) and fault management (FM), and configuration management (CM) data from the RANOAM SMOF. The method described in item 10. Item 12: Upon receiving the FM and CM data, the RANOAM SMOF is configured to transmit the NF traffic distribution configuration to the E2 node. The E2 node is configured to apply NF traffic allocation based on the NF traffic allocation configuration in order to drain at least one NF, and to send a notification to the RANOAM SMOF that the application of the NF traffic allocation has been completed. Upon receiving the notification that the NF traffic allocation has been completed, the RANOAM SMOF is configured to forward the notification of completion of the NF traffic allocation to the SO SMOF and / or the nRT RIC SMOF. The method described in item 11. Item 13: Upon receiving notification from the RANOAM SMOF that the NF traffic distribution has been completed, the nRT RIC SMOF is configured to evaluate the performance of the drained at least one NF and, based on the evaluated performance, send a report to the SO SMOF recommending whether or not to roll back the NF traffic distribution configuration. Upon receiving the aforementioned report, the SO SMOF is configured to send a request to the ORMO to terminate the at least one NF deployment. The method described in item 12. Item 14: The method of item 13, further comprising the ORMO sending a request to the DMS to terminate the deployment of the at least one NF when it receives such a request from the SO SMOF. Item 15: A method for managing the interaction between the O-Cloud Resource Management and Orchestration (ORMO) Service Management Orchestration function (SMOF) and the Radio Access Network Operations Administration Maintenance (RANOAM) function, Through the aforementioned ORMO, the Service Management and Exposure (SME) will receive services related to Service Orchestration and Assurance (SOA) SMOF, The ORMO sends a request to the SOA SMOF to drain traffic from at least one network function (NF), The ORMO sends a request to the Topology Exposure and Inventory Management (TE / IV) to update the inventory, A method that includes this. Item 16: The method according to item 15, wherein upon receiving the request from the ORMO, the SOA SMOF is configured to query the topology details of the resources allocated from the at least one NF and the TE / IV, send a request to the ORMO to redeploy the at least one NF, and send a request to the RANOAM SMOF to distribute the traffic. Item 17: Upon receiving the request from the SOA SMOF to distribute the aforementioned traffic, the RANOAM SMOF is configured to notify the non-real-time (nRT) RIC SMOF of the request to drain the traffic of at least one NF. Upon notification of the request to drain the traffic of at least one NF, the nRT RIC SMOF is configured to query and collect performance management (PM) data from the data management entity (DME) and fault management (FM), and configuration management (CM) data from the RANOAM SMOF. The method described in item 16. Item 18: Upon receiving the FM and CM data, the RANOAM SMOF is configured to transmit the NF traffic distribution configuration to the E2 node. The E2 node is configured to apply NF traffic allocation based on the NF traffic allocation configuration in order to drain at least one NF, and to send a notification to the RANOAM SMOF that the application of the NF traffic allocation has been completed. Upon receiving the notification that the NF traffic allocation has been completed, the RANOAM SMOF is configured to forward the notification to the SOA SMOF and / or the nRT RIC SMOF. The method described in item 17. Item 19: The method according to item 18, wherein upon receiving the notification from the RANOAM SMOF that the NF traffic distribution has been completed, the nRT RIC SMOF is configured to evaluate the performance of the drained at least one NF and, based on the evaluated performance, send a report to the SOA SMOF recommending whether or not to roll back the NF traffic distribution configuration.

[0226] Item 20: The method according to item 19, wherein upon receiving the report, the SOA SMOF is configured to send a request to the ORMO to terminate the at least one NF deployment.

[0227] In light of the above teachings, it can be understood that many modifications and variations of this disclosure are possible. It is clear that this disclosure may be implemented in a manner different from that specifically described herein, within the scope of the attached items.

Claims

1. A method for managing the interaction between the O-Cloud Resource Management and Orchestration (ORMO) Service Management Orchestration function (SMOF) and the Radio Access Network Operations Administration Maintenance (RANOAM) function, Through the aforementioned ORMO, the Service Management and Exposure (SME) will receive services related to the SMOF, The ORMO sends a request to the SMOF to drain traffic from at least one network function (NF), The ORMO sends a request to the Topology Exposure and Inventory Management (TE / IV) to update the inventory, A method for providing this.

2. The aforementioned SMOF is a RANOAM SMOF. Upon receiving the request from the ORMO, the RANOAM SMOF is configured to notify the non-real-time (nRT) RIC SMOF of the request to drain the traffic of at least one NF. Upon notification of the request to drain the traffic of at least one of the aforementioned NFs, the nRT RIC SMOF is configured to query and collect performance management (PM) data from the data management entity (DME) and fault management (FM), and configuration management (CM) data from the RANOAM SMOF. The method according to claim 1.

3. Upon receiving the FM and CM data, the RANOAM SMOF is configured to transmit the NF traffic distribution configuration to the E2 node. The E2 node is configured to apply NF traffic allocation based on the NF traffic allocation configuration in order to drain at least one NF, and to send a notification to the RANOAM SMOF that the application of the NF traffic allocation has been completed. The method according to claim 2.

4. The method according to claim 3, wherein upon receiving the notification that the NF traffic allocation has been completed, the RANOAM SMOF is configured to forward the notification that the NF traffic allocation has been completed to the nRT RIC SMOF.

5. The method according to claim 4, wherein upon receiving the notification from the RANOAM SMOF that the NF traffic distribution has been completed, the nRT RIC SMOF is configured to evaluate the performance of the drained at least one NF and, based on the evaluated performance, send a report to the RANOAM SMOF recommending whether or not to roll back the NF traffic distribution configuration.

6. The method according to claim 5, wherein upon receiving the report, the RANOAM SMOF is configured to send a notification to the ORMO indicating that traffic draining has been completed.

7. The method according to claim 6, further comprising the ORMO sending a request to the Deployment Management Service (DMS) to terminate the at least one NF deployment upon receiving the notification from the RANOAM SMOF.

8. A method for managing the interaction between the O-Cloud Resource Management and Orchestration (ORMO) Service Management Orchestration function (SMOF) and the Radio Access Network Operations Administration Maintenance (RANOAM) function, Through the aforementioned ORMO, services related to Service Orchestration (SO) SMOF are received from Service Management and Exposure (SME), The ORMO sends a request to the SO SMOF to terminate and redeploy at least one network function (NF), The ORMO sends a request to the Topology Exposure and Inventory Management (TE / IV) to update the inventory, A method for providing this.

9. The method of claim 8, wherein upon receiving the request from the ORMO, the SO SMOF is configured to query the topology details of the resources allocated from the at least one NF and the TE / IV, and to send a request to the ORMO to redeploy the at least one NF.

10. When the SO SMOF receives the request to redeploy at least one of the aforementioned NFs, The aforementioned ORMO sends a request to the Deployment Management Service (DMS) to create a new NF instance, The ORMO sends a notification to the SO SMOF that the new NF instance has been created, The method according to claim 9, further comprising:

11. Upon receiving the notification from the ORMO that the new NF instance has been created, the SO SMOF is configured to send a request to the RANOAM SMOF to drain the at least one NF. Upon receiving the request from the SO SMOF to drain the traffic of at least one NF, the RANOAM SMOF is configured to notify the non-real-time (nRT) RIC SMOF of the request to drain the traffic of at least one NF. Upon notification of the request to drain the traffic of at least one of the aforementioned NFs, the nRT RIC SMOF is configured to query and collect performance management (PM) data from the data management entity (DME) and fault management (FM), and configuration management (CM) data from the RANOAM SMOF. The method according to claim 10.

12. Upon receiving the FM and CM data, the RANOAM SMOF is configured to transmit the NF traffic distribution configuration to the E2 node. The E2 node is configured to apply NF traffic allocation based on the NF traffic allocation configuration in order to drain at least one NF, and to send a notification to the RANOAM SMOF that the application of the NF traffic allocation has been completed. Upon receiving the notification that the NF traffic allocation has been completed, the RANOAM SMOF is configured to forward the notification to the SO SMOF and / or the nRT RIC SMOF. The method according to claim 11.

13. Upon receiving notification from the RANOAM SMOF that the NF traffic distribution has been completed, the nRT RIC SMOF is configured to evaluate the performance of the drained at least one NF and, based on the evaluated performance, send a report to the SO SMOF recommending whether or not to roll back the NF traffic distribution configuration. Upon receiving the aforementioned report, the SO SMOF is configured to send a request to the ORMO to terminate the at least one NF deployment. The method according to claim 12.

14. The method of claim 13, further comprising the ORMO sending a request to the DMS to terminate the deployment of the at least one NF when it receives such a request from the SO SMOF.

15. A method for managing the interaction between the O-Cloud Resource Management and Orchestration (ORMO) Service Management Orchestration function (SMOF) and the Radio Access Network Operations Administration Maintenance (RANOAM) function, Through the aforementioned ORMO, the Service Management and Exposure (SME) will receive services related to Service Orchestration and Assurance (SOA) SMOF, The ORMO sends a request to the SOA SMOF to drain traffic from at least one network function (NF), The ORMO sends a request to the Topology Exposure and Inventory Management (TE / IV) to update the inventory, A method for providing this.

16. The method according to claim 15, wherein upon receiving the request from the ORMO, the SOA SMOF is configured to query the topology details of the resources allocated from the at least one NF and the TE / IV, send a request to the ORMO to redeploy the at least one NF, and send a request to the RANOAM SMOF to distribute the traffic.

17. Upon receiving the request from the SOA SMOF to distribute the aforementioned traffic, the RANOAM SMOF is configured to notify the non-real-time (nRT) RIC SMOF of the request to drain the traffic of at least one NF. Upon notification of the request to drain the traffic of at least one of the aforementioned NFs, the nRT RIC SMOF is configured to query and collect performance management (PM) data from the data management entity (DME) and fault management (FM), and configuration management (CM) data from the RANOAM SMOF. The method according to claim 16.

18. Upon receiving the FM and CM data, the RANOAM SMOF is configured to transmit the NF traffic distribution configuration to the E2 node. The E2 node is configured to apply NF traffic allocation based on the NF traffic allocation configuration in order to drain at least one NF, and to send a notification to the RANOAM SMOF that the application of the NF traffic allocation has been completed. Upon receiving the notification that the NF traffic allocation has been completed, the RANOAM SMOF is configured to forward the notification to the SOA SMOF and / or the nRT RIC SMOF. The method according to claim 17.

19. The method according to claim 18, wherein upon receiving the notification from the RANOAM SMOF that the NF traffic distribution has been completed, the nRT RIC SMOF is configured to evaluate the performance of the drained at least one NF and, based on the evaluated performance, send a report to the SOA SMOF recommending whether or not to roll back the NF traffic distribution configuration.

20. The method according to claim 19, wherein upon receiving the report, the SOA SMOF is configured to send a request to the ORMO to terminate the at least one NF deployment.

Images