Communication method and apparatus for multicast and broadcast service

Abstract

Embodiments of the present application disclose a communication method and apparatus for a multicast and broadcast service. The method comprises: a first node receives a first packet data convergence protocol (PDCP) sequence number from a second node, wherein the first PDCP sequence number is a PDCP sequence number of a first data packet sent by the second node at a first moment; the first node sends the first PDCP sequence number to a third node; the first node receives a second data packet from the third node, wherein a PDCP sequence number of the second data packet is within a receiving window of a PDCP layer of a user equipment (UE); and the first node sends the second data packet to the UE, wherein the first data packet and the second data packet are associated with a first multicast and broadcast service. The method can avoid packet loss when the same multicast and broadcast service is transmitted.

Description

Communication method and device for multicast broadcast service

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on July 31, 2023, with application number 202310958000.1, and priority to the Chinese patent application entitled “A communication method and device for multicast broadcast services”, all contents of which are incorporated by reference into this application. Technical Field

[0002] The embodiments of the present application relate to the field of communication technology, and in particular to a communication method and apparatus for a multicast broadcast service. Background Art

[0003] Multicast and broadcast service (MBS) is a service for multiple user equipment (UE), such as live broadcast services, public safety services, and batch software updates. MBS data can come from the data server corresponding to the service. First, the data server sends the MBS data to the core network device, which then sends the MBS data to the base station. Finally, the base station sends the MBS data to at least one UE receiving the MBS service.

[0004] The base station architecture of the above-mentioned 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.

[0005] In the above-mentioned shared DU-only architecture, it is assumed that the base station changes from using one CU (for convenience of description, referred to as the first CU) to transmit service data to using another CU (for convenience 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 reception 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.

[0006] Summary of the Invention

[0007] The embodiments of the present application disclose a communication method and apparatus for a multicast broadcast service, which can avoid packet loss when transmitting the same multicast broadcast service.

[0008] In a first aspect, the present application discloses a communication method for a multicast broadcast service, which may include:

[0009] The first node receives a first data convergence protocol PDCP sequence number from the second node, where the first PDCP sequence number is the PDCP sequence number of a first data packet sent by the second node at a first moment;

[0010] The first node sends the first PDCP sequence number to the third node;

[0011] The first node receives a second data packet from the third node, where a PDCP sequence number of the second data packet is within a receiving window of a PDCP layer of a user equipment UE;

[0012] The first node sends a second data packet to the UE, where the first data packet and the second data packet are associated with a first multicast broadcast service.

[0013] In an embodiment of the present application, the PDCP sequence number of the first data packet sent by the second node at the first moment is sent to the third node, so that the third node can configure a PDCP sequence number for the second data packet that is within the receiving window of the PDCP layer of the user equipment, wherein the first data packet and the second data packet are associated with a first multicast broadcast service. Therefore, even if the packet sending progress of the second node and the third node is different, since the PDCP sequence number of the second data packet is within the receiving window of the PDCP layer of the user equipment, the user equipment can successfully receive the second data packet, and a large number of second data packets will not be discarded.

[0014] The first moment is the moment when the first data packet is sent.

[0015] The first data packet and the second data packet being associated with the first multicast broadcast service may mean that the first data packet and the second data packet belong to the same multicast broadcast service. For example, the first data packet and the second data packet may carry the same associated session ID.

[0016] As a possible implementation manner, the second node includes a first user plane of the second node and a first control plane of the second node; and the first node receives a first data convergence protocol PDCP sequence number from the second node, including:

[0017] The first node receives a first PDCP sequence number from a first control plane; the first PDCP sequence number is obtained by the first control plane from a first user plane.

[0018] The second node and the second node may be different CUs.

[0019] In the embodiment of the present application, PDCP SN numbers are exchanged between different CUs by using control plane signaling, thereby ensuring that the PDCP SN numbers of different CUs are negotiated to be the same, thereby avoiding packet loss caused by hopping.

[0020] As a possible implementation manner, the third node includes a second user plane of the third node and a second control plane of the third node; and the first node sends the first PDCP sequence number to the third node, including:

[0021] The first node sends the first PDCP sequence number to the second control plane; the second control plane is used to send the first PDCP sequence number to the second user plane; the first PDCP sequence number is used by the second user plane to configure the PDCP sequence number of the second data packet.

[0022] In the embodiment of the present application, PDCP SN numbers are exchanged between different CUs by using interaction on the user plane, thereby ensuring that the PDCP SN numbers of different CUs are negotiated to be the same, thereby avoiding packet loss caused by hopping.

[0023] As a possible implementation manner, the third node includes a second user plane of the third node; and the first node sends the first PDCP sequence number to the third node, including:

[0024] The first node sends the first PDCP sequence number to the second user plane; the first PDCP sequence number is used by the second user plane to configure the PDCP sequence number of the second data packet.

[0025] As a possible implementation manner, the second node includes a first user plane of the second node; and the first node receives a first data convergence protocol PDCP sequence number from the second node, including:

[0026] The first node receives a first PDCP sequence number from a first user plane.

[0027] As a possible implementation manner, the third node includes a second user plane of the third node; and the first node sends the first PDCP sequence number to the third node, including:

[0028] The first node sends the first PDCP sequence number to the second user plane; the first PDCP sequence number is used by the second user plane to configure the PDCP sequence number of the second data packet.

[0029] As a possible implementation manner, the third node includes a second user plane of the third node and a second control plane of the third node; and the first node sends the first PDCP sequence number to the third node, including:

[0030] The first node sends the first PDCP sequence number to the second control plane; the second control plane is used to send the first PDCP sequence number to the second user plane; the first PDCP sequence number is used by the second user plane to configure the PDCP sequence number of the second data packet.

[0031] As a possible implementation manner, before the first node sends the second data packet to the user equipment UE, the process includes:

[0032] The first node receives a first message from the third node, where the first message is used to instruct the first node to use the data packet from the third node. The first message is sent to the first node by the third node after receiving the first PDCP sequence number.

[0033] In an embodiment of the present application, the third node may configure the PDCP sequence number of the second data packet based on the received first PDCP sequence number, and after the configuration is completed, notify the first node to use the second data packet sent by the third node.

[0034] As a possible implementation manner, before the first node receives the first Data Convergence Protocol (PDCP) sequence number from the second node, the method further includes:

[0035] The first node sends a first request to the second node, where the first request is used to request a first PDCP sequence number.

[0036] As a possible implementation manner, before the first node receives the first Data Convergence Protocol (PDCP) sequence number from the second node, the method further includes:

[0037] The first node receives a first data packet from the second node, where a first PDCP sequence number of the first data packet is within a receiving window of a PDCP layer of the UE.

[0038] In a second aspect, the present application discloses a communication method for a multicast broadcast service, which may include:

[0039] The third node receives a first Packet Data Convergence Protocol (PDCP) sequence number from the first node, where the first PDCP sequence number is the PDCP sequence number of the first data packet sent by the second node at the first moment;

[0040] The third node sends a second data packet to the first node, where the PDCP sequence number of the second data packet is within the receiving window of the PDCP layer of the user equipment UE; the first data packet and the second data packet are associated with the first multicast broadcast service.

[0041] As a possible implementation manner, before the third node sends the second data packet to the first node, the method further includes:

[0042] The third node sends a first message to the first node, where the first message is used to instruct the first node to use a data packet from the third node.

[0043] As a possible implementation manner, before the third node sends the second data packet to the first node, the method further includes:

[0044] The third node configures the PDCP sequence number of the second data packet based on the first PDCP sequence number.

[0045] In a third aspect, the present application discloses a communication method for a multicast broadcast service, which may include:

[0046] The second node sends a first Data Convergence Protocol (PDCP) sequence number to the first node, where the first PDCP sequence number is the PDCP sequence number of a first data packet sent by the second node at a first moment.

[0047] As a possible implementation, the method further includes:

[0048] The second node receives a first request from the first node, where the first request is used to request a first PDCP sequence number.

[0049] In a fourth aspect, the present application discloses a communication method for a multicast broadcast service, which may include:

[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] The first node sends a first message to the UE, where the first message includes parameter information of a second MRB configuration; the first MRB configuration is different from the second MRB configuration;

[0052] After sending the first message, the first node sends a second message to the UE, where the second message includes parameter information configured by the first MRB;

[0053] After sending the second message, the first node sends a second data packet to the UE based on the first MRB configuration. The second data packet is sent by the third node to the first node. The first data packet and the second data packet are associated with the first multicast broadcast service.

[0054] The embodiment of the present application deletes and reconstructs the MRB in the MCCH modification period through the above-mentioned first message and second message, so that the UE can perceive that the MRB has changed and a new MRB has been reconstructed, which can solve the problem of packet loss when the first node switches from sending a first data packet to the UE to sending a second data packet in the same MRB.

[0055] As a possible implementation manner, before the first node sends the first message to the UE, the method further includes:

[0056] The first node receives a first request sent by the second node, where the first request includes a service identifier of the multicast broadcast service; the first request is used to request to release a session of the multicast broadcast service of the second node.

[0057] As a possible implementation manner, 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 NID.

[0058] As a possible implementation, at least one configuration parameter in the parameter information of the first MRB configuration is different from that in the parameter information of the second MRB configuration, and the configuration parameter includes at least one of a data convergence protocol sequence number length, robust header compression, and a reordering timer.

[0059] As a possible implementation manner, when the first node receives the first request within a first multicast control channel MCCH modification period, the first node sends the first message within a second MCCH modification period, and the second MCCH modification period is the next MCCH modification period of the first MCCH modification period;

[0060] The time when the first node sends the second message is within a third MCCH modification period, and the third MCCH modification period is the next MCCH modification period of the second MCCH modification period.

[0061] In the embodiment of the present application, the first node may receive the first request, send the first message, and send the second message in three consecutive MCCH cycles. This method may increase the speed of deleting and re-establishing the MRB.

[0062] As a possible implementation, when the first node sends the first message within the fourth MCCH modification period, the first node sends the second message within the fifth MCCH modification period, and the fifth MCCH modification period is the next MCCH modification period of the fourth MCCH modification period.

[0063] In the embodiment of the present application, the first node may send the first message and the second message in two consecutive MCCH cycles. This method can increase the speed of deleting and re-establishing the MRB.

[0064] In a fifth aspect, the present application discloses a communication device for a multicast broadcast service, which may include:

[0065] a receiving unit, configured to receive a first data convergence protocol PDCP sequence number from the second node, where the first PDCP sequence number is the PDCP sequence number of a first data packet sent by the second node at a first moment;

[0066] a sending unit, configured to send the first PDCP sequence number to a third node;

[0067] a receiving unit, configured to receive a second data packet from a third node, where a PDCP sequence number of the second data packet is within a receiving window of a PDCP layer of a user equipment UE;

[0068] The sending unit is configured to send a second data packet to the UE, where the first data packet and the second data packet are associated with a first multicast broadcast service.

[0069] As a possible implementation manner, the second node includes a first user plane of the second node and a first control plane of the second node; and a receiving unit is specifically configured to:

[0070] A first PDCP sequence number is received from a first control plane; the first PDCP sequence number is obtained by the first control plane from a first user plane.

[0071] As a possible implementation manner, the third node includes a second user plane of the third node and a second control plane of the third node; and a sending unit is specifically configured to:

[0072] The first PDCP sequence number is sent to the second control plane; the second control plane is used to send the first PDCP sequence number to the second user plane; the first PDCP sequence number is used by the second user plane to configure the PDCP sequence number of the second data packet.

[0073] As a possible implementation manner, the third node includes a second user plane of the third node; and a sending unit, specifically configured to:

[0074] The first PDCP sequence number is sent to the second user plane; the first PDCP sequence number is used by the second user plane to configure the PDCP sequence number of the second data packet.

[0075] As a possible implementation manner, the second node includes a first user plane of the second node; and a receiving unit, specifically configured to:

[0076] A first PDCP sequence number is received from a first user plane.

[0077] As a possible implementation manner, the third node includes a second user plane of the third node; and a sending unit, specifically configured to:

[0078] The first PDCP sequence number is sent to the second user plane; the first PDCP sequence number is used by the second user plane to configure the PDCP sequence number of the second data packet.

[0079] As a possible implementation manner, the third node includes a second user plane of the third node and a second control plane of the third node; and a sending unit is specifically configured to:

[0080] The first PDCP sequence number is sent to the second control plane; the second control plane is used to send the first PDCP sequence number to the second user plane; the first PDCP sequence number is used by the second user plane to configure the PDCP sequence number of the second data packet.

[0081] As a possible implementation manner, before sending the second data packet to the user equipment UE, the receiving unit is further configured to:

[0082] A first message is received from a third node, where the first message is used to instruct to use a data packet from the third node, and the first message is sent by the third node after receiving a first PDCP sequence number.

[0083] As a possible implementation manner, before receiving the first Data Convergence Protocol (PDCP) sequence number from the second node, the sending unit is further configured to:

[0084] A first request is sent to the second node, where the first request is used to request a first PDCP sequence number.

[0085] As a possible implementation manner, before receiving the first Data Convergence Protocol (PDCP) sequence number from the second node, the receiving unit is further configured to:

[0086] A first data packet is received from the second node, where a first PDCP sequence number of the first data packet is within a receiving window of a PDCP layer of the UE.

[0087] In a sixth aspect, the present application discloses a communication device for a multicast broadcast service, which may include:

[0088] A receiving unit, configured to receive a first Packet Data Convergence Protocol (PDCP) sequence number from the first node, where the first PDCP sequence number is the PDCP sequence number of a first data packet sent by the second node at a first moment;

[0089] The sending unit is configured to send a second data packet to the first node, wherein the PDCP sequence number of the second data packet belongs to the receiving window of the PDCP layer of the user equipment UE; the first data packet and the second data packet are associated with the first multicast broadcast service.

[0090] As a possible implementation manner, before sending the second data packet to the first node, the sending unit is further configured to:

[0091] A first message is sent to the first node, where the first message is used to instruct the first node to use a data packet from the communication device.

[0092] As a possible implementation manner, before sending the second data packet to the first node, the apparatus further includes a configuration unit, the configuration unit being configured to:

[0093] Based on the first PDCP sequence number, a PDCP sequence number of the second data packet is configured.

[0094] In a seventh aspect, the present application discloses a communication device for a multicast broadcast service, which may include:

[0095] The sending unit is configured to send a first Data Convergence Protocol (PDCP) sequence number to the first node, where the first PDCP sequence number is the PDCP sequence number of a first data packet sent by the sending unit at a first moment.

[0096] As a possible implementation manner, the apparatus further includes a receiving unit, the receiving unit being configured to:

[0097] A first request is received from a first node, where the first request is used to request a first PDCP sequence number.

[0098] In an eighth aspect, the present application discloses a communication device for a multicast broadcast service, which may include:

[0099] 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 by the second node to the communication device;

[0100] A sending unit, configured to send a first message to a UE, where the first message includes parameter information of a second MRB configuration; the first MRB configuration is different from the second MRB configuration;

[0101] A sending unit, configured to send a second message to the UE after sending the first message, where the second message includes parameter information configured by the first MRB;

[0102] The sending unit is configured to send a second data packet to the UE based on the first MRB configuration after sending the second message, where the second data packet is sent by the third node to the communication device; the first data packet and the second data packet are associated with the first multicast broadcast service.

[0103] As a possible implementation manner, before sending the first message to the UE, the apparatus further includes a receiving unit, the receiving unit being configured to:

[0104] A first request sent by a second node is received, where the first request includes a service identifier of a multicast broadcast service; the first request is used to request to release a session of the multicast broadcast service of the second node.

[0105] As a possible implementation manner, 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 NID.

[0106] As a possible implementation, at least one configuration parameter in the parameter information of the first MRB configuration is different from that in the parameter information of the second MRB configuration, and the configuration parameter includes at least one of a data convergence protocol sequence number length, robust header compression, and a reordering timer.

[0107] As a possible implementation manner, when the communication device receives the first request within a first multicast control channel MCCH modification period, the communication device sends the first message within a second MCCH modification period, and the second MCCH modification period is the next MCCH modification period of the first MCCH modification period;

[0108] The moment when the communication device sends the second message is within a third MCCH modification period, and the third MCCH modification period is the next MCCH modification period of the second MCCH modification period.

[0109] As a possible implementation, when the communication device sends the first message within the fourth MCCH modification period, the communication device sends the second message within the fifth MCCH modification period, and the fifth MCCH modification period is the next MCCH modification period of the fourth MCCH modification period.

[0110] In a ninth aspect, the present application discloses a communication device for a multicast broadcast service. The communication device for the multicast broadcast service can be the network device in the above-mentioned method embodiment, or a chip or processor provided in the network device. The communication device for the multicast broadcast service includes a processor coupled to a memory, the memory being used to store programs or instructions. When the program or instructions are executed by the processor, the communication device for the multicast broadcast service executes the method performed by the network device, or the chip or processor in the network device, in the above-mentioned method embodiment.

[0111] In a tenth aspect, the present application discloses a communication device for a multicast broadcast service. The communication device for the multicast broadcast service may be the network device in the above-mentioned method embodiment, or a chip provided in the network device. The communication device for the multicast broadcast service includes a processor and a memory, the memory being used to store programs or instructions. When the program or instructions are executed by the processor, the communication device for the multicast broadcast service executes the method performed by the network device, or the chip or processor in the network device, in the above-mentioned method embodiment.

[0112] In an eleventh aspect, the present application discloses a communication device for a multicast broadcast service. The communication device for the multicast broadcast service can be the network device in the above-mentioned method embodiment, or a chip provided in the network device. The communication device for the multicast broadcast service includes a communication interface and a processor, and optionally, a memory. The memory is used to store computer programs or instructions. The processor is coupled to the memory and the communication interface. When the processor executes the computer program or instructions, the communication device for the multicast broadcast service performs the method performed by the network device or the chip in the network device in the above-mentioned method embodiment.

[0113] In the twelfth aspect, the present application discloses a communication system, which may include a network device that executes a communication method for a multicast broadcast service disclosed in the first aspect, a network device that executes a communication method for a multicast broadcast service disclosed in the second aspect, and a network device that executes a communication method for a multicast broadcast service disclosed in the third aspect.

[0114] In a thirteenth aspect, the present application discloses a computer-readable storage medium having a computer program or computer instructions stored thereon. When the computer program or computer instructions are executed by a processor, a communication method for a multicast broadcast service as disclosed in the above aspects is implemented.

[0115] In a fourteenth aspect, the present application discloses a chip, including a processor, for executing a program stored in a memory. When the program is executed, the chip executes the above method.

[0116] As a possible implementation, the memory is located outside the chip.

[0117] In a fifteenth aspect, the present application discloses a computer program product, which includes a computer program code. When the computer program code is executed by a processor, the above-mentioned communication method for multicast broadcast services is executed.

[0118] The beneficial effects of the above-mentioned fifth to fifteenth aspects are similar to the beneficial effects of the corresponding methods in the first to fourth aspects, and detailed descriptions can refer to the beneficial effects of the corresponding methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0119] FIG1 is a schematic diagram of an MBS service transmission architecture provided in an embodiment of the present application;

