Ethernet header compression technology in new radio

Abstract

This disclosure includes a method at a device configured to process both wireless data traffic and Ethernet data traffic as wireless communication, the method comprising: determining at a compressor whether an acknowledgment (ACK) signal has been received from a decompressor in response to transmitting a context creation message via a wireless communication link for a context identifier (ID) associated with a stream of incoming Ethernet data traffic; suppressing transmission of compressed packets corresponding to the stream from the compressor to the decompressor via the wireless communication link based on a first determination that no ACK signal has been received from the decompressor; and allowing transmission of compressed packets corresponding to the stream from the compressor to the decompressor via the wireless communication link based on a second determination that an ACK signal has been received from the decompressor.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 914,239, filed on October 11, 2019, entitled “ETHERNET HEADER COMPRESSION TECHNIQUES IN NEW RADIO,” and U.S. Patent Application No. 17 / 065,890, filed on October 8, 2020, entitled “ETHERNET HEADER COMPRESSION TECHNIQUES IN NEW RADIO,” and both applications are assigned to the assignee of this application and are expressly incorporated herein by reference.

[0003] Public domain

[0004] Aspects of the present disclosure relate generally to wireless communications, and more particularly to techniques and apparatus for Ethernet header technology in new radios.

[0005] background

[0006] Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, and broadcasting. Typical wireless communication systems may employ multiple access technologies that can support communication with multiple users by sharing available system resources (e.g., bandwidth, transmit power, etc.). Examples of such multiple access technologies include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single carrier frequency division multiple access (SC-FDMA) systems, time division synchronous code division multiple access (TD-SCDMA) systems, and long term evolution (LTE). LTE / LTE-Advanced is a set of enhancements to the Universal Mobile Telecommunications System (UMTS) mobile standard promulgated by the Third Generation Partnership Project (3GPP).

[0007] A wireless communication network may include several base stations (BS) that can support communication of several user equipments (UEs). User equipments (UEs) may communicate with base stations (BSs) via downlinks and uplinks. Downlinks (or forward links) refer to the communication link from a BS to a UE, while uplinks (or reverse links) refer to the communication link from a UE to a BS. As will be described in more detail herein, a BS may be referred to as a Node B, gNB, Access Point (AP), Radio Head, Transmit Receiving Point (TRP), New Radio (NR) BS, 5G Node B, and the like.

[0008] The above multiple access technologies have been adopted in various telecommunication standards to provide common protocols that enable different user equipment to communicate at city, country, region, and even global levels. New Radio (NR) (which may also be referred to as 5G) is an enhancement set to the LTE mobile standard promulgated by the Third Generation Partnership Project (3GPP). NR is designed to better support mobile broadband Internet access by improving spectrum efficiency, reducing costs, improving services, utilizing new spectrum, and using orthogonal frequency division multiplexing (OFDM) (CP-OFDM) with cyclic prefix (CP) on the downlink (DL), using CP-OFDM and / or SC-FDM (e.g., also referred to as discrete Fourier transform spread OFDM (DFT-s-OFDM)) on the uplink (UL), and supporting beamforming, multiple input multiple output (MIMO) antenna technology and carrier aggregation to better integrate with other open standards. However, as the demand for mobile broadband access continues to grow, there is a need for further improvements in LTE and NR technologies. Preferably, these improvements should be applicable to other multiple access technologies and telecommunication standards that employ these technologies.

[0009] Overview

[0010] In some aspects, a communication method performed by a transmitter may include determining that a context identifier is to be modified, the context identifier corresponding to an Ethernet packet header value, and transmitting a context delete message identifying the context identifier to a receiver.

[0011] In some aspects, a method at a device configured to process both wireless data traffic and Ethernet data traffic into wireless communications includes: determining at a compressor whether an acknowledgement (ACK) signal is received from a decompressor in response to transmitting, over a wireless communication link, a context creation message for a context identification (ID) associated with a stream of incoming Ethernet data traffic; suppressing, by the compressor, transmitting, to the decompressor, over the wireless communication link, compressed packets corresponding to the stream based on a first determination that the ACK signal was not received from the decompressor; and transmitting, by the compressor, to the decompressor, over the wireless communication link, compressed packets corresponding to the stream based on a second determination that the ACK signal was received from the decompressor.

[0012] In some aspects, a transmitter or receiver configured to process both wireless data traffic and Ethernet data traffic into wireless communications may include a memory and one or more processors coupled to the memory. The memory and the one or more processors may be configured to: determine at a compressor whether an ACK signal is received from a decompressor in response to transmitting a context creation message for a context ID associated with a flow of incoming Ethernet data traffic over a wireless communication link; refrain from transmitting a compressed packet corresponding to the flow to the decompressor by the compressor over the wireless communication link based on a first determination that an ACK signal was not received from the decompressor; and transmit a compressed packet corresponding to the flow to the decompressor by the compressor over the wireless communication link based on a second determination that an ACK signal was received from the decompressor.

[0013] In some aspects, a non-transitory computer-readable medium may store one or more instructions for communication. The one or more instructions, when executed by one or more processors of a transmitter or a receiver, may cause the one or more processors to: determine at a compressor whether an ACK signal is received from a decompressor in response to transmitting a context creation message for a context ID associated with a flow of incoming Ethernet data traffic over a wireless communication link; refrain from transmitting a compressed packet corresponding to the flow to the decompressor by the compressor over the wireless communication link based on a first determination that an ACK signal was not received from the decompressor; and transmit a compressed packet corresponding to the flow to the decompressor by the compressor over the wireless communication link based on a second determination that an ACK signal was received from the decompressor.

[0014] In some aspects, an apparatus for communication may include: means for determining at a compressor whether an ACK signal is received from a decompressor in response to transmitting a context creation message for a context ID associated with a flow of incoming Ethernet data traffic over a wireless communication link; means for suppressing transmission by the compressor of compressed packets corresponding to the flow to the decompressor over the wireless communication link based on a first determination that the ACK signal was not received from the decompressor; and means for transmitting by the compressor of compressed packets corresponding to the flow to the decompressor over the wireless communication link based on a second determination that the ACK signal was received from the decompressor.

[0015] Additionally disclosed is a method at a device configured to handle wireless communications of both wireless data traffic and Ethernet data traffic, comprising: receiving, by a decompressor, one or more compressed packets associated with a context identifier (ID) of a stream corresponding to incoming Ethernet data traffic from a compressor and over a wireless communication link; determining, by the decompressor, whether a context creation message associated with the context ID is received from the compressor; and discarding, by the decompressor, the one or more compressed packets based on a determination that a context creation message associated with the context ID is not received from the compressor.

[0016] In some aspects, a transmitter or receiver for communication may include a memory and one or more processors coupled to the memory. The memory and the one or more processors may be configured to: receive, by a decompressor, one or more compressed packets associated with an ID of a flow corresponding to incoming Ethernet data traffic from a compressor and over a wireless communication link; determine, by the decompressor, whether a context creation message associated with the context ID is received from the compressor; and discard, by the decompressor, the one or more compressed packets based on a determination that a context creation message associated with the context ID is not received from the compressor.

[0017] In some aspects, a non-transitory computer-readable medium may store one or more instructions for communication. The one or more instructions, when executed by one or more processors of a transmitter or a receiver, may cause the one or more processors to: receive, by a decompressor, one or more compressed packets associated with an ID of a flow corresponding to incoming Ethernet data traffic from a compressor and over a wireless communication link; determine, by the decompressor, whether a context creation message associated with the context ID is received from the compressor; and discard, by the decompressor, the one or more compressed packets based on a determination that a context creation message associated with the context ID is not received from the compressor.

[0018] In some aspects, an apparatus for communication may include: means for receiving, by a decompressor, one or more compressed packets associated with an ID of a flow corresponding to incoming Ethernet data traffic from a compressor and over a wireless communication link; means for determining, by the decompressor, whether a context creation message associated with the context ID is received from the compressor; and means for discarding, by the decompressor, the one or more compressed packets based on a determination that a context creation message associated with the context ID is not received from the compressor.

[0019] Aspects generally include methods, apparatuses, systems, computer program products, non-transitory computer-readable media, user equipment, base stations, wireless communication devices, and processing systems as substantially described herein with reference to and as illustrated in the accompanying drawings and specification.

[0020] The foregoing has broadly outlined the features and technical advantages of examples according to the present disclosure in an effort to make the following detailed description better understood. Additional features and advantages will be described hereinafter. The disclosed concepts and specific examples can be easily used as a basis for modifying or designing other structures for implementing the same purpose as the present disclosure. Such equivalent constructions do not depart from the scope of the appended claims. The characteristics of the concepts disclosed herein, both in terms of their organization and method of operation, and the associated advantages will be better understood by considering the following description in conjunction with the accompanying drawings. Each of the accompanying drawings is provided for illustration and description purposes and does not define limitations on the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to understand in detail the manner in which the above-stated features of the present disclosure are used, the above briefly summarized content may be described in more detail with reference to various aspects, some of which are illustrated in the accompanying drawings. However, it should be noted that the accompanying drawings illustrate only certain typical aspects of the present disclosure and should not be considered to limit its scope, as the description may allow for other equally effective aspects. The same reference numerals in different drawings may identify the same or similar elements.

[0023] Figure 1 is a block diagram conceptually illustrating an example of a wireless communication network in accordance with various aspects of the present disclosure.

[0024] Figure 2 is a block diagram conceptually illustrating an example of a base station and a user equipment (UE) in communication in a wireless communication network according to various aspects of the present disclosure.

[0025] Figure 3 is a diagram illustrating an example Ethernet header in accordance with various aspects of the present disclosure.

[0026] Figure 4-7 is a diagram illustrating an example of Ethernet header removal for Ethernet frame delivery on new radio in accordance with aspects of the present disclosure.

[0027] Figure 8-15 is a diagram illustrating example procedures related to Ethernet header compression state management and other Ethernet header compression techniques in new radio in accordance with aspects of the present disclosure.

[0028] Detailed Description

[0029] The present disclosure generally relates to wireless communication devices configured to process both wireless data packets and Ethernet data packets and to communicate such packets over wireless communication links. Typical wireless communication protocols and / or packet compression protocols may not be suitable for processing Ethernet data packet streams for wireless communication in new radios to meet the low latency, high reliability, and low processing resource utilization requirements of Ethernet data packet streams, which are typically high capacity and high quality of service. The wireless communication devices of the present disclosure may be configured to overcome one or more of these deficiencies.

[0030] In some aspects, Ethernet header compression used in wireless nodes (e.g., UE or base station) has several unique characteristics and requirements, unlike conventional header compression algorithms (e.g., IP). Ethernet header compression can be used for traffic carried on wireless links that is susceptible to packet loss (e.g., due to unavailable context) and packet errors (e.g., due to stale context) (e.g., factory automation traffic that requires high reliability), and therefore the robustness of Ethernet header compression is extremely important. In addition, Ethernet header compression must be simple (e.g., not requiring complex operations on each packet) so that all processing related to compression / decompression can be performed quickly while meeting the ultra-reliable low latency communication (URLLC) timeline for some types of traffic carried on wireless links. Ethernet header compression in wireless node communications over wireless links should also take into account retransmissions and reordering caused by wireless transmissions, and allow a wireless network node (e.g., a gNB) to control the configuration of the compressor and decompressor in the UE based on the configuration observed by the wireless network node (e.g., the number of hybrid automatic repeat request (HARQ) / radio link control (RLC) retransmissions used) and channel conditions.

[0031] In one aspect, the present disclosure relates to Ethernet header compression in new radio, and more specifically to managing changes in context identifiers for contexts associated with one or more flows of compressed Ethernet packets. As used herein, a context identifier identifies a set of Ethernet header fields and a corresponding set of corresponding field values ​​associated with a compressed Ethernet packet. In one implementation, a transmitter performing Ethernet header compression may determine that a context identifier is to be modified (e.g., the set of Ethernet packet headers and / or corresponding values ​​are to be modified); and in response, a context delete message identifying the context identifier to be modified is transmitted to a receiver. In response to the context delete message, a receiver for decompressing compressed Ethernet packets may then clear the stored mapping between the context identifier and the set of Ethernet packet headers and corresponding values. This procedure enables the transmitter to reuse a content identifier with a modified set of Ethernet packet headers and / or corresponding values ​​for compressing a new Ethernet packet flow. Thus, the present disclosure enables simple and efficient context management for Ethernet header compression. These and other details of the present disclosure are discussed in more detail below.

