Patent Description:
Wireless communication systems are widely deployed to provide various types of communication content such as voice, data, and so on. These systems may be multiple-access systems capable of supporting communication with multiple users by sharing the available system resources (e.g., bandwidth and transmit power). Examples of such multiple-access systems include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) systems and orthogonal frequency division multiple access (OFDMA) systems.

Generally, a wireless multiple-access communication system can simultaneously support communication for multiple wireless terminals. Each terminal communicates with one or more base stations via transmissions on the forward and reverse links. The forward link (or downlink) refers to the communication link from the base stations to the terminals, and the reverse link (or uplink) refers to the communication link from the terminals to the base stations. This communication link may be established via a single-input single-output, multiple-input single-output or a multiple-input multiple-output (MIMO) system.

A MIMO system employs multiple (NT) transmit antennas and multiple (NR) receive antennas for data transmission. A MIMO channel formed by the NT transmit and NR receive antennas may be decomposed into NS independent channels, which are also referred to as spatial channels. Each of the NS independent channels corresponds to a dimension. The MIMO system can provide improved performance (e.g., higher throughput and/or greater reliability) if the additional dimensionalities created by the multiple transmit and receive antennas are utilized.

A user equipment (UE) may be located within the coverage of multiple wireless networks, which may support different communication services. A suitable wireless network may be selected to serve the UE based on one or more criteria. The selected wireless network may be unable to provide a desired communication service (e.g., voice service) for the UE. A set of procedures may then be performed to redirect the UE to another wireless network (e.g., <NUM>, <NUM> or non-LTE <NUM>) that can provide the desired communication service.

<CIT> relates to compression of messages in communications using data protocols, e.g., Internet protocols.

<CIT> discloses a method of compressing data using a dictionary-based algorithm in a wireless sensor network, including machine-to-machine devices, e.g., IoT sensors, whereby a dictionary of repetitive patterns is built while scanning an input message. The patterns found in the input are replaced with indices to the dictionary.

Techniques and apparatus are provided herein for compressing data packets for communications with cellular internet of things (CloT) devices. By compressing header and/or payload content of a data packet in communications with CIoT devices, transmitting devices can reduce the amount of overhead used in communicating with devices via small and infrequent data packets.

The techniques described herein may be used for various wireless communication networks such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA) and other networks. A CDMA network may implement a radio access technology (RAT) such as universal terrestrial radio access (UTRA), cdma2000, etc. UTRA includes wideband CDMA (WCDMA) and other variants of CDMA. IS-<NUM> is also referred to as 1x radio transmission technology (1xRTT), CDMA2000 1X, etc. A TDMA network may implement a RAT such as global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), or GSM/EDGE radio access network (GERAN). An OFDMA network may implement a RAT such as evolved UTRA (E-UTRA), ultra mobile broadband (UMB), IEEE <NUM> (Wi-Fi), IEEE <NUM> (WiMAX), IEEE <NUM>, Flash-OFDM. , etc. UTRA and E-UTRA are part of universal mobile telecommunication system (UMTS). 3GPP long-term evolution (LTE) and LTE-Advanced (LTE-A) are new releases of UMTS that use E-UTRA, which employs OFDMA on the downlink and SC-FDMA on the uplink. The techniques described herein may be used for the wireless networks and RATs mentioned above as well as other wireless networks and RATs.

<FIG> shows an exemplary deployment in which multiple wireless networks have overlapping coverage. An evolved universal terrestrial radio access network (E-UTRAN) <NUM> may support LTE and may include a number of evolved Node Bs (eNBs) <NUM> and other network entities that can support wireless communication for user equipments <NUM> (UEs). Each eNB <NUM> may provide communication coverage for a particular geographic area. The term "cell" can refer to a coverage area of an eNB and/or an eNB subsystem serving this coverage area. A serving gateway (S-GW) <NUM> may communicate with E-UTRAN <NUM> and may perform various functions such as packet routing and forwarding, mobility anchoring, packet buffering, initiation of network-triggered services, etc. A mobility management entity (MME) <NUM> may communicate with E-UTRAN <NUM> and serving gateway <NUM> and may perform various functions such as mobility management, bearer management, distribution of paging messages, security control, authentication, gateway selection, etc. The network entities in LTE are described in <NPL>" which is publicly available.

A radio access network (RAN) <NUM> may support GSM and may include a number of base stations <NUM> and other network entities that can support wireless communication for UEs. A mobile switching center (MSC) <NUM> may communicate with the RAN <NUM> and may support voice services, provide routing for circuit-switched calls, and perform mobility management for UEs located within the area served by MSC <NUM>. Optionally, an inter-working function (IWF) <NUM> may facilitate communication between MME <NUM> and MSC <NUM> (e.g., for 1xCSFB).

E-UTRAN <NUM>, serving gateway <NUM>, and MME <NUM> may be part of an LTE network <NUM>. RAN <NUM> and MSC <NUM> may be part of a GSM network <NUM>. For simplicity, <FIG> shows only some network entities in the LTE network <NUM> and the GSM network <NUM>. The LTE and GSM networks may also include other network entities that may support various functions and services.

A UE <NUM> may be stationary or mobile and may also be referred to as a mobile station, a terminal, an access terminal, a subscriber unit, a station, etc. UE <NUM> may be a cellular 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, etc..

Upon power up, UE <NUM> may search for wireless networks from which it can receive communication services. If more than one wireless network is detected, then a wireless network with the highest priority may be selected to serve UE <NUM> and may be referred to as the serving network. UE <NUM> may perform registration with the serving network, if necessary. UE <NUM> may then operate in a connected mode to actively communicate with the serving network. Alternatively, UE <NUM> may operate in an idle mode and camp on the serving network if active communication is not required by UE <NUM>.

UE <NUM> may be located within the coverage of cells of multiple frequencies and/or multiple RATs while in the idle mode. For LTE, UE <NUM> may select a frequency and a RAT to camp on based on a priority list. This priority list may include a set of frequencies, a RAT associated with each frequency, and a priority of each frequency. For example, the priority list may include three frequencies X, Y and Z. Frequency X may be used for LTE and may have the highest priority, frequency Y may be used for GSM and may have the lowest priority, and frequency Z may also be used for GSM and may have medium priority. In general, the priority list may include any number of frequencies for any set of RATs and may be specific for the UE location. UE <NUM> may be configured to prefer LTE, when available, by defining the priority list with LTE frequencies at the highest priority and with frequencies for other RATs at lower priorities, e.g., as given by the example above.

UE <NUM> may operate in the idle mode as follows. UE <NUM> may identify all frequencies/RATs on which it is able to find a "suitable" cell in a normal scenario or an "acceptable" cell in an emergency scenario, where "suitable" and "acceptable" are specified in the LTE standards. UE <NUM> may then camp on the frequency/RAT with the highest priority among all identified frequencies/RATs. UE <NUM> may remain camped on this frequency/RAT until either (i) the frequency/RAT is no longer available at a predetermined threshold or (ii) another frequency/RAT with a higher priority reaches this threshold. This operating behavior for UE <NUM> in the idle mode is described in <NPL>" which is publicly available.

UE <NUM> may be able to receive packet-switched (PS) data services from LTE network <NUM> and may camp on the LTE network while in the idle mode. LTE network <NUM> may have limited or no support for voice-over-Intemet protocol (VoIP), which may often be the case for early deployments of LTE networks. Due to the limited VoIP support, UE <NUM> may be transferred to another wireless network of another RAT for voice calls. This transfer may be referred to as circuit-switched (CS) fallback. UE <NUM> may be transferred to a RAT that can support voice service such as 1xRTT, WCDMA, GSM, etc. For call origination with CS fallback, UE <NUM> may initially become connected to a wireless network of a source RAT (e.g., LTE) that may not support voice service. The UE may originate a voice call with this wireless network and may be transferred through higher-layer signaling to another wireless network of a target RAT that can support the voice call. The higher-layer signaling to transfer the UE to the target RAT may be for various procedures, e.g., connection release with redirection, PS handover, etc..

As described in greater detail below, in some embodiments, the Node Bs <NUM> may implement the functionality described herein for improving user experience of a voice call associated with a device, such as simultaneous voice and long-term evolution (SV-LTE) device, (e.g., improving silent redial in mobile originated calls). For example, a Node B may detect failures during mobile originated calls from a UE and may redirect the UE to another system in an effort to speed up a silent redial procedure.

