TW202408256A - Communication method and apparatus - Google Patents

Abstract

This application provides a communication method and apparatus. In this method, in case that a terminal has joined a multicast session, a core network device may notify an access network device that refuse to configure an eDRX under an inactive state for the terminal, or indicate to the access network device that an eDRX under an inactive state is inapplicable to the terminal, so that when the access network device changes the state of the terminal to be an inactive state, the access network device could avoid configuring the terminal to be an eDRX under an inactive state according to the notification or the indication from the core network device, thereby realizing the management of an eDRX for the terminal, and ensuring the transmission of a multicast service.

Description

Communication method and communication device

The embodiments of the present application relate to the field of communication, and more specifically, to a communication method and a communication device.

The access network equipment can save the energy consumption of the terminal by configuring extended discontinuous reception (eDRX) for the terminal. The terminal in the sleep state of eDRX is unreachable, that is, the terminal cannot receive downlink data.

Currently, a terminal can receive multicast service data (which can be referred to as multicast data) by joining a multicast session, and during the transmission process of multicast data, the terminal remains in the connected state. Due to the limited capacity of the access network equipment, the access network equipment only supports a limited number of terminals to remain connected. In order to ensure the transmission of multicast data when the access network equipment resources are insufficient, a solution is proposed: the terminal receives multicast data in an inactive state. Specifically, when the access network equipment resources are insufficient, the access network equipment can convert the terminal that has joined the multicast session into an inactive state, and notify the terminal to receive multicast data through broadcast or other methods, thereby realizing the terminal Receive multicast data in inactive state. In the above scenario, how to manage eDRX of terminals in an inactive state has become an urgent problem to be solved.

This application provides a communication method and communication device, which can realize eDRX management of terminals in an inactive state.

In the first aspect, a communication method is provided. The method can be executed by a core network device or by a module or unit in the core network device. For convenience of description, it will be collectively referred to as the core network device below.

The method includes: the core network device learns that the terminal has joined the multicast session; the core network device sends first information, the first information is used to notify the refusal to configure eDRX in an inactive state for the terminal, or the The first information is used to indicate that the terminal is not suitable for eDRX in the inactive state.

Optionally, when the first information is used to notify the refusal to configure eDRX in the inactive state for the terminal, the core network device sends the first information to the access network device.

Optionally, when the first information is used to indicate that the terminal is not suitable for eDRX in the inactive state, the core network device sends the first information to the access network device or the terminal.

Based on the above method, when the terminal has joined the multicast session, the core network device can notify the access network device to refuse to configure eDRX in the inactive state for the terminal, or instruct the terminal not to use eDRX in the inactive state in order to facilitate access. The network access device does not configure eDRX in the inactive state for the terminal according to the notification or instruction of the core network device; or the core network device indicates to the terminal that the terminal does not apply eDRX in the inactive state so that the terminal can request to update the terminal in the access network device. The eDRX capability (updated to not support eDRX) enables the access network equipment to not configure eDRX in the inactive state for the terminal based on the updated eDRX capability of the terminal, thereby realizing eDRX management of the terminal.

In addition, when the terminal has joined the multicast session, not configuring eDRX in the inactive state for the terminal helps to ensure the transmission of multicast data corresponding to the multicast session.

With reference to the first aspect, in a possible implementation manner, the core network device sends the first information, including: when at least one of the following conditions is met, the core network device sends the first information: for the The access network equipment provided by the terminal does not support eDRX, the terminal does not support eDRX, or the multicast session meets preset conditions; wherein the preset conditions are: the multicast session is active, the The multicast service corresponding to the multicast session does not support eDRX, or the multicast session is in an active state and the multicast service corresponding to the multicast session does not support eDRX.

The "following conditions" here refer to: the access network equipment that provides services for the terminal does not support eDRX, the terminal does not support eDRX, or the multicast session meets preset conditions.

Based on the above method, after the core network device learns that the terminal has joined the multicast session, the core network device can further determine whether the above conditions are met. When the above conditions are met, the core network device sends the first message to notify the refusal to configure the terminal. eDRX in the inactive state or indicating that the terminal is not applicable to eDRX in the inactive state. In this way, the judgment results of the core network equipment can be made more accurate.

In conjunction with the first aspect or any implementation thereof, in another possible implementation, when the first information is used to notify a refusal to configure eDRX in an inactive state for the terminal, the first information includes rejection information , the rejection information is used to indicate a refusal to configure eDRX in an inactive state for the terminal. In conjunction with the first aspect or any implementation thereof, in another possible implementation, the method further includes: the core network device receiving second information, the second information being used to request to configure inactivation for the terminal. eDRX in state.

Based on the above method, when the access network device determines to convert the terminal to the inactive state, it can request the core network device to configure eDRX in the inactive state for the terminal. The core network device receives the request from the access network device. Finally, it can be combined with the fact that the terminal has joined the multicast session to determine that eDRX in the inactive state is not allowed to be configured for the terminal, thereby rejecting the request of the access network device, so that the access network device does not configure the inactive state for the terminal after the request is rejected. eDRX, so that eDRX in the inactive state is not configured for the terminal when the terminal has joined the multicast session, which helps to ensure the transmission of multicast data corresponding to the multicast session.

In conjunction with the first aspect or any implementation thereof, in another possible implementation, the rejection information includes a reason for refusing to configure eDRX in an inactive state for the terminal; wherein the reason includes at least one of the following: The terminal has joined a multicast session, the access network equipment that provides services to the terminal does not support eDRX, the terminal does not support eDRX, or the multicast session meets preset conditions; wherein the preset conditions are: The multicast session is in an active state and the multicast service corresponding to the multicast session does not support eDRX, or the multicast session is in an active state and the multicast service corresponding to the multicast session does not support eDRX.

With reference to the first aspect or any implementation thereof, in another possible implementation, the method further includes: the core network device receiving third information from the access network device, and the third information is used to Indicates that the access network equipment does not support eDRX.

Based on the above method, the access network device can report to the core network device whether it supports eDRX, so that the core network device can determine whether to allow inactive eDRX to be configured for the terminal based on the eDRX capability of the access network device.

Combined with the first aspect or any implementation thereof, in another possible implementation, the core network device is an access and mobility management function network element or a session management function network element.

Combined with the first aspect or any implementation thereof, in another possible implementation, the core network device is an access and mobility management function network element, and the method further includes: the access and mobility management function The network element receives service information from the session management function, where the service information is used to indicate that the multicast service corresponding to the multicast session does not support eDRX.

Based on the above method, the core network device can determine whether to allow eDRX in the inactive state to be configured for the terminal based on whether the multicast service corresponding to the multicast session that the terminal has joined supports eDRX.

With reference to the first aspect or any implementation thereof, in another possible implementation, the service information includes the type of the multicast service, and the type is a delay-sensitive type.

Combined with the first aspect or any implementation thereof, in another possible implementation, the core network device is an access and mobility management function network element, and the method further includes: the access and mobility management function The network element receives fourth information from the session management function network element, where the fourth information is used to indicate that the terminal has joined the multicast session.

Based on the above method, the session management function network element provides the access and mobility management function network element with information that the terminal has joined the multicast session, so that the access and mobility management function network element can send the third message based on the terminal having joined the multicast session. a message.

In the second aspect, a communication method is provided. The method can be executed by the access network device or by a module or unit in the access network device. For convenience of description, it will be collectively referred to as the access network device below.

The method includes: when the access network device determines to convert the terminal to the inactive state, the access network device sends second information to the core network device, the second information is used to request to configure the inactive state for the terminal. eDRX in the inactive state; the access network device receives the first information from the core network device, the first information is used to notify the refusal to configure eDRX in the inactive state for the terminal; the access network device According to the first information, eDRX in an inactive state is not configured for the terminal.

Based on the above method, when the access network device determines to convert the terminal to the inactive state, it can request the core network device to configure eDRX in the inactive state for the terminal, and do not configure the eDRX for the terminal after the request is rejected by the core network device. The terminal configures eDRX in the inactive state, so that eDRX in the inactive state is not configured for the terminal when the terminal has joined the multicast session, thereby realizing eDRX management of the terminal.

In addition, when the terminal has joined the multicast session, not configuring eDRX in the inactive state for the terminal helps to ensure the transmission of multicast data corresponding to the multicast session.

In conjunction with the second aspect, in a possible implementation manner, the first information includes rejection information, and the rejection information is used to indicate a refusal to configure eDRX in an inactive state for the terminal.

In conjunction with the second aspect or any implementation thereof, in another possible implementation, the rejection information includes a reason for refusing to configure eDRX in an inactive state for the terminal; wherein the reason includes at least one of the following: The terminal has joined the multicast session, the access network device does not support eDRX, the terminal does not support eDRX, or the multicast session meets a preset condition; wherein the preset condition is: the multicast session In the active state, the multicast service corresponding to the multicast session does not support eDRX, or the multicast session is in the active state and the multicast service corresponding to the multicast session does not support eDRX.

Combined with the second aspect or any implementation thereof, in another possible implementation, the core network device is an access and mobility management function network element or a session management function network element.

In the third aspect, a communication method is provided. The method can be executed by the access network device or by a module or unit in the access network device. For convenience of description, it will be collectively referred to as the access network device below.

The method includes: the access network device receives first information from the core network device, the first information is used to indicate that the terminal is not suitable for eDRX in the inactive state; when the access network device determines to convert the terminal When in the inactive state, the access network device does not configure eDRX in the inactive state for the terminal according to the first information.

Based on the above method, when the terminal has joined the multicast session, the core network device can indicate to the access network device that the terminal is not suitable for eDRX in the inactive state, and the access network device can not configure it for the terminal according to the instruction of the core network device. eDRX in the inactive state to achieve eDRX management of the terminal.

In addition, when the terminal has joined the multicast session, not configuring eDRX in the inactive state for the terminal helps to ensure the transmission of multicast data corresponding to the multicast session.

Combined with the third aspect, in a possible implementation manner, the core network device is an access and mobility management function network element or a session management function network element.

In the fourth aspect, a communication method is provided. The method may be executed by the access and mobility management function network element, or may be executed by a module or unit in the access and mobility management function network element. For the convenience of description, the following They are collectively called access and mobility management functional network elements.

The method includes: the access and mobility management function network element receives second information from the access network device, the second information is used to request to configure eDRX in an inactive state for the terminal; the access and mobility The management function network element sends the second information to a first session management function network element and a second session management function network element. The first session management function network element is used to manage the multicast session associated with the terminal. Unicast session, the second session management function network element is used to manage a unicast session that is not associated with the multicast session of the terminal; the access and mobility management function network element receives information from the first session management function The first information of the functional network element, the first information is used to notify the refusal to configure eDRX in the inactive state for the terminal; the access and mobility management functional network element sends the said first information, and/or, sending fifth information to the second session management function network element, where the fifth information is used to trigger the second session management function network element to stop configuring the inactive state for the terminal. eDRX.

Based on the above method, the access network device interacts with the first session management function network element through the access and mobility management function network element. The access and mobility management function network element may request the first session management function network element and the second session management function network element to configure eDRX in the inactive state for the terminal, and when the access and mobility management function network element receives After the first information from the first session management function network element, the access and mobility management function network element sends a fifth information to the second session management function network element to trigger the second session management function network element to stop being the terminal. Configure eDRX in the inactive state to implement eDRX management of the terminal.

In addition, when the terminal has joined the multicast session, not configuring eDRX in the inactive state for the terminal helps to ensure the transmission of multicast data corresponding to the multicast session.

It should be noted that although the information received by the access and mobility management function network element and the information sent by the access and mobility management function network element are both called first information or second information, the access and mobility management function network element The information received by the management function network element and the information sent by the access and mobility management function network element can be implemented in the same way or in different ways (for example, through different messages and/or information elements), without limitation.

In conjunction with the fourth aspect, in a possible implementation manner, the first information includes rejection information, and the rejection information is used to indicate a refusal to configure eDRX in an inactive state for the terminal.

In conjunction with the fourth aspect or any implementation thereof, in another possible implementation, the rejection information includes a reason for refusing to configure eDRX in an inactive state for the terminal; wherein the reason includes at least one of the following: The terminal has joined the multicast session, the access network device does not support eDRX, the terminal does not support eDRX, or the multicast session meets a preset condition; wherein the preset condition is: the multicast session In the active state, the multicast service corresponding to the multicast session does not support eDRX, or the multicast session is in the active state and the multicast service corresponding to the multicast session does not support eDRX.

In the fifth aspect, a communication method is provided. The method can be executed by the access network device or by a module or unit in the access network device. For convenience of description, it will be collectively referred to as the access network device below.

The method includes: the access network device learns that the terminal has joined the multicast session; and when the access network device determines to convert the terminal to an inactive state, the access network device does not configure inactivation for the terminal. eDRX in state.

Based on the above method, when the terminal has joined the multicast session, the access network device does not configure eDRX in the inactive state for the terminal, thereby realizing eDRX management of the terminal. In addition, when the terminal has joined the multicast session, not configuring eDRX in the inactive state for the terminal helps to ensure the transmission of multicast data corresponding to the multicast session.

With reference to the fifth aspect, in a possible implementation manner, the access network device does not configure eDRX for the terminal, including: when at least one of the following conditions is met, the access network device does not configure eDRX for the terminal. The terminal configures eDRX in an inactive state: the access network device does not support eDRX, the terminal does not support eDRX, or the multicast session meets a preset condition; wherein the preset condition is: the multicast The session is in an active state and the multicast service corresponding to the multicast session does not support eDRX, or the multicast session is in an active state and the multicast service corresponding to the multicast session does not support eDRX.

The "following conditions" here refer to: the access network device does not support eDRX, the terminal does not support eDRX, or the multicast session meets preset conditions.

Based on the above method, after the access network device learns that the terminal has joined the multicast session, the access network device can further determine whether the above conditions are met. When the above conditions are met, the access network device does not configure the inactive state for the terminal. eDRX. In this way, the judgment result of the access network device can be made more accurate.

With reference to the fifth aspect or any implementation thereof, in another possible implementation, the method further includes: the access network device receiving service information from the session management function, the service information being used to indicate that the multiple The multicast service corresponding to the broadcast session does not support eDRX.

Based on the above method, the access network device can determine whether to allow eDRX in the inactive state to be configured for the terminal based on whether the multicast service corresponding to the multicast session that the terminal has joined supports eDRX.

Combined with the fifth aspect or any implementation thereof, in another possible implementation, the service information includes the type of the multicast service, and the type is a delay-sensitive type.

In a sixth aspect, a communication method is provided. The method can be executed by a terminal or by a module or unit in the terminal. For convenience of description, it will be collectively referred to as the terminal below.

The method includes: the terminal learns that the terminal has joined the multicast session and the terminal supports eDRX; and the terminal sends sixth information to the access network device, where the sixth information is used to indicate that the terminal does not support eDRX.

Based on the above method, when the terminal has joined the multicast session, the terminal that supports eDRX can provide the access network device with information that it does not support eDRX, so that the access network device can determine whether to convert the terminal into an inactive state. , eDRX in the inactive state can not be configured for the terminal according to the fact that the terminal does not support eDRX, thereby realizing eDRX management of the terminal.

In addition, when the terminal has joined the multicast session, not configuring eDRX in the inactive state for the terminal helps to ensure the transmission of multicast data corresponding to the multicast session.

With reference to the sixth aspect, in a possible implementation manner, the terminal sends sixth information to the access network device, including: when at least one of the following conditions is met, the terminal sends The sixth information: the first information from the core network device is received, the access network device does not support eDRX, the terminal does not support eDRX, or the multicast session meets preset conditions; wherein, the third A message is used to indicate that the terminal is not suitable for eDRX in the inactive state. The preset conditions are: the multicast session is in the active state, the multicast service corresponding to the multicast session does not support eDRX, or the The multicast session is active and the multicast service corresponding to the multicast session does not support eDRX.

The "following conditions" here refer to: receiving the first information from the core network device, the access network device does not support eDRX, the terminal does not support eDRX, or the multicast session meets preset conditions.

Based on the above method, after learning that the terminal has joined the multicast session, the terminal can further determine whether the above condition is satisfied. When the above condition is satisfied, the terminal provides sixth information to the terminal. In this way, the judgment result of the terminal can be made more accurate.

Combined with the sixth aspect or any implementation thereof, in another possible implementation, the core network device is an access and mobility management function network element or a session management function network element.

Combined with the sixth aspect or any implementation thereof, in another possible implementation, the method further includes: the terminal receiving service information from the session management function, the service information being used to indicate that the multicast session corresponds to The multicast service does not support eDRX.

Based on the above method, the terminal can determine whether to provide the sixth information to the access network device according to whether the multicast service corresponding to the multicast session to which the terminal has joined supports eDRX.

With reference to the sixth aspect or any implementation thereof, in another possible implementation, the service information includes the type of the multicast service, and the type is a delay-sensitive type.

Combined with the sixth aspect or any implementation thereof, in another possible implementation, before the terminal sends the sixth information to the access network device, the method further includes: the terminal sends the sixth information to the access network device Send seventh information, where the seventh information is used to indicate that the terminal supports eDRX.

That is, when the current judgment result of the terminal is inconsistent with the eDRX capability reported to the access network device, the terminal can update its eDRX capability on the access network device.

Combined with the sixth aspect or any implementation thereof, in another possible implementation, the method further includes: after the terminal leaves all multicast sessions to which the terminal has joined, the terminal The network device sends eighth information, where the eighth information is used to indicate that the terminal supports eDRX.

That is, after the terminal leaves all multicast sessions that the terminal has joined, the terminal can request to update its eDRX capabilities on the access network equipment.

In the seventh aspect, a communication method is provided. The method can be executed by the session management function network element, or can be executed by a module or unit in the session management function network element. For convenience of description, it will be collectively referred to as the session management function network element below. .

The method includes: the session management function network element receives second information from the access network device, the second information is used to request to configure eDRX in an inactive state for the terminal; the session management function network element performs the following steps according to the first The second information is to establish a transmission channel between the unicast user plane functional network element and the multicast user plane functional network element. The transmission channel is used to transmit the multicast data of the terminal; the session management functional network element provides access to The network device sends ninth information, where the ninth information is used to indicate that eDRX in an inactive state is successfully configured for the terminal.

In this way, when a terminal joins a multicast session, the access network device can convert the terminal into an inactive state and configure eDRX for the terminal, thereby realizing eDRX management of the terminal.

In conjunction with the seventh aspect, in a possible implementation, the method further includes: the session management function network element sending eDRX cache information to the unicast user plane function network element or the multicast user plane function network element. , the eDRX cache information is used to cache the multicast data.

Based on the above method, when a terminal joins a multicast session, the access network device can convert the terminal into an inactive state and configure eDRX for the terminal, and the unicast user plane functional network element or the multicast user plane functional network element can The terminal's multicast data is cached to prevent the terminal from missing multicast data and help ensure the transmission of multicast services.

In addition, multicast data is cached by the multicast user plane functional network element, and the cache point is relatively high, which helps to reduce the amount of data cached by the network.

In an eighth aspect, a communication method is provided. The method can be executed by a multicast user plane functional network element, or can be executed by a module or unit in the multicast user plane functional network element. For convenience of description, it will be collectively referred to as multicast in the following. Broadcast user plane functional network elements.

The method includes: the multicast user plane functional network element receives eDRX cache information from the session management function network element, and the eDRX cache information is used to cache the multicast data of the terminal; the multicast user plane functional network element is configured according to the eDRX caches information and caches multicast data of the terminal.

Based on the above method, when a terminal joins a multicast session, the access network device can convert the terminal into an inactive state and configure eDRX for the terminal, and the multicast user plane functional network element caches the multicast data of the terminal. This prevents the terminal from missing multicast data and helps ensure the transmission of multicast services.

In addition, multicast data is cached by the multicast user plane functional network element, and the cache point is relatively high, which helps to reduce the amount of data cached by the network.

A ninth aspect provides a communication device, which is used to perform the method provided by any of the above aspects or its implementation. Specifically, the device may include units and/or modules, such as a processing unit and/or a communication unit, for executing the method provided by any of the above aspects or implementations thereof.

In an implementation manner, the device is a core network device, an access network device, an access and mobility management function network element, a terminal, a session management function or a multicast user plane function network element. When the device is core network equipment, access network equipment, access and mobility management function network element, terminal, session management function or multicast user plane function network element, the communication unit may be a transceiver, or input/output Interface, or communication interface; the processing unit may be at least one processor. Optionally, the transceiver is a transceiver circuit. Optionally, the input/output interface is an input/output circuit.

In another implementation, the device is a chip or chip system used in core network equipment, access network equipment, access and mobility management function network elements, terminals, session management function or multicast user plane function network elements or circuit. When the device is a chip, chip system or circuit used in core network equipment, access network equipment, access and mobility management function network elements, terminals, session management functions or multicast user plane function network elements, the communication unit It can be the input/output interface, interface circuit, output circuit, input circuit, pin or related circuit on the chip, chip system or circuit, etc.; the processing unit can be at least one processor, processing circuit or logic circuit, etc.

In a tenth aspect, a communication device is provided. The device includes: a memory for storing a program; and at least one processor for executing the computer program or instructions stored in the memory to execute the method provided by any of the above aspects or its implementation. .

In an implementation manner, the device is a core network device, an access network device, an access and mobility management function network element, a terminal, a session management function or a multicast user plane function network element.

In another implementation, the device is a chip or chip system used in core network equipment, access network equipment, access and mobility management function network elements, terminals, session management function or multicast user plane function network elements or circuit.

In an eleventh aspect, a communication device is provided. The device includes: at least one processor and a communication interface. The at least one processor is used to obtain computer programs or instructions stored in a memory through the communication interface to execute any one of the above aspects or The methods provided for its implementation. The communication interface can be implemented by hardware or software.

In one implementation, the device further includes the memory.

A twelfth aspect provides a processor for executing the methods provided in the above aspects.

For operations such as sending and getting/receiving involved in the processor, if there is no special explanation, or if it does not conflict with its actual role or internal logic in the relevant description, then it can be understood as processor output, reception, input and other operations. , can also be understood as the transmitting and receiving operations performed by the radio frequency circuit and the antenna, which is not limited in this application.

In a thirteenth aspect, a computer-readable storage medium is provided. The computer-readable medium stores program code for device execution. The program code includes a method for executing any of the above aspects or its implementation.

A fourteenth aspect provides a computer program product containing instructions. When the computer program product is run on a computer, it causes the computer to execute the method provided by any of the above aspects or its implementation.

A fifteenth aspect provides a chip. The chip includes a processor and a communication interface. The processor reads instructions stored in the memory through the communication interface and executes the method provided by any of the above aspects or its implementation. The communication interface can be implemented by hardware or software.

Optionally, as an implementation manner, the chip also includes a memory, in which computer programs or instructions are stored. The processor is used to execute the computer program or instructions stored in the memory. When the computer program or instructions are executed, the processor is used to execute the above. Methods provided by any aspect or its implementation.

A sixteenth aspect provides a communication system, including at least one of the above core network equipment, access network equipment, access and mobility management function network elements, terminals, session management functions or multicast user plane function network elements. a.

In order to facilitate understanding of the embodiments of the present application, the following explanations are made before introducing the embodiments of the present application.

"For indicating" or "instructing" may include direct indication and indirect indication, or "for indicating" or "instructing" may indicate explicitly and/or implicitly. For example, when describing certain information as indicating information I, it may include that the information directly indicates I or indirectly indicates I, but it does not mean that the information must contain I. As another example, an implicit indication may be based on the location and/or resources used for transmission; an explicit indication may be based on one or more parameters, and/or one or more indexes, and/or one or more bits it represents. model.

The first, second, third, fourth and various numerical numbers are only for convenience of description and are not used to limit the scope of the embodiments of the present application. For example, distinguish different fields, different information, etc.

Words such as "exemplary," "for example," "exemplarily," "as (another) example" are used to mean examples, illustrations or illustrations. Any embodiment or design described herein as "example" is not intended to be construed as preferred or advantageous over other embodiments or designs. Rather, the use of the word example is intended to present a concept in a concrete way.

“Including,” “includes,” “having,” and variations thereof all mean “including but not limited to,” unless otherwise specifically emphasized.

"At least one" means one or more, and "plurality" means two or more. "And/or" describes the relationship between associated objects, indicating that there can be three relationships, for example, A and/or B, which can mean: A exists alone, A and B exist simultaneously, and B exists alone, where A, B Can be singular or plural. The character "/" generally indicates that the related objects are in an "or" relationship. “At least one of the following” or similar expressions refers to any combination of these items, including any combination of single items (items) or plural items (items). For example, at least one of a, b, and c can mean: a, or, b, or, c, or, a and b, or, a and c, or, b and c, or, a , b and c. Among them, a, b and c can be single or multiple respectively.

Descriptions such as "when...", "in the case of...", "if" and "if" all refer to the device will perform corresponding processing under certain objective circumstances. They do not limit the time and do not require The device must have judgment actions when implementing it, and it does not mean that there are other restrictions.

In the embodiments of this application, related descriptions related to network element A sending messages, information or data to network element B, and network element B receiving messages, information or data from network element A are intended to illustrate the messages, information or data. It is to be sent to which network element, and it does not limit whether they are sent directly or indirectly through other network elements.

In the embodiments of the present application, various aspects, embodiments or features will be presented around a system including a plurality of devices, components, modules, etc. It should be understood that each system may include all devices, components, and modules involved in the schematic diagram of the network architecture, or may include only some of them without limitation.

The embodiments provided in this application can be applied to various communication systems. For example, the ^fifth generation (5G) or new radio (NR) system, long term evolution (LTE) system, LTE frequency division duplex (FDD) system, LTE time Time division duplex (TDD) system, etc. The embodiments provided in this application can also be applied to non-terrestrial network (NTN) communication systems such as satellite communication systems. The embodiments provided by this application can also be applied to device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, machine-to-machine (M2M) communication, machine type Communication (machine type communication, MTC), and Internet of things (Internet of things, IoT) communication systems or other communication systems. The embodiments provided in this application can also be applied to future communication systems, such as the sixth generation mobile communication system.

By way of example, Figure 1 shows a schematic diagram of a network architecture.

As shown in Figure 1, the network architecture takes the ^5th generation system (5GS) as an example. The network architecture can include three parts, namely user equipment (UE), data network (DN) and operator network. Among them, the operator's network may include one or more of the following network elements: (radio) access network (R)AN) equipment, user plane function (UPF) network element, Access and mobility management function (AMF) network element, session management function (SMF) network element, policy control function (PCF) network element, unified data management (unified data management (UDM) network element and application function (AF) network element. In the above operator network, the part other than (R)AN can be called the core network.

In this application, the (wireless) access network equipment, UPF network element, AMF network element, SMF network element, PCF network element, UDM network element, and AF network element are referred to as (R)AN, UPF, AMF, and SMF respectively. , PCF, UDM, AF.

Below is a brief description of each equipment involved in Figure 1.

1.UE

UE may also be called terminal, user, access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal equipment, wireless communication equipment, user agent or user device, etc. , for the convenience of description, they are collectively referred to as terminals below.

A terminal is a device that can access a wireless communication network. Air interface technology (such as NR or LTE) can be used to communicate between the terminal and the (R)AN. Air interface technology (such as NR or LTE) can also be used to communicate between terminals. Specifically, the terminal can be a mobile phone (mobile phone), a tablet computer (pad), a computer with wireless transceiver functions, a virtual reality (VR) terminal, an augmented reality (AR) terminal, or a terminal in satellite communications. , terminals in integrated access and backhaul (IAB) systems, terminals in WiFi communication systems, terminals in industrial control (industrial control), terminals in self-driving (self driving), remote Terminals in remote medical, terminals in smart grid, terminals in transportation safety, terminals in smart city, terminals in smart home, etc.

The embodiments of this application do not limit the specific technology and specific equipment form used by the terminal.

2.(R)AN

(R)AN can be a device used to communicate with a terminal, or it can be a device that connects the terminal to a wireless communication network.

(R)AN may be a node in a wireless access network. For example, base station, evolved base station (evolved NodeB, eNodeB), transmission reception point (TRP), home base station (e.g., home evolved NodeB, or home Node B, HNB), Wi-Fi access point Access point (AP), mobile switching center, next generation base station (next generation NodeB, gNB) in 5G mobile communication system, open radio access network (open radio access network, O-RAN or open RAN) Access network equipment, next-generation base stations in the ^6th generation (6G) mobile communication system, or base stations in future mobile communication systems, etc. (R)AN can also be a module or unit that completes some functions of the base station. For example, it can be a centralized unit (CU), a distributed unit (DU), or a remote radio unit (RRU). ) or baseband unit (BBU), etc.

(R)AN can also be equipment that assumes base station functions in D2D communication systems, V2X communication systems, M2M communication systems, and IoT communication systems. (R)AN can also be a network device in NTN, that is, (R)AN can be deployed on high-altitude platforms or satellites. (R)AN can be a macro base station, a micro base station or an indoor station, or a relay node or a donor node, etc.

The embodiments of this application do not limit the specific technology, equipment form, and name used by (R)AN. For convenience of description, (R)AN will be collectively referred to as access network equipment below.

3.UPF

UPF is mainly responsible for the forwarding and routing of user data in the terminal. For example, UPF can receive user plane data from the DN and send the user plane data to the terminal through the access network equipment. UPF can also receive user plane data from the terminal through the access network equipment and forward it to the DN. The transmission resources and scheduling functions in UPF network elements that provide services for terminals are managed and controlled by SMF.

4.DN

DN is mainly used in operator networks that provide data services to terminals. For example, the Internet, a third-party business network, or an IP multi-media service (IMS) network, etc. There can be multiple application servers (AS) in the DN.

5.AMF

AMF is mainly responsible for terminal access control and mobility management, such as user location update, user registration network, or user switching.

6. SMF

SMF is mainly responsible for user plane network element selection, user plane network element redirection, Internet protocol (IP) address allocation, session establishment, modification and release, and QoS control.

8.PCF

PCF is mainly responsible for policy control decisions, policy rules that provide control plane functions, and traffic-based charging control functions.

9.UDM

UDM is mainly responsible for terminal contract data management, including the storage and management of terminal identification, terminal access authorization, etc.

10. AF

AF mainly supports interaction with the 3GPP core network to provide services, such as affecting data routing decisions, policy control functions or providing third-party services to the network. The AF can be the AF deployed by the operator's network itself, or it can be a third-party AF.

Figure 2 is a schematic diagram of the network architecture of a multicast/broadcast service.

Among them, the network architecture and the functions of the network elements shown in Figure 2 are enhanced and defined based on the network architecture and the functions of the network elements shown in Figure 1. For the sake of simplicity, only the multicast/broadcast service-specific functions of each network element in Figure 2 are described below.

1.PCF

PCF is mainly responsible for: QoS processing of multicast/broadcast service (MBS) sessions, providing policy information to multicast/broadcast SMF (MB-SMF), and communicating with user data repository (user data repository, UDR) to interactively obtain QoS information, etc. PCF is an optional network element. For example, this functional entity can be provided only when dynamic policy charging control (PCC) is used.

2.MB-SMF

MB-SMF is an entity that supports multicast/broadcast features. MB-SMF is responsible for: management of MBS sessions, such as QoS control, etc.; configuring multicast/broadcast (multicast-broadcast UPF, MB-UPF); interacting with access network equipment to control broadcast flow (flow) transmission; and unicast SMF Interact to associate protocol data unit (PDU) sessions; interact with access network equipment to control the transmission of multicast streams, etc. MB-SMF can also have the function of unicast SMF at the same time.

3. SMF

SMF is mainly responsible for: discovering MB-SMF, authenticating terminals to join MBS, interacting with MB-SMF to manage multicast session context, interacting with access network equipment to establish multicast transmission resources, etc.

4.MB-UPF

MB-UPF is the gateway of the data plane of MBS. It is mainly responsible for: interacting with MB-SMF to obtain data forwarding rules, transmitting multicast data to the access network device through the shared delivery method (shared delivery method), and passing the separate delivery method to UPF. (individual delivery method) transmits multicast data, etc.

5.UPF

