WO2022151297A1

WO2022151297A1 - Data transmission method and apparatus

Info

Publication number: WO2022151297A1
Application number: PCT/CN2021/071956
Authority: WO
Inventors: 高云龙; 罗海燕; 曾清海
Original assignee: 华为技术有限公司
Priority date: 2021-01-14
Filing date: 2021-01-14
Publication date: 2022-07-21

Abstract

A data transmission method and apparatus, relating to the technical field of communications, for use in ensuring highly reliable transmission of MBS service data. The method comprises: a first RLC entity of an access network device side sends at least one RLC SDU to at least one terminal device comprising a first terminal device; a second RLC entity of the access network device side receives first information from the first terminal device, the first information being used for indicating an RLC SN of a first RLC SDU that is not successfully received among the at least one RLC SDU; the second RLC entity of the access network device side delivers second information to the first RLC entity, the second information being used for indicating the RLC SDU that is not successfully received; and the first RLC entity or the second RLC entity sends the first RLC SDU to the first terminal device.

Description

Data transmission method and device

technical field

The present application relates to the field of communication technologies, and in particular, to a data transmission method and apparatus.

Background technique

Multicast broadcast service (multicast and broadcast service, MBS) is a service for multiple terminal equipment (user equipment, UE), such as live broadcast service, public safety service, batch software update service, etc. When the MBS service data is sent from the access network equipment to the terminal equipment, there are two transmission methods: the first is point to multi-point (PTM) transmission; the second is point-to-point ( point to point, PTP) transmission method.

At present, for the scenario where the access network equipment adopts the PTM transmission mode to transmit the MBS service data, the existing automatic repeat request (ARQ) technology cannot be directly applied, so that the highly reliable transmission of the MBS service data cannot be guaranteed.

SUMMARY OF THE INVENTION

Embodiments of the present application provide a data transmission method and apparatus, which are used to ensure highly reliable transmission of MBS service data.

In a first aspect, a data transmission method is provided, which is applied to an access network device, and the access network device is configured with a packet data convergence protocol (PDCP) entity, a first radio link control (radio link control) entity. , RLC) entity and the second RLC entity, the first RLC entity and the second RLC entity are respectively associated with the PDCP entity, the first RLC entity is used to support the point-to-multipoint PTM transmission mode to send the multicast broadcast service MBS service data, the second The RLC entity is used to support the point-to-point PTP transmission mode to send MBS service data, and the first RLC entity and the second RLC entity are associated with the same multicast radio bearer (MBS radio bearer, MRB). At least one terminal device including the terminal device sends at least one RLC service data unit (service data unit, SDU); the second RLC entity receives first information from the first terminal device, and the first information is used to indicate the RLC of the first RLC SDU Serial number (serial number, SN), the first RLC SDU belongs to at least one RLC SDU that has not been successfully received; the second RLC entity submits second information to the first RLC entity or PDCP entity, and the second information is used to indicate The RLC SN of the first RLC SDU; the first entity sends the first RLC SDU to the first terminal device, and the first entity is the first RLC entity or the second RLC entity.

Based on the above technical solutions, the access network device transmits the MBS service data in a PTM manner through the first RLC entity, and obtains the receiving state of the terminal device for the MBS service data through the second RLC entity. Further, the access network device may determine the MBS service data that needs to be retransmitted, and retransmit the MBS service data through the first RLC entity or the second RLC entity. It can be seen that the technical solution provided by the present application can make the ARQ mechanism applied to the PTM transmission mode, and ensure the highly reliable transmission of MBS service data.

In a possible design, the first entity is the first RLC entity; before the first entity sends the first RLC SDU to the first terminal device, the method further includes: the first RLC entity obtains the first RLC according to the second information SDU.

In a possible design, the first entity is the second RLC entity; before the first entity sends the first RLC SDU to the first terminal device, the method further includes: the first RLC entity sends the second RLC entity to the second RLC according to the second information The entity submits the first RLC SDU.

In a possible design, before the first entity sends the first RLC SDU to the first terminal device, the method further includes: the PDCP entity submits the first RLC SDU to the first entity according to the second information.

In a possible design, the second information includes the RLC SN of the first RLC SDU, and the PDCP entity submits the first RLC SDU to the first entity according to the second information, including: the PDCP entity according to the RLC SN of the first RLC SDU, and The preset mapping relationship is to determine the PDCP SN of the first PDCP protocol data unit (protocol data unit, PDU), and the preset mapping relationship is used to indicate the mapping relationship between the PDCP SN and the RLC SN; the PDCP entity is based on the PDCP of the first PDCP PDU. SN, obtains the first PDCP PDU, and the first PDCP PDU is the first RLC SDU; the PDCP entity submits the first RLC SDU to the first entity.

In a possible design, the second information includes the PDCP SN of the first PDCP PDU, and the PDCP entity submits the first RLC SDU to the first entity according to the second information, including: the PDCP entity obtains, according to the PDCP SN of the first PDCP PDU, the first RLC SDU. The first PDCP PDU, the first PDCP PDU is the first RLC SDU; the PDCP entity submits the first RLC SDU to the first entity.

In a possible design, before the second RLC entity submits the second information to the PDCP entity, the method further includes: the second RLC entity determines the first PDCP PDU according to the RLC SN of the first RLC SDU and the preset mapping relationship. The PDCP SN, the preset mapping relationship is used to indicate the mapping relationship between the PDCP SN and the RLC SN. Based on this design, the first RLC entity and the second RLC entity can perform the same RLC SN number on the RLC SDUs with the same content and submitted by the PDCP.

In a possible design, the method further includes: the access network device sends first indication information to the first terminal device, where the first indication information is used to instruct the first terminal device to receive starting data sequence number information of the MBS service data.

In a possible design, the starting data sequence number information includes the PDCP SN, the PDCP count value and/or the starting RLC SN.

In a possible design, the method further includes: the access network device sends MRB configuration information to the first terminal device, where the MRB configuration information is used to configure an MBS session between the first terminal device and the access network device.

In a possible design, the MRB configuration information includes a PTM identifier or MBS session information.

In a possible design, the MRB configuration information includes two RLC bearer configuration information, the two RLC bearer configuration information are associated with the same MRB, and at least one RLC bearer configuration information in the two RLC bearer configuration information includes a PTM identifier or MBS session information.

In a second aspect, a data transmission method is provided, the method is applied to a first terminal device, the first terminal device is configured with a third RLC entity and a fourth RLC entity, and the third RLC entity is used to receive the access network device in a PTM manner The sent MBS service data, the fourth RLC entity is used to receive the MBS service data sent by the access network device in the PTP manner, the third RLC entity and the fourth RLC entity are associated to the same MRB, and the method includes: the third RLC entity is connected from the The network access device receives at least one RLC SDU; the fourth RLC entity receives third information from the third RLC entity, the third information indicates the RLC SN of the first RLC SDU in the at least one RLC SDU; the fourth RLC entity generates the first RLC SDU according to the third information. 1 information; the fourth RLC entity sends the first information to the access network device, where the first information is used to indicate the RLC SN of the first RLC SDU, and the first RLC SDU belongs to the RLC SDU that is not successfully received in at least one RLC SDU.

Based on the above technical solutions, the third RLC entity receives at least one RLC SDU, and the third RLC entity sends the third information to the fourth RLC entity to trigger the fourth RLC entity to send the first information to the access network device, so that the access network device can be accessed by the third RLC entity. The network device learns that the first RLC SDU was not successfully received. Therefore, based on the mutual interaction between the third RLC entity and the fourth RLC entity, the ARQ mechanism in the PTM transmission mode can be implemented, and the highly reliable transmission of the MBS service data can be ensured.

In a possible design, before the fourth RLC entity receives the third information from the third RLC entity, the method further includes: the third RLC entity determines that the first RLC SDU has not been successfully received; the third RLC entity determines that the first RLC SDU is not successfully received; The RLC SN of the SDU generates the third information.

In a possible design, before the fourth RLC entity receives the third information from the third RLC entity, the method further includes: the third RLC entity determines that the second RLC SDU in the at least one RLC SDU is successfully received; the third RLC The entity generates the third information according to the RLC SN of the second RLC SDU.

In a possible design, after the fourth RLC entity sends the first information to the access network device, the method further includes: the fourth RLC entity receives the first RLC SDU from the access network device.

In a possible design, after the fourth RLC entity sends the first information to the access network device, the method further includes: the third RLC entity receives the first RLC SDU from the access network device.

In a possible design, the method further includes: the third RLC entity indicates to the fourth RLC entity that the first RLC SDU is successfully received. Therefore, the fourth RLC entity may learn that the first RLC SDU is successfully received, and thus the fourth RLC may not need to send the first information again, so as to trigger the access network device to retransmit the first RLC SDU.

In a possible design, the method further includes: the first terminal device receives first indication information from the access network device, where the first indication information is used to instruct the first terminal device to receive starting data sequence number information of the MBS service data.

In a possible design, the first indication information is specifically used to indicate the starting PDCP SN, the PDCP count value and/or the starting RLC SN.

In a possible design, the method further includes: the first terminal device receives MRB configuration information from the access network device, where the MRB configuration information is used to configure an MBS session between the first terminal device and the access network device.

In a third aspect, a data transmission method is provided, the method comprising: a target access network device receiving a handover request message from a source access network device, where the handover request message is used to request handover of a terminal device from the source access network device to the target access network device Network access device; the target access network device sends fourth information to the source access network device, where the fourth information is used to instruct the source access network device to forward to the target access network device at least one SN corresponding to the first sequence number SN MBS service data of terminal equipment.

Based on the above technical solution, the target access network device sends fourth information to the source access network device to instruct the source access network device to forward the information of the terminal device corresponding to at least one SN before the first sequence number SN to the target access network device. For MBS service data, unnecessary data forwarding between base stations is avoided during MBS service switching.

In a possible design, before the target access network device sends the fourth information to the source access network device, the method further includes: the target access network device obtains the second SN information from the core network element; the target access network device obtains the second SN information; The device determines the first SN information according to the second SN information. The first SN information is used to indicate the first SN.

In a possible design, the target access network device obtains the second SN information from the core network element, including: the target access network device sends a path switch request message to the core network element, where the path switch request message is used to request the core network The network element switches the transmission path of the MBS service data of the terminal device; the target access network device receives a path switching confirmation message from the core network network element, and the path switching confirmation message includes the second SN information.

In a possible design, the first SN is PDCP SN, general packet radio service tunneling protocol (general packet radio service tunneling protocol, GTP)-user plane (user, U) SN or quality of service flow ID (quality of service flow ID). , QFI)SN.

In a possible design, there is a preset mapping relationship between PDCP SN and GTP-US SN; or, there is a preset mapping relationship between the combination of QFI and QFI SN and PDCP SN. Based on this design, it is ensured that the data sent by the core network to the source access network device and the target access network device with the same content has the same PDCP SN, avoiding data packet loss during the switching process of the terminal device, and ensuring lossless or minimal packet loss switching. .

In a fourth aspect, a data transmission method is provided, the method comprising: a source access network device sending a handover request message to a target access network device, where the handover request message is used to request handover of a terminal device from the source access network device to the target access network device network access device; the source access network device receives fourth information from the target access network device, where the fourth information is used to instruct the source access network device to forward the terminal device corresponding to at least one SN before the first SN to the target access network device MBS business data.

Based on the above technical solution, the target access network device sends fourth information to the source access network device to instruct the source access network device to forward the information of the terminal device corresponding to at least one SN before the first sequence number SN to the target access network device. MBS service data reduces unnecessary data forwarding between base stations in handover scenarios.

In a possible design, the first SN is a PDCP SN, a GTP-US SN, or a QFI SN.

A fifth aspect provides a communication device, the communication device includes a PDCP entity, a first RLC entity and a second RLC entity, the first RLC entity and the second RLC entity are respectively associated with the PDCP entity, and the first RLC entity is used to support PTM The transmission mode sends the MBS service data, the second RLC entity is used to support the PTP transmission mode to send the MBS service data, and the first RLC entity and the second RLC entity are associated to the same MRB. The first RLC entity is configured to send at least one RLC SDU to at least one terminal device including the first terminal device. The second RLC entity is configured to receive first information from the first terminal device, where the first information is used to indicate the RLC sequence number SN of the first RLC SDU, and the first RLC SDU belongs to at least one RLC SDU that is not successfully received in the RLC SDU . The second RLC entity is further configured to submit second information to the first RLC entity or the PDCP entity, where the second information indicates the RLC SN of the first RLC SDU. The first entity is configured to send the first RLC SDU to the first terminal device, where the first entity is the first RLC entity or the second RLC entity.

In a possible design, the first entity is the first RLC entity; before the first entity is used to send the first RLC SDU to the first terminal device, the first RLC entity is also used to obtain the first RLC entity according to the second information. One RLC SDU.

In a possible design, the first entity is the second RLC entity; before the first entity is used to send the first RLC SDU to the first terminal device, the first RLC entity is also used to send the second RLC SDU according to the second information. The RLC entity delivers the first RLC SDU.

In a possible design, before the first entity is configured to send the first RLC SDU to the first terminal device, the PDCP entity is configured to deliver the first RLC SDU to the first entity according to the second information.

In a possible design, the second information includes the RLC SN of the first RLC SDU. The PDCP entity is specifically used to determine the PDCP SN of the first PDCP PDU according to the RLC SN of the first RLC SDU and the preset mapping relationship, and the preset mapping relationship is used to indicate the mapping relationship between the PDCP SN and the RLC SN; The PDCP SN of a PDCP PDU obtains the first PDCP PDU, which is the first RLC SDU; and submits the first RLC SDU to the first entity.

In a possible design, the second information includes the PDCP SN of the first PDCP PDU. The PDCP entity is specifically configured to obtain the first PDCP PDU according to the PDCP SN of the first PDCP PDU, and the first PDCP PDU is the first RLC SDU; and submit the first RLC SDU to the first entity.

In a possible design, the second RLC entity is also used to determine the PDCP SN of the first PDCP PDU according to the RLC SN of the first RLC SDU and a preset mapping relationship, and the preset mapping relationship is used to indicate the PDCP SN and the RLC. Mapping relationship between SNs.

In a possible design, the communication device further includes a communication module. The communication module is configured to send first indication information to the first terminal device, where the first indication information is used to instruct the first terminal device to receive the starting data sequence number information of the MBS service data.

In a possible design, the communication module is further configured to send MRB configuration information to the first terminal device, where the MRB configuration information is used to configure the MBS session between the first terminal device and the access network device.

In a sixth aspect, a communication apparatus is provided, the communication apparatus includes a third RLC entity and a fourth RLC entity. The third RLC entity is used to receive the MBS service data sent by the access network device in the PTM mode; the fourth RLC entity is used to receive the MBS service data sent by the access network device in the PTP mode; the third RLC entity and the fourth RLC entity Entities are associated to the same MRB. The third RLC entity is configured to receive at least one RLC SDU from the access network device. The fourth RLC entity is configured to receive third information from the third RLC entity, where the third information indicates the RLC SN of the first RLC SDU in the at least one RLC SDU. The fourth RLC entity is further configured to generate first information according to the third information; send the first information to the access network device, where the first information is used to indicate the RLC SN of the first RLC SDU, and the first RLC SDU belongs to at least one RLC SDU RLC SDUs that were not successfully received in .

In a possible design, the third RLC entity is also used to determine that the first RLC SDU is not successfully received; generate the third information according to the RLC SN of the first RLC SDU.

In a possible design, the third RLC entity is further configured to determine that the second RLC SDU in the at least one RLC SDU is successfully received; and generate the third information according to the RLC SN of the second RLC SDU.

In a possible design, the fourth RLC entity is further configured to receive the first RLC SDU from the access network device after sending the first information to the access network device.

In a possible design, the third RLC entity is further configured to receive the first RLC SDU from the access network device.

In a possible design, the third RLC entity is further configured to indicate to the fourth RLC entity that the first RLC SDU is successfully received.

In a possible design, the communication device further includes a communication module. The communication module is configured to receive first indication information from the access network device, where the first indication information is used to instruct the first terminal device to receive the starting data sequence number information of the MBS service data.

In a possible design, the communication module is further configured to receive MRB configuration information from the access network device, where the MRB configuration information is used to configure the MBS session between the first terminal device and the access network device.

In a seventh aspect, a communication device is provided, comprising: a processing module and a communication module connected to the processing module. The communication module is configured to receive a handover request message from the source access network device, where the handover request message is used to request the terminal device to be handed over from the source access network device to the target access network device. The processing module is configured to generate fourth information, where the fourth information is used to instruct the source access network device to forward the MBS service data of the terminal device corresponding to at least one SN before the first sequence number SN to the target access network device. The communication module is further configured to send fourth information to the source access network device.

In a possible design, the communication module is further configured to obtain the second SN information from the core network element before sending the fourth information to the source access network device; the processing module is further configured to obtain the second SN information according to the second SN information. , and determine the first SN information. The first SN information is used to indicate the first SN.

In a possible design, the communication module is further configured to send a path switching request message to the core network element, and the path switching request message is used to request the core network element to switch the transmission path of the MBS service data of the terminal device; The element receives the path switch confirmation message, and the path switch confirmation message includes the second SN information.

In a possible design, the first SN is a PDCP SN, a GTP-US SN, or a QFI SN.

