WO2018006401A1

WO2018006401A1 - Methods and devices for selective network service deployment in the cloud environment

Info

Publication number: WO2018006401A1
Application number: PCT/CN2016/089353
Authority: WO
Inventors: Shunliang Zhang
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2016-07-08
Filing date: 2016-07-08
Publication date: 2018-01-11

Abstract

Cloud environment functions are modified to be able to automatically deploy network services according to their respective network function placement requirements. Network function placement requirements are recognized and taken into consideration in cloud resource allocation and the network service instantiation. A communication mechanism between cloud management functions and the OSS/BSS enables implementing and monitoring network services according to network function placement requirements. Network function placement requirements may be updated, and related network function configurations can be updated based on network function placement fulfillment status.

Description

METHODS AND DEVICES FOR SELECTIVE NETWORK SERVICE DEPLOYMENT IN THE CLOUD ENVIRONMENT

TECHNICAL FIELD

The present invention generally relates to Virtualized Network Function (VNF) and, more particularly, to mechanisms and techniques for flexibly deploying and operating network services having network function placement requirements in the cloud environment.

BACKGROUND

Inspired by the great success of cloud technology in the information technology (IT) world, the telecommunications industry plans to provide cloud-based network service according to the Network Functions Virtualization (NFV) initiative at the European Telecommunications Standards Institute (ETSI) . NFV aims to transform the way network operators design networks by developing standard IT virtualization technology that consolidates many network equipment types into industry-standard, high-volume servers, switches and storage, which can be located in Data Centers (DC) . The cloud type of approach implements network functions in software that can run on a range of industry-standard server hardware, and which can be moved to, or instantiated in, various network locations as needed, without requiring new equipment installation.

NFV transforms the manner in which networks are built and operated by leveraging standard IT virtualization technology and consolidating network equipment types into industry-standard servers. NFV technology provides and operates more flexibly and efficiently virtual mobile network services, adding value through low capital expenses (CAPEX) , low operating expenses (OPEX) and reducing time-to-market. Therefore, it is foreseeable that more and more network services will be deployed in a cloud environment as virtual applications, for agile operation and scale in the context of dynamic user requirements.

From a network service perspective, certain network services have specific deployment requirements. For example, in one scenario, Evolved Packet Core (EPC) network service may require that Packet Data Network (PDN) gateway (i.e., P-GW) and serving gateway (S-GW) functions be deployed collocated as indicated in Figure 1. Figure 1 (which is reproduced from 3GPP TS 23.401 Release 13) illustrates a non-roaming architecture 100 for 3GPP access with a single gateway 110 (i.e., collocated S-GW and P-GW) configuration between user equipment (UE) 120 and Network Operator 130. However, in another scenario, S-GW and P-GW have to be deployed in different locations (e.g., S-GW to be more distributed, and P-GW to be more centralized and shared by many S-GWs) .

In another example, related to a Selected IP Traffic Offload (SIPTO) or Local IP Access (LIPA) service scenario, 3GPP TS 23.401 Release 13 states: “SIPTO at the Local Network can be achieved by selecting a L-GW function collocated with the (H) eNB or selecting stand-alone GWs (with S-GW and L-GW collocated) residing in the Local Network. In both cases, the selected IP traffic is offloaded via the Local Network” (here “L-GW” stands for Local Gateway, and “ (H) eNB” means an evolved Node B, eNB, which may be the Home eNB, HeNB) . Thus, P-GW and/or S-GW have to be collocated with a radio access network (RAN) function (e.g., all functions to be embedded in a base station) to reduce backhaul transmission cost and ensure a better user experience.

As yet another example, a Long Term Evolution Advanced (LTE-A) relaying system includes a similar requirement that Donor eNode B (DeNB) be collocated with S-GW and with P-GW serving the relay node. Despite eNB and P-GW/S-GW being different independent network functions, their deployment is subject to special requirements.

Implementing network services with network function placement requirements is illustrated in Figure 2. System 200 includes a Data Center (DC) 210 and a Central Office (CO) 220. For a first network service, which requires collocated S-GW/P-GW deployment, user traffic is steered along line 230 using CO 220’s collocated S-GW1 and P-GW1. For a second network service, which requires separated S-GW/P-GW deployment, user traffic is steered along line 230 via S-GW1 located in CO 220 and P-GW2 located in DC 210.