[0120] FIG2 is a system architecture diagram of an MOCN provided in an embodiment of the present application;

[0121] FIG3 is a schematic diagram of an interface between a CU-CP, a CU-UP, and a DU provided in an embodiment of the present application;

[0122] FIG4 is a schematic diagram of an architecture of a shared DU-only architecture provided in an embodiment of the present application;

[0123] FIG5A is a schematic diagram of a network architecture provided by an embodiment of the present application;

[0124] FIG5B is a schematic diagram of an application scenario provided by an embodiment of the present application;

[0125] FIG6 is a flow chart of another communication method for a multicast broadcast service according to an embodiment of the present application;

[0126] FIG7A is a schematic diagram of a first node coordinating a first PDCP sequence number according to an embodiment of the present application;

[0127] FIG7B is a schematic diagram of another embodiment of the present application providing a first node coordinating a first PDCP sequence number;

[0128] FIG7C is a schematic diagram of another embodiment of the present application providing a first node coordinating a first PDCP sequence number;

[0129] FIG7D is a schematic diagram of another embodiment of the present application providing a first node coordinating a first PDCP sequence number;

[0130] FIG8 is a flow chart of another communication method for a multicast broadcast service according to an embodiment of the present application;

[0131] FIG9A is a flow chart of another communication method for a multicast broadcast service provided in an embodiment of the present application;

[0132] FIG9B is a schematic diagram of changing the PDCP SN size according to an embodiment of the present application;

[0133] FIG10 is a flow chart of another communication method for a multicast broadcast service according to an embodiment of the present application;

[0134] FIG11 is a schematic structural diagram of a communication device for a multicast broadcast service according to an embodiment of the present application;

[0135] FIG12 is a schematic structural diagram of a communication device for a multicast broadcast service according to an embodiment of the present application;

[0136] FIG13 is a schematic structural diagram of another communication device for a multicast broadcast service according to an embodiment of the present application;

[0137] FIG14 is a schematic structural diagram of a communication device for a multicast broadcast service according to another embodiment of the present application;

[0138] FIG15 is a schematic structural diagram of a communication device for a multicast broadcast service according to an embodiment of the present application;

[0139] FIG16 is a schematic structural diagram of another communication device for multicast broadcast services provided in an embodiment of the present application. DETAILED DESCRIPTION

[0140] The embodiments of the present application will be described clearly and in detail below with reference to the accompanying drawings in the embodiments of the present application.

[0141] The terms used in the implementation section of this application are only used to explain the specific embodiments of this application and are not intended to limit this application.

[0142] First, the following definitions of technical terms that may appear in the embodiments of this application are given:

[0143] (1) MBS service transmission architecture

[0144] Multicast and Broadcast Service (MBS) is a service for multiple user equipment (UE), such as live broadcast service, public safety service, batch software update service, etc.

[0145] FIG1 exemplarily shows a schematic diagram of an MBS service transmission architecture.

[0146] As shown in Figure 1, a data server can send MBS service data to a core network device (CN). The CN then sends the MBS data to a gNB, which then sends the MBS data to at least one UE receiving the MBS service. The data server can be the provider of the MBS service data (MBS server).

[0147] When sending data from the core network to the base station, MBS services are transmitted through a common transmission channel, an MBS session. Each MBS session can contain at least one MBS QoS flow. When sending data from the base station to the UE, the data packets are transmitted through an MBS data radio bearer (MRB). An MBS radio bearer has two transmission modes: PTM (point to multi-point) transmission mode and PTP (point to point) transmission mode.

[0148] In the embodiment of the present application, the MBS service may be a multicast service, a broadcast service, or a groupcast service, which is not limited in the embodiment of the present application.

[0149] (2) Wireless access network sharing (RAN sharing)

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

[0151] RAN sharing can include 5G RAN common carrier sharing (Multi-Operator Core Network, MOCN) and 5G RAN multi-carrier sharing (Multi-Operator Radio Access Network, MORAN). The following describes each from the perspectives of resource sharing intensity and service independence:

[0152] In the MOCN sharing model, the core network is independent; configuration management, alarm management, and performance indicators are managed by the primary operator. Some performance indicators can be monitored separately for the Public Land Mobile Network (PLMN), and individual features cannot be enabled. The indoor baseband unit (BBU), remote radio unit (RRU) / active antenna unit (AAU) are all shared, and all site-side RAN equipment is shared. Sharing certain carrier segments or segments from different operators creates a continuous, high-bandwidth shared carrier, reducing infrastructure and equipment costs.

[0153] FIG2 exemplarily shows a system architecture diagram of MOCN.

[0154] As shown in Figure 2, the system architecture can include the core network equipment of two operators: the 5G core network of operator A and the 5G core network of operator B. It also includes a shared base station gNodeB and a shared cell. Users in the shared cell can use operator A's mobile network PLMN A and operator B's mobile network PLMN B.

[0155] In the MORAN sharing model, the core network is independent, 5G RAN equipment is shared, and cells and spectrum are independent. Configuration and alarm management are managed by the primary operator, performance indicators can be monitored separately, and cell-level features can be independently planned and activated. BBU sharing connects to RRUs / AAUs from the same manufacturer. Each RRU / AAU is independent for each operator and carrier, and each carrier is independently configured and managed. On the radio side, within the gNodeB, logically independent cells are used to provide independent use to multiple operators.

[0156] The RAN sharing in the embodiment of the present application adopts the MOCN sharing method.

[0157] (3) CU-DU architecture

[0158] CU stands for Centralized Unit, and DU stands for Distributed Unit. The CU-DU split base station architecture is a new base station architecture introduced in 5G. In the 4G architecture, each base station is independently deployed and connected to the 4G core network. In the 5G architecture, the DU portions of different base stations are independently deployed, while the CU portions of different base stations are centrally deployed.