In a possible design, there is a preset mapping relationship between PDCP SN and GTP-US SN; or, there is a preset mapping relationship between the combination of QFI and QFI SN and PDCP SN.

In an eighth aspect, a communication device is provided, comprising: a processing module and a communication module connected to the processing module. The processing module is configured to generate a handover request message, where the handover request message is used to request handover of the terminal device from the source access network device to the target access network device. The communication module is used for sending a handover request message to the target access network device. The communication module is further configured to receive fourth information from the target access network device, where the fourth information is used to instruct the source access network device to forward the information of the terminal device corresponding to at least one SN before the first sequence number SN to the target access network device. MBS business data.

In a possible design, the first SN is a PDCP SN, a GTP-US SN, or a QFI SN.

In a ninth aspect, a communication device is provided, the communication device includes a processor and a transceiver, and the processor and the transceiver are used to implement the method provided by any one of the above-mentioned first to fourth aspects or any design thereof. The processor is configured to perform processing actions in the corresponding method, and the transceiver is configured to perform the receiving/transmitting actions in the corresponding method.

In a tenth aspect, a computer-readable storage medium is provided, the computer-readable storage medium stores computer instructions that, when executed on a computer, cause the computer to perform any one of the first to fourth aspects or its Either way the design provides.

In an eleventh aspect, there is provided a computer program product comprising computer instructions, which, when the computer instructions are executed on a computer, cause the computer to perform the method provided by any one of the first aspect to the fourth aspect.

A twelfth aspect provides a chip, including: a processing circuit and a transceiver pin, where the processing circuit and the transceiver pin are used to implement the method provided by the first aspect to the fourth aspect or any design thereof. Wherein, the processing circuit is used for executing the processing actions in the corresponding method, and the transceiver pins are used for executing the actions of receiving/transmitting in the corresponding method.

A thirteenth aspect provides a communication system, comprising: the communication device provided by the fifth aspect or any design thereof, and the communication device provided by the sixth aspect or any design thereof.

A fourteenth aspect provides a communication system, comprising: the communication device provided by the seventh aspect or any design thereof, and the communication device provided by the eighth aspect or any design thereof.

It should be noted that, for the technical effect brought by any design in the fifth aspect to the fourteenth aspect, reference may be made to the technical effect brought by the corresponding design in any one of the first aspect to the fourth aspect, here No longer.

Description of drawings

FIG. 1 is a schematic diagram of an MBS service data transmission process according to an embodiment of the present application;

2(a) is a schematic diagram of an air interface protocol stack provided by an embodiment of the present application;

2(b) is a schematic diagram of transmission of MBS service data through an air interface protocol stack according to an embodiment of the present application;

3 is a schematic diagram of a sending window and a receiving window provided by an embodiment of the present application;

FIG. 4 is a schematic diagram of the architecture of a 5G communication system provided by an embodiment of the present application;

FIG. 5 is a schematic diagram of a CU-DU architecture provided by an embodiment of the present application;

FIG. 6 is a schematic diagram of still another CU-DU architecture provided by an embodiment of the present application;

FIG. 7 is a schematic diagram of another CU-DU architecture provided by an embodiment of the present application;

FIG. 8 is a schematic structural diagram of a protocol stack of an access network device according to an embodiment of the present application;

9 is a flowchart of a data transmission method provided by an embodiment of the present application;

FIG. 10(a) is a schematic structural diagram of a protocol stack of another access network device according to an embodiment of the present application;

FIG. 10(b) is a schematic structural diagram of a protocol stack of another access network device according to an embodiment of the present application;

FIG. 11(a) is a schematic diagram of the architecture of a protocol stack of a terminal device according to an embodiment of the present application;

FIG. 11(b) is a schematic diagram of transmission of MBS service data through an air interface protocol stack according to an embodiment of the present application;

12 is a flowchart of another data transmission method provided by an embodiment of the present application;

FIG. 13(a) is a schematic diagram of the architecture of a protocol stack of a terminal device according to an embodiment of the present application;

FIG. 13(b) is a schematic diagram of transmission of MBS service data through an air interface protocol stack according to an embodiment of the present application;

14 is a flowchart of another data transmission method provided by an embodiment of the present application;

15 is a flowchart of another data transmission method provided by an embodiment of the present application;

16 is a flowchart of another data transmission method provided by an embodiment of the present application;

17 is a flowchart of another data transmission method provided by an embodiment of the present application;

18 is a schematic diagram of a handover process provided by the related art;

FIG. 19 is a flowchart of another data transmission method provided by an embodiment of the present application;

20 is a flowchart of another data transmission method provided by an embodiment of the present application;

21 is a flowchart of another data transmission method provided by an embodiment of the present application;

22 is a flowchart of another data transmission method provided by an embodiment of the present application;

FIG. 23 is a schematic structural diagram of a communication device according to an embodiment of the present application;

FIG. 24 is a schematic structural diagram of another communication apparatus provided by an embodiment of the present application.

Detailed ways

In the description of this application, unless otherwise stated, "/" means "or", for example, A/B can mean A or B. In this article, "and/or" is only an association relationship to describe the associated objects, which means that there can be three kinds of relationships, for example, A and/or B, which can mean that A exists alone, A and B exist at the same time, and B exists alone these three situations. Further, "at least one" means one or more, and "plurality" means two or more. The words "first" and "second" do not limit the quantity and execution order, and the words "first", "second" and the like do not limit certain differences.

It should be noted that, in this application, words such as "exemplary" or "for example" are used to represent examples, illustrations or illustrations. Any embodiment or design described in this application as "exemplary" or "such as" should not be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present the related concepts in a specific manner.

In the description of this application, "indication" may include direct indication and indirect indication, as well as explicit indication and implicit indication. The information indicated by a certain piece of information is called information to be indicated, and in the specific implementation process, there are many ways to indicate the information to be indicated. For example, the information to be indicated may be directly indicated, wherein the information to be indicated itself or an index of the information to be indicated, etc. For another example, the information to be indicated may also be indirectly indicated by indicating other information, wherein there is an association relationship between the other information and the information to be indicated. For another example, only a part of the information to be indicated may be indicated, while other parts of the information to be indicated are known or agreed in advance. In addition, the indication of specific information can also be implemented by means of the arrangement order of each information pre-agreed (for example, stipulated by the protocol), thereby reducing the indication overhead to a certain extent.

The technical solutions provided in the embodiments of the present application can be applied to various communication systems, for example, a long term evolution (LTE) communication system, a new radio (NR) communication system using 5G communication technology, a future evolution system or A variety of communication fusion systems and so on. The technical solutions provided in this application can be applied to various application scenarios, such as machine to machine (M2M), macro-micro communication, enhanced mobile broadband (eMBB), ultra-reliable and ultra-low latency Communication (ultra-reliable & low latency communication, uRLLC) and massive IoT communication (massive machine type communication, mMTC) and other scenarios. These scenarios may include, but are not limited to: a communication scenario between a terminal device and a terminal device, a communication scenario between a network device and a network device, a communication scenario between a network device and a terminal device, and the like. The following description is given by taking an example of application in a communication scenario between a network device and a terminal device.

In this embodiment of the present application, the access network device may be a base station or a base station controller for wireless communication. For example, the base station may include various types of base stations, such as a micro base station (also referred to as a small cell), a macro base station, a relay station, an access point, etc., which are not specifically limited in this embodiment of the present application. Wherein, the base station can be a global system for mobile communication (GSM), a base station (base transceiver station, BTS) in a code division multiple access (code division multiple access, CDMA), a broadband code division multiple access ( Wideband code division multiple access (WCDMA) in the base station (node B), long term evolution (long term evolution, LTE) in the evolved base station (evolutional node B, eNB or e-NodeB), Internet of things (internet of things, IoT) ) or an eNB in a narrow band-internet of things (NB-IoT), a gNB in a future 5G mobile communication network or a future evolved public land mobile network (PLMN), an embodiment of the present application There are no restrictions on this.

In this embodiment of the present application, the terminal device is a device with a wireless transceiver function. Terminal equipment can be deployed on land, including indoor or outdoor, handheld or vehicle; can also be deployed on water (such as ships, etc.); can also be deployed in the air (such as aircraft, balloons and satellites, etc.). The terminal equipment may be user equipment (user equipment, UE). The UE includes a handheld device, a vehicle, an in-vehicle device, a wearable device or a computing device with a wireless communication function. Exemplarily, the UE may be a mobile phone, a tablet computer, or a computer with a wireless transceiver function. The terminal device may also be a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal device in industrial control, a wireless terminal device in unmanned driving, and a wireless terminal in telemedicine. equipment, wireless terminal equipment in smart grid, wireless terminal equipment in smart city, wireless terminal equipment in smart home, etc. In this embodiment of the present application, the apparatus for implementing the function of the terminal device may be the terminal device, or may be an apparatus capable of supporting the terminal device to implement the function, such as a chip system. In this embodiment of the present application, the chip system may be composed of chips, or may include chips and other discrete devices. In the embodiments of the present application, the technical solutions provided by the embodiments of the present application are described by taking the device for realizing the function of the terminal device as the terminal device as an example.

In addition, the network architecture and service scenarios described in the embodiments of the present application are for the purpose of illustrating the technical solutions of the embodiments of the present application more clearly, and do not constitute limitations on the technical solutions provided by the embodiments of the present application. With the evolution of the network architecture and the emergence of new service scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

In order to facilitate the understanding of those skilled in the art, some technical terms are first introduced below.

1. MBS service transmission architecture

Multicast broadcast service (multicast and broadcast service, MBS) is a service for multiple terminal equipment (user equipment, UE), such as live broadcast service, public safety service, batch software update service, etc.

In this embodiment of the present application, multicast is a specific form of multicast, so multicast may also be called multicast.

Exemplarily, FIG. 1 shows the transmission process of MBS service data. As shown in FIG. 1 , the data server sends the MBS service data to the core network, then the core network sends the MBS service data to the base station, and finally the base station sends the MBS service data to at least one UE receiving the MBS service.

Among them, when the MBS service data is sent from the core network to the base station, there are two basic transmission modes. One is the 5G core network (5G Core, 5GC) shared MBS service delivery method (5GC shared MBS traffic delivery method), and the other is the 5GC individual MBS service delivery method (5GC individual MBS traffic delivery method). This paper takes the 5GC shared MBS service transmission mode as an example. The MBS service data is transmitted through a common general packet radio service tunneling protocol (GTP)-user plane (user, U) channel between the core network and the base station. transport, and each MBS session uses one GTP-U channel. It should be noted that an MBS session includes one or more quality of service (quality of service, QoS) flows, and these QoS flows of an MBS are mapped to one or more MBS radio bearers (MBS radio bearers, MRB) over the air interface. Generally, different MRBs have different QoS requirements or belong to different MBS sessions. QoS flows of different MBS sessions cannot be mapped to the same MRB.

For the base station supporting MBS, when the MBS service data is sent from the base station to the UE, there are two transmission modes: the first is the PTM (point to multi-point, point-to-multipoint) transmission mode; the second is PTP (point to point, point to point) transmission method. The PTM transmission mode may also be called a group scheduling mode or a multicast transmission mode. Here, the base station supporting MBS can support the above two transmission modes.

(1) PTM transmission method

The PTM transmission mode refers to a transmission mode in which a certain service sends data to multiple terminal devices simultaneously through a network device. When using PTM transmission, for the same data, multiple terminal devices receive the same data simultaneously in the process of sending by a network device (eg, a base station).

In the LTE system, PTM is mainly divided into two modes: Multicast Broadcast Single Frequency Network (MBSFN) mode and Single Cell Point to Multipoint (SC-PTM) mode . Among them, the MBSFN mode means that multiple mutually synchronized cells (belonging to different base stations) in the MBSFN area transmit the same information to multiple terminal devices at the same time, so as to improve the strength of the signal received by the terminal device and eliminate the interference between cells. The SC-PTM mode means that the MBS service is transmitted only through one cell (eg, one base station), and one network device performs group scheduling on multiple terminal devices at the same time. PTM in NR is similar to SC-PTM.

Optionally, the sending device (not limited to the base station) using the PTM transmission mode to send means: when the sending device sends the transport block (transport block, TB) corresponding to the protocol data unit (protocol data unit, PDU), the packet wireless network temporary identifier is used. Group radio network temporary identifier (G-RNTI) scrambles the physical downlink control channel (PDCCH) and the physical downlink shared channel (PDSCH) respectively.

Optionally, receiving by the receiving apparatus in the PTM transmission mode means that the receiving apparatus descrambles and receives the PDCCH and PDSCH according to the G-RNTI to obtain the PDU.

(2) PTP transmission method

The PTP transmission mode refers to the transmission mode in which a certain service sends data to a terminal device through a network device. When using PTP transmission, for the same data, a terminal device receives at the same time in the process of sending by a network device (eg, a base station).

Optionally, the sending device using PTP transmission means that: when the sending device sends the TB corresponding to the PDU, the PDCCH and PDSCH are scrambled by using a cell network temporary identifier (C-RNTI) respectively.

Optionally, receiving by the receiving apparatus in the PTP transmission mode means that the receiving apparatus descrambles and receives the PDCCH and PDSCH according to the C-RNTI to obtain the PDU.

2. Protocol stack of wireless access network

Access network equipment and terminal equipment have a certain protocol stack structure for mutual communication.

Figure 2(a) shows a protocol stack structure of an access network device and a terminal device. As shown in Figure 2(a), the protocol stack of the access network device or the terminal device may include a service data adaptation protocol (SDAP) layer, a packet data convergence protocol (PDCP) layer, Radio link control (radio link control, RLC) layer, media access control (media Access Link control, MAC) and physical layer (physical layer, PHY) and so on.

Among them, the physical layer is located at the lowest layer (ie, layer 1). The MAC layer, the RLC layer, the PDCP layer, and the SDAP layer belong to the second layer (ie, layer 2).

The SDAP layer is responsible for the mapping of QoS flows to radio bearers. The PDCP layer is responsible for functions such as data transmission, encryption, integrity protection, and header compression on the user plane and control plane. The RLC layer is responsible for functions such as segment reassembly and automatic repeat request (ARQ); the MAC layer completes functions such as data scheduling and mapping between logical channels and transport channels. The PHY layer is responsible for functions such as encoding and decoding, modulation, demodulation, and multi-antenna mapping.

Based on the protocol stack structure shown in Figure 2(a), the access network device and the terminal device will create an SDAP entity for each MBS session and a PDCP entity for each MRB. Each PDCP entity may correspond to one or more RLC entities. It should be understood that each RLC entity corresponds to one logical channel.

Exemplarily, the flow of MBS service data transmission through the protocol stack of the wireless access network is described with reference to FIG. 2(b). The MBS service data first arrives at the SDAP layer of the access network device, and the SDAP layer delivers the MBS service data to the corresponding PDCP layer according to the mapping relationship between the QoS flow and the MRB determined by the access network device. After being processed by the PDCP layer of the access network device, the MBS service data is sequentially delivered to the RLC layer and the MAC layer. After being processed by the RLC layer and the MAC layer, it is sent from the physical layer and transmitted to the terminal device through the air interface. Each protocol layer of the terminal device sequentially processes the data packets according to the processing sequence opposite to that of the access network device, so as to receive the MBS service data.

It should be understood that MBS service data needs to be processed by each layer at each layer, and each layer has corresponding functional entities to perform corresponding functions, such as the PDCP entity of the PDCP layer, or the RLC entity of the RLC layer.

3. RLC entity transmission mode

RLC entity transmission modes include the following three:

(1) Transparent Mode (TM): The RLC entity does not perform any processing on the data, and only provides the pass through function of the data. The RLC entity that adopts this transmission mode is called TM RLC entity, or TM entity for short.

(2) Unacknowledged Mode (UM): The RLC entity provides all RLC functions except retransmission and re-segmentation. Even in the case of packet transmission errors, the RLC entity in this transmission mode does not retransmit function, can only provide an unreliable transmission service. An RLC entity that adopts this transmission mode is called a UM RLC entity, or UM entity for short.

(3) Acknowledged Mode (AM): The RLC entity provides all RLC functions, including the ARQ function, and the RLC entity provides a reliable transmission service through error detection and retransmission. An RLC entity that adopts this transmission mode is called an AM RLC entity, or AM entity for short.

4. Automatically request to resend ARQ

ARQ is one of the important functions of the RLC acknowledgment mode. ARQ can detect the lost PDU and request retransmission by checking the sequence number of the received PDU.

There are three basic types of traditional ARQ:

(1) Stop-And-Wait (SAW) ARQ: In stop-and-wait ARQ, after the data frame is sent, the sender waits for a status report from the receiver, and if the status report message is successfully sent, the subsequent data is sent frame, otherwise retransmit the data frame.

In stop-and-wait ARQ, the size of the sending window and the receiving window are both 1. The sender must stop and wait for the acknowledgement from the receiver after sending a frame, and only continue to send the next frame when the receiver confirms the correct reception.

(2) Go-Back-N (GBN) ARQ: The sender does not need to wait for the receiver's response, and continues to send multiple frames. If an error occurs in the frame that has been sent, then from the one with the error The beginning of the frame and all subsequent frames are all retransmitted.

(3) Selective repeat (selective repeat) ARQ: The sender does not need to wait for the receiver's response, and continues to send multiple frames. If an error occurs in the frame that has been sent, the sender will only re-send the one with the error. frame.

