System and method for virtualisation of mobile network function

TECHNICAL FIELD OF THE INVENTION

The present invention relates to a system and method for wireless data transmission, and in particular to a system and method for virtualizing a mobile network function.

Prior Art

Networks can be controlled using software based on automation tools with application programming interfaces (APIs).

The amount of data in mobile network operators (MNO) is increasing. Virtualization of the mobile network function (MNFV) establishes links between the areas of network formation, their interaction and applications in mobile networks. MNFV supports various types of infrastructure, including traditional mobile infrastructures, virtualized network functions (CloudEPC) and mobile platforms as a service (MPaaS). MNFV can work when installing a decentralized function, with the installation of a centralized function and intellectually distributed functions of mobile networks. In addition, MNFV can be used to disconnect hardware and physical resources, such as layouts, including a licensed and unlicensed spectrum, mobile virtual network (MVNO) operators and provision of other mobile services and implementation capabilities. In addition, MNFV can provide the ability to catalog, install and integrate network functions with network-level services (service binding) for the provided rich services, and to facilitate granular and standard mechanisms of mobile networks, service level and applications, for dynamic state exchange, level agreements services (SLA), resources and other information.

Summary of the Invention

The method in an embodiment for virtualizing a mobile network function (MNFV) includes forming a core of a deployed packet (EPC) cluster and associating a subnet with an EPC cluster. The method also includes downloading the virtual machine (VM) and attaching the VM to the EPC.

The method in an embodiment for virtualizing a mobile network function (MNFV) includes transmitting, via a controller, to an EMS (EMS) call control system, and transmitting, via a controller, to a cloud management system (CMS), a CMS call after a call transfer EMS. The method also includes receiving, using a controller from the EMS, an EMS response, in accordance with an EMS call and reception, using a controller from the CMS, a CMS response, in accordance with the CMS call.

The computer, in accordance with an embodiment, includes a processor and a permanent computer readable medium containing software for executing by the processor. The software includes instructions for forming an Enhanced Packet Core (EPC) cluster and associating a subnet with an EPC cluster. The software also includes instructions for downloading the virtual machine (VM) and attaching the VM to the EPC.

In the foregoing, a general overview of embodiments of the present invention has been presented to better understand the following detailed description of the invention. Further features and advantages of embodiments of the invention that form the subject matter of the claims will be described. It should be understood by those skilled in the art that the described concept and specific embodiments can be easily used as a basis for modifying or reconstructing other structures or processing for the same purpose of the present invention. It will also be understood by those skilled in the art that such equivalent structures are within the spirit and scope of the invention as set forth in the appended claims.

Brief Description of the Drawings

For a more complete understanding of the present invention and its advantages, reference is made to the following descriptions, which should be read in conjunction with the accompanying drawings, in which:

in Fig. 1 shows a diagram of a wireless network for data transmission;

in Fig. 2 illustrates a mobile network function virtualization (MNFV) system according to an embodiment;

in Fig. 3 shows another embodiment of the MNFV system;

in Fig. 4 shows an additional MNFV system;

in Fig. 5 shows an embodiment system for administering applications;

in Fig. 6 shows an embodiment system for an application program interface (API);

in Fig. 7 shows the mobile network operator (MNO) of the embodiment;

in Fig. 8 is a functional view of an Enhanced Packet Core (EPC) of an embodiment;

in Fig. 9 shows the architecture of an embodiment of an open mobile controller (OMS);

in Fig. 10 is a diagram of an OMS object in accordance with an embodiment;

in Fig. 11 shows a message flow diagram for the application programming interface (API) method;

in Fig. 12 shows another embodiment of the MNFV system;

in Fig. 13 is a flowchart for an embodiment of a method for forming an EPC cluster;

in Fig. 14 is a flowchart for an embodiment of a method for determining geographic areas;

in Fig. 15 is a flowchart for an embodiment of a method for simulating and interacting a mobile network;

in Fig. 16 shows a topology of an embodiment of a node;

in Fig. 17 shows an embodiment of a state machine for forming an EPC;

in Fig. 18 shows another system for MNFV;

in Fig. 19 shows an additional system for MNFV; and

in Fig. 20 is a block diagram of an embodiment of a general-purpose computer system.

The corresponding reference numbers and symbols in different figures generally refer to the corresponding parts, unless otherwise indicated. The figures are presented to clearly illustrate the respective aspects of the embodiments and are not necessarily shown to scale.

Detailed Description of Embodiments

First of all, it is to be understood that while an exemplary embodiment of one or more embodiments is provided below, the disclosed systems and / or methods can be implemented using any number of technologies, both known and existing at the present time. Disclosure should in no way be limited to the illustrative embodiments, drawings and technologies presented below, including exemplary structures and embodiments presented and described herein, but may be modified within the scope of the appended claims with the full scope of its equivalents.

The QuantumLeap (QL) module implementation is used when virtualizing the mobile network function (MNFV). In one embodiment, the QL module is installed as part of the controller. The controller can work together with the compute module and the network module. The database is used for the interface interface (API) of the north interface (NB), while the south interface API (SB) can form part of the public administration protocol for the vSwitch database (OVSDB) or the database administration system element (EMSDB). The API of the north interface is an API that allows, in particular, for a network component, to communicate with components of a higher level. Conversely, the southern interface is associated with lower-level components. The southern interface can be an OpenFlow ™ protocol, which facilitates the transfer of data between the network controller with a software definition (SDN) and physical and virtual network nodes, thus the router expands the network topology, determines the flows in the network and embodies the requests transmitted through the API of the north interface. The north interface can be a data area with protocol support between the controller and higher-level applications or programs. QL can provide a standard API for information technology (IT) communication tools, for implementing northwestern mobile functions. QuantumLeap can support various modes of operation, including CloudEdge, on demand and elastic modes. and virtual network nodes, so the router expands the network topology, determines the flows on the network, and embodies the requests transmitted through the API of the north interface. The north interface can be a data area with protocol support between the controller and higher-level applications or programs. QL can provide a standard API for information technology (IT) communication tools, for implementing northwestern mobile functions. QuantumLeap can support various modes of operation, including CloudEdge, on demand and elastic modes. and virtual network nodes, so the router expands the network topology, determines the flows on the network, and embodies the requests transmitted through the API of the north interface. The north interface can be a data area with protocol support between the controller and higher-level applications or programs. QL can provide a standard API for information technology (IT) communication tools, for implementing northwestern mobile functions. QuantumLeap can support various modes of operation, including CloudEdge, on demand and elastic modes. The north interface can be a data area with protocol support between the controller and higher-level applications or programs. QL can provide a standard API for information technology (IT) communication tools, for implementing northwestern mobile functions. QuantumLeap can support various modes of operation, including CloudEdge, on demand and elastic modes. The north interface can be a data area with protocol support between the controller and higher-level applications or programs. QL can provide a standard API for information technology (IT) communication tools, for implementing northwestern mobile functions. QuantumLeap can support various modes of operation, including CloudEdge, on demand and elastic modes.

In an embodiment, there are five functions in the set for Enhanced Packet Core (EPC) operations. The functions include a mobile administration entity (MME), a serving gateway (SGW), a packet gateway (PGW), a core network subscriber (HSS) service, and a PCRF function.

In some situations, the network and IT or application areas are vague, due to virtualization and dislocation of logical and physical resources. In addition, there may exist functional ranges in massively scalable and interconnected clusters. Applications, services, network functions, and virtualized topologies can be located in the same type of infrastructure, for example, in a cluster running OpenStack ™.

OpenStack ™ is a free cloud computing platform from an open source. OpenStack ™ can be deployed as an infrastructure, as a service solution (IaaS). The technology used in OpenStack ™ includes interconnected projects that manage sets of resources for processing, storing and building networks through a data center for administration or provision via a dashboard on a network basis, command-line tools, or via the REST API ful .

OpenStack ™ has a modular architecture with codenames for its components. The Compute module, known as Nova, is a structure controller for "cloud computing", designed to administer and automate sets of computer resources. The Compute module can work with various virtualization technologies, with computer facilities without software and computer configurations with high characteristics (LDCs). A hypervisor or a virtual machine monitor (VMM) runs on virtual machines. In addition, the Compute module works with external libraries, with an architecture that scales horizontally.

The OpenStack ™ object storage module, known as Swift, is a scalable redundant accumulation system. Objects and files are written to multiple disk drives distributed to servers in the data center using OpenStack ™ software, responsible for replicating and data integrity within the cluster. Accumulation clusters are scaled horizontally by adding new servers. When a server or hard disk drive fails, OpenStack ™ generates a replica of its content from other active nodes in new locations in the cluster.

In addition, the OpenStack ™ network generation module, known as Neutron, formerly known as Quantum, is a system for administering Internet Protocol (IP) networks and addresses. Networking OpenStack ™ reduces the bottleneck of the network to facilitate the provision of its own services to users. Networking OpenStack ™ provides models for networking for different applications or groups of users. The models used include single-type networks or virtual local area networks (VLANs) for separation services and traffic. Networking OpenStack ™ administers IP addresses, facilitates specialized static IP addresses or a dynamic configuration protocol for host devices (DHCP). Floating IP addresses help to dynamically redirect traffic to computing resources, and reduce traffic during maintenance or in the event of a failure. Users can configure their own networks, manage traffic and connect servers and devices with one or more networks. Administrators can use network-based networking defined by software (SDN), such as OpenFlow, for high levels with a multi-tenancy architecture scale and on a massive scale. Networking OpenStack ™ has an extension framework for additional network services, such as intrusion detection systems (IDS), load balancing, firewalls and virtual private networks (VPNs). Users can configure their own networks, manage traffic and connect servers and devices with one or more networks. Administrators can use network-based networking defined by software (SDN), such as OpenFlow, for high levels with a multi-tenancy architecture scale and on a massive scale. Networking OpenStack ™ has an extension framework for additional network services, such as intrusion detection systems (IDS), load balancing, firewalls and virtual private networks (VPNs). Users can configure their own networks, manage traffic and connect servers and devices with one or more networks. Administrators can use network-based networking defined by software (SDN), such as OpenFlow, for high levels with a multi-tenancy architecture scale and on a massive scale. Networking OpenStack ™ has an extension framework for additional network services, such as intrusion detection systems (IDS), load balancing, firewalls and virtual private networks (VPNs).

