Tcpip Over Umts

8/6/2019 Tcpip Over Umts

1/99

Technische Universitat Wien

Diplomarbeit

TCP/IP over UMTS

ausgefuhrt am

Institut fur

Nachrichtentechnik und Hochfrequenztechnik

der Technischen Universitat Wien

unter der Anleitung von

o. Univ. Prof. Dr. techn. Ernst BonekDI Manfred Taferner

durch

Georg LoffelmannA - 1210 Wien, Eichfelderstrae 17

Wien, im September 2000


2/99


3/99

Zusammenfassung

Die steigende Nachfrage fur mobilen Internetzugang verlangt nach hochdatenratigen,paketvermittelten Mobilkommunikationssytemen.

Universal Mobile Telecommunications System (UMTS) ist das Mobilfunksystem der drit-ten Generation und soll 2002 in Betrieb gehen. UMTS bietet Datenubertragungsratenbis maximal 2048 kbit/s. Die UMTS Funkschnittstelle UMTS Terrestrial Radio Access(UTRA) basiert auf Direct Sequence Code Division Multiple Access (DS-CDMA). UTRAbietet paketvermittelte Transportdienste und dynamische Ressourcenzuweisung. Der Ra-dio Link Control (RLC) Layer an der Funkschnittstelle verfugt uber verschiedene Ubertra-gungsmodi: Unacknowledged Mode Data (RLC UMD) mit Fehlererkennung und Acknowl-edged Mode Data (RLC AMD) mit Fehlerkorrektur, wobei, basierend auf Negative Ac-knowledgements (NACKs), fehlerhafte Daten neu ubertragen werden. UMTS stellt auchoptionale TCP/IP Header-Kompression fur die paketvermittelten Datendienste bereit.

Das Standard Transportprotokoll fur die fehlerfreie Datenubertragung uber das Internetist das Transmission Control Protocol (TCP) mit einer auf Acknowledgements (ACKs)basierenden Fehlerkorrektur durch Anzeige korrekt empfangener Daten. TCP setzt aufdem Internet Protocol (IP) auf.

In dieser Diplomarbeit beschreibe ich die Simulation von Datenubertragungen zwischeneinem herkommlichen Internet-Server und einer UMTS Mobilstation. Der TCP Durchsatzwird fur variierende Blockfehlerraten (BLER) am Transportkanal fur Transportdienste mit12.2 kbit/s, 64 kbit/s, 144 kbit/s, 384 kbit/s und 2048 kbit/ ausgewertet. Die maximalerlaubte BLER liegt im Bereich von ca. 10% fur RLC AMD und etwa 1% fur RLC UMD.

Der TCP Gesamtdurchsatz beim 64 kbit/s Transportdienst steigt bei Aktivierung derHeader-Kompression mit RLC AMD, fallt aber fur RLC UMD unter den Wert, derohne Header-Kompression erreicht wird. Fur den 384 kbit/s Transportdienst wurden ver-schiedene Verkehrsszenarien, darunter gleichzeitige FTP Downloads, gleichzeitige FTP Up-und Downloads sowie HTTP Web Browsing, ausgewertet. Die Dynamik des Flukontrol-lalgorithmus von TCP fuhrt zu Durchsatzergebnissen unter dem theoretischen Maximum.

Ich komme zu dem Schlu, da die derzeit am haufigsten verwendete TCP Reno Implemen-tation nicht optimal uber UMTS Transportdienste bei hohen Datenraten arbeitet. NeuereImplementationen, wie TCP Vegas, sollten hier den Durchsatz erhohen. Die Verwendungvon Window Scaling und Selective Acknowledgements (SACKs) ist fur hohe Datenratenauf der UMTS Funkschnittstelle zwingend notwendig.

i


4/99

Abstract

The rising demand for mobile Internet access requires mobile telecommunications systemswith the ability to handle packet switched data at high data rates.

Universal Mobile Telecommunications System (UMTS) is the third generation mobile radiosystem and is expected to launch in 2002. UMTS provides raw data rates for packetswitched data of up to 2048 kbit/s. The UMTS radio interface UMTS Terrestrial RadioAccess (UTRA) is based on Direct Sequence Code Division Multiple Access (DS-CDMA).UTRA provides transport services for the packet switched domain and dynamic allocationof resources. The Radio Link Control (RLC) layer of the UMTS radio interface providesdifferent modes for transmission of packet switched data: Unacknowledged Mode Data(UMD), providing error detection, and Acknowledged Mode Data (AMD), providing errorcorrection by retransmitting corrupt data based on Negative Acknowledgements (NACKs).UMTS packet switched data services also provide optional TCP/IP header compression.

The standard transport protocol for reliable transmission of data on the Internet is theTransmission Control Protocol (TCP) with an error correction based on Acknowledgements(ACKs), indicating valid received data. TCP operates on top of the Internet Protocol (IP).

In this thesis, I will describe simulations of data transmissions between a conventionalInternet server and a UMTS User Equipment (UE). TCP throughput is evaluated forvaried block error ratios (BLER) on the transport channel for transport services with datarates of 12.2 kbit/s, 64 kbit/s, 144 kbit/s, 384 kbit/s and 2048 kbit/s. The maximumallowed BLER is in the range of about 10% for RLC AMD and about 1% for RLC UMD.

The overall TCP throughput for the 64 kbit/s transport service is increased if headercompression is activated when using the RLC AMD mode. However, a decrease below thevalue evaluated without header compression is observed for the RLC UMD mode. Severaltraffic scenarios are evaluated for the 384 kbit/s transport service, including simultaneousFTP downloads, simultaneous FTP up- and download and HTTP web browsing. Thedynamics of TCPs congestion control algorithm lead to throughput results below thetheoretical maximum.

I come to the conclusion that the, todays most commonly used, TCP Reno implementationperforms not optimal over UMTS transport services at high data rates. Newer implemen-tations, like TCP Vegas, should increase overall throughput. The use of Window Scalingand Selective Acknowledgements (SACKs) is mandatory for high data rates in heavy-lossenvironments, like the UMTS radio interface.

ii


5/99

Acknowledgement

I wish to express my appreciation to Prof. Dr. Ernst Bonek for his endeavors throughoutthe time I wrote this diploma thesis. He encouraged me in many ways and providedvaluable hints on the presentation of topics and the English Language.

I want to thank all members of the Mobile Communications Group for their best care andattention and numerous constructive discussions.

Special thanks go to my supervisor DI Manfred Taferner. He had great patience in teachingme the mysteries of the simulation software and was always supportive in an exemplaryway.

He shared his work on evaluation of TCP/IP data transmission with the simulation soft-ware, which was of great help and provided many insights. He also had very helpfulsuggestions when proof reading my thesis.

I would like to dedicate this diploma thesis to my parents. You never lost faith in what I

did and it is your singular support I admire with great respect.

iii


6/99

Contents

1 Introduction 1

1.1 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 UMTS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 UMTS Protocol Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 UTRAN Protocol Architecture 7

2.1 Packet Data Convergence Protocol . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Radio Link Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 Unacknowledged Mode Data, UMD . . . . . . . . . . . . . . . . . . 11

2.2.2 Acknowledged Mode Data, AMD . . . . . . . . . . . . . . . . . . . 12

2.3 Medium Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.1 MAC-c/sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.2 MAC-d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 TCP/IP Protocol Stack 18

3.1 IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Sliding Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.2 Retransmission Timer . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.3 Slowstart and Congestion Avoidance . . . . . . . . . . . . . . . . . 24

3.2.4 Fast Retransmit and Fast Recovery . . . . . . . . . . . . . . . . . . 26

3.2.5 Delayed Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.6 Window Scaling for Long, Fat Networks . . . . . . . . . . . . . . . 27

3.3 Performance Issues and Influences . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.1 IP Maximum Transmission Unit . . . . . . . . . . . . . . . . . . . . 28

3.3.2 TCP Maximum Segment Size . . . . . . . . . . . . . . . . . . . . . 28

3.3.3 TCP Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.4 UMTS PDCP Header Compression . . . . . . . . . . . . . . . . . . 29

iv


7/99

CONTENTS v

3.3.5 UMTS RLC Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.6 UMTS MAC Scheduling and Physical Layer Transmission Format . 32

3.3.7 External Packet Data Network . . . . . . . . . . . . . . . . . . . . . 32

4 Simulation Model 34

4.1 Simulation Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.1 TCP Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.2 IP Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2.3 PDCP Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2.4 RLC Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.5 MAC Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.6 Channel Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.7 Internet Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.8 FTP Server Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2.9 HTTP Traffic Model . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.3 Simulation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 Investigation of Transport Services 44

5.1 12.2 kbit/s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2 64 kbit/s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2.1 RLC AMD/UMD + TCP/IP Header Compression . . . . . . . . . 50

5.3 144 kbit/s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.4 384 kbit/s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.4.1 RLC AMD + Lossy Internet . . . . . . . . . . . . . . . . . . . . . . 56

5.4.2 RLC AMD + Simultaneous FTP Downloads . . . . . . . . . . . . . 58

