SQM Implementation Approaches

 SQM  Comments Off on SQM Implementation Approaches
Oct 042011
 

Service quality management is becoming more popular day after day. The reason behind this is the data boom in the mobile communications area.

Service providers are aware that they need to move to service management in order to take control of the quality of their services, at least from the service provider perspective.

After the need is realized, they try to project the scope of such a service management migration. Are our data sources ready? Do we need to pay extra licenses to the OSS vendors? How should we set-up new business processes or change the existing ones? etc.

As you can see, the operator should handle both technical and business aspects of the migration. On the technical side, operators typically prefer to run some assessments with software vendors in order to understand their technical readiness for the SQM.

We are seeing 2 approaches in such assessments which OSS vendors follow.

1-) Top down
2-) Bottom up

Bottom up approach, focuses on collecting as much information as possible. In this approach, vendors look at all the data sources that are available in the resource domain. These include FM, PM and the elements themselves. Then they ask the customer which of these KPI/KQIs are needed by him. Since the customer generally knows very little about the concept at this stage, he asks for all of them. And the scope gets bigger and bigger. After some point, when it is the time to bind these KPI’s and KQI’s to the service itself, we come up with lots of unnecessary details. At this stage, the vendor/customer returns back to square one to re-evaluate the needs.

Top down approach tries to get rid of this situation. It first asks the business need. Why I am moving to SQM? Which services I am going to manage under the SQM process? What should be the least granular service tree that can reflect my operational status? Are there any off-the-shelf products around to guide me in formulating details like modelling?

Staring with questions like these, helps the customer to focus what he needs, nothing more. The outcome would be shorter implementation periods, reduced risk and more importantly a successful SQM project.

More Printed Articles

 Inventory Management, SQM  Comments Off on More Printed Articles
Oct 042011
 

Here are 3 articles that I have sent to a Turkish telecommunications magazine: Tele.com.tr.
Unfortunately there is no English translation, but I can say that the context is in-line with my previous blog articles.

Tele.com.tr – December 2011 Issue
Mobile Devices and Web Experience – Page: 62,63
http://www.scribd.com/doc/74883534/Tele-com-tr-Aral%C4%B1k-2011

Tele.com.tr – September 2011 Issue
Network Inventory Management Systems – Page: 54,55
http://www.scribd.com/doc/65277706/Tele-com-tr-Eylul-2011

Tele.com.tr – August 2011 Issue
Service Quality Management – Page: 54,55
http://www.scribd.com/doc/64840536/Tele-com-tr-Temmuz-A%C4%9Fustos-2011

OTT Services and SQM

 SQM  Comments Off on OTT Services and SQM
May 062011
 

Have you seen the rumors that Facebook will buy Skype? Well, it won’t be a surprise for most people. One big OTT company buys another. The big surprise would be to see Facebook to embed Skype into the Facebook application and kill the stand-alone Skype. This way, it will force to move all the VoIP users to enter to it’s application where it could have the option to issue ads, campaigns and more importantly, user stats that can be easily sold to 3rd parties.

From the service provider and OSS point of view, this puts another barrier in front of the end to end service visibility. Skype service, embedded in a Facebook web application, located in the internet. Cloud in a cloud situation.

Service providers need to see both the external OTTs service and possible sub-services underneath. Putting a robotic probe that will continuously logs in to a Facebook account will not be enough. The bot, should also try to initiate a call. And, there is no standard mechanism such as calling a web service to initiate the call. The bot, should use screen scrapping mechanisms to simulate the user clicks to make this happen.

If we are lucky enough to “decode” the remote OTT service, we can get some KPIs to be fed into our SQM system. This way, we can get proactive actions such as informing the users about the problems regarding the OTT service provider to achieve customer satisfaction.

Yet, OTTs and Service Providers do not have any standard communication mechanisms that will able them to exchange KPIs of their services. This would definitely be the next generation trend as both sides need those in order to provide expected levels of service. We’ll have to see B2B supplier/partner interfaces between OTTs that will enable them to issue / track and manage trouble tickets.

