Wireless IP for M2M / IoT 101 Neo White Paper A concise introduction to using wireless devices for M2M / IoT data transmissions. www.neo.aeris.com
Let our experts lead the way Table of Contents INTRODUCTION 2 WHY DO I NEED WIRELESS IP FOR M2M / IOT COMMUNICATIONS? 2 WIRELESS IP IN M2M / IOT: THE BASICS 2 WIRELESS IP RADIO MODULES 3 POINT-TO-POINT PROTOCOLS 3 IP SESSION STARTED BY THE DEVICE 3 UDP OR TCP? 4 USER DATAGRAM PROTOCOL (UDP) 4 TRANSMISSION CONTROL PROTOCOL (TCP) 4 WHICH PROTOCOL TO USE? 5 SECURITY 5 ABOUT NEO 6
INTRODUCTION Since the introduction of wireless IP for M2M / IoT networks in 1995, communication and data transmission between and among machines is faster than ever before. More, it requires less power. This revelation has not only increased the speed of business, but also enabled the introduction of many new products and applications for M2M / IoT communication. WHY DO I NEED WIRELESS IP FOR MACHINE TO MACHINE COMMUNICATION? The first M2M / IoT applications utilized SMS as their data transport methodology. While very reliable for the delivery of data, SMS is limited to 140 eight-bit bytes (or 160 characters of seven-bits) of M2M / IoT application data in every message packet transmission. This is true for both GSM and CDMA cellular technologies. Many M2M / IoT applications require more bandwidth than SMS allows. For example, firmware updates for a remote device or content updates for a digital billboard require more data to be sent than an SMS solution would allow. In 2G GSM and CDMA cellular, the IP data transport technologies are GPRS and 1xRTT. While these have slower data throughput rates compared to 3G and 4G cellular, they are quite sufficient for the IP transmission needs for most M2M / IoT Applications. (Readers should be aware that all 2G GSM GPRS services on the AT&T network will be shut by the end of 2016) For M2M / IoT applications requiring faster transmission rates, devices use 3G CDMA and GSM protocols such as EV-DO and HSPA (or 4G LTE in the future). Today, HSPA geographic coverage in the US does not match the EV-DO coverage, and LTE coverage is not sufficient for M2M / IoT applications. Finally, the cost per byte of data is significantly lower for wireless IP when compared to SMS as a transport. 3G radio modules are more expensive than 1xRTT modules, so they are only used when the faster transmission rates are required for a particular M2M / IoT application. All of this has led to the mass adoption of Wireless IP as the primary method of data transfer for M2M / IoT applications. WIRELESS IP IN M2M / IOT: THE BASICS This section describes the basics of wireless IP for M2M / IoT data transport. First, it is important to recognize that wireless IP data technologies are not the same as wired IP data technologies. Recently, software developers, used to working with DSL, fiber and cable IP services (and local area IP networks), have begun working on wireless IP devices. They sometimes attempt to apply wired IP practices to wireless IP implementations and then things are certain to go awry.
WIRELESS IP RADIO MODULES THINK MODEMS Wireless IP radio modules ( modules ) are more similar to old dial-up modems than continuously-connected devices used in DSL and Cable IP services for example (DSL and cable units also perform the functional equivalent of dial-up, but these are usually set to dial immediately on power-on, and stay connected till power-off acting as if they were connected via a physical wire to the Internet). To establish a session, the M2M / IoT code must initiate the cellular transmission from the module using a dial-string similar to making a phone call with a dial-up modem. The controller running the M2M / IoT code sends an AT command (for example, ATDT #777 ) to the module over a RS-232 or USB port. Using AT commands with modules is very similar to using AT commands (originally developed by Hayes Corporation) for traditional dial-up modems. After receiving the ATDT #777 command, the module originates a call using the dialed digits #777 to the Mobile Switching Center ( MSC ) that is serving the device in the local cellular network. The MSC interprets the digits #777 as a request to establish a data session and allows the process to continue. The detailed mechanisms of establishing an IP session in Wireless IP technologies (authorization, authentication, etc.) is not described here. It is sufficient to note that the cellular systems have the necessary equipment, protocols, and communication and control mechanisms to make it happen, using relevant cellular standards. POINT-TO-POINT PROTOCOLS Using a Point-to-Point Protocol ( PPP ) session for IP data transmissions after dialing in using a module, is just like using PPP on traditional dial-up modems on dial-up telephone lines. In traditional dial-up modem connections, the computer that is connected to the modem uses a PPP stack to establish an IP session to the network and remote server. This is under the control of the computer, since the user can choose whether the dial-up modem connection is used for an IP data session or with a terminal emulation program for accessing the server. TODAY, HSPA GEOGRAPHIC COVERAGE IN THE US DOES NOT MATCH THE EV-DO COVERAGE, AND LTE COVERAGE IS NOT SUFFI- CIENT FOR M2M / IOT APPLICATIONS. Similarly, the wireless device must use a PPP stack for the IP data session to the cellular network. IP SESSION STARTED BY THE DEVICE In cellular data technologies, the session is always initiated by the module (under the control of the external M2M / IoT application code) the analogy to dial-up modem service holds true. Thus, until such an IP session is started and connected, there isn t any IP data path for a network system or server to send IP data to the device. M2M / IoT applications are generally designed with this concept in mind. However, if the network or server needs to initiate the transmission of IP data to a device, mechanisms called shoulder-taps must be used to cause the device to start the actual session if it is not in a session. Typically, these shoulder-taps are Mobile-Terminated SMS ( MT-SMS ) messages sent to the device.
UDP OR TCP? We are often asked whether a device should transmit User Datagram Protocol ( UDP ) packets or use Transmission Control Protocol ( TCP ) streaming sessions for M2M / IoT data transport. The answer, not surprisingly, is: It depends! From the Internet Engineering Task Force ( IETF ) detailed definitions, let s briefly describe these two protocols to understand why one may be better than the other for certain M2M / IoT data transmissions. First, it is important to note that both UDP and TCP are used over an underlying IP connection. USER DATAGRAM PROTOCOL ( UDP ) The UDP format was first defined in an Internet Engineering Task Force ( IETF ) Request for Comment ( RFC ) specification, RFC 768. This protocol provides a procedure for applications programs to send messages to other programs with a minimum of protocol mechanism. This protocol is transaction-oriented, and delivery and duplicate protection are not guaranteed. If an application requires ordered, reliable delivery of streams of data, UDP is not the preferred protocol. The format has lower overhead than TCP i.e., fewer bytes are sent in the headers of the packets in UDP than TCP. TRANSMISSION CONTROL PROTOCOL ( TCP ) The TCP format was first defined in an IETF RFC specification, RFC 761. TCP is a connection-oriented, end-to-end reliable protocol and is intended for use as a highly reliable host-to-host protocol between hosts in IP networks, and especially in interconnected systems of such networks. TCP requires that a connection be opened and managed for the duration of the IP data transmission. Within the protocol, transmitted and received packets are acknowledged by the device and the servers. The format has more overhead than UDP i.e., more bytes are sent in the headers of the packets in TCP than UDP.
WHICH PROTOCOL TO USE? In general, the choice of UDP vs. TCP must take into account: The desired balance between the reliability of TCP and the lower cost of UDP, since UDP uses fewer bytes of overhead to transmit the same amount of application data. The increased complexity of TCP, where the module must open a data stream to a remote host where server programs await connections. Careful design of TCP server programs to allow easy scaling as the number of deployed Devices is increased. A desire for the acknowledgments provided by TCP sessions. It is important to note that these two protocols are not mutually exclusive for a given M2M / IoT application. For some communication purposes, a simple transmission of a UDP packet to a remote host may be sufficient including using independent acknowledgment packets via UDP. If an acknowledgment is expected, but not received, either side can retry intelligently (i.e., with limits on number of retries, variable delays between retries, etc.) For other purposes, even in the same application, a device may open a TCP connection to a server, and communicate with the higher reliability of a TCP streaming session to a program that accepts these connections and transmissions. Often, the amount of data may require the use of TCP. For example, if an application needs to transmit a large file (more than a few kilobytes), it is better to use TCP, since the consequences of an error during transmission via UDP could mean that the entire file might need a complete retransmission. SECURITY Should transmitted data from a M2M / IoT device be encrypted to enhance security? Let s examine the perceived need. While it is true that the radios in wireless cellular systems can be overheard, the ANSI-2000 CDMA radio protocol is secure to all but the most serious of listeners. The vast majority of individual and entities do not have the expensive equipment needed to listen to the spread spectrum noisy CDMA transmissions. IN THE NEO CDMA NETWORK, THE TRANSMIS- SION OF DATA IS VERY SECURE....VPN NETWORK CONNECTIONS ARE ALREADY ENCRYPTED AND PROVIDE SECURE ACCESS. Furthermore, the cellular nature of the system also ensures that any listening to the radio in the device will necessarily be localized radio frequency ( RF ) transmissions from a particular cellular module do not travel more than a few miles in dense urban areas. Finally, content data encryption may require significant processor performance in the module or device to encode and decode data. This process might be beyond the capability of many M2M / IoT application devices. Based on these issues, our experiences, and use of VPN s where appropriate, we do not recommend, or require, application-level encryption of IP data to and from the modules. Regardless, we do not prevent customers from encrypting their data if they wish to do so.
ABOUT NEO Neo enables any company to easily develop, launch, and manage innovative M2M and IoT solutions that require cellular connectivity while dramatically reducing the time, cost, and hassle of obtaining and operating connectivity through traditional channels. Neo is powered by Aeris. Get in touch To learn more, contact us at info@aeris.net or 1-888-GO-AERIS in North America or +44 118 925 3202 in Europe. Copyright 2015 Aeris Communications, Inc. All Rights Reserved. Like this white paper? Share with your friends. www.neo.aeris.com