WO2025014469A1

WO2025014469A1 - Apparatus and method for robust header compression optimization

Info

Publication number: WO2025014469A1
Application number: PCT/US2023/027234
Authority: WO
Inventors: Sheethal KOVOOR; Su-Lin Low; Chun-I Lee; Hausting Hong; Sangwon Ki
Original assignee: Greater Shine Ltd
Current assignee: Greater Shine Ltd
Priority date: 2023-07-10
Filing date: 2023-07-10
Publication date: 2025-01-16
Anticipated expiration: 2026-01-10

Abstract

According to one aspect of the present disclosure, a wireless device is provided. The wireless device may include a robust header compression (ROHC) decompressor. The ROHC decompressor may receive a packet decompression request associated with a packet. The ROHC decompressor may update a fast-pass token based on one or more parameters associated with the packet. The ROHC decompressor may determine whether the fast-pass token is set to a first indicator. In response to determining that the fast-pass token is set to the first indicator, the ROHC decompressor may implement a set of fast pass operations to decompress the packet. In response to determining that the fast-pass token is set to a second indicator different than the first indicator, the ROHC compressor may implement a set of normal pass operations to decompress the packet. The set of fast pass operations may include fewer operations than the set of normal pass operations.

Description

APPARATUS AND METHOD FOR ROBUST HEADER COMPRESSION OPTIMIZATION

BACKGROUND

[0001] Embodiments of the present disclosure relate to apparatus and method for wireless communication.

[0002] Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, and broadcasts. In cellular communication, such as the 4th-gen eration (4G) Long Term Evolution (LTE) and the 5th- generation (5G) New Radio (NR), the 3rd Generation Partnership Project (3GPP) defines various procedures for robust header compression (ROHC).

SUMMARY

[0003] According to one aspect of the present disclosure, a wireless device is provided. The wireless device may include a ROHC decompressor. The ROHC decompressor may be configured to receive a packet decompression request associated with a packet. The ROHC decompressor may be configured to update a fast-pass token based on one or more parameters associated with the packet. The ROHC decompressor may be configured to determine whether the fast-pass token is set to a first indicator. In response to determining that the fast-pass token is set to the first indicator, the ROHC decompressor may be configured to implement a set of fast pass operations to decompress the packet. In response to determining that the fast-pass token is set to a second indicator different than the first indicator, the ROHC compressor may be configured to implement a set of normal pass operations to decompress the packet. The set of fast pass operations may include fewer operations than the set of normal pass operations.

[0004] According to another aspect of the present disclosure, an apparatus for wireless communication is provided. The apparatus may include a communication interface configured to receive a ROHC compressed packet. The apparatus may include a ROHC decompressor. The ROHC decompressor may be configured to receive a packet decompression request associated with the ROHC compressed packet. The ROHC decompressor may be configured to update a fast-pass token based on one or more parameters associated with the ROHC compressed packet. The ROHC decompressor may be configured to determine whether the fast-pass token is set to a first indicator. In response to determining that the fast-pass token is set to the first indicator, the ROHC decompressor may be configured to implement a set of fast pass operations to decompress the ROHC compressed packet. In response to determining that the fast-pass token is set to a second indicator different than the first indicator, the ROHC compressor may be configured to implement a set of normal pass operations to decompress the ROHC compressed packet. The set of fast pass operations may include fewer operations than the set of normal pass operations.

[0005] According to a further aspect of the present disclosure, a method of wireless communication of a user equipment is provided. The method may include receiving, by a ROHC decompressor, a packet decompression request associated with a packet. The method may include updating, by the ROHC decompressor, a fast-pass token based on one or more parameters associated with the packet. The method may include determining, by the ROHC decompressor, whether the fast-pass token is set to a first indicator. In response to determining that the fast-pass token is set to the first indicator, the method may include implementing, by the ROHC decompressor, a set of fast pass operations to decompress the packet. In response to determining that the fast-pass token is set to a second indicator different than the first indicator, the method may include implementing, by the ROHC decompressor, a set of normal pass operations to decompress the packet. The set of fast pass operations may include fewer operations than the set of normal pass operations.

[0006] These illustrative embodiments are mentioned not to limit or define the present disclosure, but to provide examples to aid understanding thereof. Additional embodiments are discussed in the Detailed Description, and further description is provided there.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments of the present disclosure and, together with the description, further serve to explain the principles of the present disclosure and to enable a person skilled in the pertinent art to make and use the present disclosure.

[0008] FIG. 1 illustrates a flowchart of an example method of wireless communication.

[0009] FIG. 2 illustrates an exemplary wireless network, according to some embodiments of the present disclosure.

[0010] FIG. 3 illustrates a block diagram of an exemplary node, according to some embodiments of the present disclosure.

[0011] FIG. 4 illustrates a detailed block diagram of an exemplary wireless device, according to some embodiments of the present disclosure.

[0012] FIG. 5 illustrates a detailed block diagram of a fast pass path of an exemplary ROHC decompressor, according to some embodiments of the present disclosure.

[0013] FIGs. 6A-6B illustrate a flowchart for an exemplary method of wireless communication, according to some embodiments of the present disclosure.

[0014] Embodiments of the present disclosure will be described with reference to the accompanying drawings.

DETAILED DESCRIPTION

[0015] Although specific configurations and arrangements are discussed, it should be understood that this is done for illustrative purposes only. A person skilled in the pertinent art will recognize that other configurations and arrangements can be used without departing from the spirit and scope of the present disclosure. It will be apparent to a person skilled in the pertinent art that the present disclosure can also be employed in a variety of other applications.

[0016] It is noted that references in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” “some embodiments,” “certain embodiments,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of a person skilled in the pertinent art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0017] In general, terminology may be understood at least in part from usage in context. For example, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a,” “an,” or “the,” again, may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context. [0018] Various aspects of wireless communication systems will now be described with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, modules, units, components, circuits, steps, operations, processes, algorithms, etc. (collectively referred to as “elements”). These elements may be implemented using electronic hardware, firmware, computer software, or any combination thereof. Whether such elements are implemented as hardware, firmware, or software depends upon the particular application and design constraints imposed on the overall system.

[0019] The techniques described herein may be used for various wireless communication networks, such as code division multiple access (CDMA) system, time division multiple access (TDMA) system, frequency division multiple access (FDMA) system, orthogonal frequency division multiple access (OFDMA) system, single-carrier frequency division multiple access (SC- FDMA) system, wireless local area network (WLAN) system, and other networks. The terms “network” and “system” are often used interchangeably. A CDMA network may implement a radio access technology (RAT), such as Universal Terrestrial Radio Access (UTRA), evolved UTRA (E-UTRA), CDMA 1000, etc. A TDMA network may implement a RAT, such as the Global System for Mobile Communications (GSM). An OFDMA network may implement a RAT, such as LTE or NR. A WLAN system may implement a RAT, such as Wi-Fi. The techniques described herein may be used for the wireless networks and RATs mentioned above, as well as other wireless networks and RATs.