[0032] In other aspects, the present disclosure relates to a device configured to process both wireless data traffic and Ethernet data traffic into wireless communications. For example, various aspects include determining at a compressor whether an acknowledgment (ACK) signal is received from a decompressor in response to transmitting a context creation message for a context identifier (ID) associated with a stream of incoming Ethernet data traffic via a wireless communication link. In addition, various aspects include suppressing transmission of a compressed packet corresponding to the stream by the compressor to the decompressor via the wireless communication link based on a first determination that an ACK signal is not received from the decompressor. In addition, various aspects include transmitting a compressed packet corresponding to the stream by the compressor to the decompressor via the wireless communication link based on a second determination that an ACK signal is received from the decompressor.

[0033] The various aspects of the present disclosure are described more fully below with reference to the accompanying drawings. However, the present disclosure can be implemented in many different forms and should not be interpreted as being limited to any specific structure or function given throughout the present disclosure. On the contrary, these aspects are provided to make the present disclosure thorough and complete, and it will fully convey the scope of the present disclosure to those skilled in the art. Based on the teachings herein, those skilled in the art will appreciate that the scope of the present disclosure is intended to cover any aspect of the present disclosure disclosed herein, whether it is implemented independently or in combination with any other aspect of the present disclosure. For example, any number of aspects set forth herein can be used to implement a device or practice method. In addition, the scope of the present disclosure is intended to cover such devices or methods practiced using supplements or other other structures, functionality, or structures and functionality as the various aspects of the present disclosure set forth herein. It should be understood that any aspect of the present disclosure disclosed herein can be implemented by one or more elements of the claims.

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

[0035] Note that while various aspects may be described herein using terminology typically associated with 3G and / or 4G wireless technologies, various aspects of the present disclosure may be applied in communication systems based on other generations, such as 5G and later generations, including NR technologies.

[0036] Figure 1 1 is a diagram illustrating a network 100 in which various aspects of the Ethernet header compression techniques described in the present disclosure may be practiced. The network 100 may be an LTE network or some other wireless network, such as a 5G or NR network. The wireless network 100 may include several BSs 110 (shown as BS 110a, BS 110b, BS 110c, and BS 110d) and other network entities. A BS is an entity that communicates with a user equipment (UE) and may also be referred to as a base station, NR BS, B node, gNB, 5G B node (NB), access point, transmit receive point (TRP), etc. Each BS may provide communication coverage for a specific geographic area. In 3GPP, the term "cell" may refer to a coverage area of ​​a BS and / or a BS subsystem serving the coverage area, depending on the context in which the term is used.

[0037] A BS may provide communication coverage for a macro cell, a pico cell, a femto cell, and / or another type of cell. A macro cell may cover a relatively large geographic area (e.g., several kilometers in radius) and may allow unrestricted access by UEs with service subscriptions. A pico cell may cover a relatively small geographic area and may allow unrestricted access by UEs with service subscriptions. A femto cell may cover a relatively small geographic area (e.g., a residence) and may allow restricted access by UEs associated with the femto cell (e.g., UEs in a closed subscriber group (CSG)). A BS for a macro cell may be referred to as a macro BS. A BS for a pico cell may be referred to as a pico BS. A BS for a femto cell may be referred to as a femto BS or a home BS. In Figure 1 , BS 110a may be a macro BS for macro cell 102a, BS 110b may be a pico BS for pico cell 102b, and BS 110c may be a femto BS for femto cell 102c. A BS may support one or more (e.g., three) cells. The terms “eNB,” “base station,” “NR BS,” “gNB,” “TRP,” “AP,” “Node B,” “5G NB,” and “femto cell” may be used interchangeably herein.

[0038] In some aspects, the cell may not necessarily be stationary, and the geographic area of ​​the cell may move depending on the location of the mobile BS. In some aspects, the BSs may be interconnected to each other and / or to one or more other BSs or network nodes (not shown) in the access network 100 via various types of backhaul interfaces, such as direct physical connections, virtual networks, and / or the like using any suitable transport network.

[0039] The wireless network 100 may also include a relay station. A relay station is an entity that can receive transmissions of data from an upstream station (e.g., a BS or a UE) and send transmissions of the data to a downstream station (e.g., a UE or a BS). A relay station may also be a UE that can relay transmissions for other UEs. Figure 1 In the example shown in , a relay station 110d may communicate with a macro BS 110a and a UE 120d to facilitate communication between the BS 110a and the UE 120d. A relay station may also be referred to as a relay BS, a relay base station, a relay, or the like.

[0040] The wireless network 100 may be a heterogeneous network including different types of BSs (e.g., macro BSs, pico BSs, femto BSs, relay BSs, etc.). These different types of BSs may have different transmit power levels, different coverage areas, and different effects on interference in the wireless network 100. For example, a macro BS may have a high transmit power level (e.g., 5 to 40 watts), while a pico BS, a femto BS, and a relay BS may have a lower transmit power level (e.g., 0.1 to 2 watts).

[0041] The network controller 130 may be coupled to a set of BSs and may provide coordination and control of these BSs. The network controller 130 may communicate with each BS via a backhaul. These BSs may also communicate with each other directly or indirectly, for example, via a wireless or wired backhaul. The network controller 130 may include, for example, a device providing a user plane function (UPF), a device providing an access management function (AMF), a device providing a session management function (SMF), a mobility management entity (MME), a serving gateway (SGW), a packet data network (PDN) gateway (PGW), and the like.

[0042] UEs 120 (e.g., 120a, 120b, 120c) may be dispersed throughout the wireless network 100, and each UE may be stationary or mobile. UEs may also be referred to as access terminals, terminals, mobile stations, subscriber units, stations, etc. A UE may be a cellular phone (e.g., a smart phone), a personal digital assistant (PDA), a wireless modem, a wireless communication device, a handheld device, a laptop computer, a cordless phone, a wireless local loop (WLL) station, a tablet device, a camera, a gaming device, a netbook, a smartbook, an ultrabook, a medical device or equipment, a biometric sensor / device, a wearable device (smart watch, smart clothing, smart glasses, smart wristband, smart jewelry (e.g., smart ring, smart bracelet)), an entertainment device (e.g., a music or video device, or a satellite radio), a vehicle component or sensor, a smart meter / sensor, an industrial manufacturing equipment, a global positioning system device, or any other suitable device configured to communicate via a wireless or wired medium.

[0043] Some UEs may be considered as machine type communication (MTC) UEs, or evolved or enhanced machine type communication (eMTC) UEs. MTC and eMTC UEs include, for example, robots, drones, remote devices such as sensors, meters, monitors, location tags, etc., which can communicate with a base station, another device (e.g., a remote device), or some other entity. A wireless node may provide connectivity to or to a network (e.g., a wide area network (such as the Internet) or a cellular network), for example, via a wired or wireless communication link. Some UEs may be considered as Internet of Things (IoT) devices, and / or may be implemented as NB-IoT (narrowband Internet of Things) devices. Some UEs may be considered as client equipment (CPE). UE 120 may be included inside a housing that houses components of UE 120, such as a processor component, a memory component, and the like.

[0044] In general, any number of wireless networks may be deployed in a given geographic area. Each wireless network may support a specific RAT and may operate on one or more frequencies. RAT may also be referred to as radio technology, air interface, etc. Frequency may also be referred to as carrier, frequency channel, etc. Each frequency may support a single RAT in a given geographic area to avoid interference between wireless networks of different RATs. In some cases, NR or 5G RAT networks may be deployed.

[0045] In some aspects, two or more UEs 120 (e.g., shown as UE 120a and UE 120e) may communicate directly (e.g., without using base station 110 as an intermediary to communicate with each other) using one or more sidelink channels. For example, UE 120 may communicate using peer-to-peer (P2P) communication, device-to-device (D2D) communication, vehicle-to-everything (V2X) protocols (e.g., which may include vehicle-to-vehicle (V2V) protocols, vehicle-to-infrastructure (V2I) protocols, etc.), mesh networks, etc. In this case, UE 120 may perform scheduling operations, resource selection operations, and / or other operations described elsewhere herein as being performed by base station 110.

[0046] As indicated above, Figure 1 It is provided only as an example. Other examples are possible and may differ from the Figure 1 Examples described.

[0047] Figure 2 A block diagram of a design 200 of a base station 110 and a UE 120 is shown, which may be Figure 1One of the base stations and one of the UEs in the UE 120, and each of the base station 110 and the UE 120 may be or may include a transmitting device or a compressor device and / or a receiving device and / or a decompressor device configured to perform the Ethernet header compression / decompression techniques discussed herein. The base station 110 may be equipped with T antennas 234a to 234t, and the UE 120 may be equipped with R antennas 252a to 252r, where in general T≥1 and R≥1.

[0048] At the base station 110, the transmit processor 220 may receive data for one or more UEs from the data source 212, select one or more modulation and coding schemes (MCS) for each UE based at least in part on a channel quality indicator (CQI) received from the UE, process (e.g., encode and modulate) the data for each UE based at least in part on the MCS selected for the UE, and provide data symbols for all UEs. The transmit processor 220 may also process system information (e.g., for semi-static resource partitioning information (SRPI), etc.) and control information (e.g., CQI requests, grants, upper layer signaling, etc.), and provide overhead symbols and control symbols. The transmit processor 220 may also generate reference symbols for reference signals (e.g., cell-specific reference signals (CRS)) and synchronization signals (e.g., primary synchronization signals (PSS) and secondary synchronization signals (SSS)). The transmit (TX) multiple-input multiple-output (MIMO) processor 230 may perform spatial processing (e.g., precoding) on ​​data symbols, control symbols, overhead symbols, and / or reference symbols, where applicable, and may provide T output symbol streams to T modulators (MOD) 232a to 232t. Each modulator 232 may process a respective output symbol stream (e.g., for OFDM, etc.) to obtain an output sample stream. Each modulator 232 may further process (e.g., convert to analog, amplify, filter, and up-convert) the output sample stream to obtain a downlink signal. The T downlink signals from modulators 232a to 232t may be transmitted via T antennas 234a to 234t, respectively. According to various aspects described in more detail below, position coding may be used to generate synchronization signals to convey additional information.

[0049] At UE 120, antennas 252a to 252r may receive downlink signals from base station 110 and / or other base stations and may provide received signals to demodulators (DEMODs) 254a to 254r, respectively. Each demodulator 254 may condition (e.g., filter, amplify, downconvert, and digitize) the received signal to obtain input samples. Each demodulator 254 may further process the input samples (e.g., for OFDM, etc.) to obtain received symbols. A MIMO detector 256 may obtain received symbols from all R demodulators 254a to 254r, perform MIMO detection on the received symbols where applicable, and provide detected symbols. A receive processor 258 may process (e.g., demodulate and decode) the detected symbols, provide decoded data for UE 120 to a data sink 260, and provide decoded control information and system information to a controller / processor 280. The channel processor may determine reference signal received power (RSRP), received signal strength indicator (RSSI), reference signal received quality (RSRQ), channel quality indicator (CQI), etc. In some aspects, one or more components of UE 120 may be included in a housing.

[0050] On the uplink, at the UE 120, a transmit processor 264 may receive and process data from a data source 262 and control information from a controller / processor 280 (e.g., for reports including RSRP, RSSI, RSRQ, CQI, etc.). The transmit processor 264 may also generate reference symbols for one or more reference signals. The symbols from the transmit processor 264 may be precoded by a TX MIMO processor 266, if applicable, further processed by demodulators 254a through 254r (e.g., for DFT-s-OFDM, CP-OFDM, etc.), and transmitted to the base station 110. At the base station 110, uplink signals from the UE 120 as well as other UEs may be received by the antenna 234, processed by the demodulator 254, detected by the MIMO detector 236, if applicable, and further processed by the receive processor 238 to obtain decoded data and control information sent by the UE 120. The receive processor 238 may provide decoded data to a data sink 239 and provide decoded control information to a controller / processor 240. The base station 110 may include a communication unit 244 and communicate with the network controller 130 via the communication unit 244. The network controller 130 may include a communication unit 294, a controller / processor 290, and a memory 292.

