O-RAN Technical Steering Committee (TSC) & Workgroups

Zahid Ghadialy, Senior Director, Technology & Innovation Strategy
July 28, 2021

After having looked at the O-RAN Alliance approach, philosophy, timelines, and detailed internal architecture, we will now provide an overview of the O-RAN Technical Steering Committee (TSC) and the Workgroups (WGs).

Figure 1: The O-RAN Alliance Technical Steering Committee (TSC)

Figure 1: The O-RAN Alliance Technical Steering Committee (TSC)

 

Let’s start with an overview of TSC. The TSC decides and provides guidance on O-RAN technical topics. In addition, it approves O-RAN specifications prior to board approval and publication. It consists of member representatives and the technical workgroup co-chairs, representing both members and contributors.

As shown in Figure 1, within the TSC, there are 10 Work Groups, 4 Focus Groups, an Open Source Community and a Minimum Viable Plan Committee. Some of these are new additions to the TSC so they have been shown in red. Let’s start looking at them one by one, starting with the Work Groups (WGs).

Figure 2: O-RAN Work Groups and their objectives

Figure 2: O-RAN Work Groups and their objectives

WG1 is the ‘Use Cases and Overall Architecture’ workgroup. It has the overall responsibility for the O-RAN architecture and use cases. It identifies tasks to be completed within the scope of the architecture & use cases and assigns task group leads to drive these tasks to completion while working across other O-RAN work groups.

WG2 is the ‘Non-Real-Time RAN Intelligent Controller and A1 Interface’ workgroup. The primary goal of Non-RT RIC is to support non-real-time intelligent radio resource management, higher layer procedure optimization, policy optimization in RAN, and providing AI/ML models to Near-RT RIC.

WG3 is the ‘Near-Real-Time RIC and E2 Interface’ workgroup. The focus of this workgroup is to define an architecture based on Near-Real-Time RAN Intelligent Controller, which enables near-real-time control and optimization of RAN elements and resources via fine-grained data collection and actions over E2 interface.

WG4 is the ‘Open Fronthaul Interfaces’ workgroup. The objective of this workgroup is to deliver truly open fronthaul interfaces, in which multi-vendor DU-RRU interoperability can be realized.

WG5 is the ‘Open F1, W1, E1, X2, Xn Interfaces’ workgroup. The objective is to provide fully operable multi-vendor profile specifications, compliant with the 3GPP specifications, for F1, W1, E1, X2 & Xn interfaces. If a limitation is discovered, then this workgroup will propose 3GPP specification enhancements. It should be noted that X2 is a fundamental interface that is needed for Open RAN 4G or LTE networks to work seamlessly. We have explained this in our blog post here.

WG6 is the ‘Cloudification and Orchestration’ workgroup that seeks to drive the decoupling of RAN software from the underlying hardware platforms. It also aims to produce technology and reference designs that would allow commodity hardware platforms to be leveraged for all parts of a RAN deployment, including the CU and the DU.

WG7 is the ‘White-Box Hardware’ workgroup whose objective is to specify and release a complete reference design to foster a decoupled software and hardware platform. The promotion of open reference design hardware is a potential way to reduce the cost of 5G deployments which will benefit both the operators and vendors.

WG8 is the ‘Stack Reference Design’ workgroup whose aim is to develop the software architecture, design, and release plan for O-RAN Central Unit (O-CU) and O-RAN Distributed Unit (O-DU) based on the O-RAN and 3GPP specifications for the NR protocol stack.

WG9 is the ‘Open X-Haul Transport’ workgroup. It focuses on the transport domain, consisting of transport equipment, physical media, control, and management protocols associated with the transport network.

Finally, we have WG10, ‘OAM and O1 Interface’. This workgroup is responsible for the OAM requirements, OAM architecture and the O1 interface. All these activities were part of workgroup 1 earlier but have now been moved to WG10 after its formation.

In addition, there are four Focus Groups as we saw earlier. Focus Groups deal with topics that are over-arching the technical workgroups or are relevant for the whole organization.

Figure 3: Standard Development Focus Group (SDFG)

