WO2018056873A1

WO2018056873A1 - Virtualised network function manager and method performed thereby for managing a virtual network function

Info

Publication number: WO2018056873A1
Application number: PCT/SE2016/050877
Authority: WO
Inventors: Cormac Hegarty; Andreas LINDQVIST; Magnus Larsson; Tomas Andersson
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2016-09-20
Filing date: 2016-09-20
Publication date: 2018-03-29

Abstract

A Virtualised Network Function Manager, VNFM, (400, 500) and a method (200) performed thereby for managing a Virtual Network Function, VNF, are provided. The method comprises obtaining (210)Performance Management, PM, information ofthe VNF running on a first VM platform on a first physical host, the PM information being associated with one or more applications running on respective one or more Virtual Machines, VMs, of the VNF. The method (200)also comprises putting (220)one or more applicationsrunning on the respectiveone or more VMs of the VNF in quarantine mode based on the obtained PM information; and performing (230)a maintenance task with regard to one or more VMs of the VNF at least based on a policy decision.

Description

VIRTUALISED NETWORK FUNCTION MANAGER AND METHOD PERFORMED THEREBY FOR MANAGING A VIRTUAL NETWORK FUNCTION

Technical field

[0001 ] The present disclosure relates to Virtual Network Functions, VNFs and in particular to management thereof.

Background

[0002] Today's computer environments, physical hosts run a plurality of Virtual Machines, VMs, and VNFs. Generally they are run on a VM platform e.g. a hypervisor platform, which in turn is executed by the physical hosts. To e.g. an application it seems as the VM or the VNF is a separate physical machine. These types of computer environments commonly run or are deployed in what is known as a cloud . The VNFs, the VMs are generally dynamic and may be moved between VM platforms and between different physical hosts. Moving a VNF or VM is also referred to as migrating the VNF or VM, which may in turn serve as an example of a Network Functions Virtualisation Infrastructure, NFVI, management procedure. The cause for, e.g. a NFVI management procedure, may be the need for updating the VM platform of the host or updating an Operation System, OS, of the host.

[0003] When a VM or and VNF is migrated from one physical host to another, it is very likely that the application deployed in the VNF on the VM may experience a grade of service degradation (service availability may be impacted), which may cause unacceptable disruption experienced by users.

Summary

[0004] The object is to obviate at least some of the problems outlined above. In particular, it is an object to provide a Virtualised Network Function Manager, VNFM, and a method performed thereby for managing a VNF, These objects and others may be obtained by providing a VNFM and a method performed by a VNFM according to the independent claims attached below. [0005] According to an aspect, a method performed by a VNFM for managing a VNF is provided. The method comprises obtaining Performance Management, PM, information of the VNF running on a first VM platform on a first physical host, the PM information being associated with one or more applications running on respective one or more Virtual Machines, VMs, of the VNF. The method also comprises putting one or more applications running on the respective one or more VMs of the VNF in quarantine mode based on the obtained PM information; and performing a maintenance task with regard to one or more VMs of the VNF at least based on a policy decision.

[0006] According to an aspect, a VNFM for managing a VNF is provided. The VNFM is configured for obtaining Performance Management, PM, information of the VNF running on a first VM platform on a first physical host, the PM information being associated with one or more applications running on respective one or more Virtual Machines, VMs, of the VNF. The method also comprises putting one or more applications running on the respective one or more VMs of the VNF in quarantine mode based on the obtained PM information; and performing a maintenance task with regard to one or more VMs of the VNF at least based on a policy decision.

[0007] The VNFM and the method performed thereby have several advantages. One possible advantage is that service availability mechanism is improved on VNF level when a maintenance task with regard to the VNF is to be performed, e.g. a maintenance task associated with a Network Functions Virtualisation

Infrastructure, NFVI. Another possible advantage is that maintenance task times may be improved, e.g. NFVI maintenance times. Still a possible advantage is that the solution is applicable to a vast variety of VNFs, cloud or other virtual machine implemented network functions.

Brief description of drawings

[0008] Embodiments will now be described in more detail in relation to the accompanying drawings, in which: [0009] Figure 1 a is an illustration of a cloud environment having two physical hosts, each running a VM platform, wherein VMs are migrated from the first VM platform to the second VM platform.

[00010] Figure 1 b is another illustration of a cloud environment having two physical hosts, each running a VM platform, wherein VMs are migrated from the first VM platform to the second VM platform.

[0001 1 ] Figure 2 is a flowchart of a method performed by a Virtualised Network Function Manager, VNFM, for managing a VNF according to an exemplifying embodiment.

[00012] Figure 3a is an illustration of a cloud environment having two physical hosts, each running a VM platform, wherein VMs are migrated from the first VM platform to the second VM platform in accordance with an exemplifying

embodiment.

[00013] Figure 3b is an illustration of a cloud environment having two physical hosts, each running a VM platform, wherein VMs are migrated from the first VM platform to the second VM platform in accordance with another exemplifying embodiment.

[00014] Figure 3c is a signalling diagram illustrating the solution for the VNFM to manage a VNF according to an exemplifying embodiment.

[00015] Figure 3d is a signalling diagram illustrating the solution for the VNFM to manage a VNF according to another exemplifying embodiment.

[00016] Figure 4 is a block diagram of a VNFM for managing a VNF according to an exemplifying embodiment.

[00017] Figure 5 is a block diagram of a VNFM for managing a VNF according to another exemplifying embodiment.

[00018] Figure 6 is a block diagram of an arrangement in a VNFM for managing a VNF according to an exemplifying embodiment. Detailed description

[00019] Briefly described, a "quarantine/lock" mechanism in the VNF (per application running on respective VM) because of NFVI management procedures (e.g. they are to be scheduled/ongoing) is introduced. This may ensure that service availability is not impacted in the affected VNFs during the course of the NFVI management procedures (e.g. live migration). When the VNF(or specific application running on respective VM in the VNF) is in state "quarantine/lock" it shall not serve new service session attempts. This in turn enables the NFVI management procedures to complete in a timelier fashion thus reducing the potential interruption times experienced by the VNF.

[00020] These policy decisions may be based on specific Key Performance Indicators, KPI, produced by the VNF (e.g. memory utilisation, messaging queue size, current latency load, number of served sessions etc.). Obtaining and factoring in these parameters may ensure more efficient NFVI management procedures. An example of this optimised policy decision is in the area of live migration whereby the VNFM (based on service continuity KPI information from the relevant VNF) may move more than 1 VM / virtualised compute resource at a time safe in the knowledge that service availability of the VNF will not be adversely affected. Generally, one application runs on one respective VM. Generally in this disclosure, an application in quarantine mode corresponds to the VM being in quarantine mode. Hence a VM being in quarantine mode means that the application running on the VM is in quarantine mode.

[00021 ] Furthermore, this disclosure proposes a dynamic policy decision mechanism (that may be automated) that may be used by the VNFM when deciding on when to set VNF/application running on VM in "quarantine / lock" and whether to initiate management procedures (and the granularity thereof) pertaining to the NFVI.

[00022] Some hypervisor (being an example of a VM platform) providers and European Telecommunications Standards Institute, ETSI, Network Function Virtualisation, NFV, define the concept of live migration as a management tool/aid in the NFVI space. It is designed to allow administrators to move running workloads to other hosts ensuring service continuity. In current cloud deployments it is often used when a host needs to be brought offline for maintenance. Once the host is back online, the workloads may be migrated back to the host. See figure 1a

[00023] However, there is no standardised description of how the service continuity shall be guaranteed in the impacted VNFs whilst these procedures are ongoing.

[00024] VNFs particularly in the IP Multimedia Subsystem, IMS, domain are performance critical and are sensitive to latency/delays. Many of these

performance critical VNFs experience disturbance/interruption whilst NFVI management procedures (e.g. live migration) are ongoing. Furthermore, as these performance critical VNFs may serve a large number of sessions (with many potential session data changes) this increased the complexity (and resulting time taken) of the NFVI management procedures. All of the aforementioned negatively influences service continuity. To alleviate the aforementioned problems many hypervisors vendors recommend migrating one VM at a time. This increases the time needed for NFVI maintenance.

[00025] A possible solution to the problems and drawbacks mentioned above is illustrated in figure 1 b. Figure 1 b illustrates VNFM using a Vi-Vnfm

interface/protocol to send " MigrateComputeRequesf to the VIM with parameter "computeld" (identifier of the virtualised compute resource to migrate-cardinality of 1 ) & "migrationType" set to LIVE_MIGRATION or OFFLINE_MIGRATION. When the operation is complete the VIM returns " MigrateComputeResponse" with information on the new compute host. See also European Telecommunications Standards Institute, ETSI, Network Function Virtualisation, NFV.

[00026] However, no mechanisms are described in prior art that the VNF may avail of to minimise currently experienced disturbance/interruption whilst the migration is ongoing in NFVI. No information is currently exposed on a reference point Ve-Vnfm indicating for example that NFVI management procedures are scheduled/ongoing.

[00027] Furthermore the currently defined reference point (in the ETSI NFV) Vi- Vnfm allows only 1 VM/virtualised compute resource to be moved at a time increasing total NFVI maintenance time and potentially impacting the service availability of the VNF (e.g. live migration initiated on compute resource that is experiencing high load in the VNF will increase the time taken for the live migration procedure to complete which in turn will impact the interruption time experienced by the VNF).

[00028] This disclosure discloses a method and apparatus for optimising NFVI management procedures whilst also proposing a procedure that ensures service continuity of the service layer, e.g. VNFs.

[00029] Embodiments herein relate to a method performed by a Virtualised Network Function Manager, VNFM, for managing a Virtual Network Function, VNF. Embodiments of such a method will now be described with reference to figure 2.

[00030] Figure 2 illustrates the method 200 comprising obtaining 210

Performance Management, PM, information of the VNF running on a first VM platform on a first physical host, the PM information being associated with one or more applications running on respective one or more Virtual Machines, VMs, of the VNF. The method 200 also comprises putting 220 one or more applications running on the respective one or more VMs of the VNF in quarantine mode based on the obtained PM information; and performing 230 a maintenance task with regard to one or more VMs of the VNF at least based on a policy decision.

[00031 ] When the VNFM wants to perform a maintenance task of some sort with regard to one or more VMs of the VNF, the VNFM may first need information pertaining to performance management, i.e. PM information. Below are given some examples of what PM information may be, but shortly PM information may indicate how busy or loaded one or more applications running on the respective one or more VMs are, i.e. how busy or loaded the respective application(s) running on the one or more VMs are. In case a VM (application(s) running on the VM) is very loaded or very busy, e.g. supporting a relatively large number of sessions, the more critical it may be to leave the VM alone in order for the application running on the VM not to be disrupted and risk losing sessions. A session that is lost may cause irritation of the customer or subscriber so it is desirable to not lose any sessions or as few as possible from an operator point of view.

[00032] The first physical host may run a first VM platform. The VM platform enables a plurality of VMs to be run on the VM platform and consequently on the first physical host. An example of a VM platform is a hypervisor.

[00033] Consequently, when the VNFM wants to perform a maintenance task of some sort with regard to one or more VMs of the VNF, the VNFM obtains PM information of the VNF running on the first VM platform on the first physical host. The PM information is associated with one for more applications running on the respective one or more VMs of the VNF. The VNFM may obtain the PM

information in different ways. For example, the VNFM may query the VNF for the PM information, e.g. by sending a request therefore and receive a response comprising the requested/queried information.

[00034] Once the VNFM has obtained the PM information, the VNFM is informed e.g. about how busy or loaded the one or more applications running on the respective one or more VMs are. The VNFM may determine if it is a good idea to initiate or perform the maintenance task with regard to one or more VMs of the VNF. Merely as a simplified and illustrative example, assume that the maintenance task may be performed when the load or current usage ratio is 10% of maximum capacity. Assume further that the PM information indicates that the load or current usage ratio of an application running on a respective VM is 20%. The VNFM may then decide to put the application in quarantine mode, wherein the VNFM may wait until the load or current usage ratio drops to 10%. Alternatively in this simplified and illustrative example, if the PM information indicates that the load or current usage ratio of the application is 55%, the VNFM may decide to leave that VM alone. In other words, the VNFM may put one or more applications running on respective VMs of the VNF in quarantine mode based on the obtained PM information.

[00035] Once the one or more applications running on the respective one or more VMs are in quarantine mode, the VNFM may perform a maintenance task with regard to one or more VMs of the VNF at least based on the policy decision.

[00036] Reverting to the simplified and illustrative example above, the policy decision may be that it is considered ok to lose the sessions constituting the 10% load or current usage ratio of the application/VM, wherein the VNFM may wait until the load or current usage ratio drops to 10% and then perform the maintenance task.

[00037] It shall be pointed out that the example above is non-limiting and is to serve as an illustrative example only. Another non-limiting and illustrative example is that the policy decision is based on the type of session that the one or more applications are handling or supporting. In such a scenario, the policy decision may comprise allowing a file transfer session to be dropped due to the

maintenance task, wherein the maintenance task is postponed until the application is no longer supporting or serving any real-time ongoing telephone or video call.

[00038] The method performed by the VNFM has several possible advantages. One possible advantage is that service availability mechanism is improved on VNF level when a maintenance task with regard to the VNF is to be performed, e.g. a maintenance task associated with a Network Functions Virtualisation

[00039] The maintenance task may comprise migrating one or more VMs of the VNF from the first VM platform on the first physical host to a second VM platform on a second physical host. [00040] There are different examples of maintenance tasks. For example, migrating the one or more VMs of the VNF from the first VM platform on the first physical host to a second VM platform on a second physical host. This is also an example of NFVI maintenance.

