CN114390440B - 业务处理方法、装置及相关设备 - Google Patents

Abstract

本申请公开了一种业务处理方法、装置及相关设备，属于通信技术领域。业务处理方法包括：向网络侧设备发送第一请求，所述第一请求用于请求目标信息，所述目标信息与多播业务相关，所述目标信息包括控制信息和数据信息中的至少一项；接收所述目标信息。本申请可以降低空口开销。

Description

业务处理方法、装置及相关设备

技术领域

本申请属于通信技术领域，具体涉及一种业务处理方法、装置及相关设备。

背景技术

在长期演进(Long Term Evolution，LTE)的广播多播传输中，可以支持多媒体广播多播业务单频网络(Multimedia Broadcast multicast service Single FrequencyNetwork，MBSFN)方式多媒体广播多播业务(Multimedia Broadcast and MulticastService，MBMS)发送和单小区点对多点(Single cell Point to Multipoint，sc-ptm)方式多播业务发送。MBSFN方式和sc-ptm方式均通过广播或者多播方式发送多播业务的控制信息和数据信息。

在现有技术中，当决定发送某个多播业务之后，会持续通过广播或者多播方式发送该多播业务的控制信息和数据信息，导致空口开销较高。

发明内容

本申请实施例提供一种业务处理方法、装置及相关设备，能够解决现有技术中因多播业务的控制信息和数据信息始终保持发送状态，导致空口开销较高的问题。

第一方面，提供了一种业务处理方法，由终端执行，所述方法包括：

向网络侧设备发送第一请求，所述第一请求用于请求目标信息，所述目标信息与多播业务相关，所述目标信息包括控制信息和数据信息中的至少一项；

接收所述目标信息。

第二方面，提供了一种业务处理方法，由网络侧设备执行，所述方法包括：

接收终端发送的第一请求，所述第一请求用于请求目标信息，所述目标信息与多播业务相关，所述目标信息包括控制信息和数据信息中的至少一项；

向所述终端发送所述目标信息。

第三方面，提供了一种业务处理装置，所述业务处理装置包括：

第一发送模块，用于向网络侧设备发送第一请求，所述第一请求用于请求目标信息，所述目标信息与多播业务相关，所述目标信息包括控制信息和数据信息中的至少一项；

第一接收模块，用于接收所述目标信息。

第四方面，提供了一种业务处理装置，所述业务处理装置包括：

第五接收模块，用于接收终端发送的第一请求，所述第一请求用于请求目标信息，所述目标信息与多播业务相关，所述目标信息包括控制信息和数据信息中的至少一项；

第二发送模块，用于向所述终端发送所述目标信息。

第五方面，提供了一种通信设备，该通信设备包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第一方面所述的方法的步骤，或者实现如第二方面所述的方法的步骤。

第六方面，提供了一种可读存储介质，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如第一方面所述的方法的步骤，或者实现如第二方面所述的方法的步骤。

第七方面，提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行网络侧设备程序或指令，实现如第一方面所述的方法，或实现如第二方面所述的方法。

在本申请实施例中，网络侧设备在接收到终端发送的用于请求目标信息的第一请求之后，才会向所述终端发送所述目标信息，其中，所述目标信息与多播业务相关，所述目标信息包括控制信息和数据信息中的至少一项。这样，可以避免在没有终端对所述目标信息相关的多播业务感兴趣时，网络侧设备仍不断发送所述目标信息的情况，从而可以降低空口信令开销，节省资源。

附图说明

图1是本申请实施例可应用的一种无线通信系统的框图；

图2是本申请实施例提供的业务处理方法的流程图之一；

图3是本申请实施例提供的业务处理方法的流程图之二；

图4是本申请实施例提供的业务处理装置的结构图之一；

图5是本申请实施例提供的业务处理装置的结构图之二；

图6是本申请实施例提供的通信设备的结构图；

图7是本申请实施例提供的终端的结构图；

图8是本申请实施例提供的网络侧设备的结构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”所区别的对象通常为一类，并不限定对象的个数，例如第一对象可以是一个，也可以是多个。此外，说明书以及权利要求中“和/或”表示所连接对象的至少其中之一，字符“/”一般表示前后关联对象是一种“或”的关系。

值得指出的是，本申请实施例所描述的技术不限于长期演进型(Long TermEvolution，LTE)/LTE的演进(LTE-Advanced，LTE-A)系统，还可用于其他无线通信系统，诸如码分多址(Code Division Multiple Access，CDMA)、时分多址(Time DivisionMultiple Access，TDMA)、频分多址(Frequency Division Multiple Access，FDMA)、正交频分多址(Orthogonal Frequency Division Multiple Access，OFDMA)、单载波频分多址(Single-carrier Frequency-Division Multiple Access，SC-FDMA)和其他系统。本申请实施例中的术语“系统”和“网络”常被可互换地使用，所描述的技术既可用于以上提及的系统和无线电技术，也可用于其他系统和无线电技术。然而，以下描述出于示例目的描述了新空口(New Radio，NR)系统，并且在以下大部分描述中使用NR术语，这些技术也可应用于NR系统应用以外的应用，如第6代(6^th Generation，6G)通信系统。

图1示出本申请实施例可应用的一种无线通信系统的框图。无线通信系统包括终端11和网络侧设备12。其中，终端11也可以称作终端设备或者用户终端(User Equipment，UE)，终端11可以是手机、平板电脑(Tablet Personal Computer)、膝上型电脑(LaptopComputer)或称为笔记本电脑、个人数字助理(Personal Digital Assistant，PDA)、掌上电脑、上网本、超级移动个人计算机(ultra-mobile personal computer，UMPC)、移动上网装置(Mobile Internet Device，MID)、可穿戴式设备(Wearable Device)或车载设备(VUE)、行人终端(PUE)等终端侧设备，可穿戴式设备包括：手环、耳机、眼镜等。需要说明的是，在本申请实施例并不限定终端11的具体类型。网络侧设备12可以是基站或核心网，其中，基站可被称为节点B、演进节点B、接入点、基收发机站(Base Transceiver Station，BTS)、无线电基站、无线电收发机、基本服务集合(Basic Service Set，BSS)、扩展服务集合(ExtendedService Set，ESS)、B节点、演进型B节点(eNB)、家用B节点、家用演进型B节点、WLAN接入点、WiFi节点、发送接收点(Transmitting Receiving Point，TRP)或所述领域中其他某个合适的术语，只要达到相同的技术效果，所述基站不限于特定技术词汇。

为了方便理解，以下对本申请实施例涉及的一些内容进行说明：

在广播多播传输中，可以支持多媒体广播多播业务单频网络(MultimediaBroadcast multicast service Single Frequency Network，MBSFN)方式多媒体广播多播业务(Multimedia Broadcast and Multicast Service，MBMS)发送和单小区点对多点(Single cell Point to Multipoint，sc-ptm)方式多播业务发送。

对于MBSFN方式，处于同一个MBSFN区域的小区会同步的发送相同的广播业务，便于UE进行接收。MBMS业务的控制信息(如控制信道参数、业务信道参数、调度信息等)和数据信息都是广播方式发送，使得空闲(idle)态UE、非激活(inactive)态和连接态(connected)UE都可接收MBMS业务。

对于sc-ptm方式，其与MBSFN方式最大的不同是只在单小区调度发送，由组无线网络临时标识(group Radio Network Temporary Identifier，g-RNTI)来进行业务调度。在广播消息里广播控制信道参数、业务的标识、周期信息等，调度信息由g-RNTI加扰的物理下行控制信道(Physical Downlink Control Channel，PDCCH)来进行通知，数据部分是组播方式发送，相当于感兴趣的UE监听g-RNTI获得数据调度进而进行接收。

在本申请实施例中，多播业务，也可以称为MBMS或广播多播业务(MulticastBroadcast Service，MBS)。也就是说，多播业务、MBMS和MBS在本申请实施例中可以相互替换。

多播业务的控制信息可以通过多播控制信道(Multicast Control Channel，MCCH)发送；多播业务的数据信息可以通过多播业务信道(Multicast Traffic Channel，MTCH)发送。因此，在某些实施方式中，多播业务的控制信息也可以称为MCCH；多播业务的数据信息也可以称为MTCH。

多播业务信息请求也可以称为：与多播业务相关的请求；多播业务的控制信息请求也可以称为：与多播业务的控制信息相关的请求；多播业务的数据信息请求也可以称为：与多播业务的数据信息相关的请求。

参见图2，图2是本申请实施例提供的业务处理方法的流程图之一。本申请实施例的业务处理方法可以由终端执行。

如图2所示，业务处理方法可以包括以下步骤：

步骤201、向网络侧设备发送第一请求，所述第一请求用于请求目标信息，所述目标信息与多播业务相关，所述目标信息包括控制信息和数据信息中的至少一项。

在本申请实施例中，需要注意的是，“所述目标信息与多播业务相关”中的“多播业务”可以理解为业务类型，也可以理解为多播业务下的特定多播业务，具体可根据实际情况决定，本申请实施例对此不做限定。

可选的，在终端不知道所述网络侧设备具体支持的多播业务，所述第一请求用于指示所述终端对多播业务感兴趣，即所述终端期望接收多播业务的情况下，该多播业务可以理解为业务类型。在此情况下，网络侧设备在接收到所述第一请求之后，可向终端发送所述网络侧设备支持的多播业务中处于按需请求(on-demand request)状态的全部多播业务的目标信息。

在终端知道所述网络侧设备具体支持的多播业务，所述第一请求携带所述终端感兴趣的特定多播业务的标识，或，所述终端感兴趣的特定多播业务的目标信息的标识的情况下，该多播业务可以理解为多播业务下的特定业务。在此情况下，网络侧设备在接收到所述第一请求之后，可向终端发送特定多播业务的目标信息，不发送其他多播业务的目标信息。这样，可以避免终端接收到不感兴趣的多播业务的目标信息，降低终端功耗，以及减少终端干扰。

为方便理解，示例说明如下：

假设所述网络侧设备支持3种多播业务，分别为：多播业务1、多播业务2和多播业务3。

在该多播业务理解为业务类型的情况下，网络侧设备在接收到所述第一请求之后，可以向终端发送所述网络侧设备支持的全部多播业务的目标信息，即多播业务1、多播业务2和多播业务3的目标信息。

在该多播业务理解为多播业务下的特定业务的情况下，假设所述第一请求仅包括多播业务1的标识，网络侧设备在接收到所述第一请求之后，可仅向终端发送所述第一请求所请求的多播业务的目标信息，即多播业务1的目标信息。

需要说明的是，在所述目标信息包括控制信息和数据信息的情况下，所述第一请求可以包括第一子请求和第二子请求，所述第一子请求用于请求与多播业务相关的控制信息，所述第二子请求用于请求与多播业务相关的数据信息，其中，多播业务的理解可参考前述描述，此处不再赘述。在实际应用中，所述第一子请求所请求的控制信息关联的多播业务，与所述第二子请求所请求的数据信息关联的多播业务可以相同，也可以不同，具体可根据实际情况决定，本申请实施例对此不做限定。

步骤202、接收所述目标信息。

在本申请实施例中，网络侧设备在接收到某终端发送的所述第一请求之后，可以通过广播或组播方式开始向该终端发送所述目标信息。可见，在本申请实施例中，终端发送的所述第一请求可视为：网络侧设备向该终端发送所述目标信息的触发条件。

具体实现时，网络侧设备在接收到所述第一请求之后，在一种实现方式中，网络侧设备可以持续通过广播或组播方式发送所述目标信息；在另一种实现方式中，网络侧设备在开始通过广播或组播方式发送所述目标信息之后，在一定条件满足的情况下，可以停止继续通过广播或组播方式发送所述目标信息，如：通过广播或组播方式发送所述目标信息的次数达到预设次数，通过广播或组播方式发送所述目标信息的时长达到预设时长等。

本申请实施例的业务处理方法，网络侧设备在接收到终端发送的用于请求目标信息的第一请求之后，才会向所述终端发送所述目标信息，其中，所述目标信息与多播业务相关，所述目标信息包括控制信息和数据信息中的至少一项。这样，可以避免在没有终端对所述目标信息相关的多播业务感兴趣时，网络侧设备仍不断发送所述目标信息的情况，从而可以降低空口信令开销，节省资源。

在本申请实施例中，引入多播业务信息请求功能。若某网络侧设备支持多播业务信息请求功能，对于处于按需请求状态的多播业务，该网络侧设备可以响应于接收到的多播业务信息请求(MBS info request)，如所述第一请求，通过广播或组播方式发送多播业务信息；若某设备不支持多播业务信息请求功能，该设备可以不响应接收到的多播业务信息请求。

在一些实施方式中，终端可以在不知道网络侧设备是否支持多播业务信息请求功能的情况下，向网络侧设备盲发所述第一请求。

在另一些实施方式中，终端在明确知晓某网络侧设备支持多播业务信息请求功能，才向该网络侧设备发送所述第一请求，以提高请求的成功率。可选的，所述向网络侧设备发送第一请求之前，所述方法还包括：

接收所述网络侧设备发送的第一信息，所述第一信息用于指示所述网络侧设备是否支持多播业务信息请求功能；

所述向网络侧设备发送第一请求，包括：

在所述第一信息指示所述网络侧设备支持所述多播业务信息请求功能的情况下，向网络侧设备发送第一请求。

在本可选实施方式中，网络侧设备可以通过发送所述第一信息告知终端自己是否支持多播业务信息请求功能。具体实现时，所述第一信息可以通过显式指示或隐式指示的方式指示所述网络侧设备是否支持多播业务信息请求功能。

一、对于显式指示的方式。

所述第一信息可以设置有第一域，所述第一域用于显式指示所述网络侧设备是否支持多播业务信息请求功能，具体可以但不仅限于包括以下实现方式：

第一实现方式中，可以通过所述第一域的比特取值，来指示所述网络侧设备是否支持多播业务信息请求功能，如：若所述第一域的比特取值为第一值，表示所述网络侧设备支持多播业务信息请求功能；若所述第一域的比特取值为第二值，表示所述网络侧设备不支持多播业务信息请求功能。

第二实现方式中，可以通过所述第一信息是否包括所述第一域，来指示所述网络侧设备是否支持多播业务信息请求功能，如：若所述第一信息包括所述第一域，表示所述网络侧设备支持多播业务信息请求功能；若所述第一信息未包括所述第一域，表示所述网络侧设备不支持多播业务信息请求功能。

所述第一信息可以为系统消息或专用信令，但不仅限于此。

可选的，所述网络侧设备是否支持多播业务信息请求功能，包括以下至少一项：

所述网络侧设备是否支持多播业务信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务信息请求；

所述网络侧设备是否支持连接态终端的多播业务信息请求；

所述网络侧设备是否支持多播业务的控制信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务的控制信息请求；

所述网络侧设备是否支持连接态终端的多播业务的控制信息请求；

所述网络侧设备是否支持多播业务的数据信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务的数据信息请求；

所述网络侧设备是否支持连接态终端的多播业务的数据信息请求。

具体实现时，对于多播业务信息请求，在第一实现方式中，可以在所述网络侧设备同时支持多播业务的控制信息请求和多播业务的控制信息请求的情况下，才视所述网络侧设备支持多播业务信息请求；在第二实现方式中，可以在所述网络侧设备仅支持多播业务的控制信息请求和多播业务的控制信息请求中的一项的情况下，即视所述网络侧设备支持多播业务信息请求，具体可根据实际情况决定，本申请实施例对此不做限定。

若所述第一信息指示所述网络侧设备仅支持空闲态或非激活态终端的与多播业务相关的请求，所述网络侧设备可以不响应连接态终端发送的与多播业务相关的请求。类似地，若所述第一信息指示所述网络侧设备仅支持的连接态终端与多播业务相关的请求，所述网络侧设备可以不响应空闲态或非激活态终端发送的与多播业务相关的请求。

若所述第一信息指示所述网络侧设备仅支持与多播业务的控制信息相关的请求，所述网络侧设备可以不响应与多播业务的数据相关的请求。类似地，若所述第一信息指示所述网络侧设备仅支持与多播业务的数据信息相关的请求，所述网络侧设备可以不响应多播业务的控制相关的请求。

二、对于隐式指示的方式。

可选的，所述第一信息满足以下任一项：

所述第一信息为与多播业务相关的信息；

所述第一信息用于指示多播业务信息请求的参数信息；

所述第一信息用于指示多播业务的目标信息处于按需请求状态。

在本可选实施方式中，若接收到的所述第一信息满足以上任一项，即可视所述网络侧设备是否支持多播业务信息请求功能。

在实施时，所述第一信息可以通过SIB消息、广播消息或专用信令承载，但不仅限于此。在某些实施方式中，可选的，所述第一信息的承载方式可以用于确定所述网络侧设备支持的多播业务信息请求类型。

如：若所述第一信息通过SIB消息或广播消息承载，则可以视所述网络侧设备支持空闲态、非激活态或连接态终端的多播业务信息请求；或，可以视所述网络侧设备支持空闲态或非激活态终端的多播业务信息请求；若所述第一信息通过专用信令承载，则可以视所述网络侧设备支持连接态终端的多播业务信息请求，进一步地，所述网络侧设备还可以支持目标空闲态或非激活态终端的多播业务信息请求，所述目标空闲态或非激活态终端满足：之前与所述网络侧设备建立过连接，且仍处于所述网络侧设备的覆盖范围内。

在本申请实施例中，可选的，所述方法还包括：

接收网络侧设备发送的第二信息，所述第二信息用于指示多播业务信息请求的参数信息；

所述向网络侧设备发送第一请求，包括：

根据所述第二信息，向网络侧设备发送第一请求。

在本可选实施方式中，终端根据网络侧设备指示的多播业务信息请求的参数信息，去请求多播业务，从而可以提高请求的成功率。可以理解的是，终端在请求多播业务的某信息之前，会先获取到该信息请求的参数信息。

具体实现时，所述第二信息可以通过SIB消息、广播消息或专用信令承载。

空闲态或非激活态终端发送所述第一请求使用的参数信息，可以通过SIB消息或广播消息接收所述第二信息获取得到，也可以为其之前处于连接态时通过专用信令接收所述第二信息获取得到；连接态终端发送所述第一请求使用的参数信息，可以通过专用信令接收所述第二信息获取得到。

可选的，所述参数信息包括以下至少一项：多播业务信息请求的发送方式；多播业务信息请求的发送资源；多播业务信息请求的最大发送次数；多播业务信息请求的发送间隔；多播业务信息请求对应的定时器的运行时长；多播业务信息请求的发送功率爬升步长。

具体说明如下：

对于所述多播业务信息请求的发送方式，可选的，其可包括以下至少一项：

通过四步(4-step)随机接入过程中的消息(Message，Msg)1发送多播业务信息请求(即4-step随机接入Msg1-based方式)；

通过四步随机接入过程中的消息3发送多播业务信息请求(即4-step随机接入Msg3-based方式)；

通过两步(2-step)随机接入过程中的消息A发送多播业务信息请求(即2-step随机接入MsgA-based方式)；

通过专用信令发送多播业务信息请求；

通过专用资源发送多播业务信息请求。

可以理解的是，在所述第一信息指示的多播业务信息请求的发送方式包括两种或两种以上的情况下，终端具体采用的发送方式可由网络侧设备配置或终端自主决定等，具体可根据实际情况决定，本申请实施例对此不做限定。

对于所述第二信息指示的多播业务信息请求的发送资源，其可以为专用前导码(Preamble)、随机接入过程中的专用时频资源、专用物理上行控制信道(Physical UplinkControl Channel，PUCCH)等，具体可根据实际情况决定，本申请实施例对此不做限定。

可选的，所述第二信息为第一对象和第二对象分别指示不同的发送资源；或，所述第二信息为第一对象和第二对象指示相同的发送资源；

其中，所述第一对象为空闲态或非激活态终端的多播业务信息请求，所述第二对象为连接态终端的多播业务信息请求；或，所述第一对象为多播业务的控制信息请求，所述第二对象为多播业务的数据信息请求。

在所述第二信息为第一对象和第二对象分别指示不同的发送资源的情况下，所述第一对象和所述第二对象发送多播业务信息请求时使用的资源是相互独立的；在所述第二信息为第一对象和第二对象指示相同的发送资源的情况下，所述第一对象和所述第二对象发送多播业务信息请求时使用的资源是相同的，即所述第一对象和所述第二对象共用同一资源用于发送多播业务信息请求。

在本申请实施例中，可选的，所述向网络侧设备发送第一请求，包括：

在确定所述网络侧设备的所述目标信息处于按需请求(on-demand request)状态的情况下，向网络侧设备发送第一请求。

这样，可以减少多播业务信息请求的无效发送，从而可以节省终端耗电，降低空口开销。

可选的，在第一条件满足的情况下，确定所述网络侧设备的所述目标信息处于按需请求状态；

其中，所述第一条件满足可以但不仅限于包括以下任一项：

在第一调度位置未检测到所述目标信息，所述第一调度位置为所述网络侧设备的所述目标信息的调度位置；

接收到所述网络侧设备发送的第三信息，所述第三信息指示所述网络侧设备的所述目标信息处于按需请求状态。

在本可选实施方式中，可选的，所述向网络侧设备发送第一请求，包括以下任一项：

a)通过四步随机接入过程中的消息1向网络侧设备发送第一前导码，所述第一前导码与所述第一请求对应；

b)通过四步随机接入过程中的消息3向网络侧设备发送第一无线资源控制RRC信令，所述第一RRC信令携带所述第一请求；

c)通过两步随机接入过程中的消息A向网络侧设备发送第二RRC信令，所述第二RRC信令携带所述第一请求；

d)向网络侧设备发送第三RRC信令，所述第三RRC信令携带所述第一请求。

在a)中，所述第一前导码与所述第一请求对应可以理解为：所述第一前导码与所述第一请求所请求的目标信息关联的多播业务对应。前导码与多播业务的对应关系可以由协议预定或由网络侧设备配置，具体可根据实际情况决定，本申请实施例对此不做限定。

在b)、c)、d)中，用于携带所述第一请求的信令，如所述第一信令、所述第二信令或所述第三信令，可以通过拓展现有RRC信令来携带所述第一请求，也可以为新设置的专用于携带所述第一请求的RRC信令，具体可根据实际情况决定，本申请实施例对此不做限定。

在b)中，空闲态或非激活态终端可以在Msg 3中进一步携带自己的身份信息。这样，若网络侧设备不希望广播发送所述目标信息，可以选择对终端执行目标过程使其进入连接态，通过目标发送方式发送所述目标信息。

对于空闲态终端，身份信息可以为全球唯一标识符或随机数，目标过程可以为RRC建立(Setup)过程；对于非激活态终端，身份信息可以为RNTI，目标过程可以为RRC恢复(Resume)过程，但不仅限于此。对于控制信息，在终端进入连接态后，目标发送方式可以为专用信令方式；对于数据信息，在终端进入连接态后，目标发送方式可以为专用调度方式，如点对点(Point to Point，PTP)方式，但不仅限于此。

在本申请实施例中，可选的，所述接收所述目标信息，包括：

在第一时刻接收所述目标信息；

其中，所述第一时刻满足以下任一项：

所述第一时刻为：所述终端发送所述第一请求后的第一个所述目标信息的发送时刻；

所述第一时刻为：第一周期中所述目标信息的发送时刻；

其中，在所述目标信息为控制信息的情况下，所述第一周期为所述终端发送所述第一请求后的第一个所述目标信息的修改周期；在所述目标信息为数据信息的情况下，所述第一周期为所述终端发送所述第一请求后的第一个所述目标信息的调度周期。

需要说明的是，在终端接收所述目标信息的次数大于1的情况下，所述第一时刻可视为终端在发送所述第一请求之后，第一次接收所述目标信息的时刻。

在本申请实施例中，可选的，在所述终端处于空闲态或非激活态的情况下，所述方法还包括：

执行第一操作，所述第一操作用于控制所述终端进入连接态；

接收所述目标信息。

可见，在本申请实施例中，对于空闲态或非激活态终端，在所述网络侧设备暂未通过广播或多播方式发送所述目标信息时，一种方式中，终端可以保持空闲态或非激活态，请求所述网络侧设备发送所述目标信息；另一种方式中，终端可以进入连接态，接收所述网络侧设备通过目标发送方式发送的所述目标信息，其中，所述目标方式可参考前述描述，此处不再赘述。

具体实现时，终端可以主动执行所述第一操作，也可以基于所述网络侧设备的指示执行所述第一操作，具体可根据实际情况决定，本申请实施例对此不做限定。

对于终端基于所述网络侧设备的指示执行所述第一操作的实施方式，可选的，所述执行第一操作之前，所述方法还包括：

接收所述网络侧设备发送的第四信息，所述第四信息用于指示以下任一项：

所述终端执行所述第一操作；

所述网络侧设备禁止连接态终端发送多播业务信息请求；

所述网络侧设备禁止所有终端发送多播业务信息请求。

在本申请实施例中，可选的，所述向网络侧设备发送第一请求之后，所述接收所述目标信息之前，所述方法还包括：

确定所述网络侧设备是否成功接收到所述第一请求；

