Communication method and communication device

Abstract

The present application provides a communication method and a communication device. In the technical solution of the present application, when a preset condition is satisfied, the access network device notifies the user equipment that the multicast session should be released or deactivated. When the multicast session is in use or should be used, the user equipment may feedback to the access network device that the user equipment is still interested in the multicast session. The access network device may determine whether the multicast session should be continued to be released or deactivated based on whether the feedback from the user equipment is received within a preset period. In this way, the technical solution can properly manage the multicast session when the user equipment in an idle state can receive multicast data.

Description

[Technical field]

[0001] The present application relates to the field of communications, and more particularly to communication methods and devices. [Background technology]

[0002] In case of multicast transmission, when the user equipment is in an idle state, the association between the user equipment and the multicast group has already been released by the network side. When the associated user equipment is not in the multicast group, the network side may release or deactivate the multicast session corresponding to the multicast group.

[0003] At present, the prior art helps a user equipment to receive multicast data when it is in an idle state. Specifically, when a user equipment enters an idle state from a connected state, the user equipment still stores the multicast reception parameters that the user equipment used when it was in a connected state, so that the user equipment in the idle state can receive multicast data by using the multicast reception parameters. It can be seen that when the associated user equipment is not in a particular multicast group, the user equipment in the idle state may be receiving or about to receive data by using a multicast session corresponding to the multicast group. In this case, if the multicast session is released or deactivated, the transmission of multicast data of the idle user equipment will be affected.

[0004] In view of the above circumstances, how to manage multicast sessions has become an urgent problem to be solved. Summary of the Invention

[0005] The present application provides a communication method and a communication device for properly managing a multicast session when a user equipment in an idle state is able to receive multicast data.

[0006] According to a first aspect, the present application provides a communication method, the method including: an access network device broadcasting a first message when a preset condition is satisfied, the first message being used to notify that a first multicast session should be released or deactivated, and the access network device releasing or deactivating the first multicast session when the access network device does not receive a second message in response to the first message within a first preset period, and / or the access network device maintaining the first multicast session when the access network device receives a second message in response to the first message within a first preset period.

[0007] The pre-set conditions may be used to release or deactivate the first multicast session.

[0008] Releasing or deactivating the first multicast session may be understood as releasing or deactivating a context of the first multicast session.

[0009] Maintaining the first multicast session may also be described as not releasing or deactivating the first multicast session, or giving up on releasing or deactivating the first multicast session.

[0010] Optionally, the second message may be used to request or inform that the first multicast session is to be released or deactivated, to indicate that data is being or should be received using the first multicast session, to simply respond to the first message (in this case, the user equipment may not need to send a response message if no data is being received using the first multicast session), to request that a radio resource control (RRC) connection be established, and optionally to convey information about active multicast sessions, etc.

[0011] Optionally, the second message is an air interface message, for example an RRC message.

[0012] In the above technical solution, when the preset condition is satisfied, the access network device notifies the user equipment that the first multicast session should be released or deactivated, so that the user equipment can feedback to the access network device that the user equipment is using or about to use the first multicast session. In this way, the access network device determines whether to continue to release or deactivate the first multicast session based on the feedback of the user equipment. When the user equipment in idle state can receive the multicast data, the multicast session can be managed appropriately.

[0013] With reference to the first aspect, in a possible implementation, the preset condition includes at least one of the following: data is not transmitted in the first multicast session within a second preset period, the associated user equipment is not in the multicast group, or a first timer used to monitor whether there is a user equipment receiving the data by using the first multicast session times out.

[0014] With reference to the first aspect or any one of the above implementations, in another possible implementation, the method further includes the access network device sending a third message to the core network device, the third message being used to request releasing or deactivating the first multicast session.

[0015] With reference to the first aspect or any one of the above implementations, in another possible implementation, the access network device sending the third message to the core network device includes the access network device sending the third message to the core network device after a first preset period of time.

[0016] In the above technical solution, the access network device requests the core network device to release or deactivate the first multicast session after a first preset period. In other words, the access network device requests the core network device to release or deactivate the first multicast session only after deciding to release or deactivate the first multicast session. In this way, the implementation of the core network device is simple.

[0017] With reference to the first aspect or any one of the above implementations, in another possible implementation, the access network device sending the third message to the core network device includes the access network device sending the third message to the core network device before the first preset period.

[0018] In the above technical solution, before determining whether to release or deactivate the first multicast session, the access network device requests the core network device to release or deactivate the first multicast session in advance. In this way, the delay of releasing or deactivating the first multicast session can be reduced.

[0019] With reference to the first aspect or any one of the above implementations, in another possible implementation, the method further includes, if the access network device receives the second message within the first preset period, the access network device sending a fifth message to the core network device, where the fifth message is used to request the core network device to maintain the first multicast session.

[0020] In the above technical solution, when the access network device requests the core network device to release or deactivate the first multicast session, if the access network device receives the second message within a first preset period, the access network device may notify the core network device to maintain the first multicast session, and prevent the core network device from releasing the first multicast session.

[0021] With reference to the first aspect or any one of the above implementations, in another possible implementation, the second message is from a user equipment.

[0022] With reference to the first aspect or any one of the above implementations, in another possible implementation, the second message is an RRC message.

[0023] According to a second aspect, the present application provides a communication method, the method including: a user equipment receiving a first message from an access network device, the first message being used to notify that a first multicast session should be released or deactivated, and when the user equipment is receiving or is about to receive data by using the first multicast session, the user equipment sending a second message to the access network device in response to the first message.

[0024] Optionally, the second message may be used to request or inform that the first multicast session is to be released or deactivated, to indicate that data is being or should be received using the first multicast session, to simply respond to the first message (in this case, the user equipment may not need to send a response message if no data is being received using the first multicast session), to request that an RRC connection be established, and optionally to convey information about active multicast sessions, etc.

[0025] Optionally, the second message is an air interface message, for example an RRC message.

[0026] In the above technical solution, the access network device notifies the user equipment that the first multicast session should be released or deactivated. When the user equipment is using or about to use the first multicast session, the user equipment may feedback to the access network device that the user equipment is using or about to use the first multicast session. In this way, the access network device determines whether to continue to release or deactivate the first multicast session based on the feedback of the user equipment. When the user equipment in an idle state can receive multicast data, the multicast session can be managed appropriately.

[0027] Referring to the second aspect, in a possible implementation the user equipment is in an idle state or an RRC inactive state.

[0028] With reference to the second aspect or any one of the above implementations, in another possible implementation, the second message is an RRC message.

[0029] According to a third aspect, the present application provides a communication method, the method including: a core network device receiving a third message from an access network device, the third message being used to request to release or deactivate a first multicast session; and the core network device releasing or deactivating the first multicast session based on the third message.

[0030] In the above technical solution, when receiving a request from the access network device, the core network device may release or deactivate the first multicast session. When the user equipment in idle state can receive the multicast data, the multicast session can be managed properly.

[0031] According to a fourth aspect, the present application provides a communication method, the method including: a core network device receiving a third message from an access network device, the third message being used to request to release or deactivate a first multicast session, and the core network device releasing or deactivating the first multicast session if the core network device does not receive a fifth message within a third preset period, and / or the core network device maintaining the first multicast session if the core network device receives a fifth message within a third preset period, the fifth message indicating to maintain the first multicast session.

[0032] In the above technical solution, when the access network device requests the core network device to release or deactivate the first multicast session, if the access network device receives the second message within a first preset period, the access network device may inform the core network device to maintain the first multicast session. When the user equipment in idle state can receive the multicast data, the multicast session can be managed properly.

[0033] According to a fifth aspect, the present application provides a communication method, the method including: an access network device broadcasting a sixth message when a preset condition is satisfied, the sixth message being used to notify that the first multicast session should be released or deactivated, and the access network device releasing or deactivating the first multicast session when the access network device does not receive an eighth message from the core network device within a first preset period, and / or the access network device maintaining the first multicast session when the access network device receives an eighth message from the core network device within a first preset period, the eighth message being used by a user equipment to request to join the first multicast session.

[0034] The pre-set conditions may be used to release or deactivate the first multicast session.

[0035] Releasing or deactivating the first multicast session may be understood as releasing or deactivating a context of the first multicast session.

[0036] Maintaining the first multicast session may also be described as not releasing or deactivating the first multicast session, or giving up on releasing or deactivating the first multicast session.

[0037] Optionally, the eighth message may be used to request or notify that the first multicast session is to be released or deactivated, to indicate that data is being or should be received using the first multicast session, to simply respond to the sixth message (in this case, if no data is being received using the first multicast session, the user device may not need to send a response message), etc.

[0038] Optionally, the eighth message may be an N2 message.

[0039] In the above technical solution, when the preset condition is satisfied, the access network device informs the user equipment that the first multicast session should be released or deactivated, so that the user equipment can feedback to the core network device that the user equipment is using or about to use the first multicast session, and then the core network device feedbacks to the access network device that the user is still using or about to use the first multicast session. In this way, the access network device determines whether to continue to release or deactivate the first multicast session based on the feedback of the user equipment. When the user equipment in the idle state can receive the multicast data, the multicast session can be managed appropriately.

[0040] With reference to the fifth aspect, in a possible implementation, the preset condition includes at least one of the following: no data is transmitted in the first multicast session within a second preset period, no associated user equipment is in the multicast group, or a first timer used to monitor whether there is a user equipment receiving the data by using the first multicast session times out.

[0041] With reference to the fifth aspect and any one of the above implementations, in another possible implementation, the method further includes the access network device sending a ninth message to the core network device before the first preset period, the ninth message being used to request to release or deactivate the first multicast session.

[0042] In the above technical solution, before determining whether to release or deactivate the first multicast session, the access network device requests the core network device to release or deactivate the first multicast session in advance. In this way, the delay of releasing or deactivating the first multicast session can be reduced.

[0043] With reference to the fifth aspect or any one of the above implementations, in another possible implementation, the method further includes, if the eighth message is not received within the first preset period, the access network device sending a ninth message to the core network device, the ninth message being used to request releasing or deactivating the first multicast session.

[0044] In the above technical solution, the access network device requests the core network device to release or deactivate the first multicast session after a first preset period. In other words, the access network device requests the core network device to release or deactivate the first multicast session only after deciding to release or deactivate the first multicast session. In this way, the implementation of the core network device is simple.

[0045] According to a sixth aspect, the present application provides a communication method, the method including: a user equipment receiving a sixth message from an access network device, the sixth message being used to notify that a first multicast session should be released or deactivated, and when the user equipment is receiving or is about to receive data by using the first multicast session, the user equipment sending a seventh message to a core network device, the seventh message being used to request to join the first multicast session.

[0046] Optionally, the seventh message may be used to request or notify that the first multicast session is to be released or deactivated, to indicate that data is being or should be received using the first multicast session, to simply respond to the sixth message (in this case, the user device may not need to send a response message if no data is being received using the first multicast session), etc.

[0047] Optionally, the seventh message is a non-access stratum (NAS) message.

[0048] In the above technical solution, the access network device may inform the user equipment that the first multicast session should be released or deactivated. When the user equipment is using or about to use the first multicast session, the user equipment may feedback to the core network device that the user equipment is using or about to use the first multicast session. In this way, the access network device determines whether to continue to release or deactivate the first multicast session based on the feedback of the user equipment. When the user equipment in an idle state can receive multicast data, the multicast session can be managed appropriately.

[0049] According to a seventh aspect, the present application provides a communication method, the method including: a core network device receiving a seventh message from a user equipment, the seventh message being used to request to join a first multicast session, and the core network device sending an eighth message to an access network device, the eighth message being used to request to add the user equipment to the first multicast session.

[0050] Optionally, the seventh message may be used to request or notify that the first multicast session is to be released or deactivated, to indicate that data is being or should be received using the first multicast session, to simply respond to the sixth message (in this case, the user device may not need to send a response message if no data is being received using the first multicast session), etc.

[0051] Optionally, the seventh message is a NAS message.

[0052] Optionally, the eighth message is an N2 message.

[0053] In the above technical solution, when the user equipment is using or about to use the first multicast session, the user equipment may feedback to the core network device that the user equipment is using or about to use the first multicast session, and the core network device may feedback to the access network device that the user equipment is still using the first multicast session. In this way, the access network device determines whether to continue to release or deactivate the first multicast session based on the feedback of the user equipment. When the user equipment in the idle state can receive the multicast data, the multicast session can be managed appropriately.

[0054] According to an eighth aspect, the present application provides a communication method, the method including: a core network device receiving a ninth message from an access network device, the ninth message being used to request to release or deactivate the first multicast session, and if the core network device does not receive a seventh message from the user equipment within a second preset period, the core network device releasing or deactivating the first multicast session, and / or if the core network device receives a seventh message from the user equipment within a second preset period, the core network device maintaining the first multicast session and sending an eighth message to the access network device, the eighth message being used to request to add the user equipment to the first multicast session, and the seventh message being used to request to join the first multicast session.

[0055] In the above technical solution, after receiving the seventh message, the core network device may know based on the seventh message that the user equipment is still using or about to use the first multicast session, determine that the first multicast session should be maintained, and request the access network device to add the user equipment to the first multicast session. In this way, the access network device determines whether to continue to release or deactivate the first multicast session based on the feedback of the user equipment. When the user equipment in the idle state can receive the multicast data, the multicast session can be managed appropriately.

[0056] According to a ninth aspect, the present application provides a communications device, comprising: a transceiver unit configured to broadcast a first message when a preset condition is satisfied, the first message being used to notify that the first multicast session should be released or deactivated; a processing unit configured to release or deactivate the first multicast session if a second message in response to the first message is not received within a first preset period of time, and / or to maintain the first multicast session if a second message in response to the first message is received within the first preset period of time; Includes.

[0057] Optionally, the communication device may be an access network device.

[0058] The pre-set conditions are used to release or deactivate the first multicast session.

[0059] Releasing or deactivating the first multicast session may be understood as releasing or deactivating a context of the first multicast session.

[0060] Maintaining the first multicast session may also be described as not releasing or deactivating the first multicast session, or giving up on releasing or deactivating the first multicast session.

[0061] Optionally, the second message may be used to request or inform that the first multicast session is to be released or deactivated, to indicate that data is being or should be received using the first multicast session, to simply respond to the first message (in this case, the user equipment may not need to send a response message if no data is being received using the first multicast session), to request that an RRC connection be established, and optionally to convey information about active multicast sessions, etc.

