Author: Phil Knight

This is the first of two blogs dealing with the topic of signalling evolution of APIs, the second part ‘5G network APIs’ will be published shortly.

As the telecom world transitions into the 5G era, one of the less visible but most significant changes is the shift in signalling protocols. Traditional signalling systems like SS7 (Signalling System 7) and Diameter are being replaced by HTTP/2-based APIs in 5G Standalone (5G SA) networks. But why is this change happening? Let’s unpack the evolution.

A Brief History: SS7 and Diameter

SS7: The Legacy Backbone

SS7 is a signalling protocol suite developed in the 1970s and used in 2G and 3G networks. It enables everything from call setup and routing to SMS and roaming. While it has been incredibly durable, it’s based on circuit-switched architecture—something the modern, data-heavy world is moving away from. When it was defined the only companies that could access the closed SS7 network were trusted fixed and mobile operators, consequently the level of in-built security was minimal. Over time this approach failed as piece by piece less scrupulous players were allowed access to the network and a multitude of scams emerged ranging from phishing to artificial SMS revenue enhancement.

Diameter: The 4G Successor

With the introduction of LTE (4G), SS7’s limitations prompted the use and further development of Diameter, an IP-based protocol designed for authentication, authorization, and accounting (AAA). It supports more advanced use cases but was still deeply tied to telco-centric infrastructure models. At the same time the industry was trying to retro engineer security features into the legacy SS7 network, which proved only partially successful. Interestingly, the MNOs (apparently quite deliberately) did not embed a speech solution into the 4G standards, relying on a difficult to implement solution called VoLTE, which even today several operators have failed to get working for a variety of reasons that were glossed over by the standards community who wrote the 4G standards. 

 Enter 5G Standalone and Service-Based Architecture (SBA)

There are two main variants of 5G, 5G NSA and 5G SA. NSA is basically 4G signalling and control with additional faster 5G bearers added to that architecture. However, 5G SA isn’t just faster LTE—it’s a complete re-architecture of the mobile core, centred on Service-Based Architecture (SBA). In this model, each network function (like session management, policy control, etc.) is exposed as a web service, using RESTful APIs over HTTP/2.

This shift is fundamental, not just in technology but also in policy. Exposing a rich suite of APIs deep inside the network core is a completely new venture for the Mobile Operators, and it’s one of the key reason HTTP is replacing SS7 and Diameter. It remains to be seen whether there is any real demand for this, for instance location information accessed via APIs has been available for years but has stimulated very little revenue.

Why the Shift to HTTP in 5G SA?

1. Cloud-Native Architecture

5G is built to be cloud-native from the ground up. HTTP/2 aligns perfectly with modern microservices and container-based environments like Kubernetes. SS7 and Diameter were never designed for this world.

2. Stateless Communication

HTTP APIs support stateless interactions, which simplifies scaling and resilience. This is critical for services like network slicing, IoT, and URLLC (Ultra-Reliable Low Latency Communication).

3. Flexibility & Extensibility

HTTP/2 and RESTful APIs are widely adopted in IT and web development. This allows for rapid integration with new services, easier innovation, and a broader talent pool for development and maintenance.

4. Improved Performance

HTTP/2 supports multiplexing, header compression, and efficient binary framing—features that reduce latency and improve signalling efficiency compared to Diameter’s AVP (Attribute-Value Pair) model.

5. Security Built-In

HTTP-based communication in 5G leverages TLS (Transport Layer Security) by default, ensuring encrypted and authenticated communication channels. SS7, in contrast, has long been criticized for serious vulnerabilities and lack of inherent security. This is not surprising because when SS7 was specified there was little or no need for the sort of security we see today, because it was a closed network connecting trusted partners, and at the time had a high technology cost to enter the environment. Of course, all of that has changed.

6. Standardized API Interface

The 3GPP standards define well-documented APIs for each 5G core network function. This modularity makes it easier to build, update, and scale networks without needing proprietary implementations or extensive vendor lock-in (in theory at least).

 What Happens to SS7 and Diameter?

• SS7 is already in decline, mostly used for backward compatibility with 2G/3G networks.

• Diameter is still relevant in 4G and will coexist with 5G Non-Standalone (NSA) deployments for some time.

• In 5G SA, HTTP-based service interfaces (like Nnrf, Nsmf, Namf) replace Diameter interfaces (like S6a, Gx, etc.), marking a definitive shift.

 The Road Ahead: HTTP is Just the Beginning

HTTP/2 and REST are just the starting point. The telecom industry is also exploring HTTP/3, gRPC, and event-driven architectures using Kafka or Webhooks for future evolutions of 5G and even early 6G concepts.

This signalling shift isn’t just about protocols—it’s about aligning telco infrastructure with the broader digital transformation, enabling networks to be as agile and programmable as the applications they serve. The lack of agility of mobile and fixed networks has long been a millstone around the operators, and it can be argued has led to them being almost completely frozen out of the service plane, and its associated revenues, and losing more of the voice and messaging revenues they once enjoyed than was necessary.

There is a cautionary note here that needs to be added, a lot of complexity in mobile networks today comes from the need to interwork between 2G, 3G, 4G,5G NSA, and 5GSA, mobile operators are notoriously poor at retiring old systems and protocols, and the use of a completely new core network architecture and protocol set, will mean another geometric expansion in the number of interworking cases to be adequately engineered, and tested.

Final Thoughts

Replacing SS7 and Diameter with HTTP in 5G Standalone is more than a technical upgrade—it’s a strategic move that redefines how networks are built, operated, and scaled. There is a strong prevailing view that as telecom becomes more software-driven, embracing modern web technologies is not only smart but necessary. There are alternatives factions who maintain that embracing the internet to this degree simply opens the telecoms networks to mass security attack, and that whilst it may not be glamourous, there will always be money in a purely bearer based business, and that this rush to embrace the latest internet and technology trend is just another in a long line of somewhat ridiculous technology purists innovations that have never returned anything like the investment they required to bring into service, the classic example being the MNO portals all of which cost millions in development and then sank without trace within two years.

The winners in this transformation will be those who can marry telco-grade reliability and historical security with web-scale agility—and arguably HTTP is the bridge that makes that possible 

Deployment of modern telecoms networks is changing markedly. It seems barely has one technology become the standard before it is being viewed as obsolescent. It makes deploying major new network elements something of a lottery in terms of the technology choice.

Another facet of the same phenomena is the segmentation of the industry with the tier1 vendors downplaying new technology initiatives until they have managed to port their own product lines creakingly across to adopt them, and the smaller nimbler innovative companies talking up the latest and greatest as the only viable way forward.

Many operators are wringing their hands over the right approach to virtualisation, 18 months ago the question would probably have been whether to invest in Openstack with its improved maintenance and network operations and pay the downside complexity price. Today they are probably wringing their hands over whether to use containers or virtual machines, with containers winning the day. Of course, you can always ask your friendly vendor, but alas the answer you will get will probably match exactly what the development of their current product set has achieved.

Virtualization is not a new concept. It was deployed on IBM mainframes in the 1960s. it was only around 2006 that Intel introduced hardware support for virtualization on x86 processors, though its adaption in the mobile core is still somewhat bizarrely far from ubiquitous.

The NFV infrastructure and architecture was one of the first NFV recommendations to be adopted by ETSI. Appliances such as gateway nodes, policy controllers and subscriber data management were ported from physical hardware onto virtual machines. ETSI defined the framework for compute, storage, OSS and networking capabilities.

Other vendors that have emerged in recent years have specifically developed their functions (VNFs) to run exclusively as NFV. This is known as cloud native application development. So, we have two approaches. Approach 1 – port the application from a physical appliance to virtual machines and approach 2 – develop and deploy VNFs on NFV known as cloud native.

We have now seen that the NFV approach is also changing with the VNFs being further decomposed into what are called microservices. ‘Microservices’ is an architecture style where complex applications are composed of small independent processes and communicate with each other using APIs and use HTTP or JSON as the protocol. This is the fundamental approach being considered in 5G networks, very relevant over the next 2 years as operators fall over each other to implement 5G standalone architectures. Using APIs affords us the opportunity to move to stateless processing and exploit HTTP transactions with an adjunct state store. HTTP has the built-in ability to find the correct state store that uniquely identifies the session.

Once microservices are introduced, they can be run more efficiently in what are termed ‘containers’. Containers provide an alternative approach to virtualization using a long-standing method for partitioning in Linux known as namespaces. The biggest difference between containers and virtual machines is that containers use the host software and host operating system and have no requirement for a hypervisor whereas virtual machines do need to have their own operating system installed.

At Azenby we are beginning to see most applications from PGW, PCRF, HSS, IMS and all the newly defined 5G nodes, move towards a cloud native and container approach, this is a prerequisite to a 5G SA core.

Maintenance and orchestration (MANO) has now become a crucial part of the NFV and containerization strategy. There is more need than ever to have a MANO layer for the daily operation of virtual machines and containers. Some virtualization vendors such as VMWare and OpenStack have a degree of MANO already built into them.

 

Figure 1 Containerized Applications and virtual machine side by side.

We believe that the orchestration layer is essential, and the introduction of VNFs and containers suggests that MNOs will need to have a best-in-class MANO layer though in our opinion orchestration is still immature, highly complex and seems to be in constant evolution.

Containers are much simpler to orchestrate than VMs. Containers have far fewer management and configuration requirements. As a result, container orchestration is a much simpler problem to solve and a number of solutions exist today, some examples are given below.

• Kubernetes is an opensource container orchestration solution from Google and generally considered to be one of the best-in-class solutions and almost the de-facto standard. It has been adopted by many Telco’s. Many vendors are providing Kubernetes branded distribution.
• Docker provides an infrastructure to create, manage and deliver containers. It is independent of Kubernetes but when combined with it, provides an extremely powerful option for container delivery and orchestration.
• Puppet provides a container infrastructure and orchestration layer.
• Red Hat OpenShift container platform is a leading enterprise distribution of Kubernetes optimized for continuous application development and multi-tenant platforms.

Network Function Virtualization has been at the heart of recent network transformation. The view from Azenby is that this is a fast evolving arena and as such due consideration must be given to ensure that the correct virtualization plan is in place, a plan that will last well into the future and accommodate the fast-changing technical landscape, including micro services and containers.

Formulating your strategy for virtualisation is a crucial element for determining your overall approach to 5G deployments. These decisions are probably the most crucial calls your business has to make in getting the 5G architecture right. At Azenby, we would be happy to help you make sure that you get it right. Contact Azenby and let’s start a discussion.

Depending upon your preferred reading material, there are now over 300 operators worldwide in more than 120 countries trialling and demonstrating 5G, be it mobile or fixed wireless access. Looking specifically at the mobile sector, as we like to do, over 50 operators in 30 countries have heralded the arrival of 5G in their network although just how many conform to exactly what parts of the 5G 3GPP specification is still open to conjecture.

What we do know for sure is that the focus has certainly been on adding elements of the 5G radio interface to the existing 4G core. I think we can also say that many MNOs around the world have done their first piece of work towards getting a feel for 5G and some have certainly claimed a 5G launch. Despite the number of trials and tests going on, the vast majority of MNOs are yet to select their vendor for the first serious 5G standalone rollout whilst the non-standalone deployments we are seeing today are really limited to working with the existing 4G vendor.

Considering this state of play, at Azenby we don’t think it is too late for MNOs to start to draw up their tick list for evaluating vendors offerings for a fully-fledged standalone 5G network. In thinking about this, we considered very carefully the fact that for the first time, this is not a ‘bolt-on’ technology upgrade to the last generation of mobile architecture. Getting 5G right is not just a technical decision, difficult though that is, it’s about architecting a network that allows for vital collaboration between MNOs and partners to deliver new services, to new customers, and to be much more than just the connectivity player in the 5G world. It’s also about adapting technologies beyond the 3GPP specifications to achieve scale, faster service deployment and lower costs. This means a new approach to operating networks and moving away from traditional diagnostics to networks that think their own way out of trouble. The challenge facing mobile operators goes way beyond getting just the 5G vendor decision right but nonetheless, getting the 5G supplier aligned to your overall strategy is an imperative.

Azenby has compiled a set of questions we believe every MNO should be asking themselves and then their prospective 5G vendor:

Support for the commercial aspirations

What is the business case for 5G?

When you strip away the vendor hype, there are some underlying advantages to 5G though many would say they do not add up to the complete ecosystem change that the hype suggests is necessary. To test this thesis, ask the vendor what the business case is for 5G as opposed to 4G simple expansion.

What is the business case for replacing existing infrastructure with 5G?

This is a variation to the previous question, where inevitably it will be suggested that equipment that is not end of life will need to be written off and upgraded. This questions the business case for doing that, again once the hype has been cut through.

What benefits can 5G bring during the roll-out period when it is not ubiquitous.

This is a crucial consideration, the answer to which can have huge implications of the rate of spend required in network roll-out and consequently the timing of investment. It is vital to understand the impact on services if the roll out of 5G services is not ubiquitous, in particular if network slicing is being used. This is a good example to press for a view on, as slicing may only be effective when 5G has been deployed across the whole geography where the service is to be used, and this will impact the customer sales process, perhaps to such a degree that it is unusable.

How can the network slicing capabilities and QOS management features in 5G be used to develop new propositions for new customer segments, particularly in IOT, and differentiated service delivery to different customers for a given proposition? Please provide uses cases for above propositions.

The Slicing and QOS tool kit has to be used carefully for its benefit to be greater than the potential adverse impact to some customers. Is the tool kit sophisticated enough with adequate feedback loops, decision logic and automatic optimisation of the resource allocation? Naturally, the customer SLAs must reflect the degree of sophistication (or lack of) and the system must be capable of measuring and reporting service delivery against SLA.

Has the vendor any business case models showing the benefits of network slicing?

This question asks the vendor to quantify the propaganda around network slicing, giving for instance a couple of user cases that demonstrate how effective it is in theory. Similarly, it asks if the vendor has models that can be used to predict the effect in a live network, particularly supporting high mobility use cases.

Have the results of network slicing testing been benchmarked in a real deployment?

It is really important to see evidence that the modelling output has been benchmarked against a real deployment of their equipment. This can’t be relied upon if it is slideware alone.

What 5G ‘unique’ features can be supported on your 4G infrastructure e.g. a proxy of network slicing, MIMO techniques?

This question builds on the previous questions and is a theme about what the vendor is doing to help optimise previous network investments. Specifically, it asks if they have managed to make any of the new 5G features backward compatible to some degree with the existing 4G infrastructure.

Network Architecture

What is the hardware and software upgrade path from non-standalone to standalone 5G for RAN and Core, and are there any impacts on any terminals

This question is self-explanatory, the expectation is that the NSA core will have a smooth upgrade path to the SA core whilst preserving all services. The second part asks for any incompatibilities that can occur between NSA and SA architectures that impinge on the mobiles themselves.

Can I take your equipment in a mixed vendor radio environment, e.g. just deploying 5G economically?

Here we assume the answer will be that each site has to be a single vendor site for the radio, but it would be interesting to see if they have considered any methods to install 5G as a standalone.

What are the benefits of taking your equipment as an upgrade, compared to if I was a new customer to you?

Often vendors offer deals to new customers that are as good or better than the deals they offer to existing customers. This question is designed to overtly explore that.

What bandwidth efficiency will you guarantee for me for my deployment Mbits/s/km

Again, there is a lot of hype about efficiencies and this is an impossible question to answer but posing the question will yield some interesting insights.

Spectrum Aggregation: How will Spectrum Aggregation at 5G differ from 4G, in terms of the range of frequency bands included and the pairings permitted, including Supplementary Downlink and CBRS spectrum? Can the additional capabilities available in 5G be retrospectively applied to your 4G equipment in my network?

Higher speeds in 5G are in part made possible through more versatile spectrum aggregation as well as the new air interface and massive MIMO. If similar powerful spectrum aggregation capabilities existed for 4G, this would extend its life and delay 5G spend for some MNOs. This is also a good time to find out how much of the frequency bands and pairing options available are set/constrained by standards and how much is vendor commercial choice.

What 5G specification options are you making available and when, and what are the prerequisites for us to deploy them.

Like 3G, and certainly 4G, the 5G specs come with a lot of options. So, understanding what the vendor includes in their 5G offering is very important. At the high level this could be is URLLC, eMBB and mMTC included. Diving deeper into the specs one could ask is de-coupling UL/DL included? But really, there are 100s of ‘options’ in the 5G specs so understanding what you really need and what is being offered is crucial.

Explain your strategy and policies for the support of interoperability and the use of proprietary or open internal interfaces

Again, this question is self-explanatory, there are a huge number of internal interfaces emerging in 5G and a generic policy statement on the use of interfaces and interoperability should be pre-requisite to any contract.

How much of your 5G offering is dependent upon legacy infrastructure?

This question probes how much of the 5G offer is complete in its own right, and how much additional equipment is assumed to be sourced by the customer, DNS, Routers, Firewalls, security/encryption functionality.

What is the scaling capability of your 5G Core to support MMTC/IOT i.e. how many devices can each core node support and what are the upgrade paths to support further volumes?

This is a question designed to tease out capacity of the core but also the underlying principles they have used in determining that capacity, it is actually a very difficult question to answer in a meaningful way unless a model can be provided.