[0020] Small-packet communication services, e.g., such as voice over internet protocol (VoIP), voice over NR (VoNR), intemet-of-things (loT), industrial loT (IIoT), interactive games, virtual reality (VR), augmented reality (AR), messaging, etc., in the 5G NR network may use ROHC to compress the headers of small packets such as Internet Protocol (IP) packets, user datagram protocol (UDP), real-time protocol (RTP), etc. ROHC may reduce header the overhead of voice packet transmissions, which lowers the block error rate (BER), reduces latency, and limits resource block (RB) consumption.

[0021] In the context of VoIP communications, ROHC may be useful since the header of the VoIP packets is much larger than the payload data it carries. For example, the payload of a VoIP packet may include around 32 bytes of payload voice data and 60 bytes of header. Thus, VoIP is a good candidate for ROHC to reduce the size of the header that is transmitted over the air. Moreover, while voice traffic tends to be very small in terms of data size, it has very frequent transmission. So, ROHC provides an efficient solution to reduce the number of transmitted resource blocks (RBs).

[0022] The ROHC protocol proposes three modes of operation: 1) Unidirectional mode (U-mode), 2) Bidirectional Optimistic mode (O-mode), and Bidirectional Reliable mode (R-mode). In U-mode, packets are transmitted in one direction only, e.g., namely, from the ROHC compressor to the ROHC decompressor. This is useful for network links with no undesirable return path. In order to handle potential decompression errors, the ROHC compressor sends periodic refreshes of the stream context to the ROHC decompressor when operating in U-mode. O-mode works in a similar fashion to U-mode; however, in O-mode, feedback packets are transmitted by the ROHC decompressor on the return path to the ROHC compressor to report transmission errors and to acknowledge successful decompression. R-mode also makes use of feedback information, but is a stricter protocol in terms of context updates.

[0023] At the beginning of a ROHC procedure, both the compressor and decompressor start in U-mode. In the event that a usable return link is identified, they may transition to O-mode, at which point the ROHC decompressor sends a positive acknowledgement with O-mode specified to the ROHC compressor. The transition to R-mode is accomplished in the same way.

[0024] The notion of ROHC compressor/decompressor states is orthogonal to the three operational modes mentioned above. In other words, whichever mode is being used, both the compressor and decompressor work in one of three states so that they basically operate as state machines. Each incoming packet may cause the compressor/decompressor to change its internal state, and every state refers to a defined behavior and compression profile.

[0025] The compressor’s state machine defines the following three states: 1) Initialization and Refresh (IR) state, 2) First Order (FO) state, and 3) Second Order (SO) state. Transitions between the above three compressor-states may occur when the compressor, e.g., 1) compresses a packet that contains too many variations, 2) receives positive/negative feedback from the decompressor, and 3) periodically refreshes the context.

[0026] On the other hand, the decompressor’s state machine defines the following three states: 1) No Context State, 2) Static Context State, and 3) Full Context State. Transitions between the above three decompressor-states may occur when the decompressor, e.g., 1) successfully decompresses a packet and 2) fails to decompress a predetermined number of packets.

[0027] The ROHC protocol defines various compression profiles. These compression profiles include, e.g. 1) Profile 0 (e.g., ROHC Uncompressed - compresses packets that cannot be compressed by any of the following profiles), 2) Profile 1 (e.g., ROHC real-time protocol (RTP) - compresses packets with internet protocol (IP)/user datagram protocol (UDP)/RTP protocol headers, and 3) Profile 2 (e.g., ROHC UDP - compresses packets with IP/UDP protocol headers), among others.

[0028] Profile 1 (e.g., the RTP profile that compresses IP/UDP/RTP headers) defines the following types of ROHC packets: 1) IR packets, 2) IR dynamic (IR-DYN) packets, 3) Type 0 (e g., UO-0, R-0, R-0-CRC), 4) Type 1 (e.g, UO-1, UO-l-ID, UO-l-TS, R-l, R-l-ID, R-l-TS, and 5) Type 2 (e.g., UOR-2).

[0029] The ROHC configuration mode for 5G/6G and beyond reliable link layer may favor O-mode. In the case of Bidirectional 5G/6G VoIP traffic, the link layer ensures minimum residual errors. Hence, most of the network’s preferred configuration for ROHC traffic is O-mode rather than R-mode. O-mode updates the context because every packet carries either a 3-bit or 7-bit cyclic redundancy check (CRC) appended thereto. Compared to R-mode, O-mode does not perform a periodic context-update of context. Unless there is a downgrading of states due to static context invalidation or a pattern change in the dynamic RTP header fields, O-mode is associated with a steady flow of unidirectional optimistic mode Type-0 (UO-0) packets for the duration of communication with the compressor. Typical VoIP traffic communicated using O-mode uses up to 90% UO-O mode packets with RTP timestamp (TS) gaps, which are regularly updated. The RTP TS gaps are generally updated with UOR-Type 2 with Extension 3 packet format.

[0030] During initial data processing, the ROHC compressor sends IR packets to establish the context for the flow. The decompressor receives the initial set of IR packets, triggers acknowledgement feedback, and if the CRC checks out, the decompressor transitions to O-mode and its Full Context State. Once the compressor determines that the decompressor has transitioned to the Static Context State (e.g., within a few IR packets), the compressor transitions to Second Order state. At this point, the compressor starts sending the most optimized packet, e.g., namely, UO-O packets. This occurs if all other dynamic fields of ROHC header can be derived with the RTP sequence number (SN). If there are some pattern changes to RTP TS or IP Identification (IPID), then the compressor switches to UO-1, UO-l-TS, UO-l-ID, UOR-2 packets with Extensions as needed. In the VoIP traffic flow analysis, these pattern changes happen during a silent period. Also, some compressors can fall back to the No Context State periodically and send IR packets to re-establish the static context.

[0031] FIG. 1 illustrates a flowchart of an example method 100 of wireless communication of an existing ROHC decompressor. To begin, at 102, the ROHC decompressor may receive a request to decompress a packet. At 104, the ROHC decompressor may use the existing normal ROHC decompression path, which is applied to all packet types, to decompress the incoming ROHC compressed packet. This existing ROHC decompression technique is executed in a large modem control processor that uses a considerable amount of memory and processing power. The incoming packet types can vary based on ROHC flow context states and input header field pattern changes. The ROHC decompression code is executed on the main mode processor to handle the decompression of all different packet types. There are no fast-pass tokens to route different traffic packets to distinguishable or separate paths or lanes for different traffic types, which leads to various drawbacks.

