O-cloud software update

Abstract

Example embodiments of the present disclosure relate to Open RAN Cloud (O-RAN) software updates. According to example embodiments, a method may include receiving, by Federated Open Cloud Orchestration & Management (FOCOM), a request from a consumer to update at least one software associated with an Open RAN Cloud (O-Cloud) Platform, wherein the request comprises a reference to at least one O-Cloud Software Management template provided by the FOCOM; forwarding, by the FOCOM, the request to Infrastructure Management Service (IMS); and receiving, by the FOCOM, a response from IMS as to whether the at least one software was updated or not.

Description

O-CLOUD SOFTWARE UPDATETECHNICAL FIELD

[0001] The present disclosure relates to Open RAN Cloud (0-RAN) software update.BACKGROUND

[0002] The information disclosed in this background section is only for the enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

[0003] A radio access network (RAN) is an important component in a telecommunications system, as it 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-users to a core network. Traditionally, hardware and / or software of a particular RAN is vendor specific.

[0004] Open RAN (0-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software to a telecommunications system. Since different vendors are involved, the type of hardware and / or software provided may also be different. That is, different types of NEs may be provided by different vendors, and depending on the specific service, the NE could be virtualized in software form (e.g., virtual machine (VM)-based), or could be in physical hardware form (e.g., non-VM based).

[0005] To this end, O-RAN disaggregates the RAN functions into a centralized unit (CU), a distributed unit (DU), and a radio unit (RU). The CU may be a logical node for hosting Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet DataConvergence Protocol (PDCP) sublayers of the RAN. The DU may be a logical node hosting Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers of the RAN. The RU may be a physical node that converts radio signals from antennas to digital signals that can be transmitted over the Front Haul to a DU. Because these entities have open protocols and interfaces between them, they can be developed by different vendors.

[0006] RAN functions in the 0-RAN architecture may be controlled and optimized by a RAN Intelligent Controller (RIC). The RIC may be a software-defined component that implements modular applications to facilitate the multivendor operability required in the 0-RAN system, as well as to automate and optimize RAN operations. The RIC may be divided into two types: a non-real-time RIC (Non-RT RIC) and a near-real-time RIC (Near-RT RIC) .

[0007] The Non-RT RIC may be the control point of a non-real-time control loop and may operate on a timescale greater than 1 second within a Service Management and Orchestration (SMO) framework . Its functionalities may be implemented through modular applications called rApps, and may include: providing policy based guidance and enrichment across the Al interface, which is the interface that enables communication between the Non-RT RIC and the Near-RT RIC; performing data analytics; Artificial Intelligence / Machine Learning (AI / ML) training and inference for RAN optimization; and / or recommending configuration management actions over the 01 interface, which may be the interface that connects the SMO to RAN managed elements (e g., Near-RT RIC , 0-RAN Centralized Unit (O-CU), 0-RAN Distributed Unit (0-DU) , etc.).

[0008] The Near-RT RIC may operate on a timescale between 10 milliseconds and 1 second and may be coupled with the 0-DU , the O-CU (disaggregated into the O-CU control plane (O-CU-CP) and the O-CU user plane (O-CU-UP) ), and an open evolved NodeB (O-eNB) via the E2 interface. The Near-RT RIC may use the E2 interface to control the underlying RAN elements(E2 nodes / network functions (NFs)) over a near-real-time control loop. The Near-RT RIC may monitor, suspend / stop, override, and control the E2 nodes (O-CU, O-DU , and O-eNB ) via policies. For example, the Near-RT RIC may set policy parameters on activated functions of the E2 nodes. Further, the Near-RT RIC may host xApps to implement functions such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, security, etc.

[0009] Here, the O-CU-CP and the O-CU-UP may be coupled to each other via the El interface, and may be coupled to the O-DU via the Fl-c interface and Fl-u interface, respectively. Further, the O-RU may be coupled to the O-DU via the Open Fronthaul (OF) Control (C), User (U), Synchronization (S), and Management (M) Planes, and may be coupled to the SMO via the OF M-Plane.

[0010] The two types of RICs work together to optimize the 0-RAN. For example, the Non-RT RIC may provide the policies, data, and AI / ML models enforced and used by the Near-RT RIC for RAN optimization, and the Near-RT RIC may return policy feedback (i.e., how the policy set by the Non-RT RIC works).

[0011] As mentioned above, the Non-RT RIC may be located within the SMO framework , which manages and orchestrates RAN elements. Specifically, the SMO may manage and orchestrate what is referred to as the O-Ran Cloud (O-Cloud). The O-Cloud may be a collection of physical RAN nodes that host the RICs, O-CUs, and O-DUs, the supporting software components (e.g., the operating systems and runtime environments), and the SMO itself. In other words, the SMO may manage the O-Cloud from within. The 02 interface may be the interface between the SMO and the O-Cloud it resides in. Through the 02 interface, the SMO may provide infrastructure management services (IMS) and deployment management services (DMS).

[0012] FIG. 1 illustrates an example decoupled SMO architecture for O-RAN according to the related art. The SMO may comprise services (SMOS) that may communicate with each other via a communication interface (labeled as SMOS communication in FIG. 1). NFO and FOCOM may be in communication with O-Cloud services (not illustrated) via an 02 interface. RAN NF may consist of one or more RAN NF 0AM services, which may implement functions responsible for Operations, Administration, Maintenance (0AM). Service Management and Exposure (SME) 240, R1 Related Services, rApps, Data Management and Exposure (DME), AI / ML workflow, and Al -related services may be services that operate in Non-RT RIC.

[0013] In the related art, software within O-Cloud, and ZMS / DMS in SMO may need to be managed. Typically in the related art, this is performed using a non-declarative approach, wherein the device or component itself is responsible for updating the software.SUMMARY

[0014] The systems in the related art do not consider using or how to use a declarative approach (e.g., a centralized system) for managing O-Cloud, IMS and DMS software updates. In particular, there is no process provided in the related art for using a Northbound Interface (NBI) and related Service Management and Orchestration Services (SMOS) for requesting and updating the software in the O-Cloud platform and related components.

[0015] Furthermore, there is a lack of using templates in the related art for O-Cloud software updates, which may hinder compliance and operational requirements for managing software updates.

[0016] Accordingly, there is a need for a declarative and more streamlined approach to updating and managing O-Cloud software updates.

[0017] According to example embodiments, a method may include receiving, by Federated Open Cloud Orchestration & Management (FOCOM), a request from a consumer to update at least one software associated with an Open RAN Cloud (O-Cloud) Platform, wherein the request comprises a reference to at least one O-Cloud Software Management template provided by the FOCOM; forwarding, by the FOCOM, the request to Infrastructure Management Service (IMS); and receiving, by the FOCOM, a response from IMS as to whether the at least one software was updated or not.

[0018] Based on the above example embodiments, a declarative approach is provided for updating software, which introduces the implementation of the NBI to enable the initiation of the Software Update procedure, thereby streamlining and standardizing the process.

[0019] According to embodiments, a Federated Open Cloud Orchestration & Management (FOCOM) may be provided and configured to: receive a request from a consumer to update at least one software associated with an Open RAN Cloud (O-Cloud) Platform, wherein the request includes a reference to at least one O-Cloud Software Management template provided by the FOCOM; forward the request to Infrastructure Management Service (IMS); and receive a response from IMS as to whether the at least one software was updated or not.

[0020] According to embodiments, a non-transitory computer-readable recording medium having recorded thereon instructions executable to perform a method may be provided, the method including: receiving, by Federated Open Cloud Orchestration & Management (FOCOM), a request from a consumer to update at least one software associated with an Open RAN Cloud (O-Cloud) Platform, wherein the request includes a reference to at least one O-Cloud Software Management template provided by the FOCOM; forwarding, by the FOCOM, the request to InfrastructureManagement Service (IMS); and receiving, by the FOCOM, a response from IMS as to whether the at least one software was updated or not.

[0021] Additional aspects will be set forth in part in the description that follows and, in part, will be apparent from the description, or may be realized by practice of the presented embodiments of the disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Features, aspects, and advantages of embodiments of the disclosure will be described below with reference to the accompanying drawings, in which like reference numerals denote like elements, and wherein:

[0023] FIG. 1 illustrates an example O-RAN architecture according to the related art, in which one or more example embodiments may be applied;

[0024] FIG. 2 illustrates a callflow diagram for updating an O-Cloud Platform Software, according to one or more example embodiments;

[0025] FIG. 3 illustrates a callflow diagram for an O-Cloud software update template request at the consumer / producer level, according to one or more example embodiments;

[0026] FIG. 4 illustrates a callflow diagram for an O-Cloud Platform Software Update at the consumer / producer level, according to one or more example embodiments;

[0027] FIG. 5 illustrates a callflow diagram for an O-Cloud software update template suspension request at the consumer / producer level, according to one or more example embodiments;

[0028] FIG. 6 illustrates a callflow diagram for updating an IMS Software, according to one or more example embodiments;

[0029] FIG. 7 illustrates a callflow diagram for updating a DMS Software, according to one or more example embodiments;

[0030] FIG. 8 illustrates a callflow diagram of an example use-case for updating an O-Cloud platform software, according to one or more example embodiments;

[0031] FIG. 9 illustrates a callflow diagram of an example use-case for retrieving available O-Cloud platform software templates, according to one or more example embodiments;

[0032] FIG. 10 illustrates a callflow diagram of an example use-case for retrieving current O-Cloud software running information, according to one or more example embodiments;

[0033] FIG. 11 illustrates a callflow diagram of an example use-case for updating IMS software, according to one or more example embodiments;

[0034] FIG. 12 illustrates a callflow diagram of an example use-case for updating DMS software, according to one or more example embodiments;

[0035] FIG. 13 illustrates a block diagram of an example method for updating a software in the O-Cloud, according to one or more example embodiments;

[0036] FIG. 14 illustrates a callflow diagram of an example use-case for performing a specific O-Cloud Platform Software Update, according to one or more example embodiments;

[0037] FIG. 15 illustrates a callflow diagram of an example use-case for retrieving available templates to Update O-Cloud software, according to one or more example embodiments;

[0038] FIG. 16 illustrates a callflow diagram of an example use-case for retrieving current O-Cloud Software running information, according to one or more example embodiments;

[0039] FIG. 17 illustrates a callflow diagram of an example use-case for performing a specific O-Cloud IMS software update, according to one or more example embodiments;

[0040] FIG. 18 illustrates a callflow diagram of an example use-case for performing a specific O-Cloud DMS software update, according to one or more example embodiments;

[0041] FIG. 19 illustrates a callflow diagram of an example use-case for suspending a specific O-Cloud IMS Software update, according to one or more example embodiments;

[0042] FIG. 20 illustrates a callflow diagram of an example use-case for performing a specific O-Cloud Platform Software Update, according to one or more example embodiments;

[0043] FIG. 21 illustrates a callflow diagram of an example use-case for cancelling a specific O-Cloud software update, according to one or more example embodiments;

[0044] FIG. 22 illustrates a block diagram of an example device for implementing one or more example embodiments; and

[0045] FIG. 23 illustrates a block diagram of an example environment for implementing one or more example embodiments.DETAILED DESCRIPTION

[0046] The following detailed description of example embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Further, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, the flowchart and description of operations provided below relate to one of the various embodiments. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that inother embodiments one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part).

