Specification and Instance in SID

SID uses extensively the concepts of “Specification” and “Instance”. The Specification provides the definition of the concept, whether it be a Product Offering, Resource or even Customer Facing Service (CFS), whilst the Instance allows as the name indicates allows individual instances of the specification be identified and linked, where appropriate to a particular Customer Account.

The Specification is easy to understand if you think of your car; every component in the car has a part number. The part number for, say the silencer (muffler), is the same for every car of the same year, model and manufacturer as your car. This allows you to go to the car parts shop and buy a new one. The silencer you buy will also have a serial number on it which is unique to that particular silencer, no other silencer with that part number will have the same serial number. So the part number identifies the Specification and the serial number identifies the Instance.

It is fairly easy to see how this model extends to customer equipment like a SIM card or handset. For example, each handset has a unique serial number (in the case of GSM handsets, the IMEI) and is identified by a part number, or name such as Motorola Raza or Nokia 6300. However this notion extends to Product Offering which is a specification of the Offering and Product Subscription which is the instance of a Customer’s use of the Product Offering and down to Installed Customer Facing Service which is the instantiation of the CFS (which is a specification too).

When defining a specification for a piece of equipment like a handset there are a set of properties that all handsets have, like

• Weight
• Talk time
• Size
• Colour
• Frequency band

as well as the capabilities of the handset, such as Bluetooth, camera, tones, MP3 player etc etc. So we can define a set of parameters relevant to the Resource Specification and then for a particular model define a set of Parameter Values (e.g. 100 grams, 4 hours, 10x5x1 cm, silver, 1800 MHz) that define the model.

We can then extend this idea to CFS where we can, for example, for “Voice Mail” (a CFS) we can define a set of parameters like

• Language
• Personalised greeting
• Message capacity
• Message latency, etc

that are relevant to Voice Mail and then when a Customer (or more correctly End User) personalises his Voice Mail we can define the particular values he/she has chosen against the Installed CFS.

This is a very powerful way of defining both the capabilities of services, products and hardware and recording the particular parametrisation relevant to individual customer's usage of them.

What does SID mean by Customer Facing Service?

A key element in SID is way it models telecoms products (Product Offerings) and especially the concept of Customer Facing Services (CFS). A Product Offering (Specification) is made up of:

• Customer Facing Services
• Resource Specifications
• A Price Plan

A Customer Facing Service is defined in SID as: “A Customer Facing Service is an abstraction that defines the characteristics and behaviour of a particular Service as seen by the Customer. This means that a Customer purchases and/or is directly aware of the type of Service and is in direct contrast to a Resource Facing Service which support Customer Facing Services but are not seen or purchased directly by the Customer.”

The key point to this definition is the word seen. The Customer (or more precisely the End User Party Role) perceives the service “Outbound Voice Call”, for example, as nothing more than that. The End User does not perceive the switching, encryption, error correction, radio frequency hops, base station transfers, multiplexing and demultiplexing that may go on in the background.

The Product Offering is thus defined in terms of the Services that an End User perceives, values, and may be charged for.

The SID does not contain the concept of Supplementary Service, which is after all a network (GSM) related artefact and should not (in the ideal world) be used when describing or pricing products and services to Customers and End Users.

Clearly defining a Product Offering, for example “3G Anytime” solely in terms of the services perceived by the End User will not help when the Product Offering is sold (as a Product Offering Subscription) to be provisioned in the network or on the Billing System, but that is precisely the objective of the SID. By allowing an Offering to be defined independently of how it is implemented as a step in the direction of Service Oriented Architectures Holy Grail – Loosely Coupled Architecture, where each domain defines what it wants in the way of services, not how the services are to be implemented or built.

Clearly a Customer Facing Service such as “Outbound Voice Call” has to be provisioned in the network as a range of low level services managed by dedicated hardware such as the MSC. These services are defined as Resource Facing Services (and I will be discussing these RFSs in a later blog).

So, we can define a Product Offering as a collection of Customer Facing Services, the Specifications of the Resources required by the Product Offering (and the CFSs) such as the telephone number (MSISDN), type of SIM, type of Handset etc and the Prices to be charged for the Product Offering and the CFSs it offers (Note: An “Outbound Voice Call” or “Send Text Message” can be charged at different rates in different Product Offerings).

I hope you will agree that this sounds sensible, but what exactly is a CFS? Is a “Voice Call” a CFS, or is “Making a Voice Call” a separate CFS from “Receiving a Voice Call”. When one tries to list CFSs it becomes incredibly difficult to actually decide what is and is not a CFS and why.

While working with Belgacom Mobile (Proximus) Eric Borremans and I faced this problem. We needed an objective way of defining what a CFS was and a set of rules to allow us to determine whether a candidate service was a CFS, and if it wasn’t a CFS, then what actually it was.

