CN101110722A - 广播组播业务中的接收上报方法以及接收上报处理装置 - Google Patents

Abstract

本发明提供了一种广播组播业务中的接收上报方法以及一种接收上报处理装置，其中，该方法包括：步骤S302，广播组播业务中心生成接收上报关联分发流程描述文件并将所述描述文件发送至一个或多个用户设备，其中，所述描述文件包括要求所述用户设备发送的接收上报消息的类型信息；步骤S304，所述一个或多个用户设备接收到所述接收上报关联分发流程描述文件后对其进行解析并确定要求的接收上报消息的上报类型；以及步骤S306，所述用户设备生成要求类型的接收上报消息并将其发送至接收上报服务器。本发明通过指示用户设备上报特定类型的接收上报消息，使得不会发生接收上报类型的错误，提高了广播组播业务的效率。

Description

广播组播业务中的接收上报方法以及接收上报处理装置

技术领域

本发明涉及通信领域，尤其涉及一种广播组播业务中的接收上报方法以及接收上报处理装置。

背景技术

在各种移动分组业务中，包括视频点播、电视广播、视频会议、网上教育、互动游戏等业务具有一个主要特征，就是订阅该业务的多个用户同时接收相同的数据，而且这业务和一般数据相比，往往具有并发用户多、数据量大、持续时间长、时延敏感等特点。显然，对这类业务仍然沿用普通点到点传输方法，对于资源紧缺的移动通信网络而言是非常低效率的。为此，3GPP(第三代合作项目)针对这一类广播和组播业务的传输需求，在Release 6引入MBMS(Multimedia Broadcast Multicast Service，多媒体广播和组播业务)技术，在移动网络中提供一个数据源向多个用户发送数据的点到多点业务，实现网络资源共享，提高网络资源的利用率，尤其是空口接口资源。3GPP定义的MBMS不仅能实现纯文本低速率的消息类组播和广播，而且还能实现高速多媒体业务的组播和广播，这无疑顺应了未来移动数据发展的趋势。

根据3GPP的规范“3GPP TS 26.346Multimedia Broadcast/Multicast Service(MBMS)Protocols and codecs，V6.3.0，2005-12”，基于MBMS的分发业务分三个功能层(如图1所示)，即承载层(Bearers)，分发方法(Delivery Method)层与用户业务(UserService)层。承载层是基于MBMS业务的基础，提供了IP数据传输的机制，以一对多的方式传输组播和广播业务。分发方法层提供安全性及密钥分发，采用前向纠错FEC(Forward-error-Correction)的可靠性控制，以及文件修复、分发验证等功能。主要有两种分发方法，即下载(Download)和流(Streaming)方法。用户业务层主要是各种应用，不同的应用采用不同的分发方法将内容分发给MBMS订阅用户。

超文本标准语言HTML(Hypertext Markup Language)是一种用来对用Web浏览器表示的信息进行编码的特定标志语言。可以说，当今世界互联网的蓬勃发展，HTML立下了汗马功劳。可是，HTML自身的特点使它蕴藏了许多危机，随着它不断的发展，这些危机不但没有减弱，反而越来越突出，甚至成为了HTML继续发展应用的障碍。可扩展标准语言XML(eXtensible Markup Language)开创了Web的新纪元，它建立了一种传输结构化数据的方法。

传统上，确认XML文件需要使用文件类型定义(DTD，Document Type Definition)，这是继承自SGML(Standard GeneralizedMarkup Language，标准通用标记语言)的。虽然DTD在以确认为目的的设置文件格式方面非常有用，他们也有很多的确定。XMLSchema是W3C的推荐标准，于2001年5月正式发布，经过数年的大规模讨论和开发，终于最终奠定下来，使得XML建模有了一个国际标准。XML Schema一确定下来，立刻成为全球公认的首选XML环境下的建模工具，已经基本取代了DTD在XML刚刚成为W3C推荐标准时的地位。按照W3C的定义，Schema是“一个XML文件的结构绑定和信息集管理的规则的集合”。