Figure 3 illustrates P-GW and/or S-GW deployed in the same DC/CO 300 as eNB1 and eNB2. In this case, user traffic 310 requires LIPA or SIPTO service to be steered in P-GW/S-GW collocated with RAN (i.e., a base station) . For other normal user traffic, P-GW and/or S-GW located in a central DC may be used. Conventionally, for a network function deployed as required by LIPA/SIPTO service, user traffic can be locally broken out to the Internet or to a local network to reduce network resource usage and improve users’ experience.

In a cloud environment, use of the cloud orchestration system is expected to lead to deploying and operating network services more flexibly and efficiently. The cloud orchestration system is responsible for allocating cloud resources and instantiating network services over the distributed cloud infrastructure. However, the conventional cloud orchestration system is not configured to take into consideration specific placement requirements of network services.

Network functions related to the network service not being placed as required may cause problems, leading to a failure to provide expected network service. If network functions are not deployed as required by the network service, user traffic is not correctly steered.

Conventionally, before network services are instantiated, a physical host for each network function is carefully dimensioned and planned through a network planning process, with all planned network function deployment information being pre-configured in the network’s Operation Support System/Business Support System (OSS/BSS) . The OSS/BSS retrieves the network configuration information for each network service and configures related network functions accordingly. Network service deployment and operation are usually associated with complicated manual configuration and high OPEX, so the dynamic and agile network service deployment and operation desirable in the cloud era remains unfulfilled. In a cloud environment, in which the distributed cloud resource pool is dynamically shared by various network services and other IT applications, OSS/BSS’s conventional static pre-configuration has become unsatisfactory.

Thus, there is a need to provide methods and devices that overcome the above-described drawbacks of the conventional approach to implementing network services that have specific network function placement requirements.

SUMMARY

In order to instantiate network services in the cloud while taking into consideration placement (collocation/anti-collocation) requirements, the network device that hosts OSS/BSS determines and transmits these requirements to the network device that hosts a cloud orchestration system. The cloud orchestration system then performs resource allocation within the cloud while considering these placement requirements. The service description model may thus be extended to convey additional information (e.g., VNF collocation/affinity information referring to collocation/affinity with another VNF of the network service, and VNF anti-collocation/affinity information referring to anti-collocation/anti-affinity with another VNF of the network service) , which may be used as monitor parameters. The embodiments may be implemented within existing interfaces and functions without requiring UE changes.

According to an exemplary embodiment there is a method implemented in a network device that hosts an OSS/BSS. The method includes determining placement requirements related to a network service to be provided to one or more users, outputting a network service request according to the placement requirements, and a network service response indicating success or failure of a cloud resource allocation for the network service according to the placement requirements.

According to another embodiment there is a network device that hosts an OSS/BSS, the device having a communication interface configured to send and receive data to and from other network devices, and a processing unit connected to the communication interface. The processing unit that includes at least one processor is configured to determine placement requirements related to a network service to be provided to a user, and to control the communication interface to output a network service request according to the placement requirements, and to receive a network service response indicating whether a cloud resource allocation according to the network service request has been successful or not.

According to yet another embodiment there is a network device including an OSS/BSS in a cloud environment. The network device includes an assessment module for determining placement requirements of a network service to be provided to a user, and a communication module for outputting a network service request according to the placement requirements and for receiving a network service response indicating success or failure of a cloud resource allocation for the network service according to the placement requirements.

According to an embodiment there is a method implemented in a network device that hosts a cloud orchestrator system in a cloud environment. The method includes receiving a network service request including a placement requirement indication related to at least one virtual network function, VNF, for providing a network service to a user. The method further includes translating a network service placement restriction requirement according to the placement requirement indication into cloud resource allocation restriction requirements, triggering a cloud resource allocation, and receiving a cloud resource allocation response indicating whether the cloud resource allocation according to the cloud resource allocation restriction requirements is a success or a failure.

According to another embodiment, there is a network device that hosts a cloud orchestrator system in a cloud environment. The network device includes a communication interface configured to send and receive data to and from other network devices, and a processing unit connected to the communication interface. The processing unit includes at least one processor and controls the communication interface to receive a network service request including to receive a network service request including a placement requirement indication related to at least one virtual network function, VNF, for providing a network service to a user, to trigger a cloud resource allocation for the at least one VNF, and to receive a cloud resource allocation response indicating whether the cloud resource allocation according to the placement requirement indication is a success or a failure.

According to yet another embodiment there is a network device including a cloud orchestrator system in a cloud environment. The network device includes a first receiver module for receiving a network service request including a placement requirement indication related to a virtual network function, VNF, for providing a network service to a user, a trigger module for triggering a cloud resource allocation for the VNF, and a second receiver module for receiving a cloud resource allocation response indicating whether the cloud resource allocation according to the placement requirement indication is a success or a failure.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more embodiments and, together with the description, explain these embodiments. In the drawings:

Figure 1 illustrates a non-roaming architecture with a single gateway；

Figure 2 illustrates network services with different requirements regarding placement of network functions, in a system；

Figure 3 illustrates a network service, in another system；

Figure 4 illustrates an architecture according to an embodiment；

Figure 5 is a flowchart of a method according to an embodiment；

Figure 6 is a flowchart related to Figure 5；

Figure 7 is a flowchart of a method implemented in a network device that hosts an OSS/BSS in a cloud environment, according to an embodiment；

Figure 8 is a schematic representation of a network device that hosts an OSS/BSS, in a cloud environment, according to an embodiment；

Figure 9 is a block diagram of a network device including an OSS/BSS, according to another embodiment；

Figure 10 is a flowchart of a method implemented in a network device that hosts a cloud orchestrator system in a cloud environment, according to an embodiment；

Figure 11 is a schematic representation of a network device that hosts a cloud orchestrator system in a cloud environment, according to an embodiment；

Figure 12 is a block diagram of a network device including a cloud orchestrator system according to another embodiment.

DETAILED DESCRIPTION

The following description of the embodiments refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. The following detailed description does not limit the invention. The following embodiments are discussed, for simplicity, with regard to the terminology and structure of a 3GPP cloud environment.

Reference throughout the specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, the appearance of the phrases “in one embodiment” or “in an embodiment” in various places throughout the specification is not necessarily all referring to the same embodiment. Further, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments.

Some of the abbreviations used in this description are listed hereinafter:

3GPP The 3^rd Generation Partnership Project is an international collaboration of a number of telecommunications standards bodies to standardize UMTS

BSS Business Support System

CAPEX Capital Expenditure

CO Central Office

DC Data Center

DeNB Donor eNode B

eNB evolved Node B

EPC Evolved Packet Core

L-GW Local GateWay

LIPA Local IP Access

MME Mobility Management Entity

NFV Network Functions Virtualization

NFVO Network Functions Virtualization Orchestrator

NS Network Service

OAM Operation and Maintenance

OPEX Operating Expense

OSS Operations Support System

OTT Over The Top

PCEF Policy and Charging Enforcement Function

PCRF Policy and Charging Rules Function

P-GW PDN Gateway

QoS Quality of Service

S-GW Serving Gateway

SIPTO Selected IP Traffic Offload

TDF Traffic Detection Function

VIM Virtualised Infrastructure Manager

VM Virtual Machine

VNF Virtualized Network Function

VNFM VNF Manager.

The OSS/BSS cooperating with a cloud orchestration system overcomes the conventional approach’s inability to consider specific network function placement requirements of the network services, to automate cloud resource provision and network service operation. The cloud orchestration system may be further configured to test whether the specific placement requirements (e.g., collocation or anti-collocation) of network services are fulfilled. If a specific requirement cannot be fulfilled during dynamic cloud resource allocation, the conventional cloud orchestration system is configured to react and/or inform the tenant OSS/BSS system about the actual status.

