Data-driven automated provisioning of telecommunications applications

Abstract

Embodiments of the present disclosure relate to data-driven automation provisioning for telecommunications applications. Systems and methods for constructing service templates that allow for agentless, data-driven, and stateful automation of provisioning of services to mobile network customers. Data associated with a request to create a target schema object class for a device and a protocol is received. Based on the device and protocol information, a set of data fields associated with CRUD semantics is retrieved from a database or from user-provided data. A decorated target object class is created based on the requested target schema object class. A sub-recipe is created that includes the decorated target object class and one or more other decorated target object classes. The recipe is processed for transmission to an execution engine to form a service instance that is customizable by an operator for a particular network device, such that service instance data fields that are not pre-populated are able to be customized by the operator.

Description

[0001] Cross-references to related applications

[0002] This application is a divisional application of the invention patent application entitled "Data-Driven Automated Supply for Telecommunications Applications", which was filed on December 9, 2016, with international application number PCT / US2016 / 065836, entered the Chinese national phase on August 2, 2018, with Chinese national application number 201680080867.X.

[0003] This application claims priority to U.S. Provisional Application No. 62 / 265,633, entitled “Data Driven Automated Provisioning of Telecommunication Applications,” filed December 10, 2015, which is incorporated herein by reference. Technical Field

[0004] This disclosure relates to data automation. More specifically, this disclosure relates to providing data-driven automated provisioning for telecommunications applications. Background Technology

[0005] Telecom network functions and applications (also referred to as applications or telecom applications in this document) often have very rich and complex configuration models. Telecom applications are also often long-lived and frequently reconfigured. For example, in a network supporting mobile customers, many network nodes and backend business systems need to be configured whenever an additional customer joins the network.

[0006] Traditionally, the final integration point for these frequently configured options in a telecommunications environment is the Operations Support System / Business Support System (OSS / BSS) system. However, integrating new devices and / or services into the network is often very time-consuming and expensive, requiring custom code development within the OSS / BSS system – which is itself a very large, complex, and customized system. Furthermore, the end result (even after sufficient time and money have been spent) is that the process is not highly automated, but rather guides the user through a series of GUI screens, typically requiring configuration for each type of device to support the entire service. Summary of the Invention

[0007] This document discloses systems and methods for constructing service templates that allow for agentless, data-driven, and stateful automation of service provisioning to mobile network clients. In some embodiments, a computing device receives data associated with a request for creating a device type category for a connection, the device type category being associated with a device and associated protocol in the mobile network. In some embodiments, the computing device receives data associated with a request for creating a target schema object class associated with the device type category of the connection, the request including a first object parameter associated with the target schema object class, the first object parameter including at least one of the device type and protocol of the device, the target schema object class representing a class of configurable resources based on the device type and protocol. In some embodiments, when the configuration parameters associated with the protocol include an importable table (associated with data that can be imported from the server into the database), the computing device retrieves a set of data fields associated with the database associated with the computing device and specifying creation, read, update, and delete (CRUD) semantics representing the capabilities of the device, based on a first object parameter. And when the configuration parameters associated with the protocol include a non-importable table (associated with data that cannot be imported from the server into the database), the computing device retrieves a set of data fields associated with the creation, read, update, and delete (CRUD) semantics representing the capabilities of the device, based on user-provided data, based on the first object parameter. In some embodiments, the computing device creates a requested target schema object class, which includes the retrieved set of data fields. In some embodiments, the computing device creates a modified target object class based on the requested target schema object class, which includes specified values ​​for at least a portion of the data fields in the retrieved set of data fields. In some embodiments, the computing device receives data associated with a request to create at least one sub-recipe, each of the at least one sub-recipe including a modified target object class and at least one of one or more other modified target object classes, and data indicating the association between the modified target object class and one or more other modified target object classes. In some embodiments, the computing device processes a recipe for transmission to an execution engine to form a service instance, the recipe including at least one sub-recipe, the service instance including service instance data fields that are pre-filled or hidden based on specified values, the service instance being customizable by an operator for a specific network device, such that service instance data fields not pre-filled can be customized by the operator.

[0008] In some embodiments, the computing device determines a set of sub-recipes with a common target object class in at least one sub-recipe, wherein the common target object class exists in each sub-recipe of the sub-recipe set. In some embodiments, the computing device receives merged parameters for a common target object class in one sub-recipe of the sub-recipe set, wherein the merged parameters include a set of values ​​for data fields of a common target object class. In some embodiments, the computing device applies the merged parameters to each of other commonly modified target object classes associated with each of the other at least one sub-recipe.

[0009] In some embodiments, the computing device creates a modified target object class by receiving specified values. In some embodiments, the specified values ​​are derived from a first object parameter. In some embodiments, the service instance further includes a target instance, which includes at least one of a virtual network function, a physical network function, or an application. In some embodiments, configurable resources include at least one of quality of service, rating groups, billing plans, and packet filters. In some embodiments, the protocol includes at least one of the following: Representational State Transfer (REST) ​​protocol, Structured Query Language (SQL) protocol, Simple Object Access Protocol (SOAP), Secure File Transfer Protocol / Secure Shell Protocol (SFTP / SSH), Simple Network Management Protocol (SNMP), and Network and Configuration Protocol (NETCONF). Attached Figure Description

[0010] The various objectives, features and advantages of the disclosed subject matter can be more fully understood when considered in conjunction with the following accompanying drawings and with reference to the following detailed description of the disclosed subject matter, wherein similar reference numerals identify similar elements.

[0011] Figure 1 This is a system diagram illustrating the deployment of a service automation platform according to some embodiments of the present disclosure.

[0012] Figure 2 This is a system diagram illustrating automated onboarding of a new mobile virtual network operator (MVNO) according to some embodiments of the present disclosure.

[0013] Figure 3 This is a system diagram of a recipe builder and a recipe transactor according to some embodiments of this disclosure.

[0014] Figure 4 This is an object relationship diagram for service instance management according to some embodiments of this disclosure.

[0015] Figure 5The image shows a screenshot of a recipe builder user interface including a service recipe section and a sub-recipe section, according to some embodiments of the present disclosure.

[0016] Figures 6A-6B The image shows a screenshot of a recipe builder user interface including a representation of a native target object, according to some embodiments of the present disclosure.

[0017] Figure 6C This is a view used to design a recipe builder user interface for a target pattern object of the connector type, according to some embodiments of this disclosure.

[0018] Figure 6D This is a view of a recipe builder user interface used for designing and modifying target object classes, according to some embodiments of this disclosure.

[0019] Figure 7 This is a screenshot showing the user interface of a recipe trader according to some embodiments of the present disclosure.

[0020] Figure 8 This is a view showing parameter merging in a recipe builder according to some embodiments of the present disclosure.

[0021] Figure 9 This is a flowchart illustrating the creation of a recipe used to partially automate the creation of service instances according to some embodiments of this disclosure. Detailed Implementation

[0022] The embodiments disclosed herein provide techniques for automating the configuration of telecommunications applications. The techniques disclosed herein allow for reusable recipes, sub-recipes, and target pattern object classes that can be customized for a variety of telecommunications applications and devices.