XML Schema的主要目的是用来定义一类XML文档(一个XML Application)。因此模式的“实例文档”形式常常用来描述一个与特定XML Schema相一致的XML文档。事实上，文档实例和Schema文档都不是必须要以文档的形式存在，他们可以以在应用之间传递的字节流的形式存在，或者作为一个数据库记录或者作为XML的“信息项”的集合而存在。

MBMS用户业务与MBMS系统间的接口主要有三个实体：广播组播业务中心(Broadcast Multicast Service Center，简称BM-SC)，网关GPRS业务点(Gateway GPRS Serving Node，简称GGSN)以及用户设备(User Equipment，简称UE)。MBMS用户业务体系架构是基于UE侧的MBMS接收机(MBMS receiver)和网络侧的广播组播业务中心。其中广播组播业务中心的功能结构如图2所示。

如图2所示，广播组播业务中心主要具有如下功能：

用户业务发现与声明(User Service Discovery/Announcement)，提供业务描述以及业务内容中的应用参数给终端用户。

密钥请求(Key Request)与注册(Registration)流程，用于接收密钥以及密钥更新。

密钥分配(Key Distribution)，用于广播组播业务中心分配接入业务数据与分发内容的密钥资料。

会话与传输(Session and Transmission)功能，进一步分为广播组播业务中心分发(MBMS Delivery)功能和关联分发(AssociatedDelivery)功能。关联分发功能为多媒体广播和组播业务用户业务、多媒体广播和组播业务分发方法及其会话提高辅助特征。其中，3GPP TS 26.346支持的关联分发流程有：多媒体广播和组播业务下载接收机支持文件修复过程(File repair procedure)、接收上报流程(reception reporting procedure)、以及多媒体广播和组播业务流接收机支持接收上报流程(reception reporting procedure)。

对于多媒体广播和组播业务下载分发来说，接收上报流程用来报告一个或多各文件的完全接收。对于多媒体广播和组播业务流分发来说，接收上报流程用来报告流的相关统计信息。

如果广播组播业务中心提供请求接收上报信息的参数，那么多媒体广播和组播业务接收机应确认接收的内容。

如果请求用于统计目的的接收上报，那么广播组播业务中心可以指定多媒体广播和组播业务接收机可能执行的接收上报的百分比子集。

关联分发流程的关联流程描述实例(description instance)可以通过如下方式分发到客户端：一是在多媒体广播和组播业务下载分发会话之前与会话描述(session description)在用户业务声明与发现一起分发；也可在多媒体广播和组播业务下载分发会话带内分发。在XML中，每个关联分发流程入口(entry)用一个元素“associatedProcedureDescription”来配置。一个关联分发流程的所有配置参数包含在元素“associatedProcedureDescription”的属性中。元素“associatedProcedureDescription”的元素(如“postFileRepair”和“postReceptionReport”)表示其配置的关联流程。接收上报关联分发流程描述的XML Schema具有如下特征：

(1)具有一个表示基本流程类型的复合类型(“basicProcedureType”)，该类型主要包括：一个表示服务器统一资源标识的元素(“serviceURI”)，一个表示多媒体广播和组播业务客户端在多媒体广播和组播业务数据传输结束后到开始上报流程等待的时间的属性(“offsetTime”)，该属性是可选的，且为无符号整型；具有一个表示多媒体广播和组播业务客户端初始化接收上报流程的时间窗长度的属性(“randomTimePeroid”)，该属性是必须的，且为无符号整型。

(2)具有一个表示接收上报类型的复合类型(“reportProcedureType”)，该类型继承于“basicProcddureType”类型，该类型具有一个属性“samplePercentag”用来设置上报接收情况的接收机的取样的百分比。samplePercentage的取值范围为0到100，可带小数，不过小数点后最多不超过3位(如67.323就可保证精度了)，该属性的use属性为“optional”，缺省属性值为”100”；具有一个布尔类型的属性“forceTimeIndependence”，该属性表示UE是否用文件修复点到点连接来发送接收上报消息，该属性的use属性值为“optional”，缺省属性为“false”；具有一个表示上报类型的属性“reportType”，该属性的类型为“xs:string”类型，该属性的use属性值为“optional”。