The RLC acknowledgement mode in NR is similar to that in LTE, but reordering to ensure in-order delivery is not supported in NR. Removing in-order delivery from RLC helps reduce overall latency because subsequent packets can be forwarded immediately without having to wait for previously lost packets to be retransmitted to higher layers. This also has positive implications for reducing the memory requirements of the buffer. The RLC protocol in LTE supports in-order delivery, and an RLC SDU cannot be forwarded to the upper layer until all previous SDUs have been received correctly. For example, because an SDU is lost due to an instantaneous interference burst, the SDU can only be delivered after a long period of blocking.

The RLC entity in acknowledged mode is bidirectional, i.e. data can flow bidirectionally between two peer entities. The entity receiving the SDU needs to feed back an acknowledgment to the entity sending the SDU. The receiver provides the information of the missing SDU to the sender in the form of a status report. The status report can be sent by the receiver actively or requested by the sender. In order to track the SDU in transmission, the sequence number is used in the header.

5. Send window and receive window

In acknowledgment mode, the RLC entity maintains two windows, namely the sending window and the receiving window. For the sender, only the SDUs located in the sending window are allowed to be sent, and the SDUs whose sequence numbers are smaller than the starting point of the window are SDUs that have been confirmed by the RLC entity of the receiver to be successfully received. For the receiving end, the receiving end can only receive SDUs whose sequence numbers are within the receiving window. Since the receiving end only needs to submit one SDU to the upper layer for the same data, the receiving end will also discard the duplicate SDU.

The sending window and the receiving window are described below with reference to FIG. 3 . It should be understood that only the receiving window of the RLC entity of the receiving end is shown in FIG. 3 , and the sending window is not shown. Only the sending port of the RLC entity of the sending end is shown in FIG. 3, and the receiving window is not shown.

At time t0, the sender has sent SDUs with sequence numbers n and before n, wherein the SDUs before n-1 and n-1 have been acknowledged by the receiver. Therefore, the sending window of the sender starts from n, the first unacknowledged SDU. The receiving window of the receiving end starts from n+1, that is, the next SDU expected to be received.

At time t1, the sender continues to transmit SDUs. Exemplarily, since the sending window starts from n, the sending end may send SDU n+1 and SDU n+2 to the receiving end. It should be understood that SDU X in this embodiment of the present application represents an SDU with a serial number of X, where X is any positive integer or 0.

Assuming that the receiving end successfully receives SDU n+2, but fails to receive SDU n+1, the receiving end will not update the receive window. The receiving port can start the t-Reassembly timer. After the t-Reassembly timer expires, the lost SDU n=1 has not been successfully received, and the receiving end can request the transmitting end to retransmit SDU n=1.

At time t2, assuming that the receiving end successfully receives SDU n+1 and SDU n+2, the receiving end can update the starting point of the receiving window, so that the starting point of the receiving end's receiving window starts from n+3.

6. Communication system

A communication system generally includes a core network and an access network. Exemplarily, FIG. 4 shows a schematic diagram of the architecture of a 5G communication system provided by an embodiment of the present application. As shown in Figure 4, the 5G communication system includes a next generation radio access network (NG-RAN) and a 5G core network (5G core network, 5GC).

5GC includes various core network equipment, such as access and mobility management function (AMF), user plane function (UPF), session management function (session management function, SMF) etc.

AMF belongs to the core network entity and is mainly responsible for the mobility management processing part, such as: access control, mobility management, attachment and detachment, and SMF selection and other functions. When the AMF provides services for a session in a terminal device, it provides storage resources of the control plane for the session to store the session ID, the SMF ID associated with the session ID, and the like.

SMF is mainly used for session management, Internet Protocol (IP) address allocation and management of terminal devices, selection of endpoints that can manage user plane functions, policy control, or charging function interfaces, and downlink data notification.

UPF can be used for packet routing and forwarding, or QoS processing of user plane data. User data can be accessed to a data network (DN) through this network element.

The above-mentioned AMF, SMF and UPF are only a name, and do not constitute a limitation on the device itself. It can be understood that, in a 5G network and other future networks, AMF, SMF, and UPF may also be other names, which are not specifically limited in this embodiment of the present application. For example, the UPF may also be referred to as a UPF network element or a UPF entity, which will be uniformly described here, and will not be repeated below.

Optionally, the core network device may be implemented by one device, or jointly implemented by multiple devices, or may be a functional module in one device, which is not specifically limited in this embodiment of the present application. It can be understood that the above-mentioned functional modules may be network elements in hardware devices, software functional modules running on dedicated hardware, or virtualized functional modules instantiated on a platform (eg, a cloud platform).

The access network includes access network equipment. Taking the access network device as a gNB as an example, in a communication system, there is an interface between two gNBs, which is called an Xn interface in this paper. There is an interface between gNB and 5GC, which is called Ng interface in this paper. For example, the NG2 interface is between the gNB and the AMF, and the NG3 interface is between the gNB and the UPF.

7. Centralized unit (CU)-distributed unit (DU) architecture

As shown in Figure 5, the gNB can adopt the CU-DU architecture. That is, the gNB is composed of a CU and at least one DU. In this case, some functions of the gNB are deployed on the CU, and another part of the functions of the gNB are deployed on the DU. Multiple DUs can share the same CU for cost savings and easy expansion.

CU and DU are functionally divided according to the protocol stack. As an implementation, the CU is deployed with a radio resource control (RRC) layer, a PDCP layer, and a service data adaptation protocol (SDAP) layer in the protocol stack; DU is deployed with the protocol stack. RLC layer, media access control (media access control, MAC) layer, and physical layer (physical layer, PHY). Thus, the CU has the processing capabilities of RRC, PDCP and SDAP. DU has the processing capability of RLC, MAC and PHY. It can be understood that the division of the above functions is only an example, and does not constitute a limitation on the CU and the DU. That is to say, there may also be other functional division manners between the CU and the DU, which are not described in detail in this embodiment of the present application.

The CU and DU are connected through the F1 interface. The CU represents the gNB is connected to the core network through the NG interface, the CU represents the gNB is connected to other gNBs through the Xn interface, and the CU can also represent the gNB to connect to other eNBs through the X2 interface to perform dual connectivity operations. It can be understood that the above interfaces are all logical interfaces. In a 5G network and other future networks, the above interface may also have other names, which are not limited in this embodiment of the present application.

Further, as shown in FIG. 6 , the CU can also be divided into CU-CP and CU-UP. The CU-CP is responsible for the control plane function, mainly including the RRC and the PDCP (ie PDCP-C) corresponding to the control plane. PDCP-C is mainly responsible for encryption and decryption of control plane data, integrity protection, and data transmission. The CU-UP is responsible for the user plane function, mainly including SDAP and the PDCP (ie PDCP-U) corresponding to the user plane. SDAP is mainly responsible for processing the data of the core network and mapping the flow to the bearer. PDCP-U is mainly responsible for data plane encryption and decryption, integrity protection, header compression, serial number maintenance, data transmission, etc. Of course, there is also a possible implementation that PDCP-C is also in CU-UP.

The CU-CP and CU-UP are connected through the E1 interface. CU-CP represents that the gNB is connected to the core network through the NG interface. The F1-C is connected to the DU through the F1 interface control plane. The CU-UP is connected through the F1 interface user plane, namely the F1-U and the DU.

Optionally, as shown in FIG. 7 , one DU can be connected to one or more CU-UPs. One CU-UP can connect one or more DUs. A DU can only be connected to one CU-CP. One CU-CP can connect one or more DUs. Only one CU-CP can be connected to a CU-UP. One CU-CP can be connected to one or more CU-UPs.

The above is an introduction to the technical terms involved in the embodiments of the present application, which will not be repeated below.

FIG. 8 is a schematic structural diagram of a protocol stack of an access network device according to an embodiment of the present application. It can be understood that the access network device may be other communication devices, which is not limited in this application.

As shown in FIG. 8 , the access network device is configured with a PDCP entity, a first RLC entity and a second RLC entity. Wherein, the first RLC entity and the second RLC entity are associated with the PDCP entity, and the first RLC entity and the second RLC entity are associated with related MRBs.

The first RLC entity is used to support the PTM transmission mode to send MBS service data. That is, the first RLC entity is used to send MBS service data to at least one terminal device.

The second RLC entity is used to support the PTP transmission mode to send MBS service data. That is, the second RLC entity is used to send MBS service data to a terminal device (the first terminal device is taken as an example below). It should be understood that, for one MRB, there may be one or more second RLC entities on the device side of the access network. Each second RLC entity corresponds to one terminal device.

Exemplarily, for an access network device, the first RLC entity may be referred to as an mRLC entity, and the second RLC entity may be referred to as a pRLC entity.

It should be understood that the access network device may have other protocol layers not shown in FIG. 8 , such as SDAP layer, MAC layer, physical layer, etc., which are not limited.

When the access network device adopts the architecture shown in Figure 8, for the same MBS service, the access network device can flexibly switch to use the PTP transmission mode or the PTM transmission mode to adapt to different application scenarios and obtain better transmission Effect.

In an ARQ technology, an RLC entity supporting AM mode may request to retransmit the unsuccessfully transmitted data if it is determined that a piece of data has not been successfully transmitted. However, when the access network device using the architecture shown in FIG. 8 adopts the PTM transmission mode, the first RLC entity in the access network device does not support the AM mode, and the above ARQ cannot obtain retransmission data from the PDCP layer. That is, for the scenario in which the access network equipment adopts the PTM transmission mode to transmit the MBS service data, the above ARQ technology cannot be directly applied, so that the highly reliable transmission of the MBS service data cannot be guaranteed. This paper mainly considers how the first RLC entity and the second RLC entity on the access network device side interact to realize the RLC ARQ function.

In order to solve the above technical problem, an embodiment of the present application provides a data transmission method, which can be applied to an access network device using the architecture shown in FIG. 8 . As shown in Figure 9, the data transmission method includes the following steps:

S101. The first RLC entity sends at least one RLC SDU to at least one terminal device including the first terminal device.

Among them, at least one RLC SDU belongs to MBS service data.

As a possible implementation manner, the PDCP entity delivers at least one PDCP PDU (that is, an RLC SDU) to the first RLC entity. The first RLC entity sends at least one RLC SDU to at least one terminal device in a PTM transmission manner.

It should be understood that sending the RLC SDU to the at least one terminal device by the first RLC entity may be specifically implemented as: the first RLC entity adds an RLC header to the RLC SDU to generate an RLC PDU; the first RLC entity sends the RLC PDU to the at least one terminal device.

For convenience of description, the working mode adopted by the first RLC entity is hereinafter referred to as an improved UM mode.

In this embodiment of the present application, the first RLC entity that adopts the improved UM mode may assign an RLC SN to each RLC SDU in sequence.

Optionally, the first RLC entity may set a discard timer (discard timer) for each RLC SDU. Therefore, after the discard timer corresponding to the RLC SDU times out, the first RLC entity discards the RLC SDU.

Optionally, the first RLC entity discards the RLC SDU after confirming that an RLC SDU is successfully transmitted through a mechanism such as an RLC status report, or after receiving a discarding instruction for the RLC SDU from the PDCP entity.

S102. The second RLC entity receives the first information from the first terminal device.

The first information is used to indicate the reception status of at least one RLC SDU. That is, the first information is used to indicate whether each RLC SDU in the at least one RLC SDU is successfully received. For example, the first information may carry the RLC SN of each successfully received RLC SDU, or only carry the RLC SN of the unsuccessfully received RLC SDU, or other methods, which are not limited in the embodiments of the present application.

After the first RLC entity receives the first information (for example, RLC Status Report), for the "RLC SDUs that have been successfully received by the UE and whose RLC SN is x" indicated by the first information, there is no need to indicate "transmission success" to the PDCP layer. . Specifically, taking 3GPP TS38.322 v16.1.0 as an example, it can be modified as follows: the underlined part is the standard modification content:

When receiving a positive acknowledgement for an RLC SDU with SN=x, the transmitting side of an AM RLC entity shall:

send an indication to the upper layers of successful delivery of the RLC SDU except for an AM RLC entity associated to an MRB;

set TX_Next_Ack equal to the SN of the RLC SDU with the smallest SN,whose SN falls within the range TX_Next_Ack<=SN<=TX_Next and for which a positive acknowledgment has not been received yet.

Its translation is as follows:

After receiving an acknowledgment feedback for an RLC SDU with an SN of X, the AM RLC entity at the receiving end shall:

In addition to the AM RLC entity associated to the MRB, the RLC entity shall indicate to the upper layer that the RLC SDU has been successfully transmitted, set the TX_Next_Ack to the SN of the RLC SDU with the smallest SN whose SN is between TX_Next_Ack and not yet received Acknowledgment between TX_Next of acknowledgment.

Optionally, in this embodiment of the present application, the second RLC entity may adopt the AM mode.

Exemplarily, the first information is used to indicate the RLC SN of the first RLC SDU, and the first RLC SDU belongs to an RLC SDU that has not been successfully received in the above at least one RLC SDU.

Optionally, the first information is used to indicate the RLC SN of the first RLC SDU, and any one of the following designs may be adopted:

Design 1. The first information includes the RLC SN of the first RLC SDU.

Design 2. The first information includes the packet loss start RLC SN and the packet loss end RLC SN in the RLC SN set. Wherein, the RLC SN set includes the RLC SNs of a plurality of consecutively unsuccessfully received RLC SDUs. It should be understood that the plurality of unsuccessfully received RLC SDUs belong to the above at least one RLC SDU. The first RLC SDU is any one of the multiple unsuccessfully received RLC SDUs.

For example, the first RLC entity sends RLC SDUs of RLC SN#1-10. For the first terminal device, none of the RLC SDUs with RLC SNs 5, 6, 7, and 8 are successfully received. Therefore, the RLC SN at the start of the packet loss is RLC SN#5, and the RLC SN at the end of the packet loss is RLC SN#8. Thus, the first information may include RLC SN#5 and RLC SN#8.

It should be understood that the second RLC entity may determine the RLC SN of the first RLC SDU according to the first information.

Optionally, the first information may also indicate an RLC SDU that is successfully transmitted and has RLC SN=X. For the successfully transmitted RLC SDU, the second RLC entity may not indicate to the PDCP layer that the RLC SDU is successfully transmitted. where X is a positive integer.

S103. The first entity retransmits the first RLC SDU to the first terminal device.

The first entity may be the first RLC entity or the second RLC entity.

In each embodiment of the present application, if it is specially stated, after the access network device receives the first information, the first entity sends the first RLC SDU to the terminal device, which means that the first entity retransmits the first RLC SDU to the first terminal device. An RLC SDU is to retransmit the first RLC SDU sent by the first RLC entity, in other words, the content of the first RLC SDU retransmitted by the first entity is exactly the same as the first RLC SDU sent by the first entity before. For example, the receiving network device may buffer a backup of the first RLC SDU in a buffer when the first RLC entity sends the first RLC SDU, and when the first entity needs to send (retransmit) the first RLC SDU , and then obtain the first RLC SDU of the backup from the buffer. The embodiments of the present application do not impose any limitations on the above-mentioned backup method and acquisition method from the cache.

Taking the first entity as the second RLC entity as an example, before retransmitting the first RLC SDU, the second RLC entity obtains the first RLC SDU, and any one of the following methods 1 to 4 can be used:

Mode 1: The second RLC entity obtains the first RLC SDU from its own buffer area.

Optionally, before the above-mentioned step S101, that is, during the initial transmission of the at least one RLC SDU, the PDCP entity will copy the at least one RLC SDU into multiple copies and submit them to the first RLC entity and the second RLC SDU respectively. RLC entity. After acquiring the above at least one RLC SDU, the first RLC entity transmits the at least one RLC SDU according to step S101. The PDCP entity instructs the second RLC entity to buffer the at least one RLC SDU to prevent the second RLC entity from initially transmitting the at least one RLC SDU. When the first RLC SDU needs to be retransmitted, the second RLC SDU can find the first RLC SDU from its own buffer area according to the RLC SN of the first RLC SDU.

That is, when the second RLC entity receives the PDCP PDU (that is, the RLC SDU) sent by the PDCP for the first time, it is stored in its own buffer area and not sent. Only after receiving the first information fed back by the terminal device, the second RLC entity acquires the first RLC SDU and retransmits the first RLC SDU to the first terminal device.

Manner 2: The second RLC entity obtains the first RLC SDU from the shared buffer area. The shared buffer area is a buffer area that can be used by both the first RLC entity and the second RLC entity.

Exemplarily, the first RLC entity will buffer the at least one RLC SDU in the shared buffer area. When the first RLC SDU needs to be retransmitted, the second RLC SDU can find the first RLC SDU from the shared buffer area according to the RLC SN of the first RLC SDU.

Optionally, the second RLC entity may not initially transmit the data stored in the shared buffer area according to its own configuration or an instruction of the PDCP entity.

Manner 3: The second RLC entity obtains the first RLC SDU from the first RLC entity.

As a possible implementation manner, the second RLC entity submits second information to the first RLC entity, where the second information is used to indicate the first RLC SDU. The first RLC entity obtains the first RLC SDU according to the second information. The first RLC entity submits the first RLC SDU to the second RLC entity.

Manner 4: The second RLC entity obtains the first RLC SDU from the PDCP entity.

