TECHNICAL FIELD

The present disclosure relates to wireless communications, and in particular, to management of wireless radio software.

BACKGROUND

The Third Generation Partnership Project (3 GPP) has developed and is developing standards for Fourth Generation (4G) (also referred to as Long Term Evolution (LTE)) and Fifth Generation (5G) (also referred to as New Radio (NR)), and Sixth Generation (6G) wireless communication systems. Such systems provide, among other features, broadband communication between network nodes, such as base stations, and mobile wireless devices (WD), as well as communication between network nodes and between WDs. In addition, 3GPP has developed standards for Radio Access Network RAN applications which run in running in access networks, e.g., cloud networks, and Kubemetes clusters.

Kubemetes (k8s) is a system for running containers in an automated, declarative, repeatable, and understandable way. Kubemetes also provides a framework for deploying application code into production. As used herein, a “container” generally refers to a runtime environment, such as an application, plus all its dependencies, operating system libraries, other dependencies such as binaries and configuration files needed to run the application, all combined into one package. k8s cluster: A cluster in k8s consists of one or more master machines and multiple worker machines or nodes. The master runs the control plane functions, e.g., k8s Application Programming Interface (API), and coordinates between all the nodes running the actual workloads knowns as pods. k8s pod: A pod in k8s is the smallest unit of deployment in a cluster, i.e., a pod may be an instance of an application. A pod could run on a single container or multiple containers. Each pod has a unique Internet Protocol (IP) address assigned. If a pod is running on multiple containers, then the containers can communicate with each other using localhost. When containers must communicate outside the pod, a User Datagram Protocol (UDP) or a Transmission Control Protocol (TCP) port is exposed. A pod is usually deployed with a controller. Examples of controllers supported in k8s include a Deployment, a StatefulSet, DaemonSet and a Job. k8s Job: Most cloud Radio Access Network (RAN) applications are long- running workloads, Deployments, that eventually need to be software upgraded and are present in a k8s clusters for as long as the services are needed. Jobs in k8s are designed for short-lived workloads, e.g., one-off tasks in a k8s cluster. Jobs are useful for tasks/processes that are to be performed once. A Job in k8s creates a pod that runs until successful termination, e.g., exit with 0, but is not automatically deleted by default, unless configured to do so. Keeping jobs allows users to view logs of completed pods to check for errors, warnings, and/or other diagnostic output. k8s node: A node is a worker machine. For example, a node may be a Virtual Machine (VM) or a physical machine which contains services to run pods. A work machine is controlled by a master which coordinates between nodes. Each node has knowledge of its Central Processing Unit (CPU), Graphical Processing Unit (GPU), memory, ephemeral storage, and maximum number of pods which can be scheduled on the node.

Cluster user: a cluster user in k8s is a user from a group of users responsible for creating and managing specific application instances, e.g., tenant pods or workloads, running in a multi-cluster network.

Cluster admin: a group of users responsible for creating and managing k8s clusters and related physical components and operating system.

Orchestrator: The management system responsible for communicating with the k8s clusters, e.g., via a k8s API interface, and managing the lifecycle of k8s resources including the workloads deployed as k8s Deployments, k8s StatefulSets, k8s DaemonSets and k8s Jobs.

Typical software upgrade processes (e.g., employing k8s technology) involve multiple manual steps such as manual input of the target radio software version and/or manual trigger (i.e., deployment) of the radio software upgrade. However, at least the manual aspect of typical upgrade processes may lead to incorrect radio software versions being used and delays in the software upgrade of RUs. SUMMARY

Some embodiments advantageously provide methods, systems, and apparatuses for automatic radio software management.

In one or more embodiments, software applications running in clouds networks such as k8s clusters may be designed to work as a pair for managing radio software on physical radio units. The pair may include:

• A Radio Software Upgrade Job Controller (RSUJC); and

• A Radio Software Upgrade Job Engine (RSUJE).

The RSUJC may be deployed on-demand (i.e., manually) by an operator. The operator typically passes configurable parameters to trigger a radio software upgrade job. The parameters usually include matching criteria for selecting the radio units (RUs), target software version and job action (or list of changes) to perform on the radio units. The parameters may be passed using helm values (e.g., values of a Helm chart) during the instantiation and/or update of the RSUJC. The target radio software version may be determined by reading release notes provided by vendors indicating tested virtual distributed unit (vDU) and/or open radio access network distributed unit (O-DU) and/or radio software combination. The target radio software version may further be determined by configuring a uniform resource identifier (URI) specifying where to fetch the wanted radio software version from an FTP server (after been onboarded into the operator network).

In some embodiments, automatic upgrades of RUs, e.g., RUs that are attached to (i.e., communicating with) a virtual DU, is provided. In some other embodiments recommended, or tested RU software is automatically selected. Automatically selecting/upgrading software allows RUs to run with the latest radio traffic, control features, and fixes at least one of the vDU/O-DU and RUs.

In some embodiments, at least one of the following may be performed:

• Automatic trigger of radio software upgrade when performing a vDU/O-DU software upgrade; and

• Automatic selection of recommended/tested radio software product and version when performing a vDU/O-DU software upgrade.

In some other embodiments, the vDU/O-DU and RU software packages may be delivered and/or on-boarded separately in an operator network. In one embodiment, the RSUJC may be packaged and/or deployed together with the vDU/O-DU services. In another embodiment, during a vDU/O-DU helm upgrade, the vDU/O-DU services may be upgraded first and then the radio software upgrade job will be automatically created when the RSUJC is instantiated together with the vDU/O-DU instance.

In some embodiments, automatic RU software version selection is performed by reading and/or selecting at least an RU software product and version that is included in the updated vDU/O-DU software inventory (which may include metadata). Such metadata is provided in vDU/O-DU helm values. yaml file and/or automatically stored in a vDU/O-RU Configuration Management service. This query action may be performed by the RSUJC before triggering the radio software upgrade job.

In some other embodiments, if multiple RU software products are listed in the updated vDU/O-DU software inventory (e.g., multiple radio software products and versions have been tested with the new vDU/O-DU software version), the RSUJC queries an RSUJE to discover identities of the attached RUs and/or RUs current running radio software product number and version.

In one embodiment, a software product and version (e.g., a radio software product and version) is selected (e.g., by the RSUJC). The RSUJC may trigger one or more radio upgrade jobs, e.g., one for each new radio software product number targeting a specific set of radio units that are attached to (i.e., associated with) the vDU/O-DU.

By combining the RSUJC with the vDU/O-DU instance and/or selecting the automatic software (e.g., RU software) selection option, operators do not need to perform any additional actions and/or select the recommended and tested RU software version when upgrading the vDU/O-DU and RU software upgrade together, e.g., during a maintenance window. For example, an entire RU software upgrade may be performed automatically with the vDU/O-DU SW upgrade. Accordingly, a system with the latest radio traffic, control features, fixes may be running on the vDU/O-DU and RUs.

If an operator desires to control the sequence of the vDU/O-DU and RU software upgrade and/or take a pause in between them to check status or progress, the operator may deploy/instantiate the RSUJC separately while still selecting the automatic RU software selection option.