(3)该接收上报关联分发流程描述的XML Schema具有一个元素“postReceptionReport”，该元素的type属性值为“reportProcedureType”，该元素的minOccurs属性值为“0”。

在现有技术一MBMS接收上报(reception reporting)关联分发流程描述的XML Schema中，属性“reportType”的use属性值为“optional”，即属性“reportType”是可选的。而属性“reprotType”表示的是接收上报的类型，根据3GPP TS 26.36的定义，只存在三种上报类型，即RAck类型，StaR类型和StaR-all类型。为RAck类型时，仅仅报告成功接收文件，而不报告详细细节。为StaR类型时，报告文件成功接收(如RAck)及用于统计分析的接收详细信息。为StaR-all类型时，需报告文件成功接收及用于统计分析的接收详细信息，还得报告文件失败接收。由于属性reportType是可选的，这样在不指定上报类型的类型时，接收端将不知道采用何种类型的上报方式，这样会导致系统处理错误。另一方面，属性reportType只能取RAck、StaR、StaR-all三种类型中的一种，而技术一只是简单的将其定义为“xs:string”类型，这样一方面可能会导致XML格式的非良好性，另一方面也可能导致客户端无法识别上报类型而导致错误。

发明内容

针对现有技术中由于接收上报关联分发流程的XML Schema设计不合理可能导致接收端无法识别接收上报类型，从而导致无法及时实施接收上报而引起错误，本发明提供了一种广播组播业务中的接收上报方法以及一种接收上报处理装置。

本发明的广播组播业务中的接收上报方法包括以下步骤：步骤S302，广播组播业务中心生成接收上报关联分发流程描述文件并将描述文件发送至一个或多个用户设备，其中，描述文件包括要求用户设备发送的接收上报消息的类型信息；步骤S304，一个或多个用户设备接收到接收上报关联分发流程描述文件后对其进行解析并确定要求的接收上报消息的上报类型；以及步骤S306，用户设备生成要求类型的接收上报消息并将其发送至接收上报服务器。

上述的接收上报消息的类型信息可以通过接收上报消息类型(ReportType)的类型来限定。接收上报消息类型的类型必须是以下三个枚举值中的一个：接收确认RAck、成功接收的统计报告StaR、以及所有内容接收的统计报告StaR-all。接收上报消息类型的缺省类型为接收确认RAck。

上述的接收上报消息的类型信息可以通过将接收上报消息类型绑定于一个简单类型来限定。该简单类型包括以下三个枚举值：接收确认RAck、成功接收的统计报告StaR、以及所有内容接收的统计报告StaR-all。接收上报消息类型的缺省类型为接收确认RAck。

在接收上报消息的类型信息为接收确认类型RAck的情况下，用户设备上报成功接收文件的信息，不上报成功接收的详细信息。

在要求的接收上报消息的类型信息为成功接收的统计报告StaR的情况下，用户设备上报成功接收统计报告的信息、成功接收文件的信息以及用于进行统计分析的详细信息。

在要求的接收上报消息的类型信息为所有内容接收的统计报告StaR-all的情况下，用户设备上报成功接收文件的信息、成功接收统计报告的信息、用于进行统计分析的信息、以及接收文件失败的信息。

本发明的接收上报处理装置包括：用户业务声明模块，用于生成接收上报关联分发流程描述文件并将描述文件发送至交互分发模块或会话与传输模块，其中，描述文件包括要求用户设备发送的接收上报消息的类型信息；交互分发模块，用于在与一个或多个用户设备进行交互的情况下，将接收上报关联分发流程描述文件发送至一个或多个用户设备；以及会话与传输模块，用于在与一个或多个用户设备进行会话的情况下，将接收上报关联分发流程描述文件发送至一个或多个用户设备。