[0159] From the perspective of physical module structure, the internal structure of a 4G base station is divided into several modules, namely BBU, RRU and antenna. Each base station has a set of BBU and is directly connected to the core network through the BBU. Under the 5G CU-DU separation architecture, the original RRU and antenna are merged into AAU, while the BBU is split into DU and CU. Each base station has a set of DU, and then multiple sites share the same CU for centralized management.

[0160] From the perspective of the protocol stack structure, in a 5G base station, the physical bottom layer in the original 4G base station's BBU is moved to the AAU for processing, and the physical upper layer, media access control (MAC) layer, and radio link control protocol (RLC) layer with high real-time requirements are placed in the DU for processing, while the PDCP layer, service data adaptation protocol (SDAP) layer, and radio resource control (RRC) layer with low real-time requirements are placed in the CU for processing.

[0161] In the CU-DU architecture, the interface between the CU and DU is called the F1 interface. The CU can be further separated into the control plane (CP) and the user plane (UP). Hereinafter, the CU control plane is referred to as the CU-CP, and the CU user plane is referred to as the CU-UP.

[0162] FIG3 exemplarily shows a schematic diagram of interfaces among CU-CP, CU-UP and DU.

[0163] As shown in Figure 3, the interface between the CU-CP and CU-UP is called the E1 interface. A base station typically has only one CU-CP, multiple CU-UPs, and multiple DUs. A DU can connect to only one CU-CP, and a CU-UP can connect to only one CU-CP. The interface between the CU-CP and the DU is called the F1-C, and the interface between the CU-UP and the DU is called the F1-U. Multiple F1-Us can exist between a single DU and multiple CU-UPs. The F1-U is typically used for data transmission and is also called an F1-U tunnel.

[0164] (4) Separate RAN Sharing Architecture

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

[0166] FIG4 exemplarily shows a schematic diagram of an architecture of a shared DU only architecture.

[0167] The architecture includes the core network equipment 5G core (5GC) corresponding to the three operators, which can be specifically 5GC PLMNA corresponding to operator A, 5GC PLMNB corresponding to operator B, and 5GC PLMNC corresponding to operator C; and the gNB-CU corresponding to the three 5G cores, which can be 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.

[0168] The 5G core and gNB-CU communicate through the NG interface. As shown in Figure 4, 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).

[0169] The gNB-CU and Shared gNB-DU communicate through the F1 interface. As shown in Figure 4, 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).

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

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

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

[0173] (5) MBS control channel (MCCH)

[0174] In actual applications, since the UE may start receiving MBS services at any time, to ensure that the UE can obtain MBS control information in a timely manner and thus obtain MBS services, the network side periodically sends MBS control information through the MCCH. In existing communication systems, the transmission process of MCCH information involves two periods: the MCCH repetition period RP (repetition period) and the MCCH modification period MP (modification period). Each MCCH modification period includes multiple MCCH repetition periods; within each MCCH repetition period, the network sends an MCCH message once. The content of the MCCH transmission in each MCCH repetition period within the same MCCH modification period is basically the same. However, for some information that needs to change rapidly, the data transmitted in each MCCH repetition period may also be different.

[0175] When a UE wants to receive MBS data, it generally needs to first read the BCCH (Broadcast Control Channel). Based on system broadcast messages, it obtains the location and configuration information of the MCCH. Then, it reads the MCCH channel to obtain the relevant configuration information of the MTCH. Finally, it obtains the MBS data by reading the MTCH channel. In the above process of the UE obtaining MBS data, the UE obtains the location and configuration of the MCCH through system broadcast messages.

[0176] The MCCH configuration includes the MRB configuration, and the MRB configuration includes the PDCP configuration.

[0177] (6) PDCP Configuration for Broadcast MCCH

[0178] In existing broadcast technologies, the CU configures the PDCP configuration of the broadcast MCCH, and then sends the configuration to the DU via a message (such as BROADCAST CONTEXT SETUP REQUEST), where the message carries the PDCP configuration.

[0179] For example, the BROADCAST CONTEXT SETUP REQUEST includes an MBS CU to DU RRC Information information element, which includes the PDCP configuration of the broadcast MRB. It should be noted that in the embodiment of the present application, the PDCP configuration of the broadcast MCCH may also be referred to as the PDCP configuration of the broadcast MRB, PDCP configuration, or MRB PDCP configuration.

[0180] Since the air interface MCCH information is full configuration information, delta configuration is not supported, that is, new configuration is not supported. If the default PDCP configuration is used, different CUs may generate the same PDCP configuration.

[0181] In the embodiment of the present application, the MRB PDCP configuration may include PDCP SN size (PDCP SN Size), Robust Header Compression (ROHC) and reordering timer (t-Reordering).

[0182] (7) PDCP corresponding receiving window

[0183] At present, in the process of data transmission in the field of mobile communications, the receiving device will maintain a receiving window at the PDCP layer. The receiving window has a fixed window length. For example, the window length is 1 / 2SN, where SN is the maximum sequence number of the PDCP layer data packet. When the data starts to be received, the receiving window is located from the PDCP layer data packet with sequence number 0 to the data packet with sequence number 1 / 2SN-1. When the data packet with sequence number 0 is received, the receiving window will move along the direction of the data packet sequence number from small to large. Assuming that the sequence number of the next PDCP layer data packet that is not received correctly is k, and k is greater than 0, the PDCP layer will The data packets with sequence numbers 0 to k-1 that have been received are delivered to the application layer of the receiving device, and the receiving window will move to the data packets with sequence numbers k to k+1 / 2SN-1. The main reason why the PDCP layer data packet is not received correctly is that the RLC layer of the receiving device has not completed the reception of the RLC layer data packet corresponding to the data packet. This part of the RLC layer data packet that has not been received must be retransmitted by the RLC layer to complete the reception, and after the retransmission is completed, the RLC layer of the receiving device is delivered to the PDCP layer, so that the data packet with the corresponding sequence number that has not been received correctly at the PDCP layer is completed.

[0184] 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:

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

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

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

[0188] 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, since the broadcast PDCP configurations mentioned above include the three items, even without any coordination and using the default configuration, different CUs may generate the same MRB PDCP configuration. Therefore, for all three cases described above, regardless of whether the CUs coordinate to the same PDCP configuration, it is possible for different CUs to generate the same PDCP configuration.

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

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

[0191] Based on the above, in order to better understand the communication method and related devices for multicast broadcast services proposed in this application, the network architecture applied in the embodiments of this application is described below.

[0192] Please refer to Figure 5A, which is a schematic diagram of a network architecture provided in an embodiment of the present application.

[0193] As shown in Figure 5A, the network architecture may include a network device 501 and a user device 502. The network device 501 may be a CU-DU architecture, comprising at least two CUs and a shared DU. Figure 5A exemplarily illustrates that the at least two CUs of the network device 501 are a first CU and a second CU. The shared DU may also be referred to as a first node, the first CU may also be referred to as a second node, and the second CU may also be referred to as a third node.

[0194] The user equipment 502 may be connected to the network device 501 in a wireless manner and may be connected to the core network through the network device 501. The user equipment 502 may be fixed or mobile.

[0195] It should be noted that the first CU, the second CU, and the shared DU can each be a separate network device. In this embodiment of the application, these three separate network devices, the first CU, the second CU, and the shared DU, are referred to as network device 501. Alternatively, at least two of the first CU, the second CU, and the shared DU can also be units in a shared network device. For example, the network device 501 is a shared base station, and the first CU, the second CU, and the shared DU are three units in the shared base station.

[0196] The network device 501 may be an entity for transmitting or receiving signals, or may be a device for communicating with the user equipment 502. The network device may be a base transceiver station (BTS) in a global system for mobile communications (GSM) system or a code division multiple access (CDMA) system, or a base station (NodeB, NB) in a wideband code division multiple access (WCDMA) system, or an evolved NodeB (eNB or eNodeB) in an LTE system, or a wireless controller in a cloud radio access network (CRAN) scenario, or the network device may be a relay station, an access point, an in-vehicle device, a wearable device, a network device in a 5G network, or a network device in a future evolved PLMN network, etc., and the embodiment of the present application is not limited thereto. The network device may be a device in a wireless network, such as a radio access network (RAN) node that connects the user equipment 502 to the wireless network. Currently, some examples of RAN nodes include base stations, next-generation base stations (gNBs), transmission reception points (TRPs), evolved Node Bs (eNBs), home base stations, baseband units (BBUs), or access points (APs) in Wi-Fi systems. In one network architecture, network equipment may include centralized unit (CU) nodes, distributed unit (DU) nodes, or RAN equipment including CU nodes and DU nodes. In an O-RAN system, the CU may also be referred to as an O-CU, and the DU may also be referred to as an O-DU.

[0197] Because the embodiments of the present application mainly involve access network devices, in the following text, unless otherwise specified, the network devices mentioned are all access network devices. In the following text, base stations can be used to represent network devices and / or access network devices.

[0198] In the embodiment of the present application, the network device 501 may include a centralized unit (CU) and a distributed unit (DU). Specifically, the access network device may include one or more centralized units (CU) and one distributed unit (DU), and one DU may also be connected to multiple CUs.

[0199] As an example, the interface between the CU and DU can be called the F1 interface, where the control plane (CP) interface can be F1-C and the user plane (UP) interface can be F1-U. The CU and DU can be divided according to the protocol layers of the wireless network. For example, the functions of the PDCP layer and above are set in the CU, and the functions of the protocol layers below the PDCP layer (such as the RLC layer and MAC layer, etc.) are set in the DU.

[0200] It will be appreciated that the above division of processing functions between the CU and DU by protocol layer is merely an example, and the division may be performed in other ways. For example, functions of protocol layers above the RLC layer may be located in the CU, while functions of protocol layers below the RLC layer may be located in the DU. Alternatively, the CU or DU may be divided to include functions of more protocol layers, or to include partial processing functions of protocol layers. In one design, partial functions of the RLC layer and functions of protocol layers above the RLC layer are located in the CU, while the remaining functions of the RLC layer and functions of protocol layers below the RLC layer are located in the DU. In another design, the functions of the CU or DU may be divided according to service type or other system requirements, for example, by latency, with functions whose processing time must meet latency requirements located in the DU, and functions that do not meet these latency requirements located in the CU. In another design, the CU may also include one or more functions of the core network. For example, the CU may be located on the network side to facilitate centralized management; the DU may include multiple radio frequency functions, or the radio frequency functions may be remotely located. This is not limited in the present embodiments.

[0201] Exemplarily, the functions of the CU can be implemented by one entity, or can be implemented by different entities. For example, the functions of the CU are further divided, that is, the control plane and the user plane are separated and implemented through different entities, namely the control plane CU entity (i.e., CU-CP entity) and the user plane CU entity (i.e., CU-UP entity). The CU-CP entity and the CU-UP entity can be coupled with the DU to jointly complete the functions of the RAN device. The interface between the CU-CP entity and the CU-UP entity can be an E1 interface, the interface between the CU-CP entity and the DU can be an F1-C interface, and the interface between the CU-UP entity and the DU can be an F1-U interface. Among them, one DU and one CU-UP can be connected to one CU-CP. Under the control of the same CU-CP, one DU can be connected to multiple CU-UPs, and one CU-UP can be connected to multiple DUs.

[0202] The user equipment 502 is an entity on the user side for receiving or transmitting signals, and is mainly used to implement wireless communication with the network device 501 .

[0203] For example, user equipment 502 can be an access terminal, a subscriber unit, a subscriber station, a mobile station, a mobile station, a remote station, a remote terminal, a mobile device, a user terminal, a terminal, a wireless communication device, a user agent, or a user device. The user equipment 502 may also be a mobile phone, a cellular phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a tablet computer, a computer with wireless transceiver function, a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal in industrial control, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device with wireless communication function, a computing device or other processing device connected to a wireless modem, an in-vehicle device, a wireless terminal in self-driving, a wireless terminal in remote medical, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, a wearable device (such as a smart watch, a smart bracelet, a pedometer, etc.), a terminal device in a 5G network, or a future-evolved public land mobile communication network. The embodiment of the present application does not limit this. The user equipment 502 can be deployed on land, including indoors or outdoors, handheld, wearable or vehicle-mounted, and can also be deployed on the water (such as ships, etc.), and can also be deployed in the air (for example, on airplanes, balloons and satellites, etc.). In the embodiment of the present application, the user equipment 502 can be a legacy UE, or a RB-level partial frequency hopping (RPFS) UE that supports SRS coverage and capacity enhancement, or other UE. The present application does not limit the type of user equipment 502. Among them, legacy UE refers to a user equipment that supports the existing mechanism, for example, a user equipment that supports release-15 and release-16.

