Patent Description:
A multimedia broadcast multicast service (multimedia broadcast multicast service, MBMS) is a service oriented to a plurality of user equipments (user equipments, UEs), for example, live streaming and scheduled program playback.

To support sending of the MBMS in a broadcast form, a current long term evolution (long term evolution, LTE) system supports a multicast/multicast single frequency network (multicast broadcast single frequency network, MBSFN) transmission method. In the method, a multicast/broadcast service center (multicast broadcast service center, BM-SC) sends an MBMS data packet to UE via an MBMS gateway and an eNB. When the BM-SC sends an MBMS data packet to each eNB, a time stamp is added to each data packet, where the time stamp may indicate a time point at which the eNB sends the data packet, so that different eNBs can send the same MBMS data packet at the same time point.

However, in a centralized unit-distributed unit (Centralized unit-Distributed unit, CU-DU) architecture of a new radio (New Radio, NR) system, there is no related solution for how to process and send an MBMS data packet.

<CIT> discloses that a communication apparatus is used as a first communication apparatus in a radio communication system including the first communication apparatus and a second communication apparatus, comprising a communication unit configured to receive a retransmitted packet addressed to a user equipment from the second communication apparatus, and to transmit the retransmitted packet to the user equipment, the communication unit transmitting delivery status information including a sequence number of the retransmitted packet to the second communication apparatus.

Preferable embodiments are defined by the dependent claims.

The technical solutions in embodiments of this application may be applied to various communication systems, for example, a long term evolution (long term evolution, LTE) system, a worldwide interoperability for microwave access (worldwide interoperability for microwave access, WiMAX) communication system, a future 5th generation (5th Generation, <NUM>) system such as a new radio access technology (new radio access technology, NR), and a future communication system such as a <NUM> system.

All aspects, embodiments, or features are presented in this application by describing a system that may include a plurality of devices, components, modules, and the like. It should be appreciated and understood that, each system may include another device, component, module, and the like, and/or may not include all devices, components, modules, and the like discussed with reference to the accompanying drawings. In addition, a combination of these solutions may be used.

In addition, the word "for example" in embodiments of this application is used to represent giving an example, an illustration, or a description. Any embodiment or design scheme described as an "example" in this application should not be explained as being more preferred or having more advantages than another embodiment or design scheme. Exactly, the word "example" is used to present a concept in a specific manner.

In embodiments of this application, information (information), a signal (signal), a message (message), or a channel (channel) may be interchangeably used sometimes. It should be noted that expressed meanings are consistent when differences are not emphasized. "Of (of)", "corresponding (corresponding, relevant)", and "corresponding (corresponding)" may be interchangeably used sometimes. It should be noted that expressed meanings are consistent when differences are not emphasized.

A network architecture and a service scenario that are described in embodiments of this application are intended to describe the technical solutions in embodiments of this application more clearly, and do not constitute a limitation on the technical solutions provided in embodiments of this application. A person of ordinary skill in the art may know that, with evolution of the network architecture and emergence of new service scenarios, the technical solutions provided in embodiments of this application are also applicable to similar technical problems.

Embodiments of this application may be applied to a conventional typical network or a future UE-centric (UE-centric) network. A non-cell (Non-cell) network architecture is introduced to the UE-centric network. To be specific, a large quantity of small cells are deployed in a specific area to form a hyper cell (Hyper cell). Each small cell is a transmission point (Transmission Point, TP) or a transmission reception point (Transmission Reception Point, TRP) of the hyper cell, and is connected to a centralized controller (controller). When UE moves in the hyper cell, a network side device selects a new sub-cluster (sub-cluster) for the UE in real time to serve the UE, to avoid a real cell handover, and implement UE service continuity. The network side device includes a wireless network device. Alternatively, in the UE-centric network, a plurality of network side devices such as small cells may have independent controllers such as distributed controllers. Each small cell can independently schedule a user, and information is exchanged between small cells for a long time, so that the small cell can provide a coordinated service for the UE flexibly to some extent.

In embodiments of this application, different base stations may be base stations having different identifiers, or may be base stations that have a same identifier and that are deployed at different geographical locations. Before being deployed, a base station does not know whether the base station is related to a scenario to which embodiments of this application are applied. Therefore, before being deployed, the base station or a baseband chip needs to support a method provided in embodiments of this application. It may be understood that the foregoing base stations having different identifiers may have base station identifications, cell identifiers, or other identifiers.

In embodiments of this application, an NR network scenario in a wireless communication network is used as an example to describe some scenarios. It should be noted that the solutions in embodiments of this application may be further applied to another wireless communication network, and a corresponding name may also be replaced with a name of a corresponding function in the another wireless communication network.

For ease of understanding embodiments of this application, a communication system shown in <FIG> is first used as an example to describe in detail a communication system applicable to embodiments of this application. <FIG> is a schematic diagram of a communication system applicable to a communication method according to an embodiment of this application. As shown in <FIG>, the communication system <NUM> includes a network device <NUM> and a terminal device <NUM>. A plurality of antennas may be configured for the network device <NUM>, and a plurality of antennas may also be configured for the terminal device. Optionally, the communication system may further include a network device <NUM>, and a plurality of antennas may also be configured for the network device <NUM>.

It should be understood that the network device <NUM> or the network device <NUM> may further include a plurality of components (for example, a processor, a modulator, a multiplexer, a demodulator, or a de-multiplexer) related to signal sending and receiving.

The network device is a device having a wireless transceiver function or a chip that may be disposed in the device. The device includes but is not limited to: an evolved NodeB (evolved NodeB, eNB), a radio network controller (radio network controller, RNC), a NodeB (NodeB, NB), a base station controller (base station controller, BSC), a base transceiver station (base transceiver station, BTS), a home NodeB (for example, a home evolved NodeB, or a home NodeB, HNB), a baseband unit (baseband unit, BBU), or an access point (access point, AP), a wireless relay node, a wireless backhaul node, a transmission point (transmission reception point, TRP or transmission point, TP), or the like in a wireless fidelity (wireless fidelity, Wi-Fi) system. Alternatively, the network device may be a gNB or a transmission point (TRP or TP) in a <NUM> system, such as an NR system, or one antenna panel or a group of antenna panels (including a plurality of antenna panels) of a base station in the <NUM> system, or may be a network node that constitutes a gNB or a transmission point, for example, a baseband unit (BBU), or a distributed unit (DU, distributed unit).

