CN117812544A - 一种通信方法及通信装置 - Google Patents

Abstract

一种通信方法及通信装置，该方法包括：终端设备确定连接恢复请求消息的原因值，向服务网络设备发送连接恢复请求消息。连接恢复请求消息包括所述原因值。之后，终端设备接收来自服务网络设备的第一消息，并在RRC非激活状态接收来自服务网络设备的组播业务。其中，第一消息用于通知终端设备保持在RRC非激活状态。针对被配置RRC非激活状态接收组播业务的终端设备来说，向服务网络设备提供请求连接恢复的原因值，从而服务网络设备根据该原因值向第二网络设备提供用于确定终端设备是否需要恢复连接。第二网络设备确定终端设备无需恢复连接，可指示终端设备保持在RRC非激活状态。通过该方法，可减少不必要的终端设备上下文迁移。

Description

一种通信方法及通信装置

技术领域

本申请涉及组播业务技术领域，尤其涉及一种通信方法及通信装置。

背景技术

处于无线资源控制(radio resource control，RRC)非激活(inactive)状态的终端设备可以通过连接恢复转入RRC连接(connecte)状态。例如，处于RRC非激活状态的终端设备需要从服务基站接收组播业务时，请求服务基站恢复连接。服务基站从锚点基站获取该终端设备的上下文。锚点基站向服务基站反馈终端设备的上下文，以实现终端设备的连接恢复。

在可能的场景中，基站可能可以为处于RRC非激活状态的终端设备提供组播业务。这种情况下，如果锚点基站还是默认将终端设备的上下文迁移到服务基站，会造成不必要的终端设备上下文迁移。

发明内容

本申请提供一种通信方法及通信装置，用于减少必不要的终端设备上下文迁移。

第一方面，本申请实施例提供一种通信方法，该方法可由通信装置执行，该通信装置可以是通信设备或能够支持通信设备实现该方法所需功能的通信装置。示例性地，该通信装置为终端设备，或者为设置在终端设备中的芯片系统，或者为用于实现终端设备的功能的其他部件。为方便描述，下面以所述通信装置为终端设备为例，描述第一方面提供的通信方法。下文中的终端设备被配置在RRC非激活状态接收组播业务，且终端设备当前处于RRC非激活状态。

所述通信方法包括：终端设备确定连接恢复请求消息的原因值，向第一网络设备发送连接恢复请求消息。其中，连接恢复请求消息包括所述原因值。之后，终端设备接收来自第一网络设备的第一消息，并在RRC非激活状态接收来自第一网络设备的组播业务。其中，第一消息用于通知终端设备保持在RRC非激活状态。

第一网络设备为终端设备的服务网络设备，第二网络设备为终端设备的锚点网络设备。在本申请实施例中，对于被配置RRC非激活状态接收组播业务的终端设备来说，该终端设备在需要接收组播业务的情况下，向第一网络设备发送的连接恢复请求消息包括请求连接恢复的原因值，从而第一网络设备根据该原因值向第二网络设备提供用于确定终端设备是否需要恢复连接的信息。在确定终端设备无需恢复连接，可指示终端设备保持在RRC非激活状态。通过该方法，可减少终端设备不必要的连接恢复，即减少不必要的终端设备上下文迁移。

在可能的实现方式中，终端设备确定连接恢复请求消息的原因值，包括如下几种情况：

情况一，终端设备有组播业务数据需要传输，且第一网络设备的小区能够为处于RRC非激活状态的终端设备提供组播业务，终端设备确定原因值为第一原因值。

情况二，第一网络设备的小区不能为处于RRC非激活状态的终端设备提供组播业务，终端设备确定原因值为第二原因值。或者，终端设备有单播业务需要传输，终端设备确定原因值为第二原因值。

情况三，终端设备接收来自第一网络设备的第一通知消息，终端设备确定原因值为第三原因值，该第一通知消息用于通知终端设备针对组播业务发送连接恢复请求消息。

情况四，终端设备接收来自第一网络设备的第二通知消息，终端设备确定原因值为第四原因值，该第二通知消息用于指示对接收组播业务且处于RRC非激活状态的终端设备进行计数。

上述第二原因值可以为已经定义的由于需要传输数据而发起连接恢复请求消息的原因值。第一原因值、第三原因值以及第四原因值相较于第二原因值是新定义的原因值。通过新定义的原因值，能够使得第一网络设备明确终端设备请求连接恢复的具体原因，从而辅助第一网络设备明确终端设备是否需要恢复连接。

在可能的实现方式中，终端设备向第一网络设备发送连接恢复请求消息，包括：满足如下任意一种或多种条件，终端设备向第一网络设备发送连接恢复请求消息。

条件一，第一网络设备的小区不能为处于RRC非激活状态的终端设备提供组播业务。

条件二，终端设备从第一网络设备的小区无法获取终端设备所加入的组播业务的传输配置信息。

条件三，第一网络设备的小区能够为处于RRC非激活状态的终端设备提供组播业务，终端设备从第一网络设备的小区无法获取终端设备所加入的组播业务的传输配置信息。

条件四，终端设备接收第一网络设备的第一通知消息。

条件五，终端设备接收第一网络设备的第二通知消息。

当终端设备满足上述的一种或多种条件，终端设备发送连接恢复请求消息。当终端设备不满足某个条件，终端设备无需发起连接恢复，例如，第一网络设备的小区能够为处于RRC非激活状态的终端设备提供组播业务，且终端设备从第一网络设备的小区可以获取终端设备所加入的组播业务的传输配置信息。这种情况下，终端设备即使处于RRC非激活状态，也能够接收来自第一网络设备的组播业务。通过该方法，可减少终端设备发不必要的连接恢复流程。

在可能的实现方式中，所述方法还包括：终端设备根据第一网络设备的小区的系统消息或多播控制信道(multimedia control channel，MCCH)确定第一网络设备的小区是否能够为处于RRC非激活状态的终端设备提供组播业务。该系统消息包括用于指示第一网络设备的小区是否支持RRC非激活状态的组播业务的指示信息。该方案提供了终端设备确定第一网络设备的小区是否支持RRC非激活状态的组播业务的两种方式。例如，第一网络设备可通过系统消息或MCCH来直接或间接指示第一网络设备的小区是否支持RRC非激活状态的组播业务。

在可能的实现方式中，终端设备根据第一网络设备的小区的MCCH确定第一网络设备的小区是否能够为处于RRC非激活状态的终端设备提供组播业务，包括：第一网络设备的小区的MCCH包括针对组播业务的配置信息，终端设备确定第一网络设备的小区能够为处于RRC非激活状态的终端设备提供组播业务。如果MCCH包括针对组播业务的部分配置信息或者全部配置信息，那么隐含指示第一网络设备的小区支持RRC非激活状态的组播业务；如果MCCH不包括针对组播业务的配置信息，那么隐含指示第一网络设备的小区不支持RRC非激活状态的组播业务。

第二方面，本申请实施例提供一种通信方法，该方法可由通信装置执行，该通信装置可以是通信设备或能够支持通信设备实现该方法所需功能的通信装置。示例性地，该通信装置为网络设备，或者为设置在网络设备中的芯片系统，或者为用于实现终端设备的功能的其他部件。为方便描述，下面以所述通信装置为第一网络设备为例，描述第二方面提供的通信方法。

所述通信方法包括：第一网络设备接收来自终端设备的连接恢复请求消息，该连接恢复请求消息包括终端设备的标识信息以及原因值；第一网络设备根据该原因值向终端设备的第二网络设备发送上下文获取请求消息，该上下文获取请求消息用于获取终端设备的上下文，终端设备被配置在RRC非激活状态接收组播业务；第一网络设备接收来自第二网络设备发送的第一消息，该第一消息用于通知终端设备保持在RRC非激活状态。

终端设备向第一网络设备提供请求连接恢复的原因值，从而第一网络设备可根据该原因值确定向第二网络设备发送的上下文获取请求消息包含的内容，以使得第二网络设备明确终端设备是否可以保持在RRC非激活状态。如果终端设备可以保持在RRC非激活状态，第二网络设备向第一网络设备指示终端设备保持在RRC非激活状态，无需反馈终端设备的上下文，从而减少终端设备的上下文不必要的迁移。

在可能的实现方式中，终端设备恢复连接的原因不同，连接恢复请求消息包括的原因值也不同，包括如下几种情况。

情况一，终端设备有组播业务数据需要传输，且第一网络设备能够为处于RRC非激活状态的终端设备提供组播业务，原因值为第一原因值。

情况二，第一网络设备不能为处于RRC非激活状态的终端设备提供组播业务，原因值为第二原因值。

情况三，终端设备接收来自第一网络设备的第一通知消息，原因值为第三原因值。该第一通知消息用于通知终端设备针对组播业务发送连接恢复请求消息。

情况四，终端设备接收来自第一网络设备的第二通知消息，原因值为第四原因值。该第二通知消息用于指示对接收组播业务的处于RRC非激活状态的终端设备进行计数。

在可能的实现方式中，上下文获取请求消息包括如下的一种或多种信息：第一信息、第二信息、第三信息、第四信息、第一原因值、第三原因值或第四原因值。其中，第一信息用于指示第一网络设备能够为处于RRC非激活状态的终端设备提供组播业务。第二信息包括第一网络设备能够为处于RRC非激活状态的终端设备提供的组播业务列表的信息。第三信息包括第一网络设备能够为处于RRC非激活状态的终端设备提供的组播业务列表中的组播业务的传输配置参数。第四信息用于指示第一网络设备期望终端设备继续保持在RRC非激活状态。

第一网络设备可根据终端设备发送的连接恢复请求消息包括的原因值，确定上下文获取请求消息的内容。例如，上下文获取请求消息包括第一信息或第一原因值，使得第二网络设备确定第一网络设备的小区能够为处于RRC非激活状态的终端设备提供组播业务，从而第二网络设备无需向第一网络设备迁移终端设备的上下文。又例如，上下文获取请求消息包括第二信息，使得第二网络设备确定是否向第一网络设备指示终端设备加入的组播业务，从而使得第一网络设备确定终端设备接收组播业务是否需要恢复连接，如果无需恢复连接，那么指示终端设备保持在RRC非激活状态。

在可能的实现方式中，所述方法还包括：第一网络设备根据连接恢复请求消息包括的第一原因值，确定上下文获取请求消息包括第一信息、第二信息或第三信息中的一个或者多个。或者，第一网络设备根据连接恢复请求消息包括的第三原因值，确定上下文获取请求消息包括第四信息。

在可能的实现方式中，第一网络设备接收来自第二网络设备发送的第一消息，包括：第一网络设备接收来自第二网络设备发送的上下文获取失败消息，该上下文获取失败消息包括第一消息。第一网络设备可复用上下文获取失败消息指示终端设备保持在RRC非激活状态，无需改变目前连接恢复流程。

在可能的实现方式中，第一消息包括终端设备加入的组播业务的传输参数信息，或者，上下文获取失败消息包括终端设备加入的组播业务的传输参数信息或者终端设备加入的组播业务列表。第二网络设备通过上下文获取失败消息可向第一网络设备提供终端设备加入的组播业务的传输参数信息或者终端设备加入的组播业务列表，以使得第一网络设备明确终端设备是否需要恢复连接。从而第一网络设备根据组播业务的传输参数信息向终端设备发送组播业务。

在可能的实现方式中，所述方法还包括：原因值为第四原因值，第一网络设备接收来自第二网络设备的终端设备加入的组播业务的信息；第一网络设备根据终端设备加入的组播业务对接入第一网络设备提供的组播业务的终端设备进行计数。通过对接入第一网络设备提供的组播业务的终端设备进行计数，在确定第一网络设备能够支持更多个终端设备接入时，可以适应性控制某个或某些终端设备恢复连接，从而提高组播业务传输的可靠性。

第三方面，本申请实施例提供一种通信方法，该方法可由通信装置执行，该通信装置可以是通信设备或能够支持通信设备实现该方法所需功能的通信装置。示例性地，该通信装置为网络设备，或者为设置在网络设备中的芯片系统，或者为用于实现终端设备的功能的其他部件。为方便描述，下面以所述通信装置为第二网络设备为例，描述第三方面提供的通信方法。

所述通信方法包括：第二网络设备接收来自第一网络设备的上下文获取请求消息，该上下文获取请求消息用于获取终端设备的上下文，该终端设备被配置在RRC非激活状态接收组播业务；第二网络设备确定第一网络设备能够为终端设备提供所需接收的组播业务，第二网络设备通过第一网络设备向终端设备发送第一消息，该第一消息用于通知终端设备继续保持在RRC非激活状态。

