Content for  TS 26.346  Word version:  19.1.0

The semantics of a Session Description of an MBMS download session includes the following parameters:

• The sender IP address.
• The number of channels in the session.
• The destination IP address and port number for each channel in the session per media.
• The Transport Session Identifier (TSI) of the session.
• The start time and end time of the session.
• The protocol ID (i.e. FLUTE/UDP).
• Media type(s) and fmt-list.
• Data rate using existing SDP bandwidth modifiers.
• Mode of MBMS bearer per media.
• FEC capabilities and related parameters.
• Service-language(s) per media.
• QoE Metrics (as defined in clauses 8.3.2.1 and 8.4).
• Alternative TMGI

This list includes the parameters required by FLUTE in RFC 3926 These shall be expressed in SDP (RFC 4566 and RFC 4570) syntax according to the following clauses.

There shall be exactly one IP sender address per MBMS download session, and thus there shall be exactly one IP source address per complete MBMS download session SDP description. The IP source address shall be defined according to the source-filter attribute ("a=source-filter:") (RFC 4566 and RFC 4570) for both IPv4 and IPv6 sources, with the following exceptions:

1. Exactly one source address may be specified by this attribute such that exclusive-mode shall not be used and inclusive-mode shall use exactly one source address in the <src-list>.
2. There shall be exactly one source-filter attribute per complete MBMS download session SDP description, and this shall be in the session part of the session description (i.e. not per media).
3. The * value shall be used for the <dest-address> subfield, even when the MBMS download session employs only a single LCT (multicast) channel.

Only one FLUTE channel is allowed per FLUTE session in the present document and thus there is no further need for a descriptor of the number of channels.

The FLUTE channel shall be described by the media-level channel descriptor. These channel parameters shall be per channel:

• IP destination address.
• Destination port number.

The IP destination address shall be defined according to the "connection data" field ("c=") of SDP RFC 4566. The destination port number shall be defined according to the <port> sub-field of the media announcement field ("m=") of SDP RFC 4566. The presence of a FLUTE session on a certain channel shall be indicated by using the "m-line" in the SDP description as shown in the following example:

• m=application 12345 FLUTE/UDP 0
• c=IN IP6 FF1E:03AD::7F2E:172A:1E24/1

In the above SDP attributes, the m-line indicates the media used and the c-line indicates the corresponding channel. Thus, in the above example, the m-line indicates that the media is transported on a channel that uses FLUTE over UDP. Further, the c-line indicates the channel address, which, in this case, is an IPv6 address.

The combination of the TSI and the IP source address identifies the FLUTE session. Each TSI shall uniquely identify a FLUTE session for a given IP source address during the time that the session is active, and also for a large time before and after the active session time (this is also an LCT requirement - see RFC 3451). The TSI shall be defined according the SDP descriptor given below. There shall be exactly one occurrence of this descriptor in a complete FLUTE SDP session description and it shall appear at session level. The syntax in ABNF is given below:

• flute-tsi-line = "a=flute-tsi:" tsi CRLF
• tsi = 1*15DIGIT

RFC 3926 requires the use of the Transport Object Identifier (TOI) header field (with one exception for packets with no payload when the A flag is used). The transport of a single FLUTE file requires that multiple TOIs are used (TOI 0 for FDT Instances). Thus, there is no further need to indicate to receivers that the session carries packets for more than one object and no SDP attribute (or other FLUTE out of band information) is needed for this.

A MBMS download session start and end times shall be defined according to the SDP timing field ("t=") RFC 4566.

A new MBMS bearer mode declaration attribute is defined which results in, e.g.:

• a=mbms-mode:broadcast 123869108302929 1
• OR
• a=mbms-mode:broadcast-mbsfn 123869108302929

The MBMS bearer mode declaration attribute shall be used in session descriptions using one or more MBMS broadcast mode media or broadcast-mbsfn mode media. If all media declarations use MBMS broadcast mode or broadcast-mbsfn mode, then the SDP attribute may be declared at session level. In that case the session level attribute applies to all media without a media level occurrence of the "mbms-mode" attribute. If one or more media using MBMS multicast mode is present in the same declaration as media using MBMS broadcast mode, then only media using the MBMS broadcast mode or broadcast-mbsfn mode will contain the "mbms-mode" attribute.

