的表示是可以被访问的。在这种情况下，DASH 客户端可能被限制为从通过广播传递可用的备选的表示中进行选择（或重定向或被指示 选择）。
[0159] 在另一个例子中，UE可能位于MBMS覆盖内，并且DASH客户端可以请求已知为在 多播传递上可用的表示。在这种情况下，所期望的表示可以由UE直接访问。
[0160] 在另一个例子中，UE可能位于MBMS接收区域之外，并且DASH客户端可以请求已 知为仅在广播传递上可用的表示。在这种情况下，DASH客户端可以被限制为从以可切换内 容的形式的、在单播传递上可用的备选的表示中进行选择（或重定向或被指示选择）。
[0161] 在另一个例子中，UE可能位于MBMS接收区域之外，并且DASH客户端可以请求也 已知为在广播传递上可用的表示。在这种情况下，DASH客户端可能能够在单播上接收以完 全相同的内容的形式的、同一表示。
[0162] 可以在USD中携带的额外信息包括对服务区域的指示，在其上，每个表示被输送， 和/或包括SDP的标识，所述SDP描述携带所述表示的FLUTE会话。
[0163] 本公开内容描述了一种技术，通过所述技术，可以将 mediaPresentationDescription2 子元素添加在userServiceDescription之下，以携带客页 外的传输参数。此前，提议了MPD-特定参数，如包含在mediaPresentationDescription2 中的时段ID、适应集ID和RepresentatationID，其可以识别在单播传递上可用的那些表 示。这些相同的参数，连同对会话描述片段的URI引用，可以识别能够在广播上传递的每个 表示，以及到携带该表示的段的、FLUTE会话的映射。
[0164] 该本公开内容的技术可以克服的一个问题是使得能够使用HTTP/1. 1作为DASH客 户端和MBMS客户端之间的协议接口以用于段请求/响应，同时在协议处理中维持干净的分 层分离。例如，在以前的技术中，MBMS客户端必须处理MPD-特定信息，所述MPD-特定信息 能够将针对特定表示的段的DASH客户端请求纠正为实际可用的、由传输模式（广播或单 播）所准许（例如，根据服务提供商策略）的表示段。在所请求的表示不能被提供的情况 下，为了使MBMS客户端使用HTTP重定向（经由3xx响应代码，如在1999年6月Fielding 等人"HypertextTransferProtocol-HTTP/1.1"，网络工作组RFC2616 中定义的，其在 http://www.ietf.org/rfc/rfc2616.txt可获取）以通知DASH客户端一个或多个可替代表 示，该MBMS客户端将不得不针对每个可替代资源构成完整的段URI。关于MBMS客户端部分 的分层冲突可以通过使用本公开内容的技术来消除。
[0165] 本公开内容的技术省略了MBMS客户端（或代理单元）要知道或必须处理（DASH特 定）MH)信息的必要。该MBMS客户端基于USD中的新的元数据的出现以及与由DASH客户 端生成的段请求URI，仅执行数据/模式匹配，来确定所请求的段是在广播上可用、单播上 可用、两种传输模式上都可用或都不可用，或通过一些其它方式（例如，高速缓存存储器） 可用。这是可能的，因为USD中还提供了唯一地标识所请求的段属于的表示的、请求URI的 部分。此外，MBMS客户端可以通过USD中的匹配数据模式的位置，来确定由DASH客户端 (其对传输模式是不可知的）请求的表示是在广播、单播，两种传输模式上都或都不可用， 或通过一些其它方式（例如，高速缓存存储器）可用。与任何其他有关规则和条件，例如 覆盖状况（UE是在单播和/或广播服务区域），服务提供商策略等相结合，并基于USD属性 replacementAllowed= '真'，假设用于返回可替代资源URI替代方法是允许的。该MBMS 客户端可以使用HTTP/1. 1机制来将段请求调解给适当的资源，例如UE中的本地内容高速 缓存器，或外部HTTP服务器，而不具有经协议分层冲突。
[0166] 如在图14A和14B的例子中可以看出，所述一个或多个广播代表中的每个在USD 中由broadcast元素的唯一baseUrl属性识别。baseURL值可能与DASH客户端用于请求 表示的段的段URI是相同的，具体而言，与该段URI的起始部分是相同的，其从该方法开始， 并延伸至并且包括该RepresentationID。例如，如果该段的URI是111?1/'111^卩:/761311^|16· com/per-3/rep-512/seg-99.3gp，"对应于时段 3 中的表不 512(RepresentationID= 512) 的段 99,则baseURL可以被定义为 "http://example.com/per_3/rep-512"。
[0167] 在本例子中，所述一个或多个广播代表中的每个在USD中由broadcast元素的 唯一baseUrl属性识别。Broadcast的每个实例映射至在MBMS承载上传递的唯一的表 示。其baseUrl将与DASH客户端用于请求段的段URI进行比较，具体而言，与该段URI的 起始部分进行比较，其从URI方案开始，并延伸至并且包括该Representation-ID(MPD中 的R印resentationOid的值）。例如，假设DASH客户端发出的段URI是URL"http: // example.com/per-3/rep-512/seg-99. 3gp"，对应于针对时段 3(Period@id= 3"）中的表不 512(Representation@id= 512)的段99的请求。出于与USD匹配的目的，所关心的该URL 的部分是"http://example.com/per-3/rep-512。在该表示在广播上也是可用的情况下， mediaPresentationDescription2.broadcast的实例将在USD中具有由"http://example. com/per-3/rep-512"给出baseURL，其与请求URI的感兴趣部分是相同的。
[0168] 在MBMS客户端确定了DASH客户端所请求的、仅可替代表示是可用的情况下， mediaPresentationDescription2 的replacementAllowed属性可以指不MBMS客户端是否 以及如何经由HTTP重定向（3xx状态码）方法向DASH客户端提供这种通知，如在RFC2616 中定义的。
[0169] 例如，如果replacementAllowed="真"，可以假定DASH内容和MPD以这种方式被 撰写：允许MBMS客户端经由"303见其他"重定向来向DASH客户提供可替代资源URI，而不 考虑可替代表示的传输模式。具体地，每个可替代URI可能是通过替换段URL中的感兴趣 部分来形成的，如以上利用对应于可替代表示的USD中的baseURL来描述的，而同时在原始 请求中保留段号。
[0170] 另一方面，如果replacementAllowed= "假"，则用于生成可替代资源URI并将其 提供给DASH客户端的这种替换方法是不允许的。导致要被请求和传递的可替代表示的、 所产生的技术可能是依赖于实现的（例如，MBMS客户端可能会返回伴随有或没有可替代表 示的4xx错误代码，其是由baseURL值以信号形式发送的，并依赖于DASH客户端来形成可 替代请求）。下面关于图15和16,基于HTTP'303'重定向描述了示例性调用流程，示出了 MBMS客户端和DASH客户端之间的交互。
[0171] 类似地，零个或多个单播表不中的每个在USD中由mediaPresentationDescription2. unicast元素的唯一baseUrl属性识另丨」。如上所讨论的，在请求的URL的相同部分与单播baseURL 的匹配模式意味着该表示在单播传递上是可用的。要注意的是，同一表示可以在两个传输 模式都是可用的、在仅一个传输模式上是可用的或两个传输模式上都不是可用的。
[0172] 另外，经由sessionDescription元素，每个广播表示可以链接到会话描述片段或 涉及携带所述表示的FLUTE会话的SDP文件。此外，serviceArea元素（如果存在的话）， 可以指示广播表示在其上可用的MBMS服务区域。
[0173] 图15是示出了用于支持MBMS上的DASH的架构的概念图。图15的例子表示用于 MBMS承载上的具有单播回退的DASH内容传递的端到端网络架构。基于FLUTE的下载传递 表示BM-SC和MBMS客户端之间的TS26. 346定义的接口。DASH客户端和MBMS客户端之间 的假定接口（这里假定为包括MBMS接收机、基于设备的HTTP服务器、策略、重定向和代理 功能的复合实体）是HTTP/1. 1。
[0174] 图16是示出了与图15的网络架构相关联的、用于广播和单播传输上的DASH内容 传送的呼叫流程。相对于图16所描述的技术基于图14A和14B中所示出的USD扩展以用于 携带DASH传输信息。虽然被描述为对应于图15的网络架构，但应该理解的是，图16的技术 可以由其它设备来执行，所述其他设备例如图1、2A、2B、6、7、8和/或17的架构中的设备。在 图16的例子中，假定USD包含表3中所示的信息，其在mediaPresentationDescription2. broadcast和mediaPresentationDescription2.unicas之下包括baseURL属性的值，并且 假设USD中的replacementAllowed属性的值为"真"。
[0175] 表 3
[0176]
[0177] 此外，在该例子中，假定MPD包括以下内容：
[0178] ·MPDOtype= 'dynamic'
[0179] ·PeriodOid= '3'
[0180] ·Period.SegmentTemplateimedia=
[0181] ^http://example.com/per-3/rep-$RepresentationID$/seg-$Number$. 3gp?
[0182] oRepresentationOid= '512' …
[0183] oRepresentationOid= '256' …
[0184] oRepresentationOid= '128' …
[0185] 给定这些示例性MPD参数值，尝试请求针对Period3中的表示512的段no. 99的 DASH客户端可以发布以下请求URI:http://example.com/per-3/rep-512/seg-99. 3gp。图 16的呼叫流程图描述了针对两种不同情况的DASH内容传递：（1)UE位于MBMS覆盖区域，并 且请求Period3中的表示512的段，其在广播传送上时可用的，以及随后，（2)UE移出MBMS 区域，并且继续请求同一表示（Representation512)，其在单播传送上时不可用的，但表示 256和128在单播上是可用的。
[0186] 换句话说，本公开内容描述了某些技术，所述技术用于支持传输分集的DASH传输 的基于USD的信令的使用。其可以在从高通公司的"RationaleforUSDIndicationof DASHDeliveryModeandIllustrativeImplementation"TdocS4-130051 中描述的先前 提议上提供一个或多个改进。例如，在该方法中，可以完全避免分层冲突，这是因为MBMS客 户端不必理解或处理MH)信息。相反，MBMS客户端可以针对由DASH客户端所请求的段的 URI来执行已知传输语义的数据模式匹配，以确定所请求的段是否请求经由广播和/或单 播来递送，并且该请求是否满意或者需要被重定向至同一表示或使用另一种传输模式可用 的可替代表示。
[0187] 这种确定可以基于诸如以下因素：UE是位于MBMS覆盖内部还是外部、服务提供商 策略（如果有的话）、由传输模式来管理表示的可访问性，以及可能地依赖于其他条件或规 贝1J。提供了针对经由MBMS具有单播回退的DASH内容递送的示例性网络架构和呼叫流程图， 以说明端到端的内容递送，其以DASH客户端和MBMS客户端之间的HTTP协议接口的使用为 特点。坚持分层协议应该提供在支持MBMS服务中的DASH中的、UE实现的可扩展性和简单 性的架构益处。
[0188] 在具有值为"真"的mediaPresentationDescription2 的replacementAllowed属 性上预测了经由3xx状态代码由MBMS客户端使用HTTP重定向以限制DASH客户端访问可 替代资源（表示）。在这种情况下，假设DASH内容和MPD以如下方式被撰写：允许MBMS客 户端经由"303见其他"重定向来向DASH客户提供可替代资源URI，而不考虑可替代表示的 传输模式。具体地，每个可替代URI是通过替换段URL中的感兴趣部分来形成的，如以上利 用对应于可替代可替代表示的USD中的baseURL来描述的，而同时保在原始请求中保留段 号。如果replacementAllowed的值="假"，则用于生成可替代资源URI并将其提供给DASH 客户端的这种替换方法是不允许的。
[0189] 导致要被请求和传递的可替代表示的所产生的技术可能是依赖于实现的。例如， MBMS客户端可能会返回伴随有或没有可替代表示的4xx错误代码，其是由HTTP响应的实体 主体中的baseURL值以信号形式发送的，并依赖于DASH客户端来形成可替代请求。此处，用 于在响应中识别可替代的表示是可用的baseURL的存在可以用作对DASH客户端的提示，其 提示DASH客户端具有后续直接请求所述表示的智能。可替代地，baseURL可能不会在4xx 响应中提供"提示"，或DASH客户端可能缺乏利用这种提示来生成对另一个表示的新请求 的智能，所述另一个表示可以对应于或可以不对应于从该MBMS客户端的角度所允许的表 不。
[0190] 图17是示出了用于支持MBMS上的DASH的示例性架构的概念图。指定BM-SC和 eMBMS客户端之间的接口可能是重要的，并且eMBMS客户端和DASH客户端之间的接口是适 当的标准。例如，所述标准可以规定BM-SC和eMBMS客户端之间的接口应当符合TS26. 346。 所述标准还可以指定，如果DASH客户端和eMBMS客户端来自不同的供应商的话，则eMBMS 客户端和DASH客户端之间的接口应当遵循TS26. 247。对比图16的例子，图17示出了 DASH 客户端和eMBMS客户端之间的接口可以遵循TS26. 247(其可以是，例如，HTTP/1. 1)的例子。 图17示出了用以允许MBMS上的DASH回落到单播上的DASH的高级架构。
[0191] 图18-23是示出了与图17的网络架构相关联的、用于广播和单播传输上的DASH 内容传送的流程图。虽然被描述为对应于图17的网络架构，但是应当理解，图18-23的技 术可以由其他设备来执行，所述设备例如在图1、2A、2B、6、7、8和/或15的结构中的设备。
[0192] 关于图18的例子，USD信令可以包括在以下针对eMBMS客户端在表4中示出的数 据：
[0193] 表 4
[0194]
[0195] 这个例子中的ΜΗ)可以指定以下数据，其中BaseURL对应于用于访问段的URL的 基部：
[0196] BaseURLl=http://www.cnn.com/512/，Representationld= "512" ；
[0197] Template=seg$Number$. 3gp,
[0198] BaseURL2 =http://www.cnn.com/256/，Representationld= "256" ；
[0199] Template=seg$Number$. 3gp,
[0200]BaseURL3 =http://www.cnn.com/128/，Representationld= "128"；
[0201] Template=seg$Number$. 3gp.
[0202] 在图18所示的例子中，假定eMBMS客户端不具有HTTP代理功能，而仅具有HTTP 重定向功能。
[0203] 关于图19的例子，USD信令可以包括在以下针对eMBMS客户端在表5中所示出的 数据：
[0204] 表 5
[0205]
[0206] 这个例子中的MH)可以指定以下数据，其中BaseURL对应于用于访问段的URL的 基部：
[0207] BaseURLl=http://www.cnn.com/512/，Representationld= "512" ；
[0208] Template=seg$Number$. 3gp,
[0209] BaseURL2 =http://www.cnn.com/256/，Representationld= "256" ；
[0210] Template=seg$Number$. 3gp,
[0211] BaseURL3 =http://www.cnn.com/128/，Representationld= "128" ；
[0212] Template=seg$Number$. 3gp.
[0213] 在图19所示的例子中，假定eMBMS客户端具有HTTP代理功能和HTTP重定向功能 二者。
[0214] 关于图20的例子，USD信令可以包括在以下针对eMBMS客户端在表6中所示出的 数据：
[0215] 表 6
[0216]
[0217] 这个例子中的MPD可以指定以下数据，其中BaseURL对应于用于访问段的URL的 基部：
[0218]BaseURLl. 1 =http://www.cnn.com/512/,
[0219]BaseURLl. 2 =http://localhost/512/，Representationld = "512" ；
[0220] Template=seg$Number$. 3gp,
[0221] BaseURL2 =http://www.cnn.com/256/，Representationld= "256" ；
[0222] Template=seg$Number$. 3gp,
[0223] BaseURL3 =http://www.cnn.com/128/，Representationld= "128"；
[0224]Template=seg$Number$. 3gp.
[0225] 在图20所示的例子中，假定eMBMS客户端不具有HTTP代理功能，而仅具有HTTP 重定向功能。
[0226] 关于图21的例子，USD信令可以包括在以下针对eMBMS客户端在表7中所示出的 数据：
[0227]表 7
[0228]
[0229] 这个例子中的MH)可以指定以下数据，其中BaseURL对应于用于访问段的URL的 基部：
[0230]BaseURLl=http://www.cnn.com/ ；
[0231]Representationld=α 5 1 2 ?, ；Temp1ate=$RepresentationId$/ seg$Number$. 3gp,
[0232]Re