In implementations, the deployment, scaling, and management of such virtualized components can be managed by an orchestrator (such as Kubernetes) in the 5G core 208. The orchestrator can trigger various software processes executed by underlying computer hardware. In implementations, the one or more management functions (managing the 5G core 208, and/or the example system architecture 200 in general) can be implemented in the 5G core 208, for example through a M-Plane. The M-Plane can be configured to facilitate monitoring of O-RAN and determining the amount and location at which cellular network functions should be deployed to meet or attempt to meet service level agreements (SLAs) across slices of the cellular network.

In various implementations, the orchestrator can allow for the instantiation of new cloud-based components of the example system architecture 200 of the 5G O-RAN. As an example, to instantiate a new DU, the orchestrator can perform a pipeline of calling the DU code from a software repository incorporated as part of, or separate from, cellular network 120; pulling corresponding configuration files (e.g., helm charts); creating Kubernetes nodes/pods; loading DU containers; configuring the DU; and activating other support functions (e.g., Prometheus, instances/connections to test tools).

In some implementations, a network slice functions as a virtual network operating on example system architecture 200 of the 5G O-RAN. In those implementations, example system architecture 200 of the 5G O-RAN is shared with some number of other network slices, such as hundreds or thousands of network slices. Communication bandwidth and computing resources of the underlying physical network can be reserved for individual network slices, thus allowing the individual network slices to reliably meet particular SLA levels and parameters. By controlling the location and amount of computing and communication resources allocated to a network slice, the SLA attributes for UE on the network slice can be varied on different slices. A network slice can be configured to provide sufficient resources for a particular application to be properly executed and delivered (e.g., gaming services, video services, voice services, location services, sensor reporting services, data services, etc.). However, resources are not infinite, so allocation of an excess of resources to a particular UE group and/or application may be desired to be avoided. Further, a cost may be attached to cellular slices: the greater the amount of resources dedicated, the greater the cost to the user; thus optimization between performance and cost is desirable.

Particular network slices may only be reserved in particular geographic regions. For instance, a first set of network slices may be present at a given RU and a given DU, a second set of network slices, which may only partially overlap or may be wholly different than the first set, may be reserved at the given RU and the given DU.

Further, particular cellular network slices may include some number of defined layers. Each layer within a network slice may be used to define QoS parameters and other network configurations for particular types of data. For instance, high-priority data sent by a UE may be mapped to a layer having relatively higher QoS parameters and network configurations than lower-priority data sent by the UE that is mapped to a second layer having relatively less stringent QoS parameters and different network configurations.

In some embodiments, the 5G core 208 implements a O-RAN ZTP (zero touch provisioning) layer. In general, in those embodiments, the O-RAN ZTP layer is configured to facilitate automation of the deployment workflow within the example system architecture 200 of the 5G O-RAN. ZTP is commonly known as automated deployment of software (new or updates) to various components in a system with as little human intervention as possible. In the context of example system architecture 200 of the 5G O-RAN, ZTP means automated deployment of software (new or updates) to hardware and/or software components such as RUs, CSRs, DUs, CUs, and various modules in the 5G core 208 with little human intervention. For example without an engineer having to be present at a specific cell site such as 202a or 202b, O-RAN ZTP can facilitate automatic update of a DU with the latest DU software. It should be understood the O-RAN ZTP layer is referred to a set of components that work together to facilitate automatic deployment of software in the example system architecture 200 of the 5G O-RAN with little human intervention. Thus, although, the O-RAN ZTP layer is shown being implemented in the 5G core 208 in FIG. 2, it is merely illustrative. That is, the O-RAN ZTP in accordance with the present disclosure is not intended to be limited to components implemented a core of the O-RAN in accordance with the present disclosure. In some other examples, one or more components of the O-RAN ZTP can be implemented in, for example, CUs or DUs in the O-RAN in accordance with the present disclosure. For instance, as will be described below, adaptors configured to communicate with devices or components of different vendors for ZTP operations can be implemented in CUs or DUs.

Also shown in FIG. 2 is a NOC 210 (Network Operation Center). In some embodiments, the NOC 210 is implemented on a general-purpose computing device. In those embodiments, one or more interfaces are implemented in the NOC 210. In those embodiments, the interfaces represent virtual dashboards that can facilitate automatic deployment of software to various components in the example system architecture 200 of the 5G O-RAN. For instance, an interface is provided in the NOC 210 to enable an operator to set a schedule to update one or more network services in the 5G core 208. As another illustration, an interface is provided in the NOC 210 to enable the operator to push software to a specific component in a cell site (such as 202a or 202b) or in a data center (such as 204) to configure or update the component. One or more requests can be generated by the NOC 210 to instigate the deployment of the software as scheduled or intended by the operator. The request(s) can be received by the O-RAN ZTP layer, which in turn can generate one or more commands to deploy the software to the component. Although one NOC 210 is shown in this example, this is not intended to be limiting. More than one NOCs are typically deployed in the example system architecture 200 of the 5G O-RAN. In some implementations, a given NOC may be provided by a vendor to the 5G O-RAN. For instance, the vendor may be a software develop that provides components or services to the example system architecture 200 of a 5G O-RAN. In that instance, the given NOC is a computing device or system on a premise of the software developer.

