Billing Approaches
From a business perspective, multiple billing options are possible; some of them are described in the following sections. The classic billing started with the invention of telephony, a combination of time- and distance-based. Alternatives are volume-based billing, flat rate, service-based billing, and departmental charge back, which is more relevant for enterprises.
Common to all scenarios is the requirement to recognize the user. A user can be an individual identified by a name and password during logon, such as at a dial-in server or web portal. From an Internet service provider's perspective, a user can be anything behind a router interface. In this case, collecting the MIB interface counters is an appropriate approach for billing. Alternatively, a user can be represented by an IP address where accounting techniques such as NetFlow can meter the user transactions. The same applies for Layer 2, where a MAC address represents an individual host.
The time stamp is a distinguishing parameter for accounting techniques, because it identifies a transaction's exact start and stop times. If the billing model requires a time stamp for each operation, the accounting from NetFlow, RADIUS, and TACACS+ are the solutions of choice. If time granularity is not required for each operation, an accounting mechanism based on MIB polling is an alternative. Indeed, the level of time granularity from MIB counters is based solely on the polling time: if polling occurs more frequently, the time granularity increases. Assuming an adequate SNMP polling time, the accounting information can be retrieved from the interface counters (Interface MIB), from the RMON MIB, from the BGP Policy Accounting MIB, and from the IP Accounting MIB.
It is important to note that the different billing categories described here are not mutually exclusive; they can be combined. For example, destination-based billing can be combined with time-based billing.
Time-Based Billing
Time-based billing originated with classic telephony, but it is not limited to that application. New services such as public wireless LAN (pWLAN) access and dial-in services apply time-based billing today. The focus of time-based billing in traditional cellular voice networks (GSM) is outside the scope of this book. However, from the perspective of the current trend toward Fixed Mobile Convergence (FMC), the described data collection methods are becoming relevant.
pWLAN
If you want to download your e-mails at an airport lounge or in a hotel room, chances are good that the charging scheme is time-based. For example, perhaps Internet access is granted for one hour and costs $5 or $20 for a full day. After activating the wireless network adapter, a DHCP server provides an IP address. After you start the browser, an HTTP redirect command points you to the provider's web kiosk, where you choose the amount of online time and pay by credit card. The timer counts down, independently of user activities, and at the end of the purchased time, the connection is cut off.
Dial-In
Even though pWLAN can be considered the successor to dial-in services, dial-in services still exist as an alternative at locations without wireless coverage. The concept is simple: A user dials into an access server that has multiple phone lines. The access server connects to AAA server (usually RADIUS), where the user is authenticated and authorized. The access servers collect accounting details, which are stored on the AAA server. User credentials can be stored on a local RADIUS server or a central directory server. As users provide a username and password, the provider can aggregate them on a monthly basis. This approach requires the user to preregister with the provider. An alternative is to charge for each call. The user pays a higher access fee to the phone company, which gives a percentage of the fee to the service provider. Chapter 9, "AAA Accounting," explains the AAA concept and RADIUS in detail.
Volume-Based Billing
In contrast to time-based billing, volume-based billing accounts for the total transmitted and received traffic. The most common use-case scenarios are residential broadband access and service provider peering agreements. A relatively new area is peer-to-peer (P2P) traffic. Although some providers try blocking or rate-limiting P2P traffic, evolving the business model and deploying P2P-based services is probably a better option. Subscribers pay for the bandwidth usage and as a result get satisfying service.
Residential Broadband Access (DSL or Cable)
DSL providers and cable operators offer multiple tariffs, from a starter package that includes, for example, 1 GB of traffic per month up to a flat rate for professional users. Combinations of volume- and time-based billing are possible. For example, a provider might offer a package with 8 GB of traffic and 100 hours of online time per month. Additional time and volume are charged for separately.
Multiple metering techniques are applicable in this scenario. Digital Subscriber Line Access Multiplexers (DSLAM) and cable modems have MIB counters on each subscriber interface. These are frequently polled by the accounting application, which consolidates data records and sends them to the billing application afterwards. For cable environments, a performance management solution is being developed at the IETF in the IP over Cable Data Network (IPCDN) working group, which develops MIBs for IPCablecom/PacketCable and Data Over Cable Service Interface Specification (DOCSIS). RFC 4639 defines the DOCSIS MIB and obsoletes RFC 2669. The CISCO-CABLE-METERING-MIB offers an interim solution on platforms that do not yet support RFC 4639. Accounting for billing is addressed by the DOCSIS 2.0 SP-OSSI (Operations Support System Interface) specification, which defines the Subscriber Account Management Interface Specification (SAMIS). The Internet Protocol Detail Record (IPDR, http://www.ipdr.org) organization provides an industry standard for IP-based usage data records. It can distinguish on-net versus off-net traffic, which is also relevant for destination-sensitive billing. The SAMIS specification is based on the Business Solution Requirements (BSR) specification version 3.5 from IPDR.
Alternatively, NetFlow can be leveraged at the provider edge router. Although this offers flexible charging, it requires a fixed IP address per user. Otherwise, additional overhead for correlating users to IP addresses occurs. To generate billing data, NetFlow records need to be correlated with the user information, such as IP address, router interface, or CPE device.
Both IPDR and NetFlow version 9 offer reliable export. IPDR takes it a step further with built-in application-level acknowledgments. Although this has a potential memory impact on the network element, it guarantees reliable delivery of accounting records, even in case of connectivity issues between the device and application.
Transit and Peering Agreements
Both peering and transit agreements describe formal contracts between service providers for exchange of traffic. Historically, a transit agreement refers to a scenario in which voice calls originated in operator A's network, are carried across operator B's network and potentially other operators' networks, and are terminated in operator C's network. Figure 17-2 illustrates this approach.
Figure 17-2. Transit and Peering Agreements
In case of a transit agreement, each party pays a fee to send traffic into the other's network. Either A pays B and C separately (direct accounting) or A pays B and B pays C (cascaded accounting). The concept of transit and peering agreements is described in more detail in Chapter 1.
A peering agreement (also called an interconnect) is a bilateral agreement that describes the reciprocal traffic exchange between two provider networks. Because transit costs are a major operating expense for ISPs, peering agreements are a way to reduce costs. In Figure 17-2, traffic from customer 2 to customer 3 can be transported through provider B's network, resulting in transit fees. If C and D sign a peering agreement, they avoid the transit costs. A peering agreement is most economical for equal parties if the amount of traffic is almost the same in both directions. In contrast to transit, both parties agree to exchange traffic without a fee. Therefore, only the total amount of traffic in both directions per day or month is relevant to verify that the peering agreement still reflects the traffic characteristics. Even though transit costs can be eliminated in the preceding example, this is a corner case and is not meant as a general assumption. Metering techniques such as Interface MIB counters, IP Accounting, and BGP Policy Accounting are examples for this use case. If an ISP uses a Layer 2 interconnection (Internet Exchange Point), accounting records including MAC addresses need to be collected. Techniques such as IP Accounting for MAC addresses and NetFlow offer metering of Layer 2 MAC addresses. The related technical details are explained in Chapter 6 for IP Accounting and in Chapter 7 for NetFlow. Alternatively, BGP Policy Accounting, described in Chapter 8, allows the accounting per traffic index, which can be set per BGP peer.
Destination-Sensitive Billing
Charges for Internet access are usually based on the total volume or flat rates, not on the traffic destination. This might not be the most profitable billing model for service providers, because it is more expensive to transport traffic over long distances than short distances.
The ISP needs to find a balance between the two options. Setting the price too high for the total volume or flat rate drives away customers, but setting the price too low reduces the margin. The right balance is a bet on the percentage of traffic that stays within the ISP's perimeter and that is sent via other providers and creates transit costs.
An alternative is the destination-sensitive billing approach, in which charging is based on the traffic's destination. However, this model is difficult to sell for Internet traffic, because the location of servers is usually unknown to the user. Instead, a provider can offer destination-sensitive billing for specific services, such as voice over IP.
Another example is an ISP offering VPN services to Enterprises, with a low price for traffic within the provider's scope (usually in-country) and a higher rate for traffic that is delivered via another ISP. This business model is appropriate for an ISP, because transit traffic generates additional costs.
For ISPs offering MPLS VPN Carrier Supporting Carrier (CsC) services, distance-based billing becomes relevant. MPLS VPN CSC is an MPLS feature that allows a service provider to act as a transport network for other MPLS networks. The fact that traffic crosses multiple providers is transparent to the end customer; however, the costs need to be aggregated from these multiple providers. MPLS-aware NetFlow is the preferred accounting technique in this environment.
Relevant accounting techniques for destination-sensitive billing are BGP Policy Accounting at the network element. Note that Flexible NetFlow offers traffic aggregation per traffic index; these are the same indexes used by BGP Policy Accounting. Therefore, NetFlow can be used as an alternative to BGP Policy Accounting, with the advantage of extra information elements.
Time- and Distance-Based Billing
For completeness, the time- and distance-based billing option is mentioned here. However, it applies to the legacy telephony environment, in which phone calls are charged based on the call's time and duration and the distance, such as local calls, national calls, and international calls. This model is well known and therefore is not covered in more detail here.
Service-Based Billing
Instead of the "one size fits all" model, billing can be applied per service. An example is differentiated Internet access, offering a best-effort class and a business class with guaranteed service parameters. At the application level, access to selected servers can be free, whereas value-added services require a subscription fee or charging for using the services.
Figure 17-3 illustrates a typical scenario for broadband access in a hotel or at a public hotspot. The user turns on his or her PC or PDA, connects to the wired or wireless network, and starts the browser. For user authentication, HTTP redirection to the web portal's login page takes place. Without any related fees, the user can access the "open-garden" content, such as the provider or hotel's web server. For Internet access, the user logs into the portal and is authenticated and authorized, either by credit card, the hotel room number, or prepaid access cards. In addition to Internet access, the provider can offer value-added content services, such as financial data, music downloads, or video on demand (VoD). These services are offered in the "walled garden" and are charged for separately. The key network element in this scenario is the Service-Selection Gateway (SSG), a Cisco IOS-based feature that works in conjunction with a service management application. It enables users to access different services based on their connectivity or profile with the providers. SSG provides RADIUS authentication and accounting per user and supports prepaid and postpaid billing models.
Figure 17-3. Billing for Service Selection
Video on Demand (VoD)
Video on demand is an example of service-based billing, in which a user has broadband Internet access and selects additional services.
The video service can be provided directly by the ISP or by a special content service provider. In case of two separate providers, they can cooperate to increase customer satisfaction, such as by automatically increasing the bandwidth during a video transmission. Alternatively, the ISP can offer a "turbo button" that users can use to increase the bandwidth ad hoc for a certain amount of time.
On the technology side, the provider's web page offers a service selection function. The user chooses a video and pays for it, and a unicast transmission starts. Alternatively, a user can join a live broadcast, such as a football game, concert, or business videoconference. In the scenarios, the user's PC gets an IP multicast address and joins a multicast video transmission.
In the case of the increased-bandwidth option just described, the service-selection server needs a link to the Network Management System's (NMS) provisioning application, which then modifies the link bandwidth parameters for an individual user immediately or at a later scheduled time.
Enterprise Departmental Charge Back
Even though this option is not a real billing solution, it is described here because several enterprises have deployed an accounting solution for charging departments. The idea is to offer a fair assignment of costs to the users and departments. Because intranet access usually has fixed costs, the charge back needs to be related only to the cost of Internet access. This is relatively simple to implement; however, it requires an accounting technique at the Internet access router that identifies the user, such as NetFlow does by collecting the IP source and destination address per flow. Afterwards, the accounting records are aggregated for each month and are assigned to users or departments.
A prerequisite for this solution is a unique assignment of IP addresses to users to identify them by their IP address range. This can be a fixed association, such as the association of the PC's MAC address to an IP address at the DHCP server. Unfortunately, this scenario does not apply to roaming users, because different locations use different IP address ranges. Alternatively, a link between the DHCP and DNS server can associate a unique DNS entry per user, which is independent of the IP address. In this case, the NetFlow collection server needs to replace the IP address in the flow records with the DNS name. The Cisco NetFlow Collector can perform this action immediately when a flow record is received.
NetFlow also supports MAC address accounting at the device level, so it could be used as an alternative. However, the total number of gathered data records could be huge.
Flat Rate Billing
A flat rate is possible with all the scenarios just described. In general, this is not the operator's preferred choice, because time-, volume-, or destination-based billing can generate more revenue. However, providers have to find a balance between pricing and implementation costs. In some cases, such as per-transaction charging, the costs of deploying and operating a complex accounting and billing solution are so high that a flat rate is the best option to make a service profitable. An example is a VoD service where customers subscribe to the service, pay a monthly fee, and watch as many movies as they want.
Alternatively, a provider can offer a flat rate for best-effort traffic combined with volume-based billing for business services that have guaranteed service level parameters, such as bandwidth, latency, and jitter.