[00041 ] When a VM is to be migrated from the first VM platform on the first physical host to a second VM platform on a second physical host, the application running on the VM is likely to lose all sessions it is currently supporting or running at the time of the migration. Consequently, the above mentioned policy decision may take into account e.g. losing as few time critical sessions as possible. Thus, the VNFM may e.g. look at the load or usage ratio of the one or more applications running on the respective one or more VMs of the VNF and/or the type of session that the one or more applications running on the respective one or more VMs of the VNF currently is serving or supporting. When one or more conditions associated with the policy is/are fulfilled, the VNFM may take the decision to migrate the one or more VMs of the VNF from the first VM platform on the first physical host to a second VM platform on a second physical host. In this manner, the VNFM may take a conscience decision to possible lose one or more sessions of one or more different types and still migrate the one or more VMs as described above.

[00042] The quarantine mode may comprise the application being in quarantine mode declining any incoming requests, invitations, registrations and only continuing to serve sessions that are ongoing at the time the application is put in quarantine mode.

[00043] When the application is in quarantine mode, the application may still continue to serve those session it had ongoing when it was put in quarantine mode. Since sessions normally have a limited duration in time, the application will have less and less sessions ongoing as time goes by from the time when the application is put in quarantine mode. Any incoming requests, inquires or the like may be refused by the application being in quarantine mode. [00044] Consequently, when the VNFM obtains the PM information associated with one or more applications running on the respective one or more VMs of the VNF, the VNFM may first put one or more of the one or more applications running on the respective one or more VMs of the VNF in quarantine mode. The decision whether or not to put an application in quarantine mode is explained above, but simply put the VNFM may put an application in quarantine mode when it determines that e.g. the load or usage ratio of the application is sufficiently close to a threshold for the VM being eligible for being subjected to the maintenance task. Since sessions normally have a limited duration in time, the VNFM may wait for a while after having put the application in quarantine mode until e.g. the load or usage ratio of the application is low enough to meet with one or more criteria of the above mentioned policy function so that the VNFM may perform the maintenance task on the VM.

[00045] An application may be put in quarantine mode when one or more performance indicators comprised in the obtained PM information meets a respective performance indicator quarantine threshold.

[00046] In order to determine whether or not to put any application in quarantine mode, the VNFM may compare the obtained PM information to one or more performance indicator quarantine thresholds. Merely as a non-limiting and illustrative example, the VNFM may compare the obtained PM information of an application to a load or usage ratio threshold, to a number of ongoing file transfers threshold, and/or to a number of ongoing real-time telephone or video calls threshold etc., the different thresholds being examples of a performance indicator quarantine threshold

[00047] Depending on whether the obtained PM information for an application meets one, some or all of the possible performance indicator quarantine

thresholds (note there might also be only one threshold per application), the VNFM may determine to put that application in quarantine mode. [00048] The performance indicator(s) may be one or more of (a) VNF or VM memory utilisation, (b) VNF or VM messaging queue size, (c) VNF or VM current latency load, (d) number of served sessions of VNF or VM.

[00049] The performance indicator(s) provides information about how suitable an application is for being either put in quarantine mode or for the VM on which it runs being subjected to the maintenance task. The different examples above may all reflect how "busy" the application or VNF is. It shall be pointed out that the VNF may comprise one or more VMs and one, more or even all VMs of the VNF may be eligible to be subjected to the maintenance task. In case all VMs of the VNF are eligible to be subjected to the maintenance task, then the whole VNF is eligible to be subjected to the maintenance task. Merely as an example, in case the maintenance task comprises migration from the first VM platform on the first physical host to a second VM platform on a second physical host, then the whole VNF may be migrated at once in case all VMs are eligible for being migrated.

[00050] Generally, VNF or VM memory utilisation is/are reflective of the VNF or the VM/application respectively supporting a large or small number of sessions, thereby being relatively busy or not. Similarly, the queue size is also reflective of the VNF or the VM/application respectively supporting a large or small number of sessions, thereby being relatively busy or not. The same can be said for VNF or VM current latency load; and number of served sessions of VNF or

VM/application. Consequently, there may be a plurality of different performance indicators comprised in the obtained PM information that may be used by the VNFM in order to determine whether or not to put the one or more applications running on the respective one or more VMs (or possible the whole VNF) in quarantine mode.

[00051 ] In an example, a VM of the VNF is migrated to the second VM platform on the second physical host when one or more performance indicators comprised in the obtained PM information meets a respective performance indicator migration threshold; or after a predetermined time after the applications running on the respective one or more VMs of the VNF was put in quarantine mode. [00052] When the VNFM puts the one or more applications in quarantine mode, the one or more VMs are not yet quite eligible for being subjected to the