What is the scaling capability of your 5G Core to support mass small cell deployment i.e. how many small cell base stations can each core node support and what are the upgrade paths to support further volumes?

This question is self-explanatory

What is the scalability of your 5G OSS for supporting mass small cell deployment i.e. the volumes of small cell base stations that can be managed by the OSS instances?

This question returns to the much promised but little delivered topic of orchestration but in this case in support of small cells where the node counts can be much higher.

Operational Considerations

Automation: How will network automation features in 5G compare with those in 4G, particularly in RAN where the operators continue to bear high costs of labour-intensive design, optimisation and operational processes?

Automation has not been a great success story through the 2G-3G-4G journey. Some progress in automatic frequency planning, and SON in RAN and SDN in transmission are a far cry from self-configuring, self-optimising, self-diagnosing and self-healing networks which we envisaged more than 15 years ago. In fact, NFV has made a real difference indirectly in this area. There is much talk about AI in RAN automation. Time to sift fact from fiction and put pressure on the vendors to make a real difference. Will real RAN automation happen only when RAN virtualisation arrives? It’s also time to see how much of this RAN automation will come from functionality and features embedded in vendors’ equipment and how much from adjunct analytics platforms. It’s not just RAN either, of course, there is still quite labour-intensive design, implementation and operational processes in transmission and to a certain extent in core and backhaul too.

Explain your supply chain including sustainability of the vendors and any involvement in trade sanctions even one step removed, including component sourcing, and 3^rd party services

This question is self-explanatory, but in today’s global supply environment, an issue with a single component involved in e.g. Chinese sanctions, can bring a line to a shuddering halt.

Is the software supported in your home market?

This question stems from the very public critical source code failure at a major MNO in Europe, where support was outsourced to such an extent that the in country local support team were completely unable to even restore service. Hence it is both a security and support issue. Don’t become dependent upon some small vendor who is more than one step removed from your prime vendor to fix bugs or even just renew your SSL Certs when the network is on its knees.

What additional measures to secure AUSF in 5G will you support

The focus of this question is to see if the vendor has a high entropy and physically secure solution for their AUSF, such as for instance a hardware based HSM.

Does your 5G system offer protection and security from cloned or fake/rogue small base stations

The question looks to understand if the vendor is aware and defends against rogue base sites which are easily implemented seeking to steal IMSIs or other confidential information through man in the middle attacks.

 

We know that this list is just the tip of the iceberg but if it has convinced you to start pulling together your own list then we have done some good today. Compiling your long list of FAQs is a vital part of evaluating your strategy for commercialising 5G and these decisions are probably the most crucial calls your business has ever had to make. At Azenby, we would be happy to help you make sure that you have all the bases covered. Contact Azenby and let’s have a discussion.

There’s a very famous Monty Python sketch about brontosauruses. John Cleese plays ‘Anne Elk (Miss)’ who is being interviewed on a chat show about her new theory, which relates to Brontosauruses. Miss Elk’s eventually expounds her theory which is that Brontosauruses are:

‘thin at one end, much much thicker in the middle, and then thin at the other end’

You can’t really knock the insight, if you’ve not seen the sketch its worth a quick look on you tube, there is a live version, but you might want to look from about 2 minutes in.

All very interesting, but you might be wondering what it has to do with MVNOs, fair question, do let me explain.

MVNOs come in many different shapes sizes and architectural styles. At one end of the spectrum are what are referred to as thin MVNOs, these are companies that sell their own mobile brand, but rely very heavily on their host MNO for the majority if not all of the telecoms services. In some cases, these companies really are just sales channels and a brand. Some of them are capitalising on their brand strength and others are serving specialist market segments.

At the other end of the spectrum there are ‘thick’ MVNOs, these are companies that use a host MNO for the radio access network, but do much more of the remainder of the service themselves. For instance, they may have their own on-line charging system to bill mobile usage, or even their own PGW, the gateway device through which a customer’s data traffic passes, they may provide their own SIMs and have their own IMSI and network codes.

There isn’t really a clear definition of the dividing line between thick and thin MVNO but you get the drift I hope. What we do know is that there a lot of them about these days. There are over 140 MVNOs in the UK alone.

MVNOs developed quite a while ago, probably 25 or 30 years ago. At the time the first MVNOs I came across at least were all thin, for a couple of reasons, firstly the MVNOs themselves didn’t really have a lot of knowledge about mobile and so were struggling to get the terminal fulfilment and branding applied to a mobile offering let alone engage in any more complex and expensive mobile technology, and secondly because at the time the host MNOs were paranoid about giving any control away of the telecoms services to an MVNO that wasn’t a member of the exclusive club of companies that had bought some very expensive spectrum. The way they saw it, they weren’t about to give away any of that value.

Time moved on and a side effect of the thin architecture rapidly became apparent to the MVNOs, which was that they were heavily locked into their host MNO. That might not have mattered during the initial contract and subsequent honeymoon period between them and their new host MNO partner, but after a few years, they tended to fall out of love with their host MNOs. There were two drivers for this discontent, one was that the reality of cost pressures sunk home on the MVNO, and the other was that the management of the host MNOs became disenchanted with their wholesale MVNO businesses, and tended to neglect it and milk it for cash.

The problem that the MVNOs then had was that they were so dependent of their hosts that to risk a move to another host could cause such a service disruption that staying in an unhappy marriage with their original host was the only viable option. For instance in the UK, many MVNOs were at the lower end of the market selling prepay services, without properly registering customers, leading to a position where a change of host MNO would require a SIM swap…… tricky to do if you don’t know who your customers are or where they live!

The natural effect of this was for many MVNOs to try to become less dependent on their host MNOs. There were two main drivers for this. One was so that they had much more leverage in commercial negotiations with their host MNO because they always had a viable threat of moving elsewhere. The second was to be able to differentiate services and have a greater control over tariff structures. For this independence to be real, and perceived as real by their host, they needed to wrest several pieces of functionality from the host, typically:

• Their own IMSI range and MNC code
• Their own HLR/HSS
• Their own charging services
• Their own GGSN/PGW gateways
• Their own voice and SMS infrastructure

An MVNO that provided all of the above themselves would definitely be in the ‘thick’ category and would have quite a realistic opportunity to move hosts if they needed to, to find a better commercial offer elsewhere. Pretty much that is where we are today, with a mix of MVNOs, but many of them electing to provide quite a lot of the technology of the mobile core, charging, and admin systems themselves.

As time goes on the big thing that is changing from a market point of view is, as everyone knows, the consumption of data. Data usage is increasing at something like a 40% CAGR, leading to some pretty high payloads being sent via the MVNO cores.

At the same time the MNOs seem to have a policy that the wholesale rate for a thick MVNO will be no lower than that for a thin MVNO, even though the thick MVNO is doing more of the ‘work’. I assume this is back to the old philosophy of wanting to keep the MVNOs as dependent and locked in as possible.

Now you’ll recall the reason why MVNOs like the idea of being thick is that they get independence and can control their own propositions. A thin MVNO has to go to their host for each and every change which can be a painful experience as they compete for IT and network change slots which are being shared in providing changes for the host MNOs own services, and they will be very much the poor relation in this respect. Ideally the thick MVNO will control all of the components needed to control their proposition themselves, and so they can make more of these changes without being dependent on the MNO engineering teams and processes.

As time has gone by, I have noticed that by far the majority of differentiation in services is commercial, there is very little differentiation in data functionality, other than what domains are zero rated, which does differ from MVNO to MVNO. Even speech services are very similar, as is SMS.

So, if we cycle back to the requirement to maintain MNO independence it can be argued that time has shown us that independence comes from being able to control your own charging tariffs, be it real time or post pay, and to be able switch between MNO hosts by having the HSS/HLR and SIM, or in a couple of years time by using e-SIM technology to seamlessly switch the IMSI in use. The net result is that the drivers for being at the thicker end of ‘thick MVNO’ are rapidly disappearing.

Looking forward, as 5G turns up with the expected very high volumes of data traffic the reasons why an MVNO would want to carry the payload traffic become even less obvious because:

• The majority of differentiation comes from (and with 5G will continue to come from), the charging and tariffing systems such as the OCS which are not involved in handling the high data payload
• The costs of handling data are related in some way to the volume of data, and since the MNOs show no sign of giving a discount when the MVNOs support the PGW, the data increases expected with 5G will simply increase thick MVNO costs

An attractive scenario for a thick MVNO of today might be to reconsider their architecture for 5G data payload, asking their host MNO to support it for them, in particular because given that the MNO will be working at higher scale it will have a more economic solution than the MVNO could achieve.

This leads to a migration towards a thinner network architecture for the MVNO than they may have considered optimum in the 2G, 3G, 4G era.

That takes me back to Miss Anne Elk, I think her theory of brontosaurus’s can be reapplied to MVNOs, something like:

‘MVNOs were very thin at one time, much much thicker now, and will be thin again in the future’

At Azenby we have worked with many MVNOs, to help them from business strategy, architectural analysis, through to vendor procurement and host MNO choice and negotiation. We believe passionately that periodic reviews of ‘cast in stone’ decisions such as architectural structure of networks should be undertaken. We have seen many companies sleepwalk into an inappropriate technical architecture because they have not tracked technology and industry changes closely enough, which is understandable once the operational pressures of the day take over their attention. If you would like to discuss how Azenby can help your MVNO business please get in touch.

 

 

Hacking – It’s definitely a worry for mobile networks, they need to be so careful about ensuring the security of customer data, both the payload and the signalling, and all the customer identity information. If they lost it, it would hit the headlines for days, and they would have a hefty fine to look forward to. The brand damage would be immense, perhaps even fatal.

They also have to be pretty careful about network availability, we saw this thrown into the limelight when O2 lost their network because of some incorrect software coding and processes in their Ericsson deployment. I am sure other operators were so quiet because they unanimously whispered ‘there but by the grace of god…..’ under their breaths.

Then there is also the suspicion of state sponsored intervention into a foreign country’s telecoms infrastructure, particularly highlighted by the level of mistrust towards Huawei in many western countries, even to the extent of outright bans and the ripping out of seemingly fully functional Huawei equipment well before its end of life.  All very cloak and dagger, but in the modern world something that regrettably needs to be taken seriously.

So, assuming the network is fully protected the next question might be, ‘if state sponsored interference is a big deal, then what else could be used to disrupt the a mobile network or to compromise user’s data or identity security?’

An interesting question and one answer does spring to mind, that is, at the heart of 95% of mobile connections these days is a highly functional piece of extremely complex technology in the form of a smartphone. The supply of these devices tends to be dominated by a limited number of massive corporates, with a lot of also-rans struggling to compete for the left overs. The big players at the time of writing are Apple, Samsung, Huawei in the UK at least, with more than 60% of the market, followed by Lenovo, Xiaomi, LG & ZTE (all stronger in the Asian sphere). There are of course regional variations, for instance Pixel in the US and some Indian vendors that are successful in India but as yet have little international presence.

One can therefore ask, if a vendor was in an intelligence co-operation with a state, presumably the state of its origin, then what could be done to disrupt the security of communications, or the privacy of the population, of another state, where a significant market share of devices was from this vendor?

Assuming that the mobile terminal operating systems are either:

• completely proprietary and owned by the terminal vendor as is the case for iOS and Apple
• or at least capable of having proprietary extensions built into it as is the case for Android

then in those cases there is flexibility for the terminal vendor to integrate malicious functionality of their own choosing into the operating system. Added to this there will also be the possibility for the manufacturer to build ‘malicious’ software into the device baseband and to have this deployed as part of their standard build.

Given this, what could be done?

