On Pricing of 5G Services

IT and telco providers are preparing for the era of 5G; in terms of technology, the driving force is virtualization, both for computing and networking. The 5G services will be superior than today's online services not only in technological aspects, but also from an economic and business perspective: fast service creation, effective utilization of resources, dynamic adaption to actual demand are all direct benefits of the virtualized infrastructure. In this paper we study the economic interactions between 5G resource providers and customers: we formalize how resources should be priced and selected for being booked. In particular we show that usage-based pricing is an income-maximizing scheme for providers, and we derive the problem the customers need to solve for cost-optimizing service deployment.


I. INTRODUCTION
5G is a key driver of a "high-sounding" revolution in the networking domain. Researchers, network operators, service providers and all other stakeholders face extreme challenges to meet the requirements: the challenges stem from both technological and economic questions and open issues. Meanwhile, virtualization has significantly changed the IT realm and it is reshaping the networking ecosystem. On the one hand, it is an essential enabler of many future services, and sustainable and cost-effective network operation. On the other hand, it is a root cause of challenges we need to address in the near future.
Cloud services such as, Infrastructure as a Service (IaaS), Platform as a Service (PaaS) or Software as a Service (SaaS), are built on compute and storage virtualization techniques and they are evident results of recent years' advancements. In networking, Network Function Virtualization (NFV) is the main driver of changes: the main goal of NFV is the softwarization of the data plane in order to transform traditional network services into software-based solutions run by cheap commodity servers. Together with Software Defined Networking (SDN), which addresses the softwarization of the control plane, they establish the basis of future networks.
Future 5G services such as, coordinated remote driving, remote surgery or Tactile Internet with its 1ms round-trip latency bound, pose extreme requirements not only on the networks but on the IT platforms. Moreover, 5G brings up the need of joint control and joint virtualization of IT and network resources. For example, the immensely fast and flexible service creation on top of shared resources requires special coordination and control workflows to be elaborated. Typical network services are realized by Service Function Chains (SFC) which can span not only over multiple domains, but over multiple operators, as well. In the novel 5G ecosystem, cost-effective, economical resource usage by sharing, and a geographically wide reach of customers are envisioned. Here, the customers are not (only) end-users, but they are Telcos, Over-The-Top (OTT) service providers and enterprise customers that deploy a service over infrastructure providers' resources, hence becoming the primary customers of 5G infrastructure providers.
In spite of emerging NFV architectures, ongoing research projects and standardization activities targeting orchestration of compute and network resources, generally only technological aspects are tackled. We argue that in the envisaged 5G ecosystem pricing and related business aspects have significant importance and should be considered together with the technological parameters. The main motivation of our work is the fact that in this complex setup management, orchestration and pricing in particular are of the utmost importance. The price of resources must be a driving factor of the orchestration decisions as the deployed services span over multiple providers' domains that come at various costs.
The contribution of this paper is fourfold: i) building on related work results, we define a resource usage-based pricing scheme for the 5G infrastructure providers; ii) we present a graph model of chaining virtual compute and network resources in a multi-operator and multi-domain setup; iii) we propose an integer linear program for customers to compute the set of providers that offer their resources for building a given service at the lowest cost; iv) we show a quantitative analysis of the providers' income for cases in which they diverge from the pricing scheme that we propose.
The paper is organized as follows. In Sec. II we give an overview of the state-of-the-art to show how poorly the question of pricing is addressed, and we argue for a resource usagebased pricing scheme. In Sec. III we describe the resource orchestration model we propose and provide the algorithmic solution for customers to minimize their costs spent on 5G resources. In Sec. IV we show with simulation results why 5G providers should follow the pricing scheme we propose. We conclude our work presented in this paper in Sec. V.

II. BACKGROUND OF SERVICE PRICING
We present an overview of pricing aspects of services over compute and network infrastructures. First we summarize how little current management and orchestration (MANO) solutions tackle pricing of resources, functions and services. Then we 978-1-5090-5019-2/17/$31.00 ©2017 IEEE list the main orchestration engines. Last, we argue how wellsuited dynamic pricing is for multi-domain SFC pricing.

A. Pricing in Service Definitions
Standardization bodies and industrial consortia work in parallel on MANO frameworks for cloud and NFV, but pricing aspects do not receive any attention, however there is clearly a strong relation between orchestration and pricing. Furthermore, not only the provider selection and function deployment is greatly affected by prices, but also the management of services, particularly through scaling and SLA enforcement.
First let us review the current status of service and function descriptors, as those are the front line means of driving MANO processes. Two main approaches co-exist for the description of services: the Network Service Descriptor [1] from ETSI and TOSCA [2] templates from OASIS. Although ETSI's NFV Industry Specification Group completed its first work phase in 2014 and one of the resulted specifications that covers management and orchestration [3] contains a todo note about adding pricing info later, even the latest publicly available specifications lack such details [1], [4]. The industry considers TOSCA as a de-facto standard to define distributed cloud services: TOSCA YAML files describe the service topology as a set of nodes, relationships, dependencies, instantiation and configuration settings, monitoring, and maintenance, but no pricing field can be currently found there.
In both cases, costs can be defined to a resource or capability, but these come as abstracted values, not necessarily related to money, but derived to express affinity or power consumption costs. Although the definition of a service given in either a NSD or a TOSCA template is generic enough to include prices as attributes of nodes. Then an upper business layer can drive this attribute, in alignment with high level goals and commercial aspects, which later on is translated into the composition of the service templates to be implemented by the service layer. A possible descriptor for this upper layer is the language called Business Process Model and Notation; an initial interface connecting business processes with TOSCA is described in [5], but without direct reference to pricing models.

B. Pricing Aspects in Orchestration Engines
Consequently the main available open-source MANO engines do not yet tackle pricing in their orchestration logic. We consider the following as the main ones. Open Source MANO (OSM) delivers an open-source stack closely aligned with the ETSI NFV reference architecture [6], building on RIFT.io component Launchpad (RIFT.ware is a commercial distribution of OSM [7] from the same company) and JuJu [8], Canonical's open source application modeling tool that deploys, configures, scales and operates the software on public and private clouds. OPEN-O [9], another major project, enables end-to-end service agility across multiple domains using unified platform for NFV and SDN orchestration. Third, Cloudify was introduced as a pure cloud orchestration solution, but the platform was further expanded to include NFV-related use cases, and the Cloudify Telecom Edition emerged [10].
Other MANO projects such as OpenBaton [11], T-NOVA/TeNor [12] and SONATA [13] have their codebases available in public repos, but while industry support, involvement of external contributors and further sustainability might be a challenging for these projects in the future [14], only traces of pricing aspects can be seen. T-NOVA's Marketplace solution allows providers to determine billing details for their services: pay-as-you-go option can be selected, price per period and service setup cost can be given in selected currencies which is then written into the NSD. The orchestrator of the UNIFY project [15] does not tackle pricing, but optimizes on balanced usage of resources, both in terms of compute and network [16]. We show that including prices in the decision, this is the outcome the orchestration will achieve implicitly.

C. Pricing of IT Resources and Services
The main reason for the lack of pricing aspects within these MANO frameworks is that they mainly target a single administrative domain, and therefore the end-user price is not directly linked to the cost of resources that are used for provisioning the service. Most infrastructure providers today apply flat or pay-as-you-go pricing schemes with fixed unit prices in the latter case. Then the price competition is defined by these prices, and the internal costs of the provider once selected to deploy a service is minimized internally. However, the provider's income is greatly affected by the dynamics of demand, by elasticity, i.e., scaling up/down the service.
In principle there are several ways to deal with this dynamics: either by creating markets that can generate the values of the parameters of the pricing schemes or by creating pricing schemes and market mechanisms where prices are set dynamically according to multiple factors (e.g., utilization). An example of the former is a spot market where a market price for a certain resource or service is generated given the intersection point of demand and supply: this approach is taken in Amazon EC2 Spot Instances [17], in ride-sharing systems like Uber [18], etc. The latter, dynamic pricing of services is most useful when two product characteristics co-exist. First, the product expires at a point in time, like hotel rooms, airline flights, generated electricity, or time-dated perishable ("sell before") products. Second, capacity is fixed well in advance and can be augmented only at a relatively high marginal cost. These characteristics create the potential for very large swings in the opportunity cost of sale, because the opportunity cost of sale is a potential foregone subsequent sale. The value of a unit in a shortage situation is the highest value of an unserved customer. Forecasting this value given current sales and available capacity represents dynamic pricing [19].
An example for this usage-based dynamic pricing scheme applied for NFCs is presented in [20]: based on historic data about service request arrival rate (modeled as a Markov process), about the amount and duration of resource allocations, about prices and resource usage levels, the authors derive the prices, based on the actual utilization, that maximizes the potential income of the provider. Going forward, in this paper we target a multi-provider setup, where a service is implemented on the federation of multiple providers. Total cost is based on the prices of booked resources of participating providers: prices are added up throughout the chain from all the operators involved. We propose that the price at a given point in time of a given amount of resource booked for a given duration in the future at a given provider should vary according to the current level of booked resource utilization for that duration at that provider. This proposition builds on the findings in [20]: as booked utilization increases, providers up their prices in order to reserve capacity for later arriving customers with higher utility in order to increase their income.