[0204] In an embodiment of the present application, the user device 502 or the network device 501 includes a hardware layer, an operating system layer running on the hardware layer, and an application layer running on the operating system layer. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory (also known as main memory). The operating system can be any one or more computer operating systems that implement business processing through processes, such as a Linux operating system, a Unix operating system, an Android operating system, an iOS operating system, or a Windows operating system. The application layer includes applications such as browsers, address books, word processing software, and instant messaging software. In addition, the embodiment of the present application does not specifically limit the specific structure of the execution subject of the method provided in the embodiment of the present application. As long as it is possible to communicate according to the method provided in the embodiment of the present application by running a program that records the code of the method provided in the embodiment of the present application, for example, the execution subject of the method provided in the embodiment of the present application can be the user device 502 or the network device 501, or it can be a functional module in the user device 502 or the network device 501 that can call a program and execute the program.

[0205] It should be noted that the number and type of user devices 502 included in the network architecture shown in FIG5A are merely examples, and embodiments of the present application are not limited thereto. For example, more or fewer user devices 502 communicating with the network device 501 may be included. For the sake of simplicity, they are not described one by one in the accompanying drawings.

[0206] In addition, in the network architecture shown in Figure 5A, although the network device 501 and the user device 502 are shown, the application scenario may not be limited to including the network device 501 and the user device 502. For example, it may also include a core network device or a device for carrying virtualized network functions, etc., wherein the core network device communicates with the user device 502 through the network device 501. For an example, please refer to the application scenario shown in Figure 5B below.

[0207] The technical solutions of the embodiments of the present application can be applied to various communication systems, such as: global system of mobile communication (GSM) system, code division multiple access (CDMA) system, wideband code division multiple access (WCDMA) system, general packet radio service (GPRS), long term evolution (LTE) system, LTE frequency division duplex (FDD) system, LTE time division duplex (TDD), universal mobile telecommunication system (UMTS), world-wide interoperability for microwave access (WiMAX) communication system, fifth generation (5G) system or new radio (NR) and future communication systems, etc., without limitation here.

[0208] Taking the 5G system in the embodiment of the present application as an example, an application scenario of the MBS service in the embodiment of the present application is introduced.

[0209] Please refer to Figure 5B, which is a schematic diagram of an application scenario exemplarily provided by an embodiment of the present application. The application scenario includes a data server, a CN, a RAN, and at least one UE.

[0210] Among them, the data server can be the provider of MBS services, such as the application server corresponding to live broadcast services, public safety services, and batch software update services; CN, access network equipment and user equipment are network elements in the network architecture of the 5G network.

[0211] Figure 5B exemplifies a CN including 5G cores corresponding to two operators, namely, 5GC PLMNA corresponding to operator A and 5GC PLMNB corresponding to operator B. The RAN adopts a shared DU architecture, comprising 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.

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

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

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

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

[0216] It should be noted that the network device 501 in FIG. 5A may be the RAN in FIG. 5B ; and the user equipment 502 in FIG. 5A may be at least one UE in FIG. 5B .

[0217] Among them, the communication between the access network equipment and the user equipment follows a certain protocol layer structure. For example, the control plane protocol layer structure may include the radio resource control (RRC) layer, the packet data convergence protocol (PDCP) layer, the radio link control (RLC) layer, the media access control (MAC) layer and the physical layer (PHY); the user plane protocol layer structure may include the PDCP layer, the RLC layer, the MAC layer and the physical layer. In one possible implementation, a service data adaptation protocol (SDAP) layer may also be included above the PDCP layer.

[0218] For MBS services, the data transmission direction of MBS services is from the access network equipment to the user equipment. For example, MBS service data can be live broadcast service data, public safety service data, or batch software update service data, etc., without limitation here.

[0219] In other embodiments of the present application, in the above application scenario, the third node may also be connected to a non-shared DU (non-shared DU), specifically, the CU-CP of the third node may be connected to the DU. Data sent by the third node to the first node may be sent synchronously to the DU.

[0220] In combination with the above-mentioned network architecture, a communication method for a multicast broadcast service provided in an embodiment of the present application is described below.

[0221] Please refer to Figure 6, which is a flow chart of a communication method for a multicast broadcast service provided in an embodiment of the present application. The functions performed by the user equipment in this embodiment can also be performed by a module (e.g., a chip) in the user equipment, and the functions performed by the network device in this application can also be performed by a module (e.g., a chip) in the network device.

[0222] In this embodiment of the present application, the first node may be the shared DU in Figure 5A or the shared gNB-DU in Figure 5B ; the second node may be the first CU in Figure 5A or the gNB-CU PLMNA in Figure 5B ; the third node may be the second CU in Figure 5A or the gNB-CU PLMNB in ​​Figure 5B ; and the user equipment may be the user equipment 502 in Figure 5A or the UE in Figure 5B . 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.

[0223] As shown in FIG6 , the communication method for the multicast broadcast service may include the following steps:

[0224] Step S601: the second node sends a first Data Convergence Protocol (PDCP) sequence number to the first node. The first PDCP sequence number is the PDCP sequence number of a first data packet sent by the second node at a first moment.

[0225] Correspondingly, the first node receives the first PDCP sequence number from the second node.

[0226] The first data packet may be service data of an MBS service, and the MBS service may be a live broadcast service, a public safety service, a batch software update service, or the like.

[0227] Taking Figure 5B as an example, the second node may be the CU corresponding to operator A's core network (i.e., 5GCPLMNA). After receiving the service data of the MBS service from the data server, the 5GCPLMNA processes the service data; then, it sends the processed first data packet to the second node; the second node may process the first data packet, such as configuring the PDCP sequence number of the first data packet; then, the second node may send the configured first data packet to the first node, which in turn sends the first data packet to the user equipment. The PDCP sequence number of the first data packet may be specifically configured by the user plane of the second node. For ease of description, in this embodiment of the present application, the user plane of the second node is referred to as CU-UP1.

[0228] In some embodiments, before executing step S601, the first node receives a first data packet from the second node, wherein the first PDCP sequence number of the first data packet is within the receiving window of the PDCP layer of the UE. Then, the first node sends the first data packet to the user equipment.

[0229] In some other embodiments, the first node sends a first request to the second node, where the first request is used to request a first PDCP sequence number, and then the second node sends a first Data Convergence Protocol PDCP sequence number to the first node.

[0230] Step S602: The first node sends the first PDCP sequence number to the third node.

[0231] Correspondingly, the third node receives the first PDCP sequence number from the first node.

[0232] Step S603: the third node sends a second data packet to the first node, where the PDCP sequence number of the second data packet is within the receiving window of the PDCP layer of the user equipment UE; the first data packet and the second data packet are associated with the first multicast broadcast service.

[0233] Correspondingly, the first node receives the second data packet from the second node. The first multicast broadcast service (also referred to as the first MBS service) may be a live broadcast service, a public safety service, a batch software update service, or the like.

[0234] In some embodiments, after receiving the first PDCP sequence number sent from the first node, the third node may configure the PDCP sequence number of the second data packet based on the first PDCP sequence number, and then send the configured second data packet to the first node.

[0235] Exemplarily, the third node may configure the second data packet currently being processed as the next PDCP sequence number of the first PDCP sequence number. The embodiment of the present application does not limit the numbering rules of the PDCP sequence numbers, that is, the next PDCP sequence number of the first PDCP sequence number may be the next value of the numerical value of the first PDCP sequence number, such as if the first PDCP sequence number is 50, the next PDCP sequence number of the first PDCP sequence number is 51; the next PDCP sequence number of the first PDCP sequence number may not be the next value of the numerical value of the first PDCP sequence number, which is determined by the numbering rules of the PDCP sequence number. In the embodiment of the present application, the numbering rules of the PDCP sequence numbers of the second node and the third node may be the same or different.

[0236] Exemplarily, assuming that the moment when the third node receives the first PDCP sequence number is moment t, the third node can configure the data packet received from the second core network or the second data packet sent to the first node after moment t based on the first PDCP sequence number and the window length of the receiving window of the PDCP layer. For example, if the first PDCP sequence number is 50 and the window length of the receiving window of the PDCP layer is 100, then the PDCP sequence number of the second data packet can be 51 to 150, and 51 to 150 all belong to the receiving window of the PDCP layer of the current UE. The embodiment of the present application does not limit the window length of the receiving window of the PDCP layer.

[0237] In one implementation, the PDCP window length corresponding to the first PDCP SN can be obtained from the SN length in the PDCP configuration. For example, if the PDCP SN length is 12 bits, the receiving window length is 2. 12-1 . Assume that the third node includes a user plane CU-UP2 and a control plane CU-CP2, CU-UP2 judges the PDCP SN of the current second data packet (referred to as the second PDCP SN) based on the first PDCP SN and the PDCP window corresponding to the reception of the first PDCP SN. If the second PDCP SN is within the above-mentioned PDCP receiving window, the second PDCP SN is not modified; if the second PDCP SN is outside the above-mentioned PDCP receiving window, the second PDCP SN is modified. The embodiment of the present application does not limit the method for modifying the PDCP SN, as long as the second PDCP SN after modification is within the above-mentioned PDCP receiving window.

[0238] Step S604: the first node sends a second data packet to the user equipment.

[0239] Correspondingly, the UE receives the second data packet from the first node.

[0240] In some embodiments, before the first node sends the second data packet to the user equipment UE, the first node includes:

[0241] The first node receives a first message from the third node, where the first message is used to instruct the first node to use the data packet from the third node. The first message is sent to the first node by the third node after receiving the first PDCP sequence number.

[0242] Steps S601 and S602 in FIG. 6 are described in detail below using FIG. 7A to FIG. For ease of description, FIG. 7A to FIG. 7D depict the user plane of the second node as CU-UP1, the control plane of the second node as CU-CP1, the user plane of the third node as CU-UP2, the control plane of the third node as CU-CP2, and the first PDCP sequence number as PDCP SN1.

[0243] FIG7A is a schematic diagram of a second node obtaining a first PDCP sequence number according to an embodiment of the present application. The second node includes a first user plane CU-UP1 of the second node and a first control plane CU-CP1 of the second node, and the third node includes a second user plane CU-UP2 of the third node and a second control plane CU-CP2 of the third node;

[0244] In the embodiment shown in Figure 7A, step S601 can specifically be: the first user plane CU-UP1 sends the first PDCP sequence number to the first control plane CU-CP1; then, the first control plane CU-CP1 sends the first PDCP sequence number to the first node, and accordingly, the first node receives the first PDCP sequence number from the first control plane CU-CP1.

[0245] For example, CU-CP1 can send a request message to CU-UP1, requesting CU-UP1 to provide the PDCP SN1 of the current broadcast session. It can be understood that since CU-UP is responsible for data transmission on the user plane, CU-UP can obtain the PDCP SN number based on the number of the currently transmitted data packet. CU-CP is responsible for control plane transmission and does not know the PDCP SN number, so it needs to send a request message to CU-UP, requesting CU-UP to send the currently transmitted PDCP SN number to CU-CP. In turn, CU-CP1 sends a request message to the shared DU, which carries the PDCP SN1.

[0246] Step S602 may specifically be: the first node sends the first PDCP sequence number to the second control plane CU-CP2; the second control plane CU-CP2 sends the first PDCP sequence number to the second user plane CU-UP2, and the first PDCP sequence number is used by the second user plane CU-UP2 to configure the PDCP sequence number of the second data packet.

[0247] For example, the first node (such as Shared DU) can send a first request message to CU-CP2, and the first request message is used to request the establishment of an F1 tunnel; then based on the F1 tunnel, a second request message is sent to CU-CP2, and the second request message is used to request to change the configuration message of the PDCP SN, and the request message carries the above-mentioned PDCP SN1. It can be understood that since CU-UP2 is currently needed to send data to the shared DU, but there is no tunnel between the two, the shared DU needs to send a request message to CU-CP2, requesting the establishment of an F1 tunnel between the two. Furthermore, CU-CP2 can send a modification request message to CU-UP2, carrying PDCP SN1 at the same time. CU-UP2 modifies the PDCP sequence number (PDCPSN2) of the currently processed data packet to PDCP SN1, and sends the modified data packet to CU-CP2; CU-CP2 sends the modified data packet to the shared DU.