5.4.3 RLC AMD + FTP Up- and Download . . . . . . . . . . . . . . . . 63

5.4.4 RLC AMD + HTTP Traffic . . . . . . . . . . . . . . . . . . . . . . 64

5.5 2048 kbit/s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.5.1 Modifications to TCP Reno . . . . . . . . . . . . . . . . . . . . . . 71

6 Summary and Conclusion 75

A Ptolemy Universes 79

B Frequently Used Acronyms 81


8/99

List of Figures

1.1 UMTS functional parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 UMTS circuit switched and packet switched domain . . . . . . . . . . . . . 4

1.3 UMTS architecture (PS domain) . . . . . . . . . . . . . . . . . . . . . . . 41.4 UMTS protocol stack (PS domain) . . . . . . . . . . . . . . . . . . . . . . 5

2.1 PDCP service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 PDCP SDU and PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 RLC service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 RLC segmentation and concatenation . . . . . . . . . . . . . . . . . . . . . 10

2.5 UMD peer entities ([TS25.322, Figure 4.3]) . . . . . . . . . . . . . . . . . . 11

2.6 AMD peer entities ([TS25.322, Figure 4.4]) . . . . . . . . . . . . . . . . . . 12

2.7 MAC service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.8 UE side MAC architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 TCP/IP header field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Sliding window principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Slowstart, congestion avoidance and timeout . . . . . . . . . . . . . . . . . 25

3.4 Fast retransmit and fast recovery . . . . . . . . . . . . . . . . . . . . . . . 27

3.5 Interaction of TCP with RLC UMD/AMD, (a) (b) . . . . . . . . . . . . . 31

4.1 Simulation model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 TCP/IP simulation model . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3 PDCP simulation model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.4 RLC simulation model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.5 MAC simulation model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.6 Internet simulation model . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.7 FTP server model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.8 Payload generator model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.9 HTTP traffic model - file size request distribution . . . . . . . . . . . . . . 42

vi


9/99

LIST OF FIGURES vii

5.1 12.2 kbit/s - TCP throughput . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2 64 kbit/s - TCP throughput . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.3 64 kbit/s - TCP throughput (header compression) . . . . . . . . . . . . . . 51

5.4 144 kbit/s - TCP throughput . . . . . . . . . . . . . . . . . . . . . . . . . 53


5.6 384 kbit/s - TCP Throughput (RLC AMD, lossy Internet) . . . . . . . . . 57

5.7 384 kbit/s - TCP and RLC data rate (2 FTP downloads) . . . . . . . . . . 59

5.8 384 kbit/s - TCP and RLC PDF of packet delay (2 FTP downloads) . . . 60

5.9 384 kbit/s - TCP throughput dynamics (5 FTP downloads) . . . . . . . . 61

5.10 384 kbit/s - TCP throughput dynamics (lossy, 5 FTP downloads) . . . . . 62

5.11 384 kbit/s - TCP throughput dynamics comparison (5 FTP downloads) . . 635.12 384 kbit/s - TCP throughput dynamics (FTP up- and download) . . . . . 64

5.13 384 kbit/s - TCP and RLC data rate (FTP up- and download) . . . . . . . 65

5.14 384 kbit/s - TCP and RLC PDF of packet delay (FTP up- and download) 66

5.15 384 kbit/s - TCP throughput over file size (HTTP traffic, 1 client) . . . . . 67

5.16 384 kbit/s - TCP throughput over file size (HTTP traffic, 2 clients) . . . . 68


5.18 2048 kbit/s - TCP data rate comparison . . . . . . . . . . . . . . . . . . . 72

5.19 2048 kbit/s - TCP PDF of packet delay comparison . . . . . . . . . . . . . 73

6.1 Maximum allowed BLER for required throughput ratios . . . . . . . . . . . 77

A.1 FTP scenarios - Evaluation of TCP throughput . . . . . . . . . . . . . . . 79

A.2 HTTP scenarios - Evaluation of TCP throughput . . . . . . . . . . . . . . 80


10/99

List of Tables

2.1 PID value allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 C/T field structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Channel coding and transmission format . . . . . . . . . . . . . . . . . . . 16

4.1 Fixed simulation parameter set . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2 Variable simulation parameter set (default values) . . . . . . . . . . . . . . 43

5.1 UMTS service classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2 12.2 kbit/s - simulation parameter set . . . . . . . . . . . . . . . . . . . . . 46

5.3 12.2 kbit/s - TCP throughput . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.4 64 kbit/s - simulation parameter set . . . . . . . . . . . . . . . . . . . . . . 48

5.5 64 kbit/s - TCP throughput . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.6 144 kbit/s - simulation parameter set . . . . . . . . . . . . . . . . . . . . . 52


5.8 384 kbit/s - simulation parameter set . . . . . . . . . . . . . . . . . . . . . 54


5.10 384 kbit/s - simulation parameter set (RLC AMD, lossy Internet) . . . . . 56

5.11 384 kbit/s - simulation parameter set (simultaneous FTP downloads) . . . 58

5.12 384 kbit/s - TCP throughput dynamics (5 FTP downloads) . . . . . . . . 61

5.13 2048 kbit/s - simulation parameter set . . . . . . . . . . . . . . . . . . . . 69


viii


11/99

Chapter 1

Introduction

Demand for mobile telecommunication systems providing data transmission at high datarates is growing rapidly. By 2004, one-third of all Europeans are estimated to regularlyuse their mobile phones to access Internet services (Forrester Research 1999).

The Global System for Mobile Communications (GSM), standardized by the EuropeanTelecommunications Standards Institute (ETSI) and todays leader in wireless communica-tions, provides circuit switched (CS) data transmission at maximum rates of 14.4 kbit/s.Circuit switched means, that a dedicated transmission medium is reserved and engagedduring the entire connection phase, even if no data is actually transmitted. General PacketRadio Service (GPRS) enhances GSM with packet switched (PS) data transmission capabil-

ities at single user rates of 172.2 kbit/s as stated in [GSM03.64]. Packed switched means,that data streams are segmented into packets and multiple users may share one singlemedium. However, GPRS decreases GSM cell capacity.

The Universal Mobile Telecommunications System (UMTS) is the third generation mo-bile system. The organizational partners of the Third Generation Partnership Project(3GPP) cooperate in specifying UMTS. It is based on an evolved GSM core network anda completely new radio access technology. The current partners forming 3GPP are: Euro-pean Telecommunications Standards Institute (ETSI), Committee T1, TelecommunicationsTechnology Association (TTA), Telecommunication Technology Committee (TTC), Associ-ation of Radio Industries and Businesses (ARIB) and China Wireless Telecommunication

Standard (CWTS).Since several specifications for UMTS are still subject to further development and discus-sion, it is here stated that Release 99 (issued in March 00) is used and all implementationdetails refer to this issue unless otherwise stated.

1.1 Contribution

The aim of this diploma thesis is analysis and evaluation of TCP/IP performance overUMTS packet switched data services and is restricted to an FDD mode radio interface and

1


12/99

CHAPTER 1. INTRODUCTION 2

its related transmission formats.

End-to-end performance of packet switched data has been evaluated in detail for TCP

connections. Careful attention has been given to the interaction of TCP/IP with UMTSpacket switched data modes and services.

Performance analysis of TCP throughput and the behavior of the TCP/IP protocol stackfor various UMTS transport services and traffic scenarios is performed on a simulation-based UMTS model environment. The UMTS model developed for this thesis supportsvarious configurations and uses a simple block error model as the channel model.

UTRAN Protocol Architecture

This chapter explains the basic functions of the protocols defined for UMTS terrestrial

radio access. The functions include header compression of transferred user data, errordetection and error correction on the radio interface and dynamic allocation of resourcesfor multi-user scenarios.

TCP/IP Protocol Stack

After a short overview on the header structure of TCP/IP, detailed information on TCPand IP is given. Flow control and known limitations of TCP are described and illustrated.Three versions of TCP implementations are presented and compared against each other.

Further sections are dedicated to influences of UMTS packet switched data transmission

on the behavior of TCP.

Simulation Environment

The used simulation tool and its structure is shortly described here. The used models forUTRAN protocols and TCP/IP are visualized with detailed descriptions of their generalfunction and parameters.

Investigation of Transport Services

This chapter shows the simulation results performed for five different UMTS transportservices. The maximum TCP throughput is evaluated for different scenarios of losses onthe radio interface and the external packet data network.

The influence of TCP/IP header compression is illustrated for the 64 kbit/s transportservice.

Different traffic scenarios, including multiple FTP downloads and simultaneous FTP up-and download have been simulated for the 384 kbit/s transport service. Another simulationshows achievable TCP throughput for HTTP traffic scenarios with a single client and withtwo clients, operating simultaneously.


13/99


Summary and Conclusions

After a review of the most important insights of this thesis, conclusions are drawn aboutpractical applicability and limitations of different modes and services of UMTS packetswitched data transmission for use with TCP/IP. Requirements for future TCP implemen-tations conclude this thesis.

