Service provider takeaway: Most of our tips provide technical know-how and advice on how to provide the best networking services to your clients. But how should you charge them for your work? In this book excerpt from Value-added Services for Next Generation Networks by Thierry Van de Velde, you will learn the appropriate charging and rating for the networking services you provide.
As the CFO of our ngvas.com next generation network service provider would say, of course it is required to develop tariff plans and payment methods, for either true communication services or for the transmission of stored media.
But tariff plans alone should not become the primary concern of a communication service provider's marketing department. The excess of creativity in this area results in a general sentiment of unfairness and alienation, rather than in a trusted and valued brand. The initial early adopters do not switch to the new tariff plans, promotions and payment methods, and feel left behind.
And the name of the game is customer ownership. Once this high quality customer relationship is created (the "account"), several services may be sold through it: connectivity, communication services, and even content, physical goods and other services than communication.
Inventing and implementing charging and billing schemes for too many of these could eventually again turn into a digression.
The purpose of this chapter is not to make a sterile overview of charging and rating systems used by today's communication service providers, nor to try and compare them or provide migration advice. The fact that the world is moving to real-time rather than batch processing, for example, is an example.
Let's first try and build a set of essential definitions, and then examine the likelihood for future communication means to require a product catalog, charging, rating, metering, advice of charge, redirection, billing, promotions, openness and/or correlation.
5.1 Product Catalog
Since the mid 1990s, mobile service providers have multiplied the number of new "product" offers -- merely corresponding to handset subsidies and tariff plans, rather than to packages of value-added services. It is as if petrol companies would have subsidized new cars, and invented various packages containing a monthly mileage or a number of gallons of fuel. Plus a higher price per extra gallon, plus a more expensive rate if you would fill your tank at competing petrol stations (roaming).
New, more competitive product offers were launched to grab extra market share, without inviting the earlier subscribers to migrate from the old products. This created a situation with sometimes more than 100 tariff plans on a single network.
In such an environment, it is impossible to launch any new service to the existing subscriber base. Any new service offer results in doubling the number of products, as each product now exists in a version without and with the new service.
A well-structured product catalog should be at the heart of any modern communications company. All processes within a communication service provider (rating, charging, billing but also marketing, retail and customer care) depend on it, and should interact with it in real time. The accuracy and quality of these processes will depend on the quality of the product catalog.
From experience, communication service providers have converged to the following elementary object model of a product catalog. Single-headed arrows represent one-too many integrity relationships, double-headed arrows are many-to-many relationships:
Figure 5.1: A simple object model of a product catalog.
A product catalog defines the offer to the end user, in terms of product types (basic and advanced services) and additional individual options.
The product catalog needs to include information on the compatibility of these individual options (mutual and with the product types). This is illustrated by the many-to-many relationship between product types and individual options. One product type may include multiple individual options, but a particular option may occur in several product types.
The product catalog (product types and options) could be different for each commercial channel — each organization (e.g., residential/business division, reseller, internal test lab) selling communication services to the end users, even if technically all channels are hosted in a single environment. Such system is also called "multitenant."
However, having a dedicated product type for a single customer could be one bridge too far, even toward a large corporate organization. It is then probably better to grant tailored discounts, or maybe promotional rates for on-net communications inside a virtual private network.
Typically, the tariff being applied (e.g., activation fees, periodic subscription fees, source-destination combination, measurement unit, initial charge, subsequent charge per unit) will depend on the combination of all objects in the product catalog:
By which commercial channel was this user acquired?
Which product type did the user select (e.g., gold, silver, vip)?
What individual options did the user subscribe to (e.g., a promotional messaging bundle)?
Which wallet is the user currently using (e.g., an company's shared wallet in the daytime, or an individual wallet at night — see Section 5.2)?
It is thus wrong to attach a tariff plan only to a Product Type.
Over time, a product catalog is a living database and should therefore be fully versioned, indicating the date and time of start and end (past and future dates) of each aspect of the offer, however tiny. When any offer ends (product type, option), it should specify the new offer by which it is replaced (and to which users are thus going to be migrated). This is often forgotten in the design of basic charging systems.
How complex should a product catalog become? In marketing terms, we are looking for the perfect match between a limited number of appropriately positioned products (price, place and promotion) for each customer segment (defined based on their usage of the communication means). Besides the limited number of products (e.g., Silver, Gold and VIP), additional individual options may be purchased or simply selected by the customer (e.g., an insurance for the cell phone, a favorite destination country, or friends and family numbers with lower rates).
Within communication service providers, but in general within many commercial organizations, there's a difficult equilibrium to be found between the mix of product types and the tailoring options. Having too many product types and no individual options usually has a greater impact on the organization (in terms of complexity, cost, training, etc) than having too few product types and too many options.
Ideally, the product catalog should regularly be compared to the subscriber database in order to detect and suppress unpopular product types and options, hence to simplify the offer toward the end user. We'll talk about this in the context of reporting (Section 6.25).
In the peer-to-peer world, the product catalog should be part of the user interface or at least of some central Web site explaining the offer to the peer-to-peer users.
Subscribers and prepaid users of telecom services used to have a lifecycle: preuse, active, dormant, suspended, fraudulent, porting out pending, and so on — please refer to the Section 6.2 on user accounts. Any lifecycle should not also include the current state but the history and future planned states, as of precise dates and time.
A new evolution is that product catalogs are evolving to include a lifecycle and renewal policy also for the product type and for the individual options.
For example, the user subscribing to the cell phone insurance could select to have this personal option starting on the first day of the next month. The option could be automatically renewed each month if there are sufficient funds in the account, or the system could automatically ask for confirmation prior to renewing that option, or the user could opt for a scheme in which the option is suppressed after one month — for example to buy the insurance only to go on holidays.
The tariff implications of that renewal policy is an area that is going to be developed in the coming years.
5.2 Account = User + Wallet
An account is a term for a customer relationship with an end user of communication means, but may also be used w.r.t. a revenue sharing partner (e.g., carrier, roaming partner, application service provider).
Some communication users could demand multiple accounts, even for the same communication events. For example, corporate organizations today want to look at their end users and usage by division, by country, by communications product and worldwide.
The degree of trust should determine the prepaid or postpaid nature of such account, more than type of user or partner. For example, when NGNSP will have thousands of NGN peering relationships, we expect prepaid accounts to appear also for (what is today called) inter-operator accounting.
What is stored in such account is credit, expressed either in monetary or in nonmonetary balances (e.g., minutes, megabits). The balances in an account may be of the debit type (positive values, "prepaid") or credit type (negative values, "postpaid").
Limited credit and single-use (non-rechargeable) balances are the two other types. An account will thus never be 100% prepaid or 100% postpaid. A single balance may be organized in multiple buckets of credit, each with a different validity date (after which the credit is suppressed) or future installment date (as of which the credit becomes usable). A balance thus has no expiration date; it is the bucket which has it.
A good idea is also to group multiple balances into a wallet. An end user could use credit from multiple wallets: a shared company wallet for business communications in the day time, a shared family wallet for international calls to a favorite destination, and a personal wallet for all other calls, for example. The wallet to be used could be determined either by the end user or by the communication service provider, based on the service being used, the destination, time of the week, and so on: a real "wallet usage policy."
What kind of data will we find in the user's profile? In there, for end users as well as partners, we will find the user's identification and contact details, the history or customer care contacts, the lifecycle data, links to purchased options (with their own lifecycles and renewal policies), preferred destinations (e.g., friends and family) and negotiated discounts.
As the user and the wallet together determine the tariff being applied, besides of course the commercial channel and individual options which nevertheless have less effect, the combination of a user and a wallet forms a valid definition of an account.
An account is thus not only a user having selected a product type and options, nor only a wallet full of balances and buckets (credit). It is encompassing both aspects. An account is also not to be confused with a payment channel. Multiple payment channels (an invoicing address, a credit card authorization, a scratch voucher, a bank-to-mobile transfer, etc.) could indeed be used to settle a bill or top-up a wallet.
A scratch voucher could for example be used to settle a postpaid bill. Mobile operators used to implement the user account databases as "Operator Support Systems" (OSS) on one side and "Prepaid Intelligent Network" systems on the other, but there's no reason to make such distinction. A generic "accounts system" would do, and could even be used for reseller/dealer accounts, inter-operator accounting and application service providers.
Are the options specific to a user? Today they are, but one could imagine options on the wallets too. In that sense it is a more future-proof idea to link new options to an account rather than to a user or partner profile.
Charging is the process through which the network delivering the communications service is interacting with the system holding the accounts. In theory, the network should interact with a charging system, which in turn should tap from an accounts system, which would finally consult a product catalog.
In practice it is not easy to define open interfaces between these, so the three functions should remain combined in a same "charging system." The timeliness and speed of this interaction is described in terms as "real-time," "hot," "warm," "cold," but the truly important distinction is "online" versus "off-line."
In online charging, the network consults the charging system prior to delivering the service, and asks for permission and for credit (in nonmonetary units). In off-line charging, the network informs the charging system that the service just got delivered.
Historically the online approach has been more suitable for user charging (retail), as it avoided any fraud in conjunction with prepaid payment methods. With off-line charging, prepaid services could be delivered while the charging system would notice afterwards that the balance was too low to pay for these. The services (calling, texting) would then have to be deprovisioned in the network, and reprovisioned after top-up.
And the off-line approach was preferred for inter-operator accounting (wholesale), as the network could pass more information to the charging system (trunk group being used for the outbound or inbound call) than through the online charging interfaces.
This has lead to a few industrial camps and matching departments within the operators: "Service Nodes" / "Prepaid IN" for online charging; and "Billing Mediation" "Billing Support Systems" for off-line charging.
Today there's no technical nor economic justification anymore to use off-line charging for postpaid (contract) users — except maybe risk sharing. Online charging systems can and should charge every user whether prepaid, postpaid, credit limited postpaid or single use (e.g., a calling card).
The online charging approach remains the ideal target method if it could address inter-operator accounting. However, today we see little evidence that the online charging interface of the next generation network will support this.
Rating is the process of letting the charging process interact with the accounts system and the product catalog to determine the price of a communications event. In general, it happens within the communication service provider's online or off-line charging system. Alternatively, a third party could perform rating if it has its own product catalog (see Section 5.12) but let's for the moment set aside this possibility. All interaction between the network and the charging process is based on nonmonetary units.
As an online/off-line charging process, a product catalog or an accounts database cannot be described in a generic way, it is also difficult to describe the rating process. For online charging, at some point the charging process reserves a slice of credit out of a balance (or multiple balances in a cascade) — a process known as credit slicing. Ideally, the slice of credit is small enough to permit multiple simultaneous services to be delivered with that balance, but large enough not to lead to too frequent charging interaction with the network. The charging process needs to consult the account's product type in order to know which balance cascade to tap from.
If the balance is monetary, inverse rating takes place: the inverse rating process consults the product catalog and determines the total price or the price per unit of the communication event. It transforms the credit slice from monetary to nonmonetary units.
Let's stress that, if all balances were expressed in minutes, no inverse rating would occur in order to charge online for calls! If credit reservation took place, the online charging process then allocates the number of nonmonetary units (e.g., seconds, megabits, clicks) to the network or just gives an acknowledgement ("go" signal). In some implementations of time-based charging, the online charging system just gives a go signal but does not instruct the network to meter the seconds. It runs its own timer and will either tap more credit out of the wallet, or interrupt the call if there's no credit anymore.
The off-line charging process usually does not acknowledge the request for debiting. Rating may occur immediately or much later: looking up the service in the product catalog and transforming nonmonetary into monetary units.
For off-line charging as for online charging, the charging process ends up debiting (lowering) the balance (monetary or not). In conclusion, off-line charging uses rating, and online charging uses inverse rating, only if the balance is monetary.
If, in a NGN, online charging thus became possible for inter-operator accounting, and all balances were expressed in nonmonetary units, no rating would be required anymore!
As described above, the online charging process may allocate the number of nonmonetary units to the network. Usually these used to be the seconds granted by a prepaid IN system (i.e., an online charging process) to a Mobile Switching Center (MSC).
In the last 5 years, however, advanced metering devices have been developed that are able to meter the seconds, kilobits or number of clicks for a wide palette of services and destinations, even within a single mobile data session.
Upon establishment of such session, the metering device retrieves the palette of services to be metered, for a given user, from a central Authorization server. The metering device is also informed whether online or off-line charging is to be applied for each service and/or destination. Some services/destinations could be marked as forbidden (black-listed) or sabotaged (gray-listed; e.g., competitors' applications).
Also, it is made aware what to do with traffic that cannot be recognized as being part of any service/destination ("background traffic"). In the coming years, the palette of services to be metered should probably be merged into a single product catalog. Too often, the definition of available data services have remained separate from the main voice and messaging product catalog.
If the background traffic requires online charging, the metering device obtains a credit slice from the online charging system. When the user/partner accesses a service/destination defined in the palette, the metering device obtains credit (sometimes also referred to as "quota" in this context) from the online charging system, or produces tickets for off-line charging.
Highly granular metering is thus required for both interaction with online charging systems, as well as for off-line charging. It is sometimes referred to as "content charging" but that's an inaccurate description, as content can be charged without metering, by applications (end points) tapping directly from the account (see Section 5.12 on openness).
5.6 Reverse Charging
Most users understand the principle of a toll-free (800) number: the call is free to the caller because it's fully paid by the called party. The decision for the charging system to allocate the charges to the content service provider (the freephone number owner in this case) used to be simple (namely based on the called number range).
That is changing in modern communication services. Let's consider the example of an online game where the game itself is charged per new downloaded game level, and normal GPRS volume charges apply for the nondownload traffic.
The metering device is smart enough (or instructed) not to take into account the game level downloading packets to calculate the volume of the background session — and to modify the background session to become time-based when using WiFi.
If a new game level download succeeds, it is charged to the end user as a unit price. If the user had already successfully downloaded that game but later lost or erased it, the game level can be restored and the gaming user pays only for volume charges — except when on WiFi.
If, however, a game level download is incomplete or unsuccessful, the volume corresponding to that failed download should be charged to the game provider. Again, except when on WiFi.
This small example illustrates that charging decisions are far from being static, and that the communication service provider's charging processes should be in full control of normal vs. reverse charging.
5.7 Advice of Charge
As the complexity of the product catalog and account structure increases, so does the need for clear Advice of Charge (AoC) to the end user, and sometimes explicit acknowledgement or even additional authentication, in advance of actually delivering the service.
In PSTN, toll exchanges completing premium rate calls are able to inform the originating local exchange of the tariff in real time (through signaling). The originating local exchange can then inform payphones of the charges to be applied (16 KHz pulses).
In some countries it is a legal requirement to inform the customer of the tariff of premium rate calls, premium SMS, or to inform the caller that the destination number is ported out (with a warning beep). Metering devices are also able to redirect the mobile data request to an AoC page, or to insert the AoC information in the downlink content.
What will be the price of SIP sessions to various destination domains, worldwide? Increasingly for data services and next generation services, the operator will be held accountable for informing the users and partners of costs, in advance of delivering the actual service. In the NGN standards there's currently no sign of an AoC facility. Early adopters won't bother, but cost conscious users might hesitate to use the services.
As mentioned above, mobile data users are sometimes redirected to AoC pages or popup windows and may explicitly need to agree. In case the metering device does not obtain credit for a service to be charged online, or in case the service is barred, it should be able to redirect the user to an explanation page (autonomously or under instruction of the online charging process).
If the problem is an empty purse, the user should be invited to top-up the credit, and in case of bad debt, to pay the bills. Maybe in some extreme cases, redirection to a human CRM agent (via text, voice or video call) would help?
Billing is the process of producing a bill, an invoice. The input for billing is a set of rated CDRs (i.e., already containing a price) coming out of the charging processes. Today, most operators generate invoices for only postpaid accounts (charged in off-line mode). Prepaid subscribers can get an invoice for top-up events (e.g., for vouchers) but not for usage (calls, messages).
But there's no technical reason to link the production of a bill to the charging mode — that is, billing should be possible in case of online charging too. Prepaid services could appear on an invoice, that is, to allow the customer to pay VAT only on usage, rather than today on the facial value of the top-up vouchers. Top-up vouchers could then be sold without VAT, to customers having a verified billing relationship (name and address).
As for product types and lifecycles, one can wonder whether bills should not be produced regarding a wallet, rather than regarding a user or partner.
The payment methods should not be imposed by the bill. It should be perfectly possible to settle a postpaid bill using a prepaid scratch voucher, ATM reload or bankto- account or inter-account credit transfer — whereas these payment methods are today considered only to top up prepaid accounts.
As for some public utility services, the customer could be proposed the option to pay a monthly fixed amount, to even out consumption peaks. The monthly amount would be recalculated annually.
As for tax payments in some countries, the customer could be invited to make advance payments in return for lower rates or bonuses (see Section 5.11 on promotions). Credit notes should be issued to correct billing mistakes — nobody's perfect. Customers and partners having real payment problems should be converted to prepaid or at least limited credit accounts.
Bills, credit notes and payments should be tracked in a ledger closely linked to the account, for customer care reasons. Payment chasing represents today roughly one third of an average communication service provider's CRM department.
Promotions can be granted upon subscription, upon usage and upon payment. In the early stages of the development of a communication service, when it is important for service providers to grab new users as fast as possible and churn doesn't matter, promotions are mainly granted upon subscription. In more mature markets, service usage and payments (e.g., top-up of prepaid account) are taken into account to stimulate loyalty and reduce churn among the most profitable users.
Promotion systems calculate the eligibility of end users and partners, based on multiple factors (e.g., address, lifecycle, usage, top-up behavior), but knowing the customer segments certainly helps. It is of no use to grant free MMSs to the Silver Cynics; they'd, however, very much appreciate free texts to their grandchildren.
The system ends up applying a promotional action: moving the account up the ladder in a loyalty scheme (e.g., from Gold to VIP in a frequent caller program), granting bonus credit in the wallets, and so on. Please note that it is often the wallet receiving this promotion, not the user/partner itself.
A promotion loses its effect if the users of the wallet are not informed in near real-time of it. Granting a bonus at the end of the month will have only a minor effect on loyalty. In most cases, but certainly if a promotion is granted upon subscription to a service, loyalty can be greatly improved by not granting the whole reward at once. Credit bonuses can be spread over time as "periodic credit installments" (e.g., one free SMS a day for the coming month).
It is important to be able to simulate a promotional campaign in advance of actually launching it. Too often, communication service providers launch campaigns with meager eligibility criteria, to unclear segments (too many people) and granting an insignificant or inappropriate benefit.
Promotions can be used as a tool to steer end users toward more profitable behavior, for example to use e-vouchers rather than scratch vouchers to top-up their prepaid wallets, or to top-up with larger amounts rather than frequent small amounts.
Much has been said and written regarding the edge between mobile operators and financial institutions. Operations on a mobile account (e.g., topping up a prepaid account using a scratch voucher) are for example subject to VAT, contrary to a bank account. A communications invoice is sent to you including VAT.
M-commerce has been touted as the possibility for the mobile communications consumers, using their mobile account, to purchase various services and goods, other than mobile communications and content, sometimes forgetting about these VAT issues. Gradually, the mobile service providers realized that by opening up that "purse" for a competitive fee (meaning at the level with credit card fees), they would face competing services being offered by these third parties directly to their own subscriber base.
We looked at this from a technical angle in Section 4.8. Premium SMS and MMS (short messages and multimedia messages to short codes) have been offered as means for third party application service providers to "tap" (debit funds) from the user's prepaid mobile account, or to add items on the postpaid bill. It is a case of bundled selling, where the mobile service providers do not wish to offer access to the purse (the payment method) without a message being carried over their networks (the communication means and connectivity).
If the payment method was offered stand-alone, then premium SMS (e.g., televoting, games, gambling) could be displaced by SMS to normal numbers (plus access by the ASP to the account). Or worse, the SMS service itself could entirely disappear and be replaced by IP-based communication means such as e-mail, instant messaging or Web browsing.
Simpay(.org), an initiative of 4 large mobile service providers to open the mobile users' purse to third parties, probably failed when these providers realized they would open the door to competing communication services that wouldn't use the mobile infrastructure anymore, or at least not in the same way (maybe still as bitpipes).
MMS is already being offered for free by independent MMS Centers out there on the wide open Internet, in the hope that users of these MMSCs will start using other services such as blogging, online albums, photo printing, or T-shirt printing.
Offering a stand-alone payment method could create a virtuous circle of higher revenue and lower margins, but open access to accounts has become Pandora's Box for many service providers — nobody dares to open it. In the Internet and credit card space, various players are trying to convince end users to establish a prepaid e-wallet, to be topped up using a credit card, or using funds transferred from another e-wallet.
Dedicated payment service providers (PSP) now allow application users to choose from a wide palette of different payment methods. Besides within telecom operators and Internet service providers, we have pre- or postpaid accounts at banks, credit card companies, public utility companies, leasing companies, cable TV distributors, electronic purses on plastic cards, and so on.
In the same line of thoughts as for the personal contact lists and tribe memberships (Section 1.9), we will soon need shared and compatible repositories for all these accounts. It is unlikely that the communication service providers will play this federating role.
There's another reason for communication service providers to be skeptical about open charging interfaces for M-commerce activities. As communication service providers cannot complete the communications to all destinations themselves, intermediate carriers will be involved, and there will always be the possibility for these third parties to use the communication means itself as a payment method for an application. In many cases, there will be no need for a dedicated charging interface (i.e., to the BSS), separate from the communications interface (i.e., to the I-BCF or even P-CSCF).
An example of this is the use of SkypeOut credit, which is normally used to set up calls to non-Skype destinations. Upon entrance to a public parking lot, a customer could key in his Skype login credentials (login, password), and the merchant (the parking company in this case) would use the Skype API to set up a virtual call from the customer's Skype ID to a mobile number owned by a payment service provider (PSP), for example, for 10 minutes in order to pay for every hour of parking.
The PSP would receive interconnect revenue, and kick back a number of cents (e.g., 5 cents a minute) to the merchant (the parking company). A similar scheme could be deployed by NGN service providers; the destination PSP would be interconnected to the NGNSP via a SIP interface. A new technical interface (protocol standard) is thus not required. The parking lot example shows that charging to certain destinations should be units-based (e.g., sip:[email protected] psp.ngvas.com) rather than time- or volume-based.
NGNSP could (should!) define higher payout rates for sessions to these PSP destinations. This matter is also linked to the question whether, in general, application service providers should be treated as end users or peer NGNs (Section 4.8).
Economically, on a charging interface, PSP would expect access to the NGNSP customer's purse at competitive fees, comparable to credit card fees (below 5% cost to the merchant). For a purchase amount of 100, this means a pay-out rate of 97 from the NGNSP to the PSP, followed by a kick-back of 95 from the PSP to the merchant.
The use of communication means as payment methods is not a new phenomenon in Next Generation Networks. Many Internet sites are now relying on premium calls and SMS (well-established communication means) as a charging method rather than as the content delivery channel. Users are invited to call premium numbers, send and/or receive premium SMS in order to obtain access to the site.
The vulnerability comes from malicious applications that would, using the customer's identification credentials (login and password), consume the communications credit without the customer knowing. In the era of dial-up Internet access, dialers would use the computer's modem to dial toll numbers. This threat became more stringent in NGN, where a dialer could force the local user agent to make even more invisible outbound calls over IP interfaces. Is it the NGNSP's duty to protect its end users from these security risks?
It would be of no use to develop a new, dedicated, highly secure charging API if the communications API can be broken. Security needs to be a concern on all interfaces, and the instruments to realize this are firewalls and session border control (Section 4.7).
For new communication means, it is of course a difficult exercise to evaluate the charging requirements in general. The requirements could be different for retail mode vs. wholesale charging, or toward other revenue sharing parties. But for sure, huge cost savings can arise from hosting these processes in a single environment (product catalog, charging, rating logic, etc.).
A next generation communication service could certainly be launched on the basis of pure functionality only, with Skype as school example — well, at least before SkypeOut was added. However, offering a new communication service in a sustainable fashion will require the appropriate dose of attention for each of the aspects of charging and rating. A reasonable shopping list could include the following:
- A single, solid product catalog, well balanced between a limited set of product types and an extensive set of individual options
- An account which is the sum of a user profile and a wallet, with a wallet usage policy allowing a single user to tap into multiple wallets, and shared wallets among corporations, families and the tribes of Section 1.11.2
- In general, online charging whenever possible, off-line charging as second choice
- Limited need for rating, by using nonmonetary credit in the wallets (e.g., seconds, megabits, clicks)
- Highly granular metering, to be preferred over blind openness to third party applications
- Reverse charging where necessary and fair to the service user
- Clear, real-time Advice of Charge at least toward end users
- Redirection to top-up and bill payment pages
- A more flexible payments policy, allowing to use multiple payment channels independently of the pre- or postpaid nature of an account (anyway, a single wallet could contain both pre- and postpaid credit)
- A well-thought promotions and loyalty strategy, after the initial growth phase
Reprinted from Value-added Services for Next Generation Networks by Thierry Van de Velde, with permission from Auerbach Publications, a Taylor & Francis Group. Copyright 2007.