In some embodiments, a determination of which radio software version to load on RUs is performed automatically, e.g., based on the upgraded vDU software version. In some other embodiments, there are one or more relationships between the vDU software version (e.g., running in the cloud) and the RUs (e.g., attached on the antenna poles). In some embodiments, operators may want to ensure RUs are upgraded “together” and are running the correct versions (e.g., without requiring operator knowledge of software version and RU relationships. For example, when a vDU is upgraded to vDU software version Y, then RUs may also be automatically upgraded to a recommended RU software version that is optimized to work with upgraded vDU version Y. The upgraded vDU instance may be configured to create a ConfigMap (i.e., configuration map) that comprises the recommended RU software version. The RSUJC can be configured to mount the ConfigMap such as when it “installed/upgraded” together with the vDU. After reading the ConfigMap, then the RSUJC can signal the RSUJE to execute the RU software upgrade to the recommended RU software version that is optimized to work with upgraded vDU version Y.

According to one aspect, a first network node configured to communicate with a second network node is described. The first network node comprises processing circuitry configured to determine a configuration map mountable as a data volume of the first network node, where the configuration map stores a list of software file names associated with a software upgrade of at least a third network node; determine a software upgrade request usable to trigger the second network node to perform the software upgrade of at least the third network node, where the software upgrade request comprises the list of software file names stored in the configuration map; and cause transmission of the software upgrade request to the second network node.

In some embodiments, the list of software file names is specified in a human- readable data serialization language file.

In some other embodiments, the determination of the configuration map comprises mounting the configuration map as the data volume of the first network node. In some embodiments, the configuration map is mounted by a pod created by a job associated with the first network node.

In some other embodiments, the job starts the pod, where the pod is configured as a client for an application programming interface (API).

In some embodiments, the client is usable for communication between the first network node and the second network node, and the software upgrade request is transmitted by the client.

In some other embodiments, one or both of the configuration map is provided by a fourth network node and the fourth network node comprises a virtual distributed unit (vDU).

In some embodiments, the method further comprises storing the configuration map in a data volume.

In some other embodiments, the software upgrade of at least the third network node is to be performed automatically by the second network node.

In some embodiments, the first network node comprises a Radio Software Upgrade Job Controller (RSUJC), the second network node comprises a Radio Software Upgrade Job Engine (RSUJE), and the third network node comprises a radio unit configurable to be upgraded with the software upgrade.

According to another aspect, a method in a first network node configured to communicate with a second network node is described. The method comprises determining a configuration map mountable as a data volume of the first network node, where the configuration map storing a list of software file names associated with a software upgrade of at least a third network node; determining a software upgrade request usable to trigger the second network node to perform the software upgrade of at least the third network node, where the software upgrade request comprises the list of software file names stored in the configuration map; and transmitting the software upgrade request to the second network node.

In some embodiments, the list of software file names is specified in a human- readable data serialization language file.

In some other embodiments, the determination of the configuration map comprises mounting the configuration map as the data volume of the first network node. In some embodiments, the configuration map is mounted by a pod created by a job associated with the first network node.

In some other embodiments, the job starts the pod, where the pod is configured as a client for an application programming interface (API).

In some embodiments, the client is usable for communication between the first network node and the second network node, and the software upgrade request is transmitted by the client.

In some other embodiments, one or both of the configuration map is provided by a fourth network node and the fourth network node comprises a virtual distributed unit (vDU).

In some embodiments, the method further comprises storing the configuration map in a data volume.

In some other embodiments, the software upgrade of at least the third network node is to be performed automatically by the second network node.

In some embodiments, the first network node comprises a Radio Software Upgrade Job Controller (RSUJC), the second network node comprises a Radio Software Upgrade Job Engine (RSUJE), and the third network node comprises a radio unit configurable to be upgraded with the software upgrade.

According to one aspect, a second network node configured to communicate with a first network node and a third network node is described. The second network node comprises processing circuitry configured to receive a software upgrade request from the first network node, where the software upgrade request is usable to trigger the second network node to perform a software upgrade of at least the third network node, the software upgrade request comprises a list of software file names stored in a configuration map, the configuration map is mountable as a data volume of the first network node, and the configuration map stores the list of software file names associated with the software upgrade of at least the third network node; and perform the software upgrade of at least the third network node based on the software upgrade request.

In some embodiments, the list of software file names is specified in a human- readable data serialization language file.

In some other embodiments, the processing circuitry is further configured to cause transmission of a fetch request to a fifth network node. The fetch request comprises the list of software file names comprised in the software upgrade request, and the fifth network node comprises a file server.

In some embodiments, the processing circuitry is further configured to receive one or more software files associated with one or more software file names comprised in the fetch request, where the one or more software files is used to perform the software upgrade of at least the third network node; and storing the one or more software files in a local volume. The local volume is a persistent volume connected to a pod associated with the second network node.

In some other embodiments, the processing circuitry is further configured to one or more of determine the third network node is not running a software version corresponding to the one or more software files; select the one or more software files, the one or more software files being is compatible with the third network node; and cause the third network node to load the one or more software files; and cause the third network node to restart and activate the one or more software files.

In some embodiments, the processing circuitry is further configured to update a software inventory indicating the software version has been loaded and activated on the third network node.

In some other embodiments, the performing of the software upgrade causes the third network node to disconnect from a virtual distributed unit (vDU) and reconnect to the vDU.

In some embodiments, the processing circuitry is further configured to stop the software upgrade when the third network node is disconnected from the vDU and resume the software upgrade when the third network node is reconnected to the vDU.

In some other embodiments, the processing circuitry is further configured to automatically perform the software upgrade of at least the third network node.

In some embodiments, the first network node comprises a Radio Software Upgrade Job Controller (RSUJC), the second network node comprises a Radio Software Upgrade Job Engine (RSUJE), and the third network node comprises a radio unit configurable to be upgraded with the software upgrade.

According to another aspect, a method in a second network node configured to communicate with a first network node and a third network node is described. The method comprises receiving a software upgrade request from the first network node, where the software upgrade request is usable to trigger the second network node to perform a software upgrade of at least the third network node, the software upgrade request comprises a list of software file names stored in a configuration map, the configuration map is mountable as a data volume of the first network node, and the configuration map storing the list of software file names associated with the software upgrade of at least the third network node; and performing the software upgrade of at least the third network node based on the software upgrade request.

In some embodiments, the list of software file names is specified in a human- readable data serialization language file.

In some other embodiments, the method further comprises transmitting a fetch request to a fifth network node. The fetch request comprises the list of software file names comprised in the software upgrade request, and the fifth network node comprises a file server.

In some embodiments, the method further comprises receiving one or more software files associated with one or more software file names comprised in the fetch request, where the one or more software files is used to perform the software upgrade of at least the third network node; and storing the one or more software files in a local volume. The local volume is a persistent volume connected to a pod associated with the second network node.

In some other embodiments, the method further comprises one or more of determining the third network node is not running a software version corresponding to the one or more software files; selecting the one or more software files, the one or more software files being is compatible with the third network node; and causing the third network node to load the one or more software files; and causing the third network node to restart and activate the one or more software files.

In some embodiments, the method further comprises updating a software inventory indicating the software version has been loaded and activated on the third network node.

In some other embodiments, the performing of the software upgrade causes the third network node to disconnect from a virtual distributed unit (vDU) and reconnect to the vDU.

In some embodiments, the method further comprises stopping the software upgrade when the third network node is disconnected from the vDU and resuming the software upgrade when the third network node is reconnected to the vDU. In some other embodiments, the method further comprises automatically performing the software upgrade of at least the third network node.

In some embodiments, the first network node comprises a Radio Software Upgrade Job Controller (RSUJC), the second network node comprises a Radio Software Upgrade Job Engine (RSUJE), and the third network node comprises a radio unit configurable to be upgraded with the software upgrade.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present embodiments, and the attendant advantages and features thereof, will be more readily understood by reference to the following detailed description when considered in conjunction with the accompanying drawings wherein:

FIG. 1 is a schematic diagram of an example network architecture illustrating a communication system connected via an intermediate network to a host computer according to the principles in the present disclosure;

FIG. 2 is a block diagram of a host computer communicating via a network node with a wireless device over an at least partially wireless connection according to some embodiments of the present disclosure;

FIG. 3 is a flowchart illustrating example methods implemented in a communication system including a host computer, a network node and a wireless device for executing a client application at a wireless device according to some embodiments of the present disclosure;

FIG. 4 is a flowchart illustrating example methods implemented in a communication system including a host computer, a network node and a wireless device for receiving user data at a wireless device according to some embodiments of the present disclosure;

FIG. 5 is a flowchart illustrating example methods implemented in a communication system including a host computer, a network node and a wireless device for receiving user data from the wireless device at a host computer according to some embodiments of the present disclosure;

FIG. 6 is a flowchart illustrating example methods implemented in a communication system including a host computer, a network node and a wireless device for receiving user data at a host computer according to some embodiments of the present disclosure;

FIG. 7 is a flowchart of an example process in a network node according to some embodiments of the present disclosure;

FIG. 8 is a flowchart of an example process in another network node according to some embodiments of the present disclosure;

FIG. 9 is a flowchart of an example process in a network node according to some embodiments of the present disclosure;

FIG. 10 is a flowchart of another example process in a network node according to some embodiments of the present disclosure;

FIG. 11 is a flowchart of another example process in another network node according to some embodiments of the present disclosure;

FIG. 12 is a flowchart of an example process according to some embodiments of the present disclosure;

FIG. 13 is a flowchart of an example process according to some embodiments of the present disclosure;

FIG. 14 is a flowchart of an example process according to some embodiments of the present disclosure;

FIG. 15 is a flowchart of another example process according to some embodiments of the present disclosure;

FIG. 16 is a flowchart of an example process according to some embodiments of the present disclosure;

FIG. 17 is a flowchart of another example processes according to some embodiments of the present disclosure;

FIG. 18 is a flowchart of an example processes according to some embodiments of the present disclosure; and

FIG. 19 is a flowchart of another example processes according to some embodiments of the present disclosure.

DETAILED DESCRIPTION

Before describing in detail example embodiments, it is noted that the embodiments reside primarily in combinations of apparatus components and processing steps related to automatic radio software management in a cloud network. Accordingly, components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein. Like numbers refer to like elements throughout the description.

As used herein, relational terms, such as “first” and “second,” “top” and “bottom,” and the like, may be used solely to distinguish one entity or element from another entity or element without necessarily requiring or implying any physical or logical relationship or order between such entities or elements. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the concepts described herein. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and/or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

In embodiments described herein, the joining term, “in communication with” and the like, may be used to indicate electrical or data communication, which may be accomplished by physical contact, induction, electromagnetic radiation, radio signaling, infrared signaling or optical signaling, for example. One having ordinary skill in the art will appreciate that multiple components may interoperate and modifications and variations are possible of achieving the electrical and data communication.

In some embodiments described herein, the term “coupled,” “connected,” and the like, may be used herein to indicate a connection, although not necessarily directly, and may include wired and/or wireless connections.

The term “network node” used herein can be any kind of network node comprised in a radio network which may further comprise any of base station (BS), radio base station, base transceiver station (BTS), base station controller (BSC), radio network controller (RNC), g Node B (gNB), evolved Node B (eNB or eNodeB), Node B, multi- standard radio (MSR) radio node such as MSR BS, multi-cell/multicast coordination entity (MCE), integrated access and backhaul (IAB) node, relay node, donor node controlling relay, radio access point (AP), transmission points, transmission nodes, Remote Radio Unit (RRU) Remote Radio Head (RRH), a core network node (e.g., mobile management entity (MME), self-organizing network (SON) node, a coordinating node, positioning node, MDT node, etc.), an external node (e.g., 3rd party node, a node external to the current network), nodes in distributed antenna system (DAS), a spectrum access system (SAS) node, an element management system (EMS), an RSUJC, an RSUJE, a centralized unit (CU) (which may be a virtual CU (vCU) and/or open radio access network distributed unit (O- CU)), a distributed unit (DU)(which may be a virtual DU (vDU) and/or open radio access network distributed unit (O-DU)), a configuration management service (CMS), a Radio Unit (RU) (which may be an eLLS RU (E-RU), and/or open radio access network RU (O-RU)), a server such as an FTP server, an orchestrator, etc. The network node may also comprise test equipment. The term “radio node” used herein may be used to also denote a wireless device (WD) such as a wireless device (WD) or a radio network node.

In some embodiments, the non-limiting terms wireless device (WD) or a user equipment (UE) are used interchangeably. The WD herein can be any type of wireless device capable of communicating with a network node or another WD over radio signals, such as wireless device (WD). The WD may also be a radio communication device, target device, device to device (D2D) WD, machine type WD or WD capable of machine to machine communication (M2M), low-cost and/or low-complexity WD, a sensor equipped with WD, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, Customer Premises Equipment (CPE), an Internet of Things (loT) device, or a Narrowband loT (NB-IOT) device, etc.

Also, in some embodiments the generic term “radio network node” is used. It can be any kind of a radio network node which may comprise any of base station, radio base station, base transceiver station, base station controller, network controller, RNC, evolved Node B (eNB), Node B, gNB, Multi-cell/multicast Coordination Entity (MCE), IAB node, relay node, access point, radio access point, Remote Radio Unit (RRU) Remote Radio Head (RRH).

Note that although terminology from one particular wireless system, such as, for example, 3GPP LTE and/or New Radio (NR), may be used in this disclosure, this should not be seen as limiting the scope of the disclosure to only the aforementioned system. Other wireless systems, including without limitation Wide Band Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMax), Ultra Mobile Broadband (UMB) and Global System for Mobile Communications (GSM), may also benefit from exploiting the ideas covered within this disclosure.

Note further, that functions described herein as being performed by a wireless device or a network node may be distributed over a plurality of wireless devices and/or network nodes. In other words, it is contemplated that the functions of the network node and wireless device described herein are not limited to performance by a single physical device and, in fact, can be distributed among several physical devices.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

Some embodiments provide automatic radio software management, e.g., without user intervention.

Referring now to the drawing figures, in which like elements are referred to by like reference numerals, there is shown in FIG. 1 a schematic diagram of a communication system 10, according to an embodiment, such as a 3GPP-type cellular network that may support standards such as LTE and/or NR (5G), which comprises an access network 12, such as a radio access network, and a core network 14. The access network 12 comprises a plurality of network nodes 16a, 16b, 16c (referred to collectively as network nodes 16), such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 18a, 18b, 18c (referred to collectively as coverage areas 18). Each network node 16a, 16b, 16c is connectable to the core network 14 over a wired or wireless connection 20. A first wireless device (WD) 22a located in coverage area 18a is configured to wirelessly connect to, or be paged by, the corresponding network node 16a. A second WD 22b in coverage area 18b is wirelessly connectable to the corresponding network node 16b. While a plurality of WDs 22a, 22b (collectively referred to as wireless devices 22) are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole WD is in the coverage area or where a sole WD is connecting to the corresponding network node 16. Note that although only two WDs 22 and three network nodes 16 are shown for convenience, the communication system may include many more WDs 22 and network nodes 16.

Also, it is contemplated that a WD 22 can be in simultaneous communication and/or configured to separately communicate with more than one network node 16 and more than one type of network node 16. For example, a WD 22 can have dual connectivity with a network node 16 that supports LTE and the same or a different network node 16 that supports NR. As an example, WD 22 can be in communication with an eNB for LTE/E-UTRAN and a gNB for NR/NG-RAN.

The communication system 10 may itself be connected to a host computer 24, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. The host computer 24 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The connections 26, 28 between the communication system 10 and the host computer 24 may extend directly from the core network 14 to the host computer 24 or may extend via an optional intermediate network 30. The intermediate network 30 may be one of, or a combination of more than one of, a public, private or hosted network. The intermediate network 30, if any, may be a backbone network or the Internet. In some embodiments, the intermediate network 30 may comprise two or more sub-networks (not shown).

The communication system of FIG. 1 as a whole enables connectivity between one of the connected WDs 22a, 22b and the host computer 24. The connectivity may be described as an over-the-top (OTT) connection. The host computer 24 and the connected WDs 22a, 22b are configured to communicate data and/or signaling via the OTT connection, using the access network 12, the core network 14, any intermediate network 30 and possible further infrastructure (not shown) as intermediaries. The OTT connection may be transparent in the sense that at least some of the participating communication devices through which the OTT connection passes are unaware of routing of uplink and downlink communications. For example, a network node 16 may not or need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 24 to be forwarded (e.g., handed over) to a connected WD 22a. Similarly, the network node 16 need not be aware of the future routing of an outgoing uplink communication originating from the WD 22a towards the host computer 24.

A network node 16 is configured to include a node determination unit 32 which is configured to perform any step and/or process and/or feature and/or function described herein, e.g., perform an automatic radio software management, perform the functions of any one of an orchestrator, FTP server, etc. A wireless device 22 is configured to include a WD determination unit 34 which is configured to perform any step and/or process and/or feature and/or function described herein.

Example implementations, in accordance with an embodiment, of the WD 22, network node 16 and host computer 24 discussed in the preceding paragraphs will now be described with reference to FIG. 2. In a communication system 10, a host computer 24 comprises hardware (HW) 38 including a communication interface 40 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 10. The host computer 24 further comprises processing circuitry 42, which may have storage and/or processing capabilities. The processing circuitry 42 may include a processor 44 and memory 46. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 42 may comprise integrated circuitry for processing and/or control, e.g., one or more processors and/or processor cores and/or FPGAs (Field Programmable Gate Array) and/or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 44 may be configured to access (e.g., write to and/or read from) memory 46, which may comprise any kind of volatile and/or nonvolatile memory, e.g., cache and/or buffer memory and/or RAM (Random Access Memory) and/or ROM (Read- Only Memory) and/or optical memory and/or EPROM (Erasable Programmable Read-Only Memory).

Processing circuitry 42 may be configured to control any of the methods and/or processes described herein and/or to cause such methods, and/or processes to be performed, e.g., by host computer 24. Processor 44 corresponds to one or more processors 44 for performing host computer 24 functions described herein. The host computer 24 includes memory 46 that is configured to store data, programmatic software code and/or other information described herein. In some embodiments, the software 48 and/or the host application 50 may include instructions that, when executed by the processor 44 and/or processing circuitry 42, causes the processor 44 and/or processing circuitry 42 to perform the processes described herein with respect to host computer 24. The instructions may be software associated with the host computer 24.

The software 48 may be executable by the processing circuitry 42. The software 48 includes a host application 50. The host application 50 may be operable to provide a service to a remote user, such as a WD 22 connecting via an OTT connection 52 terminating at the WD 22 and the host computer 24. In providing the service to the remote user, the host application 50 may provide user data which is transmitted using the OTT connection 52. The “user data” may be data and information described herein as implementing the described functionality. In one embodiment, the host computer 24 may be configured for providing control and functionality to a service provider and may be operated by the service provider or on behalf of the service provider. The processing circuitry 42 of the host computer 24 may enable the host computer 24 to observe, monitor, control, transmit to and/or receive from the network node 16 and or the wireless device 22. The processing circuitry 42 of the host computer 24 may include a host determining unit 54 configured to enable the service provider to perform any step and/or process and/or feature and/or function described herein, e.g., observe/monitor/ control/transmit to/receive from the network node 16 and or the wireless device 22.

The communication system 10 further includes a network node 16 provided in a communication system 10 and including hardware 58 enabling it to communicate with the host computer 24 and with the WD 22. The hardware 58 may include a communication interface 60 for setting up and maintaining a wired or wireless connection with an interface of a different communication device (e.g., any other network node 16) of the communication system 10, as well as a radio interface 62 for setting up and maintaining at least a wireless connection 64 with a WD 22 located in a coverage area 18 served by the network node 16. The radio interface 62 may be formed as or may include, for example, one or more RF transmitters, one or more RF receivers, and/or one or more RF transceivers. The communication interface 60 may be configured to facilitate a connection 66 to the host computer 24. The connection 66 may be direct or it may pass through a core network 14 of the communication system 10 and/or through one or more intermediate networks 30 outside the communication system 10.

In the embodiment shown, the hardware 58 of the network node 16 further includes processing circuitry 68. The processing circuitry 68 may include a processor 70 and a memory 72. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 68 may comprise integrated circuitry for processing and/or control, e.g., one or more processors and/or processor cores and/or FPGAs (Field Programmable Gate Array) and/or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 70 may be configured to access (e.g., write to and/or read from) the memory 72, which may comprise any kind of volatile and/or nonvolatile memory, e.g., cache and/or buffer memory and/or RAM (Random Access Memory) and/or ROM (Read-Only Memory) and/or optical memory and/or EPROM (Erasable Programmable Read-Only Memory).

