Communication method and communication apparatus

Abstract

The present application provides a communication method and a communication apparatus. The communication method is applied to a central unit-control plane (CU-CP) of a first access network device. The first access network device further comprises a central unit-user plane (CU-UP). The communication method comprises: the CU-CP receives first indication information from the CU-UP, wherein the first indication information is used for indicating that the CU-UP has not detected first data of a multicast and broadcast service (MBS) session within a first preset duration, and the first data is data from a core network device; and the CU-CP sends second indication information to the CU-UP on the basis of the first indication information, wherein the second indication information is used for indicating to stop sending the first data when the CU-UP has detected the first data. The present application can achieve the reliable transmission of MBS data, and perfect a signaling interaction mechanism on an E1 interface.

Description

Communication method and communication device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on September 28, 2023, with application number 202311295537.0 and application name “Communication Method and Communication Device”, the entire contents of which are incorporated by reference into this application. Technical Field

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

[0003] Multicast and broadcast service (MBS) is a service for multiple UEs, such as live broadcast services, public safety services, and batch software updates. MBS data originates from a data server, which first sends the MBS data to core network devices. The core network devices then send the MBS data to access network devices, which then send the MBS data to one or more terminal devices within the MBS session.

[0004] With the evolution of communication technology, standards define that access network equipment can adopt an architecture that separates a centralized unit (CU) from a distributed unit (DU). Furthermore, the CU can be divided into the centralized unit-control plane (CU-CP) and the distributed unit-user plane (CU-UP).

[0005] The CU-UP and CU-CP can be deployed on different physical devices, connected via the E1 interface. In this separate architecture, when there is no MBS data to be sent to a terminal device, the access network device can release the terminal device to the radio resource control inactive (RRC_INACTIVE) state. Furthermore, given that the terminal device may switch base stations during MBS data transmission, achieving reliable MBS data transmission remains a technical challenge.

[0006] Summary of the Invention

[0007] The embodiments of the present application provide a communication method and a communication device, which can achieve reliable transmission of MBS data and improve the signaling interaction mechanism on the E1 interface.

[0008] In a first aspect, a communication method is provided, which is applied to a centralized unit-control plane CU-CP of a first access network device, wherein the first access network device also includes a centralized unit-user plane CU-UP. The method includes: the CU-CP receives first indication information from the CU-UP, wherein the first indication information is used to indicate that the CU-UP has not detected first data of a multicast broadcast service MBS session within a first preset time period, and the first data is data from a core network device; the CU-CP sends second indication information to the CU-UP according to the first indication information, wherein the second indication information is used to instruct the CU-UP to stop sending the first data when it detects the first data.

[0009] According to the communication method provided in the embodiment of the present application, after CU-UP fails to detect MBS data (recorded as first data) from the core network device within a first preset time period, it can send a first indication message to CU-CP, and CU-CP can release at least one terminal device according to the first indication message to save terminal energy consumption and communication resources. CU-CP can also send a second indication message to CU-UP according to the first indication message, and the second indication message is used to instruct CU-UP to stop sending the first data when it detects new first data, such as pausing for a period of time before sending the first data, or waiting to receive further instructions from CU-CP before sending, thereby avoiding missing data packets due to the lack of access of terminal devices (in an RRC inactive state).

[0010] Furthermore, considering that the CU-UP of the first access network device may also receive MBS data (recorded as second data) from other access network devices such as the second access network device, the second indication information in the embodiment of the present application instructs the CU-UP to stop sending the first data, rather than instructing the CU-UP to stop sending all MBS data. When there is second data that needs to be forwarded, the CU-UP will not stop forwarding the second data. For example, after receiving the second indication information, if there is second data from the second access network device that needs to be forwarded to the terminal device (the terminal device is switched from the second access network device to the first access network device), the CU-UP will not stop forwarding the second data, thereby avoiding the terminal device from missing data, ensuring the integrity of the data received by the terminal device, and ensuring the smooth operation of the MBS service.

[0011] The communication method provided in the embodiment of the present application can realize reliable transmission of MBS data, avoid data leakage of terminal devices, and can also smoothly reach the corresponding terminal devices for MBS data from other access network devices, ensuring that the terminal devices can achieve the purpose of lossless reception, ensuring that the MBS service can be smoothly implemented, and can improve the reliability of the signaling interaction process, thereby improving the signaling interaction mechanism on the E1 interface.

[0012] Optionally, the second data may come from the second access network device, or from any other access network device such as the third access network device, or from multiple devices such as the second access network device and the third access network device. This application does not limit this.

[0013] Optionally, the core network device may be, for example, an MB-UPF.

[0014] Optionally, the first access network device and the second access network device are two completely different access network devices. For example, the second access network device may be a neighboring base station of the first access network device.

[0015] Optionally, as a special case, considering the cell switching within the first access network device, the first access network device and the second access network device may also be the same access network device. At this time, the terminal device undergoes cell switching, and the source cell and target cell before and after the switching may belong to the same CU-UP or to different CU-UPs. The source cell's progress (progress) in sending MBS data lags behind the target cell, so it is necessary to forward the second data. At this time, the forwarding of the second data is an internal behavior of the first access network device. This application does not limit the specific implementation form. After CU-UP obtains the second data, it forwards the second data to the terminal device where the cell switching occurs.

[0016] Optionally, as a special case, after the CU-CP receives the first indication information, it is also possible that no terminal device is released. This application does not exclude this situation. For example, the CU-CP determines that each terminal does not meet the release condition (requirement) based on the current service situation of each terminal (not limited to MBS service). Therefore, the CU-CP may not release any terminal, that is, keep each terminal device in the RRC connected state.

[0017] Optionally, the first preset duration may be any duration, for example, 1 to 7200 seconds, such as 2 seconds, 3 seconds, 5 seconds, 10 seconds, 30 seconds, 60 seconds, 120 seconds, 180 seconds, 500 seconds, 1000 seconds, 2000 seconds, 5000 seconds, etc. The first preset duration may be pre-configured in a static or semi-static manner. For example, the first preset duration may be determined based on indication (configuration) information from the CU-CP, and the indication information may include, for example, indication information of an inactivity timer.

[0018] Optionally, the first indication information and the second indication information may both be transmitted via the E1 interface, for example, carried in an E1AP message. The E1AP message may be, for example, a bearer context establishment / modification / notification / request / response message, but is not limited thereto.

[0019] Optionally, the first indication information is carried in a multicast (MC) bearer notification message or a bearer context inactivity notification message. For example, the first indication information includes a temporary no data indication.

[0020] Optionally, the second indication information is carried in an MC bearer context setup request or an MC bearer context modification request (BEARER CONTEXT SETUP / MODIFICATION REQUEST) message. For example, the second indication information includes a suspend indication.

[0021] In a possible implementation, the method also includes: the CU-CP releases the radio resource control RRC connection of the first terminal device according to the first indication information, the first terminal device is a terminal device among multiple terminal devices served by the CU-UP that has not received the second data within the first preset time length, and the second data is data from the MBS session of the second access network device.

[0022] In order to avoid releasing a terminal device that is still transmitting data, or in other words, to avoid releasing a terminal device that still has second data to be transmitted, in an embodiment of the present application, the CU-CP only releases the first terminal device according to the first indication information, that is, only releases the terminal device that has not received the second data within the first preset time period, thereby ensuring that the terminal devices that receive the second data can fully receive the second data and ensure the reliability of MBS data transmission.

[0023] Optionally, the first terminal device fails to receive the second data within the first preset time period, which means that the first terminal device fails to receive the second data at any time (for example, the start time, the end time) of the first preset time period.

[0024] Optionally, the CU-CP releases the RRC connection of the first terminal device through a well-known process in the prior art or through other processes. This application does not limit the specific release process. For example, it includes the steps of the CU-CP sending a UE context release command message to the DU, the message carrying an RRC release message (information), and the DU further sending the RRC release message to the first terminal device.

[0025] Optionally, the first terminal device here may be a terminal device that receives the first data but does not receive the second data. In other words, the first terminal device may be a terminal device that has been served by the CU-UP, that is, has been receiving MBS data through the CU-UP without any base station switching or cell switching.

[0026] Optionally, the first terminal device here may also be a terminal device that receives the first data and the second data. Wherein, the first terminal device undergoes base station switching or cell switching, but the first terminal device completes reception of the second data before the start time of the first preset duration. At this time, the first terminal device's reception of the second data will not affect the RRC release of the first terminal device.

[0027] Optionally, the first terminal device here can be one or more, and this application does not limit this.

[0028] In a possible implementation, the method also includes: the CU-CP receives third indication information from the CU-UP, the third indication information is used to indicate that the sending of the second data sent to the second terminal device is completed, the second terminal device is a terminal device among multiple terminal devices served by the CU-UP that receives the second data within the first preset time length, and the second data is data of the MBS session from the second access network device; the CU-CP releases the RRC connection of the second terminal device according to the third indication information.

[0029] After the second data is sent, the CU-UP can send a third indication message to the CU-CP, and the CU-CP can determine that the second data sent to the second terminal device is completed based on the third indication message. In this way, the CU-CP can further release the RRC connection of the second terminal device based on the third indication message to save energy consumption of the second terminal device and save communication resources. By setting the third indication message to instruct the CU-CP to release the second terminal device, the problem of when the second terminal device is released is solved, and the signaling interaction mechanism under the separated architecture is improved.

[0030] Optionally, the second terminal device is a terminal device that receives the second data within a first preset time period. For a certain terminal device, as long as it receives the second data at any time within the first preset time period (for example, the start time, the middle time or the end time), the terminal device can be determined as the second terminal device.

[0031] Optionally, within the first preset time period, there may be multiple terminal devices receiving the second data (the second data received by each terminal device may be different, for example, may come from different access network devices), and the second terminal device may be one of the multiple terminal devices.

[0032] In a possible implementation, the CU-CP releases the RRC connection of the second terminal device according to the third indication information, including: the CU-CP releases the RRC connection of the second terminal device according to the third indication information and the first indication information.

[0033] The first indication information is sent after the first preset time period, and the third indication information is sent when the second data transmission to the second terminal device is completed. There is no logical order in the timing of the transmission of these two indication information. The third indication information may be sent first and then the first indication information. Taking this into account, in order to avoid the second terminal device being released prematurely, the CU-CP releases the second terminal device only after receiving both the first indication information and the third indication information. When the third indication information has been received and the first indication information has not been received, it is possible to wait until the first indication information is received before executing the release process for the second terminal device. In other words, the release process for the second terminal device needs to wait for at least the first preset time period before executing, so as to avoid releasing the second terminal device when there may still be data, thereby avoiding frequent switching of the RRC state of the second terminal device. When executing the release process for the second terminal device, multiple terminal devices including the first terminal device can be released at the same time, thereby simplifying the process.

[0034] In a possible implementation, the third indication information is further used to indicate that no other data of the MBS session sent to the second terminal device is detected within a second preset time period after the second data is sent.

[0035] In a possible implementation, the method further includes: after determining that a preset trigger condition is met, the CU-CP sends fourth indication information to the CU-UP, where the fourth indication information is used to instruct the CU-UP to resume sending data for the MBS session.

[0036] In one possible implementation, the trigger condition includes at least one of the following conditions: the CU-CP receives a data arrival indication from the CU-UP; the CU-CP receives an MBS session activation indication sent by a core network device; the CU-CP receives a group paging message sent by a core network device; the CU-CP receives a group paging message sent by other access network devices; and the CU-CP sends a group paging message to a terminal device.

[0037] In a possible implementation, the CU-CP sends the fourth indication information to the CU-UP, including: when it is determined that a preset trigger condition is met, waiting for a third preset time period and then sending the fourth indication information to the CU-UP.

[0038] If the fourth indication (resumption indication) is sent directly to the CU-UP when the preset trigger condition is met, some terminal devices may not have connected yet, which may cause the terminal devices to miss the MBS data that has just been sent. Therefore, after the trigger condition is met (triggered), the fourth indication information can be sent after waiting for a third preset time period to prevent terminal devices from missing the MBS data that has just been sent.

[0039] Optionally, the third preset duration may be any duration, for example, 20 milliseconds to 1000 milliseconds, such as 50 milliseconds, 100 milliseconds, 200 milliseconds, 300 milliseconds, 320 milliseconds, 500 milliseconds, or 800 milliseconds. The third preset duration may be pre-configured in a static or semi-static manner.

[0040] In a possible implementation, the third preset duration is greater than or equal to the duration of a paging cycle.

[0041] According to a second aspect, a communication method is provided, which is applied to a centralized unit-user plane CU-UP of a first access network device, wherein the first access network device also includes a centralized unit-control plane CU-CP. The method includes: the CU-UP sends a first indication message to the CU-CP, wherein the first indication message is used to indicate that the CU-UP has not detected the first data of the multicast broadcast service MBS session within a first preset time period, and the first data is data from a core network device; the CU-UP receives a second indication message from the CU-CP, wherein the second indication message is sent according to the first indication message, and the second indication message is used to indicate that when the CU-UP detects the first data, it stops sending the first data.

[0042] In one possible implementation, the first indication information is also used to enable the CU-CP to release the radio resource control RRC connection of the first terminal device, where the first terminal device is a terminal device among multiple terminal devices served by the CU-UP that has not received second data within the first preset time period, and the second data is data from the MBS session of the second access network device.

[0043] In a possible implementation, the method also includes: the CU-UP sends a third indication message to the CU-CP, the third indication message is used to indicate that the second data sent to the second terminal device is completed, the second terminal device is a terminal device among multiple terminal devices served by the CU-UP that receives the second data within the first preset time length, the second data is data of the MBS session from the second access network device, and the third indication message is used to enable the CU-CP to release the RRC connection of the second terminal device.

[0044] In a possible implementation, the third indication information is further used to indicate that no other data of the MBS session sent to the second terminal device is detected within a second preset time period after the second data is sent.

[0045] In one possible implementation, the method further includes: the CU-UP receiving fourth indication information from the CU-CP, where the fourth indication information is used to instruct the CU-UP to resume sending data for the MBS session, and the fourth indication information is issued after the CU-CP determines that a preset trigger condition is met.

[0046] In one possible implementation, the trigger condition includes at least one of the following conditions: the CU-CP receives a data arrival indication from the CU-UP; the CU-CP receives an MBS session activation indication sent by a core network device; the CU-CP receives a group paging message sent by a core network device; the CU-CP receives a group paging message sent by other access network devices; and the CU-CP sends a group paging message to a terminal device.

[0047] In a possible implementation, the fourth indication information is sent by the CU-CP to the CU-UP after waiting for a third preset time period when the CU-CP determines that a preset trigger condition is met.

[0048] In a possible implementation, the third preset duration is greater than or equal to the duration of a paging cycle.

[0049] According to a third aspect, a communication method is provided, the method comprising:

[0050] The first node sends the first data packet to the user equipment UE based on the first multicast data radio bearer MRB configuration; the first data packet is sent by the second node to the first node.

[0051] When the first condition is met (ie, the first condition is established), the first node sends a first message to the UE, where the first message includes parameter information of the second MRB configuration; the first MRB configuration is different from the second MRB configuration.

[0052] According to the communication method provided in an embodiment of the present application, when the first condition is met, for example, when the first node stops receiving multicast broadcast service MBS data from the second node and starts receiving multicast broadcast service MBS data from the third node, it is necessary to modify the MRB configuration on the UE side. The first node can send a first message to the UE, and the first message includes parameter information of a second MRB configuration, which is different from the current first MRB configuration.

[0053] After the UE receives the parameter information configured by the second MRB, it can release the current MRB based on the information and create a new MRB based on the parameter information configured by the second MRB. This creates a new receiving window, i.e., the receiving window is reset, thereby ensuring that the newly created receiving window can receive new MBS data, thereby resolving the aforementioned problem of data packet discard caused by the data packet sequence number not being within the data window. MBS data from the third node can then be accurately received without data packet discard, and the order in which data is submitted can be guaranteed to be consistent. This prevents the UE from being unable to normally receive MBS data packets from the third node.

[0054] Optionally, after the UE receives the parameter information of the second MRB configuration, it can modify the MRB configuration according to the information. For example, the current first MRB can be released, and a new second MRB can be created according to the parameter information of the second MRB configuration. In this way, there is a new receiving window, that is, the receiving window is reset, and it can be ensured that the newly created receiving window can receive new MBS data (the new MBS data comes from the 5GC PLMNB in ​​Figure 17, for example). In this way, the MBS data from the third node can be accurately received, and data packets will not be discarded. It can also ensure that the order of data submission will not be disordered. This prevents the UE from failing to receive the MBS data packet from the third node normally.

[0055] Optionally, in some special cases (scenarios), even if the UE receives the parameter information configured by the second MRB, it may continue to maintain the current first MRB, that is, not release the first MRB.

[0056] Optionally, the first condition means that the first node stops receiving MBS data from the second node and starts receiving MBS data from the third node. Exemplarily, before the first node sends the first message to the UE, the first node receives a first request sent by the second node, the first request including a service identifier of the MBS; the first request is used to request the release of the MBS session of the second node.

[0057] Optionally, the first request may further include parameter information configured by the second MRB.

[0058] Among them, the parameter information configured by the second MRB may include at least one of a group radio network temporary identifier (Group Radio Network Temporary Identifier, G-RNTI), a discontinuous reception configuration point to multipoint configuration index (Discontinuous Reception Configuration Point to Mutiple Point Index, DRX-ConfigPTM-Index), a physical downlink shared channel configuration index (Physical Downlink Shared Channel Configuration Index, PDSCH-ConfigIndex), a multicast traffic channel synchronization signal block mapping window index (Multicast Traffic Channel Synchronization Signal and PBCH Block Mapping Window Index, MTCH-SSB-MappingWindowIndex), a multicast radio bearer broadcast list (Multicast Radio Bearer List Broadcast, MRB-ListBroadcas), a logical channel identifier (logicalChannelIdentity), a sequence number field length (sn-FieldLength), and a reassembly timer (t-Reassembly).

[0059] The service identifier of the multicast broadcast service includes at least one of a session identifier of the multicast broadcast service, a temporary multicast group identifier TMGI, and a service network identifier (Network Identifier, NID).

[0060] Take changing the sequence number field length (sn-FieldLength) as an example. TMGI1 is used to indicate that it is the MRB configuration corresponding to the broadcast session of the second node, and TMGI2 is used to indicate that it is the MRB configuration corresponding to the broadcast session of the third node. Before the first MCCH modification period, the PDCP configurations of the second node and the third node are the same. Before the first MCCH modification period, the first node uses the sn-FieldLength of 6 bits in the first MRB configuration. During the first MCCH modification period, the first node receives the first request sent by the second node, and the first request includes parameter information of the second MRB configuration (MRB configuration), including PDCP configuration information, such as data convergence protocol sequence number length (PDCP SN Size), robust header compression (Robust Header Compression, ROHC), and reordering timer (t-Reordering).

[0061] Furthermore, the first node may modify the sn-FieldLength to 12 bits in the second MCCH modification period, and the second MCCH modification period may be the next period of the first MCCH modification period. For example, the first node (such as DU) receives a first request sent by the second node, and the first request includes parameter information of the second MRB configuration, including the PDCP configuration; then, after receiving the PDCP configuration information of the second MRB, the DU may modify the sn-FieldLength from the original 6 bits to 12 bits, so that the DU may broadcast the MRB configuration of 12 bits of sn-FieldLength over the air interface. After the UE sees that the MRB configuration has changed, it may delete the original 6-bit MRB configuration of sn-FieldLength and establish an 18-bit MRB configuration of sn-FieldLength.

[0062] In a fourth aspect, a communication method is provided, the method comprising:

[0063] The user equipment UE receives a first data packet from the first node. The first data packet is sent by the second node to the first node. The first node sends the first data packet based on a first multicast data radio bearer MRB configuration.

[0064] The user equipment UE receives a first message from the first node, where the first message includes parameter information of a second MRB configuration; the first MRB configuration is different from the second MRB configuration, wherein the first message is sent by the first node to the UE when a first condition is met.

[0065] In the fifth aspect, a communication device is provided, which is applied to a first access network device, wherein the first access network device also includes a centralized unit-user plane CU-UP, and the device includes: a receiving unit, used to receive a first indication information from the CU-UP, wherein the first indication information is used to indicate that the CU-UP has not detected the first data of the multicast broadcast service MBS session within a first preset time period, and the first data is data from the core network device; a sending unit, used to send a second indication information to the CU-UP according to the first indication information, wherein the second indication information is used to indicate that when the CU-UP detects the first data, it stops sending the first data.

[0066] In one possible implementation, the device also includes: a release unit, used to release the radio resource control RRC connection of the first terminal device according to the first indication information, the first terminal device is a terminal device among the multiple terminal devices served by the CU-UP that has not received the second data within the first preset time length, and the second data is data from the MBS session of the second access network device.

[0067] In one possible implementation, the receiving unit is further used to: receive a third indication message from the CU-UP, the third indication message being used to indicate that the sending of the second data to the second terminal device is completed, the second terminal device being a terminal device among multiple terminal devices served by the CU-UP that receives the second data within the first preset time length, and the second data is data of the MBS session from the second access network device; the device also includes a release unit, the release unit being further used to: release the RRC connection of the second terminal device according to the third indication message.

[0068] In a possible implementation, in terms of releasing the RRC connection of the second terminal device according to the third indication information, the releasing unit is specifically used to: release the RRC connection of the second terminal device according to the third indication information and the first indication information.

[0069] In a possible implementation, the third indication information is further used to indicate that no other data of the MBS session sent to the second terminal device is detected within a second preset time period after the second data is sent.

[0070] In a possible implementation, the sending unit is further configured to: when it is determined that a preset trigger condition is met, send fourth indication information to the CU-UP, where the fourth indication information is used to instruct the CU-UP to resume sending data for the MBS session.

[0071] In one possible implementation, the trigger condition includes at least one of the following conditions: the device receives a data arrival indication from the CU-UP; the device receives an MBS session activation indication sent by a core network device; the device receives a group paging message sent by a core network device; the device receives a group paging message sent by other access network devices; and the device sends a group paging message to a terminal device.

[0072] In a possible implementation, in terms of sending the fourth indication information to the CU-UP, the sending unit is specifically used to: when it is determined that the preset trigger condition is met, wait for a third preset time length and then send the fourth indication information to the CU-UP.

[0073] In a possible implementation, the third preset duration is greater than or equal to the duration of a paging cycle.

[0074] In the sixth aspect, a communication device is provided, which is applied to a first access network device, wherein the first access network device also includes a centralized unit-control plane CU-CP, and the device includes: a sending unit, used to send a first indication message to the CU-CP, wherein the first indication message is used to indicate that the device has not detected the first data of the multicast broadcast service MBS session within a first preset time period, and the first data is data from a core network device; a receiving unit, used to receive a second indication message from the CU-CP, wherein the second indication message is sent based on the first indication message, and the second indication message is used to instruct the device to stop sending the first data when it detects the first data.

[0075] In one possible implementation, the first indication information is also used to enable the CU-CP to release the radio resource control RRC connection of the first terminal device, where the first terminal device is a terminal device among multiple terminal devices served by the apparatus that has not received second data within the first preset time period, and the second data is data from the MBS session of the second access network device.

[0076] In one possible implementation, the sending unit is also used to: send a third indication message to the CU-CP, the third indication message is used to indicate that the second data sent to the second terminal device is completed, the second terminal device is a terminal device among multiple terminal devices served by the device that receives the second data within the first preset time length, the second data is data from the MBS session of the second access network device, and the third indication message is used to enable the CU-CP to release the RRC connection of the second terminal device.

[0077] In a possible implementation, the third indication information is further used to indicate that no other data of the MBS session sent to the second terminal device is detected within a second preset time period after the second data is sent.

[0078] In one possible implementation, the receiving unit is further used to: receive fourth indication information from the CU-CP, where the fourth indication information is used to instruct the device to resume sending data for the MBS session, and the fourth indication information is issued after the CU-CP determines that a preset trigger condition is met.

[0079] In one possible implementation, the trigger condition includes at least one of the following conditions: the CU-CP receives a data arrival indication from the CU-UP; the CU-CP receives an MBS session activation indication sent by a core network device; the CU-CP receives a group paging message sent by a core network device; the CU-CP receives a group paging message sent by other access network devices; and the CU-CP sends a group paging message to a terminal device.

[0080] In a possible implementation, the fourth indication information is sent to the apparatus by the CU-CP after waiting for a third preset time period when the CU-CP determines that a preset trigger condition is satisfied.

[0081] In a possible implementation, the third preset duration is greater than or equal to the duration of a paging cycle.

[0082] In a seventh aspect, a communication device is provided, including: a sending unit, configured to send a first data packet to a user equipment UE based on a first multicast data radio bearer MRB configuration; the first data packet is sent from a second node to a first node.

[0083] The sending unit is further configured to send a first message to the UE when a first condition is met, where the first message includes parameter information of the second MRB configuration; and the first MRB configuration is different from the second MRB configuration.

[0084] In an eighth aspect, a communication device is provided, comprising a receiving unit for receiving a first data packet from a first node, where the first data packet is sent from a second node to the first node, and the first node sends the first data packet based on a first multicast data radio bearer MRB configuration.

[0085] The receiving unit is further configured to receive a first message from the first node, the first message including parameter information of the second MRB configuration; the first MRB configuration is different from the second MRB configuration, wherein the first message is sent by the first node to the UE when the first condition is met.

[0086] In the ninth aspect, a communication device is provided, comprising at least one processor, wherein the at least one processor is used to couple with a memory, read and execute instructions (or computer programs) in the memory to implement the method provided by any possible implementation manner in the first aspect, or to implement the method provided by any possible implementation manner in the second aspect, or to implement the method provided by any possible implementation manner in the third aspect, or to implement the method provided by any possible implementation manner in the fourth aspect.

[0087] Optionally, the communication device further includes the memory.

[0088] In the tenth aspect, an access network device is provided, comprising a communication device provided by any possible implementation method of the aforementioned fifth aspect, and / or, a communication device provided by any possible implementation method of the aforementioned sixth aspect, and / or, a communication device provided by any possible implementation method of the aforementioned seventh aspect.

[0089] In the eleventh aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is run on a computer, the computer is caused to execute the method provided by any possible implementation of the first aspect, or the method provided by any possible implementation of the second aspect, or the method provided by any possible implementation of the third aspect, or the method provided by any possible implementation of the fourth aspect.

[0090] In the twelfth aspect, a chip system is provided, comprising a processor for calling and running a computer program from a memory, so that a communication device equipped with the chip system executes the method provided by any possible implementation method in the first aspect, or executes the method provided by any possible implementation method in the second aspect, or executes the method provided by any possible implementation method in the third aspect, or executes the method provided by any possible implementation method in the fourth aspect.

[0091] In the thirteenth aspect, a computer program product is provided, comprising: a computer program code, which, when executed on a computer, enables the computer to execute the method provided by any possible implementation of the first aspect, or the method provided by any possible implementation of the second aspect, or the method provided by any possible implementation of the third aspect, or the method provided by any possible implementation of the fourth aspect.

[0092] It should be noted that the above-mentioned computer program code can be stored in whole or in part on the first storage medium, wherein the first storage medium can be packaged together with the processor or separately from the processor, and this application does not make any specific restrictions on this.

[0093] In the fourteenth aspect, a communication system is provided, which includes at least one of the communication devices provided in the fifth, sixth or seventh aspects, eighth and ninth aspects, and the access network equipment provided in the tenth aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0094] FIG1 is a schematic diagram of a network architecture provided in an embodiment of the present application.

[0095] FIG2 is a schematic diagram of MBS data transmission disclosed in an embodiment of the present application.

[0096] Figure 3 is a schematic diagram of the separation architecture of the gNB provided in an embodiment of the present application.

[0097] FIG4 is a schematic diagram of a CU-CP and CU-UP separation architecture provided in an embodiment of the present application.

[0098] FIG5 is a schematic diagram of the transition of the RRC state provided in an embodiment of the present application.

[0099] FIG6 is a schematic diagram of the transition process of the UE from the RRC connected state to the RRC inactive state.

[0100] FIG7 is a schematic diagram of the transition process of the UE from the RRC inactive state to the RRC connected state.

[0101] FIG8 is a flow chart of an example of a communication method provided in an embodiment of the present application.

[0102] FIG9 is a flow chart of another example of a communication method provided in an embodiment of the present application.

[0103] FIG10 is a timing diagram of an example of CU-UP sending data and indication information provided in an embodiment of the present application.

[0104] FIG11 is a flow chart of another example of the communication method provided in an embodiment of the present application.

[0105] FIG12 is a timing diagram of another example of CU-UP sending data and indication information provided in an embodiment of the present application.

[0106] FIG13 is a flow chart of another example of the communication method provided in an embodiment of the present application.

[0107] FIG14 is a timing diagram of another example of CU-UP sending data and indication information provided in an embodiment of the present application.

[0108] Figure 15 is a flowchart of another example of the communication method provided in an embodiment of the present application.

[0109] FIG16 shows a schematic diagram of an architecture of a shared DU-only architecture.

[0110] Figure 17 shows that the CN includes 5G cores corresponding to two operators.

[0111] FIG18 is a flow chart of a communication method for a multicast broadcast service provided in an embodiment of the present application.

[0112] Figure 19 is a schematic block diagram of an example of a communication device provided in an embodiment of the present application.

[0113] Figure 20 is a schematic block diagram of another example of a communication device provided in an embodiment of the present application.

[0114] Figure 21 is a schematic structural diagram of the communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0115] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the accompanying drawings.

[0116] The technical solutions of the embodiments of the present application can be applied to various communication systems, including but not limited to: fifth generation (5G) systems or new radio systems, long term evolution (LTE) systems, LTE frequency division duplex (FDD) systems, LTE time division duplex (TDD) systems, etc. The technical solutions provided in the present application can also be applied to future communication systems, such as sixth generation (6G) communication systems. In addition, they can also be applied to device to device (D2D) communication, vehicle-to-everything (V2X) communication, machine to machine (M2M) communication, machine type communication (MTC), and Internet of Things (IoT) communication systems or other communication systems.

[0117] The terminal equipment mentioned in this application may also be referred to as user equipment (UE), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent or user device, etc., which is a device that provides voice and / or data connectivity to users. The terminal device in the embodiments of the present application can be a handheld terminal, customer premise equipment (CPE), a laptop computer, a subscriber unit, a cellular phone, a smart phone, a wireless data card, a personal digital assistant (PDA) computer, a tablet computer, a wireless modem, a handheld device, a laptop computer, a session initiation protocol (SIP) phone, a cordless phone or a wireless local loop (WLL) station, a machine type communication (MTC) terminal, a wearable device (such as a smart watch, a smart bracelet, a pedometer, etc.), an in-vehicle device (such as a car, a bicycle, an electric car, an airplane, a ship, a train, a high-speed rail, etc.), a virtual reality (VR) device, an augmented reality (AR) device, a wireless terminal in industrial control, a smart home device (such as a refrigerator, a television, an air conditioner, an electric meter, etc.), an intelligent robot, a workshop device, an unmanned driving (self-driving) device, a wearable device (such as a smart watch, a smart bracelet, a pedometer, etc.), an in-vehicle device (such as a car, a bicycle, an electric car, an airplane, a ship, a train, a high-speed rail, etc.), a virtual reality (VR) device, an augmented reality (AR) device, a wireless terminal in industrial control, a smart home device (such as a refrigerator, a television, an air conditioner, an electric meter, etc.), a smart ... The wireless terminals include wireless terminals in autonomous driving, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, flying equipment (such as intelligent robots, hot air balloons, drones, airplanes, etc.), or other devices that can access the Internet.

[0118] The access network equipment (RAN) mentioned in this application can be a device with wireless transceiver functions. The access network equipment can be a device that provides wireless communication function services, usually located on the network side, including but not limited to the next-generation base station (gNodeB, gNB) in the 5G communication system, the base station in the 6G communication system, the base station in the future mobile communication system or the access node in the wireless fidelity (WIFI) system, the evolved NodeB (eNB) in the LTE system, the radio network controller (RNC), the NodeB (NB), the base station controller (BSC), the home base station (e.g., home evolved NodeB, or home NodeB, HNB), the baseband unit (BBU), the transmission reception point (TRP), the transmitting point (TP), the base transceiver station (BTS), etc. Alternatively, the access network equipment can also be a wireless controller, relay station, vehicle-mounted equipment, and wearable device in the cloud radio access network (CRAN) scenario. Furthermore, a base station can be a macro base station, a micro base station, a relay node, a donor node, or a combination thereof. A base station can also refer to a communication module, modem, or chip used to be installed in the aforementioned devices or apparatuses. A base station can also be a mobile switching center, a device that performs base station functions in D2D, V2X, and M2M communications, a network-side device in a 6G network, or a device that performs base station functions in future communication systems. A base station can support networks with the same or different access technologies, without limitation.

[0119] The core network device mentioned in this application may be a core network (CN) device, which corresponds to different devices in different systems. For example, in a 3G system, it may correspond to a serving GPRS support node (SGSN) and / or a gateway GPRS support node (GGSN) of a general packet radio service (GPRS) technology. For another example, in an LTE system, it may correspond to one or more of a mobility management entity (MME), a serving gateway (SGW), a public data network (PDN) gateway (PGW), a policy and charging rules function (PCRF) network element, a home subscriber server (HSS), and the like. For another example, in a 5G system, it may correspond to one or more network elements or devices such as an access and mobility management function (AMF) network element, a session management function (SMF) network element, a user plane function (UPF) network element, a policy control function (PCF) network element, and a unified data management (UDM) network element. It should be understood that the core network device may be other devices or network elements in other communication devices.

[0120] In an embodiment of the present application, the core network device may further include a multicast / broadcast user plane function (MB-UPF) network element, which is primarily used to implement user plane forwarding functions for multicast / broadcast services. The core network device may further include an AMF network element, which is primarily used to implement activation and deactivation of MBS sessions.

[0121] Multicast and broadcast service (MBS) is a service for multiple UEs, such as live broadcast services, public safety services, and batch software update services. MBS services include multicast services and broadcast services, specifically, both of which transmit the same content to multiple recipients. Taking broadcast services as an example, in order to save terminal energy consumption and network deployment costs, in a one-way broadcast service scenario, the network side can simultaneously broadcast service content to a large number of terminal devices, such as TV or live sports. The R17 standard supports the flexible multiplexing and coexistence of multicast / broadcast and existing unicast systems through the establishment of an architecture, support for different levels of services, flexible network deployment and operation, and multicast / broadcast air interface technology.

[0122] MBS data comes from a data server. The data server first sends the MBS data to a core network device. The core network device then sends the MBS data to an access network device (e.g., a gNB). Finally, the access network device sends the MBS data to one or more UEs within the MBS session. The following further describes the MBS data transmission process in conjunction with the network architecture shown in Figure 1. Figure 1 is a schematic diagram of a network architecture provided by an embodiment of the present application. As shown in Figure 1, the network architecture may include a data server, one or more core network devices, two or more access network devices, and two or more terminal devices.

[0123] The data server is used to send MBS data to the core network device.

[0124] The core network device is used to send MBS data to the access network device through an MBS session when the access network device supports MBS, and to send MBS data to the access network device through a unicast protocol data unit (PDU) session when the access network device does not support MBS.

[0125] The access network device is used to send MBS data to the terminal device through the MBS radio bearer (MRB) when MBS is supported, and to send MBS data to the terminal device through the data radio bearer (DRB) when MBS is not supported.

[0126] The terminal device receives MBS data from the access network device through the MRB when the terminal device is within the range of the access network device that supports MBS; and receives MBS data from the access network device through the DRB when the terminal device is within the range of the access network device that does not support MBS.

[0127] That is, when the access network device supports MBS, the access network device can send MBS data to the terminal device via multicast broadcast. When the access network device does not support MBS, the access network device can send MBS data to the terminal device via unicast.

[0128] It should be noted that the network architecture shown in Figure 1 is not limited to including only the terminal devices, access network devices, and core network devices shown in the figure, but may also include other terminal devices, access network devices, or core network devices not shown in the figure, and this application will not list them one by one here. Unless otherwise specified, the access network devices in the embodiments of this application specifically refer to access network devices that support MBS.

[0129] Figure 2 is a schematic diagram of an MBS data transmission disclosed in an embodiment of the present application. As shown in Figure 2, MBS data can be transmitted between a data server and a core network device via a common transmission channel—an MBS session. Each MBS session includes at least one MBS quality of service (QoS) flow. When an access network device sends MBS data to a UE, the data packets in the MBS data can be transmitted via an MRB. MRB has two transmission modes: one is point-to-multipoint (PTM) transmission, and the other is point-to-point (PTP) transmission.

[0130] PTM transmission mode refers to a service that sends data to multiple terminal devices simultaneously via network equipment. When using PTM transmission, multiple terminal devices simultaneously receive the same data while the access network device is transmitting it. PTP transmission mode refers to a service that sends data to a single terminal device via an access network device. When using PTP transmission, the access network device establishes a separate transmission channel with each terminal device and then sends the data to each terminal separately.

[0131] Multicast services are designed for services with high QoS requirements. Group management is required for multicast services, and the same QoS level as unicast services can be provided. Specifically, for multicast services, the core network needs to manage the joining and exit of UEs. The transmission between core network devices and access network devices relies on MBS sessions, and new MBS QoS flows are introduced. For access network devices, PTP and PTM transmission methods are supported to send data to UEs, and dynamic switching between PTP and PTM controlled by access network devices is supported. In the R17 standard, multicast services can only be provided to UEs in the RRC connected state (RRC_CONNECTED), and access network devices and core network devices are required to maintain UE information corresponding to the multicast service group. At the same time, for multicast services, MBS session deactivation / activation triggered by core network devices is also supported, and the UE is not aware of the service status.

[0132] In the description of the embodiments of the present application, MBS session can also be equivalently replaced (understood as) MBS service, MBS broadcast service, MBS broadcast service or MBS service, etc., and the data of the MBS session is called MBS data.

[0133] In the description of the embodiments of the present application, terms such as MBS, multicast, groupcast, and broadcast can also be replaced with each other. For example, MBS session, multicast session, multicast session, broadcast session, etc. can be replaced with each other, and MBS service, multicast service, multicast service, broadcast service, etc. can also be replaced with each other.

[0134] For the same MBS service, two or more access network devices can be used to send MBS data to multiple terminal devices, expanding the broadcast / multicast range of the MBS service. For example, for the same MBS session, access network device #1 in Figure 1 sends MBS data to UEs such as terminal device #1 and terminal device #3, while access network device #2 sends MBS data to UEs such as terminal device #2.

[0135] Due to factors such as the mobility of terminal devices, the serving base station of some terminal devices may switch while receiving MBS data. For example, after a period of time, terminal device #1 may move and a base station switch may occur. In this case, the serving base station of terminal device #1 switches from access network device #1 to access network device #2. After the base station switch, terminal device #1 can continue to receive MBS data through access network device #2.

[0136] In some cases, if access network device #1 is sending MBS data more slowly than access network device #2, i.e., if access network device #1 is sending MBS data slower than access network device #2, to ensure that terminal device #1 can receive all data packets for the MBS session, i.e., to achieve lossless reception, access network device #1 can forward the data packets for the MBS session required by terminal device #1 to access network device #2. Specifically, access network device #1 needs to forward data packets that have been sent by access network device #2 but not yet sent by access network device #1 (i.e., data packets that lag behind access network device #2) to access network device #2, which then sends these data packets to terminal device #1. During data transmission, under normal circumstances, access network device #2 can send data packets to its UE (e.g., terminal device #1 and terminal device #2) via PTP or PTM. Data forwarded from access network device #1 is typically sent to terminal device #1 via PTP.

[0137] As a specific example, as shown in Figure 1, access network device #1 and access network device #2 send MBS data to the terminal device in the order of packet numbers from #1 to #110. The packet numbers here can be, for example, PDCP sequence numbers (SN). Assume that at the moment when a base station handover occurs in terminal device #1, the progress of access network device #1 sending MBS data to terminal device #1 reaches packet #80, while the progress of access network device #2 sending MBS data to terminal device #2 reaches packet #100. Therefore, data forwarding is required, that is, access network device #1 needs to send data packets numbered #80 to #100 to access network device #2, and access network device #2 continues to send this data to terminal device #1 via PTP, thereby ensuring data integrity and ensuring that terminal device #1 does not miss data due to the base station handover.

[0138] To sum up, considering that the terminal device may switch base stations during the MBS data transmission process, when the source base station lags behind the target base station in sending MBS data packets, data forwarding can be performed. The source base station forwards the data packets that have been sent by the target base station but have not been sent by the source base station to the target base station, and the target base station sends this part of the data to the terminal device via PTP.

[0139] In order to facilitate a better understanding of the embodiments of the present application, the relevant technologies of the embodiments of the present application are described below.

[0140] gNB split architecture

[0141] Please refer to Figure 3, which is a schematic diagram of the separated gNB architecture provided in an embodiment of the present application. Specifically, in the 5G system, a base station is called a gNB or ng-eNB, which primarily includes the RRC / SDAP / PDCP / RLC / MAC / PHY protocol layers. Hereinafter, the term "gNB" will be used to represent a base station.

[0142] As shown in Figure 3, gNBs connect to each other via the Xn interface. The gNB and 5G core (5GC) connect via the NG interface. A gNB can be composed of a centralized unit (CU) and a distributed unit (DU). This means that the base station's functions are split, with some functions deployed in a CU and the remaining functions in the DU. Multiple DUs share a single CU, saving costs and facilitating network expansion. The division between CUs and DUs can be based on the protocol stack. One possible approach is to deploy the radio resource control (RRC), service data adaptation protocol (SDAP), and packet data convergence protocol (PDCP) layers in the CU, while the remaining radio link control (RLC), medium access control (MAC), and physical layers (PHY) are deployed in the DU. The CU and DU are connected via the F1 interface. CU represents the gNB connected to the core network through the NG interface, CU represents the gNB connected to other gNBs through the Xn interface, and CU can also represent the gNB to perform dual connectivity operations with other eNBs through the X2 interface.

[0143] Furthermore, to optimize the location of different radio access network functions based on different scenarios and performance requirements, the gNB-CU can be further subdivided into a control plane (gNB-CU-CP) and a user plane (gNB-CU-UP). Figure 4 is a schematic diagram of a CU-CP and CU-UP separation architecture provided in an embodiment of the present application. As shown in Figure 4, the CU-CP and CU-UP are connected via the E1 interface. The E1 interface is a simple control plane interface, and its functions include E1 interface management and E1 bearer context management.

[0144] Figure 4 shows the split gNB-CU architecture. A gNB can consist of a gNB-CU-CP, multiple gNB-CU-UPs, and multiple gNB-DUs. The gNB-CU-CP connects to the gNB-DU via the F1-C interface, the gNB-CU-UP connects to the gNB-DU via the F1-U interface, and the gNB-CU-UP connects to the gNB-CU-CP via the E1 interface. Each gNB-DU connects to only one gNB-CU-CP, and each gNB-CU-UP connects to only one gNB-CU-CP. The gNB-CU-CP manages the control plane portion of the RRC and PDCP protocols. It also terminates the E1 interface with the gNB-CU-UP and the F1-C interface with the gNB-DU. The gNB-CU-UP manages the user plane portion of the PDCP protocol for the gNB-CU within the en-gNB, as well as the user plane portions of the PDCP and SDAP protocols for the gNB-CU within the gNB. The gNB-CU-UP terminates the E1 interface (with the gNB-CU-CP) and the F1-U (gNB-DU) interface. The gNB-CU-CP implements the gNB control plane functions, including those for the Uu, NG, and Xn interfaces. The gNB-CU-UP provides the gNB user plane functions, including those for the Uu, NG, and Xn interfaces.

[0145] RRC status

[0146] At the RRC layer, a terminal device generally has three states: RRC connected (RRC_CONNECTED), RRC idle (RRC_IDLE), and RRC inactive (RRC_INACTIVE). These three states are described below.

[0147] RRC connected state

[0148] If the terminal device establishes an RRC connection with the network device, the terminal device is in the RRC connected state. In the RRC connected state, the terminal device can establish a user plane and control plane connection with the network device; the network device and the terminal device also save the context of the terminal device's access stratum (AS); the network device can know the cell to which the terminal device belongs; the terminal device can receive data sent by the network device, and the terminal device can also send data to the network device; the terminal device can measure the channel between the terminal device and the network device, and can report the measurement results to the network device. The network device can determine whether to switch the cell to which the terminal device belongs based on the measurement results. In other words, in the RRC connected state, the terminal device and the network device can not only transmit data normally, but the network device can also manage the terminal device.

[0149] RRC idle state

[0150] If the terminal device has not established an RRC connection with the network device, the terminal device is in the RRC idle state. In the RRC idle state, the terminal device can select a Public Land Mobile Network (PLMN); the terminal device can receive system messages broadcast by the network device; the terminal device can reselect a cell; and the terminal device can receive paging messages.

[0151] RRC inactive state

[0152] After the terminal device establishes an RRC connection with the network device, the terminal device enters the RRC connected state. If the terminal device has no data transmission needs with the network device within the preset time period in the RRC connected state, the network device can determine that the terminal device has entered the RRC inactive state, and the network device can send an RRC release (RRCRelease with suspend indication) message carrying a suspension indication to the terminal device. After the terminal device receives the RRCRelease with suspend indication message, the terminal device retains its own context and enters the RRC inactive state. In the RRC inactive state, the terminal device can save the context information of the terminal device and only temporarily disconnect the RRC connection with the network device. When the terminal device has data to transmit, the terminal device can send an RRC recovery request message to the network device.

[0153] Among them, the above three states in the RRC layer can be converted to each other, and Figure 5 is a schematic diagram of the conversion of the RRC state provided by an embodiment of the present application. As shown in Figure 5, when the terminal device is in the RRC connected state, the network device can send an RRC release message to the terminal device, and the terminal device can release the RRC connection between the terminal device and the network device and then enter the RRC idle state. When the terminal device is in the RRC idle state, it can send an RRC establishment request message to the network device, and the network device can establish an RRC connection with the terminal device based on the RRC establishment request message, so that the terminal device can enter the RRC connected state. When the terminal device is in the RRC connected state, the network device can send an RRC release (RRC release with suspend indication) message carrying a suspend indication to the terminal device. After receiving the RRC release with suspend indication message, the terminal device enters the RRC inactive state. When the terminal device is in the RRC inactive state, if there is data to be transmitted, the terminal device may send an RRC resume request message to the network device, and the network device may send an RRC resume response message to the terminal device. After receiving the resume response message, the terminal device may send an RRC resume complete message to the network device, and the terminal device enters the RRC connected state and resumes using the context of the terminal device. It can be understood that the speed of the terminal device entering the RRC connected state from the RRC inactive state is faster than entering the RRC connected state from the RRC idle state. If the terminal device is in the RRC inactive state, the network device may send an RRC release message to the terminal device, and the terminal device enters the RRC idle state.

[0154] The following describes the RRC state transition process for a terminal device based on the gNB separation architecture shown in Figure 4. Figure 6 illustrates the transition process for a UE from the RRC connected state to the RRC inactive state. As shown in Figure 6, the transition process includes:

[0155] In step 11, the gNB-CU-CP sends a BEARER CONTEXT SETUP REQUEST message to the gNB-CU-UP. The message carries the UE-specific inactivity timer. In some cases, the message may also carry the PDU session-specific or DRB-specific inactivity timer.

[0156] Step 12: The gNB-CU-UP sends a BEARER CONTEXT SETUP RESPONSE message to the gNB-CU-CP.

[0157] Step 13: The gNB-CU-UP sends a BEARER CONTEXT INACTIVITY NOTIFICATION message to the gNB-CU-CP, which carries the inactivity monitoring results.

[0158] Specifically, at time t1, the gNB-CU-UP completes downlink data transmission. The inactivity timer starts counting from time t1 until the configured duration (e.g., 10 seconds) is reached. If no downlink data needs to be transmitted during this time, the gNB-CU-CP sends a Bearer Context Inactivity Notification message. If uplink data is received from the UE during this time, the timer is reset and starts again.

[0159] Step 14: After receiving the Bearer Context Inactivity Notification message, the gNB-CU-CP decides to release the UE to the RRC Inactive state.

[0160] In step 15, the gNB-CU-CP sends a BEARER CONTEXT MODIFICATION REQUEST message to the gNB-CU-UP. The message includes a bearer context state change indication, i.e., a suspend indication, indicating that the UE is entering the RRC Inactive state. The gNB-CU-CP retains the F1 uplink address.

