[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]


Overview of Prepaid Services Demo

Prepaid service applications assume that users (subscribers) are registered with a subscriber management system, so that they can log in to the network and be authenticated. By default a subscriber has no access to the network. All attempts to access the Internet are intercepted and captured by the Service Selection Portal.

Subscribers pay for the service in advance of use by purchasing an access card that has a valid account number and expiration date. The subscriber then can activate the prepaid service, which might be, for example, access to the Internet or access to a gaming server. At activation, the portal prompts the subscriber for the account number and validates the access. The portal grants access if appropriate, and charging starts as soon as the portal grants access.

To integrate prepaid service applications, the prepaid services demo consists of the following two components:

The prepaid services demo supports two types of prepaid service applications, time based and volume based. Both types are limited in the demo to a single service being concurrently active per prepaid account. The account server maintains the accounts.

Account Server

The account server is the central data repository for the prepaid services demo. It maintains the different accounts and provides access for the other SRC components. The account server is a CORBA server with a data storage backend. In the prepaid services demo, data is stored on the local file system; in a real application you should use a relational database management system (RDBMS) for data storage.

The account server employs the SAE plug-in interface. The server publishes an object reference to a standard COS naming service or to a file in the local file system. It uses the managed accounts to authorize access to prepaid services and updates the accounts based on actual usage.

The model assumes that subscribers can log in and be authenticated. By default, all attempts to access the Internet are intercepted and captured by the portal. Subscribers pay for the service in advance of use by purchasing a valid access card. The subscriber then can activate the prepaid service. At activation, the portal prompts the subscriber for the account number and validates the access. The portal grants access if the account exists, has not expired, is not locked, and has a remaining balance (time or volume) greater than 0. When it grants access in response to a request, the account server locks the account against concurrent access. Charging starts as soon as the portal grants access.

Time-Based Services

Time-based services are sold by access time. These services have no limits placed on the data transmitted. For example, voice long distance service accounts are measured in connection time.

When it authorizes a time-based prepaid account, the account server sets the session timeout based on the current balance of the account. The account server locks the account when the session start is signaled. When the session stop is signaled, the account server updates the account based on the session time and unlocks it.

When the service stops (because the subscriber stops service on the portal, the subscriber logs out, or the session timeout expires), the account is unlocked, and its time balance is decreased by the session time.

Volume-Based Services

Volume-based services are sold based on upload or download data volume. For the demo application, volume is defined as the sum of the upload and download volumes. A real implementation might distinguish between the two for accounting purposes.

When it authorizes a volume-based prepaid service, the account server sets an interim update interval according to the following formula:

The maximum bandwidth is the greater of the two plug-in attributes upstreamBandwidth and downstreamBandwidth. If you do not specify values for these attributes, then the maximum bandwidth defaults to 1 Mbps.

When the session start is signaled, the account server locks the account.

When an interim update is signaled, the account server updates the interim update interval based on the account balance and the current consumption. It compares the volume used so far in the session with the remaining volume. If the session volume is greater than the remaining volume, the account server sets the session timeout to zero to stop the session.

If the session volume is less than the remaining volume, the interim update interval is recalculated, and no further action takes place until the end of that interval.

The interim update interval must be larger than a specified minimum value; the demo application employs a minimum of 5 minutes. This feature enables accounts to be overdrawn by an amount equal to the maximum bandwidth times the minimum time.

When the session stop is signaled, the account server updates the account based on the volume counters and unlocks it.


[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]