Services are getting complex day after day. Value chains are getting longer. There are lots of parties to interface with. There are no simple service like “GSM Voice” anymore. We are in the beginning of a change and it is better to act fast for the operators to invest in SQM and re-engineer their processes accordingly.

Jan 152011
 

As the level of maturity increases in the operators, they focus more on improving the quality of services they give. As I explained in my previous posts, SQM (or sometimes call BSM-Business Service Management) is the key to measure the quality of the overall service. In SQM, we model the service and the service is composed of multiple service components. These components can be HLR, Charging, Core Network, Packet Network, Applications, Databases etc. and each of them is managed by a functional unit in the organization.

In an SQM”less” scenario, from the top-down approach, when a service problem is identified on the very top level, it is questioned the source of the problem. Identifying the root source of the problem may be time consuming. (The departments will most probably blame each other).  SQM can pinpoint the source and take necessary actions that increases the effectiveness. But who runs the SQM?

According to eTOM, SQM belongs to the Service Management & Operations functional grouping, so in best practice, it is advisable to assign a department for this process. (eTOM does not mandate it should be separate. This could be a role that can be assigned to an existing department. But as we will see, it won’t be effective to consolidate functions)

A new term, Service Operation Centers arise with the introduction of service quality management  concept. Service Operation Center or SOC is an organizational “department” that monitors the quality of the overall service and take the necessary actions in the case of service degradations and outages. The main data source for the SOC screens will be the SQM. The operators in the SOC will continuesly monitor SQM and coordinate with other departments to decrease the MTTR of the service outages.

A typical operator has a Network Operation Center or NOC inside it’s organization. This NOC, manages the NMS systems, monitors faults and events, track the performance of the network and troubleshoot the problems at the first hand. (L1 support). However, as the name implies, the main purpose of the NOC is to manage the network.

The network is only one part of the service. There are other components from IT. There may even some components from outside the organization such as content. NOC’s primary responsibility is to deal with those network specific complex problems. They should not communicate with the content provider to resolve a problem.

Because a network service provider’s main product is “network”, up to now, NOCs were sufficient to achieve overall assurance activities. But, as the services get more diverse and complex, SOC concept became much more logical.

As SOC deals with cross-functional teams, they should be sponsored by a upper level organizational entity to be effective. SOC should also have necessary interfaces to the other units (most likely the TT system) where strict OLAs are applied to. The people in SOC should include experts with  skills in networking, IT and other necessary topics to streamline the troubleshooting activities.

IP Probes

 SQM  Comments Off on IP Probes
Mar 242010
 

In order to get the end-to-end network performance data, we should install probes to the infrastructure. Probes are the most effective way to reach the end-to-end performance that is perceived by the end user. An alternative approach is to correlate multiple node-to-node performance data to reach the end-to-end performance metrics. This is very hard to maintain and may cause misleading results so we should always use probes where possible.

There are two types of probes. Active and Passive.

Passive probes passively monitor the packets that are passed through them. Basically in the entrance point, they monitor the packet header to identify the source address, destination address and some other information. The remote probe at the exit point does the same. Both probes send this information along with the timestamps to the management system where they are correlated and converted to performance metrics. Passive probing is a costly solution. Its’ main benefit is, they do not generate any traffic so maximum throughput is maintained.

Active Probes, on the other hand, generate special traffic between each other to measure the end-to-end performance. Some probe vendors use ICMP PDUs for this purpose. Other vendors, such as Cisco, prefer to send special PDUs that have additional parameters. Active Probes are cost effective when compared to the passive ones. They should be the preferred approach to measure IP based traffic.

Probes can be external (hardware based) or internal (software based). Software based probes are easier to deploy and maintain. Most popular software based internal probes are Cisco SAA probes (IP SLA).

Probes provide granular data. Typically this data is collected and further aggregated by the performance management systems and forwarded to other systems such as SQM.