Tag: orchestration

A3 in open RAN

What is open RAN?

Open RAN (with a capital O) describes a set of standards defined by the O-RAN Alliance. The standard architecture of Open RAN is shown in the figure below, and the major parts of the architecture include:

  • The Service Management and Orchestration Framework (SMO), which will most likely form the umbrella RAN management system for all RANs going forward. It includes:
    • A design environment for rapid application development
    • A common data collection platform for management of RAN data and mediation for the O1, O2 and A1 interfaces
    • Support for licensing, access control and AI/ML lifecycle management
    • Existing OSS functions such as service orchestration, inventory/topology and policy control.
  • The RAN Intelligent Controller (RIC), which is responsible for controlling and optimising RAN functions. It has three main objectives: to receive a stream of data on which to make optimisation decisions, to ensure that services maintain the required performance levels, and to ensure RAN efficiency, balancing the needs of all users. The RIC has two components:
    • The Non-Real Time RIC (Non-RT RIC) offers closed-loop control functions which last for more than one second. Some of these functions are available today in C-SON. The placement of the Non-RT RIC in the SMO and not in the RAN is to secure access to contextual data and use it to optimise the RAN, something that the RAN nodes CU, DU and Near RT-RIC can’t do. rApps are developed for the Non-RT RIC and ingest radio environment data (e.g. device location, signal strength measurements), device data (e.g. positioning and trajectories, plus application-level information), cross-domain information (e.g. insights from the core) and external data (e.g. weather). There are a wide range of potential rApps being developed – including those involved in traffic steering, load balancing, capacity optimisation and energy optimisation. They also involve complex self-organising network functions, such as the dynamic orchestration of radio and transport domains; and various management functions, such as management of the cloud, slices and policy.
    • The Near-Real Time RIC (near-RT RIC) offers closed-loop control with functions lasting between 10ms and one second which support faster data streams and fast control of RAN functions. xApps are developed for the near-RT RIC and, unlike rApps, have access to data from specific CUs and DUs, and receive instructions from the rApps on actions to take. Use cases include network control, such as radio bearer management, load balancing, handover and interference mitigation, and mMIMO beamforming optimisation. Their development is challenging and requires specific knowledge of radio network  parameters and of currently vendor-proprietary APIs, as well as the ability to tightly interact with the vendor’s CUs and DUs.

Enter your details below to download an extract of the report

O-RAN overall logical architecture

Source: O-RAN Alliance White Paper, Feb 2020

Overview of the xApp/rApp market and opportunities for vendors

This section looks at the trends in xApp and rApp deployment over the next couple of years and provides some detail from analysis of their current availability.

As previously discussed, telcos have a wide range of requirements when upgrading the RAN: improved performance, cost reduction, improved spectrum and capital utilisation, as well as developing its future potential to underpin new revenues. This broad goal offers many opportunities for both RAN-specialist and other vendors to develop a range of simple to more sophisticated intelligence and automations. Opportunities will be dependent on market factors including:

  • The amount of telcos which will choose to convert, or ask vendors to convert, the already deployed capabilities of their existing C-SON into rApps/xApps. We expect this to be a popular option where the telco feels comfortable with current performance and capabilities
  • As the non-RT RIC can also interoperate with legacy RAN, which will help a smooth transition of existing capabilities into the open RAN, the number of new rApps needed in the short term might be smaller
  • Telcos, many of which will be Tier 1s with the ability to develop their own A3, will also impact the early market. Our interview discussions suggested that the majority of DIY telcos will solve specific network situations where there is no available vendor solution and that, therefore, the creation of home-grown solutions will reduce over time. However, there was also discussion of telcos wanting to become rApp developers in order to monetise their IP, which is likely to see a steady stream of app development from telcos.

Table of Contents

  • Executive Summary
    • The need for A3 within open RAN
    • A3 market development
    • Actions for telcos and vendors
  • Table of Contents
  • Table of Figures
  • Quick review: What is open RAN?
  • Overview of the xApp/rApp market and opportunities for vendors
    • rApp market
    • xApp market
    • Assessing the potential of rApps and xApps
  • A3 requirements in open RAN
    • Interference management
    • Channel estimation
    • RAN design and planning
    • Handover management
    • Load balancing
    • Traffic steering
    • RAN management
    • Beamforming
    • Service-related
    • Power management
    • The use of A3 in the SMO
  • Conclusion
  • Index

