专利名称：用于对包括多个组成的通知消息进行传输的方法和装置的制作方法
技术领域：
本发明一般地涉及广播和多播系统领域。更具体地，本发明涉及在广播和多播系统内的通知的消息传送和功能。
背景技术：
本部分旨在对权利要求中记载的本发明提供背景或上下文。此处的描述可以包括能够被探究的概念，但未必是那些之前已经想到或者探究的概念。因此，除非在此明确指出外，本部分提及的内容对于本申请的说明书和权利要求书而言不是现有技术，并且并不因为包括在本部分中就承认其为现有技术。
近年来，移动多播和广播系统已被不同的组织标准化，这些组织
诸如是第三代伙伴合作计划(3GPP )多媒体广播/多播服务(MBMS )组织、数字视频广播(DVB)广播与移动服务技术模块整合(TM-CBMS)组织、以及开放移动联盟(OMA)移动广播服务(BCAST)组织。其他多播和广播系统还包括综合服务数字广播-陆地(ISDB-T)、数字多媒体广播-陆地/手持(DMB-T/H)、数字多媒体广播(T-DMB)、仅前向链路(FLO)和专有系统，诸如MediaFLO。此类多播/广播解决方案提供的两个主要服务是流式传输和文件递送服务。尽管流式传输服务被认为是该技术(例如，移动TV应用)的主要驱动力，但也期望文件递送生成大量的业务并带来显著收益。例如，在音乐和视频剪辑的递送中，文件递送可以构成主要的应用组成部分。备选地，在例如富媒体应用和频道切换(zapping)流的情况下，文件递送可能是应用的次要组成部分。
在文件递送的情况下，可以使用单向传送文件递送(FLUTE)作为文件递送协议。FLUTE由互联网工程任务组(IETF)定义，并且
8基于异步分层编码(ALC)协议实例化。ALC包括一组构建块，诸如分层编码传输(LCT)块以及前向纠错(FEC)构建块。除其他之外，FLUTE通过定义用来描述FLUTE会话内容的机制来扩展ALC。这是通过引入传输对象标识符(TOI)等于0的公知对象来实现的，从而携带文件递送表(FDT)实例。FDT实例列出了一组文件及其相应的传输选项。FDT是遵循在FLUTE规范中所定义模式(schema )的XML文件。
将多播和广播服务的另一组成称作通知服务。通知服务通过提供支持服务相关信息的交互和递送的方式来补充移动TV服务，而同时还支持新的服务和/或关键服务，诸如紧急情况通知。海啸通知服务是紧急情况通知的示例。
当前，DVBTM-CBMS目前正在下一因特网协议数据广播系统(IPDC) IPDC2.0范围内定义通知框架，其寻求对实现多种已经定义用例的支持。在"IP Datacast over DVB-H: Notification (LivingDocument)" TM-CBMS 1520r8中描述了这些用例，在此通过引用将其全部结合于此。应该注意，可以根据如下标准来对通知用例进行分类通知是具有强时间约束还是具有松散时间约束，例如，在给定时间内应当接收的通知和/或可以以各种定时需求来处理的通知；通知是引导至终端还是引导至用户，例如，通知目标在于终端或者驻留于其上的应用，或者通知目标在于用户，其中在处理通知中终端的涉入超过向用户呈现通知的需求；其中通知是服务相关的或者服务不可知的，通知分别依赖于服务或者独立于服务；以及通知是否需要交互性，例如，其主要目的在于引导终端与网络或者应用进行后续交互的通知。
如果通知消息例如包括音频/视频和/或其他内容，则其可能具有较大的大小。由此，当通知消息体积较大时，文件递送协议可以更适用递送通知消息。此外，除可能需要一定量的交互性以外，通知消息还可以涉及服务，并且具有强同步需求。此类通知服务的一个示例是投票服务，该投票服务紧密地与服务(诸如TV广播)同步。需要观看者在特定的时间段内投票，而该时间段可以短至数秒。由此，音频
9/视频流通常必须准确地同步于通知服务。任何不准确的同步均可导致混乱并且误导观看者，尤其是如果交互动作是基于通知消息来触发的
时候。由此，实时传输协议(RTP)可以更好地适合于递送需要更严格同步的通知消息。当前，尚未定义用于传输这样的通知消息的方法，即，该消息既大又鉴于其内容而必须使用RTP。
OMA BCAST定义了 一种通知功能，其支持对电子服务指南(ESG)和通过FLUTE、短消息传送服务(SMS )或者OMA-PUSH进行的通知数据递送中的通知服务的描述。交互性文档可用于描述所需交互的类型，并且可以作为通知消息的部分来递送。然而，同步机制并不足够准确，这是由于其依赖于网络时间协议(NTP)的时间戳。换言之，NTP时间戳可用于将通知消息同步于相关的、实际服务的媒体流。RTP时间戳到"壁钟(wallclock)，，时间的映射在终端处执行，以便同步实际服务的音频/视频流。然而，所指示的NTP时间戳表示音频/视频流生成器处的时间，而并不反应终端处的时间。此外，音频/视频流的播出通常受到延迟，这是由于消除抖动緩存需要时间。由此，依赖于通知消息中承载的时间戳可以导致太早显示通知消息。还可能的是，媒体流生成器以及通知消息生成器的时钟是不同的。由此，NTP时间戳不能保证准确的时间同步。
应该注意，通知实体不同于流生成实体。另外，没有考虑在屏幕上示出相应内容之前为了快速触发交互动作音频/视频流可能需要的任何緩沖时间。
此外，已经提出了通过使用RTP扩展报头来向音频/视频流添加同步信息，同时还将通知消息划分成三个单独部分。所提议的三个单独部分包括插入至实际服务的音频/视频流的RTP扩展报头的同步标记，其中该同步标记可以承载交互对象标识符；用于将交互对象与同步标记相关联的交互描述符，同时还包括诸如时序信息的其他信息；以及可以承载通知消息的内容或者描述的交互对象。然而，为了插入或者提取任何所需的报头，这需要对音频/视频流进行修改。另外，为了提取扩展报头，需要在接收机处解译RTP流。还不清楚，针对
10RTCP统计可以导致何种长期影响，因为RTP流被改变而并没有修改同步源(SSRC)。通常，旨在由媒体流接收机使用扩展报头，但该扩展报头并不意味着包括涉及完全不同实例的信息。
发明内容
各种实施方式提供了对去往用户的通知消息进行的划分，其中通知消息支持与媒体广播服务相关联的信息递送和交互性中的至少一个。通知消息的第一组成承载媒体内容，并且利用文件递送协议(诸如，FLUTE、 HTTP和OMA-PUSH)来传输。通知消息的第二组成承载与消息的递送和交互性相关联的任何同步信息，该信息与媒体广播服务相关联。通知消息的第二组成可以经由RTP来在RTP净荷中传送，以便允许将通知消息与包括媒体内容的媒体广播服务的媒体流进行精确同步。
由此，各种实施方式允许有效传输通知消息，该通知消息具有与相关媒体广播服务相关联的同步需求。然而，不必利用RTP来承载通知消息的任何较大组成，RTP对于较大消息的传输可能效率较低。取而代之，可以利用文件递送协议，诸如FLUTE、 HTTP和OMA画PUSH。
当结合附图阅读下文详细描述时，本发明的这些以及其他优点和特征以及本发明的组织和操作方式将变得易见，其中贯穿下文描述的多个附图，类似的元件具有类似的标号。
图1是其中可以实现本发明的各种实施方式的广播和多播服务系统的概括视图3是图2的移动终端的终端电路的示意性表示；
图4是根据本发明的各种实施方式而出现的通知动作的示意性表示；
图5是根据本发明的一个实施方式的引用可用内容的通知消息的 示意性表示；以及
图6示^了用千A棍棍太劳即式。
具体实施例方式
图1示出了系统10，该系统IO示出了用于包括通知功能的多播 和广播服务的系统的一个示例性架构。系统IO可以划分为内容提供 者、服务提供者和网络运营商逻辑域。可以包括收集元件11的内容 提供者域可表示拥有和/或被许可销售内容和/或内容资产的系统10 的部分。在某些实施方式中，内容提供者还可以是内容创建者。内容 提供者域的一个目的在于，允许由服务提供者域中的服务提供者对内 容进行获取。应当注意，收集元件11可以表示能够捕获期望内容的 任何元件和/或应用。
可以利用服务提供者域来向订户(诸如移动终端12的所有者) 提供实际服务。应当注意，服务提供者域可以包含不同的服务提供者 和/或不同类型的服务提供者，例如传统的因特网服务提供者和内容服 务提供者。例如，在IP电视的环境中，内容服务提供者可以从一个 或者多个内容提供者获取和/或许可内容，并且将所述内容封装至服 务。由此，服务提供者域还可以包括用于对内容进行编码的音频/视频 编码器14。另外，服务提供者域可以包括至少某些通知服务元件，包 括通知提供器16、通知网关20以及应用服务器18,服务提供者可以 通过应用服务器18来向移动终端12提供实际服务。
网络运营商域可以包括FLUTE文件服务器24，其转而可以直接 从通知提供器16接收通知消息，并且IP封装器(IPE) 22可以封装 通过通知网关20传输的通知消息。另外，IPE22还可以用于在IP分 组中封装由FLUTE文件服务器24接收的通知消息。无论通知消息是 否经由应用服务器18来传输，连接到移动终端12的FLUTE文件服
12务器24和/或IPE 22可以通过各种类型的传输元件和/或协议来实现， 包括但不限于数字视频广播-手持/陆地(DVB-H/T)传输以及蜂窝3G 传输。
另外，移动终端12可以表示客户域，其中可以使用诸如MBMS 服务和/或内容的广播以及多播服务。应该注意，尽管示出了单一移动 终端12,但是可以针对服务消费来使用利用各种通信协议的多个设 备，其中多个设备可以以各种方式联网和相关。例如， 一个或者多个
移动设备可以使用各种传输技术来通信，这些传输技术包括但不限于 码分多址(CDMA)、全球移动通信系统(GSM)、通用移动通信系 统(UMTS )、时分多址(TDMA )、频分多址(FDMA )、传输控 制协议/互联网协议(TCP/IP)、短消息传送服务(SMS)、多媒体消 息传送服务(MMS)、电子邮件、即时消息传送服务(IMS)、蓝牙、 IEEE 802.il等。移动设备可以使用各种介质进行通信，这些介质包 括但不限于无线电、红外、激光、线缆连接等。
图2和图3示出了可以与各种实施方式相结合使用的一个代表性 移动电话12。然而，应当理解，本发明不旨在限于特定类型的电子 设备。图2和图3的移动电话12包括外壳30、液晶显示器形式的显 示器32、小4建盘34、麦克风36、耳机38、电池40、红外端口42、 天线44、根据本发明一个实施方式的UICC形式的智能卡46、读卡 器48、无线电接口电路52、编解码器电路54、控制器56以及存储器 58。个体电^各和元件可以是本领域公知的所有类型，例如Nokia系列 的移动电话。
各种实施方式支持将来自通知提供器16的通知消息划分为两个 组成。第一组成可以称为通知对象，其例如可以承载通知消息的内容 和/或通知消息的内容描述。另外，第一组成的大小可以较大，并且可 以使用文件递送方法(包括但不限于FLUTE、OMA-PUSH或者HTTP ) 来以广播模式递送至移动终端12的用户。通知消息的该第一组成可 以被预先下载，以便在对其进行利用之前在移动终端12处可用。应 当理解，第一组成/通知对象可以包括第一指针，用于指向包括通知消
13息的至少部分的其他内容。由于XML允许高度的灵活性，可以将XML 用作通知对象描述的格式。
通知消息的第二组成可以称为通知触发，其例如可以承载同步信 息、通知消息信息的类型和/或其他相关信息。第二组成/通知触发的 大小可以较小/较短，并且可以以同步方式递送至实际服务(例如，音 频/视频流)。应当注意，同步信息例如可以在流式传输会话的特定时 刻处触发交互性动作。RTP可以用作针对此第二组成的适合的传输协 议，由此允许准确地同步通知消息和实际服务的音频/—见频流。通知触 发还可以承载允许对通知消息进行过滤的信息。
此外，通知消息的第二组成可以承载指向通知消息的第 一组成的 第二指针。第二指针可以提供一种方式，以便在例如FLUTE会话中 定位通知消息的第 一组成。第二指针还可以用于指向可远程获得的内 容，例如，所述内容可以经由HTTP、文件传输协议(FTP)和/或任 何其他适合的文件下载方法通过交互信道获得。如上所述，第二组成 中的指示可以用于触发第一组成的预先下载。例如，可以在向移动终 端12用信号发送通知事件之前立刻执行。由此，可以预先预获取通 知对象以及先验通知消息的所有其他部分，以便确保在需要时通知消 息的全部组成均为可用。
图4示出了在流式传输服务的通知动作期间引用通知内容410的 已同步通知触发400的示意性表示，所述流式传输服务包括音频RTP 流、视频RTP流以及通知RTP流。图5图示了通知应用的示例，例 如可用内容存在用于下载。框500可以表示指示内容在框510处可用 于下载的内容的通知消息。通知消息可以在RTP通知流中传输，而 例如可以在ALC/FLUTE会话、HTTP会话等中找到该内容。
根据一个实施方式，可以定义设被计用于承载通知消息的RTP 净荷格式，如上所述。RTP净荷格式可承载各种类型的信息，包括但 不限于关于将被承载的通知消息的类型的信息、其他有用信息(诸如 从RTP时间戳开始的通知消息的有效性)，以及在需要时的分段和 重复信息。此外，RTP提供内部同步信息，并且允许流式传输会话的
14不同媒体组成的准确同步。RTP还提供用于序列编号的机制，并且支
持分组丢失、重复或者乱序的标识。可以将大的分组分段，并且以媒 体感知的方式重新组装，这将在丟失单一分段的情况下最小化失真。
RTP的优势比使用纯UDP传输的优势更重要。
可以封装通知消息并且作为通知流来传输。通知流可以被认为是 实际服务的会话描迷协议(SDP)内部的单独的流，由此支持通知流 与音频/^见频流同步。应当注意，SDP文件可以包括关于例如才各式、 时序、以及音频/-现频流的作者或者任何其他流式传输内容的信息。此 外，由于在单独RTP会话中承载通知触发，增加或者去除通知服务 是简单的，并且仅需要更新SDP文件。由此，实际服务的音频/视频 流可以保持不受修改。下文是SDP文件的示例，该示例声明了随同 音频W见频流的通知流。
0=_ 4 4 IN IP4 172,22.37.66
s=News Channel 15华s
i=News Ch薩i
e=user@example.com
c=INIP4 232.0,64,32
b=AS:200
t=0
m=video 38002 RTP/AVP 102 b=AS:140
a=rtpmap:102 H264/90000
a=finfp:102 profile-leveWd42E00C; packeti2atkm-mode=0; sprop-parameter-
seteHT0LgHvQKD9CAAAI)6AAAdTBeMGVA=，KM4Gcg==;
m=audio 38004 RTP/AVP 104
b=AS:65
15a,ni邵:104 MP4A-LATM/22050/2
a=feitp: 104 pro file-level誦id-l ;config=400027203FC0
,卿licatkm 38004 RTP/A VP 106
b=AS:30
a=rtpmap:106 NOTCFAOOO
a=ftntp:106 config=AJDk6589MTBeLb93
如上述示例中所示，通知流类型可以是"应用，，，并且mime类 型可以是"应用/NOTIF"。为1000的时钟速率可用于通知消息流， 其允许精确(例如，高达毫秒)的同步。另外，在Base64中编码的 配置参数可用于配置通知消息解码器，并且在通知流的fmtp线中给 出。应当注意，在此所述示例并非排他性的，并且在实现本发明的各 种实施方式时，可以使用其他变量、参数和/或值。
由此，RTP分组的净荷可以承载通知消息的第二组成。应当注意， 所述第二组成可以以文本才各式(例如，可扩展标记语言(XML))实 现或者可以是二进制形式。由此，净荷可以承载指向通知消息的第一 组成的第二指针，并且还可以承载针对时序约束以及有待执行的动作 描述的信息。尽管动作通常依赖于消息类型，然而至少可以针对通知 对象预获取、通知对象的激活以及通知对象的过期而定义特定动作类 型。
换言之，第二组成/通知触发字段可以部分地包括在RTP报头(例 如，时间戳、序列号等)、RTP净荷格式(例如，类型、动作、过滤 字段)中、以及部分地处于RTP净荷中。例如，通知触发事件的RTP 净荷格式甚至可以包括但不限于如下字段分段信息，其中如果通知 触发消息较大，则执行应用层分段；通知触发的标识符，用于当多个 通知触发消息可能具有相同时间戳时，和/或标识来自非复制消息的复 制消息时，其中可以多次发送通知触发消息以确保正确递送；通知信 息类型，用于支持通知消息过滤，例如对投票消息不感兴趣的用户可 以指导移动终端12略过承载投票请求的通知消息；通用过滤报头， 其中可以由通知服务(例如快速访问过滤数据)来定义附加过滤标准，可以使用可定制过滤报头；以及已定制过滤字段，其中过滤字段及其
值由通知服务的服务描述来指示。
图6示出了根据本发明一个实施方式的RTP净荷格式。标识字段 ID 600可以是8位字^殳，其中ID 600和时间戳的配对针对任何两个 不同通知触发消息可以是唯一的。类型字段610可以是8位字段，其 基于一个或者多个特定用例，允许定义高达256个不同类型。FRAG 字段620可以指示当前分组是否不是分段(00)、是第一分段(01 )、 是分段(IO)、或者是最后分段(ll)。报头长度字段640可以指示 从ID字段600开始的净荷格式报头的以字节为单位的长度。扩展报 头ID 650可以指示扩展报头670的类型，其中扩展报头670可以承 载特定于当前扩展报头类型的信息。长度字段LEN 660可以将当前扩 展报头的长度指示为4字节的倍数。应当注意，保留字段630保持未 定义/未占用，以便未来支持关于RTP净荷格式的需要。
现在返回图1,应该注意，通信消息的第一组成和第二组成两者 均可经由IPE 22、 FLUTE文件服务器24和/或应用服务器18来发送。 然而，如上所述，由于第一组成可以大于第二组成，通常使用广播传 输机制(诸如通过IPE 22和FLUTE文件服务器24的DVB-H/T传输) 来传输第一组成。第二组成较小，由此可以通过通信机制(例如，蜂 窝3G)、使用适当传输协议来经由应用服务器18向移动终端12传 输所述第二组成。
根据一个实施方式，通知消息的第 一组成可以通过文件的统一资 源标识符(URI)来标识，其可以包括通知消息的单一分段的全部。 根据另一实施方式，URI可以表示指向通知消息的其他分段的文件。 备选的是，通知消息可以利用分段文件URI以外的或者代替其的通知 消息的第一组成的版本来标识。另外，备选地，可以将承载通知消息 的第一组成的流式传输会话的访问类型用作标识符，其中流式传输会 话可以是FLUTE会话、HTTP会话、或者任何其他文件递送协议会 话。应该注意，当使用FLUTE协议时，可以已经在通知服务声明中 给出流式传输会话描述。换言之，承载特定通知服务的通知对象的FLUTE会话可以例如在ESG的获得分段中描述。备选地，第一组成/ 通知触发可以承载第一指针，如上所述，该指针指向FLUTE会话内 部的通知对象。另外，通知对象可以定位在远程服务器上并且在需要 时使用交互信道来获取。根据本发明的一个实施方式，HTTP可以用 作传输协议。
由此，各种实施方式允许有效传输通知消息，该通知消息要求与 相关的流式传输服务同步。另外，可以使用RTP来实现同步。然而， 通知消息的任何较大组成不必使用RTP来承载，RTP对于较大消息 的传输效率较低。而是，可以使用诸如FLUTE的文件传输协议。
可以在方法步骤或者处理的一般上下文描述在此描述的各种实 施方式，在一个实施方式中，其可以在包含在计算机可读介质中的计 算机程序产品实现，包括在联网环境中执行的计算机可执行指令，诸 如程序代码。计算机可读介质可以包括可移除和不可移除存储设备， 包括但不限于只读存储器(ROM)、随机访问存储器(RAM)、 压缩盘(CD)、数字通用盘(DVD)等。通常，程序模块包括例程、 程序、对象、组件、数据结构等，用于执行具体任务或者实现特定 的抽象数据类型。计算机可执行指令、相关数据结构和程序模块代
描述的功能的对应动作的示例。
本发明的实施方式可以以软件、硬件、应用逻辑或者软件、硬件 和应用逻辑的组合来实现。软件、应用逻辑和/或硬件可以驻留在例如 芯片集、移动设备、台式机、膝上型计算机或者服务器之上。本发明 的软件和web实现能够利用标准编程技术来完成，利用基于规则的 逻辑或者其他逻辑来实现数据库搜索步骤、相关步骤、比较步骤和
决策步骤。各种实施方式还可以全部或者部分地实现在网元或者模 块内部。还应当注意的是，此处以及下文的权利要求书中使用的词 语"组件"和"模块"意在包括使用 一行或者更多行软件代码的实现和/ 或硬件实现和/或用于接收手动输入的设备。出于示例和描述的目的，已经给出了本发明实施的前述说明。 前述说明并非是穷举性的也并非要将本发明限制到所公开的确切形 式，根据上述教导还可能存在各种变形和修改，或者是可能从本发 明的实践中得到各种变形和修改。选择和描述这些实施方式是为了 说明各种实施方式的原理和特征及其实际应用，以使得本领域的技
而利用本发明。在此所述实施方式的特征可以结合至方法、设备、模 块、系统以及计算机程序产品的全部可能组合。
权利要求
1.一种方法，包括经由第一传输机制向用户传输通知消息的第一组成；以及经由第二传输机制向所述用户传输所述通知消息的第二组成，其中所述通知消息支持涉及去往所述用户的媒体广播服务的信息的交互性和递送中的至少一个。
2. 根据权利要求1所述的方法，其中所述第一组成包括所述通知消息的内容描述和所述内容的至少 一个。
3. 根据权利要求1所述的方法，其中在通知操作中使用所述第一组成之前，将所述第一组成预先下载至用户设备。
4. 根据权利要求1所述的方法，其中所述第一传输机制包括至少 一 个文4牛递送f办i义。
5. 根据权利要求4所述的方法，其中所述文件递送协议包括以下至少一个单向传送文件递送协议、开放移动联盟-PUSH协议以及超文本传输协议。
6. 根据权利要求1所述的方法，其中所述第一组成由以下至少一个来标识文件的统一资源标识符、所述第一组成的版本以及承载所述第 一 组成的媒体广播服务会话的访问类型。
7. 根据权利要求6所述的方法，其中所述文件包括以下全部中的一个所述通知消息的第 一多个分段以及指向所述通知消息的第二多个分段的第一指针。
8. 根据权利要求1所述的方法，其中所述第二组成被同步地递送至所述媒体广播服务的媒体内容流。
9. 根据权利要求1所述的方法，其中所述第二组成承载用于以下至少 一 个的同步信息在媒体内容流式传输会话的特定时刻触发交互性动作以及递送与所述媒体广播服务相关的信息。
10. 根据权利要求1所述的方法，其中所述第二传输机制包括实时传输协议。
11. 根据权利要求IO所述的方法，其中所述实时传输协议使用所定义的净荷格式，以便承载以下至少一个通知消息类型、分段信 息、重复信息、所述第一组成的标识符、过滤信息以及其他通知消息 相关的信息。
12. 根据权利要求11所述的方法，其中所述第二组成以文本格 式和二进制格式中的一个来承载。
13. 根据权利要求1所述的方法，其中所述第二组成承栽指向所 述第一组成的第二指针。
14. 根据权利要求13所述的方法，其中所述第二指针支持以下 至少一个在单向传送文件递送会话中定位所述第一组成、以及指向 通过交互信道可远程获取的可用媒体内容。
15. 根据权利要求14所述的方法，其中实时传输协议净荷承载 以下至少一个所述第二指针、时序约束信息以及描述所述交互性的 信息。
16. 根据权利要求1所述的方法，其中包括所述通知消息的通知 流被声明为是所述媒体广播服务的会话描述协议中的单独流。
17. 根据权利要求1所述的方法，其中所述第一组成的大小大于 所述第二组成。
18. 根据权利要求1所述的方法，其中所述第二组成包括配置用 于触发到所述用户的所述第一组成的预先下载的指示符。
19. 一种包含在计算机可读介质上的计算机程序产品，包括配置 用于执行根据权利要求1所述的处理的计算机代码。
20. —种设备，包括 处理器；以及存储器单元，可操作地连接至所述处理器并且包括 用于经由第 一传输机制向用户传输通知消息的第 一组成的计算 机代码；以及用于经由第二传输机制向所述用户传输所述通知消息的第二组 成的计算机代码，其中所述通知消息支持涉及去往所述用户的媒体广播服务的信息的交互性和递送中的至少 一 个。
21. 根据权利要求20所述的设备，其中所述第一组成包括所述通知消息的内容描述和所述内容的至少 一个。
22. 根据权利要求20所述的设备，其中所述第一传输机制包括至少 一 个文件递送协i义。
23. 根据权利要求20所述的设备，其中所述第一组成由以下至少一个来标识文件的统一资源标识符、所述第一组成的版本以及承载所述第 一 组成的媒体广播服务会话的访问类型。
24. 根据权利要求23所述的设备，其中所述文件包括以下全部中的 一个所述通知消息的第 一 多个分段以及指向所述通知消息的第二多个分段的第一指针。
25. 根据权利要求20所述的设备，其中所述第二组成被同步地递送至所述媒体广播服务的媒体内容流。
26. 根据权利要求20所述的设备，其中所述第二组成承载用于以下至少 一个的同步信息在媒体内容流式传输会话的特定时刻触发交互动作以及递送与所述媒体广播服务相关的信息。
27. 根据权利要求20所述的设备，其中所述第二传输机制包括实时传输协议。
28. 根据权利要求27所述的设备，其中所述实时传输协议使用所定义的净荷格式来承载以下至少一个所述通知消息的类型、分段信息、重复信息、所述第一组成的标识符、过滤信息以及其他通知消息相关的信息。
29. 根据权利要求20所述的设备，其中所述第二组成承载指向所述第一组成的第二指针。
30. 根据权利要求29所述的设备，其中所述第二指针支持以下至少一个在单向传送文件递送会话中定位所述第一组成以及指向通过交互信道可远程获取的可用媒体内容。
31. 根据权利要求30所述的设备，其中实时传输协议净荷承载以下至少一个所述第二指针、时序约束信息以及描述所述交互性的信息。
32. 根据权利要求20所述的设备，其中所述第一组成的大小大 于所述第二组成。
33. 根据权利要求20所述的设备，其中所述第二组成包括配置 用于触发到所述用户的所述第一组成的预先下载的指示符。
34. —种系统，包括 包括收集元件的内容提供者域；服务提供者域，包括以下至少一个用于从所述收集元件接收媒 体流的媒体编码器、用于使用所述媒体流来提供至少一个媒体广播服 务的应用服务器、用于提供通知消息的第一组成和第二组成的通知提 供器以及通知网关；网络运营商域，包括至少一个文件递送元件用于从所迷应用服 务器、所述通知网关和所述通知提供者中的一个以及至少一个通信传 输机制接收所述通知消息的所述第一组成，其中所述至少一个通信传 输机制配置用于向包括用户终端的客户域来传输所述通知消息的第 一组成和第二组成。
35. 根据权利要求34所述的系统，其中所述第一组成包括所述 通知消息的内容描述和所述内容的至少 一个。
36. 根据权利要求34所述的系统，其中所述第一组成由以下至 少一个来标识文件的统一资源标识符、所述第一组成的版本以及承 载所述第 一 组成的媒体广播服务会话的访问类型。
37. 根据权利要求34所述的系统，其中所述文件包括以下全部 中的 一个所述通知消息的第 一多个分段以及指向所述通知消息的第 二多个分段的第一指针。
38. 根据权利要求34所述的系统，其中所述第二组成经由实时 传输协议来被同步地递送至所述媒体广播服务的媒体内容流。
39. 根据权利要求38所述的系统，其中所述实时传输协议使用 所定义的净荷格式，以便承载以下至少一个所述通知消息的类型、 分段信息、重复信息、所述第一组成的标识符、过滤信息以及其他通知消息相关的信息。
40. 根据权利要求34所述的系统，其中所述第二组成承载指向所述第一组成的第二指针。
41. 根据权利要求40所述的系统，其中所述第二指针支持以下至少一个在单向传送文件递送会话中定位所述第一组成以及指向通过交互信道可远程获取的可用媒体内容。
42. 根据权利要求41所述的系统，其中实时传输协议净荷承载以下至少一个所述第二指针、时序约束信息以及描述所述交互性的信息。
43. 根据权利要求34所述的系统，其中所述第一组成的大小大于所述第二组成。
44. 根据权利要求34所述的系统，其中所述第二组成包括配置用于触发到所述用户的所述第一组成的预先下载的指示符。
45. —种方法，包括向用户传输通知消息的第一组成的第一方式；以及向所述用户传输所述通知消息的第二组成的第二方式，其中所述通知消息支持涉及去往所述用户的媒体广播服务的信息的交互性和递送中的至少一个。
46. 根据权利要求45所述的方法，其中所述第一组成包括所述通知消息的内容描述和所述内容的至少 一 个。
47. 根据权利要求45所述的方法，其中所述第一方式包括使用以下至少一个的第一传输机制单向传送文件递送协议、开放移动联盟-PUSH协议以及超文本传输协议。
48. 根据权利要求45所述的方法，其中所述第二组成被同步地递送至所述媒体广播服务的媒体内容流。
49. 根据权利要求45所述的方法，其中所述第二组成承载用于以下至少 一个的同步信息在媒体内容流式传输会话的特定时刻触发交互动作以及递送与所述媒体广播服务相关的信息。
50. 根据权利要求45所述的方法，其中所述第二方式包括使用实时传输协议的第二传输机制。
51. 根据权利要求45所述的方法，其中所述第一组成的大小大 于所述第二组成。
52. 根据权利要求45所述的方法，其中所述第二组成包括配置 用于触发到所述用户的所述第一组成的预先下载的指示符。
全文摘要
各种实施方式提供了用于对去往用户的通知消息进行的划分，其中所述通知消息支持与媒体广播服务相关联的信息的交互性和递送的至少一个。通知消息的第一组成承载媒体内容，并且使用诸如FLUTE、HTTP和OMA-PUSH的文件递送协议来传输。通知消息的第二组成承载与信息的交互性和递送相关联的任何同步信息，其中该信息与媒体广播服务相关联。通知消息的第二组成可以经由RTP在RTP净荷中传送，以便允许通知消息与包含媒体内容的媒体广播服务的媒体流准确同步。
文档编号H04H20/95GK101669309SQ200880013838
公开日2010年3月10日 申请日期2008年2月29日 优先权日2007年3月9日
发明者I·鲍阿齐齐 申请人:诺基亚公司