• mbms-bearer-mode-declaration-line = "a=mbms-mode:" ("broadcast" SP tmgi SP mbms-counting-information) / ("broadcast-mbsfn" SP tmgi) CRLF
• tmgi = 1*15DIGIT
• mbms-counting-information = 1 * DIGIT

Please find below an example of the building of the TMGI: The Temporary Mobile Group Identity (tmgi) information element is defined in TS 24.008 including the coding of the fields. Octets 3 to 8 (MBMS Service ID, MCC and MNC) shall be placed in the tmgi attribute of the MBMS bearer mode declaration line, and are encoded as a decimal number. Octet 3 is the most significant octet. As this is encoded as a decimal number, leading zeros of the MBMS Service ID field may be omitted. The MBMS Counting Information (mbms-counting-information) information element is defined in TS 25.413 and indicates whether the RAN level counting procedures are applicable or not for the MBMS broadcast mode. The value 0 corresponds to the information element value of "not counting" and the value 1 corresponds to the information element value "counting". If the MBMS bearer mode declaration attribute is applied at the session level, there shall be exacly one instance of MBMS bearer mode declaration attribute in the Session Description.

A new FEC-declaration attribute is defined which results in, e.g.:

• a=FEC-declaration:0 encoding-id=1

This attribute may be used on both session-level and media-level. Multiple instances are allowed to specify several different FEC declarations. The attribute is used on session level to define FEC declarations used by multiple media components. On media level it is used to define FEC declarations which are only valid for a single media component. If FEC declarations on both session and media level use the same reference number (fec-ref) then the media level declaration takes precedence for that media component. Each media component references one FEC declaration using the "a=FEC" attribute. This attribute is optional to use for the download delivery method as the information will be available elsewhere (e.g. FLUTE FDT Instances). If this attribute is not used, and no other FEC-OTI information is signalled to the UE by other means, the UE may assume that support for FEC id 0 is sufficient capability to enter the session. A new FEC-declaration reference attribute is defined which results in, e.g.:

• a=FEC:0

This is a media-level only attribute, used as a short hand to reference one of one or more FEC-declarations. The syntax for the attributes in ABNF RFC 5234 is:

• fec-declaration-line = "a=FEC-declaration:" fec-ref SP fec-enc-id [";" SP fec-inst-id] CRLF
• fec-ref = 1*3DIGIT ; value is the SDP-internal identifier for FEC-declaration.
• fec-enc-id = "encoding-id=" enc-id
• enc-id = 1*DIGIT ; value is the FEC encoding ID used
• fec-inst-id = "instance-id=" inst-id
• inst-id = 1*DIGIT ; value is the FEC Instance ID used.
• fec-line = "a=FEC:" fec-ref CRLF

The existing SDP attribute "a=lang" is used to label the language of any language-specific media. The values are taken from RFC 4646 which in turn takes language and (optionally) country tags from ISO 639 [74] and ISO 3166 [75] (e.g. "a=lang:EN-US"). These are the same tags used in the User Service Description XML.

The maximum bit rate required by this FLUTE session shall be specified using the "AS" bandwidth modifier RFC 4566 on media level. The Application Specific (AS) bandwidth for a FLUTE session shall be the largest sum of the sizes of all packets transmitted during any one second long period of the session, expressed as kilobits. The size of the packet shall be the complete packet, i.e. IP, UDP and FLUTE headers, and the data payload.

The "FEC-redundancy-level" declaration attribute is defined in the form:

• a=FEC-redundancy-level:<fec-ref> <fec-redun-lev>,

This attribute is associated with the FEC-declaration attribute defined in clause 7.3.2.8, with the same <fec-ref> field value. It may be used at the session or media level, and declares the redundant level of FEC protection, as a percentage, applied to the media component(s) carried on the associated MBMS download session. For example, a FEC redundancy level of 40% means that for an FEC-encoded block of K symbols, 1.4*K symbols are broadcast over the air. The applicability of the FEC redundancy level parameter, at the session or media level, mirrors the session- or media-level use of the corresponding FEC-declaration attribute with the same <fec-ref> value. The FEC-redundancy-level attribute is optional to use as a FEC declaration. The syntax for this attribute, expressed in ABNF per RFC 5234, is as follows:

• <fec-ref> is as defined in clause 7.3.2.8,
• <fec-redun-lev> = "redundancy level=" <redun-lev>, and
• <redun-lev> = 1*3DIGIT; represents the redundant amount of FEC protection applied to the file object, expressed as an integer percentage value.

In the event that both the FDT extension attribute "FEC-Redundancy-Level" as defined in clause 7.2.16, and the SDP FEC redundancy level indication are present, the declaration in the FDT shall take precedence from the UE processing perspective.

An alternative TMGI declaration attribute is defined at the session level with the following ABNF RFC 5234 syntax:

• "a=alternative-tmgi:" tmgi-list CRLF
• tmgi-list = tmgi *("," tmgi)
• tmgi = 1*15DIGIT

The content(s) of an MBMS User Service may be delivered simultaneously in multiple PLMN areas, over different MBMS bearer service instances (each identified by a unique TMGI). In this case, the alternative-tmgi attribute shall be present at the session level and lists all alternative values to the TMGI contained in the session-level MBMS bearer mode declaration attribute, used for the broadcast of the FLUTE session data. When this attribute is present, the UE shall determine that the service is available at its current location, upon detecting a match between the TMGI derived from the PLMN-ID representing its current location, with one of the TMGIs from the following list:

• The set of TMGI values comprising the default TMGI in the MBMS bearer mode declaration attribute and
• the TMGIs contained in the alternative-tmgi attribute.

Absence of a match shall be an indication to the UE that the service not available at its current location. The alternative-tmgi declaration attribute is optional. It is not a replacement for the MBMS mode declaration attribute as defined in clause 7.3.2.7. In addition to the MBMS mode declaration attribute (which is the default TMGI), at most a single instance of the alternative-tmgi declaration attribute shall be present in the Session Description. The same definition of the Temporary Mobile Group Identity (tmgi) as used in clause 7.3.2.7 shall be applied.

For the MBMS download delivery method, the <proto> field of the media descriptions ("m=") line of the SDP shall be set to 'FLUTE/UDP'.

For the MBMS download delivery method, the media type and format list information shall be set in the "m=" line of the SDP as follows. The <media> field shall be set to 'application' and the <fmt> field shall be set to '0'.

As a child element of deliveryMethod, each instance of r12:broadcastAppService denotes all resources that are available over broadcast, i.e. the resources are carried over the MBMS bearer. Each entry of basePattern under all r12:broadcastAppService element(s) is for use by the MBMS Client to match against a portion of the entire resource URL used by the application to request files. A match implies that the corresponding requested resource is carried over an MBMS bearer. For example in DASH over MBMS, should the URL associated with a Segment request contain the BaseURL "http://example.com/per-3/rep-512", and the same BaseURL value were to appear in an instance of r12:broadcastAppService.basePattern, it means that the Representation with Representation@id = '512' is available over broadcast. The basePattern value may, but is not required to, be identical to that of the Representation.BaseURL if present in the MPD. In addition, each r12:broadcastAppService element may contain one or more serviceArea child elements which specify the service area(s) in which the associated broadcast resources (as identified by basePattern) is delivered/accessible. The semantics of serviceArea complies to the MBMS Service Area Identity as defined in TS 23.003 and TS 36.443. A given broadcast resource may be available in a set of service area(s) in common with, or different from, the service area(s) of any other broadcast resources. Absence of the serviceArea element implies that the availability of the broadcast resources is not restricted by service area. The serviceArea element(s) that may be present in one instance of r12:broadcastAppService element must be a subset of the MBMS Service Area Identities included in the userServiceDescription.availabilityInfo.infoBinding.serviceArea elements for the same serviceId. When one or more serviceArea element(s) are included under one or more r12:broadcastAppService, the union of all the MBMS Service Area Identities identified by the serviceArea elements under all the r12:broadcastAppService must match the list of MBMS Service Area Identities included in the userServiceDescription.availabilityInfo.infoBinding.serviceArea elements for the same serviceId.

