CN115243201B

CN115243201B - 一种多播实现方法和装置

Info

Publication number: CN115243201B
Application number: CN202110443367.0A
Authority: CN
Inventors: 常光辉; 闫旭峰
Original assignee: Datang Mobile Communications Equipment Co Ltd
Current assignee: Datang Mobile Communications Equipment Co Ltd
Priority date: 2021-04-23
Filing date: 2021-04-23
Publication date: 2023-10-31
Anticipated expiration: 2041-04-23
Also published as: CN115243201A

Abstract

本申请实施例提供了一种多播实现方法和装置，所述方法包括：基站根据用户终端的业务类型建立多媒体广播多播服务MBMS用户队列；接收预设链路方向发送的通信数据，并根据所述MBMS用户队列所包含的业务承载确定所述通信数据的数据类型；若所述通信数据为下行链路的通信数据，且所述通信数据的数据类型为主用户数据，将所述通信数据发送给所述主用户终端，以及将所述通信数据分发到所述辅用户终端。通过根据所建立的MBMS队列以及所接收的通信数据识别出MBMS用户，并将主用户终端的流量分发到辅用户终端，使得能够减小上游传输网络所带来的压力，避免出现在业务集中时所存在的时延大、视频不同步的问题。

Description

一种多播实现方法和装置

技术领域

本申请涉及通信技术领域，特别是涉及一种多播实现方法和一种多播实现装置。

背景技术

在3GPP(3rd Generation Partnership Project，第三代合作伙伴计划)中已规定了多播业务MBMS(Multimedia Broadcast Multicast Service，多媒体广播多播业务)的标准，以及在4G LTE(The 4th Generation mobile communication technology，即第四代移动电话行动通信标准，指的是第四代移动通信技术)时期对多播业务MBMS进行增强且提出了E-MBMS业务(Enhance MultimediaBroadcastMulticast Service多媒体广播多播业务)，但由于应用场景少、网络覆盖较差和依托大塔的广播业务正处于较完善的时期等因素，E-MBMS业务并未被推行。而在R14版本(其为一种LTE版本)的标准中，基于E-MBMS业务进行进一步地增强，规定了enTV(Enhance Televison，增强电视)功能，即可以在多播基础上，将广播的服务与传输彻底解耦，实现可以不依托于与运营商的签约便可完成接收多播业务的功能，然而该功能进入R14时已是LTE发展后期，终端能力等未重视此功能，应用场景也比较有限，因此没有得到广泛推广和应用，还保持传统的“点对点”单播应用方式。

随着移动通信系统从4G向5G(5th-Generation，第五代移动通信技术，也是蜂窝移动通信技术)的演进，4K/8K(指的是分辨率)超高清视频、三维立体视频、多视角视频、VR(Virtual Reality，虚拟现实，也称为虚拟技术)、AR(Augmented Reality，增强现实，是一种实时地计算摄影机影像的位置及角度并加上相应图像的技术)等高质量多媒体业务将会得到广泛应用，流媒体视频与智能手机、平板电脑等移动智能终端在人们的日常生活中扮演着重要的角色。蜂窝移动通信网络内传输的流量不断提升，甚至被很多人形容成“爆发式增长”，给网络的持续扩容升级带来越来越大的压力，而导致传统的单播模式给上游传输网络带来较大压力。

发明内容

鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种多播实现方法和相应的一种多播实现装置。

为了解决上述问题，本申请实施例公开了一种多播实现方法，所述方法包括：

基站根据用户终端的业务类型建立多媒体广播多播MBMS用户队列；所述MBMS用户队列存在与所述业务类型相应业务承载所对应的主用户终端和辅用户终端；

接收预设链路方向发送的通信数据，并根据所述MBMS用户队列所包含的业务承载确定所述通信数据的数据类型；

若所述通信数据为下行链路的通信数据，且所述通信数据的数据类型为主用户数据，将所述通信数据发送给所述主用户终端，以及将所述通信数据分发到所述辅用户终端。

可选地，所述MBMS用户队列存在业务承载的承载标识与用户终端的索引关系；根据所述MBMS用户队列所包含的业务承载确定所述通信数据的数据类型，包括：

确定所述通信数据的业务承载以及所述通信数据的业务承载相应的承载标识；

若所述MBMS用户队列中存在所述通信数据的业务承载相应的承载标识，且所述承载标识与所述主用户终端具有索引关系，则确定所述通信数据的数据类型为主用户数据；

若所述MBMS用户队列中存在所述通信数据的业务承载相应的承载标识，且所述承载标识与所述辅用户标识具有索引关系，则确定所述通信数据的数据类型为辅用户数据。

可选地，将所述通信数据分发到所述辅用户终端，包括：

确定所述通信数据的业务承载上的业务类型，以及从所述MBMS用户队列中确定与所述主用户数据具有相同业务类型的辅用户终端；

将所述主用户数据依次复制给所述具有相同业务类型的辅用户终端对应的业务承载。

可选地，所述将所述主用户数据依次复制给所述具有相同业务类型的辅用户终端对应的业务承载，包括：

获取所述下行链路的通信数据的通信数据包；

按照所述辅用户终端对应的业务承载更新所述通信数据包的包头信息。

可选地，所述按照所述辅用户终端对应的业务承载更新所述通信数据包的包头信息，包括：

若所述具有相同业务类型的辅用户终端的数量为一个，则确定所述辅用户终端对应的业务承载的通信地址为目标地址信息，并修改所述通信数据包的包头信息中所包含的通信地址信息为目标地址信息；

或，若所述具有相同业务类型的辅用户终端的数量为多个，获取预先设置的具有相同业务类型的辅用户终端的广播地址，并将所述广播地址作为目标地址信息，以及修改所述数据包的包头信息中所包含的通信地址信息为所述目标地址信息。

可选地，所述方法还包括：

若所述下行链路的通信数据的数据类型为辅用户数据，且所述下行链路的通信数据不是预设类型的数据，则停止向所述辅用户终端传输所述下行链路的通信数据。

可选地，所述预设链路方向发送的通信数据还包括上行链路的通信数据；所述方法还包括：

若所述上行链路的通信数据的数据类型为主用户数据，则将所述上行链路的通信数据发送给核心网络；

或，若所述上行链路的通信数据的数据类型为辅用户数据，且所述上行链路的通信数据为传输控制协议TCP数据，则将所述上行链路的通信数据发送给核心网络；

或，若所述上行链路的通信数据的数据类型为辅用户数据，且所述上行链路的通信数据为用户数据报协议UDP数据，则停止向核心网传输所述上行链路的通信数据。

可选地，所述基站根据用户终端的业务类型建立多媒体广播多播MBMS用户队列，包括：

所述基站向业务服务器传输用户终端发送的业务连接请求；所述业务连接请求由所述用户终端根据所需请求数据的业务类型生成；

判断是否接收到所述业务服务器返回的业务应答数据；所述业务应答数据由所述业务服务器响应所述业务连接请求生成；

若接收到所述业务服务器返回的业务应答数据，则将所述用户终端添加到预先建立的MBMS用户队列。

可选地，所述将所述用户终端添加到MBMS用户队列，包括：

对所述用户终端增加用户标识及承载标识，将增加标识后的用户终端添加至预先建立的MBMS用户队列。

可选地，对所述用户终端增加用户标识，包括：

识别与所述首个业务应答数据相应的用户终端为主用户终端，同时对所述主用户终端增加主用户标识；

将在首个业务应答数据之后识别到的业务应答数据相应的用户终端做为辅用户终端，同时对与所述辅用户终端增加辅用户标识。

可选地，所述业务连接请求包含所请求数据的业务类型，对所述用户终端增加承载标识，包括：

确定所述所请求数据的业务类型的目标业务承载；

根据所述目标业务承载生成承载标识，并对所述用户终端增加所生成的承载标识。

可选地，所述主用户终端为所述MBMS用户队列中的首位用户终端，所述方法还包括：

删除所述MBMS用户队列中的首位用户终端；

在删除所述首位用户终端之后，获取当前位于所述MBMS用户队列中头结点的辅用户终端，并将所述当前位于所述MBMS用户队列中头结点的辅用户终端作为新的主用户终端。

本申请实施例还公开了一种多播实现装置，所述装置包括：

用户队列建立模块，用于根据用户终端的业务类型建立MBMS用户队列；所述MBMS用户队列存在与所述业务类型相应业务承载所对应的主用户终端和辅用户终端；

数据类型确定模块，用于接收预设链路方向发送的通信数据，并根据所述MBMS用户队列所包含的业务承载确定所述通信数据的数据类型；

通信数据分发模块，用于若所述通信数据为下行链路的通信数据，且所述通信数据的数据类型为主用户数据，将所述通信数据发送给所述主用户终端，以及将所述通信数据分发给所述辅用户终端。

可选地，所述MBMS用户队列存在业务承载的承载标识与用户终端的索引关系；所述数据类型确定模块包括：

承载标识确定子模块，用于确定所述通信数据的业务承载以及所述通信数据的业务承载相应的承载标识；

主用户数据类型确定子模块，用于若所述MBMS用户队列中存在所述通信数据的业务承载相应的承载标识，且所述承载标识与所述主用户终端具有索引关系，则确定所述通信数据的数据类型为主用户数据；

辅用户数据类型确定子模块，用于若所述MBMS用户队列中存在所述通信数据的业务承载相应的承载标识，且所述承载标识与所述辅用户标识具有索引关系，则确定所述通信数据的数据类型为辅用户数据。

可选地，所述通信数据分发模块包括：

辅用户终端获取子模块，用于确定所述通信数据的业务承载上的业务类型，以及从所述MBMS用户队列中确定与所述主用户数据具有相同业务类型的辅用户终端；

通信数据分发子模块，用于将所述主用户数据依次复制给所述具有相同业务类型的辅用户终端对应的业务承载。

可选地，所述通信数据分发子模块包括：

通信数据包获取单元，用于获取所述下行链路的通信数据的通信数据包；

包头信息更新单元，用于按照所述辅用户终端对应的业务承载更新所述通信数据包的包头信息。

可选地，所述包头信息更新单元包括：

第一包头信息更新子单元，用于若所述具有相同业务类型的辅用户终端的数量为一个，则确定所述辅用户终端对应的业务承载的通信地址为目标地址信息，并修改所述通信数据包的包头信息中所包含的通信地址信息为目标地址信息；

第二包头信息更新子单元，用于若所述具有相同业务类型的辅用户终端的数量为多个，获取预先设置的具有相同业务类型的辅用户终端的广播地址，并将所述广播地址作为目标地址信息，以及修改所述数据包的包头信息中所包含的通信地址信息为所述目标地址信息。

可选地，所述通信数据分发模块还包括：

第一通信数据丢弃子模块，用于若所述下行链路的通信数据的数据类型为辅用户数据，且所述下行链路的通信数据不是预设类型的数据，则停止向所述辅用户终端传输所述下行链路的通信数据。

可选地，所述预设链路方向发送的通信数据还包括上行链路的通信数据；所述通信数据分发模块还包括：

第一通信数据发送子模块，用于若所述上行链路的通信数据的数据类型为主用户数据，则将所述上行链路的通信数据发送给核心网络；

第二通信数据发送子模块，用于若所述上行链路的通信数据的数据类型为辅用户数据，且所述上行链路的通信数据为传输控制协议TCP数据，则将所述上行链路的通信数据发送给核心网络；

第二通信数据丢弃子模块，用于若所述上行链路的通信数据的数据类型为辅用户数据，且所述上行链路的通信数据为用户数据报协议UDP数据，则停止向核心网传输所述上行链路的通信数据。

可选地，所述用户队列建立模块包括：

业务连接请求发送子模块，用于向业务服务器传输用户终端发送的业务连接请求；所述业务连接请求由所述用户终端根据所需请求数据的业务类型生成；

业务应答数据判断子模块，用于判断是否接收到所述业务服务器返回的业务应答数据；所述业务应答数据由所述业务服务器响应所述业务连接请求生成；

用户终端添加子模块，用于若接收到所述业务服务器返回的业务应答数据，则将所述用户终端添加到预先建立的MBMS用户队列。

可选地，所述用户终端添加子模块包括：

用户终端添加单元，用于对所述用户终端增加用户标识及承载标识，将增加标识后的用户终端添加至预先建立的MBMS用户队列。

可选地，所述用户终端添加单元模块包括：

主用户标识增加子单元，用于识别与所述首个业务应答数据相应的用户终端为主用户终端，同时对所述主用户终端增加主用户标识；

辅用户标识增加子单元，用于将在首个业务应答数据之后识别到的业务应答数据相应的用户终端作为辅用户终端，同时对与所述辅用户终端增加辅用户标识。

可选地，所述业务连接请求包含所请求数据的业务类型，所述用户终端添加单元包括：

目标业务承载确定子单元，用于确定所述所请求数据的业务类型的目标业务承载；

承载标识增加子单元，用于根据所述目标业务承载生成承载标识，并对所述用户终端增加所生成的承载标识。

可选地，所述主用户终端为所述MBMS用户队列中的首位用户终端，所述装置还包括：

主用户终端删除模块，用于删除所述MBMS用户队列中的首位用户终端；

主用户终端更新模块，用于在删除所述首位用户终端之后，获取当前位于所述MBMS用户队列中头结点的辅用户终端，并将所述当前位于所述MBMS用户队列中头结点的辅用户终端作为新的主用户终端。

本申请实施例还公开了一种装置，包括存储器，收发机，处理器：

存储器，用于存储计算机程序；收发机，用于在所述处理器的控制下收发数据；处理器，用于读取所述存储器中的计算机程序并执行如上述任一项所述的多播实现方法。

本申请实施例还公开了一种处理器可读存储介质，所述处理器可读存储介质存储有计算机程序，所述计算机程序用于使所述处理器执行任一项所述的多播实现方法的步骤。

本申请实施例包括以下优点：

在本申请实施例中，基站可以根据用户终端的业务类型建立MBMS用户队列，并在接收到预设链路方向所发送的通信数据之后，可以根据MBMS用户队列和所接收的通信数据确定通信数据的数据类型，在通信数据为下行链路数据，且通信数据的数据类型为主用户数据的情况下，将通信数据发送主用户终端以及将通信数据分发给辅用户终端。通过预先建立的MBMS用户队列以及根据所接收的通信数据识别出MBMS用户，并将主用户的流量分发到辅用户，减小上游传输网络所带来的压力，避免出现在业务集中时所存在的时延大、视频不同步的问题。

附图说明

图1是现有技术中单播模式业务处理的流程示意图；

图2是本申请实施例中多播模式业务处理的流程示意图；

图3是本申请的一种多播实现方法实施例的步骤流程图；

图4是本申请的另一种多播实现方法实施例的步骤流程图；

图5是本申请实施例中多播实现方法的应用场景一的示意图；

图6是本申请实施例中多播实现方法的应用场景二的示意图；

图7是本申请的一种多播实现装置实施例的结构框图；

图8是本申请中一种装置实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

目前由于应用场景的有限性，还保持着传统的“点对点”单播应用方式，如图1所示，在单播模式下的通信架构可以为终端—5G-NR基站(5G New Radio，为一种专门提供5G网络服务的公用移动通信基站)—5G-enabled EPC(5G Evolved Packet Core，基于5G的演进型分组核心网)—业务服务平台，其中可通过UME网管(Ume network management，其可以用于进行资源集中管理、资源调度分配等)进行统一网管。

具体的，在单播业务模式下，用户在做视频播放、文件下载等业务时，每部终端和服务器单独建立相关传输连接，形成了类似点对点的传输模型；然而在这种模式下，如果在业务集中时段由于服务器或传输网压力过大，可能导致业务时延增大，造成视频的播放不同步问题，影响客户体验等；同时，每部终端同时进行业务时，特殊业务情况下(在线会议或视频实时播放)也会增加客户使用成本。

基于上述问题，在本申请实施例中基于已有的通信框架以及业务流程(如图1所示的单播业务模式处理的流程示意)对流量进行优化处理，进行优化处理后的流程可以如图2所示，为基于NR PDCP(NR Packet Data Convergence Protocol，基站分组数据汇聚协议)的多播业务处理，在这个流程中，每部终端和服务器之间所建立的相关传输连接并不是单独建立的，其可以形成类似点对多点的传输模型，这种点对多点的传输模型可以表现为减少主干网络及传输设备的流量压力。

本申请的核心思想之一是在于基站根据所接收到的通信数据(包括上行数据和下行数据)识别MBMS用户，主要是基于特征业务服务器或业务类型来判断，并在识别之后做主、辅用户标识，然后将主用户流量复制分发到辅用户，有效的减少辅用户流量流经主干网络、时延等，在切实减轻主干网络流量压力的同时还能降低用户时延、提高客户体验等。

参照图3，示出了本申请的一种多播实现方法实施例的步骤流程图，在本申请实施例中，为了减少主干网络及传输设备的流量压力，基站可以将主用户的流量复制分发到辅用户，那么在复制分发，即在通过基站在获取MBMS用户队列之前，需要对主用户和辅用户进行标识，此时可以表现为根据用户终端的业务类型建立MBMS用户队列。

具体可以包括如下步骤：

步骤301，基站向业务服务器传输用户终端发送的业务连接请求；

在本申请的一种实施例中，基站可以与业务服务器进行通信，在对主用户和辅用户进行标识的过程中，可以按照如图2所示的用户终端—基站—业务服务器的通信框架，并基于特征业务服务器或业务类型对NR PDCP多播用户进行识别处理，以识别用户终端并将用户终端添加到MBMS用户队列。其中，与用户终端进行通信的基站，其本质上可以为基站内的主要通信模块SgNB模块(指的是5G NBIOT，5G Narrow Band Internet ofThings，其可以构建于5G蜂窝网络)，SgNB模块可以用于在5G网络中接入信令以及建立连接，此时可以通过SgNB模块将用户终端所发送的业务连接请求转发至业务服务器，以便在建立连接的过程中为后续通信数据的分发创建MBMS用户队列。

在实际应用中，用户终端向业务服务器请求通信数据，可以首先确定所要请求的通信数据的业务类型，并基于所确定的通信数据的业务类型生成相应的业务连接请求，并向符合所请求业务类型的业务服务器发送所生成的业务连接请求；以及，所需请求数据的业务类型还可以基于用户终端所要连接的业务服务器进行确定。对此，本申请实施例不加以限制。

需要说明的是，本申请实施例涉及的终端设备，可以是指向用户提供语音和/或数据连通性的设备，具有无线连接功能的手持式设备、或连接到无线调制解调器的其他处理设备等。在不同的系统中，终端设备的名称可能也不相同，例如在5G系统中，终端设备可以称为用户设备(User Equipment，UE)。无线终端设备可以经无线接入网(RadioAccessNetwork,RAN)与一个或多个核心网(Core Network,CN)进行通信，无线终端设备可以是移动终端设备，如移动电话(或称为“蜂窝”电话)和具有移动终端设备的计算机，例如，可以是便携式、袖珍式、手持式、计算机内置的或者车载的移动装置，它们与无线接入网交换语言和/或数据。例如，个人通信业务(Personal Communication Service，PCS)电话、无绳电话、会话发起协议(Session Initiated Protocol，SIP)话机、无线本地环路(Wireless LocalLoop，WLL)站、个人数字助理(Personal DigitalAssistant，PDA)等设备。无线终端设备也可以称为系统、订户单元(subscriberunit)、订户站(subscriber station)，移动站(mobile station)、移动台(mobile)、远程站(remote station)、接入点(access point)、远程终端设备(remote terminal)、接入终端设备(access terminal)、用户终端设备(userterminal)、用户代理(user agent)、用户装置(user device)，本申请实施例中并不限定。

步骤302，判断是否接收到业务服务器返回的业务应答数据；所述业务应答数据由所述业务服务器响应所述业务连接请求生成；

具体的，基于特征业务服务器或业务类型，可以表现为通过用户终端向某个业务服务器的访问实现，其中，可以测试用户终端与所要访问的业务服务器之间的网络可达性，使得网络可达的业务服务器作为特征业务服务器，或根据网络可达的业务服务器确定业务类型。

在实际应用中，在用户终端已接入网络的情况下，用户终端可以生成针对访问某个业务服务器的业务连接请求，并经由基站向业务服务器发送用户终端所生成的业务连接请求，此时可以根据业务服务器是否返回业务应答数据来确定用户终端与业务服务器之间的网络可达性。

作为一种示例，Ping是一种计算机网络诊断工具，其可以用于测试互联网协议网络上主机的可达性，向业务服务器发送用户终端所生成的业务连接请求，可以表现为通过用户终端向业务服务器以因特网包探索器所具有的Ping特征进行请求，业务服务器的业务应答数据可以表现为业务服务器返回的Ping Reply(为针对Ping操作的回复数据，该PingReply需经由基站返回给用户终端)，即若接收到Ping Reply，则表示用户终端与该业务服务器之间网络可达。

在一种优选的实施例中，假设用户终端始终接入网络，在向业务服务器以因特网包探索器所具有的Ping特征对业务服务器进行请求，但未接收到业务服务器的业务应答数据的情况下，可以在有限次数内不断向特征业务服务器进行Ping触发，直至接收到业务应答数据为止。需要说明的是，有限次数需要按照实际情况而定，对此，本申请实施例不加以限制。

步骤303，若接收到业务服务器返回的业务应答数据，则将所述用户终端添加到预先建立的MBMS用户队列。

在本申请的一种实施例中，在用户终端与业务服务器网络可达的情况下，基站可以将此用户终端添加到预先建立的用户队列，该用户队列可以为MBMS用户队列，即用于进行多播业务的用户队列，以便后续在接收到通信数据时可通过MBMS用户队列确定主、辅用户。

具体的，将用户终端添加到预先建立的MBMS用户队列，可以表现为对用户终端增加用户标识及承载标识，并将增加标识后的用户终端添加至预先建立的MBMS用户队列。其中，可以包括如下子步骤：

子步骤S11，对所述用户终端增加用户标识；

在本申请实施例中，对用户终端所增加的用户标识包括主用户标识和辅用户标识，其中，主用户标识可以用于表示用户终端在MBMS用户队列中为主用户，辅用户标识可以用于表示用户终端在MBMS用户队列中为辅用户。

在实际应用中，可以将第一个被识别的用户终端作为主用户，第一个被识别的用户终端可以指的是第一个与业务服务器进行网络可达检测，且可达的用户终端。

在具体实现中，第一个与业务服务器进行网络可达检测，且可达的用户终端可以通过所接收到的业务应答数据(例如Ping Reply)的次序进行确定。

其中，基站所接收到的业务应答数据可以包括首个业务应答数据和非首个业务应答数据，此时可以识别出与首个业务应答数据相应的用户终端为主用户终端，并对所识别得到的主用户终端增加主用户标识；以及，可以将在首个业务应答数据之后识别到的业务应答数据相应的用户终端作为辅用户终端，并对所识别得到的辅用户终端增加辅用户标识。

子步骤S12，对所述用户终端增加承载标识。

在本申请实施例中，用户终端可能存在多个承载，且用户所要进行的所有业务数据都可以在用户终端的承载上进行，在除了对用户终端增加用户标识以外，还可以对用户终端增加承载标识，该承载标识可以用于确定用户终端所需的业务数据是位于哪个承载上的数据。其中，用户终端上的多个承载可以表现为RB承载(Radio Bearer，无线承载)，业务数据的承载一般为DRB承载(Data Radio Bearer carrying userplane data，数据无线承载)上的承载。

在实际应用中，可以确定业务连接请求的目标业务承载，并根据目标业务承载生成承载标识，以及对用户终端增加所生成的承载标识，即对用户终端所增加的承载标识与用户终端网络可达的业务服务器有关，即可以识别出Ping的承载作为用户终端的多播承载，并采用该多播承载为用户终端增加相应的承载标识。

在一种优选的实施例中，MBMS用户队列实质上可以为索引列表，该索引列表可以用于存储用户终端的用户标识、承载标识以及业务类型之间的索引关系，以便用于后续进行包复制处理。

在一种优选的实施例中，除了在将用户终端添加到预先建立的MBMS用户队列以外，还可以对已添加到MBMS用户队列中的用户终端进行删除处理。

在用户终端的删除处理方面，可以存在如下情况：

第一种情况，删除MBMS用户队列中具有主用户标识的用户终端，即主用户终端，主用户终端可以是位于MBMS用户队列中的首位用户终端，那么在删除位于首位的主用户终端之后，可以将位于MBMS用户队列头结点的辅用户终端更新为新的主用户终端，此时可以为更新后位于MBMS用户队列首位的用户终端添加主用户标识；

第二种情况，删除MBMS用户队列中的业务承载，当在删除某个业务承载时，若所删除的业务承载具有对应的多播辅用户，那么可以删除该用户承载所维护的多播辅用户信息记录，即删除与多播辅用户承载相应的辅用户终端；

第三种情况，删除小区并在删除小区的同时可以清除小区内多播主用户信息和多播辅用户信息，在实际应用中，可以通过某个基站建立相互通信的小区，那么用户终端所添加到的MBMS用户队列实际上可以为针对小区的用户队列，若某个小区被删除，此时针对该删除小区的用户队列也将被删除，即用户队列中所添加的主用户终端和辅用户终端均会被删除。

在本申请实施例中，通过基于特征业务服务器或业务类型以及预先建立的MBMS用户队列识别出MBMS用户，以便后续将主用户终端的流量分发到辅用户终端，使得能够减小上游传输网络所带来的压力，避免出现在业务集中时所存在的时延大、视频不同步的问题。

参照图4，示出了本申请的另一种多播实现方法实施例的步骤流程图，应用于基站，基站可以与用户终端通信，具体可以包括如下步骤：

步骤401，基站获取MBMS用户队列；所述MBMS用户队列存在与所述业务类型相应业务承载所对应的主用户终端和辅用户终端；

