用于接收报告的客户端ID和多应用支持的制作方法

本申请要求享受2014年3月25日提交的、标题为“CLIENT ID AND MULTI-APPLICATION SUPPORT FOR RECEPTION REPORTING”的美国临时申请No.61/970,343和2015年3月17日提交的、标题为“CLIENT ID AND MULTI-APPLICATION SUPPORT FOR RECEPTION REPORTING”的美国专利申请No.14/660,891的优先权，故以引用方式将这些申请的全部内容明确地并入本文。

技术领域

概括地说，本公开内容涉及通信系统，具体地说，本公开内容涉及接收报告。

背景技术：

已广泛地部署无线通信系统，以便提供诸如电话、视频、数据、消息和广播之类的各种电信服务。典型的无线通信系统可以使用能通过共享可用的系统资源(例如，带宽、发射功率)，来支持与多个用户进行通信的多址技术。这类多址技术的例子包括码分多址(CDMA)系统、时分多址(TDMA)系统、频分多址(FDMA)系统、正交频分多址(OFDMA)系统、单载波频分多址(SC-FDMA)系统和时分同步码分多址(TD-SCDMA)系统。

在多种电信标准中已采纳这些多址技术，以提供使不同无线设备能在城市范围、国家范围、地域范围、甚至全球范围上进行通信的通用协议。一种新兴的电信标准的例子是长期演进(LTE)。LTE是第三代合作伙伴计划(3GPP)发布的通用移动通信系统(UMTS)移动标准的演进集。设计LTE以便通过提高谱效率、降低费用、提高服务、充分利用新频谱来更好地支持移动宽带互联网接入，并与在下行链路(DL)上使用OFDMA、在上行链路(UL)上使用SC-FDMA以及使用多输入多输出(MIMO)天线技术的其它开放标准进行更好地集成。但是，随着移动宽带接入需求的持续增加，存在着进一步提高LTE技术的需求。优选的是，这些提高应当可适用于其它多址技术和使用这些技术的通信标准。

技术实现要素：

在本公开内容的一个方面，提供了一种方法、计算机程序产品和装置。该装置可以是第一用户设备(UE)。第一UE从运行在第二UE上的应用或者运行在第一UE上的应用接收针对服务的请求。第二UE与第一UE不同。针对服务的该请求是针对通过多媒体广播多播业务(MBMS)服务来获得文件集合或者流集合的请求。第一UE尝试通过MBMS服务从基站或者第三UE中的一个接收该文件集合或者流集合。第一UE发送包括以下内容的接收报告：与该文件集合或者流集合相关联的接收确认或者统计报告中的至少一项。与该文件集合或者流集合相关联的接收确认或者统计报告中的至少一项包括：与第二UE、第三UE、运行在第二UE上的应用、或者运行在第一UE上的应用中的至少一个相关联的标识符。

在本公开内容的一个方面，提供了一种方法、计算机程序产品和装置。该装置可以是UE。UE从第二UE或者运行在第二UE上的应用接收针对服务的请求。针对服务的该请求是针对通过MBMS服务来获得文件集合或者流集合的请求。UE尝试通过MBMS服务来接收该文件集合或者流集合。UE发送包括以下内容的接收报告：与该文件集合或者流集合相关联的接收确认或者统计报告中的至少一项。与该文件集合或者流集合相关联的接收确认或者统计报告中的所述至少一项，包括：与第二UE或者运行在第二UE上的应用中的至少一个相关联的标识符。

在一种配置中，与所述文件集合或者流集合相关联的接收确认或者统计报告中的所述至少一项包括与所述UE相关联的标识符。在一种配置中，与所述UE相关联的标识符以及与第二UE或者运行在第二UE上的应用中的至少一个相关联的标识符是在所述接收确认或者所述统计报告中的所述至少一个中的客户端标识符属性中进行指示的。在一种配置中，与所述UE相关联的标识符在所述接收确认或者所述统计报告中的所述至少一个中的客户端标识符属性中进行指示的，并且与第二UE或者运行在第二UE上的应用中的至少一个相关联的标识符是在所述接收确认或者所述统计报告中的所述至少一个中的不同属性中进行指示的。在一种配置中，所述UE和第二UE是同一个UE，并且所述标识符与运行在第二UE上的应用相关联。在一种配置中，所述文件集合或者流集合包括一个文件集合，并且所述接收报告包括与该文件集合相关联的接收确认。在一种配置中，所述UE从第三UE或者运行在所述第三UE上的应用接收针对第二文件集合的请求。所述UE尝试通过MBMS服务接收第二文件集合。所述UE发送第二接收报告，其中该第二接收报告包括与第二文件集合相关联的接收确认。与第二文件集合相关联的接收确认包括：与所述UE相关联的标识符、以及与第三UE或者运行在第三UE上的应用中的至少一个相关联的标识符。在一种配置中，将所述接收报告和第二接收报告汇总到一个报告中。在一种配置中，所述UE从第三UE或者运行在第三UE上的应用接收针对第二文件集合的请求。所述接收确认还与第二文件集合相关联。所述文件集合是S₁，所述文件的第二集合是S₂。针对文件集合S₁∩S₂，所述接收确认包括：用于确认所述文件S₁∩S₂的接收的子元素、与所述UE相关联的标识符、以及与下面中的至少一项相关联的标识符：第二UE和第三UE二者或者运行在第二UE和第三UE二者上的应用。针对不包括文件子集S₁∩S₂的文件集合S₁，所述接收确认包括：用于确认不包括文件子集S₁∩S₂的文件S₁的接收的子元素、与所述UE相关联的标识符、以及与第二UE或者运行在第二UE上的应用中的至少一个相关联的标识符。针对不包括文件子集S₁∩S₂的文件集合S₂，所述接收确认包括：用于确认不包括文件子集S₁∩S₂的文件S₂的接收的子元素、与所述UE相关联的标识符、以及与第三UE或者运行在第三UE上的应用中的至少一个相关联的标识符。在一种配置中，所述文件集合或者流集合包括一个流集合，并且所述接收报告包括与所述流集合相关联的统计报告。在一种配置中，所述UE从第三UE或者运行在第三UE上的应用，接收针对所述流集合的请求。所述UE发送第二接收报告，其中该第二接收报告包括与所述流集合相关联的第二统计报告。与所述流集合相关联的第二统计报告包括：与所述UE相关联的标识符、以及与第三UE或者运行在第三UE上的应用中的至少一个相关联的标识符。在一种配置中，将所述接收报告和第二接收报告汇总到一个报告中。在一种配置中，所述UE从第三UE或者运行在第三UE上的应用接收针对所述流集合的请求。第二UE请求在持续时间T₁期间接收所述流集合，第三UE请求在持续时间T₂期间接收所述流集合。所述UE发送与所述流集合相关联的另外的接收报告。所述接收报告和所述另外的接收报告包括第一接收报告，后者包括与在所述持续时间T₁∩T₂期间接收的所述流集合相关联的统计报告。与在所述持续时间T₁∩T₂期间接收的所述流集合相关联的所述统计报告包括：与所述UE相关联的标识符、以及与下面中的至少一项相关联的标识符：第二UE和第三UE二者或者运行在第二UE和第三UE二者上的应用。此外，所述接收报告和所述另外的接收报告还包括第二接收报告，后者包括与在不包括所述持续时间T₁∩T₂的所述持续时间T₁期间接收的所述流集合相关联的统计报告。与在不包括所述持续时间T₁∩T₂的所述持续时间T₁期间接收的所述流集合相关联的所述统计报告包括：与所述UE相关联的标识符、以及与第二UE或者运行在第二UE上的应用中的至少一个相关联的标识符。此外，所述接收报告和所述另外的接收报告还包括第三接收报告，后者包括与在不包括所述持续时间T₁∩T₂的所述持续时间T₂期间接收的所述流集合相关联的统计报告。与在不包括所述持续时间T₁∩T₂的所述持续时间T₂期间接收的所述流集合相关联的统计报告包括：与所述UE相关联的标识符、以及与第三UE或者运行在第三UE上的应用中的至少一个相关联的标识符。

附图说明

图1是示出一种网络架构的例子的图。

图2是示出一种接入网络的例子的图。

图3是示出LTE中的DL帧结构的例子的图。

图4是示出LTE中的UL帧结构的例子的图。

图5是示出用于用户平面和控制平面的无线协议架构的例子的图。

图6是示出接入网络中的演进节点B和用户设备的例子的图。

图7A是示出多播广播单频网中的演进型多媒体广播多播业务(eMBMS)信道配置的例子的图。

图7B是示出多播信道调度信息媒体访问控制单元的格式的图。

图8是示出一种示例性eMBMS端到端架构的图。

图9是示出不同的示例性eMBMS端到端架构的图。

图10是示出针对文件传输服务，在不具有应用之间的汇总的情况下，(每应用)并行报告的例子的图。

图11是示出在不具有应用之间的汇总的情况下进行并行报告时，针对文件传输服务所发送的接收报告的例子的图。

图12是示出在具有应用之间的汇总的情况下进行并行报告时，针对文件传输服务所发送的接收报告的例子的图。

图13是示出针对流服务，在不具有应用之间的汇总的情况下，(每应用)并行报告的例子的图。

图14是示出在不具有应用之间的汇总的情况下进行并行报告时，针对流服务所发送的接收报告的例子的第一图。

图15是示出在具有应用之间的汇总的情况下进行并行报告时，针对流服务所发送的接收报告的例子的第二图。

图16是示出在具有应用之间的汇总的情况下进行并行报告时，针对流服务所发送的接收报告的例子的图。

图17是示出针对文件传输服务，在具有应用之间的汇总的情况下，(每应用)线性报告的例子的图。

图18是示出在具有应用之间的汇总的情况下进行线性报告时，针对文件传输服务所发送的接收报告的例子的图。

图19是示出针对流服务，在不具有应用之间的汇总的情况下，(每应用)线性报告的例子的图。

图20是示出在不具有应用之间的汇总的情况下进行线性报告时，针对流服务所发送的接收报告的例子的第一图。

图21是示出在不具有应用之间的汇总的情况下进行线性报告时，针对流服务所发送的接收报告的例子的第二图。

图22是示出在不具有应用之间的汇总的情况下进行线性报告时，针对流服务所发送的接收报告的例子的第三图。

图23是示出在具有应用之间的汇总的情况下进行线性报告时，针对流服务所发送的接收报告的例子的第一图。

图24是示出在具有应用之间的汇总的情况下进行线性报告时，针对流服务所发送的接收报告的例子的第二图。