1.2 UMTS Architecture

The UMTS network is divided into two functional parts: A Core Network (CN) and anAccess Network (AN). A UMTS Terrestrial Radio Access Network (UTRAN) performs theterrestrial mobile radio access to User Equipments (UE) (see Fig. 1.1).

UE UTRAN CN

Uu Iu

Figure 1.1: UMTS functional parts

The radio interface uses Direct Sequence Code Division Multiple Access (DS-CDMA) withtwo duplex modes: Frequency Division Duplex (FDD) and Time Division Duplex (TDD).

UMTS offers packet switched data transport services (defined in[TS25.944]) with data ratesof up to 2048 kbit/s.

UMTS packet switched data services support various transport protocols like the Trans-mission Control Protocol (TCP, specified in [P81b]) together with the Internet Protocol(IP, specified in [P81a] and [DH98]) for connections to the Internet and other packet datanetworks.

The UMTS core network in Release 99 is logically divided into a Circuit Switched Do-main (CS) and a Packet Switched Domain (PS) as shown in Fig. 1.2 [TS23.101]. Theprotocols and interfaces used are GSM Phase 2+ compliant and defined in [TS22.060] and[TS23.060]. Packet switched nodes as Serving GPRS Support Node (SGSN) and GatewayGPRS Support Node (GGSN) have to be enhanced to support higher data rates in thepacket switched domain.

Section 1.3 describes a core network protocol architecture currently under investigation,using ATM connectivity within the core network for the packet switched domain. Thisconfiguration is suggested in [TS25.401].

Release 00 however, is expected to contain an All IP Network without any need for a CSdomain. All Types of Services (voice, data, video, etc.) will be transmitted and routedusing the PS services and capabilities.

The UMTS Architecture used for this thesis is shown in Fig. 1.3. A UE is connected toUTRAN over the Radio Interface Uu. It has radio connections to one or more NodeBs


14/99


SGSN

CN

RNC

RNC

RNSRNS

RNCNodeB

RNC

NodeB

GGSN

UE UTRAN CN

Uu

Iub

Iur

IuPS

Iub

Uu Iu

UE

GMSC

IuCS PSTN

Gn

Gi

Gp

PSTN

PSTN

CS

PS

MSC

Figure 1.2: UMTS circuit switched and packet switched domain

RNC

RNC

RNS

RNS

RNCNodeB SGSN

RNC

NodeB

GGSN

CN

UE UTRAN CN

Uu

Iub

Iur

IuPS

IubPacket

Data

Network

Uu Iu

PDN TE

TEUE

Figure 1.3: UMTS architecture (PS domain)


15/99


(UMTS Radio Transceiver Stations) and logical connections to a Radio Network Controller(RNC). One or more radio network controller together with their related NodeBs form a

Radio Network Subsystem (RNS) which is connected to the core network via the IuPSinterface.

Within the Core Network SGSN holds interconnections to other Public Land Mobile Net-works (PLMN) and GGSN interconnects to Packet Data Networks (PDN) like the Internet.

1.3 UMTS Protocol Architecture

The UMTS protocol stack (Release 99) is shown in Fig. 1.4. ATM transport technologyis used in UTRAN and for the Iu interface. ATM is capable of supporting various and

especially high data rates. Additionally an inherent support to meet stringent Quality ofService (QoS) requirements and scalability is provided.

Figure 1.4: UMTS protocol stack (PS domain)

The scenario in Fig. 1.4 shows a UE that established a TCP connection to a TerminalEquipment (TE) connected to an external packet data network (PDN).

TCP (Transmission Control Protocol, see Section 3.2) controls end-to-end transmission ofuser data, thus one entity of the TCP protocol stack can be found on both the UE andTE.

IP (Internet Protocol, see Section 3.1) performs addressing of network nodes and routing(forwarding) of IP datagrams. IP protocol stacks are necessary not only on the respectivetransmitting and receiving nodes, but also on all nodes, where routing is needed to deliverIP datagrams to a specific branch of a network, especially for the dynamically changingnetwork configurations of mobile users (handover, roaming).

PDCP (Packet Data Convergence Protocol, see Section 2.1) ensures proper framing of IPdatagrams and provides optional header compression capabilities. Framing information is


16/99


needed only on the radio interface Uu to distinguish between different other network layerprotocols beside IP.

RLC (Radio Link Control, see Section 2.2) provides different modes for transmission ofhigher layer data over the radio interface, including error detection and error recovery.

MAC (Medium Access Control, see Section 2.3) is used to share resources on transportchannels.

Service Data Units (SDU) are exchanged between a protocol layer and its respective higherlayer. The exchange point to a higher layer is called Service Access Point (SAP). ProtocolData Units (PDU) are generated in the protocol and are transferred to and received fromthe lower layer (see Fig. 2.1 for illustration).

IP packets are tunneled between nodes SGSN and RNC using the GPRS Tunneling Protocol(GTP-U) over the User Datagram Protocol (UDP [P80]). UDP/IP is handed down toATM using ATM Adaption Layer 2 (AAL2) on NodeB and RNC, ATM Adaption Layer 5(AAL5) on RNC and SGSN respectively. End-to-end addressing and routing is achievedin user IP packets, whereas local addressing of SGSN and RNC is expected to be achievedby means of UDP/IP below GTP-U and ATM addressing.

A Controlling Radio Network Controller (CRNC) controls logical connections to a UE,whereas a Serving Radio Network Controllers (SRNC) actually provides the connectionsvia its NodeBs. SRNC and CRNC can be one RNC entity, as shown in Fig. 1.4. SRNCand CRNC can be separated in case of handover scenarios given in [TS25.401].

All UTRAN data transmission related protocol entities are sited on UE and the counterparton SRNC/CRNC. They are described in more detail in Chapter 2.

Since the shared medium must be transparent between all related UEs and SRNC/CRNCan additional framing protocol between SRNC/CRNC and the actual transceiving NodeBsfor multiplexing is needed to transmit certain channel data to NodeBs. Dedicated framingprotocols for shared channels are defined in [TS25.401]. Figure 1.4 shows the framing ofthe Common Packet Channel (CPCH) with a specified Common Packet Channel FramingProtocol (CpchFP) over AAL2.


17/99

Chapter 2

UTRAN Protocol Architecture

The UTRAN protocol architecture is logically divided into Control Plane and User Plane.All control functions like resource management, call establishment and instantiation ofdata transmission protocols entities are performed by protocols belonging to the controlplane. User plane protocols are responsible for actual transmission of user data. An overalldescription is given in [TS25.401].

All UTRAN related issues belong to the Radio Network Layer. The Transport NetworkLayer incorporates all transport technology used for UTRAN, but without specific UTRANrequirements.

A Radio Access Bearer (RAB) uses a specific radio access scheme to transmit data. A single

UE may have multiple RABs. A Radio Link is a logical association between a single UEand a single UTRAN Access Point and consists of one or more radio bearer transmissions.The UTRAN access point is unique for one cell. It is the UTRAN-side end point of a radiolink.

This thesis is restricted to simulation of user plane protocols. All simulations start ata point, where control plane protocols finished all connection setup and instantiation ofneeded resources. Especially all dynamic relocations of RNCs/RNSs are omitted.

In the following sections the UTRAN protocols will be described in more detail. The entireprotocol stack has already been shown in Fig. 1.4.

2.1 Packet Data Convergence Protocol

The Packet Data Convergence Protocol (PDCP [TS25.323]) transfers data packets from andto the network layer in a transparent way, thus ensuring the operability of a wide range ofnetwork layer protocols over UMTS. Figure 2.1 gives an overview of the interconnections toother protocols. In Release 99, the supported protocols are IPv4 and IPv6. Every RadioAccess Bearer (RAB) is connected to one PDCP entity and one PDCP entity is connectedto one RLC entity.

7


18/99

CHAPTER 2. UTRAN PROTOCOL ARCHITECTURE 8

It provides functions that improve channel efficiency, standardized IETF header compres-sion algorithms are specified. In general the following functions are performed:

Transfer of user data.

TCP/IP and UDP/IP Header Compression and Decompression.

Buffering of transmitted PDCP SDUs and sequence numbering used for lossless SRNSrelocation1.

Release 00: Multiplexing of RABs onto one RLC entity.

IP

RLC

MAC-

c/sh

IP

RLC

UE Uu IubNodeB CRNC/SRNC

PDCP

MAC-

c/sh

PDCP

MAC-d MAC-d

PDCP SDU

PDCP PDU

PDCP SDU

PDCP PDU

Figure 2.1: PDCP service

The header compression method is chosen upon the network layer protocol type by RadioResource Control (RRC). Any signalling between compressors and decompressors duringdata transmission is carried out in the user plane.

In order to distinguish multiple different header compression types and to process userdata packets with the correct compression method, a Packet Identifier (PID) is assignedto each PDCP Protocol Data Unit (PDU). The assignment of PID values in Release 99 isshown in Tab. 2.1.

The PID is conveyed in the header field of each PDU. It defines the used optimization

