Methods, apparatus and systems for sensing-based data transmission and reception in wireless networks

Abstract

This disclosure generally relates to methods, apparatus, and systems for congestion control in wireless networks. A method performed by a first network element is disclosed. The method may include: providing a first drop instruction to a second network element, the first drop instruction indicating a list of dropped PDUs or a list of dropped PDU sets, each dropped PDU set in the list of dropped PDU sets including a list of PDUs, wherein the first drop instruction triggers the second network element to drop the list of dropped PDUs or the list of dropped PDU sets; or providing a second drop instruction to the second network element, the second drop instruction indicating that a PDU or a PDU set is dropped, wherein the second drop instruction triggers the second network element to drop the PDU or PDU set.

Description

Technical Field

[0001] This disclosure relates generally to wireless communication, and more particularly to methods, apparatus and systems for sensing-based data transmission in wireless networks. Background Technology

[0002] With the development of wireless communication technology, an increasing number of devices and applications require high data rates and low latency. These applications include extended reality (XR), virtual reality (VR), mixed reality (MR), and video streaming. Efficient and robust congestion control and mitigation mechanisms are crucial for supporting these applications. Receiving entities can utilize the identification and perception of dropped data packets, thus gaining early awareness of these dropped packets.

[0003] Controlling power consumption and reducing energy costs are crucial for the development and deployment of wireless communication networks. Energy-saving technologies are essential for achieving this goal. It is beneficial to transition network elements to sleep mode as soon as it is determined that they have no pending transmission tasks. This transition also requires coordination between the various network elements. Summary of the Invention

[0004] This disclosure relates to a method, apparatus, and system for sensing-based data transmission in a wireless network.

[0005] In some embodiments, a method performed by a first network element is disclosed. The method may include: providing a first discard instruction to a second network element, the first discard instruction indicating a list of discarded Protocol Data Units (PDUs) or a list of discarded PDU sets, each discarded PDU set in the list of discarded PDU sets including a list of PDUs, wherein the first discard instruction triggers the second network element to discard the list of discarded PDUs or the list of discarded PDU sets; or providing a second discard instruction to the second network element, the second discard instruction indicating that a PDU or a PDU set is discarded, wherein the second discard instruction triggers the second network element to discard the PDU or PDU set.

[0006] In some embodiments, a method performed by a first network element is disclosed. The method may include: receiving, by a receiving entity hosted in the first network element, a drop instruction from a second network element, the drop instruction indicating a list of dropped PDUs or a list of sets of dropped PDUs, each PDU set in the list of dropped PDU sets including a list of PDUs; and dropping the list of dropped PDUs or the list of sets of dropped PDUs at a receiving layer corresponding to the receiving entity.

[0007] In some embodiments, a method performed by a wireless device is disclosed. The method may include: sending an indication to a network element that an uplink transmission has been completed; and in response to sending the indication, stopping monitoring of the physical downlink control channel (PDCCH) during the current discontinuous reception (DRX) cycle.

[0008] In some embodiments, a method performed by a wireless device is disclosed. The method may include: receiving an indication from a network element that a downlink transmission has been completed; and, in response to receiving the indication, stopping monitoring the PDCCH in the current DRX cycle.

[0009] In some embodiments, a method performed by a wireless device is disclosed. The method may include: terminating an on-duration period in a DRX cycle in response to receiving from a base station one of the following: a MAC CE message identified by a dedicated downlink LC-ID and not including a data payload; a DCI message indicating the end of the on-duration period; or an end flag used to trigger the end of the on-duration period; and terminating the on-duration period in a DRX cycle in response to the expiration of a DRX on-duration timer.

[0010] In some embodiments, a method performed by a wireless device is disclosed. The method may include sending an indication to a base station that a duration of on-time in a DRX cycle is ending.

[0011] In some embodiments, there is a wireless device or network element including a processor and a memory, wherein the processor is configured to read code from the memory and implement any of the methods described in any embodiment.

[0012] In some embodiments, the computer program product includes computer-readable program medium code stored thereon, which, when executed by a processor, causes the processor to implement any of the methods described in any embodiment.

[0013] The above embodiments and other aspects and alternatives of their implementation are described in more detail in the accompanying drawings, specification and claims. Attached Figure Description

[0014] Figure 1 An example wireless communication network is shown.

[0015] Figure 2 An example wireless network node is shown.

[0016] Figure 3 An example user device is shown.

[0017] Figure 4An exemplary mapping of application frames to Internet Protocol (IP) packets is shown.

[0018] Figure 5 An exemplary protocol stack in the UE and base station is shown.

[0019] Figure 6A and Figure 6B An exemplary message flow is shown for transmitting PDU drop indications or PDU set drop indications between peer entities.

[0020] Figures 7A-7L Various exemplary PDUs are shown for use as PDU drop instructions or PDU set drop instructions.

[0021] Figure 8A-8B Various receiving entities with SDU or SDU set integrity checks are shown.

[0022] Figure 9 An exemplary message flow is shown for an uplink transmission end indication or a PDU set transmission end indication.

[0023] Figure 10 An exemplary message stream is shown for a PDCCH monitoring end indication or an start duration timer end indication.

[0024] Figure 11A An exemplary discontinuous reception (DRX) cycle with a fixed DRX on duration is shown.

[0025] Figure 11B An exemplary DRX cycle with a sliding DRX on duration is shown.

[0026] Figure 12 An exemplary message stream for transmitting parameters related to a PDU set is shown.

[0027] Figures 13A-13C Various exemplary message flows for exchanging congestion indication information are shown. Detailed Implementation

[0028] Wireless communication network

[0029] Figure 1 An exemplary wireless communication network 100 is illustrated, which includes a core network 110 and a radio access network (RAN) 120. The core network 110 also includes at least one mobility management entity (MME) 112 and / or at least one access and mobility management function (AMF). Other functions that may be included in the core network 110 are not shown in the diagram. Figure 1As shown in the diagram. RAN 120 also includes multiple base stations, such as base stations 122 and 124. Base stations may include at least one evolved NodeB (eNB) for 4G LTE, an enhanced LTE eNB (ng-eNB), or a next-generation NodeB (gNB) for 5G New Radio (NR), or any other type of signal transmission / reception equipment, such as a UMTS NodeB. eNB 122 communicates with MME 112 via the S1 interface. Both eNB 122 and gNB 124 can be connected to AMF 114 via the Ng interface. Each base station manages and supports at least one cell. For example, base station gNB 124 can be configured to manage and support cell 1, cell 2, and cell 3.

[0030] The gNB 124 may include a central unit (CU) and at least one distributed unit (DU). The CU and DU may coexist in the same location, or they may be separated into different locations. The CU and DU may be connected via an F1 interface. Alternatively, for an eNB capable of connecting to a 5G network, it may similarly be divided into one CU and at least one DU, referred to as ng-eNB-CU and ng-eNB-DU, respectively. The ng-eNB-CU and ng-eNB-DU may be connected via a W1 interface.