According to an exemplary embodiment, there is a method for providing network services with network function placement requirements. The method includes determining one or more network function placement requirements associated with a network service, reserving cloud resources according to the one or more network function placement requirements, and requesting cloud resource allocation according to the one or more network function placement requirements. According to one embodiment, an OSS/BSS function, which is now different from the conventional OSS/BSS function, performs the determining step and informs the network function placement requirements to a cloud orchestration system, and the cloud orchestration system, which is now different from the conventional cloud orchestration system, performs the reserving and the requesting steps.

The cloud orchestration system may also transform the manner in which network function placement requirements are received from the OSS/BSS function, to express these requirements as virtual machine allocation policy/instructions, which defines the anti-affinity or affinity among VMs hosting related network functions, to a virtual infrastructure manager.

The method may further include monitoring the status of the network service to detect changes related to network function placement by the cloud orchestration system. The OSS/BSS function may update network function placement requirements associated with network service.

Figure 4 illustrates architecture 400 of a cloud environment able to implement network services that have network function placement requirements. OSS/BSS 410 according to an embodiment identifies a network function placement requirement for a network service (e.g., the collocation or anti-collocation of certain network functions) to be provided to a user. OSS/BSS 410 communicates the requirement (e.g., network functions’ collocations or anti-collocations) via a message to the cloud orchestration system 420. Note that depending on the context, the cloud orchestration system is sometimes called the Management and Orchestration system (MANO) or, in the NFV context, Network Function Virtualization Orchestrator (NFVO) .

The message prompts the cloud orchestration system to instantiate the network service. The cloud orchestration system translates the requirement to virtual machine (VM) level affinity and anti-affinity requirements among VMs hosting associated network functions. The cloud orchestration system instructs the virtualized infrastructure manager (VIM) 430 to allocate VM resources according to the affinity or anti-affinity requirements so as to achieve a VNF-level collocation or anti-collocation requirement.

In one embodiment, based on feedback from the VIM, the cloud orchestration system informs the OSS/BSS if a required network service has been instantiated successfully, with the VNF placement requirement fulfilled or not. Additionally, the cloud orchestration system may update the network function placement requirement (e.g., if network function collocation or anti-collocation is maintained or not) fulfillment status info to OSS/BSS system. The OSS/BSS may generate/update configurations to related network functions based on information from the cloud orchestration system.

Some features and advantages of various embodiments are highlighted below.

1. The OSS/BSS system may determine the network function placement requirement (e.g., collocation or anti-collocation) for the network service based on business requirements and network service characteristics.

2. The OSS/BSS informs the cloud orchestration system about the network function placement requirement via a message asking the cloud orchestration system to instantiate the network service.

3. The conventional network service description model may be extended to convey the following additional information: VNF collocation (affinity) information, referring to collocation (affinity) with another VNF of the network service and VNF anti-collocation (affinity) information referring to anti-collocation (anti-affinity) with another VNF of the network service.

4. The following information may be defined as monitor parameters of network service definition to inform the OSS/BSS about the collocation or anti-collocation (affinity/anti-affinity) status of network service. The cloud orchestration system may be required to monitor the change of network service reflected by VM affinity or anti-affinity status change as monitored by the VIM, for example: VNF1’s collocation (affinity) with VNF2, VNF3, and/or VNF4’s anti-collocation (anti-affinity) with VNF5, VNF6.

5. The cloud orchestration system translates the network service placement requirement into cloud resource allocation requirements, e.g., it allocates VM resource in appropriate locations based on VNF collocation or anti-collocation requirements as included in the network service request. Specifically: (A) for VNFs with a collocation requirement, the NFVO informs the VIM to allocate a VM resource that hosted in the same physical host (e.g., VMs hosting VNF1 to have affinity with VMs hosting VNF2) ； or (B) for a VNF with an anti-collocation requirement, the cloud orchestration system informs the VIM to allocated a VM resource that is hosted by a different DC, or a different physical host of the same DC(e.g., VMs hosting VNF1 to have anti-affinity with VMs hosting VNF2) .

6. If the VNF’s collocation or anti-collocation status is changed, the cloud orchestration system communicates the OSS/BSS system of the tenant about the latest VNF deployment information via a message.

7. Based on updated location (collocation/anti-collocation) information from the cloud orchestration system, the OSS/BSS configures or updates the specific VNF deployment location/collocation-related configuration to a related VNF, such as the virtual Domain Name System (vDNS) function or virtual Home Subscriber System (vHSS) .