As shown in <FIG>, in some deployments, the gNB may include a centralized unit (centralized unit, CU) <NUM> and a DU <NUM>. The gNB may further include a radio unit (radio unit, RU). The CU implements a part of functions of the gNB, and the DU implements a part of functions of the gNB. For example, the CU implements functions of a radio resource control (radio resource control, RRC) layer and a packet data convergence protocol (packet data convergence protocol, PDCP) layer, and the DU implements functions of a radio link control (radio link control, RLC) layer, a media access control (media access control, MAC) layer, and a physical (physical, PHY) layer. Information at the RRC layer eventually becomes information at the PHY layer, or is converted from information at the PHY layer. Therefore, in this architecture, it may also be considered that higher layer signaling, such as RRC layer signaling or PDCP layer signaling, may be sent by the DU or sent by the DU and the CU. It can be understood that the network device may be a CU node, a DU node, or a device including a CU node and a DU node. In addition, the CU may be classified as a network device in a radio access network RAN, or the CU may be classified as a network device in a core network CN. This is not limited herein.

The terminal device may also be referred to as user equipment (user equipment, UE), 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 apparatus. The terminal device in embodiments of this application may be a mobile phone (mobile phone), a tablet (Pad), a computer having a wireless transceiver function, a virtual reality (virtual reality, VR) terminal device, an augmented reality (augmented reality, AR) terminal device, a wireless terminal in industrial control (industrial control), a wireless terminal in self-driving (self-driving), a wireless terminal in telemedicine (remote medical), a wireless terminal in a smart grid (smart grid), a wireless terminal in transportation safety (transportation safety), a wireless terminal in a smart city (smart city), a wireless terminal in a smart home (smart home), or the like. An application scenario is not limited in embodiments of this application. The terminal device having a wireless transceiver function and a chip that may be disposed in the terminal device are collectively referred to as a terminal device in this application.

In the communication system <NUM>, the network device <NUM> and the network device <NUM> each may communicate with a plurality of terminal devices (for example, the terminal device <NUM> shown in the figure). The network device <NUM> and the network device <NUM> may communicate with one or more terminal devices similar to the terminal device <NUM>. However, it should be understood that a terminal device communicating with the network device <NUM> and a terminal device communicating with the network device <NUM> may be the same or may be different. The terminal device <NUM> shown in <FIG> may simultaneously communicate with the network device <NUM> and the network device <NUM>. However, only a possible scenario is shown. In some scenarios, the terminal device may communicate with only the network device <NUM> or the network device <NUM>. This is not limited in this application.

It should be understood that <FIG> is merely a simplified schematic diagram used as an example for ease of understanding. The communication system may further include another network device or another terminal device that is not shown in <FIG>.

The following describes in detail embodiments of this application with reference to the accompanying drawings.

It should be understood that the technical solutions in this application may be applied to a wireless communication system, for example, the communication system <NUM> shown in <FIG>. The communication system may include at least one network device and at least one terminal device, and the network device and the terminal device may communicate with each other through a wireless air interface. For example, the network device in the communication system may correspond to the network device <NUM> and the network device <NUM> shown in <FIG>, and the terminal device may correspond to the terminal device <NUM> shown in <FIG>.

Without loss of generality, the following describes embodiments of this application in detail by using an interaction process between a terminal device and a network device as an example. The terminal device may be a terminal device that is in a wireless communication system and that has a wireless connection relationship with the network device. It may be understood that the network device and a plurality of terminal devices that are in the wireless communication system and that have wireless connection relationships with the network device may transmit a data packet according to the same technical solutions. This is not limited in this application.

It should be understood that, in embodiments of this application, a sequence of a payload, a synchronization protocol header, a PDCP header, a MAC header, and an RLC header is a defined logical data structure, and is only a higher-layer data structure. A sequence at a lower layer and when a data unit is processed is not specifically limited in embodiments of this application.

<FIG> is an example flowchart of a communication method from a device interaction perspective according to an embodiment of this application. As shown in <FIG>, the method may include the following steps.

Step <NUM>: A centralized unit CU receives a data packet sent in a multicast manner.

The data packet herein may be an MBMS data packet, and is sent to the CU by a multicast gateway, an MBMS gateway, or a BM-SC. The MBMS data packet may be a synchronization packet data unit. The data packet herein may include a synchronization protocol header and a payload. That the data packet is sent in the multicast manner means that the data packet is sent to a terminal in the multicast manner.

Step <NUM>: The CU generates a PDCP data unit based on the data packet, where the PDCP data unit includes the data packet and a PDCP header.

Step <NUM>: The CU sends the PDCP data unit to a DU.

A synchronization protocol is transparent to the CU. The CU may not need to parse the synchronization protocol header, and may directly transparently transmit the PDCP data unit including the synchronization protocol header to the DU.

Step <NUM>: The DU generates a MAC data unit, where the MAC data unit includes a MAC header, an RLC header, the PDCP header, and the payload.

Step <NUM>: The DU sends the MAC data unit to the terminal.

The following describes different implementation methods of the embodiment shown in <FIG>.

In an implementation, the data packet received by the CU in step <NUM> may be a synchronization packet data unit, or the data packet may include the synchronization packet data unit. The synchronization packet data unit may include a synchronization protocol header and a payload. The payload is located after the synchronization protocol header. The PDCP data unit generated by the CU based on the data packet in step <NUM> may include the PDCP header, the synchronization protocol header, and the payload. The PDCP header is located before the synchronization protocol header.

In an implementation, the CU may send PDCP format information to the DU. The DU generates a MAC data unit based on the PDCP format information and the PDCP data unit, and sends the MAC data unit to the terminal. The PDCP format information includes at least one of the following: a length of the PDCP header, a PDCP serial number SN length, or a PDCP format indication.

It should be noted that the PDCP format information and the PDCP data unit may be simultaneously sent to the DU, or the CU may send the PDCP format information to the DU after sending the PDCP data unit. This is not specifically limited in this application.

The following describes the PDCP format information in detail.

The following describes the foregoing implementation method in detail with reference to the accompanying drawing. As shown in <FIG> and <FIG>, when the MBMS gateway or the BM-SC sends a synchronization packet data unit, a synchronization protocol (SYNC) header is before a payload (Payload). After receiving the synchronization packet data unit, the CU adds a PDCP header before the synchronization protocol header, to generate a PDCP data unit. The CU sends the PDCP data unit and PDCP format information to the DU. After receiving the PDCP data unit and the PDCP format information, the DU generates a MAC data unit. The MAC data unit includes a MAC header, an RLC header after the MAC header, the PDCP header after the RLC header, and the payload after the PDCP header. The DU sends the MAC data unit to the terminal.

In the present invention, that A is after (or before) B means that a bit stream of A is after (or before) a bit stream of B. For example, if the bit stream of A is <NUM>, and the bit stream of B is <NUM>, a combination manner in which A is after B is <NUM>, and a combination manner in which A is before B is <NUM>.

In the foregoing method, in a CU-DU architecture, the data packet sent in the multicast manner can be processed, to support sending of a multimedia broadcast service in a broadcast form, and enhance a sending effect of the multimedia broadcast service. In addition, the CU sends the PDCP format information to the DU, so that the DU can accurately determine the length of the PDCP header, and further accurately determine a start position of the synchronization protocol header, to read and remove the synchronization protocol header.

In another implementation, the data packet received by the CU in step <NUM> may be a synchronization packet data unit. The synchronization packet data unit includes a synchronization protocol header and a payload after the synchronization protocol header. The PDCP data unit generated by the CU based on the data packet in step <NUM> may include the PDCP header, the payload after the PDCP header, and the synchronization protocol header after the payload. The following describes this implementation in detail with reference to <FIG>.

A feasible example is shown in <FIG> and <FIG>. When the multicast gateway, the MBMS gateway, or the BM-SC sends a synchronization packet data unit, a synchronization protocol header is before a payload. After receiving the synchronization packet data unit, the CU moves the synchronization protocol header in the synchronization packet data unit to after the payload (as shown in <FIG>, moves the synchronization protocol header from a dashed-line box SYNC to a solid-line box SYNC), and adds a PDCP header before the payload, to generate a PDCP data unit. Therefore, the PDCP data unit includes the PDCP header, the payload after the PDCP header, and the synchronization protocol header after the payload. The CU sends the PDCP data unit to the DU. The DU generates a MAC data unit based on the PDCP data unit, where the MAC data unit includes a MAC header, an RLC header after the MAC header, the PDCP header after the RLC header, and the payload after the PDCP header. The DU sends the MAC data unit to the terminal.

Another feasible example is shown in <FIG> and <FIG>. The multicast gateway, the MBMS gateway, or the BM-SC sends a data packet. The data packet may be a first synchronization packet data unit, or the data packet may include the first synchronization packet data unit. The first synchronization packet data unit includes a synchronization protocol header and a payload after the synchronization protocol header. After receiving the first synchronization packet data unit, the CU reverses a bit stream of the first synchronization packet data unit to obtain a second synchronization packet data unit. For example, if the bit stream of the first synchronization packet data unit is <NUM>, where a bit stream of the synchronization protocol header is <NUM>, and a bit stream of the payload is <NUM>, a bit stream of the second synchronization packet data unit is <NUM>. That is, the second synchronization packet data unit is obtained by reversing the bit stream of the first synchronization packet data unit. The CU adds a PDCP header before a payload of the second synchronization packet data unit, to generate a PDCP data unit. The CU sends the PDCP data unit to the DU. The DU generates a MAC data unit based on the PDCP data unit, where the MAC data unit includes a MAC header, an RLC header after the MAC header, the PDCP header after the RLC header, and the payload that is in the second synchronization packet data unit and that is after the PDCP header. The DU sends the MAC data unit to the terminal.

In the foregoing method, the CU does not need to send PDCP format information to the DU, and the DU may directly remove the synchronization protocol header from the rear of the PDCP data unit, and add the RLC header and the MAC header, so that a quantity of times of signaling interworking between the CU and the DU can be reduced.

In still another implementation, the data packet received by the CU in step <NUM> may be a synchronization packet data unit. The synchronization packet data unit includes a payload, and a synchronization protocol header after the payload. The PDCP data unit generated by the CU based on the data packet in step <NUM> may include the PDCP header, the payload after the PDCP header, and the synchronization protocol header after the payload. The following describes the foregoing implementation method in detail with reference to the accompanying drawing.

As shown in <FIG> and <FIG>, when the multicast gateway, the MBMS gateway, or the BM-SC sends a synchronization packet data unit, a synchronization protocol header is after a payload. After receiving the synchronization packet data unit, the CU adds a PDCP header before the payload, to generate a PDCP data unit. Therefore, the PDCP data unit includes the PDCP header, the payload after the PDCP header, and the synchronization protocol header after the payload. The CU sends the PDCP data unit to the DU. The DU generates a MAC data unit based on the PDCP data unit. The MAC data unit includes a MAC header, an RLC header after the MAC header, the PDCP header after the RLC header, and the payload after the PDCP header. The DU sends the MAC data unit to the terminal.

In the foregoing method, the CU may directly add the PDCP header before the synchronization packet data unit, and does not need to send PDCP format information to the DU, so that a quantity of times of signaling interworking between the CU and the DU can be reduced.

In yet another implementation, the data packet received by the CU in step <NUM> may be a synchronization packet data unit. The synchronization packet data unit includes a synchronization protocol header and a payload after the synchronization protocol header. The PDCP data unit generated by the CU based on the data packet in step <NUM> may include the PDCP header and the synchronization packet data unit after the PDCP header. The following describes the foregoing implementation method in detail with reference to the accompanying drawing.

As shown in <FIG> and <FIG>, when the multicast gateway, the MBMS gateway, or the BM-SC sends a synchronization packet data unit, a synchronization protocol header is before a payload. After receiving the synchronization packet data unit, the CU generates a PDCP data unit. When generating the PDCP data unit, the CU needs to remove the synchronization protocol header, and add a PDCP header before the payload. After adding the PDCP header, the CU needs to add the removed synchronization protocol header before the PDCP header. Therefore, the PDCP data unit generated by the CU includes the PDCP header and the synchronization packet data unit after the PDCP header. The CU sends the PDCP data unit to the DU. The DU generates a MAC data unit based on the PDCP data unit. The MAC data unit includes a MAC header, an RLC header after the MAC header, the PDCP header after the RLC header, and the payload after the PDCP header. The DU sends the MAC data unit to the terminal.

In the foregoing method, the CU does not need to send PDCP format information to the DU, and the DU may directly remove the synchronization protocol header from the front of the PDCP data unit, and add the RLC header and the MAC header, so that signaling interworking between the CU and the DU is reduced.

In the technical solutions provided in embodiments of this application, the DU receives the PDCP data unit from the CU or the multicast gateway, or the CU receives the synchronization protocol data unit from the multicast gateway. In the technical solutions provided in embodiments of this application, the DU may further determine, based on the synchronization protocol header, whether data is lost. The synchronization protocol header includes at least one of the following:.

