In the 1960’s, when the U.S Department of Defense set a requirement for a packet-switched network nobody anticipated that it would grow into what we know today as the Internet. The Internet and Internet Protocol (IP) have changed the way we communicate and conduct business. Having a common communications protocol such as IP has opened the door for many application programmers to develop unique applications for businesses. Today, our networking tools have reached incredible speeds of 1 Gigabit/sec or faster allowing them to support a variety of media including text, audio and video.
In today’s fast-paced, customer focused, business environment mobile workers need and want to have the same information at their fingertips whether they are in the office or on the road. Though wireless data communication has been around for over 20 years, the limitations of radio still don’t allow the same data rates to be obtained in the wireless world as in the wireline world. Today, most over-the-air data rates in the private data industry are between 4,800 bps and 19,200 bps. Compared to their 10 Megabit and 1 Gigabit wireline cousins, wireless data systems are considerably slower. Therefore, when you marry applications that were developed to be used on a high speed, IP-based network with a wireless network, the results can be (and usually are) very disappointing.
To Connect Or Not to Connect – TCP vs. UDP
IP based applications are either “connection-oriented” or “connectionless”. A “connection-oriented” application uses TCP (Transmission Control Protocol) and IP while “connectionless” applications use UDP (User Datagram Protocol) and IP when communicating over a network.
Though you may not have realized it, some common connectionoriented applications are web surfing, email, file transfer TN 3270 green screen and remote terminal login. When one of these applications initiates a remote connection, it is the responsibility of TCP to establish the connection. A TCP connection consists of a three-step process:
A connection-oriented process (TCP/IP) is similar to the process of having a conversation with a friend on the telephone. First, you must call your friend to see if he is home. If someone answers then you would ask to speak to your friend. Assuming your friend is there and picks up the phone, you have now established a connection with your friend. Once the connection is established you can begin a conversation. This exchange of conversation usually consists of something being said and a response from the receiving party to indicate that they heard what was said. If their attention was diverted while you were speaking and they didn’t hear everything you said you might have to repeat what you had just said. In a TCP/IP based application, TCP works the same way. If it doesn’t receive an acknowledgment within a certain amount of time it will retransmit the message.
The “speak and acknowledgement received” aspect is an important part of the process. It tells you if the other person received the information that you just told him. Once the conversation has ended you would start the process of saying goodbye and then terminate the call by hanging up the phone.
As you can see, a connection-oriented process provides some form of reliability. The reliability doesn’t mean that each time you attempt to make a connection that your friend will be there or that you’ll have a good phone line. What the reliability does provide is a series of acknowledgments to let you know that 1) a connection could be established and 2) the information was transferred successfully. Though they provide a certain level of reliability, connection-oriented processes have a lot of overhead or “chattiness” associated with them. Here lies one area that can be optimized.
In contrast to the connection-oriented process, the application in a connectionless process (UDP/IP) does not establish a connection with the receiving application. A connectionless process makes the assumption that either the medium being used (wireline or wireless) will get the message there or the application will determine that the message was received. UDP has been nicknamed the “Unreliable Data Protocol” since there aren’t any acknowledgments given by the system to inform the sending application that the message was received.
Who determines if an application will use a TCP/IP or UDP/IP protocol? The application developer does, and their decision is typically based on the type of network that the application will be used on. Up until now, networks as we know them have predominately been wireline-based, operating at 10Mbps or faster. Since capacity on most wireline networks isn’t an issue, application developers haven’t worried about the additional overhead or “chattiness” required for TCP/IP services. Most of the major, and most popular, business applications in use today have been developed for wired networks and so use TCP/IP.
Understanding the difference between TCP and UDP applications is essential when considering the deployment of a wireless data network. The wired and wireless computing worlds operate under completely different paradigms. The wired world assumes a constant connection with high bandwidth and increasingly faster speeds. A wireless environment functions via intermittent connections over a narrow bandwidth, operating at much slower speeds. These fundamental differences introduce a number of difficulties when organizations attempt to extend traditional “wired” applications over wireless networks.
Packet Payloads
As described earlier, to establish a connection or “socket” TCP requires a three-packet-overhead “handshake.” It also requires another three packets to disconnect. When you are talking about a browser-based application where every HTTP request (which is required for each graphic or file included in a page) opens and closes a socket, the overhead is excessive. This is particularly true in a wireless environment where in some cases you are paying according to the amount of data sent.
TCP also uses a “windowing” protocol that regularly sends acknowledgement packets to let the sender know the progress of the communication. With a wide pipe, numerous acknowledgements are not a problem. However, in a wireless environment, the difficulty comes in the number of acknowledgements that TCP sends. Typically, TCP sends one acknowledgement packet for every one to two packets of data that are sent. Once again, this is extremely high overhead for a wireless network.
Also, because TCP/IP assumes it is communicating between two devices over a wired network the TCP protocol expects to receive these acknowledgements very rapidly. There are timers within the TCP protocol that cause additional retransmissions or a connection to have to be reestablished if these acknowledgement packets aren’t received in a set time because it is assumed that the connection has been disrupted. In a wireless environment, where throughput speeds are much lower and users frequently move in and out of coverage or operate in “fringe” coverage conditions, the timers “expire,” causing connections to drop and restart. To make matters worse, reestablishing that connection yields yet another three-packet handshake.
When operating under fringe wireless conditions, it is not uncommon for some packets of data not to make it through. With TCP, when this occurs it automatically resends all packets since the missing one taking up more bandwidth.
To top it off, TCP applications themselves can often be very “chatty,” generating many communication transactions between devices. For example, these applications may require excessive handshakes (similar to the TCP protocol handshakes) to establish the communication. Also, many terminal emulation-based applications have a number of different screens and since it assumes a “dumb” terminal is being used it sends the data for the entire screen with each field. Finally, TCP applications frequently use “fat” data formats that could be too large to send over-the-air cost-effectively.
TCP/IP Gateway Solutions
So you would think with all this “overhead” and “chattiness”, why even bother using TCP applications? Some organizations have chosen to overcome these TCP overhead issues by substituting the TCP protocol with UDP (User Datagram Protocol). This choice would appear even more obvious when you consider that while UDP/IP’s header payload is only 28 bytes (8 for UDP and 20 for IP) the TCP/IP handshake or header has a payload of 40 bytes (20 for TCP and 20 for IP). However, while UDP/IP’s header size is smaller and does not require handshakes or an always-on connection, it also does not provide acknowledgements, making it truly a “send and pray” protocol. This simply isn’t acceptable in most wireless applications because mobile users need to be sure their message got through and don’t need the hassle of manually resending messages.
While the TCP/IP protocol clearly isn’t designed for wireless communications, at the same time, it has become a “de facto” industry networking and communication standard with the advent of Internet and intranet computing. So the question becomes, if you want to leverage your TCP/IP applications for use in the field, how do you make it work reliably and efficiently?
Over the past couple of years, several vendors have realized that there are a lot of customers that have existing TCP/IP based applications, but would like to use them in a wireless environment. With this in mind, Radio IP Software Inc. has developed TCP/IP gateway software that improves the performance of TCP/IP-based applications in a wireless environment. Using TCP/IP gateway software is a very viable and cost efficient way to extend existing Windows and browser based HQ applications to field personnel. However, before investing in a in TCP/IP wireless solution, make sure you’re getting the best possible solution for your particular situation. Here are a few key questions you should ask your supplier or systems integrator when considering a TCP/IP gateway deployment.
Will the software allow me to use my existing Windows based applications?
Rather than offering a truly optimized TCP/IP gateway solution some vendors offer what is called UDP/IP middleware. Be careful. It is just not viable to run today’s web-enabled, off-the-shelf software like MS Explorer and Outlook in the field using a UDP/IP transport protocol. When UDP/IP middleware is implemented, applications must be modified to do their own error checking and data recovery. Often, a costly Application Program Interface (API) is required for each off-the-shelf software procuct. With a TCP/IP gateway solution, users have the flexibility to run many TCP/IP applications straight out-of the box.
Is the wireless IP solution truly optimized to maximize the application performance?
While UDP middleware does offer data compression, the data is compressed on a packet-by-packet basis but the total number of packets transmitted is not reduced. Packet-by-packet based compression typically compresses data at about 50%, while TCP/IP gateway software compresses data on a socket basis. Data is compressed going into the socket, sending fewer packets and using each more efficiently. Compression rates may vary from vendor to vendor so make sure you check the specs. Some TCP/IP gateway software solutions are able to reduce packet header size to as small as 7 bytes, so it’s worth checking into to make sure you’re getting the best bang for your compression buck.
Can the wireless IP solution roam to dissimilar networks using TCP/IP?
It is rare for one radio network to provide complete coverage of your service area. What you are looking for is a vendor who can offer a TCP/IP gateway solution that automatically and transparently switches to the best network available, based on availability, priority, time of day and cost, to deliver TCP/IP data seamlessly across a number of discrete wireless systems.
Does the wireless IP solution offer data/network security?
The Data Encryption Standard (DES) was developed by an IBM team in the mid seventies and adopted as a national standard a few years later. At the time DES was a major breakthrough in data network security, however, it proved not to be foolproof. The answer was triple DES. Early DES was based on a key length of 56 bits, triple DES simply extends the key length to 128 or 168 to achieve a much higher degree of reliability. The extended key length proved to be very secure and today triple DES has become the de facto standard for data encryption. You should check to see if the TCP/IP gateway solution uses an encryption standard which meets or exceed federal and state requirements.
Mobile Data Computing – Today and Tomorrow
Mobile Data is here to stay and there is no question that its potential is great. But without the proper implementation plan or reasonable expectations the results can be disappointing at best and disastrous at worst.
In one form or another the enabling technologies to deliver real-time data to field personnel are available today, but these technologies are still evolving as are the mobile networks themselves. The best approach is to ask questions. Your wireless provider can be very helpful when it comes to suggesting a development plan. But don’t rely on their advice alone. Look at what other utilities are doing, talk to your peers; conferences and trade magazines like this one can also be a good source of information.
Building a profitable and efficient mobile data network will require careful planning, coordination, and the integration of business processes and technologies. The key is to get educated, work within your resources and start small to meet short-term objectives, while ensuring that you’ve planned a longer-term migration path.
About the Author
Mike Bourre is Vice President of Sales & Marketing with Radio IP Software Inc, based in Montreal, QC. He can be reached at 514.890.6070.
In today’s fast-paced, customer focused, business environment mobile workers need and want to have the same information at their fingertips whether they are in the office or on the road. Though wireless data communication has been around for over 20 years, the limitations of radio still don’t allow the same data rates to be obtained in the wireless world as in the wireline world. Today, most over-the-air data rates in the private data industry are between 4,800 bps and 19,200 bps. Compared to their 10 Megabit and 1 Gigabit wireline cousins, wireless data systems are considerably slower. Therefore, when you marry applications that were developed to be used on a high speed, IP-based network with a wireless network, the results can be (and usually are) very disappointing.
To Connect Or Not to Connect – TCP vs. UDP
IP based applications are either “connection-oriented” or “connectionless”. A “connection-oriented” application uses TCP (Transmission Control Protocol) and IP while “connectionless” applications use UDP (User Datagram Protocol) and IP when communicating over a network.
Though you may not have realized it, some common connectionoriented applications are web surfing, email, file transfer TN 3270 green screen and remote terminal login. When one of these applications initiates a remote connection, it is the responsibility of TCP to establish the connection. A TCP connection consists of a three-step process:
- The Hello Handshake -
Establishes a connection between the sending application and the receiving application - The Acknowledgement -
Transfers the information and acknowledges that it was received properly.
(i.e. the receiving application must acknowledge that the data was received.) - The Goodbye Handshake -
Tears down the connection that was established in step 1.
A connection-oriented process (TCP/IP) is similar to the process of having a conversation with a friend on the telephone. First, you must call your friend to see if he is home. If someone answers then you would ask to speak to your friend. Assuming your friend is there and picks up the phone, you have now established a connection with your friend. Once the connection is established you can begin a conversation. This exchange of conversation usually consists of something being said and a response from the receiving party to indicate that they heard what was said. If their attention was diverted while you were speaking and they didn’t hear everything you said you might have to repeat what you had just said. In a TCP/IP based application, TCP works the same way. If it doesn’t receive an acknowledgment within a certain amount of time it will retransmit the message.
The “speak and acknowledgement received” aspect is an important part of the process. It tells you if the other person received the information that you just told him. Once the conversation has ended you would start the process of saying goodbye and then terminate the call by hanging up the phone.
As you can see, a connection-oriented process provides some form of reliability. The reliability doesn’t mean that each time you attempt to make a connection that your friend will be there or that you’ll have a good phone line. What the reliability does provide is a series of acknowledgments to let you know that 1) a connection could be established and 2) the information was transferred successfully. Though they provide a certain level of reliability, connection-oriented processes have a lot of overhead or “chattiness” associated with them. Here lies one area that can be optimized.
In contrast to the connection-oriented process, the application in a connectionless process (UDP/IP) does not establish a connection with the receiving application. A connectionless process makes the assumption that either the medium being used (wireline or wireless) will get the message there or the application will determine that the message was received. UDP has been nicknamed the “Unreliable Data Protocol” since there aren’t any acknowledgments given by the system to inform the sending application that the message was received.
Who determines if an application will use a TCP/IP or UDP/IP protocol? The application developer does, and their decision is typically based on the type of network that the application will be used on. Up until now, networks as we know them have predominately been wireline-based, operating at 10Mbps or faster. Since capacity on most wireline networks isn’t an issue, application developers haven’t worried about the additional overhead or “chattiness” required for TCP/IP services. Most of the major, and most popular, business applications in use today have been developed for wired networks and so use TCP/IP.
Understanding the difference between TCP and UDP applications is essential when considering the deployment of a wireless data network. The wired and wireless computing worlds operate under completely different paradigms. The wired world assumes a constant connection with high bandwidth and increasingly faster speeds. A wireless environment functions via intermittent connections over a narrow bandwidth, operating at much slower speeds. These fundamental differences introduce a number of difficulties when organizations attempt to extend traditional “wired” applications over wireless networks.
Packet Payloads
As described earlier, to establish a connection or “socket” TCP requires a three-packet-overhead “handshake.” It also requires another three packets to disconnect. When you are talking about a browser-based application where every HTTP request (which is required for each graphic or file included in a page) opens and closes a socket, the overhead is excessive. This is particularly true in a wireless environment where in some cases you are paying according to the amount of data sent.
TCP also uses a “windowing” protocol that regularly sends acknowledgement packets to let the sender know the progress of the communication. With a wide pipe, numerous acknowledgements are not a problem. However, in a wireless environment, the difficulty comes in the number of acknowledgements that TCP sends. Typically, TCP sends one acknowledgement packet for every one to two packets of data that are sent. Once again, this is extremely high overhead for a wireless network.
Also, because TCP/IP assumes it is communicating between two devices over a wired network the TCP protocol expects to receive these acknowledgements very rapidly. There are timers within the TCP protocol that cause additional retransmissions or a connection to have to be reestablished if these acknowledgement packets aren’t received in a set time because it is assumed that the connection has been disrupted. In a wireless environment, where throughput speeds are much lower and users frequently move in and out of coverage or operate in “fringe” coverage conditions, the timers “expire,” causing connections to drop and restart. To make matters worse, reestablishing that connection yields yet another three-packet handshake.
When operating under fringe wireless conditions, it is not uncommon for some packets of data not to make it through. With TCP, when this occurs it automatically resends all packets since the missing one taking up more bandwidth.
To top it off, TCP applications themselves can often be very “chatty,” generating many communication transactions between devices. For example, these applications may require excessive handshakes (similar to the TCP protocol handshakes) to establish the communication. Also, many terminal emulation-based applications have a number of different screens and since it assumes a “dumb” terminal is being used it sends the data for the entire screen with each field. Finally, TCP applications frequently use “fat” data formats that could be too large to send over-the-air cost-effectively.
TCP/IP Gateway Solutions
So you would think with all this “overhead” and “chattiness”, why even bother using TCP applications? Some organizations have chosen to overcome these TCP overhead issues by substituting the TCP protocol with UDP (User Datagram Protocol). This choice would appear even more obvious when you consider that while UDP/IP’s header payload is only 28 bytes (8 for UDP and 20 for IP) the TCP/IP handshake or header has a payload of 40 bytes (20 for TCP and 20 for IP). However, while UDP/IP’s header size is smaller and does not require handshakes or an always-on connection, it also does not provide acknowledgements, making it truly a “send and pray” protocol. This simply isn’t acceptable in most wireless applications because mobile users need to be sure their message got through and don’t need the hassle of manually resending messages.
While the TCP/IP protocol clearly isn’t designed for wireless communications, at the same time, it has become a “de facto” industry networking and communication standard with the advent of Internet and intranet computing. So the question becomes, if you want to leverage your TCP/IP applications for use in the field, how do you make it work reliably and efficiently?
Over the past couple of years, several vendors have realized that there are a lot of customers that have existing TCP/IP based applications, but would like to use them in a wireless environment. With this in mind, Radio IP Software Inc. has developed TCP/IP gateway software that improves the performance of TCP/IP-based applications in a wireless environment. Using TCP/IP gateway software is a very viable and cost efficient way to extend existing Windows and browser based HQ applications to field personnel. However, before investing in a in TCP/IP wireless solution, make sure you’re getting the best possible solution for your particular situation. Here are a few key questions you should ask your supplier or systems integrator when considering a TCP/IP gateway deployment.
Will the software allow me to use my existing Windows based applications?
Rather than offering a truly optimized TCP/IP gateway solution some vendors offer what is called UDP/IP middleware. Be careful. It is just not viable to run today’s web-enabled, off-the-shelf software like MS Explorer and Outlook in the field using a UDP/IP transport protocol. When UDP/IP middleware is implemented, applications must be modified to do their own error checking and data recovery. Often, a costly Application Program Interface (API) is required for each off-the-shelf software procuct. With a TCP/IP gateway solution, users have the flexibility to run many TCP/IP applications straight out-of the box.
Is the wireless IP solution truly optimized to maximize the application performance?
While UDP middleware does offer data compression, the data is compressed on a packet-by-packet basis but the total number of packets transmitted is not reduced. Packet-by-packet based compression typically compresses data at about 50%, while TCP/IP gateway software compresses data on a socket basis. Data is compressed going into the socket, sending fewer packets and using each more efficiently. Compression rates may vary from vendor to vendor so make sure you check the specs. Some TCP/IP gateway software solutions are able to reduce packet header size to as small as 7 bytes, so it’s worth checking into to make sure you’re getting the best bang for your compression buck.
Can the wireless IP solution roam to dissimilar networks using TCP/IP?
It is rare for one radio network to provide complete coverage of your service area. What you are looking for is a vendor who can offer a TCP/IP gateway solution that automatically and transparently switches to the best network available, based on availability, priority, time of day and cost, to deliver TCP/IP data seamlessly across a number of discrete wireless systems.
Does the wireless IP solution offer data/network security?
The Data Encryption Standard (DES) was developed by an IBM team in the mid seventies and adopted as a national standard a few years later. At the time DES was a major breakthrough in data network security, however, it proved not to be foolproof. The answer was triple DES. Early DES was based on a key length of 56 bits, triple DES simply extends the key length to 128 or 168 to achieve a much higher degree of reliability. The extended key length proved to be very secure and today triple DES has become the de facto standard for data encryption. You should check to see if the TCP/IP gateway solution uses an encryption standard which meets or exceed federal and state requirements.
Mobile Data Computing – Today and Tomorrow
Mobile Data is here to stay and there is no question that its potential is great. But without the proper implementation plan or reasonable expectations the results can be disappointing at best and disastrous at worst.
In one form or another the enabling technologies to deliver real-time data to field personnel are available today, but these technologies are still evolving as are the mobile networks themselves. The best approach is to ask questions. Your wireless provider can be very helpful when it comes to suggesting a development plan. But don’t rely on their advice alone. Look at what other utilities are doing, talk to your peers; conferences and trade magazines like this one can also be a good source of information.
Building a profitable and efficient mobile data network will require careful planning, coordination, and the integration of business processes and technologies. The key is to get educated, work within your resources and start small to meet short-term objectives, while ensuring that you’ve planned a longer-term migration path.
About the Author
Mike Bourre is Vice President of Sales & Marketing with Radio IP Software Inc, based in Montreal, QC. He can be reached at 514.890.6070.