[0051] Controller / processor 240 of base station 110, controller / processor 280 of UE 120, controller / processor 290 of network controller 130, and / or Figure 2Any other component(s) of the base station 110 may perform one or more techniques associated with Ethernet header compression in new radio, as described in more detail elsewhere herein. For example, the controller / processor 240 of the base station 110, the controller / processor 280 of the UE 120, the controller / processor 290 of the network controller 130, and / or Figure 2 Any other component(s) may perform or direct e.g. Fig.12 The process 1200 Fig.13 The process of 1300 Fig.14 The process of 1400 Fig.15 The operations of process 1500, and / or other processes as described herein. Memories 242, 282, and 292 may store data and program codes for base station 110, UE 120, and network controller 130, respectively. Scheduler 246 may schedule UEs for data transmission on the downlink and / or uplink.

[0052] In some aspects, a transmitter (eg, base station 110, UE 120, network controller 130, etc.) may include means for performing various operations, among other things.

[0053] Additionally or alternatively, a receiver (eg, base station 110, UE 120, network controller 130, etc.) may include means for performing various operations, etc.

[0054] In some aspects, such devices may include a combination of Figure 2 One or more components of base station 110, UE 120 and / or network controller 130 are depicted.

[0055] As indicated above, Figure 2 It is provided only as an example. Other examples are possible and may differ from the Figure 2 Examples described.

[0056] In new radio and other types of radio access technologies, Ethernet frames carrying one or more Ethernet data packet streams may be transmitted over a wireless wide area network (WWAN) such as a cellular network, a 5G network, and the like. For example, a packet data network (PDN) and corresponding protocols have been defined for transmitting Ethernet traffic over 5G, sometimes referred to as Ethernet over a packet data convergence protocol (PDCP). In some cases, a header of an Ethernet frame (e.g., an Ethernet header) may contribute significant overhead to the overall size of a packet including an Ethernet frame. For example, an Ethernet header may be 14 bytes, 18 bytes, 22 bytes, or larger. In some scenarios such as factory automation, the overall size of the transmitted packets may be smaller, such as between 20 bytes and 50 bytes. In these cases, when an Ethernet header is included in each packet, the Ethernet header may significantly increase the size of the packet (e.g., by 28% or more, including up to 110% or more). Some of the techniques and devices described herein, such as by removing the Ethernet header when certain conditions are met, significantly reduce the amount of overhead caused by the Ethernet header transmitted over a 5G network or a similar type of network.

[0057] In addition, the overhead caused by transmitting Ethernet headers requires network resources (e.g., time resources, frequency resources, space resources, resource elements, etc.) that could otherwise be used to transmit other network traffic. In scenarios with low latency requirements and / or high reliability requirements (e.g., factory automation, ultra-reliable low latency communication (URLLC), etc.), transmitting Ethernet headers on 5G networks or similar types of networks can reduce the likelihood that network traffic delivery meets such requirements. Accordingly, some techniques and devices described herein save network resources and help meet latency requirements, reliability requirements, etc. by reducing Ethernet header overhead.

[0058] Figure 3 is a diagram illustrating an example Ethernet header in accordance with various aspects of the present disclosure.

[0059] Figure 3 Three different types of Ethernet headers for Ethernet frames are shown. As shown, different fields may be included in the Ethernet header depending on the specific Ethernet protocol being used for communication. For example, different numbers of fields may be included in the Ethernet header depending on whether virtual local area network (VLAN) information is carried in the Ethernet header and the number of VLANs of the VLAN information carried in the Ethernet header. As a result, the size of the Ethernet header may vary depending on these factors.

[0060] As shown by reference numeral 305, when a VLAN tag is not used, a first type of Ethernet header may be used. In this case, the Ethernet header may include a source address identifier (e.g., a source media access control (MAC) address, etc., shown as SRC), a destination address identifier (e.g., a destination MAC address, etc., shown as DST), and an Ethernet type (EtherType) identifier for indicating a protocol type encapsulated in a payload of an Ethernet frame and / or a size of an Ethernet frame. In the first type of Ethernet header, the source address identifier may be 6 bytes, the destination address identifier may be 6 bytes, and the Ethernet type identifier may be 2 bytes, and the Ethernet header may be 14 bytes in total.

[0061] As shown by reference numeral 310, when VLAN tags are used and a single VLAN tag is used (e.g., sometimes referred to as a single tag), a second type of Ethernet header may be used. In this case, the Ethernet header may include a source address identifier, a destination address identifier, an Ethernet type identifier, and a single VLAN tag field. The VLAN tag field may sometimes be referred to as an 802.1Q tag and may include a tag protocol identifier (TPID) field (e.g., 2 bytes) and a tag control information (TCI) field (e.g., 2 bytes). The TCI field may include a priority code point (PCP) field (e.g., 3 bits), a discard eligibility indicator (DEI) field (e.g., 1 bit), and a VLAN identifier (VID) field (e.g., 12 bits). In some aspects, if the Ethernet header includes a single VLAN tag field, the VLAN tag field may be referred to as a consumer tag (C-TAG) field. In the second type of Ethernet header, the source address identifier may be 6 bytes, the destination address identifier may be 6 bytes, the Ethernet type identifier may be 2 bytes, and the VLAN tag field may be 4 bytes, for a total of 18 bytes for the Ethernet header.

[0062] As shown by reference numeral 315, a third type of Ethernet header may be used when VLAN tags are used and two VLAN tags are used (e.g., sometimes referred to as dual tags). In this case, the Ethernet header may include a source address identifier, a destination address identifier, an Ethernet type identifier, a first VLAN tag field, and a second VLAN tag field. In some aspects, if the Ethernet header includes two VLAN tag fields, one of the two VLAN tag fields may be referred to as a consumer tag (C-TAG) field and the other VLAN tag field may be referred to as a service tag (S-TAG) field. In the third type of Ethernet header, the source address identifier may be 6 bytes, the destination address identifier may be 6 bytes, the Ethernet type identifier may be 2 bytes, the first VLAN tag field may be 4 bytes, and the second VLAN tag field may be 4 bytes, for a total of 22 bytes for the Ethernet header.

[0063] Thus, as indicated above, the Ethernet header may contribute between 14 bytes and 22 bytes of overhead to a packet carrying an Ethernet frame over PDCP, 5G, etc. Figure 3 The types of Ethernet headers shown in are provided as examples, and in some cases other types of Ethernet headers (e.g., Ethernet headers of different sizes) may be used. As will be described in more detail below, some techniques and apparatus described herein reduce packet overhead by compressing or removing all or part of the Ethernet header when certain conditions are met. Some of these techniques may be performed in association with packet filtering, thereby improving the efficiency of Ethernet header removal.

[0064] As indicated above, Figure 3 It is provided only as an example. Other examples are possible and may differ from the Figure 3 Examples described.

[0065] Figure 4 is a diagram illustrating an example 400 of Ethernet header removal for Ethernet frame delivery on new radio in accordance with aspects of the present disclosure.

[0066] like Figure 4 As shown in , a transmitter 405 (e.g., a base station 110, a UE 120, a network controller 130 (such as a UPF device), etc.) may include a traffic flow template (TFT) component 410 and a bearer mapping component 415. The TFT component 410 may store one or more traffic flow templates and may use the traffic flow templates to map incoming traffic (e.g., traffic input into the TFT component 410) to a specific traffic flow. A traffic flow may refer to a group of related packets, such as packets having one or more field values ​​that match a specific value or a set of values.

