Consumption Reporting - Handling of access network change

[dsilhavy]

Feature description

TS 26.512 Section 4.7.4 defines procedures for consumption reporting. One requirement is the handling of access network changes:

If the consumption reporting procedure is activated, the Media Session Handler shall produce and submit a consumption report to the 5GMSd AF when any of the following conditions occur: Upon determining an access network change (e.g., unicast to eMBMS, or vice versa), if the clientConsumptionReportingConfiguration.accessReporting property is set to True.

To enable the MediaSessionHandler to request a new consumption report once the access network has changed the MediaStreamHandler needs to dispatch a access_network_changed event to the MediaSessionHandler.

[dsilhavy]

It might make sense to detect the change of an access network directly in the MediaSessionHandler as the underlying access network is shared by all instances of the MediaStreamHandler being connected to a MediaSessionHandler. In this case there is no need to dispatch an event from the MediaStreamHandler to the MediaSessionHandler, see also 5G-MAG/rt-5gms-media-session-handler#42

[shilinding]

As I understand, the ServiceAccessInfo will be updated(update clientConsumptionReportingConfiguration.accessReporting) when the access network changes on AF. And then, UE side will get the updated clientConsumptionReportingConfiguration.accessReporting while get ServiceAccessInfo, and determine whether need to report consumption report by clientConsumptionReportingConfiguration.accessReporting.

So I don't quite understand why we need to detect the change of an access network in the MediaSessionHandler(or even detect in MediaStreamHandler and dispatch a access_network_changed event to the MediaSessionHandler), but not get from ServiceAccessInfo from AF directly. And if it's a must, I think I don't know how to know the change of an access network on UE side.

[dsilhavy]

The AF is located on the core side, the network change is happening on the UE side. The clientConsumptionReportingConfiguration.accessReporting field in the ServiceAccessInformation does not change when the client switches to a different network. Instead,clientConsumptionReportingConfiguration.accessReporting defines if the client should react to an access network change and send a consumption report to the AF (see 26512 4.7.4):

If the consumption reporting procedure is activated, the Media Session Handler shall produce and submit a consumption report to the 5GMSd AF when any of the following conditions occur: Upon determining an access network change (e.g., unicast to eMBMS, or vice versa), if the clientConsumptionReportingConfiguration.accessReporting property is set to True.

However, I agree that we should define what should be considered an access network change. Maybe @rjb1000 can enhance/correct this list:

• Switch from unicast to broadcast delivery and vice versa. It can probably be detected by checking whether the segments are consumed from http://localhost or not. If two Media Stream Handlers can behave differently here (one still fetching via unicast the other one via broadcast, my comment above is obsolete).
• Switch from Wifi to mobile and vice versa

As a sidenote: 26501 5.6.3 defines a list of conditions under which a consumption report shall be sent. This list does not contain the access network change scenario that is listed in 26512 4.7.4.

[shilinding]

Got you, thanks.

But I think in TS 26.512 Section 4.7.4 literally the "access network change" only include the switching between unicast and broadcast, not include the switching between Wifi and mobile. And for both Wifi and mobile, the URL are start with http://localhost.

And if we detect the switching between unicast and broadcast by checking the URL of the segments(include http://localhost or not), I think may do it in MediaStreamHandler and then dispatch a access_network_changed event to the MediaSessionHandler is better. Because we only can get the URL of segments in MediaStreamHandler(unless pass the URLs to MediaSessionHandler, but I think it's a bad idea). So, why do you suggested to check in MediaSessionHandler?

[rjb1000]

I think the original intent was to detect changes between unicast and broadcast consumption of content. Obviously, that only applies in hybrid reception cases where more than one mode of content delivery is operative. How the UE detects that depends on which hybrid architecture is used. Three different switching strategies are documented in clause 6.4.4 of ETSI TR 103 972.

Regarding switching between cellular and Wi-Fi access networks: I am not sure if this is considered in scope or not. In fact, I can't find anything about this aspect of consumption reporting in TS 26.501. So this appears to be unmotivated at stage-2, unless I have missed it.

Detecting a switch from the cellular network to Wi-Fi and vice versa is probably easy using the Android API. But it raises an interesting question for 5G Media Streaming: if the 5GMS AS is deployed inside the mobile operator's Trusted DN, is it even accessible via Wi-Fi? The answer is "probably not". In such cases, the MPD probably needs to be conditioned for this eventuality, e.g. by providing an alternative CDN endpoint (perhaps at a lower priority) that can be fallen back to when access to the 5GMS AS is lost.

[dsilhavy]

I would like to pick this up in the call tomorrow, here are the discussion points that I think are relevant

What are Access Network changes

Description

26.512 4.7.4 states Upon determining an access network change (e.g., unicast to eMBMS, or vice versa), if the clientConsumptionReportingConfiguration.accessReporting property is set to True.

Questions

• What are other examples for a network change as the specification says "e.g."?
• Should this be specified in more detail?
• Detecting a switch from the cellular network to Wi-Fi and vice versa is probably easy using the Android API. But it raises an interesting question for 5G Media Streaming: if the 5GMS AS is deployed inside the mobile operator's Trusted DN, is it even accessible via Wi-Fi? The answer is "probably not". In such cases, the MPD probably needs to be conditioned for this eventuality, e.g. by providing an alternative CDN endpoint (perhaps at a lower priority) that can be fallen back to when access to the 5GMS AS is lost.

Detecting changes from broadcast to unicast

Description

Based on ETSI TR 103972 Section 6.4.4: In general, how can we detect that a switch from broadcast to unicast and vice versa in the MediaSessionHandler/MediaStreamHandler?

Option 1 (Single service instance with switching handled by 5G Broadcast Receiver)

• For 5GBC: The DVB-DASH client fetches segments and manifests from a local webserver in the 5G Broadcast receiver.
• For unicast: Directly be resolved by the DVB-DASH client from the DVB-DASH server
• The client can be steered by manipulating the manifest, adding SAND headers to MPD requests or probably also use a content steering server.
• How do we detect that a switch of the access network was done? Is looking at the BaseURLs sufficient?

Option 2 (Single service instance switched by DVB-DASH Client):

• The different delivery networks are differentiated by different representation Base URL.
• How can a DVB-DASH client can identify which BaseURL maps to broadcast and which one to unicast. The client is probably steered by an external service and not aware which delivery method is active? Unless http://localhost always means it is playing broadcast content hosted by the 5G Broadcast Receiver

Option 3 (Two seamlessly switchable DVB-I service instances switched by DVB-DASH Client):

• Each service instance is described by its own DVB-DASH MPD.
• Can we use DVB-I service list attributes to know if an MPD references broadcast or unicast segments?

Evaluation of the Consumption Reports

Description

Related to the previous discussion item, how does the application provider or the entity that consumes the consumption report know that a change of the access network has happened? Looking at the option 1 and 2 above, the Representation@id does not change when an access network switch was done. Consequently, the mediaConsumed property remains the same in the ConsumptionReportingUnit. If mediaEndpointAddress contains the server EndpointAddress and not client EndpointAddress the information can probably be derived based on localhost usage?

Btw this would also explain why mediaEndpointAddress should be "Present only if access reporting is enabled in the Consumption Reporting Configuration."

Others

• 26501 5.6.3 defines a list of conditions under which a consumption report shall be sent. This list does not contain the access network change scenario that is listed in 26512 4.7.4.

[dsilhavy]

Agreed to put this to the backlog as the desired behavior needs to be clarified.