The following characteristics determine advantages achieved by some embodiments:

A. the network function placement requirement of a network service is taken into consideration when the network service is deployed in the cloud environment；

B. the architecture implementing this added functionality is consistent with 3GPP network architecture and NFV framework as defined by ETSI；

C. no UE changes are necessary (i.e., there is no impact on UE implementation) ； and

D. the embodiments are implemented within existing interfaces and functions, which simplifies their implementation.

Figure 5 is a flowchart of a method according to an embodiment. At step 1, the OSS/BSS 510 determines the network function placement requirement of a specific network service. The network function placement requirement may specify that certain network functions should be collocated or placed at separate locations (anti-collocated) .

At step 2, the OSS/BSS 510 sends a network service instantiation request message to the NFVO 520. This message informs about the specific placement requirement of certain network functions. The message may include VNF-level collocation/anti-collocation or affinity/anti-affinity requirements (e.g., VNF1 should be collocated or anti-collocated with VNF2) .

At step 3, the NFVO 520 allocates/reserves cloud resources for the network service according to the network function placement requirement. The NFVO may translate the VNF-level collocation/anti-collocation requirement into a VM-level affinity or anti-affinity requirement (e.g., VMs hosting VNF1 to have affinity or anti-affinity with VMs hosting VNF2) .

At step 4, the NFVO/VNFM (VNF manager) instructs the VIM 530 to allocate/reserve cloud resources for related VMs via a message, which indicates whether the group of VMs hosting one VNF should have an affinity or anti-affinity relationship with another group of VMs hosting another VNF.

At step 5, the VIM 530 allocates cloud resources (virtual computing resources, virtual memory resources, and virtual network resources) for VMs in view of the affinity and anti-affinity requirements. In the case of VMs with affinity requirements, the VIM allocates resources for VMs from the same physical host. Otherwise, for VMs with affinity requirements, the VIM 530 allocates VM resources from a different physical host.

At step 6, the VIM 530 sends a message to the NFVO 520 to inform whether the allocation of required VM resources according to the affinity or anti-affinity requirement has been successful or not.

At step 7, in view of the allocation result, the NFVO 520 sends a message to the OSS/BSS 510 to inform if the network service with the network function placement requirement has been successfully instantiated or not.

At step 8, the NFVO 520 in cooperation with the VIM monitors if any change of cloud resource provision related to ongoing network service has occurred. Such a change may be VM migration or evacuation or other events that impact the VNF collocation or anti-collocation (affinity or anti-affinity) .

At step 9, if a change of the VNF collocation or anti-collocation (affinity or anti-affinity) has occurred, the NFVO 520 informs the OSS/BSS 510 about the updated status of VNF collocation/anti-collocation via a message such as a network service update request.

At step 10, the OSS/BSS 510 replies to the NFVO 520 with a message to confirm that related information has been received successfully.

At step 11, the OSS/BSS 510 determines which NFV network configuration to update based on the VNF collocation/anti-collocation status as updated by the NFVO 520, and generates/updates the related VNF configuration regarding VNF placement.

At step 12 illustrated in Figure 6, the OSS/BSS 660 (the same as 530 in Figure 5) updates, via a message, the VNF placement-related information to other related network functions such as HSS or DNS 650.

Steps 13-17 illustrated in Figure 6 may occur before, after, or intertwined with steps 1-12, and are performed as specified, for example, in the 3GPP documents. At step 13, the UE 610 initiates an attach process by sending a Non-Access Stratum (NAS) message to a mobility management entity (MME) 620. At step 14, the MME 620 interacts with DNS 650 to select the right P/S-GW 630 for providing the network service to the user.

At step 15, the UE 610 sends the service request (e.g., as an HTTP message) to the over the top application server 670.

Upon detecting the UE service request, the PCRF 640 collocated with the S/P-GW 630 interacts to get the quality of service (QoS) and charging-related policy at step 16. The PCRF 640 provides the policy by a message at step 17. The PCRF and/or the traffic detection function enforce the policy.

