Description of Related Art

[0001] The present application generally relates to telecommunications and broadband cellular networks, particularly to methods and a system for optimizing small packet applications, such as Voice Over Internet Protocol (VoIP) processing and Internet of Things (loT), in communication systems.

Brief Description of the Drawings

[0002] The present disclosure, in accordance with one or more various embodiments, is described in detail with reference to the following figures. The figures are provided for purposes of illustration only and merely depict typical or example embodiments.

[0003] FIG. 1 depicts an example computing system, such as a User Equipment (UE), implementing the hybrid Robust Header Compression (ROHC)-Real-Time Protocol (RTP) stack system for efficient Voice Over Internet Protocol (VoIP) over wireless networks, in accordance with embodiments of the application.

[0004] FIG. 2 depicts example formats for a VoIP packet that can be processed by the hybrid ROHC-RTP stack system shown in FIG. 1, in accordance with some embodiments.

[0005] FIG. 3 depicts an example sub-system of the hybrid ROHC-RTP stack system particularly employed for downlink communications to the UE, in accordance with some embodiments.

[0006] FIG. 4 is a flow diagram illustrating an example flow sequence for downlink communications to the UE that is implemented by the sub-system of the hybrid ROHC-RTP stack system, in accordance with some embodiments. [0007] FIG. 5 depicts an example sub-system of the hybrid ROHC-RTP stack system particularly employed for uplink communications from the UE, in accordance with some embodiments.

[0008] FIG. 6 is a flow diagram illustrating an example flow sequence for uplink communications from the UE that is implemented by the sub-system of the hybrid ROHC-RTP stack system, in accordance with some embodiments.

[0009] FIG. 7 is a block diagram of an example computing component or device for implementing the disclosed techniques, in accordance with the disclosure.

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

Detailed Description

[0011] Fifth-generation wireless (5G) is an iteration of a cellular technology standard for broadband cellular networks, required by International Mobile Telecommunications as the standard to support an all-internet Protocol (IP) network. 5G technology supports faster data rates, higher connection density, and much lower latency.

[0012] Fourth-generation wireless (4G) is an iteration of broadband mobile communications that has superseded the former 3G wireless technology, and is the predecessor of 5G. In other words, 5G was deployed as the planned successor to the 4G networks which provide connectivity to most current cellphones. 5G technology has been engineered to greatly increase the speed and responsiveness of wireless networks.

[0013] In some deployments, the 5G network is implemented as a stand-alone network. For example, in 5G NR, a voice call is supported entirely over the packet switching (PS) domain with IP Multimedia Subsystem (IMS) signaling and media. Similar to 4G Long Term Evolution (LTE) networks, 5G voice calls are implemented as end-to-end voice over IP (VoIP) connections managed by the IMS core. In other words, the IMS core provides voice as a 5G application service. Voice and video communications services in 5G networks can be implemented on top of the IP data connection. Therefore, the IMS architecture plays an increasingly important role in 5G VoNR. Unlike voice services provided by external applications (i.e., so-called OTT speech services), voice over IMS supports quality of service (QoS) management across the entire 5G system (5GS). While IMS can provide voice services for various types of access (e.g., fixed, cable and 2G/3G) as well as for 5G deployments, 5G is not as flexible. In many cases, 5G NR and VoNR utilize an IMS network to handle the voice services, even across the many deployments that are possible for voice over 5G networks. Thus, in order to conduct a voice call entirely over 5G, the user equipment (UE) setup an IMS Voice Over Internet Protocol (VoIP) call session.

[0014] The IMS is a Session Initiation Protocol (SlP)-based network that serves as the infrastructure for services, call, or session control in advanced networks. As previously described, IMS is employed in both 5G network deployments, and 4G network deployments. For example, in 4G/LTE networks, IMS is located above the packet switch (PS) layer, but it can interact with circuit switch (CS) networks and other packet-switched networks like the Internet. The IMS defines an architecture of logical elements using SIP for call signaling between network elements and provides a layered approach with defined service, control, and transport planes. The application plane provides: an infrastructure for the provision and management of services; subscriber configuration and identity management; and defines standard interfaces to common functionality. The IMS control plane handles the call related signaling and controls transport plane. Major elements of control plane include the Call Session Control Function (CSCF), which comprises Proxy-CSCF (P-CSCF), Interrogating-CSCF (I- CSCF) and Serving-CSCF (S-CSCF), (where the CSCF is essentially a SIP server). The IMS transport plane provides a core IP network with access from a subscriber device over wireless network (or wireline networks). An end-user device, for instance User Equipment (UE), can be implemented with software that allows these devices to be IMS SIP-compliant and utilize SIP-based applications. Such software can include an IMS SIP stack which enables the devices to perform IMS related functions to support IMS SIP applications and services, such as VoIP. [0015] In other approaches, an IMS stack does not distinctly separate the control plane and the data plane. The control plane and the data plane of the IMS are integrated and/or collocated on the same processor of the hardware in some UEs. For example, an existing implementation for the IMS stack can include the control plane (including SIP, User Datagram Protocol (UDP), and Internet protocol (IP) layers) and a data plane (including RTP, UDP, and IP layers) both located on a main processor of the UE. However, this integration of the IMS' control plane and data plane can generally cause an inefficient usage of a modem's resources while processing traffic related to small packet streams services, such as VoIP, loT or gaming. In operation, the UE has to process a VoIP protocol data stack across multiple processors and resources, in a manner that can lead to a wastage of the modem's hardware and processor resources. For example, while the IMS stack is implemented on the main processor, other functions associated with VoIP packet processing are performed by processor(s) and hardware components of the UE's modem. Thus, during packet processing, data has to be re-routed between the UE's main processor (for the IMS stack) and the modem, causing multiple hand-offs between the hardware platforms, which further leads to latency and additional overhead. In some embodiments, the US's main processor includes an operating system and at least one central processing unit. These inefficiencies with respect to the IMS stack, may become more prominent particularly in handling small packet/low throughput traffic such as VoIP and Industrial Internet of Things (HOT) traffic. For example, the extra overhead in processing lower throughput traffic, such as in VoIP applications, can lead to further inefficiencies including larger memory, processor, and microprocessor without Interlocked Pipelines Stages (MIPS) cycles. Furthermore, existing IMS architectures having the integrated control and data planes also experience high modem power usage. Additionally, currently deployed IMS architectures have no flexibility with respect to how resources are employed to process traffic, which exacerbates these drawbacks. That is, an existing IMS does not have the capability to dynamically adjust its resource utilization based on observed patterns and throughput of the traffic that is seen during operation. [0016] Embodiments of the application provide a lightweight (e.g., designed to have a small memory footprint and low resource usage) and efficient hybrid Robust Header Compression (ROHC) and Real-Time Protocol (RTP) stack for VoIP processing in wireless communications systems. The disclosed methods and system are distinctly implemented to optimize the data plane Layer and Layer3 operation in a manner that is particularly suitable for small packet applications. The hybrid ROHC-RTP stack system, as disclosed in detail herein, comprises a combination of hardware and software elements that implement a data plane of the IMS stack on a hardware device that is separate and distinct from the hardware utilized to implement the control plane of the IMS stack. For example, the hybrid ROHC-RTP stack system, including the associated data plane and a RTP stack, can be implemented on a dedicated microprocessor on the UE, while the control plane and other elements of the IMS stack are implemented on a baseband processor (or control processor) of the UE. Consequently, by employing the ROHC-RTP stack system on the microprocessor, which generally consumes less power and experiences less latency than larger hardware platforms (e.g., modem board, baseband processor, etc.), the UE can achieve a more efficient processing of small packets. Furthermore, the hybrid ROHC-RTP stack system can be used to adaptively employ a specific flow sequence (or data path) for processing small packets based on the operational use case (or traffic pattern). For instance, the hybrid ROHC-RTP stack system can be utilized to perform a flow sequence for downlink VoIP traffic received at the UE, where particular hardware resources of the UE are "powered-on" as necessary for the processing required to complete that operation. Thus, in comparison with other approaches, the embodiments can dynamically implement a data path within the hardware of the UE in a manner that achieves efficient, optimized, and low power performance for VoIP applications, thereby improving voice services.

[0017] As alluded to above, an integral aspect of the hybrid ROHC-RTP stack system is a physical (e.g., hardware) and functional (e.g., flow sequence) separation of the control plane and the data plane of the IMS stack on the UE, which allows for fast and efficient processing of small packets. According to the embodiments, the control plane of an IMS stack, which resides on a hardware platform of the UE (e.g., control processor), is physically separated (e.g., in hardware) from the data plane of the RTP stack. The data plane of the RTP is implemented as part of the hybrid ROHC-RTP stack system on a separate microcontroller. By employing separate and distinct hardware resources of the UE to implement the data plane and the control plane of the IMS stack, respectively, it enables fast and low power processing of small packets on the data plane. VoIP applications can transmit packets having payloads that are small, typically under 200 bytes, thereby not using the entire 1500 bytes possible. To this end, it is optimal to process "small" sized packets, such as VoIP packets, without utilizing the power and/or hardware resources associated with a full IMS stack (e.g., control plane and data plane). In some embodiments, an upper limit the small sized packet length is about 200 bytes. If the upper limit is greater than 200 bytes, the power saving decreases, in some instances. In contrast, the hybrid ROHC-RTP stack system can continue processing small packets by separately employing the data plane, without consuming power of the hardware resources of the control plane (e.g., control plane power is "off" while not in use). As will be described in detail, this functional separation (which supports the physical separation) of the control plane and the data plane of the IMS stack can be achieved by strategically passing relevant IMS and RTP information from the control plane to the data plane (after the required control plane functions have been completed), in a manner that allows packet processing to continue to be performed by the data plane independent of the control plane.