[0031] The wireless communication network 100 may include one or more tracking areas, which may include a set of cells managed by at least one base station. For example, tracking area 1, labeled 140, includes cell 1, cell 2, and cell 3, and may also include cells that can be managed by other base stations. Figure 1 Further cells are not shown. The wireless communication network 100 may also include at least one UE 160. The UE may select one of a plurality of cells supported by the base station to communicate with the base station via an over-the-air (OTA) wireless communication interface and resources, and may reselect a cell for communication as the UE 160 travels within the wireless communication network 100. For example, the UE 160 may initially select cell 1 to communicate with the base station 124, and then may reselect cell 2 at a later point in time. The cell selection or reselection by the UE 160 may be based on the wireless signal strength / quality in each cell and other factors.

[0032] The wireless communication network 100 can be implemented as, for example, a 2G, 3G, 4G / LTE, or 5G cellular communication network. Correspondingly, base stations 122 and 124 can be implemented as 2G base stations, 3G NodeBs, LTE eNBs, or 5G NR gNBs. The UE 160 can be implemented as a mobile or fixed communication device capable of accessing the wireless communication network 100. The UE 160 can include, but is not limited to, mobile phones, laptops, tablets, personal digital assistants, wearable devices, Internet of Things (IoT) devices, MTC / eMTC devices, distributed remote sensor devices, roadside assistance devices, XR devices, and desktop computers. The UE 160 can also generally be referred to as a wireless communication device or a wireless terminal. The UE 160 can support sidechain communication with another UE via a PC5 interface.

[0033] Although the following description focuses on such Figure 1 The cellular wireless communication system shown is based on principles applicable to other types of wireless communication systems used for paging wireless devices. These other wireless systems may include, but are not limited to, Wi-Fi, Bluetooth, ZigBee, and WiMax networks.

[0034] Figure 2 An example of an electronic device 200 for implementing a network base station (e.g., a radio access network node), core network (CN), and / or operation and maintenance (OAM) is shown. Optionally, in one embodiment, the example electronic device 200 may include wireless transmit / receive (Tx / Rx) circuitry 208 to transmit / receive communications with a UE and / or other base stations. Optionally, in one embodiment, the electronic device 200 may also include network interface circuitry 209 to enable the base station to communicate with other base stations and / or the core network, such as optical or wired interconnects, Ethernet, and / or other data transmission media / protocols. The electronic device 200 may optionally include an input / output (I / O) interface 206 for communicating with operators, etc.

[0035] Electronic device 200 may also include system circuitry 204. System circuitry 204 may include processor(s) 221 and / or memory 222. Memory 222 may include operating system 224, instructions 226, and parameters 228. Instructions 226 may be configured to allow one or more processors 221 to perform the functions of a network node. Parameters 228 may include parameters that support the execution of instructions 226. For example, parameters may include network protocol settings, bandwidth parameters, radio frequency mapping assignments, and / or other parameters.

[0036] Figure 3An example of an electronic device for implementing a terminal device 300 (e.g., a user equipment (UE)) is shown. The UE 300 may be a mobile device, such as a smartphone or a mobile communication module located in a vehicle. The UE 300 may include some or all of the following: a communication interface 302, system circuitry 304, input / output interfaces (I / O) 306, display circuitry 308, and storage 309. The display circuitry may include a user interface 310. The system circuitry 304 may include any combination of hardware, software, firmware, or other logic / circuit. The system circuitry 304 may be implemented, for example, using one or more system-on-chip (SoC), application-specific integrated circuit (ASIC), discrete analog and digital circuitry, and other circuitry. The system circuitry 304 may be part of any desired functionality implementation in the UE 300. In this regard, system circuitry 304 may include, for example, logic to facilitate the decoding and playback of music and video, such as MP3, MP4, MPEG, AVI, FLAC, AC3, or WAV decoding and playback; to run applications; to accept user input; to save and retrieve application data; to establish, maintain, and terminate cellular phone calls or data connections, such as internet connections; to establish, maintain, and terminate wireless network connections, Bluetooth connections, or other connections; and to display relevant information on user interface 310. User interface 310 and input / output (I / O) interface 306 may include a graphical user interface, a touch-sensitive display, haptic feedback or other haptic outputs, voice or facial recognition inputs, buttons, switches, speakers, and other user interface elements. Other examples of I / O interface 306 may include microphones, video and still image cameras, temperature sensors, vibration sensors, rotation and orientation sensors, headphone and microphone input / output jacks, universal serial bus (USB) connectors, memory card slots, radiation sensors (e.g., IR sensors), and other types of inputs.

[0037] See Figure 3The communication interface 302 may include radio frequency (RF) transmitting (Tx) and receiving (Rx) circuitry 316 that processes the transmission and reception of signals via one or more antennas 314. The communication interface 302 may include one or more transceivers. The transceiver may be a wireless transceiver that includes modulation / demodulation circuitry, a digital-to-analog converter (DAC), a shaping table, an analog-to-digital converter (ADC), filters, waveform shapers, filters, preamplifiers, power amplifiers, and / or other logic for transmission and reception via one or more antennas or (for some devices) via a physical (e.g., wired) medium. The transmitted and received signals may conform to various formats, protocols, modulations (e.g., QPSK, 16-QAM, 64-QAM, or 256-QAM), frequency channels, bit rates, and encodings. As a specific example, the communication interface 302 may include a transceiver supporting transmission and reception under 2G, 3G, BT, WiFi, Universal Mobile Telecommunications System (UMTS), High-Speed ​​Packet Access (HSPA)+, 4G / LTE, and 5G standards. However, the techniques described below are applicable to other wireless communication technologies, whether from the 3rd Generation Partnership Project (3GPP), the GSM Association, 3GPP2, IEEE, or other partnerships or standards bodies.

[0038] See Figure 3 System circuitry 304 may include one or more processors 321 and memory 322. Memory 322 stores, for example, an operating system 324, instructions 326, and parameters 328. Processor 321 is configured to execute instructions 326 to perform desired functionality for UE 300. Parameters 328 can be provided and specify configuration and operational options for instructions 326. Memory 322 may also store any BT, WiFi, 3G, 4G, 5G, or other data that UE 300 will send or has received via communication interface 302. In various implementations, system power for UE 300 may be provided by power storage devices such as batteries or transformers.

[0039] Application data mapping to PDU / PDU set