Components such as DUs, CUs, the orchestrator, O-RAN ZTP layer, interfaces in the NOC 210, and/or any other components in the 5G core 208 may include various software components communicating with each other, handling large volumes of data traffic, and be able to properly respond to changes in the network. In order to ensure not only the functionality and interoperability of such components, but also the ability to respond to changing network conditions and the ability to meet or perform above vendor specifications, significant testing must be performed.

The methods, systems, and devices discussed above are examples. Various configurations may omit, substitute, or add various procedures or components as appropriate. For instance, in alternative configurations, the methods may be performed in an order different from that described, and/or various stages may be added, omitted, and/or combined. Also, features described with respect to certain configurations may be combined in various other configurations. Different aspects and elements of the configurations may be combined in a similar manner. Also, technology evolves and, thus, many of the elements are examples and do not limit the scope of the disclosure or claims.

Specific details are given in the description to provide a thorough understanding of example configurations (including implementations). However, configurations may be practiced without these specific details. For example, well-known circuits, processes, algorithms, structures, and techniques have been shown without unnecessary detail in order to avoid obscuring the configurations. This description provides example configurations only, and does not limit the scope, applicability, or configurations of the claims. Rather, the preceding description of the configurations will provide those skilled in the art with an enabling description for implementing described techniques. Various changes may be made in the function and arrangement of elements without departing from the spirit or scope of the disclosure.

Also, configurations may be described as a process which is depicted as a flow diagram or block diagram. Although each may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be rearranged. A process may have additional steps not included in the figure. Furthermore, examples of the methods may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments to perform the necessary tasks may be stored in a non-transitory computer-readable medium such as a storage medium. Processors may perform the described tasks.

FIG. 3A illustrates an example process 300 for setting up, provisioning, and operating a O-RAN such as the example system architecture 200 of the 5G O-RAN shown in FIG. 2. In the process 300, O-RAN ZTP technologies are employed to facilitate each step in the process 300. The example process 300 is shown to help understand how the O-RAN ZTP technologies in accordance with the present disclosure helps running of an O-RAN in accordance with the present disclosure. It should be understood the steps shown in FIG. 3A, while sequential, is not intended to be limited to the specific sequence shown in FIG. 3A. In some other examples, relevant sequences for the process 300 may be different from that shown in FIG. 3A.

As the name ZTP (Zero Touch Provisioning) suggests, a goal of using various ZTP technologies in an O-RAN is to 1) install/update network hardware components (such as RUs) in cell sites, 2) install/update network functionality components (such as DUs, CUs, orchestrator, and/or any other networking components in the O-RAN) in data centers, and/or any other operations without someone needing to configure those components locally where they are located. For example, a new or replacement device can be sent to a cell site, physically installed and powered up by a locally present employee, who is not required to have IT skills. This is when the ZTP technologies can come in, to automatically carry out the software installation, updates, the configuration of the device, and connect the device to the O-RAN.

Attention is now directed to FIG. 3A. In the example process 300 for setting up, provisioning, and operating an O-RAN in accordance with the present disclosure, at electronic processor 302, a network environment is typically set up. At 302, operations such as setting up various network function components (for example, those mentioned above) in one or more data centers is performed to facilitate the operation of the O-RAN. For example, this may involve implementing network function components according to one or more design specifications for the O-RAN, pre-CSR integration of the various network function components, emulating DUs for the O-RAN for setting up the network environment using the various network function components, implementing one or more transport tools, and/or any other operations. During this stage, a ZTP layer can be implemented, for example such as the O-RAN ZTP layer shown in FIG. 2.

At 304, a cell site can be set up in the network environment set up at 302. For example, in the 5G context shown in FIG. 2, this may involve installing one or more RUs in the cell site, laying cables in the cell site, configurating one or more CSRs for the cell sites, making connections from the RUs to the CSRs, making connections from the cell site to a core network in the network environment, making connections between the cell site and any other cell sites, and/or any other operations. During this stage, functions or services can be automatically provisioned or commissioned on various components. For instance, after an RU device is installed in the cell site (such as cell site 202a or 202b shown in FIG. 2) and powered up for the first time, a communication address can be automatically assigned to the RU device. Then, the O-RAN ZTP layer can automatically configure the RU device through the communication address assigned to the RU device. As another example, a CSR implemented in the cell site can be automatically integrated into the network environment according to a network specification configured with the O-RAN ZTP layer after the CSR is ready to function in the network environment.

At 306, continuous integration and continuous deployment (CI/CD) of various network function components are carried out in the network environment set up at 302. CI/CD is a set of practices that enable how software, in this case, O-RAN software, is installed and updated. CI or Continuous Integration is the practice of merging all developers working code to a shared mainline several times at a frequency. Every merge is typically validated before merging to uncover any issues. CD or Continuous Delivery/Deployment is the practice in which software developers produce reliable software in short cycles that can be released (delivered) at any time, which can then be deployed at a frequency. As a result, any software can be released much faster, more frequently and reliably into O-RAN. The benefit of CD is more predictable deployments that can happen on demand without waiting for an “official” upgrade cycle—this is now thing of the past.