[0062] Optionally, the second message is an air interface message, for example an RRC message.

[0063] In the above technical solution, when the preset condition is satisfied, the access network device notifies the user equipment that the first multicast session should be released or deactivated, so that the user equipment can feedback to the access network device that the user equipment is using or about to use the first multicast session. In this way, the access network device determines whether to continue to release or deactivate the first multicast session based on the feedback of the user equipment. When the user equipment in idle state can receive the multicast data, the multicast session can be managed appropriately.

[0064] With reference to the ninth aspect, in a possible implementation, the preset condition includes at least one of the following: data is not transmitted in the first multicast session within a second preset period, the associated user device is not in the multicast group, or a first timer used to monitor whether there is a user device receiving the data by using the first multicast session times out.

[0065] With reference to the ninth aspect or any one of the above implementations, in another possible implementation, the transceiver unit is further configured to send a third message to the core network device, the third message being used to request the first multicast session to be released or deactivated.

[0066] With reference to the ninth aspect or any one of the above implementations, in another possible implementation, the transceiver unit is specifically configured to transmit the third message to the core network device after the first preset period.

[0067] In the above technical solution, the access network device requests the core network device to release or deactivate the first multicast session after a first preset period. In other words, the access network device requests the core network device to release or deactivate the first multicast session only after deciding to release or deactivate the first multicast session. In this way, the implementation of the core network device is simple.

[0068] With reference to the ninth aspect or any one of the above implementations, in another possible implementation, the transceiver unit includes transmitting a third message to the core network device before the first preset period.

[0069] In the above technical solution, before determining whether to release or deactivate the first multicast session, the access network device requests the core network device to release or deactivate the first multicast session in advance. In this way, the delay of releasing or deactivating the first multicast session can be reduced.

[0070] With reference to the ninth aspect or any one of the above implementations, in another possible implementation, the transceiver unit is further configured to send a fifth message to the core network device if the second message is received within the first preset period, where the fifth message is used to request the core network device to maintain the first multicast session.

[0071] In the above technical solution, when the access network device requests the core network device to release or deactivate the first multicast session, if the access network device receives the second message within a first preset period, the access network device may notify the core network device to maintain the first multicast session, and prevent the core network device from releasing the first multicast session.

[0072] With reference to the ninth aspect or any one of the above implementations, in another possible implementation, the second message is from a user equipment.

[0073] With reference to the first aspect or any one of the above implementations, in another possible implementation, the second message is an RRC message.

[0074] According to a tenth aspect, the present application provides a communications device, comprising: The method includes receiving a first message from the access network device, the first message being used to notify that the first multicast session should be released or deactivated, and transmitting a second message to the access network device in response to the first message if the first multicast session is in use or should be used.

[0075] Optionally, the second message may be used to request or inform that the first multicast session is to be released or deactivated, to indicate that data is being or should be received using the first multicast session, to simply respond to the first message (in this case, the user equipment may not need to send a response message if no data is being received using the first multicast session), to request that an RRC connection be established, and optionally to convey information about active multicast sessions, etc.

[0076] Optionally, the second message is an air interface message, for example an RRC message.

[0077] Optionally, the communication device is a user device.

[0078] In the above technical solution, the access network device may notify the user equipment that the first multicast session should be released or deactivated. When the user equipment is using or about to use the first multicast session, the user equipment may feedback to the access network device that the user equipment is using or about to use the first multicast session. In this way, the access network device determines whether to continue to release or deactivate the first multicast session based on the feedback of the user equipment. When the user equipment in an idle state can receive multicast data, the multicast session can be managed appropriately.

[0079] Referring to the second aspect, in a possible implementation the user equipment is in an idle state or an RRC inactive state.

[0080] With reference to the second aspect or any one of the above implementations, in another possible implementation, the second message is an RRC message.

[0081] According to an eleventh aspect, the present application provides a communications device, comprising: a transceiver unit configured to receive a third message from the access network device, the third message being used to request the first multicast session to be released or deactivated; a processing unit configured to release or deactivate the first multicast session based on the third message; Includes.

[0082] Optionally, the communication device may be a core network device.

[0083] In the above technical solution, when receiving a request from the access network device, the core network device may release or deactivate the first multicast session. When the user equipment in idle state can receive the multicast data, the multicast session can be managed properly.

[0084] According to a twelfth aspect, the present application provides a communications device, comprising: a transceiver unit configured to receive a third message from the access network device, the third message being used to request the first multicast session to be released or deactivated; a processing unit configured to release or deactivate the first multicast session if the fifth message is not received within a third preset period of time, and / or to maintain the first multicast session if the fifth message is received within the third preset period of time. and the fifth message indicates maintaining the first multicast session.

[0085] Optionally, the communication device may be a core network device.

[0086] In the above technical solution, when the access network device requests the core network device to release or deactivate the first multicast session, if the access network device receives the second message within a first preset period, the access network device may inform the core network device to maintain the first multicast session. When the user equipment in idle state can receive the multicast data, the multicast session can be managed properly.

[0087] According to a thirteenth aspect, the present application provides a communications device, comprising: a transceiver unit configured to broadcast a sixth message when a preset condition is satisfied, the sixth message being used to notify that the first multicast session should be released or deactivated; and a processing unit configured to release or deactivate the first multicast session if the eighth message is not received from the core network device within a first preset period, and / or to maintain the first multicast session if the eighth message is received from the core network device within a first preset period, the eighth message being used by a user equipment to request to join the first multicast session; Includes.

[0088] Optionally, the communication device may be an access network device.

[0089] The pre-set conditions may be used to release or deactivate the first multicast session.

[0090] Releasing or deactivating the first multicast session may be understood as releasing or deactivating a context of the first multicast session.

[0091] Maintaining the first multicast session may also be described as not releasing or deactivating the first multicast session, or giving up on releasing or deactivating the first multicast session.

[0092] Optionally, the eighth message may be used to request or notify that the first multicast session is to be released or deactivated, to indicate that data is being or should be received using the first multicast session, to simply respond to the sixth message (in this case, if no data is being received using the first multicast session, the user device may not need to send a response message), etc.

[0093] Optionally, the eighth message may be an N2 message.

[0094] In the above technical solution, when the preset condition is satisfied, the access network device informs the user equipment that the first multicast session should be released or deactivated, so that the user equipment can feedback to the core network device that the user equipment is using or about to use the first multicast session, and then the core network device feedbacks to the access network device that the user is still using or about to use the first multicast session. In this way, the access network device determines whether to continue to release or deactivate the first multicast session based on the feedback of the user equipment. When the user equipment in the idle state can receive the multicast data, the multicast session can be managed appropriately.

[0095] With reference to the thirteenth aspect, in a possible implementation, the preset condition includes at least one of the following: no data is transmitted in the first multicast session within a second preset period, no associated user equipment is in the multicast group, or a first timer used to monitor whether there is a user equipment receiving data by using the first multicast session times out.

[0096] With reference to the thirteenth aspect and any one of the above implementations, in another possible implementation, the transceiver unit is further configured to send a ninth message to the core network device before the first preset period, the ninth message being used to request the first multicast session to be released or deactivated.

[0097] In the above technical solution, before determining whether to release or deactivate the first multicast session, the access network device requests the core network device to release or deactivate the first multicast session in advance. In this way, the delay of releasing or deactivating the first multicast session can be reduced.

[0098] With reference to the thirteenth aspect or any one of the above implementations, in another possible implementation, the transceiver unit is further configured to send a ninth message to the core network device if the eighth message is not received within a first preset period, the ninth message being used to request the first multicast session to be released or deactivated.

[0099] In the above technical solution, the access network device requests the core network device to release or deactivate the first multicast session after a first preset period. In other words, the access network device requests the core network device to release or deactivate the first multicast session only after deciding to release or deactivate the first multicast session. In this way, the implementation of the core network device is simple.

[0100] According to a fourteenth aspect, the present application provides a communication device, comprising: The present invention includes a transceiver unit configured to receive a sixth message from the access network device, where the sixth message is used to notify that the first multicast session should be released or deactivated, and to send a seventh message to the core network device when data is being received or is to be received by using the first multicast session, where the seventh message is used to request to join the first multicast session.

[0101] Optionally, the seventh message may be used to request or notify that the first multicast session is to be released or deactivated, to indicate that data is being or should be received using the first multicast session, to simply respond to the sixth message (in this case, the user device may not need to send a response message if no data is being received using the first multicast session), etc.

[0102] Optionally, the seventh message is a NAS message.

[0103] Optionally, the communication device may be a user device.

[0104] In the above technical solution, the access network device may inform the user equipment that the first multicast session should be released or deactivated. When the user equipment is using or about to use the first multicast session, the user equipment may feedback to the core network device that the user equipment is using or about to use the first multicast session. In this way, the access network device determines whether to continue to release or deactivate the first multicast session based on the feedback of the user equipment. When the user equipment in an idle state can receive multicast data, the multicast session can be managed appropriately.

[0105] According to a fifteenth aspect, the present application provides a communication device, comprising: The present invention includes a transceiver unit configured to receive a seventh message from a user device, the seventh message being used to request joining the first multicast session, and to send an eighth message to an access network device, the eighth message being used to request adding the user device to the first multicast session.

[0106] Optionally, the communication device may be a core network device.

[0107] Optionally, the seventh message may be used to request or notify that the first multicast session is to be released or deactivated, to indicate that data is being or should be received using the first multicast session, to simply respond to the sixth message (in this case, the user device may not need to send a response message if no data is being received using the first multicast session), etc.

[0108] Optionally, the seventh message is a NAS message.

[0109] Optionally, the eighth message is an N2 message.

[0110] In the above technical solution, when the user equipment is using or about to use the first multicast session, the user equipment may feedback to the core network device that the user equipment is using or about to use the first multicast session, and the core network device may feedback to the access network device that the user equipment is still using the first multicast session. In this way, the access network device determines whether to continue to release or deactivate the first multicast session based on the feedback of the user equipment. When the user equipment in the idle state can receive the multicast data, the multicast session can be managed appropriately.

[0111] According to a sixteenth aspect, the present application provides a communications device, comprising: a transceiver unit configured to receive a ninth message from the access network device, the ninth message being used to request to release or deactivate the first multicast session; a processing unit configured to release or deactivate the first multicast session if the seventh message is not received from the user equipment within a second preset period of time, and / or to maintain the first multicast session if the seventh message is received from the user equipment within a second preset period of time. The processing unit is further configured to send an eighth message to the access network device, where the eighth message is used to request adding the user equipment to the first multicast session, and the seventh message is used to request joining the first multicast session.

[0112] Optionally, the communication device may be a core network device.

[0113] In the above technical solution, after receiving the seventh message, the core network device may know based on the seventh message that the user equipment is still using or about to use the first multicast session, determine that the first multicast session should be maintained, and request the access network device to add the user equipment to the first multicast session. In this way, the access network device determines whether to continue to release or deactivate the first multicast session based on the feedback of the user equipment. When the user equipment in the idle state can receive the multicast data, the multicast session can be managed appropriately.

[0114] According to a seventeenth aspect, the present application provides a communication device including a processor. The processor may be coupled to a memory and configured to execute instructions in the memory, such that the device performs a method provided in any one of the first to eighth aspects, or performs a method in any possible implementation of the first to eighth aspects. Optionally, the device further includes the memory. The device further includes an interface circuit, the processor being coupled to the interface circuit.

[0115] According to an eighteenth aspect, the present application provides a processor including an input circuit, an output circuit, and a processing circuit, the processing circuit being configured to receive a signal using the input circuit and to transmit a signal using the output circuit, such that the processor performs a method provided in any one of the first to eighth aspects, or performs a method in any possible implementation of the first to eighth aspects.

[0116] In a specific implementation process, the processor may be a chip, the input circuit may be an input pin, the output circuit may be an output pin, and the processing circuit may be a transistor, a gate circuit, a trigger, various logic circuits, etc. The input signal received by the input circuit may be, for example, but not limited to, received and input by a receiver, and the signal output by the output circuit may be, for example, but not limited to, output to a transmitter and transmitted by the transmitter, and the input circuit and the output circuit may be the same circuit, in which case the circuit is used as an input circuit and an output circuit at different times. The specific implementation of the processor and various circuits is not limited to the embodiments of the present application.

[0117] According to a nineteenth aspect, the present application provides a processing device including a processor. The processor is coupled to a memory. The processor is configured to read instructions stored in the memory, receive a signal using the receiver, and transmit a signal using the transmitter, to perform a method provided in any one of the first to eighth aspects, or a method in any possible implementation of the first to eighth aspects. Optionally, the processing device may further include the memory.

[0118] Optionally, there are one or more processors and one or more memories.

[0119] Optionally, the memory may be integral to the processor, or alternatively, the memory and the processor may be separately located.

[0120] In a specific implementation process, the memory may be a non-transitory memory such as a read-only memory (ROM). The memory and the processor may be integrated into one chip, or may be separately arranged on different chips. The type of memory and the way in which the memory and the processor are arranged are not limited in this embodiment of the present application.

[0121] The processing device according to the nineteenth aspect may be a chip. The processor may be implemented by hardware or software. When the processor is implemented by hardware, the processor may be a logic circuit, an integrated circuit, etc. When the processor is implemented by software, the processor may be a general-purpose processor and is implemented by reading software code stored in a memory. The memory may be integrated into the processor or may be located outside the processor and exist independently.

[0122] According to a twentieth aspect, the present application provides a computer program product. The computer program product includes computer instructions (also referred to as code or instructions). When the computer program is executed, the computer is capable of performing the method provided in any one of the first to eighth aspects, or of performing a method in any possible implementation of the first to eighth aspects.

[0123] According to a twenty-first aspect, the present application provides a computer-readable medium. The computer-readable medium stores a computer program (also called code or instructions). When the computer-readable medium is executed on a computer, the computer can execute the method provided in any one of the first to eighth aspects, or execute the method in any possible implementation of the first to eighth aspects.

[0124] According to a twenty-second aspect, the present application provides a communication system including at least one communication device as provided in any one of the above aspects or possible implementations of the above aspects. [Brief description of the drawings]