[0018] Another aspect of the hybrid ROHC-RTP stack system, as disclosed, consists of implementing a lightweight ROHC decompressor with an RTP stack. For example, in the downlink of VoIP traffic to the UE, the ROHC decompressor functions in concert with the RTP stack to allow VoIP packets to be routed directly to a VoIP application/codec. In comparison with other approaches, the hybrid ROHC-RTP stack system can perform both ROHC-specific and RTP-specific processing of the VoIP packets at the data plane, which results in the packets being in a format that is suitable for them to be directly passed to the VoIP application for further processing. Restated, the need for the IP layer and the UDP layer are essentially eliminated due to the distinct functionality of the hybrid ROHC-RTP stack. Therefore, the overhead (e.g., power consumption, resource utilization, and latency) from the additional processing at the IP and UDP layers (used in conventional IMS stack implementations) can be mitigated by the disclosed embodiments.

[0019] Yet another aspect of the hybrid ROHC-RTP stack system, as disclosed, consists of implementing a lightweight ROHC compressor with an RTP stack. For example, in the uplink of VoIP packets from the UE, the ROHC compressor functions in concert with the RTP stack to allow VoIP packets to be routed directly to the Layer 2 and PHY layer of the UE's hardware platform. The hybrid ROHC-RTP stack system can perform the ROHC-specific and RTP-specific processing of the VoIP packets at the data plane. As a result, the packets are in a format that is suitable for them to be directly passed to the Layer 2 and the PHY layer of the UE (without additional IP layer or UDP layer processing) in order to be ultimately transmitted to the network. As will be described in greater detail herein, each of these aspects of the hybrid ROHC-RTP stack system can function collectively to efficiently process small packets, such as VoIP packets, for optimization of the data plane Layer2 and Layer3 operation. It should be appreciated that although the structure and function of the hybrid ROHC-RTP stack system is described herein with respect to VoIP applications for purposes of illustration, it is not intended to be limiting and the disclosed embodiments can be utilized with other types of communication applications that generate "small" packet communications and/or low latency traffic (e.g., IOT/IIOT).

[0020] Referring now to FIG. 1, an example architecture for a UE's hardware, which is shown in FIG. 1 as a modem 100 hardware platform, that is distinctly configured to implement the disclosed hybrid ROHC-RTP stack system is depicted. In an embodiment, the modem 100 is implemented as a UE baseband modem that has a hardware platform for operating in accordance with third generation partnership project (3GPP) specifications. As referred to herein, the UE baseband modulation and demodulation (modem) hardware platform consists of one or more processors that are configured to support multiple radio access technologies, and the various functions needed for wireless cellular communications. One such function of the modem 100 of a UE can include converting data from a digital format into a format suitable for analog, such as telephone or radio. Generally, the modem 100 transmits data from the UE by modulating one or more carrier wave signals to encode digital information, while the receiver demodulates signals received by the UE to recreate the original digital information.

[0021] A UE is any device used directly by an end-user to communicate. Accordingly, as referred to herein, a UE can be a hand-held telephone, smartphone, a laptop computer equipped with a mobile broadband adapter, or any other mobile computing device. The UE is configured to connect to the base station, such as gNodeB for 5G, as specified in accordance with 3GPP standard specifications (LTE and/or 5G). The UE may be implemented as other forms of mobile computing devices or wireless devices that are used directly by an end-user to communicate and equipped with telecommunication functions, such as voice, video, and text. In an embodiment, the UE is a 5G-enabled smartphone which is capable of supporting enhanced data services, voice (e.g., voice calls over 5G NP, VoNP, VoIP, etc.), video, and other telecommunication functions that are commonly employed by subscribers to broadband cellular networks. Furthermore, the UE's hardware, for example the modem 100 hardware platform, is depicted to implement the disclosed hybrid ROHC-RTP stack system for optimizing VoIP over 4G networks, 5G networks, and emerging 6G networks, as described in greater detail herein.

[0022] The modem 100 can be programmed with firmware, code, software, and the like, in order to implement the functionality required to support the UE's wireless cellular communications. FIG. 1 shows that the hardware platform of the modem 100 can include a first hardware device, such as processor(s), central processing units(s) (CPU) or controller(s), implementing a control plane 110 associated with the IMS functions for the UE. For example, the modem 100 comprises a processor that implements the functions and elements for the control plane 110 and is programmed with an IMS stack 120 (also referred to herein as an "IMS SIP stack"). For example, the IMS stack 120 is software that implements a highly versatile set of tools to facilitate use of IMS SIP applications in a manner that is fully compliant with IETF and 3GPP standards. In some instances, an IMS SIP stack provides SIP, SDP and RTP services, such as encoding, sending, receiving, and parsing SIP messages. The SIP messages can be transferred over several transportation layers, such as UDP, TCP, and SCTP over IPv4 or IPv6, using several security schemes, such as TLS and IPsec. In some cases, the IMS SIP stack implements and supports many extensions and layers above the SIP message. Examples of features implemented by an IMS SIP stack, such as IMS stack 120, can include, but are not limited to: SIP headers for IMS; IPv6 support (the mandatory IMS transportation level); signaling compression (mandatory IMS request for signaling between UE and P-CSCF); support for IP Multimedia (IM) Uniform Resource Identifier (URI), Presence (PRES) URI, and Telephone-Subscriber (TEL) URI; Electronic Number Matching (ENUM) (translation between phone numbers orTEL URI to SIP URI); support for instant messaging (IM); Security agreement negotiation; and support for mobile registration using Service-route and Path headers.

[0023] FIG. 1 shows that the IMS stack 120 is collocated on the first hardware device, such as a processor, that implements the control plane 110. Further, the IMS stack 120 particularly implements an IMS/SIP layer 121, a UDP layer 122, and an IP layer 123. Accordingly, IMS stack 120 that is used in accordance with the embodiment, does not include an RTP layer, in addition to the aforementioned IMS/SIP, UDP, and IP layers. The IMS stack 120 does not have an RTP layer implemented, because the RTP layer (and functions associated with RTP services) are separated logically and physically from the control plane 110 and the IMS stack 120 by implementing the hybrid ROHC-RTP stack. This concept is illustrated in the modem's 100 hardware architecture, as the hybrid ROHC-RTP stack system. This system is shown as including, at least, the hybrid ROHC-RTP (DL) stack 142 and the hybrid ROHC-RTP (UL) stack 146, and a data plane subsystem 130, which is on hardware that is separate and distinct from the hardware processor that is implementing the control plane 110. In an embodiment, the data plane subsystem 130 (or at least the hybrid ROHC-RTP stack) is implemented on a lightweight hardware device, such as a microcontroller. Thus, the microcontroller for the data plane subsystem 130 is a separate hardware device (or circuitry) on the modem's 100 hardware platform, as oppossed to conventional IMS SIP stack deployments that have the data plane and control plane that are collocated on the same hardware processor. Although a microcontroller is described herein for purposes of discussion, it should be appreciated that it is not intended to be limiting and a second hardware device implementing the data plane associated with the IMS functions for the UE, can be a CPU, controller, processor, circuitry, or other device capable of processing small packets to support the UE conducting the communication over a 5G network, for example, without supplying power to the control plane 110. Consequently, the hybrid ROHC-RTP layer achieves both a logical (e.g., RTP services and processing completed independent of the control plane 110) and physical (e.g., RTP stack implemented on a dedicated microcontroller) separation of the RTP layer (and RTP-specific functions) from the IMS stack 120 and the control plane 110.

[0024] Furthermore, FIG. 1 also depicts a separation where the control plane 110 has elements and functions grouped in a logical control path 101 of the modem 100, and the data plane, namely the data plane subsystem 150, has elements and functions grouped into a logical datapath (which is further divided into a downlink datapath 102a, and an uplink datapath 102b). In addition, FIG. 1 depicts another logical architecture of the modem 100, where its various functions and elements, including the disclosed hybrid ROHC-RTP stack system, are grouped into several separate power domains 151-154. Particularly in the example of FIG. 1, the different power domains that comprise the modem's 100 logical architecture include: a PHY-DL domain (Power Domain A); a Data Plane VoIP Processing Stack Domain 152 (Power Domain B), which includes the hybrid ROHC-RTP stack; a PHY - UL Domain 153 (Power Domain C); and a Control Plane Domain 154 (Power Domain D). The logical structure of the aforementioned power domains 151-154 can be based on elements and particular functions that are nominally associated with a UE's modem 100 in 5G and/or 6G VoIP operations, such as decoding (e.g., downlink), packet processing, encoding (e.g., uplink), and the like. In other words, a sub-grouping of the power domain 151-154 can be considered to include the components necessary in order to independently execute a respective task in the modem's 100 function. For example, power domain A 151 & power domain B 152 include the elements needed to execute receiving and processing VoIP packets during a downlink communication to the UE. Consequently, the hybrid ROHC-RTP stack's function allows for power domain A 151 & power domain B 152 to be enabled during downlink, without power being unnecessarily consumed by the other power domains (e.g., power domain C 153 and power domain D 154 in this example) that are not needed in the downlink. Ultimately, by employing the logical groupings achieved by defining power domains 151-154, the embodiments can efficiently control (e.g., turning on/off one or more power domains) these functions respectively, as deemed necessary and optimally for a particular application. Restated, the modem 100 may only "turn-on" an optimized sub-group, including one or more power groups 151-154, of elements on the hardware platform to conduct a VoIP communication. In contrast, a conventional modem wastefully powers the entire hardware platform for every communication. For example, in existing deployments which supply power to the modem's entire hardware platform, even the elements that are only employed for uplink are "turned-on" (but unused) during a downlink communication to the UE, and vice versa. Thus, the disclosed embodiments utilize the concept of power domains to achieve reduced power consumption by the UE's modem and an optimization in processing pf small packets for applications over 46, 5G and/or 6G, thereby mitigating the waste/inefficient use of hardware and CPU resources that is often experienced by UEs currently used in industry. Although functions of the hybrid ROHC-RTP stack system are described with respect to 4G, 5G and 6G wireless networks for purposes of illustration, it is not intended to be limiting. It should be appreciated that the disclosed embodiments can be extended for use with other forms of wireless communication technology, such as WiFi (e.g., IEEE 802.11 family of standards), Bluetooth, automotive and satellite wireless protocols. Similarly, the disclosed embodiments can be employed to achieve efficient processing of small packets for a plethora of applications, such as loT, 11 oT, voice, gaming, and the like, which utilize the aforementioned wireless communication technologies.

[0025] As seen in FIG. 1, the logical architecture of the modem 100 includes a PHY-

DL domain (or PHY-RX domain), depicted as power domain A 151. The functions that can be associated with power domain A 151 include the reception and decode of DL control channel and data channel, including the radio frequency (RF), DFEC and PHY baseband layers. Power domain A 110 can also implement functions for the reception of DL control channel and the decoding of the Downlink Control Information (DCI), which schedules the DL grant and the UL grant.

[0026] The logical architecture of the modem 100 further includes the power domain B 152, which includes a data plane VoIP stack 140. FIG. 1 shows that several key components of the disclosed embodiments are implemented within the power domain B 152, including: a context identifier (CID) table (DL) 142; a ROHC-RTP stack (DL) 141, which further comprises an RTP stack 143, and a ROHC decompressor 144; a CID table (UL) 146; the ROHC-RTP stack (UL) 145, which further comprises an RTP stack 147, and a ROHC compressor 148. The function and structure of these aforementioned elements are described in greater detail herein, for example in reference to FIGS. 3-6. Also, FIG. 1 illustrates that the power domain B 152, particularly the hybrid ROHC-RTP stack, includes a sub-group of components that are in the downlink datapath 102a, and a sub-group of components that are in the uplink datapath 102b, so as to have a dedicated path (and sequence flow) for downlink and uplink communications, respectively. Generally, the functions that can be associated with the power domain B 152 include the packet processing of VoIP data for both downlink and uplink of the UE. Power domain B 152 also encompasses the VoIP datapath from Layer 2/Layer 3 - medium access control (MAC) layer, and RLC/PDCP/ROHC/RTP layers.

[0027] FIG. 1 shows that the logical architecture of the modem 100 includes a PHY- UL domain (or PHY-TX domain), depicted as power domain C 153. Functions associated with power domain C 153 can involve the preparation and transmission of data packets (e.g., VoIP packets) in uplink traffic. For example, functions associated with power domain C 153 can include data plane Layer 2 encoding, PHY-TX encoding, and baseband/RF transmission. Power domain C 153 can also include the transmission of UL control channel, which may be activated without the UL data channel. [0028] In addition, FIG. 1 shows that the logical architecture of the modem 100 includes a control domain, which is depicted as power domain D 154. As seen in FIG. 1, the power domain D 154 comprises the control plane 110, data plane hardware for downlink (DPHW_DL) 131, and data plane hardware for uplink (DPHWJJL) 132. FIG. 1 also shows that the modem 100 can also include communication to an access point (AP)/ host 160. Particularly, FIG. 1 illustrates that the AP/host 160 receives communication data, such as VoIP packets, from the DPHW_DL 131 and transmits communication data, such as VoIP packets, to the DPHWJJL 132.

[0029] The power domain D 154 is associated with the functions and elements of the control plane, including the RRC 111, NAS 112, and the IMS stack 120 (which includes the IP layer 123, UDP layer 122, and the IMS/SIP layer 121). Also, the power domain D 154 can include nominal data plane downlink Layer 3 components (shown in FIG. 1 as DPHW_DL 131) and data plane uplink Layer 3 components (shown in FIG. 1 as DPHWJJL 132). Therefore, by defining the power domain D 154 that particularly includes the control plane 110, the disclosed embodiments can control the resource utilization associated with control plane 110, which further leverages the physical and logical separation of the control plane 110 from the data plane 130 in the architecture. As an example, after the control plane 110 performs the initial procedures to set-up a VoIP session (e.g., IMS and NAS/RRC setup), the power domain D 145 can be "turned-off" to save power consumption, as the subsequent VoIP packet processing functions can be executed separately by the data plane subsystem 130. Thus, as previously alluded to, the power domains 151-154 can be adaptively employed to realize fast and low power processing of VoIP packets (e.g., while control plane 110/power domain D 154 power is "off").

[0030] Also, FIG. 1 illustrates an example of the cooperative functionality of the abovementioned elements of the modem's 100 hardware platform, including the hybrid ROHC-RTP stack and the power domains 151-154 in operation. As an operational example, while utilizing a 5G VoIP application, illustrated as a first VoIP application 155a (shown in FIG. 1 as VoIP Appl) and a second VoIP application 155b (shown in FIG. 1 as VoIP App2) implemented on the UE, traffic consisting of VoIP packets may be communicated by the UE (e.g., using antennas and other wireless communication hardware). Accordingly, in order to support the functionality of the VoIP applications 155a, 155b the control plane 110 is enabled to setup the IMS session using the IMS stack 120. Thereafter, the control plane 110 can transmit the information associated with the setup of the IMS session (e.g., IP, UDP, RTP context and header related info) to the data plane, illustrated in FIG. 1 as the data plane subsystem 130. The data plane subsystem 130 resides on a separate microcontroller of the modem's 100 hardware platform in accordance with the embodiments. The data plane subsystem 130 can store the received information from the control plane 110, such as Layer 3 context information, in a shared CID context table, namely CID table (DL) 142 for a downlink communication and CID table (UL) 146 for an uplink communication. In a communication, each flow corresponds to a flow identifier (Flow ID), and IMS session, and a IMS VoIP flow destination. For example, a flow of a downlink that has an intended flow destination of VoIP application 155a can be corrected routed to that particular application (not VoIP application 155b) based on its corresponding Flow ID, IMS session, indicated flow destination, and other related information. Due to the IMS session related information being saved in either of the CID tables 142, 146, the data plane subsystem 130 and its elements have full visibility of the flow context including the IP/UDP/RTP header static and semi-static fields (e.g., based on the Flow ID). As will be described in greater detail below, this data provided by the control plane 110 is sufficient to enable the hybrid ROHC-RTP stack, where either the ROHC-RTP (DL) 141 or the ROHC-RTP (UL) 145 on the data plane performs ROHC decompression or ROHC compression respectively, and the necessary RTP functions to transfer data between the VoIP applications 155a, 155b and Layer 2 of the modem's 100 hardware platform. Thus, the modem 100 of the disclosed embodiments, implementing the hybrid ROHC-RTP stack, allows a UE to efficiently process VoIP packets (and other "small" packets), which realizes an optimal and low power performance for VoIP applications over 5G and/or 6G.

[0031] FIG. 2 depicts an example format for a VoIP packet 200. In VoIP, audio samples are placed into data packets for transmission over the IP network. In many cases, a single packet contains anywhere from 10 to 30 milliseconds of audio. TCP and UDP are two of the most commonly used connection protocols for data traversal across the Internet. A compressed voice frame is required to be packetized with RTP, UDP, and IP headers and then encapsulated with network interface headers in order to be communicated across a network. A typical format for a Layer 3 - VoIP packet 200 is illustrated. For instance, at Layer 3 of the UE, the VoIP packet 200 comprises the IP header 206, followed by the UDP header 207, followed by RTP header 208, and finally followed by the payload which includes the voice encoded packet data 205. The payload for the VoIP packet 200 can vary with compression codec, payload duration, and compression rate options. In some embodiments, the voice encoded packet data 205 can comprise 10 bytes - 60 bytes of voice payload size. The format of the VoIP packet 200 at Layer 3 generally reflects, to a great extent, the hierarchical structure of the OSI model, and its layers.

[0032] The IP header 206, at the beginning of the VoIP packet 200, can have a size of at least 20 bytes, and fields that include information relevant to routing over a packet- switched network, or IP, such as the packet's length, a source IP address, and a destination IP address. The IP header 206 fields can include: version; Internet Header Length; Type of Service; Total length; Identification; IP Flags: Flag; Fragment Offset; Time to live; Protocol; Header Checksum; Source Address; Destination address; IP Options; and Data.

[0033] The UDP header 207 can have a size of at least eight bytes and fields can include: source port, destination port, packet length (header and data), and a simple (and optional) checksum. Generally, UDP operates at Layer 4.

[0034] RTP is a network protocol used to deliver real-time streaming audio and video media over packet-switched networks, thereby enabling VoIP. In a broad sense, RTP serves as the protocol of voice. RTP operates at the transport layer of the OSI model on top of UDP. UDP provides the services port numbers (that is, session multiplexing) and header checksums (which ensure that the header information does not become corrupted). RTP adds time stamps and sequence numbers to the header information. This allows the remote device to put the packets back in order when it receives them at the remote end (function of the sequence number) and use a buffer to remove jitter (slight delays) between the packets to give a smooth audio playout (function of the time stamp). When transmitting streams of data, there are conditions in the network that may impact communication of packets, such as VoIP packet 200, including: the network can de-sequence packets; some packets can be lost; and jitter can be introduced (jitter is a variance of packet inter-arrival time). RTP can be leveraged to address these issues. Additionally, voice applications are particularly sensitive to delays, and it is important to reliability that packets of the stream are transmitted in real-time. This emphasizes the importance of the RTP header 208, as it is essential in processing VoIP packets to ensure that the packets are communicated in-sequence and without errors. In other words, processing the RTP header 208 properly, is essential for proper end-to-end delivery of realtime voice traffic for the UE. As an example, the RTP header 208 has a size of at least 12 bytes and fields can include: version; padding; extension; CSRC count; marker; payload type; sequence number: time stamp: synchronization source identifier; CSRC; and header extension (optional).

