WO2018000239A1

WO2018000239A1 - Assurance of end-to-end quality-of-service over networks that implement network function virtualization

Info

Publication number: WO2018000239A1
Application number: PCT/CN2016/087657
Authority: WO
Inventors: Tao Zheng; Xiaoyu Wang
Original assignee: Orange
Priority date: 2016-06-29
Filing date: 2016-06-29
Publication date: 2018-01-04

Abstract

A method of assuring end-to-end quality of service for a network service implemented on networking infrastructure comprising network function virtualization (NFV) comprises determining a target profile for end-to-end quality of service (QoS) for the network service, monitoring network function virtualization platform information as it changes， determining a service chain deployment, comprising virtualised network functions, satisfying said target QoS profile and output-ting information indicative of the determined service chain deployment to NFV management infrastructure for set-up of the VNFs of said service chain.

Description

Assurance of End-to-end Quality-of-Service over Networks that implement Network Function Virtualization

Background Technical field

The present invention relates to the implementation of communications network functionality and, in particular, to functionality for implementing network services that operate over networks that implement Network Function Virtualization (NFV) . More especially, the invention provides a method and system to assure end-to-end quality of service over network infrastructure in which implement network function virtualization is implemented.

Related art

In communications networks, networking has traditionally been implemented using specialised hardware to provide the required functionality. To improve the pace of improvement in networking technology, and in the light of increasing convergence between telecommunications networks and data communications networks, software implementations of networking equipment have been developed.

Thus, for example, the European Telecommunications Standards Institute (ETSI) has issued standards involving use of network function virtualization (NFV) in next generation communications networks. NFV involves ″virtualizing″ tasks which would have been performed in the past by dedicated and specialized hardware so that, instead, they may be implemented in software, for example using virtual machines and/or software applications executed by commodity-based hardware (e.g. servers and other commercial off-the-shelf (COTS) hardware) .

In the present document the expression ″communications network″ refers in general to networks of different kinds including, inter alia, telecommunications networks and data-communications networks (and converged networks) , whether providing fixed or mobile services. The expression ″computer network″ as used herein may also refer to the same networks in view of the fact that the present document discusses networks in which network functions are virtualized. Incidentally, the present invention may be applied in relation to network services that operate over network infrastructure in which NFV is implemented at least to some extent； in other words, the invention may be applied even in the case where the network infrastructure still employs one or more dedicated hardware elements (physical network functions, PNFs) .

A given end-to-end service that operates over communications networks, e.g. a video-on-demand streaming service, a voice over IP service, etc., can be defined in terms of a forwarding graph of network functions and end points/terminals. The expression ″network service″ used herein refers to some service that is implemented with the aid of network infrastructure and which involves performance of technical functions by components in the network (e.g. communications functions, networking functions, firewall functionality, domain name resolution functionality, and so on) .

In a network environment where NFV is employed the service model of a given network service may be implemented by network service chaining, as illustrated in figure 1. Some or all of the network functions needed to operate the network service may be implemented using virtual network functions (VNFs) . The VNFs may be considered to be middleboxes and elements of network services that are to be deployed in a cloud platform. The network service is implemented on a service platform which may belong to a network operator or other service provider.

Typically, different types and different numbers of VNFs may be instantiated on network infrastructure so that the network has the capability of supporting different network services. In view of the virtualized nature of VNFs there is often considerable flexibility regarding ″where″ in the network infrastructure a given VNF will be instantiated, i.e. which resources (computing power, storage, networking resources) of which specific hardware component will be allocated for implementing the associated virtual machine/run the associated application software.

Figure 1 illustrates a simple generalised example of a network service implemented using VNFs 102, 104, and 106. For the purposes of the present discussion the specific functions of these elements is unimportant. However, VNFs may be used to provide various functions including, but not limited to: deep packet inspection, virtual firewalls, load balancing, evolved packet core features, base station functionality, intrusion prevention, virtual routing, and so on. Also, for the purposes of simplification, figure 1 does not represent all elements of the service platform on which the network service is implemented.

As illustrated in figure 1, the VNFs 102, 104, 106 are in communication with one another via network infrastructure.

End points

100 and 108 of the architecture represent the service end points, such as for example a user terminal connected to a base station 1 and/or a processing device in a house 27 (see figure 3 discussed below) . As illustrated in figure 1, the end point 100 is in communication with the VNF 102 via a first infrastructure network 110, the end point 108 is in communication with the VNF 106 via a third infrastructure network 116, and VNF 102 is in communication with VNF 104 via infrastructure network 114. Moreover, there may be various networks 115 between the VNF 104 and the VNF 106.

