用于优化去往漫游客户的下载用户服务递送的系统和方法

摘要

一种用于使用单播承载来提供MBMS内容分发的系统和方法。根据各种实施方式，MBMS下载用户服务通过经由OMA Push消息递送FLUTE文件递送表而被递送到多个用户设备。多个不同附加动作之一可以用在MBMS下载用户服务的递送中。这些动作包括(1)使用简单的URL编码格式进行单个HTTP GET请求，以取回FDT的所有文件；(2)使用URL编码中FDT的“组”字段进行单个HTTPGET请求，以取回FDT的文件的逻辑组；(3)进行流水线化的HTTPGET请求，其中每一个HTTP GET请求取回FDT的至少一个文件；(4)进行串行化的HTTP GET请求，其中每个HTTP GET请求取回FDT的至少一个文件；(5)进行流水线化的HTTP GET请求，其中每个HTTP GET请求取回FDT的文件的至少一个逻辑组；(6)进行串行化的HTTP GET请求，其中每个HTTP GET请求取回FDT的文件的至少一个逻辑组；(7)在上述OMA PUSH消息中递送MBMS用户服务的ServiceID，而不将ServiceID包括在FLUTE FDT中；(8)用于将MBMS UE从BM-SC解注册以停止MBMS下载用户服务的单播递送的HTTP请求；以及(9)在OMA Push消息中递送FDT实例的FDT实例ID。

说明书

技术领域

本发明总体上涉及多媒体广播多播服务(MBMS)。更具体地，本发明涉及使用单播承载进行MBMS内容分发。

背景技术

本部分旨在为权利要求书中记载的本发明提供背景或上下文。在此的描述可包括可以探究的概念，但不一定是之前已经想到或者已经探究的概念。因此，除非在此指出，否则在本部分中描述的内容对于本申请的说明书和权利要求书而言不是现有技术，并且并不因为包括在本部分中就承认是现有技术。

近些年来，移动广播方案已经由不同组织进行了标准化，诸如第三代合作伙伴计划(3GPP)MBMS。3GPP MBMS支持将流行的多媒体内容以资源高效的方式递送到移动用户。MBMS客户端可以经由下载递送、流式传输递送以及流式传输递送和下载递送的组合来接收内容。

MBMS是在3GPP第6版中描述的特征。然而，MBMS仅可以由运营商部署在少数区域中，在这些区域中，广播/多播分发流行内容是具有成本效益的。当MBMS订户移动到不具有MBMS覆盖的区域时，运营商可以利用单播模式来分发MBMS内容。在这种用例中，需要应用层/传输层信令来确保MBMS内容的广播/多播模式接收与MBMS内容的单播模式接收之间的无缝切换。

针对MBMS用户服务扩展的3GPP SA4第7版工作项目的目标之一在于：规定单播模式中的MBMS内容分发(通过流式传输承载和交互式承载)所需的应用层/传输层信令。另一目标在于规定针对MBMS内容递送的优化技术。

以下的表1示出了在3GPP SA4中、针对将在广播/多播模式中使用的协议和在单播模式中使用的协议之间的映射的当前工作假设。

表1

  纯下载递送方  法  纯流式传输  递送方法  流式传输递送方法  +下载递送方法  使用广播承载/  多播承载的  MBMS内容分  发  FLUTE/UDP  MBMS流式  传输框架  -用于媒体传  输的  RTP/UDP  -用于FEC  传输的  RTP/UDP  MBMS流式传输框  架  -用于媒体传输的  RTP/UDP  -用于FEC传输的  RTP/UDP+用于文  件下载的  FLUTE/UDP  使用单播承载  进行的MBMS  内容分发(用于  漫游MBMS客  户端)  用于FDT传送  的OMA-PUSH   用于个体文件  的HTTP GET  请求  PSSe  -用于会话控  制的RTSP  -用于媒体传  输的  RTP/UDP  PSSe  -用于会话控制的  RTSP  -用于媒体传输的  RTP  -用于在同一RTSP  会话中的文件下载  的FLUTE/UDP