[0161] After the gNB-CU-UP receives the BEARER CONTEXT MODIFY REQUEST message containing the SUSPENSION INDICATION, it may suspend sending downlink data to the UE if there is downlink data to be transmitted.

[0162] In step 16, the gNB-CU-UP sends a BEARER CONTEXT MODIFICATION RESPONSE message to the gNB-CU-CP, which includes the uplink and downlink PDCP status that may be used for data volume reporting. The gNB-CU-UP maintains the UE's E1 connection, NG-U resources, and F1 uplink address.

[0163] In step 17, the gNB-CU-CP sends a UE CONTEXT RELEASE COMMAND message to the gNB-DU serving the UE. The message includes the RRC Release message to the UE. Steps 15 and 17 can be performed simultaneously.

[0164] Step 18: The gNB-DU sends an RRC release message to the UE.

[0165] Step 19: After the UE's RRC release procedure is completed, the gNB-DU sends a UE CONTEXT RELEASE COMPLETE message to the gNB-CU-CP.

[0166] FIG7 is a schematic diagram of a process for transitioning a UE from an RRC inactive state to an RRC connected state. As shown in FIG7 , the transition process includes:

[0167] In step 20, the gNB-CU-UP receives downlink data (DL data) from the NG-U interface (i.e., from the core network).

[0168] Step 21: The gNB-CU-UP sends a DL DATA NOTIFICATION message to the gNB-CU-CP.

[0169] Step 22: The gNB-CU-CP sends a PAGING message to the gNB-DU.

[0170] In step 23, the gNB-DU sends a paging message to the UE. Steps 20 to 23 are only required when downlink data arrives.

[0171] Step 24: When a RAN paging scenario or uplink data arrives, the UE sends an RRC Resume Request message to the gNB-DU.

[0172] Step 25: The gNB-DU sends an INITIAL UL RRC MESSAGE TRANSFER message to the gNB-CU-CP.

[0173] In step 26, the gNB-CU-CP sends a UE CONTEXT SETUP REQUEST message to the gNB-DU to establish a UE context. The message includes the stored F1 uplink address.

[0174] In step 27, the gNB-DU responds to the gNB-CU-CP with a UE CONTEXT SETUP RESPONSE message containing the F1 downlink address of the DRB.

[0175] In step 28, the gNB-CU-CP and UE perform the RRC-Resume procedure via the gNB-DU.

[0176] In step 29, the gNB-CU-CP sends a Bearer Context Modification Request message to the gNB-CU-UP, including a Resume Indication indicating that the UE is resuming from the RRC Inactive state. The gNB-CU-CP also carries the F1 downlink address received in step 27. Steps 28 and 29 are parallel steps and can be performed simultaneously.

[0177] After receiving the Bearer Context Modification Request message containing the Resume Indication, the gNB-CU-UP may start sending downlink data to the UE if there is downlink data to be transmitted.

[0178] Step 30: The gNB-CU-UP sends a Bearer Context Modification Response message to the gNB-CU-CP.

[0179] In related technologies, when an MBS service temporarily has no data to send to a terminal device, the access network device can release the terminal device to the RRC inactive state. Since the presence of data is only detected by the user plane, and therefore only the gNB-CU-UP can determine if there is no data, releasing the terminal device to the inactive state is an action that can only be performed by the control plane. Therefore, for MBS services, signaling interactions similar to those shown in Figures 6 and 7 are required between the gNB-CU-UP and the gNB-CU-CP. However, in MBS scenarios, the signaling interaction mechanism (E1 interface interaction) between the gNB-CU-UP and gNB-CU-CP is still incomplete. Furthermore, considering that MBS data is sent to multiple UEs and that terminal devices may switch base stations during transmission, how to achieve reliable transmission of MBS data in this separate CU-CP and CU-UP architecture remains a technical challenge.

[0180] To address the above issues, the present application provides a communication method. According to this communication method, MBS data from other access network devices can be smoothly forwarded by the CU-UP to the corresponding terminal device, ensuring the integrity of the data received by the terminal device. This enables reliable transmission of MBS data and ensures the smooth implementation of MBS services. This application can improve the reliability of the signaling interaction process and improve the signaling interaction mechanism on the E1 interface.

[0181] The following describes a communication method provided by an embodiment of the present application in conjunction with the accompanying drawings. In the embodiment of the present application, the first access network device may be, for example, access network device #2 in FIG. 1 . The first access network device includes a centralized unit-control plane (CU-CP) and a centralized unit-user plane (CU-UP). The first access network device may be, for example, the gNB shown in FIG. 4 . The core network device in the embodiment of the present application may be, for example, the core network device in FIG. 1 , the second access network device may be, for example, access network device #1 in FIG. The first terminal device may be, for example, terminal device #2 in FIG. 1 , and the second terminal device may be, for example, terminal device #1 in FIG. 1 .

[0182] FIG8 is a flow chart of a communication method 100 provided in the present application. The communication method 100 is applied to a first access network device, which includes a centralized unit-control plane CU-CP and a centralized unit-user plane CU-UP. The CU-CP and CU-UP can be respectively arranged on different physical devices and communicated via an E1 interface. The communication method 100 provided in an embodiment of the present application is described below in conjunction with FIG8. The method 100 includes:

[0183] In step 110, the CU-UP sends first indication information to the CU-CP. The first indication information indicates that the CU-UP has not detected first data of a multicast broadcast service (MBS) session within a first preset duration. The first data is data from a core network device. In other words, detecting MBS data from an access network device (hereinafter referred to as second data) does not affect the functionality of the first indication information, nor does it affect the triggering and sending of the first indication information, or the result of determining that no data was detected.

[0184] Accordingly, in step 110 , the CU-CP receives first indication information from the CU-UP.

[0185] Step 120: The CU-CP sends second indication information to the CU-UP according to the first indication information, where the second indication information is used to instruct the CU-UP to stop sending the first data when it detects the first data.

[0186] Accordingly, in step 120 , the CU-UP receives the second indication information from the CU-CP.

[0187] During the transmission of MBS data, there may be a situation where the terminal device switches the serving base station. In order to ensure that the terminal device does not miss data, that is, to ensure the integrity of data reception, the source base station will also forward the relevant MBS data to the target base station, and the target base station will send this part of the data to the terminal device that has switched the serving base station. In other words, the first access network device in the embodiment of the present application can not only send the MBS data from the core network device to the multiple terminal devices it serves, but also forward the MBS data from other access network devices (neighboring base stations) such as the second access network device to the terminal devices it serves. For the same MBS session, the data sent by the first access network device to the terminal device may have two data sources (including two parts), that is, one part comes from the core network device, and the other part comes from other access network devices (neighboring base stations).

[0188] More specifically, under the separate architecture of CU-CP and CU-UP, the CU-UP of the first access network device can receive MBS data from the core network device and forward the MBS data to one or more terminal devices it serves. In addition, the CU-UP of the first access network device can also receive MBS data from other access network devices such as the second access network device, and forward the MBS data to the terminal device it serves. The terminal device may be a terminal device switched from the second access network device to the first access network device. Here, the MBS data from the core network device and the MBS data from other access network devices such as the second access network device may belong to the same MBS session.

[0189] In the embodiment of the present application, for the convenience of expression and understanding, the MBS data from the core network device may be referred to as first data. The first data is sent directly from the core network device to the first access network device without being forwarded by other access network devices such as the second access network device. The first data may be MBS data received by the first access network device through the NG-U port, NG port, or N3 port. The first data may also be expressed or understood as normal data, regular data, or core network data. After receiving the first data, the CU-UP of the first access network device may forward the first data to the multiple terminal devices served by it through PTM or PTP.

[0190] In an embodiment of the present application, for the convenience of expression and understanding, the MBS data from other access network devices such as the second access network device may be referred to as second data. The second data is forwarded by the second access network device and other access network devices to the first access network device. The second data is the MBS data received by the first access network device through the Xn port. The second data may be expressed or understood as forwarded data, indirect data, or neighboring station data, etc. In another scenario, the forwarded data (i.e., the second data) may also be sent to the CU-UP of the first access network device based on the core network, i.e., data received by one CU-UP through the N3 forwarding tunnel from another CU-UP. Here, the data sent through the core network device is regarded as the second data, not the first data. After receiving the second data, the CU-UP of the first access network device may forward the second data to the terminal device where the base station switching has occurred, such as forwarding it to the terminal device switched from the second access network device to the first access network device, in a PTP manner, to ensure the integrity of the data received by the terminal device.

[0191] Optionally, the second data may come from the second access network device, or from any other access network device such as the third access network device, or from multiple devices such as the second access network device and the third access network device. This application does not limit this.

[0192] Optionally, the core network device may be, for example, an MB-UPF.

[0193] Optionally, the first access network device and the second access network device are two completely different access network devices. For example, the second access network device may be a neighboring base station of the first access network device.

[0194] Optionally, as a special case, considering the cell switching within the first access network device, the first access network device and the second access network device may also be the same access network device. At this time, the terminal device undergoes cell switching, and the source cell and the target cell before and after the switching may belong to the same CU-UP or to different CU-UPs. The progress (progress) of the source cell in sending MBS data lags behind that of the target cell, so it is necessary to forward the second data. At this time, the forwarding of the second data is an internal behavior of the first access network device. This application does not limit the specific implementation form. For example, a CU-UP of the first access network device receives (for example, through the N3 forwarding tunnel) the second data from another CU-UP. After the CU-UP obtains the second data, it forwards the second data to the terminal device where the cell switching occurs.

[0195] As a specific example, the first access network device in the embodiment of the present application corresponds to the access network device #2 in Figure 1, and the second access network device corresponds to the access network device #1 in Figure 1. As shown in Figure 1, the access network device #2 (i.e., the first access network device) will not only receive the MBS data (e.g., data packets #1 to #100) from the core network device, but will also receive the MBS data (e.g., data packets #80 to #100) from the access network device #1 (i.e., the second access network device). The access network device #2 can send the MBS data (data packets #1 to #100, i.e., the first data) from the core network device to at least one terminal such as the terminal device #2 via PTP or PTM. The access network device #2 can also forward the MBS data (data packets #80 to #100, i.e., the second data) from the access network device #1 to the terminal device #1 switched from the access network device #1 to the access network device #2 via PTP, thereby ensuring the integrity of the data received by the terminal device #1.

[0196] In an embodiment of the present application, the CU-UP is capable of detecting (perceiving), receiving, and forwarding the first data of the MBS session, which is data from the core network device. For example, the CU-UP is capable of monitoring the NG-U port, the NG port, or the N3 port to determine whether the core network device has downlink data arrival (DL data arrival). If no new first data is detected within a first preset time period after the current first data is sent, that is, if no new data is detected from the core network device within a first preset time period after the MBS data from the core network device is sent (no new data arrival is detected), the CU-UP may indicate to the CU-CP, that is, send first indication information to the CU-CP.

[0197] After CU-CP receives the first indication information, it can determine that the first data of CU-UP has been sent according to the first indication information, and determine that no new first data is detected within the first preset time period thereafter (that is, no new data arrives from the core network device within the first preset time period thereafter). At this time, CU-CP can release one or more terminal devices to the RRC inactive state based on the current actual situation to save terminal energy consumption and communication resources. For example, CU-CP can release at least one of the terminal devices that has not undergone base station switching during the transmission of MBS data and has been served by the first access network device, that is, has been receiving MBS data through the first access network device, to the RRC inactive state.

[0198] Optionally, as a special case, after the CU-CP receives the first indication information, it is also possible that no terminal device is released. This application does not exclude this situation. For example, the CU-CP determines that each terminal does not meet the release condition (requirement) based on the current service situation of each terminal (not limited to MBS service). Therefore, the CU-CP may not release any terminal, that is, keep each terminal device in the RRC connected state.

[0199] Optionally, the first preset duration may be any duration, for example, 1 to 7200 seconds, such as 2 seconds, 3 seconds, 5 seconds, 10 seconds, 30 seconds, 60 seconds, 120 seconds, 180 seconds, 500 seconds, 1000 seconds, 2000 seconds, 5000 seconds, etc. The first preset duration may be pre-configured in a static or semi-static manner. For example, the first preset duration may be determined based on indication (configuration) information from the CU-CP, and the indication information may include, for example, indication information of an inactivity timer.

[0200] Taking into account that some terminals may have been released to the RRC inactive state at this time, the CU-CP can send second indication information to the CU-UP based on the first indication information. The second indication information is used to instruct the CU-UP to stop sending the first data when it detects new first data, such as suspending the sending of the first data, or caching the first data. That is to say, within a period of time thereafter, if the CU-UP detects new first data, it will not send the data. For example, it may pause for a period of time (such as a pre-set duration) before sending, or wait for further instructions from the CU-CP before sending, so as to avoid missing data packets because some terminals are not connected (that is, some terminals are in the RRC inactive state).

[0201] Furthermore, the second indication information instructs CU-UP to stop sending the first data, that is, to stop sending the MBS data from the core network device, but does not stop sending the MBS data from other access network devices (neighboring base stations) such as the second access network device. In other words, CU-UP will not stop forwarding the MBS data from other access network devices such as the second access network device according to the instruction of the second indication information. For example, after CU-UP receives the second indication information, if there is second data that needs to be forwarded, the second data can come from the second access network device or from any other access network device such as the third access network device. At this time, CU-UP will not stop forwarding the second data, thereby avoiding the terminal device that has undergone base station switching from missing data, ensuring the integrity of the data received by the terminal device, and ensuring the smooth progress of the MBS service.

[0202] Optionally, the first indication information and the second indication information may both be transmitted via the E1 interface, for example, both carried in an E1AP message. The E1AP message may be, for example, a multicast bearer context establishment / modification / notification / request / response message, but is not limited thereto.

[0203] Optionally, the first indication information is carried in a multicast / multicast (MC) bearer notification message or a bearer context inactivity notification message. For example, the first indication information includes a temporary no data indication.

[0204] Optionally, the second indication information is carried in an MC bearer context setup request or an MC bearer context modification request (BEARER CONTEXT SETUP / MODIFICATION REQUEST) message. For example, the second indication information includes a suspend indication.

[0205] According to the communication method 100 provided in an embodiment of the present application, after CU-UP fails to detect MBS data (recorded as first data) from a core network device within a first preset time period, it may send a first indication message to CU-CP, and CU-CP may release at least one terminal device according to the first indication message to save terminal energy consumption and communication resources. CU-CP may also send a second indication message to CU-UP according to the first indication message, and the second indication message is used to instruct CU-UP to stop sending the first data when it detects new first data, such as pausing for a period of time before sending the first data, or waiting to receive further instructions from CU-CP before sending, thereby avoiding missing data packets due to the lack of access of a terminal device (in an RRC inactive state).

[0206] Furthermore, considering that the CU-UP of the first access network device may also receive MBS data (recorded as second data) from other access network devices such as the second access network device, the second indication information in the embodiment of the present application instructs the CU-UP to stop sending the first data, rather than instructing the CU-UP to stop sending all MBS data. When there is second data that needs to be forwarded, the CU-UP will not stop forwarding the second data. For example, after receiving the second indication information, if there is second data from the second access network device that needs to be forwarded to the terminal device (the terminal device is switched from the second access network device to the first access network device), the CU-UP will not stop forwarding the second data, thereby avoiding the terminal device from missing data, ensuring the integrity of the data received by the terminal device, and ensuring the smooth operation of the MBS service.

[0207] The communication method 100 provided in the embodiment of the present application can realize reliable transmission of MBS data, avoid data leakage of terminal devices, and can also smoothly reach the corresponding terminal devices for MBS data from other access network devices, ensuring that the terminal devices can achieve the purpose of lossless reception, ensuring that the MBS service can be smoothly implemented, and can improve the reliability of the signaling interaction process, thereby improving the signaling interaction mechanism on the E1 interface.

[0208] Optionally, as shown in FIG8 , in the embodiment of the present application, the communication method 100 further includes:

[0209] In step 130, the CU-CP releases the radio resource control (RRC) connection of the first terminal device according to the first indication information, that is, releases the first terminal device from an RRC connected state to an RRC inactive state. The first terminal device is a terminal device among multiple terminal devices served by the CU-UP that has not received the second data within a first preset time period, and the second data is data from an MBS session of a second access network device, or in other words, the second data is data from the MBS session of another access network device.