[0032] For example, the ROHC decompression technique suffers from e.g., 1) the use of a large amount of code and number of instructions, 2) a large number of central processing unit (CPU) million instructions per second (MIPs) cycles, 3) an undesirable amount of power consumption, 4) decompression processing latency, and 5) a large modem silicon footprint due to the large size processor needed to handle the decompression of all packet types using the same processing path. [0033] To overcome these and other challenges, the present disclosure provides an exemplary ROCH decompressor that implements a fast pass control token, which may be used to dynamically route packets to the ROHC fast pass lane. The ROHC fast pass lane is a path designed to be lightweight and efficient for the most frequently used packet types, and is separate from the normal path processing for all other packet types. This routing is based on the ROHC decompressor state and channel -variable conditions, e.g., including the decompressor state, decompressor mode, CRC pass counts, traffic parameters in a flow context, and memory availability, just to name a few.

[0034] Moreover, the exemplary fast pass control token is programmable to suit different application quality-of-service (QoS) types (e.g., for each of the conditions and parameters) to control fast pass routing for each QoS flow and radio bearer. Using this exemplary technique, a user equipment of the present disclosure may be optimized for VoIP traffic by processing the compressed ROHC header for DL RTP packets with less latency and CPU MIPs cycles, as compared to the existing techniques. Additional details of the exemplary ROHC decompressor and its fast-pass token for routing ROHC compressed packets to the fast pass lane are provided below in connection with FIGs. 2-6B.

[0035] FIG. 2 illustrates an exemplary wireless network 200, in which some aspects of the present disclosure may be implemented, according to some embodiments of the present disclosure. As shown in FIG. 2, wireless network 200 may include a network of nodes, such as user equipment 202, an access node 204, and a core network element 206. User equipment 202 may be any terminal device, such as a mobile phone, a desktop computer, a laptop computer, a tablet, a vehicle computer, a gaming console, a printer, a positioning device, a wearable electronic device, a smart sensor, or any other device capable of receiving, processing, and transmitting information, such as any member of a vehicle to everything (V2X) network, a cluster network, a smart grid node, or an Internet-of-Things (loT) node. It is understood that user equipment 202 is illustrated as a mobile phone simply by way of illustration and not by way of limitation.

[0036] Access node 204 may be a device that communicates with user equipment 202, such as a wireless access point, a base station (BS), a Node B, an enhanced Node B (eNodeB or eNB), a next-generation NodeB (gNodeB or gNB), a cluster master node, or the like. Access node 204 may have a wired connection to user equipment 202, a wireless connection to user equipment 202, or any combination thereof. Access node 204 may be connected to user equipment 202 by multiple connections, and user equipment 202 may be connected to other access nodes in addition to access node 204. Access node 204 may also be connected to other user equipments. When configured as a gNB, access node 204 may operate in millimeter wave (mmW) frequencies and/or near mmW frequencies in communication with the user equipment 202. When access node 204 operates in mmW or near mmW frequencies, the access node 204 may be referred to as an mmW base station. Extremely high frequency (EHF) is part of the radio frequency (RF) in the electromagnetic spectrum. EHF has a range of 30 GHz to 200 GHz and a wavelength between 1 millimeter and 10 millimeters. Radio waves in the band may be referred to as a millimeter wave. Near mmW may extend down to a frequency of 3 GHz with a wavelength of 200 millimeters. The super high frequency (SHF) band extends between 3 GHz and 30 GHz, also referred to as centimeter wave. Communications using the mmW or near mmW radio frequency band have extremely high path loss and a short range. The mmW base station may utilize beamforming with user equipment 202 to compensate for the extremely high path loss and short range. It is understood that access node 204 is illustrated by a radio tower by way of illustration and not by way of limitation.

[0037] Access nodes 204, which are collectively referred to as E-UTRAN in the evolved packet core network (EPC) and as NG-RAN in the 5G core network (5GC), interface with the EPC and 5GC, respectively, through dedicated backhaul links (e.g., SI interface). In addition to other functions, access node 204 may perform one or more of the following functions: transfer of user data, radio channel ciphering and deciphering, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection setup and release, load balancing, distribution for non-access stratum (NAS) messages, NAS node selection, synchronization, radio access network (RAN) sharing, multimedia broadcast multicast service (MBMS), subscriber and equipment trace, RAN information management (RIM), paging, positioning, and delivery of warning messages. Access nodes 204 may communicate directly or indirectly (e.g., through the 5GC) with each other over backhaul links (e.g., X2 interface). The backhaul links may be wired or wireless.

[0038] Core network element 206 may serve access node 204 and user equipment 202 to provide core network services. Examples of core network element 206 may include a home subscriber server (HSS), a mobility management entity (MME), a serving gateway (SGW), or a packet data network gateway (PGW). These are examples of core network elements of an evolved packet core (EPC) system, which is a core network for the LTE system. Other core network elements may be used in LTE and in other communication systems. In some embodiments, core network element 206 includes an access and mobility management function (AMF), a session management function (SMF), or a user plane function (UPF) of the 5GC for the NR system. The AMF may be in communication with a Unified Data Management (UDM). The AMF is the control node that processes the signaling between the user equipment 202 and the 5GC. Generally, the AMF provides QoS flow and session management. All user Internet protocol (IP) packets are transferred through the UPF. The UPF provides user equipment (UE) IP address allocation as well as other functions. The UPF is connected to the IP Services. The IP Services may include the Internet, an intranet, an IP Multimedia Subsystem (IMS), a PS Streaming Service, and/or other IP services. It is understood that core network element 206 is shown as a set of rack-mounted servers by way of illustration and not by way of limitation.

[0039] Core network element 206 may connect with a large network, such as the Internet 208, or another Internet Protocol (IP) network, to communicate packet data over any distance. In this way, data from user equipment 202 may be communicated to other user equipments connected to other access points, including, for example, a computer 210 connected to Internet 208, for example, using a wired connection or a wireless connection, or to a tablet 212 wirelessly connected to Internet 208 via a router 214. Thus, computer 210 and tablet 212 provide additional examples of possible user equipments, and router 214 provides an example of another possible access node. [0040] A generic example of a rack-mounted server is provided as an illustration of core network element 206. However, there may be multiple elements in the core network including database servers, such as a database 216, and security and authentication servers, such as an authentication server 218. Database 216 may, for example, manage data related to user subscription to network services. A home location register (HLR) is an example of a standardized database of subscriber information for a cellular network. Likewise, authentication server 218 may handle authentication of users, sessions, and so on. In the NR system, an authentication server function (AUSF) device may be the entity to perform user equipment authentication. In some embodiments, a single server rack may handle multiple such functions, such that the connections between core network element 206, authentication server 218, and database 216, may be local connections within a single rack.

