CN101073237B - 用于传送多媒体文件的方法 - Google Patents

Abstract

提供一种从始发方向接收方传送多媒体数据文件比如MMS的方法，所述始发方具有与其关联的始发方服务器，所述接收方具有与其关联的接收方服务器。该技术包括经由始发方服务器和接收方服务器建立从始发方到接收方的通信路径。接收方服务器接收从始发方上载到始发方服务器的数据文件或其各部分。此后，接收方服务器在不等待完整数据文件的接收的情况下单独转发从始发方服务器接收的数据文件部分。

Description

用于传送多媒体文件的方法

技术领域

本发明涉及通信。更具体而言，本发明涉及一种用于有效传送多媒体文件比如包含多媒体内容的多媒体消息传送服务的消息的技术。

背景技术

随着无线网络吞吐量的增加以及移动通信装置的完善，多媒体消息传送服务(MMS)型数据传送正在变得日益在用户中流行。然而，用于传送这种消息的当前技术是没有效率的，并且消耗不必要的网络资源，同时还导致传送和接收MMS的延迟。

对于常规系统，MMS通常从始发方网络部件被发送到与其关联的服务器或中继器，该服务器或中继器将多媒体消息转发给与接收方网络部件(或简单地为接收方)关联的服务器或中继器。接收方服务器然后把MMS通知给接收方，接收方从服务器检索内容。内容检索和读取答复由接收方确认，并且被返回到始发方服务器并最终返回到始发方网络节点。

图1提供一种信令图100，该图详述了关于使用常规技术进行MMS传送的在始发终端的始发方MMS用户代理(UA)110、始发方MMS中继器/服务器(或简短地为始发方MMS服务器)120、接收方MMS中继器/服务器(或简短地为接收方MMS服务器)130以及接收方终端的接收方MMS UA 140之间交换的信号。请求经由信号1A(例如MM1_submit.REQ)发出，以将MMS从始发方MMS UA 110传送给始发方MMS服务器130，该服务器130经由信号1B(例如MM1_submit.RES)答复。此后，始发方MMS服务器120经由信号1C(例如MM4_forward.REQ)把请求转发给接收方MMS服务器130，该服务器130通过信号1D(例如M4_forward.RES)答复。接收方MMS服务器130然后经由信号1E(例如MM1_notification.REQ)把该请求通知给接收方MMS UA 140，该接收方MMS UA 140通过信号1F(例如MM1_notification.RES)进行响应。

如果接收方MMS UA 140选择接受如在该请求中所提供的MMS的传送，则生成信号1G(例如MM1_retrieve.REQ)并将其发送给接收方MMS服务器130，然后响应经由信号1H(例如MM1_retrieve.RES)被送回给接收方MMS UA 140。接收方MMS UA140利用信号1I(例如MM1_acknowledgment.REQ)把内容检索确认发送给接收方MMS服务器130，该服务器130然后把报告有关内容的信号1J(例如MM4_delivery_report.REQ)发送给始发方MMS服务器120，该服务器120随后经由信号1K(例如MM4_delivery_report.RES)答复。始发方MMS服务器120然后向始发方MMS UA 110发送确认传送报告的信号1L(例如MM1_delivery_report.REQ)。接收方MMS UA 140还经由信号1M(例如MM1_read_reply_reiplent.REQ)发送读取答复确认，然后向始发方MMS服务器120发送报告有关内容的信号1N(例如MM4_delivery_report.REQ)，服务器120随后经由信号1K(例如MM4_delivery_report.REQ)答复。始发方MMS服务器120此后向始发方MMS UA 110发送读取答复确认信号1P(例如MM1_read_reply_originator.REQ)。

尽管MMS的流行性在增长，但是传送MMS所需的时间量可能过长。结合图2的信令图200显示传送延迟的一个原因，图2说明了在始发网络部件例如始发终端210、短消息传送服务中心220(SMS-C)、WAP代理230、推送代理网关240(PPG)以及始发多媒体消息传送中心(MMC)即始发方MMS中继器/服务器250之间的信令。始发终端210经由WAP代理230发送信号2A中的MMS，并向始发MMC 250发送信号2B。对于慢速网络接入，可能花费高达四十(40)秒把MMS内容完全上载到MMC 250。在完成上载之后，始发MMC 250经由信号2C和2D确认MMS的接收。始发方MMC 250然后将MMS转发给也确认MMS的接收的接收方MMS中继器/服务器(未示出)。

图3说明具有与图2类似部件的信令图300，但是与由接收方网络部件例如接收方终端对MMS的检索相关。从MMC即与接收方终端310关联的接收方MMS中继器/服务器350经由信号3A将推送接入协议消息发送给PPG 340，PPG 340经由信号3B确认该消息。从PPG 340把短消息对等协议消息3C发送给SMS-C 320，SMS-C 320随后经由信号3D将MMS通知给接收方终端310。接收方终端310然后可以发送一个通知以经由WAP代理330获得信号3E中MMS，并把信号3F发送给接收方MMC 350。MMC 350然后经由信号3G和3H把MMS下载到接收方终端。类似于MMS到始发方MMC 250的上载，从接收方MMC 350到接收方终端310的下载可能也花费高达四十(40)秒，这取决于网络的速度。

因此根据上述将认识到，MMS的传送基本上通过三个独立的阶段完成：

1.始发网络部件到始发方MMS中继器/服务器；

2.始发方MMS中继器/服务器到接收方MMS中继器/服务器；以及

3.接收方MMS中继器/服务器到接收方网络部件。

因此，使用常规技术的MMS传送不必要地过长(尤其是如果仅仅存在可用的低速网络接入的话)，并且导致消耗始发方和接收方MMS中继器/服务器中显著的缓冲器空间(其部分地基于大量的并行进行的传输)。这种延迟可以随着MMS大小的增加(例如在大的视频剪辑的情况下)而增加。

接收MMS的延迟消极地影响在接收方网络部件上的用户体验，并且可能阻止用户发送MMS(由此降低网络运营商的潜在吞吐量收入)。例如，在一些情况下，比如关于体育或新闻剪辑，用户可能急切等待MMS被完全加载。在其它情形下，用户可能知道MMS在途中，比如当用户也正在参加与始发用户的语音会话并且并行发送MMS(例如经由组合服务等等)时，以及用户可能知道传送的延迟会消极地影响与其它用户的交互。延迟在单个用户向所有参与者发送MMS的多用户组会话中也成问题。当接收参与者可能已经为多用户内容而注册时，他们被认为对内容接收是准备好的。

因此，仍然需要一种用于从始发方向接收方传送MMS或类似消息的改进的技术。

发明内容

本发明体现为一种从始发方向接收方传送多媒体数据文件比如MMS的方法，所述始发方具有与其关联的始发方服务器，所述接收方具有与其关联的接收方服务器。这种方法可以包括：经由始发方服务器和接收方服务器建立从始发方到接收方的通信路径。该方法还可以包括：由接收方服务器从始发方服务器接收数据文件的各部分(每个数据文件部分或完整数据文件从始发方被上载到始发方服务器)。此后，在不等待完整数据文件的接收的情况下，接收方服务器单独转发从始发方服务器接收的数据文件部分，以用于由接收方重组。

到接收方服务器以及也到接收方的通信路径可以在整个数据文件被上载到始发方服务器之前被建立。所以，接收方(或者处理数据文件的其内部部件，比如MMS用户代理)可以在最初已经是在线且可达的(例如在数据文件到始发方服务器的上载开始之前)。因而通过数据文件内容的同时上载、传播和下载，可以加速数据文件的传送。可选择地，可以以两个或更多个步骤来建立通信路径(例如在数据文件上载期间或者在数据文件被上载到始发方服务器之后)。

各个数据文件部分可以经由在数据文件传输时间建立的(半)永久通信路径直接转发给接收方。在许多情况下，建立到接收方的通信路径所必需的信息是最初可得到的(例如在数据文件内容或者其部分到始发方服务器的上载开始之前)。为了建立通信路径，可以执行协商(以便也商定用于数据文件传送的通信原则)。在这方面所交换的信息可以包括关于待传送的数据文件的大小的信息。正如可以认识到的，可以根据期望配置对该方法作出各种可选修改。例如，该方法还可以包括由接收方服务器接收数据文件被正确地重组的确认的步骤。另外或者作为选择，该方法还可包括以下步骤：由接收方服务器向始发方服务器或者由接收方向接收方服务器再向始发方服务器发送一个指示数据文件部分未被接收的消息。类似地，可以由接收方服务器向始发方服务器或者由接收方向接收方服务器再向始发方服务器发送消息，该消息指示数据文件部分已经被正确接收。

为了最小化经由无线网络的数据文件部分的传送，始发方服务器和接收方服务器中的至少一个可以高速缓存已接收的数据文件部分，以使如果相邻部件在数据业务流内没有正确接收这种数据文件部分，则可以快速重发该数据文件部分。

该方法还可以包括由始发方和始发方服务器中的至少一个把数据文件细分成数据文件部分的步骤。如果数据文件被始发方细分，则消耗更少的网络资源。结果，网络运营商可以根据数据文件是否被始发方或者被始发方服务器或某一其它网络部件细分来收取不同费用(尤其是如果始发方和接收方中的至少一个是移动通信装置的话)。在这方面，该方法还可包括以下步骤：基于由始发方服务器和接收方服务器中的至少一个所利用的处理能力的量，把记帐费用与数据文件的传送相关联。

该方法还可包括建立或协商用于从始发方到接收方传送数据文件的参数的多个步骤。对于该变化，该方法还可以包括以下步骤：由接收方服务器接收响应于来自始发方的请求而生成的来自始发方服务器的传送查询，该传送查询包含或涉及关于数据文件的传送的初始参数；由接收方服务器确定是否修改初始参数；由接收方服务器对传送查询发送包括或涉及最终参数的的响应，所述最终参数包括初始参数的接受或已修改参数；以及由接收方服务器接收根据最终参数所传送的数据文件，以用于向接收方传送。本领域技术人员还将认识到，可以结合上述的数据文件传送方法来利用以及分别利用这样的预传送协商，并且该协商技术还可以适用于其它通信情况。

与数据文件的传送有关的参数可以涉及各种因素，并且可以可选地从包括以下各项的组中进行选择：数据文件内容类型、数据文件内容大小、用于编码内容的编解码器、数据文件的部分的数量、每个数据文件部分的大小、数据文件部分的顺序编号、请求丢失的数据文件部分的过程、接收方的数量、以及所利用的确认协议。

为了最小化关于通信参数的建立所交换的信号或消息的数量，初始参数可以包含至少两种用于把数据文件传送给接收方的技术，并且响应可以包括所述至少两种不同技术之一的接受或者已修改参数。该方法还可提供：始发方从至少两个预定义的通信参数集中选择通信参数，并且这些集最终可以被转发给接收方服务器和/或接收方。

该方法还可提供始发方服务器存储该请求，并且它还可提供接收方服务器存储传送查询，例如在需要重传这种消息(或由此产生的消息)的情况下，或者在转码要被执行的情况下。

可以被包含在该方法中的附加步骤包括：由接收方服务器把传送查询转发给接收方；以及由接收方服务器对传送查询接收包括最终参数的响应。可选择地，当接收方服务器转发传送查询时，它可以根据预定的传送查许标准来修改该传送查询(再将其存储在数据库中)，并且把已修改的传送查询转发给接收方。作为选择，该方法可以包括以下步骤：由接收方服务器(而不是由接收方)基于预定的传送标准来生成对传送查询的响应。预定的传送标准可以包括接收方的已知能力。

而且，该方法还可包括以下步骤：由接收方或接收方服务器把所述响应转换成与始发方服务器和始发方中的至少一个兼容的格式。

在另一个实施例中，提供一种从始发方向接收方传送多媒体数据文件比如MMS的方法，所述始发方具有与其关联的始发方服务器，所述接收方具有与其关联的接收方服务器，该方法包括：经由始发方服务器和接收方服务器建立从始发方到接收方的通信路径。该方法还包括：由始发方服务器从始发方接收数据文件或数据文件的各部分，并且如果接收到数据文件，就把该数据文件分成多个数据文件部分；以及由始发方服务器在不等待完整数据文件的接收的情况下，单独转发从始发方接收的数据文件部分，以用于由接收方重组。

根据一个变型，始发方服务器和接收方服务器中的至少一个接收一个或多个数据文件部分，包括与数据文件有关的报头和控制信息中的至少一个。根据另一个变型，始发方服务器接收在单个消息中的数据文件以及报头和控制信息中的至少一个。这两种变型允许始发方服务器和/或接收方服务器立即开始处理报头和控制信息中的至少一个，而不用等待数据文件的完整接收。所以，始发方服务器和/或接收方服务器可以确定传输有关方面，象数据文件的接收方和/或在数据文件传输的非常早阶段的数据文件的长度。

事实上，中间节点比如始发方服务器和接收方服务器不需要关于数据文件内容的任何知识来开始它们专用的处理操作。因此，始发方服务器可以把与将由始发方服务器所转发的数据文件有关的信息通知给接收方服务器，同时始发方服务器仍然从始发方接收数据文件或数据文件部分。这一方面在始发方服务器与始发方之间以及另一方面在始发方服务器与接收方服务器之间产生了同时的或“交织的”(即不严格连续)消息传送过程。这种过程的优点在于这样的事实，即接收方服务器例如可以对于它将接收的数据文件分配资源和/或在非常早的阶段向接收方通知数据文件传输。

本发明还可体现为一种可以被存储在计算机可读记录介质上的计算机程序产品，该计算机程序产品包括程序代码部分，用于当计算机程序产品在一个或多个计算机或计算机系统上运行时执行在此所述的方法的步骤。

在又一个变型中，本发明体现为一种包括计算机处理器和与该处理器耦合的存储器的系统，其中利用一个或多个程序对存储器进行编码，所述程序执行在此所述的方法的步骤。

本发明还实现了一种经由建立的通信路径从始发方向接收方传送多媒体数据文件比如MMS的设备，所述始发方具有与其关联的始发方服务器。这样的设备可以包括：接收单元，用于从始发方服务器接收数据文件的各部分，所述数据文件或者数据文件的各部分从始发方被上载到始发方服务器；以及中继单元，用于单独转发从始发方服务器所接收的数据文件的各部分，以用于由接收方重组，其中在不等待完整数据文件的接收的情况下转发数据文件部分。

类似地，本发明还可包括一种经由建立的通信路径从始发方向接收方传送多媒体数据文件比如MMS的设备，所述接收方具有与其关联的接收方服务器。这样的设备可以包括：接收单元，用于从始发方接收数据文件或数据文件的各部分，并且如果接收到数据文件，就把数据文件分成多个数据文件部分；以及中继单元，用于单独转发从始发方所接收的数据文件部分，以用于由接收方重组，其中在不等待完整数据文件的接收的情况下转发数据文件部分。

在又一个实施例中，本发明采取经由建立的通信路径传送多媒体数据文件比如MMS的系统的形式。该系统包括：启动数据文件的传输的始发方用户代理；接收方用户代理；与始发方用户代理关联的始发方服务器；以及与接收方用户代理关联的接收方服务器。在操作中，始发方把数据文件或数据文件部分上载到始发方服务器，始发方服务器把数据文件的多个部分发送给接收方服务器，以及接收方服务器在不等待完整数据文件的接收的情况下把已接收的数据文件的部分单独转发给接收方以用于重组。

附图说明

在下文中将参考在附图中所说明的示例性实施例来描述本发明，其中：

图1是示出与多媒体数据文件的传送有关的技术的第一信令图；

图2是示出与多媒体数据文件的传送有关的技术的第二信令图；

图3是示出与多媒体数据文件的传送有关的技术的第三信令图；

图4是根据本发明的方法实施例的过程流程图；

图5是根据本发明的设备实施例的示意图；

图6是与对于理解和实施本发明有用的多媒体数据文件的传送启动有关的实例的信令图；

图7是与对于理解和实施本发明有用的多媒体数据文件的传送有关的实例的信令图；

图8是示出根据本发明的直接转发和通知过程的第一信令图；以及

图9是示出根据本发明的直接转发和通知过程的第二信令图。

具体实施方式

在后面的描述中，为了解释而非限制的目的，陈述了特定细节，比如特定信号格式等等，以便提供对本发明的彻底理解。对于本领域技术人员而言下述将是显而易见的：可以在背离这些特定细节的其它实施例中实行本发明。例如，本领域技术人员将会认识到，本发明可以结合多媒体数据文件类型以及其中需要更有效的数据传送的不同于MMS的消息传送服务来使用。

而且，本领域技术人员还将认识到，在下文所解释的功能可以被这样实施：使用单独的硬件电路，使用软件功能以及程控的微处理器或通用计算机，使用专用集成电路(ASIC)，和/或使用一个或多个数字信号处理器(DSP)。还将认识到，尽管本发明主要被描述为方法，但是它也可以体现为包括计算机处理器和与该处理器耦合的存储器的系统，其中利用可以执行在此所公开的方法的一个或多个程序来对存储器进行编码。

图4公开了用于从始发方(比如第一移动终端)到接收方(比如第二移动终端)传送数据文件比如MMS的方法400，所述始发方具有与其关联的始发方服务器，所述接收方具有与其关联的接收方服务器。该方法开始于步骤410，在此建立从始发方经由始发方服务器和接收方服务器到接收方的通信路径。在步骤420，由始发方服务器从始发方或者由接收方服务器从始发方服务器接收至少部分数据文件(从始发方上载到始发方服务器的)来继续该方法。此后，在步骤430，由始发方服务器或由接收方服务器在不等待完整数据文件的接收的情况下单独转发数据文件的已接收部分以用于由接收方重组(例如，基于可能与每个数据文件部分关联的序号)来继续该方法。

图5说明经由建立的通信路径从始发方到接收方传送多媒体数据文件比如MMS的设备500，所述始发方具有与其关联的始发方服务器。设备500包括两个主要部件：接收单元510，用于从始发方或者始发方服务器接收至少部分数据文件，该数据文件或者数据文件部分从始发方被上载到始发方服务器；以及中继单元520，用于单独转发从始发方或始发方服务器接收的数据文件的部分，以用于由接收方重组，其中在不等待完整数据文件的接收的情况下转发数据文件部分。

下面提供可以与在此所述的实施例可选地结合使用的的变化的实例，或者单独或者组合应用。尽管下面可能把网络部件描述为移动通信装置或移动单元，但是将认识到，上述也适用于各种各样的计算机网络部件，包括有线终端。

参考图6，提供了信令图600，其中信号在始发方MMS UA(用户代理)610、始发方MMS中继器/服务器620、接收方MMS中继器/服务器630以及接收方MMS UA 640之间交换，以作为在实际传送MMS之前进行的并且关于将从始发方MMS UA 610向接收方MMS UA 640传送MMS所用的参数的协商的部分。将会注意，如果期望的话，始发方MMS服务器620和接收方MMS服务器630可以被组合在相同的物理网络实体内。

经由信号6A(其可以是MMS_Comm.REQ信号)，始发方MMSUA 610向始发方MMS服务器620发送所建议的通信参数。这些通信参数可以包括各种通信原则，这些通信原则将规定MMS或其它多媒体文件从始发方MMS UA 610被最终传送到接收方MMS UA 640的方式。例如，所述参数可以包括：MMS内容类型和大小；用于编码多媒体文件(和/或潜在的内容)的编解码器；MMS内容部分的数量以及可选地每个数据文件部分的大小(其可能预先不知道，这取决于期望的配置)；每个数据文件部分的序号(除非标准化)；请求数据文件的丢失的部分的过程(除非标准化)；与在数据文件的每个部分之内潜在的内容有关的信息(其例如可以由接收方MMS UA 640使用以通知始发方MMS UA 610：数据文件的某些部分不需要被传送)；单个或多个用户数据文件传送；ACK/NACK是否将被用来(被动地)确认数据文件部分的正确接收，等等。而且，在一些变化中，始发方MMSUA 610还可以发送通信参数的若干选项(例如固定的传输模板)，以使接收方MMS服务器630和/或接收方MMS UA 640可以选择最佳的通信参数集。

从始发方MMS服务器620发送给接收方MMS服务器630的信号6B(其可以是MMC_Comm.REQ信号)转发所建议的通信参数(或者发送与通信参数或通信参数集关联的已修改消息信号)。可选地，始发方MMS服务器620还可以(例如在本地存储器或数据库中)存储与在信号6A内所包含的通信参数有关的信息。作为选择，信号6B可以仅仅包含对特定的预定义通信参数集的引用。

利用信号6C(其可以是MMS_Comm.REQ信号)，接收方MMS服务器630把所建议的通信参数(或与其有关的信息)转发给接收方MMS UA 640。接收方MMS服务器630还可以在发送信号6C之前可选地(例如在装入存储器或数据库中)存储在信号6B内所包含的信息。如果接收方MMS服务器630已经具有关于接收方MMS UA 640的能力的信息，则它可以可选地排除某些所建议的通信参数或者修改在信号6C内所发送的各个通信参数。

经由信号6D(其可以是隐含MM1_notification.RES指示符的MMS_Comm.RES信号)，接收方MMS UA 640(其可以可选地存储所建议的通信参数)把结果返回给信号6C的请求。该结果可以是简单的OK指示(意味着所建议的通信参数是可接受的)，或者作为选择，该结果可以包括所接受或所排除的参数的列表或者已修改参数的列表。这些排除或改变可以基于在接收方MMS UA 640内存在的定义的参数或限制。如果使用参数集，则可以交换简化的和更有效的信令。在简档信息被发送的情况下，该结果可以指示所选择的简档。

如图6中的虚线所示，根据期望的配置，可能不需要信号6C和6D。例如，接收方MMS服务器630可以访问或包括这样的数据库，该数据库包含与接收方MMS UA 640的能力或多媒体文件传送偏好有关的信息，因此避免了对信号6C和6D的需要。对于此安排，在包含数据文件部分的第一消息之前应该是MM1_notification.REQ消息和MM1_notification.RES消息。在现有的MMS规范中，这些消息被用来通知接收方存在可以检索的MMS内容。

接收方MMS服务器630经由信号6E把关于所建议的通信参数的响应返回给始发方MMS服务器620。在接收方MMS服务器630或接收方MMS UA 640已经修改(或减少)通信参数的那些情况下，接收方MMS服务器630可以安装变换器功能，并且仍然把未修改的通信参数返回给始发方MMS服务器620。这可以当在所建议的通信参数与接收侧所支持的通信参数之间存在不一致时进行。接收方MMS中继器/服务器630然后例如可以执行实际内容的编解码器变换、除去颜色(color)比特和/或执行类似操作。

始发方MMS服务器620然后经由信号6F把通信参数返回给始发方MMS UA 610。可选地，如果通信参数先前没有被接收方MMS服务器630变换，则始发方MMS服务器620可以安装变换器功能。

在数据文件被发送到多个接收方MMS UA的情况下，MMS_Comm.REQ信号则指示通信参数可能是固定的并且不能被改变(部分是由于这样的事实，即数据文件必须以统一的方式被传送，并且为多播或其它多用户会话或服务而注册时，接收方UA已经同意这种传送)。另外，接收方MMS UA可以不返回MMS_Comm.RES信号(因为这种信令可能使网络过载)。

图7提供信令图700，该图说明与MMS 8的传送有关的在始发方MMS UA 610、始发方MMS服务器620、接收方MMS服务器630以及接收方MMS UA 640之间的信号交换(并且可选地在参考图6所述的协商结束之后)。

接收方MMS UA 640可以把信号7A(比如MM1_retrieve.REQ信号)发送给接收方MMS服务器630，以启动从MMS中继服务器630检索数据文件部分(例如每当每个数据文件部分到达接收方MMS中继服务器630时)。经由信号7B(比如MM1_submit.REQ信号)，始发方MMS UA 610把数据文件部分上载到始发方MMS服务器620。此后，通过信号7C(比如MM4_forward.REQ信号)，始发方MMS服务器630直接(并且可选地一接收到它)把数据文件部分转发给接收方MMS UA 630。接着，经由信号7D(比如MM1_retrieve.RES信号)，接收方MMS UA 630直接(并且可选地一接收到它)把数据文件部分转发给接收方MMS UA 640。由信号7B(经由信号7E和7K)、7C(经由信号7F和7L)以及7D(经由7G和7M)所表示的信令序列可以被重复多次，直至接收方MMS UA 640接收到所有的数据文件部分。

将会注意，在信号7B和7C之前、期间或之后，可以发送信号7A。然而，数据文件部分到接收方MMS UA 640的传送(经由信号7D)在信号7A被接收到之前将不开始。在多用户服务的情况下，信号7A可能不被发送(并且可能使网络过载)，以及接收方MMS服务器630一接收到数据文件部分，就把它们传送给接收方MMS UA 640。

每个数据文件部分包括可以用来检测丢失的数据文件部分和/或用于重组目的的序号。如果始发方MMS服务器620、接收方MMS服务器630或接收方MMS UA 640检测到丢失的数据文件部分，则这样的部件因此通知它们在业务链中的对应部分(如由信号7H、7I、7J、7N、7O以及7P所示，所有这些信号由虚线表示)。为了最小化将由未正确接收的数据文件部分的重传所产生的任何进一步延迟和业务，始发方MMS服务器620和接收方MMS服务器630可以高速缓存数据文件部分，以便避免这种数据文件部分经由无线网络被再次上载。

另外或者作为选择，为了监视NACK消息(指示存在丢失的数据文件部分)，还有可能使用ACK消息来确认相应数据文件部分的正确接收。数据文件部分被高速缓存在始发方MMS服务器620和接收方MMS服务器630内的这种安排在具有多个接收方MMS UA和还具有多个接收方MMS服务器的情况中会特别有用，所以对接收方MMS UA640的传输故障不需要经由无线网络的附加上载。

而且，在一些变化中，来自始发方MMS服务器620、接收方MMS服务器630和接收方MMS UA 640中任何一个的信号可以被最终发送给始发方MMS UA 610，指示某一数据文件部分(或者其分部)不需要被传送。这可能是例如当通信参数包括关于不同MMS部分的内容的信息时的情况。接收方然后可以决定不是所有的内容部分都被实际需要或想要。假定例如MMS包括报尾加视频/音频内容。在这种情况下，接收方可以指示只想要报尾。在另一情况下，MMS可以包括slights、视频内容加音频内容。接收方然后可以指示仅仅想要slights和音频内容(即不需要传送视频内容)。

返回到图7的信令图700，接收方MMS UA 640经由信号7Q向接收方MMS服务器630确认完整数据文件部分的正确接收，该服务器630经由信号7R把该确认转发给始发方MMS服务器620，该服务器620经由信号7S进行确认，并随后经由7T转发给始发方MMS UA610。

可选地，接收方MMS UA 640还可以经由信号7U把读取答复报告发送给接收方服务器630，该服务器630利用信号7V把读取答复报告转发给始发方MMS服务器620，该服务器620经由信号7W进行确认，并经由信号7X将其转发给始发方MMS UA 610。读取答复报告还可包含各种信息，比如何时读取数据文件部分，访问数据文件部分多久，等等。

可选实施例的目的是最小化对发送方和接收方的终端影响。基本思想是，始发方MMS中继器/服务器(即始发方MMSC)一可以确定接收方MMS用户代理以及因而确定接收方MMS中继器/服务器，就开始转发和通知过程。在第一变型中，在始发MMSC接收到MM1_submit.REQ消息之后立即开始的分析。在第二变型中，两个新交互被引入，以从消息内容分别上载消息报头。

在这两种变型背后的思想是，中间节点不需要知道完全的MMS内容。中间节点仅仅需要报头和控制信息，并且也许还是标志，该标志指示实际MMS内容以“流”方式被传送。这还意味着为了MMS传送而改变端到端的消息序列。接口(例如MM1或MM4)上的序列不必受到影响。

图8说明了用于逐级MMS传送的已修改信令图的第一变型。在MM1和MM4接口上的序列被“交织”，这允许从始发方到接收方的MMS的传送快得多。

始发方MMS用户代理810“照常”向始发方MMSC 820发送MMS(包括报头和控制信息)。这里，始发方MMSC 820一接收到MMS报头和控制信息，就开始处理并估计MMS报头和控制信息(估计已经接收的部分不必等待MMS传输结束)。可选地，“报头长度”字段对MM1消息8A进行扩展。该字段将允许始发方和接收方MMSC 820、830在尝试提取和处理报头之前，首先对已接收字节进行计数。

当始发方MMSC 820已经接收到MMS报头和控制信息时，始发方MMSC 820立即分析报头并确定接收方MMSC 830。始发方MMSC820使用MM4_forward.REQ消息8B来向接收方MMSC 830发送MMS报头。在始发方与接收方MMSC 820、830之间的通信链路对于实际MMS内容保持开放。可选择地，始发方MMSC 820保持整个MMS(报头和内容)的副本以用于故障操作，直至它从接收方MMSC接收到MM4_forward.RES消息。

在该过程之前，始发方MMSC 820确定接收方MMSC 830的能力。存在若干方式来确定接收方MMSC 830所支持的能力。这里假设，始发方MMSC 820知道接收方MMSC 830的能力。

可选地，MMS内容长度字段对MM4消息进行扩展。这主要用于监视目的，因为在始发方和接收方MMSC 720、830之间所用的协议是可靠的。

接收方MMSC 830首先接收用于输入MMS的报头和控制信息(例如，在初始MMS部分中，该初始MMS部分由始发方MMSC 820通过把MMS分成单独转发给接收方MMSC 830的多个MMS部分中而生成)。在从始发方MMSC 820接收到整个MMS之前，它分配用于输入MMS的文件名。文件名的URL在通知消息8C中被转发给接收方MMS用户代理840(考虑了用于存储输入MMS的标准过程)。接收方MMSC 830开始该通知过程，并将SMS与MMS的URL一起发送给接收方用户代理840，尽管整个MMS内容在接收方MMSC 830中还不可用。

在接收方终端在线并且可用于接收输入MMS的情况下，接收MMS用户代理840开始检索过程，并且使用MM1_retrieve.REQ消息8E联系接收方MMSC 830。接收方MMSC 830利用MM1_retrieve.REQ消息8E进行回答，尽管它还没有完全的MMS内容(很可能接收方MMSC 830已经接收MMS内容的更多部分，因为通知过程花费一些时间)。在已经把MMS内容传送给接收方MMS用户代理840时，接收方MMSC 830正在从始发方MMSC 820接收MMS内容。由于MM1链路经常比MM4链路慢，因此接收方MMSC 830将具有足够的信息来发送给接收方MMS用户代理840。