The infrastructure hardware used in implementing the network service illustrated in figure 1 may depend on the nature of the service: typically it may include servers, storage, communications links, routing devices, control and management units, and so on. The communications links used in implementing the network service illustrated in figure 1 may be wired and/or wireless.

ETSI has defined a framework, known as NFV MANO, for the management and orchestration of NFV resources in networking infrastructure (including management of computing, networking, storage and virtual machine (VM) resources) . Implementation of NFV MANO involves use of three main functional modules -NFV Orchestrator, VNF Manager and Virtualized Infrastructure Manager (VIM) –interacting with application program interfaces (APIs) that are provided on components in the network infrastructure. According to the ETSI NFV MANO framework, the manner in which individual VNFs are managed on a commodity hardware platform is described using an Elemental Management System (EMS) .

Figure 2 illustrates schematically an example of network infrastructure architecture provided with NFV MANO components that interact with one another, with EMSs and other network infrastructure elements in order to manage and orchestrate NFV resources. In the example of figure 2 the network infrastructure includes NFV infrastructure (NFVI) 120 including hardware resources 121 with an associated virtualization layer 122 for instantiating VNFs 124 which are managed according to EMSs 125. The network infrastructure includes business support systems (BSS) and/or operations support systems (OSS) 128 provided by network service providers for managing their networks (e.g., telephone networks) . The BSS/OSS 128 provides functionality to support functions such as service provisioning and network configuration and fault management.

In the example of figure 2 NFV MANO infrastructure 130 is interconnected to the network infrastructure and it comprises the three functions mentioned above: an NFV orchestrator (NFVO) 132, a set of VNF Managers 134 and a virtualized Infrastructure manager (VIM) 136. The N FV Orchestrator (NFVO) 132 is configured to be in communication with the OSS/BSS 128, the set of VNF managers 134 and the virtualized infrastructure manager (VIM) 136. The set of VNF managers 134 are configured to be in communication with the VNFs 124 and their associated EMSs 125, as well as with the NFVO 132 and the VIM 136. The VIM 136 is configured to be in communication with the NFV infrastructure 120 as well as with the set of VNF mangers 134 and the NFVO 132.

NFV MANO can be installed according to its own capacity, network size, network types and network location. Generally, one set of NFV MANO components is connected to one single operator′s NFV network, unless the size of a single NFV network exceeds the capacity of a NFV MANO (in which case, the NFV network can be divided into several parts connecting to different MANOs, for example according to geographic location) or the single network may have been divided into different parts in advance because of its very large-scale coverage (for example, in China a nationwide network is divided up, generally by different provinces) . .

The example of figure 2 is simplified. In reality communications networks tend to be interconnected in complex webs that include, for example, network infrastructure operated by different telecommunications companies, networks implementing different technology standards, and so on. Typically, network services may be implemented using VNFs that are located in plural, different infrastructure networks. In addition, one end-to-end service usually relates to different networks, or network parts, belonging to different MANOs. In the example of figure 1 the VNFs of the service chain are located in three

different infrastructure networks

110, 114, 116. Accordingly, there may be a large physical distance between two successive VNFs in a service chain. This issue is illustrated by figure 3.

Figure 3 illustrates an example of network architecture implementing, inter alia, mobile telecommunications, in which NFV is employed to virtualize the dependency between network functions and the associated hardware. In the example of figure 3 substantially all of the network functions are illustrated as VNFs but the skilled person will recognize that physical network functions (PNFs) may also be present in network infrastructure. The cloud shapes shown in figure 3 represent hardware resource pools.

In figure 3, the virtualization of base stations is represented by a hardware pool 3. As illustrated, base stations (BS) 1 can provide communications capabilities via software implementations of functions such as the functions of LTE virtual bases stations (vBS LTE) 5, 3G virtual base stations (vBS 3G) 7, 2G virtual base stations (vBS 2G) 9 and WiMax virtual base stations (vBS WiMax) 11 that run on hardware devices 13.

The skilled person will recognise that content delivery network (CDN) functionality 15 can be virtualized so as to be implemented via software implementation 17 on hardware devices 13 (two virtualized CDN functions are illustrated in figure 3) . The network infrastructure illustrated in figure 3 also includes virtualized home and enterprise networks 21, virtualized fixed access networks 23 (for communication with homes 27 and offices 25) , virtualized mobile core networks/IMS 19 and virtualized mobile IP networking systems 29. Each of these

virtualized systems