在可能的实现方式中，在第二网络设备通过第一网络设备向终端设备发送第一消息之前，所述方法还包括：第二网络设备向第一网络设备发送上下文获取失败消息，该上下文获取失败消息包括第一消息。

在可能的实现方式中，第一消息包括终端设备加入的组播业务的传输参数配置信息，或者，上下文获取失败消息包括终端设备加入的组播业务的传输参数配置信息。

在可能的实现方式中，上下文获取请求消息包括如下的一种或多种：第一信息、第二信息、第三信息、第四信息、第一原因值、第三原因值或第四原因值。其中，第一信息用于指示第一网络设备能够为处于RRC非激活状态的终端设备提供组播业务。第二信息包括第一网络设备能够为处于RRC非激活状态的终端设备提供的组播业务列表的信息。第三信息包括第一网络设备能够为处于RRC非激活状态的终端设备提供的组播业务列表中的组播业务的传输配置参数。第四信息用于指示第一网络设备期望终端设备继续保持在RRC非激活状态。

在可能的实现方式中，上下文获取请求消息包括第四原因值，该第一消息包括终端设备加入的组播业务的信息。

关于第三方面及其实现方式的有益效果可以参考对第一方面或第二方面及其实现方式的有益效果的描述。

第四方面，本申请实施例提供了一种通信装置，所述通信装置具有实现上述第一方面、第二方面或第三方面方法实施例中行为的功能，相应地，有益效果可以参见第一方面、第二方面或第三方面的描述，此处不再赘述。

该通信装置可以是第一方面中的终端设备，或者该通信装置可以是能够实现第一方面提供的方法的装置，例如芯片或芯片系统。在一个可能的设计中，该通信装置包括用于执行第一方面的方法的相应手段(means)或模块。例如，所述通信装置：包括处理单元(有时也称为处理模块或处理器)和/或收发单元(有时也称为收发模块或收发器)。收发单元可包括发送单元和接收单元，也可以理解为，发送单元和接收单元是同一个功能模块。或者，收发单元也理解为是发送单元和接收单元的统称，发送单元和接收单元可以是不同的功能模块。这些单元(模块)可以执行上述第一方面方法示例中的相应功能，具体参见方法示例中的详细描述，此处不做赘述。

该通信装置可以是第二方面中的第一网络设备，或者该通信装置可以是能够实现第二方面提供的方法的装置，例如芯片或芯片系统。在一个可能的设计中，该通信装置包括用于执行第二方面的方法的相应手段(means)或模块。例如，所述通信装置：包括处理单元(有时也称为处理模块或处理器)和/或收发单元(有时也称为收发模块或收发器)。收发单元可包括发送单元和接收单元，也可以理解为，发送单元和接收单元是同一个功能模块。或者，收发单元也理解为是发送单元和接收单元的统称，发送单元和接收单元可以是不同的功能模块。这些单元(模块)可以执行上述第二方面方法示例中的相应功能，具体参见方法示例中的详细描述，此处不做赘述。

该通信装置可以是第三方面中的第二网络设备，或者该通信装置可以是能够实现第三方面提供的方法的装置，例如芯片或芯片系统。在一个可能的设计中，该通信装置包括用于执行第二方面的方法的相应手段(means)或模块。例如，所述通信装置：包括处理单元(有时也称为处理模块或处理器)和/或收发单元(有时也称为收发模块或收发器)。收发单元可包括发送单元和接收单元，也可以理解为，发送单元和接收单元是同一个功能模块。或者，收发单元也理解为是发送单元和接收单元的统称，发送单元和接收单元可以是不同的功能模块。这些单元(模块)可以执行上述第三方面方法示例中的相应功能，具体参见方法示例中的详细描述，此处不做赘述。

第五方面，本申请实施例提供一种通信装置，该通信装置可以为上述第四方面的通信装置，或者为设置在第四方面中的通信装置中的芯片或芯片系统。该通信装置可以为终端设备或第一网络设备或第二网络设备。该通信装置包括通信接口以及处理器，可选的，还包括存储器。其中，该存储器用于存储计算机程序，处理器与存储器、通信接口耦合，当处理器读取所述计算机程序或指令时，使通信装置执行上述方法中由终端设备或第一网络设备或第二网络设备所执行的方法。

第六方面，本申请实施例提供了一种通信装置，该通信装置包括输入输出接口和逻辑电路。输入输出接口用于输入和/或输出信息。逻辑电路用于执行第一方面中的任意一个方面中所述的方法。或者，逻辑电路用于执行第二方面中的任意一个方面中所述的方法。或者，逻辑电路用于执行第三方面中的任意一个方面中所述的方法。

第七方面，本申请实施例提供了一种芯片系统，该芯片系统包括处理器，还可以包括通信接口，用于实现第一方面或第二方面或第三方面中所述的方法。在一种可能的实现方式中，所述芯片系统还包括存储器，用于保存计算机程序。该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。

第八方面，本申请实施例提供了一种通信系统，所述通信系统包括用于实现第一方面或第二方面或第三方面相关功能的终端设备和网络设备。当然，所述通信系统可以包括更多终端设备或更多网络设备。

第九方面，本申请提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，当该计算机程序被运行时，实现上述第一方面或第二方面或第三方面中的方法。

第十方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码被运行时，使得上述第一方面或第二方面或第三方面中的方法被执行。

上述第四方面至第十方面及其实现方式的有益效果可以参考对第一方面至第三方面及其实现方式的有益效果的描述。

附图说明

图1为本申请实施例适用的通信系统的一示例性的架构图；

图2为本申请实施例提供的组播业务的架构示意图；

图3为本申请实施例适用的通信系统的一示例性的架构图；

图4为本申请实施例提供的终端设备恢复连接的一种过程示意图；

图5为本申请实施例提供的终端设备恢复连接的另一种过程示意图；

图6为本申请实施例提供的第一种通信方法的流程示意图；

图7为本申请实施例提供的第二种通信方法的流程示意图；

图8为本申请实施例提供的第三种通信方法的流程示意图；

图9为本申请实施例提供的通信装置的一种结构示意图；

图10为本申请实施例提供的通信装置的另一种结构示意图。

具体实施方式

本申请的实施例提供的技术方案可以应用于新无线(new radio，NR)系统，或者应用于长期演进(long term evolution，LTE)系统物联网(internet of things，IoT)系统、窄带物联网(narrow band internet of things，NB-IoT)系统中，或者还可以应用于下一代移动通信系统或其他类似的通信系统，具体的不做限制。

请参考图1，为本申请实施例适用的通信系统的一示例性的架构图，该通信系统可包括核心网设备、网络设备和至少一个终端设备。如图1以一个终端设备为例。终端设备通过无线的方式与网络设备相连，网络设备通过无线或有线方式与核心网设备连接。核心网设备与网络设备可以是独立的不同的物理设备；或者核心网设备的功能与网络设备的逻辑功能集成在同一个物理设备上；又或者部分核心网设备的功能和部分的网络设备的功能集成在同一个物理设备上。需要说明的是，图1只是示意，本申请的实施例对该移动通信系统中包括的核心网设备、网络设备和终端设备的数量不做限定。在一些实施例中，该通信系统还可以包括其它网络设备，例如服务器，可以为终端设备提供业务数据。

其中，网络设备可以是终端设备通过无线方式接入到移动通信系统中的接入设备，例如包括接入网(access network，AN)设备，例如基站。网络设备也可以是指在空口与终端设备通信的设备。网络设备可以包括下一代节点B(next-generation Node B，gNB)、传输接收点(transmission reception point，TRP)、演进型节点B(evolved Node B，eNB)、无线网络控制器(radio network controller，RNC)、节点B(Node B，NB)、基站控制器(basestation controller，BSC)、基站收发台(base transceiver station，BTS)、家庭基站(例如，home evolved NodeB，或home Node B，HNB)、基带单元(base band unit，BBU)，或无线保真(wireless fidelity，Wifi)接入点(access point，AP)等。本申请实施例中网络设备的名称可以是中继节点(relay node，RN)，中继传输接收点(relay transmission andreceptio point，rTRP)、车载设备以及未来演进的公共陆地移动网络(Public LandMobile Network，PLMN)设备、D2D网络中的设备、M2M网络中的设备、物联网IoT网络中的设备或者PLMN网络中的网络设备等。本申请的实施例对网络设备所采用的具体技术和具体设备形态不做限定。

另外，本申请实施例中的基站可以包括CU和分布式单元(distributed unit，DU)，多个DU可以由一个CU集中控制，也可以称之为CU与至少一个DU连接。这种结构可以将通信系统中网络设备的协议层拆开，其中部分协议层放在CU集中控制，剩下部分或全部协议层功能分布在DU中，由CU集中控制DU。CU与DU物理上可以通过光纤连接，逻辑上存在一个专门定义的F1接口，用于CU与DU之间进行通信。从功能的角度，CU主要负责无线资源控制与配置，跨小区移动性管理，承载管理等；DU主要负责调度，物理信号生成与发送。

以基站为gNB为例，gNB的协议层包括无线资源控制(radio resource control，RRC)层、业务数据适配协议(service data adaptation protocol，SDAP)层、分组数据汇聚协议(packet data convergence protocol，PDCP)层、无线链路控制(radio linkcontrol，RLC)层、媒体访问控制子层(media access control，MAC)层和物理层(physicallayer，PHY)。其中，示例性的，CU可以用于实现RRC层、SDAP层和PDCP层的功能，DU可以用于实现RLC层、MAC层和物理层的功能。需要说明的是，这种协议层的划分仅仅是一种举例，还可以在其它协议层划分。射频装置可以拉远，不放在DU中，也可以集成在DU中，或者部分拉远部分集成在DU中，本申请实施例不作任何限制。另外，本申请实施例不对CU、DU包括的协议栈做具体限定。在一些实施例中，还可以将CU的控制面(control plan，CP)和用户面(user plan，UP)分离，分成不同实体来实现，分别为控制面CU实体(CU-CP实体)和用户面CU实体(CU-UP实体)。CU的控制面CU-CP还包括一种进一步切分的架构，即把现有的CU-CP进一步切分为CU-CP1和CU-CP2。其中CU-CP1包括各种无线资源管理功能，CU-CP2仅包括无线资源控制(radio resource control，RRC)功能和PDCP-C功能(即控制面信令在PDCP层的基本功能)。在本文中，网络设备均指的是基站。

本申请实施例中，用于实现网络设备功能的通信装置可以是网络设备，也可以是能够支持网络设备实现该功能的装置，例如芯片系统，该装置可以被安装在网络设备中。在本申请实施例提供的技术方案中，以用于实现网络设备的功能的装置是网络设备，描述本申请实施例提供的技术方案。

终端设备是一种具有无线收发功能的设备，可以向网络设备发送信号，或接收来自网络设备的信号。终端设备可包括用户设备(user equipment，UE)，有时也称为终端、接入站、UE站、远方站、无线通信设备、或用户装置等等。所述终端设备用于连接人，物，机器等，可广泛用于各种场景，例如包括但不限于以下场景：蜂窝通信、设备到设备(device todevice，D2D)、车与外界(vehicle-to-everything，V2X)、机器到机器/机器类通信(machine-to-machine/machine-type communications，M2M/MTC)、IoT、虚拟现实(virtualreality，VR)、增强现实(augmented reality，AR)、工业控制(industrial control)、无人驾驶(self driving)、远程医疗(remote medical)、智能电网(smart grid)、智能家具、智能办公、智能穿戴、智能交通、智慧城市(smart city)、无人机、机器人等场景中的终端设备。

作为示例而非限定，在本申请的实施例中，该终端设备还可以是可穿戴设备。可穿戴设备也可以称为穿戴式智能设备或智能穿戴式设备等，是应用穿戴式技术对日常穿戴进行智能化设计、开发出可以穿戴的设备的总称，如眼镜、手套、手表、服饰及鞋等。而如上介绍的各种终端设备，如果位于车辆上(例如放置在车辆内或安装在车辆内)，都可以认为是车载终端设备，车载终端设备例如也称为车载单元(on-board unit，OBU)。本申请的终端设备还可以是作为一个或多个部件或者单元而内置于车辆的车载模块、车载模组、车载部件、车载芯片或者车载单元，车辆通过内置的所述车载模块、车载模组、车载部件、车载芯片或者车载单元可以实施本申请的方法。

本申请实施例中，用于实现终端设备功能的通信装置可以是终端设备，也可以是能够支持终端设备实现该功能的装置，例如芯片系统，该装置可以被安装在终端设备中。在本申请实施例提供的技术方案中，以用于实现终端设备的功能的装置是终端设备为例，描述本申请实施例提供的技术方案。

