Picking Which Wireless M2M Device To Use

When designing an M2M application, engineers will need to connect a cellular radio to the remote device. There are several considerations when deciding on which type of cellular radio to use. Each consideration basically involves trading off the cost of the cellular radio against other factors, such as performance, coverage, engineering effort and cost, and time-to-market.

The decisions to be made on selecting an M2M cellular radio are basically three-fold:

·         Should you implement GSM cellular technology, CDMA technology, or both?

·         Should you use 2G level technology or 3G (or maybe even 4G)?

·         Should you use a separate modem, embed a pre-certified “socket modem”, or design in a basic cellular module?

Each of these trade-offs has unit cost implications on the final device. They also carry implications for available cellular coverage, cost of cellular coverage, product form factor, product longevity, and upfront engineering cost and risk. Each of these decisions can be made independently, but they should usually be made in roughly the order presented above. First select the cellular technology that will be used, then select the evolution of the technology to implement, and then finally select how deeply the cellular technology is to be embedded into the device.

Cellular Technology – GSM vs. CDMA

The first decision to make is whether to implement cellular technology based on the GSM standard or on the CDMA standard. This is a significant choice in the United States and Canada, since these are the regions of the world in which the CDMA standard is broadly commercially deployed. There are a number of new networks in other countries based on a CDMA technology called CDMA450, but it is not interoperable with the CDMA technology deployed in North America. If your solution needs to operate around the world, including North America, then implementing GSM is the only real option.

Solution developers have several factors to consider when deciding whether to implement GSM or CDMA. Both technologies have large coverage footprints in the US from two Tier 1 carriers each. Neither of these technologies have a marked coverage advantage over the other, but in less populated areas, there are places where CDMA coverage is available and GSM is not, and vice versa. The monthly recurring costs for service are roughly equivalent between the two technologies; in fact, there tends to be more difference between the rates charged between the largest and second largest carrier in each technology than there is between the technologies. There are also differences between the communications speeds or data rates provided by the technologies, with CDMA generally offering higher speeds in the basic, low cost technology evolution. M2M applications, however, neither require nor can take advantage of CDMA’s higher data rates.

One factor in which there is a clear difference between GSM and CDMA technology, however, is in the cost of the radio device hardware required to implement it. Regardless of the hardware platform selected – separate modem, embedded socket modem, or embedded module – CDMA technology costs at least 25% more than GSM technology. Table 1 shows illustrative prices for radio hardware for each of these two technologies in the summer of 2011 (in quantities of 1,000).

Table 1

Hardware Costs For Cellular Technologies

Cellular Technology	Separate Modem	Socket Modem	Embedded Module
GSM	$125-$165	$94	$23-$28
CDMA	$157-$167	$153	$30-$36

These cost comparisons are based on the actual selling prices of devices in the United States in the summer of 2011. The price ranges reflect the differences between various manufacturers, as well as the differences between different products with varying secondary characteristics (e.g., form factor, I/O count, brand, etc.).

Clearly GSM technology is the less expensive approach. Together with its global footprint, its lower cost has made it the most popular technology for M2M applications.

Although GSM technology may be the most cost effective choice, some applications desire to also have a CDMA design alternative to provide service in those locations where there is CDMA coverage and GSM coverage is unavailable. While this is easy to provide with external modems, and relatively straightforward for socket modems, the cost and complexity of providing supplementary CDMA support – in addition to GSM -- is significant when using embedded modules.

Technology Evolution – 2G vs. 3G

The second decision is whether to implement the most widely deployed cellular technology evolution – 2G – or to use the newer evolution that will soon become as widely deployed – 3G. Wireless carriers continue to upgrade the technology evolution of their networks is to provide greater capacity for handling cell phone subscribers with the spectrum they have available.

The original digital cellular data standard for GSM networks (called GPRS, not “1G”) is still available, as are modems and modules supporting it. GPRS offers no advantages over stepping up to the evolutionary level that is broadly deployed today – 2G. Carriers have recently upgraded most of their networks to the next evolution – 3G – which offers higher data rates and enables the carriers to support more devices on their networks. Carriers also are adopting 3G technology to provide better support for high bandwidth applications – sending and receiving pictures and video, playing on-line games, downloading applications, and making other file transfers. Most M2M applications do not need nor can they use the higher bandwidth provided by 3G technology.

Because 3G technology is just becoming available for M2M applications, it is primarily available through embedded modules. 3G options are not readily available for the other hardware platforms, socket modems and separate, stand-alone modems, although this should improve over the next year.

There is a significant cost difference between using 2G radio technology or 3G technology in an M2M device. Basic 2G embedded modules from major manufacturers can be readily obtained in moderate volumes for $26 to $30 apiece. On the other hand, 3G modules from major manufacturers still cost between $50 and $80 apiece, although those prices have come down significantly over the last year and are expected to continue declining. New 3G modules from less proven Chinese manufacturers are becoming available for as little as $38 at $40, at comparable volumes. Together with its lack of compelling performance advantages, the significantly higher cost has kept 3G from being adopted in M2M applications so far.

Carriers are expected to convert their networks exclusively to 3G some time within the economic life of many of the M2M devices being designed today. At that time, carriers are expected to discontinue support for 2G devices (at least with GSM). Consequently, and in spite of its cost premium, many device developers are beginning to move towards selecting 3G technology for their new designs.

Hardware Platform – External vs. Embedded

The final decision is whether to add cellular communications by using an external modem, or by embedding a wireless communications radio inside the actual device itself. External modems are self-contained devices in their own enclosures and often with their own, independent power supply. They usually connect to a standard communications port on the host device – usually serial, USB or Ethernet – and the device sends and receives data over that connection. On the other hand, embedded modules are designed to be built into the device, and they generally require a modification to the device design to support the module. Usually the module is attached to the device’s printed circuit board (PCB) and has signal and power connections with it.

In considering what type of radio to use, the basic trade-off is between the unit cost of the radio platform and the upfront, non-recurring engineering cost of supporting the radio.

With an external modem, the unit cost is relatively high because the modem is a complete, working device. It has its own power supply and enclosure. It also has its own embedded processor and memory, and the programming to drive it. There are also a PCB, connectors, LEDs and other components that add cost. On the other hand, to use an external modem, the device only needs to connect through a common communications port and implement some basic send and receive functions. The upfront engineering effort to implement an external modem is relatively low.

Embedding a wireless modem into a device, whether directly onto the main PCB or through an attached daughtercard, adds cellular communications capability to a device at the lowest unit cost. The only other major component required in addition to the module itself is some form of antenna (although even that can sometimes be implemented as traces on the PCB). On the other hand, the cost to build in a cellular module is significant. A PCB almost certainly has to be significantly redesigned to support a cellular module. Not only does space have to be made for the component itself, but the power supply usually needs to be modified to accommodate its high peak current draw. Since the cellular module is an active, relatively high powered RF device, the PCB also has to be designed to provide signal isolation and strengthen the grounding.

The other major upfront cost to embed a wireless module is the cost of certifying compliance with the different regulations governing cellular devices. The cost of testing by a certified lab can be as great as the engineering cost just to create the design. The engineering sophistication to achieve compliance is non-trivial, and is primarily a function of the product design. Engineers who are designing their first embedded cellular device will almost always fail to pass regulatory compliance on the first attempt. Redesign and retesting will add to the upfront cost of adding cellular connectivity.

“Socket” modems are an alternative to designing in the traditional embedded module. A socket modem still needs to fit into a connector on a main or host PCB, and there is some initial engineering effort to add that connector. But the socket modem avoids the need to conduct any additional certification testing, including for emissions, since it is entirely self-contained and pre-certified. The unit cost of a socket modem lies somewhere between the low unit cost of an embedded module and the higher unit cost of an external modem.

It is difficult to categorically estimate the upfront engineering costs to implement the three different cellular device alternatives because the design challenge differs so much from one product to another. One thing that can be compared, however, is the unit cost of the hardware. Those costs are evident in Table 1, above. The separate, external modem is the highest unit cost solution, while an embedded module yields the lowest unit cost. A socket modem provides some cost reduction over an external modem, but it is still significantly more expensive than an embedded module. In the case of GSM 2G, the socket modem is three times more expensive.

So which hardware platform should an application developer use? The answer must be determined on a case-by-case basis, and including all other considerations, such as form factor constraints and time-to-market objectives. But in general, when the application is going to be implemented in low volumes (such as for internal deployment within a company), then the most cost effective approach is to use an external modem. If the application is going to be deployed in any meaningful volume, of around 1000 to 2000 units (or more), then it is usually most cost effective to design in an embedded module and complete the regulatory certification process. The socket modem serves applications cost effectively that will be implemented in a modest volume. At a forecast volume of 1000 units, however, the embedded module can absorb almost $70,000 of incremental engineering development and certification cost (enough for many types of devices) and still be at parity with a socket modem.

Conclusion

Adding cellular wireless communications capability to a device requires careful consideration to select the most cost effective approach to using this technology. There is no answer that is optimal for all applications and situations. A good way to approach the problem is to first select the cellular technology, then select the appropriate evolution of that technology, and then to finally select the proper hardware platform of that cellular technology.

A Personal Trek into the World of Wireless Data

[Note: I recently found this article that I had written 18 years ago in a publications database on the web. For context, this article was written 12 years after the first introduction of the IBM PC, and two years before the initial public availability of the World Wide Web. Some of the topics of discussion are quaint today, such as the focus on mainframe terminal-based applications and on the proprietary wireless networks that prevailed at the time. But the fundamental observations I made then are still true today. Wireless data applications have been a long time coming. – WS]

Wireless datacom is a jump-shift from conventional datacom. A look at some of the fundamental differences.

As technologies change the face of business communications, those who develop, market, manage and use new communications technologies also must go through a rite of passage to understand, interpret and implement new solutions. One particularly challenging transition is the shift from the world of conventional, wireline data communications to the wireless data communications world.

Two factors are stimulating interest in wireless data communications. One is the explosive growth of cellular service. Technology brought a unique and much-needed solution to an area--mobile voice communications--that had been poorly served in the past.

The second factor is the growing disparity between the automation tools available to those who primarily operate from fixed locations (i.e., traditional office desktops) and those who are "mobile." This disparity was not an issue when corporate information systems were primarily host-based transaction processing systems, but personal computers and workstations have altered expectations for employee productivity and effectiveness. As a result, organizations are now investigating ways of bringing mobile employees into the information network.

Last year, I made a personal and professional transition into the emerging world of wireless data communications. Even though I had worked extensively with large corporate data communications environments--IBM SNA, NetBIOS and Netware PC local area networks and "open systems" communications (i.e., TCP/IP and X.25)--my years of experience with traditional data communications proved to be of limited value.

Many fundamental differences exist between the new wireless data communications world and the familiar data communications environment from which I had come. I will focus on wireless data communications in wide area or metropolitian area data networks, as opposed to wireless LANs.

Scarce Spectrum

One of the most striking differences between traditional datacom and wireless data is that the basic, fundamental medium is extremely limited. Only so much radio spectrum is available, and unlike copper or optical fiber, there isn't any more being made. This fact affects all aspects of wireless communications, including its availability, cost and data rates.

The total amount of raw usable spectrum bandwidth available for wireless data communications is roughly equal to 1,700 to 2,000 T1 circuits, 250 to 300 Ethernets or 25 to 30 FDDI networks. While the wireless datacom industry is developing techniques for more efficient frequency reuse and allocation, data compression and high-efficiency protocols, the laws of physics will prevent us from converting to a totally wireless communications world.

Some industry pundits argue that spectrum isn't really scarce but it used inefficiently. While it is true that spectrum in the U.S. isn't used efficiently, the reality in today's market is that virtually all of the most usable frequency bands have already been allocated, either to a specific user or to an industry.

Moreover, the mechanism for allocating spectrum in this country is intensely political, and the rules of the game have been set up such that it is a win-lose situation: If you want access to spectrum, you have to dislodge whoever is currently using it. This process is expensive and uncertain.

In many cases, the incumbent owners of spectrum have long-standing relationships with the regulators, and regulatory authorities have a long history of favoring voice over data communications. The bottom line is that spectrum for data communications will remain scarce.

The scarcity of spectrum is part of what makes wireless communications so much more expensive than traditional landline communications (see Figure 1). Corporations should be wary of implementing wireless data communications casually or in volume, because it can quickly add up to serious money.

Telecommunications managers who pay the bills for cellular telephone service can appreciate how quickly wireless communications expenses can run up. In addition, many wireless data networks charge by the packet, which can accelerate costs even more.

The Federal Communications Commission's historical philosophy toward spectrum allocation is not consistent with efficient wireless data communications services. For example, spectrum tends to be allocated in channels that represent the spectrum capacity needed to carry human speech--about 25 kHz. The present practical maximum amount of data that can be pushed down such a channel is 19.2 kbps, hardly significant by conventional telecommunications standards.

Even though wireless data seldom achieves this maximum because of these networks' high errors rates, the effective data rate is usually enough to support the kinds of interactive terminal-oriented applications that are in common use today. Moving larger amounts of data, such as file transfers and faxes, tends to happen at speeds characteristic of dial-up telecommunications rather than the rates supported by LANs or backbone landlines. If the objective was to extend existing terminal-oriented applications out to the field using wireless communications, the scarcity of spectrum would prevent enough channels from being available to support a significant population of terminals going on line concurrently.

Another problem is that a single slice of spectrum is usually allocated to several geographically separated users. Various users in Seattle, Dallas and Boston may receive an allocation for the same frequency because their transmissions could not interfere. Most of these frequencies were originally allocated to local-only services, such as public safety and taxi dispatch, and little attempt was made to make coherent and consistent frequency assignments across the nation.

As a result, it is difficult to get a single uniform national channel assignment. Thus, a company may have data radio equipment in one city that won't operate in another city. While today's data radio equipment is usually "frequency agile," and thus able to operate on a broad range of frequencies, this capability doesn't come free--it increases the cost of the already expensive equipment. Moving data over the cellular telephone system and over certain national packet data services, however, provides national service on the same frequency bands.

Hostile Environment

Reliability problems are another surprise waiting to happen. Wireless data is not as reliable or accessible as data moving over wireline telecommunications or LANs. The radio environment has significant signal quality problems compared with copper wire or fiber optic media, and these problems are particularly troublesome for data communications, where small interruptions in the link can corrupt data or even drop the link.

Radio signals attenuate sharply over distance, and signal strength typically falls proportionately to the distance between the sender and receiver. In wireless communications, the sender and/or receiver is often moving, and it is impossible to install signal repeaters or amplifiers between them. As a result, a rapid decrease in signal strength is unavoidable.

This significantly limits the practical distance between sender and receiver. The equipment to increase that range--to detect a weak signal and to amplify and process it to a usable form--becomes more expensive as the desired separation between sender and receiver increases.

