WO2024067268A1

WO2024067268A1 - Communication method and communication apparatus

Info

Publication number: WO2024067268A1
Application number: PCT/CN2023/119838
Authority: WO
Inventors: 李秉肇; 张海森; 沙桐; 刘南南
Original assignee: 华为技术有限公司
Priority date: 2022-09-30
Filing date: 2023-09-19
Publication date: 2024-04-04
Also published as: CN117812544A

Abstract

A communication method and a communication apparatus. The method comprises: a terminal device determines a cause value of a connection resume request message and sends the connection resume request message to a serving network device, the connection resume request message comprising the cause value; the terminal device receives a first message from the serving network device and receives a multicast service from the serving network device in an RRC inactive state, the first message being used for instructing the terminal device to be kept in the RRC inactive state; the terminal device configured to receive the multicast service in the RRC inactive state provides a cause value for requesting connection resume to the serving network device, so that the serving network device provides a second network device with the cause value for whether the terminal device needs to be resume the connection; and the second network device determines that the terminal device does not need to resume the connection, and instructs the terminal device to be kept in the RRC inactive state. By means of the method, unnecessary context transfer of a terminal device can be reduced.

Description

A communication method and a communication device

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on September 30, 2022, with application number 202211231750.0 and application name “A Communication Method and Communication Device”, the entire contents of which are incorporated by reference in this application.

Technical Field

The present application relates to the technical field of multicast services, and in particular to a communication method and a communication device.

Background technique

A terminal device in the radio resource control (RRC) inactive state can enter the RRC connected state through connection recovery. For example, when a terminal device in the RRC inactive state needs to receive multicast services from the serving base station, it requests the serving base station to restore the connection. The serving base station obtains the context of the terminal device from the anchor base station. The anchor base station feeds back the context of the terminal device to the serving base station to achieve connection recovery of the terminal device.

In a possible scenario, the base station may be able to provide multicast services for terminal devices in an RRC inactive state. In this case, if the anchor base station still migrates the context of the terminal device to the serving base station by default, unnecessary terminal device context migration will be caused.

Summary of the invention

The present application provides a communication method and a communication device for reducing unnecessary terminal device context migration.

In a first aspect, an embodiment of the present application provides a communication method, which can be performed by a communication device, which can be a communication device or a communication device that can support the communication device to implement the functions required by the method. Exemplarily, the communication device is a terminal device, or a chip system provided in the terminal device, or other components for implementing the functions of the terminal device. For ease of description, the communication method provided in the first aspect is described below by taking the communication device as a terminal device as an example. The terminal device hereinafter is configured to receive multicast services in an RRC inactive state, and the terminal device is currently in an RRC inactive state.

The communication method comprises: a terminal device determines a cause value of a connection recovery request message, and sends a connection recovery request message to a first network device. The connection recovery request message includes the cause value. Afterwards, the terminal device receives a first message from the first network device, and receives a multicast service from the first network device in an RRC inactive state. The first message is used to notify the terminal device to remain in the RRC inactive state.

The first network device is a service network device of the terminal device, and the second network device is an anchor network device of the terminal device. In an embodiment of the present application, for a terminal device configured to receive multicast services in an RRC inactive state, when the terminal device needs to receive multicast services, the connection recovery request message sent to the first network device includes a reason value for requesting connection recovery, so that the first network device provides the second network device with information for determining whether the terminal device needs to restore the connection based on the reason value. When it is determined that the terminal device does not need to restore the connection, the terminal device can be instructed to remain in an RRC inactive state. Through this method, unnecessary connection recovery of terminal devices can be reduced, that is, unnecessary context migration of terminal devices can be reduced.

In a possible implementation, the terminal device determines the cause value of the connection restoration request message, including the following situations:

In case one, the terminal device has multicast service data to transmit, and the cell of the first network device can provide multicast services for the terminal device in the RRC inactive state, and the terminal device determines that the cause value is the first cause value.

In case 2, the cell of the first network device cannot provide multicast services for the terminal device in the RRC inactive state, and the terminal device determines the cause value to be the second cause value. Alternatively, the terminal device has a unicast service to transmit, and the terminal device determines the cause value to be the second cause value.

Case three, the terminal device receives a first notification message from the first network device, and the terminal device determines that the cause value is a third cause value. The first notification message is used to notify the terminal device to send a connection recovery request message for the multicast service.

Case four, the terminal device receives a second notification message from the first network device, and the terminal device determines that the cause value is a fourth cause value. The second notification message is used to indicate counting of terminal devices that receive multicast services and are in an RRC inactive state.

The second reason value may be a defined reason value for initiating a connection recovery request message due to the need to transmit data. The first reason value, the third reason value, and the fourth reason value are newly defined reason values compared to the second reason value. The newly defined reason values can make The first network device specifies the specific reason why the terminal device requests connection restoration, thereby assisting the first network device in determining whether the terminal device needs to restore the connection.

In a possible implementation, the terminal device sends a connection restoration request message to the first network device, including: when any one or more of the following conditions are met, the terminal device sends a connection restoration request message to the first network device.

Condition 1: The cell of the first network device cannot provide multicast services for terminal devices in the RRC inactive state.

Condition two: the terminal device cannot obtain the transmission configuration information of the multicast service joined by the terminal device from the cell of the first network device.

Condition three: the cell of the first network device can provide multicast services for the terminal device in the RRC inactive state, and the terminal device cannot obtain the transmission configuration information of the multicast service joined by the terminal device from the cell of the first network device.

Condition four: the terminal device receives the first notification message from the first network device.

Condition five: the terminal device receives the second notification message from the first network device.

When the terminal device meets one or more of the above conditions, the terminal device sends a connection recovery request message. When the terminal device does not meet a certain condition, the terminal device does not need to initiate connection recovery. For example, the cell of the first network device can provide multicast services for terminal devices in an RRC inactive state, and the terminal device can obtain the transmission configuration information of the multicast service joined by the terminal device from the cell of the first network device. In this case, the terminal device can receive multicast services from the first network device even if it is in an RRC inactive state. Through this method, unnecessary connection recovery processes initiated by the terminal device can be reduced.

In a possible implementation, the method further includes: the terminal device determines whether the cell of the first network device can provide multicast services for the terminal device in the RRC inactive state according to the system message or multicast control channel (MCCH) of the cell of the first network device. The system message includes indication information for indicating whether the cell of the first network device supports the multicast service in the RRC inactive state. The scheme provides two ways for the terminal device to determine whether the cell of the first network device supports the multicast service in the RRC inactive state. For example, the first network device can directly or indirectly indicate whether the cell of the first network device supports the multicast service in the RRC inactive state through a system message or MCCH.

In a possible implementation, the terminal device determines whether the cell of the first network device can provide a multicast service for the terminal device in the RRC inactive state according to the MCCH of the cell of the first network device, including: the MCCH of the cell of the first network device includes configuration information for the multicast service, and the terminal device determines that the cell of the first network device can provide a multicast service for the terminal device in the RRC inactive state. If the MCCH includes part of the configuration information or all of the configuration information for the multicast service, it implicitly indicates that the cell of the first network device supports the multicast service in the RRC inactive state; if the MCCH does not include the configuration information for the multicast service, it implicitly indicates that the cell of the first network device does not support the multicast service in the RRC inactive state.

In a second aspect, an embodiment of the present application provides a communication method, which can be performed by a communication device, which can be a communication device or a communication device that can support the communication device to implement the functions required by the method. Exemplarily, the communication device is a network device, or a chip system set in a network device, or other components for implementing the functions of a terminal device. For the convenience of description, the communication method provided by the second aspect is described below by taking the communication device as a first network device as an example.

The communication method includes: a first network device receives a connection recovery request message from a terminal device, the connection recovery request message including identification information of the terminal device and a reason value; the first network device sends a context acquisition request message to a second network device of the terminal device according to the reason value, the context acquisition request message is used to acquire the context of the terminal device, and the terminal device is configured to receive multicast services in an RRC inactive state; the first network device receives a first message sent from the second network device, and the first message is used to notify the terminal device to remain in the RRC inactive state.

The terminal device provides the first network device with a reason value for requesting connection recovery, so that the first network device can determine the content of the context acquisition request message sent to the second network device according to the reason value, so that the second network device can clearly understand whether the terminal device can remain in the RRC inactive state. If the terminal device can remain in the RRC inactive state, the second network device indicates to the first network device that the terminal device remains in the RRC inactive state without feeding back the context of the terminal device, thereby reducing unnecessary migration of the context of the terminal device.

In possible implementations, the reasons why the terminal device restores the connection are different, and the reason values included in the connection restoration request message are also different, including the following situations.

Case 1: The terminal device has multicast service data to transmit, and the first network device can provide multicast services for the terminal device in the RRC inactive state, and the cause value is the first cause value.

Case 2: The first network device cannot provide multicast services for the terminal device in the RRC inactive state, and the reason value is the second reason value.

Case 3: The terminal device receives a first notification message from the first network device, and the cause value is the third cause value. Used to notify the terminal device to send a connection recovery request message for the multicast service.

Case 4: the terminal device receives a second notification message from the first network device, and the cause value is a fourth cause value. The second notification message is used to indicate counting of terminal devices in an RRC inactive state that receive multicast services.

In a possible implementation, the context acquisition request message includes one or more of the following information: first information, second information, third information, fourth information, first reason value, third reason value or fourth reason value. Among them, the first information is used to indicate that the first network device can provide multicast services for terminal devices in an RRC inactive state. The second information includes information on a list of multicast services that the first network device can provide to terminal devices in an RRC inactive state. The third information includes transmission configuration parameters of multicast services in the list of multicast services that the first network device can provide to terminal devices in an RRC inactive state. The fourth information is used to indicate that the first network device expects the terminal device to continue to remain in an RRC inactive state.

The first network device may determine the content of the context acquisition request message according to the reason value included in the connection recovery request message sent by the terminal device. For example, the context acquisition request message includes the first information or the first reason value, so that the second network device determines that the cell of the first network device can provide multicast services for the terminal device in the RRC inactive state, so that the second network device does not need to migrate the context of the terminal device to the first network device. For another example, the context acquisition request message includes the second information, so that the second network device determines whether to indicate to the first network device the multicast service that the terminal device joins, so that the first network device determines whether the terminal device needs to restore the connection to receive the multicast service, and if the connection does not need to be restored, then the terminal device is instructed to remain in the RRC inactive state.

In a possible implementation, the method further includes: the first network device determines that the context acquisition request message includes one or more of the first information, the second information, or the third information according to the first cause value included in the connection recovery request message. Alternatively, the first network device determines that the context acquisition request message includes the fourth information according to the third cause value included in the connection recovery request message.

In a possible implementation, the first network device receives a first message sent from the second network device, including: the first network device receives a context acquisition failure message sent from the second network device, the context acquisition failure message including the first message. The first network device can reuse the context acquisition failure message to instruct the terminal device to remain in the RRC inactive state without changing the current connection recovery process.

In a possible implementation, the first message includes the transmission parameter information of the multicast service joined by the terminal device, or the context acquisition failure message includes the transmission parameter information of the multicast service joined by the terminal device or the list of multicast services joined by the terminal device. The second network device can provide the first network device with the transmission parameter information of the multicast service joined by the terminal device or the list of multicast services joined by the terminal device through the context acquisition failure message, so that the first network device knows whether the terminal device needs to restore the connection. Thus, the first network device sends the multicast service to the terminal device according to the transmission parameter information of the multicast service.

In a possible implementation, the method further includes: the cause value is a fourth cause value, the first network device receives information about a multicast service joined by a terminal device from the second network device; the first network device counts the terminal devices accessing the multicast service provided by the first network device according to the multicast service joined by the terminal device. By counting the terminal devices accessing the multicast service provided by the first network device, when it is determined that the first network device can support access by more terminal devices, one or some terminal devices can be adaptively controlled to restore the connection, thereby improving the reliability of multicast service transmission.

In a third aspect, an embodiment of the present application provides a communication method, which can be performed by a communication device, which can be a communication device or a communication device that can support the communication device to implement the functions required by the method. Exemplarily, the communication device is a network device, or a chip system set in a network device, or other components for implementing the functions of a terminal device. For the convenience of description, the communication method provided in the third aspect is described below by taking the communication device as a second network device as an example.

The communication method includes: a second network device receives a context acquisition request message from a first network device, the context acquisition request message is used to obtain the context of a terminal device, and the terminal device is configured to receive multicast services in an RRC inactive state; the second network device determines that the first network device can provide the terminal device with the multicast services required to be received, and the second network device sends a first message to the terminal device through the first network device, and the first message is used to notify the terminal device to continue to remain in the RRC inactive state.

In a possible implementation, before the second network device sends the first message to the terminal device through the first network device, the method further includes: the second network device sends a context acquisition failure message to the first network device, where the context acquisition failure message includes the first message.

In a possible implementation, the first message includes transmission parameter configuration information of the multicast service joined by the terminal device, or the context acquisition failure message includes transmission parameter configuration information of the multicast service joined by the terminal device.

In a possible implementation, the context acquisition request message includes one or more of the following: first information, second information, third information, fourth information, first reason value, third reason value or fourth reason value. Among them, the first information is used to indicate that the first network device can provide multicast services for terminal devices in an RRC inactive state. The second information includes information on a list of multicast services that the first network device can provide for terminal devices in an RRC inactive state. The third information includes transmission configuration parameters of multicast services in the list of multicast services that the first network device can provide for terminal devices in an RRC inactive state. The fourth information is used to indicate that the first network device expects the terminal device to The device continues to remain in the RRC inactive state.

In a possible implementation, the context acquisition request message includes a fourth cause value, and the first message includes information about the multicast service to which the terminal device joins.

For the beneficial effects of the third aspect and its implementation, reference may be made to the description of the beneficial effects of the first aspect or the second aspect and its implementation.

In the fourth aspect, an embodiment of the present application provides a communication device, which has the function of implementing the behaviors in the method embodiments of the first aspect, the second aspect or the third aspect above. Accordingly, the beneficial effects can be found in the description of the first aspect, the second aspect or the third aspect, and will not be repeated here.

The communication device may be a terminal device in the first aspect, or the communication device may be a device capable of implementing the method provided in the first aspect, such as a chip or a chip system. In one possible design, the communication device includes corresponding means (means) or modules for executing the method of the first aspect. For example, the communication device: includes a processing unit (sometimes also referred to as a processing module or processor) and/or a transceiver unit (sometimes also referred to as a transceiver module or transceiver). The transceiver unit may include a sending unit and a receiving unit, and it can also be understood that the sending unit and the receiving unit are the same functional module. Alternatively, the transceiver unit is also understood to be a general term for the sending unit and the receiving unit, and the sending unit and the receiving unit may be different functional modules. These units (modules) can perform the corresponding functions in the above-mentioned first aspect method example, and refer to the detailed description in the method example for details, which will not be repeated here.

The communication device may be the first network device in the second aspect, or the communication device may be a device capable of implementing the method provided in the second aspect, such as a chip or a chip system. In one possible design, the communication device includes corresponding means (means) or modules for executing the method of the second aspect. For example, the communication device: includes a processing unit (sometimes also referred to as a processing module or processor) and/or a transceiver unit (sometimes also referred to as a transceiver module or transceiver). The transceiver unit may include a sending unit and a receiving unit, and it can also be understood that the sending unit and the receiving unit are the same functional module. Alternatively, the transceiver unit is also understood to be a general term for the sending unit and the receiving unit, and the sending unit and the receiving unit may be different functional modules. These units (modules) can perform the corresponding functions in the above-mentioned second aspect method example, and refer to the detailed description in the method example for details, which will not be repeated here.

The communication device may be the second network device in the third aspect, or the communication device may be a device capable of implementing the method provided in the third aspect, such as a chip or a chip system. In one possible design, the communication device includes corresponding means (means) or modules for executing the method of the second aspect. For example, the communication device: includes a processing unit (sometimes also referred to as a processing module or processor) and/or a transceiver unit (sometimes also referred to as a transceiver module or transceiver). The transceiver unit may include a sending unit and a receiving unit, and it can also be understood that the sending unit and the receiving unit are the same functional module. Alternatively, the transceiver unit is also understood to be a general term for the sending unit and the receiving unit, and the sending unit and the receiving unit may be different functional modules. These units (modules) can perform the corresponding functions in the above-mentioned third aspect method example, and refer to the detailed description in the method example for details, which will not be repeated here.

In a fifth aspect, an embodiment of the present application provides a communication device, which may be the communication device of the fourth aspect above, or a chip or chip system arranged in the communication device of the fourth aspect. The communication device may be a terminal device or a first network device or a second network device. The communication device includes a communication interface and a processor, and optionally, also includes a memory. The memory is used to store a computer program, and the processor is coupled to the memory and the communication interface. When the processor reads the computer program or instruction, the communication device executes the method performed by the terminal device or the first network device or the second network device in the above method.

In a sixth aspect, an embodiment of the present application provides a communication device, which includes an input/output interface and a logic circuit. The input/output interface is used to input and/or output information. The logic circuit is used to execute the method described in any one of the first aspects. Alternatively, the logic circuit is used to execute the method described in any one of the second aspects. Alternatively, the logic circuit is used to execute the method described in any one of the third aspects.

In a seventh aspect, an embodiment of the present application provides a chip system, which includes a processor and may also include a communication interface, for implementing the method described in the first aspect, the second aspect, or the third aspect. In a possible implementation, the chip system also includes a memory for storing a computer program. The chip system may be composed of a chip, or may include a chip and other discrete devices.

In an eighth aspect, an embodiment of the present application provides a communication system, wherein the communication system includes a terminal device and a network device for implementing the functions related to the first aspect, the second aspect, or the third aspect. Of course, the communication system may include more terminal devices or more network devices.

In a ninth aspect, the present application provides a computer-readable storage medium storing a computer program. When the computer program is executed, the method in the first aspect, the second aspect or the third aspect is implemented.

In a tenth aspect, a computer program product is provided, the computer program product comprising: a computer program code, when the computer program code is run, the method in the first aspect, the second aspect or the third aspect is executed.

The beneficial effects of the fourth to tenth aspects and their implementations can refer to the first to third aspects and their implementations. Description of the beneficial effects.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is an exemplary architecture diagram of a communication system to which an embodiment of the present application is applicable;

FIG2 is a schematic diagram of the architecture of a multicast service provided in an embodiment of the present application;

FIG3 is an exemplary architecture diagram of a communication system applicable to an embodiment of the present application;

FIG4 is a schematic diagram of a process of restoring a connection of a terminal device provided in an embodiment of the present application;

FIG5 is a schematic diagram of another process of restoring a connection of a terminal device provided in an embodiment of the present application;

FIG6 is a schematic diagram of a flow chart of a first communication method provided in an embodiment of the present application;

FIG7 is a schematic diagram of a flow chart of a second communication method provided in an embodiment of the present application;

FIG8 is a schematic diagram of a flow chart of a third communication method provided in an embodiment of the present application;

FIG9 is a schematic diagram of a structure of a communication device provided in an embodiment of the present application;

FIG. 10 is another schematic diagram of the structure of a communication device provided in an embodiment of the present application.

Detailed ways

The technical solutions provided in the embodiments of the present application can be applied to new radio (NR) systems, or to long term evolution (LTE) systems, Internet of things (IoT) systems, narrowband Internet of things (NB-IoT) systems, or to next generation mobile communication systems or other similar communication systems, without specific limitation.

Please refer to Figure 1, which is an exemplary architecture diagram of a communication system applicable to an embodiment of the present application. The communication system may include a core network device, a network device and at least one terminal device. As shown in Figure 1, a terminal device is taken as an example. The terminal device is connected to the network device wirelessly, and the network device is connected to the core network device wirelessly or wired. The core network device and the network device can be independent and different physical devices; or the functions of the core network device and the logical functions of the network device are integrated on the same physical device; or the functions of part of the core network device and the functions of part of the network device are integrated on the same physical device. It should be noted that Figure 1 is only for illustration, and the embodiments of the present application do not limit the number of core network devices, network devices and terminal devices included in the mobile communication system. In some embodiments, the communication system may also include other network devices, such as servers, which can provide service data for terminal devices.

Among them, the network device can be an access device that the terminal device accesses to the mobile communication system by wireless means, for example, including access network (AN) equipment, such as a base station. The network device can also refer to a device that communicates with the terminal device at the air interface. The network device can include a next-generation Node B (gNB), a transmission reception point (TRP), an evolved Node B (eNB), a radio network controller (RNC), a Node B (NB), a base station controller (BSC), a base transceiver station (BTS), a home base station (e.g., home evolved Node B, or home Node B, HNB), a base band unit (BBU), or a wireless fidelity (Wifi) access point (AP), etc. The name of the network device in the embodiments of the present application may be a relay node (RN), a relay transmission and reception point (rTRP), a vehicle-mounted device, a future evolved public land mobile network (PLMN) device, a device in a D2D network, a device in an M2M network, a device in an IoT network, or a network device in a PLMN network, etc. The embodiments of the present application do not limit the specific technology and specific device form adopted by the network device.

In addition, the base station in the embodiment of the present application may include a CU and a distributed unit (DU), and multiple DUs may be centrally controlled by one CU, which may also be referred to as a CU connected to at least one DU. This structure can separate the protocol layers of network devices in the communication system, with some of the protocol layers being centrally controlled by the CU, and the remaining part or all of the protocol layer functions being distributed in the DU, which is centrally controlled by the CU. The CU and DU can be physically connected via optical fiber, and logically there is a specially defined F1 interface for communication between the CU and DU. From a functional perspective, the CU is mainly responsible for wireless resource control and configuration, inter-cell mobility management, bearer management, etc.; the DU is mainly responsible for scheduling, physical signal generation and transmission.

Taking the base station as gNB as an example, the protocol layer of gNB includes radio resource control (RRC) layer, service data adaptation protocol (SDAP) layer, packet data convergence protocol (PDCP) layer, radio link control (RLC) layer, media access control sublayer (MAC) layer and physical layer (PHY). Among them, CU can be used to implement RRC layer, SDAP layer and The function of the PDCP layer, DU can be used to implement the functions of the RLC layer, MAC layer and physical layer. It should be noted that this division of the protocol layer is only an example, and it can also be divided in other protocol layers. The radio frequency device can be pulled away and not placed in the DU, or it can be integrated in the DU, or part of it can be pulled away and part of it can be integrated in the DU. The embodiment of the present application does not impose any restrictions. In addition, the embodiment of the present application does not specifically limit the protocol stack included in the CU and DU. In some embodiments, the control plane (control plan, CP) and the user plane (user plan, UP) of the CU can also be separated and divided into different entities for implementation, namely the control plane CU entity (CU-CP entity) and the user plane CU entity (CU-UP entity). The control plane CU-CP of the CU also includes a further segmented architecture, that is, the existing CU-CP is further divided into CU-CP1 and CU-CP2. Among them, CU-CP1 includes various radio resource management functions, and CU-CP2 only includes radio resource control (radio resource control, RRC) functions and PDCP-C functions (that is, the basic functions of control plane signaling at the PDCP layer). In this article, network devices all refer to base stations.

In the embodiment of the present application, the communication device for realizing the function of the network device can be a network device, or a device that can support the network device to realize the function, such as a chip system, which can be installed in the network device. In the technical solution provided in the embodiment of the present application, the device for realizing the function of the network device is a network device, and the technical solution provided in the embodiment of the present application is described.

A terminal device is a device with wireless transceiver functions, which can send signals to network devices or receive signals from network devices. The terminal device may include user equipment (UE), sometimes also referred to as a terminal, access station, UE station, remote station, wireless communication equipment, or user device, etc. The terminal device is used to connect people, objects, machines, etc., and can be widely used in various scenarios, such as but not limited to the following scenarios: cellular communication, device to device (D2D), vehicle-to-everything (V2X), machine-to-machine/machine-type communications (M2M/MTC), IoT, virtual reality (VR), augmented reality (AR), industrial control, self-driving, remote medical, smart grid, smart furniture, smart office, smart wear, smart transportation, smart city, drones, robots and other scenarios.

As an example but not limitation, in the embodiments of the present application, the terminal device may also be a wearable device. Wearable devices may also be referred to as wearable smart devices or smart wearable devices, etc., which are a general term for the intelligent design and development of wearable devices for daily wear using wearable technology, such as glasses, gloves, watches, clothing and shoes, etc. The various terminal devices introduced above, if located on a vehicle (for example, placed in a vehicle or installed in a vehicle), can be considered as vehicle-mounted terminal devices, and vehicle-mounted terminal devices are also referred to as on-board units (OBU). The terminal device of the present application may also be a vehicle-mounted module, a vehicle-mounted module, a vehicle-mounted component, a vehicle-mounted chip or a vehicle-mounted unit built into a vehicle as one or more components or units. The vehicle may implement the method of the present application through the built-in vehicle-mounted module, vehicle-mounted module, vehicle-mounted component, vehicle-mounted chip or vehicle-mounted unit.

In the embodiment of the present application, the communication device for realizing the function of the terminal device may be a terminal device, or may be a device capable of supporting the terminal device to realize the function, such as a chip system, which may be installed in the terminal device. In the technical solution provided in the embodiment of the present application, the technical solution provided in the embodiment of the present application is described by taking the device for realizing the function of the terminal device as an example that the terminal device is used as the device.