UPF is mainly responsible for: transmitting multicast data through individual delivery methods, for example, receiving multicast data from MB-UPF and transmitting multicast data to the terminal through PDU sessions.

6.AMF

AMF is mainly responsible for: signaling routing (for example, signaling routing between (R)AN and MB-SMF), and selecting (R)AN for MBS, etc.

7.(R)AN

(R)AN is mainly responsible for: processing MBS QoS flows, sending data to terminals through point to multipoint (PTM) and point to point (PTP), and configuring the access stratum (AS) Receive broadcast streams, switch between PTM and PTP, support Xn and N2 switching of multicast sessions, process session signaling, and establish air interface broadcast and multicast resources, etc.

8.UE

The main functions of the UE are: receiving multicast data through PTM/PTP, receiving multicast data/broadcast data through PTM, processing QoS, initiating session join (session join) and session leave (session leave), and resource management on the terminal side of MBS wait.

9. Multicast/broadcast service function (MBSF) network element

The MBSF network element, hereinafter referred to as MBSF, mainly supports the following functions: business layer functions, interworking with LTE MBS, interacting with AF and MB-SMF to support MBS session operations, determining transmission parameters and MBS session types, selecting MB- SMF controls MBSTF, determines the sender's IP multicast address, etc. MBSF is an optional network element.

10. Multicast/broadcast service transmission function (MBSTF) network element

The MBSTF network element, hereinafter referred to as MBSTF, mainly supports the following functions: an anchor point for MBS data; serving as a source of IP multicast; supporting general transmission functions such as frames, multi-streams, and forward error correction (FEC); Send the input file as an object or object flow in a multicast or broadcast manner, etc. MBSTF is an optional network element.

11. AF

AF mainly supports the following functions: providing business information to the core network (core network) and requesting multicast or broadcast services, as well as instructing session operations with MBS, etc.

12.UDM

UDM mainly supports subscription/subscription management of multicast sessions, etc.

13. Network repository function (NRF)

NRF mainly includes the following functions: supporting the management of MB-SMF serving MBS sessions, including saving the MBS session ID of MB-SMF services, etc.

14. Network exposure function (NEF)

NEF mainly includes the following functions: select MB-SMF; interact with AF and MB-SMF to implement MBS session operations, determine transmission parameters, etc.; provide AF with MBS process interfaces such as service configuration, MBS session configuration, QoS management interfaces, etc.

In the network architecture shown in Figures 1 and 2, each network element can communicate with each other through interfaces. The interface between each network element can be a point-to-point interface or a service-oriented interface, which is not limited by this application.

It should be understood that the network architecture shown above is only an illustrative description, and the network architecture applicable to the embodiments of the present application is not limited thereto. Any network architecture that can realize the functions of each of the above network elements is applicable to the embodiments of the present application.

It should also be understood that each function or network element shown in Figures 1 and 2 can be understood as network elements used to implement different functions, and for example, can be combined into a network slice as needed. These network elements can be independent devices, or they can be integrated into the same device to implement different functions, or they can be network elements in hardware devices, software functions running on dedicated hardware, or platforms (for example, cloud The virtualization function instantiated on the platform), this application does not limit the specific form of the above network elements.

It should also be understood that the above nomenclature is only defined to facilitate the differentiation of different functions and should not constitute any limitation on this application. This application does not rule out the possibility of using other naming in 6G networks and other networks in the future. For example, in a 6G network, some or all of the above network elements may use the terminology used in 5G, or may adopt other names.

In order to facilitate understanding of the embodiments of this application, the terms involved in this application will first be briefly explained.

1. Multicast session

A session used to transmit multicast services can be called a multicast session. The characteristic of a multicast session is that a group of terminals receive the same data. A multicast session may also be called a multicast MBS session or a multicast session, and is collectively referred to as a multicast session in this application.

A terminal can receive multicast service data by joining a multicast session. The data of the multicast service can be referred to as multicast data.

In this application, "join multicast session" can also be replaced by "join multicast group" without restriction.

2. DRX and eDRX

In order to reduce terminal power consumption, DRX technology is introduced into the communication system. DRX technology can make the terminal enter sleep state periodically to achieve the purpose of reducing terminal power consumption. A DRX cycle includes a sleep period and an activation period. During the activation period, the terminal monitors and receives the downlink channel; during the sleep period, the terminal does not need to turn on the receiver to receive data on the downlink channel, thereby reducing terminal power consumption. The DRX cycle can be divided into short DRX cycle and long DRX cycle.

Furthermore, for terminals with limited capabilities, DRX can be extended to eDRX. eDRX can change the terminal's DRX cycle from a maximum of 10.24 seconds (s) to more than 10,000 seconds, allowing the terminal to spend less time turning on the receiver, thereby further reducing terminal power consumption. eDRX can include long eDRX (long eDRX), and the cycle length of long eDRX can be greater than 10.24 seconds. eDRX in this application can also be replaced by eDRX cycle, long eDRX, long eDRX cycle, or eDRX with a cycle length greater than 10.24 seconds.

The terminology involved in this application has been briefly explained above, and will not be described again in the following embodiments.

The communication method provided by the embodiment of the present application is described in detail below.

Figure 3 is a schematic flow chart of the communication method 300 provided by this application.

Method 300 may be executed by access network equipment and core network equipment, or may be executed by modules or units in access network equipment and core network equipment. This application will not limit the method. For convenience of description, it will be collectively referred to as access network equipment below. and core network equipment. Method 300 includes at least part of the following.

Step 301: The core network device learns that the terminal has joined the multicast session.

Optionally, the core network device is SMF or AMF.

When the core network device is SMF, SMF can learn that the terminal has joined the multicast session during the process of the terminal joining the multicast session.

Specifically, the SMF may determine based on the identification of the multicast session carried in the Non-Access Stratum (NAS) message sent by the terminal and/or the join request (join request) information.

Or, after receiving the above non-access layer message, the SMF further obtains the terminal's subscription information (for example, whether the terminal is authorized to join certain multicast sessions) from the local or UDM, and/or obtains the terminal's subscription information from the local or MB-SMF. Obtain the context information of the multicast session. The context information includes whether the multicast session is open to all terminals. For example, if the subscription information of the terminal includes information that the terminal is authorized to join a multicast session (for example, the subscription information includes identification information of the multicast session, where the identification of the multicast session may be, for example, a temporary multicast group identification). group identifier, TMGI)), then SMF learns that the terminal has joined the multicast session. If the terminal's subscription information does not include information that the terminal is authorized to join the multicast session, but the context information of the multicast session always includes that the multicast session is open to all terminals, then SMF learns that the terminal has joined the multicast session.

When the core network device is an AMF, step 301 includes: the AMF receives the fourth information from the SMF, and accordingly, the SMF sends the fourth information to the AMF, where the fourth information is used to indicate that the terminal has joined the multicast session; Four messages learn that the terminal has joined the multicast session. Among them, for SMF, SMF can learn that the terminal has joined the multicast session during the process of the terminal joining the multicast session.

Optionally, the fourth information includes an identification of the multicast session to which the terminal has joined. The identifier of the multicast session may be, for example, a temporary multicast group identifier (TMGI). It can be understood that the fourth information indicates in an implicit manner that the terminal has joined the multicast session corresponding to the identifier of the multicast session.

Optionally, the fourth information includes the identification of the multicast session that the terminal has joined and the first indication information. The identifier of the multicast session may be, for example, TMGI, and the first indication information is used to indicate that the terminal has joined the multicast session. It can be understood that the fourth information indicates through display that the terminal has joined the multicast session and the identifier of the multicast session.

Optionally, step 301 specifically includes: SMF sending fourth information to AMF when the multicast session is active, and accordingly, AMF receives the fourth information from SMF.

Step 302: The core network device sends the first information.

The first information is used to notify the refusal to configure eDRX in the inactive state for the terminal, or the first information is used to indicate that the terminal is not suitable for eDRX in the inactive state.

Among them, "the terminal is not suitable for eDRX in the inactive state" can also be described as follows: "the terminal is not allowed to be configured with eDRX in the inactive state", "the terminal is not configured with eDRX in the inactive state", "the terminal is not allowed to be configured with eDRX in the inactive state", "The terminal is converted to the inactive state of eDRX", "The terminal is not applicable to eDRX", "The terminal is not converted to the eDRX in the inactive state", "The terminal does not enter the eDRX in the inactive state" or "The terminal is not sent to the inactive state". eDRX in active state" etc.

Among them, "refuse to configure eDRX in the inactive state for the terminal" can also use the following description: "refuse to convert the terminal into the inactive state of eDRX", "refuse to convert the terminal into eDRX in the inactive state", "reject the terminal Enter eDRX in the inactive state" or "Refuse to send the terminal to eDRX in the inactive state", etc.

Optionally, when the first information is used to notify a refusal to configure eDRX in an inactive state for the terminal, the first information includes rejection information, and the refusal information is used to indicate a refusal to configure eDRX in an inactive state for the terminal. The rejection information may include a reason for refusing to configure eDRX in an inactive state for the terminal. The reason varies with the information considered by the core network device when sending the first information, and will be described below.

Optionally, when the core network device is an AMF, the first information may be RRC inactive assistance information (RIAI), and the first information does not include the UE specific extended idle DRX value. idle mode DRX values).

Optionally, when the core network device is SMF, the first information may be included in the PDU Session Resource Setup Request Transfer message, or included in the PDU Session Resource Modify Request Transfer message. )information.

Optionally, when the first information is used to notify the refusal to configure eDRX in the inactive state for the terminal, step 302 includes: the core network device sends the first information to the access network device. And before step 302, the method 300 also includes step 303, and step 303 is as follows.

Step 303: When the access network device determines to convert the terminal to the inactive state, the access network device sends the second information to the core network device.

Correspondingly, the core network device receives the second information from the access network device.

The second information is used to request to configure eDRX in an inactive state for the terminal. For example, the second information is used to request the terminal to be converted to an inactive state and the second information carries eDRX information, where the eDRX information includes a period for the terminal to enter eDRX, and so on. "Request" can also be replaced by "instruction" or "configuration", etc.

Step 303 can also be described as: the access network device determines to convert the terminal to an inactive state, and the access network device sends the second information to the core network device. The access network device determines to convert the terminal to the inactive state before the access network device sends the second information, or after the access network device sends the second information, without limitation.

Optionally, in step 303, the access network device may use RRC inactive assistance information (RIAI) and other possible information (such as the implementation of the access network device, or the current status of the access network device). load, etc.), decide to convert the terminal to an inactive state. For a more detailed description, reference may be made to the prior art and will not be described again here.

It should be noted that if the core network device is an SMF, the interaction between the access network device and the SMF passes through the AMF. For example, the SMF sends the first information to the access network device through the AMF. For another example, the access network device may send the second information to the SMF through the AMF. In this case, although the information received by the AMF and the information sent by the AMF are both called first information or second information, the information received by the AMF and the information sent by the AMF may be implemented in the same way or in different ways (for example, via different messages and/or cells), without limitation. For example, the SMF can send the first information to the AMF through the N11 message; after receiving the N11 message from the SMF, the AMF sends the N2 message to the access network device according to the first information, that is, through the N2 message or the cells in the N2 message. The access network equipment transmits the first information. For another example, the access network device can send the second information to the AMF through the N2 message; after receiving the N2 message from the access network device, the AMF sends a PDU session update session management context request message to the SMF based on the second information ( Such as Nsmf_PDUsession_UpdateSMContext request), that is, the second information is transmitted to the SMF through the PDU session update session management context request message or the information element therein.

It should also be noted that when the core network device is an SMF, after receiving the second information from the access network device, the AMF may send the second information to one or more SMFs. For the case where the AMF sends the second information to multiple SMFs, for example, the AMF may send the second information to the first SMF for managing the unicast session associated with the multicast session of the terminal and the first SMF for managing the multicast session that is not associated with the terminal. The second SMF of the unicast session sends the second information. In this case, the core network device may be the first SMF, and after the AMF receives the first information from the first SMF, the AMF sends the fifth information to the second SMF. , correspondingly, the second SMF receives the fifth information from the AMF, where the fifth information is used to trigger the second SMF to stop configuring eDRX in the inactive state for the terminal; the second SMF stops configuring eDRX in the inactive state for the terminal.

Wherein, the second SMF stopping to configure eDRX in the inactive state for the terminal may include: the second SMF disables cached data.

In one possible implementation manner, the second SMF sends a multicast-specific configuration message to the UPF, and the multicast-specific configuration message does not contain an eDRX cache indication, or contains instruction information to clear the eDRX cache. The UPF here can be the UPF managed by the second SMF.

In another possible implementation, the second SMF sends a configuration message for multicast to the UPF, and the configuration message for multicast sets the Buffer Action Rule (BAR) to 0, or contains instructions for clearing the BAR. .

In another possible implementation, the second SMF sends a configuration message for multicast to the UPF. In the configuration message for multicast, the multicast creation (or update) forwarding action rule (Create/Update Forwarding Action Rule, Create /Update FAR) is set to a special value (such as 0) to indicate that caching is not required, or the Create/Update FAR for multicast does not include the corresponding BAR identifier.

In another possible implementation, the second SMF sends a configuration message for multicast to the UPF, and the configuration message for multicast includes a Delete/Release Forwarding Action Rule for multicast (Delete/Release Forwarding Action Rule, Delete/Release FAR), and the BAR identifier included in Delete/Release FAR is set to a special value to indicate that caching is not required, or the configuration message for multicast includes a deletion (or release) forwarding action for multicast. Rule (Delete/Release Forwarding Action Rule, Delete/Release FAR), and Delete/Release FAR includes the corresponding BAR identifier.

Among them, "stop configuring eDRX in the inactive state for the terminal" can also use the following description: "restore the original state of the terminal", "cancel the configuration of eDRX in the inactive state for the terminal" or "withdraw the configuration of the inactive state for the terminal" eDRX under "etc.

Optionally, when the first information is used to indicate that the terminal is not applicable to eDRX in the inactive state, step 302 includes: the core network device sends the first information to the access network device or the terminal. Optionally, the first information can be carried in the RIAI.

It should be noted that when the core network device is an SMF, the SMF sends the first information to the access network device through the AMF. In this case, although the information received by the AMF and the information sent by the AMF are both called first information, the information received by the AMF and the information sent by the AMF may be implemented in the same way or in different ways (for example, through different messages). and/or cells), without limitation.

In one possible implementation, step 302 includes: if the terminal has joined the multicast session, the core network device sends the first information. It can be understood that after the core network device learns that the terminal has joined the multicast session, the core network device can send the first message to notify the refusal to configure eDRX in the inactive state for the terminal or to instruct the terminal not to use eDRX in the inactive state. . In this implementation, if the first information includes a rejection reason, the reason is that the terminal has joined the multicast session.

In another possible implementation, step 302 includes: when at least one of the following conditions is met, the core network device sends the first information: the access network device that provides services to the terminal does not support eDRX, the terminal does not support eDRX, or more The multicast session meets the preset conditions, where the preset conditions are: the multicast session is active, the multicast service corresponding to the multicast session does not support eDRX, or the multicast session is active and the multicast service corresponding to the multicast session does not support eDRX. Support eDRX. It can be understood that after the core network device learns that the terminal has joined the multicast session, the core network device further determines whether the above conditions are met. When the above conditions are met, the core network device sends the first message to notify that the terminal is refused to be configured with non-configuration information. eDRX in the active state or indicating that the terminal is not applicable to eDRX in the inactive state. In this implementation, if the first information includes a rejection reason, the reason includes at least one of the following reasons: the terminal has joined the multicast session, the access network equipment that provides services to the terminal does not support eDRX, the terminal does not support eDRX, or Multicast sessions meet preset conditions.

For example, assuming that the preset condition is that the multicast session is active, if the terminal has joined the multicast session and the multicast session is active, and/or the access network equipment does not support eDRX, and/or the terminal does not support eDRX, the core network device sends the first information; if the terminal has joined the multicast session and the multicast session is in the deactivated state, the access network device supports eDRX, and the terminal supports eDRX, the core network device does not send the first information .

