Communication method and related equipment

Abstract

The invention provides a communication method and related equipment, which are used for improving the success rate of receiving multicast data by terminal equipment, can improve the number of users of multicast session service, and can improve the number of multicast session users which can be served by a single cell at the same time. In the method, a first device determines that a first terminal device preferentially receives multicast data in a first state according to first information; wherein the first state comprises a radio resource control (RRC) connection (RRC CONNECTED) state or a radio resource control (RRC) inactive (RRC INACTIVE) state, and the first state comprises a radio resource control (RRC) connection (RRC CONNECTED) state or a radio resource control (RRC) inactive (RRC INACTIVE) state; and the first equipment sends second information to network equipment, wherein the second information is used for indicating that the first terminal equipment preferentially receives the multicast data in the first state.

Description

Technical Field

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

[0002] In a communication system, different communication devices can communicate with each other in a variety of ways, such as broadcast, multicast or unicast, etc. Among them, multicast can refer to a communication technology that sends a copy of data to a specific group of devices.

[0003] At present, in the process of multicast communication, the provider of multicast data (i.e., the multicast source) can send a data packet once so that two or more receivers in a group (or multicast group, multicast group, etc.) receive the data packet, thereby improving the utilization rate of bandwidth resources. Generally, a terminal device can serve as a receiver in a multicast group and receive multicast data from a multicast source through a network device.

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

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

[0006] 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 a 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.

[0007] Based on the above scheme, after the first device determines that the first terminal device prefers to receive multicast data in the first state according to the first information, the first device sends the 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 connection 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 connection 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 receiving 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 scheme, the first device can determine the second information according to 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.

[0008] It should be understood that the first device can be a server or a logical network element that provides multicast data transmission control (or provides multicast services). For example, the first device can be a server or a logical network element with an application function (AF) having 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.

[0009] It should be understood that in the above scheme, the recipient of the second information sent by the first device can be a network device, and the network device can be a network device connected to the first terminal device, or the network device can be a device that provides network services for the first terminal device. For example, the network device can include an access network device and / or a core network device, etc. Taking the network device including an access network device and a core network device (for example) as an 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 of 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 element, and at this time, the first device can also send the second information to the UDM or UDR network element through the network exposure function (NEF) network element.

[0010] 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.

[0011] Based on the above scheme, the second information is also used to indicate that other terminal devices in the multicast group to which the first terminal device belongs receive the first multicast data in the first state, so that the above scheme can implement the preference setting for the first state of receiving multicast data by the terminal devices included in the multicast group to reduce overhead.

[0012] 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.

[0013] Optionally, in the above scheme, the second information sent by the first device to the network device 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.

[0014] Optionally, in the above scheme, the second information sent by the first device to the network device may include multiple pieces of information, and the multiple pieces of information respectively indicate that the terminal devices in different multicast sessions prefer to receive the multicast data in the first state, and the terminal devices of one of the multicast sessions in the different multicast sessions 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 the second information, and through the 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, in the case where 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 parts corresponding to several multicast sessions in the multiple pieces of information to the access network device, or the core network device may also send all of the multiple pieces of information to the access network device, which is not limited here.

[0015] It should be noted that, in different connection states, the terminal device may process multicast data differently. For example, when the first terminal device is in an RRC connected state, when the first terminal device receives multicast data from the channel indicated by the multicast multicast radio bearer configuration, a hybrid automatic repeat qequest (HARQ) feedback may be provided. If datagram loss occurs, the access network device may perform point-to-point (PTP) retransmission. When the first terminal device is in an 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 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.

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

[0017] 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;

[0018] 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;

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

[0020] The location of the first terminal device;

[0021] the number of multicast groups participated in by the first terminal device;

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

[0023] 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;

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

[0025] One or more speech right request messages from the first terminal device.

[0026] 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 by a combination of one or more of the above to enhance the flexibility of the scheme implementation.

[0027] 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 in the RRC connection state to receive, 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).

[0028] 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.

[0029] 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.

[0030] 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.