The core network is mainly used to manage terminal devices and provide the function of communicating with network devices. The core network equipment may include one or more of the following network elements: access and mobility management function (AMF), session management function (SMF), user plane function (UPF), policy control function (PCF), unified data management (UDM) network element. The purpose of each network element is not described here. It should be noted that in different communication systems, the network elements in the above core network may have different names. The above is explained using the NR system as an example and is not intended to limit the present application.

In the embodiments of the present application, the number of nouns, unless otherwise specified, means "singular noun or plural noun", that is, "one or more". "At least one" means one or more, and "plural" means two or more. "And/or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and/or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character "/" generally indicates that the previous and next associated objects are in an "or" relationship. For example, A/B means: A or B. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c means: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, c can be single or multiple.

The ordinal numbers such as "first" and "second" mentioned in the embodiments of the present application are used to distinguish multiple objects, and are not used to limit the size, content, order, timing, application scenario, priority or importance of multiple objects. For example, "first reason value" and "second reason value" indicate that there are two reason values, but do not mean that the priority or importance of the two reason values is different.

The embodiments of the present application relate to the transmission of multicast services. Multicast services, also known as multicast services, refer to services for multiple terminal devices, such as live broadcasts and scheduled broadcasts of programs. Multicast services are services that meet the requirements of high quality of service (QoS). The same QoS level as unicast service can be provided by group management for multicast service. In LTE, multicast service is also called multimedia broadcast multicast service (MBMS) service, and in NR, multicast service is also called multicast/multicast broadcast service (MBS) service.

Please refer to Figure 2, which is a schematic diagram of the architecture of the multicast service. As shown in Figure 2, the server can provide service data for the terminal device, the server sends the multicast service data to the core network device, and then the core network device sends the multicast service data to the base station, and finally the base station sends the multicast service data to at least one terminal device that receives the multicast service data. Figure 2 takes at least one terminal device including terminal device 1 and terminal device 2 as an example.

The core network equipment can perform group management on the multicast service, that is, manage the terminal equipment to join or leave the group. The protocol data unit (PDU) session established between the core network equipment and the base station introduces the MBS QoS flow. The core network equipment sends the multicast service data to the base station through the PDU session, and then the base station sends it to at least one terminal device. Among them, the base station can send the multicast service data to the terminal device through a dedicated bearer point-to-point (PTP) transmission mode established for the terminal device; it can also send the multicast service data to the terminal device through a dedicated bearer established for the multicast service in a point-to-multipoint (PTM) transmission mode. In addition, the base station can also switch between the PTP transmission mode and the PTM transmission mode.

As shown in FIG3, for MBS services, the core network device can send MBS service data to the base station through a common transmission channel MBS session. Each MBS session includes at least one MBS QoS flow. The base station sends the MBS service data to at least one terminal device through the MBS wireless bearer. Among them, the base station can send the MBS service data to at least one terminal device (such as terminal device 1-terminal device 3 in FIG3) in a PTM transmission mode, and can also send the MBS service data to at least one terminal device (such as terminal device 4 in FIG3) in a PTP mode.

Multicast services are provided to terminal devices in the RRC connected state (denoted as RRC_CONNECTED), which requires the terminal devices to remain in the RRC connected state. The base station and the core network equipment maintain the information of the terminal devices corresponding to the multicast service group. However, the capacity of the base station is limited, that is, the number of terminal devices that the base station can support to reside in the RRC connected state is limited. Based on this, it is expected that terminal devices in the RRC inactive state (denoted as RRC_INACTIVE) can also receive multicast services. In other words, multicast services can also be provided to terminal devices in the RRC Inactive state. In this way, when the base station is not sufficient to support the connected terminal devices, some of the terminal devices can be transferred from the RRC connected state to the RRC Inactive state.

When the terminal device is released from RRC_CONNECTED to RRC_INACTIVE, the base station will assign an inactive radio network temporary identifier (I-RNTI) to the terminal device, and use this identifier to store the context of the terminal device. This base station is the base station that last served the terminal device, also known as the last serving base station or anchor base station. The connection between the terminal device and the core network will be saved in the anchor base station. The anchor base station controls the terminal device to enter the RRC inactive state, and assigns the terminal device's context identifier and management area information (RAN notification area (RAN notification area, RNA)) to the terminal device. If the terminal device moves out of the management area, the RAN node (that is, the base station) must be notified; if the terminal device moves within the management area, the RAN node may not be notified.

When the terminal device requests to resume the connection from the RRC inactive state, the terminal device can send an RRC Resume Request message to the current base station. Of course, if the RNA is updated, the terminal device also sends an RRC Resume Request message to the base station.

Please refer to Figure 4, which is a schematic diagram of a process of restoring a connection of a terminal device. As shown in Figure 4, the process of restoring a connection of a terminal device may include the following steps:

S41. The terminal device sends a connection resumption request (RRC Resume Request) message to the serving base station.

S42. The serving base station sends a context acquisition request (RETRIEVE UE CONTEXT REQUEST) message to the anchor base station.

S43: The anchor base station sends a RETRIEVE UE CONTEXT RESPONSE message to the serving base station. The context acquisition response message includes the context of the terminal device.

S44. The serving base station sends an RRC resume (RRC Resume) message to the terminal device.

The serving base station receives the context of the terminal device, executes an RRC recovery message according to the context of the terminal device, and sends the RRC recovery message to the terminal device.

S45. The terminal device restores the RRC connection and enters the RRC connection state.

S46. The terminal device sends an RRC Resume Complete message to the serving base station.

After the terminal device restores the RRC connection, it sends an RRC recovery completion message to the serving base station, so that the serving base station determines that the terminal device is in the RRC connection state. After that, the serving base station can send a path switching process to the core network device to restore the connection between the terminal device and the core network. Then switch to the serving base station to complete the connection recovery of the terminal device, that is, execute S47-S49.

S47. The service base station sends a path switch request (PATH SWITCH REQUEST) message to the core network device.

S48. The core network device sends a path switch request response (PATH SWITCH REQUEST RESPONSE) message to the serving base station.

S49. The serving base station sends a terminal device context release (UE CONTEXT RELEASE) message to the core network device.

The terminal device can also request to restore the connection without entering the RRC connection state. For example, when the RNA is updated, the terminal device can also trigger a request to restore the connection. In this case, the terminal device has no business data to transmit, and the anchor base station can choose to release the terminal device to the RRC inactive state, without migrating the context of the terminal device, and naturally without changing the state of the terminal device.

For example, see Figure 5, which is another schematic diagram of a process for restoring a connection of a terminal device. As shown in Figure 5, the process for restoring a connection of a terminal device may include the following steps:

S51. When the terminal device determines that RNA is updated, it sends a connection resumption request (RRC Resume Request) message to the serving base station.

S52. The serving base station sends a context acquisition request (RETRIEVE UE CONTEXT REQUEST) message to the anchor base station.

S53: The anchor base station sends a RETRIEVE UE CONTEXT FAILURE message to the serving base station. The RETRIEVE UE CONTEXT FAILURE message does not include the context of the terminal device or includes partial context information.

S54. The serving base station sends an RRC Release message to the terminal device.

For terminal devices in the RRC inactive state, the base station can notify the terminal device how to receive multicast service data through broadcasting or other means. For example, the base station can broadcast configuration information for receiving multicast service data to the terminal device. There are multiple base stations deployed in the network, some of which can provide multicast services for terminal devices in the RRC inactive state, and some base stations cannot provide multicast services for terminal devices in the RRC inactive state. As the terminal device moves, the terminal device cannot determine whether the current serving base station can provide multicast services for the terminal device in the RRC inactive state, so the terminal device will initiate connection recovery. However, the serving base station may be able to provide multicast services for terminal devices in the RRC inactive state, if the anchor base station does not know whether the serving base station can provide multicast services for terminal devices in the RRC inactive state. According to the process shown in Figure 4, the terminal device initiates connection recovery, and the anchor base station will migrate the context of the terminal device to the serving base station by default, which will cause unnecessary context migration of the terminal device.

In view of the above problems, in the solution provided by the embodiment of the present application, the serving base station can determine the reason for the connection recovery of the terminal device to determine whether the terminal device needs to recover the connection. If the serving base station determines that the terminal device does not need to recover the connection, the serving base station notifies the anchor base station that the terminal device can remain in the RRC inactive state, so that the anchor base station does not need to migrate the context of the terminal device to the serving base station, reducing unnecessary context migration of the terminal device. It should be understood that the serving base station refers to the base station to which the terminal device is currently connected. The anchor base station refers to the last base station that provides services to the terminal device before the serving base station, and the anchor base station saves the terminal context and saves the connection between the terminal device and the core network device. In this article, "first network device" is replaceable with "serving network device" or "serving base station", and "second network device" is replaceable with "anchor network device" or "anchor base station". The solution provided by the embodiment of the present application can be applied to a terminal device in an RRC inactive state, and can also be applied to a terminal device in an RRC idle state. Unless otherwise specified, the "RRC inactive state" in the embodiment of the present application can be replaced with "RRC idle state". The following describes the solution provided by the embodiment of the present application by taking a terminal device in an RRC inactive state as an example.

The terminal device performs cell reselection or cell selection in the RRC inactive state, and after determining the target cell, it can initiate connection recovery to the serving base station. When the terminal device needs to receive data from the serving base station, it can also send a connection recovery request message to the serving base station. In an embodiment of the present application, if any one or more of the following conditions are met, a connection recovery request message is sent to the serving base station.

Condition 1: The cell of the serving base station cannot provide multicast services for terminal devices in the RRC inactive state. That is, when the terminal device determines that the cell of the serving base station cannot provide multicast services for terminal devices in the RRC inactive state, but the terminal device needs to receive multicast services, the terminal device can send a connection recovery request message to the serving base station so that the terminal device enters the RRC connection state and receives multicast services. How the terminal device determines whether the cell of the serving base station can provide multicast services for terminal devices in the RRC inactive state will be described below.

Condition two: the terminal device cannot obtain the transmission configuration information of the multicast service to which the terminal device joins from the cell of the serving base station. That is, the terminal device does not send a connection recovery request message, but first obtains the transmission configuration information of the multicast service to which the terminal device joins from the cell of the serving base station. If the terminal device cannot obtain the transmission configuration information of the multicast service to which the terminal device joins from the cell of the serving base station, it means that the terminal device cannot receive the multicast service from the serving base station. In this case, when the terminal device needs to receive the multicast service, it sends a connection recovery request message to the serving base station. How the terminal device specifically obtains the transmission configuration information of the multicast service to which the terminal device joins from the cell of the serving base station will be described below.

Condition 3: The cell of the serving base station can provide multicast services for the terminal device in the RRC inactive state. In the inactive state, the transmission configuration information of the multicast service joined by the terminal device cannot be directly obtained from the cell of the serving base station. Similar to condition two, even if the cell of the serving base station can provide multicast services for the terminal device in the RRC inactive state, if the terminal device cannot obtain the transmission configuration information of the multicast service joined by the terminal device from the cell of the serving base station in the RRC inactive state, it means that the terminal device does not enter the RRC connected state and still cannot receive the multicast service. Therefore, when condition three is met, the terminal device determines to send a connection recovery request message to the serving base station.

Condition four: The terminal device receives a first notification message from the serving base station, and the first notification message is used to notify the terminal device to send a connection recovery request message for the multicast service. For example, when the serving base station determines that the number of terminal devices connected is small, the serving base station notifies the terminal device in the RRC inactive state through the first notification message that it needs to receive the multicast service and initiates a connection recovery request message. The terminal device receives the first notification message and determines to send a connection recovery request message to the serving base station.

Condition five, the terminal device receives a second notification message from the serving base station, and the second notification message is used to instruct the counting of terminal devices that receive multicast services and are in an RRC inactive state. For example, the second notification message is used to instruct the serving base station to count terminal devices that receive multicast services and are in an RRC inactive state. By counting terminal devices that receive multicast services and are in an RRC inactive state, the serving base station can determine the terminal devices that may access in the future, thereby determining whether to allow one or some terminal devices to access the serving base station based on its own capabilities. In this case, the serving base station notifies the terminal device that is in an RRC inactive state and receives multicast services through the second notification message to initiate a connection recovery request message. The terminal device receives the second notification message and determines to send a connection recovery request message to the serving base station.

Condition six: The terminal device needs to send a connection recovery request message every time it changes cells.

Exemplarily, after determining the target cell, the terminal device may determine whether one or more of the above conditions are met, thereby determining whether to send a connection recovery request message to the serving base station. For example, the terminal device may determine whether any of conditions one to six are met. If so, the terminal device determines to send a connection recovery request message to the serving base station. For another example, the terminal device may determine whether condition one is met. If condition one is not met, the terminal device continues to determine whether condition two or condition three are met. If so, the terminal device determines to send a connection recovery request message to the serving base station.

