6.3.2 MBMS Client State Model for Media Streaming
26.3473GPPApplication Programming Interface and URLMultimedia Broadcast/Multicast Service (MBMS)Release 17TS
6.3.2.1 Overview
Figure 6.3.2-1 provides an informative client state model in order to appropriately describe the messages on the Media streaming service API. Four different states are defined. State changes may happen based on:
– Calls from the MAA or the Media client
– Information provided by the MBMS User Service (USD, schedule, FDT, file complete)
– Changes in the reception conditions
Figure 6.3.2-1: State Diagram
Table 6.3.2-1 defines states for the MBMS client. Detailed descriptions are provided in the following subclauses .
Table 6.3.2-1: States of MBMS Client
|
States and Parameters |
Definition |
|---|---|
|
IDLE |
In this state the MBMS client does not have a registered MAA and it may not keep the service definition up to date. For more details see clause 6.3.2.3. |
|
NON_AVAILABLE |
In this state the MBMS client is not available and an MAA cannot register with the MBMS client. |
|
REGISTERED |
In this state the MBMS client has registered the MAA, it may keep the service definition up to date, and it may be providing file capture services to the MAA(s). In this state the MBMS client sends callback notifications to the MAA. For more details see clause 6.3.2.4. |
|
ACTIVE |
In this state the MBMS client provides all services to of the REGISTERED state and also provides the streaming service to the MAA. For more details see clause 6.3.2.5. |
|
STALLED |
In this state the MBMS client provides all services to of the REGISTERED state, but the streaming services is at least temporarily stalled. For more details see clause 6.3.2.6. |
6.3.2.2 MBMS Client Internal parameters
The MBMS client maintains internal parameters as defined in Table 6.3.2.2-1. Note that the parameters are conceptual and internal and only serve for the purpose to describe message generation on the API calls.
Table 6.3.2.2-1: Parameters of MBMS Client for Media Streaming Service
|
Internal Parameters |
Definition |
|||
|---|---|---|---|---|
|
_app[] |
The MBMS client maintains a parameter set per registered app |
|||
|
_appId |
A unique ID provided by the application and assigned to the app. |
|||
|
_serviceClass[] |
A list of service classes identifying the services the application has access to. |
|||
|
_registrationValidityDuration |
A period of time following the application de-registration over which the MBMS client continues to capture files for the application, see clause. |
|||
|
_service[] |
The MBMS client maintains a parameter list per service. In this context the list is assigned also to one app, but an implementation may share the internal parameter list assigned to a service across multiple apps. |
|||
|
_serviceID |
The service ID for a Streaming Application service over which the MBMS client collects files for the application. |
|||
|
_serviceClass |
The service class associated with the Streaming Application service assigned the Service ID. |
|||
|
_serviceLanguage |
The language of the service |
|||
|
_serviceName[] _name _lang |
The service name, possibly expressed in different languages. |
|||
|
_serviceBroadcastAvailability |
The service broadcast availability for the client. Three different types are defined: BROADCAST_AVAILABLE – UE is in broadcast coverage BROADCAST_UNAVAILABLE – UE is outside of broadcast coverage SERVICE_UNAVAILABLE – The service is unavailable for the UE |
|||
|
ServiceFormat[] |
A list of possible formats for the service as specified in clause 6.3.2.4. |
|||
|
_ServiceMimeType |
The MIME type which identifies the service format. |
|||
|
_Manifest |
The latest Manifest associated to the service for that particular MIME type. |
|||
|
IS[] |
The Initialization Segments for the Media Presentation i.e. Initialization Segment in the case of DASH, CMAF Header for CMAF, Media Initialization Section in the case of HLS. |
|||
|
_ManifestURI |
The URI which is provided to the application for initiating the Media Presentation. |
|||
|
_sessionSchedule[] _start _stop |
Documents the session schedule for this session. Only sessionSchedule records should be included for which the value of the _stop time is in the future. |
|||
6.3.2.3 MBMS Client Operation in IDLE state
In the IDLE state, the MBMS client may listen to the User Service Bundle Description and may collect information. However, no binding with the MAA is in place.
When the registerStreamingApp() as defined in subclause 6.3.3.2 is invoked, then:
1) The MBMS client checks the input parameters for consistency and sets the internal variables:
a) If the functions of the MBMS client is not accessible, the MBMS client throws a FAILED_LTE_EMBMS_SERVICE_UNAVAILABLE result code in the registerStreamingResponse() as defined in subclause 6.3.3.3 and abort the following steps and may at least temporarily move in NOT_AVAILABLE state.
b) If appId is an empty string then the MBMS client throws a MISSING_PARAMETER result code in the registerStreamingResponse() as defined in subclause 6.3.3.3 and abort the following steps and stays in IDLE mode. If not, the MBMS client sets the internal variable _appId to the value of the parameter.
c) The MBMS client adds each entry in the serviceClassList parameter to its _serviceClass[] record. Note that the serviceClassList parameter may contain an empty service class entry. If an empty service class is provided the MBMS client considers the MAA to be registered with a service class that is also empty and only allow the MAA to have access to Media Streaming Application Services that are not associated with a serviceClass (i.e., the USD for these services do not have a serviceClass defined).
d) On receiving a registerStreamingApp() following a deregisterStreamingApp(), the MBMS client updates the serviceClassList to its _serviceClass[] record in the same way described for the setStreamingServiceClassFilter() method.
e) If callBack is defined, the MBMS client uses the interfaces in the callback parameter of the registerStreamingApp() interface to send notification of event occurrences to the MAA.
2. generates a response registerStreamingResponse() as defined in subclause 6.3.3.3 and changes to REGISTERED state as defined in clause 6.3.2.4:
a) If the MBMS client functions cannot be activated for any reason, especially if the Streaming Delivery Application Service API did not find an MBMS client available on the UE on which the MAA is running, the FAILED_LTE_EMBMS_SERVICE_UNAVAILABLE registration response code is sent. The MBMS client may provide a message.
b) If the MAA did not provide a mandatory parameter the MBMS client functions cannot be activated, the MISSING_PARAMETER registration response code is sent.
c) If the MBMS client functions can be activated, then:
i) the RegResponseCode is set to REGISTER_SUCCESS registration response code;
ii) a message may be generated.
d) Sends the response with the above parameters.
3. If the MBMS client functions can be activated and the response is sent with a REGISTER_SUCCESS, then MBMS client is in REGISTERED state and uses the REGISTERED parameters to provide the list of matching streaming delivery services using the information in the User Service Description (USD). If the response is sent with a FAILED_LTE_EMBMS_SERVICE_UNAVAILABLE, then MBMS client is in NOT_AVAILABLE state. If the response is sent with a MISSING_PARAMETER, then MBMS client is in IDLE state.
If the MBMS client receives the getVersion() API call as defined in clause 6.3.3.13, it shall return version 1.0.
6.3.2.4 MBMS Client Operation in REGISTERED state
For each registered MAA and the assigned parameters according to Table 6.3.2.2-1, the MBMS client uses the information in the User Service Description as well as its internal state information for the MAA in _app[] in the service class list _serviceClass[] to collect and keep up-to-date all internal information for the services of interest for the app, i.e. those that are member of any service class for which the MAA has interest.
For each MBMS user service for which the USD as defined in TS 26.346 [5] is available in the MBMS client for the service classes registered by the MAA in _serviceClass[] and which is identified as a DASH-over-MBMS service according to the definition in TS 26.346 [5], clause 5.6, or identified as a generic application service according to the definition in TS 26.346 [5], clause 5.7 for HLS, one service record in the internal parameter _service[] is defined in the MBMS client and continuously updated whenever a new USD is available:
– For each userServiceDescription.name element, a (name, lang) pair is generated and added to the _serviceName[] list with _name set to the value of the USD element, and if present, the _lang set to the value of the associated @lang attribute. If no @lang attribute is present, the _lang parameter is set to an empty string.
– If the attribute userServiceDescription@serviceClass is present, the value of this attribute is assigned to _serviceClass. If not present, the _serviceClass is set to an empty string.
– The value of the attribute userServiceDescription@serviceId is assigned to _serviceId.
– If the attribute userServiceDescription@serviceLanguage is present, the value of this attribute is assigned to _serviceLanguage. If not present, the _serviceLanguage is set to an empty string.
If there is a r9:mediaPresentationDescription element or or a r12:appService element (with an attribute mimeType whose value contains "application/dash+xml" or “application/dash+xml profiles=’ urn:mpeg:dash:profile:cmaf:2019’”), a instance of service format is created:
– ServiceMimeType is equals to “application/dash+xml” and
– The Media Presentation Description fragment referenced by the r9:mediaPresentationDescription element or the Application Service Description fragment referenced by an a r12:appService (with an attribute mimeType whose value contains "application/dash+xml" or “application/dash+xml profiles=’ urn:mpeg:dash:profile:cmaf:2019’”) referencing an MPD and conforming to TS 26.247 [7] is extracted by the MBMS client. The contained MPD is stored in the Manifest parameter and the Initialization Segments are stored in the _IS[]. The MnifestURI parameter is generated at which location the MPD will be made available.
If there is a r12:appService element (with an attribute mimeType whose value contains "application/vnd.apple.mpegurl "), a instance of service format is created:
– ServiceMimeType is equals to “application/vnd.apple.mpegurl”,
– the Application Service Description fragment whose content is the Master Playlist referenced by the r12:appService (with an attribute mimeType whose value contains "application/vnd.apple.mpegurl ") is extracted by the MBMS client . The contained Master Playlist is stored in the _Manifest parameter and the Initialization Segments are stored in the _IS[]. The _ManifestURI parameter is generated at which location the Master Playlist will be made available.
– The _serviceBroadcastAvailability is continuously updated set it to
– BROADCAST_AVAILABLE, if broadcast is available (if the UE is in broadcast coverage of the service),
– BROADCAST_UNAVAILABLE, if broadcast is not available (if the UE is NOT in broadcast coverage of the service).
– If the userServiceDescription.schedule element is present then the MBMS client uses the information in the schedule description fragment to generate the internal _sessionSchedule[] list and keep up to date as a result of USD updates. The MBMS client shall only include _sessionSchedule[] records if the _stop value is in the future.
If updates are provided and added to the _service[] parameter, the MBMS client should send a streamingServiceListUpdate() callback as defined in clause 6.3.3.6.
When the getStreamingServices() method is received as defined in clause 6.3.3.4, the MBMS client sets the parameters as follows:
– If the _service[] list is empty, the list is empty.
– For each MBMS user service in the service[] list, one service record is generated as follows:
– The value of the attribute _serviceId is assigned to serviceId.
– The value of the attribute _serviceClass is assigned to serviceClass.
– The value of _serviceLanguage is assigned to serviceLanguage.
– For each record in the _serviceName[] one serviceNameList entry is generated and:
– the name is set to the value _name,
– the name is set to the value _name,
– The value of _serviceBroadcastAvailability is assigned to serviceBroadcastAvailability.
– The list of MIME types available. For each element of this list, _ManifestURI is assigned to ManifestURI
– If at least one _sessionSchedule[] record is present then:
– The activeDownloadPeriodStartTime is set to the value of earliest _start time of any entry in the _sessionSchedule[].
– The activeDownloadPeriodStopTime is set to the value of the _stop time of the entry selected earliest start time.
– If no _sessionSchedule[] record is present:
– The activeDownloadPeriodStartTime is set to 0.
– The activeDownloadPeriodStopTime is set to 0.
When the setStreamingServiceClassFilter() as defined in clause 6.3.3.5 is received, the MBMS client runs the following steps:
– It replaces the internal variable _serviceClass[] with the parameter values provided in serviceClassList.
– The MBMS client dis-associates the service classes previously associated with the MAA that are not included on this list.
– The MBMS client associates the service classes not previously associated with the MAA that are newly included on this list.
– The MBMS client issues a streamingServiceListUpdate() notification as defined in clause 6.3.3.6 to the MAA to notify of this effect.
When the startStreamingService() method as defined in clause 6.3.3.7 is received with a parameter serviceID, the MBMS client runs the following steps:
– The MBMS client checks for errors and if necessary, the streamingServiceError() notification as defined in clause 6.3.3.12 is initiated. Specifically, if the MBMS client does not find a matching serviceId in its internal _service[] record, it responds with error code STREAMING_INVALID_SERVICE. Otherwise it may use the error code STREAMING_UNKNOWN_ERROR. An error message may be provided in the errorMsg string.
– If the service with the serviceId parameter can be started:
– The MBMS client uses the Manifest file in the _ Manifest file parameter and the remaining associated metadata to offer a valid media presentation to the Media client by providing a Media server in the MBMS client. For different options to provide such a service, refer to clause 7.
– The URL to the Manifest file that is exposed to the MAA for media consumption is stored in the internal variableManifestURI. The Manifest file stored at this URI may be continuously updated, based on dynamic information received in the service announcement or inband Manifest file updates.
– The MBMS client sends a serviceStarted() notification as defined in clause 6.3.3.8 with the serviceId being passed along with the notification.
– The MBMS client moves to ACTIVE state as defined in clause 6.3.2.5.
Whenever there has been a change to the parameters reported to the MAA in response to a getStreamingServices() API, i.e. in the internal service class list _serviceClass[] to add a new service record to the list or a change in one of the following internal parameters in the service record in the _serviceLanguage, _serviceName[]_serviceBroadcastAvailability, or updates to the __Manifest URI, the MBMS client notifies the MAA with streamingServiceListUpdate() as defined in clause 6.3.3.6.
When the deregisterStreamingApp() is received, all internal parameters for the MAA are cleared and the client moves to IDLE state.
6.3.2.5 MBMS Client Operation in ACTIVE state
In the ACTIVE state, the MBMS client carries out all actions as in the REGISTERED state.
The MBMS client continuously downloads the media resources and makes them available as announced in the Manifest. For different options to provide such a service to the MAA and media client, refer to clause 7. The URL to the MPD that is exposed to the MAA for media consumption is stored in the internal variable _ManifestURI. The Manifest file stored at this URI may be continuously updated, based on dynamic information received in the service announcement or inband Manifest file updates.
When the MBMS client receives a stopStreamingService() request as defined in clause 6.3.3.9 that matches an active service.
– The MBMS client checks for errors and if necessary, the streamingServiceError() notification as defined in clause 6.3.3.12 is initiated. Specifically, if the MBMS client does not find a matching serviceId in its internal _service[] record, it responds with error code STREAMING_INVALID_SERVICE. Otherwise it may use the error code STREAMING_UNKNOWN_ERROR. An errorMsg may be provided in the errorMsg string.
– the MBMS client stops providing the media resources at its media server, i.e. at the location announced in the Manifest file referenced by the _ManifestURI.
– The MBMS client moves to REGISTERED state as defined in clause 6.3.2.4.
When the MBMS client receives a stopStreamingService() request as defined in clause 6.3.3.9 that matches an active service, the MBMS client terminates the download of the resources of this download delivery session and no longer makes it available at the indicated resources in the Manifest. The MBMS client transitions to REGISTERED state
When the MBMS the internal parameter _serviceBroadcastAvailability transitions to BROADCAST_UNAVAILABLE, and no alternative delivery method is defined, or if the service is no longer available for other reasons (e.g. frequency conflict), then the service is stalled. In this case the MBMS client:
– No longer makes available the resources in the announced locations by the _ManifestURI and the references therein.
– Sends a serviceStalled() notification as defined in clause 6.3.3.11, along with one of the following reasons:
– 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.
– Transitions to the STALLED state as defined in clause 6.3.2.6.
6.3.2.6 MBMS Client Operation in STALLED state
In the STALLED state, the MBMS client carries out all actions as in the REGISTERED state.
In this state the MBMS client continuously monitors if the service can be made available again.
Once the service gets available again, the MBMS client:
– The MBMS client downloads the media resources and makes them available as announced in the Manifest. For different options to provide such a service, refer to clause 7. The URL to the Manifest that is exposed to the MAA for media consumption is stored in the internal variable _ManifestURI. The Manifest stored at this URI may be continuously updated, based on dynamic information received in the service announcement or inband Manifest updates
– The MBMS client sends a serviceStarted() notification as defined in clause 6.3.3.8 with the serviceId being passed along with the notification.
– The MBMS client moves to ACTIVE state as defined in clause 6.3.2.5.