III. RESOURCE MODEL FOR SERVICE CREATION
In order to grasp the complexity of the multi-provider setting we build a price model of resources and we give an algorithm that finds the resource set for the customer that can host its service at the lowest cost possible.
The actors of the ecosystem can be grouped into 3 categories. We model the customers by the Service Access Points (SAP) where they are ready to consume the service: this might be a geographic point or region, an IP address or an IP address range, even a whole autonomous system. Network service providers is the second group that we denote by NWs which refers to access and transit networks. An access network can be either wired or wireless, either a virtual operator or one with a physical network; a transit network can be a Tier1 or a Tier2 provider, even a Tier3 one with direct DC connectivity. And this brings us to the third group of actors, the Data Center providers, marked as DCs, which might be located at a single or multiple locations but connected to the same NW.
First we summarize the notations we use throughout this paper and present the graph model of the ecosystem, then we define the SFC orchestration problem of finding the cheapest possibility for the customer to deploy its service as a minimum-cost flow problem, finally we formulate the problem as an Integer Linear Program.

A. Graph Model and Notations
Let denote the set of SAPs, the set of NWs and the set of DCs. We define a directed graph = ( , ) as follows, where denotes the set of nodes, and the set of arcs. There is a node assigned to each SAP, each NW and each DC in , thus the total number of nodes is | | = | | + | | + | |. We add the following arcs (see Fig. 1): • Connect SAP to NW: each customer's online service is reachable at one or more network providers; • Interconnect NW nodes: connect the transit and access networks which have direct links, representing direct peering, connectivity at Internet Exchange Points, etc.; • Connect NW to DC: each DC is connected to the Internet via at least one network provider. Note, has no arcs between the nodes in , and similarly it has no arcs between the nodes of (see Fig. 1).
A given service request ∈ is defined by a SAP, denoted by ∈ , the maximum price the customer is willing to pay, a delay constraint that gives an upper limit on the additive network latencies the network providers guarantee, and the required resource amount . If a service chain has multiple SAPs, in our model it can be replaced by multiple service chains each with single SAP. In our model, we assume that resources have a general unit, which is either a measure of computation required to run the service in DCs, or corresponds to consumed network bandwidth at NWs. This also implies that any DC can serve any service, i.e., the computation never requires any special hardware.
On the providers' side we use upper-case letters. is used to denote their capacity, which can be either a network capacity for ∈ , or compute capacity in a data center for ∈ , and inline with the above assumption, we suppose that there is a fixed relation between the network and the compute requirements of all services. We introduce for the supposedly constant latency/delay a network provider guarantees, e.g., . We assume zero delay in data centers, i.e., = 0, ∀ ∈ . As pricing, we use the notations and for the current usage level and the current price of resources for both network and data center providers. As motivated in Sec. II, we assume that there is functional relation between usage and price: = ( ), ∀ ∈ ∪ . The price is zero for SAP nodes, i.e. = 0, ∀ ∈ , and those nodes do not raise any technical obstacles, i.e., = ∞, = 0, ∀ ∈ .