[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 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.

[0032] In a possible implementation of the first aspect, the first information includes a 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 a 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.

[0033] 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.

[0034] In a possible implementation of the first aspect, the first information includes one or more right-of-voice 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 a first state, including: when the total amount of the 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 device determines that the first terminal device prefers to receive the multicast data in the RRC connection 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 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. 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.

[0036] In a possible implementation manner of the first aspect, the first information also includes priority information corresponding to the at least one item mentioned above.

[0037] 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 item, so that when the first information includes two or more of the 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 a 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.

[0038] 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.

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

[0040] 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.

[0041] 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.

[0042] 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.

[0043] In a possible implementation of the first aspect, the method also includes: the first device receives a first message from the MCservice client, and the first message 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 user equipment (UE) session join notification message, or a multicast broadcast service session monitoring status report message.

[0044] Based on the above scheme, when the capability information and the preference information can come from the MCservice 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.

[0045] 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.

[0046] 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 multiple implementation methods for the first device to obtain the capability information and / or the preference information.

[0047] In a possible implementation of the first aspect, the method also includes: the first device receives a second message from the NRMclient, 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.

[0048] Based on the above scheme, when the capability information and the preference information can come from the NRMclient 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.

[0049] In a possible implementation manner 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 is satisfied, the first device sending the second information to the network device includes:

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

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

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

[0053] 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.

[0054] Based on the above scheme, the multicast data of the first terminal device can be the multicast data of a certain multicast session (such as 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 scheme implementation.

[0055] 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.

[0056] Optionally, for the first device, after the first device sends a response message of 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 created. The response message may be a response message of successful session establishment of a multicast broadcast service auxiliary information (multicast and broadcast service, MBS). Accordingly, for the first device, before the first device sends the response message, it may be determined that the first multicast session has not been created.

[0057] 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 can determine that the first terminal device has joined the first multicast session, and the indication information is used to indicate that the first terminal device and the network device have executed the MBS session joining process. Correspondingly, before the first device receives the indication information, the first device can determine that the first terminal device has not yet joined the first multicast session.

[0058] 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, 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 terminal device functions. In the second aspect and its possible implementation, the method is described as being executed by a first terminal device. In the 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 a 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.

[0059] 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. Among them, 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 a different way 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, the number of multicast session users that can be served by a single cell can be increased. 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 receiving the multicast data.

[0060] In a possible implementation manner 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.

[0061] 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 implementation of the solution.

[0062] 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, 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 network device functions. In the first aspect and its possible implementation, the method is described as being executed by a network device. In the 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.

[0063] 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, 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 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.

[0064] In a fourth aspect of the present application, a communication device is provided, which is a first device, or the device is a partial component in the first device (such as a processor, a chip or a chip system, etc.), or the device can also be a logic module or software that can implement all or part of the functions of the first device. In the seventh aspect and its possible implementation, the communication device is described as a first device, and the first device can be a terminal device or a network device.

[0065] 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 a 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.

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

[0067] 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;

[0068] 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;

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

[0070] The location of the first terminal device;

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

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

[0073] 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;

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

[0075] One or more speech right request messages from the first terminal device.

[0076] 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.

[0077] 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.

[0078] In a possible implementation of the fourth aspect, the first information includes a 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.

[0079] In a possible implementation of the fourth aspect, the first information includes one or more right-of-voice 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-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 processing unit determines that the first terminal device prefers to receive the multicast data in the RRC connection state.

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

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

[0082] In a possible implementation of the fourth aspect, the transceiver unit is also used to receive a first message from the MC serviceclient, and the first message 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.

[0083] 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.

[0084] 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.

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

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

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

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

[0089] 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.

[0090] 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.

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

[0092] 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.

[0093] In a fifth aspect of the present application, a communication device is provided, which is a terminal device, or the device is a partial component in the terminal device (such as a processor, a chip or a chip system, etc.), or the device can also be a logic module or software that can implement all or part of the functions of the terminal device. In the fifth aspect and its possible implementation, the communication device is described as an example of executing the terminal device.

[0094] 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.

[0095] 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.

[0096] In the fifth 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 second aspect and achieve corresponding technical effects. For details, please refer to the second aspect and will not be repeated here.

[0097] In a sixth aspect of the present application, a communication device is provided, which is a network device, or the device is a partial component in the network device (such as a processor, a chip or a chip system, etc.), or the device can also be a logic module or software that can implement all or part of the network device functions. In the sixth aspect and its possible implementation, the communication device is described as an example of a network device.

[0098] 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.

[0099] In the sixth 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 third aspect and achieve corresponding technical effects. For details, please refer to the third aspect and will not be repeated here.

[0100] A seventh aspect of an embodiment of the present application provides a communication device, comprising at least one processor, wherein the at least one processor 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.

[0101] An eighth aspect of an embodiment of the present application provides a communication device, comprising at least one processor, wherein the at least one processor 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.

[0102] A ninth aspect of an embodiment of the present application provides a communication device, comprising at least one processor, wherein the at least one processor 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.

[0103] In a tenth aspect, an embodiment of the present application provides a communication device, including 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 method of the first aspect.

[0104] In an eleventh aspect of an embodiment of the present application, a communication device is provided, including 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 method of the second aspect.

[0105] A twelfth aspect of an embodiment of the present application provides a communication device, including 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 method of the third aspect.

[0106] 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 a method as described in any possible implementation of any one of the first to third aspects above.

[0107] 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.

[0108] 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.

[0109] In one possible design, the chip system may also 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 devices. Optionally, the chip system also includes an interface circuit for providing program instructions and / or data to the at least one processor.

[0110] 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.

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

[0112] Figure 1 A schematic diagram of a communication system involved in this application;

[0113] Figure 2 Another schematic diagram of the communication system involved in this application;

[0114] Figure 3 Another schematic diagram of the communication system involved in this application;

[0115] Figure 4a A schematic diagram of the multicast communication process involved in this application;

[0116] Figure 4b Another schematic diagram of the multicast communication process involved in this application;

[0117] Figure 4c Another schematic diagram of the multicast communication process involved in this application;

[0118] Figure 5 Another schematic diagram of the multicast communication process involved in this application;

[0119] Figure 6a Another schematic diagram of the multicast communication process involved in this application;

[0120] Figure 6b Another schematic diagram of the multicast communication process involved in this application;

[0121] Figure 6c Another schematic diagram of the multicast communication process involved in this application;

[0122] Figure 7 A schematic diagram of the communication method provided by the present application;

[0123] Figure 8 Another schematic diagram of the communication method provided by the present application;

[0124] Fig. 9 Another schematic diagram of the communication method provided by the present application;

[0125] Fig.10 A schematic diagram of a communication device provided for this application;

[0126] Fig.11 Another schematic diagram of a communication device provided by the present application;

[0127] Fig.12 Another schematic diagram of a communication device provided by the present application. DETAILED DESCRIPTION

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

[0129] (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 users, or a handheld device with wireless connection function, or other processing devices connected to a wireless modem.

[0130] The terminal device can communicate with one or more core networks or the Internet via a radio access network (RAN). The terminal device can be a mobile terminal device, such as a mobile phone (or "cellular" phone, mobile phone), a computer and a data card. For example, it can be a portable, pocket-sized, handheld, computer-built-in or vehicle-mounted mobile device that exchanges language and / or data with the radio access network. For example, personal communication service (PCS) phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), tablet computers (Pads), computers with wireless transceiver functions, and other devices. The 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), a drone, etc. The terminal device may also be a wearable device and 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), etc.

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

