SYSTEM AND METHOD FOR CONFIGURING A NETWORK FOR ONBOARDING A LARGE NUMBER OF DEVICES

Abstract

A method for configuring a network to integrate a plurality of devices, comprising: receiving a hierarchical parameter data file describing the configuration parameters of the plurality of devices; by a processor, populating a parameter database file with a plurality of configuration parameters, wherein at least one of the configuration parameters is derived from the contents of the hierarchical parameter data file; by a processor, generating a parameter library at least partially based on the parameter database file; by a processor, generating a class definition file based at least partially 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 provides an interface to at least one device of the plurality of devices, wherein the configuration file is based at least partially on the parameter library and the class definition file; and providing the configuration file to the corresponding network function so that it can be implemented there.

Description

Technical field Devices, systems, and methods according to one or more embodiments are generally aimed at configuring networks and their network functions to "onboard" a group of devices. The system generally provides for some or all of the necessary configuration data to 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 entry. background Modern networked systems, such as mobile networks, internet connections and cloud computing systems, must manage the interactions between a variety of third-party devices connected to the system. When a new device is to be added to the network, a process called "onboarding" takes place, in which the network is configured to recognize and respond to the device. Particularly in the context of a mobile phone network, a vendor or manufacturer of such devices (e.g., phones) will often try to integrate all their devices into the network together by providing the network operator with information about the device models. The operator can then configure their systems accordingly for all these models by creating one or more configuration "schemas" that describe the configuration parameters of these models collectively and define the necessary connection protocols. This can be a lengthy process, but it is necessary to ensure stable and secure connections between the devices and the network as a whole. German patent application DE 11 2012 004 935 T5 discloses a wireless communication system that describes techniques for reducing interference in heterogeneous networks. This system uses special subframe configurations to improve the coexistence of macrocells and picocells. Furthermore, US patent 9,785,412 B1 discloses a method for managing radio resources in a mobile network. This method focuses on optimizing quality of service (QoS) through the dynamic allocation of bandwidth resources based on current network conditions. SUMMARY The aim of the presented system and procedure is to enable an onboarding configuration process with minimal data input. Another goal of the disclosed system and procedure is to reduce the time required and human error in an onboarding configuration process. Another goal of the presented system and procedure is to use existing network parameter files to derive data for an onboarding configuration process. These and other goals can be achieved with a system and procedure for configuring a network for onboarding a large number of devices. In accordance with certain embodiments of the present disclosure, a method for configuring a network for onboarding a plurality of devices is provided. The method comprises receiving a hierarchical parameter data file describing configuration parameters of the plurality of devices; populating a parameter database file with a plurality of configuration parameters by a processor, wherein at least one of the configuration parameters is derived from the contents of the hierarchical parameter data file; generating a parameter library by a processor, which is based at least partially on the parameter database file; and generating a class definition file by a processor, which is based at least partially 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, wherein the configuration file is based at least partially on the parameter library and the class definition file; and providing the configuration file for the corresponding network function to be implemented 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; populate a parameter database file with a plurality of configuration parameters, wherein at least one of the configuration parameters is derived from the contents of the hierarchical parameter data file; generate a parameter library based at least partially on the parameter database file; and generate a class definition file based at least partially on the parameter database file and / or the hierarchical parameter data file.Generating at least one configuration file corresponding to a network function that interfaces to at least one device of the plurality of devices, wherein the configuration file is based at least partially on the parameter library and the class definition file; and providing the configuration file to the corresponding network function for implementation there. In accordance with 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 for configuring a network for onboarding a plurality of devices. The method comprises receiving a hierarchical parameter data file describing configuration parameters of the plurality of devices; populating a parameter database file with a plurality of configuration parameters by a processor, wherein at least one of the configuration parameters is derived from the contents of the hierarchical parameter data file; and generating a parameter library by a processor that is based at least partially on the parameter database file.by a processor, generating a class definition file based at least partially 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 being based at least partially on the parameter library and the class definition file; and providing the configuration file for the corresponding network function to be implemented therein. Further aspects, details and advantages of the presented system and procedure are partly explained in the following description and illustrations. BRIEF DESCRIPTION OF THE DRAWINGS Features, advantages, and significance of exemplary embodiments of the disclosure are described below with reference to the accompanying drawings, in which identical symbols denote identical elements, and in which: Fig. 1A and Fig. 1B are flowcharts illustrating the sequence 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 representing a sequence 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.Figures 3A-3D are representations 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 Figure 4 is a diagram of the components of one or more devices according to an exemplary embodiment of the present invention. DETAILED DESCRIPTION The following detailed description of exemplary embodiments refers to the accompanying drawings. The same reference numbers in different drawings may denote the same or similar elements. The foregoing disclosure contains illustrations and descriptions, but does not claim to be exhaustive and does not limit the explanations to the exact form disclosed. Modifications and variations are possible in light of the above disclosure or can be acquired from practical implementations. Furthermore, one or more features or components of one embodiment can be integrated into or combined with another embodiment (or one or more features of another embodiment). In addition, one or more operations can be omitted, one or more operations can be added, one or more operations can be performed (at least partially) simultaneously, and the sequence of one or more operations can be changed in the flowcharts and descriptions of operations below. It is clear that the systems and / or methods described here can 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 a limiting factor. Therefore, the operation and behavior of the systems and / or methods have been described here without reference to any specific software code, and software and hardware can be designed to implement the systems and / or methods based on this description. Even if certain combinations of features are listed in the claims and / or the description, these combinations are not intended to limit the disclosure of possible embodiments. In fact, many of these features can be combined in ways not expressly mentioned in the claims and / or disclosed in the description. Although each dependent claim listed below depends directly on only one other claim, the disclosure of possible embodiments includes each dependent claim in combination with every other claim in the claim set. No element, action, or instruction used herein should be considered critical or essential unless expressly designated as such. The articles "a" and "a single one" used herein are meant to include one or more elements and may be used interchangeably with "one or more." When only one article is meant, the term "a" or a similar phrase is used. Likewise, the terms "has," "have," "include," "including," or similar terms used herein are to be understood as open-ended. The phrase "based on" means "based at least in part on" unless expressly stated otherwise. Furthermore, phrases such as "at least one of [A] and [B]" or "at least one of [A] or [B]" are to be understood as including only A, only B, or both A and B. It should be noted that the principles disclosed here are generally applicable to all types of networks, including, but not limited to, Internet service provider networks such as fiber optic and cable networks, traditional telephone networks, and both wired and wireless networks within a structure, complex, or other localized area. However, for the sake of clarity and conciseness, the network analyzed and managed by the system described herein will primarily be referred to as a mobile network. As briefly explained in the background of this revelation, interactions between a network and a hardware vendor or other manufacturer of network equipment require the use of a configuration scheme to negotiate these interactions. When a vendor attempts to "onboard" a network, i.e., establish connection protocols, this scheme must be provided to describe the configuration requirements for the vendor's equipment. (It should be noted that the seller and the manufacturer of a particular device may be the same or different companies, and if they are different, they may handle different aspects of what is described here as the actions of the "seller". However, the distinction between these roles is not relevant for the present disclosure. For the sake of brevity, the seller and the manufacturer are therefore treated here as a single, unified entity, and the terms are used interchangeably.) The schema typically takes the form of a CMDB (Configuration Management Database) file or similar, a telecommunications parameter library derived from the CMDB file, and a JAR (Java Archive) and / or JSON (JavaScript Object Notation) file. By combining the data from these files, a suitable XML file can be automatically generated to describe the interactions between a specific combination of network and manufacturer devices or systems. This XML file is then generated and pushed to each network node or function to configure the interaction protocols for that node. It should also be noted that CMDB, JAR, and YANG files, and various combinations thereof, can also be used to activate other configuration operations. The content and format of each of these files are standardized, ensuring that each of these configuration operations functions correctly. A CMDB file generally describes the configuration of each of a manufacturer's network devices in a database format. The CMDB file must be uniquely created for each manufacturer-network pairing, following a template. This would typically require manually entering a large amount of data into a CMDB generation tool or directly into the template. Such input is time-consuming and tedious. Furthermore, it is prone to errors and requires careful review and frequent correction before any CMDB-based configuration can be implemented. The YANG ("Yet Another Next Generation") modeling language is used to define configuration and status data for network management protocols. YANG uses an XML tree format with numerous data types and can store parameter data in a hierarchy, defining the parameter structure where applicable. A YANG file can also be easily converted to JSON format if this is more convenient for interaction between the network and the vendor. Due to its practicality, many vendors will already have defined and organized aspects of their configuration data in the form of a YANG file. Embodiments of the present invention are based on the previously unrecognized insight that a significant portion of the information required for the CMDB and the JAR files, in particular the relevant XPaths and static parameters, can be trivially derived from the data in a manufacturer's YANG file. If a manufacturer has already prepared a standard YANG file, as is the case with most manufacturers of network-enabled devices, using the data in the YANG file to derive this information can significantly reduce the amount of manual input required to configure the CMDB and JAR files. In certain embodiments, only some, and not all, parameters for the CMDB file are derived from the YANG file. More precisely, in certain embodiments, the values ​​of certain dynamic parameters—parameters defined by the manufacturer and potentially changing between runtimes—are still manually entered via a software tool, such as a suitable graphical user interface, preferably after the values ​​of the other parameters have been 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) required for a standard configuration scheme can be successfully derived from the data in a YANG file without any further input. Furthermore, even when dynamic parameters are required, on average about 70% of the data input into a typical CMDB generation tool can be replaced by automatic conversion from the YANG file, resulting in significant time savings and error reduction. A sequence 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 is now described with reference to Fig. 1A and Fig. 1B according to an embodiment of the invention. At 110, a hierarchical parameter data file is received or retrieved, describing the configuration parameters of a multitude of devices to be connected to a network. Although other parameter data file formats 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 here as the "YANG file"), which will be assumed for the following. The content and format of the YANG file for a hierarchical parameter data file can conform to standard YANG file structures. The devices can be organized according to device models, assuming that the same general configuration parameters apply to all devices of the same model. Other organizational groupings of the devices, including treating all devices as having individual parameters, are also possible and within the scope of the invention. At step 120, a parameter database file is generated and populated with a multitude of configuration parameters in database format. Although other parameter database file formats also fall within the scope of the invention, a CMDB file is used in the present embodiment, which will be assumed hereafter for the sake of simplicity. The content and format of a CMDB file can conform to standard CMDB file structures. More precisely, in the illustrated embodiment, at 121 the parameters for populating the database file are derived from the content of the YANG file, and at 125 the CMDB file is populated with the parameters. In the embodiment shown, it is assumed that each configuration parameter added to the CMDB file is derived from the contents of the YANG file, although, as noted below, particularly with reference to Fig. 1B, this is not a requirement of the invention. In section 130, a telecommunications parameter library is created based on the content of the CMDB file and, in certain embodiments and configurations, additionally on other stored or directly provided data. The parameter library preferably has a format comparable to that of the CMDB file, and methods and tools for generating 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 all data that can be extracted from the library file is referenced directly to the CMDB file. However, in other embodiments, a library file is prepared because this file format is easier to reference when a user or an automated system wants to check the values ​​of a specific parameter. It should be noted that operations 120 and 130 can be combined in certain embodiments, with the required content of the YANG file being directly converted into the parameter library format. However, the embodiment shown utilizes existing methods for preparing a parameter library based on the CMDB file and therefore uses the CMDB file as an intermediary. Furthermore, it is more convenient to integrate additional data provided as input during the creation of the CMDB file than at other stages. As mentioned below, particularly with reference to Fig. 1B, such additional data is sometimes necessary. In section 140, a class definition file is created. Although other class definition file formats also fall within the scope of the invention, a JAR file is currently preferred and will be assumed for simplicity in the following. The content and format of the JAR file for a class definition file can conform to the standard structures of a JAR file. In the embodiment shown in Fig. 1A, the content of the JAR file is derived from the content of the YANG file and, in certain embodiments and configurations, is also based on other stored or directly provided data. This derivation is similar to that of the content of the CMDB file, particularly for content that is identical except for the file format. In the embodiment shown in Fig. 1A, operation 140 is executed simultaneously with operations 120 and 130 to save time. If simultaneous execution is not possible due to hardware limitations or other reasons, operation 140 can be executed either before or after operations 120 and 130. At step 150, the connection parameters for a specific network function, network node, or similar are configured. This process is known in the industry as "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 subsequent operations. Specifically, in section 151, the network function or network node and its properties are identified. In particular, an XPath or similar is preferably specified. At point 153, a configuration file for the network node is generated. Although other configuration file formats also fall within the scope of the invention, an XML file is currently preferred and will be assumed hereafter for simplicity. The configuration file is based on the contents of the parameter library and the 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 provided XPath. If the class definition file is a JAR file, it can be converted to an XML file, with the necessary XPath-related data being extracted from the parameter library and added. The content and format of the XML file for a configuration file can conform to standard XML file structures. In version 155, the configuration file is "pushed" or otherwise made available to the network node. In different network implementations, this can involve transmission to the individual devices of the network node, to the network node or network element itself, or to an element management system (EMS) that manages the node or element. Operation 150 can 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 these devices were described in the original YANG file. It can be assumed that a complete YANG file for a given manufacturer describes all devices manufactured by that manufacturer. As already mentioned, the embodiment shown in Fig. 1A assumes that all parameters relevant for the configuration, and therefore first added 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, if all relevant parameters are not dynamic but static, since at least some embodiments of the invention are able to derive any possible static parameter from a YANG file that is complete and properly formatted according to the standardized YANG file formats. However, if dynamic parameters are required and these dynamic parameters cannot be fully derived from the YANG file, the process flow must be modified. In such a modification, illustrated in Fig. 1B, operation 120 is changed to 120'. Within operation 120', parameters are still derived in 121', but not all of the 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 to the derived CMDB file parameters at 125'. Alternatively, sufficient additional data is provided at 123 to allow the missing dynamic parameters to be derived from this additional data in combination with the data in the YANG file. Furthermore, 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 sufficient data to generate the JAR file due to the direct provision of the additional data at 123. The approach shown in Fig. 1B can also be implemented if there are no relevant dynamic parameters, since for certain combinations of parameters in the CMDB and JAR files it may be more advantageous to derive or copy one from the other than to derive both directly from the YANG file. A clear functional flowchart of the interactions between systems during a process for configuring network functions on the primary basis of a YANG file or another hierarchical parameter data file is now described with reference to Fig. 2, according to an embodiment of the invention. In the embodiment shown, the systems include a network orchestrator 10. The orchestrator 10 is the primary control device for the operations described above, among others. Using the orchestrator 10, and in particular one or more interfaces provided via the orchestrator 10, an agent of a network operator can configure aspects of the network by triggering processes in the other systems. For the purposes of this disclosure, it is not relevant whether the network orchestrator 10 operates automatically and, if not, who operates it and how. If a representative of the network operator operates the network orchestrator 10 to perform an action, this is described in the disclosure, for the sake of brevity, as if the network orchestrator 10 were performing the action. In the illustrated embodiment, the systems comprise a network infrastructure platform 20. The platform 20 preferably performs the various operations described above in response to the actuation of the orchestrator 10. It should be noted that certain embodiments combine the orchestrator 10 and the platform 20 in a single system. However, due to network configurations, it is often more advantageous for the platform 20 to be a server controlled by a remote terminal implementing the orchestrator 10. In the illustrated embodiment, the systems comprise a file storage system 30. This can be a server or cloud-based storage. A preferred implementation is a MinIO cloud storage system, although the invention is not limited to this. The provider stores its YANG file (or another hierarchical parameter data file) on the file storage system 30 for access by the network operator and, typically, by other parties as well. The file storage system 30 can be wholly or partially under the control of the provider or the network operator, as long as both have sufficient access for their respective operations described below. In certain embodiments, the file storage system 30 is integrated into the infrastructure platform 20 or into a provider system 40 (see below). In the illustrated embodiment, the systems comprise a vendor or manufacturer system 40. The vendor system 40 is the primary control device for operations initiated by representatives of the vendor or manufacturer. Figure 2 shows only one such operation interacting with the file storage system 30, and in embodiments where this is an expected degree of simplicity, the vendor system 40 is preferably a remote interface to the file storage system 30 running on any suitable device. For the purposes of this disclosure, it is not relevant whether the vendor system 40 operates automatically and, if not, who operates it and how. If a representative of the vendor operates the vendor system 40 to perform an action, this is described in the disclosure, for the sake of brevity, as if the vendor system 40 itself performs the action. In the illustrated embodiment, the systems comprise at least one network function or network node 50. The network node 50 manages a network element of a physical device or a group of physical devices with similar network characteristics. Due to these similar characteristics, the devices can be managed in the same or a similar way using the same configuration file. In the illustrated embodiment, it is assumed that all devices managed by the network node 50 are products of the manufacturer. In scenario 201, the vendor system 40 stores a YANG file in the file storage system 30 (e.g., by uploading it). The file is stored at a specific address designated for storing YANG files for that vendor. This could be a general storage location used by the vendor to make the YANG file available to anyone who needs it, or a location specific to the network operator, with uploading being part of the vendor's application to join 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. Platform 20 uses this address to request the YANG file at 205 from the file storage system 30, which provides it at 207. At step 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 can be provided by the Orchestrator 10 when required due to the execution of Operation 123 of Fig. 1B or similar operations. For example, at 211, the Orchestrator activates a system to provide all necessary data. The platform 20 responds at 213 by requesting information about the dynamic parameters, which in certain embodiments is done via a GET command. The Orchestrator 10 provides the required values ​​at 215, which in certain embodiments is done via a SET command. These values ​​can be retrieved, in particular, from another module or database, such as an IP Address Manager (IPAM) module. In section 217, Orchestrator 10 optionally requests the derived configuration data in the parameter library for local storage or other purposes. In particular, Orchestrator 10 preferably requests the static parameters that are not based on any of the inputs provided in section 215. Platform 20 fulfills this requirement in section 219 by providing the requested data, which in certain embodiments is done by a COPY command. At step 221, Orchestrator 10 initiates a configuration "push" for a specific network node, namely network node 50 in the example shown. At step 223, platform 20 responds by generating the XML file for network node 50, for example, according to step 153 of Fig. 1A. And at step 225, the XML file is transferred to network node 50 for its configuration or otherwise "push" it, for example, according to step 155 of Fig. 1A. Illustrative examples of GUI pages for configuring a network based primarily on a YANG file or another hierarchical parameter data file are now described with reference to Figures 3A-3D. It should be noted that these examples are in no way controlling, as a variety of suitable interfaces are possible for the disclosed invention, but merely serve as an illustrative example of how such an interface could be implemented and operated in practice. A general administration page of the graphical user interface, shown in Fig. 3A, provides a list of configuration schemes. This list includes all schemes that have been fully generated or are in the generation process. The parameters included in the list in this example are: a status indicating whether the generation ("creation") of the CMDB, library, or JAR is currently in progress, has not yet started, or is complete (as the expected final stage of scheme generation); the scheme name; the vendor or manufacturer associated with the scheme; a domain for the scheme, such as "RAN" (Radio Access Network); an applicable version of the generated scheme; and a network technology, such as LTE or 5G. In the illustrative example, the controls are displayed in the upper right corner of the page. In particular, there is a control 321, "Add Schema". Activating control 321 causes the graphical user interface to open another page, as shown in Fig. 3B. A schema identification page, shown in Fig. 3B, provides controls to supply identification information for the schema being added. In the example shown, the information provided includes a name for the schema and its corresponding domain, the vendor or manufacturer, the technology, and the version. This information appears in the list on the general administration page of the graphical user interface in Fig. 3A once schema creation begins. Various suitable selection forms and other data entry means for each piece of information are well-known in the art and need not be explained in detail. Once all the information has been entered, the user can proceed to another GUI page, as shown in Fig. 3C. The upload page shown in Fig. 3C provides a means for uploading a YANG file or another hierarchical parameter data file. In the example shown, the file for upload can be selected either by drag and drop from a file folder view or by opening a file browser. Other upload interfaces are well-known in the art and do not require further explanation. Once the upload is complete, the user can switch to another GUI page, as shown in Fig. 3D. A preview page, shown in Fig. 3D, displays the information provided on the schema identification page of Fig. 3B, as well as information related to or extracted from the YANG file uploaded via the upload page of Fig. 3C, for review. If the information is satisfactory to the user, they can confirm the submission. The system then returns to the general management GUI page of Fig. 3A. Optionally, a confirmation message appears indicating that the addition was successful. A schema is shown in Fig. 3A under 330, with status 331 "uploaded," indicating that a YANG file has been uploaded, but the generation of the other files has not yet begun. When the row in the list for the YANG file is selected or highlighted, controls 333, 335, and 337 appear and can be activated. The JAR generation control 333 activates the complete generation of a schema, including the CMDB file, parameter library, and JAR file. The CMDB generation control 335 triggers only the generation of the CMDB file and the parameter library, leaving the JAR stage for a later time. The delete control 337 deletes schema 330 from list 310. In certain embodiments, the JAR generation controller 333 only initiates the generation of the JAR file. If the system determines that dynamic parameters not derivable from the YANG file are required for configuration, the JAR generation controller 333 is deactivated until the generation of the CMDB file and parameter library is complete, allowing the procedure shown in Fig. 1B, or a similar procedure, to be completed sequentially. When the system determines that all required parameters can be derived from the YANG file, the JAR generation controller 333 is activated and can be operated before or after the activation of the CMDB generation controller 335. Fig. 4 is a diagram of the components of one or more devices according to one embodiment. The device 400 can correspond to any of the computer 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 procedure, and a memory containing any described data storage. As shown in Fig. 4, the device 400 can comprise 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 is understood that one or more of the components can be omitted and / or one or more additional components can be included. The bus 410 comprises a component that enables communication between the components of the 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. The process 420 comprises one or more processors that can be programmed to perform a function. The memory 430 comprises 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 relating to the operation and use of the device 400. The storage component 440 may, for example, include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, and / or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cassette, a magnetic tape, and / or another type of non-transferable, computer-readable medium, together with a suitable drive. The input component 450 comprises a component that enables the device 400 to receive information, e.g., via user input (e.g., a touchscreen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone). The input component 450 may include a sensor for acquiring information (e.g., a GPS (Global Positioning System) 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)). The communication interface 470 comprises a transceiver-like component (e.g., a transceiver and / or a separate receiver and transmitter) that enables the device 400 to communicate with other devices, for example, via a wired connection, a wireless connection, or a combination of wired and wireless connections. The communication interface 470 can enable the device 400 to receive information from another device and / or provide information to another device. The communication interface 470 can include, for example, an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency interface, a USB (Universal Serial Bus) interface, a Wi-Fi interface, a cellular interface, or similar interfaces. The device 400 can perform one or more of the processes described herein. The device 400 can perform operations based on the processor 420, which executes software instructions stored in a non-transient, computer-readable medium, such as the memory 430 and / or the memory component 440. A computer-readable medium is defined here as a non-transient storage device. A storage device comprises storage space within a single physical storage device or storage space distributed across multiple physical storage devices. Software instructions can be read into memory 430 and / or memory component 440 from another computer-readable medium or device via the communication interface 470. During execution, the software instructions stored in memory 430 and / or memory component 440 can cause the processor 420 to perform one or more processes described herein. Additionally or alternatively, hardwired circuits can be used instead of, or in combination with, software instructions to perform one or more of the processes described herein. Therefore, the embodiments described here are not limited to a specific combination of hardware circuits and software. The foregoing disclosure serves for illustration and description, but makes no claim to completeness and does not limit the explanations to the exact form disclosed. Modifications and variations are possible in light of the above disclosure or can be acquired from practical implementations. Some embodiments may refer to a system, a method, and / or a computer-readable medium at any possible level of technical detail of integration. Furthermore, one or more of the components described above may be implemented as instructions stored on a computer-readable medium that can be executed by (and / or contain) at least one processor. The computer-readable medium may comprise a computer-readable non-transitory storage medium (or media) containing computer-readable program instructions to instruct a processor to perform operations. The computer-readable storage medium can be a tangible device capable of storing and holding instructions for use by an instruction-executing device. For example, the computer-readable storage medium can be, 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 floppy disk, a hard disk, random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random-access memory (SRAM), a portable compact disc read-only storage device (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically coded device such as punched cards or raised structures in a groove with instructions recorded thereon, and any suitable combination of the foregoing. A computer-readable storage medium, as used here, is not to be understood as consisting of 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., a waveguide).Light pulses traveling through a fiber optic cable), or electrical signals transmitted through a wire. The computer-readable program instructions described here can be downloaded from a computer-readable storage medium to the respective computing / processing devices or to an external computer or 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 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 them for storage on a computer-readable storage medium within the respective computer / processing device.The computer-readable program code / instructions for executing operations can be assembly instructions, ISA (Instruction Set Architecture) 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 object-oriented programming languages ​​such as Smalltalk, C++, and similar languages, and procedural programming languages ​​such as C or similar. The computer-readable program instructions can be executed 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 the remote computer or server.In the latter case, the remote computer can 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 can 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 (FPGAs), or programmable logic arrays (PLAs), can execute the computer-readable program instructions by using state information from the computer-readable program instructions to personalize the electronic circuits to perform specific aspects or operations. These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or any other programmable data processing device to create a machine such that the instructions executed through the processor of the computer or other programmable data processing device provide means for implementing the functions / actions specified in the flowchart and / or block diagram.These computer-readable program instructions can also be stored in a computer-readable storage medium that can instruct a computer, a programmable data processing device and / or other devices to function in a certain manner, such that the computer-readable storage medium with the instructions stored therein comprises a manufactured item containing instructions that implement aspects of the function / action specified in the flowchart and / or block diagram block or blocks. The computer-readable program instructions can also be loaded onto a computer, other programmable data processing device, or other device to initiate a series of operational steps that are executed on the computer, other programmable device, or other device to produce a computer-implemented process, such that the instructions executed on the computer, other programmable device, or other device implement the functions / actions 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, procedures, and computer-readable media according to various embodiments. In this context, each block in the flowchart or block diagrams can represent a module, segment, or part of instructions that includes one or more executable instructions for implementing the specified logical function(s). The procedure, computer system, and computer-readable medium may contain additional blocks, fewer blocks, different blocks, or blocks arranged differently than those shown in the figures. In some alternative implementations, the functions specified in the blocks may occur in a different order than shown in the figures. For example,Two blocks shown consecutively are not actually executed simultaneously or substantially simultaneously, or the blocks may sometimes be executed in 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, can be implemented by special hardware-based systems that perform the specified functions or actions, or execute combinations of special hardware and computer instructions. It is clear that the systems and / or methods described here can 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 a limiting factor. Therefore, the operation and behavior of the systems and / or methods have been described here without reference to any specific software code, and software and hardware can be designed to implement the systems and / or methods based on this description.