As a possible implementation manner, the second RLC entity submits second information to the PDCP entity, where the second information is used to indicate the first RLC SDU. The PDCP entity submits the first PDCP PDU (ie, the first RLC SDU) to the second RLC entity according to the second information.

It should be understood that PDCP PDU and RLC SDU are different names for the same data by different protocol layers.

It should be understood that the above manners 1 to 4 are only examples and do not constitute specific limitations.

Taking the first entity as the first RLC entity as an example, before retransmitting the first RLC SDU, the first RLC entity obtains the first RLC SDU, and any one of the following manners 5 to 6 may be used:

Manner 5: The first RLC entity obtains the first RLC SN.

As a possible implementation manner, the second RLC entity submits second information to the first RLC entity, where the second information is used to indicate the first RLC SN. The first RLC acquires the first RLC SDU according to the second information.

Manner 6: The first RLC entity obtains the first RLC SN from the PDCP entity.

As a possible implementation manner, the second RLC entity submits second information to the PDCP entity, where the second information is used to indicate the first RLC SDU. The PDCP entity submits the first PDCP PDU (ie, the first RLC SDU) to the first RLC entity according to the second information.

It should be understood that the above mode 5 or mode 6 is only an example, and does not constitute a specific limitation.

Optionally, for mode 3 or mode 5, the second information may include the RLC SN of the first RLC SDU.

Optionally, for mode 4 or mode 6, the second information may include the RLC SN of the first RLC SDU. Alternatively, the second information may include the PDCP SN of the first PDCP PDU.

Exemplarily, the second RLC entity may determine the PDCP SN of the first PDCP PDU according to the RLC SN of the first RLC SDU and the first preset mapping relationship. Wherein, the first preset mapping relationship is used to indicate the mapping relationship between the PDCP SN and the RLC SN. Furthermore, the second RLC entity may encapsulate the PDCP SN of the PDCP PDU corresponding to the first RLC SDU in the second information.

Exemplarily, if the second information includes the RLC SN of the first RLC SDU, the PDCP entity submits the first RLC SDU to the first entity according to the second information, which may be specifically implemented as: the PDCP entity submits the first RLC SDU according to the RLC SN of the first RLC SDU. , and the first preset mapping relationship to determine the PDCP SN of the first PDCP PDU corresponding to the first RLC SDU. After that, the PDCP entity obtains the first PDCP PDU according to the PDCP SN of the first PDCP PDU; the PDCP entity submits the first PDCP PDU (ie, the first RLC SDU) to the first entity.

Exemplarily, if the second information includes the PDCP SN of the first PDCP PDU, the PDCP entity submits the first RLC SDU to the first entity according to the second information, which may be specifically implemented as: the PDCP entity according to the PDCP SN of the first PDCP PDU , obtain the first PDCP PDU; the PDCP entity submits the first PDCP PDU (ie, the first RLC SDU) to the first entity.

In this embodiment of the present application, the first preset mapping relationship may be agreed in a protocol, or configured by a core network (or a network management) to an access network device. In order to support the first preset mapping relationship, the size (size) of the RLC SN should be less than or equal to the size of the PDCP SN to ensure that a PDCP SN can only derive a unique RLC SN. The above size may also be referred to as the length, that is, the number of bits occupied by the sequence number.

Exemplarily, the first mapping relationship may be: RLC SN=PDPC SN mod(max RLC SN+1). Among them, max RLC SN represents the maximum value that RLC SN can take.

In this embodiment of the present application, the first RLC entity and the second RLC entity perform the same RLC SN number on the PDCP PDU with the same content and submitted by the PDCP entity according to the first preset mapping relationship, thereby ensuring that the first RLC entity and the second RLC entity have the same RLC SN number. The RLC entity can obtain the same RLC SDU according to the same RLC SN, thereby ensuring accurate retransmission of the RLC SDU.

Optionally, in this embodiment of the present application, considering that the first RLC entity and the second RLC entity should use the same RLC SN size, and the RLC SN size is not larger than the PDCP SN size, the RLC SN size in this embodiment of the present application is Support 12bit.

It should be understood that the size of the RLC SN in the embodiments of the present application is not fixed. In the case where the size of the RLC SN in AM mode and/or UM mode is changed in the protocol, or the size of the PDCP SN is changed, the size of the RLC SN in this embodiment of the present application can also be changed.

Optionally, after the first RLC entity (or PDCP entity) receives the second information from the second RLC entity, the first RLC entity (or PDCP entity) may decide to adopt the multicast PTM method according to the preset retransmission rule. To retransmit the data, the unicast PTP method is used to retransmit the data.

It should be understood that the first RLC entity (or PDCP entity) decides to retransmit data in a multicast PTM manner, that is, the first RLC entity (or PDCP entity) decides to retransmit data by the first RLC entity. The first RLC entity (or PDCP entity) decides to use the unicast PTP mode to retransmit data, that is, the first RLC entity (or PDCP entity) decides to use the second RLC entity to retransmit data.

Exemplarily, the retransmission rule may be: if the first RLC entity (or PDCP entity) receives more than a preset number of second information within a preset time period, the first RLC entity (or PDCP entity) decides that the first The RLC entity retransmits the first RLC SDU; otherwise, the first RLC entity (or the PDCP entity) decides to retransmit the first RLC SDU by the second RLC entity.

Exemplarily, the retransmission rule may be: the first RLC entity (or PDCP entity) receives more than a preset number of information for triggering retransmission of data within a preset time period, then the first RLC entity (or PDCP entity) ) decides to retransmit the data by the first RLC entity; otherwise, the first RLC entity (or PDCP entity) decides to retransmit the data by the second RLC entity. It should be understood that the retransmitted data may be the RLC SDU sent by the first RLC entity in the previous period of time.

It should be understood that the information for triggering data retransmission submitted by the second RLC entity corresponding to different terminal devices to the first RLC entity or the PDCP entity may indicate that different RLC SDUs are not successfully received.

Based on the embodiment shown in FIG. 9 , the access network device transmits the MBS service data in the PTM manner through the first RLC entity, and obtains the receiving state of the terminal device for the MBS service data through the second RLC entity. Further, the access network device may determine the MBS service data that needs to be retransmitted, and retransmit the MBS service data through the first RLC entity or the second RLC entity. It can be seen that the technical solution provided by the present application can make the ARQ mechanism applied to the PTM transmission mode, and ensure the highly reliable transmission of MBS service data.

Optionally, the access network device may send a MAC CE to the terminal device to instruct the terminal device to switch between the PTM transmission mode and the PTP transmission mode.

For example, before step S101, the access network device may send the MAC CE for activating the PTM to at least one terminal device. After receiving the MAC CE for activating the PTM, the terminal device monitors the PDCCH and PDSCH scrambled by the G-RNTI, and performs corresponding steps according to the method shown in FIG. 9 .

For another example, the access network device may send a MAC CE for deactivating the PTM to one or more terminals. After receiving the MAC CE for deactivating the PTM, the terminal device stops monitoring the PDCCH and PDSCH scrambled by the G-RNTI, uses the PTP mode to monitor the PDCCH and PDSCH scrambled by the C-RNTI, and transmits the corresponding MBS service data. with retransmission.

Optionally, if the access network device only sends the MAC CE for deactivating the PTM to one terminal device at a time, the access network device can use C-RNTI to scramble and schedule the PDCCH and PDSCH corresponding to the MAC CE.

Optionally, if the access network device performs PTM deactivation for all terminal devices involved in the MRB, the access network device may use G-RNTI to scramble and schedule the PDCCH and PDSCH of the MAC CE.

Optionally, when the access network device adopts the CU-DU architecture, the protocol stack architecture shown in FIG. 8 may be specifically implemented as the protocol stack architecture shown in FIG. 10(a) or FIG. 10(b).

Exemplarily, as shown in FIG. 10( a ), for the same MBS service/MRB, the gNB-CU is configured with a PDCP entity, and the gNB-DU is configured with a first RLC entity and a second RLC entity. The first RLC entity and the second RLC entity use the same F1-U tunnel to communicate with the PDCP entity, that is, the first RLC entity and at least one second RLC entity share the F1-U tunnel. That is, the F1-U tunnel corresponds to the MBS service/MRB, the MBS service/MRB corresponds to the PDCP entity, the first RLC entity and the second RLC entity, so the F1-U tunnel corresponds to the first RLC entity.

Optionally, based on the architecture shown in FIG. 10(a), when the first RLC entity and the second RLC entity use the same FI-U tunnel to communicate with the PDCP entity, for the PDCP of the gNB-DU from the F-U tunnel from the gNB-CU For the data packet obtained by the entity, the gNB-DU can deliver the data packet to the second RLC entity corresponding to the terminal device according to the F1-U UE identifier of the terminal device carried in the F1-U header of the data packet. If the F1-U header does not carry any identification of the terminal device, the gNB-DU delivers the data packet to the first RLC entity corresponding to the F1-U tunnel.

Exemplarily, as shown in FIG. 10(b), the gNB-CU is configured with a PDCP entity, and the gNB-DU is configured with a first RLC entity and a second RLC entity. The first RLC entity and the second RLC entity use different F1-U tunnels respectively to communicate with the PDCP entity. That is, the first RLC entity and each second RLC entity correspond to respective F1-U tunnels, and the first RLC entity or the second RLC entity associated with the terminal device can be determined according to the F1-U tunnel.

It should be understood that the method (for example, the data transmission method shown in FIG. 9 ) in the embodiments of the present application applicable to the access network device using the architecture shown in FIG. 8 is also applicable to the method using FIG. 10( a ) or FIG. 10( b ) Access network equipment of the architecture shown.

Optionally, when the access network device adopts the CU-DU architecture, when the PDCP entity of the gNB-CU-UP submits the PDCP PDU to the first RLC entity and/or the second RLC entity in the gNB-DU, the gNB - The CU-UP uses the PDCP SN contained in the PDCP PDU carried in the GTP-U message of the F1-U tunnel to indicate to the first RLC entity and/or the second RLC entity the PDCP of the PDCP PDU transmitted by the F1-U tunnel SN. Therefore, the first RLC entity and/or the second RLC entity in the gNB-DU can map data of the same content (same PDCP SN) to the same RLC SN according to the PDCP SN and the first preset mapping relationship.

Optionally, when configuring the logical channel corresponding to the MRB, the CU can indicate to the DU the type of each radio bearer or logical channel on the DU side through the F1-C tunnel, so as to determine whether the data in the radio bearer or logical channel adopts the PTP mode. Or PTM mode for transmission.

Optionally, when configuring the logical channel corresponding to the MRB, the CU indicates to the DU the binding relationship between the logical channel on the DU side and the RNTI. For example, if a logical channel is bound to a C-RNTI, the PDSCH or PDCCH corresponding to the data of the logical channel is scrambled by the C-RNTI and sent in a unicast manner. For another example, if a certain logical channel is bound with G-RNTI, the PDSCH or PDCCH corresponding to the data of the logical channel is scrambled by G-RNTI, and sent by multicast or broadcast.

Exemplarily, one possibility is that the CU determines the PTP/PTM type corresponding to each radio bearer or logical channel. For example, the CU may include in the F1AP message (eg UE context setup/modification request) the MRB ID/data radio bearer (DRB) identity (identity, ID)/logical channel identity (LCID) and the corresponding PTP/PTM indication. For example, MRB/DRB ID#1 corresponds to PTP or C-RNTI, MRB/DRB ID#2 corresponds to PTM or G-RNTI, or LCID#1 corresponds to PTP or C-RNTI, and LCID#2 corresponds to PTM or G-RNTI.

Another possibility is that the CU determines the PTP/PTM type corresponding to each radio bearer, and the DU determines the PTP/PTM type corresponding to each logical channel based on this. For example, the CU may include the MRB/DRB ID and the corresponding PTP/PTM indication in the F1AP message. For example, MRB/DRB ID#1 corresponds to PTP+PTM mode or C-RNTI+G-RNTI mode, and MRB/DRB ID#2 corresponds to PTP or C-RNTI mode, then DU can be configured with associated MRB/DRB ID#1 Two LCIDs, for example, LCID#1 corresponds to PTP or C-RNTI, and LCID#2 corresponds to PTM or G-RNTI. Configure an associated LCID for MRB/DRB#2, for example, LCID#2 corresponds to PTP or C-RNTI. That is, for the PTP mode, the subsequent PDCCH and PDSCH are scrambled and descrambled with the C-RNTI. For the PTM method, the subsequent PDCCH and PDSCH are scrambled and descrambled with G-RNTI. Specifically, the PTP/PTM type can define a PTP/PTM type information element, and the value of the information element can be {0, 1, 2}, for example, 0 corresponds to the PTP mode or C-RNTI mode, and 1 corresponds to the PTM mode or G-RNTI mode Mode, 2 corresponds to PTP+PTM or C-RNTI+G-RNTI mode. Other similar representation methods are not repeated here.

The following describes the data transmission method provided by the embodiments of the present application from the perspective of a terminal device.

Exemplarily, FIG. 11( a ) shows a schematic diagram of the architecture of a protocol stack of a terminal device.

It can be understood that the terminal device may be other communication devices, which is not limited in this application.

As shown in FIG. 11( a ), the terminal device may configure the third RLC entity and the fourth RLC entity. Wherein, the third RLC entity and the fourth RLC entity are associated with the same MRB. Wherein, the third RLC entity is used for receiving MBS service data sent by the access network device in a PTM manner. The fourth RLC entity is configured to receive MBS service data sent by the access network device in a PTP manner.

As shown in FIG. 11( a ), the terminal device is further configured with a PDCP entity. The third RLC entity and the fourth RLC entity are respectively associated with the PDCP entity. The PDCP entity corresponds to one MBS service or MRB, and correspondingly, the third RLC entity and the fourth RLC entity correspond to one MBS service or MRB.

Optionally, as shown in Figure 11(b), when MBS service data is transmitted between the terminal device using the architecture shown in Figure 11(a) and the access network device using the architecture shown in Figure 8, the third RLC entity uses the For communicating with the first RLC entity of the access network device, the fourth RLC entity is used for communicating with the second RLC entity corresponding to the terminal device on the access network device side.

As shown in FIG. 12 , a data transmission method provided by an embodiment of the present application is applied to the first terminal device adopting the architecture shown in FIG. 11( a ). The method includes the following steps:

S201. A third RLC entity receives at least one RLC SDU from an access network device.

Optionally, when the access network device adopts the architecture shown in FIG. 8 , step S201 may be specifically implemented as: the third RLC entity receives at least one RLC SDU from the first RLC entity of the access network device.

For convenience of description, the working mode adopted by the third RLC entity is referred to as an improved UM mode or an improved AM mode below.

In this embodiment of the present application, the third RLC entity that adopts the improved UM mode will feed back the reception status of the RLC SDU to the fourth RLC entity. Exemplarily, the third RLC entity may submit third information to the fourth RLC entity, where the third information is used to indicate the RLC SN of the first RLC SDU.

S202, the third RLC entity submits the third information to the fourth RLC entity. Correspondingly, the fourth RLC entity obtains the third information from the third RLC entity.

Wherein, the third information is used to indicate the RLC SN of the first RLC SDU.

Optionally, the third RLC entity may generate the third information in the following implementation manner.

Implementation 1: The third RLC entity determines that the first RLC SDU is not successfully received. The third RLC entity generates third information according to the RLC SN of the first RLC SDU.

Optionally, based on implementation 1, the third information may include the RLC SN of the first RLC SDU.

Optionally, based on the implementation mode 1, the third RLC entity maintains the receiving window according to the RLC SN (similar to the UM window pulling mechanism). Based on the receive window, the third RLC entity may acknowledge unsuccessfully received RLC SDUs (eg, the first RLC SDU).

Optionally, based on implementation 1, the fourth RLC entity may not need to maintain the receiving window.

Implementation mode 2: The third RLC entity determines that the second RLC SDU in the at least one RLC SDU is successfully received. The third RLC entity generates third information according to the RLC SN of the second RLC SDU.

Optionally, based on implementation 2, the third information may include the RLC SN of the second RLC SDU.

Optionally, based on implementation mode 2, the third RLC entity may not need to maintain the receiving window, that is, the third RLC entity may not need to confirm the unsuccessfully received RLC SDUs. The third RLC entity submits the third information to the fourth RLC entity, so that the fourth RLC entity knows each RLC SDU successfully received by the third RLC entity. Correspondingly, the fourth RLC entity needs to maintain the receive window according to the RLC SN (similar to the AM window push mechanism). Thus, the fourth RLC entity may determine the RLC SN of the unsuccessfully received RLC SDU (eg, the first RLC SDU) according to the third information.

Optionally, the first terminal device receives an RRC reconfiguration message sent by the access network device, where the RRC reconfiguration message includes MRB configuration information. When the two logical channels (logical channel, LCH) configured in the MRB configuration information are associated with the same DRB or MRB, and one of the LCHs is associated with an MBS session, the first terminal device can determine that the DRB/MRB is actually an MRB . In addition, when the RRC module of the first terminal device determines that the fourth RLC entity configured by the MRB configuration information is in the AM mode, the RRC module will notify the third RLC entity to send the fourth RLC entity to the fourth RLC entity according to implementation 1 or implementation 2 subsequently. Three information.

S203. The fourth RLC entity acquires the first information according to the third information.

