Cellular and 802.11 Networks – Application and Data Usage

Motion Mobility Services

1 | Copyright 2012 Motion Computing

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



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


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



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




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

Any Connect. These products are designed to keep the network connection active

and make sure that interruptions in IP connectivity do not bring down the whole

TCP connection to the end user. They do this by caching and managing the

network connections using an intermediate server. This is different than

virtualization as the connection is being managed by the server and not the whole

application interface.

Documents

Cellular and 802.11 Networks – Application and Data Usage