In this article, Wayne Stargardt from Numerex Corp. (USA) explains why 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 developers must take into account.
The number of applications being created to operate over wireless networks is growing tremendously every day. However, 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. But we need to address wireless. The field is new, 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.
I’d like to address how we “upgrade” our engineering so that applications are designed to communicate across the worldwide public cellular telephone network.
Advice for Application Developers
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. Application developers are accustomed to TCP/IP providing a standard set of communications services and a dependable quality of service across a network connection. While TCP/IP connections and sessions are indeed supported across the cellular network, that form of communication operates differently over wireless connections in some very important ways.
Usage-Based Charges
In a wireline environment there is a fixed cost for the communication service, allowing applications to communicate across the connection as much as the contracted bandwidth will allow. Wireless networks, on the other hand, charge based on usage – on how much data is transmitted across the network. Not only is cellular much more expensive for raw, bulk data transmission, but it is more expensive for transactional usage.
Using TCP/IP in a network with usage-based charges clearly incurs some significant costs. The protocol incurs chargeable communications overhead on several dimensions: advertisement and discovery, route discovery, network registration, session negotiation and establishment, flow control, delivery guarantee and error recovery transactions, extended services header information, worldwide addressing, source routing and error detection are all 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.” They send heartbeat and status messages when there is nothing noteworthy to report. Applications send text strings when a bit or two would suffice. 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 and time, for example. All of these application design decisions, which incur no costs over a wireline network, generate significant 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. 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 cannot afford the premium charges and higher cost hardware these channels require.
Most 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 need to rethink the data flow designs in their applications to accommodate these relatively extreme constraints. Failing to take these factors into account may result in an application that does not work reliably, or which cannot establish or maintain a connection.
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. Cellular networks, however, 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 only up to a certain threshold and then disconnects the session.
A developer who has not designed an application to presume that sessions must be set up before every transaction and taken down afterwards – may find the application performs poorly over a wireless network.
Dynamic IP Addressing
Most mobile devices are assigned an IP address by the carrier for communicating over the Internet. 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.
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. 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 mobile devices. Wireless applications need to be structured so that the device itself 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.
Addressing Complexity
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.
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
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. Once again, things are not so straightforward and simple with cellular wireless communications. Communicating with a mobile device is only “seamless” 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.
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 cannot 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.
