WO2017035777A1

WO2017035777A1 - Method and apparatus for orchestrating service provisioning

Info

Publication number: WO2017035777A1
Application number: PCT/CN2015/088736
Authority: WO
Inventors: Shunliang Zhang; Zhiping Lei
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2015-09-01
Filing date: 2015-09-01
Publication date: 2017-03-09
Also published as: CN107925649A

Abstract

A method, apparatus and computer program product for orchestrating service provisioning are disclosed. Particularly, the method for orchestrating service provisioning is performed at a network element in a core network. The method comprises obtaining service provisioning information related to at least one service to be applied to user traffic (510). The service provisioning information at least comprises information on a location of at least one service enabler for provisioning the at least one service. Particularly, for each of the at least one service enabler, the information on the location of that service enabler comprises any of the following: an identifier of a virtual machine hosting that service enabler, an identifier of a physical host hosting that service enabler, an identifier of a data center hosting that service enabler, and a location of the data center. The method also comprises determining, based at least on the service provisioning information, an order in which the at least one service is to be applied to the user traffic in a service provisioning network (520), and then generating a traffic steering policy for steering the user traffic in the service provisioning network (530). The traffic steering policy embodies the determined order in which the at least one service is to be applied.

Description

METHOD AND APPARATUS FOR ORCHESTRATING SERVICE PROVISIONING

TECHNICAL FIELD

The non-limiting and exemplary embodiments of the present disclosure generally relate to the field of communications， and specifically to a method， an apparatus， and a computer program product for orchestrating service provisioning to user traffic.

BACKGROUND

This section introduces aspects that may facilitate better understanding of the present disclosure. Accordingly， the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

With the quick development of various smartphone applications and machine-to-machine (M2M) applications， most mobile operators start to explore a new business model and revenue by providing various value added services (VASs) to subscribers， like security protection， anti-advertisement service， video optimization， Web cache， Hyper Text Transfer Protocol (HTTP) header enrichment， Transmission Control Protocol (TCP) /HTTP optimization. Usually， VAS services are applied to user traffic based on business considerations. It is not necessary that all VAS services are applied to all user traffic. One or more VAS services car be selectively provided to different users at different situations based on operators’ policies and users’ subscriptions. Traditionally， the topology of VAS enablers for providing VAS services is static or even fixed in a service chain. Furthermore， various VAS enablers are usually deployed in a dedicated physical box. Addition/deletion of an enabler or a change in the logic of the service chain may result in a change of the whole network topology， which may somehow cause many issues.

As a solution， the software defined network (SDN) technology emerged to flexibly provide VAS services to user traffic by steering user traffic across different VAS enablers in a scrvice provisioning network， e.g. a Gi/SGi local area network (LAN) .

Meanwhile， inspired by the great success of cloud technology in Information Technology (IT) world， the telecom industry is considering providing cloud-based network services through Network Function Virtualization (NFV) initiated by European Telecommunicatious Standards Iustitute (ETSI) . The NFV technology may make it more flexible and efficient to provide and operate virtual mobile network services， as well as VAS services. It may be expected that various VAS enablers can be deployed with virtual applications in a cloud environment and scale according to dynamic user requirements. The VAS enablers may be deployed in cloud infrastructutes across more than one data center (DC) . In one DC， multiple VAS enablers may be distributed on different physical servers or hosts deployed therein. In addition， a VAS enabler may be migrated from one virtual machine (VM) to another VM in the same physical host， or from one VM in one physical host to another VM in another physical host， which may also be located in another DC. Some VAS enablers are deployed by a network operator， while some others may be deployed by a third party virtual service provider.

The emerging SDN technology and cloud computing has enabled the NFV concept to be widely recognized as a potential approach to provide VAS services to user traffic by steering user traffic across difierent VAS enablers in a flexible way. The SDN makes it possible to steer specific user traffic to required VAS enablers. With the NFV technology， various VAS enablers can be flexibly instantiated or decomposed in a common cloud resource pool (i.e. data center) based on dynamic business requirements. Besides， VAS enabler’s capacity can be flexibly scaled out or scaled in based on a variable size of a user group and/or according to user requirements. In the near future， it is natural that more and more VAS enablers will be deployed and operated in the cloud environment， and flexible VAS provision will be enabled by SDN based service chaining. The NFV and SDN will leverage each other to enable flexible VAS provision in the cloud environment. Therefore， flexible service chaining for dynamic VAS provision should be taken into account the trend that more and more VAS enablers will be deployed and operated in the cloud environment.

In the 3^rd Generation Partnership Project (3GPP) ， a formal work on architecture and potential solutious is under hot discussion in Service and System Aspects Work Group 2 (SA2) . Currently， there are already some proposals on the potential solutions. Most of the existing solutious focus on traffic steering based on traffic characteristics detected by network， e.g. by Traffic Detection Function (TDF) or Deep Packet Inspection (DPI) ， or on intelligence information from Policy and Charging Rules Function (PCRF) ， such as an access network type， a user location， a network load status， etc， for example， as described in U.S patent applications No. 13/859.141 and 13/652,620. The focus is on how to flexibly determine which specific VAS enabler (s) shall be added to or removed from a VAS service chain. But， there is little discussion on how to determine an order of certain VAS services in the VAS service chain.

SUMMARY

Various embodiments of the present disclosure mainly aim at providing a more efficient solution to apply services， particularly VAS services， to user traffic. Other features and advantages of embodiments of the present disclosure will also be understood from the following description of specific embodiments when read in conjunction with the accompanying drawings， which illustrate the principles of embodiments of the present disclosure.

In a first aspect of the present disclosure， there is provided a method for orchestrating service provisioning. The method is performed at a network element in a core network. The method comprises obtaining service provisioning information related to at least one service to be applied to user traffic. The service provisioning information at least comprises information on a location of at least one service enabler for provisioning the at least one service. Particularly， for each of the at least one service enabler， the information on the location of that service enabler comprises any of the following： an identifier of a virtual machine hosting that service enabler， an identifier of a physical host hosting that service enabler， an identifier of a data center hosting that service enabler， and a location of the data center. The method also comprises determining， based at least on the service provisioning information， an order in which the at least one service is to be applied to the user traffic in a service provisioning network， and then generating a traffic steering policy for steering the user traffic in the service provisioning network. The traffic steering policy embodies the determined order in which the at least one service is to be applied. The traffic steering policy may also be referred to as a service steering policy or a service chaining policy. However， it shall be appreciated that the term itself will not constitute a limitation to the present disclosure.

In an embodiment， the service provisioning information may further comprise information on status of the at least one service enabler. Particularly， for each of the at least one service enabler， the information on the status of that service enabler comprises any of the following： instantiation of that service enabler， termination of that service enabler， suspend of that service enabler， resuming of that service enabler， a capacity of that service enabler， and a load of that service enabler.

According to the above embodiments， the traffic steering policy may be generated in consideration of the condition， such as location and/or status of already deployed service enablers， so that the generated traffic steering policy may more efficiently steer user traffic within the service provisioning network， so as to improve resource utilization efficiency and user experience.

In a further embodiment， the method may further comprise providing a requirement for an order of provisioning of a certain service. By this way， the traffic steering policy may be generated in further consideration of the desired order in which services are to be applied to user traffic， so that infrastructure resources may be more efficiently utilized and user experience may be improved accordingly.

In various embodiments， the service provisioning infonnation may be obtained from a business and operation support system or from a network controller in the service provisioning network. By this way， the existing 3 GPP network architecture and NFV frame work as defined by ETSI and the existing interfaces may be reused. From the implementation perspective， the method according to various embodiments of the first aspect would be simple and feasible.

In a second aspect of the disclosure， there is also provided a method for orchestrating service provisioning. The method is performed at a cloud orchestrator in a cloud environment. The method comprises monitoring service provisioning information related to at least one service to be applied to user traffic. The service provisioning information at least comprises information on a location of at least one service enabler for provisioning the at least one service in the service provisioning network. Particularly， for each of the at least one service enabler， the information on the location of that service enabler comprises any of the following： an identifier of a virtual machine hosting that service enabler， an identifier of a physical host hosting that service enabler， an identifier of a data center hosting that service enabler， and a location of the data center. The method also comprises transmitting the service provisioning information for use by a network element in a core network to determine an order in which the at least one service is applied to the user traffic in a service provisioning network.

In another embodiment， the service provisioning information may further comprises information on status of the at least one service enabler. Particularly， for each of the at least one service enabler， the information on the status of that service enabler comprises any of the following： instantiation of that service enabler， termination of that service enabler， suspend of that service enabler， resuming of that service enabler， a capacity of that service enabler， and a load of that service enabler.

In an embodiment， the method may further comprise receiving a requirement for an order of provisioning of a certain service from a business and operation support system or from a network controller in the service provisioning network and then instructing a virtualized infrastructure manager to allocate infrastructure resources for the certain service based at least on the received requirement. By this way， the traffic steering policy may be generated in further consideration of the desired order in which services are to be applied to user traffic so that infrastructure resources may be more efficiently utilized and user experience may be improved accordingly.

In a further embodiment， the service provisioning information may be informed to a business and operation support system， which then forwards the service provisioning information to the network element in the core network. Alternatively， the service provisioning information may be informed to a network controllerin the service provisioning network， which then forwards the service provisioning information to the network element in the core network directly or via an intermediate network function above the service provisioning network. By this way， the existing 3GPP network architecture and NFV frame work as defined by ETSI and the existing interfaces may be reused. From the implementation perspective， the method according to various embodiments of the second aspect would be simple and feasible.

In a third aspect of the disclosure， there is provided an apparatus for orchestrating service provisioning. The apparatus is embodied at or as at least part of at a network element in a core network. Particularly， the apparatus comprises an obtaining unit， a determining unit and a generating unit. The obtaining unit is configured to obtain service provisioning information related to at least one service to be applied to user traffic. The determining unit is configured to determine， based at least on the service provisioning information， an order in which the at least one service is to be applied to the user traffic in a service provisioning network. The generating unit is configured to generate a traffic steering policy for steering the user traffic in the service provisioning network. The service provisioning information at least comprises information on a location of at least one service enabler for provisioning the at least one service. The traffic steering policy embodies the determined order in which the at least one service is to be applied.

In a fourth aspect of the disclosure， there is provided an apparatus for orchestrating service provisioning. The apparatus is embodied at or as at least part of a cloud orchestrator. The apparatus comprises a monitoring unit and an informing unit. The monitoring unit is configured to monitor service provisioning information related to at least one service to be applied to user traffic. The informing unit is configured to transmit the service provisioning information for use by a network element in a core network to determine an order in which the at least one service is applied to the user traffic in a service provisioning network. The service provisioning information at least comprises information on a location of at least one service enabler for provisioning the at least one service in the service provisioning network.

In a fifth aspect of the disclosure， there is provided an apparatus for orchestrating service provisioning. The apparatus comprises a processor and a memory. The memory contains instructions executable by the processor， whereby the apparatus is operative to perform the method according to the first aspect or the second aspect of the present disclosure.

In a sixth aspect of the disclosure， there is provided an apparatus for orchestrating service provisioning. The apparatus comprises processing means adapted to perform the method according to the first aspect or the second aspect of the present disclosure.

In a seventh aspect of the disclosure， there is provided a computer program product， comprising instructions which， when executed on at least one processor， cause the at least one processor to carry out the method according to the first aspect or the second aspect of the present disclosure.

It shall be appreciated that various embodiments of the first aspect may also be equally applied to the third aspect of the present disclosure， while various embodiments of the second aspect may be equally applied to the fourth aspect of the present disclosure.

According to the various aspects and embodiments as mentioned above， an effective and efficient solution or architecture is provided for orchestrating service provisioning via SDN based service chaining. Other features and advantages of embodiments of the present disclosure will become more apparent from the following description with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other aspects， features， and benefits of various embodiments of the present disclosure will become more fully apparent， from the following detailed description with reference to the accompanying drawings， in which：

FIG. 1 illustrates a typical scenario for illustrating a possible problem of traffic steering across VAS enablers deployed within two data centres (DCs) in a cloud environment；

FIG. 2 illustrates another typical scenario for illustrating a possible problem of traffic steering across VAS enablers deployed within a single data centre in a cloud environment；

FIG. 3 illustrates a schematic diagram of network architecture for orchestrating service provisioning in a cloud environment according to an embodiment of the present disclosure；

FIG. 4 illustrates a schematic diagram of another network architecture for orchestrating service provisioning in a cloud environment according to another embodiment of the present disclosure；

FIG. 5 illustrates a flowehart of a method implemented at a network element in the core network as illustrated in FIG. 3 or FIG. 4 for orchestrating service provisioning according to an embodiment of the present disclosure；

FIG. 6 illustrates a flowchart of a method implemented at the cloud orehestrator as illustrated in FIG. 3 or FIG. 4 for orchestrating service provisioning according to an embodiment of the present disclosure；

FIG. 7 illustrates an example message flow among various functions/entities in the cloud environment of FIG. 3：