Examples of CI/CD at 306 can include infrastructure deployment or update including the following components: networking stack, computing stack, storage stack, monitoring stack, security stack, core network functions. In some embodiments, the CI/CD at 306 can include CNF deployment and update. For instance, a CNF is deployed onto one or more CUs using control tools. In some embodiments, the CI/CD at 306 can include deploying a specific application or tool for a specific CNF. In some embodiments, changes to various network function components are deployed in the network environment continuously. In implementations, a ZTP pipeline is used to facilitate the aforementioned CI/CD operations. In one implementation, the ZTP pipeline is deployed within the O-RAN ZTP layer shown in FIG. 2. In that implementation, the ZTP pipeline defines various stages through which software code is retrieved from a source code repository, is built into corresponding artifacts (e.g., micro-services, network functions), is tested using predefine tests, and is deployed in the network environment after successful results of the testing.

At 308, a cell site is updated, for example, with latest software or configuration. This may be triggered at a preset frequency configured at the ZTP layer in the network environment. For instance, a cadence such as every week may be set to update software deployed on the components in the cell site, such as RUs, DUs, CSRs, and/or any other components. However, this is not necessarily the only case. Operations at 308 can also involve configuring or provisioning devices or components newly installed in the cell site—e.g., replacement or new devices. Similar to operations at 304, in such situations, software can be pushed to the newly installed devices or components by the ZTP layer once they are live in the network environment.

In implementations, operations involved in 304 may be referred to as “day 0” operations. Operations involved in 302 may be referred to as “day 1” operations. Operations involved in 306 may be referred to as “day 2” operations. Operations involved in 308 may be referred to as “day 3” operations. The numerical references in these operations do not necessarily indicate that these operations have to happen in a time sequence. As shown in FIG. 3A, operations in the example process 300 can happen in any sequence. For example, after a day “0” operation in 304 happens, the process 300 can proceed to 302 to push a specific configuration that involves components in the “day 0” operation to a core network (such as the 5G core 208 shown in FIG. 2), and then proceed to 308 to update another cell site (e.g., to configure that cell site to be connected to the cell site set up in the day 0 operation). Other scenarios are contemplated.

FIG. 3B illustrates another example process 350 showing an example of how ZTP and CI/CD are facilitated in an O-RAN in accordance with the present disclosure. Process 350 illustrates the ZTP and CI/CD in the O-RAN in accordance with the present disclosure from a perspective of O-RAN operation cycles.

At 352, an activity or operation at a cell site triggers an automation in the ZTP layer of the O-RAN. For example, this may involve a replacement of a RU device in the cell site is brought online by a personnel present at the cell site. Once the RU device is online, the RU device may generate a request for software update, e.g. security patch, and configuration of the RU device, and such a request may be received by the ZTP layer in the O-RAN. In some embodiments, the ZTP layer may be configured to monitor activities across cell sites in the network environment and the automation is triggered by the ZTP layer once the replacement RU device is detected to be online.

At 354, lower level network (e.g., radio network or RAN) CI/CD can be carried out. In some situations, the operations in 354 are triggered by one or more activities at 352. For example, as illustration, after the replacement RU device is brought online and configured by the ZTP layer in the O-RAN, one or more components in a CSR, DU and/or CU is to be configured to record the replacement RU device. In that example, the ZTP layer in the O-RAN can trigger such a configuration so the lower level network is updated to incorporate the replacement RU into the O-RAN. In some situations, the lower level network CI/CD at 354 is independent of the activities at cell sites. For instance, the software developers for particular types of CSR, DU or CU can set a CI/CD pipeline and schedule deployment of their latest software on the CSR, DU or CU at a preset frequency (e.g., nightly or weekly).

At 356, network service CI/CD is performed. In some situations, the CI/CD operations in 356 are triggered by one or more operations or changes in at 354. For example, as illustration, after software is deployed at the lower network level at 354, one or more network services are updated based on the deployment of the software. For instance, without limitation, in the context of 5G, various 5G network services can be updated after the underlying RAN in the 5G O-RAN are updated. In some situations, the CI/CD operations in 356 are independent of operations or changes at 354. For example, software developers of the core network services for the 5G O-RAN can set up a schedule to release their software to update the core network services on a regular basis.

At 358, operations control the ZTP in the O-RAN are performed. Examples of these operations can include scheduling release of software to update O-RAN components, instantiating a DU or CU, provisioning an RU or CSR in a cell site, and/or any other operations. In some examples, the operations at 358 are performed on an NOC such as the NOC 210 shown in FIG. 2. It should be understood although process 350 is illustrated so far from 352 to 358 in sequence, this is not intended to limit the O-RAN ZTP technologies in accordance with the present disclosure to a bottom up or top-down approach. In a top-down approach, ZTP is instigated, for example, at 358 and software is pushed to the core network, lower network level, and/or cell sites through the ZTP layer in the O-RAN. In a bottom-up approach, ZTP request is generated, for example, by a component at a cell site or data center, and software is pushed to that component through the ZTP layer in the O-RAN. In various embodiments, a ZTP request is configured for instigating one or more ZTP operations in the O-RAN. In some situations, ZTP can be carried out by a third-party vendor to update its components in the O-RAN in a mixture of bottom-up and top-down approach. For instance, the third-party vendor may ship a router device to a cell site, which is installed by a technician on the cell site. Once the router device is live, it generates its status information to a management server of the third-party vendor for configuration of the router. In that example, the third-party vendor dynamically configures the router according to specifications or requirements of the O-RAN where the router is installed. In this way, a mixture of bottom-up and top-down ZTP is used to configure the router.