[0047] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limited to the described implementations. 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 description herein.

[0048] Even though particular combinations of features are disclosed in the claims and / or in the specification, these combinations are not intended to limit the disclosure of implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of implementations includes each dependent claim in combination with every other claim in the claim set.

[0049] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. 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.” Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B]”, “[A] and / or [B]”, or “at least one of [A] or [B]”, are to be understood as including only A, only B, or both A and B.

[0050] It shall be noted that, descriptions of example embodiments of the present disclosure may include terms and names defined in one or more standard organizations, such as the 3rd Generation Partnership Project (3GPP) standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, the Open Radio Access Network (O-RAN) Alliance standard organization, and the like.

[0051] Example embodiments may describe the flow of updating / downgrading the O-Cloud Platform Software using an O-Cloud Software Management Template in a declarative approach. An update platform software stack of an existing O-Cloud Cluster may be utilized herein.

[0052] According to example embodiments, an O-Cloud Platform Software update request may be provided, which originates from the FOCOM and is transmitted to the IMS (Infrastructure Management System) within the O-Cloud. This operation may be a subset of an 02-IMS provisioning function (e.g., performed over the 02 interface), and targeting Platform Software Updates for an existing O-Cloud Cluster. Updates may include installing new software versions (for O-Cloud Platform Software, IMS and DMS software), and applying platform software patches for security or performance improvements.

[0053] According to example embodiments, an NBI SMO (Service Management Orchestration), may send an O-Cloud Platform Software Update request to FOCOM. This request may comprise a template, and may contain details such as the targeted software update area (e.g., O-Cloud Platform), the desired post-update status (activate, deactivate, or activate at a scheduled time), whether service interruptions are acceptable, the time for activation (immediate or scheduled), rollback version information, the software package name, and the O-Cloud identifier (ID) of the targeted instance.

[0054] Upon receiving the request, FOCOM may acknowledge it to confirm receipt and begins processing. The FOCOM may forward the software update request to the IMS for execution. The IMS may first conduct a feasibility check to ensure the update is practical under the current conditions, such as hardware compatibility and operational constraints. Once verified, the IMS may perform resource checks to confirm the availability of storage, compute, and network resources required for the update.

[0055] Following these checks, the IMS may initiate the software download procedure to retrieve the specified software package from the repository. Once downloaded, the update process may be executed based on the parameters provided in the request, such as activation timing and service interruption preferences. After the update is applied, the IMS may update its software inventory to reflect the new version and ensures all records are synchronized.

[0056] Finally, the IMS reports the outcome of the update process to FOCOM, including specifying whether it succeeded or failed. The FOCOM may then notifies NBI SMOs of the update status, providing the final confirmation of the operation’s result. This completes the software update procedure efficiently while adhering to the specified constraints and preferences.

[0057] Based on the above example embodiments, the specified O-Cloud may have its platform software updated as defined in the O-Cloud Template, ensuring compliance with operational requirements and maintaining seamless functionality across the O-Clod Node Cluster.

[0058] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely a portion of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure. Further descriptions of the features, components, configuration, operations, and implementations of the example embodiments of the present disclosure are provided in the following.

[0059] FIG. 2 illustrates a callllow diagram for updating an O-Cloud Platform Software, according to one or more example embodiments.

[0060] The callflow described in FIG. 2 illustrates an O-Cloud Platform Software Update (Upgrade or Downgrade) of a previously created and configured O-Cloud in the O-Cloud using an O-Cloud Template. This may include referencing a new or update O-Cloud Template and / or software version to update the cluster accordingly. The updated cluster may reflect changes in capabilities and / or capacities for workload deployments, aligning with the updated configuration. An additional goal may include notifying the requestor (typically the FOCOM) that the O-Cloud platform Software has been successfully updated.

[0061] According to embodiments, the entities which are involved may include an external consumer including Northbound Service Management Orchestration (NBI SMO) 200 which may initiate the software request, the Service Management Orchestration framework, which particularly includes FOCOM 210 acting as the consumer that will request for the O-Cloud platform software to be updated, and Infrastructure Management Services (IMS) 220, which will process the request for the O-Cloud Node platform software update. The O-Cloud and / or O-Cloud platform may refer to a targeted O-Cloud Note Cluster which is designed for executing the platform software update action.

[0062] It may be assumed that an existing O-Cloud platform has already been previously created, and that IMS 220 supports O-Cloud platform software updates, that is, IMS 220 should support seamless O-Cloud Platform Software Update with a robust rollback mechanism to ensure reliability and minimize disruptions. It may also be assumed that Network Function Deployment Migration Capability is provided, Network Functions (NF’s) should be migratable to alternate O-Cloud clusters to ensure service continuity and minimize disruptions during maintenance or updates.

[0063] Preconditions for executing the callflow may include the SMO being available and operational, the O-Cloud being operational and details thereof being known to the SMO, NF deployment migration which recommends that the deployed NF at the O-Cloud cluster (the target for the software update) be migrated to another O-Cloud cluster to avoid service outages, the IMS being available, and that the O-Cloud has connectivity and authorization for communicating with the SMO.

[0064] Referring to FIG. 2, at step 1, the O-Cloud Operator or NBI SMO 200 may initiate the O-Cloud platform software update request, and send it to FOCOM 210. FOCOM 210 may determine that an update is needed or receive instruction from NBI SMO 200 via NBI to trigger O-Cloud Platform Software update. It should be appreciated that at this stage, new or running software availability information may be known to the user (the O-Cloud Operator) by querying to the O-Cloud and fetching the running parameter schema, already know to SMOs via inventory function from O-Cloud, or inventory SMOS.

[0065] At step 2, FOCOM 210 acknowledges the O-Cloud Platform Software Update Request by generating and providing a unique O-Cloud Platform Update Request ID to the NBI SMO 200 as part of the response. Fhis unique ID may serve as a reference identifier for the specific software update operation. The same Update Request ID can be utilized by the NBI SMO 200 to initiate additional actions related to the update, such as cancelling the software update in case of changing operational requirements or unforeseen circumstances. By leveraging this identifier, NBI SMO 200 can efficiently manage and track the status of the update operation, ensuring precise control and operational flexibility throughout the update lifecycle

[0066] At step 3, FOCOM210 sends to the IMS 220 an O-Cloud Platform Software Update request. The update (Upgrade or Downgrade) request object may contain the reference of the O-Cloud Template along with all relevant parameters including Software version information which need to upgraded or downgraded.

[0067] At step 4, the IMS 220 sends an acknowledgement message to FOCOM 210 and begins to process O-Cloud Platform Software Update.