In an implementation, the CU receives a synchronization packet data unit (SYNC PDU or SYNC packet) from the multicast gateway, where the synchronization packet data unit includes a synchronization protocol header and a payload (payload), and the synchronization protocol header includes an octet counter. The CU encapsulates the synchronization packet data unit into a PDCP data unit, and sends the PDCP data unit to the DU. The DU receives the PDCP data unit, and learns that a value of the octet counter included in the synchronization protocol header is a first value. The DU determines that a sum of octets of an elapsed payload in a first synchronization sequence is recorded as a second value. If the DU determines that the first value is equal to the second value, the DU determines that no multicast data is lost. If the first value is not equal to the second value, the DU determines that multicast data is lost.

The following describes the foregoing implementation method.

For example, the DU receives the first three PDCP data units in a first synchronization sequence, and the first three PDCP data units are respectively a PDCP data unit a, a PDCP data unit b, and a PDCP data unit c in a receiving sequence. A value of an octet counter included in a synchronization protocol header of the PDCP data unit c is <NUM> bytes. The DU calculates a sum of octets of payloads of the PDCP data unit a and the PDCP data unit b. If the calculated sum of the octets of the payloads is <NUM> bytes, the DU determines that no data is lost when the PDCP data unit c is received. If the calculated sum of the octets of the payloads is not <NUM> bytes, the DU determines that data is lost when the PDCP data unit c is received.

In the foregoing method, the DU may determine, based on the sum of the octets of the elapsed payload, whether the multicast data is lost, and the DU may ignore a quantity of octets of a PDCP header.

In another implementation, the CU receives a synchronization packet data unit (SYNC PDU or SYNC packet) from the multicast gateway, where the synchronization packet data unit includes a synchronization protocol header and a payload (payload), and the synchronization protocol header includes an octet counter. The CU encapsulates the synchronization packet data unit into a PDCP data unit, and sends the PDCP data unit to the DU. The DU receives the PDCP data unit, and learns that a value of an octet counter in the PDCP data unit is a first value. The DU determines a sum of octets of a payload of a PDCP data unit received in a first synchronization sequence. If the sum of the octets of the payload of the PDCP data unit is the same as the first value, the DU determines that no data is lost when the current PDCP data unit is received. If the sum of the octets of the payload of the PDCP data unit is different from the first value, the DU determines that data is lost when the current PDCP data unit is received.

It should be noted that the first synchronization sequence herein may be one synchronization sequence, two synchronization sequences, or three synchronization sequences. This is not specifically limited in this application. The following describes the foregoing implementation method in detail.

For example, the DU receives three PDCP data units in a first synchronization sequence, and the three PDCP data units are respectively a PDCP data unit a, a PDCP data unit b, and a PDCP data unit c in a receiving sequence. When receiving the PDCP data unit c, the DU learns that a value of an octet counter included in a synchronization protocol header of the PDCP data unit c is <NUM> bytes. The DU calculates a sum of octets of payloads of the PDCP data unit a, the PDCP data unit b, and the PDCP data unit c. If the calculated sum of the octets of the payloads is <NUM> bytes, it is determined that no data is lost in the first synchronization sequence. If the calculated sum of the octets of the payloads is not <NUM> bytes, it is determined that data is lost in the first synchronization sequence.

In the foregoing method, the DU may determine, based on the sum of octets of the payload of the PDCP data unit received in the first synchronization sequence, whether multicast data is lost in the first synchronization sequence, and the DU may ignore a quantity of octets of a PDCP header.

In still another implementation, the CU receives a synchronization packet data unit (SYNC PDU or SYNC packet) from the multicast gateway, where the synchronization packet data unit includes a synchronization protocol header and a payload (payload), and a value of an octet counter included in the synchronization protocol header is a first value. The CU encapsulates the synchronization packet data unit into a PDCP data unit, and sends the PDCP data unit to the DU. The DU receives the PDCP data unit, and learns that a value of an octet counter in the PDCP data unit is a second value. The second value is a sum of the first value and octets of a PDCP header. The DU determines a sum of octets of a payload and octets of a PDCP header of a PDCP data unit received in a first synchronization sequence. If the sum of the octets of the payload and the octets of the PDCP header of the PDCP data unit is the same as the second value, the DU determines that no data is lost when the PDCP data unit is received. If the sum of the octets of the payload and the octets of the PDCP header of the PDCP data unit is different from the second value, the DU determines that data is lost when the PDCP data unit is received.

It should be noted that the first synchronization sequence herein may be one synchronization sequence, two synchronization sequences, or three synchronization sequences. This is not specifically limited in this application. The following describes the foregoing implementation with reference to <FIG>.

As shown in <FIG>, the CU receives the <NUM>st multicast data packet, where a value of an octet counter in the <NUM>st multicast data packet is <NUM>, and a payload has x1 octets. The CU generates a first PDCP data unit based on the <NUM>st multicast data packet, where a value of an octet counter in the first PDCP data unit is <NUM>, a PDCP header has y1 octets, and the payload has the x1 octets. The CU sends the first PDCP data unit to the DU. The CU receives the <NUM>nd multicast data packet, where a value of an octet counter in the <NUM>nd multicast data packet is a sum of octets of the elapsed payload in a first synchronization sequence, namely, x1, and a payload has x2 octets. The CU generates a second PDCP data unit based on the <NUM>nd multicast data packet, where a value of an octet counter in the second PDCP data unit is a sum of octets of the elapsed payload and PDCP header in the first synchronization sequence, namely, x1+y1, a PDCP header has y1 octets, and the payload has the x2 octets. The CU sends the second PDCP data unit to the DU. The CU receives the <NUM>rd multicast data packet, where a value of an octet counter in the <NUM>rd multicast data packet is x1+x2, and a payload has x3 octets. The CU generates a third PDCP data unit based on the <NUM>rd multicast data packet, where a value of an octet counter in the third PDCP data unit is x1+x2+<NUM>×y1, a PDCP header has y1 octets, and the payload has the x3 octets. The CU sends the PDCP data unit to the DU.

The DU receives the first PDCP data unit, the second PDCP data unit, and the third PDCP data unit in the first synchronization sequence. When receiving the second PDCP data unit, the DU learns that the value of the octet counter in the second PDCP data unit is x1+y1. When the DU learns that the sum of the octets of the payload and the octets of the PDCP header of the elapsed first PDCP data unit in the first synchronization sequence is x1+y1, the DU determines that no multicast data is lost when the second PDCP data unit is received. When receiving the third PDCP data unit, the DU learns that the value of the octet counter in the third PDCP data unit is x1+x2+<NUM>×y1. The DU calculates a sum of octets of the payloads and the PDCP headers of the elapsed first PDCP data unit and second PDCP data unit in the first synchronization sequence. When the DU determines that the sum of the octets of the payloads and the PDCP headers of the first PDCP data unit and the second PDCP data unit is equal to x1+x2+<NUM>×y1, the DU determines that no multicast data is lost when the third PDCP data unit is received.