[0125] [Figure 1] FIG. 1 is a schematic diagram of a network architecture. [Diagram 2] 1 is a simplified flowchart of a communication method according to the present application. [Diagram 3] 4 is a schematic flow chart of another communication method according to the present application. [Figure 4] 4 is a schematic flow chart of another communication method according to the present application. [Diagram 5] 2 is a schematic flow chart of an access network (AN) connection release by a user equipment; [Figure 6] 4 is a schematic flow chart of another communication method according to the present application. [Figure 7] 4 is a schematic flow chart of another communication method according to the present application. [Figure 8]4 is a schematic flow chart of another communication method according to the present application. [Figure 9] 1 is an example of a communication method according to an embodiment of the present application. [Figure 10] 13 is another example of a communication method according to an embodiment of the present application. [Figure 11] 13 is another example of a communication method according to an embodiment of the present application. [Figure 12] 13 is another example of a communication method according to an embodiment of the present application. [Figure 13] 1 is a schematic block diagram of a communication device according to an embodiment of the present application; [Figure 14] FIG. 1 is a schematic diagram of the structure of a communication device according to the present application. [Figure 15] FIG. 1 is a schematic diagram of the structure of a communication device according to the present application. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0126] The following describes the technical solutions of the present application with reference to the accompanying drawings.

[0127] The technical solutions of the embodiments of the present application may be applied to various communication systems, such as long term evolution (LTE) systems, LTE frequency division duplex (FDD) systems, LTE time division duplex (TDD) systems, universal mobile telecommunication system (UMTS), worldwide interoperability for microwave access (WiMAX) communication systems, 5th generation (5G) systems, new radio (NR) communication systems, satellite communication systems, and future mobile communication systems.

[0128] FIG. 1 is a schematic diagram of a network architecture. The embodiments of the present application may be applied to the network architecture. The 5G network architecture is used as an example. The network architecture includes a user equipment (UE) 101, a radio access network (RAN) device 102, a user plane function (UPF) network element 103, a data network (DN) network element 104, an access and mobility management function (AMF) network element 105, a session management function (SMF) network element 106, a policy control function (PCF) network element 107, a unified data management (UDM) network element 108, an application function (AF) network element 109, and a unified data repository (UDR) network element 110. The user equipment 101, radio access network device 102, UPF network element 103, DN network element 104, AMF network element 105, SMF network element 106, PCF network element 107, UDM network element 108, AF network element 109, and UDR network element 110 are hereinafter referred to for brevity as UE 101, RAN 102, UPF 103, DN 104, AMF 105, SMF 106, PCF 107, UDM 108, AF 109, and UDR 110, respectively.

[0129] The UE 101 mainly accesses the 5G network and obtains services through a radio air interface. The UE 101 interacts with the RAN 102 through the air interface and interacts with the AMF 105 in the core network by using NAS signaling.

[0130] The RAN 102 is responsible for scheduling air interface resources for the UE 101 to access the network, and is responsible for air interface connection management.

[0131] The UPF 103 is responsible for handling user data in the user equipment, such as forwarding and charging. For example, the UPF 103 may receive user data from the DN 104 and transmit the user data to the UE 101 by using the RAN 102, or may receive user data from the UE 101 by using the RAN 102 and forward the user data to the DN 104. The transmission resources and scheduling functions used by the UPF 103 to provide services to the UE 101 are managed and controlled by the SMF 106.

[0132] The DN 104 is an operator network that provides data transmission services for users, such as internet protocol (IP) multimedia services (IMS) or the Internet. The UE 101 accesses the DN 104 by establishing a protocol data unit (PDU) session between the UE 101, the RAN 102, the UPF 103, and the DN 104.

[0133] The AMF 105 is mainly responsible for mobility management within a mobile network, such as user location update, user network registration, and user handover.

[0134] The SMF 106 is mainly involved in session management within a mobile network, such as session establishment, modification, and release, etc. Specific functions include assigning IP addresses to users, selecting a UPF that provides a packet forwarding function, etc.

[0135] The PCF 107 is responsible for providing policies, such as quality of service (QoS) policies or slice selection policies, to the AMF 105 and the SMF 106.

[0136] The UDM 108 is configured to store user data, such as subscription information and authentication / authorization information.

[0137] The AF 109 is primarily responsible for providing services for the 3rd generation partnership project (3GPP) network, such as influencing service routing and interacting with the PCF 107 to perform policy control.

[0138] The UDR 110 is responsible for storing and retrieving subscription data, policy data, common architecture data, and the like.

[0139] In the network architecture, N1 is an interface between the UE 101 and the AMF 105. N2 is an interface between the RAN 102 and the AMF 105, and is used to transmit NAS messages, etc. N3 is an interface between the RAN 102 and the UPF 103, and is used to transmit user plane data, etc. N4 is an interface between the SMF 106 and the UPF 103, and is used to transmit information such as tunnel identifier information, data buffer indication information, and downlink data notification messages for the N3 connection. N5 is an interface between the PCF 107 and the AF 109. N6 is an interface between the UPF 103 and the DN 104, and is used to transmit user plane data, etc. N7 is an interface between the SMF 106 and the PCF 107. N8 is an interface between the AMF 105 and the UDM 108. N9 is an interface between the UPFs. N10 is an interface between the UDM 108 and the SMF 106. N11 is an interface between the AMF 105 and the SMF 106. N15 is an interface between the AMF 105 and the PCF 107. N25 is an interface between the UDM 108 and the PCF 107. N35 is an interface between the UDM 108 and the UDR 110. N36 is an interface between the UDR 110 and the PCF 107.

[0140] It should be noted that the interfaces between the network elements shown in Figure 1 may alternatively be serviced interfaces. This is not a limitation.

[0141] The user device of the embodiment of the present application may also be referred to as a terminal device, a user, an access terminal, a subscriber unit, a subscriber station, a mobile station, a mobile console, a remote station, a remote terminal, a mobile device, a user terminal, a terminal, a wireless communication device, a user agent, a user equipment, etc. The user device may be a cellular phone, a smart watch, a wireless data card, a mobile phone, a tablet computer, a personal digital assistant (PDA) computer, a wireless modem, a handheld device, a laptop computer, a machine type communication (MTC) terminal, a computer with a wireless transceiver function, an Internet of Things terminal, a virtual reality terminal device, an augmented reality terminal device, a wireless terminal in industrial control, a wireless terminal in autonomous driving, a wireless terminal in remote surgery, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, a wireless terminal in satellite communication (e.g., a satellite phone or a satellite terminal), etc. The specific technology and the specific device form used for the user device are not limited in the embodiment of the present application.

[0142] The access network device of the embodiment of the present application may be a device configured to communicate with a user device, and is mainly responsible for functions such as radio resource management, service quality management, and data compression and encryption on the air interface side. The access network device may be a base transceiver station (BTS) in a global system for mobile communications (GSM) system or a code division multiple access (CDMA) system, a Node B (NB) in a wideband code division multiple access (WCDMA) system, an evolved Node B (eNB) in an LTE system, a base station in a worldwide interoperability for microwave access (WiMAX) communication system, a radio controller in a cloud radio access network (CRAN) scenario, and an intermediate access point, relay station, vehicle-mounted device, wearable device, etc. in a wireless high fidelity system. Alternatively, the access network device may be a terminal that functions as a base station in D2D communication or machine-to-machine communication. Alternatively, the access network device may be a network device in a 5G network, a network device in a future evolved PLMN network, etc. Furthermore, the access network device may alternatively be a module or unit that completes some functions of a base station, for example, a central unit (CU) or a distributed unit (DU).The specific technology and specific device configuration used in the access network device are not limited to the embodiments of this application.

[0143] It should be understood that the names of each network element shown in FIG. 1 are merely names, and the names do not constitute any limitation on the functions of the network elements. In different networks, the above network elements may alternatively have other names. This is not particularly limited in the embodiments of the present application. For example, in a 6th generation (6G) network, some or all of the above network elements may still use 5G terminology or may have other names. An overview is given here. Details will not be described again below. Similarly, the interfaces between the network elements shown in FIG. 1 are merely examples. In a 5G network and other future networks, the interfaces between the network elements may alternatively not be the interfaces shown. This is not limited in the present application. It should be further understood that the embodiments of the present application are not limited to the system architecture shown in FIG. 1. For example, a communication system to which the present application is applied may include more or fewer network elements or devices. The devices or network elements in FIG. 1 may be hardware, or may be software obtained through functional division, or a combination of hardware and software. The devices or network elements in FIG. 1 may communicate with each other via other devices or network elements.

[0144] It should be noted that the multicast in the embodiment of the present application may be replaced by groupcast or broadcast, and this is not limited thereto.

[0145] When the 5G network needs to send the same data to multiple user equipments, a multicast session may be established for the multiple user equipments to transmit the same data, so that only one copy of the same data is sent to the multiple user equipments, which helps to improve the utilization efficiency of air interface resources and core network resources.

[0146] It should be noted that the user equipment can receive multicast data by using a multicast session only when the user equipment is in a connected state. However, keeping the user equipment in a connected state may occupy storage resources and scheduling resources of the access network device. Currently, public safety requires that one access network device can support multicast transmission of 800 users. As a result, the access network device may not meet the requirement.

[0147] Based on this, a solution is provided in which a user equipment receives multicast data by using a multicast session when the user equipment is in an idle state. Specifically, when the user equipment enters an idle state from a connected state, the user equipment still stores the multicast receiving parameters when the user equipment is in a connected state, so that the user equipment in the idle state can receive multicast data by using the multicast receiving parameters.

[0148] Generally, after a user equipment enters an idle state, the network side disassociates the user equipment from the multicast group. When the associated user equipment is not in the multicast group, the network side may release or deactivate the multicast session corresponding to the multicast group. If the user equipment in the idle state can receive multicast data, and the network side determines that the associated user equipment is not in a particular multicast group, the user equipment in the idle state can still receive data by using the multicast session corresponding to the multicast group. In this case, if the network side releases or deactivates the multicast session, the transmission of multicast data of the user equipment will be affected. Thus, how to manage the multicast session has become an urgent problem to be solved.

[0149] In response to the above problem, the present application provides a communication method and a communication device for properly managing a multicast session when a user equipment in an idle state is able to receive multicast data.

[0150] Figure 2 is a simplified flowchart of a communication method according to the present application. The method illustrated in Figure 2 may be applied to the system architecture illustrated in Figure 1 and the scenario illustrated in Figure 2. However, this embodiment of the present application is not so limited.

[0151] The method of FIG. 2 may be performed by the access network device and the user equipment, or may be performed by a module or unit (e.g., a circuit, a chip, or a system on chip (SOC)) in the access network device and the user equipment. In FIG. 2, an example is used in which the access network device and the user equipment are used as the execution body. The method of FIG. 2 may include at least a part of the following contents.

[0152] Step 201: An access network device sends a first message when a preset condition is satisfied.

[0153] The first message may be used to notify that the first multicast session should be released or deactivated.

[0154] When the first multicast session should be released or deactivated, it indicates that the first multicast session is not released or deactivated, but the first multicast session may be released or deactivated after a certain period of time. It is clear that a change in the first multicast session within this period (which may be called a buffer time) may also cause a failure in the release or deactivation of the first multicast session that is not released or deactivated. For example, there is a user device that participates in the first multicast session, or there is data to be transmitted. This is not limited.

[0155] In the embodiment of the present application, releasing or deactivating the first multicast session may be understood as releasing or deactivating a context of the first multicast session.

[0156] In some implementations, the preset conditions may include at least one of the following: (1), (2), and (3).

[0157] (1) Data is not transmitted in the first multicast session within a second preset period of time.

[0158] No data is transmitted in the first multicast session within the second preset period of time may be understood as the user device not receiving multicast data using the first multicast session within the second preset period of time, the tunnel of the first multicast session not being occupied within the second preset period of time, etc.

[0159] (2) The associated user device is not in the multicast group.

[0160] The associated user equipment not being in the multicast group may be understood as the user equipment associated with the multicast group is not in the multicast group, the bound user equipment is not in the multicast group, the user list to which the first multicast session or multicast group belongs is empty, the access network device does not have context information about the user equipment in the multicast group, etc. The multicast group here is the multicast group corresponding to the first multicast session, hereinafter referred to as the first multicast group.

[0161] Specifically, the access network device may determine unassociated user equipment in the first multicast group based on the following information: the last user equipment belonging to the first multicast group is handed over to another access network device, the last user equipment belonging to the first multicast group releases the AN connection, etc.

[0162] For the procedure by which the user equipment releases the AN connection, please refer to the relevant description in Figure 5 below.

[0163] (3) The first timer times out.

[0164] Here, the first timer is used to monitor whether there is any user device receiving data by using the first multicast session.

[0165] For example, if the first timer times out, the access network device transmits the first message, if any event occurs that may cause the first timer to stop timing, the access network device does not transmit the first message.

[0166] In the example, a first timer begins timing when the following occurs:

[0167] (a) There is no user device in the first multicast group (in other words, there is no user device currently in a connected state that receives data by using the first multicast session).

[0168] (b) Alternatively, no data is transmitted in the first multicast session within a second preset period of time.

[0169] It should be noted that no user equipment in the first multicast group may mean that no user equipment is served by the access network device in the first multicast group.

[0170] The first timer stops timing if the following conditions occur:

[0171] (a) There is a user device in the first multicast group (in other words, there is a user device that is currently in a connected state and receives multicast data by using the first multicast group).

[0172] (b) Alternatively, the data is transmitted in a first multicast session.

[0173] It should be noted that there are user equipments in the first multicast group, which may mean that there are user equipments in the first multicast group that are served by the access network device.

[0174] When the first timer times out, the following action may be triggered: the access network device transmits a first message.

[0175] In another example, when the access network device detects that the associated user equipment is not in the first multicast group, the access network device may notify the user equipment that the first multicast group should be released or deactivated. When the user equipment feedbacks to the access network device that the user equipment is receiving or is about to receive multicast data by using the first multicast session, the access network device may maintain the first multicast session and start a first timer after receiving the feedback from the user equipment. When the first timer times out, the access network device may again notify the user equipment that the first multicast group should be released or deactivated, and may determine whether to release or deactivate the first multicast session based on the feedback of the user equipment.

[0176] In this application, a timer timing out can also be described as a timer expiring. This is not distinguished.