At this point we should mention that it isn’t really news to say that smartphones can host malicious software, for years we have seen apps that surreptitiously dialled premium rate numbers or sent premium rate SMSs or let the app vendor mine large amounts of user information that could then be sold on, or used to access accounts elsewhere. This is a big risk, however, users in general understand these risks, they accept the risks, and largely those that care attempt to minimise their exposure to these risks by being ‘sensible’ in their behaviours with devices, be they tablets, or phones or PCs.

We would argue there are a few key differences when the malicious code is installed by the terminal vendor, and these are:

• Firstly, the malicious software can be in every terminal that the vendor produces, it is not dependent on any user behaviour, e.g. access a particular website, or download a particular app.
• Secondly, the malicious software can be down almost at the binary level and many times harder to find than anything at the app level.
• Thirdly, most of the controls against malicious code are actually at the app level, be that by user scrutiny, or app store scrutiny.

This means that if for instance a vendor has 20% of the market then it opens up attack options not only aimed at the owner of the terminal but also to some degree at the mobile network as a whole, and to the population as a whole. Two attacks spring to mind for example:

• 20% of mobiles over stressing the network by continually going into and out of flight mode 10 times a minute is probably going to overload the mobility components of most networks and bring effective communication to a halt.
• Gaining access to a random 20% of the population’s address books will allow a near complete network map of communications between the population, and all associated telephone numbers.

To implement these two attacks would require very little, a very simple broadcast instruction invoking a routine in the case of the first attack, and a periodic small upload from participating mobiles in the second, which would be unnoticed given the scale of data usage and the propensity for these devices to ‘phone home’ anyway.

Another aspect to consider is that whilst the integrity of the core network’s software is subject to on-going scrutiny by the customer operators, and by some governments, the same is not true for mobile terminals. These receive little or no external scrutiny, other than from the amateur software community.

You can argue of course that there are other similar risks in for instance the PC domain, where there are really only 2 laptop operating system suppliers, and one of those is also a supplier of tablets, and smartphones, so in terms of potential impact of malicious vendor code perhaps having the full suite of smart devices is the holy grail and we should all be casting a suspicious eye in Apple’s direction. Of course we do not suggest that Apple would be involved in any behaviour of this nature, but merely pointing out that the control of the vital operating systems for many types of devices, is in the hands of an ever decreasing number of private companies.

The conclusion we at Azenby reached is that the industry has taken many decisions over the years in terms of network integrity, customer bill/privacy and integrity, and largely these have been successful. However, the technology and the regulatory regimes have evolved to allow an uncontrolled mass of powerful mobile terminals with unregulated (or at least self-certificated) software on them to populate networks. These represents a potential massive threat to the mobile networks, and to the privacy of the population in general.

Looking forward the situation seems fairly binary, with two options:

Option A: accept the risks and assume that governments will privately take whatever measures are necessary individually to protect the national interests they represent, with for instance segmented networks that are relatively immune to the mass of potentially rogue terminals sponsored by foreign governments. In this case the population as a whole continue to have their privacy invaded and their services disrupted, though often in return they receive some free services which they value.

Option B: address the risks, through:

• customer groups start forming that do not accept the current state of affairs and use their purchasing power to only purchase terminals and services that offer some form of guarantee around the security of their information.
• and networks/governments extend their concerns over supply of network equipment to the supply of terminals as well, and take a view on the maximum percentage of terminals they are prepared to accept on their network from the various major vendor.

We believe that the attraction of free, highly functional services will continue to anaesthetise the population as a whole to the loss of their privacy with all of the attendant risks that brings, and that choice A will continue indefinitely. The loss of privacy and the erosion of network security will continue bit by bit, with a continuous stream of high profile but not disastrous incidents bringing this to the fore periodically but never triggering a major re-think. Coupled with this, as each new yearly cohort of users comes into the market knowing nothing different, an assumption that there is no privacy on-line will become rooted in common culture as the norm.

Lets just keep our fingers crossed that when the chips are down our government has had a closer eye on this than the population as a whole.

At Azenby a lot of our clients have asked us to undertake technical due diligence for them, normally when there is some sort of company acquisition or merger. It’s a standard business process. You want to buy something and not unnaturally you want to know if it is worth buying and therefore call in the due diligence (DD) team to check out the target of the acquisition. This is especially sensible given that it’s so often a unique one off and complex purchase and the value comes as a result of a complement to existing business. Azenby has performed more than 10 major DD activities in recent years across Europe and Asia.

In the mobile industry, our speciality, a technology DD covers at least some of the following issues:

• Current deployments
• Assets end of life
• Plans to evolve
• Failures and incidents
• Staffing levels and competencies
• Project processes
• Accreditations
• Spectrum and spectrum plans if applicable
• Network economics and how the network is supporting the company strategy and the marketing vision.

Often a buyer has considerable expertise to do the technical due diligence themselves, but there are a couple of reasons why general expertise can be augmented with outside help. For instance, the buyer may be expanding into a new market segment and so by definition they don’t know the new domain in sufficient detail.

Another reason that an external resource can beneficially be used for DD is a little more subtle. The result of a DD can be that it results in a decision not to buy the target company. Indeed, a not-to-proceed decision is the norm in due diligences as realities should be continually tested against hard business benefits of an acquisition. In this case the two companies risk parting ways with a feeling of mutual irritation. However, since the target is likely operating in a sector close to the buyer, NDAs with strict confidentiality will have been obtained. In many cases the staff involved in the DD are then sent on gardening leave for a few months. In the event that the sale does not proceed, it’s quite logical to insist this be the case because those staff will have seen future plans, products, planned investments and all manner of commercially sensitive material, in all likelihood from a direct competitor of the buyer.

From the buyer’s perspective a thorough DD process is essential, which means they need to use some of their best people, yet those same people might be forced out of the business for months of gardening leave if the sale does not proceed, not a great result from any perspective! If an external company is used, they probably have more experience in DD, but also if the sale stalls critical staff are not quarantined.