[0067] For example, as shown by reference numeral 420, the TFT component 410 may receive Ethernet traffic (e.g., Ethernet frames) and may map the Ethernet traffic to a traffic flow based on the type of the Ethernet traffic. The type may be based at least in part on a corresponding set of fields of the Ethernet traffic (such as the fields of the Ethernet header, as described above in conjunction with Figure 3TFT component 410 may read an Ethernet header of an incoming Ethernet frame, determine whether one or more field values ​​of the Ethernet header satisfy a set of conditions (e.g., match one or more values ​​in a set of stored values), and may map the Ethernet frame to a specific traffic flow (e.g., shown as Ethernet traffic types 1 to 4), as shown by reference numeral 425. TFT component 410 may map an Ethernet frame to a traffic flow based at least in part on which conditions are satisfied (e.g., using a sequential filter) and / or whether any condition is satisfied. In some aspects, if the Ethernet frame does not match any of the stored traffic flow templates, TFT component 410 may map the Ethernet frame to a default flow. As shown, TFT component 410 may perform similar operations on other types of network traffic, such as Internet Protocol (IP) traffic (e.g., by reading an IP header).

[0068] As indicated by reference numeral 430, bearer mapping component 415 may map network traffic to bearers (e.g., radio bearers, and evolved packet system (EPS) bearers, etc.) based at least in part on the type of network traffic (e.g., Ethernet traffic, IP traffic, etc.). A bearer may carry one or more classes of network traffic and may be assigned a quality of service class indicator (QCI) value for traffic prioritization. In some cases, there may be a one-to-one mapping of traffic type to bearers, as shown by Ethernet traffic type 1 mapping to EPS bearer A and Ethernet traffic type 2 mapping to EPS bearer B. In some cases, there may be a many-to-one mapping of traffic type to bearers, as shown by Ethernet traffic types 3 and 4 mapping to EPS bearer C. As shown, transmitter 405 may transmit Ethernet traffic on a bearer associated with an Ethernet PDN. As shown, bearer mapping component 415 may perform similar operations for other types of network traffic, such as IP traffic.

[0069] As indicated by reference numeral 435, in some aspects, the Ethernet header may be completely specified by a traffic flow template stored by the TFT component 410. For example, the traffic flow template may include specific values ​​for all required fields of the Ethernet header (e.g., depending on the type of Ethernet header), and the values ​​of those required fields in the Ethernet header may match the values ​​included in the traffic flow template for each of those required fields. Figure 5 The following describes additional details of the fully specified Ethernet header. In this case, only a single type of Ethernet traffic is transmitted on a specific bearer. Figure 5As described in more detail, when the Ethernet header is completely specified by the traffic flow template, the transmitter 405 can remove the Ethernet header from the packet, thereby saving network resources, reducing overhead, etc. In the case where multiple types (e.g., having different values ​​in each Ethernet header) of Ethernet traffic are mapped to a single bearer (e.g., shown as Ethernet traffic types 3 and 4 mapped to EPS bearer C), the transmitter 405 may not be able to remove the Ethernet header because the Ethernet header is not completely specified by the traffic flow template in this case. Figure 5 To provide additional details of the operations performed by transmitter 405.

[0070] In some aspects, the removal of the Ethernet header can be performed by the TFT component 410, the bearer mapping component 415, and / or another component of the transmitter 405. In some aspects, the Ethernet header can be removed after and / or in conjunction with filtering the traffic using the traffic flow template. Additionally or alternatively, the Ethernet header can be removed after and / or in conjunction with mapping the traffic to the bearer.

[0071] As indicated above, Figure 4 It is provided only as an example. Other examples are possible and may differ from the Figure 4 Examples described.

[0072] Figure 5 is a diagram illustrating another example 500 of Ethernet header removal for Ethernet frame delivery on new radio in accordance with aspects of the present disclosure.

[0073] Figure 5 2 shows example operations performed by a transmitter 505 in conjunction with Ethernet header removal for Ethernet frame delivery on a new radio (eg, on PDCP). In some aspects, the transmitter 505 may correspond to the above in conjunction with Figure 4 The transmitter 505 described above may be a base station 110, a UE 120, a network controller 130 (eg, a UPF device, etc.), etc. As shown, the transmitter 505 may include a TFT component 510 (eg, which may correspond to Figure 4 TFT component 410), a carrier mapping component 515 (eg, which may correspond to Figure 4 The load mapping component 415), and / or the compression component 520. These components may include hardware, firmware, or a combination of hardware and software. For example, these components may include the above combined Figure 2 In some aspects, compression component 520 can be integrated into TFT component 510 and / or bearer mapping component 515. Alternatively, compression component 520 can be a separate component.

[0074] As indicated by reference numeral 525, transmitter 505 (e.g., compression component 520) may determine a configuration related to Ethernet header compression for Ethernet frames to be transmitted over PDCP, 5G, etc. In some aspects, transmitter 505 may receive the configuration from another device. For example, UE 120 may receive the configuration from base station 110 (e.g., when the configuration may be generated and / or received from network controller 130). Additionally or alternatively, base station 110 may receive the configuration from network controller 130 (e.g., UPF device). In some aspects, transmitter 505 may generate the configuration. For example, base station 110 and / or network controller 130 may generate the configuration.

[0075] The configuration may indicate whether to remove Ethernet headers from traffic (e.g., network traffic, one or more packets, etc.) mapped to a particular bearer. Additionally or alternatively, the configuration may indicate whether to remove Ethernet headers from traffic when the Ethernet headers are fully specified by a traffic flow template (e.g., mapping the traffic to a particular bearer). In some aspects, the configuration may be generated and / or indicated in association with establishing a particular bearer. Additionally or alternatively, the configuration may be indicated in a radio resource control (RRC) message (e.g., an RRC configuration message, an RRC reconfiguration message, etc.), a non-access stratum (NAS) message, etc. Additionally or alternatively, the configuration may be signaled using a traffic flow template format, thereby improving efficiency when applying header removal in combination with traffic flow template filtering.

[0076] In some aspects, the configuration may indicate whether the transmitter 505 is to transmit packets including Ethernet frames, with or without an indication of whether the Ethernet header has been removed from the packets. This indication may be used by a receiver of the packets to determine whether the packets include an Ethernet header, to determine whether the receiver is to reconstruct the Ethernet headers of the packets, and the like.

[0077] As indicated by reference numeral 530, the TFT component 510 may receive Ethernet traffic to be transmitted over a bearer (eg, via 5G, PDCP, etc.), as described above in conjunction with Figure 4 The TFT component 510 may apply one or more filters to the incoming Ethernet traffic to generate filtered Ethernet traffic mapped to the traffic flow, as shown by reference numeral 535 and as described above in conjunction with Figure 4 as described.

[0078] As indicated by reference numeral 540, compression component 520 may determine that the Ethernet header of the filtered Ethernet traffic is completely specified by the traffic flow template stored by TFT component 510. The Ethernet header may be completely specified by the traffic flow template when the traffic flow template includes specific values ​​(e.g., and not a range of values) for all required fields of the Ethernet header and each of those specific values ​​matches a corresponding value of a corresponding field included in an Ethernet header (e.g., of the incoming Ethernet traffic).

[0079] For a first type of Ethernet traffic, the required fields may be a source address field, a destination address field, and an Ethernet type field. For other types of Ethernet headers, the required fields may be a source address field, a destination address field, an Ethernet type field, and all VLAN tag fields, which may include a single VLAN tag field in a single tag case or two VLAN tag fields in a double tag case. For example, for a second type of Ethernet header, the required fields may be a source address field, a destination address field, an Ethernet type field, and a single VLAN tag field. For a third type of Ethernet header, the required fields may be a source address field, a destination address field, an Ethernet type field, a first VLAN tag field (e.g., a C-TAG field), and a second VLAN tag field (e.g., an S-TAG field). Additionally or alternatively, the Ethernet header may be fully specified by the traffic flow template only when packets with the same Ethernet header (e.g., the same values ​​for each Ethernet header field) are mapped to a flow and / or bearer indicated by the traffic flow template.

[0080] If the traffic flow template does not store specific values ​​for one or more required fields of the Ethernet header, then the traffic flow template cannot fully specify any Ethernet header (e.g., where the traffic flow template does not store a specific value for the EtherType field). For a particular Ethernet header, if the value of any required field of the particular Ethernet header does not match the corresponding value stored by the traffic flow template (e.g., for the same field), then the particular Ethernet header is not fully specified by the traffic flow template.

[0081] As indicated by reference numeral 545, the compression component 520 may remove the Ethernet header from the filtered Ethernet traffic based at least in part on the configuration and / or a determination that the Ethernet header of the filtered Ethernet traffic (e.g., one or more packets) is completely specified by the traffic flow template. In some aspects, the configuration may indicate that the Ethernet header is to be removed from the Ethernet traffic mapped to a particular bearer, and the compression component 520 may remove the Ethernet header from the Ethernet traffic based at least in part on a determination that the Ethernet traffic is mapped to the particular bearer. In some cases, the compression component 520 does not have to determine whether the Ethernet header is completely specified by the traffic flow template because the configuration may ensure that only completely specified Ethernet headers are configured for Ethernet header removal.

[0082] In some aspects (e.g., where the configuration does not ensure that only fully specified Ethernet headers are configured for Ethernet header removal), the compression component 520 may determine whether the Ethernet header is fully specified and may remove the Ethernet header if the Ethernet header is fully specified. In some aspects, where the Ethernet header is fully specified, the Ethernet header may be removed by default. Additionally or alternatively, the compression component 520 may determine whether the configuration of the bearer indicates that the Ethernet header is to be removed from the Ethernet traffic mapped to the bearer. In this case, if the configuration indicates that the Ethernet header is to be removed and if the Ethernet header is fully specified, the compression component 520 may remove the Ethernet header. However, if the configuration indicates that the Ethernet header is not to be removed, the compression component 520 may refrain from removing the Ethernet header, regardless of whether the Ethernet header is fully specified by the traffic flow template.

[0083] As indicated by reference numeral 550, removing the Ethernet header may include removing all fields of the Ethernet header from the packet(s) to be transmitted (but retaining the Ethernet payload). For example, for a first type of Ethernet header, the compression component 520 may remove all values ​​of the source address field, the destination address field, and the Ethernet type field. For other types of Ethernet headers, the compression component 520 may remove all values ​​of the source address field, the destination address field, the Ethernet type field, and all VLAN tag fields. For example, for a second type of Ethernet header, the compression component 520 may remove all values ​​of the source address field, the destination address field, the Ethernet type field, and a single VLAN tag field. Similarly, for a third type of Ethernet header, the compression component 520 may remove all values ​​of the source address field, the destination address field, the Ethernet type field, a first VLAN tag field (e.g., a C-TAG field), and a second VLAN tag field (e.g., an S-TAG field).

[0084] As shown by reference numeral 555, in some aspects, transmitter 505 may insert an indication of whether an Ethernet header has been removed from a packet including an Ethernet payload. As described above, in some aspects, the configuration may indicate whether to insert this indication, and transmitter 505 may determine whether to insert this indication based at least in part on the configuration. In some aspects, the Ethernet header may be removed from all packets transmitted via a specific bearer, and the receiver may be notified as such. In this case, the receiver does not need an indication of whether an Ethernet header has been removed from a packet transmitted via the specific bearer. Thus, the indication does not have to be transmitted, thereby saving processing power, network resources, etc. However, in some cases, the Ethernet header may not be removed from all packets transmitted via a specific bearer. In this case, the receiver may need an indication of whether the Ethernet header has been removed from a packet in order to correctly process the packet.

[0085] In some aspects, if an indication of whether the Ethernet header has been removed is included in the packet, the indication may be included in a field of a Service Data Adaptation Protocol (SDAP) header and / or a field of a PDCP header. In some aspects, the indication may be a single bit that may be set to a first value (e.g., 1) when the Ethernet header has been removed or may be set to a second value (e.g., 0) when the Ethernet header has not been removed.

[0086] As shown by reference numeral 560, the transmitter 505 may transmit Ethernet traffic (e.g., one or more packets including an Ethernet payload) via a bearer to which the Ethernet traffic is mapped (e.g., by the bearer mapping component 515). If the Ethernet header is removed from the packet, the portion of the packet that carries the Ethernet frame may include only the Ethernet payload (e.g., and not including the Ethernet header). If the Ethernet header is not removed from the packet, the portion of the packet that carries the Ethernet frame may include the Ethernet payload and the Ethernet header. In either case, an Ethernet checksum (e.g., a cyclic redundancy check (CRC)) may be removed from the packet (e.g., via a PDCP function). In some aspects, the packet may include an indication as to whether the Ethernet header is removed (e.g., according to configuration), as described above.

[0087] By removing the Ethernet header when it is completely specified by the traffic flow template, network resources can be saved without negatively affecting the reception of Ethernet frames, because the receiver will be able to reconstruct the Ethernet header due to the Ethernet header being completely specified by the traffic flow template, as described below in conjunction with Figure 6 Described in more detail. In this way, the amount of overhead caused by Ethernet headers transmitted over 5G, PDCP, etc. can be reduced. This can save significant overhead, especially for small payload and / or packet sizes.

[0088] As indicated above, Figure 5 It is provided only as an example. Other examples are possible and may differ from the Figure 5 Examples described.

[0089] Figure 6 is a diagram illustrating another example 600 of Ethernet header removal for Ethernet frame delivery on new radio in accordance with aspects of the present disclosure.

[0090] Figure 6 Example operations performed by a receiver 605 in conjunction with Ethernet header removal for Ethernet frame delivery on a new radio (e.g., on PDCP) are shown. In some aspects, the receiver 605 may be a base station 110, a UE 120, a network controller 130 (e.g., a UPF device, etc.), etc. As shown, the receiver 605 may include a bearer identification component 610 and / or a header reconstruction component 615. These components may include hardware, firmware, or a combination of hardware and software. For example, these components may include the above-mentioned combination of Figure 2 One or more components described.

[0091] As indicated by reference numeral 620, the receiver 605 may receive a packet, which may include Ethernet traffic. For example, the packet may be a packet including an Ethernet payload, which may be transmitted by the transmitter 505, as described above in conjunction with Figure 5 as described.

[0092] As indicated by reference numeral 625, receiver 605 (eg, bearer identification component 610) can identify a bearer associated with a received packet. For example, a bearer can be identified based at least in part on a QCI value, a bearer identifier, etc., which can be included in the packet.

[0093] As indicated by reference numeral 630, the receiver 605 (eg, header reconstruction component 615) may be configured to perform the above-described Figure 5 A similar manner as described herein determines a configuration related to Ethernet header compression for Ethernet frames to be transmitted over PDCP, 5G, etc. In some aspects, the receiver 605 may receive the configuration from another device. For example, the UE 120 may receive the configuration from the base station 110. Additionally or alternatively, the base station 110 may receive the configuration from the network controller 130. In some aspects, the receiver 605 may generate the configuration. For example, the base station 110 and / or the network controller 130 may generate the configuration. The configuration may be associated with a bearer.

[0094] As above combined Figure 5As described, in some aspects, the configuration may be generated and / or indicated in association with establishing a bearer. Additionally or alternatively, the configuration may be indicated in an RRC message, a NAS message, etc. Additionally or alternatively, the configuration may be signaled using a traffic flow template format.

[0095] As shown by reference numeral 635, the receiver 605 (e.g., header reconstruction component 615) may determine that the Ethernet header has been removed from the traffic on the bearer. For example, the receiver 605 may determine that the bearer is associated with a configuration indicating that the Ethernet header is to be removed from the traffic associated with the bearer. In some aspects, the configuration may indicate that all packets received via a specific bearer will be received without an Ethernet header (e.g., the Ethernet header is removed). In this case, the receiver 605 may determine that the Ethernet header has been removed from the packet when the packet is received via a specific bearer, and the Ethernet header of the packet may be reconstructed, as described below. In some aspects, the configuration may indicate (e.g., in an SDAP header, a PDCP header, etc.) that the packet received via a specific bearer will include an indication of whether the Ethernet header has been removed from the packet. In this case, the receiver 605 may read an indication from a packet to determine whether the Ethernet header has been removed from the packet. If the indication indicates that the Ethernet header has been removed from the packet, the receiver 605 may reconstruct the Ethernet header of the packet as described below.

[0096] As indicated by reference numeral 640, the receiver 605 (e.g., header reconstruction component 615) may reconstruct an Ethernet header of an Ethernet frame in the packet based at least in part on the configuration. For example, the configuration may indicate values ​​for various fields of the Ethernet header (e.g., a source address field, a destination address field, an Ethertype field, and / or one or more VLAN tag fields), and the receiver 605 may read the configuration to determine specific values ​​to be inserted into specific fields of the Ethernet header. The receiver 605 may reconstruct the fields and / or insert the indicated values ​​into those fields to reconstruct the Ethernet header.

[0097] By removing the Ethernet header at the transmitter when the Ethernet header is fully specified by the traffic flow template so that the Ethernet header can be reconstructed by the receiver 605 (e.g., due to the mapping of Ethernet header values ​​to bearers, as indicated in the configuration), network resources can be saved without negatively impacting the reception of Ethernet frames.

[0098] As indicated above, Figure 6 It is provided only as an example. Other examples are possible and may differ from the Figure 6 Examples described.

[0099] Figure 7is a diagram illustrating another example 700 of Ethernet header removal for Ethernet frame delivery on new radio in accordance with aspects of the present disclosure.

[0100] Figure 7 Example operations performed by a network device 705 in conjunction with Ethernet header removal for Ethernet frame delivery on a new radio (e.g., on PDCP) are shown. In some aspects, the network device 705 can be a base station 110, a network controller 130 (e.g., a UPF device, an AMF device, an SMF device, etc.), etc. In some aspects, the network device 705 can be the same device as the transmitter 505. In some aspects, the network device 705 can be the same device as the receiver 605.

[0101] As shown by reference numeral 710, the network device 705 may determine that the Ethernet header is completely specified by the traffic flow template that maps the traffic to the bearer. In some aspects, the network device 705 may make this determination when establishing the bearer. The network device 705 may identify the bearer to be established, may identify the traffic flow template that maps the traffic to the bearer, and may determine whether the traffic flow template completely specifies the Ethernet header. As shown, the first traffic flow template (e.g., shown as TFT A) does not completely specify the Ethernet header, and therefore the Ethernet header removal may not be permitted for the traffic transmitted by the bearer to which the traffic is mapped by the first traffic flow template.

[0102] As shown by reference numeral 715, the network device 705 may determine whether to configure Ethernet header removal for a traffic flow template and / or a bearer. In some aspects, the network device 705 may determine whether to configure Ethernet header removal based at least in part on the capabilities of a transmitter and / or a receiver associated with the bearer for supporting Ethernet header removal. In some aspects, such capabilities may be indicated to the network device 705 (e.g., in a UE capability report, a base station capability report, etc.). In some aspects, if both the transmitter and the receiver do not support Ethernet header removal, the network device 705 may determine not to configure Ethernet header removal, regardless of whether the Ethernet header is fully specified by the traffic flow template (e.g., as shown in the case of TFT B). In some aspects, if the transmitter and the receiver support Ethernet header removal and the Ethernet header is fully specified, the network device 705 may configure Ethernet header removal for the bearer and / or traffic flow template (e.g., as shown in the case of TFT C).

[0103] As indicated by reference numeral 720, the network device 705 may transmit a configuration indicating whether to remove the Ethernet header from the traffic mapped to the bearer. As indicated elsewhere herein, the configuration may be generated and / or transmitted in association with establishing the bearer. Additionally or alternatively, the configuration may be indicated in an RRC message, a NAS message, or the like. Additionally or alternatively, the configuration may be signaled using a traffic flow template format.

[0104] As shown, if the network device 705 determines that the Ethernet header is to be removed from the traffic mapped to the bearer, the configuration may indicate that the Ethernet header is to be removed from such traffic. As further shown, the configuration may indicate the values ​​of the fields of the Ethernet header (e.g., for all fields removed from the Ethernet header). The network device 705 may determine the values ​​of the fields based at least in part on a traffic flow template, which may indicate specific values ​​of the fields when the Ethernet header is completely specified by the traffic flow template. In this way, the receiver may reconstruct the Ethernet header when the Ethernet header has been removed.

[0105] As further shown, in some aspects, the configuration may indicate whether the traffic mapped to the bearer is to include an indication of whether the Ethernet header has been removed from the traffic. In this way, the transmitter may include such an indication when necessary, and the receiver may use such an indication to determine whether to reconstruct the Ethernet header, as described elsewhere herein.

[0106] As indicated above, Figure 7 It is provided only as an example. Other examples are possible and may differ from the Figure 7 Examples described.

[0107] refer to Figure 8-15, describes various aspects of performing Ethernet header compression context state management. Ethernet header compression may be configured for uplink and / or for downlink per data radio bearer (e.g., dedicated radio bearer). In one implementation, for example, Ethernet packets may be grouped into streams, and each stream may be assigned a context identifier (ID). A transmitter may identify the starting point of transmission of a new context to a receiver by transmitting at least one packet with a complete Ethernet header and a corresponding context ID. Then, the transmitter may transmit a compressed Ethernet packet omitting the complete Ethernet header, and replace the completed Ethernet header with an Ethernet compression header, which may include a type indicator and the context ID. In some cases, the transmitter may wait to receive a new context setup confirmation from a receiver before initiating transmission of a compressed Ethernet packet of a new context. In some cases, when the transmitter assigns a context ID to a stream, the transmitter may desire to reuse a previously used context ID. In this case, the transmitter may transmit a context ID deletion message to the receiver to ensure that the receiver clears the settings associated with the previously used context ID. Thus, the transmitter may wait to receive a context ID deletion acknowledgement from the receiver before initiating transmission of Ethernet packets associated with the reused context ID.

[0108] refer to Figure 8 In some aspects, Ethernet header compression and header decompression as described herein may be performed by an Ethernet header compression function and an Ethernet header decompression function. These two functions may be part of a corresponding Packet Data Convergence Protocol (PDCP) function of a transmitting PDCP entity or a receiving PDCP entity as part of a protocol layer on a transmitter or a receiver.

[0109] In one aspect, the Ethernet header compression function defines its own Ethernet compression sub-header, which may include a type and a context ID, as will be described in more detail below. Figure 3 An example Ethernet header for an Ethernet frame is shown as described above. In one aspect, the Ethernet compression sub-header may omit some or all fields of the Ethernet header.

[0110] The Ethernet header may not include variable fields, such as a sequence number or a timestamp. In addition, the Ethernet packet may correspond to a specific flow having a repeated value in the Ethernet packet header, such as a value of the source, a value of the destination, or a value of the Ethernet type. For example, the Ethernet packet flow may be a control or automation flow (e.g., a time-sensitive network (TSN) flow) between a controller and a sensor or actuator, a login or diagnostic flow between a server and a machine, a management or provisioning flow between a provisioning system and a machine, or a security flow between a security panel and an alarm. Accordingly, multiple Ethernet packets sent from a transmitting UE to a receiving UE through a radio access network interface may have the same header, or may include a header with a continuously repeated value.

[0111] Some flows may benefit from header compression. For example, flows with small packets (e.g., automated flows) may find header compression particularly beneficial. Some flows (e.g., automated flows) require low latency on their packets and may need compression and decompression operations to minimally affect that latency.

[0112] refer to Fig. 9 , the Ethernet packet is converted into a compressed header Ethernet packet. The Ethernet packet includes an Ethernet packet header and an Ethernet packet payload. The PDCP and compression sublayer at the transmitter (e.g., transmitter 405 or transmitter 505) remove the Ethernet packet header and replace the Ethernet packet header with an Ethernet compression subheader, while adding a PDCP header. In the case where a context identifier may be included in the Ethernet compression subheader, the PDCP PDU including the Ethernet compression subheader may include a PDCP PDU header value, a PDCP PDU type value, and / or a context identifier value. In some aspects, the PDCP PDU header value may be set to data, thereby indicating that an Ethernet payload including data is attached to the Ethernet compression subheader. In some aspects, the PDCP PDU header value may be set to data, and no data or padding bits are attached to the Ethernet compression subheader. In some aspects, the PDCP PDU header value may be set to control, thereby indicating that the packet is used as a control function and the Ethernet payload may not be included. The PDCP PDU Type value may be set to "Compressed" or may otherwise indicate that this is a packet with a compressed Ethernet header based on a context identifier. The context identifier value may identify which Ethernet header values ​​should be associated with a compressed Ethernet packet.

[0113] Compression of partial fields of the header may involve additional complexity for compression and decompression. The definition of a compressed header format that includes some Ethernet header fields and removes other Ethernet header fields (which may have a large number of combinations of included / omitted fields); the compressor process for creating a header with partial compression; and the decompressor process for creating a complete header based on a received header all add complexity to compression and decompression. Fig. 9 The Ethernet compression sub-header can avoid this added complexity by replacing the entire Ethernet packet header and using the context identifier value to represent the values ​​therein.

[0114] refer to Fig.10 , describing a packet for creating a compression context. The PDCP and compression sublayer at a transmitter (e.g., transmitter 405 or transmitter 505) attach a context creation header to an Ethernet packet and send a packet including the context creation header, an Ethernet packet header, and an Ethernet packet payload to a receiver (e.g., receiver 605). In the case where a context identifier may be included in an Ethernet compression subheader, a PDCP PDU including a context creation header may include a PDCP PDU header value, a PDCP PDU type value, and / or a context identifier value. The PDCP PDU header value may be set to data. The PDCP PDU type value may be set to "context establishment" or may otherwise indicate that the packet should be used to establish a new context for Ethernet packet header compression. The context identifier value may identify a context identifier that should be associated with a value in a subsequent attachment header. Upon receiving an Ethernet packet with a context creation header, a receiver (e.g., receiver 605) may store the value of the attached Ethernet header value in association with the value of the context identifier. Upon receiving an Ethernet packet with a compressed header (such as the above reference Fig. 9 When the described packet (a packet having a PDCP PDU type value of "Compressed"), the receiver may decompress the header by replacing the compressed header with the stored header value.

[0115] Fig.11 The Ethernet Compression Configuration Packet is illustrated (note that a PDCP PDU may be a PDCP Data PDU or a PDCP Control PDU). In some embodiments, a PDCP PDU including an Ethernet Compression Subheader may include a PDCP PDU Type and a PDCP PDU Subtype associated with a context identifier value. For example, Fig.11 As shown, the PDCP PDU type may be "Ethernet Compression Configuration" or may indicate that the header is for a packet for which a compression configuration function is performed.

[0116] The subtype may identify what compression configuration function should be performed for the associated context identifier. For example, packet 1105 is a setup confirmation packet. The subtype may indicate that the header is a setup confirmation to be sent from a receiver (e.g., receiver 605) to a transmitter (e.g., transmitter 405, transmitter 505) to indicate a context creation packet with a context creation header (e.g., as described above with reference to Fig.10 described) has been received and the context identifier has been established accordingly.

[0117] After a period of time, a compressor (e.g., compression component 520) or a transmitter (e.g., transmitter 405 or transmitter 505) may realize that a context identifier is not currently receiving any traffic and may therefore determine to associate a different stream (e.g., a different Ethernet header) with the context identifier. In some aspects, the transmitter may send a context creation packet with a new compression context (e.g., a new Ethernet header) for an existing context identifier, which the receiver interprets as replacing the old compression context. For example, this may be accomplished by referring to the above reference to Fig.10 This is accomplished by sending packets as described.

[0118] A decompressor (e.g., header reconstruction component 615) or a receiver (e.g., receiver 605) may need to prepare for any incoming packets to replace an existing compression context, in which case it may need to deliver this packet to a higher layer and perform context modification procedures within a compact URLLC time limit. This adds complexity to the receiving path of the established context identifier. A decompressor or receiver may also need to prepare for frequent changes to the compression context (e.g., Ethernet packet header) of a given compression identifier, including receiving a context creation packet situation while the decompressor or receiver is setting up a context for a previously received context creation packet. Ultimately, in the case where PDCP is configured for out-of-order delivery and in the case where context creation packets are sent adjacent to each other, the decompressor may set its state to an older compression context, resulting in a decompression error.

[0119] In some aspects, the transmitter may first delete the compression context for the context identifier and then create a new compression context for the context identifier. Packet 1110 is a context delete packet. It includes a subtype value of "delete" in association with the context identifier. The transmitter may send packet 1110 to the receiver, and upon receiving packet 1110, the receiver may remove whatever association currently exists between the Ethernet header and the context identifier. Packet 1115 is a delete confirmation packet. It includes a subtype value of "delete confirmation" in association with the context identifier. Once the association between the Ethernet header and the context identifier is completed, the receiver may transmit packet 1115 to the transmitter so that the transmitter knows that the context identifier is available for reuse.

[0120] Packets 1105, 1110, and 1115 each include a PDCP PDU header value set to "control" and accordingly do not include an Ethernet packet payload. It may be desirable to use PDCP control PDU packets to transmit these packets because these packets can be sent at any time without sending data. In some aspects, the PDCP PDU header may be set to "data" and may include an Ethernet packet payload that is empty or includes padding bits, and a receiver or transmitter that receives the packet may ignore the Ethernet packet payload. In some aspects, these packets may be transmitted using PDCP data PDUs because duplicate PDCP data PDUs are discarded at the receiving PDCP entity while duplicate PDCP control PDUs are not discarded. Such duplications may be due to RLC retransmissions, and the duplications may be reordered due to HARQ retransmissions. Discarding duplicate PDCP data PDUs may improve the robustness of context management to reordering of context management messages (e.g., context deletion messages, context deletion acknowledgment messages) due to RLC retransmissions and HARQ retransmissions.

[0121] In some aspects, the PDCP compression sublayer supports sending uncompressed packets that do not require compression, sending uncompressed packets for context setup, and sending packets with compressed headers. Additional functions (e.g., confirmation of context setup) can be handled by the PDCP control plane and therefore the definition of the compression sublayer header may not be required.

[0122] In some aspects, the compression sublayer header may include two bits for identifying whether the packet is uncompressed, a context setup packet, or a compressed packet. In some aspects, the compression sublayer header includes six bits for the context identifier, and these six bits may be ignored by the receiver when the packet is uncompressed.

[0123] Fig.121 is a diagram illustrating an example process 1200, performed, for example, by a transmitter, in accordance with various aspects of the present disclosure. The example process 1200 is an example in which a transmitter (e.g., transmitter 405, transmitter 505, base station 110, UE 120, network controller 130, etc.) performs operations associated with Ethernet header compression in new radio.

[0124] like Fig.12 As shown in , in some aspects, process 1200 may include determining that a context identifier is to be modified (block 1212). For example, a transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may determine that a context identifier is to be modified, as described above in conjunction with Figure 8-11 Described. The context identifier may correspond to an Ethernet packet header value. In some aspects, determining that the context identifier is to be modified may include determining that a set time period has elapsed since a transmitter transmitted an Ethernet packet with the context identifier to a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.). In some aspects, determining that the context identifier is to be modified may include determining that a new context identifier is to be created and determining that all available context identifier values ​​are in use. Determining that a new context identifier is to be created may include receiving a plurality of new Ethernet packets, identifying that the plurality of new Ethernet packets have a set of common field values ​​in a set of common Ethernet header fields, and determining that the set of common field values ​​in the set of common Ethernet header fields do not match known field values ​​in a plurality of known Ethernet header fields corresponding to an existing context identifier. Determining that a new context identifier is to be created may be accomplished in response to determining that there is no match.

[0125] In some aspects, the context identifier corresponds to a profile identifier that identifies a particular set of Ethernet header fields.

[0126] like Fig.12 As further shown in FIG. 1 , in some aspects, process 1200 may include transmitting a context delete message identifying the context identifier to a receiver (block 1214). For example, a transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may transmit a context delete message to a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.), as described above in conjunction with Figure 8-11The context delete message may include a packet data convergence protocol (PDCP) packet data unit (PDU), wherein a PDCP PDU header value is set to control or data. The PDCP PDU header value may be set to data, and a data field of the PDCP PDU may be empty or may include padding bits. The context delete message may include a PDCP PDU packet including an indication indicating that the context delete message is a context delete message. The indication may be a value of a field in the PDCP PDU.

