CN1934825A - 通过通信协议传送广播/多播会话的参数 - Google Patents
通过通信协议传送广播/多播会话的参数 Download PDFInfo
- Publication number
- CN1934825A CN1934825A CNA200580009100XA CN200580009100A CN1934825A CN 1934825 A CN1934825 A CN 1934825A CN A200580009100X A CNA200580009100X A CN A200580009100XA CN 200580009100 A CN200580009100 A CN 200580009100A CN 1934825 A CN1934825 A CN 1934825A
- Authority
- CN
- China
- Prior art keywords
- session
- receiver
- attribute
- receivers
- public data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明涉及在一个传输会话内从一个发送器(902)向多个接收器(901)传输公用数据的方法、计算机程序、计算机程序产品、系统、发送器、接收器和会话描述协议,包括:通过通信协议,向所述多个接收器(901)传送(802)与所述传输会话内的所述公用数据的所述传输有关的至少一个会话参数;以及在所述传输会话内从所述发送器(902)向所述多个接收器(901)传输所述公用数据。本发明特别涉及有线和/或无线网络中的公用数据的广播/多播传输,其中使用了单向传输上的文件交付FLUTE协议。
Description
技术领域
本发明涉及用于在一个传输会话内从一个发送器向多个接收器传输公用数据的方法、计算机程序、计算机程序产品、系统、发送器、接收器以及协议。
背景技术
广播/多播业务是旨在提供用于从一个发送器向多个接收器发送公用(相同)信息的灵活的、高效的机制的业务。
在无线通信系统的上下文中,如由第三代伙伴项目(3GPP)所标准化的,多媒体广播/多播业务(MBMS)使用在通用移动电信系统(UMTS)中。
在3GPP MBMS中,该广播业务描述从单一信源实体(发送方)到一个或多个广播区域内的所有用户(接收方)的多媒体数据(如文本、音频、图片、视频)的单向点对多点传输。该广播方式意在有效地使用无线/网络资源,举例来说,数据是通过公用无线信道传输的。数据被传输到该网络定义的广播区域上。
用户接收的广播业务可能包括一个或多个连续广播会话。例如,一个广播业务可以由单一正在进行的会话(如一个媒体流)组成,或者包括在一延长时限内的几个断续会话(如消息)。
使用广播方式的业务的一个例子是广告或网络的欢迎信息。由于并非与该网络相连的所有用户都希望接收此类信息,所以用户能够在他的用户设备(UE)上启用/禁用这些广播业务的接收。
广播方式与多播方式的区别是,不具体要求启动或预订广播方式中的MBMS。
3GPP MBMS的多播方式允许从单一信源点到多播区域内的多播组的多媒体数据(如文本、音频、图片、视频)的单向点对多点传输。多播方式意在有效地使用无线/网络资源,例如,数据是通过公用无线信道传输的。如该网络所定义的,数据被传输到多播区域。在多播方式中,对于该网络有可能有选择地传输到包含多播组的成员的多播区域内的小区。
UE接收的多播业务可能包括一个或多个连续多播会话。例如,一个多播业务可以或者由单一正在进行的会话(如一个多媒体流)组成,或者包括在一延长时限上的多个断续多媒体会话(如消息)。使用多播方式的业务的一个例子可以是需要进行预订的足球结果业务。
不同于广播方式,多播方式通常需要预订多播预订组,然后用户加入相应的多播组。可以由公用陆地移动网络(PLMN)运营商、用户或代表他们的第三方(如公司)进行预订和组加入。
作为可以从因特网工程任务组(IETF)获得的因特网草案(http://www.ietf.org/internet-drafts/),单向传输上的文件交付(FLUTE)协议代表用于在基于IP(因特网协议)的网络上的文件的单向交付的协议,基于IP的网络特别适合于多播网络,其中把公用数据从一个基于IP的实体发送到多个基于IP的主机。FLUTE规范构建在异步分层编码(ALC)协议上,该协议是为大量可升级的多播分发而设计的基础协议。通过使用时长为几秒钟或更长的交付会话,FLUTE适合向许多基于IP的主机交付大文件和小文件。例如,FLUTE还用来同时向许多基于IP的主机交付大量软件更新。它也可以用于分段而连续的数据,如用于字幕的带有时间线的文本。
然而,当试图使FLUTE协议的业务(向基于IP的主机提供的业务)对于3GPP MBMS可用时,为了允许处在无线通信系统中的移动接收器访问最初位于基于IP的网络中的广播/多播内容,会造成以下问题,移动接收器无法获得建立广播/多播会话所需的多个参数,其中至少部分地在FLUTE协议的控制下,部分通过基于IP的网络,部分通过无线网络,把公用内容从位于基于IP的网络内的信源实体传输到所述接收器。例如,当前不可能向移动接收器提供与前向纠错(FEC)有关的信息,与广播/多播会话期间内容损坏的情况下的数据修复能力有关的信息,与拥塞控制有关的信息,与多个信道的使用的信息以及FLUTE协议使用的内容描述有关的信息,从而造成以下事实,在广播/多播传输路径的两端均无法执行上述功能性。
发明内容
基于在无线通信系统中的IP发起的公用内容到移动接收器的广播/多播方式传输的具体上下文中遇到的问题,除别的目的以外,本发明的一般目的是,提供允许向多个接收器传送与在传输会话内的从发送器到多个接收器的公用数据的传输有关的参数的方法、计算机程序、计算机程序产品、系统、发送器、接收器和协议。
提出了在传输会话内从一个发送器向多个接收器传输公用数据的方法,该方法包括:通过通信协议,向所述多个接收器传送与所述传输会话内的所述公用数据的所述传输有关的至少一个会话参数;以及在所述传输会话内从所述发送器向所述多个接收器传输所述公用数据。
所述公用数据可以包括可以用电子形式表示的任何种类的信息,如文本、音频、图像和视频。所述公用数据可以是采用同步方式从所述发送器连续传输到所述多个接收器的流传输数据,或者是非流传输数据。所述数据是公用的,亦即,采用点对多点方式把相同数据传输到所述多个接收器的每个接收器。所述公用数据的所述传输可以在有线(wire-bound)网络中,或者在无线网络中,或在其组合中进行。因此,发送器例如可以是因特网服务器,接收器可以为基于IP的主机。同样,所述接收器也可以是无线网络中的移动接收器。所述接收器可以是相同类型的或不同类型的。所述公用数据的所述传输在可以在有限持续时间的传输会话内进行。
所述至少一个会话参数与所述传输会话内的所述公用数据的所述传输有关。所述至少一个会话参数可以例如描述用于所述公用数据的所述传输的错误防护、信道编码、调制和/或交织。所述至少一个会话参数可以同样包括与加在该接收器上的延迟或存储限制有关的信息、与公用数据的内容有关的信息、与拥塞控制有关的信息、与错误恢复有关的信息、或任何其它与所述公用数据的正确传输和接收有关的主题有关的信息。例如,如果一个或几个接收器没有正确接收到所述公用数据,因而不得不在修复会话内至少部分地重传公用数据时,在所述公用数据的所述传输之后可能需要的与修复会话有关的信息可以包含在所述至少一个会话参数中。
所述至少一个会话参数是通过通信协议传送到所述多个接收器的。所述通信协议可以例如为会话描述协议(SDP),文件传输协议(FTP),超文本传输协议(HTTP),短消息业务(SMS),通用分组无线业务(GPRS)或类似协议。例如,可以在不同端的通信协议实体之间交换的协议数据单位中传送所述至少一个会话参数,其中一端可以是发送器,而另一端可以是所述多个接收器中的一个接收器。所述通信协议可以是为所述至少一个会话参数的传送而特别指定或定义的。
向所述多个接收器传送所述会话参数的所述通信协议的部署可以为所述接收器提供与所述传输会话有关的信息,该信息对所述传输会话的正确运行是至关重要的。
根据本发明的方法,所述至少一个会话参数优选地是在建立所述传输会话之前或在建立所述传输会话期间传送到所述多个接收器的。然后,及早给接收器提供所述至少一个会话参数,该会话参数与所述传输会话内的所述公用数据的所述后续传输有关,以便所述多个接收器可以正确接收所述公用数据。
根据本发明的方法,所述通信协议优选地为会话描述协议(SDP)。
所述SDP旨在描述用于会话通告、会话邀请和其它形式的多媒体会话发起目的的多媒体会话。
所述SDP提供用于媒体细节的描述、传送地址和其它会话描述元数据的标准表示,这些元数据在发起多媒体电话会议、通过IP的语音(VoIP)呼叫、流传输视频或其它实时会话时是所需要的。在实际多媒体会话发生之前,可以把所述SDP提供的所述会话描述元数据运送到多媒体会话的参与者。所述SDP可以独立于传送信息所用的实际方式。所述SDP可以仅仅是不包括传送协议的用于会话描述的格式,目的是使用不同的合适的传送协议,例如包括会话通告协议(SAP),会话发起协议(SIP),实时流传输协议(RTSP),或超文本传输协议(HTTP)。所述SDP旨在是通用的,从而可以在广泛范围的网络环境和应用中使用。所述SDP可以例如是由所述发送器中的SDP协议实体(或诸如内容服务器之类的另一个实例)和所述多个接收器中的SDP协议实体操作的。
所述SDP可以是例如因特网工程任务组(IETF)定义的SDP。
所述至少一个会话参数是通过所述SDP传送到所述多个接收器的。例如,可以用所述SDP定义的多个属性字段实现上述处理,其中每个属性字段能够合并一个或多个会话参数的信息。
根据本发明的方法,所述公用数据优选地是至少部分地通过基于IP的网络从所述发送器传输到所述多个接收器的。例如,所述发送器可以是因特网服务器或因特网内的类似实例,并且所述接收器可以是其核心网络与因特网相连进而与所述发送器相连的无线通信系统的移动接收器。
根据本发明的方法,所述公用数据优选地是以广播或多播操作从所述发送器传输到所述多个接收器的。无论如何,点对多点操作总会发生。
根据本发明的方法,所述公用数据优选地是流传输数据或非流传输数据。流传输数据的特征可能在于其作为以流传输视频或音频的形式,从所述发送器向所述多个接收器连续地且以同步方式传输的数据。
根据本发明的方法,所述公用数据优选地是实时数据或非实时数据。
根据本发明的方法,所述公用数据优选地是至少部分地通过无线网络从所述发送器传输到所述多个接收器的。例如,所述接收器可以是与驻留在基于IP的网络上的发送器相连的无线通信网络中的移动接收器。所述无线网络可以例如是符合通用移动电信系统(UMTS)标准的移动无线通信网络,或者是诸如IEEE 802.11或HiperLAN/2的无线局域网(W-LAN),抑或是基于卫星的网络。
根据本发明的方法,所述无线网络优选地是移动网络,该移动网络至少部分地实现如第三代伙伴项目3GPP定义的多媒体广播/多播业务MBMS。
根据本发明的方法,所述通信协议优选地包含前向纠错(FEC)属性,该属性指定至少FEC编码方案,该编码方案用于所述传输会话内的所述公用数据的所述传输。
所述通信协议中包含的所述属性可以是用于扩展所述通信协议的主要方法,并且可以被定义为用作“会话级”或“媒体级”属性,或二者。所述属性可以添加有关媒体流的信息。此外,它也可以运送作为整体应用于所述传输会话而非应用于个别媒体的附加信息。属性可以或者是性质属性,或者是值属性。
所述FEC属性指定的所述FEC编码方案可以例如是自动重复请求(ARQ)方案。
根据本发明的方法,所述FEC属性优选地进一步指定FEC编码标识符。所述FEC编码标识符可以包含关于FEC解码矩阵或FEC字节码的信息。
根据本发明的方法,所述通信协议优选地包含FEC机器属性,该属性指定可以下载FEC解码信息的位置。
根据本发明的方法,所述多个接收器中的至少一个接收器优选地以无差错的方式从所述位置下载诸如FEC解码矩阵或FEC字节码的所述FEC解码信息。
根据本发明的方法,所述多个接收器中的至少一个接收器优选地使用基于超文本传输协议(HTTP)或传输控制协议(TCP)的点对点连接来下载所述FEC解码信息。
根据本发明的方法,所述多个接收器中的至少一个接收器优选地使用时间分散函数来确定何时开始从所述位置下载所述FEC解码信息,或者确定何时开始修复会话。该时间分散函数可以例如通过规定用于所述下载的随机开始时间来减少可能同时尝试从所述位置下载所述FEC信息或可能同时尝试执行修复会话的接收器的数目。
根据本发明的方法,所述通信协议优选地包含FEC缓冲属性,该属性指定在所述传输会话内从所述发送器向所述多个接收器传输所述公用数据期间强加在所述多个接收器上的缓冲需求。
根据本发明的方法,所述缓冲需求优选地为缓冲延迟和/或缓冲存储容量。
根据本发明的方法,所述通信协议优选地包含拥塞控制属性,该属性指定所述传输会话内所述公用数据的所述传输使用的拥塞控制方案。
根据本发明的方法,当所述多个接收器中的至少一个接收器没有正确接收到所述公用数据时,优选地在修复会话内从修复服务器向所述至少一个接收器传输所述公用数据的至少一部分。
根据本发明的方法,所述多个接收器中的所述至少一个接收器优选地使用时间分散函数来确定何时开始所述修复会话。
根据本发明的方法,所述修复会话优选地为点对点或点对多点修复会话。
根据本发明的方法,所述通信协议优选地包含修复统一资源标识符URI属性,该属性指定所述修复服务器的URI。
根据本发明的方法,所述通信协议优选地包含修复阈值属性,该属性指定错误阈值,并且所述错误阈值与所述传输会话内所述公用数据由所述多个接收器从所述发送器那里接收时的接收质量有关。例如,所述错误阈值可以量化每分组或每次的比特错误的最大允许数。
根据本发明的方法,所述多个接收器中的一个接收器是否进入所述修复会话优选地取决于在所述传输会话内所述公用数据由所述接收器从所述发送器那里接收时的接收质量和所述错误阈值之间的相互关系。例如,如果所述接收器在所述传输会话期间以300秒的窗口中10个字节的错误来接收所述公用数据,并且如果所述错误阈值规定只有300秒的窗口中达到1个字节的错误时才允许起动修复会话,则所述接收器可能被禁止进入所述修复会话。
根据本发明的方法,优选地按照错误单位、错误值、测量窗口单位和测量窗口值对所述错误阈值进行量化。所述错误单位可以例如是字节、比特、分组或百分比,所述错误值可以是实值的数,所述窗口单位可以例如是秒、分组、比特或字节,并且所述窗口值可以是实值的数。按上述方式量化的错误阈值的一个示例是,在300秒的窗口中有10个错误字节或类似组合。
根据本发明的方法,所述错误阈值优选地是按照错误值进行量化的。也可以用实值的错误值(如0.01)来指定所述错误阈值。例如,可以预先定义错误单位,测量窗口单位和测量窗口值。
根据本发明的方法,对于所述传输会话优选地使用多个错误阈值,其中明确地或隐含地标记所述错误阈值。例如,可以用整数来明确地标记所述错误阈值,从而可以区分第一、第二等的错误阈值。同样,可以固有地标记所述错误阈值,例如,规定按照错误阈值的大小对错误阈值进行排序,然后从最小或最大的错误阈值开始按照升序(或者可选地按照降序)进行标记。当支持不同补偿模式并且当每个错误阈值与各补偿模式相对应时,标记错误阈值特别有利,其中补偿模式可以例如描述接收器在对于修复会话的请求开始前需要等待多长时间。可以根据接收错误的大小控制接收器进入修复会话,因此例如,具有大的接收错误的接收器最先或最后进入所述修复会话。
根据本发明的方法,所述通信协议优选地包含补偿模式属性,该属性提供与在所述传输会话内没有从所述发送器正确接收到所述公用数据的接收器何时可以开始对于所述修复会话的请求有关的信息。
根据本发明,所述通信协议优选地包含补偿模式属性,该属性指定补偿模式,其中所述补偿模式提供与在所述传输会话内没有从所述发送器正确接收到所述公用数据的接收器何时可以开始对于所述修复会话的请求有关的信息,其中对于所述传输会话使用多个补偿模式,并且其中把所述错误阈值中的至少一个阈值和所述补偿模式的至少一个模式链接起来。例如,可以把每个错误阈值和相应的补偿模式链接起来。例如,通过标记错误阈值和补偿模式两者,以使相应的标记被理解为表示链接,可以实现上述链接。
根据本发明,优选地根据在所述传输会话期间所述公用数据由所述接收器接收时的接收质量和所述错误阈值要求的接收质量之间的关系,为接收器指派所述补偿模式。基于在所述传输会话内接收所述公用数据期间接收器经历的错误率,以及所述错误阈值和所述补偿模式之间的联系,则可以为所述接收器指派补偿模式。以此方式,具有高错误率(超过第一错误阈值)的接收器被指派为第一补偿模式,具有较低错误率(比第一错误阈值小但比第二错误阈值大)的接收器被指派为第二补偿模式。然后允许处于第一补偿模式的接收器在处于第二补偿模式的接收器之前或之后进行传输,由此实现服务质量(QoS)控制。
根据本发明的方法,优选地由补偿单位、补偿值和补偿窗口表示所述信息。所述补偿单位可以例如是以秒为单位的相对时间,绝对网络时间协议(NTP)时间,字节,比特或分组。所述补偿值可以例如是实值的数。所述补偿窗口可以例如是实值的数,其单位可以与所述补偿单位指定的单位相同。所述信息可以与绝对或相对时基有关。例如,如果所述补偿单位是秒,所述补偿值是60并且所述补偿窗口是120,这可以指示接收器可以在该传输会话结束后的60到180(=60+120)秒之间开始对于修复会话的请求,其中所述启动时间可以是例如基于均匀分布在60到120秒之间的所述间隔内随机选择的。
根据本发明的方法,所述信息优选地是用变量和时间值表示的,其中变量指示使用绝对定时还是使用相对定时。例如,如果所述变量指示使用绝对定时,则所述时间值可以指定开始对于修复会话的请求(或在其左右或从其可以随机选择开始时间)的绝对NTP时间。可选择地,如果所述变量指示使用相对定时,则所述时间值可以例如指定可以在以下间隔内随机开始所述请求,亦即在该传输会话结束时开始并且在所述时间值指示的持续时间之后结束的间隔内。也可以把所述时间值定义为最大修复可用时间,亦即修复操作可行之前的时间,因此优选地用NTP时间表示,从而支持所谓的懒惰修复(lazy repair)。
根据本发明的方法,所述信息优选地包括一个错误阈值和三个值X、Y和Z,并且在所述多个接收器中的至少一个接收器中,如果在所述传输会话内所述公用数据由所述至少一个接收器从所述发送器那里接收时的接收质量好于所述错误阈值指示的接收质量,则对于所述修复会话的所述请求是在持续时间X的时间间隔内随机开始的,其中所述间隔在所述传输会话结束时开始;否则,在Y和Y+Z之间的时限内随机开始对于所述修复会话的所述请求,其中Y是从所述传输会话结束时开始起算的。
根据本发明的方法,优选地能够使用所述通信协议向所述多个接收器传送所述多个接收器的数目。在确定所述修复会话的补偿时间时,所述接收器可以有利地使用与接收器的数目有关的信息。
根据本发明的方法,所述通信协议优选地包含修复类型参数属性,该属性指定所述修复会话可以是点对点会话,点对多点会话,还是二者。
根据本发明的方法,所述通信协议优选地包含修复令牌属性,该属性指定所述修复会话的类型,和/或与将在所述修复会话内从所述修复服务器向所述至少一个接收器传输的在所述传输会话内所述多个接收器中的至少一个接收器没有正确接收到的所述公用数据的哪些部分有关的信息。与所述部分有关的所述信息可以例如指定文件标识符,所述公用数据的源块号(SBN)和/或编码符号ID (ESI),或基于这些值的一对值或范围。
根据本发明的方法,所述通信协议优选地包含内容描述属性,该属性指定所述发送器如何向所述多个接收器指示URI,后者为所述公用数据的内容描述的存储位置。所述URI可以例如是诸如文件交付表(FDT)XML方案的扩展标记语言(XML)方案,或者是到达因特网媒体指南(IMG)数据模型的入口点,抑或是到达某一方案或模型的另一个入口点。
根据本发明的方法,从所述发送器到所述多个接收器的所述公用数据的所述传输优选地是至少部分地由单向传输上的文件交付FLUTE协议控制的。所述FLUTE可以表示用于因特网上的文件的单向交付的协议,因特网特别适合于多播网络。所述FLUTE协议可以基于异步分层编码(ALC)。
根据本发明的方法,所述通信协议优选地包含FLUTE信道属性,该属性指定在所述传输会话内该发送器使用多少信道向所述多个接收器传输所述公用数据。
根据本发明的方法,所述通信协议优选地包含FLUTE传输会话标识符TSI属性,该属性指定所述传输会话内的TSI的值。
根据本发明的方法,所述通信协议优选地包含媒体描述,该媒体描述指定所述传输会话内使用的媒体。该媒体描述也称为“m-行”。例如,所述媒体可以是音频、视频、应用、数据和控制。所述媒体描述可以例如描述在信道上传送的视频数据,其中该信道在用户数据报协议(UDP)上使用FLUTE。
根据本发明的方法,所述通信协议优选地包含连接数据,该连接数据指定所述传输会话内使用的信道的地址。该连接数据也称为“c-行”。所述连接数据可以包括网络类型、地址类型和连接地址。因此,该连接数据可以例如指示IPv6地址。
另外,提出了其指令可操作为使处理器执行上述方法步骤的计算机程序。所述处理器可以例如集成到所述发送器、接收器或二者中。
另外,提出了一种计算机程序产品,该计算机程序产品包括其指令可操作为使处理器执行上述方法步骤的计算机程序。
另外,提出了用于传输数据的系统,该系统包括至少一个发送器和多个接收器,其中所述至少一个发送器和所述多个接收器包括用于通过会话描述协议通信协议从所述至少一个发送器向所述多个接收器传送至少一个会话参数的装置,该会话参数与所述传输会话内的所述公用数据的所述传输有关;以及其中所述至少一个发送器和所述多个接收器包括用于在所述传输会话内从所述发送器向所述多个接收器传输所述公用数据的装置。
另外,提出了用于在传输会话内向多个接收器传输公用数据的发送器,该发送器包括:用于通过会话描述协议通信协议向所述多个接收器传输至少一个会话参数的装置,该会话参数与所述传输会话内的所述公用数据的所述传输有关;以及用于在所述传输会话内向所述多个接收器传输所述公用数据的装置。
另外,提出了用于接收公用数据的接收器,该公用数据是在传输会话内从一个发送器传输到多个接收器的,该接收器包括:用于接收至少一个会话参数的装置,该会话参数与所述传输会话内的所述公用数据的所述传输有关,并且该参数是通过会话描述协议通信协议传输到所述多个接收器的;以及用于接收在所述传输会话内从所述发送器传输到所述多个接收器的所述公用数据的装置。
另外,提出了会话描述协议,该协议包括至少一个会话参数的定义,该会话参数与在传输会话内从一个发送器到多个接收器的公用数据的传输有关。
通过参照下文描述的实施方式阐述本发明的这些方面和其它方面,本发明的这些方面和其它方面将是明显的。
附图说明
在附图中,
图1表示根据本发明的方法的可能实施方式的流程图;以及
图2表示根据本发明的系统的可能实施方式的示意图。
具体实施方式
本发明提议部署通信协议,以便向通过点对多点连接接收来自发送器的公用数据的多个接收器传送会话参数。在不是用来限制本发明的范围的下述描述中,将使用会话描述协议SDP作为用于此目的的通信协议的例子。为此目的,所述SDP包含为传送所述会话参数而定义的属性、媒体描述和连接数据。在下文中,将针对以下系统,亦即为因特网工程任务组(IETF)定义的单向传输上的文件交付(FLUTE)协议控制的会话提供第三代伙伴项目(3GPP)多媒体广播/多播业务的系统,用示例的方式说明这些SDP组成部分的定义。请注意,本发明在该系统中的应用以及下面的组成部分定义决不意味着把本发明的范围限制为该具体应用。这些组成部分是基于增量巴科斯-诺尔范式(ABNF)语法描述格式定义的。
1.FEC参数
前向纠错(FEC)属性描述所使用的FEC编码方案。FEC属性也可以描述FEC编码标识符(以及其与使用的FEC编码方案的联系)。例如,在IETF FLUTE协议草案中,给出了用于FLUTE协议的FEC编码ID的描述。可以有多个编码标识符与一个FEC编码方案相联系。
下面给出用于根据本发明的FEC属性的示例语法:
a=FEC-Info:″{″value*(″,″value)″}″CRLF
其中
value=value-single/value-couple
value-single=%d0-127
value-couple=″(″%d128-255″,″%d0-255″)″
其中,value是一个数值,代表所使用的FEC编码方案。value-single代表FEC编码方案(在本例中,其值在0到127之间)。value-couple代表(FEC编码方案,FEC编码ID)对(在本例中,FEC编码方案的值在128到255之间,编码ID的值在0到255之间)。
FEC属性优选地为仅会话级属性(然而,不排除把它用作媒体级属性)。
给出的value-single和value-couple示例可以是优选语法。然而,诸如value-single=%d0-255或value-couple=″(″%d0-255″,″%d0-255″)″之类的其它选项也在本发明的范围内。
如果在SDP描述符之中没有此属性,则这可以指示该描述符不使用FEC(例如,正如IETF FLUTE协议草案规定的那样,使用简洁无代码(Compact Nocode)FEC)。这相当于使用描述符a=FEC-Info:{0}。
供根据本发明的FEC属性使用的例子是:
a=FEC-Info:{0,64,127,(128,3),(128,4),(129,3)}
在上面的例子中,发送器指示使用了多个FEC ID。数字0、64、127等表示这些FEC ID。发送器不需要把这些ID映射到FLUTE会话的具体信道。
供根据本发明的FEC属性所使用的另一个例子是:
a=FEC-Info:{0}
在上面的例子中,发送器向接收器指示它使用简洁无代码FEC。也可以仅仅使用该参数来指示FEC ID 0-127(其是完全指定的)。然而,发送器也可以选择使用两个参数以指定可以使用FEC ID 0-127,例如,a=FEC-Info:{(0,0)}描述FEC ID 0和FEC实例0(在用于FEC ID 0-127的最佳模式中,实例信息是冗余信息)。
ALC版本1指定了仅单个用于FEC编码ID 0-127的参数是有用的(FEC编码ID)的限制。然而,根据本发明,为了进一步扩展可以用信号传送的完全指定的FEC模式的数目,也可以想象针对FEC编码ID 0-127使用第二参数(FEC实例ID)。
2.FEC机器参数:
如果使用通用FEC机器(亦即,允许在开始会话之前向接收器下载FEC方案或FEC解码矩阵的系统),则发送器必须用信号传送要从接收器上下载的FEC解码矩阵或FEC字节码的准确位置,以便对将要在多播/广播信道上传输的数据进行解码。
有利地,该数据的下载是以无错误的方式,优选地(但不限于)通过HTTP/TCP点对点连接进行的。如果没有把字节码或FEC矩阵无错误地交付给接收器,则接收器难以在多播/广播会话内正确接收公用数据。
根据本发明,发送器在SDP会话通告期间从而在会话开始之前用信号传送FEC文件的位置。有利地,在会话开始之前,接收器取回无错误的FEC文件,以使系统准备好对该数据进行解码。为了避免由于许多接收器的对于FEC文件下载的请求引起的网络过载,接收器可以根据随机选择的开始时间开始点对点下载。例如,接收器可以计算在时刻0(当通过所述SDP收到该会话描述时)到同一会话描述内包含的(第一个)t参数值中的会话开始时间指示的时刻之间的时间。
下面给出用于根据本发明的FEC机器属性的示例语法:
a=FEC-machine:FILE-ID
其中
FILE-ID=<″>textstring<″>
textstring=1*((0x01..0x09)/0x0b/0x0c/
0x0e..0x21)
/(0x023..0xff))
;除NUL、CR、LF、`″`之外的任何字节
FEC机器属性可以优选地为仅会话级属性。然而,不排除把它用作媒体级属性。
可以有许多FEC机器属性定义(亦即,有多行a=FEC-machine)。此时,接收器不仅可以在时间量纲上进行随机化,而且也可以基于许多FEC-machine位置进行随机化。
供根据本发明的FEC机器属性使用的示例是:
a=FEC-machine:″http://www.fec.com/matrix.fec″
在本例中,接收器从上面的地址中提取FEC矩阵文件。
3.FEC缓冲参数
FEC缓冲属性描述接收多播/广播数据流时FEC编码方案强加到接收器上的需求或约束。例如,这些约束可以按照第一参数附加延迟(亦即,用时间量纲例如用毫秒表示的等待时间)和/或第二参数存储需求(亦即,在接收器处执行FEC解码所需的字节数)。
有利地,第一参数适用于实时会话(如多播媒体流传输会话)。可以利用它来保证在接收器处的FEC编码媒体数据的实时的、无停顿的解码和重放。
有利地,第二参数适用于实时会话,而且适用于非实时会话(例如,文件下载会话)。接收器可以使用它,以便对照该会话需求确定其终端能力,并分配足够的存储容量以实现有效的FEC数据解码。
两个参数优选地为仅会话级属性。然而,不排除把它们用作媒体级属性。
不要求两个参数均出现在FEC缓冲属性描述中。同样,通过给出所使用的FEC编码方案,可以创建对前一个FEC属性的引用。
下面给出用于根据本发明的FEC缓冲属性的示例语法:
a=FEC-Buf:″{″(scheme-value)″,″0*1(delay-value)″,″
0*1(memory-value)″}″CRLF
其中
scheme-value=%d
delay-value=%d
memory-value=%d
下面给出供根据本发明的FEC缓冲属性使用的例子。
例1:
a=FEC-Buf:{127,500,1000000}
在本例中,发送器告知接收器FEC方案127产生500ms的延迟并且需要1000000字节的存储容量。
例2:
a=FEC-Buf:{127,500,}
在本例中,存储需求参数缺失。
例3:
a=FEC-Buf:{127,,1000000}
在本例中,延迟参数缺失。
4.拥塞控制参数
拥塞控制属性描述所使用的拥塞控制方案。
下面给出用于根据本发明的拥塞控制属性的示例语法:
a=Congestion-Control-ID:value CRLF
其中
value=%d/<″>textstring<″>
textstring=1*((0x01..0x09)/0x0b/0x0c/
(0x0e..0x21)
/(0x023..0xff))
;除NUL、CR、LF、`″`之外的任何字节
其中,value可以是数字或字母数字值,用来代表所使用的拥塞控制方案。该属性是仅会话级属性。
5.修复参数
这些属性优选地是仅会话级属性。然而,不排除把它们用作媒体级属性。在下面的描述中,示例性地定义与修复参数有关的四个属性。
5.1修复服务器的URI
修复服务器的URI属性描述接收器为建立点对点或点对多点修复会话所使用的修复服务器的地址。
下面给出用于根据本发明的修复URI属性的示例语法:
a=repai-URI:″uri=″<″>URI<″>CRLF
其中
URI=如请求注释(RFC)文档2396中所定义的
其中,URI是用于修复服务器的有效URI,接收器可以利用该服务器来建立修复会话。
在会话级处,存在″a=repai-URI″属性的多个实例。客户机可以基于以下标准选择适合的服务器:
-服务器的IP域(例如,在网络拓扑方面最接近的修复服务器),或者
-随机。
供根据本发明的修复URI属性使用的例子是:
a=repair-URI:uri=″www.repairserver.com″
在上面的示例中,发送器指示接收器将要使用修复服务器在没有正确接收到整个会话的情况下建立点对点修复会话。
5.2错误率修复阈值
与错误率修复阈值有关的SDP属性的定义包括以下两个方面。
5.2.1第一方面:使用四个值
错误率修复阈值属性可以描述超过其接收器就不能请求修复请求的阈值。
下面给出用于修复阈值语法的示例语法:
a=repair-threshold:″(″value 1″,″value2″,″value3″,″value4″)″
其中
value1=%d
value2=%d/float-value
value3=%d
value4=%d/float-value
float-value=1*DIGIT[″.″1*DIGIT]
其中,value1是用于错误率阈值的错误单位。可以用于此目的的值的示例是:
value1=0;字节(每秒)
value1=1;比特(每秒)
value1=2;分组(每秒)
value1=3;百分比(例如,丢失的字节或分组的百分比)(每秒)
错误单位的其它值也是可行的。例如,可以定义不带“每秒”指示的相同错误单位:
value1=0;字节
value1=1;比特
value1=2;分组
value1=3;百分比(例如,丢失的字节或分组的百分比)
value2是错误值。例如,为此可以使用10分钟,2百万字节或30个分组的值。该参数应该是用户定义的。
value3是测量窗口单位。可以用于此目的的值的示例是:
value3=0;测量窗口单位是秒。
value3=1;测量窗口单位是分组。
value3=2;测量窗口单位是比特。
value3=3;测量窗口单位是字节。
value4是测量窗口值的数量。该参数描述测量窗口的值。例如,如果value3=0并且value4=4,这指示4秒的测量窗口。
因此,当使用“每秒”指示时,如果value1=0,value2=10,value3=0并且value4=300,这表示阈值是在300秒的窗口中每秒有10个字节的错误。如果接收器观察到超过该阈值的错误,则它不得不做出所需要的反应。
同样,当不使用“每秒”指示时,如果value1=0,value2=10,value3=0并且value4=300,这表示阈值是在300秒的窗口中有10个字节的错误。如果接收器观察到超过该阈值的错误,则它不得不做出所需要的反应。
在使用多个错误阈值的优选操作中,依照最有挑战性的错误阈值标准(亦即,最低的错误率阈值)到最没有挑战性的错误阈值标准(亦即,最高的错误率阈值),采用升序(0,1,2,...n)隐含地标记这些阈值。因此,以低于最高错误率(例如,小于每秒0.000001比特的阈值)进行接收将被标识为错误率0,把下一个最有挑战性的标准(例如,小于每秒0.01比特,但大于每秒0.000001比特)标识为错误率1等等,直到最没有挑战性的接收标准(超过所有阈值)获得标记“错误率n”。请注意,根据该标记处理,指定的阈值的数目为n+1,并且可以是不变的。该虚拟标记处理的重要性在于,把错误阈值映射到可能使用的不同补偿模式。
对于本领域的熟练技术人员而言,显然value1、value2、value3和value4的若干枚举是可能的,并且在本发明的范围内。例如,value3=0(测量窗口单位为分组);value3=1(测量窗口单位为秒)是与上面的示例不同的枚举。
重要的是请注意,可以给出几个值四元组。一个示例是a=repair-threshold:″(A,B,C,D)(W,X,Y,Z)″。另一个示例是a=repair-threshold:″(A,B,C,D)″,继之以a=repair-threshold:″(W,X,Y,Z)″。这可以使主机理解多个阈值。正如下面将要更详细地说明的那样,在使用多个阈值的优选实施方式中,可以把阈值和补偿模式链接起来。对此既简单又精巧的方法是,四元组的顺序确定接收器的行为的模式。因此,(超过)指定的第一阈值(阈值1)相应于指定的第一补偿模式(补偿模式1),等等。
供根据本发明的该修复阈值属性使用的示例是:
a=repair-threshold:(0,10,0,300)
在本例中,发送器向接收器指示修复阈值为在300秒的窗口中每秒10字节。
5.2.2第二方面:使用一个值
重要的是指出包含四个值的语法示例并不限制把该错误阈值属性应用于更简单的情况。例如,正如下面的示例性描述的那样,使用单个值也是可能的:
a=repair-threshold:value
其中
value=%d/float-value
float-value=1*DIGIT[″.″1*DIGIT]
重要的是强调在第一方面(四个值,参见上面的条款2.1)和第二方面(一个值,参见本条款2.2)之间存在映射,其中第二方面代表第一方面的特例。事实上,根据本发明的第一方面和第二方面,可以表示简单错误率(如5%)。
供根据本发明的该修复阈值属性使用的例子是:
a=repair-threshold:5
在本例中,如果知道错误率是以分组丢失率为单位测量的,则发送器向接收器指示修复阈值是5%的分组丢失率。
5.3补偿模式
下面(5.3.1,5.3.2和5.3.3)将给出依赖于参数数目的补偿模式属性的三个可能的定义。
5.3.1第一补偿模式属性
补偿模式属性(等效名称可以是抑制模式,响应定时模式,时间分散函数,或时间扩展函数)描述发送器告知接收器何时开始对于修复操作的请求的方式,或者如何计算该开始时间。这可以包括用信号传送单个值(以时间为单位),传送接收器可以在该值上随机选择修复请求起动时间,或者用信号传送使接收器能够计算修复开始时间的一组值(例如,更复杂的一组阈值或者与多播传输有关的接收器的数目)。
类似于为错误率阈值而定义的方案的方案也可以与一组模式一起使用。下面给出用于根据本发明的补偿模式属性的示例语法:
a=backoff-mode:″(″value1″,″value2″,″value3″)″
其中
value 1=%d/float-value
float-value=1*DIGIT[″.″1*DIGIT]
value2=%d
value3=%d
其中,value1是测量单位。可以使用的value1的值的示例是:
value1=0;单位是相对时间,以秒为单位,
value1=1;单位是绝对NTP时间,
value1=2;单位是字节,
value1=3;单位是比特,或者
value1=4;单位是分组。
value2是测量值。例如,10秒,20字节,30分组。该值可以代表偏移值,并且可以是负的。请注意,对于时间测量,该值可以是绝对时间或相对时间。如果会话长度有限并且具有比较短的时间,则优选的相对方式可以相对于会话的结束(正如在该描述符中通告的那样)。对于永不结束的会话(非MBMS),可以使用另一个实体的结束(如传输报头标志用信号传送的传输对象的结束)。
value3代表窗口。其单位可以与value2的单位相同,亦即,value1定义的单位。
在本发明的可选实施方式中,比三个参数更少的参数也是可能的。例如,只有2个参数可以指示其默认为相对时间。同样,只有一个参数可以指示零偏移的相对时间。
例如,a=backoff-mode:(0,60,120)将指示使用此模式的设备将计算发送消息(例如,修复请求)的时间,优选地在从通告的会话(或另一个有关实体)结束开始的60秒和180(=60+120)秒之间以均匀分布的方式进行随机选择。
在优选操作中,依据该描述实例中的出现顺序,采用升序(0,1,2,...,m)隐含地标记补偿模式。因此,把描述的第一模式(例如,从SDP文件的开始)标识为模式0,把下一个出现的模式标识为模式1等等,直至所描述的最后一个模式获得标记“模式m”。该虚拟标记操作的重要性在于从错误率阈值(如上所述)进行映射,错误率阈值告知接收器使用哪个模式。因此,如果经历错误率1,则接收器可以使用补偿模式1。良好的设计可以确保模式数(m+1)等于指定的错误率阈值的数目。然而,为了避免不必要的错误状态:当n>m时,对所有错误率m和更大的错误率,可以使用模式m;当n<m时,可以忽略补偿模式n+1到m。请注意,依赖于错误率标准的多个模式的目的是为了允许快速和慢速修复类型的服务,通过允许具有最低请求修复需求优先级的用户进入修复调度,可以最大化整个多播/广播组上的用户感受到的QoS。因此,对于此种情况,确保模式0提供最及时的最早的修复并且模式m提供最不及时的修复是合理的。然而,这不是强制的,所以可选的方案也是允许的。
例如,a=backoff-mode:(0,0,60),a=backoff-mode:(0,60,120)将指示使用第一模式的设备将在从该会话的结束开始的0秒和60秒之间的某个时刻发送其消息,使用第二模式的设备将在从该会话的结束开始的60秒和120秒之间的某个时刻发送其消息。上面的例子表示非重叠消息窗口,尽管重叠窗口(跨越不同模式)也在本发明的范围内。
一个可选的操作是向每个补偿模式行添加第四个值,第四个值可以或者以整数的方式或者以某些其它标记的方式给出模式标记,其中可以把该整数映射到上面的错误率,其中某些其它标记需要类似标记以被引入到错误阈值行中,或者需要也被使用的独立的映射描述符。
供根据本发明的该补偿模式属性使用和该修复阈值属性使用的例子是:
a=backoff-mode:(0,0,30)
a=repair-threshold:(1,10,0,100)
a=backoff-mode:(0,30,60)
a=repair-threshold:(1,20,0,100)
a=backoff-mode:(0,60,240)
在本例中,如果错误率小于每秒10比特(在100秒的滑动时间窗口上),则接收器应在交付会话结束和30秒之间随机选择修复请求的开始时间。如果错误率大于等于每秒10比特但小于每秒20比特,则接收器应在交付会话结束之后等待30秒,然后在30秒等待时间结束和另外60秒之间(亦即,在会话结束之后的30秒和90秒之间)随机选择修复请求。如果错误率大于等于每秒20比特,则接收器应在交付会话结束之后等待60秒,然后在60秒等待时间结束和另外240秒之间(亦即,在会话结束之后的60秒和300秒之间)随机选择修复请求。
请注意,接收器对上述例子的解释与对以下可选顺序的解释相同:
a=repair-threshold:(1,10,0,100)
a=repair-threshold:(1,20,0,100)
a=backoff-mode:(0,0,30)
a=backoff-mode:(0,30,60)
a=backoff-mode:(0,60,240)
5.3.2第二补偿模式属性
根据本发明的可选的补偿操作可以服从以下规则:
如果低于阈值错误率则
″在从初始交付会话结束开始的时限X上均匀地随机选择一个或多个NACK″
否则
″必须在初始会话结束之后等待某个时间Y,然后在时间段Z上随机选择一个或多个NACK″。
其中,否定应答消息(NACK)可以例如相当于开始对于修复会话的请求。
该可选的补偿操作需要某些SDP参数的描述。这里,参数是ERROR RATE,X,Y和Z,其中ERROR RATE是用与上面定义的错误率阈值的单位相同的单位表示的,而X、Y、Z是用时间单位(如秒)表示的。下面给出用于根据本发明的此类补偿模式属性的示例语法:
a=backoff-mode:″(″value1″,″value2″,″value3″,″value4″)″
其中
value1=%d/float-value
float-value=1*DIGIT[″.″1*DIGIT]
value2=%d
value3=%d
value4=%d
其中,value1是与如上在错误率修复阈值中定义的错误率一样的错误率。value2是错误率低于value1时的补偿时间,它是从交付会话结束开始的。value3是错误率超过value1给出的阈值时的等待时间。value4是错误率高于value1时的补偿时间。它可以是交付会话结束之后的相对于value3的偏移值,或者是相对于交付会话结束的偏移值(在后一种情况中,value4>value2)。
带有补偿模式属性的多个a-行定义一批条件,并且也是可能的。
供该补偿模式属性使用的示例是:
例1:
a=backoff-mode:(5,10,20,30)
在本例中,如果错误率小于5%,则接收器应在交付会话结束和10秒之间随机选择修复请求的开始时间。如果错误率大于5%则接收器应在交付会话结束之后等待20秒,然后在20秒等待时间结束和30秒之间随机选择修复请求。
例2:
a=backoff-mode:(5,10,20,30)
a=backoff-mode:(10,20,30,60)
本例包含带有相同属性的多个a行。除例2中定义的用于5%的错误率的规则之外,制订用于处理10%的错误率的第二条规则,其语义与前一个例子中的语义相同。
5.3.3第三补偿模式属性
重要的是指出上面的语法例子并不限制把该补偿模式属性应用于简单情况。例如,正如下面示例性给出的那样,使用单个值也是可能的:
a=backoff-mode:″(″[″+″]value″)″
其中
value=%d
其中,如果使用″+″,则考虑从SDP的接收开始的相对时间。在此情况下,发送器可以告知接收器在该会话结束和(用秒表示的)value之间的一个随机时间开始修复会话。如果不使用″+″,则使用绝对NTP时间单位。
也可以把value定义为最大修复可用性时间(直到可以进行修复操作的时间),并且优选地用NTP时间表示。在此情况下,可以启用懒惰修复。
此外,发送器也可以通过SDP用信号传送已经加入多播会话的接收器的数目,因为这是可以提供给计算该修复会话的开始的补偿时间的函数的输入(与上面的随机时间一起)的数目。
供该补偿模式属性使用的示例是:
例1:
a=backoff-mode:(+500)
在本例中,发送器告知接收器在该会话结束和500秒之间的一个随机时间开始该修复会话。
例2:
a=backoff-mode:(+500)
a=backoff-mode-users:5000
在本例中,发送器告知接收器在考虑已有5000用户加入多播会话的情况下计算补偿时间。
5.4修复类型参数和修复令牌参数
该参数描述修复类型(亦即,点对多点修复,点对点修复,或二者)以及修复令牌。第一个用于描述什么类型的修复是可能的。第二个描述具体对象(如文件)将如何进行修复(亦即,修复类型),以及该对象的哪些部分需要修复(例如,在使用点对多点修复时)。可以有多个修复令牌属性列表。该属性可以是会话级属性或媒体级属性。
用于根据本发明的修复类型属性的示例语法给出如下:
a=repair-type-param:repair-type
其中
repair-type=″ptp″/″ptm″/″both″
并且给出根据本发明的修复令牌属性的示例语法:
a=repair-token:″{″repair-type*(″,″entity)}″
其中
repair-type=″ptp″/″ptm″/″both″
entity=(″(″File-ID[*(″,(″SBN*(″,″ESI)″)″)/
(*(″,(first_byte_position=″
first_byte_position″,number_of_bytes=″
number_of_bytes)″)″)]″)″)
FILE-ID=<″>textstring<″>
SBN=(%d)/(″(″%d*(″,″%d)″)″)/(″(″%d″-″%d″)″)
ESI=(%d)/(″(″%d*(″,″%d)″)″)/(″(″%d″-″%d″)″)
first_byte_position=%d
number_of_bytes=%d
textstring=1*((0x01..0x09)/0x0b/0x0c/
(0x0e..0x21)
/(0x023..0xff))
;除NUL、CR、LF、`″`之外的任何字节
其中,SBN是源块号,而ESI是编码符号ID。ESI和SBN可以是成对的,ESI和SBN可以是范围或范围列表。然而,ESI不能在该描述符中单独出现。
修复令牌可以按照每个对象(如文件)的修复令牌而发送。请注意,通常希望File-ID文本串为URI或其一部分。
供修该复类型属性使用的示例是:
a=repair-type-param:ptm
在本例中,告知接收器该修复将通过点对多点进行。
供该修复令牌属性使用的示例是:
例1:
a=repair-token:{ptm,(″http://www.file.com/file3.3gp″,(10,20),(12,134))}
在本例中,对于指示的文件,修复是通过点对多点完成的。要修复的块是具有SBN 10和ESI 20以及SBN 12和ESI 134的那些块。
例2:
a=repair-token:{ptm,(″http://www.file.com/file3.3gp″,(10-14),(16,34))}
在本例中,对于指示的文件,修复是通过点对多点完成的。要修复的块是SBN 10-SBN14以及SBN 16的ESI 34的那些块。
例3:
a=repair-token:{ptm,(″http://www.file.com/file3.3gpp″,
″first_byte_position=10,number_of_bytes=150″)}
在本例中,对于指示的文件,修复是通过点对多点完成的。要修复的字节数是150,从字节10开始。
6.多信道
与多信道有关的SDP属性的定义包括将如下描述的三个方面。
6.1第一方面
多信道属性描述发送器进行传输时使用的信道数。也可以利用它来对照SDP m-行检查信道数。
下面给出根据本发明的示例语法:
a=flute-ch:value CRLF
其中
value=%d
其中,value是发送器在一个FLUTE会话中传输数据时使用的信道数。该参数可以向接收器指示发送器正在该FLUTE会话中使用多个信道传输数据。这也可以指示发送器使用的信道数。接收器可以利用该描述符指定的值来检查它已经收到描述目的地的所有m-行。例如,如果该参数的值是2,则存在m-行指定的2个信道。
6.2第二方面
此外,根据本发明的TSI属性描述用于该会话的传输会话标识符(TSI)的值。用于该TSI属性的示例性语法是:
a=flute-tsi:value CRLF
其中
value=%d
6.3第三方面
在本发明中,还引入了用来指示某个信道上存在FLUTE会话的新的媒体描述符(m-行)和连接数据(c-行)。其实现方式是在下面的示例中所示的SDP描述中使用m-行:
m=data 12345 FLUTE/UDP 0
c=IN IP6 FF1E:03AD::7F2E:172A:1E24/1
在上面的SDP媒体描述符(m-行)和连接数据(c-行)中,m-行指示所使用的媒体,而c-行指示相应的信道。因此,在上面的例子中,m-行指示该媒体是在以下信道上,亦即在UDP上使用FLUTE的信道上传输的。此外,c-行指示信道地址,在这种情况中,信道地址是IPv6地址。
供与根据上述三个方面的多信道有关的属性使用的示例是:
v=0
o=user123 2890844526 2890842807 IN IP6
2201:056D::112E:144A:1E24
s=File delivery session example
i=More information
t=2873397496 2873404696
a=source-filter:incl IN IP6*
2001:210:1:2:240:96FF:FE25:8EC9
a=flute-tsi:3
a=flute-ch:2
m=data 12345 FLUTE/UDP 0
c=IN IP6 FF1E:03AD::7F2E:172A:1E24/1
m=data 12346 FLUTE/UDP 0
c=IN IP6 FF1E:03AD::7F2E:172A:1E30/1
在上面的例子中,发送器指示它将在两个信道上传输该FLUTE会话中的数据(a=flute-ch:2)。接着,发送器指定信道。这些信道是在行c=IN IP6 FF1E:03AD::7F2E:172A:1E30/1中指示的。同时,向接收器表明该信道是两个(在其它情况中可能是更多个)连续信道。行a=flute-tsi:3中定义的属性TSI描述用于该会话的TSI(传输会话标识符)。行a=source-filter:incl IN IP6*2001:210:1:2:240:96FF:FE25:8EC9中定义的属性描述源滤波器。在本例中,发送器指示接收器应该把给定的IP地址(2001:210:1:2:240:96FF:FE25:8EC9)包含到该会话中。(源IP地址,TSI)对一起唯一地标识会话。请注意,尽管可以使用其它可能性,但是在这种情况中,在上面的描述符中可以仅使用incl和*属性。行m=data 12345 FLUTE/UDP 0是新增的,用于指示该信道使用的媒体。在本例中,有两个`m`行,用于所描述的两个信道。
当需要所描述的FLUTE会话范围之外的修复会话时,为了向接收器用信号传送所用的参数,发送器使用第7节定义的SDP属性用于会话修复。这些参数允许接收器定位正确的修复服务器,允许发送器设置预定义的修复阈值,并且允许发送器定义修复类型和其它参数。
7.内容描述符指针
内容描述符指针属性描述发送器如何向接收器指示存储内容描述的URI。
下面给出用于根据本发明的内容描述符指针属性的示例语法:
a=content-desc:″uri=″<″>URI<″>CRLF
其中
URI=如RFC 2396中所定义的
其中,URI是用于内容描述的有效URI。URI可以是诸如文件描述表(FDT)XML方案的扩展标记语言(XML)方案,到达因特网媒体指南(IMG)数据模型的入口点或到达某一方案或数据模型的其它此类入口点。本领域的技术人员能够发现使用该方法的其它可选方案。
图1描绘根据本发明的方法的可能实施方式的流程图。在第一步骤801中,在发送器和接收器之间建立物理连接或逻辑连接。接着,在第二步骤802中,通过例如SDP的通信协议,从发送器向接收器传送会话参数,该会话参数例如与将应用于传输会话中的FEC编码方案有关的信息或与接收器处的缓冲需求有关的信息。在这种情况中,可以借助于在本发明的以上描述中用示例性地定义的SDP属性,传送所述会话参数。在所述接收器接收这些会话参数并处理这些会话参数之后,在步骤803中,执行从发送器到接收器的公用数据的点对多点传输,公用数据的点对多点传输至少部分地由所述会话参数定义。
图2示意性地描绘了根据本发明的系统的可能实施方式。该系统包括发送器902,网络903以及接收器901-1、901-2和901-3。所述发送器902可以例如是MBMS服务器。在一个点对多点会话内,通过所述网络903,从所述发送器902向所述接收器901-1、901-2和901-3传输数据,所述网络903可以例如是基于IP的广播/多播网络。在所述点对多点会话以前,通过所述通信的协议,从所述发送器902向所述接收器901-1、901-2和901-3传送会话参数,所述通信协议可以例如是SDP。
从上面提供的例子中容易看出,本发明至少在以下几方面具有显著优势:
本发明提供在FLUTE会话之外向接收器发送在接收器处接收该会话所需的参数的方法。
本发明还提供当接收器在会话期间没有收到全部所需数据的情况下向接收器发送建立点对点修复会话所需的参数的方法。再者,就其本性而言,这些参数需要在该会话之外发送。通过使用SDP向接收器发送这些参数提供实现该目的的理想方法。
此外,本发明能够根据有差别的接收恢复要求,特别是通过把不同的错误阈值和各个补偿模式链接起来,实现了简单的、强大的可升级的多种补偿算法。
上面借助于示例和优选实施方式描述了本发明。请注意,存在对于本领域的熟练技术人员是显然的可选方式和变更,并且它们的实现并不背离所附权利要求书的范围和实质。特别地,本发明适用于IP网络上的所有类型的广播/多播系统,并且不限于移动网络或3GPPMBMS系统。此外,本发明绝不限于FLUTE会话,而是同样可以应用于其它类型的会话。
Claims (48)
1.在传输会话内从一个发送器向多个接收器传输公用数据的方法,该方法包括:
通过通信协议,向所述多个接收器传送与所述传输会话内的所述公用数据的所述传输有关的至少一个会话参数;以及
在所述传输会话内从所述发送器向所述多个接收器传输所述公用数据。
2.根据权利要求1的方法,其中所述至少一个会话参数在建立所述传输会话之前或在建立所述传输会话期间传送到所述多个接收器。
3.根据权利要求1的方法,其中所述通信协议是会话描述协议SDP。
4.根据权利要求1的方法,其中所述公用数据至少部分地通过基于因特网协议(IP)的网络从所述发送器传输到所述多个接收器。
5.根据权利要求1的方法,其中所述公用数据在广播或多播操作中从所述发送器传输到所述多个接收器。
6.根据权利要求1的方法,其中所述公用数据是流传输数据或非流传输数据。
7.根据权利要求1的方法,其中所述公用数据是实时数据或非实时数据。
8.根据权利要求1的方法,其中所述公用数据至少部分地通过无线网络从所述发送器传输到所述多个接收器。
9.根据权利要求8的方法,其中所述无线网络是至少部分地实现第三代伙伴项目(3GPP)定义的多媒体广播/多播业务(MBMS)的移动网络。
10.根据权利要求1的方法,其中所述通信协议包含前向纠错(FEC)属性,该属性指定至少FEC编码方案,该编码方案用于所述传输会话内的所述公用数据的所述传输。
11.根据权利要求10的方法,其中所述FEC属性进一步指定FEC编码标识符。
12.根据权利要求1的方法,其中所述通信协议包含FEC机器属性,该属性指定可以下载FEC解码信息的位置。
13.根据权利要求12的方法,其中所述多个接收器中的至少一个接收器以无错误的方式从所述位置下载所述FEC解码信息。
14.根据权利要求12的方法,其中所述多个接收器中的至少一个接收器使用基于超文本传输协议(HTTP)或传输控制协议(TCP)的点对点连接来下载所述FEC解码信息。
15.根据权利要求12的方法,其中所述多个接收器中的至少一个接收器使用时间分散函数来确定开始从所述位置下载所述FEC解码信息的时间。
16.根据权利要求1的方法,其中所述通信协议包含前向纠错缓冲属性,该属性指定在所述传输会话内从所述发送器向所述多个接收器传输所述公用数据期间加在所述多个接收器上的缓冲需求。
17.根据权利要求16的方法,其中所述缓冲需求为缓冲延迟、缓冲存储容量或二者。
18.根据权利要求1的方法,其中所述通信协议包含拥塞控制属性,该属性指定所述传输会话内所述公用数据的所述传输使用的拥塞控制方案。
19.根据权利要求1的方法,其中当所述多个接收器中的至少一个接收器没有正确接收到所述公用数据时,在修复会话内从修复服务器向所述至少一个接收器传输至少部分所述公用数据。
20.根据权利要求19的方法,其中所述多个接收器的所述至少一个接收器使用时间分散函数来确定所述修复会话的开始时间。
21.根据权利要求19的方法,其中所述修复会话为点对点或点对多点修复会话。
22.根据权利要求1的方法,其中所述通信协议包含修复统一资源标识符(URI)属性,该属性指定所述修复服务器的URI。
23.根据权利要求19的方法,其中所述通信协议包含修复阈值属性,该属性指定错误阈值,并且其中所述错误阈值与在所述传输会话内所述公用数据由所述多个接收器从所述发送器那里接收时的接收质量有关。
24.根据权利要求23的方法,其中所述多个接收器中的一个接收器是否进入所述修复会话取决于在所述传输会话内所述公用数据由所述接收器从所述发送器那里接收时的接收质量和所述错误阈值之间的关系。
25.根据权利要求23的方法,其中按照错误单位、错误值、测量窗口单位和测量窗口值对所述错误阈值进行量化。
26.根据权利要求23的方法,其中所述错误阈值是按照错误值进行量化的。
27.根据权利要求23的方法,其中多个错误阈值用于所述传输会话,并且其中明确地或隐含地标记所述错误阈值。
28.根据权利要求19的方法,其中所述通信协议包含补偿模式属性,该属性指定补偿模式,并且其中所述补偿模式提供与所述传输会话内没有从所述发送器正确接收到所述公用数据的接收器何时可以开始对于所述修复会话的请求有关的信息。
29.根据权利要求27的方法,其中所述通信协议包含补偿模式属性,该属性指定补偿模式,其中所述补偿模式提供与所述传输会话内没有从所述发送器正确接收到所述公用数据的接收器何时可以开始对于所述修复会话的请求的有关的信息,其中多个补偿模式用于所述传输会话,并且其中所述错误阈值中的至少一个阈值和所述补偿模式中的至少一个模式分别链接起来。
30.根据权利要求29的方法,其中根据在所述传输会话期间所述公用数据由所述接收器接收时的接收质量和所述错误阈值要求的接收质量之间的关系,为接收器分配所述补偿模式。
31.根据权利要求28的方法,其中所述信息是用补偿单位、补偿值和补偿窗口表示的。
32.根据权利要求28的方法,其中所述信息是用变量和时间值表示的,该变量指示使用绝对定时还是使用相对定时。
33.根据权利要求28的方法,其中所述信息包括错误阈值和三个值X、Y和Z,并且其中在所述多个接收器中的至少一个接收器中,如果在所述传输会话内所述公用数据由所述至少一个接收器从所述发送器那里接收时的接收质量好于所述错误阈值指示的接收质量,则对于所述修复会话的所述请求是在持续时间X的时间间隔内随机启动的,其中所述间隔在所述传输会话结束时开始;否则,在Y和Y+Z之间的期间内随机开始对于所述修复会话的所述请求,其中Y是从所述传输会话结束时起算的。
34.根据权利要求1的方法,其中可以使用所述通信协议向所述多个接收器传送所述多个接收器的数目。
35.根据权利要求19的方法,其中所述通信协议包含修复类型参数属性,该属性指定所述修复会话可以是点对点会话,点对多点会话,或是二者。
36.根据权利要求19的方法,其中所述通信协议包含修复令牌属性,该属性指定所述修复会话的类型,或与将在所述修复会话内从所述修复服务器向所述至少一个接收器传输的所述传输会话内所述多个接收器中的至少一个接收器没有正确接收到的部分所述公用数据的有关的信息,或二者。
37.根据权利要求1的方法,其中所述通信协议包含内容描述属性,该属性指定所述发送器如何向所述多个接收器指示存储所述公用数据的内容描述的URI。
38.根据权利要求1的方法,其中从所述发送器到所述多个接收器的所述公用数据的所述传输是至少部分地由单向传输上的文件交付FLUTE协议控制的。
39.根据权利要求38的方法,其中所述通信协议包含FLUTE信道属性,该属性指定在所述传输会话内该发送器使用多少信道向所述多个接收器传输所述公用数据。
40.根据权利要求38的方法,其中所述通信协议包含FLUTE传输会话标识符TSI属性,该属性指定所述传输会话内的TSI的值。
41.根据权利要求38的方法,其中所述通信协议包含媒体描述,该媒体描述指定所述传输会话内使用的媒体。
42.根据权利要求38的方法,其中所述通信协议包含连接数据,该连接数据指定所述传输会话内使用的信道的地址。
43.一种其指令可操作以使处理器执行权利要求1的方法步骤的计算机程序。
44.一种计算机程序产品,该计算机程序产品包括其指令可操作以使处理器执行权利要求1的方法步骤的计算机程序。
45.一种用于传输数据的系统,该系统包括:
至少一个发送器;以及
多个接收器;
其中所述至少一个发送器和所述多个接收器包括用于通过通信协议从所述至少一个发送器向所述多个接收器传送至少一个会话参数的装置,该会话参数与所述传输会话内的所述公用数据的所述传输有关;以及
其中所述至少一个发送器和所述多个接收器包括用于在所述传输会话内从所述发送器向所述多个接收器传输所述公用数据的装置。
46.一种在传输会话内向多个接收器传输公用数据的发送器,该发送器包括:
用于通过通信协议向所述多个接收器传送至少一个会话参数的装置,该会话参数与所述传输会话内的所述公用数据的所述传输有关;以及
用于在所述传输会话内向所述多个接收器传输所述公用数据的装置。
47.一种用于接收公用数据的接收器,该公用数据是在传输会话内从一个发送器传输到多个接收器的,该接收器包括:
用于接收至少一个会话参数的装置,该会话参数与所述传输会话内的所述公用数据的所述传输有关,并且是通过通信协议传送到所述多个接收器的;以及
用于接收在所述传输会话内从所述发送器传输到所述多个接收器的所述公用数据的装置。
48.一种通信协议,该协议包括:
至少一个会话参数的定义,该会话参数与在传输会话内从发送器到多个接收器的公用数据的传输有关。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/806,023 | 2004-03-22 | ||
US10/806,023 US8296436B2 (en) | 2004-03-22 | 2004-03-22 | Conveying parameters for broadcast/multicast sessions via a communication protocol |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2012105134588A Division CN102984262A (zh) | 2004-03-22 | 2005-03-17 | 通过通信协议传送广播/多播会话的参数 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN1934825A true CN1934825A (zh) | 2007-03-21 |
Family
ID=34961972
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA200580009100XA Pending CN1934825A (zh) | 2004-03-22 | 2005-03-17 | 通过通信协议传送广播/多播会话的参数 |
CN2012105134588A Pending CN102984262A (zh) | 2004-03-22 | 2005-03-17 | 通过通信协议传送广播/多播会话的参数 |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2012105134588A Pending CN102984262A (zh) | 2004-03-22 | 2005-03-17 | 通过通信协议传送广播/多播会话的参数 |
Country Status (8)
Country | Link |
---|---|
US (2) | US8296436B2 (zh) |
EP (1) | EP1728356B1 (zh) |
JP (1) | JP4550883B2 (zh) |
KR (3) | KR100857187B1 (zh) |
CN (2) | CN1934825A (zh) |
AU (1) | AU2005226165B2 (zh) |
TW (1) | TW200539639A (zh) |
WO (1) | WO2005093998A1 (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2008128409A1 (fr) * | 2007-04-24 | 2008-10-30 | Huawei Technologies Co., Ltd. | Procédé et appareil pour émettre et recevoir un message de notification à travers le protocole de distribution de fichier par transport unidirectionnel |
CN101309437B (zh) * | 2007-05-17 | 2011-06-22 | 中兴通讯股份有限公司 | 单向文件传输方法及接口配置装置 |
CN110892756A (zh) * | 2017-07-20 | 2020-03-17 | 代傲表计系统有限公司 | 用于分配数据的方法 |
Families Citing this family (46)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060193337A1 (en) * | 2005-02-25 | 2006-08-31 | Toni Paila | Device management broadcast operation |
US20060198326A1 (en) * | 2005-03-07 | 2006-09-07 | Yifan Yang | IP multicast streaming data error correction |
US7899877B2 (en) * | 2005-05-17 | 2011-03-01 | Dell Products L.P. | Method for dynamically managing multicast sessions for software downloads and related systems |
US20060262806A1 (en) * | 2005-05-19 | 2006-11-23 | Imed Bouazizi | System and method for data delivery |
KR100733911B1 (ko) * | 2005-12-08 | 2007-07-02 | 한국전자통신연구원 | Mbms 제공 시스템 및 그 방법 |
KR100726175B1 (ko) | 2005-12-09 | 2007-06-11 | 한국전자통신연구원 | 무선 휴대 인터넷 시스템에서 상위 프로토콜 메시지의 방송 전송 방법 및 장치 |
EP2421265B1 (en) * | 2006-01-05 | 2013-10-02 | Telefonaktiebolaget LM Ericsson (PUBL) | Generation of media container files |
US20070183458A1 (en) * | 2006-02-06 | 2007-08-09 | Nokia Corporation | System and method for using scalable session initiation and termination in mobile broadcast/multicast services |
CN100454822C (zh) * | 2006-05-13 | 2009-01-21 | 华为技术有限公司 | 一种用于多媒体广播和组播业务中的下载分发方法 |
WO2008023335A2 (en) * | 2006-08-21 | 2008-02-28 | Nokia Corporation | Caching directives for a file delivery protocol |
CN101136759A (zh) * | 2006-09-01 | 2008-03-05 | 华为技术有限公司 | 一种多媒体广播组播业务的发送处理方法及系统 |
US8155628B1 (en) * | 2006-09-15 | 2012-04-10 | At&T Mobility Ii Llc | Mobile initiated broadcast |
EP1901525A1 (en) * | 2006-09-15 | 2008-03-19 | THOMSON Licensing | File repair method for a content distribution system |
US20080101317A1 (en) * | 2006-10-30 | 2008-05-01 | Nokia Corporation | System and method for providing advanced session control of a unicast session |
GB0622454D0 (en) | 2006-11-13 | 2006-12-20 | Siemens Ag | Emergency alert |
KR100819302B1 (ko) | 2006-12-01 | 2008-04-02 | 삼성전자주식회사 | 광대역 무선 접속 시스템의 멀티캐스트 및 브로드캐스트서비스를 위한 데이터 송수신 방법 |
US7940785B2 (en) * | 2007-01-08 | 2011-05-10 | International Business Machines Corporation | Ethernet adapter packet management |
WO2008119673A1 (en) * | 2007-03-30 | 2008-10-09 | Thomson Licensing | Robust file casting for mobile tv |
US8463913B2 (en) * | 2007-09-29 | 2013-06-11 | Research In Motion Limited | System and method of responding to a request in a network environment including IMS |
CN101919222B (zh) | 2007-10-27 | 2014-02-05 | 黑莓有限公司 | 在分布式环境中处理消息内容的内容部署系统和方法 |
US8266260B2 (en) * | 2007-12-11 | 2012-09-11 | Sharp Laboratories Of America, Inc. | Method and system for updating the software of multiple network nodes |
US8553555B2 (en) * | 2008-01-18 | 2013-10-08 | Qualcomm Incorporated | Methods and apparatus for an efficient multicast file distribution system |
US8365229B2 (en) | 2008-06-09 | 2013-01-29 | Lg Electronics Inc. | Method for mapping between signaling information and announcement information and broadcast receiver |
KR101598518B1 (ko) * | 2008-06-09 | 2016-02-29 | 엘지전자 주식회사 | 서비스 제공 방법 및 모바일 방송 수신기 |
US8422509B2 (en) | 2008-08-22 | 2013-04-16 | Lg Electronics Inc. | Method for processing a web service in an NRT service and a broadcast receiver |
TWI486040B (zh) | 2008-10-10 | 2015-05-21 | Thomson Licensing | 在接收器要求失落符號之方法及其接收器 |
KR101781889B1 (ko) | 2008-12-09 | 2017-09-26 | 엘지전자 주식회사 | 비실시간 서비스 처리 방법 및 방송 수신기 |
CN101841405A (zh) * | 2009-03-16 | 2010-09-22 | 日电(中国)有限公司 | 无线通信系统、无线通信方法、发送器和接收器 |
US8306049B2 (en) * | 2010-02-22 | 2012-11-06 | Microsoft Corporation | Multicast subscription based on forward error correction |
CN101860797B (zh) * | 2010-05-21 | 2014-08-13 | 中兴通讯股份有限公司 | 数据信息的传输方法、装置及移动多媒体广播业务系统 |
US20120017149A1 (en) * | 2010-07-15 | 2012-01-19 | Jeffrey Lai | Video whisper sessions during online collaborative computing sessions |
JP5748471B2 (ja) * | 2010-12-14 | 2015-07-15 | キヤノン株式会社 | 配信装置、配信方法、プログラム |
US20120191823A1 (en) * | 2011-01-21 | 2012-07-26 | T-Mobile Usa, Inc. | Software-Implemented Communications Adapter |
US9590814B2 (en) * | 2011-08-01 | 2017-03-07 | Qualcomm Incorporated | Method and apparatus for transport of dynamic adaptive streaming over HTTP (DASH) initialization segment description fragments as user service description fragments |
CA2849853C (en) * | 2011-10-05 | 2017-12-12 | Peerialism AB | Method and device for arranging peers in a live streaming p2p network |
US9438883B2 (en) * | 2012-04-09 | 2016-09-06 | Intel Corporation | Quality of experience reporting for combined unicast-multicast/broadcast streaming of media content |
US9900166B2 (en) * | 2013-04-12 | 2018-02-20 | Qualcomm Incorporated | Methods for delivery of flows of objects over broadcast/multicast enabled networks |
US9781181B2 (en) | 2013-06-17 | 2017-10-03 | Qualcomm Incorporated | Multiple file delivery over unidirectional transport protocol sessions for a service |
US9350484B2 (en) * | 2014-03-18 | 2016-05-24 | Qualcomm Incorporated | Transport accelerator implementing selective utilization of redundant encoded content data functionality |
US9450947B2 (en) * | 2014-05-20 | 2016-09-20 | Motorola Solutions, Inc. | Apparatus and method for securing a debugging session |
KR101877268B1 (ko) * | 2014-09-15 | 2018-07-11 | 주식회사 쏠리드 | Pc-cfr 장치 및 papr 감소 방법, 및 피크 값 결정 장치 |
CN107209749A (zh) * | 2014-11-25 | 2017-09-26 | 劳德—海拉尔股份有限公司 | 通过对等网络进行广播的本地与时序方法及其系统 |
JP6774957B2 (ja) * | 2015-04-07 | 2020-10-28 | サムスン エレクトロニクス カンパニー リミテッド | マルチメディアブロードキャストマルチキャストサービスに基づくフレキシブルブロードキャストサービスのための方法及び装置 |
JP7247706B2 (ja) * | 2019-03-28 | 2023-03-29 | 日本電気株式会社 | 送信ノード、放送局システム、制御ノード及び送信制御方法 |
JP7247707B2 (ja) * | 2019-03-28 | 2023-03-29 | 日本電気株式会社 | 送信ノード、放送局システム、制御ノード及び送信制御方法 |
JP2021056505A (ja) * | 2019-09-30 | 2021-04-08 | 日東電工株式会社 | 表面保護フィルム付き封止調光素子 |
Family Cites Families (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2357941B (en) * | 1996-07-31 | 2001-08-22 | Inmarsat Ltd | Method and apparatus for transmitting data |
US6167052A (en) | 1998-04-27 | 2000-12-26 | Vpnx.Com, Inc. | Establishing connectivity in networks |
GB9826158D0 (en) | 1998-11-27 | 1999-01-20 | British Telecomm | Anounced session control |
GB9826157D0 (en) | 1998-11-27 | 1999-01-20 | British Telecomm | Announced session control |
US6782490B2 (en) * | 1999-03-17 | 2004-08-24 | At&T Corp. | Network-based service for the repair of IP multicast sessions |
US6501763B1 (en) * | 1999-05-06 | 2002-12-31 | At&T Corp. | Network-based service for originator-initiated automatic repair of IP multicast sessions |
US6567929B1 (en) * | 1999-07-13 | 2003-05-20 | At&T Corp. | Network-based service for recipient-initiated automatic repair of IP multicast sessions |
PA8502401A1 (es) | 1999-09-17 | 2002-02-21 | Nagracard Sa | Procedimiento y sistema de transmision de una cadena de mensajes para banco de datos. |
US6993325B1 (en) | 2000-02-29 | 2006-01-31 | Ericsson Inc. | Method for facilitating electronic communications |
US6693907B1 (en) * | 2000-04-11 | 2004-02-17 | Sun Microsystems, Inc. | Method and system for measuring reception characteristics in a multicast data distribution group |
US7224702B2 (en) * | 2000-08-30 | 2007-05-29 | The Chinese University Of Hong Kong | System and method for error-control for multicast video distribution |
FR2819139B1 (fr) | 2001-01-03 | 2003-03-28 | Canal Plus Technologies | Procede et dispositif de gestion d'informations dans un systeme de communication interactif |
US20020116471A1 (en) | 2001-02-20 | 2002-08-22 | Koninklijke Philips Electronics N.V. | Broadcast and processing of meta-information associated with content material |
US6807578B2 (en) * | 2001-03-14 | 2004-10-19 | International Business Machines Corporation | Nack suppression for multicast protocols in mostly one-way networks |
US7693508B2 (en) * | 2001-03-28 | 2010-04-06 | Qualcomm Incorporated | Method and apparatus for broadcast signaling in a wireless communication system |
US6745364B2 (en) * | 2001-06-28 | 2004-06-01 | Microsoft Corporation | Negotiated/dynamic error correction for streamed media |
KR100391016B1 (ko) * | 2001-08-29 | 2003-07-12 | 한국전자통신연구원 | 엑스캐스트를 이용한 멀티캐스트 데이터 전송 방법 |
JP3912091B2 (ja) * | 2001-12-04 | 2007-05-09 | ソニー株式会社 | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム |
EP1337086B1 (en) | 2002-02-13 | 2006-07-19 | Matsushita Electric Industrial Co., Ltd. | Method for transmitting data packets using RTP and RTCP protocols |
US6677864B2 (en) * | 2002-04-18 | 2004-01-13 | Telefonaktiebolaget L.M. Ericsson | Method for multicast over wireless networks |
US20040057446A1 (en) | 2002-07-16 | 2004-03-25 | Nokia Corporation | Method for enabling packet transfer delay compensation in multimedia streaming |
US8411594B2 (en) | 2002-09-20 | 2013-04-02 | Qualcomm Incorporated | Communication manager for providing multimedia in a group communication network |
US7130282B2 (en) | 2002-09-20 | 2006-10-31 | Qualcomm Inc | Communication device for providing multimedia in a group communication network |
KR100477513B1 (ko) * | 2002-11-25 | 2005-03-17 | 전자부품연구원 | 이기종 프로토콜간 상호 데이터 전송을 위한 공통프로토콜 계층 구조 및 방법과 공통 프로토콜 패킷 |
US7296205B2 (en) * | 2004-02-18 | 2007-11-13 | Nokia Corporation | Data repair |
-
2004
- 2004-03-22 US US10/806,023 patent/US8296436B2/en not_active Ceased
-
2005
- 2005-03-17 EP EP05718227A patent/EP1728356B1/en active Active
- 2005-03-17 CN CNA200580009100XA patent/CN1934825A/zh active Pending
- 2005-03-17 AU AU2005226165A patent/AU2005226165B2/en not_active Ceased
- 2005-03-17 KR KR1020087008307A patent/KR100857187B1/ko active IP Right Grant
- 2005-03-17 KR KR1020077024637A patent/KR100855372B1/ko active IP Right Grant
- 2005-03-17 JP JP2007504500A patent/JP4550883B2/ja active Active
- 2005-03-17 KR KR1020067019693A patent/KR100809654B1/ko not_active IP Right Cessation
- 2005-03-17 WO PCT/IB2005/000718 patent/WO2005093998A1/en not_active Application Discontinuation
- 2005-03-17 CN CN2012105134588A patent/CN102984262A/zh active Pending
- 2005-03-18 TW TW094108268A patent/TW200539639A/zh unknown
-
2013
- 2013-04-15 US US13/863,006 patent/USRE45352E1/en active Active
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2008128409A1 (fr) * | 2007-04-24 | 2008-10-30 | Huawei Technologies Co., Ltd. | Procédé et appareil pour émettre et recevoir un message de notification à travers le protocole de distribution de fichier par transport unidirectionnel |
US8010626B2 (en) | 2007-04-24 | 2011-08-30 | Huawei Technologies Co., Ltd. | Method and apparatus for transporting/receiving notification messages via file delivery over unidirectional protocol |
CN101309437B (zh) * | 2007-05-17 | 2011-06-22 | 中兴通讯股份有限公司 | 单向文件传输方法及接口配置装置 |
CN110892756A (zh) * | 2017-07-20 | 2020-03-17 | 代傲表计系统有限公司 | 用于分配数据的方法 |
CN110892756B (zh) * | 2017-07-20 | 2023-06-20 | 代傲表计系统有限公司 | 用于分配数据的方法 |
Also Published As
Publication number | Publication date |
---|---|
KR100855372B1 (ko) | 2008-09-04 |
USRE45352E1 (en) | 2015-01-20 |
WO2005093998A1 (en) | 2005-10-06 |
US8296436B2 (en) | 2012-10-23 |
KR100809654B1 (ko) | 2008-03-05 |
JP2007531368A (ja) | 2007-11-01 |
CN102984262A (zh) | 2013-03-20 |
EP1728356B1 (en) | 2012-07-11 |
KR20080032663A (ko) | 2008-04-15 |
KR20060116032A (ko) | 2006-11-13 |
AU2005226165A1 (en) | 2005-10-06 |
KR100857187B1 (ko) | 2008-09-05 |
TW200539639A (en) | 2005-12-01 |
AU2005226165B2 (en) | 2008-10-09 |
KR20070112426A (ko) | 2007-11-23 |
JP4550883B2 (ja) | 2010-09-22 |
US20050207415A1 (en) | 2005-09-22 |
EP1728356A1 (en) | 2006-12-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1934825A (zh) | 通过通信协议传送广播/多播会话的参数 | |
CN1220359C (zh) | 通信终端、服务器、广播通信系统及方法 | |
CN1969528A (zh) | 用于点对多点传输系统的点对点修复响应机制 | |
CN1638321A (zh) | 发送设备和方法、接收设备和方法、存储介质以及程序 | |
CN1144441C (zh) | 移动通信系统中按照无线电链路协议发送可变长度数据的装置和方法 | |
CN1914922A (zh) | 内容的编码、分发及接收的方法、装置、系统以及程序 | |
CN1816053A (zh) | 基于会话初始化协议的流媒体直播p2p网络方法 | |
CN1387338A (zh) | 数据再现装置和数据再现方法 | |
CN1846420A (zh) | 嵌入的服务质量相关信息的传送 | |
CN1890944A (zh) | 用于web服务中介体的端口类型不可知的代理支持 | |
CN1819671A (zh) | 关于按键通话发言权和队列信息的方法及其相关装置 | |
CN1843050A (zh) | 无线通信网络中资源预留的方法和系统 | |
CN1335724A (zh) | 编码装置和编码方法 | |
CN1290445A (zh) | 用于媒体数据传输的方法和装置 | |
CN1801814A (zh) | 一种离线消息发送和接收方法 | |
CN1531282A (zh) | 分组中继装置 | |
CN1308437A (zh) | 用于媒体数据传输的方法和装置 | |
CN1685672A (zh) | 通信控制方法及系统,数据包转发及监测方法和系统 | |
CN1110883A (zh) | 拒收帧的隐蔽 | |
CN1801970A (zh) | 自动产生和/或控制有多个参加者的电信会议的方法及设备 | |
CN1526246A (zh) | 移动即时消息收发和存在服务 | |
CN1794705A (zh) | 即时消息用户使用其它即时消息系统聊天室的方法及系统 | |
CN1968251A (zh) | 数据通信装置 | |
CN1615646A (zh) | 通信装置 | |
CN1770805A (zh) | 计算机辅助管理电话会议的方法以及电话会议服务器装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20070321 |