[0040] In wireless communication networks, various applications can run on wireless terminals (such as UEs). Some applications, such as XR, VR, MR, and video streaming, require high data rates and low latency. Each application may need to send and / or receive data from the wireless communication network. At the application layer, data can be represented as data units. For example, for video-related applications, there may be various types of frames, such as I-frames, P-frames, and B-frames. See also Figure 4Example application data unit 410 includes multiple application frames. For data transmission in a wireless communication network, each application frame can be sent via multiple Internet Protocol (IP) packets. For example, an I-frame I1 can be mapped to n IP packets, and a B-frame B2 can be mapped to m IP packets, where n and m are positive integers. Multiple IP packets corresponding to the same application frame can be grouped together to form a set of Protocol Data Units (PDUs). Note that the PDU set includes all the necessary information for reconstructing its corresponding application frame. In addition to... Figure 4 In addition to the mapping from application frames to PDU sets shown, PDU sets can also be mapped from other sources, such as media units, media slices, video / audit chunks, haptic application information, etc.

[0041] Each PDU set can be assigned Quality of Service (QoS) requirements, for example, based on the source information mapped to it. Taking application frames as an example, the QoS requirements for a PDU set can be assigned based on the type of the mapped application frame. Different types of application frames can apply different (de)decoding schemes, and different types of frames have different QoS priorities or importance. This will be described in detail below.

[0042] An I-frame is a keyframe that stores the basic data required to display the frame. I-frames can be referenced when decoding other frame types. Typically, in compressed video, I-frames are interspersed with P-frames and B-frames. The more I-frames a video stream contains, the better the video quality. However, compared to other frame types, I-frames can contain the most bits. Therefore, I-frames not only occupy more space on the storage medium but also require more transmission resources, such as radio resources for transmission via the Uu interface and / or wired resources for transmission between network nodes connected via wired / cable connections.

[0043] A P-frame is an incremental frame that contains only data that has changed compared to the previous I-frame (such as color changes (e.g., chroma or luminance) or content changes). Therefore, decoding a P-frame depends on the preceding I-frame. In other words, if the preceding I-frame is lost or cannot be decoded, subsequent P-frames may also fail to be decoded, even if the P-frame itself was not received incorrectly.

[0044] B-frames are also incremental frames; they contain only data that has changed compared to the previous frame and is different from the data in subsequent frames (e.g., the next frame). Therefore, decoding a B-frame depends on the frames before and after it.

[0045] As can be seen, I-frames are considered the most important frames. If an I-frame is lost, subsequent B-frames or P-frames may not be decoded at the receiving end. Therefore, it makes sense to assign a higher QoS priority to the PDU set mapped to an I-frame than to B-frames or P-frames.

[0046] For applications requiring high data rates (such as XR applications), network congestion can occur due to high bandwidth requirements. In network congestion, some lower-priority or less important PDU sets can be dropped / discarded before higher-priority PDU sets must be dropped. For example, a PDU set for an I-frame can be retained, but another PDU set for a P-frame or B-frame can be dropped. If the receiving side is aware of PDU set dropping information (e.g., if the transmitting side marks the PDU set as dropped), the receiving side can reduce PDU reordering delay, PDU set reordering delay, and the delay caused by delivering PDUs and / or PDU sets (or Service Data Units (SDUs) or SDU sets associated with PDUs or PDU sets) to the upper layer.

[0047] Furthermore, if higher layers on the transmission side are aware of network congestion, they can adjust service transmission strategies to alleviate congestion, for example, by adjusting the service data rate and / or service transmission time. If the network (e.g., the base station) and the UE are aware that data transmission has terminated, the UE can promptly stop PDCCH monitoring to save power.

[0048] In this disclosure, sensing-based data transmission and reception in radio communication systems are introduced. The term "sensing" applies to all aspects.

[0049] In one respect, the transmission side can be aware of data packet loss information. For example, the transmission side can know that certain PDUs or sets of PDUs have been dropped, and can mark these PDUs and / or sets of PDUs accordingly.

[0050] On the other hand, the receiving side can be aware of data packet loss information. For example, by checking PDU loss information or PDU set loss information sent by the transmitting side.

[0051] On the other hand, the UE can know that it has no further pending transmission tasks. In this case, the UE can choose to notify the base station and switch to sleep mode, even if the UE is still in the on-druation period.

[0052] On the other hand, the base station can know that it has no further pending transmission tasks for the UE. In this case, the base station can choose to notify the UE, so that the UE can switch to sleep mode, even if the UE is still in the active duration.

[0053] On the other hand, the UE can dynamically adjust its on-time period based on its own perception of the transmission task or based on the perception transmitted from the base station, instead of following a static on-time period.

[0054] In some implementations, data mapping can occur at the PDU level, rather than at the PDU set level. For example, application frames can be mapped to one or more PDUs.

[0055] This disclosure presents various embodiments for implementing service-aware data transmission and reception.

[0056] Example 1: PDU discard indication in PDCP entity

[0057] like Figure 5 As shown, an exemplary radio access network (RAN) may include the following protocol entities:

[0058] • Service Data Adaptive Protocol (SDAP) entity;

[0059] • Packet Data Convergence Protocol (PDCP) entity;

[0060] • Radio Link Control (RLC) entity;

[0061] • Media Access Control (MAC) entity; and

[0062] • Physical layer (PHY) entity.

[0063] Each entity can correspond to a layer. For example, a PDCP entity corresponds to the PDCP layer, and an RCL entity corresponds to the RLC layer.

[0064] In this embodiment, such as Figure 6A As shown, a PDU drop indication and / or PDU set drop indication can be sent from the transmitting PDCP entity to the receiving PDCP entity. The PDCP entity can be hosted in a radio terminal, such as a UE, a base station, such as a gNB, a gNB's CU, etc. The PDCP entity can be implemented as a logical entity or a physical entity.

[0065] If a PDCP entity determines that a PDU or set of PDUs should be discarded, it will mark the PDU or set of PDUs accordingly. In this disclosure, a PDU or set of PDUs marked as discarded may be referred to as a discarded PDU or a discarded PDU set. When a receiving entity receives a PDU or set of PDUs marked as discarded (or to be discarded), the receiving entity can process them accordingly. For example, the receiving entity can simply discard the discarded PDU or the discarded PDU set.

[0066] In some exemplary implementations, the PDU / PDU set drop indication can be initiated by the transport PDCP entity at the PDCP layer and received by the peer receiving PDCP entity at the peer PDCP layer. The PDU drop indication and / or PDU set drop indication can be sent in a PDCP control PDU in various formats, or as an empty PDCP data PDU (e.g., a PDCP data PDU with missing data payload).

[0067] Similarly, in some exemplary implementations, PDU / PDU set discard information can be initiated by the transport RLC entity at the RLC layer and received by the peer receiving RLC entity at the peer RLC layer. PDU discard indication and / or PDU set discard indication can be sent in various formats in the RLC control PDU, or sent as an empty RLC data PDU (e.g., an RLC data PDU with missing data payload).

[0068] In this embodiment, the PDCP layer / entity is used for exemplary purposes. It should be noted that the same principle can be applied to the RLC layer / entity.

