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.

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.

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.

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.

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.

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 clause 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

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/1.1 protocol specified in RFC 9112). 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 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. 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 Message.

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 request method GET as specified in RFC 9112. Further arguments are encoded into the URI query part (RFC 3986) 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: 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 RFC 9112]

• 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 RFC 3986.
• 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 Section 3.4.1 of RFC 3926 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

In this message format, the MBMS UE uses the conventional HTTP/1.1 GET or partial GET requests as specified in RFC 9112 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 specified in Section 14.2 of RFC 9110. The MBMS UE shall indicate the specific source symbols or sub-symbols as a bytes range specifier as specified in Section 14.1.2 of RFC 9110. 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, as specified in Section 13.1.1 of RFC 9110 and Section 13.1.5 of RFC 9110, respectively. 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: 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 "http://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: 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 replies with a 412 "Precondition Failed" reply. Otherwise, the server satisfies the request and replies 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: 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 http://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: 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:

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 five response scenarios:

• The server returns a repair response message where a set of encoding symbols forms an HTTP payload as specified below (see clause 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 clause 9.3.7.2a for details).
• The server returns the requested file or file groups (see clause 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 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.

The response codes of HTTP servers to the byte-range-based repair request message in clause 9.3.6.2 are specified in Section 15 of RFC 9110. The response codes of symbol-based file repair servers to the symbol-based repair request message in clause 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 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 clause 9.3.7.3. Other HTTP status codes specified in Section 15 of RFC 9110) 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. 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 HTTP/1.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 per RFC 5234 as follows: Note that the following error messages MAY be used in the message body of the HTTP response error messages.

The format of the response message to the symbol-based repair request message in clause 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).

The Content-Type response header 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

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 of 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 9.3.7-1 illustrates the complete file repair response message format (box sizes are not indicative of the relative lengths of the labelled entities).

Length Indicator (2 bytes): FEC Payload ID: Encoding Symbols:

The response message to the byte-range-based repair request message in clause 9.3.6.2 follows the format and procedures specified in Section 14.4 of RFC 9110 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 range-resp to indicate the byte range of the repair data as specified in Section 14.4 of RFC 9110. 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 Section 14.6 of RFC 9110.

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 clause 9.3.7.2 or clause 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 Associated Delivery Procedures Description (see clause 9.5) 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 Associated Delivery Procedures Description 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.

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

The server shall encapsulate the requested files into a multipart MIME container. Each part of the multipart MIME container shall contain at least the Content-Location of the embedded files.

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.

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

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 GET method as specified in RFC 9112. The FDT Instance is identified in the response by the MIME media 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 Message formats specified in clauses 9.3.6.1 and 9.3.6.2, respectively.