As described in greater detail below, in some embodiments, the UEs <NUM> may implement the functionality described herein for improving user experience of a voice call associated with a device, such as a simultaneous voice and long-term evolution (SV-LTE) device, (e.g., improving silent redial in mobile originated calls). For example, the UE may maintain timers, counts, and/or thresholds for use in silent redial. UE <NUM> may also detect a failure during mobile originated call, determine how to attempt retrying the call, select a subsequent system for attempting the call, and attempt to retry the call as described herein.

<FIG> shows a block diagram of a design of UE <NUM>, eNB <NUM>, and MME <NUM> in <FIG>. At UE <NUM>, an encoder <NUM> may receive traffic data and signaling messages to be sent on the uplink. Encoder <NUM> may process (e.g., format, encode, and interleave) the traffic data and signaling messages. A modulator (Mod) <NUM> may further process (e.g., symbol map and modulate) the encoded traffic data and signaling messages and provide output samples. A transmitter (TMTR) <NUM> may condition (e.g., convert to analog, filter, amplify, and frequency upconvert) the output samples and generate an uplink signal, which may be transmitted via an antenna <NUM> to eNB <NUM>.

On the downlink, antenna <NUM> may receive downlink signals transmitted by eNB <NUM> and/or other eNBs/base stations. A receiver (RCVR) <NUM> may condition (e.g., filter, amplify, frequency downconvert, and digitize) the received signal from antenna <NUM> and provide input samples. A demodulator (Demod) <NUM> may process (e.g., demodulate) the input samples and provide symbol estimates. A decoder <NUM> may process (e.g., deinterleave and decode) the symbol estimates and provide decoded data and signaling messages sent to UE <NUM>. Encoder <NUM>, modulator <NUM>, demodulator <NUM>, and decoder <NUM> may be implemented by a modem processor <NUM>. These units may perform processing in accordance with the RAT (e.g., LTE, 1xRTT, etc.) used by the wireless network with which UE <NUM> is in communication.

A controller/processor <NUM> may direct the operation at UE <NUM>. Controller/processor <NUM> may also perform or direct other processes for the techniques described herein. Controller/processor <NUM> may also perform or direct the processing by UE. Memory <NUM> may store program codes and data for UE <NUM>. Memory <NUM> may also store a priority list and configuration information.

At eNB <NUM>, a transmitter/receiver <NUM> may support radio communication with UE <NUM> and other UEs. A controller/processor <NUM> may perform various functions for communication with the UEs. On the uplink, the uplink signal from UE <NUM> may be received via an antenna <NUM>, conditioned by receiver <NUM>, and further processed by controller/processor <NUM> to recover the traffic data and signaling messages sent by UE <NUM>. On the downlink, traffic data and signaling messages may be processed by controller/processor <NUM> and conditioned by transmitter <NUM> to generate a downlink signal, which may be transmitted via antenna <NUM> to UE <NUM> and other UEs. Controller/processor <NUM> may also perform or direct other processes for the techniques described herein. Controller/processor <NUM> may also perform or direct the processing by eNB <NUM>. Memory <NUM> may store program codes and data for the base station. A communication (Comm) unit <NUM> may support communication with MME <NUM> and/or other network entities.

In some cases, controller/processor <NUM> and/or controller/processor <NUM> may be configured to perform techniques presented herein to detect and recover from sequence number de-synchronization (e.g., operations <NUM> shown in <FIG>).

At MME <NUM>, a controller/processor <NUM> may perform various functions to support communication services for UEs. Controller/processor <NUM> may also perform or direct the processing by MME <NUM> in <FIG> and <FIG>. Memory <NUM> may store program codes and data for MME <NUM>. A communication unit <NUM> may support communication with other network entities.

<FIG> shows simplified designs of UE <NUM>, eNB <NUM>, and MME <NUM>. In general, each entity may include any number of transmitters, receivers, processors, controllers, memories, communication units, etc. Other network entities may also be implemented in similar manner.

Aspects of the present disclosure provide techniques for compressing header and/or payload portions of data packets transmitted between cellular internet of things (CIoT) devices. By compressing header and/or payload portions of data packets in CIoT communications, overhead can be reduced relative to an uncompressed packet.

In some cases, packet header and/or payload can be compressed based on the contents of a prefill buffer preloaded at the compressor and decompressor. The prefill buffer may include common strings and may associate each common string with an identifier, such as a memory address (pointer) or other identifier. When a transmitting device (e.g., a CIoT UE or CIoT serving gateway node) generates a packet for transmission, the transmitting device can replace matched strings stored in the prefill buffer with the associated identifier to generate a compressed packet. On receipt of the compressed packet, the receiving device can refer to the prefill buffer to replace an identifier carried in the compressed packet with the associated common string from the prefill buffer. By replacing strings with shorter identifiers, the size of a packet header and/or payload may be reduced.

In CIoT, compressed packets may be transmitted in non-access stratum (NAS) data protocol data units (PDUs). Because NAS PDUs are generally encrypted, transmitting devices can compress the data carried in a packet before the packet is encapsulated into an NAS PDU and transmitted. For CIoT data, which may have a small data size (e.g., <NUM>-<NUM> bytes) and may be transmitted infrequently, transmitting uncompressed data can impose additional overhead. Additionally, configuring CIoT UEs to use a particular prefill buffer regularly (e.g., via radio resource control (RRC) signaling) may increase transmission overhead.

To reduce an amount of overhead for CIoT communications, aspects of the present disclosure provide techniques for using prefill buffers common to one or more UEs to store commonly-transmitted strings. As discussed in further detail herein, transmitting devices can use the prefill buffers common to one or more UEs to replace commonly transmitted strings with one or more identifiers (e.g., pointers to the string in a prefill buffer) and reduce the size of a transmitted packet. Meanwhile, receiving devices can use an indication that a received packet is compressed and the prefill buffers common to one or more UEs to replace the one or more identifiers in the received, compressed packet with the one or more common strings associated with the identifiers included in the received packet. In some cases, the transmitting and receiving devices need not engage in packet exchanges prior to transmission and reception of compressed packets (e.g., transmission of one or more packets including a prefill buffer to be used by a transmitting device for generating compressed packets for transmission) in order to enable data compression for CIoT communications.

<FIG> illustrates example operations that may be performed by a transmitting device to generate and transmit a compressed packet, according to an embodiment. As illustrated, operations <NUM> begin at <NUM>, where a transmitting device establishes at least one prefill buffer common to one or more user equipments (UEs). The prefill buffer generally includes common strings and may include associations to corresponding identifiers.

At <NUM>, the transmitting device generates a compressed packet. The compressed packet generally includes one or more of the identifiers in at least one of a header portion or a payload portion of the packet. As discussed herein, the compressed packet can include an identifier in place of a longer string, which can reduce the size of the compressed packet relative to an uncompressed packet in which common strings are not replaced by the corresponding identifier in a prefill buffer. In generating the compressed packet, the transmitting device can find matches to common strings in the prefill buffer with data in the header and/or payload of the packet, associate an identifier to each of the common strings found in the header and/or payload of the packet, and replace the common strings with the associated identifiers. At <NUM>, the transmitting device transmits the packet. As discussed, the packet may be encapsulated in an NAS PDU for transmission.

<FIG> illustrates example operations that may be performed by a receiving device to receive and decompress a compressed packet, according to an embodiment. As illustrated, operations <NUM> begin at <NUM>, where a receiving device receives a compressed packet. The packet generally includes at least one identifier corresponding to a common string.

At <NUM>, the receiving device processes the packet. To process the packet, the receiving device retrieves the common string from a prefill buffer common to one or more user equipments (UEs) using the identifier.

To generate compressed packets for CIoT, one or more prefill buffers may be established at a CIoT serving gateway node (C-SGN), which may include a mobile management entity (MME) for CIoT devices. These prefill buffers may be common to a plurality of UEs. By maintaining prefill buffers at a C-SGN for a plurality of UEs, the C-SGN need not maintain a compression context for each UE (e.g., need not track the prefill buffer used for communications with each UE). During a UE attach procedure, a C-SGN can identify the prefill buffer to use for compressing and decompressing packets, and the UE and C-SGN may use the identified prefill buffer to compress and decompress packets while the UE is attached to the C-SGN. The identification of the prefill buffer to be used for compressing and decompressing packets may be, for example, a checksum or other unique identifier (e.g., a Universally Unique Identifier, or UUID) associated with the specific prefill buffer. In some cases, the UE and C-SGN may exchange the identification of the prefill buffer upon establishing a connection and need not exchange additional packets beyond an identification of the prefill buffer to be used for compression and decompression of packets in order for the UE and C-SGN to transmit and receive compressed packets.

In some cases, the prefill buffers may be generated on a per-application basis. A prefill buffer generated for a specific application may include one or more common strings used by the application. In some cases, where multiple prefill buffers are established at a C-SGN, one of the prefill buffers may be designated as a default prefill buffer. The default prefill buffer may include common strings in packet headers and may include an association with an identifier but need not include identifiers associated with strings present in a packet payload. In some cases (e.g., when the payload format of an application is not yet known), the transmitting and receiving devices can use the default prefill buffer to compress and decompress the header of transmitted packets, while leaving the payload of a transmitted packet uncompressed. A transmitting device can, in some cases, choose the default prefill buffer during runtime to compress a packet upon determining that the payload of the packet does not include compressible data. In some cases, different prefill buffers may be established for uplink and downlink communications.

In some cases, the prefill buffers may include a plurality of identifiers associated with known server information, such as destination internet protocol (IP) addresses. While certain fields (e.g. a UE IP address) may be known at the C-SGN, the prefill buffer need not include an identifier associated with the fields (e.g., UE IP address). When a transmitting device generates a compressed packet including, for example, the UE IP address, the transmitting device can indicate the presence of the UE IP address in the packet using an identifier that is not included in the prefill buffers.

The prefill buffers used by a CIoT UE and C-SGN may be fixed in content. Because the contents of the prefill buffers may be fixed, the prefill buffers used by the UE and C-SGN may remain synchronized. Additionally, as the prefill buffers are not updated during communications between the UE and C-SGN, packets may be received in order or out of order. Further, because the contents of the prefill buffers may be fixed, UEs and C-SGNs need not establish prefill buffers after the attach procedure, which may shorten an amount of time needed for context setup. Compression may be applied to the first packet transmitted by a transmitting device using the contents of the prefill buffer identified during the attach procedure.

<FIG> illustrates an example system architecture <NUM> for performing compression of packets in CIoT communications, according to an embodiment. As illustrated, an uplink data compressor may be included as part of the data over non-access stratum (NAS) convergence protocol. As discussed above, the uplink data compressor may compress uplink data by using the contents of one or more prefill buffers to replace commonly transmitted strings with identifiers in the prefill buffers, which may reduce the size of a message transmitted from a transmitting device (e.g., UE <NUM> illustrated in <FIG>) to a receiving device (e.g., C-SGN <NUM> illustrated in <FIG>). At the transmitting device (e.g., UE <NUM> illustrated in <FIG>), data compression may be performed on a packet before the packet is encapsulated in an NAS PDU and transmitted to another device. At a receiving device (e.g., C-SGN <NUM> illustrated in <FIG>), data decompression may be performed after the receiving device decrypts the data carried in the NAS PDU. To decompress the received packet, C-SGN <NUM> can search for strings in the one or more prefill buffers corresponding to identifiers included in the received packet. Each identifier may be replaced with the corresponding string from one or more prefill buffers common to one or more UEs as discussed in further detail herein, which allows C-SGN <NUM> to retrieve the contents of the compressed packet.

<FIG> illustrates a compressed data packet <NUM>, according to an embodiment. As illustrated, the packet includes a header <NUM>, pointer metadata <NUM>, and uncompressed data bytes <NUM>. The header <NUM> generally indicates if the packet is compressed or not compressed. The pointer metadata <NUM> generally identifies the location of compressed data in a prefill buffer. The location may include, for example, a memory pointer or another identifier associated with a common string. The data packet may include multiple pointer metadata fields based on the number of strings in the packet that are compressed. Uncompressed data bytes <NUM> generally follow the pointer metadata. When a receiving device receives a compressed data packet <NUM>, the receiving device examines the pointer metadata <NUM>, if present, to replace the pointer metadata with the corresponding string from the one or more prefill buffers. After the pointer metadata <NUM> is replaced by the corresponding strings to decompress the compressed data packet, the receiving device can perform subsequent processing of the data transmitted in the compressed packet.