[0127] In some aspects, process 1200 may further include receiving a deletion confirmation from a receiver (block 1216). For example, a transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may receive a deletion confirmation message from a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.), as described above in conjunction with Figure 8-11 The deletion confirmation message may include a PDCP PDU, wherein a PDCP PDU header value is set to control or data. The PDCP header value may be set to data, and a data field of the PDCP PDU may be empty or may include padding bits. The deletion confirmation message may include a PDCP PDU, which includes an indication for indicating that the deletion confirmation message is a deletion confirmation message. The indication may be a value of a field in the PDCP PDU.

[0128] In some aspects, the context deletion message includes a PDCP PDU header value set to "Control", a PDU type value set to "Ethernet Compression", and a subtype value set to "Delete", and the deletion confirmation message includes a PDCP header value set to "Control", a PDU type value set to "Ethernet Compression", and a subtype value set to "Delete Confirmation".

[0129] In some aspects, process 1200 may further include removing an Ethernet packet header value associated with the context identifier (block 1218). The Ethernet packet header value may be removed in response to receiving the delete confirmation message. The Ethernet packet header value may be stored in a memory associated with the transmitter and may be removed from the memory at block 1218. For example, the transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may remove the Ethernet packet header value associated with the context identifier from a memory associated with the transmitter in response to receiving the delete confirmation message, as described above in conjunction with Figure 8-11 as described.