[0068] At step 5, an optional feasibility check may be performed by IMS 220, in the case that the O-Cloud Platform Software Update operation, the IMS 220 performs feasibility checks for related software update aspects.

[0069] At step 6, an optional resource verification check may be performed, the IMS 220 checks the resources associated and the IMS 220 processes the request which is asking for O-Cloud resource to facilitate O-Cloud platform software update.

[0070] At step 7, IMS 220 initiates the software download procedure. If the required software is not available in the local repository, the IMS 220 may trigger a process to download the necessary software from an external source.

[0071] At step 8, a response to the update O-Cloud Platform Software Request may be performed by executing the software update process by IMS 220. In case of software update failure, IMS 220 rolls back to the original version (the version which was running before initiating the software update). IMS 220 notifies SMO that IMS 220 failed in O-Cloud software update in this scenario. For example, IMS 220 then responds to the (upgrade or downgrade) O-Cloud Platform Software request with a response over the 02 IMS interface back to FOCOM 210.

[0072] At step 9, IMS 220 determines that O-Cloud Node has updated software and is in running state. IMS 220 may update its SW inventory. IMS 220 notifies the SMO that O-Cloud software has been updated and SMO may update its inventory accordingly.

[0073] At step 10, the O-Cloud Platform Software Update response is returned to the O-Cloud operator by SMO. This may be forwarded by FOCOM 210 to NBI SMO 200 in step 11. The response may specify for example, a success in which the O-Cloud Platform Software Update successfully, or failure in which the O-Cloud Platform Software Update has been rolled back to the original version.

[0074] Examples of possible exceptions which may occur include, but are not necessarily limited to:

[0075] O-CLOUD NOT FOUND - The requested O-Cloud ID was not found or does not exist in the O-Cloud.

[0076] UPDATE FAILED - Update of O-Cloud Platform Software Update could not be completed.

[0077] INSUFFICIENT RESOURCES TO PERFORM OPERATION - There are insufficient resources to perform the Update operation.

[0078] MALFORMED REQUEST - The request had an incorrect format and could not be processed by the IMS. The request to update the Provisioning Request Object is rejected.

[0079] Post conditions may include in the case of success: (1) SMO holds updated inventory, (2) O-Cloud Platform running with updated O-Cloud Platform software, (3) IMS holds updated SW inventory. In the case of failure, post conditions may include the O-Cloud software being rolled back to the original version.

[0080] According to embodiments, FOCOM 210 may enables seamless interactions with NBI SMO 200 by exposing specific capabilities through its Northbound interface. These interactions ensure that NBI SMO 200 can request, manage, and monitor platform-level services effectively. Examples of capabilities which may be exposed include:

[0081] Service Registration: FOCOM 210 advertises its available services to the Service Management Environment (SME). This enables NBI SMO 200 to discover and utilize FOCOM' 210’s offerings, such as software update management and query services, on demand. The registration process ensures a standardized mechanism for interaction, allowing services to be consumed multiple times without requiring re-registration.

[0082] Query Management: NBI SMO 200 can query FOCOM 210 to retrieve operational details such as, status of submitted service requests (e.g., software version query, current software update status etc.), availability of predefined templates for software updates, and metadata about existing configurations.

[0083] Template Software Update Management: FOCOM 210 may provide predefined templates to NBI SMO 200, offering a streamlined approach to initiating software updates. These templates may encapsulate configuration details, such as update constraints, rollback options, and activation schedules, ensuring consistency and reducing complexity in software update requests.

[0084] Suspend Software Update Request: NBI SMO 200 can issue a request to suspend an ongoing software update. This capability may be critical for addressing unforeseen issues during the update process or responding to changing operational requirements.

[0085] Callback URI Notification: FOCOM 210 supports a callback mechanism to notify NBI SMO 200 of important events and outcomes related to their software update requests.Notifications include acknowledgment of the request, updates on the progress of the update, and final success or failure status, including any rollback details if applicable.

[0086] According to embodiments, NBI SMO 200 may interact with FOCOM 210 to manage platform operations through the Southbound interface. These interactions may focus on querying software templates and sending requests to update or suspend platform software:

[0087] Sending O-Cloud Platform Software Template Query Request: NBI SMO 200 may send requests to FOCOM 210 to retrieve predefined templates for platform software updates. These templates provide a standardized approach, detailing configurations, supported versions, constraints, and operational policies for initiating updates. FOCOM 210 may process the query and returns the relevant templates, enabling NBI SMO 200 to select the most suitable configuration for their needs.

[0088] Sending O-Cloud Platform Software Update Request: NBI SMO 200 may interact with FOCOM 210 to initiate platform software updates. For update requests, detailed attributes such as target area, activation type, service interrupt policies, rollback versions, and software identifiers may be provided to ensure precise execution.

[0089] Sending O-Cloud Platform Software Suspend Request: NBI SMO 200 may interact with FOCOM 210 to initiate platform software updates suspend request ongoing update operations, for update requests, detailed attributes such as target area, activation type, service interrupt policies, rollback versions, and software identifiers are provided to ensure precise execution. Suspend requests allow NBI SMO 200 to temporarily pause or cancel ongoing and scheduled updates, this will be providing flexibility to address operational needs. FOCOM 210 processes these requests and provides feedback to ensure transparency and control during the operation

[0090] Examples of northbound and southbound interactions between NBI SMO 200 (as a consumer) and FOCOM 210 (as a producer) for SMOS are described with reference to FIG. 3-5 below, and example use-cases thereof are also described with reference to FIG. 8-12 below.

[0091] FIG. 3 illustrates a callflow diagram for an O-Cloud software update template request at the consumer / producer level, according to one or more example embodiments.

[0092] According to embodiments, the O-Cloud software update template may be a predefined structure for initiating software update requests. It may ensure consistency and provides the minimum required information elements to enable precise and efficient execution of update operations. Information elements which may be included include, but are not necessarily limited to:

[0093] O-Cloud ID: Identifies the specific O-Cloud instance targeted for the O-Cloud software update.

[0094] SW Name: Specifies the name of the software to be updated.

[0095] Service Attribute (Informative): Indicates the targeted software update area. (Example values: O-Cloud Platform, OS, FPGA, etc.)

[0096] Post Status: Describes the desired state of the software after the update. (Example values: Activate / Deactivate / Scheduled Activation)

[0097] Time to Activation: Specifies when the updated software should be activated. (Example values: Immediate / Scheduled (Specify Time))

[0098] Service Interrupt: Defines whether service interruptions are acceptable during the update process. (Example values: Accepted / Not Accepted)

[0099] Rollback to Version: Specifies the software version to revert to in case the update fails.

[0100] Referring now to FIG. 3, FOCOM SMOS acting as Consumer 300 and FOCOM SMOS acting as Producer 310 are provided.

[0101] At step 1, O-Cloud software update template request (including the update ID) is sent by Consumer 300 to Producer 310.

[0102] At step 2, upon receiving the software update template request from step 1, Producer 310 may either retrieve template and information from its cache, or interact with the IMS over the 02 interface to receive the same.

[0103] At step 3, the O-Cloud software update template request response (including the payload) may be retrieved by Consumer 300.

[0104] FIG. 4 illustrates a callflow diagram for an O-Cloud Platform Software Update at the consumer / producer level, according to one or more example embodiments.

[0105] FOCOM SMOS acting as Consumer 400 and FOCOM SMOS acting as Producer 410 are provided.

[0106] At step 1, O-Cloud software update request is sent by Consumer 400 to Producer 410.

[0107] At step 2, upon receiving the software update request from step 1, Producer 310 may send an acknowledge (ACK) back to Consumer 400.

[0108] At step 3, Producer 410, after performing the ACK, may request and interact with IMS over 02 interface to perform the O-Cloud Platform Software Update procedure.

[0109] At step 4, the Producer 410 may notify Consumer 400 about the O-Cloud Platform Software Update Status response.

[0110] FIG. 5 illustrates a callflow diagram for an O-Cloud software update template suspension request at the consumer / producer level, according to one or more example embodiments.

[0111] FOCOM SMOS acting as Consumer 500 and FOCOM SMOS acting as Producer 510 are provided.

[0112] At step 1, Consumer 500 may send an O-Cloud template software update request suspension request including an update ID to Producer 510.

[0113] At step 2, Producer 510 may either cancel the requested software update, or interact with IMS over 02 interface to suspend the software update request.

[0114] At step 3, the O-Cloud template software update suspension request response is sent to Consumer 500 as a payload.

[0115] FIG. 6 illustrates a callflow diagram for updating an IMS Software, according to one or more example embodiments.

[0116] The callflow described in FIG. 6 illustrates an IMS Software Update (Upgrade or Downgrade) of a previously created and configured O-Cloud in the O-Cloud using an O-Cloud Template. This may include referencing a new or update O-Cloud Template and / or software version to update the IMS software accordingly. The updated IMS software may reflect changes in capabilities and / or capacities for workload deployments, aligning with the updated configuration. An additional goal may include notifying the requestor (typically the FOCOM) that the IMS Software has been successfully updated.