经由单向传输的文件递送(FLUTE)协议在互联网工程任务组(IETF)征求意见(RFC)3926中进行了讨论，其在www.ietf.org/rfc/rfc3926.txt处可得。用户数据报协议(UDP)在IETFRFC 768中进行了讨论，其在www.ietf.org/rfc/rfc0768.txt处可得。实时传输协议(RTP)是一种用于实时应用的传输协议，在IETF RFC3550中进行了讨论，其在www.ietf.org/rfc/rfc3550.txt处可得。实时流式传输协议(RTSP)在IETF RFC 2326中进行了讨论，其在www.ietf.org/rfc/rfc2326.txt处可得。

3GPP分组交换流式传输服务(PSS)是用于在移动设备中支持分组交换流式传输的3GPP方案。PSS定义用来支持用于移动设备的流式传输服务的协议和媒体编解码器。PSS是基于用于会话建立和控制的RTSP。3GPP分组交换流式传输服务增强(PSSe)目前正在3GPP中进行定义。这些增强的目标在于：定义3GPP PSS版本号6的扩展，以优化流式传输服务。PSS的总体描述可以在3GPP TS26.233 V6.0.0(2004-09)中找到：透明的端到端分组交换流式传输服务(PSS)；总体描述(版本6)，其在www.3gpp.org/ftp/Specs/archive/26_series/26.233处可得。PSS传输协议和编解码器在3GPP TS 26.234 V7.2.0(2007-03)中规定，并且在www.3gpp.org/ftp/Specs/archive/26_series/26.234/处可得。

3GPP TS 26.346-730的7.4节分两步描述了当MBMS承载不可用时，将开放移动联盟(OMA)Push(推送)机制用于MBMS下载。利用此机制，MBMS用户设备(UE)首先向广播多播交换中心(BM-SC)注册其移动台集成服务数字网络(MSISDN)，以便使用OMA Push来接收下载会话。BM-SC随后分发FLUTE文件递送表(FDT)实例，其允许MBMS UE获取感兴趣的文件。

发明内容

各种实施方式提供了一种用于将MBMS下载用户服务递送到需要单播递送的MBMS UE(例如，当漫游时，或者在MBMS覆盖区域外处于切换时)的机制。在这些实施方式中，该机制涉及经由OMAPUSH消息来递送FLUTE FDT。另外，多个不同附加动作之一可以用在MBMS下载用户服务的递送中。这些动作包括(1)使用简单的URL编码格式制作出单个HTTP GET(获取)请求，以取回FDT实例的所有文件，其例如可以由其FDT实例ID标识；(2)使用URL编码中FDT的“组”字段制作出单个HTTP GET请求，以取回FDT或FDT实例的文件的逻辑组，其例如可以由其FET实例ID标识；(3)制作出流水线化的HTTP GET请求，其中每一个HTTP GET请求取回FDT实例的至少一个文件，其例如可以由其FDT实例ID标识；(4)制作出串行化的HTTP GET请求，其中每个HTTP GET请求取回FDT实例的至少一个文件，其例如可以由其FDT实例ID标识；(5)制作出流水线化的HTTP GET请求，其中每个HTTP GET请求取回FDT实例的文件的至少一个逻辑组，其例如可以由其FDT实例ID标识；(6)制作出串行化的HTTP GET请求，其中每个HTTPGET请求取回FDT的文件的至少一个逻辑组；(7)在上述OMAPUSH消息中递送MBMS用户服务的ServiceId，而不将ServiceId包括在FLUTE FDT中；(8)用于将MBMS UE从BM-SC解注册以停止MBMS下载用户服务的单播递送的HTTP请求；以及(9)在OMAPush消息中递送FDT实例的FDT实例ID，使得MBMS UE可以根据上述实施方式(1)-(7)、在其用于单播文件递送的请求中参考特定FDT实例。