Claims

A method for configuring a network to integrate a plurality of devices, comprising: receiving a hierarchical parameter data file describing the configuration parameters of the plurality of devices; by a processor, populating a parameter database file with a plurality of configuration parameters, wherein at least one of the configuration parameters is derived from the contents of the hierarchical parameter data file; by a processor, generating a parameter library at least partially based on the parameter database file; by a processor, generating a class definition file based at least partially 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 provides an interface to at least one device of the plurality of devices, wherein the configuration file is based at least partially on the parameter library and the class definition file; and providing the configuration file to the corresponding network function so that it can be implemented there. Method according to claim 1, wherein each static configuration parameter contained in the parameter database file is derived from the contents of the hierarchical parameter data file. Method according to claim 1, wherein the hierarchical parameter data file is formatted according to the Yet Another Next Generation (YANG) modeling language. Method according to claim 1, wherein the parameter database file is a configuration management database (CMDB). Method according to claim 1, wherein the class definition file is a Java archive file (JAR). Method according to claim 1, wherein the configuration file is an XML (Extensible Markup) file. A system for configuring a network to integrate a multitude of devices, the system comprising a processor that executes software instructions to: receive a hierarchical parameter data file describing the configuration parameters of the multitude of devices; populate a parameter database file with a multitude of configuration parameters, wherein at least one of the configuration parameters is derived from the contents of the hierarchical parameter data file; create a parameter library at least partially based on the parameter database file; generate a class definition file at least partially based on the parameter database file and / or the hierarchical parameter data file;to generate at least one configuration file corresponding to a network function that provides an interface to at least one device of the multitude of devices, wherein the configuration file is based at least partially on the parameter library and the class definition file; and to make the configuration file available to the corresponding network function so that it can be implemented there. System according to claim 7, wherein each static configuration parameter contained in the parameter database file is derived from the contents of the hierarchical parameter data file. System according to claim 7, wherein the hierarchical parameter data file is formatted according to the Yet Another Next Generation (YANG) modeling language. System according to claim 7, wherein the parameter database file is a Configuration Management Database (CMDB) file. System according to claim 7, wherein the class definition file is a Java archive file (JAR). System according to claim 7, wherein the configuration file is an XML (Extensible Markup) file. A non-transitory, computer-readable recording medium on which instructions are recorded that can be executed by at least one processor to perform a method for 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; populating a parameter database file with a plurality of configuration parameters, wherein at least one of the configuration parameters is derived from the contents of the hierarchical parameter data file; generating a parameter library based at least partially on the parameter database file; generating a class definition file based at least partially on the parameter database file and / or the hierarchical parameter data file;Generating at least one configuration file corresponding to a network function that provides an interface to at least one device of the plurality of devices, wherein the configuration file is based at least partially on the parameter library and the class definition file; and providing the configuration file for the corresponding network function so that it can be implemented there. Recording medium according to claim 13, wherein each static configuration parameter contained in the parameter database file is derived from the contents of the hierarchical parameter data file. Recording medium according to claim 13, wherein the hierarchical parameter data file is formatted according to the Yet Another Next Generation (YANG) modeling language. Recording medium according to claim 13, wherein the parameter database file is a Configuration Management Database (CMDB) file. Recording medium according to claim 13, wherein the class definition file is a Java archive file (JAR). Recording medium according to claim 13, wherein the configuration file is an XML (Extensible Markup) file.

Images