Measuring and Billing User Internet TrafficJ-Ch. Gregoire

INRS-EMTMontreal, QC, CANADA

Email:gregoire@emt.inrs.ca

Abstract—Many Internet Service Providers, as part of adeclared policy to control the impact of the growth of Internettraffic on their infrastructures, have started billing their usersper volume transferred. Such a policy raises a number of issueswhich we present in this paper. For the most part, users areconfronted with a bill which they cannot easily reconcile withtheir day to day use of the Internet.

Based on an experiment in reconciliation between data sup-plied by the ISP and measured by consumers, we discussthe many difficulties which arise to procure user–meaningfulmeasurements. We analyze their cause and possible workarounds.An example of a new service infrastructure is presented tostudy how that problem can be treated. Practical deploymentconstraints are also discussed.

We then review the inadequacy of the state of the art in guar-anteeing predictability and fairness and present possible avenuesfor remediation, based on better information and feedback forthe user, and possible education in better uses of the Internet asa consumable resource.

Index Terms—Internet traffic, Internet user traffic measure-ments, Internet usage billing, charging fairness.

I. INTRODUCTION

In many countries, Internet Service Providers (ISP) havemoved away from a flat-fee, pipe-size model of pricing Inter-net access to new formulas where volume transferred becomea factor in billing. This usage billing is meant to help fundingthe deployment of more Internet bandwidth, due to the steadyincreases in Internet traffic, with promises of larger increasesin the future mostly related to video streaming. Withoutchallenging such claims—or comparing crystal balls—it is stillworthwhile to explore the implications and even the relevanceof such measurements.

Usage billing indeed introduces critical issues, which weexplore in this paper. Specifically, we, as customers, want toknow what is measured in terms of volume and how accuratesuch information can be. We would also want to know howpredictable it can be, in terms of constantly evolving usagepatterns. Beyond customer concerns, we must also explorehow such practices are compatible with emerging serviceplatforms such as IP/TV or IMS.

A major issue we present here is that consumption numbersare inconsequential for average users, who typically wouldhave no sense of what the IP protocol, or packets, are. Moreand more, the use of the Internet is viewed as access toservices, supplied by different content or service providers.The billing information received from the ISP is hard toreconcile with this perspective. While a disconnect betweena service view and an IP view of the Internet by the general

public is hardly new, the introduction of usage billing bringsthis issue to the forefront.

In this paper, we begin by exploring the detailed moti-vations presented by ISPs to justify the introduction of thisnew form of billing. We then describe an experiment in themeasure of user traffic and discuss the pitfalls of reconcilingmeasurements with numbers produced by the ISP. The resultsof this experiment lead us to a discussion of the majorissues related with usage billing. We then present models forbilling in service–oriented infrastructures and analyze howthese perspectives—network and service—can be reconciledin the Internet of the Future. We conclude with a user–centricperspective of the major concerns which must be addressedwith this form of billing.

II. BACKGROUND

Charging for Internet access is an old issue, which washeavily discussed in the early days of the web (see, e.g. [8]).[3], expanding on the experience of earlier projects includingCA$hMAN [4] and M3i [5], provides a good survey of dif-ferent approaches to achieve it. But the industry has shownlittle interest in academic research on this topic and takena different path which, rather than looking into the value ofspecific flows, takes a more holistic view of user traffic. Aftera flat fee approach for access, followed by a discriminationbased on the size (i.e. bandwidth) of the access pipe, ISPshave introduced another factor in the way they charge users.

Why did ISPs start to charge for volume? The followingquote, taken from a tariff application 1 filed to the Cana-dian Radio-television and Telecommunications Commission(CRTC), the agency regulating telecommunications servicesin Canada, gives us an official perspective.

“9. The present flat-rated pricing structure forGateway Access Service (GAS) is no longer appro-priate, in light of trends in Internet usage and theimpacts that such usage is having on the Companies’networks. . . . , the Companies noted that Internettraffic has grown exponentially and such growth isexpected to continue. . . . . Indeed, the key driversof rapidly increasing demand for Internet usageinclude entertainment video from providers such asYouTube, Amazon, Netflix, Blockbuster and Apple;and business usage for video conferencing. These

1Associated with Bell Aliant Tariff Notice 242 and Bell Canada TariffNotice 7181.

and other growth factors currently, and will continueto, strain network capacity. The Companies furthernoted that a small number of users were generatinga disproportionate percentage of the total traffic onthe network.

10. The current price structures were not de-signed to handle this dramatic increase in demand.As a result of this strain on network capacity, theCompanies have adopted a three-pronged approachto managing capacity on their networks. That ap-proach consists of: i) investing in capacity throughmanaged capital spending; ii) moving toward usage-based pricing and new business models in a mannerthat benefits end-users and takes into account therealities of the highly competitive marketplace; andiii) managing bandwidth. Despite the Companies’efforts to augment their network capacity to managecongestion and meet the skyrocketing demand forbandwidth, the demand for bandwidth to provide ser-vices such as the entertainment and business videoproducts discussed above continues unabated. Thenature of the growth of Internet traffic is such thatas network capacity expands, new user applicationsinvariably also grow to utilize that capacity.”

This specific ISP, certainly not an isolated case in NorthAmerica, essentially argues growth in demand, combined withcost of upgrading infrastructures leads it to look at new waysto bill users. It could be argued that earlier arguments on theneutrality of the net, which prevent ISPs from charging basedon the destination of user traffic, may have contributed to pushthem in this direction. But motivation is not an issue here.Table II gives an example of usage charges for DSL access,based on downlink speed. In addition to such charges, ISPswill sell users a form of insurance policy for excess volume,say a flat fee of 5 $ for an extra consumption of 30 GB.

Several observations can be made from this data. Firstthe limits appear quite arbitrary, and, to the average user,rather meaningless. Second, looking at the minimal offer—a maximum of 2 gigabytes of data per month—we canappreciate that an increased interest in, say, watching YouTubevideos can lead to unpleasant surprises. Third, the volumeseems unrelated to the maximum speed: for a factor of 10in bandwidth we have a factor of 30 in volume. We must alsokeep in mind that the speeds indicated are only hypothetical(best–case) and can be lower in practice.

Max. Speed Tariff Monthly Limit Cost per excess GB512 Kbps 24.95 $ 2 GB 2.50 $2 Mbps 34.95 $ 20 GB 2.50 $5 Mbps 49.95 $ 60 GB 2.50 $

TABLE ITARIFF FOR BELL CANADA’S DSL, FROM CRTC BELL NOTICE 7181.

This leads us to ask a number of questions:• What is the traffic measured?

• Is such a measure fair?• How much feedback should the user have?• How can a user adjust her consumption?• Is this model sustainable?

We look at these issues in turn in the following sections.

III. A STORY OF 2 MEASUREMENTS

We have performed an experiment with two ISPs to compareconsumption as measured by the user to consumption asreported by the operators. In both cases, the ISPs supplyinformation on daily usage. We report here the observationswhich were made and the questions they raise, typically withrespect to where in the network measurements are made andwhat they reflect. These measurements were conducted over aperiod of 2 months, although we present only a limited sampleof that data here, representative in volume and variability.

Note that these experiments were not meant to provide uswith statistically accurate information, for which we wouldhave required a large number of different Internet users, butrather to give us information on the measurement process,its relative accuracy and other practical concerns users mighthave.

A. Measuring

User–side traffic counting was done using off–the–shelftechnology, with a FreeBSD–powered PC-Engines board, act-ing as an ethernet bridge between the access modem anda “home router.” The statistics of the interface facing themodem were collected every five minutes via the NETSTATcommand, processed and transmitted in compounded formdaily to a server for storage. We thus retrieved information onvolumes and packets transferred and received as well as packeterrors. Detailed daily information also allowed us to monitorthe evolution of traffic patterns across the day, although thisinformation is not strictly relevant here.

