Higher layer compression with lower layer signaling

Methods and devices for reducing traffic over a wireless link through the compression or suppression of high layer packets carrying predictable background data prior to transportation over a wireless link. The methods include intercepting application layer protocol packets carrying the predictable background data. In embodiments where the background data is periodic in nature, the high layer packets may be compressed into low-layer signaling indicators for communication over a low-layer control channel (e.g., an on off keying (OOK) channel). Alternatively, the high layer packets may be suppressed entirely (not transported over the wireless link) when a receiver side daemon is configured to autonomously replicate the periodic background nature according to a projected interval. In other embodiments, compression techniques may be used to reduce overhead attributable to non-periodic background data that is predictable in context.

TECHNICAL FIELD

The present invention relates generally to wireless communications, and more particularly to a system and method for reducing the amount of traffic communicated over wireless links attributable to background information or predictable signaling.

BACKGROUND

Today's wireless devices allow users to run various data applications, such as internet browsers (Internet Explorer, Firefox, etc.), social media programs (e.g., Facebook, Twitter, etc.), email managers (e.g., Outlook, etc.), network programs (e.g., Skype, Instant Messenger, etc.), and other programs. Such programs often generate a considerable amount of background overhead that may generally be communicated over the wireless link using predictable messages (such as hello messages) containing predictable background data. For instance, a user equipment (UE) that is running a social media application (e.g., Facebook) may send occasional status messages to the service provider that confirm that the application is still running on the UE. This status information may allow the service provider to perform various tasks, such as alert other users that the instant user is available to chat. There are many other reasons that applications may communicate background overhead, including for (but not limited to) billing/accounting, control signaling, and validation purposes.

Oftentimes the predictable packets used to communicate this background overhead are repetitive in nature, and are sent periodically (or semi-periodically). For instance, a social media application may send a status/hello message every ten seconds to notify the server that the programming is still running. These predictable packets may be internet protocol (IP) packets (or another protocol, such as Ethernet) comprising upwards of forty bytes, and consequently the transportation of these predictable packets may consume significant amounts of bandwidth on the wireless connection. Additionally, a UE may be required to complete an initialization protocol (e.g., a control plane protocol) to achieve an appropriate level of synchronization prior to sending the background information over the wireless link. For instance, in 3rd Generation Partnership Project (3GPP) long term evolution (LTE) systems, a UE that is presently in an idle state (e.g., a radio resource connected (RRC) idle state) may need to transition into an active state (e.g., RRC_CONNECTED state) before sending predictable packets. In some instances, UEs in the active state (e.g., RRC_CONNECTED state) may be required to transition from a low-level synchronization sub-state (e.g., OUT_OF_SYNC) to a higher level synchronization sub-state (e.g., IN_SYNC state) before sending the predictable packet over the wireless link. Such transitions may require the communication of hundreds (or even thousands) of bytes of data over the wireless link, thereby substantially increasing the amount of resources consumed through communication of the background overhead.

For these and other reasons, the communication of background overhead related to data applications installed on wireless devices (e.g., UEs) may consume substantial amounts of bandwidth in wireless networks. Accordingly, techniques and systems for reducing the amount of bandwidth consumed by the communication of background information are desired.

SUMMARY

Example embodiments of the present invention which provide a system and method for reducing the bandwidth consumed by predictable messaging in wireless communication systems.

In an embodiment, a method is provided for reducing traffic over a wireless link. In this example, the method includes intercepting a predictable signaling packet intended for transmission over the wireless link, and subsequently classifying the predictable signaling packet to identify a generic message type. In some instances, the predictable signaling packet carries predictable background data corresponding to an application running on a wireless device. Pursuant to classifying the predictable signaling packet, the method further includes triggering replication of the predictable signaling packet on an opposite side of the wireless link.

