1. The Subscription Component is initialised.
2. The Provider Administrator has access to a management application, which can connect to the Subscription Component and allows them to enter the appropriate data needed to create a service.
3. The AMC is initialised, contains a relevant set of tariffs available for service charging, and can process subscription-related events.

1. The Provider Administrator inputs the information needed to define a new service, including a general service description; one or more service records (see below); a number of quality of service criteria; and an optional collection of SLAs using most of these criteria (see below).
2. A service is made up of one or more service records. Service records define some usable part of a service allowing the provider to sub-divide a service and levy a tariff against it. The tariff is selected from a list obtained from the AMC. If a suitable tariff does not exist the AMC is used to create one (see AMC Use Case document).
3. The administrator creates a number of QoS criteria detailing the bounds within which a service is consider to be operating satisfactorily. New QoS criteria can be created at anytime during service creation.
4. A SLA defines a contractual level of expected service, which, if exceeded, implies some compensation or violation tariff is credited to the customer. A SLA is composed of one or more QoS criteria. The administrator selects QoS criteria to create an SLA. QoS criteria can be selected individually or combined using Boolean logic. As each is added to the SLA the administrator defines the physical limit for which each bound will operate and the violation tariff to be credited if this limit is exceeded.
5. QoS criteria can be directly bound to a service record. A service composed of such service records must also select a SLA to which the bound QoS criteria belong.

1. A new service exists comprising of one or more service records.
2. A number of SLAs may also exists for this service
3. All details are recorded in persistent storage.

1. The Subscription Component is initialised.
2. The Provider Administrator has access to a management application that can connect to the Subscription Component allowing them to create a new customer account.
3. The administrator has received a request to open a new customer account.
4. The AMC is initialised and can process subscription-related events.

1. The administrator selects the option to create a new customer.
2. They enter the customer’s name and address.
3. The customer is registered with the AMC.

1. A new customer account is created.
2. All details are recorded in persistent storage.

1. The Subscription Component is initialised.
2. The Provider Administrator has access to a management application that can connect to the Subscription Component.
3. The administrator has received a request to subscribe a customer to a service.
4. The requested service exists (Label: flowthru.sub.PA 1, Post-condition 1).
5. This customer has a registered account (Label: flowthru.sub.PA 2, Post-condition 1).
6. The AMC is initialised and can process subscription-related events.

1. The administrator browses the current list of services and selects the one to which the customer wishes to subscribe.
2. A list of service records is displayed one or more of which is selected to precisely match the customer’s requirements for this subscription.
3. A relevant SLA is chosen from those defined for the chosen service.
4. A Contract is concluded defining the relationship between the subscriber and provider by entering contractual information including commencement date, withdrawal date, billing contact, billing address, original requestor, and a technical contact.
5. The new account is registered with the AMC in order the customer can be correctly charged.

1. The customer is subscribed to the requested service, one or more service record has been assigned, and a contract concluded.
2. All details are recorded in persistent storage.

2. The Customer Administrator has access to a management application that can connect to the provider’s Subscription Component.

1. The Subscription Component is initialised.
2. The Provider Administrator has access to a management application that can connect to the Subscription Component.
3. The customer is subscribed to a service (Label: flowthru.sub.PA 3, Post-condition 1).

1. The administrator selects the appropriate customer from the customer list.
2. The customer’s current subscriptions are shown and the desired subscription is selected.
3. The administrator selects the appropriate service in order display the list of service records.
4. One or more service records are selected to match the new customer requirements and these are linked to this subscription.

1. The service record(s) is (are) available for selection from the customer’s subscription.

2. The Customer Administrator has access to a management application that can connect to the Subscription Component.

1. The Subscription Component is initialised.
2. The Provider Administrator has access to a management application that can connect to the Subscription Component.
3. An account for the customer exists and they are subscribed to a valid service (Label: flowthru.sub.PA 3, Post-condition 1).
4. The CMC is initialised and contains relevant customer site information.

1. The administrator selects the customer for whom this SUG is to be created.
2. The SUG is given a name for easy identification, and a list of member users.
3. The administrator can now add a list of valid network addresses obtained from the CMC detailing from where users may access the service.

1. A SUG for the customer is created though users are not yet able to access a service.
2. All details are recorded in persistent storage.

2. The Customer Administrator has access to a management application that can connect to the provider’s Subscription Component.

1. The Subscription Component is initialised.
2. The Provider Administrator has access to a management application that can connect to the Subscription Component.
3. An account for the customer exists and they are subscribed to a valid service (Label: flowthru.sub.PA 3, Post-condition 1).
4. The required service record assignments exist (Label: flowthru.sub.PA 3, Post-condition 1).
5. The required SUGs exist (Label: flowthru.sub.PA 5, Post-condition 1).
6. The UMC is initialised and is able to receive subscription events.