21, 23, 29, 19 is provided via software implementations running on hardware 13.

Thus, in respect of virtualization in fixed access networking 23, figure 3 illustrates the provision of virtualized control plane functionality of Asymmetric digital subscriber lines ASDL 31, of Very-high-bit-rate digital subscriber lines (VDSL) 33 and virtualized control plane functionality conforming to ITU-T or G standards (ITU-T/G) 35. In respect of virtualization in home/enterprise networking 21, figure 3 illustrates virtualized residential gateways (RGW) 37, virtualized Network address translation (NAT) 39 and virtualized set-top box functionality 41 provided via software implementations running on hardware 13.

In respect of virtualization of core mobile networks 19, figure 3 illustrates virtualization of functions and entities such as Call Session Control Function (CSCF) 43, signalling gateway (SGW) 45, mobility management entity (MME) 47, domain name server (DNS) 49, Dynamic Host Configuration Protocol (DHCP) 51 and firewalls 53, with the functions provided via software implementations running on hardware 13. In respect of virtualized mobile IP networking systems 29, figure 3 illustrates a case where CSCF 43, MME 47, DHCP 51 are also provided in virtualized form, as well as virtualized packet data network gateways (PGW) 55, virtualized App servers 57 and virtualized load balancing 59.

Figure 3 represents an example in which several

different cloud infrastructures

3, 15, 19, 21, 23 and 29 are interconnected. These may well correspond to networks operated and managed by different operating companies. In this example NFV is implemented in all of the illustrated cloud infrastructures and each one is liable to have its own set of NFV MANO components.

As an example of a network service that may be provided using a networking architecture such as that of figure 3, consider a cloud application which a user can access using his mobile device via networking capability provided using LTE. This is illustrated using the VNF forwarding graph 61 at the top of figure 3. The skilled person will recognise that this is merely one example of a VNF forwarding graph selected for one service provided using one particular type networking architecture. Other forwarding graphs representing other services can also be generated, and such graphs need not be merely linear as depicted in figure 3, for example they may contain branches.

As illustrated, the example network service represented by forwarding graph 61 is considered to start at an LTE vBS 5 (represented in the forwarding graph as 63) . In reality in this example the end point of the service is actually an end-user whose user equipment communicates with the LTE base station via a wireless interface, but from the point of view of the network infrastructure the service chain may be considered to begin at the base station. The LTE virtualized base station 5 communicates with an MME 47 in the core mobile network 19 (represented in the forwarding graph as 65) and then an SGW 45 in the core mobile network 19 (represented in the forwarding graph as 67) . Subsequently, the service communicates with a PGW 55 in the mobile IP networking system 29 (represented in the forwarding graph as 69) and an App server in the mobile IP networking system 29 (represented in the forwarding graph as 71) which hosts the cloud application the user wishes to access.

In the example illustrated in figure 3 the VNFs are deployed in several different cloud infrastructures. So, in the VNF forwarding graph, the connections from the first VNF 63 in the service chain (i.e. LTE virtualized base station 5) to the second VNF 65 (i.e. virtualized mobile management entity 47) and from the third VNF 67 (i.e. virtualized signaling gateway 45) to the fourth VNF 69 (i.e. virtualized packet data network gateway 55) are long distance connections. Thus, these two connections are likely to have a huge impact on the end-to-end quality of service (QoS) that is attained by the network service which is implemented using a service chain that embodies this VNF forwarding graph 61.

Ensuring that end-to-end QoS requirements are satisfied in network service chains is particularly important, especially to telecommunications operators. Various techniques are known for monitoring performance in networking infrastructure and for managing the implementation of network function virtualization. However, the known techniques do not provide methods or systems that assure end-to-end QoS for network services that operate over real-world network infrastructure in which NFV is implemented.

Accordingly, it is an aim of the present invention to solve or mitigate at least some of the above-described problems.

Summary

In the present document reference is made to ″assuring″ that end-to-end QoS requirements are satisfied in networking infrastructure in which NFV is employed. It is to be understood that use of this expression (and its correlates, such as ″assures″ , ″assurance″ , and so on) does not imply a requirement for the described methods and systems to ensure that specified QoS requirements are perfectly satisfied at all times. Rather this expression, and its correlates, indicate that the methods and systems according to the invention operate to promote satisfaction of the end-to-end QoS requirements, for example by taking action (reactively or proactively) to avoid or remedy a drop in attained end-to-end QoS and by taking action to set up service chains in a manner which favours satisfaction of end-to-end QoS requirements.