[0248] The communication method for the multicast broadcast service corresponding to FIG. 7A is described in detail below through S11 to S18 .

[0249] S11: Optionally, the shared DU may send a first request message to the CU-CP1, where the first request message is used to request the CU-CP1 to provide the PDCP SN number of the current broadcast session, which is recorded as the first PDCP SN.

[0250] S12: CU-CP1 sends a second request message to CU-UP1, where the second request message is used to request CU-UP1 to provide a first PDCP SN of the current broadcast session.

[0251] In one implementation, the CU-UP is responsible for PDCP packet transmission and therefore knows the PDCP SN of the currently transmitted packet. The CU-CP is only responsible for control plane transmission and is unaware of the PDCP SN of user plane packets. Therefore, the CU-CP needs to send a request to the CU-UP, requesting it to provide the PDCP SN of the currently transmitted broadcast session packet.

[0252] S13: CU-CP1 sends a first response message to the shared DU, carrying the first PDCP SN.

[0253] S14: The Shared DU sends a third request message to CU-CP2, carrying the first PDCP SN.

[0254] In one implementation, before using CU-UP2 to send data to the shared DU, a user plane tunnel needs to be established between CU-UP2 and the shared DU. It should be noted that whether a tunnel is established is not limited in the embodiment of the present application. For example, if there is no user plane tunnel between CU-UP2 and the shared DU, the Shared DU can send a request message to CU-CP2, and the request message is used to request the establishment of a tunnel and carry the above-mentioned first PDCP SN; if there is a user plane tunnel between CU-UP2 and the shared DU, the Shared DU can send a request message to CU-CP2, and the request message is used to carry the first PDCP SN.

[0255] S15: CU-CP2 sends a modification request message to CU-UP2, carrying the first PDCP SN.

[0256] In one implementation, if CU-UP2 is also sending a data packet of the same broadcast service to the DU, the PDCP SN of the current data packet is recorded as the second PDCP SN. Since the second PDCP SN may not be within the PDCP window for receiving the first PDCP SN, CU-CP2 needs to send a modification request message to CU-UP2 to modify the PDCP SN of the same broadcast service transmitted on CU-UP2.

[0257] S16: CU-UP2 modifies the current second PDCP SN according to the first PDCP SN and the PDCP window corresponding to the received first PDCP SN.

[0258] In one implementation, the PDCP window length corresponding to the first PDCP SN can be obtained from the SN length in the PDCP configuration. For example, if the PDCP SN length is 12 bits, the receiving window length is 2. 12-1 . CU-UP2 judges the second PDCP SN based on the first PDCP SN and the PDCP window corresponding to the first PDCP SN. If the second PDCP SN is within the above-mentioned PDCP receiving window, the second PDCP SN is not modified; if the second PDCP SN is outside the above-mentioned PDCP receiving window, the second PDCP SN is modified. The embodiment of the present application does not limit the method for modifying the PDCP SN, as long as the modified second PDCP SN is within the above-mentioned PDCP receiving window.

[0259] S17: CU-UP2 sends a response message of the modification request to CU-CP2. The response message is used to indicate that the modification of the second PDCP SN has been completed.

[0260] S18: CU-CP2 sends a response message corresponding to the third request message to the shared DU. The response message is used to indicate that the tunnel has been established or the data source has been switched to CU-UP2.

[0261] The embodiment of the present application modifies the second PDCP SN through interaction on the control plane, so that packet loss does not occur when the UE uses the same MRB to receive the same broadcast service. In addition, the reliability is improved through the interaction of control signaling.

[0262] FIG7B is a schematic diagram of another embodiment of the present application providing a second node obtaining a first PDCP sequence number. The second node includes a first user plane CU-UP1 of the second node, and the third node includes a second user plane CU-UP2 of the third node;

[0263] In the embodiment shown in FIG. 7B , step S601 may specifically be: the first user plane CU-UP1 sends the first PDCP sequence number to the first node, and accordingly, the first node receives the first PDCP sequence number from the first user plane CU-UP1.

[0264] For example, the first node (eg, shared DU) receives downlink data transmission of CU-UP1, ie, DL USER DATA, which includes PDCP SN1.

[0265] Step S602 may specifically be: the first node sends the first PDCP sequence number to the second user plane CU-UP2, and accordingly, the second user plane CU-UP2 receives the first PDCP sequence number from the first node, and the first PDCP sequence number is used by the second user plane CU-UP2 to configure the PDCP sequence number of the second data packet.

[0266] For example, the shared DU sends a request message to CU-UP2 to establish an F1-U tunnel between them. In one implementation, the shared DU needs to send a tunnel establishment request message to CU-UP2 to request the establishment of an F1-U tunnel between them, so that it can receive data from CU-UP2. The shared DU uses DL DATA DELIVERY STATUS (PDU Type 1) to notify CU-UP2 of PDCP SN1. CU-UP2 then modifies PDCP SN2 to PDCP SN1. CU-UP2 then uses DL USER DATA (PDU Type 0) to notify the shared DU of the modified PDCP SN1.

[0267] The communication method for the multicast broadcast service corresponding to FIG. 7B is described in detail below through S21 to S24 .

[0268] S21: The shared DU receives downlink data transmission from CU-UP1, i.e., DL USER DATA (PDU Type 0), wherein the header of the data packet (i.e., the first data packet) includes the first PDCP SN;

[0269] S22: Optionally, the shared DU sends a request message to CU-CP2 to request the establishment of an F1-U tunnel between the two.

[0270] In one implementation, if no data transmission tunnel exists between the shared DU and CU-UP2, the shared DU needs to send a tunnel establishment request message to CU-CP2, requesting to establish an F1-U tunnel between the shared DU and CU-UP2, so as to receive data sent by CU-UP2.

[0271] S23: The shared DU sends a DL DATA DELIVERY STATUS (PDU Type 1) to CU-UP2, with the first PDCP SN in its header.

[0272] In one implementation, DL DATA DELIVERY STATUS is feedback on DL USER DATA, that is, the shared DU feeds back the sending status of the data packet after receiving the data packet sent by CU-UP2. Therefore, whether there is already a user plane tunnel between the shared DU and CU-UP2 (CU-UP2 has been sending data to the shared DU), or there is no user plane tunnel between the shared DU and CU-UP2 (using the tunnel establishment process of S22), CU-UP2 will send DL USER DATA to the shared DU after the tunnel is established, which carries the second PDCP SN. When the shared DU receives the data packet sent by CU-UP2, it will send DL DATA DELIVERY STATUS to CU-UP2, which, in addition to carrying the second PDCP SN, should also carry the first PDCP SN to indicate the data packet number received by the current shared DU from CU-UP1.

[0273] S24: CU-UP2 modifies the current second PDCP SN according to the first PDCP SN and the PDCP window corresponding to the received first PDCP SN.

[0274] In one implementation, the PDCP window length corresponding to the first PDCP SN can be obtained from the SN length in the PDCP configuration. For example, if the PDCP SN length is 12 bits, the receiving window length is 2. 12-1. CU-UP2 judges the second PDCP SN based on the first PDCP SN and the PDCP window corresponding to the first PDCP SN. If the second PDCP SN is within the above-mentioned PDCP receiving window, the second PDCP SN is not modified; if the second PDCP SN is outside the above-mentioned PDCP receiving window, the second PDCP SN is modified. The embodiment of the present application does not limit the method for modifying the PDCP SN, as long as the modified second PDCP SN is within the above-mentioned PDCP receiving window.

[0275] The embodiment of the present application modifies the second PDCP SN by using user plane interaction, so that the UE does not experience packet loss when receiving the same broadcast service using the same MRB. Compared with the embodiment of Figure 7A, the embodiment of the present application can save user plane signaling overhead and is simpler to implement.

[0276] FIG7C is a schematic diagram of another embodiment of the present application providing a second node obtaining a first PDCP sequence number. The second node includes a first user plane CU-UP1 of the second node and a first control plane CU-CP1 of the second node, and the third node includes a second user plane CU-UP2 of the third node;

[0277] In the embodiment shown in Figure 7C, step S601 can specifically be: the first user plane CU-UP1 sends the first PDCP sequence number to the first control plane CU-CP1; then, the first control plane CU-CP1 sends the first PDCP sequence number to the first node, and accordingly, the first node receives the first PDCP sequence number from the first control plane CU-CP1.

[0278] Step S602 may specifically be: the first node sends the first PDCP sequence number to the second user plane CU-UP2, and accordingly, the second user plane CU-UP2 receives the first PDCP sequence number from the first node, and the first PDCP sequence number is used by the second user plane CU-UP2 to configure the PDCP sequence number of the second data packet.

[0279] FIG7D is a schematic diagram of a second node obtaining a first PDCP sequence number according to an embodiment of the present application. The second node includes a first user plane CU-UP1 of the second node, and the third node includes a second user plane CU-UP2 of the third node and a second control plane CU-CP2 of the third node;

[0280] In the embodiment shown in FIG. 7D , step S601 may specifically be: the first user plane CU-UP1 sends the first PDCP sequence number to the first node, and correspondingly, the first node receives the first PDCP sequence number from the first user plane CU-UP1.

[0281] Step S602 may specifically be: the first node sends the first PDCP sequence number to the second control plane CU-CP2; the second control plane CU-CP2 sends the first PDCP sequence number to the second user plane CU-UP2, and the first PDCP sequence number is used by the second user plane CU-UP2 to configure the PDCP sequence number of the second data packet.

[0282] It can be understood that the embodiments shown in FIG. 7C and FIG. 7D are embodiments in which the interaction modes of the control plane and the user plane are combined with each other. This method can save control plane signaling and ensure stability to a certain extent.

[0283] The following exemplarily describes the method of FIG. 6 in detail through the embodiment of FIG. 8 in combination with the scenario of FIG. 5B .

[0284] FIG8 is a flow chart of another communication method for a multicast broadcast service provided in an embodiment of the present application. The communication method for a multicast broadcast service may include the following steps:

[0285] Phase 1: The data server sends service data of the first service to the user equipment through the first core network, the second node, and the first node.

[0286] Step S1: The data server sends service data of a first service to a first core network.

[0287] Step S2: The first core network sends a first data packet of the first service to the second node; the first data packet is obtained based on service data of the first service.

[0288] The first core network and the second node may belong to the same operator.

[0289] In some embodiments, the second node configures the PDCP configuration of the broadcast MCCH, and then sends the configuration to the first node via a message (eg, BROADCAST CONTEXT SETUP REQUEST), where the message carries the PDCP configuration.

[0290] Step S3: The second node sends a first data packet to the first node, where the first data packet includes a sequence number configured by the second node; the PDCP sequence number of the first data packet is within a receiving window of the PDCP layer of the user equipment.

[0291] Step S4: The first node sends the first data packet to the user equipment.

[0292] In some embodiments, the first node currently adopts a session between the second node and the data server to obtain service data, and the MRB configuration for communicating with the user equipment adopts the PDCP configuration of the second node.

[0293] Phase 2: The first node sends the PDCP sequence number of the first data packet currently sent by the second node (ie, the first PDCP sequence number) to the third node.

[0294] Step S5: The second node sends a first PDCP sequence number to the first node, where the first PDCP sequence number is the PDCP sequence number of the first data packet currently sent by the second node.

[0295] Correspondingly, the first node receives the first PDCP sequence number from the second node.

[0296] Step S6: The first node sends the first PDCP sequence number to the third node. The first PDCP sequence number is used by the third node to configure the PDCP sequence number of the second data packet, and the PDCP sequence number of the second data packet is within the receiving window of the PDCP layer of the user equipment.

[0297] Correspondingly, the third node receives the first PDCP sequence number from the first node.

[0298] Phase 3: The data server sends service data of the first service to the user equipment through the second core network, the third node, and the first node.

[0299] Step S7: The data server sends the service data of the first service to the second core network.

[0300] Step S8: The second core network sends a second data packet of the first service to the third node; the second data packet is obtained based on the service data of the first service.

[0301] The second core network and the third node may belong to the same operator.

[0302] In some embodiments, the third node configures the PDCP configuration of the broadcast MCCH, and then sends the configuration to the first node via a message (such as BROADCAST CONTEXT SETUP REQUEST), where the message carries the PDCP configuration.