Fig. 1. Measurement Set-up

Figure 1 shows a typical home setup used for our measure-ments; the modem is at the right, the measurement box in themiddle and the home router to the left. The USB key appearingon the measurement box is used to store daily information forbackup. With a 5 Mbps connection, forwarding and accountingtraffic did not present any challenge for our box.

B. A point-to-point channel

The setup: The first collection we analyzed was madeon an Asymmetric Digital Subscriber Line (ADSL) access, de-ployed over a legacy ATM network. Communications betweenthe home and a traffic aggregator box are point–to–point. ThePoint–to–point over Ethernet (PPPoE) protocol [9] is used forframing on top of the ADSL bridge, and, with this specificISP, customers can have up to 4 different PPPoE sessions. IPaddresses are assigned dynamically and change periodically,probably to prevent users from setting up servers at home,although the usefulness of such an approach is limited withservices such as DynDNS.

The measurements: Our measurements, some of whichare collected in table II, have matched the numbers advertisedby the ISP within a few percent. We have to realize that thereis no guarantee that the ISP’s notion of the time zone has tobe your own, and thus some fluctuations from day to day arepossible, although they obviously should even out in the longterm.

We must underline however that during a time period,not presented in the table, numbers no longer matched. Thisperiod appears to have coincided with changes in the ISPuser feedback service. Attempts to investigate this issue withthe ISP (or any other related issue, for that matter) provedunsuccessful.

TABLE IIVOLUME MEASURED (USER) AND REPORTED (ISP) FOR AN ADSL LINK

OVER 8 DAYS.

Measured (GB) Reported (GB) Diff. Pkts1.538 1.547 0.60 % 19228560.665 0.652 -2.00 % 8387345.998 6.014 0.27 % 82787096.490 6.556 1.01 % 106765531.883 1.894 0.59 % 21924193.219 3.245 0.81 % 41452222.087 2.098 0.50 % 24994973.989 3.996 0.18 % 5577749

Curiosities: ISP measurements, in this case, appear to bedone at the “front” of the ISP’s network; that is, at the trafficaggregator. This is quite sensible since such a device wouldmanage the ATM connection or the PPPoE session and havedirect access to the link statistics.

C. A broadcast channel

The setup: The other experiment was performed overcable access in a DOCSIS–based [7] environment. Such anaccess presents a LAN model, hence has natural support forbroadcast traffic as we see below.

The measurements: Table III presents only volume in-formation. As we can see here, volumes are much smaller(number in Mbytes) than in the ADSL experiment, which issimply a reflection of statistics from a less Internet–inclineduser.

TABLE IIIVOLUME MEASURED AND REPORTED FOR DOCSIS ACCESS, OVER 8

DAYS.

Measured (MB) Reported (MB)92.9 33.35

458.28 344.7629.301 119.5128.68 0.09

27.711 0.0929.821 0.0931.051 0.09136.97 105.55

Curiosities: The numbers average to daily differences ofabout 29 Mbytes, traced down to various forms of broadcastcommunications, mostly ARP requests sent by the cable head-end node, for which the user was not billed. Investigationhas confirmed though that these measurements indeed “front”like ADSL links 2. We have also observed that the otherwiseDHCP–assigned IP addresses remained stable over weeks,which supports the assumption that they were used to identifythe user deeper within the ISP’s network. We shall come backto this issue.

We see small values (0.09) in the reported volumes used.They are supposed to be the consumption on days when theuser did not use the Internet at all, and reflected both uploadand download traffic in an 8/1 ratio. Such traffic can consistof DHCP lease updates, NTP and DNS traffic.

We also see the effect of a time offset, i.e. when a 24 hourcycle starts, in this set of measurements. The measured valueof 458.28 is balanced over two values reported by the ISP,344.76 and 119.51.

D. Discussion