[0023] For example, Network Functions Virtualization (NFV) is not just about enabling new Virtual Network Functions (VNFs) / Virtual Machines (VMs). Many VNFs are long-lived and multi-tenant. Many VNFs have complex and ongoing configuration requirements.

[0024] For example, Service Function Chains (SFCs) can increase integration challenges. VNFs within an SFC are often long-lived and multi-tenant. Policy reconciliation is not entirely resolved by the SFC (e.g., a VNF may not know which policies are associated with a Service Function Path (SFP) ID).

[0025] True end-to-end carrier service may require extensive coordination configuration across control planes (e.g., MME, RADIUS, PCRF, OCS, OFCS, PE routers) and various internal applications.

[0026] Service modeling can take too long (e.g., the time spent defining a service and how to implement it in a network) and is not automated enough (e.g., programming of a meta-model (MOP) represented as a Word document with a corresponding list).

[0027] Data-driven approaches to automation have been used in script form for quite some time. To some extent, script-driven automation is data-driven because the script itself represents data. Furthermore, scripts are "fire and forget," resulting in a lack of stateful representation of the effects achieved as a result of running the script.

[0028] While scripting methods have been utilized in traditional information technology (IT) setups, they haven't been widely applied to the provisioning of telecommunications applications for some time. Unlike typical IT applications, which are typically configured at deployment time and require little to no incremental reconfiguration, telecommunications applications require service configuration validation to ensure that the expected artifacts in the network are provisioned as intended.

[0029] Attempts have been made to simplify the integration of telecommunications applications into automation frameworks, but each requires code writing by the automation platform developers to ultimately integrate new devices, services, or programs. In contrast, the approach described in this paper is entirely data-driven and agentless, where the end user of the solution provides all the data necessary to model the desired automation process.

[0030] Telecommunications applications are typically agentless. Agent-based approaches allow clients (e.g., applications) to pull the necessary configurations from a server (e.g., an agent running on a server or virtual machine (VM) queries the server to determine which software packages it should install). Conversely, without an agent, a central "manager" must push all the necessary configurations to each client. Due to the variety of vendors and application types (e.g., routers, DNS servers, PCRFs, PGWs, etc.), telecommunications applications tend to be agentless. This contrasts with homogeneous environments with agent-based goals (e.g., installing an agent on Linux for software installation and upgrades).

[0031] As described herein, a data-driven approach can refer to a system user who provides the information needed to manage the configuration of any new network function or application. As described in some embodiments, the system does not provide a list of supported network functions or applications. Instead, the system user can directly enable the configuration of said applications in a dynamic manner. As mentioned above, an agentless approach can be used in applications such as telecommunications, where deploying ubiquitous (e.g., distributed) agents to pull any and all types of configurations into any and all related network functions and applications is impractical.

[0032] Furthermore, to alleviate the burden on end users of the aforementioned problems, in some embodiments, a data automation language can be used to describe any and all automated processes. In some embodiments, the systems and methods described herein use Extensible Markup Language (XML) to create a language that allows the expression of general sequences of actions occurring on a set of target entities over some supported transport, such as Secure Shell / Command Line Interface (SSH / CLI). In some embodiments, the expressive power of this language is also sufficient to capture if / else logic to handle any range of executable versions within the set of target entities.

[0033] This approach can be object-oriented to allow for lifecycle management of abstract service instances, which may include the collection of supported native object instances on selected targets. Such service instances can be created, deleted, modified, inspected for synchronization with underlying targets, forced to synchronize with underlying targets, have their status checked, and statistics collected.

[0034] The method described in this paper can support any desired transport protocol toward the desired target device, including Network Configuration Protocol (NETCONF), Simple Network Management Protocol (SNMP), SSH / CLI, SSH File Transfer Protocol (SFTP), Representational State Transfer (REST), and Simple Object Access Protocol (SOAP) / XML.

[0035] In some embodiments, a recipe builder (also referred to herein as vBuilder) is used to define services. As described in more detail below, the recipe builder allows subject matter experts (SMEs) to build recipes for network operators. In some embodiments, the system described herein provides GUI-based end-user devices that require no coding and have no built-in product-specific adapters. In some embodiments, reusable model definitions by SMEs are used. As described in more detail below, an example of a reusable model definition is a sub-recipe used in multiple recipes. In some embodiments, the system described herein allows for flexible argument handling and propagation and can be modified to support any target device or application on any transport connector (e.g., NETCONF, REST, SOAP, SNMP, Java Structured Query Language (JSQL), CLI / SSH). In some embodiments, the system described herein supports multiple versions of the target.

[0036] In some embodiments, the system described herein provides a recipe transactor (also referred to herein as a recipe vTransactor) for service instantiation. The recipe transactor can import completed recipes from a recipe builder. In some embodiments, services are triggered via a GUI or programmatically (e.g., using REST). Services may include creation / modification / deletion status, statistics, and user-defined actions. In some embodiments, the system described herein can track instantiated service instances, such as configuration synchronization / checks, status with cross-target aggregations, and cross-target statistics rollups.

[0037] Figure 1 This is a system diagram illustrating the deployment of a service automation platform according to some embodiments of the present disclosure. Figure 1 The diagram illustrates the following components: operational network 102, corporate IT network 104, interface to the operator 106, interface to subject matter experts (SMEs) 108, recipe builder (also referred to herein as recipe builder) 110, recipe executor (also referred to herein as recipe trader) 112, operations support system / business support system (OSS / BSS) application 114, element management system (EMS) 116, network element (NE) 118, NE 120, virtual I / O module (VIM) 122, NFV orchestrator / virtual network function manager (NFVO / VNFM) 124, and application 126.

[0038] Recipe Builder 110 can be deployed as a tool within corporate network 104. In some embodiments, the target user is a Subject Matter Expert (SME) 108. SME 108 can communicate with Recipe Builder 110 via a web service architecture such as REST. Recipe Builder 110 specifies how to build a model suitable for recurring calls to the recipe. As described in more detail below, in some embodiments, Recipe Builder 110 allows SME 108 to specify how the operator can onboard new customers by enabling operator 106 to create, retrieve, update, and delete service instances. SME 108 constructs native target objects (also referred to herein as “target schema object class” or “target schema object”) / modified target objects (also referred to herein as “modified target object class”) in an object-oriented program, which constitute the recipe (e.g., QoS policy, billing plan). Services can be defined by recipes, enabling complete service modeling (e.g., creation / modification / deletion status, statistics, user-defined actions). The system described in this paper does not require coding or product-specific adapters, at least in part because recipes can be constructed by SME 108 through direct interaction with the recipe builder's GUI, importing configuration object model schemas (e.g., another next-generation (YANG) module from router vendor X) and user data entry to define "pseudo-schemas" for applications that do not provide machine-readable schemas. An example of this is an application or network function that is solely managed using a command-line interface (CLI). Application providers can typically publish CLI user guides as PDF files (e.g., they can publish machine-readable formats such as Backus-Noir-Form (BNF) that only provide syntax and not semantics). In the CLI documentation example, there is actually no "official" schema for the application.