method for the PDCP peer entities. Any PID value not defined upon setup shall invalidatethe PDU and it is discarded.

There are two formats of Protocol Data units defined with PDCP. PDCP No-Header PDU,which introduces no overhead to the PDCP SDU, and PDCP Data PDU, which holdscompressed or uncompressed user data in PDCP SDUs and a PID to distinguish thecompression algorithm.

1Lossless SRNS relocation allows forwarding of PDUs from an old SRNC to the target SRNC duringrelocation procedures. A more detailed description can be found in [TS25.323, Section 5.5].


19/99


PID value Optimization method Packet type

0 No header compression -

1 RFC2507 Full header2 RFC2507 Compressed TCP3 RFC2507 Compressed TCP non-delta4 RFC2507 Compressed non TCP5 RFC2507 Context state6 Method A Uncompressed TCP/IP... ... ...

Table 2.1: PID value allocation

PDCP PDU

PDCP SDU

IP TCP User Data

PID User DataCH

Figure 2.2: PDCP SDU and PDU

2.2 Radio Link Control

Radio Link Control (RLC) is specified in [TS25.322]. Figure 2.3 gives an overview of theconnections to other protocols. There are three modes for data transmission available withRLC. Transparent Mode Data (TrD) allows data transmission without introducing anyoverhead. Unacknowledged Mode Data (UMD) and Acknowledged Mode Data (AMD) addoverhead but also introduce several functions including error detection/correction and flowcontrol. Details on the latter two modes are given in Sections 2.2.1 and 2.2.2.

Radio Link Control in general supports the following functions:

Segmentation and reassembly of higher layer SDUs.

Concatenation

Padding

Transfer of user data.

In-sequence delivery of higher layer SDUs.

Error detection (UMD)

Error correction (AMD)


20/99


Duplicate Detection (UMD/AMD)

Ciphering

IP

MAC-

c/sh

IP


PDCP

MAC-

c/sh

PDCP

MAC-d MAC-d

RL C RL C

RLC SDU RLC SDU

RLC PDU RLC PDU

Figure 2.3: RLC service

The length of RLC PDUs depends on the Transport Formats (TF) and Transport FormatCombinations (TFC). It is negotiated upon setup and during connection by Radio ResourceControl (RRC). Its length is not necessarily a multiple of 8 bits. Incoming RLC SDUs areof arbitrary size and thus a Segmentation and Reassembly Mechanism is implemented inRLC to fit the data into RLC PDUs.

RLC SDU

IP T CPPID

RLC PDU

S N LI

User Data

RLC PDU

SN

RLC PDU

S N LI

RLC SDU

IP TC PPID User Data

IP T CPPID IP TCPPID Pad

Figure 2.4: RLC segmentation and concatenation

Figure 2.4 shows a typical process upon reception of higher layer SDUs. The first SDU issegmented and inserted into two PDUs. The second SDU is concatenated with the firstSDU into the second PDU.

The last field in the third PDU Pad refers to an unused space, known as padding.Padding is necessary, because RLC PDUs need to have fixed sizes to fit into a MAC PDU(see Section 2.3).

There are two PDU formats defined. Data PDUs carry actual user data received in RLCSDUs in one of the three known modes TrD, UMD or AMD. Control PDUs can be of typeSTATUS, where one entire PDU or piggybacked status information on a data PDU can beused. Other types are RESET and RESET ACK for peer-to-peer entity re-initialization.


21/99


2.2.1 Unacknowledged Mode Data, UMD

Figure 2.5 shows the model of unacknowledged mode peer entities.

ransm.

M-Entit

Transmission

buffer

M-SAP

eceiver

M-Entit

Receiver

buffer

M-SAP

adio Interface

Segmentation &

Concatenation

Ciphering

Add RLC header

Reassembly

Deciphering

Remove RLC

header

CCH/DCCH/

TCH/SHCCH

TCH

CCH/DCCH/D

CH/ SHCCH

TCH

Figure 2.5: UMD peer entities ([TS25.322, Figure 4.3])

SDUs are received by the transmitting entity through the Unacknowledged Mode ServiceAccess Point (UM-SAP). They are then segmented into pieces of appropriate length andinserted into PDUs. Higher layer SDUs will be concatenated in PDUs, if possible.

After ciphering of SDU data, the RLC header is generated and added to the PDU. It isstored in a transmission buffer where RLC PDUs are deployed to the MAC sublayer uponrequest.

RLC header information includes a PDU Sequence Number with range 27 (0 .. 127) andLength Indicators (LI), which indicate the end of one or more higher layer SDUs withinthis PDU.

PDUs are received and stored in a receive buffer through one of the logical channels fromthe MAC sublayer. RLC header data is removed and user data is deciphered. Reassemblyrebuilds higher layer SDUs and delivers them to PDCP.

If UMD should detect loss of PDUs, higher layers are informed by RLC. Duplicated orcorrupted PDUs received from MAC sublayer are discarded and the loss is signalled.


22/99


2.2.2 Acknowledged Mode Data, AMD

Figure 2.6 shows the model of acknowledged mode peer entities.

Transmission

buffer

Retransmission

buffer &

mangement

MUX

Set fields in RLC Header (e.g. set

poll bits).

RLC Control Unit

Receivedacknowledgements

Acknowledgements

CCH/

TCH*

AM-SAP

CCH/

TCH**

CCH/

TCH**

AM-Entity

Demux/Routing

CCH/

TCH*

CCH/

TCH**

CCH/

TCH**

Receiver buffer &

Retransmission

management

ransmitting Side eceiving Side

Segmentation/Concatenation

Ciphering

Add RLC header

Reassembly

Deciphering

Remove RLC header & Extract

Piggybacked information

Piggybacked status

Optional

Figure 2.6: AMD peer entities ([TS25.322, Figure 4.4])

SDUs are received here through an Acknowledged Mode Service Access Point (AM-SAP).The SDUs are segmented into one or more PDUs if necessary and concatenated if possible.

The length of a protocol unit is a semi-static value, which is negotiated during connectionsetup or through dynamic reconfiguration of the Transport Format Combination by RRC.

To determine the end of an SDU a Length Indicator (LI) is inserted into this PDU. Thereis one LI for every end of an SDU in a PDU. It is inserted at the beginning of a PDU.Sequence numbering is also used here with sequence number range 212 (0 .. 4095).

Padding can be replaced by piggybacking status information, allowing almost continuousmessage exchange between transmitting and receiving RLC entity. This guarantees all


23/99


state information to be consistent and up to date.

PDUs are placed into a Transmission Buffer and a Retransmission Buffer, excluding pig-

gybacked status information. Excluding the status reports is necessary, since retransmittedout-of-date status information will seriously harm consistency of state variables in bothentities.

The Multiplexer (MUX) afterwards decides, which PDU has to be delivered to MAC andschedules the time of transmission. Scenarios are possible, where control PDUs are for-warded to another logical channel than data PDUs. The broad dashed lines in Fig. 2.6illustrate this case. The retransmission buffer receives acknowledgements from the receiver,indicating already ACK-ed packets, which can be deleted from the retransmission buffer.

Every sent packet also has its own retransmission timer, ensuring loss-free retransmissionof packets in case of late or no status information updates due to corrupted control PDUs

or protocol errors.A function implemented for simulation is the use of a timer for Periodic Poll, which pollsthe counterpart peer entity of RLC every 3 seconds for an update of status information,ensuring consistency when recovering from protocol errors.

The transmission of status information (RLC Status Reports) is triggered by several con-ditions during data transmission. The available trigger conditions for exchange of reportsis negotiated by RRC upon setup. The receiver should always send a status report whenreceiving a poll request. The following triggers are available:

Detection of one or more PDUs missing (Negative Acknowledgement NACK).

Timer based transfer of status information.

Estimated PDU Counter (EPC) mechanism (described in the following).

The Estimated PDU Counter (EPC) is used for scheduling the retransmission of statusreports at the receiving entity. The receiving entity will send a new status report, requestingPDUs not yet received. Subsequent status report retransmissions are not equally spacedin time, but controlled by this counter. It is started at transmissions of STATUS PDUs. Ifnot all PDUs requested for retransmission have been received before the EPC has reached

zero, a new status report is transmitted. EPC adapts the retransmission timeout to thecurrent bit rate indicated in the Transport Format Indicator (TFI) in order to minimizedelay of status report retransmissions.

The EPC is decremented every Transmission Time Interval (TTI, see Tab. 2.3) with theestimated number of PDUs that should have been transmitted during that TTI. If PDUsare missing, the receiver generates a status report (NACK) and sets EPC to the numberof requested (missing) PDUs.

When EPC reaches zero and not all of the previous requested PDUs have been receivedcorrectly, a new status report is generated and EPC is set accordingly.


24/99


2.3 Medium Access Control

Medium Access Control (MAC) is specified in [TS25.321]. MAC entity functions are dif-ferent for UE and UTRAN.

IP

MAC-

c/sh

IP


PDCP

MAC-

c/sh

PDCP

RLCRLC

MAC-dMAC-d

MAC SDU MAC SDU

MAC PDU MAC PDU

Figure 2.7: MAC service

Following entities are defined for FDD mode:

Medium Access Control - broadcast (MAC-b): MAC entity handling theBroadcast Channel (BCH). There is one MAC-b entity in each UE and one MAC-bin UTRAN for each cell.

Medium Access Control - common/shared (MAC-c/sh): MAC entity han-dling the Paging Channel (PCH), the Forward Access Channel (FACH), the RandomAccess Channel, the Uplink Common Packet Channel (UL CPCH) and the Down-link Shared Channels (DSCH). There is one MAC-c/sh entity in each UE and oneMAC-c/sh in the UTRAN for each cell.

Medium Access Control - dedicated (MAC-d): MAC entity handling dedi-cated logical channels and Dedicated Transport Channels (DCH) allocated to a UE.There is one MAC-d entity in each UE and one MAC-d entity for each UE in theUTRAN. It is also responsible for selecting a Transport Format Indicator (TFI) and

Transport Format Combination Indicator (TFCI) to be used in each TransmissionTime Interval (TTI) when dynamically sharing resources between bearers supportedby a UE.

MAC entities perform several functions on both UE and UTRAN side:

Mapping between logical and transport channels

Selection oftransport format for each transport channel depending on instantaneoussource rate


25/99


Priority handling between data flows of one UE, between UEs with dynamic schedul-ing, between data flows of several users on the DSCH and FACH

Identification of UEs on common transport channels. Note, that identification is notused for end-to-end addressing but is resolved by MAC multiplexer and demultiplexerand is dynamically allocated and negotiated by RRC.

Multiplexing of higher layer data into transport blocks delivered to the physical layeron common transport channels and vice versa.

Multiplexing of higher layer data into transport block sets delivered to the physicallayer on dedicated transport channels and vice versa.

Traffic Monitoring

Dynamic switching of Transport Channel type

Ciphering of TrD RLC (not provided by RLC, see Section 2.2)

Access Service Class (ASC) selection for RACH and CPCH transmission.

MAC PDUs are bit strings with length not necessarily a multiple of 8 bits. Dependingon the provided and negotiated transport service, MAC SDUs are bit strings with anynon-null length and is included into MAC PDUs from first bit onward.

All PDUs delivered to the physical layer in the UE for uplink within one TTI are definedas Transport Block Sets (TBS). A TBS consists of one or more transport blocks, eachcontaining one MAC PDU.

The order of delivery shall be adopted from the order of reception of SDUs from RLC. Thesame goes for multiplexing multiple RLC PDUs from different logical channels.

MAC PDUs consist of an optional MAC header and one MAC SDU. There are severalfields defined for the MAC header. The Target Channel Type Field (TCTF) providesidentification of logical channel classes (BCCH, CCCH, ...) on FACH and RACH channels.The Channel Type Field (C/T) is used to provide identification of logical channel instances,channel types on dedicated transport channels and data transmission over FACH andRACH, respectively. The MAC header used in further simulations is 4 bits (C/T), andused on DTCH and DCCH which are mapped to DCH.

A C/T field with all bits set as shown in Tab. 2.2 is reserved and the current version ofthe protocol will discard MAC PDUs with this C/T type.

RLC has to provide RLC PDUs to MAC, which fit into the available transport blocks onthe transport channels. This is described in Section 2.2.

The transmission formats used for simulations in this thesis are shown in Tab. 2.3 andare examples taken from [TS25.944]. Cyclic Redundancy Check (CRC) is applied to each


26/99


C/T field Designation

0000 Logical channel 1

0001 Logical channel 2... ...

1110 Logical channel 151111 reserved

Table 2.2: C/T field structure

Transport service Transport block Set size CRC TTI

12.2 kbit/s 244 bit 1 12 bit 20 ms64 kbit/s 1280 bit 1 16 bit 20 ms

144 kbit/s 2880 bit 1 16 bit 20 ms384 kbit/s 3840 bit 1 16 bit 10 ms

2048 kbit/s 4096 bit 40 16 bit 80 ms

Table 2.3: Channel coding and transmission format

Transport Block. The only exception is the 12.2 kbit/s transport service, where the 12-bit CRC is only attached to Transport Block Segment #1. The used Transmission TimeInterval (TTI) is a multiple of the basic Radio Frame duration of 10 ms.

The used 12.2 kbit/s transport service can be applied to Adaptive Multi-Rate (AMR)speech transmission over packet switched data services. Another possible use is the useof 12.2 kbit/s for uplink in highly asymmetric scenarios, like with HTTP Clients runningon UEs (Web Surfing). The 64 kbit/s and 144 kbit/s transport services will be used forinteractive applications with demand for multimedia data transmission at moderate datarates. These transport services may also serve as the backward path of highly asymmetricdata transmissions.

384 kbit/s is used for highly interactive multimedia applications. 2048 kbit/s is defined forhigh data rate multimedia applications.

2.3.1 MAC-c/sh

Medium Access Control - common/shared (MAC-c/sh) entities provide mapping betweenlogical and transport channels and handling of the TCTF field in the MAC header. TCTFindicates also the logical channel type.

If a dedicated logical channel is used, MAC distinguishes between UEs by the UE Id fieldin the MAC header.

It is possible to use transport format selection in the uplink. If a CPCH is used, a transportformat is selected out of a transport format set determined from status information on theCSICH.


27/99


Scheduling and priority handling is used to transmit information received from MAC-d onRACH and CPCH. In order to prioritize transport channels, Transport Format Combina-

tion Selection can be performed. A Channel Transport Combination is then selected outof a negotiated set of TFCs. The negotiation is done by RRC.

Figure 2.8: UE side MAC architecture

2.3.2 MAC-d

Medium Access Control - dedicated (MAC-d) entities perform several functions, includingDynamic Transport Channel Type Switching based on RRC decision. Further functions in-clude multiplexing of dedicated logical channels, with C/T header field in their packets set,onto appropriate transport channels and downlink mapping of dedicated logical channelsonto common and dedicated transport channels.

One dedicated logical channel can be mapped simultaneously onto DCH and DSCH. AMAC-d entity using common or downlink shared channels is connected to a MAC-c/shentity that handles data reception on UE-assigned common channels. See Fig. 2.8 for

illustration of this interconnection.

The UTRAN side architecture of MAC-d is similar and differs only by the way MAC-c/shand MAC-d are interconnected. In case SRNC/CRNC are separated, this interconnectionis obviously not local, but established via the Iur interface (see Fig. 1.3).


28/99

Chapter 3

TCP/IP Protocol Stack

Transmission Control Protocol (TCP) / Internet Protocol (IP) is an entire protocol suitecovering OSI layers 3 and 4. It evolved from ARPANET, an ancestor of the Internet,connecting US Universities in the early 1970s and replaced the original Network ControlProgram (NCP) protocol. Rising popularity of the Internet spread this protocol suite allover the world. Its ease of implementation and the continuous research and investigationson its behavior lead to an ongoing increase of performance with every new (backwardcompatible) version.

IP in its current version 4 (IPv4) is able to address 232 different network nodes. IPv6expands the address range to 128 bits (2128 nodes).

TCP typically adds a 20 byte header structure to user data and IP adds another 20 bytes.Thus the minimum header size for non fragmented TCP/IP packets is 40 bytes. Both IPand TCP provide 16-bit checksum fields covering different areas for error detection.

3.1 IP

IP is a network layer protocol (OSI layer 3). It provides functions like datagram deliveryservice, addressing and fragmentation. IP Versions 4 and 6 are defined in [P81a] and[DH98], respectively. An IP Datagram is the basic unit of a TCP/IP data packet. It

consists of an IP header and user data. The minimum length of the IP header field is 20bytes. A minimum TCP/IP header is shown in Fig. 3.1.

The maximum length of an IP datagram is 65,535 bytes (octets). The IP layer on inter-mediate gateways may fragment datagrams during transmission. This implies, that thereceiving side must be capable of reassembling a datagram before it is processed and userdata is handed up to higher layers. All IP hosts are required to support and process IPdatagrams of sizes up to 576 bytes without fragmentation.

Datagram fragments contain almost identical headers, which are basically copies of theoriginal header with only few modifications, and user data. Fragments are treated asnormal IP datagrams during transmission.

18


29/99

CHAPTER 3. TCP/IP PROTOCOL STACK 19

Figure 3.1: TCP/IP header field


30/99


Since IP provides only unreliable datagram service, the entire IP datagram is consideredcorrupted and is discarded by the receiver, if one or more fragments are lost or corrupted

during transmission.The first 20 octets in Fig. 3.1 form the IP Header:

Protocol Version: Current version is 4 (IPv4) and 6 denotes IPv6. Besides 4 and6 only 5 (experimental) is defined.

Header Length: Length of IP Header counted in 32-bit quantities excluding userdata field.

Service Type: Indication of the Quality of Service requested for this datagram.

Total Length: Total length in bytes of this datagram, including header.