In addition, the OpenStack ™ identity, known as Keystone, provides a central director for users to access OpenStack ™ services that are accessible. Identity acts as a common authentication system in the cloud operating system and can be integrated with other server directory services, such as the Lightweight Directory Access Protocol (LDAP). In addition, Identity supports many forms of authentication, including the standard user name and password-based identity, marker-based systems, and Amazon (AWS) ® network service logins. In addition, the directory provides a list with the ability to form a queue of services deployed in the OpenStack ™ cloud in the same registry.

The Telemetry module, known as the Ceilometer, provides a point of contact for billing systems, providing counters for establishing customer accounts among OpenStack ™ components. Delivery of meters can be monitored and suitable for audit. The counters are broad enough to support new projects, and the agents collecting data are independent of the entire system.

Additional OpenStack ™ modules include Dashboard (Horizon), Image Service (Glance), Orchestration (Heat), Database (Trove) and Elastic Map Reduce (Sahara). OpenStack ™ Dashboard provides for administrators and users a graphical interface for accessing, providing and automating resources based on the cloud. In addition, Orchestration organizes a variety of composite "cloud" applications, using templates both through its own OpenStack ™ REST API, using the API Heat Orchestration Template (HOT), and through CloudFormation® AWS®, compatible with the Query API. The database is a database used as a mechanism for providing a relational and non-relational database. Elastic Map Reduce is a service that facilitates the processing of resource data administered by OpenStack ™,

The embodiment model includes determining a standard IT or network model (NW) and a method for mobile networks. For example, the name of the access point (APN), mobile virtual network operator (MVNO), subscriber and policy implementation are defined. A network belonging to the IT layer is used to integrate with platforms such as OpenStack ™ and CloudStack ™, and applications, and is located within API repositories. In an embodiment, the MNFV provides the mobile functions of the north and south interfaces, implementation methods and interactive methods, and associated descriptors that facilitate the integration of NW mobile functions with hybrid Internet IT service applications, such as OpenStack ™, to form and coordinate the service.

The agent The QuantumLeap plug-in on the OS or the hypervisor can implement the main classes to support the virtual network function (VNF) for EPC clusters, such as MME, SGW and PGW, for the south interface, via Neutron. Access to some of the functions of the north interface and the southern interface is via epc.xml or pgw.xml, or the appropriate JavaScript object name format (JSON) files. Associated OVSDB can be used to implement O VS. In addition, the ML2 plugin can also be used.

When translating the southern interface to pass through connectable requests and responses, the virtual machine or operating system uses their translation through plug-in agents and drivers. The driver can be a switch or router device (L2 / L3) (kernel-level processing), while the agent can run on top of the operating system (OS), in order to facilitate translation for software execution, as user-level processing.

In Fig. 1 illustrates a network 100 for transmitting data. The network 100 includes a data transfer controller 102 having a coverage area 106, a plurality of user equipment (UE) including a UE 104 and a UE 105, and a reverse transmission network 108. Two UEs are represented, but there may be a much larger number of UEs. The data controller 102 may be any component configured to provide wireless access, among other things, establishing an uplink transmission channel (dashed line) and / or downlink (dashed line) connections to UE 104 and UE 105 such as a base station , extended base station (eNB), access point, picocell, femtocell and other wireless access devices. The UE 104 and UE 105 may be any component, configured to establish a wireless connection with the data transfer controller 102, such as cellular phones, smart phones, tablet computers, sensors, etc. The reverse transfer network 108 may represent

any component or set of components that allows data to be exchanged between the communication controller 102 and the remote end. In some embodiments, the network 100 may include various other wireless devices, such as relay stations, femtocells, etc. Embodiments can be embodied in the UE or in the communication controllers. Embodiments can be used in wireless networks, such as network 100.

The Advanced System Architecture Presentation (SAE) is an architecture of the core network for wireless data transmission of the 3GPP Third-Generation Partnership Project (LTE). SAE is the development of a basic common packet data service (GPRS) network with a simplified architecture, a fully IP-based (AIPN) network, a radio access network with support for higher throughput and lower latency (RAN), and support for mobility between multiple heterogeneous access networks, including a non-3GPP system. SAE includes MME, SGW, PGW, HSS, access network disclosure and selection function (ANDSF), and deployed packet data gateway (ePDG).

The MME is the control node for the access networks responsible for paging in the UE in the standby mode and the marking procedure, including retransmission. The MME is involved in the process of activating and deactivating the media, and selecting SGW, for the UE at the initial connection and during the transfer of the mobile terminal at which the node of the core network (CN) changes. In addition, the MME performs authentication for users by interacting with the HSS.

The SGW routes and redirects user data packets, and acts as a mobility anchor for the user layer during the transfer of the mobile terminal between the eNBs. In addition, SGW acts as an anchor to provide mobility between LTE and other 3GPP technologies. For the UE in the idle state, the SGW terminates the downlink data channel and initiates the paging transmission when the downlink data is received for the UE. In addition, SGW administers resource use records for enforcement of policies and billing.

PGW provides the ability to connect from the UE to external packet data networks during the exit and traffic entry for the UE. The UE may simultaneously have the ability to connect to one or more than the PGW to access a plurality of public data networks (PDNs). PGW enforces policy enforcement, packet filtering for users, changes in charging

accounts, interception and sifting of packages.

HSS is a central database that contains information related to the user and subscription. HSS has functions such as mobility management, call and session setup support, user authentication and access authorization.

ANDSF provides information in the UE about the possibility of connecting to 3GPP and He-3GPP access networks, such as Wi-Fi. ANDSF helps the UE when it detects access networks in the immediate vicinity and provides policies for prioritizing and administering connections to these networks.

ePDG provides data transfer from a UE connected to the EPC via non-secure He-3GPP access.

In Fig. 2 illustrates the MNFV 190, which can be used in a mobile system. The MNFV 190 contains the level of the gasket, the installation of the mobile function and the IT / NW connector. The application layer 194 can use OpenStack ™ and / or hypertext markup language (HTML). The application layer 194 selects functions 196, such as AWS®, cloud services Joyent®, VMware® and Eucalyptus®. The functions 196 perform the disclosure of the network value, the implementation design, the publishing and the incubation of the API.

The SAE disclosure package 204 and applications 208 are used by electronic payment mechanisms, ad insertion mechanisms, real-time analytics and content distribution and caching.

The SAE suite 212 includes PCRF 214, MME 216, HSS 218, PGW 220 and SGW 222. Virtual machines (VMs) 226 connect these modules to available resources.

The wireless data transmission administration unit 228 and the revenue engine 230 are used in the EPC structure 192, the integrated EPC structure, which is used to evaluate the technology, obtain comparative characteristics, and generate prototypes.

Computing resources include a cluster with load balancing, accelerators, virtualized nodes or clusters that are automated or managed. Network resources can represent speeds of 24-100 Tbps, no blocking when connecting any-with-any and the redirection mechanism of the optimized packet (PFE) Ethernet 100 Gigabit (GE). There are also security modules 232 and 234 and a media layer 236. The media layer 236 includes a virtual node administration module 238, a hierarchical service quality module (H-QoS) 240, a MPLS mapping module 242, a PCEF enforcement function 244, S1-U246,

Mobile functions can be virtualized and implemented using the API. The provisioning functions include the formation, configuration and testing of the EPC virtual network, the formation, configuration and testing of MVNO and the formation, configuration and testing of the network from machine to machine (M2M). Optimization and maintenance functions include configuration of the EPC scaling parameters, network scaling, performance tuning, topology optimization, dynamic provisioning, re-provisioning, fault management and software administration. Operational functions include APN, subscriber, policy, security, report planning, SLAs and M2M. The functions of synthesis and analysis, and intelligent functions include intelligent network facility (N1), intelligent subscriber facility (SI), intelligent application tool (AI), intelligent device facility (DI), reporting, network alerts, and service alerts. In addition, the service functions include service connections, voice functions, subscriber administration (SMS), module administration (MMS), videoconferencing, positioning, device capabilities, subscriber profile for payment, QoS, M2M and intelligent functions.

The embodiment includes an integrated platform with OpenStack ™ for interworking services for MVNO and a cloud of carriers. There is a separation of service levels and administration. The embodiment includes new methods for MVNO, policy management, and CloudEPC for templates and attributes in accordance with physical and virtual networks of media. Dynamic dimensioning based on time and traffic structures is supported, including the use case for M2M / IOT.

Table 1 illustrates examples of configuration and flow. GTP-v1U uses the user datagram protocol (UDP), as protocol and port 2152, for GPR, Universal Mobile Data Transfer (UMTS) and LTE. GTP-v1C uses UDP and port 2123 for GPRS and UMTS. In addition, GTP-v2C uses UDP and port 2123 for LTE. In addition, GTP 'uses UDP for a CDR with an unknown port. GTP-v2Cx uses UDP and port 2123 for VxLAN through the SxV interface.

<img file="00000001.jpg" he="51" wi="160" img-format="jpg" img-content="undefined" />

Different templates can be used for virtual network functions. Policies are forcibly performed by the owner and are specific to a group of users. Some examples of templates include Template_MVNO (Tenant, SP), Template_EPC (Tenanat, ITDelegate, Capacity, Delay, MME, PGW, SGW), Template_Service (ServiceName, Tenanat, SP, ServiceID, EpcID, PolicylD, ApnID), Template_APN (ApnName , ApnID, Tenanat, SP), Template_Policy (PolicyNarne, PolicylD, Tenant, SP), Template_Subscriber (SubscriberProfHeID, Tenant, SP), Template_Tunnel (Type, Endpoints (n), Capacity, TEID), and Template_DNS (ReolverID, PrivateFlag, IP address, port, protocol, ForwardingID).