[0039] Residing in the operating network 102, the recipe transactor 112 allows operator 106 to provision services based on recipes received from the recipe builder 110. Operator 106 can communicate with the recipe transactor via a network service architecture such as REST. The recipe transactor 112 utilizes models to support the lifecycle management of service instances (e.g., creation, retrieval, updating, deletion). The recipe transactor 112 can also communicate with all other components (e.g., OSS / BSS application 114, Component Management System (EMS) 116, Network Element (NE) 120, Virtual I / O Module (VIM) 122, NFV Orchestrator (NFVO) / Virtual Network Function Manager (VNFM) 124, and application 126) through a set of supported connectors or protocols. Models can be created from at least one of the protocol and device types detected by the recipe and from prior knowledge of the protocol or device associated with service instantiation. As described in more detail below, operator 106 can instantiate a service by providing recipe information specific to a particular target instance provided by the recipe transactor 112. Recipe transceiver 112 can specify parameters to OSS / BSS application 114, Component Management System (EMS) 116, Network Element (NE) 120, Virtual I / O Module (VIM) 122, NFV Orchestrator (NFVO) / Virtual Network Function Manager (VNFM) 124, and application 126 to instantiate services. Recipe transceiver 112 can also use additional instructions to specify parameters to OSS / BSS application 114 to configure Component Management System (EMS) 116, Network Element (NE) 120, Virtual Infrastructure Manager (VIM) 122, NFV Orchestrator (NFVO) / Virtual Network Function Manager (VNFM) 124, and application 126 to instantiate services. Recipe transceiver 116 can communicate with other operational network elements through protocols / connectors supported by the system described herein (e.g., at least one of REST, SOAP, and NETCONF).

[0040] OSS / BSS application 114 can be used to manage and support end-to-end telecommunications services. OSS includes management functions such as service provisioning. BSS includes components for managing business operations for telecommunications service providers. EMS 116 manages network elements 120 in the telecommunications network. NFVO / VNFM 124 manages and orchestrates NFV resources. VNFM manages the VNF lifecycle. Application 126 refers to telecommunications applications.

[0041] As described above, the recipe builder 110 is data-driven. To automate the incorporation process, the SME 108 can use a combination of one or more target schema objects (also referred to herein as "target schema object classes") and one or more modified target objects (also referred to herein as "modified target object classes") to constrain the configuration parameters that should be specified by the operator 106. As described in more detail below, the SME 108 may include combinations of target schema object classes in a single sub-recipe and specify relationships between target schema object classes. The recipe trader 112 supports protocols for configuring products, thereby configuring the product itself. The recipe can specify at least some of the parameters required for each protocol. In some embodiments, the SME can simplify the model and / or specify constraints that are more restrictive than the constraints of the target itself by hardcoding certain attributes that are otherwise flexible from the target's perspective. In some embodiments, the actual values ​​that ultimately satisfy all constraints are processed by the trader during the execution of operations (e.g., creation, update, etc.).

[0042] For example, to enable customer onboarding, SME 108 can compose a recipe defining how to onboard a new customer. Recipes composed by SME 108 allow operators to create, retrieve, update, and delete (also referred to as CRUD semantics in this document) lifecycles for instantiation. An example of service instantiation is when a wireless operator directly onboards a large customer (e.g., join in When, or when a wireless operator adds a subsidiary customer (e.g., When joining a mobile virtual network operator (MVNO) such as Cricket Wireless. In some embodiments, joining a customer requires a configuration of multiple touchpoints, as described below. Figure 2 More detailed description.

[0043] Figure 2 This is a system diagram illustrating the automated joining of a new MVNO according to some embodiments of the present disclosure. Figure 2The following are shown: Recipe Trading System 112, Network Functions Virtualization Infrastructure (NFVI) 202, OSS 114, and NFVO / VNFM. 124. GiLAN Service 208. Packet Data Network Gateway (PGW) 210. Mobility Management Entity (MME) 212. Domain Name Server (DNS) 214. Offline Charging System (OFCS) 216. Online Charging System (OCS) 218. Home Subscriber Server / Home Location Register (HSS / HLR) 220. Policy and Charging Rules Function (PCRF) 222. Authentication, Authorization and Accounting (AAA) Server 224. Provider Edge (PE) Router 226. Northbound Application Programming Interface (API) Renderer 228. Formula Trader Engine 112. Authorization Manager 232. Representational State Transfer (REST) ​​Protocol 234. Structured Query Language (SQL) Protocol 236. Simple Object Access Protocol (SOAP) 238. Secure File Transfer Protocol / Secure Shell Protocol (SFTP / SSH) 240. Simple Network Management Protocol (SNMP) 242. Network and Configuration Protocol (NETCONF) 244.

[0044] NFVI 202 is a collection of compute, storage, and network resources available for VNF utilization. In some embodiments, the system described herein can be used to manage virtual network functions, physical network functions, or a combination of both. Figure 2As shown, instantiating a service requires configuring a variety of network components. For example, configuring PE router 226 may include configuring at least one or more instances of each of Border Gateway Protocol (BGP) Virtual Routing Function (VRF) and Multiprotocol Label Switching (MPLS) BGP / MPLS VRF; configuring AAA server 224, PCRF 222, and HSS / HLR 220 may include configuring at least one of Access Point Name (APN) policy mapping and International Mobile Subscriber Identity (IMSI) policy mapping; configuring OCS 218 and OFCS 216 may include configuring the APN as an MVNO mapping; configuring DNS 214 may include configuring APN and PGW C name records; configuring MME 212 may include configuring APN carrier policies and PGW selection policies; and configuring Gi LAN service 208 may include configuring PGW, APN, User Equipment (UE) pool, BGP / MPLS VRF, workflow control, and data profiles. Gi is the interface from GGSN / PGW to the Internet. In some embodiments, various value-added services are inserted between GGSN / PGW and the Internet. These entities are referred to as GiLAN or Gi LAN. For example, GiLAN service 208 may include configurations for policies and behaviors targeting Hypertext Transfer Protocol (HTTP) proxies, Transmission Control Protocol (TCP) proxies, HTTP content filtering, Network Address Translation (NAT), or firewalls. As described above, operator 106, via northbound API renderer 228, can execute recipes via recipe transceiver 112 to configure network elements to create, retrieve, update, or delete service instances via supported protocols (e.g., REST 234, SQL 236, SOAP 238, SFTP / SSH 240, SNMP 242, NETCONF 244). In contrast, existing technologies require either 1) manual programming for each new service instantiation or 2) inflexible systems that only support a small subset of services designed at high cost by IT departments or are under-reserved, requiring continuous validation of previously configured scripted approaches. As described in more detail below, the system and method described herein automate the process of adding a new customer by having the SME input the following information: 1) a first layer including recipes, 2) a second layer including sub-recipes, and 3) a third layer including a) a target schema object class natively seen by the target (also referred to herein as the "target schema object"), and b) a target schema object class annotated by the SME (also referred to herein as the "modified target object"). Verbs (e.g., CRUD) are behavioral aspects of all layers.