[0041] Each element in FIG. 2 may be considered a node of wireless network 200. More detail regarding the possible implementation of a node is provided by way of an example in the description of a node 300 in FIG. 3. Node 300 may be configured as user equipment 202, access node 204, or core network element 206 in FIG. 2. Similarly, node 300 may also be configured as computer 210, router 214, tablet 212, database 216, or authentication server 218 in FIG. 2. As shown in FIG. 3, node 300 may include a processor 302, a memory 304, and a transceiver 306. These components are shown as connected to one another by a bus, but other connection types are also permitted. When node 300 is user equipment 202, additional components may also be included, such as a user interface (UI), sensors, and the like. Similarly, node 300 may be implemented as a blade in a server system when node 300 is configured as core network element 206. Other implementations are also possible.

[0042] Transceiver 306 may include any suitable device for sending and/or receiving data. Node 300 may include one or more transceivers, although only one transceiver 306 is shown for simplicity of illustration. An antenna 308 is shown as a possible communication mechanism for node 300. Multiple antennas and/or arrays of antennas may be utilized for receiving multiple spatially multiplex data streams. Additionally, examples of node 300 may communicate using wired techniques rather than (or in addition to) wireless techniques. For example, access node 204 may communicate wirelessly to user equipment 202 and may communicate by a wired connection (for example, by optical or coaxial cable) to core network element 206. Other communication hardware, such as a network interface card (NIC), may be included as well.

[0043] As shown in FIG. 3, node 300 may include processor 302. Although only one processor is shown, it is understood that multiple processors can be included. Processor 302 may include microprocessors, microcontroller units (MCUs), digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functions described throughout the present disclosure. Processor 302 may be a hardware device having one or more processing cores. Processor 302 may execute software. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Software can include computer instructions written in an interpreted language, a compiled language, or machine code. Other techniques for instructing hardware are also permitted under the broad category of software. [0044] As shown in FIG. 3, node 300 may also include memory 304. Although only one memory is shown, it is understood that multiple memories can be included. Memory 304 can broadly include both memory and storage. For example, memory 304 may include random-access memory (RAM), read-only memory (ROM), static RAM (SRAM), dynamic RAM (DRAM), ferroelectric RAM (FRAM), electrically erasable programmable ROM (EEPROM), compact disc readonly memory (CD-ROM) or other optical disk storage, hard disk drive (HDD), such as magnetic disk storage or other magnetic storage devices, Flash drive, solid-state drive (SSD), or any other medium that can be used to carry or store desired program code in the form of instructions that can be accessed and executed by processor 302. Broadly, memory 304 may be embodied by any computer-readable medium, such as a non-transitory computer-readable medium.

[0045] Processor 302, memory 304, and transceiver 306 may be implemented in various forms in node 300 for performing wireless communication functions. In some embodiments, at least two of processor 302, memory 304, and transceiver 306 are integrated into a single system- on-chip (SoC) or a single system-in-package (SiP). In some embodiments, processor 302, memory 304, and transceiver 306 of node 300 are implemented (e.g., integrated) on one or more SoCs. In one example, processor 302 and memory 304 may be integrated on an application processor (AP) SoC (sometimes known as a “host,” referred to herein as a “host chip”) that handles application processing in an operating system (OS) environment, including generating raw data to be transmitted. In another example, processor 302 and memory 304 may be integrated on a baseband processor (BP) SoC (sometimes known as a “modem,” referred to herein as a “baseband chip”) that converts the raw data, e.g., from the host chip, to signals that can be used to modulate the carrier frequency for transmission, and vice versa, which can run a real-time operating system (RTOS). In still another example, processor 302 and transceiver 306 (and memory 304 in some cases) may be integrated on an RF SoC (sometimes known as a “transceiver,” referred to herein as an “RF chip”) that transmits and receives RF signals with antenna 308. It is understood that in some examples, some or all of the host chip, baseband chip, and RF chip may be integrated as a single SoC. For example, a baseband chip and an RF chip may be integrated into a single SoC that manages all the radio functions for cellular communication.

[0046] Referring back to FIG. 2, in some embodiments, user equipment 202 may include the exemplary ROCH decompressor that implements a fast pass control token, which may be used to dynamically route the most commonly used packets to the ROHC fast pass lane. Additional details of the exemplary ROHC decompressor are provided below in connection with FIGs. 4-6B. [0047] FIG. 4 illustrates a block diagram of an exemplary apparatus 400 including a baseband chip 402, an RF chip 404, and a host chip 406, according to some embodiments of the present disclosure.

[0048] Referring to FIG. 4, apparatus 400 may be implemented as user equipment 202 of wireless network 200 in FIG. 2. As shown in FIG. 4, apparatus 400 may include baseband chip 402, RF chip 404, host chip 406, and one or more antennas 410. In some embodiments, baseband chip 402 is implemented by a processor and a memory, and RF chip 404 is implemented by a processor, a memory, and a transceiver. Besides the on-chip memory 418 (also known as “internal memory,” e.g., registers, buffers, or caches) on each chip 402, 404, or 406, apparatus 400 may further include an external memory 408 (e.g., the system memory or main memory) that can be shared by each chip 402, 404, or 406 through the system/main bus. Although baseband chip 402 is illustrated as a standalone SoC in FIG. 4, it is understood that in one example, baseband chip 402 and RF chip 404 may be integrated as one SoC or one SiP; in another example, baseband chip 402 and host chip 406 may be integrated as one SoC or one SiP; in still another example, baseband chip 402, RF chip 404, and host chip 406 may be integrated as one SoC or one SiP, as described above.

[0049] In the uplink, host chip 406 may generate raw data and send it to baseband chip 402 for encoding, modulation, and mapping. Interface 414 of baseband chip 402 may receive the data from host chip 406. Baseband chip 402 may also access the raw data generated by host chip 406 and stored in external memory 408, for example, using the direct memory access (DMA). Baseband chip 402 may first encode (e.g., by source coding and/or channel coding) the raw data and modulate the coded data using any suitable modulation techniques, such as multi-phase shift keying (MPSK) modulation or quadrature amplitude modulation (QAM). Baseband chip 402 may perform any other functions, such as symbol or layer mapping, to convert the raw data into a signal that can be used to modulate the carrier frequency for transmission. In the uplink, baseband chip 402 may send the modulated signal to RF chip 404 via interface 414. RF chip 404, through the transmitter, may convert the modulated signal in the digital form into analog signals, i.e., RF signals, and perform any suitable front-end RF functions, such as filtering, digital pre-distortion, up-conversion, or sample-rate conversion. Antenna 410 (e.g., an antenna array) may transmit the RF signals provided by the transmitter of RF chip 404.