[0177] In some implementations, the preset condition being satisfied may alternatively be replaced by the access network device determining that the preset condition is satisfied, e.g., the access network device transmits the first message when the access network device determines that no data is transmitted in the first multicast session within a second preset period, or that the associated user equipment is not in the first multicast group, or that a first timer times out.

[0178] In some implementations, the access network device may broadcast the first message. For example, the access network device transmits the first message in a system information broadcast (SIB) manner. As another example, the access network device broadcasts the first message by using a multicast specific channel. In this case, the first message may include first information, which may be information used to uniquely determine the first multicast session. Optionally, the first information may be one or more of the following information: an identifier of the first multicast session, a group radio network temporary identity (G-RNTI) received by the multicast corresponding to the first multicast session, an identifier of the first multicast group, a temporary mobile group identifier (TMGI) of the first multicast group, an IP address of an application server corresponding to the first multicast session, a service identifier (service ID) corresponding to the first multicast session, packet filter information corresponding to the first multicast session, a service data flow (SDF) identification rule corresponding to the first multicast session, ID information of an application (application ID) corresponding to the first multicast session, target IP address information of multicast data of the first multicast session (IP multicast address), context identifier information of the first multicast session (multicast session context ID), etc.

[0179] In some other implementations, the access network device may alternatively transmit the first message by using a multicast transmission resource corresponding to the first multicast session. For example, the first message is a special RRC message, and the message may be received by user equipment in the first multicast group. In a possible manner, all user equipment in the first multicast group are configured with related configuration information to receive the message (for example, after the user equipment transmits a message used to request to join the first multicast group, the access network device or the core network device provides the configuration information to the user equipment). In this case, the first message may include the first information or may not include the first information. This is not particularly limited.

[0180] Optionally, the first message may be a dedicated message used to release or deactivate the multicast session.

[0181] Optionally, the first message may be a message used to collect statistics about the multicast data currently being received.

[0182] In the present application, after receiving a first message, the user equipment may determine whether to send a second message in response to the first message to the access network device based on whether data is being received or should be received by using the first multicast session.

[0183] Optionally, the second message may be used to request or inform that the first multicast session is to be released or deactivated, to indicate that data is being or should be received using the first multicast session, to simply respond to the first message (in this case, the user equipment may not need to send a response message if no data is being received using the first multicast session), to request that an RRC connection be established, and optionally to convey information about active multicast sessions, etc.

[0184] Optionally, the second message may be transmitted on time domain and / or frequency domain resources dedicated for multicast information transmission.

[0185] Optionally, the second message may be an air interface message, for example, the second message may be an RRC message.

[0186] Optionally, the second message may be a dedicated RRC message, e.g. dedicated to informing the access network device that the user equipment is receiving or is about to receive multicast data. The second message may include the above-mentioned first information, or the second message does not include the above-mentioned first information, and the first information is included in a subsequent RRC message.

[0187] Step 202: When the user equipment is receiving or is about to receive data by using the first multicast session, the user equipment sends a second message to the access network device in response to the first message.

[0188] When possible, before receiving the first message, a user equipment in an idle state or an RRC inactive state is receiving data by using the first multicast session or is receiving data of the first multicast session, and the user equipment transmits a second message to the access network device after receiving the first message.

[0189] It should be noted that the user equipment may be in an idle state or an RRC inactive state.

[0190] Step 203: If a second message in response to the first message is received within a first preset period after the first message is sent, the access network device maintains the first multicast session.

[0191] In other words, if the user equipment feedbacks to the access network device within a first preset period that the user equipment is receiving or is about to receive data by using the first multicast session, the access network device may maintain the first multicast session.

[0192] If the user equipment does not receive data by using the first multicast session, the user equipment may not send the second message to the access network device, where the user equipment does not receive data by using the first multicast session may be understood as the user equipment is not currently receiving data by using the first multicast session, the user equipment will not receive data by using the first multicast session in a future period, etc.

[0193] Step 204: If a second message in response to the first message is not received within a first preset period of time after the first message is sent, the access network device releases or deactivates the first multicast session.

[0194] In other words, if the user equipment does not feedback to the access network device within a first preset period that the user equipment is receiving or is about to receive data by using the first multicast session, the access network device considers that the first multicast session can be released or deactivated.

[0195] It should be noted that steps 202 to 204 are optional steps. For example, the method may include steps 202 and 203. As another example, the method may include step 204. As yet another example, the method may also include steps 202 to 204.

[0196] For example, if the access network device broadcasts a first message and receives a second message from the user equipment 1 responding to the first message within a first preset period, which indicates that the user equipment 1 is receiving or is about to receive data by using the first multicast session, the access network device may maintain the first multicast session to ensure the service transmission of the user equipment 1. It is clear that the access network device may further receive a second message from another user equipment responding to the first message. This is not limited. Correspondingly, a user equipment in an idle state or an RRC inactive state may receive data of the first multicast session by using the stored multicast reception parameters of the first multicast session.

[0197] It should be noted that maintaining the first multicast session can also be described as not releasing or deactivating the first multicast session, or giving up on releasing or deactivating the first multicast session, which is not limited in this embodiment of the present application.

[0198] In some implementations, after step 202, the method may further include: the access network device starts a first timer, and when the first timer expires, the access network device broadcasts a first message again to the user equipment to notify that the first multicast session should be released or deactivated. Further, the access network device may determine whether to release or deactivate the first multicast session based on the feedback of the user equipment, i.e., perform step 203 or step 204.

[0199] In the above method, when the preset condition is satisfied, the access network device notifies the user equipment that the first multicast session should be released or deactivated, so that the user equipment can feedback to the access network device whether the user equipment uses the first multicast session. In this way, the access network device determines whether the first multicast session should be continued to be released or deactivated based on the feedback of the user equipment. When the user equipment in an idle state can receive the multicast data, the multicast session can be managed appropriately.

[0200] Fig. 3 is a schematic flow chart of another communication method according to the present application. The method of Fig. 3 may be executed by an access network device, a core network device, and a user equipment, or may be executed by a module or unit in the access network device, the core network device, and the user equipment. In Fig. 3, an example is used in which the access network device, the core network device, and the user equipment are used as execution bodies. The method of Fig. 3 may include at least a part of the following contents.

[0201] Step 301: An access network device sends a first message when a preset condition is satisfied.

[0202] The first message may be used to notify that the first multicast session should be released or deactivated.

[0203] For a detailed description of step 301, please refer to step 201. The details will not be described again here.

[0204] Step 302: The access network device sends a third message to the core network device.

[0205] Correspondingly, the core network device receives a third message from the access network device.

[0206] The third message may be used to request that the first multicast session be released or deactivated.

[0207] Optionally, the third message may be an N2 message, for example, a UE context release message, a PDU session context change request message, a PDU context update request message, a PDU session release request message, or other dedicated message used to inform the core network device to release or deactivate the first multicast session (e.g., a multicast session deactivate message, a multicast session release message, a multicast session modify message, or a multicast session update message).

[0208] Optionally, the third message may include the first information in step 201 .

[0209] Step 303: When the user equipment is receiving or is about to receive data by using the first multicast session, the user equipment sends a second message to the access network device in response to the first message.

[0210] For a detailed description of step 303, please refer to step 202. The details will not be described again here.

[0211] Step 304: If a second message in response to the first message is received within a first preset period after the third message is sent, the access network device maintains the first multicast session.

[0212] Step 305: If a second message in response to the first message is received within a first preset period after the third message is sent, the access network device sends a fifth message to the core network.

[0213] The fifth message may be used to instruct to maintain the first multicast session.

[0214] Optionally, the fifth message may be an N2 message, for example, a UE context release message, a PDU session context change request message, a PDU context update request message, a PDU session release request message, or other dedicated message used to instruct the core network device to maintain the first multicast session (e.g., a multicast session deactivation message, a multicast session release message, a multicast session modification message, or a multicast session update message).

[0215] Optionally, the fifth message may include the first information in step 201.

[0216] Step 306: If the fifth message is received within a third preset period after the third message is received, the core network device maintains the first multicast session.

[0217] When the user equipment does not receive data by using the first multicast session, the user equipment does not need to send the second message to the access network device.

[0218] Step 307: If a second message in response to the first message is not received within a first preset period after the third message is sent, the access network device releases or deactivates the first multicast session.

[0219] Step 308: if the fifth message is not received within a third preset period after the third message is received, core The network device releases or deactivates the first multicast session.

[0220] It should be noted that steps 303 to 308 are optional steps. For example, the method may include steps 303 to 306. As another example, the method may include steps 307 and 308. As yet another example, the method may also include steps 303 to 308.

[0221] Optionally, after step 308, step 309 may further be executed.

[0222] Step 309: The core network device sends a fourth message to the access network device.

[0223] The fourth message may be used to indicate or inform the access network device that the core network device has released or deactivated the first multicast session.

[0224] Optionally, the fourth message may be a response message to the third message, such as a UE context response message, a PDU session context change response message, a PDU session context update response message, a PDU session release response message, or other dedicated message (e.g., a multicast session deactivation response message, a multicast session release response message, a multicast session change response message, or a multicast session update response message).

[0225] Optionally, after step 303, the method may further include: the access network device starts a first timer and periodically sends a first message to the user equipment to notify that the first multicast session should be released or deactivated. The above steps 302 to 306 are repeated, or the above steps 302 and 307 to 309 are repeated.

[0226] In the above method, the access network device sends a third message to the core network device before the first preset period. Before determining whether to release or deactivate the first multicast session, the access network device requests the core network device to release or deactivate the first multicast session. Thus, if the access network device receives the second message within the first preset period after sending the third message, the access network device can inform the core network device to maintain the first multicast session, so that the core network device maintains the first multicast session.

[0227] In the above method, the access network device requests the core network device to release or deactivate the first multicast session before the first preset period. In other words, the access network device requests the core network device to release or deactivate the first multicast session in advance without determining whether the first multicast session should be released or deactivated. In this way, the delay of releasing or deactivating the first multicast session can be reduced.

[0228] 4 is a schematic flow chart of another communication method according to the present application. The method in FIG. 4 may be executed by an access network device, a core network device, and a user equipment, or may be executed by a module or unit in the access network device, the core network device, and the user equipment. FIG. 4 is used in an example in which the access network device, the core network device, and the user equipment are used as execution bodies. 4 The method may include at least some of the following:

[0229] Step 401: An access network device sends a first message when a preset condition is satisfied.

[0230] The first message may be used to notify that the first multicast session should be released or deactivated.

[0231] For a detailed description of step 401, please refer to step 201. The details will not be described again here.

[0232] Step 402: When the user equipment is receiving or is about to receive data by using the first multicast session, the user equipment sends a second message to the access network device in response to the first message.

[0233] For a detailed description of step 402, please refer to step 202. The details will not be described again here.

[0234] Step 403: If a second message in response to the first message is received within a first preset period after the first message is sent, the access network device maintains the first multicast session.

[0235] Because the access network device determines not to release or deactivate the first multicast session, the access network device does not need to send a message to the core network device to instruct the core network device to make the change.

[0236] If the user equipment does not receive data by using the first multicast session, the user equipment does not need to send the second message to the access network device.

[0237] Step 404: If a second message in response to the first message is not received within a first preset period of time after the first message is sent, the access network device releases or deactivates the first multicast session.

[0238] Step 405: The access network device sends a third message to the core network device.

[0239] The third message may be used to request that the first multicast session be released or deactivated.

[0240] Optionally, the third message may be an N2 message, for example, a UE context release message, a PDU session context change request message, a PDU context update request message, a PDU session release request message, or other dedicated message used to inform the core network device to release or deactivate the first multicast session (e.g., a multicast session deactivate message, a multicast session release message, a multicast session modify message, or a multicast session update message).

[0241] Optionally, the third message may include the first information in step 201 .

[0242] Step 406: After the third message is received, the core network device releases or deactivates the first multicast session.

[0243] It should be noted that steps 402 to 406 are optional steps. For example, the method may include steps 402 and 403. As another example, the method may include steps 404 to 406. As yet another example, the method may also include steps 402 to 406.

[0244] Optionally, after step 406, step 407 may further be executed.

[0245] Step 407: The core network device sends a fourth message to the access network device.

[0246] The fourth message may be used to indicate or inform the access network device that the core network device has released or deactivated the first multicast session.

[0247] Optionally, the fourth message may be a response message to the third message, such as a UE context response message, a PDU session context change response message, a PDU session context update response message, a PDU session release response message, or other dedicated message (e.g., a multicast session deactivation response message, a multicast session release response message, a multicast session change response message, or a multicast session update response message).

[0248] Optionally, after receiving the second message, the method may further include: the access network device starting a first timer and periodically sending a first message to the user equipment to notify that the first multicast session should be released or deactivated. The above steps 402 and 403 are repeated, or the above steps 404 to 406 are repeated.

[0249] In the above method, the access network device may send a third message to the core network device after a first preset period. In other words, when the access network device decides to release or deactivate the first multicast session, the access network device sends a third message to the core network device to request the core network device to release or deactivate the first multicast session. In this case, after receiving the third message, the core network device releases or deactivates the first multicast session.

[0250] In the above method, the access network device requests the core network device to release or deactivate the first multicast session after a first preset period. In other words, the access network device requests the core network device to release or deactivate the first multicast session only after determining to release or deactivate the first multicast session. In this way, the implementation of the core network device is simple.

[0251] It should further be noted that the access network device may alternatively send the third message to the core network device within the first preset period.

[0252] The following describes the procedure for a user equipment to release an AN connection with reference to FIG.

[0253] Figure 5 is a schematic flow chart of releasing an AN connection by a user equipment. Figure 5 only briefly describes the procedure of releasing an AN connection. For specific details, please refer to the prior art.

[0254] Step 501: An access network device detects that a condition for releasing a context of a user equipment is satisfied.

[0255] For example, when the access network device detects that unicast signaling or data for a particular user equipment is not transmitted within a period of time (or may be described as a user inactivity timer expiring), the access network device triggers the release of the user equipment's context information.

[0256] Step 502: The access network device disassociates or releases the association relationship between the unicast and multicast of the user equipment, and releases the context information of the user equipment.

[0257] It may be understood that the access network device assumes that the user equipment does not continue to receive the multicast data of the first multicast session.