1. The administrator selects the required customer followed by the particular subscription of interest.
2. Two lists of records associated with this subscription are displayed: a list of SUGs, and a list of service record assignments.
3. The administrator can either select one or more SUGs followed by a service record assignment to which they will be associated, or can assign a SUG to one or more service record assignments.
4. The UMC is informed that users in the selected SUGs are to have access to the given service.

1. For this customer potentially many connections exist between customer service record assignments and SUGs.
2. The users listed in each SUG can now access the service described in the assigned service record.
3. All details are recorded in persistent storage.

2. The Customer Administrator has access to a management application that can connect to the Subscription Component.

1. The Subscription Component is initialised.
2. The Provider Administrator has access to a management application that can connect to the Subscription Component.
3. An account for the customer exists and they are subscribed to a valid service (Label: flowthru.sub.PA 3, Post-condition 1).
4. The required SUG exist (Label: flowthru.sub.PA 5, Post-condition 1).
5. Connections exist between the SUG and one or more service record assignment exists (Label: flowthru.sub.PA 3, Post-condition 1).
6. The UMC is initialised and can receive subscription-related events.

1. The administrator selects the required customer and a list of customer SUGs is displayed.
2. Once the required SUG has been selected its connections to customer assigned service records are shown.
3. The administrator selects those to be activated.
4. The UMC is informed that all users in the selected SUG now have access to the connected service(s).

1. SUG members can now access the services for which they have been activated.
2. All details are recorded in persistent storage.

2. The Customer Administrator has access to a management application that can connect to the Subscription Component.

1. The Subscription Component is initialised.
2. The Provider Administrator has access to a management application that can connect to the Subscription Component.
3. An account for the customer exists and they are subscribed to a valid service (Label: flowthru.sub.PA 3, Post-condition 1).
4. The required SUG exists (Label: flowthru.sub.PA 5, Post-condition 1).
5. One or more SUG to customer service record assignment connections exist (Label: flowthru.sub.PA 6, Post-condition 1).
6. The UMC is initialised and is able to receive subscription events.

1. The administrator selects the required customer and a list of customer SUGs is displayed.
2. Once the required SUG has been selected its connections to all customer service record assignments are shown.
3. The administrator selects those that are to be de-activated.
4. The UMC is informed that users in the selected SUG no longer have access to the connected service(s).

1. Connections between the required SUG and customer service record assignments are de-activated.
2. SUG members are no longer able to access those services that have been de-activated.
3. The connection between the de-activated SUG and its service record assignments still exists.
4. All details are recorded in persistent storage.

2. The Provider Administrator has access to a management application that can connect to the Subscription Component.

1. The Subscription Component is initialised.
2. The Provider Administrator has access to a management application that can connect to the Subscription Component.
3. An account for the customer exists and they are subscribed to a valid service (Label: flowthru.sub.PA 3, Post-condition 1).
4. The required service record assignments exist (Label: flowthru.sub.PA 3, Post-condition 1).

1. The administrator selects the required customer from the current customer list followed by the subscription of interest.
2. A list of service record assignments associated with this subscription is displayed and the administrator selects one or more of these that they wish to de-activate.

1. The selected service record assignments are de-activated.
2. SUG members connected to these assignments can no longer use the service.
3. Any associations between SUGs and service record assignments remain.
4. All details are recorded in persistent storage.

1. The Subscription Component is initialised.
2. The Provider Administrator has access to a management application that can connect to the Subscription Component.
3. An account for the customer exists and they are subscribed to a valid service (Label: flowthru.sub.PA 3, Post-condition 1).
4. The required service record assignments exist (Label: flowthru.sub.PA 3, Post-condition 1).

1. The administrator selects the required customer from the current customer list.
2. A list of service record assignments associated with this subscription is displayed and the administrator selects one or more of these that they wish to activate.

1. The selected service record assignments are activated.
2. Activated SUG members may now use the service(s) described by the assigned service record(s).
3. All details are recorded in persistent storage.

1. The Subscription Component is initialised.
2. The Provider Administrator has access to a management application that can connect to the Subscription Component.
3. An account for the customer exists and they are subscribed to a valid service (Label: flowthru.sub.PA 3, Post-condition 1).
4. The required SUG exists and is connected to one or more assigned service records (Label: flowthru.sub.PA 6, Post-condition 1).
5. The SUG has been de-assigned from to relevant service record assignments (Label: flowthru.sub.PA 8, Post-condition 1)
6. The UMC is initialised and is ready to receive subscription events.

1. The administrator selects the required SUG from the list associated with this customer.
2. A list of SUG to service record assignments is displayed and the administrator selects the appropriate relationship which, after confirmation, is deleted.