In the present document reference is made to assuring that QoS requirements for a network service are satisfied ″end-to-end″ . This refers to the quality of service between two end points involved in some transaction or communication as part of implementation of the network service. Embodiments of the invention affect the VNFs deployed in the overall service chain and thereby promote the satisfaction of the end to end QoS requirements.

In a first aspect, the present invention provides a method of assuring end-to-end quality of service for a network service implemented on networking infrastructure comprising network function virtualization (NFV) , the method comprising:

determining a target profile for end-to-end quality of service (QoS) for the network service；

monitoring network function virtualization platform information as it changes；

determining a service chain deployment, comprising virtualised network functions, satisfying said target QoS profile； and

outputting information indicative of the determined service chain deployment to NFV management infrastructure for set-up of the VNFs of said service chain.

In a second aspect, the present invention provides a system to assure end-to-end quality of service for a network service implemented on networking infrastructure comprising network function virtualization (NFV) , the system comprising:

an NFV end-to-end QoS manager configured to determine a target profile for end-to-end quality of service (QoS) for the network service； and

an NFV-platform information monitoring module configured to monitor network function virtualization platform information as it changes；

wherein the end-to-end QoS manager is configured to determine a service chain deployment, comprising virtualised network functions, satisfying said target QoS profile, and to output information indicative of the determined service chain deployment to NFV management infrastructure for set-up of the VNFs of said service chain.

In further aspects there is provided a computer program product comprising computer readable instructions which, when executed by a processor perform all of the steps of the method of the first aspect, and a computer readable medium comprising such a computer program.

The method, system and computer program product according to the invention provide a technique for assuring end-to-end QoS for a network service implemented in networking infrastructure wherein NFV is implemented. The provided method, system and computer program product provide simplified handling of scenarios such as those which may be involved when implementing network services ″across-MANOs″ , for example roaming, inter-communications between network operators and multiple MANOs deployment (one operator having several independent networks) .

In certain embodiments of the method, system and computer program product the same unified modules and algorithm are which are used when generating service chains that assure desired end-to-end QoS are also used when handling failures of VNFs； this reduces system complexity.

Brief description of the drawings

The invention will now be illustrated by describing certain embodiments thereof, described for the purposes of illustration only, and not limitation, with reference to the accompanying drawings of which:

Figure 1 illustrates a simplified example of a network forwarding graph；

Figure 2 illustrates schematically the provision of NFV-MANO components to manage NFV in an example network infrastructure；

Figure 3 illustrates a known example of a network architecture implementing mobile telecommunications in which NFV is employed to virtualise the relationship between network functions and the associated hardware；

Figure 4 illustrates an example of a system according to an embodiment of the invention to assure a service chain′s end-to-end QoS in communications network infrastructure where NFV is implemented.

Figure 5 illustrates an embodiment in which the QoS assurance system of figure 4 is deployed externally to NFV-MANO；

Figure 6 illustrates an embodiment in which the QoS assurance system of figure 4 is deployed internally to NFV-MANO；

Figure 7 illustrates an example of a method according to an embodiment of the invention to assure a service chain′s end-to-end QoS in communications network infrastructure where NFV is implemented.

Figure 8 illustrates an example of interactions that may take place between components of the QoS assurance system of figure 4 and components of network infrastructure at a time when a new service chain is generated； and

Figure 9 illustrates an example of interactions that may take place between components of the QoS assurance system of figure 4 and components of network infrastructure when QoS is unsatisfied and/or a QoS profile is changed.

Detailed Description

There now follows a detailed description of certain embodiments of the invention.

The skilled person will recognise that essentially any service chain can be implemented using different VNFs in different configurations, and there is no particular limitation on the number or type of VNFs employed or in the manner in which such VNFs are connected to one another. Thus, for example, the principles discussed below may be applied in respect of assuring end-to-end QoS for service chains implemented in the network architecture of figure 3 and, indeed, for service chains implemented over substantially any communications network infrastructure in which NFV is implemented. The examples below will be described in a context where the management and orchestration of NFV in a networking infrastructure are handled according to the ETSI NFV-MANO framework, but it is to be understood that the present invention is not limited to application in that context, the invention may be applied in the context of other frameworks.

According to a first aspect, certain embodiments of the present invention provide a system to assure a service chain′s end-to-end QoS in communications network infrastructure where NFV is implemented. The system comprises two new functional modules to handle the end-to-end QoS of NFV′s service chain to the network infrastructure.

Figure 4 illustrates an example of a system 200, according to an embodiment of the invention, to assure a service chain′s end-to-end (E2E) QoS in communications network infrastructure where NFV is implemented.

