Huawei makes a number of bold claims at MWC replacement event

Huawei released a string of new products at its MWC replacement event in London and claimed to be number one in every field.

At its product and solution launch event, dubbed “5G, Bring New Value”, Huawei unveiled a number of new products including a new chipset, an updated 5G core, new solutions for private networks and optical transmission, a new IP router, and a new software suite.

These products were launched one by one after Ryan Ding, Huawei’s President of Carrier Business Group, already unveiled the 64T64R Massive MIMO 5G base station during his keynote, when he reiterated the claim he made a year ago that Huawei enjoyed 18 months’ leadership over its competitors. When asked to substantiate the claim in a subsequent analyst briefing, Huawei simply said its leadership is in all technologies.

Similar claims, if not down to the specific number of months of its leadership, were repeated in the other product launches. After the new flagship base station and other 5G solutions (Blade AAU, 5G X-Haul for higher network slicing precision, a new optical module for ultra-broadband transmission) were introduced in more details by Yang Chaobin, Huawei’s 5G Product Line President, Henk Koopmans (pictured), CEO of Huawei’s R&D UK, took the stage to unveil the new 5G chipset, called 5G pre-module. It has a 2/3/4/5G-in-one baseband that will work on frequency bands from sub-6GHz to mmWave.

Huawei stressed the reference design that comes with it which will make it easier for Huawei’s customers to onboard the platform and design and make their products. What is puzzling is Koopmans’s claim that this chipset, on a 7nm process, is the world’s most advanced design, and is the world’s first to support both standalone (SA) and non-standalone (NSA) 5G modes, clearly undeterred by the fact that the new Qualcomm 5G chipset launched two days earlier does exactly that, and is designed on a 5nm process.

Huawei’s new private network solutions, called HiCampus, include LAN switch and fibre. It focuses on providing its customers with full wireless connectivity, full fibre, and full AI. The AI capability is highlighted in the context of fast detection of root causes for network errors. Huawei claims that over 85% of its customers’ network errors can be automatically resolved.

Other new products introduced at the event include Huawei’s new 5G core, with highlight on what it calls “deterministic networking” (including E2E network slicing, service & topology awareness, and resource orchestration); intelligent optical network solutions, called OptiX, to deliver enhanced experience for home use (especially supported by embedded AI) and private networks (with passive optical LAN); NetEngine 8000, Huawei’s new IP router for data communications which the company claims to be the world’s first to be able to deliver service level agreement (SLA) assurance. Huawei’s new billing system, called Huawei 5G CBS R20, was the final launch at the event. The company claimed that the billing system has achieved the first live 5G SA implementation, with STC Kuwait.

Another key theme that threads all the product launches at the event was Huawei’s stress on the “green” advantage of its new products, with different percentages of energy consumption reduction attached to the feature introductions. This is assumed to not only demonstrate the power consumption efficiency that can save OPEX for its customers, but also echo the message from the GSMA representative at the event that telecoms industry is the first sector to comply with the United Nations Sustainable Development Goals (SDGs).

The Path to Cloud-Native Applications

The cloud-native approach describes a way of modernizing existing applications and building new applications based on cloud principles, using services and adopting processes optimized for the agility and automation of cloud computing. This e-book describes detailed steps as a part of a successful journey from where you are today to adopting a cloud-native application approach.

 

 

What are the IT investment essentials for 5G monetisation?

Telecoms.com periodically invites expert third parties to share their views on the industry’s most pressing issues. In this piece Francesca Greane, Marketing, Content and Community Lead for 5G World 2020, reviews where service providers should be looking to invest for profitable 5G monetisation.

As communications service providers (CSPs) start to roll out 5G networks, they first face the challenge of figuring out how to go to market with new industry partners and business models.

Existing legacy IT systems that support traditional products are not designed for dynamic 5G service.

As a result, questions such as: What are the key use cases and services that will drive new revenue, and what IT capabilities are needed to support new 5G services are dominating the conversation. As a report by McKinsey put it, operators today are keenly aware that they have to increase their infrastructure investments in 5G technology; something that fills them with both anticipation and resignation.

The main question and source of contention is where these investments should lie.

To help guide the conversation, Ovum’s recent report – IT Essentials for 5G Monetisation – examines the market dynamics and areas of CSP IT investment for 5G monetisation. As the report discusses, many of the high-profile features of 5G such as multi-access edge computing and network slicing will not be immediately available. Instead, 5G network capabilities will arrive in three phases, the final phase beginning in 2022.

However, CSPs that have started deploying their 5G networks cannot afford to wait until the full capabilities of 5G are available to begin monetizing the network. CSPs will need to invest in upgrading revenue management systems so that they are able to charge and bill for 5G services, in policy control for quality of service (QoS) and network slices, and in customer management tools to improve the customer experience and create more opportunities for monetization.

The report also examines the full 5G ecosystem; looking towards the vendors with whom these CSPs will be looking to partner as they invest in their IT capabilities. The report thus outlines key recommendations for vendors, such as focusing on the impact of customer experience on monetisation, vendors are urged to demonstrate their cloud readiness and provide use case-guided transformation techniques, in order to secure new partnerships with these investing CSPs.

You can download the full report – and gain access to all of Ovum’s market recommendations and business-critical insights, by clicking here.

To gain more insights around where you should be investing for your 5G roadmap, claim your FREE ticket to 5G World 2020 (9-11 June, ExCel, London).

With access to three days of content from industry-leading speakers, networking opportunities and 5,000+ tech and telecoms professionals, and the opportunity to meet with hundreds of service providers looking to invest in a new partner, don’t miss out on claiming your free ticket now by clicking HERE.

What we talk about when we talk about digital transformation

Digital transformation is one of the core buzzwords used in the telecoms industry and beyond, right up there with 5G, cloud computing, and artificial intelligence. What sets digital transformation apart from the others is the sheer number of different things it can stand for.

Here we are sharing the opening section of this Telecoms.com Intelligence special briefing to look into how the industry practitioners have undertaken the tasks of digitally transforming their businesses, what are the key success factors as well as the main obstacles to the success of these endeavours, and which approaches they prefer to adopt to tackle the challenges.

The full version of the report is available for free to download here.

In its broadest sense, digital transformation has been used in the socio-economic context by organisations like the United Nations. The 2019 Digital Strategy of United Nations Development Programme (“UNDP”) sees in digital transformation the pathways to the UN’s sustainable development goals. Although it heavily relies on the communications industry to help make the strategy happen, e.g. “digitally deliver policy and programme support”, UNDP’s strategy scope goes beyond that.

When it comes to the communications industry, digital transformation is often cited as an overarching theme to encapsulate all the telecom operators’ efforts to expand their role from mere connectivity provider to that of a digital service platform. However, there are so many components in such a context that one would likely get a different definition of digital transformation from every industry person one asked.

To start with, certain quarters of the industry, still occasionally conflate digitisation with digitalisation. It is therefore necessary to clarify the concept from outset. Digitisation refers to the change from analogue to digital. For example, the process can be called digitised when the application form to open a mobile account can be filled out on the computer instead of in paper form. Digitalisation refers to the change of processes, often focusing on automating previously manual processes, using digital technologies. In the example of opening a mobile account, the process can be viewed as digitalised when the whole application process is done online. Digitisation is therefore a prerequisite for digitalisation.

In the mobile telecoms world, digitisation was completed when 2G replaced (the retrospectively named) 1G networks. Digitalisation, on the other hand, is still an ongoing process and by all accounts will be with the industry for a long time, not the least because digital transformation is so much more complex than digitising the radio signal.

Despite that telecom operators may not agree with one another what digital transformation means to them individually, almost all of them agree collectively that they must undertake the transformation. This is both a strategic imperative and a competitive necessity. It is also widely agreed that the main objectives of digital transformation include:

  • To grow top line revenues as a way of sustaining the business, when the income growth from selling voice minutes, text messages, and data packages has stalled
  • To defend bottom line by improving operational efficiency
  • To develop technological and organisational capability to be more future ready

The following chapters of this report will look into the key steps the industry has taken and still needs to take, the major obstacles to overcome and the worst misunderstandings to dispel, to achieve digital transformation objectives. The discussion and analysis will draw heavily on the first-hand insight and experience from the practitioners.

Modernization of OSS/BSS with Open Source, Part 3: Integration

This is the third article of a four-part series, companions to a set of four webinars[1]. In the first article, we describe how open-source software can speed the evolution of OSS and BSS to a modern cloud-native microservices-based architecture. In the second article we explain how open source can be used to automate business, network and IT to provide initial quick hits that rapidly bring value to a CSP and, eventually, lead to fully automated operations. In this article, and in the corresponding webinar, we describe how open-source integration tools and frameworks can be used to integrate existing and new systems for near-term benefits and pave the way to implementing the cloud-native architecture of the future.

Introduction

To realize the agility and velocity that have become imperatives in the market environment today, communications service providers (CSPs) must transform their service delivery and management infrastructure. This means that the systems that underpin their network and service operations must evolve. These are the operations support systems (OSS) that enable the operator to manage the network and the business support systems (BSS) that facilitate the management of the customer and overall business operations.

The modernization of the OSSs and BSSs is based on three pillars:

Figure 1. Pillars of OSS and BSS Modernization

The importance of integration in OSS and BSS modernization

The CSPs’ software infrastructure has typically evolved over many years, with new systems added to support each new service or technology as needed. The result is that even a small Tier 3 CSP may have hundreds of systems while a Tier 1 CSP can have as many as 1,500 different systems (often with multiple instances of each). Attempts to replace these systems with an end-to-end pre-integrated infrastructure all at once in the past have failed and have often led to business disruption. Therefore, it is recommended that operators proceed in incremental steps, with smaller, department-sized transformations, implemented in multi-phase projects. This iterative process, while optimal, has the inherent requirement to reintegrate systems as they are updated or replaced into the evolving OSS/BSS environment. This constant integration requirement highlights the need for a strong integration architecture that is cloud-native, distributed, microservices-based and containerized.

Modernizing OSS/BSS Integration Architectures

The traditional centralized enterprise service bus (ESB) architecture, on which CSPs relied for integrating systems until recently, is ill-suited to the dynamic integration environment that is essential in the market. Therefore, operators need to move to a modern, cloud-native one, based on a distributed architecture with open Application Programming Interfaces (API) and agile teams using new DevOps development methodologies.

Figure 2. Modern Agile Integration vs. Traditional Approach (Source: Red Hat)

Traditional architectures have centralized integrations into one large platform where integrations are controlled by the team that owns the ESB platform and that has the specialized expertise to operate it. Developing new applications against the platform typically required several attempts to get everything right. The entire integration platform had to be functional for anything to work, and failures of individual components could affect totally unrelated applications. This has resulted in very long cycles to introduce or modify services.

On the other hand, cloud and container-based architectures are developed completely differently. Monolithic applications are broken up into services designed to be small, reusable and loosely coupled to refactor the original application. A container runs one and only one service usually, allowing flexibility in deployment and scalability. Integration between services and applications is distributed among the exact elements where it is needed, no more but no less than is required. Applications and services interact with APIs and expect the services implementing each API to behave as documented without needing to know the implementation detail. Service developers implement their code using whichever language and framework that make sense (and comply with corporate standards). The technical requirements are simple: the service implements the API, no more and no less than documented, allowing the services to be developed and evolved separately with little to no overall system regression testing. This enables the organization to respond more quickly to changing business requirements and priorities and to implement innovative ideas more quickly and efficiently.

The distributed nature of the architecture in Figure 2 describes not only how a cloud native application can be architected, but also how multiple old and new systems can be integrated together in a modern architecture. The distributed services can be microservices or can be wrapped, containerized legacy systems integrated with the new microservices in an overall framework. The right side of Figure 2 shows the containerized elements of an application built with a cloud-native architecture. These services within the application can be newer microservices or legacy ones wrapped with APIs for integration into the overall framework.

Tools for Integrating Systems for OSS/BSS Modernization

CSPs can implement a modern integration architecture using the following set of open-source tools and platforms for the underlying technology:

Integrating microservices inside a new system: New, cloud-native software applications built on containerized microservices require an integration platform to provide the internal communications among microservices, data sources and network elements, whether virtual or physical. Excellent examples of a distributed, cloud-native integration platform are Red Hat Fuse, part of Red Hat Integration, and OpenShift Service Mesh for inter-microservices communication.

Integrating new systems into the existing OSS/BSS complex: To interface the new cloud-native systems with the existing systems, an API management platform is needed. Red Hat 3scale API Management and Red Hat OpenShift Service Mesh are examples of integration frameworks that underpin an API first approach. They provide API visibility and control, security, rate limits, analytics, API keys and a developer portal, allowing the overall management of internal and external APIs.

If the existing systems do not provide RESTful APIs in a service-oriented architecture, they need to be wrapped to provide the APIs. Red Hat AMQ, part of Red Hat Integration, is an Apache Kafka-based platform, providing messaging-as-a service and streams operators, as well as an HTTP bridge. It supports microservice applications, provides an efficient bridge to legacy systems, and enables large-scale solutions.

Integrating and federating legacy systems: Many legacy systems duplicate functions for different work groups and systems in the various organizations, geographies, business areas or network technologies. This often requires manual intervention during provisioning, trouble management or network management processes, resulting in delays and potential errors. Quick-hit integration and federation projects using event and message-based integration technologies bring near-term benefits. A good example is the federation of multiple inventory systems, which leads to reducing database discrepancies and to mitigating the need to access multiple systems. As another example, the synchronization of trouble ticketing systems allows the free flow of information and status among them and obviates the need for manual intervention, thus reducing costs and potential errors and improving customer satisfaction.

The computing infrastructure platform supports the software/container platform with OS, compute and storage resources, creating the right containers for the software with the right computing resources at the right location. It also manages the environment for the container creation and for the management of the API wrapped legacy systems and the new microservices. Red Hat OpenShift is a popular example of such an infrastructure platform.

Conclusion

CSPs’ need for agility and velocity to compete creates requirements for constant integration as the overall OSS/BSS environment evolves piece by piece, leading vendors, systems integrators, and CSPs themselves to adopt new open-source solutions for agile integration. Adopting API led design with new software development methodologies benefits developers with shorter development times and less testing, users with faster implementation of new features and functionality, and business owners with increased business agility. Adopting standard open-source platforms across the business provides a homogeneous technology base, allowing for faster, more reliable feature development at scale. Red Hat Integration and Red Hat OpenShift solutions are ideally suited to the iterative modernization journey for OSS and BSS.

[1] For the webinars, see:
Introduction to modernizing OSS/BSS with microservices-based, cloud-native architectures,
Automate OSS/BSS to drive innovation and reduce operating costs,
Agile integration for OSS/BSS flexibility, reusability and scale,
Transforming OSS/BSS from monoliths to cloud-native applications.

Increase OSS and BSS efficiency with Red Hat agile integration

Disparate operations support systems (OSS) and business support systems (BSS) lack scalability and limit the value of network and application data. IT teams need federated access to legacy systems and data, while developers and partners need secure, easy access to systems.

An application programming interface (API)-centric approach to integration, secured via API management, addresses these issues for modern, containerized technology and application adoption. Exposing data and functionality using APIs supports reuse and modernization of legacy applications and systems, increases agility and scalability of internal and partner OSS and BSS systems, and reduces maintenance costs.

Red Hat’s API-centric agile integration solution for OSS and BSS processes and systems combines multivendor products with customer-owned systems. This Red Hat solution provides a single security framework that also supports TM Forum API specification standards and an automated, service-oriented approach.

Microservices-Based Cloud Native Modernization of OSS/BSS with Open Source

This article is sponsored by Red Hat

Market forces and changes in subscriber needs and expectations are leading Communications Service Providers (CSPs) to transform their entire service delivery and management infrastructure. At the forefront of this transformation is the modernization of the systems that enable the management of network services, the operations support systems (OSS) and systems for managing the customer and the overall business operations, the business support systems (BSS). Current systems were built for a business paradigm that is increasingly outdated; they are rigid, siloed, rely on extensive human involvement and often require esoteric skills. Modernization of these systems enables CSPs to address requirements for becoming the Digital Service Providers (DSPs) of the future: business agility, elastic scale and capacity, service velocity and the ability to continuously reinvent themselves.

CSPs can build a foundation for successful modernization by standardizing on managed open source because it provides tools and services optimal for continuous integration and automation, critical to future-proof the complex digital business transformation.

THE OSS AND BSS MODERNIZATION IMPERATIVES

The modernization of the OSS and BSS systems has three main requirements:

 


Figure 1 OSS/BSS modernization imperatives

In this article, we focus on the evolution to cloud-native containerized microservices, powered by managed open source software.

THE OSS AND BSS MODERNIZATION VISION

CSPs need to drive significantly lower costs and a commensurate increase in agility in their business and operations to survive in today’s competitive environment, Their legacy OSS and BSS systems were designed primarily to support the people who operate the workflows (hence, the names Operations and Business Support Systems). These systems need automation and orchestration to evolve toward operating the business, autonomously, under the control and oversight of people.

The new environment will be microservices based. OSS and BSS functions will be instantiated as containerized microservices interconnected via a service mesh, guided by business policies and governance rules, and ultimately overseen by people. This architecture will eliminate silos and provide the underpinnings for continuous integration and continuous development (CI/CD).


Figure 2. OSS/BSS Modernization Vision

EVOLVING TO A MICROSERVICES ARCHITECTURE

The modernization of the OSS and BSS systems should proceed in steps. Undertaking a massive transformation of OSS and BSS systems could result in business disruption and would likely not succeed. Instead, the service provider should start by identifying discrete tasks and well-defined business processes to automate. This enables the organization to reap quick optimization results with minimal disruption, to prove the new technology, and to give employees the opportunity to work in a microservices-based environment. At the same time, the telco can containerize and enhance old systems with API management wrappers. This will require minimal development and disruption, but will improve the reliability, scalability, and IT operations costs.

As new capabilities are added, they should be added as containerized microservices in a cloud native architecture. Once the operator has a substantial set of microservices, it can proceed to redefine the management domains, collapsing the separate domains into a rationalized cross-domain architecture that is optimized for automated operations, not duplicating the organizational structure of the CSP.


Figure 3. OSS/BSS Modernization Journey

As for “monolithic” legacy systems, they will be re-platformed (“lifted and shifted” into containers for more efficient IT operations) and refactored over time into smaller pieces, which may eventually be further refactored into sets of microservices. This may happen all at once, or in stages, balancing the refactoring of the legacy monolith with building new (and refactored) features and functions on the new cloud native architecture.

ENABLING MICROSERVICES ACROSS THE ORGANIZATION

The migration to microservices should be accompanied by important changes across the organization. In the words of Jez Humble, “Reminder: If you’re building microservices, you’re building a distributed system.” Therefore, along with the modernization journey described above, the operator should carefully introduce organizational changes. For example, to maximize the benefits of the distributed microservices environment, the operator should incentivize collaboration, adopt DevOps principles, and introduce the right organizational capabilities for continuous development, continuous testing and continuous delivery. Only when the service provider has taken this comprehensive approach to modernization will it fully realize its goal to become a digital service provider.

CONCLUSION

The modernization journey will be a long process, but one whose benefits match the continuing investment required. A “big bang” investment would likely only deliver benefits in the outer years and may lead to business disruption. However, this transformation process means that the operator will be operating in a hybrid environment, gradually migrating functionality to the cloud. This ongoing transformation with continuous development and integration can best be achieved by using open source technology to ensure that there is no “lock in” to proprietary or obsolete technologies. The open source community is now large enough that technologies that are superseded drive conversion tools available to the next technology. Thus, open source-based transformation future proofs the systems.

Amdocs launches ‘future ready’ RevenueONE billing system

Telecoms software vendor Amdocs has unveiled its bid to bring billing into the 5G and cloud era, in the form of RevenueONE.

The Amdocs marketing team saw fit to describe it as ‘game-changing’ in the headline of the press release. What game that is, whether it needs changing and whether or not this launch does so, we’ll leave to others to establish. The top line is that this is a billing system designed to help operators exploit all the new revenue opportunities we’re constantly being told have been generated by 5G and the move to the cloud.