[0117] According to embodiments, the entities which are involved may include an external consumer including NBI SMO 600 which may initiate the software request, the Service Management Orchestration framework, which particularly includes FOCOM 610 acting as theconsumer that will request for the IMS software to be updated, and IMS 620, which will process the request for the IMS software update. The O-Cloud and / or O-Cloud platform may refer to a targeted O-Cloud which is designed for executing the IMS software update action.

[0118] It may be assumed that an existing O-Cloud platform has already been previously created, and that IMS 620 supports IMS software updates, that is, IMS 620 should support seamless IMS Software Update with a robust rollback mechanism to ensure reliability and minimize disruptions.

[0119] Preconditions for executing the callflow may include the SMO being available and operational, the O-Cloud being operational and details thereof being known to the SMO, the IMS 620 being available, and that the O-Cloud has connectivity and authorization for communicating with the SMO.

[0120] Referring to FIG. 6, at step 1, the O-Cloud Operator or NBI SMO 600 may initiate the IMS software update request, and send it to FOCOM 610. FOCOM 610 may determine that an update is needed or receive instruction from NBI SMO 600 via NBI to trigger IMS Software update.

[0121] At step 2, FOCOM 610 acknowledges the IMS Software Update Request by generating and providing a unique IMS Software Update Request ID to the NBI SMO 600 as part of the response. This unique ID may serve as a reference identifier for the specific software update operation. The same Update Request ID can be utilized by the NBI SMO 600 to initiate additional actions related to the update, such as cancelling the software update in case of changing operational requirements or unforeseen circumstances. By leveraging this identifier, NBI SMO 600 can efficiently manage and track the status of the update operation, ensuring precise control and operational flexibility throughout the update lifecycle

[0122] At step 3, FOCOM 610 sends to the IMS 620 an IMS Software Update request. The update (Upgrade or Downgrade) request object may contain the reference of the O-Cloud Template along with all relevant parameters including Software version information which need to upgraded or downgraded.

[0123] At step 4, the IMS 620 sends an acknowledgement message to FOCOM 610 and begins to process IMS Software Update.

[0124] At step 5, an optional feasibility check may be performed by IMS 620, in the case that the IMS Software Update operation, the IMS 620 performs feasibility checks for related software update aspects.

[0125] At step 6, an optional resource verification check may be performed, the IMS 620 checks the resources associated and the IMS 620 processes the request which is asking for O-Cloud resource to facilitate IMS software update.

[0126] At step 7, IMS 620 initiates the software download procedure. If the required software is not available in the local repository, the IMS 620 may trigger a process to download the necessary software from an external source.

[0127] At step 8, a response to the update IMS Software Request may be performed by executing the software update process by IMS 620. In case of software update failure, IMS 620 rolls back to the original version (the version which was running before initiating the software update). IMS 620 notifies SMO that IMS 620 failed in IMS software update in this scenario. For example, IMS 620 then responds to the (upgrade or downgrade) IMS Software request with a response over the 02 IMS interface back to FOCOM 610.

[0128] At step 9, IMS 620 determines that O-Cloud Node has updated software and is in running state. IMS 620 may update its SW inventory. IMS 620 notifies the SMO that IMS software has been updated and SMO may update its inventory accordingly.

[0129] At step 10, the IMS Software Update response is returned to the O-Cloud operator by SMO. This may be forwarded by FOCOM 610 to NBI SMO 600 in step 11. The response may specify for example, a success in which the IMS Software Update successfully, or failure in which the IMS Software Update has been rolled back to the original version.

[0130] Examples of possible exceptions which may occur are similar to those described with reference to FIG. 2 above.

[0131] Post conditions may include in the case of success: (1) SMO holds updated inventory, (2) IMS running with updated IMS software, (3) IMS holds updated SW inventory. In the case of failure, post conditions may include the IMS software being rolled back to the original version.

[0132] FIG. 7 illustrates a callflow diagram for updating a DMS Software, according to one or more example embodiments.

[0133] The callflow described in FIG. 7 illustrates a DMS Software Update (Upgrade or Downgrade) of a previously created and configured O-Cloud in the O-Cloud using an O-Cloud Template. This may include referencing a new or update O-Cloud Template and / or software version to update the DMS Software accordingly. The updated DMS Software may reflect changes in capabilities and / or capacities for workload deployments, aligning with the updated configuration. An additional goal may include notifying the requestor (typically the FOCOM) that the DMS Software has been successfully updated.

[0134] According to embodiments, the entities which are involved may include an external consumer including NBI SMO 700 which may initiate the software request, the Service Management Orchestration framework, which particularly includes FOCOM 710 acting as the consumer that will request for the DMS Software to be updated, and IMS 720, which will process the request for the DMS Software update. The O-Cloud and / or O-Cloud platform may refer to a targeted O-Cloud which is designed for executing the DMS Software update action.

[0135] It may be assumed that an existing O-Cloud platform has already been previously created, and that IMS 720 supports DMS Software updates, that is, IMS 720 should support seamless DMS Software Update with a robust rollback mechanism to ensure reliability and minimize disruptions.

[0136] Preconditions for executing the callflow may include the SMO being available and operational, the O-Cloud being operational and details thereof being known to the SMO, the IMS 720 being available, the DMS being available, and that the O-Cloud has connectivity and authorization for communicating with the SMO.

[0137] Referring to FIG. 7, at step 1, the O-Cloud Operator or NBI SMO 700 may initiate the DMS Software update request, and send it to FOCOM 710. FOCOM 710 may determine that an update is needed or receive instruction from NBI SMO 700 via NBI to trigger DMS Software update.

[0138] At step 2, FOCOM 710 acknowledges the DMS Software Update Request by generating and providing a unique DMS Software Update Request ID to the NBI SMO 700 as part of the response. This unique ID may serve as a reference identifier for the specific software update operation. The same Update Request ID can be utilized by the NBI SMO 700 to initiate additional actions related to the update, such as cancelling the software update in case of changing operationalrequirements or unforeseen circumstances. By leveraging this identifier, NBI SMO 700 can efficiently manage and track the status of the update operation, ensuring precise control and operational flexibility throughout the update lifecycle

[0139] At step 3, FOCOM 710 sends to the IMS 720 a DMS Software Update request. The update (Upgrade or Downgrade) request object may contain the reference of the O-Cloud Template along with all relevant parameters including Software version information which need to upgraded or downgraded.

[0140] At step 4, the IMS 720 sends an acknowledgement message to FOCOM 710 and begins to process DMS Software Update.

[0141] At step 5, an optional feasibility check may be performed by IMS 720, in the case that the DMS Software Update operation, the IMS 720 performs feasibility checks for related software update aspects.

[0142] At step 6, an optional resource verification check may be performed, the IMS 720 checks the resources associated and the IMS 720 processes the request which is asking for O-Cloud resource to facilitate DMS Software update.

[0143] At step 7, IMS 720 initiates the software download procedure. If the required software is not available in the local repository, the IMS 720 may trigger a process to download the necessary software from an external source.

[0144] At step 8, a response to the update DMS Software Request may be performed by executing the software update process by IMS 720. In case of software update failure, IMS 720 rolls back to the original version (the version which was running before initiating the software update). IMS 720 notifies SMO that IMS 720 failed in DMS Software update in this scenario. Forexample, IMS 720 then responds to the (upgrade or downgrade) DMS Software request with a response over the 02 IMS interface back to FOCOM 710.

[0145] At step 9, IMS 720 determines that O-Cloud Node has updated software and is in running state. IMS 720 may update its SW inventory. IMS 720 notifies the SMO that DMS Software has been updated and SMO may update its inventory accordingly.

[0146] At step 10, the DMS Software Update response is returned to the O-Cloud operator by SMO. This may be forwarded by FOCOM 710 to NBI SMO 700 in step 11. The response may specify for example, a success in which the DMS Software Update successfully, or failure in which the DMS Software Update has been rolled back to the original version.

[0147] Examples of possible exceptions which may occur are similar to those described with reference to FIG. 2 above.

[0148] Post conditions may include in the case of success: (1) SMO holds updated inventory, (2) IMS running, (3) DMS holds updated SW inventory. In the case of failure, post conditions may include the DMS Software being rolled back to the original version.

[0149] FIG. 8 illustrates a callflow diagram of an example use-case for updating an O-Cloud platform software, according to one or more example embodiments. This may cover the use-case wherein a consumer needs the FOCOM SMOS to update the O-Cloud platform software so that they can understand and enhance the capability and characteristics of the O-Cloud.

[0150] FOCOM SMOS acting as Consumer 800, and FOCOM SMOS acting as Producer 810 may be provided.

[0151] At step 1, Consumer 800 may request to perform a specific O-Cloud platform software update.

[0152] At step 2, Producer 810 may acknowledge the specific O-Cloud platform software update request.