Thus, the network node 16 further has software 74 stored internally in, for example, memory 72, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by the network node 16 via an external connection. The software 74 may be executable by the processing circuitry 68. The processing circuitry 68 may be configured to control any of the methods and/or processes described herein and/or to cause such methods, and/or processes to be performed, e.g., by network node 16. Processor 70 corresponds to one or more processors 70 for performing network node 16 functions described herein. The memory 72 is configured to store data, programmatic software code and/or other information described herein. In some embodiments, the software 74 may include instructions that, when executed by the processor 70 and/or processing circuitry 68, causes the processor 70 and/or processing circuitry 68 to perform the processes described herein with respect to network node 16. For example, processing circuitry 68 of the network node 16 may include node determination unit 32 configured to perform any step and/or process and/or feature and/or function described herein, e.g., perform an automatic radio software management, perform the functions of any one of an orchestrator, FTP server, etc. The processing circuitry 68 may also include RSUJC 100 configured to perform any step and/or process and/or feature and/or function described herein, e.g., any step and/or process and/or feature and/or function of the RSUJC. The processing circuitry 68 may also include RSUJE 102 configured to perform any step and/or process and/or feature and/or function described herein, e.g., any step and/or process and/or feature and/or function of the RSUJE. The processing circuitry 68 may also include CU 104 configured to perform any step and/or process and/or feature and/or function described herein, e.g., corresponding to any CU described herein. The processing circuitry 68 may also include DU 106 configured to perform any step and/or process and/or feature and/or function described herein, e.g., corresponding to any DU described herein. The processing circuitry 68 may also include CMS 108 configured to perform any step and/or process and/or feature and/or function described herein, e.g., corresponding to any configuration management service described herein. CMS 108 may refer to a virtual distributed unit CMS. The processing circuitry 68 may also include RU 110 configured to perform any step and/or process and/or feature and/or function described herein, e.g., corresponding to any RU described herein. RU may refer to any network node 16.

Although processing circuitry 68 is shown as including RSUJC 100, RSUJE 102, CU 104, DU 106, CMS 108, RU 110, processing circuitry 68 is not limited as such and may include none of, or one or more of, each of RSUJC 100, RSUJE 102, CU 104, DU 106, CMS 108, RU 110. In a nonlimiting example, a first network node 16a may comprise (e.g., as part of processing circuitry 68) an RSUJC 100, a second network node 16b may comprise (e.g., as part of processing circuitry 68) a RSUJE 102, and a third network node 16c may comprise (e.g., as part of processing circuitry 68) a CMS 108 such as a DU CMS. Each network node 16 may communicate with any other device such as other network node 16, e.g., the first, second, and third network nodes 16a, 16b, 16c may be in communication with each other, via communication interface 60 and/or radio interface 62. It is also understood that implementations may include more than or fewer than three network nodes, e.g., a fourth network node 16d (not shown in FIG. 1).

The communication system 10 further includes the WD 22 already referred to. The WD 22 may have hardware 80 that may include a radio interface 82 configured to set up and maintain a wireless connection 64 with a network node 16 serving a coverage area 18 in which the WD 22 is currently located. The radio interface 82 may be formed as or may include, for example, one or more RF transmitters, one or more RF receivers, and/or one or more RF transceivers.

The hardware 80 of the WD 22 further includes processing circuitry 84. The processing circuitry 84 may include a processor 86 and memory 88. In particular, in addition to or instead of a processor, such as a central processing unit, and memory, the processing circuitry 84 may comprise integrated circuitry for processing and/or control, e.g., one or more processors and/or processor cores and/or FPGAs (Field Programmable Gate Array) and/or ASICs (Application Specific Integrated Circuitry) adapted to execute instructions. The processor 86 may be configured to access (e.g., write to and/or read from) memory 88, which may comprise any kind of volatile and/or nonvolatile memory, e.g., cache and/or buffer memory and/or RAM (Random Access Memory) and/or ROM (Read-Only Memory) and/or optical memory and/or EPROM (Erasable Programmable Read-Only Memory).

Thus, the WD 22 may further comprise software 90, which is stored in, for example, memory 88 at the WD 22, or stored in external memory (e.g., database, storage array, network storage device, etc.) accessible by the WD 22. The software 90 may be executable by the processing circuitry 84. The software 90 may include a client application 92. The client application 92 may be operable to provide a service to a human or non-human user via the WD 22, with the support of the host computer 24. In the host computer 24, an executing host application 50 may communicate with the executing client application 92 via the OTT connection 52 terminating at the WD 22 and the host computer 24. In providing the service to the user, the client application 92 may receive request data from the host application 50 and provide user data in response to the request data. The OTT connection 52 may transfer both the request data and the user data. The client application 92 may interact with the user to generate the user data that it provides.

The processing circuitry 84 may be configured to control any of the methods and/or processes described herein and/or to cause such methods, and/or processes to be performed, e.g., by WD 22. The processor 86 corresponds to one or more processors 86 for performing WD 22 functions described herein. The WD 22 includes memory 88 that is configured to store data, programmatic software code and/or other information described herein. In some embodiments, the software 90 and/or the client application 92 may include instructions that, when executed by the processor 86 and/or processing circuitry 84, causes the processor 86 and/or processing circuitry 84 to perform the processes described herein with respect to WD 22. For example, the processing circuitry 84 of the wireless device 22 may include a WD determination unit 34 configured to perform any step and/or process and/or feature and/or function described herein.

In some embodiments, the inner workings of the network node 16, WD 22, and host computer 24 may be as shown in FIG. 2 and independently, the surrounding network topology may be that of FIG. 1.

In FIG. 2, the OTT connection 52 has been drawn abstractly to illustrate the communication between the host computer 24 and the wireless device 22 via the network node 16, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the WD 22 or from the service provider operating the host computer 24, or both. While the OTT connection 52 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).

The wireless connection 64 between the WD 22 and the network node 16 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the WD 22 using the OTT connection 52, in which the wireless connection 64 may form the last segment. More precisely, the teachings of some of these embodiments may improve the data rate, latency, and/or power consumption and thereby provide benefits such as reduced user waiting time, relaxed restriction on file size, better responsiveness, extended battery lifetime, etc.

In some embodiments, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 52 between the host computer 24 and WD 22, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 52 may be implemented in the software 48 of the host computer 24 or in the software 90 of the WD 22, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 52 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 48, 90 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 52 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the network node 16, and it may be unknown or imperceptible to the network node 16. Some such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary WD signaling facilitating the host computer’s 24 measurements of throughput, propagation times, latency and the like. In some embodiments, the measurements may be implemented in that the software 48, 90 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 52 while it monitors propagation times, errors, etc.

Thus, in some embodiments, the host computer 24 includes processing circuitry 42 configured to provide user data and a communication interface 40 that is configured to forward the user data to a cellular network for transmission to the WD 22. In some embodiments, the cellular network also includes the network node 16 with a radio interface 62. In some embodiments, the network node 16 is configured to, and/or the network node’s 16 processing circuitry 68 is configured to perform the functions and/or methods described herein for preparing/initiating/maintaining/supporting/ending a transmission to the WD 22, and/or preparing/terminating/maintaining/supporting/ending in receipt of a transmission from the WD 22.

In some embodiments, the host computer 24 includes processing circuitry 42 and a communication interface 40 that is configured to a communication interface 40 configured to receive user data originating from a transmission from a WD 22 to a network node 16. In some embodiments, the WD 22 is configured to, and/or comprises a radio interface 82 and/or processing circuitry 84 configured to perform the functions and/or methods described herein for preparing/initiating/maintaining/supporting/ending a transmission to the network node 16, and/or preparing/terminating/maintaining/supporting/ending in receipt of a transmission from the network node 16.

Although FIGS. 1 and 2 show various “units” such as node determination unit 32 (and/or RSUJC 100 and/or RSUJE 102 and/or CU 104 and/or DU 106 and/or CMS 108 and/or RU 110), and WD determination unit 34 as being within a respective processor, it is contemplated that these units may be implemented such that a portion of the unit is stored in a corresponding memory within the processing circuitry. In other words, the units may be implemented in hardware or in a combination of hardware and software within the processing circuitry.

FIG. 3 is a flowchart illustrating an example method implemented in a communication system, such as, for example, the communication system of FIGS. 1 and 2, in accordance with one embodiment. The communication system may include a host computer 24, a network node 16 and a WD 22, which may be those described with reference to FIG. 2. In a first step of the method, the host computer 24 provides user data (Block S100). In an optional substep of the first step, the host computer 24 provides the user data by executing a host application, such as, for example, the host application 50 (Block S102). In a second step, the host computer 24 initiates a transmission carrying the user data to the WD 22 (Block S104). In an optional third step, the network node 16 transmits to the WD 22 the user data which was carried in the transmission that the host computer 24 initiated, in accordance with the teachings of the embodiments described throughout this disclosure (Block S106). In an optional fourth step, the WD 22 executes a client application, such as, for example, the client application 92, associated with the host application 50 executed by the host computer 24 (Block s 108).

FIG. 4 is a flowchart illustrating an example method implemented in a communication system, such as, for example, the communication system of FIG. 1, in accordance with one embodiment. The communication system may include a host computer 24, a network node 16 and a WD 22, which may be those described with reference to FIGS. 1 and 2. In a first step of the method, the host computer 24 provides user data (Block SI 10). In an optional substep (not shown) the host computer 24 provides the user data by executing a host application, such as, for example, the host application 50. In a second step, the host computer 24 initiates a transmission carrying the user data to the WD 22 (Block S 112). The transmission may pass via the network node 16, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third step, the WD 22 receives the user data carried in the transmission (Block S 114).

FIG. 5 is a flowchart illustrating an example method implemented in a communication system, such as, for example, the communication system of FIG. 1, in accordance with one embodiment. The communication system may include a host computer 24, a network node 16 and a WD 22, which may be those described with reference to FIGS. 1 and 2. In an optional first step of the method, the WD 22 receives input data provided by the host computer 24 (Block SI 16). In an optional substep of the first step, the WD 22 executes the client application 92, which provides the user data in reaction to the received input data provided by the host computer 24 (Block SI 18). Additionally or alternatively, in an optional second step, the WD 22 provides user data (Block S120). In an optional substep of the second step, the WD provides the user data by executing a client application, such as, for example, client application 92 (Block S122). In providing the user data, the executed client application 92 may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the WD 22 may initiate, in an optional third substep, transmission of the user data to the host computer 24 (Block S124). In a fourth step of the method, the host computer 24 receives the user data transmitted from the WD 22, in accordance with the teachings of the embodiments described throughout this disclosure (Block S126).