For another example, assume that the preset condition is that the multicast service corresponding to the multicast session does not support eDRX. If the terminal has joined the multicast session and the multicast service corresponding to the multicast session does not support eDRX, and/or the access network equipment eDRX is not supported, and/or the terminal does not support eDRX, the core network device sends the first information; if the terminal has joined the multicast session and the multicast service corresponding to the multicast session supports eDRX, and the access network equipment supports eDRX, If the terminal supports eDRX, the core network device does not send the first information.

For another example, assume that the preset condition is that the multicast session is active and the multicast service corresponding to the multicast session does not support eDRX. If the terminal has joined the multicast session and the multicast session meets the preset conditions, and/or access If the network equipment does not support eDRX, and/or the terminal does not support eDRX, the core network equipment sends the first information; if the terminal has joined the multicast session and the multicast session does not meet the preset conditions, the access network equipment supports eDRX , and when the terminal supports eDRX, the core network device does not send the first information.

Optionally, the method 300 also includes step 304: the core network device receives third information from the access network device, and accordingly, the access network device sends the third information to the core network device, where the third information is used to indicate the access network device. Whether the network access device supports eDRX. For example, when the access network device is powered on, the third information may be reported to the core network device.

Optionally, the third information may be carried in a next generation (interface) configuration request (NG set request) message.

It should be pointed out that when the core network device is an SMF, the access network device can send the third information to the SMF through the AMF. In this case, the third information received by the AMF and the third information sent by the AMF to the SMF may be implemented in the same way or in different ways (for example, through different messages and/or information elements), without limitation.

Optionally, when the core network device is an AMF, method 300 also includes: the AMF receives service information from the SMF, and accordingly, the SMF sends the service information to the AMF, where the service information is used to indicate the multicast service corresponding to the multicast session. Whether to support eDRX.

As an example, the service information may include the type of multicast service. When the multicast service type is a delay-sensitive type, it can be considered that the multicast service supports eDRX. When the multicast service type is a non-delay-sensitive type, it can be considered that the multicast service does not support eDRX.

As another example, the service information may include second indication information, and the second indication information is used to indicate whether the multicast service supports eDRX. The second indication information may be one or several bits, that is, the service information may indicate whether the multicast service supports eDRX in a display manner.

Step 305: The access network device does not configure eDRX in the inactive state for the terminal according to the first information.

Among them, "not configuring eDRX in the inactive state for the terminal" can also be understood as not performing the operation of configuring eDRX for the terminal, which can also be described as follows: "not converting the terminal to the inactive state using eDRX" or "not Transition terminal to eDRX state".

Optionally, method 300 also includes: the access network device converts the terminal to an inactive state, keeps the terminal in a connected state, converts the terminal to an idle state, converts the terminal to an inactive state and configures DRX for the terminal, and configures the terminal with DRX. Convert to the inactive state and configure only DRX for the terminal without eDRX information, convert the terminal to the inactive state and only include RAN-Paging Cycle (ran-PagingCycle) information in the terminal configuration information, or convert the terminal to In the inactive state, the terminal configuration information only contains RAN-Paging Cycle (ran-PagingCycle) information and does not contain RAN-Extended Paging Cycle (ran-ExtendedPagingCycle). Further optionally, the DRX period is no longer than 2.56s.

Among them, "conversion" can also be described as "release", "switching", "configuration", or "setting", etc.

Optionally, when the first information is used to indicate that the terminal is not suitable for eDRX in the inactive state, step 305 includes: when the access network device determines to convert the terminal to the inactive state, the access network device does not Configure eDRX in the inactive state for the terminal.

In this way, through method 300, when the terminal has joined the multicast session, the core network device can notify the access network device to refuse to configure eDRX in the inactive state for the terminal or indicate to the access network device that the terminal is not suitable for the inactive state. eDRX in the inactive state allows the access network equipment to not configure eDRX in the inactive state for the terminal according to the notification or instruction of the core network equipment when converting the terminal to the inactive state, thereby ensuring the multicast data corresponding to the multicast session. transmission.

Figure 4 is a schematic flow chart of the communication method 400 provided by this application.

Method 400 may be executed by access network equipment and core network equipment, or may be executed by modules or units in access network equipment and core network equipment. This application will not limit the method. For convenience of description, it will be collectively referred to as access network equipment below. and core network equipment. Method 400 includes at least some of the following.

Step 401: The access network device learns that the terminal has joined the multicast session.

In one possible implementation manner, the access network device can learn that the terminal has joined the multicast session during the process of the terminal joining the multicast session.

Specifically, the access network device can learn that the terminal has joined the multicast session based on receiving the N2 information sent by the SMF from the address allocated to the terminal, and the information contains the identifier of the multicast session.

Alternatively, the access network device receives a PDU Session Resource Setup Request (PDU SESSION RESOURCE SETUP REQUEST) sent from the AMF. The request message contains a PDU Session Resource Setup Request Transfer. The request transfer message contains MBS Session Setup Request List, and the list contains multicast session ID information (for example, MBS Session ID, which can be TMGI).

Alternatively, the access network device receives the PDU SESSION RESOURCE MODIFY REQUEST sent from the AMF, and the request message contains the PDU Session Resource Modify Request Transfer. The request transfer message contains the MBS. Session establishment request or modification list (MBS Session Setup or Modify Request List), and the list contains multicast session ID information (such as MBS Session ID, which can be TMGI).

Step 402: When the access network device determines to convert the terminal to the inactive state, the access network device does not configure eDRX in the inactive state for the terminal.

Among them, "not configuring eDRX in the inactive state for the terminal" can also be understood as not performing the operation of configuring eDRX for the terminal, which can also be described as follows: "not converting the terminal to an inactive state using eDRX" or "not Transition terminal to eDRX state".

Optionally, method 400 also includes: the access network device converts the terminal to an inactive state, keeps the terminal in a connected state, converts the terminal to an idle state, converts the terminal to an inactive state and configures DRX for the terminal, and configures the terminal with DRX. Convert to the inactive state and configure only DRX for the terminal without eDRX information, convert the terminal to the inactive state and only include RAN-Paging Cycle (ran-PagingCycle) information in the terminal configuration information, or convert the terminal to In the inactive state, the terminal configuration information only contains RAN-Paging Cycle (ran-PagingCycle) information and does not contain RAN-Extended Paging Cycle (ran-ExtendedPagingCycle). Further optionally, the DRX period is no longer than 2.56s.

Among them, "conversion" can also be described as "release", "switching", "configuration", or "setting", etc.

In one possible implementation manner, step 402 includes: if the terminal has joined the multicast session, the access network device does not configure eDRX in the inactive state for the terminal. It can be understood that when the conditions for converting the terminal to the inactive state are met, the access network device further considers whether the terminal has joined the multicast session, and does not configure eDRX for the terminal if the terminal has joined the multicast session. Or it can also be understood that the access network device determines that the conditions for converting the terminal to an inactive state and configuring eDRX for the terminal are not met based on the fact that the terminal has joined the multicast session.

In another possible implementation, step 402 includes: when at least one of the following conditions is met, the access network device does not configure eDRX in the inactive state for the terminal: the access network device does not support eDRX, the terminal does not support eDRX, Or the multicast session meets the preset conditions, where the preset conditions are: the multicast session is active, the multicast service corresponding to the multicast session does not support eDRX, or the multicast session is active and the multicast service corresponding to the multicast session The service does not support eDRX. It can be understood that when the access network device learns that the terminal has joined the multicast session, when it decides that the access network will convert the terminal to an inactive state, it determines whether the above conditions are met. When the above conditions are met, the access network device Network access equipment does not configure eDRX in the inactive state for terminals.

For example, assuming that the preset condition is that the multicast session is active, if the terminal has joined the multicast session and the multicast session is active, and/or the access network equipment does not support eDRX, and/or the terminal does not support eDRX, the access network equipment does not configure eDRX in the inactive state for the terminal; if the terminal has joined the multicast session and the multicast session is in the deactivated state, the access network equipment supports eDRX, and the terminal supports eDRX, then the The network access device can configure eDRX in the inactive state for the terminal.

For another example, assume that the preset condition is that the multicast service corresponding to the multicast session does not support eDRX. If the terminal has joined the multicast session and the multicast service corresponding to the multicast session does not support eDRX, and/or the access network equipment eDRX is not supported, and/or the terminal does not support eDRX, the access network equipment does not configure eDRX in the inactive state for the terminal; if the terminal has joined a multicast session and the multicast service corresponding to the multicast session supports eDRX, the access network device does not support eDRX. If the access network equipment supports eDRX and the terminal supports eDRX, the access network equipment can configure eDRX in the inactive state for the terminal.

For another example, assume that the preset condition is that the multicast session is active and the multicast service corresponding to the multicast session does not support eDRX. If the terminal has joined the multicast session and the multicast session meets the preset conditions, and/or access If the network equipment does not support eDRX, and/or the terminal does not support eDRX, the access network equipment does not configure eDRX in the inactive state for the terminal; if the terminal has joined the multicast session and the multicast session does not meet the preset conditions, When the access network equipment supports eDRX and the terminal supports eDRX, the access network equipment can configure eDRX in the inactive state for the terminal.

Optionally, method 400 also includes step 403: the access network device receives service information from the SMF, and accordingly, the SMF sends the service information to the access network device, where the service information is used to indicate the multicast service corresponding to the multicast session. Whether to support eDRX.

As an example, the service information may include the type of multicast service. When the multicast service type is a delay-sensitive type, it can be considered that the multicast service supports eDRX. When the multicast service type is a non-delay-sensitive type, it can be considered that the multicast service does not support eDRX.

As another example, the service information may include second indication information, and the second indication information is used to indicate whether the multicast service supports eDRX. The second indication information may be one or several bits, that is, the service information may indicate whether the multicast service supports eDRX in a display manner.

In this way, through method 400, when the terminal has joined the multicast session, the access network device can determine not to configure eDRX in the inactive state for the terminal, thereby ensuring the transmission of multicast data corresponding to the multicast session.

Figure 5 is a schematic flow chart of the communication method 500 provided by this application.

Method 500 may be executed by the terminal and the access network equipment, or may be executed by modules or units in the terminal and the access network equipment, which is not limited in this application. For the convenience of description, they are collectively referred to as the terminal and the access network equipment below. Method 500 includes at least some of the following.

Step 501: The terminal learns that the terminal has joined the multicast session.

Among them, the terminal supports eDRX.

One possible implementation method is that the terminal can learn that the terminal has joined the multicast session during the process of the terminal joining the multicast session.

Specifically, the terminal can learn that the terminal has joined the multicast session according to the NAS message sent from the AMF, and the NAS message contains the identifier of the multicast session.

Or, the terminal receives the PDU SESSION ESTABLISHMENT ACCEPT message sent from the AMF, and the message contains the MBS Session ID (such as TMGI). In a possible implementation, the MBS Session ID is included in the received MBS information (Received MBS information), the received MBS information is included in the received MBS container (Received MBS container), and the received MBS container is included in the PDU session establishment acceptance. in the message. At this time, the terminal can learn that the terminal has joined the multicast session.

Alternatively, the access network device receives a PDU SESSION MODIFICATION COMMAND message sent from the AMF, and the message contains the MBS Session ID (for example, TMGI). In a possible implementation, the MBS Session ID is included in the received MBS information (Received MBS information), the received MBS information is included in the received MBS container (Received MBS container), and the received MBS container is included in the PDU session modification command. in the message. At this time, the terminal can learn that the terminal has joined the multicast session.

Step 502: The terminal sends sixth information to the access network device.

Correspondingly, the access network device receives the sixth information from the terminal.

The sixth information is used to indicate that the terminal does not support eDRX.

In this way, when the terminal joins the multicast session, the access network device can not configure eDRX in the inactive state for the terminal according to the sixth information when making a judgment to convert the terminal to the inactive state, thereby ensuring that the multicast Transmission of multicast data corresponding to the session.

In a possible implementation manner, step 502 includes: the terminal sends sixth information to the access network device through the AMF. For example, the terminal sends a registration request message carrying sixth information to the AMF, and the sixth information may be the eDRX capability information of the terminal; after receiving the registration request message of the terminal, the AMF sends the sixth information to the access network device through the terminal context update message. information. Optionally, the sixth information may be carried in the RIAI.

It should be noted that when the terminal sends the sixth information to the access network device through the AMF, the implementation of the sixth information received by the AMF and the sixth information sent by the AMF may be the same or different (for example, through different messages and /or cells), are not restricted.

In one possible implementation, step 502 includes: if the terminal has joined the multicast session, the terminal sends sixth information. It can be understood that after the terminal learns that the terminal has joined the multicast session, the terminal can send the sixth information to the access network device to indicate to the access network device that the terminal does not support eDRX.

In another possible implementation, step 502 includes: the terminal sends sixth information to the access network device when at least one of the following conditions is met: the terminal receives the first information from the core network device, the access network device does not support eDRX, the terminal does not support eDRX, or the multicast session meets preset conditions. The first information is used to indicate that the terminal is not applicable to eDRX. The preset conditions are: the multicast session is active, and the multicast service corresponding to the multicast session is not available. eDRX is supported, or the multicast session is active and the multicast service corresponding to the multicast session does not support eDRX. It can be understood that after the terminal learns that the terminal has joined the multicast session, the terminal further determines whether the above conditions are met. When the above conditions are met, the terminal sends sixth information to the access network device to indicate to the access network device that the terminal does not Support eDRX.

For example, assuming that the preset condition is that the multicast session is active, if the terminal has joined the multicast session and the multicast session is active, and/or receives the first information from the core network device, and/or receives If the access network equipment does not support eDRX, and/or the terminal does not support eDRX, the terminal sends the sixth information to the access network equipment; if the terminal has joined the multicast session and the multicast session is in the deactivated state and has not received any If the first information of the core network equipment, the access network equipment supports eDRX, and the terminal supports eDRX, then the terminal may not send the sixth information to the access network equipment.

For another example, assume that the preset condition is that the multicast service corresponding to the multicast session does not support eDRX. If the terminal has joined the multicast session and the multicast service corresponding to the multicast session does not support eDRX, and/or, a message from the core network is received. The first information of the device, and/or, the access network equipment does not support eDRX, and/or the terminal does not support eDRX, then the terminal sends the sixth information to the access network equipment; if the terminal has joined the multicast session and the multicast session If the multicast service corresponding to the broadcast session supports eDRX, the first information from the core network device is not received, the access network device supports eDRX, and the terminal supports eDRX, then the terminal may not send the sixth information to the access network device.

For another example, assume that the preset condition is that the multicast session is active and the multicast service corresponding to the multicast session does not support eDRX. If the terminal has joined the multicast session and the multicast session meets the preset conditions, and/or receives The first information comes from the core network equipment, and/or the access network equipment does not support eDRX, and/or the terminal does not support eDRX, then the terminal sends the sixth information to the access network equipment; if the terminal has joined the multicast session If the multicast session does not meet the preset conditions, the first information from the core network device is not received, the access network device supports eDRX, and the terminal supports eDRX, the terminal may not send the sixth information to the access network device. .

It should be noted that the related description of the first information may refer to the method 300 and will not be described again here.

Optionally, method 500 also includes step 503: the terminal receives service information from the SMF, and accordingly, the SMF sends the service information to the terminal, where the service information is used to indicate whether the multicast service corresponding to the multicast session supports eDRX. Service information can be included in messages such as PDU session modification command, PDU session modification acceptance, and PDU session establishment response.

As an example, the service information may include the type of multicast service. When the multicast service type is a delay-sensitive type, it can be considered that the multicast service supports eDRX. When the multicast service type is a non-delay-sensitive type, it can be considered that the multicast service does not support eDRX.

As another example, the service information may include second indication information, and the second indication information is used to indicate whether the multicast service supports eDRX. The second indication information may be one or several bits, that is, the service information may indicate whether the multicast service supports eDRX in a display manner.

Optionally, in another scenario of the above embodiment, before step 501, method 500 further includes: the terminal sends seventh information to the access network device, and accordingly, the base station receives the seventh information from the terminal, wherein the seventh information Information used to indicate that the terminal supports eDRX. The method for the terminal to send the seventh information to the access network device may refer to the method for the terminal to send the sixth information to the access network device, which will not be described again here.