The system 200 to assure E2E QoS comprises an NFV-platform information center 210 which operates to collect NFV platform information that impacts on the end-to-end QoS of a service chain that is (or is to be) implemented using VNFs. The NFV-platform information center 210 may be configured to collect the following items of information:

a) each infrastructure network′s location

b) transmission delay between each two infrastructure networks

c) current state of deployment of VNFs (VNF types, the platform where each VNF is located)

d) NFV platform′s load rate

The specific items of information, regarding the NFV platform, which are monitored by the NFV-platform information center 210 may vary depending on the use case； for example in the case of mobile services it may be appropriate to monitor a greater number of special NFV-platform information items than in the case of fixed-line services. In many use cases it is advantageous to monitor the four information items a) to d) of the above list in order to ensure that a judicious choice is made of deployment solution (see below) . Monitoring the transmission delay and network location can increase the likelihood of choosing, for deployment, VNFs which are instantiated in locations which have a relatively greater positive impact on QoS. Monitoring the current state of deployment of VNFs promotes reuse of VNFs after they have finished other tasks, or during the runtime, and this can reduce costs. Monitoring the NFV platform′s load rate can help to deploy VNFs more balanced among the whole NFV platform on the premise that the service chain′s E2E QoS is assured.

The NFV-platform information center 210 may be configured:

-to receive the NFV platform information from NFV management and organization (MANO) infrastructure provided in the networking architecture in which the network service is being (or will be) implemented, and

-to maintain a record of the collected information, and keep the record updated in an ongoing manner.

During a preliminary phase, the NFV-platform information center 210 may be configured to establish a preliminary record of the NFV-platform information of the NFV-MANOs in the networking infrastructure, as a kind of image of the current state of the NFV platform with which the system 200 may interact. In this preliminary phase the NFV-platform information center 210 may establish the preliminary record in a variety of ways. In one example, the preliminary record is recorded in the NFV-platform information center by explicit programming (manual or automated) . In another example a kind of ″NFV-MANO discovery″ process may be implemented involving communication between the NFV-platform information center 210 and the NFV-MANOs in the networking infrastructure, whereby the NFV-platform information center 210 discovers the NFV-MANOs that are operating in the networking infrastructure and obtains their NFV-platform information.

The NFV-MANO infrastructure which communicates with the system 200 may be configured so that, during the operational phase of system 200, the NFV-MANOs respond to changes they are aware of in NFV-platform parameters that impact on end-to-end performance (e.g. parameters mentioned under a) to d) above) by reporting the changes to the NFV-platform information center 210, thereby keeping the NFV-platform information center 210 updated. Each NFV-MANO reports NFV-platform changes in the NFV infrastructure which it is managing. If desired the NFV-MANOs may be configured to report current values of relevant NFV-platform parameters to the NFV-platform information center 210 even at times when no change occurs (e.g. periodically or intermittently； spontaneously or triggered by receipt of a request from the NFV-platform information center 210) .

Existing NFV-MANO components already determine some of the NFV-platform information items that are of use to the NFV-platform information center 210. New functions and physical/software interfaces may be added to existing NFVMANO components as needed so that the NFV-MANO components determine other NFV-platform information items required by the NFV-platform information center 210 and communicate the determined information items to the NFV-platform information center 210. Of course, new NFV-MANO components may be built which already include all the required functions and interfaces.

The system 200 to assure E2E QoS further comprises an NFV end-to-end QoS manager 220 which operates to assure satisfaction of end-to-end QoS by generating a deployment solution of VNFs to implement a service chain satisfying the QoS profile. More specifically, the NFV end-to-end QoS manager 220 may be configured:

- to retrieve, from an external source, information regarding the desired/required QoS,

- to retrieve NFV-platform-related information from the NFV platform information center 210, and

- to generate an NFV-deployment configuration to implement a service chain satisfying the desired/required QoS.

to retrieve, for example from a QoS function of the service platform implementing the network service in question, information

Thus, for example, the NFV end-to-end QoS manager 220 may be configured to communicate with a QoS function of the service platform which implements the relevant network service, in order to obtain details of an end-to-end QoS profile associated with the network service. The physical (or virtualized) element from which the NFV end-to-end QoS manager 220 retrieves the QoS profile may vary dependent on the implementation of the external service platform.

As an example, the QoS profile may include the following information:

i) end-to-end delay requirement

ii) specific delay requirement (e.g. between specific VNFs in the network function forwarding graph)