There are some rules we have distilled from our Due Diligence experience, we like to think of it as a survival guide:

Rule 1 : The data room

All relevant data should be put into the data room, some of it potentially redacted for a variety of reasons. So, rule 1 is that the DATA ROOM IS NEVER COMPLETE OR ON TIME so don’t expect it to be! Expect to have  numerous iterations asking for a more complete set of data through asking specific questions.

Rule 2: Beware the sophisticated data room system

Sometimes, the data room itself is set up by a 3^rdparty with a super secure, super access controlled and logged data room system. All well and good you would think until as a data room user you discover you have to download a client to your laptop to get access to it, and your laptop never works again! We have even resorted to using a different device from our normal laptop to work in the data room.

Rule 3 : Don’t believe a word

Never trust the interviews, as you continue work your way through the material in the data room there will come a time where you have friendly discussions with the staff of the target company, those at least who feel they can talk in public. In general, some will be completely honest, some will obscure by omission, and some will have embellished their memory of events (shorthand for they will obscure to your face!). Trust no-one! Just use the written data, and get any verbal statements backed up in writing, or even better have the corroborating documents entered into the data room.

Rule 4 : Carry a helmet

Prepare to be complained about. For the team actually doing the DD and delving into the target company, maybe going places the target would rather you didn’t, and by necessity asking for corroborating evidence, can generate friction. As a result, it is not unknown for the target company to complain about the amount of time that is being sunk into answering questions, or the fact that questions are being asked that are confidential or not relevant. Ignore all of these complaints, if anything they are a sign that the DD is being done effectively and some difficult truths may be surfaced.

Rule 5 : Beware your Instincts

Instincts or suspicions can result in serious trouble. Picture the scene. You have been doing a DD for a week, and you are convinced there is a potential problem with some aspect of the target but you haven’t fully resolved the issue. You are asked for a report on how things are going from the buyer…. You mention your concerns….. and suddenly, after a chat between the two CEOs, you are requested to provide explanation.  The target has refuted all your suspicions and demanded proof, and without details to support suspicions an untimely and potentially difficult withdrawal is necessary.

There are other uses for the expertise and metier of Due Diligence. With very large projects, most especially those of a highly political nature, or involving many levels of subcontract, delays can build to catastrophic levels as unwillingness to declare shortfalls is escalated through the network. DD allows large projects top to bottom sanity checks. This is very difficult for engaged and interested parties, some of whom may be facing damages and costs as a result of declaring over runs. Our experience has been that this process can bring much needed extra clarity to the formal reporting.

At Azenby, we frequently advise clients using DD techniques both during acquisitions, but also at many stages in projects where an independent view can be of use. For more information contact phil@azenby.com.

At Azenby we are always interested in and tracking what innovation is happening in the world of mobile. One of our product design and development experts Phil Knight has been observing what is happening in the world of mobile device innovation:

Last week I looked at all my old phones, I have a terrible habit of keeping all of them, each time I upgrade, yet another phone goes into the drawer. I have them going all the way back to the old feature phones, and even a couple that could barely do SMS and could double as dumbbells, the batteries were so heavy. I even found my very first phone, a Siemens brick that took so long to charge that even if I put it on to charge as soon as I got in from work, by the morning it was still only half charged by the time I had to leave again. It could store up to 30 numbers though!

We have certainly moved on a long way from those days, and actually over the whole course of the history of our industry, I would have to say it is the terminal vendors who have really played the major role in getting the industry to where it is. Sure the networks have been built and some clever people have written and agreed some clever standards, but the terminals are what have given the mobile industry popular appeal. It’s all the customers see of the mobile industry after all and all they care about, well the price plan as well I guess.

Anyway, back to my beauty parade of old phones, so there it was, a long line of mobiles that have changed immeasurably from the early days and added huge amounts of functionality and style, or so it seems. I say this because there is another very noticeable trend that seems to have happened over the last 5 years; all the phones look the same, maybe a little bigger, with screens that are so good now they are beyond the visual acuity of my eyes, but basically the same designs from all of the vendors for the last 5 years and more, when someone says smartphone these days, there is no question about what it looks like….. they all look identical!

This can’t be the case surely, they may look the same, but they must do lots of new things? Well not really, some modest innovations like finger print sensors, and even (if it works) face recognition, but pretty much identical units with the addition of greater definition. This leads me to the question, whatever happened to all the innovations in terminals that took us from my Siemens brick of 25 years ago to the smartphone of today? The innovation appears to have stalled, we seem to have plateaued.

Maybe this is unfair, maybe the identical terminal designs we see from every vendor is really totally optimal, and there is nowhere else to go and that is why all the innovation that has really captured the customers imagination in the last few years has been  the OTT apps they run. I am joking of course, you can see lots of options and it is odd they haven’t emerged For instance, in the laptop market we see 2 in1 device formats where the same device can be used in tablet or PC mode, both very effectively. The same could be applied to mobile terminals for instance, a smartphone form factor that is for every day mobile use which the user then opens up to provide a screen twice the size for browsing.

Then there is the input mechanism, it is so primitive, still reliant on one way or another a thought being turned into the motion of  fingers on a keyboard or other iconic touch displays, though here I was really pleased to see an announcement from Facebook about attempting to make an interface that would allow text messages to be constructed from brain wave analysis Sounds tricky but well done for trying to do something really innovative.

There have been other innovations of course, smart watches are an interesting idea, but pretty much a notification adjunct to the terminal with some new health  considerations. Also, a brief foray into glasses that try to present augmented reality in a seamless fashion, but largely attempts so far haven’t been engineered well enough to have mass appeal. Perhaps that will be a new thread, the practical implementation of visual input output devices which link back through the terminal, even to the extent where the need for a screen on the terminal becomes obsolete, it becomes relegated to just handling wide area communications.