核心网主要用于对终端设备进行管理，并提供与网络设备通信的功能。核心网设备可包括以下中的一个或多个网元：接入和移动管理功能(access and mobilitymanagement function，AMF)、会话管理功能(session management function，SMF)、用户面功能(user plane function，UPF)、策略控制功能(policy control function，PCF)、统一数据管理(unified data management，UDM)网元。关于各个网元的用途此处不作赘述。需要说明的是，在不同的通信系统中，上述核心网中的网元可以有不同的名称。上述是以NR系统为例进行说明的，并不作为对本申请的限定。

在本申请实施例中，对于名词的数目，除非特别说明，表示“单数名词或复数名词”，即"一个或多个”。“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A,B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。例如，A/B，表示：A或B。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a,b,或c中的至少一项(个)，表示：a,b,c,a和b,a和c,b和c,或a和b和c，其中a,b,c可以是单个，也可以是多个。

本申请实施例提及“第一”、“第二”等序数词是用于对多个对象进行区分，不用于限定多个对象的大小、内容、顺序、时序、应用场景、优先级或者重要程度等。例如，“第一原因值”和“第二原因值”是表示存在两个原因值，并不表示这两个原因值的优先级或者重要程度等不同。

本申请实施例涉及组播业务的传输。组播业务，也可以称为多播业务，指面向多个终端设备的业务，例如现场直播、定时播放节目等。组播业务是针对较高服务质量(Qualityof Service，QoS)需求的业务设计的，通过针对组播业务进行组管理，可以提供和单播业务相同的QoS等级。在LTE中，多播业务也称为多媒体广播多播(multimedia broadcastmulticast service，MBMS)业务，在NR中，多播业务也称为组播/多播广播(multicastbroadcast service，MBS)业务。

请参见图2，为组播业务的架构示意图。如图2所示，服务器可以为终端设备提供业务数据，服务器将多播业务数据发送给核心网设备，然后核心网设备将多播业务数据发送给基站，最后基站将多播业务数据发送给接收多播业务数据的至少一个终端设备。图2以至少一个终端设备包括终端设备1和终端设备2为例。

核心网设备可以对组播业务进行组管理(group management)，也就是管理终端设备加入组或者退出组。在核心网设备与基站之间建立的协议数据单元(protocol dataunit，PDU)会话(session)引入MBS QoS流(flow)，核心网设备通过PDU session将多播业务数据发送给基站，再由基站发送给至少一个终端设备。其中，基站可以可通过为终端设备建立的专用承载点到点(point to point，PTP)传输方式将多播业务数据发送给终端设备；也可以通过为多播业务建立的专用承载以点到多点(point to multi-point，PTM)传输方式将多播业务数据发送给终端设备。另外，基站也可以在PTP传输方式和PTM传输方式之间切换。

如图3所示，对于MBS业务来说，核心网设备可以通过一个公共的传输通道MBS会话将MBS业务数据发送给基站。每个MBS会话中包括至少一个MBS QoS flow。基站通过MBS无线承载将MBS业务数据发送给至少一个终端设备。其中，基站可以以PTM传输方式将MBS业务数据发送给至少一个终端设备(如图3中的终端设备1-终端设备3)，也可以以PTP方式将MBS业务数据发送给至少一个终端设备(如图3中的终端设备4)。

组播业务提供给处于RRC连接状态(记为RRC_CONNECTED)的终端设备，这就需要终端设备保持在RRC连接状态。基站和核心网设备维护多播业务组对应的终端设备的信息。然而，基站的容量有限，也就是，基站能够支持驻留在RRC连接状态的终端设备的数量有限。基于此，期望处于RRC inactive状态(记为RRC_INACTIVE)的终端设备也能够接收组播业务。换句话说，组播业务也可以提供给处于RRC Inactive态的终端设备。这样，当基站不足以支持所接入的终端设备时，可以将一部分终端设备从RRC连接状态转移到RRC Inactive状态。

在终端设备从RRC_CONNECTED释放到RRC_INACTIVE时，基站会给该终端设备分配一个标识非激活状态无线网络临时标识(inactive radio network temporaryidentifier，I-RNTI)，并且以此标识存储终端设备的上下文。该基站是为终端设备最后服务的基站，也称为最后服务基站或者锚点(anchor)基站。终端设备和核心网之间的连接会保存在锚点基站。锚点基站控制终端设备进入RRC非激活状态，并且为终端设备分配终端设备的上下文标识，以及管理区域信息(RAN通知区(RAN notification area，RNA))。终端设备移出管理区域，则需通知RAN节点(也就是基站)；如果终端设备在管理区域内移动，可以不通知所述RAN节点。

当终端设备从RRC非激活状态请求恢复连接时，终端设备可向当前的基站发送RRCResume Request消息。当然，如果RNA有更新时，终端设备也向基站发送RRC ResumeRequest消息。

请参见图4，为终端设备恢复连接的一种过程示意图。如图4所示，终端设备恢复连接的过程可以包括如下步骤：

S41、终端设备向服务基站发送连接恢复请求(RRC Resume Request)消息。

S42、服务基站向锚点基站发送上下文(context)获取请求(RETRIEVE UE CONTEXTREQUEST)消息。

S43、锚点基站向服务基站发送上下文获取响应(RETRIEVE UE CONTEXTRESPONSE)消息。上下文获取响应消息包括终端设备的上下文。

S44、服务基站向终端设备发送RRC恢复(RRC Resume)消息。

服务基站收到终端设备的上下文，根据终端设备的上下文进行RRC恢复消息，并向终端设备发送RRC恢复消息。

S45、终端设备恢复RRC连接，进入RRC连接状态。

S46、终端设备向服务基站发送RRC恢复完成(RRC Resume Complete)消息。

终端设备恢复RRC连接之后，向服务基站发送RRC恢复完成消息，以使得服务基站确定终端设备处于RRC连接态。之后，服务基站可向核心网设备发送路径切换过程，将终端设备和核心网之间的连接切换到该服务基站，完成终端设备的连接恢复。即执行S47-S49。

S47、服务基站向核心网设备发送路径切换请求(PATH SWITCH REQUEST)消息。

S48、核心网设备向服务基站发送路径切换请求响应(PATH SWITCH REQUESTRESPONSE)消息。

S49、服务基站向核心网设备发送终端设备上下文释放(UE CONTEXT RELEASE)消息。

终端设备在无需进入RRC连接状态时，也可以请求恢复连接。例如，当RNA有更新，终端设备也可以触发恢复连接请求。这种情况下，终端设备没有业务数据需要传输，锚点基站可以选择将终端设备释放到RRC非激活状态，无需迁移终端设备的上下文，自然也无需改变终端设备的状态。

例如，请参见图5，为终端设备恢复连接的另一种过程示意图。如图5所示，终端设备恢复连接的过程可以包括如下步骤：

S51、终端设备在确定RNA更新时，向服务基站发送连接恢复请求(RRC ResumeRequest)消息。

S52、服务基站向锚点基站发送上下文(context)获取请求(RETRIEVE UE CONTEXTREQUEST)消息。

S53、锚点基站向服务基站发送上下文获取失败(RETRIEVE UE CONTEXT FAILURE)消息。上下文获取失败消息不包括终端设备的上下文或包括部分上下文信息。

S54、服务基站向终端设备发送RRC释放(RRC Release)消息。

针对处于RRC非激活状态的终端设备，基站可以通过广播等方式通知终端设备如何接收组播业务数据。例如，基站可向终端设备广播用于接收组播业务数据的配置信息。网络部署的多个基站，有的基站可以为处于RRC非激活状态的终端设备提供组播业务，有的基站不能为处于RRC非激活状态的终端设备提供组播业务。随着终端设备的移动，终端设备无法确定当前的服务基站是否能够为处于RRC非激活状态的终端设备提供组播业务，因此，终端设备会发起连接恢复。但是服务基站可能可以为处于RRC非激活状态的终端设备提供组播业务，如果锚点基站不知道服务基站是否可以为处于RRC非激活状态的终端设备提供组播业务。按照图4所示流程，终端设备发起连接恢复，锚点基站会默认将终端设备的上下文迁移到服务基站，会造成不必要的终端设备的上下文迁移。

针对上述问题，本申请实施例提供的方案中，服务基站可以确定终端设备连接恢复的原因，以确定终端设备是否需要连接恢复。如果服务基站确定终端设备无需连接恢复，那么服务基站通知锚点基站终端设备可以保持在RRC非激活状态，从而锚点基站无需将终端设备的上下文迁移到服务基站，减少不必要的终端设备的上下文迁移。应理解，服务基站指的是终端设备当前所连接的基站。锚点基站指的是在服务基站之前为终端设备提供服务的最后一个基站，锚点基站保存终端上下文并保存所述终端设备和核心网设备间的连接。在本文中，“第一网络设备”与“服务网络设备”或“服务基站”可替换，“第二网络设备”与“锚点网络设备”或“锚点基站”可替换。本申请实施例提供的方案可以应用于处于RRC非激活状态的终端设备，也可以应用于处于RRC空闲(idle)态的终端设备。如无特殊说明，本申请实施例中的“RRC非激活状态”可替换为“RRC空闲态”。下文以处于RRC非激活状态的终端设备为例，描述本申请实施例提供的方案。

终端设备在RRC非激活状态进行小区重选或者小区选择，在确定目标小区后，可向服务基站发起连接恢复。终端设备在需要接收来自服务基站的数据时，也可向服务基站发送连接恢复请求消息。在本申请实施例中，满足如下任意一种或多种条件，向服务基站发送连接恢复请求消息。

条件一，服务基站的小区不能为处于RRC非激活状态的终端设备提供组播业务。即终端设备确定服务基站的小区不能为处于RRC非激活状态的终端设备提供组播业务，但是终端设备需要接收组播业务时，终端设备可向服务基站发送连接恢复请求消息，以便终端设备进入RRC连接态，接收组播业务。具体终端设备如何确定服务基站的小区是否能够为处于RRC非激活状态的终端设备提供组播业务将在下文中介绍。

条件二，终端设备从服务基站的小区无法获取终端设备所加入的组播业务的传输配置信息。也就是，终端设备不发送连接恢复请求消息，而是先从服务基站的小区获取终端设备所加入的组播业务的传输配置信息。如果终端设备从服务基站的小区无法获取终端设备所加入的组播业务的传输配置信息，说明终端设备无法接收来自服务基站的组播业务。这种情况下，终端设备需要接收组播业务时，向服务基站发送连接恢复请求消息。具体终端设备如何从服务基站的小区获取终端设备所加入的组播业务的传输配置信息将在下文中介绍。

条件三，服务基站的小区能够为处于RRC非激活状态的终端设备提供组播业务，终端设备在RRC非激活状态无法直接从服务基站的小区无法获取终端设备所加入的组播业务的传输配置信息。类似条件二，即使服务基站的小区能够为处于RRC非激活状态的终端设备提供组播业务，如果终端设备在RRC非激活状态从服务基站的小区无法获取终端设备所加入的组播业务的传输配置信息，说明终端设备不进入RRC连接态，还是无法实现组播业务的接收。因此，满足条件三时，终端设备确定向服务基站发送连接恢复请求消息。

条件四，终端设备接收服务基站的第一通知消息，该第一通知消息用于通知终端设备针对组播业务发送连接恢复请求消息。例如，服务基站确定接入的终端设备数量较少的情况下，服务基站通过第一通知消息通知处于RRC非激活状态的终端设备需要接收组播业务时发起连接恢复请求消息。终端设备接收第一通知消息，确定向服务基站发送连接恢复请求消息。

条件五，终端设备接收服务基站的第二通知消息，该第二通知消息用于指示对接收组播业务且处于RRC非激活状态的终端设备进行计数。例如，第二通知消息用于指示服务基站对接收组播业务且处于RRC非激活状态的终端设备进行计数，服务基站通过对接收组播业务且处于RRC非激活状态的终端设备进行计数，可确定后续可能接入的终端设备，从而根据自身能力确定是否允许某个或某些终端设备接入服务基站。这种情况下，服务基站通过第二通知消息通知处于RRC非激活状态且接收组播业务的终端设备发起连接恢复请求消息。终端设备接收第二通知消息，确定向服务基站发送连接恢复请求消息。

条件六，终端设备在每次更换小区时需要发送连接恢复请求消息。

示例性的，终端设备在确定目标小区之后，可判断是否满足如上述的一种或多种条件，从而确定是否向服务基站发送连接恢复请求消息。例如，终端设备可判断是否满足条件一至条件六中的任一条件，如果满足，那么终端设备确定向服务基站发送连接恢复请求消息。又例如，终端设备可判断是否满足条件一，如果不满足条件一，终端设备继续判断是否满足条件二或条件三，如果满足，那么终端设备确定向服务基站发送连接恢复请求消息。