In yet another implementation, the CU receives a synchronization packet data unit (SYNC PDU or SYNC packet) from the multicast gateway, where the synchronization packet data unit includes a synchronization protocol header and a payload (payload), and a value of an octet counter included in the synchronization protocol header is a first value. The CU encapsulates the synchronization packet data unit into a PDCP data unit, and sends the PDCP data unit to the DU. The DU receives the PDCP data unit, and learns that a value of an octet counter in the PDCP data unit is a second value. The second value is a sum of the first value and octets of a PDCP header. The DU determines a sum of octets of payloads and octets of PDCP headers of all PDCP data units received in a first synchronization sequence. If the sum of the octets of the payloads and the octets of the PDCP headers of the PDCP data units is the same as the second value, the DU determines that no data is lost when the PDCP data unit is received. If the sum of the octets of the payloads and the octets of the PDCP headers of the PDCP data units is different from the second value, the DU determines that data is lost when the PDCP data unit is received.

It should be noted that the first synchronization sequence herein may be one synchronization sequence, two synchronization sequences, or three synchronization sequences. This is not specifically limited in this application. The following describes the foregoing implementation method in detail with reference to <FIG> and <FIG>.

As shown in <FIG>, the CU receives the <NUM>st multicast data packet, where a value of an octet counter in the <NUM>st multicast data packet is a sum of octets of a payload received by the CU in a first synchronization sequence, and the payload has x1 octets. The CU generates a first PDCP data unit based on the <NUM>st multicast data packet, where a value of an octet counter in the first PDCP data unit is a sum of the octets of the payload received by the CU and octets of a PDCP header added by the CU in the first synchronization sequence, namely, x1+y1, the PDCP header has y1 octets, and the payload has the x1 octets. The CU sends the first PDCP data unit to the DU. The CU receives the <NUM>nd multicast data packet, where a value of an octet counter in the <NUM>nd multicast data packet is a sum of octets of payloads received in the first synchronization sequence, namely, x1+x2, and a payload has x2 octets. The CU generates a second PDCP data unit based on the <NUM>nd multicast data packet, where a value of an octet counter in the second PDCP data unit is x1+x2+<NUM>×y1, a PDCP header has y1 octets, and the payload has the x2 octets. The CU sends the second PDCP data unit to the DU. The CU receives the <NUM>rd multicast data packet, where a value of an octet counter in the <NUM>rd multicast data packet is x1+x2+x3, and a payload has x3 octets. The CU generates a third PDCP data unit based on the <NUM>rd multicast data packet, where a value of an octet counter in the third PDCP data unit is x1+x2+x3+<NUM>×y1, a PDCP header has y1 octets, and the payload has the x3 octets. The CU sends the PDCP data unit to the DU.

The DU receives the first PDCP data unit, the second PDCP data unit, and the third PDCP data unit in the first synchronization sequence. When receiving the second PDCP data unit, the DU learns that the value of the octet counter in the second PDCP data unit is x1+x2+<NUM>×y1. When the DU learns that a sum of octets of payloads and octets of PDCP headers of the elapsed first PDCP data unit in the first synchronization sequence is x1+x2+<NUM>×y1, the DU determines that no multicast data is lost when the second PDCP data unit is received. When receiving the third PDCP data unit, the DU learns that the value of the octet counter in the third PDCP data unit is x1+x2+x3+<NUM>×y1. The DU calculates a sum of octets of payloads and PDCP headers of the first PDCP data unit, the second PDCP data unit, and the third PDCP data unit received in the first synchronization sequence. When the DU determines that the sum of the octets of the payloads and the PDCP headers of the first PDCP data unit and the second PDCP data unit is equal to x1+x2+x3+<NUM>×y1, the DU determines that no multicast data is lost when the third PDCP data unit is received.

As shown in <FIG>, the CU receives the <NUM>st multicast data packet, where a value of an octet counter in the <NUM>st multicast data packet is <NUM>, and a payload has x1 octets. The CU generates a first PDCP data unit based on the <NUM>st multicast data packet, where a value of an octet counter in the first PDCP data unit is <NUM>, a PDCP header has y1 octets, and the payload has the x1 octets. The CU sends the first PDCP data unit to the DU. The CU receives the <NUM>nd multicast data packet, where a value of an octet counter in the <NUM>nd multicast data packet is a sum of octets of payloads received by the CU in a first synchronization sequence, namely, x1+x2, and a payload has x2 octets. The CU generates a second PDCP data unit based on the <NUM>nd multicast data packet, where a value of an octet counter in the second PDCP data unit is a sum of the octets of the payloads received by the CU and octets of PDCP headers added by the CU in the first synchronization sequence, namely, x1+x2+<NUM>×y1, a PDCP header has y1 octets, and the payload has the x2 octets. The CU sends the second PDCP data unit to the DU. The CU receives the <NUM>rd multicast data packet, where a value of an octet counter in the <NUM>rd multicast data packet is x1+x2+x3, and a payload has x3 octets. The CU generates a third PDCP data unit based on the <NUM>rd multicast data packet, where a value of an octet counter in the third PDCP data unit is x1+x2+x3+<NUM>×y1, a PDCP header has y1 octets, and the payload has the x3 octets. The CU sends the PDCP data unit to the DU.

In an implementation, the value of the octet counter included in the synchronization protocol header of the synchronization packet data unit received by the CU is a first value. After generating a PDCP data unit, the CU modifies the value of the octet counter to a second value. The second value is a sum of the first value and octets of the synchronization protocol header.

The DU receives a current PDCP data unit from the CU in a first synchronization sequence, and the DU obtains an octet counter included in a synchronization protocol header of the current PDCP data unit. If a value of the octet counter is the second value, the DU determines a sum of octets of a payload and octets of a synchronization protocol header of an elapsed PDCP data unit in the first synchronization sequence. If the sum of the octets of the payload and the octets of the synchronization protocol header of the PDCP data unit is the same as the second value, the DU determines that no data is lost when the current PDCP data unit is received. If the sum of the octets of the payload and the octets of the synchronization protocol header of the PDCP data unit is different from the second value, the DU determines that data is lost when the current PDCP data unit is received.

For example, the CU receives three synchronization packet data units in a first synchronization sequence, and the three synchronization packet data units are respectively a synchronization packet data unit a, a synchronization packet data unit b, and a synchronization packet data unit c in a receiving sequence. After generating a PDCP data unit a1 based on the synchronization packet data unit a, the CU modifies a value of an octet counter included in a synchronization protocol header to the second value. Similarly, after generating a PDCP data unit b1 based on the synchronization packet data unit b, the CU modifies a value of an octet counter included in a synchronization protocol header to the second value. After generating a PDCP data unit c1 based on the synchronization packet data unit c, the CU modifies a value of an octet counter included in a synchronization protocol header to the second value. The CU sends the PDCP data units a1, b1, and c1 to the DU.

The DU receives three PDCP data units in the first synchronization sequence, and the three PDCP data units are respectively the PDCP data unit a1, the PDCP data unit b <NUM>, and the PDCP data unit c1 in a receiving sequence. When receiving the PDCP data unit b1, the DU learns that the value of the octet counter included in the synchronization protocol header of the PDCP data unit is <NUM> bytes, and the DU calculates, in the first synchronization sequence, a sum of octets of a payload and a synchronization protocol header of an elapsed PDCP data unit, namely, the PDCP data unit a1. If the calculated sum of the octets is <NUM> bytes, the DU determines that no data is lost when the PDCP data unit b1 is received. When receiving the PDCP data unit c1, the DU learns that the value of the octet counter included in the synchronization protocol header of the PDCP data unit c1 is <NUM> bytes. The DU calculates a sum of octets of payloads of the PDCP data unit a1 and the PDCP data unit b1 and a sum of octets of synchronization protocol headers of the PDCP data unit a1 and the PDCP data unit b1. If the calculated sum of the octets is <NUM> bytes, the DU determines that no data is lost when the PDCP data unit c1 is received. If the calculated sum of the octets is not <NUM> bytes, the DU determines that data is lost when the PDCP data unit c1 is received.

In another implementation, the value of the octet counter included in the synchronization protocol header of the synchronization packet data unit received by the CU is a first value. After generating a PDCP data unit, the CU modifies the value of the octet counter to a second value. The second value is a sum of the first value and octets of the synchronization protocol header.

The DU receives a current PDCP data unit from the CU in a first synchronization sequence, and the DU obtains an octet counter included in a synchronization protocol header of the current PDCP data unit. If a value of the octet counter is the second value, the DU determines a sum of octets of payloads and octets of synchronization protocol headers of all PDCP data units received in the first synchronization sequence. If the sum of the octets of the payloads and the octets of the synchronization protocol headers of the PDCP data units is the same as the second value, the DU determines that no data is lost when the current PDCP data unit is received. If the sum of the octets of the payloads and the octets of the synchronization protocol headers of the PDCP data units is different from the second value, the DU determines that data is lost when the current PDCP data unit is received.

The DU receives three PDCP data units in the first synchronization sequence, and the three PDCP data units are respectively the PDCP data unit a1, the PDCP data unit b <NUM>, and the PDCP data unit c1 in a receiving sequence. When receiving the PDCP data unit b1, the DU learns that the value of the octet counter included in the synchronization protocol header of the PDCP data unit is <NUM> bytes, and the DU calculates a sum of octets of payloads and synchronization protocol headers of all PDCP data units, namely, the PDCP data unit a1 and the PDCP data unit b1, that are received in the first synchronization sequence. If the calculated sum of the octets is <NUM> bytes, the DU determines that no data is lost when the PDCP data unit b1 is received. When receiving the PDCP data unit c1, the DU learns that the value of the octet counter included in the synchronization protocol header of the PDCP data unit c1 is <NUM> bytes. The DU calculates a sum of octets of payloads of the PDCP data unit a1, the PDCP data unit b1, and the PDCP data unit c1, and a sum of octets of synchronization protocol headers of the PDCP data unit a1, the PDCP data unit b1, and the PDCP data unit c1. If the calculated sum of the octets is <NUM> bytes, the DU determines that no data is lost when the PDCP data unit c1 is received. If the calculated sum of the octets is not <NUM> bytes, the DU determines that data is lost when the PDCP data unit c1 is received.

The foregoing describes in detail the communication method in embodiments of this application with reference to <FIG>. The following describes in detail communication apparatuses in embodiments of this application with reference to <FIG>.

<FIG> is a schematic diagram of a structure of a network device according to an embodiment of this application, for example, may be a schematic diagram of a structure of a base station. As shown in <FIG>, the base station may be used in the system shown in <FIG>, to perform functions of the centralized unit in the foregoing method embodiments. The base station <NUM> may include one or more radio frequency units, such as a remote radio unit (remote radio unit, RRU) <NUM> and one or more baseband units (baseband units, BBUs) (which may also be referred to as digital units, digital units, DUs) <NUM>. The RRU <NUM> may be referred to as a transceiver unit, a transceiver, a transceiver circuit, a transceiver, or the like, and may include at least one antenna <NUM> and a radio frequency unit <NUM>. The RRU <NUM> part is mainly configured to perform sending and receiving of a radio frequency signal and conversion between the radio frequency signal and a baseband signal, for example, configured to send the PDCP data unit in the foregoing embodiments to a distributed unit. The BBU <NUM> part is mainly configured to: perform baseband processing, control a base station, and so on. The RRU <NUM> and the BBU <NUM> may be physically disposed together; or may be physically disposed separately, in other words, in a distributed base station.

The BBU <NUM> is a control center of the base station, may also be referred to as a processing unit, and is mainly configured to implement baseband processing functions such as channel coding, multiplexing, modulation, and spectrum spreading. For example, the BBU (processing unit) <NUM> may be configured to control the base station to perform an operation procedure related to the centralized unit in the foregoing method embodiments.

In an example, the BBU <NUM> may include one or more boards. A plurality of boards may jointly support a radio access network (such as an LTE network) of a single access standard, or may separately support radio access networks (such as an LTE network, a <NUM> network, and another network) of different access standards. The BBU <NUM> further includes a memory <NUM> and a processor <NUM>. The memory <NUM> is configured to store necessary instructions and data. For example, the memory <NUM> stores the synchronization protocol header in the foregoing embodiments. The processor <NUM> is configured to control the base station to perform a necessary action, for example, configured to control the base station to perform an operation procedure related to the centralized unit in the foregoing method embodiments. The memory <NUM> and the processor <NUM> may serve one or more boards. In other words, a memory and a processor may be independently disposed on each board, or a plurality of boards may share a same memory and a same processor. In addition, a necessary circuit may further be disposed on each board.