FIG. 8 illustrates an example message flow among various functions/entities in the cloud environment of FIG. 4：

FIG. 9 illustrates a schematic block diagram of an apparatus adapted for orchestrating service provisioning according to an embodiment of the present disclosure；

FIG. 10 illustrates a schematic block diagram of an apparatus adapted for orchestrating service provisioning according to an embodiment of the present disclosure； and

FIG. 11 illustrates a schematic block diagram of an apparatus for orchestrating service provisioning in a cloud environment according to embodiments of the present disclosure.

In the above drawings， like reference numerals or letters are used to designate like or equivalent elements.

DETAILED DESCRIPTION

Hereinafter， the principle and spirit of the present disclosure will be described with reference to illustrative embodiments. It should be understood， all these embodiments are given merely for one skilled in the art to better understand and further practice the present disclosure， but not for limiting the scope of the present disclosure. For example， features illustrated or described as part of one embodiment may be used with another embodiment to yield still a further embodiment. In the interest of clarity， not all features of an actual implementation are described in this specification.

References in the specification to “an embodiment” ， “another embodiment” ， “a further embodiment” etc. indicate that the embodiment described may include a particular feature， structure， or characteristic， but every embodiment may not necessarily include the particular feature， structure， or characteristic. Moreover， such phrases are not necessarily referring to the same embodiment. Further， when a particular feature， structure， or characteristic is described in connection with an embodiment， it is submitted that it is within the knowledge of one skilled in the art to affect such feature， structure， or characteristic in connection with other embodiments whether or not explicitly described.

It shall be understood that， although the terms “first” and “second” etc. may be used herein to describe various elements， these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example， a first element could be termed a second element， and similarly， a second element could be termed a first element， without departing from the scope of example embodiments. As used herein， the term “and/or” includes any and all combinations of one or more of the associated listed terms.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the embodiments. As used herein， the singular forms “a” ， “an” and “the” are intended to include the plural forms as well， unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” ， “comprising” ， “has” ， “having” ， “includes” and/or “including” ， when used herein， specifythe presence of stated features， elements， and/or components etc.， but do not preclude the presence or addition of one or more otherfeatures， elements， components and/or combinations thereof.

In the following description and claims， unless defined otherwise， all tectnical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs. For example， the services “orchestrated” by a cloud orchestrator are typically VAS services， such as security protection， anti-advertisement service， video optimization， Web cache， HTTP header enrichment， TCP/HTTP optimization etc.， but not limited to VAS services only. The service enablers， e.g. VAS enablers， may also comprise virtualized service instances. The traffic steering policy used in this document may also be referred to as a service steering policy or a service chaining policy. However， it shall be appreciated that the term itself will not constitute a limitation to the present disclosure.

For better understanding of the present disclosure， some possible problems of the existing solutions for service provisioning based on traffic steering will be detailed first. Furthermore， althongh the description is made in the context of VAS provisioning， those skilled in the art shall appreciate that the present disclosure may be more generally applied to provisioning of other services in a cloud environment.

In order to generate an appropriate traffic steering policy for certain user traffic， one important issue is how to determine which VAS (s) should be included in a service chain and another important issue is how to determine an order of the various VASs in the service chain. Currently， most of discussions and solutions are focused on the first issue. The second issue hasn’ t been well addressed. If the order of various VASs in the service chain is not appropriately arranged， then network resources may not be efficiently used. In addition， system performance， e.g. bandwidth， and/or user experience， e.g. atraffic delay， may be negatively impacted.

The above mentioned problem in the existing solution will be better understood with reference to FIG. 1 and FIG. 2.

Particularly， FIG. 1 illustrates a typical scenario for illustrating a possible problem of traffic steering across VAS enablers deployed within two data centres (DCs) in a cloud environment. As illustrated， DC1 comprises a virtual Routing and Forwarding (VRF) function， a virtual storage (vStorage) ， and two VMs hosting two different virtual VAS enablers， vVAS2 and vVAS4， while DC2 comprises a VRF function， a vStorage， and two VMs hosting two different VAS enablers， vVAS1 and vVAS3. Assuming that a control system for traffic steering or service chaining has no knowledge of the actual deployment of VAS enablers in the DCs， it may possibly generate a service chaining policy indicating a service provisioning order as VAS1→VAS2→VAS3→VAS4. Then， the user traffic entering into DC2 first may be steered back and forth across the DCs so as to be provisioned with VAS services by the enablers VAS1-VAS4 that are distributed in the cloud environment. Thus， the traffic swinging between the two DCs may occupy a large transmission bandwidth and may bring a delay to the user traffic， which will result in insufficient use of cloud resources and deteriorated user experience.

FIG. 2 illustrates another typical scenario for illustrating a possible problem of traffic steering across VAS enablers deployed within a single data centre in a cloud environment. As illustrated， data centre DC1 comprises a switch for switching user traffic and a plurality of physical servers/hosts (althongh two are shown) on which two kernel-based virtual machines， KVM1 and KVM2， are running. Above KVM1 are running two virtual VAS enablers， vVAS1 and vVAS3， while above KVM2 are running two other virtual VAS enablers， vVAS2 and vVAS4. Again， assuming that the control system for traffic steering or service chaining has no knowledge of the actual deployment of VAS enablers in the DC， it may possibly generate a service chaining policy indicating a service provisioning order as VAS1→VAS2→VAS3→VAS4. Then， the user traffic entering into DC1 may be steered back and forth across the two physical servers so as to be provisioned with VAS services by the enablers VAS1-VAS4 that are distributed in DC 1. Thus， the traffic swinging between the two physical servers may occupy a large transmission bandwidth and may bring a delay to the user traffic， which will result in insufficient use of cloud resources and deteriorated user experience.

As for other scenarios that user traffic may need to be switched not only between two physical servers in a single DC but also between two difierent DCs， the system performance and user experience may be further deteriorated.

In order to solve at least part of the above problems， a solution for orchestrating service provisioning according to embodiments of the present disclosure will be described with reference to FIGs. 3-11.

FIG. 3 illustrates a schematic diagram of network architecture for orchestrating service provisioning in a cloud environment according to an embodiment of the present disclosure. This architecture is in line with 3GPP network architecture and NFV frame work as defined by ETSI. Thus， the existing infrastructures and existing interfaces between different network elements or network functions may be reused. Further， with this architecture， the implementation of terminal devices of users will not be impacted.

The illustrated embodiment comprises a radio access network (RAN) where user traffic may be originated， a core network (CN) ， and a service provisioning network， such as a SDN based chaining network， e.g. a Gi or SGi service LAN， which are deployed by a network operator. This network operator further provides a business and operation support system， e.g. Operations Support System (OSS) /Business Support System (BSS) . There also exists a cloud orchestrator， which may be responsible for fulfilling resource orchestration functions and fulfilling network service orehestration functions.

