Data processing method, electronic device, storage medium, and program product

By introducing RB groups and shared entities into the radio bearer protocol, the problem of lack of correlation between radio bearer protocol entities is solved, enabling synchronous transmission of related services and improving user experience.

WO2026016636A1PCT designated stage Publication Date: 2026-01-22ZTE CORP
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
PCT/CN2025/097178
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2024-07-18
Filing Date
2025-05-26
Publication Date
2026-01-22

AI Technical Summary

Technical Problem

In existing technologies, the lack of correlation between wireless bearer protocol entities between network devices and wireless terminals makes it impossible to guarantee the synchronization of related service transmissions, affecting the user's service experience, especially in service scenarios such as video calls and extended reality.

Method used

The concept of RB groups is introduced, which divide RBs with business relevance into RB groups and set up shared entities within RB groups to provide shared services such as SN allocation, header compression, data encryption and integrity protection. The synchronization of related services is ensured through the expected send variable values ​​and receive window mechanism maintained by the RB groups.

Benefits of technology

The RB group mechanism enables synchronous processing of services across different bearers, improving the consistency of user service experience and transmission efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN2025097178_22012026_PF_FP_ABST
    Figure CN2025097178_22012026_PF_FP_ABST
Patent Text Reader

Abstract

The present application provides a data processing method, an electronic device, a storage medium, and a program product. The method comprises: acquiring multiple target transmit entities belonging to a same resource bearer (RB) group, and an expected transmit variable value of the RB group (S110); on the basis of the expected transmit variable value, configuring a sequence variable value of a service data unit (SDU) from an upper layer received by any one of the target transmit entities (S120); updating the expected transmit variable value according to a preset step size value, so that sequence variable values corresponding to multiple SDUs in the same group can be made sequential, causing PDUs generated on the basis of the SDUs to also be sequential (S130).
Need to check novelty before this filing date? Find Prior Art

Description

Data processing method, electronic device, storage medium, and program product

[0001] Cross-reference to related applications

[0002] This application is based on and claims priority to Chinese Patent Application No. 202410971405.3, filed on July 18, 2024, the entire contents of which are incorporated herein by reference. TECHNICAL FIELD

[0003] Embodiments of the present application relate to the field of communication technology, and in particular to a data processing method, an electronic device, a computer readable storage medium, and a computer program product. BACKGROUND

[0004] A radio bearer (RB) is a general term for different layer protocol entities and configurations allocated by a network device for a wireless terminal. Multiple RBs can be established between the network device and the wireless terminal, and each RB contains protocol entities for implementing transmission functions. The protocol entities corresponding to different RBs have no correlation, but in actual applications, the services carried by the protocol entities corresponding to different RBs can have correlation. The transmission of these associated services cannot be guaranteed to be synchronized, which to some extent affects the user's service perception. SUMMARY

[0005] Embodiments of the present application provide a data processing method, an electronic device, a computer readable storage medium, and a computer program product.

[0006] In a first aspect, embodiments of the present application provide a data processing method, which includes: obtaining multiple target sending entities belonging to the same resource bearer (RB) group and an expected sending variable value of the RB group; configuring a sequence variable value of a service data unit (SDU) from an upper layer received by any of the target sending entities according to the expected sending variable value; and updating the expected sending variable value according to a preset step value.

[0007] In a second aspect, embodiments of the present application provide a data processing method, which includes: obtaining multiple target receiving entities belonging to the same resource bearer (RB) group; in response to any of the target receiving entities receiving a protocol data unit (PDU) from a lower layer, obtaining a sequence variable value of the PDU; and in a case where the sequence variable value is greater than a lower edge variable value of a receiving window of the RB group, placing the PDU in the receiving window of the RB group to wait for submission to an upper layer.

[0008] In a third aspect, an electronic device is provided, and the electronic device includes at least one processor, at least one memory configured to store at least one program, and the at least one program is configured to cause the at least one processor to implement the data processing method according to the first aspect or the data processing method according to the second aspect.

[0009] In a fourth aspect, a computer-readable storage medium is provided, and the computer-readable storage medium stores a computer program, and the computer program is configured to cause a processor to implement the data processing method according to the first aspect or the data processing method according to the second aspect.

[0010] In a fifth aspect, a computer program product is provided, and the computer program product includes a computer program, and the computer program is configured to cause a processor to implement the data processing method according to the first aspect or the data processing method according to the second aspect. BRIEF DESCRIPTION OF DRAWINGS

[0011] FIG. 1 is a schematic diagram of a user plane protocol stack architecture of long term evolution;

[0012] FIG. 2 is a schematic diagram of a user plane protocol stack architecture of new radio;

[0013] FIG. 3 is a schematic diagram of a RB established between a base station and a UE according to an embodiment of the present application;

[0014] FIG. 4 is a schematic diagram of a function architecture of a sending end PDCP entity and a receiving end PDCP entity according to an embodiment of the present application;

[0015] FIG. 5 is a schematic diagram of an implementation environment of the data processing method according to an embodiment of the present application;

[0016] FIG. 6 is a schematic diagram of a data processing method according to an embodiment of the present application;

[0017] FIG. 7 is a schematic diagram of a data processing method according to an embodiment of the present application;

[0018] FIG. 8 is a schematic diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0019] In order to make the objectives, technical solutions and advantages of the present application clearer, further detailed description will be made to the present application with reference to the accompanying drawings and embodiments. It should be understood that the embodiments described herein are only used to explain the present application, and are not used to limit the present application.

[0020] A user plane protocol stack is a collection of protocols and interfaces used to handle the transmission of user data (such as voice, video, and data packets) in a mobile communication system. The implementation of the user plane protocol stack can vary in different mobile communication systems.

[0021] FIG. 1 is a schematic diagram of a user plane protocol stack architecture of a long term evolution (LTE). As shown in FIG. 1, in the LTE user plane protocol stack architecture, there are, from top to bottom, a packet data convergence protocol (PDCP) layer, a radio link control (RLC) protocol layer, a medium access control (MAC) protocol layer, and a physical layer (PHY).

[0022] FIG. 2 is a schematic diagram of a user plane protocol stack architecture of a new radio (NR). As shown in FIG. 2, compared with the LTE user plane protocol stack, the NR user plane protocol stack adds a service data adaptation protocol (SDAP) layer, and the NR user plane protocol stack, from top to bottom, includes the SDAP layer, the PDCP layer, the RLC layer, the MAC layer, and the PHY layer.

[0023] A radio bearer (RB) is a general term for different layer protocol entities and configurations allocated by a network device (such as a base station) for a wireless terminal (such as a user equipment (UE)), including a PDCP protocol entity, an RLC protocol entity, a MAC protocol entity, and a series of resources allocated by the PHY. The RB is a channel (including the PHY, the MAC, the RLC, and the PDCP) connecting the network device and the wireless terminal over a wireless interface (Uu interface), and any data transmitted over the wireless interface has to go through the RB.

[0024] It should be understood that there can be multiple RBs between the network device and the wireless terminal, and each RB contains protocol entities (such as the PDCP protocol entity, the RLC protocol entity, and the MAC protocol entity) used to implement the transmission function.

[0025] FIG. 3 is a schematic diagram of RBs established between a base station and a UE according to an embodiment of the present application. As shown in FIG. 3, the base station and the UE establish radio bearers RB1, RB2, RB3 and RB4, the RB1 includes PDCP entity-11 and PDCP entity-21, the RB2 includes PDCP entity-21 and PDCP entity-22, the RB3 includes PDCP entity-13 and PDCP entity-23, and the RB4 includes PDCP entity-14 and PDCP entity-24. The base station is an NR base station, i.e., a gNB (next Generation NodeB). The two entities in one RB in FIG. 3 are a sending-end PDCP entity and a receiving-end PDCP entity, respectively.

[0026] FIG. 4 is a schematic diagram of the functional architecture of a sending-end PDCP entity and a receiving-end PDCP entity according to an embodiment of the present application. As shown in FIG. 4, the sending-end PDCP entity includes the following functions: SN allocation (Transmission buffer: Sequence numbering), header compression (Header Compression), data ciphering (Ciphering) and integrity protection (Integrity Protection). The receiving-end PDCP entity includes the following functions: SN reordering (Reception buffer: Reordering), header decompression (Header Decompression), data deciphering (Deciphering) and integrity verification (Integrity Vertification).

[0027] It should be understood that there is no correlation between multiple protocol entities of the sending end or multiple protocol entities of the receiving end in the existing standard, but in actual application, the services carried by different protocol entities can have correlation. Therefore, the current protocol entity design is not sufficient to meet the service scenario with strong correlation. Typical service scenarios are, for example, video calls over new radio (ViNR), extended reality (XR) and the like. In such service models, voice, video and data messages rely on different bearers or different protocol entities. However, because of the irrelevance between protocol entities, the transmission synchronization of the associated voice, video and data services cannot be guaranteed, which affects the user service perception to some extent.

[0028] In view of this, the embodiments of the present application provide a data processing method, an electronic device, a computer readable storage medium and a computer program product, aiming to solve the technical problem of synchronization of correlated service transmission.

[0029] FIG. 5 is a schematic diagram of an implementation environment of the data processing method according to an embodiment of the present application. As shown in FIG. 5, the implementation environment includes a sending end and a receiving end. In an embodiment, the sending end is located at a network device side, and the receiving end is located at a terminal device side. In another embodiment, the sending end is located at a terminal device side, and the receiving end is located at a network device side.

[0030] The network device includes a base station, which can be an evolutional node B (eNB or eNodeB), a base station device gNB in a 5G network, or a base station in a future communication system, and the base station can include various macro base stations, micro base stations, home base stations, wireless remote, reconfigurable intelligent surface (RIS), routers, wireless fidelity (WIFI) devices, and various network side devices.

[0031] The terminal device includes a user terminal UE, which can be a mobile phone, a tablet computer (Pad), a computer with wireless transceiver function, a virtual reality (VR) terminal, an augmented reality (AR) terminal, a wireless terminal in industrial control, a wireless terminal in self driving, and various user side devices.

[0032] In the embodiments of the present application, the sending end includes multiple sending entities, as shown in FIG. 5, including sending entity 1, sending entity 2, sending entity 3, and sending entity 4. These sending entities uniquely correspond to one RB, for example, sending entity 1 uniquely corresponds to RB1, sending entity 2 uniquely corresponds to RB2, sending entity 3 uniquely corresponds to RB3, and sending entity 4 uniquely corresponds to RB4.

[0033] In the embodiments of the present application, based on the association characteristics of services between multiple bearers, the concept of RB group (RB GROUP) is proposed. The RBs with service association are divided into one RB group, so that the multiple entities corresponding to the multiple RBs with service association can be considered as belonging to the same RB group.

[0034] As shown in the example of FIG. 5, RB1 and RB2 are divided into RB GROUP1, and RB3 and RB4 are divided into RB GROUP2, thus it can be obtained that the sending entity 1 and the sending entity 2 belong to the RB GROUP1, and the sending entity 3 and the sending entity 4 belong to the RB GROUP2. In the example of FIG. 5, the sending end is further provided with an RB GROUP1 sending end common entity and an RB GROUP2 sending end common entity, wherein the RB GROUP1 sending end common entity is configured to provide common services for the sending entity 1 and the sending entity 2 belonging to the RB GROUP1, and the RB GROUP2 sending end common entity is configured to provide common services for the sending entity 3 and the sending entity 4 belonging to the RB GROUP2.

[0035] In the embodiment of the present application, the common services that can be provided by the sending end common entity include one or more of the following: SN allocation, header compression, data encryption and integrity protection.

[0036] In the embodiment of the present application, the receiving end includes a plurality of receiving entities, as shown in FIG. 5, including the receiving entity 1, the receiving entity 2, the receiving entity 3 and the receiving entity 4, which respectively uniquely correspond to one RB, for example, the receiving entity 1 uniquely corresponds to the RB1, the receiving entity 2 uniquely corresponds to the RB2, the receiving entity 3 uniquely corresponds to the RB3, and the receiving entity 4 uniquely corresponds to the RB4. As shown in the example of FIG. 5, the RB1 and the RB2 are divided into the RB GROUP1, and the RB3 and the RB4 are divided into the RB GROUP2, thus it can be obtained that the receiving entity 1 and the receiving entity 2 belong to the RB GROUP1, and the receiving entity 3 and the receiving entity 4 belong to the RB GROUP2. In the example of FIG. 5, the receiving end is further provided with an RB GROUP1 receiving end common entity and an RB GROUP2 receiving end common entity, wherein the RB GROUP1 receiving end common entity is configured to provide common services for the receiving entity 1 and the receiving entity 2 belonging to the RB GROUP1, and the RB GROUP2 receiving end common entity is configured to provide common services for the receiving entity 3 and the receiving entity 4 belonging to the RB GROUP2.

[0037] In the embodiment of the present application, the common services that can be provided by the receiving end common entity include one or more of the following: SN reordering, header decompression, data decryption and integrity verification.

[0038] It should be understood that the sending entity is configured to process a service data unit (SDU) received from a first protocol layer into a protocol data unit (PDU) and then deliver the PDU to a second protocol layer, and the receiving entity is configured to process a PDU received from the second protocol layer into an SDU and then deliver the SDU to the first protocol layer.

[0039] wherein the first protocol layer represents an upper protocol layer and the second protocol layer represents a lower protocol layer. In an embodiment of the present application, the first protocol layer is a PDCP layer and the second protocol layer is an RLC layer; in another embodiment of the present application, the first protocol layer is an RLC layer and the second protocol layer is a MAC layer.