在本申请的一种实施例中，在MBMS用户队列中已对用户终端中的主用户和辅用户进行标识，此时可以通过基站获取MBMS用户队列，以便后续确定所接收到的通信数据为主用户数据还是辅用户数据，并将主用户终端的流量复制分发到辅用户终端，以减少主干网络及传输设备的流量压力。

步骤402，接收预设链路方向发送的通信数据，并根据所述MBMS用户队列所包含的业务承载确定所述通信数据的数据类型；

在本申请实施例中，基站在接收到通信数据之后，可以根据所获取的MBMS用户队列所包含的业务承载和所接收的通信数据确定通信数据的业务类型，即确定所接收到的通信数据为主用户数据还是辅用户数据，以便后续将主用户终端的流量复制分发到辅用户终端。

需要说明的是，基站所接收到的通信数据可以为预设链路方向发送的通信数据，预设链路方向的通信数据可以包括相对基站而言下行链路的通信数据，还可以包括相对基站而言上行链路的通信数据。其中，当基站接收到核心网发送的下行链路的通信数据，并向用户终端发送下行链路的通信数据时，此下行链路的通信数据同样可以指的是相对用户终端而言下行方向链路所发送的数据，当基站接收到用户终端发送的上行链路的通信数据，并向核心网发送上行链路的通信数据时，所发送的上行链路的通信数据可以是相对用户终端而言的上行方向(或上传方向)的数据，对此，本申请实施例不加以限制。

在实际应用中，在所获取的MBMS用户队列中可以包括与用户终端具有索引关系的承载标识以及业务类型，那么此时可以通过确定所接收到通信数据的业务承载，从而根据业务承载确定承载标识的同时确定通信数据的业务类型。

在具体实现中，可以获取通信数据相应的承载标识，并判断承载标识是否位于MBMS用户队列，若位于MBMS用户队列中，则可以表示基站所接收到的业务数据承载可能是主用户终端承载上的数据，也可能为具有辅用户终端承载上的数据。

在一种情况下，若承载标识位于MBMS用户队列，且承载标识与主用户终端具有索引关系，可以表示通信数据的业务承载为多播主用户多播承载上的数据，则可以确定通信数据的数据类型为主用户数据；在另一情况下，若承载标识位于MBMS用户队列，且所述承载标识与辅用户终端具有索引关系，可以表示通信数据的业务承载为多播辅用户承载上的数据，则可以确定通信数据的数据类型为辅用户数据。

在具体实现中，预先建立的MBMS用户队列实质上为用于存储用户终端的用户标识、承载标识以及业务类型之间的索引关系的索引列表，那么MBMS用户队列具有与用户终端相应的承载标识，其中，用户终端可以包括主用户终端和辅用户终端。在判断通信数据相应的承载标识是否位于MBMS用户队列时，可以表现为判断MBMS用户队列中是否存在与通信数据相应承载标识相同的承载标识，若存在与通信数据相应承载标识相同的承载标识，则可以表示此时通信数据的相应承载标识位于MBMS用户队列中；若不存在与通信数据相应承载标识相同的承载标识，则可以表示此时通信数据的相应承载标识并不在MBMS用户队列中。

其中，通信数据的数据类型可以通过通信数据的业务承载确定，通信数据可以为承载上的业务数据，而业务类型可以通过用户终端Ping的承载进行确定，且通信数据的数据类型可以指的是主用户承载上的数据，那么数据类型也可用于表示业务类型。即在根据MBMS用户队列和通信数据确定通信数据的数据类型时，本质上是对通信数据的业务类型进行确定，以便基于特征业务服务器或业务类型识别出MBMS用户。

需要说明的是，不同的业务承载可以承载不同业务类型的数据，且不同的业务承载可以具有业务承载ID(Identity document，标识)，在所建立的MBMS用户队列中，用户终端所对应的业务承载ID均不同，即MBMS用户队列中的主用户终端与各个辅用户终端、以及多个辅用户终端之间所对应的业务承载是不同的。

步骤403，若所述通信数据的数据类型为主用户数据，将所述通信数据发送给所述主用户终端，以及将所述通信数据分发到辅用户终端。

在本申请的一种实施例中，可以根据通信数据的业务类型对通信数据的传输进行进一步处理，具体的，当所确定的数据类型为主用户数据，即所接收的通信数据为来自具有主用户标识的主用户终端承载上的数据时，可以将通信数据发送给具有主用户标识的主用户终端的同时，将通信数据复制并分发到具有辅用户标识的辅用户终端，减轻主干网络流量压力以及避免由于业务集中而导致的时延大以及视频不同步的问题。

在实际应用中，预设链路方向发送的通信数据包括相对用户终端而言下行链路的通信数据，那么所复制分发的通信数据可以为基站所接收的下行链路的通信数据，业务承载可以用于承载多个不同业务类型的通信数据，且同一业务类型的通信数据可以由不同的业务承载进行承载，此时可以获取通信数据的业务承载上的业务类型，以及从MBMS用户队列中获取具有相同业务类型的辅用户终端，然后可以将下行链路的通信数据依次复制给具有相同业务类型的辅用户终端的对应业务承载。

在一种优选的实施例中，基于基站BBU(Base band Unit，基带处理单元)范围识别MBMS主、辅用户，同一BBU范围内同一业务类型的用户越多效果越明显；同时使用本方案的基站越多效果越好；有效的降低了设备传输的压力，提高了主干网络的稳定性、可靠性、业务量；同时减少了客户业务集中时客户的使用成本。

其中，基站可以与相互通信的用户终端形成无线通信小区，MBMS用户队列实际上可以为针对小区的用户队列，则其所确定的具有相同业务类型的辅用户终端可以为在该小区里的辅用户终端，且所获取的辅用户终端可以以辅用户终端的列表形式进行获取，所获取的辅用户终端列表中可以包括单个辅用户终端，也可以包括多个辅用户终端。

在本申请的一种实施例中，步骤403可以包括如下子步骤：

子步骤S21，获取所述下行链路的通信数据的通信数据包，并按照所述辅用户终端对应的业务承载更新所述通信数据包的包头信息。

在实际应用中，按照辅用户终端的对应承载更新通信数据包的包头信息，可以表现为更新所要分发给辅用户数据的IP(Internet Protocol，互联网协议)头信息，即修改主用户数据的数据包(即通信数据包)里的目标IP地址。

具体的，当所接收到的通信数据为UDP(User Datagram Protocol，用户数据报协议)数据时，可以更新将会发送给具有辅用户标识的辅用户终端的通信数据中的UDP头信息；在另一种情况下，当所接收到的通信数据为TCP(Transmission Control Protocol，传输控制协议)数据时，可以更新将会发送给具有辅用户标识的辅用户终端的通信数据中的TCP头信息，更新UDP头信息和更新TCP头信息可以表现为重新进行IP校验和计算。

其中，通信数据包的包头信息可以包括通信地址信息，在一种情况下，处于单播模式时，若具有相同业务类型的辅用户终端的数量为一个，则可以确定辅用户终端对应的业务承载的通信地址为目标地址信息，并修改通信数据包的包头信息中所包含的通信地址信息为目标地址信息；在另一种情况下，若具有相同业务类型的辅用户终端的数量为多个，则可以获取预先设置的具有相同业务类型的辅用户终端的广播地址，并将广播地址作为目标地址信息，以及修改数据包的包头信息中所包含的通信地址信息为目标地址信息。

在实际应用中，具有相同业务类型的辅用户终端的广播地址可以通过预先建立的MBMS用户队列进行预先设置，预先建立的MBMS用户队列存储有用户终端的用户标识、承载标识以及业务类型之间的索引关系，此时可以预先创建多个广播地址，并按照MBMS用户队列中所存储的具有相同承载标识，且用户标识为辅用户标识的辅用户终端划为一个广播组，并从预先创建的多个广播地址中向此广播组分配广播地址。需要说明的是，为具有相同业务类型的辅用户终端设置广播地址的时机可以是在建立MBMS用户队列之后，也可以是在接收到所发送的通信数据的同时或之后，对此，本申请实施例不加以限制。

在一种优选的实施例中，预设链路方向发送的通信数据可以包括相对基站而言下行链路的通信数据，此时若下行链路的通信数据的数据类型为辅用户数据，即为多播辅用户多播承载上的数据，且下行链路的通信数据不是预设类型的数据，预设类型可以指的是应答类型的数据，当下行链路的通信数据为非业务应答数据时，停止向具有辅用户标识的辅用户终端传输下行链路的通信数据，此时可以将所接收到的下行链路的通信数据丢弃，即在下行链路的辅用户数据为业务应答数据时，向辅用户终端传输此辅用户数据。

在一种优选的实施例中，预设链路方向发送的通信数据还可以包括相对基站而言上行链路的通信数据，在一种情况下，若上行链路的通信数据的数据类型为主用户数据，则可以直接将上行链路的通信数据发送给核心网络；在另一种情况下，若上行链路的通信数据的数据类型为辅用户数据，且上行链路的通信数据为TCP数据，则可以将上行链路的通信数据发送给核心网络，在实际应用中可以使用TCP代理建立连接并向核心网络发送通信数据；在又一种情况下，若上行链路的通信数据的数据类型为辅用户数据，且上行链路的通信数据为UDP数据时，由于对于上行数据是UDP而言认为是不需要广播的，其中，核心网可以用于负责对数据的处理和分发，核心网后段可以指的是利用路由交换对数据处理的部分，那么此时不需要将该UDP数据发送给核心网后段，可以停止向核心网传输上行链路的通信数据，即此时可以将所接收到的上行链路的通信数据丢弃。

在本申请实施例中，基站可以根据用户终端的业务类型建立MBMS用户队列，并在接收到预设链路方向所发送的通信数据之后，可以根据MBMS用户队列和所接收的通信数据确定通信数据的数据类型，在通信数据为下行链路数据，且通信数据的数据类型为主用户数据的情况下，将通信数据发送主用户终端以及将通信数据分发给辅用户终端。通过预先建立的MBMS用户队列和根据所接收的通信数据识别出MBMS用户，并将主用户终端的流量分发到辅用户终端，使得能够减小上游传输网络所带来的压力，避免出现在业务集中时所存在的时延大、视频不同步的问题。

参照图5，示出了本申请实施例中多播实现方法的应用场景一的示意图，主要是对用户终端进行识别处理的过程，具体的：

对于小区里在QCI(QoS Class Identifier，Qos等级识别)6～9承载上识别出PingReply包的第一个用户，作为多播主用户(即具有主用户标识的主用户终端)，并识别出Ping的承载作为多播承载，例如假设Ping Reply包对应的业务类型为QCI9，那么可以将QCI9的承载作为多播承载。其中，QCI可以指的是QoS类标识符，而QCI6～9可以理解为代表不同的业务类型；多播主用户识别出之后在QCI6～9承载上识别出Ping Reply的用户作为多播辅用户(即具有辅用户标识的辅用户终端)，识别出Ping的承载作为多播辅用户的多播承载。

然后可以建立用于维护小区里多播辅用户索引UeIndex(unique index，唯一索引)和多播无线承载RB的索引列表，该索引列表可以指的是MBMS用户列表，以便于后续进行包复制处理。

参照图6，示出了本申请实施例中多播实现方法的应用场景二的示意图，主要是对多播用户业务进行处理的过程，具体的：

从核心网接收到下行GTPU(GPRS Tunnelling Protocol-U，用于在GPRS核心网内，为无线接入网与核心网之间传送用户数据，该类型的用户数据包可以以IPv4(InternetProtocol 4，互联网协议第四版)，IPv6(Internet Protocol 6，互联网协议第六版)或PPP(Point to Point Protocol，点对点协议，指的是在同等单元之间传输数据包这样的简单链路设计的链路层协议)中的任何格式传输)数据时，如果是多播主用户多播承载上的数据，则可以依次复制给小区里各多播辅用户对应的RB。其中，复制前可以先修改数据包里的目标IP地址为当前的目标地址，即重新进行IP校验和计算，然后再发给各用户进行正常数据处理发给底层。其中，当前的目标地址可以根据所需要接收的多播辅用户的数量进行确定，作为一种示例，若多播辅用户的数量为1个，此时可以将从MBMS用户队列中获取与该多播辅用户对应承载的通信地址，并将该通信地址作为当前的目标地址。需要说明的是，目前只考虑复制IPv4(Internet Protocol Version 4，互联网协议的第四版，为构成现今互联网技术的基础的协议)数据包。

而当多播辅用户多播承载上的下行数据，在理论上，如果不是Ping Reply包，则可以直接丢弃，并不递交底层，需要说明的是，也可以向底层发送Ping Reply包。

在本申请实施例中，当用户承载删除时，如果对应多播辅用户承载，则需要删除维护的多播辅用户信息记录；当小区删除时，可以清除小区内多播主用户信息和多播辅用户信息。

在本申请实施例中，基于已有架构、业务流程对流量进行了一定的优化处理，并做了功能拓展设计；从而使大并发的同一业务量处理更加具有时效性，大大降低了主干网络及传输设备的流量压力，有效缓解了同一业务量大并发时带来的时延大、主干网络及传输设备流量压力大等现象。同时对已有架构所进行的功能扩展涉及可以为后续的独立演进提供基础，即可适用于传统的基站模型，也适用于类似于小站等基站模型，亦适用于CU(Control Unit，控制面单元)-DU(DataUnit，业务面单元)模型的新型站。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

参照图7，示出了本申请的一种多播实现装置实施例的结构框图，应用于基站，基站可以与用户终端通信，具体可以包括如下模块：

用户队列建立模块701，用于根据所述用户终端的业务类型建立MBMS用户队列；所述MBMS用户队列存在与所述业务类型相应业务承载所对应的主用户终端和辅用户终端；

数据类型确定模块702，用于接收预设链路方向发送的通信数据，并根据所述MBMS用户队列所包含的业务承载确定所述通信数据的数据类型；

通信数据分发模块703，用于若所述通信数据为下行链路的通信数据，且所述通信数据的数据类型为主用户数据，将所述通信数据发送给所述主用户终端，以及将所述通信数据分发给所述辅用户终端。

在本申请的一种实施例中，所述MBMS用户队列存在业务承载的承载标识与用户终端的索引关系；数据类型确定模块702可以包括如下子模块：

在本申请的一种实施例中，通信数据分发模块703可以包括如下子模块：

辅用户终端获取子模块，用于所述通信数据为下行链路的通信数据，且所述通信数据的数据类型为主用户数据时，确定所述通信数据的业务承载上的业务类型，以及从所述MBMS用户队列中确定与所主用户数据具有相同业务类型的辅用户终端；

在本申请的一种实施例中，通信数据分发子模块可以包括如下单元：

在本申请的一种实施例中，包头信息更新单元可以包括如下子单元：

在本申请的一种实施例中，通信数据分发模块还可以包括如下子模块：

第一通信数据丢弃子模块，用于若所述下行链路的通信数据的数据类型为辅用户数据，且所述下行链路的通信数据不是预设类型的数据，则停止向所述具有辅用户标识的第二用户终端传输所述下行链路的通信数据。

在本申请的一种实施例中，所述预设链路方向发送的通信数据还包括上行链路的通信数据；通信数据分发模块还可以包括如下子模块：

在本申请的一种实施例中，用户队列建立模块701可以包括如下子模块：

在本申请的一种实施例中，用户终端添加子模块可以包括如下单元：

在本申请的一种实施例中，用户终端添加单元可以包括如下子单元：

辅用户标识增加子单元，用于将在首个业务应答数据之后识别到的首个业务应答数据相应的用户终端作为辅用户终端，同时对与所述辅用户终端增加辅用户标识。

在本申请的一种实施例中，所述业务连接请求包含所请求数据的业务类型，用户终端添加单元可以包括如下子单元：

在本申请的一种实施例中，所述主用户终端为所述MBMS用户队列中的首位用户终端，所述装置还可以包括如下模块：

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本申请实施例还提供了一种装置，包括存储器，收发机，处理器：

存储器，用于存储计算机程序；收发机，用于在所述处理器的控制下收发数据；处理器，用于读取所述存储器中的计算机程序并执行以下操作：

根据所述用户终端的业务类型建立MBMS用户队列；所述MBMS用户队列存在与所述业务类型相应业务承载所对应的主用户终端和辅用户终端；

若所述通信数据为下行链路的通信数据，且所述通信数据的数据类型为主用户数据，将所述通信数据发送给所述主用户终端，以及将所述通信数据分发给辅用户终端。

在本申请的一种实施例中，针对基站根据用户终端的业务类型建立多媒体广播多播MBMS用户队列的过程，基站可以与业务服务器通信，首先基站可以向业务服务器传输用户终端发送的业务连接请求，其中，业务连接请求可以是由用户终端根据所需请求数据的业务类型生成；然后可以判断是否接收到业务服务器返回的业务应答数据，即判断是否接收到由所述业务服务器响应业务连接请求生成并返回的业务应答数据；在一种情况下，若接收到业务服务器返回的业务应答数据，则可以将用户终端添加到预先建立的MBMS用户队列。

在将用户终端添加到预先建立的MBMS用户队列时，需要对用户终端增加用户标识及承载标识，并将增加标识后的用户终端添加至预先建立的MBMS用户队列。

具体的，在对用户终端增加用户标识的过程中，可以识别与首个业务应答数据相应的用户终端为主用户终端，同时对主用户终端增加主用户标识；可以将在首个业务应答数据之后识别到的业务应答数据相应的用户终端作为辅用户终端，同时对与辅用户终端增加辅用户标识。

对用户终端增加承载标识，首先可以确定所请求数据的业务类型的目标业务承载，再根据目标业务承载生成承载标识，对用户终端增加所生成的承载标识。

在一种优选的实施例中，不仅可以建立MBMS用户队列，还可以对已建立的MBMS用户队列进行删除操作。具体可以表现为删除MBMS用户队列中的首位用户终端，即主用户终端；在删除首位的主用户终端之后，可以获取当前位于MBMS用户队列中头结点的辅用户终端，并将当前位于所述MBMS用户队列中头结点的辅用户终端作为新的主用户终端，此时可以对更新后的主用户终端增加主用户标识。

在本申请的一种实施例中，针对基站根据所建立的多媒体广播多播MBMS用户队列进行流量分发的过程，具体的：

MBMS用户队列可以存在业务承载的承载标识与用户终端的索引关系，此时可以确定所述通信数据的业务承载以及所述通信数据的业务承载相应的承载标识；若MBMS用户队列中存在通信数据的业务承载相应的承载标识，且承载标识与主用户终端具有索引关系，则确定通信数据的数据类型为主用户数据；若MBMS用户队列中存在所述通信数据的业务承载相应的承载标识，且承载标识与所述辅用户标识具有索引关系，则确定通信数据的数据类型为辅用户数据。

其中，预设链路方向发送的通信数据可以包括下行链路的通信数据，若数据类型为主用户数据，则可以确定通信数据的业务承载上的业务类型，以及从MBMS用户队列中确定与主用户数据具有相同业务类型的辅用户终端；将下行链路的通信数据，即所接收到的主用户数据依次复制给具有相同业务类型的辅用户终端对应的业务承载。

在分发的过程中，可以获取下行链路的通信数据的通信数据包，并按照辅用户终端对应的业务承载更新通信数据包的包头信息。

其中，业务承载可以用于承载多个不同业务类型的通信数据，且通信数据包的包头信息包括通信地址信息，此时若具有相同业务类型的辅用户终端的数量为一个，则确定辅用户终端对应的业务承载的通信地址为目标地址信息，并修改通信数据包的包头信息中所包含的通信地址信息为目标地址信息；或，若具有相同业务类型的辅用户终端的数量为多个，获取预先设置的具有相同业务类型的辅用户终端的广播地址，并将广播地址作为目标地址信息，以及修改数据包的包头信息中所包含的通信地址信息为目标地址信息。

在本申请一种可选的实施例中，若下行链路的通信数据的数据类型为辅用户数据，且下行链路的通信数据不是预设类型的数据，预设类型的数据可以为应答类型的数据，即当所接收到的下行链路的辅用户数据为非应答数据时，可以停止向辅用户终端传输该下行链路的通信数据。

在本申请实施例中，预设链路方向发送的通信数据还可以包括上行链路的通信数据，其中，在对上行链路的通信数据进行处理的过程中，若上行链路的通信数据的数据类型为主用户数据，则将上行链路的通信数据发送给核心网络；或，若上行链路的通信数据的数据类型为辅用户数据，且上行链路的通信数据为传输控制协议TCP数据，则将上行链路的通信数据发送给核心网络；或，若上行链路的通信数据的数据类型为辅用户数据，且上行链路的通信数据为用户数据报协议UDP数据，则停止向核心网传输所述上行链路的通信数据。

收发机800，用于在处理器810的控制下接收和发送数据。

其中，在图8中，总线架构可以包括任意数量的互联的总线和桥，具体由处理器810代表的一个或多个处理器和存储器820代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口提供接口。收发机800可以是多个元件，即包括发送机和接收机，提供用于在传输介质上与各种其他装置通信的单元，这些传输介质包括无线信道、有线信道、光缆等传输介质。处理器810负责管理总线架构和通常的处理，存储器820可以存储处理器810在执行操作时所使用的数据。

处理器810可以是中央处埋器(CPU)、专用集成电路(Application SpecificIntegrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable GateArray，FPGA)或复杂可编程逻辑器件(Complex Programmable Logic Device，CPLD)，处理器也可以采用多核架构。

在此需要说明的是，本申请实施例提供的上述装置，能够实现上述方法实施例所实现的所有方法步骤，且能够达到相同的技术效果，在此不再对本实施例中与方法实施例相同的部分及有益效果进行具体赘述。

本申请实施例还提供了一种处理器可读存储介质，处理器可读存储介质上存储计算机程序，计算机程序被处理器执行时实现上述多播实现方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机可执行指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机可执行指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些处理器可执行指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的处理器可读存储器中，使得存储在该处理器可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些处理器可执行指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种多播实现方法和一种多播实现装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims

1.一种多播实现方法，其特征在于，所述方法包括：

基站根据用户终端的业务类型建立多媒体广播多播MBMS用户队列；所述MBMS用户队列存在与业务类型相应业务承载所对应的主用户终端和辅用户终端；

若所述通信数据为下行链路的通信数据，且所述通信数据的数据类型为主用户数据，将所述通信数据发送给所述主用户终端，以及将所述通信数据分发到所述辅用户终端；所述通信数据包括主用户数据，在向所述辅用户终端进行分发时将所述主用户数据依次复制给与主用户数据具有相同业务类型的辅用户终端对应的业务承载，其中，所述主用户终端为首个业务应答数据相应的用户终端，所述辅用户终端为在首个业务应答数据之后识别到的业务应答数据相应的用户终端。

2.根据权利要求1所述的方法，其特征在于，所述MBMS用户队列存在业务承载的承载标识与用户终端的索引关系；根据所述MBMS用户队列所包含的业务承载确定所述通信数据的数据类型，包括：

若所述MBMS用户队列中存在所述通信数据的业务承载相应的承载标识，且所述承载标识与所述辅用户终端具有索引关系，则确定所述通信数据的数据类型为辅用户数据。

3.根据权利要求1所述的方法，其特征在于，所述将所述主用户数据依次复制给与主用户数据具有相同业务类型的辅用户终端对应的业务承载，包括：

获取所述下行链路的通信数据的通信数据包；

4.根据权利要求3所述的方法，其特征在于，所述按照所述辅用户终端对应的业务承载更新所述通信数据包的包头信息，包括：

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

6.根据权利要求1所述的方法，其特征在于，所述预设链路方向发送的通信数据还包括上行链路的通信数据；所述方法还包括：

7.根据权利要求1所述的方法，其特征在于，所述基站根据用户终端的业务类型建立多媒体广播多播MBMS用户队列，包括：

8.根据权利要求7所述的方法，其特征在于，所述将所述用户终端添加到MBMS用户队列，包括：

9.根据权利要求8所述的方法，其特征在于，对所述用户终端增加用户标识，包括：

对所述主用户终端增加主用户标识；

对所述辅用户终端增加辅用户标识。

10.根据权利要求8所述的方法，其特征在于，所述业务连接请求包含所请求数据的业务类型，对所述用户终端增加承载标识，包括：

确定所述所请求数据的业务类型的目标业务承载；

11.根据权利要求1所述的方法，其特征在于，所述主用户终端为所述MBMS用户队列中的首位用户终端，所述方法还包括：

删除位于所述MBMS用户队列中的首位用户终端；

在删除所述首位用户终端之后，获取当前位于所述MBMS用户队列中头节点的辅用户终端，并将所述当前位于所述MBMS用户队列中头节点的辅用户终端作为新的主用户终端。

12.一种装置，其特征在于，包括存储器，收发机，处理器：

存储器，用于存储计算机程序；收发机，用于在所述处理器的控制下收发数据；处理器，用于读取所述存储器中的计算机程序并执行如权利要求1至11任一项所述的多播实现方法。

13.一种多播实现装置，其特征在于，所述装置包括：

用户队列建立模块，用于根据用户终端的业务类型建立多媒体广播多播MBMS用户队列；所述MBMS用户队列存在与所述业务类型相应业务承载所对应的主用户终端和辅用户终端；

通信数据分发模块，用于若所述通信数据为下行链路的通信数据，且所述通信数据的数据类型为主用户数据，将所述通信数据发送给所述主用户终端，以及将所述通信数据分发到所述辅用户终端；所述通信数据包括主用户数据，在向所述辅用户终端进行分发时将所述主用户数据依次复制给与主用户数据具有相同业务类型的辅用户终端对应的业务承载，其中，所述主用户终端为首个业务应答数据相应的用户终端，所述辅用户终端为在首个业务应答数据之后识别到的业务应答数据相应的用户终端。

14.一种处理器可读存储介质，其特征在于，所述处理器可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至11任一项所述的多播实现方法的步骤。