6.2.2 MBMS Client State Model
26.3473GPPApplication Programming Interface and URLMultimedia Broadcast/Multicast Service (MBMS)Release 17TS
6.2.2.1 Overview
Figure 6.2.2.1-1 provides an informative MBMS client state model in order to appropriately describe the messages on the service API. Five different states are defined as listed in Table 6.2.2.1-1.
Note that the state model is defined on the granularity per service and each MAA. This means that the MBMS client may at least conceptually have to maintain multiple state machines, namely one for each MAA/service combination.
The state model does not imply any implementation requirements for an MBMS client, but is used as a model to support the description of the APIs.
State changes may be the result of:
– Requests from the MAA
– Timer expiration in the MBMS client
– Information provided by the MBMS User Service (USD, schedule, FDT, file complete)
Figure 6.2.2.1-1: State Diagram
Table 6.2.2.1-1 describes the states for the MBMS client. Detailed descriptions are provided in the following subclauses.
Table 6.2.2.1-1: States and Parameters of MBMS Client
|
States and Parameters |
Definition |
|
IDLE |
In this state the MAA is not registered with the MBMS client and it may not keep the service parameters up-to-date. For more details see clause 6.2.2.3. |
|
NON_AVAILABLE |
In this state the MBMS client is not available and an MAA cannot register with the MBMS client. The MBMS client may not be aware of the state, it is only a state perceived by the MAA. |
|
REGISTERED |
In this state the MBMS client has registered the MAA, it may keep the service definition up to date, but it is not providing file capture services to the MAA(s). For more details see clause 6.2.2.4. |
|
CAPTURE_NOTIFY |
In this state the MBMS client provides file capture for one specific service to a registered MAA and notifies the MAA on any received file. For more details see clause 6.2.2.5. |
|
CAPTURE_BACKGROUND |
In this state the MBMS client provides file capture for one specific service to an MAA without notifying the MAA on any received file for some agreed time. For more details see clause 6.2.2.6. |
6.2.2.2 MBMS Client Internal parameters
The MBMS client maintains internal parameters as defined Table 6.2.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.2.2.2-1: Parameters of MBMS Client
|
States and Parameters |
Definition |
||
|---|---|---|---|
|
_Preconfigurations |
|||
|
_maxRegistrationValidityDuration |
MBMS client parameter that provides the maximum time after deregistration that a client still captures files on behalf of an MAA. |
||
|
_defaultAvailabilityDeadline |
the time a file that is kept in the MBMS client owned storage location. |
||
|
_app[] |
The MBMS client maintains a parameter set per registered app |
||
|
_appId |
A unique ID provided by the MAA and assigned to the app. |
||
|
_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. |
||
|
_locationPath |
The storage location where the MAA wants the MBMS client to store collected files. |
||
|
_backgroundCaptureTimer |
Timer on how long files are captured in background. |
||
|
_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 File Delivery Application service over which the MBMS client collects files for the MAA. |
||
|
_serviceClass |
The service class associated with the File Delivery 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. |
||
|
_fileCaptureRequest[] – _fileURI – _disableFileCopy – _captureOnce |
A sequence of requested file captures from the MAA with some parameters. The _fileURI identifies the file(s) as they will also be used on the FLUTE FDTs for the File Delivery Application Service Allowed values for the _fileURI include: – The empty string signals that the MAA is interested in receiving all new files and updates to previously received files. – A BaseURL, i.e., a complete path for subdirectory (a prefix) identifying a group of files under that directory. – An absoluteURL, i.e., a complete URL that identifies a single file resource. _disableFileCopy – when set to true, this signals that the MAA does not want the MBMS client to make the file available on the application space. _captureOnce – when set to true, signals that a file matching a requested via the _fileURI (i.e. a file matching a BaseURL in fileURI, or any file if the fileURI is empty) is to be captured only once. |
||
|
_fileURIStatus[] _URI _contentType _deliveryState _md5 _deliverySchedule[] _start _stop _appState _notified _fileLocation |
A sequence of _fileURIStatus[] that states the status of files the MAA may be interested or the service provides, possibly using scheduling information. The internal parameters store relevant information on the file such as content_type or MD5, if the information is available yet. The delivery state can be: – FD_RECEIVED – the file is received by the MBMS client and no more updates are expected according to the file schedule. – FD_SCHEDULED – scheduled, if a file schedule is delivered and a file is scheduled, but not yet received. – FD_IN_PROGRESS – the reception of the file is in progress The delivery schedule records the current upcoming delivery schedules. The application state may be transitioned to express that – the file was moved to the application, – failed if the move failed or – the location path points to an MBMS client controlled space. A _notified flag is provided to indicate if the MAA has been notified on the reception of the file. |
||
|
_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.2.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 MBMS client received the registerFdApp() call as defined in subclause 6.2.3.2, then:
1) The MBMS client checks the input parameters for consistency and sets the internal variables
a) If appId is an empty string then the MBMS client throws a MISSING_PARA
METER result code in the registerFdResponse() as defined in subclause 6.2.3.3 and aborts these steps. If not, the MBMS client sets the internal variable _appId to the value of the parameter.
b) 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 allows the MAA to have access to File Delivery Application Services that are not associated with a serviceClass (i.e., the USD for these services do not have a serviceClass defined).
c) On receiving a registerFdApp() following a deregisterFdApp(), the MBMS client updates the serviceClassList to its _serviceClass[] record in the same way described for the setFdServiceClassFilter() method.
d) If locationPath is not defined, the MBMS client provides means such that the MAA has access to the files the MBMS Client received on behalf of the MAA. If the locationPath is defined, the internal variable _locationPath is set to the value of the parameter.
e) If registrationValidityDuration is not defined, the value of the internal parameter _registrationValidityDuration is set to 0 (zero) . If the registrationValidityDuration is defined, the internal variable _ registrationValidityDuration is set to this parameter, or to _maxRegistrationValidityDuration if the value of registrationValidityDuration is larger than _maxRegistrationValidityDuration.
f) If callBack is defined, the MBMS client uses the interfaces in the callback parameter of the registerFdApp() interface to send notifications of event occurrences to the MAA.
2) generates a response registerFdResponse() as defined in subclause 6.2.3.3 and changes to REGISTERED state:
a) If the MBMS client functions cannot be activated for any reason, especially if the File 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 and may set acceptedFdRegistrationValidityDuration to any arbitrary value.
b) If the MAA did not provide a mandatory parameter, the MBMS client functions cannot be activated and the MISSING_PARAMETER registration response code is sent. The MBMS client may provide a message and may set acceptedFdRegistrationValidityDuration to any arbitrary value.
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,
iii the MBMS client sets the value of acceptedFdRegistrationValidityDuration to the _registrationValidityDuration.
The MBMS client 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 file delivery services using the information in the User Service Description (USD). If the response is sent with a FAILED_LTE_EMBMS_SERVICE_UNAVAILABLE, then the 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, it shall return version "1.0".
6.2.2.4 MBMS Client Operation in REGISTERED state
For each registered MAA and the assigned parameters according to Table 6.2.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[], one service record in the internal parameter _service[] is defined in the MBMS client and continuously updated whenever an updated 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 _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 _fileURI[] and _sessionSchedule[] list and keep up to date as a result of USD updates. The MBMS client should only include _fileUri[] list if there is a current or a future scheduled transmission of that file. The MBMS client shall only include _sessionSchedule[] records if the _stop value is in the future. The _deliveryState is set appropriately, e.g. to FD_SCHEDULED if the file is scheduled and FD_IN_PROGRESS, if the FDT is available, but the file reception is not yet completed.
If updates are provided and added to the _service[] parameter, the MBMS client should send a fdServiceListUpdate() callback as defined in clause 6.2.3.17.
When the getFdServices() call is received by the MBMS client as defined in clause 6.2.3.4, the MBMS client sets the parameters as follows:
– If the _service[] list is empty, then an empty list is returned.
– 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 language is set to the value _language.
– The value of _serviceBroadcastAvailability is assigned to serviceBroadcastAvailability.
– 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[]such that the corresponding _stop time is in the future.
– The activeDownloadPeriodStopTime is set to the value of the _stop time of the entry selected earliest start time.
– If no _sessionSchedule[] record is present, or the _start and _stop on existing entries in _sessionSchedule[] are in the past:
– The activeDownloadPeriodStartTime is set to 0.
– The activeDownloadPeriodStopTime is set to 0.
When the setFdStorageLocation() method as defined in sub-clause 6.2.3.5 is received by the MBMS client, the MBMS client runs the following steps:
– It updates the internal variable _locationPath to the parameter value of locationPath provided in the call.
Note: The MBMS client provides any new files for that MAA at the locationPath, but not ongoing file capture.
– If the storage location is empty the MBMS client selects a local directory on the device, which the MAA can access directly via file access interfaces or via HTTP GET methods (see sub-clauses 6.2.2.5 and 6.2.2.6).
When the setFdServiceClassFilter() is received, the MBMS client runs the following steps:
– It replaces the internal variable _serviceClass[] with the parameter values provided in serviceClassList.
Note that this does not necessarily change the ongoing MBMS client operation, e.g. capturing.
– The MBMS client issues a fdServiceListUpdate() notification as defined in clause 6.2.3.17 to the MAA to notify it of this effect.
When the startFdCapture() method is received, the MBMS client runs the following steps:
– The MBMS client checks for errors and if necessary, the fdServiceError() notification as defined in clause 6.2.3.18 is initiated.
– If the requested fileURI matches an existing outstanding startFdCapture() request as recorded on the _fileCaptureRequest[], the internal error code is set to FD_DUPLICATE_FILE_URI and the fdServiceError() notification as defined in clause 6.2.3.18 is initiated.
– If the requested fileURI is ambiguous in the following manner
– The fileURI is an absolute URL or a Base URL and there is an existing outstanding startFdCapture() with an empty fileURI, or
– fileURI is an absolute URL and there is an existing outstanding startFdCapture() with an Base URL in the fileURI that is base URL for the aboluteURL.
then, the internal error code is set to FD_AMBIGUOUS_FILE_URI and the fdServiceError() notification as defined in 6.2.3.18 is initiated.
– Otherwise, The fileURI is added to the internal list of the MBMS client _fileCaptureRequest[]. Any overlapping entry should be avoided.
– The MBMS client removes existing outstanding startFdCapture() requests from _fileCaptureRequest[] when the requested fileURI on a startFdCapture() is broader (i.e., superseding older requests) than these existing outstanding startFdCapture() requests; this request consolidation will not impact ongoing file downloads, specifically:
– When fileURI is empty on the new startFdCapture(), all existing outstanding startFdCapture() are removed.
– When fileURI is a Base URL, existing outstanding startFdCapture() requests with an absolute URL are removed if the new fileURI in the request is a base URL for the absolute URL on these existing outstanding startFdCapture().
– The _disableFileCopy is set to the value of disableFileCopy.
– The _captureOnce is set to the value of captureOnce.
– The MBMS client is in CAPTURE_NOTIFY mode.
Whenever there has been a change to the parameters reported to the MAA in response to a getFdServices() 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 _fileURIStatus[] adding new _URIs with _deliveryState set to FD_SCHEDULED, the MBMS client notifies MAA with fdServiceListUpdate() as defined in clause 6.2.3.17.
When the deregisterFdApp() is received, the client moves to IDLE state.
6.2.2.5 MBMS Client Operation in CAPTURE_NOTIFY State
In the CAPTURE_NOTIFY state, the MBMS client carries out all actions as in the REGISTERED state.
For one MBMS user service identified with one service record in the internal parameter _service[] with a specific _serviceID the MBMS client continuously updates the internal parameters for this service.
In addition, for each fileCaptureRequest[] record in the service record:
1) If the _fileUri is empty then the MBMS client receives all new and updated files delivered on this MBMS service with service ID serviceId. Updated files may be discovered by a change of the MD5 in the FDT.
2) If the _fileUri is a complete absolute URI, then the MBMS client receives only that file delivered on the MBMS service with service ID serviceId which has a matching URL as the fileURI parameter if the file is received for the first time or is a new version since the last reception.
3) If the _fileUri is a Base URI as defined in RFC 3986 [11], then the MBMS client receives all new and updated files delivered on the MBMS service with service ID serviceId which are delivered through the MBMS user service with a matching BaseURL of the one defined in the fileURI parameter.
Furthermore, the MBMS Client performs the actions as follows.
4) For each file announced via the file schedule element and matching any of the capture requests in _fileCaptureRequest[]:
– the MBMS client creates an entry in the _fileURIStatus[] adding the _URI and delivery schedules _deliverySchedule[] and sets the _deliveryState to FD_SCHEDULED.
– The MBMS Client should send a fdServiceListUpdate() callback as defined in clause 6.2.3.17.
5) For each file announced in the FDT and matching any of the capture requests in fileCaptureRequest[], the MBMS client:
– Updates or creates an entry adding the _URI.
– Sets the _deliveryState to FD_IN_PROGRESS.
– Does not download the same version of the file if the Content-MD5 in the File element of the FDT Instance is the same as a previously received version of the file.
– If a MIME type was defined via the FDT describing that file transmission, the _contentType parameter is set to the value of the Content-Type as in the File entry of the FDT. If the MIME type is not defined, the _contentType parameter is set to an empty string. The MD5 may be extracted from the FDT if present.
6) For each successfully received file announced in the FDT and matching any of the capture requests in fileCaptureRequest[]:
– The MBMS client updates the _deliveryState to FD_RECEIVED.
– If the _locationPath is defined and if the MBMS client is successful in copying/moving the collected file to the directory in _locationPath, the MBMS client sets the _appState to moved and the _fileLocation pointing to the file in the _locationPath.
– If the _locationPath is empty, (i.e. _appState indicates that MBMS client space needs to be used or that the MBMS client selected a location on the MAA space) or if the MBMS client is not successful in copying/moving the collected file to the directory defined in _locationPath (_appState is set to indicate the failure) then the _fileLocation is set to:
– A complete file name (including the directory path) on the UE local file system where the file can be accessed by the MAA. The file may be stored under an MBMS client defined directory that is accessible to the MAA.
– An HTTP URL where the MAA can retrieve the file using the HTTP GET method. This format may be used when the file is stored on a location that is not directly accessible to the MAA.
– The MBMS client announces it through fileAvailable() notification as defined in clause 6.2.3.8 to the MAA by setting the parameters as follows:
– The serviceId is set to the _serviceID.
– The fileUri is set to the value of _URI.
– The fileLocation is set to the value of the _fileLocation.
– The contentType is set to the _contentType.
– If the _appState is failed or internal, the MBMS client sets the value of the availabilityDeadline to the internal variable _defaultAvailabilityDeadline, otherwise sets the value to 0.
– The internal _notified flag is set to true.
– If the _captureOnce is set to true, the corresponding fileURI is excluded/removed from the _fileCaptureRequest[] and from the internal _fileURIStatus[] list.
7) For each non-successfully received file announced in the FDT and matching any of the capture requests in fileCaptureRequest[] (after file repair failed or when file repair is not defined for the service):
– The MBMS client sets the sets the _deliveryState to FD_SCHEDULED
– The MBMS client announces it through fileDownloadFailure() notification as defined in 6.2.3.10 to the MAA with the following parameter settings:
– The serviceId is set to the _serviceID.
– The fileUri is set to the value of _URI.
Whenever the in the internal _fileURIStatus[] was changed, the MBMS client should issue a fileDownloadStateUpdate()notification as defined in 6.2.3.15 with the following parameters:
– The serviceId is set to the _serviceID.
The MBMS client moves to REGISTERED state if the _fileCaptureRequest[] is empty.
When the getFdAvailableFileList() API call as defined in clause 6.2.3.12 is received, the MBMS client runs the following steps:
– For the service with internal _serviceId set to the input parameter serviceID, for each successfully received file (i.e. internal _deliveryState being received) that matches a _fileCaptureRequest[] and is included in the _fileURIStatus[] record with an internal status _notified set to false, the following parameters are assigned
– The fileUri is set to the value of _URI.
– The fileLocation is set to the value of the _fileLocation.
– The contentType is set to the _contentType.
– If the _appState is failed or internal, the MBMS client sets the value of the availabilityDeadline to the internal variable _defaultAvailabilityDeadline, otherwise sets the value to 0.
– The internal status _notified set to true.
When the MBMS client receives a stopFdCapture() request as defined in clause 6.2.3.13 that matches an entry in the internal parameter _fileCaptureRequest[]:
– The MBMS client removes this entry from the _fileCaptureRequest[] record in order to stop any on-going and future file receptions that match that particular record.
– The MBMS client should keep records of outstanding startFdCapture() requests that are unambiguous such that a stopFdCapture() can unambiguously remove an entry in the internal parameter _fileCaptureRequest[] from an earlier startFdCapture() request.
– The MBMS client may also send a failure indication via the fdServiceError() with the FD_AMBIGUOUS_FILE_URI error code when the requested fileURI on a stopFdCapture() is more specific than an existing outstanding startFdCapture() requests that is broader:
– When fileURI is an absolute URL or a Base URL and there exists an entry in the internal parameter _fileCaptureRequest[] with an empty fileURI.
– When fileURI is an absolute URL and there exists an entry in the internal parameter _fileCaptureRequest[] with an empty fileURI. With an Base URL in the _fileURI that is base URL for the aboluteURL.
– The MBMS client may send a failure indication via the fdServiceError() with the FD_STOP_FILE_URI_NOT_FOUND error code to any stopFdCapture() request that does not match an entry in the internal parameter _fileCaptureRequest[].
When the getFdActiveServices() API call as defined in clause 6.2.3.14 is received, the MBMS client runs the following steps:
– For the service with internal _serviceId set to the input parameter serviceID, for each entry in the internal parameter _fileCaptureRequest[] one record in the response is set with the fileUri set to the value of _URI.
When the MBMS Client receives getFdDownloadStateList()API call as defined in clause 6.2.3.16, it runs the following steps:
– For the service with internal _serviceId set to the input parameter serviceID, for each file that matches a _fileCaptureRequest[] and is included in the _fileURIStatus[] record, the following parameters are assigned:
– The fileUri is set to the value of _URI.
– The state is set to the internal value _deliveryState.
If the deregisterFdApp() API call invoked the MBMS client:
– And if the _fileCaptureRequest[] record contains no more entries or the _registrationValidityDuration is set to zero, the MBMS client moves to IDLE state.
– If the _fileCaptureRequest[] record contains one or more entries, the MBMS client moves to CAPTURE_BACKGROUND state.
6.2.2.6 MBMS Client Operation in CAPTURE_BACKGROUND State
When the MBMS client enters this state, the internal _backgroundCaptureTimer is set to _registrationValidityDuration and started. The MBMS client remains in this state until this timer expires, or the MAA invokes a new registerFdApp() API call.
Once the time for the registration validation has expired, the MBMS client clears all context for the MAA and returns to IDLE state for the MAA. Until this is the case, the MBMS client performs the following actions.
The MBMS client carries out all actions as in the CAPTURE_NOTIFY state, except for those associated with sending notifications (invoking call-back functions) to the app.
While an MAA is deregistered and files are received for that MAA, if multiple versions of the same file (i.e., the same fileURI but different Content-MD5 in the FDT for a File Delivery Application Service) are received, only the last file version received is kept by the MBMS client and made available to the MAA after the new registration.
If the MAA is not currently registered at the time and the download of files for that MAA fails, the MBMS client is not able to inform MAA.
For one MBMS user service identified with one service record in the internal parameter _service[] with a specific _serviceID the MBMS client continuously updates the internal parameters for this service. Whenever the delivery state is changed in the state, the internal _notified flag is set to false.