[0130] In some aspects, process 1200 may further include transmitting a context creation packet to the receiver in response to receiving the delete confirmation message (block 1220). The context creation packet may include the modified Ethernet packet header value and the context identifier. For example, the transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may transmit a context creation packet to the receiver in response to receiving the delete confirmation message, the context creation packet including the modified Ethernet packet header value and the context identifier, as described above in conjunction with Figure 8-11 as described.

[0131] In some aspects, process 1200 may further include receiving an Ethernet packet corresponding to the modified Ethernet packet header value (block 1222). The Ethernet packet may have a header value corresponding to the modified Ethernet packet header value. For example, a transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may receive an Ethernet packet having a header value corresponding to the modified Ethernet packet header value, as described above in conjunction with Figure 8-11 as described.

[0132] In some aspects, process 1200 may further include transmitting the Ethernet packet as a compressed packet to the receiver (block 1224). The compressed packet may have an Ethernet compression header that includes the context identifier. For example, a transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may transmit the Ethernet packet as a compressed packet to the receiver, the compressed packet having an Ethernet compression header that includes the context identifier, as described above in conjunction with Figure 8-11 as described.

[0133] In some aspects, process 1200 may further include transmitting a packet with the context identifier (block 1204). That is, at block 1204, the process may include transmitting a packet with the context identifier associated with the Ethernet header value before establishing the new compression context. For example, a transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may receive a plurality of Ethernet packets including a header with an Ethernet packet header value, associate the context identifier with the Ethernet packet header value, transmit a first packet of the plurality of packets including the Ethernet header value and the context identifier to a receiver, and transmit subsequent packets of the plurality of packets as compressed packets having an Ethernet header including the context identifier, as described above in conjunction with Figure 1-11 as described.

[0134] In some aspects, process 1200 may further include receiving a plurality of new Ethernet packets (block 1206). For example, a transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may receive a plurality of new Ethernet packets, as described above in conjunction with Figure 8-11 as described.

[0135] In some aspects, process 1200 may further include identifying that the plurality of new Ethernet packets have a set of common field values ​​in a set of common Ethernet header fields (block 1208). For example, the transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may identify that the plurality of new Ethernet packets have a set of common field values ​​in a set of common Ethernet header fields, as described above in conjunction with Figure 8-11 as described.

[0136] In some aspects, process 1200 may further include determining that the set of common field values ​​does not match known field values ​​corresponding to an existing context identifier (block 1210). For example, the transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may determine that the set of common field values ​​in the set of common Ethernet header fields does not match known field values ​​in multiple sets of known Ethernet header fields corresponding to existing context identifiers, as described above in conjunction with Figure 8-11 In some aspects, determining to create a new context identifier is responsive to determining that a match does not exist.

[0137] In some aspects, process 1200 may further include receiving a value for the set time period (block 1202). The value for the set time period may be received from a base station (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.). For example, a transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may receive the value for the set time period from a base station, as described above in conjunction with Figure 8-11 as described.

[0138] although Fig.12 An example block diagram of process 1200 is shown, but in some aspects, process 1200 may include Fig.12 Additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the process 1200. Additionally or alternatively, two or more blocks of the process 1200 may be executed in parallel.

[0139] Fig.131 is a diagram illustrating an example process 1300 performed, for example, by a receiver for managing Ethernet header compression state in accordance with various aspects of the present disclosure. The example process 1300 is an example in which a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) performs operations associated with Ethernet header compression and decompression in new radio.

[0140] like Fig.13 As shown in , in some aspects, process 1300 may include receiving a context delete message from a transmitter, the context delete message identifying a context identifier (block 1304). For example, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may receive a context delete message from a transmitter (e.g., transmitter 405, transmitter 505, base station 110, UE 120, network controller 130, etc.), the context delete message identifying a context identifier corresponding to an Ethernet packet header value, as described above in conjunction with Figure 8-11 The context delete message may include a packet data convergence protocol (PDCP) packet data unit (PDU), wherein the PDCP PDU header value is set to control or data. The context delete message may include a PDCP PDU packet, which includes an indication for indicating that the context delete message is a context delete message. The indication may be a value of a field in the PDCP PDU.

[0141] In some aspects, a PDCP PDU header value of the context delete message is set to data, a data field of the PDCP PDU of the context delete message is empty or includes padding bits, and the receiver ignores the data field of the PDCP PDU of the context delete message.

[0142] like Fig.13 As further shown in FIG. 1 , in some aspects, process 1300 may include removing an association between the context identifier and the Ethernet packet header value (block 1306). The association may be removed in response to receiving a context delete message. For example, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may remove the association between the context identifier and the Ethernet packet header value in response to receiving the context delete message, as described above in conjunction with Figure 8-11 Removing the association between the context identifier and the Ethernet packet header value may be removing the Ethernet packet header value from a memory associated with the receiver.

[0143] In some aspects, process 1300 may further include transmitting a deletion confirmation message to the transmitter (block 1308). For example, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may transmit a deletion confirmation message to a transmitter (e.g., transmitter 405, transmitter 505, base station 110, UE 120, network controller 130, etc.), as described above in conjunction with Figure 8-11 The deletion confirmation message may include a PDCP PDU, wherein the PDCP PDU header value is set to control or data. The deletion confirmation message may include a PDCP PDU, which includes an indication for indicating that the deletion confirmation message is a deletion confirmation message. The indication may be a value of a field in the PDCP PDU.

[0144] In some aspects, a PDCP PDU header value of the DELETE ACKNOWLEDGEMENT message is set to data, a data field of the PDCP PDU of the DELETE ACKNOWLEDGEMENT message is empty or includes padding bits, and the receiver ignores the data field of the PDCP PDU of the DELETE ACKNOWLEDGEMENT message.

[0145] In some aspects, the context deletion message includes a PDCP PDU header value set to "Control", a PDU type value set to "Ethernet Compression", and a subtype value set to "Delete", and the deletion confirmation message includes a PDCP header value set to "Control", a PDU type value set to "Ethernet Compression", and a subtype value set to "Delete Confirmation".

[0146] In some aspects, process 1300 may further include receiving a context creation packet from a transmitter (block 1310). The context creation packet may include the modified Ethernet packet header value and the context identifier. For example, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may receive a context creation packet from a transmitter (e.g., transmitter 405, transmitter 505, base station 110, UE 120, network controller 130, etc.), the context creation packet including the modified Ethernet packet header value and the context identifier, as described above in conjunction with Figure 8-11 as described.

[0147] In some aspects, process 1300 may further include storing an association between the context identifier and the modified Ethernet packet header value (block 1312). For example, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may store an association between the context identifier and the modified Ethernet packet header value, as described above in connection with Figure 8-11 as described.

[0148] In some aspects, process 1300 may further include receiving a compressed packet having an Ethernet compression header (block 1314). The Ethernet compression header may include the context identifier. For example, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may receive a compressed packet having an Ethernet compression header including the context identifier, as described above in conjunction with Figure 8-11 as described.

[0149] In some aspects, process 1300 may further include decompressing the Ethernet compressed header using the modified Ethernet packet header value (block 1316). For example, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may decompress the Ethernet compressed header using the modified Ethernet packet header value, as described above in conjunction with Figure 8-11 as described.