[0040] In the embodiments of the present application, the first protocol layer is exemplarily taken as a PDCP layer and the second protocol layer is exemplarily taken as an RLC layer. The sending entity of the PDCP layer can be referred to as a PDCP sending entity. In the example of FIG. 5, the sending entity 1, the sending entity 2, the sending entity 3 and the sending entity 4 can all be PDCP sending entities, and the PDCP sending entities are configured to deliver the PDCP PDUs processed from the PDCP SDUs received from the upper layer (the SDAP layer) to the lower layer (the RLC layer). The receiving entity of the PDCP layer can be referred to as a PDCP receiving entity. In the example of FIG. 5, the receiving entity 1, the receiving entity 2, the receiving entity 3 and the receiving entity 4 can all be PDCP receiving entities, and the PDCP receiving entities are configured to deliver the PDCP SDUs processed from the PDCP PDUs received from the lower layer (the RLC layer) to the upper layer (the SDAP layer).

[0041] It should be understood that the belonging relationship of the RB and the RB GROUP, and the sharing relationship of the related services in the RB GROUP, can be configured according to the correlation characteristics of the services between the bearers at the beginning of the RB establishment. For example, for the ViNR video call service, in order to ensure the audio-video synchronization, the 5QI1 audio bearer and the 5QI2 video bearer can be attributed to the same RB GROUP; for the new wireless call service, in order to ensure the audio-video-data synchronization, the 5QI1 audio bearer, the 5QI2 video bearer and the DC data bearer can be attributed to the same RB GROUP. Meanwhile, in order to ensure the synchronous processing of the audio, video and DC data services, the bearers in the RB GROUP can share the SN allocation service of the PDCP entity sending end and the SN reordering service of the PDCP entity receiving end.

[0042] Meanwhile, in order to ensure the configuration synchronization of the RB GROUP between the base station and the terminal device, the base station can notify the terminal device of the belonging relationship of the RB and the GROUP, and the sharing relationship of the related services in the RB GROUP through the PDCP or RLC related configuration message at the beginning of the RB establishment.

[0043] FIG. 6 is a schematic diagram of a data processing method provided by an embodiment of the present application. The method can be applied to a sending end and is executed by a sending end sharing entity in the sending end. As shown in FIG. 6, the method comprises the following steps:

[0044] In step S110, a plurality of target sending entities belonging to the same resource bearer RB group and an expected sending variable value of the RB group are acquired.

[0045] For example, the correspondence between the RBs and the RB groups can be preconfigured, and then the RB group corresponding to the sending entity is determined according to the RB corresponding to the sending entity. The sending entities corresponding to the same RB group are the target sending entities belonging to the same RB group.

[0046] For example, each RB group maintains a value of an expected sending variable, which is a state variable of the sending end and can be denoted as TX_NEXT. Under the PDCP protocol, TX_NEXT is used to indicate the COUNT value (composed of a hyper frame number (HFN) and a sequence number (SN)) of the next transmission of the PDCP SDU of the RB group; under the RLC protocol, TX_NEXT is used to indicate the SN value of the next transmission of the RLC SDU of the RB group.

[0047] In step S120, a sequence variable value of a service data unit (SDU) received from an upper layer by any target sending entity is configured according to the value of the expected sending variable.

[0048] For example, under the PDCP protocol, the sequence variable value represents the COUNT value of the SDU. The target sending entity of the RB group receives the SDU from the upper layer, and then associates the current value of the expected sending variable (TX_NEXT) maintained by the RB group to the COUNT value of the SDU. Under the PDCP protocol, the SN of the SDU can also be determined according to the value of the expected sending variable (TX_NEXT).

[0049] For example, under the RLC protocol, the sequence variable value represents the RLC SN value of the SDU. The target sending entity of the RB group receives the SDU from the upper layer, and then associates the current value of the expected sending variable (TX_NEXT) maintained by the RB group to the RLC SN value of the SDU.

[0050] In step S130, the value of the expected sending variable is updated according to a preset step value.

[0051] It should be understood that after the sequence variable value of the SDU is configured, the value of the expected sending variable (TX_NEXT) needs to be updated according to a preset step value, so as to configure the sequence variable value of the next SDU according to the updated value of the expected sending variable (TX_NEXT). The preset step value can be 1, that is, TX_NEXT is updated as follows: TX_NEXT = TX_NEXT + 1.

[0052] In the embodiments of the present application, the service SDUs with correlation are associated by the RB group, the sequence variable values of the SDUs in the group are uniformly configured by using the expected sending variable value maintained by the RB group, the order of the sequence variable values of the associated SDUs is ensured, and the services with correlation are sequentially transmitted according to the sequence variable values in the transmission process, so as to improve the synchronization of service transmission.

[0053] For example, after the sequence variable values of the SDUs are configured according to the expected sending variable value, the following one or more processes are further performed on the SDUs: header compression process, data encryption process and integrity protection process.

[0054] In the embodiments of the present application, the RB group can provide the common services of header compression, data encryption and integrity protection in addition to providing the SN allocation common service for the target sending entities in the group. The contents of the common services can be adjusted according to actual needs, and the embodiments of the present application do not make specific limitations.

[0055] For example, under the PDCP protocol, the data encryption and integrity protection are performed on the SDUs by using the COUNT values associated with the SDUs.

[0056] For example, before the multiple target sending entities belonging to the same resource bearer RB group are obtained, the configuration information synchronized with the network device and the terminal device is further obtained; the RB group to which the RB belongs is determined according to the configuration information; the sending entity corresponding to the RB is obtained; and the sending entity corresponding to the RB is taken as the target sending entity belonging to the RB group.

[0057] In the embodiments of the present application, the configuration information of the RB group is synchronized in advance between the network device and the terminal device, so that the network device and the terminal device can both know the ownership relationship between the RB and the RB group in advance by using the configuration information. The target sending entity corresponding to the RB group can be determined by the sending entity corresponding to the RB, regardless of whether the sending entity is located in the network device or the terminal device.

[0058] FIG. 7 is a schematic diagram of a data processing method provided by the embodiments of the present application, which can be applied to a receiving end and is executed by a receiving end common entity in the receiving end. As shown in FIG. 7, the method includes the following steps:

[0059] In step S210, the multiple target receiving entities belonging to the same resource bearer RB group are obtained.

[0060] For example, the correspondence between the RB and the RB group can be configured in advance, and then the RB group corresponding to the receiving entity is determined according to the RB corresponding to the receiving entity. The receiving entities corresponding to the same RB group are the target receiving entities belonging to the same RB group.

[0061] Step S220, in response to any target receiving entity receiving a protocol data unit (PDU) from a lower layer, obtaining a sequence variable value of the PDU.

[0062] For example, under the PDCP protocol, the sequence variable value represents a COUNT value (RCVD_COUNT) of the PDU. The target receiving entity of the RB group receives the PDU from the upper layer, can extract the SN (RCVD_SN) from the PDU, and then obtains the RCVD_HFN of the RB group at the receiving end, and then splices the RCVD_HFN and the RCVD_SN to obtain the RCVD_COUNT.

[0063] For example, under the RLC protocol, the sequence variable value represents an SN value of the PDU, and the target receiving entity of the RB group receives the PDU from the upper layer, can extract the SN (RCVD_SN) from the PDU.

[0064] Step S230, in the case where the sequence variable value is greater than a lower edge variable value of a receiving window of the RB group, placing the PDU in the receiving window of the RB group to wait for submission to the upper layer.

[0065] For example, a receiving window and a receiving window related variable are maintained separately for each RB group, wherein the receiving window related variable includes a lower edge variable value (RX_DELIV), and the RX_DELIV indicates a sequence variable value associated with a first SDU that has not been submitted to the upper layer, and the RX_DELIV is updated incrementally as the SDU is submitted to the upper layer.

[0066] For example, under the PDCP protocol, the RX_DELIV can represent a COUNT value associated with a first PDCP SDU that has not been submitted to the upper layer in the receiving window. Under the RLC protocol, the RX_DELIV can represent an SN value associated with a first RLC SDU that has not been submitted to the upper layer in the receiving window. Taking the PDCP protocol transmission as an example, if the COUNT value of the PDCP PDU received by the PDCP receiving entity from the lower layer is greater than the RX_DELIV, it indicates that the PDCP PDU introduces out-of-order, and the PDCP PDU needs to be stored in the receiving window maintained by the RB group, and wait until the RX_DELIV points to the COUNT value of the PDCP PDU, and then submit to the upper layer. In this way, the PDCP PDU is reordered according to the COUNT value assigned by the RB group at the receiving end, and a plurality of PDCP PDUs having service association are processed into corresponding PDCP SDUs after reordering, and the PDCP SDUs in the RB group are submitted to the upper layer in ascending order of the COUNT value, thereby ensuring the synchronization of the associated service transmission.

[0067] Exemplarily, after obtaining the sequence variable value of the PDU, the PDU is delivered to the upper layer in the case that the sequence variable value is equal to the lower edge variable value of the receiving window of the RB group.

[0068] That is, in response to any target receiving entity receiving a protocol data unit (PDU) from a lower layer, obtaining the sequence variable value of the PDU, if the sequence variable value of the PDU is equal to the lower edge variable value of the receiving window of the RB group, directly processing the PDU into an SDU without waiting, and then delivering the SDU to the upper layer. Taking PDCP protocol transmission as an example, if the COUNT value of the PDCP PDU received by the PDCP receiving entity from the lower layer is exactly equal to RX_DELIV, the PDCP PDU can be directly processed into a PDCP SDU, and then delivered to the upper layer.

[0069] Exemplarily, before delivering the PDU to the upper layer, the PDU is also decompressed. By decompressing the PDU, a corresponding SDU is obtained, and then the SDU is delivered to the upper layer.

[0070] Exemplarily, after obtaining the sequence variable value of the PDU, the PDU is discarded in the case that the sequence variable value is equal to the lower edge variable value of the receiving window of the RB group.

[0071] That is, in response to any target receiving entity receiving a protocol data unit (PDU) from a lower layer, obtaining the sequence variable value of the PDU, if the sequence variable value of the PDU is less than the lower edge variable value of the receiving window of the RB group, discarding the PDU without processing and transmitting it. Taking PDCP protocol transmission as an example, if the COUNT value of the PDCP PDU received by the PDCP receiving entity from the lower layer is less than RX_DELIV, the PDCP PDU is directly discarded.

[0072] Exemplarily, after placing the PDU in the receiving window of the RB group to wait for delivery to the upper layer, the expected receiving variable value of the RB group is also updated to the sum of the sequence variable value of the PDU and a preset step value in the case that the sequence variable value is greater than the expected receiving variable value of the RB group.

[0073] In the embodiments of the present application, each RB group also maintains an expected receiving variable value (RX_NEXT) at the receiving end.

[0074] RX_NEXT is used to indicate the sequence variable value of the next PDU expected to be received. For example, under the PDCP protocol, the expected receiving variable value (RX_NEXT) represents the COUNT value of the next PDCP PDU expected to be received. For another example, under the RLC protocol, the expected receiving variable value (RX_NEXT) represents the SN value of the next RLC PDU expected to be received.

[0075] For example, if the COUNT value of the PDCP PDU received by the PDCP receiving entity from the lower layer is greater than the RX_NEXT value, it indicates that the RCVD_COUNT is the highest value in the receiving window, and RX_NEXT=RCVD_COUNT+1 is executed, where the step value is 1.

[0076] For example, after updating the expected receiving variable value of the RB group to the sum of the sequence variable value of the PDU and the preset step value, the reordering variable value of the RB group is also updated to the expected receiving variable value, and the reordering timer is started, in the case that the reordering timer of the RB group is not running.

[0077] In the embodiments of the present application, the reordering variable value (RX_REORD) of each RB group is also maintained separately at the receiving end, and RX_REORD indicates the COUNT+1 of the PDU triggering the reordering timer (t-Reordering), which can be used to determine whether the reordering timer meets the stop running condition.

[0078] For example, if RX_DELIV is less than RX_NEXT (the expected receiving variable value), it indicates that there is a hole in the current receiving window. In the case that the reordering timer (t-Reordering) maintained by the RB group is not started and there is a hole in the receiving window, the reordering timer needs to be started for RX_NEXT. In some embodiments, RX_REORD=RX_NEXT is updated, and the t-Reordering timer is started to wait, where the waiting time of the t-Reordering timer can be set according to the service characteristics in the RB group.

[0079] RX_NEXT, and the t-Reordering timer is started to wait, where the waiting time of the t-Reordering timer can be set according to the service characteristics in the RB group.

[0080] For example, after starting the reordering timer, the reordering timer is also stopped in the case that the lower edge variable value is greater than or equal to the reordering variable value.

[0081] It should be understood that if RX_DELIV is greater than or equal to RX_REORD, it indicates that the last PDU in the receiving window is due to be submitted to the upper layer, and at this time, the t-Reordering timer can be stopped.

[0082] For example, after starting the reordering timer, in the case that the reordering timer times out, the PDU with a sequence variable value less than the reordering variable value in the receiving window and the continuous PDU starting from the reordering variable value are submitted to the upper layer; and the lower edge variable value is updated to the sequence variable value of the first PDU that has not been submitted to the upper layer.

