Method and apparatus for differentiated quality of service (QOS) processing of packets within same traffic flow

Abstract

According to an embodiment, a first PDCP entity receives a PDCP DU from an associated upper layer. The first PDCP entity processes the PDCP SDU using a COUNT value to generate a first PDCP data PDU (Protocol Data Unit). The first PDCP entity determines that transmission of the first PDCP data PDU needs to be abandoned. And the first PDCP entity discards the first PDCP data PDU (Protocol Data Unit). The first PDCP entity notifies a second PDCP entity of a second device of COUNT information related to one or more discarded COUNT values. The one or more discard COUNT values are associated with one or more discard PDCP data PDUs. The one or more discarded PDCP data PDUs comprise the first PDCP data PDU. The second PDCP entity is a peer-to-peer PDCP entity of the first PDCP entity and is used for processing data received from first equipment.

Description

[0001] This patent application claims the benefit of U.S. Provisional Patent Application No. 63 / 396,489, filed on August 9, 2022, entitled “Methods and Apparatus for Differential Quality of Service (QoS) Handling of Packets within A Same Service Stream” and U.S. Provisional Patent Application No. 63 / 501,290, filed on May 10, 2023, entitled “Methods and Apparatus for Differential Quality of Service (QoS) Handling of Packets within A Same Service Stream”, which are incorporated herein by reference. Technical Field

[0002] The present invention generally relates to methods and apparatus for network communications, and in a specific embodiment, to methods and apparatus for performing differentiated QoS processing on packets. Background Art

[0003] As a sublayer of the Layer 2 protocol in the 5G new radio (NR), the packet data convergence protocol (PDCP) provides various functions, such as data transmission between the user plane and the control plane, maintenance of the PDCP sequence number (SN), header compression and decompression, encryption and decryption, integrity protection and integrity verification, packet routing (for separate bearers and dual active protocol stack (DAPS) bearers), packet replication (for PDCP replication), duplicate detection and discard, packet reordering and sequential delivery, timer-based service data unit (SDU) discard, etc. Summary of the invention

[0004] The embodiments of the present invention describe methods and apparatus for performing differentiated QoS processing on packets, which generally achieve technical advantages.

[0005] According to an embodiment, a first PDCP entity receives a PDCP service data unit (SDU) from an associated upper layer of the first PDCP entity. The first PDCP entity associates a COUNT value with the PDCP SDU. The first PDCP entity processes the PDCP SDU using the COUNT value to generate a first PDCP data protocol data unit (PDU). The first PDCP entity determines that the transmission of the first PDCP data PDU needs to be abandoned. The first PDCP entity discards the first PDCP data PDU based on the determination that the transmission of the first PDCP data PDU needs to be abandoned. The first PDCP entity notifies a second PDCP entity of a second device of COUNT information related to one or more discarded COUNT values. The one or more discarded COUNT values ​​are associated with one or more discarded PDCP data PDUs. The one or more discarded PDCP data PDUs include the first PDCP data PDU. The second PDCP entity is a peer PDCP entity of the first PDCP entity, and is used to process data received from the first device.

[0006] In some embodiments, the COUNT information may indicate a first discarded COUNT (FDC) value. The FDC value may be a minimum COUNT value among the one or more discarded COUNT values.

[0007] In some embodiments, the COUNT information may further include a bitmap indicating additional discarded COUNT values. The one or more discarded COUNT values ​​may include the FDC value and the additional discarded COUNT value. Each bit in the bitmap may correspond to a unique COUNT value in a continuous COUNT value sequence. The continuous COUNT value sequence may numerically follow the FDC value and include the additional discarded COUNT value. Each bit in the bitmap may carry a first value indicating that the corresponding COUNT value is associated with a discarded PDCP data PDU, or a second value indicating that the corresponding COUNT value is not associated with any discarded PDCP data PDU in the discarded PDCP data PDU.

[0008] In some embodiments, the COUNT information may also indicate a total number of additional discarded COUNT values. The one or more discarded COUNT values ​​may include the FDC value and the number of consecutive COUNT values ​​numerically following the FDC value. The number may be equal to the total number.

[0009] In some embodiments, the COUNT information may indicate a last discarded COUNT (LDC) value. The LDC value may be a maximum COUNT value among the one or more discarded COUNT values.

[0010] In some embodiments, the first PDCP entity may notify the second PDCP entity of the COUNT information by indicating that any COUNT value that is less than the LDC value and has not been received when notified will be considered as a discarded COUNT value among the one or more discarded COUNT values.

[0011] In some embodiments, the COUNT information may indicate a first resumed COUNT (FRC) value. The FRC value may be associated with a second PDCP data PDU. The second PDCP data PDU may be the earliest PDCP PDU to be sent to the second PDCP entity when transmission to the second PDCP entity is resumed. The FRC value may be a minimum COUNT value used after transmission to the second PDCP entity is resumed and is greater than any discarded COUNT value among the one or more discarded COUNT values.

[0012] In some embodiments, the first PDCP entity may notify the second PDCP entity of the COUNT information by indicating that any COUNT value that is less than the FRC value and has not been received when notified will be considered as a discarded COUNT value among the one or more discarded COUNT values.

[0013] In some embodiments, the COUNT information may indicate a hyper frame number (HFN) value of a first resumed COUNT (FRC) value. The FRC value may be associated with a second PDCP data PDU. The second PDCP data PDU may be the earliest PDCP data PDU to be sent to the second PDCP entity when transmission to the second PDCP entity is resumed. The FRC value may be the minimum COUNT value used after transmission to the second PDCP entity is resumed and is greater than any discarded COUNT value among the one or more discarded COUNT values. The HFN value may be a value represented by a pre-specified number of most significant bits of the FRC value.

[0014] In some embodiments, the first PDCP entity may notify the second PDCP entity of the COUNT information by sending the COUNT information in a PDCP control PDU to the second PDCP entity in response to discarding the first PDCP data PDU.

[0015] In some embodiments, the first PDCP entity may determine that transmission to the second PDCP entity needs to be resumed after discarding the first PDCP data PDU and before notifying the second PDCP entity.

[0016] In some embodiments, the first PDCP entity may notify the second PDCP entity of the COUNT information by sending the COUNT information in a PDCP control PDU to the second PDCP entity in response to the determination that transmission to the second PDCP entity needs to be resumed.

[0017] In some embodiments, the COUNT information may further indicate that the one or more discarded COUNT values ​​will not be reused to process other PDCP SDUs, the other PDCP SDUs being used for a second transmission to the second PDCP entity.

[0018] In some embodiments, before sending the COUNT information to the second PDCP entity, the first PDCP entity may determine that the one or more discarded COUNT values ​​may not be reused for processing other PDCP SDUs.

[0019] In some embodiments, the first device may be a user equipment (UE), and the second device may be a base station. In some embodiments, the first device may be a base station, and the second device may be a UE. In some embodiments, the first device and the second device may be peer UEs.

[0020] In some embodiments, the first PDCP entity may process the PDCP SDU by integrity protecting and ciphering the PDCP SDU using the COUNT value.

[0021] According to an embodiment, a first PDCP entity receives COUNT information associated with one or more discard COUNT values ​​from a second PDCP entity of a second device. The one or more discard COUNT values ​​are respectively associated with one or more PDCP data protocol data units (PDUs) that the second PDCP entity has discarded. The second PDCP entity is a peer PDCP entity of the first PDCP entity, and is used to process data to be transmitted to the first device. The first PDCP entity receives a PDCP data PDU from the second PDCP entity. The first PDCP entity processes the PDCP data PDU to generate a PDCP service data unit (SDU) based on the COUNT information. The first PDCP entity transmits the PDCP SDU to an associated upper layer without waiting for the one or more PDCP data PDUs associated with the one or more discard COUNT values.

[0022] In some embodiments, the first PDCP entity may process the PDCP data PDU based on the COUNT information by determining a COUNT value associated with the PDCP data PDU using the COUNT information.

[0023] In some embodiments, the COUNT information may indicate a first discarded COUNT (FDC) value. The FDC value may be a minimum COUNT value among the one or more discarded COUNT values.

[0024] In some embodiments, the COUNT information may further include a bitmap indicating additional discarded COUNT values. The one or more discarded COUNT values ​​may include the FDC value and the additional discarded COUNT value. Each bit in the bitmap may correspond to a unique COUNT value in a continuous COUNT value sequence. The continuous COUNT value sequence may numerically follow the FDC value and include the additional discarded COUNT value. Each bit in the bitmap may carry a first value indicating that the corresponding COUNT value is associated with the corresponding discarded PDCP PDU, or a second value indicating that the corresponding COUNT value is not associated with any discarded PDCP PDU in the discarded PDCP PDU.

[0025] In some embodiments, the first PDCP entity may determine a maximum COUNT value among the one or more discarded COUNT values ​​as a COUNT value corresponding to a last bit in the bitmap set to the first value.

[0026] In some embodiments, the COUNT information may also indicate a total number of additional discarded COUNT values. The one or more discarded COUNT values ​​may include the FDC value and the number of consecutive COUNT values ​​numerically following the FDC value. The number may be equal to the indicated total number.

[0027] In some embodiments, the first PDCP entity may determine a maximum COUNT value among the one or more discarded COUNT values ​​to be equal to a sum of the FDC value and the total number indicated by the COUNT information.

[0028] In some embodiments, the COUNT information indicates a last discarded COUNT (LDC) value, where the LDC value is a maximum COUNT value among the one or more discarded COUNT values.

[0029] In some embodiments, the first PDCP entity may update the state variable RX_NEXT of the first PDCP entity to be equal to the sum of 1 and the maximum COUNT value of the one or more discarded COUNT values ​​in response to determining that the sum is greater than the RX_NEXT value before the update.

[0030] In some embodiments, the first PDCP entity may update a state variable RX_DELIV of the first PDCP entity to be equal to a sum of 1 and the maximum COUNT value of the one or more discard COUNT values.

[0031] In some embodiments, the first PDCP entity may update the state variable RX_DELIV of the first PDCP entity to be equal to a minimum COUNT value that satisfies all of the following conditions: greater than the RX_DELIV value before the update; greater than or equal to the sum of 1 and the maximum COUNT value among the one or more discarded COUNT values; the PDCP SDU associated with the minimum COUNT value has not yet been transmitted to the upper layer associated with the first PDCP entity, and the upper layer is still waiting for the PDCP SDU.

[0032] In some embodiments, the first PDCP entity may determine a COUNT value that is less than the LDC value and has not yet been received as a discarded COUNT value among the one or more discarded COUNT values.

[0033] In some embodiments, the COUNT information may indicate a first resumed COUNT (FRC) value. The FRC value may be associated with a second PDCP data PDU. The second PDCP data PDU may be the earliest PDCP data PDU to be sent by the second PDCP entity when notified, and the FRC value is a minimum COUNT value to be used by the second PDCP entity when sending a next PDCP data PDU when notifying the first PDCP entity.

[0034] In some embodiments, the first PDCP entity may update a state variable RX_NEXT of the first PDCP entity to be equal to the FRC value indicated by the COUNT information in response to determining that the FRC value is greater than the RX_NEXT value before the update.

[0035] In some embodiments, the first PDCP entity may update a state variable RX_DELIV of the first PDCP entity to be equal to the FRC value indicated by the COUNT information.

[0036] In some embodiments, the first PDCP entity may update the state variable RX_DELIV of the first PDCP entity to be equal to a minimum COUNT value that satisfies all of the following conditions: greater than the RX_DELIV value before the update; greater than or equal to the notified FRC value; the PDCP SDU associated with the minimum COUNT value has not yet been transmitted to the upper layer associated with the first PDCP entity, and the upper layer is still waiting for the PDCP SDU.

[0037] In some embodiments, the first PDCP entity may determine a COUNT value that is less than the FRC value and has not yet been received as a discarded COUNT value among the one or more discarded COUNT values.

[0038] In some embodiments, the COUNT information may indicate a hyper frame number (HFN) value of a first resumed COUNT (FRC) value. The FRC value may be associated with a second PDCP data PDU. The second PDCP data PDU may be the earliest PDCP data PDU to be sent by the second PDCP entity when notified. The FRC value is a minimum COUNT value to be used by the second PDCP entity when sending a next PDCP data PDU when notifying the first PDCP entity.

[0039] In some embodiments, the first PDCP entity may receive the COUNT information by receiving the COUNT information in a PDCP control PDU.

[0040] In some embodiments, the first PDCP entity may determine that there is no need to wait for the one or more PDCP PDUs associated with the one or more discard COUNT values.

[0041] In some embodiments, the first PDCP entity may regard the one or more PDCP PDUs associated with the one or more discard COUNT values ​​as having been received and delivered to upper layers associated with the first PDCP entity.

[0042] In some embodiments, the first device may be a user equipment (UE), and the second device may be a base station. In some embodiments, the first device may be a base station, and the second device may be a UE. In some embodiments, the first device and the second device may be peer UEs. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] For a more complete understanding of the present invention and its advantages, reference is made to the following description in conjunction with the accompanying drawings, in which:

[0044] Figure 1A An exemplary communication system according to some embodiments is shown;

[0045] Figure 1B An example of a transmitting PDCP entity on a data transmitter side and a receiving PDCP entity on a data receiver side for unidirectional data transmission according to some embodiments is shown;

[0046] Figure 2 An exemplary PDCP data protocol data unit (PDU) format with a 12-bit PDCP SN according to some embodiments is shown;

[0047] Figure 3 illustrates an exemplary network architecture according to some embodiments;

[0048] Figure 4A illustrates an exemplary PDCP Transmission State Control PDU according to some embodiments;

[0049] Figure 4B illustrates an exemplary PDCP Transmission State Control PDU according to some embodiments;

[0050] Figure 4C illustrates an exemplary PDCP Transmission State Control PDU according to some embodiments;

[0051] Figure 5A illustrates an exemplary PDCP Control PDU according to some embodiments;

[0052] Figure 5B illustrates an exemplary PDCP Control PDU according to some embodiments;

[0053] Figure 6 A flow chart illustrating an exemplary process occurring in a PDCP entity of a transmitting device according to some embodiments;

[0054] Figure 7 A flow chart illustrating an exemplary process occurring in a PDCP entity of a receiving device according to some embodiments;

[0055] Figure 8 A flow chart illustrating an exemplary process occurring in a PDCP entity of a transmitting device according to some embodiments;

[0056] Fig. 9 A flow chart illustrating an exemplary process occurring in a PDCP entity of a receiving device according to some embodiments;

[0057] Fig. 10A A flow chart illustrating a method performed by a first PDCP entity of a first device according to some embodiments;

[0058] Fig. 10B A flow chart illustrating a method performed by a first PDCP entity of a first device according to some embodiments;

[0059] Fig.11 An exemplary communication system according to some embodiments is shown;

[0060] Fig. 12A and Fig. 12B An exemplary implementation device is shown in which the methods and instructions according to the present invention can be implemented;

[0061] Fig.13 A block diagram of a computing system that may be used to implement the devices and methods disclosed herein is shown, according to some embodiments.

[0062] Unless otherwise indicated, corresponding numerals and symbols in the different figures generally refer to corresponding parts. The figures are drawn to clearly illustrate the relevant aspects of the embodiments and are not necessarily drawn to scale. DETAILED DESCRIPTION

[0063] The making and use of embodiments of the present invention will be discussed in detail below. However, it should be understood that the concepts disclosed herein can be embodied in a variety of specific contexts, and the specific embodiments discussed herein are merely illustrative and are not intended to limit the scope of the claims. In addition, it should be understood that various changes, substitutions and modifications may be made herein without departing from the spirit and scope of the present invention as defined by the appended claims.

[0064] An embodiment of the present invention provides a packet processing mechanism that can perform differentiated QoS processing on packets of different types of application data units within the same service flow. The mechanism provides a method for classifying packets of different types of application data units within the same service flow (e.g., a video stream of an extended reality (XR) service) based on pre-configured classification rules and parameters and information related to a PDU set transmitted by each packet of the video stream. The mechanism also provides a method for discarding packets based on information related to the PDU set when congestion conditions are met, or when a transmission deadline associated with a packet has passed and the packet is not successfully transmitted, or when other application data units on which the packet depends are not successfully sent.

[0065] An embodiment of the present invention also provides a signaling mechanism for a sending PDCP entity to notify a receiving PDCP entity of one or more COUNT values, wherein the one or more COUNT values ​​are associated with a discarded PDCP PDU and will not be reused to send other PDCP SDUs from the sending PDCP entity to the receiving PDCP entity, so there is no need to wait.

[0066] The technology of this embodiment can avoid wasting precious wireless resources on unnecessary transmission that cannot improve user experience.

[0067] This notification (e.g., transmitted via a PDCP transmission status control PDU) enables the receiving PDCP entity to avoid deferring the transmission of subsequently received PDCP SDUs to the upper layer due to performing unnecessary reordering procedures that would otherwise be triggered (and continue until timeout) due to the fact that a discarded PDCP PDU was not received and not notified. Unless specifically described as a PDCP control PDU (i.e., a PDCP PDU with a control type, as indicated by a value of 0 in the data / control (D / C) field in the PDCP header), the PDCP PDUs described herein that carry upper layer data and may be discarded refer to PDCP data PDUs, which are PDCP PDUs with a data type, as indicated by a value of 1 in the D / C field in the PDCP header. The PDCP data PDU is generated by a PDCP entity of a communication device (referred to as a transmitting PDCP entity) for transmitting a PDCP SDU (i.e., upper layer data) to a peer PDCP entity of another communication device (referred to as a receiving PDCP entity). On the other hand, the PDCP control PDU (for example, the PDCP transmission status control PDU described in this document) is generated by the first PDCP entity and is used to transmit a PDCP control message to a peer PDCP entity of the first PDCP entity. The control message is initiated at the first PDCP entity to manage operations between the two PDCP entities, for example, reporting status or sending feedback information.

[0068] Figure 1A An exemplary communication system 100 according to an embodiment is shown. The communication system 100 includes an access node 110 that serves user equipment (UE), such as UE 120, having a coverage area 101. In a first operating mode, communications to and from the UE pass through the access node 110 having the coverage area 101. The access node 110 is connected to a backhaul network 115 for connection to the Internet and for operations and management, etc. In a second operating mode, communications to and from the UE do not pass through the access node 110, however, the access node 110 typically allocates resources to the UE for communication when specific conditions are met. Communications between a pair of UEs 120 may use a sidelink connection (shown as two separate unidirectional connections 125). In Figure 1AIn the embodiment, sidelink communication occurs between two UEs operating in the coverage area 101. However, sidelink communication may also generally occur in the following situations: both UEs 120 are outside the coverage area 101; both UEs are inside the coverage area 101; or one UE is inside the coverage area 101 and the other UE is outside the coverage area 101. Communication between the UE and the access node pair is carried out through a unidirectional communication link, where the communication link between the UE and the access node is called an uplink 130, and the communication link between the access node and the UE is called a downlink 135.

[0069] Access nodes may also be generally referred to as NodeB, evolved NodeB (eNB), next generation (NG) NodeB (gNB), master eNB (MeNB), secondary eNB (SeNB), master gNB (MgNB), secondary gNB (SgNB), network controller, control node, base station, access point, transmission point (TP), transmission-reception point (TRP), cell, carrier, macro cell, femto cell, pico cell, etc., and UE may also be generally referred to as mobile station, mobile station, terminal, user, subscriber, site, etc. The access node may provide wireless access according to one or more wireless communication protocols, for example, third generation partnership project (3GPP) long term evolution (LTE), LTE advanced (LTE-A), 5G, 5G LTE, 5G NR, sixth generation communication technology (6G), high speed packet access (HSPA), IEEE 802.11 series standards, such as 802.11a / b / g / n / ac / ad / ax / ay / be, etc. Although it can be understood that the communication system can adopt multiple access nodes capable of communicating with multiple UEs, for simplicity, only one access node and two UEs are shown.

[0070] Figure 1BAn example of a transmitting PDCP entity 152 on the data sender side and a receiving PDCP entity 154 on the data receiver side for unidirectional data transmission is shown. In some embodiments, the data sender and the data receiver may be a UE and a next generation radio access network (NG-RAN) node (e.g., a gNB in ​​5G NR), respectively, or vice versa, or two peer UEs, respectively. For a bidirectional data radio bearer (DRB) where data can be transmitted in both directions, there is also an additional pair of transmitting PDCP entity and receiving PDCP entity ( Figure 1B not shown).

[0071] like Figure 1B As shown, when an upper layer data packet (also called a PDCP SDU) for transmission is received from an associated upper layer of the sending PDCP entity 152, the sending PDCP entity 152 associates a unique integer called a COUNT value with the PDCP SDU. The COUNT value of each subsequent PDCP SDU is incremented by 1, and the COUNT value is used to integrity protect and encrypt the associated PDCP SDU. If header compression is configured on the DRB through radio resource control (RRC) signaling, the sending PDCP entity 152 compresses certain upper layer protocol headers according to the configured header compression profile before performing integrity protection and encryption on the header compressed PDCP SDU. Then, the sending PDCP entity 152 generates a PDCP PDU, which includes a PDCP header, a data payload, and a message authentication code for integrity (MAC-I). The data payload encapsulates the PDCP SDU that has been header compressed, integrity protected and encrypted. The PDCP header includes a PDCP SN, which is the number of least significant bits (LSB) of the pre-configured COUNT value associated with the PDCP SDU. According to the current 3GPP PDCP specification (TS 38.323v17.4.0), the length of the PDCP SN can be 12 bits or 18 bits ( Figure 2 An exemplary PDCP data PDU format with a 12-bit PDCP SN is shown.) The transmitting PDCP entity then submits the PDCP PDU to the associated lower layers of the transmitting PDCP entity for transmission.

[0072] On the data receiving side, upon receiving a PDCP PDU from the associated lower layers of the receiving PDCP entity 154, the receiving PDCP entity 154 retrieves the PDCP SN (from the PDCP header), data (payload), and MAC-I from the received PDCP PDU. The receiving PDCP entity reconstructs the COUNT value using the retrieved PDCP SN and a reconstructed hyper frame number (HFN) value, which is reconstructed by the receiving PDCP entity 154 to track the untransmitted remainder of the COUNT value used by the transmitting PDCP entity on the received PDCP PDU (i.e., the untransmitted most significant bit (MSB) excluding the PDCP SN bit). For example, the reconstructed HFN value is determined based on the value of the HFN portion of a state variable of the receiving PDCP entity called RX_DELIV and a comparison between the value of the retrieved PDCP SN and the value of the PDCP SN portion of RX_DELIV. The RX_DELIV is used to track the COUNT value of the first PDCP SDU that has not yet been transmitted to the associated upper layer of the receiving PDCP entity but is still waiting. The receiving PDCP entity 154 uses the reconstructed COUNT value to decrypt the retrieved data payload and verify the integrity of the decrypted data payload. The receiving PDCP entity also uses the reconstructed COUNT value in the received integrity-verified data payload to perform duplicate detection and discard, and if necessary, reordering for sequential delivery. If header compression is configured, the receiving PDCP entity decompresses (i.e., reconstructs) the upper layer header according to the configured header compression profile so that the PDCP SDU is fully reconstructed before transmitting it to the associated upper layer of the receiving PDCP entity. In addition to RX_DELIV, the receiving entity also maintains other state variables, such as RX_NEXT and RX_REORD. RX_NEXT is used to track the COUNT value of the next PDCP SDU expected to be received. RX_REORD is used to track the COUNT value following the COUNT value associated with the PDCP PDU that triggered the start of the tReordering timer. If the tReordering timer is not subsequently stopped and reset due to successful reception of the missing PDCP PDU, then upon expiration of the tReordering timer, any PDCP PDU with a COUNT value less than the value of RX_REORD that has not yet been received will be considered as finally lost in transmission and no longer need to be waited for. In this case (i.e., the timer times out), RX_DELIV will be updated to the COUNT value of the new first PDCP SDU that has not yet been delivered to the associated upper layers of the receiving PDCP entity but is still waiting.The COUNT value is greater than RX_REORD (indicating that the receiving PDCP entity searches for the new first PDCP SDU that has not been transmitted only from RX_REORD). Then, if the updated value of RX_DELIV is less than the value of RX_NEXT, it is determined that the transmission of the PDCP PDU having the COUNT value equal to the updated value of RX_DELIV has started but has not been successful, and thus at least one new lost PDCP PDU is identified. Then, in response to identifying the new lost PDCP PDU, the receiving PDCP entity updates RX_REORD to a value equal to RX_NEXT and starts the t reordering timer again.

[0073] Extended reality (XR) services are expected to become an important driving force in the development of next-generation wireless communication technologies. The data traffic in XR services typically includes a video data stream corresponding to video images (also called frames) periodically generated by a video codec (e.g., in an XR server, or in an AR client for uplink (UL) video). The video images are typically sliced, compressed, and encoded into multiple coding units. For example, in H.264, these coding units are called network adaptation layer (NAL) units, and the first byte of the NAL unit is a NAL unit header containing an indication of the data type in the NAL unit. A group of NAL units can belong to the same application data unit, which corresponds to an image or a layer representation of an image (such as a base layer, a spatial enhancement layer, a temporal enhancement layer, a quality enhancement layer). When transmitted over a transport network, each NAL unit is typically encapsulated in one or more concatenated real-time protocol (RTP) / user datagram protocol (UDP) / internet protocol (IP) packets for end-to-end delivery to a video decoder (e.g., in an XR client, or in an AR server for UL video). Such delivery may involve transmission over a wireless link between a gNB and a UE. The gNB is typically connected to the XR server via a wired connection, and the UE is co-located and / or connected to the XR client. Upon receiving these RTP / UDP / IP packets from the associated upper layers, the service data adaptation protocol (SDAP) entity of the gNB (for DL ​​transmission) or UE (for UL transmission) further encapsulates each of these RTP / UDP / IP packets in an SDAP PDU, which arrives at the gNB's transmitting PDCP entity or the UE's transmitting PDCP entity as a PDCP SDU. The transmitting PDCP entity of the gNB or UE then processes the PDCP SDU to generate a PDCP PDU and submits the PDCP PDU to the associated lower layers of the transmitting PDCP entity for transmission, as described above.

[0074] Since the video decoder processes the received video application data unit as a whole, the RTP / UDP / IP / SDAP / PDCP packets (PDUs) associated with the same video application data unit should be processed in an integrated manner at each corresponding protocol layer during end-to-end transmission. The RTP / UDP / IP / SDAP / PDCP packets (PDUs) associated with the same video application data unit are also collectively referred to as PDU sets. Therefore, the application data unit and its corresponding PDU set can be considered to be the same (or at least carry the same media content), except that the application data unit is more used in the application layer, while the PDU set was recently introduced in 3GPP TS23.700-60 for processing these packets (or PDUs) by the corresponding protocol layers when transmitted through the transport network or RAN. For example, at the RTP layer, the PDU set refers to all RTP packets associated with the same video application data unit. At the UDP layer, the PDU set refers to all UDP packets associated with the same video application data unit. At the IP layer, the PDU set refers to all IP packets associated with the same video application data unit. In the SDAP sublayer, a PDU set refers to all SDAP data PDUs associated with the same video application data unit. In the PDCP sublayer, a PDU set refers to all PDCP data PDUs associated with the same video application data unit. In the radio link control (RLC) sublayer, a PDU set refers to all RLC data PDUs associated with the same video application data unit.

[0075] In order to ensure that users of XR services can enjoy immersive and virtual reality experiences, XR services usually have very high requirements for video resolution. For example, 4K video is required to achieve retinal resolution using a head mounted display (HMD), which is only a few centimeters away from the human eye, while 1080p video is required to achieve the same resolution on a smartphone screen. Higher resolution translates into higher peak data rates and higher average throughput, and therefore, a higher chance of network congestion, especially in the radio access network (RAN). When network congestion occurs, new technologies are needed to handle such a large amount of data transmission in order to alleviate network congestion and reduce the impact on user experience.

[0076] Due to the real-time and interactive nature of XR services and the physiological characteristics of humans, the end-to-end delay, called motion-to-photon delay, needs to be very short (e.g., no more than 20 milliseconds (msec)); otherwise, users may experience network sickness, such as dizziness, disorientation, and nausea. Therefore, XR services usually have very strict latency requirements for video traffic. In order to improve the utilization efficiency of transmission resources in the network, especially in RAN, new methods may be needed to efficiently handle data transmission when latency requirements are not met.

[0077] Traditional enhanced mobile broadband (eMBB) services typically require high peak data rates and high throughput, but do not have strict requirements on latency. Traditional ultrareliable low latency communications (URLLC) services typically require low latency and high reliability, but compared to XR use cases, traditional URLLC use cases (e.g., sensors or industrial control) often require relatively low peak data rates and throughput. Therefore, existing wireless technologies developed for eMBB and URLLC services are not sufficient to handle XR services. New approaches are needed to simultaneously meet the requirements of high peak data rates, high throughput, high reliability, and low latency.

[0078] The technical solution of the present invention first provides a framework for implementing differentiated QoS processing for packets of different types of application data units (i.e., PDU sets) in the same video stream. The framework provides a method for classifying packets of different types of application data units in the same video stream according to pre-configured classification rules and information related to the PDU set transmitted by each packet of the video stream. The framework also provides a method for discarding packets according to information related to the PDU set when congestion conditions are met, or when the transmission deadline associated with the packet has passed and the packet is not successfully transmitted, or when other application data units on which the packet depends are not successfully sent.

[0079] The technical solution of the present invention also provides a signaling method for notifying a receiving PDCP entity of one or more COUNT values ​​associated with a discarded PDCP PDU and which will not be reused after the PDCP PDU is discarded, or notifying a receiver of the first resumed transmission when the transmission of the PDCP PDU is resumed. For example, a PDCP PDU may be discarded due to congestion, missed transmission deadlines, reliance on a previous PDU set and unsuccessful transmission of the previous PDU set, etc. The notification enables the receiving PDCP entity to avoid postponing the transmission of subsequently received PDCP SDUs to the associated upper layer due to the execution of an unnecessary reordering process, which would otherwise be triggered and continued due to the fact that the discarded PDCP PDU was not received and notified.

[0080] XR services typically use advanced codecs (e.g., H.264 or H.265) for video streams, where different application data units may be of different types, may be associated with different importance levels, and / or may have different dependency states on other application data units within the same video stream.

[0081] Taking H.264 advanced video coding (AVC) as an example, application data units are periodically generated as intra-coded (I) pictures, which are pictures that are coded independently of all other pictures. Usually an I picture is followed by multiple application data units called predictive coded (P) pictures or bi-predictive coded (B) pictures until the same pattern is repeated on the next I picture, and so on. P pictures and B pictures are compressed and encoded by directly using the I picture as a reference picture, or by reconstructing another reference picture for inter-picture prediction using another previous P picture. The other previous P picture can be compressed and encoded by directly using the I picture as a reference picture, or by reconstructing another reference picture for inter-picture prediction using another previous P picture, and so on. B pictures are not used as reference pictures for any inter-picture prediction. Therefore, the successful decompression of P pictures and B pictures (to reconstruct their associated complete pictures) depends on the successful reception and decompression of their corresponding reference pictures. If an I picture is lost (i.e., not received by the video decoder), then all subsequently received P pictures and B pictures (before the next I picture) will be useless even if they are successfully received. In this case, an I picture is more important than a P picture and a B picture, and therefore requires a higher priority and higher reliability when transmitted. A P picture that is dependent on another P picture or B picture is more important than an independent P picture, and is also more important than a B picture. A B picture is the least important picture because no other pictures depend on it, and therefore can be processed with a lower priority and lower reliability when transmitted. Therefore, when a gNB or UE encounters congestion, it can first discard packets (or PDUs) corresponding to the lowest priority application data units, such as independent P pictures and B pictures, to alleviate the congestion. If the congestion persists, packets (or PDUs) corresponding to the second lowest priority application data units, such as dependent P pictures, can also be discarded, and so on. The type of application data unit associated with the data carried in the NAL unit is indicated by the nal_unit_type field in the NAL unit header, which includes the first octet of the NAL unit. The NAL unit (or fragments of the NAL unit when the NAL unit is too large) is encapsulated as payload in concatenated RTP / UDP / IP packets. In addition to distinguishing the processing of packets of different application data units based on the type of application data unit, H.264 also allows the video encoder to provide an indication of the reference or dependency level through the num_ref_idc field in the NAL unit header. The binary value '00' in the 2-bit num_ref_idc field indicates that the contents of the NAL unit are not used to reconstruct reference pictures for inter-picture prediction. Such NAL units can be discarded without destroying the integrity of the reference pictures.Values ​​greater than '00' indicate that the NAL unit needs to be decoded to maintain at least partial integrity of the reference picture. The highest priority is '11', followed by '10', then '01', and finally, '00' is the lowest. This (multi-level) codepoint for importance / dependency indication provides the ability to indicate multiple levels of dependencies (and thus multiple levels of importance) when hierarchical inter-picture dependencies are used.

[0082] Taking the H.264 scalable video coding (SVC) extension as an example, the video codec divides the video stream into a substream of a base layer application data unit and multiple substreams of an enhancement layer application data unit. Each base layer application data unit is self-decodable and provides an image with a lower spatial resolution, which is used as a reference image for the enhancement layer application data unit that depends on it. For example, a spatial enhancement layer application data unit can be generated to provide a higher spatial resolution, a temporal enhancement layer application data unit can be generated to provide a higher temporal resolution, and a quality enhancement layer application data unit can be generated to provide a reconstructed image with a higher quality (or fidelity). Therefore, the base layer application data unit is generally more important than the enhancement layer application data unit, and therefore requires a higher priority and higher reliability when transmitted than the enhancement layer application data unit. In addition, according to IETF RFC 6190 (titled "RTP Payload Format for Scalable Video Coding"), the H.264 SVC encoder indicates the priority level of the NAL unit with finer granularity through the 6-bit priority_id (PRID) field in the NAL unit type specific extension header. The NAL unit type specific extension header is specific to the SVC type of the NAL unit and includes the second to fourth octets of the NAL unit. The smaller the value of the PRID field, the higher the priority. The H.264 SVC encoder also indicates the inter-layer coding dependency level of the layer application data unit associated with the SVC type of the NAL unit by using the 3-bit dependency_id (DID) field in the NAL unit type specific extension header. A layer application data unit with a given dependency_id can be used for inter-layer prediction for encoding other layer application data units with a higher dependency_id, while the layer application data unit with the given dependency_id should not be used for inter-layer prediction for encoding layer application data units with a lower dependency_id. Therefore, PRID and DID information can be used to distinguish the processing of packets of different types of layer application data units during end-to-end transmission.

[0083] like Figure 3As shown, after using traditional packet filtering (packet filtering can be based on a five-tuple (i.e., source / destination IP address, source / destination port number, and protocol ID) to identify incoming RTP / UDP / IP packets belonging to the same video stream of the XR service running on UE 306), the user plane function (UPF) 302 (for DL ​​video transmission) or UE 306 (for UL video transmission) further classifies the identified RTP / UDP / IP packets by inspecting various fields in the RTP header, NAL unit header, and / or NAL unit type-specific extension header as described above, and the classification is based on rules and parameters provided by a session management function (SMF) 304, which provides services for the data PDU session established for the video stream of the XR service. After classification, UPF 302 maps DL packets corresponding to PDU sets with different priority level requirements and / or different reliability requirements (or UE 306 maps UL packets corresponding to PDU sets with different priority level requirements and / or different reliability requirements) to different QoS flows or different QoS sub-flows of the same QoS flow. Each QoS flow is uniquely identified by a QoS flow ID (QFI), and each QoS sub-flow is uniquely identified by a QoS sub-flow ID in addition to being identified by the QFI of a common QoS flow.

[0084] For DL ​​video transmission, the UPF 302 forwards each classified RTP / UDP / IP packet (which is further encapsulated in a general packet radio service (GPRS) tunneling protocol (GTP) user plane (GTP-U) packet for transmission between the UPF 302 and the gNB in ​​the next generation RAN (NG-RAN) through the GTP tunnel) and the associated QFI, QoS subflow ID and additional PDU set related information (carried in the GTP-U extension header of the GTP-U packet) to the NG-RAN node 308 (i.e., the gNB) serving the UE. Examples of the additional PDU set related information include the PDU set size (e.g., the total number of packets) of the PDU set to which the packet belongs, a start marker and / or an end marker indicating whether the packet is the first packet or the last packet in the PDU set to which the packet belongs, respectively, the PDU set SN of the PDU set to which the packet belongs, the PDU SN indicating the position of the packet in the PDU set to which the packet belongs, inter-PDU set dependency information, etc. For example, the inter-PDU set dependency information may be an indication of whether the PDU set to which the packet belongs depends on a second PDU set. For another example, the inter-PDU set dependency information may be a PDU set SN of the second PDU set, and the PDU set to which the packet belongs depends on the second PDU set. The GTP-U interface unit of the gNB retrieves the RTP / UDP / IP packet, and the QFI, QoS substream ID, and additional PDU set related information associated with each packet in the RTP / UDP / IP packet from the received GTP-U packet and transmits them to the SDAP entity of the gNB, the purpose of establishing the SDAP entity is to provide services for the data PDU session configured for the video stream of the XR service. The SDAP entity may encapsulate each RTP / UDP / IP packet in the RTP / UDP / IP packet in an SDAP PDU, respectively, and submit each generated SDAP PDU to a sending PDCP entity among multiple sending PDCP entities of the gNB according to the QFI and QoS substream ID associated with each SDAP PDU in the generated SDAP PDU. Each of the multiple sending PDCP entities is used to provide services for a unique DRB, and the unique DRB is used to meet different levels of QoS requirements. The SDAP entity can also provide the sending PDCP entity with additional PDU set related information, and the additional PDU set related information is associated with the SDAP PDU submitted to the sending PDCP entity.For UL video transmission, QFI, QoS sub-flow ID, and similar additional PDU set related information may also be transmitted along with the RTP / UDP / IP packets within the UE 306 across different layers until reaching the sending PDCP entity of the UE 306 through the UE implementation.

[0085] The transmitting PDCP entity in the gNB (for DL) or UE (for UL) may then use the PDU set related information to process the packet accordingly. For example, the PDU set SN, PDU set size information, PDU SN, start marker and / or end marker associated with the packet may assist the transmitting PDCP entity in determining whether the transmitting PDCP entity has successfully sent all packets in the PDU set to which the packet belongs before the transmission deadline. In the event that the transmitting PDCP entity is unable to successfully send the packet of the PDU set before the transmission deadline, the transmitting PDCP entity may discard the remaining packets of the same PDU set instead of attempting to send them, which remaining packets may be identified by the PDU set SN and the PDU SN associated with the remaining packets. The transmitting PDCP entity may also determine whether packets of a second PDU set are dependent on the discarded PDU set. For example, packets of the second PDU set are subsequently received by the transmitting PDCP entity for transmission, and the inter-PDU set dependency information associated with each packet of the packets of the second PDU set indicates the PDU set SN of the discarded PDU set (meaning that these packets are dependent on the discarded PDU set). In response to determining that the second PDU set is dependent on the discarded PDU set, the transmitting PDCP entity may also discard all packets of the second PDU set. This is because without receiving all packets of the discarded PDU set, sending all packets of the second PDU set may be wasteful because the video decoder cannot successfully decompress the image to generate a complete image. Discarding packets to avoid unnecessary transmissions helps avoid wasting precious radio resources on transmissions that do not improve the user experience.

[0086] To reduce packet processing delays, PDCP PDUs are typically pre-processed, which means that time-consuming calculations associated with header compression, integrity protection, and ciphering of the PDCP SDUs are typically completed before the associated lower layers indicate that a transmission opportunity exists. As previously mentioned, the COUNT value associated with the PDCP SDU is used when calculating the integrity protection and ciphering of the PDCP SDU. Since the transmitting PDCP entity of the gNB (for DL) or UE (for UL) may discard the pre-processed PDCP PDUs of the discarded PDU set from time to time (e.g., due to missed delivery deadlines due to transmission errors or congestion conditions, or because the reference application data units that the pre-processed PDCP PDUs depend on have been discarded), the transmitting PDCP entity may not have time to reallocate the COUNT value associated with the discarded PDCP PDU to the subsequent PDCP SDUs. More importantly, if these subsequent PDCP SDUs have been received and pre-processed by the sending PDCP entity (from the upper layer for transmission), the sending PDCP entity may not have the time and computing resources to repeat the calculations for integrity protection and ciphering on the subsequent PDCP SDUs; otherwise, repeating the calculations may cause the transmission deadlines of these subsequent PDCP SDUs to also be missed.

[0087] On the other hand, not reusing the discarded COUNT value on the subsequent PDCP SDUs may result in the following situation: the receiving PDCP entity believes that the associated PDCP PDU is still in transmission, unaware that the transmitting PDCP entity has abandoned the transmission of the associated PDCP PDU, and thus triggers the reordering procedure, i.e., waiting for the reception of the lost PDCP PDU. During the waiting period, if in-sequence delivery is configured, the receiving PDCP entity may postpone the delivery of the subsequently received PDCP SDUs to the associated upper layer until the reordering procedure times out, thereby artificially increasing the delay for the delivery of these subsequently received packets. In addition, the loss of a large number of consecutive COUNT values ​​may also cause the receiving PDCP entity to generate an erroneous HFN value for reconstructing the COUNT value of the subsequently received PDCP PDU. The erroneous HFN value and the erroneous COUNT value may cause the decryption and integrity verification of the subsequently received PDCP PDU to fail, even if the subsequently received PDCP PDU is authentic and received without any errors.

[0088] According to various embodiments, the transmitting PDCP entity notifies the receiving PDCP entity of a COUNT value associated with a PDCP PDU that has been discarded and is not reused when transmitting a subsequent PDCP PDU. For example, whenever the transmitting PDCP entity discards a PDCP PDU and does not reuse the COUNT value associated with the discarded PDCP PDU on a subsequent PDCP SDU, the transmitting PDCP entity sends a PDCP control PDU referred to as a PDCP transmission state control PDU. For example, the PDCP transmission state control PDU may also be referred to as a PDCP discard state control PDU, or simply referred to as a transmission state control PDU or a discard state control PDU, etc.

[0089] According to an exemplary embodiment, Figure 4A As shown, the PDCP transmission state control PDU 400 includes a D / C field 402, which carries a value of 0 (zero) indicating that the PDCP PDU is a control PDU, a PDU type field 404 carries a value corresponding to the PDCP transmission state control PDU type, and a first discarded COUNT (FDC) field 406 carries an FDC value, which is the first (i.e., the smallest) COUNT value among the COUNT values ​​associated with the discarded PDCP PDU and not reused. When there is more than one discarded PDCP PDU (the associated COUNT value is not reused), the PDCP transmission state control PDU also includes a bitmap field 408, which carries a discard status (e.g., "discarded" or "not discarded") indicating consecutive COUNT values ​​after the FDC value. For example, the first bit in the bitmap corresponds to the first COUNT value after the FDC value, the second bit in the bitmap corresponds to the second COUNT value after the FDC value, and so on. For example, a value of 0 (zero) carried by a bit in the bitmap indicates that the corresponding COUNT value has not been discarded (i.e., "not discarded"), while a value of 1 carried by the bit indicates that the corresponding COUNT value has been discarded and the COUNT value is not reused (i.e., "discarded") on a subsequent PDCP SDU, thereby notifying the receiving PDCP entity that there is no need to wait for the COUNT value. The opposite indication logic is also possible. Padding bits may be added at the end of the bitmap to keep the size of the bitmap to an integer number of octets. All padding bits may be set to a value indicating that the corresponding COUNT value has not been discarded.

[0090] When receiving the PDCP transmission status control PDU 400, such as Figure 4AAs shown, the receiving PDCP entity can determine the COUNT value indicated by the FDC field 406 and any other COUNT value. The corresponding bit in the bitmap field 408 of the other COUNT value is set to a value indicating a "discarded" state, that is, it is discarded by the sending PDCP entity, or is received and transmitted to the upper layer. Therefore, no matter which method is used, there is no need to wait. The receiving PDCP entity can also determine the maximum COUNT value among the notified discarded COUNT values. For example, the receiving PDCP entity determines that the maximum COUNT value among the notified discarded COUNT values ​​is the value corresponding to the last bit of the value set to indicate the "discarded" state in the bitmap field 408. Based on this determination, the receiving PDCP entity can also update its state variables, such as RX_NEXT, RX_DELIV, and RX_REORD, accordingly. For example, if the maximum COUNT value among the notified discarded COUNT values ​​is greater than or equal to the value of RX_NEXT, the receiving PDCP entity updates RX_NEXT to be equal to the sum of 1 and the maximum COUNT value among the notified discarded COUNT values. The receiving PDCP entity may then also update its RX_DELIV. For example, the receiving PDCP entity updates its RX_DELIV to be equal to the sum of 1 and the maximum COUNT value among the notified discarded COUNT values ​​(or simply equal to the updated value of RX_NEXT). For another example, the receiving PDCP entity updates its RX_DELIV to be equal to the first (i.e., smallest) COUNT value that satisfies all of the following: (1) a value greater than RX_DELIV (the value before RX_DELIV is updated); (2) greater than the maximum COUNT value among the notified discarded COUNT values; (3) the PDCP SDU associated with the first COUNT value has not yet been transmitted to the upper layer, and the upper layer is still waiting for the PDCP SDU. Then, if the current value of RX_DELIV is less than the current value of RX_NEXT, the possible update of the corresponding state variable will take these two values ​​into account, and as described above, the receiving PDCP entity may also update its RX_REORD to be equal to the current value of RX_NEXT.

[0091] When the transmitting PDCP entity decides to abandon a PDU set, if the transmission of the PDU set has not yet started, all PDCP PDUs belonging to the PDU set may be discarded, or if some PDCP PDUs belonging to the PDU set have been transmitted, all remaining PDCP PDUs belonging to the PDU set may be discarded. Therefore, the discard COUNT value may be a large number of consecutive COUNT values. Therefore, according to an optional exemplary embodiment, such as Figure 4BAs shown, the PDCP transmission state control PDU 420 includes a D / C field 422, a PDU type field 424, and an FDC field 426, as described above. When there is more than one discarded PDCP PDU (without reusing the associated COUNT value), the PDCP transmission state control PDU also includes an additional discarded COUNT number field 428, which carries a value indicating the total number of consecutive additional discarded COUNT values ​​after the FDC value. Figure 4B As shown, a single octet of the Additional Drop COUNT Number field 428 is sufficient to indicate up to 256 consecutive additional drop COUNT values ​​following the FDC value, while Figure 4A The bitmap field 408 in requires 1 to 16 octets to indicate up to 256 consecutive additional discard COUNT values ​​following the FDC value.

[0092] When receiving the PDCP transmission status control PDU 420, such as Figure 4BAs shown, the receiving PDCP entity can determine the COUNT value indicated by the FDC field 426 and the number of consecutive COUNT values ​​after the FDC. The number is indicated in the additional discarded COUNT number field 428, that is, it is discarded by the sending PDCP entity, or it is received and transmitted to the upper layer. Therefore, no matter which method is used, there is no need to wait. The receiving PDCP entity can also determine the maximum COUNT value among the notified discarded COUNT values. For example, the receiving PDCP entity determines that the maximum COUNT value among the notified discarded COUNT values ​​is equal to the sum of the value in the FDC field 426 and the value in the additional discarded COUNT number field 428. Based on this determination, the receiving PDCP entity can also update its state variables accordingly, such as RX_NEXT, RX_DELIV and RX_REORD. For example, if the maximum COUNT value among the notified discarded COUNT values ​​is greater than or equal to the value of RX_NEXT, the receiving PDCP entity updates RX_NEXT to be equal to the sum of 1 and the maximum COUNT value among the notified discarded COUNT values. The receiving PDCP entity may then also update its RX_DELIV. For example, the receiving PDCP entity updates its RX_DELIV to be equal to the sum of 1 and the maximum COUNT value among the notified discarded COUNT values ​​(or simply equal to the updated value of RX_NEXT). For another example, the receiving PDCP entity updates its RX_DELIV to be equal to the first (i.e., smallest) COUNT value that satisfies all of the following: (1) a value greater than RX_DELIV (the value before RX_DELIV is updated); (2) greater than the maximum COUNT value among the notified discarded COUNT values; (3) the PDCP SDU associated with the first COUNT value has not yet been transmitted to the upper layer, and the upper layer is still waiting for the PDCP SDU. Then, if the current value of RX_DELIV is less than the current value of RX_NEXT, the possible update of the corresponding state variable will take these two values ​​into account, and as described above, the receiving PDCP entity may also update its RX_REORD to be equal to the current value of RX_NEXT.

[0093] According to another optional exemplary embodiment, Figure 4C As shown, the PDCP transmission state control PDU 440 includes a D / C field 442 and a PDU type field 444 as described above, and a last discarded COUNT (LDC) field 446 carrying an LDC value, which is the last (i.e., maximum) COUNT value among the COUNT values ​​associated with the discarded PDCP PDUs and not reused.

[0094] When receiving the PDCP transmission status control PDU 440, such as Figure 4CAs shown, the receiving PDCP entity can determine that the COUNT value indicated by the LDC field 446 and any COUNT value before (less than) the COUNT value and not successfully received is discarded by the sending PDCP entity, or is received and transmitted to the upper layer. Therefore, no matter which method is used, there is no need to wait. Based on this determination, the receiving PDCP entity can also update its state variables, such as RX_NEXT, RX_DELIV, and RX_REORD, accordingly. For example, if the value in the LDC field 446 is greater than or equal to the value of RX_NEXT, the receiving PDCP entity updates RX_NEXT to be equal to the sum of 1 and the notified LDC value. Then, the receiving PDCP entity can also update its RX_DELIV. For example, the receiving PDCP entity updates its RX_DELIV to be equal to the sum of 1 and the notified LDC value (or simply equal to the updated value of RX_NEXT). For another example, the receiving PDCP entity updates its RX_DELIV to be equal to the first (i.e., smallest) COUNT value that satisfies all of the following conditions: (1) greater than the value of RX_DELIV (the value before RX_DELIV is updated); (2) greater than the notified LDC value; (3) the PDCP SDU associated with the first COUNT value has not yet been delivered to the upper layer, and the upper layer is still waiting for the PDCP SDU. Then, if the current value of RX_DELIV is less than the current value of RX_NEXT, the possible update of the corresponding state variable will take these two values ​​into account. As described above, the receiving PDCP entity may also update its RX_REORD to be equal to the current value of RX_NEXT.

[0095] In some cases, for example, when congestion occurs in the RAN, the transmitting PDCP entity needs to suspend transmission to the receiving PDCP entity and thus continuously discards the periodically generated PDU sets (e.g., until the congestion is relieved). However, each time the transmitting PDCP entity discards the PDU set of a service cycle, since the transmitting PDCP entity may not be able to predict whether the network congestion will be relieved by then, the transmitting PDCP entity may not be able to predict whether the next PDU set of the next service cycle will be discarded. Therefore, the transmitting PDCP entity may need to send a PDCP transmission status control PDU to the receiving PDCP entity, such as FIG. 4A to FIG. 4C As shown and described above, each time the transmitting PDCP entity discards a set of PDUs for the receiving PDCP entity, a large amount of signaling overhead is generated. According to an exemplary embodiment of sending a PDCP transmission status control PDU to notify the discard of COUNT value and FDC value and bitmap, or discarding COUNT value and FDC value and the number of consecutive COUNT values ​​discarded, or discarding COUNT value and LDC value, as previously described in FIG. 4A to FIG. 4CAs described and shown in, it can be sent only once when transmission is resumed to the receiving PDCP entity, rather than each time a discard occurs. This helps reduce signaling overhead, especially when discards occur repeatedly due to network congestion. However, the number of discarded PDCP PDUs caused by network congestion may be quite large. For example, for high-resolution video typically used in XR services, the rate may be as high as 1000 PDUs per second, thus requiring a large bitmap to be carried in the bitmap field 408, or requiring an additional discard COUNT number field to carry 2 to 3 octets, rather than requiring an additional discard COUNT number field 428 to carry 1 octet, as shown in Figure 4B Therefore, from the perspective of signaling overhead, in this case, it is advantageous to use the LDC value for notification.

[0096] According to various optional embodiments, each time a discard occurs, the sending PDCP entity can avoid notifying the receiving PDCP entity of the discarded COUNT value. In contrast, when transmission to the receiving PDCP entity is resumed (for example, after network congestion is relieved), the sending PDCP entity notifies the receiving PDCP entity of the COUNT value associated with the PDCP PDU and used on the PDCP PDU, and the COUNT value is the first value to be sent to the receiving PDCP entity, referred to herein and hereinafter as the first resumed COUNT (FRC). Other methods of naming FRCs may also be used. In a non-limiting example, the FRC may also be referred to as the first transmitted COUNT or the next COUNT, etc. By notifying the FRC, the sending PDCP entity only needs to send a notification once when the sending PDCP entity decides to resume transmission to the receiving PDCP entity, thereby reducing signaling overhead when the sending PDCP entity needs to continuously discard a periodically generated set of PDUs, for example due to network congestion.

[0097] According to an exemplary embodiment, Figure 5A As shown, the transmitting PDCP entity sends a PDCP control PDU called COUNT update control PDU 500 to the receiving PDCP entity. The COUNT update control PDU 500 includes a D / C field 502 as described above, a PDU type field 504 carrying a value corresponding to the COUNT update control PDU type, and an FRC field 506 carrying an FRC value.

[0098] When receiving a COUNT update control PDU, the receiving PDCP entity may update its state variables, such as RX_NEXT, RX_DELIV, and RX_REORD, accordingly. For example, if the value in the FRC field 506 is greater than the value of RX_NEXT, the receiving PDCP entity updates RX_NEXT to be equal to the FRC value. The receiving PDCP entity may then also update its RX_DELIV. For example, the receiving PDCP entity updates its RX_DELIV to be equal to the FRC value (or the updated value of RX_NEXT). For another example, the receiving PDCP entity updates its RX_DELIV to be equal to the first (i.e., minimum) COUNT value that satisfies all of the following: (1) a value greater than RX_DELIV (the value before RX_DELIV is updated); (2) greater than or equal to the notified FRC value; (3) the PDCP SDU associated with the first COUNT value has not yet been transmitted to the upper layer, and the upper layer is still waiting for the PDCP SDU. Then, if the current value of RX_DELIV is less than the current value of RX_NEXT, a possible update of the corresponding state variables takes both values ​​into account and the receiving PDCP entity may also update its RX_REORD to be equal to the current value of RX_NEXT as described above.