<FIG> illustrates a compressed data packet <NUM>, according to an embodiment. Compressed data packet <NUM> generally includes a header <NUM>, a plurality of metadata segments <NUM>, and uncompressed data bytes <NUM>. As illustrated, the header <NUM> generally includes an indication of whether the packet is compressed in the packet action field <NUM>. The packet action field <NUM> may include a binary indication of whether the packet is compressed (e.g., that metadata related to a prefill buffer is included in the packet). If the packet is compressed, the header generally includes a second portion <NUM>, which may include data indicating an amount of metadata in the compressed data packet that follows the header.

The metadata segments <NUM> included in a compressed data packet may be, for example, two or three bytes in length. If the compressed data indicated by a metadata type field is, for example, a UE IP address (that, as discussed above, is not included in a prefill buffer), the metadata may be two bytes in length. The two bytes may include a first byte indicating at least the metadata type. In some cases, the first byte may additionally indicate the length of the data to be inserted into an uncompressed version of the packet. A second byte may indicate where the indicated data (e.g., a UE IP address) is to be inserted into the uncompressed version of the packet.

If the compressed data indicated by the metadata type field is three bytes in length, the metadata segments <NUM>, as illustrated, generally include a first byte <NUM> indicating the metadata type and the length of the data to be inserted into an uncompressed version of the packet. A second byte <NUM> may include a distance to a pointer, which indicates where the compressed data is to be inserted in the uncompressed version of the packet. The distance to the pointer may be, for example, a distance from the beginning of the one or more uncompressed data bytes transmitted in the packet after the one or more metadata fields. In some cases, the distance to the pointer may be, for example, a distance relative to a pointer referenced by a previous metadata segment <NUM> (e.g., with a negative distance indicating that the desired pointer is located before the previously referenced pointer and with a positive distance indicating that the desired pointer is located after the previously referenced pointer). A third byte <NUM> may be an offset field, which indicates a distance in bytes from the beginning of the prefill buffer that the matching string may be found.

During decompression, for each element of compressed data identified by a metadata segment <NUM> in compressed data packet <NUM>, a receiving device generally obtains a string from the prefill buffer based on the data carried in the offset field. The receiving device subsequently inserts the string from the prefill buffer into the location in the uncompressed data bytes indicated by the distance to the pointer carried in the metadata included in the compressed data packet. When the packet is fully decompressed, the receiving device can perform subsequent processing of the data transmitted in the compressed packet.

In some cases, a prefill buffer includes a plurality of predefined labels that indicate the fields present in the prefill buffer. Each label may be associated a string and the length of the string.

<FIG> illustrates an example compressed data packet <NUM> including a plurality of labels associated with uncompressed data, according to an embodiment. As illustrated, the compressed data packet includes a header <NUM> indicating whether the packet is compressed and, if so, the number of metadata fields <NUM> present in the packet, a number of metadata fields <NUM>, and uncompressed data bytes <NUM>.

Each metadata field <NUM> may include a first byte <NUM> indicating a label in the prefill buffer and a second byte <NUM> including a distance to a pointer. The distance to the pointer, as discussed above, indicates a location in the uncompressed data bytes <NUM> included in the compressed packet that a string retrieved from the prefill buffer is to be inserted. During decompression, a receiving device generally obtains the label identifying a string in one or more prefill buffers from the first byte of the metadata and retrieves the corresponding string and string length associated with the label from the prefill buffer. Upon retrieving the corresponding string and string length from the prefill buffer, the receiving device can insert the string at the location indicated in the distance to pointer field. In some cases, the metadata may include a special label value that indicates that data known at both a compressor (transmitting device) and decompressor (receiving device), such as a UE IP address, is to be inserted into the decompressed packet. In such a case, the receiving device need not access the one or more prefill buffers to obtain a string to insert into the compressed data packet at the location identified by the distance to pointer information carried in second byte <NUM>.

In some cases, the prefill buffers may include a plurality of templates associated with common messages from a particular application. For example, each template can be associated with a sample header format located in the prefill buffer. Values in a transmitted compressed packet that are different from the header format template in the prefill buffer can be filled from data carried in the compressed packet (explicitly), indicated as a special field (e.g., for the UE IP address), or filled from another portion of the prefill buffer.