[0132] In an implementation example, the access network device in the network device can be a radio access network (RAN) node (or device) that connects the terminal device to the wireless network, which can also be called a base station. At present, some examples of RAN devices are: a new generation base station (generation Node B, gNodeB) in a 5G communication system, a transmission reception point (transmission reception point, TRP), an evolved Node B (evolved Node B, eNB), a radio network controller (radio network controller, RNC), a Node B (Node B, NB), a base station controller (base station controller, BSC), a base transceiver station (base transceiver station, BTS), a home base station (for example, home evolved Node B, or home Node B, HNB), a base band unit (base band unit, BBU), or a wireless fidelity (wireless fidelity, Wi-Fi) access point (access point, AP), etc. In addition, in a network structure, the access network device may include a centralized unit (CU) node, a distributed unit (DU) node, or a RAN device including 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.

[0133] 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 according to the configuration information, so that the network configuration between the access network device and the terminal device is aligned; or, through the network configuration preset in the access network device and the network configuration preset in the terminal device, the network configuration between the access network device and the terminal device is aligned. Specifically, "alignment" means that when there is an interactive message between the network device and the terminal device, the two have a consistent understanding of the carrier frequency for sending and receiving the interactive message, 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.

[0134] 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 the present application do not limit the specific technology and specific device form used by the network device. For the convenience of description, the embodiments of the present application do not limit.

[0135] In an implementation example, the core network device may be a physical network element or a logical network element included in the core network (CN) part of the mobile communication system. Generally, the core network device can connect the terminal device 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 function may be different.

[0136] In the embodiments of the present application, the device for implementing the function of the network device may be a 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 scheme provided in the embodiments of the present application, the scheme provided in the embodiments of the present application is described by taking the device for implementing the function of the network device as a network device as an example.

[0137] (3) Configuration and pre-configuration: In this application, configuration and pre-configuration are used at the same time. 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, or 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.

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

[0139] (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 "plurality" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: the existence of A alone, the existence of A and B at the same time, and the existence of B alone, where A and B can be singular or plural. The character " / " generally indicates that the objects associated with each other are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, "at least one of A, B and C" includes A, B, C, AB, AC, BC or ABC. And, 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.

[0140] 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).

[0141] 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.

[0142] To facilitate understanding of the method provided in the embodiment of the present application, the system architecture of the method provided in the embodiment of the present application is described below. It is understandable that the system architecture described in the embodiment of the present application is to more clearly illustrate the solution of the embodiment of the present application, and does not constitute a limitation on the solution provided in the embodiment of the present application.

[0143] See also Figure 1 , is a schematic diagram of a communication system provided in an embodiment of the present application. Figure 1 As shown, the configuration information sending entity may be a network device, wherein the configuration information receiving entity may be UE1-UE6. At this time, the network device and UE1-UE6 form a communication system, in which 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.

[0144] See also Figure 2 , is another schematic diagram of a communication system provided in an embodiment of the present application. Figure 2As shown, 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.

[0145] As Figure 2 An implementation example of the communication system shown in FIG. 1 may be a 5G network system. Figure 3 As shown, Figure 2 The terminal device 100 may include Figure 3 UE301 in Figure 2 The access network device 201 may include Figure 3 RAN302 in Figure 2 The core network device 202 may include Figure 3 One or more of the following logical network elements: 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.

[0146] The following are the Figure 3 Introduce the equipment or network elements involved.

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

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

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

[0150] SMF306 is mainly 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 UPFs that provide message forwarding functions.

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

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

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

[0154] For example, in Figure 3 In the present invention, UE301 can establish a session (eg, a protocol data unit session (PDU session)) between UE301, RAN302, UPF303 and DN304, and access DN304 through the session.

[0155] In communication systems (such as Figure 1 , Figure 2 or Figure 3 In the communication system shown in FIG. 1 , different communication devices can communicate with each other in a variety of ways, such as broadcast, multicast or unicast. Currently, in the multicast communication process, the provider of multicast data (i.e., the multicast source) can send a data packet once so that two or more receivers in the multicast group (or multicast group) receive the data packet, thereby improving the utilization rate of bandwidth resources. Generally, a terminal device can serve as a receiver in a multicast group and receive multicast data from a multicast source through a network device.

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

[0157] like Figure 4a As shown, compared to Figure 3In the network architecture shown in the figure, the network elements that may be involved in the multicast process also include network repository function (NRF) network element, multicast and broadcast session management function (MB-SMF, M-SMF for short) network element, multicast and broadcast user plane function (MB-UPF, M-UPF for short) network element, multicast and broadcast service function (MBSF), multicast and broadcast service transport function (MBSTF), etc. Among them, the interfaces between different network elements are as follows: Figure 4a shown.

[0158] As an implementation example, Figure 4a The functions of each network element specific to multicast or broadcast are as follows:

[0159] 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: quality of service (QoS) processing of multicast and broadcast service session (MBS session); providing policy information to MB-SMF; interacting with UDR to obtain QoS information, etc.

[0160] MB-SMF: is an entity that supports broadcast features and can also have the functional role of unicast SMF. Specifically, MB-SMF is responsible for: MBS session management, including QoS control; configuring MB-UPF; interacting with RAN to control broadcast flow transmission (broadcast session specific function); interacting with SMF to associate PDU session; interacting with RAN to control multicast flow transmission (multicast session specific function), etc.

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

[0162] MB-UPF: It is the data plane gateway of 5G MBS. It 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.

[0163] 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.

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

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

[0166] UE: Main functions are: 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); terminal-side resource management of 5G multicast and broadcast service (5MBS), etc.

[0167] MBSF: It is an optional network element. It mainly supports the following functions: service layer functions, and interworking with multimedia broadcast multicast service (MBMS); interacting with AF and MB-SMF to support the operation of MBS session, determine the transmission parameters and the type of MBS session; select MB-SMF; control MBSTF; determine the sender's Internet Protocol (IP) multicast address, etc.

[0168] MBSTF: It is an optional network element that mainly supports the following functions: anchor point for MBS data; serving as the source of Internet Protocol multicast (IPmulticast); supporting common transmission functions such as frames, multi-streams, and forward error correction (FEC); sending input files as objects or object flows in multicast or broadcast mode, etc.

[0169] 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 5GC, etc.

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

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

[0172] Figure 4a The network architecture shown in the figure can be used to implement unicast-based multicast technology. The unicast-based multicast technology aims to solve the problem of how to further save network resources on the basis of reusing unicast processes as much as possible, that is, the user plane network element selects one copy of the data stream with the same content sent to different UEs in the group (from UPF to AN), thereby improving the efficiency of the use of air interface side and core network resources. For its basic idea, please refer to Figure 4b The process shown includes the following description.

[0173] In an implementation example, the unicast-based multicast technology can consider the data path processing between MB-UPF, AN and UE. For the data packets between AS and MB-UPF, it can be a multicast application data packet of a single user equipment (per UE), a unicast data packet of per UE, or a multicast data packet of multicast transmission, without limitation. The application data packets from MB-UPF to AN to UE or AN to UE are all multicast data packets with the same content (the destination IP is a multicast address). Among them, the 5G MBS multicast session supports the following two modes of transmission methods: individual delivery mode and shared delivery mode.

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

[0175] For example, Figure 4c As shown in Figure 1, Individual delivery mode is a solution when the base station where the UE resides does not support MBS capabilities, that is, Figure 4c The specific transmission path for the multicast data of UE d is: the path between MB-UPF, UPF with unicast capability, RAN 2 and UE d. Since the data on the RAN side actually comes from the unicast UPF, it is unicast data in the eyes of RAN2.

[0176] In addition, 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 of a certain multicast service. At the same time, the session management network element MB-SMF that manages this MB-UPF network element will be selected. For ease of understanding, the following briefly describes the joining process of unicast-based multicast technology:

[0177] 1. The UE sends a join request to the SMF through 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, and the session information may be an MBS sessionId).

[0178] 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 context information corresponding to the multicast based on the multicast information, and optionally, the corresponding unicast QoS Flow information. The corresponding 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 provide the corresponding unicast QoS Flow to the base station in advance, which can better ensure service continuity during switching.

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

[0180] As an implementation example, the process of using multicast service by application service is as follows: Figure 5 As shown, the process includes the following steps.

[0181] 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.

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

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

[0184] 4. Data Transfer, that is, downlink multicast data is transmitted to UE.

[0185] 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.

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

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

[0188] As another implementation example, Figure 6b It is an implementation method of the application layer architecture and functional model based on the 5MBS architecture. Figure 6b In the MC service server, 5GC can interact with each other in various ways, such as through NEF network elements, MBSF network elements, or MBSTF network elements. Figure 6b In the information related to mission critical everything (MCX for short) may include one or more of mission critical push to talk (MCPTT), mission critical video (MCVideo), and mission critical data (MCData).

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

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

