Figure SO.28 - Relationship Between ServiceBundleSpec and ServicePackageSpec

The next concept to introduce is that of ServiceBundles.<br/>Just as ServicePackageSpecs and ServicePackages define the templates and instances of a set of CustomerFacingServices, ServiceBundleSpecs and ServiceBundles define the templates and instances of a set of ResourceFacingServices. Note the symmetry – this is once again indicative of an extensible, robust information model. The extensibility is, of course, in the use of the ServicePackageSpec and ServiceBundleSpec entities. Once the desired specifications have been defined, it is relatively easy to instantiate those templates (thereby producing ServicePackage and ServiceBundle entities). Furthermore, this enables different instances to be easily differentiated while ensuring that their important characteristics remain constant. This also greatly simplifies their definition and management.<br/>The following Figure shows the relationship between a ServicePackageSpec and a ServiceBundleSpec. <br/>A ServiceBundleSpecification is the base class for defining the different classes of bundled ResourceFacingServiceSpecifications that a Customer can obtain via a Product. The preferred way to represent a Customer subscription to a Product of this nature is by using the association class ServicePackageBundleDetails to define the set of specific ServiceBundleSpecifications that are used by a particular ServicePackage.<br/>Conceptually, a ServiceBundle is thought of as a collection to enable the needs of different sets of ResourceFacingServices to be grouped together. The “bundle” conveys the concept of grouped Services that are related. Since these are ResoureFacingSpecifications, they define reusable templates for implementing the ResourceFacingServices that are required by a particular CustomerFacingService (as represented by a ServicePackage).<br/>The following Figure shows four exemplary subclasses of ServiceBundle for defining four different groups of Class of Service (CoS). The idea is to use each CoSBundle class to represent the Class of Service settings for a specific ServiceBundle. This enables different CoS settings to be associated with the different CustomerFacingServices that are defined by a particular ServicePackage, which is what the Customer obtains via a Product. For example, CoS1 could be used for VoIP, CoS2 could be used for mission-critical applications, CoS3 could be used for all other applications that are not mission-critical but require better than best-effort delivery, and CoS4 could define best effort service delivery.<br/>The combination of ServicePackage and ServiceBundle enables a Service Provider to abstract the notion of different classes of service that are sold to subscribers. For example, the troublesome use case of provisioning a Customer’s request to upgrade to a higher-level Service (or downgrade to a lower-level Service) can now be much more easily and efficiently handled. More importantly, this enables a single link to be defined between the low-level QoS model (which controls the mechanisms used in the devices to condition traffic appropriately) and this higher-level, business-oriented model.<br/>