[0099] According to an optional exemplary embodiment, Figure 5B As shown, when transmission to the receiving PDCP entity resumes, the transmitting PDCP entity sends a PDCP control PDU called a HFN update control PDU 520 to the receiving PDCP entity, the HFN update control PDU 520 including a D / C field 522 as previously described, a PDU type field 524 carrying a value corresponding to the HFN update control PDU type, and a HFN field of FRC 526, the HFN field of FRC 526 carrying the HFN portion of the COUNT (FRC) value of the first PDCP PDU to be sent by the transmitting PDCP entity to the receiving PDCP entity. The HFN field of FRC 526 is in Figure 5B 520 is shown as a 20-bit field. This is for the case where the PDCP SN is configured as 12 bits long. When the PDCP SN is configured as 18 bits long, the HFN field of the FRC in the HFN update control PDU 520 can be 14 bits long to keep the total length of the complete COUNT value at 32 bits. In this case, the HFN update control PDU 520 also includes 6 reserved bits.

[0100] When receiving the HFN update control PDU 520, the receiving PDCP entity may store the value indicated in the HFN field 526 of the FRC. Then, when receiving a first PDCP PDU from the transmitting PDCP entity, the receiving PDCP entity may first attempt to reconstruct the COUNT value used on the first PDCP PDU by concatenating the stored HFN value (as the MSB of COUNT) with the PDCP SN explicitly carried in the received first PDCP PDU (as the LSB of COUNT), and then decrypt and integrity verify the first PDCP PDU using the reconstructed COUNT value. If both the decryption and integrity verification are successful, the COUNT value reconstructed in the first attempt is considered to be the correct COUNT value used on the first PDCP PDU. If decryption or integrity verification fails, the receiving PDCP entity may make a second attempt to reconstruct the COUNT value used on the first PDCP PDU by concatenating 1 and the stored HFN value (which is used as the MSB of COUNT) with the PDCP SN explicitly carried in the received first PDCP PDU (as the LSB of COUNT), and then decrypt and integrity verify the first PDCP PDU again using the COUNT value reconstructed in the second attempt. If both decryption and integrity verification (in the second attempt) are successful, the COUNT value reconstructed in the second attempt is considered to be the correct COUNT value used on the first PDCP PDU.

[0101] The reason why the first attempt fails and the second attempt succeeds is that the first PDCP PDU successfully received by the receiving PDCP entity may be different from the first PDCP PDU sent by the sending PDCP entity when transmission is resumed (and the first successfully received PDCP PDU is sent after the first sent PDCP PDU), because different hybrid automatic repeat request (HARQ) retransmission times and / or different RLC retransmission times are used when sending the first sent PDCP PDU and the first received PDCP PDU, respectively. In this case, the first COUNT value used on the first received PDCP PDU should be greater than the second COUNT value used on the first sent PDCP PDU (the second COUNT value is FRC), because the PDCP SDU carried by the first received PDCP PDU should arrive at the sending PDCP entity after the PDCP SDU carried by the first sent PDCP PDU (for one transmission). It is possible that when the COUNT value is increased from the second COUNT value to the first COUNT value, a wraparound may have occurred in the PDCP SN part, which results in the HFN part being incremented by 1, indicating that the HFN value of the first COUNT value (not explicitly sent in the PDCP data PDU) is equal to the sum of 1 and the HFN value of the second COUNT value, which is the notified and stored HFN value. It is also possible that, in an optional implementation, the receiving PDP entity uses the sum of 1 and the stored HFN value (which is used as the MSB of the reconstructed COUNT) in the first attempt, and uses the stored HFN value (as the MSB of the reconstructed COUNT) in the second attempt.

[0102] If a correctly reconstructed COUNT value is found in any attempt, the receiving PDCP entity may also update its state variables, such as RX_NEXT, accordingly. For example, if the correctly reconstructed COUNT value of the first received PDCP PDU is greater than or equal to the value of RX_NEXT, the receiving PDCP entity updates RX_NEXT to be equal to the sum of 1 and the correctly reconstructed COUNT value of the first received PDCP PDU. At this point, the receiving PDCP entity may not be able to determine whether the correctly reconstructed COUNT value on the first received PDCP PDU is an FRC, and therefore cannot determine whether there are any COUNT values ​​that have been transmitted but not yet received and should be waited for before the correctly reconstructed COUNT value. Therefore, in this case, the receiving PDCP entity may update its RX_DELIV and RX_REORD according to various exemplary embodiments, as described in the following paragraphs.

[0103] In a first exemplary embodiment, upon receiving a first PDCP PDU, the receiving PDCP entity does not immediately update its RX_DELIV or RX_REORD, but instead first starts a timer with a specific initial value. The initial timer value may be set to a maximum amount of time required to cover a maximum number of HARQ retransmissions based on a maximum number of RLC retransmissions for a maximum number of PDCP PDUs that may be sent in parallel from the transmitting PDCP entity to the receiving PDCP entity. When the timer expires, the receiving PDCP entity updates its RX_DELIV to be equal to a first (i.e., minimum) COUNT value that satisfies the following two conditions: (1) it is greater than the minimum COUNT value among the PDCP PDUs that have been successfully received and decrypted and integrity verified since transmission was resumed; and (2) the PDCP SDU associated with the first COUNT value has not yet been delivered to upper layers, and the upper layers are still waiting for the PDCP SDU. Then, if the current value of RX_DELIV is less than the current value of RX_NEXT, all possible updates of the corresponding state variables since the resumption of transmission take into account both values ​​and the receiving PDCP entity may also update its RX_REORD to be equal to the current value of RX_NEXT.

[0104] According to the second exemplary embodiment, after receiving a first PDCP PDU, the receiving PDCP entity first updates its RX_DELIV to be equal to the sum of 1 and the correctly reconstructed COUNT value of the received first PDCP PDU, and starts a timer with a specific initial value, as described above. Then, when a PDCP PDU is subsequently received, in addition to possibly updating its RX_NEXT as described above, the receiving PDCP entity also updates its RX_DELIV to be equal to the sum of 1 and the (i.e. correctly reconstructed) COUNT value used on the subsequently received PDCP PDU if all of the following conditions are met: (1) the timer is still running; (2) the COUNT value used on the subsequently received PDCP PDU is less than RX_DELIV (the value before RX_DELIV is updated); (3) the PDCP SDU associated with the COUNT value (equal to 1 and the COUNT value on the subsequently received PDCP PDU) has not yet been delivered to the upper layer, and the upper layer is still waiting for the PDCP SDU. Then, if the current value of RX_DELIV is less than the current value of RX_NEXT, all possible updates of the corresponding state variables since the resumption of transmission take into account both values ​​and the receiving PDCP entity may also update its RX_REORD to be equal to the current value of RX_NEXT.

[0105] According to the third exemplary embodiment, after receiving a first PDCP PDU, the receiving PDCP entity first updates its RX_DELIV to be equal to the sum of 1 and the correctly reconstructed COUNT value of the first received PDCP PDU. Then, when a PDCP PDU is subsequently received, in addition to possibly updating its RX_NEXT as described above, the receiving PDCP entity also updates its RX_DELIV to be equal to the sum of 1 and the COUNT value used on the subsequently received PDCP PDU (i.e., correctly reconstructed) if all of the following conditions are met: (1) the sum of a pre-specified number and the COUNT value used on the subsequently received PDCP PDU is greater than the COUNT value used on the first received PDCP PDU; (2) the COUNT value used on the subsequently received PDCP PDU is less than RX_DELIV (the value before RX_DELIV is updated); (3) the PDCP SDU associated with the COUNT value (equal to 1 and the COUNT value on the subsequently received PDCP PDU) has not yet been delivered to the upper layer, and the upper layer is still waiting for the PDCP SDU. For example, the pre-specified number is the smaller of: the maximum number of PDCP PDUs that can be sent simultaneously from the transmitting PDCP entity to the receiving PDCP entity using the maximum number of HARQ processes allowed, and the maximum number of PDCP PDUs that can be generated by the video codec based on the video frame. Then, if the current value of RX_DELIV is less than the current value of RX_NEXT, all possible updates of the corresponding state variables since the resumption of transmission take these two values ​​into account, and the receiving PDCP entity may also update its RX_REORD to be equal to the current value of RX_NEXT.

[0106] Figure 6 A flow chart of an exemplary process 600 occurring in a PDCP entity of a first device (e.g., a transmitting device) is shown. Flow 600 may indicate operations occurring in a PDCP entity of the first device when the first device transmits data to a second device. The first device may be a UE and the second device may be a gNB, or vice versa, or the first device and the second device may be peer UEs.

[0107] Process 600 begins with the PDCP entity receiving one or more PDCP SDUs from its associated upper layer for transmission at operation 610. Upon receiving each of the one or more PDCP SDUs, the PDCP entity may start a discard timer associated with each of the one or more PDCP SDUs, respectively. The discard timer tracks the remaining time before the deadline for transmitting the associated PDCP SDU and stops when the associated PDCP SDU is successfully transmitted, and thus only times out when the deadline passes without successfully transmitting the associated PDCP SDU. At operation 620, the PDCP entity associates a unique COUNT value with each of the one or more PDCP SDUs. For example, a state variable of the PDCP entity (referred to as TX_NEXT) is used to track the COUNT value to be associated with the next PDCP SDU received after the current PDCP SDU, and is incremented by 1 after its current value is associated with the current PDCP SDU. At operation 630, the PDCP entity processes each of the one or more PDCP SDUs using the corresponding associated COUNT value to generate one or more PDCP PDUs, respectively. For example, the processing includes performing integrity protection and ciphering on each of the one or more PDCP SDUs by using a corresponding associated COUNT value, and adding a PDCP header to the integrity protected and ciphered PDCP SDU to generate an associated PDCP PDU. The PDCP header includes a PDCP SN, which is a specified number of LSBs of the associated COUNT value.

[0108] Then, at operation 640, the PDCP entity determines that the transmission of one or more PDCP PDUs needs to be abandoned. For example, the PDCP entity may determine to abandon the transmission of one or more PDCP PDUs in response to determining that the deadline for transmitting one or more PDCP PDUs has passed. For another example, the PDCP entity may determine to abandon the transmission of one or more PDCP PDUs in response to determining that a congestion situation has occurred. For another example, the PDCP entity may determine to abandon the transmission of one or more PDCP PDUs in response to determining that one or more PDCP PDUs belong to the same PDU set and the discard timer associated with one of the one or more PDCP SDUs has timed out. For another example, the PDCP entity may determine to abandon the transmission of one or more PDCP PDUs in response to determining that one or more PDCP PDUs belong to the same PDU set, and the discard timer associated with one of the one or more PDCP SDUs has timed out. For another example, the PDCP entity may determine to abandon the transmission of one or more PDCP PDUs in response to determining that one or more PDCP PDUs belong to a first PDU set, the first PDU set depends on a second PDU set that precedes the first PDU set, and the second PDU set is not successfully sent. The first PDU set depends on the second PDU set means that if the receiver does not successfully receive the second PDU set, receiving the first PDU set is useless for the receiver. At operation 650, the PDCP entity discards one or more PDCP PDUs without transmitting. For example, the PDCP entity discards any one of the one or more PDCP PDUs that have not been submitted to its associated lower layer for transmission and is not submitted. For another example, if the RLC entity has not sent one or more PDCP PDUs, the PDCP entity instructs its associated RLC entity to discard any PDCP PDU in the one or more PDCP PDUs that have been submitted to the RLC entity for transmission and is not sent.

[0109] Then, at operation 660, the PDCP entity determines whether it can reuse the COUNT value associated with the one or more PDCP PDUs for subsequent PDCP SDUs. For example, if no PDCP SDUs have arrived at the PDCP entity for transmission since the one or more PDCP SDUs arrived at the PDCP entity, then when the one or more PDCP PDUs arrive, the COUNT value associated with the one or more PDCP PDUs may be reused for the subsequent PDCP SDUs (i.e., respectively associated with the subsequent PDCP SDUs). For another example, if the subsequent PDCP SDUs that arrive immediately after the one or more PDCP SDUs have not been respectively associated with unique COUNT values, then the COUNT value associated with the one or more PDCP PDUs may be reused for the subsequent PDCP SDUs. For another example, if the subsequent PDCP SDUs that arrive immediately after the one or more PDCP SDUs have been respectively associated with unique COUNT values ​​and have been pre-processed with the corresponding associated COUNT values, but the PDCP entity determines that there is sufficient time and computing resources to repeat the processing of the subsequent PDCP SDUs, then the COUNT value associated with the one or more PDCP PDUs may be reused for the subsequent PDCP SDUs. Repeating the processing of the subsequent PDCP SDU includes performing a second integrity protection and ciphering on the subsequent PDCP SDU using the reused COUNT value, respectively, to generate a PDCP PDU associated with the subsequent PDCP SDU.

[0110] At operation 670, in response to determining that the COUNT value associated with one or more PDCP PDUs can be reused for subsequent PDCP SDUs, the PDCP entity associates the reused COUNT value with the subsequent PDCP SDUs, and processes the subsequent PDCP SDUs using the associated COUNT value to generate PDCP PDUs associated with the subsequent PDCP SDUs, respectively. The PDCP entity then submits the generated PDCP PDUs to its associated lower layer for transmission, and process 600 ends.