B. Service Chain as a Flow
Our goal is to provide resources for a service chain initiated from the customer's SAPs. Typically, in each service chain there is a single SAP, which is connected to a single DC through the graph of NWs. So for deploying a given service, the customer has to select a DC and a path in the network to reach it (see Fig. 1): technically this is going to be a path in between a node in to a node in . Generally however, a service chain may be connected to multiple DCs if the capacity of one DC is not enough or it is too expensive. If the SAP is served by multiple DCs we may face an additional cost of synchronizing the states of the service between DCs, which we neglect here. These imply that the service chain ∈ can be modeled as a flow starting from its SAP ∈ with capacity , and terminating in DCs. Moreover, a service chain may have multiple SAPs, with a given capacity requirement starting at each one of those SAPs.
In case of multiple SAPs, we treat the service as multiple flows calculated separately.
To be inline with network flow theory, first we need to redefine the price, delay and capacity values, but this time on arcs instead of on nodes, denoted by , and respectively for arc ∈ , as follows: One can verify that a simple path (without loops), has the same cost in both models, i.e., with price defined on network nodes or on arcs, formally ∑ ∈ = ∑ ∈ . Note that as a result of cost optimization, the obtained flow corresponding to a service chain has no loops either, thus the above can be generalized to flows as well. This holds for delay too, which is also an additive metric. Similarly, one can verify that a flow that meets the capacity constraints of the nodes, also meets the capacity constraints of the links, and vice versa.
Claim 1: Any loopless flow has the same cost, delay and meets the capacity constraints equally in both models: with the price, delay and capacity defined on nodes or on arcs. ■

C. Integer Linear Program (ILP) for SFC Orchestration
We conjecture that the SFC orchestration problem is NPhard; thus, we will formulate it as an ILP. Let be an arc of the graph, and let , denote the amount of flow allocated for a service request . Based on the above the total price the customer pays for service , i.e., the target function to minimize, is: as both network and data center costs add up to the final bill. The customer budget raises a constraint to this cost: ∑ ∈ ⋅ , ≤ .
Next we define the flow constraints. First, we need to ensure there are flow originated at the SAP of the service chain: Second, in each NW we have flow conservation constraints: Note that we do not need to deal with DC nodes as they are always sink of the flows. Third, to consider the capacity constraints of each arc, we add the following constraints: Finally, we address delay constraints on the NWs for each service chain . To do so, we need to add a binary working variable , for each arc ∈ , and a non-negative real variable , for each node . Variable , indicates that there is a flow on link , formally 1 if service chain uses arc , 0 otherwise. This can be ensured by the following equations: where is the maximum capacity value for each node, i.e. = max ∈ . Variable , represents the delay of the service chain at node from SAP . It should not be larger than : Last but not least, we have the following constraints: which ensure that if arc → is traversed by the service chain, i.e., , → = 1, then the delay at node for service chain is (at least) , = , + → , otherwise the constraint on the delay is relaxed (because the difference between variables , and , is at most ).

IV. NUMERICAL ANALYSIS
In this section we turn back to the pricing scheme of the providers, and with simulations we show the motivation behind the usage-based dynamic pricing. In the 5G market, the NWs compete with each other in order to make sales and increase their income, but they also need to take into account that subsequently arriving customers might pay more for the resource they sell, which is on the other hand perishable, i.e., resource utilization expires at the point in time when the booked period ends.

A. Simulation Settings
Topology. We simulate an environment of 200 SAPs, 60 NWs (10 transit and 50 edge networks) and 200 DCs being interconnected in hierarchical topology of three tiers. All the transit NWs belong to the first tier and they are connected in a full-mesh, while each serves a number of edge NWs of the second tier. In particular, the edge NWs are assigned to the transit NWs in a uniformly distributed random way. Finally, the third tier consists of DCs and SAPs, who are also uniformly distributed to the available edge NWs via connections. We assume that an edge NW can be connected to more than one DCs or multiple SAPs, but we omit the case where an edge NW hosts SAPs and DCs simultaneously. The minimum cost solution for the SFC in this case would be mostly trivial since SAPs would always choose local DCs.
Resource capacity and network delay. We assume that the compute resource capacity is the same at all DCs and it is normalized to 1. The total network resource capacity of an edge NW is determined by the number of DCs or SAPs connected to it, i.e., we add 1 unit of capacity per link. For the transit NWs we follow the same approach, but we double the capacity to capture the fact that congestion rarely happens in the core. A fixed delay is assigned to each NW with uniformly distributed random values in the range of 10 − 20 for the edge and 2 − 5 for the transit NWs.
Service requests. We generate multiple request series of services with various lengths, ranging from 6000 up 24000 Pricing. Each provider charges for each service it serves and the price is based on the current utilization level of its infrastructure. We assume that all DCs or NWs use the same linearly increasing pricing function, and the maximum price they can charge at 100% utilization is set to 1. The total price that a customer pays is the sum of the prices requested by the different providers in the service chain.
Service composition. We assume that the service requests are served in a first-come-first-served fashion. We calculate the minimum cost path for each request solving the ILP in Sec. III and if all criteria are satisfied, we book resources for the service on the resource graph. After each booking, the involved providers re-set their prices to the actual booked utilization level of their infrastructure. We investigate the case where a provider deviates from this standard pricing policy setting its price higher or lower (± ).