[0153] At step 3, Producer 810 may request the IMS for the specific O-Cloud platform software update. The IMS may verify the request, and perform a specific update.

[0154] At step 4, Consumer 800 is notified about the outcome of the specific O-Cloud Platform Software update request by Producer 810.

[0155] FIG. 9 illustrates a callflow diagram of an example use-case for retrieving available O-Cloud platform software templates, according to one or more example embodiments. This may cover the scenario wherein a consumer needs the FOCOM SMOS to retrieve the details of the O-Cloud template schemas and their parameter values for the available templates, in order to update the O-Cloud software.

[0156] FOCOM SMOS acting as Consumer 900, and FOCOM SMOS acting as Producer 910 may be provided.

[0157] At step 1, Consumer 900 may request to retrieve available templates to update the O-Cloud software to Producer 910.

[0158] At step 2, the Producer 910 may either retrieve the template schemas and parameters from its cache, or interact with O2IMS.

[0159] At step 3, the Producer 910 may responds and share available templates to update O-Cloud software with the payload.

[0160] FIG. 10 illustrates a callflow diagram of an example use-case for retrieving current O-Cloud software running information, according to one or more example embodiments. This may cover the use-case wherein a consumer needs the FOCOM SMOS to query existing platformsoftware deployments in the O-Cloud so they can retrieve current O-Cloud software running information, and thereby understand characteristics of the O-Cloud.

[0161] FOCOM SMOS acting as Consumer 1000, and FOCOM SMOS acting as Producer 1010 may be provided.

[0162] At step 1, Consumer 1000 may request a query to retrieve the current O-Cloud software running information.

[0163] At step 2, the Producer 1010 may either retrieve the information from its cache, or interact with O2IMS for information.

[0164] At step 3, Producer 1010 responds to Consumer 1000 with the query with current O-Cloud software running information.

[0165] FIG. 11 illustrates a callflow diagram of an example use-case for updating IMS software, according to one or more example embodiments. This may cover the use-case wherein a consumer needs the FOCOM SMOS to update the IMS software so they can understand and enhance characteristics of the O-Cloud.

[0166] FOCOM SMOS acting as Consumer 1100, and FOCOM SMOS acting as Producer 1110 may be provided.

[0167] At step 1, Consumer 1100 may request to perform a specific IMS software update.

[0168] At step 2, Producer 1110 may acknowledge the specific IMS software update request.

[0169] At step 3, the Producer 1110 may request with IMS for the specific IMS software update. The IMS may verify the request and perform specific IMS update. The Producer 1110 may respond with the outcome of the specific IMS update request.

[0170] At step 4, the Consumer 1100 may be notified about the outcome of the specific IMS software update request.

[0171] FIG. 12 illustrates a callflow diagram of an example use-case for updating DMS software, according to one or more example embodiments. This may cover the use-case wherein a consumer needs the FOCOM SMOS to update the DMS software so they can understand and enhance capabilities and characteristics of the O-Cloud.

[0172] FOCOM SMOS acting as Consumer 1200, and FOCOM SMOS acting as Producer 1210 may be provided.

[0173] At step 1, Consumer 1200 may request to perform a specific DMS software update.

[0174] At step 2, Producer 1210 may acknowledge the specific DMS software update request.

[0175] At step 3, the Producer 1210 may request with IMS for the specific DMS software update. The IMS may verify the request and perform specific DMS update. The Producer 1210 may respond with the outcome of the specific DMS update request.

[0176] At step 4, the Consumer 1200 may be notified about the outcome of the specific DMS software update request.

[0177] FIG. 13 illustrates a block diagram of an example method 1300 for updating a software in the O-Cloud, according to one or more example embodiments.

[0178] At operation S1031, the FOCOM receives a request from a consumer to update at least one software. According to embodiments, the consumer may be any to any entity that can utilize the services provided by FOCOM. This consumer may be either internal or external. For example, an rApp can be an internal consumer of FOCOM services, while the SMO has the capability to integrate external consumers as well. For example, the consumer may be an NBISMO. The request may comprise a reference to at least one software management template provided by the FOCOM, which may include at least one of an O-Cloud identifier, a software name, a service attribute, a post status, a time to activation field, a service interrupt field, and a rollback version field. According to embodiments, the software may be an O-Cloud platform software, IMS software, or DMS software.

[0179] According to embodiments, the FOCOM may retrieve this template from its internal cache or request it from IMS. In cases where internal or external consumers already possess the required template from a previous request, it is FOCOM's responsibility to validate the template."

[0180] At operation S1302, the FOCOM forwards the request to the IMS. Upon receiving the request, the IMS may optionally perform a feasibility check for software updates associated with the at least one software, and verify resources associated with the request. Thereafter, the IMS may be configured to initiate a software download of the at least one software, based on the request (e g., based on the template). Either the IMS can trigger a software download from the Artifactory path provided in the software update request, or the FOCOM can supply the software package, depending on the situation.

[0181] At operation SI 303, the FOCOM receives a response from the IMS with the status update. This may specify as to whether the software was updated or not.

[0182] At operation SI 304, the FOCOM notifies the consumer with the status update from operation SI 303.

[0183] FIG. 14 illustrates a callflow diagram of an example use-case for performing a specific O-Cloud Platform Software Update, according to one or more example embodiments.

[0184] FOCOM SMOS acting as Consumer 1400, and FOCOM SMOS acting as Producer 1410 may be provided.

[0185] In this example use-case, the consumer needs the FOCOM SMOS to trigger an update of the O-Cloud Software so that they can use the capability and characteristics of the updated O-Cloud Software. Accordingly, the goal may be to enable the FOCOM SMOS consumer 1400 to trigger the O-Cloud Platform Software Updates for enhanced O-Cloud functionality. The IMS may be included as an entity. It may be assumed that the Producer 1410 supports the software update procedure. As a precondition, Consumer 1400 must be authorized to interact with Producer 1410. As a post-condi tion / acceptance criteria, the O-Cloud platform software is successfully updated, and an update notification is delivered to Consumer 1400.

[0186] At Step 1, Consumer 1400 may request to perform a specific O-Cloud Platform Software Update to Producer 1410.

[0187] At Step 2, producer 1410 may request with the IMS for a specific O-Cloud Platform Software Update. The IMS may verify the request and perform the specific O-Cloud Platform Software Update. The producer 1410 may respond with the outcome of the specific O-Cloud Platform Software Update request.

[0188] At Step 3, the consumer 1400 may be notified about the outcome of the specific O-Cloud Platform Software Update request from producer 1410.

[0189] FIG. 15 illustrates a callflow diagram of an example use-case for retrieving available templates to Update O-Cloud software, according to one or more example embodiments.

[0190] FOCOM SMOS acting as Consumer 1500, and FOCOM SMOS acting as Producer 1510 may be provided.

[0191] In this example use-case, consumer 1500 needs the FOCOM SMOS to retrieve the details of the O-Cloud templates schema and their parameter values for the available templates in order to update the O-Cloud software. Accordingly, the goal may be to enable Consumer 1510 to retrieve details of the O-Cloud template along with the parameter schema to trigger specific O-Cloud Software update. The IMS may be included as an entity. It may be assumed that the Producer 1510 supports the software update procedure. As a precondition, Consumer 1500 must be authorized to discover O-Cloud template information. As a post-condition / acceptance criteria, Producer 1510 may allow Consumer 1500 to discover O-Cloud templates and identify all parameters required for O-Cloud software updates.

[0192] At Step 1, Consumer 1500 may request to retrieve available templates to Update O-Cloud Software including the template ID from producer 1510.

[0193] At Step 2, producer 1510 may either retrieve the template schema and parameter information from its cache, or interact with O2IMS.

[0194] At Step 3, the consumer 1510 may receive the available templates based on Producer 1510 responding and sharing the available templates, for example via a payload.

[0195] It should be appreciated that the above use-case may be split into two sub-cases, one in which consumer 1500 needs to retrieve the O-Cloud templates schema in order to update O-Cloud Software, and a second where consumer 1500 needs to retrieve existing running template parameter values.

[0196] FIG. 16 illustrates a callflow diagram of an example use-case for retrieving current O-Cloud Software running information, according to one or more example embodiments.

[0197] FOCOM SMOS acting as Consumer 1600, and FOCOM SMOS acting as Producer 1610 may be provided.

[0198] In this example use-case, consumer 1600 needs the FOCOM SMOS to query existing platform software deployments in the O-Cloud so they can receive current O-Cloud software running information and understand characteristics of the o-Cloud software. Accordingly, the goal may be for consumer 1600 to query the FOCOM SMOS. The entities involved may also include the IMS. It may be assumed that producer 1610 supports query information procedure, and as a pre-condition consumer 1600 should be authorized to query producer 1610. As post-condition / acceptance criteria, producer 1610 may successfully process query requests form consumer 1600.

[0199] At Step 1, Consumer 1600 may request a query to retrieve current O-Cloud Software running information.