上述的接收上报消息的类型信息可以通过接收上报消息类型的类型来限定。接收上报消息类型的类型必须是以下三个枚举值之一：接收确认RAck、成功接收的统计报告StaR、以及所有内容接收的统计报告StaR-all。接收上报消息类型的缺省类型为接收确认RAck。

上述的接收上报消息的类型信息可以通过将上报消息类型一个简单类型来限定。简单类型包括以下至少一个枚举值：接收确认RAck、成功接收的统计报告StaR、以及所有内容接收的统计报告StaR-all。接收上报消息的缺省类型为接收确认RAck。

在接收上报消息的类型信息为接收确认类型RAck的情况下，指示用户设备上报成功接收文件的信息，不上报成功接收的详细信息。

在要求的接收上报消息的类型信息为成功接收的统计报告StaR的情况下，指示用户设备上报成功接收统计报告的信息、成功接收文件的信息以及用于进行统计分析的详细信息。

在要求的接收上报消息的类型信息为所有内容接收的统计报告StaR-all的情况下，指示用户设备上报成功接收文件的信息、成功接收统计报告的信息、用于进行统计分析的信息、以及接收文件失败的信息。

本发明能够使接收上报关联分发流程的XML Schema设计更加合理，使接收端正确地识别接收上报类型，从而避免实施接收上报而引起错误。

附图说明

附图提供本发明的进一步理解，并结合到本申请中构成本申请的一部分，与说明书一起说明本发明的实施例以解释本发明的原理。在附图中，

图1是根据现有技术的多媒体广播和组播业务功能层的示意图；

图2是根据现有技术的广播组播业务中心的功能结构的示意图；

图3是根据本发明的广播和组播业务中的接收上报方法的流程图；以及

图4是根据本发明的广播组播业务处理装置的示意图。

具体实施方式

以下将参考附图详细描述本发明。

图3是根据本发明的广播和组播业务中的接收上报方法的流程图。如图3所示，本发明的广播组播业务中的接收上报方法包括以下步骤：步骤S302，广播组播业务中心生成接收上报关联分发流程描述文件并将描述文件发送至一个或多个用户设备，其中，描述文件包括要求用户设备发送的接收上报消息的类型信息；步骤S304，一个或多个用户设备接收到接收上报关联分发流程描述文件后对其进行解析并确定要求的接收上报消息的上报类型；以及步骤S306，用户设备生成要求类型的接收上报消息并将其发送至接收上报服务器。

上述的接收上报消息的类型信息可以通过接收上报消息类型的类型来限定。接收上报消息类型的类型必须是以下三个枚举值之一：接收确认RAck、成功接收的统计报告StaR、以及所有内容接收的统计报告StaR-all。接收上报消息类型的缺省类型为接收确认RAck。

上述的接收上报消息的类型信息可以通过将接收上报消息的类型绑定于一个简单类型来限定。该简单类型包括以下三个枚举值：接收确认RAck、成功接收的统计报告StaR、以及所有内容接收的统计报告StaR-all。接收上报消息类型的缺省类型为接收确认RAck。

在接收上报消息的类型信息为接收确认类型RAck的情况下，用户设备上报成功接收文件的信息，不上报成功接收的详细信息。

在要求的接收上报消息的类型信息为成功接收的统计报告StaR的情况下，用户设备上报成功接收统计报告的信息、成功接收文件的信息以及用于进行统计分析的详细信息。

在要求的接收上报消息的类型信息为所有内容接收的统计报告StaR-all的情况下，用户设备上报成功接收文件的信息、成功接收统计报告的信息、用于进行统计分析的信息、以及接收文件失败的信息。

图4是根据本发明的广播组播业务处理装置的示意图。如图4所示，本发明的接收上报处理装置400包括：用户业务声明模块402，用于生成接收上报关联分发流程描述文件并将描述文件发送至交互分发模块或会话与传输模块，其中，描述文件包括要求用户设备发送的接收上报消息的类型信息；交互分发模块404，用于在与一个或多个用户设备进行交互的情况下，将接收上报关联分发流程描述文件发送至一个或多个用户设备；以及会话与传输模块406，用于在与一个或多个用户设备进行会话的情况下，将接收上报关联分发流程描述文件发送至一个或多个用户设备。

上述的接收上报消息的类型信息可以通过接收上报消息类型的类型来限定。接收上报消息类型的类型必须是以下三个枚举值之一：接收确认RAck、成功接收的统计报告StaR、以及所有内容接收的统计报告StaR-all。接收上报消息类型的缺省值为接收确认RAck。

上述的接收上报消息的类型信息可以通过将接收上报消息类型绑定于一个简单类型来限定。简单类型包括以下三个枚举值：接收确认RAck、成功接收的统计报告StaR、以及所有内容接收的统计报告StaR-all。接收上报消息类型的缺省类型为接收确认RAck。

在接收上报消息的类型信息为接收确认类型RAck的情况下，指示用户设备上报成功接收文件的信息，不上报成功接收的详细信息。

在要求的接收上报消息的类型信息为成功接收的统计报告StaR的情况下，指示用户设备上报成功接收统计报告的信息、成功接收文件的信息以及用于进行统计分析的详细信息。

在要求的接收上报消息的类型信息为所有内容接收的统计报告StaR-all的情况下，指示用户设备上报成功接收文件的信息、成功接收统计报告的信息、用于进行统计分析的信息、以及接收文件失败的信息。

本发明的多媒体广播组播中关联分发流程中接收上报的XMLSchema设计，包含一个表示接收上报的元素(“postReceptionReport”)，并具有如下特征：

(1)具有一个表示上报类型的属性，该属性的use属性值为“optional”，该属性的缺省属性为“RAck”；将该属性记为“reportType”，则用XML Schema规范表示为：

<xs:attribute name＝“reportType”use＝”optional”default＝”RAck”/>

(2)如(1)所述，该表示上报类型的属性(reportType)的type属性为“reportTypeType”，该“reportTypeType”表示上报类型的类型，该类型有三个枚举(enumeration)值(“RAck”，“StaR”，“StaR-all”)，即(1)中表示上报类型的属性(reportType)只能取“RAck”、“StaR”、“StaR-all”三者中之一。

设置reportType为RAck(Reception Acknowledgement，接收确认)，仅报告成功接收文件，而不报告详细细节。

设置reportType为StaR(Statistical Reporting for successfulreception，成功接收统计报告)，报告文件成功接收(如RAck)及用于统计分析的接收详细信息。

设置reportType为StaR-all(Statistical Reporting for all contentreception，所有内容接收的统计报告)，同StaR，需报告文件成功接收及用于统计分析的接收详细信息，还得报告文件失败接收。

用XML Schema规范表示如下：

<xs:simpleType name＝”reportTypeType”>

   <xs:restriction base＝”xs:string”>

      <xs:enumeration value＝“RAck”/>

      <xs:enumeration value＝“StaR”/>

      <xs:enumeration value＝”StaR-all”/>

   </xs:restriction>

</xs:simpleType>

<xs:attribute name＝“reportType”type＝“reportTypeType”use＝”optional”default

＝”RAck”/>

(3)如(1)所述，该表示上报类型的属性(reportType)绑定于一个简单类型，该简单类型有三个枚举值(“RAck”，“StaR”，“StaR-all”)，即(1)中表示上报类型的属性(reportType)只能取“RAck”，“StaR”，“StaR-all”三者中之一。

设置reportType为RAck，仅报告成功接收文件，而不报告详细细节。

设置reportType为StaR，报告文件成功接收(如RAck)及用于统计分析的接收详细信息。

设置reportType为StaR-all，同StaR，需报告文件成功接收及用于统计分析的接收详细信息，还得报告文件失败接收。

用XML Schema规范表示如下：

