Cellular and 802.11 Networks – Application and Data Usage
Wireless connectivity has become a necessity for application usage and productivity workflows. Network connectivity changes as users move from indoors to outdoors or carry their devices with them in the car or travel, this is a challenge when trying to access applications or get access to remote data from the cloud or the network. Traditionally it has been expected that access to enterprise applications will be managed on higher speed 802.11 networks and lightweight applications are going to be presented over cellular networks.
The deployment of higher speed cellular networks in most metro areas also is blurring the expectation between what is possible and manageable on cellular networks compared to 802.11. Because integration of cellular and 802.11 networking into almost all mobile devices it is difficult to differentiate between the two technologies at an end user level.
To the end user the fact that they have connectivity means that the network should work as expected everywhere all the time. After all, this is what every other commercial on television shows, blindingly fast speeds and always on and available networks.
Because of mobile application usage, which is in turn tied to device usage which is tied to network usage the end users very often will equate network expectations with the device being used. If you have a phone or PDA type device it then it is not uncommon that the usage will be limited to highly mobile applets and will be tuned to this type of network use.
However, if I have a tablet or laptop then the expectation of network availability and usage rises as the capability of the devices grows, this “expectation index” is often the primary reason for frustration and lack of satisfaction with the device. An example of this is shown in the chart below, as can be seen as the size and richness of applications on the device goes up as the device becomes bigger until the expectation of functionality and use is one of wired connectivity.
This usage expectation is creating a significant amount of issues with both application vendors and device vendors as they try to manage the end user workflows across some very diverse geographical and structural ecosystems such as driving in vehicles and moving around in buildings.
The workflows that are most challenging are those where the connectivity from either Wi-Fi or cellular technology cannot be assessed for use in a meaningful way by the end user. The primary issues are:
Connectivity drops when roaming between networks
Issues surrounding VPN for access to enterprise assets
Throughput and application usage for specific assets
Roaming vs. Session Persistence on the same network
Application behavior using cellular when compared to 802.11
Furthermore, complex Mobile devices are also becoming a meaningful part of many mission critical workflows sometimes being used to coordinate emergency response or used for access and storage or very sensitive information. These would include applications used by first responders like fire, medical and police as well as highly mobile workers such as maintenance, operations and home healthcare workers. In all of these cases the use of bigger and more feature rich applications are being used in hybrid cellular and 802.11 workflows. This creates the need for a different approach to the way devices and applications are being used and the expectations of usage by the end users.
There are three distinct areas of opportunity that can be leveraged in order to mitigate a large amount of the issues. These areas of opportunity are:
Network and packet connectivity
Inter network roaming
Application performance assurance
In order to tackle these disparate connectivity modalities it is necessary to fully understand each workflow and propose solutions to each of them in a discrete fashion.
The first thing to assess is will connectivity be required while moving or can the application be used during moments of relative proximity to a fixed signal source?
An example of this would be home health or perhaps device maintenance such as air conditioner repair. In these examples the end user would be perhaps be using a large amount of data such as a patient records or large schematic drawings but would only be used in specific relatively stationary areas.
Secondly, will the application be used in a highly mobile environment where application continuity would be difficult to assure at all times? An example of this would be traveling at high speeds to the scene of an accident or a fire.
Lastly would the application need to be available while moving around in buildings that have construction that is hard for wireless to penetrate such as basements or stairways in high rise buildings.
In addition to this is the application, a traditional three tier application where parts are installed as a thick client on the device and the database is hosted on a remote server or is the entire application hosted in the cloud and only accessible by having network access.
Furthermore is it anticipated that the application requires a lot of bandwidth in order to function properly.
Is there a “thinner” version of the application that can be used when connectivity or bandwidth may be limited? Is it anticipated that the end user will be able to use parts of the application or do they need access to all of the features all of the time?
What affects network usability?
The two pictures below illustrate the issues surrounding connectivity inside buildings.
The picture on the left shows the construction of a medical building, the cement structures visible are the elevator and stairway walls.
The picture on the right shows the finished building. The average end user would not know about the construction of these buildings and therefore would be surprised that their cellular connection can be dramatically affected by this.
Everyone knows that a cell phone connection is not going to work well in an elevator but not very many people know that the stairwells are of equal issue to the cellular connection. This can create a gap between the expected coverage and the actual coverage that is quite pronounced.
The scenario goes something like this:
What the End User thinks happened
1. I am connected to an application but want to go down a floor.
2. I decide to go down the stairwell instead of the elevator because I don’t want to lose connectivity and elevators are terrible for this.
3. I get down stairs and the application has locked up
4. I know it can’t be the connection because the wireless connection icon I show that I am connected still
5. It must be the device or the application is faulty, but which one?
6. The application vendor says: “it’s the device, the application is fine”.
What has actually happened?
1. I am connected to an application but want to go down a floor.
2. I decide to go down the stairwell instead of the elevator because I don’t want to lose connectivity and elevators are terrible for this.
3. As I step into the stairwell my cellular connection is unstable I lose connectivity to the application. (See table below).
Application connection error Connection Manager showing connectivity
What happened under the hood?
If you use a protocol analyzer to look at the traffic you can see that the packet timing between both of the red lines shows an extended period of time between received packets. However all the analyzer is recording data and higher level IP management packets.
If you look at the actual connection you can see that the reason for the application disconnects is an extended period of time in which the application database cannot stay synchronized with the client and times out.
The picture below illustrates the fact that the packets are taking up to 3.7 seconds each to travel one way, this means a 7 second delay for packet acknowledgement. If you have enough of these in a row, the TCP session will time out or the application will drop. This is what actually happened while still technically connected; the application was not able to remain usable because the connection was not stable enough.
The blue area shows the connection times becoming more and more extended.
The orange areas show the connection becoming unable to support a TCP connection.
These extended packet trip times are the effect of several factors:
Signal level and quality of signal
Interference from other RF devices in same frequency space
Signal loss and fade due to physical interference
Signal quality due to distance from cell tower and
In order to illustrate this we will use the following example of what can happen. The building below is a generator plant used for emergency power next to a high rise building. As can be seen the building has block walls and a lot of metal and other cellular signal inhibitors inside.
The picture below shows the amount of frequency noise and interference both outside the building, (picture on left) and inside the building (picture on right)
This picture shows a pretty clean wireless connection with occasional interference.
(the green dot in center of picture)
This picture shows a high level of interference and low signal level
Cellular latency at the packet level
The first two pictures below compare packet latency of an 802.11 wireless connection to a device inside a typical network.
As you can see the packet trip time on the right is normal for this type of network, around 2 to 4 milliseconds.
However the cellular connection pinging the exact same network device is around 300 to 400 milliseconds.
This creates a tremendous amount of network latency that needs to be accounted for both in the application and in the end users expectation of device usage.
This is typical cellular latency due to low signal that could be due to interference or distance from the cellular tower.
The first picture shows latency that is pretty typical for a decent network connection on a cellular connection
The second picture shows cellular latency from a weakened signal as a user moves into a building that causes the signl level to drop
This last picture shows an unusable cellular signal that is due to very low signal quality because of building materials and interference
Web based vs. thick client application connections from 802.11 or cellular
Typical Three tier application
The back end-database and application server provide content and data to the application with the client on the device managing the presentation layer of the application.
Typically this type of application interface has been used for rich content in a client / server type of architecture. This type of application interface has both advantages and disadvantages.
The application and sometimes the database and other information can be loaded locally and then used offline, however the way the applications are written often require a lot of synchronized data passing from the front end application back to the application server and the database.
Typical web / Cloud based presentation architecture
The picture below shows a typical web based application architecture. The application is hosted on the web server and there is almost no client installation necessary. Often the only thing that needs to happen is installation of a browser plug-in. Once this is done the client web browser interacts with the web server for screen refreshes of information. All data is stored on the app server and database. The major issue with this type of architecture is that it requires a permanent connection to the web server in order to use the application.
Typical VPN architecture for 3-tier application usage
In this scenario a tunnel is created between the VPN device and the front end Client device this creates secure access to the application and database while making sure that the client is properly authenticated to the network.
You would not typically use VPN for cloud based networks as the connection can be encrypted using SSL in the browser however, it is an essential part of corporate network access strategies for mobile users.
Typical Mobile IP / Session Persistence usage
In this scenario the IP session is managed by either mobile IP management or by a proxy session manager that fools the application into believing that it is the end use client. Both of these scenarios create a relatively stable IP connection that is tolerant of a reasonable level of loss of connectivity.
Trouble shooting and understanding causes of application issues
Obviously there are many layers that can affect the performance of applications and device performance, especially when using 802.11 and cellular networks. In these types of architectures there is often a cumulative layer of problems that cause a greater problem. Because of this it is important to try to separate the issues and break them down into smaller groups in order to find out what the significant issues are.
Generally the approach that is the most pragmatic is to understand what works and what doesn’t.
An example of this would be the following, a network engineer has been asked to add an application to a device and test it to make sure that it is working properly. During this testing he notices that the application constantly disconnects from the server. In order to understand what is causing this it is important to check all aspects of the application pathway and see where the issue is manifesting itself.
The best tool to test all of this is a simple ping test. A few simple tests and the issue should be pretty easy to isolate.
1. If the device is plugged into a wired Ethernet connection how does it perform?
a. How does the application perform on this device compared to a baseline device using a wired connection?
b. Has all of the device functionality been tested including a typical mobile workflow? This is important because of the issues that can arise with different areas of the application and how they are being used in different networks.
c. Ping the local gateway, ping a known address on the internet, like Yahoo.com. Ping the application server and record the results from all of these for comparison.
2. If the device is used on an 802.11 network how does it perform? What are the differences compared to the wired connection?
a. Has all of the device functionality been tested including a typical mobile workflow? This is important because of the issues that can arise with different areas of the application and how they are being used in different networks.
b. Ping the local gateway, ping a known address on the internet, like Yahoo.com. Ping the application server and record the results from all of these for comparison.
3. Lastly after performing the other two tests, if the device is used over a cellular connection how does it perform? What are the differences?
a. Has all of the device functionality been tested including a typical mobile workflow? This is important because of the issues that can arise with different areas of the application and how they are being used in different networks.
b. Ping the local gateway, ping a known address on the internet, like Yahoo.com. Ping the application server and record the result from all of these for comparison.
It is highly unlikely that these results will be the same and more than likely will provide good information that can be used in the rest of the troubleshooting areas.
Typical areas of concern and recommended causes and remediation
1. Issue - Sluggishness in certain areas of the application that only occur on the cellular network. Typically this is caused by an application design that is not developed for use over cellular networks. The types of issues that can occur are time outs or freezing in certain areas.
Recommendation – Work with application vendor and server support team to determine if there are any timeout counters or back offs that can be extended or removed in order to allow for a slower connection. The most common of these would be the database synchronization counters or page refresh timers. It may only need some minor adjustment of these heartbeat timers in order to have the application work in an acceptable manner.
2. Issue – trying to synchronize data with database times out or takes a long time.
This issue could have many causes but typically what you are dealing with here is the attempt to pull down way too much data over a communication link that is not designed for this.
Recommendation - More often than not this can be managed by having the end users sync the databases prior to leaving the office or by using an available 802.11 network to sync the database. Then use the cellular network connection for
mission critical use only.
3. Issue – Application is basically unusable over the cellular connection because it is too sluggish or times out or crashes. This is a more systemic issue than the one above.
Recommendation - In these cases it is recommended that a virtualization layer be placed between the application server and the end client. Products from Citrix, Microsoft and VMware are the most popular and come with a lot of advantages including application session persistence because of the fact that the application connection is managed in the VM and not on the client.
4. Issue – The application has intermittent connectivity issues and when there is a disconnection all of the data entered is lost. This happens with no notice and does not give the end user time to save the data already entered.
Recommendation – Use a session persistent product like Net-Motion or Cisco
