9 Associated delivery procedures
26.3463GPPMultimedia Broadcast/Multicast Service (MBMS)Protocols and codecsRelease 17TS
9.1 Introduction
Associated delivery procedures describe general procedures, which start before, during or after the MBMS data transmission phase. They provide auxiliary features to MBMS user services in addition, and in association with, MBMS delivery methods and their sessions. Those procedures that shall only be permitted after the MBMS Data transmission phase may also be described as post-delivery procedures.
To enable future backwards compatibility, clause 9 specifies generic and extensible techniques for a potentially wide range of associated delivery procedures.
Clauses 9.3 and 9.4 specify the associated delivery procedures that are initiated only after an MBMS data transmission phase.
The present document describes the following associated delivery procedures:
– File repair, for post-delivery repair of files initially delivered as part of an MBMS download session.
– Content reception reporting of download files and/or media streams of an MBMS User Service delivered to an MBMS UE, which may include the reporting of DASH QoE metrics for a DASH-over-MBMS service.
– Consumption reporting of MBMS User Service.
These procedures are enabled by establishing a point-to-point connection; and using the MBMS session parameters, received during User Service Discovery/Announcement, to communicate the context (e.g. file and session in question) to the network and the MBMS sender infrastructure. To avoid network congestion in the uplink and downlink directions, and also to protect servers against overload situations, the associated delivery procedures from different MBMS UEs shall be distributed over time and resources (network elements).
One or more serviceURI elements in the Associated Delivery Procedure Description are used to specify the network server(s) associated with one or more of the following Associated Delivery Procedure functionality: symbol-based file repair, reception reporting, and consumption reporting. In MBMS download delivery, the use of the "Alternate-Content-Location-1" or "Alternate-Content-Location-2" elements alone, or in combination with the "Base-URL-1" or "Base-URL-2" elements in the FDT specify standard HTTP/1.1 servers in support of byte-range-based file repair. The network can selectively enable or disable the use of confidentiality protection of Reception Reporting, Consumption Reporting, and/or File Repair, based on indicating in the server identities the use of the ‘HTTPS’ or ‘HTTP’ scheme as specified in TS 33.246 [10] clause 6.7.
NOTE: The use of the HTTPS scheme for Reception Reporting, Consumption Reporting, or File Repair Associated Delivery Procedures is restricted to servers for which a trusted root certificate is present in the list described in TS 33.246 [10], clause 6.7.3.
An instance of an "associated procedure description" is an XML file that describes the configuration parameters of one or more associated delivery procedures.
MBMS Download receivers shall support the file repair procedure as defined in sub-clause 9.3.
MBMS Download receivers shall support the reception reporting procedure as defined in sub-clause 9.4.
MBMS Download receivers shall support the consumption reporting procedures as defined in sub-clause 9.4A.
MBMS Streaming receivers shall support reception reporting procedures (StaR and StaR-all report types) as defined in sub-clause 9.4.
MBMS Transparent Delivery receivers are not expected to support any associated delivery procedures.
9.2 Associated Procedure Description
An associated procedure description instance (configuration file) for the associated delivery procedures may be delivered to the MBMS clients:
– during a User Service Discovery / Announcement prior to the MBMS download session along with the session description (out-of-band of that session); or
– in-band within a MBMS download session.
The most recently delivered configuration file (i.e. the one with the highest version number – as given from the envelope, see sub-clause 11.1.3) shall take priority, such that configuration parameters received prior to, and out-of-band of, the download session they apply to are regarded as "initial defaults", and configuration parameters received during, and in-band with the download session, overwrite the earlier received parameters. Thus, a method to update parameters dynamically on a short time-scale is provided but, as would be desirable where dynamics are minimal, is not mandatory.
During the User Service Discovery / Announcement Procedure, the associated procedure description instance is clearly identified using a URI, to enable UE cross-referencing of in and out-of-band configuration files.
The MIME application type "application/mbms-associated-procedure-description+xml" as defined in clause C.7 identifies associated delivery procedure description instances (configuration files).
In XML, each associated delivery procedure entry shall be configured using an "associatedProcedureDescription" element. All configuration parameters of one associated delivery procedure are contained as attributes of an "associatedProcedureDescription" element. The elements (e.g. "postFileRepair" and "postReceptionReport") of an "associatedProcedureDescription" element identify which associated procedure(s) to configure. The associated delivery procedure description is specified formally as an XML schema in sub-clause 9.5.1.
9.3 File Repair Procedure
9.3.1 Introduction
The purpose of the File Repair Procedure is to repair lost or corrupted file fragments from the MBMS download data transmission. When in multicast/broadcast environment, scalability becomes an important issue as the number of MBMS clients grows. Three problems must generally be avoided:
– Feedback implosion due to a large number of MBMS clients requesting simultaneous file repairs. This would congest the uplink network channel.
– Downlink network channel congestion to transport the repair data, as a consequence of the simultaneous clients requests.
– File repair server overload, caused again by the incoming and outgoing traffic due to the clients’ requests arriving at the server, and the server responses to serve these repair requests.
The three problems are interrelated and must be addressed at the same time, in order to guarantee a scalable and efficient solution for MBMS file repair.
The principle to protect network resources is to spread the file repair request load in time and across multiple servers.
The MBMS client:
1. Identifies the end of transmission of files or sessions.
2. Identifies the missing data from an MBMS download.
3. Calculates a random back-off time and selects a file repair server randomly out of a list.
4. Sends a repair request message to the selected file repair server at the calculated time.
When a MBMS download session of repair data is configured in the associated delivery descriptions, a MBMS client should wait for repair data in the defined MBMS download session on its MBMS bearer – except where the UE is prevented from doing so due to limited simultaneous context activation capability.
Then the file repair server:
1. Responds with a repair response message either containing the requested data, redirecting the client to an MBMS download session, redirecting the client to another server, or alternatively, describing an error case.
The BM-SC may also send the repair data on a MBMS bearer (possibly the same MBMS bearer as the original download) as a function of the repair process.
The random distribution, in time, of repair request messages enhances system scalability to the total number of such messages the system can handle without failure.
9.3.2 Starting Time of the Associated Delivery Procedure for MBMS Download Delivery
FLUTE File Delivery Table (FDT) Instances include an "expires" attribute, which defines the expiration time of the FDT instance. The sender must use an expiry time relative to the current time at the BM-SC. According to clause 7.2.9, the UE shall not use a received FDT Instance to interpret packets received beyond the expiration time of the FDT Instance".
The starting time of Associated Delivery Procedure for the MBMS download is the expiration time of the FDT instance at the latest.
The starting time of the postFileRepair timer (see sub-clause 9.4.4) corresponds to the starting time of the Associated Delivery Procedure. The postFileRepair timer value corresponds to the back-off time determined from sub-clause 9.3.4, using the file repair associated parameters in the ADP.
The starting time for the postReceptionReport timer (see clause 9.4.4) for RAck reports corresponds to the time at which the UE determines that there has been a complete file reception for MBMS download, as specified in sub-clause 9.4.1.
The starting time for the postReceptionReport timer (see sub-clause 9.4.4) for StaR/StaR-only/StaR-all reports corresponds to the expiration of a periodic ‘report interval’ timer whose value is defined by the r14:reportInterval attribute of the postReceptionReport element if present, or, to the time at which the UE has identified a complete MBMS delivery session reception, as specified in sub-clause 9.4.2.
The postReceptionReport timer value for RAck and StaR/StaR-only/StaR-all reports is set to the same value and corresponds to the back-off time, as determined from sub-clause 9.3.4, using the reception reporting associated parameters in the ADP.
The MBMS UE may also choose to start the Associated Delivery Procedure when any of the following occurs:
– The MBMS UE has received an end-of-object (B-flag) for an object;
– An end-of-session (A-flag) is received before the FDT instance expires. Note, the end-of session (A-flag) indicates, that neither more objects nor FDT instances will be transmitted by the BM-SC;
– The end of the file transmission time (end attribute in the fileSchedule element) per the Schedule Description fragment is reached even when the FDT Instance is not received;
– The end of the session occurrence transmission time (given by the stop element in the sessionSchedule element adjusted to the specific session occurrence, to account for any session reoccurrences) per the Schedule Description fragment is reached even when the FDT Instance is not received.
If the MBMS UE is not capable of receiving an MBMS transmission while using an interactive bearer, the MBMS UE shall ignore the end-of-object flags (B-flag).
When a particular file (URI) is present in several FDT Instances with different TOI values, then the FDT Instance with the highest FDT Instance ID defines the TOI for the most recent instance of the file and determines the end of transmission time for that file. A UE shall only determine transmission completeness for a file for the most recent instance of the file – and shall not use FDT Instance expiry time to determine transmission completeness for any other (TOI) instances of a file (fileURI).
NOTE 1: The intention of this sub-clause is to just start the Associated Delivery Procedure back-off timer for the more recent instance version of a file with respect to the FLUTE transmission session.
When a particular file (URI) is present in more than one FDT Instance with the same TOI value, then the end of transmission time is defined by the expiration time of the latest FDT Instance to expire.
If an FDT Instance is received describing the file after this time (giving an FDT Instance expiry time in the future and a different TOI value) the UE shall determine that the transmission of the file is incomplete – i.e. that more packets may arrive within the MBMS download session for that file, ‘forgetting’ its previous file transmission complete determination.
NOTE 2: This effectively resets and stops any running timers already initiated for an associated delivery procedure for that file.
If the MBMS UE receives an end-of-object packet (with FLUTE header B flag set true) the MBMS UE shall determine that the transmission of that object is complete, and shall interpret that as file transmission complete if no, more recent, TOIs are described for the same file (URI) in any received and unexpired FDT Instance(s).
If the MBMS UE determines that the download session is complete (as specified in sub-clause 9.4.2) then it shall interpret this also that all the transmissions of all files (and TOIs) described by all FDT Instances, received from that session, are complete.
9.3.3 Identification of Missing Data from an MBMS Download
The session description and the MBMS download delivery protocol, FLUTE, provide the client with sufficient information to determine the source block and encoding symbol structure of each file. From this a client is able to determine which source symbols should have been transmitted but have not been received. The client is also able to determine the number of symbols it has received for each source block of each file, and thus the number of further symbols required to decode the block.
Thus, an MBMS client is able to identify any source symbols lost in transmission, and the number (and ESI values where appropriate) of required source and/or repair symbols that would complete the reconstruction of a source block (of a file).
When the MBMS FEC scheme is used, the MBMS client shall consider already received repair symbols when making the determination of the further symbols required. In this case, the client should either:
– identify a minimal set of specific symbols that, combined with the already received symbols, allows the MBMS FEC decoder to recover the file, or
– identify a number, r, of symbols such that reception of r previously unreceived symbols will allow the MBMS FEC decoder to recover the file.
9.3.4 Back-off Timing the Procedure Initiation Messaging for Scalability
This clause describes a back-off mode for MBMS download to provide information on when a receiver, that did not correctly receive some data from the MBMS sender during a transmission session, can start a request for a repair session. In the following it is specified how the information and method a MBMS client uses to calculate a time (back‑off time), instance of the back-off mode, to send a file repair message to the MBMS server.
The back-off mode is represented by a back-off unit, a back-off value, and a back-off window. The two latter parameters describe the back-off time used by the MBMS client.
The back-off unit (in the time dimension) defaults to seconds and it is not signalled.
The back-off time shall be given by an offset time (describing the back-off value) and a random time period (describing the back-off window) as described in the following clauses.
An MBMS client shall generate random or pseudo-random time dispersion of repair requests to be sent from the receiver (MBMS client) to the sender (MBMS server). In this way, the repair request is delayed by a pre-determined (random) amount of time.
The back-off timing of repair request messages (i.e. delaying the sending of repair requests at the receiver) enhances system scalability to the total number of such messages the system can handle without failure.
9.3.4.1 Offset time
The OffsetTime refers to the repair request suppression time to wait before requesting repair, or in other words, it is the time that a MBMS client shall wait after the end of the MBMS data transmission to start the file repair procedure. An associated procedure description instance shall specify the wait time (expressed in back-off unit) using the "offset-time" attribute.
9.3.4.2 Random Time Period
The Random Time Period refers to the time window length over which a MBMS client shall calculate a random time for the initiation of the file repair procedure. The method provides for statistically uniform distribution over a relevant period of time. An associated procedure description instance shall specify the wait time (expressed in back-off unit) using the "random-time-period" attribute.
The MBMS client shall calculate a uniformly distributed Random Time out of the interval between 0 and Random Time Period.
9.3.4.3 Back-off Time
The sending of the file repair request message shall start at Back-off Time = offset-time + Random Time, and this calculated time shall be a relative time after the MBMS data transmission. The MBMS client shall not start sending the repair request message before this calculated time has elapsed after the initial transmission ends.
9.3.4.4 Reset of the Back-off Timer
The reception of an updated (higher version number) associatedDeliveryProcedureDescription and/or an updated sessionDescription shall overwrite the timer parameters used in the back-off algorithm. Except in the case that the offset-time, random-time-period and session end time parameters are identical to the earlier version; the back-off time shall be recalculated. For currently running timers this requires a reset.
9.3.5 File Repair Server Selection
9.3.5.1 List of Server URIs
A list of symbol-based file repair service URIs is provided as elements of the Associated Delivery procedure fragment’s postFileRepair element. A list of byte-range based repair servers may be additionally provided as elements of the FDT. Service URIs host identity may also be given as IP addresses, which may be used to avoid a requirement for DNS messaging. The file repair service URIs of a single associated delivery procedure description shall be of the same type, e.g. all IP addresses of the same version, or all domain names. The number of symbol-based file repair service URIs is determined by the number of "serviceURI" elements, each of which shall be a child-element of the "procedure" element. The "serviceURI" element provides the references to the file repair server’s resource via the "xs:anyURI" value. At least one "serviceURI" element shall be present. The number of byte-range based file repair service URIs is determined by the number of "Alternate-Content-Location-1" and "Alternate-Content-Location-2" elements in the FDT. The "Alternate-Content-Location-1" and "Alternate-Content-Location-2" elements provide the references to the file repair server’s resource via the "xs:anyURI" value. At least one "Alternate-Content-Location-1" element shall be present in the FDT if byte-range based file repair is to be supported by the network.
When present, the "Base-URL-1" and "Base-URL-2" elements provide base URLs against which to resolve a relative reference included in any "Alternate-Content-Location-1" or "Alternate-Content-Location-2" element, respectively.
When present, the "Availability-Time" attribute provides a method to inform the UE of an absolute time according to the UTC time standard until which the UE can expect that, if reachable and functioning, the file repair server will return the requested repair data.
9.3.5.2 Selection from the Server URI List
There may be one or more file repair URIs of one or more types present in the Associated Delivery procedure fragment and the FDT. Within a list, the UE randomly selects one of the service URIs from the list, with uniform distribution.
The MBMS client shall exhaust (according to section 9.3.7.1) the list of highest priority URIs before moving to the list of next highest priority, etc.
The priority of file repair URI lists is:
– byte-range based repair servers included as "Alternate-Content-Location-1"
– byte-range based repair servers included as "Alternate-Content-Location-2"
– symbol-based repair servers
9.3.6 File Repair Request Messages
9.3.6.0 General
Once missing file data is identified, the MBMS client sends one or more messages to a file repair server requesting transmission of data that allows recovery of missing file data. All file repair requests and repair responses for a particular MBMS transmission shall take place in a single TCP session using the HTTP protocol (RFC 2616 [18]). The repair request is routed to the file repair server IP address resolved from the selected file repair server URI.
The timing of the opening of the TCP connection to the server, and the first repair request, of a particular MBMS client is randomized over a time window as described in sub-clause 9.3.2. If there is more than one repair request to be made these are sent immediately after the first.
When a MBMS UE identifies symbols or the byte range of symbols in repair requests these symbols shall be source symbols, and should include all the missing source symbols of the relevant source block. Note, these represent information for the file repair server and the BM-SC may use these source symbols and/or redundant symbols in providing the necessary repair data.
After the MBMS download session, the receiver identifies a set of encoding symbols that allow recovery of the missing file data and requests for their transmission in a file repair session.
There are two formats for the MBMS UE to request repair data: the Symbol-Based File Repair Request Message and the Byte-Range-Based Request Messsage.
9.3.6.1 Symbol-Based File Repair Request Message Format
In this message format, the MBMS UE requests specific encoding symbols and uniquely identifies these by the combination (URI, SBN, ESI). This message format shall be used if the MBMS UE is requesting symbols from a file repair server that only supports symbol-based file repair request messages, i.e., the server is listed in a "serviceURI" element of the Associated Delivery procedure. The file repair request shall either include the URI of the file for which it is requesting the repair data or an identifier of a set of files. The URI uniquely identifies the file (resource) and is found from the FLUTE FDT Instances. Additionally, the repair request for single files shall contain the MD5 hash value of the transport object, if present in the FDT instance declaring the file from which data is being requested. The MD5 hash value is used to identify a specific transport object and version of the file.
For completely missed files, a Repair Request may give only the URI of the file and optionally the MD5 hash value of the transport object of the file. If the MD5 hash value is not present, the server shall respond with the latest version of the file.
A set of files may be fetched using the File Repair server. A client may request all files from a specific FDT instance or a specific logical group of a particular MBMS User Services.
The client makes a file repair request using the HTTP (RFC 2616 [18]) request method GET. Further arguments are encoded into the URI query part (RFC 3986 [19]) as defined below and included in the HTTP GET request. If a number of previously unreceived symbols are requested for a specific Source Block, then the SBN is provided along with the ESI of the symbol, which is subsequent in the symbol sequence to the latest received symbol for that source block and the number of symbols requested. If a number of previously unreceived source blocks are requested for a specific file, the URI should be provided along with an SBN range starting from the first missing source block and ending with the SBN of the last missing source block of the contiguous set of source block. Examples for requesting contiguous and non-contiguous ranges of symbols and source blocks or even entire files or group of files are given below.
For example, assume that in a MBMS download session a 3gp file with URI = www.example.com/news/latest.3gp was delivered to an MBMS client. After the MBMS download session, the MBMS client recognized that it did not receive two packets with SBN = 5, ESI = 12 and SBN=20, ESI = 27. If the selected repair service URI (from the associated delivery procedure meta data fragment) is http://mbmsrepair1.example.com/path/repair_script, only supports symbol-based file repair requests, and the MD5 value of that file is "ODZiYTU1OTFkZGY2NWY5ODh==", then the HTTP GET request is as follows:
GET /path/repair_script?fileURI=www.example.com/news/latest.3gp&Content-MD5= ODZiYTU1OTFkZGY2NWY5ODh== &SBN=5;ESI=12&SBN=20;ESI=27 HTTP/1.1
Host: mbmsrepair1.example.com
A file repair session shall be used to recover the missing file data from a single MBMS download session only. If more than one file were downloaded in a particular MBMS download session, and, if the MBMS client needs repair data for more than one file received in that session, the MBMS client shall send separate HTTP GET requests for each file.
An HTTP client implementation might limit the length of the URL to a finite value, for example 256 bytes. In the case that the length of the URL-encoded (SBN, ESI) data exceeds this limit, the MBMS client shall distribute the URL‑encoded data into multiple HTTP GET requests.
In any case, all the HTTP GETs of a single file repair session shall be performed within a single TCP session and they shall be performed immediately one after the other.
In the following, we give the details of the syntax used for the above request method in ABNF.
In this case an HTTP GET with a normal query shall be used to request the missing data, according to HTTP1.1 [RFC2616 [18]]
– repair_request_http_URL = repair_service_URI "?" query
– repair_service_URI = <selected serviceURI from the Associated Delivery Procedure Description>
Where, for MBMS File Repair Request:
– query = std_query / alt_query
– std_query = file_uri ["&" content_md5] *( "&" sbn_info)
– file_uri = "fileURI=" URI-reference; URI-reference is as defined in [19].
– content_md5 = "Content-MD5=" 1*(ALPHA / DIGIT / "+" / "/" / "=")
– sbn_info = "SBN=" sbn_range
– sbn_range = ( sbnA [ "-" sbnZ ] ) / ( sbnA [ ";" esi_info] )
– esi_info = "ESI=" ((esi_range *( "," esi_range ) ) ) / (esiA "+" number_symbols)
– esi_range = esiA [ "-" esiZ ]
– sbnA = 1*DIGIT; the SBN, or the first of a range of SBNs
– sbnZ = 1*DIGIT; the last SBN of a range of SBNs
– esiA = 1*DIGIT; the ESI, or the first of a range of ESIs
– esiZ = 1*DIGIT; the last ESI of a range of ESIs
– number_symbols = 1*DIGIT; the number of additional symbols required
– alt_query = service_id "&" ( fdt_inst_id / fdt_group_id )
– service_id = "serviceId=" <value of the serviceId attribute of the User Service Description>
– fdt_inst_id = "fdtInstanceId=" <as defined in clause 3.4.1 of [9] or in clause 7.4>
– fdt_group_id = "fdtGroupId=" < value of the Group element as defined in clause 7.2.10.1>
Thus, the following symbols adopt a special meaning for MBMS download URI: ? – + , ; & =
One example of a query on encoding symbol 34 of source block 12 of a music file "www.example.comm/greatmusic/number1.aac" using the provided repair service URI "http://mbmsrepair1.example.com/path/repair_script" is:
– http://mbmsrepair1.example.com/path/repair_script?fileURI= www.example.com/greatmusic/number1.aac&SBN=12;ESI=34
An example of requesting an entire file is
– http://mbmsrepair1.example.com/path/repair_script?fileURI= www.example.com/greatmusic/number1.aac
An example of requesting a specific source block from a specific file version is
– http://mbmsrepair1.example.com/path/repair_script?fileURI= www.example.com/greatmusic/number1.aac&Content-MD5=ODZiYTU1OTFkZGY2NWY5ODh==
For messaging efficiency, the formal definition enables several contiguous and non-contiguous ranges to be expressed, as well as a number of symbols with ESIs of a given value or above in a single query:
– An entire file (like in the above example).
– A symbol of a source block (e.g. …&SBN=12;ESI=23).
– A range of symbols for a certain source block (e.g. …&SBN=12;ESI=23-28).
– A number of symbols with ESIs of a given value or above (e.g. …&SBN=12;ESI=120+10).
– A list of symbols for a certain source block (e.g. …&SBN=12;ESI=23,26,28).
– All symbols of a source block (e.g. …&SBN=12).
– All symbols of a range of source blocks (e.g. …&SBN=12-19).
– non-contiguous ranges (e.g.1. …&SBN=12;ESI=34&SBN=20;ESI=23 also, * e.g. 2. …&SBN=12 19&SBN=28;ESI=23-59&SBN=30;ESI=101).
An example to request all file of a particular FDT instance is given below:
– http://mbmsrepair1.example.com/path/repair_script?serviceId=urn:3gpp:0010120123hotdog&fdtInstanceId=12
9.3.6.2 Byte-Range-Based File Repair Request Message Format
In this message format, the MBMS UE uses the conventional HTTP/1.1 GET or partial GET requests as defined in RFC 2616 [18] to request all or a subset of source symbols of the referenced resource, respectively. The UE shall support these message requests formats to allow the file repair requests to be serviced by a standard HTTP/1.1 server. These message formats shall be used if the MBMS UE is requesting symbols from a file repair server that supports byte range requests, i.e., the server is listed in the "Alternate-Content-Location-1" or "Alternate-Content-Location-2" elements in the FDT.
The MBMS UE uses the HTTP GET request when it requires all the source symbols of the resource to be transmitted.
If the MBMS UE only requests transmission of a subset of the source symbols or sub-symbols the UE uses the HTTP partial GET request with the Range request header as defined in 14.35.2 of RFC 2616 [18]. The MBMS UE shall indicate the specific source symbols or sub-symbols as a byte-range-spec as defined in 14.35.1 of RFC 2616 [18].
For messaging efficiency, the HTTP GET method allows the UE to include multiple byte range requests within a single partial GET request. If the UE includes multiple byte ranges in a single request the HTTP GET request should not exceed 2048 bytes in length to avoid truncation by the HTTP server.
If the MBMS UE determines that it can select among multiple subsets of the source symbols or sub-symbols, the MBMS UE should request the subset with the lowest ESI values, i.e., choose the missing source symbols or sub-symbols from the beginning of the source block or source sub-block, respectively. This improves the caching efficiency of the HTTP file repair servers.
If more than one file were downloaded in a particular MBMS download session, and, if the MBMS client needs repair data for more than one file received in that session, the MBMS client shall send separate HTTP GET requests for each file.
If "File-ETag" is present in the FDT Instance, its value shall be used as the entity-tag in the "If-Match" or "If-Range" header of a conditional byte-range file request.
If "File-ETag" is not present in the FDT Instance, but "Content-MD5" is, the latter may be used as the entity-tag in the "If-Match" or "If-Range" header of a conditional byte-range file request, or the UE may choose to send an HTTP GET request containing the "Range" header for the requested byte range(s), without the "If-Match" or "If-Range" header.
For the UE, the nominal objective of using the "If-Match" header is to receive the requested range(s) of the file associated with the entity-tag, or no repair data if the request cannot be satisfied by the repair server. The nominal objective of using the "If-Range" header is to receive the latest version of the entire file in case the version associated with the entity-tag is no longer available on the repair server. To reduce the impact to capacity, the UE should not use the "If-Range" header if it can request the range(s) from other repair servers.
If the "Content-Encoding" element is included in the FDT Instance for the file and is set to "gzip", then the MBMS UE shall make the request to a modified URL, that is, the original file URL with the ".gz" extension added to the full path name but prior to the query part of the URL, if any. The MBMS UE shall only use this request if a) the "File-ETag" attribute is present in the FDT Instance of that file, for use as the entity-tag in the request, or b) the "Content-MD5" attribute is present in the FDT Instance for that file, for use as the entity-tag in the request. Otherwise, the MBMS UE should rather request the complete file instead of using byte range requests.
As an example, a FLUTE receiver partially receives the transport object with URL "http://www.example.com/service1/document.pdf",Content-Encoding set to "gzip", and with the Content-MD5 set to "B2B359591E961C6B0F468FE536BCD920=" while the "File-ETag" attribute is absent in the FDT Instance. It issues a repair request to the host server to fetch the missing bytes. The request is as follows:
GET /service1/document.pdf.gz HTTP/1.1
If-Match: "B2B359591E961C6B0F468FE536BCD920="
Range: bytes=5018640-5042399
Host: www.example.com
The conditional request is used by the repair server to ensure that the byte range it will serve to the client is from the exact same compressed file. The conditional repair procedure is described earlier in this section.
As a second example, assume that the "Alternate-Content-Location-1" element in the FDT Instance of the file indicates that byte range repair requests are supported by the HTTP server at URI www.example.com/service1/news_service/latest_news.mp4. The UE determines that it requires the byte ranges 5018640-5042399 and 19037040-19050239. The "Content-MD5" attribute provided in the FDT Instance of the file is Base64 encoded as B2B359591E961C6B0F468FE536BCD920, and the "File-ETag" attribute is absent in the FDT Instance. The HTTP GET request may look as follows:
GET /service1/news_service /latest_news.mp4 HTTP/1.1
If-Match: "B2B359591E961C6B0F468FE536BCD920="
Range: bytes=5018640-5042399,19037040-19050239
Host: www.example.com
In case the version identifier, indicated by the "Content-MD5" value as the entity-tag in the ‘If-Match’ header cannot be matched, the server will reply with a 412 "Precondition Failed" reply. Otherwise, the server will satisfy the request and reply with a 206 "Partial Content" if the request would be successful without the ‘If-Match’ header.
The following is an example of a response from the repair server:
HTTP/1.1 412 Precondition Failed
Content-Range: bytes=5018640-5042399,19037040-19050239
ETag: "B2B359591E961C6B0F468FE536BCD920="
Content-Length: 0
As a third example, assume that the "Alternate-Content-Location-1" element in the FDT Instance of the file indicates that byte range repair requests are supported by the HTTP server at URI www.example.com/service2/magazine_service/article_xyz.pdf. The UE determines that it requires the byte ranges 5000-7999 and 25500-40500. The "File-ETag" attribute is present in the FDT Instance and its value is "10690a1-4f2-40d45ae1". The HTTP GET request may look as follows:
GET /service2/magazine_service /article_xyz.pdf HTTP/1.1
If-Match: "10690a1-4f2-40d45ae1"
Range: bytes=5000-7999, 25500-40500
Host: www.example.com
In this example, the version identifier of the file, represented by the value of the FDT Instance’s "File-ETag" and used as the entity-tag in the ‘If-Match’ header, matches the file version at the byte-range repair server. The server will send a 206 "Partial Content" response, providing the requested byte ranges in the payload:
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 2015 06:25:24 GMT
ETag: "10690a1-4f2-40d45ae1"
Content-Length: 18001
Content-Type: multipart/byteranges; boundary=SEPARATION_STRING
–SEPARATION_STRING
Content-Type: application/pdf
Content-Range: bytes 5000-7999
…<the first range>…
— SEPARATION_STRING
Content-type: application/pdf
Content-range: bytes 25500-40500
…<the second range>…
— SEPARATION_STRING
9.3.7 File Repair Response Message
Once the MBMS file repair server has assembled a set of encoding symbols that contain sufficient data to allow the UE to reconstruct the file data from a particular file repair request, the MBMS file repair server sends one message to the UE. Each file repair response occurs in the same TCP and HTTP session as the repair request that initiated it.
An MBMS client shall be prepared for any of these 5 response scenarios:
– The server returns a repair response message where a set of encoding symbols forms an HTTP payload as specified below (see 9.3.7.2 for details).
– The server returns a repair response message where a byte range or set of byte ranges forms an HTTP payload as specified below (see 9.3.7.2a for details).
– The server returns the requested file or file groups (see 9.3.7.5 for details).
– The server redirects the client to a broadcast/multicast delivery (an MBMS download session).
– The server redirects the client to another file repair server (if a server is functioning correctly but is temporarily overloaded).
– An HTTP error code is returned (note that sub-clause 9.3.8 describes the case of no server response).
For (reasonably) uniformly distributed random data losses, immediate point-to-point HTTP delivery of the repair data will generally be suitable for all clients. However, broadcast/multicast delivery of the requested data may be desirable in some cases:
– A repeat MBMS download (all or part of the files from a download session) is already scheduled and the BM-SC prefers to handle repairs after that repeat MBMS download.
– Many UEs request download data (over a short period of time) indicating that broadcast/multicast delivery of the repaired data would be desirable.
In this case a redirect to the broadcast/multicast repair session for UEs that have made a repair request would be advantageous.
9.3.7.1 Symbol-Based File Repair Response Messages Codes
The response codes of HTTP servers to the byte-range-based repair request message in 9.3.6.2 are specified in RFC 2616 [18]. The response codes of symbol-based file repair servers to the symbol-based repair request message in 9.3.6.1 are specified as follows.
In the case that the file repair server receives a correctly formatted repair request which it is able to understand and properly respond to with the appropriate repair data, the file repair server shall attempt to serve that request without an error case.
For a direct point-to-point HTTP response with the requested data, the file response message shall report a 200 OK status code and the file repair response message shall consist of HTTP header and file repair response payload (HTTP payload), as defined in sub-clause 9.3.7.2. If the client receives a 200 OK response with fewer than all the quantity of requested symbols it shall assume that the file repair server wishes the missing symbols to be requested again (due to its choice or inability to deliver those symbols with this HTTP response).
For a redirect case the file repair server uses the HTTP response status code 302 (Found – Redirection) to indicate to the UE that the resource (file repair data) is temporarily available via a different URI. The temporary URI is given by the Location field in the HTTP response. In the case of a redirect to another file repair server, this temporary URI shall be the URL of that repair server.
In the case of a redirect to a broadcast/multicast delivery, the temporary URI shall be the URI of the Session Description (SDP file) of the broadcast/multicast (repair) session as described in sub-clause 9.3.7.3.Other HTTP status codes (RFC 2616 [18]) shall be used to support other cases. Other cases may include server errors, client errors (in the file repair request message) and server overload.
In case the file repair server does not find the requested file (file with given fileURI is found), the server shall respond with "400 Bad Request" and optionally with "0001 File not found" in the response body. As a result, the MBMS UE may choose another file repair server as defined in clause 9.3.5.
In case the file repair server does not find the requested version of the requested file (file with given fileURI is found but Content-MD5 is not found), the server shall respond with "400 Bad Request" and optionally with "0002 Content-MD5 not valid" in the response body. As a result, the MBMS UE may choose another file repair server as defined in clause 9.3.5. Or the MBMS UE may request the latest version of the file and discard the previously received chunks of the file. Note, the MBMS UE can request the latest version of a file by using only the fileURI argument in the file repair request.
NOTE. In the case of repetitive server errors, the client is not expected to go through the complete list of available file repair servers, and may abandon after a limited number of attempts.
If the file repair server does not find any of the requested SBN or ESI values, it shall respond with the "400 Bad Request" and optionally with "0003 SBN or ESI out of range" in the response body. As a result, the UE should discard all received chunks of the file and request the entire file from the file repair server.
If the file repair server receives unknown query line arguments, it shall respond with "501 Not Implemented". The server should add the HTTP1.1 "Server" header with the value "MBMS/6". As a result, the client should try to fetch the entire file from the file repair server. Note, this behaviour is intended to make the file repair service forward compatible and allow addition of new function in later releases.
If the file repair server does not find the requested serviceId value, it shall respond with the "400 Bad Request" and optionally with "0004 ServiceId not found" in the response body. As a result, the UE should request the needed file separately using the fileURI query line argument.
In case the file repair server does not find the requested fdtInstanceId value, it shall respond with the "400 Bad Request" and optionally with "0005 fdtInstanceId not found" in the response body. As a result, the UE should request the needed file separately using the fileURI query line argument.
If the file repair server does not find the requested fdtGroupId value, it shall respond with the "400 Bad Request" and optionally with "0006 fdtGroupId not found" in the response body. As a result, the UE should request the needed file separately using the fileURI query line argument.
If the file repair server is, or is about to, experiencing an overload condition, it should respond with the "503 Service Unavailable" that can include a Retry-After header. As a result, the UE should stop the file repair procedure to that file repair server. The UE shall consider this server unavailable for this file repair session, or, if supported by the UE, for the period of time indicated in the Retry-After header, The UE may immediately try an alternative available file repair server. The UE may re-try the current file repair server after the Retry-After time has elapsed. In the case that all known file repair servers have been exhausted in this manner, the UE shall cease the file repair procedure. When the time in Retry-After header is expressed as an integer number of seconds then it is relative to the reception time of the "503 Service Unavailable".
HTTP response error messages may contain a message body, which gives a more detailed error message. The MIME type of such message body shall be in text/plain. The syntax of the HTTP error message body is defined in ABNF [23] as follows:
http-error-body = error-code (SP / HTAB) error-description CRLF
error-code = 4DIGIT
error-description = 1*(SP / VCHAR)
Note that the following error messages MAY be used in the message body of the HTTP response error messages.
0001 File not found
0002 Content-MD5 not valid
0003 SBN or ESI out of range
0004 ServiceId not found
0005 fdtInstanceId not found
0006 fdtGroupId not found
9.3.7.2 Symbol-Based File Repair Response Message Format for HTTP Carriage of Repair Data
The format of the response message to the symbol-based repair request message in 9.3.6.1 is specified here.
The file repair response message consists of HTTP header and file repair response payload (HTTP payload).
The HTTP header shall provide:
– HTTP status code, set to 200 OK for the case of a successful request.
– Content type of the HTTP payload (see below).
NOTE: Other HTTP headers (RFC 2616 [18]) may also be used but are not mandated by this mechanism.
The Content-Type shall be set to "application/simpleSymbolContainer", which denotes that the message body is a simple container of encoding symbols as described below.
This header is as follows:
– HTTP/1.1 200 OK
– Content-Type: application/simpleSymbolContainer
NOTE: Other HTTP headers (RFC 2616 [18]) may also be used but are not mandated by this mechanism.
Encoding symbols are included in the response in groups. Each group is preceded by an indication of the number of symbols within the group and an FEC Payload ID coded according to the FEC scheme used for the original file delivery session. The FEC Payload ID identifies all the symbols in the group in the same way that the FEC Payload ID of an FEC source or repair packet identifies all the symbols in the packet. The file repair response payload is constructed by including each FEC Payload ID and Encoding Symbol group one after another (these are already byte aligned). The order of these pairs in the repair response payload may be in order of increasing SBN, and then increasing ESI, value; however no particular order is mandated.
A single HTTP repair response message shall contain, at the most, the same number of symbols as requested by the respective HTTP repair request message.
The UE and file repair server already have sufficient information to calculate the length of each encoding symbol and each FEC Payload ID. All encoding symbols are the same length; with the possible exception of the last source encoding symbol in the repair response. All FEC Payload IDs are the same length for one file repair request-response as a single FEC Scheme is used for a single file.
Figure 17: deleted
Figure 18 illustrates the complete file repair response message format (box sizes are not indicative of the relative lengths of the labelled entities).
|
HTTP Header |
||
|
Length Indicator |
FEC Payload ID |
Encoding Symbols |
|
Length Indicator |
FEC Payload ID |
Encoding Symbols |
|
Length Indicator |
FEC Payload ID |
Encoding Symbols |
Length Indicator (2 bytes): indicates the number of encoding symbols in the group (in network byte order, i.e. high order byte first)
FEC Payload ID: indicates which encoding symbols are included in the group. The format and interpretation of the FEC Payload ID are dependent on the FEC Scheme in use.
Encoding Symbols: contain the encoding symbols. All the symbols shall be the same length.
Figure 18: File Repair Response Message Format
9.3.7.2a Byte-Range-Based File Repair Response Message Format for HTTP Carriage of Repair Data
The response message to the byte-range-based repair request message in 9.3.6.2 follows the format and procedures in RFC 2616 [18] for responding to byte range requests.
When the HTTP message includes the content of a single byte range the repair server can provide the HTTP response with a "206 Partial content" status, include the Content-Range header, and use the content-range-spec to indicate the byte range of the repair data as specified in 14.16 of RFC 2616 [18].
When the repair server receives a request for multiple byte ranges it should attempt to transmit all the requested ranges in a single HTTP response. When an HTTP message includes multiple byte ranges, these are transmitted as a multipart message using the "multipart/byteranges" media type as defined in appendix 19.2 of RFC 2616 [18].
9.3.7.3 File Repair Response for Broadcast/Multicast of Repair Data
Details of how a file repair server decides, or is instructed, to use broadcast/multicast repair instead of point-to-point over HTTP are implementation specific and beyond the scope of the present document.
Prior to the decision to use broadcast/multicast repair, each repair response shall be provided by HTTP according to sub-clause 9.3.7.2 or 9.3.7.2a.
The file repair server uses the HTTP response status code 302 (Found – Redirection) to indicate to the UE that the resource (file repair data) is temporarily available via a different URI. The temporary URI is given by the Location field in the HTTP response and is the URI of the Session Description (SDP file) of the broadcast/multicast repair session.
Where feasible, it is recommended that the same download session that delivered the original data be used for the broadcast/multicast repair. If this conflicts with the session end time limit of the Session Description then a new version of the Session Description shall be sent with an updated (extended) session end time. This shall be sent in-band of that download session.
In some cases this may not be feasible and a different (possibly new) download session may be defined for the repair.
The SDP file for broadcast/multicast repair session may be carried as payload (entity-body) in the HTTP response – which is especially useful if the broadcast/multicast repair session is a new (or recently end time modified) FLUTE download session and other means of service announcement prior to this were not feasible.
The delivery method’s associatedDeliveryProcedureDescription may be updated and the new version transmitted in-band with the download session so that currently active client back-off timers are reset, thus minimizing additional client requests until after the broadcast/multicast repair session. The server shall be prepared for additional requests in any case as successful reception of the updated associatedDeliveryProcedureDescription cannot be assured in all cases.
The existence of a broadcast/multicast file repair session is signalled by the inclusion of the optional bmFileRepair procedure in the updated Associated Delivery procedure description. This is signalled by the bmFileRepair element with a single "sessionDescriptionURI" attribute of type "xs:anyURI" which specifies the URI of the broadcast/multicast file repair session’s session description.
In the cases where the same IP addressing is used for the broadcast/multicast repair session as the original download session, the UE simply shall not leave the group. Otherwise, the UE shall join to the MBMS bearer for the repair session as it would for any MBMS session.
A broadcast/multicast file repair session behaves just as an MBMS download session, and the determination of end of files and session, and use of further associated delivery procedures uses the same techniques as specified for the MBMS download delivery method.
9.3.7.4 File Repair Response Message Format for HTTP carriage of Complete Files
The file repair response message consists of HTTP header and one or more complete files.
The HTTP header shall provide:
– HTTP status code, set to 200 OK for the case of a successful response.
– Content type shall be set to multipart/related
NOTE: Other HTTP headers (RFC 2616 [18]) may also be used but are not mandated by this mechanism.
The server shall encapsulate the requested files into a multipart mime container. Each part of the multipart mime shall contain at least the Content-Location of the embedded files.
9.3.8 Server Not Responding Error Case
In the error case where a UE determines that the its selected file repair server is not responding it shall return to the serverURI list of repair servers and uniformly randomly select another server from the list, excluding any servers it has determined are not responding. All the repair requests message(s) from that UE shall then be immediately sent to the newly selected file repair server.
If all of the repair servers from the serverURI list are determined to be not responding, the UE may attempt an HTTP GET to retrieve a, potentially new, instance of the session’s Associated Procedure Description; otherwise UE behaviour in this case is unspecified.
A UE determines that a file repair server is not responding if any of these conditions apply:
1. The UE is unable to establish a TCP connection to the server.
2. The server does not respond to any of the HTTP repair requests that have been sent by the UE (it is possible that second and subsequent repair requests are sent before the first repair request is determined to be not‑responded‑to).
3. The server returns an unrecognized message (not a recognizable HTTP response).
4. The server returns an HTTP server error status code (in the range 500 to 505).
9.3.9 Full File Repair Without the FDT
9.3.9.1 Introduction
When an MBMS UE is unable to receive a file of interest and its associated FDT Instance over MBMS bearers (e.g., UE is outside of MBMS coverage or tunes in between session occurrences of a Datacasting service), the UE may use the following procedures to retrieve the file.
9.3.9.2 File Repair Using the FileSchedule
When the fileSchedule element is provided in the Schedule Description metadata fragment, the MBMS UE may use the fileURI element in the fileSchedule to request the file of interest in accordance with the file repair procedures specified in clause 9.3, i.e., the back-off timing procedures (clause 9.3.4), symbol-based repair server selection (clause 9.3.5) and Repair Request Message format (clause 9.3.6.1).
9.3.9.3 File Repair Using the FDTInstanceURI in the Session Schedule
When the FDTInstanceURI element is provided in the sessionSchedule of the Schedule Description metadata fragment, the MBMS UE may use this to retrieve the FDT Instance for the file(s) of interest. The UE determines the URI of the FDT Instance based on the FDTInstanceURI and when applicable, the session index value for the session occurrence as specified in clause 11.2A.1.2.
From the time that the transmission of files for a session occurrence is considered complete (see clause 9.3.2), the MBMS UE shall wait for the Back-off Time as specified in clause 9.3.4.3 to elapse before requesting the FDT Instance for the file(s) of interest via the HTTP (RFC 2616 [18]) GET method. The FDT Instance is identified in the response by the MIME type "application/fdt+xml" and should fully describe (i.e., contains all necessary FDT file description entries) all of the files delivered in the session occurrence. After receiving the FDT Instance, the MBMS client shall request any file(s) of interest described by that FDT Instance using the server selection procedures specified in clause 9.3.5 and the symbol-based or byte-range based request Request Message Formats specified in clauses 9.3.6.1 and 9.3.6.2, respectively.
9.4 The Reception Reporting Procedure
9.4.0 Generic Reception Reporting Procedure Description
Following successful reception of content whether through point-to-multipoint MBMS bearers only, unicast bearers only, or using both point-to-multipoint and point-to-point bearers, a reception reporting procedure can be initiated by the MBMS Receiver (UE) to the BM-SC. For a DASH-over-MBMS service, the nominal reception reporting procedure may also include DASH QoE measurements as defined in [98], provided to the MBMS client by the DASH client. The additional procedure for such optional inclusion of DASH QoE metrics reporting is described in clause 9.4.8.
For MBMS Download Delivery method, and depending on the content of the MBMS User Service, the reception reporting procedure is used to report a) the complete reception of one or more files, or b) transport level statistics on the stream, or c) both report types a and b. In particular, for a DASH-over-MBMS service, application level statistics on the media stream, in the form of DASH quality metrics, may be aggregated with the report of transport level statistics. For MBMS Streaming Delivery method, the reception reporting procedure is used to report statistics on the stream.
If the BM-SC provided parameters requiring reception reporting confirmation then the MBMS Receiver shall confirm the content reception.
If reception reporting is requested for statistical purposes the BM-SC may specify the percentage subset of MBMS receivers it would like to perform reception reporting. A different sample percentage value may be defined for DASH QoE reports relative to the sample percentage value defined for a nominal MBMS reception report, in deriving the probability of the DASH QoE reporting event given the occurrence of the MBMS reception report.
Transport errors can prevent an MBMS Receiver from deterministically discovering whether the reception reporting associated delivery procedure is described for a session, and even if this is successful whether a sample percentage is described. An MBMS Receiver shall behave according to the information it has even when it is aware that this may be incomplete.
The MBMS Receiver:
1. Identifies the completion of the reception of an MBMS session and its content items (e.g. a file, or a set of files within an MBMS download session). See sub-clauses 9.4.1and 9.4.2.
2. Determines the need to report reception. See sub-clause 9.4.3.
3. Determines the ability to aggregate reception reports. See sub-clause 9.4.4.
4. Selects a time (Request time) at which a reception report request will be sent and selects a server from a list – both randomly and uniformly distributed. See sub-clauses 9.4.4 and 9.4.5.
5. Sends a reception report request message to the selected server at the selected time. In the event that the content components of an MBMS User Service instance are carried on multiple MBMS delivery sessions, each reception report request message shall identify the delivery session to which the report pertains. See sub-clause 9.4.6.
Regarding the above rules for determining the need for, and subsequent occurrences of reception reports, each of these reception reports may also include one or more DASH QoE metrics reports, the rules on the generation of which are defined in sub-clause 9.4.8.
Then the server:
1. Responds with a reception report response message either describing a success or an error case. See sub-clause 9.4.7.
9.4.1 Identifying Complete File Reception from MBMS Download and Determining Download Status
A file is determined to be completely downloaded when it is fully received and reconstructed by MBMS reception with FEC decoding (if FEC is actually used) and/or a subsequent File Repair Procedure (sub-clause 9.3).
When compiling RAck reception reports for an MBMS download session, the failure or success of a file is determined after FEC decoding and any subsequent File Repair Procedure.
When compiling StaR, StaR-all, or StaR-only reception reports for an MBMS download session, the failure or success of a file is determined after FEC decoding and before any subsequent File Repair Procedure.
9.4.2 Identifying Complete MBMS Delivery Session Reception
If a schedule description fragment is received for a service, MBMS download sessions are considered complete when the stop time in the sessionSchedule adjusted to the specific session occurrence to account for any session reoccurrence when applicable, is reached.
If a Schedule Description fragment is not received for a service, the sessions (MBMS download and MBMS streaming) are considered complete when the "time to" value of the session description (from "t=" in SDP) is reached. Where the end time is unbounded (time to = 0) then this parameter is not used for identifying completed sessions.
MBMS download and MBMS streaming sessions are also considered complete when the UE decides to exit the session – where no further data from that session will be received. In this case the UE may or may not deactivate the MBMS bearer(s).
For MBMS download sessions, FLUTE provides a "Close session flag" (see sub-clause 7.2.7) which, when used, indicates to the UE that the session is complete.
9.4.3 Determining Whether a Reception Report Is Required
Upon full reception of a content item, or at the expiration of the periodic ‘report interval’ timer if present, or when a session is complete, the MBMS Receiver must determine whether a reception report is required. The reception report may additionally include the reporting of DASH QoE metrics, in the event of a DASH-over-MBMS service, as described in sub-clause 9.4.8. An Associated Delivery Procedure Description indicates the parameters of a reception reporting procedure (which is transported using the same methods as the ones that describe File Repair).
A delivery method may associate zero or one associated delivery procedure descriptions with an MBMS delivery session. Where an associated delivery procedure description is associated with a session, and the description includes a postReceptionReport element, the UE shall initiate a reception reporting procedure. Reception reporting behaviour depends on the parameters given in the description as explained below.
The Reception Reporting Procedure is initiated if:
a. A postReceptionReport element is present in the associated procedure description instance, and/or if the QoE reporting according to sub-clause 8.3.2.2 is activated.
For report types StaR, StaR-all, and StaR-only, if the r14:reportInterval attribute is present under postReceptionReport, then whenever the UE starts consumption of the MBMS User Service of concern, it is expected to reset its corresponding ‘report interval’ timer to the value of that attribute and begin count down of the timer. Whenever the UE stops the consumption of the same service, it is expected to disable its corresponding ‘report interval’ timer and transmit the last report, if required and in accordance to the rules defined in clause 9.4.0.
If r14:reportInterval is present and the "Sending-Rate" parameter of the SDP is set to "Periodic", QoE metrics completely gathered during the ending reportInterval period shall be inserted into the reception report request message. If the "Sending-Rate" parameter of the SDP is set to "End", then the QoE metrics shall be sent at the end of the session.
Note: In case of "Periodic" sending-rate, the UE shall report all metrics that have been completely gathered (linked to "Measure-Resolution" or "Measure-Range" if present). If QoE metrics are currently being calculated but gathering is not finished, the UE shall not send such metrics and wait for the next reportInterval time to send this currently accumulating data. Similar rule shall apply to the reporting of successful and/or failed file reception and associated reception details, i.e. if such file reception information is currently being calculated but its collection is not yet finished, the UE shall defer the reporting of this information and wait until the occurrence of the next reportInterval time to do so.
In the event that the UE determines a selection for reporting to both active reporting procedures, it should comply with both reporting configurations. Should such separate reporting not be desirable due to, for example, report compilation complexity, reception reporting in accordance to OMA-DM should take precedence over reporting in accordance with the Associated Delivery Procedure.
One of the following will determine the UE behaviour:
b. reportType is set to RAck (Reception Acknowledgement). Only successful file reception is reported without reception details.
c. reportType is set to StaR (Statistical Reporting for successful reception). Successful file reception is reported (as with RAck) with reception details for statistical analysis in the network.
d. reportType is set to StaR-all (Statistical Reporting for all content reception). The same as StaR with the addition that failed reception is also reported. StaR-all is relevant to both streaming and download delivery.
e. reportType is set to StaR-only (Statistical Reporting without Reception Acknowledgement). The same as StaR-all with the exception that individual files are not acknowledged. Only reception details are reported for the session for both streaming and download delivery. StaR-only is equivalent to StaR-all for streaming delivery. StaR-all is relevant to download delivery where session performance is obtained through QoE metrics.
The reportType attribute is optional and behaviour shall default to RAck when it is not present.
If a reportType attribute is included, and set to an unknown value, then it shall be ignored by the receiver (i.e. the UE).
The samplePercentage attribute can be used to set a percentage sample of receivers which should report reception. This can be useful for statistical data analysis of large populations while increasing scalability due to reduced total uplink signalling. The samplePercentage takes on a value between 0 and 100, including the use of decimals. It is recommended that no more than 3 digits follow a decimal point (e.g. 67.323 is sufficient precision).
The samplePercentage attribute is optional and behaviour shall default to 100 (%) when it is not present. The samplePercentage attribute may be used with StaR, StaR-only and StaR-all, but shall not be used with RAck.
When the samplePercentage is not present or its value is 100 each UE which entered the associated session shall send a reception report. If the samplePercentage were provided for reportType StaR, StaR-only and StaR-all and the value is less than 100, the UE generates a random number which is uniformly distributed in the range of 0 to100. The UE sends the reception report when the generated random number is of a lower value than the samplePercentage value.
In the case of a DASH-over-MBMS service, the determination of whether a DASH QoE metrics report shall be attached to the nominal reception report parameters, assuming the presence of the r13:DASHQoEProcedure child element of the associatedProcedureDescription element, is specified by an additional target probability, as given by the DASHQoESamplePercentage element. The details are specified in sub-clause 9.4.8.
9.4.4 Request Time Selection
The MBMS receiver selects a time at which it is to issue a delivery confirmation request. The default start time for the reception reporting procedure is defined in clause 9.3.2.
Back-off timing is used to spread the load of delivery confirmation requests and responses over time.
Back-off timing is performed according to the procedure described in sub-clause 9.3.4. The offsetTime and randomTimePeriod used for delivery confirmation may have different values from those used for file-repair and are signalled separately in the reception reporting description of the associated delivery procedure description instance.
In general, reception reporting procedures may be less time critical than file repair procedures. Thus, if a postFileRepair timer may expire earlier than a postReceptionReport, radio and signalling resources may be saved by using the file repair point-to-point PDP context (and radio bearer) activate period also for reception reporting (to remove the delay and signalling of multiple activations and deactivations over time)
The default behaviour is that a UE shall stop its postReceptionReport timers which are active when a postFileRepair timer expires, and the UE shall send the corresponding reception report(s) immediately following the file repair procedure on the point-to-point communication setup for file repair.
In some circumstances, the system bottleneck may be in the server handling of reception reporting. In this case the forceTimeIndependence attribute may be used and set to true. (false is the default case and would be a redundant use of this optional attribute). When forceTimeIndependence is true the UE shall not use file repair point-to-point connections to send reception reporting messages. Instead it will allow the timers to expire and initiate point-to-point connections dedicated to reception report messaging.
A UE may aggregate multiple reception reports together to be more efficient. When a UE has determined that a reception report is required, the UE may determine that if a currently pending reception report exists, these reception reports may be aggregated and sent together.
In the case that a UE decides to aggregate more than one reception reports together from across different user services, the UE shall collect the new reception report and the postReceptionReport timer for this aggregated bundle shall be set to the lowest remaining postReceptionReport timer of the individual reception reports in the aggregated bundle.
In the case that a UE decides to aggregate more than one reception reports together within a user service, the UE shall collect the new reception report and the postReceptionReport timer for this aggregated bundle shall be set according to the first reception report and remain unchanged during any further aggregation (i.e., equal to the sum of the offsetTime and the generated randomTimePeriod of the first reception report in the aggregated bundle.
In the case of aggregating reception reports from within a user service, if a UE has generated a random number to compare against samplePercentage (in the case that samplePercentage is used), this number shall persist until the aggregated reception report bundle is sent. This means that an original decision to report or not persists until the end of a session. In the case of aggregating across services, the various generated random numbers to compare against samplePercentage remain independent from other services.
These reception reports are then aggregated as in sub-clause 9.4.6 and the aggregated bundle shall be sent at the expiration of the postReceptionReport timer, assuming no further aggregation.
For StaR, StaR-only and StaR-all, session completeness – according to sub-clause 9.4.2 – shall determine the back-off timer initialization time.
For RAck, the complete download session – according to sub-clause 9.4.2 – as well as completing any associated file repair delivery procedure shall determine the back-off timer initialization time. RAcks shall be only sent for completely received files.
9.4.5 Reception Report Server Selection
Reception report server selection is performed according to the procedure described in sub-clause 9.3.5.2.
In the case of an aggregated reception report, the server URI list shall be the subset of server URIs common to all reports.
9.4.6 Reception Report Message
Once the need for reception reporting has been established, the MBMS receiver sends one or more Reception Report messages to the reception report server URI. The report message shall include the parameters associated with the nominal MBMS reception report type (i.e. one of the following categories: RAck, StaR, StaR-all and StaR-any). It may optionally include the report by the DASH client of DASH quality metrics as defined in [98], and in accordance to the parameters and procedure specified in sub-clause 9.4.8. A reception report message shall not be used to only carry DASH QoE metrics of a DASH-over-MBMS service. All Reception Report requests and responses for a particular MBMS transmission should take place in a single TCP session using the HTTP protocol (RFC 2616 [18]).
The Reception Report request shall include the URI of the file for which delivery is being confirmed. URI is required to uniquely identify the file (resource).
The client shall make a Reception Report request using the HTTP (RFC 2616 [18]) POST request carrying XML formatted metadata for each reported received content (file). An HTTP session shall be used to confirm the successful delivery of a single file. If more than one file were downloaded in a particular MBMS download multiple reception reports shall be added in a single POST request.
Each Reception Report is formatted in XML according the following XML schema (sub-clause 9.5.3). An informative example of a single reception report XML object is also given (sub-clause 9.5.3.2).
Multipart MIME (multipart/mixed) may be used to aggregate one or more small XML files of individual reports to a larger object. The aggregated multipart MIME file may contain only nominal MBMS reception reports, or any combination of one or more MBMS reception reports along with one or more DASH QoE metrics reports.For Reception Acknowledgement (RAck) a receptionAcknowledgement element shall provide the relevant data. In the event that the content components of an MBMS User Service instance are delivered on multiple MBMS delivery sessions, each Reception Report request shall identify the corresponding session as given by the attribute sessionId of the receptionAcknowledgment element.
For Statistical Reporting (StaR) one or more statisticalReport elements shall provide the relevant data. In the event that the content components of an MBMS User Service instance are delivered on multiple MBMS delivery sessions, the sessionId attribute for any given StaR type of reception report (StaR, StaR-all or StaR-only), i.e., receptionReport.statisticalReport.qoeMetrics.medialevel_qoeMetrics@sessionId, shall provide the identity of the session for that StaR reception report.
Multiple reception reports, along with zero or more DASH QoE metrics reports, can be aggregated together in order to reduce radio resources and HTTP transactions. In the case that sessions are close together as defined in sub-clause 9.4.4, two or more reception reports should be aggregated together at the client.
Note that the following text in the current sub-clause on RAck and/or StaR-related types of reception reports addresses aggregation only for nominal MBMS reception reports. Inclusion of DASH QoE reports in the aggregated report file is not precluded.
There are two possible mechanisms for aggregating reception reports. In the case of StaR (StaR, StaR-all, StaR-only):
– a single reception report should contain multiple statisticalReport elements, each relating to a different serviceId.
– alternatively, multipart MIME (multipart/mixed) may be used to aggregate several reception report XML files.
In the case of RAck reporting:
– multipart MIME (multipart/mixed) may be used to aggregate several reception report XML files.
For both RAck and StaR/StaR-all (mandatory):
– For download, one or more fileURI elements shall specify the list of files which are reported. If the Content-MD5 value of the file is present in the FDT, it shall be provided in the Content-MD5 attribute in the reception report. Note, this allows unambiguous identification of the files. For RAck reporting, the following attributes may be included:
– A clientId and a deviceId attribute, whose format is the same as that defined below for clientId and deviceId under StaR/StaR-all/StaR-only. If present, they shall be included in at least the first instance of the fileURI elements to allow identification of the client and the device that has received the file(s) identified by all instances of the fileURI element in the RAck report.
– A sessionId attribute, whose format is the same as that defined below for sessionId under StaR/StaR-all/StaR-only. If present, it shall be included in at least the first instance of the fileURI elements.
– For the StaR-all mode only, a list of the number of received symbols and a list of the total number of source symbols shall be provided for failed blocks of the file, if any. Both lists are tabulated before any unicast file repair procedures. Thus, the lists are provided for failed files, and for successfully received files that required unicast file repair procedures.
For only StaR/StaR-all/StaR-only (all optional):
– Each fileURI element has an optional receptionSuccess status code attribute which defaults to "true" ("1") when not used. This attribute shall be used for StaR-all reports. This attribute shall not be used for StaR reports. This attribute is not relevant for StaR-only reports.
– Each QoE Metrics element has a set of attributes and any number of media level QoE Metrics elements. All attributes are defined in sub-clause 9.5.3 and correspond to the QoE metrics listed in sub-clause 8.4.2. Individual metrics, both at session and at media level can be selected via SDP as described in sub-clause 8.3.2.1.
NOTE: The medialevel_qoeMetrics element is nominally used to declare QoE metrics associated with RTP streaming content. For a StaR-type reception report pertaining to media components of a DASH-over-MBMS service, only the sessionId attribute (i.e., none of the other attributes of this element) should be present under medialevel_qoeMetrics.
– The sessionId attribute identifies the delivery session. If the sessionType is "download", sessionId is of the format source_IP_address + ":" + flute-tsi. If the sessionType is "streaming", sessionId is of the format source_IP_address + ":" + RTP_destination_port.
– The sessionStartTime and sessionStopTime attributes identifies the time when the session was started and stopped, respectively. The values of each attribute corresponds to the 32 most significant bits of a 64 bit Network Time Protocol (NTP) [78] time value (i.e. the seconds part of the NTP time stamp format). These 32 bits provide an unsigned integer representing the time in seconds relative to 0 hours 1 January 1900. Handling of wraparound of the 32 bit time is outside the scope of NTP and FLUTE.
– The sessionType attribute defines the basic delivery method session type used = "download" || "streaming".
– The serviceId attribute is value and format is taken from the respective userServiceDescription serviceId definition.
– The clientId attribute is unique identifier for the receiver, e.g. an MSISDN of the UE as defined in [77].
– The deviceId attribute is a unique identifier for the receiver device, e.g. an IMEI of the UE as defined in [77].
– The serviceURI attribute value and format is taken from the respective associatedDeliveryProcedureDescription serviceURI, which was selected by the UE for the current report. This attribute expresses the reception report server to which the reception report is addressed.
9.4.7 Reception Report Response Message
An HTTP response is used as the Reception Report response message.
The HTTP header shall use a status code of 200 OK to signal successful processing of a Reception Report. Other status codes may be used in error cases as defined in RFC 2616 [18].
9.4.8 Combining DASH Quality Measurements with Reception Reporting
9.4.8.1 Introduction
A new element is added to the Associated Delivery Procedure Description (ADPD) fragment to support, in the case of DASH-over-MBMS services, DASH QoE metrics reports produced by the DASH client to be acquired and subsequently sent by the MBMS client as part of reception reporting. The r13:DASHQoEProcedure element may be present as a child of the associatedProcedureDescription element, containing signaling on the eligibility, actual presence and characteristics of DASH QoE metrics measurements, attached to the nominal reception report. The details of DASH QoE metrics are described in TS 26.247 [98]. The aggregation of the XML documents representing MBMS reception report(s) and DASH QoE metrics report(s) shall be implemented as a MIME multipart structure of the multipart/mixed subtype, as defined in RFC 2557 [37].
9.4.8.2 Whether and What DASH QoE Metrics to Include in Reception Report
Presence of the r13:DASHQoEProcedure element in the ADPD is an indication that the MBMS client shall collect the DASH QoE metrics reported by the DASH client in order for this information to become eligible for inclusion in Reception Report request messages. The DASH QoE metrics are reported in conjunction with the nominal reception reports as described in sub-clause 9.4.8.3. If r13:DASHQoEProcedure is present, then the target probability for DASH quality metrics measurements to be included in the Reception Report request message shall be specified by the DASHQoESamplePercentage child element of r13:DASHQoEProcedure. The semantics of DASHQoESamplePercentage, including its default value when this element is absent, is identical to the samplePercentage attribute of the postReceptionReport element as defined in sub-clause 9.4.3. In particular, the following rules shall apply when the r13:DASHQoEProcedure element is present:
– If the reception reporting procedure is active (i.e. the postReceptionReport element is present in the ADPD fragment, and its attribute samplePercentage value is non-zero), and the DASHQoESamplePercentage is absent, then a DASH QoE metrics report shall be sent every time a MBMS reception report is sent. Whenever a Reception Report is sent, it shall include the one or more DASH QoE metrics reports collected by the MBMS client for the same time period over which the Reception Report was collected.
– If the reception reporting procedure is active, and DASHQoESamplePercentage is present, then the probability of DASH QoE metrics measurements being present in a given reception report shall be given by the value of {r13:DASHQoEProcedure.DASHQoESamplePercentage}. The DASH QoE metrics measurements to be attached in the reception report shall be specified by the DASHMetrics child of the r13:DASHQoEProcedure element, as a string of comma-separated variables.
– If the reception reporting procedure is inactive (i.e., the postReceptionReport element is either absent in the ADPD, or if present, the random number generated by the UE is above the samplePercentage value), then regardless of the value of DASHQoESamplePercentage, no DASH QoE metrics report will be sent.
NOTE: It is expected that these parameters will correspond exactly to the QoE metrics sent by the DASH client in its QoE report to the MBMS client, and may represent the entirety or a subset of the quality metrics defined in sub-clause 10.2 of TS 26.247 [98] and specified by the MPD.Metrics@metrics attribute in [98].
9.4.8.3 Multipart MIME Aggregation of Reception Report and DASH QoE Metrics Report
As described in sub-clause 9.4.6, MBMS reception reports and DASH QoE measurement reports shall be combined into a single aggregate document by making use of the MIME multipart/mixed file format [37]. Two options are possible:
– Option 1: The Internet Media Type (content type) is used to differentiate between the two types of reports, i.e., "application/mbms-reception-report+xml" for nominal reception report files, and "application/3gpdash-qoe-report+xml" for DASH QoE metrics report files
– Option 2: The same text/xml media type may be used for both. The server can differentiate the report types by the XML header portion of the report.
An example of Option 1 is shown below. Here, the MIME multipart message which contains as separate body parts the Reception Report and the DASH QoE Report delineates the two parts by a boundary, named "separator" in the "Content-Type: " header. This boundary is placed between the parts at the beginning and end of the body of the message, as follows:
POST http://www.exampleserver.com/rr HTTP/1.1
Host: 192.68.1.1
User-Agent: Mozilla/5.0(Linux; U; Android 4.0.3 ….)
Content-Length: 12345
Content-Type: multipart/mixed; boundary=separator
Connection: Keep-Alive
<…other HTTP headers>
–separator
Content-Type: application/mbms-reception-report+xml
<XML document of the MBMS Reception Report>
–separator
Content-Type: application/3gpdash-qoe-report+xml
<XML document of the DASH QoE Metrics Report>
–separator–
Option 1 is recommended as the aggregate report format since it avoids the report server having to look into the header portion of each component XML file to determine the composition of the aggregated report.
9.4A MBMS User Service Consumption Reporting
9.4A.1 Introduction
Towards attaining more accurate knowledge of ongoing consumption of an MBMS User Service, consumption reporting procedures are defined in this clause. This functionality better enables the MBMS service operator to decide, based on real time demand of an MBMS User Service, to either
– establish service delivery over an MBMS bearer;
– teardown service delivery over an already established MBMS bearer to only leave service delivery over unicast
and doing so in a dynamic manner, to best utilize overall network capacity resources in supporting unicast and/or MBMS services delivery. The MBMS service consumption reporting procedure is initiated by the MBMS receiver (UE) to the BM-SC, in accordance to parameters in the Associated Delivery Procedure description. Consumption of an MBMS User Service over an MBMS bearer by a UE is defined as the reception of service content on any of the transport session(s) referenced by the deliveryMethod element(s) under the userServiceDescription element of that service. Consumption of an MBMS User Service delivered over unicast by the UE, in the event that the MBMS bearer for such service is not provisioned where the UE is located, is represented by the reception of service content associated with either (but not both) the r12:unicastAppService child element or the r8:alternativeAccessDelivery child element under the deliveryMethod element.
9.4A.2 Whether and How Consumption Report Is to be Performed
The MBMS Receiver shall determine whether a consumption report is required for an associated MBMS User Service. An Associated Delivery Procedure Description indicates the parameters of a consumption reporting procedure (transported using the HTTP request mechanism procedure similarly used for File Repair and Reception Reporting).
An MBMS User Service may associate zero or one Consumption Reporting Description instances with the MBMS User Service. When the r12:consumptionReporting element is present in the userServiceDescription element of the MBMS User Service Bundle Description Fragment, the UE shall initiate a consumption reporting procedure when any of the conditions below become valid:
– Start of UE consumption of the MBMS User Service on the MBMS bearer;
– Stop of UE consumption of the MBMS User Service on the MBMS bearer;
– Start of UE consumption of the MBMS User Service on unicast;
– Stop of UE consumption of the MBMS User Service on unicast;
– Transition of UE consumption of the service from unicast to MBMS bearer, which may occur in one of the following ways:
a) The UE stops consuming the MooD eligible MBMS User Service on unicast, and starts consumption of the service on an MBMS bearer;
b) The UE stops consuming the MooD eligible non-MBMS service on unicast, and starts consumption of the corresponding MBMS User Service on an MBMS bearer
– Transition of UE consumption of the MBMS User Service from MBMS bearer to unicast, which occurs in the following way:
– The UE stops consuming the MBMS User Service on a MBMS bearer, and starts consumption of the MBMS User Service on unicast;
– Upon determining the need to report ongoing UE consumption of the MBMS User Service
– The "ongoing" report is performed at periodic intervals as set by the reportInterval attribute of the r12:consumptionReport element.
NOTE 1: If the reportInterval attribute is present under r12:consumptionReport, then whenever the UE starts consumption of the MBMS User Service of concern, it is expected to reset its corresponding ‘report interval’ timer to the value of that attribute and begin count down of the timer. Whenever the UE stops the consumption of the same service, it is expected to disable its corresponding ‘report interval’ timer.
– Upon determining a location change. If the location element in r12:consumptionReport is included, and upon detecting a change of location while consuming an MBMS User Service. Depending on the value of the location child element in the r12:consumptionReport element, the UE detects a location change as either
– an MBMS SAI change, if the location element indicates to report MBMS SAI. An MBMS SAI location change shall be detected by the UE if there are one or more SAI values that have changed in its non-empty SAI list(s) prepared for inclusion in the Consumption Report Request message as specified in clause 9.5A.5, and any of the SAIs in the list match any of the SAI in availabilityInfo.infoBinding.serviceArea elements in the USD.
– a CGI change, if the location element indicates to report CGI
– an ECGI change, if the location element indicates to report ECGI
NOTE 2: If the reportInterval attribute is present under r12:consumptionReport, then whenever the UE detects a location change while consuming an MBMS User Service, it is expected to reset its corresponding ‘report interval’ timer to the value of that attribute and begin count down of the timer.
Consumption Reporing shall not be performed by the UE if any of the following conditions are met:
– If the Consumption Reporting Description is absent under the userServiceDescription element;
– If the Consumption Reporting Description is present, and the location type requested to be reported is MBMS SAI and
– there is no match between any of the SAI in availabilityInfo.infoBinding.serviceArea elements in the USD with the entries in the MBMS SAI list prepared for inclusion in the Consumption Report request message (see 9.5A.5), or
– SIB 15 is not present.
– If the r12:mooDConfiguration element in the userServiceDescription element is present, and the UE is consuming the service on unicast. More specifically, the UE shall not generate Consumption Report signalling unicast comsumption to indicate:
– Start of UE consumption of the MBMS User Service on unicast;
– Stop of UE consumption of the MBMS User Service on unicast;
– Transition of UE consumption of the service from unicast to MBMS bearer. The UE shall instead report Start of UE consumption of the MBMS User Service on the MBMS bearer if Consumption Report is enabled for MBMS User Service consumed on the MBMS bearer;
– Transition of UE consumption of the MBMS User Service from MBMS bearer to unicast. The UE shall instead report Stop of UE consumption of the MBMS User Service on the MBMS bearer if Consumption Report is enabled for MBMS User Service consumed on the MBMS bearer;
– Ongoing consumption of the MBMS User Service on unicast, upon the expiration of the "report interval" timer;
– Location change while consuming the MBMS User Service on unicast.
The BM-SC can specify the percentage subset of MBMS receivers that the BM-SC would like to perform consumption reporting via the samplePercentage attribute. The samplePercentage takes on a value between 0 and 100, including the use of decimals. It is recommended that no more than 3 digits follow a decimal point (e.g. 67.323 is sufficient precision). The samplePercentage attribute is optional and the default UE behavior when it is absent is to always perform consumption reporting in accordance to the rules and criteria stated in this sub-clause 9.4A.2, as well as sub-clauses 9.4A.3, 9.4A.4 and 9.4A.5.
The BM-SC can specify the nominal periodicity by which the UE, when it is continuously consuming the service of concern, shall perform consumption reporting. This periodicity, defined as a time duration between consecutive reports, is specified by the reportInterval attribute. Periodic consumption reporting uses the ‘report interval’ timer, which is preset to the reportInterval value whenever the UE starts consumption of the associated MBMS User Service, or when the timer has expired from the previous countdown cycle, and begins a subsequent countdown cycle. The reportInterval attribute is optional and the default UE behavior when it is absent is not to perform ongoing consumption reporting.
The BM-SC can specify whether the UE shall include its current location by serving cell-ID or MBMS SAI when it performs consumption reporting, via the location child element of r12:consumptionReport. The cell-ID(s) to be reported depends on whether the MBMS service is delivered on unicast bearer(s) or MBMS bearer(s), if Carrier Aggregation [96] is employed in the E-UTRAN. If the MBMS service is delivered via unicast bearer(s), the reported ECGI(s) should include the identity (identities) of all serving cell(s), i.e., that of the PCell and zero or more SCells. If the MBMS service is provided on MBMS bearer(s), the reported cell-ID shall be that of the MBMS cell, which could be either the PCell, the SCell, or a configurable SCell. The UE shall report its location according to the enumerated value of the location element, i.e., "MBMS SAI", "CGI" or ECGI". The location element is optional and the default UE behavior when it is absent, or if its content is set to an unknown value, is not to include the UE’s location in the consumption report.
NOTE 3: The means of reporting cell-ID as defined in this clause shall apply to the described mechanism in clause 9.4A5 on reporting of the location attribute for ECGI.
The BM-SC can specify whether the UE shall include, in the consumption report message, the clientId attribute which represents the unique identifier for the receiver, e.g. an MSISDN of the UE as defined in [77]. This is specified by the reportClientId attribute of r12:consumptionReport, which when set to "1" or "true" indicates that the UE shall include clientId in the consumption report message, and when set to "0" or "false" indicates that the UE shall not include clientId in the consumption report message. The reportClientId attribute is optional and the default UE behavior when it is absent is not to include the client identifier in the consumption report.
9.4A.3 Consumption Report Server Selection
One or more consumption report servers are implemented in the BM-SC, and the selection of which consumption report to use by the UE is performed similar to the procedure described for file repair server selection in sub-clause 9.1. If more than one serviceURI elements are present under consumptionReporting, the UE shall randomly select one of them, with uniform distribution as the destination of the consumption report message. Use of the selected consumption report server by the UE shall be maintained for the entire duration span of UE submissions of the "start", "ongoing" (one or more), and "stop" consumption reports, unless the consumption report server redirects the UE to another consumption report server using an HTTP 3xx status code in the response message.
When a UE obtains an updated APD fragment for the MBMS User Service of interest, and the serviceURI under the consumptionReporting element that the UE had selected is no longer listed in the updated APD, the UE shall randomly select a new serviceURI element currently present under consumptionReporting, with uniform distribution as the destination of the consumption report request message. The UE shall send consumption reports to the newly selected destination at the next scheduled "ongoing" consumption report opportunity, as well as for consumption report submission resulting from a "location change", a "stop", or a "start" condition.
9.4A.4 Back-Off Timing in Consumption Reporting
Back-off timing is used to spread the load of consumption report requests uniformly over time. Back-off timing is performed according to the procedure described in sub-clause 9.3.4. The offset time and random time period used for consumption reporting may differ in values from those used in file-repair and/or reception reporting, and are signalled separately by the offsetTime and randomTimePeriod attributes of the consumptionReport child element of the Associated Delivery Procedure Description instance. For example, UEs might be required to submit consumption reports within a tighter time window and with a smaller offset delay to enable more timely reception of consumption reports by the BM-SC in order to affect dynamic decision on whether to maintain or disable the associated MBMS service. The offsetTime attribute is optional. The default UE behavior when this attribute is absent or set to ‘0’ is not to employ a wait time before computing a random time within the time window given by randomTimePeriod in initiating the consumption report procedure.
9.4A.5 Consumption Report Request Message
Once the need for consumption reporting has been established, the MBMS receiver sends one or more Consumption Report request messages to the consumption report server identified by the serviceURI. Consumption Report requests and responses pertaining to a single complete sequence of the "start", one or more "ongoing", and the "stop" consumption reports to/from the same consumption report server shall take place in one or more TCP sessions using the HTTP protocol (RFC 2616 [18]), i.e., via the use of either persistent or non-persistent TCP connections for carrying the HTTP consumption reporting traffic.
NOTE: Should the BM-SC wish to correlate the start and stop consumption reports from individual UEs, the reportClientId attribute of the r12:consumptionReport element in the ADPD fragment should be set to "1" or "true".
The MBMS client shall make a Consumption Report request using the HTTP (RFC 2616 [18]) POST request carrying XML formatted metadata for each report. The MIME Type for the document in the request shall be as defined in Annex C.16.
Each consumption report is formatted in XML according to the XML schema shown in sub-clause 9.5.4. An informative example of a single consumption report XML object is given in sub-clause 9.5.4.1).
The Consumption Report request message contains the following mandatory and optional parameters:
Mandatory:
– The serviceId attribute that represents the MBMS User Service to which each consumption report pertains, and whose value and format is identical to that specified by the associated userServiceDescription element of the USD.
– The consumptionType attribute which declares the consumption report as belonging to one of the following types, and are mapped to the conditions for consumption reporting as indicated in sub-clause 9.4A.2:
1) – start of consumption of the MBMS User Service on the MBMS bearer;
2) – transition of UE consumption of the service from unicast to MBMS bearer;
3) – stop of consumption of the MBMS User Service on the MBMS bearer;
4) – transition of UE consumption of the MBMS User Service from MBMS bearer to unicast;
5) – ongoing consumption of the MBMS User Service on the MBMS bearer upon the expiration of the ‘report interval’ timer;
6) – location change while consuming the MBMS User Service on the MBMS bearer;
7) – start of consumption of the MBMS User Service on unicast;
8) – stop of consumption of the MBMS User Service on unicast;
9) – ongoing consumption of the MBMS User Service on unicast, upon the expiration of the ‘report interval’ timer
10) – location change while consuming the MBMS User Service on unicast.
Optional:
– The clientId attribute which identifies the reporting UE, if the attribute reportClientId was present under the consumptionReport element in the Associated Delivery Procedure Description instance.
– The reportTime attribute which identifies the time when the report is generated by the UE.
– The location attribute which represents the UE’s location by CGI or ECGI or the list(s) of MBMS SAI(s) from SIB15 [97] as defined by the MooD configuration parameter <X>/LocationType in sub-clause 12.2.2. For the case of MBMS SAI, the UE shall build the list of MBMS SAIs to include in its Consumption Report Request message as follows:
– Include all the SAIs from the SIB 15 intra-frequency list if present (see mbms-SAI-IntraFreq-r11 in [97]), in intraFreq-SAI element in the Consumption report request message;
– Include all the SAIs from every inter-frequency lists if present in SIB 15 (see mbms-SAI-InterFreqList-r11 in [97]) in interFreq-SAI element in the Consumption report request message;
– Include a list of SAIs corresponding to the intersection between the SAIs from the SIB 15 [97] and the list of MBMS Service Area Identities included in the userServiceDescription.availabilityInfo.infoBinding.serviceArea elements for the same serviceId, in the intersected-SAI element in the Consumption report request message. Before the intersection is created, all SAIs from intra-frequency neighbour cells shall be removed from the SIB15 SAI list (see [97] for details of SAIs from intra-frequency neighbour cells).
9.4A.6 Consumption Report Response Message
An HTTP response is used as the Consumption Report response message.
The HTTP header shall use a status code of 200 OK to signal successful processing of a Consumption Report request message. Other status codes may be used in error cases as defined in RFC 2616 [18].
9.5 XML-Schema for Associated Delivery Procedures
9.5.1 Generic Associated Delivery Procedure Description
Below is the formal XML syntax of associated delivery procedure description instances. Documents following this schema can be identified with the MIME type "application/mbms‑associated-procedure-description+xml" defined in Annex C.7. The schema filename of delivery procedure description is associatedprocedure.xsd.
In this version of the specification, the network shall set the schemaVersion element, defined as a child of associatedProcedureDescription element, to 2.
The schema version attribute (part of the schema instruction) shall be included in the UE schema and the network schema.
NOTE: The value of the schemaVersion element and version attribute is intended to be increased by 1 in every future releases where new element(s) or attribute(s) are added.
When a UE receives an instantiation of an associated delivery procedure description compliant to this schema, it shall determine the Associated Delivery Procedures schema version required to parse the instantiation as follows:
– If the UE supports one or more versions of the Associated Delivery Procedures schema with the schema version attribute, then the UE shall use the schema that has the highest schema version attribute value that is equal to or less than the value in the received schemaVersion element;
– Otherwise, if the UE supports an Associated Delivery Procedures schema without a schema version attribute, or if all of its Associated Delivery Procedures schemas with the schema version attribute have a value greater than the value received in the schemaVersion element, then the UE shall use its schema without a version attribute.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
xmlns="urn:3gpp:metadata:2005:MBMS:associatedProcedure"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:r12="urn:3gpp:metadata:2005:MBMS:associatedProcedure-rel-12-extension"
xmlns:r13="urn:3gpp:metadata:2005:MBMS:associatedProcedure-rel-13-extension"
xmlns:r14="urn:3gpp:metadata:2005:MBMS:associatedProcedure-rel-14-extension"
xmlns:sv="urn:3gpp:metadata:2009:MBMS:schemaVersion"
targetNamespace="urn:3gpp:metadata:2005:MBMS:associatedProcedure"
elementFormDefault="qualified"
version="2">
<xs:import namespace="urn:3gpp:metadata:2009:MBMS:schemaVersion" schemaLocation="schema-version.xsd"/>
<xs:import namespace="urn:3gpp:metadata:2005:MBMS:associatedProcedure-rel-12-extension" schemaLocation="adpd-rel-12-extension.xsd"/>
<xs:import namespace="urn:3gpp:metadata:2005:MBMS:associatedProcedure-rel-13-extension" schemaLocation="adpd-rel-13-extension2.xsd"/>
<xs:import namespace="urn:3gpp:metadata:2005:MBMS:associatedProcedure-rel-14-extension" schemaLocation="adpd-rel-14-extension.xsd"/>
<xs:element name="associatedProcedureDescription" type="associatedProcedureType"/>
<xs:complexType name="associatedProcedureType">
<xs:sequence>
<xs:element name="postFileRepair" type="basicProcedureType" minOccurs="0"/>
<xs:element name="bmFileRepair" type="bmFileRepairType" minOccurs="0"/>
<xs:element name="postReceptionReport" type="reportProcedureType" minOccurs="0"/>
<xs:element ref="r12:consumptionReport" minOccurs="0"/>
<xs:element ref="sv:schemaVersion"/>
<xs:element ref="r13:DASHQoEProcedure" minOccurs="0"/>
<xs:element ref="sv:delimiter"/>
<xs:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="basicProcedureType">
<xs:sequence>
<xs:element name="serviceURI" type="xs:anyURI" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="offsetTime" type="xs:unsignedLong" use="optional"/>
<xs:attribute name="randomTimePeriod" type="xs:unsignedLong" use="required"/>
</xs:complexType>
<xs:complexType name="bmFileRepairType">
<xs:attribute name="sessionDescriptionURI" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="reportProcedureType">
<xs:complexContent>
<xs:extension base="basicProcedureType">
<xs:attribute name="samplePercentage" type="xs:decimal" use="optional"
default="100"/>
<xs:attribute name="forceTimeIndependence" type="xs:boolean" use="optional"
default="false"/>
<xs:attribute name="reportType" use="optional" default="RAck">
<xs:simpleType>
<xs:union memberTypes="knownReportType xs:string"/>
</xs:simpleType>
</xs:attribute>
<xs:attribute ref="r14:reportInterval"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="knownReportType">
<xs:restriction base="xs:string">
<xs:enumeration value="RAck"/>
<xs:enumeration value="StaR"/>
<xs:enumeration value="StaR-all"/>
<xs:enumeration value="StaR-only"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
The following is the Release 12 extension of the XML syntax of associated delivery procedure description instances. The schema filename of this extension is "adpd-rel-12-extension.xsd".
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:3gpp:metadata:2005:MBMS:associatedProcedure-rel-12-extension" targetNamespace="urn:3gpp:metadata:2005:MBMS:associatedProcedure-rel-12-extension" elementFormDefault="qualified">
<xs:element name="consumptionReport" type="consumptionReportType"/>
<xs:complexType name="consumptionReportType">
<xs:sequence>
<xs:element name="serviceURI" type="xs:anyURI" maxOccurs="unbounded"/>
<xs:element name="location" type="uELocationType" minOccurs="0"/>
<xs:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="samplePercentage" type="xs:decimal" default="100"/>
<xs:attribute name="reportInterval" type="xs:duration"/>
<xs:attribute name="offsetTime" type="xs:unsignedLong"/>
<xs:attribute name="randomTimePeriod" type="xs:unsignedLong" use="required"/>
<xs:attribute name="reportClientId" type="xs:boolean" default="0"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
<xs:simpleType name="uELocationType">
<xs:union memberTypes="knownUELocationType xs:string"/>
</xs:simpleType>
<xs:simpleType name="knownUELocationType">
<xs:restriction base="xs:string">
<xs:enumeration value="CGI"/>
<xs:enumeration value="ECGI"/>
<xs:enumeration value="MBMS SAI"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
The following is the Release 13 extension of the XML syntax of associated delivery procedure description instances. The schema filename of this extension is "adpd-rel-13-extension.xsd".
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="urn:3gpp:metadata:2005:MBMS:associatedProcedure-rel-13-extension" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:3gpp:metadata:2005:MBMS:associatedProcedure-rel-13-extension" elementFormDefault="qualified">
<xs:element name="DASHQoEProcedure" type="DASHQoEProcedureType"/>
<xs:complexType name="DASHQoEProcedureType">
<xs:sequence>
<xs:element name="DASHQoEMetrics" type="xs:string"/>
<xs:element name="DASHQoESamplePercentage" type="xs:decimal" default="100" minOccurs="0"/>
<xs:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
</xs:schema>
The following is the Release 14 extension of the XML syntax of associated delivery procedure description instances. The schema filename of this extension is "adpd-rel-14-extension.xsd".
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="urn:3gpp:metadata:2005:MBMS:associatedProcedure-rel-14-extension" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:3gpp:metadata:2005:MBMS:associatedProcedure-rel-14-extension" elementFormDefault="qualified">
<xs:attribute name="reportInterval" type="xs:duration" use="optional"/>
</xs:schema>
9.5.2 Example Associated Delivery Procedure Description Instance
Below is an example of an associated delivery procedure description for reception reporting.
<?xml version="1.0" encoding="UTF-8"?>
<associatedProcedureDescription
xmlns="urn:3gpp:metadata:2005:MBMS:associatedProcedure"
xmlns:sv="urn:3gpp:metadata:2009:MBMS:schemaVersion"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:3gpp:metadata:2005:MBMS:associatedProcedure associatedprocedure.xsd">
<postFileRepair
offsetTime="5"
randomTimePeriod="10">
<serviceURI>http://mbmsrepair0.example.com/path/repair_script</serviceURI>
<serviceURI>http://mbmsrepair1.example.com/path1/repair_script</serviceURI>
<serviceURI>http://mbmsrepair2.example.com/path2/repair_script</serviceURI>
</postFileRepair>
<bmFileRepair sessionDescriptionURI="http://www.example.com/3gpp/mbms/session1.sdp"/>
<postReceptionReport
offsetTime="5"
randomTimePeriod="10"
reportType="StaR-all"
samplePercentage="100"
forceTimeIndependence="0">
<serviceURI>http://mbmsreport.example.com/path/report_script</serviceURI>
</postReceptionReport>
<sv:schemaVersion>1</sv:schemaVersion>
</associatedProcedureDescription>
9.5.3 XML Syntax for a Reception Report Request
Below is the formal XML syntax of reception report request instances. The schema filename of reception report request is receptionreport.xsd.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:3gpp:metadata:2008:MBMS:receptionreport"
xmlns="urn:3gpp:metadata:2008:MBMS:receptionreport"
elementFormDefault="qualified">
<xs:element name="receptionReport" type="receptionReportType"/>
<xs:complexType name="receptionReportType">
<xs:choice>
<xs:element name="receptionAcknowledgement" type="rackType"/>
<xs:element name="statisticalReport" type="starType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="rackType">
<xs:sequence>
<xs:element name="fileURI" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="fileUriType">
<xs:attribute name="clientId" type="xs:string" use="optional"/>
<xs:attribute name="sessionId" type="xs:string" use="optional"/>
<xs:attribute name="deviceId" type="xs:string" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="starType">
<xs:sequence>
<xs:element name="fileURI" type="fileUriType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="qoeMetrics" type="qoeMetricsType" minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="sessionType" type="sessionTypeType" use="optional"/>
<xs:attribute name="serviceId" type="xs:string" use="optional"/>
<xs:attribute name="clientId" type="xs:string" use="optional"/>
<xs:attribute name="deviceId" type="xs:string" use="optional"/>
<xs:attribute name="serviceURI" type="xs:anyURI" use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
<xs:simpleType name="sessionTypeType">
<xs:restriction base="xs:string">
<xs:enumeration value="download"/>
<xs:enumeration value="streaming"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="fileUriType">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="receptionSuccess" type="xs:boolean" use="optional" default="true"/>
<xs:attribute name="Content-MD5" type="xs:base64Binary" use="optional"/>
<xs:attribute name="receivedSymbolsForFailedBlocks" type="unsignedLongVectorType" use="optional"/>
<xs:attribute name="totalSymbolsForFailedBlocks" type="unsignedLongVectorType" use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="qoeMetricsType">
<xs:sequence>
<xs:element name="medialevel_qoeMetrics" type="medialevel_qoeMetricsType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="totalRebufferingDuration" type="doubleVectorType" use="optional"/>
<xs:attribute name="numberOfRebufferingEvents" type="unsignedLongVectorType"
use="optional"/>
<xs:attribute name="initialBufferingDuration" type="xs:double" use="optional"/>
<xs:attribute name="contentAccessTime" type="xs:double" use="optional"/>
<xs:attribute name="sessionStartTime" type="xs:unsignedLong"/>
<xs:attribute name="sessionStopTime" type="xs:unsignedLong"/>
<xs:attribute name="networkResourceCellId" type="stringVectorType" use="optional"/>
<xs:attribute name="numberOfLostObjects" type="unsignedLongVectorType"
use="optional"/>
<xs:attribute name="symbolCountUnderrun" type="stringVectorType" use="optional"/>
<xs:attribute name="numberOfReceivedObjects" type="unsignedLongVectorType"
use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
<xs:complexType name="medialevel_qoeMetricsType">
<xs:attribute name="sessionId" type="xs:string"/>
<xs:attribute name="totalCorruptionDuration" type="unsignedLongVectorType"
use="optional"/>
<xs:attribute name="numberOfCorruptionEvents" type="unsignedLongVectorType"
use="optional"/>
<xs:attribute name="t" type="xs:boolean" use="optional"/>
<xs:attribute name="totalNumberofSuccessivePacketLoss" type="unsignedLongVectorType"
use="optional"/>
<xs:attribute name="numberOfSuccessiveLossEvents" type="unsignedLongVectorType"
use="optional"/>
<xs:attribute name="numberOfReceivedPackets" type="unsignedLongVectorType"
use="optional"/>
<xs:attribute name="framerateDeviation" type="doubleVectorType" use="optional"/>
<xs:attribute name="totalJitterDuration" type="doubleVectorType" use="optional"/>
<xs:attribute name="numberOfJitterEvents" type="unsignedLongVectorType" use="optional"/>
<xs:attribute name="framerate" type="doubleVectorType" use="optional"/>
<xs:attribute name="codecInfo" type="stringVectorType" use="optional"/>
<xs:attribute name="codecProfileLevel" type="stringVectorType" use="optional"/>
<xs:attribute name="codecImageSize" type="stringVectorType" use="optional"/>
<xs:attribute name="averageCodecBitrate" type="doubleVectorType" use="optional"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
<xs:simpleType name="doubleVectorType">
<xs:list itemType="xs:double"/>
</xs:simpleType>
<xs:simpleType name="unsignedLongVectorType">
<xs:list itemType="xs:unsignedLong"/>
</xs:simpleType>
<xs:simpleType name="stringVectorType">
<xs:list itemType="xs:string"/>
</xs:simpleType>
</xs:schema>
9.5.3.1 Use of Specific Values
Void.
9.5.3.2 Example XML for the Reception Report Request
<?xml version="1.0" encoding="UTF-8"?>
<receptionReport xmlns="urn:3gpp:metadata:2008:MBMS:receptionreport"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:3gpp:metadata:2008:MBMS:receptionreport receptionreport.xsd">
<receptionAcknowledgement>
<fileURI>http://www.example.com/mbms-files/file1.3gp</fileURI>
<fileURI>http://www.example.com/mbms-files/file2.3gp</fileURI>
<fileURI>http://www.example.com/mbms-files/file4.3gp</fileURI>
</receptionAcknowledgement>
</receptionReport>
A second example shows a statistical report for a streaming session. Note that the cell used during the second measurement period is the same cell as was used during the first period (indicated by the "=" sign).
<?xml version="1.0" encoding="UTF-8"?>
<receptionReport xmlns="urn:3gpp:metadata:2008:MBMS:receptionreport"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:3gpp:metadata:2008:MBMS:receptionreport receptionreport.xsd">
<statisticalReport
clientId="clientID"
sessionType="streaming"
serviceURI="bmsc.example.com"
serviceId="serviceID">
<qoeMetrics
numberOfRebufferingEvents="0 1 0"
initialBufferingDuration="3.213"
totalRebufferingDuration="0 1.23 0"
contentAccessTime="2.621"
sessionStartTime="3428397714"
sessionStopTime="3428397741"
networkResourceCellId="240012AF134EA = 240012AF1325E">
<medialevel_qoeMetrics
sessionId="10.50.65.30:5050"
framerateDeviation="0.345 0.250 0.123"
t="false"
numberOfSuccessiveLossEvents="5 0 3"
numberOfCorruptionEvents="6 5 2"
numberOfJitterEvents="0 1 0"
totalCorruptionDuration="152 234 147"
totalNumberofSuccessivePacketLoss="25 0 6"
numberOfReceivedPackets="456 500 478"
codecInfo="H263-2000/90000 = ="
codecProfileLevel="profile=0;level=45 = ="
codecImageSize="176×144 = ="
averageCodecBitRate="124.5 128.0 115.1"
totalJitterDuration="0 0.346 0"/>
</qoeMetrics>
</statisticalReport>
</receptionReport>
9.5.4 XML Syntax for a Consumption Report Request
Below is the formal XML syntax of the consumption report request message. The schema filename of consumption report request is consumptionreport.xsd.
In this version of the the specification, the UE shall set the schemaVersion element, defined as a child of r12:consumptionReport element, to 1.
The schema version attribute (part of the schema instruction) shall be included in the UE schema.
NOTE: The value of the schemaVersion element and version attribute is intended to be increased by 1 in every future releases where new element(s) or attribute(s) are added.
When the network receives an instantiation of a consumption report request message compliant to this schema, it shall determine the schema version required to parse the instantiation as follows:
– If the network supports one or more versions of the consumption report request message schema with the schema version attribute, then it shall use the schema that has the highest schema version attribute value that is equal to or less than the value in the received schemaVersion element.
The XML schema "schema-version.xsd" is specified in Annex J.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="urn:3gpp:metadata:2014:MBMS:consumptionreport" xmlns:xs=http://www.w3.org/2001/XMLSchema
xmlns:sv="urn:3gpp:metadata:2009:MBMS:schemaVersion"
targetNamespace="urn:3gpp:metadata:2014:MBMS:consumptionreport" elementFormDefault="qualified" attributeFormDefault="unqualified"> version="1">
<xs:import namespace="urn:3gpp:metadata:2009:MBMS:schemaVersion" schemaLocation="schema-version.xsd"/>
<xs:element name="consumptionReport" type="consumptionReportType"/>
<xs:complexType name="consumptionReportType">
<xs:sequence>
<xs:choice>
<xs:element name="locationCGI" type="xs:string"/>
<xs:element name="locationECGI" type="xs:string"/>
<xs:element name="locationSAI" type="locationSAIType"/>
</xs:choice>
<xs:element ref="sv:schemaVersion"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="serviceId" type="xs:string" use="required"/>
<xs:attribute name="consumptionType" type="xs:unsignedByte" use="required">
<xs:annotation>
<xs:documentation>
1 – start of consumption of the MBMS User Service on the MBMS bearer;
2 – transition of UE consumption of the Service from unicast to MBMS bearer;
3 – stop of consumption of the MBMS User Service on the MBMS bearer;
4 – transition of UE consumption of the MBMS User Service from MBMS bearer to unicast;
5 – ongoing consumption of the MBMS User Service on the MBMS bearer upon the expiration of the ‘report interval’ timer;
6 – location change while consuming the MBMS User Service on the MBMS bearer;
7 – start of consumption of the MBMS User Service on the unicast;
8 – stop of consumption of the MBMS User Service on the unicast;
9 – ongoing consumption of the MBMS User Service on the unicast, upon the expiration of the ‘report interval’ timer;
10 – location change while consuming the MBMS User Service on the unicast
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="reportTime" type="xs:dateTime"/>
<xs:attribute name="clientId" type="xs:string">
<xs:annotation>
<xs:documentation>presence depends on the value of the ‘reportClientId’ attribute of the ‘r12:consumptionReport’ element in Associated Delivery Procedures Description </xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
<xs:complexType name="locationSAIType">
<xs:sequence>
<xs:element name="intraFreq-SAI" type="MBMS-SAI-List" minOccurs="0"/>
<xs:element name="interFreq-SAI" type="MBMS-SAI-List" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="intersection-SAI" type="MBMS-SAI-List" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="MBMS-SAI-List">
<xs:sequence>
<xs:element name="MBMS-SAI" type="xs:unsignedInt" maxOccurs="64"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
9.5.4.1 Example XML for the Consumption Report Request
<?xml version="1.0" encoding="UTF-8"?>
xsi:schemaLocation="urn:3gpp:metadata:2014:MBMS:consumptionreport consumptionreport.xsd" xmlns="urn:3gpp:metadata:2014:MBMS:consumptionreport" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xmlns:sv="urn:3gpp:metadata:2009:MBMS:schemaVersion">
<consumptionReport serviceId="urn:examplecom:1234567890hotdog" consumptiontype="1" reportTime="2014-08-04T09:30:47Z" clientId="9410788021">
<locationCGI>12345</locationCGI>
<sv:schemaVersion>1</sv:schemaVersion>
</consumptionReport>