A method and device for dynamic extension of a network element configuration model

Abstract

The present application relates to the field of network equipment management, and particularly relates to a method and device for dynamic extension of a network element configuration model. Mainly comprising: obtaining a metadata model, the metadata model being used to describe the network element configuration model; defining an extension field structure, reserving an extension field in the metadata model using the extension field structure, and using a corresponding extension field in the network element configuration model; generating conversion code between different network element configuration data models based on the network element configuration model through a code compiling process according to the metadata model, the conversion code being used to convert data between the extended data models; and extending in the extension field of the network element configuration model when the network element configuration data model needs to be extended. The present application can contain all different device configuration block extensions in the extension field, and can use the conversion code for conversion, without additional configuration on the network management side.

Description

Technical Field

[0001] This invention relates to the field of network device management, and in particular to a method and apparatus for dynamically expanding a network element configuration model. Background Technology

[0002] In telecommunications transmission networks, each transmission device is referred to as a network element in network management software. The network management software performs service configuration by managing the network element configuration corresponding to the device configuration block on the network element.

[0003] With the rapid development of 5G technology, network scale is increasing, and the types of devices on the network are also increasing. At the same time, with the development and iteration of new requirements for equipment products, when new service configuration parameters and fields are added to the device configuration block, the network management software also needs to add corresponding parameters and fields for interface display and service configuration.

[0004] For network management software, the network element configuration subsystem is a large subsystem. It manages a wide variety of devices. It needs to abstract a common network element configuration model from a large number of devices to develop a general program flow and reduce development and maintenance costs; at the same time, it needs to reflect the subtle differences between devices from the general model to adapt to the customized development needs of each device.

[0005] Based on the above, existing technical methods have the following main problems:

[0006] 1. The network management software manages various types of network elements, each corresponding to the actual devices it manages, and manages multiple device configuration blocks. Each device configuration block requires a corresponding network element configuration model defined within the network management software. For the same configuration block, devices within the same major category exhibit consistency or similarity; therefore, a universal model needs to be defined for unified management to simplify the development process and reduce workload.

[0007] 2. For the same network element configuration model, different devices may have slight differences. Therefore, the general model can only fully describe the same configuration block of each device through the union of sets, and cannot describe the differences between device types.

[0008] 3. A general platform developed based on the fixed general model defined in 1 means that when the configuration block of a single device needs to be extended on the device product side, the abstract model of this configuration block on the platform side must be modified synchronously, making it impossible to dynamically extend the model without modifying the platform.

[0009] 4. Modifications to the general model, as well as its development and compilation process, will also affect other products that use this general model, and cannot support the independent evolution of individual device versions.

[0010] Therefore, how to overcome the shortcomings of existing technologies and solve the problem that existing network element configuration models are not easy to expand and modify is a problem to be solved in this technical field. Summary of the Invention

[0011] In view of the above-mentioned defects or improvement needs of the existing technology, the present invention solves the problem that the existing network element configuration model is not easy to expand and modify.

[0012] The embodiments of the present invention adopt the following technical solutions:

[0013] In a first aspect, the present invention provides a method for dynamically expanding a network element configuration model, specifically comprising: obtaining a metadata model, the metadata model being used to describe the network element configuration model; defining an extension field structure, reserving extension fields in the metadata model using the extension field structure, and using the corresponding extension fields in the network element configuration model; generating conversion code between models of different network element configuration data based on the network element configuration model through a code compilation process according to the metadata model, the conversion code being used to perform data conversion between the expanded data models; and expanding the network element configuration data model in the extension fields of the network element configuration model when the model needs to be expanded.

[0014] Preferably, the acquisition of the metadata model specifically includes: acquiring the network element configuration data to be used; defining the metadata model based on the network element configuration data, wherein the metadata model can derive models of each network element configuration data; and generating and / or converting the metadata model based on the correspondence between the network element configuration data and the metadata model.

[0015] Preferably, the definition of the extended field structure and the reservation of extended fields in the metadata model using the extended field structure specifically include: using a general type container as the extended type of the extended field structure, wherein the general type container is used to represent different types of network element configuration data; reserving fields of the extended type in the metadata model as reserved extended fields in the metadata model.

[0016] Preferably, the step of generating conversion code between different data models based on the network element configuration model through the code compilation process specifically includes: calling the parsing file of the metadata model to generate the code of the network element configuration model;

[0017] Configure the model of each network element configuration data according to the metadata model in the network element configuration model, and generate corresponding conversion code according to the model of each network element configuration data.

[0018] Preferably, when the model of the network element configuration data is a network element configuration display model, the step of generating corresponding conversion code according to the model of each network element configuration data specifically includes: traversing all composite type tags, obtaining the attributes related to the network element configuration display model in the composite type tags; and generating implementation code corresponding to the current network management programming language according to the attribute structure of the network element configuration display model.

[0019] Preferably, when the model of the network element configuration data is a network element configuration memory model, the step of generating corresponding conversion code based on the model of each network element configuration data specifically includes: traversing all composite type tags and obtaining the device type-related attributes in the composite type tags; generating implementation code corresponding to the current network management programming language based on the attributes of different device types.

[0020] Preferably, when the model of the network element configuration data is the network element configuration storage model, the step of generating corresponding conversion code according to the model of each network element configuration data specifically includes: traversing all composite type tags and obtaining the pb protocol-related attributes in the composite type tags; generating implementation code corresponding to the current network management programming language according to the pb protocol attributes.

[0021] Preferably, the data conversion between the extended data models using conversion code specifically includes: for basic type fields in the network element configuration storage model, directly assigning values ​​based on the network element configuration data; for array fields in the network element configuration, traversing all arrays in the network element configuration storage model and sequentially inserting the obtained values ​​into the corresponding arrays after conversion; for extended fields in the network element configuration, traversing the extended field structure in the network element configuration storage model and sequentially inserting the obtained key-value pairs into the extended fields after conversion based on the key-value pairs of the extended fields.

[0022] Preferably, the expansion through extended fields of the network element configuration model specifically includes: when the network element configuration model is a network element configuration memory model, dynamically expanding the fields in the network element configuration memory model and assigning values ​​to the dynamically expanded fields; when the network element configuration model is a network element configuration storage model, obtaining the extended fields in the network element configuration storage model; and when the network element configuration model is a network element configuration interface display model, obtaining the extended fields in the network element configuration interface display model.

[0023] On the other hand, the present invention provides an apparatus for dynamically expanding a network element configuration model, specifically comprising at least one processor and a memory, wherein the at least one processor and the memory are connected via a data bus, the memory stores instructions that can be executed by the at least one processor, and the instructions, after being executed by the processor, are used to complete the method for dynamically expanding the network element configuration model in the first aspect.

[0024] Compared with existing technologies, the beneficial effects of this invention are as follows: Extended fields are reserved in the metadata model, and the network element configuration model is described using a metadata model with reserved extended fields. This allows a universal network element configuration model to describe the different configurations of all device configuration blocks, enabling network management software to independently develop configuration systems containing extended fields within similar network management products without modifying the universal network management configuration model. This has no impact on the development of other products, improving the efficiency of parallel product development and release. Furthermore, by using the extended network element configuration model, the extensions of all different device configuration blocks are included in the extended fields and can be converted using conversion code without additional configuration on the network management side. Therefore, the solution in this embodiment can extend the metadata model on the device product side and automatically support features such as rule constraints and validity verification of extended fields, reducing development workload. Attached Figure Description

[0025] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly described below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0026] Figure 1 A flowchart illustrating a method for dynamically expanding a network element configuration model, as provided in an embodiment of the present invention;

[0027] Figure 2 Flowchart of another method for dynamically expanding a network element configuration model provided in an embodiment of the present invention;

[0028] Figure 3 Flowchart of another method for dynamically expanding a network element configuration model provided in an embodiment of the present invention;

[0029] Figure 4 Flowchart of another method for dynamically expanding a network element configuration model provided in an embodiment of the present invention;

[0030] Figure 5 A schematic diagram of a device structure for dynamically expanding a network element configuration model, provided in an embodiment of the present invention;

[0031] Figure 6 A schematic diagram of the functional modules of the processor 11 in a device for dynamically expanding a network element configuration model according to an embodiment of the present invention;

[0032] The reference numerals in the attached figures are as follows:

[0033] 11: Processor; 12: Memory. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0035] This invention is an architecture of a specific functional system. Therefore, the specific embodiments mainly describe the functional logic relationship of each structural module, and do not limit the specific software and hardware implementation methods.

[0036] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0037] Example 1:

[0038] When managing the configuration of large-scale network element devices, a unified network element configuration model is usually used to exchange configuration data. In order to meet the configuration requirements of different network element devices, the unified network element configuration model needs to be dynamically expanded.

[0039] like Figure 1 As shown, the specific steps of the method for dynamically expanding the network element configuration model provided in this embodiment of the invention are as follows:

[0040] Step 101: Obtain the metadata model, which is used to describe the network element configuration model.

[0041] A network element configuration model corresponds to a configuration block on a device, which defines the parameters or attribute configurations required for a service function. Therefore, the fields of a network element configuration model and the protocol fields of the device configuration block should have a one-to-one relationship. However, in network management software, based on different software architecture layers, the same network element configuration model may contain different models at different implementation levels of the network management software, such as: a network element configuration interface display model, a network element configuration memory model, and a network element configuration database storage model.

[0042] To dynamically expand the network element configuration model, this embodiment defines a metadata model for network element configuration, which describes attributes such as the common name and display name of a single network element configuration. Simultaneously, the metadata model also defines a list of fields included in the corresponding network element configuration model, containing information such as the type, name, and index value of each field. In existing technologies, a different network element configuration model needs to be defined in the network management software for each device configuration block. In the method provided in this embodiment, using the metadata model of network element configuration, specific and consistent network element configuration models can be generated based on the different usage levels of the network element configuration in the network management software and the technology or language used. It also enables conversion logic code between different levels of models. Combined with a framework code implementation of a general process, this ensures that the entire process code for the network management software interface, network management software backend, and inter-device interaction is as universal as possible across different levels of reading and distribution processes for different network element configurations, significantly reducing the amount of code written related to model or data conversion.

[0043] Step 102: Define the extended field structure, reserve extended fields in the metadata model using the extended field structure, and use the corresponding extended fields in the network element configuration model.

[0044] In existing technologies, a single network element configuration model cannot describe the subtle differences between different devices. In this embodiment, the network element configuration model is extended by extending the metadata model. Besides containing existing network element configurations, the metadata model also reserves extended fields. These extended fields can be used to extend the metadata model, thereby expanding the network element configuration model to describe the subtle differences between different devices. Furthermore, in practical implementation, to meet as many potential extension needs as possible, extended fields can use general-type extensions to be compatible with more configuration data types. For example, in a specific scenario, the metadata model is defined using an Extensible Markup Language SchemaDefinition (XSD) file. In this scenario, the extended field structure can be defined using the composite type ExtField defined in XSD and used as a reserved extended field in the metadata model. In practical implementation, this extended field structure can be used as a dynamic extended field, extending one or more configuration attributes as needed, or not using the field for extension. Different usage methods will not affect the structure of the metadata model or the use of the existing network management system.

[0045] Step 103: Based on the metadata model, generate conversion code between different network element configuration data based on the network element configuration model through the code compilation process. The conversion code is used to perform data conversion between the expanded data models.

[0046] Because the network element configuration model in this embodiment is described using a metadata model, and this metadata model includes reserved extended fields, unlike the fixed network element configuration models used in the prior art, the network element configuration model in this embodiment, after code compilation, can also include extended fields in the generated data model. At different software architecture levels, through the code compilation process, dynamically expandable network element configuration interface display models, network element configuration memory models, network element configuration database storage models, and conversion code between other types of models can be automatically generated based on the metadata model.

[0047] Step 104: When the network element configuration data model needs to be expanded, expand it in the expansion field of the network element configuration model.

[0048] By introducing extended fields into the network element configuration model through the metadata model and obtaining the conversion code corresponding to the network element configuration data models used at different software architecture levels, the expansion of the network element configuration data model can be completed through the conversion code. In the prior art, when the network element configuration model needs to be modified, the network management software also needs to be modified accordingly. In this embodiment, in the network management software framework that uses and embeds the implementation of the network element configuration model, it is only necessary to add and assign values ​​to the extended fields of the network element configuration model to automatically realize the dynamic expansion of the data model of network element configuration at each level. Between different software architecture levels, the network element configuration model can still be regarded as a whole for data transfer and interaction without changing the existing network management product.