The following first introduces how a terminal device determines whether the cell of a serving base station can provide a multicast service for a terminal device in an RRC inactive state.

In an embodiment of the present application, the serving base station may directly or indirectly indicate whether the serving base station is capable of providing multicast services for a terminal device in an RRC inactive state.

Exemplarily, the serving base station may broadcast a system message including indication information for indicating whether the cell of the serving network device supports multicast services in the RRC inactive state. The terminal device receives the system message and can clarify whether the serving base station can provide multicast services for the terminal device in the RRC inactive state based on the indication information in the system message. Alternatively, if the system message does not indicate the MCCH that can be configured with the multicast service, it implicitly indicates that the serving base station cannot provide multicast services for the terminal device in the RRC inactive state. The system message may be a master information block (MIB), a system information block (SIB)1 or other system information (OSI), etc.

Exemplarily, the MCCH sent by the serving base station includes configuration information for the multicast service, and the terminal device determines that the cell of the serving network device can provide the multicast service for the terminal device in the RRC inactive state; or, the MCCH of the cell of the serving network device includes partial configuration information for the multicast service, and the terminal device determines that the cell of the serving network device can provide the multicast service for the terminal device in the RRC inactive state. If the MCCH includes partial or all configuration information for the multicast service, it implicitly indicates that the cell of the serving network device supports the multicast service in the RRC inactive state; if the MCCH does not include configuration information for the multicast service, it implicitly indicates that the cell of the serving network device does not support the multicast service in the RRC inactive state.

The terminal device obtains the transmission configuration information of the multicast service joined by the terminal device from the cell of the serving base station, including the following three acquisition methods.

Acquisition method 1: The terminal device acquires the transmission configuration information of the multicast service joined by the terminal device from the cell of the anchor base station through dedicated signaling, wherein the dedicated signaling includes, for example, an RRC connection release or RRC connection reconfiguration message.

For example, the terminal device obtains information including an area from the anchor base station when the RRC connection is released or before the RRC connection is released. Alternatively, the terminal device obtains information including an area from the anchor base station when the RRC connection is reconfigured or before the RRC connection is reconfigured. The area information includes one or more of a cell list, RNA information, or TA information, and transmission configuration information of the cell contained in the area information for the multicast service joined by the terminal device. If the cell of the serving base station is not within the cell contained in the area information, the terminal device determines that it cannot obtain the transmission configuration information of the multicast service joined by the terminal device from the cell of the serving base station. In this case, the terminal device determines to send a connection recovery request message to the serving base station. If the cell of the serving base station is within the cell contained in the area information, the terminal device determines that it can obtain the transmission configuration information of the multicast service joined by the terminal device from the cell of the serving base station. In this case, the terminal The device does not need to send a connection recovery request message to the serving base station.

Acquisition method 2: The terminal device acquires the transmission configuration information of the multicast service joined by the terminal device from the cell of the serving base station through public signaling, wherein the public signaling is, for example, MCCH, system message or paging message.

For example, the terminal device receives the MCCH of the current cell of the serving base station or a broadcast system message. The MCCH or system message may include the transmission configuration information of the multicast service provided or supported by the serving base station for the terminal device in the RRC inactive state. If the terminal device cannot read the transmission configuration information of the multicast service joined by the terminal device from the received MCCH or system message, the terminal device determines that it cannot obtain the transmission configuration information of the multicast service joined by the terminal device from the cell of the serving base station. In this case, the terminal device determines to send a connection recovery request message to the serving base station. If the terminal device can read the transmission configuration information of the multicast service joined by the terminal device from the received MCCH or system message, the terminal device determines that it can obtain the transmission configuration information of the multicast service joined by the terminal device from the cell of the serving base station. In this case, the terminal device determines that it does not need to send a connection recovery request message to the serving base station.

Acquisition method three: the terminal device obtains the transmission configuration information of the multicast service joined by the terminal device from the cell of the serving base station through public signaling and dedicated signaling.

For example, the terminal device receives configuration parameter set 1 from the anchor base station through dedicated signaling, and receives configuration parameter set 2 through public signaling of the current cell of the serving base station. Configuration parameter set 1 includes partial transmission configuration information of each multicast service. For example, configuration parameter set 1 includes at least one configuration index, and each configuration index indicates partial transmission configuration parameters of a multicast service. Partial transmission configuration parameters, for example, include one or more parameters such as group radio network temporary identifier (G-RNTI), multicast radio bearer (MRB) configuration information, PDSCH configuration parameters, etc. Configuration parameter set 2 includes partial transmission configuration information of each multicast service. For example, configuration parameter set 2 includes identification information of each multicast service, and parameter configuration index of each multicast service. Optionally, configuration parameter set 2 may also include other transmission configuration parameters of each multicast service, for example, including PDSCH configuration parameters, rate matching parameters, etc.

The terminal device determines whether it can obtain the transmission configuration information of the cell of the serving base station for the multicast service joined by the terminal device based on configuration parameter set 1 and configuration parameter set 2. For example, the terminal device determines that the identification information of the joined multicast service is located in the identification information included in configuration parameter set 2, and the configuration index corresponding to the identification information in configuration parameter set 2 is located in at least one configuration index in configuration parameter set 1, then the terminal device determines that it can obtain the transmission configuration information of the multicast service joined by the terminal device from the cell of the serving base station. In this case, the terminal device determines that it is not necessary to send a connection recovery request message to the serving base station. On the contrary, if the terminal device determines that the identification information of the joined multicast service is not included in the identification information included in configuration parameter set 2, then the terminal device determines that it cannot obtain the transmission configuration information of the multicast service joined by the terminal device from the cell of the serving base station. In this case, the terminal device determines that it is necessary to send a connection recovery request message to the serving base station. Alternatively, the terminal device determines that the identification information of the multicast service joined is within the identification information included in the configuration parameter set 2, but the configuration index corresponding to the identification information in the configuration parameter set 2 does not belong to at least one configuration index in the configuration parameter set 1, then the terminal device determines that the transmission configuration information of the multicast service joined by the terminal device cannot be obtained from the cell of the serving base station. In this case, the terminal device determines to send a connection recovery request message to the serving base station.

In order to let the serving base station know the reason why the terminal device initiates the connection recovery request message, the connection recovery request message includes a reason value for the terminal device to initiate the connection recovery request message. In an embodiment of the present application, the reason value of the connection recovery request message may be the following first reason value, second reason value, third reason value or fourth reason value. For different scenarios, the reason value of the connection recovery request message is different, including the following situations.

Case 1: The terminal device has multicast service data to transmit, and the cell of the serving base station can provide multicast services for the terminal device in the RRC inactivated state, and the cause value of the connection recovery request message is the first cause value. The first cause value may be a newly defined cause value. Specifically, the multicast service is a multicast service that the terminal device is configured to receive in the RRC inactivated state. The terminal device has multicast service data to transmit, including the terminal device having only multicast service data and no unicast service data to send. For example, when the terminal device needs to receive the multicast service, and the terminal device determines that the cell of the serving base station can provide multicast services for the terminal device in the RRC inactivated state, then the terminal device determines that the cause value of the connection recovery request message is the first cause value. Specifically, the first cause value may be "only multicast services in the RRC inactivated state", or "only multicast services", etc.

Case 2: The cell of the serving base station cannot provide multicast services for the terminal device in the RRC inactive state, and the cause value of the connection recovery request message is the second cause value. Alternatively, the terminal device has a unicast service to transmit, and the cause value of the connection recovery request message is the second cause value. The second cause value is the defined cause value for initiating the connection recovery request message due to the need to transmit data. For example, the terminal device has a unicast service to transmit, and the cause value of the connection recovery request message is the second cause value. In an embodiment of the present application, the cell of the serving base station cannot provide multicast services for the terminal device in the RRC inactive state, and the terminal device determines that the cause value of the connection recovery request message can reuse the defined second cause value. For example, the second cause value can be "data transmission" or "signaling transmission", etc.

Case three, the terminal device receives the first notification message from the serving base station, and the cause value of the connection recovery request message is the third cause value. The first notification message is used to notify the terminal device to send a connection recovery request message for the multicast service. The third cause value may be a newly defined cause value. For example, when the serving base station determines that the number of terminal devices accessed is small, the serving base station notifies the terminal device in the RRC inactive state through the first notification message that it needs to receive the multicast service and initiates a connection recovery request message. The terminal device receives the first notification message and determines that the cause value for initiating the connection recovery request message is the third cause value. Specifically, the third cause value may be "response to multicast service access."

Case four, the terminal device receives a second notification message from the serving base station, and the cause value of the connection recovery request message is a fourth cause value. The second notification message is used to indicate the counting of terminal devices that receive multicast services and are in an RRC inactive state. The fourth cause value may be a newly defined cause value. For example, when the serving base station needs to count the terminal devices that receive multicast services and are in an RRC inactive state, the serving base station notifies the terminal devices that are in an RRC inactive state and receive multicast services through a second notification message to initiate a connection recovery request message. The terminal device receives the second notification message and determines that the cause value for initiating the connection recovery request message is the fourth cause value. Specifically, the fourth cause value may be a "multicast count response."

In a possible implementation, based on the defined second reason value, the first reason value, the third reason value or the fourth reason value may be newly defined. Alternatively, based on the defined second reason value, multiple reason values among the first reason value, the third reason value and the fourth reason value may be newly predefined.

To facilitate understanding of the technical solutions provided by the present application, the technical solutions provided by the present application are described in detail with specific examples in conjunction with the accompanying drawings. In the following introduction, the communication method provided in the embodiment of the present application is applied to the network architecture shown in Figure 1 as an example. The network architecture and application scenarios described in the embodiment of the present application are intended to more clearly illustrate the technical solutions of the embodiment of the present application, and do not constitute a limitation on the technical solutions provided in the embodiment of the present application. It is known to those of ordinary skill in the art that with the evolution of the network architecture and the emergence of new application scenarios, the technical solutions provided in the embodiment of the present application are also applicable to similar technical problems.

In addition, the method can be performed by three communication devices, such as a first communication device, a second communication device, and a third communication device. For ease of introduction, in the following, the method is performed by a terminal device, a service base station, and an anchor base station as an example, that is, the first communication device is a terminal device, the second communication device is a service base station, and the third communication device is an anchor base station. In the following embodiments, the terminal device is a terminal device configured to receive a multicast service in an RRC inactive state. For example, the terminal device is configured to receive multicast service 1 in an RRC inactive state.

Please refer to Figure 6, which is a flow chart of the first communication method provided in an embodiment of the present application. In the scenario of Figure 6, the terminal device does not have a transmission configuration for the multicast service of the target cell.

S601. The terminal device determines a cause value of a connection recovery request message.

The terminal device determines that it needs to receive multicast services from the serving base station, and the terminal device determines to send a connection recovery request message to the serving base station. In order for the serving base station to clarify the reason why the terminal device initiated connection recovery, the terminal device can determine the reason value carried by the connection recovery request message. As mentioned above, when the terminal device needs to receive multicast services, and the terminal device determines that the cell of the serving base station can provide multicast services for terminal devices in an RRC inactive state, then the terminal device determines that the reason value of the connection recovery request message is the first reason value. If the terminal device has a unicast service that needs to be transmitted, the terminal device determines that the reason value of the connection recovery request message is the second reason value. Considering that a base station that does not support the provision of multicast services to terminals in an RRC inactive state may be a base station that has not been upgraded and cannot identify the second reason value, if the cell of the serving base station cannot provide multicast services for terminal devices in an RRC inactive state, the terminal device determines that the reason value of the connection recovery request message is the second reason value. This can avoid the reason why the terminal device sends the second reason value to a base station that has not been upgraded, causing the base station to be unable to process RRC recovery.

Optionally, if the terminal device needs to receive multicast services, and the terminal device determines that the cell of the serving base station can provide multicast services for the terminal device in the RRC inactive state, and the terminal device moves out of the RNA area, in this case, the cause value of the connection recovery request message is also the first cause value.

S602. The terminal device sends a connection recovery request message to the serving base station. Correspondingly, the serving base station receives the connection recovery request message sent by the terminal device, where the connection recovery request message includes a cause value.

