的表示是可以被訪問的。在這種情況下，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