B. Results
We mitigate the effects of randomness in our results by running simulations for 10 different topologies and 10 service request series. The results reveal that the combination of the usage-based pricing and minimum cost path selection leads to load balancing (Table I) with high service completion (Fig. 2). Fig. 2 shows the number of successful and unsuccessful service compositions as the service request series gets longer, i.e., more services need to be deployed. We can observe that as the number of requests increases and the resource utilization rises to a high level, i.e., over 90%, the number of unsuccessful service composition attempts starts to increase. This growth is an expected behavior since a service request can be rejected for three different reasons: (i) there is no path that satisfies the minimum delay guarantee, (ii) available paths are more expensive than what the customer is willing to pay, (iii) there is a resource scarcity on all available paths. At low utilization levels and thus with low prices, a service request might be rejected most probably for demanding extremely low delay guarantees. As the utilization increases, so does the price, therefore after a certain level some requests can be rejected because of low willingness to pay. Finally, as the system reaches its capacity limits, only requests that combine high willingness to pay and a demand of relatively low capacity can be served. Table II maps the number of unsuccessful service compositions of Fig. 2 to these three reasons. Note that a request may be rejected for multiple reasons on any candidate path. The results show that usage-based pricing is a useful mechanism to avoid extreme infrastructure utilization. Fig. 3 depicts the total income of providers as the length of the service request series increases. We can observe that the income starts increasing almost linearly with the number of requests, but it becomes concave as the utilization level grows further since the successful composition ratio decreases.
Finally, we investigate the case where a provider deviates from the usage-based pricing and intentionally sets its price higher/lower than it should set to. We randomly select a provider and we run again the experiments with it following either a conservative (lower) or an aggressive (higher) pricing. In particular, after setting its usage-based price, we increase (or respectively decrease) the value by = 0.2. Fig. 4 depicts the income of the selected provider for the three scenarios while Fig. 3 shows the total income for all providers. The results reveal that a provider who follows conservative pricing policy, attracts customers and thus becomes over-utilized compared to others. This may bring extra profit when the resource supply is high compared to the demand, but as the demand increases this policy leads to profit loss (e.g. for service series length > 18 * 10 3 in Fig. 4). On the other hand, being aggressive in pricing leads to under-utilization, especially when supply is high compared to demand, however, when the availability of resources is low, an aggressive provider will still have resources to supply to the high utility customers and therefore will generate profit. Both of these approaches may have an advantage in very extreme cases, but on average the usagebased pricing generates higher income. Note that in Fig. 4, the results for each different series length is an average of multiple runs and with a random selection of the deviating provider each time. Due to this randomness, we do not expect the plots to be strictly monotone.

V. CONCLUSION
With this work we tackled the questions around resource pricing in the envisioned context of 5G online services. Major efforts are being made towards this vision: developing IT virtualization techniques and NFV advancements pave the way to the resource-optimized and elastic infrastructure lying below the future 5G services for which even the borders between providers are torn down. With this pioneer work we show, backed with a numerical analysis, how these providers will probably price their resources, and in turn we build a model and we provide a formulation for the problem that customers will face when selecting the right set of providers' resources for deploying their services.
The model and analysis proposed in this paper are meant to be the first in their kind, i.e., pricing of multi-operator SFCs. We intend to continue the work by alleviating our assumptions made in our model, and by fabricating heuristics that make SFC orchestration fast and close-to-optimal even in the more complex setting. Furthermore, instead of numerical simulations, we plan to perform a game theoretical analysis of the pricing schemes applied by the operators, in particular studying the interplay between the connectivity graph of the providers and their income-maximizing pricing strategies.
ACKNOWLEDGMENT This work has been performed in H2020-ICT-2014 project 5GEx (www.5gex.eu, Grant Agreement no. 671636), partially funded by the European Commission. The research was partially supported by the Hungarian Scientific Research Fund (grant No. OTKA 108947). Laszló Toka was partially supported by the János Bolyai Research Scholarship of the Hungarian Academy of Sciences.