System and method for configuring a network for onboarding a plurality of devices

Abstract

A system and method are provided for configuring a network for device onboarding. A hierarchical parameter data file describing the configuration parameters of the plurality of devices, such as a Yet Another Next Generation (YANG) model, is received. A parameter database file is populated with a plurality of configuration parameters, at least one of the configuration parameters being derived from the contents of the hierarchical parameter data file, and a parameter library is generated based on the parameter database file. A class definition file is created based on the database file and / or the hierarchical parameter data file. Then, for a network function, a corresponding configuration file is generated based on the parameter library and the class definition file and provided to the network function for implementation.

Description

Technical FieldApparatuses, systems, and methods according to one or more embodiments are generally directed to configuring networks and the network functions included therein to "include" (onboarding) a group of devices. The system generally contemplates that some or all of the required configuration data be derived from a hierarchical parameter data file, such as a YANG file, so that the data files required for configuration can be generated more quickly and easily with reduced manual data input.BackgroundModern networked systems, such as cellular networks, Internet connections, and cloud computing systems, must manage the interactions between a plurality of third-party devices connected to the system.When a new device is to be included in the network, a so-called "onboarding" process takes place, in which the network is configured to recognize and respond to the device. Particularly in the context of a mobile telephone network, a seller or manufacturer of such devices (e.g. telephones) will often attempt to include all its devices together in the network by making information about the device models available to the network operator. The provider can then configure its systems for all of these models accordingly by creating one or more configuration "schemes" that describe the configuration parameters of these models together and establish the required connection protocols. This can be a long process, but is required to ensure stable and secure connections between the devices and the network as a whole.SUMMARYThe object of the presented system and method is to enable an onboarding configuration process with minimal data input.Another object of the disclosed system and method is to reduce time and human errors in an onboarding configuration process.Another object of the present system and method is to utilize already existing network parameter files to derive data for an onboarding configuration process.These and other objects may be achieved with a system and method for configuring a network for onboarding a plurality of devices.In accordance with certain embodiments of the present disclosure, a method of configuring a network for onboarding a plurality of devices is provided. The method includes receiving, by a processor, a hierarchical parameter data file describing configuration parameters of the plurality of devices; padding, by a processor, a parameter database file with a plurality of configuration parameters, at least one of the configuration parameters being derived from the content of the hierarchical parameter data file; generating, by a processor, a parameter library based at least in part on the parameter database file; by a processor, a class definition file based at least in part on the parameter database file and / or the hierarchical parameter data file; generating, by a processor, at least one configuration file corresponding to a network function interfacing with at least one device of the plurality of devices, the configuration file being based at least in part on the parameter library and the class definition file; and providing the configuration file to the corresponding network function for implementation therein.In accordance with other embodiments of the present disclosure, a system for configuring a network for onboarding a plurality of devices is provided. The system includes a processor. The processor executes software instructions to receive a hierarchical parameter data file describing configuration parameters of the plurality of devices; fill a parameter database file with a plurality of configuration parameters, at least one of the configuration parameters derived from the content of the hierarchical parameter data file; generate a parameter library based at least in part on the parameter database file; generate a class definition file based at least in part on the parameter database file and / or the hierarchical parameter data file; generate at least one configuration file corresponding to a network function interfacing with at least one device of the plurality of devices, the configuration file based at least in part on the parameter library and the class definition file; and provide the configuration file to the corresponding network function to implement it there.In accordance with still other embodiments of the present disclosure, a non-transitory computer readable recording medium is provided. Instructions are recorded on the medium that can be executed by at least one processor to perform a method of configuring a network for onboarding a plurality of devices. The method includes receiving, by a processor, a hierarchical parameter data file describing configuration parameters of the plurality of devices; padding, by a processor, a parameter database file with a plurality of configuration parameters, at least one of the configuration parameters being derived from the content of the hierarchical parameter data file; generating, by a processor, a parameter library based at least in part on the parameter database file; by a processor, a class definition file based at least in part on the parameter database file and / or the hierarchical parameter data file; generating, by a processor, at least one configuration file corresponding to a network function interfacing with at least one device of the plurality of devices, the configuration file being based at least in part on the parameter library and the class definition file; and providing the configuration file to the corresponding network function for implementation therein.Other aspects, details, and advantages of the presented system and method are set forth in part in the following description and drawings.BRIEF DESCRIPTION OF THE DRAWINGSFeatures, advantages, and significance of exemplary embodiments of the disclosure will be described below with reference to the accompanying drawings, in which like numerals denote like elements, and in which: FIGS. 1A and 1B are flowcharts illustrating the flow of processes for configuring network functions in a network based on a hierarchical parameter data file according to an exemplary embodiment of the present invention; FIG. 2 is a functional flowchart illustrating a flow of processes for configuring network functions in a network based on a hierarchical parameter data file according to an exemplary embodiment of the present invention; FIGS. 3A-3D are illustrations of an illustrative example of a graphical user interface for deriving various data files from a hierarchical parameter data file according to an exemplary embodiment of the present invention; and FIG. 4 is a diagram of the components of one or more devices according to an exemplary embodiment of the present invention.DETAILED DESCRIPTIONThe following detailed description of exemplary embodiments relates to the attached drawings. The same reference numerals in different drawings may designate the same or similar elements.The foregoing disclosure includes illustrations and descriptions, but is not intended to be exhaustive and does not limit the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Further, one or more features or components of one embodiment may be integrated into or combined with another embodiment (or one or more features of another embodiment). Moreover, in the flowcharts and descriptions of operations below, one or more operations may be omitted, one or more operations may be added, one or more operations may be (at least partially) performed simultaneously, and the order of one or more operations may be changed.It will be appreciated 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 limiting to the implementations. Thus, the operation and behavior of the systems and / or methods have been described herein without reference to particular software code, wherein software and hardware may be designed to implement the systems and / or methods based on the description herein.Although specific combinations of features are set forth in the claims and / or the description, these combinations are not intended to limit the disclosure of possible embodiments. Indeed, many of these features may be combined in a manner not expressly mentioned in the claims and / or disclosed in the specification. Although each dependent claim listed below depends directly on only one claim, the disclosure of possible embodiments encompasses each dependent claim in combination with any other claim in the claim set.No element, action, and instruction used herein should be considered critical or essential unless expressly stated to be such. The articles "a" and "a single" used herein are intended to include one or more elements and may be used interchangeably with "one or more.". When only an article is meant, the term "a" or similar formulation is used. Also, the terms "has", "have", "have", "comprise", "including" or similar terms used herein are to be understood as open terms. The term "based on" means "based at least in part on" unless expressly stated otherwise. In addition, terms such as "at least one of [A] and [B]", or "at least one of [A] or [B]" are to be understood to include only A, only B, or both A and B.It should be appreciated that the principles disclosed herein are generally applicable to all types of networks, including, but not limited to, networks of Internet service providers such as fiber and cable networks, conventional telephone networks, and both wired and wireless networks in a structure, complex, or other localized area. However, for purposes of clarity and clarity, the network being analyzed and managed by the system described herein is primarily referred to as a mobile network.As briefly discussed in the background of this disclosure, interactions between a network and a hardware provider or other network device manufacturer require the use of a configuration scheme used to negotiate these interactions. When a provider attempts to "bind" to a network (onboard), i.e. establish connection protocols, this scheme must be provided in order to describe the configuration requirements for the devices of the provider.(It should be noted that the seller and manufacturer of a particular device may be the same or different companies, and if they are different they may treat different aspects of what is described herein as the actions of the "seller.". The distinction between these roles, however, is not relevant to the present disclosure. Therefore, for brevity, the vendor and manufacturer will be treated herein as a single unitary unit, and the terms will be used interchangeably).The scheme is normally in the form of a Configuration Management Database (CMDB) file or similar file, a telecommunications parameter library derived from the CMDB file, and a Java Active (JAR) and / or JavaScript Object Notation (JSON) file. By combining the data from these files, an appropriate XML file can be automatically created to describe the interactions between a particular combination of network devices or systems and the manufacturer. Such an XML file is generated and "pushed" to each network node or network function to configure the interaction protocols for that node.It is also noted that the CMDB, JAR, and YANG files and various combinations thereof may also be used to enable other configuration operations. The content and format of each of these files are standardized so that each of these configuration operations can function properly.A CMDB file generally describes the configuration of the manufacturer's individual network devices in a database format. The CMDB file must be uniquely created for each manufacturer-network pairing after a template. This would normally require a large amount of data to be manually input to a CMDB generation tool or directly to the template. Such an input is time consuming and cumbersome. It is also error prone and requires careful checking and frequent correction before CMDB-based configuration can be made.The modeling language YANG ("Yet Anchor Next Generation") is used to define configuration and state data for network management protocols. YANG uses an XML tree format with numerous data types and can store parameter data in a hierarchy, the structure being defined for the parameters when such a structure is applicable. A YANG file can also be easily converted to the JSON format if this is more favorable for the interaction between the respective network and the respective manufacturer. Because of its convenience, many manufacturers will have already defined and organized aspects of their configuration data in the form of a YANG file.Embodiments of the present invention are based on the until now unrecognized discovery that a substantial portion of the information required for the CMDB and the JAR files, particularly the relevant xpaths and static parameters, can be derived trivially from a manufacturer's YANG file data. If a manufacturer has already prepared a standard YANG file, as is the case with most network enabled device manufacturers, using the data in the YANG file to derive this information can significantly reduce the amount of manual inputs required to configure the CMDB and JAR files.In certain embodiments, only some, and not all, of the parameters for the CMDB file are derived from the YANG file. More specifically, in certain embodiments, the values of certain dynamic parameters-parameters that are defined by the manufacturer and may potentially change between runtimes-are still manually input via a software tool such as a suitable graphical user interface, preferably after the values of the other parameters are successfully derived from the YANG file.Practical tests of embodiments according to the disclosed invention have shown that all static parameters (i.e., all parameters that are not dynamic parameters) required for a default configuration scheme can be successfully derived from the data in a YANG file without further input. Moreover, even if dynamic parameters are required, on average, about 70% of the data input to a typical CMDB generation tool can be replaced with automatic conversion from the YANG file, resulting in significant time saving and error reduction.A flow of processes for configuring a network, in particular the network functions, on the primary basis of a YANG file or another hierarchical parameter data file will now be described with reference to FIGS. 1A and 1B, according to an embodiment of the invention.At 110, a hierarchical parameter data file describing configuration parameters of a plurality of devices to be connected to a network is received or retrieved. Although other formats of parameter data files also fall within the scope of the invention, in the present embodiment a file formatted according to the YANG modeling language is used (for simplicity, it is referred to herein as a "YANG file"), which is assumed hereinafter for simplicity. The content and format of the YANG file for a hierarchical parameter data file may correspond to standard YANG file structures.The devices may be organized according to device models, assuming that the same general configuration parameters apply to all devices of the same device model. Other organization groupings of devices, including treatment of all devices as having individual parameters, are also possible and are within the scope of the invention.At 120, a parameter database file is created and populated with a plurality of database format configuration parameters. Although other formats of parameter database files also fall within the scope of the invention, in the present embodiment a CMDB file is used, which is assumed below for simplicity. The content and format of a CMDB file may conform to the standard CMDB file structures.More specifically, in the illustrated embodiment, at 121, the parameters for padding the database file are derived from the contents of the YANG file, and at 125, the CMDB file is padded with the parameters.In the illustrated embodiment, it is assumed that each configuration parameter added to the CMDB file is derived from the content of the YANG file, although as noted below, particularly with reference to FIG. 1B, this is not a requirement of the invention.At 130, a telecommunications parameter library is created that is based on the content of the CMDB file and, in certain embodiments and configurations, additionally other stored or directly provided data. The parameter library preferably has a format comparable to the format of the CMDB file, and methods and tools for creating a parameter library based on a provided (e.g., uploaded) CMDB file are known in the art.In certain embodiments, operation 130 and the presence of the library file are omitted and the CMDB file is directly referenced for all data that can be retrieved from the library file. However, in other embodiments, a library file is prepared because this file format can be more easily referenced when a user or automated system wants to check the values of a particular parameter.It should be appreciated that in certain embodiments, operations 120 and 130 may be merged, converting the required content of the YANG file directly into the format of the parameter library. However, the illustrated embodiment utilizes existing methods to prepare a parameter library based on the CMDB file and thus uses the CMDB file as a mediator. Moreover, it is more convenient to integrate additional data provided as input during creation of the CMDB file than in other stages. As mentioned below, particularly with reference to FIG. 1B, such additional data is sometimes necessary.At 140, a class definition file is generated. Although other formats of class definition files are within the scope of the invention, a JAR file is presently preferred, which is assumed below for simplicity. The content and format of the JAR file for a class definition file may correspond to the standard structures of a JAR file.In the embodiment depicted in FIG. 1A, the content of the JAR file is derived from the content of the YANG file and is also based on other stored or directly provided data in certain embodiments and configurations. This derivation is similar to that of the contents of the CMDB file, particularly for the contents that are identical except for the file format.In the embodiment shown in FIG. 1A, operation 140 is performed simultaneously with operations 120 and 130 to save time. If concurrent execution is not possible due to hardware constraints or other reasons, operation 140 may be performed either before or after operations 120 and 130.At 150, the connection parameters are configured for a particular network function, network node, or the like. This process is referred to in the art as a "push configuration.". At this stage, the CMDB and YANG files are no longer required; the library file and the JAR file are sufficient to complete the following operations.Specifically, in 151, the network function or node and its characteristics are identified. In particular, an xpath or the like is preferably given.At 153, a configuration file for the network node is generated. Although other formats of configuration files also fall within the scope of the invention, an XML file is currently preferred, which is assumed below for the sake of simplicity. The configuration file is based on the contents of the parameter library and class definition file relevant to the identified network node, and in certain embodiments and configurations also on other stored or directly provided data. Preferably, the parameters are mapped based on the xpath provided. If the class definition file is a JAR file, it can be converted to an XML file, and the necessary data relating to the xpath is taken from the parameter library and added. The content and format of the XML file for a configuration file may correspond to standard XML file structures.At 155, the configuration file is pushed or otherwise provided to the network node. In various implementations of the network, this may include the transmission to the individual devices of the network node, to the network node or the network element or to an element management system (EMS) which manages the node or the element.Operation 150 may be repeated for any number of network functions, network nodes and elements, and individual devices using the same parameter library and JAR file, provided all of these devices have been described in the original YANG file. It can be assumed that a complete YANG file for a particular manufacturer describes all the devices manufactured by it.As mentioned above, the embodiment illustrated in FIG. 1A assumes that all parameters relevant to the configuration, and therefore added first to the CMDB file and then to the parameter library, can be derived directly from the contents of the YANG file. This applies, for example, when all relevant parameters are not dynamic, but static, since at least some embodiments of the invention are able to derive each possible static parameter from a YANG file that is complete and may be properly formatted according to standardized YANG file formats.However, if dynamic parameters are required and these dynamic parameters cannot be completely derived from the YANG file, the process flow must be changed. In such a change, as shown in Figure 1B, operation 120 is changed to 120'. In operation 120', parameters are still derived at 121', but not all parameters required for the CMDB file. The dynamic parameters that cannot be fully derived from the YANG file are provided directly at 123 and added along with the derived parameters to the CMDB file at 125'. Alternatively, at 123, so much additional data is provided that the missing dynamic parameters can be derived from this additional data in combination with the data of the YANG file.Moreover, all relevant dynamic parameters are required to create the JAR file. Therefore, the generation of the JAR file cannot occur simultaneously with the generation of the CMDB file and the parameter library at 120 and 130, but is instead delayed until after 130. The contents of the parameter library are then used instead of the YANG file itself to generate the contents of the JAR file at 140', since the parameter library contains enough data to generate the JAR file due to the direct provision of the additional data at 123.The approach illustrated in FIG. 1B may be implemented even when there are no relevant dynamic parameters, as for certain combinations of parameters in the CMDB and JAR files, it may be more favorable to derive or copy one from the other than to derive both directly from the YANG file.An illustrative functional flow diagram of interactions between systems during a process for configuring network functions based primarily on a YANG file or other hierarchical parameter data file will now be described with reference to FIG. 2, in accordance with an embodiment of the invention.In the illustrated embodiment, the systems include a network orchestrator 10. The orchestrator 10 is the primary controller for the operations described above, among others. Using the orchestrator 10, and more particularly one or more interfaces provided via the orchestrator 10, an agent of a network operator may configure aspects of the network by triggering processes in the other systems. For purposes of this disclosure, it is not relevant whether the network orchestrator 10 is operating automatically and, if not, who is being served as it is. For brevity, when a representative of the network operator operates the network orchestrator 10 to perform an action, this is described in the disclosure as if the network orchestrator 10 were to perform the action.In the illustrated embodiment, the systems include a network infrastructure platform 20. The platform 20 preferably performs the various operations described above in response to actuation of the orchestrator 10. It should be appreciated that certain embodiments combine the orchestrator 10 and the platform 20 into a single system. However, due to the arrangement of networks, it is often more favorable for platform 20 to be a server controlled from a remote terminal implementing orchestrator 10.In the illustrated embodiment, the systems include a file storage system 30. this may be a server or cloud-based storage. A preferred implementation is a MinIO cloud storage system, although the invention is not limited thereto. The provider stores its YANG file (or other hierarchical parameter data file) on the file storage system 30 for access by the carrier and typically by other parties as well. The file storage system 30 may be wholly or partly under the control of the supplier or the carrier as long as both have sufficient access for their respective operations described below. In certain embodiments, file storage system 30 is integrated into infrastructure platform 20 or into a provider system 40 (see below).In the illustrated embodiment, the systems include a vendor or manufacturer system 40. the vendor 40 system is the primary control for operations initiated by representatives of the vendor or manufacturer. Only one such operation that interacts with the file storage system 30 is illustrated in FIG. 2, and in embodiments where this is an expected level of simplicity, the seller system 40 is preferably a remote interface of the file storage system 30 that executes on any suitable device. For purposes of this disclosure, it is not relevant whether the seller system 40 is operating automatically and, if not, who is being served. In the disclosure, when a representative of the provider operates the provider system 40 to perform an action, it is described as if the provider system 40 itself performs the action for brevity.In the illustrated embodiment, the systems include at least one network function or node 50. the node 50 manages a network element of a physical device or group of physical devices with similar network characteristics. Due to the similar properties, the devices may be managed in the same or similar manner with the same configuration file. In the embodiment shown, it is assumed that all the devices managed by the network node 50 are products of the manufacturer.At 201, the seller system 40 stores a YANG file in the file storage system 30 (e.g., by uploading). The file is stored at a particular address intended for storage of YANG files for that provider. This may be a general location that the provider uses to provide the YANG file to each that it needs, or a storage location specific to the network operator, with the upload being part of the provider's request to be included in the network, among other possibilities.At 203, the orchestrator 10 transmits the address (e.g., a network path) of the YANG file to the network infrastructure platform 20.At 209, platform 20 begins generating the CMDB, library, and JAR files based on the provided YANG file. This process can be carried out, for example, as described in FIG. 1A or FIG. 1B.Specific inputs may be provided by the orchestrator 10 if required due to execution of operation 123 of FIG. 1B or similar operations. For example, at 211, the orchestrator activates a system to provide all the required data. Platform 20 responds with 213 by requesting information about the dynamic parameters, which in certain embodiments is by a GET command. The orchestrator 10 provides the required values at 215, which in certain embodiments is by a SET command. These values can be called up in particular by another module or a database, for example by an IP address manager (IPAM) module.At 217, the orchestrator 10 optionally requests the derived configuration data in the parameter library for local storage or other purposes. In particular, the orchestrator 10 preferably requests the static parameters that are not based on any of the inputs provided at 215. Platform 20 detects this request at 219 by providing the requested data, which in certain embodiments is by a COPY command.At 221, the orchestrator 10 initiates a configuration "push" for a particular network node, namely the network node 50 in the illustrated example. At 223, platform 20 responds to generating the XML file for network node 50, for example, according to operation 153 of FIG. 1A. And at 225, the XML file is transmitted or otherwise "pushed" to the network node 50 to configure it, e.g., according to operation 155 of FIG. 1A.Illustrative examples of GUI pages for configuring a network based on a YANG file or other hierarchical parameter data file will now be described with reference to FIGS. 3A-3D. It is to be understood that these examples are in no way controlling, as a plurality of suitable interfaces are possible for the disclosed invention, but merely serve as illustrative example of how such an interface could be implemented and operated in practice.On a general management page of the graphical user interface shown in FIG. 3A, a list 310 of the configuration schemes is provided. The list lists all schemes that have been completely generated or are in the generation process. The parameters included in the list include, in this example: a status that describes whether the generation ("create") of the CMDB, library, or JAR is currently in progress or has not yet begun, or whether the JAR is complete (as the expected last stage of schema generation); the name of the schema; the provider or manufacturer associated with the schema; a domain for the schema, such as "RAN" (Radio Access Network); an applicable version of the generated schema; and a network technology, such as LTE or 5G.In the illustrative example, the control elements are displayed on the upper right of the page. In particular, a control element 321 "add schema" is present. The actuation of the control element 321 results in the graphical user interface opening another page, as shown in FIG. 3B.On a schema identification page shown in Fig. 3B, control elements are provided to provide identification information for the schema to be added. In the illustrated example, the information provided includes a name for the schema and the corresponding domain, supplier, technology, and version. This information is displayed in the list on the general management page of the graphical user interface in Figure 3A once the schema begins to be created. Various suitable selection forms and other data entry means for the individual information are well known in the art and need not be discussed in detail.Once all information is entered, the user may proceed to another GUI page, as shown in FIG. 3C.On an upload page shown in FIG. 3C, a means for uploading a YANG file or another hierarchical parameter data file is provided. In the illustrated example, the upload file may be selected either by drag and drop from a file folder representation or by opening a file browser. Other upload interfaces are well known in the art and need not be discussed in detail.Once the upload is completed, the user may switch to another GUI page, as shown in FIG. 3D.On a preview page shown in Fig. 3D, the information provided on the schema identification page of Fig. 3B and information relating to or extracted from the YANG file uploaded via the upload page of Fig. 3C are displayed for verification. If the information is satisfactory to the user, he can confirm the communication. The system then returns to the general management GUI page of Figure 3A. Optionally, an acknowledgment message appears that the addition was successful.A diagram is seen in FIG. 3A at 330, with the "uploaded" state 331 indicating that a YANG file has been uploaded but not yet started generating the other files. When the line in the list is selected or highlighted for the YANG file, the controls 333, 335 and 337 appear and can be actuated. The JAR generation element 333 activates the full generation of a schema, including CMDB file, parameter library, and JAR file. The CMDB generation control part 335 only triggers generation of the CMDB file and the parameter library, and leaves the JAR stage at a later time. The delete controller 337 deletes the schema 330 from the list 310.In certain embodiments, the JAR generation controller 333 only causes the generation of the JAR file. When the system determines that dynamic parameters that cannot be derived from the YANG file are required for configuration, the JAR generation controller 333 is disabled until the generation of the CMDB file and the parameter library is completed, so that the method illustrated in FIG. 1B or a similar method can be completed in sequence. If the system determines that all required parameters can be derived from the YANG file, the JAR generation controller 333 is activated and can be actuated before or after activation of the CMDB generation controller 335.FIG. 4 is a diagram of the components of one or more devices according to an embodiment. The device 400 may correspond to any of the computing devices described above (e.g., the network orchestrator 10, the network infrastructure platform 20, the file storage system 30, the provider system 40, and the network node 50), as well as a processor executing any described software module or method, and a memory including any described data storage.As shown in FIG. 4, the device 400 may include a bus 410, a processor 420, a memory 430, a memory component 440, an input component 450, an output component 460, and a communication interface 470. It should be appreciated that one or more of the components may be omitted and / or one or more additional components may be included.Bus 410 includes a component that enables communication between the components of device 400. The processor 420 is implemented in hardware, firmware, or a combination of hardware and software. The processor 420 is 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 another type of processing component. Process 420 includes one or more processors that can be programmed to execute a function.The memory 430 includes random access memory (RAM), read only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions for use by the processor 420.The storage component 440 stores information and / or software related to the operation and use of the device 400. The storage component 440 may include, for example, a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, and / or a solid state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cassette, a magnetic tape, and / or another type of non-transitory computer readable medium along with a corresponding drive.The input component 450 includes a component that enables the device 400 to receive information, e.g., via a user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone). The input component 450 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator).The output component 460 includes a component that provides output information from the device 400 (e.g., a display, a speaker, and / or one or more light emitting diodes (LEDs)).Communication interface 470 includes a transceiver-like component (e.g., a transceiver and / or a separate receiver and transmitter) that enables device 400 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communication interface 470 may allow device 400 to receive information from another device and / or provide information to another device. The communication interface 470 may include, for example, an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency interface, a Universal Serial Bus (USB) interface, a Wi-Fi interface, a cellular interface, or the like.The device 400 may perform one or more processes described herein. The apparatus 400 may perform operations based on the processor 420 executing software instructions stored on a non-transitory computer readable medium such as the memory 430 and / or the storage component 440. A computer readable medium is defined herein as a non-transitory storage device. A storage device includes storage space within a single physical storage device or storage space distributed across multiple physical storage devices.Software instructions may be read into the memory 430 and / or the storage component 440 from another computer readable medium or device via the communication interface 470. When executed, the software instructions stored in the memory 430 and / or the storage component 440 may cause the processor 420 to perform one or more processes described herein.Additionally or alternatively, hardwired circuits may be used in place of or in combination with software instructions to perform one or more processes described herein. Therefore, the embodiments described herein are not limited to any particular combination of hardware circuits and software.The foregoing disclosure is illustrative and illustrative, but is not intended to be exhaustive and does not limit the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.Some embodiments may relate to a system, method, and / or computer readable medium at any possible technical level of detail of integration. Further, one or more of the components described above may be implemented as instructions stored on a computer readable medium and executable by at least one processor (and / or may include at least one processor). The computer readable medium may include a computer readable non-transitory storage medium (or media) having computer readable program instructions thereon for causing a processor to perform operations.The computer readable storage medium may be a tangible device that can store and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of a computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium as used herein is not to be understood to be transitory signals per se, 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 an optical fiber cable), or electrical signals transmitted through a wire.The computer readable program instructions described herein may be downloaded from a computer readable storage medium to the respective computing / processing devices or to an external computer or external storage device via a network, e.g., the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computer / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computer / processing device.The computer readable program code / instructions for executing operations may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state data, integrated circuit configuration data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuits including, for example, programmable logic circuits, field programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by using state information of the computer readable program instructions to personalize the electronic circuits to perform aspects or operations.These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, provide means for implementing the functions / acts specified in the flowchart and / or block diagram. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing device, and / or other devices to function in a particular manner, such that the computer readable storage medium having the instructions stored therein comprises an article of manufacture including instructions that implement aspects of the function / action indicated in the flowchart and / or block diagram block or blocks.The computer readable program instructions may also be loaded onto a computer, other programmable data processing device, or other device to cause a series of operational steps to be performed on the computer, other programmable device, or other device to produce a computer implemented process such that the instructions performed on the computer, other programmable device, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.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 flowchart or block diagrams may represent a module, segment, or portion of instructions that includes one or more executable instructions for implementing the specified logical function(s). The method, computer system, and computer readable medium may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the figures. In some alternative implementations, the functions indicated in the blocks may occur in an order other than that indicated in the figures. For example, two blocks shown in succession may actually be executed simultaneously or substantially simultaneously, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It is also noted that each block in the block diagrams and / or flowcharts, as well as combinations of blocks in the block diagrams and / or flowcharts, may be implemented by special purpose hardware-based systems that perform the specified functions or acts, or perform combinations of special purpose hardware and computer instructions.It will be appreciated 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 limiting to the implementations. Thus, the operation and behavior of the systems and / or methods have been described herein without reference to particular software code, wherein software and hardware may be designed to implement the systems and / or methods based on the description herein.

