Wireless IP for IoT / M2M Best Practices

Transcription

1 Wireless IP for IoT / M2M Best Practices Neo White Paper neo.aeris.com WIRELESS IP FOR M2M / IOT DATA BEST PRACTICES COPYRIGHT 2015, AERIS COMMUNICATIONS, INC. 1

2 Let our experts lead the way Table of Contents INTRODUCTION 1 SMS 1 Wireless IP 1 BEST PRACTICES FOR WIRELESS IP IN IOT / M2M 2 Wireless IP Is Not the Same as Wired IP 2 Wireless IP Radio Modules Are Modems 2 Dueling Stacks 2 IP Session Started by the Device 3 Send Content in MT-SMS Shoulder Taps 3 UDP or TCP? 4 User Datagram Protocol (UDP) 4 Transmission Control Protocol (TCP) 4 Which Protocol to Use? 4 Data Encryption 5 ABOUT NEO 6 WIRELESS IP FOR M2M / IOT DATA BEST PRACTICES COPYRIGHT 2015, AERIS COMMUNICATIONS, INC. 1

3 INTRODUCTION Now that you understand the basics of wireless IP for Internet of Things/Machine-to-Machine communications, you are ready to consider more advanced issues like radio modules, shoulder taps, and UDP vs. TCP. SMS The first IoT / M2M applications used Short Message Service (SMS) as their data transport methodology. While very reliable for the delivery of data, SMS is unfortunately limited to 140 eight-bit bytes (or 160 characters of seven bits) of IoT / M2M application data in every message packet transmission, in both GSM and CDMA cellular technologies. Many IoT / M2M 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 (and sent faster) than an SMS solution would allow. Finally, the cost per byte of data is significantly lower for wireless IP when compared to SMS as a transport. All of this has led to the mass adoption of wireless IP as the primary method of data transfer for IoT / M2M applications. WIRELESS IP Wireless Internet Protocol (IP) data transports are used when the amount of data to be sent per event is larger than an SMS message can contain. 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 sufficient for the IP transmission needs for most IoT / M2M applications. (Readers should be aware that a significant portion of 2G GSM GPRS services will be shut down in the United States at the end of 2016, so CDMA 1xRTT is the only practical option for new 2G devices.) For IoT / M2M applications requiring higher 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 IoT / M2M applications. 3G radio modules are more expensive than 1xRTT modules, so they are only used when the higher transmission rates are required for a particular IoT / M2M application. WIRELESS IP FOR M2M / IOT DATA BEST PRACTICES COPYRIGHT 2015, AERIS COMMUNICATIONS, INC. 1

4 BEST PRACTICES FOR WIRELESS IP IN IOT /M2M This section outlines the practices that will maximize the benefits of using wireless IP for IoT / M2M data transport. WIRELESS IP IS NOT THE SAME AS WIRED IP First, it is important to recognize that wireless IP data technologies are not the same as wired IP data technologies. Software developers who are accustomed to working with DSL, fiber, and cable IP services (and local-area IP networks) should not expect to apply the same practices to wireless IP devices; this will not work. Read on to learn why. WIRELESS IP RADIO MODULES ARE MODEMS Wireless IP radio modules (aka modules) are more similar to old dial-up modems that used traditional telephone lines than to the 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 at power-on and stay connected until power-off acting as if they were connected via a physical wire to the Internet). To establish a session, the IoT / M2M code must initiate the cellular transmission from the module using a dial-string similar to making a phone call with a dialup modem. The controller running the IoT / M2M 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. Readers should be aware that a significant portion of 2G GSM GPRS services are being shut down soon in the United States. The detailed mechanisms of establishing an IP session in wireless IP technologies (authorization, authentication, etc.) are 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. DUELING STACKS 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. Similarly, the wireless device must use a PPP stack for the IP data session to the cellular network. This is a potential source of trouble. Many manufacturers provide an IP stack in the module. However, developers writing code for their IoT / M2M applications sometimes add a separate IP stack to the firmware of their devices. When the module establishes a cellular data session with the network, both stacks may attempt to set up PPP sessions! This causes problems for device operation on the network. The cellular systems providing the end-point of the IP session may get WIRELESS IP FOR M2M / IOT DATA BEST PRACTICES COPYRIGHT 2015, AERIS COMMUNICATIONS, INC. 2

5 confused and assign multiple IP addresses; they may disconnect only one session when the module eventually terminates the session; the systems may reject both session attempts; etc. With the deep network visibility that we have at Neo, we see this conflict clearly as devices attempt to initiate an IP session. We have significant experience working with customers to resolve and correct this condition. Accordingly, if there are two IP stacks in the device, software developers must cleanly ensure that only one stack attempts to establish the PPP session; they must choose whether the IP stack in the module or the application is used. IP SESSION STARTED BY THE DEVICE In cellular data technologies, the session is always initiated by the module (under the control of the external IoT / M2M 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. IoT / M2M 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. SEND CONTENT IN MT-SMS SHOULDER TAPS When an MT-SMS is used to shoulder-tap a device to initiate an IP data session, it is useful to send information to the device in the SMS fields, rather than simply sending an empty MT-SMS, since the length of the SMS content generally does not change its cost. For example, consider sending Absolute Time (perhaps the server time in seconds past midnight UTC ) for the remote device programming to make decisions about the time-validity of a command to take action. Remember to compensate for the (current) 15-second difference between Absolute Time UTC and CDMA time; the latter is based on Global Positioning System (GPS) time and, hence, does not correct for leap-seconds. This is even more relevant if the device has an on-board GPS system from which it receives time data. It may be useful to send the URL for the radio to connect to or IP port number to use or the protocol (such as whether the device should open a TCP session or send data via a UDP packet or use an HTTP session). Since the SMS capacity is 140 eight-bit bytes, or 160 seven-bit characters, all of the above content (including other information that is unique to the IoT / M2M application) can be sent in a single MT-SMS shoulder tap. WIRELESS IP FOR M2M / IOT DATA BEST PRACTICES COPYRIGHT 2015, AERIS COMMUNICATIONS, INC. 3

6 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 IoT / M2M 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 IoT / M2M 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 IETF Request for Comment 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. Today, HSPA geographic coverage in the US does not match the EV-DO coverage, and LTE coverage is not sufficient for IoT / M2M applications. 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 IoT / M2M 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.) WIRELESS IP FOR M2M / IOT DATA BEST PRACTICES COPYRIGHT 2015, AERIS COMMUNICATIONS, INC. 4

7 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. DATA ENCRYPTION Should transmitted data from an IoT / M2M 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 individuals and entities do not have the expensive equipment needed to listen to the spread spectrum noisy CDMA transmissions. 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 IoT / M2M application devices. Based on these issues, our experiences, and use of VPNs where appropriate, we do not recommend or require applicationlevel encryption of IP data to and from the modules. WIRELESS IP FOR M2M / IOT DATA BEST PRACTICES COPYRIGHT 2015, AERIS COMMUNICATIONS, INC. 5

8 ABOUT NEO Neo enables any company to easily develop, launch, and manage innovative IoT / M2M 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. Visit neo.aeris.com or follow us on to learn how we can inspire you to create new business models and to participate in the revolution of the Internet of Things. Get in touch Copyright 2015 Aeris Communications, Inc. All Rights Reserved. neo.aeris.com 1512 WIRELESS IP FOR M2M / IOT DATA BEST PRACTICES COPYRIGHT 2015, AERIS COMMUNICATIONS, INC. 6