Identification: Unique number assigned by the sender. Used for reassembly in thereceiver. All fragments of a datagram carry the same Identification.

Flags: Dont fragment (DF) and More Fragments (MF) used for fragmentationprocessing.

Fragment Offset: Offset of user data in this fragment given in 64-bit pieces.

Time to Live: Denotes the time in seconds, that a datagram can be in transitincluding all processing effort. Most routers, however, will process and deliver data-grams in fractions of seconds nowadays. TTL now is a hop-count metric rather thana time metric. It is decremented at every router the packet travels through. When itreaches zero the packet is assumed to be running in some closed loop and discarded.

Protocol Number: Indicates the higher layer protocol. TCP has protocol number6, UDP 17, ICMP has 1. Even for IP a number, 4, is assigned for IP encapsulationtechniques.

Header Checksum: This header checksum covers the header area only and doesnot extend onto the user data area. It is calculated as the 16-bit ones complement ofthe ones complement sum of all 16-bit words in the IP header. While calculating thechecksum this field is considered all zero for obvious reasons. A checksum mismatchdiscards a packet.

Source IP Address: 32-bit identification number of the network node the data-gram originated from. A more human-readable format is the dotted-decimal formatconvention, where each dot-delimited section refers to one byte of the 32-bit number.A valid IP Address therefore could be 128.131.67.83.

Destination IP Address: 32-bit identification number of the target network nodeof the datagram.


31/99


An IP Options field of variable length, following the basic header fields may contain furtherinformation for all IP layers, passed during the transmission and forwarding of this packet.

The maximum IP header length including options can be 60 bytes.When crossing different gateways and networks, IP datagrams may get fragmented due torestrictions in maximum frame sizes these networks are willing to handle. The MaximumTransmission Unit (MTU) quantizes this parameter. IP requires each link to be capableof offering a minimum MTU of 68 bytes. IP implementations are not required to han-dle unfragmented IP datagrams larger than 576 bytes. However, most implementationsnowadays offer MTUs of 8192 bytes or higher and almost all a minimum of 1500 bytes.

If fragmentation is necessary, the corresponding flags and offsets will be set in the datagram.Since IP fragments may travel to their destination using different routes in some cases,the receiver must be capable of reassembling the original IP datagram, even if fragments

overtake each other or in case of duplication (cloning) of datagrams by gateways.Fragments can even be subject to further fragmentation, if the MTU of a used networkpath requires this. Modern TCP implementations use MTU Path Discovery techniques toavoid fragmentation by setting the datagram size in a way, that the whole IP datagrampasses through all gateways unfragmented.

3.2 TCP

The Transmission Control Protocol (TCP) is a transport layer protocol (OSI layer 4). It is

specified in [P81b]. TCP adds a 20 byte header structure (without options) to user data.TCP provides error recovery, flow control and reliable data transmission over unreliabletransmission media. TCP is a connection-oriented protocol unlike the User Datagram Pro-tocol (UDP) which is connectionless . Connection-oriented means, that both entities of theprotocol related with the transmission of user data (transmitter and receiver) have knowl-edge of each others state condition. They are exchanging data not only in the forward butalso in the backward direction (acknowledgement traffic). Connection-oriented protocolsrequire exchange of data to set up a connection, do actual data transfer and undergo awell-defined release procedure.

Most of todays application protocols like TELNET, FTPand HTTPrequire lossless trans-

mission of user data and make use of TCP.TCP provides a byte-stream connection, sequence numbering every byte in the stream.This contiguous stream of data is divided into TCP segments prior to transmission.

TCP is a so-called self-clocking protocol, adapting the senders rate to the offered band-width. TCP sends one or more segments only, if prior ACKs from the receiving side havereached the transmitter. The only exception are timeout-based retransmissions.

The second 20 bytes (20 .. 39) in Fig. 3.1 form a TCP header structure:

Source Port: 16-bit source port number, used for replies.


32/99


Destination Port: 16-bit destination port number indicating the port at the re-ceiver where this segment is delivered to.

Sequence Number: Indicates the byte number of the first byte of user data in thissegment.

Acknowledgement Number: Indicates the next sequence number, the receiver iswilling to accept (only used if ACK flag set).

Data Offset: Offset of user data in this segment. This indicates the size of the TCPheader including options.

URG: Indicates that the urgent pointer field carries relevant data.

ACK: Indicates that the acknowledgement field carries relevant data.

RST, SYN, FIN: Used as indicators for reset, synchronization and end of trans-mission state messaging between the two peer entities, and used during setup andrelease of a TCP connection.

Window: Specifies the number of bytes which the sender of this segment is willingto accept, beginning with the one indicated in the acknowledgement field.

Checksum: This checksum covers header and data fields and is calculated as theones complement sum of all 16-bit words in a pseudo-header, the TCP header and

the user data. The Checksum field is considered all zero during calculation. Thepseudo-header used in this calculation covers IP information and consists of SourceIP Address, Destination IP Address, the Protocol Type and TCP length.

TCP Options are defined like IP Options. They are of variable size and format. One optionexists for agreeing upon the Maximum Segment Size (MSS) the peers are willing to handle.Another important option is the TCP Window Scale Option. See also Section 3.2.6.

The first TCP implementation available was TCP Tahoe, offering basic flow control andtimeout-based retransmissions. It was followed by TCP Reno, which provides more so-phisticated congestion avoidance mechanisms, and TCP Vegas with newer functions likeWindow Scaling, Selective Acknowledgement (SACK) increasing performance while main-taining Renos congestion avoidance.

3.2.1 Sliding Window

Since TCP is a self-clocking, or to be more exact, an ACK-clocked protocol, decision onwhether to send a segment is taken upon reception of ACKs from the receiving side. Thismay decline performance on lines with a large Bandwidth Delay Product(see Section 3.2.6)

A possible solution to this imperfection is to increase line efficiency by sending more seg-ments out onto the line without waiting for every particular segment to be acknowledged.


33/99


1 2 3 4 5 6 7 8 9

Window

1 2 3 4 5 6 8

Window

5678

ACK=6, WND=2

TCP

Receiver

TCP

Sender

Figure 3.2: Sliding window principle

This principle is illustrated in Fig. 3.2. A window containing four segments is used on bothpeers, enabling the transmitter to send four segments without waiting for an ACK for thesegment at the left edge of the transmission window. For reasons of clarification, segmentnumbers are used where byte-sequence numbers would be used in real implementations.A certain amount of segments is allowed to be sent without having to wait for their ac-knowledgement, thus filling the pipe. When ACKs arrive, new packets can be sent, thus

obtaining a continuous flow of data.TCP uses cumulative ACKs, indicating the last correctly received segment with its sequencenumber. In this case segment #7 is lost on the line or had to be discarded due to checksumerrors. The receiving side informs the sender, not only of a possible loss by (multiple)indicating only correct reception of segments up to #6, but also indicates, that it is willingto accept only two more new packets before the reception window closes. Since the receiverhas to hold out-of-band segments in a reception buffer, this prevents overflowing of thereceivers buffer and reduces unnecessary transmissions and occupied bandwidth on theline.

After some time, the sender will retransmit segment #7 and the receiver will send back

an ACK indicating correct received segments up to #8. It will also indicate a re-openedreceiver window. The sender can now slide its window three segments, allowing it to sendpackets #9 through #12.

The requirement for a TCP sender, of never sending more segments, than the receiver iswilling to receive, indicated through its receive window, makes it possible for the receiverto regulate the segment arrival rate by adjusting the senders transmission window.

3.2.2 Retransmission Timer

In case of corrupted or lost segments, the receiver will respond to all further well-received

segments with acknowledgements only indicating the last correctly received segment. Thesender will stop sending further segments since it reaches the right edge of its transmissionwindow.

However, the TCP sender started a retransmission timer for each outgoing segment andeventually a timeout will occur.

The further behavior, on whether to send just the missing segment or all segments fromthat point on, is subject to the implementer. Resending just one segment and waiting forfurther timeouts in case of multiple losses, or resending all segments within the currentwindow - whatever strategy is used, maximum throughput is lost.


34/99


35/99


36/99


3.2.4 Fast Retransmit and Fast Recovery

The major problem of timeout-based retransmissions is the possible loss of ACK clocking.This happens, if all ACKs reach the sender before timeouts occur. This is called drainingof the pipe and fatally decreases performance.

Fast Retransmitis a heuristic that is capable of retransmitting dropped packets sooner thanregular transmission timeouts would do. This preserves the ACK Clock (see [AVS99]) incase of single dropped segments in a flight of segments. Fast retransmit is an enhancementto timeouts and does not replace them.

The idea behind fast retransmit is, that every time a duplicate ACK is received by thesender it not only indicates the loss of segments, but also that segments were received andhave left the network.

In practice, TCP waits for the reception of the third duplicate ACK and retransmits thesegment indicated lost by these ACKs. After that Fast Recovery governs the transmissionof new data until a new (non-duplicate) ACK arrives.

The threshold ssthresh, used by the sender to determine whether to use slow start orcongestion avoidance, is set to a value not larger than given in Eqn. 3.2.

ssthresh = max

Flightsize

2, 2MSS

(3.2)

Flightsize is the number of user data currently in flight, i.e. data conveyed in segmentsthat is not yet acknowledged. CWND is set to ssthresh plus 3MSS. This inflates thewindow by the number of segments that actually have left the network so far and whichthe receiver has buffered. Every duplicate ACK received after the start of fast recoveryinflates the window further by MSS for every ACK to reflect another segment that has leftthe network. TCP shall transmit new segments, if CWND allows that.

The first ACK that indicates new data acknowledged, triggers the deflating of the windowand CWND is set to the value at the start of fast recovery.

Figure 3.4 illustrates TCPs behavior. Upon reception of the third duplicate ACK TCPresends what appears to be the missing segment and lowers its CWND. The CWND risesrapidly to a point, where fast recovery detects new ACKs. Then the window is deflated.

Slow start is never entered here and this heuristic will keep the pipe filled and ACK clockingpreserved, reducing throughput much lesser than timeout-based retransmissions.

3.2.5 Delayed Acknowledgement

TCP Reno was the first implementation that introduced delayed acknowledgement in thereceiver. Acknowledgements are sent only for every other packet received, thus reducingtraffic in the backward direction. Another reason for introduction is increased efficiencyfor interactive traffic, where ACKs can be piggybacked on echoed characters.


37/99


384 kbps: CWND, RTO, RTT

RTTCWND

RTO

[MSS],[s]

Time[s]0.00

5.00

10.00

15.00

20.00

25.00

30.00

0.00 5.00 10.00 15.00 20.00

Figure 3.4: Fast retransmit and fast recovery

However, TCP receivers shall not delay ACKs more than 500 ms to prevent spuriousretransmissions of already received segments.

To keep accuracy of retransmissions high, TCP receivers shall also report received out-of-order segments or duplicate segments immediately back in ACKs, without any delaying.

3.2.6 Window Scaling for Long, Fat Networks

A link with a given bandwidth and delay has the following pipesize, i.e. the maximumamount of data in transit:

Pipesize[bits] = Bandwidth[bit/s] Delay[s] (3.3)

This is called the Bandwidth-Delay-Product. In case of not delaying ACKs at the receiver,it takes a minimum of two times a link delay, until an ACK for a previously sent segmentarrives at the sender. To make full use of the lines capacity, segments worth two times the

pipesize can be sent. If the window is lower, not the full capacity of the line is used. Asthe doubled delay equals the RTT, the limit in bandwidth is

Bandwidth[bit/s]max =Windowsize[bit]

RTT[s](3.4)

Paths with high bandwidth delay products are called long, fat pipes - networks containingthese paths long, fat networks (LFN).

The original TCP implementation provides handling of window sizes of up to 64 kbytes,which gives poor performance over some specific links (e.g. satellite links). Window Scal-


38/99


ing allows TCP to scale the original 16-bit window size value by another 16 bits and isperformed in a backwards compatible way during the initial handshake. Window scaling

is described in [JBB92] and is implemented in TCP Vegas .

3.3 Performance Issues and Influences

This section describes known and other possible performance influences of TCP/IP overUMTS packet switched data services.

3.3.1 IP Maximum Transmission Unit

The MTU size can not be seen isolated for the Uu radio interface, but has to be consideredfor configurations, where the counterpart TCP is on a Terminal Equipment (TE) outsideof the core network connected through a packet data network.

If RLC AMD is used, MTU is mainly an issue on the connected paths in public datanetworks, like the Internet. All RLC modes perform segmentation and concatenation ofhigher layer SDUs, thus providing nearly constant overhead, regardless of the SDU size.RLC AMD provides error-free transmission of SDUs and thus the influence of MTU sizeon performance is negligible.

Most links nowadays, including ATM, provide MTUs of 1500 bytes and more.

3.3.2 TCP Maximum Segment Size

TCP Maximum Segment Size (MSS) is closely related to MTU. Most implementationsallow a minimum of 64 byte for TCP/IP header information. Thus MSS must be smalleror equal (MTU 64) bytes to achieve one segment to be carried in one IP datagram.

An evaluation of the optimum including considerations about protocol overhead and seg-ment loss is given in [TA00]. Since MSS is also negotiated during connection setup anddepends on MTU size, no dynamic adaption can be achieved.

As modern TCP implementations use MTU path discovery to set MTU and negotiatea proper MSS, IP fragmentation mainly occurs on international lines with heavy loadswhere some packets get diverted and may take different routes, getting fragmented there(per-packet load balancing).

3.3.3 TCP Implementation

The TCP Implementation has the largest influence on performance. Since most UMTSpacket switched configurations, especially with higher data rates, can be seen as LFNs (seeSection 3.2.6), all implementations prior to TCP Reno like TCP Tahoe, relying just onretransmission timeouts perform poor.


39/99


TCP Reno performs well to a point, where multiple losses in a flight of packets corrupt thefast retransmitand fast recovery heuristic. TCP Reno also has no Window Scaling Option

implemented, running into the same troubles as TCP Tahoe as described in Section 3.2.6.TCP Vegas is expected to overcome all these limits. It not only provides window scaling,but also provides a more accurate measurement method of the RTT based on Time Stampsand uses Selective Acknowledgement (SACK) to trigger selective packets to be resent.

Clock granularity has a small influence on heavy congested or lossy paths, where manyretransmissions occur and accurate timing of retransmissions become important.

Another problem is the restart of transmissions on idle connections as discussed in [VH97].In case of persistent connections, like with HTTP, the TCP connection is not released aftertransmission but kept open for further transmissions. This may introduce large bursts ofdata on the network paths, since the last CWND is used for new transmission and the slow

start phase is omitted.This is proven to lead to diminished performance. A possible refinement to the originalTCP protocol implementation is to sense for a transmission pause. If this pause exceeds3RTO, slow start is invoked and CWND is lowered to one MSS for further transmission ofdata. The implementation of TCP in this thesis is using this mechanism.

The used window size also affects the minimum required queue size of RLC and interme-diate packet data network routers. This is especially true for lossless or nearly losslesssimulation scenarios, where CWND reaches its upper limit of 64 kbytes.

More packets are being induced into the network and are queued at RLC level or in routers.The resulting rise of the packet round trip time is smaller than the rise of the congestion

window, resulting in a rise of packets that have to be queued. The amount of queuedpackets stops to rise only if the congestion window reaches its upper limit and maintainsconstant.

Whether lossless transmission is a realistic scenario or not - this effect has to be kept inmind for simulation.

3.3.4 UMTS PDCP Header Compression

Header compression of TCP/IP headers increase throughput efficiency, thus increasing thefraction UserDataSize

TCPIPDataPacketSize

.

The compression algorithms defined in [J90] and [DNP99] encode only the changes to vitalprotocol fields. Other fields, that may change not so often or never during a connection,are maintained in local state variables.

A typical minimum TCP/IP header is 40 bytes long and is delta-compressed to 3 6 (!)bytes for typical FTP and TELNET scenarios.

The algorithm defined in [J90] is also known as Van Jacobson Header Compression. Itprovides no signalling between decompressor and compressor, thus relying totally on thebehavior of TCP. When transmitting new data, the compressor assigns this connection anID and transmits the segment unaltered. Only the ID carried in the protocol type field


40/99


41/99


42/99


43/99


loss here invalidate all advantages RLC AMD offers. See Chapter 5 for simulation resultsand further discussion. The influence of delay in the external packet data network affects

both RLC modes equally. Packet switched transport services with high data rates turninto long, fat networks (LFNs), if the additional delays introduced on these paths exceeda few 10 ms. Window Scaling is needed to make full use of the available bandwidth. Thepossible loss of multiple packets in one single flight of packets on large pipes gets higher,which affects TCPs Fast Retransmit and Fast Recovery.

This is a general problem of TCP in the Internet. But the high losses over the radio interfaceintensifies this problem. In GSM this was not an issue yet, because the bandwidth was nothigh enough.


44/99

Chapter 4

Simulation Model

4.1 Simulation Environment

The used simulation tool is Ptolemy Classic, Version 0.7.1 for Linux. It is a set of programs,developed at the University of Berkeley. It provides an X11 compatible graphical interfaceas well as a console-driven direct simulation of compiled universes. Ptolemy and all partsdeveloped for simulation are written in C++.

A simulation environment in Ptolemy is called universe, containing stars and galaxies .Galaxies are a number of stars linked together. There are several domains defined forsimulation. All simulation in this thesis is carried out in the Discrete Event (DE) domain.The events are triggered by particles traveling from star to star. The DE domain providesa general environment for time-oriented simulations of systems, such as communicationnetworks. A scheduler processes events in chronological order. Time intervals betweenevents are not fixed and Time Stamps are associated to each particle. Time stamps aregenerated by the star sending the particle. It is based on the time stamp of the receivedparticles and the latency of the block.

