IBM and Stream Computing
Normally I do not write about vendor products but since today’s topic seems to be a new driver for the industry, I will make an exception. Today’s topic is about IBM Infosphere Streams product which introduces a new term to our industry: Stream Computing.
Stream Computing concept stems from the fact that todays’ OSS/BSS environment is composed of “streams” of data flowing between the systems. Each stream serve different purposes. The stream that fetches CDR data to the mediation system over the ftp protocol serves to the Order to Cash process. Another stream that looksup the segment information of a given MSISDN from the
Campaing Management Application could serve to a different end-to-end process.
Stream computing allows us to “intercept” and do additional actions over the traditional streams that we use in our operations.
Take mediation example: We fetched the CDR from the switch to the mediation system. This is a standard ftp operation and until it finalizes no system has a control over its payload. If we put a stream computing system between these two, we can intercept the data and play with the payload. Here is how it works:
You create the main stream in the Infosphere Streams system, which does the real thing: ftp, from one place to the other. This operation is transparent to the OSS systems in the chain: The mediation system “thinks” that it is getting the data from switch. And since we do not “touch” this main stream, there’s little or no latency in the mediation process.
The magic, however, lies within the Infosphere Streams. With this product you can “clone” the stream to serve parallel different purpose. Following the same example, I clone the main stream and I have two output data now: CDR information. The second stream, goes to another OSS system which checks the MSISDN with the campaign mgmt system to see if this is a VIP activity. If so, the VIP customer can be SMSed after the call for example.
Streams reaches billions of events per second in the data processing speeds, which can easily cope with Telecom’s moving data speed and volume.
As you may know, IBM is spending too much time for the research an development of AI systems. AI studies go in parallel with big data studies. The most recent outcome of these studies was the introduction of Watson, which is an AI program equipped with big data processing algorithms.
It will be wise to combine stream computing with these AI study outcomes and IBM seems to be moving in that direction.
Mobile Device Agents
Today, I want to talk about a new trend that seems to popped up in the SQM/CEM field: Mobile Device Agents.
Mobile Device agents are software components that reside on user devices and collect statistics about the quality of user experience which will enable the operator to act upon service degradation. Operator can also have the same data correlated with service quality data to plan future service improvements.
Device agent term is fairly new for the mobile industry. However, this is not the case for the fixed line. In fixed line, operators have been collecting metrics about the given end-to-end service for years. These metrics are collected from CPE(Customer Premises Equipment) devices (mostly routers and L2 switches) that reside on the customer premises. Ideally, but not necessarily, these devices are also managed by the operator, taking the name Managed CPE. By utilizing data coming from these CPEs, operators are able to measure not only the core network health, but also the Access side.
In order to increase user perceived quality, service providers continuously seek new datasources that will give clues about the customer’s service perception. Customer usage data can be collected in several places:
- Probe systems
- DPI systems
- Device Agent systems
Probe system and DPI system can provide the top most visited URLs, throughput/speed kind of statistics that will give clues about the service usage. Probe systems can additionaly provide call drop statatistics and catch device configuration errors.
Device agents can do both. But, they also provide device related information such as signal strength or battery status. They even can tell which software along with their versions are installed on the phone.
If we collect all this data (usage + device + signalling) and correlate successfully, we can do lot’s of customer experience related analysis with it. We can detect that a specific service usage drop from the DPI system and correlate this with mobile phone configuration errors. The dropped calls can be correlated with device battery information to see if the dropped call has occurred because of a device problem. In some cases where the operator has not done any investment to DPI and probe systems, just the Device Agent system can provide all that data.
But why device agents are not so popular? First answer is the privacy. Most people will not want agents on their phones that are sending their usage patterns to somewhere else. There are not so many regulations around this but we should expect to see them soon.
The second answer is more technical. The agents consume processing power and drain the batteries soon. In order to get rid of this, agents should not always be on-line, and collected statistics should be uploaded in relatively longer intervals (a couple hours). That late data cannot be utilized by SQM systems so it can only be used for late correlation and planning purposes.
Device agents use push mechanism and upload their statistics to a central server where further correlation and reporting functions can be executed. However, because of the reasons I have provided, they cannot be real-time data sources which are required by most SQM/CEM systems.
Why TAM is “less” popular?
OSS is all about automations and tools automate things. Maybe we should pay more attention to TAM rather to eTOM. This is all about marketing indeed. TMForum “sells” eTOM in a very successful way. TAM, on the other hand, seems to be left on one side to it’s destiny.
If you have a look at the documentation differences, you will see that TAM has only 1 reference document attached in contrast with eTOM which have dozens of related documents. You won’t also see any related training directly addressing TAM.
The second reason for this situation is the driver of the standards. The driver of TAM is the service providers themselves not TMForum itself.
However, when you go to the field, the first thing the service providers use for any OSS gap analysis is the TAM framework. eTOM, which should appear first, goes next. Offcourse any transformation activity should start at the processes level but this requires time and effort.
Do you also see TAM more in the picture in your transformation programs?
CFS and External Business Service Catalogs. When terms collide..
Anyone who enters the complex world of OSS/BSS transformations, will face different technologies, standards and their terminology they carry with. Management standards depict the terms, and the terms become the language people talk to each other. Take IT for example. ITIL is the dominating de-facto standard for managing the whole lifecycle of IT services, from birth to death. ITIL sees IT as a function that serves the core business whether it is a restaurant business or a telco. When it comes to telco, as we said, the principle is the same. However, in telco, IT is more “involved” in the business. Even worse, the business cannot live without it.
When we have a look at IT services in a telco, you will see that most of them serve some part of a service that has been served to the customers. Why just some part? What is the other part? The other part is the bearer, the network itself, and it is a separate organization, structure and culture. So the end user service needs IT and Network. (Telcos playing the role, cloud provider, can only serve IT services without Network, however, this is another story.)
This holistic view has been adapted nicely by the TMForum standards where the service that has been “used” or “perceived” by the customer is called the customer facing service(CFS). CFS’s reside in the product catalog and they include one or more resource facing services.(RFS) CFS and RFS reside in the product catalog of the organization.
Returning our attention back to IT, we have business service, which reside in the business service catalog. Business service, as its name implies, the service that is served to the business. So it can be a payroll application or SMS application, which means, it can be involved in a CFS or not. But it is the business service at the end.
The problem I have seen while communicating the services and catalogs is this. In order to be inline with the holistic view, IT tends to divide its business service catalog to “internal” and “external” business services. External business services are the CFS’s or RFS to some CFS’s. Internals are the ones who are internal to the business such as payroll. This creates multiple catalogs. (On the other side, Network can live with CFS and RFS terms as they don’t have ITIL).
Some eTOM-ITIL mapping studies has been issued by TMForum to solve these communication problems. However, for me, there needs to be more studies around standardization of these service catalog structures. Especially for telcos who follow ITIL for the IT standard.
Linkedin Group – Telecommunications OSS and BSS
I created a group on Linked’in to notify the new events that are happening in this blog.
You are also welcomed to include any comments about the site.
Please join the group at:
http://www.linkedin.com/groups?gid=4250468
Regards,
Murat Balkan
