CN109964471B

CN109964471B - 用于向移动用户设备发送内容的方法

Info

Publication number: CN109964471B
Application number: CN201780071552.3A
Authority: CN
Inventors: R·拉霍里-卡尔拉特; T·特兰泰; C·博迪内; C·蒂埃诺
Original assignee: Expway SA
Current assignee: Expway SA
Priority date: 2016-10-18
Filing date: 2017-10-18
Publication date: 2022-03-22
Anticipated expiration: 2037-10-18
Also published as: KR20190066060A; US11165841B2; EP3529972B1; CN109964471A; WO2018073317A1; EP3529972A1; US20190273769A1; KR102381335B1

Abstract

本发明涉及一种用于从用户终端访问传递内容的服务的方法，该方法包括：向终端的客户端模块(MBMC)发送统一资源定位符URL，该URL包括请求内容(CNT)的标识符和指定与向用户终端(UM)传递所述请求内容相关的请求或条件的命令，如果根据所指定的条件所述请求内容在用户终端中可用，则从客户端模块接收所述请求内容(CNT)，以及如果根据所指定的条件所述请求内容在用户终端中不可用，则向服务广播服务器(BMS)发送URL。

Description

用于向移动用户设备发送内容的方法

技术领域

本公开的各方面可以涉及用于通过无线通信网络向用户设备发送具有各种格式的内容的方法和设备。

背景技术

无线通信网络被广泛部署以提供各种通信服务，诸如语音、视频、分组数据、消息传递、广播等。这些无线网络通常是能够通过共享可用网络资源来支持多个用户的多路访问网络。

无线通信网络可以包括多个基站，该基站可以支持多个用户设备(也称为移动实体)的通信。用户设备可以经由下行链路和上行链路与基站通信。下行链路(或前向链路)指的是从基站到用户设备的通信链路，并且上行链路(或反向链路)指的是从用户设备到基站的通信链路。

第三代合作伙伴计划(3GPP)长期演进(LTE)代表了作为全球移动通信系统(GSM)和通用移动电信系统(UMTS)的演进的蜂窝技术的重大进步。LTE物理层(PHY)提供了在基站和移动实体之间传送数据和控制信息二者的高效方式。在先前的申请中，用于促进多媒体的高带宽通信的方法是用于广播的单频网络(SFN)操作。SFN利用无线发射机，诸如例如基站中的无线发射机，与订户(subscriber)设备通信。在单播操作中，每个基站被控制为发送承载指向一个或多个特定订户设备的信息的信号。

在广播操作中，广播区域中的几个基站可以以同步的方式广播信号，承载可以由广播区域中的任何订户设备接收和访问的信息。在发送一般公共兴趣的信息(例如，与事件相关的多媒体广播)方面，广播操作的通用性使得其比单播服务更高效。随着针对事件相关多媒体和其它广播服务的需求和系统能力增加，系统运营商对利用3GPP网络中的广播操作表现出越来越大的兴趣。

诸如视频内容的内容的传输可以通过通信网络中的各种方法来执行。在视频内容的情况下，例如，可以经由单播传输或多播/广播传输来进行从视频源到显示器的视频信息的传输。单播传输指向特定目标接收设备。为了获得单播传输，目标设备可以具有带有视频源地址的统一资源定位符(URL)，并且可以生成HTTP(超文本传输协议)GET命令，其可以发送到视频源(通常是服务器)以便于下载视频文件。

用于在单播环境中传输视频的已知方法是通过HTTP上的动态自适应流传输(DASH)。在单播中使用DASH获取整个文件。DASH可以将视频文件转换为称为DASH段的较小组件，其可以在接收设备处重新组装以显示所需的视频。另一种方法是HTTP实时流传输(HLS)，遵循与DASH相同的机制。

因为传输被发送到多个接收设备，诸如在演进的多媒体广播/多播服务(eMBMS)中的多播或广播传输呈现出不同的考虑因素。在这些环境中，接收设备可以在相关联的系统之前获得信息，该相关联的系统实际上采取步骤来获得该信息。接收设备可以将所接收的信息存储在本地高速缓存中。当系统(通常在应用层)生成用于获得信息的URL时，生成的URL可以指向已经在本地高速缓存中而不是如在单播环境中的服务器端的内容。

DASH结合单向传输的文件传递(FLUTE)可以用在多播环境中。根据这种组合，视频内容可以被转换为DASH段，并且可以由FLUTE分组引擎(FPE)累积小组的DASH段，该FLUTE分组引擎进而可以将DASH段转换为FLUTE分组以进行传输。DASH段的结构符合ISO基础媒体文件格式(ISOBMFF)。

DASH和大多数基于ISOBMFF的自适应流技术通常假设无差错的传输层。然而，诸如eMBMS的部署可以依赖于多播用户数据报协议(UDP)或诸如DVB-GSE(数字视频广播-通用流封装)的其它广播数据链路层来传递DASH段。

可以使用MBMS方案或HTTP/HTTPS方案来访问网络可用内容或服务。传统上，用户设备被配置为以直接方式使用MBMS应用程序接口(API)访问MBMS服务，并使用HTTP/HTTPSURL查询HTTP/HTTPS内容。

当用户设备(安装在用户设备中的应用程序)请求内容时，所请求内容可能已经下载到用户设备中并且本地存储在高速缓冲存储器中，它可以以单播或多播或广播的形式传递，并且它可以在请求传输时被传递，或传递可以被安排在将来。此外，规范3GPP TS26.347引入了一种通用情况，其中使用通用操作系统URL解析库，由客户端应用程序呈现(render)和查询资源。取决于给定的方案(例如，mbms，http)，调用操作系统的适当的URL处理机(handler)来处理资源呈现。如果用户应用程序提供的URL的方案名称是http/https，则将URL提供给HTTP URL处理机。如果URL中存在mbms方案名称，则将URL提供给MBMS URL处理机。