1. The previously de-activated SUG cannot be re-activated (Label: flowthru.sub.PA 7).
2. Persistent storage is updated to record the change.

2. The Customer Administrator has access to a management application that can connect to the Subscription Component.

1. The Subscription Component is initialised.
2. The Provider Administrator has received a request to add a user to a SUG and has access to a management application that can connect to the Subscription Component.
3. An account for the customer exists and they have successfully subscribed to a service (Label: flowthru.sub.PA 3, Post-condition 1).
4. The required SUG exists (Label: flowthru.sub.PA 15, Post-condition 1).
5. The UMC is initialised and is ready to receive subscription events.
6. The user is registered with the UMC.

1. The administrator selects the required SUG from the list associated with this customer.
2. The user is added to the existing SUG member list.
3. The UMC is informed that the user has been added to this SUG.

1. The user is added to the SUG.
2. If the SUG is activated and is connected to an active service record the user may its services.
3. Persistent storage is updated to record the change.

2. The Customer Administrator has received a request to add a user to a SUG and has access to a management application that can connect to the Subscription Component.

1. The Subscription Component is initialised.
2. The Provider Administrator has received a request to add a site to a SUG and has access to management application that can connect to the Subscription Component.
3. An account for the customer exists and they have successfully subscribed to a service (Label: flowthru.sub.PA 3, Post-condition 1).
4. The required SUG exists (Label: flowthru.sub.PA 15, Post-condition 1).
5. The UMC is initialised and is able to receive subscription events.
6. The CMC is initialised and contains relevant customer site information.

1. The administrator selects the required SUG from the list associated with this customer.
2. The administrator creates a new site template and enters site-specific information such as network addresses obtained from the CMC.

1. The input site details are added to the required SUG.
2. Members of this SUG may access the service(s) with which it is associated from the new site providing the SUG/service record activation rules allow.
3. All details are recorded in persistent storage.

2. The System Administrator has received a request to add a site to a SUG and has access to a management application that can connect to the Subscription Component.

Use case description:

Post-conditions:

1. The Subscription Component is initialised.
2. The Provider Administrator has access to a management application that can connect to the Subscription Component.
3. The service to be withdrawn exists (Label: flowthru.sub.PA 1, Post-condition 1)
4. There are no customers subscribed to this service (Label: flowthru.sub.PA 16).

1. The current list of provider services is displayed and may be browsed.
2. The administrator selects the appropriate service and following confirmation the request is actioned.

1. The service is withdrawn.
2. Persistent storage is updated to record the change.

1. The Subscription Component is initialised.
2. The Provider Administrator has access to a management application that can connect to the Subscription Component that allows them to select to delete an existing customer account.
3. The account to be deleted exists (Label: flowthru.sub.PA 2).
4. The customer is not subscribed to a service (Label: flowthru.sub.PA 16)
5. The AMC is initialised and can receive subscription-related events.

1. The customer’s account is selected from a list of customers who have accounts with this provider.
2. The administrator selects the appropriate action and after confirmation the account is removed.
3. An event is sent to the AMC informing it that the customer no longer has a subscription.

1. An account for this customer no longer exists.
2. The customer is notified that their account has been deleted.
3. Persistent storage is updated to record the change.

1. The Subscription Component is initialised.
2. The Provider Administrator has access to a management application that can connect to the Subscription Component and unsubscribe a customer.
3. An account for the customer exists and they have successfully subscribed to a service (Label: flowthru.sub.PA 3, Post-condition 1).
4. There are no users using the service through this customer and they are prohibited from using the service while this operation is being performed.
5. The AMC is initialised and can process subscription-related events.
6. The UMC is initialised and is able to receive subscription-related events.

1. The administrator selects a customer from the current provider account list.
2. Their subscription portfolio is displayed and individual subscriptions may be browsed.
3. The administrator selects a subscription and after confirmation the request is actioned.
4. An event is sent to the AMC informing it that this customer is no longer subscribed to the service and, if the customer has no further subscriptions that a bill should be sent.
5. An event is sent to the UMC informing it of the users that are no longer subscribed to this service.
6. The customer administrator is notified of termination.

1. The customer’s subscription to the service is terminated.
2. The customer’s user can no longer access services to which they were subscribed.
3. Any associations between the customer’s subscription account and service template service records are removed (Label: flowthru.sub.PA 11).
4. Customer SUGs with connections to this service are de-activated (Label: flowthru.sub.PA 8).
5. The contract for this subscription is discarded.
6. Persistent storage is updated to record the change.

2. The Customer Administrator has access to a management application that can connect to the provider’s Subscription Component and unsubscribe a customer.