[0191] Among them, MC service client can be a software function module of the terminal device, located on the operating system, supporting SIP registration of cluster services, service authentication and authorization, group call, single call, emergency call, media speaking right, media data processing, etc. The above functions can be implemented using session initialization 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 of broadcast multicast reception quality and reports broadcast multicast reception quality information to the MC service server; after successfully joining the multicast MBS session (multicastMBS session), reports to the MC service server the information that the UE has successfully joined the MBS session.

[0192] In addition, the MC service server is a peer-to-peer server-side function of the MC service client. It supports receiving the SIP registration of the MC service client, service authorization, and is responsible for managing services such as group calls, single calls, and emergency calls. It is responsible for the management and adjudication of voice rights and the distribution of media data. In terms of supporting 5MBS, it interacts with the core network to create MBS sessions; it supports the peer-to-peer capabilities of the UE side, that is, it sends service / sessionannouncement messages to the MC service client, which contain information about the MBS session (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; it refers to the UE's reported information to decide whether to send data to the MBS session.

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

[0194] 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 on 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, messages, and data exchanges between the NRM client and NRM server. For example, Figure 6c It is a functional model using the 5MBS architecture based on the service enabler application layer (SEAL) model.

[0195] In the above multicast communication process, the terminal device, as a multicast receiver, can receive multicast data through the network device. Among them, since the terminal device may be in different connection states, and in different connection states (such as RRC connection 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 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.

[0196] 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.

[0197] However, in the above implementation, 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.

[0198] In order 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.

[0199] See also Figure 7 , is a schematic diagram of an implementation of the communication method provided in this application, and the method includes the following steps.

[0200] It should be noted that Figure 7 In the example, the first device, the first terminal device and the network device are used as the execution subjects of the interaction diagram to illustrate the method, but the present application does not limit the execution subjects of the interaction diagram. Figure 7 In the corresponding implementation method, the execution subject of S701, S702 and S703a is the first device. The execution subject may also be a chip, a chip system, or a 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. Figure 7 The network devices in S702, S703a, and S703b in the corresponding implementation method can also be replaced by a chip, a chip system, or a processor that supports the network device to implement the method, and can also be replaced by a logic module or software that can implement all or part of the network device functions. Figure 7 The first terminal device in S703b in the corresponding implementation method can also be replaced by a chip, a chip system, or a processor that supports the first terminal device to implement the method, and can also be replaced by a logic module or software that can implement all or part of the functions of the first terminal device.

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

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

[0203] 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.

[0204] It should be noted that, in different connection states, the processing method of receiving multicast data by the terminal device may be different. 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 can be provided. If data packet loss occurs, the access network device can perform point-to-point (PTP) retransmission. It should be understood that the HARQ feedback can 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.

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

[0206] 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.

[0207] 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.

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

[0209] Information D. Location of the first terminal device.

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

[0211] Information F: The number of multicast sessions that the first terminal device has joined.

[0212] 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.

[0213] Information G. Reception quality information of the first terminal device for the first multicast session, the first multicast session being 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).

[0214] Information H. Business communication model of the first terminal device.

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

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

[0217] 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.

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

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

[0220] 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 scheme 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, and saving transmission resources to improve communication efficiency. Moreover, after such a setting, system resources can be more fully utilized, the number of users that can be served by a multicast session can be increased, and the number of users that can be served by a single cell can be increased, so as to enhance the overall service experience and the user experience of a single terminal device (such as the first terminal device).

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

[0222] 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, 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, the first device determines that the first terminal device prefers to receive the multicast data in the RRC connection. Thus, 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 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.

[0223] 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 the multicast data.

[0224] 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.

[0225] 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 connected state, so that the first terminal device can use the RRC connection to quickly transmit data in the RRC connected 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 an RRC connected state or an 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.

[0226] 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 may 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 short 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 an RRC connected state or an 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.

[0227] 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 that the first terminal device prefers to receive the multicast data in the RRC connected state or the RRC inactive state based on the number of multicast groups in which the first terminal device participates, 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.

[0228] 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 that the first terminal device prefers to receive the multicast data in the RRC connected state or the RRC inactive state based on the number of multicast sessions that the first terminal device has joined, 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 that the first terminal device has joined.

[0229] 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, for which 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, for which 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.

[0230] 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 connected 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 connected 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.

[0231] 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 the 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 large 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 large uplink transmission demand of the first terminal device and reduce the power consumption and implementation complexity of the first terminal device.

[0232] Optionally, for information I, in addition to whether the total amount of the one or more right-to-speech request messages exceeds the first threshold and / or whether the frequency of the one or more right-to-speech request messages exceeds the second threshold as the basis for determining the first state, other statistical information of the one or more right-to-speech request messages may also be included, such as the time interval between any two right-to-speech 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.

[0233] 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.

[0234] 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, based on the combination, that the first terminal device prefers to receive multicast data in the first state. In this case, the first information also includes priority information corresponding to at least one of the above information A to information I. Specifically, the priority information may indicate the priority of the above at least one item, so that when the first information includes two or more of the above at least one item, the first device can select one of the items as the basis for determination according to the priority information, so as to avoid behavioral confusion caused by a contradiction between the two or more items, so that the first device can determine, based on the priority indicated by the priority information, that the first terminal device prefers to receive multicast data in the first state.

[0235] 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.

[0236] Optionally, in addition to the implementation of the above 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 state of the first terminal device. Accordingly, in step S701, for information J (the first information includes the state from the first terminal device), the first device determines that the first terminal device prefers to receive multicast data in the first state according to 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, in the case where the first information includes the state 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. 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.

[0237] In a possible implementation, the multicast data is the multicast data of the first multicast session. Specifically, the multicast data of the first terminal device can be the multicast data of a certain multicast session (e.g., the first multicast session), so that the first device can set the first state of the terminal device receiving the multicast data according to the granularity of the multicast session, so as to improve the reception success rate of the terminal device receiving the multicast data in the first multicast session.

[0238] In a possible implementation, the capability information and the preference information (i.e., the information A and / or information B above) come from an MC service client, and the MC service client 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, and accordingly, the first device may receive the capability information and the preference information from the MC service client through the MC service server, so that the above solution can be adapted to the communication scenario between the MC service client and the MC service server.

[0239] In a possible implementation, the method also includes: the first device receives a first message from the MC serviceclient, 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 MCservice client on the terminal device, or the message is used to indicate the registration of the terminal device deployed with the MC serviceclient), an emergency business service registration request message (the message is used to indicate the registration of the client by the MCservice client on the terminal device, or the message is used to indicate the registration of the terminal device deployed with the MC serviceclient), a UE session join notification message (the message is used to indicate that the terminal device has successfully joined the multicast and broadcast service (MBS) session), or a multicast and 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 may come from the MC service client in the first terminal device, the first device may obtain the capability information and / or the preference information through a first message, and the first message may be implemented through any of the above items to enhance the flexibility of the solution implementation.