可能希望利用MBMS的所有特性并向用户设备提供简化且灵活的内容传递服务，特别是考虑到内容项可以已经下载并高速缓存在用户设备中，或者可以以单播或多播/广播的形式传递。还可能期望以广播模式安排内容传递，特别是在对服务有很高的需求时。因此，期望使用户设备能够获得关于多播/广播模式中的内容传递的信息并且定义要应用于内容传递的条件。

发明内容

描述了一种用于从用户终端访问传递内容的服务的方法。该方法包括：向终端的客户端模块发送统一资源定位符URL，该URL包括请求内容的标识符和指定与向用户终端传递所述请求内容相关的请求或条件的命令，如果根据所指定的条件所述请求内容在用户终端中可用，则从客户端模块接收所述请求内容，以及如果根据所指定的条件所述请求内容在用户终端中不可用，则向服务广播服务器发送URL。

根据实施例，该方法进一步包括由用户终端的应用程序生成URL。

根据实施例，URL包括指定多媒体广播或多播服务或超文本传输协议服务作为服务类型的方案，该方法进一步包括向特定于该方案的终端的URL处理机发送URL。

根据实施例，指定的条件是与所述请求内容的访问相关的调度或时间条件，和/或与用户终端能力相关的技术条件，和/或与所述请求内容相关的用户所定义的用户条件。

根据实施例，该命令指定针对所述请求内容传递的当前状态的请求。

根据实施例，该命令属于命令集，该命令集包括：

指定请求所述请求内容的开始时间的命令，如果没有指定时间，则开始时间是当前时间，

指定请求该内容的时间段的命令，

指定媒体编解码器和用户终端的显示大小的命令，

指定用户终端位置的命令，

指定用于所述请求内容的优选语言的命令，

指定从其开始请求所述请求内容的内容发布日期的命令，

指定所述请求内容的请求部分的开始和结束的命令，

用于停止或取消对所述请求内容的访问的命令，

用于请求所述请求内容的传递状态的命令，

用于指定终端必须在后台访问所请求服务内容的命令，

用于请求在所述请求内容准备好被广播时接收通知或者指示所述请求内容何时准备好被广播的命令，以及

用于请求所述请求内容一个时段内可用的最新版本的命令，所述时段从由指定开始时间的命令指定的时间开始，并且具有由指定内容在其期间被请求的时段的命令定义的持续时间。

根据实施例，该方法进一步包括从服务广播服务器接收所述请求内容将在指定日期被广播的通知。

根据实施例，该方法进一步包括由服务广播服务器对在网络区域中请求内容的终端的数量进行计数，以及当请求内容的终端的数量超过阈值时，调度内容的广播。

根据实施例，该方法进一步包括向请求内容的终端通知与所述请求内容的广播相关的调度数据。

根据实施例，URL包括：传递所述请求内容的服务的服务标识符和内容标识符，或者URL仅包括内容标识符，当URL仅包括内容标识符时，该方法进一步包括域名系统解析。

实施例还可以涉及被配置为访问传递内容的服务的终端，该终端进一步被配置为实现如先前定义的方法。

实施例还可以涉及可加载到计算机存储器中并且包括代码部分的计算机程序产品，该代码部分当由一个或多个计算机执行时，配置一个或多个计算机以执行如先前定义的方法。

附图说明

参考以下附图和描述可以更好地理解该方法和/或设备。使用以下附图描述非限制性和非穷举性描述。在附图中，除非另有说明，否则相同的附图标记可以在不同附图中指代相同的部件。

图1是通过网络提供媒体数据的多播或广播服务的系统的框图，

图2是图1的系统的更详细视图的框图，

图3示意性地示出了在移动终端中实现的用于访问单播或广播内容的软件层，

图4是根据实施例的移动终端内的功能架构的框图；

图5是根据另一实施例的移动终端内的功能架构的框图；

图6是示出根据实施例的提供用户终端对广播内容的访问的步骤的顺序图。

具体实施方式

本公开涉及与通过网络的多媒体数据(诸如音频和视频数据)的流传输和文件传递服务有关的技术。可以与HTTP上的动态自适应流传输(DASH)结合使用的这些技术包括流传输视频数据，使用文件传递服务的多播或广播协议(诸如单向传输的文件传递(FLUTE)协议)根据ISO基础媒体文件格式(ISOBMFF)封装该流传输视频数据。FLUTE建立在异步分层编码(ALC)协议之上，该协议提供可靠的传输，并且因此，FLUTE也可以被称为FLUTE/ALC。

可用于代替FLUTE的附加文件传递协议包括：FCAST、原始ALC/LCT(例如，使用ALC和LCT报头来传递文件属性，诸如文件类型、编码和压缩属性)、ROUTE和NORM。FCAST在2011年10月在IETF RMT工作组的由Roca所著的“FCAST:Scalable Object Delivery for theALC and NORM protocols(FCAST：用于ALC和NORM协议的可扩展对象传递)”中描述。ALC在2010年4月在RFC 5775的由Luby等人所著的“Asynchronous Layered Coding(ALC)Protocol Instantiation(异步分层编码(ALC)协议实例化)”中描述。LCT在2009年10月在RFC 5651的由Luby等人所著的“Layered Coding Transport(LCT)Building Block(分层编码传输(LCT)构建块)”中描述。ROUTE是在“Signalling,Delivery,Synchronization,andError Protection(A/331)(信令、传递、同步和错误保护(A/331))”中描述的针对ATSC 3.0的FLUTE的演变。NORM在2009年11月在RFC 5740的由Adamson等人所著的“NACK-OrientedReliable Multicast(NORM)Transport Protocol(面向NACK的可靠多播(NORM)传输协议)”中描述。用于大规模文件广播下载的其它协议包括IEEE 802.1E系统负载协议，其在MAC层广播文件。在基于IP的移动广播TV系统中，诸如DVB-H、ATSC-M/H、3GPP MBMS(多媒体广播多播服务)、3GPP2BCMCS(广播和多播服务)，使用不同传输协议传递流传输和文件传递服务。流传输服务传递采用RTP(实时传输协议-根据RFC 3550)或MMT(MPEG媒体传输，ISO/IEC23008-1中规定)，而文件传递服务包括FLUTE/ALC(分别根据RFC 3926和RFC5775)。基于单播的自适应HTTP流传输服务目前是用于视频传递的因特网中的主要技术，并且在3GPP[TS26.247]和MPEG[ISO/IEC FCD23001-6]中被标准化，通常被称为DASH(HTTP上的动态自适应流传输)。

广播流传输传递还可以利用文件传递服务，诸如RFC 6726中记录的FLUTE协议。文件传递服务可以在广播媒体访问控制(MAC)协议上操作，诸如增强型多媒体广播多播服务(eMBMS)，其基于LTE技术或诸如IP多播的多播协议。流传输和文件内容二者都由单个应用程序传输协议(例如，FLUTE)承载。此外，通过使用DASH作为连续媒体“文件”结构来承载FLUTE/ALC分组中的流传输内容，从广播到单播传递的服务连续性仅涉及从通过FLUTE/广播来传输DASH段到HTTP/单播的切换。

图1表示提供多媒体数据MBMS(多媒体广播多播服务)的广播多播流传输和/或文件传递服务的系统。该系统包括一个或多个内容服务器CNTS、一个或多个网络IPN(例如因特网)、一个或多个服务器MBMS(实施MBMS或eMBMS服务，经由网络IPN中的一个网络链接到服务器CNTS中的一个服务器)、在服务器BMS和移动网络UTRN之间的一个或多个网关MGW，以及各自连接到移动网络UTRN中的一个移动网络的用户或客户端设备UM。服务器CNTS中的一个服务器例如根据MPEG-DASH发送多媒体内容。

文件传递可以涉及用于下载可从公共基本URL(例如，Web服务的HTML页面)访问的单个文件或一组文件的服务。

图2是图1的系统的示例性详细框图。在该示例中，服务器CNTS产生和/或存储内容数据CD，诸如编码视频数据、音频数据、文件、多媒体内容等。更一般地，服务器CNTS可以产生数据流，该数据流可以在被封装在文件中之前被转换成分组化的基本流。可以根据诸如ITU-T H.261、H.262、H.263、MPEG-1、MPEG-2、H.264/MPEG-4第10部分的压缩标准对每个单独的流进行压缩处理。

在图2的示例中，服务器CNTS包括封装单元ENCM，该封装单元ENCM接收包括编码数据的基本流。封装单元ENCM从基本流形成对应的网络抽象层单元。封装单元ENCM可以将针对多媒体内容的一个或多个表示的数据连同清单(manifest)文件(例如，MPD)一起提供给输出接口OINT。输出接口OINT可以包括网络接口或用于写入存储介质的接口，诸如通用串行总线(USB)接口、CD或DVD写入器或刻录机、到磁或闪存存储介质的接口，或用于存储或发送媒体数据的其它接口。封装单元ENCM可以将对应的多媒体内容的每个表示的数据提供给输出接口OINT，该输出接口OINT可以经由网络传输或存储介质向服务器BMS发送数据。

服务器BMS可以实现一个或多个广播或多播协议以广播或多播多媒体数据。在图2的示例中，服务器BMS可以包括存储各种多媒体内容MCNT的存储介质、请求处理单元RQPU和网络接口FSND。在一些示例中，服务器BMS可以包括多个网络接口，其包括网络接口FSND。此外，服务器设备MBMS的任何或所有特征可以在内容分发网络的其它设备(诸如路由器、网桥、代理设备、交换机，或其它设备)上实现。在一些示例中，内容分发网络的中间设备可以高速缓存多媒体内容MCNT的数据，并且包括基本上符合服务器BMS的组件的组件。通常，网络接口FSND被配置为经由网络IPN发送和接收数据。

在DASH的示例中，可以存在针对多媒体内容的多个表示。这种表示的清单在媒体呈现描述MPD数据结构中定义。媒体呈现可以对应于HTTP流传输客户端设备可访问的结构化数据集合。HTTP流传输客户端设备可以请求和下载媒体数据信息以向客户端设备的用户呈现流传输服务。MPD数据结构描述了每个表示的编码和呈现特性。另外，服务器设备可以提供描述广播或多播的特性的数据，从而例如向客户端设备提供用于接收广播或多播的足够的信息。例如，数据可以包括客户端设备可以用来加入多播内容传递的多播地址。

多媒体内容MCNT可以包括清单文件和一个或多个表示。在一些示例中，表示可以被分成自适应集。也就是说，各种表示的子集可以包括相应的共同特性集。清单文件可以包括指示表示中对应于特定自适应集的子集的数据，以及针对自适应集的共同特性。清单文件还可以包括表示针对自适应集的各个表示的各个特性的数据，诸如比特率。以该方式，自适应集可以提供简化的网络带宽自适应。可以使用清单文件的自适应集元素的子元素来指示自适应集中的表示。

请求处理单元RQPU被配置为从客户端设备UM接收针对数据内容MNCT的网络请求。例如，请求处理单元RQPU可以实现超文本传输协议(HTTP)版本1.1或2(版本1.1在RFC 2616中描述，版本2在RFC7540中描述)。也就是说，请求处理单元RQPU可以被配置为接收HTTPGET或部分GET请求，并响应于请求提供多媒体内容MCNT的数据。请求可以例如使用段的URL指定表示中的一个表示的段。在一些示例中，请求还可以指定段的一个或多个字节范围。在一些示例中，可以使用部分GET请求来指定段的字节范围。

请求处理单元RQPU可以进一步被配置为服务HTTP HEAD请求以提供表示中的一个表示的段的报头数据。在任何情况下，请求处理单元RQPU可以被配置为处理请求以向请求设备(诸如客户端设备UM)提供请求数据。

网络接口FSND可以被配置为从请求处理单元RQPU接收DASH段，并将它们转换为FLUTE分组FP。网络接口FSND可以在一个或多个FLUTE分组上对DASH段进行分段。到FLUTE分组FP的转换涉及FEC(前向纠错)编码，以采用冗余数据对DASH段进行编码，从而实现传输纠错。为了将FLUTE分组FP与DASH段相关，网络接口FSND可以为每个段分配一个传输对象标识符(TOI)。一个段可以被认为是一个文件，并且段URL可以与由TOI识别的FLUTE文件的文件名相同。网络接口FSND可以生成文件传递表(FDT)实例以描述那些DASH段的属性。DASH段的属性可以包括文件名(由例如URL指定)、文件类型(例如，文件的MIME媒体类型)、文件的大小、文件的消息摘要(例如，MD5)、有关FEC处理的信息，以及文件的编码格式。表FDT可以在由网络接口FSND发送的一个或多个FLUTE分组FP中发送。

客户端设备UM可以包括文件接收器FREC、应用程序APP和MBMS客户端模块MBMC。应用程序APP可以包括用于利用从服务器BMS接收的内容的软件，包括例如诸如音频和视频解码器和播放器的内容解码器和播放器。文件接收器可以包括FLUTE接收器和FEC解码器，以实现文件传递协议，诸如FLUTE协议。以该方式，客户端设备UM可以被配置为使用经由FLUTE协议的广播或多播来检索多媒体内容MCNT的数据。为了将FLUTE用作文件传递服务，服务器BMS可以在文件传递表(FDT)中插入向客户端设备UM指示针对媒体内容MCNT的一个或多个单播统一资源定位符(URL)的属性。文件接收器FREC可以通过广播、多播或单播接收从服务器设备MBMS(或另一服务器设备)发送的数据。特别地，文件接收器FREC可以接收FLUTE分组并将表示中所接收的段的数据提供给应用程序APP。应用程序APP进而可以将DASH段提供给DASH客户端模块DSHC，该DASH客户端模块DSHC通过DASH服务器模块与MBMS客户端模块MBMC进行通信。模块MBMS实现规范3GPP TS26.346中定义的功能。

应用程序APP可以包括由客户端设备UM的基于硬件的处理单元执行的web浏览器，或者对这种web浏览器的插件。对应用程序APP的引用通常应该被理解为包括web应用程序(诸如web浏览器)、独立视频播放器，或者合并有对web浏览器的播放插件的web浏览器。在视频内容的情况下，应用程序APP可以检索客户端设备UM内的配置数据，以确定音频和视频解码器的解码能力以及音频和视频播放器的呈现能力。

应用程序APP可以被配置为请求和接收由服务器BMS发送的广播或多播数据。例如，应用程序APP可以被配置为最初针对清单文件检索数据，该清单文件可以包括用于加入多播组(诸如多播组IP地址)或用于接收广播(例如，用于加入广播域或VLAN的数据)的数据。

有时，客户端设备UM的用户可以使用客户端设备UM的用户界面(诸如键盘、鼠标、触控笔、触摸屏界面、按钮或其它界面)与应用程序APP交互，以请求多媒体内容，诸如多媒体内容MCNT。响应于来自用户的这种请求，应用程序APP可以基于例如客户端设备UM的解码和呈现能力来选择表示中的一个表示。为了检索所选择的表示中的一个表示的数据，应用程序APP可以顺序地请求表示中所选择的表示的特定字节范围。以该方式，应用程序APP可以通过多个请求顺序地接收文件的部分，而不是通过一个请求接收完整文件。

图3示出了在移动终端中实现的用于访问单播或广播内容的软件层。这些软件层对应于OSI(开放系统互连)模型中指定的网络层。这些软件层包括应用层APPS，该应用层APPS包括安装在移动终端中的所有应用程序，这些应用程序使用服务和内容接收层。服务和内容接收层具有两种不同类型，以专门以单播模式UC接收内容，或者以实现单播和多播/广播模式UC/BC的MBMS模式接收内容。服务和内容接收层进一步包括在图3中不明显的与安全性相关的元素。

从应用层APPS下的最高级别开始，与单播模式UC相关的软件层并行地包括提供与由内容服务提供的内容相关的元数据的通告服务SANU，相关联的传递过程ADPU，其特别包括用于处理器传输错误的文件修复服务FREP，以及提供与数据接收有关的统计数据的接收报告服务RAPR。例如，可以将这些统计数据发送到服务器BMS。由层SANU和ADPU提供的数据由实现协议HTTP(超文本传输协议)的HTTP层UHT发送。由层UHT发送的数据由实现协议TCP(传输控制协议)的传输层UTCP封装和发送。由层UTCP发送的数据由实现协议IP(因特网协议)的网络层IPUC插入分组中。最后，与无线传输信道的实现对应的点对点链路层PTPB发送由层IPUC产生的分组IP。

从应用层APPS下的最高级别开始，与MBMS(UC/BC)模式相关的软件层并行地包括用于通告可用数据流(特别是多播或广播数据流)的通告服务SANN、用于下载具有不同格式的文件的文件下载服务DWL、相关联的传递过程ADP，以及内容流传输服务STCD。服务STCD包括编解码器(音频、视频、语音、文本等)，以及实现协议DASH的数据流传输接收服务DSHC。服务ADP特别包括文件修复服务FMRP，用于处理广播模式中的传输错误。在层STCD之下，存在用于格式化传输流的格式化服务RTPF，其特别包括安全和非安全的实时传输服务SRTP、RTP和实时传输控制服务RTCP。提供位于格式化服务RTPF之下的文件修复服务FEC以处理传输错误。实现协议HTTP的层HTPC位于层DSHC之下。实现协议FLUTE的层FLT位于层DSHC、DWL、FMRP和SANN之下。层FLT包括用于处理传输错误的纠错服务FFEC。实现协议UDP(用户数据报协议)的层MUDP位于层RTPF(FEC)和FLT之下。实现协议TCP的层MTC位于层HTPC之下。在单播和多播模式中实现协议IP的网络层IPMU位于层MUDP和MTC之下。最后，单播和多播链路层MTB发送在IPMU层生成的IP分组。

图4和图5示出了用户设备的功能不同架构。在图4中，可以使用模块MBMC的应用程序接口MAPI编写应用程序APP1以使用MBMS服务。可以编写另一个应用程序APP2以支持寻址“文件”资源的URL，并且使用通用操作系统URL解析模块URLD在遇到所识别的资源时返回该所识别的资源。“文件”资源可以是服务的入口点，并且可能存在如在使用http方案访问网站时传统完成的那样为服务定义的默认文件的情况。URL模块URLD从URL方案名称(例如“http：”或“mbms：”)识别特定协议处理机，并为mbms方案调用适当的协议特定处理机MUH，或为http方案调用HUH。处理机MUH、HUH的接口也可以由用户设备UM的操作系统确定。HTTP处理机HUH将URL发送到操作系统的HTTP模块HF。MBMS处理机MUH分离(pick apart)URL表单，并使用现有的MBMS接口MAPI，启动MBMS服务的获取，该MBMS服务允许访问所识别的资源，以及从该会话获取所指示的“文件”资源，并返回该资源。

MBMS URL方案允许内容提供商在不知道将使用的传递方法的细节以及内容传递的精确调度的情况下，构建并向客户端设备发送其内容的MBMS URL。

图5与图4的不同之处在于，由MBMS处理机MUH执行的功能是集成到模块MBMC中的功能IMH，该模块MBMC直接调用IMH的内部功能而不使用编程接口MAPI。

根据实施例，可以由应用程序APP1、APP2发送的URL包括：使应用程序能够指定用于接收所请求内容的调度数据的命令、用户装备配置和位置数据、用于指定要接收的特定内容部分或版本的内容部分数据或版本数据，以及内容传递的请求状态。URL语法与用于http URL的规范RFC3986以及用于mbms URL的RFC 7230和3GPP TS 26.347第8.2节一致。mbms URL可以定义如下：

mbms：//<权限>/<路径><参数>&<标签>＝<值>

其中：

<权限>/<路径>是服务标识符URI(统一资源标识符)，

？<参数>是可选的，其指定由“&”分隔的一个或多个属性-值对；属性可以在一组预定义命令中选择。

&<标签>＝<值>是可选的，其指定由所请求的服务传递的特定内容的资源标识符(例如，用于由下载服务传递的单个文件的文件URI，用于DASH内容的MPD标识符，用于HLS内容的.m3u8文件标识符，或用于RSS或Atom提要(feed)的提要URL)。如果URL中不存在后缀“&＜标签＝<值>”，则前缀mbms：//<权限>/<路径>提供所请求内容的资源标识符，并且服务标识符未知。在这种情况下，给定MBMS URL的DNS(域名系统)解析可以提供传递所请求内容的服务的标识符。

可以在下表1中定义命令集：

表1

表1还指示针对什么内容类型来设计命令(单个文件下载、DASH VOD内容、HLS VOD内容、RSS提要、Atom提要)。

命令“Start”或“Open”在该命令之后的日期开始下载或打开服务。如果未指定日期，则会立即开始下载文件或打开服务。如果URL中不存在命令，则该命令是默认命令。

命令“MaxWaitingPeriod”或“SetMaxDuration”之后是持续时间(例如以秒为单位)。该命令指定在其期间用户设备UM可以等待传递所请求内容的时间量。如果省略持续时间，则持续时间默认值可以为空值(null)或无穷大。如果默认持续时间为空值，则应立即执行操作。如果没有可用的服务或文件，则向用户设备UM发送4xx错误(诸如404-没有可用服务)。如果默认值为无穷大，则模块MBMS将定期重试。在实施方式中，可以将默认值设定为用户设备根据电池寿命可以支持的值。例如，可以在为用户设备的操作系统定义的一组参数中定义默认值。根据用户设备预期将在2小时的延迟中消费播客内容的示例，用户设备可以将“MaxWaitingPeriod”值固定为2小时，以使得如果播客内容在该给定延迟内广播，则内容将由设备本地高速缓存。

命令“UECapabilities”指定用户设备UM支持的媒体编解码器，以及用户设备UM的显示器的大小和分辨率。例如，对于与4K视频兼容的用户设备，该命令对于在若干表示中可用的DASH/HLS VOD或直播流内容是有用的。在该示例中，UECapabilities可以被设定为等于“4K”或“HD”。

命令“Languages”指定用户设备对所请求的服务内容所期望的语言(语音和字幕)。该命令对于以多种语言提供的DASH VOD服务内容是有用的。用户设备能力和语言在传递DASH VOD项时与RSS/Atom提要相关。该命令可以被设定为等于具有涉及国家或语言的两个字母的一个代码，诸如“EN”、“ES”、“DE”、“FR”或一列这种代码。

命令“Location”表示用户设备的当前位置。该命令之后是蜂窝网络中的用户设备的地理坐标或小区编号。

特定于Atom和RSS提要的命令“PublicationStartDate”之后是日期。该命令指示用户设备等待在该日期之后发布的RSS或Atom提要的传递。

当没有请求内容的开始部分时(例如，因为内容的第一部分已经被高速缓存或查看)，命令“From”指定内容的请求部分的开始。该命令之后是指定所述请求内容的开始的百分比，默认值为0％。

当没有请求内容的结尾部分时(例如，仅高速缓存内容的开始)，命令“to”指定内容的所请求部分的结束。该命令之后是指定所述请求内容结尾的百分比，默认值为100％。命令“From”和“To”特定于文件下载和DASH以及HLS VOD服务，并且可以在同一URL中同时使用以指定仅请求内容的中间部分。

命令“Stop”或“Discard”停止当前内容接收并清除高速缓存。该命令之后没有参数。

命令“GetStatus”请求指定内容的当前传输状态。不同的值可以是：“已停止”、“102：正处理/处理中”、“404：未知服务”、“201：下载”(如果是文件)、“200：OK/完成”(如果是DASH或HLS VOD、RTP，和RSS或Atom)。

命令“SetDownloadBackground”要求模块MBMC在后台接收请求的内容并将其存储在高速缓存中。

命令“GetNotified”向模块MBMC指示当所请求的服务在广播模式中可用时，应用程序APP请求被通知。该命令之后没有任何参数。仅当所请求的服务在广播模式中可用时才发送对该命令的响应。

命令“LatestVersion”用于向模块MBMC通知仅请求所述请求内容的最新版本。该命令应与“Start”或“Open”命令和“MaxWaitingPeriod”命令结合使用。在这种情况下，请求模块MBMC跟踪从开始时间发送并且在最大持续时间结束之前发送的所请求文件的最新版本。

例如，通过以下URL：

mbms://www.operator.com/service1000？start＝1477339200

&GetNotified＝yes&label＝http://www.example.com/videos/sample.mp d

应用程序APP请求具有由服务mbms：//www.operator.com/service1000所传递的MPD URI http://www.example.com/videos/sample.mpd的DASH内容，该内容从时间“1477339200”请求，以及在对应内容可用时请求通知。

通过以下URL：

mbms://www.operator.com/service1001&DownloadBackground＝yes

&label＝http://www.manufacturer.com/firmware/version10.bin

应用程序APP指定请求由MBMS服务“www.operator.com/service1001”传递的文件“http://www.manufacturer.com/firmware/version10.bin”，并且该文件必须在后台下载。

对上述命令的响应消息可以使用针对HTTP指定的代码数字，如下：

1xx，用于信息回复，

2xx，在请求的操作成功时使用，

3xx，指示内容已被重定向到另一个位置，

4xx，从模块MBMC引入错误消息，以及

5xx，已从模块MBMC引入错误消息。例如，当模块MBMC中的本地高速缓存或本地HTTP服务器功能不满足有效请求时，将这种错误消息发送到应用程序APP。所有这些消息由模块MBMC发送到应用程序APP。

例如：

当针对处理的请求被接受时发出“202已接受”，但是当前没有完成请求的处理。

当例如所请求的文件永远不会被服务器BMS发送时，模块MBMC发出“308”，以指定永久重定向到文件(如RFC 7538中所指定的)。

在当前无法找到所请求的资源时会发出“404”，但将来该资源可能会被找到。

当模块MBMC不能或不会处理请求时发出“400错误请求”，因为它由于语法错误而无法被理解。

当模块MBMC当前不可用(例如超载或停机以进行维护)时发出“503服务不可用”。该消息通常信令发送临时状态。

图6示出了根据一个实施例的步骤S21至S43，其可以被执行以使用户终端UM能够访问提供媒体内容的服务或文件下载服务。目标服务可以访问实时或延迟时间发送的数据流，诸如要下载的文件或可通过流传输或者通过DASH或HLS服务访问的内容(多媒体、音频、视频)。内容可以是文件或一组文件。内容也可以是RSS提要(例如RSS 2.0)或Atom提要。在步骤S21中，应用程序APP发送访问请求以查询提供特定内容的服务SVC。该请求包含识别所请求服务的URL U1，以及一个或多个命令，诸如先前定义的命令。根据示例，URL U1包括方案“mbms”并且可能包括与持续时间相关联的命令“MaxWaitingPeriod”或“SetMaxDuration”，以及其它命令，诸如指定用户设备UM的能力(“UECapabilities”)、用户设备的位置(“Location”)和用户请求的优选语言(“Languages”)的那些命令。URL U1指示应用程序APP请求服务SVC并准备等待与命令“MaxWaitingPeriod”相关联的持续时间以通过广播传递对应的内容。URL U1由模块URLD处理，该模块URLD从URL方案名称识别可以处理URL的特定协议处理机MUH、HUH。由于包括方案“mbms”，模块URLD将URL U1发送到处理机MUH，该处理机MUH调用与URL U1的内容对应的模块MBMC的条目功能(API)。这样，模块MBMC被请求确定所述请求内容是否已经在高速缓存中，并且存储应用程序APP可以等待接收所述请求内容的持续时间。如果所述请求内容已经在高速缓存中(如果适当的话，同时考虑命令“UECapabilities”和“Languages”)，则执行步骤S42和S43，否则执行步骤S22。当先前发送的服务的URL U1包含命令“DownloadBackground”时，所述请求内容可能已经在高速缓存中。

在步骤S22中，模块MBMC将针对包括URL U1的元数据MTD的请求发送到服务器BMS。在步骤S23中，服务器BMS的通告功能SANF接收该请求，并在从广播模式中排除的服务的服务列表中以及在包括当前广播内容的服务元数据或可以在以后由服务器BMS广播的内容的数据库MB中查找服务SVC的服务标识符。如果URL U1中不存在后缀“&<标签＝<值>”，则功能SANF使用DNS解析功能来确定服务标识符(服务URI)，该服务标识符可以传递由URL U1的前缀mbms：//<权限>/<路径>识别的内容。当服务器BMS查询数据库MB时，可以考虑与命令“MaxWaitingPeriod”相关联的持续时间和与命令“Location”相关联的位置。可以激活提供相同内容的若干服务以支持具有用于访问内容的不同特征的用户移动设备，每个服务以适于一种给定类型的用户设备的能力的方式提供内容。因此，当考虑终端UM的能力和URL U1中给出的优选语言数据时，服务器BMS可以在步骤S23中检查所请求的服务SVC是否可用于终端UM。

如果所请求的服务SVC从广播模式中排除，或者如果根据由命令“UECapabilities”指定的终端的能力它不可用，或者如果在由命令“MaxWaitingPeriod”指定的时隙期间和/或在由命令“Location”指定的网络MNT的区域中不可用，则可以执行步骤S24。如果没有从广播模式中排除与服务标识符SVC对应的服务，则执行步骤S25至S26或S38。在步骤S24中，将错误消息ERR发送到由用户设备UM执行的应用程序APP。

如果与服务标识符SVC对应的服务可以被广播，但是未在数据库MB中引用，则执行步骤S25至S26，否则执行步骤S38。在步骤S25中，服务器BMS(例如，服务器BMS的通告功能SANF)在用户终端UM请求的数据库MB中存储服务SVC。在步骤S26中，服务器BMS向用户终端UM发送响应消息RetL，该响应消息RetL信令发送所请求的服务SVC此时在广播模式中不可用，但是可以在稍后，例如当足够数量的用户设备请求相同的服务SVC时可用。消息RetL可以包括终端UM在它可以重新发出步骤S21的服务请求之前等待的时间长度。消息RetL可以首先由用户终端UM的模块MBMC接收，并发送到应用程序APP。然后，终端UM的用户可以决定在广播模式中等待服务SVC的可用性，或者决定在单播模式中请求服务SVC。应用程序APP还可以发送请求在服务SVC将可用时被通知的新URL(命令“GetNotified”)。

当执行步骤S21至S26时，服务器BMS对从用户设备接收的服务请求(步骤S22)进行计数(步骤S25)并执行步骤S29至S38。具体地，功能SANF考虑到本地化数据(在接收数据MURI中)来对请求访问相同服务的用户终端的数量计数。在步骤S29中，服务器BMC确定是否有足够数量的用户终端请求给定服务以证明(justify)广播与服务相对应的内容。为此，服务器BMS的功能SANF将所计数的终端数量与阈值进行比较。在步骤S30中，只要网络MNT的区域中请求相同服务的用户终端UM的数量不超过阈值，则再次执行步骤S29，否则执行步骤S31至S38。

在步骤S31中，服务器BMS的功能SANF发送针对与将被广播的服务SVC相关的元数据MTD的请求。在步骤S32中，元数据请求通过服务器BMS的功能STF发送到提供服务SVC的内容CNTS。在步骤S32中，当服务是VOD流传输时，服务器BMS还可以请求服务SVC的初始化段。在步骤S33中，内容服务器CNTS接收元数据请求，并向服务器BMS发送包含针对服务SVC所请求的元数据MTD(SVC)的响应消息。在步骤S34中，服务器BMS的功能STF接收元数据并从接收的元数据MTD生成统一的元数据UMTD。为此目的，服务器BMS调度一个或多个时隙，在该时隙期间将广播内容。通过向接收到的元数据MTD添加可以接收广播服务的URL地址以及与将要广播对应内容时的时隙相关的信息，从接收到的元数据MTD得到统一的元数据UMTD。统一的元数据UMTD存储在数据库MB中。服务器可以从所接收的元数据MTD检查由服务提供的内容的大小。在步骤S35中，统一的元数据UMTD被发送到服务器BMS的功能SANF。如果所请求的服务SVC是文件下载服务，则服务器BMS本身可以生成服务的元数据。

在步骤S36中，功能SANF通过在其中存储所接收的统一的元数据UMTD和所接收的初始化段来更新数据库MB，该数据库MB包含用于访问可以被广播的服务的元数据。当执行步骤S36时，功能STF向内容服务器CNTS发送针对由服务SVC提供的内容的内容请求CNT(步骤S39)。在步骤S40中，服务器CNTS将所请求内容CNT(SVC)发送到服务器BMS。服务器BMS本地存储内容CNT，以使其对于位于移动网络MNT中的服务器BMS的服务区中的用户终端UM是可用的。

在与步骤S22相同的步骤S37中，模块MBMC再次请求服务SVC的元数据MTD。该步骤可以在S26之后，在消息RetL中指定的等待时间之后，或者当模块MBMC接收对先前发送的包含命令“GetNotified”的URL的响应时执行。在步骤S37之后的步骤S38中，统一的元数据UMTD在由功能SANF管理的数据库MB中可用，并且响应于在步骤S37(或S22)中发送的请求，从服务器BMS发送到用户终端UM的模块MBMC。因此，在步骤S41中，一旦广播的服务SVC将在该模式中可用，终端UM就可以使用特别包括URL的元数据MTD来访问广播的服务SVC。在步骤S42中，内容CNT(SVC)存储在终端UM的高速缓冲存储器LC中。在步骤S43中，模块MBMC通知由用户终端UM执行的应用程序APP内容CNT(SVC)当前被广播并且可供应用程序APP使用。