<xs:attribute name＝“reportType”use＝”optional”default＝”RAck”>

   <xs:simpleType>

      <xs:restriction base＝”xs:string”>

         <xs:enumeration value＝“RAck”/>

         <xs:enumeration value＝“StaR”/>

         <xs:enumeration value＝”StaR-all”/>

      </xs:restriction>

   </xs:simpleType>

</xs:attribute>

(4)如(2)或(3)所述，具有一个用来设置上报接收情况的接收机的取样的百分比的属性，记为samplePercentage。samplePercentage的取值范围为0到100，可带小数，不过小数点后最多不超过3位(如67.323就可保证精度了)。samplePercentage用于StaR和StaR-all，但不用于RAck。当sample的值为100时，处于关联会话的UE将发送接收报告。对于报告类型为StaR和StaR-all，且samplePercentage的值小于100，UE将产生一个0与100之间均匀分布的随机数，当这个随机数小于samplePercentage的值时，UE发送接收报告。用XML Schema规范表示如下：

<xs:attribute name＝”samplePercentage”type＝”xs:decimal”use＝“optional“default＝”100”/>

(5)如(2)或(3)所述，还具有一个表示UE是否用文件修复点到点连接来发送接收上报消息的属性，记为forceTimeIndependence，该属性为布尔类型且可选，默认值为“false”，当该属性为真时，UE将不使用文件修复点到点连接来发送接收上报消息，否则可以发起点到点连接来发送接收上报消息。用XML Schema规范表示如下：

<xs:attribute name＝”forceTimeIndependence”type＝”xs:Boolean”use＝”optional”default＝”false”/>

(6)基于(1)、(2)、(4)、(5)设计接收上报关联分发流程的XML Schema具有如下特征：

(a)具有一个表示基本流程类型的复合类型(“basicProcedureType”)，该类型主要包括：一个表示服务器统一资源标识的元素(“serviceURI”)，一个表示MBMS客户端在MBMS数据传输结束后到开始上报流程等待的时间的属性(“offsetTime”)，该属性是可选的，且为无符号整型；具有一个表示MBMS客户端初始化接收上报流程的时间窗长度的属性(“randomTimePeroid”)，该属性是必须的，且为无符号整型。

(b)具有一个表示接收上报类型的复合类型(“reportProcedureType”)，该类型继承于“basicProcddureType”类型，该类型具有一个属性“samplePercentag”用来设置上报接收情况的接收机的取样的百分比。samplePercentage的取值范围为0到100，可带小数，不过小数点后最多不超过3位(如67.323就可保证精度了)，该属性的use属性为“optional”，缺省属性值为”100”；具有一个布尔类型的属性“forceTimeIndependence”，该属性表示UE是否用文件修复点到点连接来发送接收上报消息，该属性的use属性值为“optional”，缺省属性为“false”；具有一个表示上报类型的属性“reportType”，上报类型的属性(reportType)的类型属性为“reportTypeType”，该“reportTypeType”表示上报类型的类型，该类型有三个枚举值(”RAck”，”StaR“，”StaR-all”)，reportType属性的use属性值为“optional”，上报类型的属性的缺省属性为“RAck”。

(c)该接收上报关联分发流程描述的XML Schema具有一个元素“postReceptionReport”，该元素的type属性值为“reportProcedureType”，该元素的minOccurs属性值为“0”。

(7)基于(1)、(3)、(4)、(5)设计接收上报关联分发流程的XML Schema具有如下特征：

(a)具有一个表示基本流程类型的复合类型(“basicProcedureType”)，该类型主要包括：一个表示服务器统一资源标识的元素(“serviceURI”)，一个表示MBMS客户端在MBMS数据传输结束后到开始上报流程等待的时间的属性(“offsetTime”)，该属性是可选的，且为无符号整型；具有一个表示MBMS客户端初始化接收上报流程的时间窗长度的属性(“randomTimePeroid”)，该属性是必须的，且为无符号整型。