[0258] It should be noted that the association relationship between the unicast and multicast of the user equipment can also be described as an association relationship between the unicast session and the first multicast session of the user equipment, an association relationship between the user equipment and the first multicast session, etc. For simplicity of description, the association relationship between the unicast and multicast of the user equipment is described below.

[0259] In some implementations, the context information of the user equipment includes multicast information (e.g., the context information of the user equipment includes information about the first multicast group). In this manner, when the access network device deletes the context information of the user equipment, the access network device may be considered to disassociate or release the association relationship between the unicast and multicast of the user equipment.

[0260] Optionally, in this implementation, the access network device may not store information regarding a list of user devices receiving data corresponding to a multicast group (for simplicity of description, hereinafter referred to as information regarding the user device list).

[0261] In some other implementations, the user equipment context information does not include the multicast information, and the access network device stores information about the user equipment list separately, in which case the access network device may delete the user equipment context information and further delete the user equipment from the information about the user equipment list.

[0262] Optionally, the information regarding the user device list may be in the following format: [Table 1]

[0263] Step 503: The access network device sends an RRC connection release request message to the user equipment.

[0264] In response, the user equipment receives an RRC connection release request message from the access network device.

[0265] Step 504: The user equipment enters an idle state and saves the multicast receiving parameters of the connected state.

[0266] Optionally, the multicast reception parameters include one or more of the following parameters:

[0267] (a) G-RNTI received via multicast

[0268] (b) Bandwidth part (BPW) configuration information corresponding to a service: When receiving a service, the user equipment determines a subcarrier spacing (SCS), a frequency domain location, and a cyclic prefix (CP) length corresponding to the BWP based on the BPW configuration. The BPW configuration information further includes COREST configuration information for physical downlink control channel (PDCCH) detection, where the COREST configuration information indicates the time-frequency resource where the PDCCH is located when G-RNTI detection is performed.

[0269] (c) Physical downlink of the service share Control channel (physical downlink share channel, PDSCH) scrambling sequence: When decoding the PDSCH of a service, the user equipment performs descrambling based on the sequence.

[0270] (d) Discontinuous reception (DRX) parameters of G-RNTI: The user equipment performs G-RNTI detection based on the DRX parameters.

[0271] (e) Demodulation reference signal configuration: The user equipment demodulates the PDSCH scheduled by the G-RNTI based on the reference signal configuration.

[0272] (f) Rate matching reference signal information

[0273] When the user equipment continuously joins or leaves the first multicast group, the user equipment associated with the first multicast group changes. When the access network device detects that the associated user equipment is not in the first multicast group, the access network device may perform step 505.

[0274] Step 505: The access network device determines that a condition for releasing or deactivating the first multicast session is met.

[0275] If the access network device determines that the conditions for releasing or deactivating the first multicast session are satisfied, it may trigger the sending of the first message and subsequent steps (e.g., steps 202 to 204 shown in FIG. 2, steps 302 to 309 shown in FIG. 3, and steps 402 to 407 shown in FIG. 4).

[0276] In the methods shown in Figures 2-4, the user equipment feeds back to the access network device whether data is being received or should be received by using the first multicast session by using an air interface message. In some methods, the user equipment may further feed back to the access network device whether data is being received or should be received by using the first multicast session by using a core network device. The following describes the methods with reference to Figures 6-8.

[0277] Fig. 6 is a schematic flow chart of another communication method according to the present application. The method shown in Fig. 6 may be applied to the system architecture shown in Fig. 1 and the scenario shown in Fig. 2. However, this embodiment of the present application is not so limited.

[0278] The method of Fig. 6 may be performed by an access network device and a user equipment, or may be performed by a module or unit (for example, a circuit, a chip, or a SOC) in the access network device and the user equipment. In Fig. 6, an example is used in which the access network device and the user equipment are used as an execution body. The method of Fig. 6 may include at least a part of the following contents.

[0279] Step 601: The access network device sends a sixth message when a preset condition is satisfied.

[0280] The sixth message may be used to inform that the first multicast session should be released or deactivated.

[0281] For the implementation of step 601, please refer to step 201. The details will not be described again here. The sixth message may be the same as the first message.

[0282] In the method shown in Figure 6, after receiving the sixth message, the user equipment may determine whether data is being received or should be received by using the first message, and feed back the data to the access network device. Different from Figures 2 to 4, the user equipment feeds back to the access network device that data is being received or should be received by using the first multicast session by using the core network device.

[0283] Step 602: When the user equipment is receiving or is about to receive data by using the first multicast session, the user equipment sends a seventh message to the core network device.

[0284] If possible, before receiving the sixth message, a user equipment in an idle state or an RRC inactive state is receiving data by using the first multicast session or is receiving data of the first multicast session, and the user equipment sends a seventh message to the access network device after receiving the sixth message.

[0285] The seventh message may be used to request or inform that the first multicast session is to be released or deactivated, to indicate that data is being or should be received using the first multicast session, to simply respond to the sixth message (in this case, the user equipment may not need to send a response message if no data is being received using the first multicast session), to request that an RRC connection be established, and optionally to convey information about active multicast sessions, etc.

[0286] Optionally, the seventh message may be a service request message, a PDU session modification request message, or an uplink NAS transport message.

[0287] Optionally, the seventh message may include the first information.

[0288] Step 603: After receiving the seventh message, the core network device sends an eighth message to the access network device.

[0289] The eighth message may be used to request or inform that the first multicast session is to be released or deactivated, to indicate that data is being or should be received using the first multicast session, to simply respond to the sixth message (in this case, the user equipment may not need to send a response message if no data is being received using the first multicast session), to request that an RRC connection be established, and optionally to convey information about active multicast sessions, etc.

[0290] Optionally, the eighth message may be an N2 message.

[0291] Step 604: If the eighth message is received within a first preset period after the sixth message is sent, the access network device maintains the first multicast session.

[0292] If the user equipment does not receive data by using the first multicast session, the user equipment does not need to send the seventh message to the core network device.

[0293] Step 605: If the eighth message is not received within a first preset period after the sixth message is sent, the access network device releases or does not deactivate the first multicast session.

[0294] In other words, if the user equipment does not feedback to the access network device within a first preset period that the user equipment is receiving or is about to receive data by using the first multicast session, the access network device considers that the first multicast session can be released or deactivated.

[0295] It should be noted that steps 602 to 605 are optional steps. For example, the method may include steps 602 to 604. As another example, the method may include step 605. As yet another example, the method may also include steps 602 to 605.

[0296] It should be further noted that only the messages received and transmitted by the core network are described above, and the message interactions between the core network devices are not limited. For example, the core network devices include an AMF and an SMF. The AMF may receive the seventh message. After receiving the seventh message, the AMF may send an N11 message to the SMF to convey the information carried in the seventh message to the SMF. Then, the SMF sends an eighth message to the access network device.

[0297] For example, if the access network device broadcasts the sixth message and receives the eighth message of the user equipment 1 within the first preset period, which indicates that the user equipment 1 is receiving or is about to receive data by using the first multicast session, the access network device may maintain the first multicast session to ensure the service transmission of the user equipment 1. It is clear that the access network device may also receive the eighth message of other user equipments. This is not limited. Correspondingly, the user equipment in the idle state or the RRC inactive state may receive the data of the first multicast session by using the stored multicast receiving parameters of the first multicast session.

[0298] It should be noted that maintaining the first multicast session can also be described as not releasing or deactivating the first multicast session, or giving up on releasing or deactivating the first multicast session, which is not limited in this embodiment of the present application.

[0299] In some implementations, after step 603, the method may further include: the access network device starts a first timer, and when the first timer expires, the access network device broadcasts a sixth message again to the user equipment to notify that the first multicast session should be released or deactivated. Further, the access network device may determine whether to release or deactivate the first multicast session based on the feedback of the user equipment, i.e., perform step 604 or step 605.

[0300] In the embodiment of the present application, releasing or deactivating the first multicast session may be understood as releasing or deactivating a context of the first multicast session.

[0301] In the above method, when the preset condition is satisfied, the access network device informs the user equipment that the first multicast session should be released or deactivated, so that the user equipment may feedback to the core network device whether the user equipment uses the first multicast session, and then the core network device feedbacks to the access network device that the user equipment still uses the first multicast session. In this way, the access network device determines whether the first multicast session should be continued to be released or deactivated based on the feedback of the user equipment. When the user equipment in the idle state can receive the multicast data, the multicast session can be managed appropriately.

[0302] Figure 7 is a schematic flow chart of another communication method according to the present application. The method of Figure 7 may be executed by an access network device, a core network device, and a user equipment, or may be executed by a module or unit in the access network device, the core network device, and the user equipment. In Figure 7, an example is used in which the access network device, the core network device, and the user equipment are used as execution bodies. The method of Figure 7 may include at least a part of the following contents.

[0303] Step 701: The access network device sends a sixth message when a preset condition is satisfied.

[0304] The sixth message may be used to inform that the first multicast session should be released or deactivated.

[0305] For the implementation of step 701, please refer to step 601. The details will not be described again here.

[0306] Step 702: The access network device sends a ninth message to the core network device.

[0307] Correspondingly, the core network device receives a ninth message from the access network device.

[0308] The ninth message may be used to request that the first multicast session be released or deactivated.

[0309] The ninth message may be the third message described above.

[0310] Step 703: When the user equipment is receiving or is about to receive data by using the first multicast session, the user equipment sends a seventh message to the core network device.

[0311] For a detailed description of step 703, please refer to step 602. The details will not be described again here.

[0312] Step 704: After receiving the seventh message, the core network device sends an eighth message to the access network device.

[0313] For a detailed description of step 704, please refer to step 603. The details will not be described again here.

[0314] Step 705: If the eighth message is received within a first preset period after the ninth message is transmitted, the access network device maintains the first multicast session.

[0315] Step 706: If the eighth message is received within a first preset period after the ninth message is sent, the access network device sends a tenth message to the core network device.

[0316] The tenth message is used to instruct to maintain the first multicast session.

[0317] The tenth message may be the fifth message described above.

[0318] Step 707: If the tenth message is received within a third preset period after the ninth message is received, the core network device maintains the first multicast session.

[0319] If the user equipment does not receive data by using the first multicast session, the user equipment sends a seventh message core It does not have to be transmitted to a network device.

[0320] Step 708: If the eighth message is not received within a first preset period after the ninth message is transmitted, the access network device releases or deactivates the first multicast session.

[0321] Step 709: If the tenth message is not received within a third preset period after the ninth message is received, the core network device releases or deactivates the first multicast session.

[0322] It should be noted that steps 703 to 709 are optional steps. For example, the method may include steps 703 to 707. As another example, the method may include steps 708 and 709. As yet another example, the method may also include steps 703 to 709.

[0323] Optionally, after step 709, step 710 may further be executed.

[0324] Step 710: The core network device sends an eleventh message to the access network device.

[0325] The eleventh message may be used to indicate or inform the access network device that the core network device has released or deactivated the first multicast session. The eleventh message may be the fourth message described above.

[0326] Optionally, after step 704, the method may further include: the access network device starting a first timer and periodically sending a first message to the user equipment to notify that the first multicast session should be released or deactivated. The above steps 702 to 707 are repeated, or the above steps 702 and 708 to 710 are repeated.

[0327] In the above method, the access network device sends a ninth message to the core network device before the first preset period. Before determining whether the first multicast session should be released or deactivated, the access network device requests the core network device to release or deactivate the first multicast session. Thus, if the access network device receives the eighth message within the first preset period, the access network device may notify the core network device to maintain the first multicast session. If the tenth message sent by the access network device is not received within a third preset period after the ninth message is received, the core network device considers that the first multicast session may be released or deactivated.

[0328] In some other implementations, step 707 may be performed before step 705, that is, after receiving the seventh message, the core network device may know based on the seventh message that the user equipment is still using or about to use the first multicast session, and determine that the first multicast session should be maintained. In this case, step 706 may not be performed.

[0329] In the above method, the access network device requests the core network device to release or deactivate the first multicast session before the first preset period. In other words, the access network device requests the core network device to release or deactivate the first multicast session in advance without determining whether the first multicast session should be released or deactivated. In this way, the delay of releasing or deactivating the first multicast session can be reduced.

[0330] Figure 8 is a schematic flow chart of another communication method according to the present application. The method of Figure 8 may be executed by an access network device, a core network device, and a user equipment, or may be executed by a module or unit in the access network device, the core network device, and the user equipment. In Figure 8, an example is used in which the access network device, the core network device, and the user equipment are used as execution bodies. The method of Figure 8 may include at least a part of the following contents.

[0331] Step 801: The access network device sends a sixth message when a preset condition is satisfied.

[0332] The sixth message may be used to inform that the first multicast session should be released or deactivated.

[0333] For the implementation of step 801, please refer to step 601. The details will not be described again here.

[0334] Step 802: When the user equipment is receiving or is about to receive data by using the first multicast session, the user equipment sends a seventh message to the core network device.

[0335] For a detailed description of step 802, please refer to step 602. The details will not be described again here.

[0336] Step 803: After receiving the seventh message, the core network device sends an eighth message to the access network device.

[0337] For a detailed description of step 803, please refer to step 603. The details will not be described again here.

[0338] Step 804: If the eighth message is received within a first preset period after the sixth message is transmitted, the access network device maintains the first multicast session.

[0339] Because the access network device determines not to release or deactivate the first multicast session, the access network device does not need to send a message to the core network device to instruct the core network device to make the change.

[0340] Step 805: If the eighth message is not received within a first preset period after the sixth message is transmitted, the access network device releases or deactivates the first multicast session.

[0341] Step 806: If the eighth message is not received within a first preset period after the sixth message is sent, the access network device sends a ninth message to the core network device.

[0342] The ninth message may be used to request that the first multicast session be released or deactivated. The ninth message may be the third message described above.

[0343] Step 807: If the ninth message is received, the core network device releases or deactivates the first multicast session.

[0344] It should be noted that steps 802 to 807 are optional steps. For example, the method may include steps 802 to 804. As another example, the method may include steps 805 to 807. As yet another example, the method may also include steps 802 to 807.

[0345] Optionally, after step 807, step 808 may further be executed.

[0346] Step 808: The core network device sends an eleventh message to the access network device.

