WO2024151308A1

WO2024151308A1 - Protocol test framework with packet generator

Info

Publication number: WO2024151308A1
Application number: PCT/US2023/060507
Authority: WO
Inventors: Sheethal KOVOOR; Su-Lin Low; Hausting Hong; Sangwon Ki; Chun-I Lee
Original assignee: Zeku Inc
Current assignee: Zeku Inc
Priority date: 2023-01-11
Filing date: 2023-01-11
Publication date: 2024-07-18
Anticipated expiration: 2025-07-11

Abstract

The various implementations described herein include methods and systems for compressing and/or decompressing packets and evaluating protocol libraries. In one aspect, a method includes: (i) providing configuration information to a packet generator, (ii) generating, at the packet generator, one or more test vectors based on the configuration information, (iii) providing the one or more test vectors to a protocol library, (iv) receiving, via the protocol library, one or more output packets based on the one or more test vectors, and (v) evaluating the one or more output packets.

Description

PROTOCOL TEST FRAMEWORK WITH PACKET GENERATOR

TECHNICAL FIELD

[0001] The disclosed embodiments relate generally to methods and systems for packet compression and decompression, including but not limited to, systems and methods for generating packet test vectors via a packet generator.

BACKGROUND

[0002] Conventional robust header compression (ROHC) uses a large number of predefined fixed sequences of IP/UDP byte streams as test vectors input to test an ROHC protocol. However, the conventional ROHC test frameworks have a large memory footprint and operate on a host or a large main processor. Moreover, because the input test vector sequences are predefined and fixed, they cannot be flexibly adjusted. Additionally, the conventional ROHC test frameworks can require a large number of processor cycles and significant power consumption.

SUMMARY

[0003] The present disclosure describes test frameworks for methodical validation of compression and decompression protocol (e.g., ROHC protocol). In some embodiments, the test framework is implemented in a microprocessor. For example, a microprocessor for a packet data convergence protocol (PDCP) layer in a 5G/6G protocol stack. In some embodiments, a test framework includes a packet generator that covers different traffic flows, e.g., for testing multiple ROHC profiles used in 5G/6G VOIP and UDP traffic. In some embodiments, the traffic flows include real-time transport protocol (RTP), user datagram protocol (UDP), and/or internet protocol (IP) packets. At least some of the test frameworks described herein include configurable test coverage settings for maximizing test coverage, e.g., ensuring a robust and reliable ROHC protocol stack. Moreover, the test framework(s) described herein have a small memory footprint to test ROHC protocol in microprocessor setting.

[0004] Conversely, conventional ROHC test systems use sequences of IP/UDP byte streams as test vectors to test ROHC protocol. These systems are typically used in a host system setup for unit testing of ROHC libraries and cannot be used in a microcontroller setting because of the test system’s large memory footprint, the byte stream test vectors used in ROHC test framework requires large memory footprint, and is limited in coverage scope. Conventional ROHC test systems also cannot be collocated in a microcontroller image with the ROHC library and therefore cannot measure on-chip deployment performance of different ROHC libraries, which may utilize different hardware custom instructions to optimize compress and decompress cycles in a system-on-chip (SOC). In this way, conventional ROHC test systems have limited or no test coverage scope in a microprocessor SOC and limited or no performance analysis comparisons for different ROHC library versions in a microprocessor SOC.

[0005] In accordance with some embodiments, a method is performed at a computing device having memory and one or more processors. The method includes: (i) providing configuration information to a packet generator; (ii) generating, at the packet generator, one or more test vectors based on the configuration information; (iii) providing the one or more test vectors to a protocol library; (iv) receiving, via the protocol library, one or more output packets based on the one or more test vectors; and (v) evaluating the one or more output packets.

[0006] In accordance with some embodiments, a computing system (e.g., a user device or network node) includes one or more processors, memory, a display, and instructions stored in the memory. The instructions are configured for execution by the one or more processors. The instructions for performing any of the methods described herein (e.g., the methods 400 and 500).

[0007] In accordance with some embodiments, a non-transitory computer-readable storage medium stores instructions configured for execution by a computing system having one or more processors and memory. The instructions for performing any of the methods described herein (e.g., the methods 400 and 500).

[0008] Thus, methods and systems are disclosed for compressing and decompressing packets. Such methods and systems may complement or replace conventional methods and systems of packet compression and/or decompression.

[0009] The features and advantages described in the specification are not necessarily all inclusive and, in particular, some additional features and advantages will be apparent to one of ordinary skill in the art in view of the drawings, specification, and claims provided in this disclosure. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes and has not necessarily been selected to delineate or circumscribe the subject matter described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] So that the present disclosure can be understood in greater detail, a more particular description can be had by reference to the features of various embodiments, some of which are illustrated in the appended drawings. The appended drawings, however, merely illustrate pertinent features of the present disclosure and are therefore not to necessarily be considered limiting, for the description can admit to other effective features as the person of skill in this art will appreciate upon reading this disclosure.

[0011] Figures 1A-1B illustrate an example of packet transfer in accordance with some embodiments.

