You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just to mention that @haudiobe is developing a draft CR in 3GPP SA4 that embellishes 5GMS Consumption Reporting with information about whether a 5GMS downlink streaming session is currently being served via M4d (i.e. unicast) or eMBMS (i.e. multicast/broadcast).
Latest working draft in contribution S4aI221283, but this will be revised in the coming weeks.
Separately (but to be documented in the same draft CR above as it develops), SA4 is debating options for conveying MBMS Reception Reporting information to the service provider in order to facilitate the application layer switching between unicast and multicast envisaged by 5G-MAG.
Here is a brief impact analysis:
Option A: Continue to use the MBMS-native Reception Reporting procedures as specified in clause 9.4 of TS 26.346
Two suboptions have been identified:
MBMS reception reports are sent to the BM-SC (per TS 26.346 in Release 16), and xMB-C needs to be extended (or a new reference point defined) to expose this information to the "Service Provider" in the 5G-MAG deployment architecture.
MBMS reception reports are sent to a different endpoint at the "Service Provider" instead of to the BM-SC by twiddling the URL in the Service Announcement. This suboption avoids any changes to the MBMS API in the client or xMB.
Option B: Extend the MBMS Metrics Reporting mechanism to convey MBMS Reception Reporting information over M5d
(The Metrics Reporting feature of TS 26.512 in Release 16 was designed from the outset to be extensible with multiple different reporting schemes operating simultaneously.)
In the option, the MBMS API in the client needs to be extended (or a new client-side reference point defined) to allow the MBMS Client to share the required information with the Media Session Handler in the 5GMS Client.
Description
This ticket is supposed to hold all relevant information for 5G media streaming over eMBMS.
Related specifications
Architecture diagrams
The text was updated successfully, but these errors were encountered: