UMTS Evolution Part II: PACKET QoS in UMTS

1
UMTS EvolutionPart II PACKET QoS in UMTS
2
Outline

• Introduction
• QoS in UMTS
• TCP and its performance within UMTS
• End-2-End QoS (IP UMTS QoS)
• Performance of different services in WCDMA
  (demonstrations)
• Summary

3
General Quality of Service

• Without any specific reference, "Quality of
  Service" generically refers to the quality of a
  requested (whatever) service, as perceived by the
  user of the service.
• Technically, "Quality of Service" refers to "the
  collective effect of service performances which
  determine the degree of satisfaction of a user of
  a service" 3GPP terminology.
• Within the Installation and Maintenance (IMN)
  business scope, the most likely provider of a
  service is a Mobile Network Operator, and the
  most likely user of that service is an end user
  (i.e. subscriber).
• Therefore, the general "Quality of Service"
  definition is further clarified through the
  following slides, from the viewpoints of Network
  and End User.

4
What is QoS?

• QoS is the collective effect of service
  performances that determine the degree of
  satisfaction of a user of a service.
• The Quality of a given service can be divided
  into several sub components, to mention some
• Availability (e.g. whether the service is
  accessible or not)
• Speed (e.g. how fast do I get the service, e.g.
  network response time, and the time taken to send
  a message),
• Performance What are the latency and throughput
  when accessing the service
• Reliability Whether the service is going to be
  maintained, within a given performance level, as
  long as it is needed once it is accessed
• Security Whether it is possible to use the
  service without security risk
• That is, Quality is seen as a combination of
  certain (although not all) performance aspects of
  a Service.

5
3GPP

• 22.105
• Quality of Service is the quality of a requested
  service (Teleservice or Bearer Service or any
  other service, e.g. customer care) as perceived
  by the customer. QoS is always meant
  end-to-end.
• 23.207
• Network Services are considered end-to-end, this
  means from a Terminal Equipment (TE) to another
  TE. An End-to-End Service may have a certain
  Quality of Service (QoS) which is provided for
  the user of a network service. It is the user
  that decides whether he is satisfied with the
  provided QoS or not.
• End User QoS Requirements
• Generally, end users care only the issues that
  are visible to them. From the end-user point of
  view only the QoS perceived by end-user matter

6
Why QoS?

• Users
• To get some kind of guarantee about the services
  they access
• Decide what quality they want based on their
  budget
• Operators/Service Providers
• Attract as many users as possible
• Do so while meeting the needs of the users
• Possibly save expenses by using resources only
  when they are necessary

7
Challenges towards QoS provision in Wireless
Networks - I

• Network related
• Bandwidth limitations
• Bandwidth fluctuations
• Transmission errors
• Interaction between different networks
• User related
• QoS is subjective
• How does the user select the needed QoS?
• Service related
• Different requirements for different services
• Widely used application level protocols such http
  are not QoS aware
• Interface to the service very significant. For
  example, a poorly designed user interface can
  make the perceived QoS to fall dramatically even
  though the other parts of the system are behaving
  as required

8
Challenges towards QoS provision in Wireless
Networks - II

• How to identify different services
• Use of flags (such as TOS in IP), or host/access
  point IP addresses?
• Problems with encrypted headers?
• How is the interaction of the different QoS
  mechanisms at different layers (e.g. traffic
  classes in UMTS diffserv in IP)
• What about heterogeneous networks (e.g. UMTS
  WLAN)?

9
Outline

• Introduction
• QoS in UMTS
• Introduction
• Packet Scheduling
• RLC
• TCP and its performance within UMTS
• End-2-End QoS (IP UMTS QoS)
• Performance of different services in WCDMA
  (demonstrations)
• Summary

10
UMTS QoS Architecture
UMTS
TE
MT
UTRAN
CN
TE
CN
Iu
Gateway
EDGE
NODE
End-to-End Service
TE/MT Local
UMTS Bearer Service
External Bearer
UMTS Bearer Service
Bearer Service
Service
Radio Access Bearer Service
CN Bearer
Service
Backbone
Iu Bearer
Radio Bearer
Bearer Service
Service
Service
UTRA
Physical
FDD/TDD
Bearer Service
Service
11
3G QoS is an end-to-end issue
- but the radio access is the most important QoS
domain -

• The radio is the capacity limiting factor
• Prioritization of different users and data flows.
• Resource allocation to most critical links
  improving perceived QoS.
• Guaranteed latency for RT multimedia services
  throughout the system.
• Radio is a hostile medium for access
• Variable transmission delay, high latency,
  error-prone and time-variant connections, and
  poor radio behavior.
• Application SW are usually designed for wireline
  connections, therefore adequate QoS mechanics
  must be provided to conceal these.

12
Service Differentiation in UMTS traffic classes

• Real Time
• Conversational
• Streaming
• Non Real Time
• Interactive
• Background

13
Conversational

• Real Time Type of Communication characterized by
  a two way conversation, where the data flow is
  relatively symmetrical.
• The Round Trip Time (RTT) is one of the key
  attributes
• Conversational traffic can tolerate small
  transmission errors
• Examples are voice calls, VoIP, video telephony

14
Streaming

• (Almost) Real Time Communication where a stream
  of live or recorded audio/video stream, usually
  characterized by a one way flow of data.
• More tolerant to delays than conversational class
• Sensitive to delay jitter (though it can be
  compensated to some extent by buffering)
• Can also tolerate small errors
• Examples are Web Broadcast, video on demand,
  Push to talk (PoC)

15
Interactive

• Non Real Time Type of Communication where an
  online UE requests data from a remote server.
• The communication is characterized by the request
  response pattern of the end user.
• The RTT is one of the key attributes of the total
  message transfer delay and the degree of
  satisfaction of the end user.
• Interactive traffic usually must be transparently
  transferred (low bit error rate).
• Examples are Web Browsing, Data Base Retrieval,
  WAP, Network Games, etc.

16
Background

• Background traffic is characterized by the fact
  that the destination is not expecting the data
  within a certain time, but infinite delays are
  not desirable!
• This scheme is the most time insensitive of the
  four traffic classes.
• Again, the message must be transparently
  transferred.
• Examples are E-mail delivery, FTP, SMS,
  E-postcards

17
Important metrics
Some typical QoS parameters for different traffic
classes
18
Typical UMTS Bearer Parameters
Highest data rate the user will experience
Deliver link layer segments in or out of sequence?
Maximum size of link layer packets (useful in
policing admission control)
Forward link layer segments even though they are
corrupt?
The error that remains even after error recovery
techniques
Fraction of link layer segments that are lost or
corrupted
Maximum delay for 95 percentile of the delay
distribution
Worst data rate that the user will experience
Relative importance for handling of link layer
segments of the UMTS bearer compared to that of
other bearers
relative importance compared to other bearers for
allocation and retention of UMTS bearer
19
Bearer Parameters

• Traffic class ('conversational', 'streaming',
  'interactive', 'background')Definition type of
  application for which the UMTS bearer service is
  optimizedPurpose By including the traffic
  class itself as an attribute, UMTS can make
  assumptions about the traffic source and optimize
  the transport for that traffic type.
• Maximum bit rate (kbps) Definition maximum
  number of bits delivered by UMTS and to UMTS at a
  SAP within a period of time, divided by the
  duration of the period.Purpose Maximum bit
  rate can be used to make code reservations in the
  downlink of the radio interface. Its purpose is
  1) to limit the delivered bit rate to
  applications or external networks with such
  limitations 2) to allow maximum wanted user bit
  rate to be defined for applications able to
  operate with different rates (e.g. non
  transparent circuit switched data)

20
Bearer Parameters (II)

• Guaranteed bit rate (kbps)Definition guaranteed
  number of bits delivered by UMTS at a SAP within
  a period of time (provided that there is data to
  deliver), divided by the duration of the period.
  Purpose Guaranteed bit rate may be used to
  facilitate admission control based on available
  resources, and for resource allocation within
  UMTS. Quality requirements expressed by e.g.
  delay and reliability attributes only apply to
  incoming traffic up to the guaranteed bit rate.
• Delivery order (y/n)Definition indicates
  whether the UMTS bearer shall provide in-sequence
  SDU delivery or not.Purpose the attribute is
  derived from the user protocol (PDP type) and
  specifies if out-of-sequence SDUs are acceptable
  or not. This information cannot be extracted from
  the traffic class. Whether out-of-sequence SDUs
  are dropped or re-ordered depends on the
  specified reliability

21
Bearer Parameters (III)

• Maximum SDU size (octets)Definition the maximum
  allowed SDU size Purpose The maximum SDU size
  is used for admission control and policing.
• SDU error ratioDefinition Indicates the
  fraction of SDUs lost or detected as erroneous.
  SDU error ratio is defined only for conforming
  traffic.Purpose Used to configure the
  protocols, algorithms and error detection
  schemes.
• Residual bit error ratioDefinition Indicates
  the undetected bit error ratio in the delivered
  SDUs. If no error detection is requested,
  Residual bit error ratio indicates the bit error
  ratio in the delivered SDUs.Purpose Used to
  configure radio interface protocols, algorithms
  and error detection coding.

22
Bearer Parameters (IV)

• Delivery of erroneous SDUs (y/n/-)Definition
  Indicates whether SDUs detected as erroneous
  shall be delivered or discarded. Purpose Used
  to decide whether error detection is needed and
  whether frames with detected errors shall be
  forwarded or not.
• Transfer delay (ms)Definition Indicates maximum
  delay for 95th percentile of the distribution of
  delay for all delivered SDUs during the lifetime
  of a bearer service.Purpose used to specify
  the delay tolerated by the application. It allows
  UTRAN to set transport formats and ARQ
  parameters.
• Allocation/Retention PriorityDefinition
  specifies the relative importance compared to
  other UMTS bearers for allocation and retention
  of the UMTS bearer. The Allocation/Retention
  Priority attribute is a subscription attribute,
  which is not negotiated from the mobile terminal.
  Purpose Priority is used for differentiating
  between bearers when performing allocation and
  retention of a bearer

23
Transfer delay of streaming class

• 23.107
• "The transfer delay requirements for streaming
  are typically in a range where at least in a part
  of this range RLC re-transmission may be used. It
  is assumed that the application's requirement on
  delay variation is expressed through the transfer
  delay attribute, which implies that there is no
  need for an explicit delay variation attribute."
• This implies
• 1. transfer delay attribute of streaming class
  STILL defines the transfer delay, exact as in
  Conversational class.
• 2. Network designer may derive the delay
  variation tolerance implicitly, from the given
  transfer delay value.
• 3. In other words, delay variation allowed in the
  network is NOT subject to any limit, so long as
  the transfer delay value is met.
• 4. In practice, the allowed delay variation must
  be less than or equal to transfer delay.

24
Example of transfer delay usage

• For example
• transfer delay required 2s at 64kbps (playout
  buffer 16Kbytes)
• packet loss rate 10
• Transfer delay of 2s can be partitioned into
• A 95 percentile queuing delay in MAC and also
  in CN
• B delay due to L2 retransmission
• -gt n max. allowed retransmissions when RTT is
  known
• A B lt 2s must hold.
• In addition, power control sets BLER to be such
  that the residual LBER after n re-transmissions
  must lead to packet error rate is less than 10
• Packet size should be set as max. allowed packet
  size

25
QoS provision in UMTS

• Radio Resource Management (RRM) plays an
  important role in QoS Provision in UMTS
• Power Control by sending not more than the
  required power cell capacity is used optimally,
  facilitating the fulfillment of user QoS
  requirements
• Hand Over Using soft handover, users ongoing
  sessions will not deteriorate during cell
  reselection
• Admission Control makes sure that the admission
  of new calls will not bring down the quality of
  ongoing calls
• Packet Scheduling takes care of the scheduling
  of packets for already admitted NRT calls
• On top of that, link and transport layer settings
  / algorithms interact in a complex way to affect
  the overall experienced quality

26
Packet Scheduler

• The packet scheduler (PS) is a general feature,
  which takes care of scheduling radio resources
  for NRT radio access bearers in both uplink and
  downlink directions.

UL Traffic volume measurements
Load measurements
Channel Allocation
27
Packet Scheduling Basics

• Packet scheduling is done both on a user or
  cell-specific level.
• Asymmetric traffic is supported by separate
  uplink and downlink capacity allocation.
• Whenever a DCH is allocated to one direction, a
  DCH also has to be allocated in the other
  direction.
• The core functionality of PS is located at the
  RNC, and the base station and the mobile provide
  measurements that affect the PS functionality.
  (Not that in HSDPA/HSUPA, the PS is located in
  the NodeB)

28
User-Specific Packet Scheduling

• User Specific PS controls RRC state transitions,
  transport channels and bit rate allocations, with
  only one user in consideration

29
Common Channels

• RACH (Random Access Channel) in the UL and FACH
  (Forward Access Channel) in the DL
• Mainly used for signaling but can also carry
  small amount of user data such as TCP connection
  establishment/termination packets
• No set up time required
• Only open loop power control
• No soft handover (hence, longer delays during
  cell reselection)

30
Data Transmission over Common Channels Example
traces from live network
Small amount of data, so common channel sufficient
Pinging www.nokia.com 147.243.3.73 with 32
bytes of data Reply from 147.243.3.73
bytes32 time301ms TTL242 Reply from
147.243.3.73 bytes32 time290ms TTL242 Reply
from 147.243.3.73 bytes32 time300ms
TTL242 Reply from 147.243.3.73 bytes32
time241ms TTL242 Reply from 147.243.3.73
bytes32 time290ms TTL242 Reply from
147.243.3.73 bytes32 time281ms TTL242 Reply
from 147.243.3.73 bytes32 time260ms
TTL242 Reply from 147.243.3.73 bytes32
time281ms TTL242 Reply from 147.243.3.73
bytes32 time300ms TTL242 Reply from
147.243.3.73 bytes32 time311ms TTL242 Reply
from 147.243.3.73 bytes32 time290ms
TTL242 Reply from 147.243.3.73 bytes32
time300ms TTL242 Reply from 147.243.3.73
bytes32 time261ms TTL242 Ping statistics for
147.243.3.73 Packets Sent 13, Received
13, Lost 0 (0 loss), Approximate round trip
times in milliseconds Minimum 241 ms,
Maximum 311 ms, Average 285 ms

RTT values of the first two packets almost the
same as there is no setup time in CELL_FACH
Average RTT on RACH/FACH is in the order of 285
ms
31
Data Transmission over Common Channels during
cell reselection Example traces from live
network
Small amount of data, so common channel sufficient
Pinging trabant.kom.auc.dk 130.225.51.16 with
32 bytes of data Reply from 130.225.51.16
bytes32 time290ms TTL239 Reply from
130.225.51.16 bytes32 time270ms TTL239 Reply
from 130.225.51.16 bytes32 time350ms
TTL239 Reply from 130.225.51.16 bytes32
time301ms TTL239 . . . Reply from
130.225.51.16 bytes32 time270ms TTL239 Reply
from 130.225.51.16 bytes32 time1192ms TTL239
Reply from 130.225.51.16 bytes32
time371ms TTL239 Reply from 130.225.51.16
bytes32 time270ms TTL239 . . Reply from
130.225.51.16 bytes32 time281ms TTL239 Reply
from 130.225.51.16 bytes32 time310ms
TTL239 Reply from 130.225.51.16 bytes32
time1042ms TTL239 Reply from
130.225.51.16 bytes32 time400ms TTL239 Reply
from 130.225.51.16 bytes32 time230ms TTL239
Cell Reselection time 1192-270922ms Large
value since there is no soft handover support in
CELL_FACH
Cell Reselection time 1042-310700ms
32
Dedicated Channels

• Bi-directional channel with both UL and DL
  directions (though not necessarily supporting the
  same data rate)
• Bit rates ranging from few kbps up to 384kbps
• Set up time required (around 1sec)
• Fast power control
• Soft handover (hence, no break during cell
  reselection)
• Transition from common channels to dedicated
  channels is decided based on traffic volume
  measurements

33
Common ? Dedicated channel switching
CELL_FACH state
CELL_DCH state
Traffic Pending Time
bit rate
InitialBitRateDL
time
Inactivity Time
High Threshold
Low Threshold
RLC buffer payload
34
Data Transmission over Dedicated Channels
Example traces from live network - I
Large amount of data, so common channel not
sufficient

• Pinging www.nokia.com 147.243.3.73 with 128
  bytes of data
• Reply from 147.243.3.73 bytes128 time1121ms
  TTL242
• Reply from 147.243.3.73 bytes128 time221ms
  TTL242
• Reply from 147.243.3.73 bytes128 time190ms
  TTL242
• Reply from 147.243.3.73 bytes128 time200ms
  TTL242
• Reply from 147.243.3.73 bytes128 time190ms
  TTL242
• Reply from 147.243.3.73 bytes128 time200ms
  TTL242

• First packet experiences the RTT DCH setup
  delay
• DCH Setup time1121-221900ms
• RTT of DCH in the order of 195ms (as compared
  with 285ms for a 32 byte ping in RACH/FACH)

35
Data Transmission over Dedicated Channels
Example traces from live network - II

• Ping was performed continuously for packets sizes
  ranging from 1 400, 10 byte interval. CELL_DCH
  mode entered during pinging 250 bytes, and kept
  afterwards.

CELL_FACH
CELL_DCH
36
Data Transmission over Dedicated Channels
Example traces from live network - III

• To start FTP connection, no DCH required
• To run simple commands like cd that dont require
  the download of a lot of data, DCH is not also
  required
• Commands that require download of data, even
  dir command, require DCH

FTP Connection establishment
Dir (listing was app. 12KB)
Cd dir
37
Data Transmission over Dedicated Channels
Example traces from live network - IV
2
3
4
3
1
38
Cell-Specific PS algorithms

• Fair Throughput Scheduling gives all users the
  same throughput, independent of where they are
  located
• Fair Resource Scheduling give the same amount of
  power to all users schedule them the same
  amount of time, i.e. all users get the same
  amount of resources
• C/I Scheduling packets belonging to links with a
  good C/I over a certain average have higher
  priority than packets with a lower C/I

UE2 128 kbps
UE1 128 kbps
UE2 64 kbps
UE1 256 kbps
39
Outline

• Introduction
• QoS in UMTS
• Introduction
• Packet Scheduling
• RLC
• TCP and its performance within UMTS
• End-2-End QoS (IP UMTS QoS)
• Performance of different services in WCDMA
  (demonstrations)
• Summary

40
Data User Plane Protocol Stack for WWW Service
41
Radio Link Control (RLC) Protocol

• RLC is responsible for segmentation and
  reassembly of higher layer data
• RLC provides reliability through link layer
  retransmission
• RLC provides flow control to monitor the rate at
  which the peer RLC can send information.
• RLC can operate in three different modes
• Transparent (TM) (Limited) Segmentation
  Reassembly
• Unacknowledged (UM) Segmentation Reassembly
  concatenation padding
• Acknowledged (AM) Segmentation Reassembly
  concatenation reliability (retransmission)

42
RLC-Acknowledged Mode Operation
Segment coming from Upper Layer (SDUs)
Segment sent to Upper Layer (SDUs)
Send Polling If required
Send Status if required
Info about received data, status polling
Scheduled segments
Transmitting Side
Receiving Side
Status report
RLC segment (PDU)
RLC PDU with Polling set
43
Some important RLC parameters

• Sender Side
• maxDAT (integer) maximum number of times that a
  PDU within a given SDU can be transmitted before
  the SDU is discarded
• Timer Poll (ms) if a poll is sent and a status
  is not received within the timer poll time, the
  poll is sent again
• Poll Last (Re)transmitted PDU (y/n) whether to
  send a poll along with the last (re)transmitted
  PDU in the send buffer
• Receiver Side
• Status Prohibit time (ms) minimum time that has
  to elapse between consecutive status reports
• Missing PDU indication (y/n) whether to send
  status immediately after out of order PDUs are
  received
• Out of order delivery (y/n) whether to deliver
  RLC packets out of order or not to higher layers

44
FTP File Downloads Effect of RLC settings - I
FS100KB - BR384kbps - TimerPoll100ms -
MissingPDUtrue, BLER10
40
35
30
25
DL mean Download Time s
20
15
10
5
0
1
2
3
4
5
6
7
8
9
10
max DAT Transmissions

• MaxDAT is the most determinant factor

45
FTP File Downloads Effect of RLC settings - II
FS100KB - BR384kbps - TimerPoll100ms -
MissingPDUtrue, BLER10
300
280
260
DL mean Throughput kbps
240
220
200
180
1
2
3
4
5
6
7
8
9
10
max DAT Transmissions

• Higher throughput with higher maxDAT and lower
  status prohibit values

46
FTP File Downloads Effect of RLC settings - III
FS100KB - BR384kbps - TimerPoll100ms -
MissingPDUtrue, BLER10
250
240
230
220
DL mean Goodput kbps
210
GoodPut (Kbps)
200
190
180
170
1
2
3
4
5
6
7
8
9
10
max DAT Transmissions

• Higher goodput with higher maxDAT and higher
  status prohibit values

47
Outline

• Introduction
• QoS in UMTS
• TCP and its performance within UMTS
• Introduction
• TCP flow and Congestion Control
• TCP RLC
• TCP HTTP
• End-2-End QoS (IP UMTS QoS)
• Performance of different services in WCDMA
  (demonstrations)
• Summary

48
Transmission Control Protocol (TCP)

• Today TCP is used for 80-90 of all packet
  traffic in the internet
• Ensures reliable transfer of data, hence used
  where reliability is important and some delay can
  be tolerated (www, Email, FTP,)
• Application data is broken into packets and
  identified by SN (Sequence Number)
• When a packet is sent, a timer is started and if
  this timer expires before receiving an ACK
  (Acknowledgment) from the receiver, the packet is
  retransmitted
• The checksum field in the header is used to
  verify the validity of a received data
• Duplicate packets are discarded
• Out-of-order received packets are reordered
• Flow control is provided to make sure that a fast
  sender will not overwhelm a slow receiver
• Congestion control mechanisms used to provide
  proper usage of network resources, considering
  all flows

49
TCP Connection Establishment and Termination

• Small Packets (40 bytes each, at the IP level)
  are exchanged during Start and Termination and
  the MSS (Maximum Segment Size) is agreed upon
  during connection setup.
• These are put on common channels in in order to
  avoid waste of capacity

50
TCP Flow Control

• Generally two methods of flow control
• Stop and Wait send one packet and wait till ACK
  is received
• Sliding Window send as much window as the
  receiver can handle before having to wait for ACK
• TCP uses sliding window flow control
• Uses Send (Transmission) and Receive (Advertised)
  Windows (AWND))

Send Window
Receive Window
1
2
3
4
5
6
7
8
9
10
11
12
1
2
3
4
5
6
7
8
9
10
11
12
ACK 5
1
2
3
4
5
6
7
8
9
10
11
12
time
1
2
3
4
5
6
7
8
9
10
11
12
ACK 7
1
2
3
4
5
6
7
8
9
10
11
12
Sent and acknowledged
Received
Sent but not acknowledged yet
Not received but expected to be received
Not sent but receiver ready to receive
Not sent and receiver not ready to receive
Not received and not expected
51
TCP Congestion Control

• Flow controls adjusts sender to transmit as fast
  as the receiver can receive but does not consider
  the network in between
• So the sending rate have to depend not only on
  AWND, but also on the estimated network
  congestion in order to adapt to congestion
  situations
• CWND (Congestion window) window size resulting
  from congestion control algorithms
• Sending window min (AWND, CWND)
• Congestion control
• Slow start initial transmissions, probing of
  network bandwidth, increments cwnd exponentially
• Congestion Avoidance after cwnd reaches some
  threshold, increments are done linearly

52
TCP Slow Start
receiver
sender
Linear Increase i.e. Congestion Avoidance
Timeout
1 MSS
18
data
Threshold
16
Threshold
ack
to half
2 MSS
data
data
Congestion window in Max segment size
9
ack
Exponential
3 MSS
Threshold
ack
data
8
increase
4 MSS
data
data
ack
5 MSS
data
ack
4
6 MSS
ack
2
7 MSS
ack
8 MSS
Transmission in Round trip time

• The impact of slow start is highly dependent on
  the Round Trip Time (RTT)

53
TCP Dedicated Channel Usage Example from live
network
DCH 384 kbps
TCP slow start effect
DCH 64 kbps
RACH/FACH
1
2
3
4
5
5
1
TCP connection establishment on RACH/FACH
2
Download starts DCH allocated with 64 kbps
3
More data in the buffer DCH bit rate upgraded
to 384 kbps
4
File transfer over transmission power to
minimum, code still reserved
5
DCH released after inactivity
54
Bandwidth delay product

• The BDP (bandwidth-delay product) is a merit
  figure of the achievable capacity in the ideal
  steady state of a TCP connection.
• It can be calculated as
• Ideally congestion window BDP, higher values
  lead to congestion, and lower values than BDP
  lead to under utilization
• The window offered by the UE has to be as large
  as this product allows or otherwise the receiver
  will limit the TCP connection with the consequent
  radio resource waste

Round Trip Time
Bandwidth of the limiting link
55
Round Trip Time
Round trip time delay from mobile USB connector
to server and back
Server
BTS
RNC
SGSN/GGSN
UE
Iub
Uu
USB
56
Why Round Trip Time is Important (1) Web Page
Download Example
UE
DNS server
Web server
DNS query and reply
1
TCP connection establishment
Minimum 3 to 4 round trip times required for page
download
2
HTTP request and reply (text)
3
HTTP request and reply (pictures)
4

• Web page download involves several signaling
  messages
• Each message exchange takes minimum 1 round trip
  time
• Download takes minimum 3 to 4 round trip times
  even for a small page
• Several TCP connections may be required in a
  single page

) DNS domain name server
57
Why Round Trip Time is Important (2) Web Page
Download Example
Max bit rate used only after TCP slow start
TCP slow start
Bit rate
Download with long round trip time
1
2
3-4
Time
Download with short round trip time
Faster download even if max bit rate is not
increased
1
2
3-4
58
Web Page Download Time
Lower round trip time improves performance but
100 ms is good enough
1 Mbps improves performance compared to 384 kbps
59
TCP Timeout (RTO)

• The TCP timeout is needed to avoid too long
  buffering along the transmission path, while the
  fast retransmission algorithm can be used to
  recover from packet losses
• When a TCP packet is being send a timer is
  started.
• The timer is used to detect congestion in the
  network.
• The timer is calculated as

Linear Increase i.e. Congestion Avoidance
Timeout
18
Threshold
16
Threshold
to half
Congestion window in Max segment size
9
Exponential
Threshold
8
increase
RTO A 4D
4
2
A filtered RTT
D filtered std RTT
Transmission in Round trip time

• At timer expiration, the congestion window is
  set to one (new slow start) and the slow start
  threshold is set to half the current window.
• Different implementations of the timer exist,
  which will lead to a different types of timeouts.

60
RTT and RTO trace
Timeouts typically happenduring the start of
theconnection.
61
Fast Retransmission and Recovery - I

• RTO a very good indication of congestion, but
  waiting for the RTO to expire in order to
  retransmit usually leads to long inactivity times
  
• A duplicate ACK is also a sign of some packet
  loss or reordering, and the more duplicate ACKs
  we get, the more probable the packet loss is
• Fast Retransmit Instead of waiting for RTO, when
  a certain number of duplicate ACKs occur,
  retransmit packet even if the RTO has not
  occurred
• Fast Recovery when the packet is transmitted due
  to duplicate ACKs, instead of reverting to slow
  start, go to congestion avoidance state

62
Fast Retransmit and Recovery - II
63
Selective Acknowledgments (SACK)

• With SACK, TCP receiver is able to acknowledge
  out of order received packets
• SACK uses the option field in the TCP header, and
  it specifies the out of order received packets in
  a bitmap structure
• The normal cumulative ACK field used by normal
  TCP is still used to specify the last in sequence
  received packet, in addition to the SACK bitmap
• When sender get a TCP packet with some SACK
  bitmap, it will take notice of that, and next
  time it is required to retransmit data, it will
  retransmit only the non SACKed ones

64
TCP RLC

• RLC can be cause of extra delay, due to
  retransmissions
• RLC can be the cause of out of order reception of
  blocks (due to retransmissions, but this depends
  on whether or not the In order delivery field is
  set).
• If the In order delivery field is set,
  retransmissions make the estimated RTT longer.
• If not, retransmissions can trigger a fast
  retransmission, leading to unnecessary
  retransmissions at TCP level.
• In both cases a high number of retransmissions
  should be avoided.

65
TCP RLC Interactions Effect of slow start
BR384kbps - Timer Poll300ms - Status
Prohibit100ms
350
300
250
DL mean Throughput kbps
200
150
100
50
1
2
3
4
5
6
7
8
9
10
max DAT Transmissions

• Available bandwidth not used properly for small
  file transfers mainly due to TCP slow start

66
TCP RLC interaction-RLC Out of sequence
delivery- I

• For the case of almost no error (1 FER), the
  FACK/SACK performs slightly better than the no
  FACK/SACK case, for both in- and out-of-sequence
  delivery
• When the error rate is increased, we see the
  performance of the FACK/SACK case worsens much
  faster than the no FACK/SACK if we are using
  out-of-sequence delivery.

67
TCP RLC interaction-RLC Out of sequence
delivery- II

• Out-of-sequence delivery leads to lower RTT
  values than in-sequence delivery, as packets are
  released immediately to upper layers, regardless
  of their order.
• For the higher error rates, for both the in- and
  out-of sequence cases, FACK/SACK performs better
  while for the low error rate FACK leads to
  increase in RTT.

68
TCP Upper Layers , HTTP 1.0
USER
SERVER

• Web Browsing Applications use the HyperText
  Transfer Protocol.
• The user establishes a TCP connection to request
  for the Web page.
• A Web Page is composed of multiple Objects
  (pictures, java applets,).
• The user parses the main body and identifies the
  required objects.
• In HTTP 1.0, the user establishes a new TCP
  Connection for each object.

TCP connection establishment
HTTP request
HTTP reply (Main Body)
TCP connection release
User Parses Main Body
TCP connection establishment
HTTP request
HTTP reply (secondary object)
TCP connection release
69
TCP Upper Layers, HTTP 1.1
USER
SERVER

• HTTP 1.1 introduced to overcome the limitations
  of HTTP 1.0
• In HTTP 1.1 the same TCP connection is employed
  to retrieve all objects.
• Small amount of data transferred per TCP
  connection is undesireable due to protocol
  overhead and TCP slow start.

TCP connection establishment
HTTP request
HTTP reply (Main Body)
HTTP request
HTTP reply (secondary object)
TCP connection release
70
TCP with HTTP 1.0 1.1
HTTP 1.0
TCP Session 1
TCP Session 4
TCP Session 7
SLOW-START
SLOW-START
SLOW-START
File 1
File 4
File 7
Channel capacity
TCP Session 2
TCP Session 5
TCP Session 8
SLOW-START
SLOW-START
SLOW-START
File 2
File 5
File 8
TCP Session 3
TCP Session 6
TCP Session 9
SLOW-START
SLOW-START
SLOW-START
File 3
File 6
File 9
Time
HTTP 1.1
TCP Session 1
SLOW-START
File 1
File 7
File 4
Channel capacity
TCP Session 2
SLOW-START
File 5
File 8
File 2
TCP Session 3
File 6
File 9
SLOW-START
File 3
Time
TCP slow start avoided for consecutive objects
71
Outline

• Introduction
• QoS in UMTS
• TCP and its performance within UMTS
• End-2-End QoS (IP UMTS QoS)
• QoS Principles in IP Domain
• IntServ
• DiffServ
• Performance of different services in WCDMA
  (demonstrations)
• Summary

72
QoS Traditional Internet

• Next-Hop forwarding approach of IP creates delays
  and bursts of traffic
• Traditional TCP/IP networks and also conventional
  internet applications (FTP, Email, Telnet) are
  tailored for best effort delivery i.e. no
  need/support for QoS
• When more demanding services such as streaming
  were introduced on the Internet, and the quality
  was bad, application-level techniques were
  generally used to mitigate, to some extent, the
  effects of delay and loss.
• Currently, two major architectures of
  introducing QoS in the IP world
• Integrated Services (IntServ)
• Differentiated Services (DiffServ)

73
QoS Provision Principles

• Marking distinguish between different classes
• Scheduling Which packets to be sent next from a
  link
• FIFO, Round Robin, Priority Based (eg. Weighted
  Fair Queuing)