In the case of using the RESTful API (generation, reading, updating and removal (CRUD)) is used to form a video chat. Videochat is a composite of two functions, video services and chat services. CRUD is applicable for transferring data from point-to-point or from point-to-multipoint points. To transfer data from point-to-point, there are two service configurations, with support for such services through service interaction. The QL API supports the interaction of the service through templates. The state machine of the open mobile controller supports the interaction unique to QL, for integration with OpenStack ™. Thus, OpenStack ™ IaaS is allowed for template interaction, to support uniquely designed templates.

Mobile network operators (MNO) are generalized terms for operators that operate on mobile networks. MVNO provides end-to-end (E2E) services without the need for ownership of all resources, but can distribute or operate with subsets of RANs or EPC functions, while the resource belongs to the owner of the physical resource (PAO). Examples of resources include servers, storage, physical network resources (NW), spectrum and software resources (SW), or code. For example, Spectrum, Compute, Storage, Network Cluster, IP Address and Virtual LAN address (vLAN) are resources. Mobile resource operator (MAO) operates with physical nodes or virtual mobile functions within certain administrative domains. The owner of a physical mobile resource (P-MAO) is the operator of a physical mobile resource. The owner of the virtual mobile resource (V-MAO) works and allocates the MVNO virtual context. A mobile platform as a service (MpaaS) or a virtual mobile network (VMNO) operator is similar to local access as a service (laaS) for cloud-operated and cloud-enabled network functions of a mobile network.

In Fig. 3 illustrates a system 130 for working with physical and virtual mobile networks. The Operation Support System (OSS) / Business Support Services Unit (BSS) 132 contains the agent 134. The API of the north interface passes through the OSS / BSS 132 to the MNFV 136, orchestrator.

MNFV 136 contains a plug-in 138 that can be a QuantumLeap plug-in. The south interface API passes to the cloud administration system (CMS) 140 that has the agent 142. Examples of CMS include OpenStack ™, CloudStack®, Eucalyptus®, CloudFoundry®, and private clouds such as Vcloud Director® and AWS®.

In addition, from the MNFV 136, the connection to the agent 148 in the administration system 144 by an element (EMS) passes. EMS 144 communicates with the network 152, traditional EPC nodes and the network. The network 152 is a traditional physical cluster of EPCs or a network. The driver 146 in the EM 144 communicates with the network 150, the geographically distributed CloudEPC clusters. Administration of network 150 may be performed by CMS 140 and / or EMS 144. Network 150 is a virtual cloud EPC with a router between the interconnection between L2 / L3 layers in network stacks. There may be bridged connections, such as vLAN, or virtual extended local area networks (VxLAN) over Ethernet, Internet Protocol Version 4 (IPv4), Internet Protocol version 6 (IPv6), or IP or MPLS at 2.5.

The workaround adapter traverses the CMS 140 and selects the EM 144 from the MNFV 136 for the EM 144, either for the network 152, or for the network 150.

The request of the high-level plug-in from the MNFV 136 can be passed through the EM 144 to the network 150 or network 152. Alternatively, the plugin request is directly transmitted to the network 150 or network 152. The agent's operating time can be implemented via the MNFV 136 puppet master for remote execution . A remote interaction agent can be executed by an agent or driver, depending on whether it is an OS, a hypervisor, or an OVS, is an L2 switch, an L3 switch, or a router for the adapter. The adapter is a plugin that is not an OpenStack ™, such as an EMS or a Puppet module. The implementation of the QuantumLeap adapter can be adjusted for MNFV services for matching attributes with the Neutron API extension. Other inconsistent attributes, such as EPC network delay and delay budgets,

The objects of the north and south interfaces are formed through REST calls, such as post, get, put and delete, corresponding to the create (C), return (R), update (U), and delete (D) calls of the structured query language (SQL). C is used for forming operations, R is used to return an attribute in response to a view or list of operations, U updates the value of the attribute, and D deletes the attribute value.

The high-level task flow involves the formation of the EPC cluster. Subnets are then associated with the EPC cluster and the VM or VNFs attached to the EPC cluster are loaded. Clean-up includes removing the VM or VNF, deleting the ports associated with the EPC cluster, and removing the EPC cluster. The subnets associated with the EPC cluster are deleted.

In Fig. 4 illustrates the operation of MNFV in the context of OpenStack using QuantumLeap. The QuantumLeap module 358 is a QuantumLeap mechanism with the QuantumLeap API. QuantumLeap API has various functions, such as the formation of EPC, the formation of APN and the formation policy. The QuantumLeap module 358 communicates with the OSS / BSS / Network Administration System (NMS) 352 running through the north interface, interacting with applications 354 3^-her side and the OpenStack ™ graphical user interface (GUI) 356. The CMS Adaptation layer works with a variety of cloud administration systems to communicate with the virtual EPC-Ds 372.

In addition, QuantumLeap interacts with various OpenStack ™ modules. Some examples of OpenStack ™ modules that can be used include NOVA API 360 (computation), Glance API 362 (image), Cinder API 364 (saving), Quantum API 366 with Create-net and Create-port, 368 API extensions and Quantum plugin 370. Quantum plugin 370 contains Create-net and Create-port operations.

The QuantumLeap plugin works in a mobile network infrastructure that contains a mobile controller 370 that works with data-tier products from multiple providers. The mobile controller 370 communicates with the virtual EPC-Ds 372.

In Fig. 5 illustrates a system 620 for administering applications with a VM agent using QuantumLeap. The system 620 includes a controller node 621 that provides the MNFV service and a computation node 623. The controller unit 621 comprises a QL server 622 that is a proxy server through the north interface. The EPC connection associates the Virtual EPC (vEPC) nodes to form the vEPC cluster. The OS administration and management networks pass through the QL server 622 and the QL agent 628 at the computing node 623. Messages in the controller node include the remote procedure call (RPC) protocol, the QuantumLeap API, the Hello Messages, the uplink and downlink connection, the bandwidth and delay to satisfy the SLA for MNO.

The computing node 623 includes a QL agent 628, a node 634, and a node 642. The node 634 includes a virtual MME (vMME) 636, a QL virtual administration unit 640, and an application plugin 642, while the node 642 includes a virtual SGW (vSGW) 644, virtual management 646 QuantumLeap and plug-in 648 applications. There are commands specific to the application in the compute nodes. Computing nodes have agents. Agent 648 QL converts the connections that need to be configured. Other commands between the nodes and the QL agent include the queue emulator port (QEMU), redirection, startup, shutdown, configuration and control signal. The vEPC status is reported. NOVA processes the virtual interface (VIF) for port forwarding. Redirection of the QEMU port is performed by mapping the port.

A sample example of the QuantumLeap command-line interaction for EPC includes:

qleap &lt;commands&gt; [options] [arguments] Commands: List Template

V-MME v-SGW v-PGW v-PCRF v-HSS v-eNB

Stack (Begin)

getTemplate (v-MME)

get Interface (CIO_S 1 -MME, CIO_S6a, CIO_S11)

getTemplate (v-SGW)

get Interface (DIO_S 1 -U, DIO_S5, DIO_S8)

getTemplate (v-PGW) getlnterface (DIO_S5, DIO_S8, DIO-SGi)

config Switch Huawei 9811 Port 1-6

link v- S GW.PI OS 5 v-PGW.DIO_S5 BW = 10Gb P1-P2

link UE-eNB-to-E-LA v-MME CIO S1-MME = 1Gb P3-P4

link UE-eNB-to-ELAN v-SGW.DIO_S1_U = 10Gb P5-P6

connect QLeap mySQL Openstakc.DB.ODBC

Group (v-MME, v-SGW, v-PGW) name CloudEPC

Stack (Commit), Build stack, Instantiate stack, Monitor stack

In Fig. 6 illustrates a system 440 for the REST API that configures and administers networks and SLAs. The controller 442 includes a 480 OpenStack ™ module that performs various OpenStack ™ functions, including a NOVA database 482 that is connected to NOVA scheduler 484, Nova conductor 486, NOVA API 488 and NOVA API 488. The NOVA planner 484 and the conductor 486 are connected to the NOVA Compute module 502 at the compute nodes 500. The NOVA guide 486 provides support for computational nodes 500 that do not access the NOVA database 482. The NOVA scheduler 484 determines how to send calculation and volume requests.

NOVA API 488 interacts with the QuantumLeap 474 module, which provides the 476 API service and contains the 478 OpenStack ™ module. The interaction and control is provided by the QuantumLeap module, which communicates with NOVA API 488 and neutron 496, which contains the 494 API service and plug-in 498. Neutron 496 communicates with Agent 504, Neutron and / or QuantumLeap host agent at computer nodes 500. Also, the neutron 498 module refers to database 490, Neutron and / or QuantumLeap database.

The LMOD module 462, which interacts with the QuantumLeap module 474, is a cloud based network-based computing provider. The IMOD module 462 includes an API service 468, a mobile network 472, and network I / F conference modules 470. In one example, the 462IMOD module and the QuantumLeap module 474 are located in one place. Alternatively, the IMOD module 462 and the QuantumLeap module 474 are distributed. The I / F 472 of the mobile network refers to virtual and physical networks, such as portfolio 506, CloudEdge administration and interaction (MANO) 508 and MPaaS 509.

The mobile network manager 450 communicates with the IMOD module 462 and the QuantumLeap module 474. The mobile network manager 450 includes an open mobile network API service 452, MNFV 458, a high availability manager (HA) 454, a content manager (CM) 456, and a policy engine 460.

The mobile network manager 450, the QuantumLeap module 474, the IMOD module 462, and the virtual mobile subscriber equipment (vMSE) 444, access the database 444. vMSE 446 accesses the Network Function Virtualization Simulator (NFV) 448, which is used to simulate the network.