[0303] Step S9: The third node sends a second data packet to the first node, where the second data packet includes a sequence number configured by the third node; the PDCP sequence number of the second data packet is within the receiving window of the PDCP layer of the user equipment.

[0304] Step S10: The first node sends a second data packet to the UE.

[0305] Correspondingly, the UE receives the second data packet from the first node.

[0306] In some embodiments, the first node acquires service data through a session between a third node and a data server, and the MRB configuration for communicating with the user equipment may adopt the PDCP configuration of the third node.

[0307] In the embodiment of the present application, since the PDCP configurations of the first node and the second node are the same, the user equipment is unaware when the first node adopts the PDCP configuration of the second node and the PDCP configuration of the third node, and thus the user equipment does not modify the receiving window of its PDCP layer. In the embodiment of the present application, the PDCP sequence number of the first data packet currently sent by the second node is sent to the third node in the second phase, so that the third node can configure the PDCP sequence number of the second data packet within the receiving window of the PDCP layer of the user equipment. Then, even if the packet sending progress of the second node and the third node is different, when the first phase transitions to the second phase, since the PDCP sequence number of the second data packet is within the receiving window of the PDCP layer of the user equipment, the user equipment can successfully receive the second data packet in the third phase, and a large number of second data packets will not be discarded.

[0308] It should be noted that the above-mentioned process of the second node executing steps S1 to S3 and the process of the third node executing steps S7 to S9 can occur simultaneously. For example, the second node and the third node both send business data of the same business to the first node according to their own processing order; the business data sent by the first node to the user equipment can come from the second node or from the third node. For example, in the first stage, the first node uses the first data packet of the second node, and in the third stage, the second data packet of the second node is used.

[0309] Please refer to Figure 9A, which is a flow chart of another communication method for a multicast broadcast service provided in an embodiment of the present application. The functions performed by the user equipment in this embodiment can also be performed by a module (e.g., a chip) in the user equipment, and the functions performed by the network device in this application can also be performed by a module (e.g., a chip) in the network device.

[0310] In this embodiment of the present application, the first node may be the shared DU in Figure 5A or the shared gNB-DU in Figure 5B ; the second node may be the first CU in Figure 5A or the gNB-CU PLMNA in Figure 5B ; the third node may be the second CU in Figure 5A or the gNB-CU PLMNB in ​​Figure 5B ; and the user equipment may be the user equipment 502 in Figure 5A or the UE in Figure 5B . 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.

[0311] As shown in FIG9A , the communication method for the multicast broadcast service may include the following steps:

[0312] Step S901: a 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 by a second node to the first node.

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

[0314] Step S902: The first node sends a first message to the UE, where the first message includes parameter information configured by the second MRB.

[0315] In some embodiments, before the first node sends the first message to the UE, the first node receives a first request sent by the second node, where the first request includes a service identifier of the multicast broadcast service; the first request is used to request release of the multicast broadcast service session of the second node.

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

[0317] The parameter information configured by the second MRB may include at least one of a data convergence protocol sequence number size (PDCP SN Size), a robust header compression (Robust Header Compression, ROHC), and a reordering timer (t-Reordering).

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

[0319] Figure 9B illustrates an exemplary diagram of changing the PDCPSN size. TMGI 1 indicates the PDCP configuration corresponding to the second node's broadcast session, and TMGI 2 indicates the PDCP configuration corresponding to the third node's broadcast session. Prior to the first MCCH modification period, the PDCPSN sizes in the PDCP configurations of the second and third nodes are identical, both 12 bits. During the first MCCH modification period, the first node receives a first request from the second node. The first request includes parameter information for a second MRB configuration, including a new PDCP configuration, such as a PDCPSN size of null (null is 18 bits).

[0320] Furthermore, the first node may set the PDCP SN size to null 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 a new PDCP configuration, such as the PDCP SN size is null (null is 18 bits); then, the DU may broadcast the MRB configuration of the 18-bit PDCP SN size over the air interface (i.e., the above-mentioned first message). After the UE sees that the MRB configuration has changed, it may delete the original 12-bit MRB configuration and establish an 18-bit MRB configuration.

[0321] Figure 9B is an exemplary embodiment of the present application in which the parameter information that changes in the first MRB configuration and the second MRB configuration is the PDCPSN size. In other embodiments of the present application, the parameter information that changes in the first MRB configuration and the second MRB configuration may be at least one of PDCPSN size, ROHC, and t-Reordering.

[0322] Step S903: After sending the first message, the first node sends a second message to the UE, where the second message includes parameter information of the first MRB configuration; the first MRB configuration is different from the second MRB configuration.

[0323] Among them, there is at least one configuration parameter different between the parameter information of the first MRB configuration and the parameter information of the second MRB configuration, and the configuration parameter includes at least one of the data convergence protocol sequence number length (PDCP SN Size), robust header compression (Robust Header Compression, ROHC), and reordering timer (t-Reordering).

[0324] For example, the first node may modify the MRB configuration during the third MCCH modification period, i.e., modify the PDCP configuration to the original PDCP configuration. Specifically, the DU may broadcast the modified 12-bit MRB PDCP configuration (the second message described above) over the air interface. When the UE detects a change in the MRB configuration, it may delete the 18-bit MRB and then recreate the 12-bit MRB. This resolves the PDCP SN number hopping issue by deleting and recreating the MRB on the UE side.

[0325] Step S904: After sending the second message, the first node sends a second data packet to the user equipment based on the first MRB configuration. The second data packet is sent by the third node to the first node. The first data packet and the second data packet belong to the same multicast broadcast service.

[0326] In some embodiments, the first node may receive the first request and send the first message and the second message within three consecutive MCCH modification periods. For example, when the first node receives the first request within the first multicast control channel MCCH modification period, the first node sends the first message within the second MCCH modification period, which is the next MCCH modification period after the first MCCH modification period; and the first node sends the second message within the third MCCH modification period, which is the next MCCH modification period after the second MCCH modification period.

[0327] In some other embodiments of the present application, the time when the first node receives the first request and the time when the first node sends the first message and the second message may not be within three consecutive MCCH modification cycles, but the time when the first node sends the first message and the second message may be within two consecutive MCCH modification cycles. For example, when the time when the first node sends the first message is within the fourth MCCH modification cycle, the time when the first node sends the second message is within the fifth MCCH modification cycle, and the fifth MCCH modification cycle is the MCCH modification cycle next to the fourth MCCH modification cycle.

[0328] The key point in the embodiment of the present application is the interaction of the air interface, that is, the air interface signaling interaction between the base station and the UE. In the base station, the air interface signaling is sent by the DU, that is, the MCCH message is sent by the DU to the UE. When the MCCH message is updated (when the MRB configuration changes), the DU can send the updated MCCH message to the UE during the MCCH modification period. The embodiment of the present application deletes and rebuilds the MRB during the MCCH modification period through the above-mentioned first message and second message, so that the UE perceives that the MRB has changed and there is a new MRB reconstruction, which can solve the problem of packet loss when the first node switches from sending a first data packet to the UE to send a second data packet for the same MRB.

[0329] The communication method for the multicast broadcast service corresponding to FIG. 9A is described in detail below through S31 to S33.

[0330] S31: Optionally, in the first MCCH modification period, the DU receives a broadcast session release request message sent by the CU, requesting to release TMGI 1.

[0331] In one implementation, the DU receives the MRB configurations of CUs of multiple operators. The CUs of the multiple operators include CU1 and CU2. The broadcast session of CU1 is identified by TMGI1, and the broadcast session of CU2 is identified by TMGI2. Although TMGI1 and TMGI2 are different broadcast sessions, the content of the broadcast sessions is the same. The premise of this embodiment is that the MRB configurations of CU1 and CU2 have been coordinated to be the same, that is, the PDCPSN size, ROHC and t-Reordering configurations in the PDCP configuration are the same. The DU receives data packets from CU1 and CU2, but the DU chooses to use the data packet of CU1 and sends it to the UE over the air interface. In the first MCCH modification period and the time period before, the DU sends data packets to the UE based on the same configured MRB configuration, and the MRB here is recorded as the first MRB. Optionally, in the first MCCH modification period, the DU receives a broadcast session release request message from CU1, that is, the core network instructs the release of CU1's broadcast session TMGI1. At this time, CU2's broadcast session TMGI2 still exists on the DU.

[0332] S32: In the second MCCH modification period, the DU receives a message from CU2, which includes the configuration of the second MRB. The configuration of the second MRB is different from the configuration of the first MRB.

[0333] In one implementation, during the second MCCH modification period, the DU receives the configuration information of the second MRB sent by CU2, and the PDCP configuration of the second MRB is different from the PDCP configuration of the first MRB. Since the PDCP configuration mainly includes three items (i.e., PDCPSN size, ROHC, and t-Reordering), one or more of the PDCP configurations in the second MRB can be different from the PDCP configuration in the first MRB. For example, the PDCP SN length is changed from 12 bits of the first MRB PDCP SN to 18 bits of the second MRB PDCP SN. At this time, the DU will broadcast the MRB configuration of the 18-bit PDCP SN over the air interface. After the UE perceives that the MRB configuration has changed, it will delete the original 12-bit MRB configuration and establish a new MRB (with a PDCP SN length of 18 bits).

[0334] S32: In the third MCCH modification period, the DU receives a message from CU2, which includes the configuration of the first MRB.

[0335] In one implementation, during the third MCCH modification period, the DU receives an MRB PDCP configuration from CU2 that is identical to the PDCP configuration of the first MRB. The DU then broadcasts the modified 12-bit MRB PDCP configuration over the air interface. Upon detecting the MRB configuration change, the UE deletes the 18-bit MRB and recreates the 12-bit MRB. This UE-side MRB deletion and re-creation not only resolves the PDCP SN hopping issue but also allows the UE to successfully receive data packets.

[0336] In an embodiment of the present application, the configuration of the MRB is modified in different MCCH modification periods so that the UE can perceive that the MRB has changed. When the UE perceives that the MRB configuration has changed, the old MRB will be deleted and a new MRB will be established. When the UE uses the new MRB, it receives data packets according to the new PDCP SN and receiving window, thereby solving the problem of PDCP SN number hopping, that is, the UE can always receive data packets (there is no problem of not being able to receive data packets for a period of time). This method uses the DU to send an updated MRB configuration method over the air interface, completely reuses the existing process, does not require any modifications to the standard, and is relatively simple to implement.

[0337] The following exemplarily describes the method of FIG. 9A in detail through the embodiment of FIG. 10 in combination with the scenario of FIG. 5B .

[0338] FIG10 is a flow chart of another communication method for a multicast broadcast service provided in an embodiment of the present application. The communication method for a multicast broadcast service may include the following steps:

[0339] Phase 1: The data server sends service data of the first service to the user equipment through the first core network, the second node, and the first node.

[0340] Step S1: The data server sends service data of a first service to a first core network.

[0341] Step S2: The first core network sends a first data packet of the first service to the second node; the first data packet is obtained based on service data of the first service.

[0342] The first core network and the second node may belong to the same operator.

[0343] In some embodiments, the second node configures the PDCP configuration of the broadcast MCCH, and then sends the configuration to the first node via a message (eg, BROADCAST CONTEXT SETUP REQUEST), where the message carries the PDCP configuration.

[0344] Step S3: The second node sends a first data packet to the first node, where the first data packet includes a sequence number configured by the second node; the PDCP sequence number of the first data packet is within a receiving window of the PDCP layer of the user equipment.

[0345] Step S4: the first node sends the first data packet to the user equipment based on the first multicast data radio bearer (MRB) configuration.

[0346] In some embodiments, the first node currently adopts a session between the second node and the data server to obtain service data, and the MRB configuration for communicating with the user equipment adopts the PDCP configuration of the second node.

[0347] Phase 2: The first node broadcasts the first message and the second message to enable the user equipment to reestablish the MRB.

[0348] Step S5: The second node sends a first request to the first node, where the first request includes parameter information configured by the second MRB.

[0349] Correspondingly, the first node receives the first request from the second node.

[0350] The first request includes a service identifier of the multicast broadcast service; and the first request is used to request the release of the multicast broadcast service session of the second node.

[0351] Step S6: The first node sends a first message to the user equipment, where the first message includes parameter information configured by the second MRB.

[0352] Correspondingly, the user equipment receives the first message from the first node.

[0353] Step S7: the third node sends a second request to the first node, where the second request includes parameter information of the first MRB configuration; the first MRB configuration is different from the second MRB configuration.

