Overview of Service Schedules
Service schedules define when specified services will be activated or deactivated and can also indicate when specified services are available or unavailable to subscribers. You can configure a service schedule for all subscribers to a service, or for a selected subscriber or subscribers. Schedules are composed of a number of rules expressed as schedule entries in schedule configuration.
You can exclude specified times, such as a day of the week, a specific date, or a time interval, from schedule rules. These times are referred to as schedule exclusions.
There are three types of schedules:
- Event-based schedules—The SAE activates or deactivates a service at a specified time. You specify the time the action is to occur, and any intervals to extend that time.
- Authorization schedules—The SAE allows or disallows access to a service during a specified interval; it can also deactivate sessions for current subscribers to a service at the beginning or end of an interval.
- State-based schedules—The SAE controls the times at which a service is available. Subscribers cannot change these schedules.
Event-Based Schedules
For each rule in event-based schedules, you specify a time at which the SAE activates or deactivates a specified service. In most cases for schedules configured under the global service configuration (for example, o=Services), a subscriber must be logged in at the time that the event occurs. For example, if a service is scheduled to be activated at 8 AM, the subscriber must already be logged in to the system at 8 AM.
You can extend the time at which a scheduled action can be initiated by configuring the following for event-based schedules:
- Action threshold—Interval after a scheduled time that an action can occur. The action threshold is configured globally for the SAE server.
- Preparation time—Interval before a scheduled time that an action can occur. The preparation time is configured globally for the SAE server.
Extending the time gives subscribers flexibility in when they can log in and in the time they can perform a task. It also gives the system time to complete a transition from one state to another and distributes the load on the system.
You can also configure an interval after a scheduled time that an action can occur for individual schedules. See Effective Period for Service Activation or Deactivation.
You can configure event-based schedules. See Adding a Service Schedule with the CLI or Adding a Service Schedule on a Solaris Platform.
Action Threshold
The action threshold indicates the maximum delay that a service allows for a time-related change to occur. For example, you can allow a 15-minute delay so that if an event is scheduled for 5:00 AM but the system is not able to perform the event at 5:00 AM, the SAE attempts to perform the action until 5:15 AM, as shown in Figure 6.
![]()
Preparation Time
Because the transition from one state to another does not occur instantaneously, the SAE uses the preparation time to allow for the time that the SAE needs to make the transition. For example, if you have a pay-per-view service and many subscribers need to have the service activated by a certain time, you can configure the service schedule preparation time to begin the process early to make sure that everyone gets his or her service activated by the time the event starts. Or you could schedule a few minutes of preparation time for setting up a videoconference.
A preparation time applies only to subscribers who have a service schedule and who are logged in to their subscriber session before the preparation time starts. For example, if you define a service schedule that activates service Audio-Gold at
8:00 AM, this service is activated only for subscribers who are subscribed to this service and are logged in as of 7:55 AM (assuming a default preparation time of 5 minutes). The service is not activated for subscribers who log in between 7:55 AM and 8:00 AM, as shown in Figure 7.
![]()
Authorization Schedules
For authorization schedules, a service is either available or unavailable. You can configure intervals during which subscribers can log in and activate a specified service and intervals during which subscribers cannot activate a specified service. In addition, an authorization schedule can deactivate a service at a specified time for subscribers who are using the service.
For example, you could use an authorization schedule to offer a service only between 5 PM and 8 PM. In this case, you can configure a schedule that denies activation of the service during any other time period. If a subscriber attempts to activate the service at a time other than between 5 PM and 8 PM, the activation is denied.
You can configure authorization schedules only for services that use authorization; that is, a service configured to use an authorization plug-in, such as the scheduleAuth plug-in provided by the sample data.
For information about configuring an authorization plug-in for a service, see Authorizing Scheduled Services with the CLI or Authorizing Scheduled Services on a Solaris Platform.
For information about configuring authorization schedules, see Adding a Service Schedule with the CLI or Adding a Service Schedule on a Solaris Platform.
State-Based Schedules
For state-based schedules, you create service schedules that are controlled administratively. A state-based schedule defines when a service is available or unavailable.
For example, you could configure a schedule to provide a service at 5 Mbps from 8 AM to 4 PM and another service at 2 Mbps from 3:45 PM to 8:15 AM. The time overlap ensures that one of the services is available at transition time.
You create state-based service schedules from:
- Enterprise Manager Portal—Service providers make schedules available to IT managers in enterprises. IT managers can then configure service schedules for their enterprises.
See SRC-PE Subscribers and Subscriptions Guide, Chapter 29, Managing Services with Enterprise Manager Portal.
- An application that uses the CORBA remote API—You can incorporate service schedules, including schedules that affect subscriber sessions, in an application that has been created with the CORBA remote API, such as a residential portal.
NOTE: The only way to associate a session with a service schedule is through the CORBA remote API.
For information about the residential portal, see SRC-PE Subscribers and Subscriptions Guide, Chapter 17, How Subscribers Use the Sample Residential Portal.
For information about the SAE CORBA remote API, see the documentation for the API in the SRC software distribution in the folder SDK/doc/idl or on the Juniper Networks Web site at
http://www.juniper.net/techpubs/software/management/sdx/api-index.html
Effective Period for Service Activation or Deactivation
You can configure an effective period for a schedule rule to give subscribers an opportunity to take advantage of a scheduled action for a specified amount of time, rather than for one specific time. If users log in after a scheduled action but before the end of the effective period, they can take advantage of the service. Although similar to an action threshold, an effective period can be configured for each schedule rule, whereas the action threshold applies to all schedules on an SAE.
An effective period is active for service schedules assigned to subscribers under the subscriber tree (for example, o=Users), but not for services under the global service configuration or a defined service scope (for example, o=Services or o=Scopes).
An effective period applies to subscribers who:
- Have a service schedule that includes an effective period
- Are logging in to their subscriber session
An effective period does not apply to subscribers who are already logged in to the system.
For example, you could create a schedule that includes a scheduled event to start at 9 AM and an effective period of 2 hours; subscribers can log in between 9 AM and 11 AM and have the event take place, as shown in Figure 8.
![]()
You can use effective periods rather than activate-on-login for subscriptions. If activate-on-login is configured for a subscription, we recommend that the service for the subscription not have an effective period configured.
One-Time Events and Recurring Events
You can specify service schedules for numerous situations. For example, you can set up:
- A one-time event—Performs an action at a specified time; for example, activating a gold Internet service at 7:00 AM on January 1, 2006.
- A recurring event—Performs an action over a period of time at specified intervals; for example, activating a gold video service at 7:00 AM every morning.
- A working-hours service—Performs actions at specified times on Monday through Friday; for example, a gold Internet service that is activated Monday through Friday at 8:00 AM and deactivated Monday through Friday at 5:00 PM. This type of service requires two schedule entries—one that activates the service and one that deactivates the service.
Schedule Availability to Subscribers
Which subscribers a service schedule affects depends on the configuration for the schedule. Table 8 shows which subscribers are affected by a schedule.
When a service provider or IT manager creates a schedule and attaches it to a service, the service schedule can be assigned to enterprise subscribers or residential subscribers. In some instances, subscribers can also create their own service schedules. When the scheduled action occurs, it applies to subscribers who are logged in and have a subscription to the scheduled service.
Schedule Exclusions
You can also exclude specific time intervals from a service schedule. For example, you can set:
- A holiday schedule—Ignores the service schedule for a specified day; for example, for January 1.
- A promotional period—Ignores the service schedule for a specified interval; for example, a 2-week period after the start date for the promotion.
Excluded times can apply to event schedules and authorization schedules. You can create numerous exclusion intervals to specify different actions and different times.