Wherein, the first information is used to indicate the RLC SN of the first RLC SDU.

As a possible implementation manner, when the third information is generated based on the foregoing implementation manner 1, the fourth RLC entity may determine the RLC SN of the first RLC SDU according to the third information, and then generate the first information. Alternatively, the fourth RLC entity may directly use the third information as the first information.

As another possible implementation manner, when the third information is generated based on the foregoing implementation manner 2, the fourth RLC entity determines the RLC SN of the second RLC SDU according to the third information. After that, the fourth RLC entity determines the RLC SN of the first RLC SDU according to the RLC SN of the second RLC SDU. The fourth RLC entity generates the first information according to the RLC SN of the first RLC SDU. For the description of the first information, reference may be made to the content in the foregoing embodiment, which is not repeated here.

S204. The fourth RLC entity sends the first information to the access network device.

Optionally, when the access network device adopts the architecture shown in FIG. 8 , step S204 may be specifically implemented as: the fourth RLC entity sends the first information to the second RLC entity of the access network device.

Optionally, after the fourth RLC entity sends the first information, the fourth RLC entity may set a corresponding timer for the RLC SDU to be retransmitted. Before the timer expires, if the first terminal device receives the RLC SDU, the timer is cleared. Or, when the timer expires, if the first terminal device has not received the RLC SDU, the fourth RLC entity may trigger the access network device to retransmit the RLC SDU again, for example, the fourth RLC entity may send the first RLC SDU again information.

Optionally, the fourth RLC entity may set the maximum number of retransmissions for the RLC SDU to be retransmitted. After the number of triggered retransmissions is greater than the maximum number of retransmissions, the fourth RLC entity may notify a higher layer (eg, the RRC layer) that a radio link failure occurs.

In a possible design, after the access network device receives the first information, the first RLC entity of the access network device may retransmit the first RLC SDU. Correspondingly, the third RLC entity of the first terminal device receives the retransmitted first RLC SDU from the first RLC entity of the access network device.

Optionally, after the third RLC entity receives the retransmitted first RLC SDU, the third RLC entity may indicate to the fourth RLC entity that the first RLC SDU is successfully received. Thus, when the fourth RLC entity learns that the first RLC SDU is successfully received, it can clear the timer corresponding to the first RLC SDU, or push the receiving window, or delete the RLC SN of the first RLC SDU, so as not to trigger the The access network device sends the first information.

In another possible design, after the access network device receives the first information, the second RLC entity of the access network device may retransmit the first RLC SDU. Correspondingly, the fourth RLC entity of the first terminal device receives the retransmitted first RLC SDU from the second RLC entity of the access network device.

Optionally, if the fourth RLC entity learns from the third RLC entity that the first RLC SDU has been successfully received, or the fourth RLC entity has successfully received the first RLC SDU, the fourth RLC entity can clear the corresponding data of the first RLC SDU. timer, or push the receiving window, or delete the RLC SN of the first RLC SDU, so as not to trigger the transmission of the first information to the access network device again.

Based on the embodiment shown in FIG. 12 , the first terminal device receives, through the third RLC entity, the MBS service data transmitted by the access network device in the PTM manner; the third RLC entity triggers the third RLC entity by sending third information to the fourth RLC entity. The fourth RLC entity sends the first information to the access network device, so that the access network device knows that the first RLC SDU has not been successfully received. It can be seen that the technical solutions provided by the embodiments of the present application can enable the ARQ mechanism to be applied to the MBS service data transmission scenario, so as to ensure highly reliable transmission of the MBS service data.

Exemplarily, FIG. 13(a) shows a schematic diagram of the architecture of a protocol stack of another terminal device. As shown in FIG. 13( a ), the terminal device may configure a PDCP entity and a fifth RLC entity, the fifth RLC entity is associated with the PDCP entity of the terminal device, and the fifth RLC entity is associated with the MBS service or MRB. That is, the MRB service or MRB corresponds to the PDCP entity and the fifth RLC entity.

As shown in Fig. 13(b), when MBS service data is transmitted between the terminal equipment using the architecture shown in Fig. 13(a) and the access network equipment using the architecture shown in Fig. 8, the fifth RLC entity is used to communicate with the access network equipment. The first RLC entity of the network device communicates with the fifth RLC entity for communicating with the second RLC entity of the access network device.

It should be understood that the terminal device only configures one RLC entity to support the PTM transmission mode and the PTP transmission mode with the access network device, which is beneficial to simplify the RLC configuration of the terminal device.

As shown in FIG. 14 , a data transmission method provided by an embodiment of the present application is applied to the first terminal device adopting the architecture shown in FIG. 13( a ). The method includes the following steps:

S301. The fifth RLC entity receives at least one RLC SDU from the access network device.

Optionally, when the access network device adopts the architecture shown in FIG. 8 , step S301 may be specifically implemented as: the fifth RLC entity receives at least one RLC SDU from the first RLC entity of the access network device.

It should be understood that the fifth RLC entity adopts AM mode.

S302. The fifth RLC entity generates first information.

As a possible implementation manner, the fifth RLC entity maintains the receiving window, and determines the RLC SN of the unsuccessfully received RLC SDU (for example, the first RLC SDU) according to the receiving window. Thus, the fifth RLC entity may generate the first information according to the RLC SN of the unsuccessfully received RLC SDU.

S303. The fifth RLC entity sends the first information to the access network device.

Optionally, when the access network device adopts the architecture shown in FIG. 8 , step S303 may be specifically implemented as: the fifth RLC entity sends the first information to the second RLC entity of the access network device.

Exemplarily, the fifth RLC entity submits the first information to the lower layer (eg, the physical layer). The bottom layer scrambles the first information by using the C-RNTI, and sends the scrambled first information to the access network device. After receiving the scrambled first information, the bottom layer of the access network device performs descrambling according to the C-RNTI used for scrambling the first information, and delivers the first information to the corresponding second RLC entity.

Optionally, for the access network device using the architecture shown in FIG. 8 , after the access network device receives the first information, the first RLC entity or the second RLC entity of the access network device may retransmit the first RLC. SDU. Correspondingly, the fifth RLC entity of the first terminal device may receive the retransmitted first RLC SDU from the first RLC entity or the second RLC entity of the access network device.

Based on the embodiment shown in FIG. 14 , the fifth RLC entity of the first terminal device receives the MBS service data transmitted by the access network device in the PTM manner, and the fifth RLC entity may send the first information to the access network device to The access network device is made aware that the first RLC SDU has not been successfully received. It can be seen that the technical solutions provided by the embodiments of the present application can enable the ARQ mechanism to be applied to the MBS service data transmission scenario, so as to ensure highly reliable transmission of the MBS service data.

Optionally, as shown in FIG. 15 , a data transmission method provided by this embodiment of the present application includes the following steps:

S401. An access network device generates first indication information.

The first indication information is used to instruct the first terminal device to receive the starting data sequence number information of the MBS service data.

Exemplarily, the starting data sequence number information includes the starting PDCP SN, the PDCP count value (count) and/or the starting RLC SN. For example, the PDCP SN, PDCP count value (count) and/or RLC SN corresponding to the next received RX_NEXT and the next received RX_DELIV.

Optionally, the initial PDCP SN, PDCP count value or initial RLC SN is not 0.

Exemplarily, the first indication information may be carried in the PTM activation signaling, or included in the RRC reconfiguration message, which is not limited in this embodiment of the present application.

S402. The access network device sends first indication information to the first terminal device. Correspondingly, the first terminal device receives the first indication information from the access network device.

As a possible implementation manner, in the case of initially accessing the MBS session or switching to the PTM mode, the access network device may send the first indication information to the first terminal device.

Based on the embodiment shown in FIG. 15 , the access network device sends the first indication information to the first terminal device, so that the RLC entity in the first terminal device can set the start point of the corresponding receiving window according to the first indication information, Instead of having to set the start point of the receive window to 0.

It should be understood that the embodiment shown in FIG. 15 may be used in combination with the embodiment shown in FIG. 8 , FIG. 12 or FIG. 14 .

Optionally, as shown in FIG. 16, a data transmission method provided by this embodiment of the present application includes the following steps:

S501. An access network device generates MRB configuration information.

The MRB configuration information is used to configure an MRB session between the first terminal device and the access network device.

Optionally, in order to avoid confusion between MRB and DRB or a signaling radio bearer (signal radio bearer, SRB), the protocol may predefine an MRB-specific radio bearer identifier. Therefore, the radio bearer identifier included in the MRB configuration information belongs to the radio bearer identifier dedicated to the MRB.

The MRB configuration information includes PTM identity and/or MBS session information. Exemplarily, the MBS session information may include a temporary mobile group identity (TMGI). Alternatively, the MBS session information may contain TMGI and session identification.

The following describes the MRB configuration information in detail with respect to the first terminal device using the protocol stack architecture shown in FIG. 11( a ) or FIG. 13 ( a ) respectively.

(1) The first terminal device adopts the protocol stack architecture shown in FIG. 11( a ), the MRB configuration information includes two RLC bearer configuration information, the two RLC bearer configuration information is associated with the same MRB, and the two RLC bearer configuration information At least one of the RLC bearer configuration information includes PTM identification and/or MBS session information.

(2) Using the protocol stack architecture shown in FIG. 13(a) for the first terminal device, the MRB configuration information may include RLC bearer configuration information, and the RLC bearer configuration information is used to configure the fifth terminal device that processes the MBS service for the first terminal device. RLC entity. The RLC bearer configuration information includes a first LCID and a second LCID, and the first LCID is associated with a PTM identifier or MBS session information.

Exemplarily, the PTM identification may be implemented in the form of an MBSPTIndication information element. MBS session information may exist in the form of associatedMBSSession cells. That is, the RLC bearer information includes the MBSPT Mendication information element, which is equivalent to the RLC bearer information including the PTM identifier. The RLC bearer information includes the associatedMBSSession information element, which is equivalent to the RLC bearer information including the MBS session information.

Exemplarily, when the LCID included in the RLC bearer configuration information adopts a PTM manner, the RLC bearer configuration information may include a PTM identifier and/or MBS session information.

For example, the RLC bearer configuration information includes LCID=1 and LCID=2, assuming that LCID=1 is bound to DRB=1 or MRB=1, and is bound to MBS session MBSSessionInfo=TMGI#1, or corresponds to MBSPTMindication. LCID=2 is also bound to DRB=1 or MRB=1. Therefore, it can be explained that DRB=1 for LCID=1 and LCID=2 is actually an MRB. Wherein, LCID=1 corresponds to the PTM mode, and corresponds to the third RLC entity of the first terminal device. LCID=2 corresponds to the PTP mode, and is connected to the fourth RLC entity of the first terminal device.

In a possible design, the RLC bearer configuration information may be in the following format, where the underlined part is the standard new content:

The associatedMBSSession information element is also added to the RLC bearer configuration information, and the associatedMBSSession information element is used to bear the MBS session information. The condition for the existence of the associatedMBSSession information element is the PTM-leg. That is, when the LCID in the RLC bearer configuration information corresponds to the PTM-leg, the RLC bearer configuration information includes the associatedMBSSession information element.

The MBSPTMIndicationd information element is also added to the RLC bearer configuration information, and the MBSPTMIndicationd information element is used to indicate whether the LCH is associated with a PTM identifier. The existence condition of the MBSPTMIndicationd cell is the PTM-leg. That is, when the LCID in the RLC bearer configuration information corresponds to the PTM-leg, the RLC bearer configuration information includes the MBSPTMIndicationd information element, and the value of the MBSPTMIndicationd information element is "true".

The RLC bearer configuration information provided by the embodiment of the present application adds an optional mrb-Identity to the servedRadioBearer information element. In addition, the associatedMBSSession information element is also added to the RLC bearer configuration information, and the associatedMBSSession information element is used to carry the MBS session information. The condition for the existence of the associatedMBSSession information element is the PTM-leg. That is, when the LCID in the RLC bearer configuration information corresponds to the PTM-leg, the RLC bearer configuration information includes the associatedMBSSession information element.

For the schematic diagram of the protocol stack of the terminal device shown in FIG. 13(a), in a possible design, the RLC bearer configuration information may be in the following format, where the underlined part is the standard addition:

Exemplarily, the "mrb-ToAddModList" information element may be added to the RLC bearer configuration information, or the LCID included in the RLC bearer configuration information belongs to the range of the logical channel identifier dedicated to the MBS service, or the RLC bearer configuration information includes MBS related indication information, Therefore, the first terminal device can be made to know that the RLC entity configured by the RLC bearer configuration information is used for processing the MBS service.

Optionally, the protocol may predefine the range of logical channel identifiers dedicated to the MBS service. That is, when the UE receives the configuration information that includes the logical channel identifier within the range of the logical channel identifier, it considers that the logical channel corresponds to the MBS service.

Exemplarily, the RLC bearer configuration information may be in the following format, where the underlined part is standard new content:

Wherein, in the embodiment of the present application, the content of mrb-identity (Identity) is added to the serving radio bearer (servedRadioBearer) information element of the RLC bearer configuration information.

Optionally, in the case where the protocol does not define the range of the logical channel identifier dedicated to the MBS service, if the LCID sent by the first terminal device when receiving the MBS service is the same as the unicast LCID that is being used by the first terminal device, the first terminal device sends the MBS service. The device can notify the network side to reconfigure the LCID related to the MBS service to avoid the conflict between the transmission of the MBS service and the transmission of the unicast service.

Optionally, when the first terminal device switches from the idle state (IDLE)/inactive state (INACTIVE) to the RRC connected state, the first terminal device may notify the access network device of the LCID corresponding to the MBS service it is interested in, to It is ensured that the access network device does not configure the first terminal device with these LCIDs for the logical channel of the unicast radio bearer.

It should be understood that the LCID corresponding to the unicast radio bearer and the LCID corresponding to the MRB are set to different values, the purpose of which is to prevent the MAC layer from demultiplexing according to the MAC subheader when it receives the MAC PDU submitted by the physical layer. LCID to determine whether the corresponding MAC sub-SDU is DRB or MRB.

S502. The access network device sends MRB configuration information to the first terminal device. Correspondingly, the first terminal device receives the MRB configuration information from the access network device.

It should be understood that since the MRB configuration information includes the PTM identifier or the MBS session information, the first terminal device can learn the MRB configuration information for configuring the MRB.

Exemplarily, the MRB configuration information may be carried in an RRC reconfiguration message.

Based on the embodiment shown in FIG. 16 , the access network device sends the MRB configuration information to the first terminal device, so that the first terminal device knows the relevant configuration of its own RLC layer.

It should be understood that the embodiment shown in FIG. 16 may be used in combination with the embodiment shown in FIG. 8 , FIG. 12 , FIG. 14 or FIG. 15 .

Optionally, a scenario in which the data transmission method shown in FIG. 16 is applied to MBS session establishment is illustrated below with reference to FIG. 17 . As shown in Figure 17, the method includes the following steps:

S601. The first terminal device sends a PDU session establishment request (PDU session establishment request) message to a mobility management network element.

The PDU session establishment request message is used to request the establishment of a PDU session. The first terminal device sends a PDU session establishment request to the mobility management network element through the access network device.

In this embodiment of the present application, the PDU session establishment request message includes MBS session indication information, where the MBS session indication information is used to indicate that the PDU session requested to be established by the PDU session establishment request message is an MBS session.

Optionally, the MBS session indication information may be a session identifier dedicated to the MBS service. Alternatively, the MBS session indication information may be a session type set as a preset value, for example, the MBS session indication information may be a session type with a value of "MBS". It should be understood that the MBS session indication information may also adopt other implementation manners, which are not limited thereto.

After receiving the PDU session establishment request message, the mobility management network element may select a session management network element that provides services for the first terminal device. The session management network element may acquire the subscription information of the first terminal device to determine whether the first terminal device has the right to establish the MBS session indicated by the MBS session indication information. If the first terminal device has the corresponding authority, the session management network element may further perform the process of establishing a PDU session. Therefore, the mobility management network element can perform the following step S602.

S602, the mobility management network element sends a PDU session resource setup request (PDU session resource setup request) message to the gNB-CU.

The PDU session resource establishment request message includes N2 session management information and a PDU session establishment accept (PDU session establishment accept) message in which the destination node is the first terminal device.

The N2 session management information includes the shared N3 GTP-U Tunnel information corresponding to the requested MBS session.

Optionally, if the shared N3 GTP-U Tunnel corresponding to the MBS session requested by the first terminal device has not been established before step S601, the shared N3 GTP-U Tunnel information may include one or more of the following parameters: : MBS session identifier, TMGI, tunnel endpoint identifier (TEID), or QoS flow information of the MBS session. The QoS information of the MBS session may include a QoS flow identifier and a QoS parameter.

Optionally, if the shared N3 GTP-U Tunnel corresponding to the MBS session requested by the first terminal device has been established before step S601, the shared N3 GTP-U Tunnel information may only include the MBS session identifier or the TEID corresponding to the MBS session. .

S603. The gNB-CU sends a PDU session resource setup response (PDU session resource setup response) message to the mobility management network element.

After receiving the PDU session resource establishment request, the gNB-CU can perform session admission control according to the N2 session management information and its own current network load. Afterwards, the gNB-CU may send a PDU session resource establishment response message to the mobility management network element according to the admission result. The PDU session resource establishment response message may include information on whether the MBS session requested by the first terminal device is accepted by the gNB-CU.