Optionally, in another scenario of the above embodiment, after step 502, method 500 also includes: after the terminal leaves all multicast sessions that the terminal has joined, the terminal sends eighth information to the access network device, correspondingly , the base station receives the eighth information from the terminal, where the eighth information is used to indicate that the terminal supports eDRX. The method for the terminal to send the eighth information to the access network device may refer to the method for the terminal to send the sixth information to the access network device, which will not be described again here.

In other scenarios of this application, step 502 can also be replaced by: the terminal sends a registration request message to the AMF, and the registration request message does not contain the requested extended DRX parameters (Requested extended DRX parameters); after receiving the registration request message from the terminal Finally, the AMF updates the terminal context of the access network device according to the registration request message that does not contain the requested extended DRX parameters. Specifically, the AMF sends RIAI information to the access network device through a terminal context update message, and the RIAI does not contain a UE specific extended idle mode DRX value (UE specific extended idle mode DRX).

Figure 6 is a schematic flow chart of the communication method 600 provided by this application.

Method 600 can be executed by the access network equipment, SMF, UPF and MB-UPF, or can be executed by the modules or units in the access network equipment, SMF, UPF and MB-UPF. This application does not limit it. For the convenience of description, Hereinafter, they are collectively referred to as access network equipment, SMF, UPF and MB-UPF. Method 600 includes at least some of the following.

Step 601: The access network device sends second information to the SMF.

Correspondingly, the SMF receives the second information from the access network device.

The second information is used to request to configure eDRX in an inactive state for the terminal. For example, the second information is used to request to convert the terminal to an inactive state and the second information carries eDRX information, where the eDRX information includes a period for the terminal to enter eDRX, and so on.

"Request" can also be replaced by "instruction" or "configuration", etc.

It should be noted that the interaction between the access network device and the SMF can be through the AMF. In this case, although the information received by the AMF and the information sent by the AMF are both called second information, the information received by the AMF and The information sent by AMF can be implemented in the same way or in different ways (for example, through different messages and/or cells) without limitation. For example, the access network device can send the second information to the AMF through the N2 message; after receiving the N2 message from the access network device, the AMF sends a PDU session update session management context request message (such as Nsmf_PDUsession_UpdateSMContext request), that is, the second information is transmitted to the SMF through the PDU session update session management context request message or the information element therein.

Step 602: After receiving the second information, the SMF establishes a transmission channel between UPF and MB-UPF based on the second information.

Among them, the transmission channel between UPF and MB-UPF is used to transmit multicast data of the terminal. The multicast data here can be multicast data when the terminal is in the eDRX sleep state.

Step 602 can be understood as triggering SMF to establish a transmission channel between UPF and MB-UPF when configuring inactive eDRX for the terminal.

Optionally, the SMF may previously learn that the access network device providing services for the terminal supports multicast. That is, when the access network device supports multicast, the SMF can establish a transmission channel between the UPF and MB-UPF after receiving the second information.

It should be pointed out that SMF establishes a transmission channel between UPF and MB-UPF based on the second information. It may be that SMF creates a new transmission channel between UPF and MB-UPF based on the second information, or it may be that SMF modifies it based on the second information. The existing transmission channel between UPF and MB-UPF enables the channel to transmit multicast data of terminals.

Optionally, there are many ways for SMF to establish a transmission channel between UPF and MB-UPF, which are not limited.

One possible implementation is that SMF sends an N4 message to UPF, and accordingly, UPF receives an N4 message from SMF. The N4 message is used to inquire whether a transmission channel from UPF to MB-UPF has been established; UPF sends an N4 message to SMF. response message, correspondingly, SMF receives the response message from UPF, where the response message includes the first downlink tunnel identifier; SMF sends a request message to MB-SMF, correspondingly, MB-SMF receives the request message from SMF, where the request The message includes the first downlink tunnel identifier; MB-SMF and MB-UPF interact to establish a transmission channel between UPF and MB-UPF; MB-SMF sends a response message to the SMF request message, and accordingly, SMF receives a response message from MB-SMF response message. Among them, if a transmission channel already exists between UPF and MB-UPF, the first downlink tunnel identifier is the tunnel identifier of the transmission channel; if a transmission channel has not yet been established between UPF and MB-UPF, the first downlink tunnel identifier Tunnel ID assigned to UPF. For a more detailed description, reference may be made to the prior art and will not be described again.

Another possible implementation is that SMF sends an N4 message to UPF. Correspondingly, UPF receives an N4 message from SMF. The N4 message is used to inquire whether a transmission channel from UPF to MB-UPF has been established; UPF sends an N4 message to SMF. response message, correspondingly, SMF receives the response message from UPF, wherein the response message includes SSM information; SMF sends a request message to MB-SMF, correspondingly, MB-SMF receives the request message from SMF, wherein the request message includes SSM information; MB-SMF and MB-UPF interact to establish a transmission channel between UPF and MB-UPF. In the process, MB-UPF provides MB-SMF with the second downlink tunnel identifier for multicast; MB-SMF provides SMF with A response message of the request message is sent. Correspondingly, the SMF receives a response message from the MB-SMF, where the response message includes the second downlink tunnel identifier; the SMF provides the second downlink tunnel identifier to the UPF. For a more detailed description, reference may be made to the prior art and will not be described again.

Step 603: SMF sends eDRX cache information to UPF or MB-UPF.

Accordingly, UPF or MB-SMF receives the eDRX cache information from SMF.

Among them, the eDRX cache information is used to cache multicast data of the terminal.

Optionally, the eDRX cache information includes third indication information and a period for the terminal to enter eDRX, where the third indication information is used to instruct to stop the transmission of the terminal's multicast data and cache the terminal's multicast data.

Optionally, the eDRX cache information includes configuration information and a period for the terminal to enter eDRX, where the configuration information is used to configure UPF or MB-UPF so that UPF or MB-UPF caches the multicast data of the terminal.

When SMF sends eDRX cache information to UPF, it can be considered that UPF caches the multicast data of the terminal. That is, MB-UPF can transmit the multicast data of the terminal to UPF through the transmission channel between UPF and MB-UPF, and the UPF can cache it. Later, when the terminal becomes reachable again, UPF can send the cached data to the terminal.

When SMF sends eDRX cache information to MB-UPF, it can be considered that MB-UPF caches the multicast data of the terminal. That is, MB-UPF can cache the multicast data of the terminal. When the terminal becomes reachable again, MB-UPF can transmit the cached multicast data to UPF through the transmission channel between UPF and MB-UPF. After being transmitted from UPF to the terminal.

It should be noted that step 603 can be implemented through step 602. For example, the SMF sends the eDRX cache information to the UPF through the N4 message sent to the UPF. For example, the SMF sends the eDRX cache information to the MB-SMF through the request message sent to the MB-SMF. information, and then MB-SMF can send eDRX cache information to MB-UPF during the interaction with MB-UPF. Step 603 can also be implemented through other signaling independent of step 602.

Step 604: The SMF sends ninth information to the access network device.

Correspondingly, the access network device receives the ninth information from the SMF.

The ninth information is used to indicate that eDRX in the inactive state is successfully configured for the terminal.

Subsequently, after receiving the ninth information, the access network device can initiate the RRC connection release process and configure eDRX for the terminal.

It should be noted that the interaction between the access network device and the SMF can be through the AMF. In this case, although the information received by the AMF and the information sent by the AMF are both called ninth information, the information received by the AMF and The information sent by AMF can be implemented in the same way or in different ways (for example, through different messages and/or cells) without limitation.

In this way, when a terminal joins a multicast session, the access network device can convert the terminal into an inactive state and configure eDRX for the terminal, and UPF or MB-UPF caches the terminal's multicast data to ensure multicast Transmission of data.

Optionally, in another scenario of the above embodiment, after receiving the second information, the SMF caches the terminal's multicast data or the SMF notifies the MB-SMF to cache the terminal's multicast data.

The embodiments of the present application are described in detail below with reference to specific examples.

In the following example, the eDRX information may correspond to the eDRX cache information above.

Example 1

Figure 7 is an example of the communication method of the present application.

In this example, the access network device may or may not support multicast.

Step 701: The terminal registers with the network and negotiates eDRX parameters for connection management (CM)-idle state (IDLE) with the network.

Specifically, when the terminal supports eDRX, the terminal carries information indicating that the terminal supports eDRX in the registration request message sent to the AMF; if the terminal is allowed to enter the eDRX state, then the AMF carries in the registration acceptance message sent to the terminal. Information indicating that the terminal is allowed to enter eDRX, and information about the paging time window (PTW). When the terminal does not support eDRX, the terminal carries information indicating that the terminal does not support eDRX in the registration request message sent to the AMF.

For a more detailed description of step 701, reference may be made to the existing technology and will not be described again here.

Step 702: The terminal requests to join the multicast session, and accordingly, the core network device establishes related resources for the multicast session.

Specifically, the terminal sends a PDU session modification request message or a PDU session establishment request message to the core network device, and the message carries the identifier of the multicast session that the terminal requests to join; the core network device generates the multicast session based on the identifier of the multicast session that the terminal requests to join. The context corresponding to the multicast session and the optional unicast QoS flow information corresponding to the multicast session are sent to the access network device; the access network device establishes or modifies the multicast based on the received information. The context corresponding to the session, and optionally establishes a unicast context.

For a more detailed description of step 702, reference may be made to the existing technology and will not be described again here.

Through step 702, the SMF can learn that the terminal has joined the multicast session.

Step 703: After the terminal joins the multicast session, the SMF sends the N11 message to the AMF.

Accordingly, the AMF receives the N11 message from the SMF.

Among them, the N11 message is used to notify the AMF that the terminal has joined the multicast session. Specifically, the N11 message includes the identifier of the multicast session to which the terminal joins (for example, a temporary multicast group identifier (TMGI)). Optionally, the N11 message also includes indication information #1, which is used to indicate that the terminal has joined the multicast session.

It should be noted that when the N11 message does not include indication information #1, it can be considered that the multicast session identifier included in the N11 message implicitly indicates that the terminal has joined the multicast session corresponding to the identifier.

It should also be pointed out that the SMF can only send the N11 message to the AMF when the multicast session joined by the terminal is active. In other words, the N11 message can implicitly indicate that the multicast session is active.

Step 704: The access network device reports to the AMF whether the access network device supports eDRX.

One possible implementation method is that when the access network device is powered on, the access network device reports to the AMF whether it supports eDRX. For example, the access network device carries eDRX capability information of the access network device in a next generation application protocol (NGAP) setup request message (NGAP setup request). The eDRX capability information is used to indicate whether the access network device Support eDRX.

Step 704 is an optional step.

Step 705: AMF determines whether the terminal can be converted to the inactive state of eDRX (ie, RRC inactive with eDRX) based on whether the access network equipment supports eDRX, whether the terminal supports eDRX, and whether the terminal has joined the multicast session.

Specifically, when the access network device does not support eDRX, and/or the terminal does not support eDRX, and/or the terminal has joined the multicast session, the AMF determines that the terminal is not suitable for eDRX in the inactive state. When the access network equipment supports eDRX, the terminal supports eDRX, and the terminal does not join the multicast session, AMF determines that the terminal is suitable for eDRX in the inactive state.

It should be noted that if step 704 is not performed, the AMF may not consider whether the access network device supports eDRX when determining whether the terminal can be converted to the inactive state of eDRX.

Step 706: The AMF sends instruction information #2 to the access network device.

Correspondingly, the access network device receives indication information #2 from the AMF.

Among them, the indication information #2 is used to indicate whether the terminal is suitable for eDRX in the inactive state. Instruction information #2 may correspond to the first information above.

In a possible implementation manner, the indication information #2 can be carried in RRC inactive assistance information (RRC inactive assistance information, RIAI).

Step 707: The access network device converts or not converts the terminal to the inactive state of eDRX according to the instruction information #2.

Specifically, when the indication information #2 is used to indicate that the terminal is not applicable to eDRX in the inactive state, the access network device does not convert the terminal to the inactive state of eDRX. When the instruction information #2 is used to instruct the terminal to apply eDRX in the inactive state, the access network device further combines other information (such as whether the access network device supports eDRX (if step 704 is not performed), the implementation of the access network device, and the current load of the access network equipment, etc.), determine whether to convert the terminal to the inactive state of eDRX or not to convert the terminal to the inactive state of eDRX.

In this way, in this example, when the terminal has joined the multicast session, the access network device does not convert the terminal to the inactive state of eDRX, which helps ensure the transmission of multicast services.

Example 2

Figure 8 is another example of the communication method of the present application.

In this example, the access network device supports multicast. Since the access network device supports multicast, the access network device knows whether the terminal has joined the multicast session and the status of the multicast session.

Step 801: The terminal registers with the network and negotiates eDRX parameters for CM-IDLE with the network.

Step 802: The terminal requests to join the multicast session, and accordingly, the core network device establishes related resources for the multicast session.

Steps 801 to 802 may refer to steps 701 to 702, which will not be described in detail here.

Step 803: The access network device converts or does not convert the terminal to the inactive state of eDRX based on whether the access network device supports eDRX, whether the terminal supports eDRX, and whether the terminal has joined the multicast session.

One possible implementation method is that when the access network device does not support eDRX, and/or the terminal does not support eDRX, and/or the terminal has joined the multicast session, the access network device does not convert the terminal to the inactive state of eDRX. . When the access network device supports eDRX, the terminal supports eDRX, and the terminal does not join the multicast session, the access network device can convert the terminal to the inactive state of eDRX, but whether the access network device converts the terminal to the inactive state of eDRX state, it also depends on whether other conditions that need to be met to convert the terminal to the inactive state of eDRX are met (for example, the implementation of the access network equipment or the current load of the access network equipment, etc.).

In another possible implementation manner, the access network device can further consider the status of the multicast session joined by the terminal. For example, when the access network device does not support eDRX, and/or the terminal does not support eDRX, and/or the terminal has joined a multicast session and the multicast session is active, the access network device does not convert the terminal to eDRX The inactive state of eDRX; otherwise, the access network equipment can convert the terminal to the inactive state of eDRX, but whether the access network equipment converts the terminal to the inactive state of eDRX depends on whether the inactive state of converting the terminal to eDRX is met. When there are other conditions that need to be met in the activation state (for example, the implementation of the access network device or the current load of the access network device, etc.).

In this way, in this example, when the terminal has joined the multicast session (the multicast session is optionally in the active state), the access network device does not convert the terminal into the inactive state of eDRX, which helps to ensure that multiple transmission of broadcast services.

Example 3

Figure 9 is another example of the communication method of the present application.

Step 901: The terminal registers with the network and negotiates eDRX parameters for CM-IDLE with the network.

Step 902: The terminal requests to join the multicast session, and accordingly, the core network device establishes related resources for the multicast session.

Steps 901 to 902 may refer to steps 701 to 702, which will not be described in detail here.

Step 903: After the terminal joins the multicast session, the SMF sends the N11 message to the AMF.

Accordingly, the AMF receives the N11 message from the SMF.

Among them, the N11 message is used to notify the AMF that the terminal has joined the multicast session. Specifically, the N11 message includes the identification (for example, TMGI) of the multicast session to which the terminal joins. Optionally, the N11 message also includes indication information #1, which is used to indicate that the terminal has joined the multicast session.

It should be noted that when the N11 message does not include indication information #1, it can be considered that the multicast session identifier included in the N11 message implicitly indicates that the terminal has joined the multicast session corresponding to the identifier.

It should also be pointed out that the SMF can only send the N11 message to the AMF when the multicast session joined by the terminal is active. In other words, the N11 message can implicitly indicate that the multicast session is active.

Step 904: The access network device decides to convert the terminal to the inactive state of eDRX based on the RIAI and other possible information (such as the implementation of the access network device or the current load of the access network device, etc.).

Step 905: Before converting the terminal to the inactive state of eDRX, the access network device sends the N2 message to the AMF.

Correspondingly, the AMF receives the N2 message from the access network device.

The N2 message is used to request that the terminal be converted to an inactive state of eDRX, and the message carries eDRX information (for example, the period for the terminal to enter eDRX, etc.). In this way, after receiving the N2 message, the AMF can learn based on the N2 message that the access network equipment plans to convert the terminal to the inactive state of eDRX.