The connection recovery request message sent by the terminal device to the service base station includes a reason value and may also include identification information of the terminal device. The identification information of the terminal device allows the service base station to clearly understand which terminal device is requesting connection recovery, so that it can determine whether the service base station is the anchor base station for the terminal device. Depending on whether the service base station is the anchor base station for the terminal device, the subsequent behavior of the service base station is different. For example, if the service base station is not the anchor base station for the terminal device, the subsequent service base station can execute S603A; if the service base station is the anchor base station for the terminal device, the subsequent service base station can execute S603B. Among them, S603A and S603B can be executed one by one. Figure 6 takes the execution of S603A as an example, so S603B is indicated by a dotted line. The reason value in the connection recovery request message allows the service base station to clearly understand the reason why the terminal device requests connection recovery, so that the service base station determines whether the terminal device needs to restore the connection based on the reason value. For example, if the service base station determines that the terminal The end device does not need to restore the connection and can instruct the terminal device to remain in the RRC inactive state, which can reduce unnecessary connection restoration of the terminal device, that is, reduce unnecessary context migration of the terminal device.

S603A: The serving base station sends a context acquisition request message to the anchor base station. Correspondingly, the anchor base station receives the context acquisition request message from the serving base station.

The serving base station determines the connection recovery request message of the terminal device and can send a context acquisition request message to the anchor base station to request the context of the terminal device. It should be understood that the context acquisition request message includes the identification information of the terminal device so that the anchor base station knows which terminal device context the serving base station needs to acquire.

In an embodiment of the present application, the serving base station may determine the content included in the context acquisition request message according to the cause value of the connection recovery request message of the terminal device, so that the anchor base station can clearly understand whether the terminal device can remain in the RRC inactive state. If the terminal device can remain in the RRC inactive state, the anchor base station does not need to feedback the context of the terminal device to the serving base station or only returns part of the required context (such as information about the multicast service joined by the terminal device), thereby reducing unnecessary context migration of the terminal device.

Exemplarily, the context acquisition request message includes one or more of the following information: first information, second information, third information, fourth information, first reason value, third reason value or fourth reason value. Among them, the first information is used to indicate that the serving base station can provide multicast services for terminal devices in the RRC inactive state. The second information includes information on the list of multicast services that the serving base station can provide to terminal devices in the RRC inactive state. The third information includes the transmission configuration parameters of the multicast services in the list of multicast services that the serving base station can provide to terminal devices in the RRC inactive state. The fourth information is used to indicate that the serving base station expects the terminal device to continue to remain in the RRC inactive state.

If the cause value included in the connection restoration request message is the first cause value, the context acquisition request message may include one or more of the first information, the second information, the third information, or the first cause value.

For example, the connection restoration request message includes the first cause value, and the context acquisition request message includes the first cause value.

Alternatively, the connection recovery request message includes the first cause value, and if the serving base station itself can provide multicast services for the terminal device in the RRC inactive state, then the serving base station can determine that the context acquisition request message can include the first information. In this way, the anchor base station receives the first information and determines that the serving base station can provide multicast services for the terminal device in the RRC inactive state, and the terminal device can continue to remain in the RRC inactive state. The anchor base station may not feed back the context of the terminal device to the serving base station.

Alternatively, the context acquisition request message includes information about a list of multicast services that the serving base station can provide to a terminal device in an RRC inactive state and/or a transmission configuration parameter of at least one multicast service, so that the anchor base station determines whether the terminal device can continue to remain in the RRC inactive state based on the information in the multicast service list. If the anchor base station includes the multicast service to be received by the terminal device according to the indicated multicast service, then the anchor base station determines that the terminal device can continue to remain in the RRC inactive state and may not feed back the context of the terminal device to the serving base station.

S603B. The serving base station sends a response message to the terminal device, and correspondingly, the terminal device receives the response message sent by the serving base station.

If the serving base station is the anchor base station of the terminal device, in other words, the terminal device has not moved out of the coverage of the serving base station. In this case, the serving base station receives the connection recovery request message sent by the terminal device and can determine whether to keep the terminal device in the RRC inactive state or enter the RRC connected state according to the cause value of the connection recovery request message.

For example, the connection recovery request message includes the first cause value, and the serving base station can provide the terminal device with the multicast service required by the terminal device. In this case, the serving base station can send a response message to the terminal device, which includes the transmission configuration information of the multicast service and notifies the terminal device to continue to remain in the RRC inactive state.

For another example, the connection recovery request message includes a second cause value. In this case, the serving base station may send a response message to the terminal device, and the response message notifies the terminal device to switch to the RRC connection state.

S604: The anchor base station sends a reply message to the serving base station in response to the context acquisition request message. Correspondingly, the serving base station receives the reply message to the context acquisition request message from the anchor base station.

After the anchor base station receives the context acquisition request from the serving base station, it can determine whether the terminal device can remain in the RRC inactive state based on the content carried in the context acquisition request. If the anchor base station determines that the terminal device needs to switch to the RRC connected state, the anchor base station sends a context acquisition response message to the serving base station. That is, the reply message to the context acquisition request message is the context acquisition response message. The context acquisition response message includes the context of the terminal device and information about the multicast service to which the terminal device joins.

On the contrary, if the terminal device can remain in the RRC inactive state, the anchor base station sends a context acquisition failure message to the serving base station. That is, the reply message to the context acquisition request message is a context acquisition failure message. The context acquisition failure message includes a first message for notifying the terminal device to remain in the RRC inactive state. For example, the context acquisition request includes information on a multicast service list, and the anchor base station determines that the multicast service joined by the terminal device is in the list, then the anchor base station determines that the terminal device can remain in the RRC inactive state. In the state, the anchor base station sends a context acquisition failure message including a first message to the serving base station. The first message may be an RRC release message. The anchor base station sends the context acquisition failure message including the first message to the serving base station, so that the serving base station forwards the first message to the terminal and notifies the terminal device to remain in the RRC inactive state.

Optionally, the first message includes transmission parameter information of the multicast service joined by the terminal device, so that the terminal receives the multicast service according to the transmission parameter information. The transmission parameter information may be obtained by the anchor base station from the transmission configuration information of each multicast service included in the context acquisition request.

Optionally, the context acquisition failure message may also include information about the multicast service to which the terminal device has joined, for example, the temporary mobile group identification (TMGI) of the multicast service to which the terminal device has joined. The serving base station determines the multicast service corresponding to the TMGI and sends the multicast service to the terminal device according to the transmission parameter information of the multicast service.

It is understandable that if the serving base station can provide multicast services for terminal devices in an RRC inactive state, but the serving base station has not yet established the multicast service, that is, the serving base station cannot provide the terminal device with the transmission configuration information of the multicast service. In this case, the anchor base station may first request the serving base station to establish the multicast service requested by the terminal device. For example, before sending the first message, the anchor base station may send a second message to the serving base station, and the second message is used to request the serving base station to establish the multicast service requested by the terminal device. The serving base station receives the second message, establishes the multicast service requested by the terminal device, and sends a third message to the anchor base station. The third message includes the transmission configuration information of the multicast service requested by the terminal device.

Optionally, before the anchor base station sends the second message, it determines the context acquisition request message to determine whether the serving base station supports or is willing to provide multicast services to the terminal device in the RRC inactive state. If the serving base station does not support or is unwilling to provide multicast services to the terminal device in the RRC inactive state, the anchor base station may not send the second message.

S605. The serving base station sends a first message to the terminal device, where the first message is used to notify the terminal device to remain in an RRC inactive state.

After obtaining the second message, the serving base station may send a first message to the terminal device, wherein the first message indicates that the terminal device remains in the RRC inactive state.

In a possible implementation manner, the serving base station receives a context acquisition failure message from the anchor node, acquires a first message from the context acquisition failure message, and then forwards the first message to the terminal device.

If the service base station receives a context acquisition response message from the anchor base station, and the first message is not carried at this time, the service base station can initiate a path switching process to the core network, switch the interface between the terminal device and the core network to the service base station, and the channel of the multicast service joined by the terminal device is also established accordingly. For details, please refer to the relevant content of the aforementioned Figure 4, which will not be repeated here. In addition, the service base station can also determine whether the terminal device remains in the RRC inactive state to receive the multicast service based on the reason value included in the connection recovery request message. For example, the reason value included in the connection recovery request message is the first reason value, and the service base station can instruct the terminal device to continue to remain in the RRC inactive state. Optionally, the service base station can also send transmission parameter information of the multicast service joined by the terminal device to the terminal device. In other words, even if the anchor node migrates the context of the terminal device to the service base station, the service base station can still determine to release the terminal device to the RRC inactive state.

After the serving base station sends the first message, the serving base station sends the multicast service to the terminal device according to the obtained transmission parameter information of the multicast service joined by the terminal device. Accordingly, the terminal device continues to remain in the RRC inactive state and receives the multicast service from the serving base station. It should be understood that the terminal device can obtain the transmission parameter information of the received multicast service through any of the three aforementioned acquisition methods.

In the first communication method, the terminal device explicitly initiates the cause value of the connection recovery request message and notifies the serving base station. The serving base station provides relevant information, such as the first information, the first cause value, the second information or the third information, to the anchor base station based on the cause value, so that the anchor base station determines whether the terminal device can continue to remain in the RRC inactive state to reduce unnecessary terminal device context migration.

Although the service base station can provide multicast services for terminal devices in the RRC inactive state, the number of terminal devices connected to the service base station has decreased. The service base station can notify the terminal devices in the RRC inactive state to switch to the RRC connected state to ensure the reliability of the terminal devices receiving multicast services as much as possible. If there are many terminal devices accessing the service base station subsequently, the load on the service base station is heavy. In this case, for the subsequent connection recovery requested by the terminal devices in the RRC inactive state, the service base station can notify the terminal devices to continue to remain in the RRC inactive state. Through this solution, the load of the service base station and the reliability of the terminal devices receiving multicast services can be balanced.

Please refer to Figure 7, which is a flow chart of the second communication method provided in an embodiment of the present application. The scenario shown in Figure 7 takes the case where the serving base station determines that the current load is heavy due to the transfer of the terminal device in the RRC inactive state to the RRC connected state. For the subsequent terminal device in the RRC inactive state, the serving base station determines that the terminal device continues to remain in the RRC connected state.

S701. The terminal device sends a connection recovery request message to the serving base station. Correspondingly, the serving base station receives the connection recovery request message sent by the terminal device. The connection recovery request message includes identification information of the terminal device and a reason value.

Before sending the connection recovery request message, the terminal device determines that the cause value included in the connection recovery request message can refer to the above-mentioned related content, which will not be repeated here. For example, the cause value included in the connection recovery request message is the first cause value or the third cause value.

Depending on whether the serving base station is the anchor base station of the terminal device, the subsequent behavior of the serving base station is different. For example, if the serving base station is not the anchor base station of the terminal device, the subsequent serving base station may execute S702A; if the serving base station is the anchor base station of the terminal device, the subsequent serving base station may execute S702B.

S702A: The serving base station sends a context acquisition request message to the anchor base station. Correspondingly, the anchor base station receives the context acquisition request message from the serving base station.

The implementation of S702A may refer to the relevant contents of the aforementioned S603A, which will not be repeated here. The difference from S603A is that if the cause value included in the connection recovery request message is the third cause value, the serving base station may determine that the context acquisition request message includes one or more of the first information, the second information, the third information, the fourth information or the third cause value. For example, the serving base station may determine that the context acquisition request message includes the fourth information or the third cause value. For another example, the context acquisition request message may include the third cause value and the fourth information.

S702B. The serving base station sends a response message to the terminal device, and correspondingly, the terminal device receives the response message sent by the serving base station.

The specific implementation of S702B can refer to the relevant content of the aforementioned S603B, which will not be repeated here. The difference from S603B is that if the cause value included in the connection recovery request message includes the first cause value or the third cause value, the serving base station determines whether to allow the terminal device to enter the RRC connection state based on its own load. If the serving base station determines to keep the terminal device in the RRC inactive state, the serving base station sends a response message to the terminal device, which includes the transmission configuration information of the multicast service, and notifies the terminal device to continue to remain in the RRC inactive state.

S703: The anchor base station sends a reply message to the serving base station in response to the context acquisition request message. Correspondingly, the serving base station receives the reply message to the context acquisition request message from the anchor base station.

After the anchor base station receives the context acquisition request from the serving base station, it can determine whether the terminal device can remain in the RRC inactive state according to the content carried in the context acquisition request. The specific implementation of S703 can refer to the relevant content of the aforementioned S604, which will not be repeated here. The difference between S703 and S604 is that if the context acquisition request includes the third reason value and the fourth information. The anchor base station determines to send a first message to the serving base station.

S704. The serving base station sends a first message to the terminal device, where the first message is used to notify the terminal device to remain in an RRC inactive state.

After the serving base station obtains the first message, it may send the first message to the terminal device. The first message indicates that the terminal device remains in an RRC inactive state. The first message may be an RRC release message. The specific implementation of S704 may refer to the relevant content of S605 and will not be repeated here. The difference between S704 and S605 is that if the context acquisition request message includes the third reason value and/or the fourth information, the first message included in the reply message to the context acquisition request message may not include the transmission parameter information of the multicast service.