With example processes of how ZTP technologies can be used in an O-RAN in accordance with the present disclosure having been generally described and illustrated in FIGS. 3A-B, attention is now directed to FIG. 4, where an example O-RAN ZTP layer 400 is shown. As mentioned above, some or all of the O-RAN ZTP layer 400 can be implemented in a core of the O-RAN in accordance with the present disclosure, such as the 5G core 208 shown in FIG. 2. However, this is not the only case. In some embodiments, some or all of the O-RAN ZTP layer 400 can be implemented in one or more data centers, which also host CUs and/or DUs.

As shown, in this example, the O-RAN ZTP layer 400 includes a reference data system 402, a ZTP orchestrator 404, a ZTP control console 406, vendor ZTP adaptors 408, O-RAN ZTP adaptor 410, and/or any other components. In various implementations, the O-RAN ZTP layer 400 can achieve various functions and objectives described in connection with and illustrated in FIG. 3A and FIG. 3B.

In this example, the reference data system 402 is configured to receive and/or obtain data from one or more data sources, validate the data, establish one or more reference data models for the O-RAN, manage the reference data including the reference data models, and/or any other operations. One insight in accordance with the present disclosure is that reference data may be used to adjust/adapt ZTP operations in an O-RAN in accordance with the present disclosure. In general, an O-RAN can have data such as network specifications, design blueprints, and data provided by vendor(s)/operator(s)/developer(s) such as specifications of hardware components and/or software components installed in the O-RAN to facilitate operations of the O-RAN. Such data may be referred to as design data, or priori-provided data, which is typically used and/or recorded at 302 or 304 shown in FIG. 3. This design data can be used as reference data to drive ZTP operations in the O-RAN, such as those described and illustrated in FIGS. 3A-3B. For example, as illustration, without limitation, design data regarding network topology (network topology data) in the O-RAN can be stored in a database and used to facilitate ZTP operations that push software updates to various components as indicated by the network topology data.

However, another insight data in accordance with the present disclosure is that sole reliance on design data mentioned above for facilitating ZTP operations is not robust at least because mistakes/errors can typically happen during implementations of the O-RAN. For instance, when setting up a cell site (such as 202a or 202b shown in FIG. 2), mistakes such as wrong wiring or wrong components can be introduced to the cell site. Such mistakes can cause inconsistencies between the design data and the actual implementation of the O-RAN. In the instance described above, the design data can indicate a component is installed in the cell site while that component is not actually installed in the cell site. As can be seen, sole reliance on the design data to facilitate ZTP operations would not be adequate and can lead to failures of the ZTP operations, such as those described and illustrated in FIGS. 3A-3B. The robustness and reliability of the ZTP operations in the sole reliance of design data model would then depend on qualities of the implementations of the O-RAN. In principle, an automatic system, such as the O-RAN ZTP, may not have a likelihood of failures without an ability to adjust/adapt itself in anticipation of inconsistences between design data and actual implementation of the O-RAN.

Still another insight in accordance with the present disclosure is that data regarding actual implementation of the O-RAN can be captured and stored during, for example, 302 or 304 shown in FIG. 3A. For instance, during setting up a cell site, field technician can be equipped with tools, such as a scanner or a smartphone, to capture information indicating actual wiring and/or connections between components set up in the cell site, actual components installed in the cell site and/or any other type of information. Such data may be referred to as implementation data, which can be stored and compared with design data. Validation intelligence can then be configured into the O-RAN ZTP layer 400 to adjust/adapt itself. For instance, if component 1 is installed in a slot indicated as component 2 in the design data, and component 1 and component 2 are of the same model (e.g., a physical server provided a same vendor), the actual reference data for the ZTP operations used by the O-RAN ZTP layer 400 can be adjusted to show component 1 is now component 2 and configure it accordingly (for example installing a version of DU on t server designated as component 2) instead of still treating it as component 1. In this fashion, inconsistencies between design data and implementation data are resolved. Another example is that inconsistency found between design and implementation data for a particular component can be reported for human attention and ZTP operations are instigated on that component only after the inconsistency is resolved.

In considerations of the various insights mentioned above, in some implementations, O-RAN ZTP layer 400 is facilitated through network/cell site modeling based on data from various data sources. For example, knowledge of how cell sites in the O-RAN are actually constructed, and actual inventory in the cell sites can be obtained to establish data models about the cell sites. Using such knowledge, the O-RAN ZTP layer 400 can deploy software to components as constructed in the cell sites. For instance, vendor information model numbers, OS versions, specific connections made to a CSR, and/or any other information about an RU can be obtained during construction of a cell site and stored in the reference data system 402. As another example, network topology of the O-RAN can be updated as cell sites come and go in the O-RAN throughout a life cycle of the O-RAN. In that example, the updated network topology can be stored in the reference data system 402.