S604. The gNB-CU sends an MBS context setup request (MBS context setup request) message to the gNB-DU.

The MBS context establishment request message includes the TMGI corresponding to the MBS session and one or more MRB configuration information.

TMGI is usually used to scramble the PDCCH when used in the PTM transmission mode. The terminal equipment interested in the MBS service corresponding to the TMGI uses the TMGI to descramble the PDCCH to determine whether there is data of the MBS service scheduled by the PDCCH.

Optionally, the access network device may also use the G-RNTI corresponding to the TMGI to scramble the PDCCH and the PDSCH. Correspondingly, the terminal device can use the G-RNTI corresponding to the TMGI to descramble the PDCCH and PDSCH.

The MRB configuration information includes QoS parameters for one or more QoS flows. Optionally, the MRB configuration information may also include shared F1 GTP-U Tunnel information, such as the TEID on the CU side.

Optionally, the MBS context establishment request message may also include one or more of the following information: TMGI, MBS session identifier, MBS local area (local area) information, MBS service pattern (traffic pattern) information, service PLMN ID, Service network identifier (network ID, NID).

Wherein, the MBS local area information is used to indicate a geographic area suitable for transmitting MBS service data. Exemplarily, the MBS local area information may include a cell list or a service area identification list.

The MBS traffic pattern information is used to indicate the generation rule of the MBS service data, such as the generation period, quantity, and generation start time of the MBS service data.

The serving PLMN ID is used to indicate the operator to which the MBS service belongs.

The service NID is used to indicate the private network to which the MBS service belongs in the private network scenario.

Optionally, after receiving the MBS context establishment request message, the gNB-DU can configure a shared RLC entity (that is, the first RLC entity in FIG. 8 ) for each MRB of the MBS service, and submit the data of the shared RLC entity. The bottom layer is transmitted over the air interface in PTM mode.

S605. The gNB-DU sends an MBS context setup response (MBS context setup response) message to the gNB-CU.

The MBS context establishment response information may include the shared F1 GTP-U Tunnel information corresponding to the MRB, such as the TEID on the DU side.

It should be understood that the main purpose of steps S604-S605 is to configure the MRB corresponding to the MBS session between the gNB-DU and the gNB-CU, such as configuring the shared F1 GTP-U Tunnel corresponding to the MRB. Optionally, if the shared F1 GTP-U Tunnel corresponding to the MBS session already exists, you can choose not to perform the above steps S604-S605.

After the shared F1 GTP-U Tunnel corresponding to the MRB is established between the gNB-DU and the gNB-CU, the gNB-DU can receive data from the shared F1 GTP-U Tunnel and remove the GTP-U header. For the shared RLC entity (the first RLC entity) or the second RLC entity, please refer to the foregoing for the specific method of which RLC entity to submit to.

S606. The gNB-CU sends a UE context modification request (UE context modification request) message to the gNB-DU.

The UE context modification request message includes one or more MRB configuration information corresponding to the MBS service requested by the first terminal device. Wherein, the MRB configuration information includes at least the MRB ID.

For example, the UE context modification request message includes the "MRB to be setup list" information element, and the "MRB to Be Setup List" IE further contains the MRB ID of each MRB.

In a possible design, after receiving the UE context modification request message, the gNB-DU generates a separate RLC entity (that is, the second RLC entity in FIG. 8 ) for each MRB of the MBS service. In this way, for all terminal devices involved in the MRB, the gNB-DU can be configured with one first RLC entity. For each terminal device in all the terminal devices involved in the MRB, the gNB-DU may be configured with a second RLC entity respectively. Therefore, for the same MRB, the gNB-DU may have one first RLC entity and at least one second RLC entity. Optionally, the logical channels corresponding to these RLC entities may have different LCIDs or the same LCID.

In another possible design, for all terminal devices involved in the MRB, the gNB-DU may configure only one RLC entity in AM mode for one MRB. Based on this design, the MRB configuration information sent by the gNB-CU to the gNB-DU needs to carry the C-RNTIs of all terminal devices corresponding to the MRB.

Optionally, when the gNB-DU configures only one RLC entity in AM mode for one MRB, only if the RLC status report information fed back by all terminal devices involved in the MRB confirms that the RLC SDU with RLC SN=X is successfully received , the RLC entity confirms that the RLC SDU with RLC SN=X has been successfully transmitted, so that the corresponding RLC AM mode operations can be performed, such as sending window movement and data discarding.

It should be understood that the first RLC entity transmits the MBS service data over the air interface in the PTM manner, and the second RLC entity transmits the MBS service data over the air interface in the PTP manner. For the PTP method, the physical layer of the gNB-DU scrambles the PDCCH containing the scheduling grant with the C-RNTI. For the PTM method, the physical layer of the gNB-DU scrambles the PDCCH containing the scheduling grant with the G-RNTI.

Wherein, each terminal device has its own C-RNTI, that is, different terminal devices are configured with different C-RNTIs.

In general, the G-RNTI is in a one-to-one correspondence with an MBS service identifier (eg, TMGI). However, if multiple MBS services are supported in one MAC PDU, the G-RNTI can also correspond to multiple MBS services.

Optionally, when the MAC layer of the gNB-DU receives the uplink data of the LCID corresponding to the MRB, it can submit the uplink data to the terminal equipment that provides services for the terminal equipment corresponding to the C-RNTI according to the C-RNTI scrambled by the uplink data. The second RLC entity performs processing. Exemplarily, the uplink data of the LCID corresponding to the MRB may be the first information in the embodiment shown in FIG. 9 .

Optionally, when the first RLC entity receives the indication information sent by the corresponding PDCP entity to indicate that the RLC SDU is discarded, if the RLC SDU instructed to be discarded has been handed over to the second RLC entity, the first RLC entity needs to send the RLC SDU to the second RLC entity. The second RLC entity sends indication information for indicating discarding of the RLC SDU.

S607. The gNB-DU sends a UE context modification response (UE context modification response) message to the gNB-CU.

S608 (optional), the gNB-CU sends MBS control information (MBS control info) to the UE.

The MBS control information includes the TMGI of the MBS service requested by the UE.

Optionally, the MBS control information may further include MBS scheduling pattern information corresponding to the MBS service. The MBS scheduling pattern information is used to indicate the time domain resource location and/or the frequency domain resource location for transmitting MBS service data. Exemplarily, the MBS scheduling pattern information includes one or more of the following parameters: scheduling/transmission period, time offset, starting position, and frequency domain resource position. The frequency domain resource location may be a bandwidth part (bandwidth part, BWP), etc., which is not limited.

Optionally, the MBS control information may be sent through system information and/or an MBS control channel.

Optionally, before sending the MBS control information, the gNB-DU or gNB-CU may send a paging message or other types of notification messages, so that the first terminal device knows that the MBS control information is updated. In this way, the first terminal device can accurately receive the MBS control information to know the start of a new MBS service.

S609. The gNB-CU sends an RRC reconfiguration (RRC reconfiguration) message to the first terminal device.

The RRC reconfiguration message includes one or more MRB configuration information corresponding to the MBS service. Optionally, the MRB configuration information is used to configure the PDCP layer and the RLC layer.

In this embodiment of the present application, for the MRB configuration information included in the RRC reconfiguration message, reference may be made to the MRB configuration information mentioned in step S501 shown in FIG. 16 , and details are not repeated here.

Optionally, the RRC reconfiguration message may include a PDU session establishment accept message. Alternatively, the gNB-CU may send a PDU session establishment accept message to the first terminal device through another RRC message.

S610. The first terminal device sends an RRC reconfiguration complete (RRC reconfiguration complete) message to the gNB-CU.

Based on the embodiment shown in FIG. 17 , in the process of establishing the MBS session, both the gNB and the first terminal device can configure the corresponding RLC layer, so that the gNB and the first terminal device can perform the data transmission shown in FIG. 9 . method.

It should be understood that the embodiment shown in FIG. 17 only introduces a part of the steps of the PDU session establishment process. The PDU session establishment process may further include other steps, which will not be repeated here.

It should be understood that the embodiment shown in FIG. 17 is mainly described from the perspective that the access network device adopts the CU-DU architecture. In fact, it is also applicable to other architectures of the access network device, such as the gNB integrated architecture or the gNB-CU. The architecture of CP/UP separation, etc. Wherein, when the embodiment shown in FIG. 17 is applied to the gNB integrated architecture, the information exchange between the gNB-CU and the gNB-DU is the internal operation of the gNB.

At present, due to the mobility of the terminal device, when the terminal device moves out of the service range of the currently connected access network device, the communication of the terminal device may be affected. Therefore, during the movement of the terminal device, the terminal device can be switched from the source access network device to the target access network device through the handover process to ensure the communication continuity and service quality of the terminal device.

Exemplarily, as shown in FIG. 18 , the handover process provided by the related art includes the following steps:

S701. The terminal device sends a measurement report (measurement report) to the source access network device.

As a possible implementation manner, in the handover preparation stage, the terminal device in the RRC connected state may send the measurement report according to the measurement report triggering criterion configured by the source access network device.

S702. The source access network device determines the target access network device according to the measurement report.

As a possible implementation manner, the source access network device determines whether the terminal device satisfies the handover condition according to the measurement report and a radio resource management (radio resource management, RRM) algorithm. In the case that the terminal device satisfies the handover condition, the source access network device determines the target access network device.

S703. The source access network device sends a handover request message to the target access network device.

Wherein, the handover request message may include the context of the terminal device.

S704. The target access network device sends a handover request confirmation message to the source access network device.

The handover request confirmation message may include the C-RNTI and other parameters allocated by the target access network device to the terminal device.

Optionally, after the source access network device receives the handover confirmation request message, the source access network device may prepare to forward the packet data to the target access network device.

S705. The source access network device sends a handover command (handover command) to the terminal device.

The handover command may include: C-RNTI allocated by the target access network device to the terminal device, random access channel (random access channel, RACH) parameters, and protocol layer configuration information of the terminal device. The protocol layer configuration information of the terminal device may be used to configure protocol layers such as PHY, MAC, RLC, PDCP, and SDAP.

Optionally, after receiving the handover command, the terminal device stops uplink data or downlink data transmission with the source access network device, and prepares to synchronize with the target access network device.

Optionally, the terminal device does not stop data transmission with the source access network device until the terminal device and the target access network device complete synchronization.

The source access network device may send the uplink data from the terminal device and/or the downlink data from the user plane network element to the target access network device.

S706, the source access network device sends SN status information (SN status transfer) to the target access network device.

S707, the terminal device and the target access network device perform synchronization and random access procedures.

Based on step S707, the terminal device can learn the uplink timing and uplink resource allocation.

S708: The terminal device sends a handover confirmation message to the target access network device.

The handover confirmation message is used to indicate that the handover is completed.

S709. The target access network device sends a handover complete message to the source access network device.

The handover complete message is used to trigger the source access network device to release the context information of the terminal device.

Afterwards, the target access network device may notify the core network network element to update the target access network device for data forwarding of the terminal device, so that the core network can forward the data of the terminal device to the target access network device.

When the handover process shown in Figure 18 is directly applied to the MBS service transmission scenario, there are several scenarios: 1) the source base station supports MBS, and the target base station supports MBS; 2) the source base station supports MBS, but the target base station does not support MBS; 3) the source base station supports MBS The base station does not support MBS, and the target base station supports MBS; 4) The source base station does not support MBS, and the target base station does not support MBS. For the case where the source base station does not support MBS, after the core network receives the path switch of the target base station, it will not continue to send the MBS data to the terminal device from the source base station, but the source base station can forward the buffered data packets to the target base station. For the case that the source base station supports MBS, and the case that the target station does not support MBS, this article does not expand. For the case where the source station supports MBS and the target station also supports MBS. Since the source base station will not stop receiving MBS service data from the core network due to the departure of the UE, that is, after the UE moves, the source station will continue to receive MBS service data from the MBS UPF. Therefore, the source base station does not know which MBS service data data is forwarded to the target base station. The target base station needs to clearly inform the source station whether it needs to do data forwarding. If necessary, to which SN number the data is forwarded to. Otherwise, more unnecessary data forwarding may occur in the handover process between the source access network device and the target access network device, resulting in a waste of system resources.

For the MBS transmission scenario, in order to solve the problem that the source base station does not know which data packets of the MBS service the data is forwarding in the handover process, thereby reducing unnecessary data forwarding, an embodiment of the present application provides a data transmission method. As shown in Figure 19, the data transmission method includes the following steps:

S801. The source access network device sends handover request information to the target access network device. Correspondingly, the target access network device receives the handover request message from the source access network device.

The handover request message is used to request to handover the terminal device from the source access network device to the target access network device. The handover request message contains relevant information of the MBS session, such as the TMGI corresponding to the MBS session, the MBS session identifier, the MRB ID, the QoS flow identifier corresponding to the MRB ID, and the QoS parameters. Therefore, the target access network device learns which service of the MBS session the terminal device currently includes.

S802. The target access network device sends fourth information to the source access network device. Correspondingly, the source access network device receives the fourth information from the target access network device.

The fourth information is used to instruct the source access network device to forward the MBS service data corresponding to at least one SN before the first SN to the terminal device to the target access network device.

Optionally, "forwarding the MBS service data corresponding to at least one SN before the first SN of the terminal device" may include forwarding the MBS service data corresponding to the first SN; or, does not include forwarding the MBS service data corresponding to the first SN. .

It should be understood that the first SN may have other names, such as last forwarding SN (last forwarding SN), which is not limited.

Optionally, the fourth information may include first SN information. Exemplarily, the first SN may be a PDCP SN, a COUNT value, a GTP-US SN, or a QFI and a corresponding QFI SN. The COUNT value contains the PDCP SN and the hyper frame number (HFN). Specifically, the fourth information may be of the following types: 1) MBS session information (TMGI and/or MBS session identifier) and corresponding PDCP SN (or COUNT value); 2) MBS session information, MRB ID and corresponding PDCP SN (or COUNT value); 3) MBS session information, QFI and corresponding QFI SN; 3) MBS session information and GTP-US SN number.

Exemplarily, the fourth information may be included in the handover request confirmation message sent by the target access network device to the source access network device.

The following describes different application scenarios.

Scenario 1: The user plane tunnel corresponding to the MBS session has not been established between the target access network device and the core network element. Hereinafter, the user plane tunnel corresponding to the MBS session is simply referred to as the MBS tunnel. Wherein, the MBS tunnel is a user plane tunnel used for transmitting MBS service data of the terminal device. Exemplarily, the above MBS tunnel may be a Shared N3 GTP-U Tunnel.

Exemplarily, the core network element may be a user plane network element, which is not limited.

Based on scenario 1, the target access network device may obtain the second SN information from the core network element; the target access network device determines the first SN information according to the second SN information. The second SN information is used to indicate the second SN, and the first SN information is used to indicate the first SN. The second SN is the next SN to the first SN, or the second SN is equal to the first SN.

Exemplarily, the target access network device sends a path switching request message to the core network element, where the path switching request message is used to request the core network element to switch the transmission path of the MBS service data of the terminal device. The target access network device receives a path switching confirmation message from the core network element, where the path switching confirmation message includes the second SN information. For example, the second SN information contained in the path switch confirmation message may be 1) MBS session information and corresponding GTP-U SN number; or 2) MBS session information, QFI and QFI SN number. Optionally, the second SN, or the second SN and other information may be included in interface messages between other target access network devices and core network elements. When the target access network device obtains the MBS session information and the corresponding GTP-US SN from the core network element, the target access network device determines that the first SN information is the MBS session information and the GTP-US SN. Or the target access network device determines the PDCP SN (or COUNT value) corresponding to the GTP-USN, thereby determining that the first SN information is MBS session information and PDCP SN (or COUNT value), or MBS session information, MRB ID and corresponding PDCP SN (or COUNT value). When the target access network device obtains the MBS session information, the QFI and the corresponding QFI SN number from the core network element, the target access network device determines that the first SN information is the MBS session information, the QFI and the corresponding QFI SN number.

Optionally, the second SN is the SN corresponding to the MBS service data of the first terminal device sent by the core network element to the target access network device.

It should be understood that the second SN may have other names, such as the first forwarded SN (first SN), which is not limited.

Scenario 2: An MBS tunnel has been established between the target access network device and the core network element.

Based on scenario 2, the target access network device can obtain and cache the MBS service data of the terminal device from the core network element through the MBS tunnel.

In a possible design, the target access network device may send the fourth information to the source access network device after receiving the handover request message. The fourth information includes the first SN, where the first SN is the SN corresponding to the first MBS service data of the terminal device buffered by the target access network device.

In another possible design, after receiving the handover request message, the target access network device receives the SN status report information sent by the source access network device, the SN status report information indicates the third SN, and the third SN is the SN status report The next COUNT value corresponding to the MBS service indicated by the information (including the PDCP SN and the superframe number HFN), that is, the target access network device can learn from the third SN when the UE accesses the target access network device, which COUNT value should be obtained from The value starts to deliver the data of the MBS service to the UE. In the case that the first SN is greater than the third SN, the target access network device sends fourth information to the source access network device. The fourth information includes the first SN, where the first SN is the SN corresponding to the first MBS service data of the terminal device buffered by the target access network device.

