6.4.2 MBMS Client State Model for MBMS packet delivery

26.3473GPPApplication Programming Interface and URLMultimedia Broadcast/Multicast Service (MBMS)Release 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.4.2.1 Overview

Figure 6.4.2.1-1 provides an informative client state model in order to appropriately describe the messages on the MBMS Packet Delivery service API. Four different states are defined as listed in Table 6.4.2.1-1. State changes may happen based on:

– Calls from the MAA or the packet streaming client

– Information provided by the MBMS User Service (USD, schedule, FDT, file complete)

– Changes in the reception conditions

Figure 6.4.2.1-1: State Diagram

Table 6.4.2.1-1 defines states for the MBMS client. Detailed descriptions are provided in the following subclauses.

Table 6.4.2.1-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.4.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.4.2.4.
ACTIVE	In this state the MBMS client provides all services to of the REGISTERED state and also provides the PACKET service to the MAA. For more details see clause 6.4.2.5.
STALLED	In this state the MBMS client provides all services to of the REGISTERED state, but the packet services is at least temporarily stalled. For more details see clause 6.4.2.6.

6.4.2.2 MBMS Client Internal parameters

The MBMS client maintains internal parameters as defined in Table 6.4.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.4.2.2-1: Parameters of MBMS Client for MBMS Packet Delivery Service

Internal Parameters			Definition
_app[]			The MBMS client maintains a parameter set per registered app
	_appId		A unique ID provided by the MAA and assigned to the app.
	serviceType		specifies the service type the MAA has requested.
	_serviceClass[]		A list of service classes identifying the services the MAA has access to.
	_registrationValidityDuration		A period of time following the MAA de-registration over which the MBMS client continues to capture files for the MAA, 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 packet Application service over which the MBMS client collects files for the MAA.
		_serviceClass	The service class associated with the packet 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
		_SDP _interfaceName _sdpURI	The latest SDP associated to the service The network interface name from which the started MBMS Packet Delivery service can be received. The URI which is provided to the MAA for initiating the Packet Session.
		_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.4.2.3 MBMS Client Operation in 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 registerPacketApp()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 registerPacketResponse() as defined in subclause 6.4.3.3 and abort the following steps and may at least temporarily move in NOT_AVAILABLE state.

b) If the MBMS client supports serviceType provided in the service _serviceType record. If the MBMS client does not support the service, it will respond with the appropriate error code, see below.

c) If the service type provided in the serviceType field, in the request is recognized by the MBMS client, an empty string then the MBMS client throws a MISSING_PARAMETER result code in the registerPacketResponse() as defined in subclause 6.4.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.

d) c) If appId is an empty string then the MBMS client throws a MISSING_PARAMETER result code in the registerPacketResponse() as defined in subclause 6.4.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.

e) d) 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 MBMS Packet Delivery Application Services that are not associated with a serviceClass (i.e., the USD for these services do not have a serviceClass defined).

f) e) On receiving a registerPacketApp() following a deregisterPacketApp(), the MBMS client updates the serviceClassList to its _serviceClass[] record in the same way described for the setPacketServiceClassFilter() method.

g) f) If callBack is defined, the MBMS client uses the interfaces in the callback parameter of the registerPacketApp()interface to send notification of event occurrences to the Application.

2) generates a response registerPacketResponse() as defined in subclause 6.4.3.3 and changes to REGISTERED state as defined in clause 6.4.2.4:

a) If the MBMS client functions cannot be activated for any reason, especially if the Packet 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 an error 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 does not support the service type, the NON_SUPPORTED_SERVICE_TYPE registration response code is sent.

d) 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.

e) 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 Packet 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 or NON_SUPPORTED_SERVICE_TYPE then MBMS client is in IDLE state.

If the MBMS client receives the getVersion() API call as defined in clause 6.4.3.13, it shall return version 1.0.

6.4.2.4 MBMS Client Operation in REGISTERED state

For each registered MAA and the assigned parameters according to Table 6.4.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[] using the service type serviceType and 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 type and service classes registered by the MAA in serviceType and _serviceClass[] and which is identified as a MBMS Packet Delivery service according to the definition in TS 26.346 [5], clause 8, 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.