[0012] Figures 2A-2B illustrate examples of packet generation in accordance with some embodiments.

[0013] Figure 3 illustrates an example system for protocol library evaluation in accordance with some embodiments.

[0014] Figure 4 provides a flowchart of an example process for evaluating compression and/or decompression in accordance with some embodiments.

[0015] Figure 5 provides a flowchart of an example process for evaluating a protocol library in accordance with some embodiments.

[0016] In accordance with common practice, the various features illustrated in the drawings are not necessarily drawn to scale, and like reference numerals can be used to denote like features throughout the specification and figures.

DESCRIPTION OF EMBODIMENTS

[0017] In a 5G/6G protocol stack, the packet data convergence protocol (PDCP) layer handles robust header compression (ROHC) operations for ROHC-enabled radio bearers, e.g., for voice-over-IP (VOIP) and other user datagram protocol (UDP) related traffic. The radio bearer (RB) setup parameters can include ROHC channel parameters, such as supported ROHC profiles and maximum flows. The PDCP layer forwards these channel parameters to ROHC modules to setup the connection between the radio bearer identifier and an ROHC channel. As an example, in uplink, the real-time protocol (RTP) packets are forwarded to an ROHC library for header compression, e.g., as the first step in the PDCP layer processing. In downlink, after a channel is established with ROHC enabled, packets in the radio bearer are forwarded to an ROHC decompressor module to perform header decompression, e.g., as the last step of PDCP processing. The decompressed packets may then be routed to upper layers for further processing.

[0018] The present disclosure describes a low cost ROHC test framework that includes a flexible packet generator configured to test one or more ROHC protocol stacks (e.g., ROHC libraries) implemented in a microprocessor. In some embodiments, the test framework resides in the small memory footprint of the data memory and is configured to test the ROHC library within the context of microprocessor. In some embodiments, the test framework includes a configurable set of rules and parameters that are used to flexibly generate an ROHC test vector input stream for the ROHC library’s compressor and/or decompressor.

[0019] The test frameworks described herein can be implemented on a host computer, where the ROHC protocol stack under development can be tested with no constraints on memory and million instructions per second (MIPs). For these configurations, the test framework can take as inputs pre-defined sequences of test vectors as well, in addition to the configurable flexible packet generator sequences.

[0020] The test frameworks described herein can be used for End-to-End Systems Integration testing, e.g., by injecting ROHC test packets in the 5G/6G protocol dataplane system. For example, for uplink, IP, UDP, and/or RTP packets with flexible sequence, timestamps, and other patterns can be generated as test vectors and injected into the uplink protocol dataplane system at the PDCP layer. The test frameworks described herein can also be used for End-to-End Systems Integration testing by injecting ROHC test packets in the 5G/6G DL protocol dataplane system. For example, for the downlink, ROHC compressed packets with configurable CRC failures, delays, gaps, and other patterns can be generated as test vectors and injected into the downlink protocol dataplane system at the media access control (MAC) layer, which encapsulates the IP payload into the dataplane system.

[0021] An ROHC library used in 5G/6G protocol stack can be run in a microprocessor and be optimized with fast processing of critical paths in compression and decompression with custom instructions or hardware accelerators. The present disclosure describes a test framework usable to test one or more ROHC libraries in a microprocessor system-on-chip environment and compare different ROHC library versions implemented in the SOC. Some embodiments include multiple implementations of an ROHC library with varying levels of hardware acceleration and/or processor custom instructions. At least some of the test frameworks described herein comply with the small memory footprint of the microprocessor data memory and are configured to test the functionality and performance of different ROHC library implementation in the context of a microprocessor. In this way, the test framework(s) provide a versatile way to analyze performance of different ROHC implementations in a microprocessor.

[0022] Turning now to the figures, Figures 1A-1B illustrate an example of packet transfer in accordance with some embodiments. Figure 1A shows user equipment 102 in communication with a node 104. The user equipment 102 may be a telephone, mobile device, and/or personal computer. The node 104 may be a base station, server node, and/or network node. In accordance with some embodiments, the user equipment 102 includes a microprocessor 112-1. In accordance with some embodiments, the node 104 includes a microprocessor 112-2. In the example of Figure 1A, the user equipment 102 sends a packet 106-1 to the node 104. The packet 106-1 includes a header 108 and a payload 110-1. In some embodiments, the packet 106-1 is an IP, UDP, or RTP packet. In the example of Figure 1A, the header 108 is uncompressed (e.g., the packet 106-1 is a first packet in a transmission).

[0023] Figure IB shows the user equipment 102 transmitting a packet 106-2 to the node 104. The packet 106-2 includes a compressed header 114 and a payload 110-2. In some embodiments, the compressed header 114 has been compressed via an ROHC process. In some embodiments, the compressed header is compressed using the header 108 (e.g., a comparison between the header 108 and an uncompressed header for the packet 106-2). As an example, an uncompressed header (e.g., the header 108) may include more than 300 bits (e.g., 320 bits or 480 bits) and a compressed header (e.g., the compressed header 114) may include less than 20 bits (e.g., 8 bits or 16 bits). In some embodiments, the compression of the packet 106-2 is performed at the microprocessor 112-1. In some embodiments, the node 104 decompresses the compressed header 114 in accordance with receiving the packet 106-2. In some embodiments, the node 104 transmits one or more compressed packets to the user equipment 102 (e.g., packets compressed using the microprocessor 112-2).

[0024] Figures 2A-2B illustrate examples of packet generation in accordance with some embodiments. Figure 2A shows a microprocessor 112 including a test framework 204 and a protocol stack 210. In some embodiments, the microprocessor 112 in Figure 2A is a component of a host test computer. The test framework 204 includes a packet generator 206 and configuration data 208. In some embodiments, the configuration data 208 includes one or more rules for the packet generator 206. For example, the test framework 204 may be an ROHC test framework with a flexible packet generator with rules to create multiple compressor packet types. In some embodiments, the configuration data 208 includes one or more settings for the packet generator 206. In some embodiments, the protocol stack 210 includes one or more libraries for compression and/or decompression of packets. For example, the protocol stack may include an ROHC library.

[0025] In accordance with some embodiments, the test framework 204 sends one or more test vectors 212 and, in response, the protocol stack 210 generates one or more compressed packets 214. For example, the protocol stack 210 compresses headers of packets in the test vectors 212 to generate the compressed packets 214. In accordance with some embodiments, the test framework 204 sends one or more test vectors 216 and, in response, the protocol stack 210 generates one or more decompressed packets 218. For example, the protocol stack 210 decompresses headers of packets in the test vectors 216 to generate the decompressed packets 218.

[0026] In some embodiments, an input IP packet, UDP packet, and/or RTP packet is provided as a starter packet in the test framework 204 to generate streams with different traffic patterns. In some embodiments, the rules include generic rules to generate traffic patterns to test different dynamic parameters of the test framework 204. In some embodiments, the rules include specific rules are used to test traffic patterns to cover testing for different packet types, in different modes and states of the ROHC compressor and/or decompressor in the library. In this way, the test framework 204 generates sequence(s) of packets based on the rules provided by the configuration data 208.

[0027] In some embodiments, the information provided by the configuration data 208 include one or more of the following: a radio bearer identifier (e.g., channel ID for ROHC library), an IP version (e.g., IPv4 or IPv6), an input (starter) packet, an input packet length, and a number of packets to be generated. In some embodiments, the input packet is the latest generated packet that was input to the protocol stack 210. In some embodiments, the test framework 204, after generating the set number of packets (e.g., with a fixed pattern), accepts another set of rules for a subsequent number of packets. In this way, a single test case can have multiple set of rules, each set of rules for a specific number of packets.

[0028] In some embodiments, the configuration data 208 includes one or more RTP compressed sequence number (SN) packet generation rules. In some embodiments, the RTP SN packet generation rules include an SN generation pattern. In various embodiments, the SN generation pattern is sequential or incremented by a fixed value. In some embodiments where the SN generation pattern is incremented by a fixed value, the RTP SN packet generation rules include an SN increment value. In some embodiments, the RTP SN packet generation rules include a default pattern continue count. For example, if the SN generation pattern is incremental, the default pattern continue count may be the number of packets after increment. In some embodiments, the RTP SN pattern is incremented sequentially as a default setting. In some embodiments, if the default pattern continue count value is zero, then packet generation is incremented by the SN increment value.

[0029] In some embodiments, the configuration data 208 includes one or more IPv4 packet generation rules. In some embodiments, the IPv4 packet generation rules include an IP ID generation pattern. In various embodiments, the IP ID generation pattern is sequential, incremented by a random value, or incremented by the fixed value. In some embodiments where the IP ID generation pattern is incremental, the IPv4 packet generation rules include an IP ID increment value. In some embodiments, the IPv4 packet generation rules include a default pattern continue count. In some embodiments where the IP ID generation pattern is incremental, the default pattern continue count is a number of packets after increment. In some embodiments, if the default pattern continue count value is zero, then packet generation is incremented by the IP ID increment value.

[0030] In some embodiments, the configuration data 208 includes one or more RTP timestamp (TS) packet generation rules. In some embodiments, the RTP TS packet generation rules include an RTP TS generation pattern. In various embodiments, the RTP TS generation pattern is TS SCALED incremented sequentially or TS SCALED incremented by a fixed value. In some embodiments, the RTP timestamp is calculated using Equation 1 below.

RTP Timestamp = TS_SCALED * TS_STRIDE + TS₀^_set

Equation 1 : RTP timestamp calculation

[0031] In some embodiments, the RTP TS packet generation rules include a TS STRIDE value. In some embodiments, the RTP TS packet generation rules include a TS SCALED increment value (e.g., if TS SCALED generation pattern is set to incremental). In some embodiments, the RTP TS packet generation rules include a default pattern continue count. In some embodiments where the RTP TS generation pattern is incremental, the default pattern continue count is a number of packets after increment. In some embodiments, if the default pattern continue count value is zero, then packet generation is incremented by the TS SCALED increment value.

[0032] In some embodiments, the configuration data 208 includes a setting for an ROHC preferred mode. For example, changing the ROHC preferred mode value to dynamically change a preferred mode setting in a ROHC decompressor library to test mode transitions (e.g., between reliable mode, optimistic mode, and unidirectional mode).

[0033] In some embodiments, the configuration data 208 includes a setting for a CRC error interval. For example, a setting to inject a CRC error to the compressed packet at the output of a compressor of the Test framework, e.g., to simulate residual error in link error and trigger different feedback and mode changes. In some embodiments, a CRC error is introduced before the compressed packet is forwarded to a decompressor of the protocol stack 210 (e.g., an ROHC library). In some embodiments, the CRC errors are introduced at a rate of one erroneously compressed packet per set interval.

[0034] In some embodiments, the configuration data 208 includes a setting for a packet drop interval. For example, a setting for the test framework 204 to drop packets at an output of a compressor (e.g., to simulate packet loss in an underlying link). In some embodiments, the packet drop interval setting is used to test various mode and state transitions in a compressor and/or a decompressor as well as packet repair and feedback mechanisms.

[0035] In some embodiments, the configuration data 208 includes a feedback delay count setting. For example, if the feedback delay count setting is nonzero, feedback generated by a decompressor is delayed by a number of input packets (specified by the feedback delay count setting) to the compressor. In some embodiments, the feedback delay count is used to test feedback loss in real links and delay acknowledgements of context synchronization between the compressor and the decompressor.

[0036] Figure 2B shows a system 202 including the microprocessor 112 and a dataplane 220. In some embodiments, the dataplane 220 is a 5G and/or 6G dataplane. In accordance with some embodiments, the dataplane 220 includes a packet data convergence protocol (PDCP) layer 222, a radio link control (RLC) layer 224, and a media access control (MAC) layer 226. The dataplane 220 sends setup information 228 to the test framework 204. In some embodiments, the configuration data 208 is adjusted based on the setup information 228. In some embodiments, at least a portion of the previous configuration data 208 is overwritten with the setup information 228. The test framework 204 sends one or more test vectors 230 to the dataplane 220 in accordance with the setup information 228. In some embodiments, the test vectors 230 include one or more uplink IP packets. In some embodiments, the test vectors 230 include one or more downlink ROHC packets (e.g., with failed CRCs, delay patterns, and the like). In some embodiments, the test vectors 230 include one or more IP, UDP, and/or RTP packets with flexible sequence, timestamps, and other patterns. In some embodiments, the test vectors 230 are injected into an uplink protocol dataplane system at the PDCP layer 222. In some embodiments, for downlink, the test vectors 230 include compressed packets (e.g., ROHC compressed packets) with configurable CRC failures, delays, gaps, and other patterns and are injected into the downlink protocol dataplane system, e.g., at the MAC layer, which encapsulates the IP payload into the dataplane system. The PDCP layer 222 transmits a request 232 to the protocol stack 210, e.g., in accordance with the test vectors 230. In some embodiments, the request 232 is an ROHC compression or decompression request. The protocol stack 210 generates and transmits a response 234 in response to the request 232. For example, in response to a compression request, the protocol stack 210 generates a set of compressed packets (e.g., compresses packets from the test vectors 230). As another example, in response to a decompression request, the protocol stack 210 generates a set of decompressed packets (e.g., decompresses packets from the test vectors 230). In this way, the test framework 204 can be used for end-to-end systems integration testing.

[0037] Figure 3 illustrates a system 300 for protocol library evaluation in accordance with some embodiments. The system 300 includes the PDCP layer 222 in communication with the microprocessor 112. The microprocessor 112 in Figure 3 includes a library interface 302 communicatively coupled to the PDCP layer 222. The microprocessor 112 in Figure 3 further includes the test framework 204 and a set of protocol libraries 306 (e.g., protocol libraries 306- 1 through 306-n) coupled to the library interface 302. For example, the test framework 204 generates test vectors for individual protocol libraries 306 and the protocol libraries 306 generate compressed and/or decompressed packets based on the test vectors. The packets from the protocol libraries 306 can be evaluated by the PDCP layer 222 (e.g., for errors, latency, and the like). Based on the evaluation, the protocol libraries 306 can be ranked and a highest performing protocol library can be selected for subsequent use.

[0038] In some embodiments, the test framework 204 in the microprocessor 112 interfaces with a protocol library 306 that supports compression for uplink and decompression for a downlink ROHC-enabled radio bearer using the library interface 302. In some embodiments, the test framework 204 includes a packet generator (e.g., the packet generator 206) for RTP, UDP, and/or IP packet generation. As an example, an RTP sequence number generation rule can be defined as default behavior and the test framework 204 will generate a sequence of RTP packets with incremental RTP SN number, RTP TS Stride and IP Identifier (e.g., if the RTP packet uses IPv4) to feed as test input vectors into the protocol library 306 under test.