iii) traffic distribution (if needed)

iv) computing load of each VNF in the network function forwarding graph

v) resource requirement of each VNF in the network function forwarding graph needed

The specific parameters or indicators that form part of the QoS profile may vary depending on the network service in question； for example in the case of certain mobile services the QoS profile may include parameters as defined in table 1 of the ETSI and GPP standard TS22.105 version 13.0.0 (currently accessible at http: //www. 3gpp. org/DynaReport/22105. htm) .

The NFV end-to-end QoS manager 220 may be configured to use any convenient technique to generate an NFV-deployment configuration to implement a service chain satisfying the desired/required QoS. Thus, for example, the NFV end-to-end QoS manager 220 may implement techniques described in the applicant′s co-pending PCT patent application filed on the same day as the present application and entitled ″Method and system for the optimisation of deployment of virtual network functions in a communications network that uses software defined networking″ , the entire contents of which are incorporated herein by reference.

The components of the system 200 to assure E2E QoS may be provided in the networking infrastructure in various ways. For example, each of the NFV-platform information center 210 and the NFV end-to-end QoS manager 220 may be implemented using a processing apparatus (for example, computer apparatus comprising a processor) configured to execute instructions of a computer program to implement the above-described functionality. The processing apparatus may form part of the network, for example it may constituted by a server in the network, but this is not essential. Each of the NFV-platform information center 210 and the NFV end-to-end QoS manager 220 may be implemented as one or more physical network functions, as one or more virtualized network functions, or a combination of the two.

The system 200 to assure E2E QoS may be deployed in networking infrastructure in various different ways. Figure 6 illustrates a first deployment scenario for the system 200 to assure E2E QoS. This first deployment scenario corresponds to an independent deployment mode. In this scenario, the NFV-platform information center 210 and the NFV end-to-end QoS manager 220 are separate from NFV MANO infrastructure and communicate with the NFV MANO infrastructure through external interfaces, for example via the Se-Ma interface defined in the ETSI NFV framework. This first deployment scenario applies to distributed and integrated NFV MANO models.

Figure 7 illustrates a second deployment scenario for the system 200 to assure E2E QoS. This second deployment scenario corresponds to a dependent deployment mode. In this scenario, the NFV-platform information center 210 and the NFV end-to-end QoS manager 220 are integrated with NFV MANO as two internal functions and communicate with NFV MANO through internal interfaces. This second deployment scenario only applies to an integrated NFV MANO model.

According to a second aspect, certain embodiments of the present invention provide a method to assure a service chain′s end-to-end QoS in communications network infrastructure where NFV is implemented. Figure 7 illustrates an example of the method.

In the example according to figure 7, the method comprises determining a target profile of end-to-end QoS for a network service (S10) . The target QoS profile may be obtained in various ways. For example, when a network service is being commissioned the service provider may specify requirements for end-to-end QoS. One or more of these requirements may form the target QoS profile. As another example, the service provider may update or otherwise modify the requirements for end-to-end QoS and the target QoS profile determined in step S10 may be based on the changed QoS profile.

In the example according to figure 7, the method further comprises ongoing monitoring (S20) of information regarding the NFV-platform. This monitoring may be performed by the NFV platform information center 210 as described above. Based on the target profile for end-to-end QoS and the current status of the NFV-platform (as indicated by the monitoring information obtained in S20) , a deployment of VNFs that would satisfy the target profile for end-to-end QoS may be generated (S30) and details of the VNF deployment may be outputted (S40) . In a case where the method is implemented in networking infrastructure that includes NFV-MANO components, the details of the generated VNF deployment solution may be outputted to the relevant NFV-MANO components in a request for set-up the VNFs, of the generated deployment solution, for which they are responsible.

The method may include special process flows when a service chain is generated and/or special process flows when there is a change such that a QoS requirement is unsatisfied.

An embodiment will now be described, with reference to figure 8, in a context where an example method according to the invention implements processing flows in a case where a new service chain is being generated. The example method will be described as performed by the system of figure 4.

Figure 8 illustrates interactions that may take place between the NFV-platform information center 210, NFV end-to-end QoS manager 220, a QoS function 300 of a service platform and a plurality of NFV-MANO installations 130a-130c in a case where the service platform intends to implement a network service so a new service chain is being generated and the service chain which ends up being generated involves VNFs to be managed by the plurality of different NFV-MANO installations 130a-130c.

The following interactions/processing steps arise in the example method illustrated in figure 8:

1) The various NFV MANO installations managing VNFs in the service chain of the network service report the NFV platform information to the NFV platform information center/function 210 when the related information changes.

