News

The dependency of one supplier…

Posted in News

Traditionally, operators have built the solutions needed to manage their networks themselves. Usually ad hoc and with focus on “solving the present problem” rather than fulfilling requirements for long term functionality or documentation, or considering future cost structure. The result is that the networks are not fully transparent and a dependency on a particular hardware provider is often created because of reluctance to bring in new vendors due to fear of negative consequences. A cumbersome approach that nevertheless has worked so far.

However, the maintenance of this hard-coded environment tends to be very time consuming and costly, as any changes in e.g. hardware, service portfolio or integration with other systems becomes more complex over time. System changes also become dependent on specific individuals meaning that operators become more vulnerable.

To change this way of working through harmonization and automation of the network via a third-party software, would be an effective solution. But, the realization of this has often failed due to two persistent myths:

Costs – On paper it looks more expensive for operators to take this step than to continue as before, as the costs for the already employed dedicated staff are rarely included in the calculation. Also the inefficiency of the current solutions affect many parts of the organizations and not only the teams responsible for the network management. These costs are usually not considered either.

Dependency – It is understandable that operators can see a potential problem in replacing one dependency (hardware) with another (software).

But myths aside, the arguments for network automation are several:

  • The value of harmonizing. In manually controlled environments, the knowledge of the network details decrease over time and is also usually distributed among several people and systems. The network harmonization allows you to abstract and simplify, enabling full control and overview of the network, including capacity and resources you have available.
  • Business development. By automating routine tasks the dedicated staff can be released for business development rather than working with pure maintenance. So the effect is two-fold: Cutting operational costs means releasing the innovative power of the organization.
  • Greater negotiating power. Network harmonization reduces the dependency of a particular hardware supplier. For an operator this means greater negotiating power in procurement. Also internal processes do not need to be based on a particular hardware type, but can easily be adjusted as the requirements change.
  • Simplified roles at the operator. In the hard-coded environment, product management is often a kind of a “hostage” in the organization. They are expected to solve what sales promised to customers, but are limited to what Network Operations can deliver, and even more so when the network is poorly documented. The time is ticking at all organizational levels.
  • Customer Service. How do you value good customer service and customer satisfaction? What is it worth to be able to promise customers delivery of new services in minutes instead of days? You could think that harmonization is contradictory to flexibility. This is however not a correct assumption. Instead it enables a fast and flexible environment for delivering new services.

 

So, with a third-party software, such as BECS, there will be structure, flexibility and capability to introduce new services faster. To take the steps needed in order to achieve these benefits may seem overwhelming, not least in terms of practical procedures, but also through the barriers in the organization as third-party software will manage tasks that technicians so magically have solved earlier. And, not least, to take the step may also be hampered by a sort of catch-22 thinking – “We do not have time to look in to this at the moment because of the existing workload”.

However, the long term effects are far greater than the temporary increase in workload. And you do not need to do everything at once. In short this means that it is better to begin the harmonization now, if only by taking small steps at a time. With a harmonization already in progress, the implementation of SDN will be a lot easier.

And finally, the issue of dependency: We dare to claim that a third-party software is easy to replace compared to a manually managed network due to the full harmonization and documentation available, allowing an easy move to a new tool if the need should arise in the future.

Discrepancy between the ideal and the real

Posted in News

Among the operators, there is a discussion about how to design networks in the future. The discussion stems from the fact that the rollout of new services is too sluggish and expensive. This is problematic at a time when the fight for customers is becoming increasingly sharp. There is a consensus among operators that network and service orchestration is necessary in order to reduce OPEX. However, there is some disagreement about the best way to get there. Automating bit by bit, how far and all at once or maybe “wait and see” until we have more knowledge?

The wait and see policy among many operators is not so difficult to understand. First and foremost a standardization work is progressing in ETSI. Secondly, operators are often busy trying to keep up with the manual work required in the networks today.

The standardization work of ETSI describes a logical future and implicate that much of the intelligence is transferred from distributed hardware to data centers. The new generation of hardware has limited functionality and will become highly standardized. This offers evident advantages as the cost of hardware is significantly reduced. At the same time, the concept provides increasing flexibility in capacity utilization. Operators can for example rapidly strengthen the capacity temporarily for mobile communication at a packed stadium without a need to have this capacity available all the time. However, to reach the goals that this future is describing will take time.

