2. 2.5G and 3G Link Characteristics

"Gurtov Andrei " <andrei.gurtov@sonera.com> Wed, 21 November 2001 07:05 UTC

Delivery-Date: Mon Jan 28 09:04:15 2002
Delivery-Date: Wed Nov 21 02:11:04 2001
Delivery-Date: Wed, 21 Nov 2001 02:11:04 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Subject: 2. 2.5G and 3G Link Characteristics
Date: Wed, 21 Nov 2001 09:05:02 +0200
Message-Id: <C6A53DA7BC39804F8599A725360914087157E5@ASSI.eur.soneragroup.net>
Thread-Topic: 2. 2.5G and 3G Link Characteristics
Thread-Index: AcFyWrGoBjjfUtzWEdWORgAAOWOFFw==
From: Gurtov Andrei <andrei.gurtov@sonera.com>
To: pilc@grc.nasa.gov
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id CAA06984
Sender: owner-pilc@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 5962
Lines: 132

Hi,

 Please find below a suggested version for Section 2 of 2.5g3g draft.

-Andrei

2. 2.5G and 3G Link Characteristics

2.1 Data rates

The main incentive for transition from 2G to 2.5G to 3G is the increased
data rates for the users. 2.5G systems have data rates of 10-20 kbps in
uplink and 10-40 kbps in downlink. 3G systems are expected to have bit
rates around 64 kbps in uplink and 384 kbps in downlink. Considering the
resulting bandwidth-delay product of around 1-5KB for 2.5G and 8-50 KB
for 3G, 2.5G links belong to LTNs, and 3G approach LFNs. For good TCP
performance both LFNs and LTNs require maintaining a large enough
window. For LFNs it is needed to utilize the available network
bandwidth. LTNs need a larger window than required for 'filling the
pipe' to avoid retransmission timeouts in presence of packet losses. 

This document recommends only standard-level mechanism suitable both for
LTNs and LFNs, and to any network in general. However, suggested
experimental mechanisms can be targeted either for LFN [1] or LTN [n1]. 

The data rates are dynamic due to other users and mobility. Arriving and
departing users can reduce or increase the available bandwidth a cell.
Traveling to a longer distance from the base station decreases the link
bandwidth due to worse link quality. Finally, the user can move to a
cell with less or more of available bandwidth. When a connection changes
from a slow to fast cell, it can underutilize the available bandwidth,
since in congestion avoidance phase TCP increases the sending rate
slowly. Changing from a fast to slow cell is handled well by TCP due to
self-clocking mechanism. However, a large TCP window used in a faster
cell can create the overbuffering problem in the slower cell.

2.2 Asymmetry

2.5G/3G systems have built in asymmetry in uplink and downlink data
rates. The uplink data rate is limited by the battery power consumption
and complexity limitations of mobile terminals. However, the asymmetry
does not exceed 3-6 times, and can be tolerated by TCP without need for
congestion control or filtering for ACKs [n2]. 

2.3 Latency

The latency of 2.5G/3G links is very high due to FEC and processing
delays. A typical RTT varies between half a second to one second. The
high latency of 2.5G/3G links is not of fundamental nature, like in
satellite links due to finite light speed, but it is unlikely to be
radically lowered. However, it can be reduced by clever design and
engineering of the system. 

The static latency of 2.5G/3G links can be further increased by the
radio resource allocation delay. For example, the user is allocated a
timeslot in GPRS and a scrambling code in UMTS. GPRS releases timeslots
shortly after a transmission; UMTS users can keep the codes longer, but
the allocation also takes longer time. The resource allocation delay has
an effect of increasing the RTT on the partly utilized link. Until the
interval between packet arrivals to the link is less than the resource
release timer, the resource allocation is triggered on every RTT.
Keeping the radio resource for the time equal to link RTT could avoid
this problem.

2.4 Delay spikes

2.5G/3G links are likely to experience delay spikes exceeding the
typical RTT by several times due to following reasons.

(1) A long delay spike can be a result of link layer recovery from a
link outage due to temporal loss of radio coverage for example while
driving into a tunnel or stepping into an elevator.

(2) During a handover the mobile terminal may have to perform some
time-consuming actions before data can be transmitted in a new cell.
Many W-WANs in such a case try to provide seamless mobility that is
internally re-route packets from the old to the new base station at the
expense of additional delay.

(3) Blocking by high-priority traffic may occur when an arriving
circuit-switch call or higher priority data user temporally preempts the
radio channel.

Delay spikes can cause spurious TCP timeouts and unnecessary
retransmissions.

2.5 Error losses

In general, 2.5G/3G systems have low rate of error losses thanks to
link-level retransmissions. Justification for link layer ARQ is
discussed in [9], [11]. In general, the link layer ARQ and FEC can
provide a packet service with a negligibly small probability of
undetected error (failure of the link CRC), and a low level of loss
(non-delivery) for the upper layer traffic, i.e. IP. The loss rate of IP
packets is low due to the ARQ, but the recovery in layer two appears as
jitter to the higher layers.

2.6 Intersystem handovers

It is likely that 3G systems will be used as a 'hot spot' technology
while 2.5G systems will provide lower speed data service on the rest of
territory. This brings the environment where a mobile user can roam
between 2.5G and 3G networks while keeping ongoing TCP connections. The
inter-system handover is likely to trigger a high delay spike (Section
2.4) and can lead to large amount of data losses. Additional problems
include context transfer, which is out of scope of this document but is
addressed by the Seamoby WG [n3].

Intersystem handovers can cause performance problems for ongoing TCP
connections as many features (e.g. window scaling) are negotiated at the
connection establishment and cannot be changed later. This is especially
a valid concern if some mechanism specific for LTN or LFN is implemented
by TCP. 

References

[n1] M. Allman (ed), S. Dawkins, D. Glover, J. Griner, D. Tran, T.
Henderson, J. Heidemann, J. Touch, H. Kruse, S. Ostermann, K. Scott, J.
Semke, "Ongoing TCP Researh Related to Satellites", RFC 2760, Feb. 2000.

[n2] H. Balakrishnan, V. Padmanabhan, TCP Performance Implications of
Network Asymmetry, draft-ietf-pilc-asym-07.txt, September 2001. Work in
progress.

[n3] J. Kempf, Problem Description: Reasons For Performing Context
Transfers Between Nodes in an IP Access Network,
draft-ietf-seamoby-context-transfer-problem-stat-03.txt, October 2001.
Work in progress.