In another embodiment, a method is provided for reducing traffic over a wireless link. In this example, the method includes recognizing a first instance of periodic signaling intended for transmission over the wireless link, instructing a daemon positioned on an opposite side of the wireless link to replicate future instances of periodic signaling at projected intervals, and thereafter, preventing an attempted transmission of a second instance of periodic signaling over the wireless link. In this embodiment, the daemon replicates the second instance of periodic signaling without being notified of the second instance of periodic signaling.

In yet another embodiment, a method is provided for compressing background data that is predictable in context. In this example, the method includes detecting a triggering message comprising the background data that is projected to elicit an attempted transportation of one or more triggered messages over a high-layer channel of a wireless link, establishing a low-layer channel on the wireless link, and communicating one or more low-layer signaling indications each of which corresponding to a compressed one of the one or more triggered messages. In this embodiment, the attempted transportation of the one or more triggered messages over the high-layer channel is prevented by intercepting the said triggered messages prior to physical layer processing on a transmitter side of the wireless link.

Other embodiments of this disclosure include apparatuses/devices for executing and/or facilitating the execution of one or multiple steps of the methods summarized above.

DETAILED DESCRIPTION

The operating of the current example embodiments and the structure thereof are discussed in detail below. It should be appreciated, however, that the present invention provides many applicable inventive concepts that can be embodied in a wide variety of specific contexts. The specific embodiments discussed are merely illustrative of specific structures of the invention and ways to operate the invention, and do not limit the scope of the invention.

One solution for reducing network overhead attributable to background data is to compress predictable packets of a common type (e.g., hello packets sent by a specific data application) into a periodic signaling indicator (e.g., a specific time frequency resource mapped to the type of compressed predictable signaling packet). Specifically, an application on the transmitter side (e.g., a transmitter side daemon) may intercept predictable signaling packets intended for transmission over the wireless link, compress the data into a low layer signaling indicator, and communicate the indicator to an application on the receiver side (e.g., a receiver side daemon). Upon detecting the signaling indicator, the receiver side daemon may replicate the predictable signaling packet, and forward the replicated predictable packet to an appropriate destination (e.g., an application server, or an application module on the wireless device).

FIG. 1illustrates a communications network100in which various aspects of this disclosure may be implemented to conserve bandwidth over a wireless link. The network100comprises a base station (eNB)110having a coverage area112, a user entity (UE)120, a backhaul network130, and a plurality of application servers140-160. The eNB110may be any component capable of establishing wireless communication with the UE120. In some embodiments, the wireless communication may be propagated over a cellular link, such as an uplink connection (dashed line) and/or a downlink connection (dotted line). In other embodiments, the wireless communication may be propagated over other types of wireless link connections (e.g., Wireless local area networks (WLAN/Wi-Fi), Bluetooth, etc.). The UE120may be any component or collection of components that allows a user to establish a wireless connection for purposes of accessing a network, e.g., the backhaul network130.

The UE120may allow a user to run one or more data applications (e.g., internet browser, social media applications, etc.). Some of these data applications may be services that are supported (at least in part) by the applications servers140-160. For instance, the UE120may be running a first data application (e.g., Internet Explorer) that corresponds to the application server140, a second data application (e.g., Skype) that corresponds to the application server150, and a third data application (e.g., Outlook) that corresponds to the application server160. When the user is actively using said applications, the UE120may exchange service-related data with the Application servers140-160via the eNB110and the Backhaul network130. Service-related data may include information related to internet content (e.g., webpages, etc.), streaming media (e.g., video/voice, etc.), and written correspondence (e.g., emails, etc.), and other services provided by the Application servers140-160via data applications.

In addition to service-related data, various background information related to the data applications may be communicated between the UE120and the applications servers140-160. Background information may include predictable and/or predictable messaging that is communicated (as a matter of course) between the UE120and the application servers140-160. For instance, a control packet (e.g., a hello packet) related to the third application (e.g., Outlook) may be periodically communicated from the UE120to the application server140to verify that the third application is still running on the UE120. This type of background signaling may be predictable because of its periodic (or semi-periodic) nature, as well as due to the standard format of the message itself. In addition, non-periodic background information may be predictable due to its context. For instance, if a first application running on the UE120sends a goodbye message, the application server140may be expected to respond with its own goodbye message. Likewise, if the application server160sends an HyperText Markup Language (HTML) identifying a webpage to the UE120, then the UE120(or a program running thereon) is likely to respond with a series of GET messages for retrieving various images/objects corresponding to that webpage, and/or equivalently utilizing significant time/frequency resources.

Depending on the number and type of applications running on the UE120, a considerable amount of background information may be communicated over the wireless link, thereby undesirably consuming significant amounts of network bandwidth. Additionally, the UE120may be required to perform synchronization/initialization protocol operations with the eNB120prior to sending/receiving the background data. Specifically, the communication of these predictable packets (e.g., IP packets) may be performed through high layer signaling, which may require relatively high degrees of synchronization between the UE120and the eNB110. Consequently, the UE120may need to transition from a low synchronization state (e.g., idle mode) to a high synchronization state (e.g., an active mode) before transmitting the predictable messaging, which may entail an initialization/authorization procedure (e.g., an RRC connection establishment protocol) that includes communicating hundreds of bytes of information of the wireless link.

FIG. 2(a) illustrates a network200for performing wireless communication, including the compression of high level signaling (e.g., containing background information) into low-level signaling. The network200comprises an eNB210, a UE220, a backhaul network230, and an application server240, which may be configured somewhat similarly to corresponding components in the network100. The eNB210may comprise an application layer212, a daemon214, and one or more physical layer interfaces216-218, while the UE220may comprise an application layer222, a daemon224, and a physical layer interface226. The application layer212may be any component (e.g., software, hardware, or combinations thereof) that supports base station operation in the eNB210, while the application layer222may be any component (e.g., software, hardware, or combinations thereof) that supports mobile device operation in the UE220. In some embodiments, the application layer212and/or the application layer222may operate according to various application layer and/or open systems interconnection (OSI) layer7protocols, such as Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), Hypertext Transfer Protocol (HTTP), Session Initiation Protocol (SIP), etc. In other embodiments, the application layer212/222may include various other functionality, such as the ability to perform transport layer protocol functions (e.g., Transmission Control Protocol (TCP)), and/or network layer protocol functions (e.g., IP related functions, etc.). In embodiments, the application layer122may allow performance of a specific task, and may be contrasted with, for example, system-software and/or middleware (e.g., operating system (OS), etc.) which provide essential services and/or resources to the application layer122.

The daemon214and the daemon224may be any components (e.g., software, hardware, or combinations thereof) that are capable of identifying, intercepting, and/or compressing packets containing background information (predictable/predictable control data). The physical layer interface216and physical layer interface226may be any components that are capable of communicating with one another via physical layer or link layer signaling. The physical layer interface218may be any component that is capable of communicating with the application server240via the backhaul network230. In some embodiments, the physical layer interface216and218may be configured to communicate via different protocols, as well as via different mediums. For instance, the physical layer interface216may be configured to communicate via a wireless connection (e.g., a cellular link, a WI-FI link, etc.), while the physical layer interface218may be configured to communicate via wire-line connection (e.g., optical link, twisted pair copper link, etc.).

In some embodiments, the daemon may reside outside of the eNB210.FIG. 2(b) illustrates a network250for performing wireless communication, including the compression of high level signaling (e.g., containing background information) into low-level signaling. The network250is similar to the network200, but includes a daemon204that resides outside the eNB210. Although much of this disclosure is discussed in the context of the network200, it should be understood that aspects of this disclosure may be applied to the network250. For instance, the daemon204may intercept signaling (e.g., high-layer signaling), as well as replicate (or trigger the replication of) a predictable data packet.

