-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
5GMS - Media Session Handler - Consumption Collection & Reporting #3
Comments
Relation to CMCD? Potential synergy? |
Some questions that did arise during the implementation:
Example of the consumption report as generated by #40 {
"mediaPlayerEntry": "https://dash.akamaized.net/envivio/EnvivioDash3/manifest.mpd",
"reportingClientId": "4bca85f1-21ac-4233-a665-b6a07a84c5be",
"consumptionReportingUnits": [
{
"mediaConsumed": "v7_257",
"mediaEndpointAddress": null,
"startTime": "2023-09-26T16:22:51Z",
"duration": 0,
"locations": null
},
{
"mediaConsumed": "v4_258",
"mediaEndpointAddress": null,
"startTime": "2023-09-26T16:22:51Z",
"duration": 0,
"locations": null
}
]
} |
In the absence of a clear specification, maybe the last Consumption Reporting Unit in the consumption report describes the media currently being consumed. I would expect this to specify how long the Representation has been playing.
If the same Representation is still being consumed when it's time to send the next consumption report, I would say that this Consumption Reporting Unit is repeated as the first one in that next report, with the same startTime as before, but a longer duration. The recipient of the consumption reports could then apply some queue compression to ignore all but the last Consumption Reporting Unit with the same start time. Please raise a Specification issue asking for both of these points to be clarified in TS 26.512. |
When the ServiceAccessInformation.clientConsumptionReporting.locationReporting flag is set, ConsumptionReportingUnit.locations is an array of locations where the UE was when this Consumption Reporting Unit was logged by the 5GMS Client. The TypedLocation type allows a number of different types of location to be reported. I suppose the Media Stream Handler will need to invoke an suitable Android API to log this information during a media streaming session. |
The media delivered at reference point M4 may be served from one of many different 5GMS AS instances in a horizontally scaled deployment of the 5GMS System. In some deployments, these 5GMS AS instances may share the same DNS name, but have different IP addresses. In some cases, the different 5GMS AS instances may be deployed in different Data Networks and/or network slices, in which case they may have different IP addresses. A 5GMS Client may even hop dynamically between different 5GMS AS instances during the course of a media streaming session to get the network Quality of Service it requires. It is useful for the system operator to know which endpoint was serving the media streaming session for debugging and other operational reasons. Any change to the 5GMS AS endpoint address during a media streaming session would result in a boundary between Consumption Reporting Units.
The 5GMS Client needs to interrogate the socket used a reference point M4 (not reference point M5, which might be on a different Data Network or slice) to determine the IP address of the remote end. You'll need to do some research on how to achieve this on Android. You may also need to register for network change events to find out when the world has moved under your feet. |
Added a standards issue here: 5G-MAG/Standards#90. Current implementation is documented here: 5G-MAG/rt-5gms-media-stream-handler#52 |
@rjb1000 Are you ok with closing this issue as we have detailed discussions here: |
Feature description
Executes the collection of content consumption measurement logs from the Media Player and sending of consumption reports to a 5GMSd AF about the currently consumed media within the available presentation, about the UE capabilities and about the environment of the media session for potential transport optimizations by the network or consumption report analysis.
Relevant specifications and corresponding sections
26.501 - 5G Media Streaming (5GMS); General description and architecture (Release 17)
26.512 - 5G Media Streaming (5GMS); Protocols (Release 17)
The text was updated successfully, but these errors were encountered: