Skip to main content
Feedback & Requirements

Meetings with 3GPP SA4

Dated log of XCHANGE meetings between 5G-MAG and 3GPP SA4, tracking specification issues, CRs and their status through to publication.

Overview​

This page is the running log of XCHANGE meetings, the regular sessions where 5G-MAG and 3GPP SA4 review the specification issues raised by implementers. Each section below is dated and listed newest first. Issue numbers link to the 5G-MAG Standards GitHub tracker, where the current status is always authoritative. For the Work Items that define what each 3GPP Release delivers, see 3GPP Work Items per Release.

On this page​

Status and milestone legend​

Issues move through the following stages, from earliest to latest: Pre-Acceptance → Adopted → Change contribution drafting → Approved for publication by Technical Body → Published. The milestone notation, for example 3GPP SA4#130→SA#106, means the change was handled at SA4 meeting 130 and went to the SA plenary 106 for approval. The Doubt label marks an issue raised as a question rather than a confirmed defect.

warning

The stage order and label meanings above are provided for orientation. Confirm the exact vocabulary with the tracker owner, as the GitHub tracker remains authoritative.

Shorthands used on this page​

The entries below use several 3GPP media-delivery shorthands. See the 5G Media Streaming standards page for fuller definitions.

  • 5GMS (5G Media Streaming); 5GMSd (downlink) and 5GMSu (uplink) are its two directions.
  • 5MBS / MBS (5G Multicast-Broadcast Services).
  • M1..M11: reference points (named interfaces) in the 5G Media Streaming architecture, for example M1 (provisioning), M4 (media delivery), M5 (service access), M6 (media session handling) and M7 (media playback).
  • EVEX: event exposure and data-collection work.
  • QoE (Quality of Experience) metrics reporting.
warning

The reference-point summaries above are for orientation only. Confirm the exact definitions against TS 26.501.

XCHANGE 09/01/2025 - Status of standards tickets by end 2024​

Issues that should have been resolved earlier in the year​

[#]TitleAssigneesStatusLabelsMilestone
#122QoE Metrics Reporting: M1 Provisioning - reportingInterval shall be greater than zerorjb1000Published3GPP Rel-16, 3GPP Rel-17, 3GPP Rel-18, 3GPP TS 26.510, 3GPP TS 26.512, 5GMS Metrics Reporting, Improvement
#123QoE Metrics Reporting - M1 Provisioning - samplingPeriod can be negativerjb1000Published3GPP Rel-16, 3GPP Rel-17, 3GPP Rel-18, 3GPP TS 26.510, 3GPP TS 26.512, 5GMS Metrics Reporting, Improvement

Issues with CRs approved at SA#106 (Madrid) December 2024​

MCC has very recently implemented these CRs, targeting publication of new specifications by mid January. Drafts not checked yet.

[#]TitleAssigneesStatusLabelsMilestone
#106TS 26.512: Discrepancy between tables and YAML for properties marked as read-onlyrjb1000, tlohmarApproved for publication by Technical Body3GPP Rel-16, 3GPP Rel-17, 3GPP TS 26.512, 5GMS Content Hosting, 5GMS Dynamic Policies, 5GMS Edge Applications, 5GMS Metrics Reporting, 5GMS Network Assistance, Adopted, Improvement3GPP SA4#130→SA#106
#146TS 26.512 V17.9.0: Discrepancies between normative tables and OpenAPI YAMLrjb1000Approved for publication by Technical Body3GPP Rel-17, 3GPP TS 26.512, 5GMS Consumption Reporting, 5GMS Content Hosting, 5GMS Dynamic Policies, 5GMS Edge Applications, 5GMS Event Exposure, 5GMS Metrics Reporting, 5GMS Service Access/Launch, Correction3GPP SA4#130→SA#106
#149TS 26.510: Gaps identified in support for Background Data Transfer at reference point M6haudiobe, ibouazizi, rjb1000, tlohmarApproved for publication by Technical Body3GPP Rel-18, 3GPP TS 26.501, 3GPP TS 26.510, 5GMS Dynamic Policies3GPP SA4#130→SA#106
#148TS 26.512: Gaps identified in support for Background Data Transfer at reference point M7rjb1000Approved for publication by Technical Body3GPP Rel-18, 3GPP TS 26.512, 5GMS Dynamic Policies3GPP SA4#130→SA#106

New issues adopted in current meeting cycle​

A CR has been drafted for the following new issue, and was endorsed by the SA4 MBS ad hoc meeting on 8th Jan.

[#]TitleAssigneesStatusLabelsMilestone
#120TS 26.346 FLUTE FDT Profile for 5MBS & delimiter usagechburdinat, haudiobe, jordijoangimenez, rjb1000, tlohmarChange contribution drafting3GPP Rel-17, 3GPP Rel-18, 3GPP TS 26.346, Doubt3GPP SA4#131→SA#107

Adopted issues that nobody is actively working on right now​

[#]TitleAssigneesStatusLabelsMilestone
#104TS 26.512: M1 Policy Template Provisioning - Return codes for error handling of put operationrjb1000Adopted3GPP Rel-16, 3GPP Rel-17, 3GPP TS 26.512, 5GMS Dynamic Policies, Adopted, Improvement3GPP SA4#131→SA#107
#106TS 29.571: regex pattern allows all non-empty strings and will not apply restrictions as intendedhaudiobe, ibouazizi, jordijoangimenez, rjb1000, tlohmar, zooksyAdopted3GPP Rel-17, 3GPP TS 29.571, Adopted, Correction, Improvement
#35ProvisioningSession resource returned by 5GMS AF at M1 does not include information about all its subresourcesfredericgabin, haudiobe, jordijoangimenez, rjb1000, tlohmarAdopted3GPP Rel-16, 3GPP Rel-17, 3GPP TS 26.512, Adopted, Improvement3GPP SA4#127→SA#103
#61TS 26.512 Policy Template state change eventsfredericgabin, rjb1000, tlohmarAdopted3GPP Rel-18, 3GPP TS 26.510, 5GMS Dynamic Policies, Adopted, Improvement3GPP SA4#127→SA#103
warning

The issue number for the TS 29.571 regex entry above (shown as #106) also appears earlier for a different TS 26.512 issue. The correct tracker number needs confirmation; check the 5G-MAG Standards tracker before relying on the link.

Unadopted issues​

[#]TitleAssigneesStatusLabelsMilestone
#49Discussion Item: Signaling of DRM information via ServiceAccessInformationdsilhavy, haudiobePre-Acceptance3GPP Rel-19, 3GPP TS 26.512, 5GMS Service Access/Launch, Discussion, New Feature3GPP SA4#127→SA#103
#63Discussion: 5GMSd Network Assistance - Synergy with CTA-Wave Common Media Server Data (CMSD)fredericgabin, haudiobe, rjb1000, tlohmarPre-Acceptance3GPP Rel-19, 3GPP TS 26.510, 3GPP TS 26.512, 5GMS Metrics Reporting, 5GMS Network Assistance, Discussion3GPP SA4#127→SA#103
#103TS 26.512: Add missing filterType parameter to ServiceDataFlowDescriptionjordijoangimenezPre-Acceptance3GPP Rel-16, 3GPP Rel-17, 3GPP Rel-18, 3GPP TS 26.510, 3GPP TS 26.512, 5GMS Dynamic Policies, 5GMS Network Assistance, Improvement3GPP SA4#130→SA#106
#118FAR Apply Action "FSSM" in PFCP Session Establishment for MBSBorjis131, jordijoangimenezPre-Acceptance3GPP Rel-17, 3GPP TS 29.244, Doubt, MBS Broadcast
#124Identical EARFCN assignment for E-UTRA bands 106 and 107jordijoangimenezPre-Acceptance3GPP Rel-18, 3GPP TS 36.101, Clarification
#126Common start of the first MCCH modification periodjordijoangimenezPre-Acceptance3GPP TS 36.300, Clarification

XCHANGE 10/10/2024​

Resolution of issues found in 3GPP technical specifications​

5G-MAG has been collecting feedback on 3GPP specifications since our last XCHANGE with 3GPP SA4. The issues raised by developers are in GitHub: Kanban · Specifications - 3GPP - Feedback (github.com).

[#]Title3GPP TS impactedTDoc #
#104TS 26.512: M1 Policy Template Provisioning - Return codes for error handling of put operationTS 26.512 Rel-17-
#146TS 26.512 V17.9.0: Discrepancies between normative tables and OpenAPI YAMLTS 26.512 Rel-17S4aI240116
#141Lack of support for preselecting a Service Operation PointTS 26.510 Rel-18 TS 26.512 Rel-18S4aI240133
#148Gaps identified in support for Background Data Transfer at reference point M6TS 26.512 Rel-18S4aI240146
#149Gaps identified in support for Background Data Transfer at reference point M7TS 26.512 Rel-18S4aI240147

Note that:

  • The content of TS 26.512 Rel-17 CR0080 [S4aI240116] (issue #146) was agreed in the SA4 MBS ad hoc meeting preceding SA4#130.
  • Stage-2 fixes for issue #141 were agreed at the SA4#129e meeting and approved for publication at SA#105; for stage-3, TS 26.512 Rel-18 CR0081 is to be looked at by the present SA4 MBS meeting.
  • Issues #148 and #149 are raised in the context of the feasibility analysis and usage guidelines for the deployment of Uplink 5G Media Streaming (5GMSu) and RTC architectures (as mentioned above) and as described by the Discussion Paper S4aI240135.

XCHANGE 02/05/2024​

Issues to be covered at the session​

See Kanban board for overview of open issues.

IssuesTDocTypeRelTopicContributorStatusForSpec / Number
#119, #122, #123, #128S4aI240047CRRel-17[5GMS3, TEI17] Metrics reporting correctionsBBCavailableEndorsementSpec: 26.512 CR0069
#110, #125S4aI240051CRRel-18[EVEX] Essential correctionsBBCavailableDecisionSpec: 26.532 CR0011
#110S4aI240050CRRel-18[EVEX, TEI18] Add missing explicit data reporting and event exposure parametersBBCavailableDecisionSpec: 26.512 CR0070
#110S4aI240049pCRRel-18[EVEX, TEI18] Add missing implicit data reporting parametersBBCavailableDecisionSpec: 26.510
#110S4aI240053CRRel-18[EVEX, TEI18] Additional QM10 reporting schema fields for alignmentBBCavailableDiscussionSpec: 26.247

CRs​

S4aI240043[5MBUSA] Corrections based on stage-3 fixesQualcomm Incorporated, BBCRichard Bradbury

S4aI240043 is postponed.

S4aI240047[5GMS3, TEI17] Metrics reporting correctionsBBCRichard Bradbury

E-mail Discussion:

Revisions: none

Presenter: Richard Bradbury

Decision: endorsed

S4aI240047 is Endorsed.

S4aI240050[EVEX, TEI18] Add missing explicit data reporting and event exposure parametersBBCRichard Bradbury

E-mail Discussion:

Revisions: none

Presenter: Richard Bradbury

Decision: Endorsed

S4aI240050 is endorsed

S4aI240051[EVEX] Essential correctionsBBCRichard Bradbury

E-mail Discussion:

Revisions: none

Presenter: Richard Bradbury

Decision: endorsed

S4aI240051 is endorsed.

S4aI240053[EVEX, TEI18] Additional QM10 reporting schema fields for alignmentBBCRichard Bradbury

E-mail Discussion:

Revisions: none

Presenter: Richard Bradbury

Decision: endorsed

S4aI240053 is endorsed

S4aI240044[5GMS_Pro_Ph2] Consolidated media plane enhancementsQualcomm Incorporated, Ericsson LM, Tencent, BBCRichard Bradbury

S4aI240044 is postponed.

S4aI240045TS 26.510 Editor's draft V1.1BBC (Editor)Richard Bradbury

S4aI240045 is postponed.

S4aI240046[5GMS_Pro_Ph2] Media delivery session identifier at M4+M7+M11BBCRichard Bradbury

S4aI240046 is postponed.

S4aI240048[5GMS_Pro_Ph2] Per-flow QoS bindingsBBCRichard Bradbury

S4aI240048 is postponed.

S4aI240049[EVEX, TEI18] Add missing implicit data reporting parametersBBCRichard Bradbury

E-mail Discussion:

Revisions: none

Presenter: Richard Bradbury

Decision: agreed

S4aI240049 is agreed.

XCHANGE 07/03/2024​

Adopted TS 26.512 issues​

[#]Milestone
#1193GPP SA4#127-e-bis→SA#104
#1023GPP SA4#128→SA#104
#104Milestone 3GPP SA4#128→SA#104

Adopted TS 26.532 issue​

[#]Milestone
#1103GPP SA4#128→SA#104
#1113GPP SA4#127-e-bis→SA#104
#1123GPP SA4#127-e-bis→SA#104
#1133GPP SA4#127-e-bis→SA#104
#1153GPP SA4#127-e-bis→SA#104
#1163GPP SA4#127-e-bis→SA#104
#1173GPP SA4#127-e-bis→SA#104

XCHANGE 26/10/2023​

Issues to be covered at the session​

See Kanban board for overview of open issues.

TS 26.247 - Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)​

Issues resolved at SA#101 Bangalore​

  • #79 5GMSd - QoE Metrics Reporting - Inconsistency with HTTPList.

Published as TS 26.247 V16.8.1 and V17.4.1.

New issues targeting approval at SA#102 Edinburgh​

None.

TS 26.346 - MBMS; Protocols and codecs​

Issues resolved at SA#101 Bangalore​

None.

New issues targeting approval at SA#102 Edinburgh​

TS 26.501 - 5G Media Streaming (5GMS); General description and architecture​

Issues resolved at SA#101 Bangalore​

  • #66 TS 26.501 Clarification - Appropriate network entity for metrics error reports.
  • #75 Confusion over "nominal time period" validity for Network Assistance throughput estimations and delivery boosts

Published as TS 26.501 V16.12.0, V17.7.0 and 18.3.1.

New issues targeting approval at SA#102 Edinburgh​

None.

TS 26.512 - 5G Media Streaming (5GMS); Protocols​

Issues resolved at SA#101 Bangalore​

  • #65 TS 26.512 MetricsReportingConfiguration scheme cardinality does not match YAML definition
  • #67 TS 26.512 - Typo in word "Metrics" - Should be named "metrics".
  • #68 TS 26.512 - Clarification on the client behavior for the list of metrics which shall be reported
  • #69 TS 26.512 - Handling of 3XX HTTP redirects via interface at M2d
  • #71 TS 26.512 - How to choose a address from clientConsumptionReportingConfiguration.serverAddresses array for consumption reporting
  • #73 TS 26.512 - Consumption reporting: How is aspId for POST URL generated?
  • #74 Possible inconsistency in specification of Service Data Flow Description
  • #76 TS 26.512: NetworkAssistanceSession Request body not specified in the OpenAPI YAML for M5 createNetworkAssistanceSession operation
  • #78 5GMSd - QoE Metrics Reporting - Clarification on sampling rate for buffer level
  • #80 5GMS AF treatment of Network Assistance Session resource
  • #81 TS 26.512: Clarification on use of optional properties in NetworkAssistanceSession

Published as TS 26.512 V16.11.0 and V17.6.0.

Discussions​

  • #49 Discussion Item: Signaling of DRM information via Service Access Information
  • #63 Discussion: 5GMSd Network Assistance - Synergy with CTA-Wave Common Media Server Data (CMSD)

Issues previously adopted but carried over from a previous meeting cycle​

  • #45 Specify methods in the M6 Media Session Handling client API to invoke 5GMS network assistance
    • Maybe something in the next meeting cycle?
  • #61 TS 26.512 Policy Template state change events
    • Maybe add something in Rel-18?
  • #82 TS 26.512: Media streaming session identifier
    • The need for an identifier that allows UE data (of the same or different types) to be correlated after their exposure as Events.
    • New Rel-18 feature versus essential correction to Rel-17?
    • Need for stage-2 motivation in TS 26.501?

Rel-18 issues for endorsement at SA4#126 Chicago​

  • #42 Specify client-facing 5GMS AF host name to be used by Media Session Handler at M5
    • See TS 26.512 Rel-18 CR0036r2 in S4aI230150 clause 6.1A.2.
    • (This change will probably end up in the new TS 26.510 document.)

New issues targeting approval at SA#102 Edinburgh​

Recently raised issues for potential adoption by 5G-MAG and 3GPP SA4​

  • #89 TS 26.512 - Make externalReference and applicationSessionContext optional properties of PolicyTemplate resource
  • #90 5GMSd - Consumption Reporting - Clarification on duration property
  • #91 Clarification of ConsumptionReportingUnit.mediaEndpointAddress ambiguity
    • Discussion on the value of reporting endpoint address of both ends of reference point M4.
  • #97 TS 26.512 - Value of mediaPlayerEntry and mediaConsumed in Definition of ConsumptionReport format
    • Discussion on virtues of explicitly specifying population of consumption reports for HLS-based media streaming sessions.

Issues already tackled in TS 26.512 CR0054:​

See TS 26.512 Rel-17 CR0054 in S4aI230145.

  1. #86 TS 26.512: Fix inconsistent name of client metrics reporting configuration property in Service Access Information
    • Corrected simple typo in YAML.
  2. #88 TS 26.512 - Use of Read-only mandatory fields in PolicyTemplate resource
    • Piloted use of readOnly YAML directive.
  3. #93 M5 Service Access Information - Inconsistency with ConsumptionReportingConfiguration.accessReporting
  4. #94 Inadvisable use of response code 422 (Unprocessable Entity) by 5GMS AF at reference point M1
    • Replaced with different HTTP response codes.
  5. #95 Unclear binding between externalReference and Policy Template identifier in M5 Service Access Information
    • Introduced new policyTemplateBindings array to explicitly bind an external reference to a Policy Template identifier.
  6. #96 TS 26.512: M1 ConsumptionReportingConfiguration.reportingInterval value range not present in the OpenAPI YAML
    • Updated YAML to specify reportingInterval > 0.
  7. #33 Use of aspId and externalApplicationId in M1_ProvisioningSession_createProvisioningSession
    • Renamed externalApplicaitonId to appId and clarified need for NEF to map external Application Identifier to internal Application Identifier.

TS 26.517 - 5G Multicast-Broadcast User Services; Protocols and Formats​

Issues resolved at SA#101 Bangalore​

  • #56 Specify mechanism for discovery of MBS User Service Announcement by MBS Client
    • Stage-2 procedures clarified during previous meeting cycle in TS 26.502 V17.5.0 clause 5.4.
    • Stage-3 API proposal in TS 26.517 Rel-17 CR0010r3 in SP-230916 approved.

Published in TS 26.517 V17.4.0.

Issues previously adopted and targeting approval at SA#102 Edinburgh​

Most issues are being dealt with (at low priority) in TS 26.517 Rel-17 CR0001.

  • #53 Applicability of Schedule Description metadata unit in MBS User Service Announcement is inconsistent
    • Proposed clarification included in Qualcomm TS 26.517 Rel-17 CR0001r11 in S4aI230117.
  • #54 Add a figure to illustrate JSON-based syntax of MBS User Service Announcement
    • Replacement figure included in Qualcomm TS 26.517 Rel-17 CR0001r11 in S4aI230117.
  • #55 Clarify population of Schedule Description metadata unit in MBS User Service Announcement
    • Still not tackled.
    • Wholesale redraft in next revision of TS 26.517 Rel-17 CR0001 will hopefully flush this issue out.
  • #57 Clarification of Byte Range Object Repair
    • Late contribution TS 26.517 Rel-17 CR0009r2 in S4-231001 has been merged into TS 26.517 Rel-17 CR0001r11 in S4aI230117

New issues targeting approval at SA#102 Edinburgh​

None.

Adopted TS 29.571 issues​

[#]Milestone
#1063GPP SA4#127-e-bis→SA#104

XCHANGE 27/07/2023​

Issues to be covered at the session​

See Kanban board for overview of open issues.

TS 26.247 - Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)​

New issues targeting approval at SA#101 Bangalore​

  • #79 5GMSd - QoE Metrics Reporting - Inconsistency with HTTPList.

TS 26.501 - 5G Media Streaming (5GMS); General description and architecture​

New issues targeting approval at SA#101 Bangalore​

  • #66 TS 26.501 Clarification - Appropriate network entity for metrics error reports.
    • Unclear which entity the Media Session Handler send error reports to when it cannot satisfy the requirements signalled in the client metrics reporting configuration.
    • Should this error reporting feature be removed completely from TS 26.501 in Rel-16, Rel-17 and Rel-18 since an error reporting endpoint has never been specified at stage-3?

TS 26.512 - 5G Media Streaming (5GMS); Protocols​

Issues resolved at SA#100 Taipei​

  • #59 Disambiguate Media Player Entry data types at M1 and M5
  • #60 Clarification on TS 26.512 ServiceAccessInformation.networkAssistanceConfiguration.serverAddresses values
  • #62 TS 26.512 Policy Template state reasons
  • #64 TS 26.512: Signalling of domainNameAliases during server certificate creation

Published as TS 26.512 V17.5.0.

Discussions​

  • #49 Discussion Item: Signaling of DRM information via Service Access Information
  • #63 Discussion: 5GMSd Network Assistance - Synergy with CTA-Wave Common Media Server Data (CMSD)
  • #72 Discussion: TS 26.512 - How is consumption reporting triggered?
    • Daniel has already found some answers to the equivalent problem for QoE metrics reporting.
  • #82 TS 26.512: Media streaming session identifier
    • The need for an identifier that allows UE data (of the same or different types) to be correlated after their exposure as Events.
    • New Rel-18 feature versus essential correction to Rel-17?
    • Need for stage-2 motivation in TS 26.501?

Issues previously adopted but carried over from a previous meeting cycle​

  • #45 Specify methods in the M6 Media Session Handling client API to invoke 5GMS network assistance
    • Maybe something in the next meeting cycle?
  • #61 TS 26.512 Policy Template state change events
    • Maybe add something later in Rel-18?

Issues previously adopted and targeting endorsement at SA#101 Bangalore​

  • #33 Use of aspId and externalApplicationId in M1_ProvisioningSession_createProvisioningSession
    • Maybe include a clarification to TS 26.512 Rel-18 CR0036 or TS 26.512 Rel-17 CR0037?
  • #42 Specify client-facing 5GMS AF host name to be used by Media Session Handler at M5
    • See TS 26.512 Rel-18 CR0036 in S4aI230104 clause 6.1A.2.

New issues targeting approval at SA#101 Bangalore​

  • #65 TS 26.512 MetricsReportingConfiguration scheme cardinality does not match YAML definition
    • Apparent discrepancy to be confirmed by SA4 experts.
    • See TS 26.512 Rel-17 CR0037 in S4aI230105.
  • #67 TS 26.512 - Typo in word "Metrics" - Should be named "metrics".
    • See TS 26.512 Rel-17 CR0037 in S4aI230105 table 11.2.3.1-1, but this really needs fixing in Rel-17 too.
  • #69 TS 26.512 - Handling of 3XX HTTP redirects via interface at M2d
    • See TS 26.512 Rel-17 CR0037 in S4aI230105 but this really needs fixing in Rel-16 and Rel-17 too.
  • #71 TS 26.512 - How to choose a address from clientConsumptionReportingConfiguration.serverAddresses array for consumption reporting
    • Historical precedent for QoE metrics reporting in TS 26.247 annex F is random selection for load balancing.
  • #73 TS 26.512 - Consumption reporting: How is aspId for POST URL generated?
    • See TS 26.512 Rel-17 CR0037 in S4aI230105 proposing change to API in Rel-18 to use provisioningSessionId instead of aspId.
  • #74 Possible inconsistency in specification of Service Data Flow Description
  • #78 5GMSd - QoE Metrics Reporting - Clarification on sampling rate for buffer level
    • Proposed general solution applicable to all QoE metrics (not just buffer level) is to add samplingPeriod to M1 MetricsReportingConfiguration and M5 ServiceAccessInformation.clientMetricsReportingConfiguration.
    • This would align TS 26.512 Rel-17 with Charles Lo's final TS 26.532 Rel-17 CR0003.
    • Should this change also be made to TS 26.512 Rel-16?
  • #75 TS 26.512: Network Assistance recommendation and boost time windows
    • Proposal to explicitly signal the duration of the validity window of bit rate recommendations and delivery boosts using HTTP cache control response headers.
  • #76 TS 26.512: NetworkAssistanceSession Request body not specified in the OpenAPI YAML for M5 createNetworkAssistanceSession operation
    • Apparent discrepancy, but original intent needs to be confirmed by SA4 experts.
  • #80 5GMS AF treatment of Network Assistance Session resource
    • How should 5GMS AF behave if a QoS is requested when creating a Network Assistance Session, but no Policy Template is cited?
    • And how should it behave if both of these are included when creating a Network Assistance Session?

TS 26.517 - 5G Multicast-Broadcast User Services; Protocols and Formats​

Issues resolved at SA#100 Taipei​

  • #52 Specify object manifest file format for MBS User Services
  • #56 Specify mechanism for discovery of MBS User Service Announcement by MBS Client
    • (See below for stage-3.)

Published as TS 26.517 V17.3.0.

Issues previously adopted and targeting approval at SA#101 Bangalore​

  • #53 Applicability of Schedule Description metadata unit in MBS User Service Announcement is inconsistent
    • Proposed clarification included in Qualcomm TS 26.517 Rel-17 CR0001r11 in S4aI230117.
  • #54 Add a figure to illustrate JSON-based syntax of MBS User Service Announcement
    • Replacement figure included in Qualcomm TS 26.517 Rel-17 CR0001r11 in S4aI230117.
  • #55 Clarify population of Schedule Description metadata unit in MBS User Service Announcement
    • Wholesale redraft in next revision of TS 26.517 Rel-17 CR0001 will hopefully flush this issue out.
  • #56 Specify mechanism for discovery of MBS User Service Announcement by MBS Client
    • Stage-2 procedures clarified during previous meeting cycle in TS 26.502 V17.5.0 clause 5.4 (see above).
    • Stage-3 API proposal in TS 26.517 Rel-17 CR0010 in S4aI230124.
  • #57 Clarification of Byte Range Object Repair
    • Late contribution TS 26.517 Rel-17 CR0009r2 in S4-231001 has been merged into TS 26.517 Rel-17 CR0001r11 in S4aI230117

New issues targeting approval at SA#101 Bangalore​

None.

XCHANGE 11/05/2023​

Quick update on Reference Tools​

Quick summary of progress on issues at SA4#123-e​

Look ahead to issues for consideration at SA4#124 Berlin​

Presentation and possible adoption of new issues for submission to SA4#125 Gothenburg​

For discussion:​

Issues to be covered at the session​

See Kanban board.

XCHANGE 11/03/2023​

The page references below are as presented at the time (11/03/2023) on the legacy pre-Docusaurus 5G-MAG site and may no longer resolve; they are kept here as a historical record of what was shown, not as live links.

What 5G-MAG does​

  • Provide insight into specs towards development/implementation
  • Foster industry engagement into applications and services
  • Support development and implementation work
  • Bring specs to life with demos and trials
  • Provide specification feedback to 3GPP (see the current Kanban board)

Reference Tools: achievements so far​

  • Implemented a Minimum Viable Product for 5G Media Streaming based on downlink Content Hosting.
    • Recently expanded this to include 5GMS AF provisioning at reference point M1d and 5GMS AS configuration at M3d.
  • Basic Rel-17 reference implementations of the 5GMSd Application Function and 5GMSd Application Server that support the key features of Content Hosting for downlink media streaming.
    • Provisioning Sessions, Server Certificates and Content Hosting Configurations can be provisioned in the 5GMSd AF via an implementation of the M1d Provisioning API, complemented by a test client.
    • Server Certificates and Content Hosting Configurations can be configured by the 5GMSd AF in the 5GMSd AS via a simple prototype implementation of an M3d Configuration API, complemented by a test client.
  • There are also basic reference implementations of the Media Player and Media Session Handler for Android.
    • The Media Session Handler, which runs as a shared Android background service, is driven by a basic implementation of the M6 Media Session Handling client API. It can retrieve its configuration for a specific Provisioning Session from the 5GMSd AF using the M5d Service Access Information API.
    • The setup uses a single index.json file that only contains provisioningSessionIDs, mediaPlayerEntry and the M5 URL.

Client-side workflow​

  1. Once the app starts, the mediaPlayerEntries are populated to the selection dropdown
  2. An entry in the dropdown is selected
  3. The MediaStreamHandler sends an IPC message to the Media Session Handler Background Service updating the lookup table (mapping between provisioningSessionIDs and mediaPlayerEntries)
  4. A stream is selected and the mediaPlayerEntry is send via IPC to the MediaSessionHandler
  5. The Media Session Handler Background Service contacts the AF (or a mocked REST server) using the route syntax defined in 26.512 11.2.2: {apiRoot}/3gpp-m5/{apiVersion}/service-access-information/ adding the {provisioningSessionId}. provisioningSessionId derived via lookup table.
  6. Once it has received the Service Access Information it sends back an IPC message to the Media Stream Handler with the mediaPlayerEntry
  7. The Media Stream Handler plays the MPD defined in mediaPlayerEntry using M7 interface and Exoplayer.
  8. Media Stream Handler collects metrics. Metric reporting endpoint to be defined.

What we intend to do next​

  • Continue engaging with standards experts in driving specs beyond the writing work.
  • Help SA4 spec development based on developers’ feedback. Our GitHub tracker is open to anyone: https://github.com/orgs/5G-MAG/projects/33
    • 5G-MAG and SA4 MBS subworking group have held two joint meetings already (in the run up to SA4#121 Toulouse and SA4#122) and these concentrated on maintenance of TS 26.512 Rel-16 and Rel-17.
    • The changes to that specification agreed recently in Athens are due to go to SA#99 next week for approval and publication, and we have already started to implement them at risk.
    • For the forthcoming meeting cycle, there is a mixture of issues relating to:
      • TS 26.512, based on the reference implementation experience.
      • TS 26.517, primarily notifying gaps that have been identified.
    • 5G-MAG is aware that both SA4#123-e and SA4#124 Berlin feed into SA#100 Taipei, so the next opportunity to see agreed changes after Easter will be in late June.
  • 5G-MAG intends to participate in the upcoming 3GPP Rel-19 Workshops in our role as Market Representation Partner of 3GPP. We would like to understand the plans for SA4 on such workshops (schedule, thoughts, …)

Issues to be covered at the session​

See Kanban board.