[0210] Combined with the above analysis, it can be seen that the MBS data sent by CU-UP to the terminal device may come from the core network device, or from other access network devices such as the second access network device (that is, from a neighboring base station). That is, the MBS data sent by CU-UP to the terminal device may include first data and second data. And for at least part of the second data, it may be transmitted within the first preset time length. That is to say, after the first data from the core network device is sent, within the first preset time length, CU-UP may be forwarding the second data from other access network devices to one (or some) terminal devices, for example, forwarding the second data from the second access network device to the second terminal device.

[0211] On this basis, in order to avoid releasing terminal devices that are still transmitting data, or in other words, to avoid releasing terminal devices that still have second data to transmit, in an embodiment of the present application, CU-CP only releases the first terminal device according to the first indication information, that is, only releases the terminal devices that have not received the second data within the first preset time period, thereby ensuring that the terminal devices that receive the second data can fully receive the second data and ensure the reliability of MBS data transmission.

[0212] Optionally, the first terminal device fails to receive the second data within the first preset time period, which means that the first terminal device fails to receive the second data at any time (for example, the start time, the end time) of the first preset time period.

[0213] Optionally, the CU-CP releases the RRC connection of the first terminal device through a well-known process in the prior art or through other processes. This application does not limit the specific release process. For example, it includes the steps of the CU-CP sending a UE context release command message to the DU, the message carrying an RRC release message (information), and the DU further sending the RRC release message to the first terminal device.

[0214] Optionally, the first terminal device here may be a terminal device that receives the first data but does not receive the second data. In other words, the first terminal device may be a terminal device that has been served by the CU-UP, that is, has been receiving MBS data through the CU-UP without any base station switching or cell switching.

[0215] Optionally, the first terminal device here may also be a terminal device that receives the first data and the second data. Wherein, the first terminal device undergoes base station switching or cell switching, but the first terminal device completes reception of the second data before the start time of the first preset duration. At this time, the first terminal device's reception of the second data will not affect the RRC release of the first terminal device.

[0216] Optionally, the first terminal device here can be one or more, and this application does not limit this.

[0217] Optionally, as shown in FIG8 , step 130 in the embodiment of the present application may be completed (performed) before step 120 , that is, the CU-CP first determines to release at least one terminal device (e.g., the first terminal device) and then sends the second indication information to the CU-UP. In this case, step 130 may serve as a triggering step for step 120 .

[0218] Optionally, in other implementations, step 130 and step 120 may be two parallel steps. This application does not limit the execution order of these two steps. For example, step 130 may be completed (performed) after step 120, or step 130 and step 120 may be performed simultaneously.

[0219] Figure 9 is a flow chart of a communication method 200 provided in the present application. The communication method 200 is applied to a first access network device, which includes a centralized unit-control plane CU-CP and a centralized unit-user plane CU-UP. The CU-CP and CU-UP can be respectively arranged on different physical devices and communicated via an E1 interface. The communication method 200 provided in an embodiment of the present application is described below in conjunction with Figure 9. The communication method 200 includes:

[0220] Step 210: The CU-CP sends an inactivity timer to the CU-UP.

[0221] Accordingly, the CU-UP receives the inactivity timer from the CU-CP.

[0222] Optionally, the inactivity timer may be carried in the bearer context establishment request message, and the inactivity timer may be an MBS session granularity inactivity timer. The duration indicated by the inactivity timer is the aforementioned first preset duration, for example, the duration may be 1 to 7200 seconds.

[0223] Step 220: When the CU-UP determines that the first data has been sent, the inactivity timer starts timing.

[0224] Specifically, the CU-UP forwards the first data, i.e., the MBS data from the core network device. When it is determined that the current first data has been sent, the inactivity timer starts. During the timing of the inactivity timer, the CU-UP detects or senses the first data, for example, by monitoring the NG-U port, NG port, or N3 port, to determine whether new downlink data has arrived at the core network device, i.e., whether new first data has arrived.

[0225] Step 230: During the timing of the inactivity timer, that is, within the first preset duration, the CU-UP sends the second data to the second terminal device.

[0226] Correspondingly, within the first preset time period, the second terminal device receives the second data from the CU-UP.

[0227] Figure 10 is a timing diagram of an example of CU-UP sending data and indication information provided by an embodiment of the present application. In combination with Figures 9 and 10, in an embodiment of the present application, the MBS data sent by the CU-UP to the terminal device also includes second data from other access network devices. Within the first preset time period, the CU-UP can send the second data to the corresponding terminal device, that is, to the second terminal device. For example, the second data comes from the second access network device, and the second terminal device is switched from the second access network device to the first access network device. The second terminal device receives the second data through the first access network device to ensure the integrity of the data received by the second terminal device.

[0228] Optionally, as shown in Figure 10, CU-UP sends the second data to the second terminal device at any time within the first preset time (for example, the start time, the end time), which means "CU-UP sends the second data to the second terminal device within the first preset time". The second data does not need to be sent within the first preset time. For example, at any time within the first preset time (for example, the start time or the end time), CU-UP starts sending the second data to the second terminal device, and the second data is not sent until a certain time after the end time of the first preset time. In addition, the starting time for CU-UP to send the second data can also be before the start time of the first preset time, and this application does not limit this.

[0229] Step 240: The CU-UP sends first indication information to the CU-CP, where the first indication information is used to indicate that the CU-UP has not detected first data of the MBS session within a first preset duration, where the first data is data from a core network device.

[0230] Accordingly, in step 240 , the CU-CP receives the first indication information from the CU-UP.

[0231] Step 240 can be understood with reference to the aforementioned description of step 110 and will not be repeated here.

[0232] In step 250, the CU-CP releases the radio resource control (RRC) connection of the first terminal device according to the first indication information, i.e., releases the first terminal device from an RRC connected state to an RRC inactive state. The first terminal device is a terminal device among multiple terminal devices served by the CU-UP that has not received the second data within a first preset time period, and the second data is data from an MBS session of a second access network device, or in other words, the second data is data from the MBS session of another access network device.

[0233] Step 250 may specifically include: the CU-CP sends an RRC release message to the first terminal device via the DU. Correspondingly, the first terminal device receives the RRC release message from the CU-CP via the DU.

[0234] Step 250 can be understood with reference to the aforementioned description of step 130 and will not be repeated here.

[0235] Step 260: The CU-CP sends second indication information to the CU-UP according to the first indication information, where the second indication information is used to instruct the CU-UP to stop sending the first data when it detects the first data.

[0236] Accordingly, in step 260 , the CU-UP receives the second indication information from the CU-CP.

[0237] Step 260 can be understood with reference to the aforementioned description of step 120 and will not be repeated here.

[0238] In step 270, CU-UP sends a third indication message to CU-CP, where the third indication message is used to indicate that the second data sent to the second terminal device is completed, wherein the second terminal device is a terminal device that receives the second data within a first preset time period among multiple terminal devices served by CU-UP.

[0239] Accordingly, in step 270 , the CU-CP receives the third indication information from the CU-UP.

[0240] The CU-CP releases the RRC connection of the second terminal device according to the third indication information, that is, switches the second terminal device from the RRC connected state to the RRC inactive state.

[0241] Specifically, as shown in Figure 10, the second terminal device is a terminal device that receives the second data within a first preset time period. The second data comes from the second access network device, for example. The second terminal device is switched from the second access network device to the first access network device. The second terminal device receives the second data through the first access network device to ensure the integrity of the data received by the second terminal device. After the second data is sent, the CU-UP can send a third indication message to the CU-CP. The CU-CP can determine that the second data sent to the second terminal device is sent based on the third indication message. In this way, the CU-CP can further release the RRC connection of the second terminal device based on the third indication message to save energy consumption of the second terminal device and save communication resources. By setting the third indication message to instruct the CU-CP to release the second terminal device, the problem of when the second terminal device is released is solved, and the signaling interaction mechanism under the separated architecture is improved.

[0242] Optionally, the second terminal device is a terminal device that receives the second data within a first preset time period. For a certain terminal device, as long as it receives the second data at any time within the first preset time period (for example, the start time, the middle time or the end time), the terminal device can be determined as the second terminal device.

[0243] Optionally, within the first preset time period, there may be multiple terminal devices receiving the second data (the second data received by each terminal device may be different, for example, may come from different access network devices), and the second terminal device may be one of the multiple terminal devices.

[0244] Further, in the embodiment of the present application, the CU-CP releases the RRC connection of the second terminal device according to the third indication information, specifically including:

[0245] The CU-CP releases the RRC connection of the second terminal device according to the aforementioned first indication information and third indication information.

[0246] Optionally, the third indication information includes a forwarding resource release indication. Indicating the release of forwarding resources indicates that the data to be forwarded has been forwarded. This can be an implicit or indirect indication based on the forwarding resource release indication. With the above configuration, no additional indication information is required, which helps save signaling overhead.

[0247] As shown in Figures 9 and 10, the first indication information is sent after the first preset time period, and the third indication information is sent when the second data transmission to the second terminal device is completed. There is no logical order in the timing of the transmission of these two indication information. The first indication information may be sent first, and then the third indication information (as shown in Figure 10); or the third indication information may be sent first, and then the first indication information (as shown in Figure 12). Taking this into account, in order to avoid the second terminal device being released too early, the CU-CP will release the second terminal device only after receiving the first indication information and the third indication information. In other words, the release process of the second terminal device needs to wait for at least the first preset time period before it is carried out, so as to avoid releasing the second terminal device when there may still be data, thereby avoiding frequent switching of the RRC state of the second terminal device.

[0248] Furthermore, the CU-CP releases the RRC connection of the second terminal device according to the first indication information and the third indication information, including:

[0249] In step 280, after the CU-CP receives the third indication information, it determines whether the first indication information has been received. For example, it may be determined that the first indication information has been received. Then, the process proceeds to step 290. If the first indication information has not been received, the process waits until the first indication information is received before releasing the RRC connection of the second terminal device. For example, after receiving the first indication information, multiple terminal devices, including the first terminal device and the second terminal device, may be released simultaneously.

[0250] In step 290, the CU-CP releases the radio resource control RRC connection of the second terminal device, that is, releases the second terminal device from the RRC connection state to the RRC inactive state.

[0251] Step 290 may specifically include: the CU-CP sends an RRC release message to the second terminal device via the DU. Correspondingly, the second terminal device receives the RRC release message from the CU-CP via the DU.

[0252] Figure 11 is a flow chart of a communication method 300 provided in the present application. The communication method 300 is applied to a first access network device, which includes a centralized unit-control plane CU-CP and a centralized unit-user plane CU-UP. The CU-CP and CU-UP can be respectively arranged on different physical devices and communicated via an E1 interface. The communication method 300 provided in an embodiment of the present application is described below in conjunction with Figure 11. The communication method 300 includes:

[0253] Step 310: The CU-CP sends an inactivity timer to the CU-UP.

[0254] Accordingly, the CU-UP receives the inactivity timer from the CU-CP.

[0255] Step 320: When the CU-UP determines that the first data has been sent, the inactivity timer starts timing.

[0256] Step 330: During the timing of the inactivity timer, that is, within the first preset duration, the CU-UP sends the second data to the second terminal device.

[0257] Correspondingly, within the first preset time period, the second terminal device receives the second data from the CU-UP.

[0258] In step 340, CU-UP sends a third indication message to CU-CP, where the third indication message is used to indicate that the second data sent to the second terminal device is completed, wherein the second terminal device is a terminal device that receives the second data within a first preset time period among multiple terminal devices served by CU-UP.

[0259] Accordingly, in step 340 , the CU-CP receives the third indication information from the CU-UP.

[0260] In step 350 , the CU-CP determines that the first indication information has not been received, and does not execute the RRC release process for the second terminal device, but waits for receiving the first indication information.

[0261] Step 360: The CU-UP sends first indication information to the CU-CP, where the first indication information is used to indicate that the CU-UP has not detected the first data of the MBS session within a first preset duration.

[0262] Accordingly, in step 360 , the CU-CP receives the first indication information from the CU-UP.

[0263] In step 370, the CU-CP releases the first terminal device and the second terminal device based on the received first indication information and the third indication information. For example, step 370 may specifically include: the CU-CP sends an RRC release message to the first terminal device and the second terminal device via the DU. Correspondingly, the first terminal device and the second terminal device each receive the RRC release message from the CU-CP via the DU.

[0264] FIG12 is a timing diagram of another example of CU-UP sending data and indication information provided by an embodiment of the present application. As shown in FIG12 , the first indication information is sent after the first preset time duration, and the third indication information is sent when the second data transmission for the second terminal device is completed. There is no logical order in the timing of the transmission of these two indication information. The third indication information may be sent first and then the first indication information. Taking this into account, in order to avoid the second terminal device being released prematurely, the CU-CP releases the second terminal device only after receiving both the first indication information and the third indication information. When the third indication information has been received and the first indication information has not been received, the CU-CP can wait until the first indication information is received before executing the release process for the second terminal device. In other words, the release process for the second terminal device needs to wait for at least the first preset time duration before executing, so as to avoid releasing the second terminal device when there may still be data, thereby avoiding frequent switching of the RRC state of the second terminal device. When executing the release process for the second terminal device, multiple terminal devices including the first terminal device can be released at the same time, thereby simplifying the process.

[0265] Step 380: The CU-CP sends second indication information to the CU-UP according to the first indication information, where the second indication information is used to instruct the CU-UP to stop sending the first data when it detects the first data.

[0266] Accordingly, in step 380 , the CU-UP receives the second indication information from the CU-CP.

[0267] For understanding of the above steps of the communication method 300, reference may be made to the description of the steps of the communication method 200, which will not be repeated here.

[0268] Figure 13 is a flow chart of a communication method 400 provided in the present application. The communication method 400 is applied to a first access network device, which includes a centralized unit-control plane CU-CP and a centralized unit-user plane CU-UP. The CU-CP and CU-UP can be respectively arranged on different physical devices and communicated via an E1 interface. The communication method 400 provided in an embodiment of the present application is described below in conjunction with Figure 13. The communication method 400 includes:

[0269] Step 410 : The CU-CP sends an inactivity timer to the CU-UP.

[0270] Accordingly, the CU-UP receives the inactivity timer from the CU-CP.

[0271] Step 420: When the CU-UP determines that the first data has been sent, the inactivity timer starts timing.

[0272] Step 430: During the timing of the inactivity timer, that is, within the first preset duration, the CU-UP sends the second data to the second terminal device.

[0273] Correspondingly, within the first preset time period, the second terminal device receives the second data from the CU-UP.

[0274] Step 440: The CU-UP sends first indication information to the CU-CP, where the first indication information is used to indicate that the CU-UP has not detected the first data of the MBS session within a first preset duration.

[0275] Accordingly, in step 440 , the CU-CP receives the first indication information from the CU-UP.

[0276] In step 450 , the CU-CP releases the radio resource control RRC connection of the first terminal device according to the first indication information, that is, releases the first terminal device from the RRC connected state to the RRC inactive state.

[0277] Step 450 may specifically include: the CU-CP sends an RRC release message to the first terminal device via the DU. Correspondingly, the first terminal device receives the RRC release message from the CU-CP via the DU.

[0278] Step 460: The CU-CP sends second indication information to the CU-UP according to the first indication information, where the second indication information is used to instruct the CU-UP to stop sending the first data when it detects the first data.

[0279] Accordingly, in step 460 , the CU-UP receives the second indication information from the CU-CP.

[0280] Step 470: After the second data is sent, the inactivity timer starts counting.

[0281] Specifically, the CU-UP forwards the second data, i.e., the MBS data from other access network devices. Upon determining that the current second data has been sent, the inactivity timer begins. During the inactivity timer, the CU-UP detects or senses the MBS data. For example, it may monitor the NG-U port, NG port, or N3 port to determine whether new downlink data has arrived at the core network device, i.e., whether new first data has arrived. For example, it may also monitor the Xn port to determine whether new data has arrived at other access network devices, i.e., whether new second data has arrived.

[0282] In step 480 , the CU-UP sends a third indication message to the CU-CP, where the third indication message is used to indicate that no other data of the MBS session sent to the second terminal device is detected within a second preset time period after the second data is sent.

[0283] In step 490, the CU-CP releases the RRC connection of the second terminal device according to the third indication information, that is, switches the second terminal device from the RRC connected state to the RRC inactive state. At this time, the CU-CP may send an RRC release message to the second terminal device.