In Fig. 7 illustrates the use of MNO with MNFV and QuantumLeap with IT input into the pipeline to the mobile area. Operator object owners, such as MNO and MVNO, use the program interfaces 512 to interact with the QuantumLeap 514 module and the OpenStack ™ modules. MVNO 516 accesses the QuantumLeap module 514 that performs the implementation of 518 vEPCs, for example, areas, zones, and data centers. In this example, there are three areas, the region of Europe, the Middle East and Africa (EMEA) 524, the Asia-Pacific region (ARAS) 536, and the Western US area 546. Operator roles are defined in block 520. Resource owners and operators are defined. In addition, the MNO and MVNO operation modes are defined in block 522. It is transferred to PGW 560 in MPaaS 558.

The EMEA 524 area, in London, contains the servers 528, PGW 530 and DC 534. In addition, the AR AS area 536 located in Shanghai contains the servers 538, MME 540 and DC 544. In addition, the western regions of the US 546 located in San -House, comprise a server 548 in the DC 552. The area contains a data controller 562 and firewalls 564 and 566. The elastic capacity on demand and the implementation of the function are performed at block 556.

In Fig. 8 illustrates the functional appearance of EPC objects, which must be implemented by calling the MNFV function. In the open mobile controller 308 (OMS), the OpenStack ™ 310 CMS and the OMS API 300 operate. The OMS API 300 is linked from the virtual stored procedure database 296 (vSPDB) to the virtual HSS (vHSS) 292 and from the virtual OSS 298 (BOCS) to the virtual BSS (vBSS) 294. OMS 308 also uses MQ-Sch 306, virtual PCRF (vPCRF) 304, Q-Mgr 302, cells 312 and 314, and vMME 316. In phase 1, vEPC 318, vSGW 320, virtual PGW (vPGW) 322, vMME 324, vEPC 326, vSGW 328 and vPGW 330. In addition, a virtual MNVF (vMNVF) 332, virtual DHCP (vDHCP) 334, virtual APN (vAPN) 336, virtual PCEF (vPCEF) 338, virtual tunnel (vTunnel) 340 and virtual GTP (vGTP) 342. The functions of the list, view, generation,

In Fig. 9, an architecture 380 for MMI is illustrated. The MOC 382 is connected to an EPC cloud management and a data layer 384. The architecture 380 is a tunneling protocol in the carrier region from an end to end GTP.

The 398 QuantumLeap database is a database similar to other OpenStack ™ modules based on a single database per module. In Fig. 10 illustrates an object schema 410 for an embodiment. The schema of an object can be transferred to a SQL or NoSQL database, based on scalability and response requirements.

In an embodiment, the MNFV covers networks in which 3GPP LTE releases are used as their macro cell.

In addition, the API generates, reads, updates and deletes the access point name (APN) and assigns it to the virtual cloud group (VCG). The VCG can be represented by a group of virtual cloud EPC descriptors "VC_EPC_D" or a group of radio cells assigned to one or more mobile administration objects (MME) called a virtual cell descriptor "VC_RAN_D".

In Fig. 11 illustrates a message diagram 420 representing an end-to-end request and response flow for an example of an API call from an application layer to an infrastructure layer. There is a data transfer between the helper module 394, the dashboard 393, the QuantumLeap module 392, the EMS cluster 402, the EPC cluster 404, and the CMS 400. The request from the HReq () helper module is sent to the dashboard. The helper redirects the GUECLI (Req) request to the dashboard, which is a command line, or the GUI toolbar. The dashboard then passes the QL_Req () request to the QuantumLeap mechanism, and the QuantumLeap mechanism passes EMS_Call (), which is based on QL_Req (), to the EMS. In addition, the QuantumLeap mechanism passes CMS_Call () to the CMS, which is based on QL_Req ().

The CMS then sends VCMS_Call () to the EPC cluster. The EPC cluster responds to VCMS_Resp (). EMS transmits EMS_Resp (), the response from EMS to the QL mechanism for the requested work, to the QuantumLeap mechanism.

In addition, EMS transmits PEMS_Call (), an EMS physical call, to the EPC.EPC cluster responds to PEMS_Resp (), a response to an EMS physical call. The CMS passes CMS_Resp (), the response from the CMS to the QL mechanism for the requested work, to the QuantumLeap mechanism.

The QuantumLeap mechanism passes the AL_Resp () response to the toolbar. Then the toolbar passes to GUECLI_Resp () as an assistant. The helper then reroutes HResp ().

In Fig. 12 illustrates the system 390 for QuantumLeap. The QuantumLeap module 396 is a QuantumLeap mechanism that processes the QuantumLeap API to execute the build, read, update, and delete commands in the EPC cluster 404. QuantumLeap detects QuantumLeap Inventory 398 QuantumLeap inventory database and associated metadata for existing or new CloudEPC clusters through the QuantumLeap database, to identify which interface should be used to interface the infrastructure and its attributes. Metadata known as the virtual cloud cluster descriptor EPC or vC_EPC_D describes a single CloudEPC cluster. CloudEPC includes the functions of the advanced enhanced packet core (EPC) node elements for MME / vMME, SGW / vSGW and PGW / vPGW. CloudEPC can also include PCRPVvPCRF,

The main MNFV module includes an API mechanism and an interaction module, supporting the virtualization of global and abstract functions of the north interface for mobile carrier networks or MNO. Mobile networks are represented by clusters of 404 EPC.

EMS clusters 402 may be a physical EMS Brownfield or virtual cloud clusters EMS that define, build, implement and administer a CloudEPC cluster through its interactions with the QuantumLeap module 396. A query from the QuantumLeap module 396 can lead to the execution of the southern interface API. The EMS Cluster 402 administers CloudEPC functions such as MME, SGW, PGW, PCRF, HSS and various mobile operations requested by MNFV, which can be traditional or virtual.

The EPC clusters 404 have backhaul channels over the Ethernet / IP radio network for management and data layers. In addition, the EPC cluster 404 supports applications and / or services in the Internet interface. MNFV manages CloudEPC through an EMS or CMS 400 cluster 402. It manages various types of nodes, Compute, Storage, fixed / mobile slices, and cloud virtual groups. Testing is performed from the QuantumLeap module 396. The 404EPC cluster is a kernel module that helps mobile network operators offer services in the cloud.

The CMS 400, which can be an OpenStack ™ controller or another CMS controller, can be independent or integrated with the QuantumLeap 396 module. Mobile functions are developed in the EPC Cloud, or CloudEPC is performed through a Hypertext Transfer Protocol (HTTP) to the QuantumLeap 396 module, or through the L3 / L2-IP / vLAN layers in the 404EPC cluster. In addition, the CMS 400 supports extraneous clouds with translation from the PI QuantumLeap inputs into the corresponding clouds in the CMS network 408. Network 406 is also used to communicate with external interfaces for the Internet.

Global module 392 forms an interface with the QuantumLeap module 396 to support network operations support services (OSS), business support services (BSS), network administration systems such as virtual EMS (vEMS) and another virtual network file system (vNFS) for building and maintaining CloudEPC.

The helper module 394 interacts with the global module 392 via the helper interface. The helper module 394 helps the third party vOSS / vBSS / vEMS / vNFS support it, in order to make the MNFV universal. The NMS Assistant module 394 presents a logical software package that can access the API for the north interface in the dashboard 393 and can programmatically manage the QuantumLeap API to manage the EMS cluster 402, the logical or physical EMS cluster.

In Fig. 13 illustrates a flowchart 690 for a method for forming an EPC cluster. Initially, in step 692, the owner generates an EPC cluster. For example, the owner generates an epc1 EPC cluster with an ID for epc1_id.

Next, in step 694, the subnet is associated with the EPC cluster formed in step 692. For example, the owner associates the subnet 10.0.0.0/24 with the epc1 EPC cluster.

Then, in step 696, the VM is loaded and attached to the EPC cluster. The owner loads the VM and installs one network interface controller (NIC), which connects to the EPC. In one embodiment, QuantumLeap comes into contact with OpenStack ™ Networking, to form a NIC and attach it to an epc1 network with the ID net1_id:

$ QuantumLeap boot &lt;server_name&gt; - image &lt;image&gt; - flavor &lt;flavor&gt; - nic net-id = &lt;epc1_id&gt;.

In another example, port1 is formed. The VM is then loaded with the specified port. OpenStack ™ Networking forms a NIC and attaches it to the port1 port with ID port1_id:

$ QuantumLeap boot &lt;server_name&gt; - image &lt;image&gt; - flavor &lt;flavor&gt; - nic port1-id = &lt;port1_id&gt;.

OpenStack ™ Networking selects and assigns an IP address for port1.

In step 698, the owner deletes the VM. QuantumLeap comes into contact with OpenStack ™ Networking and removes the port1 port. The allocated IP address is returned to the general set of available IP addresses.

Then, in step 700, the ports are removed. When the owner has formed the ports and associated them with the EPC cluster, the owner removes these ports.

Eventually, at block 702, the network is deleted. The owner deletes the EPC cluster. The OpenStackQuantumLeap cluster and its associated transferred EPC modules are deleted when the port is not currently configured over the network.

In Fig. 14 illustrates a flowchart 710 for a method of using a mobile carrier, such as MNO or MVNO. Initially, in step 712, the owner, MNO or MVNO, forms a global zone, for example, an empty global provider zone. For example, the owner creates a North American zone with ID GZone_id.

Next, in step 714, the site is associated with the global zone generated in step 712. The owner associates the site with the global zone. For example, the owner associates the EPC cluster and epc1 with the North American GZone_id.

Then, in step 716, a local zone is formed and attached to the global zone. The owner forms a local zone, for example, an empty local area of ​​the provider. For example, the owner forms the Santa Clara zone with the zone ID for LZone_id.

In step 718, the site is associated with the local zone generated in step 716. The owner associates the site with this local area. For example, the owner associates clusters of EPC and epc2 with Santa Clara LZone_id.

Eventually, in step 720, the subscriber is provisioned. After establishing global zones, local zones and locations with the corresponding EPC clusters, the provision of the mobile network involves the allocation of sets of providers, resources, attributes and quotas. Further provision of the subscriber and use of the provided applicable resources, such as APN, can be tested using other API calls with the EPC adapter.

