DP簡檔，而AlternativeAccessDelivery元素可能包含對針對單播訪問的RTSP URL的引用，或包含PSSSDP文件，其表示單播SDP會話信息。當(dāng)UE處于廣播網(wǎng)絡(luò)覆蓋范圍 下時，eMBMS中間件可以使用廣播SDP會話信息來消耗廣播內(nèi)容。否則，該中間件可以通過 連接到AlternateAccessDelivery中的unicastAccessURI來傳遞內(nèi)容。該eMBMS用戶服 務(wù)描述（USD)模式片段的例子在圖11中不出。
[0120] 對攜帶廣播SDP和單播訪問URI的deliveryMethod的可替代例子具有統(tǒng)一的單 個SDP，其在不同的媒體流中包含單播和廣播會話描述二者。因為SDP中的任何會話描述可 以包含多個媒體流定義（例如，一個用于音頻軌，而另一個用于視頻軌），可以使用機制來 將廣播和單播媒體流組合成不同的集合，以提供統(tǒng)一的SDP簡檔。這可以通過在SDP中分 組方法來實現(xiàn)。分組機制的例子描述如下
[0121] Mediastreamidentification
[0122] a)Identifiesmediastreamswithingroups
[0123] b)Media-attribute="a=mid: "Identification-tag
[0124] c)Identification-tag=token
[0125]Groupattribute
[0126]d)Identifiesunicast/broadcastmediastreams
[0127]e)Group-attribute="a=group:'，Semantics(identification-tag)氺
[0128]f)Semantics= "BROADCAST" | "UNICAST"
[0129] 表2中的下列片段提供了例子，在所述例子中，提供了針對組和媒體流標(biāo)識符屬 性的值。在下面的例子中，"a=group: "行表示哪些媒體流用于廣播和哪些媒體流用于單 播。在該例子中，廣播媒體流分別由"a=mid: "值1和2表示，而單播分別由"a=mid: " 值3和4來表示。因此，中間件可以連接到IP地址224. 1. 1.2和用于廣播內(nèi)容的端口 30000 和30002,以及連接到IP地址131. 10. 1. 2和用于單播流的端口 26890和26892。
[0130] 表 2
[0131]
[0132] 以這種方式，圖10示出了一種設(shè)備的例子，所述設(shè)備包括被配置為接收會話描述 協(xié)議（SDP)消息的一個或多個處理器，所述SDP)消息包括限定了時移緩存器（TSB)的深度 的屬性，基于所述屬性的值來確定用于TSB的存儲器的量，向TSB分配所確定的量的存儲 器，以及在TSB中存儲與SDP消息相關(guān)聯(lián)的媒體數(shù)據(jù)的至少一部分。
[0133] 圖12和13是示出了用于針對RTSP/RTP客戶端支持傳輸分集的示例性組件的框 圖。無論eMBMSUSD中的傳遞方法被用于在廣播和單播傳輸之間進行區(qū)分，還是使用統(tǒng)一 單個SDP機制，本公開內(nèi)容的技術(shù)可以提供由RTSP/RTP客戶端進行的無縫內(nèi)容獲取。為了 實現(xiàn)這個目標(biāo)，如在Fall臨時申請中提出的，可能在eMBMS中間件（也稱為多播服務(wù)設(shè)備 客戶端（MSDC))之外，策略管理器、控制器和RTSP重定向器/代理可以保持在UE中。當(dāng) RTSP客戶端請求SDP時，RTSP重定向器/代理總會提供SDP簡檔，其攜帶本地主機（例如 IP版本4,地址127. 0. 0. 1)作為連接端點地址。方法是，無論該RTSP重定向器/代理是經(jīng) 由eMBMS中間件（用于廣播）還是單播RTSP服務(wù)器（用于單播）接收內(nèi)容，其總是從本地 主機內(nèi)容向RTSP/RTP客戶端服務(wù)內(nèi)容。因此，客戶端不知道傳輸機制的分集。下面我們提 供的架構(gòu)的主要組件的簡要說明，并給出了如何將內(nèi)容遞送至客戶端的例子。
[0134] 在圖12和13的例子中，回放應(yīng)用是嘗試消耗流媒體內(nèi)容的應(yīng)用；RTSP/RTP客戶 端是針對客戶端行為實現(xiàn)RTP協(xié)議的客戶端；eMBMS中間件是實現(xiàn)eMBMS(或MBMS)廣播服 務(wù)發(fā)現(xiàn)（用于流是傳輸或文件下載）并經(jīng)由廣播LTE網(wǎng)絡(luò)消耗流式傳輸或文件傳遞內(nèi)容的 中間件架構(gòu)；策略管理器維護如上面所討論的數(shù)據(jù)庫；控制器是從策略管理器獲取策略信 息以及從eMBMS中間件獲取和eMBMS廣播覆蓋指示并且向RTSP重定向器/代理提供映射、 陳述要從（單播或廣播）選擇哪些SDP簡檔的組價；而RTSP重定向器/代理是從控制器接 收映射信息，并取決于該映射從eMBMS中間件收集RTP內(nèi)容（在UE在廣播覆蓋范圍中的情 況下）或連接到單播RTSPURI并經(jīng)由單播傳輸來接收內(nèi)容的代理單元，其可以隨后傳遞到 RTSP/RTP客戶端。
[0135] 圖12表示用于RTP內(nèi)容的廣播遞送的示例性過程。圖12包括RTSP/RTP客戶 端1202、回放應(yīng)用1204、RTSP重定向器/代理1218、控制器1214、eMBMS中間件（也稱為 MSDC) 1208、策略管理器1216和廣播傳輸單元（也被稱為eMBMSrX) 1220。圖12還描繪了 長期演進（LTE)無線接入網(wǎng)絡(luò)（RAN) 1206。LTERAN1206提供MBMS服務(wù)，其限定了用于媒 體數(shù)據(jù)的多種類型的傳輸（例如，廣播、多播或單播）中的至少一個。因此，當(dāng)MSDC1208 在由LTERAN1206提供的覆蓋的服務(wù)區(qū)域中時，MSDC1208可以經(jīng)由LTERAN1206使用 廣播或多播傳輸來接收媒體數(shù)據(jù)。此外，MSDC1208實現(xiàn)服務(wù)器1212,所述服務(wù)器1212包 括高速緩存器1210。以這種方式，MSDC1208既可以用作接收媒體數(shù)據(jù)的客戶端又能作為 向例如RTSP/RTP客戶端1202提供數(shù)據(jù)的服務(wù)器。另外，RTSP/RTP客戶端1202可以從例 如MSDC1208或RTSP重定向器/代理1218取回媒體數(shù)據(jù)，并且隨后向回放應(yīng)用1204提供 所述媒體數(shù)據(jù)。
[0136] 回放應(yīng)用1204可以基本上對應(yīng)于應(yīng)用101 (圖1)，而RTSP/RTP客戶端1202可以 基本上對應(yīng)于應(yīng)用服務(wù)客戶端102 (圖1)。同樣，MSDC1208可以基本上對應(yīng)于傳輸中間件 110A-110R(圖10)?？刂破?214可以基本上對應(yīng)于控制器106(圖1)。RTSP重定向器/ 代理1218可以基本上對應(yīng)于重定向器/代理104(圖1)。
[0137] 在這個例子中，策略管理器被提供具有策略（1230)。所述eMBMS中間件（或 MSDC) 1208接收針對eMBMS服務(wù)列表的USD描述（1232、1234)。所述MSDC1208隨后將 針對RTP流式傳輸服務(wù)的SDP簡檔信息和廣播覆蓋通知傳遞給控制器1214(1236)，而 控制器1214將SDP信息與策略列表進行匹配，并將映射信息提供給RTSP重定向器代理 1218(1238)。映射信息包含數(shù)據(jù)，所述數(shù)據(jù)指示針對每個場景（廣播或單播覆蓋），要使用 哪個SDP簡檔連接端點。以這種方式，RTSP重定向器可以獲取映射信息，所述映射信息將 針對所述媒體數(shù)據(jù)的標(biāo)識符映射到資源位置。所述資源位置可以對應(yīng)于網(wǎng)絡(luò)地址，例如，經(jīng) 由LTERAN1206可用的地址。所述服務(wù)定義用于傳輸媒體數(shù)據(jù)的多個類型的傳輸中的至 少一個，例如廣播或多播。
[0138] 同時，MSDC1208將服務(wù)列表傳遞給回放應(yīng)用1204(1240)?；胤艖?yīng)用1204可以 對應(yīng)于應(yīng)用101 (圖1)。該回放應(yīng)用1204隨后將RTSPURI(被提供具有來自MSDC的服務(wù) 列表）和代理地址傳遞給RTSP/RTP客戶端1202(1242)。當(dāng)RTSP/RTP1202客戶端調(diào)用 DESCRIBE命令時（RTSP定義的命令）（1244)，RTSP重定向器/代理1218提供重定向至本地 服務(wù)器的修改的SDP消息（1246)。該RTSP/RTP客戶端1202解析SDP信息（1248)，并調(diào)用 SETUP命令（RTSP命令），以與本地服務(wù)器建立RTP會話。當(dāng)與服務(wù)器建立成功時，該RTSP/RTP客戶端1202還傳遞播放命令（1250)。RTSP重定向器/代理1218向RTSP/RTP客戶端 1202提供了對SETUP和PLAY請求的成功消息（1252)。由RTSP重定向器/代理1218從 RTSP/RTP客戶端1202接收到的SETUP和PLAY命令表示針對媒體數(shù)據(jù)的請求的例子。另 外，RTSP重定向器/代理1218向MSDC1208發(fā)送SETUP和PLAY命令（1251)。
[0139] RTSP重定向器/代理1218可以確定用于取回媒體數(shù)據(jù)的服務(wù)是否是可用的，例 如，將廣播或多播定義作為傳輸?shù)姆?wù)是否是可用的。RTSP重定向器/代理1218可以至少 部分地基于RTSP重定向器/代理1218或MSDC1208是否是在服務(wù)覆蓋區(qū)域內(nèi)，來確定服 務(wù)是否是可用的。圖12的技術(shù)假定服務(wù)是可用的。如以下更詳細(xì)討論的，圖13描述了當(dāng) 服務(wù)不可用時可以使用的額外技術(shù)。
[0140] 同時，在流式傳輸服務(wù)的活動廣播會話期間，網(wǎng)絡(luò)運營商在LTERAN1206上發(fā)送 RTP內(nèi)容（1254)。MSDC針對來自廣播連接端點（在圖12中標(biāo)記為eMBMSrX1220)的服務(wù) 收集RTP內(nèi)容（1256)，處理該內(nèi)容（如果需要的話），并在與RTSP重定向器/代理的SETUP 命令期間，在由客戶端指定的端點處將內(nèi)容傳遞給RTSP/RTP客戶端1202 (1258)。以這種方 式，當(dāng)服務(wù)是可用的（例如，限定廣播或多播傳輸?shù)姆?wù)）時，RTSP重定向器/代理1218使 得RTSP/RTP客戶端1202從MSDC1208接收媒體數(shù)據(jù)（即，使用服務(wù)從資源位置例如經(jīng)由 LTERAN1206接收媒體數(shù)據(jù)的單元）。特別是，在本例子中，MSDC1208基于映射信息（例 如，上述的USD數(shù)據(jù)）經(jīng)由LTERAN1206接收來自網(wǎng)絡(luò)位置的媒體數(shù)據(jù)，該映射信息將服 務(wù)映射到這個位置。
[0141] 以這種方式，圖12的技術(shù)表示了一種方法的例子，所述方法包括：由代理單元（例 如，RTSP重定向器/代理1218)進行以下操作：獲取映射信息，所述映射信息基于用于取回 所述媒體數(shù)據(jù)的服務(wù)，將針對所述媒體數(shù)據(jù)的標(biāo)識符映射到資源位置，其中，所述服務(wù)定義 用于傳輸所述媒體數(shù)據(jù)的多個類型的傳輸（例如，廣播、多播或單播）中的至少一個；從應(yīng) 用服務(wù)客戶端（例如，RTSP/RTP1202)接收針對所述媒體數(shù)據(jù)的請求；確定所述服務(wù)是否 是可用的；以及當(dāng)所述服務(wù)是可用的時，使得所述應(yīng)用服務(wù)客戶端從單元接收所述媒體數(shù) 據(jù)，所述單元基于所述映射信息，使用所述服務(wù)從所述資源位置接收所述媒體數(shù)據(jù)。在這個 例子中，接收媒體數(shù)據(jù)的單元對應(yīng)于MSDC1208。
[0142] 圖13表示用于RTP內(nèi)容的單播遞送的示例性過程。在本例子中，步驟1232-1248 與關(guān)于圖2所描述的內(nèi)容的廣播遞送是基本相同的。然而，在這種情況下，當(dāng)RTSP/RTP客 戶端調(diào)用SETUP和PLAY命令（1310)時，RTSP重定向器/代理1218經(jīng)由RAN/互聯(lián)網(wǎng)1302 從映射信息接觸單播RTSP服務(wù)器（1312)，從單播RTSP服務(wù)器取回內(nèi)容（1314)，并在SETUP 命令期間或在步驟1246處SDP中公布的那些期間將該內(nèi)容傳遞給由RTSP/RTP客戶端1202 所提到的端點。因此，在這種情況下，RTSP重定向器/代理1218(其可以存在于用戶設(shè)備 中，所述用戶設(shè)備還包括RTSP/RTP客戶端1202)充當(dāng)遠(yuǎn)程RTSP服務(wù)器的客戶端，并代表 RTSP/RTP客戶端來取回內(nèi)容。
[0143] 以這種方式，本公開內(nèi)容的技術(shù)可以使用SDP擴展機制（屬性），以針對RTP內(nèi)容 的eMBMS廣播傳遞提供TSB指示。本公開內(nèi)容還定義了用以支持廣播和單播傳輸之間的無 縫轉(zhuǎn)換的示例性架構(gòu)，以及在UE內(nèi)提供RTP媒體內(nèi)容遞送機制。此外，本公開內(nèi)容描述了一 種用于在SDP消息中針對內(nèi)容的單播和廣播遞送而將多個基于RTP的媒體流分組的技術(shù)。
[0144] RTSP重定向器/代理1218表示了代理單元的例子，所述代理單元可被配置為進行 以下操作：獲取映射信息，所述映射信息基于用于取回所述媒體數(shù)據(jù)的服務(wù)，將針對所述媒 體數(shù)據(jù)的標(biāo)識符映射到資源位置，其中，所述服務(wù)定義用于傳輸所述媒體數(shù)據(jù)的多個類型 的傳輸（例如，廣播、多播或單播）中的至少一個；從應(yīng)用服務(wù)客戶端接收針對所述媒體數(shù) 據(jù)的請求；確定所述服務(wù)是否是可用的；以及當(dāng)所述服務(wù)是可用的時，使得所述應(yīng)用服務(wù) 客戶端從單元接收所述媒體數(shù)據(jù)，所述單元基于所述映射信息，使用所述服務(wù)從所述資源 位置接收所述媒體數(shù)據(jù)。
[0145] 圖14A和14B是示出了用于擴展USD以攜帶DASH傳輸信息的示例性XML內(nèi)容模 型的概念圖。被圈的A表示圖14A和14B之間的連接在此處接合的點?？梢詥为毷褂肵ML 內(nèi)容模型或結(jié)合任何上述技術(shù)來使用。圖1、2A、2B、6、7和/或8的組件可以被配置為利用 關(guān)于圖14A和14B所描述的XML內(nèi)容模型。如上所述，本公開內(nèi)容的技術(shù)包括的用在于單 播和廣播傳輸模式之間進行選擇的技術(shù)。圖14B示出了用于限定廣播表示（在USD中的 broadcast元素）和單播表示（在USD中的unicast元素）的數(shù)據(jù)。
[0146] 根據(jù)本公開內(nèi)容的某些技術(shù)，應(yīng)用服務(wù)客戶端，如DASH客戶端（例如，圖1、2A、2B、 6、7和/或8的DASH客戶端）可以作出對從哪個表示來取回段的初始選擇。特別是，DASH 客戶端可以做出這種初始選擇，而其余的不可知該請求的段所屬于的表示的傳輸模式（廣 播和/或單播）。出于示例的目的，假設(shè)，HTTP由DASH客戶端用于請求所選擇的表示的段， 以及圖14B中所示的擴展的USD用于攜帶DASH傳輸信息。一個或多個廣播表示中的每一 個在USD中由broadcast元素的唯一 baseUrl屬性來識別。
[0147]Broadcast的每個實例映射到MBMS承載上所傳遞的唯一表示。其baseURL時將與 由DASH客戶端所使用的、段URL的一部分作比較，以請求段，具體而言，所述段URL的一部 分是段URI的初始部分，其從URI方案開始，并延伸至并包括該段所屬于的表示的標(biāo)識符， 以確定所述表示是否正被請求。
[0148] 例如，假定由DASH客戶端發(fā)出的段URL是"http://example.com/per-3/rep-512/ seg-99. 3gp"，其對應(yīng)于時段 3(Period@id= '3'）中的表不 512(Representation@ id= '512'）的段99。出于與USD中的basesURL匹配的目的，要考慮的該URI的部 分是"http://example.com/per-3/rep-512。在該表示在廣播上也是可用的情況下， mediaPresentationDescription2.broadcast的實例將存在于USD中，具有由 "http: // example.com/per-3/rep_512"給出baseURL，其與請求URL中的感興趣部分相同。例如，該 請求URL中的感興趣部分與USD的broadcast元素的baseURL屬性的匹配表示請求的段所 屬于的表示的廣播傳輸。
[0149] 類似地，在該例子中，零個或多個單播表示中的每個在USD中由 mediaPresentationDescription2.unicast元素的唯一baseUrl屬性識別。如上所討論的， 在請求的URL的相同部分與單播baseURL的匹配模式時意味著該表示在單播傳遞上是可用 的。同一表不可能在兩個傳輸模式都是可用的、在僅一個傳輸模式上是可用的或兩個傳輸 模式上都不是可用的。
[0150] DASH客戶端提交段向其請求的實體可以是代理單元（或提交給MBMS或eMBMS客 戶端）。出于示例的目的，以下將代理單元描述為執(zhí)行這些技術(shù)，但應(yīng)理解的是，例如圖1、 2A、2B、6、7和/或8的MBMS或eMBMS可以被配置為執(zhí)行歸因于代理單元的技術(shù)，如下所述。 通過使用針對請求URL的感興趣的部分與USD中的broadcast和unicast元素的baseURL 值之間的模式匹配，代理單元可以確定所選擇的傳輸模式是否是可用的和/或比另一傳輸 模式優(yōu)選。
[0151] 代理單元可以取回指示各種傳輸類型之間的偏好的策略。例如，該策略可以指示， 如果請求是用于在單播上傳遞的表示，只要該裝置位于廣播覆蓋范圍內(nèi)，僅廣播傳遞的表 示對DASH客戶端是應(yīng)當(dāng)可訪問的。雖然在不同的傳輸模式上傳遞，但如果baseURL在USD 的identicalContent元素中出現(xiàn)，并且可以針對被請求的表示而被取代，貝lj這種廣播表示 可能與原始所請求的是同一表示。
[0152] 或者，廣播表示可以是已知在廣播上傳遞的可替代表示，并且被認(rèn)為是可切換的 表示，這是由于針對可替代表示的baseURL出現(xiàn)在USD元素switchableContent的條目列 表中。在這種情況下，代理單元可以將消息發(fā)送回DASH客戶端，以使得DASH客戶端請求屬 于在廣播上傳送的可替代表示的同一個段。例如，代理單元可以發(fā)送300類型的HTTP響應(yīng) 消息給DASH客戶端，其對應(yīng)于重定向消息，并且所述重定向消息可以指定對應(yīng)于來自包含 在switchableContent的列表中的可替代表示的資源URL。
[0153] 作為另一例子，如果DASH客戶端請求代理單元已知要在廣播上傳遞的段，但廣播 接收不可用（例如，由于客戶端設(shè)備處于廣播覆蓋區(qū)域之外），則代理單元可以發(fā)送300類 型的HTTP響應(yīng)消息，其包括對應(yīng)于同一單播傳輸?shù)亩蔚腢RL，或者如果該同一表示在單播 傳輸上是不可用的但顯示為switchableContent中的條目，則對應(yīng)于不同的表示。
[0154] 作為另一例子，如果DASH客戶端請求已知為代理單元要在廣播上傳遞的段，但廣 播接收可用，則代理單元將請求代理到本地內(nèi)容高速緩存器，并將所取回的段傳遞回DASH 客戶端。
[0155] 可選地，代理單元可以用400類型錯誤消息來進行響應(yīng)，這可能會導(dǎo)致DASH客戶 端使用不同的段URL來重新提交請求。代理單元還可以以其他方式來傳輸不同的傳輸協(xié) 議，例如，經(jīng)由應(yīng)用編程接口（API)、進程間通信（IPC)，發(fā)送省略所選擇的基URL的修改的 MH)等等。
[0156] 來自代理單元的重定向或錯誤消息可能會使得DASH客戶端選擇不同的傳輸模 式。在一些例子中，在重定向的傳輸模式上一個以上的表示可能是可用的，在這種情況下， DASH客戶端可能從那些可用的表示中的一個進行選擇。作為一個例子，如果DASH客戶端曾 嘗試選擇廣播表示（如由圖14A和14B的broadcast元素的實例所給出的），但代理單元確 定廣播接收是不可用的，則代理單元可以向DASH客戶端發(fā)送消息（例如，經(jīng)由IPC通信等 的300類型重定向消息、400類型錯誤消息、API調(diào)用），以使得DASH客戶端代替地選擇圖 14A和14B的單播表示。
[0157] 在一些實例中，應(yīng)用服務(wù)客戶端，如DASH客戶端，可以負(fù)責(zé)管理單播廣播轉(zhuǎn)換。作 為例子，本公開內(nèi)容關(guān)于圖14A和圖14B描述了用于利用額外的參數(shù)來擴展USD的架構(gòu)，在 MBMS上的DASH下載傳遞的情況下，使得MBMS客戶端能夠確定來自DASH客戶段的請求是否 可以作為、是或僅是來自一個或多個可替代表示。USD可以指示媒體表達(dá)描述（MPD)中指定 的每個表示的傳輸模式（僅廣播、僅單播，還是廣播和單播二者）。以下描述了用于確定表 示可用性的規(guī)則和機制的示例性場景。
[0158] 在一個例子中，用戶設(shè)備（UE)可以位于MBMS覆蓋區(qū)域內(nèi)，并且DASH客戶端可以 請求該USD指示是經(jīng)由廣播傳遞不可用的、特定的表示。服務(wù)提供商策略可以指示，當(dāng)UE處于MBMS覆蓋中時，僅同一節(jié)目的廣播傳遞