maintenance task, e.g. being migrated from the first VM platform on the first physical host to a second VM platform on a second physical host. However, the performance indicator(s) indicate(s) that the one or more applications are close to fulfil the requirements (defined by the above described policy) for the respective one or more VMs being subjected to said migration. The VNFM may monitor the one or more applications, e.g. one or more performance indicators of the applications in quarantine mode. As the sessions served or supported by the one or more applications are ending as time goes by, at a point in time the one or more VMs become eligible for the migration from the first VM platform on the first physical host to a second VM platform on a second physical host.

[00053] The VNFM may compare one or more performance indicators to one or more respective performance indicator migration threshold in a similar manner as described above when deciding whether or not to put the one or more applications in quarantine mode and comparing one or more performance indicators comprised in the obtained PM information to one or more performance indicator quarantine thresholds.

[00054] The VNFM may interact with the VNF via an Element Manager, EM.

[00055] The VNFM may communicate directly with the VNF and/or the VMs. Alternatively, the VNFM may communicate with the VNF and/or the VMs via the EM. The VNFM may use e.g. Ve-Vnfm, for communicating with the VNF and/or the VMs, directly or via the EM.

[00056] The EM may have different functions. For example, it may act as a proxy for the VNFM. Consequently, the EM may perform the same tasks as the VNFM, set application in quarantine, obtain performance information, report performance information to VNFM etc.

[00057] Figure 3a is an illustration of two physical hosts, host 1 and host 2 having reference numerals 310 and 320. Each physical host 310, 320 runs a respective VM platform 315, 325. An example of a VM platform is a hypervisor. Figure 3a illustrates how a VNF 370 comprising three VMs VM1 , VM2 and VM3 also denoted 331 , 332 and 333 is migrated from VM platform 1 also denoted 315 on the first host 310 to VM platform 2 also denoted 325 on the second host.

[00058] Figure 3b is an illustration of the same elements, however with an additional EM 380, which is an alternative implementation.

[00059] Both figure 3a and 3b disclose the VNFM querying the VNF (e.g. via an updated Ve-Vnfm reference point) for "performance management / Key

Performance Indicator" information from the VNF (e.g. memory utilisation, messaging queue size, current latency load, number of served sessions etc.). Based on this information the VNFM may take a dynamic policy decision to "quarantine / lock" a number of applications running on respective VMs in the affected VNF, i.e. put it/them in quarantine mode. After "quarantine / lock" completion the VNFM may, e.g. based on the aforementioned policy decision, initiate a more granular management procedure in NFVI e.g. via the (possibly updated) Vi-Vnfm interface. As these decisions may be dynamic and the VNF is in quarantine the NFVI management procedures may complete in a timelier fashion thus decreasing the risk of service disturbance.

[00060] Figures 3c and 3d are signalling diagrams of two exemplifying embodiments. At a point in time, the VNFM determines that a management procedure is to be performed. For example, the VNFM may determine that a VM platform needs to be updated on the host on which a VNF is executing. The VNFM may receive a command triggered by an operator command.

[00061 ] Prior to initiating maintenance procedures on the NFVI the VNFM may query the VNF directly (fig. 3c) or via the EM (fig. 3d) to obtain VNF specific performance information like for example VNF memory utilisation, VNF messaging queue size, current latency load, number of served sessions etc.

[00062] In an embodiment, the Ve-Vnfm reference point is changed to query the VNF for PM information. For example, the "Query PM Job operation" could be changed to be bi-directional whereby it may also be possible for the VNFM to solicit performance information from the EM (or directly from the VNF) based on predefined performance jobs.

[00063] Based on received PM information the VNFM may take a dynamic policy decision to "quarantine / lock" a number of applications running on respective VMs in the affected VNF. Decision on which applications to quarantine / lock may be for example based on current load of applications, number of sessions being currently served by applications, number of current initial attempts etc.

[00064] VNFM may issue a quarantine/lock order with requested number of VMs on which applications of the VNF are running to be locked. The Ve-Vnfm reference point may be updated to support this procedure.

[00065] The VNF may set, or put, the requested number of applications in "Quarantine/lock" state. These applications will continue to serve existing/ongoing sessions, however will gracefully refuse new initial session (e.g. SIP

registration/Invite) requests.

[00066] Based on the aforementioned queried information and policy decision, the VNFM may request NFVI management procedures to be initiated and the granularity thereof. Because the policy information is dynamic, an optimised grouping of VMs (i.e. more than one) may be subject to management procedures (in the given example live migration for VM1 -VM3). In this manner, more than one VM may be migrated at a time, making the migration more efficient and quicker.

[00067] The existing operation on Vi-Vnfm, " MigrateComputeRequesf may be initiated to the VIM with parameter "computeld" (identifier of the virtualised compute resource to migrate) & "migrationType" set to LIVE_MIGRATION or OFFLINE_MIGRATION. The parameter "computeld may be updated to support cardinality of more than 1 (i.e. 1 ..N).

[00068] Embodiments herein also relate to a VNFM for managing a VNF. The VNFM has the same technical features, objects and advantages as the method performed by the VNFM described above. The VNFM will therefore be described only in brief in order to avoid unnecessary repetition. The VNFM will be described with reference to figures 4 and 5.

[00069] Figure 4 illustrates the VNFM 400, 500 being configured for obtaining PM information of the VNF running on a first VM platform on a first physical host, the PM information being associated with one or more applications running on respective one or more VMs of the VNF. The VNFM 400, 500 is further configured for putting one or more applications running on the respective one or more VMs of the VNF in quarantine mode based on the obtained PM information; and

performing a maintenance task with regard to one or more VMs of the VNF at least based on a policy decision.

[00070] The VNFM 400, 500 may be realised or implemented in different ways. A first exemplifying implementation or realisation is illustrated in figure 4. Figure 4 illustrates the VNFM 400 comprising a processor 421 and memory 422, the memory comprising instructions, e.g. by means of a computer program 423, which when executed by the processor 421 causes the VNFM 400 to obtain PM information from the VNF running on a first VM platform on a first physical host, the PM information being associated with one or more applications running on respective one or more VMs of the VNF; and to put one or more applications running on the respective one or more VMs of the VNF in quarantine mode based on the obtained PM information. The memory further comprises instructions, which when executed by the processor 421 causes the VNFM 400 to perform a maintenance task with regard to one or more VMs of the VNF at least based on a policy decision.

[00071 ] Figure 4 also illustrates the VNFM 400 comprising a memory 410. It shall be pointed out that figure 4 is merely an exemplifying illustration and memory 410 may be optional, be a part of the memory 422 or be a further memory of the VNFM 400. The memory may for example comprise information relating to the VNFM 400, to statistics of operation of the VNFM 400, just to give a couple of illustrating examples. Figure 4 further illustrates the VNFM 400 comprising processing means 420, which comprises the memory 422 and the processor 421 . Still further, figure 4 illustrates the VNFM 400 comprising a communication unit 430. The communication unit 430 may comprise an interface through which the VNFM 400 communicates with other nodes or entities of the physical hosts or entities running on respective VM platforms as well as other communication units, e.g. an Element Manager, EM. Figure 4 also illustrates the VNFM 400 comprising further functionality 440. The further functionality 440 may comprise hardware or software necessary for the VNFM 400 to perform different tasks that are not disclosed herein.

[00072] An alternative exemplifying implementation of the VNFM 400, 500 is illustrated in figure 5. Figure 5 illustrates the VNFM 500 comprising an obtaining unit 503 for obtaining PM information from the VNF running on a first VM platform on a first physical host, the PM information being associated with one or more applications running on respective one or more VMs of the VNF; and a mode putting unit 504 for putting one or more applications running on the respective one or more VMs of the VNF in quarantine mode based on the obtained PM

information. The VNFM 500 further comprises a performing unit 505 for performing a maintenance task with regard to one or more VMs of the VNF at least based on a policy decision.

[00073] In figure 5, the VNFM 500 is also illustrated comprising a

communication unit 501 . Through this unit, the VNFM 500 is adapted to

communicate with other nodes and/or entities in the physical hosts or entities running on respective VM platforms or associated therewith, or e.g. an EM. The VNFM 500 is further illustrated comprising a memory 502 for storing data. Further, the VNFM 500 may comprise a control or processing unit (not shown) which in turn is connected to the different units 503-505. It shall be pointed out that this is merely an illustrative example and the VNFM 500 may comprise more, less or other units or modules which execute the functions of the VNFM 500 in the same manner as the units illustrated in figure 5.

[00074] It should be noted that figure 5 merely illustrates various functional units in the VNFM 500 in a logical sense. The functions in practice may be implemented using any suitable software and hardware means/circuits etc. Thus, the embodiments are generally not limited to the shown structures of the VNFM 500 and the functional units. Hence, the previously described exemplary embodiments may be realised in many ways. For example, one embodiment includes a computer-readable medium having instructions stored thereon that are executable by the control or processing unit for executing the method actions or steps in the VNFM 500. The instructions executable by the computing system and stored on the computer-readable medium perform the method actions or steps of the VNFM 500 as set forth in the claims.