The core network may comprise a traffic steering policy generator， e.g. a Policy and Charging Rules Function (PCRF) ， and a Packet Data Network Gateway (PGW) . In order to realize traffic steering in the operator deployed service provisioning network， the network operator uses various parameters， such as those related to subscriber’s session and application traffic， and based on various information， sueh as service provisioning information which will be detailed hereafter， to define traffic steering policies by the PCRF. These policies may be enforced by the PGW to control the steering of user traffic to appropriate service enablers in the service provisioning network. The service provisioning network， which is illustrated as SGi-LAN， may comprise a traffic controller， such as a SDN controller (SDNC) and one or more service enablers， such as VAS enablers for provisioning VAS services. The user traffic， e.g. from User 1， User 2， and User 3， flows through the RAN， the CN and the service provisioning network to be provided with required services.

In the illustrated architecture， the business and operation support system， e.g. OSS/BSS， subscribes from the cloud orchestrator service provisioning information related to at least one service to be applied to the user traffic. The service provisioning information at least comprises information on a location of at least one service enabler for provisioning the at least one service. Particularly， for each of the at least one service enabler， the information on the location of that service enabler (which will be simplified as location information) comprises any of the following： an identifier of a virtual machine hosting that service enabler， an identifier of a physical host hosting that service enabler， an identifier of a data center hosting that service enabler， and a location of the data center. Obviously， an identifier of the at least one service enabler may be implicitly included in the service provisioning information.

Additionally， the service provisioning information may further comprise information on status of the at least one service enabler. Particularly， for each of the at least one service enabler， the information on the status of that service enabler (which will be simplified status information) may comprise any of the following： instantiation of that service enabler， termination of that service enabler， suspend of that service enabler， resuming of that service enabler， a capacity of that service enabler， and a load of that service enabler.

Optionally， the business and operation support system may inform the cloud orchestrator of a specific requirement on an order of provisioning of a certain service， e.g. which position the certain service will be in a service chain， in case that some services in the service chain needs to be applied to the user traffic in a consecutive way. The cloud orchestrator may then instruct a virtualized infrastructure manager in the cloud to schedule or allocate infrastructure resources for the certain service based at least on the specific requirement received from the business and operation support system. For example， the virtualized infrastructute manager may schedule or allocate closely collocated resources to service enablers that will provide services requiring to be provided sequentially according to the received specific requirement. More particularly， the virtualized infrastructure manager may schedule or allocate computing and storage resources to related services from the same physical host if possible； or to schedule or allocate computing and storage resources in different physical hosts of the same DC if there is no enough resource from the same physical host； or to schedule or allocate resources from different physical hosts in different DCs connected with a richer (i.e. with a shorter distance， faster and/or cheaper) physical link if there is no enough resource from the same DC.

The cloud orchestrator monitors the service provisioning information related to the services to be applied to the user traffic and actively informs the business and operation support system of the service provisioning information， e.g. periodically or when any change in the location information and/or the status information occurs.

Triggered by the information informed from the cloud orchestrator， the business and operation support system may forward the service provisioning information to a network element in the core network， i.e. the traffic steering policy generator (e.g. PCRF) ， as input for traffic steering policy generation. As an alternative， the PCRF may actively retrieve the service provisioning information from the business and operation support system to assist the traffic steering policy generation. With the service provisioning information， the traffic steering policy generator can determine and/or update the traffic steering policy. More particularly， it may determine or adjust the order of specific services in a service chain based at least on the location information comprised in the service provisioning information， and may also add or remove a service to or from the service chain based at least on the status information comprised in the service provisioning information.

Particularly， services hosted by a same virtual machine may be deployed consecutively in the service chain. In the case of no common virtual machine， services hosted by a same physical host/server may be deployed consecutively in the service chain. In the case of no common physical host， services hosted by the same DC may be deployed consecutively in the service chain. Besides， the service enablers closer to the PGW may be deployed in the front of the service chain for uplink traffic. For downlink traffic， the service enablers closer to the PGW may be deployed at the end of the service chain.

When the location of the service enabler is changed， for example， previously collocated service enablers (e.g. placed on the same virtual machine， or VMs on the same physical host， or VMs on difierent physical hosts) are dispersed dne to a change in cloud resources， e.g. located in different VMs， or VMs in difietent physical hosts， or in different DCs， the services will not be consecutive in the service chain， the location information comprised in the service provisioning information may be changed accordingly.

As for the status information comprised in the service provisioning information， in the case that a service enabler is instantiated， the service enabler may be added into the service chain when it is needed. In the case that the service enabler is terminated， the service enabler may be removed from the service chain. In the case that a service enabler is out of service， the service enabler may be disabled in the service chain. In the case that a service enabler is resumed to service， the service enabler may be enabled in the service chain. In the case that the service enabler is to be overloaded， the service enabler will not be added to the service chain. In the case that the service enabler is recovered to normal or a light load from overload， the service enabler may be added to the service chain.

Additionally， the order of services in the service chain may also be determined based further on service functionality configuration. For example， VAS 1 is configured as header enrichment function and VAS 2 is configuration encryption function. If both VAS1 and VAS2 are to be included in the service chain， VAS1 may be deployed in front of VAS 2 for uplink traffic， while for downlink traffic； VAS2 may be deployed in front of VAS 1.

Since the generation of the traffic steering policy takes into account of the desired order in which the services are to be applied to user traffic， the cloud resources may be more efficiently utilized and user experience may be improved accordingly. Furthermore， the proposed solution or architecture reuses the existing interface and network infrastructute. Thus the implementation will be simple and feasible sinee only existing interfaces and functions are enhanced.

FIG. 4 illustrates a schematic diagram of network architecture for orchestrating service provisioning in a cloud environment according to another embodiment of the present disclosure.

The embodiment as illustrated in FIG. 4 differs from the embodiment as illustrated in FIG. 3 only in that no OSS/BSS is involved. Instead， a network controller in the service provisioning network， e.g. aSDNC in the SGi-LAN， may play the same role as the OSS/BSS does in the embodiment as illustrated in FIG. 3， in combination with an intermediate network function above the service provisioning network， e.g. a Service Chain Traffic Controller Function (SCTCF) as defined in 3GPP TR 23.718 V1.1.O. The network controller with the intermediate network function may be regarded as a whole entity， in which they are connected via an internal interface. The following description will focus on the difference between FIG. 3 and FIG.4 only for the sake of brevity.