[0347] The eleventh message may be used to indicate or inform the access network device that the core network device has released or deactivated the first multicast session. The eleventh message may be the fourth message described above.

[0348] Optionally, after step 803, the method may further include: the access network device starts a first timer and periodically sends a first message to the user equipment to notify that the first multicast session should be released or deactivated. The above steps 802 to 804 are repeated, or the above steps 805 to 808 are repeated.

[0349] In the above method, the access network device may send a ninth message to the core network device after a first preset period. In other words, when the access network device decides to release or deactivate the first multicast session, the access network device sends a ninth message to the core network device to request the core network device to release or deactivate the first multicast session. In this case, after receiving the ninth message, the core network device releases or deactivates the first multicast session.

[0350] In the above method, the access network device requests the core network device to release or deactivate the first multicast session after a first preset period. In other words, the access network device requests the core network device to release or deactivate the first multicast session only after determining to release or deactivate the first multicast session. In this way, the implementation of the core network device is simple.

[0351] It should further be noted that the access network device may alternatively send the ninth message to the core network device within the first preset period.

[0352] In an embodiment of the present application, at least one of the first preset period, the second preset period, and the third preset period may be implemented by using a timer.

[0353] The following describes in detail the technical solutions of the embodiments of the present application with reference to specific examples.

[0354] Example 1

[0355] Figure 9 is an example of a communication method according to the present application. In Figure 9, an example is used in which the core network device includes an AMF, an SMF, and a UPF. In this example, if there is no feedback from the user equipment within a first preset period, the multicast session is still released.

[0356] Step 901: An access network device detects that a condition for releasing a context of a user equipment is satisfied.

[0357] It can be understood that the access network device triggers the AN release of the user equipment.

[0358] Step 902: The access network device disassociates or releases the association relationship between the unicast and multicast of the user equipment, and releases the context information of the user equipment.

[0359] It may be understood that the access network device assumes that the user equipment does not continue to receive the multicast data of the first multicast session.

[0360] Step 903: The access network device sends an RRC connection release request message to the user equipment.

[0361] In response, the user equipment receives an RRC connection release request message from the access network device.

[0362] Step 904: The user equipment enters an idle state and saves the multicast receiving parameters of the connected state.

[0363] Step 905: The access network device determines that a condition for releasing or deactivating the first multicast session is met.

[0364] For a more detailed description of steps 901 to 905, please refer to steps 501 to 505. The details will not be described again here.

[0365] Step 906: The access network device sends a message to the user equipment to inform the user equipment that the first multicast session should be released or deactivated. The message may be the first message or the sixth message described above.

[0366] The access network device may send a message in a broadcast manner. For example, the access network device sends a message in a SIB manner. As another example, the access network device broadcasts a message by using a multicast specific channel.

[0367] In this case, the first message may include the first information, and the first information may be information used to uniquely determine the first multicast session. Optionally, the first information may be one or more of the following information: an identifier of the first multicast session, a G-RNTI corresponding to the first multicast session, an identifier of the first multicast group, a TMGI of the first multicast group, an IP address of an application server corresponding to the first multicast session, a service identifier corresponding to the first multicast session, packet filtering information corresponding to the first multicast session, an SDF identification rule corresponding to the first multicast session, ID information of an application corresponding to the first multicast session, target IP address information of multicast data of the first multicast session, context identifier information of the first multicast session, etc.

[0368] Alternatively, the access network device may send the first message by using a multicast transmission resource corresponding to the first multicast session, in which case the message may include the first information or may not include the first information, which is not particularly limited.

[0369] Optionally, the message may be a dedicated message used to release or deactivate a multicast session.

[0370] Optionally, the message may be a message used to gather statistics about the multicast data currently being received.

[0371] Step 907: The access network device sends the message to the SMF.

[0372] The message may be used to request to release or deactivate the first multicast session (release is used as an example in FIG. 8). Alternatively, it may be described as the message being used to release or deactivate the multicast transmission channel between the UPF and the RAN 102.

[0373] The UPF and SMF here may be UPF and SMF configured to transmit downlink multicast data.

[0374] The message may be a dedicated message used for multicast, or the request may be sent to the core network device by using a unicast message. For example, the access network device sends the message to the AMF by using an N2 message, and then the AMF sends the message to the SMF that manages the "unicast session related to multicast". Optionally, the SMF may further send the information to the multicast SMF. The N2 message may be a UE NGAP message corresponding to a next generation application protocol (NGAP) UE RAN / AMF id, such as a UE context release message.

[0375] Step 908: The access network device locally starts a second timer.

[0376] The time period of the second timer is the first preset period described above.

[0377] Optionally, the access network device may start a second timer when or after sending the message in step 908, or when or after sending the message in step 807.

[0378] Step 909: The SMF locally starts a third timer.

[0379] The time period of the third timer is the third preset period mentioned above.

[0380] Optionally, the SMF may start a third timer when sending the message in step 908 or after sending the message.

[0381] The functions of the second and third timers are as follows: if the first multicast session is not prevented from being subsequently released or deactivated, when the timers expire, the devices corresponding to the timers may release or deactivate the locally stored multicast context information of the first multicast session. Thus, both the second and third timers are maintained to release or deactivate the downlink channel of the first multicast session. That is, the second and third timers are related to the downlink transmission channel between the UPF of the first multicast session and the RAN 102.

[0382] Step 910: A second timer of the access network device expires.

[0383] Step 911: The third timer of the SMF expires.

[0384] The expiration of the second timer indicates that the user equipment does not feedback that the first multicast session is in use or should be in use within the time period of the second timer. The same applies to the third timer.

[0385] For example, the first multicast session is released when the second timer and the third timer expire. After the second timer expires, execution continues with step 912, and after the third timer expires, execution continues with step 913.

[0386] Step 912: The access network device releases the locally stored multicast context information of the first multicast session.

[0387] For example, the access network device may release information regarding the user equipment list in step 502 .

[0388] Step 913: The SMF releases the locally stored multicast context information of the first multicast session.

[0389] For example, the context released by the SMF may be a stored address identification information of the access network device, such as a tunnel ID of the access network device.

[0390] Optionally, the SMF may further notify the UPF to release the associated context, which may include one or more of the following: address identification information of the access network device stored in the UPF, data forwarding rules configured locally in the UPF, etc. Releasing the data forwarding rules configured locally in the UPF may be to delete the forwarding rules themselves or to change the forwarding rules, for example to set "no forwarding".

[0391] If the first multicast session is deactivated when the second timer and the third timer expire, the access network device and the SMF may perform the following procedure.

[0392] The access network device releases the locally stored multicast context information for the first multicast session.

[0393] The SMF deletes the locally stored access network related information for the first multicast session.

[0394] For example, the content deleted by the SMF may be stored address identification information of the access network device, such as a tunnel ID of the access network device.

[0395] Optionally, the SMF may further notify the UPF to change the current processing rules of the multicast data, including one or more of the following: a forwarding action rule (FAR), for example, after receiving downlink multicast data corresponding to a multicast session, the UPF does not forward the data to a specific access network device, and a notification rule, for example, after receiving downlink multicast data corresponding to a multicast session, the UPF reports to the SMF that the downlink data has been received.

[0396] In example 1, the access network device may notify the user equipment that the first multicast session should be released or deactivated, so that the user equipment can feedback to the access network device that the user equipment is still interested in the multicast session. This helps the access network device to decide whether to subsequently release or deactivate the downlink transmission channel. Furthermore, the access network device and the core network device separately maintain a timer, and separately delete the downlink transmission channel of the first multicast session when the timer expires. The advantage of this is that the notification message notified by the access network device to the core network device may rely on "unicast signaling of the last remaining user equipment", and the existing procedure is hardly changed.

[0397] Example 2

[0398] Figure 10 is another example of a communication method according to the present application. In Figure 10, an example is used in which the core network device includes an AMF, an SMF, and a UPF. In this example, if there is no feedback from the user equipment within a first preset period, the multicast session is subsequently released or deactivated.

[0399] The difference between this example and example 1 is that the access network device notifies the SMF to release or deactivate the first multicast session upon expiration of the second timer only if the access network device does not receive feedback from the user equipment.

[0400] For the implementation of steps 1001 to 1006 in this example, please refer to steps 901 to 906. The details will not be described again here.

[0401] Step 1007: The access network device locally starts a second timer.

[0402] The time period of the second timer is the first preset period described above.

[0403] Optionally, the access network device comprises steps 1006 A second timer may be started locally when sending the message or after sending the message.

[0404] For an explanation of the second timer, please refer to the related description of FIG.

[0405] Step 1008: A second timer of the access network device expires.

[0406] The expiration of the second timer indicates that the user equipment does not feedback that the first multicast session should be used within the time period of the second timer.

[0407] For example, the first multicast session is released when the second timer expires. After the second timer expires, steps 1009 to 1011 are subsequently executed.

[0408] Step 1009: The access network device releases the locally stored multicast context information of the first multicast session.

[0409] For example, the access network device may release information regarding the user equipment list in step 502 .

[0410] Step 1010: The access network device sends a message to the SMF.

[0411] The message may be used to request to release the first multicast session, or it may be described that the message is used to release or deactivate the multicast transmission channel between the UPF and the RAN 102.

[0412] The UPF and SMF here may be UPF and SMF configured to transmit downlink multicast data.

[0413] Step 1011: The SMF releases the locally stored multicast context information of the first multicast session.

[0414] For example, the context released by the SMF may be a stored address identification information of the access network device (e.g., a tunnel ID of the access network device).

[0415] Optionally, the SMF may further notify the UPF to release the associated context, which may include one or more of the following: address identification information of the access network device stored in the UPF, data forwarding rules configured locally in the UPF, etc. Releasing the data forwarding rules configured locally in the UPF may be to delete the forwarding rules themselves or to change the forwarding rules, for example to set "no forwarding".

[0416] It should be noted that the order of step 1009 and step 1010 is not limited in this embodiment of the present application.

[0417] If the first multicast session is deactivated when the second timer expires, the access network device and the SMF may perform the following procedure.

[0418] The access network device releases the locally stored multicast context information for the first multicast session.

[0419] The SMF deletes the locally stored access network related information for the first multicast session.

[0420] For example, the content deleted by the SMF may be the stored address identification information of the access network device (the tunnel ID of the access network device).

[0421] Optionally, the SMF may further notify the UPF to change the current processing rules of the multicast data, including one or more of the following: forwarding rules, for example, after receiving downlink multicast data corresponding to the multicast session, the UPF does not forward the data to a specific access network device, and notification rules, for example, after receiving downlink multicast data corresponding to the multicast session, the UPF reports to the SMF that the downlink data has been received.

[0422] In example 2, the access network device may inform the user equipment that the first multicast session should be released or deactivated, so that the user equipment can feedback to the access network device that the user equipment is still interested in the multicast session. This helps the access network device to decide whether to subsequently release or deactivate the downlink transmission channel. Furthermore, the access network device maintains a timer. When the timer expires, the access network device notifies the core network device to delete the downlink transmission channel of the first multicast session and release the first multicast session. The advantage of this is that the core network device does not need to maintain a timer, and it is simple to implement.

[0423] Example 3

[0424] Figure 11 is another example of the communication method according to the present application. In Figure 11, an example is also used in which the core network device includes an AMF, an SMF, and a UPF. In this example, if there is feedback from the user equipment within a first preset period, the access network device and the core network device give up releasing or deactivating the first multicast session. In this example, the user equipment feeds back to the access network device by using the core network device that the user equipment is using or about to use the first multicast session.

[0425] For the implementation of steps 1101 to 1106 in this example, please refer to steps 901 to 906. The details will not be described again here.

[0426] Step 1107: The access network device locally starts a second timer.

[0427] The time period of the second timer is the first preset period described above.

[0428] Optionally, the access network device may locally start a second timer when sending the sixth message in step 1106 or after sending the message.

[0429] For an explanation of the second timer, see Figure 9 Please refer to the related description in.

[0430] Step 1108: After receiving the sixth message or when receiving the first message, the user equipment determines that multicast data is being received or should be received by using the first multicast session.

[0431] Step 1009: The user equipment feedbacks to the access network device that the user equipment is using or is about to use the first multicast session.

[0432] Because the user equipment may continue to receive multicast data by using the first multicast session, the user equipment may send a message to the access network device to inform the access network device that the user equipment is using or is about to use the first multicast session, so that the network side is prevented from releasing or deactivating the first multicast session.

[0433] Optionally, the message sent by the user equipment may include second information, which may include one or more of the following information: (a) a unicast PDU session identifier corresponding to the multicast service, e.g., a PDU Session ID; and (b) A multicast service identification.

[0434] The identification information of the multicast service may be one or more of the following information: an identifier of the first multicast session, a G-RNTI corresponding to the first multicast session, an identifier of the first multicast group, a TMGI of the first multicast group, an IP address of an application server corresponding to the first multicast session, a service identifier corresponding to the first multicast session, packet filtering information corresponding to the first multicast session, an SDF identification rule corresponding to the first multicast session, ID information of an application corresponding to the first multicast session, target IP address information of multicast data of the first multicast session, context identifier information of the first multicast session, etc.

[0435] In FIG. 11, an example is used in which a core network device sends a message to an access network device.

[0436] In some implementations, step 1109 may be specifically implemented by using step 1109-1, step 1109-2, and step 1109-3.

[0437] Step 1109-1: The access network device sends a NAS message to the AMF. Correspondingly, the AMF receives the NAS message sent by the user equipment.

[0438] Optionally, the NAS message may include the above second information.

[0439] Optionally, the NAS message may be a service request message.

[0440] Step 1109-2: After receiving the NAS message, the AMF sends an N11 message to the SMF based on the PDU session ID included in the NAS message and the locally stored correspondence between the PDU session ID and the SMF. The SMF receives the N11 message accordingly.

[0441] The N11 message may include the second information described above.

[0442] Step 1109-3: After receiving the N11 message, the SMF initiates a subsequent procedure of sending the context information of the user equipment to the access network device. Specifically, the SMF sends an N2 message to the access network device. The N2 message includes relevant information of the multicast service. For example, the N2 message may include the identification information of the multicast service, the multicast service QoS information, etc.