– The SDP metadata fragment referenced by either the r9:sessionDescription element referencing an SDP and conforming to TS 26.346 [5] is extracted by the MBMS client. The contained SDP is stored in the _SDP parameter. The _sdpURI parameter is generated at which location the SDP will be made available. The name of the network interface from which the Packet data is available is stored in the _interfaceName parameter

– The _serviceBroadcastAvailability is continuously updated set it to BROADCAST_AVAILABLE, if broadcast is available (if the UE is in broadcast coverage of the service), if not, it is set to BROADCAST_UNAVAILABLE (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 packetServiceListUpdate() callback as defined in clause 6.4.3.6.

When the getPacketServices() method is received as defined in clause 6.4.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 lang is set to the value _lang.

– The value of _serviceBroadcastAvailability is assigned to serviceBroadcastAvailability.

– The _sdpURI is assigned to spdURI.

– If at least one _sessionSchedule[] record is present then

– The activeServicePeriodStartTime is set to the value of earliest _start time of any entry in the _sessionSchedule[].

– The activeServicePeriodStopTime is set to the value of the _stop time of the entry selected earliest start time.

– If no _sessionSchedule[] record is present:

– The activeServicePeriodStartTime is set to 0.

– The activeServicePeriodStopTime is set to 0.

When the setPacketServiceClassFilter() as defined in clause 6.4.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 rtpServiceListUpdate() notification as defined in clause 6.4.3.6 to the MAA to notify of this effect.

When the startPacketService() method as defined in clause 6.4.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 packetServiceError() notification as defined in clause 6.4.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 PACKET_INVALID_SERVICE. Otherwise it may use the error code PACKET_UNKNOWN_ERROR. An errorMsg may be provided in the errorMsg string.

– If the service with the serviceId parameter can be started:

– The MBMS client uses the SDP in the _SDP parameter and the remaining associated metadata to offer a valid session to the packet client by providing a server in the MBMS client. Clause 7 provides different provides service specific interfaces.

– The URL to the SDP that is exposed to the MAA for Packet consumption is stored in the internal variable _sdpURI. The SDP stored at this URI shall not be changed for a session.

– The MBMS client sends a serviceStarted() notification as defined in clause 6.4.3.8 with the serviceId being passed along with the notification.

– The MBMS client moves to ACTIVE state as defined in clause 6.4.2.5.

Whenever there has been a change to the parameters reported to the MAA in response to a getPacketServices() 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 _sdpURI the MBMS client notifies MAA with packetServiceListUpdate() as defined in clause 6.4.3.6.

When the deregisterPacketApp() is received, all internal parameters for the MAA are cleared and the client moves to IDLE state.

6.4.2.5 MBMS Client Operation in ACTIVE state

The MBMS client carries out all actions as in the REGISTERED state.

The MBMS client continuously receives the packet data and makes it available as announced in the SDP. For different options depending on the service type, refer to clause 7. The URL to the SDP that is exposed to the MAA for Packet consumption is stored in the internal variable _sdpURI.

When the MBMS client receives a stopPacketService() request as defined in clause 6.4.3.9 that matches an active service, then

– the MBMS client checks for errors and if necessary, the packetServiceError() notification as defined in clause 6.4.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 PACKET_INVALID_SERVICE. Otherwise it may use the error code PACKET_UNKNOWN_ERROR. An errorMsg may be provided in the errorMsg string.

– the MBMS client stops providing the session at its internal server, i.e. at the location announced in the SDP referenced by the _sdpURI.

– The MBMS client moves to REGISTERED state as defined in clause 6.4.2.4.

When the MBMS client receives a stopPacketService() request as defined in clause 6.4.3.9 that matches an active service, the MBMS client terminates the reception of the data of this delivery session and no longer makes it available at the indicated resources in the SDP. 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 _sdpURI and the references therein,

– sends a serviceStalled() notification as defined in clause 6.4.3.11, along with one of the following reasons:

– RADIO_CONFLICT – indicates a frequency conflict, namely the service requested to be started via a startPacketService() 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 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.4.2.6.

6.4.2.6 MBMS Client Operation in 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 receives the packet streams and makes them available as announced in the SDP. The URL to the SDP that is exposed to the MAA for Packet consumption is stored in the internal variable _sdpURI.

– The MBMS client sends a serviceStarted() notification as defined in clause 6.4.3.8 with the serviceId being passed along with the notification.

– The MBMS client moves to ACTIVE state as defined in clause 6.4.2.5.