Enter your details below to download an extract of the report

5G network slicing: How to secure the opportunity

Network slicing is central to unlocking the 5G opportunity

There has understandably been a lot of talk and hype about 5G and network slicing in the telecoms industry. It promises to bring greater speeds, lower latency, greater capacity, ultra-reliability, greater flexibility in the network operations and more. It also pledges to support high device densities and to enable new services, new business and operational models as well as new vertical opportunities.

Given that the rollout of 5G networks is expected to involve a significant investment of hundreds of billions of dollars, there is a need to look at how it might address new business opportunities that previous generations of cellular networks could not. Many, including us, have argued that the consumer business case for 5G is limited, and that the enterprise segment is likely to represent the greater opportunity.

One highly anticipated aspect of 5G is that it will be built on virtualised infrastructure. Network functions will run as software in datacentres, rather than on dedicated appliances as in the past. This will mean that operators can deploy and make changes to functions with far greater flexibility than ever before. It also offers the promise of enabling multiple logical end-to-end networks – each intended to meet specific needs – to be “spun-up”, operated and retired as required, over the same shared hardware. Traditionally, achieving such a multi-service outcome would have required building dedicated stand-alone networks, which was rarely a viable proposition.  This capability is the essence of network slicing.

Figure 1: Diagram of network slicing

5G network slicing diagram

Source: STL Partners

Enter your details below to download an extract of the report

This report will explore the concept of network slicing and what it means for enterprise customers. It will have a particular focus on one aspect of network slicing through the enterprise perspective, that being security. The first section will cover how we define network slicing whilst the second will dive into what the enterprise security-related concerns are. We will then assess the implications of these concerns in the third section, before identifying ways that telcos can address these concerns in order to accelerate the adoption of network slicing.

Our findings in this report are informed by a wider STL Partners research programme that STL Partners has conducted with telcos and enterprises across several verticals, including transport, defence, utilities, logistics and smart cities.

Enterprise security concerns with network slicing are rooted in the fear of the new and unknown

Network slicing is inherently complex. Multiple networks being created over common infrastructure, each serving different customers, use cases and devices means that management and orchestration of network slices is something that telcos are still grappling with. It not only represents a change in technology but also a shift in the way that the network lifecycle is managed, which is new and unfamiliar to telcos and their enterprise customers. Current security protocols will not necessarily be equipped to cover many of the new dimensions that network slicing brings. This new shift in the way things work will result in various enterprise security concerns. Changes in the network architecture with slicing, with multiple logical networks each having their own resources and sharing others, also poses questions of how the security architecture needs to evolve in order to address new risks.

Enterprise customers define security as not only about preventing services being compromised by intentional malicious attacks, but also about preventing service degradation or disruption due to unintentional operational or technical failures and/or negligence, unplanned breakdowns etc. Due to the interdependence of slices, even if a fault occurrence happens, it could consume resources in one slice, just like an attack would, which would affect the reliability or lifecycle of other network slices that share the same resources. Regardless of how the performance of a slice gets affected, whether it is by a malicious attack, a natural disaster, a bug or unintentional negligence, the consequences are ultimately the same. These are all, in some way, related to security. Therefore, when considering security, we need to think beyond potential intentional malicious attack but also unintentional negligence and unplanned events.

What if my network slice gets compromised? What if another slice gets compromised? What if another slice is eating up resources?

We outline these three key questions that enterprises have around their security concerns, as potential tenants of network slices, in the body of the report.