In the second communication method, the terminal device explicitly initiates the reason value of the connection recovery request message, such as receiving the first notification message sent by the serving base station. The auxiliary serving base station determines whether the terminal device is transferred to the RRC connected state for the subsequent connection recovery requested by the terminal device in the RRC inactive state. This balances the load of the serving base station and the reliability of the terminal device receiving the multicast service.

According to the process shown in Figure 7, when the number of terminal devices connected to the service base station decreases, the service base station can notify the terminal devices in the RRC inactive state to switch to the RRC connected state. If multiple terminal devices in the RRC inactive state subsequently request connection recovery, the service base station allows all of these multiple terminal devices to switch to the RRC connected state, which is a heavy load for the service base station. To this end, an embodiment of the present application also provides a communication method. In this method, before determining whether to switch the terminal device to the RRC connected state, the service base station can count the number of terminal devices in the RRC inactive state, thereby controlling the state conversion of the terminal device according to the counted number.

Please refer to Figure 8, which is a third communication method provided by an embodiment of the present application. The scenario shown in Figure 8 takes the example of a serving base station determining whether a terminal device continues to remain in an RRC connected state according to the number of terminal devices in an RRC inactive state.

S801. The serving base station sends a second notification message to the terminal device. Correspondingly, the terminal device receives the second notification message from the serving base station.

When the serving base station determines that the current load is heavy, it may send a second notification message to the terminal device, where the second notification message is used to indicate that the serving base station needs to count the terminal devices that receive multicast services and are in an RRC inactive state. The serving base station determines whether to allow one or some terminal devices in an RRC inactive state to enter an RRC connected state by counting the terminal devices that receive multicast services and are in an RRC inactive state. The second notification message is, for example, an MCCH message, a system message, or a paging message.

S802. The terminal device sends a connection recovery request message to the serving base station. Correspondingly, the serving base station receives the connection recovery request message sent by the terminal device. The connection recovery request message includes identification information of the terminal device and a reason value.

Before sending the connection recovery request message, the terminal device determines the cause value included in the connection recovery request message. For example, the cause value included in the connection recovery request message is the first cause value or the fourth cause value.

Depending on whether the serving base station is the anchor base station of the terminal device, the subsequent behavior of the serving base station is different. For example, if the serving base station is not the anchor base station of the terminal device, the subsequent serving base station may execute S803A; if the serving base station is the anchor base station of the terminal device, the subsequent serving base station may execute S803B.

S803A: The serving base station sends a context acquisition request message to the anchor base station. Correspondingly, the anchor base station receives the context acquisition request message from the serving base station.

The implementation of S803A may refer to the relevant contents of the aforementioned S603A, which will not be described in detail here. The difference from S603A is that if the cause value included in the connection recovery request message is the fourth cause value, the serving base station may determine that the context acquisition request message includes one or more of the first information, the second information, the third information, or the fourth cause value. For example, the serving base station may determine that the context acquisition request message includes the third information or the fourth cause value.

S803B. The serving base station sends a response message to the terminal device, and correspondingly, the terminal device receives the response message sent by the serving base station.

The specific implementation of S803B can refer to the relevant content of the aforementioned S603B, which will not be repeated here. The difference from S603B is that if the reason value included in the connection recovery request message includes the fourth reason value, the service base station also counts the number of terminal devices receiving the multicast service provided by the service base station based on the multicast service that the terminal device has joined. That is, the terminal devices receiving the multicast service provided by the service base station are counted, for example, the number of terminal devices receiving the multicast service provided by the service base station is increased by 1.

S804: The anchor base station sends a reply message to the serving base station in response to the context acquisition request message. Correspondingly, the serving base station receives the reply message to the context acquisition request message from the anchor base station.

After the anchor base station receives the context acquisition request from the serving base station, it may perform corresponding actions according to the content carried in the context acquisition request message. For example, the context acquisition request message includes the fourth reason value. The specific implementation of S804 can refer to the relevant content of the aforementioned S604, which will not be repeated here. The difference between S804 and S604 is that if the context acquisition request includes the fourth reason, the context acquisition failure message may include information about the multicast service joined by the terminal device. Thus, the serving base station receives the context acquisition failure message, and counts the terminal devices receiving the multicast service provided by the serving base station according to the information about the multicast service joined by the terminal device in the context acquisition failure message.

S805. The serving base station sends a first message to the terminal device, where the first message is used to notify the terminal device to remain in an RRC inactive state.

The specific implementation of S805 can refer to the relevant content of S605, which will not be repeated here. The difference between S805 and S605 is that if the service base station determines that the number of terminal devices receiving the multicast service provided by the service base station is large, the service base station sends a first message to the terminal device. In the process of counting the number of terminal devices receiving the multicast service provided by the service base station, the service base station sends a first message to the terminal device.

In the third communication method, the serving base station may count the number of terminal devices receiving the multicast service provided by the serving base station to assist in determining whether the terminal device is transferred to the RRC connected state. In the process of counting the number of terminal devices receiving the multicast service provided by the serving base station, the terminal device may be controlled to continue to remain in the RRC inactive state, thereby reducing the load of the serving base station as much as possible.

The first communication method, the second communication method and the third communication method can be implemented independently or in combination. For example, the first communication method and the second communication method can be combined, and the first communication method and the third communication method can also be combined.

In the above embodiments provided by the present application, the method provided by the embodiment of the present application is introduced from the perspective of the interaction between the serving base station, the anchor base station, the terminal device, and the serving base station, the anchor base station, and the terminal device. Among them, the steps performed by the serving base station or the anchor base station can also be implemented by different communication devices respectively. For example: the first device is used to generate a context acquisition request message, and the second device is used to send a context acquisition request message, that is, the first device and the second device jointly complete the steps performed by the base station in the embodiment of the present application, and the present application does not limit the specific division method. When the network architecture includes one or more distributed units (distributed units, DU), one or more centralized units (centralized units, CU) and one or more radio frequency units (RU), the steps performed by the above base station can be implemented by DU, CU and RU respectively. In order to realize the functions of the method provided by the above embodiments of the present application, the serving base station, the anchor base station, and the terminal device may include hardware structure and/or software module, and the above functions are realized in the form of hardware structure, software module, or hardware structure plus software module. Whether a certain function of the above functions is executed in the form of hardware structure, software module, or hardware structure plus software module depends on the specific application and design constraints of the technical solution.

Based on the same inventive concept as the method embodiment, the present application embodiment provides a communication device. The following describes the communication device used to implement the above method in the present application embodiment in conjunction with the accompanying drawings.

9 is a schematic block diagram of a communication device 900 provided in an embodiment of the present application. The communication device 900 may include a processing module 910 and a transceiver module 920. Optionally, a storage unit may be further included, which may be used to store instructions (codes or programs) and/or data. The processing module 910 and the transceiver module 920 may be coupled to the storage unit. For example, the processing module 910 may read the instructions (codes or programs) and/or data in the storage unit to implement the corresponding method. The above-mentioned modules may be independently arranged or partially or fully integrated.

In some possible implementations, the communication device 900 can implement the behaviors and functions of the terminal device in the above method embodiments. The communication device 900 may be a terminal device, or a component (such as a chip or circuit) used in a terminal device, or a chip or a chipset in the terminal device or a part of a chip used to execute the functions of the related method.

For example, the processing module 910 is used to determine the cause value of the connection recovery request message, wherein the communication device 900 is configured to receive the multicast service in the RRC inactive state. The transceiver module 920 is used to: send a connection recovery request message to the serving base station, the connection recovery request message including the cause value; receive a first message from the serving base station, receive the multicast service from the serving base station, the first message is used to notify the communication device 900 to remain in the RRC inactive state.

As an optional implementation method, the processing module 910 is specifically used for: when the communication device 900 has multicast service data to be transmitted, and the cell of the serving base station can provide multicast service for the communication device in the RRC inactivated state, the cause value is determined to be a first cause value; or, when the cell of the serving base station cannot provide multicast service for the communication device in the RRC inactivated state, the cause value is determined to be a second cause value; or, when the transceiver module 920 receives a first notification message from the serving base station, the cause value is determined to be a third cause value, and the first notification message is used to notify the communication device 900 to send the connection recovery request message for the multicast service; or, when the transceiver module 920 receives a second notification message from the serving base station, the cause value is determined to be a fourth cause value, and the second notification message is used to indicate counting of communication devices that receive multicast service and are in the RRC inactivated state.

As an optional implementation method, the transceiver module 920 is specifically used to meet any one or more of the following conditions and send a connection recovery request message to the service base station: the cell of the service base station cannot provide multicast services for the communication device in the RRC inactivated state; the transmission configuration information of the multicast service joined by the communication device 900 cannot be obtained from the cell of the service base station; the cell of the service base station can provide multicast services for the communication device in the RRC inactivated state, and the transmission configuration information of the multicast service joined by the communication device 900 cannot be obtained from the cell of the service base station; the first notification message of the service base station is received; or, the second notification message of the service base station is received.

As an optional implementation, the processing module 910 is further configured to determine whether the cell of the serving base station can provide a multicast service for a communication device in an RRC inactive state according to a system message or MCCH of the cell of the serving base station. The system message includes indication information for indicating whether the cell of the serving base station supports a multicast service in an RRC inactive state.

As an optional implementation method, the processing module 910 is specifically used for: the MCCH of the cell of the serving base station includes configuration information for the multicast service, and determines that the cell of the serving base station can provide multicast services for the communication device in the RRC inactivated state; or, the MCCH of the cell of the serving base station includes partial configuration information for the multicast service, and determines that the cell of the serving base station can provide multicast services for the communication device in the RRC inactivated state.

In some possible implementations, the communication device 900 can implement the behaviors and functions of the service base station in the above-mentioned method embodiments. The communication device 900 can be a network device, or a component (such as a chip or circuit) used in a network device, or a chip or chipset in the network device or a part of a chip used to execute related method functions.

For example, the transceiver module 920 is used to receive a connection recovery request message from a terminal device, and the connection recovery request message includes identification information of the terminal device and a cause value. The processing module 910 is used to determine the cause value. The transceiver module 920 is also used to send a context acquisition request message to an anchor base station of the terminal device, and receive a first message sent by the anchor base station. The context acquisition request message is used to acquire the context of a terminal device, and the terminal device is configured to receive multicast services in an RRC inactive state. The first message is used to notify the terminal device to remain in an RRC inactive state.

As an optional implementation method, the terminal device has multicast service data to be transmitted, and the communication device 900 can provide multicast services for terminal devices in an RRC inactivated state, and the cause value is a first cause value; or, the communication device 900 cannot provide multicast services for terminal devices in an RRC inactivated state, and the cause value is a second cause value; or, the terminal device receives a first notification message from the communication device 900, and the cause value is a third cause value, and the first notification message is used to notify the terminal device to send a connection recovery request message for the multicast service; or, the terminal device receives a second notification message from the communication device 900, and the cause value is a fourth cause value, and the second notification message is used to indicate counting of terminal devices in an RRC inactivated state that receive multicast services.

As an optional implementation method, the context acquisition request message includes one or more of the following information: first information, second information, third information, fourth information, first reason value, third reason value or fourth reason value. Among them, the first information is used to indicate that the communication device 900 can provide multicast services for terminal devices in an RRC inactive state. The second information includes information on a list of multicast services that the communication device 900 can provide for terminal devices in an RRC inactive state. The third information includes transmission configuration parameters for multicast services in the list of multicast services that the communication device 900 can provide for terminal devices in an RRC inactive state. The fourth information is used to indicate that the communication device 900 expects the terminal device to continue to remain in an RRC inactive state.

As an optional implementation method, the processing module 910 is also used to: determine that the context acquisition request message includes one or more of the first information, the second information or the third information based on the first reason value included in the connection recovery request message; or, determine that the context acquisition request message includes fourth information based on the third reason value included in the connection recovery request message.

As an optional implementation manner, the transceiver module 920 is specifically configured to receive a context acquisition failure message sent from an anchor base station, where the context acquisition failure message includes a first message.

As an optional implementation manner, the first message includes transmission parameter information of the multicast service joined by the terminal device, or the context acquisition failure message includes transmission parameter information of the multicast service joined by the terminal device or a list of multicast services joined by the terminal device.

As an optional implementation method, the transceiver module 920 is also used to receive information about the multicast service joined by the terminal device from the anchor base station, wherein the cause value is the fourth cause value; the processing module 910 is also used to count the terminal devices that access the multicast service provided by the communication device 900 according to the multicast service joined by the terminal device.