文件下载服务可能涉及可能不时更新的几个文件。在该上下文中，应用程序APP在步骤S21中发送的请求可以涉及这些文件中的一个文件的一次出现(例如，最后一次出现)，或者所有这些文件的一次出现(例如，最后一次出现)，或者一个或所有文件的所有出现。

可以观察到，可以在消息RetL中指定的预定时隙之前广播服务SVC(在步骤S26中发送)。在后一种情况下，如果终端UM已经在单播中接收到由服务SVC提供的内容，则它可以以用户看来无缝的经典方式切换到广播内容。在元数据MTD中通告由服务SVC提供的内容何时被广播时，应用程序APP还可以触发自己访问广播的内容。

本公开和说明应被视为说明性的而非限制性的，并且所附权利要求旨在覆盖落入本说明书的真实精神和范围内的所有这种修改、增强和其它实施例，或其组合。因此，所附权利要求的范围将由权利要求及其等同物的最宽泛的可允许解释来确定，并且不应受前述描述的约束或限制。

特别地，本公开不限于上述命令列表。其它命令可以容易地想象，同时保持在所附权利要求的范围内。可能的命令可以被分类为诸如指定调度或时间条件的那些类别，指定与用户终端能力相关的技术条件的那些类别，指定由用户定义的条件的那些类别(诸如“语言”)，以及请求与URL的<权限>和<路径>字段指定的服务的传递相关的进一步信息的那些类别。

Claims

1.一种用于从用户终端访问传递内容的服务的方法，所述方法包括：

向所述用户终端的客户端模块(MBMC)发送来自内容播放应用程序的统一资源定位符URL，所述URL包括第一字段，所述第一字段包括标识请求内容(CNT)的标识符，

其中，所述URL还包括与所述第一字段不同的第二字段，所述第二字段包括与向所述用户终端传递所述请求内容相关的至少一个命令，所述命令由所述用户终端在包括多个命令的预定命令集中选择，所述多个命令包括指定与所述用户终端对所述请求内容的访问相关的调度或时间条件的命令，所述方法还包括：

如果根据所指定的命令所述请求内容在所述用户终端中可用，则从所述客户端模块向所述内容播放应用程序发送所述请求内容(CNT)，以及

在所述命令指定与对所述请求内容的访问相关的调度或时间条件的情况下，如果根据所述命令所述请求内容在所述用户终端中不可用，则向服务广播服务器发送来自所述客户端模块的所述URL，以及

在根据所述命令所述请求内容对于所述广播服务器可用的情况下，由所述用户终端接收所述请求内容，

在根据所述至少一个命令所述请求内容将在以后对于所述广播服务器可用的情况下，由所述用户终端接收指示所述请求内容何时可用的消息，以及

在根据所述命令所述请求内容对于所述广播服务器永远不可用的情况下，由所述用户终端接收指示所述内容将不被广播的消息。

2.根据权利要求1所述的方法，进一步包括：由所述用户终端的所述内容播放应用程序生成所述URL。

3.根据权利要求1所述的方法，其中，所述URL包括第三字段，所述第三字段包括指定多媒体广播或多播服务或超文本传输协议HTTP服务作为服务类型的方案，所述方法进一步包括向特定于所述方案的所述用户终端的URL处理机发送所述URL。

4.根据权利要求1所述的方法，其中，所述命令指定与用户终端能力相关的技术条件，和/或与所述请求内容相关的用户所定义的用户条件。

5.根据权利要求1所述的方法，其中，所述命令是针对所述请求内容传递的当前状态的请求。

6.根据权利要求1至5中任一项所述的方法，其中，所述命令集包括：

指定请求所述请求内容(CNT)的开始时间的命令，如果没有指定时间，则所述开始时间是当前时间，

指定请求所述内容的时间段的命令，

指定媒体编解码器和所述用户终端的显示大小的命令，

指定所述用户终端的位置的命令，

指定用于所述请求内容的优选语言的命令，

指定从其开始请求所述请求内容的内容发布日期的命令，

用于停止或取消对所述请求内容的访问的命令，

用于请求所述请求内容的传递状态的命令，

用于请求所述请求内容在一个时段内可用的最新版本的命令，所述时段从由指定开始时间的命令指定的时间开始，并且具有由指定内容在其期间被请求的时段的命令定义的持续时间。

7.根据权利要求1至5中任一项所述的方法，其中，所述URL还包括以下命令中的至少一个：

指定所述请求内容的请求部分的开始和结束的命令，以及

用于指定所述用户终端必须在后台接收请求服务内容的命令。

8.根据权利要求1至5中任一项所述的方法，进一步包括：由所述客户端模块从所述服务广播服务器(BMS)接收所述请求内容(CNT)将在指定日期被广播的通知(RetL)。

9.根据权利要求1至5中任一项所述的方法，进一步包括：

由所述服务广播服务器(BMS)对在网络区域中请求内容(CNT)的终端的数量进行计数，以及

当请求所述内容的用户终端的数量超过阈值时，调度所述请求内容的广播。

10.根据权利要求9所述的方法，进一步包括：向请求所述内容的所述用户终端通知与所述请求内容(CNT)的广播相关的调度数据。

11.根据权利要求10所述的方法，其中，所述URL包括：传递所述请求内容的服务的服务标识符和内容标识符，或者所述URL仅包括所述内容标识符，当所述URL不包括所述服务标识符时，所述方法进一步包括域名系统解析。

12.一种被配置为访问传递内容的服务的终端，所述终端包括：

至少一个处理器；以及

至少一个存储器，所述存储器存储程序代码，当所述程序代码由所述至少一个处理器执行时使得所述终端执行根据权利要求1至11中任一项所述的方法。

13.一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序包括代码部分，所述代码部分当由一个或多个计算机执行时，配置所述一个或多个计算机执行根据权利要求1至11中任一项所述的方法。