[0050] In the downlink, antenna 410 may receive RF signals from an access node or other wireless device. The RF signals may be passed to the receiver (Rx) of RF chip 404. RF chip 404 may perform any suitable front-end RF functions, such as filtering, IQ imbalance compensation, down-paging conversion, or sample-rate conversion, and convert the RF signals (e.g., transmission) into low-frequency digital signals (baseband signals) that can be processed by baseband chip 402.

[0051] Still referring to FIG. 4, baseband chip 402 may include an exemplary ROCH decompressor 420 that implements a fast pass control token, which may be used to dynamically route the most commonly used packets to the ROHC fast pass lane. All other packets may be decompressed using a reduced-sized processor (e.g., a normal pass path). A detailed description of the fast pass path on the small microcontroller is described below in connection with FIG. 5.

[0052] FIG. 5 illustrates a detailed block diagram of a fast pass path 500 of exemplary ROHC decompressor 420 of FIG. 4, according to some embodiments of the present disclosure. Fast pass path 500 may be located on a small microcontroller, while the normal pass path (not shown) may be located on a separate microcontroller and/or processor.

[0053] Referring to FIG. 5, fast pass path 500 may include a control path 502a and a data path 502b. Control path 502a may process information included in ROHC channel control messages 501. In the downlink, the packet data convergence protocol (PDCP) layer handles ROHC compression and decompression for ROHC-enabled radio bearers. The radio bearer setup parameters include ROHC channel parameters, e.g., such as supported ROHC profiles and maximum flows. The PDCP layer forwards the ROHC channel parameters to ROHC decompression components to set up the connection between the RBID and ROHC channel. These operations may be performed by control path 502a of the ROHC decompressor 420. To that end, control path 502a may include, e.g., an initialize context component 504, a context manager 506, a radio bearer identification (RBID) to context mapper 508, a context memory 510, an IP packet working buffer 512, and a feedback handler 514, which outputs feedback information 503.

[0054] Data path 502b may process downlink compressed IP packets 505 received in a channel from multiple flows to generate decompressed IP packets 507. For instance, after the radio bearer channel is established with ROHC enabled, all packets in the radio bearer are forwarded to the ROHC decompressor 420 to perform header decompression as the last step of PDCP processing. These operations may be performed by the data path 502b of the ROHC decompressor. Then, the decompressed IP packets 507 are routed to upper layers to further process the voice frames/ IP/RTP/UDP packets, etc. To that end, data path 502b includes a direct memory access (DMA)-in compressed IP header component 516, a packet parser 518, a packet decompressor 520, a decompressor helper 522, a repair context component 524, and a DMA-out decompressed IP header component 526, which outputs a decompressed IP packet.

[0055] The fast pass algorithm used by data path 502b decompresses commonly used compressed packet formats using minimum processing cycles. For instance, fast-pass processing can include using the minimal processing blocks required to decompress these fast-pass packets, thus eliminating unnecessary processing functions and conditional logic to parse, decode and decompress all possible packet types and conditions. When a fast pass packet is identified, lightweight and highly optimized fast pass processing functions may be applied, while eliminating other cumbersome processing blocks used in the normal pass. For example, the fast pass microcontroller (uC) may perform a limited set of ROHC decompression operations as compared to the normal pass processor, both of which may be located at ROHC decompressor 420. In some embodiments, the fast-pass uC and normal pass processor may be located at packet decompressor 520.

[0056] The operations performed by the fast pass microcontroller may be limited to, e.g., ROHC header parsing, ROHC IP/UDP/RTP header decompression and reconstruction, and ROHC CRC calculations for the dynamic header fields only. Non-fast pass packets are sent to the normal pass processor, which performs all other packet types parsing, decompression, reconstruction, and CRC checking, as well as handling exceptions. The fast pass or normal pass processing route is determined by ROHC decompressor 420 based on a fast-pass token, which is dynamically set based on various programmable parameters and conditions. These programmable parameters and conditions may include, e.g., 1) packet types, 2) current state, 3) current mode, 4) CRC success count, 5) traffic parameters in a flow context, 6) and context identifier (CID) flow memory, just to name a few. Additional details of the fast pass and normal pass algorithms are described below in connection with FIGs. 6A and 6B.

[0057] FIGs. 6A and 6B illustrate a flowchart for an exemplary method 600 (referred to hereinafter as “method 600”) of wireless communication of a ROHC decompressor, according to some embodiments of the present disclosure. Method 600 may be performed by a wireless device, e.g., such as one or more of user equipment 202, node 300, apparatus 400, ROHC decompressor 420, control path 502a, data path 502b, packet decompressor 520, a fast path microcontroller, and/or a normal path processor, a fast-pass token generator, just to name a few. Method 600 may include steps 602-622, as described below. Operations 612-622 in FIG. 6B may be the suboperations of operation 606 in FIG. 6A. It is to be appreciated that some of the steps may be optional, and some of the steps may be performed simultaneously, or in a different order than shown in FIGs. 6 A and 6B.

[0058] Referring to FIG. 6A, at 602, the wireless device may receive a decompress packet request. At 604, the wireless device may update the fast-pass token based on information associated with the compressed packet for which the decompress packet request was received. For instance, the fast-pass token may be updated based on one or more of, e.g., 1) the ROHC compressed packet types, 2) the ROHC decompressor’s current state, 3) the ROHC decompressor’s current mode, 4) CRC success count, 5) traffic parameters in flow context, 6) and the amount of available CID flow memory, just to name a few. At 606, the wireless device may determine whether the fast-pass token is set to “True.” If “Yes at 606, the operations move to 608, where the ROHC compressed packet is decompressed using the fast-pass uC; otherwise, if “No” at 606, the operations move to 601, where the ROHC compressed packet is decompressed using the normalpass processor. Operation 606 may include one or more of the following suboperations described below in connection with FIG. 6B.

[0059] Referring to FIG. 6B, at 612, the wireless device may determine whether the fastpass token is set to “True” by determining whether the ROHC compressed packet is of a first- packet type. In some embodiments, the following O-mode packets are the first-packet type considered for fast pass processing: 1) UO-0, 2) UO-l-ID (no extension, and 3) UO-l-TS (no extension), just to name a few. This can be configurable based on application QOS requirements. For instance, a high-performance QoS with highly compressed data types of UO-0, may only configure UO-O for the Fast-pass token. However, in some other embodiments, the fast pass algorithm can also be programmed for R-mode, if traffic patterns of future networks choose R- mode over O-mode. In that case, the following R-mode packets are the first-packet type considered for fast pass processing: 1) R-0, 2) R-O-CRC, and 3) R-l-ID (no extension), just to name a few. If “Yes” at 612, the operations move to 614; otherwise, if “No” at 612, the operations move to 610 in FIG. 6A, where the ROHC compressed packet associated with the request is processed using the normal-pass processor.