[0045] In some embodiments, at the third layer, there is a two-level modeling approach: first, importing or defining a native representation of the target of a resource (e.g., an object), and second, modifying or annotating that native representation to specify more restrictive constraints, perform data hiding by hard-coding certain attributes, or perform simplification by merging (e.g., combining) multiple attributes. An aspect of the model associated with each CRUD verb can be referred to as a facet of the model—a recipe, a sub-recipe, a target schema object class / modified target object class—all having a verb-specific aspect of the model for creating, updating, etc., to represent the model. In some embodiments, a non-verb-specific aspect of the resource or object model is a key attribute that uniquely identifies an instance of the resource. These attributes are fully specified for performing the verb.

[0046] As described in some embodiments of this disclosure, a target pattern object is a representation of an object provided by a native application with precision and flexibility—for example, reading a CLI guide to view a static route object, such as having a way to uniquely identify its instance, having certain mandatory attributes, certain optional attributes, and those attributes having types and possibly constraints. Once a target pattern object is established (e.g., imported by an SME), further refinement can be allowed in the form of additional constraints, data hiding, and other operations such as merging attributes, such that multiple attributes will always be provided with the same value. For example, a modified target object class can be created based on a static route target pattern object class by restricting it to using only IPv4 addresses. In different modified target object classes based on the same target pattern object class, the constraint could be to allow only IPv6 addresses.

[0047] In some embodiments of the system described herein, the authorization manager 232 enables certain auxiliary functions. Created service instances can be specified such that only a subset of operators can perform further actions (updates, deletions, etc.) on them. For example, a Cricket MVNO and a Jasper MVNO can be created by a trader based on an MVNO model or recipe designed by an SME. There can be one operator team that can modify only the Cricket MVNO and a different team that can modify only the Jasper MVNO.

[0048] Figure 3 This is a system diagram of a recipe builder and a recipe trader according to some embodiments of this disclosure. Figure 3The following are illustrated: service database 310, recipe database 312, end-to-end (E2E) test recipe 316, service recipe 318, simulation test target 320, network service definition language (WSDL) 322, XML schema definition (XSD) 324, next-generation configuration object modeling language (YANG) 326, management information base (MIBS) 328, physical / virtual network functions (P / VNF) 330 332 340 342, NFVO / NF / application 334, P / VNF / application 336, and remote database 344.

[0049] Service database 310 includes records of services instantiated by recipe transactor 112. As described in more detail below, service records may include service instances, target types, and target instances. Recipe database 312 includes records of recipes, sub-recipes, target pattern objects, and modified target object classes created by SME 108 through recipe builder 110.

[0050] Simulation Test Objective 320 allows SMEs to execute recipes in a simulation environment used for testing, debugging, and modification. Simulation Test Objective 320 refers to simulations that can be defined by SMEs with objectives such as PCRF based on request / response pairs. This allows for first-level testing of sub-recipes intended for PCRF even before deployment on the trader.

[0051] Recipe Builder 110 can create two types of recipes: E2E test recipe 316 and service recipe 318. E2E test recipe 316 can verify the behavior of service instances created via the recipe. E2E test recipe 316 not only tests that the configuration is correct and current, but it can also test real end-to-end behavior that may be affected by operating conditions such as the physical link state on various router-to-router links. For example, instead of the usual CRUD lifecycle management of service instances, the systems and methods described herein can be used to model, collect, and interpret calls to the results of active tests that can be used for service verification. For example, a test UE owned by an operator can be deployed to connect to an MVNO and then retrieve files from an operator-owned server. The test UE can be triggered to perform a test, and the results of this test can be queried. In this example, no actual service instance is created; instead, stateless actions are used. As described in more detail herein, service recipe 318 can be designed by SME for use by operator 106 to instantiate a service.

[0052] The recipe can be designed to communicate with applications managed via SOAP / XML and publish corresponding Web Services Definition Language (WSDL) 322, YANG 326, and / or Management Information Base (MIBS) 328. WSDL 322 is an XML format that defines services as collections of network endpoints capable of exchanging messages. YANG 326 is a language for NETCONF that is modular and represents data structures in XML tree format. MIBS 328 allows network management systems to monitor database objects.

[0053] As described above, the recipe transceiver 112 can receive recipes that can utilize any number of protocols (e.g., Representational State Transfer (REST) ​​protocol 234, Structured Query Language (SQL) protocol 236, Simple Object Access Protocol (SOAP) 238, Secure File Transfer Protocol / Secure Shell Protocol (SFTP / SSH) 240, Simple Network Management Protocol (SNMP) 242, Network and Configuration Protocol (NETCONF) 244). Each protocol can be associated with P / VNF 330 332 340 342, NFVO / NF / Application 334, P / VNF / Application 336, and Remote Database 344 and used to specify its configuration. For example, NETCONF can be used with YANG-enabled routers (e.g., Juniper routers, Cisco routers). As described in more detail below, YANG files are published by application providers (e.g., "Enterprise" YANG models) and / or standardized (e.g., published by the Internet Engineering Task Force (IETF) in a Request for Comments (RFC)) and can be dragged into the Recipe Builder 110 workspace to specify workflows (e.g., QoS flows). Other protocols include REST, SOAP, and command-line interfaces (CLI). The NETCONF protocol is typically paired with the YANG model, the SNMP protocol is typically paired with the MIB model, the SOAP / XML protocol is typically paired with the WSDL model, and the REST and CLI protocols typically do not have formal schemas.

[0054] Figure 4 This is an object relationship diagram for service instance management according to some embodiments of this disclosure. Figure 4 Recipe 402, sub-recipe 404, and target pattern object class 406 associated with recipe builder 110 are shown; and service instance 410, target type 412, and target instance 414 associated with recipe trader 112 are shown.

[0055] like Figure 4As shown, the elements above the lines illustrate some embodiments of the systems and methods described herein from the perspective of recipe builder 110 (e.g., service model); the elements below the lines illustrate some embodiments of the systems and methods described herein from the perspective of recipe transactor 112 (e.g., the result of executing the model to create service instances). Specifically, artifacts configured into the network with respect to which target instances are involved (e.g., which PE router instance and what native targets or resources, including all their associated values) have been created on those target instances (i.e., VRF, MP-BGP peer sessions, etc.). From the perspective of recipe builder 110, recipe 402, sub-recipe 404, and target pattern object class 406 are created and linked for deployment on recipe transactor 112. Service instance 410 is created when a creation command (e.g., utilizing MVNO) is first issued in association with recipe 402. Multiple service instances 410 represent each service instance created based on the service model represented by recipe 1 402. The same recipe 402 can be used to provision different service instances for different customers. Service instances can be created by executing recipes (e.g., create commands). In some embodiments, recipe transactor 110 has a MySQL database to maintain a hierarchy that tracks service instances and target objects 414 (also referred to as the service instance footprint).

[0056] Recipe 402 may include multiple sub-recipes 404. In some embodiments, each sub-recipe 404 is associated with one or more target types 412. In some embodiments, target type 412 includes device type (e.g., router). Sub-recipes 404 may include multiple target schema object classes 406 constrained by the same target type and the same connector type. Target schema object classes 406 include objects that must be configured for creating service instantiation (e.g., VNF, PNF, application). For example, target schema object classes 406 include CRUD semantics (e.g., create, retrieve, update, and delete).