In the illustrated architecture of FIG.4， the network controller， e.g. SDNC subscribes service provisioning information related to at least one service to be applied to the user traffic from the cloud orchestrator.

The cloud orchestrator monitors the service provisioning information of the services to be applied to the user traffic and actively informs the network controller of the service provisioning information， e.g. when any change in the location information and/or the status information.

Optionally， the intermediate network function， e.g. SCTCF， may obtain a specific requirement for an order of provi sioning of a certain service from the network element in the core network. Further， the intermediate network function may forward this specific requirement to the network controller， which may in tum inform the cloud orchestrator of the specific requirement for an order of provisioning of a certain service， e.g. which position the certain service is in a service chain， in case that some services in the service chain needs to be applied to the user traffic in a consecutive way.

On the other hand， upon receiving information from the cloud orchestrator regarding the service provisioning， the network controller may inform the network element in the core network， i.e. the traffic steering policy generator (e.g. PCRF) of the information via the intermediate network function or directly， as input for traffic steering policy generation. As an alternative， the PCRF may actively retrieve the service provisioning information from the network controller via the intermediate network function or directly so as to assist the traffic steering policy generation.

Additionally， upon receiving information from the cloud orchestrator regarding the service provisioning， the network controller may utilize this information to generate/update specific OpenFlow configuration information to steer user traffic across specific service enabler instances in the service provisioning network. For example， the network controller may use the status information and the location information comprised in the service provisioning information to select an appropriate service enabler instance in the case that multiple service enabler instances capable of providing the same VAS service are in operation so as to achieve service load balancing among instances providing the same VAS service.

All other aspects as described with reference to FIG.3 may be equally applicable to the embodiment of FIG. 4， which thus will not be detailed herein for the purpose of brevity.

FIG. 5 illustrates a flowchart of a method 500 implemented at a network element， e.g. PCRF in the core network as illustrated in FIG. 3 or FIG. 4 for orchestrating service provisioning according to an embodiment of the present disclosure.

In FIG. 5， operations in blocks with a solid line are essential while operations in blocks with a broken line are optional depending on various embodiments of the present disclosure. The description will be started from the essential operation in block 510.

As illustrated， the method 500 enters at block 510， in which service provisioning information related to at least one service to be applied to user traffic is obtained at the network element. In an embodiment， the service provisioning information may be obtained from a business and operation support system as illustrated in FIG. 3. In another embodiment， the service provisioning information may be obtained from a network controller in the service provisioning network， e.g. aSDN controller as illustrated in FIG. 4.

The service provisioning information at least comprises information on a location of at least one service enabler for provisioning the at least one service.

As mentioned above， for each of the at least one service enabler， the information on the location of that service enabler comprises any of the following： an identifier of a virtual machine hosting that service enabler， an identifier of a physical host hosting that service enabler， an identifier of a data center hosting that service enabler， and a location of the data center.

In another embodiment， the service provisioning information may further comprise information on status of the at least one service enabler. As mentioned above， for each of the at least one service enabler， the information on the status of that service enabler comprises any of the following： instantiation of that service enabler， termination of that service enabler， suspend of that service enabler， resuming of that service enabler， a capacity of that service enabler， and a load of that service enabler.

Based at least on the service provisioning information， an order in which the at least one service is to be applied to the user traffic in a service provisioning network is determined at block 520.

Then at block 530， a traffic steering policy for steering the user traffic in the service provisioning network i s generated. The generated traffic steering policy embodies the determined order in which the at least one service is to be applied. The traffic steering policy may also be referred to as a service steering policy or a service chaining policy. However， it shall be appreciated that the term itself will not constitute a limitation to the present disclosure.

Optionally， the method 500 may also comprise providing a requirement for an order of provisioning of a certain service at block 505. By this way， the traffic steering policy may be generated in further consideration of the desired order in which services are to be applied to user traffic so that the infrastructure resources may be more efficiently utilized and user experience may be improved accordingly.

FIG. 6 illustrates a flowchart of a method 600 implemented at a clond orchestrator as illustrated in FIG. 3 or FIG. 4 for orchestrating service provisioning according to an embodiment of the present disclosure.

In FIG. 6， operations in blocks with a solid line are essential while operatious in blocks with a broken line are optional depending on various embodiments of the present disclosure. The description will be started fiom the essential operation in block 610.

As illustrated， the method 600 enters at block 6 1 0， in which the clond orchestrator monitors service provisioning information related to at least one service to be applied to user traffic. The service provisioning information at least comprises information on a location of at least one service enabler for provisioning the at least one service in the service provisioning network. Particularly， for each of the at least one service enabler， the information on the location of that service enabler comprises ary of the following： an identifi er of a virtual machine hosting th at service enabler， an identifi er of a physical host hosting that service enabler， an identifi er of a data center hosting that service enabler， and a location of the data center.

In an embodiment， the service provisioning information may further comprise information on status of the at least one service enabler. Particularly， for each of the at least one service enabler， the information onthe status of that service enabler comprises any of the following： instantiation of that service enabler， termination of that service enabler， suspend of that service enabler， resuming of that service enabler， a capacity of that service enabler， and a load of that service enabler.

Then at block 620， the service provisioning information is informed， e.g. periodically or upon a change in that information， for use by a network element in a core network to determine an order in which the at least one service is applied to the user traffic in a service provisioning network.

In an embodiment， the cloud orchestrator may inform a business and operation support system of the service provisioning information. The business and operation support system may then forward the service provisioning information to the network element in the core network.

In another embodiment， the cloud orchestrator may inform a network controller in the service provisioning network of the service provisioning information. The network controller may then forward the service provisioning information to the network element in the core network directly or via an intermediate network function above the service provisioning network.

In a further embodiment， the cloud orchestrator may receive a requirement for an order of provisioning of a certain service from the business and operation support system or from the network controller in the service provisioning network， and instruct a virtualized infrastructure manager to allocate infrastructure resources for the certain service based at least on the received requirement.

FIG. 7 illustrates an example message flow among various functions/entities in the cloud environment of FIG. 3 according to an embodiment of the present disclosure.

The OSS/BSS may first derive a requirement for an order of provisioning of a certain service， which may be translated to a requirement on VAS enabler deployment， based on a VAS service chaining function requirement， when certain VAS services need to be applied to user traffic in a consecutive way or in a certain order， for example.

Further， the OSS/BSS may initiate VAS service provisioning through a message to the cloud orchestrator， e.g. aNetwork Functions Virtualisation Orchestrator (NFVO) as defined in ETSI GS NFV-MAN 001 V1.1.1. Optionally， the message may include the derived requirement for the order of provisioning of the certain service.