In some possible implementations, the communication device 900 can implement the behaviors and functions of the anchor base station in the above-mentioned method embodiments. The communication device 900 can be a network device, or a component (such as a chip or circuit) used in a network device, or a chip or chipset in the network device or a part of a chip used to execute related method functions.

For example, the transceiver module 920 is used to receive a context acquisition request message from a serving base station, the context acquisition request message is used to acquire the context of a terminal device, the terminal device is configured to receive a multicast service in an RRC inactive state. The processing module 910 is used to determine whether the serving base station can provide the terminal device with the multicast service required to be received. The transceiver module 920 is also used to send a first message to the terminal device through the serving base station, the first message is used to notify the terminal device to continue to remain in the RRC inactive state.

As an optional implementation manner, the transceiver module 920 is further configured to send a context acquisition failure message to the serving base station, where the context acquisition failure message includes the first message.

As an optional implementation manner, the first message includes transmission parameter configuration information of the multicast service joined by the terminal device, or the context acquisition failure message includes transmission parameter configuration information of the multicast service joined by the terminal device.

As an optional implementation method, the context acquisition request message includes one or more of the following: first information, second information, third information, fourth information, first reason value, third reason value or fourth reason value. Among them, the first information is used to indicate that the serving base station can provide multicast services for terminal devices in the RRC inactive state. The second information includes information on the list of multicast services that the serving base station can provide to terminal devices in the RRC inactive state. The third information includes the transmission configuration parameters of the multicast services in the list of multicast services that the serving base station can provide to terminal devices in the RRC inactive state. The fourth information is used to indicate that the serving base station expects the terminal device to continue to remain in the RRC inactive state.

As an optional implementation manner, the context acquisition request message includes a fourth reason value, and the first message includes information about the multicast service to which the terminal device joins.

It should be understood that the processing module 910 in the embodiment of the present application can be implemented by a processor or a processor-related circuit component, and the transceiver module 920 can be implemented by a transceiver or a transceiver-related circuit component or a communication interface.

FIG10 is a schematic block diagram of a communication device 1000 provided in an embodiment of the present application. The communication device 1000 may be a terminal device that can implement the functions of the terminal device in the method provided in the embodiment of the present application. The communication device 1000 may also be a device that can support the terminal device to implement the corresponding functions in the method provided in the embodiment of the present application, wherein the communication device 1000 may be a chip system. In the embodiment of the present application, the chip system may be composed of a chip, or may include a chip and other discrete devices. For specific functions, please refer to the description in the above method embodiment. The communication device 1000 may also be a network device that can implement the functions of a serving base station or an anchor base station in the method provided in the embodiment of the present application. The communication device 1000 may also be a device that can support a network device to implement the corresponding functions in the method provided in the embodiment of the present application, wherein the communication device 1000 may be a chip system. In the embodiment of the present application, the chip system may be composed of a chip, or may include a chip and other discrete devices. For specific functions, please refer to the description in the above method embodiment.

The communication device 1000 includes one or more processors 1001, which can be used to implement or support the communication device 1000 to implement the function of the terminal device in the method provided in the embodiment of the present application. Please refer to the detailed description in the method example for details, which will not be repeated here. One or more processors 1001 can also be used to implement or support the communication device 1000 to implement the function of the serving base station or anchor base station in the method provided in the embodiment of the present application. Please refer to the detailed description in the method example for details, which will not be repeated here. The processor 1001 can also be referred to as a processing unit or a processing module, which can implement certain control functions. The processor 1001 can be a general-purpose processor or a dedicated processor, etc. For example, it includes: a central processing unit, an application processor, a modem processor, a graphics processor, an image signal processor, a digital signal processor, a video codec processor, a controller, a memory, and/or a neural network processor, etc. The central processing unit can be used to control the communication device 1000, execute software programs and/or process data. Different processors can be independent devices or integrated in one or more processors, for example, integrated in one or more application-specific integrated circuits.

Optionally, the communication device 1000 includes one or more memories 1002 for storing instructions 1004, and the instructions can be executed on the processor 1001, so that the communication device 1000 performs the method described in the above method embodiment. The memory 1002 and the processor 1001 can be set separately or integrated together, and the memory 1002 and the processor 1001 can also be considered to be coupled. The coupling in the embodiment of the present application The coupling is an indirect coupling or communication connection between devices, units or modules, which may be electrical, mechanical or other forms, and is used for information exchange between devices, units or modules. The processor 1001 may cooperate with the memory 1002. At least one of the at least one memory may be included in the processor. It should be noted that the memory 1002 is not necessary, so it is illustrated by a dotted line in FIG. 10.

Optionally, data may also be stored in the memory 1002. The processor and memory may be provided separately or integrated together. In an embodiment of the present application, the memory 1002 may be a non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD), etc., or a volatile memory (volatile memory), such as a random-access memory (RAM). The memory is any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory in the embodiment of the present application may also be a circuit or any other device that can realize a storage function, for storing program instructions and/or data.

Optionally, the communication device 1000 may include instructions 1003 (sometimes also referred to as codes or programs), and the instructions 1003 may be executed on the processor so that the communication device 1000 performs the method described in the above embodiment. The processor 1001 may store data.

Optionally, the communication device 1000 may further include a transceiver 1005 and an antenna 1006. The transceiver 1005 may be referred to as a transceiver unit, a transceiver module, a transceiver, a transceiver circuit, a transceiver, an input/output interface, etc., and is used to implement the transceiver function of the communication device 1000 through the antenna 1006.

The processor 1001 and the transceiver 1005 described in the present application may be implemented in an integrated circuit (IC), an analog IC, a radio frequency integrated circuit (RFID), a mixed signal IC, an ASIC, a printed circuit board (PCB), or an electronic device. The communication device described in this article may be an independent device (e.g., an independent integrated circuit, a mobile phone, etc.), or may be a part of a larger device (e.g., a module that can be embedded in other devices). For details, please refer to the aforementioned description of the terminal device and the network device, which will not be repeated here.

Optionally, the communication device 1000 may also include one or more of the following components: a wireless communication module, an audio module, an external memory interface, an internal memory, a universal serial bus (USB) interface, a power management module, an antenna, a speaker, a microphone, an input/output module, a sensor module, a motor, a camera, or a display screen, etc. It is understood that in some embodiments, the communication device 1000 may include more or fewer components, or some components may be integrated, or some components may be separated. These components may be implemented in hardware, software, or a combination of software and hardware.

It should be noted that the communication device in the above embodiments may be a terminal device, or a circuit, or a chip applied to a terminal device, or other combination devices, components, etc. having the functions of the above terminal devices. When the communication device is a terminal device, the transceiver module may be a transceiver, which may include an antenna and a radio frequency circuit, etc., and the processing module may be a processor, such as a central processing unit (CPU). The communication device in the above embodiments may be a network device, or a circuit, or a chip applied to a network device, or other combination devices, components, etc. having the functions of the above network devices. When the communication device is a service base station or an anchor base station, the transceiver module may be a transceiver, which may include an antenna and a radio frequency circuit, etc., and the processing module may be a processor, such as a central processing unit (CPU). When the communication device is a component having the functions of the above terminal device or a service base station or an anchor base station, the transceiver module may be a radio frequency unit, and the processing module may be a processor. When the communication device is a chip system, the communication device may be a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on chip (SoC), a CPU, a network processor (NP), a digital signal processor (DSP), a microcontroller unit (MCU), a programmable logic device (PLD) or other integrated chips. The processing module may be a processor of the chip system. The transceiver module or the communication interface may be an input/output interface or an interface circuit of the chip system. For example, the interface circuit may be a code/data read/write interface circuit. The interface circuit may be used to receive code instructions (the code instructions are stored in a memory, may be read directly from the memory, or may be read from the memory through other devices) and transmit them to the processor; the processor may be used to run the code instructions to execute the method in the above method embodiment. For another example, the interface circuit may also be a signal transmission interface circuit between a communication processor and a transceiver.

When the communication device is a chip-type device or circuit, the device may include a transceiver unit and a processing unit, wherein the transceiver unit may be an input/output circuit and/or a communication interface; and the processing unit may be an integrated processor or microprocessor or integrated circuit.

The embodiment of the present application also provides a communication system, specifically, the communication system includes a terminal device, a serving base station and an anchor base station. Alternatively, the communication system may also include more terminal devices and base stations. Exemplarily, the communication system includes a terminal device, a serving base station and an anchor base station for implementing the related functions of one or more of the above-mentioned Figures 6 to 8. Please refer to the relevant description in the above-mentioned method embodiment for details, which will not be repeated here.

An embodiment of the present application also provides a computer-readable storage medium, including instructions, which, when executed on a computer, enables the computer to execute the method executed by the terminal device, service base station or anchor base station in one or more of Figures 6-8.

A computer program product is also provided in an embodiment of the present application, including instructions, which, when executed on a computer, enables the computer to execute the method executed by the terminal device, the serving base station or the anchor base station in one or more of Figures 6 to 8.

The embodiment of the present application provides a chip system, which includes a processor and may also include a memory, for implementing the functions of the terminal device in the aforementioned method; or for implementing the functions of the serving base station or anchor base station in the aforementioned method. The chip system may be composed of a chip, or may include a chip and other discrete devices.

It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

Those of ordinary skill in the art will appreciate that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the part of the technical solution of the present application that contributes essentially or the part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM), RAM, disk or CD-ROM and other media that can store program codes.

Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

A communication method, comprising:

The terminal device determines a cause value of a connection recovery request message, wherein the terminal device is configured to receive a multicast service in a radio resource control (RRC) inactive state, and the terminal device is in an RRC inactive state;

The terminal device sends the connection restoration request message to the first network device, where the connection restoration request message includes the cause value;

The terminal device receives a first message from the first network device, wherein the first message is used to notify the terminal device to remain in an RRC inactive state;

The terminal device receives the multicast service from the first network device.
The method according to claim 1, wherein the terminal device determines the cause value of the connection recovery request message, comprising:

The terminal device has multicast service data to be transmitted, and the cell of the first network device can provide multicast service for the terminal device in the RRC inactive state, and the terminal device determines that the cause value is a first cause value; or,

The cell of the first network device cannot provide a multicast service for a terminal device in an RRC inactive state, and the terminal device determines that the cause value is a second cause value; or,

The terminal device receives a first notification message from the first network device, and the terminal device determines that the cause value is a third cause value, wherein the first notification message is used to notify the terminal device to send the connection recovery request message for the multicast service; or

The terminal device receives a second notification message from the first network device, and the terminal device determines that the cause value is a fourth cause value, wherein the second notification message is used to indicate counting of terminal devices that receive multicast services and are in an RRC inactive state.
The method according to claim 1 or 2, characterized in that the terminal device sends a connection recovery request message to the first network device, comprising:

If any one or more of the following conditions are met, the terminal device sends the connection recovery request message to the first network device:

The cell of the first network device cannot provide a multicast service for a terminal device in an RRC inactive state;

The terminal device cannot obtain the transmission configuration information of the multicast service joined by the terminal device from the cell of the first network device;

The cell of the first network device can provide a multicast service for a terminal device in an RRC inactive state, and the terminal device cannot obtain transmission configuration information of the multicast service joined by the terminal device from the cell of the first network device;

The terminal device receives the first notification message of the first network device;

The terminal device receives the second notification message from the first network device.
The method according to claim 2 or 3, characterized in that the method further comprises:

The terminal device determines whether the cell of the first network device can provide multicast services for the terminal device in the RRC inactive state based on the system message or multicast control channel MCCH of the cell of the first network device, and the system message includes indication information for indicating whether the cell of the first network device supports multicast services in the RRC inactive state.
The method according to claim 4, characterized in that the terminal device determines whether the cell of the first network device can provide a multicast service for the terminal device in an RRC inactive state according to the MCCH of the cell of the first network device, comprising:

The MCCH of the cell of the first network device includes configuration information for the multicast service, and the terminal device determines that the cell of the first network device can provide the multicast service for the terminal device in the RRC inactive state.
A communication method, comprising:

The first network device receives a connection recovery request message from the terminal device, where the connection recovery request message includes a cause value;

The first network device sends a context acquisition request message to a second network device of the terminal device according to the cause value, wherein the context acquisition request message is used to acquire the context of the terminal device, and the terminal device is configured to receive a multicast service in an RRC inactive state;

The first network device receives a first message sent from the second network device, where the first message is used to notify the terminal device to remain in an RRC inactive state.
The method according to claim 6, characterized in that

The terminal device has multicast service data to be transmitted, and the first network device can provide multicast service for the terminal device in RRC inactive state, and the cause value is a first cause value; or,

The first network device cannot provide a multicast service for a terminal device in an RRC inactive state, and the cause value is a second cause value; or,

The terminal device receives a first notification message from the first network device, and the cause value is a third cause value, wherein the first notification message is used to notify the terminal device to send the connection recovery request message for the multicast service; or