[0060] At 614, the wireless device may determine whether the ROHC decompressor’s state machine is in the “Full Context State.” Here, the fast pass is only enabled when the ROHC decompressor’s state machine is in the “Full Context State.” If “Yes” at 614, the operations may move to 616; otherwise, if “No” at 614, the operations may move to 610 in FIG. 6A, where the ROHC compressed packet associated with the request is processed using the normal-pass processor.

[0061] At 616, the wireless device may determine whether the ROHC decompressor’s current mode is the “Preferred Mode.” Here, the fast pass is only enabled when the preferred mode is the current mode established through feedback messages between the user equipment and the access point. If “Yes” at 616, the operations move to 618; otherwise, if “No” at 616, the operations may move to 610 in FIG. 6A, where the ROHC compressed packet associated with the request is processed using the normal-pass processor.

[0062] At 618, the wireless device may determine whether the number of CRC pass count is greater than N number of successful CRC checks. Here, the fast pass is enabled only after a configurable count number of CRC checks are successful, according to the application’s QoS requirements. This may eliminate constant switching between fast pass and normal pass processing if there were recent CRC failures, which may be associated with pattern changes that required extension 3 packet types and recent packet repairs. If “Yes” at 618, the operations move to 620; otherwise, if “No” at 618, the operations may move to 610 in FIG. 6A, where the ROHC compressed packet associated with the request is processed using the normal-path processor.

[0063] At 620, the wireless device may determine whether the fast-pass traffic parameters are satisfied. For instance, the list of conditions for the fast pass can be programmable according to the application’s specific requirements. This may include that the fast pass is not enabled for non-typical cases. Non-typical cases may include, e.g., 1) packets with long contributing source (CSRC) lists, 2) packets with an IP extension header, and 3) packets associated with timer-based compression of the RTP TS, just to name a few. If “Yes” at 620, the operations may move to 622; otherwise, if “No” at 620, the operations may move to 610 in FIG. 6A, where the ROHC compressed packet associated with the request is processed using the normal-path processor.

[0064] At 622, the wireless device may determine whether it is available the CID flow memory. Here, the fast pass may only be supported for a specific amount of parallel CID flows, depending on memory availability. CID flows with small CIDs are allocated on a first-come basis for fast pass, while the rest of parallel flows are routed to regular processing. If “Yes” at 622, the operations may move to 608 in FIG. 6A, where the ROHC compressed packet is decompressed using the fast-pass microcontroller. Otherwise, if “No” at 622, the operations may move to 610 in FIG. 6A, where the ROHC compressed packet associated with the request is processed using the normal-path processor.

[0065] In various aspects of the present disclosure, the functions described herein may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or encoded as instructions or code on a non-transitory computer-readable medium. Computer-readable media includes computer storage media. Storage media may be any available media that can be accessed by a computing device, such as node 300 in FIG. 3. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, HDD, such as magnetic disk storage or other magnetic storage devices, Flash drive, SSD, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a processing system, such as a mobile device or a computer. Disk and disc, as used herein, includes CD, laser disc, optical disc, digital video disc (DVD), and floppy disk where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. [0066] According to one aspect of the present disclosure, a wireless device is provided. The wireless device may include a ROHC decompressor. The ROHC decompressor may be configured to receive a packet decompression request associated with a packet. The ROHC decompressor may be configured to update a fast-pass token based on one or more parameters associated with the packet. The ROHC decompressor may be configured to determine whether the fast-pass token is set to a first indicator. In response to determining that the fast-pass token is set to the first indicator, the ROHC decompressor may be configured to implement a set of fast pass operations to decompress the packet. In response to determining that the fast-pass token is set to a second indicator different than the first indicator, the ROHC compressor may be configured to implement a set of normal pass operations to decompress the packet. The set of fast pass operations may include fewer operations than the set of normal pass operations.

[0067] In some embodiments, the set of fast pass operations may be implemented using a fast-pass microcontroller by the ROHC decompressor. In some embodiments, the set of normal pass operations may be implemented using a normal-pass processor by the ROHC decompressor.

[0068] In some embodiments, to determine whether the fast-pass token is set to the first indicator, the ROHC decompressor may be configured to determine whether the packet is a first set of packet types. In some embodiments, to determine whether the fast-pass token is set to the first indicator, the ROHC decompressor may be configured to, in response to determining that the packet is not the first set of packet types, determine that the fast-pass token is set to the second indicator.

[0069] In some embodiments, in response to determining that the packet is the first set of packet types, the ROHC decompressor may be further configured to determine whether a state machine of the ROHC decompressor is in a Full Context State. In some embodiments, in response to determining that the state machine of the ROHC decompressor is not in the Full Context State, the ROH decompressor may be further configured to determine that the fast-pass token is set to the second indicator.

[0070] In some embodiments, in response to determining that the state machine of the ROHC decompressor is in the Full Context State, the ROHC decompressor may be further configured to determine whether a mode used by the ROHC decompressor and a corresponding ROHC compressor operate in a predetermine mode. In some embodiments, in response to determining that the state machine of the ROHC decompressor is in the Full Context State, the ROHC decompressor may be further configured to, in response to determining that the ROHC decompressor and the corresponding ROHC compressor do not operate in the predetermine mode, determine that the fast-pass token is set to the second indicator.

[0071] In some embodiments, in response to determining that the ROHC decompressor and the corresponding ROHC compressor operate in the predetermine mode, the ROHC decompressor may be further configured to determine whether a number of successful CRC calculations meets a first threshold value. In some embodiments, in response to determining that the ROHC decompressor and the corresponding ROHC compressor operate in the predetermine mode, the ROHC decompressor may be further configured to, in response to determining that the number of successful CRC calculations does not meet the first threshold value, determine that the fast-pass token is set to the second indicator.

[0072] In some embodiments, in response to determining that the number of successful CRC calculations meets the first threshold value, the ROHC decompressor may be further configured to determine whether a set of fast-pass traffic parameters are satisfied. In some embodiments, in response to determining that the number of successful CRC calculations meets the first threshold value, the ROHC decompressor may be further configured to, in response to determining that the set of fast-pass traffic parameters are not satisfied, determine that the fast-pass token is set to the second indicator.