Then the cloud orehestrator may instruct a virtualized infrastructure manager (VIM) to allocate cloud resources in appropriate locations based on the requirement for the order of provisioning of the certain service. More specifically， the cloud orchestrator informs the VIM to allocate computing and storage resources for related VAS from the same physical host if possible， or to allocate computing and storage resources in different physical hosts of the same DC if there is no enough resource from the same physical host； or to allocate cloud resources from different physical hosts in different DCs connected with a richer physical link if there is no enough resource from the same DC.

The cloud orchestrator also replies the OSS/BSS with a message to inform ifthe VAS deployment requirement can be fulfilled or not， as well as the cloud resource allocation results， which may form at least part of the service provisioning information that may include location and/or status information for related VAS enablers.

The cloud orchestrator may monitor the service provisioning information and provide the same via a message to the OSS/BSS upon any change in this information or periodically.

Upon receiving the service provisioning information related to VAS services which may be applied to user traffic， the OSS/BSS may identify a specific PCRF that is related with the VAS services and generates/updates PCRF configuration information with the service provisioning information.

The OSS/BSS may also reply the NFVO with a message to confirm that the service provisioning information has been successfully received.

The OSS/t3SS then transmits the generated/updated configuration information to the PCRF by a message， which includes the service provisioning information and associated service identifiers.

Based on the service provisioning information as informed by the OSS/BSS， the PCRF generates/updates a traffic steering policy to be applied to the user traffic.

The PCRF may reply the OSS/BSS with a message to confirm that the configuration info has been successfully received.

Accordingly， the user may select a specific access network， and/or core network interface， and sends a service request to an application server or an application function.

Upon detecting the service request， the PCEF/TDF collocated with the P-GW interacts with the PCRF to get the traffic steering policy as well as a quality of service (QoS) and charging related policy etc.. The PCRF then provides the generated traffic steering policy by a message， and the PCEF/TDF enforces the traffic steering policy as informed by the PCRF.

The service request message is then steered to specific VAS server as indicated in traffic steering policy.

FIG. 8 illustrates an example message flow among various functions/entities in the cloud environment of FIG. 4 according to another embodiment of the present disclosure.

In this embodiment， the intermediate network function SCTCF mayfirst derive from the PCRF a requirement for an order of provisioning of a certain service， which may be translated to a requirement on the VAS enabler deployment， based on a VAS service chaining function requirement when certain VAS services need to be applied to user traffic in a consecutive way or in a certain order， for example.

The network controller SDNC may initiate VAS service provisioning through a message to the cloud orchestrator， e.g. a NFVO as defined in ETSI GS NFV-MAN 001 V1.1.1. Optionally， the message may include the derived requirement for the order of provisioning of the certain service.

Then the cloud orchestrator may instruct VIM to allocate cloud resources in appropriate locations based on the requirement for the order of provisioning of the certain service. More specifically， the clond orchestrator instructs the VIM to allocate computing and storage resources for related VAS from the same physical host if possible， or to allocate computing and storage resources in different physical hosts of the same DC ifthere is no enough resource from the same physical host； or to allocate cloud resources from different physical hosts in different DCs connected with a richer physical link if there is no enough resource from the same DC.

The cloud orchestrator also replies the SDNC with a message to inform if the VAS deployment requirement can be fulfi lled or not， as well as the cloud resource allocation results， which may form at least part of the service provisioning information that includes location and/or status information for related VAS enablers.

The cloud orehestrator may monitor the service provisioning information and provide the same via a message to the SDNC upon any change in this information or periodically.

The SDNC may also reply the NFVo with a message to confirm that the the service provisioning information has been successfully received.

The SDNC transmits the generated/updated configuration information to the PCRF directly or via the intermediate SCTCF by a message， which includes the service provisioning information and associated service identifiers.

Based on the service provisioning information as informed by the SDNC， the PCRF generates/updates a traffic steering policy to be applied to the user traffic.

The PCRF may reply the OSS/BSS with a message to confirm that the configuration info has been successfu lly reeeived.

Then， the user may select a specific access network， and/or core network interface， and sends a service request to an application server or an application function.

Upon detecting the service request， the PCEF collocated with the P-GW interacts with the PCRF to get the traffic steering policy as well as a QoS and charging related policy etc..

The PCRF then provides the generated traffic steering policy by a message to the PCEF/TDF.

The PCEF/TDF enforces the traffic steering policy as informed by the PCRF.

FIG. 9 illustrates a schematic block diagram of an apparatus 900 adapted for orchestrating service provisioning according to an embodiment of the present disclosure. The apparatus 900 may be embodied at or as at least part of a network element in a core network， e.g. PCRF as illustrated in FIG. 3.

In FIG. 9， units in blocks with a solid line are essential while units in blocks with a broken line are optioual depending on various embodiments of the present disclosure.

As illustrated， the apparatus 900 comprises an obtaining unit 910， a determining unit 920， and a generating unit 930. Particularly， the obtaining unit 910 is configured to obtain service provisioning information related to at least one service to be applied to user traffic. The service proyisioning information may at least comprise information on a location of at least one service enabler for provisioning the at least one service. In an embodiment， for each of the at least one service enabler， the information on the location of that service enabler may comprise any of the following： an identifier of a virtual machine hosting that service enabler， an identifier of a physical host hosting that service enabler， an identifier of a data center hosting that service enabler， and a location of the data center.

In another embodiment， the service provisioning information may further comprise information on status of the at least one service enabler. Additionally， for each of the at least one service enabler， the information on the status of that service enabler comprises any of the following： instantiation of that service enabler， termination of that service enabler， suspend of that service enabler， resuming of that service enabler， a capacity of that service enabler， and a load of that service enabler.

The determining unit 920 is configured to determine， based at least on the service provisioning information， an order in which the at least one service is to be applied to the user traffic in a service provisioning network. The generating unit 93 0 is configured to generate a traffic steering policy for steering the user traffic in the service provisioning network. The traffic steering policy embodies the determined order in which the at least one service is to be applied.

In another embodiment， the apparatus 900 may further comprise a providing unit 905 configured to provide a requirement for an order of provisioning of a certain service.

In yet another embodiment， the obtaining unit 910 may be configured to obtain the service provisioning information from a business and operation support system or from a network controller in the service provisioning network.

The above units 905 and 910-930 may be configured to implement corresponding method operatious or steps as described with reference to FIG. 5 and thus will not be detailed herein for the conciseness purpose.

