Patent Application
20200366743
Embodiments of the invention relate to the enactment of a process model using model-driven techniques.
Cloud computing is a major breakthrough in recent years in computer science, and is a very efflorescent domain, being more and more used by everyone (from individual customers to IT companies). In essence, cloud computing is the domain of virtual machines, which are entities that only exist in the memory of other machines. A main goal of cloud computing is to provide infrastructure, platform and software as a service, shielding users from most of the technicalities that come when building and maintaining physical machines by providing virtual computing, storage and network. Indeed, a network node, or more generally a network function can be virtualized, leading to what is called a Virtual Network Function (VNF), in an overall process called Network Function Virtualization (NFV). NFV enables the design of an entire service (including servers, router, firewall and so on) that can be hosted on a machine, virtual or physical.
The NFV paradigm is making way for the rapid provisioning of network services (NS). Defining a process for the design, deployment, and management of network services and automating the process is therefore highly desirable and beneficial for NFV systems. Automating the end-to-end management of network services, that is, enacting the workflow or process for network service management without manual intervention remains a major challenge for network operators and service providers. The European Telecom Standards Institute (ETSI) has recently launched a zero-touch network and service management group. The challenges of 5G also trigger the need for a radical change in the way networks and services are managed and orchestrated.
The wide variety of technologies, needs, users and designers makes it difficult to create a proper network service, especially with respect to requirements such as availability.
The use of model-driven orchestration means has been recently advocated in the context of NFV systems. Model management approaches sometimes use megamodels which provide structures to avoid the so-called “mega-muddle,” that is, a complicated set of relations between resources leading to an occultation of their semantics, their origins, where they are involved, etc. A megamodel contains artifacts (which include models), relations between them (which include transformations), and other relevant metadata. Megamodels have already been used in various domains, especially in software engineering. Megamodels can be tailored to fit specific needs; however, their high level of abstraction makes them difficult to use as they are.
In one embodiment, a method is provided for automating design and management of network services. The method comprises obtaining a process model which models activities and ordering among actions in a process for the network services. Each activity includes a set of actions and each action is associated with a model-based transformation which transforms one or more input models into one or more output models. The method further comprises: constructing a megamodel which incorporates the process model and describes relations among resources to be used by model-based transformations of the process model, wherein the resources include models and meta-models; generating, based on the megamodel, a transformation chain containing coordinated sequences of the model-based transformations; and enacting the transformation chain to thereby enact the process model for the network services.
In another embodiment, there is provided a network node comprising processing circuitry and memory. The memory stores instructions executable by the processing circuitry to automate design and management of network services. The network node is operative to obtain a process model which models activities and ordering among actions in a process for the network services. Each activity includes a set of actions and each action is associated with a model-based transformation which transforms one or more input models into one or more output models. The network node is further operative to: construct a megamodel which incorporates the process model and describes relations among resources to be used by model-based transformations of the process model, wherein the resources include models and meta-models; generate, based on the megamodel, a transformation chain containing coordinated sequences of the model-based transformations; and enact the transformation chain to thereby enact the process model for the network services.
In yet another embodiment, there is provided a network node operable to automate design and management of network services. The network node includes an input module operative to obtain a process model which models activities and ordering among actions in a process for the network services. Each activity includes a set of actions and each action is associated with a model-based transformation which transforms one or more input models into one or more output models. The network node further includes a megamodel construction module operative to construct a megamodel which incorporates the process model and describes relations among resources to be used by model-based transformations of the process model, wherein the resources include models and meta-models. The network node further includes a transformation chain generation module operative to generate, based on the megamodel, a transformation chain containing coordinated sequences of the model-based transformations; and an enactment module operative to enact the transformation chain to thereby enact the process model for the network services.
Other aspects and features will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments in conjunction with the accompanying figures.
Embodiments will now be described, by way of example only, with reference to the attached figures.
In the following description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description. It will be appreciated, however, by one skilled in the art, that the invention may be practiced without such specific details. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.
Embodiments of the invention provide a model-driven approach for automated process enactment. The approach combines the orchestration of model transformation chains with model management means. To begin with, a process is modeled as a process model (PM) which is obtained as input. The process model includes activities and actions. The activities in the process model include actions and may embed other activities, and an activity may be unfolded recursively into actions. Actions are associated with model-based transformations. Model-based transformations include transformations that are themselves models or executable programs (e.g. in machine code). Input and output objects of the model-based transformation are model instances of existing domain-specific language(s).
A megamodel (MgM) is built for model management. The megamodel contains information of all resources used by the model-based transformations of the process model, as well as the link(s) (representing the relations) between these resources. The resources include models and meta-models. The process model itself is also a resource which is registered in the megamodel. To enact the process model, the megamodel is used to build a transformation chain. Token-based enactment means may be implemented to orchestrate the transformation chain.
An enactment tool has been created with NFV systems as the target domain. The model-driven approach and the tool support are not restricted to NFV, and can be used in various other domains for process enactment.
In the disclosed approach, transformation chaining is used for modeling the orchestration of different model-based transformations. A transformation chain includes coordinated sequences of model-based transformations. Orchestration languages may be used for the composition of the transformations. A transformation chain may include sequential steps of transformations. A transformation chain may also include a complex chain which incorporates conditional branches and loops; alternatively or additionally, a transformation chain may include a composite chain, which is a chain including other transformation chains.
The enacter described herein is a generic enacter that can adapt to different kinds of process models. Having a generic enacter enables the integration of different formalisms for modeling the process model, instead of having an enacter for each kind of process model.
In classical engineering, and especially computer and software engineering, software designers are often focused on low-level considerations or implementation details, e.g. specific behaviors, algorithms or data structures. However, most of the time, this focus occults the real difficulties of the studied problem, and brings the risk of creating a solution that is highly specific and hardly adaptable, which is a major flaw when it comes to the real world filled with a broad diversity of machines, systems and technologies. In this regard, creating an abstract representation (e.g. model) of the subject of the studied problem can greatly help to master the problem and to design a solution, which can then be implemented with low-level constraints. This methodology is called Model-Driven Engineering (MDE).
The following provides some definitions of MDE terminologies.
Definition 1 (Models). A model is a set of objects and relations between them.
Definition 2 (Meta-models and Conformance Relationship). A model abides by specific rules, which form a meta-model. That is, the model conforms to the meta-model. In other words, there is a conformance relationship between the model and the meta-model.
It is noted that a meta-model can also be represented as a model, and therefore can conform to another meta-model, which is called a meta-meta-model. Also, a model can conform to itself (e.g. Ecore).
Definition 3 (Transformations). A transformation represents a process on models, with associated inputs and outputs specifications (i.e. constraints on the input/output models, typically in the form of meta-models to which those input/output models conform).
Definition 4 (Megamodels). A megamodel is a structure containing models as well as relations between the models. More precisely, a megamodel is a model which has other models as objects.
The basic idea of megamodels is that everything is a model: models, meta-models, transformations and even other resources; and models can be linked together through relations, typically, conformance (as in Definition 2), and also derivation (when a model is the result of a transformation) and cross-referencing (when an object in a model is used in another model). A megamodel is a map for finding and linking together all involved models. A megamodel can be used to enforce conformance and compatibility checks between the various models and transformations. A megamodel is also useful for reusing and composing transformations in transformation chains.
The above definition of megamodels expresses a general idea of megamodels, leaving to users a choice of what, how, and to what extent to put into the megamodels. For example, a user may add a specific type of relation or remove a cross-reference relationship in the megamodel. In other words, a megamodel is a structure that contains models. What gets to put inside the megamodel is entirely up to the user.
The megamodels described herein have a high level of traceability. Every mutation (e.g. as a result of a transformation or induced by a user) that can happen to a resource can be registered with the megamodels. A megamodel with such a traceability support can be used as a repository, and enables a user to trace the version of every resource, the origin of the resources (e.g. as a result of a transformation or provided by the user), the location of the resources, whether a resource exists, etc.
Definition 5 (Process Model). A process model is a model which contains: (a) Actions: representing a task or a set of tasks, inputs and outputs, where the inputs and outputs are, in general, models; (b) Control flows: directed links between those actions that establish the order in which the actions are to be executed; and (c) Object flows: links between the inputs and outputs of actions, allowing for using the output of an action as the input of another.
A process model is used to model a process. A process model describes the ordering of various actions as well as how to interface the actions. A process model can be extended in numerous ways, thus enabling its users to define more refined structures. For example, some of the following additional concepts may be used in process models: (a) Initial and final nodes: special actions specifying respectively the beginning and the end of a process model. (b) Parallelization: actions that do not depend on each other can be executed in parallel. (c) Decision: depending on various criteria (a condition), the execution of a process model can omit some branches. (d) Parameters and Outputs: (also referred as object nodes) a way to express what can be fed in the process model or its actions and what can be retrieved from them. (e) Nested behaviors: a process model can be used to express the actual behavior of an action, leading to the definition of specific actions that actually refers to other process models.
The semantics of the process model includes: (a) Two actions that are linked with a control flow (which, being directed, has a beginning and an end), the action at the beginning is executed just before the action at the end. In this case, the actions are said to be sequential. (b) When having two sequential actions, the second one is executed only when the first one has finished. (c) Object nodes that are linked share the exact same data.
As an example, Unified Modeling Language (UML) 2.0 Activity Diagrams may be used to represent and visualize a process model. It is also possible for processes to be modeled with some other workflow modeling language, for instance, BPMN. A person skilled in the art would understand that a process model could be based on another language or technology.
Activity diagrams are typically used to model software and business processes. These diagrams allow the modeling of concurrent processes and their synchronization with the use of forks and joins. Both control flow and object flow can be depicted in the model. An activity node can be either a simple action (representing a single step within an activity) or an activity (representing a decomposable activity which embeds actions or other activities). An activity specifies a behavior that may be reused, i.e. an activity can be included in other activity diagrams to invoke a behavior. Along with the activities, the input and output models associated with each activity are also clearly identified via input and output parameter nodes (denoted by the rectangles on the activity border). Since UML 2.0 Activity Diagrams are given semantics in terms of Petri Nets, the precise formal semantics allow the activity diagrams to be simulated and analyzed.
In one embodiment, the Eclipse Papyrus Activity Diagram environment may be used to create a process model. The process model instance conforms to the activity diagram language. Each process model includes one or more activities, which are decomposable into actions. The behavior of each action is implemented with a model-based transformation. The attributes of activity nodes in the activity diagram provide information about the associated transformations. Each action in the process model is also associated with a set of input and output models. With Papyrus, all meta-models are mapped to profiles to allow model instances to be created and to be used as source or target models of the transformations.
Actions are represented as rounded rectangles. Object nodes are represented as (not rounded) rectangles. Some object nodes are “attached” to the action, which means they represent an input or an output of that action. The other nodes correspond to general parameters and outputs of the process model. The initial node is represented as a dark circle, the final node as a double circle. Control flows are represented by filled arrows. Object flows are represented by dash arrows. Decision is represented as the “D” diamond. A tiny black diamond represents the end of the branches of the decision (often called merge). Parallelization is represented in between two elongated rectangles (the first rectangle is called fork and the second one is called join).
The following is a description of megamodels. One main issue in resource management is how to centralize information about resources for easy access. This issue may be resolved by devising a transformation which is expressed using heterogeneous technologies. A transformation may be an executable program (e.g. in machine code) or a model conforming to a specific meta-model, for instance, ATL, QVT, Epsilon, Java, etc.). Transformations define a precise configuration as to what to be fed in and pulled out from. This disclosure describes the use of megamodels for model management. The megamodel can be built incrementally in two steps: 1) by registering the resources, and then 2) by registering the process model.
Registering the resources: To begin with, the resources (i.e., models and meta-models/profiles) which are part of the target project are registered in the megamodel. This is carried out automatically by going through the project workspace (referred to as workspace discovery), and an initial megamodel is derived at this stage.
Registering the process model: Following the workspace discovery, the initial megamodel is incrementally built by carrying out a process model discovery. This step includes registering the process model and the associated transformations in the megamodel. Thus, the process model is incorporated into the megamodel. The process model is linked with the elements of the rest of megamodel (i.e., the parts of the megamodel outside the process model) using externalized links delegated to another system called a weaving model, which is not the process model nor the megamodel. Thus, users can reach all relevant information to enact the process model, and no constraint is imposed on the structure of the process model, effectively decoupling its meta-model from the megamodel. That is, there is no reference to the megamodel in the process model. The weaving model binds every relevant element of the process model to their corresponding resources in the megamodel, without touching the structure of either of them. The links between the process model and the rest of the megamodel are created by weaving the process model and the megamodel and storing the details in a weaving model, as will be defined below in Definition 6.
Definition 6 (Weaving model) A weaving model is a special kind of model that defines relations between the objects and relations of other distinct models (at least two). These relations are the objects of a weaving model, which is based entirely on cross-referencing.
The weaving model is dependent on the process model. In other words, the weave meta-model is specific to the process model language that it weaves. Thus, if a designer adapts the environment for another process model language (e.g., expressed with BPMN), it would be necessary to create a new weaving model to bind the new type of process model with the megamodel. Further details about the weaving model will be provided with reference to
The meta-model of a megamodel (also referred to as the meta-megamodel) includes two parts: a core part, which only stores the basic information about the architecture, and the traceability part, which is a useful extension. This disclosure uses Ecore-based megamodeling. However, a person skilled in the art would understand that megamodeling could be based on another language or technology.
A specific UMLModel meta-class is provided because UML models can have one or more profiles applied to them. A UML model is thus a model conforming to UML and that can have profiles, which is unique to this case.
The Transformation meta-class: in addition to storing standard data (e.g. name and conformance), the Transformation meta-class also stores its full configuration; that is, the specification of what goes in and comes out of it, under the form of “in-outs” represented by the TransformationInOut meta-class. The TransformationInOut meta-class describes the in-out resources of a transformation. It stores the meta-model, profiles and direction of the specification (either IN or OUT; that is, each in-out resource is either an input resource or an output resource for a transformation), but also presents two attributes, reference and metamodelReference, which are the names by which the model and meta-model are referred to inside the transformation.
Typically, in a transformation (e.g. an ATL transformation), the meta-models and in-outs are referred to using their aliases. The use of aliases allows, among other things, to avoid specifying the model directly inside the transformation, thus making the transformation reusable.
An analogy may be drawn on defining the prototype of the transformation in a programmatic point of view. The meta-model reference is the name of the type (which will correspond later to an actual implementation) and the model reference is the name of the parameter (which will be filled in when executing the transformation).
The megamodel further includes two special models: WeavingModel and ProcessModel. These two models allow a user to easily map a process model to its weave.
Every resource is given a history that traces everything that happened to it.
Every resource is given metadata, which can be of any form (e.g. a version, an author, an encoding, etc.) and includes a timestamp to express how recent the resource is. This timestamp is used to sort the history.
Every resource is given an origin to express from where the resource comes from. For example, a resource provided by the user is labeled as [UserProvided], or a resource created as a result of a process is labeled as [Derived].
Every resource is given a uniform resource identifier (URI), that is, a way to access the actual content it represents. There is also a flag called “exists” that states whether or not the resource exists. For example, the result of a transformation that has not been launched does not yet exist.
Transformations hold a trace, that is, a list of every execution that happened. A resource can then be specified as being the result of a transformation, with the corresponding configuration (e.g. actual parameters that were being fed in the transformation).
The megamodels described above are generic. A megamodel conforms to the structure provided in
The weaving model maps each element of the process model to a corresponding resource. Some elements of the process model do not have to be mapped (e.g. control flows do not represent any resource), so in the end, the weaving model may not be “complete”, in that it may not contain every element of the process model.
Regarding the object nodes and object flows, it is noted that object nodes linked with one or several object flow(s) represent the same data, meaning that this data can be mapped to this object flow instead of being mapped to each element it links.
Moreover, object flows are one-to-many, meaning that an output can present several outgoing object flows but an input can only have one incoming. Thus, a set of object flows emanating from the same source and going to various targets can be mapped to the same data (model, meta-model and profiles). Basically, those considerations translate to the ObjectNodeMapping meta-class.
However, it is noted that this kind of mapping only links object flows to data; what still needs to be determined is which pin is mapped to which transformation configuration, so that in the end, an execution can be built to run the transformation. For that, an additional meta-class, InOutMapping, is used to link an input-output to a full object flow, providing information as to what goes in and comes out of the transformation it is linked to.
A process model is given translational semantics by mapping it to a transformation chain. The translation from a process model to a transformation chain takes the megamodel as input, which includes information of the process model, the weaving model, and, if applicable, additional environment information, and generates the corresponding transformation chain.
A transformation chain (also referred to as a schedule) is standalone (i.e. self-contained), meaning that it is sufficient in itself to be executed without the process model and the megamodel. A schedule is generic. Some transformations that are not directly dependent on each other may be executed in parallel.
The actual behavior of an action is expressed through a handlerClass attribute. When the handlerClass attribute is associated with an enacter the action becomes meaningful and may represent a Java class, an ATL class, or a path to an executable program, etc. The children classes of ParameterValue specify the way parameters are expressed.
In addition to this meta-model, the following constraints are imposed on a schedule to control the flow of actions: (a) An action has at most one previous node and at most one next node. (b) An action with no previous node is called initial and an action with no next node is called final. (c) A fork node has at most one previous node and has at least one next node. (d) A join node has at most one next node and has at least one previous node.
In one embodiment, the schedule is associated with token-based semantics, which includes: (a) Tokens are circulating in the schedule. At every moment, one or several nodes (actions, fork or join) have a token, in which case it is said it has the control. (b) When an action receives a token, it is executed. When the action is done, it passes its token to its next node. (c) When a fork node receives a token, it passes a token to each of its next nodes, at the same time. (d) When a join node receives as many tokens as it has previous nodes, it passes one token to its next node.
Initially, a token is given to every initial node. The execution ends whenever every token circulating cannot be passed further (typically: the only nodes having a token are the final ones). Therefore, the enacter is based on controlling the tokens and activating the actions when needed.
After generating the transformation chain of actions, this chain is executed by an enacter. An enacter is a program that can execute the correct actions in the right order, based on a schedule model. An enacter does not order the actions; an enacter reads the schedule model and acts accordingly.
The enactment system 800 includes support for enacting a chain of transformations in ATL, Java, other transformation languages, or executable programs. The enactment system 800 allows for the enactment of activities in process models which include executable actions. This extension allows transformations to be written in any general purpose programming language (e.g. Java, C, Python) or executable code. It also supports other types of input and output models to be associated with activities besides UML models, such as Ecore or XMI. This feature allows integration and reuse of legacy code in the process model.
A loader subsystem 810 is centered around a loading engine 811 and also includes Resources 812 (e.g. models and meta-models), EncoreLoader, UMLLoader, ATLLoader and QVTLoader. Loaders for other languages (e.g., Java) or executable code may also be included.
The loader subsystem 810 provides a high-level interface with the actual resources of a system (i.e. a file system). The loader subsystem 810 is able to recognize the correct way of loading a file and to extract relevant data from the file into the megamodel, for example. Typically, when attempting to register a file in the megamodel, a discovery engine 821 requests the loading engine 811 to load the file so that data can be extracted from the file. Defining loaders allows different technologies to be incorporated into the enactment system 800, making the enactment system 800 capable of understanding new formats.
A registration subsystem 820 is centered around the discovery engine 821. The “discovery” is the process by which a resource is added to the megamodel. It includes the recognition of the resource (determining that it is a meta-model, a transformation, a profile, etc.) as well as the extraction of its data (Uniform Resource Identifier (URI), name, inputs and outputs, etc.). As in the case of the loaders, a custom discoverer may be developed. For instance, as shown in
The registration subsystem 820 is also the place that weaves the process model to the megamodel, with the help of a weave engine 822. As the weave is entirely dependent on the process model language, it is noted that the weaving process is completely devolved to the discoverer, which provides both a specific weaver (an implementation) as well as filling it.
A management subsystem 830 is centered around a megamodel manager 831 and also includes the megamodel and a user interface. The subsystem 830 allows a user to access the megamodel, such as: request to register a resource, create or delete a megamodel, etc. The subsystem 830 also includes an extensive API for manipulating the megamodel, ensuring its validity throughout the process.
A translation subsystem 840 revolves around a translation engine 841 and also includes a PMtranslator. The translation subsystem 840 provides the translation of a process model to a schedule (i.e. a transformation chain) that can be enacted. The translation subsystem 840 exposes an extension point that allows users to plug their own translation means (e.g. a translation algorithm or other types of translators) if ever the users want to use another type of process model.
A scheduling and enactment subsystem 850 includes two subparts: a generic enacter (enacter 851) and an interface between the enacter 851 and the remaining part of the project, through a ProcessModelEnacter. The enacter 851 is independent of the project, and is shown inside the dashed box labeled “Enactment core” which also includes the Chain and Handlers. The interface allows to include language handlers such as QVTHandler and ATLHandler. Other language handlers, such as JavaHandler and/or ProcessHandler (which handles executable code), may also be included, for example, for interacting with a managed system.
A Launcher 861 orchestrates everything needed to execute the process model, which includes translating the process model into a transformation chain and enacting the chain. The launcher 861 also manages enactment configurations (i.e. data associated with the process model to translate and enact it), which may be stored as a standard Eclipse launch configuration.
A simple example of process model enactment is presented in the following with reference to
NFV Case Study. Automating network service design and management is one of the challenges in the NFV domain. The following example demonstrates the enactment of the network service (NS) design process, which is one of the activities of the NS management process.
An NS, such as VoIP, is a composition of Network Function(s) (NF) and/or other NSs, interconnected with one or more Forwarding Graphs (FG). These graphs interconnect the NFs and describe the traffic flow between them. Virtualized Network Functions (VNF) are the building blocks of an NS in NFV. VNFs are software pieces that have the same functionality as their corresponding Physical Network Functions (PNF), e.g., a virtual firewall (vFW) vs. a traditional firewall device. The design of an NS consists of defining an NS Descriptor (NSD), which is a deployment template capturing all this information. This template is provided to the NFV Orchestrator for the NS lifecycle management.
Coming up with the deployment template for an NS is not an easy task for an inexperienced tenant who has limited knowledge regarding the details of the target NS. Instead of these details, the tenant may request at some level of abstraction the functional and non-functional characteristics of the targeted NS. The gap between these NS requirements (NSReq) and the NS deployment template is filled with an automated NS design method. With the help of a network function ontology (NFOntology), it is indeed possible to fill this gap and design automatically NSDs from NSReqs. The NF ontology captures the known NF/service decompositions and their (standard) architectures. In the NS design method, the NSReq decomposition is guided by the NFOntology to a level where proper network functions can be selected from an existing VNF catalog. After the selection of the VNFs, the method continues with the design of the forwarding graphs given the characteristics of the selected VNFs and their dependencies. This generates a set of forwarding graphs, which are refined further based on the non-functional requirements in the NSReq, resulting in the target NSD. As a final step, the NF ontology is enriched with the new decompositions. It is also possible to enrich the NF ontology with new standards and new services. Please note that the goal of this disclosure is not to describe the details of the NS design method but to show how the process is enacted using the disclosed method and tool.
When a request is received to enact the process model, the NS design process model 1200 is mapped to the transformation chain 1300 (
The process model enactment approach described above has been applied to the enactment of the entire NS design and management process. NS lifecycle management includes, among others, the activities such as onboarding, instantiation, configuration, scaling, update, and termination of network services. Each activity in the NS lifecycle management involves a complex chain of tasks (i.e. actions), which may be modeled by a process model. The process model can then be mapped on to a composite chain of transformations along with a megamodel to allow for automated deployment and management of network services.
A tool has been implemented in the form of an extension of Papyrus/Eclipse. However, a person skilled in the art would understand that a similar tool could be based on another language, technology, or development tool(s). In one embodiment, the resulting tool targets network service designers.
The tool hides megamodels from users to prevent users from damaging the megamodels inadvertently with incorrect addition. The megamodel is manipulated through an interface (a user interface for the user and an API for the developer). A user may have several megamodels at the same time. The tool is extensible. The tool adapts to any technology, any transformation type/engine, and any structure of the process model. In the following, an overview of the user interface of the tool is provided.
The user interface provides two types of menu: a global menu which allows the user to access the global operations on megamodel (
A megamodel is specified by its name. The system will deny the creation of a megamodel with the same name as an already existing one, unless the “Overwrite existing” checkbox has been checked. Additionally, the validity of the megamodel's name is verified. In case the name is not valid, the “OK” button is disabled, preventing the user to accept an invalid name, and an error message is printed in the dialog (e.g. below the title).
When selecting the menu entry “Register to Megamodel . . . ” (
As an example, Eclipse's launch configuration system (accessible via the “Run” menu) may be used for the enactment of a process model. A process model launch configuration is characterized by a megamodel, a process model and a specific translator (provided through an extension point). Eclipse enables a user to define a custom UI to manage the configuration, an example of which is presented in
The method 1700 begins with the system at step 1710 obtaining a process model which models activities and ordering among actions in a process for the network services. Each activity includes a set of actions and each action is associated with a model-based transformation which transforms one or more input models into one or more output models. The system at step 1720 constructs a megamodel which incorporates the process model and describes relations among resources to be used by model-based transformations of the process model. The resources include models and meta-models. The system at step 1730 generates, based on the megamodel, a transformation chain containing coordinated sequences of the model-based transformations. The system at step 1740 enacts the transformation chain to thereby enact the process model for the network services.
In some embodiments, some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines implemented in one or more virtual environments 2000 hosted by one or more of hardware nodes 2030. Further, in embodiments in which the virtual node is not a radio access node or does not require radio connectivity (e.g., a core network node), then the network node may be entirely virtualized.
The functions may be implemented by one or more applications 2020 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) operative to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein. Applications 2020 are run in virtualization environment 2000 which provides hardware 2030 comprising processing circuitry 2060 and memory 2090. Memory 2090 contains instructions 2095 executable by processing circuitry 2060 whereby application 2020 is operative to provide one or more of the features, benefits, and/or functions disclosed herein.
Virtualization environment 2000, comprises general-purpose or special-purpose network hardware devices 2030 comprising a set of one or more processors or processing circuitry 2060, which may be commercial off-the-shelf (COTS) processors, dedicated Application Specific Integrated Circuits (ASICs), or any other type of processing circuitry including digital or analog hardware components or special purpose processors. Each hardware device may comprise memory 2090-1 which may be non-persistent memory for temporarily storing instructions 2095 or software executed by processing circuitry 2060. Each hardware device may comprise one or more network interface controllers (NICs) 2070, also known as network interface cards, which include a physical network interface 2080. Each hardware device may also include non-transitory, persistent, machine-readable storage media 2090-2 having stored therein software 2095 and/or instructions executable by processing circuitry 2060. Software 2095 may include any type of software including software for instantiating one or more virtualization layers 2050 (also referred to as hypervisors), software to execute virtual machines 2040 as well as software allowing it to execute functions, features and/or benefits described in relation with some embodiments described herein.
Virtual machines 2040, comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 2050 or hypervisor. Different embodiments of the instance of virtual appliance 2020 may be implemented on one or more of virtual machines 2040, and the implementations may be made in different ways.
During operation, processing circuitry 2060 executes software 2095 to instantiate the hypervisor or virtualization layer 2050, which may sometimes be referred to as a virtual machine monitor (VMM). Virtualization layer 2050 may present a virtual operating platform that appears like networking hardware to virtual machine 2040.
As shown in
Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.
In the context of NFV, virtual machine 2040 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of virtual machines 2040, and that part of hardware 2030 that executes that virtual machine, be it hardware dedicated to that virtual machine and/or hardware shared by that virtual machine with others of the virtual machines 2040, forms a separate virtual network element (VNE).
Still, in the context of NFV, Virtual Network Function (VNF) is responsible for handling specific network functions that run in one or more virtual machines 2040 on top of hardware networking infrastructure 2030 and corresponds to application 2020 in
In some embodiments, one or more radio units 2026 that each includes one or more transmitters 2022 and one or more receivers 2021 may be coupled to one or more antennas 2025. Radio units 2026 may communicate directly with hardware nodes 2030 via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station.
In some embodiments, some signaling can be effected with the use of control system 2023 which may alternatively be used for communication between the hardware nodes 2030 and radio units 2026.
The above-described embodiments are intended to be examples only. Alterations, modifications and variations may be effected to the particular embodiments by those of skill in the art.
This application claims the benefit of U.S. Provisional Application No. 62/553,311 filed on Sep. 1, 2017.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/IB2018/056641 | 8/30/2018 | WO | 00 |
| Number | Date | Country | |
|---|---|---|---|
| 62553311 | Sep 2017 | US |