图25是无线通信的第一方法的流程图。

图26是无线通信的第二方法的流程图。

图27是无线通信的第三方法的流程图。

图28是无线通信的第四方法的流程图。

图29是无线通信的第五方法的流程图。

图30是示出接收报告中的客户端ID属性/元素的图。

图31是示出示例性装置中的不同模块/单元/部件之间的数据流的概念性数据流图。

图32是示出用于使用处理系统的装置的硬件实现的例子的图。

具体实施方式

下面结合附图描述的具体实施方式，仅仅旨在对各种配置进行描述，而不是旨在表示仅在这些配置中才可以实现本文所描述的概念。为了对各种概念有一个透彻理解，具体实施方式包括特定的细节。但是，对于本领域普通技术人员来说显而易见的是，可以在不使用这些特定细节的情况下实现这些概念。在一些实例中，为了避免对这些概念造成模糊，公知的结构和组件以框图形式示出。

现在参照各种装置和方法来给出电信系统的一些方面。这些装置和方法将在下面的具体实施方式中进行描述，并在附图中通过各种框、模块、组件、电路、步骤、处理、算法等等(其统称为“元素”)来进行描绘。可以使用电子硬件、计算机软件或者其任意组合来实现这些元素。至于这些元素是实现成硬件还是实现成软件，取决于特定的应用和对整个系统所施加的设计约束条件。

举例而言，元素或者元素的任何部分或者元素的任意组合，可以用包括一个或多个处理器的“处理系统”来实现。处理器的示例包括微处理器、微控制器、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、可编程逻辑器件(PLD)、状态机、门逻辑、分离硬件电路和被配置为执行贯穿本发明描述的各种功能的其它适当硬件。处理系统中的一个或多个处理器可以执行软件。软件应当被广泛地解释为意味着指令、指令集、代码、代码段、程序代码、程序、子程序、软件模块、应用、软件应用、软件包、例行程序、子例行程序、对象、可执行文件、执行的线程、过程、函数等等，无论其被称为软件、固件、中间件、微代码、硬件描述语言还是其它术语。

因此，在一个或多个示例性实施例中，本文所描述的功能可以用硬件、软件、固件或者其任意组合来实现。当使用软件实现时，可以将这些功能存储或编码成计算机可读介质上的一个或多个指令或代码。计算机可读介质包括计算机存储介质。存储介质可以是计算机能够存取的任何可用介质。通过示例的方式而不是限制的方式，这种计算机可读介质可以包括随机存取存储器(RAM)、只读存储器(ROM)、电可擦写可编程ROM(EEPROM)、紧致碟(CD-ROM)或其它光盘存储、磁盘存储介质或其它磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望程序代码并能够由计算机存取的任何其它介质。上述的组合也应当包括在计算机可读介质的范围之内。

图1是示出LTE网络架构100的图。该LTE网络架构100可以称为演进分组系统(EPS)100。EPS 100可以包括一个或多个用户设备(UE)102、演进型UMTS陆地无线接入网络(E-UTRAN)104、演进分组核心(EPC)110和运营商的互联网协议(IP)服务122。EPS可以与其它接入网络互连，但为简单起见，没有示出这些实体/接口。如图所示，EPS提供分组交换服务，但是，如本领域普通技术人员所容易理解的，贯穿本公开内容给出的各种概念可以扩展到提供电路交换服务的网络。

E-UTRAN包括演进节点B(eNB)106和其它eNB 108，可以包括多播协调实体(MCE)128。eNB 106提供针对于UE 102的用户平面和控制平面协议终止。eNB 106可以经由回程(例如，X2接口)连接到其它eNB 108。MCE 128为演进型多媒体广播多播业务(MBMS)(eMBMS)分配时间/频率无线资源，确定用于eMBMS的无线配置(例如，调制和编码方案(MCS))。MCE 128可以是单独的实体，也可以是eNB 106的一部分。eNB 106还可以称为基站、节点B、接入点、基站收发机、无线基站、无线收发机、收发机功能、基本服务集(BSS)、扩展服务集(ESS)或者某种其它适当术语。eNB 106为UE 102提供针对EPC 110的接入点。UE 102的例子包括蜂窝电话、智能电话、会话发起协议(SIP)电话、膝上型计算机、个人数字助理(PDA)、卫星无线设备、全球定位系统、多媒体设备、视频设备、数字音频播放器(例如，MP3播放器)、照相机、游戏控制台、平板计算机或者任何其它类似功能设备。本领域普通技术人员还可以将UE 102称为移动站、用户站、移动单元、用户单元、无线单元、远程单元、移动设备、无线设备、无线通信设备、远程设备、移动用户站、接入终端、移动终端、无线终端、远程终端、手持装置、用户代理、移动客户端、客户端或者某种其它适当术语。

eNB 106连接到EPC 110。EPC 110可以包括移动管理实体(MME)112、归属用户服务器(HSS)120、其它MME 114、服务网关116、多媒体广播多播业务(MBMS)网关124、广播多播服务中心(BM-SC)126和分组数据网络(PDN)网关118。MME 112是处理UE 102和EPC 110之间的信令的控制节点。通常，MME 112提供承载和连接管理。所有用户IP分组通过服务网关116来传送，其中服务网关116自己连接到PDN网关118。PDN网关118提供UE IP地址分配以及其它功能。PDN网关118和BM-SC 126连接到IP服务122。IP服务122可以包括互联网、内联网、IP多媒体子系统(IMS)和PS流服务(PSS)和/或其它IP服务。BM-SC 126提供用于MBMS用户服务提供和传送的功能。BM-SC 126可以服务成内容提供商MBMS传输的进入点，可以用于在PLMN中授权和发起MBMS承载服务，并可以用于调度和传送MBMS传输。MBMS网关124可以用于向属于广播特定服务的多播广播单频网(MBSFN)区域的eNB(例如，106、108)分发MBMS业务，并可以负责会话管理(起始/停止)和收集与eMBMS有关的计费信息。

图2是示出LTE网络架构中的接入网络200的例子的图。在该例子中，将接入网络200划分成多个蜂窝区域(小区)202。一个或多个低功率类型eNB 208可以具有与小区202中的一个或多个重叠的蜂窝区域210。低功率类型eNB 208可以是毫微微小区(例如，家庭eNB(HeNB))、微微小区、微小区或者远程无线电头端(RRH)。宏eNB 204分配给各小区202，并被配置为向小区202中的所有UE 206提供针对EPC 110的接入点。在接入网络200的该例子中，不存在集中式控制器，但在替代的配置中可以使用集中式控制器。eNB 204负责所有与无线相关的功能，其包括无线承载控制、准入控制、移动控制、调度、安全和连接到服务网关116。eNB可以支持一个或多个(例如，三个)小区(其还称为扇区)。术语“小区”可以指代eNB的最小覆盖区域和/或服务于特定覆盖区域的eNB子系统。此外，本文可以互换地使用术语“eNB”、“基站”和“小区”。

接入网络200使用的调制和多址方案可以根据所部署的具体通信标准来变化。在LTE应用中，在DL上使用OFDM，在UL上使用SC-FDMA，以便支持频分双工(FDD)和时分双工(TDD)。如本领域普通技术人员通过下面的详细描述所容易理解的，本文给出的各种概念非常适合用于LTE应用。但是，这些概念也可以容易地扩展到使用其它调制和多址技术的其它通信标准。举例而言，这些概念可以扩展到演进数据优化(EV-DO)或超移动宽带(UMB)。EV-DO和UMB是第三代合作伙伴计划2(2GPP2)作为CDMA2000标准系列的一部分发布的空中接口标准，EV-DO和UMB使用CDMA来为移动站提供宽带互联网接入。这些概念还可以扩展到使用宽带CDMA(W-CDMA)和CDMA的其它变型(例如，TD-SCDMA)的通用陆地无线接入(UTRA)；使用TDMA的全球移动通信系统(GSM)；使用OFDMA的演进UTRA(E-UTRA)、IEEE 802.11(Wi-Fi)、IEEE 802.16(WiMAX)、IEEE 802.20和闪速OFDM。在来自3GPP组织的文档中描述了UTRA、E-UTRA、UMTS、LTE和GSM。在来自3GPP2组织的文档中描述了CDMA2000和UMB。使用的实际无线通信标准和多址技术，取决于特定的应用和对系统所施加的整体设计约束条件。

eNB 204可以具有支持MIMO技术的多个天线。MIMO技术的使用使eNB 204能够使用空间域来支持空间复用、波束成形和发射分集。空间复用可以用于在相同频率上同时发送不同的数据流。将数据流发送给单一UE206以增加数据速率，或者发送给多个UE 206以增加整体系统容量。这可以通过对每一个数据流进行空间预编码(即，应用幅度和相位的缩放)，并随后通过多个发射天线在DL上发送每一个空间预编码的流来实现。到达UE 206的空间预编码的数据流具有不同的空间特征，这使得每一个UE 206都能恢复出目的地针对于该UE 206的一个或多个数据流。在UL上，每一个UE 206发送空间预编码的数据流，其中空间预编码的数据流使eNB 204能识别每一个空间预编码的数据流的源。

当信道状况良好时，通常使用空间复用。当信道状况不太有利时，可以使用波束成形来将传输能量聚焦在一个或多个方向中。这可以通过对经由多个天线发送的数据进行空间预编码来实现。为了在小区边缘实现良好的覆盖，可以结合发射分集来使用单一流波束成形传输。

在下面的详细描述中，将参照在DL上支持OFDM的MIMO系统来描述接入网络的各个方面。OFDM是一种扩频技术，该技术将数据调制在OFDMA符号中的多个子载波上。这些子载波间隔开精确的频率。这种间隔提供了使接收机能够从这些子载波中恢复数据的“正交性”。在时域，可以向每一个OFDM符号添加防护间隔(例如，循环前缀)，以防止OFDM符号间干扰。UL可以使用具有DFT扩展OFDM信号形式的SC-FDMA，以便补偿较高的峰值与平均功率比(PARR)。

