Communication method and related device

Abstract

Provided in the present application are a communication method and a related device, which are used for improving the success rate of a terminal device receiving multicast data, can increase the number of users of a multicast session service, and also can increase the number of multicast session users which can be served by a single cell. The method comprises: on the basis of first information, a first device determining that a first terminal device prefers to receive multicast data in a first state, wherein the first state comprises a radio resource control (RRC) connected state or an RRC inactive state; and the first device sending second information to a network device, wherein the second information is used for indicating that the first terminal device prefers to receive the multicast data in the first state.

Description

A communication method and related equipment

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on August 14, 2023, with application number 202311020987.9 and invention name “A communication method and related equipment”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of communication technology, and in particular to a communication method and related equipment. Background Art

[0003] In a communication system, different communication devices can communicate with each other in various ways, such as broadcast, multicast, or unicast, etc. Multicast refers to a communication technology that sends a copy of data to a specific group of devices.

[0004] Currently, during multicast communication, the provider of multicast data (i.e., the multicast source) can send a single data packet to two or more receivers within a group (or multicast group, multicast group, etc.), thereby improving bandwidth utilization. Generally, a terminal device can act as a receiver within a multicast group and receive multicast data from the multicast source through a network device.

[0005] However, in the multicast communication process, how to improve the success rate of terminal devices receiving multicast data is a technical problem that needs to be solved urgently.

[0006] Summary of the Invention

[0007] The present application provides a communication method and related equipment for improving the success rate of terminal devices in receiving multicast data.

[0008] In a first aspect, the present application provides a communication method, which is executed by a first device, or the method is executed by some components in the first device (such as a processor, a chip or a chip system, etc.), or the method can also be implemented by a logic module or software that can realize all or part of the functions of the first device. In the first aspect and its possible implementation, the method is described as being executed by the first device. In the method, the first device determines, based on first information, that the first terminal device prefers to receive multicast data in a first state; wherein the first state includes a radio resource control (RRC) connected (RRC CONNECTED) state or an RRC inactive (RRC INACTIVE) state; the first device sends a second information to the network device, and the second information is used to indicate that the first terminal device prefers to receive the multicast data in the first state.

[0009] Based on the above solution, after the first device determines that the first terminal device prefers to receive multicast data in the first state based on the first information, the first device sends a second information to the network device to indicate that the first terminal device prefers to receive the multicast data in the first state, and the first state includes an RRC connected state or an RRC inactive state. Among them, since the terminal device may be in different connection states, and in different connection states (such as RRC connected state or RRC inactive state), the terminal device may receive multicast data in different ways. Therefore, reasonably setting the connection state of the terminal device to receive multicast data will be able to increase the number of users that the multicast session can serve, and at the same time, it can increase the number of multicast session users that a single cell can serve. In the above solution, the first device can determine the second information based on the first information and send the second information to the network device. Subsequently, the network device can use the second information as one of the bases for scheduling the first terminal device to receive multicast data, so that the network device can schedule the first terminal device to receive the multicast data in the first state, thereby improving the success rate of the first terminal device receiving multicast data, and can increase the number of users served by the multicast session, and at the same time, can increase the number of multicast session users that a single cell can serve.

[0010] It should be understood that the first device can be a server or logical network element that provides multicast data transmission control (or provides multicast services). For example, the first device can be a server or logical network element with an application function (AF) with multicast broadcast capabilities, an application server (AS), a mission-critical business server (such as a mission-critical push-to-talk server, a mission-critical video server, a mission-critical data server) (specifically, it can be a server that undertakes the participating function in the mission-critical server), a network resource management middleware server, etc.

[0011] It should be understood that in the above solution, the recipient of the second information sent by the first device can be a network device, which can be a network device connected to the first terminal device, or the network device can be a device that provides network services to the first terminal device. For example, the network device can include an access network device and / or a core network device. Taking the example of the network device including an access network device and a core network device (for example), in the process of the first device sending the second information to the network device, the first device can send the second information to the access network device through the core network device, or the first device sends the second information to the core network device, and subsequently in the process of the core network device and the access network device establishing a multicast session for the first terminal device, the core network device sends part or all of the second information to the access network device. For example, the network device can be a unified data management (UDM) or user data repository (UDR) network element in the core network network element. In this case, the first device can also send the second information to the UDM or UDR network element through a network exposure function (NEF) network element.

[0012] In a possible implementation manner of the first aspect, the second information is further used to instruct other terminal devices in the multicast group to which the first terminal device belongs to receive the first multicast data in the first state.

[0013] Based on the above scheme, the second information is also used to indicate that other terminal devices in the multicast group where the first terminal device is located receive the first multicast data in the first state, so that the above scheme can realize the preference setting of the first state for the terminal devices included in the multicast group to receive multicast data to reduce overhead.

[0014] Optionally, the second information is carried in multicast and broadcast service assistance information (MBS assistance information), or other messages / signaling / information, which is not limited here.

[0015] Optionally, in the above scheme, the second information sent by the first device to the network device may be sent at the multicast session granularity (for example, when the second information is carried in the multicast broadcast service auxiliary information), that is, the second information may indicate that the terminal devices in a multicast session prefer to receive the multicast data in the first state, and the terminal devices in the multicast session include the first terminal device, and other terminal devices that may exist. In other words, for different multicast sessions in a multicast broadcast service session list (MBS session list), different multicast sessions may correspond to different multicast broadcast service session identifiers (MBS session IDs). The first device may send different second information to respectively indicate that one or more terminal devices in the multicast sessions corresponding to different multicast broadcast service session identifiers prefer to receive multicast data in the first state.

[0016] Optionally, in the above solution, the second information sent by the first device to the network device may include multiple pieces of information, each of which indicates that terminal devices in different multicast sessions prefer to receive the multicast data in the first state. The terminal devices of one of the different multicast sessions include the first terminal device and any other terminal devices. In other words, for different multicast sessions in a multicast broadcast service session list (MBS session list), the different multicast sessions may correspond to different multicast broadcast service session identifiers (MBS session IDs). The first device may send the second information and, through the multiple pieces of information in the second information, indicate that one or more terminal devices in the multicast sessions corresponding to the different multicast broadcast service session identifiers prefer to receive the multicast data in the first state. In addition, when the network device includes a core network device and an access network device, after the first device sends the second information containing the multiple pieces of information to the core network device, the core network device may send the portions of the multiple pieces of information corresponding to several multicast sessions to the access network device, or the core network device may send all of the multiple pieces of information to the access network device, without limitation herein.

[0017] It should be noted that, in different connection states, the terminal device may process the multicast data received in different ways. For example, when the first terminal device is in the RRC connected state, when the first terminal device receives multicast data from the channel indicated by the multicast multicast radio bearer configuration, it can provide hybrid automatic repeat qequest (HARQ) feedback. If data packet loss occurs, the access network device can perform point-to-point (PTP) retransmission. When the first terminal device is in the RRC inactive state, when the first terminal device receives multicast data from the channel indicated by the multicast multicast radio bearer configuration, the first terminal device may not send HARQ feedback. If data packet loss occurs, it will be handled by the upper layer. Generally speaking, compared with the terminal device in the RRC inactive state, the terminal device in the RRC connected state may have better reception quality and a higher reception success rate.

[0018] In a possible implementation of the first aspect, the first information includes at least one of the following:

[0019] Capability information of the first terminal device, where the capability information indicates that the first terminal device supports receiving multicast data in the RRC inactive state;

[0020] Preference information of the first terminal device, where the preference information indicates that the first terminal device prefers to receive multicast data in the first state;

[0021] The multicast role of the first terminal device in the group corresponding to the multicast data;

[0022] the location of the first terminal device;

[0023] the number of multicast groups that the first terminal device participates in (joined);

[0024] The number of multicast sessions that the first terminal device has joined;

[0025] Reception quality information of the first terminal device for a first multicast session, where the first multicast session is used to transmit the multicast data;

[0026] The service communication model of the first terminal device; and

[0027] One or more speaking right request messages from the first terminal device.

[0028] Based on the above scheme, the first information serves as one of the bases for the first device to determine that the first terminal device prefers to receive multicast data in the first state. The first information can be implemented through a combination of one or more of the above to enhance the flexibility of the scheme implementation.

[0029] In addition, since the combination of one or more of the above items can reflect the actual service situation of the first terminal device to a certain extent, the first state of the first terminal device receiving multicast data can be set more accurately based on the combination of one or more items, avoiding setting unreasonable / unnecessary terminal devices to receive in the RRC connection state, which can save transmission resources to improve communication efficiency. Moreover, after such a setting, system resources can be more fully utilized, thereby improving the overall service experience and the user experience of a single terminal device (such as the first terminal device).

[0030] In a possible implementation of the first aspect, the first information includes capability information of the first terminal device, and the first device determines, based on the first information, that the first terminal device prefers to receive multicast data in the first state, including: when the capability information indicates that the first terminal device supports receiving multicast data in the RRC inactive state, the first device determines that the first terminal device prefers to receive the multicast data in the RRC inactive state; or, when the capability information indicates that the first terminal device does not support receiving multicast data in the RRC inactive state, determines that the first terminal device prefers to receive the multicast data under the RRC connection.

[0031] Based on the above scheme, the first information serves as one of the bases for the first device to determine that the first terminal device prefers to receive multicast data in the first state. When the first information includes the capability information of the first terminal device, the first device can determine, based on the capability information, that the first terminal device prefers to receive the multicast data in the RRC inactive state, so that the first state indicated by the second information sent by the first device can be adapted to the capability of the first terminal device, thereby enabling the subsequent first terminal device to receive multicast data in the first state supported by the capability of the first terminal device.

[0032] In a possible implementation of the first aspect, the first information includes preference information of the first terminal device, and the first device determines, based on the first information, that the first terminal device prefers to receive multicast data in the first state, including: when the preference information indicates that the first terminal device prefers to receive multicast data in an RRC connected state, the first device determines that the first terminal device prefers to receive the multicast data in the RRC connected state; or, when the preference information indicates that the first terminal device prefers to receive multicast data in an RRC inactive state, determines that the first terminal device prefers to receive the multicast data in the RRC inactive state.

[0033] Based on the above scheme, the first information serves as one of the bases for the first device to determine that the first terminal device prefers to receive multicast data in the first state. When the first information includes the preference information of the first terminal device, the first device can determine, based on the preference information, that the first terminal device prefers to receive the multicast data in the RRC connected state or the RRC inactive state, so that the first state indicated by the second information sent by the first device can be adapted to the preference of the first terminal device, thereby enabling the subsequent first terminal device to receive multicast data in the first state that satisfies the preference of the first terminal device.

[0034] In a possible implementation of the first aspect, the first information includes the service communication model of the first terminal device, and the first device determines, based on the first information, that the first terminal device prefers to receive multicast data in the first state, including: when the service communication model of the first terminal device indicates frequent uplink, the first device determines that the first terminal device prefers to receive the multicast data in the RRC connected state; or, when the service communication model of the first terminal device indicates only downlink, the first device determines that the first terminal device prefers to receive the multicast data in the RRC inactive state.

[0035] Based on the above scheme, the first information is used as one of the bases for the first device to determine that the first terminal device prefers to receive multicast data in the first state. When the first information includes the service communication model of the first terminal device, when the service communication model indicates frequent uplink, large uplink data transmission volume / high transmission frequency, or large downlink data transmission volume / high transmission frequency, since the terminal device may be able to send uplink data through frequent RRC connection recovery requests in the RRC inactive state, the first device can determine that the first terminal device prefers to receive the multicast data in the RRC connection state to reduce the power consumption and implementation complexity of the first terminal device. When the service communication model indicates only downlink or only uplink, since the terminal device can still receive only downlink data in the RRC inactive state, the first device can determine that the first terminal device prefers to receive the multicast data in the RRC inactive state to reduce the power consumption of the first terminal device.

[0036] In a possible implementation of the first aspect, the first information includes one or more right-of-speech request messages from the first terminal device, and the first device determines, based on the first information, that the first terminal device prefers to receive multicast data in the first state, including: when the total amount of the one or more right-of-speech request messages exceeds a first threshold and / or the frequency of the one or more right-of-speech request messages exceeds a second threshold, the first device determines that the first terminal device prefers to receive the multicast data in the RRC connection state.

[0037] Based on the above scheme, the first information serves as one of the bases for the first device to determine that the first terminal device prefers to receive multicast data in the first state. When the first information includes one or more right-of-voice request messages from the first terminal device, when the total amount of one or more right-of-voice request messages exceeds a first threshold and / or the frequency of the one or more right-of-voice request messages exceeds a second threshold, the first terminal device may have a larger uplink transmission demand. For this reason, the first device can determine that the first terminal device prefers to receive the multicast data in the RRC connection state to meet the larger uplink transmission demand of the first terminal device and reduce the power consumption and implementation complexity of the first terminal device.

[0038] In a possible implementation manner of the first aspect, the first information further includes priority information corresponding to the at least one item.

[0039] Based on the above scheme, the first information may also include priority information corresponding to at least one of the above items, that is, the priority information indicates the priority of the at least one of the above items, so that when the first information includes two or more of the at least one of the above items, the first device can select one of them as the basis for determination according to the priority information to avoid behavioral confusion caused by contradictions between the two or more items, so that the first device can determine that the first terminal device prefers to receive multicast data in the first state based on the priority indicated by the priority information.

[0040] Optionally, the priority information is preconfigured / predefined, or the priority information comes from other devices (such as core network devices, servers, etc.), which is not limited here.

[0041] In a possible implementation manner of the first aspect, the multicast data is multicast data of a first multicast session.

[0042] Based on the above scheme, the multicast data of the first terminal device can be the multicast data of a certain multicast session (for example, the first multicast session), so that the first device can set the first state of the terminal device receiving multicast data according to the granularity of the multicast session to improve the success rate of the terminal device receiving multicast data in the first multicast session.

[0043] In a possible implementation manner of the first aspect, the capability information and the preference information come from a mission critical service client (MC service client), and the MC service client is deployed on the first terminal device.

[0044] Based on the above scheme, when the capability information and preference information in the first information come from the first terminal device, the capability information and the preference information can come from the MC service client in the first terminal device. Accordingly, the first device can receive the capability information and preference information from the MC service client through the mission critical service server (MC service server), so that the above scheme can be adapted to the communication scenario between the MC service client and the MC service server.