当已经从始发方MMSC 820接收到完全MMS内容时，接收方MMSC 830利用MM4_forward.RES消息8H进行响应。

该实施方式的优点是不修改在MM1接口中的现有过程。仅仅需要基础设施更新来改进该系统的对等发送性能。

图9所示的第二变型主要遵循图8的第一变型。唯一的区别是引入了转发报头信息的新过程。该过程被用来转发MMS报头和控制信息(之一或二者)(例如在初始MMS部分中，该初始MMS部分之后是包含实际MMS内容的后续MMS部分)。这允许网络节点在处理它之前首先完全接收该传输。

该过程还被用来确定下一节点的能力(例如始发和接收方MMSC920、930)。在节点对出错消息(或者根本不)进行反应的情况下，发送器可以后退到标准过程。

在图9中描绘了第二变型的信令图。MM1_header.[REQ |RES]消息9A、9B和MM4_header.[REQ|RES]消息9C、9D是新引入的消息，仅仅来转发MMS报头和控制信息。始发方MMSC 920处理该消息，并利用MM4-报头消息建立到接收方MMSC 930的通信路径。两个MMSC 920、930保持处理和转发实际MMS传输(可选地仅仅MMS内容)的状态信息。

接收方MMSC 930一接收到MM4_header.REQ消息9C，就可以开始该通知过程。通知消息包含仍然为空的文件的URL。应当注意，由于MM1_notification过程的持续时间，文件可能已经包含MMS内容的部分。

当接收方MMS用户代理940在线并且可用来接收输入MMS时，它开始MM1检索过程以取出内容。在最佳情形下(当接收方940也在线时)，接收方940在始发方910仍然发送时将接收MMS。

在MMS从一个服务器被发送到一个或几个接收方MMS UA的情形下，本发明也是有益的，因为MMS传送的终结部分在该情况下仍然是最佳的。

本发明提供优于用于传送多媒体数据文件的常规技术的许多优点，例如更快的传送(接近实时)、降低的网络和终端缓冲器的平均占用、以及降低的处理能力要求。另外，原则上关于MMS的(最大)尺寸没有限制。而且，由于在此所述的技术提供更有效的数据传送，因此网络运营商可以例如通过收取较低费用来向始发方UA提供在传送之前细分多媒体数据文件的激励。

尽管已经就特定实施例(包括某些系统安排和各种方法内的某些步骤顺序)描述了本发明，但是本领域技术人员将认识到，本发明不限于在此所描述和所说明的特定实施例。例如，将会认识到，本发明可以被用来从第一网络部件(比如始发方用户代理)向第二网络部件(比如接收方用户代理)传送任何类型的数据文件。还将理解，把多媒体数据文件细分成各部分可以发生在接收方MMS服务器而不是始发方MMS服务器中，或者甚至通过WAP网关发生(假设在数据文件部分之一中提供一个指示)。而且，可以认识到，在实行本发明时，还可能涉及在图2和图3中所示的各个部件。

因此，尽管已经关于本发明的优选实施例描述了本发明，但是应当理解，该公开仅仅是说明性的。所以，本发明打算仅仅由附于此的权利要求书的范围来限定。

Claims (24)

1.一种从始发方(110)向接收方(140)传送多媒体数据文件的方法，所述始发方具有与其关联的始发方服务器(120)，所述接收方具有与其关联的接收方服务器(130)，所述方法包括以下步骤：

经由始发方服务器(120)和接收方服务器(130)建立从始发方(110)到接收方(140)的通信路径；

由接收方服务器(130)从始发方服务器(120)接收数据文件的各部分，所述数据文件或数据文件部分从始发方(110)被上载到始发方服务器(120)；以及

由接收方服务器(130)在不等待完整数据文件的接收的情况下单独转发从始发方服务器(120)所接收的数据文件部分，以用于由接收方(140)重组。

2.权利要求1所述的方法，还包括以下步骤：由接收方服务器(130)接收数据文件被正确地重组的确认。

3.权利要求1或2所述的方法，还包括以下步骤：由接收方(140)向接收方服务器(130)和/或由接收方服务器(130)向始发方服务器(120)发送指示数据文件部分未被接收的消息。

4.在前权利要求中任何一项所述的方法，还包括以下步骤：由接收方(140)向接收方服务器(130)或者由接收方服务器(130)向始发方服务器(120)发送指示数据文件部分已经被正确地接收的消息。

5.在前权利要求中任何一项所述的方法，还包括以下步骤：由始发方服务器(120)和接收方服务器(130)中的至少一个高速缓存所接收的数据文件部分。

6.在前权利要求中任何一项所述的方法，还包括以下步骤：由始发方(110)和始发方服务器(120)中的至少一个把数据文件细分成有序的数据文件部分。

7.在前权利要求中任何一项所述的方法，还包括以下步骤：基于由始发方服务器(120)和接收方服务器(130)中的至少一个所利用的处理能力的量，把记帐费用与数据文件的传送相关联。

8.在前权利要求中任何一项所述的方法，还包括以下初始步骤：

由接收方服务器(130)接收响应于来自始发方(110)的请求而生成的来自始发方服务器(120)的传送查询，该传送查询包含或涉及关于数据文件的传送的初始参数；

由接收方服务器(130)确定是否修改初始参数；

由接收方服务器(130)向始发方服务器(120)发送对传送查询包括或涉及最终参数的响应，所述最终参数包括初始参数的接受或已修改参数；以及

由接收方服务器(130)接收根据最终参数所传送的数据文件，以用于向接收方(140)传送。

9.权利要求8所述的方法，其中从包括以下各项的组中选择参数：数据文件内容类型、数据文件内容大小、用于编码内容的编解码器、数据文件的部分的数量、每个数据文件部分的大小、数据文件部分的顺序编号、请求丢失的数据文件部分的过程、接收方的数量、以及所利用的确认协议。

10.权利要求8或9所述的方法，其中初始参数包含至少两种用于把数据文件传送给接收方的不同技术，并且响应包括所述至少两种不同技术之一的接受或已修改参数。

11.权利要求8至10中任何一项所述的方法，其中始发方服务器(120)存储该请求。

12.权利要求8至11中任何一项所述的方法，其中接收方服务器(130)存储该传送查询。

13.权利要求8至12中任何一项所述的方法，其中始发方(110)从至少两个预定义的通信参数集中选择通信参数。

14.权利要求8至13中任何一项所述的方法，还包括以下步骤：

由接收方服务器(130)把传送查询转发给接收方(140)；以及

由接收方服务器(130)从接收方(140)接收对传送查询的响应，该响应包括最终参数。

15.权利要求8至14中任何一项所述的方法，其中接收方服务器(130)根据预定传送查询标准来修改传送查询，并把已修改的传送查询转发给接收方。

16.权利要求8至15中任何一项所述的方法，还包括以下步骤：由接收方服务器(130)基于预定传送标准来对传送查询生成响应。

17.权利要求8至16中任何一项所述的方法，还包括以下步骤：把所述响应转换成与始发方服务器(120)和始发方(110)中的至少一个兼容的格式。

18.一种从始发方(110)向接收方(140)传送多媒体数据文件的方法，所述始发方具有与其关联的始发方服务器(120)，所述接收方具有与其关联的接收方服务器(130)，所述方法包括以下步骤：

经由始发方服务器(120)和接收方服务器(130)建立从始发方(110)到接收方(140)的通信路径；

由始发方服务器(120)从始发方(110)接收数据文件或数据文件的各部分，并且如果收到数据文件，就把该数据文件分成多个数据文件部分；

由始发方服务器(120)在不等待完整数据文件的接收的情况下单独转发从始发方(110)接收的数据文件部分，以用于由接收方(140)重组。

19.权利要求18所述的方法，还包括：由始发方服务器(120)和接收方服务器(130)中的至少一个接收一个或多个数据文件部分，所述数据文件部分包括与该数据文件有关的报头和控制信息中的至少一个。

20.权利要求18所述的方法，还包括：由始发方服务器(120)从始发方(110)接收在单个消息中的数据文件以及报头和控制信息中的至少一个。

21.权利要求19或20所述的方法，还包括在不等待数据文件的完整接收的情况下，立即开始由始发方服务器(120)和接收方服务器(130)中的至少一个处理报头和控制信息中的至少一个。

22.一种经由建立的通信路径从始发方(110)到接收方(140)传送多媒体数据文件的设备，所述始发方具有与其关联的始发方服务器(120)，所述设备包括：

接收单元(510)，用于从始发方服务器(120)接收数据文件的各部分，所述数据文件或者数据文件部分从始发方(110)被上载到始发方服务器(120)；以及

中继单元(520)，用于单独转发从始发方服务器(120)接收的数据文件部分以用于由接收方(140)重组，其中在不等待完整数据文件的接收的情况下转发数据文件部分。

23.一种经由建立的通信路径从始发方(110)到接收方(140)传送多媒体数据文件的设备，所述接收方具有与其关联的接收方服务器(130)，所述设备包括：

接收单元(510)，用于从始发方(110)接收数据文件或数据文件的各部分，并且如果数据文件被接收，就把该数据文件分成多个数据文件部分；以及

中继单元(520)，用于单独转发从始发方(110)接收的数据文件部分以用于由接收方(140)重组，其中在不等待完整数据文件的接收的情况下转发数据文件部分。

24.一种经由建立的通信路径传送多媒体数据文件的系统，该系统包括：

用于启动数据文件的传输的始发方用户代理(610)；

接收方用户代理(640)；

与始发方用户代理(610)关联的始发方服务器(620)；

与接收方用户代理(640)关联的接收方服务器(630)；

其中始发方(610)把数据文件或其各部分上载到始发方服务器(620)；

其中始发方服务器(620)把数据文件的多个部分发送给接收方服务器(630)；以及

其中接收方服务器(630)在不等待完整数据文件的接收的情况下把已接收的数据文件部分单独转发给接收方(640)以用于重组。

Images