图3是示出LTE中的DL帧结构的例子的图300。可以将一个帧(10ms)划分成10个均匀大小的子帧。每一个子帧可以包括两个连续的时隙。可以使用一个资源格来表示两个时隙，每一个时隙包括一个资源块。将资源格划分成多个资源单元。在LTE中，对于普通循环前缀而言，一个资源块在频域上包含12个连续的子载波，在时域上包含7个连续的OFDM符号，对于总共84个资源单元而言。对于扩展循环前缀来说，对于总共72个资源单元，一个资源块在频域中包含12个连续子载波，在时域中包含6个连续的OFDM符号。这些资源单元中的一些(其指示成R 302、304)包括DL参考信号(DL-RS)。DL-RS包括特定于小区的RS(CRS)(其有时还称为通用RS)302和特定于UE的RS(UE-RS)304。在将相应的物理DL共享信道(PDSCH)所映射到的资源块上，只发送UE-RS 304。每一个资源单元所携带的比特数量取决于调制方案。因此，UE接收的资源块越多，调制方案阶数越高，则针对该UE的数据速率越高。

图4是示出LTE中的UL帧结构的例子的图400。可以将用于UL的可用资源块划分成数据段和控制段。可以在系统带宽的两个边缘处形成控制段，控制段具有可配置的大小。可以将控制段中的资源块分配给UE，以传输控制信息。数据段可以包括不包含在控制段中的所有资源块。该UL帧结构导致包括连续的子载波的数据段，其允许向单一UE分配数据段中的所有连续子载波。

可以向UE分配控制段中的资源块410a、410b，以向eNB发送控制信息。此外，还可以向UE分配数据段中的资源块420a、420b，以向eNB发送数据。UE可以在控制段中的分配的资源块上，在物理UL控制信道(PUCCH)中发送控制信息。UE可以在数据段中的分配的资源块上，在物理UL共享信道(PUSCH)中只发送数据或者发送数据和控制信息二者。UL传输可以跨度子帧的两个时隙，可以在频率之间进行跳变。

可以使用一组资源块来执行初始的系统接入，并在物理随机接入信道(PRACH)430中实现UL同步。PRACH 430携带随机序列，并且不能携带任何UL数据/信令。每一个随机接入前导占据与六个连续资源块相对应的带宽。起始频率由网络进行指定。也就是说，将随机接入前导的传输限制于某些时间和频率资源。对于PRACH来说，不存在频率跳变。PRACH尝试在单一子帧(1ms)中或者在一些连续子帧序列中进行携带，UE可以在每一帧(10ms)只进行单一的PRACH尝试。

图5是示出用于LTE中的用户平面和控制平面的无线协议架构的示例的图500。用于UE和eNB的无线协议架构示出为具有三个层：层1、层2和层3。层1(L1层)是最低层，其实现各种物理层信号处理功能。本申请将L1层称为物理层506。层2(L2层)508高于物理层506，其负责物理层506之上的UE和eNB之间的链路。

在用户平面中，L2层508包括媒体访问控制(MAC)子层510、无线链路控制(RLC)子层512和分组数据会聚协议(PDCP)514子层，其中PDCP 514子层在网络一侧的eNB处终止。虽然没有示出，但UE可以具有高于L2层508的一些上层，其包括网络层(例如，IP层)和应用层，其中所述网络层在网络一侧的PDN网关118处终止，所述应用层在所述连接的另一端(例如，远端UE、服务器等等)处终止。

PDCP子层514提供不同的无线承载和逻辑信道之间的复用。PDCP子层514还提供用于上层数据分组的报头压缩，以减少无线传输开销，通过对数据分组进行加密来实现安全，以及为UE提供eNB之间的切换支持。RLC子层512提供上层数据分组的分段和重组、丢失数据分组的重传以及数据分组的重新排序，以便补偿由于混合自动重传请求(HARQ)而造成的乱序接收。MAC子层510提供逻辑信道和传输信道之间的复用。MAC子层510还负责在UE之间分配一个小区中的各种无线资源(例如，资源块)。MAC子层510还负责HARQ操作。

在控制平面中，对于物理层506和L2层508来说，除不存在用于控制平面的报头压缩功能之外，用于UE和eNB的无线协议架构基本相同。控制平面还包括层3(L3层)中的无线资源控制(RRC)子层516。RRC子层516负责获得无线资源(即，无线承载)，并负责使用eNB和UE之间的RRC信令来配置更低层。

图6是接入网络中，eNB 610与UE 650的通信的框图。在DL中，将来自核心网的上层分组提供给控制器/处理器675。控制器/处理器675实现L2层的功能。在DL中，控制器/处理器675提供报头压缩、加密、分组分段和重新排序、逻辑信道和传输信道之间的复用以及基于各种优先级度量来向UE 650提供无线资源分配。控制器/处理器675还负责HARQ操作、丢失分组的重传以及向UE 650发送信令。

发射(TX)处理器616实现L1层(即，物理层)的各种信号处理功能。这些信号处理功能包括编码和交织，以有助于在UE 650处实现前向纠错(FEC)，以及基于各种调制方案(例如，二进制移相键控(BPSK)、正交移相键控(QPSK)、M相移相键控(M-PSK)、M阶正交幅度调制(M-QAM))来映射到信号星座。随后，将编码和调制的符号分割成并行的流。随后，将每一个流映射到OFDM子载波，在时域和/或频域中将其与参考信号(例如，导频)进行复用，并随后使用逆傅里叶变换(IFFT)将各个流组合在一起以便生成携带时域OFDM符号流的物理信道。对该OFDM流进行空间预编码，以生成多个空间流。来自信道估计器674的信道估计量可以用于确定编码和调制方案以及用于实现空间处理。可以从UE650发送的参考信号和/或信道状况反馈中导出信道估计量。随后，可以经由单独的发射机618TX，将各空间流提供给不同的天线620。每一个发射机618TX可以使用各空间流对RF载波进行调制，以便进行传输。

在UE 650处，每一个接收机654RX通过其各自天线652接收信号。每一个接收机654RX恢复调制到RF载波上的信息，并将该信息提供给接收(RX)处理器656。RX处理器656实现L1层的各种信号处理功能。RX处理器656可以对所述信息执行空间处理，以恢复目的地针对于UE 650的任何空间流。如果多个空间流目的地针对于UE 650，则RX处理器656将它们组合成单一OFDM符号流。随后，RX处理器656使用快速傅里叶变换(FFT)，将OFDM符号流从时域变换到频域。频域信号包括用于OFDM信号的每一个子载波的单独OFDMA符号流。通过确定eNB 610发送的最可能的信号星座点，来恢复和解调每一个子载波上的符号以及参考信号。这些软判决可以是基于信道估计器658所计算得到的信道估计量。随后，对这些软判决进行解码和解交织，以恢复eNB 610最初在物理信道上发送的数据和控制信号。随后，将这些数据和控制信号提供给控制器/处理器659。

控制器/处理器659实现L2层。该控制器/处理器可以与存储程序代码和数据的存储器660进行关联。存储器660可以称为计算机可读介质。在UL中，控制器/处理器659提供传输信道和逻辑信道之间的解复用、分组重组、解密、报头解压缩、控制信号处理，以恢复来自核心网的上层分组。随后，将上层分组提供给数据宿662，其中数据宿662表示高于L2层的所有协议层。此外，还可以向数据宿662提供各种控制信号以进行L3处理。控制器/处理器659还负责使用确认(ACK)和/或否定确认(NACK)协议进行错误检测，以支持HARQ操作。

在UL中，数据源667用于向控制器/处理器659提供上层分组。数据源667表示高于L2层的所有协议层。类似于结合eNB 610进行DL传输所描述的功能，控制器/处理器659通过提供报头压缩、加密、分组分段和重新排序，以及基于eNB 610的无线资源分配在逻辑信道和传输信道之间进行复用，来实现用户平面和控制平面的L2层。控制器/处理器659还负责HARQ操作、丢失分组的重传和向eNB 610发送信令。

信道估计器658从eNB 610发送的参考信号或反馈中导出的信道估计量，可以由TX处理器668使用，以便选择适当的编码和调制方案和有助于实现空间处理。可以经由各自的发射机654TX，将TX处理器668所生成的空间流提供给不同的天线652。每一个发射机654TX可以利用各自空间流来对RF载波进行调制，以便进行传输。

以类似于结合UE 650处的接收机功能所描述的方式，eNB 610对UL传输进行处理。每一个接收机618RX通过其各自的天线620来接收信号。每一个接收机618RX恢复调制到RF载波上的信息，并将该信息提供给RX处理器670。RX处理器670实现L1层。

控制器/处理器675实现L2层。控制器/处理器675可以与存储程序代码和数据的存储器676进行关联。存储器676可以称为计算机可读介质。在UL中，控制器/处理器675提供传输信道和逻辑信道之间的解复用、分组重组、解密、报头解压缩、控制信号处理，以恢复来自UE 650的上层分组。可以将来自控制器/处理器675的上层分组提供给核心网。控制器/处理器675还负责使用ACK和/或NACK协议进行错误检测，以支持HARQ操作。

图7A是示出MBSFN中的演进型MBMS(eMBMS)信道配置的例子的图750。小区752’中的eNB 752可以形成第一MBSFN区域，小区754’中的eNB 754可以形成第二MBSFN区域。eNB 752、754可以与其它MBSFN区域相关联(例如，多达总共八个MBSFN区域)。可以将MBSFN区域中的小区指定成保留小区。保留小区不提供多播/广播内容，但与小区752’、754’进行时间同步，可以具有关于MBSFN资源的受限制功率，以便限制对于MBSFN区域的干扰。MBSFN区域中的每一个eNB同步地发送相同的eMBMS控制信息和数据。每一个区域都可以支持广播、多播和单播服务。单播服务是旨在针对于特定用户的服务(例如，语音呼叫)。多播服务是可以由一组用户接收的服务(例如，订阅视频服务)。广播服务是可以由所有用户进行接收的服务(例如，新闻广播)。参见图7A，第一MBSFN区域可以支持第一eMBMS广播服务，例如通过向UE 770提供特定的新闻广播。第二MBSFN区域可以支持第二eMBMS广播服务，例如，通过向UE 760提供不同的新闻广播。每一个MBSFN区域支持多个物理多播信道(PMCH)(例如，15个PMCH)。每一个PMCH对应于一个多播信道(MCH)。每一个MCH可以对多个(例如，29个)多播逻辑信道进行复用。每一个MBSFN区域可以具有一个多播控制信道(MCCH)。因此，一个MCH可以对一个MCCH和多个多播业务信道(MTCH)进行复用，剩余的MCH可以对多个MTCH进行复用。

