The throughput experienced at the application layer is always lower than the Link layer speed (which is in most cases advertised). The speeds published by the Network Service Providers is reduced because of number of factors.
For definition:
Link Layer Speed: is the throughput at the Link Layer. This is the rate with which a L2 packet is transferred between the corresponding L2 entities.
Application Layer Speed: is the speed experienced by the user. The rate at which the data useful to the application is transferred between the Application End points.
The extent of reduction in the Application layer speed depends upon:
- IP and transport protocol overhead
- UMTS Layer 2, Layer 3 Header overheads
- Segmentation/Concatenation
- Amount of Padding
The IP carries almost all of the data traffic and adds a IP header. The transport protocol adds another header and extra bytes to the data to be transmitted.
The UMTS architecture has multiple entities on the UE and network side interacting with each other. These require some control information in order to transfer data among each other.
The L2 (MAC) and L3(RLC) headers add to the over head. Next is the efficiency of the algorithm at MAC which packs the data in MAC PDUs. This algorithm should be smart enough to keep the amount of padding to a minimum.
The figure above shows the overhead added at each layer. Though not to scale, it highlights all the extra bytes that the MAC PDU is carrying for the Application data bytes that it is carrying.
Also, here it is assumed that the IP packet is transmitted as a whole, which is seldom the case. At most of the time, the IP packet might be segmented into RLC PDUs and then one RLC PDU segmented into MAC PDUs, depending on the TB size selected by MAC.
This overhead is even more pronounced when the MAC PDU size is small. Therefore it is important that RLC PDU size and the MAC PDU sizes be chosen in a way that the segmentation is minimized.
Lets take an example to see the magnitude of this overhead:
For a application using 384 kbps PS RAB
|
Higher layer
|
RAB/Signalling RB
|
RAB
|
|
|
RLC
|
Logical channel type
|
DTCH
|
|
|
RLC mode
|
AM
|
||
|
Payload sizes, bit
|
320
|
||
|
Max data rate, bps
|
384 000
|
||
|
AMD PDU header, bit
|
16
|
||
|
MAC
|
MAC header, bit
|
0
|
|
|
MAC multiplexing
|
N/A
|
||
|
Layer 1
|
TrCH type
|
DCH
|
|
|
TB sizes, bit
|
336
|
||
|
TFS
|
TF0, bits
|
0x336
|
|
|
TF1, bits
|
1x336
|
||
|
TF2, bits
|
2x336
|
||
|
TF3, bits
|
4x336
|
||
|
TF4, bits
|
8x336
|
||
|
TF5, bits
|
12x336
|
||
|
TF6, bits
|
N/A (alt. 16x336)
|
||
|
TF7, bits
|
N/A (alt. 20x336)
|
||
|
TF8, bits
|
N/A (alt. 24x336)
|
||
|
TTI, ms
|
10 (alt. 20)
|
||
|
Coding type
|
TC
|
||
|
CRC, bit
|
16
|
||
|
Max number of bits/TTI after channel coding
|
12 684 (alt. 25 368)
|
||
|
RM attribute
|
110 to 150
|
||
Lets assume for simplicity a 5 byte ping. Each ping packet will be carried in a IP packet with ICMP header and will be fit inside one Transport Block for carrying over the air. The application data transferred in each 336 bit of Transport Block is:
ping size = 5 * 8 = 40 bits
The header sizes are:
336 - 20*8(IP header) - 8*8(ICMP header) - 16 (MAC-header) - 16 (RLC AM header) - 40 (padding) = 40 bits.