CN101953137A - 在通信系统中提供下载服务 - Google Patents

Abstract

本发明涉及形成自组织子组以对一组对某个服务或内容感兴趣的请求用户终端(UE2)寻址。本发明使得能够基于相似的内容请求(2-3)来建立临时多播子组。在本发明中，服务供应商(例如移动无线电站)收集由用户终端(UE2)传输的内容请求，将它们相比较(2-7)，并且如果在它们之间存在足够的相似性，并且如果它们的定时是适当的，则形成自组织多播子组，并且所请求的内容被多播(2-10)给该自组织多播子组的成员(UE2)。在这之后，删除自组织多播子组。

Description

在通信系统中提供下载服务

技术领域

本发明涉及向通信系统中的用户终端提供下载服务。

背景技术

3GPP MBMS(第三代合作伙伴项目多媒体广播多播服务)、3GPP2BCMCS(广播多播服务)和DVB CBMS/IPDC(广播和移动服务的数字视频广播融合/网际协议数据广播)提供了通过移动网络来传送多媒体内容的能力。这通过将广播引入移动通信网络中来实现。在单播中，数据被传输到单个专用接收机。在广播中，例如在基于陆地和卫星的电视传输中内容被发送给无限、未知数目的用户。

当内容被广播到一大群接收者时，特别地当为某个东西做广告时，系统可以支持即时交互(例如投票、投注、订购)。例如，用户可以决定购买她/他正在听的歌曲，或者请求对被推作至终端设备的下载广播的文件的许可。在这些情况下，用户需要连接到应用服务器并且提出请求。所请求的内容可以是免费的，但是仍需要下载它，并且可选地利用服务器侧上的数字权利管理(DRM)来保护该内容。在后面的情况下，最终用户设备可从授权者(rights issuer)请求附加许可。

在现有技术系统中，用户终端按照单播接收下载数据，即使在(几乎)同时进行订购的若干用户终端之间所请求的数据是相同的，通常就是上述这些情况。单播指的是递送应用服务器和最终用户设备之间的专用连接。单播连接是必需的，因为内容请求在被发布的同时就被处理，也就是说内容文件被即时递送。

上述系统的缺点是将相同内容分别发送给每个请求方的效率很低。单播连接不能很好地扩展，并且因此就网络容量和金钱来说成本很高。可扩展性是所关心的问题，特别是在预期或期望大的响应速率时，比如在移动营销情景中。

另一种解决方案是广播(免费的或受DRM保护的)内容，使最终用户设备在本地存储它，并且如果必要的话根据需要获得许可。例如，在被保护以免受未经授权消费的“激活现有下载的广播服务内容”的OMA BCAST解决方案中，内容供应商在广播服务内提供数字内容，例如最新的十大音乐排行榜。用户终端接收内容并且存储它。如果最终用户想消费所述内容，或者仅消费部分内容，她/他必须购买所述内容的权利(许可)。权利被递送到用户终端，以实现消费所存储的内容。如果最终用户决定不消费所述内容，则可以从用户终端删除它。

上述解决方案的缺点是内容被广播，但是用户可能对它不感兴趣。因此，没有高效利用系统中的传输资源。此外，将内容本地存储在用户设备上增加了最终用户设备(例如移动设备)的存储器需求，尤其在以这种方式递送多个服务的情况下。例如，如果将该解决方案应用于移动营销情景中，用户不希望为广告花费它们的本地存储空间。

多播指从单个发送机到多个特定接收机的数据的单向传输。在多播中，内容被发送到先前已加入专用多播组的设备。3GPP MBMS、3GPP2BCMCS、DVB-H(手持DVB)CBMS，和OMA BCAST(开放移动联盟广播)已经指定了用于广播/多播递送内容的解决方案。然而，在这种情况下，一旦形成多播组，它就在不同的时段内(例如在每次预订支付的情况下)保持为一个组。

发明内容

因此，本发明的目的是提供一种方法、用于实施所述方法以便解决上述问题的网络节点和系统。本发明的目的通过一种方法和装置来实现，所述方法和装置由在独立权利要求中所阐述的方法和装置来表征。优选实施例被公开在从属权利要求中。

