Why is openness important?
I was recently invited to give my opinions on a Mobile World Live discussion where this was discussed. Clock the image below to listen to the replay or click here.
Openness is more than Open RAN and openness is not an answer, it is an approach.
Why now and who does it serve?
What is it good for? Absolutely Everything!
There are 3 main beneficiaries.
Operations - for efficiency and acceleration
Operating vendor black boxes does not scale, from an economics point of view and from a speed point of view. Traditional closed systems were not designed to be automated as part of an end-to-end total network operation. Where hyperscale cloud vendors replaced traditional server supply and proprietary bloat, telecom will now follow with the network.
And traditional systems come with their own vendor specific management systems that were designed for manual operation by people that understand the vendor specifics. Open standardized interfaces allow all vendor equipment to be managed the same way, removing the need for islands of special vendor competence, management systems, supply chain spare parts, inventory and warehousing. Automation allows accelerated control in parallel increasing the speed of deployment and operations possible.
The networks are increasingly complicated and with the advent of AI this will only accelerate. These networks were not designed to be manually run by people anymore. We need to provide vendor neutral platforms and remove proprietary solutions, for all phases of operation, from planning, through deployment to service assurance and life cycle management.
Resiliency
Countries, businesses and people increasingly run at the speed of machines on the networks we provide. If they are vulnerable the country is vulnerable. We must have choice and optionality in being able to rapidly replace parts of the networks with different vendors. As geopolitics becomes a larger conversation, these options increasingly need to be local or regional in nature. Open disaggregated networks deliver this flexibility.
We have no choice but ensure we are in local control of our networks.
End-Customer
We build networks for one reason and one reason only - to deliver valuable services to customers. As the customer world moves from one size fits all to being more specialized we need to make sure we can divide and change more granular parts of our networks on demand. This requires highly programmable networks where others can integrate into our systems and not be forced to "look and feel" like a telco.
Closed network approaches are no longer fit for purpose. This is not a choice but a necessity.
Why is openness hard?
It places complexity into plain view rather than being hidden behind a pre-assembled "black box" that "works but you don't know how". With that increased visibility and granularity comes great power but also great responsibility. While previous procurement of legacy systems appear more like insurance programs than technology acquisitions, this new approach requires each of us in operators to take more responsibility for end to end system design, overall operations, and risk profile. It is moving from managing one massive juggernaut that delivers everything but very slowly, to a fleet of fast trucks that can all deliver in parallel but need to be synchronized, managed and controlled in the field.
This is cloud-native. This is where dynamism comes from. This is what leads us to being able to discover new market opportunities and execute on them quickly once proven.
This is how all software native companies can make magic happen.
Conclusion
It is a great time to be in telecom. More change is happening right now in the core of the network part than has happened since the 1990s. But telecom is massive and needs to work so change happens very slowly. But when it does happen, it happens very quickly.
We are designing for a very different world going forward, where the users of the network might be more silicon based lifeforms than carbon based ones.
Be prepared for that.
Passionate About OSS || Helping to make your OSS decisions easier || Managing Director || Investor
1 周Geoff Hollingworth, I'm a really visual person, so your wonderful image tells as much of a story as your story does.... 1. There's a black box (a vendor managed service), that looks like a machine but has room for some people inside ;) 2. There are dozens of staff / contractors scurrying around the outside monitoring the black box, many in a mild sense of panic (interestingly none seem to be meeting / discussing what the black box is doing though, which probably doesn't reflect reality) 3. The suit at the right is intently watching what his team/empire is doing outside the box (oblivious to what's going on inside the box, but calm in the knowledge that if the box fails, he can blame the box for failing) 4. There appears to be only one woman in the room, which hints at a real lack of diversity 5. There's only one isolated black box shown but we know that there are usually a few interconnected black boxes in reality 6. There are a lot of experiments / test-kit around the black box but none are actually connected to anything 7. There's another exec at the back playing a soothing song on guitar, rocking backwards and forwards, nervously praying the black box continues to work reliably, knowing it could explode at any moment
Silicon vs Carbon based lifeforms, but who will pay for it? https://www.dhirubhai.net/posts/garethpricejones_is-5g-useful-for-everything-so-in-the-beginning-activity-7265120243281227776-jBjO?utm_source=share&utm_medium=member_ios
Rethinking networking
1 周Hi Geoff, I agree with you 100% that the openness is important, but pretty much disagree with you on some of the root causes. I would here push back towards the operators, not the vendors. As LI didn't allow me to put the whole text as comment, I have created a post and linked to your post :) https://www.dhirubhai.net/posts/dbogdanovic_title-slide-activity-7265108964722237443-7kwG
Geoff Hollingworth the other reason people choose to create 'black' boxes is control of the interoperation of the various components. This is also doublespeak for permitting oneself to cut corners in SW design and implementation (in the interests of TTM at best or bad practice at worst) which the comes with a massive cost in speed of evolution, maintenance costs etc - whoch ends up loaded on the end user as cost, lock in or lack of feature velocity. I can think of cases where this approach may make sense (think overloaded standards designed by committee) but in general had idea... 2c