Robust header compression during packet data convergence protocol reconstruction

Abstract

The receiving device reestablishes a Packet Data Convergence Protocol (PDCP) entity. The receiving device resets a Robust Header Compression (ROHC) context. The receiving device receives a packet retransmission with ROHC-based header compression. The receiving device decompresses the packet retransmission. The receiving device discards duplicate packets after decompressing the packet retransmission.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of priority to provisional application serial no. 63 / 007,828, filed on April 9, 2020, and entitled “ROBUST HEADER COMPRESSION HANDLING DURING PACKET DATA CONVERGENCE PROTOCOL RE-ESTABLISHMENT,” which is expressly incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure generally relates to communication systems, and more particularly, to wireless communications including robust header compression. Background Art

[0004] Wireless communication systems are widely deployed to provide a variety of telecommunication services such as telephony, video, data, messaging, and broadcasts. Typical wireless communication systems may employ multiple access technologies capable of supporting communication with multiple users by sharing available system resources. Examples of such multiple access technologies include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single-carrier frequency division multiple access (SC-FDMA) systems, and time division synchronous code division multiple access (TD-SCDMA) systems.

[0005] These multiple access technologies have been adopted in various telecommunication standards to provide a common protocol that enables different wireless devices to communicate at a city, country, region, and even global level. An example telecommunication standard is 5G New Radio (NR). 5G NR is part of the continued mobile broadband evolution released by the 3rd Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (for example, in conjunction with the Internet of Things (IoT)), and other requirements. 5G NR includes services associated with enhanced mobile broadband (eMBB), massive machine type communications (mMTC), and ultra-reliable low latency communications (URLLC). Some aspects of 5G NR may be based on the 4G Long Term Evolution (LTE) standard. There is a need for further improvements to 5G NR technology. These improvements may also be applicable to other multiple access technologies and telecommunication standards that employ these technologies. Summary of the Invention

[0006] The following is a brief summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects and is neither intended to identify key or critical elements of all aspects nor to delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that will be presented later.

[0007] In one aspect of the present disclosure, a method, computer-readable medium, and apparatus for wireless communication at a receiving device are provided. The apparatus reestablishes a Packet Data Convergence Protocol (PDCP) entity. The apparatus resets a Robust Header Compression (ROHC) context. The apparatus receives a packet retransmission with ROHC-based header compression. The apparatus decompresses the packet retransmission. After decompressing the packet retransmission, the apparatus discards duplicate packets.

[0008] In one aspect of the present disclosure, a method, computer-readable medium, and apparatus for wireless communication at a receiving device are provided. The apparatus receives a plurality of packets based on a first ROHC context. The apparatus reestablishes a PDCP entity. The apparatus resets to a second ROHC context. The apparatus sends a PDCP status report for the plurality of packets, wherein the PDCP status report indicates a negative acknowledgement (NACK) for each packet starting with a first lost packet.

[0009] In one aspect of the present disclosure, a method, computer-readable medium, and apparatus for wireless communication at a transmitting device are provided. The apparatus transmits a plurality of packets based on a first ROHC context. The apparatus receives an RLC acknowledgment (ACK) for a packet from the plurality of packets that is successfully received based on the first ROHC context. The apparatus reestablishes a PDCP entity. The apparatus resets to a second ROHC context. The apparatus receives a PDCP status report for the plurality of packets, wherein the PDCP status report indicates a negative acknowledgement (NACK) for each packet starting with a first lost packet.

[0010] To accomplish the foregoing and related objectives, one or more aspects include the features hereinafter fully described and particularly pointed out in the claims. The following description and the accompanying drawings set forth in detail certain illustrative features of one or more aspects. However, these features are indicative of only some of the various ways in which the principles of the various aspects may be employed, and this description is intended to include all such aspects and their equivalents. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 is a schematic diagram illustrating an example of a wireless communication system and an access network.

[0012] Figure 2A 、2B , 2C and 2D are diagrams showing examples of a first 5G / NR frame, a DL channel within a 5G / NR subframe, a second 5G / NR frame, and a UL channel within a 5G / NR subframe, respectively.

[0013] Figure 3 is a schematic diagram showing an example of a base station and a UE in an access network.

[0014] Figure 4 is a diagram illustrating an example of a PDCP architecture.

[0015] Figure 5 is an example communication flow between a transmitting PDCP entity and a receiving PDCP entity.

[0016] Figure 6 is a diagram illustrating an example of a PDCP architecture.

[0017] Figure 7 is an example communication flow between a transmitting PDCP entity and a receiving PDCP entity according to aspects of the present disclosure.

[0018] Figure 8 is an example communication flow between a transmitting PDCP entity and a receiving PDCP entity according to aspects of the present disclosure.

[0019] Figure 9 is a flow chart of a method of wireless communication.

[0020] Figure 10 is a diagram illustrating an example of a hardware implementation for an example apparatus according to various aspects presented herein.

[0021] Figure 11 is a flow chart of a method of wireless communication.

[0022] Figure 12 is a diagram illustrating an example of a hardware implementation for an example apparatus according to various aspects presented herein.

[0023] Figure 13 is a flow chart of a method of wireless communication.

[0024] Figure 14 is a flow chart of a method of wireless communication.

[0025] Figure 15 is a flow chart of a method of wireless communication. DETAILED DESCRIPTION

[0026] The specific embodiments described below in conjunction with the accompanying drawings are intended to serve as descriptions of various configurations and are not intended to represent the only configurations in which the concepts described herein may be practiced. For the purpose of providing a comprehensive understanding of the various concepts, the specific embodiments include specific details. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring such concepts.

[0027] Several aspects of telecommunications systems will now be presented with reference to various apparatuses and methods. These apparatuses and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as "elements"). These elements can be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system.

[0028] For example, an element, or any part of an element, or any combination of elements, can be implemented as a "processing system" comprising one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs), central processing units (CPUs), application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, systems on a chip (SoCs), baseband processors, field programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gating logic, discrete hardware circuits, and other suitable hardware configured to perform the various functions described throughout this disclosure. One or more processors in a processing system can execute software. Whether referred to as software, firmware, middleware, microcode, hardware description language, or other names, software should be broadly interpreted as meaning instructions, instruction sets, codes, code segments, program codes, programs, subroutines, software components, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, processes, functions, etc.

[0029] Accordingly, in one or more exemplary embodiments, the described functions can be implemented in hardware, software, or any combination thereof. If implemented in software, the functions can be stored or encoded on a computer-readable medium as one or more instructions or codes. Computer-readable media include computer storage media. Storage media can be any available medium that can be accessed by a computer. By way of example and not limitation, such computer-readable media can include random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), optical disk storage devices, magnetic disk storage devices, other magnetic storage devices, a combination of the above-mentioned types of computer-readable media, or any other medium that can be used to store computer-executable code in the form of instructions or data structures that can be accessed by a computer.

[0030] During a handover process in which a UE switches from one base station to another, and / or during a radio link failure (RLF) re-establishment between the UE and the base station, the UE and the base station may be configured to perform PDCP re-establishment. During and / or after the PDCP re-establishment, the receiving PDCP entity may discard some duplicate PDCP packets, which may appear as a loss to the ROHC decompressor of the receiving PDCP entity, which may affect the compression efficiency of the ROHC decompressor. In addition, when the receiving PDCP entity processes PDCP SDUs that were stored out of order before the ROHC reset, some out of order PDCP SDUs may appear as a loss to the ROHC decompressor, which may affect the synchronization between the receiving PDCP entity and the corresponding transmitting PDCP entity. The various aspects given herein may improve the efficiency of ROHC compression and decompression for, for example, a transmitting PDCP entity and a receiving PDCP entity during PDCP re-establishment. The various aspects given herein may reduce the PDCP packets that may appear as a loss to the ROHC decompressor, and may also reduce the PDCP packets processed by the ROHC compressor.

[0031] Figure 1 1 is a diagram illustrating an example of a wireless communication system and access network 100. In certain aspects, a base station 102 or 180 and / or a UE 104 may include a PDCP component 198 configured to change the order in which ROHC header decompression and duplicate PDCP packet discarding are processed, for example, during a PDCP reestablishment. For example, the UE 104 or base station 102 or 180 may reestablish a PDCP entity, reset the ROHC context, and receive a packet retransmission with ROHC-based header compression. The PDCP component may be configured to perform decompression on the packet retransmission and discard the duplicate packet after performing decompression on the packet retransmission.

[0032] Alternatively, the PDCP component 198 may be configured to not decompress any out-of-order PDCP packets and to send a PDCP status report with NACK feedback for lost and / or out-of-order PDCP packets. Various aspects presented herein may improve the efficiency of ROHC operations. For example, the PDCP component 198 may be configured to receive a plurality of packets based on a first ROHC context. After reestablishing the PDCP entity and resetting to a second ROHC context, the PDCP component 198 may be configured to send a PDCP status report for the plurality of packets, wherein the PDCP status report indicates a NACK for each packet starting with the first lost packet.

[0033] As a transmitter, UE 104 or base station 102 or 180 may transmit a plurality of packets based on a first ROHC context and may receive RLC ACKs for packets from the plurality of packets that were successfully received based on the first ROHC context. After reestablishing the PDCP entity and resetting to a second ROHC context, PDCP component 198 may be configured to receive a PDCP status report for the plurality of packets, the PDCP status report indicating a NACK for each packet starting with the first lost packet. In some examples, the PDCP status report may indicate a NACK for a packet for which the transmitter previously received an RLC ACK. PDCP component 198 may be configured to send a retransmission of each packet starting with the first lost packet based on the second ROHC context.

[0034] The wireless communication system (also referred to as a wireless wide area network (WWAN)) includes a base station 102, a UE 104, an evolved packet core (EPC) 160, and another core network 190 (e.g., a 5G core (5GC)). The base station 102 may include a macro cell (a high-power cellular base station) and / or a small cell (a low-power cellular base station). A macro cell includes a base station. A small cell includes a femto cell, a pico cell, and a micro cell.

[0035] A base station 102 configured for 4G LTE (collectively referred to as the Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN)) can interface with the EPC 160 via a first backhaul link 132 (e.g., an S1 interface). A base station 102 configured for 5G NR (collectively referred to as the Next Generation RAN (NG-RAN)) can interface with the core network 190 via a second backhaul link 184. The base station 102 can perform, among other functions, one or more of the following: transmission of user data, radio channel encryption and decryption, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection establishment and release, load balancing, distribution of non-access stratum (NAS) messages, NAS node selection, synchronization, radio access network (RAN) sharing, multimedia broadcast multicast service (MBMS), user and device tracking, RAN information management (RIM), paging, positioning, and delivery of warning messages. The base stations 102 can communicate with each other directly or indirectly (eg, through the EPC 160 or the core network 190) over a third backhaul link 134 (eg, an X2 interface). The third backhaul link 134 can be wired or wireless.

[0036] Base stations 102 can communicate wirelessly with UEs 104. Each of base stations 102 can provide communication coverage for a corresponding geographic coverage area 110. There can be overlapping geographic coverage areas 110. For example, a small cell 102′ can have a coverage area 110′ that overlaps with the coverage area 110 of one or more macro base stations 102. A network that includes both small cells and macro cells can be referred to as a heterogeneous network. A heterogeneous network can also include home evolved Node Bs (eNBs) (HeNBs), which can provide services to a restricted group called a closed subscriber group (CSG). The communication link 120 between base station 102 and UE 104 can include uplink (UL) (also known as reverse link) transmissions from UE 104 to base station 102 and / or downlink (DL) (also known as forward link) transmissions from base station 102 to UE 104. The communication link 120 can use multiple-input multiple-output (MIMO) antenna technology, which includes spatial multiplexing, beamforming, and / or transmit diversity. The communication link can be over one or more carriers. Base station 102 / UE 104 can use spectrum with a bandwidth of up to Y MHz (e.g., 5, 10, 15, 20, 100, 400, etc. MHz) per carrier, allocated in carrier aggregation for a total of up to Yx MHz (x component carriers) for transmission in each direction. The carriers may be adjacent to each other or may not be adjacent to each other. The allocation of carriers may be asymmetric with respect to DL and UL (e.g., more or fewer carriers may be allocated for DL ​​compared to UL). Component carriers may include a primary component carrier and one or more secondary component carriers. The primary component carrier may be referred to as a primary cell (PCell), and the secondary component carrier may be referred to as a secondary cell (SCell).

[0037] Some UEs 104 can communicate with each other using device-to-device (D2D) communication links 158. The D2D communication links 158 can use the DL / UL WWAN spectrum. The D2D communication links 158 can use one or more sidelink channels, such as a physical sidelink broadcast channel (PSBCH), a physical sidelink discovery channel (PSDCH), a physical sidelink shared channel (PSSCH), and a physical sidelink control channel (PSCCH). D2D communication can be achieved through various wireless D2D communication systems, such as WiMedia, Bluetooth, ZigBee, Wi-Fi based on the Institute of Electrical and Electronics Engineers (IEEE) 602.11 standard, LTE, or NR.

[0038] The wireless communication system may also include a Wi-Fi access point (AP) 150 that communicates with a Wi-Fi station (STA) 152 in the 5 GHz unlicensed spectrum via a communication link 154. When communicating in the unlicensed spectrum, the STA 152 / AP 150 may perform a clear channel assessment (CCA) to determine whether the channel is available before communicating.