[0284] Specifically, if no new MBS data is detected within a second preset duration (i.e., the duration of the inactivity timer in step 470) after the current second data transmission is completed, the CU-UP may indicate to the CU-CP, i.e., send third indication information to the CU-CP. After receiving the third indication information, the CU-CP can determine, based on the third indication information, that the second data of the CU-UP has been transmitted and that no new MBS data has been detected within the subsequent second preset duration, i.e., no detection of the first data, which also constitutes detection of the second data.

[0285] Furthermore, after receiving the third indication information, the CU-CP may release the second terminal device to the RRC inactive state according to the third indication information to save terminal energy consumption and communication resources.

[0286] Optionally, the second preset duration may be the same as or different from the aforementioned first preset duration, and this application does not limit this. The second preset duration may be any duration, for example, 1 to 7200 seconds, such as 2 seconds, 3 seconds, 5 seconds, 10 seconds, 30 seconds, 60 seconds, 120 seconds, 180 seconds, 500 seconds, 1000 seconds, 2000 seconds, 5000 seconds, etc. The second preset duration may be pre-configured in a static or semi-static manner. For example, the second preset duration may be determined based on indication (configuration) information from the CU-CP. The indication information may include, for example, indication information of an inactivity timer. In this case, two inactivity timers may be used to indicate the first preset duration and the second preset duration respectively. When the two durations are equal, one inactivity timer may also be used to indicate the two durations at the same time.

[0287] Compared to the previous embodiment, in this embodiment, the CU-CP releases the first terminal device based on the first indication information, and releases the second terminal device based on the third indication information. The release actions of the first terminal device and the second terminal device are independent of each other and are no longer associated with each other. The first terminal device can be released when the first indication information is received, and the second terminal device can be released when the third indication information is received.

[0288] Figure 14 is a timing diagram of another example of CU-UP sending data and indication information provided by an embodiment of the present application. As shown in Figure 14, the first preset duration and the second preset duration can be equal. At this time, since at least part of the second data is transmitted within the first preset duration, the starting time of the second preset duration is later than the starting time of the first preset duration, and therefore the end time of the second preset duration is also later. That is, the CU-CP first receives the first indication information, and according to the first indication information, the first terminal device can be released first. Then, the third indication information is received, and the second terminal device is released according to the third indication information.

[0289] For understanding of the above steps of the communication method 400, reference may be made to the description of the steps of the communication method 200 and the communication method 300, which will not be repeated here.

[0290] FIG15 is a flow chart of a communication method 500 provided in the present application. The communication method 500 can be considered as a continuation of the aforementioned communication method 200, communication method 300, or communication method 400. The communication method 500 provided in an embodiment of the present application will be described below in conjunction with FIG15. The communication method 500 includes:

[0291] In step 510, the CU-UP sends data arrival indication information to the CU-CP, where the data arrival indication information is used to indicate that new first data has been detected, that is, to indicate that the core network device has issued new MBS data for the MNB session.

[0292] Accordingly, the CU-CP receives data arrival indication information from the CU-UP.

[0293] In step 520, the CU-CP switches the first terminal device from the RRC inactive state to the RRC connected state based on the data arrival indication information. At this time, the CU-CP can send a paging message to the first terminal device via the DU. The subsequent switching process can be referred to the relevant content of Figure 7 above and will not be repeated here.

[0294] Step 530 , determining whether a preset trigger condition is met, if so, proceeding to step 540 .

[0295] Step 540: After determining that the preset trigger condition is met, the CU-CP sends fourth indication information to the CU-UP, where the fourth indication information is used to instruct the CU-UP to resume (continue or start) sending data of the MBS session.

[0296] Correspondingly, CU-UP receives the fourth indication information from CU-CP and resumes the data transmission of the MBS session according to the fourth indication information, that is, executes step 550 to send the first data to the first terminal device, so that the MBS service can continue.

[0297] Optionally, the data arrival indication information and the fourth indication information may both be transmitted via the E1 interface, for example, carried in an E1AP message. The E1AP message may be, for example, a bearer context establishment / modification / notification / request / response message, but is not limited thereto.

[0298] Optionally, the data arrival indication information is carried in the MC bearer notification message or the MC bearer context inactivity notification message.

[0299] Optionally, the fourth indication information is carried in the MC bearer context establishment request or the MC bearer context modification request message. For example, the fourth indication information includes a resume indication.

[0300] Optionally, the trigger condition includes at least one of the following conditions:

[0301] The CU-CP receives data arrival indication information from the CU-UP (ie, step 510 is triggered).

[0302] The CU-CP receives an MBS session activation indication sent by a core network device (eg, AMF).

[0303] The CU-CP receives a group paging message sent by a core network device (e.g., AMF).

[0304] The CU-CP receives a group paging message sent by other access network devices.

[0305] The CU-CP sends a group paging message to the terminal device (for example, step 520 is triggered or is about to be triggered).

[0306] Furthermore, as shown in FIG15 , the CU-CP sends fourth indication information to the CU-UP, including:

[0307] When it is determined that the preset trigger condition is met, the fourth indication information is sent to the CU-UP after waiting for a third preset time period.

[0308] If the fourth indication (resumption indication) is sent directly to the CU-UP when the preset trigger condition is met, some terminal devices may not have connected yet, which may cause the terminal devices to miss the MBS data that has just been sent. Therefore, after the trigger condition is met (triggered), the fourth indication information can be sent after waiting for a third preset time period to prevent terminal devices from missing the MBS data that has just been sent.

[0309] Optionally, the third preset duration may be any duration, for example, 20 milliseconds to 1000 milliseconds, such as 50 milliseconds, 100 milliseconds, 200 milliseconds, 300 milliseconds, 320 milliseconds, 500 milliseconds, or 800 milliseconds. The third preset duration may be pre-configured in a static or semi-static manner.

[0310] Optionally, the third preset duration is greater than or equal to the duration of a paging cycle of a cell of an access network device (CU-CP).

[0311] For example, the paging cycle here may be a default paging cycle configured in system information block (SIB) 1. This is because in the default paging cycle, all non-connected terminal devices will read the paging message at least once.

[0312] The base station architecture of the base station can be a centralized unit (CU)-distributed unit (DU) separated base station architecture (referred to as CU-DU architecture), specifically a shared DU only architecture (only DU shared) in the CU-DU architecture. The base station of this architecture consists of at least two CUs and one shared DU. Each CU can receive MBS data sent by core network equipment corresponding to different operators, and then send the MBS data to the shared DU, which then sends the MBS data to the UE.

[0313] In the above-mentioned shared DU-only architecture, it is assumed that the base station changes from using one CU (for ease of description, referred to as the first CU) to transmit service data to using another CU (for ease of description, referred to as the second CU) to transmit the same service data. The packet data convergence protocol (PDCP) configuration of the first CU and the second CU is the same, but the transmission progress of the MBS service between the first CU and the second CU is different. Then, if the PDCP sequence numbers (PDCP SNs) of the MBS data packets of the same service sent by the DU to the UE are different, and the PDCP sequence numbers of the data packets sent by the second CU are not within the PDCP receiving window (reordering window) for the UE to receive the data packets sent by the first CU, the UE will discard a large number of MBS data packets.

[0314] For example, if the sequence numbers of the data packets received in the current receive window are 1000-2000, that is, the data packets with sequence numbers from 1000 to 2000 are received in sequence within the window. At this time, if a data packet with sequence number 100 is received, it will be discarded. At this time, if data packets with sequence numbers from 100 to 1000 are received, all data packets with sequence numbers from 100 to 1000 will be discarded, resulting in the UE discarding a large number of MBS data packets.

[0315] In order to facilitate a better understanding of the embodiments of the present application, the relevant technologies of the embodiments of the present application are described below.

[0316] (1) Wireless access network sharing (RAN sharing)

[0317] To avoid duplication of network infrastructure, conserve overall network investment, alleviate the enormous financial pressures facing fifth-generation mobile network (5G) construction, and accelerate 5G commercialization, increased network co-construction and sharing efforts are warranted. RAN sharing primarily refers to the ability for a single RAN to connect to multiple operators' core network equipment. This can occur through collaborative RAN construction by multiple operators, or through a single operator independently building the RAN while the others lease its network.

[0318] (2) Separate RAN Sharing Architecture

[0319] Split RAN sharing architectures can include shared CU-DU and shared DU-only architectures. In the shared CU-DU architecture, multiple operators share a CU (referred to as a shared gNB-CU) and a DU (referred to as a shared gNB-DU). In the shared DU-only architecture, multiple operators have their own CUs, but the CUs are not shared. Instead, multiple operators share a single DU (referred to as a shared gNB-DU).

[0320] FIG16 exemplarily shows an architectural diagram of a shared DU architecture.

[0321] The architecture includes the core network equipment 5G core (5GC) corresponding to the three operators, specifically 5GC PLMNA corresponding to operator (Public Land Mobile Network (PLMN)) A, 5GC PLMNB corresponding to operator B, and 5GC PLMNC corresponding to operator C; and gNB-CU corresponding to the three 5G cores, specifically gNB-CU PLMNA corresponding to operator A, gNB-CU PLMNAB corresponding to operator B, and gNB-CU PLMNAC corresponding to operator C; and a shared DU, namely SharedgNB-DU.

[0322] The 5G core and gNB-CU communicate through the NG interface. As shown in Figure 16, the 5GC PLMNA and gNB-CU PLMNA communicate through NG (PLMNA); the 5GC PLMNB and gNB-CU PLMNB communicate through NG (PLMNB); and the 5GC PLMNC and gNB-CU PLMNC communicate through NG (PLMNC).

[0323] The gNB-CU and Shared gNB-DU communicate through the F1 interface. As shown in Figure 16, the gNB-CU PLMNA and Shared gNB-DU communicate through F1 (PLMNA); the Shared gNB-DU and gNB-CU PLMNB communicate through F1 (PLMNB); and the Shared gNB-DU and gNB-CU PLMNC communicate through F1 (PLMNC).

[0324] As shown in Figure 16, gNB-CUs are not shared. Instead, they receive their respective operator's Temporary Multicast Group Identifier (TMGI) and service ID and send them to the shared gNB-DU. In this architecture, because the gNB-CUs of each operator cannot know the TMGI and service IDs of other operators, the gNB-CUs cannot determine whether broadcast services from different operators are the same service. Therefore, gNB-CUs from different operators must send the TMGI and service ID to the shared gNB-DU to determine whether they are the same service.

[0325] The shared CU-DU architecture can consist of multiple operator core networks, a shared gNB-CU, and a shared gNB-DU. The shared gNB-CU receives data from the core networks of different operators. For example, operator A establishes a data transmission channel, also known as an NG-U tunnel, with the gNB-CU. During tunnel establishment, operator A sends TMGI A and service identifier X to the shared gNB-CU. Similarly, operator B sends TMGI B and service identifier X to the shared gNB-CU. Upon receiving this information, the shared gNB-CU determines whether the broadcast services of the two operators are the same based on service identifier X. Alternatively, the shared gNB-CU sends service identifier X to the shared gNB-DU, allowing the shared gNB-DU to determine whether the broadcast services of the two operators are the same.

[0326] In the embodiment of the present application, the split RAN sharing architecture may adopt a shared DU-only architecture.

[0327] Figure 17 illustrates an example in which the CN includes 5G cores corresponding to two operators, namely, 5GC PLMNA corresponding to operator A and 5GC PLMNB corresponding to operator B. The RAN uses a shared DU architecture and includes a Shared gNB-DU, a gNB-CU PLMNA corresponding to operator A, and a gNB-CU PLMNAB corresponding to operator B. The at least one UE includes n UEs, namely, UE1, UE2, to UEn, where n is a positive integer greater than 2. In this embodiment of the present application, the Shared gNB-DU may be referred to as the first node, the gNB-CU PLMNA corresponding to operator A may be referred to as the second node, and the gNB-CU PLMNAB corresponding to operator B may be referred to as the third node.

[0328] For example, using the MBS service as the first service, the data server can send service data for the first service to the gNB-CU PLMNA and the gNB-CU PLMNAB. Specifically, the data server can establish a multicast broadcast service session for the first service (referred to as the first session) with the gNB-CU PLMNA, and a multicast broadcast service session for the first service (referred to as the second session) with the gNB-CU PLMNAB. The data server sends the service data for the first service to the gNB-CU PLMNA via the first session, and the data server sends the service data for the first service via the second session.

[0329] Furthermore, the gNB-CU PLMNA may process the service data of the first service to obtain a first data packet; and the gNB-CU PLMNAB may process the service data of the first service to obtain a second data packet. For ease of description, the data packet obtained after the gNB-CU PLMNA processes the service data of the first service is referred to as the first data packet, and the data packet obtained after the gNB-CU PLMNAB processes the service data of the first service is referred to as the second data packet.

[0330] The processing of the service data of the first service by the gNB-CU PLMNA and the gNB-CU PLMNAB includes configuring the PDCP SN for the data packets of the first service. Because different CUs may have different rules for configuring PDCP SNs, the gNB-CU PLMNA and the gNB-CU PLMNAB may configure different PDCP SNs for the same data packet of the first service.

[0331] Assuming that the PDCP configuration for the first service sent by the gNB-CU PLMNA and the gNB-CU PLMNB to the Shared gNB-DU is the same, the Shared gNB-DU uses the same MRB configuration to transmit service data for the first service. Furthermore, the gNB-CU PLMNA can send the first data packet to the Shared gNB-DU, and the gNB-CU PLMNB can send the second data packet to the Shared gNB-DU. The Shared gNB-DU sends the first data packet or the second data packet to at least one UE based on the same MRB configuration.

[0332] Regarding MRB PDCP configuration in RAN sharing scenarios, several solutions (cases) were proposed in the 3GPP RAN3 120th meeting for the only DU shared scenario, as shown below:

[0333] Case 1: The DU decides which CU's MRB PDCP configuration to select;

[0334] Case 2: The DU coordinates the MRB PDCP configurations of multiple CUs to ensure that different CUs have the same MRB PDCP configuration.

[0335] Case 3: Use default values ​​or preconfigured methods.

[0336] In the currently discussed scenario, only DUs are shared, so the underlying MRB configurations generated by the DUs are identical. This means that, except for the MRB PDCP configuration, all other configurations are identical. However, for CUs, due to the three aforementioned schemes for broadcast PDCP configurations, even without any coordination and using the default configuration, different CUs may generate the same MRB PDCP configuration. Therefore, regardless of whether the CUs coordinate to the same PDCP configuration, it is possible for different CUs to generate the same PDCP configuration.

[0337] Since the DU uses a set of air interface configurations to send data to the UE, if different CUs use the same MRB PDCP configuration, the DU will generate the same MRB configuration and send it to the UE.

[0338] Assume that PLMNA is currently used for service transmission, and PLMNB and PLMNC can also provide service transmission. If you want to use PLMNB for service transmission, you need to change the PDCP configuration of the PLMNA CU to the PDCP configuration of the PLMNB CU. Assuming that the PDCP configuration before and after the modification is the same, then the MRB has not been modified in the eyes of the UE, and the UE will continue to identify whether to receive data packets from the DU based on the current PDCP receive window. Assuming that different core networks have different packet sending progress, the PDCP SN numbers before and after the modification will jump. For example, the PDCP SN number of the data packet sent before the modification is 200, and the PDCP SN number of the data packet sent after the modification is 50. Then, the data packet of PLMNB is outside the current PDCP receive window of the UE, so a large number of data packets are discarded, causing the UE to receive no data for a period of time.

[0339] Please refer to Figure 18, which is a flow chart of a communication method 900 for a multicast broadcast service provided in an embodiment of the present application. The functions performed by the user equipment in this embodiment may also be performed by a module (e.g., a chip) in the user equipment, and the functions performed by the first node in this application may also be performed by a module (e.g., a chip) in the first node.

[0340] In this embodiment of the present application, the first node may be the Shared gNB-DU in Figure 17 ; the second node may be the gNB-CU PLMNA in Figure 17 ; the third node may be the gNB-CU PLMNB in ​​Figure 17 ; and the user equipment may be the UE in Figure 17 . For detailed descriptions of the first node, the second node, the third node, and the user equipment, please refer to the relevant content above and are not repeated here.