[0039] Conversely, a conventional ROHC tester stores a large database of pre-defined uplink IP sequences, and downlink ROHC compressed packet sequences, which are used for injecting into the ROHC library under test. These sequences occupy a large memory footprint, and are also fixed and limited in test coverage scope. Thus, many conventional ROHC testers are required to execute on a host PC platform, with fixed sequences of ROHC test vectors occupying a large memory footprint. Therefore, conventional ROHC testers do not provide performance analysis platforms for comparing real-time ROHC performance parameters of multiple ROHC libraries.

[0040] In some embodiments, the system 300 is a component of a host PC or emulator environment. In accordance with some embodiments, the system 300 comprises an ROHC test system in a microprocessor setting. For example, the system 300 can provide a common test interface to test ROHC protocol in a microprocessor setting with multiple versions of hardware customized instructions. The system 300 allows for inclusion and testing of multiple libraries 306 (e.g., ROHC libraries) with the library interface 302 (e.g., including a standard test API) for performance evaluation of the different libraries. In this way, the system 300 allows for comparison of performance metrics and analysis for several versions of ROHC implementations on-chip, including ROHC libraries with custom instructions. For example, the system 300 can be used to evaluate different ROHC library implementations based on test output criteria in a production-like test environment. In some embodiments, each protocol library 306 includes hardware custom instructions. In some embodiments, the custom instructions in the microprocessor execute in a C model in an emulator environment.

[0041] In some embodiments, each protocol library 306 is a distinct ROHC library version. In some embodiments, the protocol libraries 306 operate concurrently in the system 300. In this way, performance metrics can be collected concurrently, and the performance analysis can be compared on-the-fly.

[0042] Thus, the test frameworks described herein reduce or minimize processing cycles and a memory footprint to be included as part of a microcontroller executable. For example, to generate silent period RTP packets in VOIP and test UOR type 2 compressed packets with extension 3, RTP timestamp packet generation rules can be used with TS SCALED incremented by the fixed value, TS STRIDE set to silent period sampling, and a default pattern continue count set to the duration of silent period. To get back from silent period, the set of rules can be changed back by setting the RTP Timestamp Packet generation rule as default, with a different TS STRIDE.

[0043] Figure 4 provides a flowchart of a method 400 for evaluating compression and/or decompression in accordance with some embodiments. The method 400 is performed at a computing system having one or more processors (e.g., the microprocessor 112) and memory. In some embodiments, the computing system is the user equipment 102 and/or the node 104. In some embodiments, the memory stores one or more instructions configured for execution by the one or more processors.

[0044] The computing system provides (402) configuration information to a packet generator (e.g., the packet generator 206). In some embodiments, the configuration information includes a starter packet. In some embodiments, the configuration information includes one or more of: a channel identifier, an Internet Protocol (IP) version, an input packet length, a number of packets to generate, an error rate, and a packet drop rate. In some embodiments, the configuration information includes one or more packet generation rules. In some embodiments, the one or more packet generation rules includes one or more real-time transport protocol (RTP) rules and one or more Internet Protocol (IP) rules. In some embodiments, the configuration information includes a Robust Header Compression (ROHC) mode indicator. In some embodiments, the configuration information includes a feedback delay parameter. In some embodiments, the configuration information is received from a dataplane. In some embodiments, the computing system includes a test framework (e.g., the test framework 204) that includes the packet generator and configuration data for the packet generator (e.g., configuration data 208). In some embodiments, the packet generator includes a compressor and/or a decompressor.

[0045] The computing system generates (404), at the packet generator, one or more test vectors (e.g., the test vectors 216 or 230) based on the configuration information. In some embodiments, the packet generator is configurable for RTP, IP, and user datagram protocol (UDP) packet generation. In some embodiments, the packet generator is implemented in a microprocessor. In some embodiments, the packet generator generators one or more IP, UDP, and/or RTP packets based on a starter packet and an ROHC profile (defined based on the configuration information). In some embodiments, the packet generator generates an IP, UDP, or RTP packet based on a previous packet.

[0046] The computing system provides (406) the one or more test vectors to a protocol library (e.g., the protocol stack 210). In some embodiments, the protocol library includes a packet compressor, and the one or more output packets include compressed data. In some embodiments, the protocol library includes a packet decompressor, and the one or more output packets include decompressed data. In some embodiments, the computing system provides one or more control messages (e.g., defined by a user) to the protocol library (e.g., an ROHC library). In some embodiments, the protocol library includes a compressor and/or a decompressor. In some embodiments, the control messages are sent to the compressor and/or the decompressor of the protocol library (e.g., to setup uplink and downlink radio bearers with ROHC enabled as two ends of the same channel). In some embodiments, the packet(s) from the packet generator are sent to a compressor of the protocol library.

