技术领域
本公开内容涉及编码数据的存储和传输。
背景技术：
可将数字视频能力并入较广范围的设备中，包括数字电视、数字直播系统、无线广播系统、个人数字助理(PDA)、膝上型或桌上型计算机、数码相机、数字记录设备、数字媒体播放器、视频游戏设备、视频游戏控制台、蜂窝式或卫星无线电话、视频电话会议设备等。数字视频设备实施视频压缩技术，例如由MPEG-2、MPEG-4、ITU-T H.263或ITU-T H.264/MPEG-4第10部分高级视频编码(AVC)定义的标准和所述标准的扩展部分中所描述的那些视频压缩技术，以更有效地发射和接收数字视频信息。
视频压缩技术执行空间预测和/或时间预测以减少或移除视频序列中所固有的冗余。对于基于块的视频编码，可将视频帧或切片分割成宏块。可进一步分割每一宏块。使用相对于相邻宏块的空间预测对帧内编码的(I) 帧或切片中的宏块进行编码。帧间编码的(P或B)帧或切片中的宏块可使用相对于同一帧或切片中的相邻宏块的空间预测或相对于其它参考帧的时间预测。
在视频数据已经被编码之后，可以对该视频数据进行分组，用于传输或存储。该视频数据可以被组装到符合各种不同标准(诸如国际标准化组织(ISO)基本媒体文件格式及其扩展格式，诸如AVC)中的任意一种标准的视频文件中。
技术实现要素：
在一个示例中，一种用于接收流数据的方法，包括：由客户端设备的代理单元接收所述流数据要经由第一服务还是第二服务接收的指示，其中，所述指示是从服务供应商网络的广播多播服务中心(BM-SC)发送的，其中，所述客户端设备还包括广播或多播中间件单元，并且其中，所述代理单元布置在所述中间件单元和由所述客户端设备的至少一个处理器执行的客户端应用之间的通信路径中；以及当所述指示指出所述流数据要经由所述第二服务接收时：激活所述中间件单元以经由所述第二服务接收所述流数据，其中，所述第二服务包括广播服务或多播服务中的至少一个，以及由所述代理单元从所述中间件单元接收所述流数据。
在一个示例中，一种用于接收流数据的方法，包括：由客户端设备的代理单元接收所述流数据要经由第一服务还是第二服务接收的指示，其中，所述指示是从服务供应商网络的广播多播服务中心(BM-SC)发送的，其中，所述客户端设备还包括多媒体广播多播服务(MBMS)或演进型MBMS (eMBMS)中间件单元，并且其中，所述代理单元布置在所述中间件单元和由所述客户端设备的至少一个处理器执行的客户端应用之间的通信路径中；以及当所述指示指出所述流数据要经由所述第一服务接收时：禁用所述中间件单元，所述中间件单元已经经由所述第二服务接收到所述流数据的至少一部分，其中，所述第二服务包括广播服务或多播服务中的至少一个，以及由所述代理单元经由所述第一服务接收所述流数据，其中，所述第一服务包括单播服务。
在一个示例中，一种用于接收流数据的设备，包括：广播或多播中间件单元，其被配置为经由第二服务接收所述流数据；以及代理单元，其被配置为布置在所述中间件单元和由所述设备的至少一个处理器执行的客户端应用之间的通信路径中，所述代理单元还配置为：从服务供应商网络的广播多播服务中心(BM-SC)接收所述流数据要经由第一服务还是所述第二服务接收的指示，当所述指示指出所述流数据要经由所述第一服务接收时：禁用所述中间件单元；以及经由所述第一服务接收所述流数据，其中，所述第一服务包括单播服务，以及当所述指示指出所述流数据要经由所述第二服务接收时：激活所述中间件单元以经由所述第二服务接收所述流数据，其中所述第二服务包括广播服务或多播服务中的至少一个；以及从所述中间件单元接收所述流数据。
在一个示例中，一种计算机可读存储介质，其上存储有用于接收流数据的指令，当所述指令被执行时使得客户端设备的至少一个处理器用于：使得所述客户端设备的代理单元接收所述流数据要经由第一服务还是第二服务接收的指示，所述指示是从服务供应商网络的广播多播服务中心 (BM-SC)发送的，其中，所述客户端设备包括广播或多播中间件单元，并且其中，所述代理单元布置在所述广播或多播中间件单元和由所述客户端设备的至少一个处理器执行的客户端应用之间的通信路径中；当所述指示指出所述流数据要经由所述第一服务接收时：禁用所述中间件单元；以及经由所述第一服务接收所述流数据，其中，所述第一服务包括单播服务，以及当所述指示指出所述流数据要经由所述第二服务接收时：激活所述中间件单元以经由所述第二服务接收所述流数据，其中所述第二服务包括广播服务或多播服务中的至少一个，以及从所述中间件单元接收所述流数据。
在一个示例中，一种用于接收流数据的设备，包括：用于使得所述设备的代理单元接收所述流数据要经由第一服务还是第二服务接收的指示的单元，所述指示是从服务供应商网络的广播多播服务中心(BM-SC)发送的，其中，所述设备还包括广播或多播中间件单元，其中，所述代理单元布置在所述广播或多播中间件单元和由所述客户端设备的至少一个处理器执行的客户端应用之间的通信路径中；用于在所述指示指出所述流数据要经由所述第一服务接收时，禁用所述中间件单元的单元；用于在所述指示指出所述流数据要经由所述第一服务接收时，由所述代理单元经由所述第一服务接收所述流数据的单元，其中，所述第一服务包括单播服务；用于在所述指示指出所述流数据要经由所述第二服务接收时，激活所述中间件单元以经由所述第二服务接收所述流数据的单元，其中所述第二服务包括广播服务或多播服务中的至少一个；以及用于在所述指示指出所述流数据要经由所述第二服务接收时从所述中间件单元接收所述流数据的单元。
在以下附图和描述中阐述一个或多个示例的细节。将从所述描述和附图并从权利要求明白其它特征、目标和优点。
附图说明
图1是描绘了实施用于通过网络对媒体数据进行流传输的技术的示例性系统的框图。
图2是描绘了示例性多媒体内容的概念图。
图3是描绘了实施用于选择性地使用一个或多个服务获取数据的技术的示例性系统的概念图。
图4是描绘了实施用于选择性地使用一个或多个服务获取数据的技术的示例性系统的概念图。
图5A-5D是描绘了用于选择性地使用一个或多个服务获取流媒体数据的示例性操作的概念图。
图6是描绘了用于重定向消息的主体实体的一个示例的概念图。
图7A和7B是描绘了用于选择性地使用一个或多个服务获取流媒体数据的示例性操作的概念图。
图8是描绘了实施用于选择性地使用一个或多个服务获取数据的技术的示例性系统的概念图。
图9是描绘了实施用于选择性地使用一个或多个服务获取数据的技术的示例性系统的概念图。
图10是描绘了实施用于选择性地使用一个或多个服务获取数据的技术的示例性系统的概念图。
图11A和11B是描绘了用于通过网络使用一个或多个服务发送数据的示例性操作的概念图。
图12是描绘了用于通过网络使用一个或多个服务获取数据的示例性操作的概念图。
图13A和13B是描绘了用于通过网络使用一个或多个服务获取数据的示例性操作的概念图。
图14是描绘了用于通过网络使用一个或多个服务获取数据的示例性操作的概念图。
图15A和15B是描绘了用于通过网络使用一个或多个服务获取数据的示例性操作的概念图。
图16是描绘了用于通过网络使用一个或多个服务获取数据的示例性系统的概念图。
图17A和17B是描绘了用于通过网络使用一个或多个服务获取数据的示例性操作的概念图。
图18是描绘了用于消耗报告的实体的一个示例的概念图。
图19是描绘了用于消耗报告的示例性操作的概念图。
图20A和20B是描绘了用于选择性地使用一个或多个服务获取流媒体数据的示例性操作的概念图。
图21是描绘了针对按需MBMS操作配置的管理对象的一个示例的概念图。
具体实施方式
无线通信网络被广泛部署以提供各种通信服务，诸如语音、视频、分组数据、消息传递、广播等。这些无线网络可以是能够通过共享可用的网络资源来支持多个用户的多址网络。这类多址网络的示例包括码分多址 (CDMA)网络、时分多址(TDMA)网络、频分多址(FDMA)网络、正交FDMA(OFDMA)网络、以及单载波FDMA(SC-FDMA)网络。
无线通信网络可以包括能够支持数个用户设备(UE)通信的数个基站， UE也可以指的是移动设备或移动实体。UE可经由下行链路和上行链路与基站通信。下行链路(或前向链路)是指从基站至UE的通信链路，而上行链路(或反向链路)是指从UE至基站的通信链路。“基站”可以指的是 eNodeB(eNB)、节点B、家庭节点B或无线通信系统的类似的网络部件。
第3代合作伙伴计划(3GPP)长期演进(LTE)作为全球移动通信系统(GSM)和通用移动电信系统(UMTS)的演进，代表了蜂窝技术中的重大进展。LTE物理层(PHY)提供了高效的方式在基站(诸如演进型节点B(eNB))与移动实体(诸如UE)之间传送数据和控制信息两者。在现有应用中，用于促进多媒体的高带宽通信的方法一直是单频网络(SFN) 操作。SFN使用无线发射机(诸如，举例来说，eNB)来与订户UE通信。在单播操作中，对每个eNB进行控制，以便发送携带去往一个或多个特定订户UE的信息的信号。单播信令的特质使得能够进行个人到个人的服务，诸如，举例来说，语音呼叫、文本消息传递或视频呼叫。
在广播操作中，广播区域中的若干个eNB以同步的方式广播信号，所述信号携带了可由广播区域中的任何订户UE接收和访问的信息。广播操作的普遍性使得能够更为高效地发送公众感兴趣的信息，例如向最终用户提供各种类型的音频-视频内容的多媒体广播和多媒体单播服务。随着针对多媒体内容的需求以及系统能力在增长，系统运营商需要工具来以灵活并且适应性的方式控制针对多媒体或其它内容的无线资源的使用。
一般而言，本公开内容描述了用于支持用于通过网络发送各种类型的数据(包括流媒体数据(例如，音频和/或视频数据))的各种类型传输机制的技术。例如，UE的一个或多个部件(例如，应用、流/文件下载客户端、代理单元或其它部件)可以被配置为接收要经由第一(例如，单播)服务还是第二(例如，广播或多播)服务接收数据的指示。在一些示例中，该指示可以是HTTP重定向、推送消息、空中接口信令消息或其它消息。当该指示指出要经由第一服务接收数据时，UE可以禁用用于经由第二服务接收数据的单元，诸如多媒体广播多播服务(MBMS)中间件单元、演进型 MBMS(eMBMS)中间件单元或多播服务设备客户端(MSDC)，并且可以使用第一分发模式(例如，单播分发模式)经由第一服务接收该数据。当该指示指出要经由第二服务接收数据时，该UE可以激活用于经由第二服务接收数据的单元并且从用于经由第二服务接收数据的单元接收该数据。用于经由第二服务接收数据的单元可以经由第一分发模式(例如，单播分发模式)或第二分发模式(例如，广播或多播分发模式)接收该数据。
换句话说，本公开内容的一种或多种技术可以包括通过提供按需 MBMS操作(MooD)对MBMS操作的改进。在一些示例中，本申请中描述的技术可以实现MBMS用户服务的空中建立和现有服务到MBMS用户服务的无缝迁移。也就是，在一些示例中，最初通过单播网络分发的某些内容可以变为MBMS用户服务，以便在业务量超过某个阈值时有效地利用网络资源。这种从单播分发到MBMS分发的动态转换也可以称为“MBMS 卸载”。MBMS卸载可以应用于通过HTTP或实时传输协议(RTP)/实时流传输协议(RTSP)携带的单播业务。在前一种情况中(例如，通过HTTP 携带的单播业务)，MBMS下载分发方法可以用于分发卸载后的内容。在后一种情况(例如，通过RTP/RTSP携带的单播业务)中，基于RTP的MBMS 流传输方法可以用于分发卸载后的内容。
在一些示例中，MBMS卸载可以是UE选择的。UE选择的卸载可以指的是MooD功能UE向指定的代理服务器发送针对有资格转换到作为 MBMS服务分发的内容的单播请求。可以由开放移动联盟设备管理 (OMA-DM)Mood管理对象(MO)基于请求域描述特定内容的转换资格。如果UE接收到MooD重定向响应(例如，包含3GPP指定的MooD报头字段)，则该UE可以通过为中间件提供用户服务描述(USD)的入口点信息来激活MBMS中间件客户端，所述USD是已经在MooD报头字段中规定或提供的。其后，当MBMS中间件客户端是操作的，已经获取到了新的 MBMS服务的USD片段(在通过HTTP的动态自适应流传输(DASH)格式化的内容的情况中包括媒体呈现描述片段)并且已经开始在该MBMS承载上接收内容时，流客户端(例如，DASH客户端)未来对内容的请求可以由该MBMS客户端服务。
经由OMA-DM(设备管理)，可以向UE提供与MooD操作有关的配置信息(例如，使用MooD配置管理对象)。配置参数可以包括要通过其发送单播内容请求的代理服务器的指示、可以有资格卸载到MBMS的内容的标识和用于UE获取服务公告信息的USD的位置。
如果UE不能处理BM-SC的重定向消息，则UE可以针对这些请求不使用代理服务器。也就是，一些UE可以被依照本申请中描述的技术配置，并且可以支持重定向消息的处理，而其它UE可能不能处理该重定向消息。
此外，本申请中描述的技术可以包括评估单播服务的性能以确定使用广播还是单播能更好地服务于该服务，以及用于针对正在进行的MBMS用户服务启用MBMS广播会话的技术，其中先前没有是激活的。
在一些示例中，本申请中描述的技术可以启用一个或多个部件(例如，服务网络的部件)以确定非MBMS单播服务是否应该被转换到MBMS用户服务，并且如果是，则启用广播多播服务中心(BM-SC)以便将该非MBMS 单播服务转换到MBMS用户服务。MBMS用户服务是在2014年3月的 V12.1.0的3GPP技术规范26.346“多媒体广播/多播服务(MBMS)；协议和编解码(版本12)”中规定的。在一些这样的示例中，本申请中描述的技术可以启用服务网络以便向感兴趣的UE分配USD或其它描述该MBMS用户服务的清单文件。
另外，在一些示例中，本申请中描述的技术可以包括确定服务的消耗水平，并且评估可以辅助确定该服务是否可以经由单播或广播/多播传输被更好地服务的元件。在一些示例中，该消耗水平可以代表消耗该服务的特定区域中UE的数量、正在消耗该服务的区域中的UE的百分比、正在消耗该服务的MooD功能UE的百分比，或其它服务消耗测量方式。在一些示例中，本申请中描述的技术可以启用USD或其它清单文件以便如果摄取很高则将MBMS下载或流会话添加到现有MBMS用户服务中。在一些示例中，本申请中描述的技术可以研究对支持R12之前的MBMS的UE的MooD 支持的水平。在各种示例中，可以使用MBMS广播服务和/或MBMS多播服务来应用本公开内容的技术。
本公开内容的技术可以与用于流媒体数据的各种应用层协议结合使用。例如，本公开内容的技术可以与自适应HTTP流传输技术结合使用，诸如DASH、HTTP实况流传输(HLS)和平滑流传输(其利用HTTP对媒体数据进行流传输)。举另外的示例，本公开内容的技术可以与RTP、RTSP 和/或文件下载协议(诸如分组交换流传输服务(PSS)渐进式下载)结合使用。在这些和其它实例中，流客户端(例如，RTP客户端、RTSP客户端、 DASH客户端等)可以是传输不可知的，在这个意义上讲流客户端不需要知道用于取回媒体数据的传输机制。例如，在一些示例中，流客户端不需要知道潜在的传输机制是对应于经由单播分发模式的单播服务还是对应于经由广播或多播分发模式的广播或多播服务。
如下面更详细讨论的，UE可以被配置为通过网络发送请求，该请求指定内容服务的某些数据(例如，媒体数据或其它文件数据)。UE的一个或多个部件可以接收该数据是否可以用特定传输机制(例如，广播服务或单播服务)取回的指示。例如，UE的代理单元可以接收该指示，作为对发送该请求的响应。然后，代理单元可以使流/文件下载客户端使用一种传输机制(基于可用性、偏好、可靠性和/或其它因素)来接收该数据。例如，如果广播服务可用，则代理单元可以使流/文件下载客户端经由该广播服务接收数据(例如，使用广播分发模式)，而如果广播服务不可用，则代理单元可以使流/文件下载客户端继续经由单播服务接收数据。
举例来说，相对于DASH，媒体数据可以从一个或多个服务器(例如广播服务器和单播服务器)获得。在一些情况中，相同的服务器设备可以既提供广播服务也提供单播服务。因此，广播服务器和单播服务器可以对应于同一个服务器设备。DASH客户端可以接收媒体数据的修改后的媒体呈现描述(MPD)，其指示该媒体数据是从本地主机(而不是服务器)可获得的。当DASH客户端向代理单元发送针对媒体数据的请求时，该代理单元可以确定(基于接收到的指示)单播服务还是广播服务可用于取回所请求的媒体数据。如果该广播服务可用，则广播接收单元(例如，MBMS或 eMBMS中间件单元或MSDC)可以经由多播或广播分发模式接收该媒体数据，并且该代理单元可以使DASH客户端向广播接收单元发送针对该媒体数据的请求。在另一方面，如果广播服务不可用，则代理单元可以使DASH 客户端向单播服务器发送针对媒体数据的请求，以便使用单播服务取回媒体数据。作为替代，如果广播服务不可用，则代理单元可以从单播服务器取回媒体数据，然后将取回的媒体数据提供给DASH客户端。
举另一个例子，相对于RTP和/或RTSP，RTP客户端(另外或者作为替代，其可以对应于RTSP客户端)可以向代理单元提交DESCRIBE、SETUP 和PLAY命令。作为对DESCRIBE命令的响应，代理单元可以向RTP客户端提供会话描述协议(SDP)消息。该SDP消息可以指定单播服务器的地址作为从其可获得媒体数据的地址。这一SDP消息可以使RTP客户端向单播服务器发送SETUP和PLAY命令。当代理单元确定(基于接收到的指示) 广播服务可用时，代理单元可以向广播接收单元(例如，MBMS或eMBMS 中间件单元或MSDC)发送SETUP和PLAY命令，该广播接收单元可以经由广播或多播分发模式接收媒体数据并将该媒体数据转发给RTP客户端。另一方面，当代理单元确定广播服务不可用时，代理单元可以从单播服务器取回媒体数据，然后将取回的媒体数据提供给RTP客户端。
在一些示例中，用于执行本公开内容的技术的部件可以包括流/文件下载客户端和广播接收单元。在各个示例中，客户端设备可以单独或以任意组合包括这些部件之一或二者。在一些示例中，客户端设备可以包括其它部件，诸如代理单元、短消息服务(SMS)接收单元、OMA-DM接收单元、无线应用协议(WAP)消息接收单元、通信单元(例如，调制解调器)或其它部件。虽然在各个示例中描述为由UE的代理单元、UE的流/文件下载客户端和/或UE的客户端应用中的一个或多个来执行，但是各种功能在一些示例中也可以依照本申请中描述的技术由其它部件执行。例如，在一些示例中，代理单元可以既提供流/文件下载客户端功能也提供代理/重定向功能。在一些示例中，虽然描述客户端设备(或用户设备)的一部分，但是各个部件可以具有本申请中描述的功能但是相互分开且有所区分。例如，客户端设备可以包括流/文件下载客户端，并且与该客户端设备分开的一个或多个设备中可以包括一个或多个其它部件。
本公开内容的技术可以应用于符合根据ISO基本媒体文件格式、可伸缩视频编码(SVC)文件格式、高级视频编码(AVC)文件格式、第三代合作伙伴项目(3GPP)文件格式和/或多视图视频编码(MVC)文件格式或其它类似视频文件格式中的任何一个格式封装的视频数据的视频文件。本公开内容的一种或多种技术也可以另外应用于其它类型的数据，诸如文件数据或其它应用数据。也就是，虽然在一些示例中是相对于流媒体数据描述的，但是本公开内容的技术可以应用于通过选择性地使用一个或多个服务和/或分发模式在一个或多个网络上获取任何类型的数据。
在HTTP流传输中，频繁使用的操作包括HEAD、GET和部分GET。 HEAD操作取回与给定统一资源定位符(URL)或统一资源名称(URN) 相关联的文件的报头，而不取回与该URL或URN相关联的有效载荷。GET 操作取回与给定URL或URN相关联的整个文件。部分GET操作接收作为输入参数的字节范围并取回对应于该接收的字节范围的文件的连续数个字节。因此，电影片段可以提供给HTTP流传输，因为部分GET操作能够获得一个或多个独立的电影片段。在一个电影片段中，可以有若干个不同轨道的轨道片段。在HTTP流传输中，媒体呈现可以是客户端可访问的数据的结构化集合。客户端可以请求并下载媒体数据信息以便向用户呈现流服务。
在使用HTTP流传输对3GPP数据进行流传输的示例中，可以有多个针对多媒体内容的视频和/或音频数据的表示。不同表示可以对应于不同的编码特征(例如，视频编码标准的不同简档或级别)，不同编码标准或编码标准的扩展(诸如多视图和/或可伸缩扩展)或不同比特率。这些表示的清单可以在媒体呈现描述(MPD)数据结构中定义。媒体呈现可以对应于HTTP 流客户端设备可访问的数据的结构化集合。该HTTP流客户端设备可以请求并下载媒体数据信息以便将流服务呈现给客户端设备的用户。媒体呈现可以在MPD数据结构中描述，其可以包括MPD的更新。
媒体呈现可以包含一个或多个周期的序列。周期可以由MPD中的周期 (Period)元素定义。每个周期在MPD中具有属性开始(start)。MPD可以包括每个周期的开始(start)属性和可用开始时间(availableStartTime) 属性。对于实况服务，周期的开始(start)属性和MPD属性可用开始时间(availableStartTime)之和可以指定该周期在UTC格式中的可用时间，尤其是相应周期中每个表示的第一媒体分段。对于按需服务，第一周期的开始(start)属性可以是0。对于任何其它周期，该开始(start)属性可以指定相应周期的开始时间相对于第一周期的开始时间之间的时间偏差。每个周期可以延伸直到下一周期的开始，或者在最后一个周期的情况中直到媒体呈现的结束。周期开始时间可以是精确的。它们可以反映从播放所有先前周期的媒体得出的实际时序。
每个周期可以包含针对相同媒体内容的一种或多种表示。一种表示可以是音频或视频数据的数个替代性编码版本中的一种。这些表示可以通过编码类型来区分，例如通过针对视频数据的比特率、分辨率和/或编解码和针对音频数据的比特率、语言和/或编解码。术语表示可以用于指编码后的音频或视频数据的对应于多媒体内容的特定周期并且以特定方式编码的部分。
特定周期的表示可以被指派给由MPD中的属性指示的组。相同自适应集合中的表示一般被认为可以相互替代，因为，客户端设备能够动态地并且无缝地在这些表示之间切换，例如以便执行带宽自适应。例如，针对特定周期的视频数据的每种表示可以被指派给相同的自适应集合，这样任何表示可以被选择用于解码以便呈现针对相应周期的多媒体内容的媒体数据 (诸如视频数据或音频数据)。在一些示例中，一个周期中的媒体内容可以由组0中的一个表示(如果存在)来表示，或者由来自每个非零组的最多一个表示的组合来表示。周期的每个表示的时序数据可以相对于该周期的开始时间来表达。
表示可以包括一个或多个分段。每个表示可以包括初始化分段，或者表示的每个分段可以是自初始化的。当呈现时，初始化分段可以包含用于访问该表示的初始化信息。一般而言，该初始化分段不包含媒体数据。分段可以由标识符唯一地引用，诸如URL、URN或统一资源标识符(URI)。 MPD可以为每个分段提供标识符。在一些示例中，MPD还可以以范围 (range)属性的形式提供字节范围，其可以对应于通过URL、URN或URI 可访问的文件中的分段的数据。
可以对针对不同类型的媒体数据的基本同时取回选择不同表示。例如，客户端设备可以选择从其取回分段的音频表示，视频表示和时序化文本表示。在一些示例中，客户端设备可以选择特定自适应集合以执行带宽自适应。也就是，客户端设备可以选择包括视频表示的自适应集合、包括音频表示的自适应集合和/或包括时序化文本的自适应集合。作为替代，客户端设备可以针对某些类型的媒体(例如，视频)选择自适应集合，并且直接选择针对其它类型的媒体(例如，音频和/或时序化文本)的表示。
每个表示还可以包括一个或多个媒体分量，其中每个媒体分量可以对应于一个单个媒体类型(诸如音频、视频或时序化文本(例如，针对隐藏字幕))的编码后版本。媒体分量可以时间连续地穿过一个表示中的连续媒体分段的边界。
本申请所描述的技术可用于各种有线或无线通信网络，诸如CDMA、 TDMA、FDMA、OFDMA、SC-FDMA和其它网络。术语“网络”与“系统”通常可互换地使用。CDMA网络可实施诸如通用陆地无线电接入(UTRA)、 CMDA2000等的无线电技术。UTRA包括宽带CDMA(WCDMA)、和CDMA 的其它变形。CDMA2000涵盖IS-2000、IS-95以及IS-856标准。TDMA网络可实施诸如全球移动通信系统(GSM)的无线电技术。OFDMA网络可实施诸如演进型UTRA(E-UTRA)、超移动宽带(UMB)、IEEE802.11 (Wi-Fi)、IEEE 802.16(WiMAX)、IEEE802.20、Flash-OFDMA等的无线电技术。UTRA和E-UTRAN是通用移动通信系统(UMTS)的一部分。3GPP 长期演进(LTE)和高级LTE(LTE-A)是使用E-UTRA的UMTS的新版本。在来自名为“第三代合作伙伴计划(3rd Generation Partnership Project)” (3GPP)的组织的文献中描述了UTRA、E-UTRA、UMTS、LTE、LTE-A 以及GSM。在来自名为“第三代合作伙伴计划2(3rd Generation Partnership Project2)”(3GPP2)的组织的文献中描述了CDMA2000和UMB。本申请中描述的技术可以用于上面提到的无线网络和无线技术以及其它无线网络和无线技术。为了清楚，下面针对LTE描述本技术的某些方面，并且在下面的很多描述中使用了LTE术语。
在各种网络中，内容可以经由单播或广播分发。当UE请求内容时，针对该内容的MBMS用户服务可能不可用，并且因此该MBMS客户端并不参与其中。在一些示例中，诸如当UE进入网络的不同区域时，或者当该网络的设备确定有足够的UE正在访问该内容时，该网络的设备可以启用 MBMS承载服务。当该网络的设备决定针对该内容启用MBMS传输时，例如基于高附连率，需要一种方式激活请求该内容的UE的MBMS客户端。在一个示例中，本公开内容提出包括本地代理，使得该本地代理将会在其获得网络重定向时激活该MBMS客户端。也就是，UE可以包括针对单播服务的本地代理，使得该UE能够潜在地切换到MBMS用户服务。另外，该MBMS客户端可以开始经由广播或多播分发模式从MBMS用户服务接收数据，并且该本地代理可以使UE借此能够从单播分发模式切换到广播分发模式。通过包括本地代理，应用不知道单播承载还是MBMS承载用于内容分发以及使用单播还是广播分发模式。也就是，在一些示例中，内容要分发到的应用不需要接收关于该内容是经由单播、广播还是多播分发模式进行分发的信息。
本申请中描述的技术可以提供MBMS用户服务的动态建立，以基于实时或非实时地卸载某些内容的单播分发，该MBMS用户服务由于那些内容的受欢迎度而达到某个业务量。此外，本申请中描述的技术可以提供先前建立的MBMS用户服务由于其消耗的后续减少而终止。还描述了配置用于支持这种按需MBMS的BM-SC和UE的功能方面。也就是，本公开内容可以提供在MooD背景中的单播网络架构和高级MBMS的描述、示出MooD 操作的示例的消息序列图示，和/或可以实现MooD操作的解决方案框架的描述(例如，包括配置数据)，以及BM-SC和UE之间的交互，其中该交互用于针对新建立的MBMS用户服务的接收而激活或触发MBMS客户端，以及报告MBMS服务的正在进行的消耗以实现针对该服务的正在进行的需求的测量。
本公开内容的技术可以提供MBMS服务的动态的并且基于需要的供应。也就是，MBMS用户服务不需要由服务供应商(例如，移动网络运营商)静态地或在某些时间上变化地供应。依照本申请中描述的技术，服务供应商可以使用经由单播承载的内容消耗的实时、基于需要的测量，以便实现动态地转换到通过MBMS承载进行分发。例如，使用本申请中所描述的技术，服务供应商一旦检测到由多个UE对公共地理区域中的同一内容或服务的足够高速率/大量的单播访问，就可以以动态方式将单播服务转换到用于广播分发的MBMS用户服务。此外，本申请中描述的技术可以提供对用于服务供应商网络向UE指示单播服务进行MBMS用户服务转换的资格的单元，以及可以使当前正经由单播服务消耗内容的UE能够通知服务供应商网络关于该UE通过广播服务接收内容的能力(或者缺少该能力)的规范化描述。
本申请中描述的技术可以另外或者作为替代包括MBMS服务的动态且基于需要的终止。也就是，本公开内容提供方法，可以由服务供应商网络用于终止正在进行的MBMS用户服务。例如，当网络中的设备确定已经超过MBMS用户服务注销事件的某个阈值(例如，由内容供应商和/或服务供应商设置的)，或者实际内容消耗的某一形式的基于网络的计数低于某个最小等级，则可以触发网络发起的MBMS用户服务终止。
本公开内容的技术可以另外或者作为替代提供服务供应商网络(例如，服务供应商网络中的BM-SC)可以用于以可伸缩的方式通知MBMS功能 UE关于潜在MBMS用户服务的方法。潜在MBMS用户服务可以是潜在地可以被迁移到MBMS用户服务的非MBMS用户服务。例如，本申请中描述的技术可以使该网络能够使用静态配置工作，其中，UE被配置为使得某些服务总是潜在MBMS用户服务。举另一个例子，该网络可以使用设备管理方法，在该方法中网络运营商可以动态配置UE，使得某些服务是MBMS 用户服务。举另一个例子，网络的设备可以通过使用将服务宣布为特定 MBMS用户服务的特定USD经由MBMS用户服务的使用通知UE。此外，本申请中描述的技术可以使UE能够连续地通知服务供应商网络(例如， BM-SC)关于潜在MBMS用户服务的消耗。在一些示例中，UE还可以通知服务供应商网络其它信息，诸如位置或消耗元数据。例如，UE可以直接注册服务并使用特定API或协议保持BM-SC得到通知。举另一个例子， UE可以使用依照配置生成的(例如针对特定代理)，用查询参数和/或cookie 增强的特定HTTP请求。
本申请中描述的技术还可以使服务供应商网络能够建立并向当前消耗服务的MBMS功能UE，或者一旦MBMS用户服务已经建立向加入潜在 MBMS用户服务的MBMS功能UE宣布MBMS用户服务。例如，该网络的设备可以使用在配置中定义的预配置的API/协议向MBMS功能UE发送 USD。举另一个例子，该网络的设备可以将USD作为服务分配的一部分(作为服务协议的一部分或者格式的一部分)来发送USD。另外，本申请中描述的技术可以使UE能够以可伸缩的方式连续地通知服务供应商网络(例如，BM-SC)关于该UE的消耗，在一些示例中包括通知服务供应商网络关于UE的服务终止。
在各个示例中，本公开内容的技术可以基于一个或多个假设。例如，在一些示例中，本申请中描述的技术可以基于下面关于MBMS用户服务的单播和广播分发模式之间的动态切换的假设：首先，可以假设商业协定使运营商(例如，服务供应商网络的运营商)能够根据标称单播内容或服务的高需求将各种内容源从单播转换到广播分发；其次，可以假设运营商想要考虑UE能力、UE位置和用户的动作(诸如时移等等)，以准确地计数服务的消耗。当然，应该了解的是本公开内容的技术不要求这些假设的任何一个。
图1是描绘了实施用于通过网络对媒体数据进行流传输的技术的示例性系统10的框图。在这个示例中，系统10包括内容准备设备20、服务器设备60和客户端设备40。客户端设备40和服务器设备60通过网络74通信地耦合，该网络可以包括互联网。在一些示例中，内容准备设备20和服务器设备60还可以通过网络74或另一个网络耦合，或者可以直接通信地耦合。在一些示例中，内容准备设备20和服务器设备60可以包括相同的设备。
在图1的示例中，内容准备设备20包括音频源22和视频源24。音频源22可以包括，例如产生代表捕捉到的将由音频编码器26编码的音频数据的电信号的麦克风。作为替代，音频源22可以包括存储先前记录的音频数据的存储介质，诸如计算机化合成器这样的音频数据生成器或任何其它音频数据源。视频源24可以包括产生将由视频编码器28编码的视频数据的视频相机，用先前记录的视频数据编码的存储介质，诸如计算机图形源的视频数据生成单元或任何其它视频数据源。在所有示例中内容准备设备 20都不需要通信地耦合到服务器设备60，但是可以将多媒体内容存储到由服务器设备60读取的单独介质。
原始的音频和视频数据可以包括模拟或数字数据。模拟数据可以在由音频编码器26和/或视频编码器28编码之前被数字化。音频源22可以在说话参与者讲话时从该说话参与者获取音频数据，而视频源24可以同时获取该说话参与者的视频数据。在其它示例中，音频源22可以包括包含有存储的音频数据的计算机可读取存储介质，而视频源24可以包括包含有存储的视频数据的计算机可读取存储介质。以这种方式，本公开内容中描述的技术可以应用于实况、流传输、实时音频和视频数据或应用于归档的、预先记录的音频和视频数据。
对应于视频帧的音频帧一般是包含由音频源22捕捉的(或生成的)，与该视频帧中包含的由视频源24捕捉的(或生成的)视频数据同时发生的音频数据的音频帧。例如，当说话参与者一般通过说话产生音频时，音频源22捕捉音频数据，而视频源24同时捕捉该说话参与者的视频数据，也就是在音频源22捕捉音频数据的同时。因此，音频帧可以时间上对应于一个或多个特定视频帧。因此，对应于视频帧的音频帧一般对应于音频数据和视频数据是被同时捕捉到的情况，并且针对这种情况音频帧和视频帧分别包括同时被捕捉到的音频数据和视频数据。
在一些示例中，音频编码器26可以在每个编码后的音频帧中编码入时间戳，其代表记录用于该编码的音频帧的音频数据的时间，并且类似的，视频编码器28可以在每个编码后的视频帧中编码入时间戳，其代表记录编码的视频帧的视频数据的时间。在这些示例中，对应于视频帧的音频帧可以包括包含时间戳的音频帧以及包含相同时间戳的视频帧。内容准备设备 20可以包括内部时钟，音频编码器26和/或视频编码器28可以从该内部时钟生成时间戳，或者音频源22和视频源24可以分别使用该内部时钟将音频和视频数据与时间戳相关联。
在一些示例中，音频源22可以向音频编码器26发送对应于记录音频数据的时间的数据，而视频源24可以向视频编码器28发送对应于记录视频数据的时间的数据。在一些示例中，音频编码器26可以将序列标识符编码到编码后的音频数据中以便指示编码的音频数据的相对时间排序，而不需要指示记录该音频数据的绝对时间，并且类似的，视频编码器28还可以使用序列标识符以指示编码后的视频数据的相对时间排序。类似的，在一些示例中，序列标识符可以与时间戳相映射或者相关联。
音频编码器26一般产生编码后的音频数据流，而视频编码器28产生编码后的视频数据流。每个单独的数据流(无论音频还是视频)可以称为基本流。基本流是表示的单个的、数字编码后的(可能压缩后的)分量。例如，该表示的编码后视频或音频部分可以是基本流。基本流可以在被封装到视频文件中之前被转换为分组化基本流(PES)。在相同表示中，流ID 可以用于相互区分属于一个基本流的PES分组。基本流的数据的基本单元是分组化的基本流(PES)分组。因此，编码的视频数据一般对应于基本视频流。类似地，音频数据对应于一个或多个相应基本流。
例如ITU-T H.264/AVC和即将到来的高效视频编码(HEVC)标准等许多视频编码标准定义用于无误差比特流的语法、语义和解码过程，所述无误差比特流中的任一者符合某简档或层级。视频编码标准通常并不指定编码器，但编码器具有保证所产生的比特流对于解码器来说是遵循标准的任务。在视频编码标准的上下文中，“简档”对应于适用于视频编码标准的算法、特征或工具及约束的子集。举例来说，如通过H.264标准所定义，“简档”是通过H.264标准指定的整个比特流语法的子集。“层级”对应于解码器资源消耗的限制，例如，举例来说，解码器存储器和计算，其涉及图片分辨率、比特速率和块处理速率。可使用profile_idc(简档指示符)值用信号表示简档，而可使用level_idc(层级指示符)值用信号表示层级。
举例来说，H.264标准认为，在给定简档的语法所强加的界限内，仍然可能需要编码器和解码器的性能有较大变化，这取决于比特流中的(例如经解码图片的指定尺寸)语法元素所取的值等。H.264标准进一步认为，在许多应用中，实施能够处理特定简档内的语法的所有假设使用的解码器既不实际又不经济。因此，H.264标准将“层级”定义为强加于位流中的语法元素值的指定约束集合。这些约束可为对值的简单限制。或者，这些约束可采用对值的算术组合(例如，图片宽度乘以图片高度乘以每秒解码的图片数目)的约束的形式。H.264标准进一步提供，各个实施方案可对于每一所支持的简档支持不同层级。
符合简档的解码器通常支持简档中定义的所有特征。举例来说，作为编码特征，B图片编码在H.264/AVC的基本简档中不被支持，但在 H.264/AVC的其它简档中被支持。符合层级的解码器应能够对任何不需要超出所述层级中定义的限制的资源的位流进行解码。简档和层级的定义可对可解释性有帮助。举例来说，在视频传输期间，可针对整个传输会话协商和同意一对简档和层级定义。更确切地说，在H.264/AVC中，层级可定义对于需要处理的宏块数目、经解码图片缓存(DPB)大小、经编码图片缓存(CPB)大小、垂直运动向量范围、每两个连续MB的运动向量的最大数目和B块是否可具有小于8x8像素的子宏块分区的限制。以此方式，解码器可确定解码器是否能够恰当地对比特流进行解码。
在图1的示例中，内容准备设备20的封装单元30从视频编码器28接收包括编码的视频数据的基本流，且从音频编码器26接收包括编码的音频数据的基本流。在一些实例中，视频编码器28和音频编码器26可各自包含用于从经编码数据形成PES分组的分组化器。在其它实例中，视频编码器28和音频编码器26可各自与用于从经编码数据形成PES分组的相应分组化器对接。在另外其它实例中，封装单元30可包含用于从经编码音频和视频数据形成PES分组的分组化器。
视频编码器28可用多种方式对多媒体内容的视频数据进行编码，以便以各种比特速率且用各种特性生成多媒体内容的不同表示，所述特性例如是像素分辨率、帧速率、对各种编码标准的符合性、对针对各种编码标准的各种简档和/或简档层级的符合性、具有一个或多个视图的表示(例如，对于二维或三维回放)或其它这样的特性。如本公开内容中所使用，表示可包括音频数据、视频数据、文本数据(例如，针对隐藏字幕)或其它这样的数据其中之一。该表示可以包括基本流，诸如音频基本流或视频基本流。每一PES分组可包含stream_id，其标识PES分组所属于的基本流。封装单元30负责将基本流组装成各种表示的视频文件(例如，分段)。
封装单元30从音频编码器26和视频编码器28接收用于表示的基本流的PES分组且从所述PES分组形成对应的网络抽象层(NAL)单元。在 H.264/AVC(高级视频编码)的实例中，编码的视频分段被组织成NAL单元，所述NAL单元提供“网络友好”的视频表示，其处理例如视频电话、存储、广播或流传输的应用。NAL单元可分类为视频编码层(VCL)NAL单元和非VCL NAL单元。VCL单元可含有核心压缩引擎，并且可包含块、宏块和/或切片层级数据。其它NAL单元可以是非VCL NAL单元。在一些示例中，一个时间实例中的编码的图片(通常呈现为基本编码的图片)可包含在访问单元中，所述访问单元可包含一或多个NAL单元。
尤其是，非VCL NAL单元可包含参数集NAL单元和SEI NAL单元。参数集可包含序列层级报头信息(在序列参数集(SPS)中)和不频繁改变的图片层级报头信息(在图片参数集(PPS)中)。对于参数集(例如，PPS 和SPS)，不频繁改变的信息不需要针对每一序列或图片重复，因此可提高编码效率。另外，使用参数集可实现重要报头信息的带外传输，从而避免需要用于容错的冗余传输。在带外传输示例中，参数集NAL单元可在与其它NAL单元(例如SEI NAL单元)不同的信道上传输。
补充增强信息(SEI)可包含对于对来自VCL NAL单元的编码的图片采样进行解码不是必需的信息，但可辅助与解码、显示、容错和其它目的有关的处理过程。非VCL NAL单元中可含有SEI消息。SEI消息是一些标准规范的规范性部分，并且因而对于遵循标准的解码器实施方案并非总是强制性的。SEI消息可以是序列层级SEI消息或图片层级SEI消息。SEI消息中可含有一些序列层级信息，所述SEI消息诸如是SVC的示例中的可伸缩性信息SEI消息，和MVC中的视图可缩放性信息SEI消息。这些示例 SEI消息可传送关于例如操作点的提取和操作点的特性的信息。此外，封装单元30可形成清单文件，诸如描述表示的特性的媒体呈现描述符(MPD)。封装单元30可根据可扩展标记语言(XML)将MPD格式化。在一些示例中，清单文件(诸如清单文件66)将各个表示(例如，表示68)的标识符映射到相应资源位置。也就是，该清单文件可以包括指示从哪能够获取表示(或者其一部分)的信息。在一些示例中，该资源位置可以是统一资源定位符(URL)、统一资源标识符(URI)和/或其它位置标识符。例如，清单文件可以包括定义用于各个表示的分段的URL的数据。
封装单元30可向输出接口32提供用于多媒体内容的一或多个表示的数据连同清单文件(例如，MPD)。输出接口32可包括网络接口或用于向存储介质进行写入的接口，例如通用串行总线(USB)接口、CD或DVD 写入器或烧录器、到磁性或闪速存储介质的接口，或用于存储或发送媒体数据的其它接口。封装单元30可向输出接口32提供多媒体内容的表示中的每一个表示的数据，所述输出接口32可经由网络传输或存储介质向服务器设备60发送所述数据。在图1的示例中，服务器设备60包含存储介质 62，其存储各种多媒体内容64，每一多媒体内容64包含相应的清单文件 66以及一个或多个表示68A-68N(表示68)。在一些实例中，输出接口32 还可向网络74直接发送数据。
在一些示例中，表示68可分成自适应集合。也就是说，表示68的各个子集可包含特性的相应共同集合，例如编解码、简档和层级、分辨率、视图数目、分段的文件格式、可标识与(例如，由说话者)解码和呈现的音频数据和/或表示一起显示的文本的语言或其它特性的文本类型信息、可描述自适应集合中的用于表示的场景的相机角度或现实世界相机视角的相机角度信息、描述对于特定受众的内容适合性的评级信息等等。
清单文件66可包含指示对应于特定自适应集合的表示68的子集以及针对所述自适应集合的共同特性的数据。清单文件66还可包含表示针对自适应集合的各个表示的各个特性(例如比特速率)的数据。以此方式，自适应集合可提供简化的网络带宽自适应。自适应集合中的表示可使用清单文件66的自适应集合元素的子元素来指示。
服务器设备60包括请求处理单元70和网络接口72。在一些示例中，服务器设备60可包括多个网络接口。此外，服务器设备60的特征中的任何或全部特征可在内容分发网络的其它设备(例如路由器、桥接器、代理设备、交换机或其它设备)上实施。在一些示例中，内容分发网络的中间设备可缓存多媒体内容64的数据，且包含基本上与服务器设备60的部件相符的部件。一般来说，网络接口72被配置为经由网络74发送和接收数据。
请求处理单元70被配置为从客户端设备(诸如客户端设备40)接收针对存储介质62的数据的网络请求。举例来说，请求处理单元70可实施超文本传输协议(HTTP)版本1.1，如费尔丁(Fielding)等人的“H ypertext Transfer Protocol-HTTP/1.1(超文本传输协议-HTTP/1.1)”(1999年6月，互联网工程任务组(IETF)，RFC 2616)所描述。也就是说，请求处理单元 70可被配置为接收HTTP GET或部分GET请求，并且提供多媒体内容64 的数据作为对该请求的响应。所述请求可例如使用表示68之一的分段的 URL来指定所述分段。在一些示例中，所述请求还可指定所述分段的一或多个字节范围，从而包括部分GET请求。请求处理单元70还可以进一步被配置为服务于HTTP HEAD请求以提供表示68之一的分段的报头数据。在任何情况下，请求处理单元70可以被配置为处理所述请求以向请求设备 (例如客户端设备40)提供所请求的数据。
另外或作为替代，请求处理单元70可以被配置为经由广播或多播协议 (诸如eMBMS)分发媒体数据。内容准备设备20可以以与所描述大体上相同的方式创建DASH分段和/或子分段，但服务器设备60可使用eMBMS 或者另一广播或多播网络传输协议分发这些分段或子分段。举例来说，请求处理单元70可以被配置为从客户端设备40接收多播组加入请求。也就是说，服务器设备60可向客户端设备(包括客户端设备40)通告与多播组相关联的互联网协议(IP)地址，其中该多播组与特定媒体内容(例如，实况事件的广播)相关联。客户端设备40接着可以提交加入所述多播组的请求。此请求可遍及网络74(例如构成网络74的路由器)传播，使得导致所述路由器将去往与多播组相关联的IP地址的业务导向订制的客户端设备 (例如客户端设备40)。
如图1的示例中说明，多媒体内容64包含清单文件66，其可对应于媒体呈现描述(MPD)。清单文件66可包括不同替代表示68(例如，具有不同质量的视频服务)的描述，并且所述描述可包含例如编解码器信息、简档值、层级值、比特速率和表示68的其它描述性特性。客户端设备40可取回媒体呈现的MPD以确定如何访问表示68的分段。
特别地，取回单元52可取回客户端设备40的配置数据(未示出)以确定视频解码器48的解码能力和视频输出44的渲染能力。配置数据还可包含客户端设备40的用户选择的语言偏好中的任何一个或全部、对应于客户端设备40的用户设定的深度偏好的一或多个相机视角，和/或客户端设备 40的用户选择的评级偏好。举例来说，取回单元52可包括网络浏览器或媒体客户端，它们被配置为提交HTTP GET和部分GET请求。取回单元52可对应于客户端设备40的一或多个处理器或处理单元(未示出)执行的软件指令。在一些示例中，相对于取回单元52描述的功能中的全部或部分可在硬件或硬件、软件和/或固件的组合中实施，其中可提供必需的硬件以执行针对软件或固件的指令。
取回单元52可将客户端设备40的解码和渲染能力与清单文件66的信息所指示的表示68的特性进行比较。取回单元52可初始地取回清单文件 66的至少一部分以确定表示68的特性。举例来说，取回单元52可请求清单文件66的描述一或多个自适应集合的特性的部分。取回单元52可选择具有客户端设备40的编码和渲染能力可满足的特性的表示68的子集(例如，自适应集合)。取回单元52可接着确定所述自适应集合中的表示的比特速率、确定网络带宽的当前可用量，并且从具有网络带宽可满足的比特速率的表示之一取回分段。
一般来讲，较高比特速率表示可产生较高质量视频回放，而在可用的网络带宽减少时较低比特速率表示可提供足够质量的视频回放。因此，当可用的网络带宽相对高时，取回单元52可从相对高的比特速率表示取回数据，而当可用的网络带宽较低时，取回单元52可从相对低的比特速率表示取回数据。以此方式，客户端设备40可经由网络74对多媒体数据进行流传输，同时还根据网络74的变化的网络带宽可用性进行调适。
另外或作为替代，取回单元52可以被配置为根据例如eMBMS或IP 多播的广播或多播网络协议接收数据。在这样的示例中，取回单元52可提交加入与特定媒体内容相关联的多播网络组的请求。在加入多播组之后，取回单元52可在没有向服务器设备60或内容准备设备20发出的进一步请求的情况下接收多播组的数据。取回单元52可以在不再需要多播组的数据时提交离开多播组的请求，例如停止回放或将信道改变到不同多播组。
网络接口54可接收所选表示的分段的数据并提供给取回单元52，所述取回单元52接着可向解封装单元50提供所述分段。解封装单元50可将视频文件的元素解封装成组成PES流，将PES流解分组化以取回经编码数据，且根据经编码数据是音频流还是视频流的一部分(例如，如通过流的PES 分组报头所指示)而向音频解码器46或视频解码器48发送经编码数据。音频解码器46对经编码音频数据进行解码，且向音频输出42发送经解码音频数据，而视频解码器48对经编码视频数据进行解码，且向视频输出44 发送所述经解码视频数据，其可包含流的多个视图。
视频编码器28、视频解码器48、音频编码器26、音频解码器46、封装单元30、取回单元52和解封装单元50各自可实施为适用的多种合适的处理电路中的任何一种，所述处理电路例如是一或多个微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、离散逻辑电路、软件、硬件、固件或其任何组合。视频编码器28和视频解码器48中的每一者可包含在一或多个编码器或解码器中，所述编码器或解码器中的任一者可集成为组合视频编码器/解码器(编解码器)的一部分。同样，音频编码器26和音频解码器46中的每一者可包含在一或多个编码器或解码器中，所述编码器或解码器中的任一者可集成为组合编解码器的一部分。包含视频编码器28、视频解码器48、音频编码器26、音频解码器 46、封装单元30、取回单元52和/或解封装单元50的装置可包括集成电路、微处理器和/或无线通信设备，例如蜂窝式电话。
客户端设备40、服务器设备60和/或内容准备设备20可配置为根据本公开内容的技术进行操作。出于示例的目的，本公开内容相对于客户端设备40和服务器设备60描述这些技术。然而，应理解的是内容准备设备20 可被配置为代替(或附加于)服务器设备60执行这些技术。
封装单元30可形成NAL单元，所述NAL单元包括标识NAL所属的程序的报头，以及有效载荷(例如音频数据、视频数据或描述NAL单元对应于的传输或程序流的数据)。举例来说，在H.264/AVC中，NAL单元包含1-字节报头和变化大小的有效载荷。在其有效载荷中包含视频数据的 NAL单元可包括各种粒度水平的视频数据。举例来说，NAL单元可包括视频数据块、多个块、视频数据的切片，或视频数据的整个图片。封装单元 30可从视频编码器28接收基本流的PES分组形式的经编码的视频数据。封装单元30可使每一基本流与对应程序相关联。
封装单元30还可组装来自多个NAL单元的访问单元。一般来说，访问单元可包括用于表示视频数据的帧以及对应于所述帧的音频数据(当该音频数据可用时)的一或多个NAL单元。访问单元通常包含针对一个输出时间实例的所有NAL单元，例如针对一个时间实例的所有音频和视频数据。举例来说，如果每一视图具有20帧/秒(fps)的帧速率，那么每一时间实例可对应于0.05秒的时间间隔。在此时间间隔期间，用于相同访问单元的所有视图的特定帧(相同时间实例)可以被同时渲染。在一个示例中，访问单元可包括一个时间实例中的经编码图片，其可呈现为初级经译码图片。
因此，访问单元可包括共同时间实例的所有音频和视频帧，例如对应于时间X的所有视图。本公开内容还将特定视图的经编码图片称为“视图分量”。也就是说，视图分量可包括在特定时间针对特定视图的经编码图片(或帧)。因此，访问单元可被定义为包括共同时间实例的所有视图分量。访问单元的解码次序不需要必定与输出或显示次序相同。
媒体呈现可包含媒体呈现描述(MPD)，其可包括不同替代表示(例如，具有不同质量的视频服务)的描述，且所述描述可包含例如编解码器信息、简档值和层级值。MPD是如清单文件66的清单文件的一个示例。客户端设备40可取回媒体呈现的MPD以确定如何访问各种呈现的电影片段。电影片段可位于视频文件的电影片段框(box)(moof框)中。
清单文件66(例如，其可以包括MPD)可以通告表示68的分段的可用性。也就是说，MPD可以包括指示表示68之一的第一分段变为可用的时钟时间的信息，以及指示表示68中的分段的持续时间的信息。以此方式，客户端设备40的取回单元52可以基于特定分段之前的分段的开始时间及其持续时间确定每个分段何时可用。
在封装单元30已基于所接收数据将NAL单元和/或访问单元组装到视频文件中之后，封装单元30将视频文件传递到输出接口32以用于输出。在一些示例中，封装单元30可将视频文件本地存储，或经由输出接口32 将视频文件发送到远程服务器，而非将视频文件直接发送到客户端设备40。输出接口32可包括，例如发射机、收发机、用于将数据写入到计算机可读介质的设备，诸如例如光盘驱动器、磁性媒体驱动器(例如，软盘驱动器)、通用串行总线(USB)端口、网络接口，或其它输出接口。输出接口32将视频文件输出到计算机可读介质34，诸如例如传输信号、磁性介质、光学介质、存储器、闪存驱动器，或其它计算机可读介质。
网络接口54可经由网络74接收NAL单元或访问单元，且经由取回单元52将NAL单元或访问单元提供给解封装单元50。解封装单元50可将视频文件的元素解封装成组成PES流，将PES流解分组以取回经编码数据，且依据经编码数据是音频流还是视频流的一部分(例如，如通过流的PES 分组报头所指示)而向音频解码器46或视频解码器48发送经编码数据。音频解码器46对经编码音频数据进行解码，且向音频输出42发送经解码音频数据，而视频解码器48对经编码视频数据进行解码，且向视频输出44 发送所述经解码视频数据，其可包含流的多个视图。
以此方式，客户端设备40表示用于取回媒体数据的设备的示例，该设备包括用于依照本公开内容的一个或多个方面接收关于要经由第一服务还是第二服务接收内容服务的媒体数据的指示的单元。当该指示指出该媒体数据要经由第一服务接收时，客户端设备40可以禁用用于经由第二服务接收数据的单元并经由第一服务接收该媒体数据。作为替代，当该指示指出该媒体数据要经由第二服务接收时，客户端设备40可以激活用于经由第二服务接收数据的单元并从所述用于经由第二服务接收数据的单元接收该媒体数据。所述用于经由第二服务接收数据的单元可以经由广播或多播分发模式接收该媒体数据。
换句话说，本公开内容的技术针对经由单播和广播传输的中介内容分发。也就是说，本公开内容提供用于在非MBMS单播服务被网络转换到 MBMS用户服务时激活MBMS中间件的各种技术。在各个示例中，本公开内容既包括基于UE的解决方案也包括基于网络的解决方案，所述方案包括中介层用于触发客户端(例如，eMBMS客户端)在从单播和广播(或多播) 服务接收数据与潜在地经由广播(或多播)服务的单播和广播(或多播) 分发模式接收数据之间切换。在示例性的基于UE的解决方案中，在任何应用运行时激活MBMS中间件。可以用应用预先配置该UE，该应用潜在地能够被切换到广播内容以避免针对所有应用都触发MBMS中间件。在示例性的基于网络的解决方案中，一旦UE从网络接收到一些“指示”或“触发”就激活MBMS中间件。在一些示例中，如果网络的设备具有关于各个UE的能力的信息，则该设备(例如，该网络中的BM-SC)可以确定正在从单播服务接收数据的UE是否具有MooD功能(例如，能够切换到经由MBMS 用户服务接收数据)。例如，该网络的设备(例如，OMA-DM服务器)可以向MooD功能UE发送MooD配置数据，同时确保非MooD功能UE将不会使用该MooD配置中指定的代理服务器。在高通公司向SA4#78投稿的 S4-140327，“MI-MooD：MBMSService Configuration”中进一步描述了MooD 配置，其整个内容以引用的方式并入本文。
所述指示可以是使UE接收USD并且接下来在MBMS承载上接收数据的触发，或者它可以是USD本身。在一些示例中，网络的设备(例如，BM-SC) 可以通过宣告新的MBMS用户服务及其在广播和/或单播分发上的可用性来发送USD或更新后的USD(例如，如果其它MBMS服务已经在使用中)。在一些示例中，该USD或更新后的USD可以使用userServiceDescription(用户服务描述)元素的deliveryMethod(分发方法)子元素下面的 r12:broadcastAppService(r12：广播App服务)和/或r12:unicastAppService (r12：单播App服务)元素来标识该内容是通过广播和/或单播传输携带的。在一些示例中，为了支持应用服务访问的基于移动性的传输切换和单播回滚而定义的现有机制(例如，如3GPP TS 26.346的部分7.6“Multimedia Broadcast/Multicast Service(MBMS)；Protocols and codecs”中所找到的)也可以应用于MooD操作。
在一些示例中，USD或更新后的USD可以利用userServiceDescription (用户服务描述)元素的r12:appService(r12：App服务)子元素，依照 MooD操作或网络策略要求(例如，当UE被重定向到广播接收并且该UE 在MBMS覆盖范围内时只允许内容的广播接收的要求)来提供能够相互替代的应用服务内容条目的一致的或替代性的版本的标识。更新后的USD中可以包含描述广播和单播表示两者的统一的MPD(例如，经由对应的媒体呈现描述片段)以便使UE能够将通过单播接收到的服务与MBMS用户服务相关联。
在一些示例中，如果BM-SC已经建立了针对USD分发的单向传输文件分发(FLUTE)会话，则BM-SC可以在该广播信道上发送USD(或更新后的USD)。否则，BM-SC可以使用现有MBMS会话建立过程建立用于发送USD或更新后的USD的FLUTE会话。在T.Paila等人的“FLUTE-File Delivery over Unidirectional Transport”(2012年11月，IETF，RFC 6726) 中描述了FLUTE。
一旦已经针对新建立的MBMS用户设备准备好USD/更新后的USD，网络的设备(例如，BM-SC)可以向UE发送重定向/触发消息以便将该UE 重定向为从单播切换到广播接收。举第一个例子，网络的设备可以与HTTP 响应中提供的内容一起发送指示以触发UE通过单播或MBMS承载访问所述USD/更新后的USD。例如，作为对内容请求的响应，网络的设备可以发送具有3GPP扩展报头的HTTP 200OK消息，其中该3GPP扩展报头包含用于触发UE的USD/更新后USD的接收的指示。也就是说，所述HTTP 200 OK消息可以包括UE已经请求的内容以及所述重定向。举另一个例子，作为对内容请求的响应，网络的设备可以发送具有3GPP扩展报头的HTTP 3xx重定向消息，其中该消息提示UE初始化该USD/更新后USD的接收。该HTTP 3xx重定向消息中包含的重定向URL可以表示相同的被请求资源的不同位置。举例来说，如果原始请求URL是 http://example.com/per-x/rep-y/seg-z.3gp，则重定向URL可以是 http://example.com/redirect/per-x/rep-y/seg-z.3gp。3GPP定义的HTTP扩展报头可以命名为具有值“获取USD”的“触发MBMS”。因此，对UE的内容请求的具有3xx状态码的HTTP响应消息可以伴随有响应报头“触发MBMS：获取USD”。
为了UE在常规重定向消息(例如，HTTP重定向状态码或RTSP重定向请求)和MBMS卸载请求之间进行区分，可以使用新的报头字段(例如， MooD报头字段)。该MooD报头字段可以应用于RTSP和HTTP重定向二者。如果UE检测到MooD报头的存在，则其可以确定该重定向是激活 MBMS客户端的指示。如果该MBMS客户端已经是激活的或者操作的，则 UE可以确定该重定向表示隐含的应该获取更新后的USD片段的通知。该 MooD报头字段可以包括指示用作到动态建立的MBMS服务的进入点的 MBMS USBD片段的位置的URL。下面给出了针对UE获取从MooD报头的接收得出的USD片段的优先规则的示例性集合，以优先级降序给出：
1.如果所述URL在MooD报头中存在，则MBMS客户端可以使用该URL 通过单播取回USBD片段。
2.如果至USBD片段的所述URL在MooD报头中不存在，但是至USD信息的URL(例如，/<X>/USD位置/URL)在该MO中存在，则MBMS 客户端可以使用该URL通过单播取回USD片段。
在从MBMS客户端开始获取USD片段时开始直到其已经通过MBMS 承载接收到按需MBMS服务的内容的过渡期期间，UE可以继续经由单播网络请求内容，以避免从单播到广播内容接收的服务中断或“先断后通”的切换。一旦MBMS中间件客户端准备好将通过MBMS分发接收到的内容提供给应用客户端，可以发生从单播到广播的接收模式切换。
在一些示例中，如果被MO中的信息请求这样做的话，MooD报头字段可以由UE用于向MooD代理服务器指示该UE的当前位置。在这样的实例中，UE的当前位置可以根据下面在图21中描述的“位置类型 (LocationType)”值来格式化。MooD报头字段的扩充巴科斯范式(ABNF) 语法定义如下：
MooD＝“3gpp-mbms-offloading”[“:”(absoluteURI
|relativeURI|currentLocation)]。
如重定向/触发消息的第二个示例，用于重定向UE以从单播切换到广播接收，网络的设备可以通过将所请求的内容(例如，分段)和USD/更新后USD封装在多部分MIME容器中，从而将该USD/更新后USD与HTTP 响应中提供的内容一起发送给UE。举第三个示例，网络的设备可以使用 OMA推送机制(例如，如在3GPP TS 26.346的部分7.4：“Multimedia Broadcast/Multicast Service(MBMS)；Protocols and codecs”中找到的)或其它推送机制以通过单播信道将该USD/更新后USD发送给UE。虽然UE正经由单播或广播传输获取新的USD或更新后USD，但是该UE可以继续使用单播信道提取内容。一旦UE能够完全从MBMS承载接收该内容，则可以释放单播信道。
各种触发方法可以用于实践用于激活UE的MBMS中间件的基于网络的解决方案。在第一种替代方案中，UE的应用可以获取一些信息然后该应用可以向该UE的MBMS中间件注册。在第二种替代方案中，UE的HTTP 代理或RTP代理可以获取一些向MBMS中间件提供指示的重定向。在第三种替代方案中，一些推送机制(诸如SMS、WAP推送、OMA-DM等)可以直接唤醒MBMS中间件。例如，该推送机制可以为用于MBMS触发的 SMS指定新的APP端口ID(例如，新的UDP端口)。当SMS层接收到具有新指定的APP端口ID的触发时，将其传递给MBMS中间件。在另一个示例中，OMA-DM服务器向UE发送管理初始化消息以启动MBMS中间件。在第四种替代方案中，网络可以使用空中接口信令，诸如系统信息块(SIB) 广播、小区广播、MBMS控制信息有效性和变化(MCCH)变化通知、USD 变化消息或其它信令方法。在第五种替代方案中，网络可以使用分组网关信令，诸如非接入层(NAS)信令、协议配置选择(PCO)或其它信令方法。依照本公开内容的一种或多种技术可以使用各种其它替代方案。
图2是描绘了示例性多媒体内容102的元素的概念图。多媒体内容102 可以包括在针对其所述内容随着被接收到而消耗的流服务中，或者针对其下载所述内容并存储用于稍后消耗的下载分发服务中。也就是，多媒体内容102可以表示一个或多个UE可访问的用于实时或非实时渲染的任何数据。在图2的示例中，多媒体内容102包括媒体呈现描述(MPD)104和多个表示110-120。表示110包括可选的报头数据112和分段114A-114N(分段114)，而表示120包括可选的报头数据122和分段124A-124N(分段124)。为了方便起见，字母N用于指定每个表示110、120中的最后一个电影片段。在一些示例中，在表示110、120之间可以有不同数量的电影片段。
MPD 104可以包括与表示110-120分离的数据结构。MPD 140可以对应于图1的清单文件66。同样，表示110-120可以对应于图1的表示68。一般来讲，MPD 104可以包括大体上描述表示110-120的特征(诸如编码和渲染特征、自适应集合、MPD 104对应的简档、文本类型信息、相机角度信息、评级信息、记录模式信息(例如，指示包括时间子序列的表示的信息)和/或用于取回远程周期的信息(例如，用于回放期间向媒体内容插入目标广告))的数据。
当存在时，报头数据112可以描述分段114的特征，例如，随机接入点(RAP，也称为流接入点(SAP))的时间位置、分段114的哪一个包括随机接入点、到分段114中与随机接入点的字节偏移、分段114的统一资源定位符(URL)或分段114的其它方面。当存在时，报头数据122可以描述分段124的类似的特征。另外或者作为替代，这些特征可以被完全包括在MPD 104中。
分段114、124包括一个或多个经编码视频采样，每个采样可以包括视频数据帧或切片。分段114的每个经编码视频采样可以具有相似的特征，例如高度、宽度和带宽要求。这些特征可以由MPD 104的数据描述，即使这些数据没有在图2的示例中描绘。MPD 104可以包括如3GPP规范描述的特征，附加本公开内容中描述的用信号表示的信息的任何或全部。
每个分段114、124可以与唯一的统一资源定位符(URL)相关联。因此，每个分段114、124可以是可独立使用流网络协议(诸如DASH)取回的。以此方式，目标设备(诸如客户端设备40)可以使用HTTP GET请求来取回分段114或124。在一些示例中，客户端设备40可以使用HTTP部分GET请求以取回分段114或124的特定字节范围。
MPD可以描述如何取回单播内容、多播内容、广播内容或它们的一些组合。也就是，MPD可以向UE(例如，流客户端)的一个或多个部件提供信息以允许该UE经由一个或多个分发模式访问内容。在一些示例中，可以修改该MPD的一部分或全部，从而改变流客户端可以接收的指令。例如，用于取回包含在MPD中的媒体数据的URL可能需要被改变以指示流客户端从新的位置获取该媒体数据。在一些示例中，为了使流客户端从新的位置获取该媒体数据，可以修改URL的基本部分。该URL的基本部分可以被改变为将流客户端导向不同的网络地址或本地地址。也就是，在一些示例中，修改后的URL的基本部分可以使流客户端(诸如客户端设备40的) 从客户端设备40本身内部的一个或多个部件取回媒体数据。这样，流客户端可以从UE的其它部件取回媒体数据，诸如MBMS中间件单元，而非从网络上的内容服务器取回。
本申请中描述了从一种服务向另一种的媒体数据的转换取回的各种技术。可以依照发起或中止所述不同服务的提供的服务供应商网络来采用这些技术。举一个使用情况的示例，服务供应商网络可以启用按需eMBMS 用于实时(RT)内容。例如，体育/新闻内容供应商可以使它的在线多媒体体育节目和新闻服务在互联网上可用(也称为“过顶(Over-the-Top)”或OTT 服务)。可以由移动网络运营商在特定国家提供对该服务的LTE单播接入。由于很多原因，体育/新闻内容供应商所提供的特定体育事件的实况转播可能在该国家变得广受欢迎。也就是，该国家中大量用户可能会访问该体育/ 新闻内容供应商的网站(例如，经由智能手机)来关注实况转播。由于所述增加的受欢迎度，该移动网络运营商(其也提供eMBMS服务)可能在其往/返体育/新闻内容供应商的网站的LTE单播网络上引发很高并且持续的业务水平。
这样高的业务量可能不仅仅对服务供应商的单播网络的容量产生压力，还有可能由于内容接收过程中更频繁的拖延而损害整体的用户体验(这可能也是体育/新闻内容提供商所担心的)。依照本申请中描述的技术，该移动网络运营商网络可以能够检测其单播网络到任何外部网站上的动态OTT 业务增加，并且可以具有动态提供eMBMS服务用于单播业务卸载的手段。在一些示例中，该移动网络运营商可以与内容供应商达成商业协定以便根据需要配置按需eMBMS服务。
举第二个使用情况示例，服务供应商网络可以启用按需eMBMS用于非实时(NRT)内容。例如，前面提到的体育/新闻内容供应商还可以发布覆盖不同类别的体育新闻、访谈、集锦等的RSS(“RDF站点摘要”或“真正简单的聚合”)源(也称为“播客”)。由于最近大受欢迎，对该播客的订制可能显著增加。这种在服务供应商的单播网络上的RSS内容分发可能在广播或eMBMS承载上分发会更高效。在一些示例中，内容供应商可以与服务供应商有合作关系，其中该合作关系可以允许测量并与服务供应商共享对该内容供应商所提供的各种RSS源的订制事件。在一些示例中，一旦达到针对给定RSS源的某个阈值，服务供应商就可以动态提供eMBMS下载分发服务以便依据广播调度分发该RSS内容。
举第三个使用情况示例，服务供应商网络可以启用eMBMS服务的按需去激活。例如，该国家的体育迷可能开始对该体育/新闻内容供应商的内容失去兴趣。检测到通过最近提供的eMBMS服务对该体育/新闻内容供应商的网站的用户访问有明显下降。该服务供应商可以确定维持该体育/新闻内容供应商的服务的专用eMBMS广播对整体网络利用率不再有利。依照原来与该内容供应商达成协议的商业条款，该服务供应商可以去激活 eMBMS服务。在一些示例中，相关联的网络容量可以针对单播业务的携带而重新分配。
举第四个使用情况示例，服务网络运营商可以根据需要控制eMBMS 操作，从而提供实况流服务支持。例如，在购物中心或其它地区，很多用户可能正使用DASH协议观看第一实况节目。覆盖该购物中心的服务网络小区可能高度拥塞。到达该购物中心的新的用户可能会有一段时间很难使用该服务网络访问内容。在这一示例中，很多访问DASH流内容的UE可以是eMBMS功能的。该拥塞状况可能引起网络运营商的注意。为了缓解拥塞，该网络的一个或多个设备可以与UE通信以便使该UE开始在MBMS 承载上接收DASH流内容。也就是，该网络可以在MBMS承载上广播实况流内容，该MBMS用户服务订制被激活并且按照从网络接收到的指令， eMBMS功能UE可以切换到eMBMS系统从而减轻该小区中的拥塞。
在一些示例中，虽然第一实况节目正在进行，但是很多用户可能中止观看该节目。另外，第二实况节目可能在该小区内的受欢迎度增加。该小区可能再次变得拥塞。在这种实例中，网络的设备可以确定第一实况节目的观众数量小于第二实况节目的观众数量。根据这一确定，网络的设备可以终止针对第一实况节目的MBMS承载并且作为替代在MBMS承载上广播第二实况节目。依照本申请中描述的技术，那些获取第一实况节目的UE 可以退出MBMS用户服务并且然后通过DASH获取该第一实况节目。另一方面，第二实况节目的观众可以订制该广播服务并且开始在MBMS承载上接收第二实况节目。
举第五个使用情况示例，服务供应商可以启用对聚合的内容的高效访问。例如，内容供应商可以提供具有多个基于DASH的实况电视频道的服务。换句话说，内容供应商可以用作其它内容生产者和内容消耗者的聚合者。所述TV频道可以包括大量个性化记者、本地新闻和/或其它小型产生源的服务。在这一使用情况示例中，所述服务的频道可以通过社交网络分享，并且偶然地这些频道可能变得受欢迎但最终再次减少。由于各种因素，流行度的变化可以相对逐渐地发生并且可以每个地区有所不同。该服务供应商可能想要确保在这些高需求情况中，所有MBMS功能设备能够消费高质量的合格服务而不会妨碍用户体验(例如，无缝服务、时移缓存的可用性、该频道的额外视图和分量、以及其它特征)。也就是，服务供应商想要以无线电高效的方式分发这些受欢迎的内容。
图3是描绘实施用于选择性使用一个或多个服务获取数据(例如，与流服务或文件下载服务有关)的技术的示例性系统150的概念图。如图3 的示例中所示，系统150包括UE侧和网络侧。在一些示例中，位于图3 的UE侧上的部件可以表示如图1中所描述的客户端设备40的部件。在一些示例中，位于网络侧上的部件可以表示内容准备设备20、服务器设备60 和/或网络74的部件(其图1中并不必然显示)。在其它示例中，UE侧上的部件可以不包括在客户端设备中，而是可以作为网络74的一部分。
在图3的示例中，系统150的网络侧包括应用服务器(“app服务器”) 152、分组数据网络网关(P-GW)154以及广播和多播服务中心(BM-SC) 156。应用服务器152、P-GW 154和BM-SC 156的每一个可以包括硬件、固件、软件或它们的任何组合。在一些示例中，应用服务器152可以具有与服务器设备60的一个或多个部件的功能相同或相似的功能。也就是，应用服务器152可操作用于接收针对数据的请求，并提供所请求的数据。P-GW 154可以通过成为UE的业务的退出和进入点为UE提供到外部分组数据网络的连接性。在一些示例中，多个P-GW可以用于向UE提供到多于一个分组数据网络的同时连接。在各个示例中，P-GW可以执行策略实施、分组滤波、收费支持、分组筛选或各种其它动作。例如，在图3的示例中，P-GW 可以为UE部件提供到应用服务器152的接入以获取内容。在一些示例中， BM-SC 156可以具有与处理单元70的功能相同或相似的功能。也就是， BM-SC 156可以被配置为经由广播或多播协议(诸如MBMS或eMBMS) 向UE分发数据。BM-SC 156可以从应用服务器152接收数据并广播该数据以便由一个或多个UE使用。
如图3的示例中所示，系统150的UE侧包括应用158、流/文件下载客户端160、MBMS单元(“MBMS客户端(中间件)/本地服务器”)162、IP 栈164和调制解调器166。应用158可以表示能够接收数据的任何应用。在一些示例中，应用158可以能够接收流媒体数据并输出音频、视频或文本以向用户呈现。例如，应用158可以是媒体播放器、网络浏览器或其它应用。在一些示例中，应用158可以随着媒体内容被通过流服务或流客户端分发或访问而实时消耗该媒体内容。在一些示例中，应用158可以参加由文件分发服务或文件下载客户端分发或访问的内容的时移消耗。流/文件下载客户端160可以是可操作用于执行本申请中描述的任何或所有功能的硬件、固件、软件或它们的组合。在一些示例中，流/文件下载客户端160可以执行与取回单元52所执行的那些操作类似的操作。例如，流/文件下载客户端160可操作用于从应用158接收针对流媒体数据的请求，并向应用158 提供用于呈现给用户的视频数据、音频数据和/或文本数据。举例来说，流/ 文件下载客户端160可以包括被配置为经由计算机网络接收流服务数据或文件分发服务数据的DASH客户端、RTP/RTSP客户端、FTP客户端、HTTP 客户端或其它客户端。
MBMS单元162可以表示可操作用于经由广播或多播服务(包括广播和多播分发模式)接收数据并将该数据存储用于由一个或多个其它部件访问的任何单元。例如，MBMS单元162可以依照各种广播或多播网络协议 (诸如MBMS、eMBMS或IP多播)工作。当广播或多播服务针对特定内容可用时，MBMS单元162可以提交请求以加入与该特定内容相关联的多播网络组，然后接收该多播组的数据而无需发出任何进一步的请求。在图3 的示例中，MBMS单元162可以通过从应用158接收指示来启用。该指示可以表示应用158正在请求广播服务或多播针对其可用的数据。在一些示例中，当MBMS单元162已经接收到特定内容的至少一部分时，MBMS单元162可以与流/文件下载客户端160通信以使流/文件下载客户端160从 MBMS中间件获取流服务数据或文件分发服务数据。也就是，MBMS单元 162可以同时用作接收到的数据的MBMS客户端和本地服务器。
在图3的示例中，MBMS单元162可以包括与流/文件下载客户端160 进行通信(诸如经由API)的功能。MBMS单元162和流/文件下载客户端 160可以可操作用于经由一个或多个API交换各种信息，诸如MPD/SDP URL(或用于通知eMBMS层用于正在被访问的呈现的MPD的机制)、 MBMS触发信息(或导致/触发eMBMS层检查用户服务描述(USD)更新的机制)，和/或重定向配置。例如，MBMS客户端和流/文件下载客户端之间的API可以用于交换信息以发送数据的清单文件或使流/文件下载客户端 160配置其设置(例如，以便从访问应用服务器152上的内容改变到访问 MBMS单元162上的内容)。
在图3的示例中，流/文件下载客户端160和MBMS单元162可以经由 IP栈164和调制解调器166与系统150的网络侧进行通信。在各个示例中， IP栈164表示可用于网络通信的任何分层协议套，诸如互联网协议套或其它协议套。调制解调器166表示能够通过物理介质(诸如经由缆线、光纤或通过使用电磁波)传输数据的任何单元。
在图3的示例的步骤1中，应用158通过单播服务(例如，使用单播分发模式)从应用服务器152获取数据。也就是，UE可以初始使用第一服务接收数据。在图3的示例的步骤2中，网络中的高附连率检测(HARD) 单元(未示出)检测高附连率。例如，HARD可以确定阈值数量的UE正在针对特定内容访问服务器152。该HARD单元向BM-SC 156指示高附连率，这启用MBMS会话(例如，MBMS承载)。BM-SC 156可以向应用服务器152指示MBMS会话，而应用服务器152可以向系统150的UE侧中的应用158指示该MBMS会话可用性。以这种方式，系统150的网络侧可以向UE的应用158指示第二服务(例如，MBMS承载或其它多播或广播服务)的可用性。可以使用广播或多播分发模式以及使用单播分发模式使该第二服务可用。
在图3的示例的步骤3中，当应用158接收到MBMS服务可用的指示时，应用158向MBMS中间件(例如，MBMS单元162)注册。MBMS单元162可以与流/文件下载客户端160进行通信(例如，经由API)以使流/ 文件下载客户端160从该MBMS中间件获取流服务数据或文件分发服务数据。也就是，依照本公开内容的一种或多种技术，在经由第一服务(例如，单播服务)接收数据期间，应用158获取一些信息(例如，指示)，然后应用158向MBMS中间件注册。
在图3的示例的步骤4中，应用158使用广播或多播服务从MBMS承载(例如，BM-SC 156)获取数据。换句话说，当UE接收到数据要经由第二服务接收的指示时，该UE可以激活用于经由该第二服务接收数据的单元 (例如，MBMS单元162)并从所述用于经由第二服务接收数据的单元接收数据。MBMS单元162可以经由广播分发模式或多播分发模式获取数据。图3的这一方法可能更适合于文件下载，诸如空中固件(FOTA)技术、播客等等。在图3的示例中，应用158不是传输不可知的。也就是，应用158 必须接收指示并向MBMS中间件注册以实现经由广播或多播服务接收数据。
图4是描绘了实施用于选择性使用一种或多种服务获取数据的技术的示例性系统200的概念图。在图4的示例中，系统200包括UE侧和网络侧。系统200的网络侧包括应用服务器(“app服务器”)202、P-GW 204、重定向/代理单元205和BM-SC 206。应用服务器(“app服务器”)202、P-GW 204 和BM-SC 206可以分别包括与图3的应用服务器152、P-GW 154和BM-SC 156的功能相同或相似的功能。重定向/代理单元205可以表示用于接收请求(诸如HTTP GET请求或RTP消息)并基于指令将所述请求导向一个或多个源的硬件、固件、软件或它们的一些组合。例如，重定向/代理单元205 可以可操作用于从UE接收针对数据的请求并将该请求转发到应用服务器 202。
在图4的示例中，系统200的UE侧包括应用208、流/文件下载客户端 210、MBMS单元(“MBMS客户端(中间件)/本地服务器”)212、代理单元(“HTTP/RTP代理”)213、IP栈214和调制解调器216。应用208、IP 栈214和调制解调器216可以分别包括与图3的应用158、IP栈164和调制解调器166的功能相同或类似的功能。在一些示例中，流/文件下载客户端 210可以包括与图3的流/文件下载客户端160的功能相同或类似的功能。在其它示例中，流/文件下载客户端210可以包括不同的或额外的功能。在一些示例中，流/文件下载客户端210可以是能够处理使用各种格式编码后的数据的部件的集合(例如，DASH客户端和RTP客户端)。MBMS单元 212可以包括与图3的MBMS单元162的功能相同或类似的功能。在图4 的示例中，MBMS单元212可以包括不同的或额外的功能。
在图4的示例中，MBMS单元212还可以包括与代理单元213进行通信(诸如经由API)的功能。MBMS单元212和代理单元213可以可操作用于经由一个或多个API交换各种信息，诸如MPD/SDP URL(或通知 eMBMS层用于正在被访问的呈现的MPD的机制)、MBM是触发信息(或导致/触发eMBMS层检查用户服务描述(USD)更新的机制)和/或重定向配置。例如，MBMS客户端和本地代理之间的API可以用于交换信息以使 MBMS单元212能够开始接收数据、发送用于流服务数据或文件分发服务数据的清单文件和/或使代理单元213配置其重定向设置(例如，以从访问应用服务器202上的内容改变到访问MBMS单元212上的内容)。
代理单元213可以包括用于接收请求(例如，针对数据的请求)并将所述请求转发到适当目的地的功能。代理单元213还可以包括用于修改接收到的请求(例如，该请求中包括的URL)以符合重定向指令的功能。例如，代理单元213可以可操作用于修改网络地址，使得流/文件下载客户端 210从MBMS单元212(例如，从广播或多播服务)而不是从应用服务器 202(例如，从单播服务)接收数据。其后，MBMS单元212可以通过广播分发模式从广播服务接收数据(如果可用)。
在图4的示例的步骤1中，应用208通过单播服务从应用服务器202 获取数据。也就是，UE可以初始地使用第一服务接收数据。重定向/代理单元205可以在单播用户业务的路径上。也就是，应用服务器202和UE侧之间的单播业务可以流经重定向/代理单元205。在图4的示例的步骤2中，网络中的HARD单元(未示出)检测到高附连率。在各种示例中，HARD 单元可以是应用服务器202、重定向/代理单元205、P-GW 204或其它网络实体的一部分。该HARD单元向BM-SC 206指示所述高附连率以启用 MBMS会话(例如，MBMS承载)。BM-SC 206请求重定向/代理单元205 (可以在用户面或控制面中)将所述UE重定向到去往本地服务器。重定向 /代理单元205可以，例如使用HTTP重定向或成功消息或者RTSP重定向或成功消息，向UE发送指示。举例来讲，HTTP或RTSP重定向消息可以对应于3xx重定向(例如，300或303类型的HTTP响应)。该重定向可以伴随报头扩展发送也可以没有。HTTP或RTSP成功消息可以对应于2xx成功(例如，200-类型的HTTP响应)，其中该2xx成功包括报头扩展。以此方式，系统200的网络侧可以向UE的代理单元213指示第二服务(例如， MBMS承载或者其它多播或广播服务)的可用性。
在图4的示例的步骤3中，当代理单元213接收到指示(例如，重定向或成功消息)时，代理单元213(例如，HTTP/RTP代理)向MBMS中间件(例如，MBMS单元212)注册。也就是，依照本公开内容的一种或多种技术，HTTP代理(或RTP代理)得到一些指示，然后激活该MBMS 中间件。
在图4的示例的步骤4中，应用208通过间接地从MBMS单元212获取该MBMS单元212使用广播或多播服务(例如，经由广播或多播分发模式)获取的数据，从MBMS承载(例如，BM-SC 206)获取数据。换句话说，当UE接收到该数据要经由第二服务接收的指示时，UE可以激活用于经由第二服务接收数据的单元(例如，MBMS单元212)并且从该经由所述第二服务接收数据的单元接收所述数据。然后，可以将经由所述第二服务接收到的数据间接(例如，经由代理单元213和流/文件下载客户端210) 提供给应用208。在一些示例中，流/文件下载客户端210和本地代理(例如，代理单元213)之间的HTTP接口可操作用于使得针对通过MBMS分发的内容的应用请求能够从本地HTTP服务器取回。图4的方法可能更适合于流服务，诸如突发新闻。在图4的示例中，应用208是传输不可知的。也就是，应用208不需要具有任何关于所述数据是如何获取的指示。相反，代理单元213可以自动更新路由信息并向MBMS单元212而不是应用服务器202发送针对数据的请求。
图5A-5D是描绘了用于选择性使用一种或多种服务获取流媒体数据的示例性操作的概念图。下面在图4的系统200的一般上下文中描述图5A-5D 的示例性操作。在图5A-5D的示例中，流/文件下载客户端210可以是DASH 客户端，重定向/代理单元205可以是代理/重定向器，MBMS单元212可以是MBMS客户端和本地HTTP服务器，代理单元213可以是HTTP代理，并且应用服务器202可以是能够提供DASH媒体内容的HTTP服务器。
依照本公开内容的一种或多种技术，应用208可以使用流/文件下载客户端210(例如，使用DASH协议)获取媒体数据。例如，应用208可以向流/文件下载客户端210发送指示清单文件(例如，MPD)的位置的URL，该清单文件定义了用于根据第一服务(例如，单播)取回媒体数据的一个或多个资源位置。流/文件下载客户端210可以通过向代理单元213发送 HTTP GET请求获取所述MPD。代理单元213可以接收所述HTTP GET请求，并且经由IP栈214、调制解调器216、P-GW 204和重定向/代理单元 205将该请求导向应用服务器202。在图5A的示例中，代理单元213还可以向MBMS单元212发送MPD URL的指示(例如通过调用API)。
在一些示例中，UE在其进行初始MPD提取时指示其具备eMBMS功能。以此方式，UE可以使得网络能够知道在区域中有多少eMBMS功能设备。指示eMBMS功能还允许网络跟踪来自该UE的地址的未来事务。在一些示例中，UE还可以在其进行初始MPD提取时指示它的位置。
应用服务器202可以接收HTTP GET请求，并发送200-类型HTTP OK 消息作为响应，代理单元213可以接收该响应消息并将其发送给流/文件下载客户端210。该OK消息可以包括单播MPD。流/文件下载客户端210可以接收所述MPD并确定要获取的媒体数据的表示、周期和分段(例如，周期3、表示256、分段1)。至少部分基于该MPD，流/文件下载客户端210 可以查询用于所确定的分段的URL并向确定的URL(例如，“http://example.com/per-3/rep-256/seg-1.3gp”)发送HTTP GET请求，代理单元213可以接收该请求并经由重定向/代理单元205将其发送给应用服务器 202。应用服务器202可以接收所述GET请求，并且作为响应可以发送包括所请求的媒体数据(例如，“分段1”)的200-类型HTTP OK消息，代理单元213可以经由重定向/代理单元205接收该消息并可以将其发送给流/ 文件下载客户端210。以此方式，流/文件下载客户端210可以使用单播服务从应用服务器202获取流媒体数据。
在网络侧，BM-SC 206可以启用MBMS(例如，广播)服务并初始化 MBMS承载。BM-SC 206可以广播包括公共MPD和/或其它参数的用户服务描述(USD)。例如，该公共MPD可以包括对应于服务的广播分发模式的URL的基本部分以及对应于所述服务的单播分发模式的URL的基本部分。BM-SC 206还可以向重定向/代理单元205发送关于针对特定媒体内容要经由MBMS服务接收媒体数据的指示。
流/文件下载客户端210可以继续发送针对媒体数据的HTTP GET请求，诸如针对分段M的请求，其包括来自原始MPD的相应URL(例如，“http://example.com/per-3/rep-256/seg-M.3gp”)。在图5A的示例中，当重定向/代理单元205接收到针对分段M的GET请求时，重定向/代理单元205 可以向UE发送3xx-类型HTTP重定向消息。所述重定向消息可以包括扩展报头，其包括重定向URL(例如“http://example.com/redirect/per-3/rep-256/seg-M.3gp”)，以指示本地代理单元 213向MBMS单元212注册。也就是，所述重定向URL可以表示相同的被请求资源的不同位置。例如，如果原始请求URL是 http://example.com/per-x/rep-y/seg-z.3gp，则重定向URL可以是 http://example.com/redirect/per-x/rep-y/seg-z.3gp。3GPP定义的HTTP扩展报头可以命名为具有值“Get-USD”的“触发-MBMS”，在这种情况中，针对UE 所请求的内容的HTTP响应消息可以伴随有响应报头“触发-MBMS：Get USD”。
在一些示例中，重定向/代理单元205可以替代性地使用具有实体主体的3xx-类型HTTP重定向消息，其中该3xx-类型HTTP重定向消息包括重定向URL和对本地代理单元213的指示，以使代理单元213向MBMS单元212注册。也就是，所述重定向消息可以包括由实体报头和/或实体主体组成的实体(例如，由HTTP所定义的)。在一些示例中，重定向/代理单元 205可以替代性地与HTTP响应中提供的内容一起发送指示。所述指示可以触发UE通过单播或MBMS承载访问USD或USD更新。例如，重定向/ 代理单元205可以发送具有3GPP扩展报头的200-类型HTTP OK消息，所述报头包括可以触发UE获取/接收所述USD或USD更新的指示。也就是，所述200-类型HTTP OK消息可以包括UE所请求的(例如，分段M)内容以及指示。
UE的代理单元213可以接收重定向消息并继续通过经由重定向/代理单元205向应用服务器202发送指向该重定向URL的针对相同分段M的新的HTTP GET请求来经由单播服务取回内容数据。发送给该重定向URL的请求可以表示代理单元213向重定向/代理单元205确认代理单元213接收到所述指示。在一些示例中，重定向/代理单元205可以接收新的HTTP GET 请求并将所述未修改的请求发送给应用服务器202。应用服务器202可以接收去往重定向URL的新的请求，并且发送分段M作为响应，代理单元213 可以经由重定向/代理单元205接收该分段M并将其发送给流/文件下载客户端210。在一些示例中，重定向/代理单元205可以接收去往重定向URL 的新的HTTP GET请求，并且修改所述新的请求之后将修改后的新请求发送到应用服务202。例如，重定向/代理单元205可以修改所述新请求，使得修改后的新请求不是至重定向URL而是至原始URL(例如，“http://example.com/per-3/rep-256/seg-M.3gp”)。应用服务器202可以接收修改后的请求，并且发送分段M作为响应，代理单元213可以经由重定向/ 代理单元205接收分段M并将其发送到流/文件下载客户端210。
除了发送新的GET请求，代理单元213可以利用API(例如，MBMS 单元212的API)以启用MBMS单元212。也就是，作为对接收到所述重定向请求的响应，代理单元213可以启用MBMS单元212但是继续将所述新的HTTP GET请求转发到app服务器202(经由重定向/代理单元205)，以经由单播服务提取数据分段，直到所述数据可以使用广播服务获得。代理单元213可以将接下来的针对单播内容的请求重定向到接收到的重定向 URL，也可以不重定向。也就是，在接收到重定向请求并经由所述重定向 URL发送针对所述内容的GET请求之后，在各个示例中，代理单元213可以允许请求无需修改即可通过，或者可以修改请求以基于所述重定向位置引导所述请求URL。
MBMS单元212一旦从本地代理单元213接收到触发，则可以使用建立好的广播服务从BM-SC 206接收所述USD，或者可以通过所述单播服务与BM-SC 206通信以获取所述USD。所述USD包括MPD URL和MPD元数据片段，后者描述每个携带DASH格式化内容的MBMS服务的自适应集合或表示。MBMS单元212可以将初始从流/文件下载客户端210接收到的 (例如，图5A的步骤3中接收到的)MPD的URL与从BM-SC 206接收到的MPD的URL进行比较。如果URL匹配，则MBMS单元212可以开始经由广播服务(例如，使用广播或多播分发模式)接收媒体数据。
例如，MBMS单元212可以激活MBMS单向传输文件分发(FLUTE)，以接收经由作为广播服务的一部分的广播分发模式发送的媒体数据。一旦 MBMS单元212已经接收到足够的媒体数据(例如，缓存)，MBMS单元 212可以调用API以配置代理单元213的重定向。在一些示例中，MBMS 单元212可以向代理单元213发送一个或多个更新后的资源位置。例如， MBMS单元212可以指令代理单元213使用可从MBMS单元212获得的修改后的MPD，而不是从应用服务器202取回的原始MPD。以这种方式，流 /文件下载客户端210接下来可以开始从MBMS单元212接收经由广播服务 (例如，使用广播分发模式)获取的媒体数据。
图5B、5C和5D提供针对四种示例性情况的示例性操作。在情况1中，MBMS单元212从BM-SC 206获取的公共MPD(例如，在图5A的步骤15中接收到的)包括与单播MPD相同的媒体内容的表示(例如，表示256)，并且所述相同的表示可经由MBMS得到。在情况1中，MBMS单元212可以指令代理单元213修改针对所述媒体内容的未来请求，方式为将所述请求中指出的URL的基本部分(例如，对应于应用服务器202的基本部分) 改变为对应于MBMS单元212的基本部分(例如，包含所述内容的本地服务器)。
例如，MBMS单元212可以调用API以将分段N的URL从“http://example.com/per-3/rep-256/seg-N”改为“http://localhost/per-3/rep-256/seg-N”。也就是，在一些示例中，第一基本部分可以是对应于第一服务(例如，单播)的网络位置，而第二基本部分可以是对应于第二服务(例如，广播)的MBMS单元212的位置。代理单元 213可以继续从流/文件下载客户端210接收HTTP GET请求。代理单元213 可以将所述请求重定向到更新后的资源位置(例如，MBMS单元212)，该资源位置是本地主机服务器。
MBMS单元212可以接收所述请求并发送包括所请求的媒体数据的 200-类型HTTP OK消息，代理单元213可以接收该消息并将其发送给流/ 文件下载客户端210。以这种方式，当代理单元213接收到要经由广播服务接收所述媒体数据的指示(例如，所述重定向消息)时，代理单元213可以激活用于经由第二服务接收数据的单元(例如，MBMS单元212)并从 MBMS单元212(例如，本地服务器)而不是远程应用服务器(诸如应用服务器202)接收媒体数据。
在情况2中，MBMS单元212从BM-SC 206获取的公共MPD包括与单播MPD表示相同的媒体内容的表示(例如，表示256和表示512)。但是，只有一个表示是可通过MBMS获得的(例如，表示512)。在情况2中， MBMS单元212可以指令代理单元213通过改变两个表示的URL的基本部分来修改请求。因此，代理单元213可以将去往应用服务器202的任何请求的URL修改为替代地发送给MBMS单元212的本地HTTP服务器。 MBMS单元212还可以指令代理单元213将针对无法通过广播获得的表示 (例如，表示256)的请求的URL修改为通过广播可获得的表示(例如，表示512)。之后，代理单元213可以从请求经由MBMS不可获得的表示的流/文件下载客户端210接收HTTP GET请求。
作为对接收到GET请求的响应，代理单元213可以向流/文件下载客户端210发送HTTP重定向消息，该消息具有可从MBMS单元212获得的表示的重定向URL。在一些示例中，该重定向消息的URL可以包含在‘位置 (Location)’报头中。在其它示例中，该重定向消息可以包括扩展报头，其包括所述重定向URL(例如，“http://example.com/per-3/rep-512/seg-N.3gp”)。在另外其它示例中，本地代理单元213可以替代性地使用具有包括所述重定向URL的主体实体的3xx-类型HTTP重定向消息。在任一情况中，流/ 文件下载客户端210可以接收所述重定向消息，并发送具有重定向URL的新的GET请求。代理单元213可以将新的GET请求导向MBMS单元212，并且该MBMS单元212可以提供所请求的媒体数据，代理单元213可以接收该媒体数据并将其发送给流/文件下载客户端210。
在情况3中，MBMS单元212从BM-SC 206获取的公共MPD包括单播MPD中不包括的表示(例如，表示512)，并且该排除的表示是通过MBMS 可获得的仅有的表示。在情况3中，MBMS单元212可以指令代理单元213 通过只改变那些与经由MBMS可获得的表示(例如，表示512)有关的请求的基本部分来修改请求URL(例如，原始指向应用服务器202)。在一些示例中，MBMS单元212还可以指令代理单元213将用于有关通过MBMS 不可获得的表示(例如，表示256)的请求的URL修改为通过MBMS可获得的表示(例如，表示512)。之后，代理单元213可以从流/文件下载客户端210接收HTTP GET请求，其从通过单播服务(例如，不是MBMS用户服务)可获得的表示请求分段。在一个示例中，作为对接收到所述GET请求的响应，代理单元213可以向流/文件下载客户端210发送具有针对经由单播可获得的不包括在单播MPD中的表示的重定向URL的HTTP重定向消息。该重定向消息可以包括扩展报头，其包含重定向URL(例如，“http://example.com/per-3/rep-512/seg-N.3gp”)并且指示该MPD需要由流/ 文件下载客户端210重新提取。代理单元213可以替代性地使用具有包括所述重定向URL和该MPD需要被重新取回的指示的主体实体的3xx-类型 HTTP重定向消息。在另一个示例中，作为对接收到所述GET请求的响应，代理单元213可以向流/文件下载客户端210发送错误代码(例如，4xx-类型HTTP错误代码)，以指示该MPD需要由流/文件下载客户端210重新提取。在任一情况中，流/文件下载客户端210可以确定需要新的MPD，并且可以发送包括MPD URL的HTTP GET请求。代理单元213可以接收所述 GET请求并将所述GET请求重定向到修改后的清单文件(例如，由MBMS 单元212获取的更新后的MPD)。MBMS单元212可以发送所述更新后的 MPD，代理单元213可以接收所述更新后的MPD并将其发送给流/文件下载客户端210。在另一个示例中，作为对接收到针对所述修改后的清单文件的GET请求的响应，代理单元213可以将更新后的MPD推送到流/文件下载客户端210。在任一情况中，在接收到更新后的MPD之后，流/文件下载客户端210可以发送针对来自经由MBMS可获得的表示的分段的新的 HTTP GET请求，并且代理单元213可以将所述请求重定向到MBMS单元 212(例如，包括本地服务器)以提取适当的分段。MBMS单元212可以提供所请求的媒体数据的分段，代理单元213可以接收所述分段并将其发送给流/文件下载客户端210。
在情况4中，MBMS单元212从BM-SC 206获取的公共MPD包括多于一种不包括在所述单播MPD中的表示(例如，表示512和表示1024)，并且被排除的表示是通过MBMS可获得的仅有的表示。在情况4中，MBMS 单元212可以指令代理单元213将请求URL(例如，其名义上指向基于网络的服务器)的基本部分修改为与经由MBMS可获得的表示(例如，表示 512和表示1024)有关的URL的基本部分。
之后，代理单元213可以从流客户端接收请求通过单播服务可获得的表示之一的HTTP GET请求。在一个示例中，作为对接收到所述GET请求的响应，代理单元213可以向流客户端210发送HTTP重定向消息，其具有用于经由广播分发可获得的不包括在单播MPD中的表示的多个重定向 URL。在一些示例中，所述重定向消息可以包括包含多个重定向URL(例如，http://example.com/per-3/rep-512/seg-N.3gp和 http://example.com/per-3/rep-1024/seg-N.3gp)的扩展报头，其中该重定向 URL指示所述MPD需要由流/文件下载客户端210重新提取。在其它示例中，本地代理单元213可以使用具有包含多个重定向URL和指示所述MPD 需要被重新提取的指示符的主体实体的3xx-类型HTTP重定向消息。在另一个示例中，作为对接收到所述GET请求的响应，代理单元213可以向流 /文件下载客户端210发送错误代码(例如，4xx-类型HTTP错误消息)以指示所述MPD需要被重新提取。
在任一情况中，流/文件下载客户端210可以确定需要新的MPD并且可以发送包括所述MPD URL的HTTP GET请求。代理单元213可以接收所述GET请求并将所述GET请求导向更新后的清单文件(例如，由MBMS 单元212获取的更新后的MPD)。MBMS单元212可以发送更新后的MPD，代理单元213可以接收该更新后的MPD并将其发送到流/文件下载客户端 210。在另一个示例中，作为对接收到所述GET请求的响应，代理单元213 可以将更新后的MPD推送到流/文件下载客户端210。然后，流/文件下载客户端210可以发送针对来自经由广播服务可获得的表示的优选表示的新的HTTP GET请求，并且代理单元213可以将所述请求发往MBMS单元 212(例如，包括本地服务器)以提取所请求的数据。MBMS单元212可以提供所请求的数据，代理单元213可以接收该所请求的数据并将其发送到流/文件下载客户端210。
以此方式，代理单元213可以实现使用MBMS单元212接收DASH媒体数据或任何其它合适的数据。这可以至少部分通过在流/文件下载客户端 210接收到不在公共MPD中的一个或多个表示的指示时修改所述流/文件下载客户端210的行为(例如，接收重定向或错误代码)来完成。例如，接收不在MPD中的表示的指示可以使流客户端210触发MPD提取或其它动作。
图6是描绘用于重定向消息的主体实体400的一个示例的概念图。在一些示例中，图6的主体实体400可以表示3xx-类型的HTTP重定向消息的主体。如图6的示例中所示，主体实体400可以依照结构化文件语言(诸如可扩展标记语言(XML)或任何其它格式)进行格式化。图6只描绘了用于重定向消息的主体实体的一个示例，可以依照本公开内容的一种或多种技术使用各种其它主体实体和/或重定向消息。
如图6的示例中所示，主体实体400具有“实体主体类型 (EntityBodyType)”的类型。实体主体类型可以包含一个或多个替代性资源402A-402N(统称为“替代性资源402”)。替代性资源402可以表示针对内容或内容数据(例如，流服务数据或文件下载服务数据)的替代性资源位置。例如，在图5A-5D的上下文中，每个替代性资源402可以指代针对各个表示的本地位置(例如，由MBMS单元212提供的)和媒体数据的每个表示的分段。
如图6的示例中所示，每个替代性资源402可以具有“替代性资源类型 (AlternativeResourceType)”的类型并且包含属性404。属性404可以包括针对相应替代性资源(例如，该URL本身)的属性。在一些示例中，替代性资源402可以包含其它信息，诸如MPDURI对象406或任何其它信息。通过在3xx-类型HTTP重定向消息中包括主体实体400，MBMS中间件单元可以使代理单元和/或流/文件下载客户端在之后向不同位置(诸如本地内容服务器(例如，与多播或广播服务相关联的))发送针对于第一服务(例如，单播服务)相关联的内容的请求。也就是，依照本公开内容的一种或多种技术，可以在激活用于经由第二分发模式接收数据的单元(例如， MBMS中间件单元)之后使用主体实体400，以接下来经由所述第二分发模式从所述单元接收数据。
图7A和7B是描绘了用于选择性地使用一种或多种服务经由 RTP/RTSP获取流媒体数据的示例性操作的概念意图。下面在图4的系统200 的一般上下文中描述图7A和7B的示例性操作。在图7A和7B的示例中，流/文件下载客户端210可以是RTP/RTSP客户端，重定向/代理单元205可以是代理/重定向器，MBMS单元212可以是MBMS客户端和本地RTSP 服务器，代理单元213可以是RTSP代理，并且应用服务器202既可以是能够提供RTP媒体数据的RTSP服务器也可以是用于向针对会话描述的HTTP GET请求提供响应的网络服务器。依照本公开内容的一种或多种技术，应用208可以使用流/文件下载客户端210获取媒体数据(例如，使用RTP协议)。例如，应用208可以向流/文件下载客户端210发送URL，其中该URL 指示将用于媒体数据的标识符映射到用于第一服务(例如，单播)的资源位置的清单文件(例如，会话描述)的位置。流/文件下载客户端210可以通过向代理单元213发送HTTP GET请求获取会话描述。代理单元213可以接收所述HTTP GET请求，并且经由IP栈214、调制解调器216、P-GW 204和重定向/代理单元205将该请求导向应用服务器202。在图7A的示例中，代理单元213还可以向MBMS单元212发送单播会话描述URL的指示(例如，通过调用API)。
在一些示例中，UE可以在其进行会话描述的初始提取时指示其是具备 eMBMS功能的。以此方式，UE可以使得网络能够知道区域内有多少 eMBMS功能设备。指示eMBMS功能还允许网络跟踪来自该UE的地址的未来事务。在一些示例中，UE还可以在其进行会话描述的初始提取时指示其位置。在任一情况中，应用服务器202可以接收HTTP GET请求并发送 200-类型HTTP OK消息，代理单元213可以接收该消息并将其发送给流/ 文件下载客户端210作为响应。该OK消息可以包括单播会话描述。
流/文件下载客户端210可以接收所述会话描述并可以经由代理单元 213向应用服务器202发送RTSP SETUP请求。所述SETUP请求可以包含会话描述URL并可以指定媒体数据将如何传输(例如，依照RTP)。在一些示例中，所述SETUP请求可以包含更多或其它信息，诸如用于接收数据的本地端口。在任一情况中，应用服务器202可以对所述SETUP请求进行应答，并且可以在流/文件下载客户端210和应用服务器202之间创建单播会话。流/文件下载客户端210可以经由代理单元213向应用服务器202发送一个或多个RTSP PLAY请求。作为对接收到PLAY请求的响应，应用服务器202可以发送流媒体数据，诸如RTP音频和/或RTP视频数据，代理单元213可以接收该流媒体数据并将其发送到流/文件下载客户端210。流/文件下载客户端210可以接收所述媒体数据并播放相关联的内容。
在网络侧，BM-SC 206可以针对所述内容启用MBMS服务并初始化 MBMS承载。BM-SC 206可以广播包括新的会话描述的USD，其中该新的会话描述包括可用广播服务的描述以及相关联的分发过程(ADP)描述。例如，所述新的会话描述可以包括对应于广播分发模式的URL以及对应于单播服务的回退URL。BM-SC 206还可以向重定向/代理单元205发送针对特定媒体内容要经由MBMS服务接收媒体数据的指示。
作为对接收到所述指示的响应，重定向/代理单元205可以向代理单元 213发送RTSP REDIRECT请求。所述REDIRECT请求可以包括新的扩展，其中该新的扩展包括用于使UE针对内容向新的URL发出后续请求的URL。所述REDIRECT请求可以向本地代理单元213指示激活MBMS单元 212。在一些示例中，所述REDIRECT请求可以包括指示UE应该开始向新的URL发出请求的时间的时间戳。在所述时间戳中指出的时间之前，流/ 文件下载客户端210可以继续经由代理单元213向应用服务器202发送请求以及从该应用服务器202接收媒体数据。
当代理单元213接收到重定向/代理单元205发送的REDIRECT请求时，代理单元213可以利用API(例如，MBMS单元212的API)启用MBMS 单元212。也就是，作为对接收到所述REDIRECT请求的响应，代理单元 213可以向MBMS单元212发送指示以使用广播服务获取数据。MBMS单元212可以与BM-SC 206通信以获取USD(包括新的会话描述)。MBMS 单元212可以将初始从流/文件下载客户端210接收到的(例如，在图7A 的步骤3中)会话描述的URL与从BM-SC 206接收到的会话描述的URL 进行比较。如果URL匹配，则MBMS单元212可以开始经由广播分发模式接收媒体数据。例如，MBMS单元212可以激活FLUTE以接收经由广播分发模式发送的RTP媒体数据。一旦MBMS单元212已经接收到足够的媒体数据(例如，缓存)，则MBMS单元212可以准备好作为媒体数据的本地服务器。
图7B提供了针对两种可能情况的示例性操作。在第一个选择中， MBMS单元212可以调用API(例如，代理单元213的API)以使流/文件下载客户端210拆毁现有会话。例如，代理单元213可以向流/文件下载客户端210发送具有MBMS单元212的本地地址的先前接收到的REDIRECT 请求的修改后版本。作为对接收到REDIRECT请求的响应，流/文件下载客户端210可以发送RTSP TEARDOWN消息并发送新的RTSP SETUP消息。新的SETUP消息可以被发送到在所接收到的REDIRECT请求中指出的 URL(例如，MBMS单元212的位置)。MBMS单元212可以经由代理单元213接收请求，并经由代理单元213与流/文件下载客户端210进行通信以提供RTP音频和/或RTP视频数据。也就是，流/文件下载客户端210可以经由代理单元213向MBMS单元212中包含的本地服务器发送一个或多个RTSP PLAY请求，并且所述本地服务器可以发送RTP媒体数据作为响应，代理单元213可以接收该RTP媒体数据并将其发送到流/文件下载客户端210。
在第二种选择中，MBMS单元212可以调用API以使代理单元213将针对对应于特定媒体内容的RTP媒体数据的请求重定向到MBMS单元 212。例如，代理单元213可以从流/文件下载客户端210接收RTSP PLAY 请求并将所述请求重定向到MBMS单元212而不是应用服务器202。之后，流/文件下载客户端210可以经由代理单元213从MBMS单元212接收RTP 音频数据和/或RTP视频数据。以这种方式，代理单元213可以选择性地启用或禁用MBMS单元212以在用于接收RTP媒体数据的各个服务和分发模式之间进行选择。
图8是描绘了实施用于选择性使用一种或多种服务获取数据的技术的示例性系统250的概念图。在图8的示例中，系统250包括UE侧和网络侧。系统250的网络侧包括应用服务器(“app服务器”)252、P-GW 254、消息服务(“SMS/OMA/WAP”)255和BM-SC 256。应用服务器(“app服务器”) 252、P-GW 254和BM-SC 256可以分别包括与图3的应用服务器152、P-GW 154和BM-SC 156的功能相同或类似的功能。消息服务255 可以表示用于与一个或多个UE进行通信的硬件、固件、软件或它们的一些组合。例如，消息服务255 可以是可操作用于使用一种或多种协议(诸如短消息服务 (SMS)中心、OMA-DM服务器、WAP服务器或其它协议)与UE进行通信的服务器。
在图8的示例中，系统250的UE侧包括应用258、流/文件下载客户端 260、MBMS单元(“MBMS客户端(中间件)/本地服务器”)262、消息客户端(“SMS/OMA-DM/WAP”)263、IP栈264和调制解调器266。应用258、 IP栈264和调制解调器266可以分别包括与图3的应用158、IP栈164和调制解调器166的功能相同或类似的功能。在一些示例中，流/文件下载客户端260可以包括与图4的流/文件下载客户端210的功能相同或类似的功能。在其它示例中，流/文件下载客户端260可以包括不同的或额外的功能。 MBMS单元262可以包括与图3的MBMS单元162的功能的相同或类似的功能。
在图8的示例中，MBMS单元262还可以包括用于与消息客户端263 进行通信的功能(诸如经由API)。消息客户端263可以可操作用于向MBMS 单元262提供各种信息，诸如单播MPD/会话描述URL(或用于通知eMBMS 层用于正在被访问的呈现的MPD的机制)、MBMS触发信息(例如，用于导致/触发eMBMS层检查USD更新的机制)或其它信息。例如，消息客户端263可以向MBMS单元212发送信息，以使MBMS单元212开始经由广播服务接收数据。
在图8的步骤1中，应用258经由流/文件下载客户端260通过单播服务从应用服务器252获取数据。MBMS单元262可以被禁用。也就是，当 UE已经接收到要经由第一服务接收数据的指示时(例如，当所述第一服务是仅有的可用服务时)，UE可以禁用用于经由第二服务接收数据的单元。在图8的示例的步骤2中，网络中的HARD单元(未示出)检测到高附连率。HARD单元向BM-SC 256指示高附连率以启用MBMS会话(例如， MBMS承载)。BM-SC 256请求消息服务255(例如，SMS中心、 OMA-DM/WAP服务器)向UE发送指示。消息服务255可以向UE中的 SMS/OMA-DM/WAP层(例如，消息客户端263)发送消息。以这种方式，该网络可以发送数据应该经由广播服务接收的指示(例如，消息)。所述消息可以包括广播服务的USD更新。
在图8的示例的步骤3中，当消息客户端263接收到所述指示(例如，用于激活MBMS单元262的指令)时，UE中的消息客户端263(例如， SMS/OMA-DM/WAP层)向MBMS中间件(例如，MBMS单元262)注册。也就是，依照本公开内容的一种或多种技术，系统250的网络侧可以使用推送机制(诸如SMS、WAP推送、OMA-DM等)直接唤醒MBMS中间件。
在图8的示例的步骤4中，应用258通过间接从MBMS单元262获取由MBMS单元262使用广播或多播服务(例如，使用广播或多播分发模式) 获得的数据来从MBMS承载(例如，BM-SC 256)获取数据。换句话说，当UE接收到数据要经由第二服务接收的指示时，UE可以激活用于经由所述第二服务接收数据的单元(例如，MBMS单元262)并从所述用于经由第二服务接收数据的单元接收数据。然后，可以将经由第二服务接收到的数据间接(例如，经由流/文件下载客户端260)提供给应用258。在图8 的示例中，系统250的网络侧的一个或多个部件可以可操作用于维持状态信息。也就是，图8的示例可以要求网络中的状态并且需要识别应该向哪些UE发送“PUSH”通知。在一些示例中，所推送的内容可以包括USD本身。在图8的示例中，应用258是传输不可知的。也就是，应用258不需要有任何关于如何获得数据的指示。相反，流/文件下载客户端260可以接收更新后的USD(例如，包括新的MPD、会话描述或其它清单文件)并且向 MBMS单元262而不是应用服务器252发送针对数据的请求。
图9是描绘实施用于选择性使用一种或多种服务获取数据的技术的示例性系统300的概念图。在图9的示例中，系统300包括UE侧和网络侧。系统300的网络侧包括应用服务器(“app服务器”)302、P-GW 304、节点 303、MBMS网关(MBMS-GW)305和BM-SC 306。应用服务器(“app服务器”)302、P-GW 304和BM-SC 306可以分别包括与图4的应用服务器 202、P-GW 204和BM-SC 206的功能相同或类似的功能。节点3可以表示用于与UE直接进行通信的网络硬件、固件、软件或它们的任意组合。例如，节点303可以表示蜂窝网络的“NodeB”或“eNodeB”，可操作用于经由空中接口技术与系统300的UE侧的一个或多个部件进行通信。MBMS-GW 305 可以表示可操作用于执行MBMS控制功能的硬件、固件、软件或其任意组合。例如，MBMS-GW 305可以可操作用于向网络的各个节点(诸如节点 303)发送多播或广播数据。MBMS-GW 305可以从BM-SC 306接收广播或多播数据并协调到一个或多个节点的广播。
在图9的示例中，系统300的UE侧包括应用308、流/文件下载客户端310、MBMS单元(“MBMS客户端(中间件)/本地服务器”)312、IP栈 314和调制解调器316。应用308、流/文件下载客户端310、IP栈314和调制解调器316可以分别包括与图4的应用218、流/文件下载客户端210、IP 栈214和调制解调器216的功能相同或类似的功能。MBMS单元312可以包括与图4的MBMS单元312的功能的相同或类似的一些功能。在图9的示例中，MBMS单元312可以包括不同的或额外的功能。例如，MBMS单元312可以包括用于从系统300的网络接收指令的功能。也就是，MBMS 单元312可以从一个或多个部件(诸如节点303、MBMS-GW 305和/或 BM-SC 306)接收各种信息。
在图9的示例的步骤1中，应用308经由流/文件下载客户端310通过单播服务从应用服务器302获取数据。在图9的示例的步骤2中，网络中的HARD单元(未示出)检测到高附连率。该HARD单元向BM-SC 306 指示所述高附连率以启用MBMS会话(例如，MBMS承载)。BM-SC 306 通过发送MBMS会话建立以添加新的临时移动组标识符(TMGI)来启用 MBMS，其中该TMGI触发eNodeB和/或多小区/多播协调实体(MCE)(例如，节点303)发送空中接口信令，诸如USD改变通知。空中接口信令可以由UE侧上的调制解调器316接收。以此方式，系统300的网络侧可以使用空中接口信令向UE指示第二服务(例如，MBMS承载或者其它多播或广播服务)的可用性。
在图9的示例的步骤3中，当调制解调器316接收到指示(例如，USD 变化通知)时，调制解调器316向MBMS中间件(例如，MBMS单元312) 指示所述USD变化。也就是，依照本公开内容的一种或多种技术，系统300 的网络侧可以使用空中接口信令，诸如SIB广播、MCCH通知、USD变化通知或其它信令来向UE指示多播或广播服务的可用性。
在图9的示例的步骤4中，应用308通过间接从MBMS单元312获取由MBMS单元312使用广播或多播服务(例如，经由广播或多播分发模式) 获得的数据来从MBMS承载(例如，BM-SC 306)获取数据。换句话说，当UE接收到媒体数据要经由第二服务接收的指示时，UE可以激活用于经由第二服务接收数据的单元(例如，MBMS单元312)并从所述用于经由第二服务接收数据的单元接收媒体数据。然后，可以将经由第二服务接收到的数据间接(例如，经由流/文件下载客户端310)提供给应用308。图9 的这一方法既可以用于流传输服务也可以用于文件下载。在图9的示例中，应用308是传输不可知的。也就是，应用308不需要有任何关于如何获得数据的指示。在一些示例中，MCCH变化通知可可能无法与多带/多频环境一起工作，因为在其它频率上添加服务的网络将不会触发针对这一频率的 MCCH变化通知。
图10是描绘了实施用于选择性使用一种或多种服务获取数据的技术的示例性系统350的概念图。在图10的示例中，系统350包括UE侧和网络侧。系统350的网络侧包括应用服务器(“app服务器”)352、P-GW 354和 BM-SC 356。应用服务器(“app服务器”)352、P-GW 354和BM-SC 356 可以分别包括与图4的应用服务器202、P-GW 204和BM-SC 206的功能相同或类似的功能。BM-SC 356可以包括向系统350的网络侧的其它部件(诸如P-GW 304)指示广播可用性的功能。
在图10的示例中，系统350的UE侧包括应用358、流/文件下载客户端360、MBMS单元(“MBMS客户端(中间件)/本地服务器”)362、IP 栈364和调制解调器368 。应用358、流/文件下载客户端360、IP栈364和调制解调器368 可以分别包括与图4的应用218、流/文件下载客户端210、 IP栈214和调制解调器216的功能相同或类似的功能。MBMS单元362可以包括与图4的MBMS单元362的功能相同或类似的一些功能。在图9的示例中，MBMS单元362可以包括不同的或额外的功能。例如，MBMS单元362可以包括用于从系统350的网络侧接收指令的功能。也就是，MBMS 单元362可以从一个或多个部件(诸如P-GW 354)接收各种信息。
在图10的示例的步骤1中，应用358经由流/文件下载客户端360通过单播服务从应用服务器352获取数据。在图10的示例的步骤2中，网络中的HARD单元(未示出)检测到高附连率。该HARD单元向BM-SC 356 指示所述高附连率以启用MBMS会话(例如，MBMS承载)。BM-SC 356 向P-GW 354发送请求以使P-GW 354向UE发送指示。所述指示可以使用 PCO或NAS信令。
在图10的示例的步骤3中，当调制解调器368 接收到所述指示时，调制解调器368 向MBMS中间件(例如，MBMS单元362)指示广播或多播服务的可用性。也就是，依照本公开内容的一种或多种技术，系统350的网络侧可以使用P-GW信令，比如NAS信令、PCO或其它信令以向UE指示多播或广播服务的可用性。
在图10的示例的步骤4中，应用358通过间接从MBMS单元362获取由MBMS单元362使用广播或多播服务(例如，经由广播或多播分发模式)获得的数据来从MBMS承载(例如，BM-SC 356)获取数据。换句话说，当UE接收到数据要经由第二服务接收的指示时，UE可以激活用于经由第二服务接收数据的单元(例如，MBMS单元362)并从所述用于经由第二服务接收数据的单元接收数据。然后，可以将经由第二服务接收到的数据间接(例如，经由流/文件下载客户端360)提供给应用358。在图10 的示例中，系统350的网络侧的一个或多个部件可以可操作用于维持状态信息。也就是，图10的示例可以要求网络中的状态并且需要识别应该向哪些UE发送该指示。在图10的示例中，应用358是传输不可知的。也就是，应用358不需要有任何关于如何获取数据的指示。
图11A和11B是描绘了用于使用一种或多种服务通过网络获取数据的示例性操作的概念图。在图11A和11B的示例中，UE上运行的应用可以请求内容(例如，媒体内容、文件或其它内容)。UE的一个或多个部件(例如，流或文件下载客户端)可以与网络上的部件进行通信以确定哪些服务可用于接收针对内容的数据。UE可以确定数据只可通过单播服务获得并且该UE可以注册该单播服务。UE可以在其确定没有多播或广播服务可用时进入单播模式，并且之后可以经由所述单播服务接收数据(例如，使用单播分发模式)。UE可以周期性地检查USD的更新以确定广播或多播服务是否可用。一旦确定广播服务可用，UE可以经由该广播服务接收数据，进入广播模式，然后拆毁单播信道。
图12是描绘了用于使用一种或多种服务通过网络获取数据的示例性操作的概念图。在图12的示例中，UE可以接收针对数据的请求(例如，从 UE的流或文件下载客户端)并可以激活eMBMS。UE可以使用单播服务接收数据，诸如在广播或多播服务不可用时。网络中的HARD可以检测到针对该内容的高附连率或高需求，并且通知BM-SC该高需求。在一步方法中， BM-SC可以将单播服务直接转换为eMBMS广播服务，并且UE可以如图 11A和11B的步骤2、3和8-15中所描述的向广播服务注册。在两步方法中，BM-SC可以首先将单播服务转换为通过单播的eMBMS服务，并且UE 可以如图11A和11B的步骤2-15中所描述的从eMBMS单播服务转换到 eMBMS广播服务。
图13A和13B是描绘了用于使用一种或多种服务通过网络获取数据的示例性操作的概念图。具体来讲，图13A和13B的示例可以描述非eMBMS 单播服务到eMBMS广播服务的切换。在一些示例中，当从非eMBMS单播服务切换到eMBMS广播服务时，BM-SC可以确定(例如接收指示)至非 eMBMS服务的高附连率。然后，BM-SC可以激活服务的eMBMS传输并将内容分发从单播分发切换到广播分发。可以依照使得服务网络供应商能够将内容供应商的各个内容源从单播分发转换为广播分发的商业协定发生这一转换，诸如当检测到标称单播内容或服务的高需求时。
在图13A和13B的示例中，当UE的应用以非eMBMS单播服务开始时，该UE的eMBMS客户端可能未被激活。依照本申请中描述的技术，可以用各种方式激活eMBMS客户端，诸如通过触发UE通过单播或广播分发获取USD的网络重定向来激活。例如，该网络重定向可以是HTTP/RTSP 重定向、OMA推送或从网络实体发送的其它信令。
在图13A和13B的示例中，UE的应用可以请求内容条目。作为对来自应用(例如，流或文件下载客户端)的请求的响应，UE可以使用过顶内容(OTT)服务或分组交换流服务(PSS)经由单播服务获取数据。接下来，BM-SC可以确定非eMBMS单播服务应该被切换到服务的eMBMS传输。例如，可以基于获取的信息、基于事件和/或基于非eMBMS单播服务的高附连率的检测来做出这一确定。在一些示例中，BM-SC还可以使用附连的 UE的单播到MBMS切换能力，如果这一信息对于BM-SC已知的话。举一个确定非eMBMS单播服务应该被切换到eMBMS传输的示例，网络中的 HARD可以确定高附连率，并向BM-SC指示这一高附连率。BM-SC可以确定建立eMBMS会话作为对接收到该指示的响应。虽然在图13A和13B 的示例中显示为单独的部件，但是在一些示例中，HARD和BM-SC可以是单个部件的一部分。
在确定建立eMBMS会话之后，BM-SC可以广播更新后的USD。在一些示例中，用户服务可以包括广播和单播相关信息。在其它示例中，用户服务可以只包括广播相关信息。如果BM-SC已经针对USD建立了eMBMS 会话(例如，USD广播信道)，则BM-SC可以通过建立好的广播信道发送更新后的USD。在一些示例中，BM-SC可以针对更新后的USD建立eMBMS 会话或在稍后一点(例如，在图13A的步骤9中)的单播到广播切换触发中包括所述更新后的USD。也就是，所述BM-SC可以使更新后的USD可通过广播、单播或其它手段获得。
BM-SC可以建立MBMS会话(例如，如3GPP技术规范 23.246“Multimedia Broadcast/Multicast Service(MBMS)；Architecture and functional description,(Release 12)”(2014年3月，v12.1.0)中所规定的)。在一些示例中，BM-SC可以与发送更新后的USD平行地建立MBMS会话。eNB可以开始eMBMS会话，并且该eNB可以使用MCCH、SIB或其它通知方法向UE发送更新。也就是，如果需要，该eNB可以应用RRC并且发送更新后的SIB13和SIB15消息。该eNB可以执行MCCH变化通知以通知所有UE关于eMBMS服务的存在。
一旦MBMS会话已经被建立起来，可以向消耗非eMBMS服务的UE 发送(例如，由网络的设备发送)触发，指示MBMS用户服务针对服务或内容的可用性。例如，该网络的设备可以发送指示以使UE从单播消耗切换到广播消耗。在一些示例中，网络的设备可以额外发送USD更新。在接收到MCCH通知或其它触发之后，该UE可以被从使用单播服务重定向到使用广播服务。也就是，对于依照本申请中描述的技术配置的UE，该UE可以激活MBMS客户端。该UE可以发起服务发现过程以便通过广播信道(如果可用)或通过单播承载接收USD。当UE已经接收到该USD时，在合适的覆盖范围内并且正在消耗服务时，该UE可以从单播切换到广播接收。 UE可以通过单播或广播服务从BM-SC获取USD。可选择地，UE的MBMS 客户端可以向BM-SC注册并请求密钥。也就是，如果UE还没有向新建立的MBMS服务注册并且USD指示要求服务注册，则UE可以执行MBMS 服务注册并获取服务密钥(例如，如果该服务保护被启用的话)。在一些示例中，UE可以向eNB指示它感兴趣的频率，并且该eNB可以执行UE到适当频率的切换。也就是，UE可以根据经由空中接收自SIB 15的信息和/ 或来自BM-SC的USD确定对应MBMS服务正在不同频率上传输。因此， UE可以发送‘MBMS兴趣指示(MBMSInterestIndication)’消息以指示UE 想要切换到指出的频率。然后，eNB可以将UE切换到适当频率。然后， UE可以根据在新的频率上发送的SIB更新系统信息。
BM-SC可以接收内容，比如从内容服务器接收内容，并且使用广播服务发送数据。虽然在图13A和13B的示例中显示为从内容服务器获取内容，但是在一些示例中，BM-SC可以从PSS服务器或其它位置获取内容。在各个示例中，BM-SC可以在建立MBMS会话之后的任何时间获取内容。然后， BM-SC可以通过MBMS承载发送获取到的内容。之后，UE可以工作在广播模式中，并且可以拆毁单播信道(例如，如果没有其它单播服务的话)。在图13A和13B的示例中，可以在MooD下定义用于各种操作(诸如步骤3、4、5、6、9、10、11和/或其它操作的一些或全部)的规范性新信令。
图14是描绘了用于使用一种或多种服务通过网络获取数据的示例性操作的概念图。在图14的示例中，UE可以接收针对数据的请求(例如，从 UE的流/文件下载客户端)。UE可以使用单播服务接收数据，其中该单播服务使用OTT或PSS。网络中的HARD可以检测到针对服务的高附连率或高需求，并且通知BM-SC。该BM-SC可以将单播服务转换为通过单播的 eMBMS服务，并且发送更新后的USD可用的指示(例如，指示eMBMS 单播服务可用)。之后，UE可以被从非eMBMS单播服务重定向到eMBMS 单播服务。该UE可以激活eMBMS并且可以如图13A和13B的步骤3-15 中所描述的从eMBMS单播分发模式转换到广播分发模式。
图15A和15B是描绘了用于使用一种或多种服务通过网络获取数据的示例性操作的概念图。在步骤1到5中，UE可以将内容作为常规MBMS 用户服务来消耗。在一些示例中，该服务可以初始为非MBMS用户服务。在图15A和15B的示例中，作为对来自应用(例如，流/文件下载客户端) 的请求的响应，UE可以使用广播或单播服务获取USD。所请求的内容可以通过MBMS用户服务可获得。在一些示例中，该USD可以指示eMBMS 可以通过广播和单播分发模式二者获得。在一些示例中，该USD可以指示 MBMS用户服务可通过单播和广播分发模式二者获得。在各个示例中，USD 可以通过不包括单播信道相关信息指示MBMS用户服务只可经由广播获得。
UE的MBMS单元可以向内容服务器注册，并且请求密钥。举例而言， UE可以通知BM-SC它希望通过MBMS用户服务注册获取MBMS用户服务。也就是，如果服务保护启用则UE可以获取服务密钥(MSK)。在一些示例中，MBMS用户服务注册可以指示UE的消耗意图。在一些示例中， MBMS用户服务注册可以指示UE向服务注册以获取必要的信息的意图。之后，UE可以检测广播分发模式针对媒体内容可用，并且可以进入广播模式。BM-SC可以从内容服务器接收内容并经由广播分发模式将所述数据发送出去。
在一些示例中，图15A和15B的后续步骤可以支持MooD方面。也就是，步骤6和接下来的步骤可以实现将MBMS用户服务转为非eMBMS用户服务。在步骤6中，可以收集关于服务的操作的过程。这些过程可以包括MCE计数过程、基于BM-SC的计数过程(例如，基于注册/注销或基于其它手段)或其它操作性方面(例如，MBMS用户服务或其它非MBMS服务的受欢迎度)。举例而言，该BM-SC可以从MCE获得关于有多少UE有兴趣接收广播服务的无线接入网络(RAN)计数结果。在某一点，基于收集到的信息，BM-SC可以确定分发模式应该从广播分发切换到单播分发。该BM-SC可以基于计数、注册/注销信息和/或其它信息(例如预配置定时器的超时等)做出该判定。举例而言，基于MCE输入和/或其它信息(例如，注册或注册信息)，BM-SC可以确定到单播服务的切换。
在所述判定之后，BM-SC可以指示MBMS传输将要停止。BM-SC可以用各种方式指示所述即将发生的停止，诸如更新USD、使用带内调度片段以指示MBMS传输的结束或者以其它方式。该UE可以接收广播分发模式的结束时间的指示(例如，使用带内调度片段信息或USD更新)。
转向图15B，该UE可以检测eMBMS会话将要停止，并可以建立无线资源连接(RRC)。可以在MBMS广播分发会话结束时间之前建立RRC。如果分组数据网络(PDN)先前没有建立的话，UE还可以建立该PDN连接。也就是，如果需要，UE可以建立PDN连接。BM-SC可以停止广播分发模式，并且eNB可以使用SIB、MCCH通知或其它通知方法通知UE。例如，BM-SC可以执行如3GPP TS 23.246“Multimedia Broadcast/Multicast Service(MBMS)；Architecture and functional description”中规定的MBMS广播分发会话停止过程。在一些示例中，BM-SC可以更新USD以指示MBMS 用户服务只通过单播分发模式可获得。在一些示例中，通过从USD移除服务由BM-SC终止MBMS用户服务。
在广播分发模式已经停止之后，UE可以通过广播或单播获取新的 USD。该新的USD可以指定eMBMS服务只可通过单播分发模式获得。因此，UE可以进入单播模式并且可以经由单播分发模式接收媒体数据。在图 15A和15B的示例中，MooD WI可以定义用于各种操作(比如步骤3、6、 7、8、13和/或其它操作的一些或全部)的规范性新信令。
图16是描绘了用于使用一种或多种服务通过网络获取数据的示例性系统的概念图。图16的示例可以表示高级MooD架构。图16的示例只表示用于执行本申请中描述的技术的系统的一个示例，并且可以依照本公开内容使用各种其它系统。
图16的示例包括公共网络500(例如，互联网)、蜂窝数据网络(CDN) 502、分组交换服务(PSS)服务器504、分组数据网络网关(PDN-GW) 506、eNodeB(eNB)508、广播和多播服务中心(BM-SC)510、MBMS 网关(MBMS-GW)512和用户设备(UE)515。在一些示例中，公共网络 500、CDN 502、PSS服务器504、PDN-GW 506、eNB 508、BM-SC 510和 /或MBMS-GW 512之中的一个或多个可以表示服务供应商网络(诸如无线或蜂窝服务供应商网络)的部件。UE 515可以表示服务供应商的订户的用户设备。
在图16的示例中，UE 515可以通过eNB 508和PDN-GW 506经由单播分发(诸如过顶(OTT)服务520A、PSS服务522A和MBMS服务524A) 访问各个内容或服务。在一些示例中，可以使用单播访问URL (unicastAccessURI)提供MBMS服务524A。PDN-GW 506可以从各个源获取这些服务。例如，PDN-GW 506可以与CDN 502进行通信以获取OTT 服务520B和/或可以与公共网络500进行通信以获取OTT服务520C。 PDN-GW 506可以与CDN 502进行通信以获取PSS服务522B和/或可以与 PSS服务器504进行通信以获取PSS服务522C。PDN-GW 506可以与CDN 502进行通信以获取MBMS服务524B，可以与PSS服务器504进行通信以获取MBMS服务524C，和/或可以与BM-SC 510进行通信以获取MBMS 服务524D。
一旦服务共供应商确定(例如，由BM-SC 510确定)OTT服务520A-C、 PSS服务522A-C或MBMS服务524A-D之中的任何一个的高附连率，则 BM-SC 510可以激活eMBMS用户服务以通过MBMS承载携带相同的内容。例如，BM-SC 510可以与公共网络500和/或CDN 502进行通信以通过单播分发获取OTT服务530并将服务转换为广播分发。BM-SC 510可以与 CDN 502进行通信以通过单播分发获取PSS服务532和/或MBMS服务534，并将服务转换为广播分发。
之后，BM-SC 510可以经由广播分发提供服务530、532和/或534。UE 515可以使用广播分发经由MBMS服务540获取服务530、532和/或534 之中的一个或多个。以此方式，本申请中描述的技术可以允许UE经由多个分发模式获取内容和/或服务。
图17A和17B是描绘了用于使用一种或多种服务通过网络获取数据的示例性操作的概念图。例如，当UE支持MooD操作并且MBMS功能UE 可以向网络(例如，向BM-SC)提供关于服务的消耗的至少一个指示时，可以使用图17A和17B的示例性操作。在一些示例中，BM-SC可以是做出关于单播、广播和/或多播分发模式和/或服务的决定的中心。虽然在图17A 和17B的示例中显示为单个部件，但是在各个示例中BM-SC的物理实施方式可以是分布式的(例如，针对单播内容的可伸缩分布使用代理服务器)。类似地，虽然在图17A和17B的示例中显示为单个部件，但是在各个示例中，MBMS功能UE可以被划分为多个部件，诸如MBMS UE和应用客户端。
在图17A的示例的步骤1中，内容服务器可以提供服务，诸如流媒体或可下载内容。在一些示例中，可以使BM-SC知道这一服务是潜在MBMS 用户服务。在一些示例中，潜在MBMS用户服务可以被定义为可以潜在地迁移到MBMS用户服务中的非MBMS用户服务。在图17A的示例的步骤 2中，BM-SC通知MBMS功能UE关于该潜在的MBMS用户服务。在步骤3中，MBMS功能UE通知BM-SC关于UE对潜在MBMS用户服务的消耗。在一些示例中，UE可以持续地向BM-SC更新关于该UE的消耗。在一些示例中，UE可以额外包括关于UE的位置和/或消耗元数据。发送这一信息可以作为UE对BM-SC将潜在MBMS用户服务迁移到MBMS用户服务的隐含同意。这一迁移可以由UE以下面一种或多种方式处理：通过直接注册服务；或者通过使用常规数据请求(例如，对潜在MBMS用户服务的请求)间接进行注册。在一些示例中，UE通知BM-SC关于该UE对潜在MBMS用户服务的消耗的方式和/或UE处理迁移的方式可以依赖于可伸缩性考虑。
在图17A的步骤4中，BM-SC确定潜在MBMS用户服务是否应该被迁移到MBMS用户服务。BM-SC可以使用来自注册的信息和/或其它信息来做出该判定。在一些示例中，这一判定可以定期地贯穿潜在MBMS用户服务发生。也就是，在每个UE发起或终止潜在MBMS用户服务的消耗之后或以某一其它时间间隔，BM-SC可以周期性做出该判定(例如，每5秒、每30秒等)。在步骤5中，UE通过直接与内容服务器进行通信或通过将 BM-SC作为针对请求的代理使用(例如，该BM-SC可以将请求转发给内容服务器)来从潜在用户服务请求数据。在步骤6中，UE像常规单播服务一样接收所请求的数据。
在图17A的步骤7中，BM-SC可以在某一时间点上确定所述内容经由广播模式提供将更高效，并且可以针对潜在MBMS用户服务发起MBMS 用户服务。在步骤8中，BM-SC用广播模式建立MBMS用户服务，并通知正在消耗内容的MBMS功能UE关于该内容经由MBMS用户服务的可获得性。在步骤9中，BM-SC开始从内容服务器取回内容。在步骤10中，BM-SC 开始将取回的内容通过建立好的MBMS用户服务进行分配，通常广播模式已经启用。
现在转向图17B，在步骤11中，UE加入MBMS用户服务并开始通过 MBMS用户服务接收内容。在图17B的步骤12中，UE开始消耗通过MBMS 用户服务接收到的内容。在步骤13中，UE可以持续地通知(例如，考虑可伸缩性)BM-SC关于服务的消耗。在一些示例中，UE还可以提供注销服务的指示。在步骤14中，BM-SC可以确定经由MBMS用户服务分发内容不再是效率最高的了。BM-SC可以使用从UE接收到的信息，诸如注册信息和/或其它信息。
在图17B的步骤15中，BM-SC通知正在消耗MBMS用户服务的UE 关于MBMS用户服务的终止。在步骤16中，UE离开MBMS用户服务。在步骤17中，UE通知BM-SC它已经离开MBMS用户服务。在步骤18中， UE再次开始通过单播请求潜在MBMS用户服务的数据(例如，通过直接与内容服务器进行通信或通过将BM-SC用作针对请求的代理)。在步骤19 中，BM-SC终止MBMS用户服务但是继续提供潜在MBMS用户服务。在图17A和17B的示例中，该MooD WI可以定义用于各种操作(诸如步骤2、 3、8、13、17和/或其它操作)的规范性新信令。
在一个或多个描述的示例中，替代或补充相同服务或内容的单播分发， BM-SC可以能够提供按需eMBMS服务。在一些示例中，一旦已经动态地将单播服务转换到MBMS用户服务，BM-SC可以只通过单播承载、通过MBMS承载或通过这两种承载类型来提供服务分发。在一些示例中，BM-SC 能够以可伸缩方式向UE提供有资格在非MBMS单播服务和MBMS用户服务之间进行切换的每个服务的指示。在一些示例中，一旦获知现有MBMS 用户服务对广播分发的低附连率/容量，则BM-SC可以去激活MBMS用户服务。在一些示例中，一旦获知现有MBMS用户服务对广播分发的低附连率/容量，则BM-SC可以将MBMS用户服务限制到仅单播分发模式。
所描述的一个或多个示例可以提供要求通知UE关于可用服务和分发模式的必要信令。一个或多个所描述的示例可以提供可伸缩解决方案，无论在潜在MBMS用户服务的数量的方面还是在工作在单播模式和广播模式时涉及的UE方面。一个或多个所描述的示例可以提供上行链路和/或下行链路资源的有效使用。一个或多个所描述的示例可以考虑相关管理和隐私性原因。一个或多个所描述的示例可以尽可能重新使用现有MBMS特征，包括版本12期间在其它工作条目中开发的特征，比如增强型MBMS操作。一个或多个描述的示例可以额外或者作为替代重新使用其它现有特征，诸如公共网络技术和HTTP特征。
一个或多个所描述的示例可以最小化从潜在MBMS用户服务向实际 MBMS用户服务迁移时对用户的影响。一个或多个所描述的示例可以提供以仅广播模式和/或以广播和单播模式运行MBMS用户服务的能力。一个或多个所描述的示例可以针对通过MBMS以及MBMS下载分发服务的DASH 实现，其中该MBMS下载分发服务可以由通过常规HTTP服务器提供修复的相关联的分发过程来扩大。一个或多个所描述的示例可以允许在将服务移动到实际MBMS用户服务时维持潜在MBMS用户服务的格式(例如，无需转码为MBMS用户服务格式)。一个或多个所描述的示例可以用BMSC 和其它网络部件的最小化处理开销工作。一个或多个所描述的示例在开销、网络利用率和UE电池消耗方面很有效率。
图18是描绘了用于消耗报告的实体的一个示例的概念图。图18的示例可以表示一个可用于确定或辅助确定服务(例如，单播、广播或多播服务)的消耗并且从而更精确地确定服务经由单播、广播和/或多播传输提供是否会更高效的实体。图18的示例可以为MBMS服务运营商(例如，服务供应商网络)提供关于对MBMS用户服务的正在进行的需求的更精确的认知，并且因此该运营商可以能够更好地确定是否终止MBMS用户服务，或者临时切换到服务的仅单播分发。
在一些示例中，在特定区域中消耗MBMS用户服务的UE的数量低于某个阈值(例如，由服务供应商网络预先配置的)时，禁用MBMS传输对网络可以是有益的。可以使用各种示例性的用于确定何时终止MBMS用户服务的方法。在图18的示例中，确定何时终止MBMS用户服务可以至少部分基于MBMS服务消耗报告方法。这一方法可以被定义为对相关联分发过程(ADP)描述的扩展以用信号表示UE对MBMS用户服务消耗报告的要求，或者可以被定义为对现有接收报告的扩展(例如，通过指定新的报告类型)。
图18包括相关联过程描述(APD)600的一个示例性扩展，其包含 MBMS服务消耗报告参数602。经由APD 600的扩展，BM-SC可以在采样报告百分比(sampleReportPercentage)属性604中指定执行MBMS用户服务报告的MBMS接收机的百分比子集。该BM-SC可以在报告间隔 (reportInterval)属性606中指定UE应该进行报告的频率。该BM-SC还可以在报告标记(reportFlag)属性608中指定是否要求UE报告其何时开始或停止接收USD中的MBMS用户服务。
如果向MBMS用户服务提供采样报告百分比(sampleReportPercentage) 属性604并且值小于100，则UE可以生成均匀分布在0到100的范围内的随机数。UE可以在所生成的随机数的值小于比采样报告百分比 (sampleReportPercentage)属性604的值时周期性地(例如，根据报告间隔(reportInterval)属性606中指定的报告频率)发送MBMS用户服务报告。
如果报告标记(reportFlag)属性608被设置为“真”，则UE可以在UE 开始(例如，包括当UE移动到MBMS覆盖范围内时)或停止(例如，包括当UE移动出eMBMS覆盖范围时)接收MBMS用户服务时发送MBMS 用户服务报告。在一些示例中，诸如为了避免报告的过度起伏(例如，由于用户在快速成功打开和关闭MBMS服务应用中的不当行为或由于UE位于MBMS覆盖范围的边界附近并且反复地获得和失去覆盖)，UE可以实施基于滞回的算法以减少消耗报告。
当UE发送MBMS用户服务报告时，其可以向BM-SC指示其位置(例如，基于MooD配置的服务区域识别码(SAI)、小区全球识别码(CGI) 或演进型小区全球识别码(ECGI))。
在用于确定何时终止MBMS用户服务的其它示例性方法中，一旦预配置定时器超时，网络设备就可以禁用MBMS传输。基于定时器的机制可以适合于在先前的开启MBMS传输的决定是由特定事件发起时使用。在另一个示例中，网络的设备可以使用MCE计数过程来确定何时终止MBMS用户服务。例如，在MCE检测到对MBMS用户服务感兴趣的UE的数量下降到某个阈值(例如，100个UE、1000个UE等)以下之后，该MCE可以向BM-SC发送通知。但是，在一些示例中，MCE计数可以不包括在空闲状态中接收MBMS用户服务的UE。此外，MCE计数在3GPP RAN2的范围内。MCE计数的一个改进的解决方案可以增强当前的RAN计数以除了包括那些处于RRC_CONNECTED状态的UE之外还包括处于RRC_IDLE 状态的那些UE。另外或者作为替代，改进的MCE计数可以允许UE自动报告该UE何时开始或停止给定MBMS用户服务的消耗。改进的MCE计数可以允许UE周期性地报告给定MBMS用户服务的消耗。最后，改进的 MCE计数可以实现在网络中向BM-SC发送RAN计数测量结果。
作为确定何时终止MBMS用户服务的另一示例，可以使用基于MBMS 用户服务注册/注销的基于BM-SC的计数过程。在一些示例中，MBMS用户服务注册的语义可以指的是最终用户的消费意愿，并且可能无法指示UE 是否实际上正在消耗(例如，执行接收)eMBMS用户服务。
虽然在图18的示例中显示为消耗报告(consumptionReporting)参数 602，但是在一些示例中，本公开内容的技术可以通过在APD 600的报告过程类型(reportProceduresType)下包括MBMS服务消耗报告参数来扩展APD 600。在一些示例中，一些参数(例如，采样百分比(samplePercentage)) 可以重新用于MBMS服务消耗报告。
图19是描绘了用于消耗报告的示例性操作的概念图。图19的示例性操作可以表示MooD功能UE和BM-SC之间用于提供MBMS用户服务消耗报告的一种可能的呼叫流。
首先，BM-SC可以向MooD功能UE发送消耗报告参数(例如，作为对ADP描述的扩展)。在图19的示例中，消耗报告参数可以包括报告间隔、采样报告百分比和报告标记。其它示例中可以包括各种其它参数。在图19 的示例的步骤1中，UE可以开始经由MBMS用户服务消耗内容(例如，服务X)。例如，UE可以依照本申请中描述的技术从服务X的单播分发切换到MBMS用户服务。举另一个例子，UE可以进入服务X的MBMS覆盖区域。在步骤1中，UE可以启动对应于服务X的报告间隔定时器。
在图19的示例的步骤2中，UE可以向BM-SC发送MBMS用户服务报告。该MBMS用户服务报告可以包括UE已经开始经由MBMS用户服务消耗服务X的指示(例如，通过指示MBMS用户服务报告的类型是“开始”类型)，TMGI和UE的位置。在图19的示例的步骤3中，UE可以在通过 MBMS用户服务消耗服务X时继续对报告间隔定时器进行倒计时。在步骤 4中，UE可以检测到对应于服务X的报告间隔定时器已经超时。接下来，在步骤5中，UE可以发送另一个MBMS用户服务报告，包括该报告是过渡更新(例如，该报告是“过渡更新”类型)的指示、TMGI和UE的位置。在发送MBMS用户服务报告之后，在步骤6中UE可以重置对应于服务X 的报告间隔定时器。在步骤7中，UE可以再次对报告间隔定时器进行倒计时。
随着UE继续消耗服务X，步骤4到7可以重复若干次。在图19的步骤8中，UE可以停止消耗服务X。例如，UE可以停止执行正在接收服务 X的应用，或者UE可以移动出服务X的MBMS覆盖区域。在图19的步骤9中，UE可以向BM-SC发送另一个MBMS用户服务报告，包括UE已经停止经由MBMS用户服务消耗服务X的指示(例如，通过指示该报告是“停止”类型)，以及TMGI和UE的位置。通过向BM-SC发送MBMS用户服务报告，UE可以向BM-SC提供更精确的信息用于确定是否经由单播、广播和/或多播分发模式提供内容。
图20A和20B是描绘用于选择性使用一个或多个服务获取流媒体数据的示例性操作的概念图。图20A和20B的示例性操作下面是在图4的系统 200的一般上下文中描述的，但是在各个示例中可以由其它系统执行。在图 20A和20B的示例中，流/文件下载客户端210可以是DASH客户端，MBMS 单元212可以是MBMS客户端(例如，MBMS中间件)和本地HTTP服务器，代理单元213可以是本地HTTP代理。此外，在图20A和20B的示例中，BM-SC 206和重定向/代理单元205可以表示为单个BM-SC单元的一部分，包括代理服务器功能单元以及服务公告和会话&传输功能单元。App 服务器202可以是能够提供DASH分段的内容服务器以及提供MPD的内容服务器。
依照本公开内容的一种或多种技术，应用208可以使用流/文件下载客户端210(例如，使用DASH协议)获取媒体数据。例如，应用208可以向流/文件下载客户端210发送指示清单文件(例如，MPD)的位置的URL，该清单文件接着定义用于依照第一服务(例如，单播)取回媒体数据的一个或多个资源位置。流/文件下载客户端210可以通过向应用服务器202(例如，通过代理单元213)发送HTTP GET请求获取MPD。代理单元213可以允许HTTP GET请求经由IP栈214、调制解调器216、P-GW 204和/或重定向/代理单元205传递到达应用服务器202。在图20A的示例中，代理单元213还可以向MBMS单元212发送MPD URL的指示(例如，通过调用 API)。
应用服务器202可以接收HTTP GET请求，并发送200-类型HTTP OK 消息作为响应。该OK消息可以传递通过BM-SC代理服务器以及本地HTTP 代理而无需修改。该OK消息可以包括单播MPD。流/文件下载客户端210 可以接收MPD并确定要获取的媒体数据的表示、周期和分段(例如，周期 3、表示256、分段1)。至少部分基于该MPD，流/文件下载客户端210可以查找用于确定的分段的URL并利用确定的URL(例如，“http://example.com/per-3/rep-256/seg-1.3gp”)发送HTTP GET请求。该HTTP GET请求可以传递通过本地HTTP代理和BM-SC代理服务器功能单元而无需修改。
应用服务器202可以接收该GET请求，并且作为响应，可以发送包括所请求的媒体数据(例如，“分段1”)的200-类型HTTP OK消息。该HTTP OK消息可以传递通过BM-SC代理服务器功能单元和本地HTTP代理而无需修改。以此方式，流/文件下载客户端210可以使用单播服务从应用服务器202获取流媒体数据。
在网络侧，BM-SC 206的代理服务器功能单元可以检测到对于单播服务的高需求。作为响应，BM-SC 206可以针对内容启用MBMS(例如，广播)服务。BM-SC 206可以从应用服务器202请求并接收针对内容的单播 MPD。然后，BM-SC 206可以广播包括公共MPD和/或其它参数的用户服务描述(USD)。贯穿该内容接下来的MBMS分发的过程，BM-SC 206可以继续从应用服务器202请求和接收内容。在启用MBMS用户服务之后， BM-SC 206(和/或重定向/代理单元205)可以利用代理服务器功能单元针对所述内容重定向UE。
之后，流/文件下载客户端210可以继续发送针对媒体数据的HTTP GET 请求，诸如针对分段M的请求，包括来自原始MPD的对应URL(例如，“http://example.com/per-3/rep-256/seg-M.3gp”)。该GET请求可以传递通过本地HTTP代理而无需修改。但是，当BM-SC 206的代理服务器功能单元 (例如，重定向/代理单元205)接收针对分段M的GET请求时，在图20A 的示例中，BM-SC 206可以向UE发送HTTP重定向消息。该重定向消息可以包括扩展报头，包括用于向本地代理单元213指示向MBMS单元212 注册的响应报头和/或重定向URL。该重定向URL可以表示针对相同的所请求的资源的不同位置。例如，如果原始请求URL是 http://example.com/per-x/rep-y/seg-z.3gp，则重定向URL可以是 http://example.com/redirect/per-x/rep-y/seg-z.3gp。3GPP定义的HTTP扩展报头可以命名为具有值“Get-USD”的“触发-MBMS”，在这种情况中，针对UE 所请求的内容的HTTP响应消息可以伴随有响应报头“触发-MBMS：Get USD”。
本地代理单元213可以接收所述HTTP重定向并且向重定向中指定的 URL发送针对所指示的媒体数据(例如，分段M)的HTTP GET请求。BM-SC 206的代理服务器功能单元可以将HTTP GET请求导向应用服务器202以取回分段。在一些示例中，BM-SC 206的代理服务器功能单元可以接收向新的URL发送的HTTP GET请求，并将未修改的请求转发给应用服务器 202。在一些示例中，BM-SC 206的代理服务器功能单元可以接收向新的 URL发送的HTTP GET请求并修改所述请求以将所述请求导向原始URL。也就是，在一些示例中，BM-SC 206的代理服务器功能单元可以允许请求传递到达重定向URL(例如，当应用服务器202被配置为处理去往重定向位置的请求时)，而在其它示例中，BM-SC 206的代理服务器功能单元可以将所述请求转发给常规URL(例如，使得应用服务器202不需要被配置为处理去往重定向位置的请求)。应用服务器202可以接收HTTP GET请求并发送包括所请求的分段的200-类型HTTP OK消息。以此方式，本地HTTP 代理可以确保在UE转换到经由MBMS服务接收内容时接收到DASH客户端所请求的内容。
作为对接收到HTTP重定向的响应，本地代理单元213可以与MBMS 客户端/本地HTTP服务器212进行通信(例如，经由API)以触发MBMS 客户端(例如，发起经由MBMS服务的内容接收)。
现在转向图20B，当通过发送HTTP GET消息、接收HTTP重定向、向所述重定向中指定的URL发送对应HTTP GET消息以及接收所请求的内容而建立MBMS会话时，UE可以继续获取所述内容。在从本地代理单元 213接收到触发之后，MBMS客户端/本地HTTP服务器212可以获取更新后的USD(例如，从BM-SC 206接收到的HTTP重定向中指定的)。该USD 可以是经由广播或单播获取的。在获取该USD之后，MBMS客户端/本地 HTTP服务器212可以确定针对服务(例如，服务X)的新的MPD URL与针对单播服务接收到的MPD URL相匹配。因此，MBMS客户端/本地HTTP 服务器212可以针对服务X激活FLUTE会话。
BM-SC 206可以通过FLUTE发送针对服务X的分段和/或MPD。 MBMS客户端/本地HTTP服务器212可以接收足够的内容并确定建立了 MBMS用户服务。如果USD指示单播MPD中包含的相同表示(例如，表示256)也包含在统一的MPD中，并且该表示可以通过广播分发获得，则 MBMS客户端/本地HTTP服务器212可以与本地代理单元213进行通信(例如，使用API)来配置本地代理单元213以将针对服务X内容的请求重定向到MBMS客户端/本地HTTP服务器212。也就是，MBMS客户端/本地 HTTP服务器212可以使得本地代理单元213将针对服务X的MPD的请求重定向到MBMS客户端/本地HTTP服务器212处的MPD，并且可以使得本地代理单元213将针对服务X的分段的请求重定向到MBMS客户端/本地HTTP服务器212处的服务X的分段。
之后，当流客户端210发送针对特定分段(例如，分段N)的HTTP GET 请求时，本地代理单元213可以将所述请求重定向到MBMS客户端/本地 HTTP服务器212。MBMS客户端/本地HTTP服务器212可以接收所述请求并将分段N作为200-类型HTTP OK消息的一部分进行发送。
图21是描绘了针对MooD配置的管理对象的一个示例的概念图。在一些示例中，图21的管理对象可以包括在发送到UE的HTTP重定向的报头中，从而向UE指示流数据可通过广播和/或多播服务获得。在一些示例中， OMA-DM可以用于指定MooD配置信息。如果这一DM配置对象存在于 UE上，则无论何时UE决定支持MBMS卸载UE都可以使用它。该OMA DM 管理对象可以额外地或者作为替代用于配置针对任何类型的有资格经由 HTTP或RTP通过单播网络访问的内容的卸载。
在一些示例中，该管理对象标识符可以被设置为： urn:oma:mo:ext-3gpp-mbmsmood:1.0。该MO可与OMA设备管理协议规范版本1.2和以上版本兼容(如由开放移动联盟核准的“OMA Device Management Protocol”(2008年6月，版本1.2.1)所指定的)，并且使用如由开放移动联盟核准的“Enabler Release Definition for OMA Device Management”(2008年6月，版本1.2.1)中所描述的OMA DM设备描述框架来定义。
图21的示例描述3GPP_MBMS MooD MO下包含的节点和叶对象，如果MBMS中间件客户端支持所描述的属性的话。
在图21的示例中，节点700(例如，节点：/<X>)可以指定MBMS MooD 管理对象的唯一对象ID。这一内部节点可以将单个对象的参数分组到一起。
-发生：0或1
-格式：节点
-最小访问类型：Get
如果UE支持“MBMS MooD管理对象”，则可以包含下面的内部节点。
在图21的示例中，节点702(例如，/<X>/启用)可以指示BM-SC是否支持MooD。
-发生：1
-格式：布尔型
-最小访问类型：Get
在图21的示例中，节点704(例如，/<X>/代理服务器)可以表示UE 可以用于该UE选择通过MBMS潜在地接收的所有单播请求的一个或多个代理服务器。
-发生：1
-格式：节点
-访问类型：Get，Replace
-值：N/A
在图21的示例中，节点706(例如，/<X>/代理服务器/<X>)可以作为与用于代理服务器选择的内容限制标识符相关联的地址，用作代理服务器信息的一个或多个实例的占位符。如果有多于一个代理服务器满足内容限制的条件，该UE可以随机选择一个代理服务器。
-发生：1或更多
-格式：节点
-访问类型：Get，Replace
在图21的示例中，节点708(例如，/<X>/代理服务器/<X>/地址)可以用完全限定域名(FQDN)的形式指示代理服务器的一个或多个地址。每个代理服务器可以与内容限制集合相关联，必须满足该集合中的至少一个内容限制以便UE将那个/那些代理服务器用于对UE选择潜在地通过 MBMS接收的资源的所有UE的单播请求。
-发生：1或更多
-格式：字符
-访问类型：Get，Replace
-值：FQDN(一个或多个)
在图21的示例中，节点710(例如：/<X>/代理服务器/<X>/内容限制) 可以是包含一个或多个域名的叶节点，所述域名用于与UE发出的资源请求的HTTP或RTSP URL进行匹配，以确定所请求的内容是否有资格从单播访问转换为MBMS用户服务，并且如果匹配，则使用对应代理服务器。这一值和所请求的资源URL之间的匹配可以指示所请求的资源可以被切换到 MBMS分发，并且相关联的代理服务器应该由UE用于该资源的单播访问。 -发生：1或更多
-格式：字符
-访问类型：Get，Replace
-值：如由Berners-Lee等人的“Uniform Resource Identifier(URI):Generic Syntax”(2005年1月，IETF，RFC 3986)中定义的URI方案与Mockapetris 的“Domain Names–Implementation and Specification”(1987年11月，IETF， RFC 1035)中所定义的域名的拼接。
在图21的示例中，节点712(例如，/<X>/代理服务器/<X>/Ext)可以是能够放置与UE对代理服务器的选择有关的供应商特定(应用供应商、设备供应商等)信息的内部节点。在一些示例中，供应商扩展可以由Ext节点下的供应商特定名称来标识。所标识的供应商下的树结构是没有定义的，并且可以因此包括一个或多个非标准化子树。
-发生：0或1
-格式：节点
-最小访问类型：Get，Replace
在图21的示例中，节点714(例如，/<X>/USD)可以表示MBMS用户服务发现/公告信息定义的开始点。
-发生：0或1
-格式：节点
-最小访问类型：Get，Replace
在图21的示例中，节点716(例如，/<X>/USD/URL)可以向封装了用于按需MBMS用户服务的所有相关元数据片段的聚合服务公告文档提供 URL，UE可以使用单播信道取提取文档。它还可以由网络在网络的设备重定向UE以切换MBMS接收时使用。如果重定向消息应该为服务公告信息提供替代性的重定向链路，则它应该优先于MO提供的URL。
-发生：0或1
-格式：字符
-最小访问类型：Get
-值：<HTTP URL>
在图21的示例中，节点718(例如，/<X>USD/Ext)可以是能够放置运营商特定信息的内部节点。在一些示例中，该运营商扩展由Ext节点下的运营商特定名称来标识。所标识的运营商下面的树结构可以是未定义的，并且因此可以包括一个或多个非标准化子树。
-发生：0或1
-格式：节点
-最小访问类型：Get
在图21中，节点720(例如，/<X>/位置类型)可以提供UE的位置类型以在单播内容请求中报告。可以呈现下面的条目之一：小区ID(例如，以小区全球识别码(CGI)或E-UTRAN小区全球识别码(ECGI)的形式)。 CGI和ECGI是在3GPP技术规范23.003“Numbering,addressing and identification,(Release 12)”(2014年3月，v12.2.0)中定义的。当存在时， UE可以将其位置作为MooD报头字段的一部分与其发送给MooD代理服务器的请求一起发送。
-发生：0或1
-格式：字符
-最小访问类型：Get
值：恰好是下面的位置信息类型中的一个：CGI、ECGI。
在图21的示例中，节点722(例如，/<X>/Ext)可以是能够放置运营商特定信息的内部节点。在一些示例中，该运营商扩展可以由Ext节点下的运营商特定名称来标识。所标识的运营商下的树结构可以是未定义的，并且因此可以包括一个或多个非标准化子树。
-发生：0或1
-格式：节点
-最小访问类型：Get
在一个或多个示例中，所描述的功能可以实施在硬件、软件、固件或它们的任意组合中。如果实施在软件中，所述功能可以作为一个或多个指令或代码存储在计算机可读介质上或在所述介质上传输，并且可以由基于硬件的处理单元执行。计算机可读介质可以包括计算机可读存储介质(其对应于诸如数据存储介质的有形介质)，或者包括任何有助于计算机程序从一个地方到另一个地方的转移(例如，根据通信协议)的任何介质的通信介质。以此方式，计算机可读介质一般可以对应于(1)非临时性有形计算机可读存储介质或(2)诸如信号或载波的通信介质。数据存储介质可以是能够由一个或多个计算机或者一个或多个处理器访问以取回用于实现本公开内容中描述的技术的指令、代码和/或数据架构的任何可用介质。计算机程序产品可以包括计算机可读介质。
举个例子，但是并不是限制，这种计算机可读存储介质可以包括RAM、 ROM、EEPROM、CD-ROM或其它光盘存储器、磁盘存储器或其它磁存储设备、闪存，或可以用于以指令或数据结构的形式存储期望程序代码并可以由计算机访问的任何其它介质。此外，任何连接也都可适当地被称作计算机可读介质。举个例子，如果指令是使用同轴电缆、纤维光缆、双绞线、数字用户线(DSL)、或无线技术(比如红外、无线电和微波)从网站、服务器、或其它远程源传输的，则同轴电缆、纤维光缆、双绞线、DSL、或无线技术(比如红外、无线电和微波)包含在介质的定义中。但是，应该理解的是计算机可读存储介质和数据存储介质不包括连接、载波、信号或其它瞬时介质，相反指的是非临时性、有形的存储介质。本申请中所用的磁盘和光盘，包括压缩光盘(CD)、激光光盘、光学光盘、数字多功能光盘 (DVD)、软盘和蓝光光盘，其中，磁盘通常磁性地复制数据，而光盘则用激光光学地复制数据。上述的结合也应当包含在计算机可读介质的范围内。
指令可由一个或多个处理器执行，比如一个或多个数字信号处理器 (DSP)、通用微处理器、专用集成电路(ASIC)、现场可编程逻辑阵列 (FPGA)或其它等价的集成的或分立的逻辑电路。因此，如本申请中所用的术语“处理器”，可以指任何前述的结构或任何其它适用于实现本申请所描述的技术的结构。另外，在一些方面中，本申请所描述的功能可以在被配置为用于编码和解码或者并入组合的编解码器的专用硬件和/或软件模块中提供。并且，技术可以完全实现在一个或多个电路或逻辑元件中。
本发明的技术可以实现在很多不同类型的设备或装置中，包括无线手机、集成电路(IC)或IC集合(例如，芯片组)。本公开内容中描述了各种组件、模块或单元以强调被配置为用于执行所公开的技术的设备的功能方面，但是不是必需要求由不同硬件单元实现的。而是如上所述，各个单元可以组合在编解码器硬件单元中或由互操作的硬件单元集合提供，包括如上所述的一个或多个处理器，结合适当的软件和/或固件。
已经描述了各个示例。这些和其它示例在权利要求的范围内。