将MBMS用户服务的ServiceId(服务ID)在OMA PUSH消息中递送，而不是将该serviceID包括在FLUTE FDT中的优势在于：其使得OMA Push客户端能够将FDT指引到相关的客户端应用，而不需解析该FDT。

把HTTP请求用于将MBMS UE从BM-SC解注册以停止MBMS下载用户服务的单播递送这样的实施方式的优势在于：其减小了网络资源的浪费，否则这些网络资源会花费在将不需要的OMA Push消息发送到MBMS UE上。

上述其他实施方式的优势在于：它们规定了用于HTTP请求的各种备用高效格式，以便使用单播承载将感兴趣的文件从BM-SC取回到MBMS UE。这些实施方式为MBMS UE请求MBMS下载会话中的个体文件、文件的逻辑组和所有文件提供了灵活性和效率。这些实施方式还可以减小通过使用HTTP流水线并随后使用语义学来在一个HTTP请求中请求文件的组，而在单播模式中获得MBMS下载用户服务中的延迟。这些实施方式进一步提供了BM-SC按照MBMSUE的请求将这些文件打包的可能性。

本发明的这些和其他优势和特征与本发明操作的组织和方式一起将会从结合附图的下述详细描述中变得明显，其中贯穿下述附图，相同元素具有相同附图标记。

附图说明

图1是描述了各种实施方式可以借由其实现的过程的流程图；

图2是本发明的各种实施方式可以在其中实现的系统的图形描述；

图3是各种实施方式可以在其中实现的系统的总览示意图；

图4是可以结合各种实施方式的实现一起使用的电子设备的透视图；以及

图5是可以包括在图4的电子设备中的电路的示意性表征。

具体实施方式

如果MBMS UE在其归属网络之外(在该处，不能通过MBMS承载对感兴趣的内容进行MBMS下载)，或者该MBMS UE在MBMS覆盖区域外参与切换，则该MBMS UE可以注册单播服务递送，如果用于此服务的MBMS用户服务描述包括deliveryMethod(递送方法)元素中的unicastAccessURI(单播访问URI)属性的话。超文本传输协议(HTTP)GET方法可以用于注册，并且serviceId和MBMSUE的MSISDN被编码至如下所定义的并包括在HTTP GET请求中的统一资源标识符(URI)查询部分中。GET/unicastReg？serviceId＝urn:3gpp:0010120123hotdog&MSISDN＝436642012345HTTP/1.1HOST:bmse.example.com

HTTP在IETF RFC 2616中进行了讨论，并且在www.ietf.org/rfc/rfc2616.txt处可得。URI在IETF RFC 3986中进行了讨论，并且在www.ietf.org/rfc/rfc3986.txt处可得。

目前，并未针对BM-SC分发FLUTE FDT实例所需的信令给出了定义。此信令可以划分成两个单独的子过程。第一子过程涉及从BM-SC到MBMS UE的消息格式。用于此目的的OMA Push的一般用法在3GPP TS 26.346-730的7.4.3节中进行了规定。MBMS下载服务的FLUTE FDT可以置入OMA Push会话中。OMA Push客户端使用应用ID来将OMA Push消息转发至单播MBMS文件下载客户端。单播MBMS文件下载客户端随后可以将接收到的FDT实例转发至由服务ID标识的正确MBMS文件下载服务。

然而，MBMS UE可能已经注册了多个单播MBMS服务。目前，服务ID不可以从OMA Push消息中获得。因此，MBMS UE不能将包含FDT实例的进入的OMA Push消息关联到正确的MBMS文件下载服务。为了解决这个问题，3GPP T doc S4-070296建议在OMA Push传输的情况下，利用用户服务描述机制的ServiceID属性来扩展FLUTE FDT。然而，此方式的不利之处在于：接收机上的OMA Push客户端必须在将FDT实例分派到相关MBMS下载服务之前，首先解析FDT以提取ServiceID。利用此方式，FDT实例还需要由推送代理网关(PPG)(或网络中的某些其他实例)进行修改以便包括服务ID。