The image shows the operating system and / or bundles of downloadable packages, as an image of standard software, for the formation of virtual machines in a standard format. Imagelink is the address of a unified network resource locator (URL), for example, for the location of the image http: // wxyz / bin / Images /. A descriptor is a formatted XML object or JSON in a hierarchy or in a relationship describing the nodes and their interfaces to form clusters of nodes that work together. The destination in the network URL or on the path to get the descriptor, conditionally or by configuration. GroupType describes closely tied EPC or RAN for use by different objects. A virtual cloud group (VCG) is a grouping of either an EPC or a RAN in a cluster, or a cloud, which can be described as a module. APN is an object that uses VCG with mobile origin (MO), mobile termination (MT) or a slice of the network clusters EPC or RAN. A mobile number is assigned to a subscriber (SUB), for example, a subscriber identity module (SIM) or a universal subscriber identity module (USIM). An object is any piece of hardware or software that can be connected to network services. Subscriber attributes include the International Mobile Equipment ID (IMEI) and International Mobile Subscriber ID (IMSI). Profile types include an independent consumer account (INDI) or a fund or corporate account (FAN). A grouped array is an array with one or more APNs or groups based on the provision of a carrier or MNO to the mobile device.

Owners of a physical object can belong to objects, or they can receive objects for leasing of various types, such as Spectrum, Compute, Storage and Network. A network can be an Ethernet network or an isolated layer 2 broadcast area, for example, reserved for the owner who generated it, or configured to share it. Owners can form many networks until certain thresholds are reached. Resources can be administered as a set, and they can be allocated or not allocated based on the availability and policies assigned to access control. For MNO, assign an ID, as in 3GPP, using the identification of an open terrestrial mobile network (PLMNID). IDs can be assigned in a variety of ways for private or unlicensed spectra. Once the MNO is established, as a project / owner, for example, according to OpenStack ™ or another cloud-based administration system, the shared resources in the radio access node or in the core network are allocated to mobile virtual network (MVNO) operators. MVNO is installed by the MNO or service provider from their network. Thus, the network provider can be equivalent to MNO resources, which include an EPC cluster with a CMS / EM, for administration elements within the core network. Billing and other functions of the Northern Interface Assistant are at the global level for administering transactions. the shared resources in the radio access node or in the core network are allocated to the mobile virtual network (MVNO) operators. MVNO is installed by the MNO or service provider from their network. Thus, the network provider can be equivalent to MNO resources, which include an EPC cluster with a CMS / EM, for administration elements within the core network. Billing and other functions of the Northern Interface Assistant are at the global level for administering transactions. the shared resources in the radio access node or in the core network are allocated to the mobile virtual network (MVNO) operators. MVNO is installed by the MNO or service provider from their network. Thus, the network provider can be equivalent to MNO resources, which include an EPC cluster with a CMS / EM, for administration elements within the core network. Billing and other functions of the Northern Interface Assistant are at the global level for administering transactions.

Owners of physical objects belong to, and they lease various types of objects, such as Spectrum, Compute, Storage and Network. Resources can be administered as sets and they can be allocated, or can be released based on availability and the policy assigned to access control. MNO assigns an ID, as in 3GPP, for example, using PLMNID, to maintain compliance with telecommunications standards. The ID can be used differently for a private or unlicensed spectrum. When the MNO is set up as a project / owner, according to the CMS, the shared resources in the radio access network or in the core network can be allocated to the MVNO. MVNO is a term established by the MNO or service provider from their networks. Thus, the network provider is a term for MNO resources, which include an EPC cluster and an EMS cluster for administering elements within the core network. Because it administers operations, billing and other functions of the assistant to the north interface are at the global level.

Thus, in addition to resource sets, before setting MNO / MVNO, geography is defined through descriptors in the XML hierarchy or JSON descriptors. A mapping is performed to minimize the configurations in the geolocation object. This is performed in a flexible manner to place the mapping in the data center (DC) and the carrier node identified in the path of the virtual circuit from the core in the direction of the edges.

Geography is defined through descriptors in XML or JSON before the establishment of MNO / MVNO. This can be done with open source programming or OpenStack ™. There is flexibility to place the mapping in the data centers and identify the carrier node in the virtual path design from the core in the direction of the edges to meet the size requirements for the traffic channel administration.

When geolocation is set in a descriptor, a node is implemented using virtual network function (VNF) node elements, such as CloudEPC in virtual areas, or additional programs or packages. Objects have a manager. Traditional EPCs are controlled using traditional EMS, and the newer CloudEPC is administered using traditional EMS or a new cloud formed in vEMS. Multiple objects can be administered through QuantumLeap, which can provide interaction of programs and functions through a cloud administration system and traditional EMS.

Once the network clusters are ready for management, the user can connect and use sessions by subscribing and using LTE-based networks. Alternatively, network clusters can be administered over the Internet as an MNO, or MVNO establishes their network as agreed and configured through an ACL, a policy for using a network resource through VCG, or rules that allow or restrict the use of specific resources and groups through a combination of ACL and policy.

When network clusters are ready for management, a user can connect and use sessions by subscribing, and using a network based on LTE. Alternatively, the user connects via the Internet, such as MNO or MVNO, to establish networks by connecting and configuring.

In the example, the owner generates an EPC cluster, for example, epc1. Next, the owner associates the subnet with this EPC cluster, for example, "10.0.0.0/24". The owner then loads the VNF using three to five EPC nodes, and establishes subnets connected to epc-net1. VM is a completely isolated installation of the guest operating system within a normal host operating system. A module, for example, QuantumLeap, calls NOVA and / or Neutron, and forms a topology based on the epc.xml or vnf.xml, epc.json, or vnf.json descriptors. Neutron assigns subnets and Internet protocols (IP), according to the request, or defined in the XML / JSON descriptors for VNF. The virtual application function (vApp) is an application on the server side, or the service processes indirectly the application functions (AF) of the multimedia IP subsystem (IMS) or directly through 3GPP, the G interface / secure (Gi / SGi) or the Internet interface. IP is provided by QuantumLeap. The owner then deletes the VM. NOVA communicates with QuantumLeap-Neutron and removes epc-netl. The allocated IP address is returned to the set of available IP addresses.

Allocate IP-addresses. EPC networks can use blocks of IP addresses of version 4 (IPv4) or IP version 6 (IPv6). The QuantumLeam implementation can have a minimum of three nodes, including MME, SGW and PGW, and additional nodes such as PCRF, HSS, other vNFs, and so on. When a port is formed over a network, by default it is allocated an available fixed IP address of the designated subnets for the IP version. When the port is no longer used, the allocated addresses are returned to the set of available IP addresses by subnets. Users of the QuantumFeap API can select a specific IP address from the block. Alternatively, the configuration files of the QuantumFeap xml / json nodes, called node descriptors, select the first available IP address.

In Fig. 15 illustrates a flowchart 570 of a flowchart for a method of simulating a mobile network and interaction. Processing begins at step 572, the system starts forming the MNO.

In step 574, the MNO CRUD is executed.

Then, at step 576, determine the market, or perform geolocation. In step 578, an area is determined. In addition, in step 580, a zone and a location are determined. In addition, the DC, cluster, and node perform work to determine geolocation.

Then, at block 582, the resource sets of the owner of the physical entity are determined. Define sets of the mobile node, clusters of the mobile node and the owners of the physical object. Traffic uploads to open clouds are built when the site is modeled.

The 590 kit with Vodafone ™ United Kingdom (VDF-UK) DC 592 refers to CloudEPC 594. In addition, the 598 kit with Vodafone ™ VDF-NDF DC 596 addresses CloudEPC 600 and CloudEPC 602. In addition, the 606 kit with VDF-DTF DC 604 refers to CloudEPC 608 and CloudEPC 610. Virtual Capacity Planning (vCPCU) 584 modules contain templates 588 and networks 586.

In Fig. 16 illustrates a topology 110 with five nodes. The eNB is connected to the MME 116 and the SGW 118. The MME is connected to the HSS 112. The SGW 118 is connected to the PGW 120 and PCRF 114, while the PGW 120 is connected to the PCRF 114. The PGW 120 is connected to the Internet. The interaction between MME 116 and SGW 118 is performed using the QuantumLeap API. Interaction includes internal and external interaction.

Another embodiment is a topology of three nodes, comprising MME 116, SGW 118 and PGW 120.

In Fig. 17 illustrates a finite state machine 650 for EPC formed with JSON requests and responses. The state machine passes from the initial request to the response for the EPC cluster. Initially, after boot, the state machine is in the init state. The state machine remains in the initiation state 652 until the initiation is completed. When the initiation is completed, the state machine passes to a waiting state 654.

In the idle state 654, the state machine waits for a start response. The state machine then responds in the response state 656. In addition, the state machine passes to the state 658 to start credentials.

Then, the state machine goes to state 660, to start the transaction Tin +.

Then, the state machine goes to state 662, for I-Req In-Fmt.

The state machine passes to state 672 on a format error or to a closed state 670. From state 672, the state machine may transition to state 668, state 674, or state 676.

In state 668, the error is reset. The state machine goes to state 670, state 666 for emergency shutdown, or state 664, to resume the next operation.

In state 674, the state machine jumps to the next operation and goes to the standby state 654.

In state 676, a packet is transmitted.

Then, in state 678, the completion of Cmt-T is performed. Pass the XML, and in state 680, the command is processed.

In state 684, a test response is performed.

Then, in state 682, the I-Res response is executed. The state machine goes to state 672.

In Fig. 18 illustrates a system 711 for intelligent virtualization of a network function with a known location. NFV performs the cataloging of the NW function, the automatic discovery of the network object, the implementation of distributed NFV, and the mode of flexible operations. A portfolio definition can be performed. NFV 713, NFV with a known iMOD location, performs intelligent and dynamic implementation of the mobile workload. Used SGW, PGW and MME.

UE 724 is connected to eNB 728 via radio bearer 730. In addition, eNB 728 is controlled by MME 734. Wireless signals are propagated between UE 724 and eNB 728. The eNB is connected to RAN 732. RAN 732 is connected to MIL 738 in PGW 736, SGW 740 and PGW, which is controlled by the MME 746.