<FIG> illustrates an example compressed data packet <NUM> including an indication of a template, according to an embodiment. As illustrated, the compressed data packet includes a header <NUM> indicating whether the packet is compressed and, if so, the number of metadata fields <NUM> present in the packet. Following the header, the packet includes a template indicator <NUM>, which indicates the template associated with the compressed data packet that the decompressing device is to retrieve from the prefill buffer. In some cases, the template indicator <NUM> may include two bytes to indicate the length of the template and the beginning location of the template in the prefill buffer. In some cases, the indication of the template may include a byte to indicate a template identifier.

Each metadata field <NUM> generally includes a match length <NUM>, mismatch length <NUM>, mismatch type <NUM>, and mismatch offset <NUM>. The match length <NUM> indicates the length of the matched block in the indicated template, and the mismatch length <NUM> indicates the length of the block that is to be replaced by other data. The mismatch type <NUM> generally indicates where the replacement data may be found. If the mismatch type indicates (e.g., using the two-bit value of "<NUM>") that the replacement data may be found in another location in the prefill buffer, the mismatch offset generally indicates where in the prefill buffer the replacement data may be found. A decompressor can locate the replacement data using the mismatch offset and mismatch length and replace the mismatching data in the template with the replacement data.

If the mismatch type <NUM> indicates (e.g., using the two-bit value of "<NUM>") that the data field is a special field to be filled by a quantity known at both the compressor (transmitting device) and decompressor (receiving device), such as a UE IP address, the decompressor need not access a prefill buffer or the uncompressed data bytes to obtain the data to insert into the template. The decompressor can insert the corresponding quantity (e.g., the UE IP address) directly into the template.

In some cases, replacement data may be carried explicitly in uncompressed data bytes <NUM> following the metadata. In such a case, the mismatch type may indicate (e.g., using the two-bit value of "<NUM>") that the replacement data is located in the uncompressed data bytes <NUM>. A decompressor can locate the replacement data in the uncompressed data bytes <NUM> and replace the mismatching data in the template with the replacement data.

The frame formats illustrated in <FIG> illustrate non-limiting examples of frame formats that may be used to carry compressed data in CIoT communications and are not to be considered limiting of its scope. Similar formats may be established and used to carry compressed data in CIoT communications.

As an example, "at least one of a, b, or c" is intended to cover: a, b, c, a-b, a-c, b-c, and a-b-c.

The various operations of methods described above may be performed by any suitable means capable of performing the operations, such as various hardware and/or software component(s), circuits, and/or module(s). Generally, any operations illustrated in the Figures may be performed by corresponding functional means capable of performing the operations.

The various illustrative logical blocks, modules and circuits described in connection with the present disclosure may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array signal (FPGA) or other programmable logic device (PLD), discrete gate or transistor logic, discrete hardware components or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any commercially available processor, controller, microcontroller or state machine.

The steps of a method or algorithm described in connection with the present disclosure may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in any form of storage medium that is known in the art. Some examples of storage media that may be used include random access memory (RAM), read only memory (ROM), flash memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM and so forth. A storage medium may be coupled to a processor such that the processor can read information from, and write information to, the storage medium.

The functions described may be implemented in hardware, software, firmware or any combination thereof. If implemented in software, the functions may be stored as one or more instructions on a computer-readable medium. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray® disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.

For example, such a computer program product may comprise a computer readable medium having instructions stored (and/or encoded) thereon, the instructions being executable by one or more processors to perform the operations described herein.

Software or instructions may also be transmitted over a transmission medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of transmission medium.

Claim 1:
A method (<NUM>) at a cellular internet of things, CIoT, serving gateway node, C-SGN, the method comprising:
establishing (<NUM>) at least a first prefill buffer common to a set of UEs, wherein the first prefill buffer includes a plurality of commonly transmitted strings, and wherein the first prefill buffer is maintained solely at the CIoT C-SGN;
transmitting to a UE an identifier of the first prefill buffer during an attach procedure with the UE of the set of UEs;
generating (<NUM>) a compressed packet by:
identifying matches between at least one commonly transmitted string of said plurality of the commonly transmitted strings and data in at least one of a header portion and/or payload portion of an uncompressed packet;
associating an identifier to each matched commonly transmitted string of the plurality of commonly transmitted strings;
replacing the at least one matched commonly transmitted string of the plurality of commonly transmitted strings with the associated identifier; and transmitting the compressed packet.