FIG. 3illustrates a protocol diagram of a signaling sequence300for compressing high level predictable packets into lower layer signaling. The signaling sequence300is performed by the eNB310and the UE320, which may be configured similarly to the eNB210and the UE220in the network200and/or the eNB110and the UE120in the network100. Specifically, the application layer322(or an application running thereon) generates a predictable packet340(e.g., an internet protocol (IP) packet) for communication to a destination on the other side of the wireless link, e.g., the eNB310, an application server (not shown) connected to the eNB320via a backhaul network (not shown), etc. The application layer322sends the predictable packet340towards the physical layer326. However, before reaching the physical layer326, the packet340is intercepted by the daemon324, where the packet is suppressed (i.e., prevented from by processed by the physical layer326). The daemon324classifies the predictable packet340to identify its type, and sets/clears an appropriate signaling indicator345. In embodiments, the signaling indicator345may be low-layer signaling that is capable of being transmitted/received while the UE320is operating in a low synchronization state, such as an idle state or low-active state. For instance, the signaling indicator345may be a specific time-frequency resource in a low-level control channel, e.g., an on-off keying (OOK) channel, such as that used in many random access channels (RACH).

By intercepting the packet340and setting the appropriate signaling indicator345, the daemon324effectively compresses high layer signaling (as would have been required to communicate the predictable packet) into low layer signaling. The signaling indicator345is sent to the physical layer326for transportation over the wireless link360to the eNB310. The eNB310receives the signaling indicator345via the physical layer interface312, where the signaling indicator345is detected by the daemon314. The daemon314recognizes that the signaling indicator345corresponds to a certain type of predictable packet (i.e., the type identified during the daemon's324classification of the packet340), and thereafter replicates the predictable packet350. The replicated predictable packet350is forwarded to the application layer316, from which it is transported to the intended destination (e.g., an application server) over a network or medium (e.g., over a backhaul network). In some embodiments, the signaling indicator345may be carried in a low-layer control channel that is established after the predictable packet340is intercepted by the daemon324. In other embodiments, the low-layer control channel may be pre-established, e.g., existing before the predictable packet340is intercepted.

A similar process occurs when a predictable packet370is sent from the eNB310to the UE320. Specifically, the daemon314intercepts and classifies the predictable packet370, thereby compressing it into an appropriate low-level signaling indicator375. The signaling indicator375is transported over the wireless link360, where it is detected by the daemon324, and de-compressed into the replicated predictable packet380.

An illustrative example of implementing aspects of this disclosure in a random access channel of an LTE wireless network standard is included herein to demonstrate how said aspects of this disclosure may be implemented in similar channels of other networks (including LTE and non-LTE networks alike). In LTE, a RACH signal is generated by the physical layer interface326of UE320in network300. Using various parameters such as those defined in PRACH-Config information element and well as other information elements, the UE can generate the RACH signal. The PRACH-Config information element is described in 3GPP technical specification (TS) 36.331 release 10 version 10.5.0 (March 2012) of the LTE standard, which is incorporated herein by reference as if reproduced in its entirety. Typically, a UE can select a “shift value” (e.g. for an initial access) or be assigned a shift value (e.g., for a handoff) from a range of shift values. The shift value is related to RACH signal generation. In this example, a UE can be assigned a shift value for each application. For a first application, the daemon324converts the message340into a RACH signal with a first specific shift value. For a second application, the daemon324converts the message340into a RACH signal with a second specific shift value. At the eNB310, the daemon314can associate the shift value from signaling indicator345(i.e., RACH signal) to generate the replicated predictable packet350. If the daemon314observes the first specific shift value, the daemon314will generate the replicated predictable packet350for the first application. Note that during establishment of the wireless link360, there may a procedure to associate the shift values of the RACH signal to applications so that the daemon324can determine the correct shift value as well as daemon314that can map the detected shift value into a replicated predictable packet350. This procedure may involve using high layer messaging.

An example of signaling indicator375is presented for LTE. Daemon314may receive a predicable packet370for an application322. The eNB310may elect to aggregate one or more signaling indicators375to reduce overhead. The eNB310may send the aggregated signaling indicators375over wireless link360using a paging channel. For example, a UE periodically examines to see whether it was paged. The eNB may elect to send the aggregated signaling indicators375during that paging channel. At the UE320, daemon324associates the received signaling indicators375into the replicated predictable packets380for the application layer322.

FIG. 4illustrates a method400for compressing high level predictable messaging into low level signaling. The method400begins at step410, where a transmitter side daemon intercepts a predictable packet containing background data. The method400then proceeds to step420, where the transmitter side daemon classifies the background data contained within the predictable packet to identify its type. Next, the method400proceeds to step430, where the transmitter side daemon sets/clears a low-level (or low-layer) signaling indicator that corresponds to the identified type. Finally, the method400proceeds to step440, where the low-level singling indicator is sent over the physical interface.

FIG. 5illustrates a method500for de-compressing low level signaling to replicate high-level predictable messaging. The method500begins at step510, where a receiver side daemon detects a low-level signaling indicator. The method500proceeds to step520, where the receiver side daemon creates or generates a replica of a predictable packet having a type that is associated with the detected low-level signaling indicator. Finally, the method500proceeds to step530, where the receiver side daemon forwards the replicated predictable packet to an appropriate destination (e.g., an application server or an application).

Although aspects of this disclosure are discussed in the context of low-layer signaling, it should be understood that such aspects may be adapted to high-layer signaling as well. For instance, a high-layer predictable message may be compressed into high-layer signaling (e.g., high-layer indicators), instead of low-layer signaling.

FIG. 6. Illustrates a protocol diagram of a signaling sequence600between the UE320and an eNB310for suppressing periodic signaling. To begin the sequence600, the daemon324detects an instance of a periodic signaling641, and transmits a signaling message645to the daemon314. In an embodiment, the signaling message645may be a start/stop message that instructs the daemon314to replicate the periodic signaling641-644(thereby producing replicated packets651-654) at projected intervals corresponding to a time period (Tp) of the periodic signaling641-644. The daemon314may continue to replicate the periodic signaling652-654without receiving further signaling from the daemon324. At some point the daemon324may detect cessation of the periodic signaling641-644, and send a message649instructing the daemon314to stop producing the replicated packets652-654.

From a general perspective, applications running in UE320may register with daemon324. As part of the registration, each application may provide a time period of the periodic signaling641-644to daemon324. During a set-up procedure, daemon314may be provided with similar information as given to daemon324. When signaling message645is received by daemon314, based on the parameters provided during the set-up period, daemon314can generate the replicated periodic signaling652-654. Some examples of the parameters are address, periodicity, counter update values, message format/content and time-out values.

FIG. 7. Illustrates a method700for suppressing periodic signaling on the transmitter side. The method700begins at step710, where a transmitter side daemon detects a first instance of periodic signaling. The method700the proceeds to step720, where the transmitter side daemon instructs the receiver side daemon to begin replication of the periodic signaling. Next, the method700proceeds to step730, where the daemon suppress subsequent instances of the periodic signaling (e.g., without notifying the receiver side daemon of said instances of periodic signaling). After some time, the method700proceeds to step740, where the transmitter side daemon detects a cessation of periodic signaling. In some embodiments, said detection may occur when the transmitter side daemon does not observe an instance of the periodic signaling during a time-out period. In other embodiments, said detection may occur when the daemon observes an application layer protocol message indicating that the periodic signaling has ended. Next, the method700proceeds to step750, where the transmitter side daemon instructs the receiver daemon to cease replication of the periodic signaling.

FIG. 8. Illustrates a method800for replicating suppressed periodic signaling on the receiver side. The method800begins at step810, where the receiver side daemon receives an instruction to begin replication of the periodic signaling. Next, the method800proceeds to step820, where the receiver side daemon replicates suppressed instances of periodic signaling at projected intervals. Subsequently, the method800proceeds to step830, where the receiver side daemon receives an instruction to stop replicating the periodic signaling. Finally, the method800proceeds to step840, where the receiver side daemon stops replicating the periodic signaling.

In some implementations, background data carried in non-periodic messages may be predictable in context. For instance, a device may be expected to return a reply message (of a certain type) upon receiving a request message (of a certain type). In other words, an initial message (e.g., a triggering message) may predictably elicit one or more responses (e.g., triggered messages). In one example, a second device receiving a goodbye message from a first device may be expected to respond with its own goodbye message. In another example, a UE that receives an HTML message (e.g., identifying a webpage) from an application server may be expected to respond with a series of GET messages for retrieving various images/objects corresponding to that webpage. Daemons (or similar applications) can exploit such predictable situations by predicting the triggered messages and/or establishing a low-layer control channel ahead of time (e.g., when detecting the triggering messages), so that the triggered messages may be communicated using less bandwidth (e.g., using low-level signaling transported over the low-layer control channel, rather than high-level IP messages transported over a high-layer channel).

FIG. 9. Illustrates a protocol diagram of a signaling sequence900for suppressing background data that is predictable in context. The signaling sequence900begins with the detection of a triggering message940(e.g., an HTML of a webpage) by either one of the daemons314and324. The triggering message940may be any predictably lead to the communication of one or more (e.g., a sequence) of triggered messages. In one example, the triggering message is an HTML message (HTTP packet) sent by the application server. However, in practice, the triggering message may be any message that would predictably lead to the communication of one or more of triggered messages. Said detection of the triggering message may cause the daemons314,324to establish a low-layer channel950, for communicating the anticipated triggered messages960-961. Next, the daemon324may detect the triggered messages960-961(e.g., GET messages for retrieving objects of the webpage), and subsequently compress the triggering messages960-961into low-layer signaling970-971. The low-layer signaling may be communicated to the daemon314, who may replicate the triggered messages960-961(thereby creating replicated triggered messages980-981).

FIG. 10illustrates a method1000for compressing high level signaling that is predictable in context. The method1000may begin at step1010, where a daemon positioned on one side of a wireless link detects a triggering message. Either the daemon on the receiver side or the daemon on the transmitter side may detect the triggering message. In some instances, the triggering message may be an application layer packet, while in other instances the triggering message may be a low level signaling indicator (e.g., corresponding to a compressed application layer packet).

Next, the method1000proceeds to step1020, where a low-layer signaling channel is established for communication of the triggered messages. Parameters of the low-layer signaling channel may be pre-established (i.e., agreed upon beforehand) or dynamically negotiated. Next, the method1000may proceed to step1030, where the triggered messages are detected by a daemon. The method1000may then proceed to step1040, where the daemon may compress the triggered messages into low-level signaling. Finally, the method1000may proceed to the step1050, where the low-level signaling may be communicated over the low-layer singling channel. Notably, a method similar to that described inFIG. 5may be implemented to decompress the low-level indicator for the purposes of replicating the triggered messages. Optionally, if the triggered messages are predicted with errors (e.g., one or more sub parameters are incorrectly guessed), then the original triggered message may be sent normally (e.g., instead of the low-layer singling).

Aspects of this disclosure may be applicable to various protocols, including (but not limited to) HTML protocol, transmission control protocol (TCP), Session Initiation Protocol (SIP), etc.

FIG. 11illustrates a block diagram of an embodiment of a communications device1100, which may be equivalent to one or more devices (e.g., UEs, eNBs, etc.) discussed above. The communications device1100may include a processor1104, a memory1106, a cellular interface1110, a supplemental wireless interface1112, and a supplemental interface1114, which may (or may not) be arranged as shown inFIG. 11. The processor1104may be any component capable of performing computations and/or other processing related tasks, and the memory1106may be any component capable of storing programming and/or instructions for the processor1104. The cellular interface1110may be any component or collection of components that allows the communications device1100to communicate using a cellular signal, and may be used to receive and/or transmit information over a cellular connection of a cellular network. The supplemental wireless interface1112may be any component or collection of components that allows the communications device1100to communicate via a non-cellular wireless protocol, such as a Wi-Fi or Bluetooth protocol, or a control protocol. The supplemental interface1114may be component or collection of components that allows the communications device1100to communicate via a supplemental protocol, including wire-line protocols.