AT&T recently announced changes to their data plans, eliminating the unlimited data plans and replacing them with tiered plans offering up to 2GB of data per month. Yet AT&T still offers unlimited messaging, including SMS and MMS. Thus, there is a mechanism to game the system.
IP via SMS
SMS relies on the GSM 03.38 character set, which is 7 bits but using an escape code for additional characters. UTF-16 is used for non-Latin alphabets, and an 8 bit clean data alphabet is also supported (but not required).
For widest support we should rely on GSM 03.38, the only character encoding which handsets are required to implement. TCP/IP packets can be encoded into at most 160 characters of 7 bits each, for a total of 1120 bits or 140 bytes. An <ESC> can be followed by only a few valid characters, so an <ESC> followed by any arbitrary character might be rejected at some point through the delivery path. An HDLC character-stuffing technique can be used to eliminate <ESC> from the data stream, details to be worked out later.
SMS does define a concatenated option to support longer messages, but it occupies 7 characters in the payload. As a compressed IP header would be smaller than 7 characters, it is recommended that SMS concatenation not be used. A 140 byte packet MTU will pack more efficiently than a larger MTU plus concatenation overheads.
With such a small MTU, header compression is a must. Robust Header Compression defines profiles for TCP+IP, UDP+IP, and RTP+UDP+IP compression, which can reduce the typical header stack down to about 3 bytes. For deployment use we'll need to define a new ROHC profile for IP Fragments, an RFC will be drafted later.
IP via MMS
MMS can be used to send small pictures and movies. Initially this seemed very promising: wrap the IP packet inside a JPG header and send it. Unfortunately to save cost, most mobile operators re-sample and re-encode any images sent via MMS to reduce their size. Straight data inside an image payload would be destroyed.
Instead the IP packet should be encoded as an image of a QR code, which can be robustly decoded even if the image is resampled. QR Code also includes error correction, helpful in this application.
QR Code can handle over 2 KBytes of data in a single barcode, easily enough to handle the maximum 1.5K ethernet frame size. ROHC header compression is not required.
Closing Notes
Yes, this is a joke. Material posted on Mondays is not intended to be taken seriously. After all, nothing productive happens on Monday.