[0049] After steps 101-104 provided in this embodiment, the dynamic expansion of the network element configuration model can be achieved.

[0050] In practical implementation, the specific data structure and data type of the metadata model can be determined according to the actual usage of network element configuration. The following provides an example of defining a metadata model for network element configuration using an XSD file. In this example, the metadata model can also be used to derive models of network element configuration data at various software architecture levels, including: defining the network element configuration interface display model using the ZeroICE model; defining the network element configuration memory model using classes in specific network management implementation languages ​​such as JAVA and C++; and defining the network element configuration storage model using Google Protobuf protocol files. For simplicity, the model of network element configuration data will be referred to as the data model below. It is understood that the following examples are only used to demonstrate the implementation process and effects of this solution and do not imply any limitation on the scope of protection of this solution. In actual implementation, the following process can be used as a reference to complete the specific implementation in the corresponding scenario, or other implementation methods can be selected based on the existing data structure of the network management software.

[0051] like Figure 2As shown, the metadata model corresponding to the device configuration block can be obtained through the following process.

[0052] Step 201: Obtain the network element configuration data to be used, and define the metadata model based on the network element configuration data. The metadata model can derive the model of each network element configuration data.

[0053] The data types used in the metadata model can include fields of system basic types such as int, bool, and string, as well as complex type fields composed of multiple basic types. In XSD, a composite type is named and defined using the `<complextype>` tag. The `<element>` tag describes the fields contained within this composite type. The `<element>` tag defines the name, type, index, and other field information of each individual field. In practice, the field types defined in `<element>` can be basic types or other composite types. When a field type is a composite type, it must also be defined using the `<complextype>` tag before use.

[0054] To facilitate use in network element configuration models, composite types, in addition to defining their contained field information, also associate these types with other generated types, such as the Zero ICE model, classes in specific network management implementation languages ​​like Java and C++, and Google Protobuf protocol files. For example, in the attributes of the `complextype` tag, `deviceclass=""` associates with classes in specific network management implementation languages ​​like Java and C++, `w:iceout=""` associates with the Zero ICE model, and `w:pbout=""` associates with the Google Protobuf protocol file.

[0055] After using a composite type metadata model, the network element configuration metadata model can be regarded as a special composite type.

[0056] Step 202: Based on the correspondence between network element configuration data and metadata model, complete the generation and / or conversion of metadata model.

[0057] After obtaining the correspondence between the metadata model and the network element configuration data, the network element configuration data can be converted into a composite type data structure of the metadata model based on the correspondence and the data structure of the metadata model. In a practical scenario, corresponding to the metadata model defined in the XSD file, Extensible Stylesheet Language Transformations (XSLT) files are used to implement the logic code for generating and converting the XSD metadata model. In the XSLT file, by traversing all complextype tags, the name and other information contained in a single composite type are parsed and obtained. By traversing all element tags contained in the composite type, all field information included in the composite type is parsed and obtained.

[0058] After steps 201-202 provided in this embodiment, the required metadata model can be obtained.

[0059] After obtaining the metadata model, it is also necessary to use, such as Figure 3 The method shown defines an extended field structure and uses this structure to reserve extended fields in the metadata model.

[0060] Step 301: Use a generic type container as the extended type of the extended field structure, where the generic type container is used to represent different types of network element configuration data.

[0061] In practice, the required extended types can be determined based on the data structure of the metadata model. In a certain scenario, XSD's extended types can be used as the data type for extended field structures. An extended type is a composite type defined in XSD, named ExtField. ExtField describes the structure of an extended field; this structure is a container for a general type that can hold basic types, consisting of a key, field type, and field value. The key is a unique identifier when the extended field is defined; it is used to locate the specified extended field when assigning or using it. The field type only supports basic types or arrays of certain basic types. Field values ​​are uniformly stored as strings; when representing array types, a delimiter is used to serialize the values ​​of all elements in the array into a single string.

[0062] In this scenario, extended fields can be defined as follows:

[0063] <complextype name="ExtField" displayname="扩展字段" w:iceseq="" w:iceseqitem="ExtFieldIce" w:icemapkey="string" w:icemaptopbveckeyname="ItemKey">

[0064] <sequence>

[0065] <element displayName="结构关键字" name="ItemKey" typeName="string" / >

[0066] <element displayName="字段类型" name="FieldType" typeName="FieldTypeIce" w:iceout="common" / >

[0067] <element displayName="字段值" name="Value" typeName="string" / >

[0068] < / sequence>

[0069] < / complextype> .

[0070] For example, if the current extended field represents an IP field, the keyword can be defined as "ip.addr", the field type is FT_STRING in FieldTypeIce, and the field value is represented as the string "10.10.10.10". It is evident that by extending fields, dynamic expansion of different types of configuration data can be achieved.

[0071] Furthermore, to facilitate the management of multiple extended types, a general structure group, implemented using a hashmap, can be defined on top of the extended types that can accommodate common structures such as types and values ​​of basic types. The general structure group uses the key of a single extended field as the key and the entire object of that extended field as the value to construct the corresponding extended field key, i.e., the extended field combination.

[0072] For example, the IP field, as an extended field, can be considered as an extended field object within the general structure group with a key "ip.addr", a value defined as "ip.addr", a field type of FT_STRING in FieldTypeIce, and a value represented as the string "10.10.10.10". When assigning a value to the IP field, the key "ip.addr" is used to search for this extended field key-value pair in the general structure group. The value from this key-value pair is then retrieved as the extended field to be assigned. Based on the FT_STRING property of the field type, the string "10.10.10.10" is directly assigned to the extended field value. Similarly, when retrieving the IP field, the key "ip.addr" is used to search for this extended field key-value pair in the general structure group. The value from this key-value pair is then retrieved as the extended field to be found. Based on the FT_STRING property of the field type, the string "10.10.10.10" is directly retrieved.

[0073] Step 302: Reserve a field of extended type in the metadata model as a reserved extended field in the metadata model.

[0074] Based on the general structure group, this general structure group can be used in the metadata model as a reserved dynamic library extension field in the network element configuration metadata model. The metadata model only provides an extension mechanism—that is, a mechanism to define the general structure group and reserve dynamic library extension fields—but it is not actually used. Actual use occurs in the network element configuration model generated from the metadata, where external logic code defines and uses the extension fields.

[0075] After steps 301-302 provided in this embodiment, extended fields can be reserved in the metadata model.

[0076] like Figure 4As shown, the specific process of generating conversion code between different data models based on the network element configuration model through code compilation is as follows:

[0077] Step 401: Call the parsing file of the metadata model to generate the code for the network element configuration model.

[0078] After defining a metadata model containing extended fields, the network element configuration model code can be automatically generated by calling the metadata model's parsing file within the code's build logic. In one scenario, during the code build process, predefined network element configuration metadata model XSD files and metadata parsing files XSLT files can be associated one-to-one. Batch processing can then be triggered, using the XSD file to be generated as a parameter and the XSLT file as a parsing template for execution. By traversing all XSD files, all network element configuration models and their associated code used in the entire network management system can be automatically generated.

[0079] Step 402: Configure the model of each network element configuration data according to the metadata model in the network element configuration model, and generate the corresponding conversion code according to the model of each network element configuration data.

[0080] In practice, different data models are used in different software architecture layers, and corresponding conversion codes need to be obtained based on the specific data model. For example, for network element configuration display models, network element configuration memory models, and network element configuration storage models, each field has a different type, and corresponding conversion codes need to be generated separately.

[0081] After steps 401-402 provided in this embodiment, conversion codes for different data models can be obtained. In actual implementation, the conversion codes can be embedded in the device adaptation module of the network element device to achieve data conversion and adaptation between the network element device and existing network management software.

[0082] In practice, the conversion between different models in step 402 can be carried out in the following manner.

[0083] (1) When the model is a network element configuration display model, iterate through all composite type tags and obtain the attributes related to the network element configuration display model in the composite type tags; generate the corresponding implementation code in the current network management programming language according to the attribute structure of the network element configuration display model.