At step 19, the service request is routed by the S/P-GW 640 to the OTT server 670, and, then, at step 20, the OTT server 670 replies to the service request indicating that the service has been established.

Without losing the functionality of conventional implementation, the cloud environment OSS/BSS, NFVO and VIM functions are modified according to various embodiments. These functions are executed on one or more processors and communication supports (interfaces, busses, etc. ) arranged to enable the required functionality. The OSS/BSS, NFVO and VIM functions according to various embodiments may be implemented on the same device or distributed on plural devices. The OSS/BSS, NFVO and VIM functions may also be implemented as programs (i.e., executable codes) and non-transitorily stored on computer-readable recording media (e.g., memories, disks, etc. ) .

Figure 7 is a flowchart of a method 700 implemented in a network device that hosts an OSS/BSS in a cloud environment, according to an embodiment. The network device indicates a hardware and software part of the network operator. Method 700 includes determining placement requirements related to a network service to be provided to a user, at S710, outputting a network service request according to the collocation/anti-collocation requirements, at S720, and receiving a network service response indicating success or failure of a cloud resource allocation for the network service according to the placement requirements, at S730.

The placement requirements represent collocation/anti-collocation for functional modules employed by the network service. The method may further include converting the placement requirements into an affinity or anti-affinity indication for a virtual network function of the network service, the affinity or anti-affinity indication being included in the network service request. The network service response may indicate whether affinity or anti-affinity is fulfilled or not.

Method 700 may further include receiving a network service update request for an updated affinity or anti-affinity status, determining updates related to the placement requirements of the network service, and providing a network service update response.

Figure 8 is a schematic representation of a network device 800 that hosts an OSS/BSS, in a cloud environment, according to an embodiment. Network device has a communication interface 810 configured to send and receive data to and from other network devices via network 912, and a processing unit 820 connected to the communication interface. The processing unit 820 that includes at least one processor is configured to determine placement requirements related to a network service to be provided to a user, and to control the communication interface to output a network service request according to the placement requirements, and to receive a network service response indicating whether a cloud resource allocation according to the network service request has been successful or not. The network device 800 may further include a memory 830 and an operator interface 840. The memory 830 may store executable codes which, when executed by the processing unit 820 makes the network device 800 perform any of methods described above.

The processing unit may further be configured to convert the placement requirements into an affinity or anti-affinity indication, which is the included in the network service request. The network service response may then indicate whether affinity or anti-affinity is fulfilled or not.

The processing unit may further be configured

● to control the communication interface to receive a network service update request for an updated affinity or anti-affinity status,

● to determine updates related to the placement requirements of the network service, and

● to control the communication interface to provide a network service update response.

Figure 9 is a block diagram of a network device 900 including an OSS/BSS module, according to another embodiment. The network device 900 includes an assessment module 910 for determining placement requirements of a network service to be provided to a user, and a communication module 920 for outputting a network service request according to the placement requirements and for receiving a network service response indicating success or failure of a cloud resource allocation for the network service according to the placement requirements. These modules are hardware and software. Although represented as separate functionalities, the modules may be executed simultaneously using the same physical support.

Figure 10 is a flowchart of a method 1000 implemented in a network device that hosts a cloud orchestrator system in a cloud environment, according to an embodiment. Method 1000 includes receiving a network service request including a placement requirement indication related to a VNF for providing a network service to a user, at S1010. The method further includes translating network service placement restriction requirements according to the placement requirement indication into cloud resource allocation restriction requirements, at S1020. For example, the collocation/anti-collocation requirements are converted into affinity/anti-affinity.

Method 1000 then includes triggering a cloud resource allocation for the VNF with the placement requirement indication, at S1030, and receiving indicating whether the cloud resource allocation according to the cloud resource allocation restriction requirements is a success or a failure, at S1040.

The network service request may be received from a network device that hosts an OSS/BSS. The method may further include outputting a network service response indicating whether affinity or anti-affinity has been fulfilled or not. The method may also further include monitoring a network service status to detect a change of the affinity or anti-affinity indication for the VNF. In one embodiment, the monitoring is achieves by sending a network service update request to an orchestration support system/business support system, OSS/BSS, and receiving a network service update response from the OSS/BSS.