[0111] On the other hand, in response to determining at operation 660 that the COUNT value associated with the one or more PDCP PDUs cannot be reused for a subsequent PDCP SDU that arrives immediately after the PDCP SDU associated with the one or more PDCP PDUs, at operation 680, the PDCP entity sends a notification of a discarded COUNT value that will not be reused to a second PDCP entity of a second device (e.g., a receiving device), the second PDCP entity being a peer PDCP entity for receiving data from the PDCP entity. For example, the PDCP entity sends a PDCP transmission state control PDU to the second PDCP entity. The PDCP transmission state control PDU includes an FDC field carrying an FDC value and a bitmap field carrying a bitmap indicating the discard status of consecutive COUNT values ​​after the FDC value; or, the PDCP transmission state control PDU includes an FDC field carrying an FDC value and an additional discard COUNT number field carrying the total number of consecutive additional discard COUNT values ​​after the FDC value; or, the PDCP transmission state control PDU includes an LDC field carrying an LDC value, wherein any COUNT value that is less than the LDC value and has not yet been received is regarded as a COUNT value in the discard COUNT value that will not be reused, as described above. The PDCP entity determines the FDC value as the minimum COUNT value in the discard COUNT value. The PDCP entity determines the LDC value as the maximum COUNT value in the discard COUNT value. The PDCP entity determines the size of the bitmap field or the value carried by the additional discard COUNT number field based on the difference between the FDC and the LDC. Then, process 600 ends.

[0112] Figure 7 A flow chart of an exemplary process 700 occurring in a PDCP entity of a first device (e.g., a receiving device) is shown. The process 700 may indicate operations occurring in a PDCP entity of the first device when the first device receives data from a second device. The first device may be a UE and the second device may be a gNB, or vice versa, or the first device and the second device may be peer UEs.

[0113] Method 700 begins with the PDCP entity receiving a notification from a second PDCP entity of a second device (e.g., a transmitting device) about one or more COUNT values ​​that have been discarded and will not be reused for sending other PDCP SDUs at operation 710, the second PDCP entity being a peer PDCP entity for sending data to the PDCP entity. For example, the PDCP entity receives a PDCP transmission state control PDU from the second PDCP entity. The PDCP transmission state control PDU includes an FDC field carrying an FDC value and a bitmap field carrying a bitmap indicating a discard status of consecutive COUNT values ​​after the FDC value; or, the PDCP transmission state control PDU includes an FDC field carrying an FDC value and an additional discarded COUNT number field carrying a total number of consecutive additional discarded COUNT values ​​after the FDC value; or, the PDCP transmission state control PDU includes an LDC field carrying an LDC value, wherein any COUNT value that is less than the LDC value and has not yet been received is regarded as a COUNT value that has been discarded and will not be reused among the one or more COUNT values, as before. At operation 720, the PDCP entity considers that there is no need to wait for one or more COUNT values. The PDCP entity may also consider that one or more COUNT values ​​have been received by the PDCP entity and transmitted to its associated upper layer.

[0114] At operation 730, the PDCP entity updates one or more parameters associated with its operation for data reception. In an exemplary embodiment, when the PDCP entity regards one or more COUNT values ​​as received, the PDCP entity may update its state variables, e.g., RX_NEXT, RX_DELIV, and / or RX_REORD, as previously described.

[0115] At operation 740, the PDCP entity receives a PDCP PDU associated with a reconstructed COUNT value that is greater than or equal to the current RX_NEXT value (taking into account the latest update of RX_NEXT). The reconstructed COUNT value is reconstructed based on the PDCP SN included in the PDCP header of the received PDCP PDU and the current RX_DELIV value (taking into account the latest update of RX_DELIV). At operation 750, the PDCP entity processes the received PDCP PDU to generate a PDCP SDU. The processing includes decrypting the payload of the received PDCP PDU using the reconstructed COUNT value and performing integrity verification on the decrypted payload. The processing may also include decompressing the upper layer header according to the configured header compression profile. At operation 760, the PDCP entity transmits the generated PDCP SDU to its associated upper layer without waiting for other PDCP PDUs associated with any of the one or more COUNT values ​​that were notified. Then, process 700 ends.

[0116] Figure 8 A flow chart of an optional exemplary process 800 occurring in a PDCP entity of a first device (e.g., a transmitting device) is shown. The process 800 may indicate operations occurring in a PDCP entity of the first device when the first device transmits data to a second device. The first device may be a UE and the second device may be a gNB, or vice versa, or the first device and the second device may be peer UEs.

[0117] Process 800 begins with the PDCP entity receiving one or more PDCP SDUs from its associated upper layer for transmission at operation 810. At operation 820, the PDCP entity associates a unique COUNT value with each PDCP SDU in the one or more PDCP SDUs. At operation 830, the PDCP entity processes each PDCP SDU in the one or more PDCP SDUs using the corresponding associated COUNT value to generate one or more PDCP PDUs, respectively. Then, at operation 840, the PDCP entity determines whether it is necessary to abandon the transmission of one or more PDCP PDUs. If it is necessary to abandon the transmission of one or more PDCP PDUs, then at operation 850, the PDCP entity discards the one or more PDCP PDUs without transmitting. If it is not necessary to abandon the transmission of one or more PDCP PDUs, then at operation 860, the PDCP entity determines whether it has abandoned the transmission of PDCP PDUs during the last business cycle. If the transmission of PDCP PDUs during the last business cycle is not abandoned, then at operation 880, the PDCP entity transmits one or more PDCP PDUs. Then, process 800 ends. If the transmission of the PDCP PDU during the previous service cycle is abandoned, the PDCP entity sends a notification to the second PDCP entity of the second device, the notification including information of the first PDCP PDU, the first PDCP PDU being the first PDCP PDU among one or more PDCP PDUs to be sent to the second PDCP entity, the PDCP entity being a peer PDCP entity of the second PDCP entity, for sending data to the second PDCP entity at operation 870. For example, the notification is sent in a PDCP control PDU. For example, the information of the first PDCP PDU includes a COUNT value used by the PDCP entity when generating the first PDCP PDU. For another example, the information of the first PDCP PDU includes the HFN portion of the COUNT value used by the PDCP entity when generating the first PDCP PDU. Then, at operation 880, the PDCP entity transmits one or more PDCP PDUs. Then, process 800 ends.

[0118] Fig. 9 A flow chart of an exemplary process 900 occurring in a PDCP entity of a first device (e.g., a receiving device) is shown. The process 900 may indicate operations occurring in a PDCP entity of the first device when the first device receives data from a second device. The first device may be a UE and the second device may be a gNB, or vice versa, or the first device and the second device may be peer UEs.

[0119] Process 900 begins with the PDCP entity receiving a notification from a second PDCP entity of a second device, the notification including information of a first PDCP PDU to be sent to the PDCP entity, the second PDCP entity being a peer PDCP entity for sending data to the PDCP entity at operation 910. For example, the notification is received in a PDCP control PDU. For example, the information of the first PDCP PDU includes a COUNT (i.e., FRC) value used by the second PDCP entity when sending the first PDCP PDU to the PDCP entity. For another example, the information of the first PDCP PDU includes the HFN portion of the COUNT value, which is the COUNT (i.e., FRC) value used by the second PDCP entity when sending the first PDCP PDU to the PDCP entity. At operation 920, the PDCP entity stores the information of the first PDCP PDU. For example, the information includes an FRC value, and the PDCP entity stores the information by updating its RX_NEXT and / or RX_DELIV to be equal to the FRC value, as described above. For another example, the information includes the HFN portion of the FRC value, and the PDCP entity stores the information in its memory, as described above. At operation 930, the PDCP entity receives a second PDCP PDU having a PDCP SN. At operation 940, the PDCP entity determines a COUNT value associated with the received second PDCP PDU based on the received PDCP SN and / or the stored information of the first PDCP PDU. For example, the PDCP entity may determine the COUNT value associated with the second PDCP PDU by concatenating the HFN portion of the stored FRC value or the HFN portion of the RX_DELIV value (the HFN portion is the MSB of the COUNT value) with the PDCP SN received in the second PDCP PDU (the PDCP SN is the LSB of the COUNT value). For another example, the PDCP entity may determine the COUNT value associated with the second PDCP PDU by concatenating 1 with the sum of the HFN portion of the stored FRC value or the HFN portion of the RX_DELIV value (the sum is the MSB of the COUNT value) and the PDCP SN received in the second PDCP PDU (the PDCP SN is the LSB of the COUNT value). At operation 950, the PDCP entity successfully processes the second PDCP PDU using the determined COUNT value to generate a PDCP SDU. For example, the successful processing includes decrypting the payload of the received PDCP PDU using the COUNT value and successfully verifying the integrity of the decrypted payload. The processing may also include decompressing the upper layer header according to a configured header compression profile. At operation 960, the PDCP entity transmits the generated PDCP SDU to its associated upper layer. Then, process 900 ends.

[0120] Fig. 10A A flow chart of a method 1000 performed by a first packet data convergence protocol (PDCP) entity of a first device according to some embodiments is shown. The first PDCP entity may include computer-readable code or instructions executed on one or more processors of the first device. In the present invention, the encoding of software for performing or executing method 1000 is within the scope of ordinary technicians in the field. Method 1000 may include more or fewer operations than shown and described, and may be performed or executed in a different order. The computer-readable code or instructions of the software executable by one or more processors may be stored on a non-transitory computer-readable medium such as a memory of the first device.

[0121] Method 1000 begins at operation 1002, where a first PDCP entity receives a PDCP service data unit (SDU) from an associated upper layer of the first PDCP entity. At operation 1004, the first PDCP entity associates a COUNT value with the PDCP SDU. At operation 1006, the first PDCP entity processes the PDCP SDU using the COUNT value to generate a first PDCP data protocol data unit (PDU). At operation 1008, the first PDCP entity determines that it is necessary to abandon the transmission of the first PDCP data PDU. At operation 1010, the first PDCP entity discards the first PDCP data PDU based on determining that it is necessary to abandon the transmission of the first PDCP data PDU. At operation 1012, the first PDCP entity notifies a second PDCP entity of a second device of COUNT information associated with one or more discarded COUNT values. The one or more discarded COUNT values ​​are associated with one or more discarded PDCP data PDUs. The one or more discarded PDCP data PDUs include the first PDCP data PDU. The second PDCP entity is a peer PDCP entity of the first PDCP entity, and is used to process data received from the first device.

[0122] In some embodiments, the COUNT information may indicate a first discarded COUNT (FDC) value. The FDC value may be a minimum COUNT value among one or more discarded COUNT values.

[0123] In some embodiments, the COUNT information may further include a bitmap indicating additional discarded COUNT values. The one or more discarded COUNT values ​​may include an FDC value and an additional discarded COUNT value. Each bit in the bitmap may correspond to a unique COUNT value in a continuous COUNT value sequence. The continuous COUNT value sequence may numerically follow the FDC value and include an additional discarded COUNT value. Each bit in the bitmap may carry a first value indicating that the corresponding COUNT value is associated with a discarded PDCP data PDU, or a second value indicating that the corresponding COUNT value is not associated with any discarded PDCP data PDU in the discarded PDCP data PDU.

[0124] In some embodiments, the COUNT information may also indicate the total number of additional discarded COUNT values. One or more discarded COUNT values ​​may include the FDC value and the number of consecutive COUNT values ​​that immediately follow the FDC value in value. The number may be equal to the total number.

[0125] In some embodiments, the COUNT information may indicate a last discarded COUNT (LDC) value. The LDC value may be a maximum COUNT value among one or more discarded COUNT values.

[0126] In some embodiments, the first PDCP entity may notify the second PDCP entity of the COUNT information by indicating that any COUNT value that is less than the LDC value and has not been received when notified will be considered as a discarded COUNT value in the one or more discarded COUNT values.

[0127] In some embodiments, the COUNT information may indicate a first resumed COUNT (FRC) value. The FRC value may be associated with the second PDCP data PDU. The second PDCP data PDU may be the earliest PDCP PDU to be sent to the second PDCP entity when transmission to the second PDCP entity is resumed. The FRC value may be the minimum COUNT value used after transmission to the second PDCP entity is resumed and is greater than any discarded COUNT value in one or more discarded COUNT values.

[0128] In some embodiments, the first PDCP entity may notify the second PDCP entity of the COUNT information by indicating that any COUNT value that is less than the FRC value and has not been received when notified will be considered as a discarded COUNT value in the one or more discarded COUNT values.

[0129] In some embodiments, the COUNT information may indicate a hyper frame number (HFN) value of a first resumed COUNT (FRC) value. The FRC value may be associated with the second PDCP data PDU. The second PDCP data PDU may be the earliest PDCP data PDU to be sent to the second PDCP entity when transmission to the second PDCP entity is resumed. The FRC value may be the minimum COUNT value used after transmission to the second PDCP entity is resumed and is greater than any discarded COUNT value in one or more discarded COUNT values. The HFN value may be a value represented by a pre-specified number of most significant bits of the FRC value.

[0130] In some embodiments, the first PDCP entity may notify the second PDCP entity of the COUNT information by sending the COUNT information in a PDCP control PDU to the second PDCP entity in response to discarding the first PDCP data PDU.

[0131] In some embodiments, the first PDCP entity may determine that transmission to the second PDCP entity needs to be resumed after discarding the first PDCP data PDU and before notifying the second PDCP entity.

[0132] In some embodiments, in response to determining that transmission to the second PDCP entity needs to be resumed, the first PDCP entity may notify the second PDCP entity of the COUNT information by sending the COUNT information in a PDCP control PDU to the second PDCP entity.

[0133] In some embodiments, the COUNT information may further indicate that one or more discarded COUNT values ​​are not reused to process other PDCP SDUs for a second transmission to a second PDCP entity.

[0134] In some embodiments, before sending the COUNT information to the second PDCP entity, the first PDCP entity may determine that one or more discarded COUNT values ​​may not be reused for processing other PDCP SDUs.