[0084] Iterate through all `complextype` tags in the XSD file and retrieve the `ice`-related attributes within each `complextype` tag. Read the attribute `w:iceseqitem="XIce"` and generate an `ice` structure named "XIce", whose fields are composed of the fields covered by the `element` fields contained under the `complextype` tag. If a field is a basic type such as `int`, `bool`, or `string`, use the corresponding basic type in `ice`; if a field is a composite type, continue to use the structure generated in `ice` for that composite type to define it. Generate the implementation code for the `ice` structure in the current network management programming language JAVA / C++.

[0085] (2) When the model is configured with a memory model for a network element, iterate through all composite type tags and obtain the device type-related attributes in the composite type tags; generate the corresponding implementation code for the current network management programming language based on the attributes of different device types.

[0086] Iterate through all `<complextype>` tags in the XSD file and retrieve the `deviceclass` attribute from each `<complextype>` tag. Read the attribute `deviceclass="CXCfg"` and generate a Java / C++ class named "CXCfg". Its fields are composed of the fields covered by the `element` fields contained under the `<complextype>` tag. If a field is a basic type such as `int`, `bool`, or `string`, use the corresponding basic type in Java / C++; if a field is a composite type, continue to define it using the structure generated by that composite type in Java / C++.

[0087] (3) When the model is configured to store the network element, iterate through all composite type tags and obtain the pb protocol-related attributes in the composite type tags; generate the corresponding implementation code in the current network management programming language according to the pb protocol attributes.

[0088] Iterate through all `complextype` tags in the XSD file and retrieve the pb-related attributes within them. Read the attribute `w:pbout=""` and generate a proto file named "X.proto". Its fields are composed of the fields covered by the `element` fields contained under the `complextype` tag. If a field is a basic type such as `int`, `bool`, or `string`, use the corresponding basic type from ICE; if a field is a composite type, continue to use the structure generated by that composite type in the pb protocol for definition. Generate the pb protocol file using the implementation code in the current network management programming language JAVA / C++.

[0089] As can be seen, the conversion code between the metadata model and each data model can be obtained through the above method, thereby realizing the automatic conversion between the metadata model and the actual data model used.

[0090] After obtaining the corresponding conversion code for the configuration data model of each network element, configuration models at various levels generated using the same metadata model can be used. It can be seen that their fields are one-to-one and their names and types are consistent. Based on this, conversion functions and code between each pair of network element configuration models can be generated. Different methods are required for data conversion of different types of fields in the data model.

[0091] (1) For the basic type fields in the network element configuration storage model, the values ​​are directly assigned based on the network element configuration data.

[0092] For basic type fields in network element configuration, values ​​can be directly assigned in the model.

[0093] (2) For array fields in network element configuration, traverse all arrays in the network element configuration storage model and insert the obtained values ​​into the corresponding arrays after conversion.

[0094] For array fields in network element configuration, it is necessary to iterate through the array in the field and then insert the value of each array element into the array in the converted model in turn.

[0095] (3) For the extended fields in the network element configuration, traverse the extended field structure in the network element configuration storage model, and insert the obtained value pairs into the converted extended fields according to the key values ​​of the extended fields.

[0096] For the extended fields in the network element configuration, iterate through the hashmap and then insert the obtained key-value pairs into the transformed extended fields one by one.

[0097] As can be seen, by using conversion code, data conversion between configuration data, metadata models, and various configuration models can be achieved.

[0098] In practice, the usage of extended fields varies depending on the data model.

[0099] (1) When the network element configuration model is the network element configuration memory model, the fields are dynamically expanded in the network element configuration memory model and the dynamically expanded fields are assigned values.

[0100] In the framework that uses and embeds this network element configuration model, when a new requirement necessitates adapting a new field to the configuration block of a certain device, the corresponding network element configuration memory model is dynamically expanded with keywords in the device adaptation module for that device. The expanded field is then assigned a value based on the actual field value of the device.

[0101] (2) When the network element configuration model is the network element configuration storage model, obtain the extended fields in the network element configuration storage model.

[0102] In the framework that uses and embeds this network element configuration model, after new fields are dynamically expanded and assigned values ​​in the network element configuration memory model, the network element configuration storage model will dynamically expand the corresponding newly added fields as the process progresses. The value of the expanded field can be retrieved from the network element configuration storage model using the field's keyword.

