The Difference between wired
and wireless Networks
Wireless
networks differ from wired
networks in several ways.
This means that applications
and protocols that are fully
functional in wired networks
do not work as efficiently
in wireless networks if they
work at all. As a
consequence applications
developed and tested in
wired networks may fail
their rollout to wireless
networks.
Further,
Applications and protocols
are often developed on
standard workstations and
servers over local area
networks. The problem with
this approach is that
wireless networks behave
completely different than,
for example, the Ethernet.
The notion that protocols
behave in the same way in,
say GPRS and the Ethernet,
is not correct. Such basic
protocols as TCP
(Transmission Control
Protocol) of the TCP/IP
frame have severe problems
in GSM-, GPRS-, VSAT-, DVB-RCS
Networks not to mention more
complicated systems such as
those involving streaming
media.
Well known
Issues in wireless Wide Area
Networks (wWAN)
This affects
all wireless Standards like
GSM, GPRS, UMTS, VSAT,
DVB-RCS, 3G Networks etc...
Regulations and Spectrum Frequencies
have to be coordinated and
unfortunately, only a very
limited amount of
Frequencies are vavailable
(due to the technical and
political Reasons). One
Research Topic involves
determining how to use
available Frequencies more
efficiently, e. g. by new
modulation Schemes or
demand-driven Mulitplexing.
Further Improvements are new
air Interfaces, Power aware
ad-hoc Networks, Smart
Antennas, and Software
defined Radios.
The Latter allow for
Software defined Radios.
The Latter ones allow
Software
Software definable
Air Interfaces but require
high Computing Power.
Shared Medium
Radio Access is always
realized via a shared
Medium. As it is impossible
to have a separate wire
between a Sender and each
Reciever, different
Competitors have to fight
for the Medium. Although
different Medium Access
Schemes have been developed,
many Questions are still
unanswered, for Example : how
to provide a high
Quality of Service
efficiently with different
Combinations of Access,
Coding, and Multiplexing
Schemes.
Ad-hoc
Networking Wireless and
Mobile Computing allows for
spontaneous Networking with
prior Set-up of an
Infrastructure. However,
this raises many new
Questions for Research:
Routing on the Network and
Application Layer, Service
Discovery, Network
Scalability, Reliability,
and Stability etc. etc.
Interference
Radio
Transmission cannot be
protected against
Interference using Shielding
as this is done in Coaxial
Cable or shielded twisted
Pairs. For Example,
electrical Engines and
Lightning cause severe
Interference and result in
higher Loss Rates for
transmitted Data or higher
bit Errors Rates
respectively.
Varying
Capacity
The
assumptions made in the
context of wired networks
differ from those in
wireless networks. For
example, in wired networks
it is valid to assume that
packet losses are caused of
a congested network, so the
problem can be solved with a
congestion control
algorithm, which reduces the
speed of the connection.
In wireless networks,
however, capacity loss is a
much more frequently
encountered problem. The air
interface connection can be
lost, for example, when a
mobile phone moves to a
position where radio waves
cannot be transmitted to or
where waves reflected from
several objects cancel out
each other. Example : When a
person with mobile is going
though a tunnel.
Also
the network itself can cause
problems such as GPRS cell
updates, which occur when a
mobile phone moves from an
area handled by one base
station to that of another.
The result is a loss of
capacity, which can last
from a few microseconds to
several seconds.
Most
protocols used over this
type of link use congestion
control methods with some
type of congestion avoidance
algorithm, which incorrectly
sees the network as
congested and reduces the
transmitting speed.
Consequently when the
network is good again, the
connection is not running at
full capacity. Thus in
reality GPRS, for example,
fails to deliver the 20
kbits/sec or whatever the
capacity might be but rather
less.
Latency is
the time a message takes to
travel through a system, for
example from a content
server to a mobile phone.
Jitter is the variation of
latency.
Network
bandwidth and network
latency are separate terms.
Networks with high bandwidth
do not guarantee low
latency. For example, a
network path traversing a
satellite link often has
high latency, even though
throughput is very high. It
is not uncommon for a
network round trip
traversing a satellite link
to have five or more seconds
of latency. The implication
of such a delay is this: an
application designed to send
a request, wait for a reply,
send another request, wait
for another reply, and so
on, will wait at least five
seconds for each packet
exchange, regardless of how
fast the server is. Despite
the increasing speed of
computers, satellite
transmissions and network
media are based on the speed
of light, which generally
stays constant.
In wired
networks, like DSL
connections, latency delays
are usually small and jitter
nonexistent. Thus, any
changes in speed, delay or
latency can safely be
assumed to be due to
congestion or some other
problem, and protocols
usually act defensively,
lowering transmission speed
to avoid congestion.
In wireless
networks, however, long
delays and variations in
latency are default
behaviour. In mobile
packet-switched networks,
for example in GPRS, the
latency varies a lot and can
be up to several seconds.
Protocols written for wired
connections interpret the
situation often incorrectly.
Further,
wirless Links can be very
asymmetrical (i.e., the
Links offer different
Service Quality depending on
the Direction to and from
the wireless Device).
Applications
must be tolerant and use
robust Protocols.
One of the main Goal of
SEN200 is to use the
wireless Network
efficiently. It works with
the assumption that the
Latency
and
Capacity and Quality of
Service may go up as well as
down at any moment.
The
Shortcut for Latency Time is
called RTT (Round
Trip Time) and is measured
in ms.
The
Graphic above shows an
Ad-hoc Measurement in a GSM
Network by Pinging our
Server in New York from
Germany.
Latency in
geostationary Satellite
Networks
Most
communications satellites
are located in the
Geostationary Orbit ( an altitude of approximately
35,786 km above the
equator. At this height the
satellites go around the
earth in a west to east
direction at the same
angular speed at the earth's
rotation, so they appear to
be almost fixed in the sky
to an observer on the
ground.
The time
for one satellite orbit and
the time for the earth to
rotate is 1 sidereal day or
23 h 56 m 4 seconds. Radio
waves go at the speed of
light which is 300,000 km
per second.
If you
are located on the equator
and are communicating with a
satellite directly overhead
then the total distance (up
and down again) is nearly
72,000 km so the time delay
is 240 ms. ms means
millisecond or 1 thousandth
of a second so 240 ms
is just under a quarter of a
second.
A
satellite is visible from a
little less than one third
of the earth's surface and
if you are located at the
edge of this area the
satellite appears to be just
above the horizon. The distance to the
satellite is greater and for
earth stations at the
extreme edge of the coverage
area, the distance to the
satellite is approx 41756
km. If you were to
communicate with another
similarly located site, the
total distance is nearly
84,000 km so the end to end
delay is almost 280 ms,
which is a little over
quarter of a second.
Extra
delays occur due to the
length of cable extensions
at either end, and very much
so if a signals is routed by
more than one satellite hop.
Significant delay can also
be added in routers,
switches and signal
processing points along the
route..
Wired
networks rarely corrupt data
packets. In wireless
networks, however,
corruption is a common
occurrence depending on
communication meters. For
example, in GPRS, the
Quality of Service (QoS)
profile defines whether the
radio communication part
itself resends corrupted
data.
Why is
this important? Simply
because better QoS
parameters may not be
available for all users, or
users may not set them and
even if they do, their rates
are higher. It is true that
transport layer protocols
like TCP and UDP (User
Datagram Protocol) do check,
whether data is corrupted or
not. But since they cannot
fetch only the corrupted
parts, they throw away
entire datagram’s. This
means that even if a small
part of large packet is
corrupted, the whole packet
is dropped. As a result,
even uncorrupted data is
resent. If the air interface
condition deteriorates
further the protocol stack
will drop even the data that
gets through the air
interface properly.
Temporary Interruptions
In wired networks, complete
loss of service is rare and
users can be expected to
restart whatever they were
doing. This might involve
reloading the web page they
were receiving or re-logging
into a service.
Wireless networks, on the
other hand, are afflicted
with frequent service
interruptions. What is
worse is, that even if the system
automatically re-connects to
the network, each time it
does so it may utilize a
different IP address (which
is typical for GPRS
connections, for instance).
Subsequently, users are
often required to restart
their applications or
re-login to the service.
Unpredictability
The main problem with
wireless networks is that
you cannot foresee what the
network is going to do. To
give an example, if you test
a GPRS application in a real
network in the office, you
can only be assured that the
application works in that
network in that office. When
you move out of that situation many
thinks may
change dramatically.
If the user of some mobile
application or game is
moving in cellular networks,
like GPRS or WLAN, the
networks occasionally change
cells. Each cell change is
accompanied by a temporary
loss of service. In
addition, moving causes
delays and capacity changes.
While running the
application, these
situations can be tested by
walking or driving around.
Unfortunately the results do
not have wider
applicability, since this is
a non-repeatable process.
Moreover, events that can be
foreseen but are difficult
to force, like GPRS routing
area updates, are almost
impossible to test in real
networks and often require
special procedures with the
network. As a result these
events cannot be fully
tested in live networks.
Small Chunk Data Packages
Many
Computer Application or TCP
Implementations don’t care
about a fully used Ethernet
Dataframe and fire continous
small Data Packages which
makes a wireless Network
inefficient and expensive.
The reason for that is that
Application Developer don’t
care about whats going on on
the Network Layers because
they are fully concentrated
on there Application and
Issues in there field of
vision. Please remember in a
wireless Network each Data
Packages must be converted
by Software and Hardware to
electromagnetic Signals and
vice versa. This process is
always nearly equal
regardless of the Length of
the Data Frame. The sending
and receiving Hardware of
this electromagnetc Signals
are comparable with an
Airport. Each incoming
Dataframe must be scheduled
and managed bye Software and
Hardware. Please remember
wheather there is landing a
Jumbo Jet or a small Jessna,
the effort for the air
traffic controllers are the
same. To reach a very good
Utilization for a wireless
Network, we should take for
granted that only Jumbo Jets
are starting and landing and
that means that the
Dataframes are fully used to
their Maximum Size. This
Size in Bytes is called
MTU (Maximum
Transmission Unit). In an
Ethernet Network the Value
is 1518 Bytes
As you can see in the right
Chart over 80 % of
all Data Packages of a
captured Session are less
than 127 Bytes. The MTU is
>=1518 Bytes but only 1,83 %
of all Data Packages uses
this size.
Another View of the not
fully used MTU Size of the
Ethernet Dataframes. Please
note that this can vary from
Application to Application.
When programs are developed
for higher level
environments like RPC, COM,
and even Windows Sockets,
developers tend to forget
how much work takes place
behind the scenes for each
sent or received packet.
When a packet arrives from
the network, an interrupt
from the network card is
serviced by the computer.
Then a Deferred Procedure
Call (DPC) is queued, and
must make its way through
the drivers. If any form of
security is used, the packet
may have to be decrypted, or
the cryptographic hash
verified. A number of
validity checks must also be
performed at each state.
Only then does the packet
arrive at the final
destination: the server
code. Sending many small
chunks of data results in
packet processing overhead
for each small chunk of
data. Sending one big chunk
of data tends to consume
significantly less CPU time
throughout the system, even
though the cost of execution
for many small chunks
compared to one large chunk
may be the same for the
server application.
TCP Overhead and higher
Delay because of TCP ACK
Packages
The TCP Standard Mechanism
produces additional Delays
in a high Latency wireless
Network because all Packages
must be acknowledged by an
own TCP ACK Package through
the Destination or Receiving
side.
If the Source Side is allowed
to send X Bytes (called
Window Size) then it must
wait until this Sequence is
acknowledged through a
Sequence No. which is a
Pointer on the Byte Stream.
So lets perform a simple
Calculation:
RTT = 1 sec
Bandwidth = 64 KByte/sec
Window Size = 16 Kbyte
Time to send the Window =
Window Size / Bandwidth = 0,25 sec
Then in
0.75
sec
nothing happens, because
the Source
has to wait until at least
till this Window is acknowledged.
In practice this Windows
Size is adapted through
various TCP Implementations
dynamically upon several
Connection Parameters and
therefore the impacts can be
reduced considerably in a
fixed Network. But these TCP
Implementations fail in a
wireless Network because of
this heavily fluctuating
Round Trip Times and
changing Bandwidth.
Furthermore there is a
Traffic Overhead because of
this permanently fired small
TCP-ACK Packages.
TCP Efficiency in Mobile-
and Satellite IP-Networks
The basic
Assumptions while designing
TCP has been completely
different from the Reality
of using wireless Hosts like
Mobile and Satellite. The
Mechanisms of TCP that make
the Protocol
network-friendly and keep
the Internet together cause
severe Efficiency Problems.
TCP
assumes a Network Congestion
if Acknowledgements do not
arrive in time. However,
wireless Links have much
higher Error Rates compared
to wired Links. Example: a
twisted pair or Fiber
Optics, that way causing
higher Packet Loss Rates.
The Link Layer may try to
correct many of those Errors
which can hide Link Layer
Characteristics. This quite often leads to
unwanted high Delays
and Jitter. Link Layer Error
Correction should therefore
be used for Application
dependency.Mobility itself,
i.e., the Handover between
different Access Points, can
cause Packet Loss without
any Congestion in the
Network. In either Case, TCP
goes into a slow Start State
reducing its Sending Rate
drastically.
There
are several classic
solutions which were
tried to increase the Efficiency
of TCP in Mobile and
wireless Environments.
Besides the Failure of
Performance Enhancing
Proxies in an IP Security
enhanced
Network, additional Issues
are still open. RFC 3150
End-to-End Performance
Implications of Slow Links
gives Recommendations for
Networks,
where Hosts can saturate the
available Bandwidth. It is
recommended here, among
others, that Header
Compression following RFC
1144 or RFC 2507 should be
used. It is also suggested
that the Timestamp Option is
turned off. These
Recommendations contrast
with the 2.5G/3G Recommendations
are considered slow in the
Sense of RFC 3150. RFC 3150
sees smaller MTU Sizes as
useful for Slow Links with
looseCharacteristics.
An
unchanged TCP faces even
more Problems when used over
Satellite Links or in
general Links to a
Spacecraft (ranging from LEO
to Interplanetary deepspace
Probes). The main Problems
are the extremely high RTT,
Error-Phone Links, limited
Link Capacity, intermittent
Connectivity, and asymmetric
Channels.
Abstract of known Issues
in wireless Wide Area
Networks
Regulations and Spectrum
Shared Medium
Ad-hoc Networking
Interference
Varying Capacity
Latency and Jitter
Latency in geostationary
Satellite Networks
Data Corruption
Temporary Interruptions
Unpredictability
Small Chunk Data
Packages
Packet Processing
Implications
TCP Overhead and higher
Delay because of TCP ACK
Packages
TCP Efficiency in
Mobile- and Satellite
IP-Networks
