“Many connection providers use outdated manual procedures for design, sizing, costing and build rather than embrace new technology.
Few companies have so far adopted a GIS-driven (Geographic Information System) approach to design and build that allows more accurate designs more quickly and can inform other processes such as sizing, costing and overall customer service.”
In yesterday’s blog we discussed the Everything of Internet (EoI) and how this model could support other utilities to become telcos as well (ie multi-utilities).
We’ve also spoken about how the OTT (Over the Top) players are skimming revenues off the old CSP business model and even how one research organisation is predicting up to $172B in revenue loss for CSPs in coming years.
One of the many reasons why CSPs find it difficult to compete with OTT players is in the CAPEX outlay required to build and operate a fully-fledged communications network as opposed to the OTT organisations, whose traffic tends to depend heavily on the data networks of the CSPs.
With the EoI, the multi-utility model discussed could actually reduce the difference between the network costs of a CSP and an OTT. The utilities already have network assets in place to service their main utility (eg electricity lines, power poles, lights, etc), so if routine maintenance replaced those assets (eg lights) with new assets that were lights and wireless access points rolled into one, the multi-utility becomes a more cost-effective proposition.*
* Noting that this is a simplistic view that doesn’t include the complexities of backhaul, the assumed negligible cost differential between the old asset and the new asset with built-in wireless, the assumption that routine maintenance refresh rates are short so the old will quickly be replaced by the new and many other reasons.
Similarly, the utilities already have operational systems to run their internal networks (communications and/or other utilities)and BSS to manage their billing, so from a general view the tools and processes will just need to be configured rather than replaced hopefull.Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email