ETSI’s “rosy standardization image” implicate that telecommunications networks are virtualized in a similar manner as data centers are today. Simple hardware utilized by software that is more sophisticated. New features and services can therefore quickly be implemented via software.

The gap between today and the new future that ETSI is working on is wide and will take time to realize. Nevertheless, it will happen and the good news is – operators do not have to wait for this new future to materialize. It is possible to begin the network automation journey now without being locked in on a path that could later turn out to prevent the work ETSI is undertaking.

IT vendors are interested in supporting this new development, so the future is bright around NFV. The pragmatic way to proceed is to choose a solution (such as BECS by PacketFront Software) that structure and automates networks based on the conditions that apply today. It provides operators both full control of the network and a hardware-independent environment enabling many of the SDN and NFV benefits already now.

Whatever conclusions ETSI later draws, the solution is future-proof as it already follows the ETSI standardization structure and is flexible to cope with the required fine-tuning as the standardization matures.

However, friends of order might object and think, “Hey, wait a minute. Doesn’t that mean that you would be dependent on a software vendor instead of a hardware vendor”?

This is the question we will look at in the next post.

How to minimize manual time and maximize time introducing new services

Posted in News

Telecom networks are complex structures. So complex that any interference in the current “status quo” is often met with an unwarranted resignation among telecom operators. Energy and focus is being invested in maintaining the networks and running them manually instead of taking steps towards automation leading to lower operating costs and increased robustness of the network.

But every other industry today would not have survived had it not taken steps towards automation of routine tasks in order to gain in profitability and time savings. In the telecoms industry, however, automation of network management is at best rare, at worst non-existent. It forces the operators to put a lot of energy and resources into just keeping the networks up and running. Too much resources. This is reflected in the general low number of new services and innovation level in the telecommunications industry today.

But we believe this scenario can be changed by attacking the many myths that still permeates the telecom sector today, such as:

  • “Our network is so complex that it is impossible to automate.”
  • “Changing our network would involve excessive risks”.
  • “The transformation of our network will take a very long time and cost significantly more than it tastes. We simply do not have the time to look over our network right now”.

The “too-complex-myth”

There is an understanding in the telecoms industry that automation is the way to go in order to make time available for developing new services. It should not take 18-24 months for each new service to be implemented, but it usually does that because operators all energy is occupied in maintaining the daily delivery, while they at the same time experience declining margins in the existing business.

To be able to reverse this situation, operators must become more innovative and agile in their service packaging. In this situation they cannot be limited by technology or structures. One important factor in releasing the innovation power is detaching the hardware from the service development and provisioning. That is a prerequisite for creating faster innovation cycles that operators need. This requires “network harmonization”, where an abstraction layer is created between the network and the systems above. The major benefits of this approach are twofold:

  • The abstraction layer isolates the overlaying OSS and BSS systems from the network structure. By doing this, the introduction of services is considerably faster as the systems in the OSS/BSS layer do not need to consider how new or changed services are realized in the network.
  • The automation makes network changes in minutes instead of weeks or even months. This is especially valuable in large and complex networks using many network technologies and topologies.

And this does not require that the whole current network structure needs to be abandoned in one swift “big bang” solution.

The “big bang myth”

One can understand that the belief of a need for a “big bang” approach creates a kind of paralysis, and a “wait-and-see” attitude easily wins. You know what you have, but not what you will get. The technicians, who are often busy keeping the networks up and running, raise their concerns and stall the process. This is usually done as a self-protective measure, but not seldom because they want to maintain their position as “the Masters of the Network”. Consequently the whole process easily comes to a halt.

However, we believe that the risk does not lie in the automation of the networks. The greatest risk is to continue to maintain time-consuming manual processes and allow competitors to get ahead with greatly improved profitability and innovation power as a result.

The “transformation will take a long time myth”

The key is to take into account the concerns that major changes raise and take small steps in the right direction instead of thinking massive overhaul projects. It is both possible and so much better to start “somewhere” than “nowhere”. But where to start then?

Step one is to start automating a small manual task in the chain of processes in a network. Such a task could be:

  • A specific service, for example a corporate or private client service
  • A part of the network, such as a geographic area
  • A specific network layer, such as MPLS nodes, access switches or end-user equipment
  • A specific function, such as the rollout of new hardware