FIG. 6 is a flowchart illustrating an example method implemented in a communication system, such as, for example, the communication system of FIG. 1, in accordance with one embodiment. The communication system may include a host computer 24, a network node 16 and a WD 22, which may be those described with reference to FIGS. 1 and 2. In an optional first step of the method, in accordance with the teachings of the embodiments described throughout this disclosure, the network node 16 receives user data from the WD 22 (Block S128). In an optional second step, the network node 16 initiates transmission of the received user data to the host computer 24 (Block S130). In a third step, the host computer 24 receives the user data carried in the transmission initiated by the network node 16 (Block S132).

FIG. 7 is a flowchart of an example process in a network node 16 (e.g., a first network node 16a comprising a RSUJC 100). One or more blocks described herein may be performed by one or more elements of network node 16 such as by one or more of processing circuitry 68 (including the node determination unit 32 and/or RSUJC 100), processor 70, radio interface 62 and/or communication interface 60. Network node 16 such as via processing circuitry 68 and/or processor 70 and/or radio interface 62 and/or communication interface 60 is configured to determine (Block S134) a software version associated with a software upgrade of a fourth network node 16d based on a configuration, the configuration indicating whether at least one of: to accept a software version indicated in the configuration, the software version being associated with a software upgrade of a fourth network node 16d; and to automatically select the software version.

In some embodiments, the method further includes at least one of querying a software inventory of the third network node 16c to automatically select the software version and automatically selecting the software version.

In some other embodiments, the method further includes determining that the software inventory is configured with a plurality of software versions; querying the second network node 16b based on the determination that the software inventory is configured with the plurality of software versions; and determining a software version currently running on the fourth network node 16d based on the query of the second network node 16b.

In one embodiment, the method further includes requesting the second network node 16b to perform the software upgrade of the fourth network node 16d using the determined software version.

In another embodiment, at least the first network node 16a and the third network node 16c are deployed as part of the same distributed unit.

In some embodiments, the software version indicates a software product and the software version.

In some other embodiments, the first network node 16 comprises a radio software upgrade job controller 100, the second network node 16b comprises a radio software upgrade job engine 102, the third network node 16c comprises a distributed unit configuration management service (CMS) 108, and the fourth network node 16d comprises a radio unit 110 configurable to be upgraded with the software upgrade.

FIG. 8 is a flowchart of an example process in a network node 16 (e.g., a second network node 16b comprising an RSUJE 102) according to some embodiments of the present disclosure. One or more blocks described herein may be performed by one or more elements of network node 16 such as by one or more of processing circuitry 68 (including the node determination unit 32 and/or RSUJE 102), processor 70, radio interface 62 and/or communication interface 60. Network node 16 such as via processing circuitry 68 and/or processor 70 and/or radio interface 62 and/or communication interface 60 is configured to receive (Block S136) a request from the first network node 16a to perform a software upgrade of the fourth network node 16d using a software version, the software version being based on a configuration of the first network node 16a.

In some embodiments, the method further includes receiving a query from the first network node 16a to determine a software version currently running on the fourth network node 16d.

In some other embodiments, the method further includes fetching a software package based on the received request; and causing the fourth network node 16d to perform the software upgrade of the fourth network node 16d using the software version.

In some embodiments, the software version indicates a software product and the software version.

In some other embodiments, the first network node 16 comprises a radio software upgrade job controller (RSUJC) 100, the second network node 16b comprises a radio software upgrade job engine 102, the third network node 16c comprises a distributed unit configuration management service 108, and the fourth network node 16d comprises a radio unit 110 configurable to be upgraded with the software upgrade.

FIG. 9 is a flowchart of an example process in a network node 16 (e.g., a third network node 16c comprising an CMS 108) according to some embodiments of the present disclosure. One or more blocks described herein may be performed by one or more elements of network node 16 such as by one or more of processing circuitry 68 (including the node determination unit 32 and/or CMS 108), processor 70, radio interface 62 and/or communication interface 60. Network node 16 such as via processing circuitry 68 and/or processor 70 and/or radio interface 62 and/or communication interface 60 is configured to determine (Block S136) a software inventory, the software inventory including a configuration map 300 obtained from a server and being usable to determine a software version associated with a software upgrade of the fourth network node 16d.

In some embodiments, the method further includes receiving a query of the software inventory from the first network node 16a; and transmitting at least one software version to the first network node 16a for the first network node 16a to determine the software version associated with the software upgrade of the fourth network node 16d. The software upgrade of the fourth network node 16d is triggered by the second network node 16b.

In some other embodiments, the software inventory is obtained from the server via a software inventory manager, the software inventory manager reading the configuration map 300 from the server and providing software metadata to the third network node 16c.

In one embodiment, the software metadata is included in a chart.

In some embodiments, the software version indicates a software product and the software version.

In some other embodiments, the first network node 16 comprises a radio software upgrade job controller 100, the second network node 16b comprises a radio software upgrade job engine (RSUJE) 102, the third network node 16c comprises a distributed unit configuration management service 108, and the fourth network node 16d comprises a radio unit 110 configurable to be upgraded with the software upgrade.

FIG. 10 is a flowchart of another example process in a network node 16 (e.g., a first network node 16a comprising a RSUJC 100). One or more blocks described herein may be performed by one or more elements of network node 16 such as by one or more of processing circuitry 68 (including the node determination unit 32 and/or RSUJC 100), processor 70, radio interface 62 and/or communication interface 60. Network node 16 such as via processing circuitry 68 and/or processor 70 and/or radio interface 62 and/or communication interface 60 is configured to determine (Block S140) a configuration map 300 mountable as a data volume of the first network node 16a, where the configuration map 300 stores a list of software file names associated with a software upgrade of at least a third network node 16c; determine (Block S142) a software upgrade request usable to trigger the second network node 16b to perform the software upgrade of at least the third network node 16c, where the software upgrade request comprises the list of software file names stored in the configuration map 300; and transmit (Block S144) the software upgrade request to the second network node 16b.

In some embodiments, the list of software file names is specified in a human- readable data serialization language file.

In some other embodiments, the determination of the configuration map 300 comprises mounting the configuration map 300 as the data volume of the first network node 16a.

In some embodiments, the configuration map 300 is mounted by a pod created by a job associated with the first network node 16a.

In some other embodiments, the job starts the pod, where the pod is configured as a client for an application programming interface (API).

In some embodiments, the client is usable for communication between the first network node 16a and the second network node 16b, and the software upgrade request is transmitted by the client.

In some other embodiments, one or both of the configuration map 300 is provided by a fourth network node 16d and the fourth network node 16d comprises a virtual distributed unit (vDU).

In some embodiments, the method further comprises storing the configuration map 300 in a data volume.

In some other embodiments, the software upgrade of at least the third network node 16c is to be performed automatically by the second network node 16b.

In some embodiments, the first network node 16a comprises a Radio Software Upgrade Job Controller (RSUJC), the second network node 16b comprises a Radio Software Upgrade Job Engine (RSUJE), and the third network node 16c comprises a radio unit configurable to be upgraded with the software upgrade.

FIG. 11 is a flowchart of an example process in a network node 16 (e.g., a second network node 16b comprising an RSUJE 102) according to some embodiments of the present disclosure. One or more blocks described herein may be performed by one or more elements of network node 16 such as by one or more of processing circuitry 68 (including the node determination unit 32 and/or RSUJE 102), processor 70, radio interface 62 and/or communication interface 60. Network node 16 such as via processing circuitry 68 and/or processor 70 and/or radio interface 62 and/or communication interface 60 is configured to receive (Block S146) a software upgrade request from the first network node 16a, where the software upgrade request is usable to trigger the second network node 16b to perform a software upgrade of at least the third network node 16c, the software upgrade request comprises a list of software file names stored in a configuration map 300, the configuration map 300 is mountable as a data volume of the first network node 16a, and the configuration map 300 stores the list of software file names associated with the software upgrade of at least the third network node 16c; and perform (Block S148) the software upgrade of at least the third network node 16c based on the software upgrade request.

In some embodiments, the list of software file names is specified in a human- readable data serialization language file.

In some other embodiments, the method further comprises transmitting a fetch request to a fifth network node 16e. The fetch request comprises the list of software file names comprised in the software upgrade request, and the fifth network node 16e comprises a file server.

In some embodiments, the method further comprises receiving one or more software files associated with one or more software file names comprised in the fetch request, where the one or more software files is used to perform the software upgrade of at least the third network node 16c; and storing the one or more software files in a local volume. The local volume is a persistent volume connected to a pod associated with the second network node 16b.

In some other embodiments, the method further comprises one or more of determining the third network node 16c is not running a software version corresponding to the one or more software files; selecting the one or more software files, the one or more software files being is compatible with the third network node 16c; and causing the third network node 16c to load the one or more software files; and causing the third network node 16c to restart and activate the one or more software files.

In some embodiments, the method further comprises updating a software inventory indicating the software version has been loaded and activated on the third network node 16c. In some other embodiments, the performing of the software upgrade causes the third network node 16c to disconnect from a virtual distributed unit (vDU) and reconnect to the vDU.