In this embodiment of the present application, in order to ensure that the target access network device and the source access network device have the same number (for example, PDCP SN) for data with the same content, a second preset mapping relationship may be specified in the protocol, or the core network or network management Configure the second preset mapping relationship.

Exemplarily, the second preset mapping relationship is a preset mapping relationship between the PDCP SN (or the COUNT value) and the GTP-US SN. Or, the second preset mapping relationship is a preset mapping relationship between the combination of QFI and QFI SN and the PDCP SN (or COUNT value).

The introduction is made by taking the second preset mapping relationship as the preset mapping relationship between the PDCP SN (or the COUNT value) and the GTP-US SN as an example. Among them, the size of the PDCP SN (or COUNT value) is less than or equal to the size of the GTP-US SN to ensure that a GTP-US SN can only derive a unique PDCP SN.

Optionally, since the PDCP SN size in the current protocol is 12 bits or 18 bits, and the GTP-US SN size is 16 bits, in order to ensure that the size of the PDCP SN is less than or equal to the size of the GTP-US SN, the PDCP SN in this embodiment of the present application size can only support 12bit.

It should be understood that the size of the PDCP SN in the embodiments of the present application is not fixed. When the size of the PDCP SN is changed in the protocol, or the size of the GTP-US SN is changed, the size of the PDCP SN in the embodiment of the present application can also be changed.

Optionally, the second preset mapping relationship may be PDCP_SN=GTP-U SN mod(max PDCP SN+1). Among them, maxPDCP SN is the maximum value that PDCP SN can take.

Based on the embodiment shown in FIG. 19 , in the handover process, the target access network device sends the fourth information to the source access network device, so that the source access network device forwards the information before the first SN to the target access network device. Instead of forwarding all MBS service data of the terminal equipment, the MBS service data of the terminal equipment corresponding to at least one SN reduces the number of data to be forwarded, which is beneficial to saving system overhead.

In addition, the source access network device forwards the MBS service data of the terminal device corresponding to at least one SN before the first SN to the target access network device, which can realize lossless or minimal packet loss transmission during the handover process.

For the MBS transmission scenario, before the handover, the target access network device may have established a user plane tunnel corresponding to the MBS session with the core network element, and the target access network device can obtain the MBS service data of the terminal device from the core network element. However, the source access network device cannot perceive the information that the target access network device has established the user plane tunnel corresponding to the MBS session with the core network element. Therefore, during the handover process, the source access network device follows the steps shown in FIG. When the handover process is executed, the source access network device will forward unnecessary MBS data to the target access network device, thereby causing waste of system resources.

Therefore, for a scenario where a target access network device has established a tunnel corresponding to an MBS session with a core network element before handover, in order to reduce unnecessary data forwarding in the handover process, an embodiment of the present application provides a data transmission method. As shown in Figure 20, the data transmission method includes the following steps:

S901. The source access network device sends handover request information to the target access network device. Correspondingly, the target access network device receives the handover request message from the source access network device.

The handover request message is used to request to handover the terminal device from the source access network device to the target access network device.

The handover request message contains relevant information of the MBS session, such as the TMGI corresponding to the MBS session, the MBS session identifier, the MRB ID, the QoS flow identifier corresponding to the MRB ID, and the QoS parameters. Therefore, the target access network device learns which service of the MBS session the terminal device currently includes.

S902. The target access network device sends fifth information to the source access network device. Correspondingly, the source access network device receives the fifth information from the target access network device.

The fifth information is used to instruct the source access network device not to forward the MBS service data of the terminal device to the target access network device.

In a possible design, before step S901, an MBS tunnel has been established between the target access network device and the core network element. In addition, the target access network device has buffered the MBS service data received from the MBS tunnel for a long enough time. Therefore, the target access network device can obtain the terminal device's status in the source connection from its own cache after receiving the terminal device handover. The network access device receives the MBS service data at the breakpoint, and sends the MBS service data to the terminal device, so as to ensure the continuity of the terminal device's reception of the MBS service data. In view of this situation, the target access network device does not need to acquire the MBS service data from the source access network device, so the target access network device can send the fifth information to the source access network device.

In another possible design, before step S901, an MBS tunnel has been established between the target access network device and the core network element. The target access network device receives and buffers some MBS service data of the terminal device from the MBS tunnel. After the target access network device receives the handover request message, it receives the SN status report information sent by the source access network device, the SN status report information indicates the third SN, and the third SN is the first unidentified SN indicated by the SN status report information. The SN corresponding to the successfully received MBS service data. In the case that the first SN is less than or equal to the third SN, the target access network device sends fifth information to the source access network device.

The above-mentioned MBS tunnel is used to transmit the MBS service data that the terminal device is receiving. Exemplarily, the above MBS tunnel may be a Shared N3 GTP-U Tunnel.

Optionally, in order to ensure that the data of the same content sent by the core network to the source access network device and the target access network device have the same PDCP SN, a second preset mapping relationship can be specified in the protocol, or the core network or the network management can configure the second Default mapping relationship. For the specific introduction of the second preset mapping relationship, reference may be made to the description in the embodiment shown in FIG. 19 , which will not be repeated here.

Exemplarily, the fifth information may be carried in the handover request confirmation message.

In a possible design, the fifth information may be an indication of "do not forward", or an indication of "MBS already exists". It should be understood that the "MBS already exists" indication is used to indicate that the target access network device has buffered the MBS service data.

In another possible design, the handover request confirmation message does not carry the Xn forwarding tunnel information of the MBS session to implicitly indicate that the handover request confirmation message contains the fifth information.

Exemplarily, the 3rd generation partnership project (3GPP) 38.423 protocol defines the handover request confirmation message to include: "Data forwarding info from target NG-RAN node" "Cell. In the embodiment of the present application, if the handover request confirmation message does not include the "data forwarding info from target NG-RAN node" information element, it is implicitly indicated that the handover request confirmation message includes the fifth information.

Based on the embodiment shown in FIG. 20, in the handover process, the target access network device sends fifth information to the source access network device, so that the source access network device does not need to forward the MBS of the terminal device to the target access network device business data, thereby reducing the number of data to be forwarded, which is beneficial to saving system overhead.

It should be understood that FIG. 19 or FIG. 20 only describes a part of the steps in the handover process. Other parts in the handover process will not be repeated here.

Currently, under the CU-DU architecture, the same gNB-CU may be simultaneously connected to a gNB-DU that supports MBS services and a gNB-DU that does not support MBS services. MBS data is transmitted in a shared transmission mode between the UPF and the gNB-CU. If the gNB-DU does not support the MBS service, the F1-U interface between the gNB-CU and the gNB-DU should establish a separate transmission channel; if the gNB-DU supports the MBS service, the gNB-CU to the gNB-DU The F1-U interface establishes a shared transmission channel. However, at present, the gNB-CU cannot accurately know whether the gNB-DU supports the MBS service, so the gNB-CU cannot accurately determine the type of transmission channel that should be established with the gNB-DU.

In order to solve this technical problem, an embodiment of the present application provides a data transmission method. As shown in Figure 21, the data transmission method includes the following steps:

S1001. The gNB-DU generates first capability indication information.

The first capability indication information is used to indicate the air interface support capability of the gNB-DU for the MBS. That is, the first capability indication information may be used to indicate whether the gNB-DU supports MBS. In other words, the first capability indication information is used to indicate whether the gNB-DU can support air interface broadcast and multicast MBS services.

S1002. The gNB-DU sends first capability indication information to the gNB-CU. Correspondingly, the gNB-CU acquires the first capability indication information from the gNB-DU.

Exemplarily, the first capability indication information is carried in the F1AP message, or the F1-U setup request message, or the gNB-DU Configuration Update message, which is not limited.

Based on the embodiment shown in FIG. 21 , the gNB-CU may determine whether the gNB-DU supports the MBS service according to the first capability indication information, and then select the type of transmission channel established with the gNB-DU. For example, when the UE applies to the core network for establishing an MBS session, and the core network determines that the base station where the gNB-CU is located supports MBS, it notifies the gNB-CU to establish a shared user plane tunnel corresponding to the MBS service. The gNB-CU further judges whether the gNB-DU where the UE is located supports MBS according to the first capability indication information reported by the gNB-DU accessed by the UE. If the gNB-DU supports MBS, the F1-U interface between the gNB-CU and the gNB-DU establishes a shared transmission channel. If the gNB-DU does not support MBS, the F1-U interface between the gNB-CU and the gNB-DU shall establish a separate transmission channel.

Optionally, the air interface support capability of the gNB-DU for MBS may change, for example, the gNB-DU may change from supporting MBS to not supporting MBS; or, the gNB-DU may change from not supporting MBS to supporting MBS. In this case, the gNB-DU may send a configuration update (configuration update) message to the gNB-CU to indicate the latest air interface support capability of the gNB-DU for MBS.

Optionally, when the air interface support capability of the gNB-DU for the MBS changes, the gNB-CU may send a gNB-DU Configuration Update Acknowledge message to the gNB-DU to indicate the gNB-DU. Change the type of transmission channel established by the F1-U interface.

Optionally, as shown in FIG. 22 , an embodiment of the present application provides a data transmission method, and the method includes the following steps:

S1101. The gNB-CU-UP generates second capability indication information.

The second capability indication information is used to indicate the air interface support capability of the gNB-CU-UP for the MBS. That is, the second capability indication information is used to indicate whether the gNB-CU-UP supports MBS.

S1102. The gNB-CU-UP sends the second capability indication information to the gNB-CU-CP.

Exemplarily, the second capability indication information may be carried in a gNB-CU-UP E1 setup message or a gNB-CU-UP configuration update message, which is not limited.

Based on the embodiment shown in FIG. 22 , the gNB-CU-CP can report the capability information of whether to support MBS to the core network according to the second capability indication information. The core network further determines the type of the transmission channel established by the NG-U interface between the UPF and the gNB-CU-UP according to the capability information on whether or not the MBS is supported reported by the gNB-CU-CP. For example, in the case that the gNB-CU-UP supports the MBS service, the NG-U interface between the UPF and the gNB-CU-UP establishes a shared transmission channel; or, in the case that the gNB-CU-UP does not support the MBS service , the NG-U interface between UPF and gNB-CU-UP establishes a separate transmission channel.

The above-mentioned separate transmission channel may also have other names, such as a dedicated transmission channel, which is not limited.

The solutions provided by the embodiments of the present application have been introduced above mainly from the perspective of methods. It can be understood that, in order to implement the above-mentioned functions, a communication apparatus (eg, an access network device and a terminal device) includes corresponding hardware structures and/or software modules for executing each function. Combining with the units and algorithm steps of each example described in the embodiments disclosed in this application, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is performed by hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art may use different methods for each specific application to implement the described functions, but such implementation should not be considered beyond the scope of the technical solutions of the embodiments of the present application.

In this embodiment of the present application, the communication device may be divided into functional modules according to the foregoing method examples. For example, each functional module may be divided corresponding to each function, or two or more functions may be integrated into one processing unit. The above-mentioned integrated units can be implemented in the form of hardware, or can be implemented in the form of software function modules. It should be noted that the division of units in the embodiments of the present application is illustrative, and is only a logical function division, and other division methods may be used in actual implementation.

As shown in FIG. 23 , a communication apparatus provided by an embodiment of the present application includes a processing module 101 and a communication module 102 .

In a possible example, taking the communication device as an access network device as an example, the processing module 101 is configured to support the access network device to perform step S401 in FIG. 15 , step S501 in FIG. 16 , and/or the embodiments of the present application. Other processing operations that need to be performed by the access network device. The communication module 102 is configured to support the access network device to perform steps S101 to S103 in FIG. 9 , step S402 in FIG. 15 , step S502 in FIG. 16 , and/or other needs to be performed by the access network device in the embodiment of the present application communication operations.

In another possible example, taking the communication apparatus as a terminal device as an example, the processing module 101 is configured to support the terminal device to parse information (for example, MRB configuration information), and/or other processing operations that the terminal device needs to perform in this embodiment of the present application For example, the processing module 101 is configured to execute steps S202 and S203 in FIG. 12 and step S302 in FIG. 14 . The communication module 102 is configured to support the terminal device to perform steps S201 and S204 in FIG. 12 , step S402 in FIG. 15 , step S502 in FIG. 16 , and/or other communication operations that the terminal device needs to perform in this embodiment of the present application.

In another possible example, taking the communication device as the target access network device as an example, the processing module 101 is configured to support the target access network device to generate information (for example, the fourth information or the fifth information), and/or the implementation of this application. Other processing operations that need to be performed by the target access network device in the example. The communication module 102 is configured to support the target access network device to perform steps S801-S802 in FIG. 19 , steps S901 and S902 in FIG. 20 , and/or other communication operations that the target access network device needs to perform in this embodiment of the present application.

In another possible example, taking the communication device as the source access network device as an example, the processing module 101 is configured to support the source access network device to parse information (for example, the fourth information or the fifth information), and/or implement the In the example, the source access network device needs to perform other processing operations. The communication module 102 is configured to support the source access network device to perform steps S801-S802 in FIG. 19 , steps S901 and S902 in FIG. 20 , and/or other communication operations that the source access network device needs to perform in this embodiment of the present application.

In another possible example, taking the communication device as a gNB-DU as an example, the processing module 101 is configured to support the gNB-DU to perform step S1001 in FIG. 21 . The communication module is used to support the gNB-DU to perform step S1002 in FIG. 21 .

In another possible example, taking the communication device as a gNB-CU as an example, the processing module 101 is configured to support the gNB-CU to parse the first capability indication information. The communication module is used to support the gNB-CU to perform step S1002 in FIG. 21 .

In another possible example, taking the communication device as the gNB-CU-UP as an example, the processing module 101 is configured to support the gNB-CU-UP to execute step S1101 in FIG. 22 , and the communication module is configured to support the gNB-CU-UP to execute Step S1102 in FIG. 22 .

In another possible example, taking the communication device as the gNB-CU-CP as an example, the processing module 101 is used to support the gNB-CU-CP to parse the second capability indication information, and the communication module is used to support the gNB-CU-CP execution map Step S1102 in 22.

Optionally, the communication device may further include a storage module 103 for storing program codes and data of the communication device, and the data may include but not limited to original data or intermediate data.

The processing module 101 may be a processor or a controller, such as a CPU, a general-purpose processor, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other Programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logical blocks, modules and circuits described in connection with this disclosure. A processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like.

The communication module 102 may be a communication interface, a transceiver or a transceiver circuit, etc., where the communication interface is a general term, and in a specific implementation, the communication interface may include multiple interfaces, for example, may include: an interface between a base station and a terminal and/or or other interfaces.

The storage module 103 may be a memory.

When the processing module 101 is a processor, the communication module 102 is a communication interface, and the storage module 103 is a memory, the communication device involved in the embodiment of the present application may be as shown in FIG. 24 .

Referring to FIG. 24 , the communication device includes: a processor 201 , a communication interface 202 , and a memory 203 . Optionally, the communication device may further include a bus 204 . Wherein, the communication interface 202, the processor 201 and the memory 203 can be connected to each other through a bus 204; the bus 204 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus etc. The bus 204 can be divided into an address bus, a data bus, a control bus, and the like. For ease of presentation, only one thick line is shown in FIG. 24, but it does not mean that there is only one bus or one type of bus.

Optionally, the embodiment of the present application further provides a computer program product carrying computer instructions, when the computer instructions are executed on the computer, the computer is made to execute the method described in the foregoing embodiments.

Optionally, the embodiments of the present application further provide a computer-readable storage medium, where the computer-readable storage medium stores computer instructions, and when the computer instructions are executed on the computer, the computer executes the methods described in the foregoing embodiments.

Optionally, an embodiment of the present application further provides a chip, including: a processing circuit and a transceiver pin, where the processing circuit and the transceiver pin are used to implement the method introduced in the foregoing embodiment. Wherein, the processing circuit is used for executing the processing actions in the corresponding method, and the transceiver pins are used for executing the actions of receiving/transmitting in the corresponding method.