UE可以驻留在LTE小区上，以发现eMBMS服务接入的可用性和相应的接入层配置。在第一步骤，UE可以捕获系统信息块(SIB)13(SIB13)。在第二步骤，基于SIB 13，UE可以获得MCCH上的MBSFN区域配置消息。在第三步骤，基于MBSFN区域配置消息，UE可以获得MCH调度信息(MSI)MAC控制单元。SIB13可以指示：(1)该小区所支持的每一个MBSFN区域的MBSFN区域标识符；(2)用于获取MCCH的信息，例如，MCCH重复周期(如，32、64、…、256个帧)、MCCH偏移(如，0、1、…、10个帧)、MCCH修改周期(如，512、1024个帧)、信令调制和编码方案(MCS)、子帧分配信息(其指示如重复周期和偏移所指示的该无线帧中的哪些子帧可以发送MCCH)；(3)MCCH改变通知配置。每一个MBSFN区域对应一个MBSFN区域配置消息。MBSFN区域配置消息可以指示：(1)PMCH中的逻辑信道标识符所标识的每一个MTCH的临时移动组标识(TMGI)和可选的会话标识符；(2)用于发送该MBSFN区域的每一个PMCH而分配的资源(即，无线帧和子帧)，以及用于该区域中的所有PMCH的所分配资源的分配周期(例如，4、8、…、256个帧)；(3)在其上发送MSI MAC控制单元的MCH调度周期(MSP)(例如，8、16、32、…、或者1024个无线帧)。

图7B是示出MSI MAC控制单元的格式的图790。每一个MSP，可以发送该MSI MAC控制单元一次。可以在PMCH的每一个调度周期的第一子帧中，发送该MSI MAC控制单元。该MSI MAC控制单元可以指示PMCH中的每一个MTCH的停止帧和子帧。每一个MBSFN区域，每一个PMCH，可以存在一个MSI。

图8是示出一种示例性eMBMS端到端架构的图800。如图8中所示，运行在第一UE上的中间件客户端806，可以从运行在第二UE上的应用808接收针对MBMS服务的请求814。此外，中间件客户端806还可以从运行在其它UE之上的应用810、812，接收针对MBMS服务的另外请求840、842。中间件客户端806可以基于所接收的MBMS服务请求814、840、842，向第三UE的LTE调制解调器804发送MBMS服务请求816。具体而言，在MBMS服务请求816中，中间件客户端806可以请求在MBMS服务请求814、840、842中所请求的相同的MBMS服务。LTE调制解调器804与基站802进行通信(818)，以获得特定的MBMS服务，随后将所接收的MBMS服务转发给(820)中间件客户端806。中间件客户端806(例如，通过短消息服务(SMS)文本消息)向应用808/第二UE通知已经接收到与MBMS服务请求814相对应的MBMS服务。此外，中间件客户端806还向应用810、812和/或它们相应的UE通知已经接收到所请求的MBMS服务。在接收到应用808已准备好接收与MBMS服务请求814相对应的MBMS服务的MBMS文件/流的指示824之后，中间件客户端806向应用808发送所请求的MBMS文件/流826。此外，中间件客户端806还可以向应用810和应用812发送所请求的MBMS文件/流。随后，中间件客户端806生成包括接收确认和/或统计报告的接收报告828。该接收报告可以包括与第二UE或者运行在第二UE上的应用808相关联的客户端标识符。中间件客户端806向LTE调制解调器804发送该接收报告830，LTE调制解调器804向基站802发送该接收报告832。

中间件客户端806可以与第一UE的标识符(例如，第一UE的移动电话号码(MDN))相关联。该MDN是第一UE的唯一标识符。假定第二UE或者运行在第二UE上的应用808与标识符X相关联，应用810或者相应的UE与标识符Y相关联，应用812或者相应的UE与标识符Z相关联。如上所述，具有该MDN的第一UE从UE或者运行在UE上的应用(它们与标识符X、Y、以及Z相关联)接收针对文件/流的请求；尝试接收这些文件/流；向与标识符X、Y、以及Z相关联的运行在这些UE上的应用提供所接收的文件/流；发送一个或多个接收报告，其中所述一个或多个接收报告提供与所接收的文件/流相关联的接收确认和/或统计报告。在所述一个或多个接收报告之中，不是提供与第一UE相关联的客户端标识符MDN，第一UE可以提供：用于指示请求这些文件/流，并且是这些文件/流的最终目的地的UE或者运行在这些UE之上的应用的客户端标识符X、Y、以及Z。在一些配置中，在所述一个或多个接收报告之中，第一UE提供与该第一UE相关联的MDN，以及用于指示请求这些文件/流并且是这些文件/流的最终目的地的UE或者运行在这些UE之上的应用的客户端标识符X、Y、以及Z。

中间件客户端806基于报告类型设置(例如，reportType)，确定要生成的接收报告的类型。如果该报告类型被设置为接收确认(RAck)，则在不具有接收细节的情况下，仅仅报告成功的文件接收。如果该报告类型被设置为针对成功接收的统计报告(StaR)，则在具有接收细节以进行网络中的统计分析的情况下，报告成功的文件接收(如同RAck)。如果该报告类型被设置为针对所有内容接收的统计报告(StaR-all)，则除了还报告失败的接收之外，报告的与StaR相同。StaR-all与流传输和下载传送二者有关。如果该报告类型被设置为不具有接收确认的统计报告(StaR-only)，则除了不对各个文件进行确认之外，报告的与StaR-all相同。仅仅针对流传输和下载传送的会话，才报告接收细节。对于流传输来说，StaR-only等同于StaR-all。StaR-all与下载传送有关，其中通过体验质量(QoE)度量来获得会话性能。当该报告类型是Rack时，可以将客户端标识符(例如，客户端ID属性/元素)存储在文件URI属性/元素下(参照图30)。当该报告类型是StaR、StaR-all或者StaR-only时，可以将客户端标识符(例如，客户端ID属性/元素)存储在统计报告属性/元素下(参见图30)。或者，可以将客户端标识符存储在与客户端ID属性/元素不同的属性/元素下(参见图30)。

图9是用于示出不同的示例性eMBMS端到端架构的图900。在第一配置902中，LTE调制解调器906、中间件客户端908和应用910与不同的UE相关联。在该配置中，中间件客户端908可以运行在第一UE之上，应用910可以运行在第二UE之上，该LTE调制解调器可以是第三UE的一部分。在第二配置922中，中间件客户端928和LTE调制解调器926与第一UE相关联，应用930与第二UE相关联。在该配置中，LTE调制解调器926可以是第一UE的一部分，中间件客户端928可以运行在第一UE之上，应用930可以运行在第二UE之上。在第三配置942中，中间件客户端948和应用950与第一UE相关联，LTE调制解调器946与第二UE相关联。在该配置中，应用950和中间件客户端948运行在第一UE之上，LTE调制解调器946是第二UE的一部分。在第四配置962中，中间件客户端968、应用970和LTE调制解调器966全部与同一个UE相关联。在该配置中，应用970和中间件客户端968运行在UE之上，LTE调制解调器966是该UE的一部分。因此，如分别通过第一、第二、第三、以及第四配置902、922、942、962所观察到的，中间件客户端908可以与同LTE调制解调器906和应用910相关联的UE不同的UE相关联(第一配置902)；中间件客户端928可以和LTE调制解调器926与相同的UE相关联，但其不是运行应用930的UE(第二配置922)；中间件客户端948可以和应用950与相同的UE相关联，但其不是具有LTE调制解调器946的UE(第三配置942)；或者中间件客户端968可以与包括LTE调制解调器966并且运行应用970的UE相关联(第四配置962)。

中间件客户端可以发送针对请求的应用的一个或多个接收报告，其中，与每一个接收的服务相关联的客户端标识符只与一个应用相关联(称为并行报告)，或者中间件客户端可以发送针对请求的应用的一个或多个接收报告，其中，与每一个接收的服务相关联的客户端标识符与一个或多个应用相关联(称为线性报告)。对于并行报告而言，可以针对每一个应用都发送接收报告(其称为在不具有应用之间的汇总的情况下的并行报告)(应当注意，在该情况下，仍然可以对针对一个应用的多个报告进行汇总)，或者可以针对所有应用，发送一个接收报告(其称为在具有应用之间的汇总的情况下的并行报告)。对于线性报告而言，可以针对每一个服务都发送接收报告(其称为在不具有应用之间的汇总的情况下的线性报告)，或者可以针对所有服务，发送一个接收报告(其称为在具有应用之间的汇总的情况下的线性报告)。下文参照图10到图16来讨论并行报告。下文参照图17到图24来讨论线性报告。

图10是示出针对文件传输服务，在不具有应用之间的汇总的情况下，(每应用)并行报告的例子的图1000。如图10中所示，应用X请求中间件客户端获得文件1、文件2、以及文件3；应用Y请求中间件客户端获得文件1和文件3；应用Z请求中间件客户端获得文件1。运行在第一UE上的中间件客户端，开始与基站的MBMS会话(如果该中间件客户端和LTE调制解调器均与第一UE相关联的话(参见图9的配置922))，或者与第二UE的MBMS会话(如果该中间件客户端和LTE调制解调器与不同的UE相关联；这里，第二UE与LTE调制解调器相关联(参见图9的配置902、942))。中间件客户端获得文件1、文件2、以及文件3。在获得文件1之后，中间件客户端生成针对应用Z的接收报告。在获得文件2和文件3之后，中间件客户端生成针对应用X的接收报告和针对应用Y的接收报告。在生成这些接收报告之后，中间件客户端向基站发送这些接收报告(如果中间件客户端和LTE调制解调器均与第一UE相关联)，或者向第二UE发送这些接收报告(如果该中间件客户端和LTE调制解调器与不同的UE相关联；这里，第二UE与LTE调制解调器相关联)。如果中间件客户端向第二UE发送接收报告，则第二UE将该接收报告转发给基站。在与这些应用所请求的各个文件结束时间的退避和随机化之后，发送这三个接收报告。对于该例子而言，接收报告可以是RAck。下文参照图11来提供这三个接收报告的例子。