[0083] It should be understood that if the t-Reordering timer expires, and there are still PDUs in the receiving window that have not been delivered to the upper layer, then the PDUs with sequence variable values less than the reordering variable value in the receiving window and the consecutive PDUs starting from the reordering variable value are forced to be delivered to the upper layer, and then the lower edge variable value is updated to the sequence variable value of the first PDU that has not been delivered to the upper layer.

[0084] For example, after obtaining the sequence variable value of the PDU, before placing the PDU in the receiving window of the RB group to wait for delivery to the upper layer, the PDU can also be subjected to one or more of the following processing:

[0085] Decrypting the PDU according to the sequence variable value;

[0086] Integrity verifying the PDU according to the sequence variable value.

[0087] For example, the PDU can be decrypted using the sequence variable value first, and then integrity verified using the sequence variable value. If the integrity verification fails, the corresponding data PDU is discarded, otherwise the decrypted data SDU is stored in the corresponding receiving window according to the judgment result of whether the RB group shares the reordering sliding window service.

[0088] For example, before obtaining the multiple target receiving entities belonging to the same resource bearer RB group, the method further includes: obtaining configuration information synchronized with the network device and the terminal device; determining the RB group to which the RB belongs according to the configuration information; obtaining the receiving entity corresponding to the RB; and taking the receiving entity corresponding to the RB as the target receiving entity belonging to the RB group.

[0089] In the embodiment of the application, the configuration information of the RB group is synchronized in advance between the network device and the terminal device, so that the network device and the terminal device can both know the ownership relationship between the RB and the RB group in advance through the configuration information. The receiving end, whether located in the network device or the terminal device, can determine the target sending entity corresponding to the RB group according to the receiving entity corresponding to the RB.

[0090] The data processing method applied to the sending end by the embodiment of the application will be described below by taking the NR communication scenario as an example.

[0091] In a possible NR communication scenario, the sending end includes a PDCP sending entity 1 and a PDCP sending entity 2, wherein the PDCP sending entity 1 corresponds to RB1 uniquely, the PDCP sending entity 2 corresponds to RB2 uniquely, and RB1 and RB2 both belong to RBGROUP1, and thus the PDCP sending entity 1 and the PDCP sending entity 2 can be considered to belong to RBGROUP1. The common services of RBGROUP1 include SN allocation, header compression, data encryption and integrity protection. In this scenario, the data processing method of the embodiment of the application can include the following steps:

[0092] Step S301, the PDCP sending entity 1 receives a PDCP SDU1 from an upper layer SDAP layer.

[0093] Step S302, a TX_NEXT value (i.e., an expected sending variable value) maintained by RB GROUP1 is obtained.

[0094] Wherein, TX_NEXT is a state variable of the sending end, indicating a next COUNT value to be allocated, wherein the COUNT value is composed of an HFN and a PDCP SN.

[0095] Step S303, a COUNT value (i.e., a sequence variable value) indicated by TX_NEXT is associated to the PDCP SDU1, and a PDCP SN1 of the PDCP SDU1 is calculated according to TX_NEXT.

[0096] Step S304, TX_NEXT is updated as TX_NEXT+1, so as to update the TX_NEXT value according to a preset step value.

[0097] Step S305, the PDCP SDU1 is sequentially subjected to header compression, integrity protection and data encryption, to generate a PDCP PDU1, wherein the PDCP PDU1 carries the above PDCP SN1.

[0098] Step S306, the PDCP PDU1 is submitted to a lower layer RLC layer.

[0099] Step S307, the PDCP sending entity 2 receives a PDCP SDU2 from the upper layer SDAP layer.

[0100] Step S308, a TX_NEXT value maintained by RB GROUP1 is obtained.

[0101] Step S309, a COUNT value (i.e., a sequence variable value) indicated by TX_NEXT is associated to the PDCP SDU2, and a PDCP SN2 of the PDCP SDU2 is calculated according to TX_NEXT.

[0102] Step S310, updating TX_NEXT=TX_NEXT+1 to update the TX_NEXT value according to a preset step value.

[0103] Step S311, performing header compression, integrity protection and data encryption on the PDCP SDU2 in sequence to generate a PDCP PDU2, wherein the PDCP PDU2 carries the PDCP SN2.

[0104] Step S312, submitting the PDCP PDU2 to the lower layer RLC layer.

[0105] In the above scenario, the PDCP sending entity 1 and the PDCP sending entity 2 having service correlation are associated through the RB GROUP 1, and then the PDCP SDU1 received by the PDCP sending entity 1 and the PDCP SDU2 received by the PDCP sending entity 2 are associated with SN allocation through the common service, so that the corresponding PDCP PDU1 and PDCP PDU2 can be reordered in sequence based on the COUNT value obtained by the SN at the receiving end, and the corresponding service can obtain synchronous and efficient processing.

[0106] The data processing method of the embodiment of the application applied to the receiving end will be described below by taking an NR communication scenario as an example.

[0107] In a possible NR communication scenario, the receiving end includes a PDCP receiving entity 1 and a PDCP receiving entity 2, wherein the PDCP receiving entity 1 corresponds to RB1 uniquely, the PDCP receiving entity 2 corresponds to RB2 uniquely, and the RB1 and the RB2 both belong to the RB GROUP 1, so the PDCP receiving entity 1 and the PDCP receiving entity 2 can be considered to belong to the RB GROUP 1. The common service of the RB GROUP 1 includes SN reordering, header decompression, data decryption and integrity verification. In this scenario, the data processing method of the embodiment of the application can include the following steps:

[0108] Step S401, the PDCP receiving entity 1 receives the PDCP PDU1 from the lower layer RLC layer.

[0109] Step S402, parsing the header information of the PDCP PDU1 to obtain the SN of the PDCP PDU1, and calculating the COUNT value (i.e. sequence variable value, which can be denoted as RCVD_COUNT) corresponding to the PDCP PDU1 based on the SN.

[0110] Step S403, obtaining the RX_NEXT value (i.e. expected receiving variable value) and the RX_DELIV (i.e. lower edge variable value) of the receiving window maintained by the RB GROUP 1.

[0111] RX_NEXT indicates the COUNT value of the next PDCP PDU expected to be received, and RX_DELIV indicates the COUNT value associated with the first SDU not yet delivered to the upper layer in the receiving window maintained by the RB GROUP 1.

[0112] Step S404, decrypt and integrity verify PDCP PDU1 based on the COUNT value corresponding to PDCP PDU1.

[0113] Step S405, judge whether the integrity verification is successful, if yes, continue to execute step S406, otherwise discard PDCP PDU1.

[0114] Step S406, if RCVD_COUNT < RX_DELIV, discard PDCP PDU1.

[0115] Step S407, if RCVD_COUNT = RX_DELIV, it means that PDCP PDU1 is not introduced out of order, and there is no need to wait for sequencing, and PDCP PDU1 is directly header decompressed to be processed into PDCP SDU1 and delivered to the upper SDAP layer.

[0116] Step S408, if RCVD_COUNT > RX_DELIV, PDCP PDU1 is placed in the receiving window maintained by the RB GROUP 1, and waits for delivery to the upper SDAP layer in the receiving window.

[0117] For example, the COUNT value of PDCP PDU1 is 11 (i.e. RCVD_COUNT = 11), RX_DELIV = 8, which means that there is a hole in the current receiving window, and PDCP PDU1 needs to wait for delivery in the receiving window.

[0118] Step S409, if RCVD_COUNT >= RX_NEXT, it means that RCVD_COUNT is the highest value in the receiving window, and RX_NEXT = RCVD_COUNT + 1 is updated.

[0119] For example, the current RCVD_COUNT = 11, RX_NEXT = 10, and then RX_NEXT = 12 is updated.

[0120] Step S410, if RX_DELIV < RX_NEXT, and the t-Reordering timer is not running, RX_REORD = RX_NEXT is updated, and the t-Reordering timer is started to wait, wherein the waiting time of the t-Reordering timer can be set according to the characteristics of the services in the RB GROUP 1.

[0121] For example, if RX_DELIV=8, RX_NEXT=12, and the t-Reordering timer is not running, then RCVD_COUNT is updated to 12 and the t-Reordering timer is started.

[0122] Step S411: If the t-Reordering timer is not expired and RX_DELIV≥RX_RECORD, then the t-Reordering timer is stopped.

[0123] When RX_DELIV points to the COUNT value 11 corresponding to PDCP PDU1, PDCP PDU11 is submitted to the upper layer. When RX_DELIV points to the value 12 of RCVD_COUNT, it indicates that PDCP PDU11 has been delivered, so the t-Reordering timer can be stopped.

[0124] Step S412: If the t-Reordering timer is expired and the hole message in the receiving window is not received, then forced delivery is performed. The PDCP PDUs with COUNT<RX_RECORD and the consecutive PDCP PDUs starting from RX_RECORD are decompressed and delivered to the upper layer in ascending order of COUNT values. Meanwhile, RX_DELIV is updated to the COUNT value of the first PDCP SDU that has not been transmitted to the upper layer.

[0125] In the above scenario, PDCP receiving entity 1 and PDCP receiving entity 2 having service correlation are associated through RB GROUP1, and then PDCP PDU1 received by PDCP receiving entity 1 and PDCP PDU2 received by PDCP receiving entity 2 are reordered through the common service, so that the corresponding PDCP SDU1 and PDCP SDU2 are delivered to the upper layer in ascending order, thereby realizing synchronous and efficient processing of the correlated service.

[0126] The following takes the LTE communication scenario as an example to illustrate the data processing method applied to the sending end by the embodiments of the present application.

[0127] In a possible LTE communication scenario, the sending end includes RLC sending entity 1 and RLC sending entity 2, wherein the RLC sending entity 1 corresponds to RB 1 uniquely, the RLC sending entity 2 corresponds to RB 2 uniquely, and the RB 1 and the RB 2 both belong to the RB GROUP 1, and thus the RLC sending entity 1 and the RLC sending entity 2 can be considered as belonging to the RB GROUP 1. The common services of the RB GROUP 1 include SN allocation, header compression, data encryption and integrity protection. In this scenario, the data processing method of the embodiment of the application can include the following steps:

[0128] Step S501: The RLC sending entity 1 receives the RLC SDU 1 from the upper PDCP layer.

[0129] Step S502: The TX_NEXT value (i.e. the expected sending variable value) maintained by the RB GROUP 1 is acquired.

[0130] Wherein, the TX_NEXT is a state variable of the sending end, indicating the RLC SN 1 to be allocated.

[0131] Step S503: The RLC SN of the RLC SDU 1 is determined based on the TX_NEXT.

[0132] Step S504: The TX_NEXT is updated as TX_NEXT=TX_NEXT+1, so as to update the TX_NEXT value according to the preset step value.

[0133] Step S505: The RLC SDU 1 is sequentially subjected to the header compression, the integrity protection and the data encryption, to generate the RLC PDU 1.

[0134] Step S506: The RLC PDU 1 is submitted to the lower MAC layer.

[0135] Step S507: The RLC sending entity 2 receives the RLC SDU 2 from the upper PDCP layer.

[0136] Step S508: The TX_NEXT value maintained by the RB GROUP 1 is acquired.

[0137] Step S509: The RLC SN 2 of the RLC SDU 2 is determined based on the TX_NEXT.

[0138] Step S510: The TX_NEXT is updated as TX_NEXT=TX_NEXT+1, so as to update the TX_NEXT value according to the preset step value.

[0139] Step S511: After the RLC SDU 2 is processed into the RLC PDU 2, the RLC PDU 2 is submitted to the lower MAC layer.

[0140] In the above scenario, RLC sending entity 1 and RLC sending entity 2 with service correlation are associated through RB GROUP 1, and then the RLC SDU 1 received by RLC sending entity 1 and the RLC SDU 2 received by RLC sending entity 2 are associated with SN allocation through the common service, so that the corresponding RLC PDU 1 and RLC PDU 2 can be reordered based on SN at the receiving end, and the corresponding service can be processed synchronously and efficiently.

[0141] The data processing method of the embodiment of the application applied to the receiving end is exemplarily described below taking the LTE communication scenario as an example.

[0142] In a possible LTE communication scenario, the receiving end includes RLC receiving entity 1 and RLC receiving entity 2, wherein the RLC receiving entity 1 corresponds to RB 1 uniquely, the RLC receiving entity 2 corresponds to RB 2 uniquely, and RB 1 and RB 2 both belong to RB GROUP 1, so the RLC receiving entity 1 and the RLC receiving entity 2 can be considered as belonging to RB GROUP 1. The common service of RB GROUP 1 includes SN reordering. In this scenario, the data processing method of the embodiment of the application can include the following steps:

[0143] Step S601, the RLC receiving entity 1 receives RLC PDU 1 from the lower MAC layer.

[0144] Step S602, the header information of RLC PDU 1 is parsed to obtain the RLC SN (i.e. sequence variable value) of RLC PDU 1.

[0145] Step S603, the RX_NEXT value (i.e. expected receiving variable value) and the RX_DELIV (i.e. lower edge variable value) of the receiving window maintained by RB GROUP 1 are obtained.

[0146] Wherein, RX_NEXT represents the SN value of the next RLC PDU expected to be received, and RX_DELIV represents the SN value associated with the first SDU not yet submitted to the upper layer in the receiving window maintained by RB GROUP 1.

[0147] Step S604, if RLC SN < RX_DELIV, discard RLC PDU 1.