[0135] In some embodiments, the first device may be a user equipment (UE), and the second device may be a base station. In some embodiments, the first device may be a base station, and the second device may be a UE. In some embodiments, the first device and the second device may be peer UEs.

[0136] In some embodiments, the first PDCP entity may process the PDCP SDU by integrity protecting and ciphering the PDCP SDU using the COUNT value.

[0137] Fig. 10B A flow chart of a method 1050 performed by a first packet data convergence protocol (PDCP) entity of a first device according to some embodiments is shown. The first PDCP entity may include computer-readable code or instructions executed on one or more processors of the first device. In the present invention, the encoding of software for performing or executing method 1050 is within the scope of ordinary technicians in the field. Method 1050 may include more or fewer operations than shown and described, and may be performed or executed in a different order. The computer-readable code or instructions of the software executable by one or more processors may be stored on a non-transitory computer-readable medium such as a memory of the first device.

[0138] Method 1050 begins at operation 1052, where a first PDCP entity receives COUNT information associated with one or more discard COUNT values ​​from a second PDCP entity of a second device. The one or more discard COUNT values ​​are respectively associated with one or more PDCP data protocol data units (PDUs) that have been discarded by the second PDCP entity. The second PDCP entity is a peer PDCP entity of the first PDCP entity, and is used to process data to be transmitted to the first device. At operation 1054, the first PDCP entity receives a PDCP data PDU from the second PDCP entity. At operation 1056, the first PDCP entity processes the PDCP data PDU to generate a PDCP service data unit (SDU) based on the COUNT information. At operation 1058, the first PDCP entity transmits the PDCP SDU to an associated upper layer without waiting for one or more PDCP data PDUs associated with the one or more discard COUNT values.

[0139] In some embodiments, the first PDCP entity may process the PDCP data PDU based on the COUNT information by determining a COUNT value associated with the PDCP data PDU using the COUNT information.

[0140] In some embodiments, the COUNT information may indicate a first discarded COUNT (FDC) value. The FDC value may be a minimum COUNT value among one or more discarded COUNT values.

[0141] In some embodiments, the COUNT information may further include a bitmap indicating additional discarded COUNT values. The one or more discarded COUNT values ​​may include an FDC value and an additional discarded COUNT value. Each bit in the bitmap may correspond to a unique COUNT value in a continuous COUNT value sequence. The continuous COUNT value sequence may numerically follow the FDC value and include an additional discarded COUNT value. Each bit in the bitmap may carry a first value indicating that the corresponding COUNT value is associated with the corresponding discarded PDCP PDU, or a second value indicating that the corresponding COUNT value is not associated with any discarded PDCP PDU in the discarded PDCP PDU.

[0142] In some embodiments, the first PDCP entity may determine the maximum COUNT value among the one or more discarded COUNT values ​​as the COUNT value corresponding to the last bit set to the first value in the bitmap.

[0143] In some embodiments, the COUNT information may also indicate the total number of additional discarded COUNT values. One or more discarded COUNT values ​​may include the FDC value and the number of consecutive COUNT values ​​that numerically follow the FDC value. The number may be equal to the indicated total number.

[0144] In some embodiments, the first PDCP entity may determine a maximum COUNT value among the one or more discarded COUNT values ​​to be equal to the sum of the FDC value and the total number indicated by the COUNT information.

[0145] In some embodiments, the COUNT information indicates a last discarded COUNT (LDC) value, where the LDC value is a maximum COUNT value among one or more discarded COUNT values.

[0146] In some embodiments, the first PDCP entity may update the state variable RX_NEXT of the first PDCP entity to be equal to the sum of 1 and the maximum COUNT value of the one or more discarded COUNT values ​​in response to determining that the sum is greater than the RX_NEXT value before the update.

[0147] In some embodiments, the first PDCP entity may update a state variable RX_DELIV of the first PDCP entity to be equal to a sum of 1 and a maximum COUNT value of one or more discard COUNT values.

[0148] In some embodiments, the first PDCP entity may update the state variable RX_DELIV of the first PDCP entity to be equal to the minimum COUNT value that satisfies all of the following conditions: greater than the RX_DELIV value before the update; greater than or equal to the sum of 1 and the maximum COUNT value of one or more discarded COUNT values; the PDCP SDU associated with the minimum COUNT value has not yet been transmitted to the upper layer associated with the first PDCP entity, and the upper layer is still waiting for the PDCP SDU.

[0149] In some embodiments, the first PDCP entity may determine a COUNT value that is less than the LDC value and has not yet been received as a discarded COUNT value among the one or more discarded COUNT values.

[0150] In some embodiments, the COUNT information may indicate a first resumed COUNT (FRC) value. The FRC value may be associated with the second PDCP data PDU. The second PDCP data PDU may be the earliest PDCP data PDU to be sent by the second PDCP entity when notified, and the FRC value is the minimum COUNT value to be used by the second PDCP entity when sending the next PDCP data PDU when notifying the first PDCP entity.

[0151] In some embodiments, the first PDCP entity may update the state variable RX_NEXT of the first PDCP entity to be equal to the FRC value indicated by the COUNT information in response to determining that the FRC value is greater than the RX_NEXT value before update.

[0152] In some embodiments, the first PDCP entity may update the state variable RX_DELIV of the first PDCP entity to be equal to the FRC value indicated by the COUNT information.

[0153] In some embodiments, the first PDCP entity may update the state variable RX_DELIV of the first PDCP entity to be equal to the minimum COUNT value that satisfies all of the following conditions: greater than the RX_DELIV value before the update; greater than or equal to the notified FRC value; the PDCP SDU associated with the minimum COUNT value has not yet been transmitted to the upper layer associated with the first PDCP entity, and the upper layer is still waiting for the PDCP SDU.

[0154] In some embodiments, the first PDCP entity may determine a COUNT value that is less than the FRC value and has not yet been received as a discarded COUNT value among the one or more discarded COUNT values.

[0155] In some embodiments, the COUNT information may indicate a hyper frame number (HFN) value of a first resumed COUNT (FRC) value. The FRC value may be associated with the second PDCP data PDU. The second PDCP data PDU may be the earliest PDCP data PDU to be sent by the second PDCP entity when notified. The FRC value is the minimum COUNT value to be used by the second PDCP entity when sending the next PDCP data PDU when notifying the first PDCP entity.

[0156] In some embodiments, the first PDCP entity may receive the COUNT information by receiving the COUNT information in a PDCP control PDU.

[0157] In some embodiments, the first PDCP entity may determine that there is no need to wait for one or more PDCP PDUs associated with one or more discard COUNT values.

[0158] In some embodiments, the first PDCP entity may consider one or more PDCP PDUs associated with one or more discard COUNT values ​​as having been received and delivered to upper layers associated with the first PDCP entity.

[0159] In some embodiments, the first device may be a user equipment (UE), and the second device may be a base station. In some embodiments, the first device may be a base station, and the second device may be a UE. In some embodiments, the first device and the second device may be peer UEs.

[0160] Fig.11 An exemplary communication system 1100 is shown. In general, the system 1100 enables multiple wireless or wired users to send and receive data and other content. The communication system 1100 can implement one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), or non-orthogonal multiple access (NOMA).

[0161] In this example, the communication system 1100 includes electronic devices (ED) 1110a to 1110c, radio access networks (RAN) 1120a to 1120b, a core network 1130, a public switched telephone network (PSTN) 1140, the Internet 1150, and other networks 1160. Fig.11 Certain numbers of these components or elements are shown, but any number of these components or elements may be included in system 1100 .

[0162] EDs 1110a to 1110c are used to operate or communicate in the system 1100. For example, EDs 1110a to 1110c are used to send or receive signals through wireless or wired communication channels. Each ED 1110a to 1110c represents any suitable end-user device and may include (or may be referred to as): user equipment (UE), wireless transmit / receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular phone, personal digital assistant (PDA), smart phone, laptop, computer, touch pad, wireless sensor or consumer electronic device.

[0163] Here, the RAN 1120a and 1120b include base stations 1170a and 1170b, respectively. Each base station 1170a and 1170b is used to wirelessly connect to one or more of the EDs 1110a to 1110c so as to access the core network 1130, the PSTN 1140, the Internet 1150 and / or other networks 1160. For example, the base stations 1170a and 1170b may include (or be) one or more of several well-known devices, such as a base transceiver station (BTS), a Node-B (NodeB), an evolved NodeB (eNodeB), a next generation (NG) NodeB (gNB), a home NodeB, a home eNodeB, a site controller, an access point (AP) or a wireless router. The EDs 1110a to 1110c are used to connect and communicate with the Internet 1150, and can access the core network 1130, the PSTN 1140 or other networks 1160.

[0164] exist Fig.11 In the illustrated embodiment, base station 1170a forms part of RAN 1120a, which may include other base stations, elements or devices. In addition, base station 1170b forms part of RAN 1120b, which may include other base stations, elements or devices. Each base station 1170a and 1170b is used to send or receive wireless signals within a specific geographic area (sometimes referred to as a "cell"). In some embodiments, if each cell has multiple transceivers, multiple-input multiple-output (MIMO) technology can be used.

[0165] Base stations 1170a and 1170b communicate with one or more of EDs 1110a-1110c using wireless communication links over one or more air interfaces 1190. Air interfaces 1190 may utilize any suitable radio access technology.

[0166] It is contemplated that the system 1100 may use multi-channel access functionality, including the schemes described above. In a specific embodiment, the base station and ED implement 5G New Radio (NR), LTE, LTE-A, or LTE-B. Of course, other multiple access schemes and wireless protocols may also be used.

[0167] RAN 1120a and 1120b communicate with core network 1130 to provide voice, data, applications, voice over Internet Protocol (VoIP) or other services to ED 1110a to 1110c. It should be understood that RAN 1120a and 1120b and / or core network 1130 can communicate directly or indirectly with one or more other RANs (not shown). Core network 1130 can also be used as a gateway access to other networks (such as PSTN 1140, Internet 1150 and other networks 1160). In addition, some or all ED 1110a to 1110c may include the ability to communicate with different wireless networks through different wireless links using different wireless technologies and / or protocols. ED can communicate with service providers or switches (not shown) and Internet 1150 through wired communication channels instead of (or in addition to) wireless communication.

[0168] Although Fig.11 An example of a communication system is shown, but the Fig.11 For example, communication system 1100 may include any number of EDs, base stations, networks, or other components in any suitable configuration.

[0169] Fig. 12A and Fig. 12BAn exemplary device is shown in which the methods and instructions according to the present invention can be implemented. Specifically, Fig. 12A An exemplary ED 1210 is shown, Fig. 12B An exemplary base station 1270 is shown. These components may be used in system 1100 or any other suitable system.

[0170] like Fig. 12A As shown, ED 1210 includes at least one processing unit 1200. Processing unit 1200 implements various processing operations of ED 1210. For example, processing unit 1200 can perform signal encoding, data processing, power control, input / output processing, or any other function that enables ED 1210 to operate in system 1100. Processing unit 1200 also supports the methods and teachings described in more detail above. Each processing unit 1200 includes any suitable processing or computing device for performing one or more operations. For example, each processing unit 1200 may include a microprocessor, a microcontroller, a digital signal processor, a field programmable gate array, or an application-specific integrated circuit, etc.

[0171] ED 1210 also includes at least one transceiver 1202. Transceiver 1202 is used to modulate data or other content for transmission through at least one antenna or network interface controller (NIC) 1204. Transceiver 1202 is also used to demodulate data or other content received by at least one antenna 1204. Each transceiver 1202 includes any suitable structure for generating a signal for wireless or wired transmission or for processing a signal received wirelessly or by wire. Each antenna 1204 includes any suitable structure for sending or receiving a wireless signal or a wired signal. One or more transceivers 1202 can be used for ED 1210, and one or more antennas 1204 can be used for ED 1210. Although transceiver 1202 is shown as a single functional unit, it can also be implemented using at least one transmitter and at least one separate receiver.

[0172] ED 1210 also includes one or more input / output devices 1206 or interfaces (e.g., a wired interface to the Internet 1150). Input / output devices 1206 facilitate interaction with users or other devices in a network (network communications). Each input / output device 1206 includes any suitable structure for providing information to or receiving information from a user, such as a speaker, microphone, keypad, keyboard, display, or touch screen, including network interface communications.

[0173] In addition, ED 1210 includes at least one memory 1208. The memory 1208 stores instructions and data used, generated, or collected by ED 1210. For example, the memory 1208 can store software or firmware instructions executed by one or more processing units 1200, as well as data for reducing or eliminating interference in incoming signals. Each memory 1208 includes any suitable volatile or non-volatile storage and retrieval device. Any suitable type of memory can be used, such as random access memory (RAM), read only memory (ROM), hard disk, optical disk, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card.

[0174] like Fig. 12B As shown, the base station 1270 includes at least one processing unit 1250, at least one transceiver 1252 (including the functions of a transmitter and a receiver), one or more antennas 1256, at least one memory 1258, and one or more input / output devices or interfaces 1266. A scheduler understood by those skilled in the art is coupled to the processing unit 1250. The scheduler may be included in the base station 1270 or operate independently of the base station 1270. The processing unit 1250 implements various processing operations of the base station 1270, such as signal encoding, data processing, power control, input / output processing, or any other function. The processing unit 1250 may also support the methods and teachings described in more detail above. Each processing unit 1250 includes any suitable processing or computing device for performing one or more operations. For example, each processing unit 1250 may include a microprocessor, a microcontroller, a digital signal processor, a field programmable gate array, or an application-specific integrated circuit, etc.