[0341] As shown in FIG18 , the communication method 900 for the multicast broadcast service may include the following steps:

[0342] Step 910: The first node sends a first data packet to a user equipment (UE) based on a first multicast data radio bearer (MRB) configuration; the first data packet is sent from the second node to the first node. For example, the first data packet comes from the 5GC PLMNA in FIG17 .

[0343] Correspondingly, the UE receives the first data packet sent by the first node.

[0344] Step 920: When the first condition is met (ie, the first condition is established), the first node sends a first message to the UE, where the first message includes parameter information of the second MRB configuration; the first MRB configuration is different from the second MRB configuration.

[0345] Correspondingly, the UE receives the second MRB configuration sent by the first node.

[0346] In some embodiments, the first condition refers to the first node stopping receiving MBS data from the second node and starting receiving MBS data from the third node. Exemplarily, before the first node sends the first message to the UE, the first node receives a first request from the second node, the first request including a service identifier of the MBS; the first request is used to request the release of the MBS session of the second node.

[0347] Optionally, the first request may further include parameter information configured by the second MRB.

[0348] Among them, the parameter information configured by the second MRB may include at least one of a group radio network temporary identifier (Group Radio Network Temporary Identifier, G-RNTI), a discontinuous reception configuration point to multipoint configuration index (Discontinuous Reception Configuration Point to Mutiple Point Index, DRX-ConfigPTM-Index), a physical downlink shared channel configuration index (Physical Downlink Shared Channel Configuration Index, PDSCH-ConfigIndex), a multicast traffic channel synchronization signal block mapping window index (Multicast Traffic Channel Synchronization Signal and PBCH Block Mapping Window Index, MTCH-SSB-MappingWindowIndex), a multicast radio bearer broadcast list (Multicast Radio Bearer List Broadcast, MRB-ListBroadcas), a logical channel identifier (logicalChannelIdentity), a sequence number field length (sn-FieldLength), and a reassembly timer (t-Reassembly).

[0349] The service identifier of the multicast broadcast service includes at least one of a session identifier of the multicast broadcast service, a temporary multicast group identifier TMGI, and a service network identifier (Network Identifier, NID).

[0350] Take changing the sequence number field length (sn-FieldLength) as an example. TMGI1 is used to indicate that it is the MRB configuration corresponding to the broadcast session of the second node, and TMGI2 is used to indicate that it is the MRB configuration corresponding to the broadcast session of the third node. Before the first MCCH modification period, the PDCP configurations of the second node and the third node are the same. Before the first MCCH modification period, the first node uses the sn-FieldLength of 6 bits in the first MRB configuration. During the first MCCH modification period, the first node receives the first request sent by the second node, and the first request includes parameter information of the second MRB configuration (MRB configuration), including PDCP configuration information, such as data convergence protocol sequence number length (PDCP SN Size), robust header compression (Robust Header Compression, ROHC), and reordering timer (t-Reordering).

[0351] Furthermore, the first node may modify the sn-FieldLength to 12 bits in the second MCCH modification period, and the second MCCH modification period may be the next period of the first MCCH modification period. For example, the first node (such as DU) receives a first request sent by the second node, and the first request includes parameter information of the second MRB configuration, including the PDCP configuration; then, after receiving the PDCP configuration information of the second MRB, the DU may modify the sn-FieldLength from the original 6 bits to 12 bits, so that the DU may broadcast the MRB configuration of 12 bits of sn-FieldLength over the air interface. After the UE sees that the MRB configuration has changed, it may delete the original 6-bit MRB configuration of sn-FieldLength and establish an 18-bit MRB configuration of sn-FieldLength.

[0352] Optionally, after the UE receives the parameter information of the second MRB configuration, it can modify the MRB configuration according to the information. For example, the current first MRB can be released, and a new second MRB can be created according to the parameter information of the second MRB configuration. In this way, there is a new receiving window, that is, the receiving window is reset, and it can be ensured that the newly created receiving window can receive new MBS data (the new MBS data comes from the 5GC PLMNB in ​​Figure 17, for example). In this way, the MBS data from the third node can be accurately received, and data packets will not be discarded. It can also ensure that the order of data submission will not be disordered. This prevents the UE from failing to receive the MBS data packet from the third node normally.

[0353] Optionally, in some special cases (scenarios), even if the UE receives the parameter information configured by the second MRB, it may continue to maintain the current first MRB, that is, not release the first MRB.

[0354] According to the communication method 900 provided in an embodiment of the present application, when the first condition is met, for example, when the first node stops receiving multicast broadcast service MBS data from the second node and starts receiving multicast broadcast service MBS data from the third node, the MRB configuration on the UE side needs to be modified. The first node can send a first message to the UE, and the first message includes parameter information of a second MRB configuration, which is different from the current first MRB configuration.

[0355] After the UE receives the parameter information configured by the second MRB, it can release the current MRB based on the information and create a new MRB based on the parameter information configured by the second MRB. This creates a new receiving window, i.e., the receiving window is reset, thereby ensuring that the newly created receiving window can receive new MBS data, thereby resolving the aforementioned problem of data packet discard caused by the data packet sequence number not being within the data window. MBS data from the third node can then be accurately received without data packet discard, and the order in which data is submitted can be guaranteed to be consistent. This prevents the UE from being unable to normally receive MBS data packets from the third node.

[0356] The communication method according to an embodiment of the present application is described in detail above with reference to Figures 1 to 18 . The communication device according to an embodiment of the present application is described in detail below with reference to Figures 19 to 21 . It should be understood that the communication device shown in Figures 19 to 21 is capable of implementing one or more steps in the aforementioned method flow. To avoid repetition, detailed description is omitted here.

[0357] Figure 19 is a schematic block diagram of a communication device 600 provided in an embodiment of the present application. The communication device 600 may correspond to the CU-CP in the embodiment of the present application, for example, the communication device 600 is the CU-CP in the aforementioned method embodiment. The communication device 600 is applied to a first access network device, which also includes a centralized unit-user plane CU-UP. As shown in Figure 19, the communication device 600 includes a receiving unit 610, a sending unit 620, and a releasing unit 630.

[0358] The receiving unit 610 is used to receive first indication information from the CU-UP, where the first indication information is used to indicate that the CU-UP has not detected first data of a multicast broadcast service MBS session within a first preset time period, and the first data is data from a core network device.

[0359] The sending unit 620 is configured to send second indication information to the CU-UP according to the first indication information, where the second indication information is used to instruct the CU-UP to stop sending the first data when it detects the first data.

[0360] Optionally, the communication device 600 also includes a release unit 630, which is used to release the radio resource control RRC connection of the first terminal device according to the first indication information. The first terminal device is a terminal device among the multiple terminal devices served by the CU-UP that has not received the second data within the first preset time length, and the second data is data from the MBS session of the second access network device.

[0361] Optionally, the receiving unit 610 is also used to: receive third indication information from the CU-UP, the third indication information being used to indicate that the second data sent to the second terminal device is completed, and the second terminal device is a terminal device among multiple terminal devices served by the CU-UP that receives the second data within the first preset time length.

[0362] The release unit 630 is further used to release the RRC connection of the second terminal device according to the third indication information.

[0363] Optionally, in terms of releasing the RRC connection of the second terminal device according to the third indication information, the releasing unit 630 is specifically used to: release the RRC connection of the second terminal device according to the third indication information and the first indication information.

[0364] Optionally, the third indication information is further used to indicate that no other data of the MBS session sent to the second terminal device is detected within a second preset time period after the second data is sent.

[0365] Optionally, the sending unit 620 is further configured to: when it is determined that a preset trigger condition is met, send fourth indication information to the CU-UP, where the fourth indication information is used to instruct the CU-UP to resume sending data for the MBS session.

[0366] Optionally, the trigger condition includes at least one of the following conditions:

[0367] The communication device 600 receives a data arrival indication from the CU-UP;

[0368] The communication device 600 receives an MBS session activation indication sent by a core network device;

[0369] The communication device 600 receives a group paging message sent by a core network device;

[0370] The communication device 600 receives a group paging message sent by other access network devices;

[0371] The communication device 600 sends a group paging message to the terminal device.

[0372] Optionally, in terms of sending the fourth indication information to the CU-UP, the sending unit 620 is specifically used to: when it is determined that the preset trigger condition is met, wait for a third preset time period and then send the fourth indication information to the CU-UP.

[0373] Optionally, the third preset duration is greater than or equal to the duration of a paging cycle.

[0374] In the above implementations, the receiving unit 610 and the sending unit 620 may also be integrated into a transceiver unit, which has both receiving and sending functions, and is not limited here.

[0375] The communication device 600 corresponds to the CU-CP in the aforementioned method embodiment. The receiving unit 610 is configured to perform a receiving action, the sending unit 620 is configured to perform a sending action, and the releasing unit 630 is configured to perform an RRC connection release action. For example, in FIG8 , the receiving unit 610 performs step 110, the sending unit 620 performs step 120, and the releasing unit 630 performs step 130.

[0376] The communication device 600 may also correspond to the first node in the aforementioned method embodiment, and the sending unit 620 is configured to perform a sending action. For example, in FIG18 , the sending unit 620 performs steps 910 and 920 .

[0377] Specifically, the sending unit 620 is configured to send a first data packet to the user equipment UE based on the first multicast data radio bearer MRB configuration; the first data packet is sent from the second node to the first node.

[0378] The sending unit 620 is further configured to send a first message to the UE when a first condition is met, where the first message includes parameter information of the second MRB configuration; the first MRB configuration is different from the second MRB configuration.

[0379] Figure 20 is a schematic block diagram of a communication device 700 provided in an embodiment of the present application. The communication device 700 may correspond to the CU-UP in an embodiment of the present application, for example, the communication device 700 is the CU-UP in the aforementioned method embodiment. The communication device 700 is applied to a first access network device, which also includes a centralized unit-control plane (CU-CP). As shown in Figure 20, the communication device 700 includes a transmitting unit 710 and a receiving unit 720.

[0380] The sending unit 710 is used to send first indication information to the CU-CP, where the first indication information is used to indicate that the device has not detected first data of the multicast broadcast service MBS session within a first preset time period, and the first data is data from a core network device.

[0381] The receiving unit 720 is configured to receive second indication information from the CU-CP, where the second indication information is sent based on the first indication information, and the second indication information is configured to instruct the device to stop sending the first data when the device detects the first data.

[0382] Optionally, the first indication information is also used to enable the CU-CP to release the radio resource control RRC connection of the first terminal device, where the first terminal device is a terminal device among the multiple terminal devices served by the communication device 700 that has not received the second data within the first preset time period, and the second data is data from the MBS session of the second access network device.

[0383] Optionally, the sending unit 710 is also used to: send a third indication message to the CU-CP, the third indication message is used to indicate that the sending of the second data to the second terminal device is completed, the second terminal device is a terminal device among the multiple terminal devices served by the communication device 700 that receives the second data within the first preset time length, and the third indication message is used to enable the CU-CP to release the RRC connection of the second terminal device.

[0384] Optionally, the third indication information is further used to indicate that no other data of the MBS session sent to the second terminal device is detected within a second preset time period after the second data is sent.

[0385] Optionally, the receiving unit 720 is further used to: receive fourth indication information from the CU-CP, where the fourth indication information is used to instruct the communication device 700 to resume sending data for the MBS session, and the fourth indication information is issued after the CU-CP determines that a preset trigger condition is met.

[0386] Optionally, the trigger condition includes at least one of the following conditions:

[0387] The CU-CP receives a data arrival indication from the CU-UP;

[0388] The CU-CP receives an MBS session activation indication sent by a core network device;

[0389] The CU-CP receives a group paging message sent by a core network device;

[0390] The CU-CP receives a group paging message sent by other access network devices;

[0391] The CU-CP sends a group paging message to the terminal device.

[0392] Optionally, when the CU-CP determines that a preset trigger condition is met, the fourth indication information is sent to the communication device 700 after waiting for a third preset time period.

[0393] In a possible implementation, the third preset duration is greater than or equal to the duration of a paging cycle.

[0394] In the above implementations, the sending unit 710 and the receiving unit 720 may also be integrated into a transceiver unit, which has both receiving and sending functions, which is not limited here.

[0395] The communication device 700 corresponds to the CU-UP in the aforementioned method embodiment, wherein the receiving unit 720 is configured to perform a receiving action, and the sending unit 710 is configured to perform a sending action. For example, in FIG8 , the receiving unit 720 performs step 120 and the sending unit 710 performs step 110.

[0396] The communication device 700 may also correspond to the user equipment UE in the aforementioned method embodiment, and the receiving unit 720 is configured to perform a receiving action. For example, in FIG18 , the receiving unit 720 performs steps 910 and 920 .

[0397] Specifically, the receiving unit 720 is configured to receive a first data packet from a first node, where the first data packet is sent from a second node to the first node, and the first node sends the first data packet based on a first multicast data radio bearer MRB configuration.

[0398] The receiving unit 720 is further configured to receive a first message from the first node, the first message including parameter information of the second MRB configuration; the first MRB configuration is different from the second MRB configuration, wherein the first message is sent by the first node to the UE when the first condition is met.

[0399] FIG21 is a schematic structural diagram of a communication device 800 provided in an embodiment of the present application. As shown in FIG18 , the communication device 800 includes: a processor 810, a memory 820, and a communication interface 830. The processor 810 is used to control the communication interface 830 to send and receive signals, and the memory 820 is used to store a computer program. The processor 810 is used to call and execute the computer program from the memory 820 so that the communication device 800 performs the processing (steps) performed by the CU-CP or CU-UP in each method embodiment of the present application.

[0400] For example, the processor 810 may have the functionality of the release unit 630 shown in FIG19 , and the communication interface 830 may have the functionality of the receiving unit 610 and / or the sending unit 620 shown in FIG19 . The communication interface 830 may also have the functionality of the receiving unit 720 and / or the sending unit 710 shown in FIG20 . The processor 810 may be configured to execute processing or operations performed internally by the communication device 800, and the communication interface 830 may be configured to execute sending and / or receiving operations performed by the communication device 800.

[0401] In one implementation, the communication device 800 may be a CU-CP in the method embodiment. In this implementation, the communication interface 830 may be a transceiver. A transceiver may include a receiver and / or a transmitter. Alternatively, the processor 810 may be a baseband device, and the communication interface 830 may be a radio frequency device.

[0402] In another implementation, the communication device 800 may be a chip (or chip system) installed in the CU-CP. In this implementation, the communication interface 830 may be an interface circuit or an input / output interface.

[0403] In one implementation, the communication device 800 may be a CU-UP in the method embodiment. In this implementation, the communication interface 830 may be a transceiver. A transceiver may include a receiver and / or a transmitter. Alternatively, the processor 810 may be a baseband device, and the communication interface 830 may be a radio frequency device.

[0404] In another implementation, the communication device 800 may be a chip (or chip system) installed in the CU-CP. In this implementation, the communication interface 830 may be an interface circuit or an input / output interface.

[0405] In one implementation, the communication device 800 may be the first node in the method embodiment. In this implementation, the communication interface 830 may be a transceiver. A transceiver may include a receiver and / or a transmitter. Alternatively, the processor 810 may be a baseband device, and the communication interface 830 may be a radio frequency device.

[0406] In another implementation, the communication device 800 may be a chip (or chip system) installed in the first node. In this implementation, the communication interface 830 may be an interface circuit or an input / output interface.

[0407] In one implementation, the communication device 800 may be the user equipment (UE) in the method embodiment. In this implementation, the communication interface 830 may be a transceiver. A transceiver may include a receiver and / or a transmitter. Alternatively, the processor 810 may be a baseband device, and the communication interface 830 may be a radio frequency device.

[0408] In another implementation, the communication device 800 may be a chip (or chip system) installed in a user equipment UE. In this implementation, the communication interface 830 may be an interface circuit or an input / output interface.

[0409] Optionally, the memory and processor in the above-mentioned device embodiments may be physically independent units, or the memory and the processor may be integrated together, which is not limited in this document.

[0410] In addition, the present application also provides a computer-readable storage medium, which stores computer instructions (or computer programs). When the computer instructions are executed on a computer, the operations and / or processing performed by the CU-CP in each method embodiment of the present application are executed.

[0411] The present application also provides a computer-readable storage medium, in which computer instructions (or computer programs) are stored. When the computer instructions are run on a computer, the operations and / or processing performed by CU-UP in each method embodiment of the present application are executed.