[0354] Correspondingly, the first node receives the second request from the third node.

[0355] It should be noted that the second request may be sent by the third node to the first node during the first phase. For example, during S1 described above, the core network also sends the service data of the first service to the second core network, and the second core network sends the data packet of the first service to the third node. Before the third node sends the data packet to the first node, it may send the second request to the first node. This embodiment does not limit the order in which the first and second core networks process the service data, nor does it limit the order in which the second and third nodes process the data packets of the same service.

[0356] Step S8: After sending the first message, the first node sends a second message to the user equipment, where the second message includes parameter information configured by the first MRB.

[0357] Correspondingly, the user equipment receives the second message from the first node.

[0358] Phase 3: The data server sends service data of the first service to the user equipment through the second core network, the third node, and the first node.

[0359] Step S9: The data server sends the service data of the first service to the second core network.

[0360] Step S10: The second core network sends a second data packet of the first service to the third node; the second data packet is obtained based on the service data of the first service.

[0361] The second core network and the third node may belong to the same operator.

[0362] In some embodiments, the third node configures the PDCP configuration of the broadcast MCCH, and then sends the configuration to the first node via a message (such as BROADCAST CONTEXT SETUP REQUEST), where the message carries the PDCP configuration.

[0363] Step S11: the third node sends the second data packet to the first node.

[0364] Step S12: The first node configures a first multicast data radio bearer (MRB) to send a second data packet to the UE.

[0365] Correspondingly, the UE receives the second data packet from the first node.

[0366] It should be noted that the above-mentioned process of the second node executing steps S1 to S3 and the process of the third node executing steps S7 to S9 can occur simultaneously. For example, the second node and the third node both send business data of the same business to the first node according to their own processing order; the business data sent by the first node to the user equipment can come from the second node or from the third node. For example, in the first stage, the first node uses the first data packet of the second node, and in the third stage, the second data packet of the second node is used.

[0367] The present application also provides a communication method for a multicast broadcast service. The functions performed by the user equipment in the embodiments of the present application can also be performed by a module (e.g., a chip) in the user equipment, and the functions performed by the network device in the present application can also be performed by a module (e.g., a chip) in the network device.

[0368] In this embodiment of the present application, the DU may be the aforementioned first node, which may be the shared DU in Figure 5A or the Shared gNB-DU in Figure 5B ; CU1 may be the aforementioned second node, which may be the first CU in Figure 5A or the gNB-CU PLMNA in Figure 5B ; CU2 may be the aforementioned third node, which may be the second CU in Figure 5A or the gNB-CU PLMNB in ​​Figure 5B ; and the UE may be the aforementioned user equipment, which may be the user equipment 502 in Figure 5A or the UE in Figure 5B . 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.

[0369] The communication method for the multicast broadcast service may include some or all of the following steps:

[0370] S101: DU receives a broadcast session release request message sent by CU1, which is used to request the release of TMGI 1.

[0371] It should be noted that S101 is an optional step. S101 is an exemplary implementation of the embodiment of the present application for triggering the DU to execute the following step S102. In other embodiments of the present application, S102 may also be actively triggered by the DU or requested to be executed by other devices. The embodiment of the present application does not limit this.

[0372] In one implementation, the DU can receive MRB configurations of CUs of multiple operators, and the MRB configurations of CUs of multiple operators can be coordinated into the same configuration; the DU can receive data packets of the same multicast broadcast service sent by CUs of multiple operators; the DU can choose to use the data packet of one of the CUs and send the data packet from the CU to the UE based on the same configured MRB configuration.

[0373] For example, the CUs of multiple operators including CU1 and CU2 are used as an example for explanation. The broadcast session of CU1 is identified by TMGI1, and the broadcast session of CU2 is identified by TMGI2. Although TMGI1 and TMGI2 are different broadcast sessions, the content of the broadcast sessions is the same. For example, the broadcast session of CU1 and the broadcast session of CU2 are both used to transmit service data of the same multicast broadcast service. Among them, the MRB configurations of CU1 and CU2 have been coordinated into the same configuration, such as the PDCP SN Size, ROHC, and t-Reordering configurations in the PDCP configuration are the same. The DU can receive data packets sent by CU1 and CU2. It is assumed that the DU chooses to use the data packet of CU1 and sends it to the UE over the air interface. During the first MCCH modification period and the previous time period, the DU sends data packets to the UE based on the same configured MRB configuration. The MRB here is recorded as the first MRB.

[0374] Optionally, in the first MCCH modification period, the DU may receive a broadcast session release request message from CU1, that is, the core network instructs the release of CU1's broadcast session TMGI1. At this time, CU2's broadcast session TMGI2 still exists on the DU.

[0375] S102: When the DU decides to use the broadcast service data from CU2, the DU may send an MCCH message over the air interface. The MCCH message carries indication information, where the indication information is used to indicate that the source of the broadcast service data has been changed to CU2.

[0376] In some embodiments, the DU may decide to use the broadcast service data from CU2 after receiving the above-mentioned broadcast session release request message sent by CU1; further, the DU may send an MCCH message over the air interface, which carries indication information, and the indication information is used to indicate that the source of the broadcast service data has been changed to CU2.

[0377] In one implementation, assuming that the DU decides to use the broadcast service data from CU2, the DU may carry indication information in the MCCH message sent over the air interface, where the indication information is used to indicate that the source of the broadcast service data has been changed to CU2.

[0378] For example, in a display indication method, the explicit indication may be carrying 1-bit information, and the 1-bit information may be 1 or 0, where 1 indicates a change and 0 indicates no change. Then, the UE can determine that the data source of the broadcast service has changed through the above indication information. Even if the configuration of the MRB in the MCCH has not changed, the UE will re-establish the MRB, that is, the second MRB (the second MRB configuration is the same as the first MRB configuration); after re-establishing the second MRB, the data of CU2 is received, so that the PDCP SN number can be continuously received to avoid jumping. It should be noted that this indication method is an illustrative indication method provided in an embodiment of the present application. In other embodiments of the present application, the DU may also send indication information to the UE through some implicit indication methods, and the embodiments of the present application are not limited to this.

[0379] In an embodiment of the present application, by adding indication information to the MCCH message sent over the air interface by the DU, the UE can quickly reestablish the MRB. The indication information is used to indicate that the data source of the multicast broadcast service has changed, for example, switching from a CU (such as CU1 described above) of operator A (PLMN A) to a CU (such as CU2 described above) of operator B (PLMN B).

[0380] Please refer to Figure 11, which is a schematic diagram of the structure of a communication device for a multicast broadcast service provided in an embodiment of the present application. The communication device can be a network device or a module (e.g., a chip) in the network device. As shown in Figure 11, the communication device 110 includes at least: a receiving unit 1101 and a sending unit 1102; wherein:

[0381] The receiving unit 1101 is configured to receive a first data convergence protocol PDCP sequence number from a second node, where the first PDCP sequence number is a PDCP sequence number of a first data packet sent by the second node at a first moment;

[0382] The sending unit 1102 is configured to send the first PDCP sequence number to a third node;

[0383] The receiving unit 1101 is configured to receive a second data packet from a third node, where a PDCP sequence number of the second data packet is within a receiving window of a PDCP layer of a user equipment UE;

[0384] The sending unit 1102 is configured to send a second data packet to the UE, where the first data packet and the second data packet are associated with a first multicast broadcast service.

[0385] As a possible implementation manner, the second node includes a first user plane of the second node and a first control plane of the second node; the receiving unit 1101 is specifically configured to:

[0386] A first PDCP sequence number is received from a first control plane; the first PDCP sequence number is obtained by the first control plane from a first user plane.

[0387] As a possible implementation manner, the third node includes a second user plane of the third node and a second control plane of the third node; the sending unit 1102 is specifically configured to:

[0388] The first PDCP sequence number is sent to the second control plane; the second control plane is used to send the first PDCP sequence number to the second user plane; the first PDCP sequence number is used by the second user plane to configure the PDCP sequence number of the second data packet.

[0389] As a possible implementation manner, the third node includes a second user plane of the third node; the sending unit 1102 is specifically configured to:

[0390] The first PDCP sequence number is sent to the second user plane; the first PDCP sequence number is used by the second user plane to configure the PDCP sequence number of the second data packet.

[0391] As a possible implementation manner, the second node includes a first user plane of the second node; and the receiving unit 1101 is specifically configured to:

[0392] A first PDCP sequence number is received from a first user plane.

[0393] As a possible implementation manner, the third node includes a second user plane of the third node; the sending unit 1102 is specifically configured to:

[0394] The first PDCP sequence number is sent to the second user plane; the first PDCP sequence number is used by the second user plane to configure the PDCP sequence number of the second data packet.

[0395] As a possible implementation manner, the third node includes a second user plane of the third node and a second control plane of the third node; the sending unit 1102 is specifically configured to:

[0396] The first PDCP sequence number is sent to the second control plane; the second control plane is used to send the first PDCP sequence number to the second user plane; the first PDCP sequence number is used by the second user plane to configure the PDCP sequence number of the second data packet.

[0397] As a possible implementation manner, before sending the second data packet to the user equipment UE, the receiving unit 1101 is further configured to:

[0398] A first message is received from a third node, where the first message is used to instruct to use a data packet from the third node, and the first message is sent by the third node after receiving a first PDCP sequence number.

[0399] As a possible implementation manner, before receiving the first Data Convergence Protocol (PDCP) sequence number from the second node, the sending unit 1102 is further configured to:

[0400] A first request is sent to the second node, where the first request is used to request a first PDCP sequence number.

[0401] As a possible implementation manner, before receiving the first Data Convergence Protocol (PDCP) sequence number from the second node, the receiving unit 1101 is further configured to:

[0402] A first data packet is received from the second node, where a first PDCP sequence number of the first data packet is within a receiving window of a PDCP layer of the UE.

[0403] For a more detailed description of the receiving unit 1101 and the sending unit 1102 , reference may be made to the relevant description of the first node in the method embodiments shown in FIG. 6 and FIG. 8 , which will not be repeated here.

[0404] Please refer to Figure 12, which is a schematic diagram of the structure of another communication device for multicast broadcast services provided in an embodiment of the present application. The communication device can be a network device or a module (e.g., a chip) in the network device. As shown in Figure 12, the communication device 120 includes at least: a receiving unit 1201 and a sending unit 1202; wherein:

[0405] The receiving unit 1201 is configured to receive a first Packet Data Convergence Protocol (PDCP) sequence number from a first node, where the first PDCP sequence number is a PDCP sequence number of a first data packet sent by a second node at a first moment;

[0406] The sending unit 1202 is configured to send a second data packet to the first node, where the PDCP sequence number of the second data packet is within the receiving window of the PDCP layer of the user equipment UE; the first data packet and the second data packet are associated with the first multicast broadcast service.

[0407] As a possible implementation manner, before sending the second data packet to the first node, the sending unit 1202 is further configured to:

[0408] A first message is sent to the first node, where the first message is used to instruct the first node to use a data packet from the communication device.

[0409] As a possible implementation manner, before sending the second data packet to the first node, the apparatus further includes a configuration unit 1203, where the configuration unit 1203 is configured to:

[0410] Based on the first PDCP sequence number, a PDCP sequence number of the second data packet is configured.

[0411] For a more detailed description of the receiving unit 1201, the sending unit 1202 and the configuring unit 1203, reference may be made to the relevant description of the third node in the method embodiments shown in FIG6 and FIG8, which will not be repeated here.

[0412] Please refer to Figure 13, which is a schematic diagram of the structure of another communication device for multicast broadcast services provided by an embodiment of the present application. The communication device can be a network device or a module (e.g., a chip) in the network device. As shown in Figure 13, the communication device 130 includes at least: a sending unit 1301; wherein:

[0413] The sending unit 1301 is configured to send a first Data Convergence Protocol (PDCP) sequence number to a first node, where the first PDCP sequence number is the PDCP sequence number of a first data packet sent by the sending unit at a first moment.

[0414] As a possible implementation manner, the apparatus further includes a receiving unit 1302, and the receiving unit 1302 is configured to:

[0415] A first request is received from a first node, where the first request is used to request a first PDCP sequence number.

[0416] For a more detailed description of the receiving unit 1302 and the sending unit 1301, reference may be made to the relevant description of the second node in the method embodiments shown in FIG6 and FIG8, which will not be repeated here.