[0047] The computing system receives (408), via the protocol library, one or more output packets (e.g., the compressed packets 214 or the decompressed packets 218) based on the one or more test vectors. In some embodiments, the protocol library receives one or more compressed packets and decompresses the compressed packets to generate one or more decompressed packets. In some embodiments, the protocol library receives one or more uncompressed packets and compresses the uncompressed packets to generate one or more compressed packets. In some embodiments, if compression of a test packet is determined to be successful, the compressed packet is transmitted to a decompressor (optionally with CRC errors and/or packet drop errors introduced). In some embodiments, feedback is generated by the decompressor and optionally transmitted to the compressor. In some embodiments, if the decompression is determined to be successful, the decompressed packet is compared with the initial test packet to determine an accuracy/correctness of the protocol library.

[0048] The computing system evaluates (410) the one or more output packets. In some embodiments, the evaluation includes determining a type and correctness of the output packets. In some embodiments, the evaluation includes determining a correctness of multiple output packet types. In some embodiments, the evaluation includes determining a correctness of mode and/or state transitions (e.g., based on error packets and/or link layer residual errors). In some embodiments, the evaluation includes one or more performance parameters (e.g., compression efficiency, processor cycles, amount of custom instruction memory used, and the like).

[0049] In some embodiments, the computing system validates (412) the protocol library based on the evaluation of the one or more output packets. For example, the computing system determines whether to utilize the protocol library for subsequent compression/decompression operations based on whether the evaluation meets one or more predefined criteria. In some embodiments, the computing system evaluates a plurality of protocol libraries (e.g., the protocol libraries 306) and selects a protocol library (e.g., the protocol library 306-1) based on the respective evaluations.

[0050] Figure 5 provides a flowchart of a method 500 for evaluating a protocol library in accordance with some embodiments. The method 500 is performed at a computing system having one or more processors (e.g., the microprocessor 112) and memory. In some embodiments, the computing system is the user equipment 102 and/or the node 104. In some embodiments, the memory stores one or more instructions configured for execution by the one or more processors.

[0051] The computing system provides (502) a first plurality of packets to a first protocol library (e.g., the protocol library 306-1) implemented on a microprocessor. For example, the test framework 204 in Figure 3 provides test packets to the protocol library 306- 1 via the library interface 302. In some embodiments, the computing system provides one or more control messages to a compressor and/or decompressor of the protocol library (e.g., to setup uplink and downlink radio bearers with ROHC enabled as two ends of a same channel). In some embodiments, the system generates the first plurality of packets using a test framework (e.g., the test framework 204). In some embodiments, the test framework generates the first plurality of packets based on an ROHC profile and the first plurality of packets include one or more IP, UDP, RTP packets, and/or ROHC packets. In some embodiments, the first plurality of packets are injected into the active protocol library stack (e.g., are injected into the first protocol library stack).

[0052] The computing system generates (504), via the first protocol library, a first plurality of output packets corresponding to the first plurality of packets. For example, the protocol library 306-1 receives one or more compressed test packets and decompresses the compressed test packets to generate one or more output packets. In some embodiments, the protocol library receives one or more uncompressed test packets and compresses the uncompressed test packets to generate one or more output packets. In some embodiments, the output packets from each active protocol library are collected/stored and analyzed.

[0053] The computing system determines (506) one or more performance metrics for the first protocol library based on the generation of the first plurality of output packets. In some embodiments, the computing system performs an evaluation of the first protocol library (e.g., as described above with respect to operation 410 of Figure 4). In some embodiments, the one or more performance metrics include one or more of: a compression efficiency, a number of processor cycles used, an amount of custom instruction memory used, and a count of packets where custom instruction blocks were utilized. In some embodiments, after a protocol library completes processing of the first plurality of packets (e.g., completes generation of the first plurality of output packets), ROHC performance statistics are calculated. In some embodiments, the ROHC performance statistics include one or more of: decompression success rate, compressor efficiency, and decompressor feedback Nack and Ack counts. In some embodiments, after a protocol library completes processing of the first plurality of packets, system performance statistics are calculated. In some embodiments, the system performance statistics include one or more of: processor (e.g., CPU) cycles for compression, processor cycles for decompression, custom instruction execution counts, and custom instruction memory sync counts.

[0054] The computing system determines (508) one or more quality metrics for the first plurality of output packets. In some embodiments, the one or more quality metrics include a correctness of multiple output packet types. In some embodiments, the one or more quality metrics include a correctness of mode and/or state transitions (e.g., based on error packets and/or link layer residual errors). In some embodiments, after a protocol library completes processing of the first plurality of packets, ROHC function test statistics are calculated. In some embodiments, the ROHC function test statistics include one or more of: type(s) of packets processed, compressor mode and/or state transition types and counts, and decompressor mode and/or state transition types and counts.

[0055] The computing system generates (510) an assessment of the first protocol library based on the one or more performance metrics and the one or more quality metrics. In some embodiments, the assessment includes a test report (e.g., with test case status and performance analysis of compared protocol libraries). In some embodiments, the assessment includes a performance score, a quality score, and/or a combined score. For example, the assessment of each protocol library can be compared across multiple ROHC implementations.

