Last week, I continued a series on the best practices for M2M data transports and posted Part 1 on Wireless IP practices. Earlier posts have covered best practices for SMS.
This week is Part 2 in the series on Wireless IP best practices.
Best Practices for Wireless IP in M2M
This section continues the outline of practices that will maximize the benefits of using Wireless IP as an M2M data transportfor detailed assistance, please contact Aeris Sales Engineering.
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 data transport. The answer, not surprisingly, is: It depends! From the Internet Engineering Task Force (IETF) detailed definitions, lets briefly describe these two protocols to understand why one may be better than the other for certain 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 (RFC) specification, specifically 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 TCPi.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, specifically 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 UDPi.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.
However, it is also important to note that using these two protocols is not mutually exclusive for a given M2M Application.
For some uses, a simple transmission of a UDP packet to a remote host may be quite sufficientincluding 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 uses, 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 require a complete retransmission.
Should transmitted data from an M2M Device be encrypted to enhance security? Lets examine the perceived need.
While it is true that the radios in wireless cellular systems can be overheardit is radio after allthe 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, and are not capable of overhearing 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 localizedradio frequency (RF) transmissions from a particular Module do not travel more than a few miles in dense urban areas.
In the Aeris CDMA network, the network transmission of data is very secure. Once the Device transmission and data leaves the radio network, it is received at Aeris via Virtual Private Network (VPN) connections from the Carrier networks, and sent to the Customers systems via other VPN connections.
These VPN network connections are already encrypted and provide secure access.
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 Application Devices.
Based on these issues, our experiences, and use of VPNs where appropriate, Aeris does not recommend, or require, Application-level encryption of IP data to and from the Modules.
Regardless, we do not prevent Customers from encrypting the data if they want to do so!