In some embodiments, the method further comprises stopping the software upgrade when the third network node 16c is disconnected from the vDU and resuming the software upgrade when the third network node 16c is reconnected to the vDU.

In some other embodiments, the method further comprises automatically performing the software upgrade of at least the third network node 16c.

In some embodiments, the first network node 16a comprises a Radio Software Upgrade Job Controller (RSUJC), the second network node 16b comprises a Radio Software Upgrade Job Engine (RSUJE), and the third network node 16c comprises a radio unit configurable to be upgraded with the software upgrade.

Having described the general process flow of arrangements of the disclosure and having provided examples of hardware and software arrangements for implementing the processes and functions of the disclosure, the sections below provide details and examples of arrangements for automatic radio software management.

Some embodiments provide one or more network nodes 16. Each network node 16 may comprise one or more of an RSUJC 100, RSUJE 102, CU 104 (such as a vCU, O-CU), DU 106 (such as a vDU, O-DU), CMS 108 (such as a vDU CMS, O- DU CMS), RU 110 (such as E-RU, O-RU), an FTP server, Orchestrator, software inventory manager such as a vDU/O-DU software inventory manager, API server such as a k8s API server, and/or any other component. Each network node 16 may be configured to communicate with one or more devices such as other network nodes 16, e.g., via communication interface 60 and/or radio interface 62.

FIG. 12 is a flowchart of an example process according to some embodiments, e.g., a process for upgrading vDU and E-RUs. More specifically, FIG. 12 shows a manual trigger of an Ericsson lower layer split (E-LLS) radio software upgrade with a manual input of an E-ELLs radio unit (E-RU) software version using RSUJC 100 and RSUJE 102. The process may involve one or more of the following: an orchestrator 200 (e.g., a network node 16 comprising a Helm client), a server 202 (e.g., a network node 16 comprising an FTP server), a vDU traffic service 204 (e.g., a network node 16 configured to perform one or more steps associated with a vDU traffic service), a server 212 (e.g., a k8s API server), a CU 104 (e.g., a vCU), a DU 106 (e.g., a vDU), etc. At step S200, a helm upgrade vDU is determined. At step S202, a helm install associated with a RSUJC (URI) is performed. At step S204, a request is made from network node (NN) 16a (e.g., RSUJC) to NN 16b (e.g., RSUJE) is made. The request may be a request to perform an upgrade job for one or more RUs. At step S206, NN 16b may fetch a software package, e.g., a software package corresponding to the request to be fetched from server 202 (e.g., FTP server). At step S208, NN 16b may trigger at least one NN 16d (e.g., one or more RUs) to perform a software upgrade. In some embodiments, the RSUJE may be deployed together with the vDU.

FIG. 13 is a flowchart of an example process according to some embodiments, e.g., a process for upgrading open radio access network (O-RAN) distributed unit (O- DU) and one or more O-RAN radio unit (O-RUs). More specifically, FIG. 13 shows a manual trigger of an O-LLS radio software upgrade with a manual input of an O-RU software version using RSUJC 100 and RSUJE 102. At step S300, a helm upgrade vDU is determined. At step S302, a helm install associated with a RSUJC (URI) is performed. At step S304, a request is made from network node (NN) 16a (e.g., RSUJC) to NN 16b (e.g., RSUJE) is made. The request may be a request to perform an upgrade job for one or more RUs. At step S306, NN 16b may fetch a software package, e.g., a software package corresponding to the request to be fetched from SERVER 202 (e.g., an FTP server). At step S3O8, NN 16b may trigger at least one NN 16d (e.g., one or more RUs) to perform a software upgrade, e.g., download, install, and/or activate O-RU LMC and/or reset O-RU. At step S310, server 208 (e.g., an FTP) server may perform an O-RU LMC download. In some embodiments, the RSUJE may be deployed together with the O-DU.

In some embodiments, automatic RU (e.g., E-RU and/or O-RU) software selection with a RSUJC may include one or more parts.

The first part may include a list of RU software products and versions, e.g., that are recommended or tested with the vDU/O-DU SW version, in one or more vDU/O-DU helm charts, which may include metadata. Such metadata may be defined in two separate key value pairs for each software load and/or concatenated into a single key value pair. The metadata may be added to the vDU/O-DU helm chart, e.g., by a development or verification team at the end of the verification cycle. Below is a nonlimiting example of a list of concatenated RU software products and versions that may be added to a file, e.g., a values.yaml file of the vDU helm chart. The same example may apply to an O-DU helm chart. The example shows two RU software products and versions, which may be recommended or tested with the vDU with product number CXF 101 0100/2, and version (revision) R38OA. In this nonlimiting example, the RU SW products and versions are:

• E-RU software product number CXF2010002_l with version (revision) R74A206

• E-RU software product number CXF2010003_l with version (revision) R74A205.

The nonlimiting example helm chart (e.g., extension to vDU helm chart) may be as follows:

#vDU software inventory Product Information. product: number: CXF 101 0100/2 revision: R38OA name: Cloud RAN DU production_date: 2022-02-02T05: 13:43+00:00 description: Cloud RAN DU type: Cloud RAN DU radioSoftware_l : E-RADIO- 74.1.206- CXF2010002 _1 -R 74A206 radioSoftware_2: E-RADIO-DEV-74.1.205-CXF2010003_l-R74A205

The nonlimiting example helm chart is not limited as such and may include at least one of the radioSoftware_l, the radioSoftware_2, and any other radioSoftware entry.

The second part may include automatically loading extended vDU/O-DU metadata with a list of recommended RU software loads into a configuration map 300 (e.g., k8s ConfigMap) such as using helm templating. This may be done when vDU is instantiated and/or upgraded. Below is a nonlimiting example of k8s ConfigMap with the vDU and RU software information implemented as k8s annotations: apiVersion: vl kind: ConfigMap metadata: name: eric-ran-du-nr annotations: ericsson.com/product-name: Cloud RAN DU ericsson.com/product-number: CXF 101 0100/2 ericsson.com/product-revision: R38OA ericsson.com/production-date: 2022-02-02T05: 13:46+00:00 ericsson.com/description: Cloud RAN DU ericsson.com/type: Cloud RAN DU ericsson.com/radioSoftware- 1: E-RADIO-74.1.206-CXF2010002_l-R74A206 ericsson.com/radioSoftware-2: E-RADIO-DEV-74.1.205-CXF2010003_1- R74A205

Another nonlimiting example configuration map 300 is as follows: apiVersion: vl kind: ConfigMap metadata: name: { { include “eric-ran-du-nr.name” . } } labels: ericsson.com/swim: “enabled”

{ { include “eric-ran-du-nr.labels” . | indent 4 } } annotations: ericsson.com/product-name: { { . Values. product.name | quote } } ericsson.com/product-number: { { . Values. product.number | quote } } ericsson.com/product-revision: { { .Values. product. revision | quote } } ericsson.com/production-date: { { .Values.product.production_date } } ericsson.com/description: { { .Values.product.description | quote } } ericsson.com/type: { { .Values.product.type | quote} } ericsson.com/radio-software- 1: { { .Values.product.radio_software_l | quote} }

{ { include “eric-ran-du-nr.config-annotations” . | indent 4 } }

A service (e.g., software inventory manager) may be executed (e.g., the software inventory manager may be realized as a k8s job, on a network node 16). The software inventory manager may be executed after the k8s ConfigMap is created and/or during the vDU/0-DU instantiation and/or upgrade to dynamically read the ConfigMap. Relevant information may be extracted, and the data sent to the vDU/0- DU configuration manager (i.e., acting as a server for storing, accessing, and/or updating the vDU metadata and configuration data).

FIG. 14 shows an example process involving a software inventory manager according to some embodiments, e.g., a nonlimiting example of an inventory manager interacting with a server 212 (e.g., the k8s API server) to read a configuration map 300 (e.g., the vDU/O-RU ConfigMap) and updating the vDU/O-RU configuration manager (i.e., configuration management services 108). At step S400, software inventory manager (e.g., vDU/O-DU software inventory manager such as an inventory manager comprised in a NN 16) reads a configuration map 300 from a server 212 (e.g., a k8s API server comprised in another NN 16). At step S402, software inventory manager 210 (e.g., vDU/O-DU software inventory manager) writes software metadata to vDU/O-RU configuration management service (e.g., comprised in NN 16c of FIGS. 12 and 13), which may be configured to store data in a data storage such as memory 72.

However, the principles of the present disclosure are not limited as such and may be implemented in any other way, e.g., implemented without a software inventory manager. The vDU/O-DU configuration manager may be configured to directly read the configuration map (i.e., ConfigMap) and/or update its database (i.e., data storage). This nonlimiting example is shown in FIG. 15. At step S500, vDU/O- DU configuration management service 108 (e.g., comprised in NN 16c of FIGS. 12 andl3) may be configured to read the configuration map 300 (e.g., vDU/O-DU configuration map from a server 212 such as a k8s API server comprised in a NN 16) and/or, at step S502, write software metadata locally (e.g., update its data storage such as memory 72).

Further, the RSUJC 100 (e.g., comprised in NN 16a) may be configured to accept an explicit radio software product and version to load on the radio units and/or allow RSUJC 100 to choose the version that is recommended by the vDU metadata. For example, such configuration option can be implemented with a parameter called swFilename (i.e., a software file name). An example swFilename may be as follows: swFilename: description: | -

The name of the unit software package (ZIP file) to load on the unit(s). The string “automatic” has a special meaning. It is used to automate the selection of the unit software package for a user job.

Type: string example 1: E-RADIO-74.L206-CXF2010002_l-R74A206.zip example 2: automatic