[0443] In some implementations, if the information used for multicasting is stored in an SMF (hereinafter referred to as M-SMF) that manages the multicast service, the SMF finds the corresponding M-SMF after receiving the N11 message. For example, based on the locally stored association relationship between the PDU session ID and the multicast service (including the identification information of the M-SMF), the SMF sends an N16 message to the M-SMF to initiate the subsequent procedure of sending the context information of the user equipment to the access network device. For example, the SMF obtains the corresponding multicast session identifier and the latest QoS parameters from the M-SMF.

[0444] In some other implementations, if the information used for multicasting is stored in the SMF instead of the M-SMF, the SMF does not need to interact with the M-SMF. In other words, after receiving the N11 message, the SMF initiates a subsequent procedure of sending the user equipment context information to the access network device without interacting with the M-SMF.

[0445] Step 1110: After receiving the N2 message, the access network device terminates the second timer in step 1107, and gives up on releasing or deactivating the first multicast session.

[0446] When the access network device sends, after step 1105, to the SMF a message used to request the first multicast session to be released or deactivated, the SMF may further stop the corresponding count of the third timer based on the identification information of the multicast data.

[0447] In example 3, the access network device may inform the user equipment that the first multicast session should be released or deactivated, so that the user equipment can feedback to the access network device that the user equipment is still interested in the multicast session. This helps the access network device to decide whether to subsequently release or deactivate the downlink transmission channel. Furthermore, in example 3, since the user equipment initiates a NAS procedure, the core network device cancels the timer and further instructs the RAN to cancel the timer.

[0448] Example 4

[0449] Figure 12 is another example of a communication method according to the present application. In Figure 12, an example is also used in which the core network device includes an AMF, an SMF, and a UPF. In this example, the user equipment feeds back to the access network device that the user equipment is using or about to use the first multicast session by using an RRC message or other type of air interface message.

[0450] In this example, for the implementation of step 1201, please refer to the description of step 201, for the implementation of step 1202, please refer to the description of step 1006, and for the implementation of step 1203, please refer to the description of step 1007. The details will not be described again here.

[0451] After sending the first message or the sixth message (hereinafter, the first message is used as an example), and gradually starting the timer, the access network device may perform steps 1204 to 1211.

[0452] Step 1204: After receiving the first message or when receiving the first message, the user equipment determines that multicast data is being received or should be received by using the first multicast session.

[0453] Step 1205: The user equipment sends an RRC message or other type of air interface message to the access network device to inform the access network device that the user equipment is using or is about to use the first multicast session.

[0454] Since the user equipment determines to continue receiving the multicast data by using the first multicast session, the user equipment may send an RRC message or other type of air interface message to the access network device to inform the access network device that the user equipment is using or is about to use the first multicast session, so that the network side is prevented from releasing or deactivating the first multicast session.

[0455] The RRC message or other types of air interface messages may include the above second information. For a description of the second information, please refer to the above description. Details will not be described again here.

[0456] Step 1206: After receiving an RRC message or other type of air interface message, the access network device terminates the count of the second timer and gives up on releasing or deactivating the first multicast session.

[0457] If the access network device has sent a message to the core network device used to request the release or deactivation of the first multicast session after receiving an RRC message or other type of air interface message, the access network device may further instruct the core network device to stop a corresponding count of the third timer.

[0458] For example, the access network device sends a message to the core network device after a first preset period of time, which is used to request the first multicast session to be released or deactivated.

[0459] Step 1207: The access network device detects that the second timer expires.

[0460] Step 1208: The access network sends a message to the AMF.

[0461] The message may be used to request that the first multicast session be released or deactivated.

[0462] Step 1209: The AMF and SMF perform signaling interaction.

[0463] For details, please refer to the description of steps 1109-2 and 1109-3, and the details will not be described again here.

[0464] Step 1210: The AMF sends a response message to the access network device to instruct the access network device to keep the first multicast session released or inactive.

[0465] Step 1211: The access network device releases or deactivates the first multicast session.

[0466] In other words, the access network device releases the locally stored multicast context information of the first multicast session.

[0467] It should be noted that if step 1211 is performed before step 1210 (i.e., when the second timer expires, the access network device may release or deactivate the first multicast session without waiting for an instruction from the core network device), the response message may be used to inform the access network device that the core network device has released or deactivated the first multicast session.

[0468] It should be noted that steps 1204 to 1211 are optional steps. For example, the method may include steps 1204 to 1206. As another example, the method may include steps 1207 to 1211. As yet another example, the method may also include steps 1204 to 1211.

[0469] In Example 4, the access network device may inform the user equipment that the first multicast session should be released or deactivated, so that the user equipment can feedback to the access network device that the user equipment is still interested in the multicast session. This helps the access network device to decide whether to subsequently release or deactivate the downlink transmission channel. Furthermore, in Example 4, the user equipment informs the network side that the user equipment is receiving or is about to receive multicast data by using the first multicast session by using an RRC message or other type of air interface message.

[0470] It should be noted that in the embodiment of the present application, after sending a specific message may be understood as after the message starts to be sent or after the message is sent. This is not limited. It should be noted that in the embodiment of the present application, after receiving a specific message may be understood as after the message starts to be received or after the message is received. This is not limited.

[0471] It should be understood that the solutions of the embodiments of the present application may be appropriately combined for use, and the explanation or description of the terms of the embodiments may be cross-referenced or explained in the embodiments. This is not limited.

[0472] It should be further understood that the sequence numbers of the above processes do not imply an execution order in the embodiments of the present application, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0473] The method provided in the embodiment of the present application is described above in detail with reference to Figures 2 to 12. The apparatus provided in the embodiment of the present application is described below in detail with reference to Figures 13 to 15.

[0474] 13 is a schematic block diagram of a communication device according to an embodiment of the present application. The communication device 1300 shown in FIG. 13 may include a transceiver unit 1310 and a processing unit 1320.

[0475] The transceiver unit 1310 may include a transmitting unit and / or a receiving unit. The transceiver unit 1310 may be a transceiver (including a transmitter and / or a receiver), an input / output interface (including an input interface and / or an output interface), a pin, a circuit, etc. The transceiver unit 1310 may be configured to perform the transmitting and / or receiving steps of the above method embodiments.

[0476] The processing unit 1320 may be a processor (which may include one or more processors), a processing circuit with processor functionality, etc., and may be configured to perform steps other than transmitting and receiving in the method embodiments described above.

[0477] Optionally, the communication device may further include a storage unit, which may be a memory, an internal storage unit (e.g., a register or a cache), an external storage unit (e.g., a read-only memory or a random access memory), etc. The storage unit is configured to store instructions, and the processing unit 1320 executes the instructions stored in the storage unit, thereby causing the communication device to perform the above-mentioned methods.

[0478] In design, the communications apparatus 1300 may correspond to an access network device in any one of the methods presented above and may perform operations performed by an access network device in a corresponding manner.

[0479] For example, the transceiver unit 1310 is configured to broadcast a first message when a preset condition is satisfied, the first message being used to notify that the first multicast session should be released or deactivated, and the processing unit 1320 is configured to release or deactivate the first multicast session when a second message in response to the first message is not received within a first preset period, and / or to maintain the first multicast session when a second message in response to the first message is received within a first preset period.

[0480] As another example, the transceiver unit 1310 is configured to broadcast a sixth message when a preset condition is satisfied, the sixth message being used to notify that the first multicast session should be released or deactivated. The processing unit 1320 is configured to release or deactivate the first multicast session when the eighth message is not received from the core network device within a first preset period, and / or to maintain the first multicast session when the eighth message is received from the core network device within a first preset period, the eighth message being used by the user equipment to request to join the first multicast session.

[0481] It should be understood that the transceiver unit 1310 and the processing unit 1320 may further perform other operations performed by an access network device in any one of the methods described above, and the details will not be described again here.

[0482] In design, the communications apparatus 1300 may correspond to a user equipment in any one of the methods described above and may perform operations performed by a user equipment in a corresponding manner.

[0483] For example, the transceiver unit 1310 is configured to receive a first message from the access network device, where the first message is used to notify that a first multicast session should be released or deactivated, and to send a second message to the access network device in response to the first message if the first multicast session is in use or should be used.

[0484] As another example, the transceiver unit 1310 is configured to receive a sixth message from the access network device, where the sixth message is used to notify that the first multicast session should be released or deactivated, and send a seventh message to the core network device when data is being received or should be received by using the first multicast session, where the seventh message is used to request to join the first multicast session.

[0485] It should be understood that the transceiver unit 1310 and the processing unit 1320 may further perform other operations performed by a user equipment in any one of the methods described above, and the details will not be described again here.

[0486] In design, the communications apparatus 1300 may correspond to a core network device in any one of the methods presented above and may perform operations performed by a core network device in a corresponding manner.

[0487] For example, the transceiver unit 1310 is configured to receive a third message from the access network device, where the third message is used to request to release or deactivate the first multicast session, and the processing unit 1320 is configured to release or deactivate the first multicast session based on the third message.

[0488] As another example, the transceiver unit 1310 is configured to receive a third message from the access network device, the third message being used to request to release or deactivate the first multicast session, and the processing unit 1320 is configured to release or deactivate the first multicast session if a fifth message is not received within a third preset period, and / or to maintain the first multicast session if a fifth message is received within a third preset period, the fifth message indicating to maintain the first multicast session.

[0489] As yet another example, the transceiver unit 1310 is configured to receive a seventh message from a user device, where the seventh message is used to request joining the first multicast session, and to send an eighth message to the access network device, where the eighth message is used to request adding the user device to the first multicast session.

[0490] As yet another example, the transceiver unit 1310 is configured to receive a ninth message from the access network device, the ninth message being used to request to release or deactivate the first multicast session. The processing unit 1320 is further configured to release or deactivate the first multicast session if the seventh message is not received from the user equipment within a second preset period, and / or to maintain the first multicast session if the seventh message is received from the user equipment within a second preset period, and to send an eighth message to the access network device, the eighth message being used to request to add the user equipment to the first multicast session, and the seventh message being used to request to join the first multicast session.

[0491] It should be understood that the transceiver unit 1310 and the processing unit 1320 may further perform other operations performed by a core network device in any one of the above methods, and the details will not be described again here.

[0492] The above division of units is merely a functional division, and there may be other division methods in actual implementation.

[0493] It should be further understood that the processing unit may be implemented using hardware, software, or a combination of software and hardware.

[0494] 14 is a schematic diagram of the structure of a communication device according to the present application. As shown in FIG. 14, a communication device 1400 may implement functions that may be performed by any network element in any one of the above method embodiments.

[0495] The communications device 1400 may include a processor 1410. The processor 1410 may also be referred to as a processing unit and may implement certain control functions. The processor 1410 may be configured to control the communications device 1400, execute software programs, and process data for the software programs.

[0496] In any design, the processor 1410 may further store instructions and / or data. The instructions and / or data may be executed by the processor 1410, thereby causing the communications device 1400 to perform the methods described in the method embodiments above.

[0497] Optionally, the communication device 1400 may include a memory 1420. The memory 1420 may store instructions, which may be executed by the processor, such that the communication device 1400 performs the methods described in the method embodiments above. Optionally, the memory may further store data. Optionally, the processor may also store instructions and / or data. The processor and the memory may be located separately or may be integrated. For example, the correspondences described in the method embodiments above may be stored in the memory or in the processor.

[0498] Optionally, the communications device 1400 may include a baseband circuit 1430, which is primarily configured to perform baseband processing.

[0499] Optionally, the communication device 1400 may include a radio frequency circuit 1440. The radio frequency circuit 1440 is mainly configured to transmit and receive radio frequency signals and perform conversion between baseband signals and radio frequency signals, for example, configured to transmit BAR frames in the above method embodiments. The radio frequency circuit 1440 may also be referred to as a transceiver unit, a transceiver machine, a transceiver circuit, a transceiver, etc.

[0500] Optionally, the communications device 1400 may include an antenna 1450 primarily configured to transmit and receive signals.

[0501] Optionally, the communications device 1400 may include a bus 1460 configured to couple portions of the communications device 1400 , such as the processor 1410 , the memory 1420 , the baseband circuitry 1430 , the radio frequency circuitry 1440 , and the antenna 1450 .

[0502] Fig. 15 is a schematic diagram of the structure of a communication device according to the present application. For ease of description, Fig. 15 only shows the main components of the communication device 1500. The communication device 1500 may implement the functions of the user device in any one of the above method embodiments.

[0503] As shown in FIG. 15, a communications device 1500 includes a processor and a memory.

[0504] Optionally, the communication device 1500 includes control circuitry, an antenna, and input / output devices.

[0505] The processor is primarily configured to process communication protocols and communication data, control the entire communication device 1500, execute software programs, and process data of the software programs, for example, to help the communication device 1500 perform the operations performed by the user equipment described in the above method embodiments. The memory is primarily configured to store software programs and data. The control circuitry is primarily configured to convert baseband signals and radio frequency signals, and process radio frequency signals. The control circuitry and antenna, collectively, may also be referred to as a transceiver, are primarily configured to receive and transmit radio frequency signals in the form of electromagnetic waves. The input / output device, such as a touch screen, display, or keyboard, is primarily configured to receive data input by a user and output data to the user.

[0506] After the communication device 1500 is powered on, the processor may read the software program in the storage unit, interpret and execute the instructions of the software program, and process the data of the software program. When data needs to be transmitted wirelessly, the processor performs baseband processing on the data to be transmitted, and then outputs the baseband signal to the radio frequency circuit. The radio frequency circuit performs radio frequency processing on the baseband signal, and then transmits the radio frequency signal in the form of electromagnetic waves by using an antenna. When data is transmitted to the communication device 1500, the radio frequency circuit receives the radio frequency signal by using an antenna, converts the radio frequency signal into a baseband signal, and outputs the baseband signal to the processor. The processor converts the baseband signal into data and processes the data.

[0507] Those skilled in the art may understand that for simplicity of description, Fig. 15 shows only one memory and one processor. In the actual communication device 1500, there may be multiple processors and memories. The memory may also be referred to as a storage medium, a storage device, etc. This is not limited in this embodiment of the present application.

