TCP, UDP & HSDPA

Dave Kitcher 25/09/06

NOKIA

FILENAMs.PPT/ DATE / NN

Contents
These slides give a brief summary of :

HSDPA TCP UDP

The purpose of these slides is to give general / background knowledge so that the terms used in the Log Analysis slides make some sense They are not detailed technical descriptions There are already more technical presentations on HSDPA available We still dont understand enough about TCP to give a detailed technical presentation
2 NOKIA FILENAMs.PPT/ DATE / NN

HSDPA
DL data is on a shared channel so theoretical maximum is high, but its affected by the number of other HSDPA users in the cell We expect a lot of product program errors because they dont get 3.6Mb/s during field testing There can be multiple cells in the active set (DCH) But there can only be one HSDPA Serving Cell at a time

HSDPA is downlink only UL data (e.g. RLC Acks) are still sent on DCH There is a high speed UL control channel for HSDPA though (contains CQI and HARQ Ack / Nak) HSDPA uses 2ms TTI

NOKIA

FILENAMs.PPT/ DATE / NN

HSDPA
There are two types of modulation for HSDPA QPSK (max throughput is 1.2Mb/s) 16-QAM (max throughput is 3.6Mb/s)

We support QPSK and 16-QAM Most of our testing is 16-QAM

VF UK only support QPSK though

L1 can Ack / Nack data, so there can be some retransmissions at L1 But there are limits, so RLC still operates in AM mode

NOKIA

FILENAMs.PPT/ DATE / NN

HSDPA Serving Cell

Active Set Update cannot be used to change the HSDPA Serving Cell in Release 5 It can only be used to affect the DCH Active Set It can be used in the future for HSDPA (for release 6) BUT the HSDPA serving cell must be in the active set

So Active Set Update can be used to remove the serving cell from the active set and this will suspend HSDPA

HSDPA Serving Cell can be changed via : Radio Bearer Reconfiguration Transport Channel Reconfiguration Physical Channel Reconfiguration

NOKIA

FILENAMs.PPT/ DATE / NN

HSDPA - CQI
CQI Channel Quality Indicator In DCH, n/w tells us the target Block Error Rate (BLER) we should aim for when the connection is established

The UE asks the n/w to adjust DL transmit power to match this target N/W
U E Target BLER = 10%
BLER > Target

Increase DL Power
BLER < Target

Decrease DL Power

NOKIA

FILENAMs.PPT/ DATE / NN

HSDPA - CQI
For HSDPA we are not told the target BLER The UE decides the acceptable target BLER The UE uses CQI to adjust the actual BLER If BLER is low, UE sends high CQI to the n/w If BLER is high, UE sends low CQI to the n/w The n/w uses CQI to decide the size of the transport blocks it sends to the UE High CQI = large transport blocks = high speed Low CQI = small transport blocks = low speed
U E DL Data CQI (and HARQ Ack / Nack) N/W
HS-PDSCH physical channel HS-DPCCH physical channel

N/W adjusts transport block size

7 NOKIA

DL FILENAMs.PPT/ DATE / NN Data

HSDPA - CQI
The n/w uses a table to map CQI to transport block size The table is only a guide. Exact implementation varies between networks CQI 22 indicates that we can receive maximum block size If you are analysing throughput logs, always check CQI. If its not 22 or more, you wont get maximum throughput Above 22, CQI is used for DL power control

High CQI means asks for lower DL power Low CQI asks for higher DL power

NOKIA

FILENAMs.PPT/ DATE / NN

HSDPA HARQ
HARQ : Hybrid Automatic Repeat Request This is how L1 requests retransmissions For each transmission the data is stored in a HARQ process For each re-transmission the data combined with previous data in the same HARQ process Number of HARQ processes is configured in WCDSP_MAC_HS_CONFIG_REQ Range from 1 to 8 All data from one specific sub-frame is processed by 1 HARQ process

This is controlled by network scheduling data in specific sub-frames

There are 3 Indications that a HARQ process can send to the n/w : Ack I received that transport block OK Nack I failed to receive that transport block
DTX There was no transport block L1 cannot wait forever for retransmissions to succeed After several attempts, data is lost and new data written into the HARQ process Data can be sent to MAC out of order (e.g. due to L1 retransmissions) MAC-HS maintains queues to re-order the data RLC can request re-transmission of data lost at L1 NOKIA FILENAMs.PPT/ DATE / NN

N/W may retransmit it

HSDPA - Architecture
Protocol Stack

Laptop or internal browser Cellmo MCU

Cellmo DSP

FTP TCP UDP IP PDCP RLC (AM) MAC (MHS) MAC (DHS)

10

NOKIA

FILENAMs.PPT/ DATE / NN

TCP
TCP is described in an RFC (793) An RFC is quite different from 3GPP specification A specification says you must do something. If you dont, then you are not following the specification and you will fail conformance tests (and might have to recall your phones) An RFC says you should do something, or it might be nice if you did something, or its recommended that you do something. If you dont, then it simply means your implementation may not be very robust. But you can still say its TCP We have already experienced TCP implementations that do not follow the recommendations in the RFC Ethereal is used to analyse TCP data for HSDPA throughput logs
11 NOKIA FILENAMs.PPT/ DATE / NN