The RAN 732 is connected to the MRL 738, which is controlled by the PGW 736.

The PGW 748 is connected to the Gi-LAN 750, which is connected to the Internet 752.

In Fig. 19 illustrates a system 760 for virtualizing a mobile network function. In the 760 system, OpenStack ™ can be used. The controller 762, the open mobile controller, controls the switch 774. The switch 774 is connected to the server 770, the server 772, the Ixia ™ 764, and the server 766. The server 766 operates OpenStack ™, while the server 772 operates PGW.

The NFV 761 is an iMOD with a known location of NFV. The connection of the service or vMSE is provided by SVC 776, SVC 778, SVC 780 and SVC 782. The SVC transports the data in such a way that it looks as if there was a connection in the form of a specialized physical layer between the source and destination terminal systems.

SVC 776 is connected to the translation of 784 network address (NAT). The SVC 778 is connected to the deep packet inspection module (DPI) 786. The SVC 780 is connected to the caching device 788. In addition, the SVC 782 is connected to the NAT 790. The DPI module 786 analyzes a portion of the packet data, searches for a mismatch in the protocol, viruses, spam, instructions, etc., to determine if the packet can be dropped to its destination. In NAT, network addresses are modified to re-map the space of one IP address to another.

The router 792 is used to generate traffic.

Traffic is passed through the 794 VPN tunnels to the MPaaS 796 and MPaaS 800 using the server 768. The MPaaS 796 that contains the PWG-AW 798 passes traffic to the eNB 804, while the MPaaS 800 that contains the PGW-RACK 802 passes the traffic to eNB 812.

Traffic can then be directed in the direction of eNB 808, UE 810 and PGW 806.

In one example, a carrier of level 1 is used. The carrier has three data centers (DCO, DC1 and DC2). The carrier branch, Branchl and Branch2 work in their own package kernels, using local data centers, working with headquarters. Thus, there are nested MNOs based on geolocation (GeoLoc). MY-MNO is global with CMS OpenStack ™, and MY-MNO1 is the local French and MY-MNO2 local Scott. MY-MNO belongs and it operates with the EPC-NET cluster from APN-UK and assigns APN-France (APN-FRANCH) and APN Santa Clara (APN-SC) for use of MY-MNO 1 and MY-MNO2 , as assigned by the owner-administrator (Great Britain) or MY-MNO for OpenStack ™, using the QuantumLeap horizon toolbar. There can only be one OpenStack ™ controller on the UK site. As an alternative,

Initially, RW, for example, MY-MNO organizes its data center resources (servers, drives and switches) in the zone / site / OS / portable modules on-demand (ROB) / clusters / racks / nodes hierarchy.

In RAO operates CMS, OpenStack ™ in non-virtualized servers. In other computing resources, hypervisors work, for example, a virtual machine based on the core (KVM). RW uses the CMS to obtain a set or allocation of resources. The CMS and nodes can use a dedicated administration network for data exchange. In the RAO works QuantumLeap (QM). OpenStack ™ is used as a CMS. QL, together with other modules, provides MNFV services.

Perform geolocation mapping. RW requests a set of available resources using QL and categorizes these resources into the hierarchy of the zone / site / OS / ROO / cluster / rack / node. QL uses OpenStack ™ to request resources. QL internally contains a geolocation mapping node. In one example, three DCs are used. These three DCs are the United Kingdom, France and Santa Clara. DC UK is global, while the other two are local. Table 2, below, illustrates the classifications for 3 DC.

<img file="00000002.jpg" he="52" wi="155" img-format="jpg" img-content="undefined" />

MNO is formed. Because each MNO has a packet core network, they are based on the global core for global templates. Global templates modify for local use. For example, the pound is changed to franc, the time zones are made local, and QuantumLeap implements these descriptors for local use, using global roaming between data centers of the three networks. The VLAN assigns a pair of odd / even transmit and receive channels.

A subscriber can be formed or can be simulated using CloudEPC SGW sessions. Subscriber sessions originating from the eNodeB can form sessions over MY-MNO1, MY-MNO2, or MY-MNO, using the QL Subscriber (API) subscriber and the Session API.

In another embodiment, only one of the MY-MNO operators belongs to the spectrum and resources of the MME. Two other resources belong to the two MVNs, MY-MVNO1 and MY-MVNO2. Table 3 below shows the parameters. The MME operations represent ClearWire ™ as P-MAO in MY-MNO and the virtual case assigned to Sprint and Leap, respectively, in MY-MVNOL and MY-MVNO2. In addition, APNs are based on the EPC used, since each object owns at least one EPC cluster within their DC.

<img file="00000003.jpg" he="51" wi="155" img-format="jpg" img-content="undefined" />

At the initial installation, RW, MY-MNO, organizes its data center resources (servers, drives, switches) in the zone / site / OS / ROO / cluster / rack / node hierarchy. RAO launches CMS for non-virtualized servers. Other computational resources work on hypervisors, such as KVM. The RW uses the CMS for the resources from the set. The CMS and the nodes use a dedicated administration network for data exchange. In the RAO works QuantumLeap. The CMS is OpenStack ™. QL and other OpenStack ™ modules provide MNFV services. This is repeated for MY-MNO, MY-MVNO1 and MY-MVN2 owners using radioactive waste, which are transferred to the owners.

The owner of MY-MNO now has radio resources distributed over all three sites, C1, S1, L1. MY-MNO determines the formation of APNs for each site separately and processes APN-SP and APN-LP for MY-MVNOL and MY-MVNO2, respectively. MY-MVNO saves APN-CW for its own use. MY-MNO now adds:

<img file="00000004.jpg" he="13" wi="160" img-format="jpg" img-content="undefined" />

<img file="00000005.jpg" he="19" wi="160" img-format="jpg" img-content="undefined" />

Next, Clearwire assigns V-MAO Sprint and Leap for RAN, which allocates the use of MVNO. This is done as follows:

<img file="00000006.jpg" he="13" wi="140" img-format="jpg" img-content="undefined" />

<img file="00000007.jpg" he="20" wi="160" img-format="jpg" img-content="undefined" />

<img file="00000008.jpg" he="13" wi="140" img-format="jpg" img-content="undefined" />

<img file="00000009.jpg" he="14" wi="160" img-format="jpg" img-content="undefined" />

<img file="00000010.jpg" he="14" wi="160" img-format="jpg" img-content="undefined" />

In a further embodiment, layer 1 carries the runs of the program it is managing over the infrastructure of the third party service provider. Level 1 transfers the hardware owners of SGW and PGW and the spectrum for operating the zone / site / BS / cluster. However, MPaaS software for CloudEPC and hardware are owned by a third party, which is RAO. The MNO is formed and the VDF spectrum is assigned to it via:

<img file="00000011.jpg" he="14" wi="160" img-format="jpg" img-content="undefined" />

The owner of MY-MVNO can create a copy of MPaaS, as a virtual context for VDF, for use in Shanghai, the local Pudong area in the South China region. This is done using:

<img file="00000012.jpg" he="14" wi="160" img-format="jpg" img-content="undefined" />

<img file="00000013.jpg" he="12" wi="160" img-format="jpg" img-content="undefined" />

<img file="00000014.jpg" he="12" wi="160" img-format="jpg" img-content="undefined" />

<img file="00000015.jpg" he="12" wi="160" img-format="jpg" img-content="undefined" />

<img file="00000016.jpg" he="13" wi="160" img-format="jpg" img-content="undefined" />

A subscriber can be formed or can be simulated using the traffic generator tool or CloudEPC SGW sessions to demonstrate that subscriber sessions originating from the eNodeB can form sessions over MNO or MPaaS using the QL SUB API and the API session.

In another embodiment, the entire APN belongs to one subscriber that receives network resources from the MY-MNO, as appropriate. With the initial RW setup, MY-MNO organizes its central data resources (servers, drives, switches) in the zone / site / BS / RDO / cluster / rack / node hierarchy. In RAO operates CMS on non-virtualized servers. In other computing resources, hypervisors, such as KVM, work. RAO uses the CMS to create a set of resources. The CMS and the nodes use a dedicated administration network for data exchange. In RAO works QL. The CMS is OpenStack ™. QL, with other OpenStack ™ modules, provides the MNFV service. When both EPC core clusters and the radio node's path are installed using MY-MNO, its subscriber receives it MPaaS. MY-MNO now adds:

<img file="00000017.jpg" he="13" wi="160" img-format="jpg" img-content="undefined" />

<img file="00000018.jpg" he="16" wi="120" img-format="jpg" img-content="undefined" />

<img file="00000019.jpg" he="14" wi="155" img-format="jpg" img-content="undefined" />

<img file="00000020.jpg" he="6" wi="21" img-format="jpg" img-content="undefined" />

The subscriber can be generated or can be simulated using the traffic generating tool or the UE with VMN01 sessions to VMNO1, VMNO2 or MY-MNO using the QL SUB API and the API session.

The request and response types can be supported in the JSON data format. The format for request and response types can be set using the tolerance header or by adding the .son extension for the requested URL. An example of an Inquiry is defined as follows:

POST / vl.O / tenants / tenant / networks HTTP / 1.1

Host 127.0.0.1:9696 Content type appendix / json

Accept application / json

Length of content 57

<img file="00000021.jpg" he="50" wi="44" img-format="jpg" img-content="undefined" />

Synchronous and asynchronous plug-ins can be present. The ability to connect a mobile network to a logical model of a mobile network with mobile network clusters, nodes, ports and subnets is the QuantumLeap API. The plugins communicate with Neutron and / or the infrastructure directly below it, in order to facilitate the redirection of the package that corresponds to the logical model. The plugin can perform such operations asynchronously, so that when the API client modifies the logical model using HTTP POST, PUT, or DELETE, the API call can be returned before modifications when executing the plugin for the virtual and / or virtual virtual switching devices located under them.

