Change Request Summary: 26.502 CR 0046 Rev 1

Document Information

• CR Number: 0046 Rev 1
• Release: Rel-17
• Category: F (Correction)
• Work Item: 5MBUSA
• Title: [5MBUSA] MBSF notification event corrections

Reason for Change

This CR addresses two main issues:

1. Misalignment between Stage-2 and Stage-3 specifications: Two notification events specified by CT3 in TS 29.580 are not properly motivated at stage-2 in TS 26.502

2. Reference: https://github.com/5G-MAG/rt-mbs-function/issues/11

3. Errors in notification event depiction: Figure 5.3-2 contains errors in the depiction of event notifications

4. Reference: https://github.com/5G-MAG/Standards/issues/188

Technical Changes

Change 1: Clause 4.6.2 - Notification Events Table

Modifications to Table 4.6.2-1:

• Column simplification: The final column "Applicable reference point(s)" has been renamed to "Stimulating reference point(s)" for improved clarity
• Clarification of event origins: The text now better explains that events in brackets originate from other NFs, while events without brackets originate from the MBSF itself

Addition of two missing notification events:

1. Distribution Session service management failure
2. Description: The MBS Distribution Session could not be started because necessary resources could not be allocated by the MBS System

3. Stimulating reference points: (Nmb1), (Nmb2), Nmb10/Nmb5

4. Distribution Session policy control failure

5. Description: The MBS Distribution Session could not be started because of a policy authorization/control failure or rejection
6. Stimulating reference points: (Nmb12), Nmb10/Nmb5

Change 2: Clause 5.3 - Procedure Corrections in Figure 5.3-2

Step 14 correction: - Changed service operation from generic notification to Nmbstf_MBSDistributionSession_StatusNotify callback service operation - Clarified that this informs the MBSF of (un)successful establishment of content ingest using the Distribution Session established event - Added state transition information: On success → ESTABLISHED, on failure → remains INACTIVE

Step 15 correction: - Changed service operation to Nmbsf_MBSUserDataIngestSession_StatusNotify callback service operation - Clarified that this informs the MBS Application Provider of (un)successful establishment of content ingest - Specified use of either Distribution Session established event or Distribution Session establishment failure event, as appropriate

Step 17 correction: - Changed service operation to Nmbsf_MBSUserDataIngestSession_StatusNotify callback service operation - Clarified that this informs the MBS Application Provider of (un)successful establishment of all MBS Distribution Sessions - Specified use of either User Data Ingest Session established event or User data ingest failure event, as appropriate

Impact

• Alignment achieved: TS 26.502 (SA4) now properly aligns with TS 29.580 (CT3)
• Implementation clarity: The MBSF can now be implemented correctly according to the specification
• No impact on TS 29.580: Changes are confined to TS 26.502

3GPP TR 26.502 Change Request Summary

General Information

• CR Number: 0047
• Category: A (mirror corresponding to a change in an earlier release)
• Release: Rel-18
• Work Item: 5MBUSA (5G MBS User Service Architecture)
• Source: BBC
• Meeting: S4#135, Goa, India, 9th-13th February 2026

Reason for Change

This CR addresses two main issues:

1. Misalignment between Stage-2 and Stage-3 specifications: Two notification events specified by CT3 in TS 29.580 are not properly motivated at stage-2 level in TR 26.502. This issue is tracked at https://github.com/5G-MAG/rt-mbs-function/issues/11

2. Errors in notification event depiction: Figure 5.3-2 contains errors in the depiction of event notifications. This issue is tracked at https://github.com/5G-MAG/Standards/issues/188

Technical Changes

Section 4.6.2: Notification Events

Modifications to Table 4.6.2-1:

• Column simplification: The final column of the notification events table has been simplified for improved clarity. The column header changed from "Applicable reference point(s)" to "Stimulating reference point(s)"

• Added motivation for missing events: Two notification events that were previously not properly motivated have been updated:

• User Service advertisement event: Now includes proper description and stimulating reference point (Nmb10/Nmb5)

• User Data Ingest Session starting event: Clarified with appropriate reference point information

• Clarification of event sources: The table now more clearly indicates which reference points stimulate each notification event, with brackets indicating intermediate reference points and explicit notation of the final delivery reference points (Nmb10/Nmb5)

Section 5.3: Procedures for User Service Provisioning

