Strategy for adding features from new 3GPP releases to the reference tools

[dsilhavy]

Description

Typically, the reference implementation of a certain technology or feature in the 5G-MAG Reference Tools is based on a specific 3GPP release. As an example, our reference implementation of 5G Downlink Media Streaming is based on Release 17.

As the work in 3GPP continues at a steady pace, new releases are published. These releases contain new features, additions, and enhancements to existing releases. As an example, consider Rel.18 or Rel.19 features for 5G Media Streaming such as the support for Common Media Client Data (CMCD).

This thread aims at collecting and discussing the integration strategy for new 3GPP releases into the existing reference implementations. 5G Downlink Media Streaming is just an example, the same question arises in the context of other projects.

General Questions / Discussion Items

• Are 3GPP releases backwards compatible? Or do they typically implement breaking changes that prevent us from simply adding functionality of a new release on top of the existing functionality.

Integration Strategies

This section collects possible integration strategies. To be defined in more detail and collected in this thread.

Release specific forks

Idea

Each GitHub repository implements a specific 3GPP release. To add support for a new release the corresponding repository is forked and labeled accordingly. For instance, to add a Rel.18 features to the rt-5gms-media-session-handler the repository is forked and labeled rt-5gms-media-session-handler-rel-18.

Pros

• Clear separation between 3GPP release specific features

Cons

• Leads to numerous repositories
• Leads to code duplication as common parts are identical between multiple repositories
• Leads to high maintenance effort and code duplication if fixes in the 3GPP specification are applied to multiple releases.
• Can lead to confusion if users combine different releases

Maintaining 3GPP release specific branches

Idea

Each GitHub repository contains multiple 3GPP release specific branches. To add support for a new release, a new branch is created in the corresponding repository. For instance, to add a Rel.18 features to the rt-5gms-media-session-handler the repository a branch labeled Rel.18 is created.

References / Examples

• Shaka Player seems to follow a similar approach, releasing multiple versions at once.

Pros

• Clear separation between 3GPP release specific features.
• No need to maintain multiple different repositories for a single component.

Cons

• GitHub commit trees of the different branches are diverting. No single development and main branch anymore.
• Fixes in the 3GPP specification that are applied to multiple 3GPP releases need to be copied to multiple branches.
• Can lead to problems if users combine branches of different releases.

Maintaining a core module and a set of extensions

Idea

Design the system with a core module and additional extensions that can be plugged together to support a specific release. As an example, there can be a CMCD module that is added to a set of core modules to support the Rel.19 CMCD feature.

References / Examples

• DataTables looks a bit like this. Configure your own build and then get all the required extensions to the core module.

Pros

• Very dynamic, allows maximum flexibility. The modules can be used as a toolbox to configure personalized components.
• No need to maintain multiple different repositories for a single component

Cons

• Very high demands in terms of design and implementation. Complicated to implement.
• If functionality in a core module needs to be adjusted, there will be a need to factor out core functionality to a new module or even multiple new modules.
• Requires configuration effort by the user.

Build or runtime configuration / Feature flags

Idea

There are no 3GPP release specific branches, and the configuration of which 3GPP release or feature to support is done either at build time or at runtime. For UE side components with a user interface, this can be a simple selection based on a group of radio buttons. For server side components, this can be a flag that is set at build time. Based on the configuration, the build includes 3GPP release specific features.

Pros

• No need to maintain multiple different repositories for a single component.

Cons

• Requires configuration effort by the user
• Potentially requires many conditional statements (if..else) in the code, which leads to high code complexity.

[dsilhavy]

21.03.2025

If two releases are very similar (small delta) there would be a “common ground” and release specific features could go into some kind of release specific "adapter"? Runtime option sounds attractive here.

[haudiobe]

Thanks Daniel: Just to check, the configuration is done through an API? Is this API consistent across dash.js and Exo? Does it align with the API/Service description in the 6th edition of DASH? At least conceptually: Do you believe it is better to configure outside the MPD using Service Provisioning or should we rely on MPD carrying the information?