2) The NFV QoS manager/function 220 sends a request to the QoS function 300 of the service platform to obtain the target QoS profile from 3^rd party service/QoS function 300.

3) The QoS function 300 of the service platform returns QoS profile information to the NFV QoS manager/function 220.

4) NFV QoS manager/function220 sends a request to the NFV platform information center/function 210 to obtain NFV platform information relevant to implementation of the target network service.

5) The NFV platform information center/function 210 responds to the request of step 4 by sending the relevant NFV platform information to the NFV QoS manager/function220.

6) The NFV QoS manager/function 220 generates a candidate deployment solution of a service chain according to related information it retrieved.

7) a) If a satisfactory new deployment solution cannot be found in step 5, then the processing flow ends and there is no deployment solution to satisfy the service′s QoS. A report of the failure may be generated and may, for example, be transmitted to the service provider. The process flow then ends.

Or

b) If a candidate solution is generated in step 6, the NFV QoS manager/function 220 sends information indicative of the solution to each related NFV MANO to request to set up related VNFs under management by that NFV MANO. Each NFV-MANO receives the information it requires to set-up the VNFs under its management which form part of the service chain in the candidate solution.

8) Each involved NFV MANO reports back to the NFV QoS manager/function 220 regarding the result of setting up (or attempting to set up) the relevant VNFs

9) If all VNFs belonging to the service chain set up successfully, the service chain generating flow will finish successfully.

Or

If some VNFs set up unsuccessfully, the process flow will return to step 6.

Figure 9 illustrates interactions that may take place between the NFV-platform information center 210, NFV end-to-end QoS manager 220, a network function relevant to QoS of the network service and a plurality of NFV-MANO installations 130a-130c in a case where, as a result of a change, a new deployment solution of VNFs may be needed in order to assure desired end-to-end QoS for a network service. Such a change may be, for example, the occurrence of some failure condition or degradation of system performance which results in the achieved QoS being less than desired (e.g. a QoS alarm may trigger the interactions illustrated in figure 9) . As another example, the change may derive from an updating of the QoS profile associated with the network service. Accordingly, the related network function may be, for example, the QoS function 300 of the service platform, a network function which detects a failure condition, and so on.

The following interactions/processing steps arise in the example method illustrated in figure 9:

2) When QoS alerts are generated relating to the network service, or the QoS profile for the network service is changed, the related function transmits to the NFV QoS manager/function 220 information indicative of the changed condition (s) .

3) The NFV QoS manager/function 220 sends a request to the NFV platform information center/function 210 asking for the NFV platform information that is relevant to the network service in question.

4) The NFV-platform information center 210 returns the relevant NFV-platform information to the NFV QoS manager/function 220.

5) The NFV QoS manager/function 220 generates a new service-chain deployment solution with the aim of finding a new solution which will satisfy the desired end-to-end QoS profile, taking into account any applicable retrieved related information. The new service-chain deployment solution may be expressed as an adjustment of a current service-chain deployment solution

6) a) If a satisfactory new deployment solution cannot be found in step 5, then the processing flow ends and there is no deployment solution to satisfy the service′s QoS. A report of the failure may be generated.

Or

b) If a satisfactory new deployment solution is found in step 5, the NFV QoS manager/function 220 sends information indicative of the solution to each related NFV MANO to request modification of related VNFs under management by that NFV MANO.

7) Each involved NFV MANO reports back to the NFV QoS manager/function 220 regarding the result of adjusting (or attempting to adjust) the relevant VNFs.

8) If all of the related VNFs are modified successfully, the processing flow will finish successfully.

Or

If some related VNFs are modified unsuccessfully, the process flow will return to step 5.

Embodiments can be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which -when loaded in an information processing system -is able to carry out these methods. Computer program means or computer program in the present context mean any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after conversion to another language. Such a computer program can be stored on a computer-or machine-readable medium allowing data, instructions, messages or message packets, and other machine-readable information to be read from the medium. The computer-or machine-readable medium may include non-volatile memory, such as ROM, Flash memory, Disk drive memory, CD-ROM, and other permanent storage. Additionally, a computer-or machine-readable medium may include, for example, volatile storage such as RAM, buffers, cache memory, and network circuits. Furthermore, the computer-or machine readable-medium may comprise computer-or machine-readable information in a transitory state medium such as a network link and/or a network interface, including a wired network or a wireless network, that allow a device to read such computer-or machine-readable information.