第二子过程涉及从MBMS UE到BM-SC的、用于获取感兴趣的文件的消息格式。在对经由OMA Push机制接收的FDT实例进行解析后，接收机能够标识会话的哪些文件是感兴趣的，并且可以执行HTTP GET请求，以便取回(1)特定文件；(2)由(源块编号(SBN)、编码符号ID(ESI))标识的一个或多个特定FLUTE分组；(3)FDT中的所有文件；或(4)FDT中文件的逻辑组。用于取回这些对象的HTTP GET请求的格式并未在3GPP中标准化。用于解决此问题的一种选择涉及对3GPP TS 26.346中定义的点到点(PtP)修复请求/响应机制进行扩展。此方案定义HTTP GET请求的一种格式，该请求用来从PtP修复服务器取回一个或多个FLUTE分组或单个文件。然而，此方案并未针对请求FDT中的所有文件以及请求FDT中文件的逻辑组而定义格式。3GPP TS 26.346-730的7.2.6节定义了FDT中用于会话中文件逻辑归组的语义元素“组”。然而，并未规定将此字段用于单播下载递送。

作为多个文件递送的一部分而下载的文件通常彼此相关。示例包括网页、软件包和参考元数据封包及其元数据片段。FLUTE客户端在接收到XML编码的FDT实例时对其进行分析、标识每个请求的文件、使用传输对象标识符(TOI)将其与FLUTE分组相关联，并发掘每个文件的相关带内下载配置参数。FLUTE FDT实例和文件元素中的附加“组”字段支持相关文件的逻辑归组。FLUTE接收机应当下载属于所有组的所有文件，其中这些组的一个或多个文件已被请求。然而，UE可以指示其FLUTE接收机忽略归组，以便处理特殊情况，诸如，低存储可用性。组名由FLUTE发送机分配，并且针对会话，每个特定组名将相应的文件归组在一起形成一个组，包括在相同的和其他的FDT实例中描述的文件。

在FDT实例中的组字段用法示出在FDT XML机制(3GPP TS26.346-730的子部分7.2.10)中。FDT实例的每个文件元素可以利用零个、一个或多个组名来标记。每个FDT实例元素可以利用零个、在该FDT实例中描述的所有文件所继承的一个或多个组名来标记。

各种实施方式提供了用于将MBMS下载用户服务递送到需要单播递送的MBMS UE(例如，当漫游时，或者在MBMS覆盖区域外处于切换中)的机制。在这些实施方式中，该机制涉及经由OMA Push消息来递送FLUTE FDT。另外，多个不同附加动作之一可以用在MBMS下载用户服务的递送中。这些动作包括(1)使用简单的URL编码格式进行单个HTTP GET请求，以取回FDT实例的所有文件，其例如可以由其FDT实例ID来标识；(2)使用URL编码中FDT的“组”字段进行单个HTTP GET请求，以取回FDT或FDT实例的文件的逻辑组，其例如可以由其FDT实例ID来标识；(3)进行流水线化的HTTP GET请求，其中每一个HTTP GET请求取回FDT实例的至少一个文件，其例如可以由其FDT实例ID来标识；(4)进行串行化的HTTP GET请求，其中每个HTTP GET请求取回FDT实例的至少一个文件，其例如可以由其FDT实例ID来标识；(5)进行流水线化的HTTP GET请求，其中每个HTTP GET请求取回FDT实例的文件的至少一个逻辑组，其例如可以由其FDT实例ID来标识；(6)进行串行化的HTTP GET请求，其中每个HTTP GET请求取回FDT的文件的至少一个逻辑组；(7)在上述OMA PUSH消息中递送MBMS用户服务的ServiceID，而不将ServiceID包括在FLUTEFDT中；(8)用于将MBMS UE从BM-SC解注册以停止MBMS下载用户服务的单播递送的HTTP请求；以及(9)在OMA Push消息中递送FDT实例的FDT实例ID，使得MBMS UE可以根据上述实施方式(1)-(7)在其用于单播文件递送的请求中参考特定FDT实例。

将MBMS用户服务的ServiceID在OMA PUSH消息中递送，而不是将该serviceID包括在FLUTE FDT中的优势在于：其使得OMAPush客户端能够将FDT指引到相关的客户端应用，而不需解析该FDT。

这种把HTTP请求用于将MBMS UE从BM-SC解注册以停止MBMS下载用户服务的单播递送的实施方式的优势在于：其减小了网络资源的浪费，否则这些网络资源会花费在将不需要的OMA Push消息发送到MBMS UE上。

上述其他实施方式的优势在于：它们规定了用于HTTP请求的各种备用高效格式，以便使用单播承载将感兴趣的文件从BM-SC取回到MBMS UE。这些实施方式为MBMS UE请求MBMS下载会话中的个体文件、文件的逻辑组和所有文件提供了灵活性和效率。这些实施方式还通过使用HTTP流水线以及使用语义学来在一个HTTP请求中请求文件的组，减小了在单播模式中获得MBMS下载用户服务时的延迟。这些实施方式进一步提供了BM-SC按照MBMS UE的请求将这些文件打包的可能性。

各种实施方式可以通过执行图1中描绘的多个过程来实现。在图1的100处，MBMS UE离开MBMS覆盖区域。在110处，MBMSUE从MBMS用户服务描述(USD)取回unicastAccessURI和serviceID。在120处，MBMS UE将其MSISDN和serviceID注册到与unicastAccessURI相关联的服务器或BM-SC。当MBMS用户服务递送开始时，在130处，BM-SC在OMA Push消息中将最新的FDT实例和serviceID发送至MBMS UE。在这样做时，BM-SC可以使用OTA-WSP协议或者OTA-HTTP协议。如果使用OTA-HTTP协议，则服务器可以使用多方MIME结构来在不同的部分中发射FDT实例、对应的FDT实例ID和serviceID。如果使用OTA-WSP，则服务器使用适当的语法来单独发送FDT实例、对应的FDT实例ID和serviceID。

在图1的140处，MBMS UE中的OMA Push客户端根据serviceID标识MBMS用户服务。在150处，OMA Push客户端随后扫描在同一消息中接收的FDT实例，以标识将在该MBMS用户服务中下载的fileURI(文件URI)。就这一点，用户随后可以处理关于FLUTE会话中所有文件的必要信息，包括它们的fileURI、内容编码、内容长度等。在160处，UE随后通过发起按照以下格式的HTTP GET请求来从BM-SC取回感兴趣的文件：

unicast_access_request_http_URI＝unicast_access_URI“？”query

unicast_access_URI＝<来自用户服务描述的unicastAccesURI；URI参考如在[IETF RFC 3986]中所定义的>

如果UE对获得来自FDT的所有文件感兴趣，则其通过在HTTPGET请求中使用以下查询来指示此选择：

GET

/path/unicast_access？serviceID＝abc&fdtInstanceID＝def&fileURI＝*

HTTP/1.1

Host:bmsc.example.com

在上述示例中，BM-SC可以通过使用多方MIME结构发送来自FDT的所有文件而做出响应。

如果UE对由FDT中的文件的groupID(组ID)所标识的文件逻辑组感兴趣，则其可以通过在HTTP GET请求中使用以下查询来指示此选择：

GET

/path/unicast_access？serviceID＝abc&fdtInstanceID＝def&groupID＝xyz

HTTP/1.1

Host:bmsc.example.com

在上述示例中，BM-SC可以通过使用多方MIME结构发送来自FDT实例ID＝def的FDT实例的属于逻辑groupID＝xyz的所有文件而做出响应。

如果UE对特定文件感兴趣，则其通过在HTTP GET请求中使用以下查询来指示此选择：

GET

/path/unicast_access？serviceID＝abcd&group_id＝www.example.com/ne

ws/latest.3gp&Content-MD5＝ODZiYTU1OTFkZGY2NWY5ODh＝＝

HTTP/1.1

Host:bmsc.example.com

应当注意，包括在GET请求中的content_md5(内容md5)消除了同一fileURI的多个版本之间的歧义。MD5是“消息摘要算法5”，其在RFC 1321中定义，并在www.ietf.org/rfc/rfc1321.txt处可得。content_md5报头字段在RFC 1864中进行了定义，并在www.ietf.org/rfc/rfc1864.txt处可得。

针对通过使用多个流水线化的或串行化的HTTP GET请求来取回FDT的多个不相关文件，一种方案基于目前的规范，其涉及针对感兴趣的每个文件发送一系列HTTP GET请求。客户端可以将用于所需文件的HTTP GET请求流水线化。这些HTTP GET请求根据用于使用单个HTTP GET请求取回FDT的文件的实现进行格式化。

HTTP流水线化是这样的技术，其中多个HTTP请求被写出(writeout)至单个套接字，而不用等待相应的响应。流水线化仅在HTTP/1.1中支持。请求的流水线化减小了信令延迟，对于长等待时间的连接更是如此。因为通常可以将若干HTTP请求放入同一TCP分组中，所以HTTP流水线化允许在网络上发送少量的TCP分组，从而减小网络负载。备选地，可以发送将所有感兴趣文件的文件URI和对应的contentMD5包括在消息体中的HTTP POST请求。然而，HTTPPOST方法的使用仅在等幂服务(诸如，数据库的修改或者服务的订阅)的情况下推荐。

针对通过使用多个流水线化的或串行化的HTTP GET请求来取回FDT的文件的多个逻辑组，方法类似于用于通过使用多个流水线化的或串行化的HTTP GET请求来取回FDT的多个不相关文件的方法。然而，在此特定情况下，HTTP GET请求根据用于在单个HTTPGET请求中取回文件的逻辑组的实现进行格式化。

针对通过使用多个流水线化的或串行化的HTTP GET请求来取回多个不相关的文件和多个逻辑组的组合，方法类似于用于通过使用多个流水线化的或串行化的HTTP GET请求来取回FDT的多个不相关文件的方法。然而，在此特定情况下，HTTP GET请求根据用于在单个HTTP GET请求中取回文件的逻辑组或通过使用单个HTTP GET请求取回FDT的文件的实现进行格式化。

如果UE对来自FDT的不相关文件集合感兴趣，则其通过在HTTP GET请求中使用以下查询来指示此选择：

GET

/path/unicast_access？serviceID＝abc&fdtInstanceID＝def&fileURI＝x1&contentMD5＝y1&fileURI＝x2&contentMD5＝y2&fileURI＝x3&contentMD5＝y3&fdInstancdID＝ghi&fileURI＝m1&contentMD5＝n1&fileURI＝m2&contentMD5＝n2  HTTP/1.1

Host:bmsc.example.com

在以上示例中，MBMS UE正在请求来自FDT实例“def”的三个文件，即，x1、x2和x3，以及来自FDT实例“ghi”的两个文件，即，m1和m2。文件的相应contentMD5分别是y1、y2、y3、n1和n2。所有文件都属于MBMS用户服务“abc”。在这种情况下，BM-SC可以通过使用多方MIME结构发送来自FDT的所有文件来做出响应。

如果UE对FDT中文件的不止一个逻辑组感兴趣，则其通过在HTTP GET请求中使用以下查询来指示此选择：

GET    /path/unicast_access？

ServiceID＝abc&fdtInstanceID＝def&groupID＝x1&groupID＝x2&fdtInstanceID＝ghi&groupID＝x3.  HTTP/1.1

Host:bmsc.example.com

在以上示例中，MBMS UE正在请求来自FDT实例“def”的两个逻辑组，即，x1和x2，以及来自FDT实例“ghi”的一个逻辑组，即，x3。所有文件都属于MBMS用户服务“abc”。在这种情况下，BM-SC可以通过使用多方MIME结构发送来自FDT的所有被请求的文件来做出响应。

针对在单个HTTP GET请求中取回一个或多个文件与文件的一个或多个逻辑组的组合，用于此过程的实现类似于用于在单个HTTPGET请求中取回文件的多个逻辑组以及在单个HTTP GET请求中取回多个不相关文件的实现。

OMA PUSH消息用于将FDT实例递送至接收机。为了让接收机能够标识当前FDT实例涉及哪个服务(FLUTE会话)，需要对FLUTE会话的唯一标识符的指示。服务ID是这种标识符的一个示例。此标识符需要在每个Push消息中与FDT实例一起发送。Push消息[即，WAP-251-Push消息]包括消息报头和消息体。消息报头类似于HTTP消息报头，并且利用若干报头字段以文本表示给出。消息体可以包含由其内容类型所标识的任何数据类型。在各种实施方式中，有两种不同的方法可以用来在Push消息中用信令通知会话标识符。在第一方法中，“X-Wap-Content-URI”作为消息报头的报头字段可以用于此目的。此报头字段给出了当前内容的URI。此URI可以具有以下格式。

X-Wap-Content-URI＝”X-Wap-Content-URI:”namespace“？ServiceID＝”ServiceID[“&SessionID＝”SessionID]

namespace(命名空间)＝URI是已注册的命名空间，其可以例如是urn:3gpp:mbms:rel7:fdt-download形式。

用于信令会话标识符的第二个方法涉及使用Push消息的消息体。该消息体被设计为多方MIME消息，其包含两个不同部分。一个部分携带FDT实例，而另一部分携带服务ID和/或会话ID和任何其他信息。在第二方法中，XML结构用于消息的第二部分。

如果MBMS UE不需要MBMS用户服务的单播递送(例如，如果MBMS UE移动回MBMS覆盖区域，或者其对MBMS传输会话中的剩余内容不感兴趣)，则其可以针对MBMS下载服务的单播递送将自己从BM-SC解注册。解注册在图1中的170处示出。如果此解注册不发生，则BM-SC会继续将OMA Push消息(无论是否存在新的FDT实例)发送到MBMS UE，这会浪费之前的单播递送资源。因此，HTTP GET消息可以使用在某些实施方式中，用于将MBMSUE从BM-SC解注册以停止serviceID所标识MBMS下载服务的单播递送。GET/unicastDeReg？serviceId＝urn:3gpp:0010120123hotdog&MSISDN＝436642012345HTTP/1.1

Host:bmsc.example.com

图2是示出了根据各种实施方式，在MBMS UE、BM-SC和其他组件之间交互的图形描述。在图2的200处，MBMS UE的单播MBMS文件下载客户端将注册请求发射至BM-SC(解注册请求也从单播MBMS文件下载客户端发出)。在210处，由FDT实例ID标识的FDT实例和serviceID发送至PPG。在220处，PPG将OTA Push消息发送至OMA Push客户端。在230处，OMA Push客户端将应用ID发送至单播MBMS文件下载客户端。在240处，单播MBMS文件下载客户端将serviceID和由FDT实例ID标识的FDT实例转发至适当的MBMS文件下载服务的MBMS文件下载应用。在250处，由FDT实例ID标识的FDT实例被发送至FDT解析器。在260处，文件URI和FDT实例ID随后被发送至HTTP请求器，在270处，该HTTP请求器随后与单播文件递送服务器或文件修复服务器进行通信。

图3示出了可以使用各种实施方式的系统10，包括可以通过一个或多个网络进行通信的多个通信设备。系统10可以包括有线或无线网络的任意组合，其中这些网络包括但不限于移动电话网络、无线局域网(LAN)、蓝牙个人局域网、以太网LAN、令牌环LAN、广域网、互联网等。系统10可以包括有线通信设备和无线通信设备两者。

例如，图3中所示系统10包括移动电话网络11和互联网28。通往互联网28的连接可以包括但不限于远程无线连接、短程无线连接，以及各种有线连接，这些有线连接包括但不限于电话线、电缆线路、电力线等。

系统10的示例性通信设备可以包括但不限于移动电话形式的移动电子设备50、组合式个人数字助理PDA和移动电话14、PDA 16、集成消息传递设备(IMD)18、台式计算机20、笔记本计算机22等。通信设备可以是固定的或者在由行进中的人员携带时是移动的。通信设备还可以处于交通模式中，包括但不限于汽车、卡车、出租车、公共汽车、火车、船、飞机、自行车、摩托车等。通信设备的一些或全部可以通过通往基站24的无线连接25发送和接收呼叫和消息，并且通过通往基站24的无线连接25与服务提供商进行通信。基站24可以连接至网络服务器26，该服务器26支持移动电话网络11和互联网28之间的通信。系统10可以包括附加的通信设备和不同类型的通信设备。

通信设备可以使用各种传输技术进行通信，包括但不限于，码分多址(CDMA)、全球移动通信系统(GSM)、通用移动通信系统(UMTS)、时分多址(TDMA)、频分多址(FDMA)、传输控制协议/互联网协议(TCP/IP)、短消息传递服务(SMS)、多媒体消息传递服务(MMS)、电子邮件、即时消息传递服务(IMS)、蓝牙、IEEE 802.11等。在实现各种实施方式时涉及的通信设备可以使用各种介质进行通信，包括但不限于，无线电、红外、激光、线缆连接等。

图4和图5示出了可以在其中实现各种实施方式的一个代表性电子设备50。然而应当理解，无意将各种实施方式限制到一种特定类型的设备。图4和图5的电子设备50包括外壳30、液晶显示器形式的显示器32、小键盘34、麦克风36、耳机38、电池40、红外端口42、天线44、根据本发明一个实施例的UICC形式的智能卡46、读卡器48、无线电接口电路52、编解码电路54、控制器56以及存储器58。单独的电路和元件可以是本领域公知的所有类型，例如Nokia范围内的移动电话系列。

在方法步骤或过程的通常背景下对此处描述的各种实施方式进行了描述，在一个实施例中，这些方法步骤或过程可以通过程序产品来实现，该计算机程序产品包含在计算机可读介质中，其包括在网络环境中由计算机执行的计算机可执行指令，诸如程序代码。通常，程序模块包括例程、程序、对象、组件、数据结构等，用于执行具体任务或者实现特定的抽象数据类型。计算机可执行指令、相关数据结构和程序模块代表了用于执行此处公开的方法的步骤的程序代码的示例。这种可执行指令或者相关数据结构的特定顺序代表了用于实现在这种步骤或过程中描述的功能的对应动作的示例。

在上文实例中描述的各个和特定结构应当理解为构成用于执行以下权利要求中所描述的特定功能的装置的代表性结构，不过权利要求中的限制不应在未在其中使用术语“装置”的情况下解释为构成“装置加功能”限制。另外，以上说明书中对术语“步骤”的使用不应当用于把权利要求中的任何特定限制认为是构建“步骤加功能”限制。就在此描述或以其他方式提及的各个参考(包括授权的专利、专利申请和非专利公开物)来说，这种参考并不意在且不应当解释为对以下权利要求范围的限制。

本发明的软件和web实现能够利用标准编程技术来完成，利用基于规则的逻辑或者其他逻辑来实现各种数据库搜索步骤或过程、相关步骤或过程、比较步骤或过程和决策步骤或过程。还应当注意的是，此处以及以下权利要求中使用的词语“组件”和“模块”意在包括使用一行或者更多行软件代码的实现和/或硬件实现和/或用于接收手工输入的设备。

出于示例和描述的目的，已经给出了本发明实施的前述说明。前述说明并非是穷举性的也并非要将实施方式限制到所公开的确切形式，而且根据上述教导还可能存在各种变形和修改，或者是可能从各种实施方式的实践中得到各种变形和修改。选择和描述此处所讨论的这些实施方式是为了说明各种实施方式的原理及本质及其实际应用，以使得本领域的技术人员能够在各种实施方式中利用适合于所构思的特定用途的各种修改来利用本发明。