The radio environment is much noisier than the telecommunications environment, and a variety of factors make it difficult to distinguish the sender's attenuated radio signal from other radiated spectral energy in the band being used. Some of this noise is natural (like the interference from sun spots), while some comes from artificial sources--e.g., licensed in-band transmitters that are not operating properly and are spilling energy into the signal band.

Interference can also come from the sender's own signal as multiple reflected versions arrive at the receiver's antenna at different times (i.e., multipath effects). The strength and nature of interference is changing constantly, and when it is strong enough to disrupt the ability to distinguish signal from noise, bits of the data stream can become lost. This is especially common when one end of the link is moving. Again, more capable and expensive equipment can overcome some of these problems, but there are limits to what the technology can achieve.

The effects of range and interference, combined with the ever-present limits on available bandwidth, severely constrain the data rates that wireless systems can sustain. Wireless local area networks can support data rates of millions of bits per second, but the rates are still far below those provided by high-speed LANs like FDDI.

Conventional data protocols are not practical in the wireless environment

The difference in data rates is even more pronounced for metropolitan and wide area networks. In a world where wide area telecommunications networks often are designed with T1 as the minimum unit of capacity and new low-cost modems are achieving 56 kbps over dial-up connections, wireless data networks are struggling to deliver 19.2-kbps links to mobile users.

Unfortunately, the practical throughput on wireless networks is usually about half of this "rated" capacity because of the high overhead of signaling and error correction protocols. This will significantly influence the architecture of potential wireless applications. Many companies will find that it is neither feasible nor affordable to extend even terminal-oriented interactive transaction networks out over the wireless environment unchanged, let alone extend native connections to LANs.

As if the wireless data environment did not offer enough challenges for users, it is also not dependable. Those who "rent" airtime--which you will do unless you are one of the elite group that already owns spectrum--cannot assume that a wireless link will be available on demand. Most cellular telephone customers who live in large cities and use their phones during rush hour are already familiar with this phenomenon.

Spectrum is indeed scarce, and there are more people who want to use it than the available bandwidth can support. Even the largest wireless packet data network in this country is reported to hit capacity limits during peak use periods. The lack of dependable availability is likely to worsen as wireless data services become more accessible.

Yet More Data Protocols

Another surprising aspect of wireless data networks is that they use protocols that are entirely different from anything else you have ever seen. Conventional data protocols are not practical in the wireless environment because the bandwidth is too scarce and because normal bit error rates are too severe.

To maximize the bandwidth for user data, wireless protocols cannot afford to use large packet sizes, large packet or frame headers, frequent positive acknowledgments, inefficient error recovery methods (i.e., send the packet again) or other protocol overhead such as address and route broadcasts, or excessive link and session synchronization. Conventional data link and transport protocols--such as SNA, TCP/IP, NetWare, Ethernet and X.25--won't be used because they are spectrally inefficient and inadequate to deal with the error-prone radio environment.

Even modem-based data communications over standard cellular telephone channels increasingly use custom wireless protocols such as MNP-10 and modified versions of V.42bis. While wireless packet data network protocols are unique, most of these networks provide somewhat transparent gateways for the corporate network using conventional protocols such as SNA/SDLC, X.25 or bisync. The connection at the mobile radio modem is somewhat different, however, and often requires the end user device to incorporate some awareness of the wireless network protocol.

Wireless data protocols are newer than their wireline counterparts, and thus, not surprisingly, they tend to be less mature, robust, functional or integrated than their older siblings. For example, network managment functions are generally not supported into the wireless network, let alone across it.

With the exception of the cellular modem protocols, most wireless data protocols are proprietary to the network or equipment vendors. This contrasts with the trend toward "open systems" protocols that are controlled by vendor-independent standards organizations. This level of maturity does not yet exist in the wireless data communications industry. The consortium behind the evolving protocol for the Cellular Digital Packet Data network is dominated by network service providers.

While most of these proprietary protocols have published interfaces, they are still vendor-controlled, and in this regard they are no more "open" than SNA or NetWare. Most users will find the wireless data environment less "open" and more enslaved to the proprietary interests of the vendors than their corporate information networks.

The consequence is that users who are entering the wireless data world will have to learn about a different communications environment with new architectures, capabilities and protocols. While many of the concepts and techniques of classic datacom also will apply to wireless, the transition will be confusing, frustrating and challenging for a while.

The Need for Client/Server

Because wireless data communications is expensive and prone to errors, it is imperative to send the fewest bits possible through the air to perform the application. Looking at it from this context, most companies will conclude that they will not be able to run existing applications just by moving the operator out to the end of a wireless link.

Mainstream corporate transaction applications usually work interactively with operators using terminals. These applications send full screens of data as character streams, and often include additional bytes for screen formatting and other user interface functions. Many interactive terminal applications echo characters back to the screen from the application or resend the entire screen contents just to update one field.

LAN-based applications tend to move even larger volumes of data between the file or application server and the user's workstation. However, the cost of operating applications in a manner that sends a lot of data over the wireless connection quickly becomes prohibitive.