[0240] In one possible implementation, the capability information and / or the preference information (i.e., the information A and / or information B 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 an NRM client, VAS, or GMS deployed on the first terminal device, so as to provide multiple implementations for the first device to obtain the capability information and / or the preference information.

[0241] In a possible implementation, the method also includes: the first device receives a second message from the NRM client, the second message carrying 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 is able to receive data of the MBS session, or the message is used to indicate the quality received by the terminal device in the MBS session, the level of reception quality, etc.). Specifically, when the capability information and the preference information may come from the NRMclient in the first terminal device, the first device may obtain the capability information and / or the preference information through a second message, and the second message may be implemented through any of the above items to enhance the flexibility of the solution implementation.

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

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

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

[0245] 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 for the first terminal device. The network device may include an access network device and / or a core network device, etc. For example, in the case where the network device includes an access network device, the first device may send the second information to the access network device via a link directly connected to the access network device or an indirect link connected to the access network device. For another example, in the case where the network device includes a core network device, the first device may send the second information to the core network device via a link directly connected to the core network device or an indirect link connected to the core network device. For another example, in the case where 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.

[0246] 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.

[0247] 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 through 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 through the NEF.

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

[0249] 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.

[0250] Optionally, the second information sent by the first device to the network device in step S702 may include information for indicating that the terminal devices in different multicast sessions prefer to receive the multicast data in the first state, and the terminal devices of one of the multicast sessions in the different multicast sessions 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 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, in the case where 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 parts corresponding to several multicast sessions in the multiple pieces of information to the access network device, or the core network device may also send all of the multiple pieces of information to the access network device, which is not limited here.

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

[0252] In a 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 is satisfied, the first device sending the second information to the network device includes:

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

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

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

[0256] 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.

[0257] 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 implementation of the solution.

[0258] 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.

[0259] Optionally, for the first device, after the first device sends a response message of 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 created. The response message may be a response message of successful session establishment of a multicast broadcast service auxiliary information (multicast and broadcast service, MBS). Accordingly, for the first device, before the first device sends the response message, it may be determined that the first multicast session has not been created.

[0260] 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 can determine that the first terminal device has joined the first multicast session, and the indication information is used to indicate that the first terminal device and the network device have executed the MBS session joining process. Correspondingly, before the first device receives the indication information, the first device can determine that the first terminal device has not yet joined the first multicast session.