[0508] In any implementation, the processor may include a baseband processor and a central processing unit. The baseband processor is mainly configured to process communication protocols and communication data, and the central processing unit is mainly configured to control the entire communication device 1500, execute software programs, and process data of the software programs. The functions of the baseband processor and the central processing unit are incorporated into the processor in FIG. 15. Those skilled in the art may understand that the baseband processor and the central processing unit may be independent processors and are interconnected by using a technology such as a bus. Those skilled in the art may understand that the communication device 1500 may include multiple baseband processors to accommodate different new network standards, the communication device 1500 may include multiple central processing units to improve the processing power of the communication device 1500, and the components of the communication device 1500 may be connected by various buses. The baseband processor may alternatively be referred to as a baseband processing circuit or a baseband processing chip. The central processing unit may alternatively be referred to as a central processing circuit or a central processing chip. The functionality for processing the communication protocol and communication data may be built into the processor or may be stored in a storage unit in the form of a software program, and the processor executes the software program to implement the baseband processing functionality.

[0509] For example, in this embodiment of the present application, the antenna with transmitting and receiving functions and the control circuitry may be considered as the transceiver unit 1510 of the communication device 1500, and the processor with processing functions may be considered as the processing unit 15200 of the communication device 1500. As shown in FIG. 15, the communication device 1500 includes a transceiver unit 1510 and a processing unit 1520. The transceiver unit may also be referred to as a transceiver, a transceiver machine, a transceiver device, etc. Optionally, a component configured to implement a receiving function in the transceiver unit 1510 may be considered as a receiving unit, and a component configured to implement a transmitting function in the transceiver unit 150 may be considered as a transmitting unit. In other words, the transceiver unit 1510 includes a receiving unit and a transmitting unit. For example, the receiving unit may be referred to as a receiver, a receiving machine, or a receiving circuit, and the transmitting unit may be referred to as a transmitter, a transmitting machine, or a transmitting circuit.

[0510] It should be noted that the processor of the embodiments of the present application may be an integrated circuit chip and is equipped with signal processing capabilities. In the implementation process, the steps in the above method embodiments may be implemented by using hardware integrated logic circuits in the processor or by using instructions in the form of software. The processor may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, a system on chip (SoC), a central processing unit (CPU), a network processor (NP), a microcontroller unit (MCU), a programmable logic device (PLD), or other integrated chip. It may be understood that the memory of the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include a volatile memory and a non-volatile memory. Non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) or flash memory. Volatile memory may be random access memory (RAM) used as an external cache.By way of example and not limitation, many forms of RAM may be used, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus dynamic random access memory (DR RAM). The memory of the systems and methods described herein includes, but is not limited to, these and any other suitable types of memory.

[0511] According to the method provided in the embodiment of the present application, the present application further provides a computer program product, which includes computer program code, which, when executed on a computer, can cause the computer to perform the operations performed by any network element (e.g., user equipment, access network device, and core network device) in any one of the above method embodiments.

[0512] According to the method provided in the embodiment of the present application, the present application further provides a computer-readable medium. The computer-readable medium stores a program code. When the computer program code is executed on a computer, the computer can perform the operations performed by any network element (e.g., user equipment, access network device, and core network device) in any one of the above method embodiments.

[0513] According to the method provided in the embodiment of the present application, the present application further provides a system, which includes one or more network elements in the above embodiment of the method.

[0514] An embodiment of the present application further provides a communication device including a processor and an interface, the processor being configured to perform the method in any one of the above method embodiments.

[0515] It should be understood that the communication device may be a chip. For example, the processing device may be a field programmable gate array (FPGA), a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), other programmable logic devices, discrete gates, transistor logic devices, or discrete hardware components, a system on chip (SoC), a central processing unit (CPU), a network processor (NP), a digital signal processor (DSP), a micro controller unit (MCU), or a programmable logic device (PLD) or other integrated chip. It may implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor, or the processor may be any conventional processor, etc. The steps of the methods disclosed with reference to the embodiments of the present application may be directly performed and achieved by using a hardware decoding processor, or may be performed and achieved by using a combination of hardware and software in the decoding processor. The software modules may be located in any storage medium mature in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, or a register.The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with the processor's hardware.

[0516] It can be understood that the memory of this embodiment of the present application may be volatile or non-volatile memory, or may include volatile and non-volatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory may be random access memory (RAM) used as an external cache. By way of example and not limitation, many forms of RAM may be used, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus dynamic random access memory (DR RAM). The memory of the systems and methods described herein includes, but is not limited to, these and any other suitable types of memory.

[0517] All or part of the above embodiments may be implemented by using software, hardware, firmware, or any combination thereof. When software is used to implement the embodiments, all or part of the embodiments may be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded into a computer and executed, the procedures or functions according to the embodiments of the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable medium or may be transmitted from a computer-readable storage medium to another computer-readable medium. For example, the computer instructions may be transmitted from a website, computer, server, or data center to another website, computer, server, or data center in a wired (e.g., coaxial cable, optical fiber, or digital subscriber line (DSL)) or wireless (e.g., infrared, radio wave, or microwave) manner. The computer-readable storage medium may be any available medium accessible by a computer, or a data storage device incorporating one or more available media, such as a server or a data center. The usable media may be magnetic media (e.g., a floppy disk, a hard disk drive, or a magnetic tape), optical media (e.g., a digital video disc (DVD)), semiconductor media (e.g., a solid state disc (SSD)), and the like.

[0518] The network device and the terminal device of the above apparatus embodiments fully correspond to the network device and the terminal of the method embodiments. The corresponding modules or units perform the corresponding steps. For example, a communication unit (e.g., a transceiver) performs the receiving or transmitting step of the method embodiments, and steps other than the transmitting and receiving steps may be performed by a processing unit (processor). For the functions of specific units, please refer to the corresponding method embodiments. There may be one or more processors.

[0519] As used herein, terms such as "component," "module," and "system" are used to indicate computer-related entities, hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable file, a thread of execution, a program, or a computer. As represented by the use of diagrams, both computing devices and applications running on computing devices may be components. One or more components may reside within a process or thread of execution, and a component may be located in one computer or distributed between two components. Furthermore, these components may execute from various computer-readable media that store various data structures. For example, components may communicate by using local or remote processes based on signals having one or more data packets (e.g., data from two components interacting with other components in a local system, in a distributed system, or across a network such as the Internet that interacts with other systems by using signals).

[0520] It should be understood that the term "embodiments" used throughout this specification means that the particular features, structures, or characteristics of the embodiments are included in at least one embodiment of the present application. Thus, the embodiments throughout the specification do not necessarily refer to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in one or more embodiments by any suitable method.

[0521] It should be understood that in the embodiments of the present application, the numbers "first", "second", etc. are merely for distinguishing different objects, e.g., to distinguish different network devices, and do not constitute a limitation on the scope of the embodiments of the present application. The embodiments of the present application are not so limited.

[0522] It should be further understood that, in this application, both "when" and "if" mean that the network element performs the corresponding processing in the intended situation, but do not constitute a limitation on time, do not require that the network element have a decisive action during implementation, and do not imply any other limitation.

[0523] It should be further understood that, as used herein, "at least one" means one or more, and "plurality" means two or more.

[0524] In the embodiments of the present application, "B corresponding to A" indicates that B is related to A, and it should be further understood that B may be determined based on A. However, it should be further understood that determining B based on A does not mean that B is determined only based on A, and B may alternatively be determined based on A and / or other information.

[0525] The term "and / or" in this specification only indicates an association relationship to describe related objects, and indicates that three relationships may exist. For example, A and / or B may indicate three cases: only A exists, both A and B exist, and only B exists. Furthermore, the character " / " in this specification generally indicates a "logical or" relationship between related objects.

[0526] Unless otherwise specified, expressions used herein similar to the expression "the item includes one or more of the following: A, B, and C" generally mean that the item may be any one of the following: A; B; C; A and B; A and C; B and C; A and B and C; A and A; A and A and A; A and A and B; A and A and C; A and B and B; A and C and C; B and B; B and B and B; B and B and C; C and C; C and C and C; and other combinations of A, B, and C. In the above description, the three elements A, B, and C are used as examples to describe any case of the item. When the expression is "the item includes at least one of the following: A, B, ..., X", in other words, when further elements are included in the expression, the item may be obtained according to the above rules if applicable.

[0527] It may be understood that in the embodiments of the present application, the terminal device and / or the network device may perform some or all of the steps of the embodiments of the present application. These steps or operations are merely examples. Other operations or variations of various operations may also be performed in the embodiments of the present application. Furthermore, steps may be performed in an order different from that presented in the embodiments of the present application, and all operations of the embodiments of the present application may not be performed.

[0528] Those skilled in the art may realize that the units and algorithm steps may be implemented by electronic hardware or a combination of computer software and electronic hardware in combination with the examples described in the embodiments disclosed herein. Whether a function is implemented by hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may implement the described functions using different methods for each specific application, but the implementation should not be considered to go beyond the scope of the present application.

[0529] As can be clearly understood by those skilled in the art, for convenience and concise description, the detailed operation processes of the above systems, devices and units are referred to the corresponding processes of the above method embodiments, and the details will not be described again here.

[0530] In some implementations provided in the present application, it should be understood that the disclosed system, device, and method may be implemented in other ways. For example, the described device embodiment is only an example. For example, the division into units is only a logical functional division, and may be other divisions in actual implementation. For example, multiple units or components may be integrated or combined into other systems, or some features may be ignored or not implemented. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be implemented by using some interfaces. Indirect couplings or communication connections between devices or units may be implemented in electronic, mechanical, or other forms.

[0531] The units described as separate parts may or may not be physically separated, and the parts shown as units may or may not be physical units, and may be located in one place or distributed among multiple network units. Some or all of the units may be selected based on actual requirements to achieve the objectives of the solutions of the embodiments.

[0532] Furthermore, the functional units of the embodiments of the present application may be integrated into one processing unit, and each unit may exist physically alone, or two or more units may be integrated into one unit.

[0533] When the functions are implemented in the form of a software functional unit and sold or used as an independent product, the functions may be stored in a computer-readable storage medium. Based on such understanding, the technical solutions of the present application may be essentially implemented in the form of a software product, or the part that contributes to the prior art, or some of the technical solutions. The software product is stored in a storage medium and includes some instructions for instructing a computer device (which may be a personal computer, a server, or a network device) to execute all or some of the steps of the method described in the embodiments of the present application. The above storage medium includes any medium that can store program code, such as a USB flash drive, a removable hard disk, a read-only memory ROM, a random access memory RAM, a magnetic disk, or an optical disk.

[0534] The above description is merely a specific implementation of the present application, and is not intended to limit the scope of protection of the present application. Any variations or replacements that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be within the scope of protection of the present application. Therefore, the scope of protection of the present application should be subject to the scope of protection of the claims.

Claims

1. broadcasting a first message to user equipments in an idle state or an RRC inactive state that are receiving data of a first multicast session when a preset condition is satisfied, by an access network device, the first message being used to notify that the first multicast session should be released or deactivated; Releasing or deactivating the first multicast session by the access network device if the access network device does not receive a second message in response to the first message within a first preset period; and / or maintaining the first multicast session by the access network device if the access network device receives, within a first preset period, a second message in response to the first message from the user equipment that received the first message; having The preset conditions are as follows: no data is transmitted on the first multicast session within a second preset period of time; the associated user equipment is not in a multicast group, or a first timer used to monitor whether there is a user device receiving data by using the first multicast session times out; At least one of: Communication methods.

2. The method further comprises transmitting, by the access network device, a third message to a core network device; the third message is used to request the first multicast session to be released or deactivated; The communication method according to claim 1 .

3. Sending a third message by the access network device to a core network device transmitting, by the access network device, the third message to the core network device after the first preset period. The communication method according to claim 2 .

4. Sending a third message by the access network device to a core network device transmitting, by the access network device, the third message to the core network device prior to the first preset period. The communication method according to claim 2 .

5. The method further comprises sending, by the access network device, a fifth message to the core network device if the access network device receives the second message within the first preset period; the fifth message is used to request the core network device to maintain the first multicast session. The communication method according to claim 4.

6. the second message is from a user equipment; A communication method according to any one of claims 1 to 5.

7. The second message is a radio resource control (RRC) message. The communication method according to claim 6.

8. receiving, by the user equipment, a first message broadcast by the access network device when a preset condition is satisfied, the first message being used to notify that the first multicast session should be released or deactivated, the preset condition being: no data is transmitted on the first multicast session within a second preset period of time; the associated user equipment is not in a multicast group, or a first timer used to monitor whether any user device is receiving data by using the first multicast session times out; and sending, by the user equipment to the access network device, a second message in response to the first message when the user equipment is in an idle state or an RRC inactive state and is receiving or is about to receive data by using the first multicast session, to cause the access network device that receives the second message within a first preset period to maintain the first multicast session; A communication method comprising:

9. the user equipment is in an idle state or a radio resource control (RRC) inactive state; The communication method according to claim 8.

10. An access network device and a user equipment, The access network device is configured to perform the communication method according to any one of claims 1 to 7, The user equipment is adapted to perform the communication method according to claim 8 or 9. Communication systems.

11. A processor and a memory, The processor is coupled to the memory, the memory being configured to store a computer program, and the processor is configured to execute the computer program stored in the memory to implement the communication method according to any one of claims 1 to 7. Communications equipment.

12. A method for controlling a computer system comprising: The processor is coupled to the memory, the memory being configured to store a computer program, and the processor is configured to execute the computer program stored in the memory to implement the communication method according to claim 8 or 9. Communications equipment.

13. A processor and a memory, The processor is coupled to the memory, the memory being configured to store a computer program, and the processor is configured to execute the computer program stored in the memory to implement the communication method according to any one of claims 1 to 7. Tips.

14. A method for controlling a computer system comprising: The processor is coupled to the memory, the memory being configured to store a computer program, and the processor is configured to execute the computer program stored in the memory to implement the communication method according to claim 8 or 9. Tips.

15. A computer program comprising: When the computer program is executed on a computer, the computer is capable of executing the communication method according to any one of claims 1 to 7. A computer-readable storage medium.

16. A computer program comprising: When the computer program is executed on a computer, the computer can execute the communication method according to claim 8 or 9. A computer-readable storage medium.

17. A computer program comprising: The computer program, when executed on a computer, causes the computer to carry out the communication method according to any one of claims 1 to 7. Computer program.

18. A computer program comprising: When the computer program is executed on a computer, the computer is caused to execute the communication method according to claim 8 or 9. Computer program.

Images