While the use of compression techniques can help reduce these costs, they are only a partial answer. Most companies will need to rewrite existing applications to migrate to a wireless environment. To minimize the data sent over the radio link, the application should send flags, codes and preformatted data rather than English-language character streams.

Applications should send dynamic data to a mobile user workstation that can interpret the coded data and manage the user interface locally with predefined screens. This implies an intelligent workstation for the mobile user, which further implies closely designed cooperation between the central application and the user's interface workstation. If this sounds like a client/server architecture, it is.

The original intent of the client/server architecture was to take advantage of the processing power of increasingly low-cost user workstations to handle local, user-specific processing tasks--e.g., graphical user interfaces, data formatting and editing, and local data manipulation. Under this concept, central application servers can be dedicated to functions that need to be centralized, such as core application and data-base transaction processing.

Adopting this architecture of application-to-application communication between the central server and the user workstation tends to reduce the volume of information that needs to flow between those two systems. A properly designed application can even more effectively minimize the data movement between the client and the server.

Most companies will need to rewrite applications to migrate to wireless

The client/server architecture is ideal for developing spectrally efficient, cost-effective applications for the wireless data environment. While corporations have been conservative and deliberate about adopting the client/server architecture in their existing information systems, the benefits of client/server are much more compelling in the wireless environment.

Looking to the Future

Wireless data applications will benefit many organizations as the need grows to provide large numbers of mobile workers the same automation advantages as office workers. The strong growth of portable computing will only amplify the need to tie mobile workers into the organization's information system.

This new wireless data communications environment presents unique challenges and pitfalls. Because spectrum is scarce, wireless data will never be cheap or easy to use. It will always require that the organization's systems and communications architects design applications and networks specifically for the radio environment.

Implementing applications in the wireless data world is difficult, but things will get better. While most of the companies that serve the wireless data market come from the voice side of the industry, they are getting increasingly sophisticated about computer systems and data communications. The FCC has developed a progressive, open-minded stance toward wireless communication, and it has actively fostered technological innovation and responded to market needs. These initiatives will stimulate revolutionary changes in corporate information systems similar to those that came from the introduction of the personal computer and the local area network.

Published in Business Communications Review, Vol. 23, Issue 4, April 1993.

Where Did These Charges Come From?

Last month we received the following queries from two customers:

Customer #1:  “I know that my devices only send 40 bytes and the portal is reporting they sent anywhere from 397-767 bytes. Where are the extra bytes coming from?”

Customer #2:  “My IIS is reporting that I have sent/received a total of 3,075 bytes, but when I look at the portal it says 6,000 KB. I am trying to figure out where the other 2,925 bytes are coming from.”

Unfortunately, these are typical queries we get from customers who have launched their first wireless application. Their first reaction is that something must be wrong with the carrier’s service or billing system and that they are being improperly charged.

Let me start off stating categorically what we tell customers every time these discussions start:

·         No carrier interjects billable bytes or data into a customer data stream that inflates the billable data volume – the data reported in the management portals. In fact, all of the carrier interactions with the device take place over the control channel (i.e., device registration and authentication, channel assignment and cell site hand-off, packet data protocol (PDP) context session initiation and termination, etc.), are not counted as billable transactions and do not show up in the count of billable data.

·         Carrier billing systems are ruthlessly accurate at counting the data incurred by communicating devices, down to the byte. They do not make mistakes. We have confirmed this numerous times by sniffing the raw packet traffic just outside the carrier’s point-of-presence at their GGSN.

So ALL of this measured data traffic is caused by the device and the central application with which they are usually communicating. But clearly it is more data volume than the customer expected. In fact it is a lot more – the 2x to 20x underestimations in the customer examples above are unfortunately typical. And since carriers charge for all data usage, these underestimations are expensive.

So what is causing the extra data that these applications are being charged for?

I will start by pointing out that carriers charge for every byte that is transmitted over the data channel. All of the carrier’s management functions are conducted over the control channel, so all data traffic flowing over the data channel – whether sent by the device or sent by the central application – is presumed to be caused by the customer application and is considered billable.

Another consideration is that carriers measure data by the “session.” Here the “session” in the wireless world is from when the PDP context is first established until it is closed. Within this PDP context session, data can flow back and forth between the device and the central application in multiple transactions or packets. At the close of the session, the carrier simply measures and reports the total number of bytes sent by the mobile device and the total sent by the central application over the air. Neither carriers nor their MVNOs capture or record any more detail than that, which contributes to the customer’s confusion about what causes session totals.

Yet another consideration is that the carriers charge for all data that is transmitted over the air. They do not guarantee the receipt and processing of data by the destination end point. If an action by an application node causes data to be sent over the wireless channel, it is billable even if it is not correctly “received” by the destination end point address.

So again, what is causing the extra data that these applications are being charged for? There are some principal causes.

Communications Protocol Overhead