[0073] In some embodiments, in response to determining that the set of fast-pass traffic parameters are satisfied, the ROHC decompressor may be further configured to determine whether an amount of available CID flow memory meets a second threshold value. In some embodiments, in response to determining that the set of fast-pass traffic parameters are satisfied, the ROHC decompressor may be further configured to, in response to determining that the amount of available CID flow memory does not meet the second threshold value, determine that the fast-pass token is set to the second indicator.

[0074] In some embodiments, in response to determining that the amount of available CID flow memory meets the second threshold value, the ROHC decompressor may be further configured to determine that the fast-pass token is set to the first indicator.

[0075] According to another aspect of the present disclosure, an apparatus for wireless communication is provided. The apparatus may include a communication interface configured to receive a ROHC compressed packet. The apparatus may include a ROHC decompressor. The ROHC decompressor may be configured to receive a packet decompression request associated with the ROHC compressed packet. The ROHC decompressor may be configured to update a fast-pass token based on one or more parameters associated with the ROHC compressed packet. The ROHC decompressor may be configured to determine whether the fast-pass token is set to a first indicator. In response to determining that the fast-pass token is set to the first indicator, the ROHC decompressor may be configured to implement a set of fast pass operations to decompress the ROHC compressed packet. In response to determining that the fast-pass token is set to a second indicator different than the first indicator, the ROHC compressor may be configured to implement a set of normal pass operations to decompress the ROHC compressed packet. The set of fast pass operations may include fewer operations than the set of normal pass operations. [0076] In some embodiments, the set of fast pass operations may be implemented using a fast-pass microcontroller by the ROHC decompressor. In some embodiments, the set of normal pass operations may be implemented using a normal-pass processor by the ROHC decompressor.

[0077] In some embodiments, to determine whether the fast-pass token is set to the first indicator, the ROHC decompressor may be configured to determine whether the ROHC compressed packet is of a first set of packet types. In some embodiments, to determine whether the fast-pass token is set to the first indicator, the ROHC decompressor may be configured to, in response to determining that the ROHC compressed packet is not the first set of packet types, determine that the fast-pass token is set to the second indicator.

[0078] In some embodiments, in response to determining that the ROHC compressed packet is the first set of packet types, the ROHC decompressor may be further configured to determine whether a state machine of the ROHC decompressor is in a Full Context State. In some embodiments, in response to determining that the state machine of the ROHC decompressor is not in the Full Context State, the ROH decompressor may be further configured to determine that the fast-pass token is set to the second indicator.

[0079] In some embodiments, in response to determining that the state machine of the ROHC decompressor is in the Full Context State, the ROHC decompressor may be further configured to determine whether a mode used by the ROHC decompressor and a corresponding ROHC compressor operate in a predetermine mode. In some embodiments, in response to determining that the state machine of the ROHC decompressor is in the Full Context State, the ROHC decompressor may be further configured to, in response to determining that the ROHC decompressor and the corresponding ROHC compressor do not operate in the predetermine mode, determine that the fast-pass token is set to the second indicator.

[0080] In some embodiments, in response to determining that the ROHC decompressor and the corresponding ROHC compressor operate in the predetermine mode, the ROHC decompressor may be further configured to determine whether a number of successful CRC calculations meets a first threshold value. In some embodiments, in response to determining that the ROHC decompressor and the corresponding ROHC compressor operate in the predetermine mode, the ROHC decompressor may be further configured to, in response to determining that the number of successful CRC calculations does not meet the first threshold value, determine that the fast-pass token is set to the second indicator.

[0081] In some embodiments, in response to determining that the number of successful CRC calculations meets the first threshold value, the ROHC decompressor may be further configured to determine whether a set of fast-pass traffic parameters are satisfied. In some embodiments, in response to determining that the number of successful CRC calculations meets the first threshold value, the ROHC decompressor may be further configured to, in response to determining that the set of fast-pass traffic parameters are not satisfied, determine that the fast-pass token is set to the second indicator.

[0082] In some embodiments, in response to determining that the set of fast-pass traffic parameters are satisfied, the ROHC decompressor may be further configured to determine whether an amount of available CID flow memory meets a second threshold value. In some embodiments, in response to determining that the set of fast-pass traffic parameters are satisfied, the ROHC decompressor may be further configured to, in response to determining that the amount of available CID flow memory does not meet the second threshold value, determine that the fast-pass token is set to the second indicator.

[0083] In some embodiments, in response to determining that the amount of available CID flow memory meets the second threshold value, the ROHC decompressor may be further configured to determine that the fast-pass token is set to the first indicator.

[0084] According to a further aspect of the present disclosure, a method of wireless communication of a user equipment is provided. The method may include receiving, by a ROHC decompressor, a packet decompression request associated with a packet. The method may include updating, by the ROHC decompressor, a fast-pass token based on one or more parameters associated with the packet. The method may include determining, by the ROHC decompressor, whether the fast-pass token is set to a first indicator. In response to determining that the fast-pass token is set to the first indicator, the method may include implementing, by the ROHC decompressor, a set of fast pass operations to decompress the packet. In response to determining that the fast-pass token is set to a second indicator different than the first indicator, the method may include implementing, by the ROHC decompressor, a set of normal pass operations to decompress the packet. The set of fast pass operations may include fewer operations than the set of normal pass operations.

[0085] In some embodiments, the set of fast pass operations may be implemented using a fast-pass microcontroller by the ROHC decompressor. In some embodiments, the set of normal pass operations may be implemented using a normal-pass processor by the ROHC decompressor. [0086] The foregoing description of the specific embodiments will so reveal the general nature of the present disclosure that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present disclosure. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.

[0087] Embodiments of the present disclosure have been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed.

[0088] The Summary and Abstract sections may set forth one or more but not all exemplary embodiments of the present disclosure as contemplated by the inventor(s), and thus, are not intended to limit the present disclosure and the appended claims in any way.

[0089] Various functional blocks, modules, and steps are disclosed above. The particular arrangements provided are illustrative and without limitation. Accordingly, the functional blocks, modules, and steps may be re-ordered or combined in different ways than in the examples provided above. Likewise, certain embodiments include only a subset of the functional blocks, modules, and steps, and any such subset is permitted. The breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

WHAT IS CLAIMED IS:

1. A wireless device, comprising: a robust header compression (ROHC) decompressor configured to: receive a packet decompression request associated with a packet; update a fast-pass token based on one or more parameters associated with the packet; determine whether the fast-pass token is set to a first indicator; in response to determining that the fast-pass token is set to the first indicator, implement a set of fast pass operations to decompress the packet; and in response to determining that the fast-pass token is set to a second indicator different than the first indicator, implement a set of normal pass operations to decompress the packet, wherein the set of fast pass operations comprise fewer operations than the set of normal pass operations.