“Front” or “remote” measurements reflect a difficulty for theprovider: what is measured may be too tied to the technologyand not to a specific goal. Let us consider figure 2. Wesee there 5 different network areas, including the Internet.Measuring traffic for the user area creates difficulties when thenetwork provider also acts as a service provider (e.g. email,Content Delivery Network a la Akamai) and wants to sellcontent, from area 3 or 4 (partner provider, with favoured orno billing) to its customer, which would be billed under adifferent model e.g. subscription for television programmessupplied with IP/TV. The user will not accept paying twice—per content and per volume. Resolving such matters can bedone by a billing system, but at the cost of some complexity.

Furthermore, some almost perverse effects can occur in thiscase. For example, customers of some ADSL–inclined ISPhave reported on public blogs that they were charged for trafficexchanged between computers within their own homes, eachset up over a different PPPoE session, a clearly unfair practiceyet possibly too hard to resolve when the measuring deviceonly looks at a low level pipe and is not aware of routinginformation.

2The ISP apparently uses Cisco devices for this purpose.

User

5

43

21

Partners

Internet

ISP services

ISP

Fig. 2. Different areas

Measuring deeper within the network may mean, on theother hand, that traffic exchanged between users within theprovider’s network may not be accounted for—a possible issuefor peer–to–peer applications.

Furthermore, deeper measurements introduce another diffi-culty: identification. As we have said before, beyond the accesslink, only the IP address can be used to identify the localsource or the destination of traffic. This is hard to do unlessthe user’s address remains stable over a long period of time.Otherwise, complex coordination between different systems isrequired.

E. To summarize

Through these experiments we have exposed a bit of aconundrum for the ISP. Since the argument (presented insection II) is that usage billing is required to pay for thegrowth of the Internet traffic, then only traffic exchanged withthe Internet should be billed to the user, rather than all trafficmeasured on the access link which can include Triple Playtraffic from zones 3 and/or 4. Yet isolating this specific trafficseems to be challenging. So the issue we find at this level isnot whether or not the measurement is correct, but what doesit really account for and should all traffic be accounted thesame way. For the customer, this is clearly about fairness.

IV. THE CUSTOMER’S PROBLEM

The user faces a different challenge in monitoring andunderstanding her consumption: what do the numbers mean?Considering that volumes of IP traffic are billed to the cus-tomer, how can such numbers be related to specific activities?Predictability is key.

A. User Traffic

Let us consider the following application categories, andthen analyze their behaviour:× Classical Email, chatting.× Streaming Viewing videos from sites such as YouTube

or TV stations web sites, or also listening to radio overthe Internet. Browsing photo albums could also fit inthis category.

× Cloud Various in nature, we typically consider Google–style tools, but also other services such as backups.

× P2P File sharing applications.× Invisible Operations which occur in the background

which the user may not be aware of, such as systemsupgrades.

It can be argued that volume will, at least, not be related toclassical applications, but this still leaves many applications.The question then becomes, is the volume predictable? Let us,for example, consider streaming.

TABLE IVSTREAMING VIDEOS

TV station YouTubeVolume (Mbytes) 150 14.673

Duration 11 min 6 minRate Mbytes/min 13.62 2.46

Streaming: Table IV show the difference between thevolume of two arbitrarily chosen videos, one picked from theweb site of a TV broadcaster, the other from YouTube. Thesevideos have been produced with different criteria in mind:In the first case, quality is important whereas, in the second,volume is more critical. This results in a ratio of about 5.6 involume between the two (on a per minute comparison basis.)

The lesson here is the unpredictability of the volume. Auser will not reason about quality of video, nor necessarilyeven keep track of the number of shows she watches over anevening.

Peer to peer: The challenge posed by file sharing applica-tions is the symmetric character of the exchanges. Data is notonly downloaded to the computer, but possibly also uploadedfrom our computer to another, which increases volume trans-ferred. To illustrate this consider that, for the video transferswe have just mentioned, for each thousand bytes received, wewould send about 28. For sharing applications, this ratio couldbe anything, from that number to the complete opposite.