FIG. 5 illustrates an example of various data sources that provide reference data regarding the O-RAN in accordance with one embodiment. In various embodiments, one or more data sources shown in FIG. 5 can be part of the O-RAN ZTP layer 400. In some embodiments, one or more data sources shown in FIG. 5 can be provided one or more vendors of the O-RAN. In those embodiments, these data sources communicate with the reference data system 402 through interfaces between systems of the vendors.

As shown in this example, one type of data source (e.g. implementation data) is construction inventory 502 shown in FIG. 5. As mentioned, during construction of cell sites, inventory information regarding the cell sites can be obtained and stored in the construction inventory 502. For example, as illustration, during construction of a cell site, components information regarding components actually installed in the cell site can be captured by a management or workflow system. For instance, as a field engineer completes installation of a particular component in the cell site, the field engineer typically records installation information for the component—for example, where it is located in the cell site, one or more connections made for the component, information regarding testing performed on the component, model information, vendor information, OS information, and/or any other component information. It should be understood that the installation information regarding the component can be different from inventory information indicating the component, for example, provided by a vendor of the component. For instance, devices actually installed in the cell site can be different from inventory/planning for the cell site. For instance, field engineers may install a different model of a device in the cell site than what is planned for the cell site. An insight provided by the present disclosure is that reference data used to facilitate O-RAN ZTP in accordance with the present disclosure cannot just rely on inventory information provided by operator(s) and/or vendor(s) of the O-RAN. Mistakes and/or inconsistencies often take place during construction of a cell site. As mentioned above, for instance, a wrong model of a device may be installed in the cell site. Thus, actual construction inventory—information regarding components actually installed in the cell site—is also obtained and stored for the O-RAN ZTP layer 400.

In some embodiments, the construction inventory 502 is implemented using a repository management system. Information regarding an actual built-out of a cell site is captured and managed by the repository management system. In those embodiments, one or more workflow procedures are performed by the field engineers when setting up a cell site, for example, in step 304 shown in FIG. 3B. For instance, according to the procedure(s), the field engineers input various installation information using their smartphones or dedicated devices. For illustration, the field engineers using their smartphones to capture an image of the backside of an installed router to show cables connected to which ports on the router. This image is then transmitted, by the smartphones, to the repository management system, which is configured to extract connection information from the image and store the connection information. As another illustration, the field engineers input data in fields for installation information regarding the installed router in an app of their smartphones. The app may be provided by a developer of the repository management system. The data input by the field engineers includes connection information regarding the installed router. The data is transmitted by the smartphones to the repository management system, which then stores the data. In one embodiment, without limitation, the construction inventory 502 is implemented using a NexSysOne (NX1) management system.

Another type of data source for the reference data system 402 is data for O-RAN design and planning (e.g., a type of design data), which is generally and collectively referred to as O-RAN design and planning data 504. Examples of O-RAN design and planning data 504 can include network planning data 5042, PaaS (Platform as a Service) planning data 5044, RAN engineering data 5046, and/or any other types of data. In some embodiments, the network planning data 5042 can include data for planning various regions, markets, data centers, and/or any other sections or entities in the O-RAN. In some embodiments, such data is available in a suite of planning tools used to design the O-RAN. In one implementation, the suite of planning tools are implemented using IP Address Management (IPAM).

In some embodiments, PaaS planning data 5044 include data for mapping data centers and compute stacks such as EKS (Elastic Kubernetes Service) clusters, data centers and storage stacks such as S3 (Simple Storage Service) buckets, EBS (Elastic Block Store) volumes and EFS (Elastic File System), data centers and monitoring stacks such as CloudWatch, data centers and security stacks such as VPC (Virtual Private Cloud) NACLs (Network Access Control List) and EC2 (Agile Scaling and Secure Service) security groups, and/or any other PaaS planning data. In some embodiments, the PaaS planning data 5044 includes data for mapping CU clusters to EKS cluster, TKG master cluster to Software Defined Data Center (SDDC), and/or any other types of PaaS planning data.

In some embodiments, the RAN engineering data 5046 includes data for RF planning including cell sites allocation within the O-RAN. In one implementation, the RF planning data is available in a tool called Planet, which is a RF software planning tool provided by Infovista. In some embodiments, the RAN engineering data 5046 includes data for DU, CU, TKG, EMS cluster mapping. In one implementation, the O-RAN design and planning data 504 is managed by a design specifications database (SDB). The SDB is configured to receive, obtain, store and manage network planning data 5042, PaaS planning data 5044, RAN engineering data 5046, and/or any other design-specific data. In that implementation, without limitation, the SDB is part of the O-RAN ZTP layer 400.