FIG. 10 illustrates a schematic block diagram of an apparatus 1000 adapted for orchestrating service provisioning according to an embodiment of the present disclosure. The apparatus l000 may be embodied at or as at least part of a cloud orchestrator.

In FI G. 10， units in blocks with a solid line are essential while units in blocks with a broken line are optional depending on various embodiments of the present disclosure.

As illustrated， the apparatus 1000 comprises a monitoring unit 1010 and an informing unit 1020. Particularly， the monitoring unit 1 010 is configured to monitor service provisioning information related to at least one service to be applied to user traffic. The service provisioning information at least comprises information on a location of at least one service enabler for provi sioning the at least one service in the service provisioning network.

In an embodiment， fof each of the at least one service enabler， the information on the location of that service enabler comprises any of the following： an identifier of a virtual machine hosting that service enabler， an identifier of a physical host hosting that service enabler， an identifi er of a data center hosting that service enabler， and a location of the data center.

The informing unit 1020 is configured to transmit the service provisioning information for use by a network element in a core network to determine an order in which the at least one service is applied to the user traffic in a service provisioning network.

In another embodiment， the apparatus 1000 may further comprise a receiving unit 1 001 and an instrtcting unit l002. The receiving unit 1 001 is configured to receive a requirement for an order of provisioning of a certain service from a business and operation support system or from a network controller in the service provisioning network. The instru cting unit 1002 is configured to instruct a virtualized infrastructure manager to allocate infrastructure resources for the certain service based at least on the received requirement.

In a further embodiment， the informing unit 1020 may be configured to inform the service provisioning information to a business and operation support system， which may forward the service provisioning information to the network element in the core network； or to inform the service provisioning information to a network controllerin the service provisioning network， which may forward the service provisioning information to the network element in the core network directly or via an intermediate network function above the service provisioning network.

The

above units

1001， 1002， 1010 and 1020 may be configured to implement corresponding method operations or steps as described with reference to FIG. 6 and thus will not be detailed herein for the conciseness purpose.

FIG. 11 illustrates a schematic block diagram of an apparatus 1100 for orchestrating service provisioning in a cloud environnent according to embodiments of the present disclosure. The apparatus 1100 may be embodied at or as at least part of a network element in a core network. Alternatively， the apparatus 1100 may be embodied at or as at least part of a cloud orchestrator in the cloud environment.

The apparatus 1100 comprises at least one processor 1110， such as a data processor (DP) and at least one memory (MEM) 1120 coupled to the processor 1110. The apparatus 1100 may further comprise a transmitter TX and receiver RX 113 0 coupled to the processor 1110. The MEM 1120 stores a program (PROG) 1140.

In the embodiment that the apparatus is embodied at or as at least part of the network element in the core network， the PROG 1140 may include instructions that， when executed on the associated processor 1110， enable the apparatus 1100 to operate in accordance with the embodiments of the present disclosure， e.g. to perform the method 500. A combination of the at least one processor 1110 and the at least one MEM 1120 may form processing means 1150 adapted to implement some embodiments of the present disclosure with reference to FIG. 5.

In the embodiment that the apparatus is embodied at or as at least part of the cloud orchestrator， the PROG 1140 may include instructions that， when executed on the associated processor 1110， enable the apparatus 1100 to operate in accordance with the embodiments of the present disclosure， e.g. to perform the method 600. A combination of the at least one processor 1110 and the at least one MEM 1120 may form processing means 1150 adapted to implement some embodiments of the present disclosure with reference to FIG. 6.

The MEMs 1120 may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology， such as semiconductor based memory devices， magnetic memory devices and systems， optical memory devices and systems， fixed memory and removable memory， as non-limiting examples.

The processors 1110 may be of any type suitable to the local technical environment， and may include one or more of general purpose computers， special purpose computers， microprocessors， digital signal processors DSPs and processors based on multicore processor architecture， as non-limiting examples.

In addition， the present disclosure may also provide a carrier containing the computer program as mentioned above， wherein the carrier is one of an electronic signal， optical signal， radio signal， or computer readable storage mediam. The computer readable storage medium can be， for example， an optical compact disk or an electronic memory device like a RAM (random access memory) ， a ROM (read only memory) ， Flash memory， magnetic tape， CD-ROM， DVD， Blue-ray disc and the like.

The tectmiques described herein may be implemented by various means so that an apparatus implementing one or more functions of a corresponding apparatus described with an embodiment comprises not only prior art means， but also means for implementing the one or more functions of the corresponding apparatus described with the embodiment and it may comprise separate meansfor each separate function， or means that may be configured to perform two or more functions. For example， these techniques may be implemented in hardware (one or more apparatuses) ， firmware (one or more apparatuses) ， software (one or more modules) ， or combinations thereof. For a firmware or software， implementation may be made through modules (e.g.， procedures， functions， and so on) that perform the functions described herein.

Exemplary embodiments herein have been described above with reference to block diagrams and flowchart illustrations of methods and apparatuses. It will be understood that each block of the block diagrams and flowchart illustrations， and combinations of blocks in the block diagrams and flowchart illustrations， respectively， can be implemented by various means including computer program instructions. These computer program instructions may be loaded onto a general purpose computer， special purpose computer， or other programmable data processing apparatus to produce a machine， such that the instructions which execute on the computer or other programmable data processing apparatus create means for implementing the functions specified in the flowchart block or blocks.

While this specification contains many specific implementation details， these should not be construed as limitations on the scope of any implementation or of what may be claimed， but rather as descriptions of features that may be specific to particular embodiments of particular implementations. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely， various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover， although features may be described above as acting in certain combinatious and even initially claimed as such， one or more features from a claimed combination can in some cases be excised from the combination， and the claimed combination may be directed to a sub-combination or variation of a sub-combination.

It will be obvious to a persor skilled in the art that， as the technology advances， the inventive concept can be implemented in various ways. The above described embodiments are given for describing rather than limiting the disclosure， and it is to be understood that modificatious and variations may be resorted to without departing from the spirit and scope of the disclosure as those skilled in the art readily understand. Such modifications and variations are considered to be within the scope of the disclosure and the appended claims. The protection scope of the disclosure is defined by the accompanying claims.

Claims

A method (500) at a network element in a core network for orchestrating service provisioning， comprising：

obtaining (510) service provisioning information related to at least one service to be applied to user traffic；

determining (520) ， based at least on the service provisioning information， an order in which the at least one service is to be applied to the user traffic in a service provisioning network； and

generating (530) a traffic steering policy for steering the user traffic in the service provisioning network， wherein

the service provisioning information at least comprises information on a location of at least one service enabler for provisioning the at least one service； and