(b)具有一个表示接收上报类型的复合类型(”reportProcedureType”)，该类型继承于“basicProcddureType”类型，该类型具有一个属性“samplePercentag”用来设置上报接收情况的接收机的取样的百分比。samplePercentage的取值范围为0到100，可带小数，不过小数点后最多不超过3位(如67.323就可保证精度了)，该属性的use属性为“optional”，缺省属性值为”100”；具有一个布尔类型的属性“forceTimeIndependence”，该属性表示UE是否用文件修复点到点连接来发送接收上报消息，该属性的use属性值为“optional”，缺省属性为“false”；具有一个表示上报类型的属性“reportType”，该表示上报类型的属性(reportType)绑定于一个简单类型，该简单类型有三个枚举值(“RAck”，“StaR”，“StaR-all”)，上报类型的属性的use属性值为“optional”，reportType属性的缺省属性为“RAck”。

(c)该接收上报关联分发流程描述的XML Schema具有一个元素“postReceptionReport”，该元素的type属性值为“reportProcedureType”，该元素的minOccurs属性值为“0”。

根据上述(6)或(7)的XML Schema，广播组播业务中心生成相应的接收上报关联分发流程描述实例，如果要求不止是上报成功的详细信息，还要求上报失败的信息，且要求UE一旦进入关联会话就将用点到点链接发送接收上报信息，则相应的接收上报分发流程描述实例如下：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<associatedProcedureDescription

    xmlns＝″urn:3gpp:metadata:2005:MBMS:associatedProcedure″

    xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″>

    <postReceptionReport

           offsetTime＝″5″

           randomTimePeriod＝″10″

           reportType＝″StaR-all″

           samplePercentage＝″100″

           forceTimeIndependence＝″0″>

        <serviceURI>″http://mbmsreport.example.com/path/report_script″</serviceURI>

    </postReceptionReport>

</associatedProcedureDescription>

广播组播业务中心的用户业务声明模块生成上述接收上报关联分发流程描述文件，然后在与用户设备进行会话时通过会话传输模块或在与用户设备进行交互时通过交互声明模块发送给用户设备。当一个内容项完全接收或一个会话完成时，用户设备必须确定广播组播业务中心是否请求其发送接收上报。用户设备通过分析关联分发流程描述接收上报流程的参数，确定上报类型以及相关的信息，并选择适当的时间和服务器发送接收上报消息。

本发明针对现有技术中由于接收上报关联分发流程的XMLSchema设计不合理可能导致接收端无法识别接收上报类型而导致错误的情况，对原有方案进行了改进。一方面给表示上报类型的属性增加一个缺省属性，其值为“RAck”，这样在没有指定上报类型的属性值时，就采用其默认值“RAck”。另一方面，该表示上报类型的属性的类型属性为“reportTypeType”，该属性“reportTypeType”表示上报类型的类型，该属性有三个枚举值(“RAck”，“StaR”，“StaR-all”)，或将表示上报类型的属性绑定于一个简单类型，该简单类型有三个枚举值(“RAck”，“StaR”，“StaR-all”)，这样表示上报类型的属性只能取“RAck”，“StaR”，“StaR-all”三者中之一，从而不会导致接收端无法识别上报类型的错误。

以上仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (20)

1.一种广播组播业务中的接收上报方法，其特征在于，包括以下步骤：

步骤S302，广播组播业务中心生成接收上报关联分发流程描述文件并将所述描述文件发送至一个或多个用户设备，其中，所述描述文件包括要求所述用户设备发送的接收上报消息的类型信息；

步骤S304，所述一个或多个用户设备接收到所述接收上报关联分发流程描述文件后对其进行解析并确定要求的接收上报消息的上报类型；以及

步骤S306，所述用户设备生成要求类型的接收上报消息并将其发送至接收上报服务器。

2.根据权利要求1所述的接收上报方法，其特征在于，所述接收上报消息的类型信息通过接收上报消息类型(ReportType)的类型来限定。

3.根据权利要求2所述的接收上报方法，其特征在于，所述接收上报消息类型的类型是以下三个枚举值之一：接收确认RAck、成功接收的统计报告StaR、以及所有内容接收的统计报告StaR-all。