[0200] At Step 2, Producer 1610 may either retrieve the information from its cached or interact with O2IMS for the information.

[0201] At Step 3, consumer 1600 may respond to the query with the current O-Cloud Software running information..

[0202] It should be appreciated that it may also be possible for the O-Cloud Software information to be retrieved from the cluster template.

[0203] FIG. 17 illustrates a callflow diagram of an example use-case for performing a specific O-Cloud IMS software update, according to one or more example embodiments.

[0204] FOCOM SMOS acting as Consumer 1700, and FOCOM SMOS acting as Producer 1710 may be provided.

[0205] In this example use-case, consumer 1700 needs the FOCOM SMOS to trigger an update of the IMS Software so they can enhance the capability and characteristics of the O-Cloud. Accordingly, the goal may be to enable consumer 1700 to trigger IMS software updates forenhanced O-Cloud functionality. The entities involved may also include the IMS. It may be assumed that the FOCOM SMOS supports IMS software update procedure, and as a pre-condition, consumer 1700 must be authorized to interact with producer 1710. The post-condition / acceptance criteria may include the IMS software being successfully updated, and an update notification may be delivered to consumer 1700.

[0206] At Step 1, Consumer 1700 may request to perform a specific O-Cloud IMS software update.

[0207] At Step 2, Producer 1710 may request with IMS for a specific O-Cloud IMS Software update. IMS verifies the request and performs the specific O-Cloud IMS software update. Producer 1710 responds with the outcome of the specific O-Cloud IMS software update request.

[0208] At Step 3, Consumer 1700 may be notified about the outcome of the specific O-Cloud IMS Software Update request.

[0209] FIG. 18 illustrates a callflow diagram of an example use-case for performing a specific O-Cloud DMS software update, according to one or more example embodiments.

[0210] FOCOM SMOS acting as Consumer 1800, and FOCOM SMOS acting as Producer 1810 may be provided.

[0211] In this example use-case, consumer 1800 needs the FOCOM SMOS to trigger an update of the DMS Software so they can enhance the capability and characteristics of the O-Cloud. Accordingly, the goal may be to enable consumer 1800 to trigger DMS software updates for enhanced O-Cloud functionality. The entities involved may also include the IMS. It may be assumed that the FOCOM SMOS supports DMS software update procedure, and as a pre-condition, consumer 1800 must be authorized to interact with producer 1810. The post-condition / acceptancecriteria may include the DMS software being successfully updated, and an update notification may be delivered to consumer 1800.

[0212] At Step 1, Consumer 1800 may request to perform a specific O-Cloud DMS software update.

[0213] At Step 2, Producer 1810 may request with IMS for a specific O-Cloud DMS Software update. IMS verifies the request and performs the specific O-Cloud DMS software update. Producer 1810 responds with the outcome of the specific O-Cloud DMS software update request.

[0214] At Step 3, Consumer 1800 may be notified about the outcome of the specific O-Cloud DMS Software Update request.

[0215] FIG. 19 illustrates a callflow diagram of an example use-case for suspending a specific O-Cloud IMS Software update, according to one or more example embodiments.

[0216] FOCOM SMOS acting as Consumer 1900, and FOCOM SMOS acting as Producer 1910 may be provided.

[0217] In this example use-case, consumer 1900 needs the FOCOM SMOS to suspend a previously triggered O-Cloud platform software update so they can diverge from the update and continue using the existing capabilities of the O-Cloud Platform. Accordingly, the goal may be to enable consumer 1900 suspend previously triggered O-Cloud platform software update and continue using the existing capabilities of the O-Cloud Platform Software.. The entities involved may also include the IMS. It may be assumed that producer 1910 supports suspending a previously triggered O-Cloud Platform Software Update, and as a pre-condition, consumer 1900 must be authorized to interact with producer 1910. The post-condition / acceptance criteria may include theplatform software update request being successfully suspended and an update notification being delivered to consumer 1900.

[0218] At Step 1, Consumer 1900 may request to suspend a specific O-Cloud IMS software update.

[0219] At Step 2, Producer 1910 may request with IMS to suspend a specific O-Cloud IMS Software update. IMS verifies the request and suspends the specific O-Cloud IMS software update. Producer 1910 responds with the outcome of the specific O-Cloud IMS software update suspend request.

[0220] At Step 3, Consumer 1900 may be notified about the outcome of the specific O-Cloud IMS Software Update suspend request.

[0221] FIG. 20 illustrates a callflow diagram of an example use-case for performing a specific O-Cloud Platform Software Update, according to one or more example embodiments.

[0222] FOCOM SMOS acting as Consumer 2000, and FOCOM SMOS acting as Producer 2010 may be provided.

[0223] In this example use-case, the consumer needs the FOCOM SMOS to trigger an update of the O-Cloud Software so that they can use the capability and characteristics of the updated O-Cloud Software. Accordingly, the goal may be to enable the FOCOM SMOS consumer 2000 to trigger the O-Cloud Platform Software Updates for enhanced O-Cloud functionality. The IMS may be included as an entity. It may be assumed that the Producer 2010 supports the software update procedure. As a precondition, Consumer 2000 must be authorized to interact with Producer 2010. As a post-condi tion / acceptance criteria, the O-Cloud platform software is successfully updated, and an update notification is delivered to Consumer 2000.

[0224] At Step 1, Consumer 2000 may request to perform a specific O-Cloud Platform Software Update to Producer 2010.

[0225] At Step 2, producer 2010 may request with the IMS for a specific O-Cloud Platform Software Update. The IMS may verify the request and perform the specific O-Cloud Platform Software Update. The producer 2010 may respond with the outcome of the specific O-Cloud Platform Software Update request.

[0226] At Step 3, the consumer 2000 may be notified about the outcome of the specific O-Cloud Platform Software Update request from producer 2010.

[0227] FIG. 21 illustrates a callflow diagram of an example use-case for cancelling a specific O-Cloud software update, according to one or more example embodiments.

[0228] FOCOM SMOS acting as Consumer 2100, and FOCOM SMOS acting as Producer 2110 may be provided.

[0229] In this example use-case, consumer 2100 needs the FOCOM SMOS to cancel a previously triggered O-Cloud platform software update so they can diverge from the update and continue using the existing capabilities of the O-Cloud Platform. Accordingly, the goal may be to enable consumer 2100 cancel previously triggered O-Cloud platform software update and continue using the existing capabilities of the O-Cloud Platform Software.. The entities involved may also include the IMS. It may be assumed that producer 2110 supports canceling a previously triggered O-Cloud Platform Software Update, and as a pre-condition, consumer 2100 must be authorized to interact with producer 2110. The post-condition / acceptance criteria may include the platform software update request being successfully canceled and an update notification being delivered to consumer 2100.

[0230] At Step 1, Consumer 2100 may request to cancel a specific O-Cloud software update.

[0231] At Step 2, Producer 2110 may request with IMS to cancel a specific O-Cloud Software update. IMS verifies the request and cancels the specific O-Cloud software update. Producer 2110 responds with the outcome of the specific O-Cloud software update cancel request.

[0232] At Step 3, Consumer 2100 may be notified about the outcome of the specific O-Cloud Software Update cancel request.

[0233] It should be appreciated that a software update suspension request may require a valid previous software update request. The FOCOM SMOS consumer may trigger a suspension request based on the identity of the previous request and may request to suspend software updates for the O-Cloud platform software, IMS software, and DMS software.

[0234] As a first example, cancellation of a schedule software update request may be performed. When a scheduled platform software update request is cancelled, the O-Cloud processes the cancellation request and notifies the user accordingly. The software update cancellation request may include information about the previously running software version. Upon receiving this cancellation request, the O-Cloud verifies the currently running software version and responds back to the FOCOM via the 02-IMS interface, confirming the cancellation.

[0235] As a second example, cancellation during the update operation (Roll-Back Scenario) may be performed. Software Update Cancel request may contain previous running software version information and based on the request, the O-Cloud may cancel current update execution and rollback to the previous software version, which can be shared by O-Cloud or they may fetch this information from a “cancel” request.

[0236] As a third example, cancellation post upgrade software Update operation (Verification of Cancelation Request) may be performed. This is objectively a negative scenario, where the user has sent the cancellation of software update request, which was already executed (response shared by the O-Cloud) resulting in a situation wherein upon reception of this request, the O-Cloud may just verify the current Running software version and responds back as “invalid cancellation request”. (The reason it is invalid may be the O-Cloud already responded back to the original request).

[0237] Based on the above example embodiments, a declarative approach is provided for updating software, which introduces the implementation of the NBI to enable the initiation of the Software Update procedure, thereby streamlining and standardizing the process.

[0238] FIG. 22 illustrates a block diagram of an example device 2200 for implementing one or more example embodiments. As shown in FIG. 22, the device 2200 includes processor 2210, a memory 2220, a storage component 2230, an input component 2240, an output component 2250, a communication interface 2260, and a bus 2270.