The subsequent API calls reflect the modified logical model accordingly. In one example, the client uses the HTTP PUT to establish an attachment for the port. The port is a virtual switch port over the logical network switch. Virtual instances attach their interfaces to ports. The logical port also specifies the address of the Media Access Controller (MAC) and the IP address to be assigned to their connection in the interfaces. When IP addresses are associated with a port, the port is associated with a subnet, because the IP address was received from the selected set for a particular subnet. A subnet is an IP address block that can be used to assign IP addresses in virtual instances. Subnets can have classless procedures inside the domain (CIDR) that are associated with the network. IP addresses can be selected from the entire CIDR subnet or from selection sets that can be set by the user. At the same time, there is no guarantee that the packets transmitted by the interface named at the attachment will be redirected immediately after the HTTP return. However, there is a guarantee that the subsequent HTTP GET, to view the attachment on the port, could return the new value of the attachment. The "status" attribute available for the cluster / EPC network and port resources can be used to understand whether the configuration of the QuantumLeap plug-in for the resource of interest has been successfully completed. will be redirected immediately after the HTTP return. However, there is a guarantee that the subsequent HTTP GET, to view the attachment on the port, could return the new value of the attachment. The "status" attribute available for the cluster / EPC network and port resources can be used to understand whether the configuration of the QuantumLeap plug-in for the resource of interest has been successfully completed. will be redirected immediately after the HTTP return. However, there is a guarantee that the subsequent HTTP GET, to view the attachment on the port, could return the new value of the attachment. The "status" attribute available for the cluster / EPC network and port resources can be used to understand whether the configuration of the QuantumLeap plug-in for the resource of interest has been successfully completed.

In the implementation of the QuantumLeap API, several objects of the same type can be generated in one API request. In the operations of forming a large array of data, the same API is used as in the operations of singleton formation, where the list of objects, instead of one object, is installed in the requested housing. Operations with a large amount of data are performed automatically, which means that all or some of the objects are formed in the requested housing. The finite state machine for the QuantumLeap mechanism, which uses the execution of transactions, is used for atomicity. When the plug-in does not support atomic operations, the QuantumLeap mechanism emulates atomic behavior. For example, the owner requests five nodes of the EPC cluster, and three nodes fall at the time of formation.

In another embodiment, QuantumLeap is used without support for operations with a large amount of data. A bad query error 400 may be returned when the client attempts to perform a large amount of data creation operation.

Performing a large amount of data is an operation whereby combined APIs can be executed to generate and / or update a large amount of data. Automation of mechanism support is built into the finite state machine.

The table below shows combinations of topologies that can be used as descriptors, for example, pgw.xml, a combination of pgw.xml and sgw.xml, or three minimal ones from mme.xml, sgw.xml and pgw.xml. Descriptors are XML formatting objects or JSON in a hierarchy that describes nodes and their interfaces to form a cluster of nodes that work together. CRUD is the basic function of a permanent drive when programming in a computer. CRUD (L, S) X is the standard for calling REST, like generating SQL type calls, reading, updating, deleting (list, view) in the API. X is intended for execution or for launching program objects.

<img file="00000022.jpg" he="143" wi="158" img-format="jpg" img-content="undefined" />

<img file="00000023.jpg" he="55" wi="156" img-format="jpg" img-content="undefined" />

The EPC cluster can use MNO or MVNO contexts together with zones, locations and data centers before their consumption by subscribers. Table 5 below shows some QuantumLeap building blocks for the hierarchical implementation and consumption of data services by a subscriber using access to the mobile network.

<img file="00000024.jpg" he="93" wi="160" img-format="jpg" img-content="undefined" />

Table 6 below shows the API objects and functions for mobile carrier network operations for cloud automation and migration. &lt;GeoLoc&gt; is a possible recursive hierarchical object, selected from a zone, a site, a DC, a cluster, a node, and a server. The server is a physical layer or a hypervisor level, perhaps a VM. The function name is one of Provision, Program, Decommission, Status and Ignore. VNF is one or more of vEMS, vMME, vSGW, vPGW, vPCRP, vHSS, virtual eNB (veNB), virtual Nano (vNano), vIMS, virtual Open Computer and software (vOCS), VNF and virtual AF (vAF) . The program is one or a combination of the operating system (OS), package, component, connection, interface and communication. The operation is one or a combination of Session, DefBearer, GBR, QoS, DRB, SRG, Tunnel, GTP, Generic Routing Encapsulation (GRE), Alloc and Dealloc. A profile can be set for an INDI subscriber, FAN, for a corporation or organization with several virtual cloud groups (VCGs) and is attached to the APN (s). VCG is a grouping either from an EPC or RAN in a cluster or in a cloud that can be described as a module. Descriptors can use the policy, subscriber profiles, access control lists and other available tools in the API to define options for MNO / MVNO, for network administration during broadcast, in the shell or a combination thereof, using rules. Similarly, some individual or groups of objects can be monitored for active or inactive status and / or protocol.

<img file="00000025.jpg" he="137" wi="160" img-format="jpg" img-content="undefined" />

<img file="00000026.jpg" he="200" wi="160" img-format="jpg" img-content="undefined" />

The MNFV implementation architecture is modular to support flexible, adaptable and extensible APIs through open source platforms, Linux® and OpenStack ™, for virtualization and virtualization properties such as KVM / Linux containers (LXC) and a variety of implementations for MNO through OpenStack ™ CMS.

Embodiment The QuantumLeap API supports the interaction of the EPC cloud and EMS clusters, which constitutes the core network of the mobile network operator. The QuantumLeap API has an open subset that is applicable to mobile carrier network providers using plug-ins.

In addition, interfaces for communication of network infrastructure nodes connected via the south interface in the EMS and EPC clouds can support third party providers. The interface between the QuantumLeap 394 module and the CMS 400 can be used as a broker for other clouds to administer the CloudEPC infrastructure for MNO and their associated MVNO.

The global module of the embodiment uses geographic separation of the network and its slices based on logical sub-objects such as a zone, a site, data centers, clusters and nodes that can be applied on the basis of templates supported via EMS modules to generate large amounts of data and instant ions for provisioning to the network.

Since the MNFV architecture is radio-neutral, it can be used in various radio administration systems, including small cell, UMTS, LTE, Advanced LTE, Ethernet or IP traffic, to support QoS and differentiated services.

Management and policy rules associated with the user level to use resources are notified to OSS / BSS modules via notification interfaces using the CMS.

Access, management and reservation of resources CloudEPC is dynamically administered through interactions between different modules, depending on the request or response calls for reserving and releasing resources by the owners, and their security and resolution levels.

CloudEPC has a separation between data and management planes and the administration plane. EPC clusters work with different VNFs in the logical area at the service level.

VCG isolates groups of radio cells and / or base EPCs, or EPC cloud clusters. The EPC and RAN group type with additional APN attributes of mobile origin or the end of the mobile network or sessions are linked as resources for using the service and charging bills.

Authentication and authorization are performed. QuantumLeap can use the Keystone OpenStack ™ identity service as the default authentication service. When Keystone is enabled, users submit requests to the QuantumLeap service by providing an authentication label in the X-Auth-label request header. The label could be obtained by authentication using Keystone.

When Keystone is enabled, the owner ID for the resources in the formation requests may not be used, because the owner ID is derived from the authentication label. In one example, only administrative users form resources on behalf of different owners.

QuantumLeap can use the information received from Keystone to authorize user requests. QuantumLeap handles two types of authorization policies. A policy-based operation sets up access criteria for specific operations, if necessary, using fine-grained control through specific attributes. A resource-based policy determines when access to specific resources is granted or not granted in accordance with the permissions configured for the resource, for example, for a network resource. Other authorization policies can be used.

The embodiment performs GTP control for VxLAN through the Sx interface in the mobile CloudEPC for tunneling between endpoints. A point-to-point transfer (PTP) is a group of IP-based data exchange protocols for GPRS for networks. In the 3GPP architecture, GTP-based interfaces and the mobile IPv6 proxy are installed at various points in the interface. GTP can be decomposed into separate protocols, GTP-C, GTP-U and GTP '. GTP-C is used within the core of the GPR network for the transmission of signals between the GPRS gateway support nodes (GGSN), and the serving GPRS support nodes (SGSN). Thus, the SGSN activates the session on behalf of the user and deactivates the session to regulate the quality of service parameters (QoS) or to update the session for a subscriber who has just arrived from another SGSN. GTP-U is used to transfer user data within the core GPRS network and between the radio access network and the core network. The transported user data may be packets of IPv4, IPv4, or protocol formats from point-to-point (PPP). GTP uses the same messaging structures as GTP-C and GTP-U, but is used to transfer charging data from the Global System for Mobile Data Communications (GSM) or the UMTS network's charging data (CDF) data function to the gateway function accrual of accounts (CGF).

In an embodiment, the elements of the mobile network are managed through the RESTful API. This can be done via the CMS, if necessary, via EMS. Alternatively, the elements of the mobile network are managed through adapters where cloud administration does not provide interaction for the network.

The embodiment operates on a thread basis where the message flow flows through the RabbitMQ request module, while metadata storage is achieved based on a modular database in MySQL. In one example, the QuantumLeap command is generated through a command line interpreter (CLI) or a horizontal plugin that executes the drive of producer threads that are fed to the QuantumLeap / channel / queue topic via the Asynchronous Message Queuing (AMQP) protocol. The command is distributed through the NOVA scheduler or the RPC callback, which returns the QuantumLeap mechanism, to obtain the service from the worker threads.

Workflows are translated from the scheduler to call a query or response to the CloudEPC or physical nodes, for example, through OpenStack ™ or EMS. CloudEPC includes EPC functions that are located in the cloud or in clusters. CloudEPC is a virtual image with composite or multiple images made from vMME, vSGW, vPGW), vPCRF and / or vHSS.

In one example, the RESTful programming interface is used to administer the MNFV service objects of the north interface and the corresponding calls to the southern interface for the CloudEPC cluster and / or physical nodes. The SB and NB API plug-ins define add-ons that are used to process a fixed or cable portion of a virtual network cluster, for example, to set up a VLAN or VxLAN.

The example has an architecture suitable for forming a plug-in where REST APIs are supported by various objects to form a cloud of a virtual cluster of a mobile network. Additional plugins can be added. In addition, users may be able to use different embodiments of the EPC cluster. Some sample plug-ins include RW, MNO, MVNO, &lt;geolocation (GeoLoc)&gt; = (Zone, site, data center, cluster, node, server), APN, VNF, Subscriber and Session. VNF is called via SB, while RW, MNO, MVNO, GeoLoc, APN, SUB and session are called via NB. VNF can be subclassified to support the EPC cluster, MME, SGW and PGW for SB, for passing through the call.

In one example, to generate an MVNO, a request to generate a JSON can be used. When using CreateAndAssign, the site is a parameter. Alternatively, MVNO is formed without a site. An example of MVNO formation is as follows:

<img file="00000027.jpg" he="50" wi="49" img-format="jpg" img-content="undefined" />

In response, the formation response can be accepted. An example of the JSON formation response is:

<img file="00000028.jpg" he="46" wi="58" img-format="jpg" img-content="undefined" />

<img file="00000029.jpg" he="59" wi="97" img-format="jpg" img-content="undefined" />

An example of an EPC response is as follows:

HTTP / 1/1 200 Accepted Content-Type application / json

Content-Length 204

<img file="00000030.jpg" he="80" wi="113" img-format="jpg" img-content="undefined" />

In one example, the application-level notification implementation affects the event logging mechanisms of OpenStack ™ Ceilometers. In the example, QuantumLeap registers the SI interface with ID = '' 35bl7138-b364-4e6a-al31-8f3099c5be68 '', and sets the SI peak so that it does not exceed the SIHighCap, for example, 10 Mbps. When Si-peak&gt; SIHighCap, the application receives a warning, and determines whether to add another Si-Interface to double the bandwidth of the eSl interface. An example of a sample JSON meter for application level notification (ALN) is specified as follows:

<img file="00000031.jpg" he="37" wi="59" img-format="jpg" img-content="undefined" />

<img file="00000032.jpg" he="73" wi="106" img-format="jpg" img-content="undefined" />

The combination of heat and a solarometer can be used for an ALN ​​that can use external specific resources such as:

<img file="00000033.jpg" he="124" wi="115" img-format="jpg" img-content="undefined" />

The implementation of QuantumLeap API is extensible. Stretching facilitates the introduction of new properties in the API without changing the version. In addition, the expansion facilitates the introduction of a vendor-specific niche functionality and the provision of a test site for experimental functions. Applications can programmatically determine which extensions are available by running the GET command for vl.0 / URI extensions. Extensions can be requested individually using a unique alias, by performing a GET operation for /vl.0/extensions/alias_name. Existing kernel API resources can be extended to give them new actions or additional attributes. In addition, new resources can be added as extensions. Extensions can have labels that prevent collisions with other extensions, defining attributes and / or resources with the same name as the resources and attributes of the kernel. The availability of the extension may depend on the deployment and specific use of the plug-in.

When a request fails, the QuantumLeap API returns an error response. QuantumLeap uses standard HTTP error codes. 4xx errors indicate problems in a specific request transmitted by the client. Table 7 illustrates some sample errors. Users submitting a request to the QuantumLeap API can also accept an unauthorized 401 when they provide invalid credentials and a 403 Forbidden error (prohibited) when the user can not access a particular resource or perform the requested operation.

<img file="00000034.jpg" he="37" wi="72" img-format="jpg" img-content="undefined" />

An example of a JSON request for the Create And Assign site is specified as follows:

<img file="00000035.jpg" he="102" wi="85" img-format="jpg" img-content="undefined" />

<img file="00000036.jpg" he="229" wi="160" img-format="jpg" img-content="undefined" />

<img file="00000037.jpg" he="5" wi="4" img-format="jpg" img-content="undefined" />

The JSON response example for the CreateAndAssign site is defined as follows:

<img file="00000038.jpg" he="242" wi="121" img-format="jpg" img-content="undefined" />

<img file="00000039.jpg" he="124" wi="106" img-format="jpg" img-content="undefined" />

The APN of Json is defined as follows:

<img file="00000040.jpg" he="88" wi="123" img-format="jpg" img-content="undefined" />

The JSON response APN example is defined as follows:

<img file="00000041.jpg" he="32" wi="60" img-format="jpg" img-content="undefined" />

<img file="00000042.jpg" he="73" wi="103" img-format="jpg" img-content="undefined" />

The example of VNF formation of Json is defined as follows:

<img file="00000043.jpg" he="164" wi="160" img-format="jpg" img-content="undefined" />

<img file="00000044.jpg" he="72" wi="103" img-format="jpg" img-content="undefined" />

The JSON response VNF example is defined as follows:

<img file="00000045.jpg" he="206" wi="160" img-format="jpg" img-content="undefined" />

<img file="00000046.jpg" he="20" wi="18" img-format="jpg" img-content="undefined" />

The example of SUB request and JSON authentication is defined as follows:

<img file="00000047.jpg" he="144" wi="71" img-format="jpg" img-content="undefined" />

The JSON response SUB example is defined as follows:

<img file="00000048.jpg" he="71" wi="77" img-format="jpg" img-content="undefined" />

<img file="00000049.jpg" he="249" wi="105" img-format="jpg" img-content="undefined" />

An example of the formation of a JSON operation or session is defined as follows:

<img file="00000050.jpg" he="101" wi="109" img-format="jpg" img-content="undefined" />

An example of the response of an operation or JSON session is determined by the following:

<img file="00000051.jpg" he="138" wi="109" img-format="jpg" img-content="undefined" />

The VNF API is used for internal EPC interfaces and communications. The API is described as the descriptor connection destination for an image connection descriptor for an image with the name of the VNF ID function.

API attributes are:

VNF = MME-Instance-id, function-name = Program, Image = Script image-link = http: //mysite.org/rnmel.sh Descriptor = mme.xml Descriptor - link = http: //mysite.org/mmel .xml Destination = MME-Instance-IP-address

The image name "script" refers to the implementation procedures before and after installation, depending on the name of the function. In this example, the function name is a program, and an instance of ID or VNF is available. Thus, the post-installation script works to configure interfaces and links in the descriptor. The mmel.xml descriptor or the five epc.xml nodes contain interfaces at the management level and interfaces at the data level. Interfaces at the control level or CIO I / O control can include from S1-MME-eNB to MME, from S6a-MME to HSS, from S11-MME to S-GW and from Sp-HSS to PCRF. Interfaces on the data layer or DIO I / O data include S1-U-eNB to S-Gw, S5 to S-GW to P-GW, S8 to S-GW to P-GW, SGi to access to the Internet, Gx to P-GW to PCRF and from Gxc to S-GW to PCRF.

The embodiment is directed to a standardized, software interface for the mobile domain.

The standard API of the north interface is used for MNO / MVNO / EMS, while the standard API of the southern interface is used for mapping, then NB on SB 1 aaS via CMS. Integration to OpenStack ™ can be used here.

In one example, the MNFV is embodied in a system using logical hardware units. Alternatively, MNFV is embodied as software executable in a processor, controller, application specific integrated circuit, and so on. In a further embodiment, the MNFV is embodied as a combination of software and hardware.

In Fig. 20 is a block diagram of a processing system 270 that can be used to implement the devices and methods disclosed herein. Certain devices can use all the presented components or only a subset of components, and the integration levels can vary from device to device. In addition, the device may contain multiple instances of a component, such as a plurality of processing units, processors, memory devices, transmitters, receivers, etc. The processing system may comprise a processing unit equipped with one or more input devices, such as a microphone, a mouse, a touch screen, a keypad, a keyboard, and the like. In addition, the processing system 270 may be equipped with one or more output devices such as a loudspeaker, printer, display, and the like.

The bus may be one or more of any type of bus from several bus architectures, including a memory bus or memory controller, a peripheral bus, a video bus, and the like. The CPU 274 may comprise any type of electronic data processor. The memory 276 can comprise any type of intransitive system memory, such as a static random access memory (SRAM), a dynamic random access memory (DRAM), a synchronous DRAM (SDRAM), a ROM, a combination thereof, and the like. In an embodiment, the storage device may include a ROM for use at bootstrap, and DRAM for storing the program and data intended for use in executing programs.

The mass storage 278 can comprise any type of non-transitive storage device configured to store data, programs and other information, and to make data, programs and other information accessible via a bus. The mass storage 278 can comprise, for example, one or more of a solid state drive, a hard disk drive, a magnetic disk drive, an optical disk drive, and the like.

The video adapter 280 and the software interface 288 provide interfaces for connecting external input and output devices to the processing module. As presented, examples of input and output devices include a display connected to a video adapter and a mouse / keyboard / printer connected to the software interface. Other devices can be connected to the processing module, and additional or fewer interface cards can be used. For example, a serial interface card (not shown) can be used to provide a serial interface to the printer.

The processing unit also includes one network interface 284 or more that can comprise wired connections such as an Ethernet cable and the like and / or wireless connections for accessing nodes or different networks. The network interface 284 allows the processing module to communicate with remote modules through networks. For example, the network interface may provide wireless data transmission through one or more transmitters / transmit antennas and one or more receivers / receive antennas. In an embodiment, the processing module is connected to a local computer network or a wide area network for processing data and exchanging data with remote devices, such as other processing modules, the Internet, remote storage facilities, and the like.

While a number of embodiments have been presented in the present disclosure, it should be understood that the disclosed systems and methods may be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples should be considered as illustrative and not restrictive, and the invention is not limited to the details presented herein. For example, various elements or components may be combined or integrated in another system, or certain properties may be excluded or not embodied.

In addition, the technologies, systems, subsystems and methods described and presented in various embodiments, both discrete or separate, can be combined or integrated with other systems, modules, technologies or methods, without going beyond the scope of the present disclosure.

Other elements shown or described as being connected or directly connected or exchanging data with each other can be indirectly connected or can exchange data through some interface, device or intermediate component, in electrical, mechanical form or otherwise. Other examples of changes, substitutions and modifications will be apparent to one skilled in the art and may be performed without departing from the scope and scope disclosed herein.