Or perhaps a combination of several of these tasks: e.g. Automation of the access switch configuration for end-users in a particular city.

Conclusion. We believe that the technical staff should minimize the time they spend on routine tasks. They should instead use their valuable skills to defining the standardized components, which the sales organization can use to build their offerings upon. On top of that an automated network provides an opportunity to test new services ad-hoc to see which ones are appreciated by the end-customers.

Small steps – major progress

Posted in News

As we have seen in two previous blog posts it IS a prerequisite to automate the networks in order to enable innovative new offerings, business and services. Operators do have this insight, but as it often involves complex structures, all dependent on each other in various ways, the thought “should we do this? Can we do a total overhaul and go all-in in the process”, easily arises.

It is understandable that this creates a kind of paralysis, and a “wait-and-see” attitude easily wins. You know what you have, but not what you will get. The technicians, who are often busy keeping the networks up and running, raise their concerns and stall the process. Usually as a self-protective measure, but not seldom because they want to maintain their position as “the Masters of the Network”. Consequently the whole process easily comes to a halt.

However, we believe that the risk does not lie in the automation of the networks. The greatest risk is instead to continue to maintain time-consuming manual processes and allow competitors to get ahead with greatly improved profitability and innovation power as a result.

The key is to take into account the concerns that major changes raises and take small steps in the right direction instead of thinking massive overhaul projects. It is both possible and so much better to start “somewhere” than “nowhere”. But where to start then?

Step one is to start automating a small manual task in the chain of processes in a network. Such a task could be:

  • A specific service, for example a corporate or private client service
  • A part of the network, such as a geographic area
  • A specific network layer, such as MPLS nodes, access switches or end-user equipment
  • A specific function, such as the rollout of new hardware

Or perhaps a combination of several of these tasks: e.g. Automation of the access switch configuration for end-users in a particular city.

By working in a small scale initially and assisted by a solution that supports this approach, one can achieve a process where the steps with the greatest benefits and lowest complexity are automated first.

An incremental automation enables a network built on modularity, where the implementation of new services can be achieved much faster and more efficient. This facilitates for the marketing and sales department to come up with ideas for new services, which can quickly be realized by the technicians.

We believe that the technicians should minimize the time they spend on routine tasks. They should instead use their technical skills to defining the standardized components, which the sales organization can use to build their offerings upon. On top of that an automated network provides an opportunity to test new services ad-hoc to see which ones are appreciated by the end-customers.

Furthermore, the technicians can use their time to develop the network for the future – including quality, capacity, robustness needs, i.e. aspects that have an actual effect on the perceived quality by the end customers. And thus directly impact customer satisfaction and the ability to earn money on the networks.

Cutting costs and increasing productivity in the telecommunications industry are all about the same things as in other industries, namely automation. The road to more cost effective and innovative company starts with small steps. Take time for the conversion if needed, but the important message is to start now. And to think modular.

PacketFront Software speaks at VNF Management & Orchestration in Barcelona April 28-29

Posted in News

PacketFront Software speaks about A Pragmatic Approach to SDN & NFV at VNF Management&Orchestration in Barcelona April 28-29 . We will also demonstrate how our product BECS is a powerful tool for anyone who believes that legacy systems will exist a long time, while still wanting to reap the benefits of SDN and NFV immediately.

Come and listen to our Head of Product Management, Henrik Johansson, covering a topic we know are top of mind for many operators: while SDN & NFV will solve many problems, they will not solve all of them . As an operator you will not rip and replace your entire network. You will not redo your entire OSS/BSS stack. So how can SDN & NFV help you today?

Henrik will talk about some low hanging fruit on your road towards NFV nirvana. And even if you don’t get there in a long time, you can still have major gains with very little investment. At the end of the day, this is all about making money, so what can be done to shorten e.g. lead-times for new service offerings?

Henrik will demonstrate technology available already today and usable in your existing network and he will look at and discuss a few different practical use-cases and he will propose a pragmatic, step-wise approach for the transformation of your network.

Welcome to meet with us and our booth for in-depth discussions!

/Ulf AVRIN, Henrik JOHANSSON and Anders WÄLIVARA

ulf.avrin@pfsw.com ; henrik.Johansson@pfsw.com and anders.walivara@pfsw.com