6.3.3 Methods
26.3473GPPApplication Programming Interface and URLMultimedia Broadcast/Multicast Service (MBMS)Release 17TS
6.3.3.1 Overview
Table 6.3.3.1-1 provides an overview over the methods defined for the Streaming Delivery Application Service API. Different types are differentiated, namely state changes triggered by the MAA, status query of the MAA to the client, parameter updates as well as notifications from the client. The direction of the main communication flow between MAA (A) and MBMS Client (C) is provided.
Table 6.3.3.1-1: Methods defined for Streaming Delivery Application Service API
|
Method |
Type |
Direction |
Brief Description |
Section |
|---|---|---|---|---|
|
registerStreamingApp |
State change |
A -> C |
MAA registers a callback listener with the MBMS client |
6.3.3.2 |
|
deregisterStreamingApp |
State change |
A -> C |
MAA deregisters with the MBMS client |
6.3.3.10 |
|
startStreamingService |
State change |
A -> C |
Starts streaming service |
6.3.3.7 |
|
stopStreamingService |
State change |
A -> C |
Stop streaming service |
6.3.3.9 |
|
getStreamingServices |
Status query |
C <-> A |
Get list of currently active services |
6.3.3.4 |
|
getVersion |
Status query |
C <-> A |
Retrieves the list of files previously captured for the MAA |
6.3.3.13 |
|
setStreamingServiceClassFilter |
Update to parameter list |
A -> C |
MAA sets a filter on file delivery services in which it is interested |
6.3.3.5 |
|
registerStreamingResponse |
Update to parameter list |
C-> A |
The response to the MAA streaming service register API |
6.3.3.3 |
|
serviceStarted |
Notification |
C -> A |
Notification to MAA when the streaming service started. |
6.3.3.8 |
|
streamingServiceListUpdate |
Notification |
C -> A |
Notification to MAA on an update of the available for Media streaming delivery services |
6.3.3.6 |
|
streamingServiceError |
Notification |
C -> A |
Notification to MAA when there is an error with the download of service |
6.3.3.12 |
|
serviceStalled |
Notification |
C -> A |
Notification to MAA that download Media segments failed |
6.3.3.11 |
|
addSA |
Update to parameter list |
A -> C |
Adds service announcement to the MBMS client on streaming services |
6.2.3.22 |
|
addSAResponse |
Notification |
C -> A |
Call back to addSA() |
6.2.3.23 |
|
metricsCollection |
State change |
A -> C |
Starts, updates, or stops the collection of metrics based on the parameters provided in the API call |
6.3.3.14 |
6.3.3.2 Registration
6.3.3.2.1 Overview
This clause defines registerStreamingApp() interface.
An MAA calls the registerStreamingApp() interface to register with the MBMS Client to consume streaming services. The registerStreamingApp() interface has two purposes:
1) It signals to the MBMS Client that an MAA is interested to consume MBMS Media Streaming Services.
2) It allows the MAA to identify its callback listeners defined in the Streaming Service API for the MBMS Client to provide asynchronous notifications to the MAA on relevant events associated with streaming.
Note: Since some application development frameworks do not support callback functions, an MAA for these frameworks will not provide callback listeners in the registerStreamingApp() interface. Instead, the MAA will implement the necessary approach available on these frameworks to receive event notifications from the MBMS Client in place of callback functions. The notifications implemented on these frameworks will include the same information content as defined on the structures for the IDL callback functions.
Figure 6.3.3.2-1 shows the registration process
Figure 6.3.3.2-1: Application Registration sequence diagram
6.3.3.2.2 Parameters
The parameters for the registerStreamingApp () API are:
– string appId – provides a unique ID for the MAA registering with the MBMS client, which uses this identity to maintain state information for a particular MAA. The uniqueness of the ID is in the context of any MAA that may possibly register with MBMS client. Uniqueness is typically provided on platform level.
– any platformSpecificAppContext – a platform-specific context for the registering MAA that enables the MBMS client to get extra information about the MAA that may be need to enable the MAA to have access to MBMS services, e.g., to enable MAA authentication or to enable the MAA to communicate with the MBMS client via platform (e.g., HLOS) services.
– sequence<string> serviceClassList – provides a comma-separated list of service classes which the MAA is interested to register. Each service class string can be any string or it may be empty.
– ILTEStreamingServiceCallback callBack – provides the MBMS client with the call back functions associated with Media Streaming Application Service APIs for the registering MAA.
Note: The callback element in the IDL description is optional and only included when the MAA development framework supports programmatic callback interfaces. If callbacks are not supported on a given MAA development framework, the same information content as defined on the callback structures is to be provided to the MAA via the notification method available with that development framework when the respective condition is met.
6.3.3.2.3 Pre-Conditions
The MAA has assigned a unique application ID appId in the context of its operation (e.g., a smartphone HLOS) with the MBMS client.
The MAA is pre-configured with the set of service classes that allows it to consume the Media Streaming Services associated with these service classes.
The MAA has access to a Media Streaming client.
The MAA may use this method at launch or after a deregisterStreamingApp() has been called.
The MBMS client is in IDLE state.
6.3.3.2.4 Usage of Method for MAA
The MAA uses the method registerStreamingApp() to register with the MBMS Client to consume Streaming Services.
The MAA provides its appId and, if applicable, some platform specific MAA context, platformSpecificAppContext.
The MAA provides the set of service classes which the MAA is interested to register.
6.3.3.2.5 Expected MBMS Client Actions
When this method is invoked, the MBMS client registers the app, if possible. For more details refer to clause 6.3.2.3.
6.3.3.2.6 Post-Conditions
The MAA expects the registerStreamingResponse() as defined in clause 6.3.3.3.
6.3.3.3 Media Streaming Application Service Registration Response
6.3.3.3.1 Overview
This clause defines registerStreamingResponse()call.
As illustrated in Figure 6.3.3.2-1, the MBMS client responds to an MAA call to the registerStreamingApp() API with a registerStreamingResponse() call back providing the result of the registration request.
6.3.3.3.2 Parameters
The parameters for the registerStreamingResponse() API are:
– EmbmsCommonTypes::RegResponseCode value – provides a result code on the registration request. The allowed values are:
– REGISTER_SUCCESS – indicates that the registration has been processed successfully and the MAA can proceed with other API interactions with the MBMS client for Streaming Delivery Application Services.
– FAILED_LTE_EMBMS_SERVICE_UNAVAILABLE – Indicates that the registration has failed since the Streaming Delivery Application Service API did not find an MBMS client available on the UE on which the MAA is running and no MBMS service will be available to the MAA.
– MISSING_PARAMETER – indicates that the registration has failed since one or more of the required parameter was missing.
– string message – provides an associated text description of the error message. The message may be empty.
6.3.3.3.3 Pre-Conditions
The MBMS client has received a call via the registerStreamingApp() API as defined in clause 6.3.3.2.
6.3.3.3.4 Expected MBMS Client Actions
The MBMS client responds accordingly and depending on the response moves to one of the states: IDLE, NOT_AVAILABLE, or REGISTERED. For more details refer to clause 6.3.2.4.
6.3.3.3.5 Usage of Method for MAA
Once the MAA receives a the registerStreamingResponse() with the RegResponseCode set to REGISTER_SUCCESS, the MAA can proceed with other API interactions with the MBMS client.
If the MBMS client is temporarily in NOT_AVAILABLE, if the registerStreamingResponse() signaled a failure with a FAILED_LTE_EMBMS_SERVICE_UNAVAILABLE, the MAA may periodically recheck if the state of the MBMS client changes by retrying the registerStreamingApp()API.
If the MBMS client is responding with MISSING_PARAMETERS, the MAA should fix the parameters and retry the registerStreamingApp() API.
6.3.3.3.6 Post-Conditions
If the MBMS client functions cannot be activated and once the response is sent, then MBMS client is at least temporarily in NOT_AVAILABLE state.
If the MBMS client functions can be activated and respective response is sent, then MBMS client is in REGISTERED state with the REGISTERED parameters as set above.
6.3.3.4 Getting information on available Media Streaming Application Services
6.3.3.4.1 Overview
This clause defines getStreamingServices() API call.
The registerStreamingApp() interface returns the complete list of available Streaming Services information. As illustrated in Figure 6.3.3.2-1, after a successful registration with the MBMS client, the MAA can use the getStreamingServices() API to discover the available Streaming Services associated with the service classes registered via the registerStreamingApp().
6.3.3.4.2 Parameters
The getStreamingServices() API does not have any input parameters.
The getStreamingServices() API returns a list describing the available Media Streaming Services, where each service is described by the following output only parameters:
– sequence<ServiceNameLang> serviceNameList – optionally provides a list of the service title name in possibly different languages. Each (name, lang) pair defines a title for the service on the language indicated.
– string name – offers a title for the user service on the language identified in the lang parameter.
– string lang – identifies a natural language identifier per RFC 3066 [10].
– string serviceClass – identifies the service class which is associated with the service.
– string serviceId – provides the unique service ID for the service. The uniqueness is among all services provided by the BMSC.
– string serviceLanguage – indicates the available language for the service and represented as an identifier per RFC 3066 [10].
– EmbmsCommonTypes::ServiceAvailabilityType serviceBroadcastAvailability – signals whether the UE is currently in the broadcast coverage area for the service.
– The possible values are:
– BROADCAST_AVAILABLE – if content for the service is broadcast at the current device location.
– BROADCAST_UNAVAILABLE – if content for the service is not broadcast at the current device location.
– SERVICE_UNAVAILABLE – if content for the service is at all available at the current device location.
– string mimeType – provides the MIME type which defines the media transport format used (DASH, HLS).
– string ManifestUri – provides an HTTP URL where the Manifest for the Media Streaming Application Service is hosted and available for Media Clients access.
– EmbmsCommonTypes::Date activeServicePeriodStartTime – signals the current/next active Media Streaming Application Service start time, when media segments and other resources start being broadcast over the air.
– EmbmsCommonTypes::Date activeServicePeriodEndTime – signals the current/next active DASH Streaming Application Service stop time, when media segments and other resources stop being broadcast over the air.
6.3.3.4.3 Pre-Conditions
The MBMS client is in REGISTERED state.
6.3.3.4.4 Expected MBMS Client Actions
When this method is invoked, the MBMS client returns the streaming service parameters. For more details refer to clause 6.3.2.4.
6.3.3.4.5 Usage of Method for MAA
The MAA should use this call right after the registerStreamingResponse() notification as defined in clause 6.3.3.3 is received or after the streamingServiceListUpdate() notification as defined in clause 6.3.3.6 is received.
The MAA should use the serviceId to identify the service in subsequent communication with the MBMS client to manage the streaming service.
The usage of the parameters serviceNameList, serviceClass, serviceBroadcastAvailability, and serviceLanguage is typically up to the MAA.
The mimeType should be used by the MAA to select the media transport format used
The ManifestURI should be used by the MAA to initiate playback by initiating a Media Client. The MAA should assume that Media Presentation can be consumed by the Media Client without any further interaction with the MAA.
The parameters activeServicePeriodStartTime and activeBroadacstPeriodEndTime provides the MAA the ability to determine the current broadcast state for the service as follows:
– If the current time is such that activeServicePeriodStartTime ≤ current time ≤ activeServicePeriodEndTime, media content is being broadcast for the service at the current time.
– If the activeServicePeriodStartTime is in the future, there is currently no broadcast being made for the service, but broadcast transmission is currently scheduled to start at this advertised time.
– If the activeServicePeriodStartTime is set to zero, there is no currently defined broadcast schedule time for the service.
6.3.3.4.6 Post-Conditions
This call does not change the MBMS client state.
The MAA uses the serviceId to identify the service in subsequent communication with the MBMS client.
6.3.3.5 Updating the registered service classes
6.3.3.5.1 Overview
This clause defines setStreamingServiceClassFilter() call.
While an MAA is actively registered with the MBMS client to consume Media Streaming Services, the MAA can call the setStreamingServiceClassFilter() API to update the list of service classes the MAA wants to be registered with, see Figure 6.3.3.5.1-1.
Figure 6.3.3.5.1-1: Sequence diagram for updating the registered service classes for an MAA
6.3.3.5.2 Parameters
The parameters for the setStreamingServiceClassFilter() method are:
– sequence<string> serviceClassList – see clause 6.3.3.2.2
6.3.3.5.3 Pre-Conditions
The MAA is actively registered with the MBMS client to consume Media Streaming Services, and MBMS client is in REGISTERED state for the MAA.
6.3.3.5.4 Expected MBMS Client Actions
When this method is invoked, the MBMS client updates the internal parameters and is expected to provide a streamingServiceListUpdate() notification as defined in clause 6.3.3.6. For more details refer to clause 6.3.2.4.
6.3.3.5.5 Usage of Method for MAA
The MAA may invoke the setStreamingServiceClassFilter() API to update the previously defined new list of service classes that includes additional service classes or includes fewer service classes than the list of service classes.
The MAA should be aware that the updates are only active once an streamingServiceListUpdate() notification is received that confirms the new service class filters.
6.3.3.5.6 Post-Conditions
The MAA expects a streamingServiceListUpdate() notification as defined in clause 6.3.3.6.
6.3.3.6 Updating the Streaming Service List
6.3.3.6.1 Overview
This clause defines streamingServiceListUpdate() notification.
This notification is used by the MBMS client to inform the MAA about a successful API call setStreamingServiceClassFilter() as shown in Figure 6.3.3.5.1-1 or other updates in streaming service list.
6.3.3.6.2 Parameters
None.
6.3.3.6.3 Pre-Conditions
The MBMS client is in REGISTERED state for the MAA. The MAA has issued a setStreamingServiceClassFilter()API call.
6.3.3.6.4 Expected MBMS Client Actions
The MBMS client issues this notification as a response to a successful setStreamingServiceClassFilter()API call or to the response to updates of the service list provided in the Manifest. For more details see clause 6.3.2.4.
6.3.3.6.5 Usage of Method for MAA
The MAA is informed about the updates of the service class list and may issues a getStreamingServices() API call as defined in clause 6.3.3.4 to obtain the updated service list.
6.3.3.6.6 Post-Conditions
The MAA has the latest service list. No state change is involved.
6.3.3.7 Start Media Streaming Service
6.3.3.7.1 Overview
This clause defines startStreamingService() API.
After the Media Streaming Application Service registration, the MAA can make calls on the startStreamingService() API for the MBMS client to start reception of Media content received over unicast or broadcast as shown in Figure 6.3.3.7-1.
Figure 6.3.3.7-1: MAA starts Media Streaming Services (DASH Example)
6.3.3.7.2 Parameters
The parameters for the startStreamingService() API are:
– string serviceId – see definition in clause 6.3.3.2.2.
6.3.3.7.3 Pre-Conditions
The MBMS client is in REGISTERED state.
The MAA has the latest service list, for example through the getStreamingServices() API call as defined in clause 6.3.3.4.
6.3.3.7.4 Usage of Method for MAA
The MAA can make calls on the startStreamingService() API for the MBMS client to start reception of Media content received over unicast or broadcast.
When MAA is no longer interested in consuming the Streaming Service, it should call the stopStreaming() API call as defined in clause 6.3.3.9.
6.3.3.7.5 MBMS Client Actions
When this method is invoked, the MBMS client starts the streaming service, if possible. For more details see clause 6.3.2.4.
6.3.3.7.6 Post-Conditions
When this method is invoked, the MBMS client starts the streaming service, if possible. For more details see clause 6.3.2.4.
6.3.3.8 Notification that Media Streaming for a Service has started
6.3.3.8.1 Overview
This clause defines serviceStarted() callback function.
As illustrated in Figure 6.3.3.7-1, once the MBMS client has successfully collected all necessary information to start the service the MBMS client invokes the serviceStarted() callback function.
6.3.3.8.2 Parameters
The parameters for the serviceStarted() API are:
– string serviceId – see definition in clause 6.3.3.2.2.
6.3.3.8.3 Pre-Conditions
The MAA issued a startStreamingService() API call.
The MBMS client is in REGISTERED state for the serviceId.
6.3.3.8.4 Expected MBMS Client Actions
The MBMS client issues this notification if the service is started successful. For details see clause 6.3.2.4.
6.3.3.8.5 Usage of Method for MAA
Once the MAA receives the callback on the successful start of the service with the serviceId, the MAA may start the streaming service by initiating a Media Presentation at a Media Client by handing over the mpdURI received during the registration process for this service.
6.3.3.8.6 Post-Conditions
The Media Cclient can communicate with the MBMS client. The MBMS client makes available the Media Streaming APplication Services – based on the Manifest referenced in by the ManifestURI of the service.
6.3.3.9 Stop Media Streaming Service
6.3.3.9.1 Overview
This clause defines stopStreamingService() API.
As Figure 6.3.3.7-1 illustrates, when an MAA that issued a startStreamingService() for a service is no longer interested in consuming the Media content for that service, it will call the stopStreamingService() API call.
6.3.3.9.2 Parameters
The parameter for the stopStreamingService() API is:
– string serviceId – see definition in clause 6.3.3.2.2.
6.3.3.9.3 Pre-Conditions
The MBMS client is in ACTIVE state for this MAA.
6.3.3.9.4 Usage of Method for MAA
If an MAA is no longer interested in consuming the Media service, it should call the stopStreamingService() API call. Latest at the same time, the MAA should inform the DASH client about the termination of the service and the Media client should no longer request resources that are provided directly or referenced by the ManifestURI.
6.3.3.9.5 MBMS Client Actions
The MBMS terminates the reception. For more details see clause 6.3.2.5.
6.3.3.9.6 Post-Conditions
The MBMS client is in REGISTERED state. The Media Presentation referenced by the ManifestURI can no longer be accessed as the referenced Segments will no longer be provided at the announced location in the Manifest.
6.3.3.10 Media Streaming Application Service De-registration
6.3.3.10.1 Overview
This clause defines deregisterStreamingApp() API call.
An MAA registers services classes with the MBMS client to request the start of streaming for Media Streaming Application Services. The MAA that registered with the MBMS client via the registerStreamingApp() API should invoke the deregisterStreamingApp() before exiting. The MBMS clients stops monitoring for Service Announcement updates when there are no MAAs registered. There are no parameters for the registerStreamingApp() API.
6.3.3.10.2 Parameters
None.
6.3.3.10.3 Pre-Conditions
The MBMS client is in REGISTERED state for this MAA.
6.3.3.10.4 Usage of Method for MAA
MAA registered with the MBMS client via the registerStreamingApp() API should invoke the deregisterStreamingApp() before exiting.
If the MAA deregisters, it will no longer receive notifications from the MBMS client and all context is cleared.
6.3.3.10.5 MBMS Client Actions
The MBMS client no longer sends notifications and clears all context for the MAA.
6.3.3.10.6 Post-Conditions
The MAA is no longer registered with the MBMS client.
The MBMS client is in IDLE mode..
6.3.3.11 Notification that Media Streaming for a Service has stalled
6.3.3.11.1 Overview
This clause defines the serviceStalled() notification.
The MBMS client enables consumption of a Media Streaming Application Service if the current setting for serviceBroadcastAvailability is BROADCAST_AVAILABLE or BROADCAST_UNAVAILABLE. However, due to UE mobility in and out of broadcast coverage for some Media Streaming Application Services, the serviceBroadcastAvailability for those services may change to SERVICE_UNAVAILABLE (i.e., the UE moves out of coverage for that service). Other circumstances may also prevent the broadcast reception of that service (e.g., a frequency conflict). In these circumstances, the MBMS client can signal the MAA that the service is temporarily not available for playback by invoking the serviceStalled() API.
When broadcast reception of the service is re-established, the MBMS client will signal the MAA that the service is again available for playback by invoking the serviceStarted() API. This is illustrated in Figure 6.3.3.11.1.
Figure 6.3.3.11.1: Signaling that a Media Streaming Service stalled (DASH Example)
6.3.3.11.2 Parameters
The parameter for the serviceStalled() API are:
– string serviceId – identifies the Media Streaming Application Service for which broadcast receptions have temporarily stalled.
– StalledReasonCode reason – provides specific information on what caused the service to stall. Valid options are:
– RADIO_CONFLICT – indicates a frequency conflict, namely the service requested to be started via a startStreamingService() cannot be started at this time since the MBMS client is actively receiving another service on a different frequency band.
– END_OF_SESSION – indicates that playback has reached the end of the scheduled transmission for the service as described by the schedule description fragment for the service. This should indicate that the advertised activeServicePeriodEndTime time has been reached.
– OUT_OF_COVERAGE – indicates a UE mobility event to an area where the service with streamingSubtype set to STREAMING_BC_ONLY is not available via broadcast.
– STALLED_UNKNOWN_REASON – indicates that another unspecified condition caused the service interruption.
6.3.3.11.3 Pre-Conditions
The MBMS client is in ACTIVE mode.
6.3.3.11.4 Expected MBMS Client Actions
The MBMS client provides a serviceStalled() notification in case it can no longer provide the referenced resources in the Media Presentation provided with ManifestURI. For more details refer to clause 6.3.2.5.
6.3.3.11.5 Usage of Method for MAA
The MAA should stop the Media client playback on reception of the serviceStalled() notification. However, unless the MAA is no longer interested in the content, it should not issue a stopStreamingService() call in order to allow the MBMS client from trying to collect Media content once the download problem is resolved. The MAA should inform the user of the temporary service interruption.
If the Media client maintains in STALLED state for too long, the MAA should stop the service by issuing a stopStreamingService().
6.3.3.11.6 Post-Conditions
The MBMS client is in STALLED mode.
6.3.3.12 Notification of Media Streaming Application Service errors
6.3.3.12.1 Overview
This clause the streamingServiceError() notification.
As illustrated in Figure 6.3.3.12.1-1, the startStreamingService() request from an MAA may not be served, so the MBMS client will send a failure indication via the streamingServiceError() to signal the error code for the result of processing the MAA’s startStreamingService().
Figure 6.3.3.12.1-1: Signaling errors with the startStreamingService() request from the Media Streaming Application
Figure 6.3.3.12.1-2 also illustrates that the streamingServiceError() is used to signal the error code for the result of processing the MAA’s a stopStreamingService() request.
Figure 6.3.3.12.1-2: Signaling errors with the stopStreamingService() request from the Media Streaming Application
6.3.3.12.2 Parameters
The parameters for the streamingServiceError() API are:
– string serviceId – identifies the Media Streaming Application Service on which the MBMS client failed.
– StreamingErrorCode errorCode – identifies the error code for the reason causing the startStreamingService() or the stopStreamingService() request for the serviceId to fail. The available error codes are:
– STREAMING_INVALID_SERVICE – signals that serviceID defined on the startStreamingService() or the stopStreamingService() request is not currently defined or it is not associated with the service classes with the MAA is registered.
– STREAMING_UNKNOWN_ERROR – signals an error condition not explicitly identified.
– string errorMsg – may provide additional textual description of the error condition.
6.3.3.12.3 Pre-Conditions
The MBMS client has received a the startStreamingService() or a stopStreamingService() request.
6.3.3.12.4 Expected MBMS Client Actions
The MBMS client will send a failure indication via the streamingServiceError() to signal the error code for the result of processing the MAA. For more details refer to clause 6.3.2.4 and 6.3.2.5.
6.3.3.12.5 Usage of Method for MAA
If the MAA receives this notification, it should revalidate the capture call. The MAA should also update the service list by issuing a getStreamingServices() as defined in clause 6.3.3.4.
6.3.3.12.6 Post-Conditions
No state change is applied.
6.3.3.13 Checking the version for Media Streaming Application Service interface
6.3.3.13.1 Overview
This clause defines the getVersion() request function.
6.3.3.13.2 Parameters
The parameters for the getVersion()API call are:
– string version – identifies the version of the MBMS clients API implementation.
6.3.3.13.3 Pre-Conditions
The MBMS client may be in any state.
6.3.3.13.4 Usage of Method for MAA
In order for the MAA to know the version of the Media Streaming Delivery Application Service interface, the getVersion() API call may be used. If the version number is not supported by the MAA, it should deregister and not use the API.
6.3.3.13.5 MBMS Client Actions
The getVersion() API returns the version of the implemented APIs of the MBMS client.
6.3.3.13.6 Post-Conditions
No state changes apply.
6.3.3.14 Metrics Collection
6.3.3.14.1 Overview
This clause defines the metricsCollection() API call. Metrics collection is assumed to be asynchronous, i.e. metrics are collected by the MBMS Client according to the configuration and the MMBS-Aware Application retrieves metrics reports from it when needed.
An overview of the procedure is provided in Figure 6.3.3.14-1.
Figure 6.3.3.14-1: Metrics collection call flow
6.3.3.14.2 Parameters
The parameters for the metricsCollection()API call are:
– active – set to true or false whether metrics collection is activated or not.
– configuration – Configuration parameters for metrics collection.
– parameters – List of parameters that the MBMS Client shall collect.
– URL – Metrics Server URL from which metrics reports are to be fetched by the MBMS-Aware Application.
6.3.3.14.3 Preconditions
The MBMS Client shall be in the ACTIVE state.
6.3.3.14.4 Usage of method by MBMS-Aware Application
The MBMS-Aware Application triggers metrics collection in the MBMS Client and configures the collection parameters.
The MBMS-Aware Application subsequently retrieves metrics reports asynchronously from the MBMS Client by polling an endpoint URL provided by the MBMS Client in response. The metrics report returned by this endpoint shall include all metrics collected since the last invocation. If no metrics have been collected since the last invocation, the metrics report shall be empty.
6.3.3.14.5 MBMS Client actions
The metricsCollection() API allows the MBMS Client to be configured.
The MBMS Client collects the metrics according to TS 26.346 [5] and provides metrics reports to the MBMS-Aware Application on demand.
6.3.3.13.6 Postconditions
No state changes apply.