To flesh out the press release we spoke to Ron Porter, Product Marketing Manager at Amdocs. He explained that 5G, IoT, connected environments, etc create all sorts of new billing opportunities for operators, but legacy billing systems aren’t geared to exploit them. A lot of this comes down to the kind of speed and flexibility that comes with having virtualized functions in the cloud, especially the edge. He concluded that the ultimate aim was to offer a billing system that is ‘future ready’.

“Amdocs RevenueONE brings together proven scalability and cloud-native architecture to accelerate the launch of new 5G services, while supporting existing products and offers, said Anthony Goonetilleke, Amdocs President of Media, Network and Technology. “At its core, the RevenueONE blueprint was built to scale, and was proven to support 200 million subscribers on a single platform.  This robust architecture allows CSPs to handle the velocity of new service launches, and the variety of new business models, that will come with 5G, while cutting time to market from days to minutes.

“Our goal was to continue to significantly reduce our hardware footprint while scaling to support the influx of new connected devices and services. Utilizing edge-based architecture to reduce network traffic, we believe RevenueONE will grow with our customers as consumers embrace new business models and services.”

The BSS/billion/digital transformation space is pretty competitive at the moment, with various vendors queueing up to giver operators the tools to capitalize on their 5G investments. If products like RevenueONE enable even half of what they promise the onus, as ever, is on operators to adapt the way they do business. 5G is still at an early stage, but the winners of it will surely be those operators that use it as a platform for genuine innovation.

Telecoms industry set to reveal its hopes and fears

It’s that time of the year when Telecoms.com once again conducts the signature Annual Industry Survey. Answering it will not only let us know what you think, but will benefit the telecoms industry as a whole, and in turn, yourselves too.

The 2019 Annual Industry Survey (AIS) has just gone live. True to its mission, this survey is designed to take the pulse of the telecoms industry, in particular of those topics most pertinent to operators, suppliers, technology vendors, analysts, consultants, and everyone else with a stake in the telecoms ecosystem. It’s my job to write collate the responses and present them to you.

This year’s survey covers many of the core technology topics the telecoms decision-makers are most interested in reading about, including Industry Landscape, 5G, Digital Transformation, IoT, and BSS/OSS. Undoubtedly the readers of this story, you, are in the best position to tell us, and the industry, how you see the current status of the industry and where you see it heading for. So, please, click here to answer it.

I was thinking about giving this story a title like “Your Industry Needs You”, but that would be too Kitchener-esque, plus I don’t have the beard to go with it. Instead, I’ll go full Churchillian: I have nothing to offer but a high-quality survey report for free, a sense of contribution, and the chance to win a new Apple Watch.

If this is your first experience with our AIS, or if you’re simply interested in finding out how correct (or incorrect) we have been with our understanding and predictions, feel free to check out last year’s results.

Another Vodafone billing fail hits roaming customers

Vodafone UK suffered yet another billing-related PR disaster as some of its customers piled up huge charges while roaming and were consequently disconnected.

The incidents took place over the weekend, just in time to make it onto mainstream media grateful for something to report on a Monday morning. One of the first Vodafone customers to flag the matter up on Twitter was David Maddison, whose trip to Malta was compromised by him suddenly being hit with five grand in charges that he wasn’t expecting.

After a few hours Vodafone tweeted that it was aware of the problem and promised customers would not be incorrectly billed. This was apparently insufficient for Andy Pearch, also travelling in Malta, who was seriously stressing out about being incorrectly billed. He was eventually placated by Vodafone, but remained unimpressed by the speed with which the problem was addressed.

“We are very sorry that yesterday, some customers could not use data or calling services when roaming abroad,” said Vodafone’s emailed statement. “This was due to a technical error, which we have now fixed. Any affected customer should restart their phone to ensure that services are resumed.

“As a result of the issue, some customers are receiving billing messages in error; we are working through these as an urgent priority and removing any errors from customer accounts. Customers will not be charged and do not need to worry about contacting us as we are proactively checking accounts and fixing any issues.”

Vodafone also explained that The spending limit cap was inadvertently triggered by a software change, which must have brought back bad memories of is major BSS fail three years ago. It added that it affected around 40,000 customers, but it’s now fixed. Hopefully for Vodafone this was an isolated glitch, and it’s bad luck that it happened on a Friday, but it still represents another setback for a company that has historically been criticised for its customer service.