[0057] For reference Figure 1 Furthermore, as described above, the recipe can be created by SME 108 to minimize the amount of manual configuration performed by operator 106 for service instantiation. In some embodiments, the recipe can be hardcoded by SME 108 to eliminate the need for significant configuration by operator 106. In some embodiments, the recipe can have open fields to obtain input from operator 106. For example, the recipe can leave open fields to specify a unique route discriminator integer value for each VRF. The recipe can expose this value as a required variable provided to operator 106. In some embodiments, the recipe can include open fields that include logical inputs (e.g., if / else) such that the field is filled based on device configuration.

[0058] One implementation of service instance 410 includes one or more target types 412 specified by sub-recipes 404 associated with recipe 402 defining service instance 410. In some embodiments, target type 412 includes one or more target instances 414. Target instance 414 is an instance of a physical (e.g., a uniper router, Cisco router) virtual network function (VNF), physical network function (PNF), or application with which target instance 414 can communicate. As described above, each target instance 414 is associated with a database of service instances and associated coverage areas and artifacts. In some embodiments, at runtime, recipe transactor 112 may request operator 106 to specify multiple instances. In some embodiments, all parameters for each of the many service instances may be specified in a transactor-consumable format (e.g., a spreadsheet).

[0059] Figure 5 The image shows a screenshot of a recipe builder user interface including a service recipe section and a sub-recipe section, according to some embodiments of the present disclosure. Figure 5 The recipe builder user interface 500, billing plan 502, rating group 508, service rule 510, package filter 512, recipe section 522, sub-recipe section 524, and sub-recipe list section 526 are shown.

[0060] The recipe builder user interface 500 includes a recipe section 522, a sub-recipe section 524, and a sub-recipe list section 526. The recipe section 522 includes a field for receiving or setting the recipe name. The recipe section 522 also includes sub-recipes associated with the recipe. As described above, each sub-recipe may include at least one of a target pattern object and a modified target object class.

[0061] The sub-recipe section 524 includes fields for receiving or setting the sub-recipe name 530, a device type field 532, an API protocol field 534, a tag 536, a description field 538, and a recipe using the sub-recipe field 540. For example, as... Figure 5As shown, sub-recipe name 530 can be Mobile Content Cloud (MCC), device type can be Mobile Content Cloud device 532, and API protocol can be YANG protocol 534. Tag 536 includes keywords associated with the MCC sub-recipe. Recipes using this sub-recipe field 540 include Policy and Charge Control (PCC) rules, which are specified in the recipe name field. In some embodiments, a sub-recipe can be associated with more than one recipe. In some embodiments, a recipe using this sub-recipe field 540 can include multiple recipe names. Sub-recipe 524 also includes window 550, which includes a description of relationships between objects (e.g., parent / child or hierarchical relationships between objects). SME 108 can select objects and how objects are connected to each other. For example, rating group 508 can be a child of billing plan 502. Billing plan 502 can have one or more associations with rating group 508. Rating group 508 can be associated with service rule 510, which can also be associated with packet filter 512. In some embodiments, hovering over an arrow connecting one object to another can display the relationship between the two objects. In some embodiments, the recipe specifies which target schema object classes are merged or joined together. For example, target schema object classes can be merged based on the existence of parent-child relationships. The modified target object classes and the merged target schema object classes can lead to further data hiding.

[0062] Sub-recipe list section 526 lists sub-recipes created by SME 108 using recipe builder 110 or available to SME 108. Sub-recipes can be grouped by mobile network element type or structure (e.g., PCRF, PGW, mobile DNS). As described above, some embodiments of the described system do not have prior knowledge of the target type, but the system may have prior knowledge of the connector type. As described above, SME 108 creates the target type in the recipe builder. When YANG, WSDL, or other patterns are available to SME, SME imports the pattern and associates it with the target type. The pattern type implies the connector type (e.g., WSDL implies SOAP / XML).

[0063] Figures 6A-6B The screenshots shown are of native target pattern object class representations (e.g., extracted from published configuration object patterns such as YANG or dynamically created by the system by the user) according to some embodiments of this disclosure. Figures 6A-6B Together, the target object section 602, the activity tab 620, the fields within the activity tab 622, and the target object list section 630 are shown.

[0064] The target object section 602 is included within the recipe builder user interface 500. The target object section 602 includes several parameters, including fields for the target pattern object class name 604, the target pattern object class API protocol 606, the target pattern object class device type 608, the target pattern object class description 610, and / or the target pattern object class label 612. Figure 6A In this context, the target pattern object class name is Quality of Service (QoS) Flow. The QoS Flow is an MCC device using the YANG API protocol. Figure 6B In this context, the target schema object class name is Package Filter. Package Filter is an MCC object type that uses the YANG API protocol. In some embodiments, at least one of the fields is configurable.

[0065] The target object section 602 also includes a facet tab 620. The facet tab 620 may include a Create / Modify tab, a Delete tab, a Configuration Synchronization tab, a Monitoring tab, a Statistics tab, and an Actions tab. The Create / Modify tab allows SME 108 to create or modify the target schema object class. The Delete tab allows SME 108 to delete instances. The Monitoring tab allows SME 108 to determine the status of instances. The Configuration Synchronization tab deals with the persistent data of instances. The Statistics tab displays attributes (e.g., packages, bytes, etc.) related to statistics of the target's native objects. On the Statistics tab, SME can indicate which of the available fields (if any) are of interest (e.g., which may be collected for any service instances built based on recipes utilizing this target schema object class). The Actions tab refers to non-CRUD facets or facets that do not affect persistent data storage (e.g., restart, retrieving files during a virus scan).

[0066] For example, such as Figure 6A As shown, the QoS flow target pattern object class is being modified. In some embodiments, already created objects are listed in the target object list section 630. SME can specify which fields 622 in the activity tab are hardcoded and which fields 622 need to be specified via the recipe trader. In some embodiments, fields that should be specified via the recipe trader are marked with indicators (e.g., marked with a red star).

[0067] The target object list section 630 lists the target schema object classes created by SME 108 using the recipe builder 110 or available for SME 108. The target schema object classes can be arranged first by target type (e.g., MCC), and then by connector type within the target type (e.g., NetConf / Yang, SSH / CLI, SFTP / CLI).

[0068] Figure 6C This is a representation of a recipe builder user interface for designing target schema objects, according to some embodiments of this disclosure. Target schema objects can be used for connector types (such as CLI) that do not have an associated native schema (e.g., the availability of the YANG schema compared to that associated with the NETCONF connector). In this interface, the SME can design object representations by declaring the existence of parameters (variables) and mapping them to specific commands (e.g., CLI text strings) required for the lifecycle management of the object (i.e., creation, retrieval, updating, deletion).

[0069] Figure 6D This is a representation of a recipe builder user interface used for designing modified target object classes according to some embodiments of this disclosure. In some embodiments, the modified target object class is designed by first selecting a target pattern object. This method allows for the specialization of multiple modified target object classes based on the same "base" target pattern object. Available modifications include the ability to hardcode parameters to specific values, to force optional parameters to be mandatory, and to constrain the numerical range of parameters to be more restrictive than would be allowed by the "base" target pattern object.