[0035] FIG. 2 illustrates an example format for the VoIP packet 200 as it is received by the UE at its PHY layer, in accordance with a wireless networking technology, such as 3GPP. As seen, the VoIP packet 200 in this format comprises network interface headers, including a MAC header 221, a RLC header 222, a Pdcp header 223, and a Sdap header 224, which encapsulates a ROHC header 210 and the payload, namely the voice encoded packet data 205. This format can result from the PHY layer decoding a MACsubPDU. A MACsubPDU is a subheader that is added to a PDU (at the MAC layer). Further, FIG. 2 illustrates that the VoIP packet 200 can be associated with a Quality of Service (QOS) FlowID (QFI). In general, QoS classification is assigned for each flow. Therefore, packets, such as VoIP packet 200, are classified and marked with an QFI that indicate the QoS classification of its associated flow.

[0036] The ROHC header 210 can be described as a compressed version of the IP header 206, the UDP header 207, and RTP header 208, in accordance with the ROHC standard. As referred to herein, ROHC is a header compression protocol/algorithm that can be used to compress the header of different IP packets, including VoIP packets. In a normal case, without compression, an IPv4 header is approximately 40 bytes and an IPv6 header is approximately 60 bytes. However, by applying ROHC for compression, these headers can be compressed in a manner that allows the ROHC header 210 to be approximately in the range of 1 - 3 bytes.

[0037] As wireless networks, for example 5G, grow to provide more bandwidth for communication applications, services and the consumers of these applications and services, all compete to get bandwidth. In services and applications like VoIP, the payload (e.g., 40 bytes) of the IP packets is almost the same size (or even smaller) than the header (e.g., 40 bytes). These protocol headers are extremely important but can be compressed (and decompressed at the other end) up to 90% using ROHC, as a means to save the bandwidth and use the expensive resource more efficiently. Furthermore, ROHC-based compression also provides other important benefits, such as reduction in packet loss and improved interactive response time. Therefore, in the example of FIG. 2, the VoIP packet 200 in the format having the ROHC header 210 can have substantially less bits (e.g., more suitable for efficient wireless transmission) than the typical Layer 3 format including the uncompressed IP header 206, UDP header 207, and RTP header 208. In an uplink communication from the UE, after ROHC compression, the VoIP packet 200 is encoded and sent down to Layer 2 components of the modem's hardware platform, where the MAC header 221, a RLC header 222, a PDCP header 223, and a SDAP header 224 are attached (in front of the ROHC header 210). The VoIP packet 200 format can be passed to the PHY layer of the UE, and subsequently uplinked to the 5G network.

[0038] A core function of the IMS data plane is to transport an in-sequence and error free payload of a VoIP packet, shown as the voice encoded packet data 205, between Layer 2 and a voice codec/application flow (associated with the application layer). In a downlink scenario, where the VoIP packet 200 is received by the UE from the 5G network, the network interface headers 221-224 are stripped after the packet's 200 initial reception by the PHY layer. Thereafter, the ROHC header 210 is decompressed. Subsequently, at Layer 3, the IP header 206, UDP header 207, and RTP header 208 are removed in order to extract the VoIP packet's 200 payload, which consists of the encoded voice data 205. Consequently, once the voice encoded packet payload 205 is extracted, there is no significant use for the IP header 206 and the UDP header 207 at the UE. In turn, there is no logical necessity to include the extra processing of a full IP layer and an UDP layer for these headers.

[0039] Generally, the IP and UDP layers functions are primarily employed for routing packets with source/destination IP addresses and port numbers. However, after the VoIP packet 200 has been successfully routed to the UE, the information needed to further route the packet data from the Layer 2 to the voice application/codec is already obtained. For example, there may be a configuration where there are multiple VoIP applications installed on the UE, thus presenting multiple upper layer destinations to potentially route the VoIP packet 200. Even in this scenario, the UE can route the voice encoded packet data 205 to the appropriate VoIP application, without performing IP layer and UDP layer processing, by utilizing a unique Flow ID that is associated with the VoIP packet 200 and obtained at Layer 3 (from the RTP processing). Furthermore, the Layer 4 and Layer 2 error recovery functions are already performed at the Layer 2 (MAC/RLC/PDCP) layers. Restated, after decompression of the ROHC header 210, the voice encoded packet payload 205 is in a format that is suitable to be directly passed to the RTP layer (bypassing IP layer processing and UDP layer processing), which performs in-sequence, de-jitter buffering, and error concealment functions before delivering packets to the VoIP application. Hence, eliminating the overhead associated with processing the IP header 206, and UDP header 207 using full IP and UDP layers in the IMS data plane is a core concept to achieve lightweight and efficient processing of the VoIP packet 200. This is in contrast to current IMS stack deployments, where processing of the VoIP packet 200 would further include unnecessary processing of the IP header 206 and the UDP header 207 and having the additional IP and UDP layers implemented in the IMS stack. The disclosed hybrid ROHC-RTP stack can be employed to minimize processing in a manner that optimizes the 5G data plane Layer 2 and Layer 3 operation.

[0040] The disclosed hybrid ROHC-RTP stack system includes several different aspects, one of which includes implementing a lightweight ROHC-RTP DL decompressor (also referred to herein as the "ROHC decompressor") with an RTP stack that can be particularly employed for downlink communications to the UE. FIG. 3 depicts a system 300 that is implemented on the hardware platform of the UE's modem. System 300 can be considered a sub-system with respect to the full hybrid ROHC-RTP stack system shown in FIG.l. The system 300 includes the portions of the hybrid ROHC-RTP stack that are particularly employed for downlink voice communications to the UE, shown as ROHC-RTP (DL) stack 305 in FIG. 3. Examples of functions performed by the ROHC decompressor 310 and the RTP stack 311, which can be deployed in a UE as elements of the ROHC-RTP (DL) 305, are also illustrated. The ROHC decompressor 310 is configured to perform decompression on the ROHC header of VoIP packets (shown in FIG. 2) received by the UE in downlink. As previously described, the ROHC header comprises the IP header, UDP header, and RTP header of the VoIP packet that have been compressed using the ROHC standard for efficient transmission across a wireless network, such as 5G. The ROHC decompressor 310 can apply a decompression algorithm, in accordance with the ROHC standard, to decompress the ROHC header and decode the data. The decompressed VoIP packets then need to undergo RTP processing at the RTP stack 311. In particular, the system 300 is able to achieve enhanced efficiency, as the ROHC decompressor 310 can directly route a decompressed VoIP packet to the RTP stack 311 without performing any processing associated with the IP and UDP layers. Conversely, packet processing for many existing IMS stacks involves processing at the full IP, UDP, and RTP layers, where the IMS stack implements the control plane (including SIP, UDP, and IP layers) and the data plane (including RTP, UDP, and IP layers). After VoIP packets (having a decompressed ROHC header) are directly routed to the RTP stack 311 from the ROHC decompressor 310, this RTP layer can extract in-sequence error-free VoIP voice packets of a flow, and ultimately route the VoIP packets to either of the VoIP applications 355a, 355b.

[0041] According to the embodiments, a key feature of the disclosed hybrid ROHC- RTP stack system is its flexibility. That is, the hybrid ROHC-RTP stack system can dynamically adjust which of the UE's hardware resources are used in a particular traffic pattern for a VoIP session (e.g., uplink or downlink) in a manner that minimizes power consumption. FIG. 3 specifically shows how the hybrid ROHC-RTP stack system can adaptively adjust resource utilization by specifically employing system 300, including the ROHC-RTP (DL) stack 305, in order to route and process packets associated with VoIP, particularly in the use case of a downlink communication to the UE. That is, during a downlink, it can be assumed that the other elements of the modem's hardware platform (as shown in FIG. 1) that are not in the system 300 do not need to be powered-on, thus achieving efficient usage of resources by avoiding powering the entire hardware platform of the modem or AP unnecessarily (e.g., turning-on elements not actually used for downlink).

[0042] As an operational example, the system 300 can receive a packet at the UE's PHY Layer 320, namely a VoIP packet in this example. The components and function of the PHY Layer 320 can be consistent with a UE's Layer 1 specifications as defined by a wireless communication technology standard, for instance 3GPP. Afterwards, the packet is routed to the IMS data plane implementation on the UE, namely the data plane VoIP stack 340. FIG. 3 illustrates that the PHY Layer 330 routes the received packet to a MAC 313 for subsequent processing. Additional Layer 2 (DL) elements and functions can be implemented on the data plane VoIP stack 340, in accordance with the standards defined by a wireless communications technology, such as 3GPP.

[0043] In order to support VoIP communications, the UE performs an IMS set-up to utilize the IMS SIP-based services that are available for the network, such as VoIP over 5G. The UE's control plane 330 can perform this IMS setup, and then transfers the information relevant to the IMS set-up from the control plane 330 to be stored at the CID table (DL) 312 on the data plane. The IMS data plane for the UE can be implemented in system 300 by the data plane VoIP stack 340 (on the separate microcontroller). Although not shown in FIG. 3, the CID table (DL) 312 may be specifically implemented as a component within the ROHC-RTP (DL) 305. Further, as seen in FIG. 3, the data plane VoIP stack 340 includes, but is not limited to: the CID table (DL) 312; the ROHC-RTP (DL) 305, which includes the ROHC decompressor 310 and the RTP stack 311; and additional Layer 2 (DL) related functions and elements, shown as MAC 313, decipher 314, and PDCP/RLC 315. On this data plane VoIP stack 340, the IMS parameters related to the IMS session, received from the control plane 330, are populated in the CID table (DL) 312. In accordance with the embodiments, there can be a respective CID table for each radio bearer (RB) - ROHC channel.

