DAA Service Accounting

Basic Concepts

Each type of service can correspond to one tariff level, implementing service-based refined operation functions and meeting requirements for settlement between local network carriers and Internet toll network carriers and for value-added services.

DAA Service Activation and Deactivation

DAA service activation can be implemented using any of the following methods: binding a DAA policy template to a domain, delivering RADIUS packets, and delivering Diameter packets. The RADIUS protocol supports static activation only. That is, RADIUS authentication reply packets carry the DAA service template name. The Diameter protocol supports the sending of CCR-I packets upon user access to activate services or the sending of RAR packets after user access to dynamically activate services.

The DAA service activation process is as follows

The BRAS installs services and delivers service forwarding entries.
The BRAS initiates service accounting start requests.

DAA service deactivation involves the following scenarios

Service deactivation when a user goes offline: All DAA services of the user are automatically stopped when a user goes offline.
Dynamic service deactivation: The RADIUS server uses a DM message to delete the DAA service policy.
Service deactivation after quota exhaustion: After the service duration or traffic volume quota is exhausted, zero quotas are delivered or the service can be configured to go offline.

The process for the RADIUS server to use a DM message to delete a DAA service policy is as follows

The RADIUS server sends a DAA service policy deletion message to the BRAS.
The BRAS sends the RADIUS server a response message indicating that the DAA service policy is deleted.
The BRAS sends an accounting stop request to the RADIUS server.
The RADIUS server sends an accounting stop response to the BRAS.

Uniform accounting and Non-uniform accounting

When uniform accounting is used for DAA services, all service accounting packets are sent for the last service of a user, and all services' traffic is counted together.

When non-uniform accounting is used for DAA services, a service accounting packet is separately sent for each service of a user, and all services' traffic is independently counted.

Statistical Mode

User and service traffic supports the following statistical modes:

Statistics separation: DAA service traffic is not counted into user traffic.
Statistics unseparation: DAA service traffic is counted into user traffic.

The following rate limit modes are supported:

Rate limit separation: DAA service traffic is unlimited by the user bandwidth.
Rate limit unseparation: DAA service traffic is limited by the user bandwidth.

Account Type

Default accounting, none accounting, and RADIUS accounting can be adopted for the value-added services.

Default Accounting

If the RADIUS server delivers the value-added service policy, the system searches for the local value-added policy matching the policy name delivered by the RADIUS server, and then performs accounting according to the accounting scheme configured in the local value-added service policy.
If a value-added service policy is bound to the domain, all users in the domain use this policy as the default value-added service policy. When the service policy is not sent by policy server, the system performs accounting according to the accounting scheme configured in the bound value-added service policy.

None Accounting

The system does not perform accounting for the value-added service, regardless of whether a value-added service policy is bound to the domain and the accounting scheme configured in the value-added service policy.

RADIUS Accounting

If radius is specified in the value-added-service account-type command, RADIUS accounting is performed for the value-added service, regardless of whether a value-added service policy is bound to the domain.

DAA service accounting process

Figure1 shows the process of DAA service accounting:

Figure 1 DAA service accounting process

DAA service accounting process is as follows:

User Authentication

The user sends a login request to the BRAS. The BRAS sends a user authentication request to the AAA server.
The AAA server returns a user authentication success message to the BRAS. The message can carry a DAA service policy name. If the message does not carry a service policy name, the BRAS implements policy control based on the local configurations.

Accounting start: After a service is activated and a forwarding channel is established, accounting start is immediately triggered for the service.

After the user goes online, the BRAS initiates the basic service accounting start process to the AAA server. The BRAS distinguishes destination addresses based on the DAA service policy, performs bandwidth control for traffic.
The BRAS sends each DAA service's accounting start request packet to the AAA server. The AAA server uses the DAA service policy in the packet to identify services.
The AAA server generates service CDR files and sends the CDR files to the billing system.
The billing system performs rating, charging, and settlement based on the user name, service policy name, and preset tariff conversion relationship in the CDR files.

Real-time accounting: To ensure the timeliness and accuracy of user service accounting, the BRAS can send service accounting packets to the RADIUS server at a configurable interval. (If real-time accounting is required, configure an accounting scheme with real-time accounting specified in a service policy.)

Accounting stop: After a service is deactivated and a forwarding channel is deleted, accounting stop is immediately triggered for the service.

The user sends a logout request to the BRAS. The BRAS sends an accounting stop request packet to the AAA server.
The AAA server sends an accounting stop response packet to the BRAS.
The BRAS sends an accounting stop request packet for basic services to the AAA server.
The AAA server sends an accounting stop response packet for basic services to the BRAS, and the user goes offline successfully.