[0103] (3) When the network element configuration model is the network element configuration interface display model, obtain the extended fields in the network element configuration interface display model.

[0104] In the framework that uses and embeds this network element configuration model, after dynamically expanding and assigning new fields in the network element configuration memory model, the network element configuration interface display model will dynamically expand the corresponding newly added fields as the process progresses. The value of the expanded field can be retrieved from the network element configuration interface display model using the field's keyword.

[0105] As can be seen, the metadata model and network element configuration model with extended fields provided in this embodiment can realize the extension and transmission of configuration data.

[0106] The method for dynamically expanding the network element configuration model provided in this embodiment defines a general model of associated network element configurations by maintaining a metadata model. By integrating the metadata model into the build process during code compilation, various models of network element configurations at different software architecture implementation levels can be automatically generated, including interface display models, memory models, and storage models, and conversion code between models can be generated. By introducing this metadata management mechanism for network element configurations, the automatically generated network element configuration models and implementation code at each level are embedded when writing the general process of network management software, and the intermediate software processes can be shared. At the same time, dynamic expansion is supported on the basis of the fixed model generated by the metadata model, so that the expansion of the same network element configuration on different devices can be dynamically expanded outside the model and general process without affecting the original system, which can be implemented quickly, greatly reducing the development workload of later maintenance and reducing the cross-impact on other products during product iteration.

[0107] Example 2:

[0108] Based on the method for dynamically expanding the network element configuration model provided in Embodiment 1 above, the present invention also provides an apparatus for dynamically expanding the network element configuration model to implement the above method, such as... Figure 5 The diagram shown is a schematic representation of the device architecture according to an embodiment of the present invention. The device for dynamically expanding the network element configuration model in this embodiment includes one or more processors 11 and a memory 12. Figure 5 Take a processor 11 as an example.

[0109] In actual implementation, such as Figure 6 As shown, to facilitate the processing of data models at different software architecture levels, the processor 11 can contain different functional modules. In actual implementation, the available functional modules and the use of data models by each functional module can refer to the following methods, or different module divisions or data model usage can be carried out according to actual needs.

[0110] (1) General model for network element configuration: This model is used to define a general metadata model that describes the configuration of network elements, and reserves extended fields in the metadata model. During the code construction process, different data models at the implementation level are generated through the metadata model, including: implementation code and conversion methods of network element configuration interface display model, network element configuration memory model, and network element configuration database storage model. The generated model supports dynamic expansion.

[0111] (2) General Process Module: Used to organize the general process of network element configuration distribution to and retrieval from devices. In the distribution process, the network element configuration saves data from the interface display module to the database storage module and distributes it to each network element device through the device adaptation module; in the general process of retrieving database configuration, the network element configuration queries data from the database storage module and returns it to the interface display module for display; in the general process of retrieving device configuration, the network element configuration synchronizes data from the network element device through the device adaptation module, saves the synchronized data to the database storage module, and then returns it to the interface display module for display.

[0112] (3) Interface display module: Uses the network element configuration interface display model to display the configuration block information of a certain network element of a certain device on the user interface. Uses the network element configuration storage model to store network element configuration data in the database and provides the data interaction interface and logic implementation of the network element configuration storage model.

[0113] (4) Database storage module: The network element configuration storage model is used to store network element configuration data in the database, and provides data interaction interface and logical implementation of the network element configuration storage model.

[0114] (5) Device Adaptation Module: Using the network element configuration memory model, the network element configuration model is assembled or parsed according to the device communication protocol for interaction with the device. The conversion code in the device adaptation module is adaptively adjusted according to device changes to meet the data interaction needs between different devices.

[0115] As can be seen, by using the above functional modules, in conjunction with the metadata model and the general network element configuration data model in Example 1, the method for dynamically expanding the network element configuration model provided in Example 1 can be completed, thereby realizing the dynamic expansion of network element configuration data.

[0116] Processor 11 and memory 12 can be connected via a bus or other means. Figure 5 Taking the example of a connection between China and Israel via a bus.