For a more detailed description of steps 904 to 905, reference can be made to the existing technology and will not be described in detail here.

Step 906: The AMF determines that the terminal is not suitable for eDRX in the inactive state based on the information obtained in step 903 (such as TMGI and/or indication information #1).

Step 907: The AMF sends the N2 message to the access network device.

Correspondingly, the access network device receives the N2 message from the AMF.

The N2 message is used to reject the request to convert the terminal to the inactive state of eDRX. Exemplarily, the N2 message includes rejection information and rejection reason, where the rejection information is used to indicate rejection of converting the terminal to the inactive state of eDRX, and the rejection reason includes that the terminal has joined the multicast session.

Step 908: The access network device does not convert the terminal to the inactive state of eDRX according to the N2 message in step 907.

In this way, in this example, when the terminal has joined the multicast session, the access network device does not convert the terminal to the inactive state of eDRX, which helps ensure the transmission of multicast services.

Example 4

Figure 10 is another example of the communication method of the present application.

Step 1001: The terminal registers with the network and negotiates eDRX parameters for CM-IDLE with the network.

Step 1002: The terminal requests to join the multicast session, and accordingly, the core network device establishes related resources for the multicast session.

Steps 1001 to 1002 may refer to steps 701 to 702, which will not be described in detail here.

Step 1003: The access network device decides to convert the terminal to an inactive state based on the RIAI and other possible information (such as the implementation of the access network device or the current load of the access network device, etc.).

Step 1004: The access network device sends the N2 message to the AMF.

Correspondingly, the AMF receives the N2 message from the access network device.

The N2 message is used to request that the terminal be converted to an inactive state of eDRX, and the message carries eDRX information (for example, the period for the terminal to enter eDRX, etc.).

In this way, after receiving the N2 message, the AMF can learn based on the N2 message that the access network equipment plans to convert the terminal to the inactive state of eDRX, so as to subsequently notify the SMF corresponding to the PDU session in the active state of the user plane to convert the terminal to the inactive state of eDRX. The inactive state of eDRX.

For a more detailed description of steps 1003 to 1004, reference can be made to the existing technology and will not be described in detail here.

Step 1005, AMF sends the N11 message to SMF.

Accordingly, SMF receives the N11 message from AMF.

Among them, the N11 message is used to request to convert the terminal to the inactive state of eDRX. The message carries eDRX information (for example, the period for the terminal to enter eDRX, etc.).

One possible implementation method is that the N11 message is Nsmf_PDUSessionUpdateSMContext request.

Step 1006: Based on the fact that the terminal has joined the multicast session, the SMF determines that the terminal is not suitable for eDRX in the inactive state.

The SMF can learn that the terminal has joined the multicast session through step 1002.

Step 1007: SMF sends the N11 message to AMF.

Accordingly, the AMF receives the N11 message from the SMF.

Among them, the N11 message is used to reject the request to convert the terminal to the inactive state of eDRX. Exemplarily, the N11 message includes rejection information and rejection reason, where the rejection information is used to refuse to convert the terminal to the inactive state of eDRX, and the rejection reason includes that the terminal has joined the multicast session.

One possible implementation method is that the N11 message is Nsmf_PDUSessionUpdateSMContext response.

Step 1008: If the AMF also sends an N11 message to other SMFs in step 1004, then after receiving the N11 message in step 1007, the AMF sends an N11 message to other SMFs.

The N11 message is used to withdraw the request to convert the terminal to the inactive state of eDRX. For example, the N11 message may carry instruction information #3, and the instruction information #3 is used to instruct to stop converting the terminal to the inactive state of eDRX.

Step 1009: The AMF sends the N2 message to the access network device.

Correspondingly, the access network device receives the N2 message from the AMF.

The N2 message is used to reject the request of the access network device to convert the terminal to the inactive state of eDRX. Exemplarily, the N2 message includes rejection information and rejection reason, where the rejection information is used to refuse to convert the terminal to the inactive state of eDRX, and the rejection reason includes that the terminal has joined the multicast session.

Step 1010: The access network device does not convert the terminal to the inactive state of eDRX according to the N2 message in step 1009.

In this way, in this example, when the terminal has joined the multicast session, the access network device does not convert the terminal to the inactive state of eDRX, which helps ensure the transmission of multicast services.

Example 5

Figure 11 is another example of the communication method of the present application.

Step 1101: The terminal registers with the network and negotiates eDRX parameters for CM-IDLE with the network.

Step 1102: The terminal requests to join the multicast session, and accordingly, the core network device establishes related resources for the multicast session.

Steps 1101 to 1102 may refer to steps 701 to 702, which will not be described in detail here.

Step 1103: SMF sends the N1 message to the terminal.

Accordingly, the terminal receives the N1 message from the SMF.

The N1 message includes service characteristics of the multicast service corresponding to the multicast session. The multicast session here can be a multicast session joined by the terminal. The service characteristics of the multicast service may be used to determine or indicate whether the multicast service supports eDRX. For example, the service characteristics of the multicast service may include whether the multicast service supports eDRX, whether the multicast service is a delay-sensitive type, etc.

In one possible implementation, the N11 message may be the message in step 1102, that is, step 1103 may be implemented through step 1102, or in other words, step 1103 is a part of step 1102. For example, the N11 message may be a response message to the multicast session join request message, such as a PDU session modification command, etc. In this case, the service characteristic of the multicast service may be an information element in the message.

In another possible implementation manner, the N11 message may be a newly added message used to transmit the service characteristics of the multicast service.

Step 1104: When the following conditions are met, the terminal sends a registration request message to the AMF in order to re-negotiate the terminal's eDRX capabilities with the network:

Condition 1: The terminal has joined the multicast session;

Condition 2: The service characteristics of the multicast service carried in the N1 message received in step 1403 indicate that the multicast service does not support eDRX;

Condition 3: eDRX parameters for CM-IDLE have been negotiated with the network before, and information indicating that the terminal is allowed to enter eDRX and PTW information are received.

The registration request message does not carry information indicating that the terminal supports eDRX or carries information indicating that the terminal does not support eDRX.

It should be pointed out that the terminal may not consider condition 2.

After that, since the terminal has joined the multicast session, information indicating that the terminal supports eDRX will not be carried when the terminal initiates the registration process again. Of course, if the terminal leaves all the multicast sessions it has joined, the terminal can carry information indicating that the terminal supports eDRX when initiating the registration process again.

Step 1105: After receiving the registration request message from the terminal, the AMF sends a terminal context update message to the access network device.

Correspondingly, the access network device receives the terminal context update message from the AMF.

The terminal context update message does not include information indicating that the terminal supports eDRX, or the terminal context update message includes information indicating that the terminal does not support eDRX. For example, the RIAI information does not carry the UE specific extended idle mode DRX, or the RIAI information carries the UE specific extended idle mode DRX, but the UE specific extended idle mode DRX is a special value.

A possible implementation manner is that before the AMF sends the terminal context update message to the access network device, the AMF determines that the RIAI information has been provided to the access network device before.

Another possible implementation is that before the AMF sends the terminal context update message to the access network device, the AMF determines that RIAI information has been provided to the access network device before, and the RIAI information includes information indicating that the terminal is allowed to enter eDRX.

Step 1106: The access network device does not convert the terminal to the inactive state of eDRX according to the updated terminal context.

In the above examples 1 to 5, when the terminal has joined the multicast session, the access network device will not convert the terminal to the inactive state of eDRX. In the following Examples 6 and 7, when the terminal has joined the multicast session, the access network device can convert the terminal to the inactive state of eDRX, and the multicast data is cached in the core network device and changes to the eDRX state again at the terminal. It is sent to the terminal only when it is reachable.

Example 6

In this example, when the terminal joins the multicast session, the access network device can convert the terminal to the inactive state of eDRX, and the multicast data can be cached in the UPF.

Figure 12 is another example of the communication method of the present application.

Step 1201: The terminal registers with the network and negotiates eDRX parameters for CM-IDLE with the network.

Step 1202: The terminal requests to join the multicast session, and accordingly, the core network device establishes related resources for the multicast session.

Steps 1201 to 1202 may refer to steps 701 to 702, which will not be described in detail here.

Step 1203: The AMF sends the N2 message to the access network device.

Correspondingly, the access network device receives the N2 message from the AMF.

Among them, the N2 message includes RIAI. The RIAI carries the information required to convert the terminal to the inactive state, such as registration area, periodic registration time, UE specific extended idle mode DRX values (UE specific extended idle mode DRX values), etc.

Step 1204: The access network device decides to send the terminal to the terminal based on the RIAI and other possible information (such as the implementation of the access network device, the UE's radio capability (UE Radio Capability) supporting eDRX, or the current load of the access network device, etc.) Convert to RRC inactive state.

Step 1205: The access network device sends the N2 message to the AMF.

Correspondingly, the AMF receives the N2 message from the access network device.

Among them, the N2 message includes eDRX information (for example, the period for the terminal to enter eDRX, eDRX indication, cache time, etc.). In this way, after receiving the N2 message, the AMF can learn based on the N2 message that the access network equipment plans (or prepares) to convert the terminal to the inactive state of eDRX, and then for the PDU session in the active state on the user plane, the AMF can notify The corresponding SMF.

Optionally, the N2 message may be a UE Notification message, an RRC INACTIVE TRANSITION REPORT message, or other messages, which are not limited in this application.

Step 1206: AMF sends an update session management context request message (such as Nsmf_PDUSessionUpdateSMContext request) to the corresponding SMF.

Accordingly, the SMF receives the update session management context request message from the AMF.

The update session management context request message carries instruction information #4 and eDRX information. Instruction information #4 is used to instruct to stop user plane transmission and cache user plane multicast data.

Thereafter, if the downlink multicast data is processed by the SMF, the SMF starts to cache the downlink multicast data. If the downlink multicast data is processed by MB-SMF, the SMF notifies MB-SMF to cache the downlink multicast data. If the downlink multicast data is processed by UPF or MB-UPF, the SMF may continue to perform step 1207.

One possible implementation solution is that the indication information #4 may be a user plane suspend (UP Suspend) indication.

An example may be that the N2 message contains a list of PDU sessions that are active on the user plane, and the AMF notifies the corresponding SMF according to the list.

Step 1207: After receiving the update session management context request message in step 1206, SMF triggers the establishment of a transmission channel (or forwarding channel, channel, forwarding tunnel) from MB-UPF to UPF.

In one possible implementation, if the SMF is an SMF that manages a unicast session associated with a terminal's multicast session, the SMF determines: a) There is currently no MB-UPF to UPF transmission channel for the terminal; and/or , b) SMF has established a transmission channel from MB-UPF to UPF, but MB-UPF does not send data to UPF at this time (for example, MB-UPF is configured not to send data to UPF); and/or, c) the terminal is currently resident The access network equipment supports multicast (for example, the SMF receives the indication information "NG-RAN supports MBS" from the N2 message received by the access network equipment); the SMF triggers the establishment of MB-UPF to UPF transmission channel. "Create" here can refer to new creation or modification.

The steps to establish the transmission channel from MB-UPF to UPF are as steps 1208~1212.

Step 1208: SMF sends an N4 message (such as an N4 session modification request message) to UPF.

Accordingly, UPF receives the N4 message from SMF.

Among them, the N4 message is used to request the establishment of a transmission channel from UPF to MB-UPF, or to ask UPF whether a transmission channel from UPF to MB-UPF has been established. The N4 message includes eDRX information (buffer info for eDRX), multicast session identifier (such as TMGI), optional SSM and other information. The eDRX information is used to cache the multicast data of the terminal.

Optionally, the N4 message also includes configuration information. The configuration information is used to configure: a) multicast data identification rules; b) multicast data forwarding rules, etc.

Step 1209: The UPF sends the response message or data packet of the N4 message in step 1208 to the SMF.

Accordingly, SMF receives the response message or data packet from UPF.

The response message includes downlink tunnel ID #1 (such as DL tunnel ID #1).

Specifically, after receiving the N4 message in step 1208, UPF determines whether a transmission channel from UPF to MB-UPF has been established. If the transmission channel from UPF to MB-UPF has not been established, UPF can return the downlink tunnel identification #1, or send the data packet according to the SSM information.

Optionally, the UPF may also include whether the downlink tunnel identifier #1 is newly allocated in the N4 response message.

Step 1210: SMF sends the N16mb message to MB-SMF.

Correspondingly, MB-SMF receives the N16mb message from SMF.

Among them, the N16mb message is used to request the establishment of a transmission channel from UPF to MB-UPF. Optionally, the N16mb message includes downlink tunnel identification #1.

Optionally, if the UPF includes in the N4 response message that the downlink tunnel identifier #1 is newly allocated, the SMF may send the N16mb message to the MB-SMF.

Step 1211, MB-SMF and MB-UPF perform the N4mb session modification process.

During this process, MB-SMF may provide downlink tunnel identity #1 to MB-UPF or receive downlink tunnel identity #2 provided by MB-UPF for multicast.

Step 1212: MB-SMF sends the response message of the N16mb message in step 1210 to SMF.

Accordingly, the SMF receives the response message from the MB-SMF.

Optionally, the response message carries downlink tunnel identification #2.

Optionally, if the N4 message does not include configuration information in step 1208, the SMF can configure the following content for the UPF after receiving the response message: a) multicast data identification rules; b) multicast data forwarding rules, etc.

Optionally, if the response message includes downlink tunnel identification #2, the SMF may provide the downlink tunnel identification #2 to the UPF.

Step 1213: The SMF sends the response message to the N11 message in step 1206 to the AMF.

Accordingly, AMF receives the response message from SMF.

Step 1214: The AMF sends the response message of the N2 message in step 1205 to the access network device.

Correspondingly, the access network device receives the response message from the AMF.

Step 1215: The access network device converts the terminal to the RRC inactive state of eDRX.

Figure 13 is a schematic diagram of transmitting multicast data.

The schematic diagram of transmitting multicast data shown in Figure 13 is based on the transmission method shown in Figure 12. When the terminal has joined the multicast session, the access network device can convert the terminal to the inactive state of eDRX.

As shown in (a) of Figure 13, for a terminal in the inactive state of DRX (such as terminal 1), MB-UPF multicasts the multicast of terminal 1 in the eDRX state through the transmission channel between UPF and MB-UPF. The data is transmitted to UPF, which caches the multicast data for terminal 1.

As shown in (b) of Figure 13, when the terminal becomes reachable again, UPF sends the cached multicast data to the terminal.

In this way, when a terminal joins a multicast session, the access network equipment can convert the terminal to the inactive state of eDRX, and the multicast data can be cached in the UPF, thereby preventing the terminal from missing multicast data and helping to ensure multicast services. transmission.

Example 7

In this example, when the terminal joins the multicast session, the access network device can convert the terminal to the inactive state of eDRX, and the multicast data can be cached in the MB-UPF.

Figure 14 is another example of the communication method of the present application.

Step 1401: The terminal registers with the network and negotiates eDRX parameters for CM-IDLE with the network.

Step 1402: The terminal requests to join the multicast session, and accordingly, the core network device establishes related resources for the multicast session.

Steps 1401 to 1402 may refer to steps 701 to 702, which will not be described in detail here.

Step 1403: The AMF sends the N2 message to the access network device.

Correspondingly, the access network device receives the N2 message from the AMF.

Among them, the N2 message includes RIAI. The RIAI carries the information required to convert the terminal to the inactive state, such as registration area, periodic registration time, UE specific extended idle mode DRX values (UE specific extended idle mode DRX values), etc.

