The number of applications being created to operate over wireless networks is growing tremendously. Whether writing consumer applications for smartphones, mobile business applications for portable computers, or M2M applications for remote devices, more software engineers are developing applications for this exciting environment. The field is new, however, so most of these engineers have no prior experience in designing applications that communicate over wireless networks. This will get them and their projects into trouble unless they carefully research how these communications networks operate, and understand how they will have to structure their applications to accommodate its unique characteristics.
Most software engineers who develop communicating applications learned their trade by designing applications to communicate over wireline TCP/IP networks. They have learned a set of architectural principles, design guidelines, algorithmic shortcuts, and communications practices appropriate to that communications environment. When they start to work on wireless applications, however, it will come as a shock to many of them that those principles and practices are simply wrong and will not work in the new environment.
In this discussion I am primarily focusing on applications that are designed to communicate across the worldwide public cellular telephone network. Many of my comments and observations will also apply to other wireless networks, including satellite networks, private radio WAN networks, wireless sensor networks, and proprietary unlicensed wireless networks.
Part of the confusion for new wireless developers comes because the cellular network supports TCP/IP communications interfaces on both ends – at the mobile device and at the cellular network point-of-presence accessed over landlines by a central server. Application developers are accustomed to TCP/IP providing a standard set of communications services and a dependable quality of service across a network connection, and abstracting the differences of the underlying physical networks from the developer’s concerns. While TCP/IP connections and sessions are indeed supported across the cellular network, that communication operates differently over wireless connections in some very important ways.
The rest of this discussion will review some of the important differences of wireless networks, how those differences impact TCP/IP-based communications, and the implications for applications designed for this environment.
Usage-Based Charges
In a wireline communications environment there is a fixed cost for the communications service (or at least a fixed monthly charge), and then applications can communicate across the connection as much as the contracted bandwidth will allow – which nowadays is usually a lot.
Wireless networks, on the other hand, charge based on usage – on how much data is transmitted across the network. In fact, cellular charges a lot more than wireline services for equivalent data volume – from 100 to 1,000 times more than wireline connections. Not only is cellular much more expensive for raw, bulk data transmission, but it is even more expensive for transactional usage. Cellular networks charge not only for the payload – the data the application is sending – but they also charge for all of the protocol. That includes headers, error checking bits, acknowledgements, handshaking and session negotiations, and so on. On top of that, some cellular networks take the data volume transmitted during a session and round it up to the nearest 1,000 bytes or so when the session ends.
Using TCP/IP in a network with usage-based charges clearly incurs some significant costs. TCP/IP is a relatively “chatty” protocol, which is necessary for it to provide the flexibility, reliability and physical network abstraction that developers like so much. The protocol incurs chargeable communications overhead on several dimensions. All of its address advertisement and discovery, route discovery, and network registration transactions are chargeable. All of its session negotiation and establishment, flow control, delivery guarantee and error recovery transactions are chargeable. All of its extended services header information, worldwide addressing, source routing, error detection and other overhead bits are chargeable. Those costs are incurred before the first bit of useful application payload is conveyed.
Beyond the real cost of using TCP/IP, developers used to wireline networks often make their applications “chatty” as well. They send heartbeat and status messages when there is nothing noteworthy to report. When applications do send information, they send a whole block of data, most of which has not changed from the last time or otherwise has limited information content. Applications send text strings when a bit or two would convey as much information to a computer. Developers have applications send diagnostic information continually “just in case” they need to check the logs on a problem. Even worse, developers architect applications so that constant communications is necessary for it to work – to synchronize application state, to synchronize time, to get information by polling rather than send on events, etc. All of these application design decisions, which are done for the convenience of the developer and incur no costs over a wireline network, generate significant unnecessary usage charges over a cellular network.
Limited Bandwidth and Latency
Most wireline TCP/IP connections today are “broadband” connections that provide high bandwidth and low latency. The bandwidth available over wireline connections has grown significantly over the previous decade. As a result, developers have evolved their applications to use more graphics and animation, rich user interfaces, dynamically downloaded applets and plugins, XML-based protocols, and other bandwidth consuming techniques that improve functionality and usability. Developers have also written their applications to be highly interactive, to load or preload relatively large datasets, and to expect relatively short timeouts in managing communications.
On the other hand, wireless networks are significantly bandwidth constrained. Most wireless connections will only operate at data rates two to three orders of magnitude slower than the common wireline connections available today (i.e., only 1/100th to 1/1000th of the wireline data rate). Some networks offer faster channels or connections that approach low end wireline connections, but most M2M applications can not afford the premium charges and higher cost hardware these channels require. In any case, most wireless connections degrade the channel data rate when the remote device is in marginal coverage to even lower throughput than the ideal case.
Relative to their wireline counterparts, wireless networks also introduce higher latency in their connections. The higher latency doesn’t just come from the lower throughput of the communications channel, but also from delays introduced by cellular network elements and signaling in the underlying wireless physical network. In particular, there can be pronounced delays when a device needs to register on a new network (such as after repowering or resetting), when it changes the serving cell site, and when it seeks to establish a new session. Latency is also a symptom when a device is in marginal coverage and has difficulty maintaining the basic wireless connection with the network infrastructure.
Most application developers are not used to developing applications for such bandwidth constrained communications links, or for connections with variable and generally high latencies in interactive transactions. Developers may need to rethink the data flow designs in their applications to accommodate these relatively extreme constraints of wireless networks. Failing to take these factors into account may result in an application that does not work reliably, or which can not establish or maintain a connection at all.
Intermittent Sessions
In many TCP/IP-based applications, the application establishes a session or socket connection between the two ends of the application (i.e., usually server and client), and leaves that connection in place as long as the application is up, even when nothing is being communicated. In a wireline environment there is no “cost” to maintaining a session, and keeping the session active can reduce latency. With an active session, either the client or the server can initiate a short message with minimum delay and processing overhead. It is a little more programming work and processing overhead to initiate a session every time the client or server needs to communicate with its counterpart – and to promptly terminate that session when the transaction is finished.
Cellular networks do not allow sessions to be maintained for any significant period of time, particularly if they are quiescent. To minimize the non-productive consumption of their network resources – including the servers that keep track of active sessions – cellular carriers allow sessions to continue up to a threshold time, and then the carrier interjects and takes down the session. This kind of network intervention to terminate sessions is virtually unknown in the wireline Internet. In addition, some cellular networks will not tolerate devices that do not handle session management in a carrier-specific, wireless aware manner, and carriers may not provide service to devices that exhibit poor behavior.
A developer who has not designed his application to presume that sessions are not established – and that sessions must be set up before every transaction and taken down afterwards – may find the application performs poorly over a wireless network. Latency over wireless networks is already long, and waiting for a communications attempt to time out before beginning to reestablish a session only magnifies that.
Intermittent Connections
Once a device is connected to the wireline Internet, the developer and the application can rely on the communications facilities being available on demand. When the application needs to send data, it can just hand the data and destination address to the TCP/IP protocol stack and rely on it to perform the communications function across the network immediately. Timeouts and retries are often used to address the rare situation when the underlying communications service is unavailable.
With wireless communications, however, it is common for the network to be unavailable to carry communications. With mobile devices, it is almost guaranteed that they will be out of range of the cellular system at some time. Intermittent communications even occurs for stationary devices since other relevant objects are moving – obstacles, interferers, and reflecting surfaces that create multi-path self-interference.
The TCP/IP protocol stack provides limited facilities to deal with the frequency and length of communication interruptions that commonly occur with wireless networks. It is incumbent on the application developer to build many of these facilities into the application. The mobile application has to determine whether the network is available by making direct status queries to the cellular radio, and the server application needs to query the cellular network directly to determine whether the mobile is registered and active. Messages that can not be delivered need to be stored locally – sometimes a very large number for a relatively long time – so that they can be forwarded on to their destination once wireless communications is established. The local application needs to be able to continue performing its basic functions without relying on communications to the remote component. It is difficult for a client/server application to function robustly if it does not implement some of the basic communications protocol functions needed to deal with the intermittent connections of the wireless network.
Dynamic IP Addressing
The Internet is a marvelous communications network in that generally any node on the Internet can connect to and communicate with any other node on the Internet, anywhere in the world. There is only one, unified address space for all Internet connected devices around the globe. All the initiating node needs to know is the IP address of the destination node in order to connect to it, and there is a worldwide network of directory servers to help initiators find the route to their destination node addresses.
Most mobile devices are assigned an IP address by the carrier for them to use for communicating over the Internet. Because the cellular industry paradigm is that mobile devices are subscriber devices and the subscriber initiates all communications, and because the cellular industry has needed to ration the IP address ranges that they have been allocated, the IP addresses are assigned temporarily or “dynamically” whenever the mobile device needs to communicate. When the mobile device is not actively communicating across an established session, then its temporarily assigned address is recovered and reused by the cellular network. Most of the time, a mobile device does not have an address assigned, and it can not be reached by a server application, even when the device is within cellular coverage.
Many cellular carriers do provide an option to assign a permanent, full-time IP address to a mobile device, which is called a “static” IP address. An external or server-based application can initiate a communications session with such a mobile device at any time, as long as it is within cellular coverage. The number of IP addresses available to carriers is still limited, however, and they charge extra for static IP addresses – sometimes significantly more.
Over cellular networks, applications can also always initiate communications with a mobile device using the Short Messaging Service (SMS) used for text messages, but this facility is extremely payload limited and entirely out-of-band from the familiar TCP/IP communications service.
A number of remote monitoring and control applications are architected under the assumption that the server is the “master” in the operation of the system, and that the central application controls communication to and from remote devices. This architecture is incompatible with a standard cellular service with dynamically assigned IP addresses for the mobile devices. Wireless applications need to be structured so that the mobile device initiates communications, either on schedule or on event. Even configuration commands and software updates for a device need to be held by a server application in a pending state until the target mobile device initiates a communications session with the server. Or the system needs to be designed so that server applications can send an SMS message to a mobile device to request it to initiate such a TCP/IP session on demand (the so-called “shoulder tap” method to get the mobile device’s attention).
Addressing Complexity
As stated previously, the Internet provides a wonderful facility of a single, unified address space that any Internet-connected node can use to communicate with any other Internet-connected node. Whether using IPv4 or IPv6, there is a one-to-one match between any physical device and its Internet address. Beneath its virtual IP address, every device also has a unique MAC address that is burned into its communications hardware, to further guarantee the unique identity of each connected physical device. The Internet infrastructure takes care of associating the virtual IP address with the physical MAC address. Everything is simple and harmonized.
In the cellular world, it really isn’t quite so simple. The cellular networks “support” IP-based communications, but they do not use IP addressing as the actual basis for communication like the Internet does (at least, not until true 4G networks become the predominant cellular network). IP addressing is actually overlaid on an entirely different cellular-based addressing universe. Rather than a MAC address, a cellular device has an International Mobile Equipment Identifier (IMEI). Devices that operate on GSM technology networks also require a separate Subscriber Identity Module (SIM), which in turn has its own unique International Mobile Subscriber Identity (IMSI) number. On top of these hard-coded physical addresses, cellular devices also have their own virtual address that is used for authentication and routing, the Mobile Subscriber Integrated Services Digital Network (MSISDN) number.
Mobile applications only need to use the virtual addressing of the Internet, the IP address, for mobile devices and central, server-based applications to communicate. However, most device and network management functions associated with the application will need to use cellular-specific addressing. Adding a new device to the application requires provisioning instructions to the cellular network, which can only be performed using the native addressing of the wireless industry. Similarly, most communication diagnostics must use cellular addressing rather than Internet addressing. Developing and deploying an application that communicates over the cellular wireless network will require use of the separate and extended addressing native to the wireless industry.
Multiple Carriers and Roaming
As stated earlier, the Internet is a marvelous communications network because any node on the Internet can connect to and communicate with any other node on the Internet, anywhere in the world. This communication is not dependent on knowing or dealing with the Internet Service Provider (ISP) of the other node. A node that connects to the Internet only needs to have commercial relationship with its own ISP. Once it has done so, the node can communicate with any other node that is obtaining service from any other ISP, because all ISPs provide reciprocal services and access to each other. An application on one node only needs to know the IP address of another node in order to communicate with it.
Once again, things are not so straightforward and simple with cellular wireless communications. Communicating with a mobile device is only “seemless” like the Internet if the device stays within the coverage area of the wireless carrier on whom the device is activated. But carrier licenses are limited to a single country, and no one carrier covers all of the geographic area in any particular country (especially the United States). In order to provide nearly ubiquitous service to subscribers, cellular carriers provide a form of reciprocal service to each other termed “roaming,” in which a device that has a commercial relationship with one carrier (the “home” carrier) is allowed to operate on the network of another carrier (the “serving” carrier). The catch is that cellular carriers charge roaming fees for this reciprocal service privilege, and often these roaming are significantly higher than the normal usage-based charges imposed by the home carrier. Roaming enables a wireless application to be deployed using devices almost anywhere in the world, but there is a significant cost for that coverage, simplicity and flexibility.
Designing and deploying an application that communicates with devices in multiple countries always involves some complexity. When communicating over the wireline Internet, devices usually piggy-back on existing Internet connections, essentially for free. If that is not possible, local Internet service has to be established with an ISP that serves that market. Using the inter-carrier roaming relationships available with wireless applications can greatly simplify the worldwide deployment of an application. But the usually steep nature of roaming charges places an even greater incentive to design the application to minimize usage-based charges. Good design principles for wireless applications are more imperative when devices are expected to operate across national and even carrier boundaries.
Summary
Software engineers use a set of architectural and design principles to develop successful multi-node, client/server applications. Designing an application that is going to communicate over a wireless network, instead of a wireline one, adds a significant new set of considerations and constraints that the engineer must take into account. Developing a successful wireless application can not succeed just with “tweaks” or small modifications to traditional design practices. The entire application architecture must usually be rethought to produce an effective, commercially viable application.