Invisible: We may at some point receive a messagefrom our computer notifying us that it is time to reboot ourcomputer to install upgrades or fixes to our system. How bulkywere they? How many times will such transfers be repeatedacross households? By the time we receive such notifications,transfers have already happened and we can no longer doanything about them.

User help: Some service providers supply tools to helpestimate how much usage volume is required based on hoursof viewing per week. Based on categories of usage (light toheavy) and examples, they allow customers to compute a totalusage. They would thus discriminate between watching a TVprogramme and watching videos.

Still, such tools put the onus on the customer to be able topredict usage, possibly for a whole family, which can be quitedifficult to achieve and does not allow for whimsical changeof habits. They may also not account for applications whichISPs may frown upon, such as peer to peer, or evaluate thecost of upgrades, which are hard to predict.

B. Real-time Feedback

Since usage, and the related traffic, have such variability,and hence little predictability, another approach is to providecustomers with feedback. Two different approaches are possi-ble: user-based or provider-based.

Monitoring applications: It is quite easy to find applica-tions, commercial or shareware, which monitor the computeron which they run to keep track of the use of networkconnection, and the related applications. They have a coupleof limitations, however: they run on a single machine, andthus do not meet the needs of a family, and furthermore, asbrowsers are used to carry a large variety of different traffic,they may not be able to provide a deep enough view of thenature of the usage.

Provider: ISPs can, and do, provide tools to report onusage on a daily basis. There is certainly a trend to movethese reports closer to real-time. For example, we have seenan ISP move from a 2–3 days later model to now offering 2hour old data. This new model, while being cumbersome touse, makes it easier for users to avoid crossing a usage limit.

Inasmuch as the provider can communicate with its Cus-tomer Premise Equipment, and depending on the degree ofintelligence of that device, it is also possible to consider usingstandard network management–based mechanisms to extractusage information in close to real time.

C. To summarize

Usage is largely unpredictable and difficult to monitor,especially with family situations with home networks. Whilebetter feedback from providers is a step in the right direction,the current model appears quite inflexible especially in viewof constantly changing usage patterns of the Internet.

The ISP billing model based on a hard limit and aninsurance policy is also rather arbitrary since it does not matchnormal usage patterns, nor does it encourage better ones. Forexample, since some times of day are worse in terms ofcongestion on the Internet links, as justified by the introductionof throttling, there could be a (financial) incentive to movesome mass volume traffic to better (i.e. less loaded) times.Some operators do apparently offer this form of incentive.

V. SERVICE INFRASTRUCTURES AND CHARGING

Rather than an IP–level consumption view of the Internet,an application–level one would seem to be more appropriate.Such a view is required for new media–based applications, andwe can study from a practical example how such accountingcan be achieved, and at what cost.

A service infrastructure answers some practical concernsfor charging by introducing mechanisms for, among otherissues, user identification, admission control, quality controlon content and delivery. As such concerns were associatedwith older, stovepipe telecommunication services, it was tobe assumed that providers would attempt to adapt and adoptthem for the Internet. We look here at a specific exampleof a state–of–the–art infrastructure to better understand howdifficult such deployments prove to be.

A. A service infrastructure

We choose the IP Multimedia Subsystem [1] as an example.It is a service architecture created by the 3rd GenerationPartnership Project (3GPP) for the needs of mobile IP-based

telephony and has later been adopted by other standard bodiessuch as TISPAN and PacketLabs to be also used over legacy(ADSL, Cable) access networks. We do not need to concernourselves with IMS in too much detail here, since our focusis how charging is integrated in the architecture.

One major benefit of IMS is it is designed around asignalling protocol, SIP. In broad terms, service requests arerouted through specialized switching nodes (CSCF) until theyreach another user, or a service node. Signalling will help setup a path for a media flow, which may or may not follow thesignalling path.