The trick was to focus back on the definition of CFS, and it comes back to the word “seen” in the definition of CFS, or perhaps more precisely “perceived”. If a End User cannot perceive the difference between two related services, then probably the two services are components of the same CFS. If on the other hand the End User can tell the difference then, probably (as there are other pragmatic criteria to be applied) these two services are separate CFSs.

For example – can an End User tell the difference between making a voice call and receiving one? To me this is a definite “Yes”. The phone rings when a call is made and when answered there is someone on the other end of the line to talk to. On the other hand when making a call the line has to be activated (by picking up the receiver, or pushing a button on the handset), the number dialled and then after hearing the ring tone the phone maybe answered.

On the other hand, can an End User tell the difference between making a voice call to a fixed line number as opposed to a mobile number? In my opinion, these are the same CFS, handled by different RFSs (to do the switching). One could argue that a knowledgeable End User can by knowing something about the numbering plan in the country, but the call is perceived (heard) in the same way during the call. It is also possible that a call to a fixed line number terminates on a mobile phone and vice versa through call forwarding, hunting groups and the like. When it comes to paying for the call the difference between fixed and mobile voice calls may also be perceived as they may be charged for differently, but that is after the event (for Postpay customers at least). So it comes down to perception during the use of the service, not prior or after the event knowledge that counts.

However if one extends this simple rule to a complex service like “Voice Mail” things become complex and uncomfortable. Clearly an End User can perceive the difference between “Listen to a Voice Mail Message” and “Delete a Voice Mail Message”, but then Voice Mail decomposes into about 10 or more CFSs that are never ‘unbundled’ – one could never imagine selling a Product Offering that allowed someone to “Delete a Voice Mail Message” but not to “Listen to a Voice Mail Message”. An additional rule needs to be defined to allow these type of services that are perceived differently to be bundled together into a pragmatic CFS.

Actually Eric Borremans and I came up with 3 rules and a method to apply these rules that allowed Eric to draw up a list of 60 or so CFSs that described every Service that Belgacom Mobile sold and managed. This list has been successfully implemented within Belgacom Mobile in the area of service management and has been used to define all of the Product Offerings they sell.

Introducing SID - Part One

The Telemanagement Forum’s Shared Information Data Model (TMF SID) is part of the NGOSS (Next Generation Operational Support System) and has been in the public domain for several years now.

The SID offers the first truly Open Enterprise Data Model for the Telecommunications industry.

There have been proprietary Telecommunications Enterprise Data Models in the market place. The author has hands on experience with Oracle’s Telecoms Enterprise Model and Teradata’s Communications Logical Data Model (cLDM). Both of these models have a great deal of strength and robustness but each is only a single organisation’s view of the information within a Telcoms business. The TMF SID however is not based on any particular software or hardware. It defines the information within a Telecoms business in such a way that it can be used to describe all products, everything from POTS to IP Telephony in a simple unified manner.

There are other things that make the SID powerful in its data modelling approach (such as the use of Party Roles and the subtle use of Logical and Physical Resources), but in this article I will be focusing of the definition of Products.

The SID does not describe the Telecoms products and services in a subscriber or MSISDN centric manner but in a very subtle integrated two-layer approach that allows all offerings to be described in a way that is understandable to the Customer (aiding billing and customer care) at one level and implementable in the network and as reusable components at another.

Lets examine the SID’s Product concepts

• Product Offering – the thing that is marketed and sold. This is best thought of as the box that everything is put in. Just as when you buy cornflakes it is the flakes of corn you want inside the box, but it is the box with its logo, brand name, and barcode that you actually purchase.

• Customer Facing Service – the things that you use in the Product Offering, or more subtly the things that the customer thinks he is using, which on the network may be supported by multiple services

• Resource Specifications – the definition of the resources needed to implement the Customer Facing Services (CFS). Note this is the specification of the resources, not the resource instances. When defining a POTS product the resources required would be a line and a phone number, not a specific line running from 34 Acacia Avenue and not a specific phone number 01252794888. Plainly when a Product Offering is sold its Resource Specifications are instantiated as specific Resources that are allocated to a particular customer for as long as that Product Offering is used (or subscribed to) by the customer

• Price Plan – the definition of the charges associated with the Product Offering. These will include the One Off Charges (such as the price of the Product Offering), the recurring charges – for the use of the Customer Facing Services and the One Off Charges (penalty charges for example). Note the Price Plan is a component of the Product Offering not the Offering itself. The practice of telecoms companies thinking they sell price plans comes from the manufactures of billing systems and confuses the heck out of the business and, more importantly, the customers

And that is all, at this level at least; there is no need to think about how the Product (Offering) is to be implemented or provisioned in the network (at this level).