[0044] FIG. 3 particularly shows an example of contents that may be contained by a CID table. For example, the CID table (DL) 312 can store, for each entry/flow: a CID; a Flow ID; IP/UDP header information; RTP header RTPhdr information; RTP session information; and Window-based least significant bit (WLSB) Win Context information. The WLSB Win Context information is related to a win check operation, which is a function of the 3GPP standard. Accordingly, the CID table (DL) 312 has stored thereon the IMS parameters that correspond to the flow for the IMS session that has been set-up. Further, with any subsequent IMS sessions that are set-up by the control plane 330, the CID table (DL) 312 is also populated with this IMS relevant information from the control plane 330. Consequently, the IMS parameters for any additional flows can be updated in the CID table (UL) 312 for subsequent IMS sessions that are also set-up for the UE at the control plane 330. As background, for each new flow in a communication a unique "flow identifier" (referred to herein as Flow ID) is generated such that the same ID is calculated for both directions of a bi-directional flow. A Flow ID can comprise, a 5-tuple (source IP address, source TCP/UDP port, destination IP address, destination TCP/UDP port and IP protocol) a 3-tuple (source IP address, destination IP address, IP protocol), or other arrangement of data that can serve as an identifier for a flow of data packets.

[0045] The CID table (DL) 312 includes a first table entry associated with a first flow in the VoIP communication that is received by the UE in downlink, which has: a corresponding Flow ID (shown in FIG. 3 as Flow ID = 1), CID (shown in FIG. 3 as CID = 'a'), and other stored information relating to the IMS parameters. In addition, the CID table (DL) 312 includes a second table entry associated with a second flow in the VoIP communication that is received by the UE in downlink, which has: a corresponding Flow ID (shown in FIG. 3 as Flow ID = 2), CID (shown in FIG. 3 as CID = 'b'), and other stored information relating to the IMS parameters. Thus, after IMS set-up, the data plane VoIP stack 305 has access to the information from the control plane that has been stored in the CID table (DL) 312, and correspondingly has full context of the flow (e.g., Layer 3 information, IP/UDP/RTP header static and semi-static fields). The CID table (DL) 312 maintains information that is sufficient for the embodiments to later perform RTP-specific functions, such as CRC-based error checking, that are required to successfully process the VoIP packets. That is, information from the CID table (DL) 312 can be retrieved in a manner that allows the full header for the VoIP packet (e.g., IP/UDP/RTP header) to be reconstructed by the ROHC-RTP (DL) 305, while still eliminating need to implement the IP and UDP layers and processing.

[0046] After the initial Layer 2 related VoIP packet processing functions are performed at the data plane VoIP stack 340 (e.g., MAC processing, decipher, etc.), the VoIP packet is passed to the ROHC-RTP (DL) 305. FIG. 3 illustrates that the VoIP packet can be output from the PDCP/RLC 315 (the initial Layer 2 processing on the data plane) to the ROHC decompressor 310 of the ROHC-RTP (DL) 305. The ROHC decompressor 310 then decompresses the ROHC header of the VoIP packet (which is received at the UE compressed by the source), as a means to decode the packet's header information that has been subjected to ROHC compression. In particular, the CID, which corresponds to the flow, is decoded from the header. For an initial uncompressed VoIP packet, the corresponding CID may not be previously stored in the CID table (DL) 312, but can obtained from the packet's header data and then updated in the CID table (DL) 312 for the appropriate flow. This is accomplished by finding the destined flow in the table 312 having IP parameters (e.g., source IP address, destination IP address) that match the IP parameters from the uncompressed VoIP packet. For example, the uncompressed header data (of an initial uncompressed VoIP packet) can include IP header information. It can then be determined that packet's IP header information is the same as the IP header information that is stored in the CID table (DL) 312 for the first flow entry corresponding to a first flow (shown in FIG. 3 as Flow ID = 1). Accordingly, the CID that is obtained from the uncompressed packet can be determined to correspond to that first flow, and then the CID is populated into the CID table (DL) 312 for the first flow entry. Once data transfer begins for compressed VoIP packets, the corresponding CID can be looked up in the CID table (DL) 312 and retrieved. The information retrieved from the CID table (DL) 312 enables full header reconstruction for the corresponding VoIP packet by the ROHC decompressor 310. Reconstructing the full header (also referred to herein as the full L3 header) of the VoIP packet is necessary for CRC purposes in the RTP-specific processing.

[0047] Additionally, FIG. 3 illustrates that the ROHC decompressor 310 can perform CRC functions using the reconstructed full header (including IP/UDP/RTP headers) in order to conduct error checking for the VoIP packet. That is, after the full header is successfully reconstructed, a CRC error checking procedure can be executed by the ROHC decompressor 310 using the header information. In an embodiment, the ROHC decompressor 310 is configured to perform CRC in accordance with 5G standard. Thus, the ROHC decompressor 310 performed CRC on the received VoIP packet in order to validate the accuracy of the information contained in the packet. This can involve calculating a ROHC CRC value from the reconstructed full header. Upon verifying that the result of the CRC validation is successful (e.g., there are no CRC errors), the received VoIP packet is validated and thus the CID table (DL) 312 can be updated to include the CID and addition information (e.g., states, etc.) for that flow.

[0048] Once the VoIP packet has been successfully validated using the CRC executed by the ROHC decompressor 310, this packet payload, which is voice encoded packet data, can be directly routed to the RTP stack 311 for further processing. As alluded to above, routing packets directly from the ROHC-RTP 305 to the RTP stack 311, essentially eliminating IP and UDP layers from the IMS stack, is a key feature of the disclosed embodiments with respect to realizing a lightweight stack that accomplishes efficient processing of VoIP packets. The RTP stack 311 is configured to implement elements and functions associated with Layer 3 and/or RTP layer packet processing, in accordance with the standards defined by a wireless communications technology, such as 5G. Subsequent to the RTP stack 311 completing all of the necessary RTP-specific functions, the payload that has been extracted from the VoIP packet can be routed to the appropriate application, either VoIP application 355a or VoIP application 355b on the UE. For example, information in the CID table (DL) 312 can be utilized to determine that a VoIP packet associated with the first flow is to be routed to the first VoIP application 355a, and a VoIP packet associated with the second flow is to be routed to the second VoIP application 355b, as depicted in the example operation of FIG. 3.

[0049] FIG. 4 is a flow diagram illustrating the flow sequence 400 that can be dynamically implemented by the disclosed hybrid ROHC-RTP stack system particularly for the traffic pattern of downlink to the UE. Restated, the flow sequence 400 may be conducted by the system implementing the ROHC-RTP (DL) as described above in reference to FIG. 3. As seen, the sequence flow 400 involves communication between several elements described in the abovementioned system (as shown in FIG. 3), including: a VoIP application 401; control plane 402; the data plane VoIP stack 403, including the ROHC-RTP (DL) 411 which further comprises the RTP stack 404, the ROHC decompressor 405, and CID table (DL) 406; Layer 2 (DL) 407; PHY Layer (DL) 408; and base station (BS)/network (NW) 409.

[0050] The sequence flow 400 can begin at flow 410 with the control plane 402 performing an RRC connection set-up and NAS registration procedure. Generally, when a UE initiates a call, in accordance with 5G NR for instance, an RRC connection is set up between the calling UE and its serving gNodeB. The RRC connection set-up and NAS registration enables the subsequent signaling and logical channels that are utilized in communication by the UE. Subsequently, at flow 414, a VoIP session can be initiated by the VoIP application 401. The VoIP application 401 can be a software application that is implemented on the UE. In operation, a user can initiate a voice call via the VoIP application 401 using a 5G-enabled mobile UE. For example, the user can press a displayed icon on the UE's user interface to launch the VoIP application 401 and start a voice call over the 5G network using VoIP. Accordingly, the VoIP application 401 can start a UE originated voice call, or VoIP session, over 5G. Subsequently, in VoIP packets can be received by the UE in downlink voice traffic to the UE.

[0051] Next, at flow 415, the control plane 402 performs an RRC reconfigure procedure with the BS/NW 409. This can involve re-configuring and/or communicating information relevant to the signaling and channels that are utilized by the UE in communication, such as the SIP and RTP bearers, RB/LC/CC/PHY Layer/Layer 2- Layer 3, and Flow IDs. The RRC configuration can include elements and functions in accordance with a standard as defined by a wireless communication technology, such as 5G. Thereafter, at flow 420, the control plane 402 performs an IMS session set-up procedure with the BS/NW 409. The IMS session set-up procedure enables the UE to utilize the IMS SIP services and functions. During the IMS set-up, the flow 420 can involve the control plane 402 establishing and communicating information that is relevant to the IMS session, such as: the VolP/SIP session parameters; RTP session parameters; IMS session parameters; UDP/IP parameters; and the like. The elements and functions that implement the IMS session set-up can be in accordance with a standard as defined by a wireless communication technology, such as 5G.