Corrections to Figure 5.3-2 Call Flow:

Three specific steps in the MBS User Service internal provisioning procedure have been corrected:

• Step 14: Corrected the event notification from MBSTF to MBSF regarding content ingest establishment status using the Distribution Session established event

• Step 15: Corrected the event notification from MBSF to MBS Application Provider regarding content ingest establishment, properly distinguishing between Distribution Session established event (success case) and Distribution Session establishment failure event (failure case)

• Step 17: Corrected the final notification event from MBSF to MBS Application Provider regarding the overall MBS User Data Ingest Session status, properly distinguishing between User Data Ingest Session established event (success case) and User data ingest failure event (failure case)

Impact Assessment

Consequences if not approved: - Continued misalignment between stage-2 (SA4) and stage-3 (CT3) normative specifications - The MBSF cannot be implemented correctly as currently specified

Alignment impact: - This CR aligns TS 26.502 with TS 29.580 - No impact on TS 29.580 is required

3GPP TR 26.502 Change Request - MBSF Notification Event Corrections

General Information

• CR Number: 0048
• Release: Rel-19
• Category: A (mirror corresponding to a change in an earlier release)
• Work Item: 5MBUSA (5G MBS User Service Architecture)
• Source: BBC
• Meeting: S4#135, Goa, India, 9th-13th February 2026

Reason for Change

This CR addresses two main issues:

1. Misalignment between Stage-2 and Stage-3 specifications: Two notification events specified by CT3 in TS 29.580 are not properly motivated at stage-2 level in TR 26.502. This issue is tracked in the 5G-MAG GitHub repository (issue #11).

2. Errors in notification event depiction: Figure 5.3-2 contains errors in the depiction of event notifications (tracked in 5G-MAG GitHub issue #188).

Without approval, there would be misalignment between SA4 (stage-2) and CT3 (stage-3) normative specifications, and the MBSF could not be implemented as currently specified.

Technical Changes

Change 1: Clause 4.6.2 - Notification Events Table

Modifications to Table 4.6.2-1:

• Column simplification: The final column has been renamed from "Applicable reference point(s)" to "Stimulating reference point(s)" for improved clarity
• Added motivation for two missing events:
• Distribution Session service management failure: Added stimulating reference points (Nmb1), (Nmb2), Nmb10/Nmb5
• Distribution Session policy control failure: Added stimulating reference points (Nmb12), Nmb10/Nmb5

The table now properly indicates which reference points stimulate each notification event, with brackets indicating when the event originates from another NF and is propagated through the MBSF.

Change 2: Clause 5.3 - User Service Provisioning Procedures

Corrections to Figure 5.3-2 call flow steps:

• Step 14: Corrected to specify that MBSTF invokes Nmbstf_MBSDistributionSession_StatusNotify (not the previous incorrect reference)

• Step 15: Corrected to specify that MBSF invokes Nmbsf_MBSUserDataIngestSession_StatusNotify to inform the MBS Application Provider about establishment success/failure of content ingest for the MBS Distribution Session

• Step 17: Corrected to specify that MBSF invokes Nmbsf_MBSUserDataIngestSession_StatusNotify to inform about the establishment status of all MBS Distribution Sessions of the parent MBS User Data Ingest Session (not just individual sessions)

Impact

• TS 26.502: This CR aligns the specification with TS 29.580
• TS 29.580: No impact on the CT3 specification
• Other specifications: No impact on other core, test, or O&M specifications

Change Request Summary: Corrections to CMCD Phase 1

CR Metadata

• CR Number: 0104
• Specification: TS 26.512 v19.1.0
• Category: F (Correction)
• Release: Rel-19
• Work Item: AMD_PRO-MED (Advanced Media Distribution for Professional Media)

Reason for Change

MPEG-DASH 6th edition contains an ambiguity regarding the interpretation of service location and adaptation set based filtering. After consultation with client implementers, it was identified that the interpretation in 5G Media Streaming does not align with actual implementations. The issue relates to whether the filtering restrictions apply to the requests themselves or to the reporting of CMCD data.

Summary of Technical Changes

The CR clarifies that the restrictions specified in the CMCD configuration apply to which requests include CMCD information, not to which CMCD data is reported. This is a critical distinction for proper implementation of the CMCD (Common Media Client Data) feature.

Detailed Technical Modifications

Clause G.5.2.2 - DASH Content Offering Requirements and Recommendations

Key Change: Modified the description of filtering capabilities to clarify scope.

• Original text: "The ability to restrict the subset of Service Locations, Adaptations Sets and/or media object types for which CMCD information is reported."

• Corrected text: "The ability to restrict the subset of requests for Service Locations, Adaptations Sets and/or media object types that include CMCD information."

This change emphasizes that the filtering controls which HTTP requests carry CMCD data, rather than controlling what data is reported once CMCD is included.

Clause G.5.2.4 - Examples (Informative)

Key Changes: Updated the example description and XML comments to align with the corrected interpretation.

1. Bullet point corrections:
2. Changed "Reporting is restricted to a single service location" → "Reporting is restricted to requests for either dist1 or dist2"
3. Changed "Reporting is restricted to Segments assigned to video Adaptations Sets only" → "Reporting is restricted to requests for Segments assigned to video Adaptations Sets only"

4. Changed "Reporting is restricted to Media segments" → "Reporting is restricted to Media Segments" (also fixed capitalization)

5. XML example: The actual MPD XML structure remains unchanged, but the descriptive text now correctly explains that the serviceLocations and adaptationSets attributes in the ClientDataReporting element control which requests include CMCD headers, not which data is reported.

Impact

If Not Approved

• Inconsistent implementations across different client implementations
• Potential interoperability issues between 5GMS clients and application servers
• Misalignment with MPEG-DASH 6th edition implementer interpretations

Affected Specifications

• Only TS 26.512 is affected
• No impact on other core specifications, test specifications, or O&M specifications

Technical Context

This correction is part of the CMCD Phase 1 implementation in 5G Media Streaming. CMCD allows DASH clients to convey media-specific information to the CDN/application server to enable better delivery optimization. The filtering mechanism allows content providers to control the overhead of CMCD reporting by limiting which requests carry this additional metadata.

Change Request Summary: Correction to Quality Reporting Scheme Information

CR Details

• CR Number: 0194
• Specification: TS 26.247 v18.4.0
• Category: F (Correction)
• Release: Rel-18
• Work Item: NR_QoE_enh-Core

Background and Reason for Change

RAN3 identified misalignment between RAN3 and SA4 specifications regarding the usage of communication service type for QoE Measurement Collection (QMC) for MBS. This was communicated through documents S4-251660/R3-255896 and S4-260016. The issue was discussed at SA4#134 (S4-252077) and further refined in the MBS SWG Telco (S4aI260011).

Main Technical Contributions

1. Restructuring of Quality Reporting Scheme (Clause 10.1 and 10.5)

Key Changes: - Separated generic DASH quality reporting scheme from QMC-specific functionality - Clarified that when using MPD or OMA-DM, the Quality Reporting scheme in clause 10.5 applies - When using QMC functionality, the Quality Reporting scheme defined in Annex L applies - Updated clause 10.1 to reflect that QMC reporting is specified in Annex L

Moved Elements from Clause 10.5 to Annex L: - @SliceScope attribute - @communicationServiceType attribute - Associated XML schema definitions for these attributes

Removed from QMC Context: - @reportingserver attribute - not needed for QMC as per TS 26.501 clause 5.5.4

2. Updates to Annex L.1 (Configuration and Reporting)

Clarifications: - Updated reference from clause 10.5 to Annex L.2 for QMC-specific quality reporting scheme - Maintained explanation that @communicationServiceType attribute indicates whether DASH client should collect/report QoE metrics for: - Unicast - MBS broadcast - MBS multicast - All communication service types

3. New Annex L.2 Structure (XML Configuration)

Major Additions:

New Table X: XML Schema of QMC Configuration

Complete XML schema definition for QMC configuration including: - QmcConfigurationType complex type - RangeType for time-based filtering - LocationFilterType for geographic filtering - StreamingSourceFilterType for source filtering - UnsignedIntVectorType for slice scope - CommunicationServiceTypeType enumeration

Key Attributes in QMC Configuration: - @metrics (required) - @samplePercentage (optional) - @reportingInterval (optional) - @sliceScope (optional) - @communicationServiceType (optional) - @qoeReferenceId (optional) - network-side reference for correlation

New Table Y: Semantics of QMC Reporting Scheme Information

Comprehensive semantics table defining: - All QMC-specific attributes and elements - Usage indicators (Mandatory/Optional) - Detailed descriptions for each parameter

Communication Service Type Values: - unicast - common unicast communication type - mbsMulticast - MBS Multicast communication service (per TS 38.300 clause 21.1) - mbsBroadcast - MBS Broadcast communication service (per TS 38.300 clause 21.1) - all - all communication service types (removed from QMC-specific definition)

4. XML Schema Updates

Clause 10.5 Schema Changes: - Removed @sliceScope attribute definition - Removed @communicationServiceType attribute definition - Removed UnsignedIntVectorType simple type - Removed CommunicationServiceTypeType simple type

Annex L.2 Schema Additions: - Complete QMC-specific XML schema with namespace urn:3GPP:ns:PSS:DASH:QMC14 - All location filtering types (PolygonListType, CircularAreaListType, ShapeType) - QMC-specific attribute definitions

5. Key Differences Between Generic DASH and QMC Reporting

| Aspect | Generic DASH (10.5) | QMC (Annex L) | |--------|-------------------|---------------| | Reporting Server | Required (@reportingserver) | Not applicable (uses RRC) | | Communication Service Type | Includes "all" value | Only specific types (unicast, mbsMulticast, mbsBroadcast) | | Configuration Delivery | MPD or OMA-DM | RRC messages | | Report Delivery | HTTP (clause 10.6) | RRC over control plane |

Impact and Alignment

This CR ensures proper alignment between: - SA4 specifications (TS 26.247) - RAN3 specifications - QMC functionality requirements - MBS communication service type definitions (TS 38.300)

The changes maintain backward compatibility for non-QMC implementations while providing clear, separate specifications for QMC-based quality reporting.

3GPP Change Request Summary: TS 26.501 CR 0034

Document Information

• Specification: TS 26.501 v19.3.0
• CR Number: 0034
• Category: F (Correction)
• Release: Rel-19
• Work Item: 5GMSA, TEI19
• Source: Nokia

Purpose of Change Request

This CR addresses an architectural inconsistency in TS 26.501 regarding the M11 reference point. The M11 interface is defined as the reference point between the Media Session Handler and the Media Access Function (both components within the Media Client) for configuring the Media Session Handler and/or media access control. However, this interface is not correctly represented in several clauses of the specification.

Technical Corrections

The CR proposes corrections across multiple architectural scenarios where the M11 interface is referenced:

1. Edge Computing Integration (Clause 4.5.2)

• Affected Section: 5G Media Streaming combined with Edge Computing
• Context: Extended architecture integrating 5GMS with Edge Applications (TS 23.558) and Edge Computing management (TS 28.538)
• Change: Correction to M11 reference point representation in Figure 4.5.2-1

2. eMBMS-based Delivery (Clauses 4.6.1 and 4.6.2)

• Affected Sections:
• Architecture for 5G Downlink Media Streaming over eMBMS (4.6.1)
• Usage of 5GMS reference points for eMBMS-based delivery (4.6.2)
• Context: Architecture combining 5GMS System with MBMS System functions
• Specific Change: Clause 4.6.2.9 - Usage of M11d reference point corrected to align with definitions in clauses 4.1 to 4.4

3. Data Collection and Reporting (Clause 4.7.1)

• Affected Section: Reference architecture instantiation
• Context: Instantiation of abstract data collection and reporting architecture from TS 26.531 within 5GMS architecture
• Change: Correction to M11 reference point in Figure 4.7.1-1

4. MBS-based Delivery (Clause 4.9.1)

• Affected Section: Architecture for downlink 5G Media Streaming over MBS
• Context: Architecture combining 5GMS System with MBS System (TS 26.502)
• Details: Covers both simple deployment (5GMSd AF in Trusted DN with direct Nmb10 interface) and complex deployments (external 5GMS System using N33 to NEF)
• Change: Correction to M11 reference point representation in Figure 4.9.1-1

Impact Assessment

Consequences if not approved: The specification would continue to contain incorrect reference point representations in the architecture, leading to potential implementation inconsistencies and misunderstandings of the Media Client internal interfaces.

Other specifications affected: None identified

Summary

This is a straightforward correction CR that ensures consistent and accurate representation of the M11 reference point across multiple architectural scenarios in TS 26.501, including edge computing, eMBMS delivery, data collection/reporting, and MBS delivery contexts.