Perhaps I have unrealistic expectations, but it seems to me that we have reached a point where the technology is more able than the ideas behind it pushing new applications. Perhaps we are missing the true visionaries of the past who combined their ability to see a way forward with the ability to motivate and deliver. Maybe the duopoly of Operating systems and their limitations is hampering innovation. One thing I am sure of though, this continual optimisation of existing designs with gimmick products to justify new releases and higher price points, is really all rather dull.

 

If you have any thoughts or comments on this post please feel free to get in touch.

In this blog, I thought I would try and look at the app developer community from the mobile operator perspective and bring out some thoughts, I gave a richer version of this as a lecture at The Mobile Academy in London, hosted by Mobile Monday London and UCL. It seemed to be appreciated and so here are some extracted points.

1. Think Scale

Firstly, think about the mobile operators, they are enormous companies but have you ever thought about the scale of them. For instance their networks cost billions literally to build and to fund, in the UK they spent more than 20 billion pounds on spectrum for their 3G networks, money which they have never got back in reality.

They have huge customer bases, have you ever done the maths to realise that with churn at 1.5 to 2% per month, then a big operator with 20,000,000+ customers like EE for instance can easily lose 4,000,000 customer a year and has to replace them just to stand still in terms of market share, and it costs several hundred pounds to acquire each customer.

So a company of this scale is not likely to be the most easy to talk to, certainly as a small developer, so my first thought is, make sure your apps use pretty well supported functions, if you rely on some new obscure network function that is only supported on one network its very unlikely that you can influence the deployment of the feature across all networks, so make sure you know the enablers you are using are widely available.

2. Think Climate

The other aspect of the mobile operators that is quite interesting and maybe not as apparent outside of their world is the climate that they are operating in. They have always been very competitive with each other for market share in particular. However they now feel that the regulatory framework is constraining their ability to earn the money they need to re-invest in the networks, for instance the constant erosion of the money that they receive for terminating calls. Similarly they feel it is almost immoral that they invest billions in networks, and then the over the top (OTT) players can exploit these networks at almost no cost and take their voice and messaging revenues. I guess it feels like a slightly one sided playing field. That’s why the price plans are changing from individual minute and message charging to large bundles and data charging.

3. Think Bandwidth

It’s worth looking at the technology that the mobile networks are built from as it can seriously impact the performance of applications.  Around 20 years ago the GSM system was specified and built mainly around Europe, it then spread worldwide. It came with no inherent data capability until the arrival of GPRS which is still in service today and is the most ubiquitous mobile data bearer that is available. It has a very limited throughput typically only 9kbits/s in many cases, and it can normally be usurped if a voice customer needs the channel for a call. Then there followed 3G and more lately 4G generations of technology. These all improve the data throughput into the Mbits/s range practically with 3G and its variants up to 10s of Mbits per second with 4G. Of course, all of these systems are shared and will slow down when more users access the same data bearer and it is shared between them. So be aware that in theory your app may have to work or at least do something sensible when it is on a data bearer ranging from 9kbites/s up to 25Mbits/s!!

4. Think Latency

There is another aspect to performance that is often ignored against the headline data rate, and that is latency. Again, this has improved significantly over the various generations of the mobile data bearers. Latency is really key to performance and on long latency systems like GPRS, the ping time can be several hundred milliseconds, compared to a few 10s of milliseconds on 4G. So if you can build a ‘non chatty’ app it will perform faster than one which uses multiple serial requests for data.

5. Think Roaming

It’s worth mentioning roaming in this context for two reasons, firstly it’s expensive today but getting cheaper so your app may have to evolve to acknowledge this. Secondly, even if the home network has rock solid 4G that goes like a rocket, when you roam you can end up on anything from GPRS at 9kbits/s upwards, so you really do need to think about how this manifests itself as a user experience, especially when roaming around Europe for instance is very affordable and customers use data as if they were at home.

6. Think SMS

SMS is interesting for a couple of aspects, firstly it’s a really easy way to monetise applications because the charging models are very mature (there are loads of aggregators around that will let you send and receive SMS), and flexible, and secondly it is ubiquitous. SMS is a strange product, it’s 20 years old, and has never been enhanced, where else can you see a 20 year old product where the owners of the product have not tried to enhance or replace it – a really strange behaviour by the operators that left the door wide open for OTT players like WhatsApp and iMessage.

One last thing with SMS, you need to be aware that in some areas of the world it is prone to attack by spoofing, faking, DOS and premium scams.

7. Think M2M / The Internet of Things

M2M is a fascinating part of the industry. It does appear that after a long and painful birth it really is growing now. You have to think differently about some M2M apps, for instance if it is a mass app with millions of terminals then all of the economics around terminal repair, and network loading are very different from those for a smartphone with human owner. Similarly the security aspects are different and have to be thought about very carefully, I have seen one project in particular where misuse of a SIM security feature caused mass failure in operation and wrote off all the savings that the project was supposed to deliver. So one thing to watch for is often M2M applications are about cost saving and so tend to run on tight margins, margins which it is easy to destroy with very simple mistakes. On the plus side there is a healthy ecosystem for M2M enablers developing, and over time it probably is the biggest growth opportunity in the industry.

8. Think Voice

Lastly I have to mention LTE and voice. This is actually a comedy of errors by the operators. On 2G and 3G the voice and messaging services were completely embedded into the radio system including specialised channel coding for their support. This means an OTT app will struggle in terms of performance using a 2G or 3G data bearer compared to the embedded service. Along comes 4G and for some reason that none of the operators can explain other than ‘we forgot’, voice is an add on layered on top of a QOS assured 4G pipe. So bizarrely the operators have no more of an advantage with voice than any other player, eg. Skype, Vonage, Viber and in fact since the operators have almost no experience of OTT  mobile VoIP they have played the best cards for one of their key services straight to the OTT industry.  Actually this probably means that the industry will change substantially in a way that will be quite unexpected …  but that’s an issue for another blog I think !!