[00075] The VNFM has the same possible advantages as the method performed by the VNFM. One possible advantage is that service availability mechanism is improved on VNF level when a maintenance task with regard to the VNF is to be performed, e.g. a maintenance task associated with a Network Functions

Virtualisation Infrastructure, NFVI. Another possible advantage is that

maintenance task times may be improved, e.g. NFVI maintenance times. Still a possible advantage is that the solution is applicable to a vast variety of VNFs, cloud or other virtual machine implemented network functions.

[00076] According to an embodiment, the VNFM is configured for performing the maintenance task by migrating one or more VMs of the VNF from the first VM platform on the first physical host to a second VM platform on a second physical host.

[00077] According to yet an embodiment, the quarantine mode comprises the application being in quarantine mode declining any incoming requests, invitations, registrations and only continuing to serve sessions that are ongoing at the time the application is put in quarantine mode.

[00078] According to still an embodiment, an application is put in quarantine mode when one or more performance indicators comprised in the obtained PM information meets a respective performance indicator quarantine threshold.

[00079] According to another embodiment, the performance indicator(s) may be one or more of (a) VNF or VM memory utilisation, (b) VNF or VM messaging queue size, (c) VNF or VM current latency load, (d) number of served sessions of VNF or VM.

[00080] According to a further embodiment, a VM of the VNF is migrated to the second VM platform on the second physical host when one or more performance indicators comprised in the obtained PM information meets a respective

performance indicator migration threshold; or after a predetermined time after the applications running on the respective one or more VMs of the VNF was put in quarantine mode.

[00081 ] According to an embodiment, the VNFM interacts with the VNF via an EM.

[00082] Figure 6 schematically shows an embodiment of an arrangement 600 in a VNFM 500. Comprised in the arrangement 600 in the VNFM 500 are here a processing unit 606, e.g. with a Digital Signal Processor, DSP. The processing unit 606 may be a single unit or a plurality of units to perform different actions of procedures described herein. The arrangement 600 of the VNFM 500 may also comprise an input unit 602 for receiving signals from other entities, and an output unit 604 for providing signal(s) to other entities. The input unit and the output unit may be arranged as an integrated entity or as illustrated in the example of figure 5, as one or more interfaces 501 .

[00083] Furthermore, the arrangement 600 in the VNFM 500 comprises at least one computer program product 608 in the form of a non-volatile memory, e.g. an Electrically Erasable Programmable Read-Only Memory, EEPROM, a flash memory and a hard drive. The computer program product 608 comprises a computer program 610, which comprises code means, which when executed in the processing unit 606 in the arrangement 600 in the VNFM 500 causes the VNFM to perform the actions e.g. of the procedure described earlier in conjunction with figure 2.

[00084] The computer program 610 may be configured as a computer program code structured in computer program modules 610a-610e. Hence, in an exemplifying embodiment, the code means in the computer program of the arrangement 600 in the VNFM 500 comprises an obtaining unit, or module, for obtaining PM information from the VNF running on a first VM platform on a first physical host, the PM information being associated with one or more applications running on respective one or more VMs of the VNF,; and a mode putting unit, or module, for putting one or more applications running on the respective one or more VMs of the VNF in quarantine mode based on the obtained PM information. The code means in the computer program of the arrangement 600 in the VNFM 500 further comprises a performing unit, or module, for performing a maintenance task with regard to one or more VMs of the VNF at least based on a policy decision.

[00085] The computer program modules could essentially perform the actions of the flow illustrated in figure 2, to emulate the VNFM 500. In other words, when the different computer program modules are executed in the processing unit 606, they may correspond to the units 503-505 of figure 5.

[00086] Although the code means in the embodiments disclosed above in conjunction with figure 5, is implemented as computer program modules which when executed in the respective processing unit causes the VNFM to perform the actions described above in the conjunction with figures mentioned above, at least one of the code means may in alternative embodiments be implemented at least partly as hardware circuits.

[00087] The processor may be a single Central Processing Unit, CPU, but could also comprise two or more processing units. For example, the processor may include general purpose microprocessors; instruction set processors and/or related chips sets and/or special purpose microprocessors such as Application Specific Integrated Circuits, ASICs. The processor may also comprise board memory for caching purposes. The computer program may be carried by a computer program product connected to the processor. The computer program product may comprise a computer readable medium on which the computer program is stored. For example, the computer program product may be a flash memory, a Random-Access Memory RAM, Read-Only Memory, ROM, or an EEPROM, and the computer program modules described above could in alternative embodiments be distributed on different computer program products in the form of memories within the VNFM.

