You must have heard that the entire telecom industry is evolving from a network-centric (or better yet, resource-centric) technical operations model towards a service-centric and, ultimately, a customer-centric operational model. But what do these customer-centric approaches mean? This blog post is dedicated to answering one fragment of this question—data models for service assurance. Before we jump into the main topic, we will briefly emphasize that the term "digital service provider" (DSP) used in this blog relates to telecoms as well as all organizations that provide digital services to business and residential customers (consumers), such as cloud service providers, data center infrastructure service providers, Internet of Things (IoT) connectivity and device providers, managed services providers (MSPs), etc.
What is data modeling in Service Assurance?
Service
assurance refers to monitoring service health and performance, alerting about service quality degradation, and taking assurance activities to improve service quality, ensuring it is SLA-compliant. Essentially, monitoring service quality primarily relies on monitoring network and other ICT resources and determining the quality based on the monitoring data. To translate the resource measurements to service quality indicators, one must establish data models that map service definitions to the resources used to provide the service. This modeling is precisely what we discuss in this blog post.
What is Service Assurance and how it relates to Resource Assurance
A digital service delivers a specific value proposition to satisfy the needs of customers or end-users by transferring data, content, and application functionalities using internet/digital technologies. The service creates measurable value for both the customer and the service provider.
To deliver on its promise, the service must meet expectations. In other words, you can't charge for it if it doesn't deliver what it was supposed to. This brings us to one of the essential operational tasks of each digital service provider (telecoms included)—ensuring that the service operates correctly and fulfills the promised value.
Put simply, service assurance is a set of processes, procedures, and technical and human resources used to ensure the service lives up to its promise (value proposition) to customers, whether residential or business.
From a technical perspective, a digital service is realized by the cumulative contribution of various technical functions finely tuned to provide the end customer with an experience that meets their expectations. These functions are supported by various network devices and data center equipment, both physical and virtual. The term used to collectively describe them is "resources."
Therefore, any degradation of the digital service typically means that some of the resources are either malfunctioning, lacking capacity, improperly configured, or the functions composing the digital service are not properly aligned.
This leads to the conclusion that assuring a digital service means ensuring that resources and their functions are managed so their combined contribution delivers the service as defined. Assuring services ultimately involves ensuring resources in a manner where assurance processes and procedures are designed to orchestrate resource remediation or reconfiguration so that the operation of the degraded digital service is fixed as soon as possible, or the degradation is avoided by a preemptive action.
To achieve this goal and understand this activity, it is important to first adopt the concept of service modeling—the way services are mapped to network and other systems' resources. The topic of service modeling is exactly what our next section and our blog post is all about.
Service modeling TM Forum-style
The concept of service-centricity has been widely recognized by many standardization organizations, with one of its major advocates being TM Forum—an industry alliance of hundreds of global companies working together to streamline technology exchange and integration capabilities between digital service providers, technology suppliers, consultancy companies, and systems integrators.
One of TM Forum's core frameworks is its Information Framework, also known as SID (Shared Information/Data Model). SID is an information reference model (not the model itself!) supported by the vocabulary needed to implement business processes in digital service provider environments. A key part of SID is its service domain building blocks (known as business entities), defined in the GB922 series of standards. A great starting point for understanding this complex area is TM Forum’s Frameworx Standard document GB922 Service Overview.
In this blog post, we face the challenge of explaining the complex concepts of service modeling in a simple manner. For that purpose, we will introduce some necessary simplifications, hoping our TM Forum colleagues won't object too much.
Entities of a service model
To explain the basic concepts, let us use an example of a telecom’s triple play service (TPP). The very name of TPP means different things to different people. To customers, it is a commercial name for something they have purchased and use. To others, it is a set of three services they use every day. To the telecom, it is a set of technical services provided to meet customers’ expectations. TM Forum’s service modeling defines different terms and entities to describe all these equally valid views.
TPP is the name of a product offering—something that a telecom offers to the market, i.e., something that customers buy. Therefore, a product offering is a definition of what is offered to customers, its pricing, promotions, but also the offering lifecycle, etc. An instance of that product offering purchased and used by a specific (concrete) customer is called a product. For simplicity, a product can be regarded as a concrete signed contract between the telecom and the customer for the use of TPP by the customer as specified by the product offering.
For this example, TPP is composed of three services: fixed voice, internet access, and IPTV. And two pieces of hardware: a home router and set-top box (STB). These five elements (three services and two resources) realize the TPP as the product, and they are precisely what customers perceive as the outcome of the product. On the other hand, it is clear that the telecom provider sees the product as implemented by a finely tuned combination of many technical services they provide, like internet connectivity, SIP line, IPTV stream, etc. All these are services, but with a significant difference depending on who perceives the service.
The customer perceives only voice, internet, and IPTV, along with two pieces of equipment, while other services, like the SIP line, are completely invisible and irrelevant to the customer. For this reason, the three constituent services that are perceived by the customer are called customer-facing services (CFS). On the other hand, the technically oriented services, provided by many underlying functions of different resources, are called resource-facing services (RFS). Customer-facing services comprise the product, along with a few technical resources, usually home/office routers (CPE), set-top boxes (STB), etc. However, customer-facing services require one or more resource-facing services to operate. Furthermore, resource-facing services are configured on and provided by one or more technical resources. In the following example, we’ll see how it all works together.
Example model
Example model figure below depicts one of hundreds of possible models for TPP service. As shown, TPP in this example is a product comprised of voice, internet access, and TV service (CFS), along with two resources: CPE and STB.
A telecom can model the product in any way that suits its needs. The figure below depicts one of hundreds of possible models for TPP service. As shown, TPP in this example is a product comprised of voice, internet access, and TV service (CFS), along with two resources: CPE and STB.
Each CFS requires one or many RFSs. For instance, internet access requires network connectivity and ISP platform resource-facing services (DNS, routing, etc.). Each of these services is configured on one or several technical resources (physical devices, virtual devices, logical resources). For instance, IPTV service must be configured on IPTV platforms but also utilizes network uplink as well as the set-top box (STB) – the same one that is part of the TPP Product.
What is the model used for?
Now that we've scratched the surface of the service modeling topic, one naturally wonders what it can be used for and what its purpose is. The number of applications is vast. One obvious use is maintaining a register of all products, along with the accompanying services and resources. However, there are many more practical applications from an assurance perspective.
One illustrative example is Service Impact Analysis (SIA). With a properly designed network management system (NMS) in place, you can always monitor all alarms for all resources. If a "link down" alarm is detected for a network uplink (the resource), you can easily identify all the RFSs that depend on that resource and mark them as impacted.
Next, you can take it a step further: for each impacted RFS, find the related CFSs and mark them as impacted as well. Finally, by tracking the known impacted CFSs, you can easily identify the products and customers using them that are also affected by the alarm.
This way, when an alarm occurs, you can quickly identify all the customers, products, and services impacted by the fault. This is called service impact analysis (SIA). It helps engineers detect customers who may be experiencing problems with their services and take the necessary steps to inform them about the potential issue, which ultimately helps improve customer satisfaction.
While SIA helps you understand which products are impacted, it doesn't provide information on whether customers are actually experiencing service degradation. For that purpose, other methods are needed, one of the most popular being Service Quality Management (SQM). That said, SQM is far more complex to explain in this post, and we'll touch on it in one of our future blogs.
Specification of products, services, and resources
In the previous section, we emphasized the importance of establishing a service model. We introduced the term "product," and it is crucial to understand that this entity is central to the TM Forum SID model since customers, by definition, buy (obtain) products, not services. At the same time, it serves as a link to the marketing aspects of telecom business processes.
We previously stated that a product is an instance of a product offering. While this is true, there is an important detail to add. The services that make up the product, as well as the resources (hardware) it includes and is configured on, are specified by another entity—product specification. Strictly speaking, the product specification is made available to the market as a product offering, and it describes the product.
On the other hand, CFSs and RFSs, as well as the resources of a product, are specified by their respective specifications. CFSs are specified by entities called customer facing service specifications, RFSs by resource facing service specifications, and the resources provided as part of the product are specified by resource specifications.
Therefore, we have instances of products, CFSs, RFSs, and resources—entities that exist once the product is purchased/rented and delivered. Their specifications describe them and establish their relationships, just like the one illustrated in the previous figure.
This is challenging to display visually without using formal languages like UML class diagrams, but the following figure attempts to depict the relationships among the entities in the model in a meaningful, though still complex, way.
The actual data structure that describes the entire model in modern BSS/OSS systems is far more complex. For instance, product specification is supported by entities like product specification type, product line, product category, product configuration specification, product specification cost, allowed product action, and more.
In addition to specification entities, the SID model also incorporates the concept of characteristics. In SID, a characteristic refers to an entity’s property. For example, in the case of a service, this could include the type of interface provided, its bandwidth, type of QoS, etc. Similarly, there are characteristics for products and resources. Furthermore, each characteristic can be associated with one or more characteristic values. For instance, a service characteristic for bandwidth might have associated characteristic values of 100 Mb/s, 500 Mb/s, 1 Gb/s, etc. The same concept applies to resource characteristics and their characteristic values. One interesting feature is that characteristic values for services and resources may be linked through a translation, where, for example, 100 Mb/s of service bandwidth might translate into 105 Mb/s of resource bandwidth.
In any case, the model behind products, services, and resources is extensive and complex. One can delve further into many details by exploring the GB922 series of standard documents from TM Forum. Some of these concepts will also be addressed in a few of our upcoming blog posts.
Product and Service Catalogs, Service Inventory
Now that we have introduced the essential elements of service, product, and resource models, we can finally put this into the context of TM Forum’s catalog-driven architecture and operations in telecoms and DSPs. In this context, a catalog is a software function that maintains a repository of definitions (specifications) for product offerings, products, services, and resources, including their interrelationships. It manages their lifecycle and dictates how telecoms create, manage, sell, and deliver their offerings to customers.
On the other hand, products, along with the corresponding CFSs, RFSs, and resources, are created based on these specifications and stored in systems that TM Forum recognizes as inventories. An inventory is a database or repository that stores and manages information about various telecom objects such as products, services, and resources, as well as their relationships.
In general, there are different types of catalogs that may be implemented as single or multiple software units:
- Product catalog
- Service catalog
- Resource catalog
Correspondingly, the inventories that store instances defined/specified in catalogs are:
- Product inventory
- Service inventory
- Resource inventory
There are also other types of inventories, such as customer inventory, physical inventory, logical inventory, capacity inventory, etc., but we do not address those in this blog post.
The following figure is a simplified representation of the relationship between catalogs, inventories, and the corresponding entities used for modeling.
UMBOSS & Service Modeling and Assurance
In this blog, we've taken the first step in introducing essential data modeling concepts needed for service assurance processes. UMBOSS, as an umbrella network and service assurance platform, implements parts of the model and functionalities mentioned above. This includes storing RFS and CFS data, as well as resource inventory. UMBOSS is also designed to interact with external product and service catalogs. Ultimately, UMBOSS is built to deliver tangible results by helping Service Operation Center (SOC) engineers effectively execute assurance processes, providing functions like SIA and SQM, and automating remediation activities.
Have any questions? Want to learn more? Get in touch and let us know how we can help. Send us a message or book a demo today.