[0045] In a possible implementation of the first aspect, the method also includes: the first device receives a first message from the MC service client, the first message carrying the capability information and / or the preference information; wherein the first message is a critical business service registration message, an emergency business service registration request message, a user equipment (UE) session join notification message, or a multicast broadcast service session monitoring status report message.

[0046] Based on the above scheme, when the capability information and the preference information can come from the MC service client in the first terminal device, the first device can obtain the capability information and / or the preference information through a first message, and the first message can be implemented through any of the above items to enhance the flexibility of the scheme implementation.

[0047] In a possible implementation of the first aspect, the capability information and / or the preference information comes from a network resource management client (NRM client), a vertical application server (VAS), or a group management server (GMS), and the NRM client is deployed on the first terminal device.

[0048] Based on the above solution, the capability information and / or the preference information received by the first device may come from the NRM client, VAS or GMS deployed on the first terminal device, so as to provide the first device with multiple implementation methods for obtaining the capability information and / or the preference information.

[0049] In a possible implementation of the first aspect, the method also includes: the first device receives a second message from the NRM client, the second message carries the capability information and / or the preference information, wherein the second message is an NRM registration request message, an emergency service registration request message, a UE session join notification message, or a multicast broadcast service session listening status report message.

[0050] Based on the above scheme, when the capability information and the preference information can come from the NRM client in the first terminal device, the first device can obtain the capability information and / or the preference information through a second message, and the second message can be implemented through any of the above items to enhance the flexibility of the scheme implementation.

[0051] In a possible implementation of the first aspect, the multicast data is multicast data of a first multicast session, and the first device sending the second information to the network device includes: when at least one of the following conditions is met, the first device sending the second information to the network device includes:

[0052] The session identifier of the first multicast session has been determined, but the first multicast session has not been created;

[0053] The first multicast session has been created, and the first terminal device has not yet joined the first multicast session;

[0054] The first multicast session has been created, and the first terminal device has joined the first multicast session;

[0055] The first multicast session has been created, the first terminal device has joined the first multicast session, and the association between the first multicast session and the group has been sent to the first terminal device.

[0056] Based on the above solution, the multicast data of the first terminal device can be the multicast data of a certain multicast session (for example, the first multicast session), and the first device can trigger the sending of the second information based on various situations of the first multicast session to improve the flexibility of the solution implementation.

[0057] Optionally, for the first device, when the first device receives a session identifier of a first multicast session from a network device (e.g., a core network device), the first device determines the session identifier of the first multicast session. The session identifier may be a multicast broadcast service session identifier (MBS session ID) or other names, which are not limited here. Exemplarily, the receiving process may be a step in the MBS session ID allocation process performed by the first device and the core network device in interaction, wherein the first device sends an MBS session ID request to the core network device, the core network device allocates an MBS session ID and returns the MBS session ID to the first device, so that the first device can determine the MBS session ID of the first multicast session.

[0058] Optionally, after the first device sends a response message indicating successful session establishment of the first multicast session to a network device (e.g., a core network device), the first device determines that the first multicast session has been established. The response message may be a response message indicating successful establishment of a multicast broadcast service auxiliary information (MBS) session. Accordingly, before the first device sends the response message, it may be determined that the first multicast session has not been established.

[0059] Optionally, for the first device, when the first device receives indication information from a network device (e.g., a core network device), the first device may determine that the first terminal device has joined the first multicast session, where the indication information is used to indicate that the first terminal device and the network device have executed the MBS session joining process. Accordingly, before the first device receives the indication information, the first device may determine that the first terminal device has not yet joined the first multicast session.

[0060] The second aspect of the present application provides a communication method, which is executed by a terminal device, or the method is executed by some components in the terminal device (such as a processor, chip or chip system, etc.), or the method can also be implemented by a logic module or software that can realize all or part of the terminal device functions. In the second aspect and its possible implementation, the method is described as being executed by a first terminal device. In this method, the terminal device determines capability information and / or preference information; wherein, the capability information indicates that the first terminal device supports receiving multicast data in a first state, and the preference information indicates that the first terminal device prefers to receive multicast data in the first state; wherein, the first state includes an RRC connected state or an RRC inactive state; the terminal device sends the capability information and / or the preference information.

[0061] Based on the above scheme, the capability information sent by the first terminal device is used to indicate that the first terminal device supports receiving multicast data in the first state, and / or the preference information sent by the first terminal device is used to indicate that the first terminal device prefers to receive multicast data in the first state. Thereafter, the recipient of the capability information and / or preference information (e.g., the first device) can send second information to the network device based on the capability information and / or preference information to indicate that the first terminal device prefers to receive the multicast data in the first state, and the first state includes an RRC connected state or an RRC inactive state. In particular, since the terminal device may be in different connection states, and in different connection states (e.g., an RRC connected state or an RRC inactive state), the terminal device may have different ways of receiving multicast data. Therefore, reasonably setting the connection state of the terminal device to receive multicast data will be able to increase the number of users served by the multicast session, and at the same time, it can increase the number of multicast session users that can be served by a single cell. In the above scheme, the first device can determine the second information based on the capability information and / or preference information sent by the first terminal device, and send the second information to the network device. Subsequently, the network device can use the second information as one of the bases for scheduling the first terminal device to receive multicast data, so that the network device can schedule the first terminal device to receive the multicast data in the first state, thereby improving the success rate of the first terminal device in receiving multicast data.

[0062] In a possible implementation of the second aspect, the capability information and / or the preference information is carried in a critical business service registration message, an emergency business service registration request message, a UE session join notification message, or a multicast broadcast service session monitoring status report message.

[0063] Based on the above solution, the capability information and / or the preference information sent by the first terminal device can be carried in any of the above messages to enhance the flexibility of the solution implementation.

[0064] The third aspect of the present application provides a communication method, which is executed by a network device, or the method is executed by some components in the network device (such as a processor, chip or chip system, etc.), or the method can also be implemented by a logic module or software that can realize all or part of the network device functions. In the first aspect and its possible implementation, the method is described as being executed by a network device. In this method, the network device receives second information, and the second information is used to indicate that the first terminal device prefers to receive multicast data in a first state; wherein the first state includes a radio resource control RRC connected state or an RRC inactive state; the network device sends the multicast data to the first terminal device according to the second information.

[0065] Based on the above scheme, the second information received by the network device is used to indicate that the first terminal device prefers to receive multicast data in the first state. Thereafter, the network device can send the multicast data to the first terminal device according to the second information. The first state includes an RRC connected state or an RRC inactive state. In particular, since the terminal device may be in different connection states, and in different connection states (such as an RRC connected state or an RRC inactive state), the terminal device may receive multicast data in different ways. Therefore, reasonably setting the connection state of the terminal device to receive multicast data will be able to increase the number of users served by the multicast session, and at the same time, it can increase the number of multicast session users that can be served by a single cell. In the above scheme, after the network device receives the second information, the network device can use the second information as one of the bases for scheduling the first terminal device to receive multicast data, so that the network device can schedule the first terminal device to receive the multicast data in the first state, thereby improving the success rate of the first terminal device receiving multicast data.

[0066] In a fourth aspect of the present application, a communication device is provided, which is a first device, or a component of the first device (such as a processor, chip, or chip system), or a logic module or software capable of implementing all or part of the functions of the first device. In the seventh aspect and its possible implementations, the communication device is described as a first device, and the first device can be a terminal device or a network device.

[0067] The device includes a processing unit and a transceiver unit; the processing unit is used to determine, based on first information, that the first terminal device prefers to receive multicast data in a first state; wherein the first state includes a radio resource control RRC connected state or an RRC inactive state; the transceiver unit is used to send second information to the network device, and the second information is used to indicate that the first terminal device prefers to receive the multicast data in the first state.

[0068] In a possible implementation of the fourth aspect, the first information includes at least one of the following:

[0069] Capability information of the first terminal device, where the capability information indicates that the first terminal device supports receiving multicast data in the RRC inactive state;

[0070] Preference information of the first terminal device, where the preference information indicates that the first terminal device prefers to receive multicast data in the first state;

[0071] The multicast role of the first terminal device in the group corresponding to the multicast data;

[0072] the location of the first terminal device;

[0073] The number of multicast groups in which the first terminal device participates;

[0074] The number of multicast sessions that the first terminal device has joined;

[0075] Reception quality information of the first terminal device for a first multicast session, where the first multicast session is used to transmit the multicast data;

[0076] The service communication model of the first terminal device; and

[0077] One or more speaking right request messages from the first terminal device.

[0078] In a possible implementation of the fourth aspect, the first information includes capability information of the first terminal device, and the processing unit determines, based on the first information, that the first terminal device prefers to receive multicast data in the first state, including: when the capability information indicates that the first terminal device supports receiving multicast data in the RRC inactive state, the processing unit determines that the first terminal device prefers to receive the multicast data in the RRC inactive state; or, when the capability information indicates that the first terminal device does not support receiving multicast data in the RRC inactive state, the processing unit determines that the first terminal device prefers to receive the multicast data under the RRC connection.

[0079] In a possible implementation of the fourth aspect, the first information includes preference information of the first terminal device, and the processing unit determines, based on the first information, that the first terminal device prefers to receive multicast data in the first state, including: when the preference information indicates that the first terminal device prefers to receive multicast data in an RRC connected state, the processing unit determines that the first terminal device prefers to receive the multicast data in the RRC connected state; or, when the preference information indicates that the first terminal device prefers to receive multicast data in an RRC inactive state, the processing unit determines that the first terminal device prefers to receive the multicast data in the RRC inactive state.

[0080] In a possible implementation of the fourth aspect, the first information includes the service communication model of the first terminal device, and the processing unit determines, based on the first information, that the first terminal device prefers to receive multicast data in the first state, including: when the service communication model of the first terminal device indicates frequent uplink, the processing unit determines that the first terminal device prefers to receive the multicast data in the RRC connected state; or, when the service communication model of the first terminal device indicates only downlink, the first device determines that the first terminal device prefers to receive the multicast data in the RRC inactive state.

[0081] In a possible implementation of the fourth aspect, the first information includes one or more right-of-speech request messages from the first terminal device, and the processing unit determines, based on the first information, that the first terminal device prefers to receive multicast data in the first state, including: when the total amount of the one or more right-of-speech request messages exceeds a first threshold and / or the frequency of the one or more right-of-speech request messages exceeds a second threshold, the processing unit determines that the first terminal device prefers to receive the multicast data in the RRC connection state.

[0082] In a possible implementation manner of the fourth aspect, the multicast data is multicast data of a first multicast session.

[0083] In a possible implementation manner of the fourth aspect, the capability information and the preference information come from a mission-critical service client MC service client, and the MC service client is deployed on the first terminal device.

[0084] In a possible implementation of the fourth aspect, the transceiver unit is also used to receive a first message from the MC service client, which carries the capability information and / or the preference information; wherein the first message is a critical business service registration message, an emergency business service registration request message, a UE session join notification message, or a multicast broadcast service session monitoring status report message.

[0085] In a possible implementation manner of the fourth aspect, the capability information and / or the preference information comes from a network resource management client NRM client, VAS, or GMS, and the NRM client is deployed on the first terminal device.

[0086] In a possible implementation of the fourth aspect, the transceiver unit is also used to receive a second message from the NRM client, the second message carrying the capability information and / or the preference information, wherein the second message is an NRM registration request message, an emergency service registration request message, a UE session join notification message, or a multicast broadcast service session listening status report message.

[0087] In a possible implementation of the fourth aspect, the multicast data is multicast data of the first multicast session, and the transceiver unit is configured to send the second information to the network device, including: when at least one of the following is satisfied, the transceiver unit is configured to send the second information to the network device, including:

[0088] The session identifier of the first multicast session has been determined, but the first multicast session has not been created;

[0089] The first multicast session has been created, and the first terminal device has not yet joined the first multicast session;

[0090] The first multicast session has been created, and the first terminal device has joined the first multicast session;

[0091] The first multicast session has been created, the first terminal device has joined the first multicast session, and the association between the first multicast session and the group has been sent to the first terminal device.

[0092] In a possible implementation manner of the fourth aspect, the second information is further used to instruct other terminal devices in the multicast group to which the first terminal device belongs to receive the first multicast data in the first state.

[0093] In a possible implementation manner of the fourth aspect, the second information is carried in multicast broadcast service assistance information MBS assistance information.

[0094] In the fourth aspect of the present application, the constituent modules of the communication device can also be used to execute the steps performed in each possible implementation method of the first aspect and achieve corresponding technical effects. For details, please refer to the first aspect and will not be repeated here.

[0095] In a fifth aspect, the present application provides a communication device, which is a terminal device, or a component of a terminal device (such as a processor, chip, or chip system), or a logic module or software capable of implementing all or part of the terminal device functions. In the fifth aspect and its possible implementations, the communication device is described as an example of a terminal device.

[0096] The device includes a processing unit and a transceiver unit; the processing unit is used to determine capability information and / or preference information; wherein, the capability information indicates that the first terminal device supports receiving multicast data in a first state, and the preference information is used to indicate that the first terminal device prefers to receive multicast data in the first state; wherein, the first state includes a radio resource control RRC connected state or an RRC inactive state; the transceiver unit is used to send the capability information and / or the preference information.

[0097] In a possible implementation of the fifth aspect, the capability information and / or the preference information is carried in a critical business service registration message, an emergency business service registration request message, a UE session join notification message, or a multicast broadcast service session monitoring status report message.

[0098] In the fifth aspect of this application, the constituent modules of the communication device can also be used to execute the steps performed in each possible implementation method of the second aspect and achieve corresponding technical effects. For details, please refer to the second aspect and will not be repeated here.

[0099] In a sixth aspect, the present application provides a communication device, which is a network device, or a component of a network device (such as a processor, chip, or chip system), or a logic module or software capable of implementing all or part of the network device functions. In the sixth aspect and its possible implementations, the communication device is described as a network device.

[0100] The device includes a processing unit and a transceiver unit; the transceiver unit is used to receive second information; the processing unit is used to determine, based on the second information, that the first terminal device prefers to receive multicast data in a first state; wherein the first state includes a radio resource control RRC connected state or an RRC inactive state; the transceiver unit is also used to send the multicast data to the first terminal device according to the second information.