The deliveryMethod element may also include one instance of the r12:unicastAppService element that denotes unicast resources that are redundant to resources available as broadcast resources. Similar to r12:broadcastAppService, each entry of basePattern element under the r12:unicastAppService element is for use by the MBMS Client to match against a portion of the entire file URL used by the application to request files provided in the application service document. A match implies that the associated file is available over unicast delivery, but if broadcast resources are available to the application service, then these resources are of no additional benefit for the user experience. Typically, such resources are particularly relevant in case broadcast resources are not available and the MBMS Client may provide these resources for unicast fallback and service continuity. For example for DASH over MBMS, should the URL associated with a Segment request contain the BaseURL "http://example.com/per-3/rep-256", and the same BaseURL value were to appear in an instance of r12: unicastAppService.basePattern, it means that the Representation with Representation@id = '256' is available over unicast. The basePattern value may, but is not required to, be identical to that of the Representation.BaseURL if present in the MPD.

The deliveryMethod element may also include one or more instances of the r15:supplementaryUnicastAppService element to denote one or more available unicast resources which are supplemental to resources provided on broadcast, i.e. they provide an additional user experience. Similar to r12:unicastAppService, each entry of the basePattern element child of the r15:supplementaryUnicastAppService element typically represents a media component delivered over unicast, but with the difference that the information is not redundant and therefore is expected to also be of benefit for the application service when in broadcast coverage.

A given resource may be delivered/available over one or both transport modes. The broadcast version might be deemed as preferable or even required for reception, for example, in accordance with service provider policy pertaining to location of the UE with respect to MBMS coverage. Based on user preference, and when the UE is in broadcast coverage, the UE may receive media resources delivered over broadcast, as well as additional resources delivered over unicast under r15:supplementaryUnicastAppService. The presence of the r12:broadcastAppService and/or r12:unicastAppService element under deliveryMethod signifies that the parent MBMS User Service is an application service which contains resources delivered via broadcast and/or unicast modes. One or both of these child elements of deliveryMethod must be present when its parent userServiceDescription element contains the r12:appService element (see clause 7.6.3).

Presence of the r12:appService child element of userServiceDescription indicates that the associated MBMS User Service is an application service explicitly linked to the r12:broadcastAppService and r12:unicastAppService elements under deliveryMethod. The r12:appService element may contain either or both the child elements identicalContent and alternativeContent. r12:appService also has the attributes appServiceDescriptionURI and mimeType.

Each identicalContent element under userServiceDescription contains two or more interchangeable URLs, as indicated by the basePattern values, for the same resources. The implication is that the resource could be interchanged in accordance to coverage condition, policy requirements, etc.

Each alternativeContent element under userServiceDescription contains two or more interchangeable URLs, as indicated by the basePattern values, corresponding to different resources available over broadcast and unicast transport but which could be substituted for one another in accordance to coverage condition, policy requirements, etc. In practical deployment of a DASH-over-MBMS service, eligibility for such switching may additionally require the following conditions to be met:

1. the employed media codecs and configuration information must be identical between the requested and substituted Representations,
2. the request does not contain a byte range, and
3. Segments of the alternative Representations must be time-aligned.

The UE may support the processing of the alternativeContent element. identicalContent and/or alternativeContent may be present under the r12:appService element because Representations listed in the MPD may be encoded differently, or associated with different configurations for a given encoding scheme, as defined by their Initialization Segments (represented by Initialization Segment Description fragments). Therefore, the mere presence of basePattern entries under r12:broadcastAppService and r12:unicastAppService does not imply that the associated Representations are automatically eligible for interchange between broadcast and unicast reception. The alternativeContent element shall not be present if the application service is not DASH-over-MBMS.

The attribute appServiceDescriptionURI of r12:appService references an Application Service Deescription which may be a Media Presentation Description fragment corresponding to a unified MPD. In this case, the attribute mimeType of r12:appService specifies the MIME type of the MPD, which may include the optional 'profiles' parameter. The latter parameter declares the interoperability and signals the use of features associated with the DASH Media Presentation described by this MPD. An example value of mimeType is the string "application/dash+xml;profiles=urn:3GPP:PSS:profile:DASH10", which denotes an MPD conforming to the 3GP-DASH Release-10 profile. Other types of Application Service Description fragments may be supported. A UE compliant with this specification shall ignore the r12:appService element whose mimeType attribute value is not supported by the UE.

