Patent Application
20220253035
To satisfy the needs and demands of users of mobile communication devices, providers of wireless communication services continue to improve and expand available services and networks used to deliver such services. One aspect of such improvements includes edge networks and options to utilize and implement such networks. Through the edge networks, a service provider may manage a large number of user devices that use different types of services and experience various conditions. Managing all various types of network connections under different conditions poses various challenges.
The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.
Advanced networks, such as Fifth Generation (5G) networks, not only can provide efficient and low latency communication services, but also have the flexibility to adapt to different service demands, usage patterns, and loads in particular geographical regions. An underlying network infrastructure can amplify such flexibility when the infrastructure has the ability to rapidly allocate hardware and software resources, such as Central Processing Unit (CPU) cycles, memories, network cards, antennas, virtual network functions, virtual machines, and other components at network edges, to support a particular set of communication services. By streamlining processes for equipment acquisition, assembly, activation, and deployment and processes for ingesting data pertaining to such equipment, the provisioning system can reduce the time for adapting the edge networks to meet user demands.
Systems and methods are described herein that allow for the automatic provisioning of components of, for example, heterogeneous networks. As an example, systems and methods are described that allow for importing component data, integrating the component data into various databases, and using the imported data to provision a heterogeneous mix of network components. The provisioning may include requesting the system to provision a network component. When the system receives a request to provision a network component, the system may allocate the equipment parts for designing, assembling, deploying, and activating the network component.
UE 202 may include a wireless communication device. Examples of UEs 202 include: a smart phone; a tablet device; a wearable computer device (e.g., a smart watch); a laptop computer; a portable gaming system; and an Internet-of-Things (IoT) device. In some implementations, UE 202 may correspond to a wireless Machine-Type-Communication (MTC) device that communicates with other devices over a machine-to-machine (M2M) interface, such as Long-Term-Evolution for Machines (LTE-M) or Category M1 (CAT-M1) devices and Narrow Band (NB)-IoT devices. UEs 202 may send packets over or to access network 204.
Access network 204 may allow UEs 202 to access core network 206 and/or external network 208. To do so, access network 204 may establish and maintain, with participation from UE 202, an over-the-air channel with UE 202; and maintain backhaul channels with core network 206. Access network 204 may convey information through these channels, from UE 202 to core network 206 and vice versa.
Access network 204 may include a Fourth Generation (4G) radio network, a Fifth Generation (5G) radio network and/or another advanced radio network. These radio networks may include many wireless stations for establishing and maintaining an over-the-air channel with UE 202. The wireless station may include a 5G, 4G, or another type of wireless station (e.g., evolved Node B (eNB), next generation Node B (gNB), etc.) that includes one or more Radio Frequency (RF) transceivers. Depending on the implementation, the wireless stations may be coupled to Multi-Access Edge Computing (MEC) clusters in access network 204. The MEC clusters may be located geographically close to the wireless stations, and therefore also be close to UEs 202 serviced by access network 204 via the wireless stations. Due to its proximity to UEs 202, the MEC clusters may be capable of providing services to UEs 202 with minimal latency. Depending on the implementations, the MEC clusters may provide many core functions and/or other services, but at network edges.
Core network 206 may include a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), an optical network, a cable television network, a satellite network, a wireless network (e.g., a Code Division Multiple Access (CDMA) network, a general packet radio service (GPRS) network, an LTE network (e.g., a 4G network), a 5G network, an ad hoc network, a telephone network (e.g., the Public Switched Telephone Network (PSTN)), an intranet, or a combination of networks. In some implementations, the advanced networks within core network 206, such as 5G network, and the other networks (if additional networks are included in core network 206) may be arranged to support network slicing.
Core network 206 may allow the delivery of communication services (e.g., Internet Protocol (IP) services) to UEs 202, and may interface with other networks, such as external network 208. Depending on the implementation, core network 206 may include 4G core network components (e.g., a Serving Gateway (SGW), a Packet data network Gateway (PGW), a Mobility Management Entity (MME), etc.), 5G core network components (e.g., Access and Mobility Function (AMF), Session Management Function (SMF), etc.) or another type of core network component. Core network 206 may also include other networks, such as an IP Multimedia Subsystem (IMS) network that may provide a Short Messaging Service (SMS), Voice-over-IP (VoIP) service, etc.
External network 208 may include networks that are external to core network 206. In some implementations, external network 208 may include packet data networks, such as an IP network.
Within the implementation shown in
Processor 302 may include a processor, a microprocessor, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a programmable logic device, a chipset, an application specific instruction-set processor (ASIP), a system-on-chip (SoC), a central processing unit (CPU) (e.g., one or multiple cores), a microcontroller, and/or another processing logic device (e.g., embedded device) capable of controlling device 300 and/or executing programs/instructions.
Memory/storage 304 may include static memory, such as read only memory (ROM), and/or dynamic memory, such as random-access memory (RAM), or onboard cache, for storing data and machine-readable instructions (e.g., programs, scripts, etc.).
Memory/storage 304 may also include a floppy disk, CD ROM, CD read/write (R/W) disk, optical disk, magnetic disk, solid state disk, holographic versatile disk (HVD), digital versatile disk (DVD), and/or flash memory, as well as other types of storage device (e.g., Micro-Electromechanical system (MEMS)-based storage medium) for storing data and/or machine-readable instructions (e.g., a program, script, etc.). Memory/storage 304 may be external to and/or removable from network device 300. Memory/storage 304 may include, for example, a Universal Serial Bus (USB) memory stick, a dongle, a hard disk, off-line storage, a Blu-Ray® disk (BD), etc. Memory/storage 304 may also include devices that can function both as a RAM-like component or persistent storage, such as Intel® Optane memories.
Depending on the context, the term “memory,” “storage,” “storage device,” “storage unit,” and/or “medium” may be used interchangeably. For example, a “computer-readable storage device” or “computer-readable medium” may refer to both a memory and/or storage device.
Input component 306 and output component 308 may provide input and output from/to a user to/from network device 300. Input and output components 306 and 308 may include, for example, a display screen, a keyboard, a mouse, a speaker, actuators, sensors, gyroscope, accelerometer, a microphone, a camera, a DVD reader, Universal Serial Bus (USB) lines, and/or other types of components for obtaining, from physical events or phenomena, to and/or from signals that pertain to device 300.
Network interface 310 may include a transceiver (e.g., a transmitter and a receiver) for network device 300 to communicate with other devices and/or systems. For example, via network interface 310, network device 300 may communicate with wireless stations. Network interface 310 may also include an Ethernet interface to a LAN, and/or an interface/connection for connecting device 300 to other devices (e.g., a Bluetooth interface). For example, network interface 310 may include a wireless modem for modulation and demodulation.
Communication path 312 may enable components of network device 300 to communicate with one another.
Network device 300 may perform the operations described herein in response to processor 302 executing software instructions stored in a non-transient computer-readable medium, such as memory/storage 304. The software instructions may be read into memory/storage 304 from another computer-readable medium or from another device via network interface 310. The software instructions stored in memory or storage (e.g., memory/storage 304, when executed by processor 302, may cause processor 302 to perform processes that are described herein.
Template system 402 may allow users (e.g., vendor agents and/or network operators) to design new templates for a network component. In addition, template system 402 may provide reference data about what is possible to be deployed in the network and what is in the inventory. For a given template, various fields maybe mapped to JSON name-value pairs as explained below. After the design, a template for a particular component may be loaded into user interface 104, where a user may fill out the template. Upon receipt of the data from user interface 104, template system 402 may further process the data, as explained further below with reference to
Inventory system 404 may track its inventory of equipment. Upon receipt of equipment data from template system 402, inventory system 404 may create instances of equipment from the reference data that depicts what is or what will be deployed in the network. In addition, inventory system 404 may indicate, in its database, equipment available for assembling network components and deployment. When the number of available equipment parts change due to their deployment (as part of the network component assembled), inventory system 404 records such status changes to the equipment in its database.
Equipment activation system 406 may activate a particular component (assembled from equipment parts), activate the component, and communicate with inventory system 404. In particular, when a component is activated, equipment activation system 406 may inform inventory system 404 identities of equipment parts that comprise the components are in use, and therefore not available for use in other components. If a network component is deactivated and disassembled, its equipment parts may be returned to the pool of equipment parts, available to be used to assemble other network components.
Circuit orchestrator 408 may receive requests for new network components for deployment from a user (e.g., a network operator) or from another system (e.g., a software component). After the receipt of a request, circuit orchestrator 408 may coordinate several of the subsystems of component provisioning system 108 to design, assemble, and activate the network component. For example, circuit orchestrator 408 may request circuit provisioning logic 410 to initiate the provisioning process.
Circuit provisioning logic 410 may receive instructions from circuit orchestrator 408, and identify equipment parts needed to assemble the component, based on, for example, input and output constraints (e.g., bandwidth, noise, etc.). Furthermore, provisioning logic 410 may determine whether the determined parts (or items that can be used as the determined parts) are available in the inventory, by consulting inventory system 404. Provisioning logic 410 may select specific available equipment parts, based on performance constraints provided by orchestrator 408. Provisioning logic 410 may have the ability to rank different types of available parts based on their capabilities, ratings, price, etc. Provisioning logic 410 may return IDs (e.g., part IDs) for the parts and the desired equipment configurations to orchestrator 408, which may then invoke assembly logic 412 in response.
Assembly logic 412 may select identified parts for assembly, activation, and deployment. Depending on the implementation, assembly logic 412 may have the ability to interconnect one piece of equipment part to another and/or to move the equipment parts. Assembly logic 412 may provide configuration settings of the selected equipment parts to topology manger 414, so that topology manager 414 can make any changes to its records of the network topology.
Topology manager 414 may receive instructions from orchestrator 408 and equipment configuration information from assembly logic 412, to update the network topology (i.e., which network components/parts are connected to which). Topology manger 414 may send equipment status information to inventory system 404, so that inventory system 404 may record their part status. Such equipment parts would no longer be in the inventory of available equipment parts. Inventory system 404 may still track the status of the deployed equipment, however. Thereafter, the assembled components may be activated by equipment activation system 406.
Transformer 502 may receive input for designing a template (e.g., fields) and modeling equipment part type. The input may designate various fields and their names. In addition, for the modeling, the input may include information that maps fields of the template to JSON name-value pairs. The mapping may include information that indicates child-parent relationship between different equipment types. For example, if input data pertains to an equipment part type that is a child to another equipment part type (e.g., the child equipment part plugs into the parent equipment part), the mapping information may indicate, for the child equipment part type, the parent (e.g., a pointer to the equipment part type data for the parent). The information may later be used after instance data for an equipment part is input by a user, to automatically retrieve and incorporate its parent/child component data (e.g., the name of the parent component, a pointer to the parent component data, etc.), as part of the instance data.
According to one implementation, the mapping information may comprise a piece of code or a script (e.g., JavaScript), that when executed, converts equipment data input into the template into JSON name-value pairs. Transformer 502 may store both the template and the mapping information in its database.
In addition, transformer 502 may also convert user input received through a template (selected from a list of templates for different equipment parts) from user interface 104. In one implementation, the data input by a user may be sent as form data associated with a particular template. After the data is received from user interface 104, transformer 502 may map the received data to JSON name-pairs, using the mapping information provided at the time of template design. An example of JSON name-value pairs for a network card is described below with reference to
Update logic 504 may update or create an entry pertaining to the equipment part. After the update, update logic 504 may forward the updated data to an inspector 506.
Inspector 506 may include mechanisms associated with inspecting the data from update logic 504. In one implementation, inspector 506 may comprise a GUI-based component that requests a user to inspect the data, make any necessary corrections, and approve the corrected data. In a different implementation, inspector 506 may include a machine-learning (ML) component (e.g., an Artificial Intelligence (AI) component, a neural network, etc.) trained to detect or modify the data so that it can be onboarded. In a different implementation, inspector 506 may include a module for detecting data errors and for warning human operators to correct the data. After the inspection and/or correction, the data is then uploaded into database 508.
Databases 508 may include equipment data (i.e., the corrected data output from inspector 506). The equipment data in database 508 may include, for each equipment part, information that provides a characterization of the part (e.g., physical dimensions, description, its relationship to another component, etc.). Once the data is stored in database 508, the data may be used to populate, for example, other databases, such as a database in inventory system 404. Such data may not only provide a list of equipment data, but their use status as well.
Process 600 may further include receiving a user's selection of a particular template for an equipment part (block 604), retrieving the template from its database in response to the selection, and sending the template to user interface 104. The user (e.g., a vendor agent) at the user interface 104 may then provide input data for the equipment part into the template.
After the user provides input (i.e., equipment part data) to the template at user interface 104, interface 104 may send the input data to template system 402. Template system 402 may receive the input (block 606). In one implementation, template system 402 may receive the data as Hypertext Markup Language (HTML) data associated with a template/form. After the receipt of the input, template system 402 may retrieve the mapping information associated with the template from its database and convert the input data into JSON name-value pairs using the mapping information. In one implementation, the mapping information may include a script, a piece of code, or a program. In such implementations, template system 402 may execute the script, the piece of code or the program to convert the data into JSON name-value pairs. In a different implementation, the mapping information may include a conversion table of symbols/strings. In the latter implementations, template system 402 may perform the conversion through table lookups.
Process 600 may further include obtaining additional data about the equipment part (block 608). In obtaining the additional data, sub-processes such as bar coding, assigning a part ID, establishing relationships between other equipment data based on modeling, etc., may be performed. Furthermore, the additional data may be combined with the converted data (i.e., use the additional data to update the converted data) (block 608).
After the data has been updated, the updated data may be inspected (block 610). The inspection, as described above, may be performed by presenting the updated data to a user, and having the user provide appropriate feedback (e.g., fix incorrect portion of data, input additional data, etc.). In a different implementation, an AI component (e.g., artificial neural networks, ML components, etc.) may perform the correction. In such implementations, the historical data-correction data may be used to further train the AI component. Thereafter, the inspected data may be uploaded to various databases, such as a database in inventory system 404 (610). Once the data has been uploaded, the data may be used for provisioning network components.
Process 600 may further include receiving a request to provision a network component from a user (e.g., a network operator) (block 612). For example, a network operator may request a circuit orchestrator 408 to provision a network component in an access network 204, to handle additional UEs 202 that may wirelessly attach to access network 204 without suffering any loss in service quality. When requested to provision a network component, orchestrator 408 may coordinate many of its subsystems to provision the network component, such as circuit provisioning logic 410. In the request for provisioning, the user may not only specify the type of network component and/or the environment in which the component is to be deployed, but also circuit performance constraints and requirements. For example, for a CPU or the memory, or a network card, the request may specify the number of cores, its computational speed, the amount of memory, the bandwidth, the number of physical ports, as well as other configurable parameters.
Process 600 may further include obtaining equipment part data from the inventory system 404 (block 614). Furthermore, using the data, provisioning logic 410 may identify the equipment parts that are to be used in assembling the network component (block 614). In one implementation, to identify the equipment parts, logic 410 may first obtain the inventory of all available equipment parts that can be used to assemble the network component from the inventory system 404. In situations where equipment parts that can be used to assemble the network component do not satisfy performance requirements, they are eliminated as potential equipment parts to be used to assemble the component. If there are multiple available equipment parts that are interchangeable, provisioning logic 410 may perform various design optimizations, such as, for example, deciding between two different types of available parts, by evaluating their performance characteristics, purchase prices, etc. After identifying all of the equipment parts are to be used to assemble the component, the provisioning logic 410 may forward a list of the identified equipment parts to orchestrator 408 or assembly logic 412.
Process 600 may further include assembling the network component based on the list of equipment parts provided by the provisioning logic 410 (block 616). For example, circuit orchestrator 408 may instruct assembly logic 412 to assemble the network component. In some implementations, assembling the network component may include physically moving the equipment parts, interconnecting them (e.g., plugging one component to anther), and/or physically arranging them. After the assembly, assembly logic 412 may notify the inventory system 404 and the topology manager 414 about the assembly (block 618). In response, the inventory system 404 and topology manager 414 may record the changes (block 618). For example, inventory system 404 may record the status of the equipment parts, indicating that they are now part of a network component, ready to be deployed, and/or that they are no longer available to be used as part of another network component. Topology manager 414 may record modifications in the network topology due to connecting/integrating the newly assembled network component into the network. Once the recording activities at the inventory system 404 and topology manager 414 have been performed, the network component/the equipment parts may be activated (block 620). Any change in the status of the equipment parts (e.g., active status) may be indicated in the inventory manager 404's database (block 620).
Shelf 702 may include multiple child slots 704, into which a particular type of card may be inserted. For example, different types of cards 706 can be plugged into slot 704-1. Since model 702 is a reference model, cards 706 correspond to network card types, and not to physical equipment parts. In
Each Pluggable components 708 may include network cards. For example, pluggable component 708-1 may include multiple cards 710. Each of cards 710 (e.g., card 710-1) includes a particular card model, having multiple ports 712. For example, card 710-1 includes 100 GBASE SMALL FORM FACTOR CARD, with a physical port 712-1.
In one implementation, each of the components 702-712 is related to others via pointers, as child-parent. For example, each of slots 704 points to child cards 706, rather than including full copies of the data that represent the children cards. Accordingly, given slot 704-1, it is possible to use its pointer to locate its subcomponents 706. In a different implementation, model 700 may be created without using pointers, such that each of components 704-712 is part of a larger contiguous data set.
As noted above, model 700 may be stored and used by system 402, for retrieving or creating templates that user interface 104 displays to the user.
At interface 750, rather than viewing the list of subcomponents types for the component CI, the user may add a new subcomponent type (e.g., at “model”). When the user activates a menu item for creating a new template for the subcomponent type, window 752 pops open, allowing the user to enter the template name, comments, and/or other data.
Each port may be a parent to a logical port. For example, user interface 1102 show multiple logical ports under port “1-TX”—the parent to the logical ports. The properties of each of the logical ports under port “1-TX”, although not illustrated in
In this specification, various preferred embodiments have been described with reference to the accompanying drawings. Modifications may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense.
While a series of processes have been described above regarding blocks illustrated in
It will be apparent that aspects described herein may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement aspects does not limit the invention. Thus, the operation and behavior of the aspects were described without reference to the specific software code—it being understood that software and control hardware can be designed to implement the aspects based on the description herein.
Further, certain portions of the implementations have been described as “logic” that performs one or more functions. This logic may include hardware, such as a processor, a microprocessor, an application specific integrated circuit, or a field programmable gate array, software, or a combination of hardware and software.
To the extent the aforementioned embodiments collect, store, or employ personal information provided by individuals, it should be understood that such information shall be collected, stored, and used in accordance with all applicable laws concerning protection of personal information. The collection, storage and use of such information may be subject to consent of the individual to such activity, for example, through well known “opt-in” or “opt-out” processes as may be appropriate for the situation and type of information. Storage and use of personal information may be in an appropriately secure manner reflective of the type of information, for example, through various encryption and anonymization techniques for particularly sensitive information.
No element, block, or instruction used in the present application should be construed as critical or essential to the implementations described herein unless explicitly described as such. Also, as used herein, the articles “a,” “an,” and “the” are intended to include one or more items. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.