图11是示出在不具有应用之间的汇总的情况下进行并行报告时，针对文件传输服务所发送的接收报告的例子的图1100。中间件客户端生成第一接收报告，以报告应用X接收到文件1、文件2、以及文件3，生成第二接收报告，以报告应用Y接收到文件1和文件3，生成第三接收报告，以报告应用Z接收到文件1。对于客户端标识符而言，中间件客户端可以报告具有与该中间件客户端和该应用相关联的信息的客户端标识符。例如，对于第一接收报告而言，中间件客户端报告客户端标识符“X@MDN”，其中X是应用X的标识符，MDN是运行该中间件客户端的UE的唯一标识符。对于第二接收报告而言，中间件客户端报告客户端标识符“Y@MDN”，其中Y是应用Y的标识符，MDN是运行该中间件客户端的UE的唯一标识符。对于第三接收报告而言，中间件客户端报告客户端标识符“Z@MDN”，其中Z是应用Z的标识符，MDN是运行该中间件客户端的UE的唯一标识符。中间件客户端可以在这些标识符之间使用与“@”字符不同的分隔符。在一些配置中，可以省略MDN标识符。应用X、Y、以及Z的标识符中的每一个可以是特定于应用的标识符、特定于应用的标识符和唯一性接收机标识符(例如，MDN或者国际移动站设备标识(IMEI))的级联、或者对于该应用来说具有唯一性的某种其它标识符。可以将该标识符存储在文件URI属性/元素下。如图11中所可以观察到的，同一文件被报告多次。例如，在这三个接收报告的每一个中都报告了文件1，在第一和第二接收报告中报告了文件3。

图12是示出在具有应用之间的汇总的情况下进行并行报告时，针对文件传输服务所发送的接收报告的例子的图1200。中间件客户端生成一个汇总的接收报告，以报告应用X接收到文件1、文件2、以及文件3，应用Y接收到文件1和文件3，以及应用Z接收到文件1。对于客户端标识符而言，中间件客户端可以报告具有与该中间件客户端和该应用相关联的信息的客户端标识符，如上面结合图11所讨论的。

图13是示出针对流服务，在不具有应用之间的汇总的情况下，(每应用)并行报告的例子的图1300。如图13中所示，应用X请求中间件客户端在tx1处激活流服务(例如，超文本传输协议承载动态自适应流媒体(HTTP)(DASH)流服务)的接收，在tx2处使该流服务的接收去激活，应用Y请求中间件客户端在ty1处激活同一流服务的接收，在ty2处使该流服务的接收去激活，应用Z请求中间件客户端在tz1处激活同一流服务的接收，在tz2处使该流服务的接收去激活。运行在第一UE上的中间件客户端，开始与基站的MBMS会话(如果该中间件客户端和LTE调制解调器均与第一UE相关联的话)，或者与第二UE的MBMS会话(如果该中间件客户端和LTE调制解调器与不同的UE相关联；这里，第二UE与LTE调制解调器相关联)。中间件客户端开始在tx1处接收流服务，在tz2处使流服务的接收去激活。在接收到该流服务之后，中间件客户端生成针对应用X的第一接收报告、针对应用Y的第二接收报告、以及针对应用Z的第三接收报告。在生成这些接收报告之后，中间件客户端向基站发送这些接收报告(如果中间件客户端和LTE调制解调器均与第一UE相关联)，或者向第二UE发送这些接收报告(如果该中间件客户端和LTE调制解调器与不同的UE相关联；这里，第二UE与LTE调制解调器相关联)。如果中间件客户端向第二UE发送接收报告，则第二UE将该接收报告转发给基站。在与该会话结束时间的退避和随机化之后，发送这三个接收报告。对于该例子而言，该接收报告可以是StaR、StaR-all或者StaR-only。在一种配置中，对于该例子而言，该接收报告可以是StaR-only。下文参照图14和图15来提供这三个接收报告的例子。

图14和图15分别是示出在不具有应用之间的汇总的情况下进行并行报告时，针对流服务所发送的接收报告的例子的图1400和1500。中间件客户端生成第一接收报告，以报告应用X对接收的对象的接收，生成第二接收报告，以报告应用Y对接收的对象的接收，生成第三接收报告，以报告应用Z对接收的对象的接收。对于客户端标识符而言，中间件客户端可以报告具有与该中间件客户端和该应用相关联的信息的客户端标识符。例如，对于第一接收报告而言，中间件客户端报告客户端标识符“X@MDN”，其中X是应用X的标识符，MDN是运行该中间件客户端的UE的唯一标识符。对于第二接收报告而言，中间件客户端报告客户端标识符“Y@MDN”，其中Y是应用Y的标识符，MDN是运行该中间件客户端的UE的唯一标识符。对于第三接收报告而言，中间件客户端报告客户端标识符“Z@MDN”，其中Z是应用Z的标识符，MDN是运行该中间件客户端的UE的唯一标识符。如上所述，中间件客户端可以在这些标识符之间使用与“@”字符不同的分隔符。在一些配置中，可以省略MDN标识符。应用X、Y、以及Z的标识符中的每一个可以是特定于应用的标识符、特定于应用的标识符和唯一性接收机标识符(例如，MDN或者IMEI)的级联、或者对于该应用来说具有唯一性的某种其它标识符。可以将该标识符存储在统计报告属性/元素下。如图14和图15中所可以观察到的，同一对象被报告多次。例如，在第一和第二接收报告中都报告了对象57和58，在第二和第三接收报告中报告了对象55。

图16是示出在具有应用之间的汇总的情况下进行并行报告时，针对流服务所发送的接收报告的例子的图1600。中间件客户端生成一个汇总的接收报告，以报告应用X对于对象60到57的接收，应用Y对于对象58到55的接收，以及应用Z对于对象55到52的接收。对于客户端标识符而言，中间件客户端可以报告具有与该中间件客户端和该应用相关联的信息的客户端标识符，如上面结合图15所讨论的。

并行报告在概念上是简单的，但由于中间件客户端将报告与应用进行关联，因此其可能需要更高的带宽使用。中间件客户端可以在同一个MBMS会话期间同时地收集多个报告。与并行报告相比，下文参照图17到图24所讨论的线性报告需要更少的带宽使用，这是由于中间件客户端可以在每一个时间周期只报告单一的报告。该线性行为模拟接收机行为。虽然在流服务情况下可能潜在存在更大数量的报告，但可以容易地对这些报告进行汇总。

图17是示出针对文件传输服务，在具有应用之间的汇总的情况下，(每应用)线性报告的例子的图1700。如图17中所示，应用X请求中间件客户端获得文件1、文件2、以及文件3；应用Y请求中间件客户端获得文件1和文件3；应用Z请求中间件客户端获得文件1。运行在第一UE上的中间件客户端开始与基站的MBMS会话(如果该中间件客户端和LTE调制解调器均与第一UE相关联的话)，或者与第二UE的MBMS会话(如果该中间件客户端和LTE调制解调器与不同的UE相关联；这里，第二UE与LTE调制解调器相关联)。中间件客户端获得文件1、文件2、以及文件3。在获得文件1之后，中间件客户端生成针对应用X、Y、以及Z的一个接收报告。在生成这些接收报告之后，中间件客户端向基站发送该接收报告(如果中间件客户端和LTE调制解调器均与第一UE相关联)，或者向第二UE发送该接收报告(如果该中间件客户端和LTE调制解调器与不同的UE相关联；这里，第二UE与LTE调制解调器相关联)。如果中间件客户端向第二UE发送接收报告，则第二UE将该接收报告转发给基站。在与该会话结束时间的退避和随机化之后发送该接收报告。对于该例子而言，该接收报告可以是RAck。下文参照图18来提供该接收报告的例子。

图18是示出在具有应用之间的汇总的情况下进行线性报告时，针对文件传输服务所发送的接收报告的例子的图1800。中间件客户端生成一个接收报告，来报告应用X、Y、以及Z接收到文件1、文件2、以及文件3。在该接收报告之中，中间件客户端可以通过第一客户端标识符来报告应用X、Y、以及Z接收到文件1；通过第二客户端标识符来报告应用X接收到文件2；通过第三客户端标识符来报告应用X和Y接收到文件3。具体而言，中间件客户端可以通过客户端标识符“X@Y@Z@MDN”来报告应用X、Y、以及Z接收到文件1；通过客户端标识符“X@MDN”来报告应用X接收到文件2；通过客户端标识符“X@Y@MDN”来报告应用X和Y接收到文件3。如上所述，X是应用X的标识符，Y是应用Y的标识符，Z是应用Z的标识符，MDN是运行该中间件客户端的UE的唯一标识符。中间件客户端可以在这些标识符之间使用与“@”字符不同的分隔符。在一些配置中，可以省略MDN标识符。在一些其它配置中，中间件客户端可以与调制解调器相比，位于不同的UE上；在该情况下，还可以提供调制解调器的MDN，例如，X@MDN_middleware@MDN_modem。应用X、Y、以及Z的标识符中的每一个可以是特定于应用的标识符、特定于应用的标识符和唯一性接收机标识符(例如，MDN或者IMEI)的级联、或者对于该应用来说具有唯一性的某种其它标识符。可以将该标识符存储在文件URI属性/元素下。如图18中所可以观察到的，针对该会话而言，同一文件只被报告一次。

图19是示出针对流服务，在不具有应用之间的汇总的情况下，(每应用)线性报告的例子的图1900。如图19中所示，应用X请求中间件客户端在tx1处激活流服务(例如，DASH流服务)的接收，在tx2处使该流服务的接收去激活，应用Y请求中间件客户端在ty1处激活同一流服务的接收，在ty2处使该流服务的接收去激活，应用Z请求中间件客户端在tz1处激活同一流服务的接收，在tz2处使该流服务的接收去激活。运行在第一UE上的中间件客户端，开始与基站的MBMS会话(如果该中间件客户端和LTE调制解调器均与第一UE相关联的话)，或者与第二UE的MBMS会话(如果该中间件客户端和LTE调制解调器与不同的UE相关联；这里，第二UE与LTE调制解调器相关联)。中间件客户端开始在tx1处接收流服务，在tz2处使流服务的接收去激活。用于生成接收报告的报告会话，在应用对服务进行激活和去激活的每一个时间进行起始和结束。因此，在该例子中，存在五个报告会话，第一报告对应于tx1到ty1，第二报告对应于ty1到tx2，第三报告对应于tx2到tz1，第四报告对应于tz1到ty2，第五报告对应于ty2到tz2。因此，在接收到该流服务之后，中间件客户端生成关于接收到tx1和ty1之间的流服务的针对应用X的第一接收报告、关于接收到ty1和tx2之间的流服务的针对应用X和Y的第二接收报告、关于接收到tx2和tz1之间的流服务的针对应用Y的第三接收报告、关于接收到tz1和ty2之间的流服务的针对应用Y和Z的第四接收报告、以及关于接收到ty2和tz2之间的流服务的针对应用Z的第五接收报告。在生成第五接收报告之后，中间件客户端可以将这些接收报告级联在一起，并将级联后的接收报告发送给基站(如果中间件客户端和LTE调制解调器均与第一UE相关联的话)或者第二UE(如果中间件客户端和LTE调制解调器与不同的UE相关联；这里，第二UE与LTE调制解调器相关联)。如果中间件客户端向第二UE发送该级联的接收报告，则第二UE将该级联的接收报告转发给基站。在与该会话结束时间的退避和随机化之后发送该级联的接收报告。对于该例子而言，该接收报告可以是StaR、StaR-all或者StaR-only。在一种配置中，对于该例子而言，该接收报告可以是StaR-only。下文参照图20、21、以及图22来提供这五个接收报告的例子。