A number of novice wireless application developers use TCP as the fundamental transport for their application – because it is what they are used to using in wireline communications, and it is the prevailing communications protocol in an Internet dominated world. Unfortunately, TCP is a relatively chatty protocol that imposes a high amount of data volume overhead on most M2M applications. TCP wraps a significant amount of data around the customer’s payload. TCP packet overhead can include fully qualified destination address, sender address, routing information, error correction checksums, packet sequence numbers, datagram descriptors – the list goes on and on.

In addition, TCP is a chatty protocol that causes a number of messages to be exchanged between the sender and destination in addition to the principal message carrying the customer’s intended payload. These additional messages may include TCP session negotiation and establishment, encryption negotiation, address advertisement and routing negotiation, confirmation of receipt, resend of incorrectly received packets, flow control throttling – this list also goes on and on. With the protocol stack often embedded in the radio module itself, much of this chatty overhead can not be turned off in the configuration of TCP. But even when it is accessible, many novice wireless developers do not do this because it isn’t needed over wireline connections and it “gives up” functionality.

All of the bytes involved in operating these communications protocols and transactions are billable data.

Application Overhead

The application itself can be designed to cause additional billable data traffic that is not directly involved in moving “application data” between the device and the central application. Sometimes these transactions are designed intentionally, and some unwittingly. For example, sometimes the application polls remote devices for the data it wants. Or the remote device sends heartbeats to signal to the application that it is still operational, to keep its PDP context session active, or to communicate its dynamically assigned IP address. The device or central application may be designed to require the receiving node to send an acknowledgement that the message or data was received correctly. All of these actions will generate billable traffic on the wireless network, and if they are being conducted using TCP and its headers, then the data volume can balloon.

Any transmissions which are used to configure or manage the device, or to troubleshoot the application will also cause billable traffic. This will include all commands sent to a remote device to change its configuration, release it to sleep mode, or clear or reset alarms. “Pinging” the device, collecting configuration parameters (e.g., device serial number, firmware version, current settings), or uploading logs will cause billable data traffic. Synchronizing state between the remote device and the central application will also generate additional traffic, as will having the application synchronize the time base with the device. All of these actions will generate data traffic that is measured and billed.

All of the bytes that the application causes to be sent between the device and the central application are billable traffic, not just the bytes that may be displayed in the application or stored in its database.

Communications Errors

Problems with the overall communication system may cause data to be sent over the wireless link that is billable, but which may not reach the destination application. Establishing a PDP context usually means that an end-to-end connection is established at the Layer 3 protocol level before any application communication starts, so this should usually not be an issue. Bugs do occur in customer applications or configurations, however, that do result in network traffic that is invisible to the customer application.

The most common cause of this type of unexpected data volume are defects in the application or device that cause messages to be sent repeatedly and frequently in error. The receiving node is not expecting the messages, or does not even recognize the contents, and so they are not “recorded” at the application. The sender keeps sending because it is not receiving an acknowledgement, because of a corruption of a timer setting, or from some other application defect. But since this bug produces data transmissions over the air, they are all billable.

Other communications errors can be the result of poor wireless application design. For example, a device may be designed to “recover” and restart a communications session if it does not receive an acknowledgement within a timeout period. But the variable latency in the wireless network may have caused a delay in the device registering or establishing the PDP context. The originally submitted data transmission may still be “in process” when the device decides to reset and start over. Any data sent before the PDP context was terminated will still be chargeable, even it is not usable to the destination application.

In marginal coverage, the wireless link may fail and the PDP context may terminate before a transmission that is in process can “complete. “ Any data transmitted before the link dropped would still be billable, even if the partial transmission is unrecognizable and unusable to the destination node.  All retries would also be billable transmissions, and these could add up if the coverage is marginal enough and the connection link cannot stay up long enough to complete a transaction. This phenomenon is fairly uncommon, but it can cause a significant volume of traffic if the application is designed to just keep trying. It is worth noting that marginal coverage, or even lack of coverage, is not a “bug” of wireless networks. These networks do not guarantee any coverage, and they only provide service on a “best efforts” basis.

All data sent over the wireless channel is billable, whether a transaction or session completed normally from the standpoint of the application.

Rounding

Another potential reason for the difference between what a user thinks they are sending, and the data volume for which they are billed, is rounding. Rounding is a practice followed by some carriers in which they “round up” the measured data traffic in a session to an even amount for billing purposes. Usually the measured data traffic in a session is rounded up to the next whole kilobyte, although some international carriers round up to the nearest 10 kilobytes. Rounding can undermine the efforts of diligent application developers who are selective about the data they send, send it in a compressed binary form, and use a low overhead protocol (such as UDP). Rounding can have a significant impact on the billable data volume when very small amounts of data are sent during a session, but its impact is less noticeable in applications that send higher data volumes.

Rounding usually shows up in the invoice or even the summary list of sessions. Most carrier portals provide the underlying real byte count of data sent to and from a remote device, so the effect of rounding can be identified.

Summary

The portal traffic statistics do not lie. What it reports is the actual billable traffic that the application is loading on the wireless network.