[0052] The flow sequence 400 can proceed to flow 425 where the control plane 402 performs a configuration procedure. For example, the UE and associated parameters can be configured in accordance with the IMS session that was set-up by the control plane 402 in previous flow 420. FIG. 4 shows that flow 425 involves the control plane 402 communicating IMS session information, RTP information, IP/UDP header information, radio bearer (RB), and Flow ID information to the CID table (DL) 406 at the data plane. The aforementioned IMS session related information that is communicated from the control plane 402 in flow 425 can be used to populate and/or update the CID table (DL) 406. Details regarding the contents, updating, and utilizing the CID table (DL) 406 are described above in reference to FIG. 4 and thus are not described in detail again for purposes of brevity.

[0053] The information stored in the CID table (DL) 406 is accessible to the other elements of the data plane VoIP stack 403, including the ROHC-RTP (DL) 411 which further comprises the RTP stack 404, the ROHC decompressor 405. As a result, the data plane has information which is sufficient to reconstruct a full header of a VoIP packet during processing at the data plane, and without implementing additional IP and UDP layers.

[0054] As previously described, FIG. 4 also illustrates a key concept of the embodiments, which is the logical separation of the control plane functions and the data plane functions. The previously described flows 410-425 from the flow sequence 400 are conducted by (or are functions of) the control plane 402. The remaining flows 430-460 of the flow sequence 400 are conducted by (or are functions of) the data plane VoIP stack 403, which implements the disclosed hybrid ROHC decompressor 405 with RTP stack 404. Therefore, flows 430-460 can be generally described as the hybrid ROHC-RTP stack functions, which are implemented at the data plane. It is this separation of the data plane processing from the control plane processing which realizes the optimized 5G data plane Layer and Layer3 operation for small voice packets for the embodiments. Furthermore, the flow sequence 400 illustrates that after the IMS session is set-up and configured (e.g., flows 420, 425), there are no other functions performed by the control plane 402 in the sequence for handling the downlink to the UE, and thus the associated hardware can be turned-off after this point to conserve power and optimize resource utilization.

[0055] At flow 430, initial uncompressed VoIP packets can be received (e.g., by the UE in downlink) from the BS/NW 409 for one or more flows associated with the VoIP session. The corresponding CIDs for the uncompressed VoIP packets of a flow can be determined by the ROHC-RTP (DL) 411 from decoding their headers. An entry in the CID table (DL) 406 that is associated with the decoded CID can be located by determining a particular flow that has matching IP parameters (based on the IMS session information received from the control plane). Accordingly, flow 430 can include updating the CID table (DL) 406 with the CID (decoded from the uncompressed packets) for the determined corresponding table entry/flow.

[0056] Thereafter, in flow 435, data transfer of compressed VoIP packets from the BS/NW 409 can begin. These compressed VoIP packets can be passed to the data plane VoIP stack 403, and more specifically to the ROHC decompressor 405 for further packet processing. FIG. 4 shows that the ROHC decompressor 405 executes its decompression and processing functions as disclosed herein, the functions including: decompression of ROHC header; decoding the ROHC header in order to obtain the corresponding CID for the packet; lookup of CID in CID table (DL) 406 to retrieve full context of the flow to reconstruct packet header; reconstruction of full Layer 3 packet header (IP/UDP/RTP headers); calculate CRC for VoIP packet using the reconstructed full Layer 3 packet header; verification of CRC; and update CID states in CID table (DL) 406. The ROHC decompressor 405 functions are previously described in detail herein, for example in reference to FIG. 1 and 3, and is not described again with respect to FIG. 4 for purposes of brevity.

[0057] Next, at flow 440, the ROHC decompressor 405 can route the payloads of the VoIP packets, which can comprise voice encoded data, to the RTP stack 404 for RTP-specific processing. Information that is relevant to RTP processing of the VoIP packet, such as Flow ID, RTP header parameters, and the like, may also be communicated from the ROHC decompressor 405 to the RTP stack 404 in flow 440. Also, FIG. 4 illustrates that examples of RTP-specific processing that is performed by the RTP stack 404, in response to receiving VoIP, include: in-sequence analysis (e.g., sequence numbering); de-jitter buffering; and error concealment.

[0058] After the RTP stack 404 successfully completes its RTP-specific processing on a VoIP packet received in downlink, the voice data can be routed from the RTP stack 404 to the VoIP application 401 to conduct VoIP over 5G, in flow 445. For example, the VoIP application 401 can convert digital signals conveying the voice content of the transmitted voice packets into a voice output in a manner that is intelligibly audible to the user of the UE.

[0059] Another aspect of the disclosed hybrid ROHC-RTP stack system includes several different aspects, one of which includes implementing a lightweight ROHC-RTP UL compressor (also referred to herein as the "ROHC compressor") with an RTP stack that can be particularly employed for uplink communications from the UE. FIG. 5 depicts a system 500 that is implemented on the hardware platform of the UE's modem. System 500 can be considered a sub-system with respect to the full hybrid ROHC-RTP stack system shown in FIG.l. The system 500 includes the portions of the hybrid ROHC-RTP stack that are particularly employed for uplink voice communications from the UE, shown as ROHC-RTP (UL) 505 in FIG. 5. As seen in FIG. 5, the hybrid ROHC-RTP (UL) 505, which is implemented within the data plane VoIP stack 550, also comprises the ROHC compressor 510 and the RTP stack 511.

[0060] As described herein, an integral feature of the hybrid ROHC-RTP stack system involves dynamically adjusting which of the UE's hardware resources are used in a particular traffic pattern for a VoIP session (e.g., uplink or downlink) in a manner that minimizes power consumption. FIG. 5 depicts which elements of the full hybrid ROHC-RTP stack system (shown in FIG. 1) are particularly employed in transmitting an uplink communication from the UE, namely the ROHC compressor 510 and the RTP stack 511. Examples of functions performed by the ROHC compressor 510 and the RTP stack 511, which can be deployed in a UE as elements of the ROHC-RTP (UL) 505, are also illustrated. Thus, FIG. 5 illustrates how the hybrid ROHC-RTP stack system can adaptively adjust resource utilization by specifically employing system 500, including the ROHC-RTP (DL) stack 505, in order to route and process packets associated with VoIP, particularly in the use case of an uplink communication from the UE. During an uplink, it can be assumed that the other elements of the modem's hardware platform (as shown in FIG. 1) that are not in the system 500 do not need to be powered-on, allowing the embodiments to achieve efficient usage of resources by avoiding powering the entire hardware platform of the modem or AP unnecessarily (e.g., turning-on elements not actually used for uplink).

[0061] FIG. 5 illustrates that, in operation, the data plane VoIP stack 550 receives voice data from either of the VoIP applications 555a, 55b. In the example, the VoIP application 555a generates data associated with a first flow, and the VoIP application 555a generates data associated with a second flow. This voice data generated by the VoIP applications 555a, 555b is packetized as the payload for VoIP packets in order to be processed and communicated over a wireless network, such as 5G. As seen in FIG. 5, the VoIP applications 555a, 555b particularly send the voice data to the ROHC-RTP (UL) 505 on the data plane VoIP stack 550, and more specifically to the RTP stack 511. The RTP stack 511 is configured to encode RTP headers for the VoIP packets. The general functions of RTP with respect to realtime voice traffic and the format of RTP headers are described in detail above, for example in reference to FIG. 2. Thus, the RTP stack 511 can generate RTP headers, execute processing and further functions with respect to Layer 4/Layer 3 components of the UE's modem hardware platform. [0062] The RTP stack 511 can then route the voice data, including the encoded RTP header, directly to the ROHC compressor 523. As previously described, a typical full L3 header comprises the IP header, UDP header, and RTP header for the VoIP packet. A key aspect related to the scheme for the uplink traffic pattern involves constructing the full header for the VoIP packet by leveraging the IMS session information that is stored in the CID table (UL) 512, without requiring the additional IP and UDP layers to be implemented in the hybrid ROHC-RTP stack. A control plane transferring IMS related information to the data plane in a manner that is sufficient is to construct (or reconstruct in the downlink scheme) the full header of a VoIP packet is explained in great detail herein, for example in reference to FIGS. 3-4. In a similar fashion, the control plane 505 (Power Domain D) can execute the IMS set-up for the UE prior to the VoIP packets being processed at the RTP stack 511. After IMS set-up is completed, the control plane 540 communicates the information that is related to this IMS set-up, such as IMS session information, RTP information, IP/UDP header information, RB, Flow ID, and the like, to the data plane VoIP stack 550. Accordingly, the CID table (DL) 512 has stored thereon the IMS parameters that correspond to the flow for the IMS session that has been set-up. Further, with any subsequent IMS sessions that are set-up by the control plane 540, the CID table (DL) 512 is also populated with this IMS relevant information from the control plane 540. Consequently, the IMS parameters for any additional flows can be updated in the CID table (UL) 312 for subsequent IMS sessions that are also set-up for the UE at the control plane 540.

[0063] For an initial uncompressed VoIP packet, the corresponding CID may not be previously stored in the CID table (DL) 512 but can be obtained from the packet's header data and then updated in the CID table (DL) 512 for the appropriate flow. This is accomplished by, after an uncompressed packet is created for a flow, finding the destined flow in the CID table (UL) table 512 having IP parameters (e.g., source IP address, destination IP address) that match the IP parameters from the uncompressed VoIP packet. For example, the uncompressed header data (of an initial uncompressed VoIP packet) can include IP header information. It can then be determined that packet's IP header information is the same as the IP header information that is stored in the CID table (UL) 512 for the first flow entry corresponding to a first flow (shown in FIG. 3 as Flow ID = 1). Accordingly, the CID that is obtained from the uncompressed packet can be determined to correspond to that first flow, and then the CID is populated into the CID table (DL) 512 for the first flow entry (shown in FIG. 3 as CID = 'a').