the traffic steering policy embodies the determined order in which the at least one service is to be applied.
The method of claim 1， further comprising：

providing (505) a requirement for an order of provisioning of a certain service.
The method of Claim 1 or 2， wherein

for each of the at least one service enabler， the information on the location of that service enabler comprises any of the following：

an identifier of a virtual machine hosting that service enabler， an identifier of a physical host hosting that service enabler， an identifier of a data center hosting that service enabler， and a location of the data center.
The method of any of Claims 1-3， wherein

the service provisioning information further comprises information on status of the at least one service enabler.
The method of Claim 4， wherein

for each of the at least one service enabler， the information on the status of that service enabler comprises any of the following：

instantiation of that service enabler， termination of that service enabler， suspend of that service enabler， resuming of that service enabler， a capacity of that service enabler， and a load of that service enabler.
The method of any of Claims 1-5， wherein

the service provisioning information is obtained from a business and operation support system or from a network controller in the service provisioning network.
A method (600) at a cloud orchestrator for orchestrating service provisioning， comprising：

monitoring (610) service provisioning information related to at least one service to be applied to user traffic； and

transmitting (620) the service provisioning information for use by a network element in a core network to determine an order in which the at least one service is applied to the user traffic in a service provisioning network， wherein

the service provisioning information at least comprises information on a location of at least one service enabler for provisioning the at least one service in the service provisioning network.
The method of claim 7， further comprising：

receiving (601) a requirement for an order of provisioning of a certain service from a business and operation support system or from a network controller in the service provisioning network； and

instructing (602) an virtualized infrastructure manager to allocate infrastructure resources for the certain service based at least on the received requirement.
The method of Claim 7 or 8， wherein

for each of the at least one service enabler， the information on the location of that service enabler comprises any of the following：

an identifier of a virtual machine hosting that service enabler， an identifier of a physical host hosting that service enabler， an identifier of a data center hosting that service enabler， and a location of the data center.
The method of any of Claims 7-9， wherein

the service provisioning information further comprises information on status of the at least one service enabler.
The method of Claim 10， wherein

for each of the at least one service enabler， the information on the status of that service enabler comprises any of the following：

instantiation of that service enabler， termination of that service enabler， suspend of that service enabler， resuming of that service enabler， a capacity of that service enabler， and a load of that service enabler.
The method of any of Claims 7-11， wherein the service provisioning information is transmitted for：

informing a business and operation support system of the service provisioning information， the business and operation support system forwarding the service provisioning information to the network element in the core network； or

informing a network controller in the service provisioning network of the service provisioning information， the network controller forwarding the service provisioning information to the network element in the core network directly or via an intermediate network function above the service provisioning network.
An apparatus (900) at a network element in a core network for orchestrating service provisioning， comprising：

an obtaining unit (910) configured to obtain service provisioning information related to at least one service to be applied to user traffic；

a determining unit (920) configured to determine， based at least on the service provisioning information， an order in which the at least one service is to be applied to the user traffic in a service provisioning network； and

a generating unit (930) configured to generate a traffic steering policy for steering the user traffic in the service provisioning network， wherein

the service provisioning information at least comprises information on a location of at least one service enabler for provisioning the at least one service； and

the traffic steering policy embodies the determined order in which the at least one service is to be applied.
The apparatus of claim 13， further comprising：

a providing unit (905) configured to provide a requirement for an order of provisioning of a certain service.
The apparatus of Claim 13 or 14， wherein

for each of the at least one service enabler， the information on the location of that service enabler comprises any of the following：

an identifier of a virtual machine hosting that service enabler， an identifier of a physical host hosting that service enabler， an identifier of a data center hosting that service enabler， and a location of the data center.
The apparatus of any of Claims 13-15， wherein

the service provisioning information further comprises information on status of the at least one service enabler.
The apparatus of Claim 16， wherein

for each of the at least one service enabler， the information on the status of that service enabler comprises any of the following：

instantiation of that service enabler， termination of that service enabler， suspend of that service enabler， resuming of that service enabler， a capacity of that service enabler， and a load of that service enabler.
The apparatus of any of Claims 13-17， wherein

the obtaining unit (910) is configured to obtain the service provisioning information from a business and operation support system or from a network controller in the service provisioning network.
An apparatus (1000) at a cloud orchestrator for orchestrating service provisioning， comprising：

a monitoring unit (1010) configured to monitor service provisioning information related to at least one service to be applied to user traffic； and

an informing unit (1020) configured to transmit the service provisioning information for use by a network element in a core network to determine an order in which the at least one service is applied to the user traffic in a service provisioning network， wherein

the service provisioning information at least comprises information on a location of at least one service enabler for provisioning the at least one service in the service provisioning network.
The apparatus of claim 19， further comprising：

a receiving unit (1001) configured to receive a requirement for an order of provisioning of a certain service from a business and operation support system or from a network controller in the service provisioning network； and

an instructing unit (1002) configured to instruct a virtualized infrastructure manager to allocate infrastructure resources for the certain service based at least on the received requirement.
The apparatus of Claim 19 or 20， wherein

for each of the at least one service enabler， the information on the location of that service enabler comprises any of the following：

an identifier of a virtual machine hosting that service enabler， an identifier of a physical host hosting that service enabler， an identifier of a data center hosting that service enabler， and a location of the data center.
The apparatus of any of Claims 19-21， wherein

the service provisioning information further comprises information on status of the at least one service enabler.
The apparatus of Claim 22， wherein

for each of the at least one service enabler， the information on the status of that service enabler comprises any of the following：

instantiation of that service enabler， termination of that service enabler， suspend of that service enabler， resuming of that service enabler， a capacity of that service enabler， and a load of that service enabler.
The apparatus of any of Claims 19-23， wherein the informing unit (1020) is configured to：

inform the service provisioning information to a business and operation support system， which forwards the service provisioning information to the network element in the core network； or

inform the service provisioning information to a network controller in the service provisioning network， which forwards the service provisioning information to the network element in the core network directly or via an intermediate network function above the service provisioning network.
An apparatus (1100) for orchestrating service provisioning， the apparatus comprising a processor (1110) and a memory (1120) ， said memory containing instructions executable by said processor， whereby said apparatus is operative to perform the method of any of Claims 1-6 or to perform the method of any of Claims 7-12.
An apparatus (1100) for orchestrating service provisioning， the apparatus comprising processing means (1150) adapted to perform the method of any of Claims 1-6 or to perform the method of any of Claims 7-12.
A computer program product， comprising instructions which， when executed on at least one processor， cause the at least one processor to carry out the method of any of Claims 1-6 or to carry out the method of any of Claims 7-12.