[0056] In some embodiments, the computing system provides (512) a second plurality of packets to a second protocol library (e.g., the protocol library 306-2) implemented on the microprocessor. In some embodiments, the computing system generates (514), via the second protocol library, a second plurality of output packets corresponding to the second plurality of packets. In some embodiments, the computing system generates (516) an assessment of the second protocol library based on one or more performance metrics and one or more quality metrics for the second protocol library. In some embodiments, the computing system performs an evaluation of the second protocol library (e.g., as described above with respect to operation 410 of Figure 4). In some embodiments, the computing system ranks (518) the first protocol library and the second protocol library in accordance with the respective assessments. In some embodiments, the computing system selects a highest ranked protocol library for use with subsequent compression and/or decompression operations. In some embodiments, the computing system sets the highest ranked protocol library as a default protocol library for subsequent operations.

[0057] Turning now to some example embodiments.

[0058] (Al) In one aspect, some embodiments include a method (e.g., the method 400) for evaluating header compression and/or decompression. The method is performed at a computing system (e.g., the user equipment 102 and/or the node 104) having memory and one or more processors (e.g., the microprocessor 112). The method includes: (i) providing configuration information (e.g., the configuration data 208) to a packet generator (e.g., the packet generator 206); (ii) generating, at the packet generator, one or more test vectors (e.g., the test vectors 212, 216, or 230) based on the configuration information; (iii) providing the one or more test vectors to a protocol library (e.g., the protocol stack 210 or a protocol library 306); (iv) receiving, via the protocol library, one or more output packets (e.g., the compressed packets 214 or the decompressed packets 218) based on the one or more test vectors; and (v) evaluating the one or more output packets. For example, the packet generator is used in a packet data convergence protocol (PDCP) layer for radio communications (e.g., 3GPP-based communications) .

[0059] (A2) In some embodiments of Al, the protocol library includes a packet compressor, and the one or more output packets include compressed data. For example, the protocol library is a robust header compression (ROHC) library. As another example, the protocol library handles compression and/or decompression for voice over internet protocol (VOIP) and/or UDP transmissions.

[0060] (A3) In some embodiments of Al or A2, the protocol library includes a packet decompressor, and the one or more output packets include decompressed data.

[0061] (A4) In some embodiments of any of A1-A3, the configuration information includes a starter packet.

[0062] (A5) In some embodiments of any of A1-A4, the configuration information includes one or more of: a channel identifier, an Internet Protocol (IP) version, an input packet length, a number of packets to generate, an error rate, and a packet drop rate. For example, the channel identifier may be a channel identifier for an ROHC library. As another example, the IP version may be IPv4 or IPv6.

[0063] (A6) In some embodiments of any of A1-A5, the configuration information includes one or more packet generation rules.

[0064] (A7) In some embodiments of A6, the one or more packet generation rules includes one or more real-time transport protocol (RTP) rules and one or more Internet Protocol (IP) rules. For example, the IP rules include IPv4 rules. In some embodiments, the IP rules include information regarding pattern generation (e.g., sequential, incremental, or random). For example, the IP rules include an increment value if the generation pattern is incremental. In some embodiments, the IP rules include a pattern continue count.

[0065] (A8) In some embodiments of any of A1-A7, the configuration information includes a robust header compression (ROHC) mode indicator. For example, the configuration information includes a value to change between a reliable mode, an optimistic mode, and a unidirectional mode.

[0066] (A9) In some embodiments of any of A1-A8, the configuration information includes a feedback delay parameter. For example, if the feedback delay parameter is nonzero, feedback generated by a decompressor is delayed by a number of input packets to compressor. This may be used to test feedback loss in real links and delay acknowledgements of context synchronization between compressor and decompressor.

[0067] (A 10) In some embodiments of any of A1-A9, the packet generator is configurable for RTP, IP, and user datagram protocol (UDP) packet generation. [0068] (All) In some embodiments of any of A1-A10, the packet generator is implemented in a microprocessor (e.g., the microprocessor 112).

[0069] (A 12) In some embodiments of any of Al-Al 1, the configuration information is received from a dataplane (e.g., a 5G/6G dataplane), e.g., the dataplane 220.

[0070] (Bl) In another aspect, some embodiments include a method (e.g., the method 500) of compressing and/or decompressing packets. The method is performed at a computing system (e.g., the user equipment 102 and/or the node 104) having memory and one or more processors (e.g., the microprocessor 112). The method includes: (i) providing a first plurality of packets to a first protocol library (e.g., the protocol library 306-1) implemented on a microprocessor (e.g., the microprocessor 112); (ii) generating, via the first protocol library, a first plurality of output packets corresponding to the first plurality of packets; (iii) determining one or more performance metrics for the first protocol library based on the generation of the first plurality of output packets; (iv) determining one or more quality metrics for the first plurality of output packets; and (v) generating an assessment of the first protocol library based on the one or more performance metrics and the one or more quality metrics.

[0071] (B2) In some embodiments of Bl, the method further includes: (i) providing a second plurality of packets to a second protocol library (e.g., the protocol library 306-2) implemented on the microprocessor; (ii) generating, via the second protocol library, a second plurality of output packets corresponding to the second plurality of packets; (iii) generating an assessment of the second protocol library based on one or more performance metrics and one or more quality metrics for the second protocol library; and (iv) ranking the first protocol library and the second protocol library in accordance with the respective assessments. In some embodiments, each protocol library corresponds to a respective set of hardware customized instructions.

