The dependency of one supplier…

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

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.