本发明基于将广播/多播服务引入通信系统的想法。本发明包括在通信系统中提供下载服务，该方法包括将内容广播到用户终端。在广播期间，可以从用户终端接收内容请求。如果从第一用户终端接收到的内容请求与从第二用户终端接收到的内容请求具有至少一个共同特征，并且在预定时间段内接收到内容请求，则限定具有多播地址的多播子组。通过利用多播地址而将所请求内容的共同部分多播到包括在多播子组中的用户终端。

本发明的方法和装置的优点是当内容被广播/多播到一大群接收者时，例如当为某个东西做广告时，服务可以即时支持交互(例如投票、投注、订购)，而没有可扩展性的问题。本发明还使得能够高效地使用广播/多播以便为在短时间段内请求相同数据的广播用户子组提供服务。本发明的另一个优点是它使得能够节省带宽并且增加效率，因为通过使用多播可以一次为一批请求提供服务。

附图说明

在下文中，将参考附图通过优选实施例来更详细地描述本发明，其中：

图1a)、1b)、1c)图示了根据本解决方案的实施例的通信系统；

图2图示根据本解决方案的实施例的信令；

图3图示根据本解决方案的网络元件的功能；

图4图示根据本解决方案的实施例的广播多播服务中心的功能；以及

图5是图示多播与单播的对比的图形表示。

具体实施方式

OMA BCAST使能器(enabler)为移动广播服务定义在物理层之外的端对端框架。该使能器是承载独立的，以使得它在不同且各异的基础设施中都有用。例如，它应用于MBMS、BCMCS或CBMS承载技术。移动广播服务可以建立于提供双向连接的移动网络系统上，和/或建立于提供单向广播的数字广播系统上。因此，移动广播服务使得能够将丰富、交互且消耗带宽的媒体内容分发给大量移动受众。OMA DRM v2.0使能器不包括对广播/多播的一对一权利供应。然而，在广播环境中，服务和内容保护措施(measure)是共同商业模型并由此是必要的。因此，已在随后开发的OMA BCAST使能器规范中(即在“服务和内容保护”(SPCP)和“DRM的广播扩展”(XBS)部分中)定义了一些措施，DRM v2.0对广播的扩展，这允许使用广播权利对象(BCRO，broadcastrights object)。OMA XBS规范10.1节将订户组定义为共享组地址以及密码密钥素材(material)和算法的设备集，所述算法使得该组的任何子集与密码密钥相关联。订户组可以被密码保护，这意味着它具有以下附加性质：来自所述组的任何用户设备不能为不包括所述设备的子集推导出不同的密码密钥。如果订户组寻址被密码保护，则它可以被用来将BCRO有效地分配给这样的子集，在所述子集中利用与特定子集相关联的不同密钥来保护BCRO中的内容加密密钥。如在SPCP中描述的那样，XBS规范应用于所谓的DRM简档(profile)。在SPCP中描述了使用智能卡简档来为多播/广播内容递送使用规则的另一个选项。该解决方案将智能卡用作用于访问内容的控制机制。

数字权利管理(DRM)以受控的方式实现对消费数字内容的权利分配。特别地在广播/多播系统中，内容分配通常连同有条件访问(conditional access)措施一起实行。在接收之后，DRM系统为内容消费定义细粒度规则。基于内容供应商所表现的用户权利，内容可以被分配并且在认证设备上消费。典型地，利用加密密钥来加密内容，并且仅可以由得到消费该内容的足够权利的用户设备来对所述内容进行解密。

DRM内容形式(DCF)被用来封装和保护离散媒体(即铃音、应用、图像等)。该离散媒体简档允许将内容包装在包封(envelope)中(DCF)。该内容可以被加密或者不被加密，并且然后被作为DCF的内部结构和布局中的单个内容对象而放置。分组化的DRM内容格式(PDCF)被用来保护连续媒体(例如音频和视频)。连续媒体被保护在单独的简档中，因为它被分组化，并且因此该简档被称为分组化DCF(PDCF)。读取并解析连续媒体的应用意在逐分组地对文件起作用。为了促进所保护的连续媒体的回放，以分组被单独保护的方式来构造存储格式。为了流传送连续媒体，也需要这种结构上知晓的分组化。符合OMA DRM的流服务器应该能够理解内容格式的结构，以便将内容分成报头和分组，其可以被递送给理解内容格式的客户端。

本解决方案包括形成自组织子组以对一组对某个服务或内容感兴趣的请求用户终端寻址。本解决方案使得能够基于相似的内容请求来建立临时多播子组。在本解决方案中，服务供应商(例如移动无线电站)收集由用户终端传输的内容请求(也被称为服务请求和/或购买请求)，将它们相比较，并且如果在它们之间存在足够的相似性，并且如果它们的定时是适当的(也就是说彼此接近；在特定合并(pooling)时段内接收到)，则形成自组织多播子组，并且所请求的内容被多播给该自组织多播子组的成员。在这之后，删除自组织子组(关于该自组织子组的信息可以被存储例如以用于计费目的)。

在下文中，将参考蜂窝或无线通信系统(例如第三代(或超3G)移动通信系统或WLAN(无线局域网))来描述本解决方案的实施例。然而，本解决方案不意味着受限于这些实施例。本解决方案能够应用于任何网络节点、(一个或多个)对应部件、以及/或者应用于任何通信系统或能够为用户终端提供广播/多播服务的不同通信系统的任何组合。该通信系统可以是固定通信系统或无线通信系统或利用固定网络和无线网络二者的通信系统。通信系统和网络节点的规范(尤其在移动和无线通信中)所使用的协议快速地发展。这样的发展可能需要对实施例的额外改变。因此，所有的文字和表达式都应该被广泛地解释，并且它们意图说明而非限制实施例。相关发明的方面所关心的是功能而非执行它的网络元件或设备。

图1a)、1b)、1c)图示根据本解决方案的实施例的通信系统S。系统S包括至少一个用户终端UE1、UE2、UE3，所述用户终端UE1、UE2、UE3可以是例如能够在广播/多播网络环境(例如移动广播无线电网络)中操作的移动或无线终端，比如移动电话(移动站)、个人数字助理(PDA)、游戏机、膝上型电脑等等。该系统S还包括无线电接入网络RAN(例如蜂窝网络的无线电接入网络)或无线局域网(WLAN)。该系统S还包括核心网络CN，例如蜂窝网络的核心网络。接入网络RAN和核心网络由网络运营商操作，以用于提供对用户终端UE1、UE2、UE3的网络接入。该系统S还包括由服务运营商操作的广播多播服务中心BM-SC。该广播多播服务中心BM-SC可以被连接到内容源CS以及计费解决方案CH。当用户终端UE1、UE2、UE3在无线电接入网络RAN的区域中时，用户终端UE1、UE2、UE3能够经由核心网络CN(包括例如移动交换中心)和无线电接入网络RAN(包括例如基站和/或无线电网络控制器)与广播多播服务中心BM-SC通信。图1a)、1b)、1c)示出移动广播网络结构的简化版本，其仅图示了图示本解决方案所必需的部件，即使本领域技术人员自然知道普通的通信系统也包括没有在本文中详细描述的其它功能和结构。网络节点广播多播服务中心BM-SC、内容源CS和/或计费解决方案CH可以包括由广播/多播网络中的服务运营商操作的任何网络元件，例如IP多媒体子系统(IMS，例如用于服务认证的归属订户服务器(HSS))、运营/业务支持系统(OSS/BSS)、流服务器或数据库。尽管每个网络节点或功能RAN、CN、BM-SC、CH、CS已被描写成一个实体，但是可以在一个或多个物理或逻辑实体中实施不同模块和存储器。

在所提议的利用图1a)、1b)、1c)中示出的合并概念的多播内容递送的实施方式中，内容请求被合并并且所请求的内容被加密(如果适用的话，例如如果内容不免费的话，就不应该被用户重传，或者具有其它约束)，并且然后按照多播来传输。如图1a)所示，用户终端UE1、UE2、UE3(以及没有在图中表示的最后其它用户)能够接收广播信号(即广播流)。在广播期间，例如UE2、UE3的用户可能喜欢某首歌曲并且请求下载它，如图1b)所图示的那样。因此，UE2和UE3能够形成自组织组，其在合并时段之后可能按照多播接收下载内容，如图1c)所图示的那样。

在图1a)、1b)、1c)所示出的图形表示中，假设订户几乎同时请求相同的内容，也就是说在合并时段内。在该示例中，移动无线电服务(例如广播多播服务中心BM-SC)将连续音频流作为广播递送给用户设备UE1、UE2、UE3。用户设备UE1、UE2、UE3可以选择通过向网络传输内容请求来随时购买当前播放的歌曲。在图1b)所示出的情况中，不仅用户终端UE2和UE3请求内容，而且接收广播流的其它用户终端也可以请求内容，尽管没有在图1b)中示出。根据本解决方案，基于在合并时段期间收集到的内容请求，可以形成自组织多播组，以用于为请求用户终端UE2、UE3提供所请求的服务。为了合并购买请求，作为下载的对应音乐文件的递送可以被延迟，直到当前歌曲(或其它节目项目)已完成播放为止，例如其中具有大约30秒的最后附加延迟。在合并时段之后，按照多播仅将音乐文件(其可以是或者可以不是受DRM保护的)递送给请求用户终端，也就是说在这种情况下是UE2和UE3而不是UE1，如图1c)所示。如果应用了OMA BCAST DRM简档，则OMA XBS扩展限定了广播权利对象(BCRO)的使用以在多播内递送所需的许可。或者，在使用OMA BCAST智能卡简档的情况下(即SC简档，在OMA BCAST中密钥管理和许可递送的另一种方式)，递送作为安全策略扩展的一部分的许可，其在OMA BCAST中是STKM/LTKM递送的一部分。LTKM(长期密钥消息)包括存储在智能卡上的密钥信息，并且是处理STKM(短期密钥消息)所必需的。尽管未在图1b)中示出，但是用户终端UE2和/或UE3未必能够在所请求的内容被多播给UE2、UE3的时间段期间接收到广播流(但是UE1能够在该时间段期间接收到广播流)。

图2说明根据本解决方案实施例的网络实体之间的信令，通过使用多媒体广播多播服务(MBMS)为例。广播流内容2-2以及一个或多个会话描述协议(SDP)文件2-1中的下载内容和流的对应元数据被传输到用户终端UE2(为了清楚的原因，仅在图2中示出了一个用户终端，但是实际上可能存在多于一个接收该内容的用户终端)。例如广播多播服务中心BM-SC经由核心网络CN和无线电接入网络RAN传输2-1SDP文件。例如内容源CS经由广播多播服务中心BM-SC、核心网络CN和无线电接入网络RAN传输2-2广播流内容。可以在消息2-1和2-2中利用现有技术信令。

可以通过加入MBMS多播组来实施购买，其中用户终端UE2经由无线电接入网络RAN和核心网络CN将因特网组管理协议(IGMP)加入消息(也被称为购买请求和/或内容请求)发送到广播多播服务中心BM-SC。(加入消息2-3指示多播组IP地址。应用层/交互协议确定正确的IP地址，例如在流期间的正确时间挑选正确的SDP文件)。在这之后，BM-SC将授权请求消息2-4传输给计费解决方案CH，以便使用户终端UE2得到对网络CN/RAN的授权。通过消息2-1的会话描述协议(SDP)文件将IGMP加入过程所需的数据传送给用户终端UE2。当生成歌曲购买的计费记录时还可以利用用户终端授权。如果后端计费解决方案CH指示用户终端UE2能够足以支付购买(例如具有足够的资金)或者该内容是免费的，则通过经由BM-SC向网络CN/RAN传输授权准许响应2-5、2-6来准许加入请求，并且用户终端UE2可以被放置在多播组中。否则，加入请求被拒绝并且用户终端UE2不能被放置在多播组中(其中可以经由BM-SC向网络CN/RAN传输2-5、2-6授权拒绝响应)。

在步骤2-7中，BM-SC被布置成等待来自其它用户终端UE1、UE3针对相似内容的最后附加内容请求。在消息2-8中，内容源CS将所购买的下载内容递送给BM-SC。在合并延迟已到期之后，BM-SC经由网络CN、RAN将所购买的下载内容作为通过单向传输的文件递送(FLUTE)下载递送2-10到已成功加入多播组的用户终端。在步骤2-9中，BM-SC基于多播组IP地址(即多播地址)创建多播组，并且在向用户终端UE2(以及在合并时段内请求相同内容的其它用户终端UE3，尽管未在图2中示出)传输下载内容之前可以加密或者不加密该下载内容。在所请求的内容已被提供给用户终端之后，可以删除多播地址和/或多播组。另一个选项是将多播地址存储在网络中(例如存储在BM-SC中)。

图3图示根据本解决方案实施例的无线电接入网络RAN/核心网络CN的功能。在步骤3-1、3-2中将由BM-SC传输的广播流内容以及会话描述协议(SDP)文件中的对应元数据转发到用户终端UE1、UE2、UE3。在步骤3-3中将由用户终端UE2、UE3传输的因特网组管理协议(IGMP)加入消息(即购买请求)转发到广播多播服务中心BM-SC。在这之后，从BM-SC接收3-4授权响应。如果用户终端UE2、UE3能够足以支付购买(例如具有足够的资金)或者该内容是免费的，则准许加入请求，从BM-SC接收3-4授权准许响应，并且用户终端UE2、UE3可以被放置在对应的多播组中。在步骤3-5中，从BM-SC接收作为通过单向传输的文件递送(FLUTE)下载的所购买的下载内容，并且将其转发3-5到已成功加入多播组的用户终端UE2、UE3。然而，如果拒绝加入请求，则用户终端不被放置在多播组中，并且可以从BM-SC接收3-4授权拒绝响应，在这种情况下不会为所考虑的用户终端提供多播下载内容。

图4图示根据本解决方案实施例的广播多播服务中心BM-SC的功能，通过使用多媒体广播多播服务(MBMS)为例。在步骤4-1中，经由核心网络CN/无线电接入网络RAN将与广播流内容有关的会话描述协议(SDP)文件中的元数据传输到用户终端UE1、UE2、UE3。在步骤4-2中，从内容源接收广播流内容并且经由核心网络CN/无线电接入网络RAN将其转发到UE1、UE2、UE3。可以在步骤4-1和4-2中利用现有技术过程。在步骤4-3中，经由接入网络RAN/核心网络CN从UE2接收因特网组管理协议(IGMP)加入消息(即购买请求)。在这之后，在步骤4-4中，BM-SC将授权请求消息传输给计费解决方案CH以便授权用户终端UE2对网络CN、RAN的使用。在步骤4-1中，通过会话描述协议(SDP)文件将IGMP加入过程所必需的数据传送给用户终端UE2。如果后端计费解决方案CH指示用户终端UE2能够足以支付购买(例如具有足够的资金)或者该内容是免费的，则在BM-SC中从CH接收授权准许响应4-5。这意味着，准许加入请求并且该用户终端UE2可以被放置在多播组中。否则，拒绝加入请求并且用户终端UE2不能被放置在多播组中(可以在BM-SC中从CH接收4-5授权拒绝响应)。在步骤4-6中，授权准许响应被传输给CN/RAN。在步骤4-7中，BM-SC等待源于其它用户终端UE1、UE3的最后附加请求。在步骤4-8中，从内容源CS接收所购买的下载内容。在合并延迟已到期之后，BM-SC经由网络CN、RAN将所购买的下载内容作为通过单向传输的文件递送(FLUTE)下载递送4-10到已成功加入多播组的用户终端UE2、UE3。在步骤4-9中，BM-SC定义多播组的多播地址，并且在向用户终端UE2、UE3传输下载内容之前可以加密或者不加密该下载内容。

图5示出了说明单播与多播的对比的图形表示，其描绘了可扩展性问题并说明了当内容被多播(下半部分)而不是被单播(上半部分)时可以实现的容量节省。在后面的情况下，对每个接收用户终端UE来说专用连接是有必要的，以便增加带宽需求，尤其是流行内容的带宽需求。相反，可以经由核心网络元件NE和基站BS将多播文件有效地递送给先前已请求内容的用户终端UE。可以从图5中看到，对于接收多播内容的每个用户终端来说在网络中专用传输是没必要的。在多播中，将内容文件供应给不同用户终端可以作为一个单元来处理，而在单播中，必须为每个用户终端UE单独处理所提供的内容文件(在网络中所必需的专用传输信道)。

当无线电服务被用作示例时，还应该注意任何其它现场流(livestreaming)服务都可以用于相同的目的，例如其中用户可以购买铃音的电视节目。流服务促进相对短时间帧中的信道购买订购(channelingpurchase order)，因为出售(offer)或购买脉冲与连续媒体递送相关联。从合并时段之外接收到的订购可能仍按照单播来递送。

所保护内容所需的解密密钥可以以下述方式传输到用户终端：a)通过使用上述合并机制来按照多播；b)通过应用包括在数据传输中的OMA DRM 2.0的域密钥概念按照单播；c)通过使用具有BCRO(DRM简档)的OMA BCAST服务和内容保护功能；以及/或者d)具有智能卡简档的OMA BCAST。

在递送内容之前合并内容请求的优点在于利用了规模经济。仅需要一个多播连接，而不是一些单播连接，从而降低了文件递送的成本。

在免费下载内容的情况下，例如广告内容，通过本解决方案可以降低营销活动的总成本。另一方面，如果内容被收费，则增加了每笔销售的利润。对于网络运营商来说，增加了可用网络容量，从而允许递送其它服务。

本解决方案的另一个优点(尤其在移动营销中，即移动广告)是将用户分成目标组的机会。许多用户不愿意接受至少在某种程度上没有被个人化的移动广告。按照单播递送的完全个人化广告引起高成本。通过根据本解决方案的多播组，在仍可以实现对用户的情况和简档的某些适配的同时可以降低广告成本。例如可以基于用户年龄、区域位置、收入和/或性别来创建根据本解决方案的多播组。因此，在合并时段期间，根据预先定义的规则集，请求用户可以被放置在最适合的组中。如果可适用，用户也可以属于多于一个多播组，因此接收多于一个下载文件。

本解决方案使得能够在不同时间发布购买命令，但是按照多播同时进行下载。

本解决方案可以应用于例如移动广告。本解决方案可以增加将来广告有关的产品的效率。本解决方案还可以应用于移动广播解决方案，其用作3G和DVB-H移动网络中的中心内容控制实体。其他可能性包括递送具有DRM的下载文件的通信服务产品，例如用于音乐、铃音等等的下载/递送平台(下载/递送服务器)。

应该注意的是结合本解决方案，术语“(进行)下载”被用来指形成子组的终端组，以及基于终端触发的请求来多播内容的网络。因此，本解决方案不同于传统下载服务。本解决方案包括广播/多播方法，其效率来自于多播而不是通常用于传统下载的点对点连接。多播由请求“下载”特征的终端触发，而且服务立刻将它发送给许多终端并因此变成高效的场景。

尽管前面已参考移动广播无线电(例如移动因特网无线电)描述了本解决方案，但是应该注意本解决方案可以以类似的方法用于提供任何其他内容服务，例如移动电视或在线游戏。尽管已描述的本解决方案假设将无线电节目作为广播流广播给用户终端，并且然后将所请求的内容作为可下载文件多播给请求用户终端，但是可以通过使用任何适当的广播/多播技术来提供内容。在本上下文中，术语内容或内容服务可以指音乐、音频、视频、数据、语音和/或可以在系统中广播/多播的任何其他类型的内容。内容可以是或者不是受保护的内容(例如受DRM保护的)。

在图中示出的项目和步骤被简化并且仅旨在描述本解决方案的想法。在上面图1到图5描述的步骤/要点、信令消息以及相关功能不是绝对按照时间先后的次序，并且可以同时或者以不同于所给出的次序的次序来执行某些步骤/要点。还可以在步骤/要点之间或步骤/要点内执行其他功能，并且在所图示的消息之间发送其他信令消息。某些步骤/要点或该步骤/要点的部分也可以被省略或者整合在一起或由相应步骤/要点或该步骤/要点的部分代替。装置操作说明可以在一个或多个物理实体或逻辑实体中实施的过程。信令消息仅是示例性的，并且甚至可以包括用于传输相同信息的若干单独消息。所述消息仅作为示例，并且它们可以仅包含某些上述信息。此外，消息还可以包含某些其他信息，并且名称可以偏离上面给出的那些。作为对广播多播服务中心、内容源节点、计费解决方案节点、核心网络、无线电接入网络和/或用户终端的代替，或者除了广播多播服务中心、内容源节点、计费解决方案节点、核心网络、无线电接入网络和/或用户终端之外，可以以通信系统的任何其他元件来执行上述操作。

除了现有技术装置之外，实施本解决方案的功能的系统或系统网络节点包括用于以上述方式建立自组织多播组的装置。现有网络节点和用户终端包括可以在本解决方案的操作中利用的存储器和处理器。可以使用包括在专用集成电路(ASIC)和/或可编程电路(例如EPLD(电可编程逻辑设备)和FPGA(现场可编程门阵列))中的例程和/或软件例程的补充或更新来执行在实施本解决方案中所必需的任何变化。

对本领域技术人员来说显而易见的是可以以各种方式来实施作为技术发展的发明概念。本发明及其实施例不限于上述示例而是可以在权利要求的范围内变化。

缩写列表

3GPP    第三代合作伙伴项目

IP      网际协议

BM-SC   广播多播服务中心

DCF     数字权利管理内容格式

PDCF    分组化DCF

DRM     数字权利管理

FLUTE   通过单向传输的文件递送(RFC 3926)

IPDC    IP数据广播

MBMS    多媒体广播多播服务

BCMCS   广播多播服务

CBMS    广播和移动服务的融合

DVB-H   手持数字视频广播

OMA     开放移动联盟

RO      权利对象

BCRO    广播权利对象

SGK     订户组密钥

SDP     会话描述协议

IGMP    因特网组管理协议

Claims (23)

1.一种在通信系统(S)中提供下载服务的方法，所述方法包括广播(2-2)能由系统(S)中的用户终端(UE1、UE2、UE3)接收的内容，其特征在于，所述方法还包括：

从第一用户终端(UE2)接收第一内容请求(2-3)，以及从第二用户终端(UE3)接收第二内容请求，

其中，如果第一内容请求(2-3)与第二内容请求具有至少一个共同的特征，并且如果在预定时间段内接收到第一内容请求和第二内容请求，则所述方法包括：

定义(2-9)具有多播地址的多播子组，其中所述多播子组包括第一和第二用户终端(UE2、UE3)；以及

通过利用所述多播地址来将所请求内容的共同部分传输(2-10)给多播子组。

2.根据权利要求1所述的方法，其特征在于：

作为对接收内容请求(2-3)的响应对用户终端执行授权检查；以及

如果授权用户终端接收所请求的内容，则将该用户终端包括在多播子组中。

3.根据权利要求1或2所述的方法，其特征在于：

形成用户终端的临时多播子组，在合并时段内从该临时多播子组接收到针对类似内容的内容请求；以及

在已将相关内容提供给用户终端之后删除临时多播子组。

4.根据权利要求1、2或3所述的方法，其特征在于在已将相关内容提供给用户终端之后删除多播地址。

5.根据前述任一项权利要求所述的方法，其特征在于提供用于将下述各项中的至少一项下载到用户终端的服务：音频文件、音乐文件、视频文件、数据文件、语音文件、音频流、音乐流、视频流、数据流、语音流以及所保护的内容。

6.根据前述任一项权利要求所述的方法，其特征在于存储关于多播子组的信息以用于计费目的。

7.根据前述任一项权利要求所述的方法，其特征在于延迟传输所请求的内容直到完成广播当前歌曲或项目为止以及/或者直到合并时段到期为止。

8.一种被配置成广播能够由系统(S)中的用户终端(UE1、UE2、UE3)接收的内容的通信系统(S)，其特征在于所述系统(S)还被配置成：

从第一用户终端(UE2)接收第一内容请求，以及从第二用户终端(UE3)接收第二内容请求，

其中，如果第一内容请求与第二内容请求具有至少一个共同的特征，并且如果在预定时间段内接收到第一内容请求和第二内容请求，则所述系统被配置成：

定义具有多播地址的多播子组，其中所述多播子组包括第一和第二用户终端(UE2、UE3)；以及

通过利用所述多播地址来将所请求内容的共同部分传输给多播子组。