下面首先介绍终端设备如何确定服务基站的小区是否能够为处于RRC非激活状态的终端设备提供组播业务。

在本申请实施例中，服务基站可直接或间接指示服务基站是否能够为处于RRC非激活状态的终端设备提供组播业务。

示例性的，服务基站可广播系统消息，该系统消息包括用于指示服务网络设备的小区是否支持RRC非激活状态的组播业务的指示信息。终端设备接收系统消息，根据系统消息中的指示信息可明确服务基站是否能够为处于RRC非激活状态的终端设备提供组播业务。或者，系统消息没有指示可以配置组播业务的MCCH，那么隐含指示服务基站不能为处于RRC非激活状态的终端设备提供组播业务。系统消息可以是主系统信息块(masterinformation block，MIB)、系统信息块(system information block，SIB)1或其他系统信息(other system information，OSI)等。

示例性的，服务基站发送的MCCH包括针对组播业务的配置信息，终端设备确定服务网络设备的小区能够为处于RRC非激活状态的终端设备提供组播业务；或者，服务网络设备的小区的MCCH包括针对组播业务的部分配置信息，终端设备确定服务网络设备的小区能够为处于RRC非激活状态的终端设备提供组播业务。如果MCCH包括针对组播业务的部分或者全部配置信息，那么隐含指示服务网络设备的小区支持RRC非激活状态的组播业务；如果MCCH不包括针对组播业务的配置信息，那么隐含指示服务网络设备的小区不支持RRC非激活状态的组播业务。

终端设备从服务基站的小区获取终端设备所加入的组播业务的传输配置信息，包括如下三种获取方式。

获取方式一，终端设备通过专用信令从锚点基站的小区获取终端设备所加入的组播业务的传输配置信息。其中，专用信令，例如包括RRC连接释放或者RRC连接重配消息。

例如，终端设备在RRC连接释放时或者在RRC连接释放之前从锚点基站获取包括区域的信息。或者，终端设备在RRC连接重配时或者在RRC连接重配之前从锚点基站获取包括区域的信息。该区域信息包括小区列表、RNA信息或TA信息中的一种或多种信息，以及所述区域信息所包含的小区对终端设备加入的组播业务的传输配置信息。如果服务基站的小区不在所述区域信息所包含的小区内，则终端设备确定无法从服务基站的小区获取终端设备所加入的组播业务的传输配置信息。这种情况下，终端设备确定向服务基站发送连接恢复请求消息。如果服务基站的小区在所述区域信息所包含的小区内，则终端设备确定能够从服务基站的小区获取终端设备所加入的组播业务的传输配置信息。这种情况下，终端设备无需向服务基站发送连接恢复请求消息。

获取方式二，终端设备通过公共信令从服务基站的小区获取终端设备所加入的组播业务的传输配置信息。其中，公共信令，例如为MCCH、系统消息或寻呼消息等。

例如，终端设备接收服务基站的当前小区的MCCH或广播的系统消息。MCCH或系统消息可包括服务基站针对处于RRC非激活状态的终端设备提供或支持的组播业务的传输配置信息。如果终端设备从接收的MCCH或系统消息读取不到终端设备所加入的组播业务的传输配置信息，则终端设备确定无法从服务基站的小区获取终端设备所加入的组播业务的传输配置信息。这种情况下，终端设备确定向服务基站发送连接恢复请求消息。如果终端设备从接收的MCCH或系统消息能够读取到终端设备所加入的组播业务的传输配置信息，则终端设备确定能够从服务基站的小区获取终端设备所加入的组播业务的传输配置信息。这种情况下，终端设备确定无需向服务基站发送连接恢复请求消息。

获取方式三，终端设备通过公共信令和专用信令从服务基站的小区获取终端设备所加入的组播业务的传输配置信息。

例如，终端设备通过专用信令从锚点基站收到配置参数集合1，通过服务基站的当前小区的公共信令收到配置参数集合2。配置参数集合1包括各个组播业务的部分传输配置信息，例如，配置参数集合1包括至少一个配置索引，每个配置索引指示一个组播业务的部分传输配置参数。部分传输配置参数，例如包括组无线网络临时标识(group radionetwork temporary identifier，G-RNTI)、多播无线承载(multicast radio bearer，MRB)配置信息、PDSCH配置参数等一种或多种参数。配置参数集合2包括各个组播业务的部分传输配置信息。例如，配置参数集合2包括各个组播业务的标识信息，以及各个组播业务的参数配置索引。可选地，配置参数集合2还可以包括各个组播业务的其他传输配置参数，例如包括PDSCH配置参数、速率匹配参数等。

终端设备根据配置参数集合1和配置参数集合2确定是否可以获取服务基站的小区针对终端设备所加入的组播业务的传输配置信息。例如，终端设备确定所加入的组播业务的标识信息位于配置参数集合2所包括的标识信息内，且该标识信息在配置参数集合2中对应的配置索引位于配置参数集合1中的至少一个配置索引，那么终端设备确定能够从服务基站的小区获取终端设备所加入的组播业务的传输配置信息。这种情况下，终端设备确定无需向服务基站发送连接恢复请求消息。相反，如果终端设备确定所加入的组播业务的标识信息不在配置参数集合2所包括的标识信息内，那么终端设备确定不能从服务基站的小区获取终端设备所加入的组播业务的传输配置信息。这种情况下，终端设备确定需要向服务基站发送连接恢复请求消息。或者，终端设备确定所加入的组播业务的标识信息在配置参数集合2所包括的标识信息内，但是该标识信息在配置参数集合2中对应的配置索引不属于配置参数集合1中的至少一个配置索引，那么终端设备确定不能从服务基站的小区获取终端设备所加入的组播业务的传输配置信息。这种情况下，终端设备确定向服务基站发送连接恢复请求消息。

为了让服务基站明确终端设备发起连接恢复请求消息的原因，该连接恢复请求消息包括终端设备发起连接恢复请求消息的原因值。在本申请实施例中，连接恢复请求消息的原因值可能为如下的第一原因值、第二原因值、第三原因值或第四原因值。针对不同的场景，连接恢复请求消息的原因值不同，包括如下几种情况。

情况一，终端设备有组播业务数据需要传输，且服务基站的小区能够为处于RRC非激活状态的终端设备提供组播业务，连接恢复请求消息的原因值为第一原因值。该第一原因值可以是新定义的原因值。具体的，所述组播业务为终端设备被配置在RRC非激活状态接收的组播业务。终端设备有组播业务数据需要传输包括终端设备仅有组播业务数据并且没有单播业务数据要发送。例如，终端设备需要接收所述组播业务时，且终端设备确定服务基站的小区能够为处于RRC非激活状态的终端设备提供组播业务，那么终端设备确定连接恢复请求消息的原因值为第一原因值。具体的，第一原因值可以为“仅有RRC非激活状态组播业务”，或者“仅有组播业务”等。

情况二，服务基站的小区不能为处于RRC非激活状态的终端设备提供组播业务，连接恢复请求消息的原因值为第二原因值。或者，终端设备有单播业务需要传输，连接恢复请求消息的原因值为第二原因值。第二原因值即为已经定义的由于需要传输数据而发起连接恢复请求消息的原因值。例如，终端设备有单播业务需要传输，连接恢复请求消息的原因值为第二原因值。在本申请实施例中，服务基站的小区不能为处于RRC非激活状态的终端设备提供组播业务，终端设备确定连接恢复请求消息的原因值可复用已经定义的第二原因值。例如，第二原因值可以为“数据传输”或者“信令传输”等。

情况三，终端设备接收来自服务基站的第一通知消息，连接恢复请求消息的原因值为第三原因值，该第一通知消息用于通知终端设备针对组播业务发送连接恢复请求消息。该第三原因值可以是新定义的原因值。例如，服务基站确定接入的终端设备数量较少的情况下，服务基站通过第一通知消息通知处于RRC非激活状态的终端设备需要接收组播业务时发起连接恢复请求消息。终端设备接收第一通知消息，确定发起连接恢复请求消息的原因值为第三原因值。具体的，第三原因值可以为“响应组播业务接入”。

情况四，终端设备接收来自服务基站的第二通知消息，连接恢复请求消息的原因值为第四原因值，该第二通知消息用于指示对接收组播业务且处于RRC非激活状态的终端设备进行计数。该第四原因值可以是新定义的原因值。例如，服务基站需要对接收组播业务且处于RRC非激活状态的终端设备进行计数时，服务基站通过第二通知消息通知处于RRC非激活状态且接收组播业务的终端设备发起连接恢复请求消息。终端设备接收第二通知消息，确定发起连接恢复请求消息的原因值为第四原因值。具体的，第四原因值可以为“组播计数响应”。

在可能的实现方式中，在已定义的第二原因值的基础上，可新定义第一原因值、第三原因值或第四原因值。或者，在已定义的第二原因值的基础上，可新预定义第一原因值、第三原因值和第四原因值中的多个原因值。

为方便理解本申请提供的技术方案，下面结合附图以具体的示例详细介绍本申请提供的技术方案。在下文的介绍中，以本申请实施例提供的通信方法应用于图1所示的网络架构为例。本申请实施例描述的网络架构以及应用场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着网络架构的演变和新应用场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

另外，该方法可由三个通信装置执行，这三个通信装置例如为第一通信装置、第二通信装置和第三通信装置。为了便于介绍，在下文中，以该方法由终端设备、服务基站和锚点基站执行为例，也就是，以第一通信装置是终端设备、第二通信装置是服务基站，第三通信装置是锚点基站为例。如下的实施例中，终端设备是被配置在RRC非激活状态接收组播业务的终端设备。例如，终端设备被配置在RRC非激活状态接收组播业务1。

请参见图6，为本申请实施例提供的第一种通信方法的流程示意图。在图6的场景中，终端设备没有目标小区的组播业务的传输配置。

S601、终端设备确定连接恢复请求消息的原因值。

终端设备确定需要接收来自服务基站的组播业务，终端设备确定向服务基站发送连接恢复请求消息。为了让服务基站明确终端设备发起连接恢复的原因，终端设备可确定连接恢复请求消息携带的原因值。如前述，终端设备需要接收组播业务时，且终端设备确定服务基站的小区能够为处于RRC非激活状态的终端设备提供组播业务，那么终端设备确定连接恢复请求消息的原因值为第一原因值。如果终端设备有单播业务需要传输终端设备确定，连接恢复请求消息的原因值为第二原因值。考虑到不支持向处于RRC非激活状态的终端提供组播业务的基站可能是没有升级的基站，无法识别第二原因值，如果服务基站的小区不能为处于RRC非激活状态的终端设备提供组播业务，终端设备确定连接恢复请求消息的原因值为第二原因值。这样可以避免终端设备向没有升级的基站发送第二原因值导致该基站无法处理RRC恢复的原因。

可选地，如果终端设备需要接收组播业务时，且终端设备确定服务基站的小区能够为处于RRC非激活状态的终端设备提供组播业务，且终端设备移出了RNA区域。这种情况下，连接恢复请求消息的原因值也为第一原因值。

S602、终端设备向服务基站发送连接恢复请求消息，相应的，服务基站接收终端设备发送的连接恢复请求消息，该连接恢复请求消息包括原因值。

终端设备向服务基站发送的连接恢复请求消息包括原因值，还可以包括终端设备的标识信息。终端设备的标识信息可以让服务基站明确请求连接恢复的是哪个终端设备，从而可以判断服务基站是否是该终端设备的锚点基站。根据服务基站是否是终端设备的锚点基站，服务基站后续的行为有所不同。例如，如果服务基站不是终端设备的锚点基站，后续服务基站可执行S603A；如果服务基站是终端设备的锚点基站，后续服务基站可执行S603B。其中，S603A和S603B可以择一执行，图6以执行S603A为例，因此，S603B用虚线示意。连接恢复请求消息中的原因值，可使得服务基站明确终端设备请求连接恢复的原因，从而使得服务基站根据该原因值确定终端设备是否需要恢复连接。例如，如果服务基站确定终端设备无需恢复连接，可指示终端设备保持在RRC非激活状态，可减少终端设备不必要的连接恢复，即减少不必要的终端设备上下文迁移。

S603A、服务基站向锚点基站发送上下文获取请求消息，相应的，锚点基站接收来自服务基站的上下文获取请求消息。

服务基站确定终端设备的连接恢复请求消息，可向锚点基站发送上下文获取请求消息，以请求获取终端设备的上下文。应理解，该上下文获取请求消息包括终端设备的标识信息，以使得锚点基站明确服务基站需要获取哪个终端设备的上下文。

在本申请实施例中，服务基站可根据终端设备的连接恢复请求消息的原因值，确定上下文获取请求消息包括的内容，以使得锚点基站明确终端设备是否可以保持在RRC非激活状态。如果终端设备可以保持在RRC非激活状态，锚点基站无需向服务基站反馈终端设备的上下文或者仅返回部分需要的上下文(例如终端设备加入的组播业务的信息)，从而减少不必要的终端设备上下文迁移。

示例性的，上下文获取请求消息包括如下的一种或多种信息：第一信息、第二信息、第三信息、第四信息、第一原因值、第三原因值或第四原因值。其中，第一信息用于指示服务基站能够为处于RRC非激活状态的终端设备提供组播业务。第二信息包括服务基站能够为处于RRC非激活状态的终端设备提供的组播业务列表的信息。第三信息包括服务基站能够为处于RRC非激活状态的终端设备提供的组播业务列表中的组播业务的传输配置参数。第四信息用于指示服务基站期望终端设备继续保持在RRC非激活状态。

如果连接恢复请求消息包括的原因值为第一原因值，上下文获取请求消息可包括第一信息、第二信息、第三信息或第一原因值中的一个或者多个。

例如，连接恢复请求消息包括第一原因值，上下文获取请求消息包括第一原因值。

或者，连接恢复请求消息包括第一原因值，如果服务基站自身能够为处于RRC非激活状态的终端设备提供组播业务，那么服务基站可确定上下文获取请求消息可包括第一信息。这样锚点基站接收第一信息，确定服务基站能够为处于RRC非激活状态的终端设备提供组播业务，终端设备可继续保持在RRC非激活状态。锚点基站可不向服务基站反馈终端设备的上下文。

或者，上下文获取请求消息包括服务基站能够为处于RRC非激活状态的终端设备提供的组播业务列表的信息和/或至少一个组播业务的传输配置参数，使得锚点基站根据该组播业务列表的信息确定终端设备是否可继续保持在RRC非激活状态。如果锚点基站根据指示的组播业务包括终端设备待接收的组播业务，那么锚点基站确定终端设备可继续保持在RRC非激活状态，可不向服务基站反馈终端设备的上下文。

S603B、服务基站向终端设备发送响应消息，相应的，终端设备接收服务基站发送的响应消息。

如果服务基站是终端设备的锚点基站，换句话说，终端设备没有移出服务基站的覆盖范围。这种情况下，服务基站接收终端设备发送的连接恢复请求消息，可根据连接恢复请求消息的原因值，确定让终端设备保持在RRC非激活状态，还是让终端设备进入RRC连接态。

例如，连接恢复请求消息包括第一原因值，服务基站能够为终端设备提供终端设备所需要的组播业务。这种情况下，服务基站可向终端设备发送响应消息，该响应消息包括组播业务的传输配置信息，并通知终端设备继续保持在RRC非激活状态。

又例如，连接恢复请求消息包括第二原因值，这种情况下，服务基站可向终端设备发送响应消息，该响应消息通知终端设备转入RRC连接态。

S604、锚点基站向服务基站发送针对上下文获取请求消息的回复消息，相应的，服务基站接收来自锚点基站针对上下文获取请求消息的回复消息。

锚点基站接收来自服务基站的上下文获取请求之后，可根据上下文获取请求携带的内容，确定终端设备是否可以保持在RRC非激活状态。如果锚点基站确定终端设备需要转入RRC连接态，锚点基站向服务基站发送上下文获取响应消息。即针对上下文获取请求消息的回复消息为上下文获取响应消息。该上下文获取响应消息包括终端设备的上下文以及终端设备所加入的组播业务的信息。

相反，如果终端设备可以保持在RRC非激活状态，锚点基站向服务基站发送上下文获取失败消息。即针对上下文获取请求消息的回复消息为上下文获取失败消息。该上下文获取失败消息包括第一消息，用于通知终端设备保持在RRC非激活状态。例如，上下文获取请求包括组播业务列表的信息，锚点基站确定终端设备所加入的组播业务位于该列表中，那么锚点基站确定终端设备可以保持在RRC非激活状态，锚点基站向服务基站发送包括第一消息的上下文获取失败消息。该第一消息可以是RRC释放消息。锚点基站将包括第一消息的上下文获取失败消息发送给服务基站，便于服务基站向终端转发所述第一消息，通知终端设备保持在RRC非激活状态。

可选地，第一消息包括终端设备所加入的组播业务的传输参数信息，使得终端根据该传输参数信息向接收组播业务。该传输参数信息可以是锚点基站从上下文获取请求包括的各个组播业务的传输配置信息获得。

可选地，上下文获取失败消息还可以包括终端设备已经加入的组播业务的信息，例如，终端设备已经加入的组播业务的临时移动群组标识(temporary mobile groupidentification，TMGI)，服务基站确定TMGI对应的组播业务，根据该组播业务的传输参数信息向终端设发送组播业务。

可以理解的是，如果服务基站能够为处于RRC非激活状态的终端设备提供组播业务，但是服务基站还没建立组播业务，也就是服务基站不能为终端设备提供组播业务的传输配置信息。这种情况下，锚点基站可先请求服务基站建立终端设备请求的组播业务。例如，锚点基站在发送第一消息之前，可向服务基站发送第二消息，该第二消息用于请求服务基站建立终端设备请求的组播业务。服务基站接收第二消息，建立终端设备请求的组播业务，并向锚点基站发送第三消息。该第三消息包括该终端设备请求的组播业务的传输配置信息。

可选地，锚点基站发送第二消息之前，确定上下文获取请求消息确定服务基站是否支持或者愿意向处于RRC非激活状态的终端设备提供组播业务。如果服务基站不支持或者不愿意向处于RRC非激活状态的终端设备提供组播业务，锚点基站可不发送第二消息。

S605、服务基站向终端设备发送第一消息，该第一消息用于通知终端设备保持在RRC非激活状态。

服务基站获取第二消息之后，可向终端设备发送第一消息。该第一消息指示终端设备保持在RRC非激活状态。

在可能的实现方式中，服务基站从锚点节点接收上下文获取失败消息，从上下文获取失败消息中获取第一消息之后，将该第一消息转发给终端设备。

如果服务基站从锚点基站接收上下文获取响应消息，此时没有携带第一消息，服务基站可以向核心网发起路径切换过程，将终端设备和核心网之间的接口切换到服务基站，同时终端设备加入的组播业务的通道也相应建立起来。具体可参考前述图4的相关内容，此处不再赘述。另外，服务基站还可以根据连接恢复请求消息包括的原因值，确定终端设备是否保持在RRC非激活状态接收组播业务。例如，连接恢复请求消息包括的原因值为第一原因值，服务基站可指示终端设备继续保持在RRC非激活状态。可选地，服务基站还可以向终端设备发送终端设备所加入的组播业务的传输参数信息。换句话说，即使锚点节点向服务基站迁移了终端设备的上下文，服务基站还是可以确定将终端设备释放到RRC非激活状态。

服务基站发送第一消息之后，根据获得的终端设备所加入的组播业务的传输参数信息向终端设备发送组播业务。相应的，终端设备继续保持在RRC非激活状态，接收来自服务基站的组播业务。应理解，终端设备可以通过前述的三种获取方式中的任一种获取方式获取接收组播业务的传输参数信息。

在第一种通信方法中，终端设备明确发起连接恢复请求消息的原因值，并通知给服务基站。服务基站根据该原因值，向锚点基站提供相关的信息，例如第一信息、第一原因值、第二信息或者第三信息等，使得锚点基站确定终端设备是否可以继续保持在RRC非激活状态，以减少不必要的终端设备上下文迁移。

虽然在服务基站能够为处于RRC非激活状态的终端设备提供组播业务，但是服务基站接入的终端设备减少，服务基站可以通知处于RRC非激活状态的终端设备转入RRC连接态，以尽量保证终端设备接收组播业务的可靠性。如果后续接入服务基站的终端设备较多，对于服务基站来说，负载较重，那么对于后续处于RRC非激活状态的终端设备请求的连接恢复，服务基站可通知终端设备继续保持在RRC非激活状态。通过该方案，可平衡服务基站的负载以及终端设备接收组播业务的可靠性。

请参见图7，为本申请实施例提供的第二种通信方法的流程示意图。图7所示的场景以由于将处于RRC非激活的终端设备转入RRC连接态，服务基站确定当前负载较重为例。针对后续处于RRC非激活状态终端设备来说，服务基站确定该终端设备继续保持在RRC连接态。

S701、终端设备向服务基站发送连接恢复请求消息，相应的，服务基站接收终端设备发送的连接恢复请求消息，该连接恢复请求消息包括终端设备的标识信息以及原因值。

终端设备在发送连接恢复请求消息之前，确定连接恢复请求消息包括的原因值的确定可参考前述的相关内容，此处不再赘述。例如，该连接恢复请求消息包括的原因值为第一原因值或第三原因值。

根据服务基站是否是终端设备的锚点基站，服务基站后续的行为有所不同。例如，如果服务基站不是终端设备的锚点基站，后续服务基站可执行S702A；如果服务基站是终端设备的锚点基站，后续服务基站可执行S702B。

S702A、服务基站向锚点基站发送上下文获取请求消息，相应的，锚点基站接收来自服务基站的上下文获取请求消息。

S702A的实现可参考前述S603A的相关内容，此处不再赘述。与S603A的不同之处在于，如果连接恢复请求消息包括的原因值为第三原因值，服务基站可确定上下文获取请求消息包括第一信息、第二信息、第三信息、第四信息或第三原因值中的一个或多个。例如，服务基站可确定上下文获取请求消息包括第四信息或第三原因值。又例如，上下文获取请求消息可包括第三原因值和第四信息。

S702B、服务基站向终端设备发送响应消息，相应的，终端设备接收服务基站发送的响应消息。

S702B的具体实现可参考前述S603B的相关内容，此处不再赘述。与S603B的不同之处在于，如果连接恢复请求消息包括的原因值包括第一原因值或第三原因值，服务基站根据自身的负载确定是否让终端设备转入RRC连接态。如果服务基站确定让终端设备保持在RRC非激活状态，服务基站向终端设备发送响应消息，该响应消息包括组播业务的传输配置信息，并通知终端设备继续保持在RRC非激活状态。

S703、锚点基站向服务基站发送针对上下文获取请求消息的回复消息，相应的，服务基站接收来自锚点基站针对上下文获取请求消息的回复消息。

锚点基站接收来自服务基站的上下文获取请求之后，可根据上下文获取请求携带的内容，确定终端设备是否可以保持在RRC非激活状态。S703的具体实现可参考前述S604的相关内容，此处不再赘述。S703与S604的不同之处在于，如果上下文获取请求包括第三原因值和第四信息。锚点基站确定向服务基站发送第一消息。

S704、服务基站向终端设备发送第一消息，该第一消息用于通知终端设备保持在RRC非激活状态。

服务基站获取第一消息之后，可向终端设备发送第一消息。该第一消息指示终端设备保持在RRC非激活状态。该第一消息可为RRC释放消息。S704的具体实现可参考S605的相关内容，此处不再赘述。S704和S605的不同之处在于，如果上下文获取请求消息包括第三原因值和/或第四信息，针对上下文获取请求消息的回复消息包括的第一消息可不包括组播业务的传输参数信息。

在第二种通信方法中，终端设备明确发起连接恢复请求消息的原因值，例如接收服务基站发送的第一通知消息。辅助服务基站针对后续处于RRC非激活状态的终端设备请求的连接恢复，确定终端设备是否转入RRC连接态。从而平衡服务基站的负载以及终端设备接收组播业务的可靠性。

按照图7所示的流程，服务基站接入的终端设备减少时，服务基站可以通知处于RRC非激活状态的终端设备转入RRC连接态。如果后续有多个处于RRC非激活状态的终端设备请求连接恢复，服务基站允许这多个终端设备都转入RRC连接态，对于服务基站来说，负载较重。为此，本申请实施例还提供一种通信方法。在该方法中，服务基站在确定是否将终端设备转入RRC连接态之前，可统计处于RRC非激活状态的终端设备的数量，从而根据统计的数量控制终端设备的转态转化。

请参见图8，为本申请实施例提供的第三种通信方法。图8所示的场景以服务基站根据处于RRC非激活状态的终端设备的数量，确定终端设备是否继续保持在RRC连接态为例。

S801、服务基站向终端设备发送第二通知消息，相应的，终端设备接收来自服务基站的第二通知消息。

服务基站确定当前的负载较重时，可向终端设备发送第二通知消息，该第二通知消息用于指示服务基站需要对接收组播业务且处于RRC非激活状态的终端设备进行计数。服务基站通过对接收组播业务且处于RRC非激活状态的终端设备进行计数，确定是否允许某个或某些处于RRC非激活状态的终端设备转入RRC连接态。第二通知消息，例如为MCCH消息、系统消息或寻呼消息。

S802、终端设备向服务基站发送连接恢复请求消息，相应的，服务基站接收终端设备发送的连接恢复请求消息，该连接恢复请求消息包括终端设备的标识信息以及原因值。

终端设备在发送连接恢复请求消息之前，确定连接恢复请求消息包括的原因值的确定可参考前述的相关内容，此处不再赘述。例如，该连接恢复请求消息包括的原因值为第一原因值或第四原因值。

根据服务基站是否是终端设备的锚点基站，服务基站后续的行为有所不同。例如，如果服务基站不是终端设备的锚点基站，后续服务基站可执行S803A；如果服务基站是终端设备的锚点基站，后续服务基站可执行S803B。

S803A、服务基站向锚点基站发送上下文获取请求消息，相应的，锚点基站接收来自服务基站的上下文获取请求消息。

S803A的实现可参考前述S603A的相关内容，此处不再赘述。与S603A的不同之处在于，如果连接恢复请求消息包括的原因值为第四原因值，服务基站可确定上下文获取请求消息包括第一信息、第二信息、第三信息或第四原因值中的一个或多个。例如，服务基站可确定上下文获取请求消息包括第三信息或第四原因值。

S803B、服务基站向终端设备发送响应消息，相应的，终端设备接收服务基站发送的响应消息。

S803B的具体实现可参考前述S603B的相关内容，此处不再赘述。与S603B的不同之处在于，如果连接恢复请求消息包括的原因值包括第四原因值，服务基站还根据终端设备已经加入的组播业务统计接收服务基站提供的组播业务的终端设备的个数。即对接收服务基站提供的组播业务的终端设备进行计数，例如对接收服务基站提供的组播业务的终端设备数加1。

S804、锚点基站向服务基站发送针对上下文获取请求消息的回复消息，相应的，服务基站接收来自锚点基站针对上下文获取请求消息的回复消息。

锚点基站接收来自服务基站的上下文获取请求之后，可根据上下文获取请求消息携带的内容，执行相应的行为。例如，上下文获取请求消息包括第四原因值。S804的具体实现可参考前述S604的相关内容，此处不再赘述。S804与S604的不同之处在于，如果上下文获取请求包括第四原因，上下文获取失败消息可包括终端设备加入的组播业务的信息。从而服务基站接收上下文获取失败消息，根据上下文获取失败消息中终端设备加入的组播业务的信息，对接收服务基站提供的组播业务的终端设备进行计数。

S805、服务基站向终端设备发送第一消息，该第一消息用于通知终端设备保持在RRC非激活状态。

S805的具体实现可参考S605的相关内容，此处不再赘述。S805和S605的不同之处在于，如果服务基站确定接收服务基站提供的组播业务的终端设备的数量较多，服务基站向终端设备发送第一消息。在统计接收服务基站提供的组播业务的终端设备的数量的过程中，服务基站向终端设备发送第一消息。

在第三种通信方法中，服务基站可统计接收服务基站提供的组播业务的终端设备的数量，以辅助确定终端设备是否转入RRC连接态。在统计接收服务基站提供的组播业务的终端设备的数量的过程中，可控制终端设备继续保持在RRC非激活状态，从而尽量减轻服务基站的负载。

上述的第一种通信方法、第二种通信方法和第三种通信方法可以独立实现，也可以组合。例如，第一种通信方法和第二种通信方法可以组合，第一种通信方法和第三种通信方法也可以组合。

上述本申请提供的实施例中，分别从服务基站、锚点基站、终端设备，以及服务基站、锚点基站、终端设备之间交互的角度对本申请实施例提供的方法进行了介绍。其中，服务基站或锚点基站执行的步骤也可以由不同的通信装置来分别实现。例如：第一装置用于生成上下文获取请求消息，第二装置用于发送上下文获取请求消息，也就是说第一装置和第二装置共同完成本申请实施例中基站执行的步骤，本申请不限定具体的划分方式。当网络架构中包括一个或多个分布单元(distributed unit，DU)、一个或多个集中单元(centralized unit，CU)和一个或多个射频单元(RU)时，上述基站执行的步骤可以分别由DU、CU和RU来实现。为了实现上述本申请实施例提供的方法中的各功能，服务基站、锚点基站、终端设备可以包括硬件结构和/或软件模块，以硬件结构、软件模块、或硬件结构加软件模块的形式来实现上述各功能。上述各功能中的某个功能以硬件结构、软件模块、还是硬件结构加软件模块的方式来执行，取决于技术方案的特定应用和设计约束条件。

基于与方法实施例的同一发明构思，本申请实施例提供一种通信装置。下面结合附图介绍本申请实施例中用来实现上述方法的通信装置。

图9为本申请实施例提供的通信装置900的示意性框图。该通信装置900可以包括处理模块910和收发模块920。可选地，还可以包括存储单元，该存储单元可以用于存储指令(代码或者程序)和/或数据。处理模块910和收发模块920可以与该存储单元耦合，例如，处理模块910可以读取存储单元中的指令(代码或者程序)和/或数据，以实现相应的方法。上述各个模块可以独立设置，也可以部分或者全部集成。

一些可能的实施方式中，通信装置900能够对应实现上述方法实施例中终端设备的行为和功能，通信装置900可以为终端设备，也可以为应用于终端设备中的部件(例如芯片或者电路)，也可以是终端设备中的芯片或芯片组或芯片中用于执行相关方法功能的一部分。

例如，处理模块910用于确定连接恢复请求消息的原因值，其中，通信装置900被配置在RRC非激活状态接收组播业务。收发模块920用于：向服务基站发送连接恢复请求消息，该连接恢复请求消息包括所述原因值；接收来自服务基站的第一消息，接收来述服务基站的组播业务，该第一消息用于通知通信装置900保持在RRC非激活状态。

作为一种可选的实现方式，处理模块910具体用于：通信装置900有组播业务数据需要传输，且服务基站的小区能够为处于RRC非激活状态的通信装置提供组播业务，确定原因值为第一原因值；或者，服务基站的小区不能为处于RRC非激活状态的通信装置提供组播业务，确定原因值为第二原因值；或者，收发模块920接收来自服务基站的第一通知消息，确定原因值为第三原因值，该第一通知消息用于通知通信装置900针对组播业务发送所述连接恢复请求消息；或者，收发模块920接收来自服务基站的第二通知消息，确定原因值为第四原因值，该第二通知消息用于指示对接收组播业务且处于RRC非激活状态的通信装置进行计数。

作为一种可选的实现方式，收发模块920具体用于满足如下任意一种或多种条件，向服务基站发送连接恢复请求消息：服务基站的小区不能为处于RRC非激活状态的通信装置提供组播业务；从服务基站的小区无法获取通信装置900所加入的组播业务的传输配置信息；服务基站的小区能够为处于RRC非激活状态的通信装置提供组播业务，从服务基站的小区无法获取通信装置900所加入的组播业务的传输配置信息；接收服务基站的第一通知消息；或者，接收服务基站的第二通知消息。

作为一种可选的实现方式，处理模块910还用于根据服务基站的小区的系统消息或MCCH确定服务基站的小区是否能够为处于RRC非激活状态的通信装置提供组播业务。其中，系统消息包括用于指示服务基站的小区是否支持RRC非激活状态的组播业务的指示信息。

作为一种可选的实现方式，处理模块910具体用于：服务基站的小区的MCCH包括针对所述组播业务的配置信息，确定服务基站的小区能够为处于RRC非激活状态的通信装置提供组播业务；或者，服务基站的小区的MCCH包括针对所述组播业务的部分配置信息，确定服务基站的小区能够为处于RRC非激活状态的通信装置提供组播业务。

一些可能的实施方式中，通信装置900能够对应实现上述方法实施例中服务基站的行为和功能，通信装置900可以为网络设备，也可以为应用于网络设备中的部件(例如芯片或者电路)，也可以是网络设备中的芯片或芯片组或芯片中用于执行相关方法功能的一部分。

例如，收发模块920用于接收来自终端设备的连接恢复请求消息，该连接恢复请求消息包括终端设备的标识信息以及原因值。处理模块910用于确定所述原因值。收发模块920还用于向终端设备的锚点基站发送上下文获取请求消息，以及接收锚点基站发送的第一消息。上下文获取请求消息用于获取终端设备的上下文，该终端设备被配置在RRC非激活状态接收组播业务。第一消息用于通知终端设备保持在RRC非激活状态。

作为一种可选的实现方式，终端设备有组播业务数据需要传输，且通信装置900能够为处于RRC非激活状态的终端设备提供组播业务，所述原因值为第一原因值；或者，通信装置900不能为处于RRC非激活状态的终端设备提供组播业务，所述原因值为第二原因值；或者，终端设备接收来自通信装置900的第一通知消息，所述原因值为第三原因值，该第一通知消息用于通知终端设备针对组播业务发送连接恢复请求消息；或者，终端设备接收来自通信装置900的第二通知消息，所述原因值为第四原因值，该第二通知消息用于指示对接收组播业务的处于RRC非激活状态的终端设备进行计数。

作为一种可选的实现方式，上下文获取请求消息包括如下的一种或多种信息：第一信息、第二信息、第三信息、第四信息、第一原因值、第三原因值或第四原因值。其中，第一信息用于指示通信装置900能够为处于RRC非激活状态的终端设备提供组播业务。第二信息包括通信装置900能够为处于RRC非激活状态的终端设备提供的组播业务列表的信息。第三信息包括通信装置900能够为处于RRC非激活状态的终端设备提供的组播业务列表中的组播业务的传输配置参数。第四信息用于指示通信装置900期望终端设备继续保持在RRC非激活状态。

作为一种可选的实现方式，处理模块910还用于：根据连接恢复请求消息包括的第一原因值，确定上下文获取请求消息包括第一信息、第二信息或第三信息中的一个或者多个；或者，根据连接恢复请求消息包括的第三原因值，确定上下文获取请求消息包括第四信息。

作为一种可选的实现方式，收发模块920具体用于接收来自锚点基站发送的上下文获取失败消息，该上下文获取失败消息包括第一消息。

作为一种可选的实现方式，第一消息包括终端设备加入的组播业务的传输参数信息，或者，上下文获取失败消息包括终端设备加入的组播业务的传输参数信息或者终端设备加入的组播业务列表。

作为一种可选的实现方式，收发模块920还用于接收来自锚点基站的终端设备加入的组播业务的信息，其中，所述原因值为第四原因值；处理模块910还用于根据终端设备加入的组播业务对接入通信装置900提供的组播业务的终端设备进行计数。

一些可能的实施方式中，通信装置900能够对应实现上述方法实施例中锚点基站的行为和功能，通信装置900可以为网络设备，也可以为应用于网络设备中的部件(例如芯片或者电路)，也可以是网络设备中的芯片或芯片组或芯片中用于执行相关方法功能的一部分。

例如，收发模块920用于接收来自服务基站的上下文获取请求消息，该上下文获取请求消息用于获取终端设备的上下文，该终端设备被配置在RRC非激活状态接收组播业务。处理模块910用于确定服务基站能够为终端设备提供所需接收的组播业务。收发模块920还用于通过服务基站向终端设备发送第一消息，该第一消息用于通知终端设备继续保持在RRC非激活状态。

作为一种可选的实现方式，收发模块920还用于向服务基站发送上下文获取失败消息，该上下文获取失败消息包括第一消息。

作为一种可选的实现方式，第一消息包括终端设备加入的组播业务的传输参数配置信息，或者，上下文获取失败消息包括终端设备加入的组播业务的传输参数配置信息。

作为一种可选的实现方式，上下文获取请求消息包括如下的一种或多种：第一信息、第二信息、第三信息、第四信息、第一原因值、第三原因值或第四原因值。其中，第一信息用于指示服务基站能够为处于RRC非激活状态的终端设备提供组播业务。第二信息包括服务基站能够为处于RRC非激活状态的终端设备提供的组播业务列表的信息。第三信息包括服务基站能够为处于RRC非激活状态的终端设备提供的组播业务列表中的组播业务的传输配置参数。第四信息用于指示服务基站期望终端设备继续保持在RRC非激活状态。

作为一种可选的实现方式，上下文获取请求消息包括第四原因值，第一消息包括终端设备加入的组播业务的信息。

应理解，本申请实施例中的处理模块910可以由处理器或处理器相关电路组件实现，收发模块920可以由收发器或收发器相关电路组件或者通信接口实现。

图10为本申请实施例提供的通信装置1000的示意性框图。其中，该通信装置1000可以是终端设备，能够实现本申请实施例提供的方法中终端设备的功能。通信装置1000也可以是能够支持终端设备实现本申请实施例提供的方法中对应的功能的装置，其中，该通信装置1000可以为芯片系统。本申请实施例中，芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。具体的功能可以参见上述方法实施例中的说明。该通信装置1000也可以是网络设备，能够实现本申请实施例提供的方法中服务基站或锚点基站的功能。通信装置1000也可以是能够支持网络设备实现本申请实施例提供的方法中对应的功能的装置，其中，该通信装置1000可以为芯片系统。本申请实施例中，芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。具体的功能可以参见上述方法实施例中的说明。

通信装置1000包括一个或多个处理器1001，可用于实现或用于支持通信装置1000实现本申请实施例提供的方法中终端设备的功能。具体参见方法示例中的详细描述，此处不做赘述。一个或多个处理器1001也可以用于实现或用于支持通信装置1000实现本申请实施例提供的方法中服务基站或锚点基站的功能。具体参见方法示例中的详细描述，此处不做赘述。处理器1001也可以称为处理单元或处理模块，可以实现一定的控制功能。处理器1001可以是通用处理器或者专用处理器等。例如，包括：中央处理器，应用处理器，调制解调处理器，图形处理器，图像信号处理器，数字信号处理器，视频编解码处理器，控制器，存储器，和/或神经网络处理器等。所述中央处理器可以用于对通信装置1000进行控制，执行软件程序和/或处理数据。不同的处理器可以是独立的器件，也可以是集成在一个或多个处理器中，例如，集成在一个或多个专用集成电路上。

可选地，通信装置1000中包括一个或多个存储器1002，用以存储指令1004，所述指令可在所述处理器1001上被运行，使得通信装置1000执行上述方法实施例中描述的方法。存储器1002和处理器1001可以单独设置，也可以集成在一起，也可以认为存储器1002和处理器1001耦合。本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。处理器1001可能和存储器1002协同操作。所述至少一个存储器中的至少一个可以包括于处理器中。需要说明的是，存储器1002不是必须的，所以在图10中以虚线进行示意。

可选地，所述存储器1002中还可以存储有数据。所述处理器和存储器可以单独设置，也可以集成在一起。在本申请实施例中，存储器1002可以是非易失性存储器，比如硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)等，还可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)。存储器是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

可选地，通信装置1000可以包括指令1003(有时也可以称为代码或程序)，所述指令1003可以在所述处理器上被运行，使得所述通信装置1000执行上述实施例中描述的方法。处理器1001中可以存储数据。

可选地，通信装置1000还可以包括收发器1005以及天线1006。所述收发器1005可以称为收发单元，收发模块、收发机、收发电路、收发器，输入输出接口等，用于通过天线1006实现通信装置1000的收发功能。

本申请中描述的处理器1001和收发器1005可实现在集成电路(integratedcircuit，IC)、模拟IC、射频集成电路(radio frequency identification，RFID)、混合信号IC、ASIC、印刷电路板(printed circuit board，PCB)、或电子设备等上。实现本文描述的通信装置，可以是独立设备(例如，独立的集成电路，手机等)，或者可以是较大设备中的一部分(例如,可嵌入在其他设备内的模块)，具体可以参照前述关于终端设备，以及网络设备的说明，在此不再赘述。

可选地，通信装置1000还可以包括以下一个或多个部件：无线通信模块，音频模块，外部存储器接口，内部存储器，通用串行总线(universal serial bus，USB)接口，电源管理模块，天线，扬声器，麦克风，输入输出模块，传感器模块，马达，摄像头，或显示屏等等。可以理解，在一些实施例中，通信装置1000可以包括更多或更少部件，或者某些部件集成，或者某些部件拆分。这些部件可以是硬件，软件，或者软件和硬件的组合实现。

需要说明的是，上述实施例中的通信装置可以是终端设备，也可以是电路，也可以是应用于终端设备中的芯片或者其他具有上述终端设备功能的组合器件、部件等。当通信装置是终端设备时，收发模块可以是收发器，可以包括天线和射频电路等，处理模块可以是处理器，例如：中央处理模块(central processing unit，CPU)。上述实施例中的通信装置可以是网络设备，也可以是电路，也可以是应用于网络设备中的芯片或者其他具有上述网络设备功能的组合器件、部件等。当通信装置是服务基站或锚点基站时，收发模块可以是收发器，可以包括天线和射频电路等，处理模块可以是处理器，例如：中央处理模块(centralprocessing unit，CPU)。当通信装置是具有上述终端设备或服务基站或锚点基站功能的部件时，收发模块可以是射频单元，处理模块可以是处理器。当通信装置是芯片系统时，该通信装置可以是现场可编程门阵列(field programmable gate array，FPGA)，可以是专用集成芯片(application specific integrated circuit，ASIC)，还可以是系统芯片(systemon chip，SoC)，还可以是CPU，还可以是网络处理器(network processor，NP)，还可以是数字信号处理电路(digital signal processor，DSP)，还可以是微控制器(microcontroller unit，MCU)，还可以是可编程控制器(programmable logic device，PLD)或其他集成芯片。处理模块可以是芯片系统的处理器。收发模块或通信接口可以是芯片系统的输入输出接口或接口电路。例如，接口电路可以为代码/数据读写接口电路。所述接口电路，可以用于接收代码指令(代码指令存储在存储器中，可以直接从存储器读取，或也可以经过其他器件从存储器读取)并传输至处理器；处理器可以用于运行所述代码指令以执行上述方法实施例中的方法。又例如，接口电路也可以为通信处理器与收发机之间的信号传输接口电路。

当该通信装置为芯片类的装置或者电路时，该装置可以包括收发单元和处理单元。其中，所述收发单元可以是输入输出电路和/或通信接口；处理单元为集成的处理器或者微处理器或者集成电路。

本申请实施例还提供一种通信系统，具体的，通信系统包括终端设备、服务基站和锚点基站。或者，该通信系统还可以包括更多个终端设备、基站。示例性的，通信系统包括用于实现上述图6-图8中一个或多个图的相关功能的终端设备、服务基站和锚点基站。具体请参考上述方法实施例中的相关描述，这里不再赘述。

本申请实施例中还提供一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行图6-图8中一个或多个图中终端设备、服务基站或锚点基站执行的方法。

本申请实施例中还提供一种计算机程序产品，包括指令，当其在计算机上运行时，使得计算机执行图6-图8中一个或多个图中终端设备、服务基站或锚点基站执行的方法。

本申请实施例提供了一种芯片系统，该芯片系统包括处理器，还可以包括存储器，用于实现前述方法中终端设备的功能；或者用于实现前述方法中服务基站或锚点基站的功能。该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。

应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各种说明性逻辑块(illustrative logical block)和步骤(step)，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (38)

1.一种通信方法，其特征在于，包括：

终端设备确定连接恢复请求消息的原因值，其中，所述终端设备被配置在无线资源控制RRC非激活状态接收组播业务，所述终端设备处于RRC非激活状态；

所述终端设备向第一网络设备发送所述连接恢复请求消息，所述连接恢复请求消息包括述原因值；

所述终端设备接收来自所述第一网络设备的第一消息，其中，所述第一消息用于通知所述终端设备保持在RRC非激活状态；

所述终端设备接收来自所述第一网络设备的组播业务。

2.如权利要求1所述的方法，其特征在于，所述终端设备确定连接恢复请求消息的原因值，包括：

所述终端设备有组播业务数据需要传输，且所述第一网络设备的小区能够为处于RRC非激活状态的终端设备提供组播业务，所述终端设备确定所述原因值为第一原因值；或者，

所述第一网络设备的小区不能为处于RRC非激活状态的终端设备提供组播业务，所述终端设备确定所述原因值为第二原因值；或者，

所述终端设备接收来自所述第一网络设备的第一通知消息，所述终端设备确定所述原因值为第三原因值，其中，所述第一通知消息用于通知所述终端设备针对组播业务发送所述连接恢复请求消息；或者，

所述终端设备接收来自所述第一网络设备的第二通知消息，所述终端设备确定所述原因值为第四原因值，其中，所述第二通知消息用于指示对接收组播业务且处于RRC非激活状态的终端设备进行计数。

3.如权利要求1或2所述的方法，其特征在于，所述终端设备向第一网络设备发送连接恢复请求消息，包括：

满足如下任意一种或多种条件，所述终端设备向所述第一网络设备发送所述连接恢复请求消息：

所述第一网络设备的小区不能为处于RRC非激活状态的终端设备提供组播业务；

所述终端设备从所述第一网络设备的小区无法获取所述终端设备所加入的组播业务的传输配置信息；

所述第一网络设备的小区能够为处于RRC非激活状态的终端设备提供组播业务，所述终端设备从所述第一网络设备的小区无法获取所述终端设备所加入的组播业务的传输配置信息；

所述终端设备接收所述第一网络设备的所述第一通知消息；

所述终端设备接收所述第一网络设备的所述第二通知消息。

4.如权利要求2或3所述的方法，其特征在于，所述方法还包括：

所述终端设备根据所述第一网络设备的小区的系统消息或多播控制信道MCCH确定所述第一网络设备的小区是否能够为处于RRC非激活状态的终端设备提供组播业务，所述系统消息包括用于指示所述第一网络设备的小区是否支持RRC非激活状态的组播业务的指示信息。

5.如权利要求4所述的方法，其特征在于，所述终端设备根据所述第一网络设备的小区的MCCH确定所述第一网络设备的小区是否能够为处于RRC非激活状态的终端设备提供组播业务，包括：

所述第一网络设备的小区的MCCH包括针对所述组播业务的配置信息，所述终端设备确定所述第一网络设备的小区能够为处于RRC非激活状态的终端设备提供组播业务。

6.一种通信方法，其特征在于，包括：

第一网络设备接收来自终端设备的连接恢复请求消息，所述连接恢复请求消息包括原因值；

所述第一网络设备根据所述原因值向所述终端设备的第二网络设备发送上下文获取请求消息，所述上下文获取请求消息用于获取所述终端设备的上下文，所述终端设备被配置在RRC非激活状态接收组播业务；

所述第一网络设备接收来自所述第二网络设备发送的第一消息，所述第一消息用于通知所述终端设备保持在RRC非激活状态。

7.如权利要求6所述的方法，其特征在于，

所述终端设备有组播业务数据需要传输，且所述第一网络设备能够为处于RRC非激活状态的终端设备提供组播业务，所述原因值为第一原因值；或者，

所述第一网络设备不能为处于RRC非激活状态的终端设备提供组播业务，所述原因值为第二原因值；或者，

所述终端设备接收来自所述第一网络设备的第一通知消息，所述原因值为第三原因值，其中，所述第一通知消息用于通知所述终端设备针对组播业务发送所述连接恢复请求消息；或者，

所述终端设备接收来自所述第一网络设备的第二通知消息，所述原因值为第四原因值，其中，所述第二通知消息用于指示对接收组播业务的处于RRC非激活状态的终端设备进行计数。

8.如权利要求7所述的方法，其特征在于，所述上下文获取请求消息包括如下的一种或多种：

第一信息，所述第一信息用于指示所述第一网络设备能够为处于RRC非激活状态的终端设备提供组播业务；

第二信息，所述第二信息包括所述第一网络设备能够为处于RRC非激活状态的终端设备提供的组播业务列表的信息；

第三信息，所述第三信息包括所述第一网络设备能够为处于RRC非激活状态的终端设备提供的组播业务列表中的组播业务的传输配置参数；

第四信息，所述第四信息用于指示所述第一网络设备期望所述终端设备继续保持在RRC非激活状态；

所述第一原因值；

所述第三原因值和第四信息，所述第四信息用于指示所述第一网络设备期望所述终端设备保持在RRC非激活状态；

所述第四原因值。

9.如权利要求8所述的方法，其特征在于，所述方法还包括：

所述第一网络设备根据所述连接恢复请求消息包括的所述第一原因值，确定所述上下文获取请求消息包括所述第一信息、所述第二信息或所述第三信息中的一个或者多个；或者，

所述第一网络设备根据所述连接恢复请求消息包括的所述第三原因值，确定所述上下文获取请求消息包括所述第四信息。

10.如权利要求6-9任一项所述的方法，其特征在于，所述第一网络设备接收来自所述第二网络设备发送的第一消息，包括：

所述第一网络设备接收来自所述第二网络设备发送的上下文获取失败消息，所述上下文获取失败消息包括所述第一消息。

11.如权利要求10所述的方法，其特征在于，所述第一消息包括所述终端设备加入的组播业务的传输参数信息，或者，所述上下文获取失败消息包括所述终端设备加入的组播业务的传输参数信息或者终端设备加入的组播业务列表。

12.如权利要求8所述的方法，其特征在于，所述方法还包括：

所述原因值为所述第四原因值，所述第一网络设备接收来自所述第二网络设备的所述终端设备加入的组播业务的信息；

所述第一网络设备根据所述终端设备加入的组播业务对接入所述第一网络设备提供的组播业务的终端设备进行计数。

13.一种通信方法，其特征在于，包括：

第二网络设备接收来自第一网络设备的上下文获取请求消息，所述上下文获取请求消息用于获取终端设备的上下文，所述终端设备被配置在RRC非激活状态接收组播业务；

所述第二网络设备确定所述第一网络设备能够为所述终端设备提供所需接收的组播业务，所述第二网络设备通过所述第一网络设备向所述终端设备发送第一消息，所述第一消息用于通知终端设备继续保持在RRC非激活状态。

14.如权利要求13所述的方法，其特征在于，在所述第二网络设备通过所述第一网络设备向所述终端设备发送第一消息之前，所述方法还包括：

所述第二网络设备向所述第一网络设备发送上下文获取失败消息，所述上下文获取失败消息包括所述第一消息。

15.如权利要求14所述的方法，其特征在于，所述第一消息包括所述终端设备加入的组播业务的传输参数配置信息，或者，所述上下文获取失败消息包括所述终端设备加入的组播业务的传输参数配置信息。

16.如权利要求13-15任一项所述的方法，其特征在于，所述上下文获取请求消息包括如下的一种或多种：

第一信息，所述第一信息用于指示所述第一网络设备能够为处于RRC非激活状态的终端设备提供组播业务；

第二信息，所述第二信息包括所述第一网络设备能够为处于RRC非激活状态的终端设备提供的组播业务列表的信息；

第三信息，所述第三信息包括所述第一网络设备能够为处于RRC非激活状态的终端设备提供的组播业务列表中的组播业务的传输配置参数；或者，

第四信息，所述第四信息用于指示所述第一网络设备期望所述终端设备继续保持在RRC非激活状态；

第一原因值，其中，所述第一原因值用于指示所述终端设备发送恢复请求的原因为终端设备有组播业务数据需要传输，且所述第一网络设备能够为处于RRC非激活状态的终端设备提供组播业务；

第三原因值，所述第三原因值用于指示所述终端设备发送恢复请求的原因为所述终端设备接收所述第一网络设备发送的第一通知消息，所述第一通知消息用于通知所述终端设备针对组播业务发送所述连接恢复请求消息；

第四原因值，所述第四原因值用于指示所述终端设备发送恢复请求的原因为所述终端设备接收所述第一网络设备发送的第二通知消息，所述第二通知消息用于指示对接收组播业务的处于RRC非激活状态的终端设备进行计数。

17.如权利要求16所述的方法，其特征在于，所述上下文获取请求消息包括所述第四原因值，所述第一消息包括所述终端设备加入的组播业务的信息。

18.一种通信装置，其特征在于，包括处理模块和收发模块；

其中，所述处理模块用于确定连接恢复请求消息的原因值，其中，所述通信装置被配置在无线资源控制RRC非激活状态接收组播业务，所述通信装置处于RRC非激活状态；

所述收发模块，用于：向第一网络设备发送所述连接恢复请求消息，所述连接恢复请求消息包括所述通信装置的标识信息以及所述原因值；

接收来自所述第一网络设备的第一消息，以及接收来自所述第一网络设备的组播业务其中，所述第一消息用于通知所述通信装置保持在RRC非激活状态。

19.如权利要求18所述的装置，其特征在于，所述处理模块具体用于：

所述通信装置有组播业务数据需要传输，且所述第一网络设备的小区能够为处于RRC非激活状态的终端设备提供组播业务，确定所述原因值为第一原因值；或者，

所述第一网络设备的小区不能为处于RRC非激活状态的终端设备提供组播业务，确定所述原因值为第二原因值；或者，

所述收发模块接收来自所述第一网络设备的第一通知消息，确定所述原因值为第三原因值，其中，所述第一通知消息用于通知所述通信装置针对组播业务发送所述连接恢复请求消息；或者，

所述收发模块接收来自所述第一网络设备的第二通知消息，确定所述原因值为第四原因值，其中，所述第二通知消息用于指示对接收组播业务且处于RRC非激活状态的通信装置进行计数。

20.如权利要求19所述的装置，其特征在于，所述收发模块具体用于：满足如下任意一种或多种条件，向所述第一网络设备发送所述连接恢复请求消息：

所述第一网络设备的小区不能为处于RRC非激活状态的通信装置提供组播业务；

从所述第一网络设备的小区无法获取所述通信装置所加入的组播业务的传输配置信息；

所述第一网络设备的小区能够为处于RRC非激活状态的通信装置提供组播业务，从所述第一网络设备的小区无法获取所述通信装置所加入的组播业务的传输配置信息；

接收所述第一网络设备的所述第一通知消息；

接收所述第一网络设备的所述第二通知消息。

21.如权利要求19或20所述的装置，其特征在于，所述处理模块还用于：

根据所述第一网络设备的小区的系统消息或多播控制信道MCCH确定所述第一网络设备的小区是否能够为处于RRC非激活状态的通信装置提供组播业务，所述系统消息包括用于指示所述第一网络设备的小区是否支持RRC非激活状态的组播业务的指示信息。

22.如权利要求21所述的装置，其特征在于，所述处理模块具体用于：

所述第一网络设备的小区的MCCH包括针对所述组播业务的配置信息，确定所述第一网络设备的小区能够为处于RRC非激活状态的终端设备提供组播业务。

23.一种通信装置，其特征在于，包括处理模块和收发模块；

其中，所述收发模块用于接收来自终端设备的连接恢复请求消息，所述连接恢复请求消息包括所述终端设备的标识信息以及原因值；

所述处理模块用于确定所述原因值；

所述收发模块，还用于向所述终端设备的第二网络设备发送上下文获取请求消息，以及接收所述第二网络设备发送的第一消息，所述上下文获取请求消息用于获取所述终端设备的上下文，所述终端设备被配置在RRC非激活状态接收组播业务，所述第一消息用于通知所述终端设备保持在RRC非激活状态。

24.如权利要求23所述的装置，其特征在于，

所述终端设备有组播业务数据需要传输，且所述通信装置能够为处于RRC非激活状态的终端设备提供组播业务，所述原因值为第一原因值；或者，

所述通信装置不能为处于RRC非激活状态的终端设备提供组播业务，所述原因值为第二原因值；或者，

所述终端设备接收来自所述通信装置的第一通知消息，所述原因值为第三原因值，其中，所述第一通知消息用于通知所述终端设备针对组播业务发送所述连接恢复请求消息；或者，

所述终端设备接收来自所述通信装置的第二通知消息，所述原因值为第四原因值，其中，所述第二通知消息用于指示对接收组播业务的处于RRC非激活状态的终端设备进行计数。

25.如权利要求24所述的装置，其特征在于，所述上下文获取请求消息包括如下的一种或多种：

第一信息，所述第一信息用于指示所述通信装置能够为处于RRC非激活状态的终端设备提供组播业务；

第二信息，所述第二信息包括所述通信装置能够为处于RRC非激活状态的终端设备提供的组播业务列表的信息；

第三信息，所述第三信息包括所述通信装置能够为处于RRC非激活状态的终端设备提供的组播业务列表中的组播业务的传输配置参数；

第四信息，所述第四信息用于指示所述通信装置期望所述终端设备继续保持在RRC非激活状态；

所述第一原因值；

所述第三原因值和第四信息，所述第四信息用于指示所述第一网络设备期望所述终端设备保持在RRC非激活状态；

所述第四原因值。

26.如权利要求25所述的装置，其特征在于，所述处理模块还用于：

根据所述连接恢复请求消息包括的所述第一原因值，确定所述上下文获取请求消息包括所述第一信息、所述第二信息或所述第三信息中的一个或者多个；或者，

根据所述连接恢复请求消息包括的所述第三原因值，确定所述上下文获取请求消息包括所述第四信息。

27.如权利要求23-26任一项所述的装置，其特征在于，所述处理模块具体用于：

接收来自所述第二网络设备发送的上下文获取失败消息，所述上下文获取失败消息包括所述第一消息。

28.如权利要求27所述的装置，其特征在于，所述第一消息包括所述终端设备加入的组播业务的传输参数信息，或者，所述上下文获取失败消息包括所述终端设备加入的组播业务的传输参数信息或者终端设备加入的组播业务列表。

29.如权利要求25所述的装置，其特征在于，所述收发模块还用于：接收来自所述第二网络设备的所述终端设备加入的组播业务的信息，其中，所述原因值为所述第四原因值；

所述处理模块还用于根据所述终端设备加入的组播业务对接入所述第一网络设备提供的组播业务的终端设备进行计数。

30.一种通信装置，其特征在于，包括处理模块和收发模块；

其中，所述收发模块用于接收来自第一网络设备的上下文获取请求消息，所述上下文获取请求消息用于获取终端设备的上下文，所述终端设备被配置在RRC非激活状态接收组播业务；

所述处理模块用于确定所述第一网络设备能够为所述终端设备提供所需接收的组播业务；

所述收发模块还用于通过所述第一网络设备向所述终端设备发送第一消息，所述第一消息用于通知终端设备继续保持在RRC非激活状态。

31.如权利要求30所述的装置，其特征在于，所述收发模块还用于向所述第一网络设备发送上下文获取失败消息，所述上下文获取失败消息包括所述第一消息。

32.如权利要求30所述的装置，其特征在于，所述第一消息包括所述终端设备加入的组播业务的传输参数配置信息，或者，所述上下文获取失败消息包括所述终端设备加入的组播业务的传输参数配置信息。

33.如权利要求29-32任一项所述的装置，其特征在于，所述上下文获取请求消息包括如下的一种或多种：

第一信息，所述第一信息用于指示所述第一网络设备能够为处于RRC非激活状态的终端设备提供组播业务；

第二信息，所述第二信息包括所述第一网络设备能够为处于RRC非激活状态的终端设备提供的组播业务列表的信息；

第三信息，所述第三信息包括所述第一网络设备能够为处于RRC非激活状态的终端设备提供的组播业务列表中的组播业务的传输配置参数；或者，

第四信息，所述第四信息用于指示所述第一网络设备期望所述终端设备继续保持在RRC非激活状态；

第一原因值，其中，所述第一原因值用于指示所述终端设备发送恢复请求的原因为终端设备有组播业务数据需要传输，且所述第一网络设备能够为处于RRC非激活状态的终端设备提供组播业务；

第三原因值和第四信息，其中，所述第三原因值用于指示所述终端设备发送恢复请求的原因为所述终端设备接收所述第一网络设备发送的第一通知消息，所述第一通知消息用于通知所述终端设备针对组播业务发送所述连接恢复请求消息，所述第四信息用于指示所述第一网络设备期望所述终端设备保持在RRC非激活状态；

第四原因值，所述第四原因值用于指示所述终端设备发送恢复请求的原因为所述终端设备接收所述第一网络设备发送的第二通知消息，所述第二通知消息用于指示对接收组播业务的处于RRC非激活状态的终端设备进行计数。

34.如权利要求33所述的装置，其特征在于，所述上下文获取请求消息包括所述第四原因值，所述第一消息包括所述终端设备加入的组播业务的信息。

35.一种通信装置，其特征在于，所述通信装置包括处理器和存储器，所述存储器用于存储计算机程序，所述处理器用于执行存储在所述存储器上的计算机程序，使得所述通信装置执行如权利要求1～5中任一项所述的方法；或者，使得所述通信装置执行如权利要求6～12中任一项所述的方法；使得所述通信装置执行如权利要求13～17中任一项所述的方法。

36.一种通信系统，其特征在于，包括终端设备、第一网络设备和第二网络设备，其中，所述终端设备用于实现如权利要求1～5中任一项所述的方法，所述第一网络设备用于实现如权利要求6～12中任一项所述的方法，所述第二网络设备用于实现如权利要求13～17中任一项所述的方法。

37.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序当被计算机执行时，使所述计算机执行如权利要求1～5中任一项所述的方法；或者，使所述计算机执行如权利要求6～12中任一项所述的方法；或者，使所述计算机执行如权利要求13～17中任一项所述的方法。

38.一种计算机程序产品，其特征在于，所述计算机程序产品存储有计算机程序，所述计算机程序当被计算机执行时，使所述计算机执行如权利要求1～5中任一项所述的方法；或者，使所述计算机执行如权利要求6～12中任一项所述的方法；或者，使所述计算机执行如权利要求13～17中任一项所述的方法。