[0150] In some optional aspects, process 1300 may further include transmitting a value of the set time period to a transmitter (block 1302). The transmitter may determine to modify the context identifier based on the set time period. For example, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may transmit a value of the set time period to a transmitter (e.g., transmitter 405, transmitter 505, base station 110, UE 120, network controller 130, etc.), and the transmitter may determine to modify the context identifier based on the set time period, as described above in conjunction with Figure 8-11 as described.

[0151] Fig.14 1 is a diagram illustrating an example process 1400 performed, for example, by a transmitter and / or compressor, according to various aspects of Ethernet header compression context creation and / or context deletion operations described in the present disclosure. The example process 1400 is an example in which a transmitter (e.g., transmitter 405, transmitter 505, base station 110, UE 120, network controller 130, etc.) performs operations associated with Ethernet header compression in new radio.

[0152] like Fig.14As shown in , in some aspects, process 1400 may include transmitting a context creation message for a context identification (ID) associated with a flow of incoming Ethernet data traffic over a wireless communication link (block 1402). The context creation message may be transmitted to a base station (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.). For example, a transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may identify Ethernet data packets in a flow having a common header portion and create a context for these common portions. In addition, the transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may convert data representing the context creation message and the context identifier into a signal and transmit the context creation message for the context ID associated with the flow of incoming Ethernet data traffic over a wireless communication link via one or more antennas (e.g., antennas 234a to 234t or 252a to 252r), as described above in conjunction with Figure 8-13 as described.

[0153] In some aspects, process 1400 may include determining at the compressor whether an acknowledgment (ACK) signal is received from the decompressor in response to transmitting a context creation message for a context ID associated with a flow of incoming Ethernet data traffic over the wireless communication link (block 1404). For example, a transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may determine whether an ACK signal is received from the decompressor, as described above in conjunction with Figure 8-13 In addition, the transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) can receive a signal corresponding to an ACK signal indicating that the network node associated with the decompressor successfully received the context creation message after transmitting the context creation message.

[0154] In some aspects, determining whether an ACK signal is received from the decompressor further includes determining whether an ACK signal is received from the decompressor within a context creation time threshold for transmitting the context creation message. For example, in one implementation, the context creation time threshold corresponds to the time duration (e.g., maximum time) between each context creation packet that will be accepted by the decompressor and operated on. In an example, the context creation time threshold may be configured by a network node at a compressor. Thus, the compressor may receive the context creation time threshold from a network node, which may be associated with a decompressor. Thus, by causing the compressor to check the reception of an ACK from the decompressor within a time amount corresponding to the context creation time threshold, the present disclosure provides a configurable amount of time that the compressor must wait before creating or changing a context and allows the decompressor to be used to configure a new or changed context, thereby controlling the frequency of context changes. In some aspects, the context creation time threshold prevents unnecessary processing and / or transmission of compressed packets by configuring the compressor to wait for a period of time before making a determination about whether to continue compressing packets. Additionally, the context creation time threshold prevents the compressor from waiting unnecessarily long before making a determination regarding compressing a packet.

[0155] In an example, the value of the context creation time threshold may be based on a retransmission window of each of the plurality of context creation messages. Additionally, the plurality of context creation messages may be based on hybrid access repeat request (HARQ) transmission and radio link control (RLC) retransmission used by the network entity.

[0156] like Fig.14 As further shown in FIG. 14 , in some aspects, process 1400 may include refraining from transmitting, by the compressor, compressed packets corresponding to the stream to the decompressor over the wireless communication link based on a first determination that an ACK signal was not received from the decompressor (block 1406). For example, a transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may refrain from transmitting, by the compressor, compressed packets corresponding to the stream to the decompressor over the wireless communication link based on a first determination that an ACK signal was not received from the decompressor, as described above in conjunction with Figure 8-13 In some aspects, a transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may be configured to wait a minimum amount of time before transmitting a compressed packet based on a minimum context creation time threshold. Additionally, in the event that an ACK signal is not received from a network node associated with the decompressor, the transmitter may also wait until the maximum context creation time threshold expires before resuming transmission.

[0157] In some aspects, the context creation time threshold and process 1400 prevent unnecessary compression procedures from being performed and unnecessary transmission of compressed packets from occurring by introducing a context creation time threshold for receiving an ACK signal from a network node associated with a decompressor before the compressor makes a decision. Accordingly, the compressor and decompressor can remain synchronized and prevent packet content mismatches, retransmissions, and other errors from occurring.

[0158] In some aspects, process 1400 may include transmitting, by the compressor, the compressed packets corresponding to the stream to the decompressor over the wireless communication link based on a second determination that an ACK signal was received from the decompressor (block 1408). For example, a transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may transmit, by the compressor, the compressed packets corresponding to the stream to the decompressor over the wireless communication link based on a second determination that an ACK signal was received from the decompressor, as described above in connection with Figure 8-13 as described.

[0159] In some aspects, a compressor (e.g., compression component 520) may compress the packet by determining that the Ethernet header of the filtered Ethernet traffic is completely specified by a traffic flow template stored by TFT component 510. The Ethernet header may be completely specified by a traffic flow template when the traffic flow template includes specific values ​​(e.g., and not a range of values) for all required fields of the Ethernet header and each of those specific values ​​matches a corresponding value of a corresponding field included in an Ethernet header (e.g., of the incoming Ethernet traffic).

[0160] In some aspects, process 1400 may further include transmitting, by the compressor to the decompressor, a second context creation message based on a second determination that an ACK signal was not received from the decompressor within a context creation time threshold for transmitting the context creation message (block 1410). For example, a transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may transmit, by the compressor to the decompressor, a second context creation message based on a second determination that an ACK signal was not received from the decompressor within a context creation time threshold for transmitting the context creation message, as described above in conjunction with Figure 8-13 This allows the compressor to attempt another context creation after waiting a configured amount of time if a previous context creation was not acknowledged by the decompressor.

[0161] In some aspects, the transmitter may send the second context creation message at any time after the context creation time threshold. In other cases, the context creation time threshold includes a minimum context creation time threshold and a maximum context creation time threshold, which may define a time window associated with signaling context creation messages. For example, in this case, in order for effective context creation to occur, the transmitter may be configured to transmit the second context creation message after the minimum context creation time threshold expires and before the maximum context creation time threshold expires.

[0162] In some aspects, process 1400 may further include transmitting, by the compressor to the decompressor, a context delete message associated with the context ID (block 1412). For example, a transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may transmit, by the compressor to the decompressor, a context delete message associated with the context ID, as described above in conjunction with Figure 8-13 In addition, a transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) can convert data representing the context deletion message into a signal and transmit the signal over a wireless communication link via one or more antennas (e.g., antennas 234a to 234t or 252a to 252r).

[0163] In some aspects, process 1400 may further include terminating, by the compressor, compression associated with the flow of incoming Ethernet traffic associated with the context ID upon transmitting the context delete message (block 1414). For example, the transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may terminate, by the compressor, compression associated with the flow of incoming Ethernet traffic associated with the context ID upon transmitting the context delete message, as described above in connection with Figure 8-13 In one example, a compressor (e.g., compression component 520) may receive a signal / indication from a transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290) that a context delete message was transmitted and that compression associated with the flow of incoming Ethernet traffic associated with the context ID is to be stopped.

[0164] In some aspects, process 1400 may further include transmitting, by the compressor, one or more uncompressed packets associated with the context ID for the flow in response to transmitting the context delete message (block 1416). For example, a transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290, compression component 520, etc.) may transmit, by the compressor, one or more uncompressed packets associated with the context ID for the flow in response to transmitting the context delete message, as described above in connection with Figure 8-13 As described. In one example, the compressor (e.g., compression component 520) may receive a signal / indication from a transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290) that a context delete message has been transmitted and that compression associated with the flow of incoming Ethernet traffic associated with the context ID is to be stopped. Accordingly, the transmitter (e.g., using controller / processor 240, controller / processor 280, controller / processor 290) may then transmit the uncompressed packet by converting data representing the uncompressed packet into a signal and transmitting the signal over a wireless communication link via one or more antennas (e.g., antennas 234a to 234t or 252a to 252r).

[0165] In some aspects, process 1400 may further include: determining by the compressor whether a second ACK signal is received from the decompressor in response to transmitting the context deletion message; and transmitting by the compressor to the decompressor a second context deletion message based on the determination that the second ACK is not received from the decompressor. For example, determining whether the second ACK signal is received from the decompressor further includes determining whether the second ACK signal is received from the decompressor within a context deletion time threshold. In another example, the compressor may receive the context deletion time threshold from the decompressor.

[0166] Thus, in summary, the operation of the compressor may include utilizing context to create packets. For example, the compressor will continue to transmit uncompressed packets until receiving an ACK signal from the decompressor. In addition, if the compressor does not receive an ACK signal, the compressor may be configured to retransmit the context to create packets after the context creation time threshold expires. Additionally, the compressor is configured to transmit a context deletion message, from which point on the compressor will transmit uncompressed packets. However, the compressor will not reuse the same context ID until receiving an ACK signal associated with the context deletion message.

[0167] Fig.151 is a diagram illustrating an example process 1500 performed, for example, by a receiver in accordance with various aspects of the present disclosure. Example process 1500 is an example in which a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) performs operations associated with Ethernet header compression and decompression in new radio.

[0168] like Fig.15 As shown in , in some aspects, process 1500 may include receiving, by a decompressor, one or more compressed packets associated with a context identifier (ID) of a flow corresponding to incoming Ethernet data traffic from a compressor and over a wireless communication link (block 1502). For example, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may receive, by a decompressor, one or more compressed packets associated with a context identifier (ID) of a flow corresponding to incoming Ethernet data traffic from a compressor and over a wireless communication link, as described above in conjunction with Figure 8-13 Furthermore, a receiver (eg, receiver 605, base station 110, UE 120, network controller 130, etc.) may convert the signal into data representing one or more compressed packets associated with the context ID.

[0169] In some aspects, process 1500 may include determining, by the decompressor, whether a context creation message associated with the context ID is received from the compressor (block 1504). For example, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may determine, by the decompressor, whether a context creation message associated with the context ID is received from the compressor, as described above in conjunction with Figure 8-13 as described.

[0170] In some aspects, determining whether a context creation message associated with the context ID is received from the compressor further comprises determining whether the context creation message is received prior to receiving the one or more compressed packets.

[0171] For example, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may be configured to: based on a determination that a context creation message is received before receiving one or more compressed packets, buffer the one or more compressed packets by a decompressor for a time period; determine by the decompressor whether a context creation message associated with the context ID is received from the compressor before the time period expires; and based on receiving a context creation message associated with the context ID from the compressor before the time period expires, decompress the one or more compressed packets by the decompressor. In addition, the receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may store the one or more compressed packets in memory 292 until the time period expires.

[0172] In another example, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may be configured to discard the one or more compressed packets by the decompressor based on a determination that a context creation message associated with the context ID was not received from the compressor before expiration of the time period.

[0173] In some aspects, process 1500 may include discarding, by the decompressor, the one or more compressed packets based on a determination that a context creation message associated with the context ID was not received from the compressor (block 1506). For example, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may discard, by the decompressor, the one or more compressed packets based on a determination that a context creation message associated with the context ID was not received from the compressor, as described above in conjunction with Figure 8-13 In addition, the receiver (eg, receiver 605, base station 110, UE 120, network controller 130, etc.) may delete the one or more compressed packets from memory 292.

[0174] In some aspects, process 1500 may include decompressing, by a decompressor, the one or more compressed packets based on a determination that a context creation message associated with the context ID is received from the compressor (block 1508). For example, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may decompress, by a decompressor, the one or more compressed packets based on a determination that a context creation message associated with the context ID is received from the compressor, as described above in conjunction with Figure 8-13 Furthermore, a decompressor (e.g., header reconstruction component 615) or a receiver (e.g., receiver 605) may need to be prepared for any incoming packets to replace an existing compression context, in which case it may need to deliver this packet to a higher layer and perform context modification procedures within a tight URLLC time limit.