1. The Subscription Component is initialised.
2. The Provider Administrator has access to a management application that can connect to the Subscription Component.
3. The customer is subscribed to a valid service (Label: flowthru.sub.PA 3, Post-condition 1).
4. Connections between the required customer account and one or more service records exist.

1. The administrator selects the appropriate customer from the customer list.
2. The customer’s current subscriptions are shown and the desired subscription is selected in order to display a list of service record assignments.
3. The administrator selects the appropriate service in order display the list of service records for this subscription.
4. One or more service records are selected and these will no longer be linked to this subscription.

1. TBA

1. The Subscription Component is initialised.
2. The Provider Administrator has access to a management application that can connect to the Subscription Component.
3. An account for the customer exists and they are subscribed to a valid service (Label: flowthru.sub.PA 3, Post-condition 1).
4. The required SUG exists (Label: flowthru.sub.PA 15, Post-condition 1).
5. There are no connections between this SUG and any customer service record assignments (Label: flowthru.sub.PA 8, Post-condition 1).
6. The UMC is initialised and is able to receive subscription-related events.

1. The administrator selects a customer from the current provider list.
2. The customer’s SUGs are displayed and individual SUGs may be browsed.
3. The administrator selects the appropriate SUG and following confirmation the request is actioned.
4. An event is sent to the UMC informing it that the SUG has been deleted and that all users associated with it are no longer subscribed to this service.

1. This SUG is deleted.
2. All SUG to customer service record assignments are removed.
3. Any users associated with this SUG who are not attached to another SUG are no longer able to access any provider services.
4. Persistent storage is updated to record the change.

2. The Customer Administrator has access to a management application that can connect to the Subscription Component.

1. The Subscription Component is initialised.
2. The Provider Administrator has access to a management application that can connect to the Subscription Component.
3. An account for the customer exists and is subscribed to a valid service (Label: flowthru.sub.PA 5, Post-condition 1).
4. A SUG for the customer exists (Label: flowthru.sub.PA 3, Post-condition 1).
5. The user to be deleted is assigned to a SUG (Label: flowthru.sub.PA 12, Post-condition 1).
6. The UMC is initialised and is ready to receive subscription events.

1. The administrator selects a customer from the current provider account list.
2. The customer’s SUGs are displayed and may be browsed.
3. The administrator either selects the user for the chosen SUG or enters their ID directly and after confirmation the request is activated.
4. An event is sent to the UMC informing it that the user no longer belongs to this group.

1. The user is removed from the user group and cannot use the services of the group to which it was subscribed.
2. Persistent storage is updated to record the change.

2. The Customer Administrator has access to a management application that can connect to the Subscription Component.

1. The Subscription Component is initialised.
2. The Provider Administrator has access to a management application that can connect to the Subscription Component.
3. A SUG for the customer exists (Label: flowthru.sub.PA 5, Post-condition 1).
4. The site to be deleted is registered with the SUG (Label: flowthru.sub.PA 13, Post-condition 1).

1. The administrator selects a customer from the current provider account list.
2. The customer’s SUGs are displayed and may be browsed.
3. The administrator selects the site for the chosen SUG and after confirmation the request is activated.

1. The customer’s site details, which include network addresses, are removed from the list of access points for this SUG.
2. Persistent storage is updated to record the change.

2. The Customer Administrator has access to a management application that can connect to the Subscription Component.

1. If persistent subscription data exists the Subscription Component has access to it.

1. The administrator instructions the subscription component to be activated.
2. Once the provider’s services have been created and the customer accounts established the AMC and UMSs are activated as these require subscription information to create user and accounting records respectively
3. An event is sent to the UMC informing it that the Subscription Component has been started and is initialised. Once both components have synchronised user information can be exchanged regarding which SUGs they are attached and to which services they are subscribed
4. An event is sent to the AMC informing it that the Subscription Component is up and running. Once both components have synchronised customer billing, charging and QoS information can be exchanged.

1. The Subscription Component, AMC and UMC are up and running. Synchronisation occurs between all three subsystems to ensure this is the case.
2. Users who belong to a SUG may now use the service defined in the associated SSP. Customers can be charged for usage and service quality monitored.

1. The provider administrator has access to a management application that can close down the Subscription Component.
2. The UMC is initialised and is ready to receive subscription events.

1. The administrator elects to close down the Subscription Component and selects the appropriate option from the management application.
2. A message is sent to all current ‘live’ users of the system that closedown has commenced and a time frame established by which they must cease using the service.
3. When the time frame completes the administrator continues the closedown procedure.

1. The Subscription Component no longer exists. Attempts to use the provider services will fail.
2. System resources owned by the Subscription Component are released.
3. All subscription service and customer account information is recorded in persistent store.
4. An event is sent to the AMC telling it to stop charging.
5. An event is sent to the UMC telling it to close all open user sessions.