Figure 11 is a schematic representation of a network device 1100 that hosts a cloud orchestrator system in a cloud environment, according to an embodiment. The similar appearance of the network device 1100 and device 800 is due to the schematic representation, but it is not meant to be a limitation. The network device 1100 includes a communication interface 1110 configured to send and receive data to and from other network devices via network 1112, and a processing unit 1120 connected to the communication interface. The processing unit 1120 includes at least one processor and controls the communication interface 1110 and operates:

● to receive a network service request including a placement requirement indication related to at least one virtual network function, VNF, for providing a network service to a user,

● to trigger a cloud resource allocation for the at least one VNF, and

● to receive a cloud resource allocation response indicating whether the cloud resource allocation according to the placement requirement indication is a success or a failure.

The network device 1100 may further include a memory 1130 and an operator interface 1140. The memory 1130 may store executable codes which, when executed by the processing unit 1120 makes the network device 1100 perform any of methods similar to method 1000 described above.

The network service request may be received from a network device that hosts an OSS/BSS, and the processing unit may further control the communication interface to output a network service response indicating whether affinity or anti-affinity has been fulfilled or not. The processing unit may further be configured to monitor a network service status to detect a change of the affinity or anti-affinity indication for the VNF.

In one embodiment the processing unit controls the communication interface to send a network service update request to an OSS/BSS, and to receive a network service update response from the OSS/BSS.

Figure 12 is a block diagram of a network device 1200 including a cloud orchestrator system (COS) according to another embodiment. The network device includes a first receiver module 1210 for receiving a network service request including a placement requirement indication related to a virtual network function, VNF, for providing a network service to a user, a trigger module 1220 for triggering a cloud resource allocation for the VNF, and a second receiver module 1230 for receiving a cloud resource allocation response indicating whether the cloud resource allocation according to the placement requirement indication is a success or a failure.

The disclosed embodiments provide methods and devices for flexibly deploying and operating network services with network function placement requirements. It should be understood that this description is not intended to limit the invention. On the contrary, the embodiments are intended to cover alternatives, modifications and equivalents, which are included in the spirit and scope of the invention. Further, in the detailed description of the embodiments, numerous specific details are set forth in order to provide a comprehensive understanding of the claimed invention. However, one skilled in the art would understand that various embodiments may be practiced without such specific details.

As also will be appreciated by one skilled in the art, the embodiments may take the form of an entirely hardware embodiment or an embodiment combining hardware and software aspects. Further, the embodiments may take the form of a computer program product stored on a computer-readable storage medium having computer-readable instructions embodied in the medium. Any suitable computer-readable medium may be utilized, including hard disks, CD-ROMs, digital versatile disc (DVD) , optical storage devices, or magnetic storage devices such as floppy disk or magnetic tape. Other non-limiting examples of computer-readable media include flash-type memories or other known memories.

Although the features and elements of the present embodiments are described in the embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the embodiments or in various combinations with or without other features and elements disclosed herein. The methods or flowcharts provided in the present application may be implemented in a computer program, software or firmware tangibly embodied in a computer-readable storage medium for execution by a specifically programmed computer or processor.

Claims

A method (700) implemented in a network device that hosts an orchestration support system/business support system, OSS/BSS, the method comprising:

determining (S710) placement requirements related to a network service to be provided to one or more users；

outputting (S720) a network service request according to the placement requirements； and

receiving (S730) a network service response indicating success or failure of a cloud resource allocation for the network service according to the placement requirements.
The method of claim 1, wherein the placement requirements represent collocation/anti-collocation for functional modules employed by the network service, the method further comprising:

converting the placement requirements into an affinity or anti-affinity indication for a virtual network function of the network service, wherein the network service request includes the affinity or anti-affinity indication.
The method of claim 2, wherein the network service response indicates whether affinity or anti-affinity is fulfilled or not.
The method of any of claims 1 to 3, further comprising:

receiving a network service update request for an updated affinity or anti-affinity status；

determining updates related to the placement requirements of the network service；

providing a network service update response； and