2. The wireless device of claim 1, wherein: the set of fast pass operations are implemented using a fast-pass microcontroller by the ROHC decompressor, and the set of normal pass operations are implemented using a normal-pass processor by the ROHC decompressor.

3. The wireless device of claim 2, wherein, to determine whether the fast-pass token is set to the first indicator, the ROHC decompressor is configured to: determine whether the packet is of a first set of packet types; and in response to determining that the packet is not of the first set of packet types, determine that the fast-pass token is set to the second indicator.

4. The wireless device of claim 3, wherein, in response to determining that the packet is of the first set of packet types, the ROHC decompressor is further configured to: determine whether a state machine of the ROHC decompressor is in a Full Context State; and in response to determining that the state machine of the ROHC decompressor is not in the Full Context State, determine that the fast-pass token is set to the second indicator.

5. The wireless device of claim 4, wherein, in response to determining that the state machine of the ROHC decompressor is in the Full Context State, the ROHC decompressor is further configured to: determine whether a mode used by the ROHC decompressor and a corresponding ROHC compressor operate in a predetermine mode; and in response to determining that the ROHC decompressor and the corresponding ROHC compressor do not operate in the predetermine mode, determine that the fast-pass token is set to the second indicator.

6. The wireless device of claim 5, wherein, in response to determining that the ROHC decompressor and the corresponding ROHC compressor operate in the predetermine mode, the ROHC decompressor is further configured to: determine whether a number of successful cyclic redundancy check (CRC) calculations meets a first threshold value; and in response to determining that the number of successful CRC calculations does not meet the first threshold value, determine that the fast-pass token is set to the second indicator.

7. The wireless device of claim 6, wherein, in response to determining that the number of successful CRC calculations meets the first threshold value, the ROHC decompressor is further configured to: determine whether a set of fast-pass traffic parameters are satisfied; and in response to determining that the set of fast-pass traffic parameters are not satisfied, determine that the fast-pass token is set to the second indicator.

8. The wireless device of claim 7, wherein, in response to determining that the set of fast-pass traffic parameters are satisfied, the ROHC decompressor is further configured to: determine whether an amount of available context identifier (CID) flow memory meets a second threshold value; and in response to determining that the amount of available CID flow memory does not meet the second threshold value, determine that the fast-pass token is set to the second indicator.

9. The wireless device of claim 8, wherein, in response to determining that the amount of available CID flow memory meets the second threshold value, the ROHC decompressor is further configured to: determine that the fast-pass token is set to the first indicator.

10. An apparatus for wireless communication, comprising: a communication interface configured to: receive a robust header compression (ROHC) compressed packet; a robust header compression (ROHC) decompressor configured to: receive a packet decompression request associated with the ROHC compressed packet; update a fast-pass token based on one or more parameters associated with the ROHC compressed packet; determine whether the fast-pass token is set to a first indicator; in response to determining that the fast-pass token is set to the first indicator, implement a set of fast pass operations to decompress the ROHC compressed packet; and in response to determining that the fast-pass token is set to a second indicator different than the first indicator, implement a set of normal pass operations to decompress the ROHC compressed packet, wherein the set of fast pass operations comprise fewer operations than the set of normal pass operations.

11. The apparatus of claim 10, wherein: the set of fast pass operations are implemented using a fast-pass microcontroller by the ROHC decompressor, and the set of normal pass operations are implemented using a normal-pass processor by the ROHC decompressor.

12. The apparatus of claim 11, wherein, to determine whether the fast-pass token is set to the first indicator, the ROHC decompressor is configured to: determine whether the ROHC compressed packet is of a first set of packet types; and in response to determining that the ROHC compressed packet is not of the first set of packet types, determine that the fast-pass token is set to the second indicator.

13. The apparatus of claim 12, wherein, in response to determining that the ROHC compressed packet is of the first set of packet types, the ROHC decompressor is further configured to: determine whether a state machine of the ROHC decompressor is in a Full Context State; and in response to determining that the state machine of the ROHC decompressor is not in the Full Context State, determine that the fast-pass token is set to the second indicator.

14. The apparatus of claim 13, wherein, in response to determining that the state machine of the ROHC decompressor is in the Full Context State, the ROHC decompressor is further configured to: determine whether a mode used by the ROHC decompressor and a corresponding ROHC compressor operate in a predetermine mode; and in response to determining that the ROHC decompressor and the corresponding ROHC compressor do not operate in the predetermine mode, determine that the fast-pass token is set to the second indicator.

15. The apparatus of claim 14, wherein, in response to determining that the ROHC decompressor and the corresponding ROHC compressor operate in the predetermine mode, the ROHC decompressor is further configured to: determine whether a number of successful cyclic redundancy check (CRC) calculations meets a first threshold value; and in response to determining that the number of successful CRC calculations does not meet the first threshold value, determine that the fast-pass token is set to the second indicator.

16. The apparatus of claim 15, wherein, in response to determining that the number of successful CRC calculations meets the first threshold value, the ROHC decompressor is further configured to: determine whether a set of fast-pass traffic parameters are satisfied; and in response to determining that the set of fast-pass traffic parameters are not satisfied, determine that the fast-pass token is set to the second indicator.

17. The apparatus of claim 16, wherein, in response to determining that the set of fast-pass traffic parameters are satisfied, the ROHC decompressor is further configured to: determine whether an amount of available context identifier (CID) flow memory meets a second threshold value; and in response to determining that the amount of available CID flow memory does not meet the second threshold value, determine that the fast-pass token is set to the second indicator.

18. The apparatus of claim 17, wherein, in response to determining that the amount of available CID flow memory meets the second threshold value, the ROHC decompressor is further configured to determine that the fast-pass token is set to the first indicator.

19. A method of wireless communication of a user equipment, comprising: receiving, by a robust header compression (ROHC) decompressor, a packet decompression request associated with a packet; updating, by the ROHC decompressor, a fast-pass token based on one or more parameters associated with the packet; determining, by the ROHC decompressor, whether the fast-pass token is set to a first indicator; in response to determining that the fast-pass token is set to the first indicator, implementing, by the ROHC decompressor, a set of fast pass operations to decompress the packet; and in response to determining that the fast-pass token is set to a second indicator different than the first indicator, implementing, by the ROHC decompressor, a set of normal pass operations to decompress the packet, wherein the set of fast pass operations comprise fewer operations than the set of normal pass operations.

20. The method of claim 19, wherein: the set of fast pass operations are implemented using a fast-pass microcontroller by the ROHC decompressor, and the set of normal pass operations are implemented using a normal-pass processor by the ROHC decompressor.