[0039] The small cell 102' can operate in licensed and / or unlicensed spectrum. When operating in the unlicensed spectrum, the small cell 102' can employ NR and use the same 5 GHz unlicensed spectrum as used by the Wi-Fi AP 150. The small cell 102' employing NR in the unlicensed spectrum can improve coverage and / or increase capacity of the access network.

[0040] Base station 102 (whether a small cell 102' or a large cell (e.g., a macro base station)) may include and / or be referred to as an eNB, gNodeB (gNB), or another type of base station. Some base stations, such as gNB 180, may operate in the traditional sub-6 GHz spectrum, in millimeter wave (mmW) frequencies, and / or near-mmW frequencies to communicate with UE 104. When gNB 180 operates in mmW or near-mmW frequencies, gNB 180 may be referred to as a mmW base station. Extremely high frequency (EHF) is a portion of the RF spectrum in the electromagnetic spectrum. EHF has a range of 30 GHz to 300 GHz and has a wavelength between 1 mm and 10 mm. Radio waves in this frequency band may be referred to as millimeter waves. Near-mmW may extend down to frequencies of 3 GHz, with a wavelength of 100 mm. The super high frequency (SHF) band extends between 3 GHz and 30 GHz and is also referred to as centimeter waves. Communications using mmW / near-mmW radio frequency (RF) bands (e.g., 3 GHz–300 GHz) have extremely high path loss and short range. The mmW base station 180 can utilize beamforming 182 with the UE 104 to compensate for the extremely high path loss and short range. The base station 180 and the UE 104 can each include multiple antennas (such as antenna elements, antenna panels, and / or antenna arrays) to facilitate beamforming.

[0041] Base station 180 may transmit beamformed signals in one or more transmit directions 182′ to UE 104. UE 104 may receive beamformed signals from base station 180 in one or more receive directions 182″. UE 104 may also transmit beamformed signals in one or more transmit directions to base station 180. Base station 180 may receive beamformed signals in one or more receive directions from UE 104. Base station 180 / UE 104 may perform beam training to determine optimal receive and transmit directions for each of base station 180 / UE 104. The transmit direction and receive direction for base station 180 may be the same or different. The transmit direction and receive direction for UE 104 may be the same or different.

[0042] EPC 160 may include a Mobility Management Entity (MME) 162, other MMEs 164, a Serving Gateway 166, a Multimedia Broadcast Multicast Service (MBMS) Gateway 168, a Broadcast Multicast Service Center (BM-SC) 170, and a Packet Data Network (PDN) Gateway 172. MME 162 may communicate with a Home Subscriber Server (HSS) 174. MME 162 is a control node that handles signaling between UE 104 and EPC 160. Generally, MME 162 provides bearer and connection management. All user Internet Protocol (IP) packets are transferred through Serving Gateway 166, which itself is connected to PDN Gateway 172. PDN Gateway 172 provides IP address allocation and other functions to UEs. PDN Gateway 172 and BM-SC 170 are connected to IP Services 176. IP Services 176 may include the Internet, an intranet, an IP Multimedia Subsystem (IMS), PS streaming services, and / or other IP services. The BM-SC 170 can provide functionality for MBMS user service provisioning and delivery. The BM-SC 170 can serve as the entry point for content providers' MBMS transmissions, can be used to authorize and initiate MBMS bearer services within a public land mobile network (PLMN), and can be used to schedule MBMS transmissions. The MBMS gateway 168 can be used to distribute MBMS services to base stations 102 belonging to a multicast broadcast single frequency network (MBSFN) area broadcasting a specific service, and can be responsible for session management (start / stop) and collecting billing information related to eMBMS.

[0043] The core network 190 may include an access and mobility management function (AMF) 192, other AMFs 193, a session management function (SMF) 194, and a user plane function (UPF) 195. The AMF 192 may communicate with a unified data management unit (UDM) 196. The AMF 192 is a control node that handles signaling between the UE 104 and the core network 190. Typically, the AMF 192 provides QoS flow and session management. All user Internet Protocol (IP) packets are transported through the UPF 195. The UPF 195 provides IP address allocation and other functions for the UE. The UPF 195 is connected to the IP services 197. The IP services 197 may include the Internet, an intranet, an IP multimedia subsystem (IMS), packet switched (PS) stream (PSS) services, and / or other IP services.

[0044] A base station may include and / or be referred to as a gNB, Node B, eNB, access point, base transceiver station, radio base station, radio transceiver, transceiver functional unit, basic service set (BSS), extended service set (ESS), transmit reception point (TRP), or some other appropriate terminology. Base station 102 provides an access point to EPC 160 or core network 190 for UE 104. Examples of UE 104 include a cellular phone, a smartphone, a Session Initiation Protocol (SIP) phone, a laptop, a personal digital assistant (PDA), a satellite radio unit, a global positioning system, a multimedia device, a video device, a digital audio player (e.g., an MP3 player), a camera, a game console, a tablet, a smart device, a wearable device, a vehicle, an electric meter, a gas pump, a large or small kitchen appliance, a healthcare device, an implant, a sensor / actuator, a display, or any other similarly functional device. Some of UE 104 may be referred to as IoT devices (e.g., a parking meter, a gas pump, an oven, a vehicle, a heart monitor, etc.). UE 104 may also be referred to as a station, a mobile station, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communication device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a user agent, a mobile client, a client, or some other appropriate terminology.

[0045] Figure 2A is a diagram 200 illustrating an example of a first subframe within a 5G / NR frame structure. Figure 2B is a diagram 230 showing an example of DL channels within a 5G / NR subframe. Figure 2C is a diagram 250 illustrating an example of a second subframe within a 5G / NR frame structure. Figure 2Dis a diagram 280 showing an example of an UL channel within a 5G / NR subframe. The 5G / NR frame structure can be frequency division duplex (FDD) (wherein, for a particular set of subcarriers (carrier system bandwidth), a subframe within that subcarrier set is dedicated to either DL or UL), or can be time division duplex (TDD) (wherein, for a particular set of subcarriers (carrier system bandwidth), a subframe within that subcarrier set is dedicated to both DL and UL). Figure 2A 、 2C In the example provided, the 5G / NR frame structure is assumed to be TDD, where subframe 4 is configured with slot format 28 (most of which are DL), where D is DL, U is UL, and X is flexible between DL / UL, and subframe 3 is configured with slot format 34 (most of which are UL). Although subframes 3 and 4 are shown as having slot formats 34 and 28, respectively, any particular subframe can be configured with any of the various available slot formats 0-61. Slot formats 0 and 1 are full DL and full UL, respectively. Other slot formats 2-61 include a mix of DL, UL and flexible symbols. The UE is configured to have a slot format (dynamically configured by DL control information (DCI) or semi-statically / statically configured by radio resource control (RRC) signaling) via a received slot format indicator (SFI). It should be noted that the following description also applies to the 5G / NR frame structure as TDD.

[0046] Other wireless communication technologies may have different frame structures and / or different channels. A frame (10ms) may be divided into 10 equally sized subframes (1ms). Each subframe may include one or more time slots. A subframe may also include mini-slots, which may include 7, 4, or 2 symbols. Each time slot may include 7 or 14 symbols, depending on the time slot configuration. For time slot configuration 0, each time slot may include 14 symbols, while for time slot configuration 1, each time slot may include 7 symbols. The symbols on the DL may be cyclic prefix (CP) OFDM (CP-OFDM) symbols. The symbols on the UL may be CP-OFDM symbols (for high throughput scenarios) or discrete Fourier transform (DFT) spread OFDM (DFT-s-OFDM) symbols (also known as single carrier frequency division multiple access (SC-FDMA) symbols) (for power-limited scenarios; limited to single stream transmission). The number of time slots within a subframe may be based on the time slot configuration and numerology. For slot configuration 0, different digital schemes μ0 to 5 allow 1, 2, 4, 8, 16, and 32 slots per subframe, respectively. For slot configuration 1, different digital schemes 0 to 2 allow 2, 4, and 8 slots per subframe, respectively. Accordingly, for slot configuration 0 and digital scheme μ, there are 14 symbols / slot and 2 μtime slots / subframes. The subcarrier spacing and symbol length / duration are functions of the digital scheme. The subcarrier spacing can be equal to 2 μ *15kHz, where μ is the digital scheme 0 to 5. Thus, digital scheme μ=0 has a subcarrier spacing of 15kHz, and digital scheme μ=5 has a subcarrier spacing of 480kHz. The symbol length / duration is inversely related to the subcarrier spacing. Figures 2A-2D An example is provided for slot configuration 0 with 14 symbols per slot and a digital scheme μ = 2 with 4 slots per subframe. The slot duration is 0.25 ms, the subcarrier spacing is 60 kHz, and the symbol duration is approximately 16.67 μs.

[0047] The resource grid can be used to represent the frame structure. Each time slot includes a resource block (RB) (also known as a physical RB (PRB)), which includes 12 consecutive subcarriers. The resource grid is divided into multiple resource elements (REs). The number of bits carried by each RE depends on the modulation scheme.

[0048] like Figure 2A As shown in , some of the REs carry reference (pilot) signals (RS) for the UE. The RS may include a demodulation RS (DM-RS) for channel estimation at the UE (indicated as R for a specific configuration). x , where 100x is the port number, but other DM-RS configurations are possible) and channel state information reference signal (CSI-RS). RS may also include beam measurement RS (BRS), beam refinement RS (BRRS), and phase tracking RS (PT-RS).

[0049] Figure 2BExamples of various DL channels within a subframe of a frame are shown. The physical downlink control channel (PDCCH) carries DCI within one or more control channel elements (CCEs), each CCE includes nine RE groups (REGs), and each REG includes four consecutive REs in one OFDM symbol. The primary synchronization signal (PSS) can be within symbol 2 of a specific subframe of the frame. The PSS is used by UE104 to determine the subframe / symbol timing and the physical layer identification. The secondary synchronization signal (SSS) can be within symbol 4 of a specific subframe of the frame. The SSS is used by the UE to determine the physical layer cell identification group number and the radio frame timing. Based on the physical layer identification and the physical layer cell identification group number, the UE can determine the physical cell identifier (PCI). Based on the PCI, the UE can determine the position of the above-mentioned DM-RS. The physical broadcast channel (PBCH) (which carries the master information block (MIB)) can be logically grouped with the PSS and SSS to form a synchronization signal (SS) / PBCH block. The MIB provides the number of RBs in the system bandwidth and the system frame number (SFN). The Physical Downlink Shared Channel (PDSCH) carries user data, broadcast system information (eg, System Information Block (SIB)) that is not transmitted through the PBCH, and paging messages.

[0050] like Figure 2C As shown in , some of the REs carry DM-RSs for channel estimation at the base station (indicated as R for one specific configuration, but other DM-RS configurations are possible). The UE may send DM-RSs for the physical uplink control channel (PUCCH) and DM-RSs for the physical uplink shared channel (PUSCH). The PUSCH DM-RS may be sent in the first one or two symbols of the PUSCH. In different configurations, the PUCCH DM-RS may be sent depending on whether a short PUCCH or a long PUCCH is sent and depending on the specific PUCCH format used. The UE may send a sounding reference signal (SRS). The SRS may be sent in the last symbol of the subframe. The SRS may have a comb structure, and the UE may send the SRS on one of the combs. The SRS may be used by the base station for channel quality estimation to enable frequency-dependent scheduling on the UL.

[0051] Figure 2D Examples of various UL channels within a subframe of a frame are shown. The PUCCH may be positioned as indicated in one configuration. The PUCCH carries uplink control information (UCI), such as scheduling requests, channel quality indicator (CQI), precoding matrix indicator (PMI), rank indicator (RI), and hybrid automatic repeat request (HARQ) ACK / NACK feedback. The PUSCH carries data and may additionally be used to carry buffer status reports (BSRs), power headroom reports (PHRs), and / or UCI.

[0052] Figure 3 3 is a block diagram of a base station 310 in an access network communicating with a UE 350. In the DL, IP packets from the EPC 160 may be provided to the controller / processor 375. The controller / processor 375 implements layer 3 and layer 2 functions. Layer 3 includes the radio resource control (RRC) layer, and layer 2 includes the service data adaptation protocol (SDAP) layer, the packet data convergence protocol (PDCP) layer, the radio link control (RLC) layer, and the medium access control (MAC) layer. The controller / processor 375 provides: RRC layer functions associated with the following: broadcast of system information (e.g., MIB, SIB), RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), inter-radio access technology (RAT) mobility, and measurement configuration for UE measurement reporting; PDCP layer functions associated with the following: header compression / decompression, security (ciphering, deciphering, integrity protection, integrity verification), and handover support functions; RLC layer functions associated with the following: transmission of upper layer packet data units (PDUs), error correction through ARQ, concatenation, segmentation and reassembly of RLC service data units (SDUs), resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functions associated with the following: mapping between logical channels and transport channels, multiplexing of MAC SDUs onto transport blocks (TBs), demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction through HARQ, priority handling, and logical channel prioritization.

