XMPP as a protocol was designed before the wide spread adoption of mobile devices, and is often cited as not being very mobile friendly as a result. However, this mostly stems from undocumented lore and outdated notions of how XMPP works. As the Internet and protocol design have changed to be more accommodating for mobile, so has XMPP.

This XEP aims to provide useful background knowledge of mobile handset behavior, and those considerations that client and server designers can take to ensure that bandwidth and battery are used efficiently.

The two major constraints on mobile devices are power and bandwidth. With the wide spread proliferation of 3G and LTE technologies, mobile bandwidth and speeds have become broadly comparable to broadband. However, they are still relatively expensive compared to traditional wired networks, and should therefore still be considered. This XEP mostly focuses on LTE as it already has a very wide deployment and will only continue to further replace 3G technologies.

XML, and by extension XMPP, is known to be highly compressible. In a simple test of a small (266089 byte) XMPP stream (connection, stream initialization, feature discovery, roster loading, several presence stanzas sent and received, disconnect), the entropy of the stream was found to be 5.616313 bits per byte. Using the `gzip` tool to apply Lempel-Ziv coding (LZ77) without concern for server-side CPU usage resulted in a compression ratio of 21% (a 79% reduction in bandwidth). In one test with a much larger dataset typical of a corporate environment (many hundreds of users in the roster), the ratio was as low as 13%, an 87% reduction in bandwidth!

Compression of XMPP data can be achieved with the DEFLATE algorithm (&rfc1951;) via TLS compression (&rfc3749;) or &xep0138;. While the security implications of stream compression are beyond the scope of this document (See the aforementioned RFC or XEP for more info), mitigating them may affect compression ratios. The author does not recommend using TLS compression with XMPP (or in general). If compression must be used, stream level compression should be implemented instead. Compressing at the stream level gives us the benefit of being able to flush the compression stream on stanza boundaries to help prevent information from leaking. This, however, may drastically increase compression ratios.

While the CPU cost of compression directly translates to higher power usage, it is vastly outweighed by the benefits of reduced network utilization, especially on modern LTE networks which use a great deal more power per bit than 3G networks as will be seen later in this document.

Supporting compression and flushing on stanza boundaries is highly recommended.

While the wide spread adoption of LTE has dramatically increased available bandwidth on mobile devices, it has also increased power consumption. According to one study, early LTE devices consumed 5–20% more power than their 3G counterparts LTE Smartphone measurements <http://networks.nokia.com/system/files/document/lte_measurements_final.pdf>. On some networks that support the legacy SVLTE (Simultaneous Voice and LTE) instead of the more modern VoLTE (Voice Over LTE) standard, or even CSFB (Circuit-switched fallback) this number would (presumably) be even higher.

XMPP server and client implementers, bearing this increased power usage in mind, and knowing a bit about how LTE radios work, can optimize their traffic to minimize network usage. For the downlink, LTE user equipment (UE) utilizes Orthogonal Frequency Division Multiplexing (OFDM), which is somewhat inefficient A Close Examination of Performance and Power Characteristics of 4G LTE Networks <http://www.cs.columbia.edu/~lierranli/coms6998-7Spring2014/papers/rrclte_mobisys2012.pdf>. On the uplink side a different technology, Single-carrier frequency division multiple access (SC-FDMA) is used, which is slightly more efficient than traditional (non linearly-precoded) OFDM, slightly offsetting the fact that broadcasting requires more power than receiving. LTE UE also implements a Discontinuous reception (DRX) mode in which the hardware can sleep until it is woken by a paging message or is needed to perform some task. LTE radios have two power modes: RRC_CONNECTED and RRC_IDLE. DRX is supported in both of these power modes. By attempting to minimize the time which the LTE UE state machine spends in the RCC_CONNECTED state, and maximize the time it stays in the DRX state (for RCC_CONNECTED and RRC_IDLE), we can increase battery life without degrading the XMPP experience. To do so, the following rules should be observed:

This section provides pointers to other documents which may be of interest to those developing mobile clients, or considering support for them in servers.

&xep0138; provides stream level compression.

&xep0115; provides a mechanism for caching, and hence eliding, the disco#info requests needed to negotiate optional features.

&xep0237; provides a relatively widely deployed extension for reducing roster fetch sizes.

&xep0198; allows the client to send and receive smaller keep-alive messages, and resume existing sessions without the full handshake. Useful on unstable connections.

&xep0357; implements push notifications (third party message delivery), which are often used on mobile devices and highly optimized to conserve battery. Push notifications also allow delivery of notifications to mobile clients that are currently offline (eg. in an XEP-0198 "zombie" state).

&xep0313; lets clients fetch messages which they missed (eg. due to poor mobile coverage and a flakey network connection).

This XEP was originally written by Dave Cridland, and parts of his original work were used in this rewrite.

This document introduces no new security considerations.

This document requires no interaction with the Internet Assigned Numbers Authority (IANA).

No namespaces or parameters need to be registered with the XMPP Registrar as a result of this document.