forms of admission control functions, as suggested in [HUST00][BERN00]. Presently, the pricing model mainly used in Internet is the flat-rate one, according to ...
Accounting and Charging in an IP Infrastructure Supporting QoS and Mobility N. Blefari-Melazzi, D. Di Sorte, M. Femminella, G. Reali D.I.E.I. - University of Perugia - Italy {blefari,disorte,femminella,reali}@diei.unipg.it Abstract: This paper presents an accounting model and some tariff models to charge IP network services on the basis of a per-usage approach. This work has been carried out in the framework of the WHYLESS.COM project1
I.
Introduction
The network scenario of the WHYLESS.COM project is constituted by the "Open Mobile Access Network" paradigm. Such paradigm is not yet another mobile radio access network but rather a new platform where electronic work and business can be conducted. This novel platform needs to be based on a non-expiring and transparent technology in order to give service and application developers a long-term perspective. WHYLESS.COM is based on a new enabling radio transmission technology (the so-called Ultra Wide Band) and on data transport resource-brokerage. The project scope is not limited to a wireless access system, but considers also fixed networks and their interplay with the wireless ones. The underlying network protocol is assumed to be IP. WHYLESS.COM aims at providing customers with mobility and different degrees of Quality of Service (QoS) performance to support adequately future Internet applications, such as voice and video over IP. In this paper, we consider the Differentiated Services (DiffServ) as the architectural model for supporting QoS [BBCD98]. We assume to enhance the standardised DiffServ architecture with some forms of admission control functions, as suggested in [HUST00][BERN00]. Presently, the pricing model mainly used in Internet is the flat-rate one, according to which the charge is not dependent on the volume of traffic involved in transmission sessions. This approach has been one of the major reasons of the wide Internet development, but it will become inadequate soon, particularly for charging applications with different QoS requirements. As underlined in [HUST00], “The introduction of QoS services creates a strong impetus to move to usage-based tariffs, where the tariff is based on the level of use of the network’s resources. This, in turn, generates a requirement to meter resource use…”. Therefore, it is necessary to realise an accounting architecture for supporting usage-based pricing model. As defined in [ABAH00], accounting is concerned with the collection of resource consumption data to support the procedures of capacity and trend analysis, cost allocation, auditing, and billing. At the same time, it is necessary to implement an architecture for price negotiation between customer and the network, particularly for added value services. Beyond the classic flat-rate approach, different usage-based pricing models for packet networks have been proposed (see [FADL00] for a survey). In this paper, we describe the general network business model, and then we focus our attention on the charging of IP network services; we propose some tariff models to charge the DiffServ network services and describe the accounting architecture for supporting the charging on a per-usage basis. We introduce also the issue of the pricing management in a mobile scenario. The paper is organised as follows. In Section II, we describe the business model. In Section III, we present tariff models to charge IP network services. In Section IV, the accounting model and the accounting management architecture are proposed. In Section V, we face the issue related to the handover management. Finally, in Section VI, we report some conclusive remarks. 1
The background of this work is the IST project WHYLESS.COM, sponsored by the European Union. The effort of the project’s partners is gratefully acknowledged. This paper, however, does not implicitly and necessarily represent the opinion of the other project partners.
II.
Reference Environment
As shown in Fig. 1, customers request services to Application Service Providers (ASPs), which offer a set of services. When a request and an offer match, the relevant ASP can provide the requested service to the end user, and charge him according to their previous agreement. This may be considered as the highest abstraction level to describe business interactions between end users and ASPs. In order to have information about the ASPs providing the requested service, end users, if necessary, may consult the Information Broker (IB), that represents the interface between the requests of customers and the offers of ASPs. After the consultation of the IB, the end user makes the explicit service request to the ASP selected. ASPs
end users
requests
offers
Fig. 1 - Logical plane.
Let us consider an end user that would like to receive a specific application service. It is evident that he cannot be required to formulate the request for the network service support by using specific technical parameters as regards the desired QoS and the flow description; this is a task of ASPs. As regards the technical aspects involved in the transmission of information, the situation is further complicated. In general, we consider a number of possible independent administrative domains, managed by a Network Service Provider (NSP). Such NSP is in charge of guaranteeing a specific service to a flow passing through the relevant domain, that is a Per Domain Behaviour (PDB) [NICA01], and, correspondingly, to request a specified fee. This means that a lot of decisions must be taken to maximise the QoS perceived by end users, and their satisfaction, given their willingness to pay. To this aim, another player is necessary: the Resource Broker (RB). It represents the interface between the requests of ASPs and the offers of NSPs, regarding the network support for providing a specific application service. In summary, we consider the scenario shown in Fig. 2. It is composed of the following entities: ! User: this entity models the users of the network. It indicates: - end users: they are private users who are allowed accessing the network for receiving a specific application service. End users pay a fee to ASPs and to the IB for their service; - Application Service Providers (ASPs): they provide customers with application services, and charge them accordingly. ASPs pay a fee to NSPs for the network support, and to the IB and the RB for the service provided. They receive a fee from end users for the application service. ! Network Service Providers (NSPs): they provide ASPs with the network infrastructure for the provisioning of the service to end users, and receive a fee from them. Moreover, NSPs pay a fee to the RB for its service. ! Information Broker (IB): this entity has the task to put in contact the requests of end users and the offers of ASPs. For the deployment of this service, it receives a fee from end users and ASPs. It could be only logically a single entity. ! Resource Broker (RB): on request of ASPs, it has the task of providing a list of suitable routes with adequate QoS level and the associated end-to-end network services cost, by choosing a certain number of paths through different administrative domains to deliver a service for a specific end user. It receives a fee for the requested service from ASPs, and NSPs. It is possible that the RB is only logically a single entity. ! Clearing House (CH): it is a trusting centre. It assures that the certified entities involved in transactions are enabled to perform their work, and that they have the necessary professional
ability to do it with success. To do this, it receives a fee from the certified entities. CH could be only logically a single entity. Domain A
Domain B
NSP
NSP
Domain C
NSP
ASPs
offers
end users
requests
RB
requests
IB
offers
CH certification
Fig. 2 – Reference environment.
III.
Network Service Tariff Models
We consider three classes of service: the classic Best Effort Service (BES), Better than Best Effort Services (BBESs), and High Quality Services (HQSs). In Internet, the most common method of payment for network support between customers and local ISPs, and between different administrative domains, is based on the flat-rate model. According to such model, the charge does not depend on the amount of traffic exchanged in the communication session. It is necessary to meet only the expenses for accessing the service (access charge). Under this model, it is possible to consider the following payment options: free access, connection charge, periodical subscription fee, and periodical subscription fee plus connection charge. Prices are usually based on the speed of the access link. It is fair to classify connection charges as metered, depending on the time, and unmetered, as for the case of access through telephone networks. We assume the flat-rate model for the BES. In spite of this, since wireless resources are particularly expensive, we remark that in some cases, beyond the flat access fee, it could be useful to adopt per-volume charge in the wireless section, also for the BES. As attested by some studies [ALCH01], subscribers are willing to pay, beyond the flat-rate access charge, an added per-usage charge for improving the perceived performance (quality of service charge) on demand, for particular applications, or in situations of marked network congestion; this is attractive for ISPs as well. Billing and payment procedures may take place periodically, or on line, e.g. using rechargeable credit card bought by customers according to their needs, and updated on line. We define per-call tariff models to be applied by each administrative domain for added value services. BBESs are qualitative services; they do not give absolute guarantees on the perceived performance, but assure that the quality will not completely degrade during network congestion periods, as regards delay and/or informative integrity. Exigent customers and some Internet applications needing a minimum of guaranteed performance, such as some multimedia services, would benefit from this type of service. The Assured Service [HBWW99] in the DiffServ model, enhanced by admission control functions, is consistent with BBES. We assume that the Assured traffic of each source is described by Leaky Bucket parameters: (r,br), where r is the sustainable rate, and br is the token bucket size, representing the sustainable rate tolerance. The sustainable rate specifies the amount of transmission capacity for which the network assures an advantageous treatment. The out of profile packets are classified as Best Effort ones. We assume that call charge = ctT+cvV, where T and V are the connection time and the exchanged traffic volume, respectively. The constants ct (i.e. the charge perunit of time) and cv, (i.e. the charge per-unit of flow) are a function of the sustainable rate, the type of
service and the time of the day. In fact, it is useful to make tariffs depending on the time of the day (time of day pricing), so as to contribute to the congestion control. Usually, the day time is divided in off-peak time and peak time. A more pretentious idea is making tariffs depending dynamically on the network congestion degree, monitored on line. In this case, the charge would consist of a fixed component plus a dynamic one (congestion charge). It is our opinion that for BBESs a per-time charge is necessary, since a per-call resource reservation is involved. Note that the resource reservation generally precludes other customers from using the reserved resources. We assume that this charge is a moderate one, because, in this case, the reservation is soft. We call this component allocation charge; it characterises the potential use of resources and it is a protection against unfair behaviours of customers. Anyway, we assume that the heaviest component of the above tariff is per-volume (effective usage charge); it depends on the actual use of resources. HQSs aim at giving quantitative end-to-end guarantees on performance, in terms of delay and losses (real time guarantees). Future Internet applications, such as voice and video over IP, would benefit from this type of service. The Premium (or Expedited) Service [JANP99] in the DiffServ model, enhanced by admission control functions, is consistent with HQS. We assume that the Premium traffic of each source is described by Dual Leaky Bucket parameters: (P,r,br), where P is the peak rate. The out of profile packets are dropped. The quantity that can be deemed as adequate to be reserved and charged is the equivalent bandwidth. Such parameter is a scalar quantity depending on the traffic characteristics and the requested performance of a flow, and on the availability of resources in a node. It represents the resource consumption of the flow at a node. Charging this type of service is complex, since the amount of allocated resources can be conspicuous. We can consider the matter from various angles. First of all, once the traffic and performance descriptors have been defined, the amount of allocated resources is generally conservative, and it is often based on worst case assumptions. This is the reason why network administrators would like to charge in proportion to this quantity. At the same time, it is difficult for customers to predict their traffic rate process exactly, so that they would consider convenient to be charged according to the actual used resources instead of the estimated (and eventually over-estimated) ones. We propose a simple tariff model, that consists of both allocation and effective usage charge components: call charge = ctT+cvV, where ct and cv depend on the allocated equivalent bandwidth and on the time of the day. In this case, we assume that the allocation charge component is the heaviest one, because the amount of reserved resources can be substantial. Since the concept of equivalent bandwidth is relative to a single node, it could be useful to define a standard node, to compute the equivalent bandwidth, for pricing purpose, univocally.
IV.
Accounting Model
Accounting concerns the collection of resource consumption data to support usage-based pricing. We need a general model supporting both the realisation and the management of accounting procedures. As regards the former feature, a model of recursive accounting has been proposed in [MIHR91]. To describe it, we refer to the general network architecture model shown in Fig. 3. Local (or access) ISPs offer connectivity to customers, and make use of the service of hierarchically higher ISPs (backbone providers). The whole network is divided in different administrative domains. Each domain applies tariffs that fit better to its own requirements, according to the models of the previous Section. We suppose that the administrator of the domain D is interested in charging on a per-usage basis the traffic passing through its network. It is possible to identify two traffic classes. The internal traffic, that has the source and the destination within D, and the external one, that has the source and/or the destination outside D; correspondingly, we can speak of intra-domain and inter-domain accounting. The first step is determining the subject responsible for payments. At first, we assume the sender-pays approach, according to which such subject is the sender. As regards the intra-domain accounting, it is sufficient to implement measurement procedures at access routers, and then processing and storing accounting data for successive billing. This approach may be extended to inter-domain accounting, in which measurements are realised at edge routers as well. As an example, let us consider a user belonging to the domain A sending traffic to a user belonging to D. The relevant traffic is measured at the edge router between A and D and, according to these measurements and to the adopted tariffs, D charges A. Then, A charges its user according to the traffic measured at the access router. To identify the subject responsible for payments, it is necessary a packets classification based on a voucher in the IPng packet [NBRO94], updated along the path.
users
users
AR
AR
ER
AR
DOMAIN C
DOMAIN D DOMAIN A
AR
ER
Local ISP
ER
ER
ER
Backbone and Local ISP
Backbone ISP
ER
AR: Access Router ER: Edge Router
Fig. 3 - Network architecture model.
The sender-pays model is not always adequate. The receiver, and not the sender, is often the subject who should be responsible for payments. It is sufficient to think to a better than best effort data download from WWW servers, or to an high quality IP telephone call, in which both corresponding customers send data. Different solutions can be applied. In the first case, subscribers can pay the complete service to the server, which is in turn responsible for the transmission charge. Therefore, the receiver is only indirectly responsible for payments to the network (dual approach charging [WOLI00]). This approach protects subscribers against unfinished or incorrect services due to server inefficiencies. Another solution presented in [CLAR96], suited for instance for telephone applications, is tagging each packet by a specific field at the network access point. This field, that we call charge bit, indicates if the responsible for payments of the per-volume charge is the receiver or the sender. For example, if the charge bit is equal to 1, then the responsible for payments is the receiver, determined at nodes by routing algorithms; otherwise, if it is 0, the responsible is the sender, and measurement devices read the voucher to determine it. The subject responsible for the per-time charge is clearly settled during the set-up phase. Another important issue for accounting purposes is the realisation of an accounting management architecture within each administrative domain. In [ABAH00] three main entities are identified: network devices, accounting servers, and billing servers. Network devices collect measurement data, and send them to accounting servers, which in turn generate the session records in which the accounting information are stored. As mentioned above, network devices are implemented both at access routers and at edge routers. Session records are then sent to the billing server, which sends invoices to its customers and to the neighbouring domains. The rules for generation, transport and storage of accounting data are known as accounting policies [CZZS00]. Scalability, reliability, and flexibility must be the main traits of an accounting management architecture [ABAH00][CZZS00].
V.
Pricing Management in a Mobile Environment
Since the WHYLESS.COM scenario provides also (and specifically) wireless and mobile access, it is necessary to face the issue of the pricing management when the active mobile customer moves, so that the point of access in the network changes. In this case, tariffs may change as well. To simplify the treatment, we assume that the price to be charged for a service is defined completely by the currently selected access network according to its own policies. This way, once the type of service is determined, it may occur that different domains apply different tariffs. To provide mobility, an additional customer entity is necessary for handling a seamless handover. A seamless handover implies that an application session can go on without being aware of the change of the access point. The availability of different access domains is known to this entity by means of feedback signalling messages that carry information on the available power level. The handover procedure could be triggered by the following events: 1. a customer leaves the coverage of a domain; 2. a cheaper (in terms of cost) access domain gets available.
When a customer starts an handover procedure, we assume that an amount of resources equal to the previously allocated ones will be available in the new domain. Under this hypothesis, we distinguish between two types of handover: forced handover and voluntary handover. In the former case, the handover procedure is needed to maintain the connection active, as in the first of the two events listed above. Such procedure needs a pricing negotiation between the customer and the network, depending on the requested type of service and on the new tariff relevant to the involved access domain. This is the reason why a customer has to choose the new QoS level to be requested according to his willingness to pay. In particular, when the new domain requests higher prices, the customer may decide if accepting a worst service while maintaining the same tariff (or a similar one), or if accepting to pay an higher tariff, in order to maintain the same QoS. In the case of voluntary handover, the change of domain is performed if there is the possibility to receive the same level of service with a lower cost, or a better service with the same cost, (see the second of the events listed above). In this case, the mobile terminal equipment reveals the signal power of different domains as being higher than a minimum pre-defined threshold, deemed necessary to provide connectivity. Therefore, it is necessary to evaluate the best trade-off between the price and the required level of service. The previous considerations can be formalised using a decision function in the customer terminal. The algorithm can be a priori settled on the basis of the customer preferences in terms of desired QoS and willingness to pay. This way, the handover is transparent to the pricing management as well. In the definition of such decision function, two basic constraints must be considered: the customer perceived performance must be better than a minimum reference level, and the price has to be lower than a maximum value. Once these constraints are fulfilled, the decision function has to determine the best trade-off. At the end of the price negotiation, the call set-up phase for requiring the QoS level previously chosen starts.
VI.
Conclusions
The main objective of this paper has been to present an accounting model for supporting different policies to charge IP network services in a DiffServ capable network. A classic flat-rate model for the classic BES, and a usage-based model for BBESs and HQSs have been presented. We have considered the issue of price negotiation, both in fixed and in mobile scenarios. The reference environment is the one of the WHYLESS.COM project.
References [ABAH00]
B. Aboba, J. Arkko, D. Harrington, “Introduction to Accounting Management”, IETF RFC 2975, October 2000. [ALCH01] J. Altmann, K. Chu, “A Proposal for a Flexible Service Plan that is Attractive to Users and Internet Service Providers”, Proceedings of IEEE INFOCOM 2001, Anchorage, USA, April 2001. [BBCD98] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, “An Architecture for Differentiated Services”, IETF RFC 2475, December 1998. [BERN00] Y. Bernet et al., “A Framework for Integrated Services Operation over DiffServ Networks”, IETF RFC 2998, November 2000. [CLAR96] D. Clark, “Combining Sender and Receiver Payments in the Internet”, Telecommunications Research Policy Conference, October 1996. [CZZS00] G. Carle, S. Zander, T. Zseby, “Policy-based Accounting”, Internet Draft, March 2001. [FADL00] M. Falkner, M. Devetsikiotis, I. Lambadaris, “An Overview of Pricing Concepts for Broadband IP Networks”, IEEE Communications Surveys, Second Quarter 2000. [HBWW99] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, “Assured Forwarding PHB Group”, IETF RFC 2597, June 1999. [HUST00] G. Huston, “Next Steps for the IP QoS Architecture”, IETF RFC 2990, November 2000. [JANP99] V. Jacobson, K. Nichols, K. Poduri, “An Expedited Forwarding PHB”, IETF RFC 2598, June 1999. [MIHR91] C. Mills, D. Hirsh, G. Ruth, “Internet Accounting: a Background”, IETF RFC 1272, Nov. 1991. [NBRO94] N. Brownlee, “Accounting Requirements for IPng”, IETF RFC 1672, August 1994. [NICA01] K. Nichols, B. Carpenter, “Definition of Differentiated Services Per-Domain Behaviors and Rules for their Specification”, IETF RFC 3086, April 2001. [WOLI00] A. Wolisz, “The Dual Approach to Internet Charging”, Internet Economy Workshop, Berlin, Germany, May 2000.