[0261] 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) included 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 more, 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 MBSsession)) or a multicast group (group), and the granularity of the information is finer and the server settings are more accurate. In situation 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 in the group (e.g., the first terminal device and other terminal devices that may exist) (e.g., 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.

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

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

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

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

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

[0267] Exemplarily, the network device may include a core network device (such as UDM, UDR or MB-UPF, etc.) and an access network device. Among them, 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 certain 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 in step S703b (for example, switching from the connected state to the inactive state). 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.

[0268] 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.

[0269] based on Figure 7 In the scheme shown, after the first device determines that the first terminal device prefers to receive multicast data in the first state according to the first information, the first device sends the 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 the RRC connection state or the RRC inactive state. Among them, since the terminal device may be in different connection states, and in different connection states (such as the RRC connection state or the RRC inactive state), the processing method of the terminal device receiving multicast data may be different. Therefore, reasonably setting the connection state of the terminal device receiving 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 according to 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, and then the network device can schedule the first terminal device to receive the multicast data in the first state (such as the implementation process of step S703a and step S703b), thereby improving the success rate of the first terminal device receiving multicast data.

[0270] exist Figure 7In the illustrated solution, it can be seen from the description of cases A to C that, in the case where the first information includes capability information and / or preference information (i.e., information A and / or information B above), the first device may obtain the capability information and / or preference information at different times. Figure 8 and Fig. 9 The illustrated embodiments are described by way of example only.

[0271] See also Figure 8 ,for Figure 7 An application example of the communication method shown includes the following steps.

[0272] It should be noted that Figure 8 In the implementation shown, step S803 is an implementation example of the above step S701, step S804 is an implementation example of the above step S702, step S808 is an implementation example of the above step S703a, and step S809 is an implementation example of the above step S703b. Figure 8 The other steps are optional.

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

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

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

[0276] 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.

[0277] 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.

[0278] 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.

[0279] 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 speaks frequently and sends uplink data frequently) through the human-computer interaction interface.

[0280] Optionally, the client may also directly report the preference information or further translate the preference information into: preferring to keep the connected MBS session reception data to be reported to the first device.

[0281] In addition, the Client (such as MC service client / NRM client) deployed on the first terminal device 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 message, 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 exiting the system or shutting down the computer.

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

[0283] Exemplarily, when the client deployed on the first terminal device is the NRM client and the NRM server is deployed on the first device, the NRM server can also obtain the RRCinactive receiving MBS session data capability / preference information for receiving MBS data of a first terminal device / user from the VAS or GMS (preference to remain in a connected state to receive MBS session data), or receive the RRCinactive 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 a connected state.

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

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

[0286] Exemplarily, the first device interacts with the network device, executes the 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.

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

[0288] 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 to use (maintain) receiving multicast data in a connected state for session data of MBS session ID 1.

[0289] The first device determines that the first terminal device (bias / preference) remains (switches to) receiving 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.

[0290] 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 in multiple MBS session IDs of a terminal device. Specifically, the first device may set the multicast reception capability preference of a terminal device for multiple MBS session IDs to the same type (e.g., preference for connected state reception).

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

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