[0069] Figure 7A The illustration shows an example PDCP control PDU carrying a PDU discard indication. Figure 7A As shown, the PDU type field in byte 1 is used to indicate that the PDU is used for a PDU discard indication. If the PDU is indicated for a PDU discard indication, the PDU may also include: the total number of discarded PDUs, and a list of sequence numbers (SNs), where each SN in the list corresponds to a discarded PDU. In this example, the "number of discarded PDUs" field occupies one byte, and each PDUSN occupies one byte. For example, byte 2 indicates the total number of discarded PDUs, and this byte can be used to determine the length of the PDU currently controlled by the PDCP. Bytes 3 through byte (3+N) can be used to carry the list of sequence numbers (SNs), where each SN in the list corresponds to a discarded PDU, and N is a non-negative integer. In this example, the total number of discarded PDUs indicated in byte 2 is equal to the number of SNs in the SN list (i.e., the length or size of the SN list).

[0070] Please note that the bit lengths of the fields presented in this disclosure (such as the "Number of PDUs Discarded" field and the "List of SNs of Discarded PDUs" field) are for illustrative purposes only. The bit lengths can be adjusted based on actual needs.

[0071] Figure 7B The illustration shows an example PDCP control PDU carrying a PDU set discard indication. Figure 7BAs shown, the PDU type field in byte 1 is used to indicate that the PDU is used for a PDU set discard indication. If a PDU is indicated for a PDU set discard indication, the PDU may also include: the total number of discarded PDU sets, and a list of SNs, where each SN in the list corresponds to one discarded PDU set. In this example, the total number of discarded PDU sets field occupies one byte, and the SN for each PDU set occupies one byte. For example, byte 2 indicates the total number of discarded PDU sets. Octons 3 through byte (3+N) can be used to carry a list of sequence numbers (SNs), where each SN in the list corresponds to one discarded PDU set, and N is a non-negative integer. In this example, the total number of discarded PDU sets indicated in byte 2 is equal to the number of SNs in the SN list (i.e., the length or size of the SN list).

[0072] Figure 7C The illustration shows another example PDCP control PDU carrying a PDU discard indication. Figure 7C As shown, the PDU type field in byte 1 is used to indicate that the PDU is used for a PDU discard indication. If the PDU is indicated for a PDU discard indication, the PDU may also include: the total number of discarded PDUs, and the SN for the first discarded PDU. In this example, the total number of discarded PDUs field occupies one byte, and the SN for the first discarded PDU occupies N byte fields. For example, byte 2 indicates the total number of discarded PDUs. Bytes 3 through (3+N) indicate the SN for the first discarded PDU, where N is a non-negative integer. In this example, the SNs of the discarded PDUs are consecutive. Therefore, each of the discarded PDUs can be identified based on the total number of discarded PDUs and the first discarded PDU. For example, suppose the first PDU to be discarded has a SN of 101 (i.e., 101 is the starting SN for the discarded PDU), and the total number of discarded PDUs is 8, then PDUs with SNs from 101 to 108 are discarded.

[0073] In this example, the PDCP controls the size of the PDU to be less than Figure 7A The PDCP shown controls the size of the PDU.

[0074] Figure 7D The illustration shows an example PDCP control PDU carrying a PDU set discard indication. Figure 7DAs shown, the PDU type field in byte 1 is used to indicate that the PDU is used for a PDU set discard indication. If the PDU is indicated for a PDU set discard indication, the PDU may also include: the total number of discarded PDU sets, and the SN for the first discarded PDU set. In this example, the total number of discarded PDU sets field occupies one byte, and the SN of the first discarded PDU occupies N byte fields. For example, byte 2 indicates the total number of discarded PDU sets. Bytes 3 through (3+N) indicate the SN of the first discarded PDU set, where N is a non-negative integer. In this example, the SNs of the discarded PDU sets are consecutive. Therefore, each PDU set in the discarded PDU set can be identified based on the total number of discarded PDU sets and the first discarded PDU set. As an example, suppose the first PDU set to be discarded has a SN of 101 (i.e., 101 is the starting SN of the discarded PDU sets), and the total number of discarded PDU sets is 8. Then PDU sets with SNs from 101 to 108 are discarded.

[0075] In this example, the size of the PDCP control PDU is smaller than the size of the PDCP control PDU, such as Figure 7B As shown in the image.

[0076] In some exemplary implementations, PDU discard indication and / or PDU set discard indication can be implicitly indicated by the PDCP data PDU itself, rather than using a dedicated control PDU.

[0077] Figure 7E This illustrates an example format for a PDCP data PDU. This example PDCP data PDU can be associated with a Data Radio Bearer (DRB). The PDCP data PDU includes a PDCP SN (also known as the PDCP PDU SN, or for simplicity, the PDUSN) field, which is 12 bits long. The PDCP SN field can take other lengths, such as 18 bits. Figure 7G and Figure 7H As shown in the image. When a data field or part of the data is missing in the PDCP data PDU, such as... Figure 7F and Figure 7H As shown, it implicitly indicates that the PDCP data PDU is discarded.

[0078] A PDU set may include one or more PDUs. For example, a PDU may be the only PDU in the PDU set; a PDU may be the first PDU in the PDU set (i.e., the starting PDU); a PDU may be the last PDU in the PDU set; or a PDU may be an intermediate PDU in the PDU set (i.e., between the starting PDU and the ending PDU).

[0079] In some exemplary implementations, a PDU Set Information (PSI) field can be introduced into the PDCP data PDU to indicate a PDU set discard indication. The PSI field can indicate whether the current PDU is the only PDU in the PDU set; whether the current PDU is the first PDU in the PDU set (i.e., the starting PDU); whether the current PDU is in the middle of the PDU set; or whether the current PDU is the last PDU in the PDU set. An example explanation of a 2-bit PSI field is shown in Table 1 below.

[0080] Table 1: Explanation of PSI Fields

[0081]

[0082] Note that Table 1 is for illustrative purposes only. Following the same basic principles, the mapping between the values ​​and interpretations of the PSI field can vary. For example, a PSI value of “01” can be used to indicate that the PDU is the last PDU in the PDU set, while 10 can be used to indicate that the PDU is the first PDU in the PDU set.

[0083] Figure 7I Example PDCP data PDUs with a PSI field are shown. In this example, the PDU's SN is 12 bits. Note that a data field is missing in this example PDU, which implicitly indicates that the PDU has been discarded. In some implementations, if one PDU in a PDU set is marked as discarded, the entire PDU set can be implicitly indicated as discarded. For example, if... Figure 7I If the PDU shown is indicated as the first PDU in the PDU set, then the remaining PDUs in the same PDU set (which may be indicated by the PSI field) may also need to be discarded.

[0084] Figure 7J Another example PDCP data PDU with a PSI field is shown. The PDU's SN is 18 bits, and the data field is missing in this PDCP data PDU.

[0085] In some exemplary implementations, in addition to the PSI field, a PDU set SN field can be added to the PDCP data PDU to indicate the SN of the discarded PDU set. By adding the PDU set SN field, not only the relative position of the PDU within the PDU set can be indicated, but also the SN of the PDU set. Therefore, at the receiving end of the PDCP data PDU, the receiving entity can obtain further information about the discarded PDU set.