[0072] (B3) In some embodiments of B2, providing the first plurality of packets to the first protocol library is concurrent with providing the second plurality of packets to the second protocol library. In some embodiments, a same plurality of packets is provided to the first and second protocol libraries. In some embodiments, generating the assessment of the first protocol library is concurrent with generating the assessment of the second protocol library.

[0073] (B4) In some embodiments of any of B1-B3, the one or more performance metrics include one or more of: a count of processor cycles, a count of custom instruction executions, and a count of custom instruction memory synchronizations. For example, the count of processor cycles are a count of processor cycles for packet compression and/or packet decompression.

[0074] (B5) In some embodiments of any of B1-B4, the one or more quality metrics include one or more of: a decompression success rate, a compressor efficiency, and decompressor feedback. For example, the decompressor feedback includes a count of Nack and/or Ack messages.

[0075] (B6) In some embodiments of any of B1-B5, the plurality of packets include robust header compression (ROHC) packets.

[0076] (B7) In some embodiments of any of B1-B6, the method further includes determining one or more packet metrics, including one or more of: respective packet types, mode transitions, and state transitions. For example, the mode and/or state transitions include compressor mode/state transition types and count and/or decompressor mode/state transition types and count.

[0077] (B8) In some embodiments of any of B1-B7, the method further includes providing configuration information to a packet generator; and the first plurality of packets are generated at the packet generator based on the configuration information. In some embodiments, the packet generator is implemented at the microprocessor.

[0078] (B9) In some embodiments of any of B2-B8, the first plurality of packets and the second plurality of packets have same respective types and payloads.

[0079] (B10) In some embodiments of any of B1-B9, the method further includes setting the first protocol library as an active library for the microprocessor in accordance with the assessment.

[0080] (Bl 1) In some embodiments of any of Bl -B10, the first protocol library is configured to compress and/or decompress incoming packets. For example, the protocol libraries are adapted to compress and/or decompress packet headers.

[0081] In another aspect, some embodiments include a computing system including one or more processors and memory coupled to the one or more processors, the memory storing one or more programs configured to be executed by the one or more processors, the one or more programs including instructions for performing any of the methods described herein (e.g., the methods 400 and 500 and A1-A12 and Bl-Bl l). The compression and decompression methods and systems described herein can be applied to a variety of wireless communication technologies (e.g., 3GPP and 3GPP2 standards as well as Bluetooth and Wi-Fi protocols).

[0082] In yet another aspect, some embodiments include a non-transitory computer- readable storage medium storing one or more programs for execution by one or more processors of a computing system, the one or more programs including instructions for performing any of the methods described herein (e.g., the methods 400 and 500 and A1-A12 and Bl-Bl l).

[0083] The terminology used in the description of the invention herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in the description of the invention and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and/or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and/or groups thereof.

[0084] The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated.

Claims

What is claimed is:

1. A method of evaluating header compression and/or decompression, comprising: providing configuration information to a packet generator; generating, at the packet generator, one or more test vectors based on the configuration information; providing the one or more test vectors to a protocol library; receiving, via the protocol library, one or more output packets based on the one or more test vectors; and evaluating the one or more output packets.

2. The method of claim 1, wherein the protocol library comprises a packet compressor, and wherein the one or more output packets comprise compressed data.

3. The method of claim 1 , wherein the protocol library comprises a packet decompressor, and wherein the one or more output packets comprise decompressed data.

4. The method of claim 1, wherein the configuration information includes a starter packet.

5. The method of claim 1, wherein the configuration information includes one or more of: a channel identifier, an Internet Protocol (IP) version, an input packet length, a number of packets to generate, an error rate, and a packet drop rate.

6. The method of claim 1, wherein the configuration information includes one or more packet generation rules.

7. The method of claim 6, wherein the one or more packet generation rules includes one or more real-time transport protocol (RTP) rules and one or more Internet Protocol (IP) rules.

8. The method of claim 1 , wherein the configuration information includes a Robust Header Compression (ROHC) mode indicator.

9. The method of claim 1, wherein the configuration information includes a feedback delay parameter.

10. The method of claim 1, wherein the packet generator is configurable for RTP, IP, and user datagram protocol (UDP) packet generation.

11. The method of claim 1 , wherein the packet generator is implemented in a microprocessor.

12. The method of claim 1, wherein the configuration information is received from a dataplane.

13. The method of claim 1, further comprising validating the protocol library based on the evaluation of the one or more output packets.

14. A computing device, comprising: one or more processors; memory; and a plurality of instructions stored in the memory and configured for execution by the one or more processors, the plurality of instructions comprising instructions to perform the method of any of claims 1-13.

15. A non-transitory computer-readable storage medium including a plurality of instructions that when executed by a computing system having one or more processors, and memory, cause the computing system to perform the method of any of claims 1-13.