[0175] Each transceiver 1252 includes any suitable structure for generating a signal for wireless or wired transmission to one or more EDs or other devices. Each transceiver 1252 also includes any suitable structure for processing signals received from one or more EDs or other devices by wireless or wired means. Although the transmitter and receiver are shown in a combined form as a transceiver 1252, the transmitter and receiver can be independent components. Each antenna 1256 includes any suitable structure for sending or receiving wireless signals or wired signals. Although the common antenna 1256 shown here is coupled to the transceiver 1252, if equipped as an independent component, one or more antennas 1256 can be coupled to the transceiver 1252, allowing independent antennas 1256 to be coupled to the transmitter and receiver. Each memory 1258 includes any suitable volatile or non-volatile storage and retrieval device. Each input / output device 1266 facilitates interaction with users or other devices (network communication) in the network. Each input / output device 1266 includes any suitable structure for providing information to a user or receiving / providing information from a user, including network interface communication.

[0176] Fig.13 13 is a block diagram of a computing system 1300 that can be used to implement the devices and methods disclosed herein. For example, the computing system can be any entity in a UE, an access network (AN), a mobility management (MM), a session management (SM), a user plane gateway (UPGW), or an access stratum (AS). A particular device may use all of the components shown or only a subset of the components, and the level of integration may vary from device to device. In addition, a device may include multiple component instances, such as multiple processing units, processors, memories, transmitters, and receivers. The computing system 1300 includes a processing unit 1302. The processing unit includes a central processing unit (CPU) 1314, a memory 1308, and may also include a mass storage device 1304 connected to a bus 1320, a video adapter 1310, and an I / O interface 1312.

[0177] Bus 1320 may be one or more of any type of several bus architectures, including a storage bus or storage controller, a peripheral bus, or a video bus. CPU 1314 may include any type of electronic data processor. Memory 1308 may include any type of non-transient system memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or a combination thereof. In an embodiment, memory 1308 may include a ROM used at boot time and a DRAM for storing programs and data used when executing a program.

[0178] The mass storage 1304 may include any type of non-transitory storage device for storing data, programs, and other information and making the data, programs, and other information accessible via the bus 1320. The mass storage 1304 may include one or more of a solid-state drive, a hard disk drive, a magnetic disk drive, or an optical disk drive, etc.

[0179] The video adapter 1310 and the I / O interface 1312 provide interfaces to couple external input and output devices to the processing unit 1302. As shown, examples of input and output devices include a display 1318 coupled to the video adapter 1310 and a mouse, keyboard, printer 1316 coupled to the I / O interface 1312. Other devices can be coupled to the processing unit 1302, and additional or fewer interface cards can be used. For example, a serial interface such as a Universal Serial Bus (USB) (not shown) can be used to provide an interface for external devices.

[0180] The processing unit 1302 also includes one or more network interfaces 1306, which may include wired links such as Ethernet cables, and / or wireless links for accessing nodes or different networks. The network interface 1306 allows the processing unit 1302 to communicate with remote units via a network. For example, the network interface 1306 may provide wireless communication via one or more transmitters / transmit antennas and one or more receivers / receive antennas. In one embodiment, the processing unit 1302 is coupled to a local area network 1322 or a wide area network for processing data and communicating with remote devices such as other processing units, the Internet, or remote storage facilities.

[0181] It should be understood that one or more steps of the embodiment methods provided herein may be performed by corresponding units or modules. The corresponding units / modules may be hardware, software, or a combination thereof. For example, one or more units or modules may be integrated circuits, such as field programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs).

[0182] Although described in detail, it should be understood that various changes, substitutions and modifications may be made without departing from the spirit and scope of the invention as defined by the appended claims. In addition, the scope of the invention is not intended to be limited to the specific embodiments described herein, as one of ordinary skill in the art will readily appreciate from the present invention, processes, machines, manufactures, compositions of matter, components, methods or steps (currently existing or to be developed later) may perform substantially the same functions or obtain substantially the same results as the corresponding embodiments described herein. Therefore, the appended claims are intended to include such processes, machines, manufactures, compositions of matter, components, methods or steps within their scope.

Claims

1. A method, characterized in that include: A first packet data convergence protocol PDCP entity of the first device receives a PDCP service data unit SDU from an associated upper layer of the first PDCP entity; The first PDCP entity associates a COUNT value with the PDCP SDU; The first PDCP entity processes the PDCP SDU using the COUNT value to generate a first PDCP data protocol data unit PDU; The first PDCP entity determines that transmission of the first PDCP data PDU needs to be abandoned; The first PDCP entity discards the first PDCP data PDU based on the determination; The first PDCP entity notifies the second PDCP entity of the second device of COUNT information related to one or more discarded COUNT values, wherein the one or more discarded COUNT values ​​are associated with one or more discarded PDCP data PDUs, the one or more discarded PDCP data PDUs include the first PDCP data PDU, and the second PDCP entity is a peer PDCP entity of the first PDCP entity, and is used to process data received from the first device.

2. The method according to claim 1, characterized in that The COUNT information indicates a first discarded COUNT FDC value, where the FDC value is a minimum COUNT value among the one or more discarded COUNT values.

3. The method according to claim 2, characterized in that The COUNT information also includes a bitmap indicating additional discarded COUNT values, the one or more discarded COUNT values ​​including the FDC value and the additional discarded COUNT value, each bit in the bitmap corresponds to a unique COUNT value in a continuous COUNT value sequence, the continuous COUNT value sequence numerically immediately follows the FDC value and includes the additional discarded COUNT value, each bit in the bitmap carries a first value indicating that the corresponding COUNT value is associated with a discarded PDCP data PDU, or a second value indicating that the corresponding COUNT value is not associated with any discarded PDCP data PDU among the discarded PDCP data PDUs.

4. The method according to claim 2, characterized in that: The COUNT information further indicates a total number of additional discarded COUNT values, the one or more discarded COUNT values ​​including the FDC value and a number of consecutive COUNT values ​​numerically following the FDC value, the number being equal to the total number.

5. The method according to claim 1, characterized in that The COUNT information indicates a last discarded COUNT LDC value, where the LDC value is a maximum COUNT value among the one or more discarded COUNT values.

6. The method according to claim 5, characterized in that The notification also includes: The indication is to treat any COUNT value that is less than the LDC value and has not been received when notified as a discarded COUNT value in the one or more discarded COUNT values.

7. The method according to claim 1, characterized in that The COUNT information indicates a first recovery COUNT FRC value, the FRC value being associated with a second PDCP data PDU, the second PDCP data PDU being the earliest PDCP PDU to be sent to the second PDCP entity when transmission to the second PDCP entity is resumed, the FRC value being a minimum COUNT value used after transmission to the second PDCP entity is resumed, and being greater than any of the one or more discarded COUNT values.

8. The method according to claim 7, characterized in that The notification also includes: Indicates that any COUNT value that is less than the FRC value and has not been received when notified will be considered as a discarded COUNT value among the one or more discarded COUNT values.

9. The method according to claim 1, characterized in that: The COUNT information indicates a hyperframe number HFN value of a first restored COUNT FRC value, the FRC value being associated with a second PDCP data PDU, the second PDCP data PDU being the earliest PDCP data PDU to be sent to the second PDCP entity when transmission to the second PDCP entity is resumed, the FRC value being the minimum COUNT value used after transmission to the second PDCP entity is resumed and being greater than any discarded COUNT value among the one or more discarded COUNT values, and the HFN value being a value represented by a pre-specified number of most significant bits of the FRC value.

10. The method according to any one of claims 1 to 9, characterized in that The notifying the second PDCP entity of the second device includes: In response to determining that transmission to the second PDCP entity needs to be resumed, the first PDCP entity sends the COUNT information in the PDCP control PDU to the second PDCP entity.

11. The method according to any one of claims 1 to 10, characterized in that The COUNT information further indicates that the one or more discarded COUNT values ​​are not reused for processing other PDCP SDUs, the other PDCP SDUs being used for a second transmission to the second PDCP entity.

12. The method according to any one of claims 1 to 11, characterized in that The first device is one of a user equipment UE and a base station, and the second device is the other of the UE and the base station.

13. The method according to any one of claims 1 to 11, characterized in that The first device and the second device are peer UEs.

14. The method according to any one of claims 1 to 13, characterized in that The processing of the PDCP SDU comprises: The PDCP SDU is integrity protected and encrypted using the COUNT value.

15. A method, characterized in that include: A first packet data convergence protocol PDCP entity of the first device receives COUNT information related to one or more discarded COUNT values ​​from a second PDCP entity of the second device, wherein the one or more discarded COUNT values ​​are respectively associated with one or more PDCP data protocol data units PDUs that have been discarded by the second PDCP entity, and the second PDCP entity is a peer PDCP entity of the first PDCP entity and is used to process data to be transmitted to the first device; The first PDCP entity receives a PDCP data PDU from the second PDCP entity; The first PDCP entity processes the PDCP data PDU to generate a PDCP service data unit SDU based on the COUNT information; The first PDCP entity delivers the PDCP SDU to an associated upper layer without waiting for the one or more PDCP data PDUs associated with the one or more discard COUNT values.

16. The method according to claim 15, characterized in that The COUNT information indicates a first discarded COUNT FDC value, where the FDC value is a minimum COUNT value among the one or more discarded COUNT values.

17. The method according to claim 16, characterized in that The COUNT information also includes a bitmap indicating additional discarded COUNT values, the one or more discarded COUNT values ​​including the FDC value and the additional discarded COUNT value, each bit in the bitmap corresponds to a unique COUNT value in a continuous COUNT value sequence, the continuous COUNT value sequence numerically immediately follows the FDC value and includes the additional discarded COUNT value, each bit in the bitmap carries a first value indicating that the corresponding COUNT value is associated with the corresponding discarded PDCP PDU, or a second value indicating that the corresponding COUNT value is not associated with any discarded PDCP PDU in the discarded PDCP PDU.

18. The method according to claim 17, characterized in that Also includes: The first PDCP entity determines a maximum COUNT value among the one or more discarded COUNT values ​​as a COUNT value corresponding to a last bit in the bitmap set to the first value.

19. The method according to claim 16, characterized in that The COUNT information further indicates a total number of additional discarded COUNT values, the one or more discarded COUNT values ​​including the FDC value and a number of consecutive COUNT values ​​numerically following the FDC value, the number being equal to the indicated total number.

20. The method according to claim 19, characterized in that Also includes: The first PDCP entity determines a maximum COUNT value among the one or more discarded COUNT values ​​to be equal to a sum of the FDC value and the total number indicated by the COUNT information.

21. The method according to claim 15, characterized in that The COUNT information indicates a last discarded COUNT LDC value, where the LDC value is a maximum COUNT value among the one or more discarded COUNT values.

22. The method according to any one of claims 18, 20 and 21, characterized in that Also includes: In response to determining that the sum is greater than the RX_NEXT value before update, the first PDCP entity updates the state variable RX_NEXT of the first PDCP entity to be equal to the sum of 1 and the maximum COUNT value among the one or more discarded COUNT values.

23. The method according to any one of claims 18, 20 and 21, characterized in that Also includes: The first PDCP entity updates the state variable RX_DELIV of the first PDCP entity to be equal to the sum of 1 and the maximum COUNT value among the one or more discarded COUNT values.

24. The method according to any one of claims 18, 20 and 21, characterized in that Also includes: The first PDCP entity updates the state variable RX_DELIV of the first PDCP entity to be equal to the minimum COUNT value that satisfies all of the following conditions: greater than the RX_DELIV value before the update; greater than or equal to the sum of 1 and the maximum COUNT value among the one or more discarded COUNT values; the PDCP SDU associated with the minimum COUNT value has not yet been transmitted to the upper layer associated with the first PDCP entity, and the upper layer is still waiting for the PDCP SDU.

25. The method according to claim 15, characterized in that The COUNT information indicates a first recovery COUNT FRC value, the FRC value being associated with a second PDCP data PDU, the second PDCP data PDU being the earliest PDCP data PDU to be sent by the second PDCP entity when notified, and the FRC value being the minimum COUNT value to be used by the second PDCP entity when sending the next PDCP data PDU when notifying the first PDCP entity.

26. The method according to any one of claims 15 to 26, characterized in that Also includes: In response to determining that the FRC value is greater than the RX_NEXT value before the update, the first PDCP entity updates the state variable RX_NEXT of the first PDCP entity to be equal to the FRC value indicated by the COUNT information.

27. The method according to claim 15, characterized in that The COUNT information indicates a superframe number HFN value of a first restored COUNT FRC value, the FRC value being associated with a second PDCP data PDU, the second PDCP data PDU being the earliest PDCP data PDU to be sent by the second PDCP entity when notified, and the FRC value being the minimum COUNT value to be used by the second PDCP entity when sending the next PDCP data PDU when notifying the first PDCP entity.

28. The method according to any one of claims 15 to 27, characterized in that Also includes: The first PDCP entity determines that there is no need to wait for the one or more PDCP PDUs associated with the one or more discard COUNT values.

29. The method according to any one of claims 15 to 28, characterized in that Also includes: The first PDCP entity regards the one or more PDCP PDUs associated with the one or more discard COUNT values ​​as having been received and delivered to an upper layer associated with the first PDCP entity.

30. The method according to any one of claims 15 to 29, characterized in that The first device is one of a user equipment UE and a base station, and the second device is the other of the UE and the base station.

31. The method according to any one of claims 15 to 29, characterized in that The first device and the second device are peer UEs.

32. A first device, characterized in that: include: at least one processor; A non-transitory computer-readable storage medium storing instructions, when the instructions are executed by the at least one processor, causes the first Packet Data Convergence Protocol (PDCP) entity of the first device to perform the method according to any one of claims 1 to 14.

33. A first device, characterized in that: include: at least one processor; A non-transitory computer-readable storage medium storing instructions, when the instructions are executed by the at least one processor, causes the first Packet Data Convergence Protocol PDCP entity of the first device to perform the method according to any one of claims 15 to 31.

Images