In IMS, billing [2] is based on customer data records(CDR), generated by a network element for the purpose ofbilling a subscriber for the provided service. A CDR identifiesuser, session, the originating network element and also somedetails on the resources used to support the session. CDRsare collected from all network elements by specific serversand specific fields in the SIP header identify these servers(P-Charging-Function-Addresses) and the billable entity (P-Charging-Vector), with enough flexibility to distinguish thelatter from the user. P-Charging-Vector uses a specific iden-tification called the IMS Charging Identifier (ICID). As allnetwork elements received this information from the signallingflow, it is guaranteed that they all share the same, consistentinformation and do not need to consult other nodes, therebyreducing their processing overhead.

IMS charging operations also include provisions for on–linecharging and transmission of tariff information through SIPheaders. CDRs received by the Charging Data Function areprocessed and sent to the AAA server, with possible exchangesof information between domains.

B. Key Issues

This brief view of the IMS operations show essentialelements to assure proper charging to users:

• Means to identify users.• Means to associate usage with applications.• Means to collect information from different areas in the

network, and possibly also partners.• Means to disseminate tracking information to all relevant

processing nodes.

We see how such means are lacking in the current Internetwhere IP addresses are used as identifiers and measurementsare made at the IP level, unrelated from applications. Finally,information collection is done on a single device which forcesthe measurement to be done at the “front,” or at least closeenough to it to guarantee that all user traffic can be monitoredconsistently as such processing is harder to do deeper in thenetwork with higher volumes of traffic.

There are however clear drawbacks to the use of signallingfor all its established benefits, especially in terms of admissioncontrol. It requires specific applications and, short of introduc-ing relays, is not compatible with dominant Internet protocolssuch as HTTP.

VI. DISCUSSION

We have clearly identified that we have two issues tocontend with: predictability of Internet usage and fair usageassessment.

A. On fair usage assessment

Short of having a signalling protocol, we see that it ishard to consistently collect charging information. The quasisystematic use of browsers and the web protocol to accessservices complicates matters further: lightweight (i.e. email)to heavyweight (i.e. video) applications are accessed in thatfashion.

Nevertheless, while we cannot fault ISPs for billing forusage, nor for the accuracy of their volume measurements,the problem remains that what is billed is flawed, fromthe perspective of their declared motivation as presented insection II, as well as in terms of what is billed, as we haveamply demonstrated.

Since the crux of the justification for billing is based on thegrowth of Internet video traffic, as we have seen in section2, traffic exchanged with area 5 in figure 2 should be thefoundation for usage measurement, rather than traffic on theaccess link. The challenge then is to find ways to perform suchmeasurements reliably and also offer users means to monitortheir usage.

Interestingly, ISPs have taken means to control that traffic,for example with Content Delivery Networks (e.g Akamai,or Google’s own), but support for streaming in such modelsremains limited. They also do not apply to P2P traffic.

There appears to be technical limitations due to the nature ofthe devices used to perform measurements and/or the locationwhere it is done. Aggregation devices, for example, maynot be able to perform content-based operations, and devicesfurther in the network have to contend with high volumes ofinformation and little processing capability.

We propose that measurements should be carried out at theuser’s premises, with a breakdown of traffic per destination,and communicated with the service provider for validation andreconciliation (i.e. for fraud prevention). This would resolvethe fairness issue, if not the predictability dimension, andalso resolve computing load concerns on the ISP side. It isactually rather straightforward to expand the functions of ourmeasurement box to that effect.

B. On predictability

Feedback on volume is not sufficient for the customers,no matter how real–time it may be. To make usage morepredictable, breakdown of usage based on applications andsites is required for each home computer. However suchinformation cannot be collected by the ISP, for neutrality aswell as practical reasons, and must be performed in the home3.

We have already mentioned the existence of tools which cancorrelate application–usage information on computers. Such

3Actually not unlike the (sometimes “smart”) meters we have for water andelectricity consumption.

tools could be extended to communicate with a central collec-tor, ideally located on the home router, as a natural extensionof the measurement functions we have just mentioned.

VII. CONCLUSION