[0101] In the sixth aspect of this application, the constituent modules of the communication device can also be used to execute the steps performed in each possible implementation method of the third aspect and achieve corresponding technical effects. For details, please refer to the third aspect and will not be repeated here.

[0102] A seventh aspect of an embodiment of the present application provides a communication device, comprising at least one processor, which is used to execute programs or instructions in a memory so that the device implements the method described in the first aspect or any possible implementation method of the first aspect.

[0103] In an eighth aspect, an embodiment of the present application provides a communication device, comprising at least one processor, which is used to execute programs or instructions in a memory so that the device implements the method described in the second aspect or any possible implementation method of the second aspect.

[0104] A ninth aspect of an embodiment of the present application provides a communication device, comprising at least one processor, which is used to execute programs or instructions in a memory so that the device implements the method described in the third aspect or any possible implementation method of the third aspect.

[0105] In a tenth aspect, an embodiment of the present application provides a communication device, comprising at least one logic circuit and an input / output interface; the logic circuit is used to execute the method described in the first aspect or any possible implementation of the first aspect.

[0106] In an eleventh aspect of an embodiment of the present application, a communication device is provided, comprising at least one logic circuit and an input / output interface; the logic circuit is used to execute the method described in the second aspect or any possible implementation of the second aspect.

[0107] A twelfth aspect of an embodiment of the present application provides a communication device, comprising at least one logic circuit and an input / output interface; the logic circuit is used to execute the method described in the third aspect or any possible implementation of the third aspect.

[0108] A thirteenth aspect of an embodiment of the present application provides a computer-readable storage medium, which is used to store one or more computer-executable instructions. When the computer-executable instructions are executed by a processor, the processor executes the method described in any possible implementation of any one of the first to third aspects above.

[0109] A fourteenth aspect of an embodiment of the present application provides a computer program product (or computer program). When the computer program product is executed by the processor, the processor executes the method described in any possible implementation of any one of the first to third aspects above.

[0110] A fifteenth aspect of an embodiment of the present application provides a chip system, which includes at least one processor for supporting a communication device to implement the functions involved in any possible implementation method of any aspect of the first to third aspects above.

[0111] In one possible design, the chip system may further include a memory for storing program instructions and data necessary for the first communication device. The chip system may be composed of a chip or may include a chip and other discrete components. Optionally, the chip system may further include an interface circuit for providing program instructions and / or data to the at least one processor.

[0112] A sixteenth aspect of an embodiment of the present application provides a communication system, which includes the communication device of the fourth aspect, the communication device of the fifth aspect, and the communication device of the sixth aspect; or, the communication system includes the communication device of the seventh aspect, the communication device of the eighth aspect, and the communication device of the ninth aspect; or, the communication system includes the communication device of the tenth aspect, the communication device of the eleventh aspect, and the communication device of the twelfth aspect.

[0113] Among them, the technical effects brought about by any design method in the fourth to sixteenth aspects can refer to the technical effects brought about by the different design methods in the above-mentioned first to third aspects, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0114] FIG1 is a schematic diagram of a communication system involved in this application;

[0115] FIG2 is another schematic diagram of the communication system involved in this application;

[0116] FIG3 is another schematic diagram of the communication system involved in this application;

[0117] FIG4a is a schematic diagram of the multicast communication process involved in this application;

[0118] FIG4 b is another schematic diagram of the multicast communication process involved in this application;

[0119] FIG4c is another schematic diagram of the multicast communication process involved in this application;

[0120] FIG5 is another schematic diagram of the multicast communication process involved in this application;

[0121] FIG6a is another schematic diagram of the multicast communication process involved in this application;

[0122] FIG6 b is another schematic diagram of the multicast communication process involved in this application;

[0123] FIG6c is another schematic diagram of the multicast communication process involved in this application;

[0124] FIG7 is a schematic diagram of a communication method provided by the present application;

[0125] FIG8 is another schematic diagram of the communication method provided by the present application;

[0126] FIG9 is another schematic diagram of the communication method provided by the present application;

[0127] FIG10 is a schematic diagram of a communication device provided by the present application;

[0128] FIG11 is another schematic diagram of a communication device provided by the present application;

[0129] FIG12 is another schematic diagram of the communication device provided in this application. DETAILED DESCRIPTION

[0130] First, some of the terms used in the embodiments of the present application are explained to facilitate understanding by those skilled in the art.

[0131] (1) Terminal device: It can be a wireless terminal device that can receive network device scheduling and instruction information. The wireless terminal device can be a device that provides voice and / or data connectivity to the user, or a handheld device with wireless connection function, or other processing device connected to a wireless modem.

[0132] Terminal devices can communicate with one or more core networks or the Internet via a radio access network (RAN). Terminal devices can be mobile terminal devices, such as mobile phones (also known as "cellular" phones, mobile phones), computers, and data cards. For example, they can be portable, pocket-sized, handheld, computer-built-in, or vehicle-mounted mobile devices that exchange voice and / or data with the radio access network. Examples include personal communication service (PCS) phones, cordless phones, Session Initiation Protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), tablet computers, and computers with wireless transceiver capabilities. A wireless terminal device may also be referred to as a system, a subscriber unit, a subscriber station, a mobile station, a mobile station (MS), a remote station, an access point (AP), a remote terminal, an access terminal, a user terminal, a user agent, a subscriber station (SS), a customer premises equipment (CPE), a terminal, a user equipment (UE), a mobile terminal (MT), an unmanned aerial vehicle (UAV), etc. A terminal device may also be a wearable device or a next-generation communication system, for example, a terminal device in a 5G communication system or a terminal device in a future-evolved public land mobile network (PLMN).

[0133] (2) Network equipment: This may include access network equipment, core network equipment, etc. in the communication network.

[0134] In one implementation example, the access network device in the network device may be a radio access network (RAN) node (or device) that connects a terminal device to a wireless network, also known as a base station. Currently, some examples of RAN devices include: a new generation Node B (gNodeB) in a 5G communication system, a transmission reception point (TRP), an evolved Node B (eNB), a radio network controller (RNC), a Node B (NB), a base station controller (BSC), a base transceiver station (BTS), a home base station (e.g., a home evolved Node B, or HNB), a baseband unit (BBU), or a wireless fidelity (Wi-Fi) access point (AP). Additionally, in one network architecture, the access network device may include a centralized unit (CU) node, a distributed unit (DU) node, or a RAN device comprising both a CU node and a DU node. In some implementations, the access network equipment may also include satellites, aircraft, drones, and ground station equipment connected to the satellites, aircraft, and drones.

[0135] Among them, the access network device can send configuration information to the terminal device (for example, carried in a scheduling message and / or an indication message), and the terminal device further performs network configuration based on the configuration information, so that the network configurations between the access network device and the terminal device are aligned; or, through the network configuration preset in the access network device and the network configuration preset in the terminal device, the network configurations between the access network device and the terminal device are aligned. Specifically, "alignment" means that when there are interactive messages between the network device and the terminal device, the two have a consistent understanding of the carrier frequency for sending and receiving interactive messages, the determination of the interactive message type, the meaning of the field information carried in the interactive message, or other configurations of the interactive message.

[0136] In addition, in other possible cases, the access network device may be other devices that provide wireless communication functions for the terminal device. The embodiments of this application do not limit the specific technology and specific device form used by the network device. For the convenience of description, the embodiments of this application are not limited.

[0137] In one implementation example, a core network device may be a physical or logical network element included in the core network (CN) portion of a mobile communication system. Generally, a core network device can connect terminal devices to different data networks and perform services such as billing, mobility management, session management, and user plane forwarding. In mobile communication systems of different standards, the names of core network devices with the same functionality may differ.

[0138] In the embodiments of the present application, the apparatus for implementing the function of the network device may be the network device, or may be a device capable of supporting the network device to implement the function, such as a chip system, which may be installed in the network device. In the solutions provided in the embodiments of the present application, the solutions provided in the embodiments of the present application are described by taking the apparatus for implementing the function of the network device as an example.

[0139] (3) Configuration and pre-configuration: In this application, configuration and pre-configuration are used simultaneously. Configuration refers to the network device sending some parameter configuration information or parameter values ​​to the terminal device through messages or signaling, so that the terminal device can determine the communication parameters or resources during transmission based on these values ​​or information. Pre-configuration is similar to configuration and can be parameter information or parameter values ​​pre-negotiated between the network device and the terminal device, parameter information or parameter values ​​used by the network device or terminal device as specified by the standard protocol, or parameter information or parameter values ​​pre-stored in the network device or terminal device. This application does not limit this.

[0140] Furthermore, these values ​​and parameters can be changed or updated.

[0141] (4) The terms "system" and "network" in the embodiments of the present application can be used interchangeably. "At least one" means one or more, and "more" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, "at least one of A, B and C" includes A, B, C, AB, AC, BC or ABC. In addition, unless otherwise specified, the ordinal numbers such as "first" and "second" mentioned in the embodiments of the present application are used to distinguish multiple objects, and are not used to limit the order, timing, priority or importance of multiple objects.

[0142] The present application can be applied to a long term evolution (LTE) system, a new radio (NR) system, or other communication systems, wherein the communication system includes a network device and a terminal device, the network device serves as a configuration information sending entity, and the terminal device serves as a configuration information receiving entity. Specifically, in the communication system, there is an entity that sends configuration information to another entity, and sends data to another entity, or receives data sent by another entity; another entity receives the configuration information, and sends data to the configuration information sending entity according to the configuration information, or receives data sent by the configuration information sending entity. Among them, the present application can be applied to a terminal device in a connected state or an active state (ACTIVE), and can also be applied to a terminal device that enters a non-connected state (INACTIVE) or an idle state (IDLE).

[0143] In this application, unless otherwise specified, the same or similar parts between the various embodiments can refer to each other. In the various embodiments in this application, and the various implementation methods / implementation methods / implementation methods in each embodiment, if there is no special explanation and logical conflict, the terms and / or descriptions between different embodiments and the various implementation methods / implementation methods / implementation methods in each embodiment are consistent and can be referenced to each other. The technical features in different embodiments and the various implementation methods / implementation methods / implementation methods in each embodiment can be combined to form new embodiments, implementation methods, implementation methods, or implementation methods according to their inherent logical relationships. The implementation methods of this application described below do not constitute a limitation on the scope of protection of this application.

[0144] To facilitate understanding of the method provided in the embodiments of the present application, the system architecture of the method provided in the embodiments of the present application is described below. It is understandable that the system architecture described in the embodiments of the present application is for the purpose of more clearly illustrating the solution of the embodiments of the present application and does not constitute a limitation on the solution provided in the embodiments of the present application.

[0145] Please refer to Figure 1, which is a schematic diagram of a communication system provided in an embodiment of the present application. As shown in Figure 1, the configuration information sending entity may be a network device, wherein the configuration information receiving entity may be UE1-UE6. In this case, the network device and UE1-UE6 constitute a communication system. In this communication system, UE1-UE6 can send uplink data to the network device, and the network device can receive uplink data sent by UE1-UE6. At the same time, the network device can send configuration information to UE1-UE6.

[0146] Please refer to Figure 2, which is another schematic diagram of a communication system provided in an embodiment of the present application. As shown in Figure 2, the communication system includes a terminal device 100, an access network device 201, and a core network device 202. The terminal device 100 and the access network device 201 can communicate via a wireless link. The access network device 201 and the core network device 202 can communicate with each other. In other words, the terminal device 100 can communicate with the access network device 201 and / or the core network device 202.

[0147] As an implementation example of the communication system shown in Figure 2, the communication system can be a 5G network system. As shown in Figure 3, the terminal device 100 in Figure 2 may include the UE 301 in Figure 3, the access network device 201 in Figure 2 may include the RAN 302 in Figure 3, and the core network device 202 in Figure 2 may include the following one or more logical network elements in Figure 3: user plane function (UPF) network element 303, data network (DN) 304, access and mobility management function (AMF) network element 305, session management function (SMF) network element 306, policy control function (PCF) network element 307, UDM network element 308, and AF network element 309.

[0148] The devices or network elements involved in FIG3 are introduced below respectively.

[0149] UPF303 is mainly responsible for processing user messages, such as forwarding and billing.

[0150] DN 304 refers to a network that provides data transmission services to users, such as Internet protocol multimedia service (IMS), the Internet, etc. In addition, there can be one or more application servers in the DN.

[0151] AMF305 is mainly responsible for mobility management in the mobile network, such as user location update, user network registration, user switching, etc.

[0152] The SMF 306 is responsible for session management in the mobile network, such as session establishment, modification, and release. Specific functions include allocating IP addresses to users and selecting the UPF that provides packet forwarding functions.

[0153] PCF307 is responsible for providing policies to AMF and SMF, such as QoS policy and slice selection policy.

[0154] UDM308 is used to store user data, such as contract information, authentication or authorization information.

[0155] AF309 is responsible for providing services to the 3GPP network, such as influencing service routing and interacting with the PCF for policy control.

[0156] For example, in FIG3 , UE 301 may establish a session (eg, a protocol data unit session (PDU session)) from UE 301 to RAN 302 to UPF 303 to DN 304 and access DN 304 through the session.

[0157] In a communication system (such as the communication system shown in Figures 1, 2, or 3), different communication devices can communicate with each other through various methods, such as broadcast, multicast, or unicast. Currently, during multicast communication, the provider of multicast data (i.e., the multicast source) can send a single data packet to two or more receivers within a multicast group (or multicast group), thereby improving bandwidth utilization. Generally, a terminal device can act as a receiver within a multicast group and receive multicast data from the multicast source through network equipment.

[0158] The following will take the 5G communication system as an example to exemplify the multicast process that may be involved in this application.

[0159] As shown in Figure 4a, compared to the network architecture shown in Figure 3, the multicast process may involve other network elements, including the network repository function (NRF), the multicast and broadcast session management function (MB-SMF, also referred to as M-SMF), the multicast and broadcast user plane function (MB-UPF, also referred to as M-UPF), the multicast and broadcast service function (MBSF), and the multicast and broadcast service transport function (MBSTF). The interfaces between the different network elements are shown in Figure 4a.

[0160] As an implementation example, the multicast or broadcast-specific functions of each network element in Figure 4a are as follows:

[0161] PCF: PCF is an optional network element. This functional entity is required when dynamic policy charging control (PCC) is used. Specifically, PCF is responsible for: processing the quality of service (QoS) of the multicast and broadcast service session (MBS session); providing policy information to the MB-SMF; and interacting with the UDR to obtain QoS information.

[0162] MB-SMF: An entity that supports broadcast features and can also perform the functions of a unicast SMF. Specifically, the MB-SMF is responsible for: MBS session management, including QoS control; configuring the MB-UPF; interacting with the RAN to control broadcast flow transmission (broadcast session-specific function); interacting with the SMF to associate PDU sessions; and interacting with the RAN to control multicast flow transmission (multicast session-specific function).

[0163] SMF: To support 5G MBS features, the unicast SMF needs to be enhanced, mainly including: discovering MB-SMF; authenticating user equipment joining (UE Join); interacting with MB-SMF to manage multicast session context; and interacting with RAN to establish multicast transmission resources.

[0164] MB-UPF: It is the data plane gateway of 5G MBS and is mainly responsible for: interacting with MB-SMF to obtain data forwarding rules; transmitting data to RAN through a shared transmission method; transmitting data to UPF through an individual transmission method, etc.

[0165] UPF: Mainly responsible for: interacting with MB-UPF to receive data transmitted by individual delivery; transmitting individual MBS data to UE through PDU session, etc.

[0166] AMF: Mainly responsible for signaling routing; selecting broadcast NG-RANs, etc.

[0167] NG-RAN: Processes MBS QoS flows; sends data to UEs via point-to-multipoint (PTM) and point-to-point (PTP); configures the access stratum (AS) to receive broadcast flows; switches between PTM and PTP; supports Xn and N2 handover for multicast sessions; processes session signaling, establishes air interface broadcast and multicast resources, etc.

[0168] UE: Main functions include: receiving multicast data through PTM or PTP; receiving group multicast data or broadcast data through PTM; processing QoS; initiating session join (session join) and session leave (session leave); and terminal-side resource management of 5G multicast and broadcast service (5MBS).

[0169] MBSF: This is an optional network element. It primarily supports the following functions: service layer functions and interworking with the Multimedia Broadcast Multicast Service (MBMS); interacting with the AF and MB-SMF to support MBS session operations, determining transmission parameters and MBS session types; selecting the MB-SMF; controlling the MBSTF; and determining the sender's Internet Protocol (IP) multicast address.

[0170] MBSTF: This is an optional network element that mainly supports the following functions: serving as an anchor point for MBS data; acting as a source for Internet Protocol multicast (IP multicast); supporting common transmission functions such as framing, multi-streaming, and forward error correction (FEC); and sending input files as objects or object flows in multicast or broadcast mode.

[0171] AF: Mainly supports the following functions: providing service information to the 5G core network (5G core, 5GC) and requesting multicast or broadcast services; instructing MBS session operations with the 5GC, etc.

[0172] UDM: Mainly supports the following functions: support for subscription or contract management of multicast sessions, etc.

[0173] UDR: Mainly supports the following functions: support for managing service parameters, including QoS requirements and serving MB-SMF information; support for UE authorization management for multicast sessions, etc.

[0174] The network architecture shown in Figure 4a can be used to implement unicast-based multicast technology. This unicast-based multicast technology aims to further conserve network resources while maximizing the reuse of unicast processes. Specifically, the user-plane network element selects a single copy of the data stream containing the same content for different UEs within a group and sends it from the UPF to the AN, thereby improving the efficiency of air interface and core network resource utilization. The basic concept is illustrated in Figure 4b, as described below.

[0175] In one implementation example, unicast-based multicast technology can consider the data path processing between the MB-UPF, AN, and UE. The data packets between the AS and MB-UPF can be multicast application packets for a single user equipment (per UE), unicast packets for a per UE, or multicast packets for multicast transmission, without limitation. Application packets from the MB-UPF to the AN to the UE, or from the AN to the UE, are all multicast packets with the same content (the destination IP address is a multicast address). 5G MBS multicast sessions support the following two transmission methods: individual delivery mode and shared delivery mode.

[0176] For example, as shown in Figure 4b, the shared delivery mode is the main scenario of multicast transmission, that is, the transmission channels from the MB-UPF to the RAN side and from the RAN to the UE on the air interface side are shared by several users in the multicast group. For example, for users a, b, and c in group x (denoted as UE a, UE b, and UEc in the figure), a copy of data can be transmitted from the MB-UPF to the RAN side. After the RAN receives this data, the RAN can transmit a copy of the data on the air interface, and users a, b, and c will all receive this data.

[0177] For example, as shown in Figure 4c, Individual Delivery Mode is used when the base station where the UE resides does not support MBS capabilities, namely RAN2 in Figure 4c. The specific transmission path for UE d's multicast data is: MB-UPF, unicast-capable UPF, RAN2, and UE d. Because the data on the RAN side actually originates from the unicast UPF, RAN2 sees it as unicast data.

[0178] Furthermore, considering that the data network may not support IP multicast, the application server can interact with the 5G core network in advance before sending data to select the entry network element (i.e., MB-UPF) for sending multicast data for a certain multicast service. At the same time, the session management network element MB-SMF that manages this MB-UPF network element is also selected. For ease of understanding, the following briefly describes the joining process of unicast-based multicast technology:

[0179] 1. The UE sends a join request to the SMF via a NAS message (e.g., a PDU session modification request or a PDU session establishment request) or a user-plane join request message (e.g., an IGMP Join message). The join request contains multicast group information or multicast session information (a multicast session is used to send data corresponding to a multicast group; the session information can be an MBS session ID).

[0180] 2. After receiving the join request message from the UE, the SMF obtains the multicast information (here the SMF can obtain the multicast information from the MB-SMF or UDR based on the information of the multicast group or multicast session), and generates the corresponding context information of the multicast and, optionally, the corresponding unicast QoS Flow information based on the multicast information. The unicast QoS Flow information is generated here so that when the UE moves to a base station that does not support MBS, the base station can use the corresponding unicast QoS Flow to transmit data for the UE (i.e., individual delivery mode), and the corresponding unicast QoS Flow is provided to the base station in advance, which can better ensure service continuity during switching.

[0181] 3. The SMF then sends a request message to the RAN via the AMF, which contains the information generated above. Based on the message sent by the SMF, the RAN establishes or modifies the multicast context information corresponding to the multicast, and may further establish unicast context information. If the MB-UPF and RAN support multicast transmission, the RAN joins the multicast address sent by the SMF. If the RAN does not support multicast, tunnel identification information can be allocated and returned to the SMF, which is then sent to the MB-SMF. The MB-SMF further sends the tunnel identification allocated by the RAN to the MB-UPF, thereby establishing a unicast transmission channel between the RAN and the MB-UPF. This transmission channel between the RAN and the MB-UPF can be used to transmit a single multicast session (per MBS session).

[0182] As an implementation example, the process of applying a service to use a multicast service is shown in FIG5 , which includes the following steps.

[0183] 1. Service Announcement: The service server sends a service announcement message to the UE, which contains the TMGI or source specific IP multicast address and other service description information such as codec.

[0184] 2. User equipment joins the session (UE Session Join), that is, the UE joins the multicast session and indicates to the 5GC that it wants to receive data from the multicast session.

[0185] 3. Session Establishment, i.e., the establishment of a multicast session, means that downlink data transmission resources can be established between the 5GC and access network equipment (e.g., NG-RAN). Session establishment can be triggered by a UE joining.

[0186] 4. Data Transfer: downlink multicast data is transmitted to the UE.

[0187] 5. The user equipment leaves the session (UE Session Leave), that is, the UE leaves the multicast session, that is, the UE no longer wants to receive data from the multicast session.

[0188] 6. Session Release: The service no longer transmits downlink data, and the resources of the network equipment in the 5G system (5GS) are released.

[0189] As an implementation example, Figure 6a shows an implementation of the application layer architecture and functional model based on the 5MBS architecture. In Figure 6a, the MC service server interacts directly with the 5GC without going through the NEF network element, MBSF network element or MBSTF network element, etc. (that is, these functions can be regarded as non-existent or not deployed).

[0190] As another implementation example, Figure 6b shows an implementation of the application layer architecture and functional model based on the 5MBS architecture. In Figure 6b, the MC service server interacts with the 5GC in various ways, including through NEF network elements, MBSF network elements, or MBSTF network elements. In addition, in Figure 6b, mission critical everything (MCX) information can include one or more of mission critical push to talk (MCPTT), mission critical video (MCVideo), and mission critical data (MCData).

[0191] In addition, at the application layer, support for MBS features may include the following server / client interfaces:

[0192] (1) A server / client interface is: MC service server-MC service client.

[0193] The MC service client is a software module on the terminal device that resides above the operating system and supports SIP registration for trunking services, service authentication and authorization, group calls, individual calls, emergency calls, media speaking rights, and media data processing. These functions can be implemented using the Session Initiation Protocol (SIP), Real-time Transport Protocol (RTP), Real-time Transport Control Protocol (RTCP), and Hypertext Transfer Protocol (HTTP). In terms of supporting 5MBS, the MC service client reports to the server whether it supports broadcast multicast capabilities and the specific broadcast multicast capabilities (eMBMS, 5MBS, or both); receives service or session announcement messages sent by the MC service server, which contain MBS session information (MBS session ID, frequency information, etc.); supports monitoring the broadcast multicast reception quality and reports the broadcast multicast reception quality information to the MC service server; after successfully joining the multicast MBS session, reports to the MC service server the information that the UE has successfully joined the MBS session.

[0194] In addition, the MC service server is a peer-to-peer server-side function of the MC service client. It supports receiving SIP registrations from the MC service client, service authorization, and is responsible for managing services such as group calls, individual calls, and emergency calls. It is responsible for managing and adjudicating voice rights and distributing media data. In terms of supporting 5MBS, it interacts with the core network to create MBS sessions; it peer-to-peer supports the peer-to-peer capabilities on the UE side, namely sending service / session announcement messages to the MC service client, which contain MBS session information (MBS session ID, frequency, etc.); it receives broadcast and multicast reception quality information from the UE; it receives information that the UE has successfully joined the MBS session; and it decides whether to send data to the MBS session based on the UE's reported information.

[0195] (2) Another server / client interface is: NRM server-NRM client.

[0196] The NRM client and NRM server are a group of peer entities that support network capability resource management. The NRM client is a software component or software module in or above an operating system. The functions of the NRM client and NRM server when using 5MBS are the same as those of the MC service client and MC service server. Specifically, the NRM client and NRM server can use SIP and HTTP protocols to support signaling, messaging, and data exchange between the NRM client and the NRM server. For example, Figure 6c is a functional model using the 5MBS architecture based on the service enabler application layer (SEAL) model.

[0197] During the multicast communication process described above, the terminal device, as a multicast receiver, can receive multicast data through the network device. Since the terminal device may be in different connection states, and the way the terminal device receives multicast data may be different in different connection states (e.g., RRC connected state or RRC inactive state), properly setting the connection state for the terminal device to receive multicast data can increase the number of users served by the multicast session and the number of multicast session users that can be served by a single cell.

[0198] In one possible implementation, the UDM / UDR can save indication information indicating the status of the terminal device receiving multicast data; thereafter, when the terminal device establishes a PDU session related to the multicast, the service SMF of the terminal device obtains the indication information from the UDM / UDR. Next, the SMF can send the information to the access network device in the PDU session process. After the access network device receives the multicast data of the terminal device, it can schedule some terminal devices to switch to the RRC inactive state to receive multicast data based on the indication information (and other possible information, such as the reception quality of the terminal device, the capabilities of the terminal device, etc.), and schedule another part of the terminal devices to remain in the RRC connected state to receive multicast data.

[0199] However, in the above implementation method, how to generate the indication information and how to improve the success rate of the terminal device receiving multicast data through the indication information, increase the number of users that the multicast session can serve, and increase the number of users that a single cell can serve is an unresolved problem.

[0200] To solve this problem, the present application provides a communication method and related devices for improving the success rate of receiving multicast data by a terminal device.

[0201] Please refer to FIG7 , which is a schematic diagram of an implementation of the communication method provided in this application. The method includes the following steps.

[0202] It should be noted that, in FIG7 , the method is illustrated by taking the first device, the first terminal device and the network device as the execution subjects of the interaction diagram as examples, but the present application does not limit the execution subjects of the interaction diagram. For example, the execution subject of S701, S702 and S703a in FIG7 and the corresponding implementation is the first device, and the execution subject may also be a chip, chip system, or processor that supports the first device to implement the method, or a logic module or software that can implement all or part of the functions of the first device. The network device in S702, S703a, and S703b in FIG7 and the corresponding implementation may also be replaced by a chip, chip system, or processor that supports the network device to implement the method, or a logic module or software that can implement all or part of the functions of the network device. The first terminal device in S703b in FIG7 and the corresponding implementation may also be replaced by a chip, chip system, or processor that supports the first terminal device to implement the method, or a logic module or software that can implement all or part of the functions of the first terminal device.

[0203] S701. The first device determines, based on the first information, that the first terminal device prefers to receive multicast data in the first state.

[0204] The first state may include a radio resource control (RRC) connected (RRC CONNECTED) state or an RRC inactive (RRC INACTIVE) state.

[0205] It should be understood that the first device may be a server or a logical network element that provides multicast data (or provides multicast services). For example, the first device may be an AF network element, an AS, or a service server.

[0206] It should be noted that, in different connection states, the terminal device may process the multicast data received in different ways. For example, when the first terminal device is in the RRC connection state, when the first terminal device receives multicast data from the channel indicated by the multicast MRB configuration, a hybrid automatic repeat request (HARQ) feedback may be provided. If data packet loss occurs, the access network device may perform point-to-point (PTP) retransmission. It should be understood that the HARQ feedback may be provided by the medium access control (MAC) layer of the first terminal device. When the first terminal device is in the RRC inactive state, when the first terminal device receives multicast data from the channel indicated by the multicast MRB configuration, the first terminal device may not send HARQ feedback. If data packet loss occurs, it is processed by other protocol layers other than the MAC layer of the first terminal device, such as the radio link control (RLC) layer, the packet data convergence protocol (PDCP) layer, etc. Generally speaking, compared with a terminal device in an RRC inactive state, a terminal device in an RRC connected state may have better reception quality and a higher reception success rate.

[0207] In a possible implementation, the first information includes a combination of one or more of the following information A to information I:

[0208] Information A. Capability information of the first terminal device, which can be used to indicate that the first terminal device supports receiving multicast data in the RRC inactive state.

[0209] Information B. Preference information of the first terminal device, where the preference information can be used to indicate that the first terminal device prefers to receive multicast data in the first state.

[0210] Information C: The multicast role of the first terminal device in the group corresponding to the multicast data.

[0211] Information D: Location of the first terminal device.

[0212] Information E: The number of multicast groups in which the first terminal device participates.

[0213] Information F: Number of multicast sessions that the first terminal device has joined.

[0214] Optionally, the multicast session that the first terminal device has joined may be 0 multicast sessions, or may be one or more multicast sessions, wherein the one or more multicast sessions may include the first multicast session or may not include the first multicast session, depending on whether the first terminal device has joined the first multicast session.

[0215] Information G. Reception quality information of the first terminal device for a first multicast session, where the first multicast session is used to transmit the multicast data. For example, the reception quality information may include one or more of reference signal received power (RSRP), reference signal received quality (RSRQ), and received signal strength indicator (RSSI).

[0216] Information H. Service communication model of the first terminal device.

[0217] Information I: One or more speech right request messages from the first terminal device.

[0218] It should be understood that the first device can obtain the above information (ie, information A to information I) in various ways.

[0219] In an implementation example, the first device can obtain the above-mentioned information A to information I through the above-mentioned information reported by the first terminal device.

[0220] In another implementation example, the first device may obtain the above-mentioned information A and information B in a manner determined locally by a client deployed on the first device. For example, the server deployed on the first device (including an MC service server or an NRM server, etc.) may determine the capability information and preference information of the first terminal device based on the operating system version number, or the server deployed on the first device (including an MC service server or an NRM server, etc.) may determine the capability information and preference information of the first terminal device based on the version number of the modem of a client deployed on the terminal device (such as an MC service client or an NRM client).

[0221] In another implementation example, the first device may obtain part or all of the information A to information I by receiving the above information from other servers. For example, a location management server or a gateway mobile location center (GMLC) may provide information D to the first device, and a VAS may provide information A to information H to the first device.

[0222] Thus, the first information serves as one of the bases for the first device to determine that the first terminal device prefers to receive multicast data in the first state. The first information can be implemented through a combination of one or more of the above-mentioned items to enhance the flexibility of the solution implementation. In addition, since the combination of one or more of the above-mentioned information A to information I can reflect the actual service situation of the first terminal device to a certain extent, the first state of the first terminal device receiving multicast data can be set more accurately based on the combination of the one or more items, thereby avoiding setting unreasonable / unnecessary terminal devices to receive in the RRC connection state, saving transmission resources and improving communication efficiency. Moreover, after such a setting, system resources can be more fully utilized, the number of users that can be served by the multicast session can be increased, and the number of users that can be served by a single cell can be increased, thereby enhancing the overall service experience and the user experience of a single terminal device (such as the first terminal device).

[0223] To facilitate understanding, the implementation of the above-mentioned information A to information I will be exemplarily described below with reference to some implementation examples.

[0224] In one implementation example, in step S701, for information A (i.e., the first information includes the capability information of the first terminal device), the first device determines that the first terminal device prefers to receive multicast data in the first state based on the first information, including: when the capability information indicates that the first terminal device supports receiving multicast data in the RRC non-activated state, the first device determines that the first terminal device prefers to receive the multicast data in the RRC non-activated state; or, when the capability information indicates that the first terminal device does not support receiving multicast data in the RRC non-activated state, the first device determines that the first terminal device prefers to receive the multicast data under the RRC connection. Thus, the first device can determine that the first terminal device prefers to receive the multicast data in the RRC non-activated state based on the capability information, so that the first state indicated by the second information sent by the first device in the subsequent step S702 can be adapted to the capability of the first terminal device, thereby enabling the subsequent first terminal device to receive multicast data in the first state supported by the capability of the first terminal device.

[0225] Optionally, the capability information in information A includes that the first terminal device does not support receiving multicast data in the RRC inactive state. To this end, in step S701, the first device can determine that the first terminal device prefers to receive the multicast data in the RRC connected state to avoid scheduling the first terminal device to the RRC inactive state, resulting in the first terminal device failing to receive multicast data.

[0226] In another implementation example, in step S701, for information B (i.e., the first information includes the preference information of the first terminal device), the first device determines that the first terminal device prefers to receive multicast data in the first state based on the first information, including: when the preference information indicates that the first terminal device prefers to receive multicast data in the RRC connected state, the first device determines that the first terminal device prefers to receive the multicast data in the RRC connected state; or, when the preference information indicates that the first terminal device prefers to receive multicast data in the RRC inactive state, determines that the first terminal device prefers to receive the multicast data in the RRC inactive state. Thus, the first device can determine that the first terminal device prefers to receive the multicast data in the RRC connected state or the RRC inactive state based on the preference information, so that the first state indicated by the second information sent by the first device in the subsequent step S702 can be adapted to the preference of the first terminal device, thereby enabling the subsequent first terminal device to receive multicast data in the first state that satisfies the preference of the first terminal device.

[0227] In another implementation example, in step S701, for information C (i.e., the first information includes the multicast role of the first terminal device in the group corresponding to the multicast data), the first device determines, based on the first information, that the first terminal device prefers to receive multicast data in the first state, including: when the multicast role of the first terminal device is a dispatcher (diapacher) or a commander, the first terminal device may perform scheduling / frequent uplink and other operations, and for this reason, the first device determines that the first terminal device prefers to receive the multicast data in the RRC connection state, so that the first terminal device can use the RRC connection to quickly transmit data in the RRC connection state; or, when the multicast role of the first terminal device is a group member (i.e., the multicast role is not a dispatcher or a commander), the first device determines that the first terminal device prefers to receive the multicast data in the RRC inactive state. Thus, the first device can determine, based on the multicast role of the first terminal device, that the first terminal device prefers to receive the multicast data in the RRC connected state or the RRC inactive state, so that the first state indicated by the second information sent by the first device in the subsequent step S702 can be adapted to the multicast role of the first terminal device.

[0228] In another implementation example, in step S701, for information D (i.e., the first information includes the location of the first terminal device), the first device determines, based on the first information, that the first terminal device prefers to receive multicast data in the first state, including: the location of the event corresponding to the multicast data can be used as a reference point, for example, the event can include emergency events such as earthquakes / typhoons, and when the distance between the location of the first terminal device and the reference point is less than or equal to a threshold, due to the close distance, the first terminal device may need to receive multicast data quickly / with high quality, for this reason, the first device determines that the first terminal device prefers to receive the multicast data in the RRC connection state. Or, when the distance between the location of the first terminal device and the reference point is greater than or equal to a threshold, due to the long distance, the first terminal device may not need to receive multicast data quickly / with high quality, for this reason, the first device determines that the first terminal device prefers to receive the multicast data in the RRC connection state. Thus, the first device can determine, based on the location of the first terminal device, that the first terminal device prefers to receive the multicast data in the RRC connected state or the RRC inactive state, so that the first state indicated by the second information sent by the first device in the subsequent step S702 can adapt to the relationship between the location of the first terminal device and the reference point.

[0229] In another implementation example, in step S701, for information E (i.e., the first information includes the number of multicast groups in which the first terminal device participates), the first device determines, based on the first information, that the first terminal device prefers to receive multicast data in the first state, including: when the number of multicast groups in which the first terminal device participates is greater than or equal to a threshold, the first terminal device may need to receive multicast data quickly / with high quality, and for this purpose, the first device determines that the first terminal device prefers to receive the multicast data in the RRC connected state; or, when the number of multicast groups in which the first terminal device participates is less than or equal to a threshold, the first terminal device may not need to receive multicast data quickly / with high quality, and for this purpose, the first device determines that the first terminal device prefers to receive the multicast data in the RRC connected state. Thus, the first device can determine, based on the number of multicast groups in which the first terminal device participates, that the first terminal device prefers to receive the multicast data in the RRC connected state or the RRC inactive state, so that the first state indicated by the second information sent by the first device in the subsequent step S702 can be adapted to the number of multicast groups in which the first terminal device participates.

[0230] In another implementation example, in step S701, for information F (i.e., the first information includes the number of multicast sessions that the first terminal device has joined), the first device determines, based on the first information, that the first terminal device prefers to receive multicast data in the first state, including: when the number of multicast sessions that the first terminal device has joined is greater than or equal to a threshold, the first terminal device may need to receive multicast data quickly / with high quality, and for this purpose, the first device determines that the first terminal device prefers to receive the multicast data in the RRC connected state; or, when the number of multicast sessions that the first terminal device has joined is less than or equal to a threshold, the first terminal device may not need to receive multicast data quickly / with high quality, and for this purpose, the first device determines that the first terminal device prefers to receive the multicast data in the RRC connected state. Thus, the first device can determine, based on the number of multicast sessions that the first terminal device has joined, that the first state indicated by the second information sent by the first device in the subsequent step S702 can be adapted to the number of multicast sessions that the first terminal device has joined.

[0231] In another implementation example, in step S701, for information G (i.e., the first information includes the reception quality information of the first terminal device for the first multicast session), the first device determines, based on the first information, that the first terminal device prefers to receive multicast data in the first state, including: when the reception quality indicated by the reception quality information is less than or equal to a threshold, the first terminal device may need to receive multicast data quickly / with high quality, and for this purpose, the first device determines that the first terminal device prefers to receive the multicast data in the RRC connected state; or, when the reception quality indicated by the reception quality information is greater than or equal to a threshold, the first terminal device may not need to receive multicast data quickly / with high quality, and for this purpose, the first device determines that the first terminal device prefers to receive the multicast data in the RRC connected state. Thus, the first device can determine, based on the reception quality information of the first terminal device, that the first terminal device prefers to receive the multicast data in the RRC connected state or the RRC inactive state, so that the first state indicated by the second information sent by the first device in the subsequent step S702 can be adapted to the number of multicast sessions to which the first terminal device has joined.

[0232] In another implementation example, in step S701, for information H (i.e., the first information includes the service communication model of the first terminal device), the first device determines, based on the first information, that the first terminal device prefers to receive multicast data in the first state, including: when the service communication model of the first terminal device indicates frequent uplink, large uplink data transmission volume / high transmission frequency, or large downlink data transmission volume / high transmission frequency, the first device determines that the first terminal device prefers to receive the multicast data in the RRC connection state; or, when the service communication model of the first terminal device indicates only downlink or only uplink, the first device determines that the first terminal device prefers to receive the multicast data in the RRC inactive state. Thus, when the service communication model indicates frequent uplink, since the terminal device may need to send uplink data through frequent RRC connection recovery requests in the RRC inactive state, the first device can determine that the first terminal device prefers to receive the multicast data in the RRC connection state to reduce the power consumption and implementation complexity of the first terminal device. When the service communication model indicates downlink only, since the terminal device can still receive downlink-only data in the RRC inactive state, the first device can determine that the first terminal device prefers to receive the multicast data in the RRC inactive state to reduce the power consumption of the first terminal device.

[0233] In another implementation example, in step S701, for information I (the first information includes one or more right-of-speech request messages from the first terminal device), the first device determines, based on the first information, that the first terminal device prefers to receive multicast data in the first state, including: when the total amount of the one or more right-of-speech request messages exceeds a first threshold and / or the frequency of the one or more right-of-speech request messages exceeds a second threshold, the first device determines that the first terminal device prefers to receive the multicast data in the RRC connection state. Thus, in the case where the first information includes one or more right-of-speech request messages from the first terminal device, when the total amount of one or more right-of-speech request messages exceeds the first threshold and / or the frequency of the one or more right-of-speech request messages exceeds the second threshold, the first terminal device may have a larger uplink transmission demand. To this end, the first device can determine that the first terminal device prefers to receive the multicast data in the RRC connection state to meet the larger uplink transmission demand of the first terminal device and reduce the power consumption and implementation complexity of the first terminal device.

[0234] Optionally, for information I, in addition to whether the total amount of the one or more right-to-speak request messages exceeds the first threshold and / or whether the frequency of the one or more right-to-speak request messages exceeds the second threshold as the basis for determining the first state, other statistical information of the one or more right-to-speak request messages may also be included, such as the time interval between any two right-to-speak request messages. When the time interval is less than or equal to the threshold, the first device determines that the first terminal device prefers to receive the multicast data in the RRC connected state; when the time interval is greater than or equal to the threshold, the first device determines that the first terminal device prefers to receive the multicast data in the RRC inactive state.

[0235] It should be noted that the thresholds involved in this application (such as the thresholds mentioned above, the first threshold, the second threshold and the third threshold, etc.) can be statically pre-set and their values ​​will not change, or they can be dynamically adjusted and their values ​​can change, which is not limited here.

[0236] In another implementation example, in step S701, the first information may include a combination of two or more of the information A to information I, so that the first device determines that the first terminal device prefers to receive multicast data in the first state based on the combination. In this case, the first information also includes priority information corresponding to at least one of the above-mentioned information A to information I. Specifically, the priority information can indicate the priority of the above-mentioned at least one item, so that when the first information includes two or more of the above-mentioned at least one item, the first device can select one of them as the basis for determination according to the priority information, so as to avoid behavioral confusion caused by the contradiction between the two or more items, so that the first device can determine that the first terminal device prefers to receive multicast data in the first state based on the priority indicated by the priority information.

[0237] Optionally, the priority information is preconfigured / predefined, or the priority information comes from other devices (such as core network devices, servers, etc.), which is not limited here.

[0238] Optionally, in addition to the implementation of the above-mentioned information A to information I, the first information may also include other information content. Exemplarily, the first information may include information J, which may indicate the status of the first terminal device. Accordingly, in step S701, for information J (the first information includes the status from the first terminal device), the first device determines that the first terminal device prefers to receive multicast data in the first state based on the first information, including: when the state of the first terminal device is an emergency state, the first device determines that the first terminal device prefers to receive the multicast data in the RRC connection state; when the state of the first terminal device is not an emergency state, the first device determines that the first terminal device prefers to receive the multicast data in the RRC non-activated state (which can reduce the power consumption of the first terminal device). Thus, when the first information includes the status of the first terminal device, when the state of the first terminal device is a promotion state, the first terminal device may have a larger uplink transmission demand. To this end, the first device can determine that the first terminal device prefers to receive the multicast data in the RRC connection state to meet the larger uplink transmission demand of the first terminal device and reduce the power consumption and implementation complexity of the first terminal device.

[0239] In one possible implementation, the multicast data is multicast data of a first multicast session. Specifically, the multicast data of the first terminal device may be multicast data of a certain multicast session (e.g., the first multicast session), so that the first device can set a first state for receiving multicast data by the terminal device based on the granularity of the multicast session, thereby improving a success rate of receiving multicast data by the terminal device in the first multicast session.

[0240] In one possible implementation, the capability information and the preference information (i.e., information A and / or information B described above) come from an MC service client, which is deployed on the first terminal device. Specifically, when the capability information and the preference information in the first information come from the first terminal device, the capability information and the preference information may come from the MC service client in the first terminal device. Accordingly, the first device may receive the capability information and the preference information from the MC service client via the MC service server, so that the above solution can be adapted to communication scenarios between the MC service client and the MC service server.

[0241] In a possible implementation, the method also includes: the first device receives a first message from the MC service client, the first message carrying the capability information and / or the preference information (i.e., the information A and / or information B above); wherein the first message is a critical business service registration message (the message is used to indicate the registration of the client by the MC service client on the terminal device, or the message is used to indicate the registration of the terminal device deployed with the MC service client), an emergency business service registration request message (the message is used to indicate the registration of the client by the MC service client on the terminal device, or the message is used to indicate the registration of the terminal device deployed with the MC service client), a UE session join notification message (the message is used to indicate that the terminal device has successfully joined the multicast broadcast service (MBS) session), or a multicast broadcast service session listening status report message (the message is used to indicate whether the terminal can receive data of the MBS session, or the message is used to indicate the quality of reception of the terminal device in the MBS session, the level of reception quality, etc.). Specifically, when the capability information and the preference information can come from the MC service client in the first terminal device, the first device can obtain the capability information and / or the preference information through a first message, and the first message can be implemented through any of the above items to enhance the flexibility of the solution implementation.

[0242] In one possible implementation, the capability information and / or the preference information (i.e., information A and / or information B described above) comes from an NRM client, VAS, or GMS, and the NRM client is deployed on the first terminal device. Specifically, the capability information and / or the preference information received by the first device may come from the NRM client, VAS, or GMS deployed on the first terminal device, thereby providing multiple implementations for the first device to obtain the capability information and / or the preference information.

[0243] In one possible implementation, the method also includes: the first device receives a second message from the NRM client, the second message carries the capability information and / or the preference information (i.e., the information A and / or information B above), wherein the second message is an NRM registration request message (the message is used to indicate the registration of the client by the NRM client on the terminal device, or the message is used to indicate the registration of the terminal device deployed with the NRM client), an NRM service registration request message (the message is used to indicate the registration of the client by the NRM client on the terminal device, or the message is used to indicate the registration of the terminal device deployed with the NRM client), a UE session join notification message (the message is used to indicate that the terminal device has successfully joined the MBS session), or a multicast broadcast service session listening status report message (the message is used to indicate whether the terminal can receive data of the MBS session, or the message is used to indicate the quality of reception of the terminal device in the MBS session, the level of reception quality, etc.). Specifically, when the capability information and the preference information can come from the NRM client in the first terminal device, the first device can obtain the capability information and / or the preference information through a second message, and the second message can be implemented through any of the above items to enhance the flexibility of the solution implementation.

[0244] S702. The first device sends second information to the network device.

[0245] Correspondingly, the network device receives the second information.

[0246] The second information may be used to indicate that the first terminal device prefers to receive multicast data in the first state.

[0247] It should be understood that in step S702, the recipient of the second information sent by the first device may be a network device, and the network device may be a network device connected to the first terminal device, or the network device may be a device that provides network services to the first terminal device. The network device may include an access network device and / or a core network device, etc. For example, when the network device includes an access network device, the first device may send the second information to the access network device via a direct link or an indirect link between the access network device and the first device. For another example, when the network device includes a core network device, the first device may send the second information to the core network device via a direct link or an indirect link between the first device and the core network device. For another example, when the network device includes an access network device and a core network device, the first device sends the second information to both the access network device and the core network device.

[0248] Taking the example that the network device includes an access network device or a core network device (such as NEF, UMD, MB-SMF, etc.), in the process of the first device sending the second information to the network device in step S702, the first device can send the second information to the access network device through the core network device, or the first device sends the second information to the core network device, and subsequently in the process of the core network device and the access network device establishing a multicast session of the first terminal device, the core network device sends the second information to the access network device.

[0249] The network device may be a UDM or UDR network element in a core network element, and the first device may specifically send the second information to the UDM or UDR network element via an NEF network element. For example, in this process, the first device invokes a service-specific parameter provisioning message of the NEF and sends the second information to the UDM or UDR via the NEF.

[0250] Optionally, the second information is carried in multicast broadcast service auxiliary information, or other messages / signaling / information, which is not limited here.

[0251] Optionally, the second information sent by the first device to the network device in step S702 may be sent at a multicast session granularity (for example, when the second information is carried in multicast broadcast service auxiliary information), that is, the second information may indicate that the terminal devices in a multicast session prefer to receive the multicast data in the first state, and the terminal devices in the multicast session include the first terminal device and other terminal devices that may exist. In other words, for different multicast sessions in a multicast broadcast service session list (MBS session list), different multicast sessions may correspond to different multicast broadcast service session identifiers (MBS session IDs). The first device may send different second information to respectively indicate that one or more terminal devices in the multicast sessions corresponding to different multicast broadcast service session identifiers prefer to receive multicast data in the first state.

[0252] Optionally, the second information sent by the first device to the network device in step S702 may include information indicating that terminal devices in different multicast sessions prefer to receive the multicast data in the first state, where the terminal devices of one of the different multicast sessions include the first terminal device and any other terminal devices. In other words, for different multicast sessions in a multicast broadcast service session list (MBS session list), the different multicast sessions may correspond to different multicast broadcast service session identifiers (MBS session IDs). The first device may send the second information and, through multiple pieces of information in the second information, respectively indicate that one or more terminal devices in the multicast sessions corresponding to different multicast broadcast service session identifiers prefer to receive the multicast data in the first state. In addition, when the network device includes a core network device and an access network device, after the first device sends the second information containing the multiple pieces of information to the core network device, the core network device may send the portions of the multiple pieces of information corresponding to several multicast sessions to the access network device, or the core network device may send all of the multiple pieces of information to the access network device, which is not limited here.

[0253] In one possible implementation, the second information is also used to instruct other terminal devices in the multicast group to which the first terminal device belongs to receive the first multicast data in the first state. Specifically, the second information is also used to instruct other terminal devices in the multicast group to which the first terminal device belongs to receive the first multicast data in the first state, so that the above scheme can implement a preference setting for the first state of receiving multicast data by the terminal devices included in the multicast group, thereby reducing overhead.

[0254] In one possible implementation, the multicast data is multicast data of a first multicast session, and the first device sending the second information to the network device includes: when at least one of the following conditions is satisfied, the first device sending the second information to the network device includes:

[0255] Case A: The session identifier of the first multicast session has been determined, but the first multicast session has not been created.

[0256] Case B: the first multicast session has been created, but the first terminal device has not yet joined the first multicast session.

[0257] Case C: the first multicast session has been created, and the first terminal device has joined the first multicast session.

[0258] Case D: the first multicast session has been created, the first terminal device has joined the first multicast session, and the association between the first multicast session and the group has been sent to the first terminal device.

[0259] Specifically, the multicast data of the first terminal device may be multicast data of a certain multicast session (eg, the first multicast session), and the first device may trigger the sending of the second information based on various situations of the first multicast session to enhance the flexibility of the solution implementation.

[0260] Optionally, for the first device, when the first device receives a session identifier of a first multicast session from a network device (e.g., a core network device), the first device determines the session identifier of the first multicast session. The session identifier may be a multicast broadcast service session identifier (MBS session ID) or other names, which are not limited here. Exemplarily, the receiving process may be a step in the MBS session ID allocation process performed by the first device and the core network device in interaction, wherein the first device sends an MBS session ID request to the core network device, the core network device allocates an MBS session ID and returns the MBS session ID to the first device, so that the first device can determine the MBS session ID of the first multicast session.

[0261] Optionally, after the first device sends a response message indicating successful session establishment of the first multicast session to a network device (e.g., a core network device), the first device determines that the first multicast session has been established. The response message may be a response message indicating successful establishment of a multicast broadcast service auxiliary information (MBS) session. Accordingly, before the first device sends the response message, it may be determined that the first multicast session has not been established.

[0262] Optionally, for the first device, when the first device receives indication information from a network device (e.g., a core network device), the first device may determine that the first terminal device has joined the first multicast session, where the indication information is used to indicate that the first terminal device and the network device have executed the MBS session joining process. Accordingly, before the first device receives the indication information, the first device may determine that the first terminal device has not yet joined the first multicast session.

[0263] It should be noted that in step S701, when the capability information and / or preference information (i.e., information A and / or information B above) contained in the first information comes from the first terminal device, in case A, the first terminal device reports the capability information and / or preference information to the first device once, and the capability information and / or preference information can be at the granularity of a single user device (per UE), thereby avoiding signaling waste caused by multiple reports. In cases B and C, after the first multicast session is established, the first terminal device can report the capability information and / or preference information to the first device once or multiple times, and the capability information and / or preference information can be at the granularity of a single multicast session (e.g., a multicast broadcast service session (per MBS session)) or a multicast group (group), and the granularity of the information is finer, and the server settings are more accurate. In case D, the group call to which the first terminal device belongs has been established, and the first device decides to transmit the group call on the first multicast session. The first device then sends a message indicating the association between the group or group call and the first multicast session to the members of the group (such as the first terminal device and other terminal devices that may exist) (for example, the message may include a group association to session stream (MapGroupToSessionStream) message), so that the group members know that they can receive group information (including signaling and media data of the group call) on the first multicast session. Thereafter, the first device sends the second information to the network device in step S702.

[0264] Furthermore, the above method may further include step S703a and step S703b, as described below.

[0265] S703a. The first device sends multicast data to the network device.

[0266] Correspondingly, the network device receives the multicast data.

[0267] S703b. The network device sends multicast data.

[0268] Correspondingly, the first terminal device receives the multicast data.

[0269] Exemplarily, the network device may include a core network device (such as UDM, UDR or MB-UPF, etc.) and an access network device. After the UDM or UDR receives the second information in step S702, the UDM or UDR network element may send the second information to the access network device. In step S703a, after the MB-UPF of the core network device receives the multicast data from the first device in step S703a, the MB-UPF may send the multicast data to the access network device in step S703b. When the access network device receives the multicast data of a multicast group in step S703a, the access network device may schedule some terminal devices in the multicast group to receive the multicast data in the RRC connected state in step S703b, and the access network device may also schedule other terminal devices in the multicast group to receive the multicast data in the RRC inactive state (for example, switching from the connected state to the inactive state) in step S703b. The scheduling basis of the access network device may include the second information in step S702, so that the first terminal device in the multicast group can receive the multicast data in the first state based on the preference indicated by the second information.

[0270] Optionally, the scheduling basis of the access network device may also include other information, such as the current load level of the network device, the reception quality of the terminal device, the capability of the terminal device, etc.

[0271] Based on the scheme shown in Figure 7, after the first device determines that the first terminal device prefers to receive multicast data in the first state based on the first information, the first device sends a second information to the network device to indicate that the first terminal device prefers to receive the multicast data in the first state, and the first state includes an RRC connected state or an RRC inactive state. Among them, since the terminal device may be in different connection states, and in different connection states (such as RRC connected state or RRC inactive state), the terminal device may process the multicast data differently. Therefore, reasonably setting the connection state of the terminal device to receive multicast data will be able to increase the number of users served by the multicast session, and at the same time, it can increase the number of multicast session users that can be served by a single cell. In the above scheme, the first device can determine the second information based on the first information and send the second information to the network device, so that the network device can use the second information as one of the bases for scheduling the first terminal device to receive multicast data, thereby enabling the network device to schedule the first terminal device to receive the multicast data in the first state (such as the implementation process of steps S703a and S703b), thereby improving the success rate of the first terminal device receiving multicast data.

[0272] In the solution shown in FIG7 , as can be seen from the descriptions of Cases A to C, when the first information includes capability information and / or preference information (i.e., information A and / or information B described above), the first device may obtain the capability information and / or preference information at different times. This will be exemplified below using the embodiments shown in FIG8 and FIG9 , respectively.

[0273] Please refer to FIG8 , which is an application example of the communication method shown in FIG7 , including the following steps.

[0274] It should be noted that, in the implementation shown in FIG8 , step S803 is an implementation example of the previous step S701 , step S804 is an implementation example of the previous step S702 , step S808 is an implementation example of the previous step S703a , and step S809 is an implementation example of the previous step S703b . Other steps in FIG8 are optional steps.

[0275] S800. A PDU session is established between the terminal device and the network device.

[0276] S801a. The terminal device sends capability information and / or preference information to the first device through the network device.

[0277] Among them, the capability information and / or preference information can refer to the information A and / or information B above, and will not be repeated here.

[0278] Exemplarily, in step S801a, a client (MC service client / NRM client) deployed on the first terminal device sends capability information and / or preference information to the first device.

[0279] For example, the client may obtain, from the modem of the first terminal device, the capability of the first terminal device to receive MBS data when RRC is inactive.

[0280] For another example, the client may determine, based on the operating system version number or the modem version number, that the first terminal device supports the capability of receiving MBS data in RRC inactive.

[0281] For another example, the client may obtain the preference information of the user holding the first terminal device for receiving MBS data (eg, whether the user frequently speaks or frequently sends uplink data) through the human-computer interaction interface.

[0282] Optionally, the client may also directly report the preference information or further translate the preference information into: a preference to maintain the connected MBS session reception data and report it to the first device.

[0283] In addition, the Client deployed on the first terminal device (such as MC service client / NRM client) can send the information to the first device in a registration request message. For example, when the Client deployed on the first terminal device is an MC client, the registration request can be an MC service registration / emergency service registration request message. When the Client deployed on the first terminal device is an NRM client, it can be an NRM registration request message. Optionally, the message is executed once during the client login. Optionally, it is executed again when logging into the first device again after logging out of the system or shutting down the computer.

[0284] S801b. The VAS / GMS sends capability information and / or preference information to the first device.

[0285] Exemplarily, when the client deployed on the first terminal device is an NRM client and the NRM server is deployed on the first device, the NRM server can also obtain the RRC inactive receiving MBS session data capability / MBS data receiving preference information of a first terminal device / user from the VAS or GMS (the preference is to remain in the connected state to receive MBS session data), or receive the RRC inactive receiving MBS session data capability of all terminal devices / users in a group, or receive the first terminal device / user / client list information that prefers to receive MBS data in the connected state.

[0286] S802. The first device receives an identifier of a multicast session from a network device.

[0287] The members of the multicast session may include the first terminal device.

[0288] Exemplarily, the first device interacts with the network device, executes an MBS session ID allocation process, and obtains one or more MBS session IDs (including ID1...IDn, where n is an integer greater than 1) for future MBS session creation. Optionally, each MBS session ID may correspond to an MBS service area.

[0289] S803. The first device determines, based on the first information, that the first terminal device prefers to receive multicast data in the first state.

[0290] Exemplarily, the first device decides to use MBS session ID 1 for Group X, and determines that the first terminal device (belonging to group X) prefers / prefers to use (maintain) a connected state to receive multicast data for session data of MBS session ID 1.

[0291] The first device determines that the first terminal device (bias / preference) remains (switches) to receive multicast data in a connected state based on one or more of the following information: the RRC inactive multicast reception capability / preference of the first terminal device (such as whether it has inactive RRC reception capability), the role of the first terminal device in the group (such as dispatcher, commander, group caller), the location information of the first terminal device (such as a terminal device whose distance from the location where the incident occurred is less than a threshold), the number of group calls in which the first terminal device participates (such as the number of multicast groups in which the first terminal device participates or the number of multicast sessions that the first terminal device has joined is greater than a threshold), and the MBS reception quality and / or reception quality level (Level) reported in the MBS listening status report.

[0292] It should be noted that in step S803, the first device may determine the preference of the first terminal device to receive multicast data in the first state based on the granularity of a single multicast group or a single terminal device. For example, when multiple groups to which a terminal device belongs are mapped to different MBS session IDs, the first device determines the multicast reception preference for the multicast session corresponding to each MBS session ID among the multiple MBS session IDs of the terminal device. Specifically, the first device may set the multicast reception capability preference of a terminal device for multiple MBS session IDs to be the same (for example, preference for connected state reception).

[0293] As an example, the first device determines whether the MBS reception preference of a certain terminal device is biased towards maintaining reception in the connected state, which may be:

[0294] (1) Based on the information about the multicast receiving capability of the first terminal device in the group in the RRC inactive state, for example, setting a user that does not support multicast receiving in the RRC inactive state to remain in the connected state to receive MBS data;

[0295] (2) According to the role of the first terminal device in the group, which may be a role that frequently sends uplink data, such as a commander or a diapacher, these first terminal devices are set to remain in a connected state to receive MBS data;

[0296] (3) Based on the location of the first terminal device, for example, users who are closer to the event are set to remain in a connected state to receive MBS data; the first device can obtain the location information of the first terminal device from the first terminal device, or obtain the location information of the first terminal device from other first devices such as a location management server or a VAL server.

[0297] (4) As the number of group calls in which the first terminal device (simultaneously) participates increases or exceeds a certain threshold, the first terminal device is set to remain in a connected state to receive MBS data; specifically, the function of the MC service server at this time is to participate in the first device (participating UE, a participating function defined in 3GPP 23.379 and 24.379). This step can be statistically implemented after step S807. When the Client deployed on the first terminal device is an NRM client, the NRM server deployed on the first device can obtain the number of group calls in which the first terminal device participates from the VAL server.

[0298] (5) As the number of MBS sessions in which the first terminal device (simultaneously) participates increases or exceeds a certain threshold, the first terminal device is configured to remain in a connected state to receive MBS data. The first terminal device may be configured to remain in a connected state to receive MBS data for each of the multiple MBS session IDs. Specifically, the function of the MC service server at this time is to participate in the first device (participating UE, a participating function defined in 3GPP 23.379 and 24.379). This statistical information may be collected after step S806c.

[0299] (6) determining, based on the reception quality / level for the MBS session ID reported by the first terminal device, that the first terminal device is configured to remain in the connected state to receive MBS data when the reception quality and / or the reception quality level is less than a predetermined threshold;

[0300] (7) When the NRM server is in operation, it can also obtain the list of terminal devices (referred to as UE list) that remain in the connected state to receive multicast session data per service from the VAL server. The NRM server can combine the UE lists sent by multiple VAL servers to aggregate the situation in which the MBS session of each first terminal device remains in the connected state to receive data, and then decide whether the first terminal device remains in the connected state to receive MBS session data. At this time, the UE list sent by the VAL server to the NRM server can indicate a UE list with a frequent uplink business model. Based on this information, the NRM server determines that it is best for the first terminal device to remain in the connected state to receive data. That is, the NRM server can translate the information provided by the VAL into business requirements and network requirements.

[0301] Specifically, step S803 may simultaneously refer to one or more information in (1)-(7), further assign a weight and / or priority to each information, and make a determination with reference to the weight and / or priority.

[0302] S804. The first device sends second information to the network device.

[0303] Exemplarily, the network device may include NEF or UDM, that is, the first device may send second information through NEF or UDM, and the second information may be MBS assistance information of the first terminal device, which contains information for indicating that the first terminal device prefers to remain in a connected state for users to receive multicast MBS data.

[0304] It should be understood that MBS refers to multicast and broadcast services, and multicast MBS may refer to multicast and broadcast services of the multicast type. Accordingly, MBS may also include multicast and broadcast services of the broadcast type, which may be referred to as broadcast MBS.

[0305] S805. The first device creates a multicast session.

[0306] Exemplarily, the first device uses MBS session ID 1 to initiate a multicast MBS session establishment process to 5GC and successfully creates an MBS session.

[0307] S806a. The first device sends an announcement to the first terminal device through the network device.

[0308] Exemplarily, the first device sends an MBS service / session announcement message to the client, where the message notifies the client of information about the multicast MBS session, including MBS session ID 1, frequency information, MBS service area information, and the like.

[0309] S806b. The first terminal device joins the multicast session.

[0310] Exemplarily, the first terminal device joins the multicast MBS session indicated by MBS session ID 1. At this time, MBS assistance information per the first terminal device is sent to the RAN node.

[0311] S806c. The first terminal device sends a message to the first device through the network device, where the message is used to indicate successful joining of the multicast session.

[0312] Exemplarily, the client sends a report message to the first device indicating that the first terminal device has successfully joined the multicast MBS session. The client also sends MBS session reception quality reporting information (via an MBS session listening status report) to the first device, indicating the quality information or level of the MBS session that the first terminal device can receive. The first terminal device can derive the MBS session quality information or level based on information such as the broadcast information reference signal and the media packet loss rate.

[0313] S807a. The first terminal device and the first device determine that the multicast session has been created.

[0314] S807b. The first device sends a MapGroupToSessionStream message to the first terminal device, which is used to notify the first terminal device to receive media data of multicast session X (Group X) in the MBS session indicated by MBS session ID 1.

[0315] Exemplarily, a multicast session is successfully established between the MC service client(s) deployed on the first terminal device and the MC service server deployed on the first device, and the media plane is successfully established. In addition, when the client deployed on the first terminal device and the server deployed on the first device are the NRM client and the NRM server respectively, this step may occur between the vertical application layer client (VAL client) and the vertical application layer server (VAL server). Among them, the VAL client is used to implement the business application client function on the first terminal device. The VAL client can be considered as one of the MC service clients. The VAL client can also be replaced by a media client, a vehicle to everything (V2X) application client, etc. Thereafter, the first device sends a MapGroupToSessionStream message to the first terminal device in step S807b. The information is used to notify the first terminal device to receive the media data of Group X in the MBS session indicated by MBS session ID1.

[0316] S808. The first device sends multicast data to the network device.

[0317] Exemplarily, the MC service server may send downlink media data to the network device (downlink media data is an example of multicast data). In the case where the first device is deployed with an NRM server, the VAL server may send downlink media data to the network device without passing through the NRM server.

[0318] S809. The network device sends multicast data to the first terminal device.

[0319] For example, after receiving the MBS session data, the access network device in the network device decides to let the first terminal device remain in the connected state to receive the multicast MBS data based on the MBS assistance information, the multicast reception capability of the first terminal device, the reception quality information of the first terminal device, etc., and guides other terminal devices to use the RRC inactive state to receive.

[0320] Step S810: The first terminal device sends one or more speaking right request messages.

[0321] For example, the subsequent MC service server may receive a floor request sent by the MC service client, and the floor request message is used to request the sending of uplink data. The MC service server may count the total amount / frequency of floor requests sent by the first terminal device, determine whether the specific first terminal device frequently sends uplink data, and then set the first terminal device to remain in the connected state to receive mutlicast MBS data. If it is the case of an NRM client and server, the VAL server may determine to set the first terminal device to receive broadcast data in the connected state based on the business model of the first terminal device, such as frequent uplink data transmission. The NRM server may change the contract data of the first terminal device and set the first terminal device to prefer receiving MBS data in the connected state. For detailed examples, please refer to the example in (7) of step 3 above.

[0322] Optionally, the first device may advance step S805 to step S802 and replace step S802 without carrying any MBS session ID. In this case, a new MBS session ID1 is obtained from establishing the MBS session in step S805.

[0323] Optionally, steps S807a and S807b may also occur before step S802. In this case, the first terminal device first receives the media data via unicast, and then after step S807b, receives the group data via multicast, for example, in the manner described in (4) and (7) of step S803.

[0324] Through the solution of the embodiment shown in Figure 8, the first device can reasonably select which first terminal devices prefer to be kept in the connected state for reception based on actual business conditions, such as the large number of group business members, the capabilities of the first terminal devices, the data transmission mode of the first terminal devices, the location of the first terminal devices, and the reception quality of the first terminal devices. The result of such settings will make the settings of the first terminal devices more accurate, avoiding setting unreasonable / unnecessary first terminal devices in the connected state for reception, which wastes valuable system transmission resources. After such settings are made, system resources can be fully utilized, so that the overall business experience and the user experience of a single first terminal device are optimized.

[0325] In addition, in some implementations, by selecting the appropriate time / actually setting the preferred receiving capability of the first terminal device, the first terminal device that needs to receive in the connected state can also be set more accurately.

[0326] In addition, in some implementations, the first terminal device may report the RRC receiving capability or preference information of the first terminal device to the first device once, and the report is at the granularity of a single terminal device, so as to avoid signaling waste caused by multiple reports.

[0327] Please refer to FIG9 , which is another application example of the communication method shown in FIG7 , including the following steps.

[0328] It should be noted that, in the implementation shown in FIG9 , step S904 is an implementation example of the previous step S701 , step S905 is an implementation example of the previous step S702 , step S909 is an implementation example of the previous step S703a , and step S909 is an implementation example of the previous step S703b . The other steps in FIG9 are optional steps.

[0329] S900. A PDU session is established between the terminal device and the network device.

[0330] S901a. The terminal device sends a registration message to the first device through the network device.

[0331] S901b. The VAS / GMS sends capability information and / or preference information to the first device.

[0332] Among them, the capability information and / or preference information can refer to the description of information A and / or information B above, and will not be repeated here.

[0333] S902. The first device creates a multicast session.

[0334] S903a. The first device sends an announcement to the first terminal device through the network device.

[0335] S903b. The first terminal device joins the multicast session.

[0336] S903c. The first terminal device sends a message to the first device through the network device, where the message is used to indicate successful joining of the multicast session.

[0337] Optionally, in step S903c, the message sent by the first terminal device may carry capability information and / or preference information (ie, information A and / or information B above).

[0338] It should be noted that, unlike the embodiment shown in FIG8 , the client deployed on the first terminal device carries capability information and / or preference information in the report message of the first terminal device successfully joining the multicast session. Alternatively, the capability information and / or preference information is reported in the MBS session listening status report message.

[0339] S904. The first device determines, based on the first information, that the first terminal device prefers to receive multicast data in the first state.

[0340] S905. The first device sends second information to the network device.

[0341] Among them, the implementation process of the first device sending the second information to the network device can refer to the above description and will not be repeated here.

[0342] S906a. The first terminal device and the first device determine that the multicast session has been created.

[0343] S906b. The first device sends a MapGroupToSessionStream message to the first terminal device. This message is used to notify the first terminal device to receive media data of Group X in the MBS session indicated by MBS session ID1.

[0344] S907. The first device sends multicast data to the network device.

[0345] S908. The network device sends multicast data to the first terminal device.

[0346] S909. The first terminal device sends one or more speaking right request messages.

[0347] It should be noted that the steps shown in FIG9 can refer to the implementation process shown in FIG8 , and are not described in detail here.

[0348] Through the solution of the embodiment shown in Figure 9, the first device can reasonably select which first terminal devices prefer to be kept in the connected state for reception based on actual business conditions, such as the large number of group business members, the capabilities of the first terminal device, the data transmission mode of the first terminal device, the location of the first terminal device, and the reception quality of the first terminal device. The result of such settings will make the settings of the first terminal devices more accurate, avoiding setting unreasonable / unnecessary first terminal devices in the connected state for reception, which wastes valuable system transmission resources. After such settings are made, system resources can be fully utilized, so that the overall business experience and the user experience of a single first terminal device are optimized.

[0349] In addition, in some implementations, the first terminal device reports capability information and / or preference information to the first device after the MBS session is established. The capability information and / or preference information may be reported multiple times with the granularity of a single multicast session or a single multicast group. The granularity of the capability information and / or preference information is finer, so that the first device can set the first state of the first terminal device more accurately.

[0350] Referring to Figure 10, an embodiment of the present application provides a communication device 1000, which can implement the functions of the first device, first terminal device, or network device in the above-mentioned method embodiment, and thus can also achieve the beneficial effects of the above-mentioned method embodiment. Specifically, the communication device 1000 can be a first device, a first terminal device, or a network device, or it can be an integrated circuit or component, such as a chip, within the first device, the first terminal device, or the network device. The following embodiments are described using the communication device 1000 as an example of a first device, a first terminal device, or a network device.

[0351] In one possible implementation, when the apparatus 1000 is used to execute the method executed by the first device in any of the aforementioned embodiments, the apparatus 1000 includes a processing unit 1001 and a transceiver unit 1002; the processing unit 1001 is used to determine, based on the first information, that the first terminal device prefers to receive multicast data in a first state; wherein the first state includes a radio resource control RRC connected state or an RRC inactive state; the transceiver unit 1002 is used to send second information to the network device, and the second information is used to indicate that the first terminal device prefers to receive the multicast data in the first state.

[0352] In one possible implementation, when the apparatus 1000 is used to execute the method executed by the first terminal device in any of the aforementioned embodiments, the apparatus 1000 includes a processing unit 1001 and a transceiver unit 1002; the processing unit 1001 is used to determine capability information and / or preference information; wherein, the capability information indicates that the first terminal device supports receiving multicast data in a first state, and the preference information is used to indicate that the first terminal device prefers to receive multicast data in a first state; wherein, the first state includes a radio resource control RRC connected state or an RRC inactive state; the transceiver unit 1002 is used to send the capability information and / or the preference information.

[0353] In one possible implementation, when the device 1000 is used to execute the method executed by the network device in any of the aforementioned embodiments, the device 1000 includes a processing unit 1001 and a transceiver unit 1002; the transceiver unit 1002 is used to receive second information; the processing unit 1001 is used to determine, based on the second information, that the first terminal device prefers to receive multicast data in a first state; wherein the first state includes a radio resource control RRC connected state or an RRC inactive state; the transceiver unit 1002 is also used to send the multicast data to the first terminal device according to the second information.

[0354] It should be noted that, for details of the information execution process and other contents of the units of the above-mentioned communication device 1000, please refer to the description in the method embodiment shown above in this application, and will not be repeated here.

[0355] Please refer to Fig. 11, which is another schematic structural diagram of a communication device 1100 provided in this application. The communication device 1100 at least includes an input and output interface 1102. The communication device 1100 may be a chip or an integrated circuit.

[0356] Optionally, the communication device further includes a logic circuit 1101 .

[0357] The transceiver unit 1002 shown in FIG10 may be a communication interface, which may be the input / output interface 1102 in FIG11 , which may include an input interface and an output interface. Alternatively, the communication interface may be a transceiver circuit, which may include an input interface circuit and an output interface circuit.

[0358] Optionally, logic circuit 1101 is configured to determine, based on the first information, that the first terminal device prefers to receive multicast data in a first state; wherein the first state includes a radio resource control (RRC) connected state or an RRC inactive state; and input / output interface 1102 is configured to send second information to the network device, the second information being configured to indicate that the first terminal device prefers to receive the multicast data in the first state. Logic circuit 1101 and input / output interface 1102 may also perform other steps performed by the first device in any of the aforementioned embodiments and achieve corresponding beneficial effects, which will not be further described herein.

[0359] Optionally, the logic circuit 1101 is used to determine capability information and / or preference information; wherein, the capability information indicates that the first terminal device supports receiving multicast data in a first state, and the preference information indicates that the first terminal device prefers to receive multicast data in the first state; wherein, the first state includes a radio resource control RRC connected state or an RRC inactive state; and the input / output interface 1102 is used to send the capability information and / or the preference information. The logic circuit 1101 and the input / output interface 1102 may also execute other steps executed by the first terminal device in any of the aforementioned embodiments and achieve corresponding beneficial effects, which will not be repeated here.

[0360] Optionally, the input / output interface 1102 is configured to receive second information; the logic circuit 1101 is configured to determine a user plane unit; the input / output interface 1102 is configured to determine, based on the second information, that the first terminal device prefers to receive multicast data in a first state; wherein the first state includes a radio resource control (RRC) connected state or an RRC inactive state; and the input / output interface 1102 is further configured to send the multicast data to the first terminal device based on the second information. The logic circuit 1101 and the input / output interface 1102 may also perform other steps performed by the network device in any of the aforementioned embodiments and achieve corresponding beneficial effects, which will not be further described herein.

[0361] In a possible implementation, the processing unit 1001 shown in FIG10 may be the logic circuit 1101 in FIG11 .

[0362] Optionally, the logic circuit 1101 may be a processing device, and the functions of the processing device may be partially or entirely implemented by software. The functions of the processing device may be partially or entirely implemented by software.

[0363] Optionally, the processing device may include a memory and a processor, wherein the memory is used to store a computer program, and the processor reads and executes the computer program stored in the memory to perform corresponding processing and / or steps in any one of the method embodiments.

[0364] Alternatively, the processing device may include only a processor. A memory for storing the computer program is located outside the processing device, and the processor is connected to the memory via circuits / wires to read and execute the computer program stored in the memory. The memory and processor may be integrated or physically separate.

[0365] Optionally, the processing device may be one or more chips, or one or more integrated circuits. For example, the processing device may be one or more field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), system-on-chips (SoCs), central processor units (CPUs), network processors (NPs), digital signal processors (DSPs), microcontroller units (MCUs), programmable logic devices (PLDs), or other integrated chips, or any combination of the above chips or processors.

[0366] Please refer to Figure 12, which is a schematic diagram of the structure of the communication device involved in the above embodiments provided in the embodiments of the present application. The communication device 1200 can specifically be the first terminal device, first device, or network device in each of the above method embodiments, or can be a chip or system-on-chip located in the first terminal device, first device, or network device. The structure of the communication device can refer to the structure shown in Figure 12.

[0367] The communication device 1200 includes at least one processor 1211. Furthermore, the communication device may also include at least one memory 1212.

[0368] The memory is mainly used to store software programs and data. The memory 1212 can be independent and connected to the processor 1211.

[0369] Optionally, the memory 1212 may be integrated with the processor 1211, for example, integrated into a single chip. The memory 1212 is used to store program codes for executing the solutions of the embodiments of the present application.

[0370] The processor 1211 is used to read the program code in the memory 1212 to implement the relevant functions of the first terminal device, the first device or the network device in the above-mentioned method embodiments.

[0371] Figure 12 shows only one memory and one processor. In an actual first terminal device, first device, or network device, there may be multiple processors and multiple memories. Memory may also be referred to as a storage medium or storage device. The memory may be a storage element on the same chip as the processor, i.e., an on-chip storage element, or an independent storage element, which is not limited in the present embodiment.

[0372] An embodiment of the present application also provides a computer-readable storage medium, which is used to store one or more computer-executable instructions. When the computer-executable instructions are executed by a processor, the processor executes the method described in the possible implementation methods of the first device, first terminal device or network device in the aforementioned embodiment.

[0373] An embodiment of the present application also provides a computer program product (or computer program). When the computer program product is executed by the processor, the processor executes the method of the possible implementation mode of the above-mentioned first device, first terminal device or network device.

[0374] An embodiment of the present application also provides a chip system, which includes at least one processor for supporting a communication device to implement the functions involved in the possible implementation methods of the above-mentioned communication device. Optionally, the chip system also includes an interface circuit, which provides program instructions and / or data to the at least one processor. In one possible design, the chip system may also include a memory, which is used to store the necessary program instructions and data for the communication device. The chip system can be composed of chips, or it can include chips and other discrete devices, wherein the communication device can specifically be the first device, the first terminal device or the network device in the aforementioned method embodiment.

[0375] The embodiment of the present application further provides a communication system, wherein the network system architecture includes the first device and the network device in any of the above embodiments, and further includes the first terminal device in any of the above embodiments.

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

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

[0378] In addition, the functional units in the various embodiments of the present application can be integrated into a processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional unit. If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the solution of the present application is essentially or the contributing part or all or part of the solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in the various embodiments of the present application. The aforementioned storage medium includes various media that can store program code, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

Claims

1. A communication method, characterized in that: include: Determine, according to the first information, that the first terminal device prefers to receive multicast data in a first state; wherein the first state includes a radio resource control RRC connected state or an RRC inactive state; Sending second information to the network device, wherein the second information is used to indicate that the first terminal device prefers to receive the multicast data in the first state.

2. The method according to claim 1, characterized in that The first information includes at least one of the following: Capability information of the first terminal device, the capability information indicating that the first terminal device supports receiving multicast data in the RRC inactive state; Preference information of the first terminal device, the preference information indicating that the first terminal device prefers to receive multicast data in the first state; The multicast role of the first terminal device in the group corresponding to the multicast data; the location of the first terminal device; the number of groups in which the first terminal device participates; The number of multicast sessions that the first terminal device has joined; reception quality information of the first terminal device for a first multicast session, the first multicast session being used to transmit the multicast data; A service communication model of the first terminal device; and One or more speech right request messages from the first terminal device.

3. The method according to claim 2, characterized in that The first information includes capability information of the first terminal device, and determining, according to the first information, that the first terminal device prefers to receive multicast data in the first state includes: When the capability information indicates that the first terminal device supports receiving multicast data in the RRC inactive state, determining that the first terminal device prefers to receive the multicast data in the RRC inactive state; or, When the capability information indicates that the first terminal device does not support receiving multicast data in the RRC inactive state, it is determined that the first terminal device prefers to receive the multicast data under the RRC connection.

4. The method according to claim 2 or 3, characterized in that: The first information includes preference information of the first terminal device, and determining, according to the first information, that the first terminal device prefers to receive multicast data in the first state includes: When the preference information indicates that the first terminal device prefers to receive the multicast data in the RRC connected state, determining that the first terminal device prefers to receive the multicast data in the RRC connected state; or, When the preference information indicates that the first terminal device prefers to receive the multicast data in the RRC inactive state, it is determined that the first terminal device prefers to receive the multicast data in the RRC inactive state.

5. The method according to any one of claims 2 to 4, characterized in that: The first information includes a service communication model of the first terminal device, and determining, according to the first information, that the first terminal device prefers to receive multicast data in the first state includes: When the service communication model of the first terminal device indicates frequent uplink, determining that the first terminal device prefers to receive the multicast data in the RRC connection state; or, When the service communication model of the first terminal device indicates downlink only, it is determined that the first terminal device prefers to receive the multicast data in the RRC inactive state.

6. The method according to any one of claims 2 to 5, characterized in that: The first information includes one or more speech right request messages from the first terminal device, and determining, according to the first information, that the first terminal device prefers to receive multicast data in the first state includes: When the total amount of the one or more speaking right request messages exceeds a first threshold and / or the frequency of the one or more speaking right request messages exceeds a second threshold, it is determined that the first terminal device prefers to receive the multicast data in the RRC connection state.

7. The method according to any one of claims 2 to 6, characterized in that: The first information also includes priority information corresponding to the at least one item.

8. The method according to any one of claims 1 to 7, characterized in that: The multicast data is multicast data of the first multicast session.

9. The method according to any one of claims 2 to 8, characterized in that: The capability information and the preference information come from a critical business service client MC service client, and the MC service client is deployed on the first terminal device.

10. The method according to claim 9, characterized in that The method further comprises: receiving a first message from the MC service client, where the first message carries the capability information and / or the preference information; The first message is a critical business service registration message, an emergency business service registration request message, a user equipment UE session joining notification message, or a multicast broadcast service session monitoring status report message.

11. The method according to any one of claims 2 to 8, characterized in that: The capability information and / or the preference information comes from a network resource management client NRM client, a service application server VAS, or a group management server GMS, and the NRM client is deployed on the first terminal device.

12. The method according to claim 11, characterized in that The method further comprises: Receive a second message from the NRM client, the second message carrying the capability information and / or the preference information, wherein the second message is an NRM registration request message, an emergency service registration request message, a UE session join notification message, or a multicast broadcast service session monitoring status report message.

13. The method according to any one of claims 1 to 12, characterized in that: The multicast data is multicast data of the first multicast session, and the sending of the second information to the network device includes: When at least one of the following is satisfied, sending the second information to the network device comprises: The session identifier of the first multicast session has been determined, and the first multicast session has not been created; The first multicast session has been created, and the first terminal device has not yet joined the first multicast session; The first multicast session has been created, and the first terminal device has joined the first multicast session; The first multicast session has been created, the first terminal device has joined the first multicast session, and an association between the first multicast session and the group has been sent to the first terminal device.

14. The method according to any one of claims 1 to 13, characterized in that: The second information is also used to instruct other terminal devices in the multicast group to which the first terminal device belongs to receive the first multicast data in the first state.

15. The method according to any one of claims 1 to 14, characterized in that The second information is carried in multicast broadcast service assistance information MBS assistance information.

16. A communication method, characterized in that: include: Determine capability information and / or preference information; wherein the capability information indicates that the first terminal device supports receiving multicast data in a first state, and the preference information indicates that the first terminal device prefers to receive multicast data in the first state; wherein the first state includes a radio resource control RRC connected state or an RRC inactive state; The capability information and / or the preference information is sent.

17. The method according to claim 16, characterized in that The capability information and / or the preference information is carried in a key business service registration message, an emergency business service registration request message, a UE session join notification message, or a multicast broadcast service session monitoring status report message.

18. A communication device, characterized in that: including a transceiver unit and a processing unit; Wherein, the transceiver unit and the processing unit are used to execute the method according to any one of claims 1 to 17.

19. A communication device, characterized in that: The method comprises at least one processor coupled to a memory; the at least one processor is configured to execute the method according to any one of claims 1 to 17.

20. A readable storage medium, characterized in that: The storage medium stores a computer program or an instruction, and when the computer program or the instruction is executed by the communication device, the method according to any one of claims 1 to 17 is implemented.

21. A communication system, characterized in that: include: A first communication device and a network device; The first communication device is used to perform the method according to any one of claims 1 to 15; The network device is used to receive the second information.

22. The communication system according to claim 21, characterized in that The communication system further comprises a second communication device, wherein the second communication device is configured to perform the method according to claim 16 or 17.

Images