<FIG> is a schematic diagram of a structure of a network device according to an embodiment of this application, for example, may be a schematic diagram of a structure of a base station. As shown in <FIG>, the base station may be used in the system shown in <FIG>, to perform functions of the distributed unit in the foregoing method embodiments. The base station <NUM> may include one or more radio frequency units, such as a remote radio unit (remote radio unit, RRU) <NUM> and one or more baseband units (baseband units, BBUs) (which may also be referred to as digital units, digital units, DUs) <NUM>. The RRU <NUM> may be referred to as a transceiver unit, a transceiver, a transceiver circuit, a transceiver, or the like, and may include at least one antenna <NUM> and a radio frequency unit <NUM>. The RRU <NUM> part is mainly configured to perform sending and receiving of a radio frequency signal and conversion between the radio frequency signal and a baseband signal, for example, configured to send the MAC data unit in the foregoing embodiments to a terminal. The BBU <NUM> part is mainly configured to: perform baseband processing, control a base station, and so on. The RRU <NUM> and the BBU <NUM> may be physically disposed together; or may be physically disposed separately, in other words, in a distributed base station.

The BBU <NUM> is a control center of the base station, may also be referred to as a processing unit, and is mainly configured to implement baseband processing functions such as channel coding, multiplexing, modulation, and spectrum spreading. For example, the BBU (processing unit) <NUM> may be configured to control the base station to perform an operation procedure related to the distributed unit in the foregoing method embodiments.

In an example, the BBU <NUM> may include one or more boards. A plurality of boards may jointly support a radio access network (such as an LTE network) of a single access standard, or may separately support radio access networks (such as an LTE network, a <NUM> network, and another network) of different access standards. The BBU <NUM> further includes a memory <NUM> and a processor <NUM>. The memory <NUM> is configured to store necessary instructions and data. The processor <NUM> is configured to control the base station to perform a necessary action, for example, configured to control the base station to perform an operation procedure related to the centralized unit in the foregoing method embodiments. The memory <NUM> and the processor <NUM> may serve one or more boards. In other words, a memory and a processor may be independently disposed on each board, or a plurality of boards may share a same memory and a same processor. In addition, a necessary circuit may further be disposed on each board.

<FIG> is a schematic diagram of a structure of a communication apparatus <NUM>. The apparatus <NUM> may be configured to implement the method described in the foregoing method embodiments. For details, refer to the descriptions in the foregoing method embodiments. The communication apparatus <NUM> may be a chip, a network device (such as a base station), a terminal device, another network device, or the like.

The communication apparatus <NUM> includes one or more processors <NUM>. The processor <NUM> may be a general-purpose processor, a dedicated processor, or the like. For example, the processor may be a baseband processor or a central processing unit. The baseband processor may be configured to process a communication protocol and communication data. The central processing unit may be configured to: control the communication apparatus (for example, a base station, a terminal, or a chip), execute a software program, and process data of the software program. The communication apparatus may include a transceiver unit that is configured to input (receive) and output (send) a signal. For example, the communication apparatus may be a chip, and the transceiver unit may be an input and/or output circuit or a communication interface of the chip. The chip may be used for a terminal, a base station, or another network device. For another example, the communication apparatus may be a terminal, a base station, or another network device, and the transceiver unit may be a transceiver, a radio frequency chip, or the like.

The communication apparatus <NUM> includes one or more processors <NUM>, and the one or more processors <NUM> may implement the method performed by the centralized unit or the distributed unit in the embodiment shown in <FIG>.

In a possible design, the communication apparatus <NUM> includes a means (means) configured to generate a PDCP data unit or a MAC data unit, and a means (means) configured to send the PDCP data unit or the MAC data unit. Functions of the means for generating the PDCP data unit or the MAC data unit and the means for sending the PDCP data unit or the MAC data unit may be implemented by using one or more processors. For example, the PDCP data unit or the MAC data unit may be generated by using the one or more processors, and the PDCP data unit or the MAC data unit may be sent by using the transceiver, the input/output circuit, or the interface of the chip. For the PDCP data unit or the MAC data unit, refer to related descriptions in the foregoing method embodiments.

In a possible design, the communication apparatus <NUM> includes a means (means) configured to receive a data packet, a PDCP data unit, or a MAC data unit, and a means (means) configured to send the PDCP data unit based on the data packet or a means (means) configured to send the MAC data unit based on the PDCP data unit. For the data packet and how to send the PDCP data unit based on the data packet, refer to related descriptions in the foregoing method embodiments. For example, the data packet may be received by using the transceiver, the input/output circuit, or the interface of the chip, and the PDCP data unit may be sent based on the data packet by using one or more processors. For the PDCP data unit and how to send the MAC data unit based on the PDCP data unit, refer to related descriptions in the foregoing method embodiments. For example, the PDCP data unit may be received by using the transceiver, the input/output circuit, or the interface of the chip, and the MAC data unit may be sent based on the PDCP data unit by using one or more processors.

Optionally, in addition to the method in the embodiment shown in <FIG>, the processor <NUM> may further implement another function.

Optionally, in a design, the processor <NUM> may execute instructions, to enable the communication apparatus <NUM> to perform the method described in the foregoing method embodiments. All or a part of the instructions, for example, instructions <NUM>, may be stored in the processor. Alternatively, all or a part of the instructions, for example, instructions <NUM>, may be stored in the memory <NUM> coupled to the processor. Alternatively, both instructions <NUM> and <NUM> may be used to enable the communication apparatus <NUM> to perform the method described in the foregoing method embodiments.

In still another possible design, the communication apparatus <NUM> may include a circuit, and the circuit may implement functions of the centralized unit or the distributed unit in the foregoing method embodiments.

In yet another possible design, the communication apparatus <NUM> may include one or more memories <NUM> that store instructions <NUM>. The instructions may be run on the processor, to enable the communication apparatus <NUM> to perform the method described in the foregoing method embodiments. Optionally, the memory may further store data. Optionally, the processor may also store instructions and/or data. For example, the one or more memories <NUM> may store the synchronization protocol header described in the foregoing embodiments, the PDCP indication information in the foregoing embodiments, or the like. The processor and the memory may be separately disposed, or may be integrated together.

In still yet another possible design, the communication apparatus <NUM> may further include a transceiver unit <NUM> and an antenna <NUM>. The processor <NUM> may be referred to as a processing unit, and controls the communication apparatus (a terminal or a base station). The transceiver unit <NUM> may be referred to as a transceiver, a transceiver circuit, a transceiver, or the like, and is configured to implement a transceiver function of the communication apparatus through the antenna <NUM>.

This application further provides a communication system, including the foregoing one or more network devices and one or more terminal devices.