This review of issues of contemporary Internet technologyand pricing leads to a number of observations.

Not all usages are created equal: We can distinguishprovider–based services from Internet–based ones. Is it normalto pay for mail usage if the provider supplies this service aspart of its basic package?

Usage billing based on volumes is unfair: It does notappear to directly address the issues that it claims to try toresolve.

Feedback on usage is lacking: Users, especially in familysituations, cannot readily relate their bill to their daily practice.Even if providers supply tools with up–to–date information, itis unrealistic to assume that people will have their eyes on themeter at all times, especially if several people are active at thesame time.

Complexity of signalling: While signalling–based ser-vices can help with the problem, the implications of movingapplications to such a model is high, and has not been verysuccessful so far. This does not seem to be an avenue for asolution in the current Internet.

Better usage: In analogy with telephony, we could imag-ine that ISPs would offer incentives to help to move someusage, such as upgrades or backups, to a more suitable timeof day. Some creativity will be required in that respect.

Middle ground: We believe that usage billing is a coun-terpoint to the net neutrality debate, in the sense that, sinceoperators cannot discriminate between different traffic/content,they can always charge back the customers, indiscriminately.

We argue that there is a need for a middle ground betweenthese extreme situations. Minimally, it should be possible forthe provider to charge only for traffic leaving its network,but even such a simple task seems difficult to accomplishwithout dedicated technology. Cooperation between customerand provider through customer–premises equipment appearsto be the more realistic avenue at this point, and is readilyachievable, as our experiments would indicate.

There remains to consider how such considerations willstand the test of time and the evolution of the Internet. Whereasearlier studies have exposed many different ways to bill usersfor Internet access, recent trends have all been to move to a flatfee, with extra incentives for user to control the usage either byrestricting themselves, or modifying their usage patterns. Wewould predict that this last point will be a more importantfocus in the future. Operators will have to walk the linebetween getting the revenues they need to sustain the growthof the Internet, while not taking the chance of stifling thatgrowth.

REFERENCES

[1] “3rd Generation Partnership Project: Technical Specification GroupServices and System Aspects; IP Multimedia Subsystem (IMS), Stage2”. 3GPP TS 23.228, V9.3.0, Mar. 2010.

[2] “3rd Generation Partnership Project: Technical Specification GroupServices and System Aspects; Charging management; IP MultimediaSubsystem (IMS) charging Stage 2”. 3GPP TS 32.260, V9.2.0, Dec.2009.

[3] C. Courcoubetis, R. Weber, “Pricing Communication Networks: Eco-nomics, Technology and Modelling”, Wiley, 2003.

[4] “Charging and Accounting Schemes in Multiservice ATMNetworks (CA$hMAN)”, European ACTS (AdvancedCommunication Technologies and Services) project 1995–1999,http://www.statslab.cam.ac.uk/ frank/cashman.html, last accessed May15, 2010.

[5] “A Market Managed Multi-Service Internet (M3I)”, European5th FWP (Fifth Framework Programme) project 2000–2001,http://cordis.europa.eu/fetch?CALLER=PROJ ICT&ACTION=D&CAT=PROJ&RCN=54480,last accessed May 15, 2010.

[6] CRTC, “Bell Canada Tariff Notice 7181”, March 2009.http://www.crtc.gc.ca/public/8740/2009/b2/1043233.zip, last accessedMarch 28, 2010.

[7] CableLabs, “Cable Modem to Customer Premise Equip-ment Interface”, Specification SP-CMCIv3.0, Mar. 2008,http://www.cablelabs.com/cablemodem/specifications/specifications30.html,last accessed March 31st, 2010.

[8] J. Mackie-Mason, H. Varian, “Pricing the Internet”, In Brian Kahin andJames Keller, editors, Public access to the Internet. Prentice-Hall, NewJersey 1995.

[9] IETF, “A Method for Transmitting PPP Over Ethernet (PPPoE)”, RFC2516, Feb. 1999.