Subscriptions and Activations
Each subscriber purchases a set of services; this purchase is known as a subscription. Information about the subscriptions is stored in the directory and is used by a residential service selection portal application to generate controls that enable the subscriber to:
Activate and deactivate subscriptions.
Subscribe to services.
Configure subscriptions to be automatically activated.
The service selection application can be either a Web application or an API. When the service selection application is a Web application, the controls are webpages with buttons and links to click on (see Figure 1 and Figure 2). However, the service selection application provides an open API that makes it possible to build applications that are controlled by mechanisms other than webpages. For instance, customers can build service selection applications that are controlled by applications running in the system tray area of the Windows task bar. This deployment consolidates the control of subscribers’ active network services and the speed of their Internet connection, along with their control of other aspects of their PC, such as the clock settings and audio volumes.
Many of the activation and deactivation interactions work in the same way, whether the subscriber is a residential subscriber or an enterprise subscriber. However, some interactions apply only to enterprise subscribers.
Subscription Activation Interactions
Clicking a button on the webpage to activate a service session causes the SAE to download the policies associated with the service to the subscriber’s IP interface on the router. Figure 3 shows the interactions among the components shown in Residential Subscriber Login and Processes during the activation process. This scenario assumes that the subscriber has already logged in.
The activation sequence is as follows:
Before the subscription is activated, the subscriber makes a request to the corresponding subscription resource in the service-controlled area.
A default policy that matches the request on the router causes the router to redirect the request to the SAE.
The SAE responds to the request with a help desk webpage, requesting that the subscriber activate the subscription before trying to access the resource.
The subscriber clicks a button on the service selection portal webpage, requesting the activation of the subscription.
The SAE sends a COPS or BEEP decision (DEC) message to the router, requesting the installation of policies for the subscription on the subscriber’s IP interface on the router, as well as service session information.
At start time, the SAE loads all services and policy templates from the directory. At activation time, the policy templates for the service are instantiated with values that are determined at activation, such as the subscriber’s IP address. The router stores session information so that if the SAE fails, the subscribers can continue using their active subscriptions. If the SAE fails, the router connects to a backup SAE. The backup SAE synchronizes all session information and then takes over management of all active subscribers on the router.
The router responds with a report (RPT) message acknowledging the decision message.
The SAE sends an accounting start message to the RADIUS server.
The RADIUS server acknowledges the accounting start message.
The SAE responds to the subscriber’s activation request, indicating that the subscription is active.
The subscriber may now retry the request for access to the controlled resource.
This time, the request to the controlled resource matches the policy from the newly activated subscription, so the router allows the request to be routed normally. Depending on the policy, the router may also apply QoS processing.
If interim accounting is enabled, the SAE periodically sends a decision message requesting usage data.
The router responds with a report message that contains usage data for the subscription. The usage data consists of the number of bytes and packets that the policies processed for the subscription.
The SAE stores the usage data in interim accounting records in the RADIUS server.
The RADIUS server acknowledges the interim accounting record.
Subscription Deactivation Interactions
Clicking a button on the webpage to deactivate a service causes the SAE to request that the router remove the policies for the service from the subscriber’s IP interface on the router.
Figure 4 shows the interactions among the components shown in Residential Subscriber Login and Processes during the subscription deactivation process. This scenario assumes that the subscriber has already logged in.
The deactivation sequence is as follows:
The subscriber sends a request to deactivate a subscription to a resource in the service-controlled area.
The request matches a policy that allows the request to be forwarded to the resource in the service-controlled area.
The subscriber clicks on a field on a webpage to request that the SAE deactivate the subscription.
As a result, the SAE sends a COPS or BEEP decision (DEC) message to the router to remove policies for the subscription from the subscriber interface and the service session from memory.
The router acknowledges the decision message with a report (RPT) message that contains service usage. The usage is the number of bytes and packets that the policies processed for the subscription.
An accounting stop record that includes the subscription usage information is written in the RADIUS server.
The RADIUS server acknowledges the accounting message.
The SAE sends a message to the subscriber, informing the subscriber that the subscription has been deactivated.
Because the policy for the subscription was removed from the subscriber interface on the router, any request for access is directed to the SAE.
The subscriber may now retry to request access to the controlled resource.
As was the case before the subscription was activated, the SAE generates a help desk webpage response that is relayed to the subscriber.