
|
|
|
Page 1 of 3 Making "dead time" on trains productive
The problem that people face when trying to work on trains and in areas of poor coverage is that existing access technologies, simply put, were not developed from the ground up to cope with the physics of wireless Underpinning most network traffic is a protocol called TCP/IP, and there are many behaviours of TCP/IP that make it less than optimal in a wireless environment. To address these, NetMotion Mobility XE is designed to provide optimum performance over intermittent and bandwidth-challenged network links. [Please click on the panel of the right to download the Technical Overview White Paper if you would like to see these technologies in the fuller context of secure mobile working.] NetMotion Mobility XE's architecture includes enhancements that allow network traffic over IP to more effectively deal with loss of connectivity from a mobile device, whether due to coverage outages or external factors, such as power management or user intervention. It also makes the most efficient use of the given bandwidth using many advanced features that reduce the "chattiness" of transport protocols:
Let's have a closer look at how, working in concert with each other, these advanced features provide for the most efficient movement of data. In addition, how Mobility XE automatically switches to the fastest bandwidth network connection when multiple connections are active, seamlessly and without interrupting the end user. Below are descriptions of how these features help in a wireless environment, especially a wide-area cellular environment.
Selective Acknowledgment Algorithm When transmitting data over a wide-area wireless connection, packet loss can have a severe impact on performance. When either side is transmitting a train of packets, it is quite possible for some of the frames to "evaporate" and never reach their ultimate destination. Mobility XE takes packet loss into account when sending and receiving data. Using sequence numbers, Mobility can detect whether a frame has been received out of order. If it receives a frame carrying a sequence number greater than the one it is expecting, it alerts the transmitting peer that it did not receive one or more of the frames in the sequence. The transmitting peer then retransmits the missing frame(s). In contrast, implementations without selective acknowledgment not only retransmit the missing frames, but may also re-send the frames that were correctly received by the peer. These gratuitous retransmissions waste bandwidth and processing resources.
Message Coalescing, Data and Acknowledgment Bundling Most standard network protocol implementations use acknowledgment frames as feedback to the sender that the peer has successfully received the sent packet(s). The feedback is continuous: every other frame (at most) is acknowledged, generating a stream of small control frames in the reverse direction. These extra frames, though small, can add up to significant overhead. Mobility XE can reduce the reverse flow of information from every other frame to one in four or greater. It does this by using its selective acknowledgment policy, and adjusting its metrics for determining network latency. This allows more application-level data to be transmitted instead of using the bandwidth for additional control information. To further reduce bandwidth consumption, Mobility XE uses a message bundling (or multiplexing) technique. With this algorithm, both control and application data from multiple distinct message streams are passed in the same frame. Without this feature, information is encapsulated in its own frame when an application transmits data. As more connections are established, more protocol overhead is required. By bundling these streams together, Mobility XE allows more application data to be transferred in the same amount of space, making significantly better use of bandwidth. Another benefit of this technique is that it allows each frame to carry the maximum amount of payload. In this example, two applications send and receive data in a non-enhanced implementation as follows: Application A sends 100 bytes of data to its peer, and Application B sends 150 bytes to its peer. Here is what this looks like on an IPSec VPN (SSL VPNs have similar challenges):
This normally generates two separate frames, one with 100 bytes of data (plus protocol overhead), and one with 150 bytes (plus protocol overhead). Each frame then requires a separate acknowledgment from the peer stating that it was received, so a total of four frames are required to move the 250 bytes of data over the wireless link. Here's what happens with Mobility XE using the same example: The data from application A (100 bytes) and application B (150 bytes) traverse the link in one 250-byte packet (plus protocol overhead). Only one acknowledgment is generated, so only two frames are required to move the same 250 bytes of data. Mobility XE becomes even more efficient as more applications transmit data.
|
NetMotion Mobility XE™ awarded Best-in-class Mobile VPN.