generating/updating configurations to related network functions based on information from the cloud orchestration system.
A non-transitory computer readable media storing executable codes which, when executed by a network device including a processor makes the network device perform any of methods of claims 1 to 4.
A network device (800) that hosts an orchestration support system/business support system, OSS/BSS, in a cloud environment, the network device comprising:

a communication interface (810) configured to send and receive data to and from other network devices； and

a processing unit (820) connected to the communication interface, including at least one processor and configured

to determine placement requirements related to a network service to be provided, and

to control the communication interface to output a network service request according to the placement requirements, and to receive a network service response indicating whether a cloud resource allocation according to the network service request has been successful or not.
The network device of claim 6, wherein the processing unit is further configured to convert the placement requirements into an affinity or anti-affinity indication, which is included in the network service request.
The network device of claim 7, wherein the network service response indicates whether affinity or anti-affinity is fulfilled or not.
The network device of any of claims 6 to 8, wherein the processing unit further

controls the communication interface to receive a network service update request for an updated affinity or anti-affinity status,

determines updates related to the placement requirements of the network service, and

controls the communication interface to provide a network service update response.
A network device (900) including an orchestration support system/business support system, OSS/BSS, in a cloud environment, the device including:

an assessment module (910) for determining placement requirements of a network service to be provided to a user； and

a communication module (920) for outputting a network service request according to the placement requirements and for receiving a network service response indicating success or failure of a cloud resource allocation for the network service according to the placement requirements.
A method (1000) implemented in a network device that hosts a cloud orchestration system in a cloud environment, the method comprising:

receiving (S1010) a network service request including a placement requirement indication related to a virtual network function, VNF, for providing a network service to a user；

translating(S1020) a network service placement restriction requirement according to the placement requirement indication into cloud resource allocation restriction requirements；

triggering (S1030) a cloud resource allocation with the cloud resource allocation restriction requirement for the VNF； and

receiving (S1040) a cloud resource allocation response indicating whether the cloud resource allocation according to the cloud resource allocation restriction requirements is a success or a failure.
The method of claim 11, wherein the network service request is received from a network device that hosts an orchestration support system/business support system, OSS/BSS, and the method further comprises outputting a network service response indicating whether affinity or anti-affinity included in the cloud resource allocation restriction requirements has been fulfilled or not.
The method of claim 11, further comprising:

monitoring a network service status to detect a change of the affinity or anti-affinity indication for the VNF.
The method of claim 13, wherein the monitoring includes:

sending a network service update request to an orchestration support system/business support system, OSS/BSS； and

receiving a network service update response from the OSS/BSS.
A non-transitory computer readable media storing executable codes which, when executed by a network device including a processor makes the network device perform any of methods in claims 11 to 14.
A network device (1100) that hosts a cloud orchestrator system in a cloud environment, the network device comprising:

a communication interface (1110) configured to send and receive data to and from other network devices； and

a processing unit (1120) including at least one processor and configured to control the communication interface

to receive a network service request including a placement requirement indication related to at least one virtual network function, VNF, for providing a network service to a user；

to trigger a cloud resource allocation for the at least one VNF； and

to receive a cloud resource allocation response indicating whether the cloud resource allocation according to the placement requirement indication is a success or a failure.
The network device of claim 16, wherein the network service request is received from a network device that hosts an orchestration support system, OSS, or business support system, BSS, and the processing unit further controls the communication interface to output a network service response indicating whether affinity or anti-affinity has been fulfilled or not.
The network device of claim 16 or 17, wherein the processing unit is further configured to monitor a network service status to detect a change of the affinity or anti-affinity indication for the at least one VNF.
The method of claim 18, wherein the processing unit controls the communication interface to send a network service update request to an orchestration support system/business support system, OSS/BSS, and to receive a network service update response from the OSS/BSS.
A network device (1200) including a cloud orchestrator system in a cloud environment, the network device including:

a first receiver module (1210) for receiving a network service request including a placement requirement indication related to one or more virtual network functions, VNFs, for providing a network service to a user；

a trigger module (1220) for triggering a cloud resource allocation for the one or more VNFs； and

a second receiver module (1230) for receiving a cloud resource allocation response indicating whether the cloud resource allocation according to the placement requirement indication is a success or a failure.