An application using HTTP GET requests to retrieve files may include in the GET request, the 'Accept' request header as defined in RFC 7231, along with a new 3GPP-defined media type 'application/3gpp-partial'. By providing this header and issuing such a partial-file-accept request, the application signals that is capable to receive partial file responses as defined in clause 7.9.2.2. An example of the use of such Accept header is: In this example, the application indicates that it will accept all media types in the response, as well as the specific "incomplete" type designated by application/3gpp-partial.

If the MBMS Client receives a regular HTTP GET request that includes the 'Accept' header but which does not contain media type 'application/3gpp-partial', and the MBMS Client has received a partial file with at least one byte, it should respond with HTTP/1.1 404 Not Found, and include in the response the 'Content-Type' header set to 'application/3gpp-partial'.

• The response code shall be set to 200 OK
• The Content-Type header shall be set to application/3gpp-partial.
• The message body is a multipart message body shall be exactly the same format as the multipart/byteranges media type as described in Appendix A of RFC 7233. The multipart/byteranges media type includes one or more body parts, each with its own Content-Type and Content-Range fields as the means to convey the byte range(s) of the partial file being returned. Each Content-Type header shall be set to the value of the Content-Type provided in the FDT Instance for this file. An extension header may be added 3gpp-access-position providing a byte position at which the handler of assigned to the Content-Type of the file may access the file. The value may be created from the mbms2015: IndependentUnitPositions, if present.
• A cache directive should be included in the response to prevent any intermediate proxies from storing an incomplete file and serving it to another application. Example for such cache directive are "Cache-Control: max-age=0" or "Cache-Control: no-cache"

If the MBMS Client receives a partial-file-accept request, and the MBMS Client has received a partial file with no bytes (i.e. only the FDT Instance describing the file metadata is received), then the MBMS Client may respond with a partial file response defined as follows:

• The response code shall be set to 416 Requested Range Not Satisfiable
• The Content-Type header shall be set to the value of the Content-Type provided in the FDT Instance for this file.
• The Content-Range shall be set to bytes */Content-Length with Content-Length the value of the attribute Content-Length provided in the FDT Instance for this file.

As an example, assume the Media Segment of interest is identified by the URL: "http://www.example.com/Period-2012-08-04T08-45-00/rep-xyz12345/seg-777.3gp". In addition, the client is willing to receive the incomplete portion of the Segment (777) available at the Server when the request is received. The DASH client sends the partial-accept request as follows: Assume that the server receives the above GET request for Segment 777, and it has the following sets of byte ranges of the requested Segment of size 256000 bytes at the time it receives the request: 0-19999, 50000-85000, 105500-199888, and 201515-229566. Due to the presence of the specific Accept header in the request, the server will return the partial Segment via the 200 response, by indicating the same content type for the message body as indicated in the request (i.e., application/3gpp-partial), but whereby the message body is constructed identically to the multipart/byteranges format. In addition, the response header Cache-Control: no-cache may be included in the response to prevent downstream caching of the message. The server's response in this case is shown below: As an extension to the example, assume that the first byte range is lost as well and FDT Instance contains an mbms2015:IndependentUnitPositions attribute with value "0 60000 80000 110000": The server's response in this case is shown below:

Independent Units may be signalled in the File entry of an FDT Instance using the attribute mbms2015: IndependentUnitPositions. The FDT Instance signaling is defined in clause 7.9.3.2. MBMS Clients that support partial file handling may also support the handling of independent units. The details of handling independent units are provided in clause 7.9.2.

Independent Units represent a non-empty list of byte locations, each of which is the location of the first byte of an Independent Unit. An Independent Unit is the chunk of bytes between two consecutive entries in the IndependentUnitPositions list, except for the last Independent Unit which ranges from the last entry in the list to the end of the file. The position of an Independent Unit is the byte position in the file, at which the handler assigned to the Content-Type for the file may access the file. If Independent Units are signalled in the FDT Instance, the following restrictions apply:

• The attribute mbms2015: IndependentUnitPositions shall not be used in combination with the use of the Content-Encoding.
• The generation of the IndependentUnitPositions values is beyond the scope of the present document.

The XML syntax of the IndependentUnitPositions attribute within the FLUTE FDT is specified in Listing 7.2.10.2-6, and the attribute is further referred to by the main FDT schema of clause 7.2.10.1.