Step 1404: The access network device decides to use the terminal based on the RIAI and other possible information (such as the implementation of the access network device, the UE's radio capability (UE Radio Capability) to support eDRX, or the current load of the access network device, etc.) Convert to RRC inactive state.

Step 1405: The access network device sends the N2 message to the AMF.

Correspondingly, the AMF receives the N2 message from the access network device.

Among them, the N2 message includes eDRX information (for example, the period for the terminal to enter eDRX, eDRX indication, cache time, etc.). In this way, after receiving the N2 message, the AMF can learn based on the N2 message that the access network equipment plans (or prepares) to convert the terminal to the inactive state of eDRX, and then for the PDU session in the active state on the user plane, the AMF can notify The corresponding SMF.

Optionally, the N2 message may be a UE Notification message, an RRC INACTIVE TRANSITION REPORT message, or other messages, which are not limited in this application.

Step 1406: AMF sends an update session management context request message (such as Nsmf_PDUSessionUpdateSMContext request) to the corresponding SMF.

Accordingly, the SMF receives the update session management context request message from the AMF.

An example may be that the N2 message contains a list of PDU sessions that are active on the user plane, and the AMF notifies the corresponding SMF according to the list.

The update session management context request message carries instruction information #4 and eDRX information. Instruction information #4 is used to instruct to stop user plane transmission and cache user plane multicast data.

Thereafter, if the downlink multicast data is processed by the SMF, the SMF starts to cache the downlink multicast data. If the downlink multicast data is processed by MB-SMF, the SMF notifies MB-SMF to cache the downlink multicast data. If the downlink multicast data is processed by UPF or MB-UPF, the SMF may continue to perform step 1407.

Step 1407: After receiving the update session management context request message in step 1406, SMF triggers the establishment of a transmission channel (or forwarding channel, channel, forwarding tunnel) from MB-UPF to UPF.

One possible implementation is that if the SMF is the SMF that manages the unicast session associated with the multicast session of the terminal, the SMF determines: a) For the terminal, there is currently no MB-UPF to UPF transmission channel; and/ Or, b) SMF establishes a transmission channel from MB-UPF to UPF, but MB-UPF does not send data to UPF at this time (for example, MB-UPF is configured not to send data to UPF); and/or, c) The terminal is currently The resident access network device supports multicast (for example, the SMF receives the "NG-RAN supports MBS" indication information from the N2 message received by the access network device); the SMF triggers the establishment of MB-UPF Transmission channel to UPF. "Create" here can refer to new creation or modification.

The judgment logic in step 1407 may or may not be executed without limitation.

The steps to establish the transmission channel from MB-UPF to UPF are as steps 1408~1412.

Step 1408: SMF sends an N4 message (such as an N4 session modification request message) to UPF.

Accordingly, UPF receives the N4 message from SMF.

Among them, the N4 message is used to request the establishment of a transmission channel from UPF to MB-UPF, or to ask UPF whether a transmission channel from UPF to MB-UPF has been established. The N4 message includes eDRX information, multicast session identifier (such as TMGI), optional SSM and other information. The eDRX information is used to cache the multicast data of the terminal.

Optionally, the N4 message also includes configuration information. The configuration information is used to configure: a) multicast data identification rules; b) multicast data forwarding rules, etc.

Step 1409: The UPF sends the response message or data packet of the N4 message in step 1408 to the SMF.

Accordingly, SMF receives the response message or data packet from UPF.

The response message includes downlink tunnel ID #1 (such as DL tunnel ID #1).

Specifically, after receiving the N4 message in step 1408, UPF determines whether a transmission channel from UPF to MB-UPF has been established. If the transmission channel from UPF to MB-UPF has not been established, UPF can return the downstream tunnel identification #1, or send the data packet according to the SSM information.

Optionally, the UPF may also include whether the downlink tunnel identifier #1 is newly allocated in the N4 response message.

Step 1410: SMF sends the N16mb message to MB-SMF.

Correspondingly, MB-SMF receives the N16mb message from SMF.

Among them, the N16mb message is used to request the establishment of a transmission channel from UPF to MB-UPF, and the N16mb message includes eDRX information. Optionally, the N16mb message includes downlink tunnel identification #1.

Optionally, if the UPF includes in the N4 response message that the downlink tunnel identifier #1 is newly allocated, the SMF may send the N16mb message to the MB-SMF.

Step 1411, MB-SMF and MB-UPF perform the N4mb session modification process.

In this process, MB-SMF may provide eDRX information to MB-UPF, and provide downlink tunnel identification #1 to MB-UPF or receive downlink tunnel identification #2 provided by MB-UPF for multicast.

Step 1412: MB-SMF sends the response message of the N16mb message in step 1410 to SMF.

Accordingly, the SMF receives the response message from the MB-SMF.

Optionally, the response message carries downlink tunnel identification #2.

Optionally, if the N4 message does not include configuration information in step 1408, the SMF can configure the following content for the UPF after receiving the response message: a) multicast data identification rules; b) multicast data forwarding rules, etc.

Optionally, if the response message includes downlink tunnel identification #2, the SMF may provide the downlink tunnel identification #2 to the UPF.

Step 1413: The SMF sends the response message of the N11 message in step 1406 to the AMF.

Accordingly, AMF receives the response message from SMF.

Step 1414: The AMF sends the response message of the N2 message in step 1405 to the access network device.

Correspondingly, the access network device receives the response message from the AMF.

Step 1415: The access network device converts the terminal to the RRC inactive state of eDRX.

Figure 15 is another schematic diagram of transmitting multicast data.

The schematic diagram of transmitting multicast data shown in Figure 15 is based on the transmission method shown in Figure 14. When the terminal has joined the multicast session, the access network device can convert the terminal to the inactive state of eDRX.

As shown in (a) of Figure 15, for terminals in the inactive DRX state (such as terminal 1), MB-UPF caches multicast data for terminals in the eDRX state (such as terminal 1).

As shown in (b) of Figure 15, when the terminal becomes reachable again, MB-UPF transmits the cached multicast data to UPF through the transmission channel between UPF and MB-UPF, and then UPF sends it to the terminal. .

In this way, when a terminal joins a multicast session, the access network equipment can convert the terminal to the inactive state of eDRX, and the multicast data can be cached in MB-UPF, thereby preventing the terminal from missing multicast data and helping to ensure multicast data transmission. transmission of broadcast services. In addition, MB-UPF caches multicast data with a relatively high cache point, which helps reduce the amount of data cached by the network.

The method provided by the present application has been described in detail above with reference to Figures 3 to 15, and the device embodiment of the present application will be described in detail below with reference to Figures 16 to 17.

It can be understood that, in order to implement the functions in the above embodiments, the device in Figure 16 or Figure 17 includes corresponding hardware structures and/or software modules to perform each function. Those skilled in the art should easily realize that the units and method steps of each example described in conjunction with the embodiments disclosed in this application can be implemented in the form of hardware or a combination of hardware and computer software.

Figures 16 and 17 are schematic structural diagrams of possible devices provided by embodiments of the present application. These devices can be used to implement the functions of core network equipment, access network equipment, access and mobility management functional network elements, terminals, session management functions or multicast user plane functional network elements in the above method embodiments, and therefore can also be implemented The above method embodiments have beneficial effects.

As shown in Figure 16, the device 1600 includes a transceiver unit 1610 and a processing unit 1620.

In some implementations, when the device 1600 is used to implement the functions of the core network device in the above method embodiment, the transceiver unit 1610 is used to: learn that the terminal has joined the multicast session; send first information, the first information is used to: The notification refuses to configure eDRX in the inactive state for the terminal, or the first information is used to indicate that the terminal is not suitable for eDRX in the inactive state.

Optionally, the transceiver unit 1610 is specifically configured to: send the first information when at least one of the following conditions is met: the access network equipment that provides services for the terminal does not support eDRX, and the terminal does not support eDRX. , or the multicast session meets a preset condition; wherein the preset condition is: the multicast session is in an active state, the multicast service corresponding to the multicast session does not support eDRX, or the multicast session The multicast service corresponding to the active state and the multicast session does not support eDRX.

Optionally, when the first information is used to notify a refusal to configure eDRX in an inactive state for the terminal, the first information includes refusal information, and the refusal information is used to indicate a refusal to configure eDRX for the terminal in an inactive state. eDRX in active state.

Optionally, the transceiver unit 1610 is further configured to receive second information, where the second information is used to request to configure eDRX in an inactive state for the terminal.

Optionally, the rejection information includes a reason for refusing to configure eDRX in an inactive state for the terminal; wherein the reason includes at least one of the following: the terminal has joined a multicast session, The access network equipment does not support eDRX, the terminal does not support eDRX, or the multicast session meets preset conditions; wherein the preset conditions are: the multicast session is active, the multicast session corresponds to The multicast service does not support eDRX, or the multicast session is in an active state and the multicast service corresponding to the multicast session does not support eDRX.

Optionally, the transceiver unit 1610 is further configured to receive third information from the access network device, where the third information is used to indicate that the access network device does not support eDRX.

Optionally, the core network device is an access and mobility management function network element or a session management function network element.

Optionally, the core network device is an access and mobility management function network element, and the transceiver unit 1610 is further configured to: receive service information from the session management function, where the service information is used to indicate the multicast session corresponding to Multicast services do not support eDRX.

Optionally, the service information includes a type of the multicast service, and the type is a delay-sensitive type.

Optionally, the core network device is an access and mobility management function network element, and the transceiver unit 1610 is further configured to: receive fourth information from the session management function network element, where the fourth information is used to indicate to the terminal Joined multicast session.

In some implementations, when the device 1600 is used to implement the functions of the access network device in the above method embodiment, the transceiver unit 1610 is configured to: when it is determined to convert the terminal to the inactive state, send the second information to the core network device , the second information is used to request to configure eDRX in the inactive state for the terminal; receive the first information from the core network device, the first information is used to notify the refusal to configure the inactive state for the terminal eDRX under. The processing unit 1620 is configured to not configure eDRX in an inactive state for the terminal according to the first information.

Optionally, the first information includes rejection information, and the rejection information is used to indicate a refusal to configure eDRX in an inactive state for the terminal.

Optionally, the rejection information includes a reason for refusing to configure eDRX in an inactive state for the terminal; wherein the reason includes at least one of the following: the terminal has joined a multicast session, the access network device is not eDRX is supported, the terminal does not support eDRX, or the multicast session meets preset conditions; wherein the preset conditions are: the multicast session is in an active state, and the multicast service corresponding to the multicast session does not eDRX is supported, or the multicast session is in an active state and the multicast service corresponding to the multicast session does not support eDRX.

Optionally, the core network device is an access and mobility management function network element or a session management function network element.

In other implementations, when the device 1600 is used to implement the functions of the access network device in the above method embodiment, the transceiver unit 1610 is used to: receive first information from the core network device, the first information is used to indicate The terminal does not support eDRX in the inactive state. The processing unit 1620 is configured to: when it is determined to convert the terminal to the inactive state, not configure eDRX in the inactive state for the terminal according to the first information.

Optionally, the core network device is an access and mobility management function network element or a session management function network element.

In some implementations, when the device 1600 is used to implement the functions of the access network device in the above method embodiment, the transceiver unit 1610 is used to: learn that the terminal has joined the multicast session. The processing unit 1620 is configured to: when determining to convert the terminal to the inactive state, not configure eDRX in the inactive state for the terminal.

Optionally, the processing unit 1620 is specifically configured to: not configure eDRX in the inactive state for the terminal when at least one of the following conditions is met: the access network device does not support eDRX, the terminal does not support eDRX, or the multicast session satisfies preset conditions; wherein the preset conditions are: the multicast session is active, the multicast service corresponding to the multicast session does not support eDRX, or the multicast The session is active and the multicast service corresponding to the multicast session does not support eDRX.

Optionally, the transceiver unit 1610 is also configured to receive service information from the session management function, where the service information is used to indicate that the multicast service corresponding to the multicast session does not support eDRX.

Optionally, the service information includes a type of the multicast service, and the type is a delay-sensitive type.

In some implementations, when the device 1600 is used to implement the functions of the access and mobility management function network element in the above method embodiment, the transceiver unit 1610 is used to: receive the second information from the access network device, the first The second information is used to request to configure eDRX in the inactive state for the terminal; the second information is sent to the first session management function network element and the second session management function network element, and the first session management function network element is used for management The unicast session associated with the multicast session of the terminal, the second session management function network element is used to manage the unicast session not associated with the multicast session of the terminal; receiving from the first session management The first information of the functional network element, the first information is used to notify the refusal to configure eDRX in the inactive state for the terminal; send the first information to the access network device, and/or, The second session management function network element sends fifth information, and the fifth information is used to trigger the second session management function network element to stop configuring eDRX in an inactive state for the terminal.

Optionally, the first information includes rejection information, and the rejection information is used to indicate a refusal to configure eDRX in an inactive state for the terminal.

Optionally, the rejection information includes a reason for refusing to configure eDRX in an inactive state for the terminal; wherein the reason includes at least one of the following: the terminal has joined a multicast session, the access network device is not eDRX is supported, the terminal does not support eDRX, or the multicast session meets preset conditions; wherein the preset conditions are: the multicast session is in an active state, and the multicast service corresponding to the multicast session does not eDRX is supported, or the multicast session is in an active state and the multicast service corresponding to the multicast session does not support eDRX.

In some implementations, when the device 1600 is used to implement the functions of the terminal in the above method embodiment, the transceiver unit 1610 is used to: learn that the terminal has joined the multicast session and the terminal supports eDRX; and sends a message to the access network device. Sixth information, the sixth information is used to indicate that the terminal does not support eDRX.

Optionally, the transceiver unit 1610 is specifically configured to: send the sixth information to the access network device when at least one of the following conditions is met: receiving the first information from the core network device, the access network device The network access device does not support eDRX, the terminal does not support eDRX, or the multicast session meets preset conditions; wherein the first information is used to indicate that the terminal is not suitable for eDRX in an inactive state, and the preset Assume that the condition is: the multicast session is in an active state, the multicast service corresponding to the multicast session does not support eDRX, or the multicast session is in an active state and the multicast service corresponding to the multicast session does not support eDRX. .

Optionally, the core network device is an access and mobility management function network element or a session management function network element.

Optionally, the transceiver unit 1610 is also configured to receive service information from the session management function, where the service information is used to indicate that the multicast service corresponding to the multicast session does not support eDRX.

Optionally, the service information includes a type of the multicast service, and the type is a delay-sensitive type.

Optionally, before the terminal sends the sixth information to the access network device, the transceiver unit 1610 is further configured to: send seventh information to the access network device, where the seventh information is used to indicate that the terminal supports eDRX.

Optionally, the transceiver unit 1610 is further configured to: after the terminal leaves all multicast sessions that the terminal has joined, send eighth information to the access network device, where the eighth information is used to indicate that the The terminal supports eDRX.

In some implementations, when the device 1600 is used to implement the function of the session management function network element in the above method embodiment, the transceiver unit 1610 is used to: receive second information from the access network device, the second information is used to Request to configure eDRX in inactive state for the terminal. The processing unit 1620 is configured to: establish a transmission channel between the unicast user plane functional network element and the multicast user plane functional network element according to the second information, where the transmission channel is used to transmit multicast data of the terminal. The transceiver unit 1610 is further configured to send ninth information to the access network device, where the ninth information is used to indicate that eDRX in the inactive state is successfully configured for the terminal.

Optionally, the transceiver unit 1610 is further configured to send eDRX cache information to the unicast user plane functional network element or the multicast user plane functional network element, where the eDRX cache information is used to cache the multicast data.

In some implementations, when the device 1600 is used to implement the functions of the multicast user plane function network element in the above method embodiment, the transceiver unit 1610 is used to: receive eDRX cache information from the session management function network element, the eDRX cache Information used to cache multicast data for endpoints. The processing unit 1620 is configured to cache the multicast data of the terminal according to the eDRX cache information.

For a more detailed description of the above-mentioned transceiver unit 1610 and processing unit 1620, reference may be made to the relevant descriptions in the above-mentioned method embodiments, which will not be described again here.

As shown in Figure 17, device 1700 includes processor 1710. Processor 1710 is coupled to memory 1730 for storing instructions. When the device 1700 is used to implement the method described above, the processor 1710 is used to execute instructions in the memory 1730 to implement the functions of the above-mentioned processing unit 1620.

Optionally, device 1700 also includes memory 1730.

Optionally, the apparatus 1700 also includes an interface circuit 1720. The processor 1710 and the interface circuit 1720 are coupled to each other. It can be understood that the interface circuit 1720 may be a transceiver or an input-output interface. When the device 1700 is used to implement the method described above, the processor 1710 is used to execute instructions to realize the functions of the above-mentioned processing unit 1620, and the interface circuit 1720 is used to realize the functions of the above-mentioned transceiver unit 1610.