4.根据权利要求3所述的接收上报方法，其特征在于，所述接收上报消息类型的缺省类型为接收确认RAck。

5.根据权利要求1所述的接收上报方法，其特征在于，所述接收上报消息的类型信息通过将上报消息类型绑定于一个简单类型来限定。

6.根据权利要求5所述的接收上报方法，其特征在于，所述简单类型包括以下三个枚举值：接收确认RAck、成功接收的统计报告StaR、以及所有内容接收的统计报告StaR-all。

7.根据权利要求6所述的接收上报方法，其特征在于，所述接收上报消息类型的缺省类型为接收确认RAck。

8.根据权利要求4或7所述的接收上报方法，其特征在于，在所述接收上报消息的类型信息为接收确认类型RAck的情况下，所述用户设备上报成功接收文件的信息，不上报成功接收的详细信息。

9.根据权利要求4或7所述的接收上报方法，其特征在于，在所述要求的接收上报消息的类型信息为成功接收的统计报告StaR的情况下，所述用户设备上报成功接收统计报告的信息、成功接收文件的信息以及用于进行统计分析的详细信息。

10.根据权利要求4或7所述的接收上报方法，其特征在于，在所述要求的接收上报消息的类型信息为所有内容接收的统计报告StaR-all的情况下，所述用户设备上报成功接收文件的信息、成功接收统计报告的信息、用于进行统计分析的信息、以及接收文件失败的信息。

11.一种接收上报处理装置，其特征在于包括：

用户业务声明模块，用于生成接收上报关联分发流程描述文件并将所述描述文件发送至交互分发模块或会话与传输模块，其中，所述描述文件包括要求所述用户设备发送的接收上报消息的类型信息；

所述交互分发模块，用于在与一个或多个用户设备进行交互的情况下，将所述接收上报关联分发流程描述文件发送至所述一个或多个用户设备；以及

所述会话与传输模块，用于在与一个或多个用户设备进行会话的情况下，将所述接收上报关联分发流程描述文件发送至所述一个或多个用户设备。

12.根据权利要求11所述的接收上报处理装置，其特征在于，所述接收上报消息的类型信息通过接收上报消息类型(ReportType)的类型来限定。

13.根据权利要求12所述的接收上报处理装置，其特征在于，所述接收上报消息类型的类型是以下三个枚举值之一：接收确认RAck、成功接收的统计报告StaR、以及所有内容接收的统计报告StaR-all。

14.根据权利要求13所述的接收上报处理装置，其特征在于，所述接收上报消息类型的缺省类型为接收确认RAck。

15.根据权利要求11所述的接收上报处理装置，其特征在于，所述接收上报消息的类型信息通过将所述上报消息类型绑定于一个简单类型来限定。

16.根据权利要求15所述的接收上报处理装置，其特征在于，所述简单类型包括以下三个枚举值：接收确认RAck、成功接收的统计报告StaR、以及所有内容接收的统计报告StaR-all。

17.根据权利要求16所述的接收上报处理装置，其特征在于，所述接收上报消息类型的缺省类型为接收确认RAck。

18.根据权利要求14或17所述的接收上报处理装置，其特征在于，在所述接收上报消息的类型信息为接收确认类型RAck的情况下，指示所述用户设备上报成功接收文件的信息，不上报成功接收的详细信息。

19.根据权利要求14或17所述的接收上报处理装置，其特征在于，在所述要求的接收上报消息的类型信息为成功接收的统计报告StaR的情况下，指示所述用户设备上报成功接收统计报告的信息、成功接收文件的信息以及用于进行统计分析的详细信息。

20.根据权利要求14或17所述的接收上报处理装置，其特征在于，在所述要求的接收上报消息的类型信息为所有内容接收的统计报告StaR-all的情况下，指示所述用户设备上报成功接收文件的信息、成功接收统计报告的信息、用于进行统计分析的信息、以及接收文件失败的信息。

Images