[0175] In some aspects, process 1500 may include receiving, by the decompressor, a context delete message associated with the context ID from the compressor (block 1510). For example, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may receive, by the decompressor, a context delete message associated with the context ID from the compressor, as described above in conjunction with Figure 8-13 as described.

[0176] In some aspects, process 1500 may include discarding, by the decompressor, any of the one or more subsequent compressed packets associated with the context ID in response to receiving the context delete message (block 1512). For example, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may discard, by the decompressor, any of the one or more subsequent compressed packets associated with the context ID in response to receiving the context delete message, as described above in conjunction with Figure 8-13 as described.

[0177] In some aspects, process 1500 may include transmitting an acknowledgment (ACK) signal in response to receiving the context delete message (block 1514). For example, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may transmit an acknowledgment (ACK) signal in response to receiving the context delete message, as described above in conjunction with Figure 8-13 In addition, the receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may convert data representing the ACK signal into a signal and transmit the ACK signal to the compressor via one or more antennas (e.g., antennas 234a to 234t or 252a to 252r) through a wireless communication link.

[0178] In some aspects, process 1500 may include receiving a new context creation message associated with the context ID (block 1516). For example, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may receive a new context creation message associated with the context ID, as described above in conjunction with Figure 8-13 Furthermore, a receiver (eg, receiver 605, base station 110, UE 120, network controller 130, etc.) may convert the signal into data representing a new context creation message.

[0179] In some aspects, process 1500 may include, in response to transmitting the ACK signal and receiving the new context creation message, creating a new context for the context ID based on the new context creation message (block 1518). For example, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may create a new context for the context ID based on the new context creation message in response to transmitting the ACK signal and receiving the new context creation message, as described above in conjunction with Figure 8-13 In some aspects, a receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) may ignore packets associated with a current context ID or a request for the same context ID. Accordingly, the new context allows the receiver (e.g., receiver 605, base station 110, UE 120, network controller 130, etc.) to decompress any received compressed packets.

[0180] Thus, in summary, the decompressor is configured to expect to receive uncompressed packets until the decompressor receives the context creation message. For example, after receiving the context creation message, the decompressor is configured to transmit an ACK signal. When transmitting the ACK signal, the decompressor expects compressed and / or uncompressed packets. In addition, the decompressor can ignore the context request of the same context ID until the context deletion message is processed. Additionally, after transmitting the context deletion ACK signal, the context creation message with the same context ID can be accepted by the decompressor.

[0181] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the aspects to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired by practice of the various aspects.

[0182] As used herein, the term component is intended to be broadly interpreted as hardware, firmware, or a combination of hardware and software. As used herein, a processor is implemented with hardware, firmware, or a combination of hardware and software.

[0183] Some aspects are described herein in conjunction with thresholds. As used herein, satisfying a threshold may mean: a value is greater than a threshold, greater than or equal to a threshold, less than a threshold, less than or equal to a threshold, equal to a threshold, not equal to a threshold, etc.

[0184] It will be apparent that the systems and / or methods described herein can be implemented in different forms of hardware, firmware, or a combination of hardware and software. Actual dedicated control hardware or software code for implementing these systems and / or methods does not limit the various aspects. Thus, the operation and behavior of these systems and / or methods are described herein without reference to specific software codes-it is understood that software and hardware can be designed to implement these systems and / or methods based at least in part on the description herein.

[0185] Although specific feature combinations are described in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of possible aspects. In fact, many of these features can be combined in a manner not specifically described in the claims and / or not disclosed in the specification. Although each dependent claim listed below can be directly subordinate to only one claim, the disclosure of possible aspects includes that each dependent claim is combined with each other claim in this group of claims. The phrase "at least one" quoted in a column of items refers to any combination of these items, including single members. As an example, "at least one of a, b or c" is intended to cover: a, b, c, ab, ac, bc, and abc, and any combination with multiple identical elements (for example, aa, aaa, aab, aac, abb, acc, bb, bbb, bbc, cc, and ccc, or any other sorting of a, b and c).

[0186] Elements, actions or instructions used herein should not be interpreted as critical or necessary unless explicitly described as such. Moreover, as used herein, the articles "one" and "a" are intended to include one or more items and can be used interchangeably with "one or more". In addition, as used herein, the terms "set" and "group" are intended to include one or more items (e.g., related items, non-related items, combinations of related and non-related items, etc.), and can be used interchangeably with "one or more". In the case of intending to have only one item, the term "one" or similar language is used. Moreover, as used herein, the terms "having", "containing", "including", etc. are intended to be open terms. In addition, the phrase "based on" is intended to mean "based at least in part on", unless otherwise explicitly stated.

Claims

1. A method at a device configured to process both wireless data traffic and Ethernet data traffic into wireless communications, comprising: determining at the compressor whether an acknowledgement (ACK) signal is received from the decompressor in response to transmitting a context creation message for a context identification (ID) associated with a flow of incoming Ethernet data traffic over the wireless communication link; refraining from transmitting, by the compressor to the decompressor over the wireless communication link, compressed packets corresponding to the flow based on a first determination that the ACK signal was not received from the decompressor; transmitting, by the compressor to the decompressor, a second context creation message based on a second determination that the ACK signal was not received from the decompressor within a context creation time threshold for transmitting the context creation message; transmitting, by the compressor to the decompressor over the wireless communication link, compressed packets corresponding to the flow based on a third determination that a subsequent ACK signal was received from the decompressor in response to transmitting the second context creation message; as well as It is determined at the compressor that the flow associated with the context ID is not currently receiving any traffic and a different flow is associated with the context ID.

2. The method of claim 1, wherein determining whether the ACK signal is received from the decompressor further comprises determining whether the ACK signal is received from the decompressor within a context creation time threshold for transmitting the context creation message. 3 . The method of claim 2 , wherein the context creation time threshold corresponds to a maximum time duration between context creation packets.

4. The method of claim 2, further comprising receiving, at the compressor, the context creation time threshold from a network node associated with the decompressor. 5 . The method of claim 2 , wherein the context creation time threshold comprises a minimum context creation time threshold and a maximum context creation time threshold. 6 . The method of claim 5 , wherein transmitting the second context creation message comprises transmitting after the minimum context creation time threshold and before expiration of the maximum context creation time threshold.

7. The method of claim 4, wherein the context creation time threshold is based on a retransmission window of each of a plurality of context creation messages.

8. The method of claim 7, wherein the plurality of context creation messages are based on Hybrid Access Repeat Request (HARQ) transmission and Radio Link Control (RLC) retransmission used by a network entity.

9. The method of claim 1, further comprising: transmitting, by the compressor to the decompressor, a context delete message associated with the context ID; terminating, by the compressor, compression associated with the flow of the incoming Ethernet data traffic associated with the context ID upon transmitting the context delete message; as well as One or more uncompressed packets associated with the context ID for the flow are transmitted by the compressor in response to transmitting the context delete message.

10. The method of claim 9, further comprising: determining, by the compressor, whether a second ACK signal is received from the decompressor in response to transmitting the context delete message; as well as A second context delete message is transmitted by the compressor to the decompressor based on a determination that the second ACK was not received from the decompressor.

11. The method of claim 10, wherein determining whether the second ACK signal is received from the decompressor further comprises determining whether the second ACK signal is received from the decompressor within a context deletion time threshold.

12. The method of claim 11, further comprising receiving, at the compressor, the context deletion time threshold from the decompressor.

13. An apparatus configured to process both wireless data traffic and Ethernet data traffic into wireless communications, comprising: Memory; as well as a processor in communication with the memory, wherein the processor is configured to: determining at the compressor whether an acknowledgement (ACK) signal is received from the decompressor in response to transmitting a context creation message for a context identification (ID) associated with a flow of incoming Ethernet data traffic over the wireless communication link; refraining from transmitting, by the compressor to the decompressor over the wireless communication link, compressed packets corresponding to the flow based on a first determination that the ACK signal was not received from the decompressor; transmitting, by the compressor to the decompressor, a second context creation message based on a second determination that the ACK signal was not received from the decompressor within a context creation time threshold for transmitting the context creation message; transmitting, by the compressor to the decompressor over the wireless communication link, compressed packets corresponding to the flow based on a third determination that a subsequent ACK signal was received from the decompressor in response to transmitting the second context creation message; as well as It is determined at the compressor that the flow associated with the context ID is not currently receiving any traffic and a different flow is associated with the context ID.

14. The apparatus of claim 13, wherein the processor configured to determine whether the ACK signal is received from the decompressor is further configured to determine whether the ACK signal is received from the decompressor within a context creation time threshold for transmitting the context creation message.

15. The apparatus of claim 14, wherein the context creation time threshold corresponds to a maximum time duration between context creation packets.

16. The apparatus of claim 14, wherein the processor is further configured to receive the context creation time threshold at the compressor from a network node associated with the decompressor. 17 . The apparatus of claim 14 , wherein the context creation time threshold comprises a minimum context creation time threshold and a maximum context creation time threshold.

18. The apparatus of claim 17, wherein the processor configured to transmit the second context creation message is further configured to transmit after the minimum context creation time threshold and before expiration of the maximum context creation time threshold.

19. The apparatus of claim 16, wherein the context creation time threshold is based on a retransmission window of each of a plurality of context creation messages.

20. The apparatus of claim 19, wherein the plurality of context creation messages are based on hybrid access repeat request (HARQ) transmission and radio link control (RLC) retransmission used by a network entity.

21. The apparatus of claim 13, wherein the processor is further configured to: transmitting, by the compressor to the decompressor, a context delete message associated with the context ID; terminating, by the compressor, compression associated with the flow of the incoming Ethernet data traffic associated with the context ID upon transmitting the context delete message; and One or more uncompressed packets associated with the context ID for the flow are transmitted by the compressor in response to transmitting the context delete message.

22. The apparatus of claim 21, wherein the processor is further configured to: determining, by the compressor, whether a second ACK signal is received from the decompressor in response to transmitting the context delete message; and A second context delete message is transmitted by the compressor to the decompressor based on a determination that the second ACK was not received from the decompressor.

23. The apparatus of claim 22, wherein the processor configured to determine whether the second ACK signal is received from the decompressor is further configured to determine whether the second ACK signal is received from the decompressor within a context deletion time threshold.

24. The apparatus of claim 23, wherein the processor is configured to receive the context deletion time threshold at the compressor from the decompressor.

25. A device configured to process both wireless data traffic and Ethernet data traffic into wireless communications, comprising: means for determining at the compressor whether an acknowledgement (ACK) signal is received from the decompressor in response to transmitting a context creation message for a context identification (ID) associated with a flow of incoming Ethernet data traffic over the wireless communication link; means for refraining from transmitting, by the compressor to the decompressor over the wireless communication link, compressed packets corresponding to the flow based on a first determination that the ACK signal was not received from the decompressor; means for transmitting, by the compressor to the decompressor, a second context creation message based on a second determination that the ACK signal was not received from the decompressor within a context creation time threshold for transmitting the context creation message; means for transmitting, by the compressor to the decompressor over the wireless communication link, compressed packets corresponding to the flow based on a third determination that a subsequent ACK signal is received from the decompressor in response to transmitting the second context creation message; as well as Means for determining, at the compressor, that the flow associated with the context ID is not currently receiving any traffic and associating a different flow with the context ID.

26. A non-transitory computer readable medium storing instructions executable by a processor and configured to process both wireless data traffic and Ethernet data traffic into wireless communications, comprising: code for determining at a compressor whether an acknowledgement (ACK) signal is received from a decompressor in response to transmitting a context creation message for a context identification (ID) associated with a flow of incoming Ethernet data traffic over a wireless communication link; code for refraining from transmitting, by the compressor to the decompressor over the wireless communication link, compressed packets corresponding to the flow based on a first determination that the ACK signal was not received from the decompressor; code for transmitting, by the compressor to the decompressor, a second context creation message based on a second determination that the ACK signal was not received from the decompressor within a context creation time threshold for transmitting the context creation message; code for transmitting, by the compressor to the decompressor over the wireless communication link, compressed packets corresponding to the flow based on a third determination that a subsequent ACK signal was received from the decompressor in response to transmitting the second context creation message; as well as Code for determining, at the compressor, that the flow associated with the context ID is not currently receiving any traffic and associating a different flow with the context ID.

Images