Claims

A method of configuring a network for embedding a plurality of devices, the method comprising: receiving, by a processor, a hierarchical parameter data file describing the configuration parameters of the plurality of devices; padding, by a processor, a parameter database file with a plurality of configuration parameters, at least one of the configuration parameters being derived from the content of the hierarchical parameter data file; generating, by a processor, a parameter library based at least in part on the parameter database file; generating, by a processor, a class definition file based at least in part on the parameter database file and / or the hierarchical parameter data file; by a processor, generating at least one configuration file corresponding to a network function that interfaces with at least one device of the plurality of devices, the configuration file based at least in part on the parameter library and the class definition file; and providing the configuration file to the corresponding network function to enable it to be implemented therein.The method of claim 1, wherein each static configuration parameter included in the parameter database file is derived from the content of the hierarchical parameter data file.The method of claim 1, wherein the hierarchical parameter data file is formatted according to the Yet Anchor Next Generation (YANG) modeling language.The method of claim 1, wherein the parameter database file is a configuration management database (CMDB).The method of claim 1, wherein the class definition file is a Java archive file (JAR).The method of claim 1, wherein the configuration file is an extensible markup (XML) file.A system for configuring a network for embedding a plurality of devices, the system comprising a processor executing software instructions to: receive a hierarchical parameter data file describing the configuration parameters of the plurality of devices; fill a parameter database file with a plurality of configuration parameters, at least one of the configuration parameters derived from the content of the hierarchical parameter data file; create a parameter library based at least in part on the parameter database file; create a class definition file based at least in part on the parameter database file and / or the hierarchical parameter data file; create at least one configuration file corresponding to a network function interfacing with at least one device of the plurality of devices, the configuration file based at least in part on the parameter library and the class definition file; and providing the configuration file of the corresponding network function so that it can be implemented there.The system of claim 7, wherein each static configuration parameter included in the parameter database file is derived from the content of the hierarchical parameter data file.The system of claim 7, wherein the hierarchical parameter data file is formatted according to the Yet Anchor Next Generation (YANG) modeling language.The system of claim 7, wherein the parameter database file is a Configuration Management Database (CMDB) file.The system of claim 7, wherein the class definition file is a Java archive file (JAR).The system of claim 7, wherein the configuration file is an extensible markup (XML) file.A non-transitory computer readable recording medium having instructions recorded thereon executable by at least one processor to perform a method of configuring a network for onboarding a plurality of devices, the method comprising: receiving a hierarchical parameter data file describing the configuration parameters of the plurality of devices; padding a parameter database file with a plurality of configuration parameters, at least one of the configuration parameters being derived from the content of the hierarchical parameter data file; generating a parameter library based at least in part on the parameter database file; generating a class definition file based at least in part on the parameter database file and / or the hierarchical parameter data file; generating at least one configuration file corresponding to a network function interfacing with at least one device of the plurality of devices, the configuration file being based at least in part on the parameter library and the class definition file; and providing the configuration file to the corresponding network function for implementation thereat.The recording medium according to claim 13, wherein each static configuration parameter included in the parameter database file is derived from the content of the hierarchical parameter data file.The recording medium of claim 13, wherein the hierarchical parameter data file is formatted according to the Yet Anchor Next Generation (YANG) modeling language.The recording medium according to claim 13, wherein the parameter database file is a Configuration Management Database (CMDB) file.The recording medium of claim 13, wherein the class definition file is a Java archive file (JAR).The recording medium according to claim 13, wherein the configuration file is an extensible markup (XML) file.

Images