Table of contents

  • Executive summary
  • Introduction
    • Network slicing is central to unlocking the 5G opportunity
    • Dynamic, virtualised, end-to-end networks on shared resource
    • Slicing might come about in different ways
    • Slicing should bring great benefits…
  • Enterprise security concerns with network slicing are rooted in the fear of the new and unknown
    • What if my network slice gets compromised?
    • What if another network slice is compromised?
    • What if another network slice is eating up resources?
  • Security concerns will slow adoption if not addressed early and transparently
    • Concerns and misconceptions can be addressed through better awareness and understanding
    • As a result, enterprises project concerns about public networks’ limitations onto slicing
    • The way that network slicing is designed actually enhances security, and there are additional measures available on top.
  • Telcos must act early and work more closely with customers to drive slicing adoption
    • Ensure that the technology works and that it is secure and robust
    • Organise and align internally on what network slicing is and where it fits internally before addressing enterprise customers
    • Engage in an open dialogue with enterprise customers and directly address any concerns via a ‘hand holding’ approach
    • Don’t wait for maturity to start testing and rolling out pilots to support the transition and learning process
  • Conclusion

Enter your details below to download an extract of the report

The Devil’s Advocate: SDN / NFV can never work, and here’s why!

Introduction

The Advocatus Diaboli (Latin for Devil’s Advocate), was formerly an official position within the Catholic Church; one who “argued against the canonization (sainthood) of a candidate in order to uncover any character flaws or misrepresentation evidence favouring canonization”.

In common parlance, the term a “devil’s advocate” describes someone who, given a certain point of view, takes a position they do not necessarily agree with (or simply an alternative position from the accepted norm), for the sake of debate or to explore the thought further.

SDN / NFV runs into problems: a ‘devil’s advocate’ assessment

The telco industry’s drive toward Network Functions Virtualization (NFV) got going in a major way in 2014, with high expectations that the technology – along with its sister technology SDN (Software-Defined Networking ) – would revolutionize operators’ abilities to deliver innovative communications and digital services, and transform the ways in which these services can be purchased and consumed.

Unsurprisingly, as with so many of these ‘revolutions’, early optimism has now given way to the realization that full-scope NFV deployment will be complex, time-consuming and expensive. Meanwhile, it has become apparent that the technology may not transform telcos’ operations and financial fortunes as much as originally expected.

The following is a presentation of the case against SDN / NFV from the perspective of the ‘devil’s advocate’. It is a combination of the types of criticism that have been voiced in recent times, but taken to the extreme so as to represent a ‘damning’ indictment of the industry effort around these technologies. This is not the official view of STL Partners but rather an attempt to explore the limits of the skeptical position.

We will respond to each of the devil’s advocate’s arguments in turn in the second half of this report; and, in keeping with good analytical practice, we will endeavor to present a balanced synthesis at the end.

‘It’ll never work’: the devil’s advocate speaks

And here’s why:

1. Questionable financial and operational benefits:

Will NFV ever deliver any real cost savings or capacity gains? Operators that have launched NFV-based services have not yet provided any hard evidence that they have achieved notable reductions in their opex and capex on the basis of the technology, or any evidence that the data-carrying capacity, performance or flexibility of their networks have significantly improved.

Operators talk a good talk, but where is the actual financial and operating data that supports the NFV business case? Are they refusing to disclose the figures because they are in fact negative or inconclusive? And if this is so, how can we have any confidence that NFV and SDN will deliver anything like the long-term cost and performance benefits that have been touted for them?

 

  • Executive Summary
  • Introduction
  • SDN / NFV runs into problems: a ‘devil’s advocate’ assessment
  • ‘It’ll never work’: the devil’s advocate speaks
  • 1. Questionable financial and operational benefits
  • 2. Wasted investments and built-in obsolescence
  • 3. Depreciation losses
  • 4. Difficulties in testing and deploying
  • 5. Telco cloud or pie in the sky?
  • 6. Losing focus on competitors because of focusing on networks:
  • 7. Change the culture and get agile?
  • 8.It’s too complicated
  • The case for the defense
  • 1. Clear financial and operational benefits:
  • 2. Strong short-term investment and business case
  • 3. Different depreciation and valuation models apply to virtualized assets
  • 4. Short-term pain for long-term gains
  • 5. Don’t cloud your vision of the technological future
  • 6. Telcos can compete in the present while building the future
  • 7. Operators both can and must transform their culture and skills base to become more agile
  • 8. It may be complicated, but is that a reason not to attempt it
  • A balanced view of NFV: ‘making a virtual out of necessity’ without making NFV a virtue in itself