The Problem with RFSs

CFSs are difficult to understand and have caused a huge amount of debate in the TMForum Community and beyond, but RFSs that lurk beneath CFSs are even less well understood.

A recent training and consulting assignment to a telco in Canada revealed a number of issues that they had with RFSs and I suspect many other people have similar problems.

The first issue was the name - Resource Facing Services.  "Resource Facing" makes it sound as if the RFSs provide services to the Resources in the same way as the "Customer Facing" services provide services to the "customer" (or rather User, so perhaps CFS should be renamed UFS, but that's another story). But RFS providing services to Resources doesn't make a lot of sense!  If we have a set of services made up of CFSs on one side and RFSs on the other each servicing its own community and the RFS are supporting the CFSs - what provides the Services themselves?  The problem lies in the name Resource Facing Service and in particular the word "Facing"; it is the wrong word.  A better name would be "Resource Exposed Service" or "Resource Hosted Service" or "Resource Provided Services" or "Resource Fronted Services" (to preserve the acronym) as these types of service don't "Face" the Resources, rather they are exposed or provided by the Resources.

My view is that the RFSs are services that run "in the network" (or perhaps in the end user device, if you are talking about a smart phone or advanced set-top-box).  I think of them (and they used to be defined in SID) as interfaces or Services implemented by software running on hardware.

A second issue, that took me a little while to understand when talking to this group of enthusiastic Canadians, was that they were erroneously assuming that the RFSs (at least, if not CFSs as well) were objects involved with the provisioning of a Product on the network.   This I assured them was not correct.   The Service is the service used when using the Product, not the provisioning process used to create a Product in the network.

A third issue was how to describe the provisioning process for RFSs.  Logically you provision a Product by breaking it down into its components - Resources that the Product delivers (i.e. CPE - so we provision by Logistics delivering (and optionally Workforce management installing the

resource) or by giving the resource to the customer in the shop) and CFSs which we provision decomposing the CFSs into RFSs and provision those on the network... 

But, I hold that you don't usually directly provision RFSs.  With intelligent Network Elements you pass commands (Resource Orders?) to the NE and it internally does some magic in its "black box" to provision the RFS, and therefore from a provisioning perspective we can (usually) ignore RFSs.

Nevertheless when provisioning we need to understand how a CFS decomposes into RFSs and which "boxes" in the network support/provide these RFSs but practically we can jump from CFS Spec (via the RFS Spec) straight to Resources that deliver the RFSs.  Practically we rarely provision a CFS or RFS directly (I guess the exception might be something like a VPN where the service has a number of parameters that can be altered after the VPN has been created, but again I would argue this is done by talking to (a) a supervisor service or application (Logical Resource) that manages the VPN or (b) a VPN "box", or resource that provides the VPN (front end).

So, RFSs are as tricky as CFSs - someone recently asked me why we bother with these Services and I replied that before them things were even trickier.  The SID has really helped Communications Service Providers describe their products in very generic manner using CFSs and RFSs.

CFSs revisited

I see from the hits on my blog that most people find there way to it from Google where they have searched for “Customer Facing Service” (I am flattered and amazed to see that my blog is the first one returned by Google for that particular term”. I have also been asked for my list of CFSs... I am not sure that

a) I could give it out to you as it belongs to the organisation that I created it for

b) It would be particularly useful to you anyway...

However I would say a couple of things on this subject that may guide people struggling with the concept of CFS

1. The SID is a means to an end and not an end in itself. It is highly generic and can be used to solve almost any problem. As a result it is highly complex. It offers you the ability for example to endlessly nest CFSs and to build a complex hierarchy of products and product specifications and offerings. What you need to do is to focus on what you are trying to achieve with your CFS definition.

2. Each organisations list of CFSs is likely to some degree or another be unique to that organisation.

3. Keeping the first point in mind; In Proximus my colleague Eric Borremans and I were trying to simplify a complex mess of services and products that had evolved over the years. We decided to limit ourself to a single level of CFS rather than a hierarchy. We wanted something that

a) the customer (or end user) experiences and recognises

b) is complete and free-standing enough to be packaged up into an Product Offering alone without any other CFSs being necessary to support it.

c) is manageable through a single 'on/off switch' within the Network Management system.

For example we considered Voice Mail. Now when a customer uses Voice Mail he is able to perceive a range of services including deleting messages, listening to messages, recording greetings etc. This would indicate that there are several CFSs that make up the Voice Mail service. However it isn't useful to separate them.

One would never package up a Voice Mail Product Offering containing only the service to delete messages but not listening to them. We therefore decided that we would only have a single CFS service as Proximus had an "all or nothing" approach to Voice Mail and any enhanced services were bundled into the PABX offerings as Office Automation type services. So for Proximus Voice Mail was a single service.

On the other hand we had 2G access and 3G access as separate CFSs. This was despite the customer being potentially unaware which service he was using during a call. The reason for this was that it was mooted that the Telco might want to sell 2G only services to an MVNO and there were 2 "switches" in the network, one to switch on/off 2G and one to switch on/off 3G.

There is no “right” answer to CFS - but if you can define a set of criteria as we did for Proximus that does not contravene the spirit of the SID and NGOSS and makes logical sense for what you are trying to achieve in using SID then you can use these criteria as an “Occam's Razor” to sort out what is a Product Offering, what is a CFS and what is a RFS.

Simply put if a "candidate CFS" was found to be made up of or contains two or more CFSs then it, according to the rules we created in Proximus, is a Product Offering, if it isn't a Product Offering and fails one or more of the CFS criteria (listed above) it must be a RFS.

The list and the rules we created in Proximus reflected our desire to simplify Service Management and to an extent CRM. If our objective had been different then perhaps the CFS rules set and the resulting CFS list would have been different.

By the way the rules we developed allowed a long list of over 400 candidate services gathered from various departments throughout the organisation to be “boiled down” to only some 65 to 70 CFSs. This allowed would have allowed us to (in theory) to load the product definitions and CFSs into the CRM system to aid with problem reporting and ticket creation.

The lesson to be learnt about the SID is that “all things are possible” with it. You can create really complex Products, Product Offerings, CFSs and RFSs - which is fine, if that is really what you want to do. If however you don't need the complexity that SID offers then ignore it!

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).