For example, when the device 1700 is a chip applied to core network equipment, access network equipment, access and mobility management function network elements, terminals, session management functions or multicast user plane function network elements, the chip implements the above In the method embodiment, the functions of core network equipment, access network equipment, access and mobility management function network elements, terminals, session management function or multicast user plane function network elements are included. The chip receives information from other modules (such as radio frequency modules or antennas) in core network equipment, access network equipment, access and mobility management function network elements, terminals, session management functions or multicast user plane function network elements. The information is sent by other devices to core network equipment, access network equipment, access and mobility management function network elements, terminals, session management function or multicast user plane function network elements; or, the chip Network access equipment, access and mobility management function network elements, terminals, session management functions or other modules (such as radio frequency modules or antennas) in multicast user plane function network elements send information, which information is core network equipment, access Network equipment, access and mobility management function network elements, terminals, session management function or multicast user plane function network elements are sent to other devices.

The application also provides a communication device, including a processor, the processor is coupled to a memory, the memory is used to store computer programs or instructions and/or data, the processor is used to execute the computer programs or instructions stored in the memory, or read the computer programs or instructions stored in the memory. Data to perform the methods in each of the above method embodiments. Optionally, there are one or more processors. Optionally, the communication device includes memory. Optionally, there are one or more memories. Optionally, the memory is integrated with the processor, or is provided separately.

The present application also provides a computer-readable storage medium, which stores the core network equipment, access network equipment, access and mobility management function network elements, terminals, session management functions or more used to implement the above method embodiments. Computer instructions broadcasting methods for execution by user plane functional network elements.

The present application also provides a computer program product, which includes instructions. When the instructions are executed by a computer, the instructions are used to implement core network equipment, access network equipment, access and mobility management function network elements, terminals, and session management in each of the above method embodiments. function or the method by which the multicast user plane function network element performs.

This application also provides a communication system, which includes the core network equipment, access network equipment, access and mobility management functional network elements, terminals, session management functions or multicast user plane functional networks in the above embodiments. At least one of the elements.

For explanations of relevant content and beneficial effects of any of the devices provided above, please refer to the corresponding method embodiments provided above, and will not be described again here.

It can be understood that the processor in the embodiment of the present application can be a central processing unit (CPU), or other general-purpose processor, digital signal processor (DSP), or application-specific integrated circuit. (application specific integrated circuit, ASIC), field programmable gate array (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. A general-purpose processor can be a microprocessor or any conventional processor.

The method steps in the embodiments of the present application can be implemented by hardware or by a processor executing software instructions. Software instructions can be composed of corresponding software modules, and the software modules can be stored in random access memory, flash memory, read-only memory, programmable read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory In a memory, a register, a hard disk, a portable hard disk, a compact disc read-only memory (CD-ROM) or any other form of storage medium well known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and storage media may be located in an ASIC. In addition, the ASIC can be located in core network equipment, access network equipment, access and mobility management function network elements, terminals, session management functions or multicast user plane function network elements. Of course, the processor and storage medium can also exist as discrete components in core network equipment, access network equipment, access and mobility management function network elements, terminals, session management functions or multicast user plane function network elements.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on the computer, the processes or functions described in the embodiments of the present application are executed in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, a network device, a user equipment, or other programmable device. The computer program or instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer program or instructions may be transmitted from a website, computer , server or data center to another website site, computer, server or data center via wired or wireless means. The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media, such as floppy disks, hard disks, and magnetic tapes; optical media, such as digital video optical disks; or semiconductor media, such as solid-state hard disks.

In the various embodiments of this application, if there is no special explanation or logical conflict, the terms and/or descriptions between different embodiments are consistent and can be referenced to each other. The technical features in different embodiments are based on their inherent Logical relationships can be combined to form new embodiments.

It can be understood that the various numerical numbers involved in the embodiments of the present application are only for convenience of description and are not used to limit the scope of the embodiments of the present application. The size of the serial numbers of the above processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic.

Unless otherwise stated, all technical and scientific terms used in the embodiments of this application have the same meanings as commonly understood by those skilled in the technical field of this application. The terminology used in this application is for the purpose of describing specific embodiments only and is not intended to limit the scope of this application. It should be understood that the above are examples, and the above examples are only to help those skilled in the art understand the embodiments of the present application, but are not intended to limit the embodiments of the present application to the specific numerical values or specific scenarios illustrated. Those skilled in the art can obviously make various equivalent modifications or changes based on the examples given above, and such modifications and changes also fall within the scope of the embodiments of the present application. The above are only preferred embodiments of the present invention, and all equivalent changes and modifications made in accordance with the patentable scope of the present invention shall fall within the scope of the present invention.

UDM: unified data management AMF: Access and Mobility Management Functions SMF: session management function PCF: Policy Control Function AF: Application function UE: User Equipment RAN: Radio Access Network UPF: user plane function DN: data network NRF: Network function library function MB-SMF: Multicast/Broadcast-Session Management Function MBSF: multicast/broadcast service function NEF: Network Open Function AF/AS: Application Function/Application Server UPF: user plane function MB-UPF: Multicast/Broadcast-User Plane Function MBSTF: multicast/broadcast service transmission function 300, 400, 500, 600: Communication method 301～305, 401～403, 501～505, 601～604, 701～707, 801～803, 901～908, 1001～1010, 1101～1106, 1201～1215, 1401～1415: Steps 1600:Device 1610: Transceiver unit 1620: Processing unit 1700:Device 1710: Processor 1720: Interface circuit 1730: memory

Figure 1 is a schematic diagram of a network architecture suitable for embodiments of the present application. Figure 2 is a schematic diagram of the network architecture of a multicast/broadcast service. Figure 3 is a schematic flow chart of the communication method 300 provided by this application. Figure 4 is a schematic flow chart of the communication method 400 provided by this application. Figure 5 is a schematic flow chart of the communication method 500 provided by this application. Figure 6 is a schematic flow chart of the communication method 600 provided by this application. Figure 7 is an example of the communication method of the present application. Figure 8 is another example of the communication method of the present application. Figure 9 is another example of the communication method of the present application. Figure 10 is another example of the communication method of the present application. Figure 11 is another example of the communication method of the present application. Figure 12 is another example of the communication method of the present application. Figure 13 is a schematic diagram of transmitting multicast data. Figure 14 is another example of the communication method of the present application. Figure 15 is another schematic diagram of transmitting multicast data. Figure 16 is a schematic structural diagram of a device provided by an embodiment of the present application. Figure 17 is a schematic structural diagram of another device provided by an embodiment of the present application.

300: Communication method

301~305: Steps

Claims (36)

A communication method, characterized in that the method includes: The core network device learns that the terminal has joined the multicast session; The core network device sends first information, the first information is used to notify the refusal to configure extended discontinuous reception eDRX in the inactive state for the terminal, or the first information is used to indicate that the terminal is not applicable to non-continuous reception eDRX. eDRX in active state. The method according to claim 1, characterized in that the core network device sends the first information, including: The core network device sends the first information when at least one of the following conditions is met: the access network device that provides services for the terminal does not support eDRX, the terminal does not support eDRX, or the multicast The session meets preset conditions; Wherein, the preset conditions are: the multicast session is in an active state, the multicast service corresponding to the multicast session does not support eDRX, or the multicast session is in an active state and the multicast service corresponding to the multicast session is in an active state. The broadcast service does not support eDRX. The method according to claim 1 or 2, characterized in that, When the first information is used to notify a refusal to configure eDRX in an inactive state for the terminal, the first information includes rejection information, and the rejection information is used to indicate a refusal to configure eDRX in an inactive state for the terminal. eDRX. The method according to claim 3, characterized in that the method further includes: The core network device receives second information, and the second information is used to request to configure eDRX in an inactive state for the terminal. The method according to claim 3 or 4, characterized in that, The rejection information includes the reason for refusing to configure eDRX in an inactive state for the terminal; Wherein, the reason includes at least one of the following: the terminal has joined a multicast session, the access network device that provides services to the terminal does not support eDRX, the terminal does not support eDRX, or the multicast session satisfies a preset condition; Wherein, the preset conditions are: the multicast session is in an active state, the multicast service corresponding to the multicast session does not support eDRX, or the multicast session is in an active state and the multicast service corresponding to the multicast session is in an active state. The broadcast service does not support eDRX. The method according to any one of claims 2 to 5, characterized in that the method further includes: The core network device receives third information from the access network device, where the third information is used to indicate that the access network device does not support eDRX. The method according to any one of claims 1 to 6, characterized in that, The core network equipment is an access and mobility management function network element or a session management function network element. The method according to claim 7, characterized in that the core network device is an access and mobility management function network element, and the method further includes: The access and mobility management function network element receives service information from the session management function, and the service information is used to indicate that the multicast service corresponding to the multicast session does not support eDRX. The method according to claim 8, characterized in that, The service information includes the type of the multicast service, and the type is a delay-sensitive type. The method according to any one of claims 7 to 9, characterized in that the core network device is an access and mobility management function network element, and the method further includes: The access and mobility management function network element receives fourth information from the session management function network element, and the fourth information is used to indicate that the terminal has joined the multicast session. A communication method, characterized in that the method includes: When the access network device determines to convert the terminal to the inactive state, the access network device sends second information to the core network device, where the second information is used to request that the terminal be configured with an extended inactive state in the inactive state. Continuously receive eDRX; The access network device receives first information from the core network device, where the first information is used to notify a refusal to configure eDRX in an inactive state for the terminal; The access network device does not configure eDRX in an inactive state for the terminal according to the first information. The method according to claim 11, characterized in that, The first information includes rejection information, and the rejection information is used to indicate a refusal to configure eDRX in an inactive state for the terminal. The method according to claim 12, characterized in that, The rejection information includes the reason for refusing to configure eDRX in an inactive state for the terminal; Wherein, the reason includes at least one of the following: the terminal has joined the multicast session, the access network device does not support eDRX, the terminal does not support eDRX, or the multicast session meets preset conditions; Wherein, the preset conditions are: the multicast session is in an active state, the multicast service corresponding to the multicast session does not support eDRX, or the multicast session is in an active state and the multicast service corresponding to the multicast session is in an active state. The broadcast service does not support eDRX. The method according to any one of claims 11 to 13, characterized in that, The core network equipment is an access and mobility management function network element or a session management function network element. A communication method, characterized in that the method includes: The access network device receives first information from the core network device, where the first information is used to indicate that the terminal is not suitable for extended discontinuous reception eDRX in the inactive state; When the access network device determines to convert the terminal to the inactive state, the access network device does not configure eDRX in the inactive state for the terminal according to the first information. The method according to claim 15, characterized in that, The core network equipment is an access and mobility management function network element or a session management function network element. A communication method, characterized in that the method includes: The access and mobility management function network element receives second information from the access network device, where the second information is used to request to configure extended discontinuous reception eDRX in the inactive state for the terminal; The access and mobility management function network element sends the second information to a first session management function network element and a second session management function network element, and the first session management function network element is used to manage the communication with the terminal. The unicast session associated with the multicast session, the second session management function network element is used to manage the unicast session that is not associated with the multicast session of the terminal; The access and mobility management function network element receives first information from the first session management function network element, where the first information is used to notify a refusal to configure eDRX in an inactive state for the terminal; The access and mobility management function network element sends the first information to the access network device, and/or sends fifth information to the second session management function network element, where the fifth information is After triggering the second session management function network element, the network element stops configuring eDRX in an inactive state for the terminal. The method according to claim 17, characterized in that, The first information includes rejection information, and the rejection information is used to indicate a refusal to configure eDRX in an inactive state for the terminal. The method according to claim 18, characterized in that, The rejection information includes the reason for refusing to configure eDRX in an inactive state for the terminal; Wherein, the reason includes at least one of the following: the terminal has joined the multicast session, the access network device does not support eDRX, the terminal does not support eDRX, or the multicast session meets preset conditions; Wherein, the preset conditions are: the multicast session is in an active state, the multicast service corresponding to the multicast session does not support eDRX, or the multicast session is in an active state and the multicast service corresponding to the multicast session is in an active state. The broadcast service does not support eDRX. A communication method, characterized in that the method includes: The access network device learns that the terminal has joined the multicast session; When the access network device determines to convert the terminal to the inactive state, the access network device does not configure extended discontinuous reception eDRX in the inactive state for the terminal. The method according to claim 20, characterized in that the access network device does not configure eDRX for the terminal, including: The access network device does not configure eDRX in the inactive state for the terminal when at least one of the following conditions is met: the access network device does not support eDRX, the terminal does not support eDRX, or the Multicast sessions meet preset conditions; Wherein, the preset conditions are: the multicast session is in an active state, the multicast service corresponding to the multicast session does not support eDRX, or the multicast session is in an active state and the multicast service corresponding to the multicast session is in an active state. The broadcast service does not support eDRX. The method according to claim 21, characterized in that the method further includes: The access network device receives service information from the session management function, where the service information is used to indicate that the multicast service corresponding to the multicast session does not support eDRX. The method according to claim 22, characterized in that, The service information includes the type of the multicast service, and the type is a delay-sensitive type. A communication method, characterized in that the method includes: The terminal learns that the terminal has joined the multicast session and that the terminal supports extended discontinuous reception eDRX; The terminal sends sixth information to the access network device, where the sixth information is used to indicate that the terminal does not support eDRX. The method according to request item 24, characterized in that the terminal sends sixth information to the access network device, including: The terminal sends the sixth information to the access network device when at least one of the following conditions is met: the first information from the core network device is received, the access network device does not support eDRX, the The terminal does not support eDRX, or the multicast session meets preset conditions; Wherein, the first information is used to indicate that the terminal is not suitable for eDRX in an inactive state, and the preset conditions are: the multicast session is in an active state, and the multicast service corresponding to the multicast session does not support eDRX, or the multicast session is in an active state and the multicast service corresponding to the multicast session does not support eDRX. The method according to claim 25, characterized in that the core network device is an access and mobility management function network element or a session management function network element. The method according to claim 25 or 26, characterized in that the method further includes: The terminal receives service information from the session management function, and the service information is used to indicate that the multicast service corresponding to the multicast session does not support eDRX. The method according to claim 27, characterized in that, The service information includes the type of the multicast service, and the type is a delay-sensitive type. The method according to any one of requests 24 to 28, characterized in that, before the terminal sends the sixth information to the access network device, the method further includes: The terminal sends seventh information to the access network device, where the seventh information is used to indicate that the terminal supports eDRX. The method according to any one of claims 24 to 29, characterized in that the method further includes: After the terminal leaves all multicast sessions that the terminal has joined, the terminal sends eighth information to the access network device, where the eighth information is used to indicate that the terminal supports eDRX. A communication device, characterized by including: A processor, configured to execute a computer program stored in the memory, so that the device performs the method as described in any one of claims 1 to 10, or performs the method as described in any one of claims 11 to 14 , or perform the method as described in request items 15 or 16, or perform the method as described in any one of request items 17 to 19, or perform the method as described in any one of request items 20 to 23, or perform A method as claimed in any one of claims 24 to 30. The device according to claim 31, characterized in that the device further includes the memory. A computer-readable storage medium, characterized in that a computer program is stored on the computer-readable storage medium. When the computer program is run on a computer, the computer is caused to execute any one of claims 1 to 10. The described method, or performs the method described in any one of claims 11 to 14, or performs the method described in claim 15 or 16, or performs the method described in any one of claims 17 to 19 Method, or perform the method as described in any one of claims 20 to 23, or perform the method as described in any one of claims 24 to 30. A computer program product, characterized in that the computer program product includes instructions for performing the method described in any one of claims 1 to 10, or includes instructions for performing the method described in any one of claims 11 to 14 Instructions for the method, or instructions for performing the method as described in claim 15 or 16, or instructions for performing the method as described in any one of claims 17 to 19, or including instructions for performing as claimed 20 to 23 or instructions for performing the method as described in any one of claims 24 to 30. A communication system, characterized by comprising: an access network device configured to perform the method described in any one of claims 11 to 16 and 20 to 23. The system according to claim 35, characterized in that when the access network device is used to perform the method according to any one of claims 11 to 16, the communication system also includes a core network device, so The core network equipment is used to perform the method described in any one of claims 1 to 10.

Images