[0086] Figure 7K The example PDCP data PDU with a PDU set SN field is shown. In this example, the PDU's SN is 12 bits. Note that the PDU is missing a data field, which implicitly indicates that the PDU has been discarded.

[0087] Figure 7L Another example PDCP data PDU with a PDU set SN field is shown. In this example, the PDU's SN is 18 bits. Note that the PDU does not have a data field, which implicitly indicates that the PDU is discarded.

[0088] Example 2: PDU Disposal Indication in RLC

[0089] In this embodiment, such as Figure 6B As shown, a PDU drop indication and / or PDU set drop indication can be sent from the transmitting RLC entity to the receiving RLC entity. The RLC entity can be hosted in a radio terminal (such as a UE), a base station (such as a gNB, a gNB's DU), etc. The RLC entity can be implemented as a logical entity or a physical entity.

[0090] In some exemplary implementations, PDU discard indications and / or PDU set discard indications may be sent in RLC control PDUs (such as RLC status PDUs) or empty RLC data PDUs. Detailed references regarding the format and usage of RLC status PDUs and empty RLC data PDUs can be found in Embodiment 1. At a higher level, the format and usage of RLC status PDUs and empty RLC data PDUs are described below.

[0091] In some exemplary implementations, PDU discard indication and / or PDU set discard indication may be sent in the RLC status PDU. In this embodiment, a new format is defined for the RLC status PDU. This new RLC status PDU may include discarded PDU information or discarded PDU set information to indicate whether a PDU (or a list of PDUs) and / or a PDU set (or a list of PDU sets) has been discarded.

[0092] In some exemplary implementations, PDU discard indication and / or PDU set discard indication can be implicitly indicated by an empty RLC data PDU. It indicates that the PDU is discarded when the RLC data PDU does not contain a data field (e.g., the RLC data PDU is an empty packet, or the RLC data PDU does not contain a payload). The RLC data PDU may include a serial number (SN) for the discarded PDU or set of discarded PDUs, or a list of SNs for a list of discarded PDUs or sets of discarded PDUs.

[0093] In some exemplary implementations, PDU sets are supported during a PDU session. In the RLC layer, Service Data Units (SDUs) can be encapsulated within multiple PDUs in a PDU set. If a transport entity indicates that one or more PDUs in the PDU set have been discarded, or if the transport entity indicates that the entire PDU set has been discarded, the SDUs encapsulated in the PDU set lose their integrity as a whole. For example, in a PDU set with 10 PDUs, PDU5 is indicated to be discarded. The receiving entity (such as an RLC entity) detects that PDU5 was marked as discarded by the transport entity. In this case, the receiving RLC entity can immediately stop processing the PDU set and discard all SDUs encapsulated in that PDU set without delivering any SDUs encapsulated in the PDU set to the upper layer. See also Figure 5 This involves understanding the relationships between upper and lower layers and the protocol / layer stack. In this specific example, since the receiving entity is an RLC entity, it will not deliver any SDUs encapsulated in the PDU set to the PCDP layer. Therefore, no additional processing is required at the upper layers for these incomplete SDUs. Quickly discarding these SDUs not only improves efficiency at the RLC layer and above, but also saves energy in the network components (e.g., UE, base station, etc.) hosting the receiving RLC entity by reducing processing workload. If all SDUs in the PDU set are received, thus passing the integrity test, the RLC layer can deliver only the SDUs to its upper layer (i.e., the PDCP layer).

[0094] In some exemplary implementations, PDU sets are not supported during a PDU session. PDU transmission is performed on a per-PDU basis, not per-PDU set. The receiving RLC entity can still perform SDU integrity checks. At the RLC layer, SDUs can be encapsulated within PDUs. If the transmitting entity indicates a PDU has been discarded, the SDU encapsulated within the PDU loses its integrity. The receiving entity (such as an RLC entity) can detect that a PDU has been discarded from the transmitting entity. In this case, the receiving RLC entity can immediately stop processing or discard the PDU marked as discarded, without even attempting to decapsulate the SDU within the PDU.

[0095] Once the receiving entity becomes aware that certain PDUs or sets of PDUs have been dropped from the transmitting entity, it will not attempt to perform any further processing on those dropped PDUs or sets of PDUs. Furthermore, other tasks on the receiving side (such as reordering tasks and buffering tasks) can continue based on the knowledge that certain PDUs or sets of PDUs have been dropped. Because this knowledge is based on a drop indication, no in-depth checking logic needs to be applied on the receiving side.

[0096] Similar SDU integrity checks can also be performed in other layers, such as the PDCP layer. For example, if any PDU in the PDU set is marked as discarded, the PDCP layer can discard the entire PDU set and not encapsulate and deliver any SDUs in the PDU set to its upper layer, the SDAP layer.

[0097] Figure 8A The illustration depicts an exemplary receive RLC entity operating in unacknowledged mode (UM) with SDU (or SDU set) integrity check 810. In this example, the transmit RLC entity can be hosted by the UE or gNB, corresponding to the receive RLC entity hosted by the gNB or UE. The transmit RLC entity and the receive RLC entity can also be hosted by UE A and UE B, respectively. Furthermore, the interface between the transmit RLC entity and the receive RLC entity can include a radio interface, such as the Uu interface between the UE and the gNB, or the PC5 interface between two UEs.

[0098] Figure 8B An exemplary receiving RLC entity operating in Acknowledgment mode (AM) is illustrated, featuring an SDU (or SDU set) integrity check 820.

[0099] In this embodiment, for illustrative purposes, an SDU / SDU set integrity check is performed at the RLC layer. Similar integrity checks can also be performed at other layers, such as the PDCP layer. For example, if a PDU set is not marked as discarded, the PDCP layer may only deliver the SDU sets associated with that PDU set to the upper layer (e.g., the SDAP layer). Once the receiving PDCP entity detects that a PDU set has been marked as discarded, it can explicitly discard the entire PDU set without any further processing of the discarded PDU set or delivering any SDUs associated with that PDU set to the SDAP layer.

[0100] Example 3: Uplink transmission or PDU set transmission end indication from UE

[0101] In wireless communication, discontinuous reception (DRX) mode has been introduced for UEs and / or base stations to save energy. For example... Figure 11A As shown, in DRX mode, the UE can be periodically woken up based on a periodicity (DRX period 1102). Within each DRX period, there can be an on-duration period 1104 during which the UE is woken up and capable of performing uplink transmissions and / or downlink receptions. The on-duration period 1104 can be tracked by a DRX duration timer. In current practice, once a specific DRX configuration is applied, the on-duration period is fixed. Figure 11AAs shown, the on-duration period 1104 begins at T1 and ends at T2. However, the UE may complete its transmission task earlier and does not need to use the entire on-duration period. It is beneficial for the UE to report this situation to the base station so that the UE can transition to sleep mode earlier (before the end of the on-duration period). At the same time, the base station can also avoid attempting to receive uplink data from the UE, since the UE has no further uplink data to transmit in the current DRX cycle. Alternatively, the base station can stop scheduling downlink transmissions for the UE in the current DRX cycle.

[0102] See Figure 9 In this embodiment, the UE can send an early termination indication to the base station to indicate that the uplink transmission or PDU set transmission has been completed.

[0103] An early termination instruction can be sent from the UE to the base station through at least one of the following:

[0104] • A Buffer Status Report (BSR) message indicating that the UE's buffer size is zero;

[0105] • Media Access Control-Control Unit (MAC CE) messages. MAC CE messages are associated with or identified by a Dedicated Uplink Logical Channel Identifier (LC-ID) and do not include a data payload. In one implementation, the Dedicated Uplink LC-ID may be associated with uplink data transmission;

[0106] • An uplink control information (UCI) message indicating that uplink transmission is complete; or

[0107] • An uplink transmission end flag indicating that uplink transmission is complete.

[0108] An uplink transmission end marker can be included in a PDU (e.g., appended to a PDU), such as the last PDU in an uplink transmission. The uplink transmission end marker can also be included in a set of PDUs, such as the last set of PDUs in an uplink transmission. Alternatively, the uplink transmission end marker can be sent via a separate message.

[0109] In some exemplary implementations, after the UE sends an early termination indication, the UE can stop monitoring the PDCCH in the current DRX cycle even if the UE is still in the on-duration period. That is, the UE can behave as if the DRX on-duration timer has expired and / or the DRX inactivity timer has been set to zero.

[0110] Example 4: PDCCH monitoring from the base station and / or end indication of the duration timer

[0111] When a base station schedules downlink transmissions for a UE, it can intelligently determine that there is no further downlink data for the UE. For example, even if the UE is still in the active duration, the base station can determine that there is no further downlink data for the UE in the current DRX cycle. In this case, the base station can choose to notify the UE to terminate downlink data transmission early, rather than keeping the UE in the active state. Therefore, the UE can transition to sleep mode earlier, reducing power consumption.

[0112] See Figure 10 In this embodiment, the base station can send an early termination indication to the UE to indicate that the UE can stop PDCCH monitoring or the UE can stop starting the duration timer, so that the UE can switch to sleep mode.

[0113] An early termination instruction can be sent from the base station to the UE through at least one of the following:

[0114] • A MAC CE message, which is associated with or identified by a dedicated downlink LC-ID and does not include a data payload. In one implementation, the dedicated downlink LC-ID is associated with downlink data transmission;

[0115] • A PDCCH downlink control information (DCI) message indicating that downlink transmission is complete; or

[0116] • A downlink transmission end flag indicating that downlink transmission is complete.

[0117] The downlink transmission end marker can be included in the PDU (e.g., appended to the PDU), such as the last PDU in the downlink transmission. The downlink transmission end marker can also be included in a set of PDUs, such as the last set of PDUs in the downlink transmission. Alternatively, the downlink transmission end marker can be sent via a separate message.

[0118] In some exemplary implementations, after the UE receives an early termination indication, the UE can stop monitoring the PDCCH during the current DRX cycle, even if the UE is still in the on-duration period. That is, the UE can behave as if the DRX on-duration timer has expired and / or the DRX inactivity timer has been set to zero.

[0119] Example 5: Slide-on duration period

[0120] As previously mentioned, the DRX enable duration period within a DRX cycle can be tracked by a DRX enable duration timer. For example, the enable duration period ends when the DRX enable duration timer expires. In current practice, the enable duration period is fixed once a specific DRX configuration is applied.

[0121] In this embodiment, a sliding opening duration period is introduced. For example... Figure 11B As shown, in DRX cycle 1112, the DRX enable duration timer expires at T3. There is a DRX enable duration 1110, which begins at T1 and ends at T2. T2 can be a sliding time point that can slide between T1 and T3. Under certain conditions, the UE and / or base station can determine that the UE no longer has pending transmissions, and therefore T2 can be dynamically adjusted once there are no pending downlink and / or uplink transmission tasks.

[0122] In some exemplary implementations, the UE can determine to end the DRX on-time duration before T3. In this case, the UE can notify the base station of the early termination of the DRX on-time duration by sending at least one of the following:

[0123] • A BSR message indicating that the UE's buffer size is zero;

[0124] • MAC CE message, which is associated with or identified by a dedicated uplink LC-ID and does not include a data payload;

[0125] • An uplink control information (UCI) message indicating that the duration of the enabled period in the DRX cycle is ending; or

[0126] • An end marker indicating that the on duration period in the DRX cycle is coming to an end.

[0127] If the UE determines that it does not apply the early termination of the DRX enable duration, the DRX enable duration will end once the DRX enable duration timer expires.

[0128] In some exemplary implementations, the base station may determine to end the DRX on-time duration before T3. In this case, the base station can notify the UE of the early termination of the DRX on-time duration by sending at least one of the following:

[0129] • MAC CE messages are associated with or identified by a dedicated uplink LC-ID and do not include a data payload;

[0130] • A downlink control information (DCI) message indicating that downlink transmission is complete; or

[0131] • A downlink transmission end flag indicating that downlink transmission is complete.

[0132] In some exemplary implementations, the UE can also determine the verification period for configuring authorization (CG) resources based on the DRX enable duration. For example... Figure 11B As shown, the effective duration of CG resources 1114 can be based on the DRX enabled duration 1110. For example, the effective duration of CG resources 1114 can be the same as the DRX enabled duration 1110.

[0133] During the DRX enabled duration period 1110, CG resources (such as CG resources used for Scheduling Requests (SRs) or BSRs) are available. CG resources can be used for uplink quasi-periodic services, such as periodic services with arrival time jitter. When an uplink service arrives, the UE can use pre-configured CG resources to send SRs or BSRs, which can reduce uplink transmission latency. When an uplink service ends, the UE can stop monitoring the PDCCH and release CG resources, which can save UE power and radio resources.

[0134] Example 6: PDU Set Related Parameters

[0135] In this embodiment, the core network (CN) can use messages (such as UE association signaling) to send parameters related to the PDU set to the base station.

[0136] The parameters associated with a PDU set include at least one of the following:

[0137] Survival time indicates one of the following: the maximum period of time during which the PDU set is valid, or the maximum period of time during which the application can survive without receiving any data bursts.

[0138] The start time of the PDU set indicates the start time of the PDU set, such as the arrival time of the first PDU in the PDU set (i.e., the starting PDU).

[0139] The end time of the PDU set, indicating the end time of the PDU set, such as the arrival time of the last PDU in the PDU set.

[0140] The duration of a PDU set that indicates the duration of the PDU set (e.g., the duration from the arrival time of the first PDU in the PDU set to the arrival time of the last PDU in the PDU set).

[0141] The grouping period used for groups in a PDU set.

[0142] The grouping interval used for groups in a PDU set.

[0143] The number of groups in the PDU set.

[0144] The group size used for each group in the PDU set.

[0145] The variance of the group size used for grouping in the PDU set. This may be the expected variance of the generated groupings, which can be used to determine the range of group sizes.

[0146] The size of the first packet in the PDU set. This can be useful for periodic services. For example, it can be used to determine or select a configuration authorization configuration, or for the semi-persistent scheduling (SPS) configuration of the first packet in the PDU set for periodic services. The remaining packets in the PDU set can be scheduled dynamically.

[0147] The minimum size of the PDU set. This can be used to determine or select the CG or SPS configuration for the PDU set. The remaining packets of the PDU set can be dynamically scheduled.

[0148] The Packet Delay Budget (PDB) for each Quality of Service (QoS) subflow. This can be used to indicate the upper limit of the time that packets in a QoS subflow may be delayed between the UE and the N6 termination point at the User Plane Function (UPF). When the PDB of a QoS subflow is received, the gNB can apply this PDB value to the corresponding QoS subflow. In the case where a QoS subflow is received but its PDB is not received, the gNB can use the PDB value of the relevant QoS flow for that QoS subflow (e.g., if the PDB is configured only in each QoS flow level, the PDB for each QoS flow level can be applied to the QoS subflow within the QoS flow).

[0149] The Packet Error Rate (PER) for each QoS subflow. This can be used to indicate the upper limit of the packet error rate for each QoS subflow. When the PER of a QoS subflow is received, the gNB applies this PER value to the corresponding QoS subflow. If a QoS subflow is received but its PER is not, the gNB can apply the PER value of the relevant QoS flow to that QoS subflow (e.g., if PER is configured only at each QoS flow level, then the PER at each QoS flow level can be applied to QoS subflows within the QoS flow).

[0150] The PDB (CN PDB) for each QoS subflow in the core network. This can be used to indicate the delay between any N6 termination point at the UPF (for any UPF that may be selected for a PDU session) and the 5G-AN in the QoS subflow. When the CN PDB of a QoS subflow is received, the gNB can apply the CN PDB value to the corresponding QoS subflow. In the case of receiving a QoS subflow but not receiving its CN PDB, the gNB can apply the CN PDB value of the relevant QoS flow to that QoS subflow (e.g., if the CN PDB is configured only in each QoS flow level, the CN PDB for each QoS flow level can be applied to the QoS subflow within the QoS flow).

[0151] PDU set delay budget indicates an upper limit on the duration, which is the duration of the PDU set between a given set of nodes from the transmission of the first packet to the reception of the last packet.

[0152] Example 7:

[0153] In this embodiment, congestion indication information can be exchanged between different network elements, such as between the UE and the base station, or between the base station and the core network (or core network nodes). Congestion indication information can also be exchanged between the application layer (e.g., the data network) and various entities or modules within the UE (e.g., the 5G system (5GS) module within the UE).

[0154] Congestion indication information may include at least one of the following:

[0155] • Network components may be congested or not.

[0156] • The congestion level of the network element selected from a predefined list of congestion levels;

[0157] • Overload status indication;

[0158] • Resource congestion status indication; or

[0159] • Higher Quality of Experience (QoE) preference indicator.

[0160] Figure 13A The diagram illustrates congestion indication information exchanged between the core network (or core network node) and the base station. This congestion indication information can be transmitted via UE-associated signaling, cell-level signaling, gNB-level signaling, or the GPRS Tunneling Protocol User Plane (GTP-U) header.

[0161] Figure 13BThe diagram illustrates the congestion indication information exchanged between the base station and the UE. This congestion indication information can be transmitted via MAC CE, RRC signaling (e.g., UE Auxiliary Information Message), UCI, PDCP header, or RLC header.

[0162] Figure 13C The diagram illustrates congestion indication information exchanged between the 5GS and the application layer. This congestion indication information can be sent by transport layer protocols such as Transmission Control Protocol (TCP), IP, User Datagram Protocol (UDP), Ethernet frame structures, etc. It can also be sent based on device implementations at the Access Layer (AS), Non-Access Layer (NAS), and higher layers.

[0163] The foregoing description and accompanying drawings provide specific exemplary embodiments and implementations. However, the described subject matter can be embodied in a variety of different forms, and therefore the covered or claimed subject matter is intended to be construed as not being limited to any of the exemplary embodiments set forth herein. The scope of the claimed or covered subject matter is intended to be quite broad. Among other things, the subject matter can be embodied as a method, apparatus, component, system, or non-transitory computer-readable medium for storing computer code. Therefore, embodiments can take the form, for example, hardware, software, firmware, storage medium, or any combination thereof. For example, the above-described method embodiments can be implemented by executing computer code stored in memory by a component, apparatus, or system including memory and a processor.

[0164] Throughout the specification and claims, terms may have contextual implications or subtle meanings beyond their explicitly stated meanings. Similarly, the phrase "in one embodiment / implementation" as used herein does not necessarily refer to the same embodiment, and the phrase "in another embodiment / implementation" as used herein does not necessarily refer to a different embodiment. For example, the claimed subject matter is intended to include combinations of all or some of the exemplary embodiments.

[0165] Generally, terms can be understood, at least in part, based on their use in context. For example, terms such as “and,” “or,” or “and / or” as used herein may have multiple meanings that may depend, at least in part, on the context in which they are used. Typically, “or,” when used in an associative list such as A, B, or C, is intended to mean A, B, and C (used herein in an inclusive sense) and A, B, or C (used herein in an exclusive sense). Furthermore, the term “one or more,” as used herein, depends at least in part on the context and can be used to describe any feature, structure, or characteristic in a singular form, or in a plural form, to describe a combination of features, structures, or characteristics. Similarly, depending at least in part on the context, the terms “a,” “an,” or “the” can be understood to convey either a singular or a plural usage. Moreover, again, depending at least in part on the context, the term “based on” can be understood to not necessarily convey a set of exclusive factors, but rather to allow for the presence of additional factors that are not necessarily explicitly described.

[0166] References to features, advantages, or similar language throughout this specification do not imply that all features and advantages achievable with this solution should be included in or be incorporated into any single implementation of it. Rather, references to features and advantages should be understood to mean that a particular feature, advantage, or characteristic described in relation to an embodiment is included in at least one embodiment of this solution. Therefore, discussions of features and advantages, as well as similar language, throughout this specification may, but do not necessarily, refer to the same embodiments.

[0167] Furthermore, the features, advantages, and characteristics described in this solution can be combined in one or more embodiments in any suitable manner. Those skilled in the art will recognize that, based on the description herein, this solution can be practiced without one or more specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments, which may not be present in all embodiments of this solution.

Claims

1. A method for wireless communication, performed by a first network element, the method comprising one of the following: A first drop instruction is provided to a second network element, the first drop instruction specifying a list of dropped Protocol Data Units (PDUs) or a list of dropped PDU sets, each of the dropped PDU sets in the list including a list of PDUs, wherein the first drop instruction triggers the second network element to drop the list of dropped PDUs or the list of dropped PDU sets; or A second discard instruction is provided to the second network element, the second discard instruction indicating that a PDU or a set of PDUs is discarded, wherein the second discard instruction triggers the second network element to discard the PDU or the set of PDUs.

2. The method of claim 1, wherein the list of discarded PDUs or the list of discarded PDU sets is associated with the PDU session of the first network element.

3. The method of claim 1, wherein the first drop instruction or the second drop instruction is initiated from a layer in a protocol stack comprising at least one layer.

4. The method according to any one of claims 1-3, wherein providing the first drop instruction to the second network element comprises: The first drop instruction is provided to the second network element via a control PDU, the first drop instruction specifying the list of PDUs to be dropped or the list of sets of PDUs to be dropped.

5. The method of claim 4, wherein the control PDU comprises at least one of the following: The control PDU is used in the PDU type field of the PDU discard indication; The size of the list of discarded PDUs; A list of PDU serial numbers (SNs) indicating the PDUs that have been discarded; The size of the list of discarded PDU sets; or A list of SNs indicating the set of PDUs to be discarded.

6. The method of claim 4, wherein the control PDU comprises at least one of the following: The control PDU is used in the PDU type field of the PDU discard indication; The size of the list of discarded PDUs; The serial number (SN) of the starting PDU in the list of discarded PDUs, and the serial numbers of the elements in the list of discarded PDUs are consecutive; The size of the list of discarded PDU sets; or The SN of the first PDU set in the list of discarded PDU sets, wherein the SNs of the elements in the list of discarded PDU sets are consecutive.

7. The method according to claim 4, wherein: The first drop instruction is initiated by the PDCP entity hosted by the first network element in the Packet Data Convergence Protocol (PDCP) layer; and Providing the first drop instruction to the second network element includes: Provide the PDCP entity hosted by the second network element with a first drop instruction indicating the list of dropped PDUs or the list of sets of dropped PDUs; and The control PDU includes the PDCP control PDU.

8. The method according to claim 4, wherein: The first drop instruction is initiated by the RLC entity hosted by the first network element in the Radio Link Control (RLC) layer; and Providing the first drop instruction to the second network element includes: Provide the RLC entity hosted by the second network element with a first drop instruction indicating the list of dropped PDUs or the list of sets of dropped PDUs; and The control PDU includes the RLC control PDU.

9. The method according to any one of claims 1-3, wherein: The PDU is a data PDU; and Providing the second network element with a second drop instruction indicating that the PDU or the set of PDUs is dropped includes: The data PDU without a data field is provided to the second network element, wherein the absence of the data field in the data PDU implicitly indicates that the data PDU is discarded.

10. The method according to any one of claims 1-3, wherein: The PDU is the data PDU in the PDU set; and Providing the second network element with a second drop instruction indicating that the PDU or the set of PDUs is dropped includes: The data PDU without a data field is provided to the second network element, wherein the absence of the data field in the data PDU implicitly indicates that the set of PDUs is discarded.

11. The method according to claim 9, wherein: The second drop instruction is initiated in the PDCP layer by the PDCP entity hosted by the first network element; and Providing the second discard instruction to the second network element includes: Provide the PDCP entity hosted by the second network element with a second drop instruction indicating the list of dropped PDUs or the list of sets of dropped PDUs; and The data PDUs include PDCP data PDUs.

12. The method according to claim 9, wherein: The second drop instruction is initiated in the RLC layer by the RLC entity hosted by the first network element; and Providing the second discard instruction to the second network element includes: Provide the RLC entity hosted by the second network element with a second drop instruction indicating the list of dropped PDUs or the list of sets of dropped PDUs; and The data PDUs include RLC data PDUs.

13. The method of claim 10, wherein the PDU includes a field indicating at least one of the following: The PDU is a unique PDU in the PDU set; The PDU is the starting PDU in the PDU set; The PDU is the last PDU in the PDU set; or The PDU is the PDU between the starting PDU and the last PDU in the PDU set.

14. The method according to any one of claims 1-3, wherein: The PDU is the data PDU in the PDU set; The PDU includes an identifier for the PDU set; and Providing the second network element with a second drop instruction indicating that the PDU or the set of PDUs is dropped includes: The data PDU without a data field is provided to the second network element, wherein the absence of the data field in the data PDU implicitly indicates that the PDU set identified by the identifier of the PDU set is discarded.

15. The method of claim 14, wherein the identifier of the PDU set includes the SN of the PDU set.

16. The method according to any one of claims 1-3, wherein the combination of the first network element and the second network element comprises at least one of the following: The first network element includes a first user equipment (UE), and the second network element includes a base station; The first network element includes the base station, and the second network element includes the first UE; or The first network element includes the first UE, and the second network element includes the second UE.

17. A method for wireless communication, performed by a first network element, the method comprising: The receiving entity hosted in the first network element receives a drop instruction from the second network element, the drop instruction specifying a list of dropped PDUs or a list of dropped PDU sets, each PDU set in the list of dropped PDU sets including a list of PDUs; as well as At the receiving layer corresponding to the receiving entity, the list of discarded PDUs or the list of discarded PDU sets are discarded.

18. The method of claim 17, wherein the list of discarded PDUs or the list of discarded PDU sets is associated with a PDU session of the second network element.

19. The method of claim 17, wherein the drop instruction is initiated from a layer in a protocol stack comprising at least one layer.

20. The method of any one of claims 17-19, wherein the drop instruction is received by an RLC entity hosted by the first network element, and wherein receiving the drop instruction from the second network element comprises: The RLC entity hosted by the second network element receives the discard instruction, which indicates the list of PDUs to be discarded or the list of sets of PDUs to be discarded.

21. The method according to any one of claims 17-19, wherein the drop instruction is received by a PDCP entity hosted by the first network element, and wherein receiving the drop instruction from the second network element comprises: The PDCP entity hosted by the second network element receives the discard instruction, which indicates the list of PDUs to be discarded or the list of sets of PDUs to be discarded.

22. The method according to any one of claims 17-19, wherein the list of discarded PDUs or the list of discarded PDU sets comprises: At the receiving layer corresponding to the receiving entity, the list of discarded PDUs or the list of discarded PDU sets is discarded without delivering any data payload associated with the list of discarded PDUs or the list of discarded PDU sets to the upper layer of the receiving layer.

23. The method according to any one of claims 17-19, wherein the combination of the first network element and the second network element comprises at least one of the following: The first network element includes a first user equipment (UE), and the second network element includes a base station; The first network element includes the base station, and the second network element includes the first UE; or The first network element includes the first UE, and the second network element includes the second UE.

Images