[0293] (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;

[0294] (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, and can also obtain the location information of the first terminal device from other first devices such as a location management server or a VAL server.

[0295] (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 participating in the first device (participating UE, 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.

[0296] (5) As the number of MBS sessions (simultaneously) participated by the first terminal device increases or exceeds a certain threshold, the first terminal device is set to remain in a connected state to receive MBS data; the first terminal device can be set to remain in a connected state to receive the multiple MBS session IDs. Specifically, the function of the MC service server at this time is participating in the first device (participating UE, a participating function defined in 3GPP 23.379 and 24.379). This statistical information can be statistically implemented after step S806c.

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

[0298] (7) When the NRM server is connected, it can also obtain the list of terminal devices that remain in a connected state to receive multicast session data per service (referred to as UE list) from the VAL server. The NRM server can combine the UE lists sent by multiple VAL servers to aggregate the situation in which each first terminal device's MBS session remains in a connected state to receive data, and then decide whether to change the first terminal device to remain in a 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 a connected state to receive data. That is, the NRM server can translate the information provided by the VAL into business requirements from network requirements.

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

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

[0301] 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 maintain connected users to receive multicast MBS data.

[0302] It should be understood that MBS refers to multicast and broadcast services, and multicast MBS may refer to multicast and broadcast services of a multicast type. Accordingly, MBS may also include a broadcast type multicast and broadcast service, which may be recorded as broadcastMBS.

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

[0304] 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.

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

[0306] 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.

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

[0308] 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.

[0309] 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.

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

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

[0312] 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.

[0313] 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 MCservice 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.

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

[0315] Exemplarily, the MC service server may send downlink media data to the network device (the 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 the downlink media data to the network device without passing through the NRM server.

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

[0317] Exemplarily, 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 instructs other terminal devices to use the RRC inactive state to receive.

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

[0319] Exemplarily, the subsequent MC sevice server may receive a floorrequest voice request sent by the MC service client, where the voice 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 that 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 NRMclient 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 to receive MBS data in the connected state. For detailed examples, please refer to the example in (7) of step 3 above.

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

[0321] Optionally, step S807a and step S807b may also occur before step S802, in which 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.

[0322] pass Figure 8 In the solution of the embodiment shown, the first device can reasonably select which first terminal devices prefer to be kept in the connected state for reception based on the actual business situation, 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 obtained by such setting will make the setting of the first terminal device more accurate, avoiding setting unreasonable / unnecessary first terminal devices in the connected state for reception, and wasting precious transmission resources of the system. After such setting, the system resources can be fully utilized, so that the overall business experience and the user experience of a single first terminal device are optimized.

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

[0324] 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 granularity is a single terminal device, so as to avoid signaling waste caused by multiple reports.

[0325] See also Fig. 9 ,for Figure 7 Another application example of the communication method includes the following steps.

[0326] It should be noted that Fig. 9 In the implementation shown, step S904 is an implementation example of the above step S701, step S905 is an implementation example of the above step S702, step S909 is an implementation example of the above step S703a, and step S909 is an implementation example of the above step S703b. Fig. 9 The other steps are optional.

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

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

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

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

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

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

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

[0334] 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.

[0335] 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).

[0336] It should be noted that Figure 8The difference of the illustrated embodiment is that the client deployed on the first terminal device carries the capability information and / or preference information in the report message of the first terminal device successfully joining the multicast session, or reports the capability information and / or preference information in the MBSsession listening status report message.

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

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

[0339] 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.

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

[0341] S906b. The first device sends a MapGroupToSessionStream message to the first terminal device, where the 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.

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

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

[0344] S909. The first terminal device sends one or more speech right request messages.

[0345] It should be noted that Fig. 9 The steps shown can refer to Figure 8 The implementation process shown is not described in detail here.

[0346] pass Fig. 9 In the solution of the embodiment shown, the first device can reasonably select which first terminal devices prefer to be kept in the connected state for reception based on the actual business situation, 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 obtained by such setting will make the setting of the first terminal device more accurate, avoiding setting unreasonable / unnecessary first terminal devices in the connected state for reception, and wasting precious transmission resources of the system. After such setting, the system resources can be fully utilized, so that the overall business experience and the user experience of a single first terminal device are optimized.

[0347] 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.

[0348] See also Fig.10 , the embodiment of the present application provides a communication device 1000, which can implement the functions of the first device, the first terminal device or the network device in the above method embodiment, and thus can also achieve the beneficial effects of the above method embodiment. Specifically, the communication device 1000 can be the first device, the first terminal device or the network device, or it can be an integrated circuit or component inside the first device, the first terminal device or the network device, such as a chip. The following embodiments are described by taking the communication device 1000 as the first device, the first terminal device or the network device as an example.

[0349] 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 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.

[0350] 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; and the transceiver unit 1002 is used to send the capability information and / or the preference information.

[0351] 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.

[0352] It should be noted that the information execution process and other contents of the units of the above-mentioned communication device 1000 can be specifically referred to the description in the method embodiment shown in the above-mentioned application, and will not be repeated here.

[0353] See also Fig.11 , is another schematic structural diagram of the communication device 1100 provided in the present application, and 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.

[0354] Optionally, the communication device also includes a logic circuit 1101.

[0355] in, Fig.10 The transceiver unit 1002 shown may be a communication interface, which may be Fig.11 The input / output interface 1102 in the communication interface may include an input interface and an output interface. Alternatively, the communication interface may also be a transceiver circuit, which may include an input interface circuit and an output interface circuit.

[0356] Optionally, the logic circuit 1101 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; and the input-output interface 1102 is used to send 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. The logic circuit 1101 and the 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 described in detail herein.

[0357] 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 can also perform other steps performed by the first terminal device in any of the aforementioned embodiments and achieve corresponding beneficial effects, which will not be repeated here.

[0358] Optionally, the input-output interface 1102 is used to receive the second information; the logic circuit 1101 is used to determine the user plane unit; the input-output interface 1102 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 input-output interface 1102 is also used to send the multicast data to the first terminal device according to the second information. The logic circuit 1101 and the input-output interface 1102 can also perform other steps performed by the network device in any of the aforementioned embodiments and achieve corresponding beneficial effects, which will not be repeated here.

[0359] In one possible implementation, Fig.10 The processing unit 1001 shown can be Fig.11 The logic circuit 1101 in.

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

[0361] 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.

[0362] Alternatively, the processing device may include only a processor. A memory for storing a computer program is located outside the processing device, and the processor is connected to the memory via a circuit / wire to read and execute the computer program stored in the memory. The memory and the processor may be integrated together, or may be physically independent of each other.

[0363] 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 (FPGA), application specific integrated circuits (ASIC), system on chip (SoC), central processor unit (CPU), network processor (NP), digital signal processor (DSP), microcontroller unit (MCU), programmable logic device (PLD) or other integrated chips, or any combination of the above chips or processors.

[0364] See also Fig.12 , 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 be specifically the first terminal device, the first device or the network device in the above method embodiments, or it can be a chip or system on chip located in the first terminal device, the first device or the network device. The structure of the communication device can refer to Fig.12 The structure shown.

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

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

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

[0368] 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.

[0369] Fig.12Only one memory and one processor are shown. In the actual first terminal device, the first device or the network device, there may be multiple processors and multiple memories. The memory may also be referred to as a storage medium or a storage device, etc. 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 embodiments of the present application.

[0370] 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, the first terminal device or the network device in the aforementioned embodiment.

[0371] 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.

[0372] 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 for 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, and may also 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.

[0373] 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.

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

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

[0376] In addition, each functional unit in each embodiment 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 part that contributes or all or part of the solution can be embodied in the form of a software product, which is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a 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