The terminal device receives a second notification message from the first network device, and the cause value is a fourth cause value, wherein the second notification message is used to indicate counting of terminal devices in an RRC inactive state that receive multicast services.
The method according to claim 7, wherein the context acquisition request message includes one or more of the following:

First information, where the first information is used to indicate that the first network device can provide a multicast service for a terminal device in an RRC inactive state;

second information, the second information comprising information of a list of multicast services that the first network device can provide for a terminal device in an RRC inactive state;

The third information includes transmission configuration parameters of multicast services in a multicast service list that the first network device can provide to a terminal device in an RRC inactive state;

Fourth information, the fourth information is used to indicate that the first network device expects the terminal device to continue to remain in the RRC inactive state;

the first cause value;

The third cause value and fourth information, the fourth information being used to indicate that the first network device expects the terminal device to remain in an RRC inactive state;

The fourth cause value.
The method according to claim 8, characterized in that the method further comprises:

The first network device determines, according to the first cause value included in the connection recovery request message, that the context acquisition request message includes one or more of the first information, the second information, or the third information; or

The first network device determines, according to the third cause value included in the connection recovery request message, that the context acquisition request message includes the fourth information.
The method according to any one of claims 6 to 9, wherein the first network device receives the first message sent by the second network device, comprising:

The first network device receives a context acquisition failure message sent by the second network device, where the context acquisition failure message includes the first message.
The method as claimed in claim 10 is characterized in that the first message includes transmission parameter information of the multicast service joined by the terminal device, or the context acquisition failure message includes transmission parameter information of the multicast service joined by the terminal device or a list of multicast services joined by the terminal device.
The method according to claim 8, characterized in that the method further comprises:

The cause value is the fourth cause value, and the first network device receives information about the multicast service joined by the terminal device from the second network device;

The first network device counts the terminal devices accessing the multicast service provided by the first network device according to the multicast service joined by the terminal devices.
A communication method, comprising:

The second network device receives a context acquisition request message from the first network device, where the context acquisition request message is used to acquire a context of a terminal device, where the terminal device is configured to receive a multicast service in an RRC inactive state;

The second network device determines that the first network device can provide the terminal device with the required multicast service, and the second network device sends a first message to the terminal device through the first network device, where the first message is used to notify the terminal device to continue to remain in the RRC inactive state.
The method according to claim 13, characterized in that before the second network device sends the first message to the terminal device through the first network device, the method further comprises:

The second network device sends a context acquisition failure message to the first network device, where the context acquisition failure message includes the first message.
The method as claimed in claim 14 is characterized in that the first message includes transmission parameter configuration information of the multicast service joined by the terminal device, or the context acquisition failure message includes transmission parameter configuration information of the multicast service joined by the terminal device.
The method according to any one of claims 13 to 15, characterized in that the context acquisition request message includes one of the following or more:

First information, where the first information is used to indicate that the first network device can provide a multicast service for a terminal device in an RRC inactive state;

second information, the second information comprising information of a list of multicast services that the first network device can provide for a terminal device in an RRC inactive state;

third information, the third information including transmission configuration parameters of multicast services in a multicast service list that the first network device can provide to a terminal device in an RRC inactive state; or,

Fourth information, the fourth information is used to indicate that the first network device expects the terminal device to continue to remain in the RRC inactive state;

A first cause value, wherein the first cause value is used to indicate that the reason why the terminal device sends the recovery request is that the terminal device has multicast service data to be transmitted, and the first network device can provide multicast services for the terminal device in the RRC inactive state;

A third cause value, where the third cause value is used to indicate that the reason why the terminal device sends the recovery request is that the terminal device receives a first notification message sent by the first network device, where the first notification message is used to notify the terminal device to send the connection recovery request message for the multicast service;

A fourth reason value, wherein the fourth reason value is used to indicate that the reason why the terminal device sends the recovery request is that the terminal device receives a second notification message sent by the first network device, and the second notification message is used to indicate counting of terminal devices in an RRC inactive state that receive multicast services.
The method as claimed in claim 16 is characterized in that the context acquisition request message includes the fourth reason value, and the first message includes information about the multicast service joined by the terminal device.
A communication device, characterized in that it comprises a processing module and a transceiver module;

The processing module is used to determine a cause value of a connection recovery request message, wherein the communication device is configured to receive a multicast service in a radio resource control (RRC) inactive state, and the communication device is in an RRC inactive state;

The transceiver module is used to: send the connection recovery request message to the first network device, where the connection recovery request message includes the identification information of the communication device and the cause value;

Receive a first message from the first network device, and receive a multicast service from the first network device, wherein the first message is used to notify the communication device to remain in an RRC inactive state.
The device according to claim 18, characterized in that the processing module is specifically used to:

The communication device has multicast service data to be transmitted, and the cell of the first network device can provide multicast service for the terminal device in the RRC inactive state, and determines that the cause value is a first cause value; or,

The cell of the first network device cannot provide a multicast service for the terminal device in the RRC inactive state, and determines that the cause value is a second cause value; or,

The transceiver module receives a first notification message from the first network device, and determines that the cause value is a third cause value, wherein the first notification message is used to notify the communication device to send the connection recovery request message for the multicast service; or

The transceiver module receives a second notification message from the first network device, and determines that the cause value is a fourth cause value, wherein the second notification message is used to indicate counting of communication devices that receive multicast services and are in an RRC inactive state.
The device according to claim 19, wherein the transceiver module is specifically configured to: send the connection recovery request message to the first network device when any one or more of the following conditions are met:

The cell of the first network device cannot provide a multicast service for a communication device in an RRC inactive state;

The transmission configuration information of the multicast service joined by the communication device cannot be obtained from the cell of the first network device;

The cell of the first network device can provide a multicast service for a communication device in an RRC inactive state, and transmission configuration information of the multicast service joined by the communication device cannot be obtained from the cell of the first network device;

Receiving the first notification message of the first network device;

Receive the second notification message from the first network device.
The device according to claim 19 or 20, characterized in that the processing module is further used for:

Whether the cell of the first network device can provide multicast services for a communication device in an RRC inactive state is determined based on a system message or a multicast control channel MCCH of the cell of the first network device, wherein the system message includes indication information for indicating whether the cell of the first network device supports multicast services in an RRC inactive state.
The device according to claim 21, characterized in that the processing module is specifically used to:

The MCCH of the cell of the first network device includes configuration information for the multicast service, and determines that the cell of the first network device can provide the multicast service for the terminal device in the RRC inactive state.
A communication device, characterized in that it comprises a processing module and a transceiver module;

The transceiver module is used to receive a connection recovery request message from a terminal device, wherein the connection recovery request message includes identification information of the terminal device and a cause value;

The processing module is used to determine the cause value;

The transceiver module is also used to send a context acquisition request message to the second network device of the terminal device, and receive a first message sent by the second network device, wherein the context acquisition request message is used to obtain the context of the terminal device, and the terminal device is configured to receive multicast services in an RRC inactive state, and the first message is used to notify the terminal device to remain in an RRC inactive state.
The device according to claim 23, characterized in that

The terminal device has multicast service data to be transmitted, and the communication device is capable of providing multicast services for the terminal device in the RRC inactive state, and the cause value is the first cause value; or,

The communication device cannot provide a multicast service for a terminal device in an RRC inactive state, and the cause value is a second cause value; or,

The terminal device receives a first notification message from the communication apparatus, wherein the cause value is a third cause value, wherein the first notification message is used to notify the terminal device to send the connection recovery request message for the multicast service; or

The terminal device receives a second notification message from the communication apparatus, and the cause value is a fourth cause value, wherein the second notification message is used to indicate counting of terminal devices in an RRC inactive state that receive multicast services.
The apparatus of claim 24, wherein the context acquisition request message includes one or more of the following:

First information, where the first information is used to indicate that the communication device can provide a multicast service for a terminal device in an RRC inactive state;

second information, the second information comprising information of a multicast service list that the communication device can provide for a terminal device in an RRC inactive state;

third information, the third information comprising transmission configuration parameters of multicast services in a multicast service list that the communication device can provide for a terminal device in an RRC inactive state;

fourth information, the fourth information being used to indicate that the communication apparatus expects the terminal device to continue to remain in the RRC inactive state;

the first cause value;

The third cause value and fourth information, the fourth information being used to indicate that the first network device expects the terminal device to remain in an RRC inactive state;

The fourth cause value.
The device according to claim 25, characterized in that the processing module is further used for:

Determining, according to the first cause value included in the connection restoration request message, that the context acquisition request message includes one or more of the first information, the second information, or the third information; or,

According to the third cause value included in the connection restoration request message, it is determined that the context acquisition request message includes the fourth information.
The device according to any one of claims 23 to 26, wherein the processing module is specifically used to:

A context acquisition failure message sent from the second network device is received, where the context acquisition failure message includes the first message.
The apparatus as described in claim 27 is characterized in that the first message includes transmission parameter information of the multicast service joined by the terminal device, or the context acquisition failure message includes transmission parameter information of the multicast service joined by the terminal device or a list of multicast services joined by the terminal device.
The device according to claim 25, characterized in that the transceiver module is further used to: receive information about the multicast service joined by the terminal device from the second network device, wherein the cause value is the fourth cause value;

The processing module is further used to count the terminal devices accessing the multicast service provided by the first network device according to the multicast service joined by the terminal devices.
A communication device, characterized in that it comprises a processing module and a transceiver module;

The transceiver module is used to receive a context acquisition request message from a first network device, wherein the context acquisition request message is used to acquire a context of a terminal device, and the terminal device is configured to receive a multicast service in an RRC inactive state;

The processing module is used to determine that the first network device can provide the terminal device with a multicast service required to be received;

The transceiver module is also used to send a first message to the terminal device through the first network device, and the first message is used to notify the terminal device to continue to remain in the RRC inactive state.
The device as described in claim 30 is characterized in that the transceiver module is also used to send a context acquisition failure message to the first network device, and the context acquisition failure message includes the first message.
The apparatus as described in claim 30 is characterized in that the first message includes transmission parameter configuration information of the multicast service joined by the terminal device, or the context acquisition failure message includes transmission parameter configuration information of the multicast service joined by the terminal device.
The apparatus according to any one of claims 29 to 32, wherein the context acquisition request message includes one or more of the following:

First information, where the first information is used to indicate that the first network device can provide a multicast service for a terminal device in an RRC inactive state;

second information, the second information comprising information of a list of multicast services that the first network device can provide for a terminal device in an RRC inactive state;

third information, the third information including transmission configuration parameters of multicast services in a multicast service list that the first network device can provide to a terminal device in an RRC inactive state; or,

Fourth information, the fourth information is used to indicate that the first network device expects the terminal device to continue to remain in the RRC inactive state;

A first cause value, wherein the first cause value is used to indicate that the reason why the terminal device sends the recovery request is that the terminal device has multicast service data to be transmitted, and the first network device can provide multicast services for the terminal device in the RRC inactive state;

a third cause value and fourth information, wherein the third cause value is used to indicate that the reason why the terminal device sends the recovery request is that the terminal device receives a first notification message sent by the first network device, the first notification message is used to notify the terminal device to send the connection recovery request message for the multicast service, and the fourth information is used to indicate that the first network device expects the terminal device to remain in an RRC inactive state;

A fourth reason value, wherein the fourth reason value is used to indicate that the reason why the terminal device sends the recovery request is that the terminal device receives a second notification message sent by the first network device, and the second notification message is used to indicate counting of terminal devices in an RRC inactive state that receive multicast services.
The apparatus as described in claim 33 is characterized in that the context acquisition request message includes the fourth reason value, and the first message includes information about the multicast service joined by the terminal device.
A communication device, characterized in that the communication device includes a processor and a memory, the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory, so that the communication device performs the method as described in any one of claims 1 to 5; or, the communication device performs the method as described in any one of claims 6 to 12; so that the communication device performs the method as described in any one of claims 13 to 17.
A communication system, characterized in that it includes a terminal device, a first network device and a second network device, wherein the terminal device is used to implement the method as described in any one of claims 1 to 5, the first network device is used to implement the method as described in any one of claims 6 to 12, and the second network device is used to implement the method as described in any one of claims 13 to 17.
A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program, and when the computer program is executed by a computer, the computer executes the method as described in any one of claims 1 to 5; or, the computer executes the method as described in any one of claims 6 to 12; or, the computer executes the method as described in any one of claims 13 to 17.
A computer program product, characterized in that the computer program product stores a computer program, and when the computer program is executed by a computer, the computer executes the method as described in any one of claims 1 to 5; or, the computer executes the method as described in any one of claims 6 to 12; or, the computer executes the method as described in any one of claims 13 to 17.