[0053] The transmit (TX) processor 316 and receive (RX) processor 370 implement layer 1 functions associated with various signal processing functions. Layer 1, including the physical (PHY) layer, may include error detection for the transport channel, forward error correction (FEC) encoding / decoding for the transport channel, interleaving, rate matching, mapping onto the physical channel, modulation / demodulation of the physical channel, and MIMO antenna processing. The TX processor 316 handles the mapping to the signal constellation based on various modulation schemes (e.g., binary phase shift keying (BPSK), quadrature phase shift keying (QPSK), M-phase shift keying (M-PSK), M-order quadrature amplitude modulation (M-QAM)). The coded and modulated symbols can then be divided into parallel streams. Each stream can then be mapped to an OFDM subcarrier, multiplexed with a reference signal (e.g., a pilot) in the time and / or frequency domain, and then combined using an inverse fast Fourier transform (IFFT) to produce a physical channel carrying a time-domain OFDM symbol stream. The OFDM stream is spatially precoded to generate multiple spatial streams. Channel estimates from a channel estimator 374 may be used to determine the coding and modulation schemes and for spatial processing. Channel estimates may be derived from a reference signal and / or channel condition feedback transmitted by the UE 350. Each spatial stream is then provided to a different antenna 320 via a separate transmitter 318TX. Each transmitter 318TX may modulate an RF carrier with a corresponding spatial stream for transmission.

[0054] At the UE 350, each receiver 354RX receives a signal via its corresponding antenna 352. Each receiver 354RX recovers the information modulated onto the RF carrier and provides the information to a receive (RX) processor 356. The TX processor 368 and the RX processor 356 implement layer 1 functions associated with various signal processing functions. The RX processor 356 can perform spatial processing on the information to recover any spatial streams destined for the UE 350. If multiple spatial streams are destined for the UE 350, the RX processor 356 can combine them into a single OFDM symbol stream. The RX processor 356 then uses a fast Fourier transform (FFT) to convert the OFDM symbol stream from the time domain to the frequency domain. The frequency domain signal includes a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, as well as the reference signal, are recovered and demodulated by determining the most likely signal constellation point transmitted by the base station 310. These soft decisions can be based on channel estimates calculated by the channel estimator 358. The soft decisions are then decoded and deinterleaved to recover the data and control signals originally sent on the physical channel by base station 310. The data and control signals are then provided to controller / processor 359, which implements layer 3 and layer 2 functionality.

[0055] The controller / processor 359 may be associated with a memory 360 that stores program codes and data. The memory 360 may be referred to as a computer-readable medium. In the UL, the controller / processor 359 provides demultiplexing between transport and logical channels, packet reassembly, decryption, header decompression, and control signal processing to recover IP packets from the EPC 160. The controller / processor 359 is also responsible for error detection using ACK and / or NACK protocols to support HARQ operations.

[0056] Similar to the functions described in conjunction with DL transmissions performed by the base station 310, the controller / processor 359 provides: RRC layer functions associated with: system information (e.g., MIB, SIB) acquisition, RRC connection, and measurement reporting; PDCP layer functions associated with: header compression / decompression and security (encryption, decryption, integrity protection, integrity verification); RLC layer functions associated with: transmission of upper layer PDUs, error correction through ARQ, concatenation, segmentation and reassembly of RLC SDUs, resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functions associated with: mapping between logical channels and transport channels, multiplexing of MAC SDUs onto TBs, demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction through HARQ, priority handling, and logical channel prioritization.

[0057] Channel estimates derived by the channel estimator 358 from a reference signal or feedback transmitted by the base station 310 may be used by the TX processor 368 to select an appropriate coding and modulation scheme, and to facilitate spatial processing. The spatial streams generated by the TX processor 368 may be provided via separate transmitters 354TX to different antennas 352. Each transmitter 354TX may modulate an RF carrier with a corresponding spatial stream for transmission.

[0058] At the base station 310, the UL transmission is processed in a manner similar to that described in conjunction with the receiver functionality at the UE 350. Each receiver 318RX receives a signal through its respective antenna 320. Each receiver 318RX recovers information modulated onto an RF carrier and provides the information to an RX processor 370.

[0059] The controller / processor 375 may be associated with a memory 376 that stores program codes and data. The memory 376 may be referred to as a computer-readable medium. In the UL, the controller / processor 375 provides demultiplexing between transport and logical channels, packet reassembly, decryption, header decompression, and control signal processing to recover IP packets from the UE 350. The IP packets from the controller / processor 375 may be provided to the EPC 160. The controller / processor 375 is also responsible for supporting HARQ operations using error detection using ACK and / or NACK protocols.

[0060] At least one of the TX processor 368, the RX processor 356, and the controller / processor 359 may be configured to perform operations related to Figure 1 At least one of the TX processor 316, the RX processor 370, and the controller / processor 375 may be configured to perform various aspects related to the PDCP component 1198. Figure 1 Various aspects related to the PDCP component 198.

[0061] In some networks, the radio link control (RLC) layer can perform framing of RLC service data units (SDUs) to fit the SDUs into the size indicated by the lower medium access control (MAC) layer. The RLC transmitter can segment the RLC SDUs to construct RLC protocol data units (PDUs), and the RLC receiver can reassemble the RLC PDUs to reconstruct the RLC SDUs. These RLC functions can be performed by an RLC entity, and an RLC entity can be established when a radio bearer is established and removed when the associated radio bearer is released. When the RLC entity is established, it can be configured in one of at least three operating modes: transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM). In RLC TM, the RLC TM entity in the RLC can not add any overhead to upper layer SDUs, and the RLC TM entity can send SDUs from upper layers to the MAC layer. In RLC UM, the RLC UM entity can be used for the transmission of delay-sensitive packets (such as VoIP packets or audio / video streams). Under RLC AM, the RLC AM entity can be used for both user plane and control plane packets and can have PDCP as an upper layer. The SDUs arriving at the RLC AM entity can be protected by security. In some examples, RLC AM can support HARQ feedback mechanisms to retransmit lost PDUs, and the RLC AM entity can also support segmentation.

[0062] When establishing a radio bearer with an RLC AM entity or an RLC UM entity, the RLC AM radio bearer and / or the RLC UM radio bearer can be configured to support Robust Header Compression (ROHC), which can be used to compress the headers of IP packets. ROHC can be associated with the Packet Data Convergence Protocol (PDCP), wherein PDCP can provide the ROHC with data to be compressed / decompressed and process the output data. In addition, ROHC can include various operating modes, such as a unidirectional mode (U mode), a bidirectional optimistic mode (O mode), and / or a bidirectional reliable mode (R mode). For example, in U mode, packets can be sent in one direction (e.g., from a compressor to a decompressor). O mode can be similar to U mode, but the decompressor can use a feedback channel to send error recovery requests (e.g., for decompression failures) and / or acknowledgments (e.g., for successful context updates). In R mode, the compressor and decompressor contexts can be synchronized, wherein the compressor can repeatedly send context update packets until feedback (e.g., acknowledgment) is received from the decompressor. A compressor can have different compressor states, such as initialization and refresh (IR) states, first-order states, and second-order states. For ROHC, information related to past packets can be maintained in a context, and this context can then be used by the compressor or decompressor to compress and / or decompress subsequent packets. If there is an inconsistency between the context of the compressor and decompressor, decompression may fail. In some examples, ROHC compression can start in the IR state, where an IR packet can be sent to initialize a new context at the decompressor. The IR packet can be a packet with a complete header.

[0063] During a handover procedure (in which the UE switches its connection from one base station to another) and / or during a radio link failure (RLF) re-establishment, the transmitting entity and / or receiving entity of the UE / base station may perform PDCP re-establishment. In some examples, one or more parameters associated with ROHC during PDCP re-establishment may be configured by system parameters (such as parameters related to whether the ROHC context continues between handovers or is reset after a handover). For example, the network may configure a parameter (e.g., a DRB-ContinueROHC parameter) that enables the receiver and / or transmitter to continue using the ROHC context. In other examples, the parameter may indicate that the ROHC context used by the UE with the previous base station (e.g., before the handover) or before the RLF may continue to be used by the UE after PDCP re-establishment. On the other hand, if the network does not configure the parameter or does not enable the parameter for the UE, the ROHC context may be reset after a handover or RLF. For example, after PDCP re-establishment and in an uplink transmission where a continuous ROHC context is not configured (or enabled), the UE may reset the ROHC context and start in IR state in U mode. This means that the UE may start sending packets (e.g., PDUs) with uncompressed headers, and then the UE may start retransmitting packets that have not been acknowledged by RLC (e.g., RLC-unacknowledged PDUs). The UE may be configured to perform ROHC again on these retransmitted packets using the new ROHC context after the reset. In other examples, after PDCP reestablishment and in downlink transmission without a continuous ROHC context configured (or enabled), the UE may have stored some SDUs waiting for reordering. The UE may start performing ROHC header decompression on the stored SDUs, then perform a ROHC reset, and the UE may start in the No Context (NC) state in U mode. Thereafter, any packets received by the UE (e.g., PDCP packets) may be decompressed based on the new ROHC context that has been reset.

[0064] As an example, the overall process for ROHC during PDCP reestablishment may include the following. First, the receiver (e.g., a receiving PDCP entity) may decompress stored packets (e.g., stored PDCP SDUs). Then, both the transmitter (e.g., a transmitting PDCP entity) and the receiver may reset the ROHC context. Then, after performing ROHC according to the new ROHC context, the transmitter may retransmit packets starting from the first RLC unacknowledged packet. In addition, the retransmitted packets may also depend on the PDCP status report sent by the receiver. ROHC compression may be performed on each RLC unacknowledged packet in the RLC unacknowledged packets. After receiving the retransmissions, the receiver may discard the duplicate retransmissions and perform ROHC decompression on the remaining retransmissions (e.g., non-duplicate retransmissions).

[0065] Figure 4 FIG400 is a diagram illustrating an example of a PDCP architecture between a transmitting PDCP entity 402 (e.g., transmitter side) and a receiving PDCP entity 404 (e.g., receiver side). A UE and / or a base station may be associated with both the transmitting PDCP entity 402 and the receiving PDCP entity 404. In one example, Figure 4 As shown, packets (e.g., data blocks) entering the transmitting PDCP entity 402 may first undergo sequence numbering, wherein the transmitting PDCP entity 402 may add a sequence number (SN) to each incoming packet. The receiving PDCP entity 404 may then use the packet's SN to identify whether one or more packets sent by the transmitting PDCP entity 402 are complete, in the correct order, and / or lost, etc. After sequence numbering, the packets may undergo header compression. In some examples, header compression may be applied to IP packet data but not to signaling messages. The transmitting PDCP entity 402 may then apply integrity protection to the compressed packets (e.g., packets associated with a PDCP SDU) and / or encrypt the compressed packets. The transmitting PDCP entity 402 may then add a PDCP header to the compressed packets, and the transmitting PDCP entity 402 may send the compressed packets with the PDCP header to the receiving PDCP entity 404 (e.g., via a Uu radio interface).

[0066] After the receiving PDCP entity 404 receives the compressed packet with the PDCP header from the transmitting PDCP entity 402, the receiving PDCP entity 404 may remove the PDCP header from the packet, decrypt the packet, and / or verify the integrity of the packet. As shown at 406, the receiving PDCP entity 404 may reorder the packets (e.g., based on their SNs) and discard any duplicate packets, and the remaining packets may then undergo header decompression.

[0067] Figure 5 is shown for example in conjunction with Figure 45. A communication flow 500 illustrates an example of a data retransmission process for a PDCP architecture. In one example, at 506, a transmitting PDCP entity 502 may use a first ROHC context to transmit ROHC compressed PDCP packets P1, P2, P3, P4, P5, and P6 (e.g., PDCP SDUs) to a receiving PDCP entity 504. However, the receiving PDCP entity 504 may receive PDCP packets P1, P2, P4, and P6, but may not receive PDCP packets P3 and P5, which may have been lost during the transmission at 506 (e.g., during a handover process). As shown at 507, the receiving PDCP entity 504 may store the received PDCP packets P1, P2, P4, and P6 in the receiving PDCP entity 504. Then, at 508, the receiving PDCP entity 504 may initiate a PDCP re-establishment procedure.

[0068] At 510, after initiating the PDCP re-establishment procedure, the receiving PDCP entity 504 may first decompress the stored PDCP packets (such as PDCP packets P1, P2, P4, and P6). Since PDCP packets P3 and P5 are not received by the receiving PDCP entity 504, PDCP packets P3 and P5 may appear to be lost to the ROHC decompressor of the receiving PDCP entity 504. The ROHC decompressor can successfully decompress PDCP packets even if a few PDCP packets are lost. However, as the number of lost PDCP packets becomes higher, decompression may become more likely to fail.

[0069] At 512, after the receiving PDCP entity 504 decompresses the stored PDCP packets, both the transmitting PDCP entity 502 and the receiving PDCP entity 504 may reset their ROHC contexts. At 513, the receiving PDCP entity 504 may send a PDCP status report to the transmitting PDCP entity 502. Because each PDCP packet may be associated with a SN, the PDCP status report may include an indication of successfully delivered PDCP packets, and the PDCP status report may also indicate the SN of the first lost PDCP packet (e.g., the first RLC unacknowledged packet, PDCP packet P3) and a bitmap indicating subsequent SNs of PDCP packets (e.g., PDCP packets P4 and P6) that were successfully received after the first lost PDCP packet (e.g., PDCP packet P3).