[0064] Once data transfer begins, the VoIP packet is routed to the RTP stack 511 for RTP header encoding for this flow, as previously described above. After processing at the RTP stack 511, it can be assumed that the payload and RTP header portions of the VoIP packet are created. Then, the VoIP packet (having RTP header and payload) can be routed from the RTP stack 511 directly to the ROHC compressor 510 (bypassing any IP/UDP layers and processing), where the corresponding CID for the flow can be looked up in the CID table (DL) 512 and retrieved. The information that is retrieved from the CID table (DL) 512 provides enough context with respect to IP and UDP for the ROHC compressor 510 to construct these headers, respectively. As a result, the ROHC compressor 510 has received the RTP header and payload portions of the VoIP packet from the RTP stack 511 and can construct the IP and UDP headers from the IMS information it has retrieved for the flow from the CID table (DL) 512. Thus, the ROHC compressor 510 is enabled to construct the full L3 header full L3 header (e.g., IP/UDP/RTP headers) for the corresponding VoIP packet, without having to implement additional IP and UDP layers in the ROHC-RTP (UL) 505. Thus, the disclosed embodiments reduce the processing and resource overhead involved in preparing the VoIP packets for uplink, in a manner that improves efficiency for VoIP over 5G.

[0065] Constructing the full header of the VoIP packet is necessary for CRC purposes in packet processing. The ROHC compressor 510 is configured to perform functions of CRC error checking in accordance with a standard defined for wireless communications technology, such as 5G. For example, the ROHC compressor 510 can calculate a CRC value for a VoIP packet using the constructed full header, and subsequently attach the calculated CRC value to the VoIP packet (e.g., to be decoded and used during the receiver-side CRC error checking functions). [0066] Furthermore, the ROHC compressor 523 is configured to perform header compression for the VoIP packet, in accordance with the ROHC standard. For example, the ROHC compressor 510 performs compression on the full header of a VoIP packet in order to reduce the overall size of the packet, prior to the VoIP packet being uplinked from the UE for more efficient transmission over the wireless network. In some embodiments, the ROHC compressor 510 applies a compression algorithm (e.g., W-LSB, scaled-TS, etc.) to the data comprising the IP, UDP, and RTP headers, thereby creating a ROHC header for the VoIP packet that is a substantially smaller in size as compared to the full header prior to compression. Ultimately, the ROHC compressor 510 outputs VoIP packets that are encoded with the ROHC header, which are then routed from ROHC-RTP (UL) 505 the to the Layer 2 (UL) 560 elements and PHY Layer 570 elements of the UE modem's hardware platform. In detail, after processing of the VoIP packets are completed by the ROHC-RTP (UL) 505, the compressed VoIP packets are prepared to be routed to the Radio Bearer (RB) queues 580. The RB queues 580 then deliver the VoIP packets to the Layer 2 (e.g., MAC/RLC/PDCP layer) 560 elements, which is shown to include PDCP 561, RLC 562, and cipher 563. From the Layer 2 (UL) 560 elements on the modem's hardware platform, the VoIP packets are sent to the PHY layer (UL) 570 elements interfacing with the network, for uplink transmission of these VoIP packets to the 5G network. For example, the VoIP packets that are uplinked from the PHY layer (UL) components 570 of the UE can be received by a second UE over the 5G network, where the second UE is a 5G-enabled mobile device that can also receive and transmit voice data in a bidirectional VoIP session.

[0067] FIG. 6 is a flow diagram illustrating the flow sequence 600 that can be dynamically implemented by the disclosed hybrid ROHC-RTP stack system particularly for the traffic pattern of uplink from the UE. For example, the flow sequence 600 may be conducted by the system implementing the ROHC-RTP (UL) as described above in reference to FIG. 5. As shown in FIG. 6, the sequence flow 600 involves communication between several elements described in the abovementioned system (as shown in FIG. 4), including: a VoIP application 601; control plane 602; the data plane VoIP stack 603, including the ROHC-RTP (UL) 611 which further comprises the RTP stack 604, the ROHC compressor 605, CID table (DL) 606, and Layer 2 (UL) 607; PHY Layer (UL) 608; and base station (BS)/network (NW) 609.

[0068] The sequence flow 600 can begin at flow 610 with the control plane 602 performing an RRC connection set-up and NAS registration procedure. The RRC connection set-up and NAS registration enables subsequent signaling and logical channels that are utilized in communication by the UE. A VoIP session can be initiated by the VoIP application 601. The VoIP application 601 can be a software application that is implemented on the UE. In operation, a user can initiate a voice call via the VoIP application 601 using a 5G-enabled mobile UE. For example, the user can press a displayed icon on the UE's user interface to launch the VoIP application 601 and start a voice call over the 5G network using VoIP. Accordingly, the VoIP application 601 can start a UE originated voice call, or VoIP session, over 5G in flow 614.

[0069] Thereafter, at flow 615, the control plane 402 performs an RRC reconfigure procedure with the BS/NW 609. Next, at flow 620, the control plane 602 performs an IMS session set-up procedure with the BS/NW 409. During the IMS set-up, the flow 620 can involve the control plane 402 establishing and communicating information that is relevant to the IMS session, such as: the VolP/SIP session parameters; RTP session parameters; IMS session parameters; UDP/IP parameters; and the like. The elements and functions that implement the IMS session set-up can be in accordance with a standard as defined by a wireless communication technology, such as 5G

[0070] The flow sequence 600 can proceed to flow 625 where the control plane 602 performs a configuration procedure. For example, the UE and associated parameters can be configured in accordance with the IMS session that was set-up by the control plane 602 in previous flow 620. FIG. 6 shows that flow 625 involves the control plane 602 communicating IMS session information, RTP information, IP/UDP header information, radio bearer (RB), and Flow ID information to the CID table (UL) 606 at the data plane. The aforementioned IMS session related information that is communicated from the control plane 602 in flow 625 can be used to populate and/or update the CID table (UL) 606. Details regarding the contents, updating, and utilizing the CID table (UL) 606 are described above in reference to FIG. 5 and thus are not described in detail again for purposes of brevity.

[0071] The information stored in the CID table (UL) 606 is accessible to the other elements of the data plane VoIP stack 603, including the ROHC-RTP (UL) 611 which further comprises the RTP stack 604, and the ROHC compressor 605. As a result, the data plane has information which is sufficient to later allow the ROHC compressor 605 to construct a full header of a VoIP packet during processing at the data plane, and without implementing additional IP and UDP layers.

[0072] As previously described, FIG. 6 also illustrates a key concept of the embodiments, which is the logical separation of the control plane functions and the data plane functions. The previously described flows 610-625 from the flow sequence 600 are conducted by (or are functions of) the control plane 602. The remaining flows 630-645 of the flow sequence 600 are conducted by (or are functions of) the data plane VoIP stack 603, which implements the disclosed hybrid ROHC compressor 605 with RTP stack 604. Therefore, flows 630-660 can be generally described as the hybrid ROHC-RTP stack functions, which are implemented at the data plane. It is this separation of the data plane processing from the control plane processing which realizes the optimized 5G data plane Layer2 and Layer3 operation for small voice packets for the embodiments. Furthermore, the flow sequence 600 illustrates that after the IMS session is set-up and configured (e.g., flows 620, 625), there are no other functions performed by the control plane 602 in the sequence for handling the uplink the UE, and thus the associated hardware can be turned-off after this point to conserve power and optimize resource utilization.

[0073] The flow sequence 600 continues with flow 630, where VoIP packets for one or more flows associated with the VoIP session are routed from the VoIP application 601 to the RTP stack 604. The RTP stack 604 encodes a respective RTP header for the received VoIP packets. Flow 630 can involve the RTP stack 604 generating RTP headers and executing other processing functions with respect to Layer 4/Layer 3 components of the UE's modem hardware platform. [0074] Subsequently, in flow 635, after the RTP stack 604 has completed its processing, the VoIP packets are routed from the RTP stack 604 to the ROHC compressor 605. The VoIP packets that are passed to the ROHC compressor 605 can comprise a payload of voice encoded data, generated by the VoIP application 601, and an RTP header, generated by the RTP stack 604. Due to the ROHC compressor's 605 capability to construct the full header for the VoIP packet by leveraging the IMS session information that is stored in the CID table (UL) 606, the VOIP packets can be passed directly from the RTP stack 604 to the ROHC compressor 605 without requiring additional IP/UDP layers and processing to be implemented in the hybrid ROHC-RTP stack. Thus, the disclosed embodiments can substantially reduce an amount of processing required for VoIP packets in a manner that increases the efficiency of VoIP over 5G.

[0075] Flow 640 involves initial uncompressed VoIP packets being created (e.g., by the UE) for one or more flows associated with the VoIP session. The corresponding CIDs for the uncompressed VoIP packets of a flow can be determined by the ROHC-RTP (UL) 611 from their headers. An entry in the CID table (DL) 606 that is associated with the CID can be located by determining a particular flow that has matching IP parameters (based on the IMS session information received from the control plane). Accordingly, flow 640 can include updating the CID table (DL) 606 with the CID (from the uncompressed packets) for the determined corresponding table entry/flow.

[0076] Then the ROHC compressor 605 can perform a series of processing functions, to construct a full packet header and prepare the VoIP packets for uplink from the UE. FIG. 6 shows that the ROHC compressor 605 executes its decompression and processing functions as disclosed herein, the functions including: lookup of CID in CID table (DL) 606 to retrieve full context of the flow to construct full packet header; construction of full Layer 3 packet header (IP/UDP/RTP headers); calculate CRC for VoIP packet using the constructed full Layer 3 packet header; compression of full packet header to encode VoIP packet with ROHC header. The ROHC compressor 405 functions are previously described in detail herein, for example in reference to FIG. 1 and 5, and are not described again with respect to FIG. 6 for purposes of brevity. As a result, the ROHC compressor 605 can output compressed VoIP packets that are prepared for uplink from the UE.