Data Units (SDUs, PDUs), used for inter-protocol communications, are objects of protocolclasses1. All protocols and their related data units are defined in these classes. The onlyexception is MAC, which uses RLC PDUs and a special property of RLC as its MACheader field.

4.2 Models

Around 20 different stars (classes) have been implemented in C++. The following subsec-tions give an overview and short insight of the most important stars. The latency of moststars is zero, i.e. processing a particle takes no simulated computation time. Delays that

1Class in this context means a C++ class.

34


45/99

CHAPTER 4. SIMULATION MODEL 35

represent processing of data units are explicitly inserted into simulations. The simulationmodel used in this thesis is shown in Fig. 4.1.

CN +

PDN

UE 2

RNC

UE 1

TCP / IP

RLC

PDCP

MAC-d

FTP

Server

TCP / IP

RLC

PDCP

HTTP

Client

TCP / IP

RLC

PDCP

HTTP

Client

RLC

PDCP

MAC-d

RLC

PDCP

RLC

PDCP

INT ERNET INTERNET INTERNET

TE1 TE1 TE1

TCP / IP

FTP

Server

TCP / IP

HTTP

Server

TCP / IP

HTTP

Server

CHANNEL

Figure 4.1: Simulation model

User data is generated in FTP Server Models or HTTP Server Models . FTP server modelsare used for evaluation of maximum TCP throughput performance and for observation ofTCPs behavior in scenarios with shared transmission resources. User data is segmentedinto packets of appropriate length for insertion into a TCP segment. HTTP server modelsput out a certain amount of user data. The amount is requested by HTTP Client Models.See Section 4.2.9 for a more detailed description on HTTP traffic modeling.

TCP segments enter the TCPIP Model, where a source port number and a destination portnumber is assigned. The TCP checksum is calculated and included into the TCP header.The TCP segments are inserted into one or more IP datagrams afterwards. A source anddestination IP address is assigned and the IP checksum is calculated before transmission.

The Internet Model does not alter the data structure. IP datagrams are only delayed ordiscarded as described in Section 4.2.7.

IP datagrams enter the PDCP Model, where the datagrams are either compressed or leftunaltered. However, the data structure changes. PDCP PDUs consist of a packet identifierand the output data of the compressor.

The RLC Model segments and concatenates the PDCP PDUs into RLC PDUs of appro-priate size and transfers the RLC PDUs into the transmission buffer and places a copyinto its retransmission buffer.

The MAC Model has its own set of buffers and demands RLC to flush the transmission


46/99


buffer every time transmission interval. It inserts RLC PDUs into MAC PDUs and appliesthe MAC header field.

A more detailed description of the queueing algorithm and prioritizing of MAC PDUs isgiven in Section 4.2.5.

The Channel Model transmits the MAC PDUs with a given loss probability.

4.2.1 TCP Model

The galaxy TCPIP, which includes other TCP related stars, is shown in Fig. 4.2. StarSliding Window incorporates a queue for incoming packets and deploys packets upon agiven limit (sequence number). TCPSender holds a retransmission buffer and has full TCPReno functionality. Additional features are window scaling, restart of idle connections and

a modified RTO calculation for high data rates over UMTS as described in Section 5.5.1.

Whenever packets are being transmitted, the corresponding sequence number leaves thestar and is fed back to the star at a delay of current RTO. Incoming timeout sequencenumbers simulate the retransmission timer and appropriate reaction can start. Otheroutputs are used for graphic visualization of CWND, RTT and RTO.

IPReceiver

outTcp

outUdp

outAck

Delay

TCPReceiver

inTcp

AckEnd

size

outAck

outTcp

AckStart

IPSender

SlidingWin

winSize

inData

outData

overflow

XMgraph

TCPSender

inACK

inTCP

inReTx

demand

outTCP

outReTx

mRTO

mCWND

mRTT

Figure 4.2: TCP/IP simulation model

Star TCPReceiver has three outputs. One is for received segments, one for generatedacknowledgements ready for transmission back to the sender and the third output is usedby the delayed acknowledgement mechanism. The segments leaving this output are delayedby 500 ms and fed back to the TCP receiver. Out-of-order data is immediately indicated


47/99


to the sender as described in Section 3.2.5. Piggybacking of ACKs onto data segments incase of direct TCP two-way traffic is not implemented.

Parameters available within TCP models are:

Version: Denotes the use of normal or modified RTO calculation.

Window Size: Specifies the maximum size of the transmit and receive window.

Window Scale Factor: Specifies the scale factor for the transmit and receive win-dow size.

MSS: Specifies the TCP Maximum Segment Size used for segmentation of user datastreams.

ACK Delaying: Specifies whether to use delayed acknowledgements or to acknowl-edge every incoming segment.

4.2.2 IP Model

The stars IPSender and IPReceiver in Fig. 4.2 are capable of processing TCP and UDPpackets and offer full IP datagram fragmentation implementation, if necessary. The receiverhas three outputs for received TCP data packets, TCP ACKs and for UDP datagrams.The only parameter is the IP Maximum Transmission Unit (MTU).

4.2.3 PDCP Model

The PDCP star performs framing and TCP/IP header compression modes defined in [J90],as well as unaltered (uncompressed) transmission of data for up to 256 different TCPconnections over one single line.

PDCP

inIP

inPDCP

outIP

outPDCP

Figure 4.3: PDCP simulation model

The maximum uncompressed SDU size is limited to 64 kbytes. Actual compression anddecompression is implemented for all cases related to the transmission of single data seg-ments or single ACK segments. Piggybacking is not implemented. The PDCP model hasonly one parameter, specifying whether to use header compression or not.


48/99


4.2.4 RLC Model

The RLC star covers the full functionality of RLC modes UMD and AMD. This starincorporates both sender and receiver. Three different queues are used for transmission,retransmission and receiver buffer. The size of this queues is variable. Overflowing a buffercauses RLC to discard the newest PDUs arriving at the queue ( drop tail mechanism).

RLC

inRLC

inDeployRLC

inPDCP

inTimer

outRLC

outPDCP

outTimer

Figure 4.4: RLC simulation model

RLC AMD uses periodic status report messaging as a backup system for the timer-basedretransmission mechanism as well as RLC PDU retransmission timeouts. The peer onthe far end is polled every 3 seconds, requesting a status report. The EPC mechanism,as described in Section 2.2.2, is not implemented. Received out-of-order RLC PDUs andmissing segments trigger an immediate status report (negative acknowledgement).

Like TCP, this star uses corresponding delayed sequence numbers which are fed back tothe star to trigger retransmissions.

Higher layer SDUs are segmented and concatenated into remaining PDUs in the transmis-sion buffer. After that, a copy is put into the retransmission buffer. Particles incoming at

inDeployRLC input trigger flushing of the transmission buffer and transmission of PDUsto MAC.

If RLC UMD PDUs are lost, RLC waits for a PDU with an indication for the beginning ofa new SDU, discarding the one in progress. An indication is the existence of one or morelength indicators (LI) in the header area of a RLC PDU.

A specific node-number is inserted upon transmission and checked upon reception of aRLC PDU, to be able to distinguish between different RLC entities. This represents theC/T field value in the MAC header.

Available parameters for RLC include:

PDU Size: Specifies the fixed size of RLC PDUs ready for insertion into MACPDUs.

Mode: Specifies the used mode for this entity (UMD or AMD)

Queue Size: Specifies the maximum buffer size in PDUs for all three buffers -transmission buffer, receive buffer and retransmission buffer - used in the RLC model.


49/99


4.2.5 MAC Model

The MAC star is capable of serving an arbitrary amount of RLC entities. In practice,the size is limited to 15 when using the C/T field in MAC headers. The value receivedat inClock causes MAC to send particles containing RLC PDUs out on outDCH. Themaximum number of particles, that can be sent, is indicated by the value received atinClock. When receiving particles at inDCH, PDUs contained will be sent to all RLCentities. In this simulation environment, it is the task of the RLC models to check theC/T-field for conformity.

MAC

inClock

inDCH

inRLC

outDCH

outRLC

outDeployRLC

Figure 4.5: MAC simulation model

In order to prevent TCP from running into problems with multiple connections over ashared medium, as described in Section 3.3.6, Fair Scheduling is implemented. Everyconnected RLC entity is assigned two unique input buffers by MAC, caching Control andData PDUs independently.

Every time PDUs are allowed to be transmitted onto the channel, MAC first gets all ControlPDUs, deploying single PDUs from each RLC Control PDU buffer, one buffer after theother. If more PDUs can be sent, MAC repeats this loop for all Data PDU buffers.

This ensures prioritization of status report messaging between two RLC peer entities andresults in more timely feedback.

4.2.6 Channel Model

The Channel Model used for all simulations is a transport block loss model. Two parame-ters are specified for the channel model.

Loss Probability: Probability of loss of one transport block while being transmittedover the channel. The losses occur uniformly distributed, since interleaving is used

for actual transmission of transport blocks (see [TS25.101] and [TS25.104

Documents

Tcpip Over Umts