[0148] Step S605, if RLC SN = RX_DELIV, it means that RLC PDU 1 does not introduce out-of-order, and RLC PDU 1 does not need to be sorted, and after RLC PDU 1 is processed into RLC SDU 1, it is submitted to the upper SDAP layer.

[0149] Step S606, if RCVD_COUNT > RX_DELIV, put RLC PDU1 in the receiving window maintained by RB GROUP1, and wait for delivery to upper layer PDCP layer in the receiving window.

[0150] For example, the RLC SN of RLC PDU1 is 11, and RX_DELIV = 8, which indicates that there is a hole in the current receiving window, and RLC PDU1 needs to wait for delivery in the receiving window.

[0151] Step S607, if RLC SN >= RX_NEXT, update RX_NEXT = RLC SN + 1.

[0152] For example, the current RLC SN = 11, and RX_NEXT = 10, then update RX_NEXT = 12.

[0153] Step S608, if RX_DELIV < RX_NEXT, and t-Reordering timer is not running, update RX_REORD = RX_NEXT, and start t-Reordering timer to wait, wherein the waiting time of t-Reordering timer can be set according to the characteristics of the services in the RB GROUP.

[0154] For example, RX_DELIV = 8, and RX_NEXT = 12, if t-Reordering timer is not running, update RCVD_COUNT = 12, and start t-Reordering timer to wait.

[0155] Step S609, if t-Reordering timer is not expired, and RX_DELIV >= RX_RECORD, control t-Reordering timer to stop running.

[0156] When RX_DELIV points to the SN value 11 corresponding to RLC PDU1, RLC PDU1 is submitted to the upper layer. When RX_DELIV points to the RCVD_COUNT value 12, it indicates that RLC PDU1 has been delivered, so t-Reordering timer can be controlled to stop running.

[0157] Step S610, if t-Reordering timer is expired, and the hole message in the receiving window is still not received, forced delivery is performed, the header of the data RLC SN < RX_RECORD and the continuous RLC PDU starting from RX_RECORD in the receiving window is decompressed, and then delivered to the upper layer in ascending order of SN value, and RX_DELIV is updated to the SN value of the first RLC SDU that has not been transmitted to the upper layer.

[0158] In the above scenario, the RLC receiving entity 1 and the RLC receiving entity 2 having the service correlation are associated through the RB GROUP 1, and then the RLC PDU 1 received by the RLC receiving entity 1 and the RLC PDU 2 received by the RLC receiving entity 2 are reordered through the shared service, so that the corresponding RLC SDU 1 and RLC SDU 2 are delivered to the upper layer in ascending order, thereby realizing the synchronous and efficient processing of the correlated services.

[0159] According to the correlation characteristics of the services between the multiple bearers, the embodiments of the present application establish the RB group to associate the bearers having the service correlation, and establish the correlation between the entities, so as to achieve the synchronous and efficient processing of the correlated services. The method provided by the embodiments of the present application is very suitable for the ViNR video call, new radio call, XR extended reality and other services.

[0160] In the embodiments of the present application, the multiple sending / receiving entities of the associated services of the bearers are attributed to the same RB group, so as to associate the multiple sending / receiving entities of the associated services of the bearers. For the sending end, when any target sending entity in the RB group receives the SDU, the sequence variable value of the SDU is configured by using the expected sending variable value maintained by the RB group, and then the expected sending variable value is updated according to the preset step value. In this way, when any target sending entity in the RB group receives the SDU, the new SDU is configured by using the updated expected sending variable value, and the process is repeated. As a result, the sequence variable values corresponding to the multiple SDUs in the same group have the order, and the PDUs generated based on the SDUs also have the order. For the receiving end, when any target receiving entity in the RB group receives the PDU from the lower layer, in the case that the sequence variable value of the PDU is greater than the lower edge variable value of the receiving window of the RB group, the PDU is placed in the receiving window of the RB group to wait for being delivered to the upper layer in the receiving window. In this way, the PDU can be delivered to the upper layer in ascending order by using the lower edge variable of the receiving window, and the PDUs having the correlation in the group are reordered according to the sequence variable value at the receiving end, thereby improving the synchronization of the transmission of the correlated services.

[0161] The embodiments of the present application also provide an electronic device, as shown in FIG. 8, the electronic device 1400 includes:

[0162] one or more processors 1410;

[0163] a memory 1420, on which one or more programs are stored, when the one or more programs are executed by the one or more processors 1410, the one or more processors 1410 implement the data processing method provided by any one of the embodiments of the present application.

[0164] The memory 1420, as a non-transitory network system, can be used to store non-transitory software programs and non-transitory computer executable programs. In addition, the memory 1420 can include a high-speed random access memory, and can also include a non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state memory device. In some embodiments, the memory 1420 can include a memory 1420 remotely arranged relative to the processor 1410, which can be connected to the processor 1410 through a network. Examples of the above-mentioned network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0165] The memory 1420 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 1420 can store an operating system and other application programs. When the technical solutions provided by the embodiments of the present application are implemented by software or firmware, the related program codes are stored in the memory 1420 and are called and executed by the processor 1410 to implement the data processing method of the embodiments of the present application.

[0166] The processor 1410 can be implemented in the form of a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, etc., for executing related programs to implement the technical solutions provided by the embodiments of the present application.

[0167] In some embodiments, the electronic device further comprises:

[0168] An input / output interface for realizing information input and output;

[0169] A communication interface for realizing communication interaction between the device and other devices, which can realize communication through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.);

[0170] A bus for transmitting information between various components (such as the processor 1410, the memory 1420, the input / output interface, and the communication interface) of the device;

[0171] The processor 1410, the memory 1420, the input / output interface, and the communication interface can realize communication connection between each other inside the device through the bus.

[0172] An embodiment of the present application further provides a computer readable storage medium, which stores computer executable instructions for executing the data processing method provided by any one of the embodiments of the present application.

[0173] An embodiment of the present application further provides a computer program product, which comprises a computer program or computer instructions stored in a computer readable storage medium, and a processor of a computer device reads the computer program or computer instructions from the computer readable storage medium, and the processor executes the computer program or computer instructions, so that the computer device executes the data processing method provided by any one of the embodiments of the present application.

[0174] According to the scheme implemented by the present application, the multiple sending / receiving entities carrying the associated services can be attributed to the same RB group, thereby associating the multiple sending / receiving entities carrying the associated services. For the sending end, when any target sending entity in the RB group receives an SDU, the sequence variable value of the SDU is configured by using the expected sending variable value maintained by the RB group, and then the expected sending variable value is updated according to a preset step value, so that when any target sending entity in the RB group receives an SDU, the new SDU is configured by using the updated expected sending variable value, and so on, so that the sequence variable values corresponding to the multiple SDUs in the same group have the sequential nature, and further the PDU generated based on the SDU also has the sequential nature. For the receiving end, when any target receiving entity in the RB group receives a PDU from the lower layer, in the case that the sequence variable value of the PDU is greater than the lower edge variable value of the receiving window of the RB group, the PDU is placed in the receiving window of the RB group to wait for being submitted to the upper layer in the receiving window, so that the ascending order of the PDU submitted to the upper layer can be controlled by using the lower edge variable of the receiving window, and the PDUs in the group having the association are reordered according to the sequence variable value at the receiving end, thereby improving the synchronization of the associated service transmission.