If “swFilename” is configured to “automatic”, then RSUJC 100 may be configured to query vDU/O-DU configuration manager and/or automatically select the software to load on RUs. If not, RSUJC 100 may be configured to use an explicit filename, e.g., that is specified by a user.

If the vDU/O-DU software inventory is configured with multiple recommended RU software products and versions, then RSUJC 100 may query the RSUJE 102 to determine the RU software product number and revision currently running on the RUs connected to the DU 106 (e.g., vDU). Based on this information, RSUJC 100 may determine the exact recommended/tested RU software version for each RU and/or trigger one or more radio software upgrade jobs towards the RSUJE 102. Each upgrade job request may be for loading a RU software load on a group of radio units of the same kind (type). In one nonlimiting example, there is a single upgrade job needed to upgrade the RUs, e.g., because the RUs are of the same type running the same RU software product number.

In some embodiments, the E-LLS radio software upgrade may be triggered with automatic selection of the recommended/tested E-RU software version using the RSUJC 100 and RSUJE 102. More specifically, a helm upgrade vDU is determined, and a helm install associated with a RSUJC (automatic) is performed. Further, NN 16a may read runtime vDU version(s), including radio software version(s), and NN 16a (e.g., RSUJC) may read RUs which may include hardware identifiers and/or running software. A request may be made from network node (NN) 16a (e.g., RSUJC) to NN 16b (e.g., RSUJE). The request may be a request to perform an upgrade job for one or more RUs. NN 16b may fetch a software package, e.g., a software package corresponding to the request. NN 16b may further trigger at least one NN 16d (e.g., one or more RUs) to perform a software upgrade. In some embodiments, the RSUJE is deployed together with the vDU.

In some embodiments, an O-LLS radio software upgrade may be triggered with automatic selection of the recommended/tested O-RU software version using the RSUJC 100 and RSUJE 102. More specifically, a helm upgrade vDU is determined, and a helm install associated with a RSUJC (automatic) is performed. Further, NN 16a may read runtime vDU version(s), including radio software version(s) and read RUs which may include hardware identifiers and/or running software. A request is made from network node (NN) 16a (e.g., RSUJC) to NN 16b (e.g., RSUJE). The request may be a request to perform an upgrade job for one or more RUs. NN 16b may fetch a software package, e.g., a software package corresponding to the request. NN 16b may trigger at least one NN 16d (e.g., one or more RUs) to perform a software upgrade. An FTP server may perform one or more O-RU LMC downloads. In some embodiments, the RSUJE is deployed together with the O-DU.

Another part is to deploy the RSUJC 100 together with the vDU/O-DU instance. The embodiments of the present disclosure allow at least for automatic trigger of the radio software upgrade when performing a vDU software upgrade with automatic selection of the recommended/tested radio software product(s) and version(s).

FIG. 16 shows an example automatic trigger of a radio software upgrade (e.g., E-LLS radio software upgrade) together with a vDU software upgrade and with automatic selection of the recommended/tested E-RU software version using the RSUJC 100 and RSUJE 102. The RSUJC 100 may be deployed together (i.e., as part of) the DU 106 (e.g., vDU). At step S600, a helm upgrade vDU (automatic) is determined. At step S602, NN 16a may read runtime vDU version(s), including radio software version(s). At step S604, NN 16a (e.g., RSUJC) may read RUs which may include hardware identifiers and/or running software. At step S606, a request is made from network node (NN) 16a (e.g., RSUJC) to NN 16b (e.g., RSUJE) is made. The request may be a request to perform an upgrade job for one or more RUs. At step S608, NN 16b may fetch a software package, e.g., a software package corresponding to the request. At step S610, NN 16b may trigger at least one NN 16d (e.g., one or more RUs) to perform a software upgrade. In some embodiments, the RSUJE 102 is deployed together with the DU 106 (e.g., vDU) and the RSUJC 100.

In some embodiments, automatic trigger of the O-LLS radio software upgrade may be performed together with an O-DU software upgrade and with automatic selection of the recommended/tested O-RU software version using the RSUJC 100 and RSUJE 102. The RSUJC 100 may be deployed together (i.e., as part of) the O- 31

DU. A helm upgrade vDU (automatic) may be determined. NN 16a may read runtime vDU version(s), including radio software version(s) and read RUs which may include hardware identifiers and/or running software. A request may be made from network node (NN) 16a (e.g., RSUJC) to NN 16b (e.g., RSUJE). The request may be a request to perform an upgrade job for one or more RUs. NN 16b may fetch a software package, e.g., a software package corresponding to the request and trigger at least one NN 16d (e.g., one or more RUs) to perform a software upgrade. An FTP server may perform an O-RU LMC download. In some embodiments, the RSUJE 102 is deployed together with the DU 106 (e.g., O-DU) and the RSUJC 100.

In some embodiments, at least a software version (e.g., an RU software version) may be passed to an RSUJC 100 (e.g., transmitted to the RSUJC 100 such as to be configured) using another configuration map 300 (e.g., a separate vDU configuration map).

In some other embodiments, a template directory may be used. The template directory may be where a configuration map 300 may be created, e.g., a vdu-ru-sw- info-configmap.yaml. In a nonlimiting example the configuration map 300 may include (e.g., be defined as): apiVersion: vl kind: ConfigMap metadata: name: eric-ran-radio-sw-controller labels: app.kubernetes.io/instance: { { .Release. Name } } annotations: data: radio_software_l : RADIO-74.1 ,206-CXF2010002_l-R74A206

In another nonlimiting example, the configuration map 300 may include (e.g., be defined as): apiVersion: vl kind: ConfigMap metadata: name: eric-ran-radio-sw-controller labels: app.kubernetes.io/instance: { { .Release. Name } } annotations: data: radio_software: | aas: RADIO-74.1.206-CXF2010002_l-R74A206

FIG. 17 shows an example process for upgrading DUs 106 (e.g., vDUs) and RUs 110 (e.g., E-RUs). A first network node 16a comprises RSUJC 100 and a configuration map volume 302 (e.g., ConfigMap Volume). In addition, configuration map 300 is mounted. More specifically, at step S700, a helm upgrade vDU (automatic) is determined. At step S702, a helm installation is performed. At step S704 the configuration map 300 is mounted, and at step S706, NN 16 may read information about RUs including hardware identifiers and running software. At step S708, NN 16a may request upgrade job(s) for target RUs. At step S710, NN 16b may obtain software packages from server 202. At step S712, NN 16b may load RU LMC and/or activate RU LMC. In some embodiments, the RSUJE 102 is deployed together with (i.e., as part of) the DU 106 (e.g., vDU).

FIG. 18 shows an example process for upgrading O-DU and O-RUs. A first network node 16a comprises RSUJC 100 and a configuration map volume 302 (e.g., ConfigMap Volume). In addition, a configuration map 300 (e.g., vDU/O-DU ConfigMap) is mounted. More specifically, at step S800, a helm upgrade vDU (automatic) is determined. At step S802, a helm installation is performed. At step S804 the configuration map 300 is mounted, and at step S806, NN 16 may read information about RUs including hardware identifiers and running software. At step S8O8, NN 16a may request upgrade job(s) for target RUs. At step S810, NN 16b may obtain software packages from server 202. At step S812, NN 16b may download, install, and activate O-RU LMC and reset O-RU. At step S814, server 208 may perform an O-RU LMC download to one or more of NN 16d such as triggered by NN 16b. In some embodiments, the RSUJE is deployed together with (i.e., as part of) the O-DU. In some other embodiments, the first network node 16 (e.g., RSUJC) is deployed together with (i.e., as part of) a DU (e.g., vDU, O-DU). The RSUJE may be deployed together with the vDU and RSUJC. In some embodiments, The RSUJE may be deployed together with the O-DU and RSUJC. FIG. 19 shows another example process. At step S900, orchestrator 200 (e.g., comprised in a network node 16) is configured to perform a vDU helm upgrade with an integrated RSUJC (e.g., radio software controller (RSC)) enabled and automatic software selection enabled. Step S200 may be performed in conjunction with server 212 (e.g., k8s API server). At step S902, NN 16a may mount configuration map 300 (e.g., vDU ConfigMap), and at step S904, NN 16a may request an upgrade job for RUs 110 (e.g., comprised in one or more NNs 16d). NN 16b, at step S906, may obtain RU software packages from server 202, and at step S908, load RU LMC and activate RU LMC. At step S910, NN 16b may confirm that RU LMC is running.

The following is a nonlimiting list of example embodiments:

Embodiment AL A first network node configured to communicate at least with a second network node and a third network node, the first network node configured to, and/or comprising a radio interface and/or a communication interface and/or comprising processing circuitry configured to: determine a software version associated with a software upgrade of a fourth network node based on a configuration, the configuration indicating whether at least one of: to accept a software version indicated in the configuration, the software version being associated with a software upgrade of a fourth network node; and to automatically select the software version.

Embodiment A2. The first network node of Embodiment Al, wherein the processing circuitry is further configured to at least one of: query a software inventory of the third network node to automatically select the software version; and automatically select the software version.

Embodiment A3. The first network node of Embodiment A2, wherein the processing circuitry is further configured to: determine that the software inventory is configured with a plurality of software versions; query the second network node based on the determination that the software inventory is configured with the plurality of software versions; and determine a software version currently running on the fourth network node based on the query of the second network node.

Embodiment A4. The first network node of any one of Embodiments Al- A3, wherein the processing circuitry is further configured to: request the second network node to perform the software upgrade of the fourth network node using the determined software version.