[0070] At 514, in response to the PDCP status report, the transmitting PDCP entity 502 may retransmit the PDCP packets not acknowledged from the first RLC (e.g., the first lost packet P3) after header compression using the new ROHC context (e.g., the second ROHC context) to the receiving PDCP entity 504. For example, at 514, the transmitting PDCP entity 502 may retransmit PDCP packets P3, P4, P5, and P6 to the receiving PDCP entity after applying header compression to the PDCP packets P3, P4, P5, and P6 using the new ROHC context.

[0071] Since the receiving PDCP entity 504 received PDCP packets P4 and P6 before the PDCP re-establishment at 508, the receiving PDCP entity 504 may regard the PDCP packets P4 and P6 received in the retransmission at 514 as duplicates. Therefore, as shown at 516, the receiving PDCP entity 504 may automatically discard the duplicate PDCP packets P4 and P6.

[0072] At 518, the receiving PDCP entity 504 may decompress the remaining PDCP packets (e.g., PDCP packets P3 and P5) via the ROHC decompressor. In some examples, as shown at 520, after the receiving PDCP entity 504 decompresses the remaining PDCP packets, the retransmitted PDCP packets P4 and P6 at 514 may appear as losses to the ROHC decompressor because they are discarded as duplicates at 516.

[0073] like Figure 5 As shown, there may be two sets of PDCP packets at the receiving PDCP entity 504 that may appear as losses to the ROHC decompressor, one of which may occur before the ROHC context reset at 512 (e.g., PDCP packets P3 and P5 - these lost PDCP packets may be referred to as a PDCP hole), and the other loss may occur during the duplicate PDCP packet discard process after the ROHC context reset or PDCP re-establishment (e.g., discarding duplicate PDCP packets P4 and P6 at 516). In some examples, since the duplicate PDCP packets discarded after PDCP re-establishment may appear as losses to the ROHC decompressor, it may affect the efficiency of the ROHC compression performed by the ROHC decompressor. In other examples, after PDCP re-establishment, since both the transmitting PDCP entity 502 and the receiving PDCP entity 504 may be reset, both may be sending IR packets (e.g., packets with complete headers). Although IR packets may still be decoded if the previous packet is lost, the ROHC may lose its context if the number of duplicate packets (e.g., P4, P6) exceeds the number of IR packets.

[0074] In other words, during the uplink PDCP re - establishment for a ROHC bearer (such as a ROHC bearer enabled with profile 6 (e.g., ROHC profile 0x6)), the transmitting PDCP entity may re - transmit PDCP packets not received by the receiving PDCP entity, starting from the first lost PDCP packet with sequence number (SN) X up to SN(X + Y), where Y can be a relatively large number. For some networks, during PDCP entity re - establishment, the ROHC processing at the receiving PDCP entity may be reset, and the transmitting PDCP entity may compress the re - transmitted PDCP packets, starting from the re - transmitted PDCP packet with SN X (e.g., using profile 6). In some examples, the first few packets in the re - transmitted PDCP packets may be ROHC IR packets, e.g., PDCP packets SN X to X+num_ir (the number of IR packets), and the remaining packets of the re - transmitted PDCP packets may be compressed (CO) packets. In such an example, the receiving PDCP entity may send a PDCP status report with a first missing count (FMC) equal to X + Z, where num_ir may be less than Z, and Z may be less than Y (e.g., num_ir < Z < Y), which means that any PDCP PDU with SN less than X + Z (e.g., SN < X + Z) may be a duplicate PDU, and this duplicate PDU may be discarded in PDCP. Thus, for new packets after PDCP re - establishment, decompression may fail because the ROHC decompressor processing is reset and the received packets are not IR packets. In one example, the transmitting PDCP entity may overcome this problem by resetting the ROHC processing when receiving a PDCP status report that discards too many IR packets (e.g., discarding a number of IR packets higher than a threshold), and compressing the remaining PDCP re - transmissions and new PDCP transmissions (PDCP NEWTX) again using profile 6. However, since the number of packets to be compressed may be large, this may result in a long processing time for the transmitting entity.

[0075] In one aspect of the present disclosure, to avoid or reduce the above scenarios, during the uplink PDCP re - establishment of a ROHC bearer with profile 6 enabled, the transmitting PDCP entity may reset the ROHC processing and compress PDCP packets with re - transmissions having SN X to SN(X + Y) using profile 0 (e.g., ROHC profile 0x0 or 0x0000) instead of profile 6, while using profile 6 to compress new PDCP packets. Thus, the first num_ir packets for both PDCP re - transmissions and new transmissions are IR packets. Then, the receiving PDCP entity may send a PDCP status report with an FMC equal to X + Z to the transmitting PDCP entity, where Z may be less than Y (e.g., Z < Y) because the receiving PDCP entity does not acknowledge PDUs not sent by the transmitting PDCP entity. In response, the transmitting PDCP entity may discard the acknowledged PDUs in the PDCP status report and reset the ROHC compression processing, and the transmitting PDCP entity may use profile 0 to compress PDCP re - transmissions starting from (X + Z) to the last PDCP re - transmission. In some examples, the first few packets may be IR packets and may be delivered by PDCP to the ROHC decompressor of the receiving PDCP entity because they are not duplicate packets. Thus, in PDCP packet re - transmissions, the number of packets to be compressed by the transmitting PDCP entity may be limited, which may be much less than processing PDCP re - transmissions with new transmissions. Additionally, the compression of profile 0 may be much faster than the compression of profile 6. Although the examples are shown using ROHC profile 6, the aspects presented herein may also be applied to other ROHC profiles, such as ROHC profiles 1, 2, 3, 4, 5, etc.

[0076] In some examples, the receiving PDCP entity may not send a PDCP status report to the transmitting PDCP entity. In such examples, when PDCP re - establishment is performed between the receiving PDCP entity and the transmitting PDCP entity, the transmitting PDCP entity may be configured to compress packets using ROHC profile 0 such that even if the receiving PDCP entity discards duplicate packets, the receiving PDCP entity may not have a problem. For example, when the transmitting PDCP entity re - transmits PDCP packets with SN X to SN X + Y to the receiving PDCP entity, the first lost packet at the receiving PDCP entity may be X + Z (e.g., Z < Y), even if the receiving PDCP entity has not sent any PDCP status reports. Then, the receiving PDCP entity may start decompressing PDCP packets starting from SN X + Z and onwards. Thus, if ROHC profile 0 is used, there may be no decompression loss at the receiving PDCP entity.

[0077] Based on the above, various aspects presented herein can improve the efficiency of ROHC operations, for example, during PDCP reestablishment for RLC AM. Various aspects presented herein can enable a receiving PDCP entity to discard duplicate PDCP packets after decompression, such that the discarded duplicate PDCP packets by the receiving PDCP entity do not appear as a loss to the ROHC decompressor. In one aspect of the present disclosure, Figure 6 As shown in diagram 600 of FIGURE 6, after PDCP is reestablished between a transmitting PDCP entity 602 and a receiving PDCP entity 604, the receiving PDCP entity 604 may discard duplicate PDCP packets after header decompression, such as shown at 606. This may enable processing of duplicate PDCP packets during or after ROHC decompression, and the retransmitted PDCP packets at the receiving PDCP entity 604 may follow the same PDCP packet order (e.g., Figure 5 P3, P4, P5, P6), for example, combined with Figure 5 The discarding of duplicate PDCP packets after ROHC decompression may be configured as a function enabled by the receiving PDCP entity 604 (e.g., during PDCP re-establishment) and disabled by the receiving PDCP entity 604 after PDCP re-establishment. If the function is disabled, duplicate PDCP packets may be discarded before decompression, for example, in conjunction with Figure 4 and 5 Descriptive.

[0078] Figure 7 It is a combination of various aspects according to the present disclosure. Figure 6A communication flow 700 depicts an example of a data retransmission process for a PDCP architecture. In one example, at 706, a transmitting PDCP entity 702 may use a first ROHC context to send ROHC compressed PDCP packets P1, P2, P3, P4, P5, and P6 (e.g., PDCP SDUs) to a receiving PDCP entity 704. However, the receiving PDCP entity 704 may receive PDCP packets P1, P2, P4, and P6, but may not receive PDCP packets P3 and P5, which may have been lost during the transmission at 706 (e.g., during a handover process). As shown at 707, the receiving PDCP entity 704 may store the received PDCP packets P1, P2, P4, and P6 at the receiving PDCP entity 704. In some examples, the receiving PDCP entity 704 may receive one or more PDCP packets based on a first ROHC profile. For example, uplink (UL) PDCP reestablishment may be enabled for a ROHC bearer with profile 6. Thus, the first ROHC profile may be profile 6. Then, at 708, the receiving PDCP entity 704 and / or the transmitting PDCP entity 702 may initiate a PDCP re-establishment procedure.

[0079] After initiating the PDCP re-establishment procedure, the receiving PDCP entity 704 may first decompress the stored PDCP packets (such as PDCP packets P1, P2, P4, and P6) at 710. Since PDCP packets P3 and P5 are not received by the receiving PDCP entity 704, PDCP packets P3 and P5 may appear as a loss to the ROHC decompressor of the receiving PDCP entity 704.

[0080] At 712, after the receiving PDCP entity 704 decompresses the stored PDCP packets, both the transmitting PDCP entity 702 and the receiving PDCP entity 704 may reset their ROHC contexts. At 713, the receiving PDCP entity 704 may send a PDCP status report to the transmitting PDCP entity 702. The PDCP status report may include an indication of successfully delivered PDCP packets, as each PDCP packet may be associated with a SN, and the PDCP status report may also indicate the SN of the first lost PDCP packet (e.g., the first RLC unacknowledged packet, PDCP packet P3) and a bitmap indicating subsequent SNs of PDCP packets (e.g., PDCP packets P4 and P6) that were successfully received after the first lost PDCP packet (e.g., PDCP packet P3).

[0081] At 714, in response to the PDCP status report, the transmitting PDCP entity 702 may retransmit the PDCP packets starting from the first unacknowledged RLC (e.g., the first lost packet P3) after header compression using the new ROHC context (e.g., the second ROHC context) to the receiving PDCP entity 704. For example, at 714, the transmitting PDCP entity 702 may retransmit PDCP packets P3, P4, P5, and P6 to the receiving PDCP entity after applying header compression to the PDCP packets P3, P4, P5, and P6 using the new ROHC context.

[0082] At 716, after receiving the PDCP packet retransmissions from the transmitting PDCP entity 702, the receiving PDCP entity 704 may perform ROHC header decompression (e.g., Figure 6 The decompression at 716 may include decompressing duplicate PDCP packets (eg, PDCP packets P4 and P6).

[0083] At 718, after the receiving PDCP entity decompresses the received retransmitted PDCP packets, the receiving PDCP entity 704 may discard the duplicate PDCP packets. For example, duplicate PDCP packets P4 and P6 may be discarded at 718, e.g. Figure 6 As shown at 606. In one example, the receiving PDCP entity 704 may determine which PDCP packets are duplicates based on the PDCP status report.

[0084] In some examples, a receiving PDCP entity (e.g., a UE or a base station) may be configured with a function / capability to change the order in which duplicate PDCP packets are discarded (e.g., from before decompression to after decompression), for example, during a PDCP re-establishment procedure. For example, if the function / capability is enabled by the receiving PDCP entity, the receiving PDCP entity may discard duplicate PDCP packets after decompression, whereas if the function / capability is disabled by the receiving PDCP entity, the receiving PDCP entity may discard duplicate PDCP packets before decompression. In some examples, the receiving PDCP entity may disable (or restore) the function / capability to change the order in which duplicate PDCP packets are discarded (hereinafter referred to as "change discard order functionality") after one or more triggering events and / or under defined conditions.

[0085] In one example, the receiving PDCP entity may enable the change discard order function during PDCP re-establishment, and the receiving PDCP entity may continue to enable the change discard order function (e.g., discard duplicate PDCP packets after decompression) until the last of the PDCP packets lost before PDCP re-establishment is filled, e.g., when Figure 7 After the last missing PDCP packet is filled, the receiving PDCP entity may be configured to disable the change discard order functionality (ie, duplicate PDCP packets may again be discarded before decompression).

[0086] In another example, if the duplicate PDCP packet is for a PDCP packet received before the PDCP re-establishment (e.g., Figure 7 If the receiving PDCP entity receives duplicate PDCP packets, the receiving PDCP entity may enable the discard order change function. As the receiving PDCP entity may continue to receive duplicate PDCP packets, the receiving PDCP entity may disable the discard order change function if the duplicate PDCP packets no longer contain PDCP packets received before PDCP re-establishment.

[0087] In another example, the receiving PDCP entity may enable the change discard order function within a defined time period (e.g., based on a timer). Once the defined time period is reached, e.g., when the timer expires, the receiving PDCP entity may disable the change discard order function.

[0088] In another example, the receiving PDCP entity may enable the change discard order function until the ROHC decompressor notifies the PDCP receiving entity that it has a valid ROHC context. The receiving PDCP entity may then disable the change discard order function.

[0089] If combined Figure 5 As described, there may be two sets of PDCP packets that may appear to be lost by the ROHC decompressor, where the first loss may occur before the ROHC reset and the second loss may occur after the ROHC reset or PDCP re-establishment. Figure 5After initiating PDCP re-establishment at 508, the receiving PDCP entity 504 can decompress the stored PDCP SDUs at 510 without waiting for the lost PDCP packets P3 and P5 (e.g., PDCP holes) to be filled. These lost PDCP holes may appear as losses to the ROHC decompressor during decompression. In some examples, if some or several PDCP packets are lost, the ROHC decompressor may still be able to successfully decompress the PDCP packets. However, if the number of lost packets exceeds a limit or becomes too high, the ROHC decompressor may lose synchronization with the transmitting PDCP entity.

[0090] In another aspect of the present disclosure, a receiving PDCP entity may improve the efficiency of ROHC decompression performed by a ROHC decompressor, for example, during PDCP reestablishment, by reducing the number of duplicate PDCP packets that may appear as losses to the ROHC decompressor prior to a ROHC context reset (e.g., at 512, 712). In one aspect, the receiving PDCP entity may be configured to not decompress out-of-order PDCP packets (e.g., PDCP packets that are not in consecutive SNs), and the receiving PDCP entity may discard one or more out-of-order PDCP packets. The receiving PDCP entity may then send a PDCP status report to the transmitting PDCP entity to indicate the lost or out-of-order one or more PDCP packets (e.g., PDCP PDUs). For example, the receiving PDCP entity may indicate in the PDCP status report negative acknowledgment (NACK) feedback for each of the lost or out-of-order one or more PDCP packets starting with the first lost PDCP packet. Based on the PDCP status report, the transmitting PDCP entity may retransmit the PDCP packets with NACK feedback using a new ROHC context. In some examples, the transmitting PDCP entity may discard PDCP packets (e.g., PDUs) that have been acknowledged in the PDCP status report after header compression. Thus, if the transmitting PDCP entity is configured to retransmit PDCP packets with NACK feedback, the transmitting PDCP entity may be configured not to discard PDCP packets that have been acknowledged because the receiving PDCP entity may indicate NACK feedback for one or more earlier RLC acknowledged PDCP packets. Thus, all packets may arrive at the receiving PDCP entity, as in conjunction with Figure 5 and 7 shown.

[0091] Figure 8FIG8 is a communication flow 800 illustrating an example of configuring a receiving PDCP entity to not decompress out-of-order PDCP packets and to send a PDCP status report with NACK feedback in accordance with aspects of the present disclosure. In one example, at 806, the transmitting PDCP entity 802 may send ROHC-compressed PDCP packets P1, P2, P3, P4, P5, and P6 (e.g., PDCP SDUs) to the receiving PDCP entity 804. The receiving PDCP entity 804 may receive the PDCP packets P1, P2, P4, and P6, but may not receive PDCP packets P3 and P5. As shown at 807, the receiving PDCP entity 804 may store the received PDCP packets P1, P2, P4, and P6 at the receiving PDCP entity 804. In some examples, the receiving PDCP entity 804 may receive one or more PDCP packets based on a first ROHC profile. For example, uplink (UL) PDCP re-establishment may be enabled for ROHC bearers having ROHC profiles such as profiles 1, 2, 3, 4, 5, 6, etc. Then, at 808, the receiving PDCP entity 804 and / or the transmitting PDCP entity 802 may initiate a PDCP re-establishment procedure.

[0092] At 810, after initiating the PDCP re-establishment procedure, the receiving PDCP entity 704 may decompress the stored PDCP packets that are not out of order (e.g., PDCP packets with consecutive sequence numbers) and may skip decompressing the out-of-order PDCP packets. The receiving PDCP entity 804 may then discard one or more PDCP packets that are out of order. For example, as shown at 810, the receiving PDCP entity 804 may decompress PDCP packets P1 and P2 because they are in order, and the receiving PDCP entity 804 may skip decompressing PDCP packets P4 and P6 because they are out of order (e.g., P3 and P5 are lost), and may discard PDCP packets P4 and P6. Thus, during decompression, no PDCP packets appear to be lost by the ROHC decompressor.

[0093] At 812, after the receiving PDCP entity 804 decompresses the in-order PDCP packets, both the transmitting PDCP entity 802 and the receiving PDCP entity 804 may reset their ROHC contexts.

[0094] At 814, the receiving PDCP entity 804 may send a PDCP status report to the transmitting PDCP entity 802. In some examples, as shown at 816, prior to sending the PDCP status report, the receiving PDCP entity 804 may have sent RLC ACKs for PDCP packets successfully received based on the first ROHC context (e.g., before the ROHC reset at 812) (which may include one or more PDCP packets received after the first lost packet (e.g., PDCP packet P3)). The PDCP status report may utilize NACK feedback to indicate NACKs for one or more PDCP packets that were lost (e.g., discarded, not received, etc.) starting from the first lost PDCP packet. For example, because the receiving PDCP entity 804 did not receive PDCP packets P3 and P5, and PDCP packets P4 and P6 were discarded, the receiving PDCP entity 804 may indicate PDCP packets P3, P4, P5, and P6 as NACKs in the PDCP status report.

[0095] At 818, in response to the PDCP status report, the transmitting PDCP entity 802 may retransmit the PDCP packets with NACK feedback in the PDCP status report. For example, because the PDCP status report indicates PDCP packets P3, P4, P5, and P6 as NACK, the transmitting PDCP entity 802 may retransmit PDCP packets P3, P4, P5, and P6 after header compression using the new ROHC context. In some examples, because the PDCP status report does not acknowledge receipt of PDCP packets P4 and P6, the receiving PDCP entity 804 may not consider the PDCP packets P4 and P6 received in the retransmission at 818 as duplicates. In some examples, the transmitting PDCP entity 802 may compress the retransmission using the reset ROHC context (e.g., the second ROH context at 812), such as shown at 817. In some examples, the transmitting PDCP entity 802 may compress the retransmission using ROHC profile 0 instead of ROHC profile 6.

[0096] In one case, during uplink PDCP re - establishment of an ROHC bearer with profile 6 enabled, at 817, the transmitting PDCP entity 804 may reset the ROHC processing and compress PDCP packets with re - transmissions having SN X to SN(X + Y) using profile 0 (e.g., ROHC profile 0x0 or 0x0000) instead of profile 6, while using profile 6 to compress new PDCP packets. Thus, the first num_ir packets of both PDCP re - transmissions and new transmissions are IR packets. Then, the receiving PDCP entity 804 may send a PDCP status report with an FMC equal to X + Z to the transmitting PDCP entity 802, where Z may be less than Y (e.g., Z < Y) because the receiving PDCP entity 804 does not acknowledge PDUs not sent by the transmitting PDCP entity 802. In response, the transmitting PDCP entity 802 may discard the PDUs acknowledged in the PDCP status report and reset the ROHC compression processing, and the transmitting PDCP entity 802 may use profile 0 to compress PDCP re - transmissions starting from (X + Z) to the last PDCP re - transmission. In some examples, the first few packets may be IR packets and may be delivered by PDCP to the ROHC decompressor of the receiving PDCP entity 804 because they are not duplicate packets. Thus, in PDCP packet re - transmissions, the number of packets to be compressed by the transmitting PDCP entity 802 may be limited, and this number of packets may be much less than processing PDCP re - transmissions with new transmissions. Additionally, compression with profile 0 may be much faster than compression with profile 6. In other examples, if the receiving PDCP entity ⑧04 does not send a PDCP status report to the transmitting PDCP entity 802 and PDCP re - establishment is performed between the receiving PDCP entity 804 and the transmitting PDCP entity 802, the receiving PDCP entity 804 may be configured to compress packets using ROHC profile 0 such that even if the receiving PDCP entity 804 discards duplicate packets, the receiving PDCP entity 804 may not have a problem. For example, when the transmitting PDCP entity 802 re - transmits PDCP packets with SNX to SN X + Y to the receiving PDCP entity 804, the first lost packet at the receiving PDCP entity 804 may be X + Z (e.g., Z < Y), even if the receiving PDCP entity 804 has not sent any PDCP status report. Then, the receiving PDCP entity 804 may start decompressing PDCP packets from SN X + Z and onwards. Thus, if ROHC profile 0 is used, there may be no decompression loss at the receiving PDCP entity 804.

[0097] At 820, after the receiving PDCP entity 804 receives retransmissions for PDCP packets with NACK feedback (e.g., PDCP packets P3, P4, P5, and P6), the receiving PDCP entity 804 may perform decompression on the retransmitted PDCP packets. Since the retransmitted PDCP packets are not discarded and / or are not out of order, no PDCP packets may appear as a loss to the ROHC decompressor. Therefore, various aspects presented herein may improve the efficiency of ROHC operations.

[0098] Figure 9 900 is a flow chart of a method of wireless communication. The method may be performed by a receiving device or a component of a receiving device (e.g., a receiving PDCP entity 504, 604, 704). In some examples, the receiving device may be a UE or a component of a UE, such as UE 104, 350, apparatus 1002, or a processing system that may include memory 360 and may be the entire UE 350 or a component of UE 350, such as TX processor 368, RX processor 356, and / or controller / processor 359. In other examples, the receiving device may be a base station or a component of base station 102, 180, 310, or a processing system that may include memory 376 and may be the entire base station 310 or a component of base station 310, such as TX processor 316, RX processor 370, and / or controller / processor 375. Optional aspects are shown in dashed lines. The method may enable the receiving device to change the order of processing ROHC header decompression and duplicate PDCP packet discarding, for example, during PDCP reestablishment.

[0099] At 902, the receiving device may re-establish a PDCP entity. The PDCP entity may be re-established during handover or RLF re-establishment, for example, in conjunction with Figure 6 and 7 For example, at 708, the receiving PDCP entity 704 may initiate PDCP reestablishment. The reestablishment of the PDCP entity may be initiated by, for example, Figure 10 The PDCP reestablishment component 1040 of the device 1002 is executed.

[0100] At 904, after the receiving device re-establishes the PDCP entity, the receiving device may reset the ROHC context, for example, in conjunction with Figure 6 and 7 For example, at 712, the receiving PDCP entity 704 may reset the ROHC context. The ROHC context may be reset, for example, by Figure 10 The ROHC reset component 1042 of the device 1002 is executed.

[0101] At 906, after the receiving device resets the ROHC context, the receiving device may receive packet retransmissions with ROHC-based header compression, e.g., in conjunction with Figure 6 and 7 For example, at 714, the receiving PDCP entity 704 may receive a packet retransmission with header compression based on reset ROHC. The reception of the packet retransmission may be performed, for example, by Figure 10 In some examples, the retransmission of the packet can be based on the PDCP status report sent by the receiving device.

[0102] At 908, after receiving the packet retransmission, the receiving device may perform decompression of the packet retransmission, for example in conjunction with Figure 6 and 7 For example, at 716, the receiving PDCP entity 704 may decompress the received PDCP packet retransmission. The decompression of the packet retransmission may be performed, for example, by Figure 10 The decompression component 1046 and / or the receiving component 1030 of the device 1002 are executed.

[0103] At 910, the receiving device may discard duplicate packets after performing decompression of the packet retransmissions, e.g., in conjunction with Figure 6 and 7 For example, at 718, the receiving PDCP entity 704 may discard duplicate PDCP packets. The discarding of duplicate packets may be performed by, for example, Figure 10 The repeated group processing component 1048 of the device 1002 is executed.

[0104] In one example, the receiving device may discard duplicate packets after performing decompression of packet retransmissions until decompressing the last lost packet before re-establishing the PDCP entity, and after decompressing the last lost packet, the receiving device may discard duplicate packets before performing decompression, e.g., in conjunction with Figure 7 Descriptive.

[0105] In another example, if the duplicate packet is a duplicate of a packet received before the PDCP entity is re-established, the receiving device may discard the duplicate packet after performing decompression of the packet retransmission, e.g., in conjunction with Figure 7 Descriptive.

[0106] In another example, if the duplicate packet is a duplicate of a packet received after the PDCP entity is re-established, the receiving device may discard the duplicate packet before performing decompression, for example, in conjunction with Figure 7 Descriptive.

[0107] In another example, the receiving device may discard duplicate packets after performing decompression of packet retransmissions until a timer expires, and after the timer expires, the receiving device may discard duplicate packets before performing decompression, e.g., in conjunction with Figure 7 In another example, the receiving device may discard duplicate packets after performing decompression of packet retransmissions until feedback is received from the ROHC decompressor, and wherein, after the feedback from the ROHC decompressor, the receiving device may discard duplicate packets before performing decompression, e.g., in conjunction with Figure 7 The feedback may indicate to the ROHC decompressor that it has a valid ROHC context.

[0108] Figure 10 FIG1000 is a diagram illustrating an example of a hardware implementation for an apparatus 1002. Apparatus 1002 is a UE and includes a cellular baseband processor 1004 (also referred to as a modem) coupled to a cellular RF transceiver 1022 and one or more subscriber identity module (SIM) cards 1020; an application processor 1006 coupled to a secure digital (SD) card 1008 and a screen 1010; a Bluetooth module 1012; a wireless local area network (WLAN) module 1014; a global positioning system (GPS) module 1016; and a power supply 1018. Cellular baseband processor 1004 communicates with UE 104 and / or BS 102 / 180 via cellular RF transceiver 1022. Cellular baseband processor 1004 may include computer-readable media / memory. The computer-readable media / memory may be non-transitory. Cellular baseband processor 1004 is responsible for general processing, including executing software stored on the computer-readable media / memory. When executed by the cellular baseband processor 1004, the software causes the cellular baseband processor 1004 to perform the various functions described above. The computer-readable medium / memory may also be used to store data manipulated by the cellular baseband processor 1004 when executing the software. The cellular baseband processor 1004 also includes a receiving component 1030, a communication manager 1032, and a transmitting component 1034. The communication manager 1032 includes one or more of the components shown. The components within the communication manager 1032 may be stored in a computer-readable medium / memory and / or configured as hardware within the cellular baseband processor 1004. The cellular baseband processor 1004 may be a component of the UE 350 and may include at least one of the TX processor 368, the RX processor 356, and the controller / processor 359 and / or the memory 360. In one configuration, the apparatus 1002 may be a modem chip and include only the baseband processor 1004, and in another configuration, the apparatus 1002 may be the entire UE (e.g., see Figure 3 350) and includes additional modules of device 1002.

[0109] The communications manager 1032 includes a PDCP re-establishment component 1040 configured to re-establish the PDCP entity, e.g., as described in conjunction with Figure 9 The communication manager 103 further includes a ROHC context reset component 1042, which is configured to reset the ROHC context, for example, in conjunction with Figure 9 904. The communication manager 1032 also includes a retransmission receiving component 1044, which is configured to receive packet retransmissions with ROHC-based header compression, for example, as described in conjunction with Figure 9 906. The communication manager 1032 also includes a decompression component 1046, which is configured to perform decompression of packet retransmissions, for example, as described in conjunction with Figure 9 908. The communication manager 1032 also includes a duplicate packet processing component 1048, which is configured to discard duplicate packets after performing decompression of packet retransmissions, for example, as described in conjunction with Figure 9 The 910 described.

[0110] The apparatus may include performing the above Figure 9 Each block in the flowchart of the algorithm has additional components. Therefore, the above components can be executed by Figure 9 Each block in the flowchart of the process / algorithm may be included in the apparatus, and the apparatus may include one or more of those components. The components may be one or more hardware components specifically configured to perform the process / algorithm, implemented by a processor configured to perform the process / algorithm, stored in a computer-readable medium for implementation by a processor, or some combination thereof.

[0111] In one configuration, the apparatus 1002 (specifically, the cellular baseband processor 1004) includes means for reestablishing a PDCP entity (e.g., a PDCP reestablishment component 1040). The apparatus 1002 includes means for resetting a ROHC context (e.g., a ROHC context reset component 1042). The apparatus 1002 includes means for receiving a packet retransmission with ROHC-based header compression (e.g., a retransmission receiving component 1044 and / or a receiving component 1030). The apparatus 1002 includes means for performing decompression of the packet retransmission (e.g., a decompression component 1046). The apparatus 1002 includes means for discarding duplicate packets after performing decompression of the packet retransmission (e.g., a duplicate packet processing component 1048).

[0112] The aforementioned means may be one or more of the aforementioned components of the apparatus 1002 configured to perform the functions recited by the aforementioned means. As described above, the apparatus 1002 may include a TX processor 368, an RX processor 356, and a controller / processor 359. Thus, in one configuration, the aforementioned means may be the TX processor 368, the RX processor 356, and the controller / processor 359 configured to perform the functions recited by the aforementioned means.

[0113] Figure 11 1 is a flow chart of a method 1100 for wireless communication. The method may be performed by a receiving device or a component of a receiving device (e.g., receiving PDCP entity 804). In some examples, the receiving device may be a UE or a component of a UE, such as UE 104, 350, apparatus 1202, or a processing system that may include memory 360 and may be the entire UE 350 or a component of UE 350, such as TX processor 368, RX processor 356, and / or controller / processor 359. In some examples, the receiving device may be a base station or a component of base station 102, 180, 310, or a processing system that may include memory 376 and may be the entire base station 310 or a component of base station 310, such as TX processor 316, RX processor 370, and / or controller / processor 375. Optional aspects are shown in dashed lines. The method may enable the receiving device to not compress any out-of-order PDCP packets and to send a PDCP status report with NACK feedback for lost and / or out-of-order PDCP packets.

[0114] At 1102, a receiving device may receive a plurality of packets based on a first ROHC context, for example, in conjunction with Figure 8 For example, at 806, the receiving PDCP entity 804 may receive a plurality of PDCP packets from the transmitting PDCP entity 802. The reception of the plurality of packets may be performed, for example, by Figure 12 The packet receiving component 1240 of the device 1202 is executed.

[0115] At 1104, after receiving a plurality of packets based on the first ROHC context, the receiving device may re-establish the PDCP entity, for example, in conjunction with Figure 8 For example, at 808, the receiving PDCP entity may perform PDCP reestablishment. The reestablishment of the PDCP entity may be performed by, for example, Figure 12 The PDCP reestablishment component 1242 of the device 1202 is executed.

[0116] At 1106, after re-establishing the PDCP entity, the receiving device may reset to a second ROHC context, e.g., in conjunction with Figure 8For example, at 812, the receiving PDCP entity 804 may reset the ROHC context to a second ROHC context. The reset of the ROHC context may be performed by, for example, Figure 12 The ROHC context reset component 1244 of the device 1202 is executed.

[0117] At 1110, the receiving device sends a PDCP status report for a plurality of packets, wherein the PDCP status report indicates a NACK for each packet starting from the first lost packet, e.g., in conjunction with Figure 8 For example, at 814, the receiving PDCP entity 804 may send a PDCP status report for a plurality of packets. The transmission of the PDCP status report may be, for example, by Figure 12 The PDCP status reporting component 1246 and / or the sending component 1234 of the device 1202 are executed.

[0118] At 1112, the receiving device receives retransmissions of each packet starting with the first lost packet based on the second ROHC context, e.g., in conjunction with Figure 8 For example, at 818, the receiving PDCP entity 804 may receive a retransmission of each packet starting from the first lost packet based on the second ROHC context. The reception of the retransmission of each packet may be performed, for example, by Figure 12 The receiving component 1230 of the device 1202 is executed.

[0119] At 1114, after receiving the retransmission, the receiving device may perform decompression of the retransmission of each packet starting with the first lost packet, e.g., in conjunction with Figure 8 For example, at 820, the receiving PDCP entity 804 may decompress the received retransmissions. The decompression of the retransmissions of each packet may be performed, for example, by Figure 12 The decompression component 1248 of the device 1202 is executed.

[0120] In one example, the receiving device may not decompress out-of-order packets. For example, the receiving device may avoid decompressing out-of-order packets, or may limit decompression of out-of-order packets. In another example, the receiving device may not decompress out-of-order packets before resetting to the second ROHC context.

[0121] In another example, as shown at 1108, the receiving device may send an RLC ACK for packets from the plurality of packets successfully received based on the first ROHC context before the PDCP status report, the successfully received packets including one or more successfully received packets after the first lost packet.

[0122] Figure 12FIG1200 is a diagram illustrating an example of a hardware implementation for an apparatus 1202. Apparatus 1202 is a UE and includes a cellular baseband processor 1204 (also known as a modem) coupled to a cellular RF transceiver 1222 and one or more subscriber identity module (SIM) cards 1220; an application processor 1206 coupled to a secure digital (SD) card 1208 and a screen 1210; a Bluetooth module 1212; a wireless local area network (WLAN) module 1214; a global positioning system (GPS) module 1216; and a power supply 1218. Cellular baseband processor 1204 communicates with UE 124 and / or BS 122 / 180 via cellular RF transceiver 1222. Cellular baseband processor 1204 may include computer-readable media / memory. The computer-readable media / memory may be non-transitory. Cellular baseband processor 1204 is responsible for general processing, including executing software stored on the computer-readable media / memory. When executed by the cellular baseband processor 1204, the software causes the cellular baseband processor 1204 to perform the various functions described above. The computer-readable medium / memory may also be used to store data manipulated by the cellular baseband processor 1204 when executing the software. The cellular baseband processor 1204 also includes a receiving component 1230, a communication manager 1232, and a transmitting component 1234. The communication manager 1232 includes one or more components shown. The components within the communication manager 1232 may be stored in a computer-readable medium / memory and / or configured as hardware within the cellular baseband processor 1204. The cellular baseband processor 1204 may be a component of the UE 350 and may include at least one of the TX processor 368, the RX processor 356, and the controller / processor 359 and / or the memory 360. In one configuration, the device 1202 may be a modem chip and include only the baseband processor 1204, and in another configuration, the device 1202 may be the entire UE (e.g., see Figure 3 350) and includes additional modules of device 1202.

[0123] The communication manager 1232 includes a packet receiving component 1240 configured to receive a plurality of packets based on the first ROHC context, e.g., as combined with Figure 11 The communication manager 1232 also includes a PDCP re-establishment component 1242 configured to re-establish the PDCP entity, for example, as described in conjunction with Figure 11 The communication manager 1232 also includes a ROHC context reset component 1244, which is configured to reset to a second ROHC context, for example, as described in conjunction with Figure 11The communication manager 1232 also includes a PDCP status reporting component 1246 configured to send a PDCP status report for a plurality of packets, wherein the PDCP status report indicates a NACK for each packet starting from the first lost packet, for example, as described in conjunction with Figure 11 The 1110 description.

[0124] The apparatus may include performing the above Figure 11 Each block in the flowchart of the algorithm has additional components. Therefore, the above components can be executed by Figure 11 Each block in the flowchart of the process / algorithm may be included in the apparatus, and the apparatus may include one or more of those components. The components may be one or more hardware components specifically configured to perform the process / algorithm, implemented by a processor configured to perform the process / algorithm, stored in a computer-readable medium for implementation by a processor, or some combination thereof.

[0125] In one configuration, the apparatus 1202 (specifically, the cellular baseband processor 1204) includes means for receiving a plurality of packets based on a first ROHC context (e.g., packet receiving component 1240 and / or receiving component 1230). The apparatus 1202 includes means for reestablishing a PDCP entity (e.g., PDCP re-establishment component 1242). The apparatus 1202 includes means for resetting to a second ROHC context (e.g., ROHC context resetting component 1244). The apparatus 1202 includes means for sending a PDCP status report for the plurality of packets, wherein the PDCP status report indicates a NACK for each packet starting from a first lost packet (e.g., PDCP status reporting component 1246 and / or sending component 1234).

[0126] The aforementioned means may be one or more of the aforementioned components of the apparatus 1202 configured to perform the functions recited by the aforementioned means. As described above, the apparatus 1202 may include the TX processor 368, the RX processor 356, and the controller / processor 359. Thus, in one configuration, the aforementioned means may be the TX processor 368, the RX processor 356, and the controller / processor 359 configured to perform the functions recited by the aforementioned means.

[0127] Figure 1313 is a flow chart of a method 1300 of wireless communication. The method may be performed by a transmitting device or a component of a transmitting device (e.g., transmitting PDCP entity 802). In some examples, the transmitting device may be a UE or a component of a UE, such as UE 104, 350, or a processing system that may include memory 360 and may be the entire UE 350 or a component of UE 350, such as TX processor 368, RX processor 356, and / or controller / processor 359. In some examples, the transmitting device may be a base station or a component of base station 102, 180, 310, or a processing system that may include memory 376 and may be the entire base station 310 or a component of base station 310, such as TX processor 316, RX processor 370, and / or controller / processor 375. Optional aspects are shown with dashed lines.

[0128] At 1302, a transmitting device may transmit a plurality of packets based on a first ROHC context, for example, in conjunction with Figure 8 (eg, at 806).

[0129] At 1304, after sending the plurality of packets, the transmitting device may receive an RLC ACK for a packet from the plurality of packets that was successfully received based on the first ROHC context.

[0130] At 1306, the transmitting device may re-establish the PDCP entity, for example in conjunction with Figure 8 (e.g., as described at 808).

[0131] At 1308, the sending device may reset to a second ROHC context, for example in conjunction with Figure 8 (e.g., at 812).

[0132] At 1310, the transmitting device may receive a PDCP status report for a plurality of packets, wherein the PDCP status report indicates a NACK for each packet starting with a first lost packet, e.g., in conjunction with Figure 8 (eg, 813). The PDCP status report may indicate a NACK for one or more packets for which the transmitting device previously received an ACK.

[0133] At 1312, the sending device may send retransmissions of each packet starting with the first lost packet based on the second ROHC context, for example in conjunction with Figure 8 (eg, 814). In one example, the sending device may send a retransmission of one or more packets for which the sending device previously received an ACK.

[0134] above Figure 13 Each box in the flowchart and Figure 8The various aspects performed by the transmitting PDCP entity 802 in the process may be performed by at least one component of the apparatus, each component being one or more hardware components specifically configured to perform the process / algorithm, implemented by a processor configured to perform the process / algorithm, stored in a computer-readable medium for implementation by the processor, or some combination thereof. The component may be a software component running in the processor, a software component residing / stored in a computer-readable medium / memory, one or more hardware components coupled to the processor, or some combination thereof. The processing system may be a component of the UE 350 and may include at least one of the TX processor 368, the RX processor 356, and the controller / processor 359 and / or the memory 360. Alternatively, the processing system may be the entire UE (e.g., see Figure 3 UE 350). The system may be a component of base station 310 and may include at least one of TX processor 316, RX processor 370, and controller / processor 375 and / or memory 376. Alternatively, the processing system may be the entire base station (e.g., see Figure 3 310).

[0135] In one configuration, an apparatus for wireless communication at a transmitting device may include: means for transmitting a plurality of packets based on a first ROHC context; means for receiving an RLC ACK for a packet successfully received based on the first ROHC context from the plurality of packets; means for reestablishing PDCP; means for resetting to a second ROHC context; and means for receiving a PDCP status report for the plurality of packets, wherein the PDCP status report indicates a NACK for each packet starting from a first lost packet, e.g., as described in conjunction with Figure 8 The apparatus may further include means for sending a retransmission of each packet starting with the first lost packet based on the second ROHC context. The aforementioned means may be one or more of the aforementioned components of the apparatus and / or the processing system of the apparatus configured to perform the functions recited by the aforementioned means. The processing system may include a TX processor 368, an RX processor 356, and a controller / processor 359. The processing system may be a component of the base station 310 and may include at least one of the TX processor 316, the RX processor 370, and the controller / processor 375 and / or the memory 376. Alternatively, the processing system may be the entire base station (e.g., see Figure 3 Thus, in one configuration, the aforementioned means may be the TX Processor 316 or 368, the RX Processor 356 or 370, and the controller / processor 359 or 375 configured to perform the functions recited by the aforementioned means.

[0136] Figure 141400 is a flow chart of a method of wireless communication. The method can be performed by a transmitting device or a component of a transmitting device (e.g., transmitting PDCP entity 802). In some examples, the transmitting device can be a UE or a component of a UE, such as UE 104, 350, or a processing system that can include memory 360 and can be the entire UE 350 or a component of UE 350, such as TX processor 368, RX processor 356, and / or controller / processor 359. In some examples, the transmitting device can be a base station or a component of base station 102, 180, 310, or a processing system that can include memory 376 and can be the entire base station 310 or a component of base station 310, such as TX processor 316, RX processor 370, and / or controller / processor 375. Optional aspects are shown with dashed lines.

[0137] At 1402, the transmitting PDCP entity may transmit one or more packets based on a first ROHC profile, for example in conjunction with Figure 8 For example, at 806 , the transmitting PDCP entity 802 may transmit a plurality of PDCP packets to the receiving PDCP entity 804 .

[0138] At 1404, the transmitting PDCP entity may re-establish PDCP, for example in conjunction with Figure 8 For example, at 808, the transmitting PDCP entity 802 may perform PDCP re-establishment.

[0139] At 1406, the sending PDCP entity may reset the ROHC context, e.g., in conjunction with Figure 8 For example, at 812, the transmitting PDCP entity 802 may reset the ROHC context to a second ROHC context.

[0140] At 1408, the transmitting PDCP entity may receive a PDCP status report, e.g., in conjunction with Figure 8 For example, at 814, the transmitting PDCP entity 802 may send a PDCP status report for a plurality of packets to the receiving PDCP entity. Then, at 1410, the transmitting PDCP entity may discard the acknowledged packets, e.g., in conjunction with Figure 8 Descriptive.

[0141] At 1412, the transmitting PDCP entity may compress retransmissions of one or more packets based on a second ROHC profile, e.g., in conjunction with Figure 8For example, at 817, the transmitting PDCP entity 802 may utilize the reset ROHC context to compress the retransmission. In some examples, the first ROHC profile may include a ROHC profile other than profile 0 (e.g., ROHC profiles 1-6, etc.), and the second ROHC profile may include profile 0.

[0142] At 1414, the transmitting PDCP entity may compress one or more packets of the initial transmission based on the first ROHC profile, for example, in conjunction with Figure 8 For example, at 817, the transmitting PDCP entity 802 may compress one or more packets for initial transmission based on the first ROHC profile.

[0143] At 1416, the transmitting PDCP entity may transmit a retransmission of one or more packets in conjunction with the initial transmission of one or more packets, e.g., Figure 8 For example, at 818 , the transmitting PDCP entity 802 may send retransmissions of the one or more packets and the one or more packets of the initial transmission to the receiving PDCP entity 804 .

[0144] Figure 15 15 is a flow chart of a method 1500 of wireless communication. The method can be performed by a receiving device or a component of a receiving device (e.g., a receiving PDCP entity). In some examples, the receiving device can be a UE or a component of a UE, such as UE 104, 350, or a processing system that can include memory 360 and can be the entire UE 350 or a component of UE 350, such as TX processor 368, RX processor 356, and / or controller / processor 359. In some examples, the receiving device can be a base station or a component of base station 102, 180, 310, or a processing system that can include memory 376 and can be the entire base station 310 or a component of base station 310, such as TX processor 316, RX processor 370, and / or controller / processor 375. Optional aspects are shown with dashed lines.

[0145] At 1502, a receiving device may receive one or more packets based on a first ROHC profile, for example, in conjunction with Figure 7 and 8 For example, at 706, the receiving PDCP entity 704 may receive one or more packets based on a first ROHC profile (e.g., context). In some examples, UL PDCP reestablishment of a ROHC bearer with a first profile may be enabled, where the first ROHC profile may be one of ROHC profiles 1, 2, 3, 4, 5, or 6.

[0146] At 1504, the receiving device re-establishes the PDCP entity, and at 1506, the receiving device resets the ROHC context, e.g., in conjunction with Figure 7 and 8 For example, at 708, the receiving PDCP entity 704 may initiate PDCP re-establishment, and at 712, the receiving PDCP entity 704 may reset the ROHC context.

[0147] As shown at 1508, the receiving device may send a PDCP status report confirming receipt of the packet received at 1502, e.g., in conjunction with Figure 8 For example, at 814, the receiving PDCP entity 804 may send a PDCP status report for a plurality of packets. For example, the PDCP status report may indicate an FMC equal to x+z, e.g., for a packet with SNx+z. In response to the status report, the transmitting device may discard the acknowledged PDU and reset the ROHC process, e.g., starting from SNx+z to the last PDCP retransmission.

[0148] At 1510, a receiving device receives a retransmission of at least one packet based on a second ROHC profile, e.g., in conjunction with Figure 8 For example, at 818, the receiving PDCP entity 804 may receive retransmissions of each packet starting with the first lost packet based on the second ROHC context. In some examples, retransmissions may be compressed using profile 0 instead of profile 6.

[0149] At 1512, the receiving device receives one or more packets of an initial transmission based on a first ROHC profile. For example, an initial transmission following the reestablishment of the PDCP entity and the reset of the ROHC context may be based on Profile 6, while a retransmission may be based on Profile 0. Since the first few packets of both the retransmission and the initial transmission are IR packets, these packets will be delivered by PDCP to the ROHC decompressor, e.g., because they are not duplicate packets. This approach reduces the number of packets to be compressed for retransmissions and reduces retransmission compression by compressing the initial transmission separately after the ROHC reset.

[0150] The following examples set forth additional aspects and are illustrative only, and aspects thereof may be combined with aspects of other examples or teachings described herein, but are not limited thereto.

[0151] Aspect 1 is a method of wireless communication at a receiving device, comprising: reestablishing a PDCP entity; resetting a ROHC context; receiving a packet retransmission with header compression based on the ROHC; performing decompression of the packet retransmission; and discarding duplicate packets after performing the decompression of the packet retransmission.

[0152] In aspect 2, the method according to aspect 1 further includes: the receiving device discards the duplicate packet after performing the decompression of the packet retransmission until decompressing the last lost packet before re-establishing the PDCP entity, and wherein, after decompressing the last lost packet, the receiving device discards the duplicate packet before performing the decompression.

[0153] In aspect 3, the method according to aspect 1 or aspect 2 further includes: if the duplicate packet is a duplicate of a packet received before re-establishing the PDCP entity, the receiving device discards the duplicate packet after performing the decompression of the packet retransmission.

[0154] In aspect 4, the method according to any one of aspects 1-3 further includes: if the duplicate packet is a duplicate of the packet received after the PDCP entity is re-established, the receiving device discarding the duplicate packet before performing the decompression.

[0155] In aspect 5, the method according to any one of aspects 1-4 further includes: the receiving device discarding the duplicate packet after performing the decompression of the packet retransmission until a timer expires, and wherein, after the timer expires, the receiving device discards the duplicate packet before performing the decompression.

[0156] In aspect 6, the method according to any one of aspects 1-5 further includes: the receiving device discarding the duplicate packet after performing the decompression of the packet retransmission until feedback is received from the ROHC decompressor, and wherein, after the feedback from the ROHC decompressor, the receiving device discards the duplicate packet before performing the decompression.

[0157] In aspect 7, the method according to any one of aspects 1-6 further includes: the feedback indicating that the ROHC decompressor has a valid ROHC context.

[0158] Aspect 8 is an apparatus for wireless communication at a receiving device, comprising: a unit for reestablishing a PDCP entity; a unit for resetting a ROHC context; a unit for receiving a packet retransmission with header compression based on the ROHC; a unit for performing decompression of the packet retransmission; and a unit for discarding duplicate packets after performing the decompression of the packet retransmission.

[0159] In aspect 9, the apparatus according to aspect 8 further comprises: means for performing the method according to any one of claims 2-7.

[0160] Aspect 10 is an apparatus for wireless communication at a receiving device, comprising: a memory; and at least one processor coupled to the memory, the memory and the at least one processor being configured to: reestablish a PDCP entity; reset a ROHC context; receive a packet retransmission with header compression based on the ROHC; perform decompression of the packet retransmission; and discard duplicate packets after performing the decompression of the packet retransmission.

[0161] In aspect 11, the apparatus according to aspect 10 further comprises: the memory and the at least one processor are further configured to execute the method according to any one of claims 2 to 7.

[0162] Aspect 12 is a non-transitory computer-readable medium storing computer-executable code for wireless communication at a receiving device, the code, when executed by a processor, causing the processor to perform the method according to any one of claims 1-7.

[0163] Aspect 13 is a method of wireless communication at a receiving device, comprising: receiving a plurality of packets based on a first ROHC context; reestablishing a PDCP entity; resetting to a second ROHC context; and sending a PDCP status report for the plurality of packets, wherein the PDCP status report indicates a NACK for each packet starting from a first lost packet.

[0164] In aspect 14, the method of aspect 13 further comprises receiving a retransmission of each packet starting with the first lost packet based on the second ROHC context.

[0165] In aspect 15, the method according to aspect 13 or aspect 14 further comprises: performing decompression of the retransmission of each packet starting from the first lost packet.

[0166] In aspect 16, the method according to any one of aspects 13-15 further includes: the receiving device not decompressing out-of-order packets.

[0167] In aspect 17, the method according to any one of aspects 13-16 further includes: the receiving device not decompressing out-of-order packets before resetting to the second ROHC context.

[0168] In aspect 18, the method according to any one of aspects 13-17 further includes: sending an RLC ACK before the PDCP status report, the RLC ACK for packets from the plurality of packets successfully received based on the first ROHC context, including one or more successfully received packets after the first lost packet.

[0169] Aspect 19 is an apparatus for wireless communication at a receiving device, comprising: a unit for receiving a plurality of packets based on a first ROHC context; a unit for reestablishing a PDCP entity; a unit for resetting to a second ROHC context; and a unit for sending a PDCP status report for the plurality of packets, wherein the PDCP status report indicates a NACK for each packet starting from a first lost packet.

[0170] In aspect 20, the apparatus according to aspect 19 further comprises means for performing the method according to any one of claims 14-18.

[0171] Aspect 21 is an apparatus for wireless communication at a receiving device, comprising: a memory; and at least one processor coupled to the memory, the memory and the at least one processor being configured to: receive a plurality of packets based on a first ROHC context; reestablish a PDCP entity; reset to a second ROHC context; and send a PDCP status report for the plurality of packets, wherein the PDCP status report indicates a NACK for each packet starting from a first lost packet.

[0172] In aspect 22, the apparatus according to aspect 21 further comprises: the memory and the at least one processor are further configured to perform the method according to any one of claims 14-18.

[0173] Aspect 23 is a non-transitory computer-readable medium storing computer-executable code for wireless communication at a receiving device, the code, when executed by a processor, causing the processor to perform the method according to any one of claims 13-18.

[0174] Aspect 24 is a method of wireless communication at a transmitting device, comprising: sending a plurality of packets based on a first ROHC context; receiving an RLCACK for a packet successfully received based on the first ROHC context from the plurality of packets; reestablishing a PDCP entity; resetting to a second ROHC context; and receiving a PDCP status report for the plurality of packets, wherein the PDCP status report indicates a NACK for each packet starting from a first lost packet.

[0175] In aspect 25, the method of aspect 24 further comprises sending a retransmission of each packet starting with the first lost packet based on the second ROHC context.

[0176] In aspect 26, the method according to aspect 24 or aspect 25 further comprises: the PDCP status report indicating the NACK for one or more packets for which the transmitting device previously received the ACK.

[0177] In aspect 27, the method according to any one of aspects 24-26 further comprises the sending device sending a retransmission for the one or more packets for which the sending device previously received the ACK.

[0178] Aspect 28 is an apparatus for wireless communication at a sending device, comprising: a unit for sending a plurality of packets based on a first ROHC context; a unit for receiving an RLC ACK for a packet successfully received based on the first ROHC context from the plurality of packets; a unit for reestablishing a PDCP entity; a unit for resetting to a second ROHC context; and a unit for receiving a PDCP status report for the plurality of packets, wherein the PDCP status report indicates a NACK for each packet starting from a first lost packet.

[0179] In aspect 29, the apparatus according to aspect 28 further comprises means for performing the method according to any one of claims 25-27.

[0180] Aspect 30 is an apparatus for wireless communication at a sending device, comprising: a memory; and at least one processor coupled to the memory, the memory and the at least one processor being configured to: send a plurality of packets based on a first ROHC context; receive an RLC ACK for a packet successfully received based on the first ROHC context from the plurality of packets; reestablish a PDCP entity; reset to a second ROHC context; and receive a PDCP status report for the plurality of packets, wherein the PDCP status report indicates a NACK for each packet starting from a first lost packet.

[0181] In aspect 31, the apparatus according to aspect 30 further comprises: the memory and the at least one processor are further configured to perform the method according to any one of claims 25-27.

[0182] Aspect 32 is a non-transitory computer-readable medium storing computer-executable code for wireless communication at a transmitting device, the code, when executed by a processor, causing the processor to perform the method according to any one of claims 24-27.

[0183] Aspect 33 is a method for wireless communication at a sending device, comprising: sending one or more first packets based on a first ROHC profile; reestablishing a PDCP entity; resetting a ROHC context; compressing retransmissions of the one or more first packets based on a second ROHC profile; compressing one or more second packets of an initial transmission based on the first ROHC profile; and sending the retransmissions of the one or more first packets and the one or more second packets of the initial transmission.

[0184] In aspect 34, the method of aspect 33 further includes: the first ROHC profile comprising ROHC profile 6, and the second ROHC profile comprising profile 0.

[0185] In aspect 35, the method according to aspect 33 or aspect 34 further includes: receiving a PDCP status report; and discarding acknowledged packets indicated in the PDCP status report before compressing the retransmission of the one or more packets.

[0186] Aspect 36 is an apparatus for wireless communication at a sending device, comprising: a unit for sending one or more first packets based on a first ROHC profile; a unit for reestablishing a PDCP entity; a unit for resetting a ROHC context; a unit for compressing retransmissions of the one or more first packets based on a second ROHC profile; a unit for compressing one or more second packets of an initial transmission based on the first ROHC profile; and a unit for sending the retransmissions of the one or more first packets and the one or more second packets of the initial transmission.

[0187] In aspect 37, the apparatus according to aspect 36 further comprises means for performing the method according to any one of claims 34-35.

[0188] Aspect 38 is an apparatus for wireless communication at a sending device, comprising: a memory; and at least one processor coupled to the memory, the memory and the at least one processor being configured to: send one or more first packets based on a first ROHC profile; reestablish a PDCP entity; reset a ROHC context; compress retransmissions of the one or more first packets based on a second ROHC profile; compress one or more second packets of an initial transmission based on the first ROHC profile; and send the retransmissions of the one or more first packets and the one or more second packets of the initial transmission.

[0189] In aspect 39, the apparatus according to aspect 38 further comprises: the memory and the at least one processor are further configured to perform the method according to any one of claims 34-35.

[0190] Aspect 40 is a non-transitory computer-readable medium storing computer-executable code for wireless communication at a transmitting device, the code, when executed by a processor, causing the processor to perform the method according to any one of claims 33-35.

[0191] Aspect 41 is a method of wireless communication at a receiving device, comprising: receiving one or more packets based on a first ROHC profile; reestablishing PDCP; resetting a ROHC context; receiving a retransmission of at least one packet based on a second ROHC profile; and receiving an initial transmission based on the first ROHC profile.

[0192] In aspect 42, the method of aspect 41 further includes: the first ROHC profile comprising profile 6, and the second ROHC profile comprising profile 0.

[0193] In aspect 43, the method according to aspect 41 or aspect 42 further includes: sending a PDCP status report.

[0194] Aspect 44 is an apparatus for receiving wireless communications at a device, comprising: a unit for receiving one or more packets based on a first ROHC profile; a unit for reestablishing PDCP; a unit for resetting a ROHC context; a unit for receiving a retransmission of at least one packet based on a second ROHC profile; and a unit for receiving an initial transmission based on the first ROHC profile.

[0195] In aspect 45, the apparatus according to aspect 44 further comprises means for performing the method according to any one of claims 42-43.

[0196] Aspect 46 is an apparatus for receiving wireless communications at a device, comprising: a memory; and at least one processor coupled to the memory, the memory and the at least one processor configured to: receive one or more packets based on a first ROHC profile; reestablish PDCP; reset a ROHC context; receive a retransmission of at least one packet based on a second ROHC profile; and receive an initial transmission based on the first ROHC profile.

[0197] In aspect 47, the apparatus according to aspect 46 further comprises: the memory and the at least one processor are further configured to perform the method according to any one of claims 42-43.

[0198] Aspect 48 is a non-transitory computer-readable medium storing computer-executable code for wireless communication at a receiving device, the code, when executed by a processor, causing the processor to perform the method according to any one of claims 33-35.

[0199] It is to be understood that the specific order or hierarchy of blocks in the disclosed process / flowchart is illustrative of exemplary methods. It is to be understood that the specific order or hierarchy of blocks in the disclosed process / flowchart may be rearranged based on design preferences. In addition, some blocks may be combined or omitted. The accompanying method claims provide elements of the various blocks in an example order and are not intended to be limited to the specific order or hierarchy provided.

[0200] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. For those skilled in the art, various modifications to these aspects will be apparent, and the general principles defined herein can be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but to be given the full scope consistent with the text claims, wherein, unless explicitly stated otherwise, reference to an element in the singular is not intended to mean "one and only one", but rather "one or more". The word "exemplary" is used herein to mean "serving as an example, instance, or illustration". Any aspect described as "exemplary" in this article is not necessarily interpreted as preferred or advantageous over other aspects. Unless otherwise explicitly stated, the term "some" refers to one or more. Combinations such as "at least one of A, B, or C", "one or more of A, B, or C", "at least one of A, B, and C", "one or more of A, B, and C", and "A, B, C, or any combination thereof" include any combination of A, B, and / or C, and may include multiple A, multiple B, or multiple C. Specifically, combinations such as "at least one of A, B, or C," "one or more of A, B, or C," "at least one of A, B, and C," "one or more of A, B, and C," and "A, B, C, or any combination thereof" may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, wherein any such combination may include one or more members or several members of A, B, or C. All structural and functional equivalents of the elements throughout the various aspects described in this disclosure that are known or later become known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be covered by the claims. In addition, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is expressly recited in the claims. The words "module," "mechanism," "element," "device," etc. are not substitutes for the word "unit." Thus, no claim element is to be interpreted as unit plus function unless the element is expressly recited using the phrase "unit for..."

Claims

1. A method for wireless communication at a receiving device, comprising: receiving a plurality of packets based on a first robust header compression (ROHC) context; Re-establishing a Packet Data Convergence Protocol (PDCP) entity; Reset to the second ROHC context; as well as sending a PDCP status report for the plurality of packets, wherein the PDCP status report indicates a negative acknowledgement (NACK) for each packet starting with a first lost packet; The receiving device does not decompress out-of-order packets before resetting to the second ROHC context, and discards the out-of-order packets before resetting to the second ROHC context.

2. The method according to claim 1, further comprising: A retransmission of each packet starting with the first lost packet is received based on the second ROHC context.

3. The method according to claim 2, further comprising: Decompression of the retransmission of each packet starting with the first lost packet is performed.

4. The method according to claim 1, further comprising: A radio link control (RLC) acknowledgement (ACK) is sent prior to the PDCP status report, the RLC ACK for packets from the plurality of packets successfully received based on the first ROHC context, including one or more successfully received packets subsequent to the first lost packet.

5. A method for wireless communication at a transmitting device, comprising: sending a plurality of packets based on a first robust header compression (ROHC) context; receiving a radio link control (RLC) acknowledgment (ACK) for a packet from the plurality of packets successfully received based on the first ROHC context; Re-establishing a Packet Data Convergence Protocol (PDCP) entity; Reset to the second ROHC context; as well as receiving a PDCP status report for the plurality of packets, wherein the PDCP status report indicates a negative acknowledgement (NACK) for each packet starting with a first lost packet; wherein the PDCP status report indicates the NACK for one or more packets for which the transmitting device previously received the RLC ACK, and the transmitting device sends a retransmission for the one or more packets for which the transmitting device previously received the RLC ACK.

6. The method according to claim 5, further comprising: A retransmission of each packet starting with the first lost packet is sent based on the second ROHC context.

7. An apparatus for receiving wireless communications at a device, comprising: means for receiving a plurality of packets based on a first robust header compression (ROHC) context; a unit for re-establishing a Packet Data Convergence Protocol (PDCP) entity; a unit for resetting to a second ROHC context; as well as means for sending a PDCP status report for the plurality of packets, wherein the PDCP status report indicates a negative acknowledgement (NACK) for each packet starting with a first lost packet; The apparatus further includes a unit for not decompressing out-of-order packets before resetting to the second ROHC context and discarding the out-of-order packets before resetting to the second ROHC context.

8. The apparatus according to claim 7, further comprising: Means for receiving a retransmission of each packet starting with the first lost packet based on the second ROHC context.

9. The apparatus according to claim 8, further comprising: Means for performing decompression of said retransmission of each packet starting from said first lost packet.

10. The apparatus according to claim 7, further comprising: Means for sending, prior to the PDCP status report, a radio link control (RLC) acknowledgement (ACK) for packets from the plurality of packets successfully received based on the first ROHC context, including one or more successfully received packets subsequent to the first lost packet.

11. An apparatus for wireless communication at a transmitting device, comprising: means for transmitting a plurality of packets based on a first robust header compression (ROHC) context; means for receiving a radio link control (RLC) acknowledgment (ACK) for a packet from the plurality of packets successfully received based on the first ROHC context; a unit for re-establishing a Packet Data Convergence Protocol (PDCP) entity; a unit for resetting to a second ROHC context; as well as means for receiving a PDCP status report for the plurality of packets, wherein the PDCP status report indicates a negative acknowledgement (NACK) for each packet starting with a first lost packet, and wherein the PDCP status report indicates the NACK for one or more packets for which the means for receiving an RLC ACK previously received the RLC ACK; The apparatus further comprises means for sending a retransmission of the one or more packets for which the means for receiving the RLC ACK previously received the RLC ACK.

12. The apparatus according to claim 11, further comprising: Means for sending a retransmission of each packet starting with the first lost packet based on the second ROHC context.

13. A computer program product for receiving wireless communications at a device, comprising processor-executable instructions that, when executed by a processor, cause the processor to: receiving a plurality of packets based on a first robust header compression (ROHC) context; Re-establishing a Packet Data Convergence Protocol (PDCP) entity; Resetting to a second ROHC context; and sending a PDCP status report for the plurality of packets, wherein: The PDCP status report indicates a negative acknowledgement (NACK) for each packet starting from a first lost packet; The processor is configured to not decompress out-of-order packets before resetting to the second ROHC context, and discard the out-of-order packets before resetting to the second ROHC context.

14. The computer program product of claim 13, wherein: The processor-executable instructions further cause the processor to perform the following steps: A retransmission of each packet starting with the first lost packet is received based on the second ROHC context.

15. The computer program product of claim 14, wherein: The processor-executable instructions further cause the processor to perform the following steps: Decompression of the retransmission of each packet starting with the first lost packet is performed.

16. The computer program product of claim 13, wherein: The processor-executable instructions further cause the processor to send, prior to the PDCP status report, a radio link control (RLC) acknowledgement (ACK) for packets from the plurality of packets successfully received based on the first ROHC context, including one or more successfully received packets subsequent to the first lost packet.

17. A computer program product for transmitting wireless communications at a device, comprising processor-executable instructions that, when executed by a processor, cause the processor to: sending a plurality of packets based on a first robust header compression (ROHC) context; receiving a radio link control (RLC) acknowledgment (ACK) for a packet from the plurality of packets successfully received based on the first ROHC context; Re-establishing a Packet Data Convergence Protocol (PDCP) entity; Reset to the second ROHC context; as well as receiving a PDCP status report for the plurality of packets, wherein the PDCP status report indicates a negative acknowledgement (NACK) for each packet starting with a first lost packet, and wherein the PDCP status report indicates the NACK for one or more packets for which the processor previously received the RLC ACK; Wherein the processor is configured to send a retransmission of the one or more packets for which the processor previously received the RLC ACK.

18. The computer program product of claim 17, wherein: The processor-executable instructions further cause the processor to perform the following steps: A retransmission of each packet starting with the first lost packet is sent based on the second ROHC context.

Images