[0117] The memory 12 serves as a non-volatile computer-readable storage medium for the dynamic expansion method of the network element configuration model. It can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the dynamic expansion method of the network element configuration model in Embodiment 1. The processor 11 executes various functional applications and data processing of the device for dynamic expansion of the network element configuration model by running the non-volatile software programs, instructions, and modules stored in the memory 12, thereby implementing the method of dynamic expansion of the network element configuration model in Embodiment 1.

[0118] Memory 12 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 12 may optionally include memory remotely located relative to processor 11, which can be connected to processor 11 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0119] The program instructions / modules are stored in memory 12. When executed by one or more processors 11, they perform the method for dynamically expanding the network element configuration model in Embodiment 1 above, for example, performing the above-described method. Figures 1 to 4 The steps shown.

[0120] Those skilled in the art will understand that all or part of the steps in the various methods of the embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0121] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for dynamically expanding a network element configuration model, characterized in that, Specifically, it includes: Obtain the metadata model, which describes the network element configuration model; this includes: obtaining the network element configuration data to be used; defining the metadata model based on the network element configuration data, wherein the metadata model can derive models of each network element configuration data; and generating and / or converting the metadata model based on the correspondence between the network element configuration data and the metadata model. Define an extended field structure, reserve extended fields in the metadata model using the extended field structure, and use the corresponding extended fields in the network element configuration model; including: using a general type container as the extended type of the extended field structure, where the general type container is used to represent different types of network element configuration data; reserving fields of the extended type in the metadata model as reserved extended fields in the metadata model; Based on the metadata model, the code compilation process generates conversion code between different network element configuration data models based on the network element configuration model. This includes: calling the parsing file of the metadata model to generate the code for the network element configuration model; configuring the model of each network element configuration data according to the metadata model in the network element configuration model; and generating corresponding conversion code according to the model of each network element configuration data. The conversion code is used to perform data conversion between the expanded data models. For basic type fields in the network element configuration storage model, values ​​are directly assigned based on the network element configuration data. For array fields in the network element configuration, all arrays in the network element configuration storage model are traversed, and the obtained values ​​are inserted into the corresponding arrays after conversion. For extended fields in the network element configuration, the extended field structure in the network element configuration storage model is traversed, and the obtained key-value pairs are inserted into the extended fields after conversion based on the key-value pairs of the extended fields. When the network element configuration data model needs to be expanded, the expansion is performed in the expansion fields of the network element configuration model; when the network element configuration model is a network element configuration memory model, the fields are dynamically expanded in the network element configuration memory model, and values ​​are assigned to the dynamically expanded fields; when the network element configuration model is a network element configuration storage model, the expansion fields are obtained in the network element configuration storage model; when the network element configuration model is a network element configuration interface display model, the expansion fields are obtained in the network element configuration interface display model.

2. The method for dynamically expanding the network element configuration model according to claim 1, characterized in that, When the model of the network element configuration data is a network element configuration display model, the step of generating corresponding conversion code based on the model of each network element configuration data specifically includes: Iterate through all composite type tags and obtain the attributes related to the network element configuration display model in the composite type tags; Based on the attribute structure of the network element configuration display model, corresponding implementation code is generated in the current network management programming language.

3. The method for dynamically expanding the network element configuration model according to claim 1, characterized in that, When the model of network element configuration data is a network element configuration memory model, the step of generating corresponding conversion code based on the model of each network element configuration data specifically includes: Iterate through all composite type tags and retrieve the device type-related attributes within the composite type tags; Generate implementation code corresponding to the current network management programming language based on the attributes of different device types.

4. The method for dynamically expanding the network element configuration model according to claim 1, characterized in that, When the model of network element configuration data is a network element configuration storage model, the step of generating corresponding conversion code based on the model of each network element configuration data specifically includes: Iterate through all composite type tags and retrieve the pb protocol-related attributes within the composite type tags; Generate implementation code corresponding to the current network management programming language based on the attributes of the pb protocol.

5. A device for dynamically expanding a network element configuration model, characterized in that: The method includes at least one processor and a memory, which are connected via a data bus. The memory stores instructions that can be executed by the at least one processor. After being executed by the processor, the instructions are used to perform the method for dynamically expanding the network element configuration model according to any one of claims 1-4.

Images