9.根据权利要求8所述的系统，其特征在于所述系统(S)被配置成：

作为对接收内容请求的响应，对用户终端(UE2、UE3)执行授权检查；以及

如果授权用户终端(UE2、UE3)接收所请求的内容，则将该用户终端包括在多播子组中。

10.根据权利要求8或9所述的系统，其特征在于所述系统(S)被配置成：

形成用户终端(UE2、UE3)的临时多播子组，在合并时段内从该临时多播子组接收到针对类似内容的内容请求；以及

在已将相关内容提供给用户终端(UE2、UE3)之后删除临时多播子组。

11.根据权利要求8、9或10所述的方法，其特征在于所述系统(S)被配置成在已将相关内容提供给用户终端之后删除多播地址。

12.根据前述任一项权利要求所述的系统，其特征在于所述系统(S)被配置成提供用于将下述各项中的至少一项下载到用户终端的服务：音频文件、音乐文件、视频文件、数据文件、语音文件、音频流、音乐流、视频流、数据流、语音流以及所保护的内容。

13.根据前述任一项权利要求所述的系统，其特征在于所述系统(S)被配置成存储关于多播子组的信息以用于计费目的。

14.根据前述任一项权利要求所述的系统，其特征在于所述系统(S)被配置成延迟传输所请求的内容直到完成广播当前歌曲或项目为止以及/或者直到合并时段到期为止。

15.一种通信系统(S)中的内容供应商节点(BM-SC)，其中所述内容供应商节点(BM-SC)被配置成广播能够由该系统(S)中的用户终端(UE1、UE2、UE3)接收的内容，其特征在于所述内容供应商节点(BM-SC)还被配置成：

从第一用户终端(UE2)接收第一内容请求，以及从第二用户终端(UE3)接收第二内容请求，

其中，如果第一内容请求与第二内容请求具有至少一个共同的特征，并且如果在预定时间段内接收到第一和第二内容请求，则所述内容供应商节点(BM-SC)被配置成：

定义具有多播地址的多播子组，其中所述多播子组包括第一和第二用户终端(UE2、UE3)；以及

通过利用所述多播地址来将所请求内容的共同部分传输给多播子组。

16.根据权利要求15所述的内容供应商节点(BM-SC)，其特征在于所述内容供应商节点(BM-SC)被配置成：

作为对接收内容请求的响应，对用户终端(UE2、UE3)执行授权检查；以及

如果授权用户终端(UE2、UE3)接收所请求的内容，则将该用户终端包括在多播子组中。

17.根据权利要求15或16所述的内容供应商节点(BM-SC)，其特征在于所述内容供应商节点(BM-SC)被配置成：

形成用户终端(UE2、UE3)的临时多播子组，在合并时段内从该临时多播子组接收到针对类似内容的内容请求；以及

在已将相关内容提供给用户终端(UE2、UE3)之后删除临时多播子组。

18.根据权利要求15、16或17所述的内容供应商节点(BM-SC)，其特征在于内容供应商节点(BM-SC)被配置成在已将相关内容提供给用户终端之后删除多播地址。

19.根据权利要求15、16或17所述的内容供应商节点(BM-SC)，其特征在于内容供应商节点(BM-SC)被配置成存储多播地址。

20.根据前述权利要求15-19中任一项所述的内容供应商节点(BM-SC)，其特征在于所述内容供应商节点(BM-SC)被配置成提供用于将下述各项中的至少一项下载到用户终端的服务：音频文件、音乐文件、视频文件、数据文件、语音文件、音频流、音乐流、视频流、数据流、以及语音流。

21.根据前述权利要求15-20中任一项所述的内容供应商节点(BM-SC)，其特征在于所述系统(S)被配置成存储关于多播子组的信息以用于计费目的。

22.根据前述权利要求15-21中任一项所述的内容供应商节点(BM-SC)，其特征在于所述内容供应商节点(BM-SC)被配置成延迟传输所请求的内容直到完成广播当前歌曲或项目为止。

23.根据前述权利要求15-21中任一项所述的内容供应商节点(BM-SC)，其特征在于所述内容供应商节点(BM-SC)是广播多播服务中心。

Images