Expressions such as "comprise" , "include" , "incorporate" , "contain" , "is" and "have" are to be construed in a non-exclusive manner when interpreting the description and its associated claims, namely construed to allow for other items or components which are not explicitly defined also to be present. Reference to the singular is also to be construed in be a reference to the plural and vice versa.

While there has been illustrated and described what are presently considered to be the preferred embodiments of the present invention, it will be understood by those skilled in the art that various other modifications may be made, and equivalents may be substituted, without departing from the true scope of the present invention. Additionally, many modifications may be made to adapt a particular situation to the teachings of the present invention without departing from the central inventive concept described herein. Furthermore, an embodiment of the present invention may not include all of the features described above. Therefore, it is intended that the present invention not be limited to the particular embodiments disclosed, but that the invention include all embodiments falling within the scope of the invention as broadly defined above.

A person skilled in the art will readily appreciate that various parameters disclosed in the description may be modified and that various embodiments disclosed and/or claimed may be combined without departing from the scope of the invention.

Claims

A method of assuring end-to-end quality of service for a network service implemented on networking infrastructure comprising network function virtualization (NFV) , the method comprising:

determining a target profile for end-to-end quality of service (QoS) for the network service；

monitoring network function virtualization platform information as it changes；

determining a service chain deployment, comprising virtualised network functions, satisfying said target QoS profile； and

outputting information indicative of the determined service chain deployment to NFV management infrastructure for set-up of the VNFs of said service chain.
A method according to claim 1, wherein:

said network service is implemented on networking infrastructure comprising plural infrastructure networks；

the determining of service chain deployment comprises determining a service chain deployment including VNFs deployed in different infrastructure networks； and

the outputting comprises outputting information indicative of the determined service chain deployment to respective NFV management infrastructure managing VNFs deployed in said respective different infrastructure networks.
A method according to claim 2, wherein the monitoring comprises monitoring each infrastructure network’s location and transmission delay between respective pairs of said infrastructure networks.
A method according to claim 3, wherein the monitoring comprises monitoring the current state of deployment of VNFs including the platform where the VNF is located.
A method according to any of claims 1 to 4 wherein the determining of the service chain deployment is triggered by a request to set up a new service chain.
A method according to any of claims 1 to 4 wherein the determining of the service chain deployment is triggered by a change in the target QoS profile.
A method according to any of claims 1 to 4 wherein the determining of the service chain deployment is triggered by detection that the currently achieved end-to-end QoS ceases to satisfy the target QoS profile.
A system (200) to assure end-to-end quality of service for a network service implemented on networking infrastructure comprising network function virtualization (NFV) , the system comprising:

an NFV end-to-end QoS manager (220) configured to determine a target profile for end-to-end quality of service (QoS) for the network service； and

an NFV-platform information monitoring module (210) configured to monitor network function virtualization platform information as it changes；

wherein the end-to-end QoS manager (220) is configured to determine a service chain deployment, comprising virtualised network functions, satisfying said target QoS profile, and to output information indicative of the determined service chain deployment to NFV management infrastructure for set-up of the VNFs of said service chain.
The end-to-end QoS assurance system according to claim 8, wherein:

said network service is implemented on networking infrastructure comprising plural infrastructure networks； and

the end-to-end QoS manager (220) is configured to determine a service chain deployment including VNFs deployed in different infrastructure networks and to output information indicative of the determined service chain deployment to respective NFV management infrastructu re managing VNFs deployed in said respective different infrastructure networks.
The end-to-end QoS assurance system according to claim 9, wherein the NFV-platform information monitoring module (210) is configured to monitor each infrastructure network’s location and transmission delay between respective pairs of said infrastructure networks.
The end-to-end QoS assurance system according to any of claims 8-10, wherein the end-to-end QoS manager (220) and the NFV-platform information monitoring module (210) are integrated into NFV management infrastructure.
The end-to-end QoS assurance system according to any of claims 8-10, wherein the end-to-end QoS manager (220) and the NFV-platform information monitoring module (210) are separate from the NFV management infrastructure and communicate with the NFV management infrastructure via external interfaces.
The end-to-end QoS assurance system according to any of claims 8-12, wherein the end-to-end QoS manager (220) is responsive to a triggering event to determine said service chain deployment, the triggering event being an event selected in the group consisting of: setting up of a new service chain, occurrence of a QoS alarm, and occurrence of a change in the target QoS profile.
A computer program product comprising computer readable instructions which, when run on a computer system, cause the computer system to perform the method of any of claim 1 to 7.
A computer readable medium comprising the computer program product according to claim 14.