XEP-0286: Mobile Considerations on LTE Networks

NOTICE: This Informational specification defines a best practice or protocol profile that has been approved by the XMPP Council and/or the XSF Board of Directors. Implementations are encouraged and the best practice or protocol profile is appropriate for deployment in production systems.

Table of Contents

1. Introduction

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.

2. Overview

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 therefore conserving them is still desirable. This XEP mostly focuses on LTE as it already has a very wide deployment and will only continue to further replace 3G technologies.

3. Compression

XML, and by extension XMPP, is known to be highly compressible. Compression of XMPP data can be achieved with the DEFLATE algorithm (RFC 1951 [1]) via TLS compression (RFC 3749 [2]) or Stream Compression (XEP-0138) [3] (which also supports other compression algorithms). A description of the security implications of stream compression is beyond the scope of this document (See RFC 3749 [2] or Stream Compression (XEP-0138) [3] for more information), but 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, and the compressed stream should have a full flush performed on stanza boundaries to help prevent chosen plaintext attacks. While this may mitigate some of the benefits of compression by raising compression ratios, in a large, real world deployment, network traffic was still observed to decrease by a factor of 0.58 when enabling Stream Compression (XEP-0138) [3] with ZLIB compression.

While the CPU cost of compression may directly translate 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. However, CPU usage is also not guaranteed to rise due to compression. In the aforementioned deployment of stream compression, a decrease in CPU utilization by a factor of 0.60 was observed, presumably due to reductions in TLS and packet handling overhead. Therefore CPU time spent on compression (for ZLIB, at least; other algorithms were not tested) can be considered negligable.

Supporting compression and performming a full flush on stanza boundaries is recommended for mobile devices.

4. Power Consumption

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 [4]. On some networks that support the legacy SVLTE (Simultaneous Voice and LTE) or CSFB (Circuit-switched fallback) instead of the more modern VoLTE (Voice Over LTE) standard, 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 [5]. On the uplink side a different technology, Single-carrier frequency division multiple access (SC-FDMA) is used, which is slightly more efficient than traditional 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:

5. Notable Extensions

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

Stream Compression (XEP-0138) [3] provides stream level compression.

Entity Capabilities (XEP-0115) [7] provides a mechanism for caching, and hence eliding, the disco#info requests needed to negotiate optional features.

Roster Versioning (XEP-0237) [8] provides a relatively widely deployed extension for reducing roster fetch sizes.

Stream Management (XEP-0198) [9] allows the client to send and receive smaller keep-alive messages, and resume existing sessions without the full handshake. This is useful on unstable connections.

Client State Indication (XEP-0352) [6] allows clients to indicate to the server that they are inactive, allowing the server to optimize and reduce unnecessary traffic.

Push Notifications (XEP-0357) [10] 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).

Message Archive Management (XEP-0313) [11] lets clients fetch messages which they missed (eg. due to poor mobile coverage and a flaky network connection).

6. Acknowledgements

This XEP was originally written by Dave Cridland, and parts of his original work were used in this rewrite. Thanks to Atlassian (HipChat) for allowing me to release numbers from their XMPP compression deployment.

7. Security Considerations

This document introduces no new security considerations.

8. IANA Considerations

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

9. XMPP Registrar Considerations

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

Appendices

Appendix A: Document Information

Series: XEP
Number: 0286
Publisher: XMPP Standards Foundation
Status: Active
Type: Informational
Version: 1.0.0
Last Updated: 2018-01-25
Approving Body: XMPP Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: NOT_YET_ASSIGNED
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Appendix C: Legal Notices

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

END