• Policing force source adherence to bandwidth
  allocations
• Drop tail, priority based dropping, Random Early
  Dropping (RED)
• Shaping retains excess packets in a queue and
  schedules the excess for later transmission
• Leaky bucket, Token bucket
• Call Admission flow declares its needs, network
  may block call (e.g., busy signal) if it cannot
  meet needs

74
Leaky vs. Token Bucket
Tokens
Max Tokens

• Packets leave at constant rate

• Tokens arrive at constant rate
• Packets leave if there is enough token

75
Policing vs. Shaping
Policing
Shaping
76
Integrated Services (IntServ)

• Needs call setup and signaling (done using
  Resource reSerVation Protocol (RSVP))
• Arriving calls specify their traffic
  characteristics (T-Spec) QoS requirement
  (R-Spec)
• Admission done at each element on the path
• Each router in between the source and destination
  maintains state info of allocated resources, and
  flow in a session treated accordingly

77
RSVP
Sender
1. PATH
Receiver
3.Modified PATH
3. Reply yes/no to resource request
1. RESV specify traffic and guarantee
PATH messages
2. Save previous hop address session
parameters, replace previous hop address with own
in the PATH message
RESV messages
2. Check Requested resource vs. Available resource
78
IntServ Traffic Classes

• Two major classes of services in IntServ
• Controlled Load a service equivalent to that
  seen by a best-effort flow on a lightly loaded
  network (i.e. flow does not noticeably
  deteriorate as the network load increases)
• Guaranteed Load flows are given an assured level
  of bandwidth, with a firm end-to-end delay bound
  and no queuing loss for conforming packets of a
  data flow.

79
DiffServ

• Suggested as a simpler alternative to deliver IP
  QoS than IntServ
• Provides QoS without requiring per flow state and
  signaling at every hop
• Uses the TOS (Type of Service) field in the IP
  header, now it is called DSCP (DiffServ Code
  Point)

• Two major operations
• Packet Marking
• Per Hop Behavior (PHB)

80
Diffserv Architecture
81
Packet Marking

• Done by edge routers
• Packets arriving are marked differently depending
  on one or more of the following parameters
  (implementation dependent)
• Peak Information Rate
• Committed Information Rate
• Excess Burst Size
• Committed Burst Size
• Marking can be used to differentiate
• Different classes, or/and
• Conforming non-conforming portions
• within a flow

Tokens
Max Tokens
82
Per Hop Behavior (PHB)

• BA (Behavior Aggregate) Collection of packets
  that have the same DSCP value, and traversing the
  same path
• PHB scheduling, queuing, policing, or shaping
  behavior of a node on any given BA, configured by
  SLA (Service Level Agreements) or some other
  policy
• Four types of PHB
• Default PHB best effort as in traditional
  internet
• Class-Selector PHB for backward compatibility
  with use of TOS precedence
• Expedited forwarding (EF) (premium service) low
  loss, low latency, low jitter, assured bandwidth
  (for applications like VoIP)
• Assured forwarding (AF) has four sub-classes.
  Each class is assigned a given buffer and
  bandwidth, and within each class, it is possible
  to specify 3 drop precedence.

83
Implementing PHBs - I

• Managing the delay, loss and jitter is basically
  a problem of managing the queues in the network.
• Several queuing mechanisms can be used
• First In First Out (FIFO) First packet that
  comes in the queue is sent out first
• Simple Priority Queuing Packets that are marked
  differently are stored in different queues with
  different priorities. Packets within the lower
  priority queue have to wait till the high
  priority queues are empty
• Round Robin Packets are forwarded in a round
  robin fashion from each queue
• Weighted Round Robin (Weighted Fair Queuing /WFQ)
  An extension of round robin queuing where more
  packets can be forwarded from a given queue
  during its forwarding turn than another depending
  on its weight

84
Implementing PHBs - II

• Leaky bucket flows with WFQ Scheduling provides a
  guaranted upper bound on delay of

85
IP-UMTS QoS Inter-Working

• In order to provide End-2-End QoS, the IP level
  QoS is used on top of UMTS QoS. For proper
  inter-working of these two we need
• Mapping from IP QoS Attributes to UMTS Bearer
  Service Attributes
• Mapping from UMTS Bearer Service Attributes to
  Core Network Bearer Service Attributes
• An example of one possible mapping, in the case
  of Diffserv, is shown below

86
IntServ DiffServ

• State Information grows proportionally with the
  flows
• Complex routers required
• Soft reservations, and periodic refreshment
  needed
• Fundamental changes in Internet
• More solid end-2-end guaranty
• Designed for dynamic SLA
• Receiver participation

• simple functions in network core, relatively
  complex functions at edge routers (or hosts)
• Define service classes, provide functional
  components to build service classes
• Difficult to predict end-2-end behavior
• Designed for static SLA
• Unidirectional, i.e. receiver has no say

87
Outline

• Introduction
• QoS in UMTS
• TCP and its performance within UMTS
• End-2-End QoS (IP UMTS QoS)
• Service performance demonstrations
• Need for Emulation
• Demonstrations
• Summary

88
QoS investigations

• QoS is usually identified by some basic
  parameters such as delay, throughput, and jitter
• ?
• As the main impact of QoS provision is on the end
  user, a detailed study on QoS should involve the
  end user
• ?
• Extensive usability experiments required to
• Study behaviour of different services in
  different network conditions
• Identify generalized service dependent
  performance metrics, for already existing
  services
• Predict network environment requirements for
  future services
• ?
• An emulation test bed for performing these QoS
  investigations required