Analysis of the communications link is necessary to find the specific root cause of the unexpected data volume. The best way to diagnose these communications issues is to run a protocol “sniffer” on the communications feed from the carrier before it reaches the destination node. For some communications problems, data communications analysis may even need to be done in front of the firewall. Instrumenting the device and the central application to capture communications traffic and facilitate diagnostics is also usually helpful.

The bottom line in this type of situation is this:

The application developer’s surprise about the difference between the payload size and the chargeable data volume only indicates that they do not understand some fundamental principles about how their application works, how data communications protocols work, and how the cellular communications network works.

How M2M Cellular Modules Evolve

M2M applications use mobile radios that are built from the components originally designed to serve the cellular telephone industry. Although the functional requirements of M2M applications are relatively modest, it is less expensive just to use the full function, telephony-oriented components whose costs have been driven down by the volume of telephone handsets.  M2M-oriented embedded modules are built from these general cellular components. These modules are designed to fit the specific needs of M2M applications, including manufacturability, form factor, power requirements, and data inputs and outputs.

The technology underlying the cellular telephone network has been evolving over the years as carriers have sought to support more users on their limited spectrum, and to provide more functionality in their phones. Originally based on an analog architecture, cellular networks next evolved to a more efficient digital foundation. The digital signaling technology of cellular networks then evolved to ever more efficient and functional versions. The data communications services of GSM digital cellular networks, for instance, started with a technology called GPRS, which has evolved through fundamental redesigns to newer and better versions, typically called 2G, then 3G, and now 4G. M2M applications, and the radio modules that they embed in their devices, also continue to evolve along these lines with the technology in the underlying cellular networks.

We now have enough history of M2M module development that we can describe the evolution path that modules will follow in these technology versions. The market has seen GPRS modules become widespread. Subsequently 2G modules have also evolved to relatively low prices and broad use.  3G modules -- and now 4G modules -- are making their appearance in the M2M market, and we can see that they are evolving through the same orderly pattern as the earlier technologies, GPRS and 2G.

First of all, M2M modules tend to lag behind the state of the art in cellular technology because M2M performance needs are so modest and because M2M applications are highly sensitive to device costs. 2G M2M modules appeared only after the technology had been pioneered in the cellular handset part of the industry, and 2G M2M modules reached wide adoption years after 2G cellular phones became the dominant handset technology. The enabling components for a new technology like 2G are used by the cellular handset industry first as carriers leverage the greater functionality and spectrum efficiency of the technology in the large mobile telephony market. A technology like 2G is incorporated into M2M modules only later after the telephony market has driven costs down enough to match the price sensitive requirements of M2M applications.

Secondly, modules of a given technology stage are relatively expensive when they first appear, and their price declines over time as they mature. Even though modules mainly use the components of cellular telephones and enjoy the scale economies of that much larger market, there is enough unique about M2M module design and manufacturing that they follow their own price curve. But there is definitely a price curve. 2G modules today are less expensive than 3G modules, which in turn are less expensive that the few 4G/LTE modules that are available. As the overall M2M market has grown, it has enabled M2M modules to reach ever lower price points. Today, 2G modules are less expensive than the earlier GPRS modules ever were. Over time, 3G and 4G modules should come down in price as the previous generations of M2M modules have done.

Third, even as their prices decline, M2M modules offer more functionality over time. This occurs in a consistent pattern as well. When a new generation of M2M modules first appears, it is essentially a bare radio that complies with the new wireless technology. There is very little other functionality in the module. Incorporating this radio module into a working device requires that a co-processor be used alongside the radio module to handle a number of communications functions. The co-processor has to implement higher level protocol functions (such as TCP/IP), control registration and re-registration processes, handle store-and-forward, provide power management of the radio module, and multiplex the different device inputs and outputs with the radio module.

Over time the price of the new generation module goes down, but its functionality also increases. No longer just a bare radio, the module incorporates the TCP/IP protocol stack. It also handles power management and the higher level communications functions that used to be performed by a co-processor. At this stage, a device processor is still required to multiplex I/O and some other functions, as well as to support the overall application logic of running the device itself.

When a module reaches the full maturity of its technology stage, it provides enough capability that an additional processor can often be eliminated from the device, thereby reducing the overall device cost. In additional to all the cellular communication functions, these modules are a complete M2M System on Chip (SoC). They provide a user programmable processor with memory, resources for program and data storage, and several integral I/O ports. They also frequently incorporate value-added functions like battery management, GPS processing, integral temperature sensors and accelerometers, and other functions. 2G modules are now becoming available with this high level of functionality that enables ever more cost effective M2M devices to be built.

M2M modules evolve over time in a predictable pattern. M2M modules in a new cellular technology appear well after that technology has been added to the cellular infrastructure and deployed in handsets. The prices of these M2M modules start relatively high, significantly higher than modules using older technology, and then decline over time as improved versions are introduced and volume grows. Those improved versions also expand the functionality of modules within the technology, from the bare radios that are initially introduced to full M2M systems-on-chips. GPRS and 2G modules have run through this full life cycle, and 3G modules are in the middle of this progression. 4G or LTE modules for M2M applications are only starting to appear, so they face many years of evolution before they are cost effective and widely adopted.