[0239] The processor 2210, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 2210 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and / or one or more single core processors, a distributed processing system, or the like. The processor 2210 may be a Central Processing Unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application-specific integrated circuit (ASIC), or another type of processing component.

[0240] Memory 2220 includes a non-transitory computer readable medium. Memory 2220 includes a random-access memory (RAM), a read only memory (ROM), and / or another type ofdynamic or static storage device (e.g., a flash memory, a magnetic memory, and / or an optical memory) that stores information and / or instructions for use by processor 2210. The memory 2220 comprises machine-readable instructions which are executable by the processor 2210. These machine-readable instructions when executed by the processor 2210 cause the processor 2210 to perform one or more method steps of an embodiment described above.

[0241] Storage component 2230 stores information and / or software related to the operation and use of the device 2200. For example, storage component 2230 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive.

[0242] Input component 2240 is configured to receive information, such as user input. For example, the input component 2240 may include, but not be limited to, a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone. Additionally, or alternatively, the input component 2240 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0243] Output component 2250 is configured to provide output information from the device 2200. For example, the output component 2250 may be, but not limited to, a display, a speaker, an instruction device to an external device, and / or one or more light-emitting diodes (LEDs).

[0244] Communication interface 2260 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 2260 can be a wired connection, a wireless connection, or a combination of wired and wireless connections, and can be a direct connection or an indirect connection via acommunication network that exists between the device 2200 and other devices. In other words, the standard of the communication interface 2260 is not limited.

[0245] The bus 2270 acts as an interconnect between the processor 2210, the memory 2220, the storage component 2230, the input component 2240, the output component 2250, and the communication interface 2260 of the device 2200. The bus 2270 may include a wired interconnection or a wireless interconnection.

[0246] The number and arrangement of components shown in FIG. 22 are provided as an example. In practice, device 2200 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 22. Additionally, or alternatively, a set of components (e.g., one or more components) of device 2200 may perform one or more functions described as being performed by another set of components of device 2200. Further, one or more method steps described in any of the embodiments may be performed utilizing a plurality of devices 2200 in communication with one another.

[0247] Example embodiments of the present disclosure may be implemented in any suitable type of environment. In the following, an example environment (in which the example embodiments may be implemented) is described.

[0248] FIG. 23 illustrates a block diagram of an example environment 2300 for implementing in which systems and / or method, described herein, may be implemented. The implementation environment 2300 includes a UE (User equipment) 2310, a service environment 2320, and a network 2330. The service environment 2320 include one or more sub-environments 2321. To illustrate this, FIG. 23 shows, for convenience, examples of a 1st sub-environment 2321-1, a 2nd sub-environment 2321-2, and an N-th sub-environment 2321-N (where N is any natural number).

[0249] The UE 2310 is connected to the network 2330, and the network 2330 is connected to the service environment 2320. The connections may be wired, wireless, or a combination of both wired and wireless. The UE 2310 and the service environment 2320 are connected via the network 2330.

[0250] The UE 2310 is a device that communicates with the service environment 2320. The UE 2310 receives information from the service environment 2320 and / or sends information to the service environment 2320. Also, the UE 2310 may generate and / or store information to be transmitted, as necessary. Also, the UE 2310 may store and / or process information that is received, as necessary.

[0251] The example figure 23 refers to the “UE”. However, it should be understood by those skilled in the art that general terms such as “user device,” “terminal,” “terminal device,” “communication device,” and “communication terminal” can be used interchangeably with the term “UE.”

[0252] For example, the UE 2310 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a wearable device (e.g., a pair of smart glasses or a smart watch), or a similar device.

[0253] The service environment 2320 is an environment that communicates with the UE 2310 to provide one or more services. The service environment 2320 receives information from the UE 2310 and / or sends information to the UE 2310. Also, the service environment 2320 may generate and / or store information to be transmitted, as necessary. Also, the service environment 2320 may store and / or process information that is received, as necessary. For example, the service environment 2320 may provide computing resources as one of the services. It should be noted thatthe service is not limited to being provided to the UE; it may also be provided to devices other than the UE. For example, based on communication from the UE, the service may perform processes such as anomaly detection or traffic analysis and notify the results to a predetermined destination.

[0254] The example figure 23 refers to the “service environment”. The term "service environment" is used to refer to the broader context within which services operate. For example, cloud environments, platforms, computing systems, network systems, and cloud systems generally represent the environments in which services are conducted, and these are included within the "service environment." However, the "service environment" is not limited to these examples. Additionally, the specific types of environments within the "service environment" are not restricted. For instance, cloud environments and cloud systems can be categorized as private cloud, public cloud, hybrid cloud, or multi-cloud, all of which are included within the "service environment."

[0255] The one or more services provided by the service environment 2320 is not specifically limited and can be adjusted according to the embodiments. For example, the services may include a service that provides information to the UE 2310, a service that stores information from the UE 2310, or a service that performs processing based on information from the UE 2310 and returns the results of the processing.

[0256] In an embodiment, the Service Environments 2320 may also provide computing resources as the service. The computing resources can be hardware resources and / or software resources. For example, applications, processors, memory, and storage can be included in the provided computing resources. Each computing resource can communicate with other computing resources via wired connections, wireless connections, or a combination of wired and wireless connections.

[0257] The provided computing resources can be actual resources (also referred to as physical resources) and / or virtual resources. Furthermore, means of virtualization for virtual resources can be selected as appropriate. That is, in this disclosure, the use of adjectives such as "Virtual" or "Virtualized" to describe names does not imply that they are virtualized by a specific means of virtualization. For example, “virtual machine” refers to software that operates like an actual computer, realized through means of virtualization, and it is not intended to exclude those realized by specific means of virtualization such as Hypervisors or Containers. Conversely, when means of virtualization such as Hypervisors or containers are mentioned in this disclosure, it is merely cited as a general method of implementation. It should also be interpreted that embodiments implemented with other virtualization means are also disclosed. Also, the services may also be provided using resources virtualized by different means.

[0258] The service environment 2320 includes one or more devices, such as servers and network devices, which provide services or perform processes. The placement of these devices within the service environment 2320 can be determined as appropriate. Additionally, if the service environment 2320 includes one or more sub-environments 2321, the placement of devices can be determined based on predetermined policies for each sub-environment 2321. For example, devices related to the first service may be placed in the 1st sub-environment 2321-1, and devices related to the second service may be placed in the 2nd sub-environment 2321-2. In another example, devices expected to have a higher load than a predetermined threshold may be placed in the 1st sub-environment 2321-1, while devices expected to have a lower load than the predetermined threshold may be placed in the 2nd sub-environment 2321-2. In this way, specific devices can be placed in specific sub-environments 2321. Conversely, each sub-environment 2321 can be specialized for a particular purpose.

[0259] In an embodiment, all processes executed in a single service may run within a single service environment, or in multiple service environments. Multiple processes executed in a single service could be provided by different service environments.

[0260] The network 2330 is a network that exchanges information between the UE 2310 and the service environment 2320. The network 2330 includes one or more wired and / or wireless networks.

[0261] For example, the network 2330 may include a cellular network (e.g., a fifth generation (5G) network, a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, or the like, a non-terrestrial network (NTN), and / or a combination of these or other types of networks.

[0262] The network 2330 can be a part of a network. For example, in a 5G network that includes a RAN, a transport network, and a core network, the network 2330 can be at least one of the RAN, the transport network, or the core network. For example, the service environment 2320 could be in the core network, in which case the network 2330 could correspond to a network that is a combination of a RAN and a transport network and is part of the 5G network.

[0263] The number and arrangement of devices and networks shown in FIG. 23 are provided as an example. It should be understood that any changes that may be implemented by those skilled in the art, such as the addition or rearrangement of well-known devices or networks at the time of implementation, are included in this disclosure.Various Aspects of Embodiments

[0264] It is contemplated that the example embodiments described hereinabove with reference to FIG. 1 to FIG. 23 are merely examples of possible embodiments of the present disclosure, and are not intended to limit or restrict the scope of the present disclosure.

[0265] Specifically, the foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

[0266] Some embodiments may relate to a device (e.g., node, etc.), a system, a method, and / or a computer-readable medium at any possible technical detail level of integration. Further, one or more of the above components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium (or media) having computer-readable program instructions thereon for causing a processor to carry out operations.

[0267] The computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, 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 of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), electrically erasable programmable read-only memory (EEPROM), a static random access memory (SRAM), a portable compact discread-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer-readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0268] Computer-readable program instructions described herein can be downloaded to respective computing / processing devices from a computer-readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, 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 forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0269] Computer-readable program code / instructions for carrying out operations may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object-oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages.

[0270] The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the 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 a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

[0271] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0272] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operationalsteps to be performed on the computer, other programmable apparatus or other devices to produce a computer-implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0273] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). The method, computer system, and computer-readable medium may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the Figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0274] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limited to the implementations. Thus, the operation and behavior of the systemsand / or methods were 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.