[0175] The system architecture and application scenarios described in the embodiments of the present application are for more clearly illustrating the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. It can be known by those skilled in the art that, with the evolution of the system architecture and the appearance of new application scenarios, the technical solutions provided by the embodiments of the present application are also applicable to similar technical problems.

[0176] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by a computer program instructing relevant hardware, and the computer program can be stored in a non-volatile computer readable storage medium. When the computer program is executed, the processes of the above-mentioned embodiments of the methods can be included. Any reference to memory, storage, databases, or other media in this application is intended to include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0177] Those skilled in the art can understand that all or some steps of the above-mentioned methods and systems can be implemented as software, firmware, hardware and appropriate combinations thereof. Some or all physical components can be implemented as software executed by a processor, such as a central processing unit, a digital signal processor or a microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software can be distributed on a computer readable medium, which can include computer storage media (or non-transitory media) and communication media (or transitory media). As known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. In addition, those skilled in the art know that communication media generally includes computer readable instructions, data structures, program modules or other data in modulated data signals such as carrier waves or other transmission mechanisms, and can include any information delivery medium.

[0178] It should be understood that, in the description of the embodiments of the present application, if there is description to "first", "second" and the like, it is only for the purpose of distinguishing technical features, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features or the sequence of the indicated technical features. "At least one" means one or more, and "multiple" means two or more. The "and / or" describes the association relationship of the associated objects, which means that there can be three kinds of relationships, for example, A and / or B can mean that A exists alone, A and B exist together, and B exists alone. Wherein A, B can be singular or plural. The character " / " generally represents that the associated objects before and after are in an "or" relationship. "At least one of the following" and the like means any group of these items, including any group of single items or multiple items. For example, at least one of a, b and c can mean: a, b, c, a and b, a and c, b and c, or a and b and c, wherein a, b, c can be single or multiple.

[0179] In addition, the technical features involved in each embodiment described in the present application can be combined with each other as long as there is no conflict.

[0180] The above describes some embodiments of the present application with reference to the drawings, but does not limit the scope of the present application. Any modification, equivalent replacement and improvement made by those skilled in the art without departing from the scope and essence of the present application shall be within the scope of the present application.

Claims

1. A data processing method, comprising: obtaining a plurality of target transmitting entities belonging to a same resource bearer (RB) group and a desired transmission variable value of the RB group; configuring a sequence variable value of a service data unit (SDU) received by any of the target transmitting entities from an upper layer according to the desired transmission variable value; updating the desired transmission variable value by a preset step value.

2. The method of claim 1, wherein, After configuring the sequence variable value of the SDU according to the desired transmission variable value, the method further comprises performing one or more of the following processes on the SDU: a header compression process; a data encryption process; an integrity protection process.

3. The method of claim 1, wherein, Before obtaining the plurality of target transmitting entities belonging to the same RB group, the method further comprises: obtaining configuration information synchronized with a network device and a terminal device; determining an RB group to which an RB belongs according to the configuration information; obtaining a transmitting entity corresponding to the RB; regarding the transmitting entity corresponding to the RB as a target transmitting entity belonging to the RB group. 4.A data processing method, comprising: obtaining a plurality of target receiving entities belonging to a same resource bearer (RB) group; obtaining a sequence variable value of a protocol data unit (PDU) received by any of the target receiving entities from a lower layer; in a case where the sequence variable value is greater than a lower edge variable value of a receiving window of the RB group, placing the PDU in the receiving window of the RB group to wait for submission to an upper layer.

5. The method of claim 4, wherein, After obtaining the sequence variable value of the PDU, the method further comprises: in a case where the sequence variable value is equal to the lower edge variable value of the receiving window of the RB group, submitting the PDU to the upper layer.

6. The method of claim 4 or 5, wherein, The method further comprises: before submitting the PDU to the upper layer, decompressing the PDU.

7. The method of claim 4, wherein, After placing the PDU in the receiving window of the RB group to wait for submission to the upper layer, the method further comprises: in a case where the sequence variable value is greater than a desired receiving variable value of the RB group, updating the desired receiving variable value of the RB group to a sum of the sequence variable value of the PDU and a preset step value.

8. The method of claim 7, wherein, After updating the desired receiving variable value of the RB group to the sum of the sequence variable value of the PDU and the preset step value, the method further comprises: in a case where a reordering timer of the RB group is not running, updating a reordering variable value of the RB group to the desired receiving variable value and starting the reordering timer.

9. The method of claim 8, wherein, After starting the reordering timer, the method further comprises: in a case where the lower edge variable value is greater than or equal to the reordering variable value, stopping running the reordering timer.

10. The method of claim 8, wherein, After starting the reordering timer, the method further comprises: in a case where the reordering timer times out, submitting, to the upper layer, PDUs in the receiving window whose sequence variable values are less than the reordering variable value and consecutive PDUs starting from the reordering variable value; updating the lower edge variable value to a sequence variable value of a first PDU that has not been submitted to the upper layer.

11. The method of claim 4, wherein, After obtaining the sequence variable value of the PDU, before placing the PDU in the receiving window of the RB group to wait for submission to the upper layer, the method further comprises performing one or more of the following processes on the PDU: decrypting the PDU according to the sequence variable value; performing integrity verification on the PDU according to the sequence variable value.

12. The method of claim 4, wherein, Before obtaining the multiple target receiving entities belonging to the same resource bearer (RB) group, the method further comprises: obtaining configuration information synchronized with the network device and the terminal device; determining the RB group to which the RB belongs according to the configuration information; obtaining the receiving entity corresponding to the RB; taking the receiving entity corresponding to the RB as the target receiving entity belonging to the RB group. 13.An electronic device, comprising: one or more processors; a memory having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the data processing method according to any one of claims 1-3, or the data processing method according to any one of claims 4-12. 14.A computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the data processing method according to any one of claims 1-3, or the data processing method according to any one of claims 4-12. 15.A computer program product comprising a computer program, wherein the computer program, when executed by a processor, implements the data processing method according to any one of claims 1-3, or the data processing method according to any one of claims 4-12.

Citation Information

Patent Citations

  • Method and apparatus for transmitting up resource scheduling request

    CN101355788A

  • Data receiving method and device, network side equipment and terminal equipment

    CN118118134A

  • Method for handling state variables of a PDCP entity in wireless communication system and a device therefor

    US20190044880A1