89
RESPECT

• Real-time Emulator for Service Performance
  Evaluation in Cellular neTworks
• Intercept real time traffic (e.g.. FTP, Web
  Browsing, Streaming)
• ?
• Pass the intercepted packets into emulated UMTS
  protocol stack
• ?
• Drop some packets, delay and re-inject others
  back into the network based on the workings of
  the UMTS network

Emulator (RESPECT)
90
RESPECT Protocol point of view
APPLICATION
APPLICATION
TCP
TCP
IP
IP
RLC
RLC
MAC
MAC
PHY
PHY
PHY
Air Interface
IUB Interface
CN
Data Link
Data Link
PHY
PHY
Emulator
Internet
PC
Server
91
Demonstration setup
92
Demonstration Effect of Bandwidth
93
Demonstration Effect of RTT
94
Demonstration Effect of BLER
95
Summary

• QoS is an important issue for wireless networks
• QoS is an End-2-End concept, where every entity
  between the sender and the receiver plays a part.
• 3GPP has specified the basic UMTS QoS
  architecture and traffic classes, but the
  implementation is up to operators/service
  providers
• Internet Engineering Taskforce (IETF) has defined
  the IntServ and Diffserv IP-level QoS
  architectures, but the implementation is up to
  operators.
• Interaction (Mapping) of IP (and higher layer, if
  any) QoS mechanisms with UMTS level ones is still
  one of the most pressing issues with regard to
  End-2-End provision in UMTS networks
• As QoS is End-2-End concept, the final verdict of
  whether the quality of a given service is
  adequate or not should be given by the end user.

96
References - General

• Harri Holma Antti Toskala, "WCDMA for UMTS
  Radio Access for UMTS Radio Access For Third
  Generation Mobile Communications", Third Edition,
  2004
• Tim Szigeti Christina Hattingh, "End-to-End QoS
  Network Design Quality of Service in LANs, WANs,
  and VPNs", Cisco press, 2004
• Cisco Systems, "Qos Tutorial", http//www.cisco.co
  m/univercd/cc/td/doc/cisintwk/ito_doc/qos.htm
• Paul Ferguson and Geoff Huston, Quality of
  Service delivering QoS on the Internet and in
  corporate networks, John Wiley Sons, 1998.
• Network Magazine, "IP Quality of Service",
  http//www.networkmagazine.com/article/NMG20000727
  S0024

97
References QoS in UMTS

• Harri Holma Antti Toskala, "WCDMA for UMTS
  Radio Access for UMTS Radio Access For Third
  Generation Mobile Communications", Third Edition,
  2004
• 3GPP, UMTS General Architecture, 3GGP TS
  23.101, v. 6.0.0, Dec 2004
• 3GPP, "QoS Concept and Architecture," 3GPP TS
  23.107, v .6.3.0, June 2005
• 3GPP, End-to-End Quality of Service (QoS)
  Concept and Architecture, 3GPP TS 23.207
  v5.3.0,June 2005
• Alcatel, QoS Implementation in UMTS networks,
  http//www.alcatel.com/doctypes/articlepaperlibrar
  y/pdf/ATR2001Q1/gb/09baudetgb.pdf
• Oumer Teyeb, et. al, ""Emulation Based
  Performance Investigation of FTP File Downloads
  over UMTS Dedicated Channels", ICN'05, April,
  2005

98
References - TCP

• J. Postel, "Transmission control protocol ", RFC
  793, September 1981.
• V. Jacobson, "Congestion avoidance and control",
  In Proceedings of the ACM SIGCOMM Conference,
  pages 314-329, August 1988.
• M. Allman, V. Paxon, and W. Stevens, "TCP
  congestion control", RFC 2581, April 1999.
• M. Mathis et al, TCP selective acknowledgment
  options, RFC 2018, Oct. 1996.
• W. Stevens, TCP/IP Illustrated, Vol 1.,
  Addision-Wesley 1994
• Ameigeiras P.J., Wigard J. and Mogensen P,
  'Impact of TCP flow control on the radio resource
  management of WCDMA systems', Proceedings of VTC
  Spring 2002, May, 2002.
• Oumer Teyeb, et. al, "The Impact of RLC Delivery
  Sequence on FTP Performance, WPMC 2005

99
References End-2-End QoS

• S. Blake et. al, "An architecture for
  differentiated services", RFC 2475, December
  1998.
• R. Braden, et al., "Integrated services in the
  internet architecture an overview", RFC 1633,
  June 1994.
• R. Braden et. al, "Resource reservation protocol
  (rsvp) - version 1 functional specification", RFC
  2205, September 1997.
• Marko Luoma et. al, "Quality of service for IP
  voice services - is it necessary?", In
  Proceedings of Voice, Video and Data '98, pages
  242-253. SPIE, November 1998.
• SAMU Project, QoS Deliverables-SP2,
  http//samu.crm-paris.com/Edocuments.htm
• Xipeng Xiao and Lionel M. Ni, IP QoS A Big
  Picture, IEEE Network, 1999
• H. Montes et. al , "An End-to-End QoS Framework
  for Multimedia Streaming Services in 3G
  Networks", PIMRC 2002
• M. Ricardo et. al, "Support of IP QoS Over UMTS
  Networks", PIMRC 2002
• Racha ben Ali et.al, UMTS-to-IP QoS Mapping for
  Voice and Video Telephony Services, IEEE
  Network, April 2005
• Oumer Teyeb, et. al, "RESPECT A Real Time
  Emulator for Service Performance Evaluation of
  Cellular neTworks", VTC fall 2005