Those of ordinary skill in the art can understand that: in the above-mentioned embodiments, all or part of them may be implemented by software, hardware, firmware or any combination thereof. When implemented in software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated. The computer may be a general purpose computer, special purpose computer, computer network, or other programmable device. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be downloaded from a website site, computer, server, or data center Transmission to another website site, computer, server or data center via wired (eg coaxial cable, optical fiber, Digital Subscriber Line, DSL) or wireless (eg infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access, or a data storage device such as a server, a data center, or the like that includes an integration of one or more available media. The available media may be magnetic media (eg, floppy disks, hard disks, magnetic tapes), optical media (eg, Digital Video Disc (DVD)), or semiconductor media (eg, Solid State Disk (SSD)) Wait.

In the several embodiments provided in this application, it should be understood that the disclosed system, apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are only illustrative. For example, the division of the modules is only a logical function division. In actual implementation, there may be other division methods. For example, multiple modules or components may be combined or Can be integrated into another system, or some features can be ignored, or not implemented. On the other hand, the shown or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, indirect coupling or communication connection of devices or modules, and may be in electrical or other forms.

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

From the description of the above embodiments, those skilled in the art can clearly understand that the present application can be implemented by means of software plus necessary general-purpose hardware, and of course hardware can also be used, but in many cases the former is a better implementation manner . Based on this understanding, the technical solutions of the present application can be embodied in the form of software products in essence or contributed parts, and the computer software products are stored in a readable storage medium, such as a floppy disk, a hard disk or an optical disk of a computer etc., including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the various embodiments of the present application.

The above are only specific embodiments of the present application, but the protection scope of the present application is not limited thereto, and changes or substitutions within the technical scope disclosed in the present application should all be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

A data transmission method, characterized in that the method is applied to an access network device, and the access network device is configured with a Packet Data Convergence Protocol PDCP entity, a first radio link control RLC entity and a second RLC entity, and The first RLC entity and the second RLC entity are respectively associated with the PDCP entity, the first RLC entity is used to support point-to-multipoint PTM transmission mode to send multicast broadcast service MBS service data, the second RLC entity The entity is used to support point-to-point PTP transmission mode to send MBS service data, the first RLC entity and the second RLC entity are associated to the same multicast radio bearer MRB, and the method includes:

The first RLC entity sends at least one RLC service data unit SDU to at least one terminal device including the first terminal device;

The second RLC entity receives first information from the first terminal device, where the first information is used to indicate the RLC sequence number SN of the first RLC SDU, and the first RLC SDU belongs to the at least one RLC SDU RLC SDUs that were not successfully received;

The second RLC entity submits second information to the first RLC entity or the PDCP entity, where the second information indicates the RLCSN of the first RLC SDU;

The first entity sends the first RLC SDU to the first terminal device, where the first entity is the first RLC entity or the second RLC entity.
The method according to claim 1, wherein the first entity is the first RLC entity; before the first entity sends the first RLC SDU to the first terminal device, the Methods also include:

The first RLC entity acquires the first RLC SDU according to the second information.
The method according to claim 1, wherein the first entity is the second RLC entity; before the first entity sends the first RLC SDU to the first terminal device, the Methods also include:

The first RLC entity submits the first RLC SDU to the second RLC entity according to the second information.
The method according to claim 1, wherein before the first entity sends the first RLC SDU to the first terminal device, the method further comprises:

The PDCP entity submits the first RLC SDU to the first entity according to the second information.
The method according to claim 4, wherein the second information includes an RLC SN of the first RLC SDU, and the PDCP entity submits the first entity to the first entity according to the second information One RLC SDU, including:

The PDCP entity determines the PDCP SN of the first PDCP PDU according to the RLC SN of the first RLC SDU and a preset mapping relationship, where the preset mapping relationship is used to indicate the mapping relationship between the PDCP SN and the RLC SN;

The PDCP entity obtains the first PDCP PDU according to the PDCP SN of the first PDCP PDU, where the first PDCP PDU is the first RLC SDU;

The PDCP entity delivers the first RLC SDU to the first entity.
The method according to claim 4, wherein the second information comprises a PDCP SN of a first PDCP PDU, and the PDCP entity submits the first RLC to the first entity according to the second information SDU, including:

The PDCP entity obtains the first PDCP PDU according to the PDCP SN of the first PDCP PDU, where the first PDCP PDU is the first RLC SDU;

The PDCP entity delivers the first RLC SDU to the first entity.
The method according to claim 6, wherein before the second RLC entity submits the second information to the PDCP entity, the method further comprises:

The second RLC entity determines the PDCP SN of the first PDCP PDU according to the RLC SN of the first RLC SDU and a preset mapping relationship, and the preset mapping relationship is used to indicate the relationship between the PDCP SN and the RLC SN. mapping relationship.
The method according to any one of claims 1 to 7, wherein the method further comprises:

The access network device sends first indication information to the first terminal device, where the first indication information is used to instruct the first terminal device to receive starting data sequence number information of the MBS service data.
The method according to claim 8, wherein the starting data sequence number information comprises a PDCP SN, a PDCP count value and/or a starting RLC SN.
The method according to any one of claims 1 to 9, wherein the method further comprises:

The access network device sends MRB configuration information to the first terminal device, where the MRB configuration information is used to configure an MBS session between the first terminal device and the access network device.
The method according to claim 10, wherein the MRB configuration information comprises two RLC bearer configuration information, the two RLC bearer configuration information are associated with the same MRB, and at least one of the two RLC bearer configuration information The RLC bearer configuration information includes PTM identification or MBS session information.
A data transmission method, characterized in that the method is applied to a first terminal device, the first terminal device is configured with a third RLC entity and a fourth RLC entity, and the third RLC entity is used to receive an access network The MBS service data sent by the device in the PTM mode, the fourth RLC entity is used to receive the MBS service data sent by the access network device in the PTP mode, and the third RLC entity and the fourth RLC entity are associated with the same The MRB, the method includes:

the third RLC entity receives at least one RLC SDU from the access network device;

the fourth RLC entity receives third information from the third RLC entity, the third information indicating the RLC SN of the first RLC SDU in at least one RLC SDU;

The fourth RLC entity generates the first information according to the third information;

The fourth RLC entity sends the first information to the access network device, where the first information is used to indicate the RLC SN of the first RLC SDU, and the first RLC SDU belongs to the at least one RLC RLC SDUs that were not successfully received in the SDU.
The method according to claim 12, wherein before the fourth RLC entity receives the third information from the third RLC entity, the method further comprises:

The third RLC entity determines that the first RLC SDU is not successfully received;

The third RLC entity generates the third information according to the RLC SN of the first RLC SDU.
The method according to claim 12, wherein before the fourth RLC entity receives the third information from the third RLC entity, the method further comprises:

The third RLC entity determines that the second RLC SDU in the at least one RLC SDU is successfully received;

The third RLC entity generates the third information according to the RLC SN of the second RLC SDU.
The method according to any one of claims 12 to 14, wherein after the fourth RLC entity sends the first information to the access network device, the method further comprises:

The fourth RLC entity receives the first RLC SDU from the access network device.
The method according to any one of claims 12 to 14, wherein after the fourth RLC entity sends the first information to the access network device, the method further comprises:

The third RLC entity receives the first RLC SDU from the access network device.
The method of claim 16, wherein the method further comprises:

The third RLC entity indicates to the fourth RLC entity that the first RLC SDU was successfully received.
The method according to any one of claims 12 to 17, wherein the method further comprises:

The first terminal device receives first indication information from the access network device, where the first indication information is used to instruct the first terminal device to receive starting data sequence number information of the MBS service data.
The method according to claim 18, wherein the first indication information is specifically used to indicate the starting PDCP SN, the PDCP count value and/or the starting RLC SN.
The method according to any one of claims 12 to 19, wherein the method further comprises:

The first terminal device receives MRB configuration information from the access network device, where the MRB configuration information is used to configure an MBS session between the first terminal device and the access network device.
The method according to claim 20, wherein the MRB configuration information includes two RLC bearer configuration information, the two RLC bearer configuration information are associated with the same MRB, and at least one of the two RLC bearer configuration information The RLC bearer configuration information includes PTM identification or MBS session information.
A data transmission method, characterized in that the method comprises:

The target access network device receives a handover request message from the source access network device, where the handover request message is used to request that the terminal device be handed over from the source access network device to the target access network device;

The target access network device sends fourth information to the source access network device, where the fourth information is used to instruct the source access network device to forward the first sequence number SN to the target access network device MBS service data of the terminal device corresponding to at least one SN of .
The method according to claim 22, wherein before the target access network device sends the fourth information to the source access network device, the method further comprises:

The target access network device obtains the second SN information from the core network element;

The target access network device determines first SN information according to the second SN information, where the first SN information is used to indicate the first SN.
The method according to claim 23, wherein the target access network device obtains the second SN information from the core network element, comprising:

The target access network device sends a path switching request message to the core network element, where the path switching request message is used to request the core network element to switch the transmission path of the MBS service data of the terminal device;

The target access network device receives a path switching confirmation message from the core network element, where the path switching confirmation message includes the second SN information.
The method according to any one of claims 22 to 24, wherein the first SN is a PDCP SN, a general packet radio service tunneling protocol GTP-user plane USN or a quality of service flow identifier QFI SN.
The method according to claim 25, wherein a preset mapping relationship exists between the PDCP SN and the GTP-US SN; or, a combination of the QFI and the QFI SN and the PDCP SN There is a preset mapping relationship.
A data transmission method, characterized in that the method comprises:

The source access network device sends a handover request message to the target access network device, where the handover request message is used to request the terminal device to be handed over from the source access network device to the target access network device;

The source access network device receives fourth information from the target access network device, where the fourth information is used to instruct the source access network device to forward at least the first SN to the target access network device. MBS service data of the terminal device corresponding to one SN.
The method according to claim 27, wherein the first SN is a PDCP SN, a GTP-US SN or a QFI SN.
The method according to claim 28, wherein a preset mapping relationship exists between the PDCP SN and the GTP-US SN; or, there is a preset mapping relationship between the combination of the QFI and the QFI SN and the PDCP SN set mapping relationship.
A communication device, characterized in that the communication device includes a PDCP entity, a first RLC entity, and a second RLC entity, the first RLC entity and the second RLC entity are respectively associated with the PDCP entity, and the The first RLC entity is used for sending MBS service data in a PTM transmission mode, the second RLC entity is used for sending MBS service data in a PTP transmission mode, and the first RLC entity and the second RLC entity are associated with the same MRB;

the first RLC entity, configured to send at least one RLC SDU to at least one terminal device including the first terminal device;

The second RLC entity is configured to receive first information from the first terminal device, where the first information is used to indicate the RLC sequence number SN of the first RLC SDU, and the first RLC SDU belongs to the at least one RLC SDUs that were not successfully received in the RLC SDUs;

the second RLC entity is further configured to submit second information to the first RLC entity or the PDCP entity, where the second information is used to indicate the RLC SN of the first RLC SDU;

a first entity, configured to send the first RLC SDU to the first terminal device, where the first entity is the first RLC entity or the second RLC entity.
The apparatus according to claim 30, wherein the first entity is the first RLC entity; before the first entity is configured to send the first RLC SDU to the first terminal device , the first RLC entity is further configured to acquire the first RLC SDU according to the second information.
The apparatus according to claim 30, wherein the first entity is the second RLC entity; before the first entity is configured to send the first RLC SDU to the first terminal device , the first RLC entity is further configured to submit the first RLC SDU to the second RLC entity according to the second information.
The apparatus according to claim 32, wherein before the first entity is configured to send the first RLC SDU to the first terminal device, the PDCP entity is configured to send the first RLC SDU to the first terminal device according to the second information, and deliver the first RLC SDU to the first entity.
The apparatus according to claim 33, wherein the second information comprises an RLC SN of the first RLC SDU, the PDCP entity is specifically configured to be based on the RLC SN of the first RLC SDU, and a predetermined Set a mapping relationship to determine the PDCP SN of the first PDCP PDU, and the preset mapping relationship is used to indicate the mapping relationship between the PDCP SN and the RLC SN; obtain the first PDCP SN according to the PDCP SN of the first PDCP PDU PDU, the first PDCP PDU is the first RLC SDU; submit the first RLC SDU to the first entity.
The apparatus according to claim 33, wherein the second information includes a PDCP SN of a first PDCP PDU, and the PDCP entity is specifically configured to acquire the first PDCP PDU according to the PDCP SN of the first PDCP PDU, The first PDCP PDU is the first RLC SDU; the first RLC SDU is submitted to the first entity.
The apparatus according to claim 35, wherein the second RLC entity determines the PDCP SN of the first PDCP PDU according to the RLC SN of the first RLC SDU and a preset mapping relationship, and the The preset mapping relationship is used to indicate the mapping relationship between the PDCP SN and the RLC SN.
The apparatus according to any one of claims 30 to 36, wherein the apparatus further comprises a communication module: the communication module is configured to send first indication information to the first terminal device, the first The indication information is used to instruct the first terminal device to receive the starting data sequence number information of the MBS service data.
The apparatus according to claim 37, wherein the starting data sequence number information includes a PDCP SN, a PDCP count value and/or a starting RLC SN.
The apparatus according to any one of claims 30 to 38, wherein the communication module is further configured to send MRB configuration information to the first terminal device, where the MRB configuration information is used to configure the first terminal device MBS session between terminal equipment and access network equipment.
The apparatus according to claim 39, wherein the MRB configuration information comprises two RLC bearer configuration information, the two RLC bearer configuration information are associated with the same MRB, and at least one of the two RLC bearer configuration information The RLC bearer configuration information includes PTM identification or MBS session information.
A communication device, characterized in that the device includes a third RLC entity and a fourth RLC entity, the third RLC entity is used to receive MBS service data sent by an access network device in a PTM manner, and the fourth RLC entity The entity is configured to receive the MBS service data sent by the access network device in a PTP manner, and the third RLC entity and the fourth RLC entity are associated with the same MRB;

the third RLC entity, configured to receive at least one RLC SDU from the access network device;

the fourth RLC entity, configured to receive third information from the third RLC entity, where the third information indicates the RLC SN of the first RLC SDU in the at least one RLC SDU;

The fourth RLC entity is further configured to generate first information according to the third information; send the first information to the access network device, where the first information is used to indicate the information of the first RLC SDU; RLC SN, the first RLC SDU belongs to the RLC SDU that is not successfully received in the at least one RLC SDU.
The apparatus according to claim 41, wherein the third RLC entity is further configured to determine that the first RLC SDU is not successfully received; generate the third RLC SDU according to the RLC SN of the first RLC SDU information.
The apparatus according to claim 41, wherein the third RLC entity is further configured to determine that the second RLC SDU in the at least one RLC SDU is successfully received; according to the RLC SN of the second RLC SDU The third information is generated.
The apparatus according to any one of claims 41 to 43, wherein the fourth RLC entity is further configured to receive the first RLC SDU from the access network device.
The apparatus according to any one of claims 41 to 43, wherein the third RLC entity is further configured to receive the first RLC SDU from the access network device.
The apparatus according to claim 45, wherein the third RLC entity is further configured to indicate to the fourth RLC entity that the first RLC SDU is successfully received.
The apparatus according to any one of claims 41 to 46, wherein the apparatus further comprises a communication module; the communication module is configured to receive first indication information from the access network device, the first indication The indication information is used to instruct the first terminal device to receive the starting data sequence number information of the MBS service data.
The apparatus according to claim 47, wherein the first indication information is specifically used to indicate the starting PDCP SN, the PDCP count value and/or the starting RLC SN.
The apparatus according to any one of claims 41 to 48, wherein the communication module is further configured to receive MRB configuration information from the access network device, where the MRB configuration information is used to configure the first An MBS session between a terminal device and the access network device.
The apparatus according to claim 49, wherein the MRB configuration information includes two RLC bearer configuration information, the two RLC bearer configuration information are associated with the same MRB, and at least one of the two RLC bearer configuration information The RLC bearer configuration information includes PTM identification or MBS session information.
A communication device, comprising a processing module and a communication module connected to the processing module;

The communication module is configured to receive a handover request message from the source access network device, where the handover request message is used to request that the terminal device be handed over from the source access network device to the target access network device;

The processing module is configured to generate fourth information, where the fourth information is used to instruct the source access network device to forward the at least one SN corresponding to the first sequence number SN to the target access network device. MBS service data of terminal equipment;

The communication module is further configured to send the fourth information to the source access network device.
The apparatus according to claim 51, wherein the communication module is further configured to acquire the second SN information from the core network element before sending the fourth information to the source access network device;

The processing module is further configured to determine first SN information according to the second SN information, where the first SN information is used to indicate the first SN.
The apparatus according to claim 52, wherein the communication module is further configured to send a path switching request message to the core network element, where the path switching request message is used to request the core network element to switch The transmission path of the MBS service data of the terminal device; and a path switching confirmation message is received from the core network element, where the path switching confirmation message includes the second SN information.
The apparatus according to any one of claims 51 to 53, wherein the first SN is a PDCP SN, a general packet radio service tunneling protocol GTP-user plane USN or a quality of service flow identifier QFI SN.
The apparatus according to claim 54, wherein there is a preset mapping relationship between the PDCP SN and the GTP-US SN; or, between the combination of the QFI and the QFI SN and the PDCP SN There is a preset mapping relationship.
A communication device, characterized in that the device includes a processing module and a communication module connected to the processing module; the processing module is used to generate a handover request message, and the handover request message is used to request that a terminal device be connected from a source to The network access device is switched to the target access network device;

the communication module, configured to send the handover request message to the target access network device;

The communication module is further configured to receive fourth information from the target access network device, where the fourth information is used to instruct the source access network device to forward the information before the first SN to the target access network device. MBS service data of the terminal device corresponding to at least one SN.
The apparatus according to claim 56, wherein the first SN is a PDCP SN, a GTP-US SN or a QFI SN.
The apparatus according to claim 57, wherein a preset mapping relationship exists between the PDCP SN and the GTP-US SN; or, there is a preset mapping relationship between the combination of QFI and QFI SN and the PDCP SN set mapping relationship.
A computer-readable storage medium, characterized in that the computer-readable storage medium stores computer instructions, which, when the computer instructions are executed on a computer, cause the computer to execute the method described in any one of claims 1 to 29. method.
A chip, characterized in that the chip includes a processing circuit and a transceiver pin; the processing circuit is used to perform the processing operation in the method according to any one of claims 1 to 29, and the transceiver pin is used for in performing the communication operation in the method of any one of claims 1 to 29.
A computer program product, characterized in that, when the computer program product is run on a computer, the computer is caused to execute the method of any one of claims 1 to 29.