图20、图21、以及图22分别是示出在不具有应用之间的汇总的情况下进行线性报告时，针对流服务所发送的接收报告的例子的图2000、2100、以及2200。中间件客户端生成第一接收报告，以报告应用X对接收的对象60和59的接收，生成第二接收报告，以报告应用X和Y对接收的对象58和57的接收，生成第三接收报告，以报告应用Y对接收的对象56的接收，生成第四接收报告，以报告应用Y和Z对接收的对象55的接收，以及生成第五接收报告，以报告应用Z对接收的对象54、53、以及52的接收。对于客户端标识符而言，中间件客户端可以报告具有与该中间件客户端和接收到所述一个或多个对象的应用相关联的信息的客户端标识符。例如，对于第一接收报告而言，中间件客户端报告客户端标识符“X@MDN”。对于第二接收报告而言，中间件客户端报告客户端标识符“X@Y@MDN”。对于第三接收报告而言，中间件客户端报告客户端标识符“Y@MDN”。对于第四接收报告而言，中间件客户端报告客户端标识符“Y@Z@MDN”。对于第五接收报告而言，中间件客户端报告客户端标识符“Z@MDN”。X是应用X的标识符，Y是应用Y的标识符，Z是应用Z的标识符，MDN是运行中间件客户端的UE的唯一标识符。如上所述，中间件客户端可以在这些标识符之间使用与“@”字符不同的分隔符。在一些配置中，可以省略MDN标识符。应用X、Y、以及Z的标识符中的每一个可以是特定于应用的标识符、特定于应用的标识符和唯一性接收机标识符(例如，MDN或者IMEI)的级联、或者对于该应用来说具有唯一性的某种其它标识符。可以将该标识符存储在统计报告属性/元素下。如图20到图22中所可以观察到的，每一个对象只被报告一次。

图23和图24分别是示出在具有应用之间的汇总的情况下进行线性报告时，针对流服务所发送的接收报告的例子的图2300和2400。中间件客户端生成一个汇总的接收报告，以报告应用X对于对象60到59的接收，应用X和Y对于对象58和57的接收，应用Y对于对象56的接收，应用Y和Z对于对象55的接收，以及应用Z对于对象54、53、以及52的接收。对于客户端标识符而言，中间件客户端可以报告具有与该中间件客户端和接收到这些报告的应用相关联的信息的客户端标识符，如上面结合图20到图22所讨论的。

图25是一种无线通信的方法的流程图2500。该方法可以由第一UE来执行。在2502处，第一UE从运行在第二UE上的应用或者运行在第一UE上的应用接收针对服务的请求。第二UE与第一UE不同。针对服务的请求是针对通过MBMS服务来获得文件集合或者流集合的请求。例如，参见图9的第一配置902，具有中间件客户端908的第一UE从运行在第二UE上的应用910接收针对服务的请求。对于另一个例子而言，参见图9的第二配置922，具有中间件客户端928和LTE调制解调器926的第一UE从运行在第二UE上的应用930接收针对服务的请求。对于另一个例子而言，参见图9的第三配置942，具有中间件客户端948和应用950的第一UE从运行在第一UE上的应用950接收针对服务的请求。对于另一个例子而言，参见图9的第四配置962，具有中间件客户端968、应用970、以及LTE调制解调器966的第一UE，从运行在第一UE上的应用970接收针对服务的请求。

在2504处，第一UE尝试通过MBMS服务，从基站或者第三UE中的一个接收该文件集合或者流集合。例如，参见图9的第二配置922，具有中间件客户端928和LTE调制解调器926的第一UE通过MBMS服务，从基站接收该文件集合或者流集合。对于另一个例子而言，参见图9的第四配置962，具有中间件客户端970、LTE调制解调器966、以及应用970的第一UE通过MBMS服务，从基站接收该文件集合或者流集合。对于另一个例子而言，参见图9的第一配置902，具有中间件客户端908的第一UE通过MBMS服务，从具有LTE调制解调器906的第三UE接收该文件集合或者流集合。对于另一个例子而言，参见图9的第三配置942，具有中间件客户端948和应用950的第一UE通过MBMS服务，从具有LTE调制解调器946的第三UE接收该文件集合或者流集合。

在2506处，第一UE发送包括以下内容的接收报告：与该文件集合或者流集合相关联的接收确认或者统计报告中的至少一项。与该文件集合或者流集合相关联的接收确认或者统计报告中的至少一项包括：与第二UE、第三UE、运行在第二UE上的应用、或者运行在第一UE上的应用中的至少一个相关联的标识符。在一些场景中，当中间件与LTE调制解调器没有同处一地时(例如，配置902、942)，则该报告还可以包括：与携带LTE调制解调器的第三UE相关联的标识符。例如，参见图9的第一配置902，具有中间件客户端908的第一UE向LTE调制解调器906发送包括以下内容的接收报告：与该文件集合或者流集合相关联的接收确认或者统计报告中的至少一项。与该文件集合或者流集合相关联的接收确认或者统计报告中的至少一项包括与下面中的至少一项相关联的标识符：包括LTE调制解调器906的第三UE、运行在第二UE上的应用910、或者运行应用910的第二UE。对于另一个例子而言，参见图9的第二配置922，具有中间件客户端928和LTE调制解调器926的第一UE向基站发送包括以下内容的接收报告：与该文件集合或者流集合相关联的接收确认或者统计报告中的至少一项。与该文件集合或者流集合相关联的接收确认或者统计报告中的至少一项包括：与运行在第二UE上的应用930、或者运行应用930的第二UE相关联的标识符。对于另一个例子而言，参见图9的第三配置942，具有中间件客户端948和应用950的第一UE向LTE调制解调器946发送包括以下内容的接收报告：与该文件集合或者流集合相关联的接收确认或者统计报告中的至少一项。与该文件集合或者流集合相关联的接收确认或者统计报告中的至少一项包括：与具有LTE调制解调器946的第三UE或者运行在第一UE上的应用950中的至少一个相关联的标识符。

在上面的例子中，与第二UE、第三UE、运行在第二UE上的应用或者运行在第一UE上的应用中的至少一个相关联的标识符可以是X。因此，可以将客户端标识符设置成X。在一种配置中，客户端标识符可以包括第一UE的标识符(例如，MDN)。在该配置中，可以将客户端标识符设置成“X@MDN”，如上所述。在2506之后，在一些配置中，可以参照图26、图27、图28、或者图29来执行2508。

在一种配置中，与所述文件集合或者流集合相关联的接收确认或者统计报告中的至少一项包括与第一UE相关联的标识符，其中，与第一UE相关联的标识符不同于与运行在第一UE上的应用相关联的标识符。例如，参见图9的第一配置902，该标识符可以包括运行中间件客户端908的第一UE的MDN。此外，该标识符还可以包括应用910的标识符、或者运行应用910的UE的标识符。对于另一个例子而言，参见图9的第二配置922，该标识符可以包括运行中间件客户端928的第一UE的MDN。此外，该标识符还可以包括应用930的标识符、或者运行应用930的UE的标识符。对于另一个例子而言，参见图9的第三配置942，该标识符可以包括运行中间件客户端948的第一UE的MDN。此外，该标识符还可以包括应用950的标识符。

在一种配置中，与运行在第一UE上的应用相关联的标识符是与运行在第一UE上的不同应用相关联的多个标识符中的一个标识符。在一种配置中，与第一UE相关联的标识符以及与第二UE、第三UE、运行在第二UE上的应用、或者运行在第一UE上的应用中的至少一个相关联的标识符，在接收确认或者统计报告中的至少一个中的客户端标识符属性/元素(例如，文件URI属性/元素或者统计报告属性/元素中的客户端ID属性/元素；参见图30)中进行指示。在一种配置中，与第一UE相关联的标识符在接收确认或者统计报告中的至少一个中的客户端标识符属性/元素(例如，客户端ID属性/元素)中进行指示，与第二UE、第三UE、运行在第二UE上的应用或者运行在第一UE上的应用中的至少一个相关联的标识符在接收确认或者统计报告中的至少一个中的不同属性/元素(例如，不同于客户端ID属性/元素的属性/元素)中进行指示。具体而言，可以在接收确认和统计报告元素中引进不同的属性/元素，其中该接收确认和统计报告元素指示请求这些文件/流并且是这些文件/流的最终目的地的UE或者运行在这些UE之上的应用。在一种配置中，该标识符与第二UE或者运行在第二UE上的应用相关联(例如，参见图9的第一配置902和第二配置922)。在一种配置中，该标识符与运行在第一UE上的应用相关联(例如，参见图9的第三配置942)。

图26是一种无线通信的方法的流程图2600。该方法可以由第一UE来执行。在图25的2502、2504、以及2506处，所述文件集合或者流集合是一个文件集合，所述接收报告包括与该文件集合相关联的接收确认(RAck)。从图25的步骤2508转到步骤2602。在2602处，第一UE从第四UE或者运行在第四UE上的应用接收针对第二文件集合的请求。在2604处，第一UE尝试通过MBMS服务来接收第二文件集合。在2606处，第一UE发送第二接收报告，其中该第二接收报告包括与第二文件集合相关联的接收确认。与第二文件集合相关联的接收确认包括：与第一UE相关联的标识符(例如，MDN)、以及与第四UE或者运行在第四UE上的应用中的至少一个相关联的标识符。例如，如果与第四UE或者运行在第四UE上的应用中的至少一个相关联的标识符是Y，则可以将客户端标识符设置成“Y@MDN”，如上所述。在一种配置中，将所述接收报告和第二接收报告汇总到一个报告中(例如，参见图12、图18)。