[0070] Figure 7 This is a screenshot showing a recipe trading page according to some embodiments of the present disclosure. Figure 7 The recipe trader page 700, recipe title 702, description of recipe 704, service instance name 706, stateful tracking 708, MCC 710, and list of recipes and instances 720 are shown.

[0071] From the Recipe Execution page 700, operators can execute or run recipes. The Recipe Execution page includes a recipe title describing the recipe (e.g., Creating a Policy and Charging Control (PCC) rule). The description of Recipe 704 associates the recipe with a service instance. A service instance name can also be specified in the Service Instance Name field 706. Recipe Execution page 700 also includes Stateful Tracking 708. Operators can specify the interval for configuring synchronous operation or collecting statistics. In some embodiments, Recipe Execution page 700 may also include MCC 710, which lists selected devices, available devices, and other mobile content cloud parameters (such as APN name, QoS flow name, maximum uplink and downlink rates, and packet filter name). As described above, many fields on Execution page 700 are designated as parts of recipes designed by SME 108. The list of recipes and instances 720 shows recipes ready to be executed or executed by the operator, as well as instances created by the operator.

[0072] Figure 8 This is a view showing parameter merging in a recipe builder according to some embodiments of the present disclosure. Figure 8 The parameter merging at 802, the modified target object class at 804, the modified target object at 806, the sub-recipe at 808, the sub-recipe at 810, the recipe at 814, and the recipe at 812 are shown. Figure 8 It also shows how SME modifies parameters in different target pattern object classes across devices to bubble up fewer parameters required for the input values ​​at the recipe level.

[0073] Parameter merging (802) is a mechanism for grouping similar parameters and accepting a single value from the originating or service operator. For example, service rules can be configured across PGW and PCRF devices, and the service rule name can be maintained so that it is identical across both device types. If the service name were manually entered twice for each device type, any typo in long names could lead to configuration mismatches between the two device types. Using the parameter merging mechanism, similar parameters across devices can have the same value, and the service operator will be allowed to enter only one value for all devices. Furthermore, parameter merging (802) helps reduce the number of parameters required at the recipe level. Figure 8 As shown, even if the number of parameters bubbled up from the modified target object class 804 and sub-recipe 808, only two parameters are modified and exposed at the recipe level. In this example, this means that the service operator in recipe trader 116 is expected to provide values ​​for only two parameters in order to create a service instance using this recipe.

[0074] Parameter merging 802 operates at all levels, at the modified target object class level 804, at the sub-recipe level 808, or at the recipe level 814. At each level, similar parameters can be merged. At the modified target object class 804, DataMember1 and DataMember2 are grouped together as merged datamember1 (CDM) at target object 11 (TargetObj11), as shown in 806. Similarly, merging is performed at target object 2, but not at target object 21. Merging is performed at the sub-recipe level when parameters are bubbled up at sub-recipe 808. As shown in 810, merging is performed using a CDM (merged data member) from target object 11 and another CDM from target object 12. CDMs are treated like any other parameter or data member. CDMs will adopt attributes applicable to all parameters in the set. For example, if one member of a CDM has an int32 type and another member has an int64 type, the CDM will adopt the int32 type to apply to all parameters in the set. When parameters are bubbled up to formulation 814, similar parameters can be merged at the formulation level, as shown in 812.

[0075] Figure 9 This is a flowchart illustrating the creation of a recipe used to partially automate the creation of service instances according to some embodiments of this disclosure.

[0076] Referring to step 902, the recipe builder receives data associated with a request to create a target pattern object class. In some embodiments, the target pattern object is associated with a connected device type category. The connected device type category may indicate managed devices present (or potentially present) in the mobile network and associated protocols. The connected device type category can be received and created before the request to create the target pattern object class is received.

[0077] In some embodiments, the request for creating a target schema object class further includes a first object parameter associated with the target schema object class. In some embodiments, the first object parameter includes at least one of a device type and a protocol associated with the managed device. The target schema object class may represent a class of configurable resources based on device type and protocol. In some embodiments, the target schema object class is associated with at least one of Quality of Service, rating groups, billing plans, and packet filters. In some embodiments, the protocol may include at least one of Representational State Transfer (REST) ​​protocol, Structured Query Language (SQL) protocol, Simple Object Access Protocol (SOAP), Secure File Transfer Protocol / Secure Shell Protocol (SFTP / SSH), Simple Network Management Protocol (SNMP), and Network and Configuration Protocol (NETCONF). The device type may include a mobile content cloud device, PCRF, router, or PGW.

[0078] Referring to step 904, the recipe builder retrieves a set of data fields associated with the creation, read, update, and delete (CRUD) semantics representing the capabilities of the specified device, based on the device type and protocol. In some embodiments, when the configuration parameters associated with the protocol include an importable table, the set of data fields is retrieved from a database associated with the recipe builder, the importable table being associated with data that can be imported from the server into the database; and when the configuration parameters associated with the protocol include a non-importable table, the set of data fields is retrieved from user-provided data, the non-importable table being associated with data that cannot be imported from the server into the database.

[0079] Referring to step 906, the recipe builder creates the requested target schema object class based on the retrieved set of data fields. As mentioned above, the target schema object class available to SMEs can contain all possible fields that can be configured based on equipment type and protocol.

[0080] Referring to step 908, the recipe builder creates a modified target object class based on the requested target schema object class. In some embodiments, the modified target object class includes specified values ​​for at least a portion of the data fields in the retrieved set of data fields. In some embodiments, the modified target object class includes a subset of data fields pre-filled based on protocol information. In some embodiments, the data fields are filled entirely by the user of the recipe builder. In some embodiments, the data fields are filled by a combination of protocol information and the user of the recipe builder.

[0081] Referring to step 910, the recipe builder receives data associated with a request to create at least one sub-recipe. In some embodiments, each of the at least one sub-recipe includes at least one of the following: 1) a modified target object class; and 2) one or more other modified target object classes, as well as data indicating the association between the modified target object class and one or more other modified target object classes. As described above, a hierarchy can be established among the modified target object classes to indicate the relationships and flows between them.

[0082] Referring to step 912, the recipe builder processes the recipe to be transmitted to the execution engine to form a service instance, wherein the recipe includes at least one sub-recipe. In some embodiments, the service instance includes service instance data fields that are pre-filled or hidden based on specified values, and the service instance is customized by the operator for a specific network device, such that service instance data fields that are not pre-filled can be customized by the operator.

[0083] An example of the system and method described herein could involve an SME (which could be an employee or consultant of a public network operator) creating a service template used to join and manage an L3 corporate VPN connectivity service. Having first obtained working knowledge of the service's business objectives and detailed operational information about the network equipment used by the network operator to provide the service, the SME will begin constructing the service template in a recipe builder. For this example, it is assumed that L3 VPN requires detailed incremental configuration of both routers and firewalls. Furthermore, the network operator uses routers from two different vendors (Vendor R1 and Vendor R2) and firewalls from two different vendors (Vendor F1 and Vendor F2). Any particular L3 VPN instance (i.e., provided for a specific corporate customer) can be deployed on an instance of R1 only, an instance of R2 only, or a combination of some instances of R1 and R2. Similarly, the combination of firewalls follows the same pattern. The service template constructed by the SME using the recipe builder can handle all possible combinations. In this example, the SME follows the following steps:

[0084] 1. Define the type of device used in the connection by specifying the pairing of device type and protocol. For example:

[0085] a.R1 is connected via NETCONF

[0086] b.R2 connected via CLI

[0087] c.F1 via REST connection

[0088] d.F2 connected via SOAP

[0089] 2. Create the target pattern object class:

[0090] a. For devices using NETCONF and SOAP-based connections, import the complete machine-readable schema (YANG for R1 via NETCONF; WSDL for F2 via SOAP). This step causes the recipe builder to dynamically create all supported target schema object classes (i.e., the target schema object class corresponding to each manageable resource described in the machine-readable schema).

[0091] b. For devices with CLI and REST-based connections, SME manually creates each required target schema object class that will be needed during subsequent steps.

[0092] c. The examples in step 2 include the following resources:

[0093] IP interfaces on i.R2 and F1

[0094] ii. IP interfaces on R2 and F1V

[0095] iii. RF on R2 and F1

[0096] iv. VRF on R2 and F1

[0097] BGP Neighbors on v.R2

[0098] access control list on vi.F1

[0099] vii.F1 Trust Zone

[0100] 3. For each of the target pattern object classes of interest from steps 2a and 2b, create a modified target object class, which in some embodiments is a variant of a constrained and / or annotated resource. Here, the SME is simplifying the full complexity and capabilities of the resource in a way that will be consumable by the operator, who will ultimately be responsible for the actual joining and management within the operating network.

[0101] 4. Group the target object classes of the modified items into sub-recipes based on the connected device types and their logical relationships. Examples include:

[0102] a. Routing interfaces on R1, including target objects modified for R1's IP interfaces and target objects modified for R1's BGP neighbors.

[0103] b. Routing interfaces on R2, including target objects modified for R2's IP interfaces and target objects modified for R2's BGP neighbors.

[0104] c. Trust zones on F1, which include target objects modified for F1's trust zones and target objects modified for F1's IP interfaces.

[0105] d. Trust zones on F2, which include target objects modified for F2's trust zones and target objects modified for F2's IP interfaces.

[0106] 5. Group sub-formulas together to form multi-supplier formulations. Example:

[0107] a. Routing interfaces, which include routing interface sub-recipes for R1 and routing interface sub-recipes for R2.

[0108] b. Trust interface, which includes a trust interface sub-formula for F1 and a trust interface sub-formula for F2.

[0109] 6. Optionally, parameters can be merged across all levels to avoid duplicate parameter inputs from the operator when values ​​should be forced to be the same. For example, regardless of whether a router of type R1 or R2 is used for a service instance, the names of the created IP interfaces should be the same - merging will be used to aggregate the IP interface names required by the IP interface sub-recipes of R1 with the same IP interface names required by the IP interface sub-recipes of R2.

[0110] 7. Export the completed service template from the recipe builder.

[0111] 8. Import the completed service template into the recipe trading platform.

[0112] 9. Operators can now use service templates to create, retrieve, update, delete, and verify instances of L3 VPN services.

[0113] While some embodiments of this disclosure have described data automation techniques for telecommunications applications, the systems and methods described herein are also applicable to other applications using agentless targets. As mentioned above, agentless targets are typically targets that require continuous configuration. Unlike agent-based targets, where updates can be pulled from a server, updates associated with agentless targets require more frequent and / or more application-specific updates, for which pulling said updates from a server is not feasible. An example of an agentless application is factory automation. Robotic parts in a factory may require incremental configuration (e.g., robotic parts in an assembly line).

[0114] The subject matter described herein can be implemented as digital electronic circuits or computer software, firmware, or hardware (including structural means disclosed herein and their structural equivalents) or combinations thereof. The subject matter described herein can be implemented as one or more computer program products, such as one or more computer programs tangibly embodied in an information carrier (e.g., in a machine-readable storage device) or embodied in a propagating signal for execution by or control of a data processing apparatus (e.g., a programmable processor, computer, or multiple computers). Computer programs (also referred to as programs, software, software applications, or code) can be written in any form of programming language (including compiled or interpreted languages) and can be deployed in any form (including as standalone programs or as modules, components, subroutines, or other units suitable for use in a computing environment). A computer program does not necessarily correspond to a file. A program can be stored as a portion of a file containing other programs or data, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., a file storing portions of one or more modules, subroutines, or code). Computer programs can be deployed to be executed on one or more computers at a single site or distributed across multiple sites and interconnected via a communication network.

[0115] The processes and logic flows described in this specification (including the method steps of the subject matter described herein) can be executed by one or more programmable processors that execute one or more computer programs to perform the functions of the subject matter described herein by manipulating input data and generating output. These processes and logic flows can also be executed by special-purpose logic circuitry (e.g., an FPGA (Field-Programmable Gate Array) or an ASIC (Application-Specific Integrated Circuit)), and the apparatus of the subject matter described herein can be implemented as special-purpose logic circuitry, such as an FPGA or an ASIC.

[0116] As an example, processors suitable for executing computer programs include both general-purpose and special-purpose microprocessors, as well as any one or more processors in any type of digital computer. Generally, a processor receives instructions and data from read-only memory or random access memory, or both. Essential components of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices (e.g., magnetic disks, magneto-optical disks, or optical disks) for storing data, or operatively coupled thereto to receive data or transfer data to or to them, or both. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including, as examples, semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices); magnetic disks (e.g., internal hard disks or removable disks); magneto-optical disks; and optical disks (e.g., CDs and DVDs). The processor and memory may be supplemented or incorporated into dedicated logic circuitry.

[0117] To provide interaction with the user, the subjects described herein can be implemented on a computer having a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user. For example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback) and can receive input from the user in any form, including acoustic, speech, or tactile input.

[0118] The subject matter described herein can be implemented as a computing system, including back-end components (e.g., data servers), middleware components (e.g., application servers), or front-end components (e.g., client computers having a graphical user interface or web browser through which their users can interact with embodiments of the subject matter described herein), or any combination of such back-end, middleware, and front-end components. Components of the system can be interconnected via any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include local area networks (“LANs”) and wide area networks (“WANs”), such as the Internet.

[0119] It should be understood that the disclosed subject matter is not limited in its application to the details of construction and arrangement of components set forth in the following description or shown in the accompanying drawings. The disclosed subject matter can have other embodiments and can be practiced and implemented in various ways. Furthermore, it should be understood that the wording and terminology used herein are for descriptive purposes and should not be considered limiting.

[0120] As such, those skilled in the art will understand that the concepts upon which this disclosure is based can be readily utilized as the basis for the design of other structures, methods, and systems for achieving several of the objectives of this disclosure. Therefore, it is important that the claims be considered to cover such equivalent constructions, provided they do not depart from the spirit and scope of this disclosure.

[0121] Although the disclosed subject matter has been described and illustrated in the foregoing exemplary embodiments, it should be understood that this disclosure is made by way of example only, and various changes may be made in the details of the implementation of the disclosed subject matter without departing from the spirit and scope of the disclosed subject matter as limited only by the claims to which it is followed.

Claims