It should be noted that the processor in embodiments of this application may be an integrated circuit chip, and has a signal processing capability. In an implementation process, steps in the foregoing method embodiments may be implemented by using a hardware integrated logic circuit in the processor or instructions in a form of software. The processor may be a general-purpose processor, a digital signal processor (Digital Signal Processor, DSP), an application-specific integrated circuit (Application-Specific Integrated Circuit, ASIC), a field programmable gate array (Field Programmable Gate Array, FPGA) or another programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component. The processor may implement or perform the methods, steps, and logical block diagrams that are disclosed in embodiments of this application. The general-purpose processor may be a microprocessor, or the processor may be any conventional processor or the like. The steps of the methods disclosed with reference to embodiments of this application may be directly performed and completed by a hardware decoding processor, or may be performed and completed by using a combination of hardware and software modules in a decoding processor. The software module may be located in a mature storage medium in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, or a register. The storage medium is located in the memory, and the processor reads information in the memory and completes the steps in the foregoing methods in combination with hardware of the processor.

It may be understood that, in embodiments of this application, the memory may be a volatile memory or a non-volatile memory, or may include both a volatile memory and a non-volatile memory. The non-volatile memory may be a read-only memory (Read-Only Memory, ROM), a programmable read-only memory (Programmable ROM, PROM), an erasable programmable read-only memory (Erasable PROM, EPROM), an electrically erasable programmable read-only memory (Electrically EPROM, EEPROM), or a flash memory. The volatile memory may be a random access memory (Random Access Memory, RAM), used as an external cache. Through example but not limitative descriptions, many forms of RAMs may be used, for example, a static random access memory (Static RAM, SRAM), a dynamic random access memory (Dynamic RAM, DRAM), a synchronous dynamic random access memory (Synchronous DRAM, SDRAM), a double data rate synchronous dynamic random access memory (Double Data Rate SDRAM, DDR SDRAM), an enhanced synchronous dynamic random access memory (Enhanced SDRAM, ESDRAM), a synchlink dynamic random access memory (Synchlink DRAM, SLDRAM), and a direct rambus random access memory (Direct Rambus RAM, DR RAM). It should be noted that the memory in the system and the method described in this specification is intended to include, but not limited to, these memories and any memory of another proper type.

An embodiment of this application further provides a computer-readable medium. The computer-readable medium stores a computer program. When the computer program is executed by a computer, the communication method according to any one of the foregoing method embodiments is implemented.

An embodiment of this application further provides a computer program product. When the computer program product is executed by a computer, the communication method according to any one of the foregoing method embodiments is implemented.

All or some of the foregoing embodiments may be implemented by using software, hardware, firmware, or any combination thereof. When software is used to implement embodiments, all or some of the embodiments may be implemented in a form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or some of the procedures or functions according to embodiments of this application are generated. The computer may be a general-purpose computer, a dedicated computer, a computer network, or another programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or may be transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center in a wired (for example, a coaxial cable, an optical fiber, or a digital subscriber line (Digital Subscriber Line, DSL)) or wireless (for example, infrared, radio, and microwave) manner. The computer-readable storage medium may be any usable medium accessible by a computer, or a data storage device, for example, a server or a data center, integrating one or more usable media. The usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, or a magnetic tape), an optical medium (for example, a high-density digital video disc (Digital Video Disc, DVD)), a semiconductor medium (for example, a solid-state drive (Solid State Disk, SSD)), or the like.

An embodiment of this application further provides a processing apparatus, including a processor and an interface. The processor is configured to perform the communication method according to any one of the foregoing method embodiments.

It should be understood that the processing apparatus may be a chip. The processor may be implemented by hardware, or may be implemented by software. When the processor is implemented by hardware, the processor may be a logic circuit, an integrated circuit, or the like. When the processor is implemented by software, the processor may be a general-purpose processor, implemented by reading software code stored in a memory. The memory may be integrated into the processor, or may be located outside the processor and exist independently.

It should be understood that "one embodiment" or "an embodiment" mentioned in the entire specification means that particular features, structures, or characteristics related to embodiments are included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing in the entire specification does not necessarily refer to a same embodiment. In addition, these particular features, structures, or characteristics may be combined in one or more embodiments in any appropriate manner. The execution sequences of the processes should be determined according to functions and internal logic of the processes, and should not be construed as any limitation on the implementation processes of embodiments of this application.

In addition, the terms "system" and "network" are usually used interchangeably in this specification. The term "and/or" in this specification describes only an association relationship for describing associated objects and represents that three relationships may exist.

It should be understood that, in embodiments of this application, "B corresponding to A" indicates that B is associated with A, and B may be determined based on A. However, it should be further understood that determining B based on A does not mean that B is determined based only on A. B may also be alternatively determined based on A and/or other information.

A person of ordinary skill in the art may be aware that, units and algorithm steps in the examples described with reference to embodiments disclosed herein may be implemented by electronic hardware, computer software, or a combination thereof. To clearly describe the interchangeability between the hardware and the software, the foregoing has generally described compositions and steps of each example according to functions.

In several embodiments provided in this application, it should be understood that the disclosed system, apparatus, and method may be implemented in another manner. For example, the described apparatus embodiments are merely examples. For example, division into the units is merely logical function division. During actual implementation, there may be another division manner. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented through some interfaces. The indirect couplings or communication connections between the apparatuses or units may be implemented in electrical, mechanical, or other forms.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, in other words, may be located in one position, or may be distributed on a plurality of network units. Some or all of the units may be selected based on an actual requirement to achieve the objectives of the solutions in embodiments in this application.

In addition, function units in embodiments of this application may be integrated into one processing unit, each of the units may exist alone physically, or two or more units may be integrated into one unit.

Claim 1:
A communication method, wherein the method comprises:
receiving (<NUM>), by a centralized unit, a data packet sent in a multicast manner;
generating (<NUM>), by the centralized unit, a packet data convergence protocol, PDCP, data unit based on the data packet, wherein the PDCP data unit comprises the data packet and a PDCP header; and
sending (<NUM>), by the centralized unit, the PDCP data unit to a distributed unit;
wherein the data packet comprises a synchronization protocol header and a payload, and in the data packet, the payload is located after the synchronization protocol header, and
in the PDCP data unit, the payload is located after the PDCP header, and the synchronization protocol header is located after the payload, or
in the PDCP data unit, the PDCP header is located after the synchronization protocol header, and the payload is located after the PDCP header; or
the data packet comprises a first synchronization packet data unit, the first synchronization packet data unit comprises a synchronization protocol header and a payload, and in the first synchronization packet data unit, the payload is located after the synchronization protocol header; in the PDCP data unit, the PDCP header is located before a second synchronization packet data unit; and the second synchronization packet data unit is obtained by reversing a bit stream of the first synchronization packet data unit; or
in the data packet, the synchronization protocol header is located after the payload; and in the PDCP data unit, the PDCP header is located before the payload.