所述接收所述目标信息，包括：

在确定所述网络侧设备成功接收到所述第一请求的情况下，接收所述目标信息。

具体实现时，终端确定所述网络侧设备是否成功接收到所述第一请求的方式，与终端向所述网络侧设备发送所述第一请求的方式相关。可选的，所述确定所述网络侧设备是否成功接收到所述第一请求，包括以下至少一项：

在所述终端通过四步随机接入过程中的消息1发送所述第一请求的情况下，确定是否接收到第一前导码的标识，所述第一前导码与所述第一请求对应；

在所述终端通过四步随机接入过程中的消息3发送所述第一请求的情况下，确定是否成功接收到消息4；

在所述终端通过两步随机接入过程中的消息A发送所述第一请求的情况下，确定是否成功接收到消息B；

在所述终端通过专用信令发送所述第一请求的情况下，确定是否接收到所述网络侧设备针对所述第一请求发送的确认信息。

可以理解的是，在以下任一情况下，可以确定所述网络侧设备成功接收到所述第一请求：接收到所述第一前导码的标识；成功接收到消息4；成功接收到消息B；接收到所述网络侧设备针对所述第一请求发送的确认信息。

在以下情况下，在以下任一情况下，可确定所述网络侧设备未成功接收到所述第一请求：未接收到所述第一前导码的标识；未成功接收到消息4；未成功接收到消息B；未接收到所述网络侧设备针对所述第一请求发送的确认信息。

在确定所述网络侧设备成功接收到所述第一请求的情况下，终端可以接收所述目标信息；在确定所述网络侧设备未成功接收到所述第一请求的情况下，可选的，可以执行第二操作；其中，所述第二操作可以但不仅限于包括以下任一项：

重新发送所述第一请求；

在所述第一请求的发送次数未达到最大发送次数的情况下，重新发送所述第一请求；

在所述第一请求的发送次数达到最大发送次数的情况下，执行重建或重选操作。

在实施时，在未配置有多播业务请求的最大发送次数的情况下，终端在确定所述网络侧设备未成功接收到所述第一请求后，即可重新发送所述第一请求。

在配置有多播业务请求的最大发送次数的情况下，终端在确定所述网络侧设备未成功接收到所述第一请求后，可以判定所述第一请求的发送次数是否达到最大发送次数，再根据判定结果，确定所述第二操作的具体表现形式。具体地，在所述第一请求的发送次数未达到最大发送次数的情况下，终端可以重新发送所述第一请求。在所述第一请求的发送次数达到最大发送次数的情况下，终端可以执行重建或重选操作。

终端具体执行重建或重选操作的具体表现形式与所述终端发送所述第一请求的方式相关。可选的，在所述第一请求通过随机接入过程发送的情况下，终端可以向高层，如RRC层上报媒体接入控制(Media Access Control，MAC)随机接入信道(Random AccessChannel，RACH)失败(Failure)指示，并发起重建或重选等操作。在所述第一请求通过专用信令发送的情况下，终端可以触发无线链路失败(Radio Link Failure，RLF)，进行重建过程。

需要说明的是，对于所述第二操作包括重新发送所述第一请求的情况，终端在每次重新发送所述第一请求时，可以基于发送功率爬升步长进行发送功率爬升，以提高所述第一请求发送的成功率。

另外，在所述第一请求通过两步随机接入过程发送，且发送失败的情况，终端在重新发送所述第一请求时，可以采用四步随机接入过程重新发送所述第一请求，当然，终端也可以仍采用两步随机接入过程重新发送所述第一请求，具体可根据实际情况决定，本申请实施例对此不做限定。

在实际应用中，在确定所述网络侧设备成功接收到所述第一请求的情况下，可能仍会存在终端未接收到所述目标信息的情况。对于此情况，可选的，可以执行第三操作；其中，所述第三操作可以但不仅限于包括以下任一项：

a)在等待第一时长之后，重新发送所述第一请求；

b)在确定所述目标信息处于挂起状态的情况下，停止发送所述第一请求；

c)在确定所述目标信息处于按需请求状态的情况下，重新发送所述第一请求；

d)执行第一操作，所述第一操作用于控制所述终端进入连接态。

具体实现时，a)可以适用于网络侧设备因负荷较高，导致在接收到所述第一请求之后，没有向终端发送所述目标信息的场景，但不仅限于此。所述第一时长可以为多播业务对应的重传定时器或者禁止定时器的运行时长，可以由协议预定或由网络侧设备配置。

在本申请实施例中，网络侧设备可以配置其支持的每个多播业务的业务状态，且不同多播业务的业务状态可以不同，同一多播业务的控制信息和业务信息的业务状态可以不同。

多播业务的业务状态可以包括以下状态：挂起(suspend)状态、按需请求状态、PTP发送状态。终端可以根据网络侧设备的指示获取所述目标信息关联的多播业务的业务状态，并根据该多播业务的业务状态，执行相应操作。

在所述目标信息处于挂起状态的情况下，意味着网络侧设备可能由于资源短缺等原因导致所述目标信息无法发送，终端可以停止发送所述第一请求，即执行b)。在所述目标信息处于按需请求状态的情况下，意味着网络侧设备可能由于对所述目标信息感兴趣的终端的数量较少等原因导致未发送所述目标信息，终端可继续发送所述第一请求，即执行c)。在所述目标信息处于PTP发送状态，终端可执行第一操作，进入连接态，接收所述目标信息，即执行d)。

参见图3，图3是本申请实施例提供的业务处理方法的流程图之二。本申请实施例的业务处理方法由网络侧设备执行。

如图3所示，业务处理方法可以包括以下步骤：

步骤301、接收终端发送的第一请求，所述第一请求用于请求目标信息，所述目标信息与多播业务相关，所述目标信息包括控制信息和数据信息中的至少一项。

步骤302、向所述终端发送所述目标信息。

本申请实施例的业务处理方法，网络侧设备在接收到终端发送的用于请求目标信息的第一请求之后，才会向所述终端发送所述目标信息，其中，所述目标信息与多播业务相关，所述目标信息包括控制信息和数据信息中的至少一项。这样，可以避免在没有终端对所述目标信息相关的多播业务感兴趣时，网络侧设备仍不断发送所述目标信息的情况，从而可以降低空口信令开销，节省资源。

可选的，所述接收终端发送的第一请求之前，所述方法还包括：

向所述终端发送第一信息，所述第一信息用于指示所述网络侧设备是否支持多播业务信息请求功能。

可选的，所述网络侧设备是否支持多播业务信息请求功能，包括以下至少一项：

所述网络侧设备是否支持多播业务信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务信息请求；

所述网络侧设备是否支持连接态终端的多播业务信息请求；

所述网络侧设备是否支持多播业务的控制信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务的控制信息请求；

所述网络侧设备是否支持连接态终端的多播业务的控制信息请求；

所述网络侧设备是否支持多播业务的数据信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务的数据信息请求；

所述网络侧设备是否支持连接态终端的多播业务的数据信息请求。

可选的，所述第一信息满足以下任一项：

所述第一信息为与多播业务相关的信息；

所述第一信息用于指示多播业务信息请求的参数信息；

所述第一信息用于指示多播业务的目标信息处于按需请求状态。

可选的，所述接收终端发送的第一请求之前，所述方法还包括：

向所述终端发送第二信息，所述第二信息用于指示多播业务信息请求的参数信息。

可选的，所述参数信息包括以下至少一项：多播业务信息请求的发送方式；多播业务信息请求的发送资源；多播业务信息请求的最大发送次数；多播业务信息请求的发送间隔；多播业务信息请求对应的定时器的运行时长；多播业务信息请求的发送功率爬升步长。

可选的，所述多播业务信息请求的发送方式，包括以下至少一项：

通过四步随机接入过程中的消息1发送多播业务信息请求；

通过四步随机接入过程中的消息3发送多播业务信息请求；

通过两步随机接入过程中的消息A发送多播业务信息请求；

通过专用信令发送多播业务信息请求；

通过专用资源发送多播业务信息请求。

可选的，所述第二信息为第一对象和第二对象分别指示不同的发送资源；或，所述第二信息为第一对象和第二对象指示相同的发送资源；

其中，所述第一对象为空闲态或非激活态终端的多播业务信息请求，所述第二对象为连接态终端的多播业务信息请求；或，所述第一对象为多播业务的控制信息请求，所述第二对象为多播业务的数据信息请求。

可选的，所述接收终端发送的第一请求之前，所述方法还包括：

向所述终端发送第三信息，所述第三信息指示所述网络侧设备的所述目标信息处于按需请求状态。

可选的，所述接收终端发送的第一请求，包括以下任一项：

通过四步随机接入过程中的消息1接收终端发送的第一前导码，所述第一前导码与所述第一请求对应；

通过四步随机接入过程中的消息3接收终端发送的第一无线资源控制RRC信令，所述第一RRC信令携带所述第一请求；

通过两步随机接入过程中的消息A接收终端发送的第二RRC信令，所述第二RRC信令携带所述第一请求；

接收终端发送的第三RRC信令，所述第三RRC信令携带所述第一请求。

可选的，所述向所述终端发送所述目标信息，包括：

在第一时刻向所述终端发送所述目标信息；

其中，所述第一时刻满足以下任一项：

所述第一时刻为：所述终端发送所述第一请求后的第一个所述目标信息的发送时刻；

所述第一时刻为：第一周期中所述目标信息的发送时刻；

其中，在所述目标信息为控制信息的情况下，所述第一周期为所述终端发送所述第一请求后的第一个所述目标信息的修改周期；在所述目标信息为数据信息的情况下，所述第一周期为所述终端发送所述第一请求后的第一个所述目标信息的调度周期。

可选的，所述向所述终端发送所述目标信息，包括以下任一项：

向所述终端发送N次所述目标信息之后，停止向所述终端发送所述目标信息，N为正整数；

向所述终端发送第二时长的所述目标信息之后，停止向所述终端发送所述目标信息；

向所述终端发送M个第二周期的所述目标信息之后，停止向所述终端发送所述目标信息，其中，在所述目标信息为控制信息的情况下，所述第二周期为修改周期，在所述目标信息为数据信息的情况下，所述第二周期为调度周期，M为正整数。

在本申请实施例中，为了避免所述网络侧设备无限制的广播所述目标信息，网络侧设备在开始广播所述目标信息之后，可在第二条件满足的情况下，停止广播所述目标信息，从而可以节省资源。

在本可选实施方式中，所述第二条件满足包括以下任一项：

所述目标信息的发送次数达到N次，N为正整数，N可以由协议约定或由网络侧设备实现；

所述目标信息的发送时长达到第二时长，所述第二时长可以由协议约定或由网络侧设备实现；

发送所述目标信息的第二周期达到M个，M为正整数，M可以由协议约定或由网络侧设备实现。

在其他实施方式中，所述第二条件满足还可以为以下任一项：

对所述目标信息感兴趣的终端移出所述网络侧设备对应的小区；

没有终端对所述目标信息感兴趣；

没有空闲态或非激活态终端对所述目标信息感兴趣；

对所述目标信息感兴趣的终端已成功接收到所述目标信息；

没有终端接收所述目标信息；

没有空闲态或非激活态终端接收所述目标信息；

所述目标信息未获取到发送资源。

另外，需要说明的是，在本申请实施例中，网络侧设备可以通过为所述目标信息设置按需请求标记，来决定所述目标信息的业务状态。具体地，若所述目标信息的按需请求标记出现，则每个调度周期或者每隔一定的时间间隔都需要有终端进行所述目标信息的按需请求，否则就停止发送；若所述目标信息的按需请求标记被去除，则所述目标信息可一直以广播方式发送，终端无需请求，可以直接读取所述目标信息，从而可以提高终端获取所述目标信息的效率。

在实际应用中，若所述目标信息已经因为一个终端的请求在广播发送，一种实现方式中，所述网络侧设备可以仍旧保持所述目标信息的on-demand request的标记，以避免对于SIB消息的频繁变动；另一种实现方式中，所述网络侧设备可以去除所述目标信息的on-demand request的标记，以提高终端获取所述目标信息的效率。

可选的，在所述终端处于空闲态或非激活态的情况下，所述方法还包括：

向所述终端发送第四信息，所述第四信息用于指示以下任一项：

所述终端执行第一操作，所述第一操作用于控制所述终端进入连接态；

所述网络侧设备禁止连接态终端发送多播业务信息请求；

所述网络侧设备禁止所有终端发送多播业务信息请求。

需要说明的是，本实施例作为与图2方法实施例对应的网络侧设备的实施例，因此，可以参见图2方法实施例中的相关说明，且可以达到相同的有益效果。为了避免重复说明，在此不再赘述。

需要说明的是，本申请实施例中介绍的多种可选的实施方式，彼此可以相互结合实现，也可以单独实现，对此本申请实施例不作限定。

为方便理解，示例说明如下：

本申请实施例主要解决UE对多播业务控制信息和或数据信息的主动请求机制，主要内容包括：

网络侧显式或者隐式的指示UE能够支持MBS信息请求功能；

UE只有在能够支持请求MBS信息功能的小区才能够进行MBS信息请求；

网络侧配置给UE发送MBS信息请求的参数；

UE可以对MCCH信息进行请求，网络侧接收到请求之后，广播多播方式发送MCCH信息；

UE可以对一个或者多个MTCH数据进行请求，网络侧接收到请求之后，广播多播方式发送这些请求的MTCH数据。

实施例一：网络配置。

UE行为需要在网络的控制下进行，因此网络需要对UE能够执行的行为进行许可和参数配置。与MBS业务请求相关的网络侧配置主要包括如下两个方面：

1、网络对支持的请求功能进行许可。

网络首先需要告知UE自己支持MBS信息请求功能，和/或支持的MBS信息请求的类型。

一种方法，是以网络系统消息或者专用信令中存在的专门域或者专门的信息，显式的指示是否支持MBS业务信息请求，包含以下至少一项：

是否支持MBS信息请求；

是否支持Idle/Inactive UE MBS信息请求；

是否支持Connected UE MBS信息请求；

是否支持MCCH请求；

是否支持Idle/Inactive UE MCCH请求；

是否支持Connected UE MCCH请求；

是否支持MTCH请求；

是否支持Idle/Inactive UE MTCH请求；

是否支持Connected UE MTCH请求；

另一种方法，是以网络系统消息或者专用信令中存在的其它域，隐式的指示是否支持MBS业务信息请求，包含以下至少一项：

MBS相关的SIB信息出现，例如SIB x被配置；

给出MBS信息请求的具体配置，例如配置了专用的preamble，用于MBS信息请求；

在MCCH配置里指示，MCCH目前没有发送，需要on-demand请求；

在MTCH配置里指示，MTCH目前并没有发送，需要on-demand请求；

SIB消息或者广播消息中出现以上关联域，则IDLE/Inactive UE支持对应的MBS信息请求；

SIB消息或者广播消息中出现以上关联域，则IDLE/Inactive/Connected UE支持对应的MBS信息请求；

专用信令中出现以上关联域，则connected UE支持对应的MBS信息请求；

之前进入连接态的UE在接收的专用信令中出现以上关联域，则当UE释放连接进入idle/Inactive，只要仍旧在当前小区或者当前区域，则可以认为支持对应的MBS信息请求。

2、网络对请求功能相关的参数进行配置。

当网络许可了可以支持MBS信息请求功能时，也需要进一步给出与请求相关的配置参数，给出配置的方法如下：

使用SIB消息或者其它广播消息，主要用于Idle/Inactive UE来获得请求相关的配置参数信息，当然Connected UE也可以使用这种方式获得；

使用专用信令，主要用于Connected UE来获得请求相关的配置参数信息，对于Idle/Inactive UE也可以是在进入连接态之后通过专用信令获得，之后释放连接，只要仍旧在该小区或者该配置区域内，仍旧可以使用之前专用信令获得的参数进行请求。

与MBS信息请求的配置参数，可以包括如下至少一项：

1)MBS信息请求的方式，可以包括以下至少一项：

4-step随机接入Msg1-based方式；

4-step随机接入Msg3-based方式；

2-step随机接入MsgA-based方式；

专用信令方式；

专用上行资源方式；

2)用于MBS信息请求的专用资源，具体说明如下：

可为Idle/Inactive和connected UE配置用于请求的分别或者共同专用资源；

可以为MCCH，MTCH请求配置用于请求的分别或者共同专用资源；

专用资源可以是专用Preamble，RACH的专用时频资源等；

对于connected UE，还可以是其它专用上行资源，例如PUCCH；

3)MBS信息请求的其它参数，可以包括以下至少一项：

MBS信息请求的发送最大次数；

MBS信息请求的发送间隔；

MBS信息请求禁止定时器长度；

发送失败的步长参数，例如第一次请求失败，第二次请求时可以增加功率。

实施例二、MCCH请求和更新。

MCCH是用于包含与MBS业务相关的控制信息，例如包含哪些业务TMGI，这些业务的配置参数，如g-RNTI，周期，偏移，调度和传输参数等。由于MCCH中包含的控制信息具有一定的半静态特性，即在业务存续的期间，这些配置信息一般不会变化。但由于新业务的到达或者已有业务的结束/挂起/恢复等，MCCH的内容会发生变化。

1、在如下情况，可以暂停对MCCH信息的周期性广播：

当小区中完全没有用户对相关MBS业务感兴趣时，这时候可以不用周期性广播MCCH信息；

当小区中没有Idle/Inactive UE对相关MBS业务感兴趣时，这时候可以不用周期性广播MCCH信息；

当小区中MCCH已经确保所有感兴趣MBS业务的UE都接收了，且未来一段时间MCCH信息不再变化，则可以不再周期性广播MCCH信息；

2、当目前小区中明确显式支持MBS业务或者支持MCCH on-demand request，例如实施例1中的MBS功能开关配置，而UE又同时获知目前MCCH并没有广播，而是采取on-demandrequest的形式，这个获知MCCH不广播的方式有两种：

隐式指示，UE在MCCH的调度位置没有检测到MCCH，则推测出小区并没有广播MCCH，而需要采用on-demand request的方式请求MCCH；

显式指示，网络侧在MCCH的调度信息里，明确指示该MCCH目前并没有广播，而是需要采用on-demand request的方式请求MCCH；

3、当UE获知了网络当前并没有广播MCCH信息，而UE又对MBS业务感兴趣，希望接收MBS业务，可选的，还可以有一些条件：

如果UE可以进入连接态，进行MBS业务接收，则可以不用发起MCCH on-demandrequest，而进入连接态获取MCCH和MTCH；

如果UE能力或者UE的preference，例如希望在idle/inactive进行接收以达到省电的目的，则UE感兴趣MBS业务时，可以发起MCCH on-demand request过程，以获得MCCH广播发送；

网络侧的显式指示，例如仅允许idle/inactive UE进行MCCH on-demand request过程，或者允许idle/inactive/Connected UE进行MCCH on-demand request，或者暂不允许任何UE进行MCCH on-demand request，或者建议所有UE都进入连接态以获得MBS MCCH信息；

4、当UE根据网络侧准许，和自己的意愿，希望获得MCCH以进一步接收MBS业务时，UE的行为可以如下：

方式1：对于Idle/Inactive/Connected UE来说，都可以用RACH过程Msg1-basedrequest方式，发送MCCH on-demand request特殊的一个preamble给网络，网络接收到该特殊的preamble，知道有UE希望获得MCCH，则可以将MCCH进行广播发送。

一般来说，可以立即开始在最近的MCCH发送时刻开始发送MCCH，或者在MCCH的下一个修改周期，开始进行MCCH发送。

为了避免无限制的进行广播MCCH发送，可进行一定次数的发送之后即停止，以节省资源，例如重复发送N次，或者重复发送一定的时长，或者在一个修改周期内按照重复周期发送，发送一个或者M个修改周期，之后停止。

虽然MCCH已经因为一个UE的请求在广播发送，但是对于MCCH on-demand request的标记仍旧保持，以避免对于SIB消息的频繁变动。

方式2：对于Idle/Inactive/Connected UE来说，可以用4-step RACH过程Msg3-based request方式，发送MCCH on-demand request，具体方式是采用通常的4-step RACH的Msg1和Msg2过程，然后在Msg3中以一个特殊的RRC信令，例如MBSMCCHRequest，或者扩展现有RRC消息来携带MCCH请求指示，并且，还可以在RRC消息中携带请求的MCCH的具体信息，例如SIB消息中广播了3类MCCH，MCCH 1是视频业务，MCCH2是音乐业务，MCCH3是体育节目，UE可以携带指示自己请求的是哪个或者哪些MCCH，以此向网络来指示自己希望要的MCCH消息，网络接收到该RRC消息，知道有UE希望获得MCCH，则可以将MCCH进行广播发送，发送的方式也类似上述方式1中列出的三点，与方式1的差别是由于方式2可以请求具体哪一个或者哪几个MCCH，因此网络可以仅广播请求的MCCH内容，而方式1只能广播所有MCCH，当然方式2中网络也可以选择广播所有MCCH。

如果是Idle UE，则Msg3消息中UE还可以可选的携带自己的身份信息，网络如果不希望进行MCCH的广播发送，可以将UE进行RRC Setup过程进入连接态之后，以专用信令方式发送MCCH给UE。

如果是Inactive UE，在Msg3消息中，可以携带自己的身份信息，例如RNTI等，网络侧可以选择对UE执行RRC Resume过程将其进入连接态之后，以专用信令方式发送MCCH给UE。

方式3：对于Idle/Inactive/Connected UE来说，可以用2-step RACH过程MsgA-based request方式，发送MCCH on-demand request，具体方式是采用通常的2-step RACH的MsgA过程，在MsgA的PUSCH中以一个特殊的RRC信令，例如MBSMCCHRequest，或者扩展现有RRC消息来携带MCCH请求指示，并且，还可以在RRC消息中携带请求的MCCH的具体类型信息，后续过程，同方式2。

如果是Idle UE，则MsgA的PUSCH消息中UE还可以可选的携带自己的身份信息，网络如果不希望进行MCCH的广播发送，可以将UE进行RRC Setup过程进入连接态之后，以专用信令方式发送MCCH给UE。

如果是Inactive UE，在MsgA的PUSCH消息中，可以携带自己的身份信息，例如RNTI等，网络侧可以选择对UE执行RRC Resume过程将其进入连接态之后，以专用信令方式发送MCCH给UE。

方式4：对于Connected UE来说，可以用RRC dedicated signaling过程来进行MCCH on-demand request，具体方式是采用一个特殊的RRC信令，例如MBSMCCHRequest，或者扩展现有RRC消息来携带MCCH请求指示，并且，还可以在RRC消息中携带请求的MCCH的具体类型信息，网络侧在接收到该RRC消息之后，可以选择以RRC dedicated signaling发送MCCH给UE，或者以广播方式发送MCCH，以广播方式发的话，就可以考虑方式1中的几点，避免一直广播。

实施例三：MTCH请求。

在上述实施例中，给出了请求MCCH的各种方式。在本实施例中，给出MTCH请求的方式。需要注意，网络侧可以同时配置MCCH on-demand request和MTCH on-demand request，或者仅配置MTCH on-demand request。

1、在如下情况，可以暂停对一个或者多个MTCH数据的广播方式发送：

当小区中完全没有用户对某个MBS业务感兴趣或者正在接收时，这时候可以不用广播方式发送对应的MTCH业务；

当小区中没有Idle/Inactive UE对某个MBS业务感兴趣或者正在接收时，这时候可以不用广播方式发送对应的MTCH信息；

当小区中资源负荷超出一定门限，而由于其它业务抢占，导致这个MTCH无法再获得资源时。

2、UE进行MTCH请求，需要有以下前提：

UE在进行MTCH请求之前，需要先从网络侧接收到MCCH信息，从MCCH信息里可以获得有哪些MTCH，例如MTCH list，包含TMGI，业务标识，业务特征等；UE从这些内容，决定自己对一个或者多个业务感兴趣，因此需要进行这一个或者多个业务对应的MTCH的业务接收。

3、UE希望接收一个或者多个业务对应的MTCH，但此时UE又从网络侧获知自己感兴趣的MTCH目前处于on-demand request状态，获知这种状态的方式可以如下一种或者组合：

UE从MCCH里获得了MTCH调度信息，但是在调度位置并没有读取到对应的MTCH信息，因此猜测网络侧进行了MTCH的挂起/on-demand/PTP等方式，则UE可以进行MTCH请求；

UE从MCCH里获得了MTCH调度信息，并且在MCCH里有该MTCH详细的状态指示，例如当前MTCH suspend/on-demand request/PTP only等方式，都说明该MTCH没有广播发送，此时UE可以进行MTCH请求。

网络对每个MTCH可以是不同的状态，例如MTCH 1是broadcast状态，MTCH 2是suspend/on-demand request状态，MTCH 3是PTP only状态，一般来说，UE只需要对后两种进行请求，第一种情况MTCH已经在广播方式发送，如果UE仍旧无法接收，则说明广播方式发送覆盖不到该UE，建议UE进入连接态，以单播PTP方式进行接收；

特别的，对于一些多播业务对应的MTCH，网络侧也可以配置给UE该业务不支持多播/广播方式发送，例如为了确保接收效果和满足QoS需求，该业务只推荐UE进入连接态以PTP方式进行接收；

4、当UE从网络侧获知了一个或者多个感兴趣的MTCH信息，需要进行这一个或者多个感兴趣MTCH请求，则UE行为可以如下：

方式1：对于Idle/Inactive/Connected UE来说，都可以用RACH过程Msg1-basedrequest方式，发送MTCH on-demand request特殊的一个preamble给网络，网络接收到该特殊的preamble，知道有UE希望获得MTCH，如果preamble并不能区分哪个MTCH,则只能将所有MTCH都进行广播发送，如果对一个MTCH或者几个MTCH组成的MTCH group分配对应的preamble，则网络侧可以根据preamble获知UE对哪个/哪些MTCH感兴趣，只对请求的MTCH进行广播发送。

一般来说，可以立即开始在最近的MTCH调度时刻开始发送MTCH，或者从MTCH的下一个调度周期，开始进行MTCH发送。

为了避免无限制的进行广播MTCH发送，可以当感兴趣UE移出该小区时向网络进行通知，或者当网络发送一定时长之后，或者网络以一定的时间间隔，再次需要UE进行确认是否感兴趣，如果没有任何一个UE响应，则网络认为不再有UE感兴趣，可以停止MTCH发送：

网络可在信令中配置这种需要UE不断确认是否感兴趣的方式，如下一点；

网络也可以在该MTCH用户平面消息中，例如L2 control PDU，PDCP control PDU，MAC CE(Control element)等，告知UE需要再次响应，否则MTCH将停止。

UE再次响应的方式，与第一次请求类似，或者可以采取其它方式，总之告知网络仍旧有UE感兴趣该MTCH，需要继续广播发送即可；

虽然MTCH已经因为一个UE的请求在广播发送，但是对于MTCH on-demand request的标记可以仍旧保持，保持的含义意味着，例如每个调度周期或者每隔一定的时间间隔都需要有UE进行该MTCH on-demand request，否则就停止发送，或者MTCH on-demandrequest标记可以去除，意味着后续这个MTCH可以一直以广播方式发送，UE无需再次请求。

方式2：对于Idle/Inactive/Connected UE来说，可以用4-step RACH过程Msg3-based request方式，发送MTCH on-demand request，具体方式是采用通常的4-step RACH的Msg1和Msg2过程，然后在Msg3中以一个特殊的RRC信令，例如MBSMTCHRequest，或者扩展现有RRC消息来携带MTCH请求指示，并且，还可以在RRC消息中携带请求的MTCH的具体信息，例如MCCH消息中通知了8个MTCH业务，UE可以携带指示自己请求的是哪个或者哪些MTCH，例如以8个bit位，其中顺序以MCCH中每个MTCH的配置顺序一致，对应MTCH的bit位置为1意味着UE希望请求该MTCH广播接收，对应MTCH的bit位置为0意味着UE并没有请求该MTCH，以此向网络来指示自己希望要的MTCH详细消息，网络接收到该RRC消息，知道有UE希望获得MTCH，则可以将MTCH进行广播发送，发送的方式也类似上述方式1中列出的三点，与方式1的差别是由于方式2可以请求具体哪一个或者哪几个MTCH，因此网络可以仅广播请求的MTCH内容，而方式1只能广播所有MTCH。

如果是Idle UE，则Msg3消息中UE还可以可选的携带自己的身份信息，网络如果不希望进行MTCH的广播发送，可以将UE进行RRC Setup过程进入连接态之后，以专用调度方式发送MTCH给UE。

如果是Inactive UE，在Msg3消息中，可以携带自己的身份信息，例如RNTI等，网络侧可以选择对UE执行RRC Resume过程将其进入连接态之后，以专用调度方式发送MTCH给UE。

方式3：对于Idle/Inactive/Connected UE来说，可以用2-step RACH过程MsgA-based request方式，发送MTCH on-demand request，具体方式是采用通常的2-step RACH的MsgA过程，在MsgA的PUSCH中以一个特殊的RRC信令，例如MBSMTCHRequest，或者扩展现有RRC消息来携带MTCH请求指示，并且，还可以在RRC消息中携带请求的MTCH的具体类型信息，后续过程，同方式2。

如果是Idle UE，则MsgA的PUSCH消息中UE还可以可选的携带自己的身份信息，网络如果不希望进行MTCH的广播发送，可以将UE进行RRC Setup过程进入连接态之后，以专用调度方式发送MTCH给UE。

如果是Inactive UE，在MsgA的PUSCH消息中，可以携带自己的身份信息，例如RNTI等，网络侧可以选择对UE执行RRC Resume过程将其进入连接态之后，以专用调度方式发送MTCH给UE。

方式4，对于Connected UE来说，可以用RRC dedicated signaling过程来进行MTCH on-demand request，具体方式是采用一个特殊的RRC信令，例如MBSMTCHRequest，或者扩展现有RRC消息来携带MTCH请求指示，并且，还可以在RRC消息中携带请求的MTCH的具体详细信息，网络侧在接收到该RRC消息之后，可以选择以专用调度方式，例如PTP方式，发送MTCH给UE，或者以广播方式发送MTCH，以广播方式发的话，就可以考虑方式1中的几点，避免感兴趣UE为零时仍旧一直广播。

实施例四：重复发送请求和失败处理。

当UE第一次向网络发送了请求之后，网络如果快速进行响应，即UE请求的MCCH或MTCH非常快的以广播/组播的方式进行了发送，则UE不需要再次进行重复请求，接收对应的MCCH/MTCH即可。如果UE发送了MCCH/MTCH请求，UE的行为可以如下：

首先，与UE发送请求的方式相关，不同情况下UE判定自己的请求被网络正确接收的方式如下：

如果是Msg1 based MBS info request，由于UE发送Msg1之后，UE需要在特定的窗口RAR(RACH Response)window中监听网络侧的响应，即检测到对应自己的Msg1的响应，例如PRACH资源计算出的RAPID(Random Access Preamble IDentifier)，preamble 64个，特定预留给Msg 1的那个，将对应自己的RAPID，如果UE接收到对应的RAPID，证明自己的请求网络接收到了，则请求过程成功结束；

如果是Msg3 based MBS info request，网络侧在Msg4会对UE进行竞争解决，即将Msg3的部分内容携带下来，UE比对之后，就可以知道是自己的Msg4，成功接收Msg4也意味着自己的请求网络接收到了，则请求过程成功结束；

如果是MsgA based MBS info request，网络侧在MsgB会对UE进行竞争解决，即将MsgA的部分内容携带下来，UE比对之后，就可以知道是自己的MsgB，成功接收MsgB也意味着自己的请求网络接收到了，则请求过程成功结束；

如果是RRC专用信令请求，则这个专用信令可以设计为需要网络侧以RRC消息来确认收到，也可以通过RLC ACK来确认收到，总之这两种方式，都可确保网络侧正确接收UE的请求，确认之后则UE认为请求过程成功结束。

其次，如果没有发送成功，则UE的行为如下：

当UE是通过RACH过程来发送MBS信息请求，则RACH过程对于Msg1-based request如果在RAR窗口中没有接收到响应，则再次重发Msg1，且功率爬升，发送次数加1操作；对于Msg3-based request，如果Msg4的竞争解决窗口中没有收到确认，则也再次重新进行RACH过程，功率爬升，发送次数加1操作；对于MsgA-based request，如果MsgB窗口中没有收到确认，则也再次重新进行2-step RACH过程，功率爬升，发送次数加1操作；特别的，将2-stepRACH尝试次数到达最大限制，可以回退到4-step RACH继续以Msg3-based方式或者Msg1-based方式继续发送；

如果到达RACH总的最大发送次数，仍旧没有成功，则UE需要向高层上报MAC RACHfailure指示，UE需要发起重建或者重选等操作；

如果是专用信令发送请求，则RRC信令一定是RLC AM，配置有RLC最大重传次数，一旦到达最大重传次数仍旧没有成功，UE触发RLF(Radio Link Failure)，进行重建过程；

其它，如果UE MBS请求发送成功，意味着请求被网络侧确认收到了，但是在MCCH发送时刻，例如当前最近的MCCH发送时刻或者下一个MCCH修改周期，或者MTCH的发送时刻，例如当前最近的MTCH发送时刻或者下一个MTCH调度周期时，UE并没有接收到预期的MCCH或者MTCH，或者UE被网络告知无法进行该业务的请求，UE行为如下：

UE默认网络侧因为其它原因无法进行请求的MCCH或者MTCH的发送，例如网络负荷较高，则UE可以等待一定的时长，这个时长可以是网络侧配置给UE的值，例如重传定时器或者禁止定时器，在该时长之后，UE被允许可以再次发送相同的请求，期待网络侧满足请求的MCCH/MTCH广播多播方式发送；

UE根据网络侧最新的配置，例如网络侧的业务状态，将该MTCH标记成挂起暂无法恢复(suspend)或者是挂起可以请求(on-demand)，这种情况下，suspend和on-demand是两个独立状态，suspend意味着目前由于资源短缺等原因该业务无法多播发送，on-demand意味着该业务由于用户数少等原因没有多播发送但可以被请求多播发送，则当业务状态改变成suspend时，UE只能停止对业务的请求，等待它的状态变为可以请求(on-demand)；

UE根据网络侧的配置，例如网络侧的业务状态，将该MTCH标记成PTP only，这种情况下，UE不用发起MTCH on-demand请求，而直接进入连接态，请求业务信息和接收；

额外的，对于Idle/Inactive UE来说，他们请求MBS信息，不需要有最大次数限制，只要网络许可，可以不断请求，直到网络将请求的信息进行广播发送；

本示例主要针对UE请求多播业务的控制信息和或数据信息的方法，主要给出：

1、网络侧向UE发送可以进行on-demand MBS请求的配置信息。

2、基于1，UE在对MBS业务感兴趣时，可以进行MCCH请求。

3、基于2，MCCH请求的条件。

4、基于2，MCCH请求的方式。

5、基于2，网络侧对MCCH请求的处理。

6、基于1，UE在对某个或者某些MBS业务感兴趣时，可以进行对应的MTCH请求。

7、基于6，MTCH请求的条件。

8、基于6，MTCH请求的方式。

9、基于6，网络对MTCH请求的处理。

10、基于6，网络定期请求或者要求UE进行感兴趣确认，否则停止发送。

11、重发的方法，重传定时器或者禁止定时器。

本申请实施例给出了MBS业务操作中，网络仅广播MBS业务基本信息，当UE请求时，才进行详细业务控制信息和或数据信息的广播多播发送，有利于提升网络资源效率，在确保UE的MBS业务接收体验的基础上大大提升了系统效率。

需要说明的是，本申请实施例提供的业务处理方法，执行主体可以为业务处理装置，或者，该业务处理装置中的用于执行业务处理方法的控制模块。本申请实施例中以业务处理装置执行业务处理方法为例，说明本申请实施例提供的业务处理装置。

参见图4，图4是本申请实施例提供的业务处理装置的结构图之一。

如图4所示，业务处理装置400包括：

第一发送模块401，用于向网络侧设备发送第一请求，所述第一请求用于请求目标信息，所述目标信息与多播业务相关，所述目标信息包括控制信息和数据信息中的至少一项；

第一接收模块402，用于接收所述目标信息。

可选的，所述业务处理装置400还包括：

第二接收模块，用于接收所述网络侧设备发送的第一信息，所述第一信息用于指示所述网络侧设备是否支持多播业务信息请求功能；

所述第一发送模块401，具体用于在所述第一信息指示所述网络侧设备支持所述多播业务信息请求功能的情况下，向网络侧设备发送第一请求。

可选的，所述网络侧设备是否支持多播业务信息请求功能，包括以下至少一项：

所述网络侧设备是否支持多播业务信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务信息请求；

所述网络侧设备是否支持连接态终端的多播业务信息请求；

所述网络侧设备是否支持多播业务的控制信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务的控制信息请求；

所述网络侧设备是否支持连接态终端的多播业务的控制信息请求；

所述网络侧设备是否支持多播业务的数据信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务的数据信息请求；

所述网络侧设备是否支持连接态终端的多播业务的数据信息请求。

可选的，所述第一信息满足以下任一项：

所述第一信息为与多播业务相关的信息；

所述第一信息用于指示多播业务信息请求的参数信息；

所述第一信息用于指示多播业务的目标信息处于按需请求状态。

可选的，所述业务处理装置400还包括：

第三接收模块，用于接收网络侧设备发送的第二信息，所述第二信息用于指示多播业务信息请求的参数信息；

所述第一发送模块401，具体用于：

根据所述第二信息，向网络侧设备发送第一请求。

可选的，所述参数信息包括以下至少一项：多播业务信息请求的发送方式；多播业务信息请求的发送资源；多播业务信息请求的最大发送次数；多播业务信息请求的发送间隔；多播业务信息请求对应的定时器的运行时长；多播业务信息请求的发送功率爬升步长。

可选的，所述多播业务信息请求的发送方式，包括以下至少一项：

通过四步随机接入过程中的消息1发送多播业务信息请求；

通过四步随机接入过程中的消息3发送多播业务信息请求；

通过两步随机接入过程中的消息A发送多播业务信息请求；

通过专用信令发送多播业务信息请求；

通过专用资源发送多播业务信息请求。

可选的，所述第二信息为第一对象和第二对象分别指示不同的发送资源；或，所述第二信息为第一对象和第二对象指示相同的发送资源；

其中，所述第一对象为空闲态或非激活态终端的多播业务信息请求，所述第二对象为连接态终端的多播业务信息请求；或，所述第一对象为多播业务的控制信息请求，所述第二对象为多播业务的数据信息请求。

可选的，所述第一发送模块401，具体用于：

在确定所述网络侧设备的所述目标信息处于按需请求状态的情况下，向网络侧设备发送第一请求。

可选的，所述业务处理装置400还包括：

第一确定模块，用于在第一条件满足的情况下，确定所述网络侧设备的所述目标信息处于按需请求状态；

其中，所述第一条件满足包括以下任一项：

在第一调度位置未检测到所述目标信息，所述第一调度位置为所述网络侧设备的所述目标信息的调度位置；

接收到所述网络侧设备发送的第三信息，所述第三信息指示所述网络侧设备的所述目标信息处于按需请求状态。

可选的，所述第一发送模块401，具体用于以下任一项：

通过四步随机接入过程中的消息1向网络侧设备发送第一前导码，所述第一前导码与所述第一请求对应；

通过四步随机接入过程中的消息3向网络侧设备发送第一无线资源控制RRC信令，所述第一RRC信令携带所述第一请求；

通过两步随机接入过程中的消息A向网络侧设备发送第二RRC信令，所述第二RRC信令携带所述第一请求；

向网络侧设备发送第三RRC信令，所述第三RRC信令携带所述第一请求。

可选的，所述第一接收模块402，具体用于：

在第一时刻接收所述目标信息；

其中，所述第一时刻满足以下任一项：

所述第一时刻为：所述终端发送所述第一请求后的第一个所述目标信息的发送时刻；

所述第一时刻为：第一周期中所述目标信息的发送时刻；

其中，在所述目标信息为控制信息的情况下，所述第一周期为所述终端发送所述第一请求后的第一个所述目标信息的修改周期；在所述目标信息为数据信息的情况下，所述第一周期为所述终端发送所述第一请求后的第一个所述目标信息的调度周期。

可选的，在终端处于空闲态或非激活态的情况下，所述业务处理装置400还包括：第一执行模块，用于执行第一操作，所述第一操作用于控制所述终端进入连接态；接收所述目标信息。

可选的，所述业务处理装置400还包括：

第四接收模块，用于接收所述网络侧设备发送的第四信息，所述第四信息用于指示以下任一项：

所述终端执行所述第一操作；

所述网络侧设备禁止连接态终端发送多播业务信息请求；

所述网络侧设备禁止所有终端发送多播业务信息请求。

可选的，所述业务处理装置400还包括：

第二确定模块，用于确定所述网络侧设备是否成功接收到所述第一请求；

所述第一接收模块402，具体用于：在确定所述网络侧设备成功接收到所述第一请求的情况下，接收所述目标信息。

可选的，所述第二确认模块，具体用于以下至少一项：

在所述终端通过四步随机接入过程中的消息1发送所述第一请求的情况下，确定是否接收到第一前导码的标识，所述第一前导码与所述第一请求对应；

在所述终端通过四步随机接入过程中的消息3发送所述第一请求的情况下，确定是否成功接收到消息4；

在所述终端通过两步随机接入过程中的消息A发送所述第一请求的情况下，确定是否成功接收到消息B；

在所述终端通过专用信令发送所述第一请求的情况下，确定是否接收到所述网络侧设备针对所述第一请求发送的确认信息。

可选的，所述业务处理装置400还包括：

第二执行模块，用于在确定所述网络侧设备成功接收到所述第一请求的情况下，执行第二操作；

其中，所述第二操作包括以下任一项：

重新发送所述第一请求；

在所述第一请求的发送次数未达到最大发送次数的情况下，重新发送所述第一请求；

在所述第一请求的发送次数达到最大发送次数的情况下，执行重建或重选操作。

可选的，所述业务处理装置400还包括：

第三执行模块，用于在确定所述网络侧设备成功接收到所述第一请求，且所述终端未接收到所述目标信息的情况下，执行第三操作；

其中，所述第三操作包括以下任一项：

在等待第一时长之后，重新发送所述第一请求；

在确定所述目标信息处于挂起状态的情况下，停止发送所述第一请求；

在确定所述目标信息处于按需请求状态的情况下，重新发送所述第一请求；

执行第一操作，所述第一操作用于控制所述终端进入连接态。

本申请实施例中的业务处理装置可以是装置，也可以是终端中的部件、集合成电路、或芯片。该装置可以是移动终端，也可以为非移动终端。示例性的，移动终端可以包括但不限于上述所列举的终端11的类型，非移动终端可以为服务器、网络附属存储器(NetworkAttached Storage，NAS)、个人计算机(personal computer，PC)、电视机(television，TV)、柜员机或者自助机等，本申请实施例不作具体限定。

本申请实施例中的业务处理装置可以为具有操作系统的装置。该操作系统可以为安卓(Android)操作系统，可以为ios操作系统，还可以为其他可能的操作系统，本申请实施例不作具体限定。

本申请实施例提供的业务处理装置400能够实现图2方法实施例实现的各个过程，并达到相同的技术效果，为避免重复，这里不再赘述。

需要说明的是，本申请实施例提供的业务处理方法，执行主体可以为业务处理装置，或者，该业务处理装置中的用于执行业务处理方法的控制模块。本申请实施例中以业务处理装置执行业务处理方法为例，说明本申请实施例提供的业务处理装置。

参见图5，图5是本申请实施例提供的业务处理装置的结构图之二。

如图5所示，业务处理装置500包括：

第五接收模块501，用于接收终端发送的第一请求，所述第一请求用于请求目标信息，所述目标信息与多播业务相关，所述目标信息包括控制信息和数据信息中的至少一项；

第二发送模块502，用于向所述终端发送所述目标信息。

可选的，所述业务处理装置500还包括：

第三发送模块，用于向所述终端发送第一信息，所述第一信息用于指示所述网络侧设备是否支持多播业务信息请求功能。

可选的，所述网络侧设备是否支持多播业务信息请求功能，包括以下至少一项：

所述网络侧设备是否支持多播业务信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务信息请求；

所述网络侧设备是否支持连接态终端的多播业务信息请求；

所述网络侧设备是否支持多播业务的控制信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务的控制信息请求；

所述网络侧设备是否支持连接态终端的多播业务的控制信息请求；

所述网络侧设备是否支持多播业务的数据信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务的数据信息请求；

所述网络侧设备是否支持连接态终端的多播业务的数据信息请求。

可选的，所述业务处理装置500还包括：

第四发送模块，用于向所述终端发送第二信息，所述第二信息用于指示多播业务信息请求的参数信息。

可选的，所述参数信息包括以下至少一项：多播业务信息请求的发送方式；多播业务信息请求的发送资源；多播业务信息请求的最大发送次数；多播业务信息请求的发送间隔；多播业务信息请求对应的定时器的运行时长；多播业务信息请求的发送功率爬升步长。

可选的，所述多播业务信息请求的发送方式，包括以下至少一项：

通过四步随机接入过程中的消息1发送多播业务信息请求；

通过四步随机接入过程中的消息3发送多播业务信息请求；

通过两步随机接入过程中的消息A发送多播业务信息请求；

通过专用信令发送多播业务信息请求；

通过专用资源发送多播业务信息请求。

可选的，所述第二信息为第一对象和第二对象分别指示不同的发送资源；或，所述第二信息为第一对象和第二对象指示相同的发送资源；

其中，所述第一对象为空闲态或非激活态终端的多播业务信息请求，所述第二对象为连接态终端的多播业务信息请求；或，所述第一对象为多播业务的控制信息请求，所述第二对象为多播业务的数据信息请求。

可选的，所述业务处理装置500还包括：

第五发送模块，用于向所述终端发送第三信息，所述第三信息指示所述网络侧设备的所述目标信息处于按需请求状态。

可选的，所述第五接收模块501，具体用于以下任一项：

通过四步随机接入过程中的消息1接收终端发送的第一前导码，所述第一前导码与所述第一请求对应；

通过四步随机接入过程中的消息3接收终端发送的第一无线资源控制RRC信令，所述第一RRC信令携带所述第一请求；

通过两步随机接入过程中的消息A接收终端发送的第二RRC信令，所述第二RRC信令携带所述第一请求；

接收终端发送的第三RRC信令，所述第三RRC信令携带所述第一请求。

可选的，所述第二发送模块502，具体用于：

在第一时刻向所述终端发送所述目标信息；

其中，所述第一时刻满足以下任一项：

所述第一时刻为：所述终端发送所述第一请求后的第一个所述目标信息的发送时刻；

所述第一时刻为：第一周期中所述目标信息的发送时刻；

其中，在所述目标信息为控制信息的情况下，所述第一周期为所述终端发送所述第一请求后的第一个所述目标信息的修改周期；在所述目标信息为数据信息的情况下，所述第一周期为所述终端发送所述第一请求后的第一个所述目标信息的调度周期。

可选的，所述第二发送模块502，具体用于以下任一项：

向所述终端发送N次所述目标信息之后，停止向所述终端发送所述目标信息，N为正整数；

向所述终端发送第二时长的所述目标信息之后，停止向所述终端发送所述目标信息；

向所述终端发送M个第二周期的所述目标信息之后，停止向所述终端发送所述目标信息，其中，在所述目标信息为控制信息的情况下，所述第二周期为修改周期，在所述目标信息为数据信息的情况下，所述第二周期为调度周期，M为正整数。

可选的，在所述终端处于空闲态或非激活态的情况下，所述业务处理装置500还包括：

第六发送模块，用于向所述终端发送第四信息，所述第四信息用于指示以下任一项：

所述终端执行第一操作，所述第一操作用于控制所述终端进入连接态；

所述网络侧设备禁止连接态终端发送多播业务信息请求；

所述网络侧设备禁止所有终端发送多播业务信息请求。

本申请实施例中的业务处理装置500可以是装置，也可以是网络侧设备中的部件、集合成电路、或芯片。网络侧设备可以包括但不限于上述所列举的网络侧设备12的类型，本申请实施例不作具体限定。

本申请实施例提供的业务处理装置500能够实现图3方法实施例实现的各个过程，并达到相同的技术效果，为避免重复，这里不再赘述。

可选的，如图6所示，本申请实施例还提供一种通信设备600，包括处理器601，存储器602，存储在存储器602上并可在所述处理器601上运行的程序或指令，例如，该通信设备600为终端时，该程序或指令被处理器601执行时实现上述图2方法实施例的各个过程，且能达到相同的技术效果。该通信设备600为网络侧设备时，该程序或指令被处理器601执行时实现上述图3方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

图7为实现本申请实施例的一种终端的硬件结构示意图。

该终端700包括但不限于：射频单元701、网络模块702、音频输出单元703、输入单元704、传感器705、显示单元706、用户输入单元707、接口单元708、存储器709、以及处理器710等部件。

本领域技术人员可以理解，终端700还可以包括给各个部件供电的电源(比如电池)，电源可以通过电源管理系统与处理器710逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。图7中示出的终端结构并不构成对终端的限定，终端可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置，在此不再赘述。

应理解的是，本申请实施例中，输入单元704可以包括图形处理器(GraphicsProcessing Unit，GPU)7041和麦克风7042，图形处理器7041对在视频捕获模式或图像捕获模式中由图像捕获装置(如摄像头)获得的静态图片或视频的图像数据进行处理。显示单元706可包括显示面板7061，可以采用液晶显示器、有机发光二极管等形式来配置显示面板7061。用户输入单元707包括触控面板7071以及其他输入设备7072。触控面板7071，也称为触摸屏。触控面板7071可包括触摸检测装置和触摸控制器两个部分。其他输入设备7072可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆，在此不再赘述。

本申请实施例中，射频单元701将来自网络侧设备的下行数据接收后，给处理器710处理；另外，将上行的数据发送给网络侧设备。通常，射频单元701包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器、双工器等。

存储器709可用于存储软件程序或指令以及各种数据。存储器709可主要包括存储程序或指令区和存储数据区，其中，存储程序或指令区可存储操作系统、至少一个功能所需的应用程序或指令(比如声音播放功能、图像播放功能等)等。此外，存储器709可以包括高速随机存取存储器，还可以包括非易失性存储器，其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。

处理器710可包括一个或多个处理单元；可选的，处理器710可集合成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序或指令等，调制解调处理器主要处理无线通信，如基带处理器。可以理解的是，上述调制解调处理器也可以不集合成到处理器710中。

其中，射频单元701，用于：

向网络侧设备发送第一请求，所述第一请求用于请求目标信息，所述目标信息与多播业务相关，所述目标信息包括控制信息和数据信息中的至少一项；

接收所述目标信息。

可选的，射频单元701，还用于：

接收所述网络侧设备发送的第一信息，所述第一信息用于指示所述网络侧设备是否支持多播业务信息请求功能；

在所述第一信息指示所述网络侧设备支持所述多播业务信息请求功能的情况下，向网络侧设备发送第一请求。

可选的，所述网络侧设备是否支持多播业务信息请求功能，包括以下至少一项：

所述网络侧设备是否支持多播业务信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务信息请求；

所述网络侧设备是否支持连接态终端的多播业务信息请求；

所述网络侧设备是否支持多播业务的控制信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务的控制信息请求；

所述网络侧设备是否支持连接态终端的多播业务的控制信息请求；

所述网络侧设备是否支持多播业务的数据信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务的数据信息请求；

所述网络侧设备是否支持连接态终端的多播业务的数据信息请求。

可选的，所述第一信息满足以下任一项：

所述第一信息为与多播业务相关的信息；

所述第一信息用于指示多播业务信息请求的参数信息；

所述第一信息用于指示多播业务的目标信息处于按需请求状态。

可选的，射频单元701，还用于：

接收网络侧设备发送的第二信息，所述第二信息用于指示多播业务信息请求的参数信息；

根据所述第二信息，向网络侧设备发送第一请求。

可选的，所述参数信息包括以下至少一项：多播业务信息请求的发送方式；多播业务信息请求的发送资源；多播业务信息请求的最大发送次数；多播业务信息请求的发送间隔；多播业务信息请求对应的定时器的运行时长；多播业务信息请求的发送功率爬升步长。

可选的，所述多播业务信息请求的发送方式，包括以下至少一项：

通过四步随机接入过程中的消息1发送多播业务信息请求；

通过四步随机接入过程中的消息3发送多播业务信息请求；

通过两步随机接入过程中的消息A发送多播业务信息请求；

通过专用信令发送多播业务信息请求；

通过专用资源发送多播业务信息请求。

可选的，所述第二信息为第一对象和第二对象分别指示不同的发送资源；或，所述第二信息为第一对象和第二对象指示相同的发送资源；

其中，所述第一对象为空闲态或非激活态终端的多播业务信息请求，所述第二对象为连接态终端的多播业务信息请求；或，所述第一对象为多播业务的控制信息请求，所述第二对象为多播业务的数据信息请求。

可选的，射频单元701，还用于：

在确定所述网络侧设备的所述目标信息处于按需请求状态的情况下，向网络侧设备发送第一请求。

可选的，处理器710，还用于：

第一确定模块，用于在第一条件满足的情况下，确定所述网络侧设备的所述目标信息处于按需请求状态；

其中，所述第一条件满足包括以下任一项：

在第一调度位置未检测到所述目标信息，所述第一调度位置为所述网络侧设备的所述目标信息的调度位置；

接收到所述网络侧设备发送的第三信息，所述第三信息指示所述网络侧设备的所述目标信息处于按需请求状态。

可选的，射频单元701，还用于以下任一项：

通过四步随机接入过程中的消息1向网络侧设备发送第一前导码，所述第一前导码与所述第一请求对应；

通过四步随机接入过程中的消息3向网络侧设备发送第一无线资源控制RRC信令，所述第一RRC信令携带所述第一请求；

通过两步随机接入过程中的消息A向网络侧设备发送第二RRC信令，所述第二RRC信令携带所述第一请求；

向网络侧设备发送第三RRC信令，所述第三RRC信令携带所述第一请求。

可选的，射频单元701，还用于：

在第一时刻接收所述目标信息；

其中，所述第一时刻满足以下任一项：

所述第一时刻为：所述终端发送所述第一请求后的第一个所述目标信息的发送时刻；

所述第一时刻为：第一周期中所述目标信息的发送时刻；

其中，在所述目标信息为控制信息的情况下，所述第一周期为所述终端发送所述第一请求后的第一个所述目标信息的修改周期；在所述目标信息为数据信息的情况下，所述第一周期为所述终端发送所述第一请求后的第一个所述目标信息的调度周期。

可选的，在终端处于空闲态或非激活态的情况下，所述业务处理装置还包括：第一执行模块，用于执行第一操作，所述第一操作用于控制所述终端进入连接态；射频单元701，还用于：接收所述目标信息。

可选的，射频单元701，还用于：

接收所述网络侧设备发送的第四信息，所述第四信息用于指示以下任一项：

所述终端执行所述第一操作；

所述网络侧设备禁止连接态终端发送多播业务信息请求；

所述网络侧设备禁止所有终端发送多播业务信息请求。

可选的，处理器710，还用于：

确定所述网络侧设备是否成功接收到所述第一请求；

射频单元701，还用于：在确定所述网络侧设备成功接收到所述第一请求的情况下，接收所述目标信息。

可选的，处理器710，还用于以下至少一项：

在所述终端通过四步随机接入过程中的消息1发送所述第一请求的情况下，确定是否接收到第一前导码的标识，所述第一前导码与所述第一请求对应；

在所述终端通过四步随机接入过程中的消息3发送所述第一请求的情况下，确定是否成功接收到消息4；

在所述终端通过两步随机接入过程中的消息A发送所述第一请求的情况下，确定是否成功接收到消息B；

在所述终端通过专用信令发送所述第一请求的情况下，确定是否接收到所述网络侧设备针对所述第一请求发送的确认信息。

可选的，处理器710，还用于以下至少一项：

在确定所述网络侧设备成功接收到所述第一请求的情况下，执行第二操作；

其中，所述第二操作包括以下任一项：

通过射频单元701重新发送所述第一请求；

在所述第一请求的发送次数未达到最大发送次数的情况下，通过射频单元701重新发送所述第一请求；

在所述第一请求的发送次数达到最大发送次数的情况下，执行重建或重选操作。

可选的，处理器710，还用于：

在确定所述网络侧设备成功接收到所述第一请求，且所述终端未接收到所述目标信息的情况下，执行第三操作；

其中，所述第三操作包括以下任一项：

在等待第一时长之后，通过射频单元701重新发送所述第一请求；

在确定所述目标信息处于挂起状态的情况下，停止发送所述第一请求；

在确定所述目标信息处于按需请求状态的情况下，通过射频单元701重新发送所述第一请求；

执行第一操作，所述第一操作用于控制所述终端进入连接态。

需要说明的是，本实施例中上述终端700可实现本申请实施例中图2方法实施例中的各个过程，及达到相同的有益效果，为避免重复，此处不再赘述。

具体地，本申请实施例还提供了一种网络侧设备。如图8所示，该网络设备800包括：天线81、射频装置82、基带装置83。天线81与射频装置82连接。在上行方向上，射频装置82通过天线81接收信息，将接收的信息发送给基带装置83进行处理。在下行方向上，基带装置83对要发送的信息进行处理，并发送给射频装置82，射频装置82对收到的信息进行处理后经过天线81发送出去。

上述频带处理装置可以位于基带装置83中，以上实施例中网络侧设备执行的方法可以在基带装置83中实现，该基带装置83包括处理器84和存储器85。

基带装置83例如可以包括至少一个基带板，该基带板上设置有多个芯片，如图8所示，其中一个芯片例如为处理器84，与存储器85连接，以调用存储器85中的程序，执行以上方法实施例中所示的网络设备操作。

该基带装置83还可以包括网络接口86，用于与射频装置82交互信息，该接口例如为通用公共无线接口(common public radio interface，简称CPRI)。

具体地，本申请实施例的网络侧设备还包括：存储在存储器85上并可在处理器84上运行的指令或程序，处理器84调用存储器85中的指令或程序执行图3方法实施例中的各个过程，并达到相同的技术效果，为避免重复，故不在此赘述。

本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述业务处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的计算机可读存储介质，如只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等。

本申请实施例还提供一种可读存储介质，所述可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述图2或图3方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

其中，所述处理器为上述实施例中所述的终端中的处理器。所述可读存储介质，包括计算机可读存储介质，如计算机只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或光盘等。

本申请实施例另提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行网络侧设备程序或指令，实现上述图2或图3方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

应理解，本申请实施例提到的芯片还可以称为系统级芯片，系统芯片，芯片系统或片上系统芯片等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本申请实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。

上面集合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (38)

1.一种业务处理方法，由终端执行，其特征在于，所述方法包括：

向网络侧设备发送第一请求，所述第一请求用于请求目标信息，所述目标信息与多播业务相关，所述目标信息包括控制信息和数据信息中的至少一项；

接收所述目标信息；

所述向网络侧设备发送第一请求之前，所述方法还包括：

接收所述网络侧设备发送的第一信息，所述第一信息用于指示所述网络侧设备是否支持多播业务信息请求功能；

所述向网络侧设备发送第一请求，包括：

在所述第一信息指示所述网络侧设备支持所述多播业务信息请求功能的情况下，向网络侧设备发送第一请求。

2.根据权利要求1所述的方法，其特征在于，所述网络侧设备是否支持多播业务信息请求功能，包括以下至少一项：

所述网络侧设备是否支持多播业务信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务信息请求；

所述网络侧设备是否支持连接态终端的多播业务信息请求；

所述网络侧设备是否支持多播业务的控制信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务的控制信息请求；

所述网络侧设备是否支持连接态终端的多播业务的控制信息请求；

所述网络侧设备是否支持多播业务的数据信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务的数据信息请求；

所述网络侧设备是否支持连接态终端的多播业务的数据信息请求。

3.根据权利要求1所述的方法，其特征在于，所述第一信息满足以下任一项：

所述第一信息为与多播业务相关的信息；

所述第一信息用于指示多播业务信息请求的参数信息；

所述第一信息用于指示多播业务的目标信息处于按需请求状态。

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

接收网络侧设备发送的第二信息，所述第二信息用于指示多播业务信息请求的参数信息；

所述向网络侧设备发送第一请求，包括：

根据所述第二信息，向网络侧设备发送第一请求。

5.根据权利要求4所述的方法，其特征在于，所述参数信息包括以下至少一项：多播业务信息请求的发送方式；多播业务信息请求的发送资源；多播业务信息请求的最大发送次数；多播业务信息请求的发送间隔；多播业务信息请求对应的定时器的运行时长；多播业务信息请求的发送功率爬升步长。

6.根据权利要求5所述的方法，其特征在于，所述多播业务信息请求的发送方式，包括以下至少一项：

通过四步随机接入过程中的消息1发送多播业务信息请求；

通过四步随机接入过程中的消息3发送多播业务信息请求；

通过两步随机接入过程中的消息A发送多播业务信息请求；

通过专用信令发送多播业务信息请求；

通过专用资源发送多播业务信息请求。

7.根据权利要求5所述的方法，其特征在于，所述第二信息为第一对象和第二对象分别指示不同的发送资源；或，所述第二信息为第一对象和第二对象指示相同的发送资源；

其中，所述第一对象为空闲态或非激活态终端的多播业务信息请求，所述第二对象为连接态终端的多播业务信息请求；或，所述第一对象为多播业务的控制信息请求，所述第二对象为多播业务的数据信息请求。

8.根据权利要求1所述的方法，其特征在于，所述向网络侧设备发送第一请求，包括：

在确定所述网络侧设备的所述目标信息处于按需请求状态的情况下，向网络侧设备发送第一请求。

9.根据权利要求8所述的方法，其特征在于，在第一条件满足的情况下，确定所述网络侧设备的所述目标信息处于按需请求状态；

其中，所述第一条件满足包括以下任一项：

在第一调度位置未检测到所述目标信息，所述第一调度位置为所述网络侧设备的所述目标信息的调度位置；

接收到所述网络侧设备发送的第三信息，所述第三信息指示所述网络侧设备的所述目标信息处于按需请求状态。

10.根据权利要求1所述的方法，其特征在于，所述向网络侧设备发送第一请求，包括以下任一项：

通过四步随机接入过程中的消息1向网络侧设备发送第一前导码，所述第一前导码与所述第一请求对应；

通过四步随机接入过程中的消息3向网络侧设备发送第一无线资源控制RRC信令，所述第一RRC信令携带所述第一请求；

通过两步随机接入过程中的消息A向网络侧设备发送第二RRC信令，所述第二RRC信令携带所述第一请求；

向网络侧设备发送第三RRC信令，所述第三RRC信令携带所述第一请求。

11.根据权利要求1所述的方法，其特征在于，所述接收所述目标信息，包括：

在第一时刻接收所述目标信息；

其中，所述第一时刻满足以下任一项：

所述第一时刻为：所述终端发送所述第一请求后的第一个所述目标信息的发送时刻；

所述第一时刻为：第一周期中所述目标信息的发送时刻；

其中，在所述目标信息为控制信息的情况下，所述第一周期为所述终端发送所述第一请求后的第一个所述目标信息的修改周期；在所述目标信息为数据信息的情况下，所述第一周期为所述终端发送所述第一请求后的第一个所述目标信息的调度周期。

12.根据权利要求1所述的方法，其特征在于，在所述终端处于空闲态或非激活态的情况下，所述方法还包括：

执行第一操作，所述第一操作用于控制所述终端进入连接态；

接收所述目标信息。

13.根据权利要求12所述的方法，其特征在于，所述执行第一操作之前，所述方法还包括：

接收所述网络侧设备发送的第四信息，所述第四信息用于指示以下任一项：

所述终端执行所述第一操作；

所述网络侧设备禁止连接态终端发送多播业务信息请求；

所述网络侧设备禁止所有终端发送多播业务信息请求。

14.根据权利要求1所述的方法，其特征在于，所述向网络侧设备发送第一请求之后，所述接收所述目标信息之前，所述方法还包括：

确定所述网络侧设备是否成功接收到所述第一请求；

所述接收所述目标信息，包括：

在确定所述网络侧设备成功接收到所述第一请求的情况下，接收所述目标信息。

15.根据权利要求14所述的方法，其特征在于，所述确定所述网络侧设备是否成功接收到所述第一请求，包括以下至少一项：

在所述终端通过四步随机接入过程中的消息1发送所述第一请求的情况下，确定是否接收到第一前导码的标识，所述第一前导码与所述第一请求对应；

在所述终端通过四步随机接入过程中的消息3发送所述第一请求的情况下，确定是否成功接收到消息4；

在所述终端通过两步随机接入过程中的消息A发送所述第一请求的情况下，确定是否成功接收到消息B；

在所述终端通过专用信令发送所述第一请求的情况下，确定是否接收到所述网络侧设备针对所述第一请求发送的确认信息。

16.根据权利要求14所述的方法，其特征在于，所述确定所述网络侧设备是否成功接收到所述第一请求之后，所述方法还包括以下至少一项：

在确定所述网络侧设备成功接收到所述第一请求的情况下，执行第二操作；

其中，所述第二操作包括以下任一项：

重新发送所述第一请求；

在所述第一请求的发送次数未达到最大发送次数的情况下，重新发送所述第一请求；

在所述第一请求的发送次数达到最大发送次数的情况下，执行重建或重选操作。

17.根据权利要求14所述的方法，其特征在于，所述确定所述网络侧设备是否成功接收到所述第一请求之后，所述方法还包括：

在确定所述网络侧设备成功接收到所述第一请求，且所述终端未接收到所述目标信息的情况下，执行第三操作；

其中，所述第三操作包括以下任一项：

在等待第一时长之后，重新发送所述第一请求；

在确定所述目标信息处于挂起状态的情况下，停止发送所述第一请求；

在确定所述目标信息处于按需请求状态的情况下，重新发送所述第一请求；

执行第一操作，所述第一操作用于控制所述终端进入连接态。

18.一种业务处理方法，由网络侧设备执行，其特征在于，所述方法包括：

接收终端发送的第一请求，所述第一请求用于请求目标信息，所述目标信息与多播业务相关，所述目标信息包括控制信息和数据信息中的至少一项；

向所述终端发送所述目标信息；

所述接收终端发送的第一请求之前，所述方法还包括：

向所述终端发送第一信息，所述第一信息用于指示所述网络侧设备是否支持多播业务信息请求功能。

19.根据权利要求18所述的方法，其特征在于，所述网络侧设备是否支持多播业务信息请求功能，包括以下至少一项：

所述网络侧设备是否支持多播业务信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务信息请求；

所述网络侧设备是否支持连接态终端的多播业务信息请求；

所述网络侧设备是否支持多播业务的控制信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务的控制信息请求；

所述网络侧设备是否支持连接态终端的多播业务的控制信息请求；

所述网络侧设备是否支持多播业务的数据信息请求；

所述网络侧设备是否支持空闲态或非激活态终端的多播业务的数据信息请求；

所述网络侧设备是否支持连接态终端的多播业务的数据信息请求。

20.根据权利要求18所述的方法，其特征在于，所述第一信息满足以下任一项：

所述第一信息为与多播业务相关的信息；

所述第一信息用于指示多播业务信息请求的参数信息；

所述第一信息用于指示多播业务的目标信息处于按需请求状态。

21.根据权利要求18所述的方法，其特征在于，所述接收终端发送的第一请求之前，所述方法还包括：

向所述终端发送第二信息，所述第二信息用于指示多播业务信息请求的参数信息。

22.根据权利要求21所述的方法，其特征在于，所述参数信息包括以下至少一项：多播业务信息请求的发送方式；多播业务信息请求的发送资源；多播业务信息请求的最大发送次数；多播业务信息请求的发送间隔；多播业务信息请求对应的定时器的运行时长；多播业务信息请求的发送功率爬升步长。

23.根据权利要求22所述的方法，其特征在于，所述多播业务信息请求的发送方式，包括以下至少一项：

通过四步随机接入过程中的消息1发送多播业务信息请求；

通过四步随机接入过程中的消息3发送多播业务信息请求；

通过两步随机接入过程中的消息A发送多播业务信息请求；

通过专用信令发送多播业务信息请求；

通过专用资源发送多播业务信息请求。

24.根据权利要求22所述的方法，其特征在于，所述第二信息为第一对象和第二对象分别指示不同的发送资源；或，所述第二信息为第一对象和第二对象指示相同的发送资源；

其中，所述第一对象为空闲态或非激活态终端的多播业务信息请求，所述第二对象为连接态终端的多播业务信息请求；或，所述第一对象为多播业务的控制信息请求，所述第二对象为多播业务的数据信息请求。

25.根据权利要求18所述的方法，其特征在于，所述接收终端发送的第一请求之前，所述方法还包括：

向所述终端发送第三信息，所述第三信息指示所述网络侧设备的所述目标信息处于按需请求状态。

26.根据权利要求18所述的方法，其特征在于，所述接收终端发送的第一请求，包括以下任一项：

通过四步随机接入过程中的消息1接收终端发送的第一前导码，所述第一前导码与所述第一请求对应；

通过四步随机接入过程中的消息3接收终端发送的第一无线资源控制RRC信令，所述第一RRC信令携带所述第一请求；

通过两步随机接入过程中的消息A接收终端发送的第二RRC信令，所述第二RRC信令携带所述第一请求；

接收终端发送的第三RRC信令，所述第三RRC信令携带所述第一请求。

27.根据权利要求18所述的方法，其特征在于，所述向所述终端发送所述目标信息，包括：

在第一时刻向所述终端发送所述目标信息；

其中，所述第一时刻满足以下任一项：

所述第一时刻为：所述终端发送所述第一请求后的第一个所述目标信息的发送时刻；

所述第一时刻为：第一周期中所述目标信息的发送时刻；

其中，在所述目标信息为控制信息的情况下，所述第一周期为所述终端发送所述第一请求后的第一个所述目标信息的修改周期；在所述目标信息为数据信息的情况下，所述第一周期为所述终端发送所述第一请求后的第一个所述目标信息的调度周期。

28.根据权利要求18所述的方法，其特征在于，所述向所述终端发送所述目标信息，包括以下任一项：

向所述终端发送N次所述目标信息之后，停止向所述终端发送所述目标信息，N为正整数；

向所述终端发送第二时长的所述目标信息之后，停止向所述终端发送所述目标信息；

向所述终端发送M个第二周期的所述目标信息之后，停止向所述终端发送所述目标信息，其中，在所述目标信息为控制信息的情况下，所述第二周期为修改周期，在所述目标信息为数据信息的情况下，所述第二周期为调度周期，M为正整数。

29.根据权利要求18所述的方法，其特征在于，在所述终端处于空闲态或非激活态的情况下，所述方法还包括：

向所述终端发送第四信息，所述第四信息用于指示以下任一项：

所述终端执行第一操作，所述第一操作用于控制所述终端进入连接态；

所述网络侧设备禁止连接态终端发送多播业务信息请求；

所述网络侧设备禁止所有终端发送多播业务信息请求。

30.一种业务处理装置，其特征在于，所述业务处理装置包括：

第一发送模块，用于向网络侧设备发送第一请求，所述第一请求用于请求目标信息，所述目标信息与多播业务相关，所述目标信息包括控制信息和数据信息中的至少一项；

第一接收模块，用于接收所述目标信息；

所述业务处理装置还包括：

第二接收模块，用于接收所述网络侧设备发送的第一信息，所述第一信息用于指示所述网络侧设备是否支持多播业务信息请求功能；

所述第一发送模块，具体用于在所述第一信息指示所述网络侧设备支持所述多播业务信息请求功能的情况下，向网络侧设备发送第一请求。

31.根据权利要求30所述的业务处理装置，其特征在于，所述业务处理装置还包括：

第三接收模块，用于接收网络侧设备发送的第二信息，所述第二信息用于指示多播业务信息请求的参数信息；

所述第一发送模块，具体用于根据所述第二信息，向网络侧设备发送第一请求。

32.根据权利要求30所述的业务处理装置，其特征在于，所述第一发送模块，具体用于以下任一项：

通过四步随机接入过程中的消息1向网络侧设备发送第一前导码，所述第一前导码与所述第一请求对应；

通过四步随机接入过程中的消息3向网络侧设备发送第一无线资源控制RRC信令，所述第一RRC信令携带所述第一请求；

通过两步随机接入过程中的消息A向网络侧设备发送第二RRC信令，所述第二RRC信令携带所述第一请求；

向网络侧设备发送第三RRC信令，所述第三RRC信令携带所述第一请求。

33.一种业务处理装置，其特征在于，所述业务处理装置包括：

第五接收模块，用于接收终端发送的第一请求，所述第一请求用于请求目标信息，所述目标信息与多播业务相关，所述目标信息包括控制信息和数据信息中的至少一项；

第二发送模块，用于向所述终端发送所述目标信息；

所述业务处理装置还包括：

第三发送模块，用于向所述终端发送第一信息，所述第一信息用于指示网络侧设备是否支持多播业务信息请求功能。

34.根据权利要求33所述的业务处理装置，其特征在于，所述业务处理装置还包括：

第四发送模块，用于向所述终端发送第二信息，所述第二信息用于指示多播业务信息请求的参数信息。

35.根据权利要求33所述的业务处理装置，其特征在于，所述第五接收模块，具体用于以下任一项：

通过四步随机接入过程中的消息1接收终端发送的第一前导码，所述第一前导码与所述第一请求对应；

通过四步随机接入过程中的消息3接收终端发送的第一无线资源控制RRC信令，所述第一RRC信令携带所述第一请求；

通过两步随机接入过程中的消息A接收终端发送的第二RRC信令，所述第二RRC信令携带所述第一请求；

接收终端发送的第三RRC信令，所述第三RRC信令携带所述第一请求。

36.根据权利要求33所述的业务处理装置，其特征在于，所述第二发送模块，具体用于以下任一项：

向所述终端发送N次所述目标信息之后，停止向所述终端发送所述目标信息，N为正整数；

向所述终端发送第二时长的所述目标信息之后，停止向所述终端发送所述目标信息；

向所述终端发送M个第二周期的所述目标信息之后，停止向所述终端发送所述目标信息，其中，在所述目标信息为控制信息的情况下，所述第二周期为修改周期，在所述目标信息为数据信息的情况下，所述第二周期为调度周期，M为正整数。

37.一种通信设备，其特征在于，包括处理器，存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如权利要求1至17中任一项所述的业务处理方法的步骤，或，实现如权利要求18至29中任一项所述的业务处理方法的步骤。

38.一种可读存储介质，其特征在于，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如权利要求1至17中任一项所述的业务处理方法的步骤，或，实现如权利要求18至29中任一项所述的业务处理方法的步骤。

Images