1. A method for constructing a service template, the service template supporting the automation of service provisioning to mobile network customers, the method comprising: Create a target schema object class that includes multiple data fields, wherein the target schema object class represents a class that is at least partially based on a configurable telecommunications network resource based on a device type; A modified target object class is created based on the target pattern object class, wherein the modified target object class includes specified values ​​for at least some of the plurality of data fields in the target pattern object class; Receive a request to create at least one sub-recipe, the at least one sub-recipe including the modified target object class, one or more other modified target object classes, and data indicating the association between the modified target object class and the one or more other modified target object classes; as well as The recipe for defining a telecommunications network service instance is processed, wherein the recipe includes at least one sub-recipe, wherein the telecommunications network service instance includes a plurality of service instance data fields that are pre-filled or not pre-filled based at least in part on the specified values ​​indicated by the modified target object class within the at least one sub-recipe, wherein the plurality of service instance data fields that are not pre-filled according to the modified target object class within the at least one sub-recipe can be customized by the operator for a specific device, and includes the target object class of the at least one sub-recipe and the modified target object class constrained by the same target type associated with the telecommunications network service instance and the same connector type associated with the telecommunications network service instance.

2. The method according to claim 1, further comprising: Determine multiple sub-recipes that share a common target object class, wherein the common target object class exists in each of the multiple sub-recipes; as well as Receive parameters for merging the target object class that is jointly modified, wherein the parameters for merging include a set of values ​​for the data fields of the target object class that is jointly modified.

3. The method according to claim 1, wherein creating the modified target object class further includes receiving the specified value.

4. The method according to claim 1, wherein: The method further includes receiving a request to create the target pattern object class; The request includes object parameters; and The specified value is derived from the object parameter.

5. The method according to claim 1, further comprising: Receive a first request to create a device type category for the connection, wherein the device type category of the connection is associated with devices and protocols in the mobile network; as well as Receive a second request to create the target pattern object class, wherein the target pattern object class is associated with the device type category of the connection.

6. The method of claim 1, wherein the class of configurable telecommunications network resources includes a type of network endpoint capable of exchanging messages between entities in the telecommunications network.

7. The method according to claim 1, wherein the telecommunications network service instance is one or more of a Virtual Network Function (VNF), a Physical Network Function (PNF), or a network application implemented on a device within a telecommunications network.

8. A method for constructing a service template, the service template supporting the automation of service provisioning to mobile network customers, the method comprising: At the computing device, a first request is received to create a device type category for the connection, wherein the device type category of the connection is associated with devices and protocols in the mobile network; The computing device receives a second request to create a target pattern object class associated with the device type category of the connection, wherein the second request includes object parameters associated with the target pattern object class, wherein the object parameters include at least one of the device type of the device and the protocol, and wherein the target pattern object class represents a class of configurable telecommunications network resources based on the device type and the protocol; At the computing device, multiple data fields are retrieved based on the object parameters, the multiple data fields representing the capabilities of the device; Create the target schema object class that includes the multiple data fields; A modified target object class is created based on the target pattern object class, wherein the modified target object class includes specified values ​​for at least some of the plurality of data fields in the target pattern object class; Receive a request to create at least one sub-recipe, the at least one sub-recipe including the modified target object class, one or more other modified target object classes, and data indicating the association between the modified target object class and the one or more other modified target object classes; as well as The recipe for defining a telecommunications network service instance is processed, wherein the recipe includes at least one sub-recipe, wherein the telecommunications network service instance includes a plurality of service instance data fields that are pre-filled or not pre-filled based at least in part on the specified values ​​indicated by the modified target object class within the at least one sub-recipe, wherein the plurality of service instance data fields that are not pre-filled according to the modified target object class within the at least one sub-recipe can be customized by the operator for a specific device, and includes the target object class of the at least one sub-recipe and the modified target object class constrained by the same target type associated with the telecommunications network service instance and the same connector type associated with the telecommunications network service instance.

9. The method according to claim 8, further comprising: The computing device determines multiple sub-recipes that have a common target object class, wherein the common target object class exists in each of the multiple sub-recipes; as well as The computing device receives parameters for merging the target object class that is jointly modified, wherein the parameters for merging include a set of values ​​for data fields of the target object class that is jointly modified.

10. The method of claim 8, further comprising, wherein creating the modified target object class further comprises receiving the specified value by the computing device.

11. The method according to claim 8, wherein: The telecommunications network service instance also includes a target instance; and The target instance includes at least one of a virtual telecommunications network function, a physical telecommunications network function, or a telecommunications network application.

12. The method of claim 8, wherein the configurable telecommunications network resources include at least one of quality of service, rating groups, billing plans, and packet filters.

13. The method of claim 8, wherein the protocol comprises at least one of the following: Representational State Transition (REST) ​​protocol, Structured Query Language (SQL) protocol, Simple Object Access Protocol (SOAP), Secure File Transfer Protocol / Secure Shell Protocol (SFTP / SSH), Simple Network Management Protocol (SNMP), and Network and Configuration Protocol (NETCONF).

14. A system for constructing service templates, the service templates supporting the automation of service provisioning to mobile network customers, the system comprising: One or more processors; Memory, communicating with the one or more processors; as well as Instructions stored in the memory, which are executable by the one or more processors to: Create a target schema object class that includes multiple data fields, wherein the target schema object class represents a class that is at least partially based on a configurable telecommunications network resource based on a device type; A modified target object class is created based on the target pattern object class, wherein the modified target object class includes specified values ​​for at least some of the plurality of data fields in the target pattern object class; Receive a request to create at least one sub-recipe, the at least one sub-recipe including the modified target object class, one or more other modified target object classes, and data indicating the association between the modified target object class and the one or more other modified target object classes; as well as The recipe for defining a telecommunications network service instance is processed, wherein the recipe includes at least one sub-recipe, wherein the telecommunications network service instance includes a plurality of service instance data fields that are pre-filled or not pre-filled based at least in part on the specified values ​​indicated by the modified target object class within the at least one sub-recipe, and wherein the plurality of service instance data fields that are not pre-filled according to the modified target object class within the at least one sub-recipe can be customized by the operator for a specific device, and includes the target object class of the at least one sub-recipe and the modified target object class constrained by the same target type associated with the telecommunications network service instance and the same connector type associated with the telecommunications network service instance.

15. The system of claim 14, wherein the instructions are additionally executable by the one or more processors to: Determine multiple sub-recipes that share a common target object class, wherein the common target object class exists in each of the multiple sub-recipes; and Receive parameters for merging the target object class that is jointly modified, wherein the parameters for merging include a set of values ​​for the data fields of the target object class that is jointly modified.

16. The system of claim 14, wherein creating the modified target object class further includes receiving the specified value.

17. The system according to claim 14, wherein: The instructions are additionally executable by the one or more processors to receive a request to create the target pattern object class; The request includes object parameters; and The specified value is derived from the object parameter.

18. The system of claim 14, wherein the class of configurable telecommunications network resources includes a type of network endpoint capable of exchanging messages between entities in the telecommunications network.

19. The system of claim 14, wherein the telecommunications network service instance is one or more of a Virtual Network Function (VNF), a Physical Network Function (PNF), or a network application implemented on a device within a telecommunications network.

Images