Key EDSG Techniques

Service Identification

Policies are executed for specific data flows, and the ACL mechanism is used to send service flows matching a service group to the corresponding service channel.

Figure 1 Service identification

Differentiated Accounting

User traffic is identified and managed as different services, and independent statistics and accounting are performed for each service. Traffic levels can be set on an AAA server to implement differentiated accounting for different types of packets.

Figure 2 Differentiated accounting

Policy Control

Policies are classified into the following types:

Static service policy

A static service policy takes effect immediately when users go online. It is obtained from a BRAS's local configurations or delivered by an AAA server using an authentication response message.
Figure 3 shows the process of a static service policy. The process is described as follows:
1. The user sends a login request to the BRAS. The BRAS sends a user authentication request to the AAA server.
2. The AAA server returns a user authentication success message to the BRAS. The message can carry an EDSG service policy name. If the message does not carry a service policy name, the BRAS implements policy control based on the local configurations.
3. After the user goes online, the BRAS initiates the basic service accounting start process to the AAA server. The BRAS distinguishes traffic based on the EDSG service policy delivered by the AAA server or the locally configured EDSG service policy, collects traffic statistics, and performs bandwidth control for traffic. For details, see EDSG Service Accounting.
4. The BRAS cyclically sends each EDSG service's accounting start request packet (carrying the user name, EDSG service policy name, and service traffic information) to the AAA server. The AAA server uses the EDSG service policy in the packet to identify services. The tariffs for services are defined on the AAA server.
5. The AAA server generates service CDR files and uses FTP/TFTP to send the CDR files to the billing system. The AAA server can also send the service accounting information to the billing system through an SQL database interface.
6. 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 (or service accounting information in the database).
7. The user sends a logout request to the BRAS. The BRAS sends an accounting stop request packet to the AAA server.
8. The AAA server sends an accounting stop response packet to the BRAS.
9. The BRAS sends an accounting stop request packet for basic services to the AAA server.
10. The AAA server sends an accounting stop response packet for basic services to the BRAS, and the user goes offline successfully.
Figure 3 Process of a static service policy
Dynamic service policy
After a user goes online, a policy server or AAA server can be used to deliver an added or changed service policy to the BRAS. The following dynamic service policies are supported:
- A carrier uses the AAA server to send the CoA parameter or the service policy name to the BRAS to modify the service policy information.
- A user logs in to the portal self-service page to dynamically modify the service policy. The policy server (or the other resource management server) then sends the modification result to the BRAS.
Figure 4 shows the process of a dynamic service policy (service policies are modified through the AAA server). The process is described as follows:
1. After the user goes online, an initial service policy is delivered by the AAA server or obtained from the BRAS's local configurations.
2. The AAA server delivers the CoA parameter to modify service bandwidth control parameters or delivers a service policy name to add a service policy or modify the user's service policy. For details, see EDSG Service Activation and Deactivation.
3. The BRAS performs bandwidth control and accounting for services based on a new service policy combination and sends accounting start packets for new services to the AAA server. The packets carry information, such as the user name and service policy name.
4. The AAA server generates CDR files based on the new service accounting information from the BRAS and sends the files to the billing system for rating and charging based on the new service policy combination.
Figure 4 Process of a dynamic service policy (a service policy is modified through the AAA server)
Figure 5 shows the process of a dynamic service policy, which is modified through the policy server or the other resource management server. The process is described as follows:
1. After the user goes online, an initial service policy is delivered by the AAA server or obtained from the BRAS's local configurations.
2. The initial service policy is used for traffic statistics, accounting, and bandwidth control.
3. After going online, the user logs in to the portal self-service page to modify the service policy.
4. The portal server uses the SOAP protocol to send the service policy modification result to the policy server.
5. The policy server sends the modified service policy to the BRAS through the CoA interface.
6. After receiving the service policy from the policy server, the BRAS performs bandwidth control and accounting for services based on the new service policy combination and sends accounting start packets for new services to the AAA server.
7. The AAA server generates CDR files based on the new service accounting information from the BRAS and sends the files to the billing system for rating and charging based on the new service policy combination.
Figure 5 Process of a dynamic service policy (a service policy is modified through the policy server)