Embodiment A5. The first network node of any one of Embodiments Al- A4, wherein at least the first network node, the second network node, and the third network node are deployed as part of a same distributed unit.

Embodiment A6. The first network node of any one of Embodiments Al- A5, wherein the software version indicates a software product and the software version.

Embodiment A7. The first network node of any one of Embodiments Al- A6, wherein the first network node comprises a radio software upgrade job controller, the second network node comprises a radio software upgrade job engine, the third network node comprises a distributed unit configuration management service, and the fourth network node comprises a radio unit configurable to be upgraded with the software upgrade.

Embodiment Bl. A method in a first network node configured to communicate at least with a second network node and a third network node, the method comprising: determining a software version associated with a software upgrade of a fourth network node based on a configuration, the configuration indicating whether at least one of: to accept a software version indicated in the configuration, the software version being associated with a software upgrade of a fourth network node; and to automatically select the software version.

Embodiment B2. The method of Embodiment B l, wherein the method further includes at least one of: querying a software inventory of the third network node to automatically select the software version; and automatically selecting the software version. Embodiment B3. The method of Embodiment B2, wherein the method further includes: determining that the software inventory is configured with a plurality of software versions; querying the second network node based on the determination that the software inventory is configured with the plurality of software versions; and determining a software version currently running on the fourth network node based on the query of the second network node.

Embodiment B4. The method of any one of Embodiments B 1-B3, wherein the method further includes: requesting the second network node to perform the software upgrade of the fourth network node using the determined software version.

Embodiment B5. The method of any one of Embodiments B 1-B4, wherein at least the first network node, the second network node, and the third network node are deployed as part of the same distributed unit.

Embodiment B6. The method of any one of Embodiments B 1-B5, wherein the software version indicates a software product and the software version.

Embodiment B7. The method of any one of Embodiments B 1-B6, wherein the first network node comprises a radio software upgrade job controller, the second network node comprises a radio software upgrade job engine, the third network node comprises a distributed unit configuration management service, and the fourth network node comprises a radio unit configurable to be upgraded with the software upgrade.

Embodiment Cl. A second network node configured to communicate at least with a first network node and a fourth network node, the first network node being configured to communicate with a third network node, the second network node configured to, and/or comprising a radio interface and/or a communication interface and/or comprising processing circuitry configured to: receive a request from the first network node to perform a software upgrade of the fourth network node using a software version, the software version being based on a configuration of the first network node.

Embodiment C2. The second network node of Embodiment Cl, wherein the processing circuitry is further configured to: receive a query from the first network node to determine a software version currently running on the fourth network node.

Embodiment C3. The second network node of any one of Embodiments Cl and C2, wherein the processing circuitry is further configured to: fetch a software package based on the received request; and cause the fourth network node to perform the software upgrade of the fourth network node using the software version.

Embodiment C4. The second network node of any one of Embodiments C1-C3, wherein the software version indicates a software product and the software version.

Embodiment C5. The second network node of any one of Embodiments C1-C4, wherein the first network node comprises a radio software upgrade job controller, the second network node comprises a radio software upgrade job engine, the third network node comprises a distributed unit configuration management service, and the fourth network node comprises a radio unit configurable to be upgraded with the software upgrade.

Embodiment DI. A method in a second network node configured to communicate at least with a first network node and a fourth network node, the first network node being configured to communicate with a third network node, the method comprising: receiving a request from the first network node to perform a software upgrade of the fourth network node using a software version, the software version being based on a configuration of the first network node.

Embodiment D2. The method of Embodiment DI, wherein the method further includes: receiving a query from the first network node to determine a software version currently running on the fourth network node.

Embodiment D3. The method of any one of Embodiments DI and D2, wherein the method further includes: fetching a software package based on the received request; and causing the fourth network node to perform the software upgrade of the fourth network node using the software version. Embodiment D4. The method of any one of Embodiments D1-D3, wherein the software version indicates a software product and the software version.

Embodiment D5. The method of any one of Embodiments D1-D4, wherein the first network node comprises a radio software upgrade job controller, the second network node comprises a radio software upgrade job engine, the third network node comprises a distributed unit configuration management service, and the fourth network node comprises a radio unit configurable to be upgraded with the software upgrade.

Embodiment El. A third network node configured to communicate at least with a first network node, the first network node being configured to communicate with a second network node that is configured to communicate with a fourth network node, the third network node configured to, and/or comprising a radio interface and/or a communication interface and/or comprising processing circuitry configured to: determine a software inventory, the software inventory including a configuration map obtained from a server and being usable to determine a software version associated with a software upgrade of the fourth network node.

Embodiment E2. The third network node of Embodiment El, wherein the processing circuitry is configured to cause the third network node to: receive a query of the software inventory from the first network node; and transmit at least one software version to the first network node for the first network node to determine the software version associated with the software upgrade of the fourth network node, the software upgrade of the fourth network node being triggered by the second network node.

Embodiment E3. The third network node of Embodiments El and E2, wherein the software inventory is obtained from the server via a software inventory manager, the software inventory manager reading the configuration map from the server and providing software metadata to the third network node.

Embodiment E4. The third network node of Embodiment E3, wherein the software metadata is included in a chart.

Embodiment E5. The third network node of any one of Embodiments El- E4, wherein the software version indicates a software product and the software version. Embodiment E6. The third network node of any one of Embodiments El- E5, wherein the first network node comprises a radio software upgrade job controller, the second network node comprises a radio software upgrade job engine, the third network node comprises a distributed unit configuration management service, and the fourth network node comprises a radio unit configurable to be upgraded with the software upgrade.

Embodiment Fl. A method in a third network node configured to communicate at least with a first network node, the first network node being configured to communicate with a second network node that is configured to communicate with a fourth network node, the method comprising: determining a software inventory, the software inventory including a configuration map obtained from a server and being usable to determine a software version associated with a software upgrade of the fourth network node.

Embodiment F2. The method of Embodiment Fl, wherein the method further includes: receiving a query of the software inventory from the first network node; and transmitting at least one software version to the first network node for the first network node to determine the software version associated with the software upgrade of the fourth network node, the software upgrade of the fourth network node being triggered by the second network node.

Embodiment F3. The method of Embodiments Fl and F2, wherein the software inventory is obtained from the server via a software inventory manager, the software inventory manager reading the configuration map from the server and providing software metadata to the third network node.

Embodiment F4. The method of Embodiment F3, wherein the software metadata is included in a chart.

Embodiment F5. The method of any one of Embodiments F1-F4, wherein the software version indicates a software product and the software version.

Embodiment F6. The method of any one of Embodiments F1-F5, wherein the first network node comprises a radio software upgrade job controller, the second network node comprises a radio software upgrade job engine, the third network node comprises a distributed unit configuration management service, and the fourth network node comprises a radio unit configurable to be upgraded with the software upgrade.

As will be appreciated by one of skill in the art, the concepts described herein may be embodied as a method, data processing system, computer program product and/or computer storage media storing an executable computer program. Accordingly, the concepts described herein may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects all generally referred to herein as a “circuit” or “module.” Any process, step, action and/or functionality described herein may be performed by, and/or associated to, a corresponding module, which may be implemented in software and/or firmware and/or hardware. Furthermore, the disclosure may take the form of a computer program product on a tangible computer usable storage medium having computer program code embodied in the medium that can be executed by a computer. Any suitable tangible computer readable medium may be utilized including hard disks, CD-ROMs, electronic storage devices, optical storage devices, or magnetic storage devices.

Some embodiments are described herein with reference to flowchart illustrations and/or block diagrams of methods, systems and computer program products. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer (to thereby create a special 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 program instructions may also be stored in a computer readable memory or storage medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

It is to be understood that the functions/acts noted in the blocks may occur out of the order noted in the operational illustrations. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

Computer program code for carrying out operations of the concepts described herein may be written in an object oriented programming language such as Python, Java® or C++. However, the computer program code for carrying out operations of the disclosure may also be written in conventional procedural programming languages, such as the "C" programming language. The program code 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. In the latter scenario, the remote computer may be connected to the user's computer through 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).

Many different embodiments have been disclosed herein, in connection with the above description and the drawings. It will be understood that it would be unduly repetitious and obfuscating to literally describe and illustrate every combination and subcombination of these embodiments. Accordingly, all embodiments can be combined in any way and/or combination, and the present specification, including the drawings, shall be construed to constitute a complete written description of all combinations and subcombinations of the embodiments described herein, and of the manner and process of making and using them, and shall support claims to any such combination or subcombination. Abbreviations that may be used in the preceding description include: k8s kubemetes

LCM Lifecycle Management

VNF Virtual Node Function

CNF Containerized Node Function cVNF Containerized Virtual Node Function app application

VNFMVNF Manager

NFVO NFV Orchestrator

ONAP Open Network Automation Platform

RU Radio Unit

E-RU eLLS Radio Unit

O-RUO-LLS Radio Unit

CSAR Cloud Service Archive

SW Software

LMC Load Module Container

SMO Service Management and Orchestration

O-RAN Open Radio Access Network

RAN Radio Access Network

RSC Radio SW Controller eLLS Ericsson Lower Layer Split

API Application Programming Interface

REST RESTful

EM Element Manager

IT Information Technology

TCP Transmission Control Protocol

FTP File Transfer Protocol

FTPes Explicit FTP over TLS

TLS Transport Layer Security

It will be appreciated by persons skilled in the art that the embodiments described herein are not limited to what has been particularly shown and described herein above. In addition, unless mention was made above to the contrary, it should be noted that all of the accompanying drawings are not to scale. A variety of modifications and variations are possible in light of the above teachings without departing from the scope of the following claims.