[0412] The present application also provides a computer-readable storage medium, in which computer instructions (or computer programs) are stored. When the computer instructions are run on a computer, the operations and / or processing performed by the first node in each method embodiment of the present application are executed.

[0413] The present application also provides a computer-readable storage medium, in which computer instructions (or computer programs) are stored. When the computer instructions are executed on a computer, the operations and / or processing performed by the user equipment UE in the various method embodiments of the present application are executed.

[0414] In addition, the present application also provides a computer program product, which includes computer program code or instructions. When the computer program code or instructions are run on a computer, the operations and / or processing performed by the CU-CP in each method embodiment of the present application are executed.

[0415] The present application also provides a computer program product, which includes computer program code or instructions. When the computer program code or instructions are run on a computer, the operations and / or processing performed by the CU-UP in the various method embodiments of the present application are executed.

[0416] The present application also provides a computer program product, which includes computer program code or instructions. When the computer program code or instructions are run on a computer, the operations and / or processing performed by the first node in each method embodiment of the present application are executed.

[0417] The present application also provides a computer program product, which includes computer program code or instructions. When the computer program code or instructions are run on a computer, the operations and / or processing performed by the user equipment UE in the various method embodiments of the present application are executed.

[0418] In addition, the present application also provides a chip, which includes a processor, a memory for storing computer programs is set independently of the chip, and the processor is used to execute the computer program stored in the memory, so that a device equipped with the chip performs the operations and / or processing performed by the CU-CP in any method embodiment.

[0419] Furthermore, the chip may further include a communication interface, which may be an input / output interface or an interface circuit.

[0420] Furthermore, the chip may also include the memory.

[0421] The present application also provides a chip, which includes a processor, a memory for storing computer programs that is set independently of the chip, and the processor is used to execute the computer program stored in the memory, so that a device equipped with the chip performs the operations and / or processing performed by the CU-UP in any method embodiment.

[0422] Furthermore, the chip may further include a communication interface, which may be an input / output interface or an interface circuit.

[0423] Furthermore, the chip may also include the memory.

[0424] The present application also provides a chip, which includes a processor, a memory for storing computer programs that is set independently of the chip, and the processor is used to execute the computer program stored in the memory, so that a device equipped with the chip performs the operations and / or processing performed by the first node in any method embodiment.

[0425] Furthermore, the chip may further include a communication interface, which may be an input / output interface or an interface circuit.

[0426] Furthermore, the chip may also include the memory.

[0427] The present application also provides a chip, which includes a processor, a memory for storing computer programs set independently of the chip, and the processor is used to execute the computer program stored in the memory, so that a device equipped with the chip performs the operations and / or processing performed by the user equipment UE in any method embodiment.

[0428] Furthermore, the chip may further include a communication interface, which may be an input / output interface or an interface circuit.

[0429] Furthermore, the chip may also include the memory.

[0430] Optionally, the processor may be one or more, the memory may be one or more, or the memory may be one or more.

[0431] In addition, the present application also provides a communication device (for example, a chip or a chip system), including a processor and a communication interface, wherein the communication interface is used to receive (or referred to as input) data and / or information, and transmit the received data and / or information to the processor, and the processor processes the data and / or information, and the communication interface is also used to send (or referred to as output) data and / or information after processing by the processor, so that the operations and / or processing performed by the CU-CP in any method embodiment are executed.

[0432] In addition, the present application also provides a communication device (for example, a chip or a chip system), including a processor and a communication interface, wherein the communication interface is used to receive (or called input) data and / or information, and transmit the received data and / or information to the processor, and the processor processes the data and / or information, and the communication interface is also used to send (or called output) data and / or information after processing by the processor, so that the operations and / or processing performed by the CU-UP in any method embodiment are executed.

[0433] In addition, the present application also provides a communication device (for example, a chip or a chip system), including a processor and a communication interface, wherein the communication interface is used to receive (or called input) data and / or information, and transmit the received data and / or information to the processor, and the processor processes the data and / or information, and the communication interface is also used to send (or called output) data and / or information after processing by the processor, so that the operations and / or processing performed by the first node in any method embodiment are executed.

[0434] The present application also provides a communication device (for example, a chip or a chip system), including a processor and a communication interface, wherein the communication interface is used to receive (or be called input) data and / or information, and transmit the received data and / or information to the processor, and the processor processes the data and / or information, and the communication interface is also used to send (or be called output) data and / or information processed by the processor, so that the operations and / or processing performed by the user equipment in any method embodiment are executed.

[0435] In addition, the present application also provides a communication device, comprising at least one processor, wherein the at least one processor is coupled to at least one memory, and the at least one processor is used to execute a computer program or instruction stored in the at least one memory, so that the communication device performs the operations and / or processing performed by the CU-CP in any one method embodiment.

[0436] The present application also provides a communication device, comprising at least one processor, wherein the at least one processor is coupled to at least one memory, and the at least one processor is used to execute a computer program or instruction stored in the at least one memory, so that the communication device performs the operations and / or processing performed by the CU-UP in any one method embodiment.

[0437] In addition, the present application also provides a communication device, comprising at least one processor, wherein the at least one processor is coupled to at least one memory, and the at least one processor is used to execute a computer program or instruction stored in the at least one memory, so that the communication device performs the operations and / or processing performed by the first node in any one method embodiment.

[0438] The present application also provides a communication device, comprising at least one processor, wherein the at least one processor is coupled to at least one memory, and the at least one processor is used to execute a computer program or instruction stored in the at least one memory, so that the communication device performs the operations and / or processing performed by the user equipment in any one of the method embodiments.

[0439] The present application also provides an access network device, including the communication device provided by any of the aforementioned embodiments. For example, the access network device may be a gNB, including the aforementioned communication device 600, communication device 700 or communication device 800.

[0440] It should be understood that the processor in the embodiments of the present application may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0441] It should also be understood that the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0442] The above embodiments can be implemented in whole or in part by software, hardware, firmware or any other combination. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer program are loaded or executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that contains one or more available media sets. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium. The semiconductor medium can be a solid-state drive.

[0443] For ease of understanding, the terms involved in the process of introducing the solution of this application are explained below.

[0444] In the embodiment of the present application, "indication" may include direct indication and indirect indication, and may also include explicit indication and implicit indication. The information indicated by a certain information (such as the "indication information" in the foregoing text) is called information to be indicated. In the specific implementation process, there are many ways to indicate the information to be indicated, such as but not limited to, the information to be indicated can be directly indicated, such as the information to be indicated itself or the index of the information to be indicated. The information to be indicated can also be indirectly indicated by indicating other information, wherein the other information has an association relationship with the information to be indicated. It is also possible to indicate only a part of the information to be indicated, while the other parts of the information to be indicated are known or agreed in advance. For example, the indication of specific information can also be achieved by means of the arrangement order of each information agreed in advance (such as specified in the protocol), thereby reducing the indication overhead to a certain extent.

[0445] In the embodiments of the present application, "first", "second", "third" and various numerical numbers are only used for the convenience of description and are not intended to limit the scope of the embodiments of the present application. For example, different resources are distinguished.

[0446] The “communication protocol” involved in the embodiments of the present application may refer to a standard protocol in the communication field, for example, it may include an LTE protocol, a NR protocol, and related protocols used in future communication systems, and the present application does not limit this.

[0447] The term "and / or" in this document simply describes a relationship between related objects, indicating that three possible relationships exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, or B exists alone. Additionally, the character " / " in this document generally indicates that the related objects are in an "or" relationship.

[0448] In this application, "at least one" means one or more, and "plurality" means two or more. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or plural.

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

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

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

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

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

[0454] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0455] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0456] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A communication method, characterized in that: A centralized unit-control plane CU-CP applied to a first access network device, the first access network device also including a centralized unit-user plane CU-UP, the method comprising: The CU-CP receives first indication information from the CU-UP, where the first indication information is used to indicate that the CU-UP does not detect first data of a multicast broadcast service MBS session within a first preset duration, and the first data is data from a core network device; The CU-CP sends second indication information to the CU-UP according to the first indication information, where the second indication information is used to instruct the CU-UP to stop sending the first data when the CU-UP detects the first data.

2. The method according to claim 1, characterized in that The method further comprises: The CU-CP releases the radio resource control RRC connection of the first terminal device according to the first indication information. The first terminal device is a terminal device among multiple terminal devices served by the CU-UP that has not received second data within the first preset time period. The second data is data of the MBS session from the second access network device.

3. The method according to claim 1 or 2, characterized in that: The method further comprises: The CU-CP receives third indication information from the CU-UP, where the third indication information is used to indicate that sending of second data sent to a second terminal device is completed, where the second terminal device is a terminal device that receives the second data within the first preset time period among multiple terminal devices served by the CU-UP, and the second data is data of the MBS session from a second access network device; The CU-CP releases the RRC connection of the second terminal device according to the third indication information.

4. The method according to claim 3, characterized in that The CU-CP releasing the RRC connection of the second terminal device according to the third indication information includes: The CU-CP releases the RRC connection of the second terminal device according to the third indication information and the first indication information.

5. The method according to claim 3, characterized in that: The third indication information is also used to indicate that within a second preset time period after the second data is sent, no other data of the MBS session sent to the second terminal device is detected.

6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: After determining that the preset trigger condition is satisfied, the CU-CP sends fourth indication information to the CU-UP, where the fourth indication information is used to instruct the CU-UP to resume sending data of the MBS session.

7. The method according to claim 6, characterized in that The trigger condition includes at least one of the following conditions: The CU-CP receives a data arrival indication from the CU-UP; The CU-CP receives an MBS session activation indication sent by a core network device; The CU-CP receives a group paging message sent by a core network device; The CU-CP receives a group paging message sent by other access network devices; The CU-CP sends a group paging message to the terminal device.

8. The method according to claim 6 or 7, characterized in that: The CU-CP sends fourth indication information to the CU-UP, including: When it is determined that the preset trigger condition is met, the fourth indication information is sent to the CU-UP after waiting for a third preset time period.

9. The method according to claim 8, characterized in that The third preset duration is greater than or equal to the duration of a paging cycle.

10. A communication method, characterized in that: A centralized unit-user plane CU-UP applied to a first access network device, the first access network device also including a centralized unit-control plane CU-CP, the method comprising: The CU-UP sends first indication information to the CU-CP, where the first indication information is used to indicate that the CU-UP has not detected first data of a multicast broadcast service MBS session within a first preset duration, where the first data is data from a core network device; The CU-UP receives second indication information from the CU-CP, where the second indication information is sent based on the first indication information, and the second indication information is used to instruct the CU-UP to stop sending the first data when detecting the first data.

11. The method according to claim 10, characterized in that The first indication information is also used to enable the CU-CP to release the radio resource control RRC connection of the first terminal device, where the first terminal device is a terminal device among multiple terminal devices served by the CU-UP that has not received second data within the first preset time period, and the second data is data from the MBS session of the second access network device.

12. The method according to claim 10 or 11, characterized in that: The method further comprises: The CU-UP sends third indication information to the CU-CP, and the third indication information is used to indicate that the sending of second data sent to the second terminal device is completed. The second terminal device is a terminal device that receives the second data within the first preset time period among multiple terminal devices served by the CU-UP. The third indication information is used to enable the CU-CP to release the RRC connection of the second terminal device. The second data is data from the MBS session of the second access network device.

13. The method according to claim 12, characterized in that The third indication information is also used to indicate that within a second preset time period after the second data is sent, no other data of the MBS session sent to the second terminal device is detected.

14. The method according to any one of claims 10 to 13, characterized in that: The method further comprises: The CU-UP receives fourth indication information from the CU-CP, where the fourth indication information is used to instruct the CU-UP to resume sending data for the MBS session, and the fourth indication information is issued after the CU-CP determines that a preset trigger condition is met.

15. A communication device, characterized in that: Applied to a first access network device, the first access network device further includes a centralized unit-user plane CU-UP, and the apparatus includes: a receiving unit, configured to receive first indication information from the CU-UP, where the first indication information is used to indicate that the CU-UP has not detected first data of a multicast broadcast service MBS session within a first preset duration, and the first data is data from a core network device; A sending unit is used to send second indication information to the CU-UP according to the first indication information, wherein the second indication information is used to instruct the CU-UP to stop sending the first data when the CU-UP detects the first data.

16. The device according to claim 15, characterized in that The device also includes: A release unit is used to release the radio resource control RRC connection of a first terminal device according to the first indication information, the first terminal device is a terminal device among multiple terminal devices served by the CU-UP that has not received second data within the first preset time period, and the second data is data from the MBS session of the second access network device.

17. The device according to claim 15 or 16, characterized in that The receiving unit is also used for: receiving third indication information from the CU-UP, where the third indication information is used to indicate that sending of second data sent to a second terminal device is completed, where the second terminal device is a terminal device that receives the second data within the first preset time period among multiple terminal devices served by the CU-UP, and the second data is data of the MBS session from a second access network device; The device further comprises a release unit, which is further used for: Release the RRC connection of the second terminal device according to the third indication information.

18. The device according to claim 17, characterized in that In terms of releasing the RRC connection of the second terminal device according to the third indication information, the releasing unit is specifically used to: Release the RRC connection of the second terminal device according to the third indication information and the first indication information.

19. The device according to claim 17, characterized in that The third indication information is also used to indicate that within a second preset time period after the second data is sent, no other data of the MBS session sent to the second terminal device is detected.

20. The device according to any one of claims 15 to 19, characterized in that The sending unit is also used for: After determining that the preset trigger condition is satisfied, fourth indication information is sent to the CU-UP, where the fourth indication information is used to instruct the CU-UP to resume sending the data of the MBS session.

21. The device according to claim 20, characterized in that In terms of sending the fourth indication information to the CU-UP, the sending unit is specifically configured to: When it is determined that the preset trigger condition is met, the fourth indication information is sent to the CU-UP after waiting for a third preset time period.

22. A communication device, characterized in that: Applied to a first access network device, the first access network device further includes a centralized unit-control plane CU-CP, and the apparatus includes: a sending unit, configured to send first indication information to the CU-CP, wherein the first indication information is used to indicate that the device has not detected first data of a multicast broadcast service MBS session within a first preset duration, and the first data is data from a core network device; A receiving unit is used to receive second indication information from the CU-CP, where the second indication information is sent according to the first indication information, and the second indication information is used to instruct the device to stop sending the first data when the device detects the first data.

23. The device according to claim 22, characterized in that The first indication information is also used to enable the CU-CP to release the radio resource control RRC connection of the first terminal device, where the first terminal device is a terminal device among multiple terminal devices served by the apparatus that has not received second data within the first preset time period, and the second data is data from the MBS session of the second access network device.

24. The device according to claim 22 or 23, characterized in that The sending unit is also used for: Send a third indication message to the CU-CP, wherein the third indication message is used to indicate that the sending of the second data sent to the second terminal device is completed, the second terminal device is a terminal device among multiple terminal devices served by the apparatus that receives the second data within the first preset time period, the second data is data of the MBS session from the second access network device, and the third indication message is used to enable the CU-CP to release the RRC connection of the second terminal device.

25. The device according to claim 24, characterized in that The third indication information is also used to indicate that within a second preset time period after the second data is sent, no other data of the MBS session sent to the second terminal device is detected.

26. The device according to any one of claims 22 to 25, characterized in that The receiving unit is also used for: Receive fourth indication information from the CU-CP, where the fourth indication information is used to instruct the device to resume sending data of the MBS session, and the fourth indication information is sent after the CU-CP determines that a preset trigger condition is met.

27. A communication device, characterized in that: The invention comprises at least one processor, wherein the at least one processor is used to be coupled with a memory, read and execute instructions in the memory, so as to implement the method according to any one of claims 1 to 9, or to implement the method according to any one of claims 10 to 14.

28. An access network device, characterized in that: Comprising the device as claimed in any one of claims 15 to 21, and / or comprising the device as claimed in any one of claims 22 to 26.

29. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed on a computer, the computer is enabled to execute the method according to any one of claims 1 to 9, or the method according to any one of claims 10 to 14.

30. A chip system, characterized in that: It includes a processor for calling and running a computer program from a memory, so that a communication device equipped with the chip system executes the method as claimed in any one of claims 1 to 9, or executes the method as claimed in any one of claims 10 to 14.

Images