TCP
TCP is an end-to-end protocol So for FTP, the TCP Connection is between the laptop and the FTP server

It is a reliable protocol Data contains sequence numbers Missing data can be detected Data must be acknowledged Data can be retransmitted Multiple TCP SDUs can be acknowledged with one TCP Ack

Most TCP implementations seem to Acknowledge every 2nd or 3rd SDU

12

NOKIA

FILENAMs.PPT/ DATE / NN

TCP
Each packet contains a sequence number But each byte is numbered. Hence the sequence number will increase by the packet size for each packet The TCP Acknowledgments contain : The sequence number of the next byte that is expected The number of bytes that the receiver has space for (up to the TCP Window size)
TCP Sequence Number 132,495. Length 1460 TCP Sequence Number 133,955. Length 1460 TCP Ack 135,415. Win 131,600

13

NOKIA

FILENAMs.PPT/ DATE / NN

TCP Transmit Window

The transmit window is the maximum number of bytes that TCP will send without receiving an Ack If it doesnt receive an Ack before the window fills, it will stop transmitting and wait If it still doesnt receive an Ack it will retransmit the entire window TCP SDU Seq. Num
1000 TCP SDU Seq. Num 2000 TCP SDU Seq. Num 15000

Ack Received

TCP Window is full Transmission stops

TCP Ack TCP SDU Seq. Num 16000

No Ack timer expires TCP SDU Seq. Num 1000 TCP SDU Seq. Num 2000 TCP SDU Seq. Num 3000
14 NOKIA FILENAMs.PPT/ DATE / NN

TCP Transmit Window

The TCP window size is a 16 bit field Later options for TCP allow window scaling this allows bigger window sizes. Scaling means that the window size is multiplied by a scaling factor

This also applies to the TCP Acks. For a 128KB TCP window, the scaling factor is 2 which means that the TCP window should be multiplied by 4. This includes the window field in the TCP Acks so they will generally be 32K, and 32K x 4 = 128K.

In Windows, there is also a Global TCP Window size The TCP Window size cannot exceed this value In theory, a 64K window is big enough to allow 3.5Mb/s We have changed the TCP Window size to 128K in our HSDPA Golden laptops

15

NOKIA

FILENAMs.PPT/ DATE / NN

TCP - Connections
A TCP Connection is established by sending a SYN frame this contains the options that the sender supports The receiving entity sends a SYN ACK, which contains the options it supports If the SYN does not contain the optional parameters (e.g. window scaling) then the SYN ACK is not allowed to contain them If a download is attempted (e.g. FTP) then a new TCP connection is established just for that download If the client doesnt set the server into passive mode then the server will send the SYN and may not include the window scaling option A TCP connection is closed by FIN / FIN ACK
16 NOKIA FILENAMs.PPT/ DATE / NN

SYN (includes options) SYN Ack (includes options) TCP Connection Established

FTP Download

SYN SYN Ack Data Transfer FIN FIN ACK FIN FIN ACK

TCP Clients and Servers

Implementations vary quite a lot. We have seen the following problems so far FTP Server does support scaling (this is seen in the SYN / SYN Ack when the initial TCP connection is established for the user to login) but when a new connection is established for a file download in non-passive mode, the n/w does not include the scaling option in the SYN The laptop has stopped sending TCP Acks even though it is clearly still receiving TCP SDUs and even though other traffic (e.g. DNS requests) are still being sent. This has only been seen with the DOS TCP client The DOS client does not handle the first point listed above. If the initial connection does successfully negotiate scaling then it seems to assume that scaling is being used in the actual download and it therefore only ever sends TCP Acks with a window field of 32K. When the window size is not being scaled, this will not allow high throughput
17 NOKIA FILENAMs.PPT/ DATE / NN

TCP Simultaneous UL / DL
This basically doesnt work. The TCP Acks are delayed by the TCP Data and these delays will cause the TCP Window to fill, and the transmission to pause. They may even cause retransmissions From testing on the STN, it seems that one direction usually wins and will have reasonably stable throughput and the other direction will lose and will have very bursty throughput

Remember most HSDPA tests will be concentrating on download speed, even if the tester carries out simultaneous UL / DL They cannot measure the UL speed so if the DL is slow / bursty they wont care that the UL worked. And if the DL is fast / stable, they probably wont even notice that the UL was slow / bursty
18

Dont spend significant time on throughput analysis for logs that have simultaneous UL / DL (assuming it was using TCP).
NOKIA FILENAMs.PPT/ DATE / NN

UDP
UDP is simply an unacknowledged equivalent of TCP SDUs still have sequence numbers

But there are no Acknowledgments, and no retransmissions

A bit like RLC in UM mode (but obviously at a higher layer)

If data is transferred over UDP, then the client (laptop) must contain s/w running to absorb / discard these packets If not, then the laptop will respond to every UDP SDU with an ICMP Destination Unreachable packet

This is longer than a TCP Ack so it means that UDP (which should have no UL data at all except for RLC Acks) generates more UL data than TCP!

We typically use Byteslinger (NRC application)

19

NOKIA

FILENAMs.PPT/ DATE / NN