Still another data source for the reference data system 402 is referred to as O-RAN deployment data 506 (e.g., a type of implementation data). As shown, examples of the O-RAN deployment data 506 can include security implementation data 5062, transport circuit implementation data 5064, network implementation data 5066 and/or any other implementation data for RAN deployment. In some embodiments, the security implementation data 5062 can include data captured during or after implementation of secure boot environment for individual hardware devices in the O-RAN (for example, SM-PXE (preboot execution environment)), security modules for DNS, DHCP and Network address management (for example, Infoblox DDI (DNS, DHCP and IP address)), and/or any other securing implementation data for the O-RAN.

The transport circuit implementation data 5064 can include data captured during or after implementations of various sections of the transport layer (such as the transport layer 206 shown in FIG. 2) in the O-RAN. For example, after cables are laid to connect a section of the midhaul in the O-RAN, data can be input by the field engineer(s) to their smartphones, which in turn can transmit the implementation data for that section of the midhaul to a management system. The management system can store and manage such transport circuit implementation data 5064.

The network implementation data 5066 can include various implementation data indicating implementation (typically software) of network services/components/functions in the O-RAN. Examples of such data can include CU/EMS implementation and deployment over one or more hosting EKS clusters, SDDC (software defined data center) deployment in the O-RAN, CI/CD pipeline implementation in the O-RAN, RAN-EMS/EFS configuration, and/or any other network implementation data. In various implementations, the O-RAN deployment data 506 is received, obtained, stored, and/or managed by a repository management system for managing the aforementioned implementation data. In one implementation, such a repository management system is part of the O-RAN ZTP layer 400.

Yet another type of data source for the reference data system 402 is reference data provided by various developers or vendors of the O-RAN. Such data is referred to as developer/vendor reference data. As shown, in some embodiments, one or more developer/vendor adaptors 508 can be provided to facilitate data from a specific developer or vendor. For example, without limitation, one or more adaptors can be provided for Cisco provided components in the O-RAN so that Cisco can provide reference data about those components—for example, data indicating the latest build version, one or more software release notes, one or more bug fix logs, and/or any other relevant information. Typically, in an O-RAN, more than one developer or vendor is involved to develop and/or facilitate the running of the O-RAN. In one implementation, developer/vendor adaptors 508 are provided for various vendors and developers including VMWare, Cisco, Dell, Amazon Cloud Service, Mavenir, Samsung, and/or any other developers and/or vendors.

Attention is now directed back to FIG. 4. The ZTP orchestrator (ZTPO) 404 is configured to facilitate orchestration of one or more ZTP operations in the O-RAN. As used herein, a ZTP operation may be referred to as an operation configured to facilitate one or more operations illustrated and described in association with FIGS. 3A-B. In various embodiments, ZTP orchestrator 404 acts as an engine in the O-RAN ZTP layer to kick off ZTP operations. As shown, the ZTP orchestrator 404 is configured to generate a specific request to the reference data system 402 to obtain reference data. The reference data obtained by the ZTP orchestrator 404 can include one or more CIQs (e.g., build/design specifications) managed by the reference data system 402 based on SDB contents. The reference data obtained by the ZTP orchestrator 404 can include information one or more actual inventory items and/or actual build-out information for a particular cell site managed by the reference data system 402. The reference data obtained by the ZTP orchestrator 404 can include information regarding an updated network topology of the O-RAN managed by the reference data system 402. In various implementations, the ZTP orchestrator 404 can be configured to validate reference data obtained, and determine inconsistencies within the reference data. In those implementations, the ZTP orchestrator 404 is configured to delay the ZTP operations until the inconsistencies are resolved.

In various embodiments, as in shown in this example, The ZTP orchestrator 404 is configured to receive, through a vendor ZTP adaptor 408, a ZTP request from a developer or vendor of the O-RAN to instigate a ZTP operation, for example to release a latest version of software to a component provided by the developer or vendor in the O-RAN. As shown, in those embodiments, the ZTP orchestrator 404 can feedback a status or result of the requested ZTP operation to the developer or vendor via the vendor ZTP adaptor 408.

As shown, the ZTP orchestrator 404 is configured to generate ZTP payload to carry out one or more ZTP operations. The ZTP payload can include instructions or actual software for configuring/provisioning/updating components in the O-RAN. As shown, the ZTP orchestrator 404 can transmit the ZTP payload directly to a core network of the O-RAN such as the 5G core 208 shown in FIG. 2. In various embodiments, such as the one shown in this example, the ZTP orchestrator 404 can transmit the ZTP payload to O-RAN ZTP adaptor 410, which in turn can configure/provision/update various components (including the core network). Some example components (such as XR11 servers) are shown in this example, just to illustrate the components can include a variety of software and hardware components provided by difference vendors and developers, and thus not intended to be limiting.

As still shown, the ZTP orchestrator 404 can receive feedbacks from the core network and/or O-RAN ZTP adaptor 410. The ZTP orchestrator 404 can be configured to update one or more aspects of the ZTP operations according to the feedbacks. For example, as shown in this example, specific ZTP stages can be updated according to the feedbacks.