图27是一种无线通信的方法的流程图2700。该方法可以由第一UE来执行。从图25的步骤2508转到2702。在步骤2702处，第一UE从第四UE或者运行在第四UE上的应用接收针对第二文件集合的请求。此外，所述接收确认还与该第二文件集合相关联。所述文件集合是S₁，第二文件集合是S₂。针对文件集合S₁∩S₂(其中，∩是这些集合的交集)，所述接收确认包括：用于确认文件S₁∩S₂的接收的子元素、与第一UE相关联的标识符(例如，MDN)、以及与下面中的至少一项相关联的标识符：第二UE和第四UE二者或者运行在第二UE和第四UE二者上的应用(例如，X可以是第二UE或者运行在第二UE上的应用的标识符，Y可以是第四UE或者运行在第四UE上的应用的标识符)。例如，这三个标识符位于客户端ID“X@Y@MDN”中。针对不包括文件子集S₁∩S₂的文件集合S₁，所述接收确认包括：用于确认不包括文件子集S₁∩S₂的文件S₁的接收的子元素、与第一UE相关联的标识符(例如，MDN)、以及与第二UE或者运行在第二UE上的应用中的至少一个相关联的标识符(例如，X)。例如，这两个标识符位于客户端ID“X@MDN”中。针对不包括文件子集S₁∩S₂的文件集合S₂，所述接收确认包括：用于确认不包括文件子集S₁∩S₂的文件集合S₂的接收的子元素、与第一UE相关联的标识符(例如，MDN)、以及与第四UE或者运行在第四UE上的应用中的至少一个相关联的标识符(例如，Y)。例如，这两个标识符位于客户端ID“Y@MDN”中。

图28是一种无线通信的方法的流程图2800。该方法可以由第一UE来执行。在图25的2502、2504、以及2506处，所述文件集合或者流集合是一个流集合，所述接收报告包括与该流集合相关联的统计报告(例如，StaR、StaR-all、StaR-only)。从图25的步骤2508转到2802。在2802处，第一UE从第四UE或者运行在第四UE上的应用接收针对该流集合的请求。在2804处，第一UE发送第二接收报告，其中该第二接收报告包括与该流集合相关联的第二统计报告。与该流集合相关联的第二统计报告包括：与第一UE相关联的标识符(例如，MDN)、以及与第四UE或者运行在第四UE上的应用中的至少一个相关联的标识符(例如，Y)。例如，如果与第四UE或者运行在第四UE上的应用中的至少一个相关联的标识符是Y，则可以将该客户端标识符设置为“Y@MDN”，如上所述。在一种配置中，将所述接收报告和第二接收报告汇总到一个报告中(例如，参见图16、图23、图24)。

图29是一种无线通信的方法的流程图2900。该方法可以由第一UE来执行。从图25的步骤2508转到步骤2902。在2902处，第一UE从第四UE或者运行在第四UE上的应用接收针对该流集合的请求。第二UE请求在持续时间T₁期间接收该流集合，第四UE请求在持续时间T₂期间接收该流集合。例如，参见图19，持续时间T₁可以是在tx1和tx2之间的持续时间，并且持续时间T₂可以是在ty1和ty2之间的持续时间。在2904处，第一UE发送与所述流集合相关联的另外的接收报告。

所述接收报告和所述另外的接收报告包括第一接收报告，其包括与在持续时间T₁∩T₂(例如，ty1和tx2之间的持续时间)期间接收的所述流集合相关联的统计报告。与在持续时间T₁∩T₂期间接收的所述流集合相关联的统计报告包括：与第一UE相关联的标识符(例如，MDN)、以及与下面中的至少一项相关联的标识符：第二UE和第四UE二者或者运行在第二UE和第四UE二者上的应用(例如，X可以是第二UE或者运行在第二UE上的应用的标识符，Y可以是第四UE或者运行在第四UE上的应用的标识符)。例如，这三个标识符位于客户端ID“X@Y@MDN”中。

此外，所述接收报告和所述另外的接收报告还包括第二接收报告，其包括与在不包括持续时间T₁∩T₂的持续时间T₁(例如，tx1和ty1之间的持续时间)期间接收的所述流集合相关联的统计报告。与在不包括持续时间T₁∩T₂的持续时间T₁期间接收的所述流集合相关联的统计报告包括：与第一UE相关联的标识符(例如，MDN)、以及与第二UE或者运行在第二UE上的应用中的至少一个相关联的标识符(例如，X)。例如，这两个标识符位于客户端ID“X@MDN”中。

此外，所述接收报告和所述另外的接收报告还包括第三接收报告，其包括与在不包括持续时间T₁∩T₂的持续时间T₂(例如，tx2和ty2之间的持续时间)期间接收的所述流集合相关联的统计报告。与在不包括持续时间T₁∩T₂的持续时间T₂期间接收的所述流集合相关联的统计报告包括：与第一UE相关联的标识符、以及与第四UE或者运行在第四UE上的应用中的至少一个相关联的标识符。例如，这两个标识符位于客户端ID“Y@MDN”中。

图30是示出接收报告中的客户端ID属性/元素的图。可以将前述的客户端标识符添加在文件URI下或者统计报告下的客户端ID属性/元素中，或者添加在与客户端ID元素属性不同的属性/元素下。

图31是示出示例性装置3102中的不同模块/单元/部件之间的数据流的概念性数据流图3100。该装置可以是第一UE 3102。第一UE 3102包括接收模块3104，后者被配置为从运行在第二UE 3112上的应用(参见图9的配置902、922)或者运行在第一UE 3102上的应用(参见图9的配置942、962)接收针对服务的请求。第二UE 3112与第一UE 3102不同。针对服务的请求是针对通过MBMS服务来获得文件集合或者流集合的请求。接收模块3104被配置为向MBMS模块3108提供MBMS请求。接收模块3104被配置为尝试通过MBMS服务从基站3116(参见图9的配置922、962)或者第三UE 3114(参见图9的配置902、942)中的一个接收该文件集合或者流集合。接收模块3104被配置为向MBMS模块3108提供任何接收的文件/流。MBMS模块3108被配置为向传输模块3110提供接收的文件/流。传输模块3110被配置为向请求这些文件/流的UE提供这些接收的文件/流(即，图9的配置902、922所对应的第二UE 3112；图9的配置942所对应的第一UE 3102)。此外，第一UE 3102还包括接收报告生成模块3106，后者被配置为生成接收报告，并将所生成的接收报告提供给传输模块3110。传输模块3110被配置为发送接收报告，其中该接收报告包括与所述文件集合或者流集合相关联的接收确认或者统计报告中的至少一项。与该文件集合或者流集合相关联的接收确认或者统计报告中的至少一项包括：与第二UE 3112、第三UE 3114、运行在第二UE 3112上的应用、或者运行在第一UE 3102上的应用中的至少一个相关联的标识符。

在一种配置中，与该文件集合或者流集合相关联的接收确认或者统计报告中的至少一项包括与第一UE相关联的标识符。与第一UE相关联的标识符不同于与运行在第一UE上的应用相关联的标识符。在一种配置中，与运行在第一UE上的应用相关联的标识符是与运行在第一UE上的不同应用相关联的多个标识符中的一个标识符。在一种配置中，与第一UE相关联的标识符以及与第二UE、第三UE、运行在第二UE上的应用、或者运行在第一UE上的应用中的至少一个相关联的标识符，在接收确认或者统计报告中的至少一个中的客户端标识符属性中进行指示。在一种配置中，与第一UE相关联的标识符在接收确认或者统计报告中的至少一个中的客户端标识符属性中进行指示，与第二UE、第三UE、运行在第二UE上的应用、或者运行在第一UE上的应用中的至少一个相关联的标识符在接收确认或者统计报告中的至少一个中的不同属性中进行指示。在一种配置中，该标识符与第二UE或者运行在第二UE上的应用相关联。在一种配置中，该标识符与运行在第一UE上的应用相关联。

在一种配置中，所述文件集合或者流集合是一个文件集合，所述接收报告包括与该文件集合相关联的接收确认。在该配置中，接收模块3104被配置为从第四UE或者运行在第四UE上的应用接收针对第二文件集合的请求。此外，接收模块3104还被配置为尝试通过MBMS服务接收第二文件集合。传输模块3110还被配置为发送第二接收报告，其中该第二接收报告包括与第二文件集合相关联的接收确认。与第二文件集合相关联的接收确认包括：与第一UE相关联的标识符、以及与第四UE或者运行在第四UE上的应用中的至少一个相关联的标识符。在一种配置中，将所述接收报告和第二接收报告汇总到一个报告中。

在一种配置中，接收模块3104被配置为从第四UE或者运行在第四UE上的应用接收针对第二文件集合的请求。此外，所述接收确认还与该第二文件集合相关联。所述文件集合是S₁，第二文件集合是S₂。针对文件集合S₁∩S₂，所述接收确认包括：用于确认文件集合S₁∩S₂的接收的子元素、与第一UE相关联的标识符、以及与下面中的至少一项相关联的标识符：第二UE和第四UE二者或者运行在第二UE和第四UE二者上的应用。针对不包括文件子集S₁∩S₂的文件集合S₁，所述接收确认包括：用于确认不包括文件子集S₁∩S₂的文件集合S₁的接收的子元素、与第一UE相关联的标识符、以及与第二UE或者运行在第二UE上的应用中的至少一个相关联的标识符。针对不包括文件子集S₁∩S₂的文件集合S₂，所述接收确认包括：用于确认不包括文件子集S₁∩S₂的文件集合S₂的接收的子元素、与第一UE相关联的标识符、以及与第四UE或者运行在第四UE上的应用中的至少一个相关联的标识符。

在一种配置中，所述文件集合或者流集合是一个流集合，所述接收报告包括与该流集合相关联的统计报告。在一种配置中，接收模块3104还被配置为从第四UE或者运行在第四UE上的应用接收针对该流集合的请求。此外，传输模块3110还被配置为发送第二接收报告，其中该第二接收报告包括与该流集合相关联的第二统计报告。与该流集合相关联的第二统计报告包括：与第一UE相关联的标识符、以及与第四UE或者运行在第四UE上的应用中的至少一个相关联的标识符。在一种配置中，将所述接收报告和第二接收报告汇总到一个报告中。