[0275] In view of the above, various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:Item [I]: A method including receiving, by Federated Open Cloud Orchestration & Management (FOCOM), a request from a consumer to update at least one software associated with an Open RAN Cloud (O-Cloud) Platform, wherein the request comprises a reference to at least one O-Cloud Software Management template provided by the FOCOM;; forwarding, by the FOCOM, the request to Infrastructure Management Service (IMS); and receiving, by the FOCOM, a response from IMS as to whether the at least one software was updated or not.Item [2]: The method according to Item [1], wherein upon receiving the request, either the IMS is configured to initiate a software download of the at least one software from a file path based on the request, or the FOCOM is configured to supply the at least one software based on the request..Item [3] : The method according to Item [2], wherein upon receiving the request, the IMS is further configured to perform a feasibility check for software updates associated with the at least one software, verify resources associated with the request.Item [4]: The method according to Item [3], wherein upon receiving the request, the IMS is further configured to update a software inventory associated with the at least one software.Item [5]: The method according to any one of Items [l]-[4], wherein the at least one software comprises one of an O-Cloud Platform software, IMS software, or Deployment Management Service (DMS) software.Item [6]: The method according to any one of Items [l]-[5], further including notifying, by the FOCOM, the external consumer as to whether the at least one software was updated or not.Item [7]: The method according to any one of Items [l]-[6], wherein the O-Cloud Software Management template includes at least one of an O-Cloud identifier, a software name, a service attribute, a post status, a time to activation field, a service interrupt field, and a rollback version field.Item [8]:. A Federated Open Cloud Orchestration & Management (FOCOM) configured to: receive a request from a consumer to update at least one software associated with an Open RAN Cloud (O-Cloud) Platform, wherein the request includes a reference to at least one O-Cloud Software Management template provided by the FOCOM; forward the request to Infrastructure Management Service (IMS); and receive a response from IMS as to whether the at least one software was updated or not.Item [9]: The FOCOM according to Item [8], wherein upon receiving the request, either the IMS is configured to initiate a software download of the at least one software from a file path based on the request, or the FOCOM is configured to supply the at least one software based on the request.Item

[0010] : The FOCOM according to Item [9], wherein upon receiving the request, the IMS is further configured to perform a feasibility check for software updates associated with the at least one software, verify resources associated with the request.Item

[0011] : The FOCOM according to Item

[0010] , wherein upon receiving the request, the IMS is further configured to update a software inventory associated with the at least one software.Item

[0012] : The FOCOM according to any one of Items [8]-[l 1], wherein the at least one software includes one of an O-Cloud Platform software, IMS software, or Deployment Management Service (DMS) software.Item

[0013] : The FOCOM according to any one of Items [8]-

[0012] , further configured to notify the consumer as to whether the at least one software was updated or not.Item

[0014] : The FOCOM according to any one of Items [8]-

[0013] , wherein the O-Cloud Software Management template includes at least one of an O-Cloud identifier, a software name, a service attribute, a post status, a time to activation field, a service interrupt field, and a rollback version field.Item

[0015] : A non-transitory computer-readable recording medium having recorded thereon instructions executable to perform a method including: receiving, by Federated Open Cloud Orchestration & Management (FOCOM), a request from a consumer to update at least onesoftware associated with an Open RAN Cloud (O-Cloud) Platform, wherein the request includes a reference to at least one O-Cloud Software Management template provided by the FOCOM; forwarding, by the FOCOM, the request to Infrastructure Management Service (IMS); and receiving, by the FOCOM, a response from IMS as to whether the at least one software was updated or not.Item

[0016] : The non-transitory computer-readable recording medium according to Item

[0015] , wherein upon receiving the request, either the IMS is configured to initiate a software download of the at least one software from a file path based on the request, or the FOCOM is configured to supply the at least one software based on the request.Item

[0017] : The non-transitory computer-readable recording medium according to Item

[0016] , wherein upon receiving the request, the IMS is further configured to perform a feasibility check for software updates associated with the at least one software, verify resources associated with the request.Item

[0018] : The non-transitory computer-readable recording medium according to Item

[0017] , wherein upon receiving the request, the IMS is further configured to update a software inventory associated with the at least one software.Item

[0019] : The non-transitory computer-readable recording medium according to any one of Items

[0015] -

[0018] , wherein the at least one software includes one of an O-Cloud Platform software, IMS software, or Deployment Management Service (DMS) software.Item

[0020] : The non-transitory computer-readable recording medium according to any one of Items

[0015] -

[0019] , the method further including: notifying, by the FOCOM, the consumer as to whether the at least one software was updated or not.It will be apparent that within the scope of the appended clauses, the present disclosures may be practiced otherwise than as specifically described herein.

Claims

What is claimed is:

1. A method comprising:receiving, by Federated Open Cloud Orchestration & Management (FOCOM), a request from a consumer to update at least one software associated with an Open RAN Cloud (O-Cloud) Platform, wherein the request comprises a reference to at least one O-Cloud Software Management template provided by the FOCOM;forwarding, by the FOCOM, the request to Infrastructure Management Service (IMS); and receiving, by the FOCOM, a response from IMS as to whether the at least one software was updated or not.

2. The method as claimed in claim 1, wherein upon receiving the request, either the IMS is configured to initiate a software download of the at least one software from a file path based on the request, or the FOCOM is configured to supply the at least one software based on the request.

3. The method as claimed in claim 2, wherein upon receiving the request, the IMS is further configured to perform a feasibility check for software updates associated with the at least one software, verify resources associated with the request.

4. The method as claimed in claim 3, wherein upon receiving the request, the IMS is further configured to update a software inventory associated with the at least one software.

5. The method as claimed in claim 1, wherein the at least one software comprises one of an O-Cloud Platform software, IMS software, or Deployment Management Service (DMS) software.

6. The method as claimed in claim 1, further comprising:notifying, by the FOCOM, the consumer as to whether the at least one software was updated or not.

7. The method as claimed in claim 1, wherein the O-Cloud Software Management template comprises at least one of an O-Cloud identifier, a software name, a service attribute, a post status, a time to activation field, a service interrupt field, and a rollback version field.

8. A Federated Open Cloud Orchestration & Management (FOCOM) configured to:receive a request from a consumer to update at least one software associated with an Open RAN Cloud (O-Cloud) Platform, wherein the request comprises a reference to at least one O-Cloud Software Management template provided by the FOCOM;forward the request to Infrastructure Management Service (IMS); andreceive a response from IMS as to whether the at least one software was updated or not.

9. The FOCOM as claimed in claim 8, wherein upon receiving the request, either the IMS is configured to initiate a software download of the at least one software from a file path based on the request, or the FOCOM is configured to supply the at least one software based on the request.

10. The FOCOM as claimed in claim 9 wherein upon receiving the request, the IMS is further configured to perform a feasibility check for software updates associated with the at least one software, verify resources associated with the request.

11. The FOCOM as claimed in claim 10, wherein upon receiving the request, the IMS is further configured to update a software inventory associated with the at least one software.

12. The FOCOM as claimed in claim 8, wherein the at least one software comprises one of an O-Cloud Platform software, IMS software, or Deployment Management Service (DMS) software.

13. The FOCOM as claimed in claim 8, further configured to notify the consumer as to whether the at least one software was updated or not.

14. The FOCOM as claimed in claim 8, wherein the O-Cloud Software Management template comprises at least one of an O-Cloud identifier, a software name, a service attribute, a post status, a time to activation field, a service interrupt field, and a rollback version field.

15. A non-transitory computer-readable recording medium having recorded thereon instructions executable to perform a method comprising:receiving, by Federated Open Cloud Orchestration & Management (FOCOM), a request from a consumer to update at least one software associated with an Open RAN Cloud (O-Cloud) Platform, wherein the request comprises a reference to at least one O-Cloud Software Management template provided by the FOCOM;forwarding, by the FOCOM, the request to Infrastructure Management Service (IMS); and receiving, by the FOCOM, a response from IMS as to whether the at least one software was updated or not.

16. The non-transitory computer-readable recording medium as claimed in claim 15, wherein upon receiving the request, either the IMS is configured to initiate a software download of the at least one software from a file path based on the request, or the FOCOM is configured to supply the at least one software based on the request.

17. The non-transitory computer-readable recording medium as claimed in claim 16, wherein upon receiving the request, the IMS is further configured to perform a feasibility check for software updates associated with the at least one software, verify resources associated with the request.

18. The non-transitory computer-readable recording medium as claimed in claim 17, wherein upon receiving the request, the IMS is further configured to update a software inventory associated with the at least one software.

19. The non-transitory computer-readable recording medium as claimed in claim 15, wherein the at least one software comprises one of an O-Cloud Platform software, IMS software, or Deployment Management Service (DMS) software.

20. The non-transitory computer-readable recording medium as claimed in claim 15, the method further comprising:notifying, by the FOCOM, the consumer as to whether the at least one software was updated or not.

Images