FIG. 6 illustrates one example of the O-RAN ZTP adaptor 410 shown in FIG. 4. As mentioned, multiple developers or vendors can be involved in an O-RAN in accordance with the present disclosure. An insight provided by the present disclosure is that individual adaptors can be provided to facilitate ZTP operations on components in the O-RAN after they are orchestrated by the ZTP orchestrator 404. In this example, the O-RAN ZTP adaptor 410 includes an automation module 4102, one or more adaptors 4104, a security module 4106, a storage 4108, and/or any other components.

In some embodiments, the automation module 4102 is configured to carry one or more ZTP operations in accordance with one or more preconfigured rules or procedures. For instance, as illustration, without limitation, the ZTP payload received from the ZTP orchestrator 404 can include an instruction for a particular ZTP operation to be carried out—e.g., release a software update to a component in the O-RAN. In that instance, the automation module 4102 is configured to instantiate such an instruction by obtaining one or more rules or procedures corresponding to ZTP operations on that component. This may involve putting together an execution plan and/or a set of commands for carrying out the software update. Various components in the O-RAN can have different rules and/or procedures for ZTP operations on them. The automation module 4102 is configured to facilitate ZTP operations on the variety of the components in the O-RAN.

The adaptor(s) 4104 is configured to communicate with one or more components in the O-RAN. As shown, in FIG. 6, the components can include DUs, CUs, routers, security modules, network functions and/or any other components in one or more data centers in the O-RAN. The components can include a server (e.g., such as XR11 server provided by Dell), CSR, computing station (e.g., such as a site management system), RU and/or any other components in a cell site. In some embodiments, the O-RAN ZTP adaptor(s) 410 can include interface for a component provided by a vendor to communicate with another component in the O-RAN. For example, such an interface can include interface between Cisco CNC/NSO and one or more CSRs, Dell BMO and one or more XR11 servers, VMWare TCA/Gitlab and one or more XR11 servers, DUs and site management systems, AWS code Pipeline and CU, and/or any other interfaces.

The security module 4106 is configured to authenticate ZTP payload such as an instruction to instigate an ZTP operation is indeed from ZTP orchestrator 404 in the O-RAN. In various implementations, the security module 4106 is configured with security protocols to ensure secure communications with ZTP orchestrator 404, reference data system 402, data centers, cell sites and/or any other entities in the O-RAN.

The storage 4108 is configured to store one or more rules and/or procedures for facilitating ZTP operations on various components in the O-RAN. In implementations, data or artifacts stored in the storage 4108 can be used by the automation module 4102 and/or adaptor(s) 4104 to facilitate the ZTP operations.

Attention is redirected back to FIG. 4. The ZTP control console 406 is configured to provide one or more interfaces to enable one or more personnel of the O-RAN to perform and/or monitor ZTP operations. In one embodiment, a graphical dashboard is provided in the ZTP control console 406. In that embodiment, the dashboard provides an interface to enable a personnel (for example, a network engineer, a support engineer, a service engineer) of an operator of the O-RAN to instigate one or more ZTP operations. The ZTP control console 406 can be configured to facilitate the personnel to generate a request to instigate the one or more ZTP operations in the O-RAN, and transmit the request to the ZTP orchestrator 404 for execution.

The vendor ZTP adaptor 408 is configured to facilitate communications between systems/servers of vendor/developer of the O-RAN and the ZTP orchestrator 404. As mentioned, multiple vendors and/or developers can be involved in the O-RAN. The vendor ZTP adaptor 408 can be configured and placed in the O-RAN to enable these vendors or developers to instigate their ZTP operations on components provided by them in the O-RAN. For instance, the vendor ZTP adaptor 408 can be configured to communicate with a release management server of a specific vendor. The communication enabled by the vendor ZTP adaptor 408, in that instance, can include receiving a ZTP trigger from the specific vendor to release a version of its software to corresponding components provided by that vendor in the O-RAN.

FIG. 7 illustrates an example of a method for facilitating ZTP on one or more components in an O-RAN in accordance with the present disclosure. The operations of method 700 presented below are intended to be illustrative. In some embodiments, method 700 may be accomplished with one or more additional operations not described and/or without one or more of the operations discussed. Additionally, the order in which the operations of method 700 are illustrated in FIG. 7 and described below is not intended to be limiting.

In some embodiments, method 700 may be implemented by one or more computing devices including one or more of a processor. A given one of the one or more computing device may include a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information. The device may execute some or all of the operations of method 700 in response to instructions stored electronically on an electronic storage medium. The device may include one or more components configured through hardware, firmware, and/or software to be designed for execution of one or more of the operations of method 700. In various implementations, method 700 is carried out in a ZTP O-RAN layer, such as the O-RAN ZTP layer 400 shown in FIG. 4.

