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.