[0417] Please refer to Figure 14, which is a schematic diagram of the structure of another communication device for multicast broadcast services provided in an embodiment of the present application. The communication device can be a network device or a module (e.g., a chip) in the network device. As shown in Figure 14, the communication device 140 includes at least: a sending unit 1401; wherein:

[0418] The sending unit 1401 is 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 by a second node to a communication device;

[0419] The sending unit 1401 is configured to send a first message to the UE, where the first message includes parameter information of a second MRB configuration; the first MRB configuration is different from the second MRB configuration;

[0420] The sending unit 1401 is configured to send a second message to the UE after sending the first message, where the second message includes parameter information configured by the first MRB;

[0421] The sending unit 1401 is configured to send a second data packet to the UE based on the first MRB configuration after sending the second message, where the second data packet is sent by the third node to the communication device; the first data packet and the second data packet are associated with the first multicast broadcast service.

[0422] As a possible implementation manner, before sending the first message to the UE, the apparatus further includes a receiving unit 1402, where the receiving unit 1402 is configured to:

[0423] A first request sent by a second node is received, where the first request includes a service identifier of a multicast broadcast service; the first request is used to request to release a session of the multicast broadcast service of the second node.

[0424] As a possible implementation manner, 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 NID.

[0425] As a possible implementation, at least one configuration parameter in the parameter information of the first MRB configuration is different from that in the parameter information of the second MRB configuration, and the configuration parameter includes at least one of a data convergence protocol sequence number length, robust header compression, and a reordering timer.

[0426] As a possible implementation manner, when the communication device receives the first request within a first multicast control channel MCCH modification period, the communication device sends the first message within a second MCCH modification period, and the second MCCH modification period is the next MCCH modification period of the first MCCH modification period;

[0427] The moment when the communication device sends the second message is within a third MCCH modification period, and the third MCCH modification period is the next MCCH modification period of the second MCCH modification period.

[0428] As a possible implementation, when the communication device sends the first message within the fourth MCCH modification period, the communication device sends the second message within the fifth MCCH modification period, and the fifth MCCH modification period is the next MCCH modification period of the fourth MCCH modification period.

[0429] For a more detailed description of the sending unit 1401 and the receiving unit 1402, reference may be made to the relevant description of the second node in the method embodiment shown in FIG9A , which will not be repeated here.

[0430] Based on the above network architecture, please refer to Figure 15, which is a structural diagram of another communication device for multicast broadcast services disclosed in an embodiment of the present application. As shown in Figure 15, the communication device for multicast broadcast services may include a processor 1501, a memory 1502, a transceiver 1503 and a bus 1504. The memory 1502 may exist independently and may be connected to the processor 1501 via the bus 1504. The memory 1502 may also be integrated with the processor 1501. The bus 1504 is used to implement connections between these components. In one case, as shown in Figure 15, the transceiver 1503 may include a transmitter 15031, a receiver 15032 and an antenna 15033. In another case, the transceiver 1503 may include a transmitter (i.e., an output interface) and a receiver (i.e., an input interface). The transmitter may include a transmitter and an antenna, and the receiver may include a receiver and an antenna.

[0431] The communication device for the multicast broadcast service can be a user equipment (UE) or a module within the UE. When the computer program instructions stored in the memory 1502 are executed, the processor 1501 can be configured to execute the above-described embodiments, and the transceiver 1503 can be configured to execute the operations performed by the receiving unit 1101 and the transmitting unit 1102, or the transmitting unit 1202 and the receiving unit 1201, in the above-described embodiments. The communication device for the multicast broadcast service can also be configured to execute the various methods performed by the UE in the method embodiments of Figures 4-6, which will not be further described.

[0432] The communication device for the multicast broadcast service can be a network device or a module within the network device. When the computer program instructions stored in the memory 1502 are executed, the processor 1501 can be used to perform the above-described embodiments, and the transceiver 1503 can be used to perform the operations performed by the receiving unit 1101 and the sending unit 1102, the receiving unit 1201 and the sending unit 1202, the receiving unit 1302 and the sending unit 1301, or the sending unit 1401 and the receiving unit 1402 in the above-described embodiments. The communication device for the multicast broadcast service can also be used to perform the various methods performed by the network device in the method embodiments of Figures 4-10 above, which will not be described in detail.

[0433] Based on the above network architecture, please refer to Figure 16, which is a structural diagram of another communication device for multicast broadcast services disclosed in an embodiment of the present application. As shown in Figure 16, the communication device for the multicast broadcast service may include an input interface 1601, a logic circuit 1602 and an output interface 1603. The input interface 1601 is connected to the output interface 1603 through the logic circuit 1602. Among them, the input interface 1601 is used to receive information from other communication devices for multicast broadcast services, and the output interface 1603 is used to output, schedule or send information to other communication devices for multicast broadcast services. The logic circuit 1602 is used to perform operations other than the operations of the input interface 1601 and the output interface 1603, such as implementing the functions implemented by the processor 1501 in the above embodiment. Among them, the communication device for the multicast broadcast service can be a user device (or a module within a user device) or a network device (or a module within a network device). Among them, a more detailed description of the input interface 1601, the logic circuit 1602 and the output interface 1603 can be directly obtained by referring to the relevant description of the user equipment and the network equipment in the above method embodiment, and is not repeated here.

[0434] An embodiment of the present application further discloses a computer-readable storage medium having instructions stored thereon, which, when executed, execute the method in the above method embodiment.

[0435] The embodiments of the present application further disclose a computer program product comprising instructions, which, when executed, perform the method in the above method embodiments.

[0436] An embodiment of the present application further discloses a communication system, which may include a network device and a user device. For a specific description, reference may be made to the communication method for a multicast broadcast service shown in FIG. 4 to FIG. 6 .

[0437] The specific implementation methods described above further illustrate the purpose, technical solutions and beneficial effects of this application. It should be understood that the above description is only the specific implementation methods of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of this application should be included in the scope of protection of this application.

Claims

1. A communication method for a multicast broadcast service, characterized in that: include: The first node receives a first data convergence protocol PDCP sequence number from the second node, where the first PDCP sequence number is the PDCP sequence number of a first data packet sent by the second node at a first moment; The first node sends the first PDCP sequence number to a third node; The first node receives a second data packet from the third node, where a PDCP sequence number of the second data packet belongs to a receiving window of a PDCP layer of a user equipment UE; The first node sends the second data packet to the UE, and the first data packet and the second data packet are associated with a first multicast broadcast service.

2. The method according to claim 1, characterized in that The second node includes a first user plane of the second node and a first control plane of the second node; The first node receiving a first data convergence protocol PDCP sequence number from the second node includes: The first node receives the first PDCP sequence number from the first control plane; The first PDCP sequence number is obtained by the first control plane from the first user plane.

3. The method according to claim 2, characterized in that The third node includes a second user plane of the third node and a second control plane of the third node; The first node sending the first PDCP sequence number to a third node includes: The first node sends the first PDCP sequence number to the second control plane; the second control plane is used to send the first PDCP sequence number to the second user plane; the first PDCP sequence number is used by the second user plane to configure the PDCP sequence number of the second data packet.

4. The method according to claim 2, characterized in that: The third node includes a second user plane of the third node; and the first node sends the first PDCP sequence number to the third node, including: The first node sends the first PDCP sequence number to the second user plane; the first PDCP sequence number is used by the second user plane to configure the PDCP sequence number of the second data packet.

5. The method according to claim 1, characterized in that The second node includes a first user plane of the second node; the first node receives a first data convergence protocol PDCP sequence number from the second node, including: The first node receives the first PDCP sequence number from the first user plane.

6. The method according to claim 5, characterized in that The third node includes a second user plane of the third node; and the first node sends the first PDCP sequence number to the third node, including: The first node sends the first PDCP sequence number to the second user plane; the first PDCP sequence number is used by the second user plane to configure the PDCP sequence number of the second data packet.

7. The method according to claim 5, characterized in that The third node includes a second user plane of the third node and a second control plane of the third node; The first node sending the first PDCP sequence number to a third node includes: The first node sends the first PDCP sequence number to the second control plane; the second control plane is used to send the first PDCP sequence number to the second user plane; the first PDCP sequence number is used by the second user plane to configure the PDCP sequence number of the second data packet.

8. The method according to any one of claims 1 to 7, characterized in that: Before the first node sends the second data packet to the user equipment UE, the method includes: The first node receives a first message from the third node, where the first message is used to instruct the first node to use the data packet from the third node, and the first message is sent by the third node to the first node after receiving the first PDCP sequence number.

9. The method according to any one of claims 1 to 4, characterized in that: Before the first node receives the first data convergence protocol PDCP sequence number from the second node, the method further includes: The first node sends a first request to the second node, where the first request is used to request the first PDCP sequence number.

10. The method according to any one of claims 1 to 9, characterized in that: Before the first node receives the first data convergence protocol PDCP sequence number from the second node, the method further includes: The first node receives a first data packet from the second node, and a first PDCP sequence number of the first data packet belongs to a receiving window of a PDCP layer of the UE.

11. A communication method for a multicast broadcast service, characterized in that: include: The third node receives a first packet data convergence protocol PDCP sequence number from the first node, where the first PDCP sequence number is the PDCP sequence number of a first data packet sent by the second node at a first moment; The third node sends a second data packet to the first node, and the PDCP sequence number of the second data packet belongs to the receiving window of the PDCP layer of the user equipment UE; the first data packet and the second data packet are associated with a first multicast broadcast service.

12. The method according to claim 11, characterized in that Before the third node sends the second data packet to the first node, the method further includes: The third node sends a first message to the first node, where the first message is used to instruct the first node to use a data packet from the third node.

13. The method according to claim 11 or 12, characterized in that: Before the third node sends the second data packet to the first node, the method further includes: The third node configures the PDCP sequence number of the second data packet based on the first PDCP sequence number.

14. A communication method for a multicast broadcast service, characterized in that: include: The second node sends a first data convergence protocol PDCP sequence number to the first node, where the first PDCP sequence number is the PDCP sequence number of a first data packet sent by the second node at a first moment.

15. The method according to claim 14, characterized in that The method further comprises: The second node receives a first request from the first node, where the first request is used to request the first PDCP sequence number.

16. A communication method for a multicast broadcast service, characterized in that: The method comprises: 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 by the second node to the first node; The first node sends a first message to the UE, where the first message includes parameter information of a second MRB configuration; the first MRB configuration is different from the second MRB configuration; After sending the first message, the first node sends a second message to the UE, where the second message includes parameter information configured by the first MRB; After sending the second message, the first node sends a second data packet to the UE based on the first MRB configuration, where the second data packet is sent from a third node to the first node; the first data packet and the second data packet are associated with a first multicast broadcast service.

17. The method according to claim 16, characterized in that Before the first node sends the first message to the UE, the method further includes: The first node receives a first request sent by the second node, where the first request includes a service identifier of the multicast broadcast service; and the first request is used to request to release a session of the multicast broadcast service of the second node.

18. The method according to claim 17, characterized in that 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 NID.

19. The method according to claims 16 to 18, characterized in that There is at least one configuration parameter different between the parameter information of the first MRB configuration and the parameter information of the second MRB configuration, and the configuration parameter includes at least one of a data convergence protocol sequence number length, robust header compression, and a reordering timer.

20. The method according to claims 16 to 19, characterized in that When the moment when the first node receives the first request is within a first multicast control channel MCCH modification period, the moment when the first node sends the first message is within a second MCCH modification period, and the second MCCH modification period is a next MCCH modification period of the first MCCH modification period; The moment when the first node sends the second message is within a third MCCH modification period, and the third MCCH modification period is the next MCCH modification period of the second MCCH modification period.

21. The method according to claims 16 to 19, characterized in that When the moment when the first node sends the first message is within the fourth MCCH modification period, the moment when the first node sends the second message is within the fifth MCCH modification period, and the fifth MCCH modification period is the next MCCH modification period of the fourth MCCH modification period.

22. A communication device for multicast broadcast service, characterized in that: Comprising modules or units for executing the method according to any one of claims 1 to 21.

23. A communication device for multicast broadcast service, characterized in that: The method comprises a processor and a memory, wherein the processor and the memory are coupled, and the processor calls a computer program stored in the memory to implement the method according to any one of claims 1 to 21.

24. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program or a computer instruction. When the computer program or the computer instruction is executed by a processor, the method according to any one of claims 1 to 21 is implemented.

25. A computer program product, characterized in that The computer program product comprises a computer program code, and when the computer program code is executed by a processor, the method according to any one of claims 1 to 21 is implemented.

Images