At 702, a request to perform zero-touch provisioning (ZTP) on a component is received. Some examples of ZTP in the O-RAN are illustrated in FIGS. 3A and 3B. It should be understood, as mentioned, zero-touch in accordance with the present disclosure does not necessarily mean no (what-so-ever) human intervention. It can mean no or little human intervention as compared to traditional component provisioning/updating. In one embodiment, the request at 702 is received from an interface provided in an O-RAN control console such as the ZTP control console 406 shown in FIG. 4. For instance, the interface enables a user (e.g. a network engineer of the O-RAN) to schedule a software update on a type of CSR (e.g., provided by a particular vendor) within the O-RAN. However, this is not necessarily the only case. In some embodiments, the request is received from a component in the O-RAN when it is first brought on-line in the O-RAN. For instance, after a router is set up in a cell site and powered up, it can send a request for provisioning itself to enable network activities for the cell site. Yet in another embodiment, the request at 702 can be sent from a vendor/developer with information regarding software release/update on a component provided by the vendor/developer. In that case, the request can be received from an interface between the O-RAN and a system of the vendor/developer, for example through the vendor ZTP adaptor 408 shown in FIG. 4. In some implementations, operations involved in 702 can be implemented by a ZTP control console substantially similar to or the same as the ZTP control console 406 described and illustrated herein.

At 704, a ZTP request is generated based on the request received at 702. In various embodiments, the ZTP request generated 704 includes information regarding software to be provisioned or to be updated, location where such software is available, a time for the requested ZTP, one or more target components for the ZTP, and/or any other information. For example, as illustration, thus without limitation, after a request to release a version of software to a CSR provided by a particular vendor is received at 704, the ZTP request is generated to include information indicating where the version of the software is available (for example, in a software repository or pipeline storage), a specific time (e.g., at a certain time and date), and types of components (e.g., one or more types of the CSR provided by the particular vendor in the O-RAN and as well as any accessory components working with those types of CSR), and/or any other information. In a sense, the ZTP request generated at 704 substantiates the request received 702 with more specificity or instructions as to a content of the ZTP to be performed on the one or more target components. In some implementations, some information include in the ZTP request may be overlap with that in the request received at 702. For example, the user may already specify a time at 702 for the ZTP on the target components. In one embodiment, operations at 704 includes validation and confirmation as to whether the ZTP requested by the user can be performed in the O-RAN, and returns an error to the user if it cannot be performed as requested, for example through the interface in the control console. In some implementations, operations involved in 704 can be implemented by a ZTP control console substantially similar to or the same as the ZTP control console 406 described and illustrated herein.

At 706, reference data is obtained based on the ZTP request generated at 704. As mentioned, one insight provided by the present disclosure is that reference data such as actual cell site construction inventory, RAN engineering specification, network planning, network design specification, PaaS planning, network security implementation, transport circuit implementation, network implementation, and/or any other types of information regarding the O-RAN can be used to drive the ZTP in the O-RAN. For example, after the ZTP request is generated, actual cell site construction inventory information can be obtained, for example, from construction inventory 502 shown in FIG. 5. This information can be used to determine, for example, which components, how many of them, where they are in the O-RAN should be the targets of the ZTP request generated at 704. For instance, the ZTP request at 704 may specify “update Cisco CSR type 1 and CSR type 2 to a specific version of the CSR software provided by Cisco”. According to this request, the actual construction inventory information is obtained so that it can be determined how many CSRs in the O-RAN are of type 1 and type 2 Cisco, where they are, and their installation status (e.g., installation complete/incomplete, powered up/down, and/or connected or disconnected), and/or any other information. In some implementations, operations involved in 706 can be implemented by a ZTP orchestrator substantially similar to or the same as the ZTP orchestrator 404 described and illustrated herein.

At 708, ZTP payload data is obtained according to the ZTP request generated at 704. The ZTP payload data can include information indicating actual software package(s) to be installed/released/updated to one or more components in the O-RAN according to the ZTP request generated at 704, a link indicating a location where the software package(s) can be obtained, schedule information indicating when to release the software package(s), one or more test suites to be performed after the software package(s) are installed to the one or more components, distribution information regarding to how to distribute the software package(s) to the one or more components in the O-RAN (e.g., where those components are located in the O-RAN), installation information indicating steps/procedures on how to install the software package(s) and/or any other ZTP payload information. In some situations, the ZTP payload data obtained at 708 is provided by a vendor or developer of the ZTP. In some situations, the ZTP payload data is generated within the O-RAN, for example, by the release/network/software engineers associated with an operator of the O-RAN. In some implementations, operations involved in 708 can be implemented by a ZTP orchestrator substantially similar to or the same as the ZTP orchestrator 404 described and illustrated herein.

At 710, one or more ZTP operations are determined based on the ZTP payload data obtained at 708 and/or the reference data obtained at 706. Examples of the ZTP operations can include one or more specific instructions or steps to be executed for the software package(s) in the ZTP payload data to be installed on the one or more components in the O-RAN, one or more preinstallation checks before the software package(s) is installed on those components, one or more post-installation sanity checks to ensure the installation is successful, one or more procedures or steps to be followed in the event when the software package(s) is not successfully installed on an individual component, one or more commands to be executed in order for the software packages to be installed. For example, the one or more commands can include a command for restoring the component to the previous version of the software package(s) if the installation is not successful. In some implementations, operations involved in 710 can be implemented by an O-RAN ZTP adaptor substantially similar to or the same as the ZTP adaptors 410 described and illustrated herein.

At 712, one or more instances of components in the O-RAN are determined to be targets of the ZTP operations determined at