[0077] After the data plane VoIP stack 603, namely the ROHC compressor 605, successfully completes its processing on a VoIP packet, the processed VoIP packets are routed from the ROHC-RTP (UL) 611 to the Layer 2 (UL) 607 components of the UE. Then routed from Layer 2 (UL) 607 of the UE PHY Layer (UL) 608. Lastly, FIG. 6 shows flow 645 that the compressed VoIP packets are uplinked from the UE to the BS/NW 609, where the packets are further transmitted to conduct VoIP over 5G.

[0078] FIG. 7 depicts a block diagram of an example computer system 700 in which various features of the ROHC-RTP hybrid stack described herein may be implemented. The computer system 700, for example, can be a mobile device used as a UE performing efficient VoIP over 5G and/or 6G networks by implemented the disclosed hybrid ROHC-RTP stack system. The computer system 700 includes a bus 702 or other communication mechanism for communicating information, one or more hardware processors 704 coupled with bus 702 for processing information. Hardware processor(s) 704 may be, for example, one or more general purpose microprocessors.

[0079] The computer system 700 also includes a main memory 706, such as a random-access memory (RAM), cache and/or other dynamic storage devices, coupled to bus 702 for storing information and instructions to be executed by processor 704. Main memory 706 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 704. Such instructions, when stored in storage media accessible to processor 704, render computer system 700 into a special-purpose machine that is customized to perform the operations specified in the instructions.

[0080] The computer system 700 further includes a read only memory (ROM) 708 or other static storage device coupled to bus 702 for storing static information and instructions for processor 704. A storage device 710, such as a magnetic disk, optical disk, or USB thumb drive (Flash drive), etc., is provided and coupled to bus 702 for storing information and instructions.

[0081] The computer system 700 may be coupled via bus 702 to a display 712, such as a liquid crystal display (LCD) (or touch screen), for displaying information to a computer user. An input device 614, including alphanumeric and other keys, is coupled to bus 702 for communicating information and command selections to processor 704. Another type of user input device is cursor control 616, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 704 and for controlling cursor movement on display 712. In some embodiments, the same direction information and command selections as cursor control may be implemented via receiving touches on a touch screen without a cursor.

[0082] The computing system 700 may include a user interface module to implement a GUI that may be stored in a mass storage device as executable software codes that are executed by the computing device(s). This and other modules may include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables.

[0083] In general, the word "component," "engine," "system," "database," data store," and the like, as used herein, can refer to logic embodied in hardware or firmware, or to a collection of software instructions, possibly having entry and exit points, written in a programming language, such as, for example, Java, C or C++. A software component may be compiled and linked into an executable program, installed in a dynamic link library, or may be written in an interpreted programming language such as, for example, BASIC, Perl, or Python. It will be appreciated that software components may be callable from other components or from themselves, and/or may be invoked in response to detected events or interrupts. Software components configured for execution on computing devices may be provided on a computer readable medium, such as a compact disc, digital video disc, flash drive, magnetic disc, or any other tangible medium, or as a digital download (and may be originally stored in a compressed or installable format that requires installation, decompression or decryption prior to execution). Such software code may be stored, partially or fully, on a memory device of the executing computing device, for execution by the computing device. Software instructions may be embedded in firmware, such as an EPROM. It will be further appreciated that hardware components may be comprised of connected logic units, such as gates and flipflops, and/or may be comprised of programmable units, such as programmable gate arrays or processors.

[0084] The computer system 700 may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system causes or programs computer system 700 to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system 700 in response to processor(s) 704 executing one or more sequences of one or more instructions contained in main memory 706. Such instructions may be read into main memory 706 from another storage medium, such as storage device 710. Execution of the sequences of instructions contained in main memory 706 causes processor(s) 704 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.

[0085] The term "non-transitory media," and similar terms, as used herein refers to any media that store data and/or instructions that cause a machine to operate in a specific fashion. Such non-transitory media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 710. Volatile media includes dynamic memory, such as main memory 706. Common forms of non-transitory media include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge, and networked versions of the same.

[0086] Non-transitory media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between non-transitory media. For example, transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 702. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

[0087] The computer system 700 also includes a communication interface 718 coupled to bus 702. Communication interface 718 provides a two-way data communication coupling to one or more network links that are connected to one or more local networks. For example, communication interface 718 may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 718 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN (or WAN component to communicated with a WAN). Wireless links may also be implemented. In any such implementation, communication interface 718 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

[0088] A network link typically provides data communication through one or more networks to other data devices. For example, a network link may provide a connection through local network to a host computer or to data equipment operated by an Internet Service Provider (ISP). The ISP in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the "Internet." Local network and Internet both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link and through communication interface 718, which carry the digital data to and from computer system 700, are example forms of transmission media. The computer system 700 can send messages and receive data, including program code, through the network(s), network link and communication interface 718. In the Internet example, a server might transmit a requested code for an application program through the Internet, the ISP, the local network and the communication interface 718.The received code may be executed by processor 704 as it is received, and/or stored in storage device 710, or other non-volatile storage for later execution.

[0089] In an embodiment, a system includes a hardware platform implemented on a UE that is employed for wireless communication. The UE is enabled to conduct a communication involving small packets over a wireless network. The hardware platform includes a first hardware device and a second hardware device. The first hardware device implements a control plane associated with IMS functions for the UE. The second hardware device implements a data plane associated with IMS functions for the UE. Furthermore, the second hardware device includes a ROHC-RTP stack system that implements the RTP functions associated with the processing the small packets.

[0090] In another embodiment, a method includes decompressing a ROHC header of a VoIP packet in a downlink communication to UE over a wireless network. Decompressing the ROHC header involves decoding a CID associated with a flow for the VoIP packet. Next, the process retrieves stored information from a CID table based on the decoded CID. The stored information corresponds to the flow and includes information related to the set-up of an IMS session for the UE. Thereafter, the method involves reconstructing a full header for the VoIP packet based on the received information that corresponds to the flow. The full header that has been reconstructed can include an IP header, a UDP header, and a RTP header. After the full header for the VoIP packets is reconstructed, CRC error checking is performed for the VoIP packet using the reconstructed full header. In response to the CRC error checking, the method proceeds to directly route the VoIP packet to an RTP stack such that RTP functions associated with processing the VoIP packet received in the downlink to the UE are performed. [0091] In a further embodiment, a method includes retrieving stored information from a CID table. A CID for a VoIP packet communicated in an uplink communication from a UE over a wireless network can be used to retrieve the stored information from the CID table. The stored information corresponds to a flow associated with the VoIP packet, and includes information related to the set-up of an IMS session for the UE. Next, the method involves constructing a full header for the VoIP packet based on the received information corresponding to the flow. The full header can include an IP header, a UDP header, and a RTP header. After the full header is constructed for the VoIP packet, the method proceeds to perform CRC error checking for the VoIP packet using the constructed full header. Subsequently, in response to the CRC error checking, the method involves compressing the full header for the VoIP packet to generate a ROHC header for the VoIP packet. Thereafter, the method routes the VoIP packet having the ROHC header to a Layer 2 component of the UE such the VoIP packet is communicated in the uplink communication from the UE over the wireless network.

[0092] Each of the processes, methods, and algorithms described in the preceding sections may be embodied in, and fully or partially automated by, code components executed by one or more computer systems or computer processors comprising computer hardware. The one or more computer systems or computer processors may also operate to support performance of the relevant operations in a "cloud computing" environment or as a "software as a service" (SaaS). The processes and algorithms may be implemented partially or wholly in application-specific circuitry. The various features and processes described above may be used independently of one another or may be combined in various ways. Different combinations and sub-combinations are intended to fall within the scope of this disclosure, and certain method or process blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular sequence, and the blocks or states relating thereto can be performed in other sequences that are appropriate, or may be performed in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed example embodiments. The performance of certain of the operations or processes may be distributed among computer systems or computers processors, not only residing within a single machine, but deployed across a number of machines.

[0093] As used herein, a circuit might be implemented utilizing any form of hardware, software, or a combination thereof. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logical components, software routines or other mechanisms might be implemented to make up a circuit. In implementation, the various circuits described herein might be implemented as discrete circuits or the functions and features described can be shared in part or in total among one or more circuits. Even though various features or elements of functionality may be individually described or claimed as separate circuits, these features and functionality can be shared among one or more common circuits, and such description shall not require or imply that separate circuits are required to implement such features or functionality. Where a circuit is implemented in whole or in part using software, such software can be implemented to operate with a computing or processing system capable of carrying out the functionality described with respect thereto, such as computer system 700.

[0094] As used herein, the term "or" may be construed in either an inclusive or exclusive sense. Moreover, the description of resources, operations, or structures in the singular shall not be read to exclude the plural. Conditional language, such as, among others, "can," "could," "might," or "may," unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps.

[0095] Terms and phrases used in this document, and variations thereof, unless otherwise expressly stated, should be construed as open ended as opposed to limiting. Adjectives such as "conventional," "traditional," "normal," "standard," "known," and terms of similar meaning should not be construed as limiting the item described to a given time period or to an item available as of a given time, but instead should be read to encompass conventional, traditional, normal, or standard technologies that may be available or known now or at any time in the future. The presence of broadening words and phrases such as "one or more," "at least," "but not limited to" or other like phrases in some instances shall not be read to mean that the narrower case is intended or required in instances where such broadening phrases may be absent.