[00088] It is to be understood that the choice of interacting units, as well as the naming of the units within this disclosure are only for exemplifying purpose, and nodes suitable to execute any of the methods described above may be configured in a plurality of alternative ways in order to be able to execute the suggested procedure actions.

[00089] It should also be noted that the units described in this disclosure are to be regarded as logical entities and not with necessity as separate physical entities.

[00090] While the embodiments have been described in terms of several embodiments, it is contemplated that alternatives, modifications, permutations and equivalents thereof will become apparent upon reading of the specifications and study of the drawings. It is therefore intended that the following appended claims include such alternatives, modifications, permutations and equivalents as fall within the scope of the embodiments and defined by the pending claims.

Claims

1 . A method (200) performed by a Virtualised Network Function Manager, VNFM, for managing a Virtual Network Function, VNF, the method comprising:

- obtaining (210) Performance Management, PM, information of the VNF running on a first VM platform on a first physical host, the PM information being associated with one or more applications running on respective one or more Virtual Machines, VMs, of the VNF,

- putting (220) one or more applications running on the respective one or more VMs of the VNF in quarantine mode based on the obtained PM information,

- performing (230) a maintenance task with regard to one or more VMs of the VNF at least based on a policy decision.

2. The method (200) according to claim 1 , wherein the maintenance task comprises migrating one or more VMs of the VNF from the first VM platform on the first physical host to a second VM platform on a second physical host.

3. The method (200) according to claims 1 or 2, wherein the quarantine mode comprises the application being in quarantine mode declining any incoming requests, invitations, registrations and only continuing to serve sessions that are ongoing at the time the application is put in quarantine mode.

4. The method (200) according to any of claims 1 -3, wherein an application is put in quarantine mode when one or more performance indicators comprised in the obtained PM information meets a respective performance indicator quarantine threshold.

5. The method (200) according to claim 4, wherein the performance indicator(s) may be one or more of (a) VNF or VM memory utilisation, (b) VNF or VM messaging queue size, (c) VNF or VM current latency load, (d) number of served sessions of VNF or VM.

6. The method (200) according to any of claims 2-5, wherein a VM of the VNF is migrated to the second VM platform on the second physical host when one or more performance indicators comprised in the obtained PM information meets a respective performance indicator migration threshold; or after a predetermined time after the applications running on the respective one or more VMs of the VNF was put in quarantine mode.

7. The method (200) according to any of claims 1 -6, wherein the VNFM interacts with the VNF via an Element Manager, EM.

8. A Virtualised Network Function Manager, VNFM, (400, 500) for managing a Virtual Network Function, VNF, the VNFM being configured for:

- obtaining Performance Management, PM, information of the VNF running on a first VM platform on a first physical host, the PM information being associated with one or more applications running on respective one or more Virtual Machines, VMs, of the VNF,

- putting one or more applications running on the respective one or more VMs of the VNF in quarantine mode based on the obtained PM information,

- performing a maintenance task with regard to one or more VMs of the VNF at least based on a policy decision.

9. The VNFM (400, 500) according to claim 8, the VNFM being configured for performing the maintenance task by migrating one or more VMs of the VNF from the first VM platform on the first physical host to a second VM platform on a second physical host.

10. The VNFM (400, 500) according to claims 8 or 9, wherein the quarantine mode comprises the application being in quarantine mode declining any incoming requests, invitations, registrations and only continuing to serve sessions that are ongoing at the time the application is put in quarantine mode.

1 1 . The VNFM (400, 500) according to any of claims 8-10, wherein an application is put in quarantine mode when one or more performance indicators comprised in the obtained PM information meets a respective performance indicator quarantine threshold.

12. The VNFM (400, 500) according to claim 1 1 , wherein the performance indicator(s) may be one or more of (a) VNF or VM memory utilisation, (b) VNF or VM messaging queue size, (c) VNF or VM current latency load, (d) number of served sessions of VNF or VM.

13. The VNFM (400, 500) according to any of claims 9-12, wherein a VM of the VNF is migrated to the second VM platform on the second physical host when one or more performance indicators comprised in the obtained PM information meets a respective performance indicator migration threshold; or after a

predetermined time after the applications running on the respective one or more VMs of the VNF was put in quarantine mode.

14. The VNFM (400, 500) according to any of claims 8-13, wherein the VNFM interacts with the VNF via an Element Manager, EM.

15. A Computer program (610), comprising computer readable code means, which when run in a processing unit (606) comprised in an arrangement (600) in a Virtualised Network Function Manager, VNFM, (500) according to claims 8-14 causes the VNFM (500) to perform the corresponding method according to any of claims 1 -7.

16. A Computer program product (608) comprising the computer program (610) according to claim 15.