在一种配置中，接收模块3104还被配置为从第四UE或者运行在第四UE上的应用接收针对该流集合的请求。第二UE请求在持续时间T₁期间接收该流集合，第四UE请求在持续时间T₂期间接收该流集合。此外，所述传输模块还被配置为：发送与所述流集合相关联的另外的接收报告。所述接收报告和所述另外的接收报告包括第一接收报告，其包括与在持续时间T₁∩T₂期间接收的所述流集合相关联的统计报告。与在持续时间T₁∩T₂期间接收的所述流集合相关联的统计报告包括：与第一UE相关联的标识符、以及与下面中的至少一项相关联的标识符：第二UE和第四UE二者或者运行在第二UE和第四UE二者上的应用。此外，所述接收报告和所述另外的接收报告还包括第二接收报告，其包括与在不包括持续时间T₁∩T₂的持续时间T₁期间接收的所述流集合相关联的统计报告。与在不包括持续时间T₁∩T₂的持续时间T₁期间接收的所述流集合相关联的统计报告包括：与第一UE相关联的标识符、以及与第二UE或者运行在第二UE上的应用中的至少一个相关联的标识符。此外，所述接收报告和所述另外的接收报告还包括第三接收报告，其包括与在不包括持续时间T₁∩T₂的持续时间T₂期间接收的所述流集合相关联的统计报告。与在不包括持续时间T₁∩T₂的持续时间T₂期间接收的所述流集合相关联的统计报告包括：与第一UE相关联的标识符、以及与第四UE或者运行在第四UE上的应用中的至少一个相关联的标识符。

该装置可以包括用于执行图25-29的前述流程图中的算法中的每一个步骤的另外模块。同样，图25-29的前述流程图中的每一个框可以由一个模块来执行，该装置可以包括这些模块中的一个或多个。这些模块可以是专门被配置为执行所陈述的处理/算法的一个或多个硬件部件、这些模块可以由配置为执行所陈述的处理/算法的处理器来实现、存储在计算机可读介质之中以便由处理器实现、或者是其某种组合。

图32是示出用于使用处理系统3214的装置3102'的硬件实现的例子的图3200。处理系统3214可以使用总线体系结构来实现，其中该总线体系结构通常用总线3224来表示。根据处理系统3214的具体应用和整体设计约束条件，总线3224可以包括任意数量的相互连接总线和桥接。总线3224将包括一个或多个处理器和/或硬件模块(其用处理器3204、模块3104、3106、3108、3110表示)、以及计算机可读介质/存储器3206的各种电路链接在一起。此外，总线3224还链接诸如时钟源、外围设备、电压调节器和电源管理电路等等之类的各种其它电路，其中这些电路是本领域所公知的，因此没有做任何进一步的描述。

处理系统3214可以耦合到收发机3210。收发机3210耦合到一个或多个天线3220。收发机3210提供通过传输介质与各种其它装置进行通信的单元。收发机3210从所述一个或多个天线3220接收信号，从所接收的信号中提取信息，将提取的信息提供给处理系统3214(具体而言，接收模块3104)。此外，收发机3210还从处理系统3214(具体而言，传输模块3110)接收信息，并基于所接收的信息，生成要应用于所述一个或多个天线3220的信号。处理系统3214包括耦合到计算机可读介质/存储器3206的处理器3204。处理器3204负责通用处理，其包括执行计算机可读介质/存储器3206上存储的软件。当该软件由处理器3204执行时，使得处理系统3214执行上文针对任何特定装置所描述的各种功能。计算机可读介质/存储器3206还可以用于存储当处理器3204执行软件时所操作的数据。此外，该处理系统还包括模块3104、3106、3108、以及3110中的至少一个。这些模块可以是在处理器3204中运行、驻留/存储在计算机可读介质/存储器3206中的软件模块、耦合到处理器3204的一个或多个硬件模块、或者其某种组合。处理系统3214可以是UE 650的部件，其可以包括存储器660和/或TX处理器668、RX处理器656和控制器/处理器659中的至少一个。

在一种配置中，用于无线通信的装置3102/3102'可以是第一UE。第一UE包括：用于从运行在第二UE上的应用或者运行在第一UE上的应用接收针对服务的请求的单元。第二UE与第一UE不同。针对服务的请求是针对通过MBMS服务来获得文件集合或者流集合的请求。此外，第一UE还包括：用于尝试通过MBMS服务从基站或者第三UE中的一个接收该文件集合或者流集合的单元。此外，第一UE还包括：用于发送接收报告的单元，其中该接收报告包括与所述文件集合或者流集合相关联的接收确认或者统计报告中的至少一项。与该文件集合或者流集合相关联的接收确认或者统计报告中的至少一项包括：与第二UE、第三UE、运行在第二UE上的应用、或者运行在第一UE上的应用中的至少一个相关联的标识符。

在一种配置中，所述文件集合或者流集合是一个文件集合，所述接收报告包括与该文件集合相关联的接收确认。在该配置中，第一UE还可以包括：用于从第四UE或者运行在第四UE上的应用接收针对第二文件集合的请求的单元；用于尝试通过MBMS服务接收第二文件集合的单元；用于发送第二接收报告的单元，其中该第二接收报告包括与第二文件集合相关联的接收确认。与第二文件集合相关联的接收确认包括：与第一UE相关联的标识符、以及与第四UE或者运行在第四UE上的应用中的至少一个相关联的标识符。在该配置中，第一UE还可以包括：用于从第四UE或者运行在第四UE上的应用接收针对第二文件集合的请求的单元。此外，所述接收确认还与该第二文件集合相关联。所述文件集合是S₁，第二文件集合是S₂。针对文件集合S₁∩S₂，所述接收确认包括：用于确认文件S₁∩S₂的接收的子元素、与第一UE相关联的标识符、以及与下面中的至少一项相关联的标识符：第二UE和第四UE二者或者运行在第二UE和第四UE二者上的应用。针对不包括文件子集S₁∩S₂的文件S₁，所述接收确认包括：用于确认不包括文件子集S₁∩S₂的文件S₁的接收的子元素、与第一UE相关联的标识符、以及与第二UE或者运行在第二UE上的应用中的至少一个相关联的标识符。针对不包括文件子集S₁∩S₂的文件集合S₂，所述接收确认包括：用于确认不包括文件子集S₁∩S₂的文件S₂的接收的子元素、与第一UE相关联的标识符、以及与第四UE或者运行在第四UE上的应用中的至少一个相关联的标识符。

在一种配置中，所述文件集合或者流集合是一个流集合，所述接收报告包括与该流集合相关联的统计报告。在该配置中，第一UE还可以包括：用于从第四UE或者运行在第四UE上的应用接收针对该流集合的请求的单元；用于发送第二接收报告的单元，其中该第二接收报告包括与该流集合相关联的第二统计报告。与该流集合相关联的第二统计报告包括：与第一UE相关联的标识符、以及与第四UE或者运行在第四UE上的应用中的至少一个相关联的标识符。在该配置中，第一UE还可以包括：用于从第四UE或者运行在第四UE上的应用接收针对该流集合的请求的单元。第二UE请求在持续时间T₁期间接收该流集合，第四UE请求在持续时间T₂期间接收该流集合。此外，第一UE还可以包括：用于发送与所述流集合相关联的另外的接收报告的单元。

所述接收报告和所述另外的接收报告包括第一接收报告，其包括与在持续时间T₁∩T₂期间接收的所述流集合相关联的统计报告。与在持续时间T₁∩T₂期间接收的所述流集合相关联的统计报告包括：与第一UE相关联的标识符、以及与下面中的至少一项相关联的标识符：第二UE和第四UE二者或者运行在第二UE和第四UE二者上的应用。

此外，所述接收报告和所述另外的接收报告还包括第二接收报告，其包括与在不包括持续时间T₁∩T₂的持续时间T₁期间接收的所述流集合相关联的统计报告。与在不包括持续时间T₁∩T₂的持续时间T₁期间接收的所述流集合相关联的统计报告包括：与第一UE相关联的标识符、以及与第二UE或者运行在第二UE上的应用中的至少一个相关联的标识符。

此外，所述接收报告和所述另外的接收报告还包括第三接收报告，其包括与在不包括持续时间T₁∩T₂的持续时间T₂期间接收的所述流集合相关联的统计报告。与在不包括持续时间T₁∩T₂的持续时间T₂期间接收的所述流集合相关联的统计报告包括：与第一UE相关联的标识符、以及与第四UE或者运行在第四UE上的应用中的至少一个相关联的标识符。

前述的单元可以是装置3102的前述模块中的一个或多个，和/或配置为执行这些前述单元所述的功能的装置3102’的处理系统3214。如上所述，处理系统3214可以包括TX处理器668、RX处理器656和控制器/处理器659。因此，在一种配置中，前述的单元可以是TX处理器668、RX处理器656和配置为执行这些前述单元所陈述的功能的控制器/处理器659。

应当理解的是，本文所公开处理/流程图中的特定顺序或者步骤层次只是示例方法的一个例子。应当理解的是，根据设计优先选择，可以重新排列这些处理/流程图中的特定顺序或步骤层次。此外，可以对一些步骤进行组合或省略。所附的方法权利要求以示例顺序给出各个步骤的元素，但并不意味着其受到给出的特定顺序或层次的限制。

为使本领域任何普通技术人员能够实现本文所描述的各个方面，上面围绕各个方面进行了描述。对于本领域普通技术人员来说，对这些方面的各种修改都是显而易见的，并且本文定义的总体原理也可以适用于其它方面。因此，本发明并不限于本文所示出的方面，而是与本发明公开的全部范围相一致，其中，除非特别说明，否则用单数形式修饰某一部件并不意味着“一个和仅仅一个”，而可以是“一个或多个”。本文所使用的“示例性的”一词意味着“用作例子、例证或说明”。本文中描述为“示例性”的任何方面不应被解释为比其它方面更优选或更具优势。除非另外特别说明，否则术语“一些”指代一个或多个。诸如“A、B或C中的至少一个”、“A、B和C中的至少一个”以及“A、B、C或者其任意组合”之类的组合，包括A、B和/或C的任意组合，其可以包括多个A、多个B或者多个C。具体而言，诸如“A、B或C中的至少一个”、“A、B和C中的至少一个”以及“A、B、C或者其任意组合”之类的组合，可以是仅仅A、仅仅B、仅仅C、A和B、A和C、B和C或者A和B和C，其中，任意的这种组合可以包含A、B或C中的一个或多个成员或者一些成员。贯穿本发明描述的各个方面的部件的所有结构和功能等价物以引用方式明确地并入本文中，并且旨在由权利要求所涵盖，这些结构和功能等价物对于本领域普通技术人员来说是公知的或将要是公知的。此外，本文中没有任何公开内容是想要奉献给公众的，不管这样的公开内容是否明确记载在权利要求书中。权利要求的构成要素不应被解释为功能模块，除非该构成要素明确采用了“功能性模块”的措辞进行记载。