专利名称：流会话期间的客户端反馈调度的制作方法
技术领域：
本发明一般涉及多媒体广播/多播业务(MB/MS)流服务。更具 体地，本发明涉及用于在MB/MS流会话期间受限(limited)用户反
馈的调度和传输机制。
背景技术：
本部分旨在提供背景或环境。此处的描述可以包括可能加以研 究的概念，但不必是先前设想或研究的的概念。因此，除非在此指 出，否则本部分所描述的内容对本申请中的权利要求书而言不是现 有技术，并且对于本部分中的结论而言也不是现有技术。
多媒体广播/多播业务(MB/MS)流服务便于在3G移动环境下 针对流行实时内容到多个接收方的资源有效传递。代替使用不同的 点对点(PtP)承载来将相同内容传递到不同移动设备，单个点对多 点(PtM )承载被用来在一个给定小区中将相同内容传递到不同的移 动设备。流内容可以包括视频、音频、SVG、时控文本和其他支持 的媒体。该内容可以被预先录制或从实时馈送中产生。
已经提出了多种用于传递过程的提议，这包括文件下载会话后 的PtP修复和下载会话或流会话后的内容传递确认报告。在下载会 话情况下，内容传递确认报告可以包括成功下载的文件的详情。在 流会话情况下，内容传递确认报告包括QoE度量(metrics )。在2004 年2月18日提交的，美国专利申请号10/782, 371题为"DATA REPAIR"，描述了用于减轻由于同时的PtP修复ifr求和内容传递确 认报告而引起的网络过载的机制，其与本申请受让人相同，并且通 过参考在此并入。该申请还介绍了随机后退时间和随机修复服务选 择的使用。该申请还定义了相关参数的信令，即最大后退时间和处
理修复或确认报告的服务器列表。然而，以上这些提出的机制都不
能处理在MBMS流会话期间的用户反々赍。
广播/多播流会话期间的用户反馈是所期望的特征，其有利于移 动电视或MBMS终端上的交互式编程。然而，目前的MBMSA见范 没有指定用于MBMS流会话期间的用户反馈的机制。来自多个 MBMS客户端的同时用户反馈可能导致服务器处反馈信息爆炸问 题，并且可能过载/阻塞网络资源。
因此，需要在MB/MS流会话期间调度和传输受限用户反馈的机 制。进一步，需要用于在广播或多播流会话期间调度客户端反馈的 相关信令信息。
发明内容
本发明一般涉及点对多播(PtM)流会话期间的可扩展反馈。广 播/多播流会话期间的用户反馈是所期望的特征，其可以有利于移动 TV或MBMS终端上的交互式编程。这种反々贵可以包4舌，例如，以 下(1 )移动TV观众在真人秀期间进行投票，(2)基于在当前流 会话期间接收到的得票数改变下一个流会话的内容，以及(3) SVG (可扩展矢量图形)内容中的动画，它在当需要在一定时间内将用 户响应发送到服务器时提示用户交互。
一个示例性实施方式涉及一种在点对多播(PtM)流会话期间提 供可扩展反馈的方法。该方法可以包括从发送方到至少一个接收方 传送数据以及在多播流会话期间从该至少 一 个接收方中的至少 一个 到发送方传送反馈。
另一示例性实施方式涉及在PtM流会话期间用以提供可扩展反 馈的系统、计算机程序以及设备。
图1是示出了根据示例性实施方式的一对多数据传输情况的示
图，图2是示出了根据示例性实施方式的"等待时间"和"最大后 退时间"参数的含义的示图，
图3是示出了根据示例性实施方式的接收方设备的示图， 图4是示出了根据示例性实施方式的发送方设备的示图。
具体实施例方式
图1示出了根据示例性实施方式的一对多数据传输情况。发送 方设备10是服务器、基于IP的设备、DVB设备、GPRS(或者UMTS ) 设备或类似的可以使用主动式前向纠错的设备，例如ALC (异步分 层编码)机制和/或FEC (前向纠错)机制，用于以 一对多方式将多 播数据块(或数据包)发送到接收方设备20。各接收设备20将关于 丢失数据块(没有被接收或者被错误接收的数据块)的否定应答 (NACK)消息(或请求)发送到发送方设备IO。作为对NACK消 息的响应，发送方设备10 —般在FLUTE(在单向传输上的文件传递) 会话(与针对原始传输建立的原始FLUTE会话或随后的FLUTE会 话相同的会话)期间将丢失数据块传输到接收方设备20。可选地， 使用另外一种并非FLUTE的协议的会话可以-波采用。
数据作为对象从发送方IO传输到接收方20。例如，文件、JPEG 图片、文件片都是对象。建立在发送方设备10和接收方设备20之 间的会话用于文件(或者数据)传递。单个会话可以包括单个或者 多个对象的传输。不同的标识符用来标识对象以及会话。
每一个数据块具有一个称为源块数(SBN)或类似名称的数字， 其标识各块。块由一组编码符号表示。每个编码符号标识符(ESI) 或类似标识符依次指示数据包(或数据块)的净荷中所携带的编码 符号如何从上述对象(例如文件)产生。
示例性实施方式提供了点对多播(PtM )流会话期间的可扩展反
相关传递过程的扩展以及RTCP反馈报告来实现。
以下是 一 个应用/内容驱动反馈实施的示例。如果在会话期间，PtM流内容需要用户反馈，那么PtM服务器描述相关的带外参数(例
如，在对应于相关的传递过程的SDP文件中)。这种参数的最小集
包括(1 )收集反馈的服务器的URI集以及(2)用于随机时间分散
的最大后退时间('maxBackOff(最大后退))。
在MBMS流会话期间，客户端应用或SVG动画可以提示用户输 入例如，选择是/否、选择最好、排出前三名等。 一旦提供(或者说在 时间='反馈时间'时)用户输入，则应用收集用户输入并将其存 储在緩冲器中用于向反馈收集服务器按进程传输。客户端中的传输 调度器在'0，和'最大后退，之间产生一个随机数'X，。然后计 算出实际传输时间^反馈时间+X。从预先在SDP中发送的URI集中 随机地选择反馈收集服务器。当目前时间='实际传输时间，时，建 立到随机选定的URI的TCP连接。将用户响应嵌入4吏用HTTP POST 方法发送的XML对象中。
用户反馈可以在XML对象中被才各式化。XML对象包括必需的 参数来标识反馈、流会话和客户端ID。通过指定到对应XML才莫式 的扩展将应用特定反馈包含于XML对象中。
在一个MBMS流会话期间的用户反々贵可以由在MBMS中定义的 用于相关传递过程的XML模式的简单扩展提供。以下是MBMS中 到相关传递过程的扩展的实施的示例。
在对应于如下文简单代码中所示的'相关传递过程，的XML才莫 式中引入了用户反馈类型的一种新的类型元素。所需的元件'服务 器URI，指定了从客户端收集反馈的服务器列表的URI。图2示出 了 '等待时间，和'最大后退，参数的定义。收集反馈后，客户端 等候'等待时间，的时间单元并且在'0，和'最大后退，之间产生 随机数'X，。等候了多于'X，个时间单元后，客户端发送反馈。 该反馈使用HTTP/TCP被可靠地发送。
< xml version="]，0" encoding="UTF-8" >
<xs:schemax mlns:xs="hup:〃www.\v3.org/2001/XMLSchema" elementFormDefauIt="qualified"> <xs:element name=''assotiatedProcedureDescriptionn type="associatedProcedureType7> <xs:compIexType name二" associatedProcedureType"> <xs;sequence〉
<xs;element riame=''postFileRepair''type="basicProcedureType'' minOccurs="0"maxOccurs="I7〉 <xs:element name="bmFileRepair'' type=" bmFileRepairType" minOccurs="0" maxOccurs="r7> <xs:elemenl name="postReceptionReport" type='lrepo^tProceciureType''minOcclIrs=''0', maxOccurs =''l"/> <xs:e!ement name=''userFeedbackReport" type="feedbackProcediireType''minOccurs="0" niaxOccurs二"r/〉
</xs:sequence> </xs: complex丁yp〉
<xs:complexType name="basicProcedureType"> <xs:sequcnce>
〈xs:element name="serverURT type-"xs:anyURT minOccurs='T' maxOccurs="unbounded'7> </xs:sequence>
<xs:attribute name="waitTime"type=''xs:unsignedLong" use="optionaI"/>
<xs:attribute name="maxBackOfF' type="xs:unsignedLong'' use="required"/> </xs: complexType〉
<xs:complexType name="bmFileRepairType">
<xs:attribute name="sessionDescriptionURT type="xs:anyURI " use="required"/> </xs: complexType>
<xs:complexType name="repairProcedureType"> <xs:simpIeContent>
<xs:extension base="basicProcedureType"> <xs;attrjbute name二"samplePercerUage" type="xs:string" use="optionar'/>
<xs;attribute name-forceTiminglndependence" type=''xs:boolean" use="optionai"/> <xs:attribute name="reportType" type="xs:string" use="optional"/> </xs:extension> </xs:simpleContent〉 </xs;complexType>
"report-type" value = "rack" || "star" || "star-all"
<xs: complexType name="userFesdbackProcedureType"> <xs:simpleContent>
<xs:extension base="basicProcedureType"〉
<xs:attribute name二"feedbackReportType'' type="xs:string" use ="optional7〉
</xs:cxtcnsion>
</xs:simpeContenl>
</xs;complexType>
</xs:schcma〉
feedbacldteportType = ("yesNo，， 1| "bestOne'， [| "ranking"}
MBMS流服务器决定在MBMS流会话期间收集一定类型的反 馈。例如，反馈类型可以是'是/否投票，、'一组选项(A/B/C/..) 中最佳的'、'排名，等等..。客户端应用在需要的时刻收集适合类 型的反馈。客户端应用还将该反馈格式化到XML对象中以便随后使 用HTTP POST方法进行传输。
用户可以在MBMS流会话期间的多个时刻提供相同类型的反 馈。对应于客户端反馈的XML对象可以包括唯一标识各反馈的某个
装置，诸如，例如，对应于客户端反馈被收集时刻的时间戳。在其 他一些实施方式中，反馈计数器可以被用来记录各种反馈实例。其
他诸如客户端ID，服务器URI等等这样的有用信息可选地被包含在 对应用户反^i;贵的XML对象中。
对应每种类型的反馈的XML模式可以如下面的简单代码中所示 那样定义。客户端应用将该反馈格式化到使用这个XML模式的XML 对象中。
< xml version="1.0" encoding="UTF-8" >
<xs:schema xmlns;xs="http:〃www.w3.org/200I/XMLSchema" elementFormDefauIt="qualified">
<xs:elemei，t name="userFeedbackReport">
<xs:choice〉
<xs:dement name二"simpIeYesNoVote" type="yesNoType7> 〈xs:eiement name二"bestAmongAGro叩"type="bestOneType'7〉 <xs:element name="rankInASpecificOrder" type="rankingType7>
</xs:choice>
</xs:element>
<xs:comp]exType name="yesNoType"> <xs:scqucncc〉
<xs:element name="yesNoVote" type-"xs:boolean" minOccurs="0" max〇ccurs='T'/〉 <xs:element name二"timeStamp" type="xs:string" minOccurs="0" maxOccurs='' 17> <xs:attribute name=''sessionId" type=''xs:string" use="optional"/> <xs:attribute name="sessionType" type="xs;string" use="optionar/> <xs:attribute name=''servicdd" type="xs:string" use="optionar/> <xs:attribute name="dientld" type-"xs:string" use="optiona'7> <xs:attribute name="serverURr type="xs:anyURr use="optional'V> </xs:sequence> </xs:complexType>
<xs:complexType name="bestOneType">
<xs:simpleContent>
<xs:element name="bestOneVote" type="xs:string" minOccurs-"O" maxOccurs=" 1 7>
<xs:element name=''timeStamp" type="xs:string" minOccurs-"O" maxOccurs=" 1 7>
<xs:attribute name二"sessionld" type="xs:string" use="optional7>
<xs:attribute name="sessionType" type-"xs:string" use="optional"/> <xs:attribute name="serviceld" typeyxs:string" use="optionar'/>
<xs:attribute name="clientld" type="xs:string'' use="optional7> <xs:attribute name二"serverURr type="xs:anyURJ" use="optional7> </xs:simpleContent>
</xs:complexType>
<xs:complexType name="rankingType"> <xs:simpleContent>
<xs:element name-"rankString" type="xs:string" minOccurs="0" maxOccurs=" 1 "/> <xs:element name="timeStamp" type="xs:string" minOccurs="0" maxOccurs="r/> <xs:attribute name=''sessionId" type="xs:string" use="optional7> <xs:attdbute name="sessionType" type="xs:stritig" use="optional7> <xs:attribute name-"serviceld" type="xs:string" use="optional'7> <xs:attribute name="clientld" type-"xs:string" use="optionar7> <xs:attribute name="serverURr type="xs:anyUR_r use=" optional7> </xs:simpleContent> </xs; complexType> </xs:complexType〉 </xs;schema>
对应于多个反馈实例的XML对象可以使用多部分-MIME结构
来聚集。
接下来是RTCP(实时控制协议)反馈报告实现的示例。发送方从 多个接收方请求反馈，经由在RTP或RTCP流中下行链^各方向上的 带外或下行链路方向上的带内服务声明信道(SDP、 XML、 FLUTE 等等)上发送反馈标记(例如通过采用具有适当字段扩展的RTP报 头、或者具有适当字段扩展的RTCP APP包)。该字段包括反馈的 指示器(指示反馈被请求)、以及可选地包括时间指示器(指示反 馈何时被请求)、以及指示被请求以发送反馈的接收方的百分比的 数字。
接收方提取一个随机数字，并且如果该数字小于或等于指示接 收方(由发送方接收的)的百分比数字，则接收方立即发送RTCP 报告(或任何其他质量报告)或者采用由发送方传送到接收方的定
时规则。
图3示出了根据示例性实施方式的接收方设备20。通信系统包 括发送方设备10、传输网络30 (例如IP网络或另一固定网络、无 线网络或固定网络与无线(蜂窝)网络的组合等)以及接收方设备 20。接收方设备20可以是蜂窝电话、卫星电话、个人数字助理或者 蓝牙设备、WLAN设备、DVB设备或其他类似的无线设备。设备20 包括内部存储器21、处理器22、操作系统23、应用程序24、网络
接口 25以及NACK和修复机制26。内部存储器21容纳处理器22、 操作系统23和应用程序24。 NACK和修复机制26使得否定应答和 修复过程能够响应于数据传输中的丟失数据或受损数据。设备20能 经由网络接口 25和网络30与发送方设备10以及其他设备进行通信。
图4示出根据示例性实施方式的发送方设备10。发送方设备10 可以是，例如，网络服务器或用于文件(或媒体)传递的任何合适 的设备。设备10包括内部存储器11、处理器12、操作系统13、应 用程序14、网络接口 15、传输和修复机制16以及数据存储器17。 内部存储器11容纳处理器12、操作系统13和应用程序14。传输和 修复机制16使数据包能够传输到接收方设备20。进一步地，传输和 修复机制16还能够在修复会话中重新传输数据包。待发送到接收方 设备20的数据和待重新传输的数据可以被存储在数据存储器17中。 可选地，数据也可以被存储在与发送方设备IO共址或者位于发送方 设备10之外的独立设备中。设备10能经由网络接口 15和网络30 与接收方设备20以及其他设备进行通信。
尽管已经描述了本发明的几个实施方式，但是本领域技术人员 应该理解本发明所包含的修改和变化。因此，随附于本说明书的权 利要求书旨在精确地限定本发明。
权利要求
1.一种在点对多播(PtM)流会话期间提供可扩展反馈的方法，该方法包括从发送方到至少一个接收方传送数据；以及在多媒体流会话期间从所述至少一个接收方中的至少一个到所述发送方传送反馈。
2. 根据权利要求1所述的方法，进一步包括提示所述至少一个 接收方进行输入。
3. 根据权利要求2所述的方法，进一步包括提供用于从所述至 少 一个接收方收集输入的参数和用于随机时间分散的最大后退时 间。
4. 根据权利要求2所述的方法，进一步包括使用相关传递过程 的扩展在多媒体流会话期间从所述至少 一 个接收方提供输入。
5. 根据权利要求2所述的方法，其中用于来自所述至少一个接
6. 根据权利要求5所述的方法，进一步包括从所述至少一个接 收方提取随机数，以及如果所述随机数小于或等于指示了接收方与 所述发送方进行传送的百分比的数字，则发送质量报告。
7. —种用于在点对多播(PtM)流会话期间提供可扩展反馈的 系统，该系统包4舌发送方设备，其发起多媒体会话并且在多媒体流会话期间经由 通信网络传送多媒体数据；以及接收方设备，其在PtM多媒体流会话期间响应于提示而传送反 馈到所述多媒体数据。
8. —种在多媒体广播流中使用的计算机程序产品，该计算机程 序产品包括用以从发送方到至少 一 个接收方传送数据的计算机代码；以及用以在点对多播多媒体流会话期间从所述至少一个接收方中的 至少 一 个到所述发送方传送反馈的计算机代码。
9. 一种在网络上多媒体会话中进行通信的设备，该设备包括 处理器，执行指令以便将多媒体数据传送到至少 一 个接收方；以及存储器，存储在点对多播多媒体流会话期间用于随机时间分散 的最大后退时间以及从所述至少 一 个接收方收集的输入。
10. —种在网络上多媒体会话中进行通信的设备，该设备包括: 处理器，接收来自发送方设备的多媒体数据；以及程序指令，提供对在点对多播多媒体流会话期间响应于接收的 多媒体数据的输入的传送。
全文摘要
本发明一般涉及包括在点对多播(PtM)流会话期间的可扩展反馈与在广播/多播流会话期间的用户反馈的系统和方法。在PtM流会话期间提供可扩展反馈的方法可以包括从发送方到至少一个接收方传送数据以及在多媒体流会话期间从该至少一个接收方中的至少一个到发送方传送反馈。
文档编号H04L12/56GK101341693SQ200680022933
公开日2009年1月7日 申请日期2006年5月2日 优先权日2005年5月3日
发明者D·莱昂, I·屈尔西奥, R·维丹萨姆 申请人:诺基亚公司