Figure 3: Standard Development Focus Group (SDFG)

The Standard Development Focus Group (SDFG) plays the leading role in working out the standardization strategies of O-RAN Alliance and is the main interface to other Standard Development Organizations (SDOs) that are relevant for O-RAN work. It also coordinates incoming and outgoing liaison statements.

The Test & Integration Focus Group (TIFG) defines O-RAN’s overall approach for testing and integration, including coordination of test specifications across various WGs.

This may include creating end-to-end test and integration specifications; profiles to facilitate O-RAN productization, operationalization and commercialization; approaches to meet general requirements; and specifications of processes for performing integration and solution verification.

The TIFG plans and coordinates the O-RAN Alliance Plugfests and sets guidelines for the 3rd party Open Test & Integration Centers (OTICs).

In October of 2020, the O-RAN Alliance successfully conducted its second worldwide Plugfest and proof of concept to demonstrate the functionality as well as the multi-vendor interoperability of O-RAN based network equipment. A total of 55 companies came together at four venues across Asia, Europe, and North America to address the functional, interoperability and performance challenges of the O-RAN ecosystem.

OTICs provided a collaborative, open, and impartial working environment for testing and integration with guidance from TIFG.

The Open Source Focus Group (OSFG) is responsible for dealing with open source-related issues for the O-RAN Alliance. Its responsibilities include the planning, preparation and establishment of an O-RAN open-source community, development of open source-related strategy, and coordination with other open-source communities etc. The biggest task that OSFG has accomplished was the successful launch of the O-RAN Software Community and as a result OSFG now remains in a dormant mode as the Software Community has taken over most of the responsibilities of the OSFG.

Finally, we have the Security Focus Group (SFG) which focuses on security aspects of the Open RAN ecosystem. It collects the security requirements and solutions from all other WGs, negotiates as necessary to ensure uniform requirements and designs among the relevant WGs, thereby ensuring a standardized security architecture, specifies security requirements, architectures, and frameworks in support of open interfaces defined by other O-RAN WGs and finally, it publishes security guidelines that span across the entire O-RAN architecture.
We have already looked at the O-RAN Software Community (OSC) in an earlier blog post, so there is no need for duplication here.

Figure 4: The role of Minimum Viable Plan Committee (MVP-C)

Figure 4: The role of Minimum Viable Plan Committee (MVP-C)

The final piece of TSC is the Minimum Viable Plan Committee (MVP-C). O-RAN specifications have been driven by bottom-up initiatives from each of the WGs, guided by the O-RAN baseline architecture. In contrast, the Minimum Viable Plan (MVP) provides top-down coordination of the priority list of work items across working groups based on the operator survey, prioritized use cases, TIFG Blueprints and OSC Progress.

The MVP-C enables an integral process which is efficient, effective, and sustainable in the O-RAN TSC. Internally, MVP enables the O-RAN Alliance to more effectively coordinate the work to enable valuable use cases in a timely manner. Externally, MVP provides a clear view to the Ecosystem regarding O-RAN roadmap and priorities.

The flowchart in Figure 4 explains the role of MVP-C in the TSC.

In March of 2021, the O-RAN Alliance published the first release of the MVP which included previously published specifications and additional work items in the following areas:

  • Open fronthaul specifications
  • Open transport
  • Open hardware
  • Open stack
  • Open cloud
  • Testing and integration guidelines for the formation of Open Testing and Integration Centers (OTICs)

It is expected that subsequent O-RAN releases will extend the MVP with additional features and functionalities based on continuing surveys and updates of the operators’ deployment priorities.

Having discussed the TSC and the workgroups, we will now turn our attention to discuss each workgroup and their deliverables in the future blog posts. In the meantime, please see the video below, which details the TSC and the workgroups.

Further Reading:
Introduction to O-RAN Philosophy
Introduction to O-RAN Timeline and Releases
An Overview of O-RAN Architecture
Why We Need the Open RAN Movement Even Though 3GPP Interfaces Are Already Open
Parallel Wireless Reaches All G O-RAN Solution Milestone
Everything You Need to Know About Open RAN: An e-Book

Translate »