The Dysfunctional Evolution of Wireless Applications

At the current embryonic state of the M2M industry, most wireless M2M applications are new. Many of these new M2M applications are actually existing applications that are being converted to communicate over wireless cellular connections. And even many M2M applications that are being newly developed for a wireless environment are being developed by engineers who are working on their first wireless application. Because wireless data communications is a different and uniquely challenging environment, most of these applications will take more time and effort to get working than originally projected. Many of the problems that engineers run into are architectural and fundamental, which ends up requiring an extensive redesign and rewrite of the application, or abandoning the project outright.

Why do M2M applications, and the engineers that develop them, get into this predicament? Some of the blame comes from the nature of the development process itself. Let me explain how this usually happens.

Fundamentally, most M2M applications are variants of client-server applications. A central server-based application communicates with remote devices that function as clients of the central application. The central application usually gathers data from the clients. Sometimes the central application sends commands to the clients, and sometimes the clients query data from the central application. Most M2M applications are fundamentally client-server in their architecture.

Client-server applications have been successfully architected and implemented for decades. The fundamental approaches are broadly known and practiced, and the development process is as well. And this is at the root of problems with M2M application development. Engineers who develop an M2M application like they do traditional client-server applications are prone to make architectural design decisions that, in a wireless environment, make the application perform poorly, expensive to operate, or simply unable to function.

When engineers start developing a client-server application, the application is usually initially prototyped in the lab. The server application is prototyped on a dedicated PC, and the client component of the application is simulated on a separate, dedicated PC. Usually the two PCs are connected using a direct serial connection to “simulate” the network. Sometimes the client application is actually compiled or ported to run on an actual client device, but at this stage it still communicates with the server over a direct serial connection. The basic functions of the server and the clients are implemented in this prototype, as well as the overall approach to how the server and clients will communicate with each other.

As the development of the client-server application proceeds, the functionality of the client and server components expands to meet the overall application requirements. The connection between the client and server is usually upgraded to running over a local TCP/IP-based network. The application is enhanced to deal with the aspects of communicating across a network, including dealing with multiple concurrent clients, dealing with network addressing, handling flow control, and interfacing to an underlying communications protocol stack. The fundamental architecture set in the bench prototype usually remains unchanged, however.

In the next stage, the client-server application is deployed to operate in the “field” over the public Internet. The communications capabilities of the clients are expanded to deal with static or dynamic address assignment, firewalls and routers, loss of Internet connectivity, and the slightly higher latency that can occur across the public Internet. Server applications are also enhanced to handle dynamic client addresses, the impact of firewalls at both the server and the client, and the expectation of dealing with even more concurrent clients. The fundamental architecture from the bench prototype still remains unchanged.

At this point, the communications architecture of the client-server application is pretty much set in concrete. The data model of the information being exchanged between client and server is fixed. The messaging structure and data flows between the client and server – both the messaging sequences and the message contents – are similarly embedded in the code. The application may be structured around assumptions of timing and latency, outage duration, communications bandwidth, and underlying protocol support that have been valid and worked fine over the networks on which the application has been developed so far. Circuitry has been designed, and software has been developed, tested, modified and refined.

Whether the application was intended to operate in a wireless environment from the start, or is being converted to operate wirelessly after successfully operating over wireline communications, an application developed in this sequence invariably faces serious problems when it attempts to use a wireless communications network. The developer assumes that since they are using a TCP/IP communications stack on both the server and remote client side, that they are isolated from vagaries in the underlying physical network. But many of the assumptions made about the underlying communications transport are completely invalid in a wireless network. By this point in development, however, those assumptions are deeply embedded in the application architecture and implemented in the code.

When this application is now deployed to operate over a wireless network, its performance can differ widely from what is desired or expected. The cost of usage-based charges over the wireless network is usually surprisingly high. The application will regularly experience higher latencies and prolonged loss of communications, which it may or may not handle gracefully. Communications may not be established between the remote devices and the server for reasons that are unfathomable to the developer, because a cell phone works fine in the same location. Very often, these issues are a result of the application design.

For a client-server application that was designed for a wireline transport, fixing it to work well over wireless is never easy. Making a few tweaks to try to get the application to work acceptably is almost never successful. By this stage, significant structural changes are often needed to get the application to work over a cellular transport. Sometimes the scope of those changes is so great that it would be easier to just rewrite the application. Unfortunately the same application developer whose unfamiliarity with wireless got things into this situation often does not immediately comprehend how significant the required design changes are. Not until a few fix attempts are unsuccessful does it become clearer to the developer how much the application needs to be fundamentally changed to work over a wireless transport. Now the project schedule and budget are truly blown.

Following the traditional approach of prototyping and developing client-server applications in a wireline environment, and using design practices that can be made to work over those connections, often leads novice wireless developers to develop applications that really can not work over cellular connections. Someday a large number of application developers will have experience in this environment and will avoid those mistakes. Unfortunately, we are not close to that point today.

Wireless Is Different: Advice For Application Developers

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/100^th to 1/1000^th 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.