Method and system for auto-commissioning a virtualized radio access network
The auto-commissioning of a virtualized radio access network through an auto-commissioning server automates the cell site deployment process, reducing time and costs while eliminating human error, thus enhancing the efficiency of cell site commissioning.
Patent Information
- Application Number
- JP2024537939
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2022-06-14
- Filing Date
- 2022-09-13
- Publication Date
- 2025-09-24
- Estimated Expiration
- 2042-09-13
AI Technical Summary
The traditional cell site commissioning process is time-consuming, labor-intensive, and prone to human error, requiring significant effort and resources from mobile operators to deploy cell sites efficiently and quickly.
A method and system for auto-commissioning a virtualized radio access network (vRAN) using an auto-commissioning server that automatically generates a day 0 configuration, deploys network functions in a cloud server, and activates them upon receiving a power-on notification from a radio unit, eliminating the need for physical site visits.
The auto-commissioning process significantly reduces commissioning time from weeks to hours, lowers operational costs, and minimizes human error by enabling a plug-and-play approach for cell site deployment.
Smart Images

Figure 0007743632000001 
Figure 0007743632000002 
Figure 0007743632000003
Abstract
Description
[Technical Field]
[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is based on and claims priority to Indian Patent Application No. 202241034050 filed on June 14, 2022, the disclosure of which is incorporated herein by reference in its entirety.
[0002] The present disclosure relates to wireless communications, and more particularly, the present disclosure relates to methods and systems for auto-commissioning a virtualized radio access network (vRAN). [Background technology]
[0003] Generally, mobile operators continue to experience huge demand for various features (e.g., high-speed communication) from users of electronic devices (e.g., smartphones), driven by multimedia applications and an ever-increasing number of electronic devices connected to networks (e.g., 5G mobile networks). To remain resilient in the market, mobile operators must deploy cell sites quickly and efficiently. Meanwhile, the cell site deployment process is complex and involves several parties, such as tower builders and wireless manufacturers.
[0004] Furthermore, the cell site deployment process involves different phases for deploying a cell site. One example is the installation phase, in which the cell site infrastructure is installed with various network hardware elements, along with necessary facilities such as electrical, cabling, and antenna mounting. Another example is the cell site integration and commissioning phase. The integration and commissioning phase is when network hardware elements (e.g., radio units (RUs)) are added to the network. During the integration and commissioning phase, cell site testing is performed to ensure that all hardware elements function as recommended by the administrator or mobile operator. One major test, among others, is communication and call testing. A quality assessment is then performed and presented to the hardware vendor and administrator for approval.
[0005] Traditionally, cell site commissioning has been a time-consuming, expensive, labor-intensive, and highly inefficient manual operation. Consider the following scenario: A network has several cell sites, and a mobile operator wants to deploy the cell sites quickly and efficiently. However, due to the manual process, a vendor or cell site engineer may need to physically visit each site. Each cell site visit may require a significant amount of time for commissioning (e.g., 3-4 hours, several days, or more). Furthermore, if the data center is not also ready, commissioning may take even longer (e.g., several days to several weeks, or more). Meanwhile, even if the vendor can perform the commissioning process remotely, the vendor still needs to perform the commissioning process manually. Therefore, with the traditional method, a mobile operator must expend significant effort and / or funds to complete commissioning on time. Furthermore, there is a possibility of human error when commissioning a cell site through a manual process. Summary of the Invention [Problem to be solved by the invention]
[0006] It would therefore be desirable to address the above-mentioned inconveniences and other shortcomings, or at least to provide a useful alternative to cell site commissioning. [Means for solving the problem]
[0007] Accordingly, a method and system for auto-commissioning a virtualized radio access network (vRAN) are provided. In one embodiment, the method may include receiving, by an auto-commissioning server, a plurality of parameters from a site controller, a database, and a plurality of network entities at the cell site. The method may further include automatically generating, by the auto-commissioning server, a day 0 configuration based on the received plurality of parameters. Furthermore, the method may also include deploying, by the auto-commissioning server, network functions of the vRAN in a cloud server based on the automatically generated day 0 configuration. The network functions of the vRAN may be at least one of cloud-native, virtual, or containerized. Additionally, the method may include receiving, by the auto-commissioning server, a power-on notification message from a radio unit (RU) at the cell site, where the power-on notification message may indicate that the RU at the cell site is ready for wireless signal transmission. The method may also include activating, by the auto-commissioning server, the deployed network functions of the vRAN before transmitting a wireless signal from the RU at the cell site.
[0008] In one embodiment, receiving the plurality of parameters from the site controller by the auto-commissioning server may include receiving, by the auto-commissioning server, a first set of parameters of the plurality of parameters from the site controller, The first set of parameters may include connectivity information associated with the cell site and the data center, and The first set of parameters may be stored in a database.
[0009] In another embodiment, receiving the plurality of parameters from the database by the auto-commissioning server may include receiving, by the auto-commissioning server, a second set of parameters of the plurality of parameters from the database. The second set of parameters may include cell site information and data center information. The cell site information and data center information may include logical identifiers associated with each network entity at the cell site and / or data center and physical information associated with each network entity at the cell site and / or data center, and the second set of parameters may be stored in the database.
[0010] In one embodiment, receiving, by the auto-commissioning server, the plurality of parameters from the plurality of network entities may include receiving, by the auto-commissioning server, a third set of parameters of the plurality of parameters from the plurality of network entities, which may include a Radio Access Network (RAN) planning tool, an Internet Protocol (IP) address controller, a naming controller, and a security engine.
[0011] In one embodiment, receiving a third set of parameters from the plurality of network entities by the auto-commissioning server may include receiving, by the auto-commissioning server, radio access network (RAN) planning data and radio unit (RU) mapping information with a network function from a RAN planning tool. The network function may include a centralized unit control plane (CUCP), a centralized unit user plane (CUUP), and a virtual distributed unit (vDU), and the auto-commissioning server may identify a cloud server on which the network function is instantiated. The RF planning data may include at least one of a physical cell identifier (PCI) or a route sequence index (RSI). Further, the method may include receiving, by the auto-commissioning server, from an IP address controller, a plurality of IP addresses for the network function and the RU at the cell site. The plurality of IP addresses may be generated based on a cloud server selected for deployment of the network function. Additionally, the method may include receiving, by the auto-commissioning server, a unique hostname for the network function. The unique hostname may be generated based on at least one of a type of network function or location information associated with the cloud server. The method may also include receiving, by the auto-commissioning server, a unique Transport Layer Security (TLS) username and password from the security engine to register a certificate from the certificate authority server. The certificate may be automatically installed for network functionality.
[0012] In one embodiment, deploying, by the auto-commissioning server, the network functions within cloud servers of the plurality of network entities based on the automatically-generated day 0 configuration may include sending, by the auto-commissioning server, a request to deploy the network function to the cloud server, deploying, by the auto-commissioning server, the network function within the cloud server, and receiving, by the auto-commissioning server, a status message from the cloud server. The status message may include an indication of at least one of successful deployment of the network function or failure to deploy the network function.
[0013] In another embodiment, the method may include automatically registering, by the auto-commissioning server, the plurality of generated IP addresses and associated fully qualified domain names (FQDNs) of the network function with a domain name system (DNS) server. Further, the method may include transmitting, by the auto-commissioning server, the updated information to a database for storing the updated information. The updated information may include a status message along with a logical identifier associated with the network function.
[0014] In yet another embodiment, activating, by the auto-commissioning server, the deployed network function of the vRAN before transmitting a radio signal from the RU of the cell site may include, by the auto-commissioning server, sending a request to a configuration management device to generate a day-1 configuration for the network function based on receiving the status message and before receiving the power-on notification message. The configuration management device may include a plurality of Third Generation Partnership Project-specific (or “3GPP®-specific”) parameters to automatically generate one or more files, and the automatically generated files may be used to activate the deployed network function of the vRAN. The network function may initiate a network configuration (NETCONF) session with the configuration management device, and the configuration management device may push the day-1 configuration to the network function when the NETCONF session is successfully established. Additionally, the method may include, upon receiving the power-on notification message, sending a request to the configuration management device to generate and push a radio unit (RU) configuration to the network function of the network function controller. The method may also include, by the auto-commissioning server, sending a notification response to the RU of the cell site by sharing parent network function connectivity information. Once the RUs at the cell site receive their radio configuration from the network function in the network function controller, they may begin radiating.
[0015] Therefore, the technology herein may use an auto-commissioning server for auto-commissioning of the vRAN. The auto-commissioning server may include an auto-commissioning engine coupled with a processor or memory. The auto-commissioning engine may receive parameters from a site controller, a database, and multiple network entities at the cell site. Further, the auto-commissioning engine may automatically generate a day 0 configuration based on the received parameters. In addition, the auto-commissioning engine may deploy network functions of the vRAN in a cloud server based on the automatically generated day 0 configuration. Also, the auto-commissioning engine may receive a power-on notification message from an RU at the cell site, which may indicate that the RU at the cell site is ready for wireless signal transmission. Furthermore, the auto-commissioning engine may activate the deployed network functions of the vRAN before transmitting wireless signals from the RU at the cell site.
[0016] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following description, while indicating preferred embodiments and numerous specific details thereof, is given by way of illustration and not limitation. Many changes and modifications may be made within the scope of the embodiments herein, and the embodiments herein include all such modifications.
[0017] Aspects and advantages of certain exemplary embodiments of the present disclosure will now be described with reference to the accompanying drawings, in which like reference numerals refer to like elements. [Brief explanation of the drawings]
[0018] [Figure 1A] FIG. 1 is a sequence diagram illustrating signaling between different entities for a virtualized radio access network (vRAN) during an auto-commissioning process, in accordance with one or more exemplary embodiments. [Figure 1B] FIG. 1 is a sequence diagram illustrating signaling between different entities for a virtualized radio access network (vRAN) during an auto-commissioning process, in accordance with one or more exemplary embodiments. [Figure 2] FIG. 1 is a sequence diagram illustrating signaling between different entities for a virtualized radio access network (vRAN) during an auto-commissioning process, in accordance with one or more exemplary embodiments.
[0019] [Figure 3] FIG. 1 is a block diagram of an auto-commissioning server for vRAN auto-commissioning, according to embodiments disclosed herein.
[0020] [Figure 4] FIG. 1 is a flow diagram illustrating a method for a vRAN auto-commissioning process, according to one or more example embodiments.
[0021] [Figure 5] FIG. 1 is a diagram of an exemplary environment in which the methods and systems described herein may be implemented.
[0022] [Figure 6] FIG. 1 is a diagram of components of one or more devices, according to one or more exemplary embodiments. DETAILED DESCRIPTION OF THE INVENTION
[0023] The following detailed description of the exemplary embodiments refers to the accompanying drawings, in which the same reference numbers in different drawings may identify the same or similar elements.
[0024] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of implementations. Furthermore, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, in the flowcharts and descriptions of operations provided below, it will be understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) concurrently, and the order of one or more operations may be permuted.
[0025] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or combinations of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not intended to limit the implementation. Accordingly, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.
[0026] Although particular combinations of features are recited in the claims and / or disclosed herein, these combinations are not intended to limit the disclosure of possible implementations. Indeed, many of these features may be combined in ways not specifically recited in the claims and / or disclosed herein. Although each dependent claim listed below may depend directly on only one claim, in the disclosure of possible implementations, each dependent claim includes in combination with every other claim in the set of claims.
[0027] No element, act, or instruction used herein should be construed as critical or required unless explicitly described as such. Additionally, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "one" or similar language is used. Additionally, as used herein, terms such as "has," "have," "having," "include," and "including" are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless expressly stated otherwise. Furthermore, phrases such as "at least one of [A] and [B]" and "at least one of [A] or [B]" should be understood to include A only, B only, or both A and B.
[0028] According to aspects of one or more embodiments presented herein, methods and systems may be provided for automatic commissioning (or "auto-commissioning") of a virtualized radio access network (vRAN). The auto-commissioning capability may enable a virtualized approach to element management systems (EMS) that may be performed remotely, eliminating the need for a physical visit to a cell site for cell site commissioning. Auto-commissioning provides a "plug-and-play" approach that significantly reduces (e.g., in minutes, etc.) the commissioning process, thereby significantly reducing or eliminating operational costs on a mobile operator's balance sheet while requiring a limited number of network resources and a limited amount of effort to complete commissioning on time.
[0029] Accordingly, embodiments herein disclose a method for auto-commissioning a virtualized radio access network (vRAN). The method may include receiving, by an auto-commissioning server, a plurality of parameters from a site controller, a database, and a plurality of network entities at a cell site. Further, the method may include automatically generating, by the auto-commissioning server, a day 0 configuration based on the received plurality of parameters. The day 0 configuration may include configurations required to deploy one or more network functions of the vRAN via a cloud server. The network functions of the vRAN may be at least one of cloud-native, virtual, or containerized. In some embodiments, the day 0 configuration includes configurations of attachment points (e.g., IPs of external interfaces and associated network functions), endpoint details of northbound systems, and images of the network functions. Further, the method may include deploying, by the auto-commissioning server, the network functions of the vRAN in the cloud server based on the automatically generated day 0 configuration. Additionally, the method may include receiving, by the auto-commissioning server, a power-on notification message from a radio unit (RU) at the cell site, where the power-on notification message may indicate that the RU at the cell site is ready for radio signal transmission. The method may also include activating, by the auto-commissioning server, deployed network functionality of the vRAN prior to transmitting wireless signals from the RUs at the cell site.
[0030] Accordingly, embodiments herein disclose an auto-commissioning server for auto-commissioning of a vRAN. The auto-commissioning server may include an auto-commissioning engine coupled with a processor or memory. The auto-commissioning engine may receive parameters from a site controller, a database, and network entities at a cell site. Furthermore, the auto-commissioning engine may automatically generate a day 0 configuration based on the received parameters. Furthermore, the auto-commissioning engine may deploy network functions of the vRAN in a cloud server based on the automatically generated day 0 configuration. Additionally, the auto-commissioning engine may receive a power-on notification message from an RU at the cell site, which may indicate that the RU at the cell site is ready for wireless signal transmission. Furthermore, the auto-commissioning engine may activate the deployed network functions of the vRAN before transmitting wireless signals from the RU at the cell site.
[0031] Unlike existing methods and systems, the proposed method enables a virtualized approach to element management systems (EMS) that can be run remotely and provides an automated commissioning capability that eliminates the need for a physical visit to a cell site for cell site commissioning. Automated commissioning provides a "plug-and-play" approach that reduces the commissioning process time from weeks to hours, thereby significantly reducing or eliminating operational costs on a mobile operator's balance sheet, requiring fewer network resources, and less effort to complete commissioning on time.
[0032] Referring now to the drawings, and more particularly to FIGS. 1A through 5, wherein like reference numerals indicate corresponding features consistently throughout the drawings, these drawings provide exemplary embodiments.
[0033] 1A, 1B, and 2 are sequence diagrams illustrating signaling between different entities for a virtualized radio access network (vRAN) auto-commissioning process, in accordance with one or more exemplary embodiments.
[0034] In some embodiments, the automatic commissioning process includes (1) instantiating and configuring network functions as shown in the sequence diagram of Figures 1A-1B, and (2) configuring radio units as shown in the sequence diagram of Figure 2.
[0035] 1A-2 illustrate an example "call flow," i.e., an example set of functions, programs, subprograms, scripts, or combinations thereof. The example call flows of FIGS. 1A-2, combined, represent an end-to-end auto-commissioning process (e.g., a 5G Macro vRAN auto-commissioning process). In some embodiments, the call flow represents zero-touch provisioning of 5G Macro vRAN services in an automated manner. The process includes steps (i.e., S1-S20) for commissioning a cell site so that the cell site is operational for one or more end customers. All network entities of system 1000 involved in vRAN auto-commissioning are integrated in a manner such that data flows automatically between all network entities, thus achieving zero-touch provisioning of the vRAN.
[0036] In one embodiment, the system 1000 includes, but is not limited to, a site controller 101, an inventory 102, an auto-commissioning server 103, a network entity 104, a configuration management device 105 (i.e., a configuration manager 105), a domain name system (DNS) server 106, a cloud server 107, a network function controller 108, and a radio unit (RU) 109. The network entity 104 includes a radio frequency (RF) planning tool 104a, an internet protocol (IP) address controller 104b, a name controller 104c, and a security engine 104d.
[0037] In step S1, the site controller 101 captures a plurality of parameters associated with the cell site and transmits the plurality of parameters to the inventory 102, where the inventory 102 stores the plurality of parameters (e.g., a first set of parameters, a second set of parameters, a third set of parameters, etc.). The plurality of parameters includes cell site information and data center information. The cell site information and data center information includes physical information associated with each network entity at the cell site and the data center. Some examples of cell site information include details of connectivity from the cell site to the data center and cell site location information (e.g., latitude, longitude, etc.), the height of the cell site and / or data center, the number of physical sectors present on the cell site, the type of antenna model installed on the cell site, the type of battery installed on the cell site, a quick response (QR) code or serial number associated with the antenna / battery model, media access control (MAC) addresses of elements (e.g., wireless devices, etc.) within the cell site, and any other suitable information.
[0038] In step S2, the site controller 101 sends connectivity information (e.g., dark fiber connectivity) associated with each cell site and data center to the auto-commissioning server 103. Connectivity information is an essential function for commissioning cell sites. Consider an exemplary scenario in which a network (e.g., a 5G network) includes approximately 10,000 data centers. However, each cell site can only have one dark fiber connection to a single data center. Thus, the connectivity information provides, for example, the connectivity fact that cell site "A" is connected to data center "1."
[0039] In step S3, upon receiving the connectivity information from the site controller 101, the auto-commissioning server 103 sends a request for cell site information and data center information to the inventory 102. In response to the request, the database provides the requested information to the auto-commissioning server 103.
[0040] In steps S4-S7, the auto-commissioning server 103 receives inputs (e.g., cell site planning data, IP addresses, unique hostnames, TLS authentication information, etc.) from the network entities 104 (i.e., the RF planning tool 104a, the IP address controller 104b, the name controller 104c, and the security engine 104d) to initiate automatic deployment of one or more V-RAN applications or one or more network functions (e.g., the centralized unit control plane (CUCP), the centralized unit user plane (CUUP), and the virtual distributed unit (vDU)).
[0041] In step S4, the auto-commissioning server 103 sends a request for RF planning data and radio unit (RU) mapping information to the RF planning tool 104a using network capabilities. The RF planning data may include, but is not limited to, a physical cell identifier (PCI) and route sequence index (RSI), a tracking area code (TAC), an azimuth angle, a tilt, and a multiple-input multiple-output (MIMO) configuration. The RF planning tool 104a sends the requested RF planning data and RU mapping information to the auto-commissioning server 103 using network capabilities. In another embodiment, the auto-commissioning server 103 fetches the RF planning data and RU mapping information from the RF planning tool 104a using network capabilities. The auto-commissioning server 103 identifies the data center / cluster in which the network capabilities need to be instantiated.
[0042] In step S5, the auto-commissioning server 103 sends a request to the IP address controller 104b to generate IP addresses for the network functions and the RUs 109 at the cell site. The IP addresses are generated based on the data center selected for deployment of the network functions. The IP address controller 104b sends the generated IP addresses for the network functions and the RUs 109 at the cell site to the auto-commissioning server 103. In another embodiment, the auto-commissioning server 103 integrates with the IP address controller 104b to generate all requested IP addresses for the network functions and the RUs 109.
[0043] In step S6, the auto-commissioning server 103 sends a request to the name controller 104c to generate a unique hostname for the network function. The unique hostname (e.g., a 14-character code) is generated based on the type of network function, and / or the type of data center, and / or location information associated with the data center. The name controller 104c sends the unique hostname for the network function to the auto-commissioning server 103. In another embodiment, the auto-commissioning server 103 integrates with the name controller 104c, which generates the unique hostname for the network function and the gNodeB ID for the vRAN network service.
[0044] In step S7, the auto-commissioning server 103 generates a unique Transport Layer Security (TLS) username and password and sends a request to the security engine 104d to register a certificate for secure access with the V-RAN application. In response, the security engine 104d generates and sends a unique TLS username and password to the auto-commissioning server 103. In another embodiment, the auto-commissioning server 103 integrates with the security engine 104d to generate the unique TLS username and password required for the certificate registration process. The certificate is automatically installed for network functionality.
[0045] In step S8, the auto-commissioning server 103 automatically generates a day 0 configuration based on the received parameters (e.g., parameters received from steps S4 to S7). The day 0 configuration is generated using descriptors or templates previously defined within the auto-commissioning server 103 for each of these services. For example, for a CUCP or CUUP service, the auto-commissioning server 103 takes all input / dynamic parameters (e.g., parameters obtained via steps S4 to S7) and inputs them (input / dynamic parameters) into those templates in an automated manner. With respect to dynamic parameters, dynamic can refer to a situation where parameters may be different for every instance of a network function and may be generated by the auto-commissioning server. Therefore, one advantage of the proposed method is that a vendor / cell site engineer / user does not need to develop a template each time, such as when 10,000 CUCPs need to be instantiated in a network. The vendor / cell site engineer / user does not need to modify data in a descriptor that is created once and reused as a template for any subsequent CUCP or CUUP service / deployment.
[0046] In step S9, the auto-commissioning server 103 sends a request to the cloud server 107 to deploy the network function. The network function is processed / managed by the cloud service provider.
[0047] In step S10, the auto-commissioning server 103 monitors the status of the deployment of the network function. Specifically, the auto-commissioning server 103 receives a status message from the cloud server 107. The status message includes an indication of the success of the deployment of the network function and / or the failure of the deployment of the network function.
[0048] In step S11, the auto-commissioning server 103 then automatically registers the generated IP addresses and associated fully qualified domain names (FQDNs) of the network functions in the DNS server 106. Generally, all IPs associated with a network (core network) function / V-RAN application must be registered / authorized to connect with the network. While the above registration process is manually performed in conventional methods / systems, the proposed method and system has an auto-registration feature that saves time and resources.
[0049] In step S12, the auto-commissioning server 103 sends a request to the inventory 102 to store updated information for the successful deployment of the network function, the updated information including a status message along with a logical identifier (e.g., FQDN, unique hostname, etc.) associated with the network function.
[0050] In steps S13-S15, the auto-commissioning server 103 sends a request to the configuration management device 105 to generate a day-one configuration for the network function based on receiving the status message (i.e., successful deployment / successful startup). The day-one configuration comprises configurations required to make the virtualized / containerized network function fully operational. In some embodiments, the day-one configuration includes external IP-related configuration, GNODEB ID, ECGI value, mobility-related configuration, bandwidth portion (BWP), and / or carrier frequency-related configuration. One or more network functions initiate one or more Network Configuration Protocol (NETCONF) sessions (e.g., NETCONF call-home and supervision procedures) with the configuration management device 105, and the configuration management device 105 pushes the day-one configuration to the network functions controller 108 upon successful NETCONF establishment. The configuration management device 105 includes several Third Generation Partnership Project-specific (or "3GPP-specific") parameters (e.g., yang files, 3GPP-specific libraries) that are used to automatically construct files (e.g., XML files) that are used to activate deployed network capabilities of the vRAN. In existing methods / systems, the vendor / cell site engineer / user must manually generate the files, but in the proposed method and system, the vendor / cell site engineer / user may upload multiple 3GPP-specific parameters (e.g., yang files, 3GPP-specific libraries), which may be one-time inputs, to the configuration management device 105 to generate a file / files based on requirements.
[0051] In steps S16-S18, the auto-commissioning server 103 receives a power-on notification message from the cell site's RU 109. This power-on notification message may be generated when a cell site engineer provides power to the cell site for radiation. Upon receiving the power-on notification message, the auto-commissioning server 103 sends a request to the configuration management device 105 to generate a radio configuration and push the radio configuration to the network functions of the network functions controller 108.
[0052] In steps S19-S20, the auto-commissioning server 103 sends a notification response to the cell site's RU 109 by sharing the parent network function connectivity information (e.g., vDU, MGMT, FQDN), and the cell site's RU 109 starts radiating upon receiving the radio configuration from the network function of the network function controller 108.
[0053] FIG. 3 is a block diagram of an auto-commissioning server 103 for vRAN auto-commissioning, according to an embodiment disclosed herein.
[0054] In one embodiment, the auto-commissioning server 103 includes a memory 103a, a processor 103b, a communicator 103c, and an auto-commissioning engine 103d.
[0055] In one embodiment, memory 103a stores multiple parameters (e.g., cell site information, data center information, connectivity information), day 0 configuration, etc. Memory 103a stores instructions executed by processor 103b. In some embodiments, memory 103a stores instructions that, when executed by processor 103b, enable processor 103b to function as a cloud orchestrator and perform one or more of the associated steps described in connection with FIGS. 1A, 1B, and 2. Memory 103a may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical disks, floppy disks, flash memory, or forms of electrically programmable memory (EPROM) or electrically erasable programmable memory (EEPROM). Additionally, memory 103a may, in some examples, be considered a non-transitory storage medium. The term “non-transitory” may indicate that the storage medium is not embodied in a carrier wave or propagating signal. However, the term “non-transitory” should not be interpreted as meaning that memory 103a is non-removable. In some examples, the memory 103a can be configured to store a larger amount of information than the memory. In particular examples, the non-transitory storage medium may store data that may change over time (e.g., in random access memory (RAM) or cache). The memory 103a can be an internal storage unit or can be an external storage unit of the auto-commissioning server 103, cloud storage, or other type of external storage.
[0056] The processor 103b is in communication with the memory 103a, the communicator 103c, and the auto-commissioning engine 103d. The processor 103b is configured to execute instructions stored in the memory 103a and perform various processes. The processor 103b may include one or more processors, possibly a central processing unit (CPU), a general-purpose processor such as an application processor (AP), a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and / or a dedicated artificial intelligence (AI) processor such as a neural processing unit (NPU).
[0057] Communicator 103c is configured to communicate internally between internal hardware components or with external devices (e.g., databases, cloud servers, etc.) over one or more networks (e.g., wireless technologies). Communicator 103c includes standard-specific electronic circuitry that enables wired or wireless communication.
[0058] The auto-commissioning engine 103d may be implemented by processing circuitry, such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuitry, etc., and may optionally be firmware-driven. The circuitry may be embodied, for example, in one or more semiconductor chips or on a substrate support such as a printed circuit board.
[0059] In one embodiment, the auto-commissioning engine 103d receives parameters from the site controller 101, the inventory 102, and the network entities 104 at the cell site.
[0060] The auto-commissioning engine 103d receives a first set of parameters from the site controller 101. The first set of parameters includes connectivity information associated with the site controller 101 and a cell site associated with the data center. The first set of parameters is stored in the inventory 102.
[0061] The auto-commissioning engine 103d receives a second set of parameters from the inventory 102. The second set of parameters includes cell site information and data center information. The cell site information and data center information includes logical identifiers associated with each network entity at the cell site associated with the site controller 101 and the data center, and physical information associated with each network entity at the cell site associated with the site controller 101 and the data center. The second set of parameters is stored in the inventory 102.
[0062] The auto-commissioning engine 103d receives a third set of parameters from the plurality of network entities 104. The plurality of network entities 104 includes an RF planning tool 104a, an IP address controller 104b, a name controller 104c, and a security engine 104d. Furthermore, the auto-commissioning engine 103d receives RF planning data and RU mapping information from the RF planning tool 104a using network functions. The network functions include a CUCP, a CUUP, and a vDU. The auto-commissioning server 103 identifies the inventory 102 and the cloud server 107, the network functions to be instantiated, and the RF planning data includes a PCI and an RSS.
[0063] Additionally, the auto-commissioning engine 103d receives from the IP address controller 104b a plurality of IP addresses for the network function at the cell site and the RU 109. The plurality of IP addresses are generated based on the inventory 102 selected for deployment of the network function. Additionally, the auto-commissioning engine 103d receives from the name controller 104c a unique host name for the network function. The unique host name is generated based on the type of network function, and / or the type of inventory 102, and / or location information associated with the inventory 102. Additionally, the auto-commissioning engine 103d receives from the security engine 104d a unique TLS username and password for registering a certificate. The certificate is automatically installed for the network function.
[0064] In one embodiment, the auto-commissioning engine 103d automatically generates a day 0 configuration based on the received multiple parameters (i.e., the first set of parameters, the second set of parameters, the third set of parameters, etc.).
[0065] In one embodiment, the auto-commissioning engine 103d deploys the network function of the vRAN in the cloud server 107 based on the automatically generated day 0 configuration. The auto-commissioning engine 103d sends a request to the cloud server 107 to deploy the network function. The auto-commissioning engine 103d deploys the network function in the cloud server 107. The auto-commissioning engine 103d receives a status message from the cloud server 107. The status message includes an indication of successful deployment of the network function, or failure to deploy the network function, or completion of deployment of the network function.
[0066] In one embodiment, the auto-commissioning engine 103d automatically registers the multiple generated IP addresses for the network function and the associated FQDN with the DNS server 106. The auto-commissioning engine 103d sends the updated information to the inventory 102 for storage. The updated information includes a status message along with a logical identifier associated with the network function.
[0067] In one embodiment, the auto-commissioning engine 103d receives a power-on notification message from the cell site's RU 109. The power-on notification message indicates that the cell site's RU 109 is ready to transmit radio signals.
[0068] In one embodiment, the auto-commissioning engine 103d activates the deployed network functions of the vRAN before transmitting a radio signal from the cell site's RU 109. Based on receiving the status message, the auto-commissioning engine 103d sends a request to the configuration management device 105 to generate a day 1 configuration for the network functions when it receives a power-on notification message. The configuration management device 105 includes multiple 3GPP-specific parameters to automatically generate a file. The automatically generated file is used to activate the deployed network functions of the vRAN. The network functions initiate a NETCONF session with the configuration management device 105, and the configuration management device 105 pushes the day 1 configuration to the network functions controller 108 when the NETCONF session is successfully established.
[0069] When the auto-commissioning engine 103d receives the power-on notification message, it sends a request to the configuration management device 105 to receive and push radio (RU) configuration to the network function of the network functions controller 108. The auto-commissioning engine 103d sends a notification response and shares parent network function connectivity information to the cell site's RU 109. When the cell site's RU 109 receives the radio configuration from the network function of the network functions controller 108, it begins radiating.
[0070] While Figure 3 illustrates various hardware components of the auto-commissioning server 103, it should be understood that other embodiments are not so limited. In other embodiments, the auto-commissioning server 103 may include fewer or more components. Furthermore, the labels or names of the components are used for illustrative purposes only and do not limit the scope of the invention. One or more components may be combined to perform the same or substantially similar functions for the auto-commissioning of a vRAN.
[0071] 4 is a flow diagram 400 illustrating a method for a vRAN auto-commissioning process, according to one or more example embodiments. Steps 401 to 405 may be performed by the auto-commissioning server 103 for auto-commissioning of a vRAN.
[0072] In step 401, the method includes receiving a plurality of parameters from a site controller 101, an inventory 102, and a plurality of network entities 104 of a cell site. In step 402, the method includes automatically generating a day 0 configuration based on the received plurality of parameters. In step 403, the method includes deploying network functions of the vRAN in the cloud server 107 based on the automatically generated day 0 configuration. In step 404, the method includes receiving a power-on notification message from an RU 109 of the cell site. The power-on notification message indicates that the RU 109 of the cell site is ready for wireless signal transmission. In step 405, the method includes activating the deployed network functions of the vRAN before transmitting wireless signals from the RU 109 of the cell site.
[0073] The various actions, operations, blocks, steps, etc. of flow diagram 400 may be performed in the order presented, in a different order, or simultaneously. Furthermore, in some embodiments, some of the actions, operations, blocks, steps, etc. may be omitted, added, modified, skipped, etc. without departing from the scope of the invention.
[0074] 5 is a diagram of an example environment 500 in which the methods and systems described herein may be implemented. As shown in FIG. 5, environment 500 may include a user device 510, a platform 520, and a network 530. The devices of environment 500 may be interconnected by wired connections, wireless connections, or a combination of wired and wireless connections. In embodiments, any of the functions and operations described with reference to FIGS. 1 through 4 above may be performed by any combination of elements shown in FIG. 5.
[0075] The user device 510 includes one or more devices that can receive, generate, store, process, and / or provide information related to the platform 520. For example, the user device 510 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smartphone, a wireless telephone, etc.), a wearable device (e.g., smart glasses or a smart watch), or a similar device. In some implementations, the user device 510 can receive information from and / or transmit information to the platform 520.
[0076] Platform 520 includes one or more devices that can receive, generate, store, process, and / or provide information. In some implementations, platform 520 may include a cloud server or a collection of cloud servers. In some implementations, platform 520 may be designed to be modular so that specific software components can be swapped out depending on specific needs. Thus, platform 520 can be easily and / or quickly reconfigured for various uses.
[0077] In some implementations, as shown, platform 520 may be hosted in a cloud computing environment 522. Notably, although the implementations described herein describe platform 520 as being hosted in a cloud computing environment 522, in some implementations platform 520 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment) or may be partially cloud-based.
[0078] Cloud computing environment 522 includes an environment that hosts platform 520. Cloud computing environment 522 may provide services such as computation, software, data access, storage, etc. that do not require end-user (e.g., user device 510) knowledge of the physical location and configuration of the systems and / or devices that host platform 520. As shown, cloud computing environment 522 may include a collection of computing resources 524 (collectively referred to as “computing resources 524” or individually as “computing resource 524”).
[0079] Computing resources 524 include clusters of one or more personal computers, computing devices, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, computing resources 524 may host platform 520. Cloud resources may include compute instances executing within computing resources 524, storage devices provided within computing resources 524, data transfer devices provided by computing resources 524, etc. In some implementations, computing resources 524 may communicate with other computing resources 524 via wired connections, wireless connections, or a combination of wired and wireless connections.
[0080] As further shown in FIG. 5, the computing resources 524 include a group of cloud resources, such as one or more applications (“APP”) 524-1, one or more virtual machines (“VM”) 524-2, virtualized storage (“VS”) 524-3, and one or more hypervisors (“HYP”) 524-4.
[0081] The application 524-1 includes one or more software applications that can be provided or accessed by the user device 510. The application 524-1 may eliminate the need to install or run a software application on the user device 510. For example, the application 524-1 may include software associated with the platform 520 and / or any other software that can be provided via the cloud computing environment 522. In some implementations, one application 524-1 may send and receive information to one or more other applications 524-1 via a virtual machine 524-2.
[0082] Virtual machine 524-2 includes a software implementation of a machine (e.g., a computer) that executes programs like a physical machine. Virtual machine 524-2 can be either a system virtual machine or a process virtual machine, depending on the application and the degree to which virtual machine 524-2 corresponds to any actual machine. A system virtual machine can provide a complete system platform that supports the execution of a complete operating system (“OS”). A process virtual machine can execute a single program and support a single process. In some implementations, virtual machine 524-2 can run on behalf of a user (e.g., user device 510) and manage the infrastructure of cloud computing environment 522, such as data management, synchronization, or long-term data transfer.
[0083] Virtualized storage 524-3 includes one or more storage systems and / or one or more devices that use virtualization techniques within the storage systems or devices of computing resources 524. In some implementations, within the context of a storage system, types of virtualization may include block virtualization and file virtualization. Block virtualization may refer to the abstraction (or separation) of logical storage from physical storage such that the storage system can be accessed regardless of the physical storage or heterogeneous structure. The separation may allow administrators flexibility in how they manage storage for end users. File virtualization can eliminate the dependency between data accessed at the file level and where the file is physically stored. This may enable optimization of storage usage, server consolidation, and / or performing non-disruptive file movements.
[0084] The hypervisor 524-4 may provide hardware virtualization technology that allows multiple operating systems (e.g., "guest operating systems") to run simultaneously on a host computer, such as the computing resource 524. The hypervisor 524-4 may present a virtual operating platform to the guest operating systems and may manage the execution of the guest operating systems. Multiple instances of various operating systems may share virtualized hardware resources.
[0085] The network 530 may include one or more wired and / or wireless networks. For example, the network 530 may include a cellular network (e.g., a fifth-generation (5G) network, a long-term evolution (LTE) network, a third-generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, an optical fiber-based network, etc., and / or a combination of these or other types of networks.
[0086] The number and arrangement of devices and networks shown in Figure 5 are provided as an example. In practice, there may be additional, fewer, different, or differently arranged devices and / or networks than those shown in Figure 5. Furthermore, two or more devices shown in Figure 5 may be implemented within a single device, or a single device shown in Figure 5 may be implemented as multiple distributed devices. Additionally, or instead, a set of devices (e.g., one or more devices) of environment 500 may perform one or more functions described as being performed by another set of devices of environment 500.
[0087] 6 is a diagram of example components of a device 600. The device 600 may correspond, for example, to a user device 510 and / or a platform 520. As shown in FIG. 6, the device 600 may include a bus 610, a processor 620, a memory 630, a storage component 640, an input component 650, an output component 660, and a communication interface 670.
[0088] The bus 610 includes components that enable communication between the components of the device 600. The processor 620 may be implemented in hardware, firmware, or a combination of hardware and software. The processor 620 may be a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or other type of processing component. In some implementations, the processor 620 includes one or more processors that can be programmed to perform certain functions. The memory 630 includes random access memory (RAM), read-only memory (ROM), and / or other types of dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory) that store information and / or instructions for use by the processor 620.
[0089] The storage component 640 stores information and / or software related to the operation and use of the device 600. For example, the storage component 640 may include a hard disk (e.g., a magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cartridge, magnetic tape, and / or other type of non-transitory computer-readable medium, along with a corresponding drive. The input component 650 includes components that enable the device 600 to receive information, such as via user input (e.g., a touchscreen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone). Additionally or alternatively, the input component 650 may include sensors for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). The output component 660 includes components that provide output information from the device 600 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).
[0090] The communication interface 670 includes transceiver-like components (e.g., a transceiver and / or a separate receiver and transmitter) that enable the device 600 to communicate with other devices via a wired connection, a wireless connection, or a combination of wired and wireless connections, etc. The communication interface 670 may enable the device 600 to receive information from and / or provide information to another device. For example, the communication interface 670 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, etc.
[0091] Device 600 may perform one or more processes described herein. Device 600 may perform these processes in response to processor 620 executing software instructions stored by a non-transitory computer-readable medium, such as memory 630 and / or storage component 640. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space across multiple physical storage devices.
[0092] The software instructions may be loaded into memory 630 and / or storage component 640 from another computer-readable medium or from another device via communication interface 670. When executed, the software instructions stored in memory 630 and / or storage component 640 may cause processor 620 to perform one or more processes described herein.
[0093] Additionally, or instead, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more of the processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
[0094] The number and arrangement of components shown in Figure 6 are provided as an example. In practice, device 600 may include additional, fewer, different, or differently arranged components than those shown in Figure 6. Additionally or alternatively, a set of components (e.g., one or more components) of device 600 may perform one or more functions described as being performed by another set of components of device 600.
[0095] In an embodiment, any one of the operations or processes of FIGS. 1 through 4 may be performed by or using any one of the elements shown in FIGS.
[0096] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of implementations.
[0097] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail of integration. Furthermore, one or more of the above components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include one or more computer-readable non-transitory storage media having computer-readable program instructions for causing a processor to perform operations.
[0098] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooved ridge structures on which instructions are stored, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as being, per se, transitory signals such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted through wires.
[0099] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.
[0100] The computer-readable program code / instructions for carrying out operations may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages such as Smalltalk, C++, and procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects or operations.
[0101] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute on the processor of the computer or other programmable data processing apparatus, create means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises a product containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.
[0102] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to execute a series of operational steps to generate a computer-implemented process, such that the instructions executing on the computer, other programmable data processing apparatus, or other device perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.
[0103] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing the specified logical function(s). The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks than those shown in the figures. In some alternative implementations, the functions noted in the blocks may occur in a different order than noted in the figures. For example, two blocks shown in succession may actually be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, can be implemented by a dedicated hardware-based system that performs the specified functions or operations or executes a combination of dedicated hardware and computer instructions.
[0104] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not intended to limit the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.
Claims
1. 1. A method for auto-commissioning of a virtualized radio access network (vRAN) by an auto-commissioning server, the method comprising: receiving, by the auto-commissioning server, a plurality of parameters from a site controller, an inventory, and a plurality of network entities at a cell site; automatically generating, by the auto-commissioning server, a day 0 configuration based on the received parameters; deploying, by the auto-commissioning server, at least one network function of the vRAN in a cloud server based on the automatically generated day 0 configuration; receiving, by the auto-commissioning server, a power-on notification message from a radio unit (RU) at the cell site indicating that the RU at the cell site is ready for wireless signal transmission; activating, by the auto-commissioning server, the at least one deployed network function of the vRAN prior to transmitting a wireless signal from the RU at the cell site; and A method comprising:
2. receiving the plurality of parameters from the site controller by the auto-commissioning server; receiving, by the auto-commissioning server, a first set of parameters of the plurality of parameters from the site controller, the first set of parameters including connectivity information associated with at least one of the cell site and a data center associated with the site controller, and storing the first set of parameters in the inventory. The method of claim 1.
3. receiving the plurality of parameters from the inventory by the auto-commissioning server; receiving, by the auto-commissioning server, a second set of parameters of the plurality of parameters from the inventory, the second set of parameters including at least one of cell site information and data center information, the cell site information and the data center information including at least one of logical identifiers associated with each network entity of the cell site and / or the data center associated with the site controller, and physical information associated with each network entity of the cell site and / or the data center associated with the site controller, and the second set of parameters being stored in the inventory. The method of claim 2.
4. receiving the plurality of parameters from the plurality of network entities by the auto-commissioning server; receiving, by the auto-commissioning server, a third set of parameters from the plurality of network entities, the plurality of network entities including a radio frequency (RF) planning tool, an internet protocol (IP) address controller, a name identifier, and a security engine. The method of claim 1.
5. receiving, by the auto-commissioning server, parameters of the third set of parameters from the plurality of network entities; receiving, by the auto-commissioning server, radio frequency (RF) planning data and radio unit (RU) mapping information from the RF planning tool with the at least one network function, the at least one network function including a centralized unit control plane (CUCP), a centralized unit user plane (CUUP), and a virtual distributed unit (vDU), the auto-commissioning server identifying the cloud server on which the inventory and the network function are instantiated, the RF planning data including a physical cell identifier (PCI) and a received signal strength (RSS); receiving, by the auto-commissioning server, from the IP address controller, a plurality of IP addresses for the at least one network function and RUs at the cell site, the plurality of IP addresses being generated based on an inventory selected for deployment of the at least one network function; receiving, by the auto-commissioning server, unique hostnames for the at least one network function and the cell site from the name identifier, the unique hostnames being generated based on at least one of a type of network function, a type of the inventory, and location information associated with the inventory; receiving, by the auto-commissioning server, from a security engine, a unique Transport Layer Security (TLS) username and password for registering a certificate, the certificate being automatically installed for the at least one network function; The method of claim 4, comprising:
6. deploying the at least one network function in the cloud server based on the day 0 configuration automatically generated by the auto-commissioning server; sending, by the auto-commissioning server, a request to deploy the at least one network function to the cloud server; deploying, by the auto-commissioning server, the at least one network function within the cloud server; receiving, by the auto-commissioning server, a status message from the cloud server, wherein the status indicated in the status message includes at least one of a successful deployment of the at least one network function, a failure to deploy the at least one network function, and a completion of deployment of the at least one network function. The method of claim 1.
7. automatically registering, by the auto-commissioning server, a plurality of generated IP addresses and associated fully qualified domain names (FQDNs) of the at least one network function with a domain name system (DNS) server; and transmitting, by the auto-commissioning server, the updated information to the inventory for storage, wherein the updated information includes a status message along with a logical identifier associated with the at least one network function. The method of claim 1.
8. activating, by the auto-commissioning server, the at least one deployed network function of the vRAN prior to emission of the RU at the cell site, sending, by the auto-commissioning server, a request to a configuration management device to generate a day 1 configuration for the at least one network function based on the status message and the power-on notification message, the configuration management device including a plurality of Third Generation Partnership Project (3GPP) specific parameters to automatically generate at least one file, the at least one automatically generated file being used to activate the at least one deployed network function of a vRAN, the at least one network function initiating a Network Configuration Protocol (NETCONF) session with the configuration management device, and the configuration management device pushing the day 1 configuration to a network functions controller when the NETCONF session is successfully established; upon receiving the power-on notification message, sending, by the auto-commissioning server, a request to the configuration management device to generate and push a radio unit (RU) configuration to the at least one network function of the network function controller; sending, by the auto-commissioning server, a notification response to the RU at the cell site by sharing parent network function connectivity information, wherein the RU at the cell site begins radiating upon receiving a radio configuration from the at least one network function of the network function controller; The method of claim 1 , comprising:
9. 1. An auto-commissioning server for auto-commissioning of a virtualized radio access network (vRAN), comprising: receiving a plurality of parameters from a site controller, an inventory, and a plurality of network entities at the cell site; automatically generating a day 0 configuration based on the received plurality of parameters; deploying at least one network function of the vRAN in a cloud server based on the automatically generated day 0 configuration; receiving a power-on notification message from a radio unit (RU) at the cell site indicating that the RU at the cell site is ready for wireless signal transmission; activating the at least one deployed network function of the vRAN before transmitting a wireless signal from the RU at the cell site; configured to execute instructions Auto-commissioning server.
10. The method of claim 1, further configured to execute instructions to receive a first set of parameters of the plurality of parameters from the site controller, the first set of parameters including connectivity information associated with at least one of the cell site and a data center associated with the site controller, and the first set of parameters being stored in the inventory.
10. The auto-commissioning server of claim 9. and further configured to receive a second set of parameters of the plurality of parameters from the inventory, the second set of parameters including at least one of cell site information and data center information, the cell site information and the data center information including at least one of logical identifiers associated with each network entity of the cell site and / or the data center associated with the site controller, and physical information associated with each network entity of the cell site and / or the data center associated with the site controller, and the second set of parameters being stored in the inventory.
11. An auto-commissioning server according to claim 10.
12. The method of claim 11, further configured to receive a third set of parameters from the plurality of network entities, the plurality of network entities including a radio frequency (RF) planning tool, an internet protocol (IP) address controller, a name identifier, and a security engine.
10. The auto-commissioning server of claim 9. receiving radio frequency (RF) planning data and radio unit (RU) mapping information from the RF planning tool using the at least one network function; receiving, by the auto-commissioning server, from the IP address controller, a plurality of IP addresses for the at least one network function and RU of the cell site; receiving, by the auto-commissioning server, a unique hostname for the at least one network function and the cell site from the name identifier; further configured by the auto-commissioning server to receive from the security engine a unique Transport Layer Security (TLS) username and password for enrolling a certificate; the at least one network function includes a centralized unit control plane (CUCP), a centralized unit user plane (CUUP), and a virtual distributed unit (vDU); the auto-commissioning server identifies the inventory and the cloud server on which the network function is instantiated; the RF planning data includes a physical cell identifier (PCI) and a received signal strength (RSS); the plurality of IP addresses are generated based on an inventory selected for deployment of the at least one network function; the unique hostname is generated based on at least one of a type of network feature, a type of the inventory, and location information associated with the inventory; The certificate is automatically installed for the at least one network function.
13. An auto-commissioning server according to claim 12.
14. The method of claim 13, further comprising: transmitting a request to deploy the at least one network function to the cloud server; deploying the at least one network function within the cloud server; and further configured to receive a status message from the cloud server, wherein the status indicated by the status message includes at least one of a successful deployment of the at least one network function, a failure to deploy the at least one network function, and a completion of deployment of the at least one network function.
10. An auto-commissioning server according to claim 9.
15. The automatic commissioning server automatically registering the plurality of generated IP addresses and associated fully qualified domain names (FQDNs) of the at least one network function with a domain name system (DNS) server; configured to send the updated information to the inventory for storage; the updated information includes a status message along with a logical identifier associated with the at least one network function.
10. An auto-commissioning server according to claim 9.
16. The method of claim 15, further comprising: sending a request to a configuration management device to generate a day 1 configuration for the at least one network function based on the status message and the power-on notification message; upon receiving the power-on notification message, sending a request to the configuration management device to generate and push a radio unit (RU) configuration to the at least one network function of a network function controller; further configured to send a notification response to the RU at the cell site by sharing parent network capability connectivity information; the configuration management device includes a plurality of Third Generation Partnership Project (3GPP) specific parameters for automatically generating at least one file, the at least one automatically generated file being used to activate the at least one deployed network function of the vRAN, the at least one network function initiating a Network Configuration Protocol (NETCONF) session with the configuration management device, and the configuration management device pushing the day 1 configuration to a network functions controller upon successful establishment of the NETCONF session; the RU at the cell site begins radiating upon receiving a radio configuration from the at least one network function of the network function controller; 10. The auto-commissioning server of claim 9.
17. To perform the method for auto-commissioning of a virtualized RAN, an auto-commissioning server computer is provided with: receiving a plurality of parameters from a site controller, an inventory, and a plurality of network entities at the cell site; automatically generating, by the auto-commissioning server, a day 0 configuration based on the received parameters; deploying at least one network function of the vRAN in a cloud server based on the automatically generated day 0 configuration; receiving, by the auto-commissioning server, a power-on notification message from a radio unit (RU) at the cell site indicating that the RU at the cell site is ready for wireless signal transmission; activating the at least one deployed network function of the vRAN before transmitting a wireless signal from the RU at the cell site; A computer program that executes the following:
Citation Information
Patent Citations
Techniques to prevent and / or minimize user equipment service disruptions in virtualized radio access network architectures
US11304109B1
Automated provisioning of radios in a virtual radio access network
US20200162348A1
Method and apparatus for performing function of radio access network
US20200383115A1
Method for managing a virtual radio access network and method for calibrating a software component
US20210289385A1
Virtualized radio access network (VRAN) decoding as a service
US20220159785A1